JP4995310B2 - 送信先違いパケットの検出装置および検出方法 - Google Patents

Description

本開示は、ネットワークまたはネットワークデバイスを検査するためのトラフィックの生成および受信に関する。

［著作権とトレードドレスの表示］
本特許文献の開示の一部は、著作権保護の対象となるマテリアルを含む。本特許文献は、所有者のトレードドレスである事項またはなり得る事項を示し、および／または記載し得る。著作権およびトレードドレス権の所有者は、特許商標庁のファイルまたは記録にあることから、本特許開示について任意の者によるファクシミリによる複製に対しては異議を有さないが、他の場合にはいかなる著作権およびトレードドレス権もすべて留保する。

多くの種類の通信ネットワークにおいて、送信される各メッセージは、固定長または可変長の部分に分割される。各部分は、情報のパケット、フレーム、セル、データグラム、データ単位または他の単位と称されることがあり、本文献においては、それらの全てをパケットと称する。

各パケットは、一般にパケットのペイロードと呼ばれる、オリジナルメッセージの一部を含む。パケットのペイロードは、データを含んでもよく、あるいは音声情報またはビデオ情報を含んでもよい。パケットのペイロードはまた、ネットワーク管理制御情報を含んでもよい。それに加えて、各パケットは、一般にパケットヘッダと呼ばれる、識別およびルーティングの情報を含む。パケットは、多数のスイッチまたはノードを介し、ネットワークを通じて個々に送信される。パケットは、メッセージがターゲットデバイスまたはエンドユーザに配信される前に、最終送信先において、パケットヘッダに含まれる情報を用いたメッセージに再構築される。再構築されたメッセージは、受信先において、ユーザ機器と互換性のある形式でエンドユーザに渡される。

メッセージをパケットとして送信する通信ネットワークは、パケット交換ネットワークと呼ばれる。パケット交換ネットワークは、一般的に、ハブまたはノードにおいて交差する送信経路のメッシュを含む。ノードの少なくとも一部は、ノードに到達するパケットを受信し、かつ適切な発信経路に沿ってパケットを再送信する、スイッチングデバイスまたはルータを含んでもよい。パケット交換ネットワークは、業界標準プロトコルの階層構造を基準とする。

パケット交換通信ネットワークに含まれるパケット交換ネットワークまたはデバイスを検査するために、多数のパケットから成る検査トラフィックが、生成され、１つ以上のポートにおいてネットワーク内に送信され、異なるポートにおいて受信されてもよい。この文脈において、「ポート」という用語は、ネットワークと、当該ネットワークを検査するために用いられる機器との間の、通信接続を指す。受信された検査トラフィックを分析することにより、ネットワークの性能を測定してもよい。ネットワークに接続される各ポートは、検査トラフィックの発信元でありかつ検査トラフィックの送信先であってもよい。各ポートは、複数の論理的な発信元または送信先のアドレスをエミュレートしてもよい。ポートの数、およびポートをネットワークに接続する通信経路の数は、一般的に、検査セッションの期間にわたって固定される。ネットワークの内部構造は、例えば通信経路またはハードウェア装置の障害によって、検査セッション中に変化し得る。

検査トラフィック内の各パケットは、１つの特定の送信先ポートにおける受信を意図されるユニキャストパケットであってもよく、または２つ以上の送信先ポートにおける受信を意図され得るマルチキャストパケットであってもよい。しかしながら、パケットは、ネットワークによって送信先違いになることがある。送信先違いパケットは、意図された送信先ではない１つ以上のポートにおいて受信されることがある。

単一のポートから発信し、かつ特定タイプのパケットおよび特定の速度を有する一連のパケットを、本文献において「ストリーム」と称する。発信元ポートは、例えば、多数のパケットタイプ、速度または送信先に対応するために、同時にかつ並行して多数の発信ストリームをサポートしてもよい。「同時に」は、「正確に同一の時刻において」を意味する。「並行して」は、「同一の時間の範囲内で」を意味する。

ストリーム内のパケットは、ネットワークトラフィックデータを報告する目的のために、フローとして編成されてもよい。ここで、「フロー」とは、ネットワークトラフィック統計を蓄積および報告する対象となる任意の複数のパケットのことである。所与のフローにおけるパケットは、各パケットに含まれるフロー識別子によって識別され得る。フロー識別子は、例えば、各データ単位内の、専用識別子フィールド、アドレス、ポート番号、タグ、または何らかの他のフィールドあるいはフィールドの組み合わせであってもよい。

複数の同時発生的ストリームを組み合わせることによって発信元ポートからの出力を形成してもよく、本文献においては、これを「検査トラフィック」と称する。検査トラフィック内のストリームは、インターリービングを介して、順次にまたは並行して送信されてもよい。インターリービングは、表現されるストリーム間において、均衡的、不均衡的、および分散的であってもよい。最新の「トリプルプレイ」のネットワークおよびネットワーク装置を検査するために、検査トラフィックは、シミュレートされたデータ、音声およびビデオのストリームを含んでもよい。

ネットワーク環境のブロック図である。 ポート単位のブロック図である。 パケットを示す図である。 送信先違いパケット検出器のブロック図である。 検査セッションを設計するためのプロセスのフローチャートである。 例示的な送信先リストである。 パケット内の署名フィールドを示す図である。 図６Ａの送信先リストに対する送信先署名の割り当てを示す表である。 図６Ａの送信先リストに対する送信先署名の割り当てを示す表である。 図７Ａおよび図７Ｂの送信先署名のためのポートフィルタの一覧を示す表である。 ネットワークを検査するためのプロセスのフローチャートである。

本文献の記述を通して、ブロック図に見られる構成要素は、３桁の参照番号が割り当てられており、最上位桁の数字は図番号で、下位２桁の数字は構成要素に特有のものである。ブロック図に記載されていない構成要素は、同じ下位２桁の数字の付いた参照番号を有する前述の構成要素と同じ特徴や機能を有するものと推定され得る。

ブロック図において、矢印終端線は、信号というよりはデータ経路を示し得る。各々データ経路は、ビット幅において多数ビットであってよい。例えば、各々のデータ経路は、４，８，１６，３２，６４、あるいはそれ以上の並列接続で構成されてもよい。

［装置の説明］
図１は、ネットワーク環境のブロック図を示す。環境は、ネットワーク検査装置１００、ネットワーク１９０、および複数のネットワークデバイス１９５を備えることができる。

