(57)【特許請求の範囲】
【請求項１】
複数のデータパケットフローをサービスするスケジューリング装置において、
前記データパケットフローのそれぞれは、指定されたサービス要求を有し、それぞれ複数のキューのうちの１つが対応し、該複数のキューのそれぞれはデータパケットを含み、前記データパケットフローへのサービスの分配はサービスフレームに分けて編成され、各サービスフレームは前記データパケットフローのそれぞれに複数のサービス機会を提供し、前記サービス機会の数が前記データパケットフローのサービス要求に依存し、１つのサービスフレームによって提供されるサービス機会の総数によって該サービスフレームの期間を表すことができ、
前記スケジューリング装置が、
サービスフレームの第１サブフレームの期間中にサービスを第１の帯域保証型（ＧＢ）データパケットフローのセットに提供する第１スケジューラであって、前記ＧＢデータパケットフローは帯域要求で表現されるサービス要求を有し、該第１サブフレームの期間が前記ＧＢデータパケットフローの帯域要求を満たすように調整されている、第１スケジューラ、及び
サービスフレームの第２サブフレームの期間中にサービスを第２のベストエフォート型（ＢＥ）データパケットフローのセットに提供する第２スケジューラであって、前記ＢＥデータパケットフローが、保証帯域要求で表現されないサービス要求を有し、第２サブフレームの期間はサービスフレームの期間から同じサービスフレーム内の第１サブフレームの期間を差し引いたものである、第２スケジューラ
からなり、
第２サブフレームの終了は、（１）サービスフレームの所定期間が満了するか、または、（２）前記第２のＢＥフローのセットに残っているバックログがなくなるかのいずれかのときに、いずれの条件が最初に生じるかにかかわらず決定され、バックログは、考えているデータパケットフローのセットに対応する１個または複数のキュー内の１個または複数のデータパケットの存在として定義されることを特徴とするスケジューリング装置。
【請求項２】
複数のデータパケットフローをサービスするスケジューリング装置において、
前記データパケットフローのそれぞれは、指定されたサービス要求を有し、それぞれ複数のキューのうちの１つが対応し、該複数のキューのそれぞれはデータパケットを含み、前記データパケットフローへのサービスの分配はサービスフレームに分けて編成され、各サービスフレームは前記データパケットフローのそれぞれに複数のサービス機会を提供し、前記サービス機会の数が前記データパケットフローのサービス要求に依存し、１つのサービスフレームによって提供されるサービス機会の総数によって該サービスフレームの期間を表すことができ、
前記スケジューリング装置が、
サービスフレームの第１サブフレームの期間中にサービスを第１の帯域保証型（ＧＢ）データパケットフローのセットに提供する第１スケジューラであって、前記ＧＢデータパケットフローは帯域要求で表現されるサービス要求を有し、該第１サブフレームの期間が前記ＧＢデータパケットフローの帯域要求を満たすように調整されている、第１スケジューラ、及び
サービスフレームの第２サブフレームの期間中にサービスを第２のベストエフォート型（ＢＥ）データパケットフローのセットに提供する第２スケジューラであって、前記ＢＥデータパケットフローが、保証帯域要求で表現されないサービス要求を有し、第２サブフレームの期間はサービスフレームの期間から同じサービスフレーム内の第１サブフレームの期間を差し引いたものである、第２スケジューラ
からなり、
前記第１スケジューラは、前記第２サブフレームの期間を規制するために、ＢＥデータパケットフローの集合に対するタイムスタンプＦＢＥを管理することを特徴とするスケジューリング装置。
【請求項３】
複数のデータパケットフローをサービスするスケジューリング装置において、
前記データパケットフローのそれぞれは、指定されたサービス要求を有し、それぞれ複数のキューのうちの１つが対応し、該複数のキューのそれぞれはデータパケットを含み、前記データパケットフローへのサービスの分配はサービスフレームに分けて編成され、各サービスフレームは前記データパケットフローのそれぞれに複数のサービス機会を提供し、前記サービス機会の数が前記データパケットフローのサービス要求に依存し、１つのサービスフレームによって提供されるサービス機会の総数によって該サービスフレームの期間を表すことができ、
前記スケジューリング装置が、
サービスフレームの第１サブフレームの期間中にサービスを第１の帯域保証型（ＧＢ）データパケットフローのセットに提供する第１スケジューラであって、前記ＧＢデータパケットフローは帯域要求で表現されるサービス要求を有し、該第１サブフレームの期間が前記ＧＢデータパケットフローの帯域要求を満たすように調整されている、第１スケジューラ、及び
サービスフレームの第２サブフレームの期間中にサービスを第２のベストエフォート型（ＢＥ）データパケットフローのセットに提供する第２スケジューラであって、前記ＢＥデータパケットフローが、保証帯域要求で表現されないサービス要求を有し、第２サブフレームの期間はサービスフレームの期間から同じサービスフレーム内の第１サブフレームの期間を差し引いたものである、第２スケジューラ
からなり、
前記第１のＧＢフローのセット内でバックログとなっているデータパケットフローは、サービスのために、一次ＷＲＲスケジューラ（ＰＷＳ）先入れ先出し（ＦＩＦＯ）キューに格納され、
前記第１のＧＢフローのセットの各データパケットフローは対応するフレームフラグを有し、
前記第１サブフレームは、前記ＰＷＳ ＦＩＦＯキューの先頭にあるＧＢフローのフレームフラグがグローバルフレームカウンタＧＦＣとは異なる値を有するときに終了し、
前記フレームフラグ及びＧＦＣがそれぞれ１ビットフラグであり、
前記ＧＦＣの値と前記ＰＷＳ ＦＩＦＯキューの先頭にある前記ＧＢフローの前記フレームフラグの値との間の差が検出された後に、前記ＧＦＣの値が前記ＰＷＳ ＦＩＦＯキューの先頭にある前記ＧＢフローの前記フレームフラグの値に等しくセットされることを特徴とするスケジューリング装置。
【請求項４】
前記ＢＥデータパケットフローの集合のタイムスタンプＦＢＥがＰＷＳ基準タイムスタンプ増分ＴＱＰＷＳを超えるたびに、前記第２サブフレームの終了が宣言されることを特徴とする請求項３記載の装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、パケットスケジューラに関し、特に、帯域要求のあるデータソースへのデータ転送レートと、帯域要求のないデータソースへのフェアネス（公平性）とを同時に保証するパケットスケジューリング装置および方法に関する。
【０００２】
【従来の技術】
Integrated Service (Intserv)やDifferentiated Service (Diffserv)のような精緻なサービス品質（ＱｏＳ）フレームワークがますます広まるとともに、フレキシブルな帯域管理の可能なパケットスケジューラが重要視されている。最適遅延性能を実現するパケットスケジューラの実装コストが高いため、また、最悪の場合の遅延性能はＩＰネットワークにおける頑強（ロバスト）な帯域性能にとっては実際にはあまり重要でないため、産業界は、重み付けラウンドロビン（ＷＲＲ：Weighted Round Robin）スケジューラ［後記の［付録］に列挙した文献１，２，３参照］に強い関心を示している。ＷＲＲスケジューラは、複雑さが非常に低く、ロバストな帯域保証およびフェアネスを提供することができるが、ぎりぎりまでの（タイトな）遅延限界を必ずしも達成するものではない。
【０００３】
【発明が解決しようとする課題】
ＷＲＲスケジューラでは、厳格な帯域保証を帯域保証型（ＧＢ：guaranteed-bandwidth）フロー（すなわち、指定された帯域要求のあるフロー）に提供することと、サービスフェアネスをベストエフォート型（ＢＥ：best-effort）フロー（すなわち、指定された帯域要求のないフロー）を提供することが、いずれかの型のフローを単独で処理するとき（すなわち、他方の型のフローがない場合）には可能である。一般に、ＧＢフローとＢＥフローを単一のＷＲＲスケジューラでまとめると、帯域資源を割り当てる際のサーバの効率が低下する。
【０００４】
従来のＷＲＲスケジューラでは、ＢＥフローは、サービスシェアが割り当てられた場合にのみサービスされる。サービスシェアの選択は常に任意であり、本質的に、ＢＥフローへの帯域の分配を特徴づけるべきフレキシビリティをその代わりに低下させる。さらに、ＢＥフローに割り当てられるサービスシェアは、ＧＢフローと共有される帯域プールから差し引かれるが、このことは、スケジューラがサポート可能なＧＢフローの量の低下を意味する。
【０００５】
ＧＢおよびＢＥフローを効率的に統合することが可能な改良されたＷＲＲスケジューラが必要とされている。
【０００６】
【課題を解決するための手段】
本発明によれば、帯域保証型（ＧＢ）およびベストエフォート型（ＢＥ）のフローをフレキシブルに統合するスケジューリング方法および装置が実現される。本発明のパケットスケジューリング装置は、一次ＷＲＲスケジューラ（ＰＷＳ：primary WRR scheduler）と二次ＷＲＲスケジューラ（ＳＷＳ：secondary WRR scheduler）の組合せを有する。ＰＷＳは、サーバのアクティビティをサービスフレームに分割する。各サービスフレーム内で、ＰＷＳは、サービスを個々のＧＢフローに分配し、すべてのバックログ（積滞）ＢＥフローの集合(aggregate)が受けるべきサービスの量を決定する。ＳＷＳは、ＢＥ集合のサービスシェアを個々のＢＥフローにわたり公平（フェア）に分配することを担当する。
【０００７】
パケットスケジューリング装置の動作によりサービスフレームは２個のサブフレームに分割される。第１サブフレームで、ＰＷＳはＧＢフローの帯域要求を充足する。第２サブフレームで、ＳＷＳはフェアサービスをＢＥフローに分配する。各フレームについて、２個のサブフレームの期間は、ＧＢフローに割り当てられる帯域の量と、そのフレームの最初に積滞している（溜まっている）ＧＢフローの数とに依存する。第２サブフレームの期間は、１サービスフレーム内でＢＥフローに利用可能な帯域の量を反映する。それは、ＧＢフローのバックログ状態とともに変化する。すなわち、ＧＢフローのアクティビティが低いときに増大し、ＧＢフローのアクティビティが高くなると減少する。こうして、本発明のスケジューラでは、ＢＥフローのサービスシェアは、ＧＢフローの帯域保証をも支持する同一の有限なプール（これはサーバの容量によって制約される）から差し引かれるのではなく、ＧＢフローにより未使用のまま残されているサーバ容量の部分に動的に適応する別個の無制約のプールから差し引かれる。
【０００８】
具体的には、本発明によれば、サービスフレームに分けてデータパケットフローをサービスするスケジューリング装置が実現される。スケジューリング装置は、（１）サービスフレームの第１サブフレームの期間中に、帯域保証を第１のＧＢフローのセットに提供する第１スケジューラと、（２）サービスフレームの第２サブフレームの期間中に、サービスを第２のＢＥフローのセットに提供する第２スケジューラとを有する。第１サブフレームの期間は、ＧＢフローの帯域要求を満たすように調整される。ＢＥフローは、保証帯域要求で表現されないサービス要求を有し、第２サブフレームの期間は、サービスフレームの期間から、同じサービスフレーム内の第１サブフレームの期間を差し引いたものである。なお、本発明のもう１つの特徴によれば、第２スケジューラは、必ずしも、サービスをそれぞれのＢＥフローに等分配するように設定される必要はない。
【０００９】
また、本発明によれば、サービスフレームに分けてＧＢフローおよびＢＥフローのデータパケットをサービスするためにスケジューラを動作させる方法が実現される。この方法は、（１）サービスフレームの第１サブフレームの期間中に、サービスを第１のＧＢフローのセットに提供するステップと、（２）サービスフレームの第２サブフレームの期間中に、サービスを第２のＢＥフローのセットに提供するステップとを有する。前記ＧＢデータパケットフローは、帯域要求で表現されるサービス要求を有し、第１サブフレームの期間は、前記ＧＢデータパケットフローの帯域要求を満たすように調整される。前記ＢＥデータパケットフローは、保証帯域要求で表現されないサービス要求を有し、第２サブフレームの期間は、サービスフレームの期間から、同じサービスフレーム内の第１サブフレームの期間を差し引いたものである。
【００１０】
【発明の実施の形態】
図１に、複数の通信スイッチ１０１−１〜１０１−ｐが通信リンクにより相互に接続された例示的なパケットネットワークを示す。いくつかのデータソース１０２−１〜１０２−ｑが通信スイッチに接続される。ネットワークコネクションが、それぞれのデータソースから、対応する宛先１０３−１〜１０３−ｇへと確立され、データパケットは、各データソースから対応する宛先へ送信される。
【００１１】
図２は、パケットネットワークの通信スイッチ１０１−１の例示的なブロック図である。図示のように、通信スイッチは、スイッチファブリック２５０と、複数の通信リンクインタフェース２００−１〜２００−ｓを有する。各通信リンクインタフェースは、複数の入力リンクを１つの出力リンクに接続し、データパケットを入力リンクから出力リンクへ転送する。通信スイッチ１０１−１は、このような通信リンクインタフェース２００を１個だけ含むことも、複数含むことも可能である。例えば、入力通信リンクインタフェース２００−１はスイッチファブリック２５０の前に配置され、その場合、入力通信リンクインタフェース２００−１の入力リンク２０１−１〜２０１−ｒは通信スイッチ１０１−１の入力リンクであり、入力通信リンクインタフェース２００−１の出力リンク２０３はスイッチファブリック２５０に接続される。
【００１２】
第２の例として、出力通信リンクインタフェース２００−ｊはスイッチファブリック２５０の出力に配置され、出力通信リンクインタフェース２００−ｊの入力リンクはスイッチファブリック２５０の複数の出力リンク２０４であることが可能であり、出力通信リンクインタフェース２００−ｊの出力リンクは通信スイッチ１０１−１の出力リンク２０２−ｊである。注意すべき点であるが、１つの特定のリンクを通じて、または、複数の相異なるリンクを通じて受信されるパケットは、同じ長さであることもそうでないこともある。例えば、スイッチファブリック２５０が非同期転送モード（ＡＴＭ）スイッチであり、図１のネットワークがＡＴＭネットワークである場合、すべてのパケットは同じ長さを有する。本発明の以下の説明では、１つの特定のリンクを通じて、または、複数の相異なるリンクを通じて受信されるパケットは、長さが必ずしも同じでないと仮定する。
【００１３】
図６に関連して後の段落で説明するように、図２の通信リンクインタフェース２００のそれぞれは一般に、少なくともパケット受信器、スケジューラ、およびパケット送信器を有する。前述のように、スケジューラは、重み付けラウンドロビン（ＷＲＲ）スケジューラ［１，２，３］であることが可能であり、さらにこれは、不足ラウンドロビン（ＤＲＲ：Deficit Round Robin）［２］または余剰ラウンドロビン（ＳＲＲ：Surplus Round Robin）［３］のアルゴリズムに従って実装されることが可能である。
【００１４】
不足ラウンドロビン（ＤＲＲ）アルゴリズムは、その最小限の実装複雑さと、割り当てられるサービスシェアに比例してフローをサービスする際のその効率とにより、可変サイズのパケットに対するＷＲＲスケジューラの最も普及している実例の１つである。ＤＲＲアルゴリズムはまた、サーバのアクティビティをサービスフレームに分割する。ＷＲＲパラダイムに従って、ＤＲＲアルゴリズムは、サービスシェアρｉを各設定フローｉに関連づける。サービスシェアは、すべての設定フローにわたるそれらの和がサーバの容量ｒを超えないときに、最小の保証サービスレートとなる。
【数１】
0004017867.tif 000002
式（１）の限界（ただし、Ｖは設定フローの総数である）は、ρｉより低くない長期レートでフローｉがサービスを受けることを保証する。
【００１５】
ＤＲＲアルゴリズムは、サーバのアクティビティをサービスフレームに分割する。本発明は、基準タイムスタンプ増分ＴＱを用いて仮想時間領域でフレーム期間を表現するアルゴリズムの定式化を参照する。この定式化は、最初に［２］で提示されたＤＲＲの定義と機能的に等価であるが、本発明の記述にはより適している。
【００１６】
１フレーム内で、各設定フローｉには、次式のような量Ｑｉの情報ユニットの送信の権利が与えられる。
Ｑｉ＝ρｉ・ＴＱ    （２）
【００１７】
スケジューラは、フレームあたり１回だけバックログフローを処理するため、一発でそのフレームに対するそれらのフローのサービス期待値を充足する。各フローｉは、パケットのキュー（フローキュー）と、長さｌｉｋの新たなパケットｐｉｋがフローキューの先頭に到着するごとに更新される次式のタイムスタンプＦｉとを管理する。
Ｆｉｋ＝Ｆｉｋ−１＋ｌｉｋ／ρｉ    （３）
【００１８】
スケジューラは、フローへのサービスを、そのタイムスタンプがＴＱより小さくとどまる限り続ける。タイムスタンプＦｉが基準タイムスタンプ増分ＴＱを超えると、スケジューラは、フローｉの処理の終了を宣言し、ＴＱをフローｉのタイムスタンプから減算し、サービスすべき別のバックログフローを探す。その結果、ＴＱの減算後、Ｆｉの値は、フローｉに対するサービスクレジット（貸し）を表現する。一般に、タイムスタンプは、バックログフローのサービスクレジットを後のフレームに持ち越すため、スケジューラは、長期間では（すなわち、複数のフレームにわたって）、割り当てられたサービスシェアに比例してサービスを分配することができる。
【００１９】
フローｉがアイドルになると、スケジューラは直ちに別のフローに移り、それへのサービスの提供を開始する。フローｉが短時間で再びバックログになると、フローｉは、サーバからの次の処理を受けるためには、次のフレームの開始を待たなければならない。フローがアイドルになると、同じフローが将来のフレームで再びバックログになった場合のサービスの損失を避けるために、そのフローのタイムスタンプはゼロにリセットされる。構成により、アイドルのフローのタイムスタンプは常にＴＱより小さいため、タイムスタンプのリセットは、他のフローに不利になるような余分のサービスクレジットを生じることはない。
【００２０】
構成により、サービスフレームの始めには、フローｉのタイムスタンプＦｉの値は０とＬｉ／ρｉの間にある。ただし、Ｌｉはフローｉのパケットの最大サイズである。タイムスタンプの初期値のゆらぎは、フローｉが１フレームで送信する情報ユニットの量のゆらぎを引き起こし、これは区間（Ｑｉ−Ｌｉ，Ｑｉ＋Ｌｉ）内にある。このため、すべての設定フローが永続的に積滞しているときでさえ、サーバが１フレームで送信する情報ユニットの総量は一定でない。
【００２１】
ＤＲＲスケジューラは、［２］では、ＦＩＦＯ順に巡回されるバックログフローの単一の連結リストにより実装された。次式のように、基準タイムスタンプ増分ＴＱが、最小サービスシェアのフローに対する最大サイズのパケットにより定まるタイムスタンプ増分より小さくない場合には、バックログフローを単一ＦＩＦＯキューに配置すると、Ｏ（１）の実装複雑さとなる。
ＴＱ≧Ｌｍａ／ρｍｉ    （４）
【００２２】
式（４）の条件が満たされない場合、スケジューラのアルゴリズム複雑さは、連続するパケット送信間に実行されるべき基本オペレーションの最悪の場合の数とともに爆発的に増大する（基本オペレーションには、連結リストにおけるフローの取り出しおよび挿入、タイムスタンプ更新、タイムスタンプと基準タイムスタンプ増分の比較、が含まれる）。実際、スケジューラは、基準タイムスタンプ増分の反復減算によりタイムスタンプが［０，ＴＱ）区間内に入るまで、いくつかの連続するフレームの間、フローへのサービスを拒否しなければならない可能性がある。図３Ａに、ＤＲＲにおいて、新たなパケットがフローｉのキューの先頭に到着したときに、そのフローｉを処理しそのタイムスタンプを更新するための規則を指定する例示的な擬似コードのリストを示す。
【００２３】
余剰ラウンドロビン（ＳＲＲ）の記述は［３］に与えられている。このアルゴリズムは、ＤＲＲと同じパラメータおよび変数を有するが、異なるイベントがタイムスタンプの更新を引き起こす。すなわち、フローｉは、パケットｐｉｋの送信が完了すると、その結果のフローのバックログ状態とは独立に、新たなタイムスタンプＦｉｋを受け取る。フレームの終わりは、１パケットの送信後に常に検出され、その前には検出されない。タイムスタンプは、（ＤＲＲの場合のクレジット（貸し）の代わりに）現フレームの期間中にフローによって累積されたデビット（借り）を次フレームに持ち越す。
【００２４】
ＤＲＲに比べてＳＲＲの利点は、ＳＲＲは、フローのフレームの終わりを決定するためにキュー先頭パケットの長さを前もって知る必要がないことである。逆に、悪意のあるフローが競争相手から帯域を盗むことを防ぐために、このアルゴリズムは、アイドルになったフローのタイムスタンプをリセットすることができない。アイドルフローのヌルでないタイムスタンプは、そのフローがアイドルになったのと同じフレームの終了によって結局は不用(obsolete)となる。理想的には、タイムスタンプは、不用になったらすぐにリセットされるべきである。しかし、数十万、さらには数百万のフローを処理するスケジューラでは、同時に不用になる可能性のあるすべてのタイムスタンプを即座にリセットすることは現実には不可能である。
【００２５】
本発明についてのこの記述は、アイドルフローのタイムスタンプの不用性を何らチェックしないＳＲＲアルゴリズムの実装に焦点をしぼる。この実装では、新たに積滞したフローは常に、そのタイムスタンプの値がいかに古くとも、そのタイムスタンプの最近の値からアクティビティを再開する。この仮定の効果は、新たに積滞したフローが、前に長時間の間に累積したデビットの結果として、サーバが最初にやってくるときにその受けるべきサービスの一部をあきらめなければならないことがあることである。図３Ｂに、ＳＲＲにおいて、サーバがパケットｐｉｋの送信を完了したときにフローｉを処理しそのタイムスタンプを更新するための規則を指定する例示的な擬似コードのリストを示す。
【００２６】
説明を簡単にするため、本明細書の残りの部分では、重み付けラウンドロビン（ＷＲＲ）の名称は一般に、ＤＲＲまたはＳＲＲを総称的に（それらを区別する特徴への明示的な言及がなければ）指すために用いるものとする。
【００２７】
エンドツーエンドのフローまたはそれらのフローの集合に帯域保証を提供するための低コストのトラフィック管理技術の利用可能性と、ネットワーク全体でサービス保証をサポートするためのロバストなフレームワークの存在［４，５，６，７］とは、ＩＰネットワークからベストエフォート型トラフィックを除去することの十分な理由とはならず、代わりに、相異なる型のトラフィックを効率的に統合するためにネットワークノードで解決されるべき追加のトラフィック管理問題を導入する。ベストエフォート型フローは、明示的に指定されたＱｏＳ要求を有しない。そのため、出リンクへのアクセスを規制するスケジューラにおいて、これらのフローに対する帯域資源は予約されない。しかし、同じリンクを要求する相異なるＢＥフローの相対的扱いにおけるフェアネス（公平性）が強く望まれることがある。
【００２８】
ベストエフォート型フローのセットだけを考える場合、すべてのフローに対して同一のサービスシェア割当てを行うＷＲＲスケジューラは、フェアネス目標を満たすために考え得る最も単純な方式である。帯域保証型フローも同じ出リンクで競合する場合には、単一のＷＲＲスケジューラではもはや不十分である。ＢＥフローに割り当てられるシェアは、ＧＢフローに割り当て可能なプールから帯域を差し引き、帯域の分配における固定された割合を強制して、ＢＥフローの性質とは矛盾することになる。
【００２９】
この問題点について簡単な例で説明する。ある単一のＷＲＲスケジューラが、ＧＢおよびＢＥの両方のフローを処理する。サーバは、その容量ｒの１％を各設定ＢＥフローに割り当てる（もちろん、１％を選ぶのは全く任意であり、他のどのような値でも同様である）。スケジューラのアクティビティは、２０個の設定ＢＥフローから開始される。この時点で、各ＢＥフローは、すべてのＢＥフローが永続的に積滞している場合には、サーバ容量の５％を取得する。次に、サーバは、それぞれ０．４ｒを要求する２個のＧＢフローを受け付ける。これで、サーバの容量は完全に割り当てられ、これ以上いずれの型のフローも設定することはできない。
【００３０】
ベストエフォート型フローに明示的シェアを割り当てる結果、このようなフローの存在は、サーバがＧＢフローに予約可能な公称帯域の量を縮小する。さらに、公称帯域の利用可能性は、設定可能なＢＥフローの数を制約する。理想的には、ＧＢフローは、サーバの容量全体にアクセスできるべきであり、ＢＥフローの設定は、（単に、ＢＥフローは明示的な帯域要求を有しないという理由だけで）公称帯域の利用可能性によって制約されるべきではない。
【００３１】
この例では、２個の設定ＧＢフローのうちの一方がアイドルになると、この単一ＷＲＲスケジューラは、積滞しているＧＢフローに０．６６ｒを与える一方、各ＢＥフローは、サーバの容量の１．６６％を得る（スケジューラは、バックログフローの明示的なシェアに従って、固定割合でバックログフローへのサービスを継続する）。理想的には、積滞しているＧＢフローは、代わりに、サーバの容量の４０％以下を受けるべきであり、一方、各ＢＥフローは、０．０３ｒでサービスされるべきである。
【００３２】
Fair Airportスケジューラ［８］では、ＢＥフローは、保証サービスキュー（ＧＳＱ：Guaranteed Service Queue）において予約帯域を有さず、補助サービスキュー（ＡＳＱ：Auxiliary Service Queue）においてＧＢフローより高い優先度を有する。これは、ＧＢフローとＢＥフローの統合に関するすべての機能的な問題に対するエレガントな解決法を提供するであろうが、スケジューラの実装コストは、ＷＲＲスケジューラの代表的なコストよりはるかに高くなる。ずっと安価な選択肢は、［９，１０］に見られる。この場合、サーバは、２個のＷＲＲスケジューラでＧＢおよびＢＥフローを処理し、割り当てられるＧＢフローの保証サービスシェアの総和をＧＢ集合に与えた後にのみ、ＢＥ集合をサービスする。
【００３３】
残念ながら、このアプローチは、アイドルＧＢフローによって使用されていない帯域をＢＥフローに移す際のフレキシビリティに欠ける。その理由は、少なくとも１つのＧＢフローが積滞している限り、ＧＢ集合からＢＥ集合へ帯域が移されないからである。このように、従来のＷＲＲスケジューラは、ＧＢフローとＢＥフローの効率的な統合を提供していない。
【００３４】
従来技術の問題点は、本発明によれば、帯域保証型（ＧＢ）フローとベストエフォート型（ＢＥ）フローを効率的に統合する単一のＷＲＲスケジューリングエンジンを用いて解決される。図４に、この改良されたＷＲＲスケジューラの２層論理編成を示す。
【００３５】
本発明のＷＲＲスケジューラは、２個のＷＲＲスケジューラの組合せからなる。一次ＷＲＲスケジューラ（ＰＷＳ）４０１は、サービスを個々のＧＢフロー４０２に分配し、ＢＥフロー集合４０３が各フレームの期間中に受けるべきサービスの量を決定する。二次ＷＲＲスケジューラ（ＳＷＳ）４０４は、ＢＥフロー集合のサービスシェアを個々のＢＥフロー４０５にわたり公平に分配することを担当する。
【００３６】
本発明のＷＲＲスケジューラは、基本のＷＲＲスケジューラのキューイング構造を複製すること、および、ＢＥ集合のいくつかの状態情報を管理すること（図５）のコストだけで、ＧＢフローからＢＥフローへの未使用帯域の移動における最も精細なグラニュラリティを達成する。ＷＲＲスケジューラは、サービスフレーム４０６を２個のサブフレームに分割することによって、基本ＷＲＲスケジューラの動作を修正する。第１サブフレーム４０７で、ＰＷＳ４０１はＧＢフロー４０２の帯域要求を充足する。第２サブフレーム４０８で、ＳＷＳ４０２はフェアサービスを複数のＢＥフロー４０５に分配する。各フレーム４０６の期待される（予想）期間４０９は固定され、形式的にはＰＷＳ基準タイムスタンプ増分ＴＱＰＷＳによって表現される。実際のフレーム期間４１０は、おおむね、そのフレーム全体でのバックログＢＥフローの利用可能性（アベイラビリティ）に依存する。
【００３７】
従来技術のＷＲＲスケジューラとは異なり、本発明の改良されたＷＲＲスケジューラでは、ＢＥフローのサービスシェアは、ＧＢフローの帯域保証をも支持する同一の有限なプール（これはサーバの容量によって制約される）から差し引かれるのではなく、ＧＢフローにより未使用のまま残されているサーバ容量の部分に動的に適応する別個の無制約のプールから差し引かれる。本発明のスケジューリング装置は、個々のＧＢフロー４０２と、ＢＥフロー集合４０３（単一のエンティティとして扱われる）とをＰＷＳ４０１で処理する。ＰＷＳ４０１では、ＢＥフロー集合４０２のサービスシェアは固定されず、その代わりに、毎回のサービスフレームで、ＧＢフローのバックログダイナミクスに適応する。
【００３８】
ＳＷＳ４０４は、機能的にはＰＷＳ４０１と同一であるが、すべてのフローに同じ値のサービスシェアを割り当てることによって、個々のＢＥフロー４０５へのサービスのフェアな（等しい）分配を保証する。このようにして、ＷＲＲスケジューラは、帯域保証型フローとベストエフォート型フローをフレキシブルに統合する。なお、本発明のもう１つの特徴によれば、第２スケジューラは、必ずしも、サービスをＢＥフローに等分配するように設定される必要はない。
【００３９】
スケジューラの詳細な動作について説明する前に、その機能的要素に焦点を当てる。図５に、ＧＢフローとＢＥフローをフレキシブルに統合するために改良されたＷＲＲスケジューラによって利用されるキュー、状態テーブル、およびパラメータを図示する。ＧＢフロー４０２は、ｇｂ１〜ｇｂＶとして示されている。それぞれのＧＢフロー４０２ごとに、受信されるパケットはそれぞれのフローキュー５０２に格納される。フローごとのＧＢ状態テーブル５０３は、ＧＢフローのさまざまなデータ要素を格納し、それぞれのＧＢフロー４０２ごとに１つずつある。例えば、フローｇｂ１を考えると、ＧＢ状態テーブル５０３は、タイムスタンプＦｇｂ１、最小保証サービスシェアρｇｂ１、およびフレームフラグＦＦｇｂ１を含む。
【００４０】
個々のＢＥフロー４０５は、ｂｅ１〜ｂｅＵとして示されている。それぞれのＢＥフロー４０５ごとに、受信されるパケットはそれぞれのフローキュー５０５に格納される。フローごとのＢＥ状態テーブル５０６は、ＢＥフローのさまざまなデータ要素を格納し、それぞれのＢＥフロー４０５ごとに１つずつある。例えば、フローｂｅ１を考えると、データテーブル５０６は、タイムスタンプＦｂｅ１およびサービスシェアρｂｅ１を含む。前に言及したように、サービスシェアρｂｅ１〜ρｂｅＵは、すべてのＢＥフローｂｅ１〜ｂｅＵについて同一である必要はない。
【００４１】
グローバル状態テーブル５０７は、グローバルフレームカウンタＧＦＣ、ＰＷＳの基準タイムスタンプ増分ＴＱＰＷＳ、およびＳＷＳの基準タイムスタンプ増分ＴＱＳＷＳのようなデータを格納する。ＢＥフロー集合状態テーブル５０８は、タイムスタンプＦＢＥ、ＢＥ現在シェアφＢＥ、およびＢＥ累積シェアΦＢＥのような、ＢＥフロー集合に関係するデータを格納する。ＰＷＳ先入れ先出し（ＦＩＦＯ）キュー５０９は、ＧＢフロー４０２へのポインタを格納する。
【００４２】
ＰＷＳ  ＦＩＦＯキュー５０９は、それぞれのＧＢフローキュー５０２からのパケットの送信を決定するためにＰＷＳがＧＢフローを巡回すべき順序を示す。レジスタ５１０は、ＰＷＳ  ＦＩＦＯキュー５０９における先頭および末尾の位置へのポインタを格納する。ＳＷＳ  ＦＩＦＯキュー５１１は、ＢＥフロー４０５へのポインタを格納する。ＳＷＳ  ＦＩＦＯキュー５１１は、それぞれのＢＥフローキュー５０５からのパケットの送信を決定するためにＳＷＳがＢＥフローを巡回すべき順序を示す。レジスタ５１２は、ＳＷＳ  ＦＩＦＯキュー５１１における先頭および末尾の位置へのポインタを格納する。
【００４３】
図６は、スケジューラが利用される入力通信リンクインタフェース２００の例示的なブロック図である。通信リンクインタフェース２００は、データパケット受信器６００、スケジューラ６０２、およびパケット送信器６０１を有する。例として、スケジューラは、コントローラ６０３、グローバル状態ＲＡＭ６０４、およびレジスタ６０５を、すべて同一のチップ６０６上に有するように示されている。パケットＲＡＭ６０７およびフロー別状態ＲＡＭ６０８は、別々のチップ上に位置するように示されている。明らかに、動作容量およびその他の特性に依存して、スケジューラ６０２は、他の構成でも実装可能である。
【００４４】
コントローラ６０３は、本発明の方法を実装したプログラムを格納し実行する。通信リンクインタフェース２００の動作を制御するプログラムの実施例を図７〜図８にフローチャート形式で示す。図５および図６をあわせて参照すると、ＧＢおよびＢＥのフローキュー５０２および５０５内のパケットはパケットＲＡＭ６０７に格納される。ＧＢフロー別状態テーブル５０３およびＢＥフロー別状態テーブル５０６はＲＡＭ６０８に格納される。グローバル状態テーブル５０７およびＢＥ集合状態テーブル５０８はＲＡＭ６０４に格納される。ＰＷＳおよびＳＷＳのＦＩＦＯキュー５０９および５１１内の要素はＲＡＭ６０８に格納される。ＰＷＳおよびＳＷＳのＦＩＦＯキューの先頭および末尾ポインタ５１０および５１２はレジスタのセット６０５に格納される。ＧＢおよびＢＥのフローキュー５０２および５０５は、データパケットのＦＩＦＯキューとして実装される。
【００４５】
スケジューラ６０２の動作の概略は以下の通りである。パケット受信器６００は、入力リンク２０１−１〜２０１−ｒから到着するＧＢデータパケットフローｇｂ１〜ｇｂＶおよびＢＥデータパケットフローｂｅ１〜ｂｅＵのパケットを受信する。受信器６００は、それぞれの入パケット（図示せず）のヘッダに含まれるフロー識別フィールドの内容を用いて、そのパケットのデータパケットフローを識別する。識別されるフローは、ＧＢフローまたはＢＥフローのいずれかであることが可能である。したがって、フロー識別は、入パケットがＧＢフローキュー５０２のうちの１つまたはＢＥフローキュー５０５のうちの１つのいずれに格納されるべきかを決定する。スケジューラは、ＧＢフロー別状態テーブル５０３、ＢＥフロー別状態テーブル５０６、グローバル状態テーブル５０７、およびＢＥ集合状態テーブル５０８の内容を用いて、各サービスフレーム４０６内の第１サブフレーム４０７および第２サブフレーム４０８の長さを決定する。例えば、現在積滞しているＧＢフローが、サーバ容量ｒの８０％に等しい累積帯域割当てを有する場合、スケジューラ６０２は、サービスフレームの約８０％を第１サブフレームに割り当て、残りの２０％を第２サブフレームに割り当てる。このようにして、スケジューラは、すべてのバックログＧＢフローの帯域保証を強制するとともに、サーバ容量の未使用部分があれば（われわれの例では２０％）、ＢＥフロー集合に分配する。第１サブフレーム４０７の期間中、スケジューラ６０２は、ＰＷＳ  ＦＩＦＯキュー５０９の先頭からバックログＧＢフローをサービスし、そのフローキュー５０２から送信器６０３へパケットを転送する。第２サブフレーム４０８の期間中、スケジューラ６０２は、ＳＷＳ  ＦＩＦＯキュー５１１の先頭からバックログＢＥフローをサービスし、そのフローキュー５０５から送信器６０３へパケットを送る。
【００４６】
［動作の詳細］
図４〜図６をあわせて参照して、以下の記載では、本発明の方法がどのようにして第２サブフレーム４０８においてＢＥフロー集合４０３に付与されるサービスの量を決定するかについて説明する。第１サブフレーム（あるいは「ＧＢサブフレーム」）４０７は、フレームの最初に積滞しているＧＢフロー４０２の帯域要求を充足することに充てられる。第２サブフレーム（あるいは「ＢＥサブフレーム」）４０８では、ＷＲＲスケジューラ６０２は、予想フレーム期間４０９に達するまで、ＢＥフロー集合４０３をサービスする（予想フレーム期間は、リンクの全容量がＧＢフローに割り当てられ、すべての割り当てられたＧＢフローが積滞しているときのＷＲＲサービスフレームの期間である）。第１サブフレーム４０７および第２サブフレーム４０８の両方の期間は、ＧＢフロー４０２のバックログ状態の変化によって引き起こされるゆらぎを受ける一方、実際の全フレーム期間４１０は、バックログＢＥフロー４０５が利用可能である限り、ほぼ一定のままである（前述のように、各バックログフローが１フレーム期間中に受けることのできるサービスの量の可変性のため、サービスフレームの全期間は、「ほぼ一定」なだけであり、「厳密に一定」ではない）。
【００４７】
１サービスフレーム４０６内でＢＥフロー集合４０３に付与されるサービスの量を決定するために、スケジューラは、リンク容量ｒと、バックログＧＢフローのサービスシェアの総和との間の差を追跡するＢＥ現在シェアφＢＥを管理する。
【数２】
0004017867.tif 000003
ただし、ＢＧＢ（ｔ）は、時刻ｔにおいて積滞しているＧＢフローの集合である。（式（５）におけるφＢＥの定義は、ＧＢフローに割り当てられるサービスシェアの総和がサーバの容量を超えないことを仮定している。）
【００４８】
スケジューラ６０２は、各ＧＢサブフレーム４０７の最後（これは、どのバックログＧＢフローも現フレームでさらなるサービスを期待しないときに検出される）にＢＥ現在シェアφＢＥをサンプリングし、その値を用いて、次のＢＥサブフレーム４０８に対するＢＥ累積シェアΦＢＥをセットする。スケジューラ６０２はまた、ＢＥサブフレーム４０８の期間を規制するためにＢＥタイムスタンプＦＢＥを管理する。ＳＲＲアルゴリズムに従って、サイズｌＢＥｋのＢＥパケットの送信の終了時に、スケジューラは、ＢＥフロー集合のタイムスタンプを次式のように更新する。
ＦＢＥｋ＝ＦＢＥｋ−１＋ｌＢＥｋ／ΦＢＥ    （６）
【００４９】
ＢＥフロー集合へのサービスの分配は、バックログＢＥフローが利用可能であり、かつ、ＢＥタイムスタンプが基準タイムスタンプ増分ＴＱＰＷＳを超えない限り、継続される。この２つの条件のいずれかが満たされないことは、ＢＥサブフレームおよびフレーム全体の両方の終了を引き起こし、新たなフレームでＧＢフロー４０２へのサービスの分配が再開される。
【００５０】
ＢＥサブフレーム４０８の期間中、スケジューラは、さらに、どのＢＥフローをサービスすべきかを決定しなければならない。同時に積滞しているＢＥフローに対する等量のサービスを要求するフェアネス基準のため、ＢＥフローを処理するメカニズムとして、別のＷＲＲスケジューラ（すなわち、ＳＷＳ４０４）を採用する。ＳＷＳ４０４では、図４に示したように、すべてのＢＥフロー４０５に同じサービスシェアρが割り当てられる。ＢＥフローのサービスシェアρは、サーバの容量に対してはカウントされないため、システムで割当て可能なＢＥフローの数に対する帯域制約はない。ＳＷＳのフレームダイナミクスは、ＰＷＳにおける対応するダイナミクスとは完全に独立である。すなわち、ＳＷＳにおける１フレームを完了するのに複数のＢＥサブフレーム４０８が必要となることもあり、また逆に、ＳＷＳにおける数個のフレームを完了するのにＰＷＳにおける単一のＢＥサブフレーム４０８で十分なこともある。また、ＰＷＳおよびＳＷＳは、それらの基準タイムスタンプ増分（それぞれ、ＴＱＰＷＳおよびＴＱＳＷＳ）として、相異なる値を採用することができる。
【００５１】
ＢＥ現在シェアφＢＥは、１個のＧＢフローがアイドルになるたびにインクリメントされ、１個のＧＢフローがバックログになるたびにデクリメントされる。第１（第２）の場合にＢＥ現在シェアφＢＥに加算（から減算）される量は、ＧＢフローの割り当てられるサービスシェアに等しい。
【００５２】
ＰＷＳがバックログＧＢフローの単一のＦＩＦＯキューとして実装される場合、ＧＢサブフレームの予想期間の検出は、各フローｉに対応するフレームフラグＦＦｉと、グローバルフレームカウンタＧＦＣという、２個の１ビットフラグの比較による。フレームフラグとグローバルフレームカウンタは次のように作用する。ＧＢフローｉは、バックログになると、バックログＧＢフローのキュー（すなわち、ＰＷＳ  ＦＩＦＯキュー５０９）の末尾に付加され、そのフレームフラグＦＦｉがＧＦＣの補数にセットされる。
ＦＦｉ＝¬ＧＦＣ    （７）
サーバは、現フレームに対するフローｉの処理を完了すると、ＰＷＳ  ＦＩＦＯキュー５０９の先頭からそのフローを取り出す。次に、そのＧＢフローに依然としてバックログがある場合、サーバは、ＰＷＳ  ＦＩＦＯキュー５０９の末尾にそのフローを付加し、そのフレームフラグをトグルする。
ＦＦｉ＝¬ＦＦｉ    （８）
ＧＢサブフレームは、ＰＷＳ  ＦＩＦＯキュー５０９の先頭にあるフローのフレームフラグがＧＦＣと異なったときに終了する。サーバは、この条件を検出すると、ＧＦＣの値をトグルし、ＢＥ現在シェアφＢＥをＢＥ累積シェアΦＢＥにコピーする。ＰＷＳ４０１は、ＢＥ累積シェアΦＢＥがゼロより大きい限り、ＢＥ集合をサービスする。ＢＥ集合へのあらゆるＰＷＳサービスは、ＢＥフローへのＳＷＳサービスに転換される。最後のバックログＢＥフローがアイドルになること、あるいは、ＢＥタイムスタンプＦＢＥがＰＷＳ基準タイムスタンプ増分ＴＱＰＷＳを超えること、という２つのイベントが、ＢＥ累積シェアΦＢＥのリセットを、したがってＢＥサブフレームの終了を引き起こす可能性がある。
【００５３】
図７および図８に、本発明に従ってパケットの送信をスケジューリングする方法をフローチャート形式で示す。このフローチャートは、ＳＲＲが、基礎となるスケジューリングアルゴリズムであるという仮定に基づいている。機能性に関する限り、ＳＲＲの代わりにＤＲＲを用いても問題はない。同様に、図４の装置は、ＰＷＳ４０１およびＳＷＳ４０２のそれぞれに対してバックログフローの単一のＦＩＦＯキュー（それぞれ、ＰＷＳ  ＦＩＦＯキュー５０９およびＳＷＳ  ＦＩＦＯキュー５１１）を用いて、ＰＷＳ４０１およびＳＷＳ４０２を実装している。フレーム内とフレーム外のフローの明確な分離が可能な他の任意のキューイング構造も同様に使用可能である。最後に、ＢＥフローを処理するためにＷＲＲスケジューラを採用することにより、ＢＥフロー全体にわたるサービスフェアネスを強制することができるが、これはＧＢフローとＢＥフローの効率的な統合を達成するためには厳密には要求されない。ＢＥフローをＧＢフローとは別個に処理するために、他の任意のスケジューリングメカニズムも同様に使用可能である。
【００５４】
以下の記述では、図４、図５、図６、および図７〜図８を参照する。図４（図５、図６）で最初に定義される要素の参照符号は４（５、６）から始まるが、図７〜図８のフローチャートのステップは、ステップ番号の前にＳを付けることによって（例えば、Ｓ３１０）示される。
【００５５】
図７において、Ｓ３１０で、スケジューラ６０２は、新たに受信したデータパケットがあるかどうかをチェックする。Ｓ３１０で、新たに受信したデータパケットがなく、Ｓ３１５で、バックログフローがある場合、制御はＳ５００に移る。他方、Ｓ３１０で、新たに受信したデータパケットがなく、Ｓ３１５で、バックログフローがない場合、スケジューラ６０２は、新たなパケットが受信されるまで、ステップＳ３１０とＳ３１５の間を循環する。Ｓ３１０において、新たに受信したパケットの存在が受信器６００で検出されると、Ｓ３２０で、スケジューラ６０２は、それらのパケットのうちの１つを選択する。その後、Ｓ３３０で、スケジューラ６０２は、データパケットのフローを識別し、最終的に、パケットを適当なフローキュー（識別されたフローに依存して、ＧＢフローキュー５０２またはＢＥフローキュー５０５）に格納する。Ｓ３５０で、フローキューの長さがゼロでない場合、Ｓ３５５で、そのフローのキュー長をインクリメントし、制御はＳ５００に移る。Ｓ３５０で、フローのキュー長がゼロである場合、Ｓ３６０で、スケジューラ６０２は、バックログフローの数をインクリメントし、Ｓ３７０で、フローキューの長さをインクリメントする（例として、フローキューの長さは、キュー内のデータパケットの数を表すことが可能であるが、バイト数、ビット数、またはメモリワード数のような他の単位も、フローキューの長さを表現するために使用可能である）。その後、Ｓ３８０で、スケジューラ６０２は、識別されたフローがＧＢフローであるかどうかをチェックする。識別されたフローがＧＢフローｇｂｉである場合、Ｓ３９０で、スケジューラ６０２は、フレームフラグＦＦｇｂｉを¬ＧＦＣに等しいとセットする。その後、スケジューラ６０２は、Ｓ４００で、ＢＥ現在シェアφＢＥをデクリメントし、Ｓ４１０で、フローｇｂｉをＰＷＳ  ＦＩＦＯキュー５０９の末尾に付加し、最後に制御をＳ５００に移す。
【００５６】
Ｓ３３０で識別されたフローがＳ３８０でＧＢフローとして認識されない場合、スケジューラ６０２は、まず、（Ｓ４２０で）そのフローをＳＷＳ  ＦＩＦＯキュー５１１の末尾に付加した後、（Ｓ４３０で）バックログフローの数が１に等しいかどうかをチェックする。Ｓ４３０でバックログフローの数が１に等しい場合、スケジューラ６０２は、Ｓ４４０で、ＢＥ累積シェアΦＢＥをＢＥ現在シェアφＢＥに等しいとセットした後、制御をＳ５００に移す。Ｓ４３０で、バックログフローの数が１に等しくない場合、スケジューラは制御を直接Ｓ５００に移す。
【００５７】
Ｓ５００で、送信器６０１が古いパケットの送信で依然としてビジーであり、送信のために新たなパケットを受け付けることができない場合、スケジューラ６０２はＳ３１０に戻る。他方、送信器６０１が古いパケットの送信でビジーでない場合、Ｓ５１０で、スケジューラ６０２は、前にサービスしたフローでその状態をさらに更新しなければならないものがあるかどうかをチェックする。このようなフローが存在しない場合、スケジューラ６０２は最後にサービスしたフローの状態をすでに更新したことを意味しており、Ｓ５２０で、スケジューラ６０２は、バックログフローがあるかどうかを判定する。バックログフローが存在しない場合、スケジューラ６０２の制御はＳ３１０に戻る。他方、Ｓ５２０でバックログフローの存在が検出された場合、Ｓ５３０で、スケジューラ６０２は、ＢＥフロー集合状態テーブル５０８に格納された、ＢＥ累積シェアΦＢＥの現在の値をチェックする。ＢＥ累積シェアΦＢＥの値がゼロである場合、スケジューラ６０２はＳ５４０に進み、サービスのために、ＰＷＳ  ＦＩＦＯキュー５０９の先頭のＧＢフロー４０２を選択する。その後、Ｓ５６０で、スケジューラ６０２は、選択したＧＢフロー４０２のフローキュー５０２の先頭のパケットを送信器６０１に送る。その後、制御はＳ３１０に戻る。Ｓ５３０で、ＢＥ累積シェアΦＢＥの値がゼロより大きい場合、スケジューラ６０２はＳ５５０に進み、サービスのために、ＳＷＳ  ＦＩＦＯキュー５１１の先頭のＢＥフロー４０５を選択する。その後、Ｓ５６０で、スケジューラ６０２は、選択したＢＥフロー４０５のフローキュー５０５の先頭のパケットを送信器６０１に送る。その後、制御はＳ３１０に戻る。
【００５８】
Ｓ５１０で、スケジューラ６０２は、最後にサービスしたフローの状態をまだ更新しなければならないと判定した場合、Ｓ５７０で、最後にサービスしたフローのキュー長のデクリメントを開始する。その後、Ｓ５８０で、スケジューラ６０２は、フロータイムスタンプの更新に進む。Ｓ５９０で、スケジューラ６０２は、最後にサービスしたフローがＧＢフローであるかどうかをチェックする。最後にサービスしたフローがＧＢフローｇｂｉである場合、Ｓ６００で、スケジューラ６０２は、フローのキュー長が今ゼロに等しいかどうかをチェックする。キュー長がゼロに等しくない場合、Ｓ６１０で、スケジューラは、ＧＢフローｇｂｉの更新されたタイムスタンプがＰＷＳ基準タイムスタンプ増分ＴＱＰＷＳ以上であるかどうかをチェックする。更新されたタイムスタンプがＴＱＰＷＳより小さい場合、スケジューラ６０２はＳ７１０に進む。他方、更新されたタイムスタンプがＴＱＰＷＳより小さくない場合、スケジューラ６０２は、まず、最後にサービスしたＧＢフローｇｂｉのフレームフラグＦＦｉをトグルした後、Ｓ６３０で、タイムスタンプを正当な範囲［０，ＴＱＰＷＳ）内にリセットし、Ｓ６４０で、ＰＷＳ  ＦＩＦＯキュー５０９の先頭からＧＢフローｇｂｉへのポインタを取り出し、最後に、Ｓ６５０で、同じフローポインタをＰＷＳ  ＦＩＦＯキュー５０９の末尾に付加する。その後、制御はＳ７１０に移る。
【００５９】
Ｓ６００で、ＧＢフローｇｂｉのキュー長がゼロに等しい場合、Ｓ６６０で、スケジューラ６０２は、フローのタイムスタンプがＴＱＰＷＳ以上であるかどうかをチェックする。タイムスタンプがＴＱＰＷＳより小さい場合、制御はＳ６８０に進む。そうでない場合、Ｓ６７０で、スケジューラは、タイムスタンプを正当な範囲内にリセットした後、Ｓ６８０に進む。Ｓ６８０で、スケジューラは、最後にサービスしたフローをＰＷＳ  ＦＩＦＯキュー５０９の先頭から取り出した後、Ｓ６９０で、ＢＥ現在シェアφＢＥをインクリメントする。Ｓ７００で、スケジューラ６０２は、バックログフローの数をデクリメントした後、Ｓ７１０に進む。
【００６０】
Ｓ７１０で、スケジューラ６０２は、今ＰＷＳ  ＦＩＦＯキュー５０９の先頭にあるＧＢフローｇｂｊのフレームフラグを、グローバルフレームカウンタＧＦＣと比較する。フレームフラグとＧＦＣが同じ値を有する場合、スケジューラ６０２は、制御をＳ５２０に移し、そうでない場合、Ｓ７２０で、ＧＦＣの値をトグルし、Ｓ７３０で、ＳＷＳ  ＦＩＦＯキュー５１１にバックログフローがあるかどうかをチェックする。少なくとも１つのバックログフローがＳＷＳ  ＦＩＦＯキュー５１１にある場合、Ｓ７４０で、スケジューラ６０２は、ＢＥ累積シェアΦＢＥをＢＥ現在シェアφＢＥに等しいとセットした後、制御をＳ５２０に移す。Ｓ７３０でバックログフローが検出されない場合、スケジューラ６０２は制御を直接Ｓ５２０に移す。
【００６１】
Ｓ５９０で、最後にサービスしたフローがＢＥフローｂｅｉとして分類された場合、Ｓ７５０で、スケジューラ６０２は、ＢＥフローｂｅｉのキュー長がゼロに等しいかどうかをチェックする。キュー長がゼロに等しくない場合、最後にサービスしたＢＥフローｂｅｉのフローキュー５０５にパケットが残っていることを意味し、スケジューラは、最後にサービスしたＢＥフローｂｅｉの更新されたばかりのタイムスタンプがＳＷＳ  ＦＩＦＯキュー５１１の基準タイムスタンプ増分ＴＱＳＷＳ以上であるかどうかをチェックする。更新されたタイムスタンプがＴＱＳＷＳより小さい場合、スケジューラ６０２はＳ８４０に進む。他方、更新されたタイムスタンプがＴＱＳＷＳより小さくない場合、スケジューラ６０２は、まず、Ｓ７７０で、タイムスタンプを正当な範囲［０，ＴＱＳＷＳ）内にリセットした後、Ｓ７８０で、ＳＷＳ  ＦＩＦＯキュー５１１の先頭からＢＥフローｂｅｉへのポインタを取り出し、最後に、Ｓ７９０で、同じフローポインタをＳＷＳ  ＦＩＦＯキュー５１１の末尾に付加する。その後、スケジューラ６０２は、制御をＳ８４０に移す。
【００６２】
Ｓ７５０で、ＢＥフローｂｅｉのキュー長がゼロに等しい場合、Ｓ８００で、スケジューラ６０２は、フローのタイムスタンプがＴＱＳＷＳ以上であるかどうかをチェックする。タイムスタンプがＴＱＳＷＳより小さい場合、制御はＳ８２０に移る。そうでない場合、Ｓ８１０で、スケジューラ６０２は、タイムスタンプを正当な範囲内にリセットした後、Ｓ８２０に進む。Ｓ８２０で、スケジューラ６０２は、最後にサービスしたフローｂｅｉをＳＷＳ  ＦＩＦＯキュー５１１の先頭から取り出す。Ｓ８３０で、スケジューラ６０２は、バックログフローの数をデクリメントした後、Ｓ８４０に進む。
【００６３】
Ｓ８４０で、スケジューラ６０２は、ＢＥフロー集合のタイムスタンプＦＢＥを更新する。その後、Ｓ８５０で、スケジューラ６０２は、ＢＥフロー集合の更新されたタイムスタンプを、ＰＷＳ基準タイムスタンプ増分ＴＱＰＷＳと比較する。タイムスタンプＦＢＥが基準タイムスタンプ増分ＴＱＰＷＳ以上である場合、Ｓ８６０で、スケジューラは、タイムスタンプを正当な範囲［０，ＴＱＰＷＳ）内にリセットした後、Ｓ８７０に進み、ＢＥフロー集合のＢＥ累積シェアΦＢＥをゼロにリセットする。その後、スケジューラ６０２は、制御をＳ５２０に移す。Ｓ８５０で、ＢＥフロー集合のタイムスタンプが、ＰＷＳ基準タイムスタンプ増分より小さいと判定された場合、スケジューラ６０２は、Ｓ８８０に進み、ＳＷＳ  ＦＩＦＯキュー５１１にバックログフローが存在するかどうかをチェックする。バックログフローがＳＷＳ  ＦＩＦＯキュー５１１に残っていない場合、スケジューラ６０２は制御をＳ８７０に移し、そうでない場合、Ｓ５２０に進む。
【００６４】
上記の実施例は、本発明に従って、重み付けラウンドロビンスケジューラで帯域保証型およびベストエフォート型のフローを統合するために使用可能な諸原理の単なる例示である。当業者であれば、ここに明示的に記載していなくとも、特許請求の範囲により規定される本発明の技術思想および技術的範囲から離れずに、それらの原理を実現するさまざまな構成を考えることが可能である。
【００６５】
［付録］
文献
［１］ M. Katevenis, S. Sidiropoulos, and C. Courcoubetis, "Weighted Round Robin Cell Multiplexing in a General-Purpose ATM Switch", IEEE Journal on Selected Areas in Communications, vol.9, pp.1265-79, October 1991.
［２］ M. Shreedhar and G. Varghese, "Efficient Fair Queueing Using Deficit Round Robin", IEEE/ACM Transactions on Networking, vol.4, no.3, pp.375-385, June 1996.
［３］ H. Adiseshu, G. Parulkar, and G. Varghese, "A Reliable and Scalable Striping Protocol", Proceedings of ACM SIGCOMM '96, August 1996.
［４］ K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Request for Comments (RFC) 2638, IETF, July 1999.
［５］ R. Braden, D. Clark, and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", Request for Comments (RFC) 1633, IETF, June 1994.
［６］ J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured Forwarding PHB Group", Request for Comments (RFC) 2597, IETF, June 1999.
［７］ V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding PHB", Request for Comments (RFC) 2598, IETF, June 1999.
［８］ P. Goyal and H. M. Vin, "Fair Airport Scheduling Algorithms", Proceedings of NOSSDAV '97, pp.273-282, May 1997.
［９］ F. M. Chiussi and A. Francini, "Providing QoS Guarantees in Packet Switches", Proceedings of IEEE GLOBECOM '99, High-Speed Networks Symposium, Rio de Janeiro, Brazil, December 1999.
［１０］ F. M. Chiussi and A. Francini, "A Distributed Scheduling Architecture for Scalable Packet Switches", IEEE Journal on Selected Areas in Communications, Vol.18, No.12, December 2000.
【００６６】
【発明の効果】
以上述べたごとく、本発明によれば、帯域保証型（ＧＢ）およびベストエフォート型（ＢＥ）のフローをフレキシブルに統合するスケジューリング方法および装置が実現される。
【００６７】
特許請求の範囲の発明の要件の後に括弧で記載した番号がある場合は、本発明の一実施例の対応関係を示すものであって、本発明の範囲を限定するものと解釈すべきではない。
【図面の簡単な説明】
【図１】データソース、通信スイッチ、およびデータ宛先を含む例示的なパケットネットワークを示す図である。
【図２】図１のパケットネットワークで用いられる例示的な通信スイッチを示す図である。
【図３】図３Ａは、新たなパケットがフローキューの先頭に到着したときにフローｉを処理する不足ラウンドロビン（ＤＲＲ）アルゴリズムで用いられる擬似コードの例を示し、図３Ｂは、サーバが１パケットの送信を完了したときにタイムスタンプｉを更新する余剰ラウンドロビン（ＳＲＲ）アルゴリズムで用いられる擬似コードの例を示す図である。
【図４】本発明による、スケジューラの２層論理編成を示す図である。
【図５】本発明のスケジューラによって利用されるキュー、状態テーブル、レジスタ、およびパラメータの機能図である。
【図６】図５の装置の具体的実装の例示的ブロック図である。
【図７】本発明に従ってパケットの送信をスケジューリングする方法を記述した例示的な流れ図である。
【図８】本発明に従ってパケットの送信をスケジューリングする方法を記述した例示的な流れ図である。
【符号の説明】
１０１  通信スイッチ
１０２  データソース
１０３  宛先
２００  通信リンクインタフェース
２０１  入力リンク
２０２  出力リンク
２５０  スイッチファブリック
４０１  一次ＷＲＲスケジューラ（ＰＷＳ）
４０２  ＧＢフロー
４０３  ＢＥフロー集合
４０４  二次ＷＲＲスケジューラ（ＳＷＳ）
４０５  ＢＥフロー
４０６  サービスフレーム
４０７  第１サブフレーム（ＧＢサブフレーム）
４０８  第２サブフレーム（ＢＥサブフレーム）
４０９  予想フレーム期間
４１０  実際のフレーム期間
５０２  ＧＢフローキュー
５０３  ＧＢフロー別状態テーブル
５０５  ＢＥフローキュー
５０６  ＢＥフロー別状態テーブル
５０７  グローバル状態テーブル
５０８  ＢＥフロー集合状態テーブル
５０９  ＰＷＳ  ＦＩＦＯキュー
５１０  レジスタ
５１１  ＳＷＳ  ＦＩＦＯキュー
５１２  レジスタ
６００  パケット受信器
６０１  パケット送信器
６０２  スケジューラ
６０３  コントローラ
６０４  グローバル状態ＲＡＭ
６０５  レジスタ
６０６  チップ
６０７  パケットＲＡＭ
６０８  フロー別状態ＲＡＭ
【図１】
0004017867.tif 000004
【図２】
0004017867.tif 000005
【図３】
0004017867.tif 000006
【図４】
0004017867.tif 000007
【図５】
0004017867.tif 000008
【図６】
0004017867.tif 000009
【図７】
0004017867.tif 000010
【図８】
0004017867.tif 000011