JP4838739B2

JP4838739B2 - ルータのバッファ管理方法並びにその管理方法を用いたルータ

Info

Publication number: JP4838739B2
Application number: JP2007024254A
Authority: JP
Inventors: 亮介横林; 博生土井
Original assignee: Central Research Institute of Electric Power Industry
Current assignee: Central Research Institute of Electric Power Industry
Priority date: 2007-02-02
Filing date: 2007-02-02
Publication date: 2011-12-14
Anticipated expiration: 2027-02-02
Also published as: JP2008193310A

Description

本発明は、ルータのバッファ管理方法並びにその管理方法を用いたルータに関する。さらに詳述すると、本発明は、通信ネットワークの輻輳によるルータのバッファからのパケットデータの廃棄を制御する技術に関する。

本明細書において、パケットデータとは、通信ネットワークにおいて転送されるデータであってパケットに分割されたデータを意味するものとして用いている。また、フローとは、送信側と受信側との一対一の通信のことを意味するものとして用いている。また、ウィンドウとは、通信ネットワークへ一度に送信するパケット数を決める量のことを意味するものとして用いている。

通信ネットワークを構成する通信機器であるルータはバッファを持っており、処理能力を上回る大量のパケットデータが一度に送信されてきた場合には一時的にそのパケットデータをバッファに蓄積することでトラヒックの変動を吸収する。しかし、トラヒック量やユーザ数が想定以上に増加して入力されるパケットデータ量がルータの持つバッファ容量を超えてしまう場合には、パケットデータはバッファから溢れて廃棄される。

通信ネットワークの輻輳制御は、大部分のアプリケーションがデータ転送用プロトコルとして用いるＴransmission Ｃontrol Ｐrotocol（以下、ＴＣＰと表記する）の機能により行われる。ＴＣＰは、ルータのバッファでのパケットデータの廃棄を送信端で検出し、一度に送信できるパケット量を決めるウィンドウサイズを減少させることによって通信ネットワークへのパケットデータ送出量を減らす制御を行って過度な輻輳を抑制する。また、ＴＣＰは廃棄されたパケットデータの再送も行う。

ＴＣＰは、具体的には、単一フローの同一ウィンドウ内で二以上のパケットデータが廃棄された場合、パケットデータの送出を一定時間待った後にウィンドウサイズを１に戻して再送を開始するＲetransmission Ｔime Ｏut（以下、ＲＴＯと表記する）と呼ばれる動作を行う。また、複数のフローに亘ってパケットデータが廃棄された場合にはＴＣＰが同期してこれらのフローに係る複数のウィンドウサイズを揃って減少させ、これによって通信ネットワークの伝送能力を大きく下回ってパケットデータ送出量が絞られることになり、通信ネットワークのスループット即ち通信データの伝送量が低下する。

上記のＲＴＯの発生即ち待ち時間発生に伴うデータ伝送遅延の問題並びにＴＣＰが同期して動作して複数のウィンドウサイズを揃って減少させる問題を解決するために従来からアクティブキュー管理方式が提案されている。その代表的なものにＲandom Ｅarly Ｄetection（以下、ＲＥＤと表記する）がある。ＲＥＤは、バッファが溢れてルータに入力されるパケットデータが連続して廃棄されることを防止するため、バッファが一杯になる前に、ルータに入力されるパケットデータを確率的に廃棄する。これによって、ＴＣＰのパケットデータ送出量が制御されると共に、通信ネットワークの過度な輻輳状態が回避される。

ＲＥＤ機能を活用した従来のパケットデータ伝送の制御方法としては、例えば、パケットデータを伝送するネットワークシステムがある（特許文献１）。このネットワークシステムは、図６に示すように、ネットワークの入り口に設けられて当該ネットワーク内に入ってきたパケットデータのネットワークにおける生存期間を示す変数であって経由してきたノード数が多いほど小さくなる変数であるＴime to Ｌive（以下、ＴＴＬと表記する）フィールド値を予め定められた値に設定する少なくとも一つのエッジノードと、転送すべきパケットデータ１０８が入力されるとＴＴＬフィールド値の小さなパケットデータをキュー１０４，１０５，１０６のうち優先度の高いキューへ割り当てると共にＴＴＬフィールド値の大きなパケットデータをキュー１０４，１０５，１０６のうち優先度の低いキューへ割り当てるＴＴＬ識別器１０２を有するフロー識別器１０３及び優先度の高いキューに割り当てられたパケットデータから順にＴＴＬフィールド値を１減じた後に次のノードに出力する処理を行うスケジューラ１０７を備えた少なくとも一つのノード１０１とから構成される。そして、ＲＥＤ機能によるパケットデータの廃棄においてＴＴＬフィールド値を考慮することによってより多くのノードを経由してきたパケットデータの廃棄率を小さくするものである。

特開２００３−３４８１４０号

しかしながら、特許文献１のネットワークシステムは、同一ウィンドウ内の複数パケットデータの廃棄率や再送されたパケットデータの廃棄率を小さくする仕組みを有するものではない。このため、同一ウィンドウ内の複数パケットデータの廃棄や再送されたパケットデータの廃棄によるＲＴＯの発生を効果的に抑制することはできず、通信ネットワークのスループット性能を十分に向上させることができるとは言い難い。

