JP5684680B2 - フロー統計集約 - Google Patents

Description

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

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

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

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

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

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

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

検査トラフィックは、複数の「トラフィックアイテム」に分けられてもよく、ここで、各トラフィックアイテムは、互いのトラフィックアイテムとは効果的に別の検査である。複数のトラフィックアイテムの一部または全てについての検査トラフィックは、同時に生成され、送信されてもよい。各トラフィックアイテムは複数のストリームを含んでもよく、各ストリームは、一般的に、単一のトラフィックアイテムの一部であってもよい。

検査データを収集する目的のために、各トラフィックアイテムについての検査トラフィックは、パケットグループとして編成されてもよく、ここで、「パケットグループ」は、ネットワークトラフィック統計が蓄積される、任意の複数のパケットである。所与のパッケトグループ内のパケットは、各パケット内に含まれるパケットグループ識別子（ＰＧＩＤ）によって識別され得る。ＰＧＩＤは、例えば、専用識別子フィールドまたは各パケット内の２つ以上のフィールドの組み合わせであってもよい。

ネットワークトラフィックデータを報告する目的のために、各トラフィックアイテムについての検査トラフィックが、フローとして編成されてもよく、ここで、「フロー」とは、ネットワークトラフィック統計を報告する任意の複数のパケットのことである。各フローは、単一のパケットグループまたは少数のパケットグループからなってもよい。各パケットグループは、一般に、単一のフローに属してもよい。

本文献の記述において、用語「エンジン」は、記述した機能を実行するハードウェアの集合体を意味し、これはファームウェアおよび／またはソフトウェアによって増強することができる。エンジンは、通常、主に機能的な用語を用いてエンジンを記述するハードウェア記述言語（ＨＤＬ）を用いて設計され得る。このようなＨＤＬ設計は、ＨＤＬシュミレーションツールを用いて検証され得る。次に、検証されるＨＤＬ設計は、一般に「合成」と呼ばれるプロセスにおいてゲートネットリストまたは他のエンジンの物理的な記述に変換され得る。この合成は、合成ツールを用いて自動的に行うことができる。ゲートネットリストまたは他の物理的な記述は、フィールドプログラマブルゲートアレー（ＦＰＧＡ）、プログラマブルロジックデバイス（ＰＬＤ）、またはプログラマブルロジックアレー（ＰＬＡ）のようなプログラマブルデバイスにおいてエンジンを実装するためにプログラミングコードにさらに変換され得る。ゲートネットリストまたは他の物理的な記述は、エンジンを特定用途向け集積回路（ＡＳＩＣ）内にて製造するためのプロセス命令およびマスクに変換され得る。

本文献の記述において、ハードウェア「ユニット」も、ファームウェアおよび／またはソフトウェアによって増強され得る、ハードウェアの集合体を意味し、これは「エンジン」よりも大規模であってもよい。例えば、ユニットには複数のエンジンを含んでいてもよく、これらの一部が並列に同様な機能を実行していてもよい。用語「エンジン」および「ユニット」は、いかなる物理的な分離または境界をも暗示していない。一または複数のユニットおよび／またはエンジンのすべてまたは一部を、ネットワークカード１１４のような共通のカード上に共に配置してもよく、共通のＦＰＧＡ、ＡＳＩＣ、または他の回路デバイス内に共に配置してもよい。

ネットワーク環境のブロック図である。 ポートユニットのブロック図である。 パケットを示す図である。 統計メモリのブロック図である。 図４Ａの統計メモリの動作を示すタイミング図である。 ネットワーク検査セッションを設計するためのプロセスのフローチャートである。 ＰＧＩＤを規定するためのプロセスの概略図である。 ネットワークを検査するためのプロセスのフローチャートである。 選択された検査データを表示するためのプロセスの第１の部分のフローチャートである。 選択された検査データを表示するためのプロセスの図である。 選択された検査データを表示するためのプロセスの第２の部分のフローチャートである。 検査データを選択し、表示するためのグラフィックユーザインターフェースの図である。

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

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

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

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

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

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

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

ネットワーク検査装置は、検査アドミニストレータ１０５と通信してもよい。検査アドミニストレータ１０５は、ネットワーク検査装置１００の内部に収容されるコンピューティングデバイスまたは外部のコンピューティングデバイスであってもよい。ネットワーク検査装置は、検査結果から検査命令を受信し、オペレータに通知するための動作インターフェース（図示せず）を備えてもよい。

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

ネットワークデバイス１９５は、ネットワーク１９０を通じて通信する能力のある任意のデバイスであってもよい。ネットワークデバイス１９５は、１つ以上のサーバ、ネットワーク対応の記憶装置（例えばネットワーク接続ストレージ（ＮＡＳ）およびストレージエリアネットワーク（ＳＡＮ）デバイス等のディスクドライブを含む）、ルータ、リレー、ハブ、スイッチ、ブリッジ、マルチプレクサおよび他のデバイスを備えてもよい。

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

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

ポートプロセッサ２３０は、検査アドミニストレータ２０５と通信してもよい。検査アドミニストレータ２０５は、ポートユニット２２０がネットワーク２９０の検査に関与するために必要とされる命令およびデータを、ポートプロセッサ２３０に提供してもよい。検査アドミニストレータ２０５から受信される命令およびデータは、例えば、ポートユニット２２０によって生成されるパケットストリームの定義、およびポートユニット２２０によって蓄積および報告され得る性能統計の定義を含んでもよい。検査アドミニストレータ２０５は、動作インターフェース２０７に接続または含まれてもよい。動作インターフェース２０７は、オペレータ（図示せず）から命令を受信し、要求し、およびオペレータに検査データを通知するために使用されてもよい。オペレータは、例えば検査データでのアクセスを必要とする検査エンジニアまたはシステムオペレータであってもよい。

ポートプロセッサ２３０は、トラフィックジェネレータユニット２４０内のストリームデータメモリ２４２に格納され得るストリームデータ２３２をトラフィックジェネレータユニット２４０に提供してもよい。ストリームデータ２３２は、発信検査トラフィック２４６を形成するためにインターリーブされ得る複数のストリームを、トラフィックジェネレータユニット２４０に形成させてもよい。複数のストリームは、単一のトラフィックアイテムまたは複数のトラフィックアイテムの部分であってもよい。ストリームの各々は、複数のパケットグループの間で分割され得る、一連のパケットを含んでもよい。ストリームデータ２３２は、例えば、パケットの種類、送信の周波数、パケット内部の固定内容フィールドおよび可変内容フィールドの定義、および各パケットストリームのための他の情報を含んでもよい。

トラフィックジェネレータユニット２４０は発信検査トラフィック２４６を生成するので、送信トラフィック統計は、送信トラフィック統計メモリ２４４に格納されてもよい。格納された送信トラフィック統計は、例えば、各ストリームのために生成されたパケットの数のカウントを含んでもよい。

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

トラフィック受信器２６０は、ネットワークインタフェース装置２８０から着信検査トラフィック２８２を受信してもよい。トラフィック受信器２６０は、統計エンジン２６２および統計メモリ２６４を含んでもよい。統計エンジン２６２は、各受信されたパケットを、特定のパケットグループのメンバーとして識別してもよく、各パケットから検査データを抽出してもよい。統計メモリ２６４は、各パケットグループのための蓄積されたトラフィック統計を格納するために使用されてもよい。各パケットグループのための格納された統計は、例えば、受信パケットの合計数、順番誤りで受信されたパケットの数、エラーを有する受信パケットの数、最大、平均および最小の待ち時間または伝搬遅延、ならびに各パケットグループのための他の統計を含んでもよい。各々の新しいパケットを受信した後、統計エンジン２６２は、関連付けられたパケットグループのための統計メモリ２６４に格納された検査統計を更新してもよい。

