(57)【特許請求の範囲】
【請求項１】
パケットネットワーク素子であって：
フローベースのパケットを受取る少なくとも1つの入力と；
所定のバンド幅の少なくとも１つの出力とを備え；
ここでは受取ったパケットは第１および第２のサービスクラスと関係しているものであるとし、さらに；
各受取ったパケットをそのサービスクラスに基づいて、第１または第２の対応するパケットバッファへ向ける手段を備え；
前記第1のパケットバッファは出力バンド幅の所定の部分に割り当てられており、また、
前記第２のパケットバッファは出力バンド幅の残りの部分に割り当てられており；
このパケットネットワーク素子は、前記第1のクラスのフローと関係するバンド幅要求を判断するバンド幅要求判断手段と；
前記バンド幅要求を満たすことができると、第１のパケットバッファに向けて第1のクラスのフローパケットの受け付けを許可する手段と；
第１および第２のパケットバッファから出力へパケットを向ける手段と、
第２のクラスのフローパケット内の宛先アドレスに依存して前記第２のクラスのフローパケットをルート設定するように設けられた第２のクラスのフロールート設定手段とを含むパケットネットワーク素子。
【請求項２】
受け付けを許可する前記手段は、出力バンド幅の前記所定の部分中の現在使用されていない部分が前記ピークレートのバンド幅要求を満たすことができるときには、第１のバッファへの受け付けを許可するピークレート試験を適用するように動作する請求項１記載の素子。
【請求項３】
受け付けを許可する前記手段は前記ピークレート試験を適用し、前記第１のパケットバッファが別のフローを受理するのに十分なスペースをもつときに受け付けを許可するバッファ充填試験を適用するように動作する請求項２記載の素子。
【請求項４】
前記受け付け許可手段は：
第１のパケットバッファを収容できる大きさにされたフロー数から現在収容されているフロー数を減算した数が少なくとも1であるとき；および、
第１のパケットバッファに割り当てられた出力バンド幅の使用されていない部分から提案されたピークレートのフローのバンド幅要求を減算した数がゼロに等しいかまたはそれよりも大きいときのみ；
第１のパケットバッファに対して第１のクラスのフローパケットの受け付けを許可するようにされている請求項３記載の素子。
【請求項５】
前記受け付け許可手段はフローが中止するときに前記未使用の部分の大きさを増加するように動作し、前記増加が、そのフローと関係するピークレートによって除算されたパケットの大きさに実質的に等しい時間期間の経過後に行われる請求項４記載の素子。
【請求項６】
第１のクラスのフローパケットが第１のパケットバッファに対して受け付けを拒否されたとき、第１のクラスのフローパケットを第２のパケットバッファに受け付ける手段をさらに含む請求項１ないし５の何れか1項記載の素子。
【請求項７】
前記ピークレートバンド幅要求判断手段が、前記受取ったパケットからピークレートのフローバンド幅要求情報部分を読み取るようにされている請求項２ないし５の何れか1項記載の素子。
【請求項８】
第１のパケットバッファに割り当てられる出力バンド幅の前記所定の部分をダイナミックに変更することができる請求項１ないし７の何れか１項記載の素子。
【請求項９】
前記ピークレートバンド幅要求判断手段が、各単一のパケットフローに対する特定のピークレートフローバンド幅要求値を判断するようにされている請求項２記載の素子。
【請求項１０】
前記受取ったパケットが第１または第２のサービスクラスと関係するか否かを判断するクラス判断手段をさらに含む請求項１ないし９の何れか1項記載の装置。
【請求項１１】
クラス判断手段が、パケットが範囲を定められた遅延のサービスクラスかまたは最善を尽くすサービスクラスの一方と関係するか否かを判断するようにされている請求項１０記載の素子。
【請求項１２】
前記クラス判断手段が、前記受取ったパケットからクラス識別部分を読み取るようにされている請求項１０または１１記載の素子。
【請求項１３】
パケットネットワーク素子内のフローベースのパケットを
制御する方法であって：
フローベースのパケットを受け取り；
受取ったパケットが第１または第２のサービスクラスと関係し；
その関係するクラスに基づいて各受取ったパケットを第１または第２の対応するパケットバッファへ向け；
前記第１のパケットバッファが所定の出力バンド幅の所定の部分に割り当てられ；
前記第２のパケットバッファが出力バンド幅の残りの部分に割り当てられ；
フローに関係する実行基準を判断し；
前記実行基準を満たすことができるとき、第１のパケットバッファに対して第１のクラスのフローパケットの受け付けを許可することができ；
第１および第２のパケットバッファから出力へパケットを向け、
第２のクラスのフローパケット内の宛先アドレスに依存して前記第２のクラスのフローをルート設定することを含む方法。
【請求項１４】
請求項１ないし１２の何れか1項に記載されている１または複数の素子をさらに含むネットワーク。
【請求項１５】
フローベースのパケットを受取る少なくとも１つの入力と；
所定のバンド幅の少なくとも１つの出力と；
受取ったパケットが第１または第２のサービスクラスと関係するか否かを判断する第１の手段と；
各受取ったパケットをその関係するクラスに基づいて第１または第２の対応するパケットバッファへ送る手段と；
所定数のフローを収容する所定の大きさをもち、出力バンド幅の所定の部分を割り当てられ、現在未使用の部分が収容されるフロー数で変化する前記第１のパケットバッファと；
出力バンド幅の残りの部分を割り当てられている前記第２のパケットバッファと；
フローと関係するピークレートのバンド幅要求を判断する第２の手段と；
第１のパケットバッファが別のフローを受理できるとき、および前記現在未使用の部分が関係するピークレートのフローバンド幅要求を満たすことができるときに、第１のクラスフローパケットを第1のパケットバッファに受け付けることができる手段と；
第１または第２のパケットバッファから出力へパケットを向ける手段と、
第２のクラスのフローパケット内の宛先アドレスに依存して前記第２のクラスのフローパケットをルート設定するように設けられた第２のクラスのフロールート設定手段とを含むパケットネットワーク素子。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、パケットネットワークおよびその中の素子およびホストに関する。
【０００２】
【従来の技術】
従来の接続指向ネットワークでは情報を送る前にユーザはシグナリングを実行するかまたはシグナリングを要求することによって回路を割り当てられる。回路は割当て段階中にユーザに特定の実行基準を満たすようにすることができ、これは一般的にコネクション（接続）受け付け規則によって制御される。したがって適切な回路が設定されると、ホスト間で特定のサービス品質（ＱｏＳ）に関する情報を送ることができる。
【０００３】
対照的に従来のコネクションレスネットワークは回路割り当てに対する要求はなく、コネクション受け付け制御を含まない。したがってネットワークの輻輳中に実行基準を満たすこと、およびサービス品質要求（例えば二地点間の遅延および遅延の変化）を満足させることを保証できない。
【０００４】
したがって将来のネットワークは、従来の接続指向ネットワークによって提供されるサービスに類似するサービス、および従来のコネクションレスネットワークによって提供されるサービスに類似したサービスを支援する必要があることが益々明らかになってきている。さらに、これらのサービスに最低限の複雑さで、受け入れられる性能との折り合い（トレードオフ）のなかで支援されることが不可欠である。
【０００５】
最近１０年間では、将来の広帯域マルチメディアネットワークが非同期転送モード（ＡＴＭ）技術および関係するネットワーク接続基準に基づくことになると考えられてきた。しかしながらＡＴＭネットワークは標準化の初期段階では接続指向型であって、ネイティブな本来のコネクションレスの動作モードを支援しないと決められた。さらにＡＴＭ標準は、ネットワークについてもっと広い視野でとらえるよりも、サービスクラスの最適化に集中する傾向があった。例えばベアラ利用を最適化するのに、支援された各個々のサービスクラスについてバンド幅利用を最適化することは必ずしも必要ではない。概して、応用はネットワーク跡追いできるよりも、より迅速に発展している可能性が高いと思われる。
【０００６】
将来のネットワークに対する従来のＡＴＭサービスがもつ潜在的な望ましくない態様および複雑性を次に示す：
・サービスクラス内の統計的多重化効果(stastical multiplexing)は、リークするバケット源のトラヒック記述子に基づく複雑なコネクション受け付け制御（ＣＡＣ）を要求する。
【０００７】
・セル損失をゼロにするのに必要なバッファの大きさが、統計的多重化効果を使用するときには確定的でない。
【０００８】
・固定されたＡＴＭのセルの大きさが全てのサービスに適している可能性が低い。
【０００９】
・交換ネットワークでは、トラヒックのタイプとは無関係にシグナリング段階が要求され、これはいくつかのタイプのコネクションレストラヒックを実行するときのボトルネックを発生することがある可能性を秘めている。
【００１０】
・セルヘッダの大きさは、より高い層のプロトコルによって既に課されているバンド幅に加えられた別のバンド幅のオーバーヘッドである。（ＡＡＬ５適用に対しては、セルヘッダは実効バンド幅の１０％を無駄にしており、他のＡＡＬに対してこれよりも高い。）
従来のＩＰネットワークは、コネクションレス転送方法のコンセプトから発展しており、今日までのところユーザに唯一の“最善を尽くす(best effort)”サービスを提供している方法よりも発展している。しかしながら新しいサービスモデル、いわゆる統合サービス（ＩＳ）インターネットが現在提案されており、ＩＥＴＦ（インターネットエンジニアリングタスクフォース）統合サービス作業グループによって呼びかけがアドレスされている。
【００１１】
ＩＳインターネットは、特定のＱｏＳ規定をもつ多数のサービスクラスを支援する。
【００１２】
主要なサービスクラスとして：
・保証されるバンド幅を支援し、遅延範囲(delay bound)を十分に規定した保証されたサービス（Guaranteed Service、ＧＳ）；
・バンド幅保証をより緩めて支援する制御されるロード（Controlled Load、ＣＬ）；および、
・従来の最善を尽くす（Best Effort、ＢＥ）サービスクラスが提案されている。
【００１３】
フロー(flow)という用語を使用して、所定のアプリケーションによって生成され、特定のＱｏＳ要求で送られる1または複数のパケット流を示す。
【００１４】
異なるサービスクラスの用意と提供を支援するために、現在のＴＣＰ／ＩＰプロトコルの総合ソフトウエアパッケージ(suite)とは対照的に、ＩＳインターネットでは全てのネットワークルータにおけるフロー状態情報が必要である。
【００１５】
これまで正式な解析は保証されたサービスクラスに集中しており、保証されたサービスクラスについてはＣＡＣアルゴリズムにおけるトークンのバケットトラヒック記述子とWeighted Fair Queuing（ＷＦＱ）のようなスケジューリング方法を使用することによって保証される遅延範囲を満足させることが提案されている。絶対的な遅延範囲はこの解決案によって保証されるが、それらは著しく悲観的であり、一定の環境のもとでは、不必要に処理が複雑になる（すなわちいくつかの環境のもとでは、複雑さが加わることのほうが潜在的な効果よりも勝ってしまうことがある）と考えられる。
【００１６】
このようなときは、より現実的な遅延範囲を与える別のより簡単な解決案が切望されることになる。
【００１７】
将来のネットワークに対する保証されるサービスの潜在的に望ましくない態様および複雑さは次のものを含む：
・バンド幅のコンテンションではなく、時間コンテンションの条件のもとでＧＳが実行されているとき、ＷＦＱによって行われる遅延制御は非常に小さいものとなる（すなわち、統計的多重化効果はない）。
【００１８】
・ＷＦＱはバンド幅の共有と厳密なフローの分離を行なうが、これは、バッファのバックログ範囲が低減するか、または適切な上限値がデータグラムの最大の大きさとされるか、あるいはこの両者のときに必要なくなることがある。
【００１９】
・ＧＳクラス内の統計的多重化効果が、トークンのバケットトラヒック記述子に基づく複雑なＣＡＣを要求する。
【００２０】
・資源確保セットアッププロトコル（ＲＳＶＰ）のシグナリングが、要求された二地点間の遅延範囲を支援できるか否かを確定するのに要求される。
【００２１】
・現在ＷＦＱはフロー毎に適用されているのでコンピュータ処理上集中してしまい、ネットワークの速度が増加するとき、またはデータグラムの大きさが低減する（データグラムのスケジューリングをコンピュータ処理する時間が低減する）とき、あるいはこの両者のときに、潜在的な動作のボトルネックを導くことがある。
【００２２】
さらに従来、遠隔通信ネットワークはネットワーク使用パターンおよびトラヒック統計がよく分かっていて、さらに比較的に安定したパラメータを使用していることに基づいて設計されてきたが、インターネットの発展により、現在ではこれらのパラメータが次第に不確かになってきている状況のもとで使用されていることが明らかになってきている。
【００２３】
したがって将来のネットワーク設計はこのパラメータの不確かさに対処するのに十分にエラー強さがなければならないが、不必要に複雑なネットワーク制御技術を使用するといった犠牲を払うべきではない。しかしながら上述の指摘は、ＱｏＳの実行を保証する領域においてそれが発生する可能性が十分にあることを示唆している。
【００２４】
【発明が解決しようとする課題】
本発明にしたがって、パケットネットワーク素子であって、フローベースのパケットを受取る少なくとも1つの入力と；所定のバンド幅の少なくとも１つの出力とを備え、ここでは受取ったパケットは第１および第２のサービスクラスと関係しているものであるとし；さらに各受取ったパケットをそのサービスクラスに基づいて、第１または第２の対応するパケットバッファへ向ける手段とを含み；なお前記第1のパケットバッファは出力バンド幅の所定の部分に割り当てられ；また前記第２のパケットバッファは出力バンド幅の残りの部分に割り当てられており；このパケットネットワーク素子は、前記第1のクラスのフローと関係するバンド幅要求を判断するバンド幅要求判断手段と；前記バンド幅要求を満たすことができると、第１のパケットバッファに向けて第1のクラスのフローパケットの受け付けを許可する手段と；第１および第２のパケットバッファから出力へパケットを向ける手段とを含むパケットネットワーク素子を提供する。
【００２５】
このやり方では、比較的に簡単なネットワーク素子のアーキテクチャが従来の接続指向ネットワークに関係するサービスに類似するサービスを第１のクラスのパケットに提供するが、従来のコネクションレスネットワークに関係するサービスに類似するサービスを第２のクラスのサービスに提供することが好都合である。
【００２６】
好ましくは、受け付けを許可する前記手段は、ピークレート試験を適用して、出力バンド幅の前記所定の部分中の現在使用されていない部分が前記ピークレートのバンド幅要求を満たすことができるときには、第１のバッファへの受け付けを許可するように動作する。
【００２７】
ある環境においては、この手段が固定された遅延範囲を定式化し、併せてより複雑な仕組みのスループットを制限するような潜在的な処理のボトルネックを避けることができることとしている。すなわち第１のパケットバッファに受け付けられる第１のクラスのフローパケットは保証された遅延範囲を与えられることになる。さらにこれはフローごとにスケジューリングせずに達成されるので、大きいネットワークを構築する際に直接的で認識されている関心事とされているスケーラビリティを与える。
【００２８】
より一般的に応用可能な実施形態においては、受け付けを許可する前記手段は前記ピークレート試験を適用し、バッファ充填試験を適用するように動作し、前記第１のパケットバッファが別のフローを受理するのに十分なスペースをもつときに受け付けを許可する。
【００２９】
このような実施形態の長所は、少数の第１のクラスのフローのみが素子によって処理されるときでも、前記受け付けを許可する手段が保証される遅延範囲を用意できることである。バッファ充填試験は多数の第１のクラスのフローを処理する高速度のコアネットワーク素子では不必要である可能性が高い。
【００３０】
好ましい実施形態では、前記受け付け許可手段は、第１のパケットバッファを収容できる大きさにされたフロー数から現在収容されているフロー数を減算した数が少なくとも1であるとき、および第１のパケットバッファに割り当てられた出力バンド幅の使用されていない部分から提案されたピークレートのフローのバンド幅要求を減算した数がゼロに等しいかまたはそれよりも大きいときのみ、第１のパケットバッファに対して第１のクラスのフローパケットの受け付けを許可するようにされている。
【００３１】
このやり方では、第１のパケットのバッファに対して受け付けられた第１のクラスのフローパケットに保証された遅延範囲を与えるように、より特定の受け付け制御規則を実行してもよい。
【００３２】
第１のクラスのフローパケットが第１のパケットバッファに対して受け付けを拒否されたとき、第１のクラスのフローパケットを第２のパケットバッファに受け付ける手段を用意することがさらに好ましい。
【００３３】
このやり方では、受け付け制御用に‘soft failure’を用意して、第１のパケットバッファに受け付けられなかったパケットが、フローの継続期間中またはこれらのパケットが第１のバッファに受け付けられるときまで、第２のパケットバッファに受け付けられるようにしてもよい。
【００３４】
いくつかの実施形態では、受取ったパケットが第１または第２のサービスクラスと関係するか否かを判断するクラス判断手段をもつ。所定のクラスのパケットとの関係が、例えばパケットが到達するインターフェイスから判断できないときにこのクラス判断手段を素子内に用意することが必要とされる。
【００３５】
前記クラス判断手段は、前記受取ったパケットからクラス識別部分を読み取るようにされていることがさらに好ましい。
【００３６】
このやり方では、‘オン−ザ−フライ  シグナリング’を実行して、別々のネットワークシグナリング段階の必要性を効果的になくすことができる。
【００３７】
前記バンド幅要求判断手段が、前記受取ったパケットからピークレートのフローバンド幅要求情報部分を読み取るようにされていることがさらに好ましい。
【００３８】
ここでもこのやり方では、‘オン−ザ−フライ  シグナリング’を実行して、別々のネットワークシグナリング段階の必要性を効果的になくすことができる。
【００３９】
前記バンド幅要求判断手段は、各単一のパケットフローに対する特定のピークレートのフローバンド幅要求値を判断するようにされていることがさらに好ましい。
【００４０】
このやり方では、単一のパケットフローは特定の処理に対してフラグを立てられる。
【００４１】
本発明の第２の態様にしたがって、パケットネットワークと関係して使用するホスト素子であって：パケットベースのフローを生成し、各フローをそれぞれ選択された関係する第１または第２のサービスクラスと関係付ける手段と；第１のサービスクラスと関係するパケットを受取るようにされた第１のパケットバッファと；第１のパケットバッファの大きさを制御する手段と；第２のサービスクラスと関係するパケットを受取るようにされた第２のパケットバッファと；第１および第２のパケットバッファから、第１のクラスのパケットフローレートが選択されたピークレートバンド幅を超えないことを確保するようにされている出力へパケットを向ける手段とを含むホスト素子を提供する。
【００４２】
このやり方では、ホストアーキテクチャは厳密に範囲を定められたピークレートをもつフローを生成して、より複雑なトラヒックの記述子の必要をなくすことが効果的である。
【００４３】
選択された関係する第１または第２のサービスクラスを前記パケットのクラス識別部分へ書き込む手段を用意することが好ましい。
【００４４】
このやり方では、‘オン−ザ−フライ  シグナリング’を行なって、効果的に別個のネットワークシグナリング段階の必要をなくすパケットを生成することができる。
【００４５】
さらにピークレートのフローバンド幅要求情報を前記パケットのピークレートのフローレートバンド幅要求部分へ書き込む手段を用意することがさらに好ましい。
【００４６】
ここでもこのやり方では、‘オン−ザ−フライ  シグナリング’を行なって、パケットを生成して、効果的に別個のネットワークシグナリング段階の必要をなくすパケットを生成することができる。
【００４７】
ここで本発明の実施形態を添付の図面を参照して例示的に記載することにする。
【００４８】
【発明の実施の形態】
送り側の送信ホストと受け側の受信ホストとは、素子またはノード、および相互接続リンクを含むネットワークによって接続されている。送信ホスト上で実行されているアプリケーションはデータパケットまたはデータグラムを生成する。‘フロー’という用語は、１または複数のパケット流がアプリケーションによって生成され、かつ特定のサービス品質（ＱｏＳ）要件を備えつつ送られることを示すために応用されている。
【００４９】
各それぞれのフローのサービス要求は、関係するサービス品質（ＱｏＳ）レベルをもつ少なくとも２つの定義されたサービスクラスの１つ、一般的にいわゆる範囲を定められた遅延クラス(bounded delay class、ＢＤクラス)またはいわゆる最善を尽くすクラス(best effort class、ＢＥクラス)の１つとしてネットワーク内で伝送するために選ばれる。
【００５０】
フローが範囲を定められた遅延ＢＤモードでネットワーク内で伝送されるとき、ネットワークは最大の規定の遅延によって範囲を定められた時間中に構成パケットを二地点間で伝送できなければならない。フローが最善を尽くすモードでネットワーク内で伝送されるときは、ネットワークは最大の遅延範囲を特定せずに構成パケットを送る。
【００５１】
これらのモードの何れを使用するかを選択するのは、送信ホスト上で実行されるアプリケーションの役目である。
【００５２】
代わりのアーキテクチャの多数のネットワーク素子またはノードは、図１（ａ）ないし１（ｄ）に示した。これらの素子またはノードは、例えば周知のルータ技術を使用して構成され、典型的な例はＣｉｓｃｏ  Ｉｎｃ．から販売されている。
【００５３】
図１（ａ）に示したネットワーク素子（１）では、１以上のパケット入力ポート（２）が入力リンク（図示されていない）に接続されて、パケットベースのフローを受取っている。
【００５４】
各ネットワーク素子（１）は遅延範囲を定めたネットワーク動作モードまたは最善を尽くすネットワーク動作モードを支援するので、モード識別器（３）を用意して、パケットが関係する２つのモードの一方で入力（２）から受取ったかを各パケットについて判断し、そのパケットを適切なパケットバッファへ向ける。全ての入力ポートに単一モードの識別器（３）を用意してもよく、またはその代わりに２以上のモードの識別器（３）を用意してもよい。
【００５５】
所定の大きさをもつ1以上の第１のパケットバッファ（４）は、範囲を定められた遅延（ＢＤ）動作モードと関係付けられ、一定数のフローを収容する大きさにされていて、1以上の関係するパケット識別器（５）をもち、バッファ（4）の１つを受け付ける前にパケットはこのバッファ（４）の特定の１つを通る。
【００５６】
次にこのパケット識別は処理素子（６）内で別の処理を開始することができる。この別の処理の結果として、第１のバッファ（４）の１つに対して新しいフローのパケットを受け付けるか否かに関して受け付け判断、一般的には、コネクション受け付け制御（ＣＡＣ）判断をすることができる。
【００５７】
所定の大きさをもち、最善を尽くす（ＢＥ）動作モードと関係している１または複数の第２のパケットバッファ（７）は、モード識別器（３）から１または複数のバッファ（７）に向けられた‘最善を尽くす（ＢＥ）’パケットを記憶する。‘範囲を定められた遅延（ＢＤ）’パケットも、後述するように第１のパケットバッファへの受け付けを拒否されたときに、第２のパケットバッファへ向けることができる。
【００５８】
第１および第２のバッファ（４，７）のそれぞれは、バッファを完全に使用する素子(buffer playout element)（８、９）をもち、バッファを完全に使用する素子（８、９）はそれぞれ１以上のスケジューリング素子（10）によって制御される。各スケジューリング素子（10）は、適切なスケジューリングアルゴリズムによって制御される。
【００５９】
各バッファを完全に使用する素子は出力ポート（11，12）へ接続され、出力ポート（11，12）は出力リンク（図示されていない）と接続している。
【００６０】
物理的に別個の出力ポートではスケジューリングは、実際は各バッファ完全使用（8，9）の完全に独立したスケジューリングを変える。
【００６１】
１以上の範囲を定められた遅延バッファ（４）および１または複数の最善を尽くすバッファ（７）と関係する出力ポート（11，12）はそれぞれ、全出力バンド幅のうちの所定の割り当て分を与えられる。
【００６２】
上述のように、図１（ａ）には実質的に入力（２）を１つだけ示したが、このようなネットワーク素子（１）はそれぞれ多数の入力（２）をもち、いくつかのホストまたは他のネットワーク素子からフローを受取ることができることは明らかである。
【００６３】
同様に、ネットワーク素子（１）は多数の出力（11，12）をもち、したがって単一の範囲を定められた遅延バッファ（４）が各範囲を定められた遅延モードの出力ポート（11）について、また同様に最善を尽くすバッファ（７）用に存在することになる。
【００６４】
関係する出力リンク（図示されていない）が物理的に別個であるとすると、スケジューリングは完全に独立なものとなる。しかしながら範囲を定められた遅延トラヒックおよび最善を尽くすトラヒックに対する出力リンクが単に見かけ上実質的に（バーチャルには）別々であるとき、技術に依存して、一定の範囲の多重化オプションそれ自体が存在してもよい。
【００６５】
さらに加えて、範囲を定められた遅延バッファおよび最善を尽くすバッファ（4，7）は物理的にではなく、見かけ上実質的に別々であってもよいことに注意すべきである。
【００６６】
図１（ｂ）に記載したネットワーク素子（13）は図１（ａ）に示したものと類似しているが、1以上の第１および第２の入力ポート（14，15）を備えている。したがって、その結果図１（ａ）に明示したモード識別器（３）は、入力（14，15）の組として、それ自体が利用される必要はなく、また範囲を定められた遅延モードおよび最善を尽くすモードとそれぞれ関係していると考えられてよい。（すなわち、図１（ｂ）の装置はモード識別器を必要としない。その理由は、入力（14）はＢＤトラヒックのみを、また入力（15）はＢＥトラヒックのみを運んでおり、モードはパケットが到着する入力から判明するからである。）しかしながら図１（ａ）に示したモード識別器（３）は依然として、全ての到来するパケットが正しいモードであることを確保する規制(policing)機能で働くのに効果的である。
【００６７】
したがって範囲を定められた遅延モードと関係している各第１の入力ポート（14）は、図１（ａ）に関して既に記載したように、範囲を定められた遅延バッファ（18）に接続する前に、関係する追加の処理素子（17）と接続されているパケット識別器（16）に直接に接続される。最善を尽くすモードと関係している各第２の入力ポート（15）は最善を尽くすバッファ（19）と直接に接続される。
【００６８】
図１（ａ）に関して述べたところと同様にここ図１（ｂ）でも、範囲を定められた遅延バッファおよび最善を尽くすバッファ（18，19）は関係するバッファを完全に使用する素子（20，21）を介してスケジューリング素子（22）と接続されており、さらにそれぞれ各範囲を定められた遅延ポートおよび最善を尽くす出力ポート（23，24）に接続されている。
【００６９】
図１（ｃ）に示したネットワーク素子（25）は、入力、パケット識別器、追加の処理、範囲を定められた遅延バッファ素子および最善を尽くすバッファ素子（26，27，28，29，30，31）に関して図１（ｂ）に示したものと類似しているが、範囲を定められた遅延モードおよび最善を尽くすモードと関係する１組のみが出力ポート（32）を送られていることが異なる。このような各出力ポート（32）には、２つのバッファ構造（30，31）が用意される。したがって各出力ポート（32）において、各範囲を定められた遅延バッファおよび最善を尽くすバッファは、スケジューリング素子（34）の制御のもとで、1つのバッファを完全に使用する素子（33）によって完全に使用され、次にこの単一の出力ポート（32）に接続される。
【００７０】
２つのバッファ（30，31）は同じ出力ポート（32）を共有しており、完全使用の完全に独立したスケジューリングは不可能であるので、バッファ完全使用素子（33）を制御するのにより複雑なスケジューリングアルゴリズムが必要となり、実行にあたって2つのモード間の対話が行われることになる。一連の適切なスケジューリングの解決案が知られている。
【００７１】
第１のバッファ（30）が少なくとも１つのパケットを含むとき、簡単な優先スケジューリングは常に第１のバッファ（30）から次のパケットを選択する。このやり方では、完全なパケットに対して第１のバッファ（30）に最も可能性の高いサービスを与えられる。範囲を定められた遅延トラヒックが全トラヒック中に占める割合が低いとき、最善を尽くすトラヒックにおける範囲を定められた遅延トラヒックの影響は比較的にわずかとなる。
【００７２】
リンクの速度による除算がされた、最大の最善を尽くすパケット長により与えられる値は、ノードごとの遅延範囲の特定の値と比較して小さいか、または許容可能な範囲内で低い値のとき、最善を尽くすトラヒックの振る舞いは範囲を定められた遅延クラスのトラヒックにほとんど影響を与えないと考えられる。これに当てはまらないときは、‘サスペンド再稼動’スケジューリングは単一の優先スケジューリングの代わりであると考えられることができる。
【００７３】
最善を尽くすパケットの‘サスペンド再稼動(suspend-resume)’スケジューリングにより、範囲を定められた遅延パケットが送信可能になると直ぐに、最善を尽くすパケットの送信をサスペンドすることができる。したがって最善を尽くすパケットは、範囲を定められた遅延パケットを収容するようにデータリンク層上で効果的に分割される。
【００７４】
最後に、図１（ｄ）に示したネットワーク素子（35）は、図１（ａ）に示したものと類似する１以上の第１の入力（36）、モード識別器（37）、関係するパケット識別器、追加プロセッサ、範囲を定められた遅延バッファ構造、および最善を尽くすバッファ構造（38，39，40，41）を含み、さらに加えて図１（ｃ）に示したものと類似する１組の出力（42）、単一のバッファを完全に使用する素子（43）、およびスケジューリング素子（44）を含む。
【００７５】
ネットワーク素子（1，13，25，35）が範囲を定められた遅延の動作モードを与える能力は、全ての競争する(contending)フローのピークレートの和が範囲を定められた遅延トラヒックに割り当てられる出力バンド幅の一部分を超えないことを保証することに依存することが明白である。フローごとにピークレートのバンド幅を特定することは、ホストの出力リンク速度が特定のピークのバンド幅に制約されるが、パケット分割時間に関係してトラヒックを形成するようにフローを生成するホストに要求することを意味すると考えられる。ピークレートの和を制御する手段は、適切な大きさにされるか、またはＣＡＣ規則を適用してもよい。しかしながらピークレートの和の制御は必要であるが、範囲を定められた遅延の動作を行なう十分条件に常になるわけではない。素子の特定の構成に依存して、範囲を定められた遅延フローの数およびパケットの大きさを制御することも必要である。
【００７６】
次に示す式１Ａおよび１Ｂは素子に対するマルチパケット遅延範囲を表わし、なお式中のlink rateは検討している出力リンクの動作速度であり、mux ratioは出力ポートリンク速度対入力ポートリンク速度の比であり、Ｎｉｐは範囲を定められた遅延（ＢＤ）クラスのフローを保持し、出力リンクをドライブする入力ポート数であり、Ｎｆｌｏｗは範囲を定められた遅延フローの最大数であり、Ｉｍａｘは範囲を定められた遅延クラスパケットの最大の大きさであり、Ｉｂｅは最善を尽くすパケットの最大の大きさである：
【数１】
0004201978.tif 000002
【００７７】
ＣＡＣ規則を使用して式１Ａおよび１Ｂまたは類似の式をピークレートのバンド幅制御と一緒に理解することができ、特定の遅延範囲を侵害することなく受け付けることができるか否かに関して新しいフローを試験できることが明らかである。これらの特定の式は、入力ポートを通るフロー分配の最悪の場合を表わしている。
【００７８】
式１Ａおよび１Ｂは、一定の範囲の状況に適用するのに十分に普遍的である。しかしながら重要な一定の特定の場合において、式１Ａおよび１Ｂを簡単な形に約して、例示的に２つの例を与える。各例において、項ｌｂｅ/link rateは無視でみるほど十分に小さいと考えられる。
【００７９】
mux ratio＝Ｎｉｐのとき：、式１Ａを次のように約すことができる：
Ｉｍａｘ・Ｎｉｐ／link rate          （式２）
この場合、この素子の遅延は自動的に範囲を定められ、フローの実際の数を知らなくても遅延範囲を設定することができる。これはアクセスノードの場合を表わし、出力(outgoing)リンク上の実効バンド幅は、範囲を定められた遅延トラヒックを支持する全ての到来リンクのバンド幅の和を収容する大きさにされる。
【００８０】
mux ratio＝１、およびＮｆｌｏｗ＞＞Ｎｉｐ＞＞１のとき、式（１Ｂ）
は次の式３に近似する：
Ｉｍａｘ・Ｎｆｌｏｗ／link rate          （式３）
式３は、バンド幅の等しい入力および出力リンクと、（例えば）４以上の組の入力および出力ポートとをもつコアネットワークノードの場合を表わすことができる。この場合に、範囲を定められた遅延動作は最早自動的ではなく、ある程度の制御は、範囲を定められた遅延クラスに受け付けられるフローにおいて遅延範囲を保証することを確実にするために必要とされる。
【００８１】
ピークバンド幅のＣＡＣ試験は式４によって表わすことができる：
（Ｐｋ fｌｏｗ＋Ｐｋ ａｃｃｕｍ／Ｐｋ ａｌｌｏｃ）＜ｌ      （式４）
Ｐｋ ｆｌｏｗは範囲を定められた遅延（ＢＤ）クラスに対する受け付けを要求する新しいフローのピークバンド幅であり、Ｐｋ ａｃｃｕｍは全ての現在受け付けられているＢＤフローのピークバンド幅の和であり、Ｐｋ ａｌｌｏｃはＢＤトラヒックに割り当てられた合計バンド幅である。式４は、新しいフローと現在受け付けられているフローのピークバンド幅の和が割り当てられたバンド幅を超えないことを検査するときに新しいフローに対して行われる試験を記載している。項Ｐｋ ａｌｌｏｃがリンクレートよりも小さくなるように選択されると、最善を尽くすクラスに対する一定レベルのバンド幅を保証することができる。
【００８２】
式（２）によって記載された場合において、Ｎｉｐおよびｌｍａｘに既知の制限を与えるとき、式（４）によって記載された試験はＣＡＣに唯一の必要条件である。
【００８３】
式（３）によって記載される場合において、ピークバンド幅試験を適用することに加えて、ＣＡＣプロセスがＮｆｌｏｗをある値、すなわちＮｆｌｏｗ ａｌｌｏｃに制限して、遅延範囲を確立することも必要である。しかしながら、最小値のピークバンド幅Ｐｋ ｍｉｎ、すなわちフローを関係付けることができる最小のピークバンド幅を定めることによって、ピークバンド幅のＣＡＣ条件を適用することによって、Ｎｆｌｏｗ ａｌｌｏｃは潜在的に制限される。したがってＮｆｌｏｗ ａｌｌｏｃはＰｋ ａｌｌｏｃ／Ｐｋ ｍｉｎに制限され、遅延範囲Ｔｂｏｕｎｄは次に示す式（５）によって表わすことができる：
Ｔｂｏｕｎｄ＝ｌｍａｘ・Ｎｆｌｏｗｓ ａｌｌｏｃ／link rare       （式５）
この例では、要求される遅延範囲はｌｍａｘおよびＰｋ ｍｉｎを特定することによってネットワークオペレータによって選択できることが明らかである。
【００８４】
ある条件では、各個々のフローにおける最大パケットの大きさの知識を使用することによってＢＤクラスをよりよく使用することが望ましい。したがってピークバンド幅要求を示すことに加えて、各フローは、最大パケットの大きさを特定することができ、ｉ番目のフローはｌｉｍａｘで表わすことができる。ネットワーク素子において、入力および出力リンク速度が等しく、異なるフローの最大パケットの大きさの差を考慮に入れるとき、式（３）のより一般的な形によって遅延範囲に近似することができる：
【数２】
0004201978.tif 000003
【００８５】
なお、和はバッファに受け付けられた全てのフローよりも大きい。この場合に、フローの明白な制御がここでは必要である。したがってピークレート試験に加えて満たされなければならないパケットの大きさに別のＣＡＣ条件を加えることによってこれを達成することができる。
【００８６】
（ｌｉｍａｘ＋ｌｍａｘ ａｃｃｕｍ）／ｌａｌｌｏｃ＜１      （式７）
なお、ｌｍａｘ ａｃｃｕｍは現在受け付けられている全ＢＤフローの最大パケット長の和であり、ｌａｌｌｏｃはフローの最大パケット長についての最大許容和である。これはネットワークオペレータによって選択されて、特定の遅延範囲を確保できること、およびＢＤの待ち行列に対するバッファ充填についての限界範囲に対応していることは明らかである。
【００８７】
ＢＤクラスにして複数のパケットフローを受け付けるＣＡＣ規則をさらに検討すると、単一のパケットフローの特定の場合に対してこれらのＣＡＣ規則をわずかに変更することが必要なことが明らかになる。式（２）と関係する条件において、ＣＡＣプロセスは新しいフローを受け付けるのに予備のバンド幅が十分にあるか否かを検査するが、連続するピークレートのパラメータに関して単一のパケットフローを記述するコンセプトには意味がない。それにも関わらず、単一のパケットと同じくらい短いフローを受け付ける手段は、ＢＤクラスに割り当てられるバンド幅を超えないことを保証することが必要とされる。１つの適切な技術では、フローの停止後適切な時間をおいてピークレートを割り当てる。ピークバンド幅の値を選択するのに種々の可能性があり、その１例では上述のＰｋ ｍｉｎのコンセプトを使用する。特定のＰｋ ｍｉｎ値はネットワーク設計プロセスの一部として選択することができ、そこでＣＡＣは単一のパケットフローに対するバンド幅パラメータとしてこの値を使用するように前もって構成されているが、特殊状態では他の値も使えるように、ＣＡＣをデフォルトで選択するようにしている。これらの実行条件のもとでは単一のパケットに対するバンド幅受け付け試験は、（式４内の）Ｐｋ ｆｌｏｗをＰｋ ｍｉｎに置換したことを除いて、複数のパケットのフローに対して記載したのと全く同じである（式８参照）：
（Ｐｋ ｍｉｎ＋Ｐｋ ａｃｃｕｍ／Ｐｋ ａｌｌｏｃ）＜ｌ      （式８）
式（３）と関係する条件では、ＣＡＣはさらに使用可能な予備のバッファスペースが十分あるかを検査し、式（７）によって記載されたＣＡＣ規則を適用する。フロー数を潜在的に制限するこのタイプのＣＡＣ規則は依然として単一のパケットフローに対して、加えて既に記載したＰｋ ｍｉｎのコンセプトを使用してネットワークに対して、式（７）は１以上のパケットフローに直接に応用できる。
【００８８】
しかしながら、独立した２つの試験のＣＡＣの解決案は、Ｐｋ ｍｉｎの解決案を使用して可能であったときよりもＣＡＣ方法をより精巧にできると考えられる。このようなＣＡＣ方法の1つの例では、ＣＡＣプロセッサで使用可能なバッファスペースおよびバンド幅の合計を維持して、予備のバンド幅の全てまたは一部分を各新しい単一のパケットフローに割り当てることである。予備のバンド幅の一部が割り当てられる場合は、その量は、例えばパケットの大きさと使用可能なバッファスペースの比に比例するようにすることができる。これらの解決案の何れを使用しても上述のＣＡＣ試験のいずれにも影響を与えず、単にＣＡＣのパラメータおよび値に対してわずかに異なる規定をもつ特定の例を生成するだけである。
【００８９】
この解決案では付加的な長所として、簡単なＦＩＦＯスケジューリングを使用して、ＷＦＱのような方式と関係する複雑で著しい処理オーバーヘッドを避けることもできる。ＦＩＦＯスケジューリングを使用するとき、ＦＩＦＯスケジューリングは、バンド幅共有の受理可能なレベルが全フローに対応するか否かも判断するので、パケットの大きさを最大にするという負担を荷うことがとくに重要である。
【００９０】
例示的に、新しいフロー中の最初のパケットを受取るとき、パケットを識別したパケット識別器（5，16，28，38）、それ自体は追加の処理を行なって、ピークレートのバンド幅要求を範囲を定められた遅延フローに関係付けることができる。この追加の処理には、例えばユーザによって提案された遅延要求に基づいて、バンド幅要求の計算を含んでもよい。
【００９１】
処理素子（6，17，29，39）における別の処理は、第１のバッファ（4，18，30，40）および関係する出力ポート（11，23，32，42）がＣＡＣ条件を満たすことができるか否かを判断でき、この結果新しいフローを第１のバッファ（4，18，30，40）に受け付けることができるか否かを判断できる。
【００９２】
所定のフローと関係するピークレートのバンド幅要求との間の識別は多数のやり方で実行できることが明らかである。
【００９３】
もとより、新しい範囲を定められた遅延フローはＣＡＣ規則のもとで第１のバッファへの受け付けを拒否される可能性がある。
【００９４】
この可能性に対処する１つの解決案では、ＣＡＣ規則によって拒絶されたフローパケットを第２のバッファに受け付け、最善を尽くすやり方で対処する。同時に適切な‘接続拒否’メッセージを資源へ中継することができる。同じフローからの後続のパケットは‘接続要求’シグナリング情報を送り続けて、最終的にフローが第１のバッファへ受け付けられる継続する可能性を確保することができる。
【００９５】
最も簡単な状況として、最悪の場合の遅延は、バッファが各受け付けられたフローからバックログされたフローを含むときにネットワーク素子において発生し、その結果最悪のケースの範囲は、各受け付けられたフローに対する最大パケットの大きさの和を出力リンク速度によって除算したものに等しい。したがって、範囲を定められた遅延クラスに対して最大の許可されるパケットの大きさを小さくすると、特定の遅延範囲を達成する一方で、収容可能なセッション数に逆比例する効果をもたらす。範囲を定められた遅延クラスに対して最大の許可されるパケットの大きさを選択するときのこの逆比例効果について検討する。
【００９６】
フローが受理されると、必要な状態情報をメモリ（図示されていない）に記憶され、フローが終了するまでメモリ内に維持され、フローが終了するまで、ソフト状態の方法または所定のパケット識別器によって消去プロセスを開始する。
【００９７】
ＢＤクラスのフローがネットワークへ受け付けられると、このパケットフローが単一であるか、複数であるかとは無関係に、バンド幅またはバッファスペース、あるいはその両者は効果的に確保され、フローが終了するときこれらの資源を解放しなければならない。確保された資源はタイムアウト機構または特定の要求によって解放することができる。特定の要求を使用する解決案の例には、フローの最後のパケットがノード内で追加の処理を開始して、確保された資源を解放するといったものがある。しかしながらフローはピークレートベースで受け付けられるので、最後のパケットを受け付けて特定の臨界値Ｔｒｅｌｅａｓｅに到達した後に時間をおかなければ、資源を再使用することはできない。Ｔｒｅｌｅａｓｅの値は可変であり、これは最後のパケットの大きさおよびフローのピークレートの両方に依存するからである。複数のパケットフローにおいて、Ｔｒｅｌｅａｓｅは式９に等しい：
【数３】
0004201978.tif 000004
【００９８】
しかしながら、ＢＤクラスに対して特定された最大の許可されたパケットの大きさがあるとすると、Ｔｒｅｌｅａｓｅは式１０を使用することによって、パケットの大きさとは無関係にすることができる：
【数４】
0004201978.tif 000005
【００９９】
しかしながらこれは資源の利用効率を低減する犠牲を払うことになり、実際の低減は最大の許可されたパケットの大きさに直接に依存する。しかしながらこの簡素化の長所は、ＣＡＣプロセスの一部としてＴｒｅｌｅａｓｅを計算でき、次にＣＡＣプロセスでは解放カウンタを作動し、Ｔｒｅｌｅａｓｅに等しい値に到達するとき、ｌｍａｘ ａｃｃｕｍの値をｌｉｍａｘ’に等しい量だけ低減し、Ｐｋ ａｃｃｕｍの値をＰｋ ｆｌｏｗに等しい量だけ低減できることである。
【０１００】
単一のパケットフローにおける解放手続きは、複数のパケットフローにおける解放手続きと同じであり、唯一の相違点はＴｒｅｌｅａｓｅを計算するときに、Ｐｋ ｆｌｏｗの項を適切なバンド幅の項と置換したことである。例えばＰｋ ｍｉｎ‘のコンセプトを使用するとき、既に記載したように、Ｐｋ ｆｌｏｗを使用する全資源を解放するコンピュータ処理は代わりにＰｋ ｍｉｎ‘を使用する。
【０１０１】
フローが受理されると、フローヘッダパケットに後続するフローパケットはフローのピークレートバンド幅要求の指示を保持する必要がないことは明らかであろう。
【０１０２】
既に記載したように、ピークレートのＣＡＣを使用する理由は、ピークレートのＣＡＣは最悪の場合のバッファの大きさにおいて決定論的な制限範囲を与え、最悪の場合のリンク遅延を、最大のパケットの大きさおよび同期するユーザの最大数の両方によって判断される値に加えるからである。したがってパケットの損失は最悪の場合の大きさにされたバッファを使用することによって防ぐことができ、リンクの遅延は、単に最大のパケットの大きさを適切に制限するだけで必要に応じて低減することができる。最悪の場合よりも小さいバッファを使用することにより、バッファのオーバーフローおよびその結果生じるパケットの損失の統計的な確率がもたらされる。
【０１０３】
パケット損失をゼロにし、これに加えて絶対的なまたは“最悪の場合”の遅延範囲、すなわち（何らかの故障以外の）何れかの条件のもとでこれまでに分かっている最大の遅延を行なうようにＣＡＣ規則を定義できることに注意すべきである。
【０１０４】
これまで“最悪の場合”と記載してきた制限範囲は、ノードへ入来するときのフローがピークレートに整形されたものであるときのみ有効であるので、このステートメントをわずかに限定化することが必要であるが、フローのパケット間のスペースはネットワーク全体に広まるにしたがって乱れる可能性が高いことがよく知られている。このため時折ピークレートを過渡的に増加することが生じ、理論上はある環境のもとでは“最悪の場合”の制限範囲が破られてしまうことがある。この結果（バッファは、最悪の場合の遅延範囲にぴったりと整合するように大きさを定められるときは）パケットが損失してしまうか、または（バッファが最悪の場合の遅延範囲よりも大きいときは）遅延が増加する。
【０１０５】
しかしながらよく設計されたネットワークでは、範囲を定められた遅延トラヒックのピークレートの和はスケジューラによって与えられた供給レートよりも幾らか小さい（これに関して言えば優先順位のある待ち行列は理想的である）とき、ピークレートにおけるこのような過渡的な変動は、遅延範囲を破られないように十分に制限される。事実、逆ではなく、多くの例では特定のノードにおける条件は、最悪の場合の範囲が統計学用語で過度に悲観的(overly pessimistic)といわれるようなもになる。
【０１０６】
したがって最悪の場合の遅延範囲は収容可能なフローの最大数が増加するのにしたがって、益々悲観的になるので、ＣＡＣが最悪の場合の遅延範囲を考慮に入れることは常に適切であるとは示唆されない。むしろ、ＣＡＣ規則をいくつかの場合において幾分緩和して、より多くのフローを受け付けることができるようにし、ノードの位置にしたがってＣＡＣを少なくとも３つのやり方で適用できると考えられる。
【０１０７】
要求される遅延範囲が、（例えば、低速度のリンクにおいて）ＢＤパケットの比較的に小さいバックログに等しいとき、受け付け制御は“ピークレートの和の試験”と“最悪の場合の遅延試験”の組み合わせに基づいている。
【０１０８】
個々のパケットのサービス時間が要求される遅延範囲と比較して十分に小さくなるようなリンク速度である場合には、統計学的に検討することにより、“ピークレートの和の試験”を適用する必要があるという結論を導き出すことができる。
【０１０９】
これらの2つの極端な試験の間で、受け付け制御は“ピークレートの和の試験”と“統計的な遅延範囲の試験”との組み合わせに基づくことが非常に適切である。“統計的な遅延範囲の試験”は、特定の遅延を超える可能性が一定の（小さい）値を超えるまで、フローを受け付けることに基づいている。
【０１１０】
さらに、ピークバンド幅の和の試験に関して、とくに多数のフローを運ぶことを意図しているノードに対して、統計的多重化効果を適用することが実際的であると考えることができる。したがって、ホストが若干の時間の間に特定のピークレートよりも低いレベルでトラヒックを生成することになるという知識または見込みに基づいて、全ての受け付けられたセッションに対するピークレートの和が、範囲を定められた遅延クラスのトラヒックに対する割り当てられたピークレートの和を超えることになる。
【０１１１】
将来のネットワークは、最善を尽くすトラヒックと遅延範囲を定められたトラヒックとを混合したものを支援する可能性が最も高いと予測され、この場合範囲を定められた遅延クラスに対するピークレートのＣＡＣの使用は、必ずしも劣悪なリンク使用に導く訳ではない。この理由は、最善を尽くすモードは所定の予め定められた割り当てから予備の範囲を定められた遅延モードのバンド幅を使用することに適応できるからである。したがって範囲を定められた遅延モードが合計バンド幅の保証される最大量を含み、最善を尽くすモードが保証される最小量を含み、平均すると、範囲を定められた遅延モード使用の統計によって判断されるよりも大きくなることを意味する。以下で開示するように、バッファ使用に関しても同様の状況が存在する。
【０１１２】
範囲を定められる遅延バッファはパケット損失を避けるように大きさを定められるとき、概してネットワークのみが範囲を定められる遅延トラヒックを支援する場合に、過度に大きい寸法にされることが明らかである。しかしながら両方の動作モードを支援するときは、必要に応じて最善を尽くすモードによって使用するために、使用されていないバッファスペースを解放することができる。この特徴は１例として、バッファ空間を回復／解放する尺度としてバッファ充填の特定のレベルを使用するように用いることができる。したがって合計のバッファ空間の寸法を定めて、パケット損失の一定の可能性を受理する必要なく、バッファ利用の合理的なレベルを達成できることになる。言い換えると、範囲を定められた遅延モードがパケットを損失する可能性を制限するのではなく、通常よくあるように、最善を尽くすモードが幾らかのバッファスペースを諦めることがある。
【０１１３】
図１（ａ）ないし１（ｄ）に記載したネットワーク素子の適切な組合わせを使用することによって、種々のネットワーク構造が得られ、図２（ａ）ないし２（ｃ）に記載したように、最善を尽くすモードと範囲を定められた遅延モードの両方を支援する。
【０１１４】
ここでも、ネットワーク素子に関して記載したように、送信ホストと受信ホスト間の単一の経路のみを示す一方で、実際にはネットワーク素子１ａ−１ｄはネットワークの多くの他の構成要素のノード（図示されていない）との接続をもつことになる。
【０１１５】
図２（ａ）において、図１（ａ）に基づく入来ノード（１）および図１（ｃ）のアーキテクチャに基づく出力ノード（25）は物理的に別々の各接続指向のネットワークとコネクションレスネットワークに接続することができる。
【０１１６】
図２（ｂ）は図２（ａ）のネットワークに類似したネットワークの例を示すが、図１（ｂ）のノードアーキテクチャ内に示した多数のノード（13）を使用して、図１（ａ）のノードアーキテクチャの入来ノード（１）と図１（ｃ）のノードアーキテクチャの出力ノード（25）とを接続している。
【０１１７】
図２（ｃ）は、図１（ｄ）のノードアーキテクチャ（35）にしたがって素子のみから形成されるネットワークを示している。
【０１１８】
ＣＡＣは、全てのノードにおいてではなく単一のノードかまたはノードのサブセットのみにおいて実行できることに注意すべきである。例えば入来または出力ノードのみにおいてＣＡＣを適用することが実際的である。
【０１１９】
本発明の重要な特徴は、範囲を定められた遅延モードのフローを設定するとき、遅延に関してネゴシエーションする必要をなくすことができることである。これはある地点へのネットワーク遅延を、全体的な二地点間遅延のごくわずかな部分になる程度まで低減することによって達成される。上述のように、いくつかの要素が素子の遅延に影響を与えるが、基本的にそれらは出力ポートリンクおよびバッファ充填の速度によって判断されるが、代わってこれは最大のパケットの大きさおよびＣＡＣ規則（すなわち、同期するユーザの最大許容数および統計的多重化効果レベル）に依存する。
【０１２０】
これらのパラメータの関数として関係する遅延の変化の模式的な例を図３（ａ）ないし３（ｃ）に記載する。
【０１２１】
図３（ａ）は、特定のネットワーク構成における全体的な二地点間遅延の構成要素部分を模式的に表わしており、この特定のネットワーク構成では例えば１キロバイトの最大パケットの大きさの接続モードのフローのみを支援し、２．５の統計的多重化効果比を使用する一定の範囲のリンク速度をもつ多数のネットワーク素子を含む。この特定の例において全体的な二地点間遅延はネットワークのリンク遅延によって占められていることが明らかである。
【０１２２】
しかしながら図３（ａ）と図３（ｂ）とを比較することによって、ＣＡＣが統計的多重化効果を防ぐときにこれらの遅延がどのくらい低減するかが分かり（すなわち、瞬間的なバンド幅要求は割り当てられた量を超えない）、さらに図３（ｃ）と図３（ｂ）とを比較することによって、パケットの大きさを５分の１にする追加の低減が達成される。これらの比較から、ある地点において全体的な二地点間遅延がリンク遅延からホスト遅延によって占められるように遷移することが直ぐに分かる。
【０１２３】
リンク遅延に影響を与える別の要素は、接続モード動作に割り当てられた合計バンド幅に比例する。例えば特定の例において、パケットの大きさを低減することにより達成される遅延低減は、範囲を定められた遅延クラスに割り当てられたバンド幅を全出力リンクバンド幅の１００％から２５％へ低減することによって表わすことができる。
【０１２４】
したがって上述のことから、動作の範囲を定められた遅延クラスについては、ゼロの統計的多重化効果（ピークレートの大きさを決めるバンド幅）、小さいパケットの大きさ、高リンク速度、および全体に対する割合が小さい、あるバンド幅割り当てといったものの組み合わせによりリンク遅延を最小に保つことができる。
【０１２５】
ホスト遅延によって支配されている領域もしくは形態（レジーム）内で動作する長所は、このアプリケーションがネットワークが関与する必要なしに、単に適切な動作条件を設定することのみによってそれ自身二地点間遅延を制御できることであり、もちろん最終的にこれはアプリケーションの要求に依存することになる。この例は、公称のデータフレームサイズの決定判断であってもよく、これは受け側のホストに対して使用されるものであり、しかもなお許容可能な遅延領域内にあり、フレーム充填／読み取り時間によって引き起こされる。もちろん本発明の用途はホスト遅延が主体となっている領域内の動作に限定されないことに注意すべきである。好都合なレジームは、例えば全ての遅延が等しいが、小さい値の場合にもたらされる。
【０１２６】
上述のように、所定のフローと関係するピークレートのバンド幅との間の識別は、多数のやり方で行なうことができる。ＩＥＴＦによって規定される資源確保セットアッププロトコル（ＲＳＶＰ）は、１つのこのような手段を用いる。ＲＳＶＰ経路およびＲｅｓｖシグナリングメッセージは、ＴｓｐｅｃおよびＲｓｐｅｃフィールドを使用して正規の動作をし、ＢＤクラスのフローおよびこのフローに対するピークレート要件Ｐｋ ｆｌｏｗを識別し、これらのシグナリングメッセージは受信側へ向け段階的に（ホップバイホップで）送られ、送信側へ段階的に送り戻される。式４で表わされるピークバンド幅のＣＡＣ規則を適用するノードについては、送信側へ送り返される各ホップは、要求されるバンド幅Ｐｋ ｆｌｏｗと既存の累積されたバンド幅Ｐｋ ａｃｃｕｍとの和を（送信側から受信側へ向かう方向の）出力ポート上でＢＤクラス（Ｐｋ ａｌｌｏｃ）に対して割り当てられた合計バンド幅と比較する。他の応用可能なＣＡＣ規則は類似のやり方で応用されることも保証することになる。
【０１２７】
ＣＡＣが成功するとすると、このフローのピークバンド幅Ｐｋ ｆｌｏｗおよび関係するフロー分類子(classifier)はノード内でＣＡＣ制御に使用される他のパラメータと一緒に記憶される。この状態は、正規としてＲＳＶＰメッセージによってリフレッシュされる。データパケットの受領を使用してこの状態をリフレッシュすることもできる。したがってこのソフト状態は、リフレッシュされないとき取り除かれ、またそれにより関係するバンド幅およびフローカウンタが修正されることになる。ＣＡＣを送ったフローの識別はトラヒックを規制し、さらにフローが停止するとき、キー使用パラメータにおける対応する変更が記録され、例えば正確なＰｋ ｆｌｏｗ値が出力ポートの合計Ｐｋ ａｃｃｕｍから取り除かれることを記録することを保証するのに要求されることは明らかであろう。ＩＰバージョン４に対するＲＳＶＰの確保は、フロー分類子として働く送信元アドレス／送信先アドレス／ポートの３つから成るもの（トリップル）によって識別される。ＩＰバージョン６は、フローＩＤと呼ばれる単一のフィールドの概念をもつ。送信側または受信側（アドレスの識別分類コード）、トラヒックタイプ（ポート番号／伝送プロトコル）、あるいは‘タグ（標識、tag)’のような他の識別子のグループに関係する他の分類子は周知であり、集約した分類子(aggregated classifier)を用意するのに使用することができる。多数のフローはＣＡＣおよび本発明のシグナリングプロセスにおいて、集約されたフローの合計ピークバンド幅を単に加算し、これを統合された分類子として記憶し、この集約した合計ピークバンド幅Ｐｋ ｆｌｏｗの値を次の下流ノードへ送るだけで容易に集約できる。モード識別プロセスは多くのやり方で達成でき、この場合は一般的な‘バンド外(out of band)’ＲＳＶＰシグナリングおよび分類プロセスの一部であってもよい。
【０１２８】
ＣＡＣが失敗するとすると、分類子状態は記憶されるが、資源は割り当てられない。この分類子状態を使用して、このノードにおいて到来するＢＤパケットをこのフローからＢＥバッファへ迂回して、このノードにおける他の受理されたＢＤフローを保護する。このフローがＣＡＣを送った下流ノードは依然としてこのパケットをＢＤクラスへ送り戻すことができる。ＲＳＶＰのメッセージングは、顧客が不完全な確保を知らされるか、または他のプロトコルあるいは診断ツールがこのフィードバックを行なうことができることを保証する。顧客はこの点でＢＤクラス要求の失敗によってフローを止めることを判断でき、この判断によって全てのノードにおける分類子状態はタイムアウトすることになる。ユーザがＢＤパケットを送り続けるとき、一定のノード（失敗したＣＡＣ）ではＢＤパケットはＢＥバッファを使用し、時間をおくと資源がそのノードにおいて使用可能になり、ＣＡＣプロセスをリフレッシュするとき、このフローはＢＤクラスに受け付けられることになる。これに対して多数のアルゴリズムが可能であるが、１例として、ノード内の失敗した(failed)フローが最初に失敗したものを最初に供給するやり方(First Failed First Served)に基づいてサーチされ、この新しく解放された資源を充填できるＰｋ ｆｌｏｗをもつフローを見付けることができる。最良のアルゴリズムは他の要素、例えば請求書発行モデル、異なるフロータイプの数、およびノードの目標使用に依存する。
【０１２９】
規制は全てのノードにおいて行われるか、あるいはトラヒックのマトリックスおよびＢＤクラス容量の割り当てられた量に対して十分な容量が割り当てられるときは、この遅延範囲を定められたネットワークの入来および出力ノードのみにおいて規制を行なうことができる。規制は、宣言された最大パケット長およびピークレート内で維持されるＢＤクラスフローを保証し、さらにパケット計数、確保方法、および請求書発行のような機能を実行するように働く。
【０１３０】
ルート変更の結果、異なるノードおよびリフレッシュ機構を使用するこのフローに対するパケットを使用して、新しいノード内でＣＡＣを呼び出し、一方でソフト状態は古いノードが予め確保しておいたバンド幅を戻したことを保証する。
【０１３１】
別の実施では、いわゆる‘オン−ザ−フライ’シグナリングを使用する。これは第１のパケットを使用して、このフローへ要求されるパラメータへシグナリングすることによって、ＲＳＶＰおよび関係する往復（一周）移動の遅延の使用を避けるものであり、１つの実行例を図４を参照して次に記載する。
【０１３２】
フローパケット（45）は、多数のフィールドを含むヘッダ部およびデータを保持するペイロード部（47）から成るように定められる。
【０１３３】
最初の２つのヘッダフィールド（48，49）は送信元および送信先アドレスを保持し、これらを使用して普通のやり方でネットワークにおいてパケットをルート設定する。他の周知のフィールドを含んでもよい。
【０１３４】
最も簡単な実施形態では、モード識別子フィールド（50）を使用して最善を尽くす遅延モードパケットと範囲を定められた遅延モードパケットとを区別する。パケット識別子フィールド（51）は特定の機能をもつパケットを示すのに使用される。
【０１３５】
１または複数の追加の処理情報フィールド（52）は、範囲を定められた遅延モードのフローに対してホストが選択した実効ピークデータレートのようなネットワーク素子情報を示すのに使用される。
【０１３６】
これらのヘッダフィールド（46）の全ては、アプリケーションによって特定することができる。その代わりにこのヘッダフィールド（46）は入来ノードによって範囲を定められた遅延ネットワークへ入力するときに特定することもできる。パケット（47）のペイロード部分はネットワークにおいて送信先ホストへ送られ情報を含む。
【０１３７】
このやり方では、図１に関係して記載したネットワーク素子の実施形態に関係して、モード識別器は受取ったパケット（45）のヘッダ内のモード識別子フィールド（50）を読み取ることによってモード識別を実行することができる。類似のやり方では、新しいフローの先頭パケットを使用してコネクション受け付け制御（ＣＡＣ）手続きを開始することができる。新しいフローの先頭パケットをパケット識別子フィールド（51）から識別したパケット識別子は、提案されたバンド幅要求によって、ピークレートのＣＡＣ判断を行なうときに、先頭パケットのヘッダバンド幅フィールド（52）から読み取ることができる。類似のやり方で他のこのようなパラメータを得ることができる。
【０１３８】
したがって‘オン−ザ−フライ  シグナリング’を使用して別々のシグナリング段階がなくても範囲を定められた遅延クラスのフローを確立することができる。
【０１３９】
同様に、さらに特定のパケット識別子を定義して、追加の処理のためにフロー内で中間のパケットを送って、必要に応じて二地点間遅延を動的に調節するアプリケーションをイネーブルすることができる。
【０１４０】
全てのパケットはＢＤクラスに対するモード識別子を含む。しかしながらモード識別器は第1の‘シグナリングパケット’からとって、分類子の一部として記憶（キャッシュ）して、分類子を整合するパケットを受取って、これを使用してパケットを正しいバッファへ入れると回復することができる。その代わりに、モードは特定の分類子、とくにＶＰＮ構成およびインターネット電話のような特定のトラヒックタイプに対してＢＤクラスを自動的に用意する集約された分類子にスタティックに構成することができる。
【０１４１】
‘オン−ザ−フライ  シグナリング’では、フロー内の第１のパケットはフローＰｋ ｆｌｏｗに対する関係するピークレートのバンド幅およびＣＡＣに必要な他のパラメータを含む。新しいフローは、上述と同じＣＡＣ規則を使用して二地点間経路上の各ノードにおいて受け付けることができる。フローがＣＡＣを失敗するとすると、失敗分類子状態は以前のようにインストールされるが、ここでは新しい‘ＣＡＣ失敗’メッセージが送信側へ戻される。これは新しいＩＣＭＰコードまたは他の手段であってもよい。加えて、‘ＣＡＣ失敗’フラグは第１のパケットヘッダ内で設定されるので、下流ノードおよび受信側も損失について知らされ、下流ノードはさらにＣＡＣ失敗メッセージを送り戻さず、このメッセージはそうでなければ送信側へスワンプ(swamp)する。分類子と整合し、ＢＤモードに設定されたフロー内の残りのパケットは、ＢＤバッファへ受け付けられるが、ＣＡＣ中にフローを失ったノード内でＢＥバッファを使用する。シグナリングパケットＰｋ ｆｌｏｗ値および他のＣＡＣパラメータをリフレッシュすると、ＣＡＣにおいて最初に失敗した時のルーティング変更、分類子状態のタイムアウト、および後の資源への受け付けに対処するのに使用できる。
【０１４２】
単一のパケットフローに関して上述で概略的に記載した解決案において、パケットヘッダ内でピークレート情報を伝える必要はないので、この情報を保持するのに通常使用されるフィールドは、ゼロといった定義されたデフォルト値に設定され、単一のパケットフローを示すのに使用することができる。
【０１４３】
今日のIP v 4プロトコルについては、ＴＯＳヘッダフィールドを使用するモードおよびパケット識別子コードを特定することによって上述の例を実行することができる。要求されるバンド幅はIP v 4オプションフィールド内に予め構成するかまたは配置してもよい。IP v 6において、モードおよびパケット識別子コードはフローＩＤフィールド内に位置付けられ、バンド幅要求は段階的に(hop by hop)拡張する（オプション）ヘッダ内に置くことができる。情報を送信側ホストへ送り戻す必要があるとき、適切なＩＣＭＰメッセージ、例えばフロー受け付けが拒否された、などを生成することができる。
【０１４４】
いくつかの形態のトラヒック処理能力は、使用されたアプリケーションのタイプおよび生成された同期するフロー数の両方に依存して送信側および受信側の両方のホスト端末内で求められる。したがって一般的にホストはネットワーク素子の２つのバッファリングをもつ性質を使用できると予測される。
【０１４５】
このようなホストアーキテクチャの構成例を図５に示した。ホストは、例えば適切なネットワークインターフェイスを設けた周知のユニックスワークステーションまたはＰＣ技術を使用して実行することができる。
【０１４６】
図５に示した一般的なホスト構成（53）において、アプリケーションＡ（54）は、範囲を定められた遅延クラスにおいて送られる1以上のフローを生成する。アプリケーションＡ（54）がこの動作クラスを使用するときは、一般的に例えばアプリケーションの実行速度ではなく、ホスト内の実行速度によって判断されるレートで、バーストパケットフローを生成し、範囲を定められた遅延バッファ（55）、バッファ割り当て、およびパケットの大きさの制御（56，57）は、フローを共有するための関係するスケジューリング素子（58）と一緒にホスト実行制御用に用意する。スケジューリング素子（58）は適切なスケジューリングアルゴリズム（59）によって制御される。
【０１４７】
ホストは原理的には同期して、範囲を定められた遅延フローおよび最善を尽くすフローの両方を実行することができるので、スケジューリングアルゴリズム（59）が範囲を定められた遅延バッファ（55）内で記憶されたパケットに最高の優先順位を与えるように設計されているという事実に完全に適応するように、最善を尽くすバッファ（60）が用意される。アプリケーションＢ（61）は、アプリケーションＡ（54）において示したバッファ割り当て（図示されていない）およびパケットの大きさ（62）において同様の制御を行なう。
【０１４８】
トラヒック形成（シェーピング）は遅延範囲を保証するフローの重要な態様であり、主としてこのトラヒック形成は、ネットワークへ入力されるのに先立ってアプリケーションによって生成されるパケット間の到達間時間を変更できるようにする。したがってパケットフローのバースト状態はトラヒック形成によって制御でき、この結果低い方のピークバンド幅がネットワークから要求されるか、さもなければ上述のような変更を行なう。実際はトラヒックシェーピングは単にネットワークバンド幅要求とホスト遅延との間のバランスであり、ネットワークバンド幅要求が増加するとき、ホスト遅延は低減する。今日、トラヒック形成は一般的にトークンバケットおよびリークバケットシェーパの何れかを使用して達成され、いくつかの例では両者を組み合わせて使用される。
【０１４９】
トークンバケットシェーピングはパケットバーストがネットワークへ入力されるのを防ぐことはできないが、バーストの大きさの範囲を限定することはよく知られている。したがってトークンバケット形成では、図７に示したようにパケットシーケンス（単一のパケットであってもよい）および隣のパケットシーケンスの始めから測定される時間期間において、瞬間値が計算されるとき、フローレートが特定のピークレートを瞬間的に超える可能性は無くならない。この定義に基づいて、フローに対する瞬間的なピークレートは式１１によって得られる：
【数５】
0004201978.tif 000006
【０１５０】
なお、ｌｐａｃｋｅｔはビット内のパケットの大きさであり、代数の和は特定の時間スパンによって含まれる全てのパケットにおける和、例えば図７内のｔ１ないしｔ５のようなものであると考えられる。
【０１５１】
使用されるシェーピングプロセスは、瞬間ピークレートが特定のピークレートを超えないとき、これを厳密なピークレート形成として次に記載する。
【０１５２】
従来のトークンバケット形成が厳密なピークレート形成を行なうことができない理由は、適切な数のトークンを使用できるようになると直ぐに、使用されたスケジューリングアルゴリズムによってパケットをネットワークへ入力できるからである。図６には、トークンバケットによって生成されるフローと、範囲を定められた遅延バッファの特定の瞬間的な充填に対するピークレート形成との間の品質上の比較を示した。式（11）にしたがって計算されるとき、厳密なピークレート形成によってフローが特定のピークレートを超えないようにするとき、フローＡとＣとの比較から、この特定の例においてトークンバケット形成フローが特定のピークレートを超えることが明らかである。出力フローは、トークンバケットが最初にトークンで満たされており、出力リンク速度が特定のピークレートよりも著しく大きいといった特定の形態をとることに注意すべきである。さらに、次の式（12）内のバケット充填レートｒおよびＰｋ ｆｌｏｗの項は両者とも特定のピークレートの同じ値に等しい。
【０１５３】
制御された量のパケットのバンチングが許容できるものになると予測されるが、いくつかの実施では従来のトークンバケットまたはリークバケットシェーピングではなく、厳密なピークレートシェーピングを使用することが好都合である。これは瞬間ピークレートにより密接な制御を与える。密接なピークレートシェーピングを達成する１つの方法を図６に示した：便宜上、図５に示した最善を尽くす素子は、シェーピングプロセスに寄与しない範囲を定められた遅延クラスからの素子と一緒に、取り除いてある。ピークレートシェーピングは、ネットワークへのフローレートが特定のピークレートを超えないことを保証できるようなやり方で、効果的にパケットの組のシェーピングを妨げる。これを満足させるスケジューリングアルゴリズムの良い例は、パケットをネットワークへ入力する判断が先行するパケットの大きさおよびこのパケットが送られた時間に基づいていることである。したがって先行するパケットτｎｌａｐｓｅの受け付けが式（12）の関係を満足させるので、スケジューリング素子は時間を経過するまで新しいパケットをネットワークへ受け付けない：
【数６】
0004201978.tif 000007
【０１５４】
なお、ｌｐａｃｋｅｔはビット内のパケットの大きさを表わし、ビット／秒でフローに対する特定のピークレートを表わす。上付き符号ｎは送られるパケットを表わし、上付き符号ｎ−１は先に送られたパケットを表わす。
【０１５５】
適切なバケットの大きさを与えられたトークンバケットシェーパを使用する厳密なピークレートシェーピングの実行は、現在使用されているものと異なるスケジューリング規則と関連して使用することも可能である。例えば範囲を定められた遅延クラスに対して特定の最大の許容されるパケットの大きさがあるとき、パケットレートシェーピングは、トークンバケットがいっぱいになるまでパケットを送ることができないといった規則と関連して、最大の許容されるパケットの大きさに等しいバケットの大きさを使用して達成される。バケットがいっぱいになると、トークンバケットが空になるか、またはバッファが空になるまで、バッファを完全に使用する。トークンバケットが再び完全にいっぱいになるまでは、パケットをこれ以上送らない、など。図６の品質上の比較において仮定される条件にこの解決案を使用して、フローＢによって示された組と類似する組が生成される。
【０１５６】
しかしながら、（ｒ，Ｔ）−スムーススケジューリングアルゴリズムに基づくシェーパを含むより一般的なタイプのシェーパは除外されない。
【０１５７】
使用されるシェーピングのタイプとは無関係に、図５のホスト構成（53）は、他の制御パラメータ、例えばパケットの大きさ、バッファ割り当て、およびピークフローレートと関連する適切なシェーパパラメータを選択することができる。しかしながらＩＰ統合サービスを支援しているネットワークにおいてこのホストが使用されるときは、トークンバケットシェーピングを使用することになり、全てでないとしても、ほとんどの他のパラメータおよびトークンバケットのパケットが、新しいフローに対して選択されてしまうと、定数として扱われる。この主な理由は、これらのパラメータのいくつかをネットワーク内で分配する必要があり、これはいつパラメータが変更されてもＲＳＶＰシグナリング段階を開始することを含むからである。これは、シグナリング遅延が変更を実行するレートを厳密に制限するので、フローを最初に設定するときは特に関係ない。これは、フローが確立されるとホストの実行と二地点間遅延との両方にアプリケーションをもつ制御を厳密に制限する。範囲を定められた遅延クラスを支援するネットワークを使用するときは除外される。
【０１５８】
範囲を定められる遅延動作を呼出す１つの簡単な実施形態において、ネットワークによって要求される唯一の情報は、フローの要求されるピークレートであり、これは‘オンザフライ’シグナリングによって用意することができる。したがって、アプリケーションはフローの寿命中にホストの実行をモニタし続け、要求される回数だけ、ネットワークを含む必要なく必要なバッファ割り当て、パケットの大きさ、パケットの放棄、またはパケットレートを調節することができる。したがってアプリケーションは、通常可能なホストの動作よりもはるかに多数のダイナミックな制御を行なう。例えばアプリケーションは、最初に選択されるデータレートに対して不十分なバッファの大きさを選択すると、パケットを放棄し、増加した遅延を犠牲にしてバッファの大きさを増加し、低減されたバンド幅効率を犠牲にしてパケットの大きさを低減する（単位時間当たりのヘッダは増加する）ことができるオプションをもつか、またはネットワークからより高いピークレートを要求することができる。
【０１５９】
上述の本発明の実施形態では範囲を定められた遅延クラスおよびコネクションレスの最善を尽くすクラスに関して記載したが、一定の範囲の別のサブクラスも可能である。
【０１６０】
例えば範囲を定められた遅延クラスに対して、このやり方を取り入れて、新しいフローがＣＡＣプロセスの一部として最大のパケットの大きさに信号を送るとすると、別々のクラスを2以上の特定の範囲のパケットの大きさに定義することができる。各パケットに対するバンド幅またはバッファ資源の割り当てを別々に制御することによって、受け付けられたフローごとにパケットの大きさを分配するための制御を行ない、これにより全体的なバンド幅遅延クラスのバンド幅使用を向上させることができる。このやり方の１つの潜在的な長所は、パケットの大きさが小さいフローを受け付ける可能性が向上することである。
【０１６１】
さらにサブクラスを設定して、範囲を定められた遅延の異なる値を用意することもできる。これは、主な範囲を定められた遅延待ち行列内の多数の仮想待ち行列にパケットを分けることによって達成することができる。
【０１６２】
最善を尽くすクラス内では同様に、ランダムのようなトラヒック管理様式の構成―すなわち初期検出（ＲＥＤ）、優先待ち行列、ＩＥＴＦ  ＩｎｔＳｅｒｖ、クラスベースの待ち行列（ＣＢＱ）、および他のこのような技術は除外されない。
【図面の簡単な説明】
【図１】  ネットワーク素子の異なるアーキテクチャの構成を示す模式図。
【図２】  図１に示したネットワーク素子を含む異なるネットワークアーキテクチャの模式図。
【図３】  異なるネットワーク構成の機能として、ネットワーク内の送信ホストと受信ホストとの間の関係する遅延を示すグラフ。
【図４】  図３に関係して使用する例示的なパケット構造を示す模式図。
【図５】  例示的なホストアーキテクチャ構造を示す模式図。
【図６】  ２つのトラヒック形成方法の比較を示す模式図。
【図７】  例示的なフローを示すグラフ。
【図１】
0004201978.tif 000008
【図２】
0004201978.tif 000009
【図３】
0004201978.tif 000010
【図４】
0004201978.tif 000011
【図５】
0004201978.tif 000012
【図６】
0004201978.tif 000013
【図７】
0004201978.tif 000014