そこで、本発明は、同一ウィンドウ内の複数パケットデータの廃棄や再送されたパケットデータの廃棄を積極的に抑制することによってＲＴＯの発生を効果的に抑制して通信ネットワークのスループット性能を向上させることができるルータのバッファ管理方法並びにその管理方法を用いたルータを提供することを目的とする。

かかる目的を達成するため、請求項１記載のルータのバッファ管理方法は、ルータのＲＥＤ機能によって廃棄候補とされたパケットデータのうちパケットデータが属するフロー毎に管理されてルータのバッファに取り込まれると値が低減する優遇カウントが廃棄条件を満たしていないものと再送されたものとは廃棄せず、ルータに続いて入力されるパケットデータの中から優遇カウントが廃棄条件を満たし且つ再送されたものではないものを廃棄するようにしている。

また、請求項２記載のルータは、ＲＥＤ機能によってパケットデータを廃棄するか否かを判定するＲＥＤ実行手段と、ＲＥＤ実行手段の判定結果に基づいて値が変化する廃棄フラグを管理する廃棄フラグ管理手段と、廃棄フラグの値に基づいてパケットデータが廃棄候補か否かを判定する廃棄フラグ判定手段と、パケットデータがバッファに取り込まれると値が低減する優遇カウントをフロー毎に管理する優遇カウント管理手段と、優遇カウントが廃棄条件を満たしているか否かを判定する優遇カウント判定手段と、パケットデータのシーケンス番号をフロー毎に管理する再生パケットデータ管理手段と、フロー毎に管理されるシーケンス番号に基づいてパケットデータが再送されたものか否かを判定する再送パケットデータ判定手段とを有し、廃棄フラグ判定手段によって廃棄候補と判定されたパケットデータのうち優遇カウント判定手段によって優遇カウントが廃棄条件を満たしていないと判定されたものと再送パケットデータ判定手段によって再送されたものであると判定されたものとは廃棄せず、続いて入力されるパケットデータの中から優遇カウント判定手段によって優遇カウントが廃棄条件を満たしていると判定され且つ再送パケットデータ判定手段によって再送されたものではないと判定されたものを廃棄するようにしている。

したがって、このルータのバッファ管理方法並びにその管理方法を用いたルータによると、パケットデータが属するフローの優遇カウントに基づいて同一フローのパケットデータを一定数だけ廃棄しないように優遇することにより、同一フローの複数パケットデータの廃棄が抑制される。さらに、再送されたパケットデータの廃棄が抑制される。

さらに、本発明のルータのバッファ管理方法は、従来用いられてきたＲＥＤと同様にルータに機能を持たせることによって従来のＴＣＰと協調して動作するものであるので、通信ネットワークの端末側に対応する機能を持たせる必要がない。

本発明のルータのバッファ管理方法並びにその管理方法を用いたルータによれば、同一フローの複数パケットデータの廃棄が抑制されることにより同一ウィンドウの複数パケットデータの廃棄が抑制されると共に再送されたパケットデータの廃棄が抑制されるので、ＲＴＯの発生を効果的に抑制することが可能であり、通信ネットワークのスループット性能の向上を図ることができる。

さらに、本発明のルータのバッファ管理方法によれば、通信ネットワークの端末側に対応する機能を持たせる必要がないので、容易に実施可能であるという利点を有する。

以下、本発明の構成を図面に示す最良の形態に基づいて詳細に説明する。

図１から図３に、本発明のルータのバッファ管理方法の実施形態の一例を示す。このルータのバッファ管理方法は、ルータのＲＥＤ機能によって廃棄候補とされたパケットデータのうちパケットデータが属するフロー毎に管理されてルータのバッファに取り込まれると値が低減する優遇カウントが廃棄条件を満たしていないものと再送されたものとは廃棄せず、ルータに続いて入力されるパケットデータの中から優遇カウントが廃棄条件を満たし且つ再送されたものではないものを廃棄するようにしている。

上記ルータのバッファ管理方法は、本発明のバッファ管理方法を用いたルータとして実現される。本実施形態のルータは、ＲＥＤ機能によってパケットデータを廃棄するか否かを判定するＲＥＤ実行手段と、ＲＥＤ実行手段の判定結果に基づいて値が変化する廃棄フラグを管理する廃棄フラグ管理手段と、廃棄フラグの値に基づいてパケットデータが廃棄候補か否かを判定する廃棄フラグ判定手段と、パケットデータがバッファに取り込まれると値が低減する優遇カウントをフロー毎に管理する優遇カウント管理手段と、優遇カウントが廃棄条件を満たしているか否かを判定する優遇カウント判定手段と、パケットデータのシーケンス番号をフロー毎に管理する再生パケットデータ管理手段と、フロー毎に管理されるシーケンス番号に基づいてパケットデータが再送されたものか否かを判定する再送パケットデータ判定手段とを有するものである。

本発明のルータのバッファ管理方法の実行にあたっては、まず、通信ネットワーク上に設置されたルータにパケットデータが入力される（Ｓ１）。