ネットワーク検査装置１００は、ネットワーク検査機器、性能アナライザ、適合性検証システム、ネットワークアナライザ、またはネットワーク管理システムとすることができる。ネットワーク検査装置１００は、シャーシ１１０内に収容または格納される１つ以上のネットワークカード１１４およびバックプレーン１１２を備えてもよい。シャーシ１１０は、ネットワーク検査装置を収容するために適切な固定式または可搬式のシャーシ、キャビネットまたは筐体であってもよい。図１に示すように、ネットワーク検査装置１００は、統合されたユニットであってもよい。それに代わって、ネットワーク検査装置１００は、トラフィックの発生および／または分析を提供するように協調する多数の個別のユニットを備えてもよい。ネットワーク検査装置１００およびネットワークカード１１４は、１つ以上の周知の標準規格またはプロトコル（例えばイーサネット（登録商標）およびファイバチャネルなどの様々な標準規格）をサポートしてもよく、商標つきのプロトコルをサポートしてもよい。

ネットワークカード１１４は、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、プログラマブルロジックアレイ（ＰＬＡ）、プロセッサおよび他の種類のデバイスを含むことができる。それに加えて、ネットワークカード１１４は、ソフトウェアおよび／またはファームウェアを含んでもよい。用語「ネットワークカード」は、ラインカード、検査カード、分析カード、ネットワークラインカード、ロードモジュール、インタフェースカード、ネットワークインタフェースカード、データインタフェースカード、パケットエンジンカード、サービスカード、スマートカード、スイッチカード、リレーアクセスカード等を含む。用語「ネットワークカード」はまた、多数のプリント回路基板を備え得るモジュール、ユニットおよび組立部品をも含む。各ネットワークカード１１４は、単一の通信プロトコルをサポートしてもよく、多数の関連するプロトコルをサポートしてもよく、または多数の無関係なプロトコルをサポートしてもよい。ネットワークカード１１４は、ネットワーク検査装置１００に恒久的に設置されていてもよく、着脱自在であってもよい。

各ネットワークカード１１４は、１つ以上のポートユニット１２０を収容してもよい。１つのポートユニットまたは複数のポートユニットは、それぞれのポートを介してネットワーク１９０に接続されてもよい。各ポートは、それぞれの通信媒体１８５を介してネットワークに接続されてもよく、通信媒体は、ワイヤ、光ファイバ、無線リンク、または他の通信媒体であってもよい。ネットワークを複数のポートに接続する通信媒体は、同じものであってもよく、異なるものであってもよい。各ポートユニット１２０は、検査トラフィックを生成してネットワークに送信してもよく、各ポートユニット１２０は、ネットワークから検査トラフィックを受信してもよい。ポートユニット１２０の１つによって送信されるパケットは、１つ以上の他のポートユニットによって共通に受信されてもよい。

バックプレーン１１２は、ネットワークカード１１４のためのバスまたは通信媒体としての役割を果たしてもよい。バックプレーン１１２はまた、ネットワークカード１１４に電力を供給してもよい。

ネットワークデバイス１９５は、ネットワーク１９０を通じて通信する能力のある任意のデバイスであってもよい。ネットワークデバイス１９５は、コンピューティングデバイス（例えばワークステーション、パーソナルコンピュータ、サーバ、ポータブルコンピュータ、携帯情報端末（ＰＤＡ）、コンピューティングタブレット、携帯電話、電子メール機器等）、周辺機器（例えばプリンタ、スキャナ、ファクシミリ装置等）、ネットワーク対応の記憶装置（例えばネットワーク接続ストレージ（ＮＡＳ）およびストレージエリアネットワーク（ＳＡＮ）デバイス等のディスクドライブを含む）、およびネットワークデバイス（例えばルータ、リレー、ハブ、スイッチ、ブリッジ、およびマルチプレクサ）であってもよい。それに加えて、ネットワークデバイス１９５は、ネットワークを通じて通信する能力のある家庭電化器具、アラームシステムおよび他の任意のデバイスまたはシステムを含んでもよい。

ネットワーク１９０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ストレージエリアネットワーク（ＳＡＮ）、有線、無線、またはこれらの組み合わせであってもよく、インターネットを含んでもよく、またはインターネットであってもよい。ネットワーク１９０上の通信は、情報のフレーム、セル、データグラム、パケットまたは他の単位を含む様々な形態をとってもよく、本文献においては、それらの全てをパケットと称する。ネットワーク検査装置１００およびネットワークデバイス１９５は、同時に相互に通信してもよく、ネットワーク検査装置１００と所与のネットワークデバイス１９５との間には、複数の論理的通信経路があってもよい。ネットワークそのものは、伝えるデータのための多数の物理的経路および論理的経路を提供する多数のノードから成ってもよい。

ここで図２を参照し、例示的なポートユニット２２０は、ポートプロセッサ２２２と、トラフィックジェネレータ２２８と、トラフィック受信器２４０と、ポートユニット２２０を被検査ネットワーク２９０に接続するネットワークインタフェース装置２３２とを備えてもよい。ポートユニット２２０は、ネットワークカード（例えばネットワークカード１１４）のすべてまたは一部であってもよい。

ポートプロセッサ２２２は、本文献に記載される機能および特徴を提供するための、プロセッサ、プロセッサに接続されたメモリ、および様々な特殊化された装置、回路、ソフトウェアおよびインタフェースを含んでもよい。プロセス、機能および特徴は、全体的にあるいは部分的に、プロセッサ上で動作するソフトウェアにおいて実現されてもよく、ファームウェア、アプリケーションプログラム、アプレット（例えばＪａｖａ（登録商標）アプレット）、ブラウザプラグイン、ＣＯＭオブジェクト、ダイナミックリンクライブラリ（ＤＬＬ）、スクリプト、１つ以上のサブルーチン、またはオペレーティングシステムのコンポーネントまたはサービスという形をとってもよい。ハードウェアおよびソフトウェアおよびそれらの機能は、一部の機能がプロセッサによって実行され、他の機能が他の装置によって実行されるように、分散型であってもよい。

ポートプロセッサ２２２は、検査アドミニストレータ２０５と通信してもよい。検査アドミニストレータ２０５は、ネットワーク検査装置１００の内部に収容されるコンピューティングデバイスまたは外部のコンピューティングデバイスであってもよい。検査アドミニストレータ２０５は、ポートユニットがネットワーク２９０の検査に関与するために必要とされる命令およびデータを、ポートプロセッサに提供してもよい。検査アドミニストレータ２０５から受信される命令およびデータは、例えば、ポートユニット２２０によって生成されるパケットストリームの定義、およびポートユニット２２０によって蓄積および報告され得る性能統計の定義を含んでもよい。

