JP2004180302A - 通信装置のためにデータトラフィックフローをスケジュールするシステムおよび方法 - Google Patents

Abstract

【課題】供給される集合体フローに付随するフローに異なるサービス品質を与えるためのシステムと方法を提供すること。
【解決手段】本方法は、通信ネットワークにおいて複数のデータトラフィックフローをスケジュールするステップを含み、さらに（ｉ）データトラフィックの第１のカテゴリ内のデータトラフィックフローをスケジュールするステップを含み、データトラフィックの前記第１のカテゴリがそれに付随する第１の帯域幅容量を有し、（ｉｉ）前記第１の帯域幅容量のどの部分がデータトラフィックの前記第１のカテゴリ内のデータトラフィックフローによって使用されていないかを判定するステップ、および（ｉｉｉ）データトラフィックの第２のカテゴリ内のデータトラフィックに使用するために前記第１の帯域幅容量の前記未使用部分を供給する、データトラフィックの前記第２のカテゴリ内の前記データトラフィックフローをスケジュールするステップを含む。
【選択図】 図３Ａ

Description

本発明は、概して、通信装置のためにデータトラフィックフローをスケジュールするシステムおよび方法に関する。特に、本システムおよび方法は、データトラフィックフローの集合体および選択したトラフィックフローを保証するサービス品質（ＱｏＳ）を供給するトラフィックスケジューリングの枠組みに関する。

データトラフィックの管理を実行し、通信ネットワークでデータの切り換えを行うシステムでは、データトラフィックフローの集合体の要素をスケジュールすることがしばしば望ましい。データトラフィックフローの集合体は、ＡＴＭ仮想パス（ＶＰ）およびＭＰＬＳラベルスイッチパス（ＬＳＰ）を含むいくつかのデータ伝送プロトコル内に供給される。データトラフィックの多様なＱｏＳ要求条件が集合化されたデータトラフィックフローによって取り扱われなければならない。多様なＱｏＳ要求条件を取り扱うことの可能な１つのプロトコルはＭＰＬＳ Ｅ−ＬＳＰである。しかしながら集合化されたデータトラフィックのフローについては、それによって使用される帯域幅に制限が課される可能性がある。たとえば、そのような制限はリアルタイム（ＲＴ）もしくは非リアルタイム（ｎＲＴ）のサービスを搬送する帯域幅制限型のＬＳＰに課される可能性がある。

通信ネットワークにわたって搬送されるデータトラフィックについてはしばしば、通信サービスプロバイダと顧客の間のサービス水準契約（ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ）（ＳＬＡ）がデータトラフィックに関する性能水準保証を設定するであろう。それらの保証を満足させないときにはしばしばサービスプロバイダに罰則が課される。たとえば、保証はＲＴデータトラフィックフローのようなデータトラフィックフローのあるカテゴリに関する最大受容可能遅延を指定する可能性もある。その結果、サービスプロバイダは性能保証を満足させるように注意しなければならず、他方で同時にネットワーク上で利用可能な帯域幅の制限された量で作業しなければならない。

米国特許第５，９２６，４５９号明細書 米国特許第６，１９８，７２３号明細書

多様なＱｏＳ要求条件を伴う集合化されたデータトラフィックフローをスケジュールするための３つの一般的アプローチが知られており、（ｉ）ＱｏＳ中心のアプローチ、（ｉｉ）フロー中心のアプローチ、および（ｉｉｉ）初めの２つのアプローチの混成である。

「ＱｏＳ中心」のアプローチはすべてのフロー（集合体その他の成分）を単一のスケジューラ上にスケジュールする。集合体は事実上、スケジューリングのレベルで考慮されない。むしろ、後に続く装置がすべてのフローを１つのフローとして処理するように識別子のみが設定される。「ＱｏＳ中心」のアプローチの範例として、Ｌｙｌｅｓらに交付された米国特許第５，９２６，４５９号明細書は、個々のネットワークのデータトラフィックをある排他的カテゴリについて実質的に従って時間多重化されたフローのパケットを直列に発信するフロー当たりの待機データトラフィック形成器を開示している。Ｌｙｌｅｓで述べられているアプローチは、集合体の機能から干渉を受けることなくスケジューラの能力の対象となるＱｏＳの要求条件を満足させることを可能にする。しかしながら、ＱｏＳ中心のアプローチは、データトラフィックをスケジュールするときに集合体をユニットとして処理することができない。それ自体では、集合体のための帯域幅の共有および帯域幅の保証が供給されることは不可能である。

「フロー中心」のアプローチは階層スケジューラを使用し、そこでは集合体のすべての成分（すなわち特定の行き先に向かうフローに相当する）は１つのスケジューリングエンティティ上に一体にスケジュールされる。スケジューリングエンティティはその集合体の成分によって使用されるだけであり、スケジューリングエンティティはそれ自体さらに高位のエンティティ上にスケジュールされる。フロー中心のアプローチは、その集合体を表わすスケジューリングエンティティのサービス率を制限することによって帯域幅の制限を容易にする。しかしながらこのアプローチでは、サービス可能なＱｏＳ水準の範囲は、さらに高位のスケジューリングで干渉が生じるせいで制限を受ける。たとえば、集合体のスケジューリングは、帯域幅を全体的に過剰供給することなくＲＴデータトラフィックの厳密な遅延要求条件を満足させることを可能にすることができない。また別の範例として、ＲＴＥＦ（リアルタイム優先転送）データトラフィックを含む集合体のサービス提供は、そのときに言わばベストエフォートのデータトラフィックのみを含む他の集合体のサービス提供のせいで遅延される可能性がある。

混成のアプローチは類似したＱｏＳを有する部分集合体の複数のフローを形成するために階層スケジューリングを使用する。第３のアプローチの範例はＰａｒｒｕｃｋらに交付された米国特許第６，１９８，７２３号明細書であり、それはデータ伝送装置の出力経路に複数セルの出力部を形成する方法を開示している。しかしながら、混成のアプローチは第１のアプローチと同じ制限を共有しており、データトラフィックをスケジュールするときに集合体のデータトラフィックを単一のユニットとして処理することができない。

