JP2023544780A - プログラマブルトラフィック管理エンジン - Google Patents

Abstract

本明細書の実施例は、プログラマブルハードウェアコンポーネント及び非プログラマブルハードウェアコンポーネントの両方を含むプログラマブルトラフィック管理エンジンを説明する。非プログラマブルハードウェアコンポーネントは、特徴を生成するために使用され、特徴は、次いで、異なるトラフィック管理アルゴリズムを実施するために使用することができる。ＰＴＭエンジンがどのトラフィック管理アルゴリズムを実施するように構成されているかに応じて、ＰＴＭエンジンは、特徴のサブセット（又は全て）を使用して、アルゴリズムを実行し得る。ＰＴＭエンジン内のプログラマブルハードウェアコンポーネントは、非プログラマブルハードウェアコンポーネントによって提供される特徴のいくつか又は全部を使用して、選択されたアルゴリズムを実施するように、ユーザによってプログラム可能（例えば、カスタマイズ可能）である。
【選択図】図２

Description

本開示の実施例は、概して、異なるトラフィック管理サービス（例えば、パケットスケジューリング、シェーピング、及びポリシング）を実施するようにプログラムすることができるハードウェアコンポーネントを含むプログラマブルトラフィック管理エンジンに関する。

データセンタは、何千ものサーバを含むインフラストラクチャを提供し、ウェブサービス、ウェブインデックス付け、バッチ分析、ストレージサービス、機械学習アプリケーション、ビデオストリーミング、及び金融サービスなどの多種多様なサービスを運営する多くの同時テナントに対応する。これらのアプリケーション又はサービスは、通常、異なる特性及びスループット／レイテンシ要件を有する。サービス品質（quality of service、ＱｏＳ）を提供し、リソースを公平に共有し、ネットワーク利用を改善するために、データセンタは、パケットスケジューリング、シェーピング、及びポリシングなどのトラフィック管理サービスを要求して、テナント用のネットワークリソースを調整する。

しかしながら、これらのトラフィック管理サービスは、現在、サーバ内の中央処理装置（central processing unit、ＣＰＵ）上で実行されるソフトウェアアプリケーションによって提供されており、これは、高いＣＰＵ使用率を招き、他のタスクのために利用可能なＣＰＵ処理能力を低下させる。これは、特に高速回線速度（４０Ｇｂｐｓ～１００Ｇｂｐｓ）クラウドアーキテクチャの場合、データセンタサービスを運営するコストを増加させ、公平性、トラフィックレイテンシ、及びスループットに関してＱｏＳを低下させる。これらのトラフィック管理サービスのうちのいくつかをハードウェアで実施することは、ＣＰＵの負担を軽減するが、現在の既製の高速ネットワークインターフェースカード（network interface card、ＮＩＣ）は、いかなるトラフィック管理サービスも実施しない。回線速度スイッチは、いくつかのトラフィック管理サービスをサポートするが、それらは典型的には、不足ラウンドロビン、及び特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）への絶対優先を含むスケジューリングアルゴリズムの非常に限られた組合せを提供する。回線速度スイッチは、ネットワークオペレータが、それらのスイッチに提供される既存のアルゴリズムを修正及び置換することができないため、プログラマブル性及びカスタマイゼーションを欠いている。

プログラマブルトラフィック管理（programmable traffic management、ＰＴＭ）エンジンを実装するための技法が説明される。一例は、ネットワークスケジューリングアルゴリズムを実行するための入力として使用するための所定数の特徴を生成するように構成された非プログラマブルハードウェアコンポーネントと、異なるタイプのネットワークスケジューリングアルゴリズムを実行するように構成されたプログラマブルハードウェアコンポーネントと、を含むチップ内に配置された集積回路であり、動作中、プログラマブルハードウェアコンポーネントは、非プログラマブルハードウェアコンポーネントによって提供される所定数の特徴のうちの少なくとも１つを使用してネットワークスケジューリングアルゴリズムを実行するように構成されており、集積回路は完全にチップ内に配置されている。

本明細書で説明される一例は、非プログラマブルハードウェアコンポーネント及びプログラマブルハードウェアコンポーネントを備えるＰＴＭエンジンによって実施されるネットワークスケジューリングアルゴリズムを提供することと、ネットワークスケジューリングアルゴリズムへの入力として使用される特徴を識別することと、プログラマブルハードウェアコンポーネントに特徴を提供するように非プログラマブルハードウェアコンポーネントを構成することと、特徴を使用してネットワークスケジューリングアルゴリズムを実行するようにプログラマブルハードウェアコンポーネントを構成することと、を含む方法である。

上記の特徴が詳細に理解され得るように、上記で簡単に要約されたより具体的な説明が、例示的な実装形態を参照することによって行われ得、それらの実装形態のうちのいくつかが添付の図面に例解される。しかしながら、添付の図面は、典型的な例示的な実装形態のみを例解しており、したがって、その範囲を限定するものと見なされるべきではないことに留意されたい。
一例による、プログラマブルトラフィック管理エンジンを有する通信システムのブロック図である。 一例による、プログラマブルトラフィック管理エンジンを例解する。 一例による、プログラマブルトラフィック管理エンジン内のパケット分類器を例解する。 一例による、プログラマブルトラフィック管理エンジン内のキューマネージャを例解する。 例による、プログラマブルトラフィック管理エンジン内のキューディスパッチャを例解する。 一例による、プログラマブルトラフィック管理エンジン内のシェーパを例解する。 一例による、プログラマブルトラフィック管理エンジンによって生成される特徴によってサポートすることができる例示的なディスパッチ時間アルゴリズムの表である。 一例による、プログラマブルトラフィック管理エンジンによって生成される特徴によってサポートすることができる例示的なラウンドロビンアルゴリズムの表である。 一例による、ＰＴＭエンジンにおいてＤＴアルゴリズム又はＲＲアルゴリズムをプログラム又は置換するためのフローチャートである。 一例による、ＰＴＭエンジンを構成するためのフローチャートである。

理解を容易にするために、可能な場合には、図面に共通する同一の要素を示すために同一の参照番号が使用されている。一例の要素は、他の例に有益に組み込まれ得ることが企図される。

様々な特徴が、図面を参照して以下に説明される。図面は縮尺通りに描かれている場合もあり、又は描かれていない場合もあり、同様の構造又は機能の要素は図面全体を通して同様の参照番号によって表されていることに留意されたい。図面は、特徴の説明を容易にすることのみを意図していることに留意されたい。それらは、網羅的な説明として、又は特許請求の範囲に対する限定として意図されていない。更に、例解された例は、示された全ての態様又は利点を有する必要はない。特定の例に関連して説明される態様又は利点は、必ずしもその例に限定されず、そのように例解されていない場合、又はそのように明示的に説明されていない場合であっても、任意の他の例において行うことができる。