本発明が対象とする通信ネットワークは、具体的にはＴＣＰ／ＩＰ通信ネットワークである。なお、ＴＣＰ／ＩＰ通信ネットワークのことを以降では単にネットワークと表記する。

また、本実施形態では、ＴＣＰとして、ＴＣＰの様々なバージョンの中でほとんどのＯperating Ｓystemで実装されているＴＣＰＲｅｎｏバージョンを用いた場合について説明する。

ＴＣＰはそれ自体がネットワークの過度な輻輳を抑制する機能を有する。具体的には、ＴＣＰＲｅｎｏバージョンは、輻輳ウィンドウ（Ｃongestion Ｗindowのこと）によってネットワークへ一度に送信できるパケットデータ量を変化させてパケットデータ送出量を制御する（例えば、W.R Stevens；TCP/IP Illustrated,Volume1:The Protocols，Addison Wesley Longman，１９９４年を参照）。

送信側のＴＣＰは、データが正常に送られたことを確認する確認応答パケットを受信側から受け取るたびにウィンドウサイズを増加させる。その増加幅は１パケットから始まり、２、４・・と指数関数的に大きくなるが、パケットデータ廃棄時にウィンドウサイズが直前の半分に自動設定される閾値を越えた場合には増加幅が１パケットずつになる。前者はスロースタート（ＳｌｏｗＳｔａｒｔ）フェーズ、後者は輻輳回避（ＣｏｎｇｅｓｔｉｏｎＡｖｏｉｄａｎｃｅ）フェーズと呼ばれる。そして、このようなウィンドウサイズの増加は、ネットワークの輻輳によってパケットデータの廃棄が発生するまで続けられる。

パケットデータの廃棄の検出方式とその後の再送動作には、ＲＴＯとＦast Ｒetransmissionとの二種類がある。ＲＴＯは、同一ウィンドウ内の複数パケットデータの廃棄等によって確認応答パケットが届くまでの時間がタイマ設定時間を超過することでパケットデータの廃棄を検出する方式である。この場合、ＴＣＰは、パケットデータの送出を一定時間を待った後に輻輳ウィンドウサイズを１パケットに戻してスロースタートから再送を開始する。

一方、Ｆast Ｒetransmissionは、同一ウィンドウ内の単一パケットデータを廃棄することにより、次に送信するべきパケットを示す番号が同一になっている確認応答パケットが三回届くことでパケットデータの廃棄を検出する方式である。この場合、ＴＣＰは、軽微な輻輳状態と判断し、輻輳ウィンドウサイズを直前の半分にして直ちに再送を開始する。

また、本実施形態では、バッファとＲＥＤ機能とレイヤ４の処理能力とを少なくとも有し、ネットワークを接続するための中継装置として利用されるルータが用いられる。

続いて、ルータのＲＥＤ実行手段は、ルータに入力されたパケットデータを廃棄するか否かをＲＥＤ機能によって判定する（Ｓ２）。なお、本発明のルータのバッファ管理方法に係る演算や各種の処理を実際に行うのはルータの演算部や制御部であって例えばＣＰＵ（Ｃentral Ｐrocessing Ｕnit；中央処理装置のこと）であるが、本明細書においては単にルータと表記したり、演算部や制御部に構成される手段として表記する。

ＲＥＤ機能自体は周知の技術であるのでここでは詳細については省略する（例えば、S.Floyd and V.Jacobson；Random early detection gateways for congestion avoidance，IEEE/ACM Trans.Netw.，vol.１，no.４，pp.３９７−４１３，１９９３年８月を参照）。なお、ＲＥＤ機能はルータに実装される。

本発明で用いられるＲＥＤ機能の具体的なアルゴリズムは以下のとおりである。ＲＥＤは、現在のバッファ長の短期的な変動の影響を受けないように一定期間のバッファ長を平均化した平均バッファ長の増加に従ってパケットデータ廃棄率を０より大きい値にし更に増加させる。平均バッファ長Ｑａは、パケットデータ到着毎に指数平均（ＥＷＭＡ：Ｅxponential Ｗeighted Ｍoving Ａverage）を用いて現在のバッファ長Ｑから数式１により計算される。

（数１）Ｑａ←（１−Ｗｑ）Ｑａ＋ＷｑＱ
ここに、Ｑａ：平均バッファ長，Ｗｑ：現在のバッファ長の重みを決定するパラメータ（ただし、０＜Ｗｑ＜１），Ｑ：現在のバッファ長。

そして、平均バッファ長Ｑａに対して最小閾値ＭＩＮth及び最大閾値ＭＡＸthの二つの閾値を設けてパケットデータの廃棄処理が行なわれる。具体的には、図２に示すように、パケットデータ廃棄率は、平均バッファ長ＱａがＭＩＮthから増加を始め、平均バッファ長ＱａがＭＡＸthのときにＭＡＸｐとなる。そして、平均バッファ長ＱａがＭＡＸthを超えると全てのパケットが廃棄される。