したがって、スケジューリングを目的としてデータトラフィックのフローを集合化し、大幅に異なる複数のＱｏＳ要求条件を有するデータトラフィックのフローを扱い、知られているスケジューリングのアプローチの欠点を解決することの可能な方法とシステムが必要とされる。

第１の態様では、集合体フローに付随するフローに多様な品質を与える方法が提供される。この方法は、
（ｉ）データトラフィックの第１のカテゴリ内でデータトラフィックフローをスケジュールするステップを含み、データトラフィックの前記第１のカテゴリがそれに付随する第１の帯域幅容量を有し、
（ｉｉ）前記第１の帯域幅容量のどの部分がデータトラフィックの前記第１のカテゴリ内のデータトラフィックフローによって使用されていないか判定するステップ、および
（ｉｉｉ）前記第１の帯域幅容量の前記未使用部分を与えるデータトラフィックの第２のカテゴリ内で、前記第２のカテゴリ内の前記データトラフィックに使用するためにデータトラフィックフローをスケジュールするステップを含む。

ある実施形態では、本方法はさらに、
（ｉｖ）データトラフィックの前記第２のカテゴリ内でデータトラフィックフローをスケジュールするために第２の帯域幅容量をデータトラフィックの前記第２のカテゴリに付随させるステップを含み、前記第２の帯域幅容量が、前記第１の帯域幅容量の前記未使用部分に加えて、データトラフィックの前記第２のカテゴリのための帯域幅を供給する。

第２の態様では、集合体フローに付随するフローに多様なサービスの品質（ＱｏＳ）を与えるシステムが提供される。このシステムは、
データトラフィックの第１と第２のカテゴリ内でデータトラフィックフローをスケジュールするための少なくとも１つのスケジューラを含み、前記スケジューラが、データトラフィックの前記第１のカテゴリを第１の帯域幅容量に付随させ、データトラフィックの前記第２のカテゴリを前記第１の帯域幅容量の任意の未使用部分に付随させる。

ある実施形態では、データトラフィックの前記第２のカテゴリは第２の帯域幅容量に付随させられ、前記第２の帯域幅容量が、前記第１の帯域幅容量の前記未使用部分に加えて、データトラフィックの前記第２のカテゴリ内のデータトラフィックフローのための帯域幅を供給する。

本発明の他の態様では、上記の態様のさまざまな組合せおよび部分集合が提供される。

本発明の前述およびその他の態様は、その特定の実施形態の以下の説明、および単なる範例の方式で本発明の原理を例示する添付の図面からさらに明らかになるであろう。図面では、同様の要素機能は同様の参照番号である（かつそこでは個々の要素は独自のアルファベットの添え字を有する）。

以下の説明およびそこで述べられる実施形態は、本発明の原理の特定の実施形態の範例もしくは複数の範例を例示する方式で与えられる。これらの範例はそれらの原理および本発明の説明を目的として与えられるものであって限定を目的としたものではない。以下の説明の中で、類似した部分は明細書および複数図面を通して同じ個別参照番号で示される。

ここで図１を参照すると、ネットワークアクセスリンク１１０を経由してある数の顧客Ｃ１．．．．Ｃ４がアクセスノード１０２に接続される範例のネットワーク１００が示されている。本範例では、アクセスノード１０２はネットワーク１００内のソースノードの役目を果たし、それが今度は複数のスイッチングノード１０８Ａ、１０８Ｂ、１０８Ｃを含むネットワーク群１０６に接続される。スイッチングノード１０８Ａ、１０８Ｂ、１０８Ｃはネットワーク群１０６の中枢（ｂａｃｋｂｏｎｅ）を形成し、ネットワーク通信リンク１１２を経由して相互接続される。行き先ノード１０４はネットワーク通信リンク１１２を経由してネットワーク群１０６の他方の側に接続される。

ソースノード１０２はネットワークアクセスリンク１１０を経由して顧客Ｃ１．．．．Ｃ４からデータトラフィックフローを受け取り、ネットワーク１００に接続されたいくつかの行き先ノードのいずれの１つに向けて顧客のデータトラフィックフローを経路指定することも可能にされる。前に言及したように、どのような中間装置（たとえばノード１０８Ａ、１０８Ｂ、１０８Ｃ）も集合体を単一のデータトラフィックフローとして便利に処理することが可能となるように特定の行き先に向けられたデータトラフィックのフローを集合化させることがしばしば望ましい。集合体を単一のデータトラフィックフローとして処理することは、たとえば、その集合体データトラフィックフローを収容するための制限された帯域幅を有するその行き先への専用の接続の使用を容易にする。

本範例では、データトラフィックフローは顧客Ｃ１とＣ２からアクセスノード１０２に入り、行き先ノード１０４へと向けられる。この範例の目的に関すると、顧客Ｃ１とＣ２は異なるＱｏＳ要求条件を備えたデータトラフィックフローを有することが仮定される。たとえば、顧客Ｃ１とＣ２の各々に由来するデータトラフィックフローはＲＴデータトラフィックとｎＲＴデータトラフィックの両方を含む可能性がある。データトラフィックの各カテゴリもしくはクラス内のＱｏＳ水準にさらなる差別化が存在する可能性はあるが、概して、最も有意のＱｏＳ差異はＲＴデータトラフィックとｎＲＴデータトラフィックの間でしばしば見受けられる。さらに特定すると、ＲＴデータトラフィックは厳密な遅延の拘束条件を有するが到着する帯域幅の量はよく制御されている。その結果、ＲＴデータトラフィックに関する主要性能基準は最小の遅延である。他方で、ｎＲＴデータトラフィックは遅延に厳密な拘束条件を有しておらず、かつ到着する帯域幅のレベルは制御されない傾向にある。その結果、ｎＲＴデータトラフィックの集合体に関する主要性能基準は、制限された帯域幅の公平で効率的な割り当てと使用である。

