JP4201978B2 - パケットネットワーク - Google Patents
パケットネットワーク Download PDFInfo
- Publication number
- JP4201978B2 JP4201978B2 JP2000511292A JP2000511292A JP4201978B2 JP 4201978 B2 JP4201978 B2 JP 4201978B2 JP 2000511292 A JP2000511292 A JP 2000511292A JP 2000511292 A JP2000511292 A JP 2000511292A JP 4201978 B2 JP4201978 B2 JP 4201978B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- flow
- class
- bandwidth
- buffer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/52—Queue scheduling by attributing bandwidth to queues
- H04L47/522—Dynamic queue service slot or variable bandwidth allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/52—Queue scheduling by attributing bandwidth to queues
- H04L47/521—Static queue service slot or fixed bandwidth allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/52—Queue scheduling by attributing bandwidth to queues
- H04L47/525—Queue scheduling by attributing bandwidth to queues by redistribution of residual bandwidth
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/56—Queue scheduling implementing delay-aware scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/6215—Individual queue per QOS, rate or priority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
- H04L47/627—Queue scheduling characterised by scheduling criteria for service slots or service orders policing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/6285—Provisions for avoiding starvation of low priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【発明の属する技術分野】
本発明は、パケットネットワークおよびその中の素子およびホストに関する。
【0002】
【従来の技術】
従来の接続指向ネットワークでは情報を送る前にユーザはシグナリングを実行するかまたはシグナリングを要求することによって回路を割り当てられる。回路は割当て段階中にユーザに特定の実行基準を満たすようにすることができ、これは一般的にコネクション(接続)受け付け規則によって制御される。したがって適切な回路が設定されると、ホスト間で特定のサービス品質(QoS)に関する情報を送ることができる。
【0003】
対照的に従来のコネクションレスネットワークは回路割り当てに対する要求はなく、コネクション受け付け制御を含まない。したがってネットワークの輻輳中に実行基準を満たすこと、およびサービス品質要求(例えば二地点間の遅延および遅延の変化)を満足させることを保証できない。
【0004】
したがって将来のネットワークは、従来の接続指向ネットワークによって提供されるサービスに類似するサービス、および従来のコネクションレスネットワークによって提供されるサービスに類似したサービスを支援する必要があることが益々明らかになってきている。さらに、これらのサービスに最低限の複雑さで、受け入れられる性能との折り合い(トレードオフ)のなかで支援されることが不可欠である。
【0005】
最近10年間では、将来の広帯域マルチメディアネットワークが非同期転送モード(ATM)技術および関係するネットワーク接続基準に基づくことになると考えられてきた。しかしながらATMネットワークは標準化の初期段階では接続指向型であって、ネイティブな本来のコネクションレスの動作モードを支援しないと決められた。さらにATM標準は、ネットワークについてもっと広い視野でとらえるよりも、サービスクラスの最適化に集中する傾向があった。例えばベアラ利用を最適化するのに、支援された各個々のサービスクラスについてバンド幅利用を最適化することは必ずしも必要ではない。概して、応用はネットワーク跡追いできるよりも、より迅速に発展している可能性が高いと思われる。
【0006】
将来のネットワークに対する従来のATMサービスがもつ潜在的な望ましくない態様および複雑性を次に示す:
・サービスクラス内の統計的多重化効果(stastical multiplexing)は、リークするバケット源のトラヒック記述子に基づく複雑なコネクション受け付け制御(CAC)を要求する。
【0007】
・セル損失をゼロにするのに必要なバッファの大きさが、統計的多重化効果を使用するときには確定的でない。
【0008】
・固定されたATMのセルの大きさが全てのサービスに適している可能性が低い。
【0009】
・交換ネットワークでは、トラヒックのタイプとは無関係にシグナリング段階が要求され、これはいくつかのタイプのコネクションレストラヒックを実行するときのボトルネックを発生することがある可能性を秘めている。
【0010】
・セルヘッダの大きさは、より高い層のプロトコルによって既に課されているバンド幅に加えられた別のバンド幅のオーバーヘッドである。(AAL5適用に対しては、セルヘッダは実効バンド幅の10%を無駄にしており、他のAALに対してこれよりも高い。)
従来のIPネットワークは、コネクションレス転送方法のコンセプトから発展しており、今日までのところユーザに唯一の“最善を尽くす(best effort)”サービスを提供している方法よりも発展している。しかしながら新しいサービスモデル、いわゆる統合サービス(IS)インターネットが現在提案されており、IETF(インターネットエンジニアリングタスクフォース)統合サービス作業グループによって呼びかけがアドレスされている。
【0011】
ISインターネットは、特定のQoS規定をもつ多数のサービスクラスを支援する。
【0012】
主要なサービスクラスとして:
・保証されるバンド幅を支援し、遅延範囲(delay bound)を十分に規定した保証されたサービス(Guaranteed Service、GS);
・バンド幅保証をより緩めて支援する制御されるロード(Controlled Load、CL);および、
・従来の最善を尽くす(Best Effort、BE)サービスクラスが提案されている。
【0013】
フロー(flow)という用語を使用して、所定のアプリケーションによって生成され、特定のQoS要求で送られる1または複数のパケット流を示す。
【0014】
異なるサービスクラスの用意と提供を支援するために、現在のTCP/IPプロトコルの総合ソフトウエアパッケージ(suite)とは対照的に、ISインターネットでは全てのネットワークルータにおけるフロー状態情報が必要である。
【0015】
これまで正式な解析は保証されたサービスクラスに集中しており、保証されたサービスクラスについてはCACアルゴリズムにおけるトークンのバケットトラヒック記述子とWeighted Fair Queuing(WFQ)のようなスケジューリング方法を使用することによって保証される遅延範囲を満足させることが提案されている。絶対的な遅延範囲はこの解決案によって保証されるが、それらは著しく悲観的であり、一定の環境のもとでは、不必要に処理が複雑になる(すなわちいくつかの環境のもとでは、複雑さが加わることのほうが潜在的な効果よりも勝ってしまうことがある)と考えられる。
【0016】
このようなときは、より現実的な遅延範囲を与える別のより簡単な解決案が切望されることになる。
【0017】
将来のネットワークに対する保証されるサービスの潜在的に望ましくない態様および複雑さは次のものを含む:
・バンド幅のコンテンションではなく、時間コンテンションの条件のもとでGSが実行されているとき、WFQによって行われる遅延制御は非常に小さいものとなる(すなわち、統計的多重化効果はない)。
【0018】
・WFQはバンド幅の共有と厳密なフローの分離を行なうが、これは、バッファのバックログ範囲が低減するか、または適切な上限値がデータグラムの最大の大きさとされるか、あるいはこの両者のときに必要なくなることがある。
【0019】
・GSクラス内の統計的多重化効果が、トークンのバケットトラヒック記述子に基づく複雑なCACを要求する。
【0020】
・資源確保セットアッププロトコル(RSVP)のシグナリングが、要求された二地点間の遅延範囲を支援できるか否かを確定するのに要求される。
【0021】
・現在WFQはフロー毎に適用されているのでコンピュータ処理上集中してしまい、ネットワークの速度が増加するとき、またはデータグラムの大きさが低減する(データグラムのスケジューリングをコンピュータ処理する時間が低減する)とき、あるいはこの両者のときに、潜在的な動作のボトルネックを導くことがある。
【0022】
さらに従来、遠隔通信ネットワークはネットワーク使用パターンおよびトラヒック統計がよく分かっていて、さらに比較的に安定したパラメータを使用していることに基づいて設計されてきたが、インターネットの発展により、現在ではこれらのパラメータが次第に不確かになってきている状況のもとで使用されていることが明らかになってきている。
【0023】
したがって将来のネットワーク設計はこのパラメータの不確かさに対処するのに十分にエラー強さがなければならないが、不必要に複雑なネットワーク制御技術を使用するといった犠牲を払うべきではない。しかしながら上述の指摘は、QoSの実行を保証する領域においてそれが発生する可能性が十分にあることを示唆している。
【0024】
【発明が解決しようとする課題】
本発明にしたがって、パケットネットワーク素子であって、フローベースのパケットを受取る少なくとも1つの入力と;所定のバンド幅の少なくとも1つの出力とを備え、ここでは受取ったパケットは第1および第2のサービスクラスと関係しているものであるとし;さらに各受取ったパケットをそのサービスクラスに基づいて、第1または第2の対応するパケットバッファへ向ける手段とを含み;なお前記第1のパケットバッファは出力バンド幅の所定の部分に割り当てられ;また前記第2のパケットバッファは出力バンド幅の残りの部分に割り当てられており;このパケットネットワーク素子は、前記第1のクラスのフローと関係するバンド幅要求を判断するバンド幅要求判断手段と;前記バンド幅要求を満たすことができると、第1のパケットバッファに向けて第1のクラスのフローパケットの受け付けを許可する手段と;第1および第2のパケットバッファから出力へパケットを向ける手段とを含むパケットネットワーク素子を提供する。
【0025】
このやり方では、比較的に簡単なネットワーク素子のアーキテクチャが従来の接続指向ネットワークに関係するサービスに類似するサービスを第1のクラスのパケットに提供するが、従来のコネクションレスネットワークに関係するサービスに類似するサービスを第2のクラスのサービスに提供することが好都合である。
【0026】
好ましくは、受け付けを許可する前記手段は、ピークレート試験を適用して、出力バンド幅の前記所定の部分中の現在使用されていない部分が前記ピークレートのバンド幅要求を満たすことができるときには、第1のバッファへの受け付けを許可するように動作する。
【0027】
ある環境においては、この手段が固定された遅延範囲を定式化し、併せてより複雑な仕組みのスループットを制限するような潜在的な処理のボトルネックを避けることができることとしている。すなわち第1のパケットバッファに受け付けられる第1のクラスのフローパケットは保証された遅延範囲を与えられることになる。さらにこれはフローごとにスケジューリングせずに達成されるので、大きいネットワークを構築する際に直接的で認識されている関心事とされているスケーラビリティを与える。
【0028】
より一般的に応用可能な実施形態においては、受け付けを許可する前記手段は前記ピークレート試験を適用し、バッファ充填試験を適用するように動作し、前記第1のパケットバッファが別のフローを受理するのに十分なスペースをもつときに受け付けを許可する。
【0029】
このような実施形態の長所は、少数の第1のクラスのフローのみが素子によって処理されるときでも、前記受け付けを許可する手段が保証される遅延範囲を用意できることである。バッファ充填試験は多数の第1のクラスのフローを処理する高速度のコアネットワーク素子では不必要である可能性が高い。
【0030】
好ましい実施形態では、前記受け付け許可手段は、第1のパケットバッファを収容できる大きさにされたフロー数から現在収容されているフロー数を減算した数が少なくとも1であるとき、および第1のパケットバッファに割り当てられた出力バンド幅の使用されていない部分から提案されたピークレートのフローのバンド幅要求を減算した数がゼロに等しいかまたはそれよりも大きいときのみ、第1のパケットバッファに対して第1のクラスのフローパケットの受け付けを許可するようにされている。
【0031】
このやり方では、第1のパケットのバッファに対して受け付けられた第1のクラスのフローパケットに保証された遅延範囲を与えるように、より特定の受け付け制御規則を実行してもよい。
【0032】
第1のクラスのフローパケットが第1のパケットバッファに対して受け付けを拒否されたとき、第1のクラスのフローパケットを第2のパケットバッファに受け付ける手段を用意することがさらに好ましい。
【0033】
このやり方では、受け付け制御用に‘soft failure’を用意して、第1のパケットバッファに受け付けられなかったパケットが、フローの継続期間中またはこれらのパケットが第1のバッファに受け付けられるときまで、第2のパケットバッファに受け付けられるようにしてもよい。
【0034】
いくつかの実施形態では、受取ったパケットが第1または第2のサービスクラスと関係するか否かを判断するクラス判断手段をもつ。所定のクラスのパケットとの関係が、例えばパケットが到達するインターフェイスから判断できないときにこのクラス判断手段を素子内に用意することが必要とされる。
【0035】
前記クラス判断手段は、前記受取ったパケットからクラス識別部分を読み取るようにされていることがさらに好ましい。
【0036】
このやり方では、‘オン−ザ−フライ シグナリング’を実行して、別々のネットワークシグナリング段階の必要性を効果的になくすことができる。
【0037】
前記バンド幅要求判断手段が、前記受取ったパケットからピークレートのフローバンド幅要求情報部分を読み取るようにされていることがさらに好ましい。
【0038】
ここでもこのやり方では、‘オン−ザ−フライ シグナリング’を実行して、別々のネットワークシグナリング段階の必要性を効果的になくすことができる。
【0039】
前記バンド幅要求判断手段は、各単一のパケットフローに対する特定のピークレートのフローバンド幅要求値を判断するようにされていることがさらに好ましい。
【0040】
このやり方では、単一のパケットフローは特定の処理に対してフラグを立てられる。
【0041】
本発明の第2の態様にしたがって、パケットネットワークと関係して使用するホスト素子であって:パケットベースのフローを生成し、各フローをそれぞれ選択された関係する第1または第2のサービスクラスと関係付ける手段と;第1のサービスクラスと関係するパケットを受取るようにされた第1のパケットバッファと;第1のパケットバッファの大きさを制御する手段と;第2のサービスクラスと関係するパケットを受取るようにされた第2のパケットバッファと;第1および第2のパケットバッファから、第1のクラスのパケットフローレートが選択されたピークレートバンド幅を超えないことを確保するようにされている出力へパケットを向ける手段とを含むホスト素子を提供する。
【0042】
このやり方では、ホストアーキテクチャは厳密に範囲を定められたピークレートをもつフローを生成して、より複雑なトラヒックの記述子の必要をなくすことが効果的である。
【0043】
選択された関係する第1または第2のサービスクラスを前記パケットのクラス識別部分へ書き込む手段を用意することが好ましい。
【0044】
このやり方では、‘オン−ザ−フライ シグナリング’を行なって、効果的に別個のネットワークシグナリング段階の必要をなくすパケットを生成することができる。
【0045】
さらにピークレートのフローバンド幅要求情報を前記パケットのピークレートのフローレートバンド幅要求部分へ書き込む手段を用意することがさらに好ましい。
【0046】
ここでもこのやり方では、‘オン−ザ−フライ シグナリング’を行なって、パケットを生成して、効果的に別個のネットワークシグナリング段階の必要をなくすパケットを生成することができる。
【0047】
ここで本発明の実施形態を添付の図面を参照して例示的に記載することにする。
【0048】
【発明の実施の形態】
送り側の送信ホストと受け側の受信ホストとは、素子またはノード、および相互接続リンクを含むネットワークによって接続されている。送信ホスト上で実行されているアプリケーションはデータパケットまたはデータグラムを生成する。‘フロー’という用語は、1または複数のパケット流がアプリケーションによって生成され、かつ特定のサービス品質(QoS)要件を備えつつ送られることを示すために応用されている。
【0049】
各それぞれのフローのサービス要求は、関係するサービス品質(QoS)レベルをもつ少なくとも2つの定義されたサービスクラスの1つ、一般的にいわゆる範囲を定められた遅延クラス(bounded delay class、BDクラス)またはいわゆる最善を尽くすクラス(best effort class、BEクラス)の1つとしてネットワーク内で伝送するために選ばれる。
【0050】
フローが範囲を定められた遅延BDモードでネットワーク内で伝送されるとき、ネットワークは最大の規定の遅延によって範囲を定められた時間中に構成パケットを二地点間で伝送できなければならない。フローが最善を尽くすモードでネットワーク内で伝送されるときは、ネットワークは最大の遅延範囲を特定せずに構成パケットを送る。
【0051】
これらのモードの何れを使用するかを選択するのは、送信ホスト上で実行されるアプリケーションの役目である。
【0052】
代わりのアーキテクチャの多数のネットワーク素子またはノードは、図1(a)ないし1(d)に示した。これらの素子またはノードは、例えば周知のルータ技術を使用して構成され、典型的な例はCisco Inc.から販売されている。
【0053】
図1(a)に示したネットワーク素子(1)では、1以上のパケット入力ポート(2)が入力リンク(図示されていない)に接続されて、パケットベースのフローを受取っている。
【0054】
各ネットワーク素子(1)は遅延範囲を定めたネットワーク動作モードまたは最善を尽くすネットワーク動作モードを支援するので、モード識別器(3)を用意して、パケットが関係する2つのモードの一方で入力(2)から受取ったかを各パケットについて判断し、そのパケットを適切なパケットバッファへ向ける。全ての入力ポートに単一モードの識別器(3)を用意してもよく、またはその代わりに2以上のモードの識別器(3)を用意してもよい。
【0055】
所定の大きさをもつ1以上の第1のパケットバッファ(4)は、範囲を定められた遅延(BD)動作モードと関係付けられ、一定数のフローを収容する大きさにされていて、1以上の関係するパケット識別器(5)をもち、バッファ(4)の1つを受け付ける前にパケットはこのバッファ(4)の特定の1つを通る。
【0056】
次にこのパケット識別は処理素子(6)内で別の処理を開始することができる。この別の処理の結果として、第1のバッファ(4)の1つに対して新しいフローのパケットを受け付けるか否かに関して受け付け判断、一般的には、コネクション受け付け制御(CAC)判断をすることができる。
【0057】
所定の大きさをもち、最善を尽くす(BE)動作モードと関係している1または複数の第2のパケットバッファ(7)は、モード識別器(3)から1または複数のバッファ(7)に向けられた‘最善を尽くす(BE)’パケットを記憶する。‘範囲を定められた遅延(BD)’パケットも、後述するように第1のパケットバッファへの受け付けを拒否されたときに、第2のパケットバッファへ向けることができる。
【0058】
第1および第2のバッファ(4,7)のそれぞれは、バッファを完全に使用する素子(buffer playout element)(8、9)をもち、バッファを完全に使用する素子(8、9)はそれぞれ1以上のスケジューリング素子(10)によって制御される。各スケジューリング素子(10)は、適切なスケジューリングアルゴリズムによって制御される。
【0059】
各バッファを完全に使用する素子は出力ポート(11,12)へ接続され、出力ポート(11,12)は出力リンク(図示されていない)と接続している。
【0060】
物理的に別個の出力ポートではスケジューリングは、実際は各バッファ完全使用(8,9)の完全に独立したスケジューリングを変える。
【0061】
1以上の範囲を定められた遅延バッファ(4)および1または複数の最善を尽くすバッファ(7)と関係する出力ポート(11,12)はそれぞれ、全出力バンド幅のうちの所定の割り当て分を与えられる。
【0062】
上述のように、図1(a)には実質的に入力(2)を1つだけ示したが、このようなネットワーク素子(1)はそれぞれ多数の入力(2)をもち、いくつかのホストまたは他のネットワーク素子からフローを受取ることができることは明らかである。
【0063】
同様に、ネットワーク素子(1)は多数の出力(11,12)をもち、したがって単一の範囲を定められた遅延バッファ(4)が各範囲を定められた遅延モードの出力ポート(11)について、また同様に最善を尽くすバッファ(7)用に存在することになる。
【0064】
関係する出力リンク(図示されていない)が物理的に別個であるとすると、スケジューリングは完全に独立なものとなる。しかしながら範囲を定められた遅延トラヒックおよび最善を尽くすトラヒックに対する出力リンクが単に見かけ上実質的に(バーチャルには)別々であるとき、技術に依存して、一定の範囲の多重化オプションそれ自体が存在してもよい。
【0065】
さらに加えて、範囲を定められた遅延バッファおよび最善を尽くすバッファ(4,7)は物理的にではなく、見かけ上実質的に別々であってもよいことに注意すべきである。
【0066】
図1(b)に記載したネットワーク素子(13)は図1(a)に示したものと類似しているが、1以上の第1および第2の入力ポート(14,15)を備えている。したがって、その結果図1(a)に明示したモード識別器(3)は、入力(14,15)の組として、それ自体が利用される必要はなく、また範囲を定められた遅延モードおよび最善を尽くすモードとそれぞれ関係していると考えられてよい。(すなわち、図1(b)の装置はモード識別器を必要としない。その理由は、入力(14)はBDトラヒックのみを、また入力(15)はBEトラヒックのみを運んでおり、モードはパケットが到着する入力から判明するからである。)しかしながら図1(a)に示したモード識別器(3)は依然として、全ての到来するパケットが正しいモードであることを確保する規制(policing)機能で働くのに効果的である。
【0067】
したがって範囲を定められた遅延モードと関係している各第1の入力ポート(14)は、図1(a)に関して既に記載したように、範囲を定められた遅延バッファ(18)に接続する前に、関係する追加の処理素子(17)と接続されているパケット識別器(16)に直接に接続される。最善を尽くすモードと関係している各第2の入力ポート(15)は最善を尽くすバッファ(19)と直接に接続される。
【0068】
図1(a)に関して述べたところと同様にここ図1(b)でも、範囲を定められた遅延バッファおよび最善を尽くすバッファ(18,19)は関係するバッファを完全に使用する素子(20,21)を介してスケジューリング素子(22)と接続されており、さらにそれぞれ各範囲を定められた遅延ポートおよび最善を尽くす出力ポート(23,24)に接続されている。
【0069】
図1(c)に示したネットワーク素子(25)は、入力、パケット識別器、追加の処理、範囲を定められた遅延バッファ素子および最善を尽くすバッファ素子(26,27,28,29,30,31)に関して図1(b)に示したものと類似しているが、範囲を定められた遅延モードおよび最善を尽くすモードと関係する1組のみが出力ポート(32)を送られていることが異なる。このような各出力ポート(32)には、2つのバッファ構造(30,31)が用意される。したがって各出力ポート(32)において、各範囲を定められた遅延バッファおよび最善を尽くすバッファは、スケジューリング素子(34)の制御のもとで、1つのバッファを完全に使用する素子(33)によって完全に使用され、次にこの単一の出力ポート(32)に接続される。
【0070】
2つのバッファ(30,31)は同じ出力ポート(32)を共有しており、完全使用の完全に独立したスケジューリングは不可能であるので、バッファ完全使用素子(33)を制御するのにより複雑なスケジューリングアルゴリズムが必要となり、実行にあたって2つのモード間の対話が行われることになる。一連の適切なスケジューリングの解決案が知られている。
【0071】
第1のバッファ(30)が少なくとも1つのパケットを含むとき、簡単な優先スケジューリングは常に第1のバッファ(30)から次のパケットを選択する。このやり方では、完全なパケットに対して第1のバッファ(30)に最も可能性の高いサービスを与えられる。範囲を定められた遅延トラヒックが全トラヒック中に占める割合が低いとき、最善を尽くすトラヒックにおける範囲を定められた遅延トラヒックの影響は比較的にわずかとなる。
【0072】
リンクの速度による除算がされた、最大の最善を尽くすパケット長により与えられる値は、ノードごとの遅延範囲の特定の値と比較して小さいか、または許容可能な範囲内で低い値のとき、最善を尽くすトラヒックの振る舞いは範囲を定められた遅延クラスのトラヒックにほとんど影響を与えないと考えられる。これに当てはまらないときは、‘サスペンド再稼動’スケジューリングは単一の優先スケジューリングの代わりであると考えられることができる。
【0073】
最善を尽くすパケットの‘サスペンド再稼動(suspend-resume)’スケジューリングにより、範囲を定められた遅延パケットが送信可能になると直ぐに、最善を尽くすパケットの送信をサスペンドすることができる。したがって最善を尽くすパケットは、範囲を定められた遅延パケットを収容するようにデータリンク層上で効果的に分割される。
【0074】
最後に、図1(d)に示したネットワーク素子(35)は、図1(a)に示したものと類似する1以上の第1の入力(36)、モード識別器(37)、関係するパケット識別器、追加プロセッサ、範囲を定められた遅延バッファ構造、および最善を尽くすバッファ構造(38,39,40,41)を含み、さらに加えて図1(c)に示したものと類似する1組の出力(42)、単一のバッファを完全に使用する素子(43)、およびスケジューリング素子(44)を含む。
【0075】
ネットワーク素子(1,13,25,35)が範囲を定められた遅延の動作モードを与える能力は、全ての競争する(contending)フローのピークレートの和が範囲を定められた遅延トラヒックに割り当てられる出力バンド幅の一部分を超えないことを保証することに依存することが明白である。フローごとにピークレートのバンド幅を特定することは、ホストの出力リンク速度が特定のピークのバンド幅に制約されるが、パケット分割時間に関係してトラヒックを形成するようにフローを生成するホストに要求することを意味すると考えられる。ピークレートの和を制御する手段は、適切な大きさにされるか、またはCAC規則を適用してもよい。しかしながらピークレートの和の制御は必要であるが、範囲を定められた遅延の動作を行なう十分条件に常になるわけではない。素子の特定の構成に依存して、範囲を定められた遅延フローの数およびパケットの大きさを制御することも必要である。
【0076】
次に示す式1Aおよび1Bは素子に対するマルチパケット遅延範囲を表わし、なお式中のlink rateは検討している出力リンクの動作速度であり、mux ratioは出力ポートリンク速度対入力ポートリンク速度の比であり、Nipは範囲を定められた遅延(BD)クラスのフローを保持し、出力リンクをドライブする入力ポート数であり、Nflowは範囲を定められた遅延フローの最大数であり、Imaxは範囲を定められた遅延クラスパケットの最大の大きさであり、Ibeは最善を尽くすパケットの最大の大きさである:
【数1】
【0077】
CAC規則を使用して式1Aおよび1Bまたは類似の式をピークレートのバンド幅制御と一緒に理解することができ、特定の遅延範囲を侵害することなく受け付けることができるか否かに関して新しいフローを試験できることが明らかである。これらの特定の式は、入力ポートを通るフロー分配の最悪の場合を表わしている。
【0078】
式1Aおよび1Bは、一定の範囲の状況に適用するのに十分に普遍的である。しかしながら重要な一定の特定の場合において、式1Aおよび1Bを簡単な形に約して、例示的に2つの例を与える。各例において、項lbe/link rateは無視でみるほど十分に小さいと考えられる。
【0079】
mux ratio=Nipのとき:、式1Aを次のように約すことができる:
Imax・Nip/link rate (式2)
この場合、この素子の遅延は自動的に範囲を定められ、フローの実際の数を知らなくても遅延範囲を設定することができる。これはアクセスノードの場合を表わし、出力(outgoing)リンク上の実効バンド幅は、範囲を定められた遅延トラヒックを支持する全ての到来リンクのバンド幅の和を収容する大きさにされる。
【0080】
mux ratio=1、およびNflow>>Nip>>1のとき、式(1B)
は次の式3に近似する:
Imax・Nflow/link rate (式3)
式3は、バンド幅の等しい入力および出力リンクと、(例えば)4以上の組の入力および出力ポートとをもつコアネットワークノードの場合を表わすことができる。この場合に、範囲を定められた遅延動作は最早自動的ではなく、ある程度の制御は、範囲を定められた遅延クラスに受け付けられるフローにおいて遅延範囲を保証することを確実にするために必要とされる。
【0081】
ピークバンド幅のCAC試験は式4によって表わすことができる:
(Pk f low+Pk accum/Pk alloc)<l (式4)
Pk flowは範囲を定められた遅延(BD)クラスに対する受け付けを要求する新しいフローのピークバンド幅であり、Pk accumは全ての現在受け付けられているBDフローのピークバンド幅の和であり、Pk allocはBDトラヒックに割り当てられた合計バンド幅である。式4は、新しいフローと現在受け付けられているフローのピークバンド幅の和が割り当てられたバンド幅を超えないことを検査するときに新しいフローに対して行われる試験を記載している。項Pk allocがリンクレートよりも小さくなるように選択されると、最善を尽くすクラスに対する一定レベルのバンド幅を保証することができる。
【0082】
式(2)によって記載された場合において、Nipおよびlmaxに既知の制限を与えるとき、式(4)によって記載された試験はCACに唯一の必要条件である。
【0083】
式(3)によって記載される場合において、ピークバンド幅試験を適用することに加えて、CACプロセスがNflowをある値、すなわちNflow allocに制限して、遅延範囲を確立することも必要である。しかしながら、最小値のピークバンド幅Pk min、すなわちフローを関係付けることができる最小のピークバンド幅を定めることによって、ピークバンド幅のCAC条件を適用することによって、Nflow allocは潜在的に制限される。したがってNflow allocはPk alloc/Pk minに制限され、遅延範囲Tboundは次に示す式(5)によって表わすことができる:
Tbound=lmax・Nflows alloc/link rare (式5)
この例では、要求される遅延範囲はlmaxおよびPk minを特定することによってネットワークオペレータによって選択できることが明らかである。
【0084】
ある条件では、各個々のフローにおける最大パケットの大きさの知識を使用することによってBDクラスをよりよく使用することが望ましい。したがってピークバンド幅要求を示すことに加えて、各フローは、最大パケットの大きさを特定することができ、i番目のフローはli maxで表わすことができる。ネットワーク素子において、入力および出力リンク速度が等しく、異なるフローの最大パケットの大きさの差を考慮に入れるとき、式(3)のより一般的な形によって遅延範囲に近似することができる:
【数2】
【0085】
なお、和はバッファに受け付けられた全てのフローよりも大きい。この場合に、フローの明白な制御がここでは必要である。したがってピークレート試験に加えて満たされなければならないパケットの大きさに別のCAC条件を加えることによってこれを達成することができる。
【0086】
(li max+lmax accum)/lalloc <1 (式7)
なお、lmax accumは現在受け付けられている全BDフローの最大パケット長の和であり、lallocはフローの最大パケット長についての最大許容和である。これはネットワークオペレータによって選択されて、特定の遅延範囲を確保できること、およびBDの待ち行列に対するバッファ充填についての限界範囲に対応していることは明らかである。
【0087】
BDクラスにして複数のパケットフローを受け付けるCAC規則をさらに検討すると、単一のパケットフローの特定の場合に対してこれらのCAC規則をわずかに変更することが必要なことが明らかになる。式(2)と関係する条件において、CACプロセスは新しいフローを受け付けるのに予備のバンド幅が十分にあるか否かを検査するが、連続するピークレートのパラメータに関して単一のパケットフローを記述するコンセプトには意味がない。それにも関わらず、単一のパケットと同じくらい短いフローを受け付ける手段は、BDクラスに割り当てられるバンド幅を超えないことを保証することが必要とされる。1つの適切な技術では、フローの停止後適切な時間をおいてピークレートを割り当てる。ピークバンド幅の値を選択するのに種々の可能性があり、その1例では上述のPk minのコンセプトを使用する。特定のPk min値はネットワーク設計プロセスの一部として選択することができ、そこでCACは単一のパケットフローに対するバンド幅パラメータとしてこの値を使用するように前もって構成されているが、特殊状態では他の値も使えるように、CACをデフォルトで選択するようにしている。これらの実行条件のもとでは単一のパケットに対するバンド幅受け付け試験は、(式4内の)Pk flowをPk minに置換したことを除いて、複数のパケットのフローに対して記載したのと全く同じである(式8参照):
(Pk min+Pk accum/Pk alloc)<l (式8)
式(3)と関係する条件では、CACはさらに使用可能な予備のバッファスペースが十分あるかを検査し、式(7)によって記載されたCAC規則を適用する。フロー数を潜在的に制限するこのタイプのCAC規則は依然として単一のパケットフローに対して、加えて既に記載したPk minのコンセプトを使用してネットワークに対して、式(7)は1以上のパケットフローに直接に応用できる。
【0088】
しかしながら、独立した2つの試験のCACの解決案は、Pk minの解決案を使用して可能であったときよりもCAC方法をより精巧にできると考えられる。このようなCAC方法の1つの例では、CACプロセッサで使用可能なバッファスペースおよびバンド幅の合計を維持して、予備のバンド幅の全てまたは一部分を各新しい単一のパケットフローに割り当てることである。予備のバンド幅の一部が割り当てられる場合は、その量は、例えばパケットの大きさと使用可能なバッファスペースの比に比例するようにすることができる。これらの解決案の何れを使用しても上述のCAC試験のいずれにも影響を与えず、単にCACのパラメータおよび値に対してわずかに異なる規定をもつ特定の例を生成するだけである。
【0089】
この解決案では付加的な長所として、簡単なFIFOスケジューリングを使用して、WFQのような方式と関係する複雑で著しい処理オーバーヘッドを避けることもできる。FIFOスケジューリングを使用するとき、FIFOスケジューリングは、バンド幅共有の受理可能なレベルが全フローに対応するか否かも判断するので、パケットの大きさを最大にするという負担を荷うことがとくに重要である。
【0090】
例示的に、新しいフロー中の最初のパケットを受取るとき、パケットを識別したパケット識別器(5,16,28,38)、それ自体は追加の処理を行なって、ピークレートのバンド幅要求を範囲を定められた遅延フローに関係付けることができる。この追加の処理には、例えばユーザによって提案された遅延要求に基づいて、バンド幅要求の計算を含んでもよい。
【0091】
処理素子(6,17,29,39)における別の処理は、第1のバッファ(4,18,30,40)および関係する出力ポート(11,23,32,42)がCAC条件を満たすことができるか否かを判断でき、この結果新しいフローを第1のバッファ(4,18,30,40)に受け付けることができるか否かを判断できる。
【0092】
所定のフローと関係するピークレートのバンド幅要求との間の識別は多数のやり方で実行できることが明らかである。
【0093】
もとより、新しい範囲を定められた遅延フローはCAC規則のもとで第1のバッファへの受け付けを拒否される可能性がある。
【0094】
この可能性に対処する1つの解決案では、CAC規則によって拒絶されたフローパケットを第2のバッファに受け付け、最善を尽くすやり方で対処する。同時に適切な‘接続拒否’メッセージを資源へ中継することができる。同じフローからの後続のパケットは‘接続要求’シグナリング情報を送り続けて、最終的にフローが第1のバッファへ受け付けられる継続する可能性を確保することができる。
【0095】
最も簡単な状況として、最悪の場合の遅延は、バッファが各受け付けられたフローからバックログされたフローを含むときにネットワーク素子において発生し、その結果最悪のケースの範囲は、各受け付けられたフローに対する最大パケットの大きさの和を出力リンク速度によって除算したものに等しい。したがって、範囲を定められた遅延クラスに対して最大の許可されるパケットの大きさを小さくすると、特定の遅延範囲を達成する一方で、収容可能なセッション数に逆比例する効果をもたらす。範囲を定められた遅延クラスに対して最大の許可されるパケットの大きさを選択するときのこの逆比例効果について検討する。
【0096】
フローが受理されると、必要な状態情報をメモリ(図示されていない)に記憶され、フローが終了するまでメモリ内に維持され、フローが終了するまで、ソフト状態の方法または所定のパケット識別器によって消去プロセスを開始する。
【0097】
BDクラスのフローがネットワークへ受け付けられると、このパケットフローが単一であるか、複数であるかとは無関係に、バンド幅またはバッファスペース、あるいはその両者は効果的に確保され、フローが終了するときこれらの資源を解放しなければならない。確保された資源はタイムアウト機構または特定の要求によって解放することができる。特定の要求を使用する解決案の例には、フローの最後のパケットがノード内で追加の処理を開始して、確保された資源を解放するといったものがある。しかしながらフローはピークレートベースで受け付けられるので、最後のパケットを受け付けて特定の臨界値Treleaseに到達した後に時間をおかなければ、資源を再使用することはできない。Treleaseの値は可変であり、これは最後のパケットの大きさおよびフローのピークレートの両方に依存するからである。複数のパケットフローにおいて、Treleaseは式9に等しい:
【数3】
【0098】
しかしながら、BDクラスに対して特定された最大の許可されたパケットの大きさがあるとすると、Treleaseは式10を使用することによって、パケットの大きさとは無関係にすることができる:
【数4】
【0099】
しかしながらこれは資源の利用効率を低減する犠牲を払うことになり、実際の低減は最大の許可されたパケットの大きさに直接に依存する。しかしながらこの簡素化の長所は、CACプロセスの一部としてTreleaseを計算でき、次にCACプロセスでは解放カウンタを作動し、Treleaseに等しい値に到達するとき、lmax accumの値をli max’に等しい量だけ低減し、Pk accumの値をPk flowに等しい量だけ低減できることである。
【0100】
単一のパケットフローにおける解放手続きは、複数のパケットフローにおける解放手続きと同じであり、唯一の相違点はTreleaseを計算するときに、Pk flowの項を適切なバンド幅の項と置換したことである。例えばPk min‘のコンセプトを使用するとき、既に記載したように、Pk flowを使用する全資源を解放するコンピュータ処理は代わりにPk min‘を使用する。
【0101】
フローが受理されると、フローヘッダパケットに後続するフローパケットはフローのピークレートバンド幅要求の指示を保持する必要がないことは明らかであろう。
【0102】
既に記載したように、ピークレートのCACを使用する理由は、ピークレートのCACは最悪の場合のバッファの大きさにおいて決定論的な制限範囲を与え、最悪の場合のリンク遅延を、最大のパケットの大きさおよび同期するユーザの最大数の両方によって判断される値に加えるからである。したがってパケットの損失は最悪の場合の大きさにされたバッファを使用することによって防ぐことができ、リンクの遅延は、単に最大のパケットの大きさを適切に制限するだけで必要に応じて低減することができる。最悪の場合よりも小さいバッファを使用することにより、バッファのオーバーフローおよびその結果生じるパケットの損失の統計的な確率がもたらされる。
【0103】
パケット損失をゼロにし、これに加えて絶対的なまたは“最悪の場合”の遅延範囲、すなわち(何らかの故障以外の)何れかの条件のもとでこれまでに分かっている最大の遅延を行なうようにCAC規則を定義できることに注意すべきである。
【0104】
これまで“最悪の場合”と記載してきた制限範囲は、ノードへ入来するときのフローがピークレートに整形されたものであるときのみ有効であるので、このステートメントをわずかに限定化することが必要であるが、フローのパケット間のスペースはネットワーク全体に広まるにしたがって乱れる可能性が高いことがよく知られている。このため時折ピークレートを過渡的に増加することが生じ、理論上はある環境のもとでは“最悪の場合”の制限範囲が破られてしまうことがある。この結果(バッファは、最悪の場合の遅延範囲にぴったりと整合するように大きさを定められるときは)パケットが損失してしまうか、または(バッファが最悪の場合の遅延範囲よりも大きいときは)遅延が増加する。
【0105】
しかしながらよく設計されたネットワークでは、範囲を定められた遅延トラヒックのピークレートの和はスケジューラによって与えられた供給レートよりも幾らか小さい(これに関して言えば優先順位のある待ち行列は理想的である)とき、ピークレートにおけるこのような過渡的な変動は、遅延範囲を破られないように十分に制限される。事実、逆ではなく、多くの例では特定のノードにおける条件は、最悪の場合の範囲が統計学用語で過度に悲観的(overly pessimistic)といわれるようなもになる。
【0106】
したがって最悪の場合の遅延範囲は収容可能なフローの最大数が増加するのにしたがって、益々悲観的になるので、CACが最悪の場合の遅延範囲を考慮に入れることは常に適切であるとは示唆されない。むしろ、CAC規則をいくつかの場合において幾分緩和して、より多くのフローを受け付けることができるようにし、ノードの位置にしたがってCACを少なくとも3つのやり方で適用できると考えられる。
【0107】
要求される遅延範囲が、(例えば、低速度のリンクにおいて)BDパケットの比較的に小さいバックログに等しいとき、受け付け制御は“ピークレートの和の試験”と“最悪の場合の遅延試験”の組み合わせに基づいている。
【0108】
個々のパケットのサービス時間が要求される遅延範囲と比較して十分に小さくなるようなリンク速度である場合には、統計学的に検討することにより、“ピークレートの和の試験”を適用する必要があるという結論を導き出すことができる。
【0109】
これらの2つの極端な試験の間で、受け付け制御は“ピークレートの和の試験”と“統計的な遅延範囲の試験”との組み合わせに基づくことが非常に適切である。“統計的な遅延範囲の試験”は、特定の遅延を超える可能性が一定の(小さい)値を超えるまで、フローを受け付けることに基づいている。
【0110】
さらに、ピークバンド幅の和の試験に関して、とくに多数のフローを運ぶことを意図しているノードに対して、統計的多重化効果を適用することが実際的であると考えることができる。したがって、ホストが若干の時間の間に特定のピークレートよりも低いレベルでトラヒックを生成することになるという知識または見込みに基づいて、全ての受け付けられたセッションに対するピークレートの和が、範囲を定められた遅延クラスのトラヒックに対する割り当てられたピークレートの和を超えることになる。
【0111】
将来のネットワークは、最善を尽くすトラヒックと遅延範囲を定められたトラヒックとを混合したものを支援する可能性が最も高いと予測され、この場合範囲を定められた遅延クラスに対するピークレートのCACの使用は、必ずしも劣悪なリンク使用に導く訳ではない。この理由は、最善を尽くすモードは所定の予め定められた割り当てから予備の範囲を定められた遅延モードのバンド幅を使用することに適応できるからである。したがって範囲を定められた遅延モードが合計バンド幅の保証される最大量を含み、最善を尽くすモードが保証される最小量を含み、平均すると、範囲を定められた遅延モード使用の統計によって判断されるよりも大きくなることを意味する。以下で開示するように、バッファ使用に関しても同様の状況が存在する。
【0112】
範囲を定められる遅延バッファはパケット損失を避けるように大きさを定められるとき、概してネットワークのみが範囲を定められる遅延トラヒックを支援する場合に、過度に大きい寸法にされることが明らかである。しかしながら両方の動作モードを支援するときは、必要に応じて最善を尽くすモードによって使用するために、使用されていないバッファスペースを解放することができる。この特徴は1例として、バッファ空間を回復/解放する尺度としてバッファ充填の特定のレベルを使用するように用いることができる。したがって合計のバッファ空間の寸法を定めて、パケット損失の一定の可能性を受理する必要なく、バッファ利用の合理的なレベルを達成できることになる。言い換えると、範囲を定められた遅延モードがパケットを損失する可能性を制限するのではなく、通常よくあるように、最善を尽くすモードが幾らかのバッファスペースを諦めることがある。
【0113】
図1(a)ないし1(d)に記載したネットワーク素子の適切な組合わせを使用することによって、種々のネットワーク構造が得られ、図2(a)ないし2(c)に記載したように、最善を尽くすモードと範囲を定められた遅延モードの両方を支援する。
【0114】
ここでも、ネットワーク素子に関して記載したように、送信ホストと受信ホスト間の単一の経路のみを示す一方で、実際にはネットワーク素子1a−1dはネットワークの多くの他の構成要素のノード(図示されていない)との接続をもつことになる。
【0115】
図2(a)において、図1(a)に基づく入来ノード(1)および図1(c)のアーキテクチャに基づく出力ノード(25)は物理的に別々の各接続指向のネットワークとコネクションレスネットワークに接続することができる。
【0116】
図2(b)は図2(a)のネットワークに類似したネットワークの例を示すが、図1(b)のノードアーキテクチャ内に示した多数のノード(13)を使用して、図1(a)のノードアーキテクチャの入来ノード(1)と図1(c)のノードアーキテクチャの出力ノード(25)とを接続している。
【0117】
図2(c)は、図1(d)のノードアーキテクチャ(35)にしたがって素子のみから形成されるネットワークを示している。
【0118】
CACは、全てのノードにおいてではなく単一のノードかまたはノードのサブセットのみにおいて実行できることに注意すべきである。例えば入来または出力ノードのみにおいてCACを適用することが実際的である。
【0119】
本発明の重要な特徴は、範囲を定められた遅延モードのフローを設定するとき、遅延に関してネゴシエーションする必要をなくすことができることである。これはある地点へのネットワーク遅延を、全体的な二地点間遅延のごくわずかな部分になる程度まで低減することによって達成される。上述のように、いくつかの要素が素子の遅延に影響を与えるが、基本的にそれらは出力ポートリンクおよびバッファ充填の速度によって判断されるが、代わってこれは最大のパケットの大きさおよびCAC規則(すなわち、同期するユーザの最大許容数および統計的多重化効果レベル)に依存する。
【0120】
これらのパラメータの関数として関係する遅延の変化の模式的な例を図3(a)ないし3(c)に記載する。
【0121】
図3(a)は、特定のネットワーク構成における全体的な二地点間遅延の構成要素部分を模式的に表わしており、この特定のネットワーク構成では例えば1キロバイトの最大パケットの大きさの接続モードのフローのみを支援し、2.5の統計的多重化効果比を使用する一定の範囲のリンク速度をもつ多数のネットワーク素子を含む。この特定の例において全体的な二地点間遅延はネットワークのリンク遅延によって占められていることが明らかである。
【0122】
しかしながら図3(a)と図3(b)とを比較することによって、CACが統計的多重化効果を防ぐときにこれらの遅延がどのくらい低減するかが分かり(すなわち、瞬間的なバンド幅要求は割り当てられた量を超えない)、さらに図3(c)と図3(b)とを比較することによって、パケットの大きさを5分の1にする追加の低減が達成される。これらの比較から、ある地点において全体的な二地点間遅延がリンク遅延からホスト遅延によって占められるように遷移することが直ぐに分かる。
【0123】
リンク遅延に影響を与える別の要素は、接続モード動作に割り当てられた合計バンド幅に比例する。例えば特定の例において、パケットの大きさを低減することにより達成される遅延低減は、範囲を定められた遅延クラスに割り当てられたバンド幅を全出力リンクバンド幅の100%から25%へ低減することによって表わすことができる。
【0124】
したがって上述のことから、動作の範囲を定められた遅延クラスについては、ゼロの統計的多重化効果(ピークレートの大きさを決めるバンド幅)、小さいパケットの大きさ、高リンク速度、および全体に対する割合が小さい、あるバンド幅割り当てといったものの組み合わせによりリンク遅延を最小に保つことができる。
【0125】
ホスト遅延によって支配されている領域もしくは形態(レジーム)内で動作する長所は、このアプリケーションがネットワークが関与する必要なしに、単に適切な動作条件を設定することのみによってそれ自身二地点間遅延を制御できることであり、もちろん最終的にこれはアプリケーションの要求に依存することになる。この例は、公称のデータフレームサイズの決定判断であってもよく、これは受け側のホストに対して使用されるものであり、しかもなお許容可能な遅延領域内にあり、フレーム充填/読み取り時間によって引き起こされる。もちろん本発明の用途はホスト遅延が主体となっている領域内の動作に限定されないことに注意すべきである。好都合なレジームは、例えば全ての遅延が等しいが、小さい値の場合にもたらされる。
【0126】
上述のように、所定のフローと関係するピークレートのバンド幅との間の識別は、多数のやり方で行なうことができる。IETFによって規定される資源確保セットアッププロトコル(RSVP)は、1つのこのような手段を用いる。RSVP経路およびResvシグナリングメッセージは、TspecおよびRspecフィールドを使用して正規の動作をし、BDクラスのフローおよびこのフローに対するピークレート要件Pk flowを識別し、これらのシグナリングメッセージは受信側へ向け段階的に(ホップバイホップで)送られ、送信側へ段階的に送り戻される。式4で表わされるピークバンド幅のCAC規則を適用するノードについては、送信側へ送り返される各ホップは、要求されるバンド幅Pk flowと既存の累積されたバンド幅Pk accumとの和を(送信側から受信側へ向かう方向の)出力ポート上でBDクラス(Pk alloc)に対して割り当てられた合計バンド幅と比較する。他の応用可能なCAC規則は類似のやり方で応用されることも保証することになる。
【0127】
CACが成功するとすると、このフローのピークバンド幅Pk flowおよび関係するフロー分類子(classifier)はノード内でCAC制御に使用される他のパラメータと一緒に記憶される。この状態は、正規としてRSVPメッセージによってリフレッシュされる。データパケットの受領を使用してこの状態をリフレッシュすることもできる。したがってこのソフト状態は、リフレッシュされないとき取り除かれ、またそれにより関係するバンド幅およびフローカウンタが修正されることになる。CACを送ったフローの識別はトラヒックを規制し、さらにフローが停止するとき、キー使用パラメータにおける対応する変更が記録され、例えば正確なPk flow値が出力ポートの合計Pk accumから取り除かれることを記録することを保証するのに要求されることは明らかであろう。IPバージョン4に対するRSVPの確保は、フロー分類子として働く送信元アドレス/送信先アドレス/ポートの3つから成るもの(トリップル)によって識別される。IPバージョン6は、フローIDと呼ばれる単一のフィールドの概念をもつ。送信側または受信側(アドレスの識別分類コード)、トラヒックタイプ(ポート番号/伝送プロトコル)、あるいは‘タグ(標識、tag)’のような他の識別子のグループに関係する他の分類子は周知であり、集約した分類子(aggregated classifier)を用意するのに使用することができる。多数のフローはCACおよび本発明のシグナリングプロセスにおいて、集約されたフローの合計ピークバンド幅を単に加算し、これを統合された分類子として記憶し、この集約した合計ピークバンド幅Pk flowの値を次の下流ノードへ送るだけで容易に集約できる。モード識別プロセスは多くのやり方で達成でき、この場合は一般的な‘バンド外(out of band)’RSVPシグナリングおよび分類プロセスの一部であってもよい。
【0128】
CACが失敗するとすると、分類子状態は記憶されるが、資源は割り当てられない。この分類子状態を使用して、このノードにおいて到来するBDパケットをこのフローからBEバッファへ迂回して、このノードにおける他の受理されたBDフローを保護する。このフローがCACを送った下流ノードは依然としてこのパケットをBDクラスへ送り戻すことができる。RSVPのメッセージングは、顧客が不完全な確保を知らされるか、または他のプロトコルあるいは診断ツールがこのフィードバックを行なうことができることを保証する。顧客はこの点でBDクラス要求の失敗によってフローを止めることを判断でき、この判断によって全てのノードにおける分類子状態はタイムアウトすることになる。ユーザがBDパケットを送り続けるとき、一定のノード(失敗したCAC)ではBDパケットはBEバッファを使用し、時間をおくと資源がそのノードにおいて使用可能になり、CACプロセスをリフレッシュするとき、このフローはBDクラスに受け付けられることになる。これに対して多数のアルゴリズムが可能であるが、1例として、ノード内の失敗した(failed)フローが最初に失敗したものを最初に供給するやり方(First Failed First Served)に基づいてサーチされ、この新しく解放された資源を充填できるPk flowをもつフローを見付けることができる。最良のアルゴリズムは他の要素、例えば請求書発行モデル、異なるフロータイプの数、およびノードの目標使用に依存する。
【0129】
規制は全てのノードにおいて行われるか、あるいはトラヒックのマトリックスおよびBDクラス容量の割り当てられた量に対して十分な容量が割り当てられるときは、この遅延範囲を定められたネットワークの入来および出力ノードのみにおいて規制を行なうことができる。規制は、宣言された最大パケット長およびピークレート内で維持されるBDクラスフローを保証し、さらにパケット計数、確保方法、および請求書発行のような機能を実行するように働く。
【0130】
ルート変更の結果、異なるノードおよびリフレッシュ機構を使用するこのフローに対するパケットを使用して、新しいノード内でCACを呼び出し、一方でソフト状態は古いノードが予め確保しておいたバンド幅を戻したことを保証する。
【0131】
別の実施では、いわゆる‘オン−ザ−フライ’シグナリングを使用する。これは第1のパケットを使用して、このフローへ要求されるパラメータへシグナリングすることによって、RSVPおよび関係する往復(一周)移動の遅延の使用を避けるものであり、1つの実行例を図4を参照して次に記載する。
【0132】
フローパケット(45)は、多数のフィールドを含むヘッダ部およびデータを保持するペイロード部(47)から成るように定められる。
【0133】
最初の2つのヘッダフィールド(48,49)は送信元および送信先アドレスを保持し、これらを使用して普通のやり方でネットワークにおいてパケットをルート設定する。他の周知のフィールドを含んでもよい。
【0134】
最も簡単な実施形態では、モード識別子フィールド(50)を使用して最善を尽くす遅延モードパケットと範囲を定められた遅延モードパケットとを区別する。パケット識別子フィールド(51)は特定の機能をもつパケットを示すのに使用される。
【0135】
1または複数の追加の処理情報フィールド(52)は、範囲を定められた遅延モードのフローに対してホストが選択した実効ピークデータレートのようなネットワーク素子情報を示すのに使用される。
【0136】
これらのヘッダフィールド(46)の全ては、アプリケーションによって特定することができる。その代わりにこのヘッダフィールド(46)は入来ノードによって範囲を定められた遅延ネットワークへ入力するときに特定することもできる。パケット(47)のペイロード部分はネットワークにおいて送信先ホストへ送られ情報を含む。
【0137】
このやり方では、図1に関係して記載したネットワーク素子の実施形態に関係して、モード識別器は受取ったパケット(45)のヘッダ内のモード識別子フィールド(50)を読み取ることによってモード識別を実行することができる。類似のやり方では、新しいフローの先頭パケットを使用してコネクション受け付け制御(CAC)手続きを開始することができる。新しいフローの先頭パケットをパケット識別子フィールド(51)から識別したパケット識別子は、提案されたバンド幅要求によって、ピークレートのCAC判断を行なうときに、先頭パケットのヘッダバンド幅フィールド(52)から読み取ることができる。類似のやり方で他のこのようなパラメータを得ることができる。
【0138】
したがって‘オン−ザ−フライ シグナリング’を使用して別々のシグナリング段階がなくても範囲を定められた遅延クラスのフローを確立することができる。
【0139】
同様に、さらに特定のパケット識別子を定義して、追加の処理のためにフロー内で中間のパケットを送って、必要に応じて二地点間遅延を動的に調節するアプリケーションをイネーブルすることができる。
【0140】
全てのパケットはBDクラスに対するモード識別子を含む。しかしながらモード識別器は第1の‘シグナリングパケット’からとって、分類子の一部として記憶(キャッシュ)して、分類子を整合するパケットを受取って、これを使用してパケットを正しいバッファへ入れると回復することができる。その代わりに、モードは特定の分類子、とくにVPN構成およびインターネット電話のような特定のトラヒックタイプに対してBDクラスを自動的に用意する集約された分類子にスタティックに構成することができる。
【0141】
‘オン−ザ−フライ シグナリング’では、フロー内の第1のパケットはフローPk flowに対する関係するピークレートのバンド幅およびCACに必要な他のパラメータを含む。新しいフローは、上述と同じCAC規則を使用して二地点間経路上の各ノードにおいて受け付けることができる。フローがCACを失敗するとすると、失敗分類子状態は以前のようにインストールされるが、ここでは新しい‘CAC失敗’メッセージが送信側へ戻される。これは新しいICMPコードまたは他の手段であってもよい。加えて、‘CAC失敗’フラグは第1のパケットヘッダ内で設定されるので、下流ノードおよび受信側も損失について知らされ、下流ノードはさらにCAC失敗メッセージを送り戻さず、このメッセージはそうでなければ送信側へスワンプ(swamp)する。分類子と整合し、BDモードに設定されたフロー内の残りのパケットは、BDバッファへ受け付けられるが、CAC中にフローを失ったノード内でBEバッファを使用する。シグナリングパケットPk flow値および他のCACパラメータをリフレッシュすると、CACにおいて最初に失敗した時のルーティング変更、分類子状態のタイムアウト、および後の資源への受け付けに対処するのに使用できる。
【0142】
単一のパケットフローに関して上述で概略的に記載した解決案において、パケットヘッダ内でピークレート情報を伝える必要はないので、この情報を保持するのに通常使用されるフィールドは、ゼロといった定義されたデフォルト値に設定され、単一のパケットフローを示すのに使用することができる。
【0143】
今日のIP v 4プロトコルについては、TOSヘッダフィールドを使用するモードおよびパケット識別子コードを特定することによって上述の例を実行することができる。要求されるバンド幅はIP v 4オプションフィールド内に予め構成するかまたは配置してもよい。IP v 6において、モードおよびパケット識別子コードはフローIDフィールド内に位置付けられ、バンド幅要求は段階的に(hop by hop)拡張する(オプション)ヘッダ内に置くことができる。情報を送信側ホストへ送り戻す必要があるとき、適切なICMPメッセージ、例えばフロー受け付けが拒否された、などを生成することができる。
【0144】
いくつかの形態のトラヒック処理能力は、使用されたアプリケーションのタイプおよび生成された同期するフロー数の両方に依存して送信側および受信側の両方のホスト端末内で求められる。したがって一般的にホストはネットワーク素子の2つのバッファリングをもつ性質を使用できると予測される。
【0145】
このようなホストアーキテクチャの構成例を図5に示した。ホストは、例えば適切なネットワークインターフェイスを設けた周知のユニックスワークステーションまたはPC技術を使用して実行することができる。
【0146】
図5に示した一般的なホスト構成(53)において、アプリケーションA(54)は、範囲を定められた遅延クラスにおいて送られる1以上のフローを生成する。アプリケーションA(54)がこの動作クラスを使用するときは、一般的に例えばアプリケーションの実行速度ではなく、ホスト内の実行速度によって判断されるレートで、バーストパケットフローを生成し、範囲を定められた遅延バッファ(55)、バッファ割り当て、およびパケットの大きさの制御(56,57)は、フローを共有するための関係するスケジューリング素子(58)と一緒にホスト実行制御用に用意する。スケジューリング素子(58)は適切なスケジューリングアルゴリズム(59)によって制御される。
【0147】
ホストは原理的には同期して、範囲を定められた遅延フローおよび最善を尽くすフローの両方を実行することができるので、スケジューリングアルゴリズム(59)が範囲を定められた遅延バッファ(55)内で記憶されたパケットに最高の優先順位を与えるように設計されているという事実に完全に適応するように、最善を尽くすバッファ(60)が用意される。アプリケーションB(61)は、アプリケーションA(54)において示したバッファ割り当て(図示されていない)およびパケットの大きさ(62)において同様の制御を行なう。
【0148】
トラヒック形成(シェーピング)は遅延範囲を保証するフローの重要な態様であり、主としてこのトラヒック形成は、ネットワークへ入力されるのに先立ってアプリケーションによって生成されるパケット間の到達間時間を変更できるようにする。したがってパケットフローのバースト状態はトラヒック形成によって制御でき、この結果低い方のピークバンド幅がネットワークから要求されるか、さもなければ上述のような変更を行なう。実際はトラヒックシェーピングは単にネットワークバンド幅要求とホスト遅延との間のバランスであり、ネットワークバンド幅要求が増加するとき、ホスト遅延は低減する。今日、トラヒック形成は一般的にトークンバケットおよびリークバケットシェーパの何れかを使用して達成され、いくつかの例では両者を組み合わせて使用される。
【0149】
トークンバケットシェーピングはパケットバーストがネットワークへ入力されるのを防ぐことはできないが、バーストの大きさの範囲を限定することはよく知られている。したがってトークンバケット形成では、図7に示したようにパケットシーケンス(単一のパケットであってもよい)および隣のパケットシーケンスの始めから測定される時間期間において、瞬間値が計算されるとき、フローレートが特定のピークレートを瞬間的に超える可能性は無くならない。この定義に基づいて、フローに対する瞬間的なピークレートは式11によって得られる:
【数5】
【0150】
なお、lpacketはビット内のパケットの大きさであり、代数の和は特定の時間スパンによって含まれる全てのパケットにおける和、例えば図7内のt1ないしt5のようなものであると考えられる。
【0151】
使用されるシェーピングプロセスは、瞬間ピークレートが特定のピークレートを超えないとき、これを厳密なピークレート形成として次に記載する。
【0152】
従来のトークンバケット形成が厳密なピークレート形成を行なうことができない理由は、適切な数のトークンを使用できるようになると直ぐに、使用されたスケジューリングアルゴリズムによってパケットをネットワークへ入力できるからである。図6には、トークンバケットによって生成されるフローと、範囲を定められた遅延バッファの特定の瞬間的な充填に対するピークレート形成との間の品質上の比較を示した。式(11)にしたがって計算されるとき、厳密なピークレート形成によってフローが特定のピークレートを超えないようにするとき、フローAとCとの比較から、この特定の例においてトークンバケット形成フローが特定のピークレートを超えることが明らかである。出力フローは、トークンバケットが最初にトークンで満たされており、出力リンク速度が特定のピークレートよりも著しく大きいといった特定の形態をとることに注意すべきである。さらに、次の式(12)内のバケット充填レートrおよびPk flowの項は両者とも特定のピークレートの同じ値に等しい。
【0153】
制御された量のパケットのバンチングが許容できるものになると予測されるが、いくつかの実施では従来のトークンバケットまたはリークバケットシェーピングではなく、厳密なピークレートシェーピングを使用することが好都合である。これは瞬間ピークレートにより密接な制御を与える。密接なピークレートシェーピングを達成する1つの方法を図6に示した:便宜上、図5に示した最善を尽くす素子は、シェーピングプロセスに寄与しない範囲を定められた遅延クラスからの素子と一緒に、取り除いてある。ピークレートシェーピングは、ネットワークへのフローレートが特定のピークレートを超えないことを保証できるようなやり方で、効果的にパケットの組のシェーピングを妨げる。これを満足させるスケジューリングアルゴリズムの良い例は、パケットをネットワークへ入力する判断が先行するパケットの大きさおよびこのパケットが送られた時間に基づいていることである。したがって先行するパケットτn lapseの受け付けが式(12)の関係を満足させるので、スケジューリング素子は時間を経過するまで新しいパケットをネットワークへ受け付けない:
【数6】
【0154】
なお、lpacketはビット内のパケットの大きさを表わし、ビット/秒でフローに対する特定のピークレートを表わす。上付き符号nは送られるパケットを表わし、上付き符号n−1は先に送られたパケットを表わす。
【0155】
適切なバケットの大きさを与えられたトークンバケットシェーパを使用する厳密なピークレートシェーピングの実行は、現在使用されているものと異なるスケジューリング規則と関連して使用することも可能である。例えば範囲を定められた遅延クラスに対して特定の最大の許容されるパケットの大きさがあるとき、パケットレートシェーピングは、トークンバケットがいっぱいになるまでパケットを送ることができないといった規則と関連して、最大の許容されるパケットの大きさに等しいバケットの大きさを使用して達成される。バケットがいっぱいになると、トークンバケットが空になるか、またはバッファが空になるまで、バッファを完全に使用する。トークンバケットが再び完全にいっぱいになるまでは、パケットをこれ以上送らない、など。図6の品質上の比較において仮定される条件にこの解決案を使用して、フローBによって示された組と類似する組が生成される。
【0156】
しかしながら、(r,T)−スムーススケジューリングアルゴリズムに基づくシェーパを含むより一般的なタイプのシェーパは除外されない。
【0157】
使用されるシェーピングのタイプとは無関係に、図5のホスト構成(53)は、他の制御パラメータ、例えばパケットの大きさ、バッファ割り当て、およびピークフローレートと関連する適切なシェーパパラメータを選択することができる。しかしながらIP統合サービスを支援しているネットワークにおいてこのホストが使用されるときは、トークンバケットシェーピングを使用することになり、全てでないとしても、ほとんどの他のパラメータおよびトークンバケットのパケットが、新しいフローに対して選択されてしまうと、定数として扱われる。この主な理由は、これらのパラメータのいくつかをネットワーク内で分配する必要があり、これはいつパラメータが変更されてもRSVPシグナリング段階を開始することを含むからである。これは、シグナリング遅延が変更を実行するレートを厳密に制限するので、フローを最初に設定するときは特に関係ない。これは、フローが確立されるとホストの実行と二地点間遅延との両方にアプリケーションをもつ制御を厳密に制限する。範囲を定められた遅延クラスを支援するネットワークを使用するときは除外される。
【0158】
範囲を定められる遅延動作を呼出す1つの簡単な実施形態において、ネットワークによって要求される唯一の情報は、フローの要求されるピークレートであり、これは‘オンザフライ’シグナリングによって用意することができる。したがって、アプリケーションはフローの寿命中にホストの実行をモニタし続け、要求される回数だけ、ネットワークを含む必要なく必要なバッファ割り当て、パケットの大きさ、パケットの放棄、またはパケットレートを調節することができる。したがってアプリケーションは、通常可能なホストの動作よりもはるかに多数のダイナミックな制御を行なう。例えばアプリケーションは、最初に選択されるデータレートに対して不十分なバッファの大きさを選択すると、パケットを放棄し、増加した遅延を犠牲にしてバッファの大きさを増加し、低減されたバンド幅効率を犠牲にしてパケットの大きさを低減する(単位時間当たりのヘッダは増加する)ことができるオプションをもつか、またはネットワークからより高いピークレートを要求することができる。
【0159】
上述の本発明の実施形態では範囲を定められた遅延クラスおよびコネクションレスの最善を尽くすクラスに関して記載したが、一定の範囲の別のサブクラスも可能である。
【0160】
例えば範囲を定められた遅延クラスに対して、このやり方を取り入れて、新しいフローがCACプロセスの一部として最大のパケットの大きさに信号を送るとすると、別々のクラスを2以上の特定の範囲のパケットの大きさに定義することができる。各パケットに対するバンド幅またはバッファ資源の割り当てを別々に制御することによって、受け付けられたフローごとにパケットの大きさを分配するための制御を行ない、これにより全体的なバンド幅遅延クラスのバンド幅使用を向上させることができる。このやり方の1つの潜在的な長所は、パケットの大きさが小さいフローを受け付ける可能性が向上することである。
【0161】
さらにサブクラスを設定して、範囲を定められた遅延の異なる値を用意することもできる。これは、主な範囲を定められた遅延待ち行列内の多数の仮想待ち行列にパケットを分けることによって達成することができる。
【0162】
最善を尽くすクラス内では同様に、ランダムのようなトラヒック管理様式の構成―すなわち初期検出(RED)、優先待ち行列、IETF IntServ、クラスベースの待ち行列(CBQ)、および他のこのような技術は除外されない。
【図面の簡単な説明】
【図1】 ネットワーク素子の異なるアーキテクチャの構成を示す模式図。
【図2】 図1に示したネットワーク素子を含む異なるネットワークアーキテクチャの模式図。
【図3】 異なるネットワーク構成の機能として、ネットワーク内の送信ホストと受信ホストとの間の関係する遅延を示すグラフ。
【図4】 図3に関係して使用する例示的なパケット構造を示す模式図。
【図5】 例示的なホストアーキテクチャ構造を示す模式図。
【図6】 2つのトラヒック形成方法の比較を示す模式図。
【図7】 例示的なフローを示すグラフ。
Claims (15)
- パケットネットワーク素子であって:
フローベースのパケットを受取る少なくとも1つの入力と;
所定のバンド幅の少なくとも1つの出力とを備え;
ここでは受取ったパケットは第1および第2のサービスクラスと関係しているものであるとし、さらに;
各受取ったパケットをそのサービスクラスに基づいて、第1または第2の対応するパケットバッファへ向ける手段を備え;
前記第1のパケットバッファは出力バンド幅の所定の部分に割り当てられており、また、
前記第2のパケットバッファは出力バンド幅の残りの部分に割り当てられており;
このパケットネットワーク素子は、前記第1のクラスのフローと関係するバンド幅要求を判断するバンド幅要求判断手段と;
前記バンド幅要求を満たすことができると、第1のパケットバッファに向けて第1のクラスのフローパケットの受け付けを許可する手段と;
第1および第2のパケットバッファから出力へパケットを向ける手段と、
第2のクラスのフローパケット内の宛先アドレスに依存して前記第2のクラスのフローパケットをルート設定するように設けられた第2のクラスのフロールート設定手段とを含むパケットネットワーク素子。 - 受け付けを許可する前記手段は、出力バンド幅の前記所定の部分中の現在使用されていない部分が前記ピークレートのバンド幅要求を満たすことができるときには、第1のバッファへの受け付けを許可するピークレート試験を適用するように動作する請求項1記載の素子。
- 受け付けを許可する前記手段は前記ピークレート試験を適用し、前記第1のパケットバッファが別のフローを受理するのに十分なスペースをもつときに受け付けを許可するバッファ充填試験を適用するように動作する請求項2記載の素子。
- 前記受け付け許可手段は:
第1のパケットバッファを収容できる大きさにされたフロー数から現在収容されているフロー数を減算した数が少なくとも1であるとき;および、
第1のパケットバッファに割り当てられた出力バンド幅の使用されていない部分から提案されたピークレートのフローのバンド幅要求を減算した数がゼロに等しいかまたはそれよりも大きいときのみ;
第1のパケットバッファに対して第1のクラスのフローパケットの受け付けを許可するようにされている請求項3記載の素子。 - 前記受け付け許可手段はフローが中止するときに前記未使用の部分の大きさを増加するように動作し、前記増加が、そのフローと関係するピークレートによって除算されたパケットの大きさに実質的に等しい時間期間の経過後に行われる請求項4記載の素子。
- 第1のクラスのフローパケットが第1のパケットバッファに対して受け付けを拒否されたとき、第1のクラスのフローパケットを第2のパケットバッファに受け付ける手段をさらに含む請求項1ないし5の何れか1項記載の素子。
- 前記ピークレートバンド幅要求判断手段が、前記受取ったパケットからピークレートのフローバンド幅要求情報部分を読み取るようにされている請求項2ないし5の何れか1項記載の素子。
- 第1のパケットバッファに割り当てられる出力バンド幅の前記所定の部分をダイナミックに変更することができる請求項1ないし7の何れか1項記載の素子。
- 前記ピークレートバンド幅要求判断手段が、各単一のパケットフローに対する特定のピークレートフローバンド幅要求値を判断するようにされている請求項2記載の素子。
- 前記受取ったパケットが第1または第2のサービスクラスと関係するか否かを判断するクラス判断手段をさらに含む請求項1ないし9の何れか1項記載の装置。
- クラス判断手段が、パケットが範囲を定められた遅延のサービスクラスかまたは最善を尽くすサービスクラスの一方と関係するか否かを判断するようにされている請求項10記載の素子。
- 前記クラス判断手段が、前記受取ったパケットからクラス識別部分を読み取るようにされている請求項10または11記載の素子。
- パケットネットワーク素子内のフローベースのパケットを
制御する方法であって:
フローベースのパケットを受け取り;
受取ったパケットが第1または第2のサービスクラスと関係し;
その関係するクラスに基づいて各受取ったパケットを第1または第2の対応するパケットバッファへ向け;
前記第1のパケットバッファが所定の出力バンド幅の所定の部分に割り当てられ;
前記第2のパケットバッファが出力バンド幅の残りの部分に割り当てられ;
フローに関係する実行基準を判断し;
前記実行基準を満たすことができるとき、第1のパケットバッファに対して第1のクラスのフローパケットの受け付けを許可することができ;
第1および第2のパケットバッファから出力へパケットを向け、
第2のクラスのフローパケット内の宛先アドレスに依存して前記第2のクラスのフローをルート設定することを含む方法。 - 請求項1ないし12の何れか1項に記載されている1または複数の素子をさらに含むネットワーク。
- フローベースのパケットを受取る少なくとも1つの入力と;
所定のバンド幅の少なくとも1つの出力と;
受取ったパケットが第1または第2のサービスクラスと関係するか否かを判断する第1の手段と;
各受取ったパケットをその関係するクラスに基づいて第1または第2の対応するパケットバッファへ送る手段と;
所定数のフローを収容する所定の大きさをもち、出力バンド幅の所定の部分を割り当てられ、現在未使用の部分が収容されるフロー数で変化する前記第1のパケットバッファと;
出力バンド幅の残りの部分を割り当てられている前記第2のパケットバッファと;
フローと関係するピークレートのバンド幅要求を判断する第2の手段と;
第1のパケットバッファが別のフローを受理できるとき、および前記現在未使用の部分が関係するピークレートのフローバンド幅要求を満たすことができるときに、第1のクラスフローパケットを第1のパケットバッファに受け付けることができる手段と;
第1または第2のパケットバッファから出力へパケットを向ける手段と、
第2のクラスのフローパケット内の宛先アドレスに依存して前記第2のクラスのフローパケットをルート設定するように設けられた第2のクラスのフロールート設定手段とを含むパケットネットワーク素子。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP97306976 | 1997-09-09 | ||
GBGB9725985.7A GB9725985D0 (en) | 1997-12-08 | 1997-12-08 | Packet network |
GB97306976.8 | 1997-12-08 | ||
GB9725985.7 | 1997-12-08 | ||
PCT/GB1998/002727 WO1999013624A1 (en) | 1997-09-09 | 1998-09-09 | Packet network |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001516992A JP2001516992A (ja) | 2001-10-02 |
JP4201978B2 true JP4201978B2 (ja) | 2008-12-24 |
Family
ID=26147594
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000511292A Expired - Lifetime JP4201978B2 (ja) | 1997-09-09 | 1998-09-09 | パケットネットワーク |
Country Status (7)
Country | Link |
---|---|
US (1) | US6538989B1 (ja) |
EP (1) | EP1013049B1 (ja) |
JP (1) | JP4201978B2 (ja) |
AU (1) | AU9084398A (ja) |
CA (1) | CA2302218C (ja) |
DE (1) | DE69818846T2 (ja) |
WO (1) | WO1999013624A1 (ja) |
Families Citing this family (87)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6747959B1 (en) | 1998-10-07 | 2004-06-08 | At&T Corp. | Voice data integrated mulitaccess by self-reservation and blocked binary tree resolution |
US6963545B1 (en) | 1998-10-07 | 2005-11-08 | At&T Corp. | Voice-data integrated multiaccess by self-reservation and stabilized aloha contention |
GB9822550D0 (en) * | 1998-10-15 | 1998-12-09 | British Telecomm | Computer communications |
US6785260B1 (en) * | 1998-12-18 | 2004-08-31 | A.T.&T. Corp. | Method and apparatus for routing of best-effort and quality of service flows |
US6798743B1 (en) * | 1999-03-22 | 2004-09-28 | Cisco Technology, Inc. | Packet prioritization processing technique for routing traffic in a packet-switched computer network |
US6567379B1 (en) * | 1999-06-09 | 2003-05-20 | Cisco Technology, Inc. | Traffic monitor using leaky bucket with variable fill |
SE516754C2 (sv) * | 1999-06-24 | 2002-02-26 | Telia Ab | Ett telekommunikationssystem som använder ett resursreserveringsprotokoll |
US6633540B1 (en) | 1999-07-02 | 2003-10-14 | Nokia Internet Communications, Inc. | Real-time traffic shaper with keep-alive property for best-effort traffic |
JP2001111619A (ja) * | 1999-10-12 | 2001-04-20 | Sony Corp | 送信装置、通信システム及びその通信方法 |
US6820117B1 (en) * | 1999-10-18 | 2004-11-16 | Sun Microsystems, Inc. | Bandwidth management |
US6577596B1 (en) | 1999-11-30 | 2003-06-10 | Telefonaktiebolaget Ln Ericsson (Publ) | Method and apparatus for packet delay reduction using scheduling and header compression |
US7010611B1 (en) * | 1999-12-21 | 2006-03-07 | Converged Access, Inc. | Bandwidth management system with multiple processing engines |
US6671258B1 (en) * | 2000-02-01 | 2003-12-30 | Alcatel Canada Inc. | Dynamic buffering system having integrated random early detection |
US6990529B2 (en) * | 2000-02-24 | 2006-01-24 | Zarlink Semiconductor V.N., Inc. | Unified algorithm for frame scheduling and buffer management in differentiated services networks |
US6801500B1 (en) * | 2000-05-18 | 2004-10-05 | Cisco Technology, Inc. | Method and apparatus for providing reserved rates to multiple flows on a network interface |
US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
US6850981B1 (en) | 2000-07-14 | 2005-02-01 | At&T Corp. | System and method of frame scheduling for QoS-driven wireless local area network (WLAN) |
US7068632B1 (en) * | 2000-07-14 | 2006-06-27 | At&T Corp. | RSVP/SBM based up-stream session setup, modification, and teardown for QOS-driven wireless LANs |
US6970422B1 (en) | 2000-07-14 | 2005-11-29 | At&T Corp. | Admission control for QoS-Driven Wireless LANs |
US7151762B1 (en) | 2000-07-14 | 2006-12-19 | At&T Corp. | Virtual streams for QoS-driven wireless LANs |
US7031287B1 (en) | 2000-07-14 | 2006-04-18 | At&T Corp. | Centralized contention and reservation request for QoS-driven wireless LANs |
US7068633B1 (en) | 2000-07-14 | 2006-06-27 | At&T Corp. | Enhanced channel access mechanisms for QoS-driven wireless lans |
US6999442B1 (en) | 2000-07-14 | 2006-02-14 | At&T Corp. | RSVP/SBM based down-stream session setup, modification, and teardown for QOS-driven wireless lans |
US6950397B1 (en) | 2000-07-14 | 2005-09-27 | At&T Corp. | RSVP/SBM based side-stream session setup, modification, and teardown for QoS-driven wireless lans |
US7756092B1 (en) | 2000-07-14 | 2010-07-13 | At&T Intellectual Property Ii, L.P. | In-band QoS signaling reference model for QoS-driven wireless LANs connected to one or more networks |
US6862270B1 (en) | 2000-07-14 | 2005-03-01 | At&T Corp. | Architectural reference model for QoS-driven wireless LANs |
US7039032B1 (en) | 2000-07-14 | 2006-05-02 | At&T Corp. | Multipoll for QoS-Driven wireless LANs |
US6804222B1 (en) | 2000-07-14 | 2004-10-12 | At&T Corp. | In-band Qos signaling reference model for QoS-driven wireless LANs |
JP2002051057A (ja) * | 2000-08-04 | 2002-02-15 | Fujitsu Ltd | Atm交換機 |
US7313593B1 (en) | 2000-10-24 | 2007-12-25 | International Business Machines Corporation | Method and apparatus for providing full duplex and multipoint IP audio streaming |
KR100551859B1 (ko) * | 2000-11-17 | 2006-02-13 | 인피니언 테크놀로지스 노쓰 아메리카 코포레이션 | 패킷 처리 장치 |
US20050088977A1 (en) * | 2000-12-14 | 2005-04-28 | Nortel Networks Limited | Dynamic virtual private network (VPN) tunnel quality of service (QoS) treatment |
US7613823B1 (en) | 2001-02-20 | 2009-11-03 | At&T Intellectual Property Ii, L.P. | Enhanced channel access mechanisms for an HPNA network |
US7180855B1 (en) | 2001-04-19 | 2007-02-20 | At&T Corp. | Service interface for QoS-driven HPNA networks |
US7142563B1 (en) | 2001-02-20 | 2006-11-28 | At&T Corp. | Service interface for QoS-driven HPNA networks |
US7382727B2 (en) * | 2001-02-21 | 2008-06-03 | Cisco Technology, Inc. | System and method for asymmetrical bandwidth management |
US7486686B2 (en) * | 2001-02-26 | 2009-02-03 | Vitesse Semiconductor Corporation | Method and apparatus for scheduling data on a medium |
US6901050B1 (en) * | 2001-03-05 | 2005-05-31 | Advanced Micro Devices, Inc. | Systems and methods for flow-based traffic shaping |
EP1239635A1 (en) * | 2001-03-07 | 2002-09-11 | BRITISH TELECOMMUNICATIONS public limited company | Method of providing service classes in a packet network |
EP1251669A1 (en) | 2001-04-19 | 2002-10-23 | BRITISH TELECOMMUNICATIONS public limited company | Communications network |
US6944168B2 (en) * | 2001-05-04 | 2005-09-13 | Slt Logic Llc | System and method for providing transformation of multi-protocol packets in a data stream |
US6901052B2 (en) * | 2001-05-04 | 2005-05-31 | Slt Logic Llc | System and method for policing multiple data flows and multi-protocol data flows |
US7042848B2 (en) * | 2001-05-04 | 2006-05-09 | Slt Logic Llc | System and method for hierarchical policing of flows and subflows of a data stream |
US6904057B2 (en) * | 2001-05-04 | 2005-06-07 | Slt Logic Llc | Method and apparatus for providing multi-protocol, multi-stage, real-time frame classification |
US7339903B2 (en) * | 2001-06-14 | 2008-03-04 | Qualcomm Incorporated | Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address |
US7027400B2 (en) * | 2001-06-26 | 2006-04-11 | Flarion Technologies, Inc. | Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system |
US8000241B2 (en) * | 2001-06-26 | 2011-08-16 | Qualcomm Incorporated | Methods and apparatus for controlling access link packet flow aggregation and resource allocation in a mobile communications system |
US7035210B2 (en) * | 2001-07-12 | 2006-04-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Media stream delay monitoring for node |
US7177271B2 (en) * | 2001-09-21 | 2007-02-13 | Microsoft Corporation | Method and system for managing admission to a network |
US7362701B2 (en) * | 2002-01-14 | 2008-04-22 | Sun Microsystems, Inc. | Customer-based service system including a cascaded pipeline with self-monitoring relays |
US20030135575A1 (en) * | 2002-01-14 | 2003-07-17 | Richard Marejka | Self-monitoring and trending service system with cascaded pipeline linking numerous client systems |
EP1335535A1 (en) | 2002-01-31 | 2003-08-13 | BRITISH TELECOMMUNICATIONS public limited company | Network service selection |
US7782776B2 (en) * | 2002-03-15 | 2010-08-24 | Broadcom Corporation | Shared weighted fair queuing (WFQ) shaper |
US20030174650A1 (en) * | 2002-03-15 | 2003-09-18 | Broadcom Corporation | Weighted fair queuing (WFQ) shaper |
US7161904B2 (en) | 2002-06-04 | 2007-01-09 | Fortinet, Inc. | System and method for hierarchical metering in a virtual router based network switch |
US20040083287A1 (en) * | 2002-10-25 | 2004-04-29 | Xia Gao | Terminal-based resource reservation protocol |
FI112421B (fi) * | 2002-10-29 | 2003-11-28 | Tellabs Oy | Menetelmä ja laitteisto siirtoyhteyskapasiteetin vuorottamiseksi pakettikytkentäisten tietoliikennevoiden kesken |
US8520520B2 (en) * | 2002-11-06 | 2013-08-27 | Avaya, Inc. | System and method for per flow guaranteed throughput, multiple TCP flow bandwidth provisioning, and elimination of packet drops for transmission control protocol (TCP) and TCP-friendly protocols |
CN1297097C (zh) * | 2003-04-09 | 2007-01-24 | 华为技术有限公司 | 提高网络拥塞时数据传输性能的方法 |
US7477604B2 (en) * | 2003-05-14 | 2009-01-13 | Ntt Docomo, Inc. | Packet communications system |
US7382801B2 (en) * | 2003-09-03 | 2008-06-03 | At&T Deleware Intellectual Property, Inc. | Link capacity dimensioning methods for packet switched communications networks, and networks and links dimensioned thereby |
JP4335619B2 (ja) * | 2003-09-04 | 2009-09-30 | 株式会社エヌ・ティ・ティ・ドコモ | パケット優先制御装置及びその方法 |
US7411971B2 (en) * | 2003-09-09 | 2008-08-12 | Avaya Inc. | Systems and methods for the schedule alignment of packet flow |
KR100601043B1 (ko) * | 2003-11-13 | 2006-07-14 | 한국전자통신연구원 | 패킷을 스케줄링하는 라우터 및 그 방법 |
JP4628162B2 (ja) | 2004-04-16 | 2011-02-09 | 株式会社ソニー・コンピュータエンタテインメント | 通信端末装置、通信システムおよび電力制御方法 |
US7545815B2 (en) * | 2004-10-18 | 2009-06-09 | At&T Intellectual Property Ii, L.P. | Queueing technique for multiple sources and multiple priorities |
CN101076980A (zh) * | 2004-11-11 | 2007-11-21 | 三菱电机株式会社 | 通信网络的ip分组中继方法和网关装置 |
US9065595B2 (en) * | 2005-04-07 | 2015-06-23 | Opanga Networks, Inc. | System and method for peak flow detection in a communication network |
US8949452B2 (en) * | 2005-04-07 | 2015-02-03 | Opanga Networks, Inc. | System and method for progressive download with minimal play latency |
US8909807B2 (en) * | 2005-04-07 | 2014-12-09 | Opanga Networks, Inc. | System and method for progressive download using surplus network capacity |
US7474662B2 (en) * | 2005-04-29 | 2009-01-06 | International Business Machines Corporation | Systems and methods for rate-limited weighted best effort scheduling |
US7948962B2 (en) | 2007-08-31 | 2011-05-24 | Wireless Technology Solutions Llc | Cellular communication system, apparatus and method for management of backhaul resources |
US8284696B2 (en) * | 2007-12-17 | 2012-10-09 | Cisco Technology, Inc. | Tracking customer edge traffic |
US8553554B2 (en) | 2008-05-16 | 2013-10-08 | Alcatel Lucent | Method and apparatus for providing congestion control in radio access networks |
US20090296613A1 (en) * | 2008-06-03 | 2009-12-03 | Colin Kahn | Method and apparatus for providing quality-of-service in radio access networks |
US8503432B2 (en) * | 2008-09-30 | 2013-08-06 | Alcatel Lucent | Method and apparatus for signaling proprietary information between network elements of a core network in a wireless communication network |
US8027255B2 (en) * | 2008-09-30 | 2011-09-27 | Alcatel Lucent | Method and apparatus for prioritizing packets for use in managing packets in radio access networks |
JP5205289B2 (ja) * | 2009-01-14 | 2013-06-05 | パナソニック株式会社 | 端末装置およびパケット送信方法 |
US8289870B2 (en) * | 2009-09-23 | 2012-10-16 | Avaya Inc. | Priority-based, dynamic optimization of utilized bandwidth |
US9467388B2 (en) * | 2012-08-29 | 2016-10-11 | Universiteit Gent | Method and device for scheduling data traffic |
US9542294B2 (en) | 2013-07-09 | 2017-01-10 | International Business Machines Corporation | Method to apply perturbation for resource bottleneck detection and capacity planning |
WO2017167607A1 (en) | 2016-03-29 | 2017-10-05 | British Telecommunications Public Limited Company | Methods and apparatus for transmitting data |
US10015103B2 (en) * | 2016-05-12 | 2018-07-03 | Getgo, Inc. | Interactivity driven error correction for audio communication in lossy packet-switched networks |
US11159440B2 (en) * | 2017-11-22 | 2021-10-26 | Marvell Israel (M.I.S.L) Ltd. | Hybrid packet memory for buffering packets in network devices |
US10805223B1 (en) * | 2019-04-10 | 2020-10-13 | Dell Products L.P. | Systems and methods for handling data congestion for shared buffer switches with dynamic thresholding |
WO2021033504A1 (ja) * | 2019-08-22 | 2021-02-25 | 富士フイルム株式会社 | カルボニル化合物の製造方法、及びカルボニル化合物を製造するフロー式反応システム |
CN113676416B (zh) * | 2021-10-22 | 2021-12-28 | 浙江锐文科技有限公司 | 一种在高速网卡/dpu内提升网络服务质量的方法 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI92362C (fi) | 1992-12-14 | 1994-10-25 | Nokia Telecommunications Oy | Menetelmä kehysvälitysverkon ylikuormitustilanteiden hallitsemiseksi sekä kehysvälitysverkon solmu |
JP3354689B2 (ja) * | 1994-02-28 | 2002-12-09 | 富士通株式会社 | Atm交換機、交換機及びそのスイッチングパス設定方法 |
US5917822A (en) * | 1995-11-15 | 1999-06-29 | Xerox Corporation | Method for providing integrated packet services over a shared-media network |
US5875175A (en) * | 1997-05-01 | 1999-02-23 | 3Com Corporation | Method and apparatus for time-based download control |
US5982736A (en) * | 1997-05-15 | 1999-11-09 | Pierson; Gerald A. | Trading card optical compact disc and methods of using and forming same |
US6108307A (en) * | 1997-12-12 | 2000-08-22 | Newbridge Networks Corporation | Frame relay priority queses to offer multiple service classes |
US6229788B1 (en) * | 1998-05-27 | 2001-05-08 | Nortel Networks Limited | Method and apparatus for traffic shaping in a broadband fiber-based access system |
-
1998
- 1998-09-09 US US09/180,102 patent/US6538989B1/en not_active Expired - Lifetime
- 1998-09-09 DE DE69818846T patent/DE69818846T2/de not_active Expired - Lifetime
- 1998-09-09 AU AU90843/98A patent/AU9084398A/en not_active Abandoned
- 1998-09-09 JP JP2000511292A patent/JP4201978B2/ja not_active Expired - Lifetime
- 1998-09-09 WO PCT/GB1998/002727 patent/WO1999013624A1/en active IP Right Grant
- 1998-09-09 CA CA002302218A patent/CA2302218C/en not_active Expired - Lifetime
- 1998-09-09 EP EP98942868A patent/EP1013049B1/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
DE69818846D1 (de) | 2003-11-13 |
DE69818846T2 (de) | 2004-08-05 |
WO1999013624A1 (en) | 1999-03-18 |
AU9084398A (en) | 1999-03-29 |
US6538989B1 (en) | 2003-03-25 |
CA2302218A1 (en) | 1999-03-18 |
CA2302218C (en) | 2007-11-06 |
EP1013049A1 (en) | 2000-06-28 |
JP2001516992A (ja) | 2001-10-02 |
EP1013049B1 (en) | 2003-10-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4201978B2 (ja) | パケットネットワーク | |
Zhao et al. | Internet quality of service: An overview | |
White | RSVP and integrated services in the Internet: A tutorial | |
US7126918B2 (en) | Micro-flow management | |
Terzis et al. | A two-tier resource management model for the Internet | |
KR100542401B1 (ko) | 인터넷 차별 서비스 망에서의 연결 수락 제어방법 | |
EP1035688B1 (en) | An RSVP-based tunnel protocol providing integrated services | |
US8638664B2 (en) | Shared weighted fair queuing (WFQ) shaper | |
US6674718B1 (en) | Unified method and system for scheduling and discarding packets in computer networks | |
US20050131984A1 (en) | Method for transmitting data from applications with different quality | |
US8773998B2 (en) | Technique for reducing resources allocated to an existing reservation in a data network | |
KR20050037073A (ko) | 인터넷 차별 서비스 망에서 입력 호 상태를 반영한 적응적연결 수락 제어방법 | |
Terzis et al. | A prototype implementation of the two-tier architecture for differentiated services | |
KR100615850B1 (ko) | 라우터의 입력 포트와 출력 포트간의 개방형 인터페이스 장치 및 이를 이용한 차등 서비스 제공 방법 | |
Cisco | Congestion Management Overview | |
Jeong et al. | QoS support for UDP/TCP based networks | |
Cisco | Quality of Service for Voice over IP | |
JP2002305538A (ja) | 通信品質制御方法、サーバ及びネットワークシステム | |
Chimento | Tutorial on QoS support for IP | |
May et al. | An experimental implementation of traffic control for IP networks | |
Dobrescu et al. | Interoperability of integrated services and differentiated services architectures | |
Fraietta et al. | A DiffServ–IntServ Integrated QoS Provision Approach in BRAHMS Satellite System | |
Chimento | Tutorial on Internet Services for SURFnet4 Infrastructure Project 1998 | |
Jeong et al. | QoS Support for Real-Time Applications Using the Integration of RSVP/Intserv and Diffserv: A Testbed Experiment | |
JP2002026977A (ja) | データ通信システムにおける帯域配信サービス方法及びそれを実行するための通信装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050901 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070514 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070522 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20070803 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20070810 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071115 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080226 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080624 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080707 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080909 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081008 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111017 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131017 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |