JP2000324159A - バッファ管理によるレート保証方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 バッファの高機能管理によってルータ内の個
々のフローまたはフローのグループにレート保証を提供
する方法。 【解決手段】 各フローにとって使用可能なバッファの
賢明な割り振りと分離を行うことによってレート保証を
提供する。最も基本的な態様では、この方法は、レート
予約を使用するいくつかのストリームを多重化して出力
リンクに送出しようとする、単純なＦＩＦＯスケジュー
ラを備えた出力待ち行列化ネットワーク装置に適用され
る。この方法は、バッファを、リンク予約に比例してフ
ローごとに厳密に予約されたいくつかの部分に厳密に区
分化する。これによって、各ストリームがリンク予約レ
ートをスケーラブルな方式で獲得するように保証され
る。本発明の特定の実施形態では、バッファの一部を厳
密に区分化することができると同時に、ストリームがバ
ッファの残りの部分に完全にアクセスできるようにす
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にパケット・
データ伝送システムに関し、より詳細には、ルータにお
ける個別フローまたはフローのグループにサービス品質
を提供するパケット・データ伝送システムに関する。

【０００２】

【従来の技術】多くのアプリケーションは本質的に、適
正に機能するためにネットワークが安定したパケットの
ストリームを提供することを必要とする。いくつかの典
型例は、テレビ会議やビデオ・オン・デマンド・アプリ
ケーションのように音声再生またはビデオ再生を伴うも
のである。このようなアプリケーションのほとんどは、
ネットワークが終端間で一定の最小帯域幅を提供しなけ
れば、パフォーマンスがきわめて悪くなる。さらに、い
くつかのビデオ及び音声コーダは、提供される帯域幅に
基づいて符号化速度を変化させることがある。したがっ
て、ネットワークが提供できる帯域幅が事前にわかって
いれば、このようなアプリケーションが符号化プロセス
のために適切なパラメータを選定するのに有用である。
ネットワークがフローに最小レート保証を提供すること
ができれば、送信側はそのレートを使用してネットワー
クにパケットを適切に配送し、それによって受信側がパ
ケットの途切れないストリームを得られるようにするこ
とができる。その最終的な結果、受信側で円滑で適時な
再生動作が行われる。

【０００３】終端間レート保証の確保が最も有用と考え
られる他の多くの応用分野がある。仮想私設ネットワー
クでは、このようなレート保証を使用して、セットアッ
プする必要がある仮想リンクのサイズと数を決定するこ
とができる。レート保証をネットワークから特定のレベ
ルのサービスを得るための手段として使用することがで
きる他の状況もある。たとえば、ワールド・ワイド・ウ
ェブ環境では、レート保証が高ければ、それに正比例し
てウェブ・ページをダウンロードする時間が短縮され
る。

【０００４】サービス保証、特にレート保証の提供は、
パケット・ネットワーク、特にインターネットではます
ます重要になりつつある。これは、新しい応用分野にお
ける要件の多様性と、インターネットの商業化の拡大の
両方による。このようなサービス保証をサポートするに
は、各フローまたはフローの集合が使用することができ
る資源の量をネットワークが制御する必要がある。使用
を制御すべきネットワーク資源は、主としてバッファと
リンク帯域幅から成り、それに付随する機構はバッファ
管理とスケジューリングである。

【０００５】図１は、送信側２０と受信側２１との間の
フロー５０（またはフローの集合）がネットワーク１を
通過するときに、そのフローに所与のレベルのサービス
を保証する必要がある事例を示す、従来技術の例であ
る。送信側２０から発信されたパケットは、ネットワー
ク１を通過するとき、リンク３０〜３４とネットワーク
要素、たとえばスイッチまたはルータ１１〜１４を通
る。この例で制御する必要がある資源は、リンク３０〜
３４上の帯域幅とネットワーク要素１１〜１４における
バッファ空間である。この制御は、コントローラ４０〜
４３によって行われ、各コントローラはフロー５０から
のパケットが対応するネットワーク要素及びリンクにお
けるそれぞれ十分なバッファ及び帯域幅にアクセスする
ことができるように保証する役割を果たす。たとえば、
コントローラ４１は、同じ資源をめぐって競合するフロ
ー６４及び６５からの衝突するトラフィックがあって
も、フロー５０に対してネットワーク要素１３内のバッ
ファとリンク３３の帯域幅を保証する役割を果たさなけ
ればならない。

【０００６】このような資源コントローラの実施にはコ
ストが伴う。資源コントローラは、パケットに対してと
るべき適切な処置を判断し、所望のサービス保証を実施
するために、受け取ったパケットごとにいくつかの処理
ステップを行う必要がある。このコストは、これらのパ
ケットごとの処理ステップの数と複雑さに応じて変わ
り、通常は提供するサービス保証の正確度及び効率と共
に増大する。その結果、サービス保証を提供する際の所
与のレベルのパフォーマンスが得られる可能な最小限の
コストで資源コントローラを実現するために使用するこ
とができる機構を突き止めることが望ましい。具体的に
は、これはリンク速度の向上に比例して拡張可能な解決
策を考案することを意味する。

【０００７】これに関連して、資源制御の一般的コスト
構成要素を理解することが重要である。前述のように、
バッファ管理とスケジューリングの２つのタイプの資源
制御機構があり、それぞれバッファへのアクセスとリン
ク帯域幅を制御する機能を果たす。この２つのうち、パ
ケット・スケジューリング・コストは一般的にはバッフ
ァ管理に付随するコストよりも大きいことがわかる。こ
れは、バッファ管理には、パケット着信時点でそのパケ
ットを受け容れるか廃棄するかを決定する必要があり、
この決定は一定量の「状態」情報に基づいて行うことが
できる。具体的には、バッファ管理決定を行う際に使用
される情報は、一般には、総バッファ内容量や、フロー
の現行パケット数などのフロー固有の状態情報など、全
体的な状態情報から成る。このモデルに相当する既存の
バッファ管理機構としては多くの例がある。比較的一般
的なものとしては、しきい値に基づく機構［Ｉ．シドン
（Cidon）、Ｒ．ゲラン（Guerin）、及びＡ．カミシー
（Khamisy）の「Protectivebuffer management policie
s」（IEEE/ACM Trans. Networking, 2(3):２４０〜２４
６ページ、１９９Ｘ年６月）］、早期パケット廃棄（Ea
rly Packet Discard：ＥＰＤ）［Ａ．ロマナウ（Romano
w）及びＳ．フロイド（Floyd）の「Dynamicsof TCP tra
ffic over ATM networks」(IEEE J. Sel. Areas Commu
n. 13(4):６３３〜６４１ページ、１９９５年５月）、
Ｊ．ターナー（Turner）の「Maintaining high through
put during overload in ATM switches」（米国カリフ
ォルニア州サンフランシスコ１９９６年４月ＩＮＦＯＣ
ＯＭ議事録２８７〜２９５ページ）］、ランダム早期廃
棄（Random Early Discard：ＲＥＤ）［Ｓ．フロイド及
びＶ．ジェーコブソン（Jacobson）「Random early det
ection gateways for congestion avoidance」（IEEE/A
CM Trans. Networking、１（４）：３９７〜４１３ペー
ジ、１９９３年８月］、及びフェアＲＥＤ（ＦＲＥＤ）
［Ｄ．リン（Lin）及びＲ．モリス（Morris）「Dynamic
s of random early detection」（SIGCOMM議事録１２７
〜１３７ページ、フランス、ソフィア・アンチポリス、
１９９７年９月］等がある。

【０００８】一方、スケジューリング決定には、フロー
の最後のパケットが送信されたのはいつか、フローのレ
ート保証または遅延保証などのフロー固有の状態情報
と、リンクへのアクセスをめぐって現在競合しているす
べてのフローに関係する操作の両方が必要である。後者
は、一般には送信を待っているパケットの記憶リスト内
の操作の挿入と削除の形で行われる。たとえば、重み付
き公正待ち行列化（Weighted Fair Queuing:ＷＦＱ）
［Ａ．Ｋ．Ｊ．パレク（Parekh）の「A Generalized Pr
ocessor Sharing Approach to Flow Control in Interg
rated Services Networks」（博士論文、Laboratory fo
r Information and Decision Systems, Massachusetts
Institute of Technology、米国０２１３９マサチュー
セッツ州ケンブリッジ、１９９２年２月Ｎｏ．ＬＩＤＳ
−ＴＨ−２０８９）］またはレート制御最早期限優先
（rate controlled Earliest Deadline First：ＥＤ
Ｆ）［Ｌ．ジョージアディス（Georgiadis）、Ｒ．ゲラ
ン、Ｖ．ペリス（Peris)、及びＫ．Ｎ．シバラージャン
（Sivarajan）「Efficient network QoS provisioning
based on per node traffic shaping」IEEE/ACM Trans.
Networking, ４（４）：４８２−５０１、１９９６年
８月）］などのアルゴリズムの場合、この記憶リスト
は、各アクティブ・フローからのパケットの最大発信時
間から成り、フローの最大発信時間はレート保証または
遅延保証あるいはその両方が確実に保証されるように計
算される。