本明細書の説明は、上記の課題に対処するための高速回線速度アーキテクチャのためのプログラマブルトラフィック管理（ＰＴＭ）エンジンを説明する。ＰＴＭエンジンの利点は、少なくとも２要素：（ｉ）ＮＩＣ（ｓｍａｒｔＮＩＣを含む）、スイッチ、及びミドルボックスなどの高速回線速度プログラマブルプラットフォーム上で容易に展開することができる柔軟なトラフィック管理オフローディングフレームワークを提供することと、（ｉｉ）ＰＴＭエンジンは、パケットスケジューリングアルゴリズムを抽象化し、開発者が、提案されたトラフィック管理アーキテクチャにおいてＣ／Ｃ＋＋又はＶｅｒｉｌｏｇ／ＶＨＤＬを使用したレジスタ転送レベル（register transfer level、ＲＴＬ）設計などの高レベル仕様を有するアルゴリズムをプログラム及びカスタマイズすることを可能にすることと、である。ＰＴＭエンジンは、ハードウェア上のカスタマイズされたトラフィック管理の開発を単純化し、開発者は、カスタマイズされたネットワークスケジューリングアルゴリズムを設計することにより集中することができる。

一実施形態では、ＰＴＭエンジンは、プログラマブルハードウェアコンポーネント及び非プログラマブルハードウェアコンポーネントの両方を含む。非プログラマブル（又は共有）ハードウェアコンポーネントは、出発時間（departure time、ＤＴ）アルゴリズム及びラウンドロビン（round robin、ＲＲ）アルゴリズムなどの異なるトラフィック管理アルゴリズムを実施するために使用することができる所定数の特徴を生成するために使用される。ＰＴＭエンジンがどのトラフィック管理アルゴリズムを実行するように構成されているかに応じて、ＰＴＭエンジンは、特徴のサブセット（又は全て）を使用して、アルゴリズムを実施し得る。

ＰＴＭエンジン内のプログラマブルハードウェアコンポーネントは、非プログラマブルハードウェアコンポーネントによって提供される特徴のいくつか又は全部を使用して、選択されたアルゴリズムを実施するように、ユーザによってプログラム可能（例えば、カスタマイズ可能）である。プログラマブルハードウェアコンポーネントは、所望のアルゴリズムを実施するために、Ｃ／Ｃ＋＋又はＲＴＬを使用してユーザによってプログラムすることができるプログラマブルロジック又は領域特化型エンジンを含み得る。このようにして、ユーザは、アルゴリズムが、提供される特徴に依存する限り、任意の既知の又は将来のネットワークトラフィックアルゴリズムを実施するように、ＰＴＭエンジンを選択し、変更し、カスタマイズすることができる。ＰＴＭエンジンは、サービスを完全にハードウェアで実施するという利点を有する純粋なソフトウェアトラフィック管理サービスの柔軟性を有し、それによってサーバ内のＣＰＵの負担を軽減する。

図１は、一例による、ＰＴＭエンジン１３５を有する通信システム１００のブロック図である。通信システム１００は、ネットワーク１８０（例えば、インターネット又はローカルエリアネットワーク（local area network、ＬＡＮ））に接続されたホスト１０５（例えば、スタンドアロンサーバ、ブレードサーバ、ラップトップなどのコンピューティングシステム）を含む。ホスト１０５は、プロセッサ１１０、メモリ１１５、及びＮＩＣ１２５を含む。プロセッサ１１０は、任意の数の処理コアを有する任意の数の処理要素（例えば、ＣＰＵ）を表す。メモリ１１５（ホストメモリとも称される）は、揮発性及び不揮発性メモリ要素を含むことができる。この例では、メモリ１１５は、ユーザが、ＰＴＭエンジン１３５を構成することを可能にするＰＴＭドライバ１２０（例えば、プロセッサ１１０上で実行されるソフトウェアアプリケーション）を記憶している。例えば、Ｃ／Ｃ＋＋、ｐｙｔｈｏｎ、又はＰ４を使用して、ＰＴＭドライバ１２０は、ユーザが、マッチングテーブル３１５にアクセスし、実装されたＤＴアルゴリズムとＲＲアルゴリズムとの間で切り替え、ＰＴＭエンジン１３５内の量子及びタイムアウトなどのパラメータを更新することを可能にする。ＰＴＭエンジン１３５をプログラミングするための詳細は、以下で詳細に説明される。

ＮＩＣ１２５は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、又は強化回路、プログラマブルロジック、若しくはこれらの組み合わせを含むシステムオンチップ（system on a chip、ＳｏＣ）であり得る集積回路（ＩＣ）１３０を含む。更に、ＩＣ１３０は、ＮＩＣ１２５内にあるものとして示されているが、他の実施形態では、ＩＣは、ＮＩＣ１２５の外部にあり得、プロセッサ１１０／メモリ１１５とＮＩＣ１２５との間のインターフェースとして機能し得る。更に、ＩＣ１３０（及びその中に具体化されたＰＴＭエンジン１３５）がホスト１０５内にあるのではなく、ＩＣ１３０は、スイッチ及びミドルボックス内で使用され得る。

ＩＣ１３０は、ＰＴＭエンジン１３５が、非プログラマブルハードウェアコンポーネント１４０及びプログラマブルハードウェアコンポーネント１６５を含むことを例解する。非プログラマブルハードウェアコンポーネント１４０は、ＰＴＭエンジン１３５によって実装され得る全てのネットワークスケジュールアルゴリズムによって共有される。言い換えれば、非プログラマブルハードウェアコンポーネント１４０は、ＰＴＭエンジン１３５が実施するように現在プログラムされている特定のネットワークスケジューリングアルゴリズムにかかわらず使用される。したがって、ＰＴＭエンジン１３５が、異なるネットワークスケジューリングアルゴリズムを実施するようにプログラムされている場合、非プログラマブルハードウェアコンポーネントが再使用される。しかしながら、以下で説明するように、非プログラマブルハードウェアコンポーネント１４０によって提供される特徴のいくつかは、特定のアルゴリズムによって使用されない場合がある。すなわち、選択されたアルゴリズムは、非プログラマブルハードウェアコンポーネント１４０によって提供される特徴のサブセットのみを必要とし得る。

この例では、非プログラマブルハードウェアコンポーネント１４０は、ＩＣ１３０内の回路内に実装されたパケット分類器１４５、キューマネージャ１５０、キューディスパッチャ１５５、及びシェーパ１６０を含む。コンポーネントの詳細は、以下の図面においてより詳細に説明される。

プログラマブルハードウェアコンポーネント１６５は、ＩＣ１３０、及びＰＴＭドライバ１２０を使用して構成可能なＰＴＭエンジン１３５内の回路を含む。この例では、プログラマブルハードウェアコンポーネント１６５は、２つの異なるタイプのネットワークスケジューリングアルゴリズム：ＤＴモジュール１７０を使用するＤＴアルゴリズム、及びＲＲモジュール１７５を使用するＲＲアルゴリズムを実装するためのコンポーネントを有する。例えば、ＤＴモジュール１７０及びＲＲモジュール１７５は、プログラマブルロジック（例えば、ＦＰＧＡ又はＳｏＣの一部として）又は領域特化型エンジン（例えば、ＡＳＩＣの一部として）を使用して実装され得る。いずれの場合も、ＤＴモジュール１７０又はＲＲモジュール１７５は、非プログラマブルハードウェアコンポーネント１４０によって提供される特徴を活用して、所望のネットワークスケジューリングアルゴリズムを実施する。ＤＴモジュール又はＲＲモジュールの選択は、ＰＴＭドライバ１２０を介して構成される。本開示は、ＤＴ及びＲＲアルゴリズムのためのプログラマブルモジュールを説明するが、他のタイプのネットワークスケジューリングアルゴリズムのための他のタイプのモジュールも可能である。

