"ルーターにおけるデータパケットの処理を制御する方法であって、前記ルーターは受信したデータパケットを入来データキューに格納し、前記入来データキューに格納されているパケットが、前記ルーターによって選択されたパケットフローレートにおいて処理される場合に、前記方法は、前記パケットフローレートを、前記ルーターにおける現在の動作状態に基づいて調整する工程を備えることを特徴とする方法。前記入来データキューが、所定の処理インターバルにおいて前記ルータによって処理されるべき前記入来データキューに保持されたパケット数を示す値を有する処理すべきパケットフィールドを含む、データキューヘッド構造を有し、前記パケットフローレートが、前記処理すべきパケットフィールドの値を増加又は減少することにより調整されることを特徴とする請求項1に記載の方法。前記データキューヘッド構造はさらに、持続的データレートフィールドと、バーストデータレートフィールドとを含み、もし、前記入来データキューにおいてデータバーストが検出されなければ、前記処理すべきパケットフィールドの値が、前記持続的データレートフィールドの値に基づき、もし、前記入来データキューにおいてデータバーストが検出されれば、前記処理すべきパケットフィールドの値が、所定期間において前記バーストデータレートフィールドの値に基づくことを特徴とする請求項2に記載の方法。前記データキューヘッド構造がさらに、処理すべきパケットフィールドの値を、バーストデータレートフィールドの値に依存させるための選択された期間を示す値を格納するバースト期間フィールドを含むことを特徴とする請求項3に記載の方法。前記バーストデータレートフィールド及び前記バースト期間フィールドの一方もしくは両方の値が、前記ルーターの現在の動作状態に基づいて調整されることを特徴とする請求項4に記載の方法。前記入来データキューにおいてデータバーストが受信されているかどうかを検出する工程と、受信したデータバーストの検出に応じて、前記パケットフローレートを一時的に増加する工程とを更に備えることを特徴とする請求項1に記載の方法。前記入来データキューが、持続的データレートフィールドを含むデータキューヘッド構造を有し、データのバーストが受信されたかどうかの判定が、持続的データレートフィールドの値を選択された非バーストパケットフローレートに設定する工程と、前記入来データキューの現在のパケットフローレートを計算する工程と、前記計算したパケットフローレートと前記持続的データレートフィールドの値とを比較する工程とによって実行されることを特徴とする請求項6に記載の方法。データキューヘッド構造が更に、タイムスタンプフィールドと、処理バイトフィールドを含み、前記前記入来データキューの現在のパケットフローレートが、前記タイムスタンプフィールドの値を、現在のパケットフローレートの計算が最後に行われた時間に設定し、パケットフローレートの最後の計算以降に処理されたデータのバイト数を反映するように前記処理バイトフィールドの値を設定し、前記タイムスタンプフィールドと前記処理バイトフィールドの値のそれぞれに基づいて、前記入来データキューのパケットフローレートを計算することにより計算されることを特徴とする請求項7に記載の方法。前記ルーターがメモリを備え、前記入来データキューが、受信したデータパケットを格納するために前記メモリのうち所定量を割り当てられており、前記メモリの現在の稼働率に基づいて、前記入来データキューにデータパケットを格納するために割り当てられるメモリの量を調整する工程をさらに備えることを特徴とする請求項1に記載の方法。前記ルーターが共同して共通制御機能を実行する1以上のプロセッサを有し、前記1以上のプロセッサがプロセッサ稼働率を有し、前記入来データキューの前記パケットフローレートは、現在の前記プロセッサ稼働率に応じて調整されることを特徴とする請求項1に記載の方法。前記ルーターはメモリを有し、前記入来データキューの前記パケットフローレートは、メモリの現在の稼働率に応じて調整されることを特徴とする請求項1に記載の方法。複数の仮想ルーターインスタンスを有し、前記各仮想ルーターインスタンスが受信データを1以上のキューに格納するルーターにおけるデータの処理を制御する方法であって、いずれかのキューに格納されているパケットは、前記ルーターによって前記各キューと関連するデータ処理レートにおいて処理される場合に、前記方法は、第1の仮想ルーターインスタンスに関連する1以上のキューの前記データ処理レートを、前記ルーターにおける現在の動作状態に基づいて調整する工程を備えることを特徴とする方法。第2の仮想ルーターインスタンスに関連する1以上のキューの前記データ処理レートを、前記ルーターにおける現在の動作状態に基づいて調整する工程を更に備えることを特徴とする請求項12に記載の方法。前記第1の仮想ルーターインスタンスに関連する前記1以上のキューのデータ処理レートが、前記第2の仮想ルーターインスタンスに関連する前記1以上のキューのデータ処理レートとは独立して調整されることを特徴とする請求項13に記載の方法。前記ルーターの同一の現動作状態に応じて、前記第1の仮想ルーターインスタンスと関連する前記1以上のキューのデータ処理レートは減少され、第2の仮想ルーターインスタンスと関連する前記1以上のキューのデータ処理レートは増加されることを特徴とする請求項13に記載の方法。メモリと複数の仮想ルーターインスタンスを有し、前記各仮想ルーターインスタンスは受信データパケットを1以上の各入来データキューに格納するパケットデータルーターにおいて、メモリの稼働率を制御する方法であって、いずれかの入来データキューに格納されているパケットは、前記ルーターによって前記1以上の各入来データキューと関連するパケットフローレートにおいて処理される場合に、前記方法は、第1の仮想ルーターインスタンスに関連する1以上の入来データキューの前記パケットフローレートを、前記ルーターにおける現在の動作状態に基づいて周期的に調整する工程を備えることを特徴とする方法。第2の仮想ルーターインスタンスに関連する1以上の入来データキューの前記パケットフローレートを、前記ルーターにおける現在の動作状態に基づいて周期的に調整する工程を更に備えることを特徴とする請求項16に記載の方法。前記第1の仮想ルーターインスタンスに関連する前記1以上の入来データキューのパケットフローレートが、前記第2の仮想ルーターインスタンスに関連する前記1以上の入来データキューのパケットフローレートとは独立して調整されることを特徴とする請求項17に記載の方法。複数のルーターと複数の仮想ルーターインスタンスを備えるシステムにおけるデータの処理を制御する方法であって、少なくとも第1の仮想ルーターインスタンスが第1のルーター及び第2のルーターの両方に現れ、各仮想ルーターインスタンスは、受信データを、前記仮想ルーターインスタンスが現れる各ルータ内の1以上の各データキューに格納し、どのデータキューに格納されるデータも、前記各ルーターによって前記各データキューに関連するデータ処理レートにおいて処理される場合に、前記方法は、前記第1のルーターの現在の動作状態に基づいて、前記第1及び第2のルーターのそれぞれにおける前記第1の仮想ルーターインスタンスに関連する1以上のデータキューのデータ処理レートを調整する工程を備えることを特徴とする方法。前記第1のルーター上に位置する前記各1以上のデータキューの前記データ処理レートは、前記第2のルーター上に位置する前記各1以上のデータキューの前記データ処理レートとは独立して調整されることを特徴とする請求項19に記載の方法。前記第1及び第2のルーターの両方に現れる第2の仮想ルーターインスタンスが更に、前記第1のルーターの現在の動作状態に基づいて、前記第1及び第2のルーターのそれぞれにおける前記第2の仮想ルーターインスタンスに関連する1以上のデータキューのデータ処理レートを調整する工程を備えることを特徴とする請求項19に記載の方法。前記第1仮想ルーターインスタンスに関連する前記データキューの前記データ処理レートは、前記第2仮想ルーターインスタンスに関連する前記データキューの前記データ処理レートとは独立して調整されることを特徴とする請求項21に記載の方法。前記第1のルーターの現在の動作状態に応じて、前記第1のルーター上に位置する前記第1の仮想ルーターインスタンスに関連する前記1以上のデータキューのデータ処理レートが減少され、前記第2のルーター上に位置する前記第1の仮想ルーターインスタンスに関連する前記1以上のデータキューのデータ処理レートが増加され、前記第1のルーター上に位置する前記第2の仮想ルーターインスタンスに関連する前記1以上のデータキューのデータ処理レートが増加され、前記第2のルーター上に位置する前記第2の仮想ルーターインスタンスに関連する前記1以上のデータキューのデータ処理レートが減少されることを特徴とする請求項21に記載の方法。図1は、インターネットサービスプロバイダーISP22によってインターネットゲートウェイとして利用される好適なパケットデータルーター20を示す。ルーター20は、アップストリームデータパケットを、複数の異なるエンドユーザー24から受信する。各受信データパケットに含まれるルーティング情報に基づいて、ルーター20は、1パケットを各インターネットサーバー38に転送、2ルーター20に接続されたエンドユーザー24に転送、又は3不知の目的地アドレスを有するか又は、配信不可能であることを理由にパケットをドロップする処理のうち、いずれかを実行する。ルーター20はまた、ダウンストリームデータパケットをインターネットサーバー38から受信し、可能で有れば、受信したダウンストリームパケットを各エンドユーザー24に転送する。エンドユーザー24は、例えば、ダイヤルアップモデム接続28やISDN回線30を介した従来の公衆交換電話網PSTNを通じてルーター20に接続されている。各エンドユーザーネットワーク32A及び32Bは、それぞれ実質的な数のエンドユーザー24を備え、ルーター20に、PSTN26の一部として提供されるそれぞれの専用線T1回線34A及び34Bを介して接続されている。PSTN26からは、各通信リンクが複数の専用回線36を介して、ISP22のルーター20へ接続されている。他の通信リンクもまた利用可能であり、例えば、不図示の無線モデムリンクや、不図示のケーブルテレビジョンネットワークにより提供される同軸ケーブルモデム接続のようなものがある。図2を参照すると、ルーター20は、共同で単一制御機能を実行するための1以上のプロセッサを含むが、図2ではこれらを単純化のためにまとめて示し、単一中央処理ユニットCPU44と呼ぶ。ルーター20はまた、共有されるバッファメモリ46を含む。これは、好ましくはダイナミックランダムアクセスメモリDRAMで実装される。ルーター20では、PSTN26からの通信回線36は、通信インタフェース40で終端される。この通信インタフェース40は、ソフトウェアを実装可能な複数のデジタル信号処理器DSP42を備える。DSP42によって処理例えば復調されるアップストリームパケットは、まずメモリ46においてリンクされたリストとして形成される入来データキュー48において保持される。当業者が理解するように、入来データキュー48は、FIFO形式での処理のための格納パケットを保持するソフトウェアデータ構造を有する。ルーター20に実装される入来データキュー48は、深度即ち、各キューが保持可能な各パケットの最大数の概念を有している。入来データキュー48のメモリ46における特定の構造は、ここで示す発明の概念から離れることなく変更されても良い。特に、図2に示す実施形態では、各エンドユーザー24、ネットワークで接続されたエンドユーザーグループ32A/32BもしくはVRI50/52は、ルーター20から受信したパケットを格納するために1以上の専用入来データキュー48を有していても良い。例えば、第1のエンドユーザーグループ32Aから受信したデータパケット及び、グループ32Aから受信した単なるパケットは、第1の専用の複数の入来データキュー48Aに格納される。同様に、第2のエンドユーザーグループ32Bから受信したデータパケット及び、グループ32Bから受信した単なるパケットは、第2の専用の複数の入来データキュー48Bに格納される。また、2以上のエンドユーザー24は1以上の入来データキュー48を、多くの可能構成において共有しても良い。図2に示す実施形態では、入来データキュー48Aはルーター20内に、第1のVRI50として実装され、入来データキュー48Bは第2のVRI52として実装され、各VRI50及び52は、固有のルーティングドメインを有する。特に、VRI50又はVRI52のパケット処理もしくはフローレートは、対応する各入来データキュー48A及び48Bのフローレートである。さらなるVRIをルーター20内に実装しても良いが、本発明の概念を説明に当たり簡単のために第1及び第2のVRI50及び52のみを示す。重要なのは、ルーター20内の各VRIが、1以上の管理可能な入来データキュー48に割り当てられていることである。別の好適な実施形態では、管理可能なキューは、VRIプロトコルレイヤーの間に位置しても良い。ここでは、入来地点とは違って、パケットドロップ及び遅延パラメータは既知である。CPU44は選択的に、FIFO形式で入来データキュー48からパケットを検索し、それらを各出力目標と関連づけられた不図示の出力キューへ転送するか、さもなくば、送信不可能なパケットをドロップする。各入来データキュー48からのパケットは、CPU44において所定のパケットフローレートで処理される。このレートは、所定の処理インターバル間においてCPU44によって処理される各入来データキュー48からのパケット数で定義される。各入来データキュー48からのパケットのパケットフローレートは異なっても良いし、より詳細に記載するように、フロー管理処理、又はルーター20のRTOSの一部であるフローマネージャ53によって制御されてもよい。もし、CPU44により所定の入来データキュー48に保持されているパケットを直ちに処理することが困難な場合、キューの長さはそれに応じて増加することは明らかである。もちろん、メモリ46がパケットを格納するための容量は有限であり、各入来データキュー48が割り当てられるのは、メモリ46のバッファスペースの所定量に限られる。各入来データキュー48に格納されたパケット数は、メモリ管理処理又は、ルーター20のRTOSの一部であるメモリマネージャ53により監視される。特に、格納されたパケットの長さは変化する。一般的に、DRAMのような共有されるバッファメモリは、それらが比較的安価であり、コンパクトな形状ながら高い格納容量を有するので、パケットデータルーターにおける利用によく適している。しかしながら、メモリ46へのリード、ライトそれぞれのアクセスには比較的時間を有する。というのも、CPU44とメモリ46の間のデータバスの帯域幅の制限や、DRAMが本来有する行アドレスのストローブのレイテンシが有るためである。言い換えれば、CPU44が各データパケットをメモリ46へ格納ライト又はメモリ46から検索retreiveリードするために消費する相対的時間及びプロセッサリソースである。図3を参照すると、フローマネージャ54の機能は、入来データキュー48のデータフローを管理制御することである。本好適な実施形態では、フローマネージャ54はシステムタスクとして実装される。これは、例えば、毎秒1回等、所定のインターバルにおいて入来データキュー48のそれぞれについて反復される。フローマネージャ54は、各入来データキュー48に保持されているデータパケットの処理を監視して、ルーター20の全体のデータフローと、特に、CPU44及びメモリ46の稼働率を管理する。この目的のために、フローマネージャ54は、メモリ46に格納されているデータキューヘッド構造を、各入来データキュー48へのヘッダーとして維持する。データキューヘッド構造55は、フローマネージャ54によって、パケットフローレートを制御し、各入来データキュー48に割り当てられるメモリの量を制御するために利用されるいくつかのデータフィールドを含む。好適な実施形態においては、データキューヘッド構造55におけるデータフィールドは、以下のものが含まれる。1処理すべきパケットpacketstobeprocessedフィールド56は、CPU44によって所定の処理インターバルにて処理される、各データキュー48に保持されているパケット数を示す値を有する。2キューカウントフィールド58は、現在、各入来データキュー48に保持されているパケット数を示す値を有する。3処理バイトフィールド60、所定の処理インターバルにおいて処理された各データキュー48からのデータバイト数を表す値を有する。4持続的データレートsustaineddatarateフィールド62は、例えば、ISP22による顧客サービス契約costomerserveiceagreementに基づいた、データキュー48それぞれについての、ターゲット最大データ処理レートをbpsで示す値を有する。5バーストデータレートburstdatarateフィールド64は、データバーストの受信に基づいて一時的に実施された、各データキュー48についての増加した最大データ処理レートをbpsで示す値を有する。6バースト期間burstdurationフィールド66は、バーストデータレートフィールド64において規定されるデータレートが、データバーストを受信に応じて維持される最大時間を秒又は他の単位で表す値を有する。7キュー深度queuedepthフィールド68は、各データキュー48に一度に保持可能なパケットの最大数を示すものである。即ち、パケット数が最大に達した場合は、現在格納されているパケットが処理され、他を格納するための余地ができない限りは、新たに受信したパケットがドロップされてしまう。8バーストスタートburststartフィールド70は、各データキュー48でデータバーストの受信を検知した時を示す時間スタンプ値を保持するためのものである。9システムタイムスタンプsystemtimestampフィールド72は、データキューヘッド構造55のポールが最後に実行された時を示すタイムスタンプ値を保持するためのものである。当業者には理解されるように、データフィールド1から9の実際の順番は、特別に重要なものではなく、ここに開示する本発明の概念から逸脱することなく多くの変更が可能である。本発明の一般的な側面によれば、フローマネージャ54及びメモリマネージャ53は、継続的に現在のルーター20の動作状況、例えば、プロセッサやメモリの稼働状況を監視する。各データキューヘッド構造55のデータフィールド1から9は、いくつかのタスクを実行するためにフローマネージャ54とメモリマネージャ53によって利用される。当該タスクには、フローレートの監視及び調整、バーストデータレートの監視、各入来データキュー48についてのメモリ割当て及び稼働率の調整が含まれる。フローマネージャ54はまた、例えば、周期的なタスクとして、各入来データキュー48の各フローレートを監視し、もし適切で有れば、エンドユーザーのサービス品質QOSへの影響が最小で済むようにシステム全体の安定性を確保するために、1以上の入来データキュー48のパケットフローレートの対応する調整を行う。特に、ルーター20のシステム安定性、及び、より重要な、ルーター20によってサービスされる、各ユーザー24、ユーザーグループ32A/32B及び/又はVRI50/52のQOSは、各パケットフローレート及び個々の入来データキュー48に対する比例的なメモリ割当ての制御を通して最良に管理されてもよい。例えば、本発明の一般的な側面によれば、もしプロセッサ稼働率が、所望の動作範囲の上限に到達するか、又は、これを越えた場合、フローマネージャ54は、1以上の入来データキュー48のパケットフローレートを、対応する処理すべきパケットフィールド56の値を減ずることにより減少させるであろう。逆に、もしプロセッサ稼働率が、所望の動作範囲の下限に到達するか、又はこれを下回った場合は、対応する処理すべきパケットフィールド56の値を増やすことにより、1以上の入来データキュー48のパケットフローレートを増加させてもよい。入来データキューレベルにおいてデータパケット処理を制御することの利点は、個々のエンドユーザー24、ユーザーグループ32A/32B、もしくはVRI50/52が反比例的に影響を受けることなく、ルーター20のシステムリソースが公平に分配され、制限されることである。一方、ルーターの従来のRTOSは、同一QOSを有するが、異なる入来データキュー上でルーターにアクセスしているエンドユーザー間では差別化できなかった。説明のために、VRI50及びVRI52が同一のQOSプロフィールを有するが、ある場合において、VRI50は唯一のアクティブなエンドユーザー24をそのネットワーク上に有する一方で、VRI52が19のアクティブなエンドユーザー24を有すると仮定する。従来のルーターROTSシステムは、リソースを異なるユーザー内で均等に割り当てる及び制限する。即ち、各エンドユーザー24に対しトータル帯域幅の5が割り当てられる。実際は、VRI50の唯一のエンドユーザー24は、利用可能なルーター帯域幅の半分50が割り当てられ、VRI52の19のエンドユーザー24が残りの半分を彼らでシェアするはずであるにもかかわらずである。個々の入来データキューのフローレートを制御可能とすることにより、本発明は従来の技術におけるこの問題点を解消するものである。また、個々のユーザー又はVRIの帯域幅保証即ち、入来データキューレベルにおけるものが本発明により可能となる。さらに、入来データキュー48のデータ処理速度を制御することにより、ISP22はサブレート帯域幅レートsubratebandwidthratesを高速モデム上で実行してもよい。例えば、QOSプロフィールが28.8Kでしかないエンドユーザーについて56.8Kモデム接続を可能とする。より重要なことに、入来データキュー48についての独立した制御により、ピークトラヒック負荷を扱う場合において、より予測がたてやすくなる。本発明のこの側面に応じて、フローマネージャ54は好ましくは、入来データキュー48の各フローレートを互いに独立に調整する。ISP22において維持されるQOSプロフィール74のそれぞれに基づいて、フローマネージャ54は、どのエンドユーザー24、ユーザーグループ32A又は32B及び/又はVRI50又は52のQOS基準についても不利な影響を最小とする入来データキュー48のフローレートを調整する。各顧客QOSプロフィールのある側面は、各入来データキュー48のデータキューヘッド構造55において維持される。例えば、持続的データレートフィールド62は、各入来データキュー48についてのターゲット最大データ処理レートを示す。これにより、各データキュー48についての処理すべきパケットフィールド56の値が計算される。好適な実施形態では、入来データキュー48についての持続的データレートフィールド62は、まず、各データキュー48と関連したエンドユーザー24、ユーザーグループ32A/32B、もしくはVRI50/52の最大の割当レートmaximumallotedrateに基づいて決定される。その後、各入来データキュー48についての持続的データレート62は、現在のルーター20の動作状態に動的に基づく。例えば、VRI50及び/又はVRI52と関連した1以上のデータキュー48Aのパケットフローレートは、ルーター20のプロセッサ稼働率を所定の動作範囲内に維持するように周期的に調整されても良い。フローマネージャ54はまた、各入来データキュー48において受信されてもよいデータバーストを管理する。QOSユーザープロフィール74は、突発的なバーストパケットトラヒックに順応するために、短い期間においてパケット処理帯域幅の付加的量が与えられるように、好ましくはエンドユーザー24に提供される。例えば、エンドユーザー24は、大きなファイルを月に一度送信する必要があっても良い。費用がかかる持続的なデータレート帯域幅のために支払いさせる代わりに、ISP22はエンドユーザー24に付加的なバーストデータレートを特定の時間例えばバースト期間において提供することができる。好適な実施形態では、各入来データキュー48についてのバーストデータレート64は、まず、ISP22によって各入来データキュー48に関連するどのエンドユーザー24に対しても保証される、最大バーストデータレートの最も高いものhighestmaximumburstdatarateに基づいて決定される。同様に、各入来データキュー48についてのバースト期間フィールド66は、まず、ISP22によって各入来データキュー48に関連するどのエンドユーザー24に対しても保証される、最高の最大バースト期間に基づいて決定される。その後、バーストデータレート64及びバースト期間66は、現在のルーター20の動作状態に基づいて、各入来データキュー48について動的に調整される。とりわけ、フローマネージャ54は、異なる持続的データレート62、バーストデータレート64、及びバースト期間66の値を、1以上の入来データキュー48について、例えば、日中における変動timeofdayvariancesのような、オフピーク稼働基準offpeakusagecriteriaに基づいて割り当てても良いが、どの入来データキュー48のフローレートについても、システムの完全性を保持するための絶対的に必要とならない限り、好ましくは、ISP22によって例えば、当該ユーザーのQOSプロフィールに基づいてどのエンドユーザー24にも保証されている最大の最小限レートよりも低くは減少させないであろう。図4は、フローマネージャ54が、データバーストが各入来データキュー48において受信されているかどうかを検出するための、ある好適な処理を示す。フローマネージャ54は、周期的に各入来データキュー48をポーリングし、現在のデータフローレート78bpsにてを計算するステップ78。好適な実施形態では、フローマネージャ54は、各入来データキュー48についてのデータヘッドキュー構造55の処理バイトフィールド60の値に8を乗ずることによって現在のフローレートを計算する。結果物は、現在の時間とシステムタイムスタンプフィールド72の値との差分によって割られる。フローマネージャ54は、ステップ80において計算した現在のパケットフローレートと、持続的データレート62における値を比較する。もし、計算されたレートが持続的データレートよりも大きい場合は、フローマネージャ54はデータバーストが各入来データキュー48において発生したとみなす。フローマネージャ54は、ステップ82において処理すべきパケットフィールド56の値を、バーストデータレートフィールド64の値に基づいて再計算し、バーストスタートフィールド70に現在の時間のタイムスタンプをセットする。もし受信バーストが検出されない場合は、即ち、計算されたデータレートが持続的データレートフィールド62と等しいか、より小さい場合は、フローマネージャ54は、ステップ85において、システムタイムスタンプフィールド72を更新し、処理バイトフィールド60の値を、次のポーリングサイクルのためにリセットする。もしデータバーストが入来データキュー48において検出されると、フローマネージャ54は、ステップ84において周期的にデータバーストの期間を、現在の時間とバーストスタートフィールド70のタイムスタンプとの差分を算出することにより計算する。フローマネージャは、ステップ86において計算されたバースト期間と、バースト期間フィールド66の値とを比較する。現在のデータバースト期間が、バースト期間フィールド66の値よりも小さい場合は、フローマネージャはステップ88において、処理すべきパケットフィールド56の値を、バーストデータレートフィールド64の値に基づいて保持する。もし、バースト期間が、バースト期間フィールド66の値よりも長く継続した場合は、フローマネージャ54は処理すべきパケットフィールド56の値を持続的データレートフィールド62の値に基づいて再計算する。好適な実施形態では、バーストデータレートフィールド64の値及びバースト期間フィールド66の値は、フローマネージャ54によって、ルーターにおける現在の動作状態に基づいて調整されても良い。例えば、顧客サービスに役立つものとして、ISP22は、フローマネージャ54を、バーストデータレートフィールド64とバースト期間フィールドの値を、ルーター20のプロセッサ稼働率が規定された動作範囲以下である限り増加するように構成しても良い。図3に戻って、メモリマネージャ53は、各入来データキュー48についての各キューカウント及びキュー深度フィールド58及び68を、メモリ管理処理の一環として監視する。もし、ルータメモリ46の全体の稼働率が、所望の範囲の上限に到達したか、又はこれを越えた場合、メモリマネージャ53は、1以上の入来データキュー48に割り当てられているメモリ量を、対応するキュー深度フィールド68の値を減ずることにより減少させるであろう。逆に、もしメモリ46の稼働率が、所望の範囲の下限に到達したか、又はこれを下回った場合は、メモリマネージャ53は、1以上の入来データキュー48に割り当てられているメモリ量を、対応するキュー深度フィールド68の値を増加することにより増やすであろう。好適な実施形態においては、メモリマネージャ53は、入来データキュー48のキュー深度フィールド68を、受信データバーストの検出に応じて増加する。そうすることにおいて、1以上の他の入来データキュー48のキュー深度フィールド68を、メモリ稼働率を維持するために同時に減少することが必要となるかもしれない。パケットフローレートと同様に、各入来データキュー48にパケットを格納するために割り当てられるメモリの量は、好ましくは、全ての他のキュー48について割り当てられるメモリとは独立して決定される。好適な実施形態においては、キュー深度フィールド68はまず、各データキュー48に関連する全てのエンドユーザー24、ユーザーグループ32A/32B、及び/又はVRI50/52に対して割り当てられたメモリの全体的な最大量に基づいて決定される。その後、各入来データキュー48にについてのキュー深度フィールド68は、ルーター20の現在の動作状態に動的に基づく。例えば、VRI50及び/又はVRI52に関連する1以上のデータキュー48Aのキュー深度フィールド68は、所定の範囲内にメモリの稼働率が維持されるように、周期的に調整されても良い。メモリマネージャ53は、例えばISP22において維持されるQOSプロフィール74のそれぞれに基づいて、どのエンドユーザー24、ユーザーグループ32A又は32B及び/又はVRI50又は52のQOS基準についても不利な影響を最小とする入来データキュー48のキュー深度フィールド68を調整するであろう。好ましくは、メモリマネージャ53は、各データキュー48に関連するエンドユーザー24、ユーザーグループ32A又は32B及び/又はVRI50又は52の全体について、ISP22によって保証される最小レートのうち最高のものを下回るまでには、どの入来データキュー48についてもキュー深度フィールド68を減少させない。各メモリマネージャ53とフローマネージャ54を構成するオペレーティングプロセスは、好ましくは、ルーター20のために管理ツールを改善するためにリンクされる。例えば、プロセッサリソースが利用可能であれば、フローマネージャ54は1以上の入来データキュー48のパケットフローレートを減少させるであろう。即ち、格納されたパケットのバックロードの処理レートを上げて、メモリの稼働率を下げる。実際、もし可能で有れば、QOSの観点から一時的に、最高のキューカウントフィールド58を有する入来データキュー48のパケットフローレートを増加させることは、キュー深度フィールド68を減少させることよりも、パケットのドロップを避ける、又は最小限にするためには好ましい。図5は、ISP100によってインターネットゲートウェイとして利用される代替的な好適なパケットデータルーターシステム110を示す。ルーターシステム110は、複数のルーター112,114,116及び118を含み、それぞれは、データパケットを複数の異なるエンドユーザーネットワーク124から、PSTN26を介して受信し、処理する。各受信データパケットに含まれるルーティング情報に基づいて、ルーターシステム110は、パケットを各インターネットサーバー38に転送、エンドユーザーネットワーク124にパケットを転送、又は、不知の目的地アドレスを有するか又は、配信不可能であることを理由にパケットをドロップする処理のうち、いずれかを実行する。ルーターシステム110はまた、ダウンストリームデータパケットをインターネットサーバー38から受信し、可能で有れば、受信したダウンストリームパケットを各エンドユーザーネットワーク124に転送する。エンドユーザーネットワーク124は、少なくとも3つの別個の顧客アカウント124A、124B及び124Cを含む。ルーターシステム110は、個人及びネットワークの両方を含む、膨大な数の他のエンドユーザー及び顧客アカウントを有してもよい。しかしながら、本発明の更なる側面を説明において簡単のために、ネットワーク124A、124B及び124Cのみを示す。図6を参照すると、ルーターシステム110の各ルーター112、114、116及び118は、実質的にルーター20と同一に構成されている。各ルーター112、114、116及び118は、共同して単一制御機能を実行する1以上のプロセッサを有するが、ここではこれらを単純化のためにまとめて示し、単一中央処理ユニットCPU144とする。ルーター112、114、116及び118はまた、共有されるバッファメモリ146を含む。これは、好ましくはDRAMで実現される。図示された好適な実施形態においては、PSTN26からの通信回線36は、通信インタフェース140で終端される。この通信インタフェース140は、ソフトウェアを実装可能な複数のDSP142を備える。別の実施形態では、1以上の個々のルーター112、114、116及び118は入来したパケットトラヒックをシフトすることを可能とする他の各ルータへの少なくとも1のインタフェース接続と共に、それぞれが独自に通信インタフェースを有している。DSP142によって処理例えば復調されるアップストリームパケットは、まず各ルーター112、114、116及び118のメモリ146においてリンクされたリストとして形成される各入来データキュー48において保持される。ルーター20における入来データキュー48について上述したように、ルーターシステム110の各ルーター112、114、116及び118の入来データキュー148は、FIFO形式での処理のための格納パケットを保持するソフトウェアデータ構造を有する。各キュー148は、深度即ち、各キューが保持可能な格納パケットの最大数の概念を有している。ここで詳細に記載されるように、ルータシステム110はシステムQOSコントローラ120を含んでいる。これは、各ルーター112、114、116及び118の動作状態を監視し、どのようにアップストリームパケットデータトラヒックを様々な入来データキュー148に分配するかを動的に制御するものである。図7を参照すると、各ルーター112、114、116及び118における1以上の入来データキュー148Aが、顧客AVRI-Aのための第1のVRIとして実装されており、ルーター112及び116における1以上の入来データキュー148Bが、顧客BVRI-Bのための第2のVRIとして実装されている。また、ルーター114及び118における1以上の入来データキュー148Cが、顧客CVRI-Cのための第3のVRIとして実装されている。各VRIは、それが現れる各ルーター内に固有のルーティングドメインを有する。各ルーター112、114、116及び118は1以上のさらなるVRIを有しても良いが、VRI-A、VRI-B及びVRI-Cのみを簡単のために示す。システム110の各ルーター112、114、116及び118は、QOSマネージャ152、フローマネージャ154及びメモリマネージャ156を含み、これらは全て各ルータのROTSの一部である。QOSマネージャ152は、各ルーター112、114、116及び118の各フロー及びメモリマネージャ154及び156と、システムQOSコントローラ120との間の制御インタフェースである。ルーター20のフロー及びメモリマネージャ54及び53と同様に、各ルーター112、114、116及び118の各メモリ及びフローマネージャ154及び156は、各ルーターの入来データキュー148のデータフローを管理し制御する。本好適な実施形態のいて、フロー及びメモリーマネージャ154及び156は、システムタスクとして実装される。これは、例えば、毎秒1回等、所定のインターバルにおいて、各ルーター112、114、116及び118の各入来データキュー148のそれぞれについて反復される。特に、フロー及びメモリーマネージャ154及び156は、各入来データキュー148に保持されているデータパケットの処理を監視して、ルーターの全体のデータフローと、特に、CPU44及びメモリ46の稼働率を管理する。フロー及びメモリーマネージャ154及び156のそれぞれは、各ルーター112、114、116及び118の各入来データキュー148について、ルーター20のデータキューヘッド構造55における各フィールドと同一のものを含むデータキューヘッド構造を監視及び維持する。このように、ルーター20と同様に、ルーターシステム110の各ルーター112、114、116及び118は、個々にパケットフローレートを制御し、各入来データキュー148に割り当てられたメモリを制御する能力がある。さらに、システムQOSコントローラ120は、ルーターQOSマネージャ152と結合して、ルーターの動作状態に応じて、各ルーター112、114、116及び118の各入来データキュー148間で入来パケットトラヒックをシフトする能力がある。例えば、本発明のさらなる側面によれば、各ルーター112、114、116及び118上のVRI-Aと関連する1以上の入来データキュー148のデータ処理レートがルーター112の現在の動作状態に基づいて調整される。好ましくは、各ルーター112、114、116及び118上のVRI-Aと関連する1以上の入来データキュー148のデータ処理レートは、他のルーター上のVRI-Aと関連する1以上の入来データキュー148の処理レートとは独立して調整される。個々のデータキューのフローレートの調整に加えて、システムQOSコントローラ120は、VRIのどれか1つと関連する入来データキュー148間において、システム負荷をよりよくバランスさせるために、入来パケットトラヒックを再割当てしても良い。本発明の好適な実施形態及びアプリケーションが示され、記載された一方で、当業者には理解されるように、多くの修正及び応用は、本発明の概念から逸脱することなく可能である。このように、開示された発明の範囲は、特許請求の範囲に対応することなく限定されるものではない。"