これらＭＩＮth，ＭＡＸth，ＭＡＸｐの閾値はＲＥＤのパラメータであり、これらパラメータによってパケットデータ廃棄の程度が決まる。廃棄の程度が過剰の場合には不必要なＲＴＯが多くなり、不足の場合にはバッファ溢れによってやはりＲＴＯが多くなる。そのため、ＲＥＤ機能を適切に作動させるためには、パケットデータの廃棄の過不足が生じないように閾値を最適に設定することによってＲＴＯの抑制効果を最大とする必要がある。

Ｓ２の処理において、ルータに入力されたパケットデータをＲＥＤ機能によって廃棄すると判定した場合には（Ｓ２；Ｙｅｓ）、ルータの廃棄フラグ管理手段は廃棄フラグＤｆの値を１増やす（Ｓ３）。

廃棄フラグＤｆは、ＲＥＤ機能によるパケットデータの廃棄指令を後に続く処理に引き継ぐための変数であり、ルータあるいはバッファを単位として設定される。

廃棄フラグＤｆは、０，１，２のいずれかの値をとり、パケットデータの廃棄処理の当初の段階で０に設定され、ＲＥＤ機能によって廃棄指令が出された場合に１となる。そして、ルータは廃棄フラグＤｆの値が１の状態で本発明の制御方法の要件を満たす即ち廃棄すべきパケットデータを探し、要件を満たすパケットデータが出現する前にＲＥＤ機能によって廃棄指令が更に出された場合に廃棄フラグＤｆの値が２となる。なお、廃棄フラグＤｆの最大値は２とする。

一方、パケットデータをＲＥＤ機能によって廃棄しないと判定した場合には（Ｓ２；Ｎｏ）、ルータの廃棄フラグ判定手段は廃棄フラグＤｆの値を確認する（Ｓ４）。

そして、廃棄フラグＤｆの値が０である場合には（Ｓ４；Ｎｏ）、ルータの優遇カウント管理手段は処理対象のパケットデータが属するフローの優遇カウントＦｃの値を１減らす（Ｓ７）。そして、ルータは当該パケットデータをバッファに取り込んで（Ｓ１３）当該パケットデータに関する処理を終える（ＥＮＤ）。

優遇カウントＦｃは、同一ウィンドウ内の複数パケットデータの廃棄を回避するための変数であり、フロー毎に管理される。なお、ルータに入力されるパケットデータのフローはＩＰヘッダのアドレス番号によって識別される。

優遇カウントＦｃは、処理開始時（ＳＴＡＲＴ）に初期優遇値Ｎに設定される。初期優遇値Ｎは、１〜６０程度の範囲、好ましくは３０〜６０程度の範囲、最も好ましくは５０程度に設定されることが考えられるが、６０を超える値であっても構わない。なお、優遇カウントＦｃはゼロやマイナスの値になる場合がある。

Ｓ３の処理に引き続いて、若しくはＳ４の処理において廃棄フラグＤｆの値が０より大きい場合には（Ｓ４；Ｙｅｓ）、ルータの廃棄フラグ判定手段は廃棄フラグＤｆの値を確認する（Ｓ５）。

そして、廃棄フラグＤｆの値が２でない場合には（Ｓ５；Ｎｏ）、ルータの優遇カウント判定手段は処理対象のパケットデータが属するフローの優遇カウントＦｃの値を確認する（Ｓ６）。

そして、優遇カウントＦｃの値が０より大きい場合には（Ｓ６；Ｙｅｓ）、ルータの優遇カウント管理手段は処理対象のパケットデータが属するフローの優遇カウントＦｃの値を１減らす（Ｓ８）。そして、ルータは当該パケットデータをバッファに取り込んで（Ｓ１４）当該パケットデータに関する処理を終える（ＥＮＤ）。

このように、本発明では、フローの優遇カウントＦｃの値が０より大きい場合には、そのフローに属するパケットデータを廃棄しない。これによって、同一フローの同一ウィンドウ内の複数パケットデータの廃棄が抑制されてＲＴＯの発生が抑制される。

ここで、図３（Ａ）に示すように、ＲＥＤ機能では、廃棄するパケットデータＰ１が単に確率的に選択され、次に廃棄するパケットデータＰ５も単に確率的に選択される。すなわち、既に廃棄したパケットデータＰ１と次に廃棄するパケットデータＰ５とが同一ウィンドウのものであるか否かを考慮することなくパケットデータを廃棄するので、同一ウィンドウ内の複数パケットデータの廃棄が抑制されずに行われることになり、ＲＴＯが発生してネットワークのスループット性能が低下してしまう。

これに対して本発明の場合には、既に廃棄したパケットデータＰ１が属するフローに係る新たに入力されたパケットデータを一定数だけ廃棄しないように優遇する処理を行うことで同一ウィンドウの複数パケットデータの廃棄を確率的に回避する。