トラフィック受信器２６０はまた、ポートプロセッサ２３０によって提供される取得基準に従って、特定のパケットを取得および格納してもよい。トラフィック受信器２６０は、検査セッションの最中または後における更なる分析のために、検査統計および／または取得パケット２６６を、ポートプロセッサ２３０に提供してもよい。

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

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

本特許において、トラフィックを生成し、送信するポートユニットは、ソースポートユニットと称される。トラフィックを受信するポートユニットは、送信先ポートユニットと称される。ネットワーク検査に接続されるポートユニットは、ソースポートユニットおよび送信先ポートユニットの両方として機能してもよい。

ここで図３を参照し、代表的なパケット３００は、ヘッダ３１０とペイロード３２０とを含んでもよい。ヘッダ３１０は、順次的な通信プロトコルレイヤに対応する複数のカスケード式ヘッダを含んでもよい。例えば、ヘッダ３１０は、レイヤ２ヘッダ（例えば媒体アクセス制御ヘッダ）、レイヤ３ヘッダ（例えばインターネットプロトコルヘッダ）、およびレイヤ４ヘッダ（例えば伝送制御プロトコルヘッダまたはユーザデータグラムプロトコルヘッダ）を含んでもよい。例えば仮想ローカルエリアネットワーク上のトラフィックを表示するパケットなどの一部の場合において、１つ以上のカプセル化ヘッダは、レイヤ２ヘッドとレイヤ３ヘッダとの間に配置されてもよい。被検査ネットワークがマルチプロトコルラベルスイッチング（ＭＰＬＳ）である場合、１つ以上のＭＰＬＳラベルは、レイヤ２ヘッダとレイヤ３ヘッダとの間に配置されてもよい。それに加えて、例えば、ＭＰＬＳラベル、トンネリングプロトコルヘッダ、および／またはＩＰ．ｖ６拡張ヘッダを追加または削除することによって、ネットワーク経由の送信中に、パケット３００のヘッダ３１０が変更されてもよい。従って、ヘッダ３４６内の様々なフィールドを解析および解釈するために、相当な量の処理が必要となり得る。

パケット受信器が、受信されたパケットが検査セッションの一部であるか否かを決定することを可能にし、パケット受信器が、パケットのヘッダ部分を解析することなく、受信されたパケットから検査データを抽出することを可能にするために、パケット３００は、署名３２２、ＰＧＩＤ３２４および検査データ３２６を含んでもよい。検査データ３２６は、例えば、ＰＧＩＤおよび／またはタイムスタンプによって規定されたパケットグループ内のパケットのシーケンス番号を含んでもよい。署名３２２、ＰＧＩＤ３２４および検査データ３２６は、一般的にペイロード３４８内に配置されてもよい。米国特許出願公開第２００７／０１１５８３３Ａ１号明細書に記載されているように、トラフィック受信器は、検査署名の公知の数値に対する浮動比較またはパターン一致を実行することによって、受信されたパケット内に署名３２２を見つけてもよい。署名が見つけられると、トラフィック受信器は、署名３２２との関係におけるこれらのフィールドの公知の位置に基づいて、ＰＧＩＤ３２４および検査データ３２６を見つけ抽出してもよい。図３に示すように、ＰＧＩＤ３２４および検査データフィールド３２６は、署名３２２の直後にあってもよい。

一部の状況において、パケットが被検査ネットワークを介して送信される場合、ユーザは、パケットに対して成される変化を示す検査データを収集することを望む場合がある。特に、ネットワークは、少なくとも一部のパケットのヘッダ内のサービスの質（Ｑｏｓ）またはサービスのタイプ（ＴｏＳ）のフィールドを修正することができる。１つ以上のヘッダフィールドに対して成された変化を示すデータを含むトラフィック統計を維持するために、トラフィック受信器は、増強されたＰＧＩＤ３２８に基づいてトラフィック統計を収集し格納することができる。増強されたＰＧＩＤは、例えば、パケットペイロード３２０からのＰＧＩＤ３２４およびパケットヘッダからのＱｏＳフィールド３１２または他のフィールドの全てまたは一部を含んでもよい。米国特許第７，６４３，４３１号は、パケットの２つ以上のフィールドからＰＧＩＤを生成するための方法および装置を記載している。

ここで図４を参照し、ポートユニット２２０でもあり得る、ポートユニット４２０は、トラフィック受信器４６０およびポートプロセッサ４３０を含んでもよい。トラフィック受信器４６０は、ポートユニット４２０で受信された着信トラフィック上の統計を格納するための統計メモリ４６４を含んでもよい。統計メモリ４６４は、２つの別々にアクセス可能なメモリバンクＡ１、Ｂ１に分割されてもよい。ポートプロセッサ４３０は、２つのメモリバンクＡ２、Ｂ２を含み得るメモリ４３４を含んでもよい。

図４Ｂの例示的なタイミング図に示すように、メモリバンクＡ１、Ｂ１、Ａ２およびＢ２は、トラフィック統計のほぼ同時リアルタイム解析を可能にしながら、トラフィック統計が連続して蓄積することを可能にし得る。時間ｔ０から時間ｔ１まで、トラフィック統計４０１は、ポートユニット４２０内のメモリバンクＡ１に蓄積され得る。時間ｔ１において、メモリバンクＡ１はフリーズされてもよく、メモリバンクＢ１はトラフィック統計４０２を蓄積するためにアクティブにされてもよい。時間ｔ１直後に、蓄積されたトラフィック統計４０１の全てまたは一部は、メモリバンクＡ１からポートプロセッサ４３０内のメモリバンクＡ２までコピーされてもよい。次いで、ポートプロセッサ４３０は、蓄積されたトラフィック統計４０１を集約、分析、および／または報告してもよい。時間ｔ０は、例えば、検査セッションの開始であってもよい。

時間ｔ１から時間ｔ２まで、トラフィック統計４０２は、ポートユニット４２０内のメモリバンクＢ１に蓄積されてもよい。時間ｔ２において、メモリバンクＡ１およびＢ１の機能は逆転されてもよい。メモリバンクＢ１はフリーズされてもよく、メモリバンクＡ１はトラフィック統計４０３を蓄積するためにアクティブにされてもよい。トラフィック統計４０３は、メモリバンクＡ１内に残っているトラフィック統計４０１と共に蓄積されることに留意されたい。時間ｔ２の直後に、蓄積されたトラフィック統計４０２の全てまたは一部は、メモリバンクＢ１からポートプロセッサ４３０内のメモリバンクＢ２にコピーされてもよい。次いで、ポートプロセッサ４３０は、メモリバンクＡ２およびＢ２にそれぞれ格納されている蓄積されたトラフィック統計４０１および４０２を集約、分析、および／または報告してもよい。

時間ｔ２から時間ｔ３まで、トラフィック統計４０３は、ポートユニット４２０内のメモリバンクＡ１に蓄積されてもよい。時間ｔ３において、メモリバンクＡ１およびＢ１の機能は、再度、逆転されてもよい。メモリバンクＡ１はフリーズされてもよく、メモリバンクＢ１はトラフィック統計４０４を蓄積するためにアクティブにされてもよい。トラフィック統計４０４は、メモリバンクＢ１内に残っているトラフィック統計４０２と共に蓄積されることに留意されたい。時間ｔ３の直後に、蓄積されたトラフィック統計４０３の全てまたは一部は、メモリバンクＡ１からポートプロセッサ４３０内のメモリバンクＡ２にコピーされてもよい。次いで、ポートプロセッサ４３０は、メモリバンクＡ２内に格納されている蓄積されたトラフィック統計４０１および４０３、ならびにメモリバンクＢ２内に格納されている蓄積されたトラフィック統計４０２をそれぞれ集約、分析、および／または報告してもよい。