ここで図２を参照すると、異なるＱｏＳ要求条件（たとえばＲＴとｎＲＴ）を備えたデータトラフィックフローを取り扱うための先行技術のデータトラフィック処理システム２００が範例の方式で示されている。このシステム２００は顧客Ｃ１とＣ２から由来するデータトラフィックフローのためのソースノード１０２によって使用されることも可能である。図示したように、顧客Ｃ１とＣ２から入来するＲＴデータトラフィックのフロー２０１はスケジューラ２０２によってスケジュールされる。その後、スケジューラ２０２の成功エントリ（ｗｉｎｎｉｎｇ ｅｎｔｒｙ）はリンク２０８への伝送のためにスケジューラ２０６によってスケジュールされることが可能である。その一方で、顧客Ｃ１とＣ２から由来するｎＲＴデータトラフィックのフロー２０３はスケジューラ２０４によって受けられ、待ち行列に入れられる。スケジューラ２０４はスケジューラ２０２と実質的に同じ機能を供給するが、しかし代わってｎＲＴデータトラフィックフロー２０３をスケジュールするのに使用される。その後、やはりスケジューラ２０４の成功エントリはリンク２０８への伝送のためにスケジューラ２０６によってスケジュールされることが可能である。

場合によっては、スケジューラ２０２とスケジューラ２０４の間で、スケジューラ２０６が、たとえばスケジューラ２０２を成功スケジューラとして選択する可能性があるとき、その後にスケジューラ２０２がリンク２０８への伝送のために成功エントリを選択する可能性がある。当業者は理解するであろうが、図示したスケジューラの導入は待ち行列間の帯域幅の「公平な」割り当てを供給するように選択される可能性がある。しかしながら、公平な割り当てが保証されない可能性がある。スケジューラ２０２と２０４のための待ち行列アルゴリズムが必ずしも同じアルゴリズムである必要がないこともやはり理解されるであろう。

さらに図２を参照すると、ＲＴデータトラフィックのフロー２０１とｎＲＴデータトラフィックのフロー２０３が両方共にスケジューラ２０６によってスケジュールされるので、もしもスケジューラ２０６が現在ｎＲＴデータトラフィック２０３を処理していると、最新到着のＲＴデータトラフィック２０１が即座にサービス提供されない可能性がある。したがって、ＲＴデータトラフィックに関する確実な最小遅延要求条件を供給するための顧客Ｃ１およびＣ２とのＳＬＡはサービスプロバイダによって満たされない可能性がある。

ここで説明するが、本発明の実施形態は（ＲＴとｎＲＴデータトラフィックフローの間といった）広範に変わるＱｏＳ要求条件を有するデータトラフィックのフローを処理し、特定の行き先ノードに接続される帯域幅制限を受けた接続内にこれらの要求条件を与える。これは、概して、初期に高優先度のスケジューラのために留保されるがその後は高優先度のスケジューラによって使用されない帯域幅に対する低優先度のデータトラフィックのアクセスを待たせるようにスケジューラが操作するのを可能にすることによって達成される。

ここで図３Ａを参照すると、システム３００Ａは、ＲＴおよびｎＲＴデータトラフィックがアクセスノード１０２で顧客Ｃ１とＣ２から受け取られ（図１）、帯域幅制限型リンク３１８上の行き先ノード１０４（図１）への伝送のためにスケジュールされる実施形態である。本実施形態は上述したような「フロー中心」のアプローチのある特徴を利用するが、しかし下記で説明するようにＲＴおよびｎＲＴデータトラフィックのフローを異なってスケジュールする。

図示した範例では、顧客Ｃ１およびＣ２から入来するすべてのＲＴのデータトラフィックフロー２０１は入来する待ち行列３０１Ａと３０１Ｂでそれぞれ待ち行列に入れられ、スケジューラ３０２によってサービス提供される。したがって、本実施形態では、所定の顧客に関するすべてのＲＴトラフィックは単一の待ち行列に集合化される。

代替となる実施形態で、所定の顧客から由来するＲＴデータトラフィックのフローが各フローについて別の待ち行列内に入れられる可能性があり、あるいは集合化の異なるレベルが生じる可能性があることは理解されるであろう。所定の顧客に関するＲＴトラフィックのための多数の待ち行列を有する代替の実施形態が下記でさらに詳細に説明される。

知られているスケジューリングシステムの慣例に従うと、ＲＴデータトラフィック２０１はスケジューラ３０２内でスケジュールされ、成功エントリが選択される。出力３０４として示された成功エントリは、さらなる処理およびリンク３１８上の付随する接続に対する帯域幅の割り当てのためにスケジューラ３０６へと転送される。この範例の目的のために、リンク３１８は１０Ｍｂｐｓに速度制限されるが、この速度制限は具体的な例示であり、ほかの点では制限することを意味するものではない。（当業者は理解するであろうが、次に何をサービス提供すべきかスケジューラが選択する間では、データは実際にはスケジューラを通って流れない。むしろ、スケジューラはデータトラフィック上の情報を修正し、選択を行い、実際のデータを伝送するために待ち行列管理装置に信号を返す。）
具体的例示の実施形態では、スケジューラ３０６は完全な優先スケジューラであり、ＲＴデータトラフィックのフロー２０１はその中で最高の優先順位を与えられる。したがって、顧客Ｃ１およびＣ２のＲＴトラフィックのフロー２０１は、スケジューラ３０８Ａおよび３０８ＢによってスケジュールされるいかなるｎＲＴデータトラフィックのフロー２０３も含めて、スケジューラ３０６によって処理される他のトラフィックに先行して処理される。

場合によっては、スケジューラ３０２とスケジューラ３１２の間で、優先スケジューラ３０６が成功スケジューラ３０２または３１２を選択すると、成功スケジューラ３０２または３１２にさらに成功エントリを選択させる。

さらに図３Ａを参照すると、顧客Ｃ１から由来するｎＲＴのデータトラフィックフロー２０３は待ち行列３０７Ａおよび３０７Ｂに入れられ、スケジューラ３０８Ａによってスケジュールされる。同様に、顧客Ｃ２から由来するｎＲＴのデータトラフィックフロー２０３は待ち行列３０７Ｃおよび３０７Ｄに入れられ、スケジューラ３０８Ｂによってスケジュールされる。具体的例示の実施形態では、スケジューラ３０８Ａおよび３０８ＢはＷＦＱとして導入される。それぞれ出力３１０Ａおよび３１０Ｂとして示したスケジューラ３０８Ａおよび３０８Ｂの出力は、やはりＷＦＱとして導入される可能性のあるスケジューラ３１２に供給される。スケジューラ３１２におけるｎＲＴデータトラフィックフロー２０３のスケジューリングは前に述べた「フロー中心」のアプローチで生じるスケジューリングと同様である。しかしながら、スケジューラ３０８Ａによる出力３１０Ａの速度制限は、たとえば、顧客Ｃ１についてＲＴトラフィックフロー２０１によって使用される帯域幅の量と、顧客Ｃ１についてｎＲＴトラフィックフロー２０３によって使用される帯域幅の量の両方が追跡される「フロー中心」のアプローチとは異なる。