【０００９】図２は、異なるフローが使用することがで
きる資源量を制御するために、典型的なネットワーク・
ノードで従来の技術によって実行されるバッファ管理及
びスケジューリング機構の動作を示す図である。異なる
フローからのパケットが入力リンク３５で着信し、ま
ず、バッファ管理ユニット７０によって処理される。こ
のユニットは、空きバッファ（図中の白い部分）の合計
数と、そのパケットが対応するフローの現行バッファ占
有量とに基づいて、着信パケットを受け入れてバッファ
７２に格納するか否かの決定を行う。具体的には、この
図には、入力リンクでバッファに着信するフローｆ１か
らのパケット５１、５４、及び５６と、フローｆ４から
のパケット５２と、フローｆ３からのパケット５５とが
図示されている。バッファ管理ユニット７０は、フロー
ｆ１からの着信パケット５６を、バッファに受け入れる
べきか否かを決定するために処理しようしている。図２
に示すフローｆ１のバッファの状態により、パケット５
６を加えるとフローｆ１がその割り振りバッファ空間を
超えることになる。その結果、パケット５６はフローｆ
１が他のいずれかのフロー、たとえばフローｆ１０から
空きバッファを「借りる」ことができる場合にのみ、バ
ッファに受け入れられる。各バッファ管理方式は、アク
ティブなフローが他のフローからどの程度積極的に空き
バッファを借りることができるようにするかという程度
が異なり、これは可能な効率とレート保証の保護との異
なる兼ね合いに対応する。

【００１０】バッファから出力リンク３６上への送信
は、スケジューラによって制御される。スケジューラ
は、処理ユニット７１とパケット送信時間７３の記憶リ
ストから成る。処理ユニット７１は、フローｆｉに関連
づけられた待ち行列ごとに、フローｆｉの待ち行列の先
頭のパケットをリンクで送信すべき最終時点を計算す
る。ＷＦＱのようなスケジューラの場合、この時点はフ
ローｆｉからの直前のパケットの送信時点とフローｆｉ
のレート保証とに基づく。たとえば、フローｆｉが時点
ｔでサイズＰｉのパケットを送信したばかりであり、レ
ート保証がＲｉである場合、処理ユニット７１はフロー
ｆｉからのパケットの次の送信時点を、ｔｉ＝ｔ＋Ｐｉ
／Ｒｉとして計算する。次にこの送信時点ｔｉを記憶リ
スト７３の、時点ｔｉとｔｌの間に挿入し、ｔｋ＜ｔｉ
≦ｔｌになるようにする。次に、送信ユニット７４が出
力リンク３６上で送信するために、送信時点が記憶リス
ト７３の先頭にあるフローｆｊから先頭パケットを選択
する。たとえば、この図ではフローｆ７からのパケット
が出力リンク３６で送信されようとしていることと、直
前に送信されたパケットがフローｆ５からのパケット８
１と、フローｆ１からのパケット８２と、フローｆ４か
らのパケット８３と、フローｆ３からのパケット８４
と、再度、フローｆ１からのパケット８５であることが
示されている。

【００１１】図２にはさらに、パケット・スケジューリ
ングの重要なコスト構成要素、すなわち、記憶リスト７
３のサイズが、サービス保証を提供する必要のあるフロ
ーの数と共に増大することが図示されている。これは、
速度が高速化するにつれてスケーラビリティにとって大
きな障害となる可能性がある。その結果、パフォーマン
ス保証の多少の低下または、スケーラビリティの目的に
とってあまり重要でない他のシステム構成要素のコスト
の増大を犠牲にしてもこの問題を解消する手法を考案す
ることが望ましい。

【００１２】可能性のある１つの方向は、記憶する情報
を多少粗くできるようにすることによって、記憶コスト
を低減することである。これは、［Ｓ．スリ（Suri）、
Ｇ．ヴァルギース（Varghese）、Ｇ．チャンドランメノ
ン（Chandranmenon）の「Leap forward virtual clock:
A new fair queuing scheme with guaranteed delayan
d throughput fairness」（ＩＮＦＯＣＯＭ議事録５５
８〜５６６ページ、神戸、１９９７年４月）］の手法で
あり、ｌｏｇＮからｌｏｇＮへの複雑さの減少を達成し
ている（ただしＮは記憶するフローの数である）。これ
によって、フローの数による影響の受けやすさが軽減さ
れるが、この要因に対する依存は残る。この依存を完全
になくす可能な手法は、優先順位交替待ち行列（Rotati
ng Priority Queue (RPQ)の提案［Ｄ．レッジ（Wrege）
及びＪ．リーベヘル（Liebeherr）「A near-optimal pa
cket shceduler for QoS networks」(ＩＮＦＯＣＯＭ議
事録５７７〜５８５ページ、神戸、１９９７年４月）］
の手法である。このＲＰＱ方式では、一定した数の待ち
行列を維持し、各待ち行列の優先順位値をＴ時間単位ご
とに交替させることによって、記憶リストによって得ら
れるパケット送信の順序付けを行う。送信は常に優先順
位の最も高い待ち行列から行われ、着信パケットは現行
優先順位が所望の送信時点に対応する待ち行列に入れら
れる。記憶操作の複雑さは、送信時に１組の待ち行列を
ステップスルーし、着信時にパケットをどの待ち行列に
挿入するかを決定することによって置き換えられる。パ
ケット送信の正確な制御には、比較的多数の待ち行列が
必要になる可能性があり、さらに、ＲＰＱ方式だけでは
フロー間の分離が得られない。すなわち、１つのフロー
からの過剰なトラフィックが別のフローのサービス保証
に影響を及ぼす可能性がある。

【００１３】したがって、記憶操作の必要を完全に回避
し、したがってパケット送信決定におけるフロー数への
依存をなくす、レート保証方法が必要である。この実施
は、全体的な複雑さを最小限にするとともに、より重要
な、他のフローからの過剰なトラフィックがある場合で
も個々のフローに対するレート保証を確保することがで
きるという他の要件も満たさなければならない。たとえ
ばＲＰＱの待ち行列数の増大のように、この方法の複雑
さは、その方法が提供する保証の正確さに著しく依存し
てもならない。

【００１４】

【発明が解決しようとする課題】したがって、本発明の
目的は、新規なバッファ管理方式の使用によって個々の
フロー（またはフローのセット）に対するレート保証を
与える方法を提供することである。

【００１５】本発明の他の目的は、記憶操作の必要をま
ったく回避し、したがって、他のフローからの過剰なト
ラフィックがある場合でも、パケット送信決定における
フロー数への依存をなくすと同時に全体的な複雑さをさ
らに少なくする、個々のフローにレート保証を与える方
法を提供することである。

【００１６】本発明の他の目的は、たとえばＲＰＱの待
ち行列数の増大のように、その方法の複雑さがその方法
によって得られる保証の正確さに著しく依存しない、レ
ート保証を与える方法を提供することである。

【００１７】本発明の他の目的は、公正で効率的でスケ
ーラブルな方式のリンク予約によって、単一のリンクを
複数のストリーム間で共用することができるレート保証
を与える方法を提供することである。

【００１８】本発明の他の目的は、ルータ（スイッチ）
が、通常のパケット転送に加えて、差別化されたサービ
スをサポートできるようにする方法を提供することであ
る。

【００１９】本発明の他の目的は、単一のクラスとして
併合されたストリームの単純なＦＩＦＯスケジューリン
グを可能にする方法を提供することである。

【００２０】本発明の他の目的は、本発明をコンピュー
タ使用可能媒体上に入れられたコンピュータ可読プログ
ラム・コードとして実施することである。

【００２１】

【課題を解決するための手段】したがって、上記の目的
は、送信を待っているパケット間のアービトレーション
を行うことができる高度なスケジューラを必要とせず
に、個々のフロー（またはフローのセット）にレート保
証を与えることができるようにする新規なバッファ管理
方式の使用によって達成される。フローまたはストリー
ムとは、発信元上のアプリケーションから発信され、宛
先上のアプリケーションで終了するパケットのシーケン
スである。各フロー専用のバッファ空間の賢明な割り振
りと分離によって、適切な１フロー当たりのパフォーマ
ンス保証を得ることができる。

【００２２】個々のフローが、ネットワークからの特定
のサービス保証品質を必要とすることがある。個々のフ
ロー（ストリーム）に対してサービス品質を保証するこ
とができる多くの異なる方法があるが、そのほとんどは
複雑なスケジューリング方法を必要とする。これらの方
法は、Ｏ（ｌｏｇＮ）の複雑さを持ち、Ｎはリンクで多
重化されるストリームの数である。本発明の方法はスケ
ジューラの複雑さを単純な先入れ先出し（ＦＩＦＯ）ス
ケジューラに制限する。ＦＩＦＯスケジューラの複雑さ
はＯ（１）であり、したがって、実施がきわめて単純で
ある。この本質的な単純さは、現今のルータにおけるス
ケジューリング方式としての広範囲な使用を促す推進力
になる。その単純さにもかかわらず、ＦＩＦＯスケジュ
ーラの主な欠点の一つは、個々のストリームに対してサ
ービスの差別化を提供することができないことである。
折衝済みのプロファイルを超過するトラフィックを送信
している単一のフローによってバッファがあふれ、基準
に合致したフローが廃棄される可能性がある。本発明人
等は、サービス差別化の負担をスケジューラからバッフ
ァ管理モジュールに移すことによって、この問題を克服
する。このバッファ管理モジュールは、どのパケットを
受け入れて送信のための待ち行列に入れるべきかを賢明
に決定する。この選択的受入れを使用して、異なるスト
リームに必要な帯域幅保証を与えることができるように
保証する。本発明は、主として単一のサービス品質パラ
メータ、すなわちストリームに対するレート保証の提供
を対象とする。言い換えると、本発明の目標は、各スト
リームに記憶バッファの所定の一部を割り振ることによ
って、特定のストリームがルータにおいて特定の最小帯
域幅を受け取ることを確実に保証できるようにすること
である。各フローにとって使用可能なバッファ空間の賢
明な割り振りと分離によって、適切なフロー当たりのパ
フォーマンス保証が得られる。

【００２３】バッファ管理にのみ依存することによって
レート保証を提供することには、多くの利点がある。一
般にバッファ管理操作は、典型的には、一定した１パケ
ット当たりの処理ステップ数を必要とし、その結果、複
雑さが低くなり、スケーラビリティ特性が向上する。さ
らに、別個のスケジューリング機構を使用しても、バッ
ファ管理と、したがってそのコストとを必要とするので
は何の価値もない。これは、スケジューリングは、せい
ぜい、個々のフローに対して十分な送信の機会を保証す
るに過ぎないためである。しかし、別の不正なフローが
バッファ空間全体を占有しているために、フローが待機
パケットを持たない場合、このような保証はあまり利益
がない。したがって、サービス保証を提供する場合はバ
ッファ管理も必要である。

【００２４】

【発明の実施の形態】以下の好ましい実施形態の説明で
は、本明細書の一部を形成し、本発明を実施することが
できる特定の実施形態が例として図示された添付図面を
参照する。本発明の範囲から逸脱することなく、他の実
施形態も使用可能であり、構造上の変更を加えることが
できることを理解されたい。

【００２５】概要 本発明の方法は、どのようなパケット通信ネットワーク
にでも適用可能である。例示のために、最も一般的なパ
ケット交換ネットワーク、すなわちインターネットを考
えてみる。発信元が、データのパケット（データグラム
と呼ぶこともある）を作成し、それをネットワークに送
出する。インターネット・プロトコル（ＩＰ）ネットワ
ークは、パケットをその発信元から最終的な宛先に宛て
て送る役割を果たすルータと呼ばれるパケット転送機構
から成る。ルータは、その対等ルータと制御情報を交換
し、パケットの一貫した転送方法を判断する。

【００２６】ルータで行われる操作は、制御経路とデー
タ経路のいずれで行われるかに基づいて、２つの明確な
カテゴリに分けることができる。制御経路は、ストリー
ムと総称されるフローまたはフローのグループにルータ
が資源を割り振ることができるように、ルータに制御情
報を供給するために使用される。ストリームは、ルータ
で資源が割り振られる基本単位であり、セットアップ段
階で特定され、これを受入れ制御とも呼ぶ。受入れ制御
のプロセスは、ルータによって実行されるセットアップ
手続きの一部として行われ、予約要求が複数のパケット
・ストリームから行われるため、それらの予約要求を解
析するセットアップ・プロトコルを必要とする。受入れ
制御アルゴリズムが、そのストリーム割り振るために使
用可能な十分なバッファ空間があるか否かに基づいて、
ストリームを受け入れるか拒否するかを決定する。この
ストリーム・セットアップは、構成または、資源予約プ
ロトコル（ＲＳＶＰ）［Ｒ．ブレーデン（Braden）等の
「Resource ReSerVation Protocol （ＲＳＶＰ）−バー
ジョン１機能仕様。Request for Comment（提案規格）
ＲＦＣ２２０５、Internet Engineering Task Force、
１９９７年９月］のような何らかの明示的予約プロトコ
ルを介して行うことができ、制御経路の一部である。

【００２７】受入れ制御プロセスの最終結果は、パケッ
ト・ストリームｎが、十分な長さの期間にわたって測定
される、少なくとも以下の帯域幅を受け取るように保証
されることである。

【数２】 この期間は、ＴｏｔａｌＢｕｆ／Ｃ秒によって上限が制
限される。

【００２８】式１の項には以下のものが含まれる。 ＡｌｌｏｃＢｕｆ［ｎ］：ストリームｎに割り振ること
ができるバッファの最大バイト数を示す。このバイト割
り振り数値は、ストリームがセットアップされる時点
（受入れ制御段階）で決定され、ストリームｎに対して
保証する必要のあるバイト数／秒で表されたレートＲの
関数である。 Ｓｐａｒｅｂｕｆ：すべてのストリームに割り振られた
後の最大残りバッファ空間を示す。ただし、

【数３】 である。 ＴｏｔａｌＢｕｆ：出力リンクにおけるバイト数で表さ
れた最大バッファサイズを示す定数である。

【００２９】パケットのサイズは異なることがあり、パ
ケットの伝送時間はパケットのサイズに比例するため、
バッファ空間はバイト数で示されることに留意された
い。

【００３０】式１を使用して、パケット・ストリームが
受け入れられたらそのパケット・ストリームに対してレ
ート保証を提供する受入れ制御方策を考案することがで
きる。すなわち、各パケット・ストリームにとって使用
可能なバッファ空間の賢明な割り振りと分離によって、
各ストリームにパフォーマンス保証を与えることができ
る。

【００３１】図３は、受入れ制御方策を示す最上位水準
図である。この図には、パケット・ストリームｎからの
予約要求を処理する全般的な機構が図示されている。セ
ットアップ・プロトコルは一般に、ルータ１０２への予
約要求１０１の送信を必要とする。次に、ルータ１０２
は、その要求を満たすのに十分なリンク容量とバッファ
空間があるか否かを調べることによって、その要求を受
け入れることができるか否かを判断する。ルータ１０２
の決定論理回路が、パケット１０３を受け入れるか拒否
するかの決定を出力する。出力で使用可能な合計バッフ
ァ空間は固定しており、ＴｏｔａｌＢｕｆによって示さ
れることを想起されたい。したがって、現在割り振ら
れ、出力リンクで多重化されているＮ個の合計ストリー
ムがある場合、Ｔｏｔａｌｂｕｆは以下のように定義さ
れる。

【数４】

【００３２】新しいストリームＮ＋１が予約要求を行っ
た場合、すなわち、Ｒバイト／秒のレートを希望してい
る場合、以下に等しいバイト数のバッファ割り振りが必
要である。

【数５】

【００３３】この新規割り振りを行うのに十分なバッフ
ァ空間がある場合、要求は受け入れられる。ない場合は
拒否される。十分なバッファ空間があるか否かの判断
は、以下の式に従って行われる。 ＡｌｌｏｃＢｕｆ［Ｎ＋１］＜＝Ｓｐａｒｅｂｕｆ

【００３４】新しいストリームからのレート予約は、任
意の時点（たとえば前に受け入れられたストリームから
のパケットの処理中）で行うことができることに留意さ
れたい。新しいストリーム（ストリームＮ＋１）が受け
入れられた後、ＡｌｌｏｃＢｕｆ［Ｎ＋１］の更新に加
えて、ＳｈａｒｅｄＢｕｆ及びＳｐａｒｅｂｕｆを以下
のように更新する必要がある。 Ｓｐａｒｅｂｕｆ＝Ｓｐａｒｅｂｕｆ−ＡｌｌｏｃＢｕ
ｆ［Ｎ＋１］ ＳｈａｒｅｄＢｕｆ＝ＳｈａｒｅｄＢｕｆ−Ａｌｌｏｃ
Ｂｕｆ［Ｎ＋１］ 上式で、 ＳｈａｒｅｄＢｕｆ：現在使用可能な共用バッファ空間
（バイト数）を示す。この変数は、Ｓｐａｒｅｂｕｆに
初期設定される。

【００３５】受入れ制御段階で、各ストリームに、合計
バッファ空間のうち、パケット処理のためにそのストリ
ームにとって使用可能なものとして保証された特定の部
分が割り振られる。任意の時点で、ストリームがその初
期割振りよりも多くのバッファ空間を必要とする場合、
そのストリームは共用バッファ空間からバッファ空間を
獲得することができる。共用バッファ空間の概念は、い
くつかの観点から見ることができ、これには、合計バッ
ファ空間のうち、その初期割り振りを超えるより多くの
バッファ空間を必要とするストリームを満足させるため
の専用の固定部分という表現が含まれるがこれには限定
されない。あるいは、共用バッファ空間は、合計バッフ
ァ空間のうち、まだどの特定のストリームにも割り振ら
れていない部分を構成するものとして見ることもでき
る。共用バッファ空間に適用される定義にかかわらず、
バッファ・メモリの固定した共用部分への分割は、物理
的なものである必要はなく、本明細書に記載の単純なア
カウンティング手続きによって行うことができることに
留意することが重要である。

【００３６】ストリームの現行バッファ使用状況と全体
的なバッファ可用性とに応じて、ストリーム共用バッフ
ァ空間を与えるか否かを決定する際に、特定の方針を適
用することができる。選択される特定の方針は、その特
定の用途と、それに付随するシステムの制約及び目的に
従う必要がある。

【００３７】パケット・ストリーム予約を終了するとき
にはこれらと逆の操作が実行される。一時的バーストを
保持する十分なバッファが確保されるように、いつでも
使用可能なある程度の共用バッファ量があるように保証
することが望ましいと考えられることに留意されたい。

【００３８】受入れ制御段階でルータにおいてパケット
・ストリーム（たとえばレート要求Ｒを認めるなど）が
開始された後に、初期設定されたストリームのパケット
処理が続く。パケット処理には、プロセスを定義するい
くつかのデータ経路操作が含まれる。パケットがルータ
に入力された直後のパケットの処理には、１）分類、
２）検査、３）バッファ管理、及び、４）スケジューリ
ングの４つの主なステップが含まれる。図４及び図５
に、ルータが受け取った各パケットの処理に付随する上
記のステップを示す。

【００３９】図４は、パケット分類１１１、準拠検査１
１２，及びバッファ管理１１３の操作を示すブロック図
である。バッファ管理操作１１３は、本発明の方法の焦
点である。各パケットがルータに受け取られると、その
パケットはそのヘッダで送られたビットのサブセットに
基づいてストリームに属するものとして分類され、この
プロセスをパケット分類１１１と呼ぶ。このプロセス
は、真正なＩＰパケットであることを保証するための特
定の真正検査の実行が含まれる。次に、パケット・ヘッ
ダ内のフィールドに基づいて、複数のストリームのう
ち、ストリームＩＤによって識別された１つのストリー
ムに属するものとして分類される。このストリームＩＤ
は、パケットを転送するための出力インタフェース、次
のホップ・ルータのアドレスなど、当該ストリームに関
係する情報を検索するためのインデックスとして使用す
ることができる。

【００４０】パケット分類１１１の実行に加えて、スト
リームがプロファイルと合致しているか否かを判断する
ために、着信パケットは準拠検査１１２を受ける場合が
ある。このステップを実施した場合、着信パケットには
１ビットを使用して「プロファイル外れ」であるか否か
がマークされる。パケットがプロファイルと合致するか
否かに関する判断は、パケットをリーキー・バケット
（Leaky-Bucket）［Ｊ．ターナー（Turner)「New direc
tions in communications (or which way to theinform
ation age?）」IEEE Communications Magazine、２４
（１０）：８〜１５ページ、１９８６年１０月］タイプ
のカウンタと照合して、送信元が、ストリームがセット
アップされた時点に折衝したよりも多くのパケットをネ
ットワークに送信したか否かを識別する操作が伴う。プ
ロファイル外れとしてマークされたパケットは、輻輳期
間中に、マークされていないパケットよりも選択的に廃
棄することができる。

【００４１】パケット分類１１１と準拠検査１１２の後
に、バッファ管理のステップが行われる。このステップ
では、パケットをリンク上に送出するまでに格納するの
に十分なバッファ空間があるか否かに関する決定を行
う。パケットを受け入れるか拒否するかの決定を行うの
はこのステップ中である。この決定プロセスへの入力値
は、（１）ストリーム識別子（ｓｔｒｅａｍｉｄ）と、
（２）合計空きバッファ空間量と、（３）現在すべての
ストリームによって占有されているバッファ空間とであ
る。本方法は、いくつかの異なる状態変数に基づいてス
トリームにレート保証を与えることができるという前提
に基づいて、各パケットを受け入れるか拒否するかを決
定する。

【００４２】図５で、バッファ管理１１３の後で行わ
れ、スケジューリング１１５と、送信１１６と、バッフ
ァの更新１１７とを含むパケット処理操作を説明する。
ＦＩＦＯリンク・スケジューラ１１５は、バッファ管理
１１３によって受け入れられたパケットの待ち行列から
リンクでの送信１１６を待っているパケット１１９の１
つを絶えず取り出す。

【００４３】本発明の方法は、バッファ管理プロセス１
１３に組み込まれ、どのパケットを受け入れ、どのパケ
ットを拒否するかを決定する比較的単純なアカウンティ
ング機構を使用して、単純なＦＩＦＯスケジューラの欠
点を解消する。このアカウンティング機構は、パケット
を受け取った時点と、パケットがリンク上での送信を完
了する時点に、２、３の単純な操作を行う。アカウンテ
ィング機構の詳細について、図６、図７、図８、図９、
及び図１０で説明する。

【００４４】パケット送信１１６のプロセス・ステップ
は、ルータ内のパケットの移動において最後の段階であ
る。この段階で、パケットはリンク１１６上に送出され
る。パケット送信が完了すると、スケジューラに「リン
ク解放」事象１１８が通知され、それによってスケジュ
ーラは送信のために次のパケットを取り出すことがで
き、このサイクルが続けられる。

【００４５】バッファ占有量に変化があるたびに、バッ
ファ管理モジュール１１７を更新しなければならない。
リンク上にパケットが送出された場合、送信されたパケ
ットが貴重なバッファ資源をもはや占有していないこと
を示すようにバッファ・カウントをそれに応じて更新１
１７する必要がある。

【００４６】実施形態例 図４に示すバッファ管理１１３の処理段階は、バッファ
の可用性と占有率に関係する。この段階で言及するバッ
ファは、スイッチまたはルータ全体にいくつかの異なる
方法で物理的に分散させることができる。たとえば、ス
イッチは、入力または出力あるいはその両方にバッファ
を備えることができる。理想的には、スイッチは入力リ
ンクの数倍の速度で動作すべきであり、そのバッファの
すべてを各出力に備えることが理想的である。出力リン
クは競合点となる可能性が高い。本明細書では、この例
示の実施形態について、出力に待ち行列を備えるバッフ
ァ管理として説明する。この実施形態では、着信パケッ
トが入れられるバッファはすべて、特定のルータまたは
スイッチの出力リンク上に配置される。各出力での待ち
行列は切り離されているため、例示のために分離された
単一の出力リンクを考えることができる。各出力リンク
ごとに、すべての着信パケットがそれをめぐって競合す
る単一のバッファ・メモリがあるものとする。このメモ
リは、物理的に出力リンク・アダプタ上に配置するか、
またはルータ全体に分散させることができる。容量Ｃバ
イト／秒の単一の出力リンクを考え、Ｎがこのリンクで
多重化されるストリーム数を示すものとする。

【００４７】図６、図７、及び図８に、パケットの受信
及び着信の時点で行われる処理を示す。図８及び図９
で、このプロセスをそれぞれフローチャートとプログラ
ム・ステートメントの形で示す。

【００４８】図６及び図７は、パケットを受け取るたび
に行われる処理を説明するフローチャートである。ステ
ップ４０は、現在の受信パケットを受け入れるか拒否す
るかを決定するパケット評価ルーチンへの入口点を表
す。最初の操作ステップ４２は、受け取ったパケットを
複数の前に受け入れた（たとえば認められたレート要
求）パケット・ストリームｎのうちの１つに分類する。
ただし、ｎは１からＮまでの範囲の整数である。ステッ
プ４４は、現在の受信パケットをバッファに加えること
によって、バイト数で表された第１のしきい値、この例
示の実施形態では最大バッファ・サイズを超えないかど
うかを判断する決定ステップである。超えない場合、プ
ロセスはステップ４６に進み、超える場合はパケットは
ステップ５６で廃棄され、プロセスはステップ５８で終
了する。ステップ４６は、バッファのうちのそのパケッ
トに関連づけられたストリームｎ専用の所定部分にパケ
ットを加えた値が第２のしきい値以下であるか否かにつ
いて決定を行う第２の決定ステップを表す。例示の実施
形態では、第２のしきい値はバッファ内のストリームｎ
に割り振られた最大バイト数である。ステップ４６でパ
ケットを加えた値が第２のしきい値を超える場合、プロ
セスはステップ４８に進む。ステップ４８は、現在の受
信パケットを共用バッファ領域に格納することができる
か否かを判断する第３の決定ステップを表す。現在使用
可能な共用バッファ空間から現在の受信パケットの長さ
（バイト数）を引いた値がゼロより大きい場合、この実
施形態では、パケットは共用バッファ領域に格納され
る。ステップ５０で、パケットは、汎用バッファ領域で
はなく共用バッファ領域に属するものとしてしかるべく
マークされる。プロセスは次にステップ５２に進み、現
在の受信パケットの記憶量を含めるように共用バッファ
空間量が更新される。

【００４９】ステップ４６で、現在の受信パケットを、
ストリームｎに割り振られた使用可能バッファ空間に入
れることができると判断された場合、プロセスはステッ
プ５４に進み、パケットは共用バッファ空間に属さない
ものとしてマークされる。この時点で、ステップ５２と
ステップ５４とが合流し、合計割り振りバッファ空間が
この最近に受け取ったパケットを加えた値を反映するよ
うに更新される。ステップ５９で、ストリームｎに割り
振られた所定のバッファ空間が、このパケットを加えた
値を反映するようにそれに応じて更新される。ステップ
６０で、パケットは後で送信するために出力リンク上に
待ち行列化される。このプロセスはステップ６１で終了
する。

【００５０】図９は、本発明の方法により、送信のため
にパケットが待ち行列から出されるたびに行わなければ
ならないアカウンティングを示すフローチャートであ
る。単純なＦＩＦＯスケジューラがリンクでの送信のた
めにこの待ち行列からパケットを取り出す。ステップ６
２は、パケット送信ルーチンに入る入口点を表す。ステ
ップ６４で、使用可能な合計バッファ空間量が、送信さ
れるパケット長だけバイト数単位で減分される。ステッ
プ６６で、ストリームｎに割り振られた所定のバッファ
空間がバイト数で表された送信パケット長だけ減分され
る。ステップ６８は、送信するパケットが共用バッファ
空間に属するか否かを判断する決定ステップを表す。共
用バッファ空間に属さない場合、パケットはステップ７
２でリンク上に送出される。共用バッファ空間に属する
場合、現在使用可能な共用バッファの量がバイト数で表
されたパケット長だけ増分される。プロセスはステップ
７３で終了する。

【００５１】図１０に、図９のフローチャートで定義さ
れたプロセスを示すプログラム・コードを示す。

【００５２】図８及び図１０に示されているプログラム
・コードを含む本明細書に記載の汎用アルゴリズムは、
プログラム記憶装置に記憶され、機械（たとえばプロセ
ッサ）によって読み取ることができるプログラム可読プ
ログラム・コードとして実施することができる。

【００５３】複数出力待ち行列 以上では、リンク上での送信を待っているすべてのパケ
ットを保持する単一のＦＩＦＯ待ち行列があることを前
提としていた。これは最も単純なスケジューリング形態
であるが、［Ｈ．ジャン（Zhang）「Service disciplin
es for guaranteed performance service in packet-sw
itching networks」（ＩＥＥＥ議事録、８３（１０）１
３７４〜１３９６ページ、１９９５年１０月）］という
文献で詳細に考察されている他のいくつかのタイプのス
ケジューラがある。本明細書に記載の機構はＦＩＦＯ以
外のスケジューリング機構にも適用可能である。

【００５４】図１１に、異なる待ち行列間のアービトレ
ーションを行う重み付き公正待ち行列スケジューラ（We
ighted Fair Queuing scheduler）１５３を備えた、出
力リンクにある複数の待ち行列を含む実施形態を示す。
重み付き公正待ち行列化（Weighted Fair Queuing）手
法は、［Ａ．デマーズ（Demers）、Ｓ．ケシャブ（Kesh
av）、及びＳ．シェンカー（Shenker）「Analysis and
simulation of a fairqueing algorithm」（Journal of
internetworking: Research and Experience、１：３
〜２６ページ、１９９０年１月）］等に記載されてい
る。重み付き公正待ち行列化（Weighted Fair Queuin
g）では、各ストリームが、何らかの所定の方針に基づ
いて待ち行列１５１のいずれか１つの待ち行列に入れら
れる。待ち行列に送信の機会が与えられると、待ち行列
の先頭にあるパケット１５２が送信される。バッファが
異なる待ち行列間で静的に区分化されている場合、本実
施形態で説明する機構を直接適用して各待ち行列のバッ
ファ管理を行うことができる。

【００５５】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００５６】（１）各ストリームｎが１からＮまでの範
囲のインデックスを付けられ、パケット交換ネットワー
ク内の共通の出力リンクｊで送信するために多重化さ
れ、前記リンクがパケットを格納するバイト数で表され
た合計バッファ空間を有するバッファから成る、複数の
パケット・ストリームｎの各パケット・ストリームにつ
いて明示的なレート保証Ｒ_nを提供する方法であって、 ａ）各現在の受信パケットについて、前記現在の受信パ
ケットに関連づけられたパケット・ストリームｎを識別
するステップと、 ｂ）前記現在の受信パケットを前記合計バッファ空間の
専有部分に加えて第１の和を求めるステップと、 ｃ）前記第１の和が第１のしきい値を超えるか否かを判
断し、それに応答して第１の変数を設定するステップ
と、 ｄ）前記現在の受信パケットを前記ストリームｎに割り
振られた前記バッファ空間に加えて第２の和を求めるス
テップと、 ｅ）前記第２の和が第２のしきい値を超えるか否かを判
断し、それに応答して第２の変数を設定するステップ
と、 ｆ）前記第１及び第２の変数に基づいて前記パケットを
受け入れるかまたは拒否し、それによって前記ストリー
ムの前記レート保証Ｒ_nを保証するステップとを含む方
法。 （２）前記第１のしきい値が合計バッファ空間である、
上記（１）に記載の方法。 （３）前記第２のしきい値が合計バッファ空間のうちの
パケット・ストリームｎに割り振られた部分である、上
記（１）に記載の方法。 （４）前記合計バッファ空間が割り振られたバッファ空
間と共用バッファ空間とを含む、上記（１）に記載の方
法。 （５）前記合計バッファ空間が、バイト数で表された前
記合計バッファ空間の前記占有部分を追跡する関連づけ
られた合計バッファ・カウンタを有する、上記（４）に
記載の方法。 （６）前記共用バッファ空間が、バイト数で表された前
記共用バッファ空間の未占有部分を追跡する関連づけら
れた共用バッファ・カウンタＳｈａｒｅｄＢｕｆを有す
る、上記（４）に記載の方法。 （７）前記割り振られたバッファ空間が合計バッファ空
間のうちのレート保証Ｒ _nが保証されているストリーム
ｎに割り振られた部分を表し、ｎ＝１．．．Ｎである、
上記（４）に記載の方法。 （８）前記共用バッファ空間の現在未占有の部分から前
記現在の受信パケットのバイト数で表された長さを引い
た値が第３のしきい値以上であるか否かを判断し、それ
に応答して第３の変数を設定するステップをさらに含
む、上記（４）に記載の方法。 （９）ステップ（ｆ）が前記第３の変数に基づいて前記
パケットを受け入れるかまたは拒否するステップをさら
に含む、上記（８）に記載の方法。 （１０）前記第３のしきい値がゼロである、上記（８）
に記載の方法。 （１１）前記第１のしきい値を超えず、前記第２のしき
い値を超えない場合、前記現在の受信パケットを前記合
計バッファ空間のうちのストリームｎに割り振られた前
記部分に加えるステップをさらに含む、上記（５）に記
載の方法。 （１２）前記現在の受信パケットを受け入れる場合、前
記合計バッファ・カウンタを、バイト数で表された前記
現在の受信パケットの長さだけ増分するステップをさら
に含む、上記（１１）に記載の方法。 （１３）前記パケットを受け入れる場合、前記現在の受
信パケットが属するストリームに関連づけられたストリ
ーム・バッファ・カウンタを、バイト数で表された前記
現在の受信パケットの長さだけ増分するステップをさら
に含む、上記（１１）に記載の方法。 （１４）前記第１のしきい値を超えず、前記第２のしき
い値を超え、前記第３のしきい値を超える場合、前記現
在の受信パケットを前記共用バッファ空間に加えるステ
ップをさらに含む、上記（８）に記載の方法。 （１５）前記現在の受信パケットを前記共用バッファ空
間に受け入れる場合、共用バッファ・カウンタをバイト
数で表された前記現在の受信パケットの長さだけ減分す
るステップをさらに含む、上記（６）に記載の方法。 （１６）前記パケットが送信の前に待ち行列化され、前
記合計バッファ空間に格納される、上記（４）に記載の
方法。 （１７）ストリームｍに関連づけられたパケットを送信
する場合、前記合計バッファ空間のうちのストリームｍ
に割り振られた前記部分から前記現在の受信パケットを
削除するステップをさらに含む、上記（５）に記載の方
法。 （１８）前記合計バッファ・カウンタをバイト数で表さ
れた前記現在の送信パケットの長さだけ減分するステッ
プをさらに含む、上記（１７）に記載の方法。 （１９）前記現在の送信パケットのストリームに関連づ
けられたストリーム・バッファ・カウンタを、バイト数
で表された前記現在の送信パケットの長さだけ減分する
ステップをさらに含む、上記（１７）に記載の方法。 （２０）前記共用バッファ空間からパケットを送信する
場合、前記共用バッファ・カウンタＳｈａｒｅｄＢｕｆ
を、バイト数で表された前記現在の送信パケットの長さ
だけ増分するステップをさらに含む、上記（６）に記載
の方法。 （２１）前記バッファが前記出力リンクに接続されたイ
ンタフェース上に配置された、上記（１）に記載の方
法。 （２２）前記共通出力リンク上での前記パケットの送信
の順序が先入れ先出し（ＦＩＦＯ）方針に基づく、上記
（１６）に記載の方法。 （２３）パケット・ストリームがパケット交換ネットワ
ークを介した出力リンク上での送信のために多重化さ
れ、前記リンクがパケットを一時的に格納するバッファ
を有し、前記バッファが割り振りバッファ空間と共用バ
ッファ空間とから成る合計バッファ空間Ｔｏｔａｌｂｕ
ｆを有する、Ｎ個の事前割り振りパケット・ストリーム
を含むパケット交換ネットワークにおいて、パケット・
ストリームＮ＋１のためのレート保証Ｒ_N+1を求める要
求を処理する方法であって、 ａ）前記パケット・ストリームＮ＋１から前記レート保
証Ｒ_N+1を求める要求を受け取るステップと、 ｂ）前記レート保証に前記出力リンク上で前記パケット
交換ネットワークによって対応することができるか否か
を判断するステップとを含み、前記判断ステップが、 ｉ）汎用バッファ空間のうち、前記レート保証Ｒ_N+1に
従って前記パケット・ストリームＮ＋１に割り振られる
部分Ａｌｌｏｃｂｕｆ［Ｎ＋１］を計算するステップ
と、 ii)Ａｌｌｏｃｂｕｆ［Ｎ＋１］を現在割り振られてい
ない合計バッファ空間量Ｓｐａｒｅｂｕｆと比較し、Ａ
ｌｌｏｃｂｕｆ［Ｎ＋１］がＳｐａｒｅｂｕｆより小さ
い場合、前記ストリームＮ＋１にＡｌｌｏｃｂｕｆ［Ｎ
＋１］に等しい前記合計バッファ空間量を割り振り、そ
れ以外の場合は、レート保証Ｒ_N+1を求める前記レート
要求を拒否するステップとを含む方法。 （２４）前記合計バッファ空間量を前記ストリームＮ＋
１に割り振る前記ステップが、以下の式

【数６】 に従って行われ、Ｃが前記ストリームＮ＋１の前記パケ
ットが送信される前記出力リンクのバイト／秒で表され
た速度である、上記（２３）に記載の方法。 （２５）前記未割り振り合計バッファ空間量Ｓｐａｒｅ
ｂｕｆを計算する前記ステップが、以下の式 Ｓｐａｒｅｂｕｆ＝Ｔｏｔａｌｂｕｆ−ΣＡｌｌｏｃＢ
ｕｆ［ｎ］ に従って行われる、上記（２３）に記載の方法。 （２６）前記ストリームＮ＋１のためのレート保証を求
める前記要求を受け入れた後で、前記共用バッファ空間
Ｓｐａｒｅｂｕｆが以下の式 Ｓｐａｒｅｂｕｆ＝Ｓｐａｒｅｂｕｆ−ＡｌｌｏｃＢｕ
ｆ［Ｎ＋１］ に従って更新される、上記（３８）に記載の方法。 （２７）前記ストリームＮ＋１のためのレート保証を求
める前記要求を受け入れた後で、前記未割り振りバッフ
ァ空間ＳｈａｒｅｄＢｕｆが以下の式 ＳｈａｒｅｄＢｕｆ＝ＳｈａｒｅｄＢｕｆ−Ａｌｌｏｃ
Ｂｕｆ［Ｎ＋１］に従って更新される、上記（２３）に
記載の方法。 （２８）前記ストリームｐのためのレート保証Ｒ_pを求
める前記要求の終了後に、Ｓｐａｒｅｂｕｆが Ｓｐａｒｅｂｕｆ＝Ｓｐａｒｅｂｕｆ＋ＡｌｌｏｃＢｕ
ｆ［ｐ］ のように更新され、ｐは終了した前記ストリームを表す
１からＮ＋１までの範囲の整数である上記（２３）に記
載の方法。 （２９）前記ストリームｐのためのレート保証Ｒ_pを求
める前記要求の終了後に、前記共用バッファ空間Ｓｈａ
ｒｅｄＢｕｆが以下の式 ＳｈａｒｅｄＢｕｆ＝ＳｈｒｅｄＢｕｆ＋ＡｌｌｏｃＢ
ｕｆ［ｐ］ に従って更新される、上記（２３）に記載の方法。 （３０）前記出力リンクに複数のバッファが関連づけら
れ、前記パケット交換ネットワークが前記複数のバッフ
ァからの送信を待つパケット間のアービトレーションを
行うスケジューラをさらに含む、上記（１）に記載の方
法。 （３１）各パケット・ストリームｎが１からＮまでの範
囲のインデックスが付けられ、パケット交換ネットワー
クにおける共通出力リンクｊ上での転送のために多重化
され、前記リンクが前記パケットを格納するためのバイ
ト数で表された合計バッファ空間を有するバッファから
成る、複数のパケット・ストリームｎの各パケット・ス
トリームに明示的なレート保証Ｒを提供する方法のステ
ップを実行するように機械によって実行可能な命令から
成るプログラムを有形に実施する機械可読コンピュータ
・プログラム装置であって、前記方法が、 ａ）各現在の受信パケットについて、前記現在の受信パ
ケットに関連づけられたパケット・ストリームｎを識別
するステップと、 ｂ）前記現在の受信パケットを前記合計バッファ空間の
専有部分に加えて第１の和を求めるステップと、 ｃ）前記第１の和が第１のしきい値を超えるか否かを判
断し、それに応答して第１の変数を設定するステップ
と、 ｄ）前記現在の受信パケットを前記ストリームｎに割り
振られた前記バッファ空間の占有部分に加えて第２の和
を求めるステップと、 ｅ）前記第２の和が第２のしきい値を超えるか否かを判
断し、それに応答して第２の変数を設定するステップ
と、 ｆ）前記第１及び第２の変数に基づいて前記パケットを
受け入れるかまたは拒否し、それによって前記レート保
証Ｒを保証するステップとを含むコンピュータ・プログ
ラム装置。 （３２）前記第１のしきい値が前記合計バッファ空間で
ある、上記（３１）に記載のコンピュータ・プログラム
装置。 （３３）前記第２のしきい値が、前記合計バッファ空間
のうちのパケット・ストリームｎに割り振られた部分で
ある、上記（３１）に記載のコンピュータ・プログラム
装置。 （３４）前記合計バッファ空間が割り振りバッファ空間
と共用バッファ空間とを含む、上記（３１）に記載のコ
ンピュータ・プログラム装置。 （３５）前記合計バッファ空間が、バイト数で表された
前記合計バッファ空間の前記占有部分を追跡する関連づ
けられた合計バッファ・カウンタを有する、上記 （３４）に記載のコンピュータ・プログラム装置。 （３６）前記共用バッファ空間が、バイト数で表された
前記共用バッファ空間の未占有部分を追跡する関連づけ
られた共有バッファ・カウンタＳｈａｒｅｄＢｕｆを有
する、上記（３４）に記載のコンピュータ・プログラム
装置。 （３７）前記割り振りバッファ空間が前記合計バッファ
空間のうち、レート保証Ｒ_nを保証するストリームｎに
割り振られた部分を表し、ｎ＝１．．．Ｎである、上記
（３４）に記載のコンピュータ・プログラム装置。 （３８）前記共用バッファ空間のうちの現在未占有の部
分からバイト数で表された前記現在の受信パケットの長
さを引いた値が第３のしきい値以上であるか否かを判断
し、それに応答して第３の変数を設定するステップをさ
らに含む、上記（３４）に記載のコンピュータ・プログ
ラム装置。 （３９）ステップ（ｆ）が前記第３の変数に基づいて前
記パケットを受け入れるかまたは拒否するステップをさ
らに含む、上記（３８）に記載のコンピュータ・プログ
ラム装置。 （４０）前記第３のしきい値がゼロである、上記（３
８）に記載のコンピュータ・プログラム装置。 （４１）前記第１のしきい値を超えず、前記第２のしき
い値を超えない場合、前記合計バッファ空間のうちのス
トリームｎに割り振られた前記部分に現在の受信パケッ
トを加えるステップをさらに含む、上記（３５）に記載
のコンピュータ・プログラム装置。 （４２）前記現在の受信パケットを受け入れる場合、前
記合計バッファ・カウンタをバイト数で表された現在の
受信パケットの長さだけ増分するステップをさらに含
む、上記（４１）に記載のコンピュータ・プログラム装
置。 （４３）前記パケットを受け入れる場合、前記現在の受
信パケットが属する前記ストリームに関連づけられたス
トリーム・バッファ・カウンタを、バイト数で表された
前記現在の受信パケットの長さだけ増分するステップを
さらに含む、上記（４１）に記載のコンピュータ・プロ
グラム装置。 （４４）第１のしきい値を超えず、第２のしきい値を超
え、第３のしきい値を超える場合、前記現在の受信パケ
ットを前記共用バッファ空間に加えるステップをさらに
含む、上記（３８）に記載のコンピュータ・プログラム
装置。 （４５）前記現在の受信パケットを前記共用バッファ空
間に受け入れる場合、共用バッファ・カウンタをバイト
数で表された前記現在の受信パケットの長さだけ減分す
るステップをさらに含む、上記（３６）に記載のコンピ
ュータ・プログラム装置。 （４６）前記パケットが送信の前に待ち行列化され、前
記合計バッファ空間に格納される、上記（３４）に記載
のコンピュータ・プログラム装置。 （４７）ストリームｍに関連づけられたパケットを送信
する場合、前記合計バッファ空間のうちのストリームｍ
に割り振られた前記部分から前記現在の受信パケットを
削除するステップをさらに含む、上記（３５）に記載の
コンピュータ・プログラム装置。 （４８）前記合計バッファ・カウンタをバイト数で表さ
れた前記現在の送信パケットの長さだけ減分するステッ
プをさらに含む、上記（４７）に記載のコンピュータ・
プログラム装置。 （４９）前記現在の送信パケットのストリームに関連づ
けられたストリーム・バッファ・カウンタを、バイト数
で表された前記現在の送信パケットの長さだけ減分する
ステップをさらに含む、上記（４７）に記載のコンピュ
ータ・プログラム装置。 （５０）前記共用バッファ空間からパケットを送信する
場合、前記共用バッファ・カウンタＳｈａｒｅｄＢｕｆ
を、バイト数で表された前記現在の送信パケットの長さ
だけ増分するステップをさらに含む、上記（３６）に記
載のコンピュータ・プログラム装置。 （５１）前記バッファが前記出力リンクに接続されたイ
ンタフェース上に配置された、上記（３１）に記載のコ
ンピュータ・プログラム装置。 （５２）前記共通出力リンク上での前記パケットの送信
の順序が先入れ先出し（ＦＩＦＯ）方針に基づく、上記
（４６）に記載のコンピュータ・プログラム装置。

【図面の簡単な説明】

【図１】ネットワークを介したフローの経路を図示し、
フローにサービス保証を与えるために、制御する必要が
ある場合及び資源を示す図である。

【図２】異なるフローが使用することができる資源の量
を制御する、ネットワーク・ノードにおける一般的なバ
ッファ管理機構及びスケジューリング機構の動作を示す
図である。

【図３】予約要求を受け入れるか拒否するかを決定する
際に必要な制御段階で行われる様々なステップを示す図
である。

【図４】データ経路で行われ、受け取ったすべてのパケ
ットについて実行される、ルータにおけるバッファ管理
に関係する様々なモジュールを示す図である。

【図５】データ経路で行われ、受け取ったすべてのパケ
ットについて実行される、ルータにおけるバッファ管理
に関係する様々なモジュールを示す図である。

【図６】受け取ったパケットを受け入れるか拒否するか
を決定する処理ステップを示すフローチャートである。

【図７】受け取ったパケットを受け入れるか拒否するか
を決定する処理ステップを示すフローチャートである。

【図８】受け取ったパケットを受け入れるか拒否するか
を決定する処理ステップを示すソフトウェアの図であ
る。

【図９】パケットが出力リンク上に送出されるときの処
理ステップを示すフローチャートである。

【図１０】パケットが出力リンク上に送出されるときの
処理ステップを示すソフトウェアの図である。

