JP2003318967A - 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 - Google Patents
帯域制御方法および輻輳制御方法ならびにネットワーク構成装置Info
- Publication number
- JP2003318967A JP2003318967A JP2002120625A JP2002120625A JP2003318967A JP 2003318967 A JP2003318967 A JP 2003318967A JP 2002120625 A JP2002120625 A JP 2002120625A JP 2002120625 A JP2002120625 A JP 2002120625A JP 2003318967 A JP2003318967 A JP 2003318967A
- Authority
- JP
- Japan
- Prior art keywords
- control
- time
- packet
- rate
- input side
- 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.)
- Granted
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
強い、1組のノード間に転送されるトラヒックに対する
帯域制御方法を提供する。 【解決手段】入力側は一定時間ごとに送信時刻と送信デ
ータ累積量とを含む制御パケットを出力側に送信する
(ステップB2)。出力側はこの制御パケットを受信する
と、受信時刻と受信データ累積量をさらに書き加えて入
力側に返送する(ステップE2)。入力側は、制御パケッ
トを受信するたびに制御パケット内の情報に基づいて入
力レートおよび出力レートの変化分をそれぞれ算出し
(ステップC1〜C5)、これに基づいて入力側から出力
側への送信許容レートを更新する(ステップC6)。
Description
における帯域制御方法および輻輳制御方法に関し、特に
インターネットにおける1組のノードもしくは1組の端
末もしくはノードと端末の間などで実行される帯域制御
方法および輻輳制御方法に関する。
ク資源に対して加えられるトラヒック量がネットワーク
の容量をこえる過負荷が継続するという状態が発生しう
る。これを輻輳状態と呼ぶ。ここでネットワーク資源と
はノードにおけるバッファの蓄積容量やノードが終端す
るリンクの伝送容量である。こうした輻輳を防止もしく
は回復するための制御を一般に輻輳制御と呼ぶが、ここ
では以下、輻輳の発生を回避するための制御を特に輻輳
防止制御と呼び、また発生した輻輳を回復するための制
御を輻輳回復制御と呼んで区別する。
輻輳防止制御は、端末に実装されているTCPにおけるウ
インドサイズの動的な変更によって実現されている。こ
こで端末はノードとは異なり、トランスポートレイヤお
よびアプリケーションレイヤのプロトコルが実装されて
いる。また、TCPとはInternetworking with TCP/IP vol
ume 1 Douglas E. Comer著 Prentice Hall刊でも解説さ
れているように、1組の端末間で信頼性の高い通信を行
なうためのプロトコルでトランスポートレイヤに位置す
る。またウインドサイズとは、送信側の端末が、パケッ
トの正常な受信に対して受信側の端末が送信側の端末に
返送する確認応答を待つことなく、送信側の端末が連続
して送信できるデータ量をさす。そして、輻輳防止のた
めのウインドサイズの動的な変更では、送信側の端末が
確認応答を受信する毎にウインドサイズを一定量増や
し、データパケットの廃棄を検出した場合は、ウインド
サイズを半分に減らす。
Kalyanaraman, "Edge-To-Edge Traffic Control for th
e Internet," RPI ECSE Networks Laboratory Technica
l Report, ECSE-NET-2000-1. March 2000では、ネット
ワーク内の1組のエッジノード間に転送されるトラヒッ
クに対して帯域を適応的に割り当てる帯域制御方法が提
案されている。ここでエッジノードとは端末を収容する
ノードをさす。この帯域制御方法によれば、ネットワー
ク内の輻輳は各エッジノードに分散されるので、ノード
内バッファでのパケットの平均的蓄積量を削減したり、
また各TCPのコネクションが得られるスループットの公
平性を向上させたりという効果がもたらされる。
いないトランスポートプロトコル(例えばUDP)もしく
はアプリケーションプロトコルに基づくトラヒックがネ
ットワーク内に大量流入して発生する深刻な輻輳状態を
回避する輻輳防止制御をネットワーク側で実行できる。
ここでUDPとはInternetworking with TCP/IP volume1 D
ouglas E. Comer著 Prentice Hall刊にも解説されてい
るように、データの信頼性の高い転送は保証しないもの
の、データが発生したら直ちに転送できるためのプロト
コルで、トランスポートレイヤに相当する。TCPのトラ
ヒックのみが存在するネットワークに大量のUDPのトラ
ヒックが流入して輻輳状態になると、TCPのトラヒック
はそこに組み込まれている輻輳防止機構により流入量を
自ら削減してしまう追出しという問題も、この帯域制御
方法によれば発生しない。
て具体的に説明する。以下、帯域制御をその間で実行す
る1組のノードにおいて、データパケットを送信するノ
ードを入力側と呼び、データパケットを受信するノード
を出力側と呼ぶ。帯域制御は入力側から出力側へ転送さ
れるトラヒックに対して帯域を適応的に割り当てること
になる。また、入力側と出力側との間で帯域制御を行な
うための情報をやりとりするためのパケットを特に制御
パケットと呼んでデータパケットと区別する。さらに、
入力側が出力側に送信する制御パケットを特に順方向制
御パケット、出力側が入力側に送信する制御パケットを
逆方向制御パケットと呼ぶ。
ットと順方向制御パケットとを含む)の送信許容レート
rを算出するが、これによりパケットの送出を制御する
方法としてはトークンバケットシェイパーがある。図9
はこのメカニズムを説明する図である。送信許容レート
rに対して、一定のサイズSをもつトークンを一定レー
トr/Sで発生させ、最大サイズσを持つトークンバケッ
トに蓄積する。到着したパケットは、そのサイズ分だけ
トークンの総量がある場合は転送され、その時トークン
バケット内の蓄積量は転送されたパケットサイズ分だけ
減算される。もし、到着したパケットのサイズにトーク
ンの総量が達しない場合は、レートr/Sでトークンを生
成することでトークン蓄積量が到着したパケットのサイ
ズに達するまでそのパケットはバッファで待たされる。
方法について説明する。入力側は一定時間T毎に順方向
制御パケットを発生させ、送信中のデータパケットを妨
げない範囲でなるべく速やかに送信する。その際、順方
向制御パケットには、順方向制御パケットの実際の送信
時刻と入力レートλとを書き込んでおく。ここでλは、
2つの連続して送信した順方向制御パケットの送信時間
間隔τの間に送信したデータパケットのデータ総量をτ
で割ったものである。
るたび、前回受信した時刻との時間間隔ηの間に受信し
たデータパケットのデータ総量をηで割って出力レート
νを計算する。これより、出力側は、蓄積量の移動平均
値qをq←q+(λ‐ν)×τで更新する。ここで蓄積
量とは、帯域制御における入力側と出力側との間の経路
上の各ノードが、この帯域制御の対象となるトラヒック
に関して蓄積していると考えられるパケットの総量であ
る。そして、出力側では、現在が輻輳期間でない場合
は、このqがトークンバケットシェイパーのバケットサ
イズσ以上の場合は輻輳期間に入ったと判定し、νを含
む逆方向制御パケットを入力側に戻す。そして、出力側
は輻輳期間である限りは、順方向制御パケットを受信す
るごとに、入力側にνを含む逆方向制御パケットを返
す。輻輳期間を出ているときは逆方向制御パケットは返
さない。
け取ると、送信許容レートrをr←β×νに設定する。
ここでβは1未満の定数である。またこのパケットを受
け取らない間は、T時間ごとに送信許容レートrを一定
値αだけ加算して、r←r+αと更新する。よって逆方
向制御パケットは負のフィードバックになっている。
ようにしておこなう。すなわち、順方向制御パケットに
挿入された順方向制御パケットの送信時刻と、出力側が
そのパケットを受信した時刻との差分を一方向転送遅延
の測定値とし、これと現在までに測定した一方向転送遅
延の最小値との差が一定値以下の場合に輻輳期間は解除
されたと判断する。
トラヒック集中によって発生した輻輳を回復するための
輻輳回復制御方法として、従来、John Ioannidis and S
teven M. Bellovin, "Implementing Pushback: Router-
Based Defense Against DDoSAttacks", Network and Di
stributed System Security Symposium, February 2002
に次のような方法が提案されている。ここでは、終端す
る特定のリンクへトラヒックが集中することによってパ
ケットの廃棄が比較的長時間継続すると、そのリンクを
終端するノードは輻輳状態が発生したと判断し、そのノ
ードはその原因となるトラヒックを特定して、それらに
対してレート制限をかける。ここでレート制限の対象と
なるトラヒックは、宛先IPアドレスもしくは宛先IPアド
レス接頭辞に基づいて特定する。レート制限は前述のト
ークンバケットシェイパーにおいて、バッファのサイズ
を0としたものである。すなわち到着したパケットはそ
の場でパケットサイズ分のトークン量を得られない場合
は直ちに廃棄される。
るレート制限においてパケットの廃棄が継続する場合
は、レート制限の対象となるトラヒックを上流からその
ノードへ転送してくる各隣接ノードに対してPushbackと
呼ばれるレート制限を要求するための制御パケットを転
送する。その際、Pushbackを転送するノードは、隣接す
る各上流ノードが用いる送信許容レートの上限を決定し
て書き込んでおく。Pushbackを受け取った上流の各隣接
ノードは、指定されたトラヒックに対して指定された送
信許容レートにそったレート制限をかける。こうした動
作はさらに上流のノードに向かって繰り返される。
除されるいわゆるソフトステートの機構を採用してい
る。すなわち、輻輳状態を検出したノードEは、輻輳回
復制御を継続したい場合は、tよりも短い一定時間ごと
にPushbackメッセージを上流に転送して、レート制限要
求のリフレッシュを行なう。このために、別途、上流ノ
ードから、レート制限の対象となるトラヒックの経路上
で隣接する下流ノードに状態通知メッセージが送信さ
れ、これは最終的に最下流に位置するノードEまで転送
される。このメッセージの中には、状態通知メッセージ
を生成して転送するノードにその上流の隣接ノードか
ら、レート制限の対象となるトラヒックが到着するレー
トの総和が書かれている。よって、状態通知メッセージ
が最下流のノードEに到着するときは、レート制限の対
象となるトラヒックの到着レートの網内における総和が
書かれている。ノードEはその総和が必要以上に下がっ
たと判断すると、Pushbackメッセージを上流に転送しな
くなり、t時間以上送信しないと上流の各ノードにおけ
るレート制限は行なわれなくなる。
の帯域制御方法では制御パケットが紛失すると帯域制御
が適切に動作しないことである。その理由は以下によ
る。すなわち、入力側から送信した順方向制御パケット
が廃棄された場合、出力側では蓄積量を更新することが
出来なくなり、輻輳期間に入ったことを判断できず、ネ
ットワーク内に輻輳が発生した場合でも入力側の送信許
容レートrを削減させることができない。また、出力側
から送信した逆方向制御パケットが紛失しても、同じく
rを削減させることができない。そして、さらに悪いこ
とには、入力側は負のフィードバックを意味する逆方向
制御パケットを受信できないと、ネットワークが輻輳状
態にあるにもかかわらず送信許容レートrを増加させる
ことになってしまうからである。
いて、ダイナミックルーチングプロトコル等により、現
在の経路が伝搬遅延のより大きな経路に切り替わった場
合、輻輳期間が依然として継続していると誤った判断を
下し、輻輳期間の解除を行なうことができなくなってし
まう。こうなると輻輳期間に入っていないのにもかかわ
らず、送信許容レートを増加させることはできなくなっ
てしまう。その理由は、出力側での輻輳期間の解除は、
一方向転送遅延を測定してこれが最小遅延との差が一定
値以下の場合に判断するからである。
対する輻輳回復制御方法は、輻輳防止機構が組み込まれ
ていないプロトコルによるトラヒックが引き起こす輻輳
を防止することは出来ないということである。その理由
は輻輳状態を検出してからレート規制を実行するからで
ある。
ーク内で行なう場合は、コストがその分増えるという問
題がでてくる。その理由は、輻輳防止制御のためには、
輻輳回復制御とは別の、例えば従来の帯域制御方法のよ
うなものを実施する必要があるからである。
も、経路の変更にも耐性のある帯域制御方法を提供する
ことにある。また、輻輳防止機構がないプロトコルによ
るトラヒックの流入で発生する輻輳の回避に対しても、
特定個所にトラヒックが集中することで発生した輻輳の
回復に対しても、共通の帯域制御方法に基づいてコスト
効率良く対処できる輻輳制御方法を提供することであ
る。
は、パケットスイッチを行なうノード、端末およびリン
クを構成要素とするネットワーク中の任意のある構成要
素Aから別の任意のある構成要素Bへ転送されるトラヒッ
クに対して帯域を割り当てる帯域制御方法において、前
記構成要素Aを入力側とし、前記構成要素Bを出力側と
し、前記入力側は前記出力側に制御パケットを送信する
際、前記制御パケットの送信時刻と、前記送信時刻まで
に入力側から出力側に送信したデータパケットの累積量
とに関する情報を前記制御パケットに書き込み、前記出
力側は前記入力側より前記制御パケットを受信したら、
これに前記制御パケットの受信時刻と、前記受信時刻ま
でに受信したデータパケットの累積量とに関する情報を
書き加えて前記入力側に返送し、前記入力側は、前記出
力側より、今回新たに受信した制御パケットと前回受信
した制御パケットとにそれぞれ含まれる情報に基づい
て、前記出力側に送信すべきデータパケットの送信許容
レートを決定することを特徴とする。
は出力側より新たに制御パケットを受信すると、今回新
たに受信した前記制御パケットと前回受信した制御パケ
ットとにそれぞれ含まれる制御パケットの送信時刻と前
記送信時刻までに入力側が送信したデータパケットの累
積量とから送信レートを算出すると共に、次に今回新た
に受信した制御パケットと前回受信した制御パケットと
にそれぞれ含まれる制御パケットの受信時刻と前記受信
時刻までに出力側が受信したデータパケットの累積量と
から受信レートを算出し、今回算出した前記送信レート
および前記受信レートと、前回制御パケットを受信した
際に算出しておいた送信レートおよび受信レートとから
送信レートの変化分および受信レートの変化分をそれぞ
れ算出し、前記受信レートの変化分が、前記送信レート
の変化分とある一定値との積より大きい場合は、入力側
の送信許容レートを増加し、そうでない場合は前記送信
許容レートを削減するようにしてよい。
御の入力側および出力側はネットワークの任意の構成要
素としてよい。すなわち、入力側および出力側がそれぞ
れノードであっても、端末であっても、リンクであって
もよいし、入力側がノードで出力側がリンクまたは端
末、入力側が端末で出力側がリンクまたはノード、入力
側がリンクで出力側がノードまたは端末であってもよ
い。
ワークにおけるある構成要素Cが終端するリンクDの輻輳
状態を検出し、それに対する帯域制御要求を前記構成要
素Cとは別の一つもしくは複数の構成要素に通知するこ
とを帯域制御の開始の契機とし、前記構成要素Cとは別
の一つもしくは複数の前記構成要素のおのおのを前記帯
域制御の入力側とし、前記構成要素Cを前記帯域制御の
出力側とし、前記入力側から前記リンクD上に転送され
るトラヒックに対して上述した帯域制御方法を実施する
ことで前記リンクDに検出された輻輳状態の回復を図る
ことを特徴とする。
御の解除は少なくとも前記入力側での輻輳状況に基づい
て決定されるようにしてよい。
御の入力側および出力側はネットワークの任意の構成要
素としてよい。すなわち、入力側および出力側がそれぞ
れノードであっても、端末であっても、リンクであって
もよいし、入力側がノードで出力側がリンクまたは端
末、入力側が端末で出力側がリンクまたはノード、入力
側がリンクで出力側がノードまたは端末であってもよ
い。
方法においては、帯域制御の対象として入力側から出力
側に流れるトラヒックは、ノードもしくはリンクもしく
は端末のみならず、さらに加えてトランスポートレイヤ
のプロトコルもしくはアプリケーションレイヤのプロト
コルに基づいて特定されるものであってよい。
パケットを送信する毎にそれまでの送信データ累積量を
更新する手段と、一定時間毎に送信時刻と前記送信デー
タ累積量とに関する情報を含む制御パケットを帯域制御
の出力側に送信する手段と、前記制御パケットを受信し
た前記出力側が前記制御パケットの受信時刻とそれまで
の受信データ累積量とに関する情報を前記制御パケット
に書き加えて返送してきたときに前記制御パケットを受
信する手段と、前記受信した制御パケットと前回受信し
た制御パケットとにそれぞれ含まれる情報に基づいて、
前記出力側に送信すべきデータパケットの送信許容レー
トを決定する手段とを備えたノード装置または端末装置
であって、前記出力側と協調して当該ネットワーク構成
装置から前記出力側へ転送されるトラフィックに対して
帯域を割り当てる帯域制御を実行する。
て、前記送信許容レートを決定する手段は、今回新たに
受信した前記制御パケットと前回受信した制御パケット
とにそれぞれ含まれる制御パケットの送信時刻と前記送
信時刻までに入力側が送信したデータパケットの累積量
とから送信レートを算出する手段と、今回新たに受信し
た制御パケットと前回受信した制御パケットとにそれぞ
れ含まれる制御パケットの受信時刻と前記受信時刻まで
に出力側が受信したデータパケットの累積量とから受信
レートを算出する手段と、今回算出した前記送信レート
および前記受信レートと、前回制御パケットを受信した
際に算出しておいた送信レートおよび受信レートとから
送信レートの変化分および受信レートの変化分をそれぞ
れ算出する手段と、前記受信レートの変化分が、前記送
信レートの変化分とある一定値との積より大きい場合
は、入力側の送信許容レートを増加し、そうでない場合
は前記送信許容レートを削減する手段とを備えるように
してよい。
ータパケットを受信する毎にそれまでの受信データ累積
量を更新する手段と、帯域制御の入力側から送信時刻と
それまでの送信データ累積量とに関する情報を含む制御
パケットを受信する手段と、受信した前記制御パケット
に前記制御パケットの受信時刻と前記受信データ累積量
とに関する情報を書き加えて前記入力側に返送する手段
とを備えたノード装置または端末装置であって、前記入
力側と協調して当該ネットワーク構成装置へ前記出力側
から転送されてくるトラフィックに対して帯域を割り当
てる帯域制御を実行する。
を示したものである。入力側が出力側に送信した制御パ
ケットを出力側が受信した場合は、出力側はそれを必ず
入力側に返信する。そして、入力側では制御パケットを
受信したときにのみ、それに含まれる情報に基づいて送
信許容レートを決定する。よって、制御パケットが入力
側から出力側へ転送時に、もしくは出力側から入力側に
返送時にそれぞれ廃棄されても悪影響を及ぼすような特
定の動作を起すことがない。
ートに対する出力レートの変化を例示したものである。
入力レートの増加にともなって出力レートも増加する
が、入力レートが十分大きくなると、パケットの遅延や
廃棄により出力レートは飽和し一定になる。これが輻輳
状態である。よって、入力レートの変化に対する出力レ
ートの変化の割合、すなわち微分値に相当するものが計
算できれば、その値が一定値以上である場合は送信許容
レートを増やし、0に近づいたらそれを減らすというよ
うな制御を行なえば、送信量を出力レートが飽和し始め
る値一杯に近づけることが可能となる。よって、この帯
域制御は、出力レートが飽和している輻輳状態から開始
すれば輻輳回復制御となり、出力レートが飽和していな
い非輻輳状態から開始すれば輻輳防止制御となる。
て図面を参照して詳細に説明する。図2は帯域制御が実
施されるネットワークの物理構成を示したものである。
ノード101〜106、リンク2、および端末3から構
成される。端末3を収容するノードを特にエッジノード
呼び、ノード101〜104がこれに相当する。エッジ
ノードのみを接続するノードを特にコアノードと呼び、
ノード105と106がこれに相当する。以下、ノード
を特に限定しない場合、参照符号1を付けてノード1と
称する。
対象となるトラヒックの流れを示したものである。ここ
では、帯域制御が、任意の1組のエッジノード間で両方
向に流れるトラヒックに対して実施される。これによ
り、図2で示すネットワーク内の任意のリンク2におい
て発生する輻輳を回避することができる。
する。まず、概要について述べる。作用で説明したよう
に、送信許容レートを決定するためには、入力レートの
変化値および出力レートの変化値を計算する必要があ
る。そのために、入力側が出力側に入力レートを算出す
るための情報を含む制御パケットを送信すると、それに
対して、出力側は入力側に出力レートを算出するための
情報をさらに加えた制御パケットを返信する。そして入
力側は制御パケットを受信するごとに入力レートと出力
レートを算出し、またそれからそれぞれの変化分を計算
して、これに基づいて送信許容レートを更新する。
側は一定時間T毎に制御パケットを発生させ、現在送信
中のデータパケットがあればそれを妨げない範囲でなる
べく早く出力側に送信する。その際、制御パケットに
は、その送信時刻STと、それまでの送信したデータパケ
ットのサイズの累積量SBとを書き込んでおく。
と、さらにその受信時刻DTと、それまでに受信したデー
タパケットのサイズの累積量DBを書き加えて入力側に返
送する。よって、入力側に戻ってきた制御パケットに
は、SB、ST、DB、DTの4つの値が書き込まれている。こ
れにもとづき、入力側では以下のようにして入力レート
λおよび出力レートνを計算する。
変数にいれて保持し、制御パケットを受信するごとに更
新する。この変数は、前回制御パケットを受信したとき
の値を保持する変数は下付文字oldで、今回受信したと
きの値を保持する変数は下付文字newでそれぞれ区別す
る。今回制御パケットを受信したらその中の情報をそれ
ぞれSBnew、STnew 、DBnew、DTnewに保持する。次
に、これらと前回受信したときに保持した情報SBold、S
Told 、DBold、DToldとから、下記の式で今回の入力
レートλnew、および出力レートνnewを次式で算出して
保持する。 λnew←(SBnew-SBold)/(STnew-STold),νnew←(DBnew-DBold)/(DTnew-DTold) …(1)
信した制御パケットの間に送信もしくは受信したデータ
パケットのサイズの総和を送信間隔もしくは受信間隔で
それぞれ割って、送信レートおよび受信レートを算出す
る。次に、入力側が今回制御パケットを受信した時の入
力レートの変化値Δλ, および出力レートの変化値Δν
を、前回制御パケットを受信したときに算出して保持し
ておいた入力レートλ oldおよび出力レートνoldを用い
て次のように計算する。 Δλ=λnew-λold , Δν=νnew-νold …(2)
て、以下のようにして送信許容レートrを更新する。す
なわち入力レートの変化分に対する出力レートの変化分
の割合が一定値γ以上なら、rを一定値αだけ増やす。
さもなければrを一定値αだけ減らす。すなわち Δν>γ×Δλ ならば r←r+α、さもなければ、r←r-α …(3) ここで、レート変化分の割合であるΔν/Δλを計算し
ないのは、Δλ=0となる場合に計算不能となるからで
ある。
の算出に備えるために変数をつぎの様に更新しておく。 SBold←SBnew、STold←STnew、DBold←DBnew、DTold←DTnew、λold←λnew 、 νold←νnew …(4)
受信する制御パケットが関与する、帯域制御の対象とな
るトラヒックを識別できる必要がある。このため本実施
の形態では、入力トラヒック識別子および出力パケット
情報識別子と呼ばれるものを用いる。よって、制御パケ
ットは少なくとも次に示す情報の組み合わせを含む。
(入力トラヒック識別子、出力トラヒック識別子、送信
時刻、送信データ累積量、受信時刻、受信データ累積
量)
ットに乗せて運ばれる。その際、この制御パケットを識
別するためにあらかじめ割り当てられた特定のプロトコ
ル番号が用いられる。また、制御パケットを運ぶIPパケ
ット内のIPアドレスは、入力側および出力側のノードに
それぞれ割り振られたIPアドレスを用いる。
に、各エッジノード間に流れるトラヒックの全体に対し
て帯域制御を行なうので、入力/出力トラヒック識別子
はそれらのエッジノードを特定するもの、たとえばその
ノードに割り振られたIPアドレスを用いればよい。
表現できる量には一般に制限量Mがあり、これを超えた
場合はMを引いてM未満になった値を書き込む。よって、
制御パケットに書き込まれた今回のデータ累積量が前回
のデータ累積量より小さい場合は、(今回のデータ累積
量)-(前回のデータ蓄積量)+Mを、2つの連続した制
御パケットを受信した間に入力もしくは出力したデータ
パケットのサイズの総量とする。よって制限量Mは、制
御パケットの発生時間間隔T内に最大送信可能なデータ
パケットのサイズの総量よりも十分大きな値にする必要
がある。
制御パケット内で表現できる量にも制限量Qがあるの
で、データ累積量と同じくして、今回の時刻が前回の時
刻よりも小さい場合は、(今回の時刻)-(前回の時
刻)+Qを、隣接する2つの制御パケットの送信もしくは
受信間隔とする。よって、制限量Qは、制御パケットの
発生時間間隔Tに制御パケットが送信もしくは返信時に
連続して廃棄される個数の平均値aをかけたもの(T*a)よ
りも十分大きな値にする必要がある。
側における動作をフローチャートにまとめると図1のよ
うになる。
ローチャートである。データパケットを送信したら(ス
テップA1)、保持している送信データ累積量にそのパケ
ットのバイト長を加えて新たな送信データ累積量とする
(ステップA2)。
刻と送信データ累積量とに関する情報を含む制御パケッ
トを出力側に送信する(ステップB2)。
テップC1)、その中の情報を保持する(ステップC2)。
次に、今回制御パケットを受信して保持した制御パケッ
ト内の情報と前回制御パケット受信時に保持した制御パ
ケット内の情報とから、式(1)より今回の入力レート
と出力レートを計算して保持する(ステップC3)。次に
これらと、前回制御パケット受信時に算出して保持して
いた入力レートと出力レートから式(2)を用いて各レ
ートの変化分を計算し(ステップC4)、次にこれにもと
づいて送信許容レートを式(3)を用いて算出し(ステ
ップC5)、最後に式(4)に示すように新しい値を古い
値を表す変数に代入して次回の計算に備える(ステップC
6)。
ャートである。データパケットを受信したら(ステップ
D1)、保持している受信データ累積量にそのパケットの
サイズを加えて新たな受信データ累積量とする(ステッ
プD2)。制御パケットを受信したら(ステップE1)、制
御パケットの返信時刻(受信時刻)と、受信データ累積
量を書き込んで入力側に返送する(ステップE2)。
容レートrに最低保証値m、および最大許容値Mがある
場合を考える。特に最低保証値を設定するのは、帯域を
保証するトラヒックを収容する場合である。また、最大
許容値を設定するのは、入力側のリンクの最大速度に物
理的な限界があることを考慮する場合である。rがmとM
の間の範囲で変更されるようにするために、式(3)は
以下のように変更する。すなわち、 Δμ>γ×Δλ ならば r←min{r+α, M}、さもなければ r←max{r‐α, m} …(5)
て、入力/出力トラヒック識別子には、ノードを特定す
るものに加えて、トランスポートレイヤのプロトコルも
しくはアプリケーションレイヤのプロトコルを識別する
ものを加える。Internetworking with TCP/IP volume 1
Douglas E. Comer著 Prentice Hall刊にも解説されて
いるように、トランスポートレイヤのプロトコルはIPパ
ケットのヘッダーに含まれるプロトコル番号により識別
でき、また、アプリケーションレイヤのプロトコルは、
TCPもしくはUDPパケットのヘッダーに含まれるポート番
号により識別できる。 よって、入力/出力トラヒック
識別子は例えば、(入力/出力側ノードのIPアドレス、
プロトコル番号)、もしくは(入力/出力側ノードのIP
アドレス、ポート番号)の組み合わせで与える。これに
より、ある1組のノード間で特定のプロトコルを用いた
トラヒックに対して帯域制御を実施することができる。
例えば、輻輳防止機構のないUDPのトラヒックに対して
ネットワーク側で輻輳防止制御を行なう場合を考える。
エッジノード101からエッジノード104へのUDPの
トラヒックを識別するための入力/出力トラヒック識別
子は(ノード101のIPアドレス/ノード104のIPア
ドレス、UDPに関するポート番号)で与える。
の形態で述べた帯域制御の入力側も出力側も、いずれも
ノード1ではなく端末3となるものである。そして、帯
域制御の対象となるトラヒックを、入力側および出力側
の端末のみならず、輻輳制御機構のないストリーミング
プロトコルによって限定する。図4は端末304から、
端末301〜303にそれぞれ転送されるストリーミン
グプロトコルのトラヒックに対して帯域制御をかける場
合を示している。ここで、端末304はストリーミング
コンテンツのサーバーであり、端末301から303は
そのクライアントに相当する。例えば端末304から3
01に転送されるストリーミングトラヒックに実施され
る帯域制御における入力トラヒック識別子は(端末30
4のIPアドレス、ストリーミングプロトコルのサーバー
側に関するポート番号)の組み合わせで、出力トラヒッ
ク識別子は(端末301のIPアドレス、ストリーミング
プロトコルのクライアント側に関するポート番号)の組
み合わせでそれぞれ与える。
図面を用いて詳細に説明する。図2の物理構成をもつネ
ットワークにおいて、特にエッジノード104につなが
る特定の端末3にトラヒックが集中して輻輳が起こって
いる場合、帯域制御によってこれを回復することを考え
る。よって、帯域制御の対象となるトラヒックは、図5
に示すように、各エッジノード101〜103のそれぞ
れから、端末301を接続するリンク210に流れるこ
とになる。よって例えばノード101からリンク210
に転送されるトラヒックに対して実施される帯域制御に
おける入力トラヒック識別子はノード101に割り振ら
れたIPアドレスで、また出力トラヒック識別子はリンク
210に割り振られたIPアドレスであたえる。つまり、
本実施の形態では出力側はリンクである。
ンク210で輻輳を検知すると、それの識別子を書き込
んだ帯域制御要求パケットを他のエッジノード101〜
103に送信する。するとこれを契機に他の各エッジノ
ード101〜103のそれぞれからリンク210に流れ
るトラヒックに対して帯域制御が開始される。なお、各
帯域制御における出力データ累積量は、エッジノード1
04がリンク210上で端末301に向かって転送でき
たデータパケットのデータ蓄積量で測る。
ジノード101〜103のそれぞれにおいて図9に示す
トラヒックシェイパーでのバッファにおけるパケット廃
棄が少なくなったときに行なう。こうして入力側で帯域
制御の解除を判断できる理由は、帯域制御を行なうと、
輻輳状態がリンク210から、入力側である各エッジノ
ード101〜103のそれぞれに移行するからである。
力側での動作は、第1の実施の形態と同じなのでここで
は説明を省略する。
出力トラヒック識別子には、ノードもしくはリンクを特
定するものに加えて、トランスポートレイヤのプロトコ
ルもしくはアプリケーションレイヤのプロトコルを識別
するものを加える。これにより特定のプロトコルによる
トラヒックが特定のリンクに集中して発生している輻輳
状態を回復することが出来る。以下の説明は第1の実施
の形態における第2の変形例と同じなので省略する。
の形態において出力側がノード1ではなく端末3である
場合である。このとき、各ノード1を経由して端末3に
到着する大量のトラヒックを端末3が検出した場合、端
末3側でノード1に制御パケットを用いて適切なフィー
ドバックをかけることで、そうした大量のトラヒックの
到着を制限することが出来る。図6では、ノード101
〜103のそれぞれから端末304に転送されるトラヒ
ックの流れを示しており、それぞれの流れに対して帯域
制御をかける。その際、端末304において返送する制
御パケットに書き込む出力データ累積量は、端末304
が受信したデータ量ではなく実際に端末で処理もしくは
蓄積可能なデータ量で測る。また、例えばノード101
から端末304に転送されるトラヒックに実施される帯
域制御における入力トラヒック識別子はノード101の
IPアドレスで、出力トラヒック識別子は端末301のIP
アドレスでそれぞれ与える。
および出力側の組として、ノードとノード(第1の実施
の形態)、端末と端末(第2の実施の形態)、ノードと
リンク(第3の実施の形態)、ノードと端末(第4の実
施の形態)について例示したが、本発明は入力側および
出力側はネットワークの任意の構成要素とすることがで
きる。すなわち、入力側および出力側がそれぞれノード
であっても、端末であっても、リンクであってもよい
し、入力側がノードで出力側がリンクまたは端末、入力
側が端末で出力側がリンクまたはノード、入力側がリン
クで出力側がノードまたは端末であってもよい。
ても制御に悪影響を及ぼさないことである。その理由
は、帯域制御の入力側が出力側に送信し、それに対して
出力側が入力側に返信して、入力側で確実に受信できた
制御パケットに含まれる情報に基づいてのみ、入力側で
帯域制御を行なうからである。
側と出力側の間に流れるトラヒックの現在の経路がより
伝搬遅延の大きな経路に変更されても制御に支障がでな
いことである。また入力側もしくは出力側で制御パケッ
トを送信もしくは受信した時刻をはかる時計がずれてい
たとしても全く問題がないことである。その理由は、輻
輳の検出もしくは輻輳緩和の検出に入力側と出力側の間
で測ったパケット転送遅延を用いないからである。
スポートプロトコルもしくはアプリケーションプロトコ
ルに基づくトラヒックに対して、それらのプロトコルを
輻輳制御対応に変更することなく、端末側で輻輳防止制
御を行なうことが可能となる。その理由は、帯域制御の
入力側および出力側を端末とし、帯域制御の対象となる
トラヒックを端末だけではなく、さらにトランスポート
レイヤプロトコルもしくはアプリケーションレイヤプロ
トコルによって限定するからである。
中することで発生する輻輳の回復に対しても、輻輳制御
機構がないプロトコルによるトラヒックによりネットワ
ークに発生するかもしれない輻輳の防止と共通の帯域制
御方法をもちいて対処でき、輻輳防止と輻輳回復とに別
々の制御方法をとることでさらに余分に発生するコスト
をおさえることができることである。その理由は、作用
でも説明したように、本発明による帯域制御は、輻輳状
態から開始すれば輻輳回復制御となり、非輻輳状態から
開始すれば輻輳防止制御となるという性質を有している
からである。
発信源である端末を特定することなく、輻輳回復制御を
実行することができることである。その理由は帯域制御
の入力側をノード、出力側を端末とすることで、端末が
ノードに処理したデータ量に関する情報を制御パケット
にのせて通知するからである。
輳に反応して転送量を削減させないトラヒックが大量に
ネットワーク内に流入して引き起こされる輻輳を回避す
るための輻輳防止制御をネットワーク側で行なうことが
可能となる。またこれにより、TCPトラヒックのように
輻輳に反応するトラヒックがネットワークから締め出さ
れることを網側で防ぐことができることである。その理
由は、帯域制御の入力側および出力側をノードとし、帯
域制御の対象となるトラヒックを、ノード間もしくはリ
ンクだけではなく、さらに加えてトランスポートレイヤ
プロトコルもしくはアプリケーションレイヤプロトコル
によって限定するからである。
ラヒックが特定のリンクに集中して発生している輻輳状
態を回復することが出来ることである。その理由は帯域
制御の入力側をノード、出力側を輻輳状態にあるリンク
とし、帯域制御の対象となるトラヒックをノード間もし
くはリンクだけではなく、さらに加えてトランスポート
レイヤプロトコルもしくはアプリケーションレイヤプロ
トコルによって限定するからである。
動作を示すフローチャート(図1(A))および本発明の
第1の実施の形態における出力側での動作を示すフロー
チャート(図1(B))である。
なるネットワークの物理構成を示す図である。
対象となるトラヒックの流れを示す図である。
対象となるトラヒックの流れを示す図である。
対象となるトラヒックの流れを示す図である。
対象となるトラヒックの流れを示す図である。
やり取りを示すための図である。
である。
明するためのブロック図である。
Claims (17)
- 【請求項1】 パケットスイッチを行なうノード、端末
およびリンクを構成要素とするネットワーク中のある構
成要素Aから別のある構成要素Bへ転送されるトラヒック
に対して帯域を割り当てる帯域制御方法において、前記
構成要素Aを入力側とし、前記構成要素Bを出力側とし、
前記入力側は前記出力側に制御パケットを送信する際、
前記制御パケットの送信時刻と、前記送信時刻までに入
力側から出力側に送信したデータパケットの累積量とに
関する情報を前記制御パケットに書き込み、前記出力側
は前記入力側より前記制御パケットを受信したら、これ
に前記制御パケットの受信時刻と、前記受信時刻までに
受信したデータパケットの累積量とに関する情報を書き
加えて前記入力側に返送し、前記入力側は、前記出力側
より、今回新たに受信した制御パケットと前回受信した
制御パケットとにそれぞれ含まれる情報に基づいて、前
記出力側に送信すべきデータパケットの送信許容レート
を決定することを特徴とする帯域制御方法。 - 【請求項2】 入力側は出力側より新たに制御パケット
を受信すると、今回新たに受信した前記制御パケットと
前回受信した制御パケットとにそれぞれ含まれる制御パ
ケットの送信時刻と前記送信時刻までに入力側が送信し
たデータパケットの累積量とから送信レートを算出する
と共に、次に今回新たに受信した制御パケットと前回受
信した制御パケットとにそれぞれ含まれる制御パケット
の受信時刻と前記受信時刻までに出力側が受信したデー
タパケットの累積量とから受信レートを算出し、今回算
出した前記送信レートおよび前記受信レートと、前回制
御パケットを受信した際に算出しておいた送信レートお
よび受信レートとから送信レートの変化分および受信レ
ートの変化分をそれぞれ算出し、前記受信レートの変化
分が、前記送信レートの変化分とある一定値との積より
大きい場合は、入力側の送信許容レートを増加し、そう
でない場合は前記送信許容レートを削減することを特徴
とする請求項1記載の帯域制御方法。 - 【請求項3】 帯域制御の入力側および出力側がそれぞ
れノードであることを特徴とする請求項1または2記載
の帯域制御方法。 - 【請求項4】 帯域制御の入力側および出力側がそれぞ
れ端末であることを特徴とする請求項1または2記載の
帯域制御方法。 - 【請求項5】 帯域制御の入力側がノードであり、出力
側がリンクまたは端末であることを特徴とする請求項1
または2記載の帯域制御方法。 - 【請求項6】 帯域制御の入力側が端末であり、出力側
がリンクまたはノードであることを特徴とする請求項1
または2記載の帯域制御方法。 - 【請求項7】 帯域制御の入力側がリンクであり、出力
側がリンクまたはノードまたは端末であることを特徴と
する請求項1または2記載の帯域制御方法。 - 【請求項8】 帯域制御の対象として入力側から出力側
に流れるトラヒックは、ノードもしくはリンクもしくは
端末のみならず、さらに加えてトランスポートレイヤの
プロトコルもしくはアプリケーションレイヤのプロトコ
ルに基づいて特定されることを特徴とする請求項1乃至
7の何れか1項に記載の帯域制御方法。 - 【請求項9】 前記ネットワークにおけるある構成要素
Cが終端するリンクDの輻輳状態を検出し、それに対する
帯域制御要求を前記構成要素Cとは別の一つもしくは複
数の構成要素に通知することを帯域制御の開始の契機と
し、前記構成要素Cとは別の一つもしくは複数の前記構
成要素のおのおのを前記帯域制御の入力側とし、前記構
成要素Cを前記帯域制御の出力側とし、前記入力側から
前記リンクD上に転送されるトラヒックに対して請求項
1または請求項2に記載の帯域制御方法を実施すること
で前記リンクDに検出された輻輳状態の回復を図ること
を特徴とする輻輳制御方法。 - 【請求項10】 帯域制御の解除は少なくとも前記入力
側での輻輳状況に基づいて決定されることを特徴とする
請求項9記載の輻輳制御方法。 - 【請求項11】 帯域制御の入力側および出力側がそれ
ぞれノードであることを特徴とする請求項9または10
記載の輻輳制御方法。 - 【請求項12】 帯域制御の入力側および出力側がそれ
ぞれ端末であることを特徴とする請求項9または10記
載の輻輳制御方法。 - 【請求項13】 出力側である端末が制御パケットに書
き込むデータパケットの累積量は、端末が受信したデー
タ量ではなく端末が処理したデータ量に基づいて決定す
ることを特徴とする請求項12記載の輻輳制御方法。 - 【請求項14】 帯域制御の対象として入力側から出力
側に流れるトラヒックは、ノードもしくはリンクもしく
は端末のみならずトランスポートレイヤのプロトコルも
しくはアプリケーションレイヤのプロトコルに基づいて
特定されることを特徴とする請求項9乃至13の何れか
1項に記載の輻輳制御方法。 - 【請求項15】 データパケットを送信する毎にそれま
での送信データ累積量を更新する手段と、一定時間毎に
送信時刻と前記送信データ累積量とに関する情報を含む
制御パケットを帯域制御の出力側に送信する手段と、前
記制御パケットを受信した前記出力側が前記制御パケッ
トの受信時刻とそれまでの受信データ累積量とに関する
情報を前記制御パケットに書き加えて返送してきたとき
に前記制御パケットを受信する手段と、前記受信した制
御パケットと前回受信した制御パケットとにそれぞれ含
まれる情報に基づいて、前記出力側に送信すべきデータ
パケットの送信許容レートを決定する手段とを備えるこ
とを特徴とするネットワーク構成装置。 - 【請求項16】 前記送信許容レートを決定する手段
は、今回新たに受信した前記制御パケットと前回受信し
た制御パケットとにそれぞれ含まれる制御パケットの送
信時刻と前記送信時刻までに入力側が送信したデータパ
ケットの累積量とから送信レートを算出する手段と、今
回新たに受信した制御パケットと前回受信した制御パケ
ットとにそれぞれ含まれる制御パケットの受信時刻と前
記受信時刻までに出力側が受信したデータパケットの累
積量とから受信レートを算出する手段と、今回算出した
前記送信レートおよび前記受信レートと、前回制御パケ
ットを受信した際に算出しておいた送信レートおよび受
信レートとから送信レートの変化分および受信レートの
変化分をそれぞれ算出する手段と、前記受信レートの変
化分が、前記送信レートの変化分とある一定値との積よ
り大きい場合は、入力側の送信許容レートを増加し、そ
うでない場合は前記送信許容レートを削減する手段とを
備えることを特徴とする請求項15に記載のネットワー
ク構成装置。 - 【請求項17】 データパケットを受信する毎にそれま
での受信データ累積量を更新する手段と、帯域制御の入
力側から送信時刻とそれまでの送信データ累積量とに関
する情報を含む制御パケットを受信する手段と、受信し
た前記制御パケットに前記制御パケットの受信時刻と前
記受信データ累積量とに関する情報を書き加えて前記入
力側に返送する手段とを備えることを特徴とするネット
ワーク構成装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002120625A JP3862003B2 (ja) | 2002-04-23 | 2002-04-23 | 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002120625A JP3862003B2 (ja) | 2002-04-23 | 2002-04-23 | 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003318967A true JP2003318967A (ja) | 2003-11-07 |
JP3862003B2 JP3862003B2 (ja) | 2006-12-27 |
Family
ID=29536798
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002120625A Expired - Fee Related JP3862003B2 (ja) | 2002-04-23 | 2002-04-23 | 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3862003B2 (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005318578A (ja) * | 2004-04-29 | 2005-11-10 | Microsoft Corp | ネットワーク増幅攻撃の軽減 |
WO2006054442A1 (ja) * | 2004-11-17 | 2006-05-26 | Sharp Kabushiki Kaisha | 送信装置、受信装置及び通信システム |
JP2006262291A (ja) * | 2005-03-18 | 2006-09-28 | Fujitsu Ltd | 通信システム、通信カード及び通信方法 |
JP2008042879A (ja) * | 2006-07-08 | 2008-02-21 | Kddi R & D Laboratories Inc | パケットの遅延変動時間に基づいて輻輳パスを分類する輻輳パス分類方法、管理装置及びプログラム |
US8254252B2 (en) | 2009-01-27 | 2012-08-28 | Alaxala Networks Corporation | Bandwidth control apparatus |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2014233028A (ja) * | 2013-05-30 | 2014-12-11 | 富士通株式会社 | 通信制御装置、情報処理装置、記憶装置、通信制御方法、及び通信制御プログラム |
-
2002
- 2002-04-23 JP JP2002120625A patent/JP3862003B2/ja not_active Expired - Fee Related
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8387144B2 (en) | 2004-04-29 | 2013-02-26 | Microsoft Corporation | Network amplification attack mitigation |
JP2005318578A (ja) * | 2004-04-29 | 2005-11-10 | Microsoft Corp | ネットワーク増幅攻撃の軽減 |
US7966661B2 (en) | 2004-04-29 | 2011-06-21 | Microsoft Corporation | Network amplification attack mitigation |
KR101312905B1 (ko) | 2004-04-29 | 2013-09-30 | 마이크로소프트 코포레이션 | 네트워크 증폭 공격 완화 방법 |
WO2006054442A1 (ja) * | 2004-11-17 | 2006-05-26 | Sharp Kabushiki Kaisha | 送信装置、受信装置及び通信システム |
JPWO2006054442A1 (ja) * | 2004-11-17 | 2008-05-29 | シャープ株式会社 | 送信装置、受信装置及び通信システム |
CN101057439B (zh) * | 2004-11-17 | 2011-07-27 | 夏普株式会社 | 发送器 |
JP4838143B2 (ja) * | 2004-11-17 | 2011-12-14 | シャープ株式会社 | 送信装置 |
US8281356B2 (en) | 2004-11-17 | 2012-10-02 | Sharp Kabushiki Kaisha | Transmitter |
JP2006262291A (ja) * | 2005-03-18 | 2006-09-28 | Fujitsu Ltd | 通信システム、通信カード及び通信方法 |
JP4588503B2 (ja) * | 2005-03-18 | 2010-12-01 | 富士通株式会社 | 通信システム及び通信方法 |
JP2008042879A (ja) * | 2006-07-08 | 2008-02-21 | Kddi R & D Laboratories Inc | パケットの遅延変動時間に基づいて輻輳パスを分類する輻輳パス分類方法、管理装置及びプログラム |
US8254252B2 (en) | 2009-01-27 | 2012-08-28 | Alaxala Networks Corporation | Bandwidth control apparatus |
Also Published As
Publication number | Publication date |
---|---|
JP3862003B2 (ja) | 2006-12-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Dukkipati et al. | Processor sharing flows in the internet | |
JP4738594B2 (ja) | データフロー制御方法および装置 | |
JP4632874B2 (ja) | 通信端末 | |
US7643427B2 (en) | Multipath routing architecture for large data transfers | |
US6535482B1 (en) | Congestion notification from router | |
US6625118B1 (en) | Receiver based congestion control | |
US4616359A (en) | Adaptive preferential flow control for packet switching system | |
US7369498B1 (en) | Congestion control method for a packet-switched network | |
Mankin et al. | Gateway congestion control survey | |
US6072797A (en) | Methods, apparatus and computer program products for aggregated transmission groups in high speed networks | |
JP2008518552A (ja) | 粗細試験期間を使用したネットワーク・パケットの経験的スケジューリング法 | |
CN102356602B (zh) | 监视传输中分组以优化网络中的分组流量的***和方法 | |
KR20060100512A (ko) | 전송제어 프로토콜 기반의 네트워크에서 평균 대역폭 추정방법 및 시스템 | |
JP2007506364A (ja) | ネットワーク・パケットの経験的スケジュール設定方法 | |
EP0955749A1 (en) | Receiver based congestion control and congestion notification from router | |
US20120155268A1 (en) | Packet relay device | |
Man et al. | ImTCP: TCP with an inline measurement mechanism for available bandwidth | |
JP3862003B2 (ja) | 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 | |
KR100674329B1 (ko) | 전송 제어 프로토콜/인터넷 프로토콜 네트웍에서 라우터의폭주 제어방법 | |
Jasem et al. | Evaluation study for delay and link utilization with the new-additive increase multiplicative decrease congestion avoidance and control algorithm | |
Hagiwara et al. | Impact of round trip delay self-similarity on TCP performance | |
Pu et al. | Enhancements on router-assisted congestion control for wireless networks | |
Komatireddy et al. | Source-ordering for improved TCP performance over load-balanced optical burst-switched (OBS) networks | |
Ayar et al. | A transparent reordering robust TCP proxy to allow per-packet load balancing in core networks | |
WO2020173384A1 (zh) | 一种通信方法、装置及*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050318 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060901 |
|
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: 20060906 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060919 |
|
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: 20091006 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101006 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111006 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121006 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131006 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |