パケットのフラグメント化の検査
【課題】データグラムをフラグメントに変換するネットワークを検査するための方法および装置を提供する。
【解決手段】トラフィックジェネレータは、複数の計測ブロックを含むデータグラムを生成し得、かつネットワークを通じて検査トラフィックを送信し得る。トラフィックレシーバは、ネットワークを介して受信された複数のフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定し得る。トラフィックレシーバは、受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を報告し得る。
【解決手段】トラフィックジェネレータは、複数の計測ブロックを含むデータグラムを生成し得、かつネットワークを通じて検査トラフィックを送信し得る。トラフィックレシーバは、ネットワークを介して受信された複数のフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定し得る。トラフィックレシーバは、受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を報告し得る。
【発明の詳細な説明】
【技術分野】
【０００１】
（著作権およびトレードドレスについての通知）
本特許文献の開示の一部は著作権保護に対象となるマテリアルを含む。本特許文献は、保有者のトレードドレスである、またはトレードドレスとなり得る事柄を示し、および／または記載する場合がある。著作権およびトレードドレスの保有者は、いかなる者であっても米国特許商標局の書類または記録の通りに本特許開示を複製する限りで、異議を申し立てるものではないが、その他の場合には、いかなる場合であっても全ての著作権およびトレードドレスの権利を保留するものである。
【０００２】
本出願は、本出願と同日に出願されたＴＥＳＴＩＮＧ ＦＲＡＧＭＥＮＴ ＲＥＡＳＳＥＭＢＬＹ（フラグメントの再構成の検査）と題された同時係属中の特許出願に関連する。
【０００３】
本開示は、ネットワークまたはネットワークデバイスを検査することに関する。
【背景技術】
【０００４】
多くのタイプの通信ネットワークにおいて、送信される各メッセージは固定長または可変長の部分へと分割される。各々の部分は、情報のパケット、フレーム、セル、データグラム、データ単位、または他の単位と呼ばれる場合があり、それらの全ては、本明細書において、パケットとして参照される。
【０００５】
各パケットは、通常、パケットペイロードと呼ばれる元のメッセージの一部を含む。パケットペイロードはデータを含んでよく、あるいは、音声情報またはビデオ情報を含んでもよい。パケットペイロードはまた、ネットワーク管理および制御情報を含んでもよい。さらに、各パケットは、通常、パケットヘッダと呼ばれる識別およびルーティング情報を含む。パケットはネットワークを通じて複数のスイッチまたはノードを介して個々に送信される。パケットは、目的とするデバイスまたはエンドユーザにメッセージが配信される前に、パケットヘッダに含まれる情報を用いて最終的な送り先または中間の送り先にてメッセージに再構築される。受信側において、その再構築されたメッセージは、ユーザの装置に適合するフォーマットでエンドユーザに送られる。
【０００６】
メッセージをパケットとして送信する通信ネットワークは、パケット交換ネットワークと呼ばれる。パケット交換ネットワークは、通常、ハブまたはノードで交差する送信パスのメッシュを含む。ノードの少なくとも一部は、ノードに到着するパケットを受け取り、適切な発信パスに沿ってパケットを再送信するスイッチングデバイスまたはルータを備えてよい。パケット交換ネットワークは、業界標準のプロトコルのレイヤ別の構造によって制御される。その構造のレイヤ１、２、および３は各々、物理レイヤ、データリンクレイヤ、およびネットワークレイヤである。
【０００７】
レイヤ１のプロトコルは、ネットワークのノード間での物理的な（電気的、光学的、または無線の）インターフェースを規定する。レイヤ１のプロトコルは、イーサネット（登録商標）の物理的コンフィグレーション、ＳＯＮＥＴ（同期光学的ネットワーク）、および他の光学接続プロトコル、ならびに、ＷｉＦｉ（登録商標）等の様々な無線プロトコルを含む。
【０００８】
レイヤ２のプロトコルは、データがネットワークのノード間を論理的に転送される方法を制御する。レイヤ２のプロトコルは、イーサネット（登録商標）、ＡＴＭ（非同期転送モード）、フレームリレー、およびＰＰＰ（ポイント・ツー・ポイント・プロトコル）を含む。
【０００９】
レイヤ３のプロトコルは、ネットワークの複数のノードを接続するパスに沿ってソースから送り先へパケットがルーティングされる方法を制御する。主要なレイヤ３のプロトコルは周知のインターネットプロトコルバージョン４（ＩＰｖ４）およびバージョン６（ＩＰｖ６）である。パケット交換ネットワークは、イーサネット（登録商標）、ＡＴＭ、ＦＲ、および／またはＰＰＰのレイヤ２のプロトコルの混合体を用いてＩＰパケットをルーティングする必要がある場合もある。ネットワークのノードの少なくとも一部は、各パケット内に含まれるネットワークレイヤヘッダから、送り先アドレスを抽出するルータを備えてもよい。ルータは次いで、パケットが再送信されるべきルートまたはパスを決定するために送り先アドレスを用いる。通常のパケットは複数のルータを通過してよく、それらのルータの各々は送り先アドレスを抽出する行為およびそのパケットが再送信されるべきルートまたはパスを決定する行為を繰り返す。
【００１０】
ＩＰｖ４およびＩＰｖ６レイヤ３のプロトコルもまた、パケットのフラグメント化および再構成を提供する。ネットワークデバイスは、元々のパケットを２つ以上のより短いパケットにフラグメント化し得て、そうしたパケットはその後、一部の他のネットワークデバイスによって元々のパケットに再構成され得る。パケットのフラグメント化および再構成は、例えば、ネットワーク内のデバイスまたはパスが、元々のパケットよりも、より短い最大許容パケット長を有する場合に必要となり得る。パケットのフラグメント化および再構成はまた、長いデータパケットを、周期的にスケジューリングされた音声または映像のパケット間で送信可能であるフラグメントに分割するために用いられ得る。ＩＰｖ４の用語体系を踏まえれば、フラグメント化される元々のパケットは、本明細書において、「データグラム」と呼ばれる。各データグラムは複数の「フラグメント（断片）」に分割され得る。データグラムおよびフラグメントの両方は、前述で規定されたようにパケットであることに留意されたい。
【００１１】
パケット交換ネットワーク、またはパケット交換通信ネットワーク内に含まれるデバイスを検査するために、多数のパケットを含んだ検査トラフィックが生成され、１つ以上のポートにおいてネットワークに送信され、かつ異なるポートにおいて受信されてよい。検査トラフィック内の各パケットは、特定の送り先ポートでの受信を意図したユニキャストのパケット、あるいは、１つ以上の送り先ポートでの受信を意図する場合もあるマルチキャストのパケットであってもよい。これに関連して、用語「ポート」とは、ネットワークと、そのネットワークを検査するために用いられる装置との間の通信接続のことをいう。用語「ポートユニット」とは、ポートにおいて、ネットワークに接続するネットワーク検査装置内のモジュールのことをいう。受信された検査トラフィックは、ネットワークのパフォーマンスを測定するために分析され得る。ネットワークに接続された各ポートユニットは、検査トラフィックのソースおよび検査トラフィックの送り先の両方であってよい。各ポートユニットは、複数の論理ソースまたは送り先アドレスをエミュレートしてよい。
【００１２】
単一のポートユニットから発せられ、特定のタイプのパケットおよび特定のレートを有する一連のパケットを、本明細書において、「ストリーム」と呼ぶ。ソースポートユニットは、例えば、複数のパケットタイプ、レート、または送り先を含むため、複数の発信ストリームを同時にかつ並行してサポートし得る。「同時に（ｓｉｍｕｌｔａｎｅｏｕｓｌｙ）」とは「正確に同一時間に」を意味する。「並行して（ｃｏｎｃｕｒｒｅｎｔｌｙ）」とは、「同一時間内で」を意味する。
【００１３】
検査データを収集する目的のために、検査トラフィックはパケットグループに分けられてよく、ここで「パケットグループ」とは、ネットワークトラフィック統計が蓄積される任意の複数のパケットである。所与のパッケトグループ内のパケットは、各パケット内に含まれるパケットグループ識別子（ＰＧＩＤ）によって識別され得る。ＰＧＩＤは、例えば、専用識別子フィールドまたは各パケット内の２つ以上のフィールドの組み合わせであってもよい。
【００１４】
ネットワークトラフィックデータを報告する目的のために、検査トラフィックが、フローとして編成されてもよく、ここで、「フロー」とは、ネットワークトラフィック統計を報告する任意の複数のパケットのことである。各フローは、単一のパケットグループまたは少数のパケットグループからなってもよい。各パケットグループは、一般に、単一のフローに属してもよい。
【００１５】
本記述において、用語「エンジン」は、記述した機能を実行するハードウェアの集合体を意味し、これはファームウェアおよび／またはソフトウェアによって増強することができる。エンジンは、通常、主に機能的な用語においてエンジンを定義するハードウェア記述言語（ＨＤＬ）を用いて設計され得る。このようなＨＤＬ設計は、ＨＤＬシュミレーションツールを用いて検証され得る。次に、検証されるＨＤＬ設計は、一般に「合成」と呼ばれるプロセスにおいてゲートネットリストまたは他のエンジンの物理的な記述に変換され得る。この合成は、合成ツールを用いて自動的に行うことができる。ゲートネットリストまたは他の物理的な記述は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックデバイス（ＰＬＤ）、またはプログラマブルロジックアレイ（ＰＬＡ）のようなプログラム可能なハードウェアデバイスにおいてエンジンを実装するためのプログラミングコードにさらに変換され得る。ゲートネットリストまたは他の物理的な記述は、エンジンを特定用途向け集積回路（ＡＳＩＣ）内にて製造するためのプロセス命令およびマスクに変換され得る。
【００１６】
本記載において、用語「ロジック」はまた、「エンジン」よりも、より小さなスケールであり得る記載された機能を実行するハードウェアの集合体を意味する。「ロジック」は、組み合わせ論理回路、フリップフロップ、レジスタ、および他のデータ保存要素を含み得るシーケンシャル論理回路、ならびに、有限状態機械等の複合シーケンシャル論理回路を含む。
【００１７】
本記載において、「ユニット」はまた、ファームウェアおよび／またはソフトウェアによって増強し得る、「エンジン」よりも、より大きなスケールであり得る、ハードウェアの集合体を意味する。例えば、ユニットは複数のエンジンであって、それらのエンジンの一部が並行して類似の機能を実行し得る。用語「ロジック」、「エンジン」、および「ユニット」は、任意の物理的な分離または境界区分の意味を含まない。１つ以上のユニットおよび／またはエンジンの全てまたは一部は、例えばネットワークカードまたはブレード等の一般的なカード上、あるいは一般的なＦＰＧＡ、ＡＳＩＣ内、または他の回路デバイス内で配置されてよい。
【図面の簡単な説明】
【００１８】
【図１】ネットワーク環境のブロック図である。
【図２】ネットワークカードのブロック図である。
【図３】パケットのフラグメント化のグラフィック図である。
【図４】パケットのフラグメント化を検査するための方法のフローチャートである。
【図５】パケットのフラグメント化のグラフィック図である。
【図６】パケットのフラグメント化のグラフィック図である。
【図７】計測ブロックのグラフィック図である。
【図８】パケット再構成を検査するための方法のフローチャートである。
【図９】計測ブロックのグラフィック図である。
【発明を実施するための形態】
【００１９】
本記載全体を通じて、ブロック図に表される要素は、３桁の参照番号が割り当てられ、最上位桁はその要素が示されている図面の番号であり、下位２つの桁は要素に特定されるものである。ブロック図に関連して記載されない要素は、同じ参照番号を有する前述された要素として同じ特徴および機能を有するものとみなされてよい。
【００２０】
ブロック図において、矢印で終端している線は、信号というよりはデータパスを示し得る。各データパスはビット幅において多数ビットであってよい。例えば、各データパスは、４、８、１６、６４、２５６、あるいはそれ以上の並列接続からなっていてもよい。
【００２１】
（装置の記載）
図１はネットワーク環境のブロック図を示す。ネットワーク環境は、ネットワーク検査装置１００、および１つ以上のネットワークデバイス１９２を含むネットワーク１９０を備えてよい。
【００２２】
ネットワーク検査装置１００は、ネットワーク検査デバイス、パフォーマンスアナライザ、適合性確認システム、ネットワークアナライザ、またはネットワーク管理システムであってよい。ネットワーク検査装置１００は、１つ以上のネットワークカード１０６、およびシャーシ１０２内に含まれるかまたは包囲されたバックプレーン１０４を備えてよい。シャーシ１０２は、ネットワーク検査装置を含むのに適した固定型または可搬型のシャーシ、キャビネット、または筐体であってよい。ネットワーク検査装置１００は図１に示すように一体化されたユニットであってよい。あるいは、ネットワーク検査装置１００は、トラフィックの生成および／または分析を提供するように協動する複数の別個のユニットを備えてよい。ネットワーク検査装置１００およびネットワークカード１０６は、例えば様々なイーサネット（登録商標）およびファイバーチャネル標準等の１つ以上の周知の規格またはプロトコルをサポートしてよく、かつ専用のプロトコルもサポートしてよい。
【００２３】
ネットワークカード１０６は、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、プロセッサ、および他の種類のデバイスを含んでよい。ネットワークカード１０６は、例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理デバイス（ＰＬＤ）、プログラマブル論理アレイ（ＰＬＡ）等の１つ以上のプログラム可能ハードウェアデバイスを含んでよい。さらに、ネットワークカード１０６は、ソフトウェアおよび／またはファームウェアを含んでよい。用語、ネットワークカードは、ラインカード、テストカード、分析カード、ネットワークラインカード、ロードモジュール、インターフェースカード、ネットワークインターフェースカード、データインターフェースカード、パケットエンジンカード、サービスカード、スマートカード、スイッチカード、リレーアクセスカード等を含む。用語、ネットワークカードはまた、複数のプリント回路基板を含み得るモジュール、ユニット、およびアセンブリを含む。各ネットワークカード１０６は１つ以上のポートユニット１１０を含み得る。各ポートユニット１１０は、１つ以上のポートを介してネットワーク１９０に接続し得る。ポートユニット１１０は、通信媒体１９５を介してネットワーク１９０に接続されてよく、この通信媒体１９５は、ワイヤ、光ファイバ、無線リンク、または他の通信媒体であってよい。各ネットワークカード１０６は、単一の通信プロトコルをサポートしてよく、複数の関連のプロトコルをサポートしてよく、または、複数の関連のないプロトコルをサポートしてもよい。ネットワークカード１０６は、ネットワーク検査装置１００内に恒久的に設置されていてもよく、または着脱自在であってもよい。
【００２４】
バックプレーン１０４は、ネットワークカード１０６のために、バスまたは通信媒体として機能してよい。バックプレーン１０４はまた、電極をネットワークカード１０６に提供し得る。
【００２５】
ネットワークデバイス１９２は、ネットワーク１９０を介しての通信を可能にする任意のデバイスであってよい。ネットワークデバイス１９２は、ワークステーション、パーソナル・コンピュータ、サーバ、ポータブル・コンピュータ、携帯情報端末（ＰＤＡ）、コンピューティング・タブレット、セル式電話／携帯電話、イーメール用装置等のコンピューティングデバイス、プリンタ、スキャナ、ファクシミリ装置等の周辺機器、ネットワーク接続ストレージ（ＮＡＳ）およびストレージ・エリア・ネットワーク（ＳＡＮ）のデバイス等のディスクドライブを含むネットワーク対応のストレージデバイス、ルータ、リレー、ハブ、スイッチ、ブリッジ、およびマルチプレクサ等のネットワーキング・デバイスであってよい。さらに、ネットワークデバイス１９２は、ネットワークを通じて通信することができる家庭電化器具、アラームシステムおよび他の任意のデバイスまたはシステムを含んでもよい。
【００２６】
ネットワーク１９０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ストレージエリアネットワーク（ＳＡＮ）、有線、無線、またはこれらの組み合わせであってもよく、インターネットを含んでもよく、またはインターネットであってもよい。ネットワーク１９０上の通信は、情報のフレーム、セル、データグラム、パケットまたは他の単位を含む様々な形態をとってもよく、本明細書においては、それらの全てをパケットと称する。ネットワーク検査装置１００およびネットワークデバイス１９２は、同時に相互に通信してもよく、ネットワーク検査装置１００と所与のネットワークデバイス１９２との間には、複数の論理的通信経路があってもよい。ネットワークそのものは、移動するデータのための多数の物理的経路および論理的経路を提供する多数のノードから成ってもよい。各ポートユニット１１０は、特定の通信媒体１９５を介して、ネットワークデバイス１９２上の対応のポートに接続されてもよい。
【００２７】
ここで図２を参照し、例示的なポートユニット２１０は、ポートプロセッサ２１２と、トラフィックジェネレータユニット２２０と、トラフィックレシーバユニット２８０と、ポートユニット２１０を被検査ネットワーク２９０に接続するネットワークインターフェースユニット２７０とを備えてもよい。ポートユニット２１０は、ネットワークカード（例えばネットワークカード１０６）のすべてまたは一部であってもよい。被検査ネットワーク２９０は、ネットワークデバイス１９４等の１つ以上のネットワークデバイス、および／または、ネットワーク１９０等のネットワークの全てまたは一部であってもよい。
【００２８】
ポートプロセッサ２１２は、本明細書に記載される機能および特徴を提供するための、プロセッサ、プロセッサに接続されたメモリ、および様々な特殊化された装置、回路、ソフトウェアおよびインターフェースを含んでもよい。プロセス、機能および特徴は、全体的にあるいは部分的に、プロセッサ上で動作するソフトウェアにおいて実現されてもよく、ファームウェア、アプリケーションプログラム、アプレット（例えばＪａｖａ（登録商標）アプレット）、ブラウザプラグイン、ＣＯＭオブジェクト、ダイナミックリンクライブラリ（ＤＬＬ）、スクリプト、１つ以上のサブルーチン、またはオペレーティングシステムのコンポーネントまたはサービスという形をとってもよい。ハードウェアおよびソフトウェアおよびそれらの機能は、一部の機能がプロセッサによって実行され、他の機能が他の装置によって実行されるように、分散型であってもよい。
【００２９】
ポートプロセッサ２１２は、オペレータインターフェース２０７に接続し得る検査アドミニストレータ２０５と通信してもよい。検査アドミニストレータ２０５は、ネットワーク検査装置１００の内部に収容されるコンピューティングデバイスまたは外部のコンピューティングデバイスであってもよい。検査アドミニストレータ２０５は、ポートユニットがネットワーク２９０の検査に関与するために必要とされる命令およびデータを、ポートプロセッサ２１２に提供してもよい。検査アドミニストレータ２０５から受信される命令およびデータは、例えば、ポートユニット２１０によって生成されるパケットストリームの定義、およびポートユニット２１０によって蓄積および報告され得るパフォーマンス統計の定義を含んでもよい。
【００３０】
ポートプロセッサ２１２は、トラフィックジェネレータユニット２２０にストリーム形成データ２１４を提供して、複数のストリームを形成させる。ストリーム形成データ２１４は、例えば、パケットのタイプ、送信の周波数、パケット内部の固定内容フィールドおよび可変内容フィールドの定義、および各パケットストリームのための他の情報を含んでもよい。トラフィックジェネレータユニット２２０は、次いで、ストリーム形成データ２１４に従って複数のストリームを生成してよい。複数のストリームは、発信検査トラフィック２３５を形成するためにインターリーブされてよい。各々のストリームは、パケットのシーケンスを含んでよい。各ストリーム内のパケットは、同じ一般的な種類であってもよく、長さおよびコンテンツが異なっていてもよい。
【００３１】
ネットワークインターフェースユニット２７０は、トラフィックジェネレータユニット２２０からの発信検査トラフィック２３５を、ワイヤ、光ファイバ、無線リンク、または他の通信リンクであり得るリンク２９５を介して、被検査ネットワーク２９０へと検査トラフィックを送信するように要求される、電気的、光学的、または無線による信号フォーマットに変換してよい。同様に、ネットワークインターフェースユニット２７０は、ネットワークからリンク２９５を介して電気的、光学的、または無線による信号を受信してよく、かつ、トラフィックレシーバユニット２８０に対して利用可能なフォーマットに、着信する検査トラフィック２７５に受信される信号を変換してよい。
【００３２】
トラフィックレシーバユニット２８０は、ネットワークインターフェースユニット２７０から着信検査トラフィック２７５を受信してよい。トラフィックレシーバユニット２８０は、各受信パケットが特定のフローのメンバーであるかを決定し得、また、ポートプロセッサ２１２から提供された検査命令２１８に従って各フローに関する検査統計を蓄積し得る。蓄積された検査統計は、例えば、受信パケットの合計数、順番通りでない順序にて（ｏｕｔ−ｏｆ−ｓｅｑｕｅｎｃｅ）受信されたパケットの数、エラーを有する受信パケットの数、最大、平均および最小の伝搬遅延、および各フローの他の統計を含んでもよい。トラフィックレシーバユニット２８０はまた、検査命令２１８に含まれる取得基準に従って、特定のパケットを取得および格納してもよい。トラフィックレシーバユニット２８０は、検査セッションの最中または後におけるさらなる分析のために、検査統計および／または取得パケット２８４を、検査命令２１８に従って、ポートプロセッサ２１２に提供してもよい。
【００３３】
発信検査トラフィック２３５および着信検査トラフィック２７５は、主にステートレスであってもよい。すなわち、発信検査トラフィック２３５は、応答を予期することなく生成されてもよく、着信検査トラフィック２７５は、応答を意図することなく受信されてもよい。しかしながら、ステートフル、すなわち双方向的な通信の一部が、検査セッションの間、ポートユニット２１０とネットワーク２９０との間において必要とされるか、または所望され得る。例えば、トラフィックレシーバユニット２８０は、検査セッションを制御するのに必要なデータを含む制御パケットを受信してもよく、この制御パケットは、確認または応答を送信するためにポートユニット２１０を必要とする。
【００３４】
トラフィックレシーバユニット２８０は、着信検査トラフィックから着信制御パケットを分離させてよく、着信制御パケット２８２をポートプロセッサ２１２へとルーティングしてよい。ポートプロセッサ２１２は、各制御パケットのコンテンツを抽出し得て、１つ以上の発信制御パケット２１６の形で適切な応答を生成し得る。発信制御パケット２１６は、トラフィックジェネレータユニット２２０に提供され得る。トラフィックジェネレータユニット２２０は、発信制御パケット２１６を発信検査トラフィック２３５に挿入し得る。
【００３５】
トラフィックジェネレータ２２０によって生成された各パケットは、検査データブロックとも呼ばれる少なくとも１つの計測（インストルメンテーション）ブロックを含んでよく、計測ブロックは、被検査ネットワークのパフォーマンスにアクセスするのに必要な情報を含む。例えば、計測ブロックは、署名フィールド、パケットグループ識別子、およびシーケンス番号を含んでよい。署名フィールドは、受信されたパケットを検査パケットとして識別してよく、かつそのパケットを用いて計測ブロックの位置を決定するために用いられてもよい。パケットグループ識別子は、検査統計を蓄積するために、受信されたパケットを、特定のパケットグループまたはフローのメンバーとして識別してよい。シーケンス番号は、任意のパケットがロストしたか、順番通りでない順序で受信されたかどうかを決定するために、識別されたパケットグループ内での、受信されたパケットの相対位置を規定してよい。計測ブロックは、その計測ブロックが正確に受信されたことを保証するために、タイムスタンプおよび／またはチェックサム等の他の検査データを含んでよい。
【００３６】
（処理についての記載）
ここで図３を参照すると、データグラム３００は、ヘッダ３１０と、計測ブロック３３０を含むペイロード３２０とを含んでよい。被検査ネットワークを介した送信の間、データグラム３００は、フラグメント３１１および３１２等の２つ以上のフラグメントに分割されてよい。データグラム３００がフラグメントに分割された場合、データグラムのヘッダ３１０はほとんどフラグメント３０１、３０２のヘッダ３１１、３１２にコピーされる。フラグメントのヘッダ３１１、３１２内において特定のフィールドが配置されてよく、元々のデータグラム内の個々のフラグメントの長さおよび個々のフラグメントのペイロードの相対位置を反映してよい。一部の状況においては、共通のトレーラ（図示せず）が、元々のデータグラム３００の終わりから各フラグメント３０１、３０２の終わりにまでコピーされてよい。
【００３７】
データグラム３００のペイロード３２０は、フラグメント３０１、３０２間で分割されてよい。元々のデータグラム３００が図３に示すように単一の計測ブロック３２０を含む場合、その計測ブロックは、フラグメント３０１および３０２の間で分割された部分３００ａ、３３０ｂに分割されてよい。あるいは、データグラム３００内の計測ブロック３３０の位置に依存して、計測ブロック３３０は、フラグメント３０１またはフラグメント３０２に全体としてコピーされてよい。いずれにせよ、単一の計測ブロックを含む元々のデータグラムがフラグメント化された場合、結果としてのフラグメントの一部または全部は完全な計測ブロックを含まない。
【００３８】
データグラムのフラグメントが、検査装置ポートにおいて受信される前に、ネットワーク内で再構成される場合、各フラグメント内での完全な計測ブロックは必要なくてよい。しかしながら、フラグメントは、再構成されることなく、検査装置ポートにおいて受信されてよい。例えば、パケットをフラグメント化するためのネットワークデバイスの機能を確認することを意図した検査は、フラグメントが再構成なしに検査装置によって受信されることを必要としてよい。こうした状況において、各々の元々のデータグラムは、各々のフラグメントが少なくとも１つの完全な計測ブロックを含むように生成されてもよい。
【００３９】
ここで図４を参照すると、フラグメント化を検査するための処理４００は、４０５において開始してよく、ならびに、多量の検査トラフィックが生成された後か、または、オペレータのアクション（図４においては図示せず）によって停止された場合に、４９５において終了してよい。処理４００は、トラフィックジェネレータ２２０等のトラフィックジェネレータを用いてトラフィックを生成すること、および、トラフィックレシーバ２８０等のトラフィックレシーバによってトラフィックを受信することを含んでよい。処理４００は事実上、周期的およびリアルタイムであってよい。図４のフローチャートは、単一のトラフィックジェネレータおよび単一のトラフィックレシーバによって実行されるものとして処理４００を示す。処理４００は、検査セッションの間、複数のトラフィックジェネレータおよびトラフィックレシーバによって、同時に、並行して、実行されてもよいことは理解されるべきである。
【００４０】
処理４００の開始４０５に先立って、検査セッションが設計されていてもよい。検査セッションのデザインは、例えば、ポートユニット２１０等の１つ以上のポートユニットに接続された検査アドミニストレータ２０５等の検査アドミニストレータ計算デバイスを用いるオペレータによってなされてもよい。検査セッションの設計は、ネットワークまたはネットワーク装置のアーキテクチャの決定または定義、検査セッションの間、各ポートユニットによって生成されるストリームの定義、対応のストリーム形成データの生成、および、個々のストリーム形成データの少なくとも１つのポートユニットへの転送を含んでよい。
【００４１】
４１０において、トラフィックジェネレータは、パケットを形成し、送信することによってトラフィックを生成し得る。４１５において、さらなるトラフィックが生成されるべきであるかどうかの決定がなされ得る。この決定は、例えば、送信されるパケットまたはデータグラムの最小数を規定する検査セッションの明細、検査セッションに必要とされる期間、または一部の他の検査セッションの完了基準に基づいてなされてよい。さらなるトラフィックが必要とされない場合、検査セッションは４９５において終了してよい。さらなるトラフィックが生成されるべきである場合、処理は４１０から繰返し得る。４１０および４１５におけるアクションは、説明を簡素化するためにシーケンシャルで示されているが、これらのアクションは同時並行（ｃｏｎｃｕｒｒｅｎｔｌｙ）して実行されてもよい。４１０および４１５におけるアクションは、検査セッションの期間、実質的に継続して繰り返されてよい。
【００４２】
４１０において生成された検査トラフィックは、複数の計測ブロックを含む少なくとも一部のデータグラムを含んでよい。複数の計測ブロックは、データグラムが被検査ネットワーク４９０によってフラグメントに分割された場合、少なくとも１つの完全な計測ブロックが各フラグメントに含まれるように、データグラムに組み込まれてよい。各データグラム内での複数の計測ブロックの処理は、フラグメントのペイロード長が知られているかどうかに依存してよい。
【００４３】
ここで図５を参照すると、データグラム５００は、ヘッダ５１０と、複数の計測ブロック５３０−１、５３０−２を含むペイロード５２０を含んでよい。２つのみの計測ブロック５３０−１、５３０−２が示されているが、データグラムは、３つ以上の計測ブロックを含んでよい。
【００４４】
被検査ネットワークを介した送信の間、データグラム５００は、フラグメント５０１および５０２等の２つ以上のフラグメントに分割されてよい。データグラム５００がフラグメントに分割された場合、フラグメントのヘッダ５１１、５１２は前述したように完了されてよい。データグラム５００のペイロード５２０は、フラグメント５０１、５０２のペイロードの部分間で分割されてよい。フラグメントのペイロードの一部の予期される長さＸが知られている場合、計測ブロック５３０−１、５３０−２は、長さＸと等しい間隔で、ペイロード５２０内に配置されてよい。この場合、各計測ブロック５３０−１、５３０−２は、各フラグメントが１つの完全な計測ブロックを含むように、個々のフラグメント５３１、５３２にコピーされてよい。この場合、データグラムから形成されるフラグメントの数は、フラグメントのペイロード長によって分けられ次の整数の番号に切り上げられるデータグラムのペイロード長に等しい。データグラムにおいて必要とされる計測ブロックの数は、データグラムから形成されるフラグメントの数に等しくてよい。
【００４５】
一部の状況において、フラグメントのペイロード長は、データグラムが生成された場合に、知られていない場合もある。例えば、ネットワークデバイスは、１つ以上の音声または映像ストリームのスケジューリングされたパケット間で送信可能であるフラグメントに、１つの長いデータパケットを変換し得る。この場合、フラグメントのペイロード長は、スケジューリングされたパケット間での利用可能時間に適合するように、ネットワークデバイスによって選択されてもよく、また、一定でなくともよく、あるいは予期可能でなくてもよい。
【００４６】
ここで図６を参照すると、データグラム６００は、ヘッダ６１０と、複数の計測ブロック６３０−１、６３０−２、６３０−３、６３０−４、および６３０−５を含むペイロード６２０を含んでよい。５つの計測ブロック６３０−１から６３０−５が図６の例において示されており、データグラムは、５よりも多いかまたは５未満の計測ブロックを含んでよい。
【００４７】
被検査ネットワークを介した送信の間、データグラム６００は、フラグメント６０１および６０２を含む、２つ以上のフラグメントに分割されてよい。データグラム６００がフラグメントに分割される場合、フラグメントのヘッダ６１１、６１２は前述したように、完了されてもよい。データグラム６００のペイロード６２０は、フラグメント６０１、６０２のペイロードの部分の間で分割されてよく、必要に応じて、他のフラグメント間で分割されてもよい。フラグメントのペイロードの一部の予期される最小の長さＸｍｉｎが知られている場合、計測ブロック６３０−１〜６３０−５は、間隔Ｙで、ペイロード６２０内に配置されてよく、ここでＹはＸｍｉｎの半分未満かＸｍｉｎと等しい。この場合、Ｘｍｉｎと等しいかまたはＸｍｉｎより長いペイロード長を有する各フラグメントは、少なくとも１つの完全な計測ブロックを含むことが保証される。図６の例において、フラグメント６０１は、計測ブロック６３０−１および６３０−２ならびに計測ブロック６３０−３の一部を含む。フラグメント６０２は、計測ブロック６３０−３の一部、計測ブロック６３０−４の全部、および計測ブロック６３０−５の一部を含む。データグラム６００の残りの部分は、１つ以上の追加のフラグメント（図示せず）によって運ばれてよい。各フラグメントが少なくとも１つの完全な計測ブロックを含む一方で、様々なフラグメント内の完全な計測ブロックの位置は予期できないことに留意されたい。
【００４８】
図４に戻って参照すると、図５および／または図６に示すように、複数の計測ブロックを有するデータグラムを含む、４１０で生成された検査トラフィックは、被検査ネットワーク４９０に送信されてよい。検査トラフィックに含まれる少なくとも一部のデータグラムは、被検査ネットワーク４９０内でフラグメントに変換されてよい。フラグメントを含む検査トラフィックは、１つ以上のトラフィックレシーバによって受信されてよい。
【００４９】
各トラフィックレシーバ内で、パケットは、４３０においてシーケンシャルに受信されてよい。４３５において、トラフィックレシーバは、各パケットから、少なくとも１つの計測ブロックを抽出してよい。４３５において、トラフィックレシーバはまた、各受信されたパケットにおいて見出された計測ブロックの数をカウントしてよい。
【００５０】
ここで図７を参照すると、４１０において生成された各パケットまたはデータグラム７００は、１つ以上の計測ブロック７３０−１、７３０−２、７３０−３を含んでよい。計測ブロック７３０−１、−２、−３は、フィルデータ７４０−１、７４０−２、７４０−３によって、隣接していてもよく、または離れていてもよい。フィルデータ７４０−１、−２、−３は、例えば、前述したように、計測ブロック間において必要とされる間隔（ｓｐａｃｉｎｇ）を維持するために、データグラム７００に挿入される、ランダムに生成されるかまたは予め決められたデータであってよい。パケットまたはデータグラムは、図７の例において示す３つの計測ブロックよりも多くても少なくてもよい数を有する。各計測ブロック７３０−１、−２、−３は、受信されたパケット内に計測ブロックを配置するために用いられる署名フィールド７３１を含んでよい。署名フィールド７３１は、予め決められた値を含んでよい。署名フィールド７３１、および従って計測ブロックは、公開されている特許出願ＵＳ２００７／０１１５８３３ Ａ１に記載されているように、予め決められた値と合致するフローティングパターンを行うことによってパケット内に配置されてよい。
【００５１】
各計測ブロック７３０−１、−２、−３は、受信されたパケットを、特定のパケットグループのメンバーとして識別するパケットグループ識別子（ＰＧＩＤ）７３２を含んでよい。各計測ブロックはまた、パケットグループを構成するパケットのシーケンス内のパケットの位置（送信された場合）を示すパケットシーケンス番号７３３を含んでよい。各計測ブロックは、他の検査データ７３７を含んでよく、これはパケットまたはデータグラムの送信時間を示すタイムスタンプを含んでよい。パケットグループ識別子７３２、シーケンス番号７３３、およびタイムスタンプ（もしあれば）の組み合わせは、データグラムを含んで、４１０において送信される各パケットに対して一意であってよい。データグラムが被検査ネットワーク４９０内でフラグメント化されている場合、データグラムのフラグメントは、同じパケットグループ識別子７３２、シーケンス番号７３３、およびタイムスタンプを含んでよい。
【００５２】
各計測ブロック７３０−１、−２、−３は、データグラムのフラグメントの全てが適切に受信されているかどうかを決定することにおいて、パケットレシーバを補助するためのデータを含む１つ以上のフィールドを含んでよい。例えば、データグラム内の計測ブロックは、データグラムのヘッダの後で、計測ブロックから始まり、順番に番号が付けられてよい。各計測ブロックは、個々のシーケンシャル番号を含む計測ブロック番号（ＩＢ番号）フィールド７３４を含んでよい。
【００５３】
ＩＢ番号フィールド７３４の他に、またはそれに加えて、各計測ブロックは、データグラム内の計測ブロックのオフセットを示すＩＢオフセットフィールド７３５を含んでよい。図７の例において、ＩＢオフセットは、データグラム７００のペイロード７２０の開始から、個々の計測ブロックの開始までの、バイトまたは文字での、距離として測定される。この例において、計測ブロック７３０−１についてのＩＢオフセットはゼロであり、計測ブロック７３０−２についてのＩＢオフセットはオフセット２であり、計測ブロック７３０−３についてのＩＢオフセットはオフセット３である。ＩＢオフセットは異なって測定されてよい。例えば、各計測ブロックのＩＢオフセットは、データグラムの開始から、ＩＰヘッダの開始から、または、一部の他の方法において測定されることができる。
【００５４】
各計測ブロック７３０−１、−２、−３は、データグラム内の計測ブロックのトータル数を示すＩＢトータルフィールド７３６を含んでよい。ＩＢトータルフィールド７３６の他に、またはそれに加えて、各計測ブロックは、元々のデータグラムのトータルのペイロード長を規定するトータルペイロード長フィールド（図示せず）を含んでよい。パケットレシーバは、データグラムのフラグメントの全てが受信されたかどうかを決定するために、ＩＢトータルフィールド７３６および／またはトータルペイロード長フィールドを使用してよい。
【００５５】
各計測ブロック７３０−１、−２、−３はまた、パケットレシーバが、計測ブロックが正確に受信されたかどうかを決定できるように、巡回冗長検査（ＣＲＣ）フィールド７３８を含んでよい。ＣＲＣフィールド７３８は、計測ブロックのみにわたって計算されてもよく、または、計測ブロックおよび隣接のフィルデータ７４０−１、−２、−３に亘って計算されてもよい。ＣＲＣフィールド７３８の代わりに、一部の他のフィールド、例えばチェックサムフィールド、パリティフィールド、または誤り訂正符号フィールドが、各計測ブロックの統合を確保するために用いられてもよい。
【００５６】
図４を再び参照すると、計測ブロックが４３５において受信されたパケットから抽出された後、ＰＧＩＤは、計測ブロックから抽出されてよく、対応するパケットグループについて、保存されたフロー統計を検索するために用いられてもよい。検索されたフロー統計は、例えば、受信されたパケットおよびトータルのバイト数、ならびに、順番通りでない順序にて受信されたパケットの数等、パケットグループについての量的な統計を含んでよい。検索されたフロー統計は、パケットグループ内における以前に受信されたパケットのシーケンス番号を含んでもよい。検索されたフロー統計はまた、例えば、最小、平均、および最大のレイテンシー等の時間的な（一時的な）（ｔｅｍｐｏｒａｌ）統計を含んでもよい。
【００５７】
４４５において、４３０において受信されたパケットがフラグメントであるかどうかの決定がなされてもよい。この決定は、４３５において抽出された計測ブロック、４４０において検索されたフロー統計、および／または受信されたパケットのＩＰヘッダに含まれるデータに基づいてなされてよい。例えば、ＩＰｖ４ヘッダは「フラグメント化しない」フラグを含む。このフラグが設定された場合、４３０において受信されたパケットはフラグメントとはなり得ない。さらに例えば、４３５において抽出された計測ブロックは、元々のデータグラムにおける計測ブロックのトータル数、または、元々のデータグラムのペイロードの長さを示すトータル長フィールドを示すＩＢトータルフィールド（図７の７３６）を含んでよい。これらのフィールドは、受信されたパケットがデータグラム全体であるのか、またはフラグメントであるのかどうかを決定するために、受信されたパケットにおいて見出された計測ブロックの数および／または受信されたパケットペイロード長と比較されてよい。４４５における決定は、一部の他の方法においてなされてもよい。
【００５８】
４３０において受信されたパケットがフラグメントではない（すなわち、４４５において受信されたパケットが完全である）という決定が４４５においてなされた場合、対応するパケットグループについてのフロー統計は、完全なパケットが受信されたということを示すために、４５０において更新されてよい。４５０においてフロー統計を更新することは、例えば、受信されたパケットの数のカウントをインクリメントすること、受信されたパケットの長さを受信された累積のトータルバイト数に加えること、必要に応じて順番通りでない順序のパケットのカウントをインクリメントすること、および必要に応じて最小または最大レイテンシータイムを変更することを含んでよい。フロー統計が４５０において更新された後、プロセス４００は４３０に戻ってよく、次のパケットの受信を待機してよい。
【００５９】
４４５において、４３０で受信されたパケットがフラグメントであるという決定がなされた場合、４５５において、受信されたパケットが新たなデータグラムのフラグメントであるのか、「古い」データグラムのフラグメントであるのかどうかの決定がなされてよく、ここでは少なくとももう１つのフラグメントが前もって受信されている。４５５での決定は、例えば、４３５において、受信されたパケットから抽出された計測ブロックに含まれるシーケンス番号と、４４０において検索されたフロー統計に含まれる、以前に受信されたパケット／フラグメントのシーケンス番号とを比較することによってなされてよい。２つのシーケンス番号が同じである場合、４３０において受信されたフラグメントは、少なくとも１つの以前に受信されたフラグメントと同じデータグラムに属する。
【００６０】
４３０において受信されたフラグメントが、少なくとも１つの以前に受信されたフラグメントと同じデータグラムに属するという決定が４５５においてなされた場合（４５５において「ｎｏ」）、対応のパケットグループについてのフロー統計は、特定のフラグメントが受信されたことを示すために、４６０において更新されてよい。例えば、４３５において抽出された計測ブロックは、ＩＢシーケンス番号フィールド（図７における７３４）を含んでよい。この場合、４４０において検索されたフロー統計は、どの計測ブロックが受信されているかを追跡するためのフィールを含んでよい。このフィールドは、対応の計測ブロックが受信されたフラグメントにおいて含まれていることを示すために設定可能である、複数の１ビットのフラグを含んでもよい。さらに例えば、４３５において抽出された計測ブロックはデータグラムについてトータルのペイロード長を含んでもよく、４４０において検索されたフロー統計は累積のペイロード受信フィールドを含んでもよい。この場合、４３０において受信されたフラグメントのペイロード長は、累積のペイロード受信フィールドに加えられてよく、その合計は、データグラム全体が受信されているかどうかを決定するために、トータルのペイロード長と比較されてよい。フロー統計が４６０において更新された後、処理４００は４３０に戻ってよく、次なるパケットの受信を待機してよい。
【００６１】
４３０において受信されたパケットが新たなデータグラムのフラグメントであるという決定が４５５においてなされた場合、以前の「古い」データグラムが完全に受信されたかどうかの決定が４６５においてなされてよい。例えば、４４０において検索されたフロー統計は、対応する計測ブロックが受信されたフラグメントにおいて含まれたことを示すために設定可能である複数のフラグを含んでもよい。この場合、フラグは、４６５において、以前のデータグラムの全ての予期されたフラグメントが受信されたかどうかを決定するために検査されてよい。さらに例えば、４３５において抽出された計測ブロックは、データグラムについてのトータルのペイロード長を含んでよく、４４０において検索されたフロー統計は累積のペイロード受信フィールドを含んでよい。この場合、累積のペイロード受信フィールドおよびトータルのペイロード長は、以前のデータグラム全体が受信されているかどうかを決定するために、４６５において比較されてよい。
【００６２】
以前のデータグラムが完全に受信されたという決定が４６５においてなされた場合、フロー統計は、以前のデータグラムが正確に受信されたことを示し、かつ新たなデータグラムのフラグメントが受信されていることを示すために、４７０において更新されてよい。フロー統計を更新することは、例えば、パケットの数／受信されたデータグラムのカウントをインクリメントすること、以前のデータグラムの長さを受信された累積のトータルのバイト数に加えること、必要であれば、順番通りでない順序のパケットのカウントをインクリメントすること、および、必要に応じて最小または最大のレイテンシータイムを変更することを含んでよい。４７０においてフロー統計を更新することはまた、新たなデータグラムの１つのみのフラグメントが受信されていることを示すために複数のフラグをリセットすること、および／または、新たなデータグラムのフラグメントのペイロード長と等しくなるように累積のペイロード受信フィールドを設定することを含んでよい。フロー統計が４７０において更新された後、処理４００は４３０に戻ってよく、次のパケットの受信を待機してよい。
【００６３】
以前のデータグラムが完全に受信されていないという決定が４６５においてなされた場合、フロー統計は、以前のデータグラムが正確に受信されていないことを示すために、かつ新たなデータグラムのフラグメントが受信されていることを示すために、４７５において更新されてよい。フロー統計を更新することは、例えば、失われたフラグメントを有するデータグラムの数のカウントをインクリメントすることを含んでもよい。４７５においてフロー統計を更新することはまた、新たなデータグラムの１つのみのフラグメントが受信されていることを示すために複数のフラグをリセットすること、および／または、新たなデータグラムのフラグメントのペイロード長と等しくなるように累積のペイロード受信フィールドを設定することを含んでよい。フロー統計が４７５において更新された後、処理４００は４３０に戻ってよく、次のパケットの受信を待機してよい。
【００６４】
図４に示されてはいないが、以前のデータグラムが正確に受信されていないという決定が４６５においてなされた場合、さらなる分析のために、以前のデータグラムのフラグメントを含む、以前に受信されたパケットをセーブするためにキャプチャ操作（ｃａｐｔｕｒｅ ｏｐｅｒａｔｉｏｎ）がトリガされてもよい。
【００６５】
図８をここで参照すると、再構成を検査するために、処理８００は８０５において開始してよく、大量の検査トラフィックが生成された後で、または、オペレータのアクション（図８には図示せず）によって停止された場合に、８９５において終了してよい。処理８００は、トラフィックジェネレータ２２０等のトラフィックジェネレータを用いてトラフィックを生成すること、およびトラフィックレシーバ２８０等のトラフィックレシーバによってトラフィックを受信することを含んでよい。処理８００は、事実上、周期的およびリアルタイムであってよい。図８のフローチャートは、単一のトラフィックジェネレータおよび単一のトラフィックレシーバによって実行されるものとして処理８００を示す。処理８００は、検査セッションの間、複数のトラフィックジェネレータおよびトラフィックレシーバによって、同時に、並行して、実行されてもよいことは理解されるべきである。
【００６６】
処理８００の開始８０５に先立って、検査セッションが設計されていてもよい。検査セッションのデザインは、例えば、ポートユニット２１０等の１つ以上のポートユニットに接続された検査アドミニストレータ２０５等の検査アドミニストレータ計算デバイスを用いるオペレータによってなされてもよい。検査セッションの設計は、ネットワークまたはネットワーク装置のアーキテクチャの決定または定義、検査セッションの間、各ポートユニットによって生成されるストリームの定義、対応のストリーム形成データの生成、および、個々のストリーム形成データの少なくとも１つのポートユニットへの転送を含んでよい。
【００６７】
８１０において、トラフィックジェネレータは、被検査ネットワーク１９０によって再構成される少なくとも一部のフラグメントを含むパケットを形成し、送信することによって検査トラフィックを生成し得る。８１５において、さらなるトラフィックが生成されるべきであるかどうかの決定がなされ得る。この決定は、例えば、送信されるパケットまたはフラグメントの最小数を規定する検査セッションの明細、検査セッションに必要とされる期間、または一部の他の検査セッションの完了基準に基づいてなされてよい。さらなるトラフィックが必要とされない場合、検査セッションは８９５において終了してよい。さらなるトラフィックが生成されるべきである場合、処理は８１０から繰返し得る。８１０および８１５におけるアクションは、説明を簡素化するためにシーケンシャルで示されているが、これらのアクションは同時並行（ｃｏｎｃｕｒｒｅｎｔｌｙ）して実行されてもよい。８１０および８１５におけるアクションは、検査セッションの期間、実質的に継続して繰り返されてよい。
【００６８】
８１０において生成された検査トラフィックは、再構成される少なくとも一部のフラグメントを含んでよい。ここで図９を参照すると、各々のフラグメントのパケット９００は、ヘッダ部分９１０、および計測ブロック９３０を含むペイロード部分９２０を含んでよい。計測ブロック９３０は、全て図７に関連して以前に記載されているように、署名フィールド９３１、ＰＧＩＤフィールド９３２、シーケンス番号フィールド９３３、他の検査データ９３８、およびＣＲＣフィールド９３９を含んでよい。署名フィールド９３１、ＰＧＩＤフィールド９３２、およびシーケンス番号フィールド９３３は、単一のデータグラムに組み合わされるために、全てのフラグメントに対して同じであってよい。
【００６９】
計測ブロック９３０はまた、各々のフラグメントが再構成されたデータグラム内に配置されるべき位置を示すフィールドを含んでよい。例えば、各々のフラグメントの計測ブロック９３０は、再構成されたデータグラムを構成する一連のフラグメントにおけるフラグメントの予期される位置を示すフラグメント番号フィールド９３４を含んでもよい。各々のフラグメントの計測ブロック９３０は、再構成されたデータグラム内の参照点に対して、フラグメントの予期された位置を示すフラグメントオフセットフィールド９３４を含んでよい。フラグメントオフセットは、例えば、データグラムのペイロードの開始から（図７に示すように）、データグラムの開始から、ＩＰヘッダの開始から、または一部の他の方法において、バイトにて、測定されてよい。
【００７０】
計測ブロック９３０はまた、どのくらい多くのフラグメントが完全な再構成されたデータグラム内に予期されるかを示すフィールドを含んでもよい。例えば、各フラグメントの計測ブロック９３０は、完全な再構成されたデータグラムを構成するのに必要とされるフラグメントのトータルの数を示すフラグメントトータルフィールド９３６を含んでもよい。各フラグメントの計測ブロック９３０は、再構成されたデータグラムの予期されるトータルのペイロード長を示すペイロードトータルフィールド９３７を含んでよい。
【００７１】
図８に戻ると、８１０にて生成された検査トラフィックは、フラグメントを含んで、被検査ネットワーク８９０に送信されてよい。少なくとも一部のデータグラムは、被検査ネットワーク８９０により、検査トラフィックに含まれるフラグメントから再構成されてよい。検査トラフィックは、再構成されたデータグラムを含んで、１つ以上のトラフィックレシーバにより受信されてよい。
【００７２】
各トラフィックレシーバ内で、パケットは、８３０において、シーケンシャルに受信されてよい。８３５において、トラフィックレシーバは、各パケットから、１つ以上の計測ブロックを抽出してよい。８３５において、トラフィックレシーバは、各々受信されたパケットにおいて見出された全ての計測ブロックの一部または全てを抽出してよい。
【００７３】
１つ以上の計測ブロックが８３５において、受信されたパケットから抽出された後、ＰＧＩＤは、１つの計測ブロック（例えば、複数の計測ブロックが８３５で抽出される場合はその最初の計測ブロック）から抽出されてよく、８４０において、対応のパケットグループについて、保存されたフロー統計を検索するために用いられてよい。８４０において検索されたフロー統計は、例えば、受信されたパケットの数およびトータルのバイト数、ならびに順番通りでない順序で受信されたパケットの数等、パケットグループについての量的な統計を含んでよい。検索されたフロー統計は、パケットグループ内において以前に受信されたパケットのシーケンス番号を含んでよい。検索されたフロー統計はまた、例えば、最小、平均、最大レイテンシー等の時間的な（一時的な）統計を含んでもよい。
【００７４】
８４５において、８３０で受信されたパケットが、２つ以上のフラグメントから再構成されたデータグラムであるかどうかの決定がなされてもよい。この決定は、８３５において抽出された計測ブロックに含まれるデータに基づいてなされてよい。例えば、８３５において抽出された計測ブロックが、計測ブロックの予期されるトータルの数が１であることを示すＩＢトータルフィールドを含む場合、受信されたパケットは再構成されたデータグラムではない。
【００７５】
８３０において受信されたパケットが再構成されたデータグラムではないという決定が８４５においてなされた場合、対応するパケットグループについてのフロー統計は、完全なパケットが受信されたということを示すために、８５０において更新されてよい。８５０においてフロー統計を更新することは、例えば、受信されたパケットの数のカウントをインクリメントすること、受信されたパケットの長さを受信された累積のトータルバイト数に加えること、必要に応じて順番通りでない順序のパケットのカウントをインクリメントすること、および必要に応じて最小または最大レイテンシータイムを変更することを含んでよい。フロー統計が８５０において更新された後、プロセス８００は８３０に戻ってよく、次のパケットの受信を待機してよい。
【００７６】
８３０において受信されたパケットが再構成されたデータグラムであるという決定が８４５においてなされた場合、フラグメントの予期された数が、被検査ネットワーク１９０により再構成されるように、データグラムに組み込まれたかどうかの決定が８５５においてなされてよい。８５５における決定は、例えば、８３５において抽出される計測ブロックの数と、予期されるフラグメントの数を示すフラグメントトータルフィールド（図９における９３６）とを比較することによってなされてよい。８５５における決定は、８３０において受信されるパケットペイロード長と、再構成されたデータグラムの予期されるペイロード長を示すペイロードトータルフィールド（図９における９３７）とを比較することによってなされてよい。８５５において、８３５で抽出された複数の計測ブロックもまた計測ブロック内のＰＧＩＤとシーケンス番号とが各々等しいことを比較されてよい。ＰＧＩＤおよび／またはシーケンス番号が、全ての計測ブロックにおいて等しくない場合、８３０において受信されたパケットは、２つ以上のデータグラムのフラグメントから再構成されていてよい。
【００７７】
８５５において、４３０で受信されたデータグラムが予期されるフラグメントの数を含まないか、または、２つ以上のデータグラムからのフラグメントを含むという決定がなされた場合、対応のパケットグループについてのフロー統計は、不正確に再構成されたデータグラムが受信されたことを示すために、９６０において更新されてよい。フロー統計が８６０において更新された後、処理８００は８３０に戻ってよく、次のパケットの受信を待機してよい。
【００７８】
８３０において受信されたデータグラムが予期されるフラグメントの数を含むという決定が８５５においてなされた場合、フラグメントが正確な順序にて再構成されたかどうかの決定がなされてよい。例えば、８６５において、８３５で抽出された各計測ブロック内のフラグメント番号フィールド（図９における９３４）および／またはフラグメントオフセットフィールド（図９における９３５）は、計測ブロックが再構成されたデータグラムにおいて正確に順序付けされたかどうかを決定するために比較されてよい。
【００７９】
８６５において、８３０において受信されたデータグラムが、データグラム内において正確なシーケンスとなっていない１つ以上のフラグメントを含むという決定がなされた場合、フロー統計は、不正確な再構成データグラムが受信されたことを示すために、８６０において更新されてよい。８６５において、８３０で受信されたデータグラムが、データグラム内で正確なシーケンスで、予期されたフラグメントの全てを有するという決定がなされた場合、フロー統計は、正確に再構成されたデータグラムが受信されたことを示すために、８７０において更新されてよい。フロー統計が８６０または８７０において更新された後、処理８００は８３０に戻ってよく、次のパケットの受信を待機してよい。
【００８０】
図８には図示されていないが、受信されたデータグラムが不正確に再構成されたという決定が８５５または８６５においてなされた場合、キャプチャ操作がトリガされてよく、さらなる分析のために、不正確に再構成されたデータグラムを含む、以前に受信されたパケットを保存してよい。
【００８１】
（終わりに）
本記載全体を通して、示された実施形態および例は、開示された、または特許請求の範囲において請求された装置および手順についての限定ではなく、典型例として想定されるべきものである。本明細書において提示された例の多くは、方法の作用またはシステムの要素の特定の組合せに関連するものであるけれども、それらの作用およびそれらの要素は、他の方法において、組み合わされてよく、同じ課題を達成するものとして理解されるべきである。フローチャートに関して、追加の工程および工程の削減もまた考慮されてよく、図示した工程は、本明細書において記載された方法を達成するために組み合わされてもよく、またはさらに改良されてもよい。１つの実施形態のみに関連して記載された作用、要素、および特徴は、他の実施形態における同様の役割から排除されることは意図されていない。
【００８２】
本明細書において用いられるように、「複数」とは、２つ以上を意味する。本明細書において用いられるように、「一連の」物品とは、１つ以上のそのような物品を含み得る。本明細書において用いられるように、明細書の記載または特許請求の範囲の請求項においては、用語「含む、備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む、備える（ｉｎｃｌｕｄｉｎｇ）」「運ぶ、有する、持つ（ｃａｒｒｙｉｎｇ）」、「有する（ｈａｖｉｎｇ）」、「含む（ｃｏｎｔａｉｎｉｎｇ）」、「含む、関する、関連する（ｉｎｖｏｌｖｉｎｇ）」等は、オープンエンド型、すなわち、含むがそれらに限定されないということを意味することは理解されるべきである。「〜からなる」および「〜から実質的になる」といった移行句の各々のみが、特許請求の範囲の請求項に関しては、クローズ型、または半クローズ型の移行句である。請求項の要素を変更するために、特許請求の範囲の請求項における「第１」、「第２」、「第３」等の序数の用語の使用は、それ自体では、任意の優先順位、優位性、またはある請求項の要素が他のものより先であったり、または、ある方法の作用が行われる時間的順序等を含意せず、請求項の要素を区別するために、特定の名前を有するある請求項の要素から、同じ名前を有する別の要素を区別するためのラベルとして（順序を示す用語の使用を別にして）単に用いられる。本明細書において用いられるように、「および／または」は、リストアップされた物品が二者択一であることを意味するが、そうした二者択一もまた、そうしてリストアップされた物品の任意の組合せを含むものである。
【技術分野】
【０００１】
（著作権およびトレードドレスについての通知）
本特許文献の開示の一部は著作権保護に対象となるマテリアルを含む。本特許文献は、保有者のトレードドレスである、またはトレードドレスとなり得る事柄を示し、および／または記載する場合がある。著作権およびトレードドレスの保有者は、いかなる者であっても米国特許商標局の書類または記録の通りに本特許開示を複製する限りで、異議を申し立てるものではないが、その他の場合には、いかなる場合であっても全ての著作権およびトレードドレスの権利を保留するものである。
【０００２】
本出願は、本出願と同日に出願されたＴＥＳＴＩＮＧ ＦＲＡＧＭＥＮＴ ＲＥＡＳＳＥＭＢＬＹ（フラグメントの再構成の検査）と題された同時係属中の特許出願に関連する。
【０００３】
本開示は、ネットワークまたはネットワークデバイスを検査することに関する。
【背景技術】
【０００４】
多くのタイプの通信ネットワークにおいて、送信される各メッセージは固定長または可変長の部分へと分割される。各々の部分は、情報のパケット、フレーム、セル、データグラム、データ単位、または他の単位と呼ばれる場合があり、それらの全ては、本明細書において、パケットとして参照される。
【０００５】
各パケットは、通常、パケットペイロードと呼ばれる元のメッセージの一部を含む。パケットペイロードはデータを含んでよく、あるいは、音声情報またはビデオ情報を含んでもよい。パケットペイロードはまた、ネットワーク管理および制御情報を含んでもよい。さらに、各パケットは、通常、パケットヘッダと呼ばれる識別およびルーティング情報を含む。パケットはネットワークを通じて複数のスイッチまたはノードを介して個々に送信される。パケットは、目的とするデバイスまたはエンドユーザにメッセージが配信される前に、パケットヘッダに含まれる情報を用いて最終的な送り先または中間の送り先にてメッセージに再構築される。受信側において、その再構築されたメッセージは、ユーザの装置に適合するフォーマットでエンドユーザに送られる。
【０００６】
メッセージをパケットとして送信する通信ネットワークは、パケット交換ネットワークと呼ばれる。パケット交換ネットワークは、通常、ハブまたはノードで交差する送信パスのメッシュを含む。ノードの少なくとも一部は、ノードに到着するパケットを受け取り、適切な発信パスに沿ってパケットを再送信するスイッチングデバイスまたはルータを備えてよい。パケット交換ネットワークは、業界標準のプロトコルのレイヤ別の構造によって制御される。その構造のレイヤ１、２、および３は各々、物理レイヤ、データリンクレイヤ、およびネットワークレイヤである。
【０００７】
レイヤ１のプロトコルは、ネットワークのノード間での物理的な（電気的、光学的、または無線の）インターフェースを規定する。レイヤ１のプロトコルは、イーサネット（登録商標）の物理的コンフィグレーション、ＳＯＮＥＴ（同期光学的ネットワーク）、および他の光学接続プロトコル、ならびに、ＷｉＦｉ（登録商標）等の様々な無線プロトコルを含む。
【０００８】
レイヤ２のプロトコルは、データがネットワークのノード間を論理的に転送される方法を制御する。レイヤ２のプロトコルは、イーサネット（登録商標）、ＡＴＭ（非同期転送モード）、フレームリレー、およびＰＰＰ（ポイント・ツー・ポイント・プロトコル）を含む。
【０００９】
レイヤ３のプロトコルは、ネットワークの複数のノードを接続するパスに沿ってソースから送り先へパケットがルーティングされる方法を制御する。主要なレイヤ３のプロトコルは周知のインターネットプロトコルバージョン４（ＩＰｖ４）およびバージョン６（ＩＰｖ６）である。パケット交換ネットワークは、イーサネット（登録商標）、ＡＴＭ、ＦＲ、および／またはＰＰＰのレイヤ２のプロトコルの混合体を用いてＩＰパケットをルーティングする必要がある場合もある。ネットワークのノードの少なくとも一部は、各パケット内に含まれるネットワークレイヤヘッダから、送り先アドレスを抽出するルータを備えてもよい。ルータは次いで、パケットが再送信されるべきルートまたはパスを決定するために送り先アドレスを用いる。通常のパケットは複数のルータを通過してよく、それらのルータの各々は送り先アドレスを抽出する行為およびそのパケットが再送信されるべきルートまたはパスを決定する行為を繰り返す。
【００１０】
ＩＰｖ４およびＩＰｖ６レイヤ３のプロトコルもまた、パケットのフラグメント化および再構成を提供する。ネットワークデバイスは、元々のパケットを２つ以上のより短いパケットにフラグメント化し得て、そうしたパケットはその後、一部の他のネットワークデバイスによって元々のパケットに再構成され得る。パケットのフラグメント化および再構成は、例えば、ネットワーク内のデバイスまたはパスが、元々のパケットよりも、より短い最大許容パケット長を有する場合に必要となり得る。パケットのフラグメント化および再構成はまた、長いデータパケットを、周期的にスケジューリングされた音声または映像のパケット間で送信可能であるフラグメントに分割するために用いられ得る。ＩＰｖ４の用語体系を踏まえれば、フラグメント化される元々のパケットは、本明細書において、「データグラム」と呼ばれる。各データグラムは複数の「フラグメント（断片）」に分割され得る。データグラムおよびフラグメントの両方は、前述で規定されたようにパケットであることに留意されたい。
【００１１】
パケット交換ネットワーク、またはパケット交換通信ネットワーク内に含まれるデバイスを検査するために、多数のパケットを含んだ検査トラフィックが生成され、１つ以上のポートにおいてネットワークに送信され、かつ異なるポートにおいて受信されてよい。検査トラフィック内の各パケットは、特定の送り先ポートでの受信を意図したユニキャストのパケット、あるいは、１つ以上の送り先ポートでの受信を意図する場合もあるマルチキャストのパケットであってもよい。これに関連して、用語「ポート」とは、ネットワークと、そのネットワークを検査するために用いられる装置との間の通信接続のことをいう。用語「ポートユニット」とは、ポートにおいて、ネットワークに接続するネットワーク検査装置内のモジュールのことをいう。受信された検査トラフィックは、ネットワークのパフォーマンスを測定するために分析され得る。ネットワークに接続された各ポートユニットは、検査トラフィックのソースおよび検査トラフィックの送り先の両方であってよい。各ポートユニットは、複数の論理ソースまたは送り先アドレスをエミュレートしてよい。
【００１２】
単一のポートユニットから発せられ、特定のタイプのパケットおよび特定のレートを有する一連のパケットを、本明細書において、「ストリーム」と呼ぶ。ソースポートユニットは、例えば、複数のパケットタイプ、レート、または送り先を含むため、複数の発信ストリームを同時にかつ並行してサポートし得る。「同時に（ｓｉｍｕｌｔａｎｅｏｕｓｌｙ）」とは「正確に同一時間に」を意味する。「並行して（ｃｏｎｃｕｒｒｅｎｔｌｙ）」とは、「同一時間内で」を意味する。
【００１３】
検査データを収集する目的のために、検査トラフィックはパケットグループに分けられてよく、ここで「パケットグループ」とは、ネットワークトラフィック統計が蓄積される任意の複数のパケットである。所与のパッケトグループ内のパケットは、各パケット内に含まれるパケットグループ識別子（ＰＧＩＤ）によって識別され得る。ＰＧＩＤは、例えば、専用識別子フィールドまたは各パケット内の２つ以上のフィールドの組み合わせであってもよい。
【００１４】
ネットワークトラフィックデータを報告する目的のために、検査トラフィックが、フローとして編成されてもよく、ここで、「フロー」とは、ネットワークトラフィック統計を報告する任意の複数のパケットのことである。各フローは、単一のパケットグループまたは少数のパケットグループからなってもよい。各パケットグループは、一般に、単一のフローに属してもよい。
【００１５】
本記述において、用語「エンジン」は、記述した機能を実行するハードウェアの集合体を意味し、これはファームウェアおよび／またはソフトウェアによって増強することができる。エンジンは、通常、主に機能的な用語においてエンジンを定義するハードウェア記述言語（ＨＤＬ）を用いて設計され得る。このようなＨＤＬ設計は、ＨＤＬシュミレーションツールを用いて検証され得る。次に、検証されるＨＤＬ設計は、一般に「合成」と呼ばれるプロセスにおいてゲートネットリストまたは他のエンジンの物理的な記述に変換され得る。この合成は、合成ツールを用いて自動的に行うことができる。ゲートネットリストまたは他の物理的な記述は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックデバイス（ＰＬＤ）、またはプログラマブルロジックアレイ（ＰＬＡ）のようなプログラム可能なハードウェアデバイスにおいてエンジンを実装するためのプログラミングコードにさらに変換され得る。ゲートネットリストまたは他の物理的な記述は、エンジンを特定用途向け集積回路（ＡＳＩＣ）内にて製造するためのプロセス命令およびマスクに変換され得る。
【００１６】
本記載において、用語「ロジック」はまた、「エンジン」よりも、より小さなスケールであり得る記載された機能を実行するハードウェアの集合体を意味する。「ロジック」は、組み合わせ論理回路、フリップフロップ、レジスタ、および他のデータ保存要素を含み得るシーケンシャル論理回路、ならびに、有限状態機械等の複合シーケンシャル論理回路を含む。
【００１７】
本記載において、「ユニット」はまた、ファームウェアおよび／またはソフトウェアによって増強し得る、「エンジン」よりも、より大きなスケールであり得る、ハードウェアの集合体を意味する。例えば、ユニットは複数のエンジンであって、それらのエンジンの一部が並行して類似の機能を実行し得る。用語「ロジック」、「エンジン」、および「ユニット」は、任意の物理的な分離または境界区分の意味を含まない。１つ以上のユニットおよび／またはエンジンの全てまたは一部は、例えばネットワークカードまたはブレード等の一般的なカード上、あるいは一般的なＦＰＧＡ、ＡＳＩＣ内、または他の回路デバイス内で配置されてよい。
【図面の簡単な説明】
【００１８】
【図１】ネットワーク環境のブロック図である。
【図２】ネットワークカードのブロック図である。
【図３】パケットのフラグメント化のグラフィック図である。
【図４】パケットのフラグメント化を検査するための方法のフローチャートである。
【図５】パケットのフラグメント化のグラフィック図である。
【図６】パケットのフラグメント化のグラフィック図である。
【図７】計測ブロックのグラフィック図である。
【図８】パケット再構成を検査するための方法のフローチャートである。
【図９】計測ブロックのグラフィック図である。
【発明を実施するための形態】
【００１９】
本記載全体を通じて、ブロック図に表される要素は、３桁の参照番号が割り当てられ、最上位桁はその要素が示されている図面の番号であり、下位２つの桁は要素に特定されるものである。ブロック図に関連して記載されない要素は、同じ参照番号を有する前述された要素として同じ特徴および機能を有するものとみなされてよい。
【００２０】
ブロック図において、矢印で終端している線は、信号というよりはデータパスを示し得る。各データパスはビット幅において多数ビットであってよい。例えば、各データパスは、４、８、１６、６４、２５６、あるいはそれ以上の並列接続からなっていてもよい。
【００２１】
（装置の記載）
図１はネットワーク環境のブロック図を示す。ネットワーク環境は、ネットワーク検査装置１００、および１つ以上のネットワークデバイス１９２を含むネットワーク１９０を備えてよい。
【００２２】
ネットワーク検査装置１００は、ネットワーク検査デバイス、パフォーマンスアナライザ、適合性確認システム、ネットワークアナライザ、またはネットワーク管理システムであってよい。ネットワーク検査装置１００は、１つ以上のネットワークカード１０６、およびシャーシ１０２内に含まれるかまたは包囲されたバックプレーン１０４を備えてよい。シャーシ１０２は、ネットワーク検査装置を含むのに適した固定型または可搬型のシャーシ、キャビネット、または筐体であってよい。ネットワーク検査装置１００は図１に示すように一体化されたユニットであってよい。あるいは、ネットワーク検査装置１００は、トラフィックの生成および／または分析を提供するように協動する複数の別個のユニットを備えてよい。ネットワーク検査装置１００およびネットワークカード１０６は、例えば様々なイーサネット（登録商標）およびファイバーチャネル標準等の１つ以上の周知の規格またはプロトコルをサポートしてよく、かつ専用のプロトコルもサポートしてよい。
【００２３】
ネットワークカード１０６は、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、プロセッサ、および他の種類のデバイスを含んでよい。ネットワークカード１０６は、例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理デバイス（ＰＬＤ）、プログラマブル論理アレイ（ＰＬＡ）等の１つ以上のプログラム可能ハードウェアデバイスを含んでよい。さらに、ネットワークカード１０６は、ソフトウェアおよび／またはファームウェアを含んでよい。用語、ネットワークカードは、ラインカード、テストカード、分析カード、ネットワークラインカード、ロードモジュール、インターフェースカード、ネットワークインターフェースカード、データインターフェースカード、パケットエンジンカード、サービスカード、スマートカード、スイッチカード、リレーアクセスカード等を含む。用語、ネットワークカードはまた、複数のプリント回路基板を含み得るモジュール、ユニット、およびアセンブリを含む。各ネットワークカード１０６は１つ以上のポートユニット１１０を含み得る。各ポートユニット１１０は、１つ以上のポートを介してネットワーク１９０に接続し得る。ポートユニット１１０は、通信媒体１９５を介してネットワーク１９０に接続されてよく、この通信媒体１９５は、ワイヤ、光ファイバ、無線リンク、または他の通信媒体であってよい。各ネットワークカード１０６は、単一の通信プロトコルをサポートしてよく、複数の関連のプロトコルをサポートしてよく、または、複数の関連のないプロトコルをサポートしてもよい。ネットワークカード１０６は、ネットワーク検査装置１００内に恒久的に設置されていてもよく、または着脱自在であってもよい。
【００２４】
バックプレーン１０４は、ネットワークカード１０６のために、バスまたは通信媒体として機能してよい。バックプレーン１０４はまた、電極をネットワークカード１０６に提供し得る。
【００２５】
ネットワークデバイス１９２は、ネットワーク１９０を介しての通信を可能にする任意のデバイスであってよい。ネットワークデバイス１９２は、ワークステーション、パーソナル・コンピュータ、サーバ、ポータブル・コンピュータ、携帯情報端末（ＰＤＡ）、コンピューティング・タブレット、セル式電話／携帯電話、イーメール用装置等のコンピューティングデバイス、プリンタ、スキャナ、ファクシミリ装置等の周辺機器、ネットワーク接続ストレージ（ＮＡＳ）およびストレージ・エリア・ネットワーク（ＳＡＮ）のデバイス等のディスクドライブを含むネットワーク対応のストレージデバイス、ルータ、リレー、ハブ、スイッチ、ブリッジ、およびマルチプレクサ等のネットワーキング・デバイスであってよい。さらに、ネットワークデバイス１９２は、ネットワークを通じて通信することができる家庭電化器具、アラームシステムおよび他の任意のデバイスまたはシステムを含んでもよい。
【００２６】
ネットワーク１９０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ストレージエリアネットワーク（ＳＡＮ）、有線、無線、またはこれらの組み合わせであってもよく、インターネットを含んでもよく、またはインターネットであってもよい。ネットワーク１９０上の通信は、情報のフレーム、セル、データグラム、パケットまたは他の単位を含む様々な形態をとってもよく、本明細書においては、それらの全てをパケットと称する。ネットワーク検査装置１００およびネットワークデバイス１９２は、同時に相互に通信してもよく、ネットワーク検査装置１００と所与のネットワークデバイス１９２との間には、複数の論理的通信経路があってもよい。ネットワークそのものは、移動するデータのための多数の物理的経路および論理的経路を提供する多数のノードから成ってもよい。各ポートユニット１１０は、特定の通信媒体１９５を介して、ネットワークデバイス１９２上の対応のポートに接続されてもよい。
【００２７】
ここで図２を参照し、例示的なポートユニット２１０は、ポートプロセッサ２１２と、トラフィックジェネレータユニット２２０と、トラフィックレシーバユニット２８０と、ポートユニット２１０を被検査ネットワーク２９０に接続するネットワークインターフェースユニット２７０とを備えてもよい。ポートユニット２１０は、ネットワークカード（例えばネットワークカード１０６）のすべてまたは一部であってもよい。被検査ネットワーク２９０は、ネットワークデバイス１９４等の１つ以上のネットワークデバイス、および／または、ネットワーク１９０等のネットワークの全てまたは一部であってもよい。
【００２８】
ポートプロセッサ２１２は、本明細書に記載される機能および特徴を提供するための、プロセッサ、プロセッサに接続されたメモリ、および様々な特殊化された装置、回路、ソフトウェアおよびインターフェースを含んでもよい。プロセス、機能および特徴は、全体的にあるいは部分的に、プロセッサ上で動作するソフトウェアにおいて実現されてもよく、ファームウェア、アプリケーションプログラム、アプレット（例えばＪａｖａ（登録商標）アプレット）、ブラウザプラグイン、ＣＯＭオブジェクト、ダイナミックリンクライブラリ（ＤＬＬ）、スクリプト、１つ以上のサブルーチン、またはオペレーティングシステムのコンポーネントまたはサービスという形をとってもよい。ハードウェアおよびソフトウェアおよびそれらの機能は、一部の機能がプロセッサによって実行され、他の機能が他の装置によって実行されるように、分散型であってもよい。
【００２９】
ポートプロセッサ２１２は、オペレータインターフェース２０７に接続し得る検査アドミニストレータ２０５と通信してもよい。検査アドミニストレータ２０５は、ネットワーク検査装置１００の内部に収容されるコンピューティングデバイスまたは外部のコンピューティングデバイスであってもよい。検査アドミニストレータ２０５は、ポートユニットがネットワーク２９０の検査に関与するために必要とされる命令およびデータを、ポートプロセッサ２１２に提供してもよい。検査アドミニストレータ２０５から受信される命令およびデータは、例えば、ポートユニット２１０によって生成されるパケットストリームの定義、およびポートユニット２１０によって蓄積および報告され得るパフォーマンス統計の定義を含んでもよい。
【００３０】
ポートプロセッサ２１２は、トラフィックジェネレータユニット２２０にストリーム形成データ２１４を提供して、複数のストリームを形成させる。ストリーム形成データ２１４は、例えば、パケットのタイプ、送信の周波数、パケット内部の固定内容フィールドおよび可変内容フィールドの定義、および各パケットストリームのための他の情報を含んでもよい。トラフィックジェネレータユニット２２０は、次いで、ストリーム形成データ２１４に従って複数のストリームを生成してよい。複数のストリームは、発信検査トラフィック２３５を形成するためにインターリーブされてよい。各々のストリームは、パケットのシーケンスを含んでよい。各ストリーム内のパケットは、同じ一般的な種類であってもよく、長さおよびコンテンツが異なっていてもよい。
【００３１】
ネットワークインターフェースユニット２７０は、トラフィックジェネレータユニット２２０からの発信検査トラフィック２３５を、ワイヤ、光ファイバ、無線リンク、または他の通信リンクであり得るリンク２９５を介して、被検査ネットワーク２９０へと検査トラフィックを送信するように要求される、電気的、光学的、または無線による信号フォーマットに変換してよい。同様に、ネットワークインターフェースユニット２７０は、ネットワークからリンク２９５を介して電気的、光学的、または無線による信号を受信してよく、かつ、トラフィックレシーバユニット２８０に対して利用可能なフォーマットに、着信する検査トラフィック２７５に受信される信号を変換してよい。
【００３２】
トラフィックレシーバユニット２８０は、ネットワークインターフェースユニット２７０から着信検査トラフィック２７５を受信してよい。トラフィックレシーバユニット２８０は、各受信パケットが特定のフローのメンバーであるかを決定し得、また、ポートプロセッサ２１２から提供された検査命令２１８に従って各フローに関する検査統計を蓄積し得る。蓄積された検査統計は、例えば、受信パケットの合計数、順番通りでない順序にて（ｏｕｔ−ｏｆ−ｓｅｑｕｅｎｃｅ）受信されたパケットの数、エラーを有する受信パケットの数、最大、平均および最小の伝搬遅延、および各フローの他の統計を含んでもよい。トラフィックレシーバユニット２８０はまた、検査命令２１８に含まれる取得基準に従って、特定のパケットを取得および格納してもよい。トラフィックレシーバユニット２８０は、検査セッションの最中または後におけるさらなる分析のために、検査統計および／または取得パケット２８４を、検査命令２１８に従って、ポートプロセッサ２１２に提供してもよい。
【００３３】
発信検査トラフィック２３５および着信検査トラフィック２７５は、主にステートレスであってもよい。すなわち、発信検査トラフィック２３５は、応答を予期することなく生成されてもよく、着信検査トラフィック２７５は、応答を意図することなく受信されてもよい。しかしながら、ステートフル、すなわち双方向的な通信の一部が、検査セッションの間、ポートユニット２１０とネットワーク２９０との間において必要とされるか、または所望され得る。例えば、トラフィックレシーバユニット２８０は、検査セッションを制御するのに必要なデータを含む制御パケットを受信してもよく、この制御パケットは、確認または応答を送信するためにポートユニット２１０を必要とする。
【００３４】
トラフィックレシーバユニット２８０は、着信検査トラフィックから着信制御パケットを分離させてよく、着信制御パケット２８２をポートプロセッサ２１２へとルーティングしてよい。ポートプロセッサ２１２は、各制御パケットのコンテンツを抽出し得て、１つ以上の発信制御パケット２１６の形で適切な応答を生成し得る。発信制御パケット２１６は、トラフィックジェネレータユニット２２０に提供され得る。トラフィックジェネレータユニット２２０は、発信制御パケット２１６を発信検査トラフィック２３５に挿入し得る。
【００３５】
トラフィックジェネレータ２２０によって生成された各パケットは、検査データブロックとも呼ばれる少なくとも１つの計測（インストルメンテーション）ブロックを含んでよく、計測ブロックは、被検査ネットワークのパフォーマンスにアクセスするのに必要な情報を含む。例えば、計測ブロックは、署名フィールド、パケットグループ識別子、およびシーケンス番号を含んでよい。署名フィールドは、受信されたパケットを検査パケットとして識別してよく、かつそのパケットを用いて計測ブロックの位置を決定するために用いられてもよい。パケットグループ識別子は、検査統計を蓄積するために、受信されたパケットを、特定のパケットグループまたはフローのメンバーとして識別してよい。シーケンス番号は、任意のパケットがロストしたか、順番通りでない順序で受信されたかどうかを決定するために、識別されたパケットグループ内での、受信されたパケットの相対位置を規定してよい。計測ブロックは、その計測ブロックが正確に受信されたことを保証するために、タイムスタンプおよび／またはチェックサム等の他の検査データを含んでよい。
【００３６】
（処理についての記載）
ここで図３を参照すると、データグラム３００は、ヘッダ３１０と、計測ブロック３３０を含むペイロード３２０とを含んでよい。被検査ネットワークを介した送信の間、データグラム３００は、フラグメント３１１および３１２等の２つ以上のフラグメントに分割されてよい。データグラム３００がフラグメントに分割された場合、データグラムのヘッダ３１０はほとんどフラグメント３０１、３０２のヘッダ３１１、３１２にコピーされる。フラグメントのヘッダ３１１、３１２内において特定のフィールドが配置されてよく、元々のデータグラム内の個々のフラグメントの長さおよび個々のフラグメントのペイロードの相対位置を反映してよい。一部の状況においては、共通のトレーラ（図示せず）が、元々のデータグラム３００の終わりから各フラグメント３０１、３０２の終わりにまでコピーされてよい。
【００３７】
データグラム３００のペイロード３２０は、フラグメント３０１、３０２間で分割されてよい。元々のデータグラム３００が図３に示すように単一の計測ブロック３２０を含む場合、その計測ブロックは、フラグメント３０１および３０２の間で分割された部分３００ａ、３３０ｂに分割されてよい。あるいは、データグラム３００内の計測ブロック３３０の位置に依存して、計測ブロック３３０は、フラグメント３０１またはフラグメント３０２に全体としてコピーされてよい。いずれにせよ、単一の計測ブロックを含む元々のデータグラムがフラグメント化された場合、結果としてのフラグメントの一部または全部は完全な計測ブロックを含まない。
【００３８】
データグラムのフラグメントが、検査装置ポートにおいて受信される前に、ネットワーク内で再構成される場合、各フラグメント内での完全な計測ブロックは必要なくてよい。しかしながら、フラグメントは、再構成されることなく、検査装置ポートにおいて受信されてよい。例えば、パケットをフラグメント化するためのネットワークデバイスの機能を確認することを意図した検査は、フラグメントが再構成なしに検査装置によって受信されることを必要としてよい。こうした状況において、各々の元々のデータグラムは、各々のフラグメントが少なくとも１つの完全な計測ブロックを含むように生成されてもよい。
【００３９】
ここで図４を参照すると、フラグメント化を検査するための処理４００は、４０５において開始してよく、ならびに、多量の検査トラフィックが生成された後か、または、オペレータのアクション（図４においては図示せず）によって停止された場合に、４９５において終了してよい。処理４００は、トラフィックジェネレータ２２０等のトラフィックジェネレータを用いてトラフィックを生成すること、および、トラフィックレシーバ２８０等のトラフィックレシーバによってトラフィックを受信することを含んでよい。処理４００は事実上、周期的およびリアルタイムであってよい。図４のフローチャートは、単一のトラフィックジェネレータおよび単一のトラフィックレシーバによって実行されるものとして処理４００を示す。処理４００は、検査セッションの間、複数のトラフィックジェネレータおよびトラフィックレシーバによって、同時に、並行して、実行されてもよいことは理解されるべきである。
【００４０】
処理４００の開始４０５に先立って、検査セッションが設計されていてもよい。検査セッションのデザインは、例えば、ポートユニット２１０等の１つ以上のポートユニットに接続された検査アドミニストレータ２０５等の検査アドミニストレータ計算デバイスを用いるオペレータによってなされてもよい。検査セッションの設計は、ネットワークまたはネットワーク装置のアーキテクチャの決定または定義、検査セッションの間、各ポートユニットによって生成されるストリームの定義、対応のストリーム形成データの生成、および、個々のストリーム形成データの少なくとも１つのポートユニットへの転送を含んでよい。
【００４１】
４１０において、トラフィックジェネレータは、パケットを形成し、送信することによってトラフィックを生成し得る。４１５において、さらなるトラフィックが生成されるべきであるかどうかの決定がなされ得る。この決定は、例えば、送信されるパケットまたはデータグラムの最小数を規定する検査セッションの明細、検査セッションに必要とされる期間、または一部の他の検査セッションの完了基準に基づいてなされてよい。さらなるトラフィックが必要とされない場合、検査セッションは４９５において終了してよい。さらなるトラフィックが生成されるべきである場合、処理は４１０から繰返し得る。４１０および４１５におけるアクションは、説明を簡素化するためにシーケンシャルで示されているが、これらのアクションは同時並行（ｃｏｎｃｕｒｒｅｎｔｌｙ）して実行されてもよい。４１０および４１５におけるアクションは、検査セッションの期間、実質的に継続して繰り返されてよい。
【００４２】
４１０において生成された検査トラフィックは、複数の計測ブロックを含む少なくとも一部のデータグラムを含んでよい。複数の計測ブロックは、データグラムが被検査ネットワーク４９０によってフラグメントに分割された場合、少なくとも１つの完全な計測ブロックが各フラグメントに含まれるように、データグラムに組み込まれてよい。各データグラム内での複数の計測ブロックの処理は、フラグメントのペイロード長が知られているかどうかに依存してよい。
【００４３】
ここで図５を参照すると、データグラム５００は、ヘッダ５１０と、複数の計測ブロック５３０−１、５３０−２を含むペイロード５２０を含んでよい。２つのみの計測ブロック５３０−１、５３０−２が示されているが、データグラムは、３つ以上の計測ブロックを含んでよい。
【００４４】
被検査ネットワークを介した送信の間、データグラム５００は、フラグメント５０１および５０２等の２つ以上のフラグメントに分割されてよい。データグラム５００がフラグメントに分割された場合、フラグメントのヘッダ５１１、５１２は前述したように完了されてよい。データグラム５００のペイロード５２０は、フラグメント５０１、５０２のペイロードの部分間で分割されてよい。フラグメントのペイロードの一部の予期される長さＸが知られている場合、計測ブロック５３０−１、５３０−２は、長さＸと等しい間隔で、ペイロード５２０内に配置されてよい。この場合、各計測ブロック５３０−１、５３０−２は、各フラグメントが１つの完全な計測ブロックを含むように、個々のフラグメント５３１、５３２にコピーされてよい。この場合、データグラムから形成されるフラグメントの数は、フラグメントのペイロード長によって分けられ次の整数の番号に切り上げられるデータグラムのペイロード長に等しい。データグラムにおいて必要とされる計測ブロックの数は、データグラムから形成されるフラグメントの数に等しくてよい。
【００４５】
一部の状況において、フラグメントのペイロード長は、データグラムが生成された場合に、知られていない場合もある。例えば、ネットワークデバイスは、１つ以上の音声または映像ストリームのスケジューリングされたパケット間で送信可能であるフラグメントに、１つの長いデータパケットを変換し得る。この場合、フラグメントのペイロード長は、スケジューリングされたパケット間での利用可能時間に適合するように、ネットワークデバイスによって選択されてもよく、また、一定でなくともよく、あるいは予期可能でなくてもよい。
【００４６】
ここで図６を参照すると、データグラム６００は、ヘッダ６１０と、複数の計測ブロック６３０−１、６３０−２、６３０−３、６３０−４、および６３０−５を含むペイロード６２０を含んでよい。５つの計測ブロック６３０−１から６３０−５が図６の例において示されており、データグラムは、５よりも多いかまたは５未満の計測ブロックを含んでよい。
【００４７】
被検査ネットワークを介した送信の間、データグラム６００は、フラグメント６０１および６０２を含む、２つ以上のフラグメントに分割されてよい。データグラム６００がフラグメントに分割される場合、フラグメントのヘッダ６１１、６１２は前述したように、完了されてもよい。データグラム６００のペイロード６２０は、フラグメント６０１、６０２のペイロードの部分の間で分割されてよく、必要に応じて、他のフラグメント間で分割されてもよい。フラグメントのペイロードの一部の予期される最小の長さＸｍｉｎが知られている場合、計測ブロック６３０−１〜６３０−５は、間隔Ｙで、ペイロード６２０内に配置されてよく、ここでＹはＸｍｉｎの半分未満かＸｍｉｎと等しい。この場合、Ｘｍｉｎと等しいかまたはＸｍｉｎより長いペイロード長を有する各フラグメントは、少なくとも１つの完全な計測ブロックを含むことが保証される。図６の例において、フラグメント６０１は、計測ブロック６３０−１および６３０−２ならびに計測ブロック６３０−３の一部を含む。フラグメント６０２は、計測ブロック６３０−３の一部、計測ブロック６３０−４の全部、および計測ブロック６３０−５の一部を含む。データグラム６００の残りの部分は、１つ以上の追加のフラグメント（図示せず）によって運ばれてよい。各フラグメントが少なくとも１つの完全な計測ブロックを含む一方で、様々なフラグメント内の完全な計測ブロックの位置は予期できないことに留意されたい。
【００４８】
図４に戻って参照すると、図５および／または図６に示すように、複数の計測ブロックを有するデータグラムを含む、４１０で生成された検査トラフィックは、被検査ネットワーク４９０に送信されてよい。検査トラフィックに含まれる少なくとも一部のデータグラムは、被検査ネットワーク４９０内でフラグメントに変換されてよい。フラグメントを含む検査トラフィックは、１つ以上のトラフィックレシーバによって受信されてよい。
【００４９】
各トラフィックレシーバ内で、パケットは、４３０においてシーケンシャルに受信されてよい。４３５において、トラフィックレシーバは、各パケットから、少なくとも１つの計測ブロックを抽出してよい。４３５において、トラフィックレシーバはまた、各受信されたパケットにおいて見出された計測ブロックの数をカウントしてよい。
【００５０】
ここで図７を参照すると、４１０において生成された各パケットまたはデータグラム７００は、１つ以上の計測ブロック７３０−１、７３０−２、７３０−３を含んでよい。計測ブロック７３０−１、−２、−３は、フィルデータ７４０−１、７４０−２、７４０−３によって、隣接していてもよく、または離れていてもよい。フィルデータ７４０−１、−２、−３は、例えば、前述したように、計測ブロック間において必要とされる間隔（ｓｐａｃｉｎｇ）を維持するために、データグラム７００に挿入される、ランダムに生成されるかまたは予め決められたデータであってよい。パケットまたはデータグラムは、図７の例において示す３つの計測ブロックよりも多くても少なくてもよい数を有する。各計測ブロック７３０−１、−２、−３は、受信されたパケット内に計測ブロックを配置するために用いられる署名フィールド７３１を含んでよい。署名フィールド７３１は、予め決められた値を含んでよい。署名フィールド７３１、および従って計測ブロックは、公開されている特許出願ＵＳ２００７／０１１５８３３ Ａ１に記載されているように、予め決められた値と合致するフローティングパターンを行うことによってパケット内に配置されてよい。
【００５１】
各計測ブロック７３０−１、−２、−３は、受信されたパケットを、特定のパケットグループのメンバーとして識別するパケットグループ識別子（ＰＧＩＤ）７３２を含んでよい。各計測ブロックはまた、パケットグループを構成するパケットのシーケンス内のパケットの位置（送信された場合）を示すパケットシーケンス番号７３３を含んでよい。各計測ブロックは、他の検査データ７３７を含んでよく、これはパケットまたはデータグラムの送信時間を示すタイムスタンプを含んでよい。パケットグループ識別子７３２、シーケンス番号７３３、およびタイムスタンプ（もしあれば）の組み合わせは、データグラムを含んで、４１０において送信される各パケットに対して一意であってよい。データグラムが被検査ネットワーク４９０内でフラグメント化されている場合、データグラムのフラグメントは、同じパケットグループ識別子７３２、シーケンス番号７３３、およびタイムスタンプを含んでよい。
【００５２】
各計測ブロック７３０−１、−２、−３は、データグラムのフラグメントの全てが適切に受信されているかどうかを決定することにおいて、パケットレシーバを補助するためのデータを含む１つ以上のフィールドを含んでよい。例えば、データグラム内の計測ブロックは、データグラムのヘッダの後で、計測ブロックから始まり、順番に番号が付けられてよい。各計測ブロックは、個々のシーケンシャル番号を含む計測ブロック番号（ＩＢ番号）フィールド７３４を含んでよい。
【００５３】
ＩＢ番号フィールド７３４の他に、またはそれに加えて、各計測ブロックは、データグラム内の計測ブロックのオフセットを示すＩＢオフセットフィールド７３５を含んでよい。図７の例において、ＩＢオフセットは、データグラム７００のペイロード７２０の開始から、個々の計測ブロックの開始までの、バイトまたは文字での、距離として測定される。この例において、計測ブロック７３０−１についてのＩＢオフセットはゼロであり、計測ブロック７３０−２についてのＩＢオフセットはオフセット２であり、計測ブロック７３０−３についてのＩＢオフセットはオフセット３である。ＩＢオフセットは異なって測定されてよい。例えば、各計測ブロックのＩＢオフセットは、データグラムの開始から、ＩＰヘッダの開始から、または、一部の他の方法において測定されることができる。
【００５４】
各計測ブロック７３０−１、−２、−３は、データグラム内の計測ブロックのトータル数を示すＩＢトータルフィールド７３６を含んでよい。ＩＢトータルフィールド７３６の他に、またはそれに加えて、各計測ブロックは、元々のデータグラムのトータルのペイロード長を規定するトータルペイロード長フィールド（図示せず）を含んでよい。パケットレシーバは、データグラムのフラグメントの全てが受信されたかどうかを決定するために、ＩＢトータルフィールド７３６および／またはトータルペイロード長フィールドを使用してよい。
【００５５】
各計測ブロック７３０−１、−２、−３はまた、パケットレシーバが、計測ブロックが正確に受信されたかどうかを決定できるように、巡回冗長検査（ＣＲＣ）フィールド７３８を含んでよい。ＣＲＣフィールド７３８は、計測ブロックのみにわたって計算されてもよく、または、計測ブロックおよび隣接のフィルデータ７４０−１、−２、−３に亘って計算されてもよい。ＣＲＣフィールド７３８の代わりに、一部の他のフィールド、例えばチェックサムフィールド、パリティフィールド、または誤り訂正符号フィールドが、各計測ブロックの統合を確保するために用いられてもよい。
【００５６】
図４を再び参照すると、計測ブロックが４３５において受信されたパケットから抽出された後、ＰＧＩＤは、計測ブロックから抽出されてよく、対応するパケットグループについて、保存されたフロー統計を検索するために用いられてもよい。検索されたフロー統計は、例えば、受信されたパケットおよびトータルのバイト数、ならびに、順番通りでない順序にて受信されたパケットの数等、パケットグループについての量的な統計を含んでよい。検索されたフロー統計は、パケットグループ内における以前に受信されたパケットのシーケンス番号を含んでもよい。検索されたフロー統計はまた、例えば、最小、平均、および最大のレイテンシー等の時間的な（一時的な）（ｔｅｍｐｏｒａｌ）統計を含んでもよい。
【００５７】
４４５において、４３０において受信されたパケットがフラグメントであるかどうかの決定がなされてもよい。この決定は、４３５において抽出された計測ブロック、４４０において検索されたフロー統計、および／または受信されたパケットのＩＰヘッダに含まれるデータに基づいてなされてよい。例えば、ＩＰｖ４ヘッダは「フラグメント化しない」フラグを含む。このフラグが設定された場合、４３０において受信されたパケットはフラグメントとはなり得ない。さらに例えば、４３５において抽出された計測ブロックは、元々のデータグラムにおける計測ブロックのトータル数、または、元々のデータグラムのペイロードの長さを示すトータル長フィールドを示すＩＢトータルフィールド（図７の７３６）を含んでよい。これらのフィールドは、受信されたパケットがデータグラム全体であるのか、またはフラグメントであるのかどうかを決定するために、受信されたパケットにおいて見出された計測ブロックの数および／または受信されたパケットペイロード長と比較されてよい。４４５における決定は、一部の他の方法においてなされてもよい。
【００５８】
４３０において受信されたパケットがフラグメントではない（すなわち、４４５において受信されたパケットが完全である）という決定が４４５においてなされた場合、対応するパケットグループについてのフロー統計は、完全なパケットが受信されたということを示すために、４５０において更新されてよい。４５０においてフロー統計を更新することは、例えば、受信されたパケットの数のカウントをインクリメントすること、受信されたパケットの長さを受信された累積のトータルバイト数に加えること、必要に応じて順番通りでない順序のパケットのカウントをインクリメントすること、および必要に応じて最小または最大レイテンシータイムを変更することを含んでよい。フロー統計が４５０において更新された後、プロセス４００は４３０に戻ってよく、次のパケットの受信を待機してよい。
【００５９】
４４５において、４３０で受信されたパケットがフラグメントであるという決定がなされた場合、４５５において、受信されたパケットが新たなデータグラムのフラグメントであるのか、「古い」データグラムのフラグメントであるのかどうかの決定がなされてよく、ここでは少なくとももう１つのフラグメントが前もって受信されている。４５５での決定は、例えば、４３５において、受信されたパケットから抽出された計測ブロックに含まれるシーケンス番号と、４４０において検索されたフロー統計に含まれる、以前に受信されたパケット／フラグメントのシーケンス番号とを比較することによってなされてよい。２つのシーケンス番号が同じである場合、４３０において受信されたフラグメントは、少なくとも１つの以前に受信されたフラグメントと同じデータグラムに属する。
【００６０】
４３０において受信されたフラグメントが、少なくとも１つの以前に受信されたフラグメントと同じデータグラムに属するという決定が４５５においてなされた場合（４５５において「ｎｏ」）、対応のパケットグループについてのフロー統計は、特定のフラグメントが受信されたことを示すために、４６０において更新されてよい。例えば、４３５において抽出された計測ブロックは、ＩＢシーケンス番号フィールド（図７における７３４）を含んでよい。この場合、４４０において検索されたフロー統計は、どの計測ブロックが受信されているかを追跡するためのフィールを含んでよい。このフィールドは、対応の計測ブロックが受信されたフラグメントにおいて含まれていることを示すために設定可能である、複数の１ビットのフラグを含んでもよい。さらに例えば、４３５において抽出された計測ブロックはデータグラムについてトータルのペイロード長を含んでもよく、４４０において検索されたフロー統計は累積のペイロード受信フィールドを含んでもよい。この場合、４３０において受信されたフラグメントのペイロード長は、累積のペイロード受信フィールドに加えられてよく、その合計は、データグラム全体が受信されているかどうかを決定するために、トータルのペイロード長と比較されてよい。フロー統計が４６０において更新された後、処理４００は４３０に戻ってよく、次なるパケットの受信を待機してよい。
【００６１】
４３０において受信されたパケットが新たなデータグラムのフラグメントであるという決定が４５５においてなされた場合、以前の「古い」データグラムが完全に受信されたかどうかの決定が４６５においてなされてよい。例えば、４４０において検索されたフロー統計は、対応する計測ブロックが受信されたフラグメントにおいて含まれたことを示すために設定可能である複数のフラグを含んでもよい。この場合、フラグは、４６５において、以前のデータグラムの全ての予期されたフラグメントが受信されたかどうかを決定するために検査されてよい。さらに例えば、４３５において抽出された計測ブロックは、データグラムについてのトータルのペイロード長を含んでよく、４４０において検索されたフロー統計は累積のペイロード受信フィールドを含んでよい。この場合、累積のペイロード受信フィールドおよびトータルのペイロード長は、以前のデータグラム全体が受信されているかどうかを決定するために、４６５において比較されてよい。
【００６２】
以前のデータグラムが完全に受信されたという決定が４６５においてなされた場合、フロー統計は、以前のデータグラムが正確に受信されたことを示し、かつ新たなデータグラムのフラグメントが受信されていることを示すために、４７０において更新されてよい。フロー統計を更新することは、例えば、パケットの数／受信されたデータグラムのカウントをインクリメントすること、以前のデータグラムの長さを受信された累積のトータルのバイト数に加えること、必要であれば、順番通りでない順序のパケットのカウントをインクリメントすること、および、必要に応じて最小または最大のレイテンシータイムを変更することを含んでよい。４７０においてフロー統計を更新することはまた、新たなデータグラムの１つのみのフラグメントが受信されていることを示すために複数のフラグをリセットすること、および／または、新たなデータグラムのフラグメントのペイロード長と等しくなるように累積のペイロード受信フィールドを設定することを含んでよい。フロー統計が４７０において更新された後、処理４００は４３０に戻ってよく、次のパケットの受信を待機してよい。
【００６３】
以前のデータグラムが完全に受信されていないという決定が４６５においてなされた場合、フロー統計は、以前のデータグラムが正確に受信されていないことを示すために、かつ新たなデータグラムのフラグメントが受信されていることを示すために、４７５において更新されてよい。フロー統計を更新することは、例えば、失われたフラグメントを有するデータグラムの数のカウントをインクリメントすることを含んでもよい。４７５においてフロー統計を更新することはまた、新たなデータグラムの１つのみのフラグメントが受信されていることを示すために複数のフラグをリセットすること、および／または、新たなデータグラムのフラグメントのペイロード長と等しくなるように累積のペイロード受信フィールドを設定することを含んでよい。フロー統計が４７５において更新された後、処理４００は４３０に戻ってよく、次のパケットの受信を待機してよい。
【００６４】
図４に示されてはいないが、以前のデータグラムが正確に受信されていないという決定が４６５においてなされた場合、さらなる分析のために、以前のデータグラムのフラグメントを含む、以前に受信されたパケットをセーブするためにキャプチャ操作（ｃａｐｔｕｒｅ ｏｐｅｒａｔｉｏｎ）がトリガされてもよい。
【００６５】
図８をここで参照すると、再構成を検査するために、処理８００は８０５において開始してよく、大量の検査トラフィックが生成された後で、または、オペレータのアクション（図８には図示せず）によって停止された場合に、８９５において終了してよい。処理８００は、トラフィックジェネレータ２２０等のトラフィックジェネレータを用いてトラフィックを生成すること、およびトラフィックレシーバ２８０等のトラフィックレシーバによってトラフィックを受信することを含んでよい。処理８００は、事実上、周期的およびリアルタイムであってよい。図８のフローチャートは、単一のトラフィックジェネレータおよび単一のトラフィックレシーバによって実行されるものとして処理８００を示す。処理８００は、検査セッションの間、複数のトラフィックジェネレータおよびトラフィックレシーバによって、同時に、並行して、実行されてもよいことは理解されるべきである。
【００６６】
処理８００の開始８０５に先立って、検査セッションが設計されていてもよい。検査セッションのデザインは、例えば、ポートユニット２１０等の１つ以上のポートユニットに接続された検査アドミニストレータ２０５等の検査アドミニストレータ計算デバイスを用いるオペレータによってなされてもよい。検査セッションの設計は、ネットワークまたはネットワーク装置のアーキテクチャの決定または定義、検査セッションの間、各ポートユニットによって生成されるストリームの定義、対応のストリーム形成データの生成、および、個々のストリーム形成データの少なくとも１つのポートユニットへの転送を含んでよい。
【００６７】
８１０において、トラフィックジェネレータは、被検査ネットワーク１９０によって再構成される少なくとも一部のフラグメントを含むパケットを形成し、送信することによって検査トラフィックを生成し得る。８１５において、さらなるトラフィックが生成されるべきであるかどうかの決定がなされ得る。この決定は、例えば、送信されるパケットまたはフラグメントの最小数を規定する検査セッションの明細、検査セッションに必要とされる期間、または一部の他の検査セッションの完了基準に基づいてなされてよい。さらなるトラフィックが必要とされない場合、検査セッションは８９５において終了してよい。さらなるトラフィックが生成されるべきである場合、処理は８１０から繰返し得る。８１０および８１５におけるアクションは、説明を簡素化するためにシーケンシャルで示されているが、これらのアクションは同時並行（ｃｏｎｃｕｒｒｅｎｔｌｙ）して実行されてもよい。８１０および８１５におけるアクションは、検査セッションの期間、実質的に継続して繰り返されてよい。
【００６８】
８１０において生成された検査トラフィックは、再構成される少なくとも一部のフラグメントを含んでよい。ここで図９を参照すると、各々のフラグメントのパケット９００は、ヘッダ部分９１０、および計測ブロック９３０を含むペイロード部分９２０を含んでよい。計測ブロック９３０は、全て図７に関連して以前に記載されているように、署名フィールド９３１、ＰＧＩＤフィールド９３２、シーケンス番号フィールド９３３、他の検査データ９３８、およびＣＲＣフィールド９３９を含んでよい。署名フィールド９３１、ＰＧＩＤフィールド９３２、およびシーケンス番号フィールド９３３は、単一のデータグラムに組み合わされるために、全てのフラグメントに対して同じであってよい。
【００６９】
計測ブロック９３０はまた、各々のフラグメントが再構成されたデータグラム内に配置されるべき位置を示すフィールドを含んでよい。例えば、各々のフラグメントの計測ブロック９３０は、再構成されたデータグラムを構成する一連のフラグメントにおけるフラグメントの予期される位置を示すフラグメント番号フィールド９３４を含んでもよい。各々のフラグメントの計測ブロック９３０は、再構成されたデータグラム内の参照点に対して、フラグメントの予期された位置を示すフラグメントオフセットフィールド９３４を含んでよい。フラグメントオフセットは、例えば、データグラムのペイロードの開始から（図７に示すように）、データグラムの開始から、ＩＰヘッダの開始から、または一部の他の方法において、バイトにて、測定されてよい。
【００７０】
計測ブロック９３０はまた、どのくらい多くのフラグメントが完全な再構成されたデータグラム内に予期されるかを示すフィールドを含んでもよい。例えば、各フラグメントの計測ブロック９３０は、完全な再構成されたデータグラムを構成するのに必要とされるフラグメントのトータルの数を示すフラグメントトータルフィールド９３６を含んでもよい。各フラグメントの計測ブロック９３０は、再構成されたデータグラムの予期されるトータルのペイロード長を示すペイロードトータルフィールド９３７を含んでよい。
【００７１】
図８に戻ると、８１０にて生成された検査トラフィックは、フラグメントを含んで、被検査ネットワーク８９０に送信されてよい。少なくとも一部のデータグラムは、被検査ネットワーク８９０により、検査トラフィックに含まれるフラグメントから再構成されてよい。検査トラフィックは、再構成されたデータグラムを含んで、１つ以上のトラフィックレシーバにより受信されてよい。
【００７２】
各トラフィックレシーバ内で、パケットは、８３０において、シーケンシャルに受信されてよい。８３５において、トラフィックレシーバは、各パケットから、１つ以上の計測ブロックを抽出してよい。８３５において、トラフィックレシーバは、各々受信されたパケットにおいて見出された全ての計測ブロックの一部または全てを抽出してよい。
【００７３】
１つ以上の計測ブロックが８３５において、受信されたパケットから抽出された後、ＰＧＩＤは、１つの計測ブロック（例えば、複数の計測ブロックが８３５で抽出される場合はその最初の計測ブロック）から抽出されてよく、８４０において、対応のパケットグループについて、保存されたフロー統計を検索するために用いられてよい。８４０において検索されたフロー統計は、例えば、受信されたパケットの数およびトータルのバイト数、ならびに順番通りでない順序で受信されたパケットの数等、パケットグループについての量的な統計を含んでよい。検索されたフロー統計は、パケットグループ内において以前に受信されたパケットのシーケンス番号を含んでよい。検索されたフロー統計はまた、例えば、最小、平均、最大レイテンシー等の時間的な（一時的な）統計を含んでもよい。
【００７４】
８４５において、８３０で受信されたパケットが、２つ以上のフラグメントから再構成されたデータグラムであるかどうかの決定がなされてもよい。この決定は、８３５において抽出された計測ブロックに含まれるデータに基づいてなされてよい。例えば、８３５において抽出された計測ブロックが、計測ブロックの予期されるトータルの数が１であることを示すＩＢトータルフィールドを含む場合、受信されたパケットは再構成されたデータグラムではない。
【００７５】
８３０において受信されたパケットが再構成されたデータグラムではないという決定が８４５においてなされた場合、対応するパケットグループについてのフロー統計は、完全なパケットが受信されたということを示すために、８５０において更新されてよい。８５０においてフロー統計を更新することは、例えば、受信されたパケットの数のカウントをインクリメントすること、受信されたパケットの長さを受信された累積のトータルバイト数に加えること、必要に応じて順番通りでない順序のパケットのカウントをインクリメントすること、および必要に応じて最小または最大レイテンシータイムを変更することを含んでよい。フロー統計が８５０において更新された後、プロセス８００は８３０に戻ってよく、次のパケットの受信を待機してよい。
【００７６】
８３０において受信されたパケットが再構成されたデータグラムであるという決定が８４５においてなされた場合、フラグメントの予期された数が、被検査ネットワーク１９０により再構成されるように、データグラムに組み込まれたかどうかの決定が８５５においてなされてよい。８５５における決定は、例えば、８３５において抽出される計測ブロックの数と、予期されるフラグメントの数を示すフラグメントトータルフィールド（図９における９３６）とを比較することによってなされてよい。８５５における決定は、８３０において受信されるパケットペイロード長と、再構成されたデータグラムの予期されるペイロード長を示すペイロードトータルフィールド（図９における９３７）とを比較することによってなされてよい。８５５において、８３５で抽出された複数の計測ブロックもまた計測ブロック内のＰＧＩＤとシーケンス番号とが各々等しいことを比較されてよい。ＰＧＩＤおよび／またはシーケンス番号が、全ての計測ブロックにおいて等しくない場合、８３０において受信されたパケットは、２つ以上のデータグラムのフラグメントから再構成されていてよい。
【００７７】
８５５において、４３０で受信されたデータグラムが予期されるフラグメントの数を含まないか、または、２つ以上のデータグラムからのフラグメントを含むという決定がなされた場合、対応のパケットグループについてのフロー統計は、不正確に再構成されたデータグラムが受信されたことを示すために、９６０において更新されてよい。フロー統計が８６０において更新された後、処理８００は８３０に戻ってよく、次のパケットの受信を待機してよい。
【００７８】
８３０において受信されたデータグラムが予期されるフラグメントの数を含むという決定が８５５においてなされた場合、フラグメントが正確な順序にて再構成されたかどうかの決定がなされてよい。例えば、８６５において、８３５で抽出された各計測ブロック内のフラグメント番号フィールド（図９における９３４）および／またはフラグメントオフセットフィールド（図９における９３５）は、計測ブロックが再構成されたデータグラムにおいて正確に順序付けされたかどうかを決定するために比較されてよい。
【００７９】
８６５において、８３０において受信されたデータグラムが、データグラム内において正確なシーケンスとなっていない１つ以上のフラグメントを含むという決定がなされた場合、フロー統計は、不正確な再構成データグラムが受信されたことを示すために、８６０において更新されてよい。８６５において、８３０で受信されたデータグラムが、データグラム内で正確なシーケンスで、予期されたフラグメントの全てを有するという決定がなされた場合、フロー統計は、正確に再構成されたデータグラムが受信されたことを示すために、８７０において更新されてよい。フロー統計が８６０または８７０において更新された後、処理８００は８３０に戻ってよく、次のパケットの受信を待機してよい。
【００８０】
図８には図示されていないが、受信されたデータグラムが不正確に再構成されたという決定が８５５または８６５においてなされた場合、キャプチャ操作がトリガされてよく、さらなる分析のために、不正確に再構成されたデータグラムを含む、以前に受信されたパケットを保存してよい。
【００８１】
（終わりに）
本記載全体を通して、示された実施形態および例は、開示された、または特許請求の範囲において請求された装置および手順についての限定ではなく、典型例として想定されるべきものである。本明細書において提示された例の多くは、方法の作用またはシステムの要素の特定の組合せに関連するものであるけれども、それらの作用およびそれらの要素は、他の方法において、組み合わされてよく、同じ課題を達成するものとして理解されるべきである。フローチャートに関して、追加の工程および工程の削減もまた考慮されてよく、図示した工程は、本明細書において記載された方法を達成するために組み合わされてもよく、またはさらに改良されてもよい。１つの実施形態のみに関連して記載された作用、要素、および特徴は、他の実施形態における同様の役割から排除されることは意図されていない。
【００８２】
本明細書において用いられるように、「複数」とは、２つ以上を意味する。本明細書において用いられるように、「一連の」物品とは、１つ以上のそのような物品を含み得る。本明細書において用いられるように、明細書の記載または特許請求の範囲の請求項においては、用語「含む、備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む、備える（ｉｎｃｌｕｄｉｎｇ）」「運ぶ、有する、持つ（ｃａｒｒｙｉｎｇ）」、「有する（ｈａｖｉｎｇ）」、「含む（ｃｏｎｔａｉｎｉｎｇ）」、「含む、関する、関連する（ｉｎｖｏｌｖｉｎｇ）」等は、オープンエンド型、すなわち、含むがそれらに限定されないということを意味することは理解されるべきである。「〜からなる」および「〜から実質的になる」といった移行句の各々のみが、特許請求の範囲の請求項に関しては、クローズ型、または半クローズ型の移行句である。請求項の要素を変更するために、特許請求の範囲の請求項における「第１」、「第２」、「第３」等の序数の用語の使用は、それ自体では、任意の優先順位、優位性、またはある請求項の要素が他のものより先であったり、または、ある方法の作用が行われる時間的順序等を含意せず、請求項の要素を区別するために、特定の名前を有するある請求項の要素から、同じ名前を有する別の要素を区別するためのラベルとして（順序を示す用語の使用を別にして）単に用いられる。本明細書において用いられるように、「および／または」は、リストアップされた物品が二者択一であることを意味するが、そうした二者択一もまた、そうしてリストアップされた物品の任意の組合せを含むものである。
【特許請求の範囲】
【請求項１】
データグラムをフラグメントに変換するネットワークを検査するための方法であって、
トラフィックジェネレータが、複数の計測ブロックを含むデータグラムを生成することと、
前記トラフィックジェネレータが、前記ネットワークを通じて前記データグラムを送信することと
を含む、方法。
【請求項２】
前記ネットワークが前記データグラムを複数のフラグメントに変換する場合、各フラグメントが少なくとも１つの完全な計測ブロックを含むように、複数の計測ブロックは前記データグラム内に配置される、請求項１に記載の方法。
【請求項３】
予期されるフラグメントのペイロード長が知られており、
前記データグラムを生成することは、前記予期されるフラグメントのペイロード長に等しい間隔で、複数の計測ブロックを前記データグラムに挿入することをさらに含む、請求項２に記載の方法。
【請求項４】
最小のフラグメントのペイロード長が知られており、
前記データグラムを生成することは、前記最小のフラグメントのペイロード長の半分未満または半分に等しい間隔で、複数の計測ブロックを前記データグラムに挿入することをさらに含む、請求項２に記載の方法。
【請求項５】
前記複数の計測ブロックの各々は、前記データグラムを識別する情報、および、前記データグラム内の各計測ブロックの位置を識別する情報を含む、請求項１に記載の方法。
【請求項６】
前記データグラムを識別する情報は、パケットグループ識別子およびパケットシーケンス番号を含む、請求項５に記載の方法。
【請求項７】
前記データグラム内の計測ブロックの位置を識別する情報は、計測ブロックシーケンス番号および計測ブロックオフセットのうちの少なくとも１つを含む、請求項５に記載の方法。
【請求項８】
前記複数の計測ブロックの各々は、前記データグラム内の計測ブロックのトータル数および前記データグラムのペイロード長のうちの少なくとも１つを示す情報を含む、請求項５に記載の方法。
【請求項９】
パケットレシーバは、前記データグラムから導かれる複数のフラグメントを受信することと、
前記パケットレシーバは、前記受信されたフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定することと、
前記パケットレシーバは、受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を累積および報告することと
をさらに含む、請求項１に記載の方法。
【請求項１０】
データグラムをフラグメントに変換するネットワークを検査するための装置であって、
複数の計測ブロックを含むデータグラムを生成し、かつ前記ネットワークを通じて前記データグラムを送信するように構成されるトラフィックジェネレータを備える、装置。
【請求項１１】
前記ネットワークが前記データグラムを複数のフラグメントに変換する場合、各フラグメントが少なくとも１つの完全な計測ブロックを含むように、複数の計測ブロックは前記データグラム内に配置される、請求項１０に記載の装置。
【請求項１２】
予期されるフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記予期されるフラグメントのペイロード長に等しい間隔で、複数の計測ブロックをデータグラムに挿入するように構成される、請求項１１に記載の装置。
【請求項１３】
最小のフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記最小のフラグメントのペイロード長の半分未満または半分に等しい間隔で、複数の計測ブロックを前記データグラムに挿入するように構成される、請求項１１に記載の装置。
【請求項１４】
前記複数の計測ブロックの各々は、前記データグラムを識別する情報、および、前記データグラム内の各計測ブロックの位置を識別する情報を含む、請求項１０に記載の装置。
【請求項１５】
前記データグラムを識別する情報は、パケットグループ識別子およびパケットシーケンス番号を含む、請求項１４に記載の装置。
【請求項１６】
前記データグラム内の計測ブロックの位置を識別する情報は、計測ブロックシーケンス番号および計測ブロックオフセットのうちの少なくとも１つを含む、請求項１４に記載の装置。
【請求項１７】
前記複数の計測ブロックの各々は、前記データグラム内の計測ブロックのトータル数および前記データグラムのペイロード長のうちの少なくとも１つを示す情報を含む、請求項１４に記載の装置。
【請求項１８】
パケットレシーバをさらに備え、前記パケットレシーバは、
前記データグラムから導かれる複数のフラグメントを受信し、
前記受信されたフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定し、
受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を累積および報告する、ように構成される、請求項１０に記載の装置。
【請求項１９】
プログラム可能なハードウェアデバイスを構成するために用いられた場合、前記プログラム可能なハードウェアデバイスが、以下：
複数の計測ブロックを含むデータグラムを生成し、かつ前記ネットワークを通じて前記データグラムを送信するように構成されるトラフィックジェネレータを備えるように構成させる構成データを含む、機械可読保存媒体。
【請求項２０】
前記ネットワークが前記データグラムを複数のフラグメントに変換する場合、各フラグメントが少なくとも１つの完全な計測ブロックを含むように、複数の計測ブロックは前記データグラム内に配置される、請求項１９に記載の機械可読保存媒体。
【請求項２１】
予期されるフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記予期されるフラグメントのペイロード長に等しい間隔で、複数の計測ブロックをデータグラムに挿入するように構成される、請求項２０に記載の機械可読保存媒体。
【請求項２２】
最小のフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記最小のフラグメントのペイロード長の半分未満または半分に等しい間隔で、複数の計測ブロックをデータグラムに挿入するように構成される、請求項２０に記載の機械可読保存媒体。
【請求項２３】
前記複数の計測ブロックの各々は、前記データグラムを識別する情報、および、前記データグラム内の各計測ブロックの位置を識別する情報を含む、請求項１９に記載の機械可読保存媒体。
【請求項２４】
前記データグラムを識別する情報は、パケットグループ識別子およびパケットシーケンス番号を含む、請求項２３に記載の機械可読保存媒体。
【請求項２５】
前記データグラム内の計測ブロックの位置を識別する情報は、計測ブロックシーケンス番号および計測ブロックオフセットのうちの少なくとも１つを含む、請求項２３に記載の機械可読保存媒体。
【請求項２６】
前記複数の計測ブロックの各々は、前記データグラム内の計測ブロックのトータル数および前記データグラムのペイロード長のうちの少なくとも１つを示す情報を含む、請求項２３に記載の機械可読保存媒体。
【請求項２７】
前記プログラム可能なハードウェアデバイスは、パケットレシーバをさらに備え、前記パケットレシーバは、
前記データグラムから導かれる複数のフラグメントを受信し、
前記受信されたフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定し、
受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を累積および報告する、ように構成される、請求項１９に記載の機械可読保存媒体。
【請求項１】
データグラムをフラグメントに変換するネットワークを検査するための方法であって、
トラフィックジェネレータが、複数の計測ブロックを含むデータグラムを生成することと、
前記トラフィックジェネレータが、前記ネットワークを通じて前記データグラムを送信することと
を含む、方法。
【請求項２】
前記ネットワークが前記データグラムを複数のフラグメントに変換する場合、各フラグメントが少なくとも１つの完全な計測ブロックを含むように、複数の計測ブロックは前記データグラム内に配置される、請求項１に記載の方法。
【請求項３】
予期されるフラグメントのペイロード長が知られており、
前記データグラムを生成することは、前記予期されるフラグメントのペイロード長に等しい間隔で、複数の計測ブロックを前記データグラムに挿入することをさらに含む、請求項２に記載の方法。
【請求項４】
最小のフラグメントのペイロード長が知られており、
前記データグラムを生成することは、前記最小のフラグメントのペイロード長の半分未満または半分に等しい間隔で、複数の計測ブロックを前記データグラムに挿入することをさらに含む、請求項２に記載の方法。
【請求項５】
前記複数の計測ブロックの各々は、前記データグラムを識別する情報、および、前記データグラム内の各計測ブロックの位置を識別する情報を含む、請求項１に記載の方法。
【請求項６】
前記データグラムを識別する情報は、パケットグループ識別子およびパケットシーケンス番号を含む、請求項５に記載の方法。
【請求項７】
前記データグラム内の計測ブロックの位置を識別する情報は、計測ブロックシーケンス番号および計測ブロックオフセットのうちの少なくとも１つを含む、請求項５に記載の方法。
【請求項８】
前記複数の計測ブロックの各々は、前記データグラム内の計測ブロックのトータル数および前記データグラムのペイロード長のうちの少なくとも１つを示す情報を含む、請求項５に記載の方法。
【請求項９】
パケットレシーバは、前記データグラムから導かれる複数のフラグメントを受信することと、
前記パケットレシーバは、前記受信されたフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定することと、
前記パケットレシーバは、受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を累積および報告することと
をさらに含む、請求項１に記載の方法。
【請求項１０】
データグラムをフラグメントに変換するネットワークを検査するための装置であって、
複数の計測ブロックを含むデータグラムを生成し、かつ前記ネットワークを通じて前記データグラムを送信するように構成されるトラフィックジェネレータを備える、装置。
【請求項１１】
前記ネットワークが前記データグラムを複数のフラグメントに変換する場合、各フラグメントが少なくとも１つの完全な計測ブロックを含むように、複数の計測ブロックは前記データグラム内に配置される、請求項１０に記載の装置。
【請求項１２】
予期されるフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記予期されるフラグメントのペイロード長に等しい間隔で、複数の計測ブロックをデータグラムに挿入するように構成される、請求項１１に記載の装置。
【請求項１３】
最小のフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記最小のフラグメントのペイロード長の半分未満または半分に等しい間隔で、複数の計測ブロックを前記データグラムに挿入するように構成される、請求項１１に記載の装置。
【請求項１４】
前記複数の計測ブロックの各々は、前記データグラムを識別する情報、および、前記データグラム内の各計測ブロックの位置を識別する情報を含む、請求項１０に記載の装置。
【請求項１５】
前記データグラムを識別する情報は、パケットグループ識別子およびパケットシーケンス番号を含む、請求項１４に記載の装置。
【請求項１６】
前記データグラム内の計測ブロックの位置を識別する情報は、計測ブロックシーケンス番号および計測ブロックオフセットのうちの少なくとも１つを含む、請求項１４に記載の装置。
【請求項１７】
前記複数の計測ブロックの各々は、前記データグラム内の計測ブロックのトータル数および前記データグラムのペイロード長のうちの少なくとも１つを示す情報を含む、請求項１４に記載の装置。
【請求項１８】
パケットレシーバをさらに備え、前記パケットレシーバは、
前記データグラムから導かれる複数のフラグメントを受信し、
前記受信されたフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定し、
受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を累積および報告する、ように構成される、請求項１０に記載の装置。
【請求項１９】
プログラム可能なハードウェアデバイスを構成するために用いられた場合、前記プログラム可能なハードウェアデバイスが、以下：
複数の計測ブロックを含むデータグラムを生成し、かつ前記ネットワークを通じて前記データグラムを送信するように構成されるトラフィックジェネレータを備えるように構成させる構成データを含む、機械可読保存媒体。
【請求項２０】
前記ネットワークが前記データグラムを複数のフラグメントに変換する場合、各フラグメントが少なくとも１つの完全な計測ブロックを含むように、複数の計測ブロックは前記データグラム内に配置される、請求項１９に記載の機械可読保存媒体。
【請求項２１】
予期されるフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記予期されるフラグメントのペイロード長に等しい間隔で、複数の計測ブロックをデータグラムに挿入するように構成される、請求項２０に記載の機械可読保存媒体。
【請求項２２】
最小のフラグメントのペイロード長が知られており、
前記トラフィックジェネレータは、前記最小のフラグメントのペイロード長の半分未満または半分に等しい間隔で、複数の計測ブロックをデータグラムに挿入するように構成される、請求項２０に記載の機械可読保存媒体。
【請求項２３】
前記複数の計測ブロックの各々は、前記データグラムを識別する情報、および、前記データグラム内の各計測ブロックの位置を識別する情報を含む、請求項１９に記載の機械可読保存媒体。
【請求項２４】
前記データグラムを識別する情報は、パケットグループ識別子およびパケットシーケンス番号を含む、請求項２３に記載の機械可読保存媒体。
【請求項２５】
前記データグラム内の計測ブロックの位置を識別する情報は、計測ブロックシーケンス番号および計測ブロックオフセットのうちの少なくとも１つを含む、請求項２３に記載の機械可読保存媒体。
【請求項２６】
前記複数の計測ブロックの各々は、前記データグラム内の計測ブロックのトータル数および前記データグラムのペイロード長のうちの少なくとも１つを示す情報を含む、請求項２３に記載の機械可読保存媒体。
【請求項２７】
前記プログラム可能なハードウェアデバイスは、パケットレシーバをさらに備え、前記パケットレシーバは、
前記データグラムから導かれる複数のフラグメントを受信し、
前記受信されたフラグメントが、個々の受信されたフラグメントから抽出された個々の計測ブロック内のデータに少なくとも部分的に基づいて完全なデータグラムを構成するかどうかを決定し、
受信された完全なデータグラムの数および受信された不完全なデータグラムの数を示す検査統計を累積および報告する、ように構成される、請求項１９に記載の機械可読保存媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１０９９６２（Ｐ２０１２−１０９９６２Ａ）
【公開日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−２４３４０３（Ｐ２０１１−２４３４０３）
【出願日】平成２３年１１月７日（２０１１．１１．７）
【出願人】（５０４０９０４００）
【Ｆターム（参考）】
【公開日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願番号】特願２０１１−２４３４０３（Ｐ２０１１−２４３４０３）
【出願日】平成２３年１１月７日（２０１１．１１．７）
【出願人】（５０４０９０４００）
【Ｆターム（参考）】
[ Back to top ]