具体的例示の実施形態では、顧客Ｃ１に関するＲＴトラフィックのフロー２０１によって使用される帯域幅の量の追跡はスケジューラ３０８Ａと待ち行列３０１Ａの間にリンク３１６Ａを供給することによって達成される。リンク３１６Ａを通じて、待ち行列３０１Ａからスケジュールされたデータトラフィックに関する帯域幅パラメータがスケジューラ３０８Ａに連絡され、それにより、スケジューラ３０８Ａはシステム３００Ａ内で顧客Ｃ１による合計帯域幅使用量を追跡することが可能になる。スケジューラ３０８Ａは、もしもあるとするとどの程度の帯域幅が顧客Ｃ１に関するｎＲＴデータトラフィックフロー２０３をスケジュールするのに利用可能であるかを判定するために、この情報および顧客Ｃ１に割り当てられた合計の帯域幅を使用する。したがって、もしも顧客Ｃ１に関するＲＴトラフィックのフロー２０１が利用可能な帯域幅すべてを消費している場合、顧客Ｃ１に関するｎＲＴデータトラフィックフロー２０３のために利用可能な帯域幅が無いことをスケジューラ３０８Ａは判断する。もしも顧客Ｃ１に関するＲＴトラフィックのフロー２０１が帯域幅のすべてを消費していない場合、顧客Ｃ１に関するｎＲＴトラフィックフロー２０３は未使用の帯域幅を与えられ、顧客Ｃ１に関するＲＴトラフィックフロー２０１とｎＲＴトラフィックフロー２０３の組合せがまるでトラフィックフロー２０１、２０３が単一のフローであるかのように帯域幅制限されることを可能にする。

同様に、顧客Ｃ２のためのスケジューラ３０８Ｂと待ち行列３０１Ｂの間にリンク３１６Ｂが設けられ、顧客Ｃ２に関するＲＴトラフィックのフロー２０１と顧客Ｃ２に関するｎＲＴトラフィックのフローが組み合わされ、顧客Ｃ１に関するトラフィックのフロー２０１、２０３と同様にして帯域幅が制限されることが可能となる。

フローの集合体（すなわち顧客Ｃ１、Ｃ２などによって集合化されたもの）による帯域幅使用の制限が、さまざまなスケジューラ３０２、３０６、３０８Ａ、３０８Ｂ、３１４および待ち行列３０１Ａ、３０１Ｂ、３０７Ａ．．．．３０７Ｄの中で帯域幅を調停することから分離処理として処理されることは理解されるであろう。本範例では、帯域幅調停処理は仕事の節約である。すなわち、もしもいずれかのエンティティが伝送すべきデータを有するならば、スケジューラは複数のエンティティの中からデータを含むそれを選択するであろう。速度制限されたエンティティについては、もしもエンティティのサービス提供が速度の乱れを引き起こすならば、そのエンティティはサービス提供されることを考慮されないであろう。したがって、調停を実行するユニットにとって、これはエンティティが空であることと等価である。この範例では、割り当てに利用可能な帯域幅を有するいずれかのエンティティ不在の待ち行列をスケジューラ３０２が有する限り、スケジューラ３０６はスケジューラ３０２を選択して次にサービス提供される待ち行列（３０１Ａまたは３０１Ｂ）を決定するであろう。もしもスケジューラ３０２上でスケジュールされたすべての待ち行列（３０１Ａまたは３０１Ｂ）が空であるか、またはそれらの割り当て帯域幅すべてを使い切っているかのいずれかである場合、スケジューラ３０６はスケジューラ３１２を選択して次にサービス提供される待ち行列３０７Ａ．．．．３０７Ｄを決めるスケジューラ（３０８Ａまたは３０８Ｂ）を決定するであろう。したがってこの枠組みでは、それにスケジュールされたデータトラフィックを含む待ち行列を有し、かつ伝送に利用可能な帯域幅を有するスケジューラだけがスケジュールすることを考慮されるであろう。

例を挙げると、待ち行列３０１Ａがスケジューラ３０２によってサービス提供され、かつｎＲＴスケジューラ３０８Ａへと伝送されるときに作り出されるメッセージを介して、待ち行列３０１Ａとスケジューラ３０８Ａの間の通信がリンク３１６Ａを使用して導入されることが可能である。そのメッセージはＲＴの待ち行列３０１Ａによって使用される帯域幅の量を示すであろう。そのメッセージは、使用される帯域幅の量を示すペイロードを伴って待ち行列３０１Ａとスケジューラ３０８Ａの間で伝送されるパケット内に導入されることが可能である。ＲＴの待ち行列３０１Ａは、それに付随するスケジューラ３０８Ａに対するポインタを有することで、どのスケジューラに情報を付帯させるべきかを示す。場合によっては、スケジューラ３０８Ａによって使用される局部メモリ内で、スケジューラ３０８Ａがそれに付随する待ち行列のリストを保存することも可能である。したがって、データトラフィックのフローがスケジューラ３０８Ａに到着すると、スケジューラ３０８Ａがそのリストを調べて他のどの待ち行列がそれに付随するかを識別することが可能である。その後、スケジューラ３０８Ａは付随する待ち行列にメッセージを送ることでそれらがいずれかのデータトラフィックを伝送したかどうか、およびそれら他の待ち行列によって使用されていないいずれの帯域幅をスケジューラ３０８Ａが利用できるかを知ることができる。