時間ｔ０、時間ｔ１、時間ｔ２、および時間ｔ３の間の時間間隔は所定の取得時間であってもよい。取得時間は、ポートユニット４２０に接続された検査アドミニストレータによって設定されてもよい。検査アドミニストレータは、メモリバンク間のデータの伝送ならびにポートプロセッサによって要求される集約、分析、および／または報告が取得時間内に完了され得ることを確保するように取得時間を設定してもよい。

時間ｔ０、時間ｔ１、時間ｔ２、および時間ｔ３の間の時間間隔は、検査データを見るためにオペレータの要求により決定されてもよい。例えば、時間ｔ０は検査セッションの開始であってもよく、時間ｔ１、ｔ２、およびｔ３はそれぞれ、特定の検査データを見るための第１、第２、および第３のオペレータの要求に関連付けられてもよい。

図４Ｂに示すように、メモリバンクＡ１またはＢ１のいずれかは、トラフィック統計を連続的に蓄積するためにトラフィック受信器４６０に交互に利用可能である。同時に、メモリバンクＡ１／Ｂ１が交換される最後の時間までに蓄積されたトラフィック統計の全ては、ポートプロセッサ４３０による分析のためにメモリバンクＡ２およびＢ２内で利用可能である。

統計メモリ４６４とポートプロセッサメモリ４３４とを２つのバンクに分割することは、トラフィック統計を蓄積し、報告するために必ずしも必要としない。例えば、統計メモリ４６４およびポートプロセッサメモリ４３４の各々が単一のバンクを有する場合、検査統計の集約および表示は、検査セッションが完了するまで単に遅延されてもよい。検査セッションの間に検査統計の分析および表示を可能にするために、検査セッションは、一時的にサスペンドされてもよいが、検査統計は、統計メモリ４６４からポートプロセッサメモリ４３４に伝送される。あるいは、検査トラフィックの蓄積は継続されてもよいが、検査トラフィックは、統計メモリ４６４からポートプロセッサメモリ４３４に伝送され、伝送された統計は単一の特定の瞬間を表さなくてもよいことは理解される。

［プロセスの説明］
ここで図５を参照し、ネットワーク検査セッションを設計するためのプロセス５００は、５０５において開始し、５９０において終了してもよい。説明を容易にするために、検査されるネットワークが、インターネットプロトコル（ＩＰ）およびＩＰアドレスを使用するという仮定がなされる。しかしながら、プロセス５００は、他のプロトコルおよびアドレススキームを使用するネットワークのための検査セッションを設計するように適用されてもよい。

プロセス５００は、例えば、ポートユニット２２０などの１つ以上のポートユニットに接続された検査アドミニストレータ２０５などの検査アドミニストレータコンピューティングデバイスによって行われてもよい。検査アドミニストレータコンピューティングデバイスは、プロセス５００の少なくとも一部を実行する自動ツールに入力を提供することができる１人以上の検査エンジニアまたは他のオペレータによって管理されてもよい。

ネットワーク検査セッションを設計するためのプロセス５００は、５１０において検査機器トポロジーを定義することによって開始できる。５１０における検査機器トポロジーを定義することは、多くの検査ポートが検査セッション内にどのように含まれ、各検査ポートがネットワークに接続される場所を決定する工程を含んでもよい。５１０における検査機器トポロジーを定義することはまた、各検査ポートが検査セッションの間にエミュレートすることを定義する工程を含んでもよい。各検査ポートは、最小で単一のＩＰアドレスおよび最大で大部分のＩＰアドレスを含むネットワーク全体をエミュレートしてもよい。さらに、５１０における検査機器トポロジーを定義することは、各検査ポートを、ボーダゲートウェイプロトコル（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）、エクステリアゲートウェイプロトコル（Ｅｘｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）、オープンショーテストパスファーストプロトコル（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ Ｐｒｏｔｏｃｏｌ）、リソースリザベーションプロトコル（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）および他のルーティングプロトコルなどの１つ以上のルーティングプロトコルを使用してネットワーク内のルータ、スイッチ、および他のデバイスに通知する制御パケットを定義する工程を含んでもよい。

５１５において検査セッションの間に生成される検査トラフィックが定義されてもよい。検査トラフィックは１つ以上のトラフィックアイテムを含んでもよい。各トラフィックアイテムは、効果的にネットワークの別の検査であってもよい。各トラフィックアイテムは、複数のストリームとして定義されてもよい。各ストリームは、ソースポート；送信の周波数；ストリーム内のパケットの固定フィールドおよび可変フィールド（例えば、パケットのプロトコルまたはタイプ、ソースおよび送信先ＩＰアドレス、サービスのタイプ、およびペイロードコンテンツ）；およびストリーム内の各パケットの他の特性などのストリームの属性を定義するストリームデータによって記載されてもよい。

複雑なネットワークの広範な検査は、１００万以上のフローを含む数千のストリームを含んでもよい。検査オペレータが、検査セッションの間に１００万のフローを評価または理解することは不可能であるため、検査統計を分類し、集約するために使用され得るトラッキングファクターまたはパラメータが、５２５〜５４０における各トラフィックアイテムのために定義されてもよい。トラッキングファクターは、ソースＩＰアドレス、送信先ＩＰアドレス、サービスのタイプ、プロトコルなどの各パケット内のフィールドおよび他のフィールドを含んでもよい。トラッキングファクターは、例えば、ソースポートユニットおよび送信先ポートユニットなどのパケット内に含まれないが、各パケットに関連付けられた情報を含んでもよい。

上記に説明したように、生成される各パケットは、パケットグループのメンバーとしてパケットを識別するためにＰＧＩＤを含んでもよく、トラフィック統計は、各ＰＧＩＤについて蓄積されてもよい。トラフィック統計が、定義されたトラッキングファクターに基づいて格納、集約、および報告されることを可能にするために、各ＰＧＩＤ値が、トラッキングファクターについての値の一意の組み合わせに対応してもよい。一部の状況において、ＰＧＩＤはまた、トラッキングファクターに関連付けられていない情報を含んでもよい。

トラッキングファクターをＰＧＩＤにマッピングするための理論的解釈および方法は、図５および図６に示した例を参照して理解され得る。図６の例において、ＩＰ．ｖ４パケット６００は、トラッキングファクターとして５２０において定義されている、サービスのタイプ（Ｔｏｓ）フィールド６０２、ソースＩＰアドレスフィールド６０４および送信先ＩＰアドレスフィールド６０６を含む。さらに、図６の例は、検査セッションが４つのトラフィックアイテムを含み、トラフィックアイテム識別子６２２がトラッキングファクターの１つであるように自動的に定義されることを仮定する。

５２５から５４０の動作は各トラッキングファクターについて繰り返されてもよい。５２５において、第１のトラッキングファクターが選択されてもよい。５３０において、検査セッションの間に実際に使用される選択されたトラッキングファクターの複数の値が識別されてもよい。複数の値は、例えば、５１５において定義されるストリームデータを検索することによって識別されてもよい。５３５において、複数の実数値が、選択されたトラッキングファクターに関連付けられたコードにマッピングまたは圧縮されてもよい。コードの長さは、トラッキングファクターについての複数の実数値の各々を識別するのに必要な最小数のビットであってもよい。