図２は、一例による、図１で紹介されたＰＴＭエンジン１３５の詳細バージョンを例解する。上述したように、ＰＴＭエンジン１３５は、異なるネットワークスケジューリングアルゴリズムにわたってＰＴＭエンジンの共通（共有）かつ再利用可能な部分である非プログラマブルハードウェアコンポーネントを有する一方、プログラマブルハードウェアコンポーネントは、設計者によって選択されたネットワークスケジューリングアルゴリズムを実施するようにプログラム可能である。

非プログラマブルハードウェアコンポーネント（ＰＴＭエンジン１３５のシェルとも称される）は、キーとして所与のネットワークパケットのフローＩＤを抽出し、キーに関連付けられた重み及びレートをルックアップするために使用されるパケット分類器１４５と、キューリソースの利用可能性及びアクティブキューの集約された重みを追跡するキューマネージャ１５０と、パケット及びメタデータをバッファリングし、各フローの送信順序を決定するキューディスパッチャ１５５と、帯域幅スロットリングのために各フローの送信レートを制御するシェーパ１６０と、を含む。

一実施形態では、これらの非プログラマブルハードウェアコンポーネントとプログラマブルハードウェアコンポーネント（例えば、ＤＴモジュール１７０及びＲＲモジュール１７５）との間のインターフェースは固定されている。重み付き公平キューイング及び絶対優先などのＤＴに関連するトラフィックスケジューリングアルゴリズムは、ＤＴモジュール１７０において実装される一方、不足ラウンドロビン及び重み付けされたラウンドロビンアルゴリズムなどのＲＲアルゴリズム及びそれらの変形は、ＲＲモジュール１７５によって実施される。ＰＴＭエンジン１３５はまた、ＰＴＭエンジン１３５内のコンポーネントを構成するためにＰＴＭドライバ１２０によって使用される制御プレーン２０５とインターフェースする。この構成は、ホストからローカルに、又はリモートプロシージャコール（remote procedure call、ＲＰＣ）、Ｐ４Ｒｕｎｔｉｍｅ、シンプルネットワーク管理プロトコル（simple network management protocol、ＳＮＭＰ）などの通信プロトコルを介して、暗号化／非暗号化チャネル上で外部サーバからリモートに行うことができる。ＰＴＭエンジン１３５のアーキテクチャは、ＤＴモジュール１７０及びＲＲモジュール１７５における高レベル記述又は低レベル記述のいずれかを用いて様々なネットワークスケジューリングアルゴリズムをカスタマイズ及びプログラムするための柔軟性を設計者に提供する。

パケットがＰＴＭに到着すると、パケット分類器（ＰＣ）モジュールは、構文解析を介してパケットのキーとしてフローＩＤ（ｆｉｄ）を導出する。導出されたキーを用いてその事前構成されたフローテーブルを検索することによって、パケット分類器１４５は、要求の重み及びレートを含む対応するテーブル値を提供する。フローテーブルは、制御プレーン２０５によってローカル又はリモートに構成することができるマッピングのセット（ｆｉｄ－＞＜重み、レート＞）を含む。パケット分類器１４５はまた、パケットの長さを計算し、キューマネージャ１５０への出力として＜ｆｉｄ、重み、レート、パケット長＞を含む制御データ（すなわち、メタデータ）を構築する。

キューマネージャ１５０は、パケット分類器１４５から受信したｆｉｄが既存のレコード＜ｆｉｄ、ｑｉｄ＞と一致するかどうかをチェックし、ここで、ｑｉｄは、受信されたパケットのネットワークフローに割り当てられた一意のキューＩＤである。一致するレコードがない場合、これは、フローが新しいエントリであることを示し、このフローの新しいｑｉｄが割り当てられ、マッピング＜ｆｉｄ、ｑｉｄ＞がキューマネージャ１５０に登録される。加えて、キューマネージャ１５０は、新たに割り当てられた各キューの重みを更新し、アクティブキューの集約された重みを追跡し得る。ある期間キューに到着するパケットがないとき（すなわち、フローが非アクティブになるとき）、そのフローに割り当てられた対応するｑｉｄが請求され、ｑｉｄ（及び対応するキュー）を異なるフローに割り当てることができる。ＤＴモジュール１７０の入力データは、パケットのＤＴを計算するためにキューマネージャ１５０において構築される。キューマネージャ１５０は、更なる処理のためにキューディスパッチャ１５５に提供される制御データ及びメタデータを生成する。

パケットデータ及びそのメタデータは、キューディスパッチャ１５５のパケットキュー及びメタデータキューにそれぞれ記憶される。キューディスパッチャ１５５は、（利用可能なキューリソースがないために）割り当てられたｑｉｄがない場合、又は割り振られたキューがフルである場合、パケット及びそのメタデータをドロップし得る。図２に示される例では、このモジュールにおいてサポートされる２つのディスパッチングモード：ユーザ又は開発者によって構成することができるＤＴモード及びＲＲモードがある。ＤＴモードでは、キューディスパッチャ１５５は、最小ＤＴ値を有するｑｉｄを出力する一方、ＲＲモードでは、各非空キューのｑｉｄを循環順序で送信する。キューディスパッチャ１５５は、フローのパケット長及びレートとともに出力ｑｉｄを伝送し、制御データを形成し、レート制御のためにシェーパ１６０にメタデータを伝送する。

シェーパ１６０におけるトラフィック規制は、トークンバケットに基づく。トークンサイズは、キューディスパッチャ１５５によって提供されるメタデータから抽出された所与のレートで増加される。一実施形態において、シェーパ１６０は、そのパケット長がそのトークンサイズ未満である場合にのみパケットを送出する。

図３～図６は、図２で紹介されたパケット分類器１４５、キューマネージャ１５０、キューディスパッチャ１５５、及びシェーパ１６０に関する詳細な説明を提供する。

図３は、一例による、ＰＴＭエンジン内のパケット分類器１４５を例解する。パケット分類器１４５は、パケットをフローに分類し、各フローの要求の重み及びレートなどの構成データを取得するために使用される。パケット分類器１４５は、構文解析モジュール３０５と、テーブル３１５を含むマッチングモジュール３１０とを含む。テーブル３１５は、ハッシング、トライベースの方法、バイナリ／ターナリコンテントアドレッサブルメモリ（binary/ternary content addressable memory、ＢＣＡＭ／ＴＣＡＭ）、及び他のフロー／トラフィック分類方法を用いて設計することができる。パケット分類器１４５は、Ｐ４、Ｃ／Ｃ＋＋などを使用する高水準合成ツール、又はＶｅｒｉｌｏｇ／ＶＨＤＬを使用するＲＴＬを用いて設計することができる。