顧客当たり多数のＲＴクラスおよびｎＲＴクラスを収容するために図３Ａのスケジューリングシステム３００Ａがスケジューラの追加段を有し得ることは理解されるであろう。たとえば、図３Ｂに示したように、システム３００Ｂは待ち行列３１７Ａと３１７Ａ’をスケジュールするスケジューラ３１９Ａ、および待ち行列３１７Ｂと３１７Ｂ’をスケジュールするスケジューラ３１９Ｂを含む。各々のスケジューラ３１９Ａ、３１９Ｂは顧客Ｃ１に関する異なるｎＲＴクラスをスケジュールする。同様に、スケジューラ３１９Ｃおよび３１９Ｄは待ち行列３１７Ｃ、３１７Ｃ’、および３１７Ｄ、３１７Ｄ’からそれぞれ由来する多数のｎＲＴクラスをスケジュールする。図３Ｂはまた、スケジューラ３０２によって扱われる待ち行列３０１Ｃ上の顧客Ｃ１に関する別のＲＴクラスも示している。当業者は、特定の用途に必要な数のＣｏＳクラスを収容するためにスケジューラと待ち行列の追加段が加えられる可能性があることを理解するであろう。

ここで図４Ａを参照すると、トークンとバケットを使用したたとえ（ａｎａｌｏｇｙ）を介してスケジューリング活動の範例的な協調が示されている。その中で、トークンシステム４００Ａ内で各々のトークンは特定の待ち行列もしくはスケジューラによって伝送可能なデータの単位を表わす。その待ち行列もしくはスケジューラはバケットで表わされ、トークンはバケット内に集められる。いずれのバケット内のトークンの深さも特定の時間の待ち行列もしくはスケジューラによる伝送許容限度のデータの量を表わす。スケジューラの場合では、トークンはそのスケジューラ上でスケジュールされる待ち行列のいずれによっても送られ得るデータの量を表わす。バケットのサイズはスケジューラの最大バースト許容速度である。トークンがバケット３０８内に入る速度４０６は、そのバケットに付随する待ち行列もしくはスケジューラに対して利用可能な帯域幅（単位時間当たりのデータの単位数）である。スケジューラがデータトラフィックの要求を処理するとき、それはその要求に割り当てられたそれ相応のトークン数をそのスケジューラ／待ち行列のバケットまたは下位のスケジューラ／待ち行列のバケットから取り去る。バケットがオーバーフローするとき、速度制限型待ち行列に利用可能な帯域幅が過剰に存在する。余剰の帯域幅は他のバケットに向けられてそれらに使用されることが可能である。

例を挙げると、ＲＴの待ち行列３０１Ａはバケット４０２に割り当てられ、ｎＲＴのスケジューラ３０８Ａはバケット４０４に割り当てられる。バケット４０２と４０４は、トークン入力ストリーム４０６がバケット４０２に流れ込むように配列される。バケット４０２がトークンで満たされるとき、トークンの段（ｌｅｖｅｌ）は深さ４０８によって示される。スケジューラ３０２（図３Ａ、図３Ｂ）が処理のためにＲＴトラフィックストリーム２０１を選択すると、割り当て帯域幅の量を表わすトークンがバケット４０２から取り去られる。これは出力ストリーム４１０で表わされる。待ち行列３０１Ａによって要求される帯域幅が最大許容よりも少ないことが理由で、もしも出力ストリーム４１０が入力ストリーム４０６よりも小さい場合、深さ４０８は増す。この状況が持続するならば、最終的に深さ４０８はバケット４０２の縁に到達する。入力ストリーム４０６によって供給されるいかなる追加の帯域幅でもってしてもバケット４０２はオーバーフローし、トークンの余剰のストリーム４１２が生じ、それがバケット４０４に流れ込む。余剰のストリーム４１２に関する情報は、上述したようにリンク３１６Ａを通るメッセージを介してＲＴ待ち行列３０１ＡとｎＲＴスケジューラ３０８Ａの間に供給される可能性がある。

余剰のストリーム４１２から由来するトークンはバケット４０４に集まるので、トークンの深さはその中で深さ４１４で表わされるように上昇する。スケジューラ３１２（図３Ａ）に関するｎＲＴトラフィックがサービス提供されると、サービス提供されたｎＲＴトラフィックに割り当てられた帯域幅がバケット４０４から取り去られる。これは出力ストリーム４１６で表わされる。したがって、システム４００Ａがバケット４０２に付随するスケジューラ（すなわちスケジューラ３０２）に、保証された帯域幅をシステムの合計帯域幅から供給することが本範例から判るであろう。いかなる余剰帯域幅も、トラフィックストリーム２０１の要求条件が完全に満たされたときにのみバケット４０４に供給される。

バケット４０２のサイズおよびバケット４０２に入る入力ストリーム４０６が、到着するＲＴデータトラフィックフローがトークンのバケット４０２を完全に使い尽くさないことを確実化するのに充分なほどに大きくあるべきことは理解されるであろう。同時に、バケット４０２のサイズは、ある程度のトークンが第２のトークンバケットへとオーバーフローするのを可能にしてｎＲＴデータトラフィック２０６を処理するのに充分なほどに小さくあるべきである。その結果、第１のトークンバケット４０２の容量は、上記で言及したように、スケジューラ３０２によって扱われるべきＲＴデータトラフィックフローのバースト速度、およびｎＲＴデータトラフィックのためのある程度の最少限の追加帯域幅に関する要求条件によって決定される。

代替の実施形態では、顧客Ｃ１に対して利用可能な合計帯域幅が常に顧客Ｃ１のＲＴトラフィックに対して許容された帯域幅よりも大きくなるように、クレジットの別の入力ストリーム４０７がバケット４０４に供給されることが可能である。言い換えると、顧客Ｃ１のためのＲＴトラフィックのレベルに関係なく顧客Ｃ１のためのｎＲＴトラフィックに対してある程度の帯域幅が割り当てられるであろう。この代替の実施形態では、ＲＴデータトラフィックの到着速度は、（ｎＲＴデータトラフィックフローの集合体、および付随するいかなるＲＴデータトラフィックフローも含む）データトラフィックフローすべてに対して許容された帯域幅よりも厳重に制約されるべきである。これは、各々のＲＴデータトラフィックフローがそれ自体の規定された帯域幅制限をその速度とバーストサイズに有し、それがスケジューラ３１２によってスケジュールされるｎＲＴデータトラフィックフローの集合体上に設定されるいかなる帯域幅制限にも累積されることを意味する。