ポートプロセッサ２２２は、検査命令２２４をトラフィックジェネレータ２２８に提供してもよい。検査命令２２４は、発信検査トラフィック２３０を形成するためにインターリーブされ得る複数のストリームを、トラフィックジェネレータ２２８に形成させてもよい。次に、トラフィックジェネレータ２２８は、検査命令２２４に従って複数のストリームを生成してもよい。ストリームの各々は、一連のパケットを含んでもよい。検査命令２２４は、例えば、パケットの種類、送信の周波数、パケット内部の固定内容フィールドおよび可変内容フィールドの定義、および各パケットストリームのための他の情報を含んでもよい。

ネットワークインタフェース装置２３２は、トラフィックジェネレータ２２８からの発信検査トラフィック２３０を、リンク２８５を介して被検査ネットワーク２９０に送信するために必要な電気信号、光学信号または無線信号の形式に変換してもよく、リンクは、ワイヤ、光ファイバ、無線リンクまたは他の通信リンクであってもよい。同様に、ネットワークインタフェース装置２３２は、ネットワークからリンク２８５を通じて電気信号、光学信号または無線信号を受信してもよく、受信した信号を、トラフィック受信器２４０において使用可能な形式の着信検査トラフィック２３４に変換してもよい。

トラフィック受信器２４０は、ネットワークインタフェース装置２３２から着信検査トラフィック２３４を受信してもよい。トラフィック受信器２４０は、各受信パケットが、進行中の検査に関連するか否か、かつ意図された送信先において受信されたか否かを決定するために、送信先違いパケット検出器２４２を備えてもよい。送信先違いパケット検出器２４２は、送信先違いの受信パケットまたは意図されない送信先において受信された受信パケットの、累積カウントを保持してもよい。受信されたパケットが正しい送信先にあることが決定されると、トラフィック受信器２４０は、受信されたパケットを特定のフローの一部として識別してもよく、フローごとに検査統計を蓄積してもよい。蓄積された検査統計は、例えば、受信パケットの合計数、順番誤りで受信されたパケットの数、エラーを有する受信パケットの数、最大、平均および最小の伝搬遅延、および各フローの他の統計を含んでもよい。トラフィック受信器２４０はまた、ポートプロセッサ２２２によって提供される取得基準に従って、特定のパケットを取得および格納してもよい。トラフィック受信器２４０は、検査セッションの最中または後における更なる分析のために、検査統計および／または取得パケット２３６を、ポートプロセッサ２２２に提供してもよい。

発信検査トラフィック２３０および着信検査トラフィック２３４は、主にステートレスであってもよい。すなわち、発信検査トラフィック２３０は、応答を予期することなく生成されてもよく、着信検査トラフィック２３４は、応答を意図することなく受信されてもよい。しかしながら、検査セッション中に、ポートユニット２２０とネットワーク２９０との間で、若干量のステートフルの（または対話型の）通信が要求されるかまたは望ましい場合がある。例えば、トラフィック受信器２４０は、制御パケットを受信してもよい。制御パケットは、検査セッションを制御するために必要なデータを含むパケットであり、ポートユニットに受信通知または応答の送信を要求する。

トラフィック受信器２４０は、着信制御パケットを着信検査トラフィックから分離してもよく、着信制御パケット２３４をポートプロセッサ２２２にルーティングしてもよい。ポートプロセッサ２２２は、各制御パケットのコンテンツを抽出してもよく、１つ以上の発信制御パケット２２６の形で適切な応答を生成してもよい。発信制御パケット２２６は、トラフィックジェネレータ２２８に提供されてもよい。トラフィックジェネレータ２２８は、発信制御パケットを発信検査トラフィック２３０の中に挿入してもよい。

ここで図３を参照し、代表的なパケット３４４は、ヘッダ３４６とペイロード３４８とを含んでもよい。ヘッダ３４６は、順次的な通信プロトコルレイヤに対応する複数のカスケード式ヘッダを含んでもよい。例えば、ヘッダ３４６は、レイヤ２ヘッダ（例えば媒体アクセス制御ヘッダ）、レイヤ３ヘッダ（例えばインターネットプロトコルヘッダ）、およびレイヤ４ヘッダ（例えば伝送制御プロトコルヘッダまたはユーザデータグラムプロトコルヘッダ）を含んでもよい。それに加えて、例えば、マルチプルプロトコルラベルスイッチングラベルまたはトンネリングプロトコルヘッダを追加または削除することによって、ネットワーク経由の送信中に、パケット３４４のヘッダ３４６が変更されてもよい。従って、ヘッダ３４６内の様々なフィールドを解析および解釈するために、相当な量の処理が必要となり得る。

パケット受信器が、受信されたパケットが検査セッションの一部であるか否かを決定することを可能にし、パケット受信器が、パケットのヘッダ部分を解析することなく、受信されたパケットから検査データを抽出することを可能にするために、パケット３４４は、署名３５０および１つ以上の検査データフィールド３５６を含んでもよい。署名３５０および検査データフィールド３５６は、一般的にペイロード３４８内に配置されてもよい。トラフィック受信器は、検査署名の公知の数値に対する浮動比較またはパターン一致を実行することによって、受信されたパケット内に署名３５０を見つけてもよい。トラフィック受信器は、署名３５０との関係におけるこれらのフィールドの公知の位置に基づいて、検査データ３５６を見つけて抽出してもよい。検査データフィールド３５６は、例えば、パケットフロー識別子（パケットグループ識別子とも呼ばれる）、識別されたパケットフロー内のシーケンス番号、タイムスタンプ、および他の検査情報を含んでもよい。図３に示すように、検査データフィールド３５６は、単に署名フィールド３５０の直後にあってもよい。検査データフィールド３５６は、パケット３４４内において署名３５０から既知量だけオフセットした他の場所において見つけられてもよい。検査パケットを検証するための署名の使用は、引用によって本文献に援用される米国特許第６７１７９１７Ｂ１号明細書に、更に記載されている。パケット内に検査データを見つけるための署名の使用は、引用によって本文献に援用される米国特許出願公開第２００７／０１１５８３３Ａ１号明細書に、更に記載されている。

受信されたパケットが送信先違いであるかまたは意図されないロケーションにおいて受信されたか否かを、トラフィック受信器が決定できるようにするために、署名３５０は、検査署名３５２と送信先署名３５４とに分割されてもよい。検査署名３５２は、受信されたパケットを、特定の検査セッションに関連する検査パケットとして識別してもよい。検査署名３５２は、検査セッション中に生成されるすべてのパケットに対して共通であってもよい。送信先署名３５４は、ネットワーク検査装置（例えばネットワーク検査装置１００）のいずれのポートが各パケットを受信するように意図されるかを定義してもよい。