パケットがパケット分類器１４５に到着すると、構文解析モジュール３０５は、パケットから情報を抽出して、テーブル３１５を検索するためのキーとして使用されるｆｉｄを構築する。ｆｉｄ（又はキー）は、ソース／宛先ＩＰアドレス、ＩＰ番号、ソース／宛先ポート、及びペイロードなどのパケット内の任意のデータによって構築することができる。導出されたｆｉｄ／キーを用いて、マッチングモジュール３１０は、ｆｉｄ／キーに対応するテーブル項目値に記憶された重み及びレートについてテーブル３１５を調べる。一実施形態では、重みは、パケットの対応するフローの優先度を定義する一方、レートは、フローの出力（送信又は受信）レートを決定するために使用される。ｆｉｄが一致しない場合、マッチングモジュール３１０はデフォルト値を使用し得る。すなわち、ユーザは、ＰＴＭエンジンによって処理され得るフロー（他のフローとは異なるように扱いたい）のサブセットのみに対する重み及びレートを有するようにテーブルを構成し得る。テーブル内のエントリと一致しないパケットが受信された場合、そのパケットにはデフォルト重み及びレート値が割り当てられる。

重み及びレートの両方は、テーブル３１５内のエントリを追加するために、ｃｏｎｆｉｇ＿ｔｂインターフェース及び制御プレーン（図示せず）を介してユーザによって構成される。ｃｏｎｆｉｇ＿ｔｂインターフェースは、例えば、ＡＸＩ－Ｌｉｔｅ（Ａｄｖａｎｃｅｄ ｅＸｔｅｎｓｉｂｌｅ Ｉｎｔｅｒｆａｃｅ－Ｌｉｔｅ）インターフェースを用いて実装することができる。

各パケットについての重み及びレートを識別することに加えて、パケット分類器１４５は、各パケットのパケット長（ｐｋｔｌｅｎ）を計算し、制御データ（すなわち、

）をキューマネージャに出力する。この例では、制御データは、ｆｉｄ、重み、レート、及びパケット長を含む。

図４は、一例による、ＰＴＭエンジン内のキューマネージャ１５０を例解する。キューマネージャ１５０は、キューリソースの利用可能性及びアクティブキューの集約された重みを追跡し、重みマネージャモジュール４０５及びキューマネージャモジュール４２５を含む。キューマネージャモジュール４２５は、新しいフローに一意のｑｉｄを割り当て、期限切れ／非アクティブフローに割り当てられたｑｉｄを請求することによってキューリソースを維持する。重みマネージャ４０５は、各アクティブキューの重みを累積し、各キューの重みを記録する。キューマネージャモジュール４２５は、ＰＴＭエンジンが、物理キューリソースよりもはるかに多くのいくつかのフローをサポートすることを可能にする。すなわち、可能なフローのサブセットのみが、所与の時間ウィンドウにおいてＰＴＭエンジンにパケットをアクティブに送信している可能性がある。これらのアクティブなフローは、ｑｉｄを割り当てることができる一方、アクティブにパケットを生成していないフローはそうではない。キューマネージャモジュール４２５は、以前のアクティブなフローが、現在、非アクティブになったか、又は期限切れになった（例えば、ＰＴＭエンジンが、所定の期間の間、フローに対応するパケットを受信しなかった）ときを判定するために、フローを、絶えず、又は間隔を置いて評価することができる。次いで、キューマネージャモジュール４２５は、ｑｉｄを異なるフローに再割り当てすることができる。このようにして、フローにサービスを提供するために使用されるキューの数を減らすことができる。

キューマネージャ１５０はまた、接続されたモジュールにおける出発時間（ＤＴ）を計算するために使用され得る、システム全体の仮想時間（virtual time、ＶＴ）を記録するためのタイマカウンタを有する。

キューマネージャモジュール４２５は、３つのコンポーネント：キューアロケータ４３５、アイドルプール４３０、及びｐｒｅ＿ＤＴキュー４４０を含む。パケット分類器から制御データ（

）を受信すると、キューマネージャモジュール４２５は、ｆｉｄ及び重みを抽出する。次いで、キューアロケータ４３５は、まず、レコード＜ｆｉｄ、ｑｉｄ＞をキャッシュしたかどうかをチェックする。レコードがない場合、これはフローが新しいエントリであることを示し、キューアロケータ４３５は、新しい利用可能なｑｉｄを求める要求をアイドルプール４３０に発行する。アイドルプール４３０は、アイドル状態を有するキューのｑｉｄを追跡する。新しいｑｉｄを取得した後、又はすでに割り当てられたｑｉｄを識別した後、キューマネージャモジュール４２５は、対応するキューの重み及び集約された重み（ｗｅｉｇｈｔ＿ｓｕｍ）を更新するために、重みを、重みマネージャ４０５に転送する。キューマネージャモジュール４２５はまた、現在非アクティブであるか又は期限切れになっているフローに割り当てられたｑｉｄをいつ請求するかを決定するためのタイムアウトロジックを有する。ある期間に到来するフローのパケットが存在しない場合、タイムアウトロジックがトリガされ、キューマネージャモジュール４２５は、ｑｉｄをアイドルプール４３０に戻し、対応するキャッシュされたエントリをクリアする。タイムアウト時間は、ＡＸＩ－Ｌｉｔｅインターフェースを用いて実装することができる制御インターフェースｃｏｎｆｉｇ＿ｑｍを介して構成することができる。

ｐｒｅ＿ＤＴキュー４４０は、ＤＴモジュール（図４には図示せず）から計算された各アクティブキュー内の先頭要素のＤＴを記憶するために使用される。ｐｒｅ＿ＤＴキュー４４０は、通信のためにＤＴモジュールへの要求／更新インターフェースを提供する。このインターフェースは、ランダムアクセスメモリ（random access memory、ＲＡＭ）読取り／書込みインターフェースを用いて実装することができる。

重みマネージャモジュール４０５は、３つのコンポーネント：重みキュー４１０、重みコントローラ４１５、及び重みアキュムレータ４２０から構成される。重みキュー４１０は、各アクティブキュー、すなわち、そのｑｉｄがフローに割り当てられたキューの重みを記録する。他のコンポーネントからｑｉｄ及び重みを取得するとき、重みコントローラ４１５は、最初に、読取り要求を送ることによって、重みキュー４１０がキューのためのデータを有するかどうかをチェックし得る。重みキュー４１０にレコードが存在し、戻されたデータが、キューマネージャモジュール４２５から受け取った重みと一致しない場合、重みコントローラ４１５は、書き込み要求を発行して、重みキュー４１０を更新し、重みアキュムレータ４２０をアクティブ化して、全てのアクティブなキューの集約された重みを再計算する。集約された重みは、ＤＴモジュールにおいて使用される。

ＤＴモジュールと通信するために、キューマネージャ１５０は、ＤＴ＿ｒｏｌｅ＿ｉｎインターフェース、ＤＴ＿ｒｏｌｅ＿ｏｕｔインターフェース、及びメモリアクセス（ｐｒｅ＿ＤＴ）インターフェースを提供する。一実施形態では、ＤＴ＿ｒｏｌｅ＿ｉｎインターフェース及びＤＴ＿ｒｏｌｅ＿ｏｕｔインターフェースは、＜ｑｉｄ、ｐｋｔｌｅｎ、ＶＴ、ＤＴ、重み、ｗｅｉｇｈｔ＿ｓｕｍ、ｎｅｗ＿ｆｌｏｗ、ｑｉｄｓ＿ａｌｌ＿ｏｃｃｕｐｉｅｄ＞を含む同じデータ構造を有し、ｎｅｗ＿ｆｌｏｗは、フローが新しいエントリであることを示し、ｑｉｄｓ＿ａｌｌ＿ｏｃｃｕｐｉｅｄは、キューリソースが利用可能でないことを示すフラグである。