図６の例において、ＩＰｖ４パケットのＴｏｓフィールド６０２は８ビットの長さであるので、２５６の可能値を有する。しかしながら、検査セッションの間、Ｔｏｓフィールドについて２５６の全ての可能値より小さい数が使用されてもよい。Ｔｏｓフィールドについての値の数は、５１５において定義されたストリームデータの全てを分析することによって５３０において決定されてもよい。図６の例において、２５６個のうち８個のみの可能Ｔｏｓ値が、特定の検査アイテムのための検査トラフィックにおいて実際に使用されるという仮定がなされる。このように、実際に使用されるＴｏＳ値は、５３５において、３ビットのみを有するＴｏＳコード６２４にマッピングされてもよい。ＴｏＳフィールド６０２の８個の実際に使用される８ビットの値から３ビットＴｏＳコード６２４までのマッピングは、ＴｏＳマップ６１２を使用して行われてもよい。ＴｏＳマップ６１２は、対応するＴｏＳコード値と各々の実際のＴｏＳフィールド値に一意的に関連するルックアップテーブルまたは他のデータ構造であってもよい。

同様に、例示的なパケット６００のヘッダは、３２ビットのソースＩＰアドレスフィールド６０４および３２ビットの送信先ＩＰアドレスフィールド６０６を含み、各々は、約４３億の送信先ＩＰアドレスを定義する。しかしながら、検査セッションの間、少数のみのソースおよび送信先ＩＰアドレスが使用されてもよい。さらに、ＤＵＴに接続される検査ポートの少なくとも一部は個別アドレスよりむしろネットワークを表示することができるので、一部のＩＰアドレスのうちの最小桁の部分（例えば、最下位バイトまたは２つの最下位バイト）は、検査セッションの間、パケットグループを識別するために使用されなくてもよい。このように、検査セッションの間にトラックされ得るソースおよび送信先ＩＰアドレス値の数は、４３億より非常に小さくなってもよい。

（５３０において識別されるような）検査セッションの間にトラックされるソースおよび送信先ＩＰアドレス値は、それぞれのマップ６２４、６２６によってそれぞれのコード６２６、６２８に（５３５において）マッピングされてもよい。例えば、５００個のソースＩＰアドレス値は、ソースＩＰマップ６１４によって９ビットのソースＩＰコード６２４にマッピングされてもよい。さらなる例のために、２５０個の送信先ＩＰアドレス値は、送信先ＩＰマップ６１６によって８ビットの送信先ＩＰコード６２６にマッピングされてもよい。

選択されたトラッキングファクターの全てについての値が、（５２５〜５４０において）それぞれのコードにマッピングされる場合、そのコードは、グローバルフロー識別子（ＩＤ）を形成するために５４５において組み合わされてもよい。この文脈において、用語「グローバル」とは、どこでも使用されるか、または全てのポートユニットによって使用されることを意味する。図６の例を続けて、ＴｏＳコード６２４、ソースＩＰコード６２６、および送信先ＩＰコード６２８は、トラフィックアイテム識別子６２２と組み合わされてグローバルフローＩＤ６２０を形成してもよい。この例において、グローバルフローＩＤ６２２は、トラフィックアイテム識別子６２２について２ビット、Ｔｏｓコード６２４について３ビット、ソースＩＰコード６２６について９ビット、および送信先ＩＰコード６２８について８ビット、合計で２２ビットを含む。グローバルフローＩＤ６２０の各値は、選択されたトラッキングファクターについての値の一意の組み合わせに対応してもよい。より具体的には、グローバルフローＩＤ６２０についての各値は、特定のトラフィックアイテム、特定のＴｏＳ、特定のソースＩＰアドレス、および特定の送信先ＩＰアドレスに関連付けられてもよい。

図６の例を続けて、２２ビットのグローバルフローＩＤは、４００万以上のパケットグループを一意的に識別する能力を有する。理想的な状況において、例示的な検査セッションの間に使用される各送信先ポートユニットは、４００万以上の異なるパケットグループ上で検査統計を蓄積するために、（図４Ａに関して説明されるように２つのメモリバンクの各々において）メモリ容量を有する。この場合、２２ビットのグローバルフローＩＤは、単に検査セッションの間に生成される各パケットに挿入されてもよい。しかしながら、実際の検査環境において、各ポートユニットにおいてこのメモリ大容量を提供することは、実用的でないか、または負担しきれない。従って、受信ポートの各々に送信されるフローの数がポートの容量を超えないようにトラフィックが定義されてもよい。

５５０において、送信先ポートは、５１０において定義される複数の送信先ポートから選択されてもよい。５５５において、選択されたポートにおいて受信されるパケットのグローバルフローＩＤが識別されてもよい。５６０において、５５５において識別したグローバルフローＩＤが、ポート固有のＰＧＩＤマップによってＰＧＩＤのポート固有のセットにマッピングされてもよいか、または圧縮されてもよい。

例えば、選択された送信先ポートは、検査セッションの間に１００，０００個の異なるフローを受信してもよく、各々は一意の２２ビットのグローバルフローＩＤに関連付けられる。この場合、１００，０００個の２２ビットのフローＩＤは、選択された送信先ポートに送信されるパケットに排他的に使用するために１０，０００個の１７ビットのＰＧＩＤに一意にマッピングされてもよい。５５０から５６５までの動作は、対応するＰＧＩＤマップおよび対応するＰＧＩＤのセットを開発するために各送信先ポートに対して反復されてもよい。各ＰＧＩＤ値は、単一のグローバルフローＩＤ値に対応してもよい。各グローバルフローＩＤ値は、選択されたトラッキングファクターについての値の一意の組み合わせに対応するので、各ＰＧＩＤ値はまた、選択されたトラッキングファクターについての値の特定の組み合わせに関連付けられてもよい。

ＰＧＩＤマップおよびＰＧＩＤのセットは、各送信先ポートに関して異なってもよい。しかしながら、マルチキャストパケットは単一のＰＧＩＤ値のみを有してもよい。従って、マルチキャストパケットフローのグローバルフローＩＤは、マルチキャストパケットフローを受信する全ての送信先ポートのＰＧＩＤマップにおいて同じＰＧＩＤ値にマッピングされてもよい。

一部の状況において、５６０において、１つ以上のポートのための許容可能であるポート固有のＰＧＩＤマップを生成することはできない。例えば、送信先ポートが、５０，０００パケットグループについてのトラフィック統計を蓄積するためにメモリ容量のみを有する場合、１００，０００個のグローバルフローＩＤを１００，０００個の１７ビットのＰＧＩＤにマッピングすることは満たさない。このような状況において、プロセス５００は、検査機器トポロジーを変化させるため、トラフィックを再定義するため、または異なるトラッキングファクターを選択するために５１０、５１５または５２５に戻ってもよい。プロセス５００は、各送信先ポートのための許容可能なＰＧＩＤマップに到達することが必要な場合、反復的に繰り返してもよい。

図６の例において、２２ビットのグローバルフローＩＤ６２０のセットは、第１のポートＰＧＩＤマップ６３０−１によってＰＧＩＤ値の第１のセット６３２−１にマッピングされてもよい。ＰＧＩＤ値の第１のセット６３２から選択されたＰＧＩＤは、第１の送信先ポートにおいて受信された全てのパケットに組み込まれてもよい。同様に、２２ビットのグローバルフローＩＤ６２０のセットは、ｎ番目のポートＰＧＩＤマップ６３０−ｎによってＰＧＩＤ値のｎ番目のセット６３２−ｎにマッピングされてもよい。ＰＧＩＤ値のｎ番目のセット６３２−ｎから選択されたＰＧＩＤは、ｎ番目の送信先ポートにおいて受信された全てのパケットに組み込まれてもよい。