説明を容易にするために、図３の例における署名３５０は、長さ２４ビットとして示される。現実の状況においては、署名３５０は、非検査パケットが署名と重複するビット列を含む確率がごくわずかであるように、有効な長さであってもよい。署名の長さは、例えば８バイト、１２バイトまたは１６バイトであってもよい。

検査署名３５２は、検査フィルタ３５８を用いて浮動パターン一致を実行することによって、パケット３４４内に検出されてもよい。検査フィルタ３５８は、検査署名のための期待値と、署名３５０のうちの何ビットが検査署名３５２として用いられるかを定義するマスクとを含んでもよい。この例においては、マスク内のビット位置の論理的「１」は、署名３５０内の対応するビットが検査署名３５２の一部であることを示し、マスク内のビット位置の論理的「０」は、署名３５０内の対応するビットが検査署名３５２の一部ではないために無視されることを示す。この例において、検査署名３５２は、署名３５０の左側の１８ビットである。マスク内の論理的「１」および論理的「０」の意味は、逆転してもよい。

送信先署名３５４がポートフィルタ３６０と一致しない場合には、パケット３４４は送信先違いであると決定されてもよい。ポートフィルタ３６０は、署名３５０の何ビットが数値と一致しなければならないかを定義する数値およびマスクを含んでもよい。この例においては、マスク内のビット位置の論理的「１」は、署名３５０内の対応するビットが数値の対応するビットに一致しなければならないことを示し、マスクのビット位置の論理的「０」は、署名３５０内の対応するビットが無視されるべきであることを示す。この例において、署名３５０の右側の６ビットが送信先署名として使用されるために利用可能であるが、利用可能な６ビットのうちの２つは無視される。

ここで図４を参照し、パケット受信器４４０（パケット受信器２４０であってもよい）は、送信先違いパケット検出器４４２を含んでもよく、送信先違いパケット検出器４４２は、第１のマスキングされたコンパレータ４６２と、第２のマスキングされたコンパレータ４６４と、送信先違いパケットカウンタ４６８とを含んでもよい。この文脈において、「マスキングされたコンパレータ」は、各２進数における特定のビット位置が無視されるかまたは「考慮せず」として指定されるように、マスクを介して２つの２進数を比較する論理回路である。

第１のマスキングされたコンパレータ４６２は、受信されたパケット４４４と検査フィルタ４５８との間の浮動パターン比較を実行することにより、受信されたパケット４４４によって検査署名４５２を（存在する場合には）見つけてもよい。受信されたパケット４４４が有効なテキスト署名４５２を含まない場合には、受信されたパケット４４４は、単に放棄または無視されてもよい。受信されたパケット４４４が有効な検査署名４５２を含む場合には、第２のマスキングされたコンパレータ４６４は、受信されたパケット４４４から抽出された送信先署名４５４を、ポートフィルタ４６０と比較してもよい。検査フィルタ４５８およびポートフィルタ４６０のコンテンツおよび形式は、検査フィルタ３５８およびポートフィルタ３６０と同様でもよいが、実質的により長くてもよい。送信先署名４５２とポートフィルタ４６０とが一致することは、受信されたパケットが意図されたロケーションにおいて正しく受信されたことを示す。

受信されたパケットが、有効な検査署名４５２と、（ＡＮＤゲート４７０によって示されるように）ポートフィルタ４６０と一致する送信先署名４５４とを含む場合には、フロー統計エンジン４７２は、受信パケット４４４から検査データ４５６を抽出することを可能にされてもよい。次に、フロー統計エンジンは、抽出された検査データに基づいて、検査統計を蓄積してもよい。検査統計は、例えば、フローごとに受信されたパケットの合計数および／またはフローごとに受信された順番誤りパケットの合計数などの累積的な情報、フローごとの最小、最大および／または平均の待ち時間などの時間的情報、および被検査ネットワークの性能を示す他の情報を含んでもよい。

受信されたパケットが、有効な検査署名４５２を含むが、（ＡＮＤゲート４６６によって示されるように）送信先署名４５４がポートフィルタ４６０と一致しない場合には、受信されたパケット４４４は、進行中の検査セッションに属するが、送信先違いであり、意図されない送信先において受信されたということである。この場合、送信先違いパケットカウンタ４６８は、検査セッションの開始時はゼロに設定されていてもよく、トラフィック受信器４４０において受信される送信先違いパケットの累積的な合計数を示すように増加させられてもよい。

［プロセスの説明］
ここで図５を参照し、検査セッションを設計するためのプロセス５００は、５０５において始まり、５９５において終了してもよく、それから検査が開始される。５１０において、検査中に生成、送信、受信および分析される予定のパケットストリームおよびフローの全てが定義されてもよい。ネットワーク装置の単一の項目の検査、または少数の性能パラメータを測定する検査などの、一部の場合において、パケットストリームおよびフローは、検査エンジニアによって定義されてもよい。より複雑な検査においては、検査エンジニアによって入力される検査パラメータおよび検査要件に応じて、ストリームおよびフローは、少なくとも部分的に、検査システムによって自動的に定義されてもよい。例えば、検査エンジニアは、各ポートにおいてネットワークに送信されるパケットの合計数、ポートの一部または全部における所望のトラフィック混合比、伝送速度またはローディング、および／または他の検査パラメータを規定してもよい。次に、検査システムは、検査エンジニアによって設定された要件を満たす複数のストリームおよびフローを定義してもよい。

５１５において、５１０からのストリームおよびフローの定義を分析することにより、パケットを受信する予定の送信先のすべて、および各送信先に関連する検査装置のポートを識別してもよい。この文脈において、「送信先」は、ユニキャストパケットを受信するポート、または同一のマルチキャストパケットを受信するポートのグループであってもよい。各送信先は、１つ以上の発信元から、パケットの、１つまたは多数のストリームおよびフローを受信してもよい。

５２０において、識別された送信先は、分類または処理されることにより、相互連結されたポートグループ（ＩＣＰＧ）を識別してもよい。ここで、ＩＣＰＧは、当該グループの他の任意の一部によってマルチキャストパケットを受信するすべてのポートを含む。逆に、ＩＣＰＧ内のポートは、ＩＣＰＧの一部ではない他の任意のポートによってマルチキャストパケットを受信することはない。ＩＣＰＧによって分類した例示的な送信先リストを図６Ａに示す。この例において、ネットワーク検査装置は、図６Ａにおいて０乃至Ｆの１６進数によって識別される１６個のポートにおいてパケットを受信する。検査セッションは、Ｄ１乃至Ｄ１７として識別される合計１７個の送信先にパケットを送信する。例えば、Ｄ１は、ポート０において受信されるべき（任意の発信元からの任意の種類の）すべてのユニキャストパケットの送信先である。同様に、Ｄ９は、ポート６、７および８からなるマルチキャストグループにおいて受信されるべきすべてのパケットの送信先である。