ここでさらに別の代替実施形態である図４Ｂを参照すると、図４Ａに関して上記で説明したようなモデル化され、かつ待ち行列３０１Ａに付随するバケット４０２を有するシステム４００Ｂが示されている。しかしながら、システム４００Ｂはまた、ｎＲＴスケジューラ３０８Ａに付随する集合体バケット４０３も供給する。バケット４０２と同じ方式でクレジットがバケット４０３から取り去られる。そのとき、バケット４０３から出るクレジットのいかなるオーバーフローもｎＲＴスケジューラ３０８Ａに付随するバケット４０４に流れ込むであろう。この代替実施例では、集合体バケット４０３に対するクレジットの入力ストリーム４０９はバケット４０２に対するクレジットの入力ストリーム４０６よりも大きくされることが可能である。これがバケット４０４に対するクレジットのオーバーフロー４１２を供給し、それが、ｎＲＴトラフィックに対して常に利用可能な帯域幅のある程度の量を保証するであろう。

図４Ｂのトークンシステム４００Ｂが図４Ｃのシステム４００Ｃで示したように一般化されることが可能であることは理解されるであろう。システム４００Ｃは多数のバケット４０２、４０２’、４０２”などで表わされる多数の待ち行列もしくはスケジューラを含む。これらバケット４０２、４０２’、４０２”の各々は、たとえば異なるＣｏＳ水準および速度Ｒ１、Ｒ２、．．．Ｒ（ｎ−１）を有するデータトラフィックに関する待ち行列を表わす可能性がある。集合体速度Ｒを有する集合体バケット４０３がやはり設けられる。集合体速度Ｒは個々の速度Ｒ１、Ｒ２、．．．Ｒ（ｎ−１）すべての集合体よりも大きいことが好ましく、かつ集合体バケット４０３は多数のバケット４０２、４０２’、４０２”の個々の速度Ｒ１、Ｒ２、．．．Ｒ（ｎ−１）すべての集合体と同じ速度で更新される。充分な集合体速度Ｒでもって、バケット４０４に対するクレジットのオーバーフロー４１２はバケット４０４によって処理されるデータトラフィックのために少なくともある程度の帯域幅を保証する。

都合のよいことに、さまざまな具体的例示の実施形態による上述の解決策は、集合体の成分（すなわち本範例のＲＴ成分）が、ＲＴ成分がフローの集合体の一部としてスケジュールされた場合に可能であるよりも高いＱｏＳ（すなわちさらに小さい遅延）でサービス提供されることを可能にし、しかも同時に全体としての集合体（すなわちｎＲＴデータトラフィックフローの部分集合体および付随するＲＴデータトラフィックフロー）がある程度規定された帯域幅制限（たとえば顧客Ｃ１についてＳＬＡによって設定される）に適合することを保証する。

ここで具体的例示の範例である図５を参照すると、図３のスケジューリング配列はソースノード１０２内でモジュール５００に導入されることが可能である。特に、図５はモジュール５００として象徴的に表わされたアクセスノード１０２内に配置されたシステム３００Ａを示している。インバウンドデータトラフィック待ち行列管理装置５０２および５０４はアクセスリンク１１０を経由して顧客Ｃ１およびＣ２にそれぞれ接続される。モジュール５００はスケジューラ３０２を待ち行列管理装置５０２と５０４から由来するＲＴデータトラフィックの出力ポート群に接続する。スケジューラ３０２のスケジュールされたデータトラフィックは完全優先のスケジューラ３０６に供給される。その一方で、スケジューラ３０８Ａはインバウンド（Ｃ１）ｎＲＴデータトラフィックフローをデータトラフィック待ち行列管理装置５０２から受け取り、スケジュールされた（Ｃ１）ｎＲＴデータトラフィックフローをさらなるスケジューリングのためにスケジューラ３１２へと向ける。同様に、スケジューラ３０８Ｂはインバウンド（Ｃ２）ｎＲＴデータトラフィックフロー２０６をデータトラフィック管理装置５０４から受け取り、スケジュールされたｎＲＴデータトラフィックフローをさらなるスケジューリングのためにスケジューラ３１２へと向ける。スケジューラ３１２の出力は完全優先のスケジューラ３０６に供給される。システム５００のアウトバウンド端部で、帯域幅制限型の回線３１８上に送り出される集合体データトラフィックは、行き先ノード１０４（図１）に向けてネットワーク群１０６（図１）にわたって伝送するためにネットワーク通信リンク１１２（図１）上に搬送される。

当業者は、図５のハードウェア構成が図３のシステムのための多くの可能なハードウェア構成のうちの１つでしかないことを理解するであろう。物理的実施形態で、モジュール５００は適切に導入された特定用途向け集積回路（ＡＳＩＣ）または書替え可能ゲートアレー（ＦＰＧＡ）内に配置されることが可能である。さらに、モジュール５００の機能が２つ以上のモジュールに与えられることも可能である。たとえば、スケジューリングの態様を与えるために、そしてスケジュールされた「成功」エントリが識別されると、成功エントリに付随するデータの伝送を実際に処理するように異なるＡＳＩＣ内に具現化される待ち行列管理装置に信号送信するために、１つのＡＳＩＣが導入されることが可能である。

さまざまな詳細の変更が本実施例に対して為され得ることを当業者は理解するであろうが、それらのすべてが本発明の範囲内に入ることに留意すべきである。たとえば、ＲＴおよびｎＲＴのデータトラフィックフローのためのスケジューラ間の相互作用を表わすために、トークンシステムが示されて説明されたが、データトラフィックフローの他の測定基準に最優先権を与えるために他の類似したトラフィック管理システムが使用される可能性があることは理解されるであろう。

別の例として、前述した図３Ａのシステムは、図３Ｂに例示したようにシステムの前段に配置されたスケジューラの追加段を備えて示されているが、スケジューラのこれら追加段はまた、図示した最後のスケジューラ（上記の範例で完全優先のスケジューラ３０６として描かれている）がそれ自体他のスケジューラ上でスケジュールされることが可能となるようにシステムの後段に配置されることも可能である。同様に、高優先度と低優先度のトラフィック間の階層内の相対的位置は具体的に例示したそれと異なることが可能である。