各送信先ポートに関して、許容可能なＰＧＩＤが（５５０〜５６５において）定義され得る場合、およびＰＧＩＤ値の対応するセットが（５５０〜５６５において）定義されている場合、５１５において少なくとも部分的に定義されるストリームデータは、適切なＰＧＩＤデータを各ストリーム定義に加えることによって５７０において完了されてもよい。５７５において、ストリームデータは、５１０において定義されるソースポートにダウンロードされてもよく、５５０〜５６５において生成されるＰＧＩＤマップは、対応する送信先ポートにダウンロードされてもよい。ストリームデータおよびマップがダウンロードされた後、検査セッションを設計するためのプロセス５００が５９０において終了してもよい。

ここで図７を参照し、ネットワークを検査するためのプロセス７００は、ポートユニット２００などの複数のポートユニットに接続された検査アドミニストレータ２０５などの検査アドミニストレータによって実行されてもよい。各ポートユニットは、トラフィックジェネレータ、トラフィック受信器、およびポートプロセッサを備えてもよい。各トラフィック受信器は、２つのメモリバンクを有し得る統計メモリ内にトラフィック統計を蓄積してもよい。存在する場合、各トラフィック受信器内の２つの統計メモリバンクは、図４Ａおよび図４Ｂに併せて記載されるようにトラフィック統計を交互に蓄積するために使用されてもよい。プロセス７００は、実際は周期的であってもよく、検査セッションの期間、連続して反復してもよい。

プロセス７００は、ポートユニットが、例えば、検査セッション設計プロセス５００における５７５などの検査セッション設計プロセスからストリームデータおよびＰＧＩＤマップを受信した後に開始してもよい。７１０において、検査セッションは、ポートユニットにより表示されたＩＰアドレスを被検査ネットワークに論理的に接続するために初期化されてもよい。検査セッションを初期化することは、ボーダゲートウェイプロトコル（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）、エクステリアゲートウェイプロトコル（Ｅｘｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）、オープンショーテストパスファーストプロトコル（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ Ｐｒｏｔｏｃｏｌ）、リソースリザベーションプロトコル（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）および他のルーティングプロトコルなどの１つ以上のルーティングプロトコルを使用してそれらの存在を被検査ネットワークに通知するポートユニットを含んでもよい。検査セッションを初期化することはまた、被検査ネットワークを用いてパラメータ、例えばＭＰＬＳラベルとの通信を取り決めるポートユニットを含んでもよい。

ポートユニットが７１０において被検査ネットワークに論理的に接続された後、検査トラフィックは、７１５において１つ以上のソースポートユニットによって生成され、７２０において１つ以上の送信先ポートユニットによって受信されてもよい。検査トラフィックは１つ以上のトラフィックアイテムを含んでもよい。各トラフィックアイテムは、複数のストリームを含んでもよく、各ストリームは多数のフローを含んでもよい。検査トラフィックは、７１５において複数のソースポートユニットによって同時に生成されてもよい。各ソースポートユニットによって生成される検査トラフィックは、複数のインターリーブストリームおよびフローを含んでもよい。７１５において、各ポートユニットはまた、各ストリームについて送信された少なくともいくらかのパケットを含む、送信トラフィック統計を蓄積してもよい。検査トラフィックは、７２０において複数の送信先ポートユニットによって同時に受信されてもよい。各送信先ポートユニットは、各受信されたパケットから抽出されるＰＧＩＤまたは増強されたＰＧＩＤによって識別されるパケットグループについての受信されたトラフィック統計を蓄積してもよい。ソースポートユニットおよび送信先ポートユニットは、全ての要求される検査トラフィックが送信されるという決定が７２５においてなされるまで、検査トラフィックを連続して生成し、受信することができる。

７３０において、オペレータは、ほぼリアルタイムの検査データを要求し、見ることができる。本特許文献において、用語「ほぼリアルタイム」とは、検査セッションの全期間に対して少しのプロセス遅延を除いて現在を意味する。ほぼリアルタイムの検査データは、例えば、数秒から数分の時間遅れてもよい。ほぼリアルタイムの検査データは、７３０において同時に、および／またはトラフィック統計が７１５および７２０において蓄積された後に報告または見られてもよい。７３０における動作は、少なくとも一部のトラフィク統計が７１５および７２０において蓄積されるまで、実行されなくてもよい。７３０における動作は、オペレータが特定の検査データを見るために要求を入力するまで、実行されなくてもよい。７３０において要求され、見られる検査データは、７１５において蓄積される送信トラフィック統計および／または７２０において収集される受信されたトラフィック統計を含んでもよい。

７３０において検査データを要求し、見ることは、実際は周期的であってもよい。７３０における動作は、オペレータが検査データを見るために新しい要求を入力するごとに反復されてもよい。７３０における動作は、定期的であってもよく、一定時間ごとに反復されてもよい。７３０が反復される時間間隔は、図４Ａおよび図４Ｂと併せて記載されるように、ポートユニット内のスイッチング統計メモリバンクと同期されてもよい。７３０における動作は、７３５において、さらなる検査データを見る必要がないという決定がなされるまで、周期的に反復されてもよい。プロセス７００は、さらなるトラフィックまたは検査データを見る必要がない場合、７９０において終えてもよい。

図８は、図７における動作７３０の一部としての使用に適切であり得る受信されたトラフィック統計を見るためのプロセス８３０のフローチャートを示す。プロセス８３０は、図９に示す例と併せて説明する。以下の説明において、８３０〜８５０の参照番号は図８に示され、９１０〜９４０の参照番号は図９に示される。

プロセス８３０は、検査アドミニストレータコンピューティングデバイスに接続され、次いで複数のポートユニットに接続される動作インターフェースによって実行されてもよい。このプロセス８３０は、８１５および８２０におけるトラフィック統計の蓄積と同時に行われてもよい。８２０において、蓄積されたトラフィック統計は、図４Ａおよび図４Ｂに併せて記載される交互に使用される２つのバンクを有する統計メモリに格納されてもよい。

８３２において、オペレータは、検査アドミニストレータコンピューティングデバイスに接続された動作インターフェースを介して特定のデータを見るために１つ以上の要求を入力してもよい。例えば、オペレータは、動作インターフェースのディスプレイデバイスに提示されたグラフィックユーザインターフェースを用いて要求を入力してもよい。各要求は、要求されたデータを集約し、編成するために使用される１つ以上のトラッキングファクターを識別できる。

８３２において入力された要求に応答して、検査アドミニストレータは、８３２において要求される受信されたトラフィック統計を提供するようにポートユニットを構成できる。検査アドミニストレータは、各ポートユニット構成データを送信することによってポートユニットを構成してもよい。構成データは、例えば、受信されたトラフィック統計が要求されることを示すフィルタマスク、受信されたトラフィック統計がどのように集約されるかを示す１つ以上の集約マスク、および他の情報を含んでもよい。

８３４において、検査アドミニストレータは、８３２において入力された要求を満たすために要求される特定の受信されたトラフィック統計を決定してもよい。検査アドミニストレータは、各送信先ポートユニットについての一意のフィルタマスクを生成してもよい。例えば、各フィルタマスクは、各ポート固有のＰＧＩＤに対応する単一のビットを有するビット列であってもよい。フィルタマスクの各ビットは、対応するＰＧＩＤのために蓄積される受信されたトラフィック統計が、８３２において入力された要求を満たすことを必要とされるか、されないかを示してもよい。８３４において、フィルタマスクは、それぞれの送信先ポートユニットに送信されてもよい。フィルタマスクは、十分な数のビット含んでもよい（１００，０００個のＰＧＩＤについての受信されたトラフィック統計を蓄積するポートユニットのためのフィルタマスクは１００，０００ビットを必要とし得る）。長いフィルタマスクは、例えば、検査アドミニストレータによって送信するために、ランレングス符号化によって圧縮され、続いて、それぞれの送信先ポートにおいて復元されてもよい。２つ以上の検査データビューが８３２において要求される場合、生成され、送信先ポートユニットに送信されるフィルタマスクは、組み合わせて要求される検査データビューの全てを必要とされる受信されたトラフィック統計を示してもよい。

