JP2007243308A - 通信品質制御方法および装置 - Google Patents
通信品質制御方法および装置 Download PDFInfo
- Publication number
- JP2007243308A JP2007243308A JP2006059498A JP2006059498A JP2007243308A JP 2007243308 A JP2007243308 A JP 2007243308A JP 2006059498 A JP2006059498 A JP 2006059498A JP 2006059498 A JP2006059498 A JP 2006059498A JP 2007243308 A JP2007243308 A JP 2007243308A
- Authority
- JP
- Japan
- Prior art keywords
- network
- quality
- quality assurance
- delay time
- cbs
- 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.)
- Pending
Links
Images
Landscapes
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】TCPのようなデータ転送量が動的に変化する通信プロトコルに対しても、ある時間内における転送データ量の保証を可能にする。
【解決手段】アプリケーションの送信するパケットの転送品質を保証するネットワークにおいて、Bandwidth Broker104は品質保証要求を受信し、品質保証要求に必要なネットワークリソースであるデータ転送速度CIRとバーストサイズCBSを算出し、CIRとCBSが確保可能か否かの判定を行い、可能であれば対象のフローが経由するエッジルータ102の設定を更新し、品質保証要求のレスポンスを要求元に送信し、品質保証されたフローは、Diffservネットワークで確保されたCIR、CBSのトラフィック規定の範囲であれば、パケットの破棄は生じず、規定を超えたパケットについてはエッジルータにおいて破棄される。
【選択図】図1
【解決手段】アプリケーションの送信するパケットの転送品質を保証するネットワークにおいて、Bandwidth Broker104は品質保証要求を受信し、品質保証要求に必要なネットワークリソースであるデータ転送速度CIRとバーストサイズCBSを算出し、CIRとCBSが確保可能か否かの判定を行い、可能であれば対象のフローが経由するエッジルータ102の設定を更新し、品質保証要求のレスポンスを要求元に送信し、品質保証されたフローは、Diffservネットワークで確保されたCIR、CBSのトラフィック規定の範囲であれば、パケットの破棄は生じず、規定を超えたパケットについてはエッジルータにおいて破棄される。
【選択図】図1
Description
本発明は、通信ネットワークにおけるルータのようなパケット中継装置の品質制御技術に関し、特にTCPのようなデータ転送量が動的に変化する通信プロトコルに対して、ある時間内における転送データ量を保証することができる通信品質制御方法および装置に関する。
近年のインターネットに代表される通信ネットワークの発展に伴って、音声や映像をIPネットワーク上で転送するIP電話やテレビ会議システムのようなアプリケーションが利用されるようになってきている。このようなアプリケーションは、パケットのロスや遅延の影響によって音声品質、映像品質が劣化するため、IPネットワーク上で通信品質の保証が必要である。通信品質の保証技術としては、品質制御を行うDiffserv(Differentated Services)と帯域管理を行うBandwidth Brokerを組み合わせた方式(以下、Bandwidth Broker品質保証方式)がIPネットワーク上の品質保証技術の主流となっており、通信品質としてデータ転送速度とバースト量の保証を行っている。
品質保証の仕組みについては、特開2004−320489(特許文献1参照)に記載の『ネットワークの品質制御方法』がある。これは、IPの経路制御プロトコルを用いて、バースト特性と統計多重効果の影響を考慮した受付制御を行うもので、利用者がサービス要求を行う際に、サービス要求内容とともに、長時間平均レート、瞬最大レート、バーストパラメータを帯域管理サーバに通知すると、帯域管理サーバは、提供されるアプリケーションのストリームが経由するリンクを特定し、通知されたバーストパラメータを用いて特定されたリンクについてパケットロス率を算出し、算出されたロス率と所定の基準値を比較して、ロス率が基準値以下の場合には当該サービス要求を許可する方法である。
また、特開2005−73106(特許文献2参照)に記載の『QoS制御システムおよびQoS制御方法』は、IPネットワーク上でセッション制御によるリソース確保型の高品質な通信サービスをスケーラブルで、リソース確保にかかる遅延を最小にしたもので、ユーザ端末Aからのセッション確立要求メッセージとユーザ端末Bからのセッション確立応答メッセージを受信して、ユーザ端末A,Bのアドレス情報と確保するリソース情報とをリソース管理部に通知するセッション制御部と、通知された情報に基づき、リソース予約の可否を判定し、判定結果をセッション制御部に通知するリソース管理部とを具備している。
また、特開2005−12655(特許文献3参照)に記載の『SIPセッション制御によるCDNにおけるQoS保証方法とQoS保証システムおよび端末装置とコンテンツ配信サブシステムとSIPセッション制御サブシステムならびにプログラム』がある。
これは、汎用性と経済性の高いQoS保証を行うストリーミングコンテンツ等の配信システムであって、端末がサブシステムにセッションの確立を要求すると、サブシステムはコンテンツ配信サブシステムから当該コンテンツの視聴に必要な帯域の情報を取得し、帯域制御サブシステムに当該帯域情報に含まれる帯域値の帯域予約の要求を行い、帯域制御サブシステムで確保された帯域でコンテンツ配信サブシステムから端末装置に当該コンテンツを送信している。
これは、汎用性と経済性の高いQoS保証を行うストリーミングコンテンツ等の配信システムであって、端末がサブシステムにセッションの確立を要求すると、サブシステムはコンテンツ配信サブシステムから当該コンテンツの視聴に必要な帯域の情報を取得し、帯域制御サブシステムに当該帯域情報に含まれる帯域値の帯域予約の要求を行い、帯域制御サブシステムで確保された帯域でコンテンツ配信サブシステムから端末装置に当該コンテンツを送信している。
前述のBandwidth Broker品質保証方式において、音声や映像のようなある一定のパターンでデータを転送するアプリケーションについては、音声品質や映像品質を保証することが可能である。一方、TCPのようなデータ通信においても通信品質を保証することで、TCPスループットの向上や保証が考えられるが、TCPのようなデータ転送量が動的に変化するような通信では、通信プロトコルのレート制御方式に適合した通信品質保証を行わなければ、スループットの保証を行うことは困難である。
また、通信品質の保証を行う場合、通常は保証するフローに対してネットワーク側でデータ転送速度とバーストサイズの上限値が制限されるため、この2つのパラメーターの設計値が悪い場合には、通信品質の保証を行わない場合と比較して、スループットが低下する可能性がある。
また、通信品質の保証を行う場合、通常は保証するフローに対してネットワーク側でデータ転送速度とバーストサイズの上限値が制限されるため、この2つのパラメーターの設計値が悪い場合には、通信品質の保証を行わない場合と比較して、スループットが低下する可能性がある。
(目的)
本発明の目的は、前記問題点を解消し、TCPのようなデータ転送量が動的に変化する通信プロトコルに対しても、ある時間内における転送データ量を保証することが可能な通信品質制御方法および装置を提供することにある。
本発明の目的は、前記問題点を解消し、TCPのようなデータ転送量が動的に変化する通信プロトコルに対しても、ある時間内における転送データ量を保証することが可能な通信品質制御方法および装置を提供することにある。
本発明は、アプリケーションの送信するパケットの転送品質を保証するネットワークにおいて、Bandwidth Brokerは品質保証要求を受信し、品質保証要求に必要なネットワークリソースであるデータ転送速度CIRとバーストサイズCBSを算出し、CIRとCBSが確保可能か否かの判定を行い、可能であれば対象のフローが経由するエッジルータの設定を更新し、品質保証要求のレスポンスを送信し、品質保証されたフローは、Diffservネットワークで確保されたCIR、CBSのトラフィック規定の範囲であれば、パケットの破棄は生じず、規定を超えたパケットについてはエッジルータにおいて破棄される。
本発明によるポリサーの算出方法は、アプリケーションの送信するパケットの転送品質を保証するネットワークにおいて、品質保証要求を処理する方法であって、フローの品質保証要求に対して、ネットワークのエッジルータで保証するべき保証品質値を、フローで用いられるプロトコル情報と、ネットワーク内の最大パケット往復遅延時間と、フローの要求するスループット値から算出する。
本発明によるキュー長の算出方法は、上記ポリサーの算出方法により算出されたフローの品質保証値からネットワークのエッジルータで必要な出力キューの長さを算出する。
本発明による往復遅延時間RTTの算出方法は、上記品質保証値の算出に必要なコンピュータ間のパケット往復遅延時間の情報を、1)ネットワーク設計時に任意のコンピュータ間の最大往復遅延時間を決定する方法、2)通信を行う前にコンピュータ間で往復遅延時間の測定を行う方法、3)ネットワークをいくつかのエリアに分割して管理し、エリア間の最大往復遅延時間をネットワーク設計時に決めるか、定期的な測定によりエリア間の最大往復遅延時間の情報を取得する方法、4)エッジルータもしくはコンピュータが定期的に他のすべてのコンピュータ・エッジルータと遅延時間の測定を行う方法、5)通信時に、データパケットの送信時刻とそれに対応するACKパケットの受信時刻からコンピュータ間の遅延時間を測定する方法、のいずれかによって取得する。
本発明によれば、TCPのようなデータ転送量が動的に変化する通信プロトコルに対して、ある時間内における転送データ量を保証することが可能である。
以下、本発明の原理および実施例を、図面により詳細に説明する。
(原理)
(保証品質値の決定)
Bandwidth Broker品質保証方式は、TCPのようにIPアドレスとポート番号によって特定できるようなフローに対して、データ転送速度CIRとバーストサイズCBSで規定されるネットワークにおける転送品質を保証する仕組みを提供するものである。
本発明は、Bandwidth Broker品質保証方式において、TCPのような転送データ量が動的に変化するプロトコルのスループットを保証するために、データ転送速度CIR、バーストサイズCBSの品質保証値を算出するものである。
以下、その算出手順について説明する。TCPの輻輳回避状態における平均スループットXは、最大送信パケット数W、往復遅延時間RTT、ペイロード長SZから算出することができ、下記(式1)で表わされる。
X=f(W,SZ,RTT) ・・・・・・・・・・・(式1)
(原理)
(保証品質値の決定)
Bandwidth Broker品質保証方式は、TCPのようにIPアドレスとポート番号によって特定できるようなフローに対して、データ転送速度CIRとバーストサイズCBSで規定されるネットワークにおける転送品質を保証する仕組みを提供するものである。
本発明は、Bandwidth Broker品質保証方式において、TCPのような転送データ量が動的に変化するプロトコルのスループットを保証するために、データ転送速度CIR、バーストサイズCBSの品質保証値を算出するものである。
以下、その算出手順について説明する。TCPの輻輳回避状態における平均スループットXは、最大送信パケット数W、往復遅延時間RTT、ペイロード長SZから算出することができ、下記(式1)で表わされる。
X=f(W,SZ,RTT) ・・・・・・・・・・・(式1)
Bandwidth Broker品質保証方式で管理されたネットワークでは、品質保証されるフローはデータ転送速度CIR、バーストサイズCBSのパラメータによってネットワークへの流入量が制限されるため、送信パケット数Wで周期的にパケット廃棄が起こる。このため、最大送信パケット数Wから往復遅延時間RTTにおける平均ウィンドウサイズWが求まり、これにペイロード長SZを掛けることで、単位時間当たりのバイト数である平均スループットが求まる。例えば、TCPNewRenoの場合、スロースタート後の輻輳回避状態において、ホスト間の往復遅延時間(RTT)毎に送信パケット数を1増やし、パケットロスが起きたとき送信パケット数を半分にするというレート制御方式であるため(後述の図5参照)、送信パケット数がWのときにネットワーク上でパケット廃棄が起きる場合、スループット関数fは下記(式2)のように表される。
3 SZ
f(W,SZ,RTT)=━━W・━━ ・・・・・・・(式2)
4 RTT
(式1)・(式2)より、スループットXを満たすための送信パケット数Wは、下記(式3)のように求められる。
f(W,SZ,RTT)=━━W・━━ ・・・・・・・(式2)
4 RTT
(式1)・(式2)より、スループットXを満たすための送信パケット数Wは、下記(式3)のように求められる。
4 RTT
W=━━X・━━━ ・・・・・・・・・・・・・・・・・(式3)
3 SZ
TCPはRTT毎に送信可能なパケット数をバースト的に送信するため、(式3)で求めた送信パケット数Wがネットワークで保証するべきバーストサイズCBSとなる。(式3)のバーストサイズCBSでは、TCPペイロード長SZでバースト量を計算しているが、IPパケット長でバースト量を計測するエッジルータでは、SZをIPパケット長の値で計算する必要がある(後述の図6参照)。
CBS=W・SZ ・・・・・・・・・・・・・・・・(式4)
W=━━X・━━━ ・・・・・・・・・・・・・・・・・(式3)
3 SZ
TCPはRTT毎に送信可能なパケット数をバースト的に送信するため、(式3)で求めた送信パケット数Wがネットワークで保証するべきバーストサイズCBSとなる。(式3)のバーストサイズCBSでは、TCPペイロード長SZでバースト量を計算しているが、IPパケット長でバースト量を計測するエッジルータでは、SZをIPパケット長の値で計算する必要がある(後述の図6参照)。
CBS=W・SZ ・・・・・・・・・・・・・・・・(式4)
そして、送信パケット数WのときがRTTの時間内で最も送信データ量が多くなるときであり、このときの送信データ速度(CBS/RTT)がネットワークで保証するべき転送速度CIRとなる。
CBS
CIR=━━━ ・・・・・・・・・・・・・・・・・・(式5)
RTT
CBS
CIR=━━━ ・・・・・・・・・・・・・・・・・・(式5)
RTT
(キュー長の決定)
品質保証された各フローが流入量制御後に同一の出力キューに格納される場合、出力キューにおいてキュー溢れが起きないようにする必要がある。品質保証された各フローiは、最大CBSiのバースト的なパケットを送信するため、各フローのバーストが重なった場合でもキュー溢れを起こさないように、出力キューのサイズLを各フローのバーストサイズの合計値にする必要がある。
n
L=ΣCBSi ・・・・・・・・・・・・・・・・・・(式6)
i=1
品質保証された各フローが流入量制御後に同一の出力キューに格納される場合、出力キューにおいてキュー溢れが起きないようにする必要がある。品質保証された各フローiは、最大CBSiのバースト的なパケットを送信するため、各フローのバーストが重なった場合でもキュー溢れを起こさないように、出力キューのサイズLを各フローのバーストサイズの合計値にする必要がある。
n
L=ΣCBSi ・・・・・・・・・・・・・・・・・・(式6)
i=1
(RTTの決定)
数式1〜数式5にはホスト間の往復遅延時間であるRTTが含まれている。(式1)で表わされるように、TCPのスループットはRTTによって変化するため、本発明では、ホスト間の最大往復遅延時間の値を以下の方法によって通信前に取得する。
1)ネットワーク設計時に任意のコンピュータ間の最大往復遅延時間が決められている。
2)通信を行うコンピュータ間で往復遅延時間の測定を行い、品質保証要求に往復遅延時間の情報を付加して、Bandwidth Brokerに送信する。
3)Bandwidth Brokerがネットワークを管理上いくつかのエリアに分割して管理し、エリア間の最大往復遅延時間がネットワーク設計時に決められているか、定期的な測定によりエリア間の最大往復遅延時間の情報を持っている。そして、品質保証要求の受信時に、品質保証を行うコンピュータが属する2つのエリアを管理情報から特定し、往復遅延時間の情報を取得する。
4)エッジルータもしくはコンピュータが定期的に他のコンピュータ・エッジルータと遅延時間の測定を行い、Bandwidth Brokerが測定データの情報を持っている。そして、品質保証要求の受信時に、品質保証を行うコンピュータ間の往復遅延時間の測定値を取得する。
5)通信時に、データパケットの送信時刻とそれに対応するACKパケットの受信時刻からコンピュータ間の遅延時間を測定する。
数式1〜数式5にはホスト間の往復遅延時間であるRTTが含まれている。(式1)で表わされるように、TCPのスループットはRTTによって変化するため、本発明では、ホスト間の最大往復遅延時間の値を以下の方法によって通信前に取得する。
1)ネットワーク設計時に任意のコンピュータ間の最大往復遅延時間が決められている。
2)通信を行うコンピュータ間で往復遅延時間の測定を行い、品質保証要求に往復遅延時間の情報を付加して、Bandwidth Brokerに送信する。
3)Bandwidth Brokerがネットワークを管理上いくつかのエリアに分割して管理し、エリア間の最大往復遅延時間がネットワーク設計時に決められているか、定期的な測定によりエリア間の最大往復遅延時間の情報を持っている。そして、品質保証要求の受信時に、品質保証を行うコンピュータが属する2つのエリアを管理情報から特定し、往復遅延時間の情報を取得する。
4)エッジルータもしくはコンピュータが定期的に他のコンピュータ・エッジルータと遅延時間の測定を行い、Bandwidth Brokerが測定データの情報を持っている。そして、品質保証要求の受信時に、品質保証を行うコンピュータ間の往復遅延時間の測定値を取得する。
5)通信時に、データパケットの送信時刻とそれに対応するACKパケットの受信時刻からコンピュータ間の遅延時間を測定する。
品質保証通信を行うホスト間のRTTが最大往復遅延時間の値よりも小さい場合には、目標スループットXよりも実際のTCPスループットは高くなる。しかし、転送速度CIRより速い送信速度ではパケット廃棄が起こるため、実際のTCPスループットはX以上、CIR以下の範囲となる。
(実施の形態)
(原理動作)
図1は、本発明で想定するBandwidth Broker品質保証方式のネットワークの構成図である。
端末のコンピュータ101−A,101−Bは、アクセス回線等を通してDiffservネットワークのエッジルータ102−Aに接続され、Diffservネットワーク内は、コアルータ103−Aおよび通信相手の接続されているエッジルータ102−Bをを経由して、通信相手の端末コンピュータ101−Cとの間でデータの送受信を行う。
Diffservネットワーク内では、Bandwidth Broker104が、各エッジルータ102−A,102−Bを制御する。
データはパケットに分割されてネットワーク上を転送される。
(原理動作)
図1は、本発明で想定するBandwidth Broker品質保証方式のネットワークの構成図である。
端末のコンピュータ101−A,101−Bは、アクセス回線等を通してDiffservネットワークのエッジルータ102−Aに接続され、Diffservネットワーク内は、コアルータ103−Aおよび通信相手の接続されているエッジルータ102−Bをを経由して、通信相手の端末コンピュータ101−Cとの間でデータの送受信を行う。
Diffservネットワーク内では、Bandwidth Broker104が、各エッジルータ102−A,102−Bを制御する。
データはパケットに分割されてネットワーク上を転送される。
図2は、本発明の一実施例に係るBandwidth Brokerとエッジルータのブロック構成図である。
Bandwidth Broker品質保証方式では、通信品質を保証するフローは、フローの通信前、もしくは通信中にユーザの申告やフローの自動検出等により識別され、送信元端末コンピュータ101−A,Bや他の装置からBandwidth Broker1に品質保証の要求が送られる。Bandwidth Broker1は、品質保証要求を品質保証要求受付部2でこれらの要求を受信し、品質保証要求に必要なネットワークリソースを保証品質決定部3で算出する。
Bandwidth Broker品質保証方式では、通信品質を保証するフローは、フローの通信前、もしくは通信中にユーザの申告やフローの自動検出等により識別され、送信元端末コンピュータ101−A,Bや他の装置からBandwidth Broker1に品質保証の要求が送られる。Bandwidth Broker1は、品質保証要求を品質保証要求受付部2でこれらの要求を受信し、品質保証要求に必要なネットワークリソースを保証品質決定部3で算出する。
ネットワークリソースとは、データ転送速度CIRとバーストサイズCBSのことである。算出されたCIRとCBSが確保可能か否かをネットワークリソース管理部4で判定し、可能であれば対象のフローが経由するエッジルータ5の設定を更新し、品質保証要求受付部2が品質保証要求のレスポンスを送信する。品質保証されたフローは、Diffservネットワークで確保されたデータ転送速度CIR、バーストサイズCBSのトラヒット規定の範囲であれば、パケットの廃棄は生じないことが保証される。CIR、CBSの規定を超えたパケットについては、送信元コンピュータが接続されているエッジルータ5において廃棄される。
このように、図2に示すBandwidth Broker1は、送信元コンピュータや他の装置から品質保証の要求が送られると、該品質保証要求を受信するとともに、品質保証を行った後に、品質保証要求の発信元に品質保証を行ったことを通知する品質保証要求受付部2と、
ネットワークのトポロジとリソースの情報が格納されたネットワークトポロジ情報(ファイル)7の情報とを比較することにより、算出されたCBS、CIR、キュー長の値をネットワークの経路上で前記CBS、CIR、キュー長のリソースが確保可能か否かの判定を行い、保証品質を決定する保証品質決定部3と、リソース確保が可能であると判定された場合、エッジルータを設定し、要求のあったフローを送受信アドレスから識別するように登録し、前記登録されたフローに対してCIR,CBSを保証するように設定を行うネットワークリソース管理部4と、品質保証を行ったフローを登録する品質保証フロー情報(ファイル)6とを設けている。
ネットワークのトポロジとリソースの情報が格納されたネットワークトポロジ情報(ファイル)7の情報とを比較することにより、算出されたCBS、CIR、キュー長の値をネットワークの経路上で前記CBS、CIR、キュー長のリソースが確保可能か否かの判定を行い、保証品質を決定する保証品質決定部3と、リソース確保が可能であると判定された場合、エッジルータを設定し、要求のあったフローを送受信アドレスから識別するように登録し、前記登録されたフローに対してCIR,CBSを保証するように設定を行うネットワークリソース管理部4と、品質保証を行ったフローを登録する品質保証フロー情報(ファイル)6とを設けている。
(RTT決定の動作)
図3は、図2における保証品質決定部のブロック構成図である。
保証品質決定部3は、最大往復遅延時間31,プロトコル情報32,および最大パケット長33の各ファイルと、それらのファイルの内容を参照することにより、外部から流入した流入量を決定する流入量決定部30と、流入量決定部30からの出力を受け取り、そのキュー長を決定するキュー長決定部34とから構成される。
保証品質決定部は、ホスト間の最大往復遅延時間の値を以下の方法により取得し、保証品質決定部3の最大往復遅延時間31に格納する。最大往復遅延時間31は、前記(式1),(式2),(式3),(式5)におけるRTTとして、使用される。
図3は、図2における保証品質決定部のブロック構成図である。
保証品質決定部3は、最大往復遅延時間31,プロトコル情報32,および最大パケット長33の各ファイルと、それらのファイルの内容を参照することにより、外部から流入した流入量を決定する流入量決定部30と、流入量決定部30からの出力を受け取り、そのキュー長を決定するキュー長決定部34とから構成される。
保証品質決定部は、ホスト間の最大往復遅延時間の値を以下の方法により取得し、保証品質決定部3の最大往復遅延時間31に格納する。最大往復遅延時間31は、前記(式1),(式2),(式3),(式5)におけるRTTとして、使用される。
1.端末コンピュータ101−Aと101−Cの往復遅延時間がDiffservネットワーク内の最大往復遅延時間であり、この値が最大往復遅延時間31に格納される。この場合、最大往復遅延時間31は全ての品質保証通信において共通の値として使われる。
2.通信を行う端末コンピュータ間、例えば端末コンピュータ101−Aと101−Cにおいて、pingのようなパケットの送信と受信によって往復遅延時間の測定を行い、端末コンピュータ101−Aの品質保証要求に往復遅延時間の測定情報を付加して、Bandwidth Broker104に送信する。Bandwidth Broker104は、品質保証要求の往復遅延時間情報を最大往復遅延時間31に格納する。この場合、最大往復遅延時間31は品質保証要求時毎に値が変わる。
3.Bandwidth Broker104がDiffservネットワークを管理する上で、例えばエッジルータ102−A,102−Bをそれぞれ単位としたエリアに分割して管理し、エリア間の最大往復遅延時間がネットワーク設計時に決められているか、例えばエッジルータ102−A,102−B間の定期的なpingによる測定によってエリア間の最大往復遅延時間の情報が最大往復遅延時間31に格納されている。そして、品質保証要求の受信時に、品質保証を行うコンピュータ、例えば端末コンピュータ101−Aと101−Cが属する2つのエリア、102−Aと102−Bを管理情報から特定し、往復遅延時間の情報を最大往復遅延時間31から取得する。この場合、最大往復遅延時間31はエリア間毎の最大往復遅延時間の情報を持っている。
4.エッジルータ102−A・102−B、もしくは端末コンピュータ101−A・101−B・101−Cが定期的に他のコンピュータ・エッジルータとpingによる遅延時間の測定を行い、最大往復遅延時間31に測定データが格納されている。そして、品質保証要求の受信時に、品質保証を行うコンピュータ間の往復遅延時間の測定値を最大往復遅延時間31から取得する。この場合、最大往復遅延時間31はコンピュータ毎の最大往復遅延時間の情報を持っている。
5.通信を行う端末コンピュータ間、例えば端末コンピュータ101−Aと101−Cにおいて、既に通信を行っているTCPセッションのデータパケットとそれに対応するACKパケットの送受信時刻の差を往復遅延時間として計算し、端末コンピュータ101−Aの品質保証要求に往復遅延時間の情報を付加して、Bandwidth Broker104に送信する。Bandwidth Broker104は、品質保証要求の往復遅延時間情報を最大往復遅延時間31に格納する。この場合、最大往復遅延時間31は、品質保証要求時毎に値が変わる。
図4は、品質保証要求に含まれる情報の説明図である。
図4に示すように、フロー識別情報とは、アドレス情報、フロー識別子等のフローを識別するための情報である。
プロトコル情報とは、TCP NewReno,High−Speed TCP等のプロトコル名である。
スループット値とは、該当フローで保証したいスループット値のことである。
往復遅延時間とは、品質保証を行うコンピュータ間の往復遅延時間の測定値(コンピュータ間で測定する場合にのみ使用)である。
図4に示すように、フロー識別情報とは、アドレス情報、フロー識別子等のフローを識別するための情報である。
プロトコル情報とは、TCP NewReno,High−Speed TCP等のプロトコル名である。
スループット値とは、該当フローで保証したいスループット値のことである。
往復遅延時間とは、品質保証を行うコンピュータ間の往復遅延時間の測定値(コンピュータ間で測定する場合にのみ使用)である。
(CIR・CBSの決定動作)
図5は、TCP New Renoの送信パケット数変化の例を示す図である。
品質保証要求は、図5に示す情報を含んだパケットで、フローの送信元コンピュータやサービスを提供しているサーバ等からBandwidth Broker104に送信され、Bandwidth Broker104の品質保証要求受付部2で受信される。
図5は、TCP New Renoの送信パケット数変化の例を示す図である。
品質保証要求は、図5に示す情報を含んだパケットで、フローの送信元コンピュータやサービスを提供しているサーバ等からBandwidth Broker104に送信され、Bandwidth Broker104の品質保証要求受付部2で受信される。
CIRとCBSの値は、保証品質決定部3の流入量決定部30において、品質保証要求受付部2から渡された品質保証要求、最大往復遅延時間31、プロトコル情報32、最大パケット長33の値から、上記(式1)〜(式5)を解くことで算出される。プロトコル情報32は、プロトコルのレート制御方式から同時送信パケット数を求める式を格納してあるリストであり、上記(式3)に相当するプロトコル毎の同時送信パケット数が格納されている。最大パケット長33は、Diffservネットワークで送信できるパケットの最大長であり、最大往復遅延時間と同様にDiffservネットワーク設計時に値が決められ、格納されているものとする。最大パケット長33は、上記(式1),(式2),(式3),(式4)におけるSZとして使用われる。
前述のように、例えば、TCPNewRenoの場合、スロースタート後の輻輳回避状態において、ホスト間の往復遅延時間(RTT)毎に送信パケット数を1増やし、パケットロスが起きたとき送信パケット数を半分にするというレート制御方式であるため、パケット送信数は、図5に示すように、送信パケット数Wとその半分であるW/2の間を往復する形(平均3W/4)で送信される。
図6は、パケット構造(TCP)を示す図である。
ここで扱われるパケットは、IPヘッダとIPペイロードから構成され、さらにIPペイロードは、TCPッダとTCPペイロードに分けられる。
前述のように、TCPはRTT毎に送信可能なパケット数をバースト的に送信するため、上記(式3)で求めた送信パケット数Wがネットワークで保証するべきバーストサイズCBSとなる。上記(式3)のバーストサイズCBSでは、TCPペイロード長SZでバースト量を計算しているが、IPパケット長でバースト量を計測するエッジルータでは、SZをIPパケット長の値で計算する必要がある。
ここで扱われるパケットは、IPヘッダとIPペイロードから構成され、さらにIPペイロードは、TCPッダとTCPペイロードに分けられる。
前述のように、TCPはRTT毎に送信可能なパケット数をバースト的に送信するため、上記(式3)で求めた送信パケット数Wがネットワークで保証するべきバーストサイズCBSとなる。上記(式3)のバーストサイズCBSでは、TCPペイロード長SZでバースト量を計算しているが、IPパケット長でバースト量を計測するエッジルータでは、SZをIPパケット長の値で計算する必要がある。
(キュー長の決定動作)
品質保証要求によって必要となるキュー長は、キュー長決定部33によって、流入量決定部30において算出されたCBSと品質保証フロー情報6から既に品質保証により確保されているCBSの値から、上記(式6)を用いて算出される。
品質保証要求によって必要となるキュー長は、キュー長決定部33によって、流入量決定部30において算出されたCBSと品質保証フロー情報6から既に品質保証により確保されているCBSの値から、上記(式6)を用いて算出される。
(要求の受付判定動作)
流入量決定部30とキュー長決定部33によって算出されたCIR,CBS,キュー長は、ネットワークリソース管理部4によって、Diffservネットワーク内の空きリソースとの比較によって判定がされる。リソースの空きがある場合には、エッジルータ5に対して設定の更新がされ、品質保証の対象となるフロー情報を品質保証フロー情報6に追加する。
流入量決定部30とキュー長決定部33によって算出されたCIR,CBS,キュー長は、ネットワークリソース管理部4によって、Diffservネットワーク内の空きリソースとの比較によって判定がされる。リソースの空きがある場合には、エッジルータ5に対して設定の更新がされ、品質保証の対象となるフロー情報を品質保証フロー情報6に追加する。
(実例動作)
次に、実際に動作させた場合の例を説明する。
図1に示すように、2台のエッジルータ102−A・102−Bと2台のコアルータ103−A・103−BからDiffservネットワークが構成されており、1台のBandwidth Broker104がDiffservネットワークの各リンクの帯域と各ルータのキュー長を管理している。
Diffservネットワークに接続されているコンピュータ間の最大往復遅延時間は60ms、転送可能な最大パケット長は1500バイトと設計時に決められており、保証品質決定部3の最大往復遅延時間31と最大パケット長33にそれぞれ格納されている。
次に、実際に動作させた場合の例を説明する。
図1に示すように、2台のエッジルータ102−A・102−Bと2台のコアルータ103−A・103−BからDiffservネットワークが構成されており、1台のBandwidth Broker104がDiffservネットワークの各リンクの帯域と各ルータのキュー長を管理している。
Diffservネットワークに接続されているコンピュータ間の最大往復遅延時間は60ms、転送可能な最大パケット長は1500バイトと設計時に決められており、保証品質決定部3の最大往復遅延時間31と最大パケット長33にそれぞれ格納されている。
また、品質保証通信で想定されるプロトコルはTCP NewRenoであり、上記(式3)の同時送信パケット数の算出式がプロトコル情報32に格納されている。ここで、端末コンピュータ101−Aが他の端末コンピュータ101−Cと通信を行う場合、エッジルータ102−A、コアルータ103−A、エッジルータ102−Bを経由してパケットの送受信が行われる。このとき、端末コンピュータ101−A・101−C間の通信品質を保証したい場合、通信前、もしくは通信中に、端末コンピュータ101−Aや101−Aが利用しているサービスのサーバ等、通信品質の保証を行いたいフローを認識できるいずれかの装置によって、品質保証要求のパケットがBandwidth Broker104に送信される。
図7は、品質保証要求の例を示す図である。また、図8はBandwidth Brokerにおける品質保証処理の動作フローチャートである。
品質保証要求のパケットは、図7に示す情報を持っており、TCP NewRenoを用いて100Mbpsのスループットを要求している。
Bandwidth Broker104では、品質保証要求受付部2によって受信された品質要求パケットの内容が保証品質決定部3に渡され(ステップ81)、保証品質決定部3の流入量決定部30においてネットワークで必要になるリソースCIR、CBSが算出され(ステップ82)、キュー長決定部34においてキュー長が算出される(ステップ83)。各値は、上記(式3)〜(式6)を用いて、以下のように算出される。
品質保証要求のパケットは、図7に示す情報を持っており、TCP NewRenoを用いて100Mbpsのスループットを要求している。
Bandwidth Broker104では、品質保証要求受付部2によって受信された品質要求パケットの内容が保証品質決定部3に渡され(ステップ81)、保証品質決定部3の流入量決定部30においてネットワークで必要になるリソースCIR、CBSが算出され(ステップ82)、キュー長決定部34においてキュー長が算出される(ステップ83)。各値は、上記(式3)〜(式6)を用いて、以下のように算出される。
流入量決定部30では、プロトコル情報32が持っている上記(式3)より、スループットXから送信パケット数Wを算出する。
4 RTT 4 0.06
W=━━X・━━━=━━ (100000000/8)・━━━━━= 667
3 SZ 3 1500
4 RTT 4 0.06
W=━━X・━━━=━━ (100000000/8)・━━━━━= 667
3 SZ 3 1500
次に、上記(式4)より同時送信パケット数WからバーストサイズCBSを算出する。
CBS=W・SZ=667・1500=1000.5KB
CBS=W・SZ=667・1500=1000.5KB
次に、上記(式5)よりCBSからCIRを算出する。
CIR=CBS/RTT=8・1000500/0.06=133.4Mbps
CIR=CBS/RTT=8・1000500/0.06=133.4Mbps
キュー長決定部34では、品質保証フロー情報6に格納されている既に品質保証されているフローのCBSの値と、上記流入量決定部30において算出されたCBSの値を用いて、上記(式6)よりキュー長Lを算出する。ここで、他の品質保証を行っているフローはないものとし、流量決定部30において算出されたCBSの値からキュー長Lを算出する。
l
L=Σ CBSi=1000.5KB
i=1
l
L=Σ CBSi=1000.5KB
i=1
以上、算出されたCBS、CIR、キュー長の値をネットワークの経路上で前記CBS、CIR、キュー長のリソースが確保可能か否かの判定を行う(ステップ84)。リソース確保の判定は、ネットワークのトポロジとリソースの情報が格納されたネットワークトポロジ情報7の情報と比較して行われる。ネットワークリソース管理部4において、リソース確保が可能であると判定された場合、エッジルータを設定し(ステップ86)、ここではエッジルータ102−Aと102−Bに対して、要求のあったフローを送受信アドレスから識別するように登録し、前記登録されたフローに対してデータ転送速度CIR133.4Mbps、バーストサイズCBS1000.5KBを保証するように設定を行う。
また、出力キュー長Lが1000.5KBよりも小さい場合には、出力キュー長Lを1000.5KBに設定する。ネットワークリソース管理部4は、エッジルータ設定後に、品質保証を行ったフローを品質保証フロー情報6に登録する(ステップ87)。
最後に、品質保証要求受付部2は、品質保証要求の発信元に品質保証を行ったことを通知する(ステップ88)。なお、ネットワークに空きリソース有りか否かを判定した結果、無い場合には、品質保証要求の発信元に品質保証失敗の通知を行う(ステップ85)。
最後に、品質保証要求受付部2は、品質保証要求の発信元に品質保証を行ったことを通知する(ステップ88)。なお、ネットワークに空きリソース有りか否かを判定した結果、無い場合には、品質保証要求の発信元に品質保証失敗の通知を行う(ステップ85)。
(評価)
図9は、本発明の方式と非最適化方式の評価結果を示す図である。
本発明は、Bandwidth Broker品質保証方式における品質制御機能であって、TCPのようなデータ転送量が動的に変化する通信プロトコルに対して、ある時間内における転送データ量を保証するものである。
図9は、本発明の方式と非最適化方式の評価結果を示す図である。
本発明は、Bandwidth Broker品質保証方式における品質制御機能であって、TCPのようなデータ転送量が動的に変化する通信プロトコルに対して、ある時間内における転送データ量を保証するものである。
本発明の効果を示すために、上記実施例と同じネットワーク構成でシミュレーションによる評価を行った。評価では、本発明の方式によって算出したデータ転送速度CIR133.4Mbps・バーストサイズCBS1000.5KB・出力キュー長1000.5KBの値を用いて品質保証を行った場合と、前記CIR・出力キューは同じであるが、バーストサイズCBSが500KBでTCPに最適化されていない場合において、目標TCPスループット100Mbpsに対する達成度合いの比較を行った。
評価における品質保証要求は、端末コンピュータ101−Aと101−C間のTCP NewRenoのフローにおいて100Mbpsのスループットを保証する要求である。
評価における品質保証要求は、端末コンピュータ101−Aと101−C間のTCP NewRenoのフローにおいて100Mbpsのスループットを保証する要求である。
図9はでは、前記2つの方式によって品質保証を行ったときの5分間のスループット変化の結果を示している。
図9からも明らかなように、本発明の方式(実線)では、目標スループットに対して最適なデータ転送速度CIR133Mbps、バーストサイズCBS1000.5KBを保証しているため、平均スループットは100.78Mbpsであり、目標スループットと一致した。
図9からも明らかなように、本発明の方式(実線)では、目標スループットに対して最適なデータ転送速度CIR133Mbps、バーストサイズCBS1000.5KBを保証しているため、平均スループットは100.78Mbpsであり、目標スループットと一致した。
これに対して、非最適化方式(破線)では、バーストサイズCBSがTCPに最適されていないため、データ転送速度CIRは133Mbpsであるが、バーストサイズCBSの制限によりロスが発生し、往復遅延時間60msに対して十分な同時パケット送信数Wが得られなかった。そのため、平均スループットは56.73Mbpsと目標スループットの約半分程度となっている。
1 Bandwidth Broker
2 品質保証要求受付部
3 保証品質決定部
4 ネットワークリソース管理部
5 エッジルータ
6 品質保証フロー情報
7 ネットワークトポロジ情報
30 流入量決定部
31 最大往復遅延時間
32 プロトコル情報
33 最大パケット長
34 キュー長決定部
101−A,101−B,101−C 端末コンピュータ
102−A,102−B エッジルータ
103−A,103−B コアルータ
104 Bandwidth Broker
2 品質保証要求受付部
3 保証品質決定部
4 ネットワークリソース管理部
5 エッジルータ
6 品質保証フロー情報
7 ネットワークトポロジ情報
30 流入量決定部
31 最大往復遅延時間
32 プロトコル情報
33 最大パケット長
34 キュー長決定部
101−A,101−B,101−C 端末コンピュータ
102−A,102−B エッジルータ
103−A,103−B コアルータ
104 Bandwidth Broker
Claims (5)
- アプリケーションの送信するパケットの転送品質を保証するネットワークの通信品質制御方法において、
Bandwidth Brokerは、該ネットワークに接続されたコンピュータから品質保証要求を受信し、品質保証要求に必要なネットワークリソースであるデータ転送速度(CIR)とバーストサイズ(CBS)を算出し、
算出された前記CIRとCBSが確保可能か否かの判定を行い、
判定の結果、可能であれば対象のフローが経由するエッジルータの設定を更新し、
品質保証要求のレスポンスを要求元のコンピュータに送信し、
品質保証されたフローは、Diffservネットワークで確保されたCIR、CBSのトラフィック規定の範囲であれば、パケットの破棄は生じず、規定を超えたパケットについてはエッジルータにおいて破棄することを特徴とする通信品質制御方法。 - 請求項1に記載の通信品質制御方法において、
前記Bandwidth Brokerは、フローの品質保証要求に対して、ネットワークのエッジルータで保証するべき保証品質値を、フローで用いられるプロトコル情報と、ネットワーク内の最大パケット往復遅延時間と、フローの要求するスループット値から算出することを特徴とする通信品質制御方法。 - 請求項1または2に記載の通信品質制御方法において、
前記Bandwidth Brokerは、キュー長の算出のため、請求項2に記載の算出方法により算出されたフローの品質保証値からネットワークのエッジルータで必要な出力キューの長さを算出することを特徴とする通信品質制御方法。 - 請求項1〜3のいずれかに記載の通信品質制御方法において、
前記Bandwidth Brokerは、往復遅延時間RTTを算出するため、品質保証値の算出に必要なコンピュータ間のパケット往復遅延時間の情報を、1)ネットワーク設計時に任意のコンピュータ間の最大往復遅延時間を決定する手法、2)通信を行う前にコンピュータ間で往復遅延時間の測定を行う手法、3)ネットワークをいくつかのエリアに分割して管理し、エリア間の最大往復遅延時間をネットワーク設計時に決めるか、あるいは、定期的な測定によりエリア間の最大往復遅延時間の情報を取得する手法、4)エッジルータもしくはコンピュータが定期的に他のすべてのコンピュータ・エッジルータと遅延時間の測定を行う手法、5)通信時に、データパケットの送信時刻とそれに対応するACKパケットの受信時刻からコンピュータ間の遅延時間を測定する手法、のいずれか一つを用いることによって取得することを特徴とする通信品質制御方法。 - アプリケーションの送信するパケットの転送品質を保証するネットワークの通信品質制御装置において、
送信元コンピュータや他の装置から品質保証の要求が送られると、該品質保証要求を受信するとともに、品質保証を行った後に、品質保証要求の発信元に品質保証を行ったことを通知する品質保証要求受付手段と、
ネットワークのトポロジとリソースの情報が格納されたネットワークトポロジ情報ファイルに格納されている情報と比較することにより、算出されたCBS、CIR、キュー長の値をネットワークの経路上で前記CBS、CIR、キュー長のリソースが確保可能か否かの判定を行い、保証品質を決定する保証品質決定手段と、
リソース確保が可能であると判定された場合、エッジルータを設定し、要求のあったフローを送受信アドレスから識別するように登録し、前記登録されたフローに対してCIR,CBSを保証するように設定を行うネットワークリソース管理手段と、
品質保証を行ったフローを登録する品質保証フロー情報ファイルと
を具備することを特徴とする通信品質制御装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006059498A JP2007243308A (ja) | 2006-03-06 | 2006-03-06 | 通信品質制御方法および装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006059498A JP2007243308A (ja) | 2006-03-06 | 2006-03-06 | 通信品質制御方法および装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007243308A true JP2007243308A (ja) | 2007-09-20 |
Family
ID=38588434
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006059498A Pending JP2007243308A (ja) | 2006-03-06 | 2006-03-06 | 通信品質制御方法および装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007243308A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010087675A (ja) * | 2008-09-30 | 2010-04-15 | Nec Corp | ネットワークシステム、制御装置及び通信フローの制御方法 |
-
2006
- 2006-03-06 JP JP2006059498A patent/JP2007243308A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010087675A (ja) * | 2008-09-30 | 2010-04-15 | Nec Corp | ネットワークシステム、制御装置及び通信フローの制御方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Carlucci et al. | Congestion control for web real-time communication | |
JP4705115B2 (ja) | ネットワーク監視 | |
CN114009089B (zh) | 在通信网络中估计时延敏感业务流的质量度量 | |
EP1235392A1 (en) | Data transmitting/receiving method, transmitting device, receiving device, transmitting/receiving system, and program | |
JP2009055327A (ja) | ネットワークシステム | |
US20160192233A1 (en) | Congestion control for a multimedia session | |
EP2873205A1 (en) | Quality of experience enhancement through feedback for adjusting the quality of service in communication networks | |
US8687507B2 (en) | Method, arrangement and system for monitoring a data path in a communication network | |
EP2868052B1 (en) | Rich media status and feedback for devices and infrastructure components using in path signaling | |
EP2670189B1 (en) | Control of data flows over transport networks | |
US12010025B2 (en) | System and method for accelerating or decelerating a data transport network protocol based on real time transport network congestion conditions | |
JP2010136257A (ja) | ネットワークシステム及び通信計画サーバ | |
Grigorescu et al. | Evaluation of the impact of packet drops due to AQM over capacity limited paths | |
EP1341350B1 (en) | A method for congestion detection for IP flows over a wireless network | |
JP4267988B2 (ja) | パケット送信量制御方法、通信システム、通信装置及びプログラム | |
JP2007243308A (ja) | 通信品質制御方法および装置 | |
Lübben et al. | On characteristic features of the application level delay distribution of TCP congestion avoidance | |
Khosroshahy | UARA in edge routers: an effective approach to user fairness and traffic shaping | |
Chodorek et al. | An analysis of elastic and inelastic traffic in shared link | |
Kudo et al. | Proposal of cross‐layer bandwidth assignment with buffer size indication for TCP flow control | |
Begić et al. | Rapid synchronization of RTP multicast sessions | |
Luczak et al. | Experimental Assessment of MPTCP Congestion Control Algorithms for Streaming Services in Open Internet. | |
Zhang et al. | A Congestion Control Mechanism for Streaming Media Transmission Over Wireless Environment | |
Domingo et al. | Quality of service support in wireless ad Hoc Networks connected to fixed diffserv domains | |
Nyambo et al. | Bandwidth Management and Security in Mobile Ad Hoc Networks |