さらに、大幅に異なるＱｏＳ要求条件を有するデータトラフィックフローの範例としてＲＴおよびｎＲＴのデータトラフィックフローが使用されたが、本発明の教示が、ＱｏＳ要求条件で同様と認識されるいかなる他の分類に対しても拡大され得ることは理解されるであろう。

また、ＲＴフローとｎＲＴフローの集合体だけの速度の制限を例示してきたが、ｎＲＴの集合体の成分を含めて追加の個別フローがそれらの速度制限を有することも可能である。

いくつかのソースから由来するデータトラフィックが、ネットワークを通じて行き先ノードに伝送されるようにアクセスノードへと向けられるネットワークを示すブロック図である。 図１のアクセスノードによって利用される可能性のあるリアルタイム（ＲＴ）のデータトラフィックと非リアルタイム（ｎＲＴ）のデータトラフィックをスケジュールするための先行技術のシステムと方法を示すブロック図である。 図１のアクセスノードによって利用される可能性のある、本発明の一実施形態によるＲＴおよびｎＲＴのデータトラフィックをスケジュールする配列を示すブロック図である。 スケジューラの追加段を有する図３Ａのスケジューリング配列を示すブロック図である。 図３のスケジューリング配列を例示するトークンシステムを示す概略図である。 図４Ａのトークンシステムの代替の実施形態を示す概略図である。 図４Ｂのトークンシステムの一般化したバージョンを示す概略図である。 図３のスケジューリング配列を導入する図１のアクセスノードの処理素子を示すブロック図である。

符号の説明

１００ ネットワーク
１０２ アクセスノード
１０４ 行き先ノード
１０６ ネットワーク群
１０８Ａ、１０８Ｂ、１０８Ｃ スイッチングノード
１１０ ネットワークアクセスリンク
１１２ ネットワーク通信リンク
Ｃ１、Ｃ２、Ｃ３、Ｃ４ 顧客
２００ データトラフィック処理システム
２０１ ＲＴのデータトラフィックフロー
２０２、２０４、２０６、３０２、３０６、３０８Ａ、３０８Ｂ、３１２、３１４、３１９Ａ、３１９Ｂ、３１９Ｃ、３１９Ｄ スケジューラ
２０３ ｎＲＴのデータトラフィックフロー
２０８、３１８ リンク
３００Ａ、３００Ｂ システム
３０１Ａ、３０１Ｂ、３０７Ａ、３０７Ｂ、３０７Ｃ、３０７Ｄ、３１７Ａ、３１７Ａ’、３１７Ｂ、３１７Ｂ’、３１７Ｃ、３１７Ｃ’、３１７Ｄ、３１７Ｄ’ 待ち行列
３０４、３１０Ａ、３１０Ｂ 出力
４００Ａ、４００Ｂ、４００Ｃ トークンシステム
４０２、４０２’、４０２”、４０３、４０４ バケット
４０６、４０９ 入力ストリーム
４０７ クレジット
４０８、４１４ 深さ
４１０、４１６ 出力ストリーム
４１２ 余剰ストリーム
５００ モジュール
５０２、５０４ インバウンドのデータトラフィック待ち行列の管理装置

Claims (27)

1. 通信ネットワーク内の複数のデータトラフィックフローをスケジュールする方法であって、
   （ｉ）データトラフィックの第１のカテゴリ内のデータトラフィックフローをスケジュールするステップを含み、データトラフィックの前記第１のカテゴリがそれに付随する第１の帯域幅容量を有し、
   （ｉｉ）前記第１の帯域幅容量のどの部分がデータトラフィックの前記第１のカテゴリ内のデータトラフィックフローによって使用されていないかを判定するステップ、および
   （ｉｉｉ）データトラフィックの第２のカテゴリ内のデータトラフィックに使用するために前記第１の帯域幅容量の前記未使用部分を供給する、データトラフィックの前記第２のカテゴリ内の前記データトラフィックフローをスケジュールするステップを含む方法。
2. さらに、
   （ｉｖ）データトラフィックの前記第２のカテゴリ内のデータトラフィックフローをスケジュールするためにデータトラフィックの前記第２のカテゴリを第２の帯域幅容量と結びつけるステップを含み、前記第２の帯域幅容量が、前記第１の帯域幅容量の前記未使用部分に加えて、データトラフィックの前記第２のカテゴリのために帯域幅を供給する請求項１に記載の方法。
3. データトラフィックの前記第１と第２のカテゴリがユーザと結びつけられ、前記第１と第２の帯域幅容量が一体になって前記ユーザのための合計帯域幅を有する請求項２に記載の方法。
4. さらに、
   （ｖ）データトラフィックの前記第１のカテゴリ内のデータトラフィックフローを第１の集合体データトラフィックフローに集約するステップ、
   （ｖｉ）データトラフィックの前記第２のカテゴリ内のデータトラフィックフローを第２の集合体データトラフィックフローに集約するステップ、および
   （ｖｉｉ）割り当てられたネットワーク通信経路に沿って前記第１と第２の集合体データトラフィックフローを方向付けするステップを含み、前記ネットワーク通信経路が前記ユーザのための前記合計帯域幅容量を収容するのに充分な帯域幅容量を有する請求項３に記載の方法。
5. データトラフィックの前記第１のカテゴリがリアルタイム（ＲＴ）のデータトラフィックを含み、データトラフィックの前記第２のカテゴリが非リアルタイム（ｎＲＴ）のデータトラフィックを含む請求項４に記載の方法。
6. さらに、
   （ｉｖ）データトラフィックの前記第１のカテゴリ内のデータトラフィックフローを第１の集合体データトラフィックフローに集約するステップ、
   （ｖ）データトラフィックの前記第２のカテゴリ内のデータトラフィックフローを第２の集合体データトラフィックフローに集約するステップ、および
   （ｖｉ）割り当てられたネットワーク通信経路に沿って前記第１と第２の集合体データトラフィックフローを方向付けするステップを含み、前記ネットワーク通信経路が前記ユーザのための前記第１の帯域幅容量を収容するのに充分な帯域幅容量を有する請求項１に記載の方法。