【図１１】出力リンクにおいて、重み付き公正待ち行列
化（Weighted Fair Queuing: ＷＦＱ）スケジューラに
よってアービトレーションされる複数の待ち行列がある
システムを示す図である。

【符号の説明】

１０１ 予約要求 １０２ ルータ １０３ パケット １５１ 待ち行列 １５２ パケット

フロントページの続き (72)発明者 ローク・アンドレ・ゲリン アメリカ合衆国10598 ニューヨーク州ヨ ークタウン・ハイツ アンダーヒル・アベ ニュー810 (72)発明者 サンジャイ・ダモダール・カマート アメリカ合衆国10562 ニューヨーク州オ シニング サウス・ハイランド・アベニュ ー151 アパートメント４エフ (72)発明者 ピン・ピー・パン アメリカ合衆国10598 ニューヨーク州ヨ ークタウン・ハイツ デボンシア・ドライ ブ20 (72)発明者 ビノード・ジェラード・ジョン・ペリス アメリカ合衆国10514 ニューヨーク州 チャパカ ハードスクラブル・ロード1243 (72)発明者 ラジェンドラン・ラジャン アメリカ合衆国10463 ニューヨーク州 ブロンクス ウェスト・トゥーハンドレッ ドトェンティセブンス・ストリート126 ナンバー１ Ｆターム(参考） 5K030 GA11 HB19 HD03 JA01 KA03 KX11 KX18 LC02 LE06 MA13 MB11 MB15 9A001 BB04 CC07 DD10 GG01

Claims (52)

【特許請求の範囲】
1. 【請求項１】各ストリームｎが１からＮまでの範囲のイ
   ンデックスを付けられ、パケット交換ネットワーク内の
   共通の出力リンクｊで送信するために多重化され、前記
   リンクがパケットを格納するバイト数で表された合計バ
   ッファ空間を有するバッファから成る、複数のパケット
   ・ストリームｎの各パケット・ストリームについて明示
   的なレート保証Ｒ_nを提供する方法であって、 ａ）各現在の受信パケットについて、前記現在の受信パ
   ケットに関連づけられたパケット・ストリームｎを識別
   するステップと、 ｂ）前記現在の受信パケットを前記合計バッファ空間の
   専有部分に加えて第１の和を求めるステップと、 ｃ）前記第１の和が第１のしきい値を超えるか否かを判
   断し、それに応答して第１の変数を設定するステップ
   と、 ｄ）前記現在の受信パケットを前記ストリームｎに割り
   振られた前記バッファ空間に加えて第２の和を求めるス
   テップと、 ｅ）前記第２の和が第２のしきい値を超えるか否かを判
   断し、それに応答して第２の変数を設定するステップ
   と、 ｆ）前記第１及び第２の変数に基づいて前記パケットを
   受け入れるかまたは拒否し、それによって前記ストリー
   ムの前記レート保証Ｒ_nを保証するステップとを含む方
   法。
2. 【請求項２】前記第１のしきい値が合計バッファ空間で
   ある、請求項１に記載の方法。
3. 【請求項３】前記第２のしきい値が合計バッファ空間の
   うちのパケット・ストリームｎに割り振られた部分であ
   る、請求項１に記載の方法。
4. 【請求項４】前記合計バッファ空間が割り振られたバッ
   ファ空間と共用バッファ空間とを含む、請求項１に記載
   の方法。
5. 【請求項５】前記合計バッファ空間が、バイト数で表さ
   れた前記合計バッファ空間の前記占有部分を追跡する関
   連づけられた合計バッファ・カウンタを有する、請求項
   ４に記載の方法。
6. 【請求項６】前記共用バッファ空間が、バイト数で表さ
   れた前記共用バッファ空間の未占有部分を追跡する関連
   づけられた共用バッファ・カウンタＳｈａｒｅｄＢｕｆ
   を有する、請求項４に記載の方法。
7. 【請求項７】前記割り振られたバッファ空間が合計バッ
   ファ空間のうちのレート保証Ｒ_nが保証されているスト
   リームｎに割り振られた部分を表し、ｎ＝１．．．Ｎで
   ある、請求項４に記載の方法。
8. 【請求項８】前記共用バッファ空間の現在未占有の部分
   から前記現在の受信パケットのバイト数で表された長さ
   を引いた値が第３のしきい値以上であるか否かを判断
   し、それに応答して第３の変数を設定するステップをさ
   らに含む、請求項４に記載の方法。
9. 【請求項９】ステップ（ｆ）が前記第３の変数に基づい
   て前記パケットを受け入れるかまたは拒否するステップ
   をさらに含む、請求項８に記載の方法。
10. 【請求項１０】前記第３のしきい値がゼロである、請求
    項８に記載の方法。
11. 【請求項１１】前記第１のしきい値を超えず、前記第２
    のしきい値を超えない場合、前記現在の受信パケットを
    前記合計バッファ空間のうちのストリームｎに割り振ら
    れた前記部分に加えるステップをさらに含む、請求項５
    に記載の方法。
12. 【請求項１２】前記現在の受信パケットを受け入れる場
    合、前記合計バッファ・カウンタを、バイト数で表され
    た前記現在の受信パケットの長さだけ増分するステップ
    をさらに含む、請求項１１に記載の方法。
13. 【請求項１３】前記パケットを受け入れる場合、前記現
    在の受信パケットが属するストリームに関連づけられた
    ストリーム・バッファ・カウンタを、バイト数で表され
    た前記現在の受信パケットの長さだけ増分するステップ
    をさらに含む、請求項１１に記載の方法。
14. 【請求項１４】前記第１のしきい値を超えず、前記第２
    のしきい値を超え、前記第３のしきい値を超える場合、
    前記現在の受信パケットを前記共用バッファ空間に加え
    るステップをさらに含む、請求項８に記載の方法。
15. 【請求項１５】前記現在の受信パケットを前記共用バッ
    ファ空間に受け入れる場合、共用バッファ・カウンタを
    バイト数で表された前記現在の受信パケットの長さだけ
    減分するステップをさらに含む、請求項６に記載の方
    法。
16. 【請求項１６】前記パケットが送信の前に待ち行列化さ
    れ、前記合計バッファ空間に格納される、請求項４に記
    載の方法。
17. 【請求項１７】ストリームｍに関連づけられたパケット
    を送信する場合、前記合計バッファ空間のうちのストリ
    ームｍに割り振られた前記部分から前記現在の受信パケ
    ットを削除するステップをさらに含む、請求項５に記載
    の方法。
18. 【請求項１８】前記合計バッファ・カウンタをバイト数
    で表された前記現在の送信パケットの長さだけ減分する
    ステップをさらに含む、請求項１７に記載の方法。
19. 【請求項１９】前記現在の送信パケットのストリームに
    関連づけられたストリーム・バッファ・カウンタを、バ
    イト数で表された前記現在の送信パケットの長さだけ減
    分するステップをさらに含む、請求項１７に記載の方
    法。
20. 【請求項２０】前記共用バッファ空間からパケットを送
    信する場合、前記共用バッファ・カウンタＳｈａｒｅｄ
    Ｂｕｆを、バイト数で表された前記現在の送信パケット
    の長さだけ増分するステップをさらに含む、請求項６に
    記載の方法。
21. 【請求項２１】前記バッファが前記出力リンクに接続さ
    れたインタフェース上に配置された、請求項１に記載の
    方法。
22. 【請求項２２】前記共通出力リンク上での前記パケット
    の送信の順序が先入れ先出し（ＦＩＦＯ）方針に基づ
    く、請求項１６に記載の方法。
23. 【請求項２３】パケット・ストリームがパケット交換ネ
    ットワークを介した出力リンク上での送信のために多重
    化され、前記リンクがパケットを一時的に格納するバッ
    ファを有し、前記バッファが割り振りバッファ空間と共
    用バッファ空間とから成る合計バッファ空間Ｔｏｔａｌ
    ｂｕｆを有する、Ｎ個の事前割り振りパケット・ストリ
    ームを含むパケット交換ネットワークにおいて、パケッ
    ト・ストリームＮ＋１のためのレート保証Ｒ_N+1を求め
    る要求を処理する方法であって、 ａ）前記パケット・ストリームＮ＋１から前記レート保
    証Ｒ_N+1を求める要求を受け取るステップと、 ｂ）前記レート保証に前記出力リンク上で前記パケット
    交換ネットワークによって対応することができるか否か
    を判断するステップとを含み、前記判断ステップが、 ｉ）汎用バッファ空間のうち、前記レート保証Ｒ_N+1に
    従って前記パケット・ストリームＮ＋１に割り振られる
    部分Ａｌｌｏｃｂｕｆ［Ｎ＋１］を計算するステップ
    と、 ii)Ａｌｌｏｃｂｕｆ［Ｎ＋１］を現在割り振られてい
    ない合計バッファ空間量Ｓｐａｒｅｂｕｆと比較し、Ａ
    ｌｌｏｃｂｕｆ［Ｎ＋１］がＳｐａｒｅｂｕｆより小さ
    い場合、前記ストリームＮ＋１にＡｌｌｏｃｂｕｆ［Ｎ
    ＋１］に等しい前記合計バッファ空間量を割り振り、そ
    れ以外の場合は、レート保証Ｒ_N+1を求める前記レート
    要求を拒否するステップとを含む方法。