ポート０、１、２、３、４、６、Ｃ、ＤおよびＦは、ユニキャストパケットを受信することが、図６Ａから分かる。これらのうち、ポート２、３およびＦは、ユニキャストパケットのみを受信し、ポート０、１、４、６、ＣおよびＤは、ユニキャストパケットおよびマルチキャストパケットを受信する。ポート５、７、８、９、ＡおよびＢは、少なくとも１つの他のポートに対してマルチキャストであるパケットのみを受信する。

送信先Ｄ３は、ポート０および１からなるマルチキャストグループである。ポート０および１は、他の任意のマルチキャストグループの一部ではないので、ポート０および１は、単にポート番号０１のラベルをつけられる第１のＩＣＰＧを構成する。ＩＣＰＧ０１はまた、送信先Ｄ１、Ｄ２およびＤ３にも対応する。送信先Ｄ１、Ｄ２またはＤ３にアドレス指定される任意のパケットは、ＩＣＰＧ０１内の１つ以上のポートにおいて受信されるように意図されるものであり、ＩＣＰＧ０１の一部ではない任意のポートによって受信されるべきではない。同様に、ポート４および５は、送信先Ｄ６およびＤ７に対応するＩＣＰＧ４５を構成し、ポート６、７および８は、送信先Ｄ８、Ｄ９およびＤ１０に対応するＩＣＰＧ６７８を構成し、ＲＸポート９、ＡおよびＢは、送信先Ｄ１１およびＤ１２に対応するＩＣＰＧ９ＡＢを構成し、ポートＣ、ＤおよびＥは、送信先Ｄ１３乃至Ｄ１６に対応するＩＣＰＧＣＤＥを構成する。図６Ａの例において、合計１７個の送信先は、５つのＩＣＰＧと、ユニキャストポートグループを構成するとみなされ得る３つのユニキャスト専用の送信先（Ｄ４、Ｄ５、Ｄ１７）とに編成することができる。

図６Ａに示す送信先のリストは、例示的なものであり、図６Ａに示すような表のリストは、実際には検査セッションごとに作成しなくてもよい。むしろ、送信先およびＩＣＰＧは、独立セットデータ構造を操作するための公知の技術を用いて、自動的に識別されてもよい。例えば、各受信ポートユニットは、ノードによって表現されてもよく、各マルチキャストグループは、関連するポートユニットを接続するエッジまたは経路によって表現されてもよい。ノードおよび経路の組み合わせは、いわゆる独立ツリーデータフォレストを形成する。ここで、各孤立ノードは、ユニキャストパケットのみを受信するポートを表現し、各ツリーデータセットは、ＩＣＰＧ内のポートを表現する。

ここで図６Ｂを参照し、送信先署名６５４は、各送信先に割り当てられてもよい。割り当てられた送信先署名は、対応する送信先に送信される各パケット内に埋め込まれてもよい。送信先署名６５４は、それぞれの送信先に送信されたパケットを受信するポートを含むＩＣＰＧまたはユニキャストグループを識別する、グループコード６５４Ａを含んでもよい。送信先署名６５４は、グループコード６５４Ａによって識別されるＩＣＰＧ内のいずれの特定のポートがそれぞれの送信先に送信されたパケットを受信するように意図されるかを示す、ポートイネーブル（ＰＥ）ビット６５４Ｂを更に含んでもよい。

図５に戻り、５２０において、ＩＣＰＧおよびユニキャスト送信先が一旦識別されると、各ＩＣＰＧ内のいずれの特定のポートがパケットを受信するように意図されるかを識別するために必要な、ＰＥビットの数が決定されてもよい。送信先が、マルチキャストグループを形成する多数のポートを含む場合には、対応する送信先署名６５４のグループコード６５４Ａは、当該マルチキャストグループにおけるすべてのポートおよび相互連結された他のすべてのポートを含むＩＣＰＧを識別してもよい。この場合、各ＰＥビット６５４Ｂは、ＩＣＰＧ内の対応するポートが、送信先に送信されるパケットを受信するように意図されること、または意図されないことを示してもよい。必要とされるＰＥビットの最大数が、最大のＩＣＰＧ（最も多くのポートを含むＩＣＰＧ）内のポートの数に等しくなり得るように、各ＰＥビットは、単一のポートに対応してもよい。一部の状況（その例は引き続いて考察する）において、ＰＥビットの数は、最大のＩＣＰＧにおけるポートの数よりも少なくてもよい。

５３０において、ＩＣＰＧおよびユニキャストグループの合計数が決定されてもよい。ＩＣＰＧの数は、５２０からわかってもよく、ユニキャストグループの数は、５２０において識別されたユニキャストポートの数および５２５において割り当てられたＰＥビット数に基づいて決定されてもよい。送信先が、ユニキャストパケットのみを受信する単一のポートを含む場合には、対応する送信先署名６５４のグループコード６５４Ａは、当該ポートを含むユニキャストグループを識別してもよく、ＰＥビットは、当該ユニキャストグループ内の特定のポートを識別してもよい。ユニキャストグループ内のポートの最大数は、５２５において決定されるように、ＰＥビットの利用可能な数によって決定されてもよい。図６Ａの例において、最大のＩＣＰＧは、３つのポートのみを含む。従って、図６Ａにおいて定義される送信先に割り当てられる送信先署名は、３つのＰＥビットを含んでもよい。各ユニキャストグループは、最高８つのユニキャストポートを含んでもよく（図６Ａにおいては３つのユニキャストポートのみが定義されている）、そのそれぞれは、８つの可能な別個の３ビットのＰＥ数値のうちの１つによって指定されてもよい。

５３５において、グループコード６５４Ａに必要なビット数は、５３０からのＩＣＰＧおよびユニキャストグループの合計数に基づいて決定されてもよい。図６Ａの例は、１７個の送信先を含むが、５２０、５２５および５３０において、５つのＩＣＰＧおよび１つのユニキャストグループに編成されてもよい。この例を続け、これらの６つのグループは、３ビットのグループコード６５４Ａを用いて、明白に識別されることができる。６つのグループの各々に、一意の３ビット数値が割り当てられてもよい。図６Ｂは、図６Ａにおいて定義される６つのＩＣＰＧに割り当てられるグループコードの例を含む。各グループが一意のグループコードを受け取る限り、グループコードは任意に割り当てられてもよい。

５４０において、グループコードビットとＰＥビットとを組み合わせた長さである送信先署名の長さが、所定の最大ビット数を超えるか否かが決定されてもよい。極端な例として、２５６個の受信ポートに関与し多数かつ広範囲のマルチキャストアドレス方式を使用した検査セッションは、単一のＩＣＰＧのみを有してもよい。この場合、送信先署名は、２５６個のＰＥビットを必要としてもよい。２５６ビットの送信先署名は、ショートパケットのペイロード全体を消費し得るし、各トラフィック受信器内に大規模な専用ハードウェアを必要とし得るので、非実用的である。送信先署名のための所定の最大ビット数は、２４ビット、３２ビットまたは６４ビット、あるいは他の何らかの数値であってもよい。

５４０において送信先署名が長すぎると決定された場合には、５４５において送信先違いパケット検出機能が無効にされてもよく、プロセス５００は５６０にて継続してもよい。５４５において送信先違いパケット検出機能を無効にすることは、５１０において定義されたストリームおよびフローに対して送信先違いパケット検出機能が利用不可である旨を検査エンジニアまたは他のオペレータに通知することを含んでもよい。５４５において送信先違いパケット検出機能を無効にすることは、各ポートユニットに対して、送信先違いパケット検出が使われなくなる旨を示すフラグを設定することまたはメッセージを送信することを含んでもよい。すべての受信ポートのためのポートフィルタのすべてのビットを「考慮せず」に設定することによって、５４５において送信先違いパケット検出機能が無効にされてもよい。ポートフィルタのすべてのビットが「考慮せず」である場合には、すべてのパケットは、受信トラフィック受信器においてポートフィルタと自動的に一致する。従って、各トラフィック受信器は、受信されたパケットが送信先違いであるという決定を決してしない。

５４０において、必要とされる送信先署名の長さが許容可能であると決定された場合には、５５０において、各送信先に一意の送信先署名が割り当てられてもよく、対応するポートフィルタが生成されてもよい。５５０において、検査セッション中にパケットを受信する予定のポートごとに、ポートフィルタが生成されてもよい。図７Ａ、図７Ｂおよび図８は、図６Ａの例を続けるものである。図７Ａおよび図７Ｂは、図６Ａにおいて定義される１７個の送信先Ｄ１乃至Ｄ１７に割り当てられる送信先署名の例を提供する。各送信先のための送信先署名は、３ビットのグループコードおよび３つのＰＥビットから成る。グループコードは、ＩＣＰＧまたはユニキャストグループを識別する。この例において、グループコード０００は、ユニキャスト送信先に割り当てられており、グループコード００１乃至１０１は、それぞれＩＣＰＧ０１、４５、６７８、９ＡＢおよびＣＤＥに順番に割り当てられている。各ＩＣＰＧまたはユニキャストグループが一意の３ビット数値を受け取る限り、グループコードの割当ては完全に任意であってもよい。

この例において、各送信先署名は、グループ内の特定のポートがそれぞれの送信先に送信されたパケットを受信することを可能にする３つのＰＥビットを含む。例えば、ＩＣＰＧ０１を構成する送信先Ｄ１、Ｄ２およびＤ３に割り当てられた送信先署名について考察する。ポート０が受信できるのは、送信先Ｄ１に送信されたパケット（ポート０に対するユニキャストパケット）および送信先Ｄ３に送信されたパケット（ポート０および１に送信されたマルチキャストパケット）であって、送信先Ｄ２に送信されたパケット（ポート１に対するユニキャストパケット）ではない。同様に、ポート１が受信できるのは、送信先Ｄ２に送信されたパケット（ポート１に対するユニキャストパケット）および送信先Ｄ３に送信されたパケット（ポート０および１に送信されるマルチキャストパケット）であって、送信先Ｄ１に送信されたパケット（ポート０に対するユニキャストパケット）ではない。各ポートを有効にするために別個のビットが用いられる限り、３つのＰＥビットのうちのいずれのビットがポート０を有効にし、いずれのビットがポート１を有効にするかという選択は、任意である。

ポート４は、送信先Ｄ６およびＤ７に設定されたパケットを受信する、すなわちポート４は、ＩＣＰＧ４５に送信されたすべてのパケットを受信する、ということに留意されたい。従って、ポート４は、グループコード０１０を有するすべてのパケットを受信するように意図されるため、ポート４のためのＰＥビットは必要ではない。同様に、ポートＡは、ＩＣＰＧ９ＡＢに送信されるすべてのパケットを受信するため、ＰＥビットを必要としない。また、ポート７および８の両者は、送信先Ｄ８ではなく、送信先Ｄ９およびＤ１０に送信されたパケットを受信する、ということにも留意されたい。ポート７および８は常に同一のパケットを受信するため、ポート７および８は単一のＰＥビットを「共有」する。

図８は、ポート０乃至Ｆのためのポートフィルタを示すものであり、これらは図７Ａおよび図７Ｂの送信先署名から直接的に導き出すことができる。例えば、ポート０のためのポートフィルタは、「００１」に等しいグループコード（左側の３ビット）と「１」に等しい右側ＰＥビットとを有する送信先署名を含むパケット（送信先Ｄ１およびＤ３に送信されたパケットを含む）を、ポート０が受信するように意図されていることを示す。同様に、（この例においてユニキャストパケットのみを受信する）ポート３ためのポートフィルタは、「０００００１」に等しい送信先署名を含むパケットを、ポート３が受信するように意図されていることを示す。

各ポートフィルタは、ポートフィルタ数値と、当該数値のいずれのビットが用いられないかまたは「考慮せず」であるかを示す別個のポートフィルタマスクとを含んでもよい。例えば、ポート０のためのポートフィルタ数値は「００１００１」であってもよく、ポートフィルタマスクは「１１１００１」であってもよく、ここで、「１」は送信先署名がポートフィルタ数値のそれぞれのビットと一致しなければならないことを示し、「０」は送信先署名のそれぞれのビットが「考慮せず」であることを示す。

再び図５を参照し、検査署名および検査フィルタは、５６０において生成されてもよい。検査署名は、完全にランダムであってもよく、または例えば、ある初期値に基づいてハッシュ関数の適用によって生成されてもよい。初期値は、例えば、検査エンジニアまたは他のオペレータによって提供される検査セッション名またはログイン名などの入力であってもよい。検査署名と送信先署名のいずれかとを組み合わせた長さが所定の長さと等しくなるように、検査署名の長さが設定されてもよい。所定の長さは、例えば、８バイト、１２バイト、１６バイトまたは他の何らかの長さであってもよい。検査フィルタは、検査署名数値および対応するマスクを含んでもよい。