具体的には、図３（Ｂ）に示すように、フローの優遇カウントＦｃを用いてフローの優遇性を考慮することにより、廃棄したパケットデータＰ１が属するフローの優遇カウントＦｃが０より大きく優遇性が高い場合にはＲＥＤ機能によって廃棄として選択されたパケットデータＰ５の廃棄を回避し、続けて入力されるパケットデータを順に調べて廃棄条件を満たすパケットデータＰ７を見つけ出して廃棄する。これによって、パケットデータＰ１が既に廃棄されたウィンドウと同一ウィンドウのパケットデータＰ５の廃棄が回避され、ＲＴＯの発生が回避されてネットワークのスループット性能の低下が防止される。

なお、優遇処理はパケットデータが廃棄されたフローを対象とするため、短いフローのみが有利になることはない。また、優遇カウントＦｃはルータを通過するパケットデータが多いフローほど早く消費されるため、大きな帯域を占めるフローのみが有利になることはない。すなわち、本発明では、特定の特質を有するフローのみが極端に優遇されたり抑制されたりすることがないので、偏りのないパケットデータ伝送の制御が行われる。

続いて、Ｓ５の処理において廃棄フラグＤｆの値が２である場合（Ｓ５；Ｙｅｓ）、並びに、Ｓ６の処理において優遇カウントＦｃの値が０以下の場合には（Ｓ６；Ｎｏ）、ルータの再送パケットデータ判定手段はパケットデータの属性として処理対象のパケットデータが再送されたパケットデータか否かを判定する（Ｓ９）。

処理対象のパケットデータが再送されたパケットデータか否かは、ルータに入力されたパケットデータのＴＣＰヘッダのシーケンス番号をフロー毎に管理することによって識別される。再送パケットデータ管理手段はパケットデータのシーケンス番号をフロー毎に管理する。

そして、処理対象のパケットデータが再送されたパケットデータである場合には（Ｓ９；Ｙｅｓ）、ルータはＳ８の処理に移行して優遇カウント管理手段は処理対象のパケットデータが属するフローの優遇カウントＦｃの値を１減らす（Ｓ８）。そして、ルータは当該パケットデータをバッファに取り込んで（Ｓ１４）当該パケットデータに関する処理を終える（ＥＮＤ）。

これによって、パケットデータが既に廃棄されたフローから再送されたパケットデータの廃棄が回避され、ＲＴＯの発生が回避されてネットワークのスループット性能の低下が防止される。

一方、再送されたパケットデータでない場合には（Ｓ９；Ｎｏ）、ルータは当該パケットデータをバッファに取り込むことなく廃棄する（Ｓ１０）。

続いて、ルータの廃棄フラグ管理手段は廃棄フラグＤｆの値を１減らし（Ｓ１１）、優遇カウント管理手段は処理対象のパケットデータが属するフローの優遇カウントＦｃを初期優遇値Ｎにする（Ｓ１２）。そして、ルータは当該パケットデータに関する処理を終える（ＥＮＤ）。

そして、ルータは、Ｓ１の処理に戻り、ルータに新たに入力されたパケットデータについてＳ１からＳ１４までの処理を繰り返す。

なお、ルータ若しくはバッファ単位の廃棄フラグＤｆの値、及びフロー毎の優遇カウントＦｃの値は次に入力されたパケットデータの処理をする際にそのまま用いられる。このため、ルータの廃棄フラグ管理手段及び優遇カウント管理手段はこれらの値を記憶したままＳ１の処理に戻る。さらに、再送パケットデータ管理手段はフロー毎に管理されてＳ９の処理で利用される入力されたパケットデータのＴＣＰヘッダのシーケンス番号を記憶したままＳ１の処理に戻る。

したがって、先に入力されたパケットデータに対してＲＥＤ機能による最初の廃棄指令が出されると（Ｓ２；Ｙｅｓ）廃棄フラグＤｆ＝１となる（Ｓ３）。そして、当該パケットデータが属するフローの優遇性（Ｓ６）と当該パケットデータの属性（Ｓ９）とから当該パケットデータを廃棄しないと判定した場合には、廃棄フラグＤｆ＝１のまま次に入力されたパケットデータの処理に移る。そして、次に入力されたパケットデータについてはＲＥＤ機能による廃棄指令が出されない場合であっても（Ｓ２；Ｎｏ）、廃棄フラグＤｆ＝１であってＲＥＤ機能による廃棄指令継続状態即ちパケットデータの廃棄待ち状態であると判断され（Ｓ４；Ｙｅｓ）、ＲＥＤ機能による廃棄指令が出されていないパケットデータについても当該パケットデータが属するフローの優遇性（Ｓ６）と当該パケットデータの属性（Ｓ９）とから当該パケットデータの廃棄の可否について判断する。また、廃棄フラグＤｆ＝１の状態で次に入力されたパケットデータについてもＲＥＤ機能による廃棄指令が出された場合には（Ｓ２；Ｙｅｓ）、廃棄フラグＤｆ＝２となって（Ｓ３）、フローの優遇性を考慮しない処理に変わる（Ｓ５；Ｙｅｓ）。そして、これにより、再送されたパケットデータを除く全てのパケットデータが廃棄されるので、パケットデータの廃棄が滞らなくなり、パケットデータの廃棄の過度な抑制が防がれてバッファ溢れが防止される。