８３６において、検査アドミニストレータは、各々の要求された検査データビューに対応する集約マスクを生成できる。１つ以上の集約マスクは、全ての送信先ポートユニットに共通であってもよい。集約マスクは、８３２において要求される受信されたトラフィック統計を集約し、表示するために使用されるグローバルフローＩＤフィールドを定義することができる。集約マスクはまた、８３６において送信先ポートユニットに送信されてもよい。

本特許文献において、用語「集約する」は、「全体に収集または組み合せること」の広範な意味を有する。集約トラフィック統計に含まれる正確な数学的演算は統計の性質に依存してもよい。例えば、多くの受信されたパケットは、各ＰＧＩＤのために蓄積されてもよい。複数のＰＧＩＤのための受信されたパケットの数を集約するために、複数のＰＧＩＤの各々のために受信されたパケットの数は、受信されたパケットの集約数を提供するように単に合計されてもよい。さらなる例のために、最大待ち時間が各ＰＧＩＤのために蓄積されてもよい。複数のＰＧＩＤのための最大待ち時間を集約するために、各ＰＧＩＤについての最大待ち時間は相互に比較されてもよく、単一の最も大きな値は、集約最大待ち時間として選択されてもよい。

８３８において、各ポートユニット内のポートプロセッサは、それぞれのフィルタマスクに従って、受信されたトラフィック統計を統計メモリから検索することができる。図９に示すように、各ポートユニットは、ＰＧＩＤセット９１０のための受信されたトラフィック統計を蓄積してもよい。フィルタマスク９２０は、対応するＰＧＩＤに関連付けられた受信されたトラフィック統計が、８３２において要求される検査データを提供するために必要とされるか否かを示す各ＰＧＩＤのための単一のビットを含んでもよい。ＰＧＩＤセット９１０は、フィルタ処理されたＰＧＩＤセット９２５を提供するためにフィルタマスク９２０によってフィルタ処理されてもよい。図８に戻って参照し、ポートプロセッサは、８３８においてフィルタ処理されたＰＧＩＤセットの各ＰＧＩＤに関連付けられた受信されたトラフィック統計を検索してもよい。

受信されたパケット内のＰＧＩＤ値は、トラッキングファクターについての値にＰＧＩＤの即座の相関関係を提供しない方法で割り当てられてもよい。８４０において、フィルタ処理されたＰＧＩＤセット９２５の各ＰＧＩＤは、フィルタ処理されたグローバルフローＩＤセット９３５にマッピングされてもよい。フィルタ処理されたＰＧＩＤセット９２５の各ＰＧＩＤは、図６に示すポート固有のＰＧＩＤマップ６３０−１、６３０−ｎなどのポート固有のＰＧＩＤマップ９３０を使用して対応するグローバルフローＩＤにマッピングされてもよい。各グローバルフローＩＤは、複数のトラッキングファクターに対応するフィールドまたはコードを含んでもよい。図６の例を継続して、フィルタ処理されたグローバルフローＩＤセット９３５の各グローバルフローＩＤは、例えば、トラフィックアイテム、ＴｏＳ／ＴＣ、ソースＩＰアドレス、および送信先ＩＰアドレスに対応する別のフィールドを含んでもよい。

８４２において、各ポートユニットは、８３６において検査アドミニストレータによって提供される集約マスクに従ってフィルタ処理されたグローバルフローＩＤに関連付けられた受信されたトラフィック統計を集約してもよい。集約マスクは、トラフィック統計を格納および報告するために使用されるフィルタ処理されたグローバルフローＩＤの１つ以上のフィールドを識別してもよい。例えば、図９に示す１番目の集約マスク９４０−１は、（暗い影をつけた）トラフィックアイテムフィールドを識別する。このマスクは、各ポートユニットに、トラフィックアイテムフィールドの値に従って、フィルタ処理されたグローバルフローＩＤに関連付けられた受信されたトラフィック統計を分類させてもよく、次いで、同じトラフィックアイテム値を有する全てのグローバルフローＩＤについての受信されたトラフィック統計を集約する。２番目および３番目の集約マスク９４０−２および９４０−３は、図１１の説明と併せて以下に説明する。

８４４において、集約された受信されたトラフィック統計は、各ポートユニットから検査アドミニストレータに更新されてもよい。上記の例に続けて、トラフィックアイテムフィールドの各値に対応する１セットの受信されたトラフィック統計は、各ポートユニットから検査アドミニストレータに更新されてもよい。８４６において、検査アドミニストレータは、各ポートユニットから受信される受信されたトラフィック統計を集約してもよい。

８５０において、検査アドミニストレータは、動作インターフェースを介して８４６から集約された受信されたトラフィック統計を表示してもよい。集約されたトラフィック統計は、動作インターフェース内のディスプレイデバイス上の検査データビューを介してオペレータに表示されてもよい。集約された受信されたトラフィック統計はまた、一部の他の方法でプリント、ネットワークを介して送信、格納、および／または報告されてもよい。

８４８において、検査アドミニストレータは、統計メモリバンクを交換する時期を決定するために、ポートユニットによって使用される取得期間を設定または更新してもよい。取得期間は、８３８から８４６において要求されるプロセス時間より単に長い時間に設定されてもよく、それによって、８５０において報告される検査データは、検査アドミニストレータおよびポートデバイスの制限内で可能な限り頻繁に更新されてもよい。

全プロセス８３０は、実質的に周期的であってもよい。８３８から８５０の動作は、ポートが統計メモリバンクを交換するごとに、または各取得期間に一度、反復されてもよい。８３２から８３６における動作は、新しい検査データビューが要求されるごとに反復されてもよい。

図１０は、図７における動作７３０の第２の部分としての使用に適切であり得る送信トラフィック統計を見るためのプロセス１０３０のフローチャートを示す。プロセス１０３０は、検査アドミニストレータコンピューティングデバイスに接続され、次いで複数のポートユニットに接続された動作インターフェースによって実行されてもよい。プロセス１０３０は、図８に示す８１５および８２０におけるトラフィック統計の蓄積と同時に、ならびに受信されたトラフィック統計を報告するためのプロセス８３０と同時に実行されてもよい。

１０３２において、オペレータは、検査アドミニストレータコンピューティングデバイスに接続された動作インターフェースを介して特定のデータを見るために１つ以上の要求を入力してもよい。例えば、オペレータは、動作インターフェースのディスプレイデバイス上に表示されるグラフィックユーザインターフェースを用いて要求を入力してもよい。各要求は、要求されたデータを集約し、編成するために使用される１つ以上のトラッキングファクターを識別できる。

１０３２において入力された要求に応答して、１０５４において、検査アドミニストレータは、例えば、送信ポートユニットによって、図７における７１５において蓄積された送信トラフィック統計を集約するための複数の集約グループを定義してもよい。「集約グループ」は、１０３２において要求される特定の検査データビューに応答して集約されるべきトラフィック統計のグループである。集約グループは、例えば、トラフィックアイテム、ＩＰソースおよび／または送信先アドレス、ソースおよび／または送信先ポートユニット、ソースおよび／または送信先ＴＣＰポート、サービスの質またはタイプ、他のファクター、およびファクターの組み合せによって定義されてもよい。検査データは、通常、表示、プリント、および他の場合には表形式で報告されてもよく、集約グループは、例えば、表の列に対応してもよい。表形式で検査データを表示し、報告することは、図１１と併せてさらに詳細に以下に説明する。