５６５において、検査セッションを実行するために必要な情報は、検査セッションに関与する予定のポートユニットに配信されてもよい。検査セッション中にパケットを生成する予定のポートユニットに配布される情報は、５６０からの検査署名、５５０からの送信先署名、および５１０から生成されるストリームおよびフローを定義するデータを含んでもよい。パケットを受信する予定の各ポートユニットに配布される情報は、５６０からの検査フィルタと５５５からの対応するポートフィルタとを含んでもよい。性能統計を蓄積するための命令およびパケットを取得するための命令などの他の情報もまた、パケットを受信する予定のポートユニットの一部または全部に配布されてもよい。検査セッションを実行するために必要なすべての情報が配布されたときに、図９に示すように検査セッションが進行してもよい。

ここで図９を参照し、ネットワークを検査するためのプロセス９００は、（図５に示すように）検査セッションが設計された後に開始してもよく、ネットワーク検査セッション中に多数のパケットに対して周期的に繰り返されてもよい。説明を容易にするために、プロセス９００は、第１ポートユニット上のトラフィックジェネレータ（例えばトラフィックジェネレータ２２８）から、第２ポートユニット上のトラフィック受信器（例えばトラフィック受信器４４０）に対して単一のパケットを送信するために実行される、一連の順次的なステップとして示される。しかしながら、多数のパケットが並行して進行中であるように、プロセス９００はパイプライン式の態様で実行されてもよい。更に、プロセス９００は、パケットを生成および受信する多数のポートユニットによって並行して実行されてもよい。

検査セッションの開始時、すなわち９０５において、各受信ポートユニットの送信先違いパケットカウンタは、ゼロに設定されてもよい。９１０において、パケットは、送信ポートユニットから生成および送信されてもよい。パケットは、検査署名および送信先署名を含んでもよい。パケットは、被検査ネットワーク９９０を通過してもよく、９１５において受信ポートユニットに受信されてもよい。一部の場合において、パケットは、同一のポートユニットによって送受信されてもよい。

９２０において、受信ポートユニットは、パケットが有効な検査署名を含むか否かを決定してもよい。受信ポートユニットは、検査フィルタを用いて浮動パターン一致を実行することによって、パケットが有効な検査署名を含むか否かを決定してもよい。受信ポートユニットが、受信されたパケット内に有効な検査署名を見つけることができない場合には、受信されたパケットは、９２５において放棄されてもよい。一部の場合において、受信ポートユニットは、有効な検査署名を有しないパケットを制御パケットとして認識してもよく、当該制御パケットを更なる処理のためにプロセッサ（図示せず）に転送してもよい。

９２０において、受信ポートユニットが、受信されたパケット内に有効な検査署名を見つけた場合には、９３０において、受信ポートユニットは、当該パケットが正しい送信先において受信されたか否かを決定してもよい。受信ポートユニットは、受信されたパケットから送信先署名を抽出してもよい。抽出された送信先署名がポートフィルタと一致する場合には、受信ポートユニットは、パケットが正しく受信されたと決定してもよい。送信先署名がポートフィルタと一致しない場合には、受信ポートユニットは、受信されたパケットが送信先違いであると決定してもよい。この場合には、９３５において、受信ポートユニット内の送信先違いパケットカウンタが増加させられてもよい。

９３０において、受信ポートユニットが、パケットが正しく受信されたと決定した場合には、９４０において検査データが抽出されてもよく、抽出された検査データに基づいて検査統計が蓄積されてもよい。

［結びのコメント］
本文献を通して示される実施形態および例は、開示または請求される装置および手順に対する限定ではなく、例としてみなされるべきである。本文献に示される例の多くは、方法行為またはシステム要素の特定の組み合わせを含むが、それらの行為および要素は、同一の目的を達成する他の方法と組み合わせられ得ることが理解されるべきである。フローチャートに関しては、更なるステップやより少ないステップをとり得るものであり、図示したステップは、組み合わせられるかまたは更に洗練されることにより、本文献に記載される方法を達成し得る。一実施形態のみに関連して説明した行為、要素および特徴は、他の実施形態における同様の役割から除外されることを意図しない。

本文献で用いられる「複数」は、２つ以上であるということを意味する。本文献で用いられる、項目の「セット」は、そのような項目の１つ以上を含み得る。明細書または特許請求の範囲のいずれにおいても、本文献で用いられる「備える」、「含む」、「持つ」、「有する」、「包含する」、「伴う」等の用語は、オープンエンド、すなわち含むが限定しないことを意味すると理解されるべきである。特許請求の範囲に関しては、「から成る」および「から基本的に成る」という移行句のみが、それぞれ、閉じた移行句またはやや閉じた移行句である。特許請求の範囲において請求項要素を修飾する「第１」「第２」「第３」等の序数用語の使用は、それ自身ではいかなる優先順、優先度、または他の請求項に対するある請求項の順序、あるいは方法の行為が実行される時間的順序を暗示するものではなく、同一の名称を有する別の要素から特定の名称を有する１つの要素を区別し、請求項要素を区別するためのラベルとして単に使用されるものである（序数用語の使用を除く）。本文献で用いられる「および／または」は、列挙される項目が選択肢であることを意味するが、選択肢もまた列挙される項目の任意の組み合わせを含む。

Claims (22)

1. ネットワークを検査する方法であって、
   ポートユニットにおいて前記ネットワークからパケットを受信する工程と、
   前記受信されたパケットが有効な検査署名を含むか否かを決定する工程と、
   前記受信されたパケットが有効な検査署名を含む場合には、前記ポートユニットが前記受信されたパケットのための予想される送信先であるか否かを、前記受信されたパケットから抽出される送信先署名とポートフィルタとを比較して決定する工程と、
   前記ポートユニットが前記受信されたパケットのための予想される送信先ではない場合には、送信先違いパケットカウンタを増加させる工程と、
   前記ポートユニットが前記受信されたパケットのための予想される送信先である場合には、前記受信されたパケットから検査データを抽出する工程と、
   を含み、
   前記検査署名および前記送信先署名は、前記受信されたパケットのペイロード部分に含まれ、該ペイロード部分から抽出される、方法。