24. 【請求項２４】前記合計バッファ空間量を前記ストリー
    ムＮ＋１に割り振る前記ステップが、以下の式 【数１】 に従って行われ、Ｃが前記ストリームＮ＋１の前記パケ
    ットが送信される前記出力リンクのバイト／秒で表され
    た速度である、請求項２３に記載の方法。
25. 【請求項２５】前記未割り振り合計バッファ空間量Ｓｐ
    ａｒｅｂｕｆを計算する前記ステップが、以下の式 Ｓｐａｒｅｂｕｆ＝Ｔｏｔａｌｂｕｆ−ΣＡｌｌｏｃＢ
    ｕｆ［ｎ］ に従って行われる、請求項２３に記載の方法。
26. 【請求項２６】前記ストリームＮ＋１のためのレート保
    証を求める前記要求を受け入れた後で、前記共用バッフ
    ァ空間Ｓｐａｒｅｂｕｆが以下の式 Ｓｐａｒｅｂｕｆ＝Ｓｐａｒｅｂｕｆ−ＡｌｌｏｃＢｕ
    ｆ［Ｎ＋１］ に従って更新される、請求項３８に記載の方法。
27. 【請求項２７】前記ストリームＮ＋１のためのレート保
    証を求める前記要求を受け入れた後で、前記未割り振り
    バッファ空間ＳｈａｒｅｄＢｕｆが以下の式 ＳｈａｒｅｄＢｕｆ＝ＳｈａｒｅｄＢｕｆ−Ａｌｌｏｃ
    Ｂｕｆ［Ｎ＋１］に 従って更新される、請求項２３に記載の方法。
