JP2007184991A - Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム - Google Patents
Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム Download PDFInfo
- Publication number
- JP2007184991A JP2007184991A JP2007096820A JP2007096820A JP2007184991A JP 2007184991 A JP2007184991 A JP 2007184991A JP 2007096820 A JP2007096820 A JP 2007096820A JP 2007096820 A JP2007096820 A JP 2007096820A JP 2007184991 A JP2007184991 A JP 2007184991A
- Authority
- JP
- Japan
- Prior art keywords
- router
- routing
- class
- bit
- traffic
- 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
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ルータ制御によるQoS手法と経路制御によるQoS手法を組み合わせても干渉を避けて実用性の高いQoSを実現することができるIPネットワークにおけるサービス品質制御装置を提供すること。
【解決手段】サービス品質制御装置は、IPネットワークで、IPパケットを品質クラス毎に分類し、分類した品質クラス毎に品質保証を行なう。本装置は、IPパケットのIPヘッダのフィールド内に、IPネットワークを構成するルータの制御のためのビットと当該ルータのルーチングためのビットを干渉しないように設定するIPヘッダ設定手段と、前記設定手段により設定された情報をルータに通知する通知手段とを有する。
【選択図】図2
【解決手段】サービス品質制御装置は、IPネットワークで、IPパケットを品質クラス毎に分類し、分類した品質クラス毎に品質保証を行なう。本装置は、IPパケットのIPヘッダのフィールド内に、IPネットワークを構成するルータの制御のためのビットと当該ルータのルーチングためのビットを干渉しないように設定するIPヘッダ設定手段と、前記設定手段により設定された情報をルータに通知する通知手段とを有する。
【選択図】図2
Description
本発明は、IPネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システムに関する。
近年ネットワークの高速化に伴いインターネットにおいて、音声やビデオのような連続メディアを高品質に転送する要求が急速に増大している。ところが、
現在のインターネットによって提供されている主なサービスはベストエフォート型であるため、リアルタイム性を伴うマルチメディア情報(リアルタイムアプリケーション)に対して、必ずしも高品質な転送を保証できるとは限らない。
現在のインターネットによって提供されている主なサービスはベストエフォート型であるため、リアルタイム性を伴うマルチメディア情報(リアルタイムアプリケーション)に対して、必ずしも高品質な転送を保証できるとは限らない。
そこで、インターネット上に流れるデータの種類に応じたサービスを提供するために、ネットワークサービスの品質、すなわちQoS(Quality-of-Service)を提供する技術としてDiffServ(Differential Services)が知られている(例えば、非特許文献1)。DiffServとは、ルータがパケット中の品質クラスに基づいてトラヒックの優先制御をする技術で、IPパケットのヘッダ内に書き込まれるクラス識別子を識別することで、クラス別の優先制御を可能にしている。
このDiffServでは、例えば、IPv4ヘッダの場合、TOS(Type of Service)フィールドの8ビットを利用してトラヒックをいくつかのクラスに分け、そのクラス単位でQoS制御が行なわれる。また、IPv6では、Traffic Classフィールドの8ビットが利用される。
一方、経路制御に関しては、OSPF(Open Shortest Path First)等のルーチングプロトコルに依存している。OSPF(例えば、非特許文献2参照)は、リンクステート型の経路プロトコルと呼ばれ、各ルータが「リンクステート」と呼ばれる情報要素を作成し、IPマルチキャストを用いてほかの全OSPFルータに配信する。これを受信したルータは、このリンクステート情報に基づき、ほかのルータがどこに存在し、どのように接続されているのかというLSDB(Link-State DataBase:リンクステートデータベース)を作成し、ネットワーク・トポロジを把握する。このようにOSPFは、リンクステート型のプロトコルであるため、各ルータは領域内のネットワーク構成が把握され、最短経路を計算することが可能となっている。
また、QoSを実現するためのルーチング制御手法として、トラヒックをクラス別に転送する目的で、複数の経路(これをマルチパスという)をクラスによって使い分けるというマルチパスルーチング手法がある。例えば、以前のOSPF(非特許文献3参照)では、目的地以外にTOSフィールドの値を参照するTOSルーチングがサポートされていたが、現在は削除されている。
[RFC2745] "An Architecture for Differentiated Services", http://www.ietf.org/rfc/rfc2475.txt
[RFC2328] "OSPF Versuion2", http://www.ietf.org/rfc/rfc2328.txt
[RFC1583] "OSPF Versuion2", http://www.ietf.org/rfc/rfc1583.txt
上述したように、サービスの品質要求に応じてQoSを提供する技術としては、DiffServのようにルータによるキューイング、スケジューリング等の制御によってQoSのための帯域制御を実現する技術(従来技術a)と、複数の経路をクラスによって使い分けてクラス別のQoSを実現するマルチパスルーチング技術(従来技術b)がある。
これまで、従来技術aのルータ制御によるIPヘッダフィールドの使用方法と、従来技術(b)のマルチパスルーチングによるIPヘッダフィールドの使用方法は、お互いに独立に考えられたものであるため、従来技術aと従来技術bを組み合わせて使用した場合、IPヘッダフィールド内の参照するビット位置同士で重なる部分があり、お互いが干渉を与え合うことになる。
IPヘッダ内のフィールドにおいてお互いの参照するビットが干渉すると、ルータ制御クラスと、ルーチングクラスの対応が自由に変更できないといった問題が生じる。例えば、トラヒックをクラス別に分ける場合、ルータ制御のクラスと、ルーチング用のクラスは1対1で対応するとは限らない。すなわち、ルータ制御のクラス複数が1つのルーチングクラスで運ばれることや、逆に同じルータの制御クラスであっても複数のルーチングクラスに分けて運ぶことも十分考えられる。
また、あるルータ制御クラスが転送経路を変えるとき、現在対応しているルーチングクラス自体の経路を再計算などによって変更するより、他のルーチングクラスで要求を満たす経路が存在するなら、そのルーチングクラスへ対応関係だけ変更させる方が望ましい。
このようにIPヘッダフィールド内のルータ制御ビットと、ルーチングの参照ビットが干渉すると、お互いの相互干渉により、クラス間の対応が固定されてしまい、柔軟なクラス間の対応が難しい。
図14は、従来技術aのルータ制御と、従来技術bのマルチパスルーチングを併用したときの上記のような問題を説明するための図である。同図では、IPネットワークを構成ルータがR1〜R4であるとしている。
同図において、DiffServとTOSルーチングを組み合わせる場合、DiffServではType of Serviceフィールドの先頭から6ビットがDSCP(DiffServ Code Point)として使用され(図15(a)参照)、TOSルーチングはIPv4ヘッダのType Of Serviceフィールドの4ビット目から7ビット目までに固定されて使用(図15(b)参照)される。例えば、IPv4ヘッダのType of Serviceフィールド内のビットが"00111100"の場合、 "001111"の6ビットはDiffServにおけるクラスを表し、"1110"の4ビットはTOSルーチングにおけるクラスを表す。すなわち、DiffServのクラスとTOSルーチングのクラスのビット位置は一部重なり合う部分(図15の矢印参照)がある。
図14に戻り、同図の(1)のケースのように、DiffServの"001111**(DSCP)"というクラスをデフォルト経路で転送する場合は、デフォルトのルートエントリで対応されるがデフォルト経路以外で転送するならTOSルーチングに"***1110*"というルートをテーブルに別にエントリすることが必要となってくる。
また、同図の(2)のケースように、DiffServの"111110**(DSCP)"というクラスをTOSルーチングの"***1110*"と同様のルートで転送したい場合でも、TOSルーチングに"***1100"というエントリが別に必要になり、独立に計算されなくてはならない。つまり、同じ経路を通る場合でもDSCP毎にTOSクラスが必要となってしまう。
さらに、DiffServクラスは対応するTOSルーチングクラスを変化させることができない。例えば、同図の(3)のケースのように、DSCP:001111をTOS:1000の経路で送りたくても、TOS:1110の経路を再計算させて変更させるしかない。
このように、TOSルーチングとDiffServとでは、その動作においてお互いが参照するビットが干渉してしまうため、DSCPとあるルーチングクラスとの対応関係を変えようとしても、自分自身の値を変えるしかない。すなわち、DiffServのクラスとTOSルーチングのクラスはお互いのビットを自由に変更するができない。
また、DSCPが自分の経路を変更するには、対応するTOSのコスト(主にインターフェイスの帯域幅により決定)を調整し、再計算により、経路を変更するしかなく、ルータや回線(リンク)に過渡の負担がかかってしまう。
また、複数のDSCPが同じ経路を通るような場合でも、TOSの部分が異なれば、TOSルーチングで同じテーブルを参照することはできないため、同じ経路に対して複数のエントリを持たなくてはならない。
これらの上述の問題はTOSルーチングの場合だけでなく他のマルチパスルーチングの場合でも同様に生起する問題であり、ルータ制御とルーチングを組み合わせてQoSを実現することは難しい。
本発明は、上記のような問題点に鑑みてなされたもので、その課題とするところは、ルータ制御によるQoS手法と経路制御によるQoS手法を組み合わせても干渉を避けて実用性の高いQoSを実現することができるIPネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システムを提供することである。
上記課題を解決するため、本発明の一形態によれば、IPパケットを品質クラス毎に分類し、分類した品質クラス毎に品質保証を行なうIPネットワークにおけるサービス品質制御装置であって、前記IPパケットのIPヘッダのフィールド内に、前記IPネットワークを構成するルータの制御のためのビットと当該ルータのルーチングためのビットを干渉しないように設定するIPヘッダ設定手段と、前記設定手段により設定された情報をルータに通知する通知手段とを有することを特徴としている。
また、本発明の一形態によれば、前記サービス品質制御装置であって、前記IPヘッダ設定手段は、前記IPヘッダのフィールド内に前記ルータを制御するためのビット領域とルーチングためのビット領域を設け、それぞれの領域の比率を変えて設定する設定制御手段を有することを特徴としている。
また、本発明の一形態によれば、前記サービス品質制御装置であって、前記ルータを制御するためのビット列をルータ制御クラスとして表現し、前記ルーチングためのビット列をルーチングクラスとして表現し、IPパケットの種類に応じて前記ルータ制御クラスと前記ルーチングクラスの対応関係を保持するデータベース手段を有し、前記通知手段は、前記ルータに対し、前記データベース手段で保持される前記ルータ制御クラスと前記ルーチングクラスの対応関係を通知することを特徴としている。
また、本発明の一形態によれば、前記サービス品質制御装置であって、前記IPネットワークを構成するルータのトラヒック状況を監視するトラフィック監視手段を備え、前記監視結果に基づき前記データベース手段で保持される前記ルータ制御クラスと前記ルーチングクラスの対応関係を変化させる対応関係更新手段を備え、前記通知手段は、前記対応関係更新手段により変化させられた対応関係を前記ルータに通知することを特徴としている。
上記本発明の一形態によれば、IPヘッダ内にキューイングやスケジューリングなどルータ制御のためのルータ制御ビットと、ルータのルーチングのためのルーチングビットをお互いが干渉しないように設定するため、ルータ制御によるQoS手法と複数経路を使い分けるQoS手法の同時混在使用が可能となり、より実用性の高いQoSを実現することができる。
以下、本発明の実施の形態を図面に基づいて説明する。
本発明の実施の一形態に係るサービス品質制御方法が適用されるIP(インターネット・プロトコル)ネットワークにおけるサービス品質制御システムは、例えば、図1に示すように構成される。
図1において、このサービス品質制御システムは、コンピュータで構成されるサービス品質制御装置10と、IPネットワーク100を構成するルータR1〜R3とから構成される。ここでは、説明を平易にするため、IPネットワーク100が3つのルータR1〜R3のみで構成されているものとする。
上記サービス品質制御装置10の機能ブロックは、例えば、図2に示すように構成される。
同図において、このサービス品質制御装置10は、制御部11と、ルータ制御・ルーチング対応データベース(DB)12と、トラフィック監視部13と、通知部14と、ビット設定部15とから構成される。
上記各ルータ(R1〜R3)の機能ブロックは基本的に同一構成をとるため、ここでは、ルータR1を例にとり構成の概要を説明する。
図3は、ルータR1の機能ブロックを示す構成図である。
同図において、このルータR1は、パケット中継処理部21と、入力キュー22と、出力キュー23と、入力インターフェイス(I/F)24、出力インターフェイス(I/F)25、ビット設定情報取得部26と、テーブル管理部27と、トラフィック測定部28と、通知部29から構成される。
次に、上記のように構成されたサービス品質制御装置10の動作概要を説明する。
サービス品質制御装置10のビット設定部15は、IPネットワーク100で使用するクラス数や経路数から、IPヘッダ内の任意のフィールドをルータ制御用のビットと、ルーチング用のビットとしてお互いが干渉しないように設定する。
例えば、図4に示すように、IPヘッダのフィールドをルータ制御用(ルータ制御ビット)とマルチパスルーチング用(ルーチングビット)に切り分けて設定する。このとき、IPv4のヘッダであればType of Serviceフィールドの前半4ビットをルータ制御ビットの領域として割当て、後半4ビットをルーチングビットの領域として割当てる。また、IPv6のヘッダであれば、Traffic Classフィールドの前半4ビットをルータ制御ビットの領域として割当て、後半4ビットをルーチングビットの領域として割当てる。
本実施例では、上記のようなルータ制御ビットとルーチングビットがIPv4のヘッダのType of Serviceフィールドに設定されたものとして以下、説明を進める。
サービス品質制御装置10のビット設定部15にて設定されたルータ制御ビットとルーチングビットの設定情報は、制御部11で所定のフォーマットに変換された後、通知部14を介してIPネットワーク100内の各ルータR1〜R3へと通知され、各ルータR1〜R3では、サービス品質制御装置10から受け取ったルータ制御ビットとルーチングビットの設定情報に基づき動作を開始させる。
次に、ルータ側の動作について図5を用いて説明する。
図5は、IPネットワークを構成するルータ群の一例を示す図である。同図において、ルータDstは、IPパケット(トラフィック)の目的地(送信先)を示し、ルータSrc(Src1〜Src3)はIPパケットの送信元(Source)を示し、ルータR1〜R4は内部ルータを示す。ここでは、まず、ルータR1を例にとり、ルータR1での動作を説明する。
ルータR1のビット設定情報取得部26は、サービス品質制御装置10から通知されたルータ制御ビットとルーチングビットの情報を入力I/F24を介して取得し、テーブル管理部27に出力する。テーブル管理部27は、ルータ制御ビットを、ルータ制御テーブルを生成するための情報として用い、ルーチングビットを、マルチパスルーチングテーブルを生成するための情報として用いる。
(1)マルチパスルーチングテーブルの生成
マルチパスルーチングテーブルは、マルチパスルーチングプロトコルに従って生成される。一般のルーチングテーブルには、あて先となるネットワーク・アドレスと使用するネットワーク・インターフェイスなどを記録した情報(エントリ)が多数格納されるが、マルチパスルーチングテーブルには、複数の経路に対するエントリが格納される。
マルチパスルーチングテーブルは、マルチパスルーチングプロトコルに従って生成される。一般のルーチングテーブルには、あて先となるネットワーク・アドレスと使用するネットワーク・インターフェイスなどを記録した情報(エントリ)が多数格納されるが、マルチパスルーチングテーブルには、複数の経路に対するエントリが格納される。
テーブル管理部27では、ルーチングビットをマルチパスルーチングテーブルの"ルーチングビット"の項目に設定する。具体的には、ルータDstまでの複数経路に対応するルーチングビット(数列)が設定される(下記及び図5の(b)参照)。
目的地 ルーチングビット 次のルータ
Dst Routing_1 R4
Routing_2 R2
さて、DiffServのルータでは、IPヘッダのTOSフィールド値を再定義することでTOSルーチングを実現している。そこで、TOSルーチングを用い、目的地に対して複数の経路を求めた場合、上記マルチパスルーチングテーブルにはTOS毎のエントリが作成される(図6の(a)参照)。ところが、このまま、TOSの値をルーチングクラスとすると、ルータ制御クラスと干渉する可能性がある。そのため、本実施例では、図6(b)に示すようにTOS毎に求めたルーチングテーブルに対し、改めてルーチングビットを対応させる(下記参照)。
Dst Routing_1 R4
Routing_2 R2
さて、DiffServのルータでは、IPヘッダのTOSフィールド値を再定義することでTOSルーチングを実現している。そこで、TOSルーチングを用い、目的地に対して複数の経路を求めた場合、上記マルチパスルーチングテーブルにはTOS毎のエントリが作成される(図6の(a)参照)。ところが、このまま、TOSの値をルーチングクラスとすると、ルータ制御クラスと干渉する可能性がある。そのため、本実施例では、図6(b)に示すようにTOS毎に求めたルーチングテーブルに対し、改めてルーチングビットを対応させる(下記参照)。
TOS ルーチングビット
TOS1 → Routing_1
TOS2 → Routing_2
なお、ルーチングプロトコル自体が、複数経路の識別子としてルーチングビットと同じフィールドを使用している場合は、サービス品質制御装置10がルーチングビットを対応させることはせず、そのままルーチングプロトコルのビットを利用する場合もある。
TOS1 → Routing_1
TOS2 → Routing_2
なお、ルーチングプロトコル自体が、複数経路の識別子としてルーチングビットと同じフィールドを使用している場合は、サービス品質制御装置10がルーチングビットを対応させることはせず、そのままルーチングプロトコルのビットを利用する場合もある。
(2)ルータ制御テーブルの生成
テーブル管理部27は、ビット設定情報取得部26から受け取ったルータ制御ビットをルータ制御テーブルの"ルータ制御ビット"の項目に設定する(下記及び図5の(a)参照)。
テーブル管理部27は、ビット設定情報取得部26から受け取ったルータ制御ビットをルータ制御テーブルの"ルータ制御ビット"の項目に設定する(下記及び図5の(a)参照)。
ルータ制御ビット キュー
Class_a Q1(優先度:高 廃棄率:低)
Class_b Q2(優先度:高 廃棄率:低)
Class_c Q3(優先度:低 廃棄率:低)
Class_d Q4(優先度:低 廃棄率:高)
ルータ制御テーブルで管理されるルータ制御クラス(Class_a〜Class_d)は、ルータ制御ビットの数列で表され、各クラス(Class)の優先度に応じたキューイング処理が行なわれる。例えば、Class_aの場合、ルータに流入してきたIPパケットは、入力キュー22内の高優先度キュー(Q1)に格納され、IPパケットが滞留している場合には、低廃棄率でIPパケットが廃棄される。
Class_a Q1(優先度:高 廃棄率:低)
Class_b Q2(優先度:高 廃棄率:低)
Class_c Q3(優先度:低 廃棄率:低)
Class_d Q4(優先度:低 廃棄率:高)
ルータ制御テーブルで管理されるルータ制御クラス(Class_a〜Class_d)は、ルータ制御ビットの数列で表され、各クラス(Class)の優先度に応じたキューイング処理が行なわれる。例えば、Class_aの場合、ルータに流入してきたIPパケットは、入力キュー22内の高優先度キュー(Q1)に格納され、IPパケットが滞留している場合には、低廃棄率でIPパケットが廃棄される。
上述したように本発明に係るサービス品質制御装置10によれば、IPヘッダ内のフィールドをルータ制御ビットとルーチングビットが相互に干渉を与えないように設定するようにしたため、図7の(a)に示すようなルータ制御のクラス複数(Class_a、Class_c、Class_d)が1つのルーチングクラス(Routing_1)で運ばれるような場合(ルータ制御クラスとルーチング用のクラスが1対1に対応しない場合)に、Class_aの経路を切替えるときでもルーチングビットをRouting_2に切替えるだけ(図7の(b)参照)。でよい。すなわち、現在対応しているルーチングクラスの経路を再計算しないで済むようになる。
なお、上記実施例では、各ルータ(R1〜R4、Scr1〜3、Dst)でルータ制御クラス・ルーチングクラスをルータ制御ビット・ルーチングビットにマッピングした同一のテーブルを持つ場合を示したが、上記各ルータで異なるテーブルを持ってもかまわない。例えば、ルータR1で、Class_a(ルータ制御クラス)とRouting_1(ルーチングクラス)を対応付けたテーブルを持ち、ルータR2で、Class_aとRouting_2を対応付けたテーブルを持つ。このように各ルータで持つテーブルを異ならせることで、柔軟な経路制御を実現することができる。
また、本発明に係るサービス品質制御装置10は、トラヒックの要求に対応するようにルータ制御クラスと、ルーチングクラスをトラヒックのQoS要求に合わせて対応させ、その対応関係を示す対応表をルータ制御・ルーチング対応データベース12に保持・管理する。
図8は、ルータ制御・ルーチング対応データベース12で保持・管理される対応表(テーブル)の構造例を示す図である。
同図において、上記対応表には、トラヒックの種別、ルータ制御クラス、ルーチングクラスが含まれる。この例では、各トラヒックの種別に対応したルータ制御クラスとルーチングクラスが以下の通り対応付けられて保持されている。
トラヒック種別 ルータ制御クラス ルーチングクラス
Traffic_a Class_a Routing_1
Traffic_b Class_b Routing_2
Traffic_c Class_b Routing_1
Traffic_d Class_c Routing_1
サービス品質制御装置10は、上記対応表をIPネットワーク内の各ルータに対して通知する(図9参照)。図9において、エッジルータ(Edge1〜6)はエリアの境界に配置されるルータである。
Traffic_a Class_a Routing_1
Traffic_b Class_b Routing_2
Traffic_c Class_b Routing_1
Traffic_d Class_c Routing_1
サービス品質制御装置10は、上記対応表をIPネットワーク内の各ルータに対して通知する(図9参照)。図9において、エッジルータ(Edge1〜6)はエリアの境界に配置されるルータである。
次に、エッジルータ(Edge1〜6)によるIPパケットの中継処理について説明する。
図10は、エッジルータ(Edge1〜6)によるルータ制御ビット・ルーチングビットの設定と内部ルータR1〜R4による転送例を説明するための図である。
同図において、IPネットワークにIPパケットが入ってくると、まず、IPネットワークの入口にあるエッジルータ(Edge2)でそのIPパケットが受け取られる。エッジルータ(Edge2)は、サービス品質制御装置10から通知された対応表(図8参照)に従い、受け取ったIPパケットのトラヒックの種類に対応するルータ制御ビットとルーチングビットをIPヘッダに書き込む。ここで、エッジルータ(Edge2)で受け取られたIPパケットのトラヒックの種類がTraffic_aとすると、図8のルータ制御・ルーチング対応データベースより、Traffic_aに対応するルータ制御クラスが"Class_a"であるので、テーブル管理部27では、"Class_a"に対応するルータ制御ビットをIPヘッダに書き込む。一方、図8のルータ制御・ルーチング対応データベースより、Traffic_aに対応するルーチングクラスが"Routing_1"であるので、Routing_1に対応するルーチングビットがIPヘッダに書き込まれる。なお、エッジルータ以外のルータ(内部ルータR1〜R4)では、上記のようなエッジルータ(Edge1)でのIPヘッダの書込みは原則操作されず、予め保持されているルータ制御ビット・ルーチングビットに従ったルータ制御・ルーチングが行なわれる。
上記のようにしてエッジルータでのテーブル書込み操作がなされると、エッジルータ(Edge2)で受け取られたTraffic_aのIPパケットは、ルータR1、R4、R3を中継してエッジルータ(Edge5)に届けられる。そして、このエッジルータ(Edge5)からIPパケットが出ていくときは、エッジルータ(Edge5)のテーブル管理部27は、先にIPヘッダに書き込んだルータ制御ビットとルーチングビットをIPネットワークに入る前の状態に戻す。なお、同図中のTraffic_bについても上述したTraffic_aと同様の処理がなされる。
また、本発明に係るサービス品質制御装置10は、ルータに流入するトラヒック状況を監視し、トラヒックの変動に応じてルータ制御クラスとルーチングクラスの対応関係を変化させる。
図11は、トラヒック変動に合わせてルータ制御クラスとルーチングクラスの対応関係の更新及び通知を行なう場合の動作を説明するための図である。
同図において、サービス品質制御装置10のトラフィック監視部13は、IPネットワーク内の各ルータ(Edge1〜6、R1〜R4)から定期的にトラヒックの報告を受ける。各ルータ(Edge1〜6、R1〜R4)のトラフィック測定部28では、入出力パケットの流入状況が観測される。例えば、単位時間あたりの総トラヒック量や、クラス毎のトラヒック量が測定される。なお、トラフィック測定部28で測定されるトラヒック量は、トラフィック状況が判断できるものであれば、限定されず、例えば、ルータの輻輳状況や利用率などであってもよい。
上記のようにしてトラフィック測定部28で測定されたトラフィック量は、トラフィック報告として通知部28を介してサービス品質制御装置10に報告される。
サービス品質制御装置10のトラフィック監視部13では、ルータから報告されたトラフィック報告を受け、その報告に基づく監視結果を制御部11に送る。制御部11では、制御部11を介して送られてくるトラヒックの変動状況に合わせて所定タイミングでルータ制御・ルーチング対応データベース12にアクセスし、該当するルータ制御クラスとルーチングクラスの対応表を更新する。このようにしてアップデートされた対応表は、IPネットワークの各ルータに通知され、各ルータでは、トラヒックの混雑具合に応じたルータ制御クラスとルーチングクラスの情報が保持される。
上記実施例では、ルータで測定されるトラヒック量に基づきルータ制御クラスとルーチングクラスの対応関係を更新する場合を示したが、IPネットワークにバースト的なパケットが発生した場合であっても、サービス品質制御装置10は、必要に応じてルータ制御クラスとルーチングクラスとの対応を変化させる。このとき、ルータ制御クラスとルーチングクラスの対応を変化させるだけで十分でない場合は、再度マルチパスルーチングプロトコル(例:TOSルーチング)を起動して経路の再設定を行ない、ルーチングビットの設定、ルータへの通知及びQoSに応じたクラスの対応を行なう。
サービス品質制御装置10において更新された上記対応表は、IPネットワーク内の各ルータに通知されるが、エッジルータ(Edge1〜6)と内部ルータ(R1〜R4)とでは処理が異なる。エッジルータ(Edge1〜6)は、新しい対応表を受け取ると、その対応表で示される新しい対応関係に従って、常にルータ制御・ルーチングを行なうが、内部ルータ(R1〜R4)は、ルータ制御クラス・ルーチングクラスの対応が変化したときなど必要なときのみルータ制御ビット・ルーチングビットを操作する。通常は、予め設定されているルータ制御ビット・ルーチングビットの値に基づいて、ルータ制御・ルーチングを行ないIPパケットの中継処理がなされる。
次に、通常トラフィック時におけるルータ制御クラスとルーチングクラスの対応について図12を参照しながら説明する。
この例のIPネットワークでは、3つのトラフィックTraffic_a、Traffic_b、Traffic_cが定義され、優先度は、Traffic_a>Traffic_b>Traffic_cであるとする。
また、Traffic_a、Traffic_bは、4MbpsのQoS要求があり、Traffic_cは、ベストエフォートのトラフィックであるものとする。
また、Traffic_a、Traffic_bは、4MbpsのQoS要求があり、Traffic_cは、ベストエフォートのトラフィックであるものとする。
また、上記IPネットワークを構成する各ルータは以下の通り構成されているものとする。
送信元ルータ:Src1〜Src3
内部ルータ:R1〜R4
送信先(目的地)ルータ:Dst
同図において、サービス品質制御装置10のビット設定部15によりIPヘッダ内のType of Serviceの前半4ビットがルータ制御ビット、後半4ビットがルーチングビットと設定されると、この設定の情報がIPネットワーク内の各ルータに通知される。ルータ制御クラスとしては、Class_a、Class_b、Class_cがあり、各ルータは、Class_a>Class_b>Class_cという順でIPパケットの出力の優先制御を行なう。ルーチングクラスは、Routing_a、Routing_bという複数の経路情報を持つ。ルータ制御クラスとルーチングクラスには、それぞれ、ルータ制御ビットとルーチングビットのビット列が割り振られる。
内部ルータ:R1〜R4
送信先(目的地)ルータ:Dst
同図において、サービス品質制御装置10のビット設定部15によりIPヘッダ内のType of Serviceの前半4ビットがルータ制御ビット、後半4ビットがルーチングビットと設定されると、この設定の情報がIPネットワーク内の各ルータに通知される。ルータ制御クラスとしては、Class_a、Class_b、Class_cがあり、各ルータは、Class_a>Class_b>Class_cという順でIPパケットの出力の優先制御を行なう。ルーチングクラスは、Routing_a、Routing_bという複数の経路情報を持つ。ルータ制御クラスとルーチングクラスには、それぞれ、ルータ制御ビットとルーチングビットのビット列が割り振られる。
通常トラヒック時、Src1からは4MbpsのTraffic_bトラフィック、Src3からは4MbpsのTraffic_cトラフィックがそれぞれDstに対して送られている。この状態では、Traffic_bのルータ制御クラスとルーチングクラスは、Class_bとRouting_aに、Traffic_cのルータ制御クラスとルーチングクラスは、Class_cとRouting_aに対応付けられている。
Src1からの4MbpsのTraffic_bトラフィックは、R1→R4の経路を経てDstに到着する。一方、Src3からの4MbpsのTraffic_cトラフィックは、R2→R3→R4の経路を経てDstに到着する。
続いて、バーストトラフィック時におけるルータ制御クラスとルーチングクラスの対応について図13を参照しながら説明する。
ここでは、IPネットワークを構成する各ルータの構成は上記と同じであるとし、Traffic_a〜Traffic_cの定義、プライオリティについても上記同様とする。
同図において、Src1、Src3からトラヒックが流れているときに、バースト的にSrc2から4MbpsのTraffic_aトラフィックが発生すると、Traffic_aは、Class_a、Routing_aに対応付けられているため、ルータR1ではTraffic_aとTraffic_bのトラフィックが合流し、Routing_aクラスの経路のままでは、リンク(R1−R4)の帯域や容量が不足する。このため、優先度の低いClass_b(Traffic_b)のパケットがロスしてしまう。
IPネットワーク内の各ルータでは、流入するトラフィックの状況が監視されており、そのトラフィック状況がサービス品質制御装置10に送られる。サービス品質制御装置10では、各ルータから受け取ったトラフィック状況からルータR1におけるTraffic_bのパケットロスの発生を検知すると、Traffic_bのルーチングクラスの変更が必要であると判断し、Traffic_bに対応するルーチングクラスの変更、例えば、Traffic_bのルーチングクラスをRouting_aからRouting_bにする変更が行なわれる。具体的には、ルータ制御・ルーチング対応データベース12に保持されている対応表の中のTraffic_b(Class_b)に対応するルーチングクラスをRouting_bに変更(更新)する。このようにして更新された新たな対応表は各ルータへと通知される。
ルータR1は、サービス品質制御装置10から上記の新たな対応表を受け取ると、その対応表に従ってルーチングテーブルのルーチングビットを変更する。これにより、Routing_bに対応付けられたTraffic_bは、ルータR2方面の迂回経路に流れ、ルータR1でのTraffic_bトラフィックのパケットロスを防ぐことができる。
ルータR2では、Traffic_bとScr3から送られてきたTraffic_cのトラフィックが合流する。リンク(R2−R3)の帯域が十分ではないが、ルータR2はルータ制御ビットを参照して優先制御を行ない、優先度の低いClass_c(Traffic_c)のベストエフォートトラフィックは、優先トラフィック(Traffic_a、Traffic_b)がなければ、リンク(R2−R3)を使用する。
ルータR4では、Traffic_a、Traffic_b、Traffic_cのトラフィックが合流する。このとき、リンク(R4−Dst)の帯域が十分ではない場合、ルータR4は、ルータ制御ビットを参照し、優先制御を行なう。優先度の低いClass_c(Traffic_c)のベストエフォートトラフィックは、優先トラフィック(Traffic_a、Traffic_b)がないときに、リンク(R4−Dst)を使用してDstに送られる。
以上により、Dstには、Class_a>Class_b>Class_cというプライオリティ値に対し、Traffic_aトラフィックの4Mbps、Traffic_bトラフィックの4Mbps、Traffic_cトラフィックの1Mbpsの割合で届き、プライオリティとQoS要求は満たされる。なお、Scr1のバーストトラフィックが無くなると、サービス品質制御装置10は、ルータ制御クラスとルーチングクラスの対応を図12のように戻し、その戻された後の対応表がIPネットワーク内の各ルータへと通知される。
以上、説明してきたように、本実施形態では、サービス品質制御装置10は、IPヘッダ内にキューイングやスケジューリングなどルータ制御のためのルータ制御ビットと、ルータのルーチングのためのルーチングビットをお互いが干渉しないように設定するため、ルータ制御によるQoS手法と複数経路を使い分けるQoS手法の同時混在使用が可能となり、より実用性の高いQoSを実現することができる。
(変形例)
本発明は上記実施形態に限定されるものではなく、種々の変形が可能である
(1)上記実施形態では、IPヘッダ内のフィールド(TOSフィールドまたはTraffic Classフィールド)の前半4ビットをルータ制御ビット、後半4ビットをルーチングビットと定義し割り振ったが、このような切り分け方に限定されるものではない。例えば、ルータ制御ビット数とルーチングビット数を次のような比率で設定してもよい。
本発明は上記実施形態に限定されるものではなく、種々の変形が可能である
(1)上記実施形態では、IPヘッダ内のフィールド(TOSフィールドまたはTraffic Classフィールド)の前半4ビットをルータ制御ビット、後半4ビットをルーチングビットと定義し割り振ったが、このような切り分け方に限定されるものではない。例えば、ルータ制御ビット数とルーチングビット数を次のような比率で設定してもよい。
ルータ制御ビット数 ルーチングビット数
7 1
6 2
5 3
4 4
3 5
2 6
1 7
また、ルータ制御ビットとルーチングビットの設定は、IPv4のTOSフィールドやIPv6のTraffic Classフィールドの他にもIPヘッダ内の任意のフィールドを利用して設定してもよい。
7 1
6 2
5 3
4 4
3 5
2 6
1 7
また、ルータ制御ビットとルーチングビットの設定は、IPv4のTOSフィールドやIPv6のTraffic Classフィールドの他にもIPヘッダ内の任意のフィールドを利用して設定してもよい。
(2)また、上記実施例では、IPネットワークで一律にIPヘッダ内のTOSフィールドをルータ制御ビットとルーチングビットと定義したが、本発明はこれに限定されるものではない。例えば、IPv6ヘッダのフローラベル領域をルータ制御ビットとルーチングビットと定義してもよいし、トラフィック毎にルータ制御ビット、ルーチングビットの設定を変えるような形態であってもよい。
上記実施例において、サービス品質制御装置10のビット設定部15の機能がIPヘッダ設定手段、設定制御手段に対応し、通知部14の機能が通知手段に対応する。また、ルータ制御・ルーチング対応データベース12の機能がデータベース手段に対応し、トラフィック監視部13の機能がトラフィック監視手段に、制御部11の機能が対応関係更新手段に対応する。
さらに、ルータのパケット中継処理部21の機能が制御中継手段に対応し、ビット設定情報取得部の機能とテーブル管理部27の機能が設定手段に対応し、トラフィック測定部28の機能がトラフィック測定手段に対応し、通知部29の機能がトラヒック状況報告手段に対応する。
以上、説明したように、本願発明によれば、IPヘッダ内にキューイングやスケジューリングなどルータ制御のためのルータ制御ビットと、ルータのルーチングのためのルーチングビットをお互いが干渉しないように設定するため、ルータ制御によるQoS手法と複数経路を使い分けるQoS手法の同時混在使用が可能となり、より実用性の高いQoSを実現することができる。
10 サービス品質制御装置
11 制御部
12 ルータ制御・ルーチング対応データベース
13 トラフィック監視部
14 通知部
15 ビット設定部
21 パケット中継処理部
22 入力キュー
23 出力キュー
24 入力インターフェイス(I/F)
25 出力インターフェイス(I/F)
26 ビット設定情報取得部
27 テーブル管理部
28 トラフィック測定部
29 通知部
100 IPネットワーク
R1〜R4、Edge1〜6、Src1〜Src3、Dst ルータ
11 制御部
12 ルータ制御・ルーチング対応データベース
13 トラフィック監視部
14 通知部
15 ビット設定部
21 パケット中継処理部
22 入力キュー
23 出力キュー
24 入力インターフェイス(I/F)
25 出力インターフェイス(I/F)
26 ビット設定情報取得部
27 テーブル管理部
28 トラフィック測定部
29 通知部
100 IPネットワーク
R1〜R4、Edge1〜6、Src1〜Src3、Dst ルータ
Claims (10)
- IPパケットを品質クラス毎に分類し、分類した品質クラス毎に品質保証を行なうIPネットワークにおけるサービス品質制御装置であって、
前記IPパケットのIPヘッダのフィールド内に、前記IPネットワークを構成するルータの制御のためのビットと当該ルータのルーチングためのビット
を干渉しないように設定するIPヘッダ設定手段と、
前記設定手段により設定された情報をルータに通知する通知手段とを有することを特徴とするサービス品質制御装置。 - 請求項1記載のサービス品質制御装置であって、
前記IPヘッダ設定手段は、
前記IPヘッダのフィールド内に前記ルータを制御するためのビット領域とルーチングためのビット領域を設け、それぞれの領域の比率を変えて設定する設定制御手段を有することを特徴とするサービス品質制御装置。 - 請求項1又は2記載のサービス品質制御装置であって、
前記ルータを制御するためのビット列をルータ制御クラスとして表現し、
前記ルーチングためのビット列をルーチングクラスとして表現し、
IPパケットの種類に応じて前記ルータ制御クラスと前記ルーチングクラスの対応関係を保持するデータベース手段を有し、
前記通知手段は、
前記ルータに対し、前記データベース手段で保持される前記ルータ制御クラスと前記ルーチングクラスの対応関係を通知することを特徴とするサービス品質制御装置。 - 請求項3記載のサービス品質制御装置であって、
前記IPネットワークを構成するルータのトラヒック状況を監視するトラフィック監視手段を備え、
前記監視結果に基づき前記データベース手段で保持される前記ルータ制御クラスと前記ルーチングクラスの対応関係を変化させる対応関係更新手段を備え、
前記通知手段は、
前記対応関係更新手段により変化させられた対応関係を前記ルータに通知することを特徴とするサービス品質制御装置。 - IPパケットを品質クラス毎に分類し、分類した品質クラス毎に品質保証を行なうIPネットワークにおけるサービス品質制御方法であって、
前記IPパケットのIPヘッダのフィールド内に、前記IPネットワークを構成するルータの制御のためのビットと当該ルータのルーチングためのビットを干渉しないように設定し、
前記設定された情報を前記ルータに通知し、
前記の通知により、前記ルータの動作を前記設定情報に基づいて開始させることを特徴とするサービス品質制御方法。 - IPパケットを品質クラス毎に分類し、分類した品質クラス毎に品質保証を行なうIPネットワークにおけるルータであって、
前記IPパケットのIPヘッダフィールド内に設定されるルータ制御のためのビットとルーチングのためのビットに応じて当該ルータの制御、及びルーチングを行なう制御中継手段を有することを特徴とするルータ。 - 請求項6記載のルータであって、
前記IPネットワークの境界に配置され、
前記IPパケットの種類に基づきルータ制御クラスとルーチングクラスを前記ルータ制御のためのビットとルーチングのためのビットに設定する設定手段を有することを特徴とするルータ。 - 請求項6又は7記載のルータであって、
当該ルータに流入するトラヒック量を測定するトラフィック測定手段と、
前記測定結果を、前記IPネットワークと接続されるサービス品質制御装置に報告するトラヒック状況報告手段とを有することを特徴とするルータ。 - IPネットワークを構成するルータと、そのIPネットワークに接続されたサービス品質制御装置とを具備してなるサービス品質制御システムであって、
前記サービス品質制御装置は、
IPパケットのIPヘッダのフィールド内に、前記ルータの制御のためのビットと当該ルータのルーチングためのビットを干渉しないように設定するIPヘッダ設定手段と、
前記IPヘッダ設定手段により設定された情報をルータに通知する通知手段とを有することを特徴とするサービス品質制御システム。 - 請求項9記載のサービス品質制御システムであって、
前記ルータは、
前記通知手段により通知される前記IPパケットのIPヘッダフィールド内に設定されるルータ制御のためのビットとルーチングのためのビットに応じて当該ルータの制御、及びルーチングを行なう制御中継手段を有することを特徴とするサービス品質制御システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007096820A JP2007184991A (ja) | 2007-04-02 | 2007-04-02 | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007096820A JP2007184991A (ja) | 2007-04-02 | 2007-04-02 | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006281849A Division JP2007049740A (ja) | 2006-10-16 | 2006-10-16 | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007220258A Division JP4112605B2 (ja) | 2007-08-27 | 2007-08-27 | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007184991A true JP2007184991A (ja) | 2007-07-19 |
Family
ID=38340620
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007096820A Pending JP2007184991A (ja) | 2007-04-02 | 2007-04-02 | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007184991A (ja) |
-
2007
- 2007-04-02 JP JP2007096820A patent/JP2007184991A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2004289674A (ja) | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム | |
Minei et al. | MPLS-enabled applications: emerging developments and new technologies | |
US7672324B2 (en) | Packet forwarding apparatus with QoS control | |
Alvarez | QoS for IP/MPLS networks | |
RU2358398C2 (ru) | Способ пересылки трафика, имеющего предварительно определенную категорию обслуживания передачи данных, в сети связи без установления соединений | |
CN101406023B (zh) | 实现多协议标签交换网络差分业务流量工程的方法和系统 | |
CN108989210B (zh) | 一种基于策略的隧道选择方法及软件定义网络控制器 | |
JP2008131240A (ja) | ネットワークシステム、その装置及び方法 | |
CN103597786B (zh) | 配置服务质量的方法和设备 | |
JP4112605B2 (ja) | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム | |
Rahimi et al. | Implementation of quality of service (QoS) in multi protocol label switching (MPLS) networks | |
JP4169493B2 (ja) | パスのアグリゲート方法およびノード装置 | |
Hodzic et al. | Traffic engineering with constraint based routing in MPLS networks | |
JP2007184991A (ja) | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム | |
JP2007049740A (ja) | Ipネットワークにおけるサービス品質制御装置及びその方法並びにル−タ、サービス品質制御システム | |
JP3720738B2 (ja) | 経路制御装置および方法 | |
Almofary et al. | Optimizing QoS for voice and video using diffserv-MPLS | |
Molnar et al. | Evaluation of bandwidth constraint models for MPLS networks | |
Garg et al. | A study of performance analysis of signaling protocols in MPLS | |
US20140269737A1 (en) | System, method and apparatus for lsp setup using inter-domain abr indication | |
JP6344005B2 (ja) | 制御装置、通信システム、通信方法及びプログラム | |
JP4668224B2 (ja) | 経路選択制御装置および通信システム | |
JP2004193975A (ja) | パケット廃棄方法およびパケット交換装置 | |
Danaj | 3G/4G IP RAN Backhauling MPLS DiffServ TE Reliability and Resiliency for Mobile Services | |
Kebria | Analyzing IP/MPLS as Fault Tolerant Network Architecture |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070427 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070626 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071106 |