キューマネージャ１５０は、制御データ（すなわち

）を出力し、これは、ダウンストリームキューディスパッチャへの＜ｑｉｄ、ＤＴ、ｐｋｔｌｅｎ、レート、ｑｉｄｓ＿ａｌｌ＿ｏｃｃｕｐｉｅｄ＞を含む。

図５は、例による、ＰＴＭエンジン内のキューディスパッチャ１５５を例解する。キューディスパッチャ１５５は、異なるフローに属するパケットの送信順序を決定し、３つのコンポーネント：メタデータキュー５０５、パケットキュー５１５、及びＤＴコンパレータ５１０から構成される。キューマネージャ１５０から受信したパケットデータ及び制御データ（

）は、対応するｑｉｄを使用して、パケットキュー５１５及びメタデータキュー５０５にそれぞれ記憶される。ｑｉｄｓ＿ａｌｌ＿ｏｃｃｕｐｉｅｄがハイにアサートされる場合、一実施形態では、キューディスパッチャ１５５は、新しいフローのためのキューリソースがないため、パケット及びそのメタデータをドロップする。同様に、特定のキューがパケットキュー５１５内でフルである場合、そのフローについての全てのパケット及びそれらのメタデータは、破棄される。

図５のキューディスパッチャ１５５は、２つのディスパッチングモード：ＤＴモード及びＲＲモードをサポートするためのハードウェアを含む。開発者は、制御インターフェースｃｏｎｆｉｇ＿ｒｒを使用して、これらのモードのうちのどれが現在アクティブであるかを選択することができる。一実施形態では、これらのモード（及び対応するＤＴ／ＲＲモジュール）のうちの１つだけが、任意の所与の時間にＰＴＭエンジンにおいてアクティブである。ＤＴモードでは、キューディスパッチャ１５５は，最小ＤＴ値を有するｑｉｄを出力する一方、ＲＲモードでは、キューディスパッチャ１５５は、各非空キューのｑｉｄを循環順序で送信する。シェーパへのキューディスパッチャ１５５の制御出力（すなわち、

）は、ｐｋｔｌｅｎ、ｑｉｄ、及びレートを含む。

ＤＴモードで動作するとき、メタデータキュー５０５は、全ての非空キューの先頭メタデータ要素（ｄｔｓ_ｔｏｐ）を選んで、最小ＤＴ値を有するｑｉｄを取得するようにＤＴコンパレータ５１０に命令する。図６で説明したように、最小ＤＴ値を有するパケットの

を使用して、シェーパは、パケットキュー５１５に記憶された実際のパケットデータをいつ送信するかを決定し、読み出し信号（ｐｏｐ_ｑｉｄ）を発行して、対応するキュー内のデータを得る。

ＲＲモードで動作するとき、非空キューのｑｉｄは、ＲＲモジュール１７５において実施されるラウンドロビンスケジューリングアルゴリズムに従って循環順序で選択される。キューディスパッチャ１５５の残りの動作は、ＤＴモードで動作しているときと同じである。

ＲＲモジュール１７５と通信するために、キューディスパッチャ１５５は、ＲＲ＿ｒｏｌｅ＿ｉｎインターフェース及びＲＲ＿ｒｏｌｅ＿ｏｕｔインターフェースを提供する。ＲＲ＿ｒｏｌｅ＿ｉｎインターフェースは、ＶＬＤ、ｑｉｄ、重み、ｐｋｔｌｅｎ、及びレートを含む一方、ＲＲ＿ｒｏｌｅ＿ｏｕｔインターフェースは、ｑｉｄ、ｐｋｔｌｅｎ、及びレートを含む。制御インターフェースｃｏｎｆｉｇ＿ｒｒは、ｃｏｎｆｉｇ＿ｑｔ_ｉを用いてＤＴ／ＲＲモード及びキューの量子値を構成する。この制御インターフェースは、ＡＸＩ－Ｌｉｔｅインターフェースを用いて実装することができる。量子値は、不足ラウンドロビン及び不足重み付けラウンドロビンなど、ＲＲモジュール１７５における様々なＲＲスケジューリングアルゴリズムを開発するために活用することができる。

図６は、一例による、ＰＴＭエンジン内のシェーパ１６０を例解する。シェーパ１６０は、帯域幅スロットリングのための各フローの送信レートを制御し、ｒｄｙ＿ＦＩＦＯ６０５、トークンバケット６１５（すなわち、トークンバケットクラスタ）、及びアービタ６２０を含む。ｒｄｙ＿ＦＩＦＯ６０５は、キューディスパッチャ１５５から受信したメタデータをバッファリングする。ｒｄｙ＿ＦＩＦＯ６０５におけるデータの受信順序は、ＤＴモジュール又はＲＲモジュールにおけるパケットスケジューリングアルゴリズムの結果を示す。示されるように、ｑｉｄは、トークンバケット６１５のうちのどれが、ＦＩＦＯ６０５によって出力されている対応するパケットのｐｋｔｌｅｎ及びレートを受信すべきかを選択するために、マルチプレクサ（ｍｕｘ）６１０のための選択信号として使用される。

一実施形態では、トークンバケット６１５の各々は、図５のパケットキュー５１５のうちの１つに対応する。トークンバケット６１５は、フローのパケットデータを調整して、ネットワークポリシング及びシェーピングを実施する。トークンは、異なる回線速度システムのデータバスの幅に依存するバイトの単位を表す。各トークンバケット６１５の深さは、記憶することができるトークンの最大数を示す一方、サイズは、バケット６１５内の現在利用可能なトークンを示す。一実施形態では、トークンは、固定レートでバケット６１５に追加され、固定レートは、ユーザによってパケット分類器に設定され得る。

データを受信したトークンバケット６１５は、ｒｄｙ＿ＦＩＦＯ６０５からｍｕｘ６１０を介して先頭要素＜ｐｋｔｌｅｎ’、ｑｉｄ’、レート’＞を取得すると、まず、レート’が現在のレート設定、レート_ｑｉｄ’に等しいか否かをチェックする。２つのレートが同じ値を有する場合、これは、パケットが以前に構成された古いフローに属することを示す。ｐｋｔｌｅｎ’が利用可能なトークンサイズ、サイズ_ｑｉｄ’より小さい場合、対応するトークンバケット６１５は、ｑｉｄ’をアービタ６２０に解放する。別の言い方をすれば、トークンバケット６１５は、パケットの長さよりも多くのトークンをそのバケット内に有する。そうでない場合、トークンバケット６１５は、ｐｋｔｌｅｎ’がサイズ_ｑｉｄ’未満になるまでｑｉｄ’をブロックする。すなわち、トークンバケット６１５は、より多くのトークンが所定のレートに従って追加されるまで待機する。バケット６１５がパケット長よりも多くのトークンを有すると、ｑｉｄ’がアービタ６２０に転送される。

