"ネットワークを検査する方法であって、複数のトラッキングファクターを識別する工程であって、各々の前記トラッキングファクターは複数の可能値を有する、工程と、1つ以上のソースポートユニットが前記ネットワークを通じて複数のパケットを送信する工程であって、各々の前記パケットは、前記複数のトラッキングファクターについての値の一意の組み合わせに対応するパケットグループ識別子PGIDを含む、工程と、1つ以上の送信先ポートユニットが前記ネットワークを介して前記パケットを受信する工程であって、前記送信先ポートユニットは、各々の受信された前記パケットから前記パケットグループ識別子を抽出し、複数の前記PGIDの各々に関するトラフィック統計を蓄積する、工程と、前記複数のトラッキングファクターから選択された第1のトラッキングファクターに基づいて集約されたトラフィック統計を生成するために、複数の前記PGIDの少なくとも一部に関して蓄積された前記トラフィック統計を集約する工程と、を含む方法。前記複数のパケットを送信する前に、複数のグローバルフロー識別子を生成する工程であって、前記複数のグローバルフロー識別子は、前記複数のトラッキングファクターについての値の全ての可能な組み合わせに対応する一意のグローバルフロー識別子を含む、工程をさらに含む、請求項1に記載の方法。前記複数のグローバルフロー識別子を生成する工程は、各々の前記トラッキングファクターに関して、それぞれの複数の前記値と対応するコードとを関連付けるためにマップを生成する工程であって、各々の前記トラッキングファクターに対応する前記コードの長さは、それぞれの複数の前記値の各々を一意に識別するのに十分な最小長さである、工程と、前記複数のトラッキングファクターについての前記値の各々の可能な組み合わせに対応する前記コードを連結させて、前記複数のグローバルフロー識別子を形成する工程と、をさらに含む、請求項2に記載の方法。各々の前記送信先ポートユニットにおいて受信される前記複数のグローバルフロー識別子のポート固有のサブセットを識別する工程と、各々の前記送信先ポートユニットに関するポート固有のPGIDマップを生成して、前記グローバルフロー識別子のそれぞれのサブセットの各々と1つ以上の前記PGIDとを関連付ける工程と、をさらに含む、請求項3に記載の方法。蓄積された前記トラフィック統計を集約する工程は、各々の送信先ポートユニットが、フィルタマスクに従って複数のフィルタ処理されたPGIDを選択する工程と、前記複数のフィルタ処理されたPGIDを、前記ポート固有のPGIDマップに基づいて対応する複数のフィルタ処理されたグローバルフロー識別子に変換する工程と、前記フィルタ処理されたグローバルフロー識別子および前記第1のトラッキングファクターに基づいて前記フィルタ処理されたPGIDに関連付けられたトラフィック統計を集約する工程と、をさらに含む、請求項4に記載の方法。蓄積された前記トラフィック統計を集約する工程は、各々の前記送信先ポートユニットが、集約された前記トラフィック統計を検査アドミニストレータコンピューティングデバイスに送信する工程と、前記検査アドミニストレータコンピューティングデバイスが、前記送信先ポートユニットから受信された前記トラフィック統計を集約する工程と、をさらに含む、請求項5に記載の方法。前記複数のパケットの各々は、複数のデータフィールドからなり、前記複数のトラッキングファクターは、トラフィックアイテム識別子ならびにソースポート識別子、送信先ポート識別子、および前記複数のデータフィールドからのフィールドのうちの1つ以上を含む、請求項1に記載の方法。前記トラッキングファクターは、ソースIPアドレス、送信先IPアドレス、サービスのタイプ、およびプロトコルのうちの少なくとも1つを含む、請求項7に記載の方法。前記トラッキングファクターは、各々のトラフィックアイテムに関して異なる、請求項7に記載の方法。蓄積された前記トラフィック統計を集約する工程は、各々の前記PGIDに関して、前記第1のトラッキングファクターについての対応する値を決定する工程と、前記第1のトラッキングファクターについての共通の値を有する前記PGIDに関する前記トラフィック統計を集約する工程と、をさらに含む、請求項1に記載の方法。前記複数のトラッキングファクターから第2のトラッキングファクターを選択する工程と、前記第2のトラッキングファクターについての特定の値を選択する工程と、蓄積された前記トラフィック統計をフィルタ処理して、前記第2のトラッキングファクターについて選択された前記特定の値に関連付けられたPGIDのみを選択する工程と、選択された前記PGIDの各々についてフィルタ処理された前記トラフィック統計を集約して、前記第1のトラッキングファクターに関する概要統計を生成する工程と、をさらに含む、請求項1に記載の方法。ネットワークを通じて複数のパケットを送信するための少なくとも1つのソースポートユニットであって、各々の前記パケットはパケットグループ識別子PGIDを含む、少なくとも1つのソースポートユニットと、少なくとも1つの送信先ポートユニットであって、前記少なくとも1つの送信先ポートユニットは、前記ネットワークから前記パケットを受信するためのネットワークインターフェースユニットと、各々の受信された前記パケットからPGIDを抽出し、各々の前記PGIDに関連付けられたトラフィック統計を蓄積するように構成される統計エンジンと、複数の前記PGIDに関する蓄積された前記トラフィック統計を格納するための統計メモリと、前記統計メモリに接続されたポートプロセッサであって、前記ポートプロセッサは、フィルタマスクに従って、選択された複数の前記PGIDに関連付けられたトラフィック統計を前記統計メモリから検索する工程と、集約マスクに従って、検索した前記トラフィック統計を集約する工程と、を含む動作を実行する、ポートプロセッサと、を含む、少なくとも1つの送信先ポートユニットと、を含む、ネットワークを検査するための装置。検索した前記トラフィック統計を集約する工程は、選択された前記PGIDを、ポート固有のPGIDマップに基づいた対応する複数のグローバルフロー識別子に変換する工程と、前記集約マスクおよび複数の前記グローバルフロー識別子に従って、検索した前記トラフィック統計を集約する工程と、をさらに含む、請求項12に記載の装置。1つ以上の前記送信先ポートユニットに接続された検査アドミニストレータコンピューティングデバイスをさらに含み、各々の前記送信先ポートユニットの前記ポートプロセッサによって実行される動作は、集約された前記トラフィック統計を前記検査アドミニストレータに送信する工程を含み、前記検査アドミニストレータは、1つ以上の前記ポートユニットから受信された集約された前記トラフィック統計を集約する工程を含む動作を実行する、請求項12に記載の装置。前記検査アドミニストレータによって実行される動作は、特定の検査データに関する要求を受信する工程と、前記要求に基づいて少なくとも1つのフィルタマスクおよび少なくとも1つの集約マスクを生成する工程と、をさらに含む、請求項14に記載の装置。前記装置は複数のポートユニットを備え、前記検査アドミニストレータは各々の前記ポートユニットに関する一意のフィルタマスクを生成する、請求項15に記載の装置。前記検査アドミニストレータは、異なる検査データに関する複数の要求を受信し、前記検査アドミニストレータは、各々の前記要求に関する一意の集約マスクを生成する、請求項15に記載の装置。[装置の説明]図1は、ネットワーク環境のブロック図を示す。その環境は、ネットワーク検査装置100、および複数のネットワークデバイス195を備えることができるネットワーク190を含んでもよい。ネットワーク検査装置100は、ネットワーク検査機器、性能アナライザ、適合性検証システム、ネットワークアナライザ、またはネットワーク管理システムとすることができる。ネットワーク検査装置100は、シャーシ110内に収容または格納される1つ以上のネットワークカード114およびバックプレーン112を備えてもよい。シャーシ110は、ネットワーク検査装置を収容するために適切な固定式または可搬式のシャーシ、キャビネットまたは筐体であってもよい。図1に示すように、ネットワーク検査装置100は、統合されたユニットであってもよい。それに代わって、ネットワーク検査装置100は、トラフィックの発生および/または分析を提供するように協調する多数の個別のユニットを備えてもよい。ネットワーク検査装置100およびネットワークカード114は、1つ以上の周知の標準規格またはプロトコル例えばイーサネット登録商標およびファイバチャネルなどの様々な標準規格をサポートしてもよく、商標つきのプロトコルをサポートしてもよい。ネットワークカード114は、1つ以上のフィールドプログラマブルゲートアレーFPGA、特定用途向け集積回路ASIC、プログラマブルロジックデバイスPLD、プログラマブルロジックアレイPLA、プロセッサおよび他の種類のデバイスを含むことができる。それに加えて、ネットワークカード114は、ソフトウェアおよび/またはファームウェアを含んでもよい。用語ネットワークカードは、ラインカード、検査カード、分析カード、ネットワークラインカード、ロードモジュール、インタフェースカード、ネットワークインタフェースカード、データインタフェースカード、パケットエンジンカード、サービスカード、スマートカード、スイッチカード、リレーアクセスカード等を含む。用語ネットワークカードはまた、多数のプリント回路基板を備え得るモジュール、ユニットおよび組立部品をも含む。各ネットワークカード114は、単一の通信プロトコルをサポートしてもよく、多数の関連するプロトコルをサポートしてもよく、または多数の無関係なプロトコルをサポートしてもよい。ネットワークカード114は、ネットワーク検査装置100に恒久的に設置されていてもよく、着脱自在であってもよい。各ネットワークカード114は、1つ以上のポートユニット120を収容してもよい。1つのポートユニットまたは複数のポートユニットは、それぞれのポートを介してネットワーク190に接続されてもよい。各ポートは、それぞれの通信媒体185を介してネットワークに接続されてもよく、通信媒体は、ワイヤ、光ファイバ、無線リンク、または他の通信媒体であってもよい。ネットワークを複数のポートに接続する通信媒体は、同じものであってもよく、異なるものであってもよい。各ポートユニット120は、検査トラフィックを生成してネットワークに送信してもよく、各ポートユニット120は、ネットワークから検査トラフィックを受信してもよい。ポートユニット120の1つによって送信されるパケットは、1つ以上の他のポートユニットによって共通に受信されてもよい。バックプレーン112は、ネットワークカード114のためのバスまたは通信媒体としての役割を果たしてもよい。バックプレーン112はまた、ネットワークカード114に電力を供給してもよい。ネットワーク検査装置は、検査アドミニストレータ105と通信してもよい。検査アドミニストレータ105は、ネットワーク検査装置100の内部に収容されるコンピューティングデバイスまたは外部のコンピューティングデバイスであってもよい。ネットワーク検査装置は、検査結果から検査命令を受信し、オペレータに通知するための動作インターフェース図示せずを備えてもよい。ネットワーク190は、ローカルエリアネットワークLAN、ワイドエリアネットワークWAN、ストレージエリアネットワークSAN、有線、無線、またはこれらの組み合わせであってもよく、インターネットを含んでもよく、またはインターネットであってもよい。ネットワーク190上の通信は、情報のフレーム、セル、データグラム、パケットまたは他の単位を含む様々な形態をとってもよく、本文献においては、それらの全てをパケットと称する。ネットワーク検査装置100およびネットワークデバイス195は、同時に相互に通信してもよく、ネットワーク検査装置100と所与のネットワークデバイス195との間には、複数の論理的通信経路があってもよい。ネットワークそのものは、伝えるデータのための多数の物理的経路および論理的経路を提供する多数のノードから成ってもよい。ネットワークデバイス195は、ネットワーク190を通じて通信する能力のある任意のデバイスであってもよい。ネットワークデバイス195は、1つ以上のサーバ、ネットワーク対応の記憶装置例えばネットワーク接続ストレージNASおよびストレージエリアネットワークSANデバイス等のディスクドライブを含む、ルータ、リレー、ハブ、スイッチ、ブリッジ、マルチプレクサおよび他のデバイスを備えてもよい。ここで図2を参照し、例示的なポートユニット220は、ポートプロセッサ230と、トラフィックジェネレータユニット240と、トラフィック受信器260と、ポートユニット220を被検査ネットワーク290に接続するネットワークインタフェース装置280とを備えてもよい。ポートユニット220は、ネットワークカード例えばネットワークカード114のすべてまたは一部であってもよい。ポートプロセッサ230は、本文献に記載される機能および特徴を提供するための、プロセッサ、プロセッサに接続されたメモリ、および様々な特殊化された装置、回路、ソフトウェアおよびインタフェースを含んでもよい。プロセス、機能および特徴は、全体的にあるいは部分的に、プロセッサ上で動作するソフトウェアにおいて実現されてもよく、ファームウェア、アプリケーションプログラム、アプレット例えばJava登録商標アプレット、ブラウザプラグイン、COMオブジェクト、ダイナミックリンクライブラリDLL、スクリプト、1つ以上のサブルーチン、またはオペレーティングシステムのコンポーネントまたはサービスという形をとってもよい。ハードウェアおよびソフトウェアおよびそれらの機能は、一部の機能がプロセッサによって実行され、他の機能が他の装置によって実行されるように、分散型であってもよい。ポートプロセッサ230は、検査アドミニストレータ205と通信してもよい。検査アドミニストレータ205は、ポートユニット220がネットワーク290の検査に関与するために必要とされる命令およびデータを、ポートプロセッサ230に提供してもよい。検査アドミニストレータ205から受信される命令およびデータは、例えば、ポートユニット220によって生成されるパケットストリームの定義、およびポートユニット220によって蓄積および報告され得る性能統計の定義を含んでもよい。検査アドミニストレータ205は、動作インターフェース207に接続または含まれてもよい。動作インターフェース207は、オペレータ図示せずから命令を受信し、要求し、およびオペレータに検査データを通知するために使用されてもよい。オペレータは、例えば検査データでのアクセスを必要とする検査エンジニアまたはシステムオペレータであってもよい。ポートプロセッサ230は、トラフィックジェネレータユニット240内のストリームデータメモリ242に格納され得るストリームデータ232をトラフィックジェネレータユニット240に提供してもよい。ストリームデータ232は、発信検査トラフィック246を形成するためにインターリーブされ得る複数のストリームを、トラフィックジェネレータユニット240に形成させてもよい。複数のストリームは、単一のトラフィックアイテムまたは複数のトラフィックアイテムの部分であってもよい。ストリームの各々は、複数のパケットグループの間で分割され得る、一連のパケットを含んでもよい。ストリームデータ232は、例えば、パケットの種類、送信の周波数、パケット内部の固定内容フィールドおよび可変内容フィールドの定義、および各パケットストリームのための他の情報を含んでもよい。トラフィックジェネレータユニット240は発信検査トラフィック246を生成するので、送信トラフィック統計は、送信トラフィック統計メモリ244に格納されてもよい。格納された送信トラフィック統計は、例えば、各ストリームのために生成されたパケットの数のカウントを含んでもよい。ネットワークインタフェース装置280は、トラフィックジェネレータユニット240からの発信検査トラフィック246を、リンク285を介して被検査ネットワーク290に検査トラフィック送信するために必要な電気信号、光学信号または無線信号の形式に変換してもよく、リンクは、ワイヤ、光ファイバ、無線リンクまたは他の通信リンクであってもよい。同様に、ネットワークインタフェース装置280は、ネットワークからリンク285を通じて電気信号、光学信号または無線信号を受信してもよく、受信した信号を、トラフィック受信器260において使用可能な形式の着信検査トラフィック282に変換してもよい。トラフィック受信器260は、ネットワークインタフェース装置280から着信検査トラフィック282を受信してもよい。トラフィック受信器260は、統計エンジン262および統計メモリ264を含んでもよい。統計エンジン262は、各受信されたパケットを、特定のパケットグループのメンバーとして識別してもよく、各パケットから検査データを抽出してもよい。統計メモリ264は、各パケットグループのための蓄積されたトラフィック統計を格納するために使用されてもよい。各パケットグループのための格納された統計は、例えば、受信パケットの合計数、順番誤りで受信されたパケットの数、エラーを有する受信パケットの数、最大、平均および最小の待ち時間または伝搬遅延、ならびに各パケットグループのための他の統計を含んでもよい。各々の新しいパケットを受信した後、統計エンジン262は、関連付けられたパケットグループのための統計メモリ264に格納された検査統計を更新してもよい。トラフィック受信器260はまた、ポートプロセッサ230によって提供される取得基準に従って、特定のパケットを取得および格納してもよい。トラフィック受信器260は、検査セッションの最中または後における更なる分析のために、検査統計および/または取得パケット266を、ポートプロセッサ230に提供してもよい。発信検査トラフィック246および着信検査トラフィック282は、主にステートレスであってもよい。すなわち、発信検査トラフィック246は、応答を予期することなく生成されてもよく、着信検査トラフィック282は、応答を予期することなく、または応答を意図することなく受信されてもよい。しかしながら、検査セッション中に、ポートユニット220とネットワーク290との間で、若干量のステートフルのまたは対話型の通信が要求されるかまたは望ましい場合がある。例えば、トラフィック受信器260は、制御パケットを受信してもよい。制御パケットは、検査セッションを制御するために必要なデータを含むパケットであり、ポートユニットに受信通知または応答の送信を要求する。トラフィック受信器260は、着信制御パケット236を着信検査トラフィックから分離してもよく、着信制御パケット236をポートプロセッサ230にルーティングしてもよい。ポートプロセッサ230は、各制御パケットのコンテンツを抽出してもよく、1つ以上の発信制御パケット238の形で適切な応答を生成してもよい。発信制御パケット238は、トラフィックジェネレータユニット240に提供されてもよい。トラフィックジェネレータユニット240は、発信制御パケットを発信検査トラフィック246の中に挿入してもよい。本特許において、トラフィックを生成し、送信するポートユニットは、ソースポートユニットと称される。トラフィックを受信するポートユニットは、送信先ポートユニットと称される。ネットワーク検査に接続されるポートユニットは、ソースポートユニットおよび送信先ポートユニットの両方として機能してもよい。ここで図3を参照し、代表的なパケット300は、ヘッダ310とペイロード320とを含んでもよい。ヘッダ310は、順次的な通信プロトコルレイヤに対応する複数のカスケード式ヘッダを含んでもよい。例えば、ヘッダ310は、レイヤ2ヘッダ例えば媒体アクセス制御ヘッダ、レイヤ3ヘッダ例えばインターネットプロトコルヘッダ、およびレイヤ4ヘッダ例えば伝送制御プロトコルヘッダまたはユーザデータグラムプロトコルヘッダを含んでもよい。例えば仮想ローカルエリアネットワーク上のトラフィックを表示するパケットなどの一部の場合において、1つ以上のカプセル化ヘッダは、レイヤ2ヘッドとレイヤ3ヘッダとの間に配置されてもよい。被検査ネットワークがマルチプロトコルラベルスイッチングMPLSである場合、1つ以上のMPLSラベルは、レイヤ2ヘッダとレイヤ3ヘッダとの間に配置されてもよい。それに加えて、例えば、MPLSラベル、トンネリングプロトコルヘッダ、および/またはIP.v6拡張ヘッダを追加または削除することによって、ネットワーク経由の送信中に、パケット300のヘッダ310が変更されてもよい。従って、ヘッダ346内の様々なフィールドを解析および解釈するために、相当な量の処理が必要となり得る。パケット受信器が、受信されたパケットが検査セッションの一部であるか否かを決定することを可能にし、パケット受信器が、パケットのヘッダ部分を解析することなく、受信されたパケットから検査データを抽出することを可能にするために、パケット300は、署名322、PGID324および検査データ326を含んでもよい。検査データ326は、例えば、PGIDおよび/またはタイムスタンプによって規定されたパケットグループ内のパケットのシーケンス番号を含んでもよい。署名322、PGID324および検査データ326は、一般的にペイロード348内に配置されてもよい。米国特許出願公開第2007/0115833A1号明細書に記載されているように、トラフィック受信器は、検査署名の公知の数値に対する浮動比較またはパターン一致を実行することによって、受信されたパケット内に署名322を見つけてもよい。署名が見つけられると、トラフィック受信器は、署名322との関係におけるこれらのフィールドの公知の位置に基づいて、PGID324および検査データ326を見つけ抽出してもよい。図3に示すように、PGID324および検査データフィールド326は、署名322の直後にあってもよい。一部の状況において、パケットが被検査ネットワークを介して送信される場合、ユーザは、パケットに対して成される変化を示す検査データを収集することを望む場合がある。特に、ネットワークは、少なくとも一部のパケットのヘッダ内のサービスの質QosまたはサービスのタイプToSのフィールドを修正することができる。1つ以上のヘッダフィールドに対して成された変化を示すデータを含むトラフィック統計を維持するために、トラフィック受信器は、増強されたPGID328に基づいてトラフィック統計を収集し格納することができる。増強されたPGIDは、例えば、パケットペイロード320からのPGID324およびパケットヘッダからのQoSフィールド312または他のフィールドの全てまたは一部を含んでもよい。米国特許第7,643,431号は、パケットの2つ以上のフィールドからPGIDを生成するための方法および装置を記載している。ここで図4を参照し、ポートユニット220でもあり得る、ポートユニット420は、トラフィック受信器460およびポートプロセッサ430を含んでもよい。トラフィック受信器460は、ポートユニット420で受信された着信トラフィック上の統計を格納するための統計メモリ464を含んでもよい。統計メモリ464は、2つの別々にアクセス可能なメモリバンクA1、B1に分割されてもよい。ポートプロセッサ430は、2つのメモリバンクA2、B2を含み得るメモリ434を含んでもよい。図4Bの例示的なタイミング図に示すように、メモリバンクA1、B1、A2およびB2は、トラフィック統計のほぼ同時リアルタイム解析を可能にしながら、トラフィック統計が連続して蓄積することを可能にし得る。時間t0から時間t1まで、トラフィック統計401は、ポートユニット420内のメモリバンクA1に蓄積され得る。時間t1において、メモリバンクA1はフリーズされてもよく、メモリバンクB1はトラフィック統計402を蓄積するためにアクティブにされてもよい。時間t1直後に、蓄積されたトラフィック統計401の全てまたは一部は、メモリバンクA1からポートプロセッサ430内のメモリバンクA2までコピーされてもよい。次いで、ポートプロセッサ430は、蓄積されたトラフィック統計401を集約、分析、および/または報告してもよい。時間t0は、例えば、検査セッションの開始であってもよい。時間t1から時間t2まで、トラフィック統計402は、ポートユニット420内のメモリバンクB1に蓄積されてもよい。時間t2において、メモリバンクA1およびB1の機能は逆転されてもよい。メモリバンクB1はフリーズされてもよく、メモリバンクA1はトラフィック統計403を蓄積するためにアクティブにされてもよい。トラフィック統計403は、メモリバンクA1内に残っているトラフィック統計401と共に蓄積されることに留意されたい。時間t2の直後に、蓄積されたトラフィック統計402の全てまたは一部は、メモリバンクB1からポートプロセッサ430内のメモリバンクB2にコピーされてもよい。次いで、ポートプロセッサ430は、メモリバンクA2およびB2にそれぞれ格納されている蓄積されたトラフィック統計401および402を集約、分析、および/または報告してもよい。時間t2から時間t3まで、トラフィック統計403は、ポートユニット420内のメモリバンクA1に蓄積されてもよい。時間t3において、メモリバンクA1およびB1の機能は、再度、逆転されてもよい。メモリバンクA1はフリーズされてもよく、メモリバンクB1はトラフィック統計404を蓄積するためにアクティブにされてもよい。トラフィック統計404は、メモリバンクB1内に残っているトラフィック統計402と共に蓄積されることに留意されたい。時間t3の直後に、蓄積されたトラフィック統計403の全てまたは一部は、メモリバンクA1からポートプロセッサ430内のメモリバンクA2にコピーされてもよい。次いで、ポートプロセッサ430は、メモリバンクA2内に格納されている蓄積されたトラフィック統計401および403、ならびにメモリバンクB2内に格納されている蓄積されたトラフィック統計402をそれぞれ集約、分析、および/または報告してもよい。時間t0、時間t1、時間t2、および時間t3の間の時間間隔は所定の取得時間であってもよい。取得時間は、ポートユニット420に接続された検査アドミニストレータによって設定されてもよい。検査アドミニストレータは、メモリバンク間のデータの伝送ならびにポートプロセッサによって要求される集約、分析、および/または報告が取得時間内に完了され得ることを確保するように取得時間を設定してもよい。時間t0、時間t1、時間t2、および時間t3の間の時間間隔は、検査データを見るためにオペレータの要求により決定されてもよい。例えば、時間t0は検査セッションの開始であってもよく、時間t1、t2、およびt3はそれぞれ、特定の検査データを見るための第1、第2、および第3のオペレータの要求に関連付けられてもよい。図4Bに示すように、メモリバンクA1またはB1のいずれかは、トラフィック統計を連続的に蓄積するためにトラフィック受信器460に交互に利用可能である。同時に、メモリバンクA1/B1が交換される最後の時間までに蓄積されたトラフィック統計の全ては、ポートプロセッサ430による分析のためにメモリバンクA2およびB2内で利用可能である。統計メモリ464とポートプロセッサメモリ434とを2つのバンクに分割することは、トラフィック統計を蓄積し、報告するために必ずしも必要としない。例えば、統計メモリ464およびポートプロセッサメモリ434の各々が単一のバンクを有する場合、検査統計の集約および表示は、検査セッションが完了するまで単に遅延されてもよい。検査セッションの間に検査統計の分析および表示を可能にするために、検査セッションは、一時的にサスペンドされてもよいが、検査統計は、統計メモリ464からポートプロセッサメモリ434に伝送される。あるいは、検査トラフィックの蓄積は継続されてもよいが、検査トラフィックは、統計メモリ464からポートプロセッサメモリ434に伝送され、伝送された統計は単一の特定の瞬間を表さなくてもよいことは理解される。[プロセスの説明]ここで図5を参照し、ネットワーク検査セッションを設計するためのプロセス500は、505において開始し、590において終了してもよい。説明を容易にするために、検査されるネットワークが、インターネットプロトコルIPおよびIPアドレスを使用するという仮定がなされる。しかしながら、プロセス500は、他のプロトコルおよびアドレススキームを使用するネットワークのための検査セッションを設計するように適用されてもよい。プロセス500は、例えば、ポートユニット220などの1つ以上のポートユニットに接続された検査アドミニストレータ205などの検査アドミニストレータコンピューティングデバイスによって行われてもよい。検査アドミニストレータコンピューティングデバイスは、プロセス500の少なくとも一部を実行する自動ツールに入力を提供することができる1人以上の検査エンジニアまたは他のオペレータによって管理されてもよい。ネットワーク検査セッションを設計するためのプロセス500は、510において検査機器トポロジーを定義することによって開始できる。510における検査機器トポロジーを定義することは、多くの検査ポートが検査セッション内にどのように含まれ、各検査ポートがネットワークに接続される場所を決定する工程を含んでもよい。510における検査機器トポロジーを定義することはまた、各検査ポートが検査セッションの間にエミュレートすることを定義する工程を含んでもよい。各検査ポートは、最小で単一のIPアドレスおよび最大で大部分のIPアドレスを含むネットワーク全体をエミュレートしてもよい。さらに、510における検査機器トポロジーを定義することは、各検査ポートを、ボーダゲートウェイプロトコルBorderGatewayProtocol、エクステリアゲートウェイプロトコルExteriorGatewayProtocol、オープンショーテストパスファーストプロトコルOpenShortestPathFirstProtocol、リソースリザベーションプロトコルResourceReservationProtocolおよび他のルーティングプロトコルなどの1つ以上のルーティングプロトコルを使用してネットワーク内のルータ、スイッチ、および他のデバイスに通知する制御パケットを定義する工程を含んでもよい。515において検査セッションの間に生成される検査トラフィックが定義されてもよい。検査トラフィックは1つ以上のトラフィックアイテムを含んでもよい。各トラフィックアイテムは、効果的にネットワークの別の検査であってもよい。各トラフィックアイテムは、複数のストリームとして定義されてもよい。各ストリームは、ソースポート;送信の周波数;ストリーム内のパケットの固定フィールドおよび可変フィールド例えば、パケットのプロトコルまたはタイプ、ソースおよび送信先IPアドレス、サービスのタイプ、およびペイロードコンテンツ;およびストリーム内の各パケットの他の特性などのストリームの属性を定義するストリームデータによって記載されてもよい。複雑なネットワークの広範な検査は、100万以上のフローを含む数千のストリームを含んでもよい。検査オペレータが、検査セッションの間に100万のフローを評価または理解することは不可能であるため、検査統計を分類し、集約するために使用され得るトラッキングファクターまたはパラメータが、525~540における各トラフィックアイテムのために定義されてもよい。トラッキングファクターは、ソースIPアドレス、送信先IPアドレス、サービスのタイプ、プロトコルなどの各パケット内のフィールドおよび他のフィールドを含んでもよい。トラッキングファクターは、例えば、ソースポートユニットおよび送信先ポートユニットなどのパケット内に含まれないが、各パケットに関連付けられた情報を含んでもよい。上記に説明したように、生成される各パケットは、パケットグループのメンバーとしてパケットを識別するためにPGIDを含んでもよく、トラフィック統計は、各PGIDについて蓄積されてもよい。トラフィック統計が、定義されたトラッキングファクターに基づいて格納、集約、および報告されることを可能にするために、各PGID値が、トラッキングファクターについての値の一意の組み合わせに対応してもよい。一部の状況において、PGIDはまた、トラッキングファクターに関連付けられていない情報を含んでもよい。トラッキングファクターをPGIDにマッピングするための理論的解釈および方法は、図5および図6に示した例を参照して理解され得る。図6の例において、IP.v4パケット600は、トラッキングファクターとして520において定義されている、サービスのタイプTosフィールド602、ソースIPアドレスフィールド604および送信先IPアドレスフィールド606を含む。さらに、図6の例は、検査セッションが4つのトラフィックアイテムを含み、トラフィックアイテム識別子622がトラッキングファクターの1つであるように自動的に定義されることを仮定する。525から540の動作は各トラッキングファクターについて繰り返されてもよい。525において、第1のトラッキングファクターが選択されてもよい。530において、検査セッションの間に実際に使用される選択されたトラッキングファクターの複数の値が識別されてもよい。複数の値は、例えば、515において定義されるストリームデータを検索することによって識別されてもよい。535において、複数の実数値が、選択されたトラッキングファクターに関連付けられたコードにマッピングまたは圧縮されてもよい。コードの長さは、トラッキングファクターについての複数の実数値の各々を識別するのに必要な最小数のビットであってもよい。図6の例において、IPv4パケットのTosフィールド602は8ビットの長さであるので、256の可能値を有する。しかしながら、検査セッションの間、Tosフィールドについて256の全ての可能値より小さい数が使用されてもよい。Tosフィールドについての値の数は、515において定義されたストリームデータの全てを分析することによって530において決定されてもよい。図6の例において、256個のうち8個のみの可能Tos値が、特定の検査アイテムのための検査トラフィックにおいて実際に使用されるという仮定がなされる。このように、実際に使用されるToS値は、535において、3ビットのみを有するToSコード624にマッピングされてもよい。ToSフィールド602の8個の実際に使用される8ビットの値から3ビットToSコード624までのマッピングは、ToSマップ612を使用して行われてもよい。ToSマップ612は、対応するToSコード値と各々の実際のToSフィールド値に一意的に関連するルックアップテーブルまたは他のデータ構造であってもよい。同様に、例示的なパケット600のヘッダは、32ビットのソースIPアドレスフィールド604および32ビットの送信先IPアドレスフィールド606を含み、各々は、約43億の送信先IPアドレスを定義する。しかしながら、検査セッションの間、少数のみのソースおよび送信先IPアドレスが使用されてもよい。さらに、DUTに接続される検査ポートの少なくとも一部は個別アドレスよりむしろネットワークを表示することができるので、一部のIPアドレスのうちの最小桁の部分例えば、最下位バイトまたは2つの最下位バイトは、検査セッションの間、パケットグループを識別するために使用されなくてもよい。このように、検査セッションの間にトラックされ得るソースおよび送信先IPアドレス値の数は、43億より非常に小さくなってもよい。530において識別されるような検査セッションの間にトラックされるソースおよび送信先IPアドレス値は、それぞれのマップ624、626によってそれぞれのコード626、628に535においてマッピングされてもよい。例えば、500個のソースIPアドレス値は、ソースIPマップ614によって9ビットのソースIPコード624にマッピングされてもよい。さらなる例のために、250個の送信先IPアドレス値は、送信先IPマップ616によって8ビットの送信先IPコード626にマッピングされてもよい。選択されたトラッキングファクターの全てについての値が、525~540においてそれぞれのコードにマッピングされる場合、そのコードは、グローバルフロー識別子IDを形成するために545において組み合わされてもよい。この文脈において、用語グローバルとは、どこでも使用されるか、または全てのポートユニットによって使用されることを意味する。図6の例を続けて、ToSコード624、ソースIPコード626、および送信先IPコード628は、トラフィックアイテム識別子622と組み合わされてグローバルフローID620を形成してもよい。この例において、グローバルフローID622は、トラフィックアイテム識別子622について2ビット、Tosコード624について3ビット、ソースIPコード626について9ビット、および送信先IPコード628について8ビット、合計で22ビットを含む。グローバルフローID620の各値は、選択されたトラッキングファクターについての値の一意の組み合わせに対応してもよい。より具体的には、グローバルフローID620についての各値は、特定のトラフィックアイテム、特定のToS、特定のソースIPアドレス、および特定の送信先IPアドレスに関連付けられてもよい。図6の例を続けて、22ビットのグローバルフローIDは、400万以上のパケットグループを一意的に識別する能力を有する。理想的な状況において、例示的な検査セッションの間に使用される各送信先ポートユニットは、400万以上の異なるパケットグループ上で検査統計を蓄積するために、図4Aに関して説明されるように2つのメモリバンクの各々においてメモリ容量を有する。この場合、22ビットのグローバルフローIDは、単に検査セッションの間に生成される各パケットに挿入されてもよい。しかしながら、実際の検査環境において、各ポートユニットにおいてこのメモリ大容量を提供することは、実用的でないか、または負担しきれない。従って、受信ポートの各々に送信されるフローの数がポートの容量を超えないようにトラフィックが定義されてもよい。550において、送信先ポートは、510において定義される複数の送信先ポートから選択されてもよい。555において、選択されたポートにおいて受信されるパケットのグローバルフローIDが識別されてもよい。560において、555において識別したグローバルフローIDが、ポート固有のPGIDマップによってPGIDのポート固有のセットにマッピングされてもよいか、または圧縮されてもよい。例えば、選択された送信先ポートは、検査セッションの間に100,000個の異なるフローを受信してもよく、各々は一意の22ビットのグローバルフローIDに関連付けられる。この場合、100,000個の22ビットのフローIDは、選択された送信先ポートに送信されるパケットに排他的に使用するために10,000個の17ビットのPGIDに一意にマッピングされてもよい。550から565までの動作は、対応するPGIDマップおよび対応するPGIDのセットを開発するために各送信先ポートに対して反復されてもよい。各PGID値は、単一のグローバルフローID値に対応してもよい。各グローバルフローID値は、選択されたトラッキングファクターについての値の一意の組み合わせに対応するので、各PGID値はまた、選択されたトラッキングファクターについての値の特定の組み合わせに関連付けられてもよい。PGIDマップおよびPGIDのセットは、各送信先ポートに関して異なってもよい。しかしながら、マルチキャストパケットは単一のPGID値のみを有してもよい。従って、マルチキャストパケットフローのグローバルフローIDは、マルチキャストパケットフローを受信する全ての送信先ポートのPGIDマップにおいて同じPGID値にマッピングされてもよい。一部の状況において、560において、1つ以上のポートのための許容可能であるポート固有のPGIDマップを生成することはできない。例えば、送信先ポートが、50,000パケットグループについてのトラフィック統計を蓄積するためにメモリ容量のみを有する場合、100,000個のグローバルフローIDを100,000個の17ビットのPGIDにマッピングすることは満たさない。このような状況において、プロセス500は、検査機器トポロジーを変化させるため、トラフィックを再定義するため、または異なるトラッキングファクターを選択するために510、515または525に戻ってもよい。プロセス500は、各送信先ポートのための許容可能なPGIDマップに到達することが必要な場合、反復的に繰り返してもよい。図6の例において、22ビットのグローバルフローID620のセットは、第1のポートPGIDマップ630-1によってPGID値の第1のセット632-1にマッピングされてもよい。PGID値の第1のセット632から選択されたPGIDは、第1の送信先ポートにおいて受信された全てのパケットに組み込まれてもよい。同様に、22ビットのグローバルフローID620のセットは、n番目のポートPGIDマップ630-nによってPGID値のn番目のセット632-nにマッピングされてもよい。PGID値のn番目のセット632-nから選択されたPGIDは、n番目の送信先ポートにおいて受信された全てのパケットに組み込まれてもよい。各送信先ポートに関して、許容可能なPGIDが550~565において定義され得る場合、およびPGID値の対応するセットが550~565において定義されている場合、515において少なくとも部分的に定義されるストリームデータは、適切なPGIDデータを各ストリーム定義に加えることによって570において完了されてもよい。575において、ストリームデータは、510において定義されるソースポートにダウンロードされてもよく、550~565において生成されるPGIDマップは、対応する送信先ポートにダウンロードされてもよい。ストリームデータおよびマップがダウンロードされた後、検査セッションを設計するためのプロセス500が590において終了してもよい。ここで図7を参照し、ネットワークを検査するためのプロセス700は、ポートユニット200などの複数のポートユニットに接続された検査アドミニストレータ205などの検査アドミニストレータによって実行されてもよい。各ポートユニットは、トラフィックジェネレータ、トラフィック受信器、およびポートプロセッサを備えてもよい。各トラフィック受信器は、2つのメモリバンクを有し得る統計メモリ内にトラフィック統計を蓄積してもよい。存在する場合、各トラフィック受信器内の2つの統計メモリバンクは、図4Aおよび図4Bに併せて記載されるようにトラフィック統計を交互に蓄積するために使用されてもよい。プロセス700は、実際は周期的であってもよく、検査セッションの期間、連続して反復してもよい。プロセス700は、ポートユニットが、例えば、検査セッション設計プロセス500における575などの検査セッション設計プロセスからストリームデータおよびPGIDマップを受信した後に開始してもよい。710において、検査セッションは、ポートユニットにより表示されたIPアドレスを被検査ネットワークに論理的に接続するために初期化されてもよい。検査セッションを初期化することは、ボーダゲートウェイプロトコルBorderGatewayProtocol、エクステリアゲートウェイプロトコルExteriorGatewayProtocol、オープンショーテストパスファーストプロトコルOpenShortestPathFirstProtocol、リソースリザベーションプロトコルResourceReservationProtocolおよび他のルーティングプロトコルなどの1つ以上のルーティングプロトコルを使用してそれらの存在を被検査ネットワークに通知するポートユニットを含んでもよい。検査セッションを初期化することはまた、被検査ネットワークを用いてパラメータ、例えばMPLSラベルとの通信を取り決めるポートユニットを含んでもよい。ポートユニットが710において被検査ネットワークに論理的に接続された後、検査トラフィックは、715において1つ以上のソースポートユニットによって生成され、720において1つ以上の送信先ポートユニットによって受信されてもよい。検査トラフィックは1つ以上のトラフィックアイテムを含んでもよい。各トラフィックアイテムは、複数のストリームを含んでもよく、各ストリームは多数のフローを含んでもよい。検査トラフィックは、715において複数のソースポートユニットによって同時に生成されてもよい。各ソースポートユニットによって生成される検査トラフィックは、複数のインターリーブストリームおよびフローを含んでもよい。715において、各ポートユニットはまた、各ストリームについて送信された少なくともいくらかのパケットを含む、送信トラフィック統計を蓄積してもよい。検査トラフィックは、720において複数の送信先ポートユニットによって同時に受信されてもよい。各送信先ポートユニットは、各受信されたパケットから抽出されるPGIDまたは増強されたPGIDによって識別されるパケットグループについての受信されたトラフィック統計を蓄積してもよい。ソースポートユニットおよび送信先ポートユニットは、全ての要求される検査トラフィックが送信されるという決定が725においてなされるまで、検査トラフィックを連続して生成し、受信することができる。730において、オペレータは、ほぼリアルタイムの検査データを要求し、見ることができる。本特許文献において、用語ほぼリアルタイムとは、検査セッションの全期間に対して少しのプロセス遅延を除いて現在を意味する。ほぼリアルタイムの検査データは、例えば、数秒から数分の時間遅れてもよい。ほぼリアルタイムの検査データは、730において同時に、および/またはトラフィック統計が715および720において蓄積された後に報告または見られてもよい。730における動作は、少なくとも一部のトラフィク統計が715および720において蓄積されるまで、実行されなくてもよい。730における動作は、オペレータが特定の検査データを見るために要求を入力するまで、実行されなくてもよい。730において要求され、見られる検査データは、715において蓄積される送信トラフィック統計および/または720において収集される受信されたトラフィック統計を含んでもよい。730において検査データを要求し、見ることは、実際は周期的であってもよい。730における動作は、オペレータが検査データを見るために新しい要求を入力するごとに反復されてもよい。730における動作は、定期的であってもよく、一定時間ごとに反復されてもよい。730が反復される時間間隔は、図4Aおよび図4Bと併せて記載されるように、ポートユニット内のスイッチング統計メモリバンクと同期されてもよい。730における動作は、735において、さらなる検査データを見る必要がないという決定がなされるまで、周期的に反復されてもよい。プロセス700は、さらなるトラフィックまたは検査データを見る必要がない場合、790において終えてもよい。図8は、図7における動作730の一部としての使用に適切であり得る受信されたトラフィック統計を見るためのプロセス830のフローチャートを示す。プロセス830は、図9に示す例と併せて説明する。以下の説明において、830~850の参照番号は図8に示され、910~940の参照番号は図9に示される。プロセス830は、検査アドミニストレータコンピューティングデバイスに接続され、次いで複数のポートユニットに接続される動作インターフェースによって実行されてもよい。このプロセス830は、815および820におけるトラフィック統計の蓄積と同時に行われてもよい。820において、蓄積されたトラフィック統計は、図4Aおよび図4Bに併せて記載される交互に使用される2つのバンクを有する統計メモリに格納されてもよい。832において、オペレータは、検査アドミニストレータコンピューティングデバイスに接続された動作インターフェースを介して特定のデータを見るために1つ以上の要求を入力してもよい。例えば、オペレータは、動作インターフェースのディスプレイデバイスに提示されたグラフィックユーザインターフェースを用いて要求を入力してもよい。各要求は、要求されたデータを集約し、編成するために使用される1つ以上のトラッキングファクターを識別できる。832において入力された要求に応答して、検査アドミニストレータは、832において要求される受信されたトラフィック統計を提供するようにポートユニットを構成できる。検査アドミニストレータは、各ポートユニット構成データを送信することによってポートユニットを構成してもよい。構成データは、例えば、受信されたトラフィック統計が要求されることを示すフィルタマスク、受信されたトラフィック統計がどのように集約されるかを示す1つ以上の集約マスク、および他の情報を含んでもよい。834において、検査アドミニストレータは、832において入力された要求を満たすために要求される特定の受信されたトラフィック統計を決定してもよい。検査アドミニストレータは、各送信先ポートユニットについての一意のフィルタマスクを生成してもよい。例えば、各フィルタマスクは、各ポート固有のPGIDに対応する単一のビットを有するビット列であってもよい。フィルタマスクの各ビットは、対応するPGIDのために蓄積される受信されたトラフィック統計が、832において入力された要求を満たすことを必要とされるか、されないかを示してもよい。834において、フィルタマスクは、それぞれの送信先ポートユニットに送信されてもよい。フィルタマスクは、十分な数のビット含んでもよい100,000個のPGIDについての受信されたトラフィック統計を蓄積するポートユニットのためのフィルタマスクは100,000ビットを必要とし得る。長いフィルタマスクは、例えば、検査アドミニストレータによって送信するために、ランレングス符号化によって圧縮され、続いて、それぞれの送信先ポートにおいて復元されてもよい。2つ以上の検査データビューが832において要求される場合、生成され、送信先ポートユニットに送信されるフィルタマスクは、組み合わせて要求される検査データビューの全てを必要とされる受信されたトラフィック統計を示してもよい。836において、検査アドミニストレータは、各々の要求された検査データビューに対応する集約マスクを生成できる。1つ以上の集約マスクは、全ての送信先ポートユニットに共通であってもよい。集約マスクは、832において要求される受信されたトラフィック統計を集約し、表示するために使用されるグローバルフローIDフィールドを定義することができる。集約マスクはまた、836において送信先ポートユニットに送信されてもよい。本特許文献において、用語集約するは、全体に収集または組み合せることの広範な意味を有する。集約トラフィック統計に含まれる正確な数学的演算は統計の性質に依存してもよい。例えば、多くの受信されたパケットは、各PGIDのために蓄積されてもよい。複数のPGIDのための受信されたパケットの数を集約するために、複数のPGIDの各々のために受信されたパケットの数は、受信されたパケットの集約数を提供するように単に合計されてもよい。さらなる例のために、最大待ち時間が各PGIDのために蓄積されてもよい。複数のPGIDのための最大待ち時間を集約するために、各PGIDについての最大待ち時間は相互に比較されてもよく、単一の最も大きな値は、集約最大待ち時間として選択されてもよい。838において、各ポートユニット内のポートプロセッサは、それぞれのフィルタマスクに従って、受信されたトラフィック統計を統計メモリから検索することができる。図9に示すように、各ポートユニットは、PGIDセット910のための受信されたトラフィック統計を蓄積してもよい。フィルタマスク920は、対応するPGIDに関連付けられた受信されたトラフィック統計が、832において要求される検査データを提供するために必要とされるか否かを示す各PGIDのための単一のビットを含んでもよい。PGIDセット910は、フィルタ処理されたPGIDセット925を提供するためにフィルタマスク920によってフィルタ処理されてもよい。図8に戻って参照し、ポートプロセッサは、838においてフィルタ処理されたPGIDセットの各PGIDに関連付けられた受信されたトラフィック統計を検索してもよい。受信されたパケット内のPGID値は、トラッキングファクターについての値にPGIDの即座の相関関係を提供しない方法で割り当てられてもよい。840において、フィルタ処理されたPGIDセット925の各PGIDは、フィルタ処理されたグローバルフローIDセット935にマッピングされてもよい。フィルタ処理されたPGIDセット925の各PGIDは、図6に示すポート固有のPGIDマップ630-1、630-nなどのポート固有のPGIDマップ930を使用して対応するグローバルフローIDにマッピングされてもよい。各グローバルフローIDは、複数のトラッキングファクターに対応するフィールドまたはコードを含んでもよい。図6の例を継続して、フィルタ処理されたグローバルフローIDセット935の各グローバルフローIDは、例えば、トラフィックアイテム、ToS/TC、ソースIPアドレス、および送信先IPアドレスに対応する別のフィールドを含んでもよい。842において、各ポートユニットは、836において検査アドミニストレータによって提供される集約マスクに従ってフィルタ処理されたグローバルフローIDに関連付けられた受信されたトラフィック統計を集約してもよい。集約マスクは、トラフィック統計を格納および報告するために使用されるフィルタ処理されたグローバルフローIDの1つ以上のフィールドを識別してもよい。例えば、図9に示す1番目の集約マスク940-1は、暗い影をつけたトラフィックアイテムフィールドを識別する。このマスクは、各ポートユニットに、トラフィックアイテムフィールドの値に従って、フィルタ処理されたグローバルフローIDに関連付けられた受信されたトラフィック統計を分類させてもよく、次いで、同じトラフィックアイテム値を有する全てのグローバルフローIDについての受信されたトラフィック統計を集約する。2番目および3番目の集約マスク940-2および940-3は、図11の説明と併せて以下に説明する。844において、集約された受信されたトラフィック統計は、各ポートユニットから検査アドミニストレータに更新されてもよい。上記の例に続けて、トラフィックアイテムフィールドの各値に対応する1セットの受信されたトラフィック統計は、各ポートユニットから検査アドミニストレータに更新されてもよい。846において、検査アドミニストレータは、各ポートユニットから受信される受信されたトラフィック統計を集約してもよい。850において、検査アドミニストレータは、動作インターフェースを介して846から集約された受信されたトラフィック統計を表示してもよい。集約されたトラフィック統計は、動作インターフェース内のディスプレイデバイス上の検査データビューを介してオペレータに表示されてもよい。集約された受信されたトラフィック統計はまた、一部の他の方法でプリント、ネットワークを介して送信、格納、および/または報告されてもよい。848において、検査アドミニストレータは、統計メモリバンクを交換する時期を決定するために、ポートユニットによって使用される取得期間を設定または更新してもよい。取得期間は、838から846において要求されるプロセス時間より単に長い時間に設定されてもよく、それによって、850において報告される検査データは、検査アドミニストレータおよびポートデバイスの制限内で可能な限り頻繁に更新されてもよい。全プロセス830は、実質的に周期的であってもよい。838から850の動作は、ポートが統計メモリバンクを交換するごとに、または各取得期間に一度、反復されてもよい。832から836における動作は、新しい検査データビューが要求されるごとに反復されてもよい。図10は、図7における動作730の第2の部分としての使用に適切であり得る送信トラフィック統計を見るためのプロセス1030のフローチャートを示す。プロセス1030は、検査アドミニストレータコンピューティングデバイスに接続され、次いで複数のポートユニットに接続された動作インターフェースによって実行されてもよい。プロセス1030は、図8に示す815および820におけるトラフィック統計の蓄積と同時に、ならびに受信されたトラフィック統計を報告するためのプロセス830と同時に実行されてもよい。1032において、オペレータは、検査アドミニストレータコンピューティングデバイスに接続された動作インターフェースを介して特定のデータを見るために1つ以上の要求を入力してもよい。例えば、オペレータは、動作インターフェースのディスプレイデバイス上に表示されるグラフィックユーザインターフェースを用いて要求を入力してもよい。各要求は、要求されたデータを集約し、編成するために使用される1つ以上のトラッキングファクターを識別できる。1032において入力された要求に応答して、1054において、検査アドミニストレータは、例えば、送信ポートユニットによって、図7における715において蓄積された送信トラフィック統計を集約するための複数の集約グループを定義してもよい。集約グループは、1032において要求される特定の検査データビューに応答して集約されるべきトラフィック統計のグループである。集約グループは、例えば、トラフィックアイテム、IPソースおよび/または送信先アドレス、ソースおよび/または送信先ポートユニット、ソースおよび/または送信先TCPポート、サービスの質またはタイプ、他のファクター、およびファクターの組み合せによって定義されてもよい。検査データは、通常、表示、プリント、および他の場合には表形式で報告されてもよく、集約グループは、例えば、表の列に対応してもよい。表形式で検査データを表示し、報告することは、図11と併せてさらに詳細に以下に説明する。1054において、ストリームごとに送信されたパケット数を含む、送信トラフィック統計は、1つ以上のポートユニットから検査アドミニストレータコンピューティングデバイスに更新されてもよい。1056において、1054から送信されたパケット数は、集約グループの間で割り当てられてもよい。集約グループの間の送信されたパケット数の割り当ては、例えば、各ストリームにおけるパケットの一部が1052において定義される集約グループの各々に属することを決定するために、各ストリームについてのストリーム生成データを分析するソフトウェアアプリケーションを実行する検査アドミニストレータコンピューティングデバイスによって行われてもよい。例えば、使用者は、各ソースポートユニットによって送信されたパケット数からなる検査データビューを要求することを仮定する。この場合、割り当てグループは、それぞれのポートユニットに対応し、1056において、所定のポートユニットから送信されるパケットの全ては、対応する集約グループに割り当てられる。より現実的な例のために、使用者が、トラフィックアイテムによる検査統計からなる検査データビューを要求することを仮定する。この場合、1056において、そのストリームにおいて送信されたパケットの部分が、各集約グループに割り当てられるべきであるかを決定するために、全てのパケットストリームについてのストリーム形成データが分析される。例えば、1056において、所定のストリームについてのストリーム形成データの分析は、ストリームが、周期的に反復される100パケットのシーケンスからなることを決定することができる。1056における分析はさらに、反復されたシーケンスにおける100パケットが、5個の集約グループの間で均一に分割されることを決定することができる。この場合、ストリームについての送信されたパケットの総数が2000パケットである場合、400パケット数が5個の集約グループの各々に割り当てられる。送信されたパケット数の全てが集約グループの間で割り当てられるまで、分析および割り当てプロセスは、全てのパケットストリームについて同様に反復されてもよい。1050において、検査アドミニストレータは、動作インターフェースを介して1046からの集約された送信トラフィック統計を表示できる。集約された送信トラフィック統計は、動作インターフェース内の、または動作インターフェースに接続されたディスプレイデバイス上の検査データビューを介してオペレータに表示されてもよい。集約された送信トラフィック統計はまた、プリント、ネットワークを介して送信、格納、および/または一部の他の方法で報告されてもよい。集約された送信トラフィック統計は、図8のプロセス830からの受信されたトラフィック統計と組み合わせて一部の他の方法で表示、プリント、送信、格納および/または報告されてもよい。全プロセス1030は実質的に周期的であってもよい。1032から1050における動作は、周期的に、または新しい検査データビューが要求されるごとに反復されてもよい。図11は、オペレータに表示され得るか、または他の場合には報告され得る例示的な検査データビュー1101、1103、1105を示す。例示的な検査データビュー1101、1103、1105は、図8のプロセス830から集約された受信されたトラフィック統計と図10のプロセス1030から集約された送信トラフィック統計とを組み合せる。例示的な検査データビューは、図6において最初に開始された例に基づく。表示を簡単にするために、1つのみの送信統計、送信されたパケット数、および2つの受信されたトラフィック統計、受信されたパケット数および順番誤りのパケット数を示す。現実世界の検査において、多数の他の受信されたトラフィック統計が蓄積され、表示されてもよい。受信されたトラフィック統計は、受信されたパケット数、順番誤りの受信されたパケット数、および失ったパケット数などの定量的データ;最小、最大、および/または平均待ち時間などの時間データ;ならびに他の情報を含んでもよい。受信されたトラフィック統計は、送信先ポートユニットにおいて蓄積されたデータ、および送信され、ソースポートユニットにおいて蓄積されたパケット数などのデータを含んでもよい。第1の検査データビュー1101は、トラフィックアイテムに従って集約された送信トラフィック統計および受信トラフィック統計の両方を示す。第1の検査データビューは、図9の1番目の集約マスク940-1と一致してもよい。図6の例に沿って、トラフィックアイテムは4つのみの値を有する。4つのトラフィックアイテムおよび対応する集約されたトラフィック統計は、例えば、図11に1101として示すように表形式で表示されてもよい。第1の検査データビューは、検査セッションについての第1のレベルのデータの概要とみなされてもよい。第1のレベルの概要のビューは、選択された第1のトラッキングファクターこの例においてトラフィックアイテムに従って集約された全てのパケットグループについての概要検査データを表示してもよい。例えば、ソースポート数または送信先ポート数などの別のトラッキングファクターは、第1のトラッキングファクターとして選択されてもよく、類似の第1のレベルの概要の検査データビューが生成されてもよい。第1のレベルの検査データビューをレビューする際に、オペレータは、第1のトラッキングファクターについての1つの特定の値を選択してもよく、次いで、第2のトラッキングに従って集約される第2のレベルの検査データビューを要求してもよい。図11の例において、オペレータは、第1のレベルの検査データビュー1101をレビューし、トラフィックアイテム0影を付けて示すを選択してもよい。次いで、可能な第2のトラッキングファクターのリスト1102が表示されてもよく、オペレータが第2のトラッキングファクターを選択してもよい。図11の例において、オペレータは、第2のトラッキングファクターとしてソースIPアドレス表1102に影を付けて示すを選択するように仮定される。ソースIPアドレスのオペレータ選択に応答して、第2のレベルの検査データビュー1103が生成されてもよい。例示的な第2のレベルの検査データビュー1103は、トラフィックアイテム0についての検査データのみを示してもよく、ソースIPアドレスによって分類および集約されるトラフィックアイテム0についての検査データを示してもよい。第2のレベルの検査データビュー1103は、トラフィックアイテム0に関連付けられていない全ての検査データを拒否するフィルタマスク920、およびフィルタ処理されたグローバルフローID925のソースIPアドレスフィールドに基づいてトラフィック統計を集約するようにポートユニットに指示する集約マスク940-2などの集約マスクを用いて生成されてもよい。第2のレベルの検査データビューをレビューする際に、オペレータは、第2のトラッキングファクターについての1つの特定の値を選択してもよく、次いで第3のトラッキングファクターに従って集約された第3のレベルの検査データビューを要求してもよい。図11の例において、オペレータは、第2のレベルの検査データビュー1102をレビューしてもよく、ソースIPアドレスbbb.bbb.bbb.bbb影を付けて示すを選択してもよい。次いで、可能な第3のトラッキングファクターのリスト1104が表示されてもよく、オペレータが第3のトラッキングファクターを選択してもよい。図11の例において、オペレータは、第3のトラッキングファクターとしてサービスのタイプ表1104に影を付けて示したToSを選択するように仮定される。ToSのオペレータ選択に応答して、第3のレベルの検査データビュー1105が生成されてもよい。例示的な第3のレベルの検査データビュー1005は、トラフィックアイテム0およびTosによって分類し、集約されるソースIPアドレスbbb.bbb.bbb.bbbについての検査データのみを示してもよい。第3のレベルの検査データビュー1105は、トラフィックアイテム0およびソースIPアドレスbbb.bbb.bbb.bbb、ならびにフィルタ処理されたグローバルフローID925のToSに基づいたトラフィック統計を集約するようにポートユニットに指示する、集約マスク940-3などの集約マスクに関連付けられていない全ての検査データを拒否するフィルタマスク920を用いて生成されてもよい。分類する1つ以上のさらなるレベルおよび集約は、所定のトラフィックアイテムに使用されるトラッキングファクターの数に応じて、利用可能であってもよい。[結びのコメント]本文献を通して示される実施形態および例は、開示または請求される装置および手順に対する限定ではなく、例としてみなされるべきである。本文献に示される例の多くは、方法行為またはシステム要素の特定の組み合わせを含むが、それらの行為および要素は、同一の目的を達成する他の方法と組み合わせられ得ることが理解されるべきである。フローチャートに関しては、更なるステップやより少ないステップをとり得るものであり、図示したステップは、組み合わせられるかまたは更に洗練されることにより、本文献に記載される方法を達成し得る。一実施形態のみに関連して説明した行為、要素および特徴は、他の実施形態における同様の役割から除外されることを意図しない。本文献で用いられる複数は、2つ以上であるということを意味する。本文献で用いられる、項目のセットは、そのような項目の1つ以上を含み得る。明細書または特許請求の範囲のいずれにおいても、本文献で用いられる備える、含む、持つ、有する、包含する、伴う等の用語は、オープンエンド、すなわち含むが限定しないことを意味すると理解されるべきである。特許請求の範囲に関しては、から成るおよびから基本的に成るという移行句のみが、それぞれ、閉じた移行句またはやや閉じた移行句である。特許請求の範囲において請求項要素を修飾する第1第2第3等の序数用語の使用は、それ自身ではいかなる優先順、優先度、または他の請求項に対するある請求項の順序、あるいは方法の行為が実行される時間的順序を暗示するものではなく、同一の名称を有する別の要素から特定の名称を有する1つの要素を区別し、請求項要素を区別するためのラベルとして単に使用されるものである序数用語の使用を除く。本文献で用いられるおよび/またはは、列挙される項目が選択肢であることを意味するが、選択肢もまた列挙される項目の任意の組み合わせを含む。"