2. 請求項１の方法において、前記受信されたパケットは、有効な検査署名を含まない場合には無視される。
3. 請求項１のネットワークを検査する方法において、前記受信されたパケットから抽出された送信先署名がポートフィルタと一致する場合には、前記ポートユニットは、前記受信されたパケットのための予想される送信先であると決定される。
4. 請求項１のネットワークを検査する方法において、前記受信されたパケットが有効な検査署名を含むか否かを決定する工程は、前記受信されたパケットと参照検査署名との間の浮動パターン一致を実行する工程を含む。
5. 請求項４のネットワークを検査する方法において、前記抽出された検査データに基づいて検査統計を蓄積する工程をさらに含む。
6. ネットワークを検査する方法であって、
   １つ以上の送信ポートユニットと複数の受信ポートユニットとを含む検査装置をネットワークに接続する工程と、
   前記ネットワークを介して前記送信ポートユニットから前記受信ポートユニットへと送信される複数のパケットを定義する工程であって、各パケットは検査署名および送信先署名を含む、工程と、
   前記ネットワークを介して前記定義された複数のパケットを送信する工程と、
   を含み、
   前記複数の受信ポートユニットのうちの第１ポートユニットは、
   第１パケットを受信する工程と、
   前記受信されたパケットが有効な検査署名を含まない場合には、前記受信されたパケットを無視する工程と、
   前記受信されたパケットが有効な検査署名を含む場合には、前記送信先署名に基づいて、前記第１ポートユニットが前記受信されたパケットのための予想される送信先であるか否かを、前記受信されたパケットから抽出される前記送信先署名とポートフィルタとを比較して決定する工程と、
   前記第１ポートユニットが前記受信されたパケットのための予想される送信先ではない場合には、送信先違いパケットカウンタを増加させる工程と、
   前記第１ポートユニットが前記受信されたパケットのための予想される送信先である場合には、前記受信されたパケットから検査データを抽出する工程と、
   を含み、
   前記検査署名および前記送信先署名は、前記受信されたパケットのペイロード部分に含まれ、該ペイロード部分から抽出される、方法。
7. 請求項６のネットワークを検査する方法において、前記受信されたパケットと参照検査署名との間の浮動パターン一致を実行することによって、前記受信されたパケットが有効な検査署名を含むか否かを決定する工程をさらに含む。
8. 請求項７のネットワークを検査する方法において、前記抽出された検査データに基づいて検査統計を蓄積する工程をさらに含む。
9. 請求項６のネットワークを検査する方法において、前記複数のパケットを定義する工程は、
   前記複数のパケットのために、送信先および関連する意図された送信先ポートのリストを構築する工程と、
   前記送信先を複数のポートグループに分類する工程と、
   前記送信先の各々の送信先署名を定義する工程と、をさらに含む。
10. 請求項９のネットワークを検査する方法において、前記複数のパケットを定義する工程は、
    疑似ランダム検査署名を生成する工程と、
    前記検査署名と前記送信先署名の少なくとも一部とを前記送信ポートユニットの各々に送信する工程と、をさらに含む。
11. 請求項１０のネットワークを検査する方法において、前記複数のパケットを定義する工程は、
    前記複数の受信ポートユニットの各々のためのそれぞれのポートフィルタを生成する工程と、
    前記検査署名と前記それぞれのポートフィルタとを前記受信ポートユニットの各々に送信する工程と、をさらに含む。
12. 請求項９のネットワークを検査する方法において、前記送信先署名の各々は、対応するポートグループを識別する第１部分と、前記ポートグループ内の特定のポートを有効にする第２部分と、を含む。
13. 請求項１２のネットワークを検査する方法において、
    前記複数のポートグループは、ユニキャストポートグループおよび相関ポートグループの一方または両方を含み、
    前記ユニキャストポートグループ内のポートは、ユニキャストパケットのみを受信し、
    相関ポートグループ内の各ポートは、１つ以上のマルチキャストグループの一部であり、前記１つ以上のマルチキャストグループの各々は、同一の相関ポートグループ内のポートのみを含む。
14. 請求項１２のネットワークを検査する方法において、
    前記送信先署名において必要とされる合計ビット数が所定の最大ビット数を超過した場合には、送信先違いパケット検出を無効にする工程をさらに含む。
15. トラフィック受信器であって、
    送信先違いパケット検出器を備え、前記送信先違いパケット検出器は、
    受信されたパケットが有効な検査署名を含むか否かを決定する第１コンパレータと、
    前記受信されたパケットが有効な検査署名を含む場合には、前記トラフィック受信器が前記受信されたパケットのための意図された送信先であるか否かを、前記受信されたパケットから抽出される送信先署名とポートフィルタとを比較して決定する、第２コンパレータと、
    前記受信されたパケットが有効な検査署名を含み、かつ前記トラフィック受信器が前記受信されたパケットのための意図された送信先である場合には、増加する、カウンタと、を含み、
    前記検査署名および前記送信先署名は、前記受信されたパケットのペイロード部分に含まれ、該ペイロード部分から抽出される。
16. 請求項１５のトラフィック受信器において、
    前記受信されたパケットが有効な検査署名を含み、かつ前記トラフィック受信器が前記受信されたパケットのための意図された送信先である場合には、前記受信されたパケットから検査データを抽出し、検査統計を蓄積する、統計アキュムレータをさらに備える。
17. 請求項１５のトラフィック受信器において、前記パケットから抽出された前記送信先署名が前記ポートフィルタと一致する場合には、前記トラフィック受信器が前記受信されたパケットのための意図された送信先であると決定する。
18. 請求項１５のトラフィック受信器において、前記第１コンパレータは、前記受信されたパケットと参照検査署名との間の浮動パターン一致を実行する。
19. プログラミングコードを格納する機械可読記憶媒体であって、プログラマブルロジックアレイをプログラムするために用いられる場合には前記プログラマブルロジックアレイがトラフィック受信器を備えるように構成し、前記トラフィック受信器は、送信先違いパケット検出器を備え、
    前記送信先違いパケット検出器は、
    受信されたパケットが有効な検査署名を含むか否かを決定する第１コンパレータと、
    前記受信されたパケットが有効な検査署名を含む場合には、前記トラフィック受信器が前記受信されたパケットのための意図された送信先であるか否かを、前記受信されたパケットから抽出される送信先署名とポートフィルタとを比較して決定する、第２コンパレータと、
    前記受信されたパケットが有効な検査署名を含み、かつ前記トラフィック受信器が前記受信されたパケットのための意図された送信先である場合には、増加する、カウンタと、を含み、
    前記検査署名および前記送信先署名は、前記受信されたパケットのペイロード部分に含まれ、該ペイロード部分から抽出される。
20. 請求項１９の機械可読記憶媒体において、前記トラフィック受信器は、
    前記受信されたパケットが有効な検査署名を含み、かつ前記トラフィック受信器が前記受信されたパケットのための意図された送信先である場合には、前記受信されたパケットから検査データを抽出し、検査統計を蓄積する、統計アキュムレータをさらに備える。
21. 請求項２０の機械可読記憶媒体において、前記パケットから抽出された前記送信先署名が前記ポートフィルタと一致する場合には、前記トラフィック受信器が前記受信されたパケットのための意図された送信先であると決定する。
22. 請求項１９の機械可読記憶媒体において、前記第１コンパレータは、前記受信されたパケットと参照検査署名との間の浮動パターン一致を実行する。
    
    

Images