レート’がレート_ｑｉｄ’と異なる場合、トークンバケット６１５は、そのレートをレート’で置き換え、サイズ_ｑｉｄ’を０にリセットする。いくつかのトークンバケット６１５が同時にｑｉｄをアービタ６２０に解放することができるため、異なるフローのパケットが同じデータバスを共有するので、これは輻輳につながる。この輻輳問題を解決するために、レディステータスを有する全てのｑｉｄがアービタ６２０内にバッファリングされる。複数のｑｉｄが受信された場合、アービタ６２０は、伝送のためにｑｉｄ（及び対応するパケット）のうちの１つを選択する。一実施形態では、アービタ６２０は、循環順序でｑｉｄを選択し、図５のキューディスパッチャ１５５内のどのパケットキュー５１５がパケットを伝送することができるかを示すｐｏｐ_ｑｉｄ信号を生成する。すなわち、シェーパ１６０は、ｐｏｐ_ｑｉｄ信号をキューディスパッチャ１５５に送信し、共有データバスを使用して、どのパケットキュー５１５が伝送されるべきかを知る。

一実施形態では、フローに割り当てられたトークンバケット６１５が、所定の期間アイドル状態のままである場合、その利用可能なトークンサイズは、ユーザによって設定されたトークンタイムアウトに従ってリセットすることができる。トークンタイムアウト値は、ＡＸＩ－Ｌｉｔｅインターフェースを用いて実装することができる制御インターフェースｃｏｎｆｉｇ＿ｓｐを介して構成することができる。

上述したように、ＰＴＭエンジンは、ネットワークスケジューリングアルゴリズムをカスタマイズするために開発者の役割を確保する。図２のＤＴモジュール１７０及びＲＲモジュール１７５は、（例えば、ＣＩＣ＋＋などの高レベル仕様を有するＨＬＳを使用して、又はＶｅｒｉｌｏｇ／ＶＨＤＬを有するＲＴＬを使用して）ＦＰＧＡ上で設計することができ、又はＲＩＳＣ（Reduced-Instruction-Set-Computer、縮小命令セットコンピュータ）コアなどのコプロセッサとインターフェースすることができる。ＤＴモジュール１７０は、各パケット／フローの出発時間又は優先度を計算するために必要なアルゴリズムを開発するために使用することができる一方、ＲＲモジュール１７５は、出発時間に関連しない多くのラウンドロビン変形を設計するために利用することができる。ＤＴモジュール１７０及びＲＲモジュール１７５を活用して、開発者は、時間のかかるシステム統合の代わりに、ネットワークスケジューリングアルゴリズムを開発することに集中することができる。

両方のＤＴベース及びＲＲベースのアルゴリズムは、アルゴリズムへの入力である特徴のセットの関数として抽象化及び定義することができる。図７は、一例による、ＰＴＭエンジンによって生成される特徴によってサポートすることができる例示的なＤＴアルゴリズムの表である。表７００内の特徴は、キューＩＤ（ｑｉｄ）、パケット長（ｐｋｌｅｎ）、仮想時間（ＶＴ）、前回の出発時間（ｐｒｅ＿ＤＴ）、重み、及び集約された重み（ｗｅｉｇｈｔ＿ｓｕｍ）を含む。それらの特徴を用いて、開発者は、表７００に列挙されるアルゴリズムを含むが、それに限定されない、ＤＴ関連アルゴリズムの大きなセットを設計及び実装することができる。ＰＴＭエンジンのプログラマビリティ及びカスタマイゼーションをサポートするために、ＤＴモジュール１７０のインターフェースは、ｑｉｄ、ｐｋｔｌｅｎ、ＶＴ、ＤＴ、重み、ｗｅｉｇｈｔ＿ｓｕｍ、ｎｅｗ＿ｆｌｏｗ、及びｑｉｄｓ＿ａｌｌ＿ｏｃｃｕｐｉｅｄを受信することができる。ＤＴモジュール１７０はまた、フローのパケットの計算された出発時間を記録するために、図４のｐｒｅ＿ＤＴキュー４４０と通信することもできる。ＤＴモジュール１７０のためのインターフェースは、ＲＡＭ読取り／書込みインターフェースを用いて実装され得る。

図８は、一例による、ＰＴＭエンジンによって生成される特徴によってサポートすることができる例示的なラウンドロビンアルゴリズムの表８００である。表８００は、３つの代表的なＲＲ関連アルゴリズムの必要な特徴（又は入力）を示す。特徴は、ｑｉｄ、重み、ｐｋｔｌｅｎ、及び量子を含む。これらの特徴を利用して、ラウンドロビン（ＲＲ）、重み付けラウンドロビン（Weighted Round Robin、ＷＲＲ）、不足ラウンドロビン（Deficit Round Robin、ＤＲＲ）、優先度付き不足ラウンドロビン（Deficit Round Robin with priority、ＤＲＲ＋及びＤＲＲ＋＋）、及び修正不足ラウンドロビン（Modified Deficit Round Robin、ＭＤＲＲ）を含むがこれらに限定されない多くのラウンドロビンアルゴリズム変形を表現することができる。

様々なラウンドロビンアルゴリズムをサポートし、ＰＴＭにおけるカスタマイゼーションを提供するために、図２のＲＲモジュール１７５のインターフェースは、表８００に列挙された特徴を受信又は生成することができる。ＲＲモジュール１７５のインターフェースは、ｑｉｄ、ｐｋｔｌｅｎ、及びレートを出力しながら、ｖｌｄ、ｑｉｄ、重み、ｐｋｔｌｅｎ、及びレートを入力として受信することができる。ｖｌｄ信号は、新しいパケットが来るたびにハイにアサートされ得る。

図９は、一例による、ＰＴＭエンジンにおいてＤＴアルゴリズム又はＲＲアルゴリズムをプログラム又は置換するための方法９００のフローチャートである。ブロック９０５において、ユーザは、ＰＴＭエンジンにおいて実装するためのネットワークスケジューリングアルゴリズムを定義する。例えば、ユーザは、アルゴリズムを定義するために、ＨＬＳツール又はＲＴＬを有する高レベルプログラミング言語（例えば、Ｃ／Ｃ＋＋）を使用し得る。

上述したように、アルゴリズムは、ＤＴタイプのアルゴリズム又はＲＲタイプのアルゴリズムであり得る。しかしながら、実施形態は、これらのタイプのアルゴリズムに限定されない。他のタイプのアルゴリズムもＰＴＭエンジンによってサポートすることができ、これは、ＰＴＭエンジンが（ＤＴモジュール及びＲＲモジュールに加えて、又はその代わりに）追加のプログラマブルコンポーネントを有することができることを意味し得る。

ブロック９１０において、開発者は、ネットワークスケジューリングアルゴリズムによって使用される特徴を識別する。図７及び８に示されるように、ＤＴ及びＲＲベースのアルゴリズムのいくつかは、非プログラマブルハードウェアコンポーネント（例えば、パケット分類器、キューマネージャ、キューディスパッチャ、及びシェーパ）によって提供される特徴のサブセットのみを使用する一方、他のアルゴリズムは、全ての特徴を使用する。例えば、図７では、先入れ先出しＤＴアルゴリズムは、ｑｉｄ及びＶＴのみを入力として使用する一方、重み付き公平キューイングＤＴアルゴリズムは、全ての特徴を入力として使用する。