なお、上述の形態は本発明の好適な形態の一例ではあるがこれに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々変形実施可能である。例えば、本実施形態では、ＲＥＤ機能による廃棄制御と優遇カウントＦｃに基づく廃棄制御と再送であるか否かに基づく廃棄制御とをルータに入力されたパケットデータ毎に逐次行うようにしているが、これに限られず、廃棄フラグＤｆが１から２となる間にルータに入力されるパケットデータを全てバッファへ取り込み、バッファの中からこの期間で最小の優遇カウントＦｃを持つパケットデータを選択して廃棄するようにしても良い。なお、この場合もバッファでの滞留時間は変わらないので遅延を起こすことなくデータ伝送を行うことができる。そして、これにより、優遇カウントＦｃの初期値である初期優遇値Ｎは例えば９９９９９など単に十分に大きな値にしておけば良いのでネットワークのトラヒック状況に応じて設定する手間を省くことができ、且つ、ＲＥＤによる廃棄制御によって廃棄が指令された場合に優遇カウントＦｃの残存状況にかかわらず常にいずれかのパケットデータが選択され廃棄されるので本発明の性能を十分に発揮させることができる。

また、本実施形態では、パケットデータが属するフローの優遇性（Ｓ６）とパケットデータの属性（Ｓ９）との両方を考慮してパケットデータを廃棄するか否かを判定するようにしているが、これに限られず、パケットデータが属するフローの優遇性のみを考慮するようにしても良い。この場合もＲＥＤ機能によって廃棄するパケットデータを単に確率的に選択する場合と比べて同一ウィンドウ内の複数パケットデータの廃棄が抑制されるので本発明の性能を発揮させることができる。そして、この場合には、レイヤ３の処理能力を有するルータを用いれば良いので、レイヤ４の処理能力を有するルータを用いる場合と比べてコストダウンを図ることができる。

また、本実施形態では、廃棄フラグＤｆ＝２の場合に（Ｓ５；Ｙｅｓ）、フローの優遇性（Ｓ６）を考慮しない一方でパケットデータの属性（Ｓ９）は考慮するようにしているが、これに限られず、フローの優遇性（Ｓ６）及びパケットデータの属性（Ｓ９）のどちらも考慮しないようにしても良い。具体的には、本実施形態のＳ５の処理においてＹｅｓの場合には次にＳ１０の処理を行ってそのままパケットデータの廃棄を行うようにしても良い。

さらに、本実施形態では、ＴＣＰとしてＲｅｎｏバージョンを用いた場合を前提とした例について主に説明したが、本発明が適用可能なＴＣＰのバージョンはこれに限られるものではなく、ＴＣＰの他のバージョンに対しても適用が可能である。なお、同一ウィンドウ内の複数パケットデータが廃棄された場合や再送されたパケットデータが廃棄された場合にデータ送出量を抑制する機能を有するＴＣＰに適用した場合に本発明の効果が特に発揮される。

本発明のルータのバッファ管理方法並びにその管理方法を用いたルータの性能評価の実施例を図４及び図５を用いて説明する。

本実施例における性能評価は計算機シミュレーションによって行った。シミュレーション用ソフトはＯＰＮＥＴ社のＯＰＮＥＴＭｏｄｅｌｅｒバージョン１１．５を用いた。そして、図４に示すクライアントであるユーザＵ１，Ｕ２，…，Ｕ１６（以下、ユーザＵｘと表記する），サーバＳ１，Ｓ２，…，Ｓ１６（以下、サーバＳｘと表記する），ユーザ側ルータＲ０，サーバ側ルータＲ１，ユーザＵｘとユーザ側ルータＲ０との間及びサーバＳｘとサーバ側ルータＲ１との間のリンクＬ１，ユーザ側ルータＲ０とサーバ側ルータＲ１との間のボトルネック回線Ｌ２からなるネットワークモデルでシミュレーションを行なった。

ユーザＵｘとサーバＳｘとの間はそれぞれ一対一でＦＴＰ（Ｆile Ｔransfer Ｐrotocolのこと）によるファイル転送を行うものとした。そして、サーバ側ルータＲ１に本発明のルータのバッファ管理方法を実装させた。なお、ユーザ側ルータＲ０は、パケットデータの宛先ＩＰアドレスを参照して当該データを宛先のユーザＵｘに単に振り分ける機能のみを有するものであって、ＲＥＤ機能によるパケットデータの廃棄制御等は行わない。すなわち、本実施例のネットワークモデルでは、サーバＳｘからユーザＵｘへ向かうトラヒックがサーバ側ルータＲ１のバッファを溢れさせる一方で、ユーザＵｘからサーバＳｘへ向かうトラヒックは微小であってユーザ側ルータＲ０のバッファを溢れさせることはない。

また、リンクＬ１のリンク帯域を１００Ｍｂｐｓ、伝送遅延を１ｍｓとした。また、ボトルネック回線Ｌ２のリンク帯域を８Ｍｂｐｓ、伝送遅延を２００ｍｓとした。なお、ボトルネック回線Ｌ２のリンク帯域は、輻輳が発生する程度に小さくすることを考慮して設定した。また、ボトルネック回線Ｌ２の伝送遅延は、ルータＲ０及びＲ１のＭＡＣ（Ｍedia Ａccess Ｃontrolのこと）層バッファによる変動吸収の影響を無視できるようにパケットデータがＭＡＣ層バッファに入らない設定としているため、これに伴うＭＡＣ層バッファでの遅延の減少分をボトルネック回線Ｌ２の伝送遅延によって補うことを考慮して設定した。

