優先フロー制御を有するパラレルトラフィックジェネレータ
【課題】ネットワークをテストするためのテストトラフィックを生成する装置を提供する。
【解決手段】スケジューラ４３０は、一連のパケットについてパケット定義データを提供し、各パケットは、それぞれのフロー制御グループに関連づけられる。チャネライズドスケジュール待ち行列４３５は、複数のパラレルチャネルを含んでもよく、各チャネルは、対応するフロー制御グループに関連づけられるパケット定義データの格納に専用される。複数のステートレスパケットビルダ４５０は、チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従って、パケットを構築する。チャネライズドパケットバッファ４５５は、複数のステートレスパケットビルダによって構築されたパケットを格納する。出力マルチプレクサ４６０は、チャネライズドパケットバッファからのパケットをインタリーブすることにより、テストトラフィックを形成する。
【解決手段】スケジューラ４３０は、一連のパケットについてパケット定義データを提供し、各パケットは、それぞれのフロー制御グループに関連づけられる。チャネライズドスケジュール待ち行列４３５は、複数のパラレルチャネルを含んでもよく、各チャネルは、対応するフロー制御グループに関連づけられるパケット定義データの格納に専用される。複数のステートレスパケットビルダ４５０は、チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従って、パケットを構築する。チャネライズドパケットバッファ４５５は、複数のステートレスパケットビルダによって構築されたパケットを格納する。出力マルチプレクサ４６０は、チャネライズドパケットバッファからのパケットをインタリーブすることにより、テストトラフィックを形成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワークまたはネットワーク装置をテストするためのトラフィックの生成に関する。
【背景技術】
【０００２】
多くの種類の通信ネットワークにおいて、送信されるべき各メッセージは、固定長または可変長の部分に分割される。各部分は、パケット、フレーム、セル、データグラム、データ単位、または情報の他の単位と呼ばれることもあるが、本明細書においては、それらの全てをパケットと呼ぶ。
【０００３】
各パケットは、パケットのペイロードと一般的に呼ばれる、オリジナルメッセージの部分を含む。パケットのペイロードは、データを含んでもよく、音声情報またはビデオ情報を含んでもよい。パケットのペイロードは、ネットワーク管理制御情報を含んでもよい。加えて、各パケットは、パケットヘッダと一般的に呼ばれる、識別および経路指定の情報を含む。パケットは、複数のスイッチまたはノードを介して、ネットワークにわたり個々に送信される。メッセージがターゲット装置またはエンドユーザに配信される前に、パケットヘッダに含まれる情報を用いて、パケットは、最終送信先においてメッセージへと再構築される。受信側において、再構築されたメッセージは、ユーザの装置と互換性のあるフォーマットでエンドユーザに渡される。
【０００４】
メッセージをパケットとして送信する通信ネットワークは、パケット交換網と呼ばれる。パケット交換網は、ハブまたはノードにおいて交差する送信経路のメッシュを一般的に含む。少なくとも一部のノードは、ノードに到着するパケットを受信して、かつ適切な発信経路に沿ってパケットを再送信する、交換装置またはルータを含んでもよい。パケット交換網は、業界基準プロトコルの階層構造によって制御される。その構造のレイヤ１、２および３は、それぞれ、物理的レイヤ、データリンクレイヤ、およびネットワークレイヤである。
【０００５】
レイヤ１プロトコルは、ネットワークのノード間の物理的な（電気的、光学的、またはワイヤレスの）インタフェースを定義する。レイヤ１プロトコルは、イーサネット（登録商標）のさまざまな物理的構成、同期光通信ネットワーク（ＳＯＮＥＴ）等の光通信接続のプロトコル、およびＷｉＦｉ等のさまざまなワイヤレスプロトコルを含む。
【０００６】
レイヤ２プロトコルは、ネットワークのノード間でデータが論理的に転送される方法を制御する。レイヤ２プロトコルは、イーサネット（登録商標）、非同期転送モード（ＡＴＭ）、フレームリレー、およびポイントツーポイントプロトコル（ＰＰＰ）を含む。
【０００７】
レイヤ３プロトコルは、ネットワークの複数ノードを接続する経路に沿って、パケットが送信元から送信先へとルーティングされる方法を制御する。主要なレイヤ３プロトコルは、周知のインターネットプロトコルのバージョン４（ＩＰｖ４）およびバージョン６（ＩＰｖ６）である。パケット交換網は、イーサネット（登録商標）、ＡＴＭ、ＦＲおよび／またはＰＰＰレイヤ２といったプロトコルの組み合わせを用いて、ＩＰパケットをルーティングする必要がありえる。ネットワークのノードの少なくとも一部は、各パケット内に含まれるネットワークレイヤヘッダから宛先アドレスを抽出するルータを含んでもよい。ルータは、次に、宛先アドレスを用いて、パケットが再送信されるべきルートまたは経路を判定する。典型的なパケットは、複数のルータを通過してもよい。各ルータは、宛先アドレスを抽出し、かつパケットが再送信されるべきルートまたは経路を判定する、という動作を反復する。
【０００８】
パケット交換通信ネットワークに含まれるパケット交換網または装置をテストするために、多数のパケットを含むテストトラフィックを、生成し、１つ以上のポートからネットワークに送信し、異なるポートにおいて受信してもよい。テストトラフィックの各パケットは、特定の送信先ポートで受信されるように意図されたユニキャストパケットであってもよく、または２つ以上の送信先ポートで受信されるように意図されたマルチキャストパケットであってもよい。この文脈において、「ポート」という用語は、ネットワークとそのネットワークをテストするために用いられる装置との間の、通信接続を指す。「ポート装置」という用語は、ポートにおいてネットワークに接続するネットワークテスト装置内のモジュールを意味する。受信されたテストトラフィックを分析することにより、ネットワークの性能を測定してもよい。ネットワークに接続された各ポート装置は、テストトラフィックの送信元およびテストトラフィックの送信先の両方であってもよい。各ポート装置は、複数の論理的な送信元または送信先のアドレスをエミュレートしてもよい。ポート装置をネットワークに接続するポート装置の個数および通信経路は、一般的に、テストセッション中は固定される。例えば、通信経路またはハードウェア装置の障害により、テストセッション中にネットワークの内部構造が変化することがある。
【０００９】
本明細書において、単一のポート装置から発信され、かつ特定の種類のパケットおよび特定の速度を有する一連のパケットを、「ストリーム」と呼ぶ。送信元ポート装置は、例えば、複数のパケット形式、速度、または送信先に適合するように、複数の発信ストリームを同時にかつ並行してサポートしてもよい。「同時に」は、「正確に同じ時間において」を意味する。「並行して」は、「同じ時間の範囲内で」を意味する。
【００１０】
本明細書において、「エンジン」という用語は、記述された機能を実行するファームウェアおよび／またはソフトウェアによって増補されえるハードウェアの集合を意味する。エンジンは、一般的に、主に機能言語によってエンジンを定義するハードウェア記述言語（ＨＤＬ）を用いて設計されてもよい。ＨＤＬの設計は、ＨＤＬシミュレーションツールを用いて検証されてもよい。検証されたＨＤＬの設計は、次に、一般的に「合成」と呼ばれる工程において、エンジンのゲートネットリストまたは他の物理的記述へと変換されてもよい。合成は、合成ツールを用いて自動的に実行されてもよい。ゲートネットリストまたは他の物理的記述は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路（ＰＬＤ）、プログラム可能論理アレイ（ＰＬＡ）、または他のプログラム可能回路等の、プログラム可能半導体デバイスにおけるエンジンを実現するためのプログラミングコードへと更に変換されてもよい。ゲートネットリストまたは他の物理的記述は、特定用途向けＩＣ（ＡＳＩＣ）内部のエンジンを作るための工程の指示およびマスクへと変換されてもよい。
【００１１】
「エンジン」は、必要に応じ、より多くの記述名を与えられてもよい。本明細書において、さまざまなエンジンに、「スケジューラ」、「ディストリビュータ」、「ビルダ」、「マルチプレクサ」、「ジェネレータ」および「受信器」という名詞の１つを含む名前が与えられている。
【００１２】
本明細書において、「論理」という用語もまた、記述される機能を実行するハードウェアの集合を意味し、「エンジン」よりも規模が小さいことがある。「論理」は、組み合わせ論理回路と、フリップフロップ、レジスタ、および他のデータ伝搬要素を含む逐次的論理回路と、有限状態機械等の複雑な逐次的論理回路とを含む。
【００１３】
本明細書において、「装置」は、「エンジン」よりも規模が大きくありえるファームウェアおよび／またはソフトウェアによって増補されえる、ハードウェアの集合を意味する。例えば、装置は、複数のエンジンを含んでもよく、その一部は、類似の機能を並行して実行してもよい。「論理」、「エンジン」および「装置」という用語は、いかなる物理的な分離または境界をも意味しない。１つ以上の装置および／またはエンジンの全てまたは一部は、ネットワークカード等の共通カード上に配置されてもよく、またはＦＰＧＡ、ＡＳＩＣまたは他の回路装置の内部に配置されてもよい。
【００１４】
１つ以上のエンジン、論理回路および／または装置が、１つ以上のプログラム可能な半導体デバイスによって実現される場合には、プログラミングコードは、コンピュータ可読媒体に格納されてもよい。プログラミングコードは、次に、プログラム可能回路または装置を構成するために用いられてもよい。記憶媒体は、例えば、磁気媒体（ハードディスク、フロッピー（登録商標）ディスクおよび磁気テープ等）、光媒体（コンパクトディスク（ＣＤ―ＲＯＭおよびＣＤ―ＲＷ）およびデジタル多用途ディスク（ＤＶＤおよびＤＶＤ±ＲＷ）等）、フラッシュメモリカード、またはデータを格納するための別の物理的オブジェクトであってもよい。「記憶媒体」という用語は、波形および信号の伝搬等を行う一過性の媒体を含まない。
【図面の簡単な説明】
【００１５】
【図１】ネットワーク環境を示すブロック図である。
【図２】ポート装置を示すブロック図である。
【図３】トラフィックジェネレータを示すブロック図である。
【図４】優先フロー制御を有するマルチレーントラフィックジェネレータを示すブロック図である。
【図５】チャネライズドパケットバッファを示すブロック図である。
【図６】パケット形成データ（ＰＦＤ）ディストリビュータを示すブロック図である。
【図７】トラフィックジェネレータのフロー制御論理を示すフローチャートである。
【図８】トラフィックジェネレータ内のフロー制御を示すグラフ図である。
【発明を実施するための形態】
【００１６】
本明細書の全体にわたり、ブロック図に示される構成要素には、３桁の参照符号が割り当てられ、参照符号の最上位桁は構成要素が示される図面番号を示し、最下位２桁は構成要素を特定するものである。ブロック図に記載されない構成要素は、同じ参照符号を有する既述の構成要素と同じ特性および機能を有するものとみなされてよい。
【００１７】
ブロック図において、矢印線は、信号よりもむしろデータ経路を示しえる。各データ経路の幅は、複数ビットであってもよい。例えば、各データ経路は、４個、８個、１６個、６４個、２５６個、またはそれ以上の個数の並列接続から成ってもよい。
【００１８】
装置の説明
図１は、ネットワーク環境のブロック図である。この環境は、ネットワークテスト装置１００と、ネットワーク１９０と、複数のネットワーク装置１９２とを含んでもよい。
【００１９】
ネットワークテスト装置１００は、ネットワークテスト装置、性能分析装置、適合性検証システム、ネットワーク分析装置、またはネットワーク管理システムであってもよい。ネットワークテスト装置１００は、シャーシ１０２内に収容または封入される、１つ以上のネットワークカード１０６と、バックプレーン１０４とを備えてもよい。シャーシ１０２は、ネットワークテスト装置を収容するのに適切な固定型または携帯型のシャーシ、キャビネットまたは筐体であってもよい。図１に示すように、ネットワークテスト装置１００は、統合された装置であってもよい。この代わりに、ネットワークテスト装置１００は、トラフィックの生成および／または分析を提供するように協同する多くの別々の装置から成ってもよい。ネットワークテスト装置１００およびネットワークカード１０６は、さまざまなイーサネット（登録商標）規格およびファイバチャネル規格等の、１つ以上の周知の規格またはプロトコルをサポートしてもよく、特許権で保護されたプロトコルをサポートしてもよい。
【００２０】
ネットワークカード１０６は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、プログラム可能論理アレイ（ＰＬＡ）、プロセッサ、および他の種類の装置を、１つ以上備えてもよい。加えて、ネットワークカード１０６は、ソフトウェアおよび／またはファームウェアを備えてもよい。ネットワークカードという用語は、ラインカード、テストカード、分析カード、ネットワークラインカード、ロードモジュール、インタフェースカード、ネットワークインタフェースカード、データインタフェースカード、パケットエンジンカード、サービスカード、スマートカード、スイッチカード、リレーアクセスカード、等を含む。ネットワークカードという用語は、モジュール、装置、およびアセンブリをも含み、それらは複数のプリント回路基板を備えてもよい。各ネットワークカード１０６は、１つ以上のポート装置１１０を備えてもよい。各ポート装置１１０は、１つ以上のポートを介して、ネットワーク１９０に接続してもよい。各ポート装置１１０は、通信媒体１９５を介して、ネットワーク１９０に接続されてもよい。通信媒体１９５は、ワイヤ、光ファイバ、ワイヤレスリンク、または他の通信媒体であってもよい。各ネットワークカード１０６は、単一の通信プロトコルをサポートしてもよく、多くの関連プロトコルをサポートしてもよく、または多くの非関連プロトコルをサポートしてもよい。ネットワークカード１０６は、ネットワークテスト装置１００内に常設的に設置されてもよく、または着脱可能であってもよい。
【００２１】
バックプレーン１０４は、ネットワークカード１０６のバスまたは通信媒体の役割を果たしてもよい。バックプレーン１０４はまた、ネットワークカード１０６に電力を提供してもよい。
【００２２】
ネットワーク装置１９２は、ネットワーク１９０を通じて通信可能ないかなる装置でもあってもよい。ネットワーク装置１９２は、コンピューティング装置（ワークステーション、パーソナルコンピュータ、サーバ、ポータブルコンピュータ、パーソナル携帯情報機器（ＰＤＡ）、コンピューティングタブレット、携帯電話／モバイル電話、電子メール機器等）、周辺機器（プリンタ、スキャナ、ファクシミリ装置等）、ディスクドライブを備えネットワーク機能を有する記憶装置（ネットワーク接続ストレージ（ＮＡＳ）、ストレージエリアネットワーク（ＳＡＮ）装置等）、ネットワーク化装置（ルータ、リレー、ハブ、スイッチ、ブリッジ、マルチプレクサ等）であってもよい。加えて、ネットワーク装置１９２は、ネットワークを通じて通信可能な、設備、アラームシステム、および他の任意の装置またはシステムを備えてもよい。
【００２３】
ネットワーク１９０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ストレージエリアネットワーク（ＳＡＮ）、これらのワイヤード版、ワイヤレス版、またはこれらの組合せであってもよく、さらにはインターネットを含んでもよく、またはインターネットであってもよい。ネットワーク１９０上の通信は、フレーム、セル、データグラム、パケットまたは他の情報単位を含むさまざまな形態をとりえるが、本明細書においては、それらの全てをパケットと呼ぶ。ネットワークテスト装置１００およびネットワーク装置１９２は、互いに同時に通信してもよい。ネットワークテスト装置１００と所与のネットワーク装置１９５との間に、複数の論理的通信経路があってもよい。ネットワークそのものは、非常に多くのノードから成ってもよく、それらのノードは、データが伝送される非常に多くの物理経路および論理経路を提供する。
【００２４】
各ポート装置１１０は、特定の通信リンク１９５を介して、ネットワーク装置１９２上の対応するポートに接続していてもよい。状況によっては、ポート装置１１０は、ネットワーク装置１９２が適切に受信できるよりも多くのトラフィックを、ネットワーク装置１９２上の対応するポートに送信してもよい。例えば、ネットワーク装置１９２は、ネットワーク装置１９２がパケットを処理および転送できる速度よりも速い全体的速度において、複数の送信元から着信パケットを受信してもよい。この場合、ネットワーク装置１９２内のバッファメモリは、受信された未処理のパケットによって満杯にされてもよい。バッファメモリのオーバフローによるパケット損失を回避するために、ネットワーク装置１９２は、フロー制御のメッセージまたはパケットをポート装置１１０に送信してもよい。
【００２５】
例えば、ポート装置１１０およびネットワーク装置１９２が全二重イーサネット（登録商標）接続を用いて通信を行う場合、ＩＥＥＥ規格８０２．３ｘの規定により、ネットワーク装置１９２は、休止フレームまたは休止パケットをポート装置１１０に送信してもよい。休止フレームは、休止パケット内のデータによって定義される時間間隔にわたって、特定の制御パケットを除くパケットの送信を停止するように、ポート装置１１０に命令してもよい。ネットワーク装置１９２は、ゼロ（０）という時間間隔を定義する休止パケットを送信することにより、前回休止されたポート装置にパケットの送信を再開させてもよい。
【００２６】
しかしながら、サービス品質（ＱｏＳ）レベル、トラフィッククラス、またはなんらかの他の優先順位方式に従ってトラフィックに優先順位をつけるネットワークのフロー制御において、単にポート装置からの出力を休止することは、許容しえない方法でありえる。例えば、ＩＥＥＥ規格８０２．１Ｑｂｂは、受信器が８個のトラフィッククラスのフローを制御してもよいと規定している。フロー制御に影響を及ぼすために、受信器は、８個のトラフィッククラスの一部または全部を休止させるように命令する優先フロー制御（ＰＦＣ）パケットを、送信器に送信してもよい。ＰＦＣパケットは、各トラフィッククラスを休止すべき時間間隔を、独立して定義してもよい。
【００２７】
ここで図２を参照すると、例示的なポート装置２１０は、ポート中央処理装置２１２（ＣＰＵ）と、トラフィックジェネレータ装置２２０と、トラフィック受信装置２８０と、ポート装置２１０をテスト対象ネットワーク２９０に連結するネットワークインタフェース装置２７０とを備えてもよい。ポート装置２１０は、ネットワークカード１０６等のネットワークカードの全部または一部であってもよい。
【００２８】
ポートＣＰＵ２１２は、プロセッサ、該プロセッサに連結されたメモリ、および本明細書に記載される機能および特徴を提供するためのさまざまな特殊な装置、回路、ソフトウェア、およびインタフェースを備えてもよい。工程、機能、および特徴は、プロセッサ上で動作するソフトウェアによって、全体的または部分的に実現されてもよく、ファームウェア、アプリケーションプログラム、アプレット（例えばＪａｖａ（登録商標）アプレット）、ブラウザのプラグイン、ＣＯＭオブジェクト、動的リンクライブラリ（ＤＬＬ）、スクリプト、１つ以上のサブルーチン、またはオペレーティングシステムのコンポーネントまたはサービス、といった形態であってもよい。プロセッサおよび他の装置の他の部分によってなんらかの機能が実行されるように、ハードウェア、ソフトウェア、およびそれらの機能は、分散型であってもよい。
【００２９】
ポートＣＰＵ２１２は、テストアドミニストレータ２０５と通信してもよい。テストアドミニストレータ２０５は、オペレータインタフェース２０７と通信してもよく、またはオペレータインタフェース２０７を備えてもよい。テストアドミニストレータ２０５は、ネットワークテスト装置１００の内部に含まれるかまたは外部にあるコンピューティング装置であってもよい。テストアドミニストレータ２０５は、ネットワーク２９０のテストに関与する際に、ポート装置が必要とする命令およびデータを、ポートＣＰＵ２１２に提供してもよい。テストアドミニストレータ２０５から受信される命令およびデータは、例えば、ポート装置２１０によって生成されるべきパケットストリームの定義と、ポート装置２１０によって蓄積および報告されえる性能統計の定義とを含んでもよい。
【００３０】
ポートＣＰＵ２１２は、複数のストリームを形成するストリーム形成データ２１４を、トラフィックジェネレータ装置２２０に提供してもよい。ストリーム形成データ２１４は、例えば、パケットのタイプ、送信の頻度、パケット内の固定コンテンツフィールドおよび可変コンテンツフィールドの定義、および各パケットストリームのための他の情報を含んでもよい。トラフィックジェネレータ装置２２０は、次に、ストリーム形成データ２１４に従って、複数のストリームを生成してもよい。複数のストリームは、インタリーブされることにより発信トラフィック２６５を形成してもよい。ストリームの各々は、一連のパケットを含んでもよい。各ストリーム内のパケットは、同じ一般的なタイプであってもよいが、長さおよびコンテンツは異なっていてもよい。
【００３１】
ネットワークインタフェース装置２７０は、トラフィックジェネレータ装置２２０からの発信トラフィック２６５を、電気信号、光学信号または無線信号のフォーマットに変換してもよい。そのフォーマットは、リンク２９５を介してテストトラフィックをテスト対象ネットワーク２９０に送信するために必要なものである。リンク２９５は、ワイヤリンク、光ファイバリンク、ワイヤレスリンク、または他の通信リンクであってもよい。同様に、ネットワークインタフェース装置２７０は、ネットワークからリンク２９５を介して電気信号、光学信号または無線信号を受信してもよく、受信した信号を、トラフィック受信装置２８０が使用できるフォーマットの着信トラフィック２７５へと変換してもよい。
【００３２】
トラフィック受信装置２８０は、ネットワークインタフェース装置２７０から、着信トラフィック２７５を受信してもよい。トラフィック受信装置２８０は、各受信パケットが特定のフローの部分であるかどうかを判定してもよく、ポートＣＰＵ２１２によって提供されるテスト命令２１８に従って、各フローのテスト統計を蓄積してもよい。蓄積されるテスト統計は、例えば、受信されたパケットの合計数、順番誤りで受信されたパケットの数、エラーとともに受信されたパケットの数、伝搬遅延の最大値、平均値および最小値、および各フローの他の統計を含んでもよい。トラフィック受信装置２８０は、テスト命令２１８に含まれる獲得基準に従って、特定のパケットを獲得および格納してもよい。トラフィック受信装置２８０は、テストセッション中またはテストセッション後のさらなる分析のために、テスト命令２１８に従って、テスト統計および／または獲得したパケット２８４を、ポートＣＰＵ２１２に提供してもよい。
【００３３】
テストセッション中に、ポート装置２１０とネットワーク２９０との間で、若干の双方向通信が必要とされるかまたは所望されることもある。例えば、トラフィック受信装置２８０は、制御パケットを受信してもよい。制御パケットは、テストセッションを制御するために必要なデータを含むパケットであり、ポート装置２１０は、それに対して受信通知または応答を送信する必要がある。トラフィック受信装置２８０は、着信制御パケットを、着信トラフィックから分離してもよく、着信制御パケット２８２を、ポートＣＰＵ２１２へとルーティングしてもよい。ポートＣＰＵ２１２は、各制御パケットのコンテンツを抽出してもよく、発信ＣＰＵトラフィック２１６という形にて、適切な応答を生成してもよい。発信ＣＰＵトラフィック２１６は、トラフィックジェネレータ装置２２０に提供されてもよい。トラフィックジェネレータ装置２２０は、発信ＣＰＵトラフィック２１６を、発信トラフィック２６５の中に挿入してもよい。
【００３４】
トラフィックジェネレータ装置２２０からの発信トラフィック２６５は、独立して休止されえる「フロー制御グループ」へと分割されてもよい。例えば、発信トラフィック２６５は、ＩＥＥＥ８０２．１Ｑｂｂに従って、８個のトラフィッククラスに対応する８個のフロー制御グループへと分割されてもよい。発信トラフィック２６５は、ＩＥＥＥ８０２．１Ｑｂｂに従って８個のトラフィッククラスに対応する８個のフロー制御グループと、休止されなくてもよい制御トラフィックおよび他のトラフィックのための第９のフロー制御グループへと、分割されてもよい。トラフィックジェネレータ装置２２０によって生成される各ストリームは、フロー制御グループに割り当てられてもよい。各フロー制御グループは、０個、１個、または複数のストリームを含んでもよい。ポート装置２２０によって受信されえる制御パケットの１つの形式は、フロー制御パケットであってもよく、例えば、ＩＥＥＥ８０２．３ｘまたはＩＥＥＥ８０２．１Ｑｂｂに従うものであってもよい。フロー制御パケットは、トラフィック受信装置２８０内で認識されてもよい。フロー制御パケット２８６に由来する、フロー制御パケットおよび／またはフロー制御データは、トラフィック受信装置２８０からトラフィックジェネレータ装置２２０へと直接的に提供されてもよい。
【００３５】
以下の説明に含まれる例において、ネットワークテスト装置のポート装置とネットワーク装置との間のフロー制御は、ＩＥＥＥ８０２．１Ｑｂｂに従うフロー制御パケットを用いて管理される、と仮定することがある。しかしながら、説明される装置および方法は、現在または将来の他の優先フロー制御方式との互換性を有し、８個より多いかまたは少ないトラフィッククラスをも含む。
【００３６】
ここで図３を参照すると、例示的なトラフィックジェネレータ３２０は、複数のパケットのストリームから成る発信トラフィック３６５を生成してもよい。トラフィックジェネレータは、例えば、１６のストリーム、６４個のストリーム、２５６個のストリーム、５１２個のストリーム、または他の個数のストリームを生成することが可能であり、ストリームを任意の組合せでインタリーブすることにより、テストトラフィックを提供してもよい。例示的なトラフィックジェネレータ３２０は、図２のトラフィックジェネレータ装置２２０であってもよく、図１に示すネットワークカード１０６の全体または一部であってもよい。
【００３７】
トラフィックジェネレータ３２０は、スケジューラ３３０を備えてもよい。所望の通信速度は、トラフィックジェネレータ３２０によって生成されるべき複数のストリームの各々に関連づけられてもよい。スケジューラ３３０は、各ストリームが発信トラフィック３６５にパケットを与えるべき時間を示す、カウンタまたは仮想カウンタ等の調時機構を、ストリームごとに備えてもよい。２つ以上のストリームが同時にパケットを与えようとする際に、その状況におけるパケットシーケンスを判定するために、スケジューラ３３０は、アービトレーション論理を備えてもよい。スケジューラ３３０は、ハードウェア、またはハードウェアとソフトウェアとの組合せによって実現されてもよい。例えば、米国特許第７，６１６，５６８Ｂ２号明細書は、リンクされたデータ構造と、単一のハードウェアタイマとを用いる、スケジューラを開示している。米国特許出願公報第２０１１／０００２２２８Ａ１号明細書は、複数のハードウェアタイマを用いるスケジューラを開示している。
【００３８】
スケジューラ３３０は、生成されるパケットごとに、パケット定義データ３３２を出力してもよい。パケット定義データ３３２は、生成されるパケットを定義するために必要なデータを含んでもよいが、パケットを生成するために必要なすべてのデータを必ずしも含まなくともよい。生成される各パケットは、複数のストリームの１つに属するものであり、パケット定義データ３３２は、例えば、対応するストリームを識別するストリーム識別子を含んでもよい。パケット定義データ３３２は、形成されるべきパケットのタイプ、長さ、または他の特性を識別するデータを含んでもよい。
【００３９】
トラフィックジェネレータ３２０によって生成される各パケットは、ステートフルコンテンツおよびステートレスコンテンツを含んでもよい。「ステートフルコンテンツ」とは、同一ストリーム内の前のパケットのコンテンツに依存するコンテンツである。ステートフルコンテンツの例としては、ストリーム内のパケットに割り当てられる逐次的なシーケンス番号、および前のパケット内の同一フィールドのコンテンツにオフセットを追加することに由来するパケット内のアドレスまたは他のフィールドが挙げられる。トラフィックジェネレータは、ステートフルな各コンテンツアイテムについての履歴または「状態」を維持しなければならないので、このようなコンテンツは「ステートフル」とみなされる。対照的に、「ステートレスコンテンツ」とは、前のパケットのコンテンツに依存しないコンテンツである。ステートレスコンテンツの例としては、ランダムに生成されるペイロードコンテンツ、ストリーム内のパケット間で異ならない固定コンテンツ、およびパケットの現在のコンテンツに基づいて生成されるチェックサムが挙げられる。「ステートフルコンテンツ」および「ステートレスコンテンツ」は、ネットワークを介するステートフル接続およびステートレス接続と混同されるべきではない。
【００４０】
トラフィックジェネレータ３２０は、ステートフルコンテンツジェネレータ３４５を備えてもよい。ステートフルコンテンツジェネレータ３４５は、スケジューラ３３０から出力されるパケット定義データ３３２に関連づけられるステートフルコンテンツ３４７を生成してもよい。パケット定義データ３３２とそれに関連づけられるステートフルコンテンツとの組合せを、本明細書においては「パケット形成データ」３４７と呼ぶ。
【００４１】
パケット形成データ３４７は、ステートレスパケットビルダ３５０に提供されてもよい。ステートレスパケットビルダ３５０は、対応するパケット形成データ３４７に基づいて、各パケットの生成を終了してもよい。パケット形成データに含まれるストリーム識別子に従って、ステートレスパケットビルダ３５０は、パケットごとにパケットテンプレートを読み出してもよい。パケットテンプレートは、ストリーム内のパケット間で異ならない固定データを含んでもよい。ステートレスパケットビルダは、次に、パケット形成データからステートフルコンテンツをテンプレート内の適切なフィールドの中に挿入し、ペイロードコンテンツおよび他のステートレスコンテンツを生成し、パケット内のチェックサムを生成および配置し、各パケットを完成するために必要な他のタスクを実行してもよい。
【００４２】
単一のステートレスパケットビルダは、回線速度において最新の高速ネットワークをテストするために充分なパケットを構築するには、非実用的でありえる。したがって、ステートレスパケットビルダは、複数の平行レーンを含んでもよい。各レーンは、独立してパケットを構築する能力を有してもよい。複数のレーンが存在することにより、レーンの個数にほぼ比例して、パケットを生成可能な速度も上昇することがある。図３は、４個のレーンを有するステートレスパケットビルダ３５０を示す。しかしながら、ステートレスパケットビルダは、４個よりも多いレーンまたは少ないレーンを有してもよい。
【００４３】
ステートレスパケットビルダ３５０によって構築されるパケットは、出力マルチプレクサ３６０に配信されてもよい。出力マルチプレクサ３６０は、ステートレスパケットビルダ３５０およびＣＰＵトラフィック３１６のチャネルからのパケットをインタリーブすることにより、発信トラフィック３６５を形成してもよい。出力マルチプレクサは、各パケットの伝送時間を示すタイムスタンプを追加したり、巡回冗長検査値を追加または調整したりする等の、パケットの仕上げ作業を、送信前に実行してもよい。
【００４４】
ステートレスパケットビルダ３５０のレーンからのパケットが確実に所望の順序でインタリーブされるようにするために、出力マルチプレクサ３６０は、スケジューラ３３０からパケットシーケンスデータ３３４を受信してもよい。パケットシーケンスデータ３３４は、発信トラフィックについての必要な送信順序を示してもよい。「パラレルコヒーレント送信エンジンを用いるトラフィックジェネレータ」という名称の米国特許第７，７６９，０４９Ｂ２号明細書は、スケジューラによって提供されるパケットシーケンスデータに従って、複数の送信エンジン（ステートレスパケットビルダ）からのパケットをインタリーブする、マルチレーントラフィックジェネレータを開示している。
【００４５】
いかなる時点においても、１つ以上のパケットがステートレスパケットビルダ内で処理中でありえるように、ステートレスパケットビルダ３５０の各レーンは、複数の逐次的ステージを含むパイプラインとして構成されてもよい。ステートレスパケットビルダは、処理ステージ間または処理ステージ中にパケットを保持するように、内部ＦＩＦＯ（先入先出）待ち行列を含んでもよい。特定のパケットのためのパケット形成データがステートレスパケットビルダに入力されてから、完成パケットがステートレスパケットビルダから出力されるまでの遅延は、特定のパケットの長さおよび／またはコンテンツ、およびパイプライン内の特定のパケットに先行するパケットの長さおよび／またはコンテンツに依存することがある。
【００４６】
ＩＥＥＥ８０２．１Ｑｂｂに従う優先フロー制御を実現するためには、他のフロー制御グループのパケットの送信が絶え間なく続いている間に、１つ以上の指定されたフロー制御グループ内でパケットの送信を休止する能力が必要とされる。休止されたフロー制御グループ内のパケットのスケジューリングを単に禁止するだけでは不十分なことがある。なぜなら、ステートレスパケットビルダのパイプラインのパケットが完成して送信される際に、休止されたフロー制御グループ内のパケットの送信が、かなりの時間間隔にわたって続くことがあるからである。休止されたフロー制御グループの処理中パケットが、ステートレスパケットビルダ内で停止できる場合には、フロー制御コマンドに対して、より即座に応答しえる。しかしながら、この場合には、休止されていないフロー制御グループのパケットは、ステートレスパケットビルダのパイプラインに沿って、停止されたパケットを渡すことができなければならない。
【００４７】
「優先フロー制御を有するトラフィックジェネレータ」という名称の同時係属米国特許出願第１２／７６６，７０４号明細書は、トラフィックジェネレータにおいて、パケットジェネレータ（ステートレスパケットビルダ）の内部ＦＩＦＯ待ち行列がチャネライズされることを開示している。本明細書において、「チャネライズド」という用語は、「複数のパラレルチャネルを有し、各チャネルが、複数のフロー制御グループの対応する１つに一意に関連づけられる」ということを意味する。「一意に関連づけられる」という用語は、一対一対応を意味する。チャネライズドＦＩＦＯ待ち行列の各チャネルは、対応するフロー制御グループについて、処理中データおよび処理中パケットの格納に専用されてもよい。チャネライズド各ＦＩＦＯ待ち行列は、休止されていないトラフィッククラスのパケットがトラフィックジェネレータ内で停止されたパケットを渡す機会を提供する。
【００４８】
マルチレーンステートレスパケットビルダを用いて高速度トラフィックジェネレータの優先フロー制御を実現する際に必要とされる、チャネライズド待ち行列専用のメモリ容量は、非実用的でありえる。例えば、米国特許出願第１２／７６６，７０４号明細書に開示された方法によると、４個のステートレスパケットビルダのレーンと９個のフロー制御グループとを有するトラフィックジェネレータは、３６個のチャネル（４個の各レーン内に９個のチャネル）を有するＦＩＦＯ待ち行列を必要としえる。特に、フィールドプログラマブルゲートアレイまたは他のプログラム可能な回路装置を用いてトラフィックジェネレータを実現する際には、このように多数のパラレルＦＩＦＯ待ち行列は、非実用的でありえる。
【００４９】
ここで図４を参照すると、例示的なトラフィックジェネレータ４２０は、非常に高い回線速度において発信トラフィックを生成し、マルチレベルの優先フロー制御を提供しえる。トラフィックジェネレータ４２０は、スケジューラ４３０と、ステートフルコンテンツジェネレータ４４０と、マルチレーンステートレスパケットビルダ４５０と、出力マルチプレクサ４６０とを含んでもよい。これらは一般に、図３のトラフィックジェネレータ３２０の対応構成要素について記載されているように機能するものである。トラフィックジェネレータ４２０は更に、スケジューラ４３０によって提供されるパケット定義データを格納する、チャネライズドスケジュールＦＩＦＯ４３５と、ステートレスパケットビルダ４５０によって提供される完成パケットを格納する、チャネライズドパケットバッファ４５５とを備えてもよい。
【００５０】
スケジューラ４３０は、例えば１６個のストリーム、６４個のストリーム、２５６個のストリーム、５１２個のストリーム、または他のなんらかの個数のストリームといった、複数のストリームをスケジューリングしてもよい。スケジューラ４３０は、各ストリームが発信トラフィック４６５にパケットを与えるべき時間を示す、カウンタまたは仮想カウンタ等の調時機構を、ストリームごとに備えていてもよい。２つ以上のストリームが同時にパケットを与えようとする際に、その状況におけるパケットシーケンスを判定するために、スケジューラ４３０は、アービトレーション論理を備えていてもよい。
【００５１】
スケジューラ４３０は、生成されるパケットごとに、パケット定義データ４３２を出力してもよい。パケット定義データ４３２は、生成されるパケットを定義するために必要なデータを含んでもよいが、パケットを生成するために必要なすべてのデータを必ずしも含まなくともよい。生成される各パケットは、複数のストリームの１つに属するものであり、パケット定義データ４３２は、例えば、対応するストリームを識別するストリーム識別子を含んでもよい。各ストリーム、およびパケット定義データの各パケットおよび各項目は、複数のフロー制御グループの１つに関連づけられていてもよい。例えば、各ストリームは、ＩＥＥＥ８０２．１Ｑｂｂに従って８個のトラフィッククラスに対応する８個のフロー制御グループを含む９個のフロー制御グループと、休止されなくてもよい制御トラフィックおよび他のトラフィックのための第９のフロー制御グループとに、関連づけられてもよい。パケット定義データ４３２は、各パケットに関連づけられるフロー制御グループを識別するフロー制御グループ識別子を含んでもよい。
【００５２】
ストリームとフロー制御グループとの間の関連づけは、固定されていてもよく、またはプログラム可能であってもよい。例えば、スケジューラ４３０は、各ストリーム識別子を関連づけられるフロー制御グループへとマッピングするデータを格納する、マップメモリ（図示せず）を備えてもよい。関連づけられるフロー制御グループへと各ストリーム識別子をマッピングするデータは、テストセッション前にマップメモリにロードされてもよく、テストセッション中に修正可能であってもよい。
【００５３】
チャネライズドスケジュール待ち行列４３５は、スケジューラ４３０から出力されるパケット定義データ４３２を格納してもよい。チャネライズドスケジュール待ち行列４３５の各チャネルは、先入れ先出しの態様で機能してもよい。チャネライズドスケジュール待ち行列４３５の各チャネルは、関連づけられるフロー制御グループについて、パケット定義データの格納に専用されてもよい。チャネライズドスケジュール待ち行列４３５は、チャネライズドスケジュール待ち行列の１つ以上のチャネルが満杯であるかどうかを示すフィードバック４３７を、スケジューラ４３０に提供してもよい。スケジューラ４３０は、チャネライズドスケジュール待ち行列４３５の１つ以上の満杯のチャネルに関連づけられるスケジューリングパケットストリームを保留してもよい。
【００５４】
ＰＦＤ（パケット形成データ）ディストリビュータ４４５は、チャネライズドスケジュール待ち行列４３５から読み込まれるパケット定義データ４３２を、ステートフルコンテンツジェネレータ４４０からのステートフルコンテンツ４４２と組み合わせることにより、パケット形成データ４４７を生成してもよい。ＰＦＤディストリビュータ４４５は、パケットごとのパケット形成データを、ステートレスパケットビルダ４５０のレーンの１つに転送してもよい。ＰＦＤディストリビュータ４４５の操作については、さらに詳細に後述する。
【００５５】
前述したように、ステートレスパケットビルダ４５０は、対応するパケット形成データに基づいて、各パケットの生成を終了してもよい。ステートレスパケットビルダ４５０は、複数の非チャネライズドパラレルレーンを含んでもよい。本特許においては、「非チャネライズド」は、チャネルがないことを意味する。具体的には、非チャネライズドパケットビルダ内の内部待ち行列は、１つのパケットがパイプライン内の他を通過できるようにするパラレル経路を有さない。したがって、一旦開始されると、各パケットは、レーン内の次のパケットが完成されえる前に、ステートレスパケットビルダのパイプラインの逐次的ステージの全てを通過してレーンから出なければならない。
【００５６】
ステートレスパケットビルダ４５０は、レーン出力フィードバック４５２を、ＰＦＤディストリビュータ４４５に提供してもよい。レーン出力フィードバック４５２は、ステートレスパケットビルダ４５０が完成パケットをチャネライズドパケットバッファ４５５に転送した、ということを示してもよい。レーン出力フィードバック４５２は、完成パケットの長さとレーン識別子とを含んでもよい。
【００５７】
ステートレスパケットビルダ４５０から出力された完成パケットは、チャネライズドパケットバッファ４５５に格納されてもよい。チャネライズドパケットバッファ４５５の各チャネルは、メモリへのパケット書き込みおよびメモリからのパケット読み込みを制御する、メモリおよび論理のブロックを含んでもよい。チャネライズドパケットバッファ４５５の各チャネルは、関連づけられるフロー制御グループについて、完成パケットの格納に専用されてもよい。
【００５８】
一部のフロー制御グループは、他のフロー制御グループからのパケット送信が続いている間に休止されえるので、フロー制御グループ間のパケットの相対的な順序を保証することはできない。各フロー制御グループ内のパケットの順序は保護されえる。すなわち、発信トラフィック４６５の中にパケットが組み込まれる順序は、パケットがスケジューリングされた順序と同じでありえる。この目的で、チャネライズドパケットバッファ４５５は、パケットシーケンスデータ４３４を、ＰＦＤディストリビュータ４４５から受信してもよい。チャネライズドパケットバッファ４５５内の論理は、パケットシーケンスデータを用いることにより、各チャネル内のスケジューリングされた順序で完成パケットを格納してもよい。
【００５９】
チャネライズドパケットバッファ４５５は、従来の先入れ先出し待ち行列として機能しなくてもよい。例えばここで、パケットＡおよびパケットＢは、同じフロー制御グループに属しており、かつ「Ａの次にＢが続く」順序で送信されるようにスケジューリングされている、と仮定する。パケットＡは、ステートレスパケットビルダの第１のレーンに割り当てられ、パケットＢは、ステートレスパケットビルダの第２のレーンに割り当てられる。パケットＢがパケットＡよりも実質的に短い場合には、パケットＢは、パケットＡよりも前に完成され、チャネライズドパケットバッファ４５５に格納されてもよい。この状態において、先入れパケット（パケットＢ）は、先出しパケットであることを意図しない。
【００６０】
出力マルチプレクサ４６０は、チャネライズドパケットバッファ４５５のチャネルからのパケットをインタリーブすることにより、発信トラフィック４６５を形成してもよい。出力マルチプレクサ４６０は、発信トラフィック４６５にパケットが追加される順序を選択するために、様々な周知技術のいずれを用いてもよい。例えば、出力マルチプレクサ４６０は、利用可能な場合には、ラウンドロビン技術を用いることにより、逐次的順序で各チャネルからパケットを読み出してもよい。出力マルチプレクサ４６０は、各チャネルに格納されるパケットの数に基づいて、またはチャネルに割り当てられる所定の優先順に基づいて、パケットを選択してもよい。出力マルチプレクサ４６０は、公平なアクセスアルゴリズムに基づき、またはなんらかの他の態様で、パケットを選択してもよい。
【００６１】
出力マルチプレクサは、フロー制御論理４６４からフロー制御データ４６６を受信してもよい。フロー制御データ４６６は、チャネライズドパケットバッファ４５５およびチャネライズドスケジュール待ち行列４３５の複数のチャネルに対応する複数のフロー制御グループの各々が、休止されるか否かを示してもよい。フロー制御グループが休止される場合には、出力マルチプレクサ４６０は、チャネライズドパケットバッファの関連づけられたチャネルからパケットを読み込むことを中止してもよい。フロー制御論理４６４は、フロー制御パケット４８６を受信および復号することにより、フロー制御データ４６６を提供してもよい。
【００６２】
出力マルチプレクサ４６０は、ＰＦＤディストリビュータ４４５に、チャネル出力フィードバック４６２を提供してもよい。チャネル出力フィードバック４６２は、出力マルチプレクサ４６０がチャネライズドパケットバッファ４５５のチャネルの１つからパケットを取り出した、ということを示してもよい。チャネル出力フィードバック４６２は、取り出されたパケットの長さとチャネル識別子とを含んでもよい。
【００６３】
図５のブロック図に示すチャネライズドパケットバッファ５００は、トラフィックジェネレータ４２０内のチャネライズドパケットバッファ４５５として用いるのに適切なものでありえる。チャネライズドパケットバッファ５００は、例示的なものであり、チャネライズドパケットバッファは、他の態様でも実現可能である。チャネライズドパケットバッファ５００は、ステートレスパケットビルダ（例えばステートレスパケットビルダ４５０）のＮ個のレーンから、完成パケットを受信し、各完成パケットを、Ｍ個のパケットバッファメモリの１つに格納してもよい（これらのうち、パケットバッファ５１０−１およびパケットバッファ５１０−Ｍのみを図示する）。ここで、ＮおよびＭは、１よりも大きい整数である。前例に続けて、Ｎは４であってもよく、Ｍは９であってもよい。完成パケットは、メモリアクセス論理５２０を介して、Ｎ個のレーンからＭ個のパケットバッファへと転送されてもよい。メモリアクセス論理５２０は、任意のレーンからのパケットをパケットバッファのいずれかに書き込むことを可能にしてもよく、２つ以上のレーンからのパケットをそれぞれのパケットバッファに同時に書き込むことを可能にしてもよい。メモリアクセス論理５２０は、一般にクロスバースイッチとして機能してもよい。但し、メモリアクセス論理５２０の実現態様は、物理的なクロスバーマトリックスではなくともよい。
【００６４】
各パケットバッファ５１０−１乃至５１０−Ｍは、循環式バッファとして用いられるランダムアクセスメモリブロックであってもよい。すなわち、メモリブロック内の最高アドレスに対してデータの読み込みまたは書き込みが行われた後に、メモリブロック内の最低アドレスに対して次のデータの読み込みまたは書き込みが行われる。各パケットバッファ５１０−１乃至５１０−Ｍに対してデータの読み込みおよび書き込みが行われる位置は、それぞれの読取ポインタおよび書込ポインタによって制御されてもよい。
【００６５】
チャネライズドパケットバッファは、各パケットバッファ５１０−１乃至５１０−Ｍに一意に関連づけられる読取ポインタ（ＲＰ）５１４−１乃至５１４−Ｍを含んでもよい。各読取ポインタ５１４−１乃至５１４−Ｍは、出力マルチプレクサ（出力マルチプレクサ４６０等）によってパケットが出力バッファから取り出される際に次に読み込まれる、それぞれのパケットバッファ内のアドレスを示してもよい。チャネライズドパケットバッファ５００は、ステートレスビルダの各レーンに関連づけられる書込ポインタ先入れ先出し待ち行列（ＷＰＦＩＦＯ）を含んでもよい（これらのうち、ＷＰＦＩＦＯ待ち行列５３０−１および５３０−Ｎのみを図示する）。ＷＰＦＩＦＯ内の各エントリは、関連づけられるステートレスパケットビルダチャネルから出力される対応パケットが格納される、開始アドレスを示してもよい。チャネライズドパケットバッファは、各パケットバッファ５１０−１乃至５１０−Ｍに一意に関連づけられる、次パケットポインタ（ＮＰＰ）５１２−１乃至５１２−Ｍを含んでもよい。各ＮＰＰは、現在はパケットを格納せず、かつステートレスパケットビルダレーン内で処理中のパケットの格納にもコミットされていない、関連づけられたパケットバッファ内に、最低アドレスを格納してもよい。
【００６６】
書込制御論理５４０は、ＷＰＦＩＦＯ５３０−１乃至５３０−Ｎに置かれる書込ポインタを生成してもよく、ＰＦＤディストリビュータ（ＰＦＤディストリビュータ４４５等）から受信されるパケットシーケンスデータ４３４に基づいて、ＮＰＰ５１２−１乃至５１２−Ｍの値を更新してもよい。ＰＦＤディストリビュータが、ステートレスパケットビルダ４５０のレーンの１つにパケットを割り当てるたびに、パケットシーケンスデータ４３４は、ＰＦＤディストリビュータから書込制御論理５４０へと送信されてもよい。パケットごとのＰＦＤは、レーン識別子、フロー制御グループ／パケットバッファ識別子、およびパケット長を含んでもよい。書込制御論理５４０は、このデータを用いることにより、識別されたステートレスパケットビルダレーンに関連づけられるＷＰＦＩＦＯ５３０−１乃至５３０−Ｎに書込ポインタを追加し、識別されたパケットバッファに関連づけられるＮＰＰ５１２−１乃至５１２−Ｍを再計算してもよい。
【００６７】
前例に続けて、パケットＡおよびＢは、パケットバッファ５１０−１に関連づけられるフロー制御グループに属する、と仮定する。ＰＦＤディストリビュータが、ステートレスパケットビルダ４５０の第１のレーンにパケットＡを割り当てると、ＰＦＤディストリビュータは、パケットＡに関連づけられるパケットシーケンスデータをも書込制御論理５４０に送信する。書込制御論理５４０は、次に、パケットバッファ５１０−１用のＮＰＰ５１２−１を、第１のレーンに関連づけられるＷＰＦＩＦＯの後ろにコピーし、以前のＮＰＰ５１２−１の値にパケットＡの長さを追加することにより、パケットバッファ５１０−１用の新たなＮＰＰを算出する。パケットＡの長さをＮＰＰの値に追加することは、ステートレスパケットビルダの第１のレーンによってパケットＡが配信される際に、パケットバッファ５１０−１の一部がパケットＡを格納するコミットメントを反映することである。同様に、ＰＦＤディストリビュータが、ステートレスパケットビルダの第２のレーンにパケットＢを割り当てる際に、ＰＤＦディストリビュータは、パケットＢに関連づけられるパケットシーケンスデータをも書込制御論理５４０に送信する。書込制御論理は、次に、第２のレーンに関連づけられるＷＰＦＩＦＯの後ろに、ＮＰＰ５１２−１の新たな値をコピーし、ＮＰＰ５１２−１の前の値に、パケットＢの長さを追加する。したがって、ステートレスパケットビルダレーンから受信されたパケットは、パケットがスケジューリングされた順序で格納される。その順序は必ずしも、パケットがチャネライズドパケットバッファにおいて受信された順序であるというわけではない。
【００６８】
図６のブロック図に示すＰＦＤディストリビュータ６００は、トラフィックジェネレータ４２０のＰＦＤディストリビュータ４４５として用いるのに適切なものでありえる。ＰＦＤディストリビュータ６００は、例示的なものであり、ＰＦＤディストリビュータは、他の態様でも実現可能である。ＰＦＤディストリビュータ６００は、チャネライズドスケジュール待ち行列（チャネライズドスケジュール待ち行列４３５等）のＮ個のレーンから、パケット定義データを受信してもよい。ＰＦＤディストリビュータ６００は、ステートレスパケットビルダ（ステートレスパケットビルダ４５０等）のＭ個のレーンに、パケット形成データ４４７を送信してもよい。前例に続けて、Ｎは９に等しくともよく、Ｍは４に等しくともよい。パケット形成データ４４７は、パケット定義データと、それに関連づけられるステートフルコンテンツ４４２とを含んでもよい。ＰＦＤディストリビュータ６００は、チャネルセレクタ６０５と、レーンセレクタ６１０とを備えてもよい。
【００６９】
チャネルセレクタ６０５は、チャネライズドスケジュール待ち行列のＮ個のチャネルから、パケット定義データ４３２を取り出してもよい。チャネルセレクタ６０５は、パケット定義データがチャネライズドスケジュール待ち行列のチャネルから読み込まれる順序を選択するために、様々な周知技術のいずれを用いてもよい。例えば、チャネルセレクタ６０５は、利用可能な場合には、ラウンドロビン技術を用いることにより、逐次的順序で各チャネルからパケット定義データを読み出してもよい。チャネルセレクタ６０５は、チャネライズドスケジュール待ち行列の各チャネルに格納されるデータ項目の数に基づき、またはチャネルに割り当てられる所定の優先順に基づき、チャネルを選択してもよい。チャネルセレクタ６０５は、公平なアクセスアルゴリズムに基づき、またはなんらかの他の態様で、チャネルを選択してもよい。
【００７０】
前述したように、ＰＦＤディストリビュータ６００は、マルチレーン非チャネライズドステートレスパケットビルダに、パケット形成データを提供してもよい。非チャネライズドパケットビルダは、処理中のパケットをレーン内で互いに通過させないので、同一レーン内において次のパケットが完成されえる前に、所与のレーンに割り当てられる各パケットは、完成されて、チャネライズドパケットバッファ（チャネライズドパケットバッファ４５５等）の送信先チャネルへと転送されなければならない。ステートレスパケットビルダの１つ以上のレーンをブロックすることを回避するためには、チャネライズドパケットバッファの送信先チャネルが完成パケットを格納するのに充分な使用可能スペースを有する場合にのみ、ＰＦＤディストリビュータは、パケット形成データ４４７をステートレスパケットビルダに送信してもよい。
【００７１】
チャネルセレクタ６０５は、パケットバッファモデル６２５を維持してもよい。パケットバッファモデルは、チャネライズドパケットバッファの各チャネルの現在の使用可能容量を示してもよい。この目的で、チャネルセレクタ６２５は、チャネライズドパケットバッファの各チャネルから読み込まれたパケットの長さを示す、チャネル出力フィードバックを受信してもよい。各チャネルの使用可能容量とは、（ａ）１つ以上の完成パケットを格納するために現在用いられておらず、かつ（ｂ）ステートレスパケットビルダ内で現在処理中のパケットを格納するために割り当てられていない、メモリ容量である。したがって、各チャネルの使用可能容量とは、チャネルに関連づけられるフロー制御グループが休止され、かつすべての処理中パケットがステートレスパケットビルダによって完成した場合に残りえる、メモリ容量を示すものである。チャネルセレクタは、以下の数式を用いて、各パケットバッファチャネルの使用可能容量をモデル化してもよい。
（使用可能容量）＝（メモリサイズ）−（パケットビルダに割り当てられるパケットの全体長）＋（パケットバッファから読み込まれるパケットの全体長）（１）
【００７２】
ＰＦＤディストリビュータ６００は、ステートレスパケットビルダのＭ個のレーンの１つを選択し、かつ構築されるべきパケットごとにパケット形成データ４４７を受信する、レーンセレクタを備えてもよい。レーンセレクタは、負荷分散アルゴリズムを用いて、レーンを選択してもよい。例えば、レーンセレクタは、ステートレスパケットジェネレータの各レーンの利用可能容量を示す、レーン帯域幅モデル６３０を維持してもよい。レーン帯域幅モデルは、各レーンに割り当てられるパケットの累計長、各レーンにおいて現在処理中のパケットの全体長、またはレーン帯域幅の他のなんらかの測定を追跡してもよい。この目的で、レーンセレクタは、各レーンがチャネライズドパケットバッファに完成パケットを転送する時間を示す、レーン出力フィードバック４５２を受信してもよい。レーンセレクタは、パケット形成データの新たな各項目を、最も利用可能な帯域幅を有するレーンに送信してもよい。
【００７３】
工程の説明
ここで図７を参照すると、トラフィックを生成するための全工程７００は、工程７０５で開始してもよく、多数のパケットが生成された後に工程７９５で終了してもよく、またはオペレータのアクション（図７に図示せず）によって停止されることもある。全工程７００は、トラフィックジェネレータ（トラフィックジェネレータ３２０またはトラフィックジェネレータ４２０等）を用いてトラフィックを生成するために適切なものでありえる。全工程７００は、事実上、巡回的かつリアルタイムなものであってもよい。図７のフローチャートは、単一のポート装置によって実行される工程７００を示す。全工程７００は、テストセッション中に複数のポート装置によって同時に並行して実行されてもよい、ということを理解すべきである。
【００７４】
工程７０５において全工程７００を開始する前に、テストセッションが設計されていてもよい。テストセッションの設計は、例えば、１つ以上のポート装置（ポート装置２１０等）に連結されたテストアドミニストレータのコンピューティング装置（テストアドミニストレータ２０５等）によって行われてもよい。テストセッションを設計することは、ネットワークまたはネットワーク装置のアーキテクチャを判定または定義することと、テストセッション中に各ポート装置によって生成されるべきストリームを定義することと、対応するストリーム形成データを生成することと、それぞれのストリーム形成データを少なくとも１つのポート装置に転送することとを含んでもよい。テストセッションを設計することは、複数のフロー制御グループ（ＦＣＧ）を定義することと、各ストリームを１つのＦＣＧに関連づけることとを更に含んでもよい。ストリームとＦＣＧとの間の関連づけを定義するＦＣＧマップデータを、各ポート装置に提供してもよい。例えば、ＦＣＧマップデータは、各ポート装置内のＦＣＧマップメモリ（メモリ４２４等）に書き込まれてもよい。
【００７５】
工程７１０において、トラフィックジェネレータは、パケットを形成および送信することにより、トラフィックを生成してもよい。工程７１５において、フロー制御（ＦＣ）パケットが受信されたか否かを判定してもよい。フロー制御パケットが受信されなかった場合には、工程７２０において、生成されるべきパケットが更にあるか否かを判定してもよい。更に生成されるべきパケットがない場合には、工程７９５において、テストセッションを終了してもよい。更に生成されるべきパケットがある場合には、工程７１０から全工程を反復してもよい。説明の容易さのために、工程７１０、工程７１５および工程７２０の動作は、逐次的なものとして示すが、これらの動作は並行して実行されてもよい。工程７１０から工程７２０までの動作は、テストセッション中は、基本的に連続的に反復されてもよい。
【００７６】
工程７１５において、フロー制御パケットが受信されたと判定された場合には、工程７２５から工程７５０までの動作は、複数のフロー制御グループの各々について独立して並行して実行されてもよい。工程７２５において、特定のフロー制御グループに影響を及ぼす命令が受信フロー制御パケットに含まれるかどうかを判定してもよい。例えば、フロー制御パケットは、Ｎビットのマスクを含んでもよい。ここでＮは、フロー制御グループの個数であり、各フロー制御グループがパケットに影響されるか否かを示す。フロー制御パケットは、影響を受ける各フロー制御グループの送信を休止または再開すべきかどうかを示す、更なるデータを含んでもよい。フロー制御パケットは、休止されるべき各フロー制御グループの休止期間を示す情報を含んでもよい。
【００７７】
例えば、ＩＥＥＥ８０２．１（Ｑｂｂ）に従う優先フロー制御パケットは、８ビットのマスクを含む。ここで、ビット値が０であれば、パケットが、それぞれのフロー制御グループのステータスに影響を及ぼさない、ということを示す。ビット値が１であれば、パケットが、それぞれのフロー制御グループを休止するように指示している、ということを示す。優先フロー制御パケットもまた、休止されるべき各フロー制御グループの休止期間を含み、休止期間がゼロであれば、前回休止されたフロー制御グループが再開されるべきことを示す。
【００７８】
工程７２５において、特定のフロー制御グループを休止する命令、特定のフロー制御グループの送信を再開する命令、または特定のフロー制御グループへの影響がないこと（命令なし）が、受信されたフロー制御パケットに含まれるかどうかを判定してもよい。受信されたフロー制御パケットが、特定のフロー制御グループに影響を及ぼさない場合には、全工程７００は、工程７１０に戻る。
【００７９】
工程７２５において、特定のフロー制御グループを休止する命令が、受信されたフロー制御パケットに含まれる、と判定された場合には、工程７３０において、パケットジェネレータは、休止されたフロー制御グループに関連づけられるパケットの送信を保留してもよい。例えば、工程７３０において、フロー制御グループが休止されたことを示すフロー制御データが、出力マルチプレクサ（出力マルチプレクサ４６０等）に送信されてもよい。パケットがトラフィックジェネレータ内で破棄されず、かつパイプラインが再び満杯になることを待たずにパケット送信を再開してもよいように、工程７５０において、フロー制御データは、パイプラインの逆方向へと（パケット形成データのフローの逆方向へと）伝搬することにより、トラフィックジェネレータに、休止されたフロー制御グループについてのパケットの生成を規則的に停止させてもよい。
【００８０】
受信されたフロー制御パケットが、指定された時間間隔にわたってフロー制御グループを休止する命令を含む場合には、指定された時間間隔における残り時間を追跡するように、タイマを始動してもよい。工程７４５において、指定された時間間隔が経過したと判定された場合には、工程７４０において、パケットジェネレータは、休止されたフロー制御グループに関連づけられるパケットの送信を自動的に再開してもよい。例えば、工程７４０において、フロー制御グループが休止されないことを示すフロー制御データが、出力マルチプレクサに供給されてもよい。次に、工程７５０において、フロー制御データは、パイプラインの逆方向へと伝搬してもよい。
【００８１】
工程７２５において、受信されたフロー制御パケットがフロー制御グループを再開する命令を含む、と判定された場合には、工程７４０において、パケットジェネレータは、休止されたフロー制御グループに関連づけられるパケットの送信を再開してもよい。例えば、工程７４０において、フロー制御グループが休止されないことを示すフロー制御データが、出力マルチプレクサに供給されてもよい。次に、工程７５０において、フロー制御データは、パイプラインの逆方向へと伝搬してもよい。
【００８２】
図８は、トラフィックジェネレータ内の単一の特定のフロー制御グループのフロー制御のための、例示的工程８００のフローチャートを示すものである。全工程８００は、必ずしも任意の特定の点において開始または終了するものではないが、フロー制御グループのフロー制御が変化するたびに、循環的に反復してもよい。全工程８００は、トラフィックジェネレータ（トラフィックジェネレータ４００等）によって実行されてもよい。トラフィックジェネレータは、スケジューラ、チャネライズドスケジュール待ち行列、ＰＦＤディストリビュータ、パケットビルダ、チャネライズドパケットバッファ、および出力マルチプレクサを備える。全工程８００は、テストセッション中に複数のポート装置によって同時に並行して実行されてもよく、各ポート装置は、複数のフロー制御グループに対して全工程８００を同時に独立して実行してもよい、ということを理解すべきである。
【００８３】
説明の目的のために、全工程８００は、フロー制御グループが休止された場合に、工程８０５において開始するものと仮定する。例えば、トラフィックジェネレータによって受信されたフロー制御パケットに応答して、フロー制御グループが休止されてもよい。フロー制御グループが休止されたあと、工程８１０において、出力マルチプレクサは、休止されたフロー制御グループについて、チャネライズドパケットバッファの対応するチャネルからのパケットの読み込みを停止してもよく、工程８１５において、チャネルが満杯になる。
【００８４】
ＰＦＤディストリビュータが、工程８２０において、関連づけられるパケットバッファの容量が完全にコミットされている（すなわち別のパケットを保持するには使用可能容量が不十分である）と認識するまでは、ＰＦＤディストリビュータは、休止されたフロー制御グループのパケットについて、パケットビルダパケット形成データを送信し続けてもよい。パケットバッファが別のパケットを保持できないということを、ＰＦＤディストリビュータが一旦認識すると、ＰＦＤディストリビュータは、休止されたフロー制御グループに関連づけられるスケジュール待ち行列チャネルからの読み込みを停止してもよい。
【００８５】
ＰＦＤディストリビュータがスケジュール待ち行列チャネルからの読み込みを停止したあと、工程８２５において、スケジュール待ち行列チャネルは満杯になる。これに応答して、工程８３０において、スケジューラは、休止されたフロー制御グループのスケジューリングを停止してもよい。すなわち、スケジューラは、休止されたフロー制御グループ内のパケットについて、パケット定義データの出力を停止してもよい。
【００８６】
工程８５５において、前回休止されたフロー制御グループは、休止解除されてもよい。例えば、トラフィックジェネレータによって受信されたフロー制御パケットに応答して、フロー制御グループは、休止解除されてもよい。フロー制御グループが休止解除されたあと、工程８６０において、出力マルチプレクサは、休止されたフロー制御グループについて、チャネライズドパケットバッファの対応するチャネルからのパケットの読み込みを再開してもよく、工程８６５において、パケットバッファチャネルを満杯でなくさせる（すなわち、完全にコミットされた状態よりも使用可能になる）。
【００８７】
工程８７０において、ＰＦＤディストリビュータは、関連づけられるパケットバッファチャネルの容量がもはや完全にはコミットされた状態でないことを認識してもよい。例えば、ＰＦＤディストリビュータは、１つ以上のパケットがパケットバッファチャネルから読み込まれたことを示すフィードバックを、出力マルチプレクサから受信してもよい。ＰＦＤディストリビュータが、パケットバッファチャネルが別のパケットを保持できるということを一旦認識すると、ＰＦＤディストリビュータは、休止されたフロー制御グループに関連づけられるスケジュール待ち行列チャネルからの読み込みを再開してもよい。
【００８８】
ＰＦＤディストリビュータがスケジュール待ち行列チャネルからの読み込みを再開したあと、工程８７５において、スケジュール待ち行列チャネルは、満杯未満になる。これに応答して、工程８８０において、スケジューラは、休止されたフロー制御グループのスケジューリングを再開してもよい。すなわち、スケジューラは、休止されたフロー制御グループ内のパケットについて、パケット定義データの出力を再開してもよい。
【００８９】
破線によって示されるように、休止されたフロー制御グループは、工程８１０から工程８３０までのフローの任意の点において休止解除されてもよく、その場合には、工程８１０から工程８３０までの動作の一部は生じなくてもよい。同様に、鎖線によって示されるように、休止解除されたフロー制御グループは、工程８６０から工程８８０までのフローの任意の点において休止されてもよく、その場合には、工程８６０から工程８８０までの動作の一部は生じなくてもよい。
【００９０】
まとめ
本明細書の全体にわたって示される実施形態および例は、開示または請求される装置および処理手順を限定するものではなく、典型的な例として考慮されるべきである。本明細書において提示される例の多くは、方法作用またはシステム要素の特定の組み合わせを含むが、それらの作用および要素は、別の態様で組み合わされても同じ目的を達成しえる、ということを理解すべきである。フローチャートに関しては、より多くの工程またはより少ない工程を含んでもよく、示される工程は、本願明細書に記載される方法を達成するために組み合わせられてもよく、更に改良されてもよい。一実施形態のみに関連して説明される作用、構成要素および特徴は、他の実施形態における類似の役割から除外されることを意図しない。
【００９１】
本明細書において、「複数」は、２つ以上を意味する。本明細書において、項目の「セット」は、１つ以上のこのような項目を含んでもよい。明細書または請求項のいずれに記載される場合も、本明細書において用いられる「備える」、「含む」、「持つ」、「有する」、「含有する」、「伴う」等の用語は、制限されない、すなわち含むが限定されないものとして意図されることを理解すべきである。「〜からなる」および「基本的に〜からなる」という移行句は、請求項に関しては、それぞれ限定的移行句または半限定的移行句である。請求項において構成要素を修飾する「第１」、「第２」、「第３」等の序数詞の使用は、優先、順位、または他の請求項に対するある請求項の順番、または方法の作用が実行される時間的な順序を単独で意味するものではなく、ある名称を有する１つの請求項構成要素を、（序数詞なしの）同じ名称を有する別の構成要素から区別し、それらの請求項構成要素を区別するための、単なるラベルとして用いられるものである。本明細書において、「および／または」は、列挙される項目が選択肢であることを意味するが、それらの選択肢もまた、列挙される項目の任意の組合せを含む。
【技術分野】
【０００１】
本開示は、ネットワークまたはネットワーク装置をテストするためのトラフィックの生成に関する。
【背景技術】
【０００２】
多くの種類の通信ネットワークにおいて、送信されるべき各メッセージは、固定長または可変長の部分に分割される。各部分は、パケット、フレーム、セル、データグラム、データ単位、または情報の他の単位と呼ばれることもあるが、本明細書においては、それらの全てをパケットと呼ぶ。
【０００３】
各パケットは、パケットのペイロードと一般的に呼ばれる、オリジナルメッセージの部分を含む。パケットのペイロードは、データを含んでもよく、音声情報またはビデオ情報を含んでもよい。パケットのペイロードは、ネットワーク管理制御情報を含んでもよい。加えて、各パケットは、パケットヘッダと一般的に呼ばれる、識別および経路指定の情報を含む。パケットは、複数のスイッチまたはノードを介して、ネットワークにわたり個々に送信される。メッセージがターゲット装置またはエンドユーザに配信される前に、パケットヘッダに含まれる情報を用いて、パケットは、最終送信先においてメッセージへと再構築される。受信側において、再構築されたメッセージは、ユーザの装置と互換性のあるフォーマットでエンドユーザに渡される。
【０００４】
メッセージをパケットとして送信する通信ネットワークは、パケット交換網と呼ばれる。パケット交換網は、ハブまたはノードにおいて交差する送信経路のメッシュを一般的に含む。少なくとも一部のノードは、ノードに到着するパケットを受信して、かつ適切な発信経路に沿ってパケットを再送信する、交換装置またはルータを含んでもよい。パケット交換網は、業界基準プロトコルの階層構造によって制御される。その構造のレイヤ１、２および３は、それぞれ、物理的レイヤ、データリンクレイヤ、およびネットワークレイヤである。
【０００５】
レイヤ１プロトコルは、ネットワークのノード間の物理的な（電気的、光学的、またはワイヤレスの）インタフェースを定義する。レイヤ１プロトコルは、イーサネット（登録商標）のさまざまな物理的構成、同期光通信ネットワーク（ＳＯＮＥＴ）等の光通信接続のプロトコル、およびＷｉＦｉ等のさまざまなワイヤレスプロトコルを含む。
【０００６】
レイヤ２プロトコルは、ネットワークのノード間でデータが論理的に転送される方法を制御する。レイヤ２プロトコルは、イーサネット（登録商標）、非同期転送モード（ＡＴＭ）、フレームリレー、およびポイントツーポイントプロトコル（ＰＰＰ）を含む。
【０００７】
レイヤ３プロトコルは、ネットワークの複数ノードを接続する経路に沿って、パケットが送信元から送信先へとルーティングされる方法を制御する。主要なレイヤ３プロトコルは、周知のインターネットプロトコルのバージョン４（ＩＰｖ４）およびバージョン６（ＩＰｖ６）である。パケット交換網は、イーサネット（登録商標）、ＡＴＭ、ＦＲおよび／またはＰＰＰレイヤ２といったプロトコルの組み合わせを用いて、ＩＰパケットをルーティングする必要がありえる。ネットワークのノードの少なくとも一部は、各パケット内に含まれるネットワークレイヤヘッダから宛先アドレスを抽出するルータを含んでもよい。ルータは、次に、宛先アドレスを用いて、パケットが再送信されるべきルートまたは経路を判定する。典型的なパケットは、複数のルータを通過してもよい。各ルータは、宛先アドレスを抽出し、かつパケットが再送信されるべきルートまたは経路を判定する、という動作を反復する。
【０００８】
パケット交換通信ネットワークに含まれるパケット交換網または装置をテストするために、多数のパケットを含むテストトラフィックを、生成し、１つ以上のポートからネットワークに送信し、異なるポートにおいて受信してもよい。テストトラフィックの各パケットは、特定の送信先ポートで受信されるように意図されたユニキャストパケットであってもよく、または２つ以上の送信先ポートで受信されるように意図されたマルチキャストパケットであってもよい。この文脈において、「ポート」という用語は、ネットワークとそのネットワークをテストするために用いられる装置との間の、通信接続を指す。「ポート装置」という用語は、ポートにおいてネットワークに接続するネットワークテスト装置内のモジュールを意味する。受信されたテストトラフィックを分析することにより、ネットワークの性能を測定してもよい。ネットワークに接続された各ポート装置は、テストトラフィックの送信元およびテストトラフィックの送信先の両方であってもよい。各ポート装置は、複数の論理的な送信元または送信先のアドレスをエミュレートしてもよい。ポート装置をネットワークに接続するポート装置の個数および通信経路は、一般的に、テストセッション中は固定される。例えば、通信経路またはハードウェア装置の障害により、テストセッション中にネットワークの内部構造が変化することがある。
【０００９】
本明細書において、単一のポート装置から発信され、かつ特定の種類のパケットおよび特定の速度を有する一連のパケットを、「ストリーム」と呼ぶ。送信元ポート装置は、例えば、複数のパケット形式、速度、または送信先に適合するように、複数の発信ストリームを同時にかつ並行してサポートしてもよい。「同時に」は、「正確に同じ時間において」を意味する。「並行して」は、「同じ時間の範囲内で」を意味する。
【００１０】
本明細書において、「エンジン」という用語は、記述された機能を実行するファームウェアおよび／またはソフトウェアによって増補されえるハードウェアの集合を意味する。エンジンは、一般的に、主に機能言語によってエンジンを定義するハードウェア記述言語（ＨＤＬ）を用いて設計されてもよい。ＨＤＬの設計は、ＨＤＬシミュレーションツールを用いて検証されてもよい。検証されたＨＤＬの設計は、次に、一般的に「合成」と呼ばれる工程において、エンジンのゲートネットリストまたは他の物理的記述へと変換されてもよい。合成は、合成ツールを用いて自動的に実行されてもよい。ゲートネットリストまたは他の物理的記述は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路（ＰＬＤ）、プログラム可能論理アレイ（ＰＬＡ）、または他のプログラム可能回路等の、プログラム可能半導体デバイスにおけるエンジンを実現するためのプログラミングコードへと更に変換されてもよい。ゲートネットリストまたは他の物理的記述は、特定用途向けＩＣ（ＡＳＩＣ）内部のエンジンを作るための工程の指示およびマスクへと変換されてもよい。
【００１１】
「エンジン」は、必要に応じ、より多くの記述名を与えられてもよい。本明細書において、さまざまなエンジンに、「スケジューラ」、「ディストリビュータ」、「ビルダ」、「マルチプレクサ」、「ジェネレータ」および「受信器」という名詞の１つを含む名前が与えられている。
【００１２】
本明細書において、「論理」という用語もまた、記述される機能を実行するハードウェアの集合を意味し、「エンジン」よりも規模が小さいことがある。「論理」は、組み合わせ論理回路と、フリップフロップ、レジスタ、および他のデータ伝搬要素を含む逐次的論理回路と、有限状態機械等の複雑な逐次的論理回路とを含む。
【００１３】
本明細書において、「装置」は、「エンジン」よりも規模が大きくありえるファームウェアおよび／またはソフトウェアによって増補されえる、ハードウェアの集合を意味する。例えば、装置は、複数のエンジンを含んでもよく、その一部は、類似の機能を並行して実行してもよい。「論理」、「エンジン」および「装置」という用語は、いかなる物理的な分離または境界をも意味しない。１つ以上の装置および／またはエンジンの全てまたは一部は、ネットワークカード等の共通カード上に配置されてもよく、またはＦＰＧＡ、ＡＳＩＣまたは他の回路装置の内部に配置されてもよい。
【００１４】
１つ以上のエンジン、論理回路および／または装置が、１つ以上のプログラム可能な半導体デバイスによって実現される場合には、プログラミングコードは、コンピュータ可読媒体に格納されてもよい。プログラミングコードは、次に、プログラム可能回路または装置を構成するために用いられてもよい。記憶媒体は、例えば、磁気媒体（ハードディスク、フロッピー（登録商標）ディスクおよび磁気テープ等）、光媒体（コンパクトディスク（ＣＤ―ＲＯＭおよびＣＤ―ＲＷ）およびデジタル多用途ディスク（ＤＶＤおよびＤＶＤ±ＲＷ）等）、フラッシュメモリカード、またはデータを格納するための別の物理的オブジェクトであってもよい。「記憶媒体」という用語は、波形および信号の伝搬等を行う一過性の媒体を含まない。
【図面の簡単な説明】
【００１５】
【図１】ネットワーク環境を示すブロック図である。
【図２】ポート装置を示すブロック図である。
【図３】トラフィックジェネレータを示すブロック図である。
【図４】優先フロー制御を有するマルチレーントラフィックジェネレータを示すブロック図である。
【図５】チャネライズドパケットバッファを示すブロック図である。
【図６】パケット形成データ（ＰＦＤ）ディストリビュータを示すブロック図である。
【図７】トラフィックジェネレータのフロー制御論理を示すフローチャートである。
【図８】トラフィックジェネレータ内のフロー制御を示すグラフ図である。
【発明を実施するための形態】
【００１６】
本明細書の全体にわたり、ブロック図に示される構成要素には、３桁の参照符号が割り当てられ、参照符号の最上位桁は構成要素が示される図面番号を示し、最下位２桁は構成要素を特定するものである。ブロック図に記載されない構成要素は、同じ参照符号を有する既述の構成要素と同じ特性および機能を有するものとみなされてよい。
【００１７】
ブロック図において、矢印線は、信号よりもむしろデータ経路を示しえる。各データ経路の幅は、複数ビットであってもよい。例えば、各データ経路は、４個、８個、１６個、６４個、２５６個、またはそれ以上の個数の並列接続から成ってもよい。
【００１８】
装置の説明
図１は、ネットワーク環境のブロック図である。この環境は、ネットワークテスト装置１００と、ネットワーク１９０と、複数のネットワーク装置１９２とを含んでもよい。
【００１９】
ネットワークテスト装置１００は、ネットワークテスト装置、性能分析装置、適合性検証システム、ネットワーク分析装置、またはネットワーク管理システムであってもよい。ネットワークテスト装置１００は、シャーシ１０２内に収容または封入される、１つ以上のネットワークカード１０６と、バックプレーン１０４とを備えてもよい。シャーシ１０２は、ネットワークテスト装置を収容するのに適切な固定型または携帯型のシャーシ、キャビネットまたは筐体であってもよい。図１に示すように、ネットワークテスト装置１００は、統合された装置であってもよい。この代わりに、ネットワークテスト装置１００は、トラフィックの生成および／または分析を提供するように協同する多くの別々の装置から成ってもよい。ネットワークテスト装置１００およびネットワークカード１０６は、さまざまなイーサネット（登録商標）規格およびファイバチャネル規格等の、１つ以上の周知の規格またはプロトコルをサポートしてもよく、特許権で保護されたプロトコルをサポートしてもよい。
【００２０】
ネットワークカード１０６は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、プログラム可能論理アレイ（ＰＬＡ）、プロセッサ、および他の種類の装置を、１つ以上備えてもよい。加えて、ネットワークカード１０６は、ソフトウェアおよび／またはファームウェアを備えてもよい。ネットワークカードという用語は、ラインカード、テストカード、分析カード、ネットワークラインカード、ロードモジュール、インタフェースカード、ネットワークインタフェースカード、データインタフェースカード、パケットエンジンカード、サービスカード、スマートカード、スイッチカード、リレーアクセスカード、等を含む。ネットワークカードという用語は、モジュール、装置、およびアセンブリをも含み、それらは複数のプリント回路基板を備えてもよい。各ネットワークカード１０６は、１つ以上のポート装置１１０を備えてもよい。各ポート装置１１０は、１つ以上のポートを介して、ネットワーク１９０に接続してもよい。各ポート装置１１０は、通信媒体１９５を介して、ネットワーク１９０に接続されてもよい。通信媒体１９５は、ワイヤ、光ファイバ、ワイヤレスリンク、または他の通信媒体であってもよい。各ネットワークカード１０６は、単一の通信プロトコルをサポートしてもよく、多くの関連プロトコルをサポートしてもよく、または多くの非関連プロトコルをサポートしてもよい。ネットワークカード１０６は、ネットワークテスト装置１００内に常設的に設置されてもよく、または着脱可能であってもよい。
【００２１】
バックプレーン１０４は、ネットワークカード１０６のバスまたは通信媒体の役割を果たしてもよい。バックプレーン１０４はまた、ネットワークカード１０６に電力を提供してもよい。
【００２２】
ネットワーク装置１９２は、ネットワーク１９０を通じて通信可能ないかなる装置でもあってもよい。ネットワーク装置１９２は、コンピューティング装置（ワークステーション、パーソナルコンピュータ、サーバ、ポータブルコンピュータ、パーソナル携帯情報機器（ＰＤＡ）、コンピューティングタブレット、携帯電話／モバイル電話、電子メール機器等）、周辺機器（プリンタ、スキャナ、ファクシミリ装置等）、ディスクドライブを備えネットワーク機能を有する記憶装置（ネットワーク接続ストレージ（ＮＡＳ）、ストレージエリアネットワーク（ＳＡＮ）装置等）、ネットワーク化装置（ルータ、リレー、ハブ、スイッチ、ブリッジ、マルチプレクサ等）であってもよい。加えて、ネットワーク装置１９２は、ネットワークを通じて通信可能な、設備、アラームシステム、および他の任意の装置またはシステムを備えてもよい。
【００２３】
ネットワーク１９０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ストレージエリアネットワーク（ＳＡＮ）、これらのワイヤード版、ワイヤレス版、またはこれらの組合せであってもよく、さらにはインターネットを含んでもよく、またはインターネットであってもよい。ネットワーク１９０上の通信は、フレーム、セル、データグラム、パケットまたは他の情報単位を含むさまざまな形態をとりえるが、本明細書においては、それらの全てをパケットと呼ぶ。ネットワークテスト装置１００およびネットワーク装置１９２は、互いに同時に通信してもよい。ネットワークテスト装置１００と所与のネットワーク装置１９５との間に、複数の論理的通信経路があってもよい。ネットワークそのものは、非常に多くのノードから成ってもよく、それらのノードは、データが伝送される非常に多くの物理経路および論理経路を提供する。
【００２４】
各ポート装置１１０は、特定の通信リンク１９５を介して、ネットワーク装置１９２上の対応するポートに接続していてもよい。状況によっては、ポート装置１１０は、ネットワーク装置１９２が適切に受信できるよりも多くのトラフィックを、ネットワーク装置１９２上の対応するポートに送信してもよい。例えば、ネットワーク装置１９２は、ネットワーク装置１９２がパケットを処理および転送できる速度よりも速い全体的速度において、複数の送信元から着信パケットを受信してもよい。この場合、ネットワーク装置１９２内のバッファメモリは、受信された未処理のパケットによって満杯にされてもよい。バッファメモリのオーバフローによるパケット損失を回避するために、ネットワーク装置１９２は、フロー制御のメッセージまたはパケットをポート装置１１０に送信してもよい。
【００２５】
例えば、ポート装置１１０およびネットワーク装置１９２が全二重イーサネット（登録商標）接続を用いて通信を行う場合、ＩＥＥＥ規格８０２．３ｘの規定により、ネットワーク装置１９２は、休止フレームまたは休止パケットをポート装置１１０に送信してもよい。休止フレームは、休止パケット内のデータによって定義される時間間隔にわたって、特定の制御パケットを除くパケットの送信を停止するように、ポート装置１１０に命令してもよい。ネットワーク装置１９２は、ゼロ（０）という時間間隔を定義する休止パケットを送信することにより、前回休止されたポート装置にパケットの送信を再開させてもよい。
【００２６】
しかしながら、サービス品質（ＱｏＳ）レベル、トラフィッククラス、またはなんらかの他の優先順位方式に従ってトラフィックに優先順位をつけるネットワークのフロー制御において、単にポート装置からの出力を休止することは、許容しえない方法でありえる。例えば、ＩＥＥＥ規格８０２．１Ｑｂｂは、受信器が８個のトラフィッククラスのフローを制御してもよいと規定している。フロー制御に影響を及ぼすために、受信器は、８個のトラフィッククラスの一部または全部を休止させるように命令する優先フロー制御（ＰＦＣ）パケットを、送信器に送信してもよい。ＰＦＣパケットは、各トラフィッククラスを休止すべき時間間隔を、独立して定義してもよい。
【００２７】
ここで図２を参照すると、例示的なポート装置２１０は、ポート中央処理装置２１２（ＣＰＵ）と、トラフィックジェネレータ装置２２０と、トラフィック受信装置２８０と、ポート装置２１０をテスト対象ネットワーク２９０に連結するネットワークインタフェース装置２７０とを備えてもよい。ポート装置２１０は、ネットワークカード１０６等のネットワークカードの全部または一部であってもよい。
【００２８】
ポートＣＰＵ２１２は、プロセッサ、該プロセッサに連結されたメモリ、および本明細書に記載される機能および特徴を提供するためのさまざまな特殊な装置、回路、ソフトウェア、およびインタフェースを備えてもよい。工程、機能、および特徴は、プロセッサ上で動作するソフトウェアによって、全体的または部分的に実現されてもよく、ファームウェア、アプリケーションプログラム、アプレット（例えばＪａｖａ（登録商標）アプレット）、ブラウザのプラグイン、ＣＯＭオブジェクト、動的リンクライブラリ（ＤＬＬ）、スクリプト、１つ以上のサブルーチン、またはオペレーティングシステムのコンポーネントまたはサービス、といった形態であってもよい。プロセッサおよび他の装置の他の部分によってなんらかの機能が実行されるように、ハードウェア、ソフトウェア、およびそれらの機能は、分散型であってもよい。
【００２９】
ポートＣＰＵ２１２は、テストアドミニストレータ２０５と通信してもよい。テストアドミニストレータ２０５は、オペレータインタフェース２０７と通信してもよく、またはオペレータインタフェース２０７を備えてもよい。テストアドミニストレータ２０５は、ネットワークテスト装置１００の内部に含まれるかまたは外部にあるコンピューティング装置であってもよい。テストアドミニストレータ２０５は、ネットワーク２９０のテストに関与する際に、ポート装置が必要とする命令およびデータを、ポートＣＰＵ２１２に提供してもよい。テストアドミニストレータ２０５から受信される命令およびデータは、例えば、ポート装置２１０によって生成されるべきパケットストリームの定義と、ポート装置２１０によって蓄積および報告されえる性能統計の定義とを含んでもよい。
【００３０】
ポートＣＰＵ２１２は、複数のストリームを形成するストリーム形成データ２１４を、トラフィックジェネレータ装置２２０に提供してもよい。ストリーム形成データ２１４は、例えば、パケットのタイプ、送信の頻度、パケット内の固定コンテンツフィールドおよび可変コンテンツフィールドの定義、および各パケットストリームのための他の情報を含んでもよい。トラフィックジェネレータ装置２２０は、次に、ストリーム形成データ２１４に従って、複数のストリームを生成してもよい。複数のストリームは、インタリーブされることにより発信トラフィック２６５を形成してもよい。ストリームの各々は、一連のパケットを含んでもよい。各ストリーム内のパケットは、同じ一般的なタイプであってもよいが、長さおよびコンテンツは異なっていてもよい。
【００３１】
ネットワークインタフェース装置２７０は、トラフィックジェネレータ装置２２０からの発信トラフィック２６５を、電気信号、光学信号または無線信号のフォーマットに変換してもよい。そのフォーマットは、リンク２９５を介してテストトラフィックをテスト対象ネットワーク２９０に送信するために必要なものである。リンク２９５は、ワイヤリンク、光ファイバリンク、ワイヤレスリンク、または他の通信リンクであってもよい。同様に、ネットワークインタフェース装置２７０は、ネットワークからリンク２９５を介して電気信号、光学信号または無線信号を受信してもよく、受信した信号を、トラフィック受信装置２８０が使用できるフォーマットの着信トラフィック２７５へと変換してもよい。
【００３２】
トラフィック受信装置２８０は、ネットワークインタフェース装置２７０から、着信トラフィック２７５を受信してもよい。トラフィック受信装置２８０は、各受信パケットが特定のフローの部分であるかどうかを判定してもよく、ポートＣＰＵ２１２によって提供されるテスト命令２１８に従って、各フローのテスト統計を蓄積してもよい。蓄積されるテスト統計は、例えば、受信されたパケットの合計数、順番誤りで受信されたパケットの数、エラーとともに受信されたパケットの数、伝搬遅延の最大値、平均値および最小値、および各フローの他の統計を含んでもよい。トラフィック受信装置２８０は、テスト命令２１８に含まれる獲得基準に従って、特定のパケットを獲得および格納してもよい。トラフィック受信装置２８０は、テストセッション中またはテストセッション後のさらなる分析のために、テスト命令２１８に従って、テスト統計および／または獲得したパケット２８４を、ポートＣＰＵ２１２に提供してもよい。
【００３３】
テストセッション中に、ポート装置２１０とネットワーク２９０との間で、若干の双方向通信が必要とされるかまたは所望されることもある。例えば、トラフィック受信装置２８０は、制御パケットを受信してもよい。制御パケットは、テストセッションを制御するために必要なデータを含むパケットであり、ポート装置２１０は、それに対して受信通知または応答を送信する必要がある。トラフィック受信装置２８０は、着信制御パケットを、着信トラフィックから分離してもよく、着信制御パケット２８２を、ポートＣＰＵ２１２へとルーティングしてもよい。ポートＣＰＵ２１２は、各制御パケットのコンテンツを抽出してもよく、発信ＣＰＵトラフィック２１６という形にて、適切な応答を生成してもよい。発信ＣＰＵトラフィック２１６は、トラフィックジェネレータ装置２２０に提供されてもよい。トラフィックジェネレータ装置２２０は、発信ＣＰＵトラフィック２１６を、発信トラフィック２６５の中に挿入してもよい。
【００３４】
トラフィックジェネレータ装置２２０からの発信トラフィック２６５は、独立して休止されえる「フロー制御グループ」へと分割されてもよい。例えば、発信トラフィック２６５は、ＩＥＥＥ８０２．１Ｑｂｂに従って、８個のトラフィッククラスに対応する８個のフロー制御グループへと分割されてもよい。発信トラフィック２６５は、ＩＥＥＥ８０２．１Ｑｂｂに従って８個のトラフィッククラスに対応する８個のフロー制御グループと、休止されなくてもよい制御トラフィックおよび他のトラフィックのための第９のフロー制御グループへと、分割されてもよい。トラフィックジェネレータ装置２２０によって生成される各ストリームは、フロー制御グループに割り当てられてもよい。各フロー制御グループは、０個、１個、または複数のストリームを含んでもよい。ポート装置２２０によって受信されえる制御パケットの１つの形式は、フロー制御パケットであってもよく、例えば、ＩＥＥＥ８０２．３ｘまたはＩＥＥＥ８０２．１Ｑｂｂに従うものであってもよい。フロー制御パケットは、トラフィック受信装置２８０内で認識されてもよい。フロー制御パケット２８６に由来する、フロー制御パケットおよび／またはフロー制御データは、トラフィック受信装置２８０からトラフィックジェネレータ装置２２０へと直接的に提供されてもよい。
【００３５】
以下の説明に含まれる例において、ネットワークテスト装置のポート装置とネットワーク装置との間のフロー制御は、ＩＥＥＥ８０２．１Ｑｂｂに従うフロー制御パケットを用いて管理される、と仮定することがある。しかしながら、説明される装置および方法は、現在または将来の他の優先フロー制御方式との互換性を有し、８個より多いかまたは少ないトラフィッククラスをも含む。
【００３６】
ここで図３を参照すると、例示的なトラフィックジェネレータ３２０は、複数のパケットのストリームから成る発信トラフィック３６５を生成してもよい。トラフィックジェネレータは、例えば、１６のストリーム、６４個のストリーム、２５６個のストリーム、５１２個のストリーム、または他の個数のストリームを生成することが可能であり、ストリームを任意の組合せでインタリーブすることにより、テストトラフィックを提供してもよい。例示的なトラフィックジェネレータ３２０は、図２のトラフィックジェネレータ装置２２０であってもよく、図１に示すネットワークカード１０６の全体または一部であってもよい。
【００３７】
トラフィックジェネレータ３２０は、スケジューラ３３０を備えてもよい。所望の通信速度は、トラフィックジェネレータ３２０によって生成されるべき複数のストリームの各々に関連づけられてもよい。スケジューラ３３０は、各ストリームが発信トラフィック３６５にパケットを与えるべき時間を示す、カウンタまたは仮想カウンタ等の調時機構を、ストリームごとに備えてもよい。２つ以上のストリームが同時にパケットを与えようとする際に、その状況におけるパケットシーケンスを判定するために、スケジューラ３３０は、アービトレーション論理を備えてもよい。スケジューラ３３０は、ハードウェア、またはハードウェアとソフトウェアとの組合せによって実現されてもよい。例えば、米国特許第７，６１６，５６８Ｂ２号明細書は、リンクされたデータ構造と、単一のハードウェアタイマとを用いる、スケジューラを開示している。米国特許出願公報第２０１１／０００２２２８Ａ１号明細書は、複数のハードウェアタイマを用いるスケジューラを開示している。
【００３８】
スケジューラ３３０は、生成されるパケットごとに、パケット定義データ３３２を出力してもよい。パケット定義データ３３２は、生成されるパケットを定義するために必要なデータを含んでもよいが、パケットを生成するために必要なすべてのデータを必ずしも含まなくともよい。生成される各パケットは、複数のストリームの１つに属するものであり、パケット定義データ３３２は、例えば、対応するストリームを識別するストリーム識別子を含んでもよい。パケット定義データ３３２は、形成されるべきパケットのタイプ、長さ、または他の特性を識別するデータを含んでもよい。
【００３９】
トラフィックジェネレータ３２０によって生成される各パケットは、ステートフルコンテンツおよびステートレスコンテンツを含んでもよい。「ステートフルコンテンツ」とは、同一ストリーム内の前のパケットのコンテンツに依存するコンテンツである。ステートフルコンテンツの例としては、ストリーム内のパケットに割り当てられる逐次的なシーケンス番号、および前のパケット内の同一フィールドのコンテンツにオフセットを追加することに由来するパケット内のアドレスまたは他のフィールドが挙げられる。トラフィックジェネレータは、ステートフルな各コンテンツアイテムについての履歴または「状態」を維持しなければならないので、このようなコンテンツは「ステートフル」とみなされる。対照的に、「ステートレスコンテンツ」とは、前のパケットのコンテンツに依存しないコンテンツである。ステートレスコンテンツの例としては、ランダムに生成されるペイロードコンテンツ、ストリーム内のパケット間で異ならない固定コンテンツ、およびパケットの現在のコンテンツに基づいて生成されるチェックサムが挙げられる。「ステートフルコンテンツ」および「ステートレスコンテンツ」は、ネットワークを介するステートフル接続およびステートレス接続と混同されるべきではない。
【００４０】
トラフィックジェネレータ３２０は、ステートフルコンテンツジェネレータ３４５を備えてもよい。ステートフルコンテンツジェネレータ３４５は、スケジューラ３３０から出力されるパケット定義データ３３２に関連づけられるステートフルコンテンツ３４７を生成してもよい。パケット定義データ３３２とそれに関連づけられるステートフルコンテンツとの組合せを、本明細書においては「パケット形成データ」３４７と呼ぶ。
【００４１】
パケット形成データ３４７は、ステートレスパケットビルダ３５０に提供されてもよい。ステートレスパケットビルダ３５０は、対応するパケット形成データ３４７に基づいて、各パケットの生成を終了してもよい。パケット形成データに含まれるストリーム識別子に従って、ステートレスパケットビルダ３５０は、パケットごとにパケットテンプレートを読み出してもよい。パケットテンプレートは、ストリーム内のパケット間で異ならない固定データを含んでもよい。ステートレスパケットビルダは、次に、パケット形成データからステートフルコンテンツをテンプレート内の適切なフィールドの中に挿入し、ペイロードコンテンツおよび他のステートレスコンテンツを生成し、パケット内のチェックサムを生成および配置し、各パケットを完成するために必要な他のタスクを実行してもよい。
【００４２】
単一のステートレスパケットビルダは、回線速度において最新の高速ネットワークをテストするために充分なパケットを構築するには、非実用的でありえる。したがって、ステートレスパケットビルダは、複数の平行レーンを含んでもよい。各レーンは、独立してパケットを構築する能力を有してもよい。複数のレーンが存在することにより、レーンの個数にほぼ比例して、パケットを生成可能な速度も上昇することがある。図３は、４個のレーンを有するステートレスパケットビルダ３５０を示す。しかしながら、ステートレスパケットビルダは、４個よりも多いレーンまたは少ないレーンを有してもよい。
【００４３】
ステートレスパケットビルダ３５０によって構築されるパケットは、出力マルチプレクサ３６０に配信されてもよい。出力マルチプレクサ３６０は、ステートレスパケットビルダ３５０およびＣＰＵトラフィック３１６のチャネルからのパケットをインタリーブすることにより、発信トラフィック３６５を形成してもよい。出力マルチプレクサは、各パケットの伝送時間を示すタイムスタンプを追加したり、巡回冗長検査値を追加または調整したりする等の、パケットの仕上げ作業を、送信前に実行してもよい。
【００４４】
ステートレスパケットビルダ３５０のレーンからのパケットが確実に所望の順序でインタリーブされるようにするために、出力マルチプレクサ３６０は、スケジューラ３３０からパケットシーケンスデータ３３４を受信してもよい。パケットシーケンスデータ３３４は、発信トラフィックについての必要な送信順序を示してもよい。「パラレルコヒーレント送信エンジンを用いるトラフィックジェネレータ」という名称の米国特許第７，７６９，０４９Ｂ２号明細書は、スケジューラによって提供されるパケットシーケンスデータに従って、複数の送信エンジン（ステートレスパケットビルダ）からのパケットをインタリーブする、マルチレーントラフィックジェネレータを開示している。
【００４５】
いかなる時点においても、１つ以上のパケットがステートレスパケットビルダ内で処理中でありえるように、ステートレスパケットビルダ３５０の各レーンは、複数の逐次的ステージを含むパイプラインとして構成されてもよい。ステートレスパケットビルダは、処理ステージ間または処理ステージ中にパケットを保持するように、内部ＦＩＦＯ（先入先出）待ち行列を含んでもよい。特定のパケットのためのパケット形成データがステートレスパケットビルダに入力されてから、完成パケットがステートレスパケットビルダから出力されるまでの遅延は、特定のパケットの長さおよび／またはコンテンツ、およびパイプライン内の特定のパケットに先行するパケットの長さおよび／またはコンテンツに依存することがある。
【００４６】
ＩＥＥＥ８０２．１Ｑｂｂに従う優先フロー制御を実現するためには、他のフロー制御グループのパケットの送信が絶え間なく続いている間に、１つ以上の指定されたフロー制御グループ内でパケットの送信を休止する能力が必要とされる。休止されたフロー制御グループ内のパケットのスケジューリングを単に禁止するだけでは不十分なことがある。なぜなら、ステートレスパケットビルダのパイプラインのパケットが完成して送信される際に、休止されたフロー制御グループ内のパケットの送信が、かなりの時間間隔にわたって続くことがあるからである。休止されたフロー制御グループの処理中パケットが、ステートレスパケットビルダ内で停止できる場合には、フロー制御コマンドに対して、より即座に応答しえる。しかしながら、この場合には、休止されていないフロー制御グループのパケットは、ステートレスパケットビルダのパイプラインに沿って、停止されたパケットを渡すことができなければならない。
【００４７】
「優先フロー制御を有するトラフィックジェネレータ」という名称の同時係属米国特許出願第１２／７６６，７０４号明細書は、トラフィックジェネレータにおいて、パケットジェネレータ（ステートレスパケットビルダ）の内部ＦＩＦＯ待ち行列がチャネライズされることを開示している。本明細書において、「チャネライズド」という用語は、「複数のパラレルチャネルを有し、各チャネルが、複数のフロー制御グループの対応する１つに一意に関連づけられる」ということを意味する。「一意に関連づけられる」という用語は、一対一対応を意味する。チャネライズドＦＩＦＯ待ち行列の各チャネルは、対応するフロー制御グループについて、処理中データおよび処理中パケットの格納に専用されてもよい。チャネライズド各ＦＩＦＯ待ち行列は、休止されていないトラフィッククラスのパケットがトラフィックジェネレータ内で停止されたパケットを渡す機会を提供する。
【００４８】
マルチレーンステートレスパケットビルダを用いて高速度トラフィックジェネレータの優先フロー制御を実現する際に必要とされる、チャネライズド待ち行列専用のメモリ容量は、非実用的でありえる。例えば、米国特許出願第１２／７６６，７０４号明細書に開示された方法によると、４個のステートレスパケットビルダのレーンと９個のフロー制御グループとを有するトラフィックジェネレータは、３６個のチャネル（４個の各レーン内に９個のチャネル）を有するＦＩＦＯ待ち行列を必要としえる。特に、フィールドプログラマブルゲートアレイまたは他のプログラム可能な回路装置を用いてトラフィックジェネレータを実現する際には、このように多数のパラレルＦＩＦＯ待ち行列は、非実用的でありえる。
【００４９】
ここで図４を参照すると、例示的なトラフィックジェネレータ４２０は、非常に高い回線速度において発信トラフィックを生成し、マルチレベルの優先フロー制御を提供しえる。トラフィックジェネレータ４２０は、スケジューラ４３０と、ステートフルコンテンツジェネレータ４４０と、マルチレーンステートレスパケットビルダ４５０と、出力マルチプレクサ４６０とを含んでもよい。これらは一般に、図３のトラフィックジェネレータ３２０の対応構成要素について記載されているように機能するものである。トラフィックジェネレータ４２０は更に、スケジューラ４３０によって提供されるパケット定義データを格納する、チャネライズドスケジュールＦＩＦＯ４３５と、ステートレスパケットビルダ４５０によって提供される完成パケットを格納する、チャネライズドパケットバッファ４５５とを備えてもよい。
【００５０】
スケジューラ４３０は、例えば１６個のストリーム、６４個のストリーム、２５６個のストリーム、５１２個のストリーム、または他のなんらかの個数のストリームといった、複数のストリームをスケジューリングしてもよい。スケジューラ４３０は、各ストリームが発信トラフィック４６５にパケットを与えるべき時間を示す、カウンタまたは仮想カウンタ等の調時機構を、ストリームごとに備えていてもよい。２つ以上のストリームが同時にパケットを与えようとする際に、その状況におけるパケットシーケンスを判定するために、スケジューラ４３０は、アービトレーション論理を備えていてもよい。
【００５１】
スケジューラ４３０は、生成されるパケットごとに、パケット定義データ４３２を出力してもよい。パケット定義データ４３２は、生成されるパケットを定義するために必要なデータを含んでもよいが、パケットを生成するために必要なすべてのデータを必ずしも含まなくともよい。生成される各パケットは、複数のストリームの１つに属するものであり、パケット定義データ４３２は、例えば、対応するストリームを識別するストリーム識別子を含んでもよい。各ストリーム、およびパケット定義データの各パケットおよび各項目は、複数のフロー制御グループの１つに関連づけられていてもよい。例えば、各ストリームは、ＩＥＥＥ８０２．１Ｑｂｂに従って８個のトラフィッククラスに対応する８個のフロー制御グループを含む９個のフロー制御グループと、休止されなくてもよい制御トラフィックおよび他のトラフィックのための第９のフロー制御グループとに、関連づけられてもよい。パケット定義データ４３２は、各パケットに関連づけられるフロー制御グループを識別するフロー制御グループ識別子を含んでもよい。
【００５２】
ストリームとフロー制御グループとの間の関連づけは、固定されていてもよく、またはプログラム可能であってもよい。例えば、スケジューラ４３０は、各ストリーム識別子を関連づけられるフロー制御グループへとマッピングするデータを格納する、マップメモリ（図示せず）を備えてもよい。関連づけられるフロー制御グループへと各ストリーム識別子をマッピングするデータは、テストセッション前にマップメモリにロードされてもよく、テストセッション中に修正可能であってもよい。
【００５３】
チャネライズドスケジュール待ち行列４３５は、スケジューラ４３０から出力されるパケット定義データ４３２を格納してもよい。チャネライズドスケジュール待ち行列４３５の各チャネルは、先入れ先出しの態様で機能してもよい。チャネライズドスケジュール待ち行列４３５の各チャネルは、関連づけられるフロー制御グループについて、パケット定義データの格納に専用されてもよい。チャネライズドスケジュール待ち行列４３５は、チャネライズドスケジュール待ち行列の１つ以上のチャネルが満杯であるかどうかを示すフィードバック４３７を、スケジューラ４３０に提供してもよい。スケジューラ４３０は、チャネライズドスケジュール待ち行列４３５の１つ以上の満杯のチャネルに関連づけられるスケジューリングパケットストリームを保留してもよい。
【００５４】
ＰＦＤ（パケット形成データ）ディストリビュータ４４５は、チャネライズドスケジュール待ち行列４３５から読み込まれるパケット定義データ４３２を、ステートフルコンテンツジェネレータ４４０からのステートフルコンテンツ４４２と組み合わせることにより、パケット形成データ４４７を生成してもよい。ＰＦＤディストリビュータ４４５は、パケットごとのパケット形成データを、ステートレスパケットビルダ４５０のレーンの１つに転送してもよい。ＰＦＤディストリビュータ４４５の操作については、さらに詳細に後述する。
【００５５】
前述したように、ステートレスパケットビルダ４５０は、対応するパケット形成データに基づいて、各パケットの生成を終了してもよい。ステートレスパケットビルダ４５０は、複数の非チャネライズドパラレルレーンを含んでもよい。本特許においては、「非チャネライズド」は、チャネルがないことを意味する。具体的には、非チャネライズドパケットビルダ内の内部待ち行列は、１つのパケットがパイプライン内の他を通過できるようにするパラレル経路を有さない。したがって、一旦開始されると、各パケットは、レーン内の次のパケットが完成されえる前に、ステートレスパケットビルダのパイプラインの逐次的ステージの全てを通過してレーンから出なければならない。
【００５６】
ステートレスパケットビルダ４５０は、レーン出力フィードバック４５２を、ＰＦＤディストリビュータ４４５に提供してもよい。レーン出力フィードバック４５２は、ステートレスパケットビルダ４５０が完成パケットをチャネライズドパケットバッファ４５５に転送した、ということを示してもよい。レーン出力フィードバック４５２は、完成パケットの長さとレーン識別子とを含んでもよい。
【００５７】
ステートレスパケットビルダ４５０から出力された完成パケットは、チャネライズドパケットバッファ４５５に格納されてもよい。チャネライズドパケットバッファ４５５の各チャネルは、メモリへのパケット書き込みおよびメモリからのパケット読み込みを制御する、メモリおよび論理のブロックを含んでもよい。チャネライズドパケットバッファ４５５の各チャネルは、関連づけられるフロー制御グループについて、完成パケットの格納に専用されてもよい。
【００５８】
一部のフロー制御グループは、他のフロー制御グループからのパケット送信が続いている間に休止されえるので、フロー制御グループ間のパケットの相対的な順序を保証することはできない。各フロー制御グループ内のパケットの順序は保護されえる。すなわち、発信トラフィック４６５の中にパケットが組み込まれる順序は、パケットがスケジューリングされた順序と同じでありえる。この目的で、チャネライズドパケットバッファ４５５は、パケットシーケンスデータ４３４を、ＰＦＤディストリビュータ４４５から受信してもよい。チャネライズドパケットバッファ４５５内の論理は、パケットシーケンスデータを用いることにより、各チャネル内のスケジューリングされた順序で完成パケットを格納してもよい。
【００５９】
チャネライズドパケットバッファ４５５は、従来の先入れ先出し待ち行列として機能しなくてもよい。例えばここで、パケットＡおよびパケットＢは、同じフロー制御グループに属しており、かつ「Ａの次にＢが続く」順序で送信されるようにスケジューリングされている、と仮定する。パケットＡは、ステートレスパケットビルダの第１のレーンに割り当てられ、パケットＢは、ステートレスパケットビルダの第２のレーンに割り当てられる。パケットＢがパケットＡよりも実質的に短い場合には、パケットＢは、パケットＡよりも前に完成され、チャネライズドパケットバッファ４５５に格納されてもよい。この状態において、先入れパケット（パケットＢ）は、先出しパケットであることを意図しない。
【００６０】
出力マルチプレクサ４６０は、チャネライズドパケットバッファ４５５のチャネルからのパケットをインタリーブすることにより、発信トラフィック４６５を形成してもよい。出力マルチプレクサ４６０は、発信トラフィック４６５にパケットが追加される順序を選択するために、様々な周知技術のいずれを用いてもよい。例えば、出力マルチプレクサ４６０は、利用可能な場合には、ラウンドロビン技術を用いることにより、逐次的順序で各チャネルからパケットを読み出してもよい。出力マルチプレクサ４６０は、各チャネルに格納されるパケットの数に基づいて、またはチャネルに割り当てられる所定の優先順に基づいて、パケットを選択してもよい。出力マルチプレクサ４６０は、公平なアクセスアルゴリズムに基づき、またはなんらかの他の態様で、パケットを選択してもよい。
【００６１】
出力マルチプレクサは、フロー制御論理４６４からフロー制御データ４６６を受信してもよい。フロー制御データ４６６は、チャネライズドパケットバッファ４５５およびチャネライズドスケジュール待ち行列４３５の複数のチャネルに対応する複数のフロー制御グループの各々が、休止されるか否かを示してもよい。フロー制御グループが休止される場合には、出力マルチプレクサ４６０は、チャネライズドパケットバッファの関連づけられたチャネルからパケットを読み込むことを中止してもよい。フロー制御論理４６４は、フロー制御パケット４８６を受信および復号することにより、フロー制御データ４６６を提供してもよい。
【００６２】
出力マルチプレクサ４６０は、ＰＦＤディストリビュータ４４５に、チャネル出力フィードバック４６２を提供してもよい。チャネル出力フィードバック４６２は、出力マルチプレクサ４６０がチャネライズドパケットバッファ４５５のチャネルの１つからパケットを取り出した、ということを示してもよい。チャネル出力フィードバック４６２は、取り出されたパケットの長さとチャネル識別子とを含んでもよい。
【００６３】
図５のブロック図に示すチャネライズドパケットバッファ５００は、トラフィックジェネレータ４２０内のチャネライズドパケットバッファ４５５として用いるのに適切なものでありえる。チャネライズドパケットバッファ５００は、例示的なものであり、チャネライズドパケットバッファは、他の態様でも実現可能である。チャネライズドパケットバッファ５００は、ステートレスパケットビルダ（例えばステートレスパケットビルダ４５０）のＮ個のレーンから、完成パケットを受信し、各完成パケットを、Ｍ個のパケットバッファメモリの１つに格納してもよい（これらのうち、パケットバッファ５１０−１およびパケットバッファ５１０−Ｍのみを図示する）。ここで、ＮおよびＭは、１よりも大きい整数である。前例に続けて、Ｎは４であってもよく、Ｍは９であってもよい。完成パケットは、メモリアクセス論理５２０を介して、Ｎ個のレーンからＭ個のパケットバッファへと転送されてもよい。メモリアクセス論理５２０は、任意のレーンからのパケットをパケットバッファのいずれかに書き込むことを可能にしてもよく、２つ以上のレーンからのパケットをそれぞれのパケットバッファに同時に書き込むことを可能にしてもよい。メモリアクセス論理５２０は、一般にクロスバースイッチとして機能してもよい。但し、メモリアクセス論理５２０の実現態様は、物理的なクロスバーマトリックスではなくともよい。
【００６４】
各パケットバッファ５１０−１乃至５１０−Ｍは、循環式バッファとして用いられるランダムアクセスメモリブロックであってもよい。すなわち、メモリブロック内の最高アドレスに対してデータの読み込みまたは書き込みが行われた後に、メモリブロック内の最低アドレスに対して次のデータの読み込みまたは書き込みが行われる。各パケットバッファ５１０−１乃至５１０−Ｍに対してデータの読み込みおよび書き込みが行われる位置は、それぞれの読取ポインタおよび書込ポインタによって制御されてもよい。
【００６５】
チャネライズドパケットバッファは、各パケットバッファ５１０−１乃至５１０−Ｍに一意に関連づけられる読取ポインタ（ＲＰ）５１４−１乃至５１４−Ｍを含んでもよい。各読取ポインタ５１４−１乃至５１４−Ｍは、出力マルチプレクサ（出力マルチプレクサ４６０等）によってパケットが出力バッファから取り出される際に次に読み込まれる、それぞれのパケットバッファ内のアドレスを示してもよい。チャネライズドパケットバッファ５００は、ステートレスビルダの各レーンに関連づけられる書込ポインタ先入れ先出し待ち行列（ＷＰＦＩＦＯ）を含んでもよい（これらのうち、ＷＰＦＩＦＯ待ち行列５３０−１および５３０−Ｎのみを図示する）。ＷＰＦＩＦＯ内の各エントリは、関連づけられるステートレスパケットビルダチャネルから出力される対応パケットが格納される、開始アドレスを示してもよい。チャネライズドパケットバッファは、各パケットバッファ５１０−１乃至５１０−Ｍに一意に関連づけられる、次パケットポインタ（ＮＰＰ）５１２−１乃至５１２−Ｍを含んでもよい。各ＮＰＰは、現在はパケットを格納せず、かつステートレスパケットビルダレーン内で処理中のパケットの格納にもコミットされていない、関連づけられたパケットバッファ内に、最低アドレスを格納してもよい。
【００６６】
書込制御論理５４０は、ＷＰＦＩＦＯ５３０−１乃至５３０−Ｎに置かれる書込ポインタを生成してもよく、ＰＦＤディストリビュータ（ＰＦＤディストリビュータ４４５等）から受信されるパケットシーケンスデータ４３４に基づいて、ＮＰＰ５１２−１乃至５１２−Ｍの値を更新してもよい。ＰＦＤディストリビュータが、ステートレスパケットビルダ４５０のレーンの１つにパケットを割り当てるたびに、パケットシーケンスデータ４３４は、ＰＦＤディストリビュータから書込制御論理５４０へと送信されてもよい。パケットごとのＰＦＤは、レーン識別子、フロー制御グループ／パケットバッファ識別子、およびパケット長を含んでもよい。書込制御論理５４０は、このデータを用いることにより、識別されたステートレスパケットビルダレーンに関連づけられるＷＰＦＩＦＯ５３０−１乃至５３０−Ｎに書込ポインタを追加し、識別されたパケットバッファに関連づけられるＮＰＰ５１２−１乃至５１２−Ｍを再計算してもよい。
【００６７】
前例に続けて、パケットＡおよびＢは、パケットバッファ５１０−１に関連づけられるフロー制御グループに属する、と仮定する。ＰＦＤディストリビュータが、ステートレスパケットビルダ４５０の第１のレーンにパケットＡを割り当てると、ＰＦＤディストリビュータは、パケットＡに関連づけられるパケットシーケンスデータをも書込制御論理５４０に送信する。書込制御論理５４０は、次に、パケットバッファ５１０−１用のＮＰＰ５１２−１を、第１のレーンに関連づけられるＷＰＦＩＦＯの後ろにコピーし、以前のＮＰＰ５１２−１の値にパケットＡの長さを追加することにより、パケットバッファ５１０−１用の新たなＮＰＰを算出する。パケットＡの長さをＮＰＰの値に追加することは、ステートレスパケットビルダの第１のレーンによってパケットＡが配信される際に、パケットバッファ５１０−１の一部がパケットＡを格納するコミットメントを反映することである。同様に、ＰＦＤディストリビュータが、ステートレスパケットビルダの第２のレーンにパケットＢを割り当てる際に、ＰＤＦディストリビュータは、パケットＢに関連づけられるパケットシーケンスデータをも書込制御論理５４０に送信する。書込制御論理は、次に、第２のレーンに関連づけられるＷＰＦＩＦＯの後ろに、ＮＰＰ５１２−１の新たな値をコピーし、ＮＰＰ５１２−１の前の値に、パケットＢの長さを追加する。したがって、ステートレスパケットビルダレーンから受信されたパケットは、パケットがスケジューリングされた順序で格納される。その順序は必ずしも、パケットがチャネライズドパケットバッファにおいて受信された順序であるというわけではない。
【００６８】
図６のブロック図に示すＰＦＤディストリビュータ６００は、トラフィックジェネレータ４２０のＰＦＤディストリビュータ４４５として用いるのに適切なものでありえる。ＰＦＤディストリビュータ６００は、例示的なものであり、ＰＦＤディストリビュータは、他の態様でも実現可能である。ＰＦＤディストリビュータ６００は、チャネライズドスケジュール待ち行列（チャネライズドスケジュール待ち行列４３５等）のＮ個のレーンから、パケット定義データを受信してもよい。ＰＦＤディストリビュータ６００は、ステートレスパケットビルダ（ステートレスパケットビルダ４５０等）のＭ個のレーンに、パケット形成データ４４７を送信してもよい。前例に続けて、Ｎは９に等しくともよく、Ｍは４に等しくともよい。パケット形成データ４４７は、パケット定義データと、それに関連づけられるステートフルコンテンツ４４２とを含んでもよい。ＰＦＤディストリビュータ６００は、チャネルセレクタ６０５と、レーンセレクタ６１０とを備えてもよい。
【００６９】
チャネルセレクタ６０５は、チャネライズドスケジュール待ち行列のＮ個のチャネルから、パケット定義データ４３２を取り出してもよい。チャネルセレクタ６０５は、パケット定義データがチャネライズドスケジュール待ち行列のチャネルから読み込まれる順序を選択するために、様々な周知技術のいずれを用いてもよい。例えば、チャネルセレクタ６０５は、利用可能な場合には、ラウンドロビン技術を用いることにより、逐次的順序で各チャネルからパケット定義データを読み出してもよい。チャネルセレクタ６０５は、チャネライズドスケジュール待ち行列の各チャネルに格納されるデータ項目の数に基づき、またはチャネルに割り当てられる所定の優先順に基づき、チャネルを選択してもよい。チャネルセレクタ６０５は、公平なアクセスアルゴリズムに基づき、またはなんらかの他の態様で、チャネルを選択してもよい。
【００７０】
前述したように、ＰＦＤディストリビュータ６００は、マルチレーン非チャネライズドステートレスパケットビルダに、パケット形成データを提供してもよい。非チャネライズドパケットビルダは、処理中のパケットをレーン内で互いに通過させないので、同一レーン内において次のパケットが完成されえる前に、所与のレーンに割り当てられる各パケットは、完成されて、チャネライズドパケットバッファ（チャネライズドパケットバッファ４５５等）の送信先チャネルへと転送されなければならない。ステートレスパケットビルダの１つ以上のレーンをブロックすることを回避するためには、チャネライズドパケットバッファの送信先チャネルが完成パケットを格納するのに充分な使用可能スペースを有する場合にのみ、ＰＦＤディストリビュータは、パケット形成データ４４７をステートレスパケットビルダに送信してもよい。
【００７１】
チャネルセレクタ６０５は、パケットバッファモデル６２５を維持してもよい。パケットバッファモデルは、チャネライズドパケットバッファの各チャネルの現在の使用可能容量を示してもよい。この目的で、チャネルセレクタ６２５は、チャネライズドパケットバッファの各チャネルから読み込まれたパケットの長さを示す、チャネル出力フィードバックを受信してもよい。各チャネルの使用可能容量とは、（ａ）１つ以上の完成パケットを格納するために現在用いられておらず、かつ（ｂ）ステートレスパケットビルダ内で現在処理中のパケットを格納するために割り当てられていない、メモリ容量である。したがって、各チャネルの使用可能容量とは、チャネルに関連づけられるフロー制御グループが休止され、かつすべての処理中パケットがステートレスパケットビルダによって完成した場合に残りえる、メモリ容量を示すものである。チャネルセレクタは、以下の数式を用いて、各パケットバッファチャネルの使用可能容量をモデル化してもよい。
（使用可能容量）＝（メモリサイズ）−（パケットビルダに割り当てられるパケットの全体長）＋（パケットバッファから読み込まれるパケットの全体長）（１）
【００７２】
ＰＦＤディストリビュータ６００は、ステートレスパケットビルダのＭ個のレーンの１つを選択し、かつ構築されるべきパケットごとにパケット形成データ４４７を受信する、レーンセレクタを備えてもよい。レーンセレクタは、負荷分散アルゴリズムを用いて、レーンを選択してもよい。例えば、レーンセレクタは、ステートレスパケットジェネレータの各レーンの利用可能容量を示す、レーン帯域幅モデル６３０を維持してもよい。レーン帯域幅モデルは、各レーンに割り当てられるパケットの累計長、各レーンにおいて現在処理中のパケットの全体長、またはレーン帯域幅の他のなんらかの測定を追跡してもよい。この目的で、レーンセレクタは、各レーンがチャネライズドパケットバッファに完成パケットを転送する時間を示す、レーン出力フィードバック４５２を受信してもよい。レーンセレクタは、パケット形成データの新たな各項目を、最も利用可能な帯域幅を有するレーンに送信してもよい。
【００７３】
工程の説明
ここで図７を参照すると、トラフィックを生成するための全工程７００は、工程７０５で開始してもよく、多数のパケットが生成された後に工程７９５で終了してもよく、またはオペレータのアクション（図７に図示せず）によって停止されることもある。全工程７００は、トラフィックジェネレータ（トラフィックジェネレータ３２０またはトラフィックジェネレータ４２０等）を用いてトラフィックを生成するために適切なものでありえる。全工程７００は、事実上、巡回的かつリアルタイムなものであってもよい。図７のフローチャートは、単一のポート装置によって実行される工程７００を示す。全工程７００は、テストセッション中に複数のポート装置によって同時に並行して実行されてもよい、ということを理解すべきである。
【００７４】
工程７０５において全工程７００を開始する前に、テストセッションが設計されていてもよい。テストセッションの設計は、例えば、１つ以上のポート装置（ポート装置２１０等）に連結されたテストアドミニストレータのコンピューティング装置（テストアドミニストレータ２０５等）によって行われてもよい。テストセッションを設計することは、ネットワークまたはネットワーク装置のアーキテクチャを判定または定義することと、テストセッション中に各ポート装置によって生成されるべきストリームを定義することと、対応するストリーム形成データを生成することと、それぞれのストリーム形成データを少なくとも１つのポート装置に転送することとを含んでもよい。テストセッションを設計することは、複数のフロー制御グループ（ＦＣＧ）を定義することと、各ストリームを１つのＦＣＧに関連づけることとを更に含んでもよい。ストリームとＦＣＧとの間の関連づけを定義するＦＣＧマップデータを、各ポート装置に提供してもよい。例えば、ＦＣＧマップデータは、各ポート装置内のＦＣＧマップメモリ（メモリ４２４等）に書き込まれてもよい。
【００７５】
工程７１０において、トラフィックジェネレータは、パケットを形成および送信することにより、トラフィックを生成してもよい。工程７１５において、フロー制御（ＦＣ）パケットが受信されたか否かを判定してもよい。フロー制御パケットが受信されなかった場合には、工程７２０において、生成されるべきパケットが更にあるか否かを判定してもよい。更に生成されるべきパケットがない場合には、工程７９５において、テストセッションを終了してもよい。更に生成されるべきパケットがある場合には、工程７１０から全工程を反復してもよい。説明の容易さのために、工程７１０、工程７１５および工程７２０の動作は、逐次的なものとして示すが、これらの動作は並行して実行されてもよい。工程７１０から工程７２０までの動作は、テストセッション中は、基本的に連続的に反復されてもよい。
【００７６】
工程７１５において、フロー制御パケットが受信されたと判定された場合には、工程７２５から工程７５０までの動作は、複数のフロー制御グループの各々について独立して並行して実行されてもよい。工程７２５において、特定のフロー制御グループに影響を及ぼす命令が受信フロー制御パケットに含まれるかどうかを判定してもよい。例えば、フロー制御パケットは、Ｎビットのマスクを含んでもよい。ここでＮは、フロー制御グループの個数であり、各フロー制御グループがパケットに影響されるか否かを示す。フロー制御パケットは、影響を受ける各フロー制御グループの送信を休止または再開すべきかどうかを示す、更なるデータを含んでもよい。フロー制御パケットは、休止されるべき各フロー制御グループの休止期間を示す情報を含んでもよい。
【００７７】
例えば、ＩＥＥＥ８０２．１（Ｑｂｂ）に従う優先フロー制御パケットは、８ビットのマスクを含む。ここで、ビット値が０であれば、パケットが、それぞれのフロー制御グループのステータスに影響を及ぼさない、ということを示す。ビット値が１であれば、パケットが、それぞれのフロー制御グループを休止するように指示している、ということを示す。優先フロー制御パケットもまた、休止されるべき各フロー制御グループの休止期間を含み、休止期間がゼロであれば、前回休止されたフロー制御グループが再開されるべきことを示す。
【００７８】
工程７２５において、特定のフロー制御グループを休止する命令、特定のフロー制御グループの送信を再開する命令、または特定のフロー制御グループへの影響がないこと（命令なし）が、受信されたフロー制御パケットに含まれるかどうかを判定してもよい。受信されたフロー制御パケットが、特定のフロー制御グループに影響を及ぼさない場合には、全工程７００は、工程７１０に戻る。
【００７９】
工程７２５において、特定のフロー制御グループを休止する命令が、受信されたフロー制御パケットに含まれる、と判定された場合には、工程７３０において、パケットジェネレータは、休止されたフロー制御グループに関連づけられるパケットの送信を保留してもよい。例えば、工程７３０において、フロー制御グループが休止されたことを示すフロー制御データが、出力マルチプレクサ（出力マルチプレクサ４６０等）に送信されてもよい。パケットがトラフィックジェネレータ内で破棄されず、かつパイプラインが再び満杯になることを待たずにパケット送信を再開してもよいように、工程７５０において、フロー制御データは、パイプラインの逆方向へと（パケット形成データのフローの逆方向へと）伝搬することにより、トラフィックジェネレータに、休止されたフロー制御グループについてのパケットの生成を規則的に停止させてもよい。
【００８０】
受信されたフロー制御パケットが、指定された時間間隔にわたってフロー制御グループを休止する命令を含む場合には、指定された時間間隔における残り時間を追跡するように、タイマを始動してもよい。工程７４５において、指定された時間間隔が経過したと判定された場合には、工程７４０において、パケットジェネレータは、休止されたフロー制御グループに関連づけられるパケットの送信を自動的に再開してもよい。例えば、工程７４０において、フロー制御グループが休止されないことを示すフロー制御データが、出力マルチプレクサに供給されてもよい。次に、工程７５０において、フロー制御データは、パイプラインの逆方向へと伝搬してもよい。
【００８１】
工程７２５において、受信されたフロー制御パケットがフロー制御グループを再開する命令を含む、と判定された場合には、工程７４０において、パケットジェネレータは、休止されたフロー制御グループに関連づけられるパケットの送信を再開してもよい。例えば、工程７４０において、フロー制御グループが休止されないことを示すフロー制御データが、出力マルチプレクサに供給されてもよい。次に、工程７５０において、フロー制御データは、パイプラインの逆方向へと伝搬してもよい。
【００８２】
図８は、トラフィックジェネレータ内の単一の特定のフロー制御グループのフロー制御のための、例示的工程８００のフローチャートを示すものである。全工程８００は、必ずしも任意の特定の点において開始または終了するものではないが、フロー制御グループのフロー制御が変化するたびに、循環的に反復してもよい。全工程８００は、トラフィックジェネレータ（トラフィックジェネレータ４００等）によって実行されてもよい。トラフィックジェネレータは、スケジューラ、チャネライズドスケジュール待ち行列、ＰＦＤディストリビュータ、パケットビルダ、チャネライズドパケットバッファ、および出力マルチプレクサを備える。全工程８００は、テストセッション中に複数のポート装置によって同時に並行して実行されてもよく、各ポート装置は、複数のフロー制御グループに対して全工程８００を同時に独立して実行してもよい、ということを理解すべきである。
【００８３】
説明の目的のために、全工程８００は、フロー制御グループが休止された場合に、工程８０５において開始するものと仮定する。例えば、トラフィックジェネレータによって受信されたフロー制御パケットに応答して、フロー制御グループが休止されてもよい。フロー制御グループが休止されたあと、工程８１０において、出力マルチプレクサは、休止されたフロー制御グループについて、チャネライズドパケットバッファの対応するチャネルからのパケットの読み込みを停止してもよく、工程８１５において、チャネルが満杯になる。
【００８４】
ＰＦＤディストリビュータが、工程８２０において、関連づけられるパケットバッファの容量が完全にコミットされている（すなわち別のパケットを保持するには使用可能容量が不十分である）と認識するまでは、ＰＦＤディストリビュータは、休止されたフロー制御グループのパケットについて、パケットビルダパケット形成データを送信し続けてもよい。パケットバッファが別のパケットを保持できないということを、ＰＦＤディストリビュータが一旦認識すると、ＰＦＤディストリビュータは、休止されたフロー制御グループに関連づけられるスケジュール待ち行列チャネルからの読み込みを停止してもよい。
【００８５】
ＰＦＤディストリビュータがスケジュール待ち行列チャネルからの読み込みを停止したあと、工程８２５において、スケジュール待ち行列チャネルは満杯になる。これに応答して、工程８３０において、スケジューラは、休止されたフロー制御グループのスケジューリングを停止してもよい。すなわち、スケジューラは、休止されたフロー制御グループ内のパケットについて、パケット定義データの出力を停止してもよい。
【００８６】
工程８５５において、前回休止されたフロー制御グループは、休止解除されてもよい。例えば、トラフィックジェネレータによって受信されたフロー制御パケットに応答して、フロー制御グループは、休止解除されてもよい。フロー制御グループが休止解除されたあと、工程８６０において、出力マルチプレクサは、休止されたフロー制御グループについて、チャネライズドパケットバッファの対応するチャネルからのパケットの読み込みを再開してもよく、工程８６５において、パケットバッファチャネルを満杯でなくさせる（すなわち、完全にコミットされた状態よりも使用可能になる）。
【００８７】
工程８７０において、ＰＦＤディストリビュータは、関連づけられるパケットバッファチャネルの容量がもはや完全にはコミットされた状態でないことを認識してもよい。例えば、ＰＦＤディストリビュータは、１つ以上のパケットがパケットバッファチャネルから読み込まれたことを示すフィードバックを、出力マルチプレクサから受信してもよい。ＰＦＤディストリビュータが、パケットバッファチャネルが別のパケットを保持できるということを一旦認識すると、ＰＦＤディストリビュータは、休止されたフロー制御グループに関連づけられるスケジュール待ち行列チャネルからの読み込みを再開してもよい。
【００８８】
ＰＦＤディストリビュータがスケジュール待ち行列チャネルからの読み込みを再開したあと、工程８７５において、スケジュール待ち行列チャネルは、満杯未満になる。これに応答して、工程８８０において、スケジューラは、休止されたフロー制御グループのスケジューリングを再開してもよい。すなわち、スケジューラは、休止されたフロー制御グループ内のパケットについて、パケット定義データの出力を再開してもよい。
【００８９】
破線によって示されるように、休止されたフロー制御グループは、工程８１０から工程８３０までのフローの任意の点において休止解除されてもよく、その場合には、工程８１０から工程８３０までの動作の一部は生じなくてもよい。同様に、鎖線によって示されるように、休止解除されたフロー制御グループは、工程８６０から工程８８０までのフローの任意の点において休止されてもよく、その場合には、工程８６０から工程８８０までの動作の一部は生じなくてもよい。
【００９０】
まとめ
本明細書の全体にわたって示される実施形態および例は、開示または請求される装置および処理手順を限定するものではなく、典型的な例として考慮されるべきである。本明細書において提示される例の多くは、方法作用またはシステム要素の特定の組み合わせを含むが、それらの作用および要素は、別の態様で組み合わされても同じ目的を達成しえる、ということを理解すべきである。フローチャートに関しては、より多くの工程またはより少ない工程を含んでもよく、示される工程は、本願明細書に記載される方法を達成するために組み合わせられてもよく、更に改良されてもよい。一実施形態のみに関連して説明される作用、構成要素および特徴は、他の実施形態における類似の役割から除外されることを意図しない。
【００９１】
本明細書において、「複数」は、２つ以上を意味する。本明細書において、項目の「セット」は、１つ以上のこのような項目を含んでもよい。明細書または請求項のいずれに記載される場合も、本明細書において用いられる「備える」、「含む」、「持つ」、「有する」、「含有する」、「伴う」等の用語は、制限されない、すなわち含むが限定されないものとして意図されることを理解すべきである。「〜からなる」および「基本的に〜からなる」という移行句は、請求項に関しては、それぞれ限定的移行句または半限定的移行句である。請求項において構成要素を修飾する「第１」、「第２」、「第３」等の序数詞の使用は、優先、順位、または他の請求項に対するある請求項の順番、または方法の作用が実行される時間的な順序を単独で意味するものではなく、ある名称を有する１つの請求項構成要素を、（序数詞なしの）同じ名称を有する別の構成要素から区別し、それらの請求項構成要素を区別するための、単なるラベルとして用いられるものである。本明細書において、「および／または」は、列挙される項目が選択肢であることを意味するが、それらの選択肢もまた、列挙される項目の任意の組合せを含む。
【特許請求の範囲】
【請求項１】
ネットワークをテストするためのテストトラフィックを生成する装置であって、
一連のパケットのためのパケット定義データを提供するスケジューラであって、各パケットは、複数のフロー制御グループからのそれぞれのフロー制御グループに一意に関連づけられる、スケジューラと、
前記パケット定義データを格納するチャネライズドスケジュール待ち行列であって、前記チャネライズドスケジュール待ち行列は、複数のパラレル待ち行列を含み、各待ち行列は、前記複数のフロー制御グループの対応する１つに関連づけられるパケット定義データの格納に専用される、チャネライズドスケジュール待ち行列と、
前記チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従って、独立してパケットを構築する、複数の非チャネライズドパケットビルダレーンと、
前記複数のパケットビルダレーンによって構築されるパケットを格納するチャネライズドパケットバッファであって、前記チャネライズドパケットバッファは、複数のパラレルパケットバッファを含み、各パケットバッファは、前記複数のフロー制御グループの対応する１つに関連づけられるパケットの格納に専用される、チャネライズドパケットバッファと、
前記チャネライズドパケットバッファからのパケットをインタリーブすることにより前記テストトラフィックを提供する出力マルチプレクサと、
を備えることを特徴とする装置。
【請求項２】
受信されたフロー制御パケットに応答して前記フロー制御グループの１つ以上を選択的に休止および休止解除するように構成される、フロー制御論理を更に備え、
前記出力マルチプレクサが、休止されたフロー制御グループに関連づけられるパケットバッファからのパケットの読み込みを中止する、ことを特徴とする請求項１に記載の装置。
【請求項３】
前記チャネライズドスケジュール待ち行列からパケット定義データを読み込み、かつ前記パケット定義データの各項目を選択されたパケットビルダレーンにルーティングする、ように構成されるディストリビュータを更に備える、ことを特徴とする請求項１に記載の装置。
【請求項４】
前記ディストリビュータが、前記チャネライズドパケットバッファ内の各パケットバッファの容量を予測するモデルを備え、
前記対応するパケットバッファの予測される前記容量が、前記パケット定義データによって定義される前記パケットを保持するために充分である場合のみに、前記ディストリビュータが、前記パケット定義データの各項目を前記パケットビルダにルーティングする、ことを特徴とする請求項３に記載の装置。
【請求項５】
前記チャネライズドパケットバッファが、前記ディストリビュータによって提供されるパケットシーケンスデータに従って各出力バッファにパケットを格納するように構成される、ことを特徴とする請求項３に記載の装置。
【請求項６】
前記チャネライズドスケジュール待ち行列が、１つ以上の待ち行列が満杯である場合にスケジューラに通知するように構成され、
前記スケジューラが、満杯の待ち行列に関連づけられるすべてのストリームのスケジューリングを中止するように構成される、ことを特徴とする請求項１に記載の装置。
【請求項７】
ネットワークをテストするためのテストトラフィックを生成する方法であって、一連のパケットについてパケット定義データを生成するステップであって、各パケットは、複数のフロー制御グループからのそれぞれのフロー制御グループに一意に関連づけられる、ステップと、
前記パケット定義データをチャネライズドスケジュール待ち行列に格納するステップであって、前記チャネライズドスケジュール待ち行列は、複数のパラレル待ち行列を含み、各待ち行列は、前記複数のフロー制御グループの対応する１つに関連づけられるパケット定義データの格納に専用される、ステップと、
前記チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従ってパケットを構築するステップと、
構築された前記パケットをチャネライズドパケットバッファに格納するするステップであって、前記チャネライズドパケットバッファは、複数のパラレルパケットバッファを含み、各パケットバッファは、前記複数のフロー制御グループの対応する１つに関連づけられるパケットの格納に専用される、ステップと、
前記チャネライズドパケットバッファから読み込まれたパケットをインタリーブすることにより前記テストトラフィックを提供するステップと、を含むことを特徴とする方法。
【請求項８】
フロー制御パケットを受信するステップと、
受信された前記フロー制御パケットに応答して１つ以上のフロー制御グループを選択的に休止および休止解除するステップと、
休止されたフロー制御グループに関連づけられるパケットバッファからのパケットの読み込みを中止するステップと、
を更に含むことを特徴とする請求項７に記載の方法。
【請求項９】
ディストリビュータがチャネライズドスケジュールＦＩＦＯからパケット定義データを読み込むステップと、前記ディストリビュータが、前記パケット定義データの各項目を、選択されたパケットビルダレーンにルーティングするステップと、を更に含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記ディストリビュータがチャネライズドパケットＦＩＦＯバッファ内の各パケットバッファの容量を予測するモデルを維持するステップと、
前記対応するパケットバッファの予測される前記容量が、前記パケット定義データによって定義される前記パケットを保持するのに充分である場合のみに、前記ディストリビュータが前記パケット定義データの各項目を前記パケットビルダにルーティングするステップと、を更に含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記ディストリビュータによって提供されるパケットシーケンスデータに従って、構築された前記パケットを各出力バッファに格納するステップを更に含む、ことを特徴とする請求項９に記載の方法。
【請求項１２】
チャネライズドスケジュールＦＩＦＯが、１つ以上の待ち行列が満杯である場合にスケジューラに通知するステップと、
前記スケジューラが満杯の待ち行列に関連づけられるすべてのストリームのスケジューリングを中止するステップと、
を更に含むことを特徴とする請求項７に記載の方法。
【請求項１３】
プログラミングコードを格納するコンピュータ読み出し可能格納媒体であって、前記プログラミングコードは、プログラマブルデバイスをプログラムするように用いられるときに、前記プログラマブルデバイスを、ネットワークをテストするためのテストトラフィックを生成する装置を含むように構成し、前記装置は、
一連のパケットについてパケット定義データを提供するスケジューラであって、各パケットは、複数のフロー制御グループからのそれぞれのフロー制御グループに一意に関連づけられる、スケジューラと、
前記パケット定義データを格納するチャネライズドスケジュール待ち行列であって、前記チャネライズドスケジュール待ち行列は、複数のパラレル待ち行列を含み、各待ち行列は、前記複数のフロー制御グループの対応する１つに関連づけられるパケット定義データの格納に専用される、チャネライズドスケジュール待ち行列と、
前記チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従って、独立してパケットを構築する、複数の非チャネライズドパケットビルダレーンと、
前記複数のパケットビルダレーンによって構築されるパケットを格納するチャネライズドパケットバッファであって、前記チャネライズドパケットバッファは、複数のパラレルパケットバッファを含み、各パケットバッファは、前記複数のフロー制御グループの対応する１つに関連づけられるパケットの格納に専用される、チャネライズドパケットバッファと、
前記チャネライズドパケットバッファからのパケットをインタリーブすることにより前記テストトラフィックを提供する出力マルチプレクサと、
を備えることを特徴とするコンピュータ読み出し可能格納媒体。
【請求項１４】
受信されたフロー制御パケットに応答して前記フロー制御グループの１つ以上を選択的に休止および休止解除するように構成される、フロー制御論理を更に備え、
前記出力マルチプレクサが、休止されたフロー制御グループに関連づけられるパケットバッファからのパケットの読み込みを中止する、ことを特徴とする請求項１３に記載のコンピュータ読み出し可能格納媒体。
【請求項１５】
前記チャネライズドスケジュール待ち行列からパケット定義データを読み込み、かつ前記パケット定義データの各項目を選択されたパケットビルダレーンにルーティングする、ように構成されるディストリビュータを更に備える、ことを特徴とする請求項１３に記載のコンピュータ読み出し可能格納媒体。
【請求項１６】
前記ディストリビュータが、前記チャネライズドパケットバッファ内の各パケットバッファの容量を予測するモデルを備え、
前記対応するパケットバッファの予測される前記容量が、前記パケット定義データによって定義される前記パケットを保持するのに充分である場合のみに、前記ディストリビュータが、前記パケット定義データの各項目を前記パケットビルダにルーティングする、ことを特徴とする請求項１５に記載のコンピュータ読み出し可能格納媒体。
【請求項１７】
前記チャネライズドパケットバッファが、前記ディストリビュータによって提供されるパケットシーケンスデータに従って各出力バッファにパケットを格納するように構成される、ことを特徴とする請求項１５に記載のコンピュータ読み出し可能格納媒体。
【請求項１８】
前記チャネライズドスケジュール待ち行列が、１つ以上の待ち行列が満杯である場合にスケジューラに通知するように構成され、
前記スケジューラが、満杯の待ち行列に関連づけられるすべてのストリームのスケジューリングを中止するように構成される、ことを特徴とする請求項１３に記載のコンピュータ読み出し可能格納媒体。
【請求項１】
ネットワークをテストするためのテストトラフィックを生成する装置であって、
一連のパケットのためのパケット定義データを提供するスケジューラであって、各パケットは、複数のフロー制御グループからのそれぞれのフロー制御グループに一意に関連づけられる、スケジューラと、
前記パケット定義データを格納するチャネライズドスケジュール待ち行列であって、前記チャネライズドスケジュール待ち行列は、複数のパラレル待ち行列を含み、各待ち行列は、前記複数のフロー制御グループの対応する１つに関連づけられるパケット定義データの格納に専用される、チャネライズドスケジュール待ち行列と、
前記チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従って、独立してパケットを構築する、複数の非チャネライズドパケットビルダレーンと、
前記複数のパケットビルダレーンによって構築されるパケットを格納するチャネライズドパケットバッファであって、前記チャネライズドパケットバッファは、複数のパラレルパケットバッファを含み、各パケットバッファは、前記複数のフロー制御グループの対応する１つに関連づけられるパケットの格納に専用される、チャネライズドパケットバッファと、
前記チャネライズドパケットバッファからのパケットをインタリーブすることにより前記テストトラフィックを提供する出力マルチプレクサと、
を備えることを特徴とする装置。
【請求項２】
受信されたフロー制御パケットに応答して前記フロー制御グループの１つ以上を選択的に休止および休止解除するように構成される、フロー制御論理を更に備え、
前記出力マルチプレクサが、休止されたフロー制御グループに関連づけられるパケットバッファからのパケットの読み込みを中止する、ことを特徴とする請求項１に記載の装置。
【請求項３】
前記チャネライズドスケジュール待ち行列からパケット定義データを読み込み、かつ前記パケット定義データの各項目を選択されたパケットビルダレーンにルーティングする、ように構成されるディストリビュータを更に備える、ことを特徴とする請求項１に記載の装置。
【請求項４】
前記ディストリビュータが、前記チャネライズドパケットバッファ内の各パケットバッファの容量を予測するモデルを備え、
前記対応するパケットバッファの予測される前記容量が、前記パケット定義データによって定義される前記パケットを保持するために充分である場合のみに、前記ディストリビュータが、前記パケット定義データの各項目を前記パケットビルダにルーティングする、ことを特徴とする請求項３に記載の装置。
【請求項５】
前記チャネライズドパケットバッファが、前記ディストリビュータによって提供されるパケットシーケンスデータに従って各出力バッファにパケットを格納するように構成される、ことを特徴とする請求項３に記載の装置。
【請求項６】
前記チャネライズドスケジュール待ち行列が、１つ以上の待ち行列が満杯である場合にスケジューラに通知するように構成され、
前記スケジューラが、満杯の待ち行列に関連づけられるすべてのストリームのスケジューリングを中止するように構成される、ことを特徴とする請求項１に記載の装置。
【請求項７】
ネットワークをテストするためのテストトラフィックを生成する方法であって、一連のパケットについてパケット定義データを生成するステップであって、各パケットは、複数のフロー制御グループからのそれぞれのフロー制御グループに一意に関連づけられる、ステップと、
前記パケット定義データをチャネライズドスケジュール待ち行列に格納するステップであって、前記チャネライズドスケジュール待ち行列は、複数のパラレル待ち行列を含み、各待ち行列は、前記複数のフロー制御グループの対応する１つに関連づけられるパケット定義データの格納に専用される、ステップと、
前記チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従ってパケットを構築するステップと、
構築された前記パケットをチャネライズドパケットバッファに格納するするステップであって、前記チャネライズドパケットバッファは、複数のパラレルパケットバッファを含み、各パケットバッファは、前記複数のフロー制御グループの対応する１つに関連づけられるパケットの格納に専用される、ステップと、
前記チャネライズドパケットバッファから読み込まれたパケットをインタリーブすることにより前記テストトラフィックを提供するステップと、を含むことを特徴とする方法。
【請求項８】
フロー制御パケットを受信するステップと、
受信された前記フロー制御パケットに応答して１つ以上のフロー制御グループを選択的に休止および休止解除するステップと、
休止されたフロー制御グループに関連づけられるパケットバッファからのパケットの読み込みを中止するステップと、
を更に含むことを特徴とする請求項７に記載の方法。
【請求項９】
ディストリビュータがチャネライズドスケジュールＦＩＦＯからパケット定義データを読み込むステップと、前記ディストリビュータが、前記パケット定義データの各項目を、選択されたパケットビルダレーンにルーティングするステップと、を更に含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記ディストリビュータがチャネライズドパケットＦＩＦＯバッファ内の各パケットバッファの容量を予測するモデルを維持するステップと、
前記対応するパケットバッファの予測される前記容量が、前記パケット定義データによって定義される前記パケットを保持するのに充分である場合のみに、前記ディストリビュータが前記パケット定義データの各項目を前記パケットビルダにルーティングするステップと、を更に含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記ディストリビュータによって提供されるパケットシーケンスデータに従って、構築された前記パケットを各出力バッファに格納するステップを更に含む、ことを特徴とする請求項９に記載の方法。
【請求項１２】
チャネライズドスケジュールＦＩＦＯが、１つ以上の待ち行列が満杯である場合にスケジューラに通知するステップと、
前記スケジューラが満杯の待ち行列に関連づけられるすべてのストリームのスケジューリングを中止するステップと、
を更に含むことを特徴とする請求項７に記載の方法。
【請求項１３】
プログラミングコードを格納するコンピュータ読み出し可能格納媒体であって、前記プログラミングコードは、プログラマブルデバイスをプログラムするように用いられるときに、前記プログラマブルデバイスを、ネットワークをテストするためのテストトラフィックを生成する装置を含むように構成し、前記装置は、
一連のパケットについてパケット定義データを提供するスケジューラであって、各パケットは、複数のフロー制御グループからのそれぞれのフロー制御グループに一意に関連づけられる、スケジューラと、
前記パケット定義データを格納するチャネライズドスケジュール待ち行列であって、前記チャネライズドスケジュール待ち行列は、複数のパラレル待ち行列を含み、各待ち行列は、前記複数のフロー制御グループの対応する１つに関連づけられるパケット定義データの格納に専用される、チャネライズドスケジュール待ち行列と、
前記チャネライズドスケジュール待ち行列から読み込まれたパケット定義データに従って、独立してパケットを構築する、複数の非チャネライズドパケットビルダレーンと、
前記複数のパケットビルダレーンによって構築されるパケットを格納するチャネライズドパケットバッファであって、前記チャネライズドパケットバッファは、複数のパラレルパケットバッファを含み、各パケットバッファは、前記複数のフロー制御グループの対応する１つに関連づけられるパケットの格納に専用される、チャネライズドパケットバッファと、
前記チャネライズドパケットバッファからのパケットをインタリーブすることにより前記テストトラフィックを提供する出力マルチプレクサと、
を備えることを特徴とするコンピュータ読み出し可能格納媒体。
【請求項１４】
受信されたフロー制御パケットに応答して前記フロー制御グループの１つ以上を選択的に休止および休止解除するように構成される、フロー制御論理を更に備え、
前記出力マルチプレクサが、休止されたフロー制御グループに関連づけられるパケットバッファからのパケットの読み込みを中止する、ことを特徴とする請求項１３に記載のコンピュータ読み出し可能格納媒体。
【請求項１５】
前記チャネライズドスケジュール待ち行列からパケット定義データを読み込み、かつ前記パケット定義データの各項目を選択されたパケットビルダレーンにルーティングする、ように構成されるディストリビュータを更に備える、ことを特徴とする請求項１３に記載のコンピュータ読み出し可能格納媒体。
【請求項１６】
前記ディストリビュータが、前記チャネライズドパケットバッファ内の各パケットバッファの容量を予測するモデルを備え、
前記対応するパケットバッファの予測される前記容量が、前記パケット定義データによって定義される前記パケットを保持するのに充分である場合のみに、前記ディストリビュータが、前記パケット定義データの各項目を前記パケットビルダにルーティングする、ことを特徴とする請求項１５に記載のコンピュータ読み出し可能格納媒体。
【請求項１７】
前記チャネライズドパケットバッファが、前記ディストリビュータによって提供されるパケットシーケンスデータに従って各出力バッファにパケットを格納するように構成される、ことを特徴とする請求項１５に記載のコンピュータ読み出し可能格納媒体。
【請求項１８】
前記チャネライズドスケジュール待ち行列が、１つ以上の待ち行列が満杯である場合にスケジューラに通知するように構成され、
前記スケジューラが、満杯の待ち行列に関連づけられるすべてのストリームのスケジューリングを中止するように構成される、ことを特徴とする請求項１３に記載のコンピュータ読み出し可能格納媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−７０３７６（Ｐ２０１３−７０３７６Ａ）
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願番号】特願２０１２−２０８２９４（Ｐ２０１２−２０８２９４）
【出願日】平成２４年９月２１日（２０１２．９．２１）
【出願人】（５０４０９０４００）
【Ｆターム（参考）】
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願日】平成２４年９月２１日（２０１２．９．２１）
【出願人】（５０４０９０４００）
【Ｆターム（参考）】
[ Back to top ]