１０５４において、ストリームごとに送信されたパケット数を含む、送信トラフィック統計は、１つ以上のポートユニットから検査アドミニストレータコンピューティングデバイスに更新されてもよい。１０５６において、１０５４から送信されたパケット数は、集約グループの間で割り当てられてもよい。集約グループの間の送信されたパケット数の割り当ては、例えば、各ストリームにおけるパケットの一部が１０５２において定義される集約グループの各々に属することを決定するために、各ストリームについてのストリーム生成データを分析するソフトウェアアプリケーションを実行する検査アドミニストレータコンピューティングデバイスによって行われてもよい。

例えば、使用者は、各ソースポートユニットによって送信されたパケット数からなる検査データビューを要求することを仮定する。この場合、割り当てグループは、それぞれのポートユニットに対応し、１０５６において、所定のポートユニットから送信されるパケットの全ては、対応する集約グループに割り当てられる。

より現実的な例のために、使用者が、トラフィックアイテムによる検査統計からなる検査データビューを要求することを仮定する。この場合、１０５６において、そのストリームにおいて送信されたパケットの部分が、各集約グループに割り当てられるべきであるかを決定するために、全てのパケットストリームについてのストリーム形成データが分析される。例えば、１０５６において、所定のストリームについてのストリーム形成データの分析は、ストリームが、周期的に反復される１００パケットのシーケンスからなることを決定することができる。１０５６における分析はさらに、反復されたシーケンスにおける１００パケットが、５個の集約グループの間で均一に分割されることを決定することができる。この場合、ストリームについての送信されたパケットの総数が２０００パケットである場合、４００パケット数が５個の集約グループの各々に割り当てられる。送信されたパケット数の全てが集約グループの間で割り当てられるまで、分析および割り当てプロセスは、全てのパケットストリームについて同様に反復されてもよい。

１０５０において、検査アドミニストレータは、動作インターフェースを介して１０４６からの集約された送信トラフィック統計を表示できる。集約された送信トラフィック統計は、動作インターフェース内の、または動作インターフェースに接続されたディスプレイデバイス上の検査データビューを介してオペレータに表示されてもよい。集約された送信トラフィック統計はまた、プリント、ネットワークを介して送信、格納、および／または一部の他の方法で報告されてもよい。集約された送信トラフィック統計は、図８のプロセス８３０からの受信されたトラフィック統計と組み合わせて一部の他の方法で表示、プリント、送信、格納および／または報告されてもよい。

全プロセス１０３０は実質的に周期的であってもよい。１０３２から１０５０における動作は、周期的に、または新しい検査データビューが要求されるごとに反復されてもよい。

図１１は、オペレータに表示され得るか、または他の場合には報告され得る例示的な検査データビュー１１０１、１１０３、１１０５を示す。例示的な検査データビュー１１０１、１１０３、１１０５は、図８のプロセス８３０から集約された受信されたトラフィック統計と図１０のプロセス１０３０から集約された送信トラフィック統計とを組み合せる。例示的な検査データビューは、図６において最初に開始された例に基づく。表示を簡単にするために、１つのみの送信統計、送信されたパケット数、および２つの受信されたトラフィック統計、受信されたパケット数および順番誤りのパケット数を示す。現実世界の検査において、多数の他の受信されたトラフィック統計が蓄積され、表示されてもよい。受信されたトラフィック統計は、受信されたパケット数、順番誤りの受信されたパケット数、および失ったパケット数などの定量的データ；最小、最大、および／または平均待ち時間などの時間データ；ならびに他の情報を含んでもよい。受信されたトラフィック統計は、送信先ポートユニットにおいて蓄積されたデータ、および送信され、ソースポートユニットにおいて蓄積されたパケット数などのデータを含んでもよい。

第１の検査データビュー１１０１は、トラフィックアイテムに従って集約された送信トラフィック統計および受信トラフィック統計の両方を示す。第１の検査データビューは、図９の１番目の集約マスク９４０−１と一致してもよい。図６の例に沿って、トラフィックアイテムは４つのみの値を有する。４つのトラフィックアイテムおよび対応する集約されたトラフィック統計は、例えば、図１１に１１０１として示すように表形式で表示されてもよい。

第１の検査データビューは、検査セッションについての第１のレベルのデータの概要とみなされてもよい。第１のレベルの概要のビューは、選択された第１のトラッキングファクター（この例においてトラフィックアイテム）に従って集約された全てのパケットグループについての概要検査データを表示してもよい。例えば、ソースポート数または送信先ポート数などの別のトラッキングファクターは、第１のトラッキングファクターとして選択されてもよく、類似の第１のレベルの概要の検査データビューが生成されてもよい。

第１のレベルの検査データビューをレビューする際に、オペレータは、第１のトラッキングファクターについての１つの特定の値を選択してもよく、次いで、第２のトラッキングに従って集約される第２のレベルの検査データビューを要求してもよい。図１１の例において、オペレータは、第１のレベルの検査データビュー１１０１をレビューし、トラフィックアイテム０（影を付けて示す）を選択してもよい。次いで、可能な第２のトラッキングファクターのリスト１１０２が表示されてもよく、オペレータが第２のトラッキングファクターを選択してもよい。図１１の例において、オペレータは、第２のトラッキングファクターとしてソースＩＰアドレス（表１１０２に影を付けて示す）を選択するように仮定される。

ソースＩＰアドレスのオペレータ選択に応答して、第２のレベルの検査データビュー１１０３が生成されてもよい。例示的な第２のレベルの検査データビュー１１０３は、トラフィックアイテム０についての検査データのみを示してもよく、ソースＩＰアドレスによって分類および集約されるトラフィックアイテム０についての検査データを示してもよい。第２のレベルの検査データビュー１１０３は、トラフィックアイテム０に関連付けられていない全ての検査データを拒否するフィルタマスク９２０、およびフィルタ処理されたグローバルフローＩＤ９２５のソースＩＰアドレスフィールドに基づいてトラフィック統計を集約するようにポートユニットに指示する集約マスク９４０−２などの集約マスクを用いて生成されてもよい。

第２のレベルの検査データビューをレビューする際に、オペレータは、第２のトラッキングファクターについての１つの特定の値を選択してもよく、次いで第３のトラッキングファクターに従って集約された第３のレベルの検査データビューを要求してもよい。図１１の例において、オペレータは、第２のレベルの検査データビュー１１０２をレビューしてもよく、ソースＩＰアドレスｂｂｂ．ｂｂｂ．ｂｂｂ．ｂｂｂ（影を付けて示す）を選択してもよい。次いで、可能な第３のトラッキングファクターのリスト１１０４が表示されてもよく、オペレータが第３のトラッキングファクターを選択してもよい。図１１の例において、オペレータは、第３のトラッキングファクターとしてサービスのタイプ（表１１０４に影を付けて示したＴｏＳ）を選択するように仮定される。

ＴｏＳのオペレータ選択に応答して、第３のレベルの検査データビュー１１０５が生成されてもよい。例示的な第３のレベルの検査データビュー１００５は、トラフィックアイテム０およびＴｏｓによって分類し、集約されるソースＩＰアドレスｂｂｂ．ｂｂｂ．ｂｂｂ．ｂｂｂについての検査データのみを示してもよい。第３のレベルの検査データビュー１１０５は、トラフィックアイテム０およびソースＩＰアドレスｂｂｂ．ｂｂｂ．ｂｂｂ．ｂｂｂ、ならびにフィルタ処理されたグローバルフローＩＤ９２５のＴｏＳに基づいたトラフィック統計を集約するようにポートユニットに指示する、集約マスク９４０−３などの集約マスクに関連付けられていない全ての検査データを拒否するフィルタマスク９２０を用いて生成されてもよい。分類する１つ以上のさらなるレベルおよび集約は、所定のトラフィックアイテムに使用されるトラッキングファクターの数に応じて、利用可能であってもよい。

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

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