7. データトラフィックの前記第１のカテゴリがリアルタイム（ＲＴ）のデータトラフィックを含み、データトラフィックの前記第２のカテゴリが非リアルタイム（ｎＲＴ）のデータトラフィックを含む請求項６に記載の方法。
8. ステップ（ｉ）でデータトラフィックの前記第１のカテゴリ内の前記データトラフィックフローが第１のスケジューラ上でスケジュールされ、ステップ（ｉｉｉ）でデータトラフィックの前記第２のカテゴリ内の前記データトラフィックフローが第２のスケジューラ上でスケジュールされる請求項１に記載の方法。
9. さらに、
   （ｉｖ）データトラフィックの前記第２のカテゴリ内のデータトラフィックフローをスケジュールするためにデータトラフィックの前記第２のカテゴリを第２の帯域幅容量と結びつけるステップを含み、前記第２の帯域幅容量が、前記第１の帯域幅容量の前記未使用部分に加えて、データトラフィックの前記第２のカテゴリのために帯域幅を供給する請求項８に記載の方法。
10. データトラフィックの前記第１と第２のカテゴリがユーザと結びつけられ、前記第１と第２の帯域幅容量が一体になって前記ユーザのための合計帯域幅容量を有する請求項９に記載の方法。
11. さらに、
    （ｖ）データトラフィックの前記第１のカテゴリ内のデータトラフィックフローを第１の集合体データトラフィックフローに集約するステップ、
    （ｖｉ）データトラフィックの前記第２のカテゴリ内のデータトラフィックフローを第２の集合体データトラフィックフローに集約するステップ、および
    （ｖｉｉ）割り当てられたネットワーク通信経路に沿って前記第１と第２の集合体データトラフィックフローを方向付けするステップを含み、前記ネットワーク通信経路が前記ユーザのための前記合計帯域幅容量を収容するのに充分な帯域幅容量を有する請求項１０に記載の方法。
12. データトラフィックの前記第１のカテゴリがリアルタイム（ＲＴ）のデータトラフィックを含み、データトラフィックの前記第２のカテゴリが非リアルタイム（ｎＲＴ）のデータトラフィックを含む請求項１１に記載の方法。
13. 通信ネットワーク内の複数のデータトラフィックフローをスケジュールするためのシステムであって、
    データトラフィックの第１および第２のカテゴリ内でデータトラフィックフローをスケジュールするための少なくとも１つのスケジューラを含み、前記スケジューラが、データトラフィックの前記第１のカテゴリと第１の帯域幅容量を結びつけ、かつデータトラフィックの前記第２のカテゴリと前記第１の帯域幅容量の任意の未使用部分を結びつけるように構成されているシステム。
14. データトラフィックの前記第２のカテゴリが第２の帯域幅容量と結びつけられ、前記第２の帯域幅容量が、前記第１の帯域幅容量の前記任意の未使用部分に加えてデータトラフィックの前記第２のカテゴリ内のデータトラフィックフローのための帯域幅を供給する請求項１３に記載のシステム。
15. データトラフィックフローの前記第１と第２のカテゴリがユーザと結びつけられ、前記第１と第２の帯域幅容量が一体になって前記ユーザのための合計帯域幅容量を有する請求項１３に記載のシステム。
16. データトラフィックの前記第１のカテゴリ内のデータトラフィックフローが第１の集合体データトラフィックフローに集約され、データトラフィックの前記第２のカテゴリ内のデータトラフィックフローが第２の集合体データトラフィックフローに集約される請求項１５に記載のシステム。
17. 前記第１と第２の集合体データトラフィックフローが割り当てられたネットワーク通信経路に沿って方向付けられ、前記ネットワーク通信経路が前記ユーザのための前記合計帯域幅容量を収容するのに充分な帯域幅容量を有する請求項１６に記載のシステム。
18. データトラフィックの前記第１のカテゴリがリアルタイム（ＲＴ）のデータトラフィックを含み、データトラフィックの前記第２のカテゴリが非リアルタイム（ｎＲＴ）のデータトラフィックを含む請求項１７に記載のシステム。
19. データトラフィックの前記第１のカテゴリ内のデータトラフィックフローが第１の集合体データトラフィックフローに集約され、データトラフィックの前記第２のカテゴリ内のデータトラフィックフローが第２の集合体データトラフィックフローに集約される請求項１３に記載のシステム。
20. 前記第１と第２の集合体データトラフィックフローが割り当てられたネットワーク通信経路に沿って方向付けられ、前記ネットワーク通信経路が前記ユーザのための前記合計帯域幅容量を収容するのに充分な帯域幅容量を有する請求項１９に記載のシステム。
21. データトラフィックの前記第１のカテゴリがリアルタイム（ＲＴ）のデータトラフィックを含み、データトラフィックの前記第２のカテゴリが非リアルタイム（ｎＲＴ）のデータトラフィックを含む請求項２０に記載のシステム。
22. 第１のスケジューラがデータトラフィックの前記第１のカテゴリ内のデータトラフィックフローをスケジュールし、第２のスケジューラがデータトラフィックの前記第２のカテゴリ内のデータトラフィックフローをスケジュールする請求項１３に記載のシステム。
23. データトラフィックフローの前記第１と第２のカテゴリがユーザと結びつけられ、前記第１と第２の帯域幅容量が一体になって前記ユーザのための合計帯域幅容量を有する請求項２２に記載のシステム。
24. データトラフィックの前記第１のカテゴリ内のデータトラフィックフローが第１の集合体データトラフィックフローに集約され、データトラフィックの前記第２のカテゴリ内のデータトラフィックフローが第２の集合体データトラフィックフローに集約される請求項２２に記載のシステム。
25. 前記第１と第２の集合体データトラフィックフローが割り当てられたネットワーク通信経路に沿って方向付けられ、前記ネットワーク通信経路が前記ユーザのための前記合計帯域幅容量を収容するのに充分な帯域幅容量を有する請求項２４に記載のシステム。
26. データトラフィックの前記第１のカテゴリがリアルタイム（ＲＴ）のデータトラフィックを含み、データトラフィックの前記第２のカテゴリが非リアルタイム（ｎＲＴ）のデータトラフィックを含む請求項２５に記載のシステム。
27. データトラフィックの前記第１のカテゴリ内のデータトラフィックフローが第１の集合体データトラフィックフローに集約され、データトラフィックの前記第２のカテゴリ内のデータトラフィックフローが第２の集合体データトラフィックフローに集約される請求項２６に記載のシステム。

Images