28. 【請求項２８】前記ストリームｐのためのレート保証Ｒ
    _pを求める前記要求の終了後に、Ｓｐａｒｅｂｕｆが Ｓｐａｒｅｂｕｆ＝Ｓｐａｒｅｂｕｆ＋ＡｌｌｏｃＢｕ
    ｆ［ｐ］ のように更新され、ｐは終了した前記ストリームを表す
    １からＮ＋１までの範囲の整数である請求項２３に記載
    の方法。
29. 【請求項２９】前記ストリームｐのためのレート保証Ｒ
    _pを求める前記要求の終了後に、前記共用バッファ空間
    ＳｈａｒｅｄＢｕｆが以下の式 ＳｈａｒｅｄＢｕｆ＝ＳｈｒｅｄＢｕｆ＋ＡｌｌｏｃＢ
    ｕｆ［ｐ］ に従って更新される、請求項２３に記載の方法。
30. 【請求項３０】前記出力リンクに複数のバッファが関連
    づけられ、前記パケット交換ネットワークが前記複数の
    バッファからの送信を待つパケット間のアービトレーシ
    ョンを行うスケジューラをさらに含む、請求項１に記載
    の方法。
31. 【請求項３１】各パケット・ストリームｎが１からＮま
    での範囲のインデックスが付けられ、パケット交換ネッ
    トワークにおける共通出力リンクｊ上での転送のために
    多重化され、前記リンクが前記パケットを格納するため
    のバイト数で表された合計バッファ空間を有するバッフ
    ァから成る、複数のパケット・ストリームｎの各パケッ
    ト・ストリームに明示的なレート保証Ｒを提供する方法
    のステップを実行するように機械によって実行可能な命
    令から成るプログラムを有形に実施する機械可読コンピ
    ュータ・プログラム装置であって、前記方法が、 ａ）各現在の受信パケットについて、前記現在の受信パ
    ケットに関連づけられたパケット・ストリームｎを識別
    するステップと、 ｂ）前記現在の受信パケットを前記合計バッファ空間の
    専有部分に加えて第１の和を求めるステップと、 ｃ）前記第１の和が第１のしきい値を超えるか否かを判
    断し、それに応答して第１の変数を設定するステップ
    と、 ｄ）前記現在の受信パケットを前記ストリームｎに割り
    振られた前記バッファ空間の占有部分に加えて第２の和
    を求めるステップと、 ｅ）前記第２の和が第２のしきい値を超えるか否かを判
    断し、それに応答して第２の変数を設定するステップ
    と、 ｆ）前記第１及び第２の変数に基づいて前記パケットを
    受け入れるかまたは拒否し、それによって前記レート保
    証Ｒを保証するステップとを含むコンピュータ・プログ
    ラム装置。
32. 【請求項３２】前記第１のしきい値が前記合計バッファ
    空間である、請求項３１に記載のコンピュータ・プログ
    ラム装置。
33. 【請求項３３】前記第２のしきい値が、前記合計バッフ
    ァ空間のうちのパケット・ストリームｎに割り振られた
    部分である、請求項３１に記載のコンピュータ・プログ
    ラム装置。
34. 【請求項３４】前記合計バッファ空間が割り振りバッフ
    ァ空間と共用バッファ空間とを含む、請求項３１に記載
    のコンピュータ・プログラム装置。
35. 【請求項３５】前記合計バッファ空間が、バイト数で表
    された前記合計バッファ空間の前記占有部分を追跡する
    関連づけられた合計バッファ・カウンタを有する、請求
    項３４に記載のコンピュータ・プログラム装置。
36. 【請求項３６】前記共用バッファ空間が、バイト数で表
    された前記共用バッファ空間の未占有部分を追跡する関
    連づけられた共有バッファ・カウンタＳｈａｒｅｄＢｕ
    ｆを有する、請求項３４に記載のコンピュータ・プログ
    ラム装置。
37. 【請求項３７】前記割り振りバッファ空間が前記合計バ
    ッファ空間のうち、レート保証Ｒ_nを保証するストリー
    ムｎに割り振られた部分を表し、ｎ＝１．．．Ｎであ
    る、請求項３４に記載のコンピュータ・プログラム装
    置。
38. 【請求項３８】前記共用バッファ空間のうちの現在未占
    有の部分からバイト数で表された前記現在の受信パケッ
    トの長さを引いた値が第３のしきい値以上であるか否か
    を判断し、それに応答して第３の変数を設定するステッ
    プをさらに含む、請求項３４に記載のコンピュータ・プ
    ログラム装置。
39. 【請求項３９】ステップ（ｆ）が前記第３の変数に基づ
    いて前記パケットを受け入れるかまたは拒否するステッ
    プをさらに含む、請求項３８に記載のコンピュータ・プ
    ログラム装置。
40. 【請求項４０】前記第３のしきい値がゼロである、請求
    項３８に記載のコンピュータ・プログラム装置。
41. 【請求項４１】前記第１のしきい値を超えず、前記第２
    のしきい値を超えない場合、前記合計バッファ空間のう
    ちのストリームｎに割り振られた前記部分に現在の受信
    パケットを加えるステップをさらに含む、請求項３５に
    記載のコンピュータ・プログラム装置。
42. 【請求項４２】前記現在の受信パケットを受け入れる場
    合、前記合計バッファ・カウンタをバイト数で表された
    現在の受信パケットの長さだけ増分するステップをさら
    に含む、請求項４１に記載のコンピュータ・プログラム
    装置。
43. 【請求項４３】前記パケットを受け入れる場合、前記現
    在の受信パケットが属する前記ストリームに関連づけら
    れたストリーム・バッファ・カウンタを、バイト数で表
    された前記現在の受信パケットの長さだけ増分するステ
    ップをさらに含む、請求項４１に記載のコンピュータ・
    プログラム装置。
44. 【請求項４４】第１のしきい値を超えず、第２のしきい
    値を超え、第３のしきい値を超える場合、前記現在の受
    信パケットを前記共用バッファ空間に加えるステップを
    さらに含む、請求項３８に記載のコンピュータ・プログ
    ラム装置。
45. 【請求項４５】前記現在の受信パケットを前記共用バッ
    ファ空間に受け入れる場合、共用バッファ・カウンタを
    バイト数で表された前記現在の受信パケットの長さだけ
    減分するステップをさらに含む、請求項３６に記載のコ
    ンピュータ・プログラム装置。
46. 【請求項４６】前記パケットが送信の前に待ち行列化さ
    れ、前記合計バッファ空間に格納される、請求項３４に
    記載のコンピュータ・プログラム装置。
47. 【請求項４７】ストリームｍに関連づけられたパケット
    を送信する場合、前記合計バッファ空間のうちのストリ
    ームｍに割り振られた前記部分から前記現在の受信パケ
    ットを削除するステップをさらに含む、請求項３５に記
    載のコンピュータ・プログラム装置。
48. 【請求項４８】前記合計バッファ・カウンタをバイト数
    で表された前記現在の送信パケットの長さだけ減分する
    ステップをさらに含む、請求項４７に記載のコンピュー
    タ・プログラム装置。
49. 【請求項４９】前記現在の送信パケットのストリームに
    関連づけられたストリーム・バッファ・カウンタを、バ
    イト数で表された前記現在の送信パケットの長さだけ減
    分するステップをさらに含む、請求項４７に記載のコン
    ピュータ・プログラム装置。
50. 【請求項５０】前記共用バッファ空間からパケットを送
    信する場合、前記共用バッファ・カウンタＳｈａｒｅｄ
    Ｂｕｆを、バイト数で表された前記現在の送信パケット
    の長さだけ増分するステップをさらに含む、請求項３６
    に記載のコンピュータ・プログラム装置。
51. 【請求項５１】前記バッファが前記出力リンクに接続さ
    れたインタフェース上に配置された、請求項３１に記載
    のコンピュータ・プログラム装置。
52. 【請求項５２】前記共通出力リンク上での前記パケット
    の送信の順序が先入れ先出し（ＦＩＦＯ）方針に基づ
    く、請求項４６に記載のコンピュータ・プログラム装
    置。