Claims (14)

1. ネットワークを検査する方法であって、
   複数のトラッキングファクターを識別する工程であって、各々の前記トラッキングファクターは複数の可能値を有する、工程と、
   複数のグローバルフロー識別子を生成する工程であって、前記複数のグローバルフロー識別子は、前記複数のトラッキングファクターについての値の全ての可能な組み合わせに対応する一意のグローバルフロー識別子を含む、工程と、
   各々の送信先ポートユニットにおいて受信される前記複数のグローバルフロー識別子のポート固有のサブセットを識別する工程と、
   各々の前記送信先ポートユニットに関するポート固有のパケットグループ識別子（ＰＧＩＤ）マップを生成して、前記グローバルフロー識別子のそれぞれのサブセットの各々と１つ以上の前記ＰＧＩＤとを関連付ける工程と、
   １つ以上のソースポートユニットが前記ネットワークを通じて複数のパケットを送信する工程であって、各々の前記パケットは、前記複数のグローバルフロー識別子の１つに対応するＰＧＩＤを含む、工程と、
   １つ以上の前記送信先ポートユニットが前記ネットワークを介して前記パケットを受信する工程であって、前記送信先ポートユニットは、
   各々の受信された前記パケットから前記パケットグループ識別子を抽出し、
   複数の前記ＰＧＩＤの各々に関するトラフィック統計を蓄積する、
   工程と、
   前記複数のトラッキングファクターから選択された第１のトラッキングファクターに基づいて集約されたトラフィック統計を生成するために、複数の前記ＰＧＩＤの少なくとも一部に関して蓄積された前記トラフィック統計を集約する工程と、
   を含む方法。
2. 前記複数のグローバルフロー識別子を生成する工程は、
   各々の前記トラッキングファクターに関して、それぞれの複数の前記値と対応するコードとを関連付けるためにマップを生成する工程であって、各々の前記トラッキングファクターに対応する前記コードの長さは、それぞれの複数の前記値の各々を一意に識別するのに十分な最小長さである、工程と、
   前記複数のトラッキングファクターについての前記値の各々の可能な組み合わせに対応する前記コードを連結させて、前記複数のグローバルフロー識別子を形成する工程と、
   をさらに含む、請求項１に記載の方法。
3. 蓄積された前記トラフィック統計を集約する工程は、
   各々の送信先ポートユニットが、
   フィルタマスクに従って複数のフィルタ処理されたＰＧＩＤを選択し、
   前記複数のフィルタ処理されたＰＧＩＤを、前記ポート固有のＰＧＩＤマップに基づいて対応する複数のフィルタ処理されたグローバルフロー識別子に変換し、
   前記フィルタ処理されたグローバルフロー識別子および前記第１のトラッキングファクターに基づいて前記フィルタ処理されたＰＧＩＤに関連付けられたトラフィック統計を集約すること
   をさらに含む、請求項１に記載の方法。
4. 蓄積された前記トラフィック統計を集約する工程は、
   各々の前記送信先ポートユニットが、集約された前記トラフィック統計を検査アドミニストレータコンピューティングデバイスに送信し、
   前記検査アドミニストレータコンピューティングデバイスが、前記送信先ポートユニットから受信された前記トラフィック統計を集約すること
   をさらに含む、請求項３に記載の方法。
5. 前記複数のパケットの各々は、複数のデータフィールドからなり、
   前記複数のトラッキングファクターは、トラフィックアイテム識別子ならびにソースポート識別子、送信先ポート識別子、および前記複数のデータフィールドからのフィールドのうちの１つ以上を含む、請求項１に記載の方法。
6. 前記トラッキングファクターは、ソースＩＰアドレス、送信先ＩＰアドレス、サービスのタイプ、およびプロトコルのうちの少なくとも１つを含む、請求項５に記載の方法。
7. 前記トラッキングファクターは、各々のトラフィックアイテムに関して異なる、請求項５に記載の方法。
8. 蓄積された前記トラフィック統計を集約する工程は、
   各々の前記ＰＧＩＤに関して、前記第１のトラッキングファクターについての対応する値を決定する工程と、
   前記第１のトラッキングファクターについての共通の値を有する前記ＰＧＩＤに関する前記トラフィック統計を集約する工程と、
   をさらに含む、請求項１に記載の方法。
9. 前記複数のトラッキングファクターから、前記第１のトラッキングファクターとは異なる別のトラッキングファクターである第２のトラッキングファクターを選択する工程と、
   前記第２のトラッキングファクターについての特定の値を選択する工程と、
   蓄積された前記トラフィック統計をフィルタ処理して、前記第２のトラッキングファクターについて選択された前記特定の値に関連付けられたＰＧＩＤのみを選択する工程と、
   選択された前記ＰＧＩＤの各々についてフィルタ処理された前記トラフィック統計を前記第１のトラッキングファクターに基づいて集約して、前記第１のトラッキングファクターに関する概要統計を生成する工程と、
   をさらに含む、請求項１に記載の方法。
10. ネットワークを通じて複数のパケットを送信するための少なくとも１つのソースポートユニットであって、各々の前記パケットはパケットグループ識別子（ＰＧＩＤ）を含む、少なくとも１つのソースポートユニットと、
    少なくとも１つの送信先ポートユニットであって、前記少なくとも１つの送信先ポートユニットは、
    前記ネットワークから前記パケットを受信するためのネットワークインターフェースユニットと、
    各々の受信された前記パケットからＰＧＩＤを抽出し、各々の前記ＰＧＩＤに関連付けられたトラフィック統計を蓄積するように構成される統計エンジンと、
    複数の前記ＰＧＩＤに関する蓄積された前記トラフィック統計を格納するための統計メモリと、
    前記統計メモリに接続されたポートプロセッサであって、前記ポートプロセッサは、
    フィルタマスクに従って、選択された複数の前記ＰＧＩＤに関連付けられたトラフィック統計を前記統計メモリから検索する工程と、
    選択された前記ＰＧＩＤを、ポート固有のＰＧＩＤマップに基づいて、対応する複数のグローバルフロー識別子に変換する工程と、
    集約マスクに従って、検索した前記トラフィック統計および複数のグローバルフロー識別子を集約する工程と、
    を含む動作を実行する、ポートプロセッサと、
    を含む、少なくとも１つの送信先ポートユニットと、
    を含む、ネットワークを検査するための装置。
11. １つ以上の前記送信先ポートユニットに接続された検査アドミニストレータコンピューティングデバイスをさらに含み、
    各々の前記送信先ポートユニットの前記ポートプロセッサによって実行される動作は、集約された前記トラフィック統計を前記検査アドミニストレータコンピューティングデバイスに送信する工程を含み、
    前記検査アドミニストレータコンピューティングデバイスは、１つ以上のポートユニットから受信された集約された前記トラフィック統計を集約する工程を含む動作を実行する、請求項１０に記載の装置。
12. 前記検査アドミニストレータコンピューティングデバイスによって実行される動作は、
    特定の検査データに関する要求を受信する工程と、
    前記要求に基づいて少なくとも１つのフィルタマスクおよび少なくとも１つの集約マスクを生成する工程と、
    をさらに含む、請求項１１に記載の装置。
13. 前記装置は複数のポートユニットを備え、
    前記検査アドミニストレータコンピューティングデバイスは各々の前記ポートユニットに関する一意のフィルタマスクを生成する、請求項１２に記載の装置。
14. 前記検査アドミニストレータコンピューティングデバイスは、異なる検査データに関する複数の要求を受信し、
    前記検査アドミニストレータコンピューティングデバイスは、各々の前記要求に関する一意の集約マスクを生成する、請求項１２に記載の装置。

Images