ユーザＵｘとサーバＳｘとはＴＣＰＲｅｎｏを実装し、最大ウィンドウサイズは６５，５３５ｂｙｔｅ、パケットサイズは１，５００ｂｙｔｅとした。

サーバ側ルータＲ１のＲＥＤ機能は、事前の検討も踏まえてＲＴＯ発生の抑制効果が最大となるようにバッファの最小閾値ＭＩＮth＝９パケット，バッファの最大閾値ＭＡＸth＝４６パケット，最大廃棄率ＭＡＸｐ＝１／６とした。なお、サーバ側ルータＲ１のＲＥＤ機能がこれらの条件を有する場合を最適廃棄ケースと呼ぶ。

ユーザＵｘとサーバＳｘとの間（以下、ユーザＵｘ〜サーバＳｘと表記する）の各フローのうち、ユーザＵ３〜サーバＳ３，ユーザＵ４〜サーバＳ４，…，ユーザＵ１６〜サーバＳ１６の１４フローは、先に帯域を占める先行トラヒックを模擬するものとして無限長のファイルが常時送信される設定にした。すなわち、ボトルネック回線Ｌ２の帯域が、ファイル長が限定されない１４フローに先行して占められていることになる。なお、事前の検討によって先行フロー数を７以上にすると輻輳が発生することを確認した上で、輻輳を発生させるに十分なフロー数とすることを考慮して１４フローとした。

一方、ユーザＵ１〜サーバＳ１並びにユーザＵ２〜サーバＳ２の２フローは、後から二つ同時に入ってくる追加トラヒックを模擬するものとして３００Ｋｂｙｔｅの固定長ファイルが２０秒周期で送信される設定にした。これにより、サーバ側ルータＲ１のバッファからパケットデータが溢れて周期的に輻輳状態が発生する状態が模擬される。なお、追加トラヒックのファイル長は特に限定されるものではないが、事前の検討に基づいて最も大きな輻輳を発生させる長さとした。また、追加フロー数は１以上であれば輻輳が発生するところ、先行フローと同様に輻輳を発生させるに十分なフロー数とすることを考慮して２フローとした。

なお、このモデルでは、ボトルネック回線Ｌ２の帯域、フロー数、バッファサイズを同一の倍率で拡大・縮小しても同じ結果が得られる。したがって、このネットワークモデルによって、本実施例のネットワーク規模に限られることなく、現実的な大規模ネットワークについての本発明の効果を検証することができる。

シミュレーション時間は６００秒とした。すなわち、この間に３０回の追加トラヒックが発生し、その度にネットワークが輻輳状態になる。

ここで、従来のＲＥＤに対しては、トラヒック状況によって最適なパラメータ設定が異なるので効果が安定しないという問題点が指摘されている（S.Flod, R.Gummadi and S.Shenker；Adaptive RED:An Algorithm for Increasing the Robustness of RED's Active Queue Management，Technical Report，２００１年８月を参照）。

そこで、本実施例では、最適廃棄ケースの最適設定からのずれによるＲＴＯ発生頻度の増加に対する本発明の抑制効果を評価した。具体的には、最適廃棄ケースを基準として、追加トラヒックを３フローに増加させて輻輳を大きくすることでＲＥＤの廃棄率が不足するようにした不足廃棄ケース、及び、先行トラヒックを１０フローに減少させて輻輳を小さくすることでＲＥＤの廃棄率が過剰となるようにした過剰廃棄ケースについてもシミュレーションを行った。

さらに、本発明のルータのバッファ管理方法の設定として、優遇カウントＦｃの初期優遇値Ｎを０から６０まで５ずつ変化させた場合それぞれについてシミュレーションを行った。なお、初期優遇値Ｎ＝０の場合は、本発明の処理のうち再送されたパケットデータの廃棄の回避処理のみが実行されている場合となる。

また、本発明のルータのバッファ管理方法の効果の検証を行うためにサーバ側ルータＲ１にＲＥＤ機能のみを実装させた場合を比較例として設定した。

そして、本実施例では、１回の輻輳につき全フロー数のうちＲＴＯが発生するフロー数の割合をＲＴＯ発生率とし、比較例を基準としたＲＴＯ発生率の減少効果で本発明の性能評価を行った。なお、ＲＴＯ発生率は３０回の平均で求めた。ここで、ＲＴＯが発生した場合の待ち時間のＴＣＰのデフォルト設定は３秒であり、しかも輻輳の程度が大きい場合には更に増加する仕組みとなっており、ＲＴＯが１回発生すると３秒以上の待ち時間が生じ、その分データ伝送が遅延してユーザＵｘの利便性を害することになる。