アルゴリズムを定義するとき、開発者は、どの特徴が入力として必要とされ、ＰＴＭエンジンによって提供されるどの特徴が必要とされないかを規定し得る。

ブロック９１５において、開発者は、識別された特徴をＰＴＭエンジン内のプログラマブルハードウェアコンポーネント（又は複数のコンポーネント）に提供するように、非プログラマブルハードウェアコンポーネントを構成する。一実施形態では、開発者は、ＰＴＭドライバ１２０を介して制御プレーン２０５を使用して、非プログラマブルハードウェアコンポーネントを構成する。例えば、アルゴリズムがＲＲベースのアルゴリズムである場合、開発者は、識別された特徴をＰＴＭエンジン内のＲＲモジュールに提供するように、非プログラマブルハードウェアコンポーネントを構成し得る。逆に、アルゴリズムがＤＴアルゴリズムである場合、開発者は、識別された特徴をＰＴＭエンジン内のＤＴモジュールに提供するように、非プログラマブルハードウェアコンポーネントを構成する。

ブロック９２０で、開発者は、識別された特徴を使用してアルゴリズムを実行するように、プログラマブルハードウェアコンポーネントを構成する。すなわち、非プログラマブルハードウェアコンポーネントによって提供される特徴を使用して、開発者は、特徴を入力として使用してアルゴリズムを実行するように、プログラマブルコンポーネント（例えば、ＤＴモジュール又はＲＲモジュール）を構成する。一実施形態では、（選択されたネットワークスケジューリングアルゴリズムのタイプに応じて）ＰＴＭエンジンが動作している所与の時間に、ＤＴモジュール又はＲＲモジュールのうちの一方のみがアクティブである一方、他方は非アクティブ又は使用されない。上述したように、これらのモジュールは、プログラマブルロジック又は領域特化型エンジンを使用して実装し得る。構成されると、ＰＴＭエンジンは、次いで、上記の図２～６で説明したように実行することができる。

図１０は、一例による、ＰＴＭエンジンを構成するための方法１０００のフローチャートである。ブロック１００５において、ＰＴＭドライバは、ネットワークフローの所望の実施パラメータを受信する。実施パラメータは、優先度、重み、所望のレートなどを含むことができる。一実施形態では、ＰＴＭドライバは、フローのＩＤも構築する。

ブロック１０１０で、ＰＴＭドライバは、フローＩＤをブロック１００５で受信された実施パラメータの値にマッピングするキー－値ペアを構築する。

ブロック１０１５において、ＰＴＭドライバは、ＰＴＭエンジンにおいてマッチングテーブルを構成する。すなわち、ＰＴＭドライバは、図３に例解されるマッチングモジュール３１０のテーブル３１５（すなわち、マッチングテーブル）にキー－値を記憶する。

上記では、本開示において提示される実施形態が参照される。しかしながら、本開示の範囲は、特定の記載された実施形態に限定されない。代わりに、説明される特徴及び要素の任意の組み合わせは、異なる実施形態に関連するか否かにかかわらず、企図される実施形態を実装し行うために企図される。更に、本明細書に開示される実施形態は、他の可能な解決策又は従来技術に勝る利点を達成し得るが、特定の利点が所与の実施形態によって達成されるか否かは、本開示の範囲を限定するものではない。したがって、前述の態様、特徴、実施形態、及び利点は、単に例示的なものであり、特許請求の範囲に明示的に記載されている場合を除き、添付の特許請求の範囲の要素又は限定とは見なされない。

当業者によって理解されるように、本明細書に開示される実施形態は、システム、方法、又はコンピュータプログラム製品として具現化され得る。したがって、態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、又は本明細書では全て一般に「回路」、「モジュール」、若しくは「システム」と呼ばれ得るソフトウェア態様とハードウェア態様とを組み合わせた実施形態の形態をとり得る。更に、態様は、コンピュータ可読プログラムコードが具現化された１つ以上のコンピュータ可読媒体において具現化されたコンピュータプログラム製品の形態をとり得る。

１つ以上のコンピュータ可読媒体の任意の組合せを利用し得る。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体であり得る。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学、電磁気、赤外線、若しくは半導体のシステム、装置、若しくはデバイス、又は前述の任意の好適な組み合わせであり得るが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）は、１つ以上のワイヤを有する電気接続、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（read-only memory、ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（erasable programmable read-only memory、ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスク読み出し専用メモリ（compact disc read-only memory、ＣＤ－ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、又は前述の任意の適切な組み合わせを含む。本明細書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、又はデバイスによって、又はそれに関連して使用するためのプログラムを含むか、又は記憶することができる任意の有形媒体である。

コンピュータ可読信号媒体は、例えば、ベースバンドにおいて、又は搬送波の一部として、コンピュータ可読プログラムコードが具現化された伝搬データ信号を含み得る。そのような伝搬信号は、電磁気、光学、又はそれらの任意の好適な組み合わせを含むが、それらに限定されない、種々の形態のうちのいずれかをとり得る。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、又はデバイスによって、又はそれに関連して使用するためのプログラムを通信、伝搬、又は移送することができる任意のコンピュータ可読媒体であり得る。

コンピュータ可読媒体上に具現化されたプログラムコードは、ワイヤレス、ワイヤライン、光ファイバケーブル、ＲＦなど、又は前述の任意の好適な組合せを含むが、それらに限定されない、任意の適切な媒体を使用して伝送され得る。

本開示の態様の動作を実行するためのコンピュータプログラムコードは、例えば、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語又は同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組合せで書かれ得る。プログラムコードは、ユーザのコンピュータ上で完全に、ユーザのコンピュータ上で部分的に、スタンドアロンソフトウェアパッケージとして、ユーザのコンピュータ上で部分的に、リモートコンピュータ上で部分的に、又はリモートコンピュータ若しくはサーバ上で完全に実行し得る。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）若しくは広域ネットワーク（wide area network、ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続し得るか、又は外部コンピュータ（例えば、インターネットサービスプロバイダを使用するインターネットを介して）に接続し得る。

本開示の態様は、本開示に提示された実施形態による方法、装置（システム）、及びコンピュータプログラム製品のフローチャート例解図及び／又はブロック図を参照して以下に記載されている。フローチャート例解図及び／又はブロック図の各ブロック、並びにフローチャート例解図及び／又はブロック図におけるブロックの組み合わせは、コンピュータプログラム命令によって実装することができることが理解されよう。これらのコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理装置のプロセッサを介して実行される命令が、フローチャート及び／又はブロック図のブロックで指定された機能／行為を実施するための手段を作成するような機械をもたらすように、汎用コンピュータ、専用コンピュータ、又は他のプログラマブルデータ処理装置のプロセッサに提供し得る。

これらのコンピュータプログラム命令はまた、コンピュータ可読媒体に記憶された命令が、フローチャート及び／又はブロック図のブロックで指定された機能／行為の態様を実装する命令を含む製造物品を生成するように、コンピュータ、他のプログラマブルデータ処理装置、又は他のデバイスに、特定の方法で機能するように指示することができる、コンピュータ可読媒体に記憶し得る。

