本発明の一実施の形態に係るネットワーク概念図を図1に示す。本実施の形態においては、ノードn1乃至n7等のルータを含むネットワーク1にLP管理サーバ3が接続されている。LPは、MPLS(Multi Protocol Label Switching)におけるラベルスイッチドパス(Label Switched Path)を省略した記号であって、LP管理サーバ3は、ネットワーク1における任意のノード間の最適経路(LP)を決定するものである。すなわち、従来技術のように各ノードによってルーティングが制御されるのではなく、ネットワーク1におけるルーティングはLP管理サーバ3により集中制御されており、図1において点線で示しているように、各ノードは直接的又は間接的にLP管理サーバ3により制御されることになる。このような処理のためLP管理サーバ3は、LPについてのデータを保持するLP−DB31を管理している。LP−DB31に保持されるデータについては後に詳しく述べる。
ここで本実施の形態におけるネットワークの基本的な概念について説明しておく。図2(a)に示すように、ノードn1とノードn6の間にリンクl101が設けられ、ノードn6とノードn7の間にリンクl102が設けられ、ノードn7とノードn4の間にリンクl103が設けられ、ノードn6とノードn5の間にリンクl104が設けられ、ノードn5とノードn7の間にリンクl105が設けられ、ノードn5とノードn2の間にリンクl106が設けられ、ノードn5とノードn3の間にリンクl107が設けられ、ノードn1とノードn2の間にリンクl108が設けられ、ノードn2とノードn3の間にリンクl109が設けられ、ノードn3とノードn4の間にリンクl110が設けられているものとする。
このようなネットワークにおいてノードn1からノードn4までの経路として、図2(b)に示すようにLP1及びLP2が存在する。LP1は、リンクl101とリンクl102とリンクl103とから構成される。そして、LP1という経路の場合に、リンクl101にはL1というラベルが付与され、リンクl102にはL2というラベルが付与され、リンクl103にはL3というラベルが付与される。また、LP2は、リンクl108とリンクl109とリンクl110とから構成される。LP2という経路の場合に、リンクl108にはL4というラベルが付与され、リンクl109にはL5というラベルが付与され、リンクl110にはL6というラベルが付与される。
さらにノードn1からノードn4までの他の経路として、図2(c)に示すようなLP3が存在する。LP3は、リンクl101とリンクl104とリンクl107とリンクl110とから構成される。そして、LP3という経路の場合、リンクl101にはL7というラベルが付与され、リンクl104にはL8というラベルが付与され、リンクl107にはL9というラベルが付与され、リンクl110にはL10というラベルが付与される。
このように、LP1とLP3では共にリンクl101を使用するが、LP1ではL1、LP3ではL7という異なるラベルが付与される。すなわち、基本的には、同じリンクを使用する場合においても、LPが異なれば異なるラベルが付与される。言い換えれば、ラベルは全てのLPにおいて一意に付与される。ラベルが特定されればLPも特定され、特定されたラベルの次のラベルに係るリンクも特定できる。例えばラベルL8が指定されれば、ラベルL8に係るリンクl104が特定され、さらに次のラベルL9も特定され、ラベルL9に係るリンクl107も特定される。すなわち、各ノードにおいて順方向のルーティングが可能となる。
図2(a)ではノードn1からノードn4へのLPを問題としたが、本実施の形態では逆方向RLP(Reverse LP)についても同じラベルを用いる。すなわち、順方向のLPに関して対称な逆方向LPを用いる。このようにすれば、上り下りについてルーティング情報を共用でき、管理すべきデータ量を減らすことができる。具体的には、逆方向ということが分かれば、例えばラベルL3が特定されれば、次のラベルはラベルL2であると特定される。すなわち、各ノードにおいて逆方向のルーティングも可能となる。
但し、このような構成にすると、LPの数及びノード数が増加するほどラベルの数(=LP数×ノード数)も増加するため、管理すべきデータ量が増加する。そこで、本実施の形態では、ラベルマージという考え方を採用する。簡単な例を図3(a)及び(b)に示す。図3(a)に示すように、ノードn10とノードn11とノードn12とノードn13とを含むネットワークにおいて、ノードn10からノードn12への経路をLP10とし、ノードn11からノードn12への経路をLP11とする。また、ノードn10からノードn12までのリンクをl121とし、ノードn11からノードn12までのリンクがl123であり、ノードn12からノードn13までのリンクがl124であるとする。このような場合、LP10とLP11では同じリンクl124を使用しているが、図2の説明に従えばLP毎に異なるラベルを登録する必要がある。しかし上で述べたように、管理すべきデータ量の削減のため、リンクl124についてラベルを集約してLmという1つのラベルを付与することにする。すなわち、LP10についてはラベルL11とラベルLmで構成され、LP11についてはラベルL12とラベルLmで構成される。ノードn12では、ラベルL11が特定されれば、LP10において次のラベルはラベルLmであると特定できる。また、同じくノードn12では、ラベルL12が特定されれば、LP11において次のラベルはラベルLmであると特定できる。
一方図3(b)で示すように、逆方向、すなわちノードn13からノードn10へのLP10rとノードn13からノードn11へのLP11rとの場合には、図2の説明のように順方向から自動的に逆方向が特定されるわけではない。すなわち、ラベルLmが特定されても、LP10rなのかLP11rなのかを特定できない。従って次のラベルも特定できないので、ルーティング不可能となる。そこで、本実施の形態では、ラベルマージを行った場合においても逆方向のルーティングを可能にするため、分岐ノードn12において分岐を行うための仮想ラベルを導入する。
仮想ラベルは、LPを特定するものであって、例えば分岐先ラベルを特定するものである。図3(b)の例では、L11rという仮想ラベルによってラベルL11の方に分岐するようにする。すなわち、発側のノードn13ではLP10rを用いる場合には、ラベルLm及び仮想ラベルL11rを併せて指定したパケットを送信することになる。一方、LP11rを用いる場合には、同様にラベルLm及び仮想ラベルL12rを併せて指定したパケットを送信することになる。この仮想ラベルは、LP毎に一個だけ定義すれば良い。例えばLPの先頭ラベルがMPLSドメインにおいて一意に定義される場合は、その先頭ラベルを仮想ラベルとして用いることができる。
次に図2及び図3に示したような仕組みを実現するための構成について説明する。まず、ノードに配置されるルータの機能ブロック図を図4に示す。ルータ5は、ラベルマップ54と、リンクテーブル55と、従来から存在し且つ例えば8クラスの優先制御のための処理を実施する優先制御部53と、優先クラス毎にリンクの使用率を測定する使用率測定部51と、優先制御部53と協働し、ラベルマップ54及びリンクテーブル55を参照してパケットのルーティングを実施するルーティング処理部52とを有する。
図3(a)におけるノードn12におけるラベルマップ54は、例えば図5に示すようなデータを含む。すなわち、第1のラベルの列と、仮想ラベルの列と、第2のラベルの列とを有しており、各レコードが1つのLPに対応する。図5の第1のレコードでは、LP10のデータが登録されており、ラベルL11に対応して、分岐ノードである場合には仮想ラベルL11rと、ラベルLmが登録されている。従って、ノードn10からラベルL11が付されたパケットを受信すると、ラベルLmに転送すればよいことが分かる。逆に、ラベルLm及び仮想ラベルL12rが付されたパケットを受信すると、ラベルL12に転送すればよいことが分かる。
一方、図3(a)におけるノードn12におけるリンクテーブル55は、例えば図6に示すようなデータを含む。すなわち、リンクの列と、ラベルの列とを有し、リンクとラベルが対応付けられている。このように、ラベルが特定できればリンクも特定でき、ルータ5において当該リンクを構成するケーブルが接続されるポートが特定されるので、パケットのルーティングを行うことができる。
ルータ5における使用率測定部51は、定期的にリンクの使用率を測定し、LP管理サーバ3に通知する。但し、使用率の変動が所定範囲内であれば通知を省略する場合もある。なお、以下でも述べるが、ルータ5に接続しているリンクにボトルネックリンクが含まれる場合には、LP管理サーバ3が重点監視指示を送信してくるので、使用率測定部51は、重点監視指示を受信すると、ボトルネックリンクについての監視周期を短くしたり、所定幅以上使用率に変更があった場合にLP管理サーバ3に通知する場合には当該所定幅を狭くするなどの処置を講ずる。
次にLP−DB31に格納されるデータの一例を図7乃至図9を用いて示す。図7にリンクテーブルの一例を示す。図7の例では、図6と同様に、リンク(Lid)の列と、ラベル(La)の列とが設けられており、リンクと当該リンクに割り当てられたラベルとの対応関係が登録されている。LPーDB31においては、ネットワーク全体のリンクのデータが登録されている。ネットワークの構成が変更されると、本テーブルのデータについても更新される。
図8にリンクデータ・テーブルの一例を示す。図8の例では、リンク(Lid)の列と、当該リンクの静的な帯域幅(Bs)の列と、当該リンクの両端に接続されるルータのID(RTid)の列と、優先度毎のリンク使用率の列(Pri-ρ)とが設けられている。ここでは説明を簡単にしているため、優先度については0及び1のみが存在するものとしている。ルータ5の使用率測定部51により測定された使用率はLP管理サーバ3に送信され、本テーブルに登録される。
図9にLPテーブルの一例を示す。図9の例では、発側エッジルータ配下のネットワークアドレス集合(ネットワークアドレスが1つであれば当該ネットワークアドレス。ネットワークアドレスが2つ以上であれば代表ネットワークアドレス)を表す発ネットワークアドレスセット番号(SNo)の列と、着側エッジルータ配下のネットワークアドレス集合を表す着ネットワークアドレスセット番号(SNd)の列と、SNoとSNd間を接続するLPの静的透過帯域順位の列と、障害(上りU/下りD)の状態を表す列と、逆方向LP(RLP)における仮想ラベル(例えばSNoを用いる。逆方向なのでSNoは着側)(Lr)の列と、LPを構成する各リンクの帯域容量から算出されるLPの静的透過帯域(Bs)の列と、静的透過帯域についてのボトルネックリンクに対応するラベル(BsBN)の列と、パケットサイズがランダムである場合(M)とパケットサイズ一定の場合(D)のいずれかを登録するための透過帯域計算方式(Cal)の列と、ベストエフォート(0)と最優先(1)との区別を行うための優先度(Pri)の列と、上り側動的透過帯域(BdU)の列と、上り側動的透過帯域についてのボトルネックリンクに対応するラベル(BdUBN)の列と、下り側動的透過帯域(BdD)の列と、下り側動的透過帯域についてのボトルネックリンクに対応するラベル(BdDBN)の列と、ラベルデータの列とを含む。ラベルデータの列には、当該LPを構成するラベル(La)と、当該ラベルに対応するリンクの上り側使用率(ρU)と、当該ラベルに対応するリンクの下り側使用率(ρD)とが含まれる。なお、上でも述べたが優先度については2段階しかない例を示しているが、一般的にはN(Nは正の整数)段階設定することができる。
次に、LP管理サーバ3の基本的な処理内容について図10乃至図14を用いて説明する。LP管理サーバ3は、各リンクの帯域幅のデータを取得し、リンクデータ・テーブル(図8)に登録する(ステップS1)。このデータについては、ネットワーク中のノードから自動的に取得しても良いし、管理者の入力データを取得するようにしても良い。次に、LP管理サーバ3は、別途保持されているLP定義に基づきLP毎に静的透過帯域幅を算出し、当該静的透過帯域幅に従ってエッジルータ間(すなわち発側ノードから着側ノードまでの間)でLPグループLPGsmを特定する(ステップS3)。
LP毎の静的透過帯域について図11(a)を用いて説明する。図11(a)において、ラベル(対応するリンク)の帯域幅は上りについては上側の帯の長さで表されており、下りについては下側の帯の長さで表されている。図11(a)の例では、ラベルL2の帯域幅が最大で、ラベルL4の帯域幅が最小である。通常帯域幅が最小のリンクによってLP全体の静的透過帯域は制限されるので、図11(a)の場合にはラベルL4の帯域幅が当該LPの静的透過帯域となる。なお、上下で帯域幅が異なる場合もあり、その場合には上り下りで当該LPの静的透過帯域が異なる場合もある。また、ボトルネックとなるラベルも上り下りで異なる場合もある。このようにして、特定のエッジルータ間において最も静的透過帯域幅の値が大きいLPを上位n(図9の例ではn=3)個選択してLPグループLPGsmを構成する。このように静的透過帯域幅によって動的透過帯域幅の算出対象を限定することにより、計算量を減らすことができる。各LPグループLPGsmに含まれるLPのデータ(算出された静的透過帯域幅の値、LPを構成するラベル、仮想ラベルが必要な場合には仮想ラベルなど)をLPテーブル(図9)に格納する。
次に、各ルータからリンクの使用率のデータを取得し、リンクデータ・テーブル(図8)及びLPテーブル(図9)に格納する(ステップS5)。上でも述べたがリンクの使用率は優先度毎に取得する。そして、各LPGsm内の各LPについて動的透過帯域の値を算出し、LPテーブル(図9)に格納する(ステップS7)。動的透過帯域について図11(a)及び図11(b)を用いて説明する。図11(a)及び図11(b)の例では、各ラベルの静的な帯域幅を示す帯の中にハッチングが付された使用帯域が示されている。実際の通信においては、各ラベルの静的な帯域幅から使用された帯域幅を除いた部分が使用される。すなわち、図11(a)及び(b)においては白抜きの帯の長さが使用可能な帯域となる。図11(a)の場合、上り下り共にラベルL4において白抜きの帯の長さが最短となり、LPの動的透過帯域は、最も少ない、ラベルL4の上り帯域幅a及び下り帯域幅bにより特定される。必ずしも、上り下りとも同じラベルが最低の帯域幅となるわけではない。また、時間によっても各ラベルの使用率は異なる。例えば図11(a)の状態から時間が経って、図11(b)の状態になるとする。ここでは、ラベルL3の上りの使用帯域が多くなり、またラベルL2の下りの使用帯域が多くなっている。従って、上りについては最も少ないラベルL3の帯域幅cと、下りについては最も少ないラベルL2の帯域幅dとにより、動的透過帯域幅が特定される。
動的透過帯域幅については具体的には以下の方法で算出する。図12に示すように、中継ノードjにおいて、入力リンク側の帯域幅Bij、入力リンク側の使用率ρij、出力リンク側の帯域幅Boj、出力リンク側の使用率ρoj、出力リンク側の動的な帯域幅Bjとする。本実施の形態においては待ち行列モデルを適用して動的な帯域幅Bjを算出するものとする。パケットサイズが可変の場合には、M/M/1モデルに従って、Bj=Boj(1−ρoj)と算出される。また、パケットサイズが固定である場合には、M/D/1モデルに従って、Bj=Boj(1−ρoj)(1−ρoj2/2)と算出される。なお、優先クラスが規定されている場合には、近似的に各優先クラスの使用率ρojを当該優先クラスより上位の全てのクラスによる使用率に置き換えて計算を行う。LPの動的透過帯域幅Bは、LPを構成する全てのリンクについての動的な帯域幅Bjによって、B=Min{Bj}で算出される。
待ち行列モデルについては以下に補足しておく。図13に示すような待ち行列モデルを想定する。すなわち、現在サービス中の要素104と、待ち行列中の要素102乃至103と、最新到着分の要素101とから構成されるとする。このとき、要素102乃至103の行列長をLqとし、行列長がLqである場合におけるサイズP(bit)のパケットが転送される時間をWqとし、現在サービス中の要素104の行列長をρとし、最新到着分の要素101の行列長を1とし、待ち行列長Lqと現在サービス中分の行列長ρとを併せた行列長(Lq+ρ)をLとし、行列長がLの場合におけるサイズP(bit)のパケットが転送される時間をW、L+1(最新到着分も含めた行列長)をLrとし、そのときのサイズP(bit)のパケットが転送される時間をWrとする。
そうすると、パケットサイズ不定の場合であるM/M/1モデルの場合、Lq=ρ2/(1−ρ)、L=ρ/(1−ρ)、Lr=1/(1−ρ)となる。なお、実際には入力バッファが有限であるから、M/M/1{N}(Nはバッファ長)の方が好ましい。しかし、バッファ長も大きな値をとることができるようになってきており、M/M/1モデルでも十分である。
そして、以下の式が成り立つ。
Wr=(P/B')×Lr=(P/B')/(1−ρ)=P/B" (1)
B'は静的な帯域幅(bps)であり、B"は動的な帯域幅である。
(1)式を変形すると、以下のようになる。
(1/B')/(1−ρ)=1/B"
B"=B'×(1−ρ)
このように動的透過帯域幅は静的な帯域幅から使用帯域幅を引いた残余の帯域に等しくなる。
また、パケットサイズ固定の場合であるM/D/1モデルの場合、Lq'=1/2×ρ2/(1−ρ)、L'=(ρ−1/2×ρ2)/(1−ρ)、Lr'=(1−1/2×ρ2)/(1−ρ)となる。
そして、以下の式が成り立つ。
Wr=(P/B')×Lr=(P/B')×(1−ρ2/2)/(1−ρ)=P/B" (2)
(2)式を変形すると以下のようになる。
(1/B)×(1−ρ2/2)/(1−ρ)=1/B"
B"=B'×(1−ρ)/(1−ρ2/2)
このように、パケットサイズ固定の場合には、パケットサイズ不定の場合より動的透過帯域幅は広くなる。パケットサイズが通常1500バイト以下なので、実際の動的透過帯域幅はパケットサイズ固定と不定の中間になる。
図10の説明に戻って、ステップS7では、動的透過帯域幅B=Min{Boj}を算出するため、動的透過帯域幅Bを決定するBjをもたらすボトルネックリンクを特定し、LPテーブル(図9)に登録する(ステップS9)。なお、静的透過帯域についても静的透過帯域幅を決定する帯域幅をもたらすボトルネックリンクを特定し、LPテーブル(図9)に登録する。その後、LP−DB31に対するDB更新処理を実施する(ステップS11)。
このDB更新処理については図14を用いて説明する。まず、静的ボトルネックリンク(BNL)に対応するルータに対して重点監視指示を送信する(ステップS221)。例えば、各リンクを監視しているルータのデータを別途保持しておき、当該データに基づきステップS9(図10)で特定された静的ボトルネックリンクを用いてルータを特定する。なお、重点監視指示を受信したルータの使用率測定部51は、当該静的ボトルネックリンクに対して、通常より監視頻度を上げたり、使用率更新通知の閾値を変更するなどの処理を行う。また、動的ボトルネックリンク(BNL)に対応するルータに対して重点監視指示を送信する(ステップS223)。ステップS221と同様の処理が行われる。なお、静的ボトルネックリンクと動的ボトルネックリンクが同一である場合にはステップS223をスキップしてもよい。
その後、ネットワーク1の各ノード(ルータ)からの使用率更新通知を待つ(ステップS225)。そして、いずれかのノードから使用率更新通知を受信すると、当該使用率のデータをリンクデータ・テーブル(図8)及びLPテーブル(図9)に登録すると共に、使用率が更新されたリンクに関連するLPについて動的透過帯域を算出し、LPテーブル(図9)に登録する(ステップS227)。動的透過帯域の算出については、図10のステップS7と同じであるからここでは説明を省略する。ステップS227では、LPのいずれのラベル(リンク)がボトルネックリンク(BNL)であるかが分かるので、当該ボトルネックリンクのラベルを特定する(ステップS229)。そして、LPテーブル(図9)に登録されたボトルネックリンクと、今回特定されたボトルネックリンクとが同一であるか、すなわちボトルネックリンクの移動があるか判断する(ステップS231)。もしボトルネックリンクの移動がなければステップS225に戻る。
一方、ボトルネックリンクの移動があると判断された場合には、ステップS229で特定されたボトルネックリンクのラベルを、LPテーブル(図9)に登録する(ステップS232)。また、移動したボトルネックリンクに対応するルータに対して重点監視指示を送信する(ステップS233)。ステップS223と同様である。また、LPテーブル(図9)を参照して、前のボトルネックリンクが静的ボトルネックリンクではないか確認し、前のボトルネックリンクが静的ボトルネックリンクではない場合には、重点監視解除通知を、前のボトルネックリンクに対応するルータに送信する(ステップS235)。重点監視解除通知を受信したルータは、通常の使用率測定に戻る。すなわち、測定周期をデフォルトの期間に戻し、使用率更新通知の閾値を元に戻す等の処理を行う(ステップS237)。
このようなステップS225乃至S235を、例えば明示的な処理終了指示の受付など処理終了の条件が満たされるまで繰り返す。
図14のような処理を実施することにより、ネットワークの性能に大きく影響を与えるボトルネックリンクについては監視を強化し、不要な監視オーバーヘッドを減らすことによって、効率的にLPテーブル(図9)を更新することができるようになる。また、ネットワークの現況を踏まえたルーティングも可能になる。なお、関連する全ルータに、現状の透過帯域幅を通知して、ルータ自身に自己がボトルネックリンクに該当するかを判断させ、LP管理サーバ3に通知させるようにしても良い。
次に、上で述べた本実施の形態の基本的な処理を踏まえて、実際にパケットをルーティングする際の処理について説明する。なお、最初に、パケットの宛先のサーバが1つであるような通常のルーティングにおける処理について図15乃至図19を用いて説明する。
最初に、クライアント端末の例えばWebブラウザから、URLを含むIPアドレスの問い合わせがDNSに対して送信される(ステップS21)。そうすると、クライアント側のエッジルータは、クライアント端末からURLを含むIPアドレスの問い合わせを受信し、DNSに転送する(ステップS23)。クライアント側のエッジルータとDNSとの通信は頻繁に発生するので、予めLP管理サーバ3により指定されたLP及びRLPのデータ(LPの最初のラベル及びRLPの最初のラベル及び必要ならば仮想ラベル。なお本データは随時更新されるものとする。)をクライアント側のエッジルータが保持しており、当該LP及びRLPのデータを用いて転送を行うものとする。DNSは、クライアント側のエッジルータからURLを含むIPアドレスの問い合わせを受信すると(ステップS25)、URLに対応するIPアドレスを検索して抽出し、IPアドレス通知を返信する(ステップS27)。返信の際には、RLPのデータ(最初のラベル及び必要であれば仮想ラベル)により経路を特定する。クライアント側のエッジルータは、DNSからIPアドレス通知を受信し、要求元のクライアント端末に転送する(ステップS29)。クライアント端末のWebブラウザ等は、クライアント側のエッジルータからIPアドレス通知を受信する(ステップS31)。そして、受信したIPアドレスを含むリクエストを送信する(ステップS33)。例えばHTTP(Hyper Text Transfer Protocol)の場合には、GETメッセージを送信する。クライアント側のエッジルータは、クライアント端末からIPアドレスを含むリクエストを受信すると当該リクエストのデータを例えばバッファなどの記憶装置に格納し(ステップS35)、IPアドレス及びポート番号等の宛先データを含む最適LP問い合わせをLP管理サーバ3に送信する(ステップS37)。クライアント側のエッジルータとLP管理サーバ3との通信は頻繁に発生するので、予めLP管理サーバ3により指定されたLP及びRLPのデータをクライアント側のエッジルータが保持しておき、当該LP及びRLPのデータを用いて転送を行う。
LP管理サーバ3は、クライアント側のエッジルータからIPアドレス及びポート番号など宛先データを含む最適LPの問い合わせを受信すると(ステップS39)、最適LP決定処理を実施する(ステップS41)。最適LP決定処理については、図16及び図17を用いて説明する。LP管理サーバ3は、LPテーブルを参照し、問い合わせ元及び宛先のIPアドレスから両端ノードを特定し、該当するLPを抽出する(ステップS50)。また、宛先データに含まれるポート番号などからルーティングポリシーを決定する(ステップS51)。ここでは、ルーティングポリシーは、非対称ルーティング、トラフィック上下均等の対称ルーティング、トラフィック上下不均等(上りと下りのトラフィック量が例えば2倍以上異なる場合)の対称ルーティングのいずれかである。例えば、上り下りのルーティングが対称である必要の無いものが非対称ルーティングとして判定される。例えば、IPアドレス及びポートから、IP電話、ファイルダウンロード、ファイルアップロード、Webブラウジングといったアプリケーションであることが特定できれば、対称ルーティングが選択されるものとする。IP電話であればトラフィック上下均等の対称ルーティングが選択され、ファイルダウンロード、ファイルアップロード及びWebブラウジングであればトラフィック上下不均等の対称ルーティングが選択されるものとする。
従って、非対称ルーティングが選択されると(ステップS53:Noルート)、LPテーブル(図9)を参照して、上り下りそれぞれについて最大動的透過帯域幅を有するLPを選択する(ステップS55)。そして元の処理に戻る。
一方、対称ルーティングであって(ステップS53:Yesルート)、トラフィック上下均等が選択された場合(ステップS57:Yesルート)、ステップS50で抽出された対象LP群のうち、上り下りのうちトラフィック量が少ない方の動的透過帯域幅が規定値以下のものを除外する(ステップS59)。なお、残余のLPが存在しないような場合にはステップS55に移行するようにしても良い。そして残余のLPのうち上り下りの動的透過帯域幅の差が最小のLPを選択する(ステップS61)。ステップS61の代わりに、残余のLPのうち上り下りの動的透過帯域幅の平均値が最大となるLPを選択するようにしても良い。そして元の処理に戻る。
さらに、対称ルーティングであって(ステップS53:Yesルート)、トラフィック上下不均等が選択された場合(ステップS57:Noルート)、ステップS50で抽出された対象LP群のうちトラフィックが少ない方向(上り又は下り)のLPで動的透過帯域幅が規定値以下であるものを除外する(ステップS63)。なお、残余のLPが存在しないような場合にはステップS55に移行するようにしても良い。そして、残余のLPのうちトラフィックが多い方向(上り又は下り)のLPで最大の動的透過帯域幅を有するLPを選択する(ステップS65)。そして元の処理に戻る。
このような処理を実施することにより、通信アプリケーションなどにより特定されるルーティングポリシーに従って最適なLPが選択されるようになる。
図17を用いて図16の処理フローを具体的に説明しておく。図17(a)に示すように、LP#1の静的透過帯域(Bs)が100で、上り側動的透過帯域(BdU)が40で下り側動的透過帯域(BdD)が3であり、LP#2の静的透過帯域(Bs)が80で、上り側動的透過帯域(BdU)が30で下り側動的透過帯域(BdD)が10であり、LP#3の静的透過帯域(Bs)が50で、上り側動的透過帯域(BdU)が20で下り側動的透過帯域(BdD)が30であるとする。非対称ルーティングが選択された場合には、図17(b)に示すように、上りについてはLP#1の動的透過帯域幅が最大となり、下りについてはLP#3の動的透過帯域幅が最大となるため、上り下りについてそれぞれ選択される。一方、図17(c)に示すように、トラフィック上下不均等で対称ルーティングが選択された場合、具体的には上りのトラフィック量が下りのトラフィック量より多い場合には、ステップS63で「下り」について規定値以下のLPとしてLP#1を除外し、ステップS65で上りの動的透過帯域幅が最大となるLP#2を選択する。さらに、図17(d)に示すように、トラフィック上下均等で対称ルーティングが選択された場合、ステップS59で図17(d)の例では下りの動的透過帯域が最小となるLP#1を除外し、ステップS61で上り下りの動的透過帯域幅の差が最小となるLPとしてLP3が選択される。
図15の処理に戻るが、端子B及びCを介して図18の処理に移行する。なお、クライアント端末の処理については端子Aを介して図19の処理に移行する。まず、図18において、LP管理サーバ3は、ステップS41において決定されたLPからLPテーブル(図9)を用いて特定される上り下りの開始ラベル(下りのLPについて仮想ラベルが必要であれば当該仮想ラベルも含む。以下同じ。)を含む最適LP通知をクライアント側のエッジルータに送信する(ステップS71)。クライアント側のエッジルータは、LP管理サーバ3から上り下りの開始ラベルを含む最適LP通知を受信し(ステップS73)、上り下りの開始ラベルを含むようにステップS35で受信したリクエストを変更し、上り下りの開始ラベル及び宛先サーバのIPアドレス等を含むリクエストを宛先サーバ宛に送信する(ステップS75)。なお、クライアント側のエッジルータは、上りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、上りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信したリクエストの上りの開始ラベルを次のラベルで置換してリクエストを更に次のルータに送出する。これを繰り返してサーバ側のエッジルータまで到達する。
サーバ側のエッジルータは、前のルータから、上りのラベル、下りの開始ラベル及び宛先サーバのIPアドレスを含むリクエストを受信し(ステップS77)、下りの開始ラベル及び要求元IPアドレスを例えばメインメモリなどの記憶装置に格納する(ステップS79)。そして、宛先サーバのIPアドレスによりリクエストの送出先を特定し、当該リクエストを宛先サーバに転送する(ステップS81)。
宛先のサーバは、サーバ側エッジルータからリクエストを受信し(ステップS83)、所定の処理を実施し、応答を生成して送信する(ステップS85)。サーバ側エッジルータは、宛先サーバから応答を受信する(ステップS87)。処理は端子D及びEを介して図19の処理に移行する。
サーバ側エッジルータは、ステップS79において格納された下りの開始ラベルを特定し、当該開始ラベル及び要求元のIPアドレスを含む応答を生成し、開始ラベルに従って送信する(ステップS89)。サーバ側エッジルータは、下りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、下りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信した応答における下りの開始ラベルを次のラベルで置換して当該応答を更に次のルータに送出する。これを繰り返してクライアント側のエッジルータまで到達する。クライアント側のエッジルータは、下りのラベル及び要求元IPアドレスを含む応答を受信し(ステップS91)、要求元IPアドレスにより当該応答をクライアント端末に転送する(ステップS93)。クライアント端末は、クライアント側のエッジルータから応答を受信し、例えばWebブラウザで表示装置に表示する(ステップS95)。
このような処理を行うことにより、LP管理サーバ3が決定した最適なLPに従って、クライアント端末と宛先サーバとの通信が行われるようになる。従って、ネットワーク全体においても効率的な通信が行われるようになる。
上で述べた例では、宛先サーバが1つに特定される場合を説明したが、同様の処理を実施するサーバが広域的に分散配置されている場合もある。このような場合に行われる処理について図20乃至図24を用いて説明する。
まず、クライアント端末の例えばWebブラウザは、URLを含むIPアドレスの問い合わせをDDNSに対して送信する(ステップS101)。そうすると、クライアント側のエッジルータは、クライアント端末からURLを含むIPアドレスの問い合わせを受信し、DDNSに転送する(ステップS103)。クライアント側のエッジルータとDDNSとの通信は頻繁に発生するので、予めLP管理サーバ3により指定されたLP及びRLPのデータ(LPの最初のラベル及びRLPの最初のラベル及び必要ならば仮想ラベル。なお本データは随時更新されるものとする。)をクライアント側のエッジルータが保持しており、当該LP及びRLPのデータを用いて転送を行うものとする。DDNSは、クライアント側のエッジルータからURLを含むIPアドレスの問い合わせを受信すると(ステップS105)、URLに対応するIPアドレス候補群を検索して抽出し、当該IPアドレス候補群の各々に対してサーバ負荷の問い合わせを送信する(ステップS107)。宛先サーバ群の各々のサーバは、サーバ負荷の問い合わせをDDNSから受信すると(ステップS109)、サーバ負荷情報を生成し、DDNSに返信する(ステップS111)。DDNSは、宛先サーバ群の各々からサーバ負荷情報を受信し、例えばメインメモリ等の記憶装置に格納する(ステップS113)。
そして、DDNSは、要求元情報(例えばクライアント端末のIPアドレス又は要求元エッジルータのアドレス/識別情報(ID))、サーバ負荷情報及び宛先サーバの情報(IPアドレス及びサーバタイプ情報)等を含む最適サーバ選択要求をLP管理サーバ3に送信する(ステップS115)。LP管理サーバ3は、DDNSから要求元情報、サーバ負荷情報及び宛先サーバの情報等を含む最適サーバ選択要求を受信し(ステップS117)、最適サーバ決定処理を実施する(ステップS119)。この最適サーバ決定処理については図21及び図22を用いて説明する。
まず、LP管理サーバ3は、要求元情報(例えば要求元エッジルータのアドレス等)及び宛先サーバ情報(IPアドレス等)に基づき両端のエッジルータを特定し、LPテーブル(図9)を参照して当該両端のエッジルータからLP群を抽出する(ステップS121)。ここでは、各宛先サーバについてLP群を抽出するものとする。
その後、宛先サーバ情報に含まれるサーバタイプなどに基づき、ルーティングポリシーを決定する(ステップS123)。例えば、宛先サーバが、Webサーバというサーバタイプを有する場合、ダウンロード用のサーバというサーバタイプを有する場合、下り優先というルーティングポリシーが決定される。また、宛先サーバが、アップロード用のサーバというサーバタイプを有する場合、上り優先というルーティングポリシーが決定される。さらに、宛先サーバが、オンラインデータ処理用のサーバというサーバタイプを有する場合、上り下り優先というサーバタイプが決定される。
従って、ルーティングポリシーが下り優先であれば(ステップS125:Yesルート)、各サーバについてサーバ負荷情報に含まれるサーバ応答動的帯域Toと当該サーバについてのLP群に係る下り最大動的透過帯域BdDbのうち最小値を指標として特定する(ステップS127)。例えば図22(a)の例では、サーバS1、サーバS2及びサーバS3という3つのサーバが候補として抽出されており、各サーバについてサーバ応答動的帯域Toと、各サーバに対応するLP群における下り最大動的透過帯域BdDbとが列挙されている。そして、サーバ応答動的帯域Toと下り最大動的透過帯域BdDbとのうち小さい方が指標として決定される。図22(a)の例では、サーバS1については80と30とのうち30が指標として決定される。また、サーバS2については60と50とのうち50が指標として決定される。さらに、サーバS3については40と50とのうち40が指標として決定される。次に、特定された指標のうち最大値を有するサーバ及び下り最大動的透過帯域BdDbを有するLPとを特定する(ステップS129)。そして元の処理に戻る。
一方、ルーティングポリシーが上り優先であれば(ステップS125:Noルート及びステップS131:Yesルート)、各サーバについてサーバ負荷情報に含まれるサーバ入力動的帯域Tiと当該サーバについてのLP群に係る上り最大動的透過帯域BdUbのうち最小値を指標として特定する(ステップS133)。例えば図22(b)の例では、サーバS1、サーバS2及びサーバS3という3つのサーバが候補として抽出されており、各サーバについてサーバ入力動的帯域Tiと、各サーバに対応するLP群における上り最大動的透過帯域BdUbとが列挙されている。そして、サーバ入力動的帯域Tiと上り最大動的透過帯域BdUbとのうち小さい方が指標として決定される。図22(b)の例では、サーバS1については60と50とのうち50が指標として決定される。また、サーバS2については40と60とのうち40が指標として決定される。さらに、サーバS3については20と40とのうち20が指標として決定される。次に、特定された指標のうち最大値を有するサーバ及び上り最大動的透過帯域BdUbを有するLPとを特定する(ステップS135)。そして元の処理に戻る。
さらに、ルーティングポリシーが上り下り優先であれば(ステップS125:Noルート及びステップS131:Noルート)、各サーバについてサーバ負荷情報に含まれるサーバ応答動的帯域Toと当該サーバについてのLP群に係る下り最大動的透過帯域BdDbのうち最小値を第1の指標D1として特定する(ステップS137)。例えば図22(c)の例では、サーバS1、サーバS2及びサーバS3という3つのサーバが候補として抽出されており、各サーバについてサーバ応答動的帯域Toと、各サーバに対応するLP群における下り最大動的透過帯域BdDbとが列挙されている。そして、サーバ応答動的帯域Toと下り最大動的透過帯域BdDbとのうち小さい方が第1の指標D1として決定される。図22(c)の例では、サーバS1については120と30とのうち30が第1の指標D1として決定される。また、サーバS2については80と50とのうち50が第1の指標D1として決定される。さらに、サーバS3については40と50とのうち40が第1の指標D1として決定される。
また、各サーバについてサーバ負荷情報に含まれるサーバ入力動的帯域Tiと当該サーバについてのLP群に係る上り最大動的透過帯域BdUbのうち最小値を第2の指標U1として特定する(ステップS139)。例えば図22(c)の例では、各サーバについてサーバ入力動的帯域Tiと、各サーバに対応するLP群における上り最大動的透過帯域BdUbとが列挙されている。そして、サーバ入力動的帯域Tiと上り最大動的透過帯域BdUbとのうち小さい方が指標として決定される。図22(c)の例では、サーバS1については60と50とのうち50が第2の指標U1として決定される。また、サーバS2については40と60とのうち40が第2の指標U1として決定される。さらに、サーバS3については20と40とのうち20が第2の指標U1として決定される。
そして、各サーバについて第1の指標D1と第2の指標U1のうち最小値を第3の指標として特定する(ステップS141)。図22(c)の例では、サーバS1については30と50とのうち30が第3の指標として決定され、サーバS2については50と40とのうち40が第3の指標として決定され、サーバS3については40と20とのうち20が第3の指標として決定される。
最後に、特定された第3の指標のうち最大値を有するサーバ並びに上り最大動的透過帯域BdUbを有するLP及び下り最大動的透過帯域BdDbを有するLPを特定する(ステップS143)。そして元の処理に戻る。
このようにすれば、サーバ負荷を考慮に加えつつ最適なサーバ及びLPを特定することができるようになる。なお図20の処理は端子F、端子G、端子H及び端子Iを介して図23に移行する。
LP管理サーバ3は、最適サーバのIPアドレス及びLPの上り下りの開始ラベル等(RLPについて仮想ラベルが必要であれば当該仮想ラベルを含む。以下同じ。)をメインメモリ等の記憶装置に格納する(ステップS151)。ここでは例えば要求元情報(要求元のエッジルータのIPアドレスや識別情報(ID))を併せて格納する場合もある。そして、最適サーバのIPアドレスをDDNSに返信する(ステップS153)。DDNSは、LP管理サーバ3から最適サーバのIPアドレスを受信すると(ステップS155)、当該最適サーバのIPアドレスをクライアント端末宛に送信する(ステップS157)。クライアント側のエッジルータは、DDNSから最適サーバのIPアドレスを受信すると、クライアント端末に転送する(ステップS159)。クライアント端末は、クライアント側のエッジルータから最適サーバのIPアドレスをDDNSからの応答として受信すると(ステップS161)、当該IPアドレスを含むリクエストを最適サーバ宛に送信する(ステップS163)。
クライアント側のエッジルータは、クライアント端末から宛先サーバのIPアドレスを含むリクエストを受信し(ステップS165)、当該リクエストを例えばバッファなどの記憶装置に格納する。そして、宛先サーバのIPアドレス及び要求元の情報(クライアント端末のIPアドレス又はクライアント側のエッジルータのIPアドレスなど)を含む最適LPの問い合わせをLP管理サーバ3に送信する(ステップS167)。LP管理サーバ3は、クライアント側のエッジルータから宛先サーバのIPアドレス及び要求元の情報を含む最適LPの問い合わせを受信する(ステップS169)。処理は、端子K及び端子Lを介して図24の処理に移行する。
LP管理サーバ3は、記憶装置を参照して宛先IPアドレス及び要求元情報に対応する最適LPを特定し、当該最適LPでLPテーブル(図9)を参照して上り下りの開始ラベルを特定し、当該上り下りの開始ラベルを含む最適LP通知を生成して、クライアント側のエッジルータに返信する(ステップS171)。最適LPは予めステップS151で格納されているので、ここで再度最適LPの特定処理を実施せずとも良い。なお、記憶装置において最適LPが特定できない場合には、図16の処理を実施するようにしても良い。クライアント側のエッジルータは、LP管理サーバ3から、上り下りの開始ラベルを含む最適LP通知を受信すると(ステップS173)、受信した上り下りの開始ラベルを含むようにステップS165で受信したリクエストを変更し、上り下りの開始ラベル及び宛先サーバのIPアドレス等を含むリクエストを宛先サーバ宛に送信する(ステップS175)。なお、クライアント側のエッジルータは、上りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、上りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信したリクエストの上りの開始ラベルを次のラベルで置換してリクエストを更に次のルータに送出する。これを繰り返してサーバ側のエッジルータまで到達する。
サーバ側のエッジルータは、前のルータから、上りのラベル、下りの開始ラベル及び宛先サーバのIPアドレスを含むリクエストを受信し(ステップS177)、下りの開始ラベル及び要求元IPアドレスを例えばメインメモリなどの記憶装置に格納する(ステップS179)。そして、宛先サーバのIPアドレスによりリクエストの送出先を特定し、当該リクエストを宛先サーバに転送する(ステップS181)。
宛先のサーバは、サーバ側エッジルータからリクエストを受信し(ステップS183)、所定の処理を実施し、応答を生成して送信する(ステップS185)。サーバ側エッジルータは、宛先サーバから応答を受信する(ステップS187)。処理は端子D及びEを介して図19の処理に移行する。図19は上で説明しているので、ここでは説明を省略する。
このような処理を実施することにより、宛先サーバが広域に分散配置されているような場合においてもサーバの負荷及びネットワークの現況を併せて考慮して最適なルーティングが行われるようになる。
なお、ステップS167においてクライアント側のエッジルータがLP管理サーバ3に最適LPの問い合わせを送信するような構成を示したが、例えば最適LPが決定された段階においてLP管理サーバ3からクライアント側のエッジルータに事前に最適LPを通知しておくような構成であってもよい。
以上本発明の一実施の形態を説明したが、本発明のこれに限定されるものではない。例えば、最適サーバ及びLPを特定するための処理において指標を特定しているが、他の算式を定義して当該算式によって算出された指標値を判断の基準に用いるようにしても良い。
また、上で述べたルーティングポリシーについても一例であって他のルーティングポリシーを定義しても良い。その際にはルーティングポリシーの定義に合わせたLPや最適サーバを特定する必要がある。
さらに、LP管理サーバ3については、複数のコンピュータにより並列処理するような構成であってもよい。
なお、LP管理サーバ3は図25に示すようなコンピュータ装置であって、メモリ2501(記憶装置)とCPU2503(処理装置)とハードディスク・ドライブ(HDD)2505と表示装置2509に接続される表示制御部2507とリムーバブル・ディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。必要に応じてCPU2503は、表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ2501に格納され、必要があればHDD2505に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウエアとOS及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
(付記1)
特定のネットワークにおける任意のノード間のパスの管理を行う管理サーバにより実行される情報処理方法であって、
前記パスを構成する各リンクの使用状況に関するデータを前記特定のネットワークにおける関連ノードから取得するステップと、
前記パスを構成する各リンクの使用状況に関するデータを用いて前記パス全体の動的透過帯域の値を算出し、管理データ格納部に登録する帯域算出ステップと、
を含む情報処理方法。
(付記2)
前記パスを構成する各リンクの使用状況に関するデータが、各前記リンクの使用率であり、
前記帯域算出ステップが、
前記リンクの使用率を用いて、待ち行列モデルに従って各前記リンクの動的な帯域幅の値を算出するステップと、
各前記リンクの動的な帯域幅の値から前記パス全体の動的透過帯域幅の値を算出し、前記管理データ格納部に登録するステップと、
を含む付記1記載の情報処理方法。
(付記3)
前記パスを構成する各リンクに一意のラベルが付されており、
前記管理データ格納部において、前記パスと当該パスを構成する各リンクのラベルとが対応付けられており、
前記特定のネットワークにおけるノードにおいて、前記ラベルから当該ラベルに係るリンクを含む前記パスにおける次のラベルを特定するためのデータによりパケットのルーティングが制御される
ことを特徴とする付記1記載の情報処理方法。
(付記4)
前記パスを構成する各リンクにラベルが付されており、
複数のパスにおいて共用される特定のリンクについては同一のラベルが付されており、
前記管理データ格納部において、前記パスと当該パスを構成する各リンクのラベルと前記パスを構成するリンクが前記特定のリンクを含む場合には前記パスの逆方向においてリンクの分岐を特定するためのデータとが対応付けられており、
前記特定のネットワークにおけるノードにおいて、前記ラベルから当該ラベルに係るリンクを含む前記パスにおける次のラベルを特定し、前記ノードが前記特定のリンクの下り方向の分岐側に位置する場合には前記リンクの分岐を特定するためのデータと前記ラベルとから当該ラベルに係るリンクを含む前記パスにおける次のラベルを特定するためのデータによりパケットのルーティングが制御される
ことを特徴とする付記1記載の情報処理方法。
(付記5)
前記管理データ格納部において、特定の2ノード間について静的又は動的透過帯域幅の値に基づき所定数のパスのみを管理することを特徴とする付記1記載の情報処理方法。
(付記6)
前記パスを構成するリンクのうち動的な帯域幅の値が最も小さいリンクを特定するステップと、
特定された前記リンクに関連するノードに対し、重点監視指示を送信するステップと、
をさらに含む付記2記載の情報処理方法。
(付記7)
特定のネットワークにおける任意のノード間の複数のパスについて動的透過帯域を管理するためのデータ格納部を有する管理サーバにより実行される情報処理方法であって、
パケットの送信先に関するデータを含むパス設定要求を受信した場合、当該パスの両端のノード及びルーティング・ポリシーを特定するステップと、
前記データ格納部を参照して、特定された前記パスの両端のノードからパス候補を特定し、特定された前記ルーティング・ポリシーに基づき前記パス候補の中から最適なパスを決定するパス決定ステップと、
前記最適なパスを特定するためのデータをパス設定要求元に送信するステップと、
を含む情報処理方法。
(付記8)
前記パス決定ステップが、
前記データ格納部を参照して、特定された前記パスの両端のノードからパス候補を特定するステップと、
特定された前記ルーティング・ポリシーが上下非対称ルーティングである場合には、前記データ格納部を参照して、前記パス候補の中から上り方向の動的透過帯域幅の値が最大となるパスと下り方向の動的透過帯域幅の値が最大となるパスとを決定するステップと、
を含む付記7記載の情報処理方法。
(付記9)
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが対称ルーティングであって上下方向のトラフィック量の差又は比が所定範囲内であると想定される場合、前記データ格納部を参照して、前記パス候補の中から上下方向の動的透過帯域幅の値が所定の条件を満たすパスを決定するステップと、
をさらに含む付記8記載の情報処理方法。
(付記10)
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが対称ルーティングであって上下方向のトラフィック量の差又は比が所定範囲外であると想定される場合、前記データ格納部を参照して、前記パス候補の中からトラフィック量が多いと想定される方向の動的透過帯域幅の値が最大であるパスを決定するステップと、
をさらに含む付記9記載の情報処理方法。
(付記11)
特定のネットワークにおける任意のノード間の複数のパスについて動的透過帯域を管理するためのデータ格納部を有する管理サーバにより実行される情報処理方法であって、
パケットの送信元及び複数の宛先候補に関するデータと宛先候補の各々のサーバ負荷に関するデータとを含む宛先決定要求を受信した場合、前記パケットの宛先候補に関するデータに基づきルーティング・ポリシーを特定すると共に、前記データ格納部を参照して前記パケットの送信元及び複数の宛先候補に関するデータに基づき前記宛先候補の各々についてパス候補を特定する特定ステップと、
前記データ格納部に格納された、前記宛先候補の各々に対する前記パス候補の動的透過帯域幅の値と前記宛先候補の各々のサーバ負荷に関するデータとに基づき、前記ルーティング・ポリシーに従った最適な宛先候補及びパス候補を決定する決定ステップと、
を含む情報処理方法。
(付記12)
前記パケットの送信元及び複数の宛先候補に関するデータが、前記複数の宛先候補のサーバタイプのデータを含み、
前記特定ステップが、
前記複数の宛先候補のサーバタイプに対応するルーティング・ポリシーを特定するステップ
を含む付記11記載の情報処理方法。
(付記13)
前記特定ステップが、
前記パケットの送信元及び複数の宛先候補に関するデータに基づき、前記宛先候補の各々についてパスを構成する両端のノードを特定するステップと、
前記データ格納部を参照して、前記宛先候補の各々について前記両端のノードから特定される1又は複数のパスを所定の条件に基づきパス候補として選択するステップと、
を含む付記11記載の情報処理方法。
(付記14)
前記決定ステップが、
前記データ格納部に格納された、前記宛先候補の各々に対する前記パス候補の動的透過帯域幅の値と前記宛先候補の各々のサーバ負荷に関するデータとから、前記宛先候補の各々について前記ルーティング・ポリシーに従った指標値を算出する算出ステップと、
算出された前記指標値に基づき最適な宛先候補及びパス候補を決定するステップと、
を含む付記11記載の情報処理方法。
(付記15)
前記算出ステップにおいて、
前記ルーティング・ポリシーが下り優先である場合には、前記宛先候補の各々に対する前記パス候補のうち下り最大動的透過帯域幅の値と当該宛先候補の応答動的透過帯域幅の値とから指標値を算出する
ことを特徴とする付記14記載の情報処理方法。
(付記16)
前記算出ステップにおいて、
前記ルーティング・ポリシーが上り優先である場合には、前記宛先候補の各々に対する前記パス候補のうち上り最大動的透過帯域幅の値と当該宛先候補の入力動的透過帯域幅の値とから指標値を算出する
ことを特徴とする付記14記載の情報処理方法。
(付記17)
前記算出ステップにおいて、
前記ルーティング・ポリシーが上下優先である場合には、前記宛先候補の各々に対する前記パス候補のうち下り最大動的透過帯域幅の値と当該宛先候補の応答動的透過帯域幅の値とから第1の指標値を算出し、前記宛先候補の各々に対する前記パス候補のうち上り最大動的透過帯域幅の値と当該宛先候補の入力動的透過帯域幅の値とから第2の指標値を算出し、前記第1及び第2の指標値から第3の指標値を算出する
ことを特徴とする付記14記載の情報処理方法。
(付記18)
付記1乃至17記載の情報処理方法をコンピュータに実行させるためのプログラム。
(付記19)
特定のネットワークにおける任意のノード間のパスの管理を行う管理サーバであって、
前記パスを構成する各リンクの使用状況に関するデータを前記特定のネットワークにおける関連ノードから取得する手段と、
前記パスを構成する各リンクの使用状況に関するデータを用いて前記パス全体の動的透過帯域幅の値を算出し、管理データ格納部に登録する帯域算出手段と、
を有する管理サーバ。
(付記20)
特定のネットワークにおける任意のノード間の複数のパスについて動的透過帯域を管理するためのデータ格納部を有する管理サーバであって、
パケットの送信先に関するデータを含むパス設定要求を受信した場合、当該パスの両端のノード及びルーティング・ポリシーを特定する手段と、
前記データ格納部を参照して、特定された前記パスの両端のノードからパス候補を特定し、特定された前記ルーティング・ポリシーに基づき前記パス候補の中から最適なパスを決定するパス決定手段と、
前記最適なパスを特定するためのデータをパス設定要求元に送信する手段と、
を有する管理サーバ。
(付記21)
特定のネットワークにおける任意のノード間の複数のパスについて動的透過帯域を管理するためのデータ格納部を有する管理サーバであって、
パケットの送信元及び複数の宛先候補に関するデータと宛先候補の各々のサーバ負荷に関するデータとを含む宛先特定要求を受信した場合、前記パケットの宛先候補に関するデータに基づきルーティング・ポリシーを特定すると共に、前記データ格納部を参照して前記パケットの送信元及び複数の宛先候補に関するデータに基づき前記宛先候補の各々についてパス候補を特定する特定手段と、
前記データ格納部に格納された、前記宛先候補の各々に対する前記パス候補の動的透過帯域幅の値と前記宛先候補の各々のサーバ負荷に関するデータとに基づき、前記ルーティング・ポリシーに従った最適な宛先候補及びパス候補を決定する決定手段と、
を有する管理サーバ。
(付記22)
特定のネットワークにおける任意のノード間のパスの管理を行う管理サーバの指示に応じたルーティングを行うルータであって、
データ格納部と、
前記データ格納部を参照し、前記管理サーバによって指定されたパスに含まれるリンクに関するデータに従ってパケットのルーティングを行うルーティング手段と、
を有し、
前記パスを構成する各リンクにラベルが付されており、
複数のパスにおいて共用される特定のリンクについては同一のラベルが付されており、
前記リンクに関するデータは前記ラベルであり、
前記データ格納部は、
前記ラベルから当該ラベルに係るリンクを含む前記パスにおける次のラベルを特定し、本ルータが前記特定のリンクの下り方向の分岐側に位置する場合には前記パスの逆方向においてリンクの分岐を特定するためのデータと前記ラベルとから当該ラベルに係るリンクを含む前記パスにおける次のラベル及び当該次のラベルに係るリンクを特定するためのデータを格納している
ルータ。