以上の条件を用い、廃棄条件ケース（すなわち、最適廃棄ケース，不足廃棄ケース，過剰廃棄ケース）別に、本発明のルータのバッファ管理方法に係る初期優遇値Ｎの値別のシミュレーションと比較例のシミュレーションとを行った。そして、本発明を適用した場合の廃棄条件ケース別のＲＴＯ発生率について初期優遇値Ｎの変化に対する推移として図５に示す結果が得られた。

いずれの廃棄条件ケースにおいても、ＲＴＯ発生率は初期優遇値Ｎの増加に伴って急激に減少し、初期優遇値Ｎ＝２０付近から変化が緩やかになった。そして、初期優遇値Ｎ＝５０で最も小さい値（不足廃棄ケースでは二番目に小さい値）となった。なお、ＲＴＯ発生の減少効果は、特定のフローだけでなく、全フローで生じていた。

一方、比較例のＲＴＯ発生率は、最適廃棄ケースで９．５％，不足廃棄ケースで１５．６％，過剰廃棄ケースで１５．２％となった。

これらから、比較例のＲＴＯ発生率に対する本発明を適用した場合のＲＴＯ発生率の減少効果を［（比較例のＲＴＯ発生率）−（本発明のＲＴＯ発生率）］／（比較例のＲＴＯ発生率）×１００（％）によって算出した。なお、本発明のＲＴＯ発生率は初期優遇値Ｎ＝５０の場合の値を用いた。その結果、本発明によるＲＴＯ発生率の減少効果は、最適廃棄ケースで８８％，不足廃棄ケースで８２％，過剰廃棄ケースで７８％となった。

以上の結果から、本発明の制御方法を用いることによって従来の制御方法である比較例と比べてＲＴＯの発生が大きく抑制されることが確認された。

また、いずれの廃棄条件ケースにおいても初期優遇値Ｎ＝５０で最小値（不足廃棄ケースでは二番目に小さい値）となったことから、本発明を用いる場合、初期優遇値Ｎの設定は好ましくは３０〜６０程度、最も好ましくは５０程度とすれば良いことが確認された。

また、本発明の制御方法はいずれの廃棄条件ケースにおいても安定した性能を発揮するものであってネットワークのトラヒック状況の変化による大きな性能低下は見られず、本発明を用いた場合にはネットワークの状況変化のスループット性能への影響は小さいことが確認された。さらに、このことから、トラヒック状況によって最適なパラメータ設定が異なるので効果が安定しないという従来のＲＥＤ機能の問題点も改善できることが確認された。

本発明のルータのバッファ管理方法の実施形態の一例を説明するフローチャートである。パケットデータの廃棄率と閾値との間の関係を示す図である。本発明による同一ウィンドウ内の複数パケットデータ廃棄並びに再送されたパケットデータ廃棄の回避を説明する概念図である。実施例のシミュレーションモデルの構成を説明する図である。実施例における本発明を適用した場合のＲＴＯ発生率の結果を示す図である。従来のパケットデータ伝送の制御方法におけるネットワークノードの構成を示すブロック図である。

符号の説明

Ｕ１，Ｕ２，…，Ｕ１６ユーザ
Ｓ１，Ｓ２，…，Ｓ１６サーバ
Ｌ１リンク
Ｌ２ボトルネック回線
Ｒ０，Ｒ１ルータ

Claims

ルータのＲＥＤ機能によって廃棄候補とされたパケットデータのうち前記パケットデータが属するフロー毎に管理されて前記ルータのバッファに取り込まれると値が低減する優遇カウントが廃棄条件を満たしていないものと再送されたものとは廃棄せず、前記ルータに続いて入力されるパケットデータの中から前記優遇カウントが廃棄条件を満たし且つ再送されたものではないものを廃棄することを特徴とするルータのバッファ管理方法。
ＲＥＤ機能によってパケットデータを廃棄するか否かを判定するＲＥＤ実行手段と、前記ＲＥＤ実行手段の判定結果に基づいて値が変化する廃棄フラグを管理する廃棄フラグ管理手段と、前記廃棄フラグの値に基づいて前記パケットデータが廃棄候補か否かを判定する廃棄フラグ判定手段と、前記パケットデータがバッファに取り込まれると値が低減する優遇カウントをフロー毎に管理する優遇カウント管理手段と、前記優遇カウントが廃棄条件を満たしているか否かを判定する優遇カウント判定手段と、前記パケットデータのシーケンス番号をフロー毎に管理する再生パケットデータ管理手段と、前記フロー毎に管理されるシーケンス番号に基づいて前記パケットデータが再送されたものか否かを判定する再送パケットデータ判定手段とを有し、前記廃棄フラグ判定手段によって廃棄候補と判定されたパケットデータのうち前記優遇カウント判定手段によって前記優遇カウントが前記廃棄条件を満たしていないと判定されたものと前記再送パケットデータ判定手段によって再送されたものであると判定されたものとは廃棄せず、続いて入力されるパケットデータの中から前記優遇カウント判定手段によって前記優遇カウントが前記廃棄条件を満たしていると判定され且つ前記再送パケットデータ判定手段によって再送されたものではないと判定されたものを廃棄することを特徴とするルータ。