コンピュータプログラム命令はまた、コンピュータ、他のプログラマブルデータ処理装置、又は他のデバイスにロードされて、コンピュータ、他のプログラマブル装置、又は他のデバイス上で実施される一連の動作ステップを行わせて、コンピュータ実装プロセスを生成し得、そのため、コンピュータ又は他のプログラマブル装置上で実行される命令は、フローチャート及び／又はブロック図のブロックに指定される機能／行為を実装するためのプロセスを提供する。

図中のフローチャート及びブロック図は、本発明の様々な実施例によるシステム、方法、及びコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能、及び動作を例解する。これに関して、フローチャート又はブロック図の各ブロックは、指定された論理機能を実装するための１つ以上の実行可能命令を含む、命令のモジュール、セグメント、又は部分を表し得る。いくつかの代替的な実装形態では、ブロックに記載されている機能は、図に記載された順序から外れて発生し得る。例えば、連続して示される２つのブロックは、実際には実質的に同時に実行され得、又はブロックは、関与する機能に応じて、逆の順序で実行され得ることがある。ブロック図及び／又はフローチャート例解図の各ブロック、並びにブロック図及び／又はフローチャート例解図におけるブロックの組み合わせは、指定された機能若しくは行為を実施するか、又は専用ハードウェアとコンピュータ命令との組み合わせを行う、専用ハードウェアベースのシステムによって実装することができることにも留意されたい。

前述は特定の実施例を対象とするが、他の実施例及び更なる実施例が、その基本的な範囲から逸脱することなく考案され得、その範囲は、以下の特許請求の範囲によって決定される。

Claims (15)

1. チップ内に配置された集積回路であって、
   ネットワークスケジューリングアルゴリズムを実行するための入力として使用するための所定数の特徴を生成するように構成された非プログラマブルハードウェアコンポーネントと、
   異なるタイプのネットワークスケジューリングアルゴリズムを実行するように構成されたプログラマブルハードウェアコンポーネントであって、動作中に、前記プログラマブルハードウェアコンポーネントが、前記非プログラマブルハードウェアコンポーネントによって提供される前記所定数の特徴のうちの少なくとも１つを使用して、前記ネットワークスケジューリングアルゴリズムを実行するように構成されており、前記集積回路が、完全に前記チップ内に配置されている、プログラマブルハードウェアコンポーネントと、を備える、集積回路。
2. 動作中に、前記プログラマブルハードウェアコンポーネントが、１つのネットワークスケジューリングアルゴリズムのみを実行するように構成されている、請求項１に記載の集積回路。
3. 前記プログラマブルハードウェアコンポーネントが、第１のプログラマブルコンポーネント及び第２のプログラマブルコンポーネントを備え、動作中、前記第１のプログラマブルコンポーネント及び第２のプログラマブルコンポーネントのうちの一方のみが、前記ネットワークスケジューリングアルゴリズムを実行するために使用される一方、他方のプログラマブルコンポーネントは、無視されるか、又は使用されない、請求項２に記載の集積回路。
4. 前記第１のプログラマブルコンポーネントが、出発時間（ＤＴ）アルゴリズムを実施するように特化されており、前記第２のプログラマブルコンポーネントが、ラウンドロビン（ＲＲ）アルゴリズムを実施するように特化されている、請求項３に記載の集積回路。
5. 前記ネットワークスケジューリングアルゴリズムは、所定数の特徴のサブセットのみを入力として使用する、請求項１に記載の集積回路。
6. 前記非プログラマブルハードウェアコンポーネント及び前記プログラマブルハードウェアコンポーネントが、同じ集積回路上に実装されている、請求項１に記載の集積回路。
7. 前記プログラマブルハードウェアコンポーネントが、前記同じ集積回路上のプログラマブルロジック又は領域特化型エンジンのうちの１つを使用して実装されている、請求項６に記載の集積回路。
8. 前記プログラマブルハードウェアコンポーネントが、動作中、出発時間（ＤＴ）アルゴリズムを実施するように特化された第１のプログラマブルコンポーネント、及びラウンドロビン（ＲＲ）アルゴリズムを実施するように特化された第２のプログラマブルコンポーネントを備え、前記非プログラマブルハードウェアコンポーネント及び前記プログラマブルハードウェアコンポーネントが、同じ集積回路上に実装されている、請求項１に記載の集積回路。
9. 方法であって、
   非プログラマブルハードウェアコンポーネント及びプログラマブルハードウェアコンポーネントを備えるプログラマブルトラフィック管理（ＰＴＭ）回路によって実施されるためのネットワークスケジューリングアルゴリズムを提供することと、
   前記ネットワークスケジューリングアルゴリズムへの入力として使用される特徴を識別することと、
   前記プログラマブルハードウェアコンポーネントに前記特徴を提供するように、前記非プログラマブルハードウェアコンポーネントを構成することと、
   前記特徴を使用して前記ネットワークスケジューリングアルゴリズムを実行するように、前記プログラマブルハードウェアコンポーネントを構成することと、を含む、方法。
10. 前記プログラマブルハードウェアコンポーネントが、異なるタイプのネットワーキングトラフィックアルゴリズムを実行することが可能であり、前記方法が、
    前記プログラマブルハードウェアコンポーネントを使用して、前記ネットワーキングスケジューリングアルゴリズムのみを実行することを更に含む、請求項９に記載の方法。
11. 前記プログラマブルハードウェアコンポーネントが、第１のプログラマブルコンポーネント及び第２のプログラマブルコンポーネントを備え、前記第１のプログラマブルコンポーネント及び第２のプログラマブルコンポーネントのうちの一方のみが、前記ネットワークスケジューリングアルゴリズムを実行するために使用される一方、他方のプログラマブルコンポーネントは、無視されるか、又は使用されない、請求項１０に記載の方法。
12. 前記第１のプログラマブルコンポーネントが、出発時間（ＤＴ）アルゴリズムを実施するように特化されており、前記第２のプログラマブルコンポーネントが、ラウンドロビン（ＲＲ）アルゴリズムを実施するように特化されている、請求項１１に記載の方法。
13. 前記非プログラマブルハードウェアコンポーネントが、所定数の特徴を生成するように構成されており、前記プログラマブルハードウェアコンポーネントに前記特徴を提供するように、前記非プログラマブルハードウェアコンポーネントを構成することが、
    前記ネットワークスケジューリングアルゴリズムを実行するときに、前記プログラマブルハードウェアコンポーネントに提供するための、前記所定数の特徴のサブセットを選択することを含む、請求項９に記載の方法。
14. 前記プログラマブルハードウェアコンポーネント及び前記非プログラマブルハードウェアコンポーネントを構成することが、データプレーンとは別個の制御プレーンを使用して、前記ＰＴＭ迂遠に通信するソフトウェアアプリケーションを使用して実施され、前記方法が、
    前記ネットワークスケジューリングアルゴリズムに従って、前記ＰＴＭ迂遠において前記データプレーン上で受信されたパケットを処理することを更に含む、請求項９に記載の方法。
15. 前記非プログラマブルハードウェアコンポーネント及び前記プログラマブルハードウェアコンポーネントが、同じ集積回路上に実装されている、請求項９に記載の方法。
    

Images