本発明の一実施の形態に係るネットワーク概念図を図1に示す。本実施の形態においては、ノードERa(エッジ・ルータ(Edge Router))とノードRa1及びRa2とノードGWRa(ゲートウェイ・ルータ(Gateway Router))等のルータを含むドメインAにLP管理サーバAが接続されており、ノードRb1及びRb2とノードGWRb1,GWRb2,GWRb3,GWRb4等のルータを含むドメインBにLP管理サーバBが接続されており、ノードERcとノードRc1及びRc2とノードGWRc等のルータを含むドメインCにLP管理サーバCが接続されている。また、ノードGWRaとノードGWRb1及びGWRb2とは接続されており、ノードGWRcとノードGWRb3及びGWRb4とは接続されている。なお、発アドレスIPo(所定のサブネットワークのIPアドレス群)のコンピュータ等とのリンクを有するルータ及び着アドレスIPd(所定のサブネットワークのIPアドレス群)のコンピュータ等とのリンクを有するルータをエッジルータER又はノードERと記し、他のドメインのルータと接続するルータをゲートウェイ・ルータGWR又はノードGWRと記す。
LPは、MPLS(Multi Protocol Label Switching)におけるラベルスイッチドパス(Label Switched Path)を省略した記号であって、LP管理サーバA、LP管理サーバB及びLP管理サーバCは、各ドメイン内における任意のノード間の最適な経路(LP)を決定するものである。すなわち、従来技術のように各ノードによってルーティングが制御されるのではなく、ドメイン内におけるルーティングはLP管理サーバにより集中制御されており、図1において点線で示しているように、各ノードは直接的又は間接的にLP管理サーバにより制御されることになる。このような処理のためLP管理サーバの各々は、LPについてのデータを保持するLP−DBを管理している。LP−DBに保持されるデータについては後に詳しく述べる。
ここでドメイン内におけるルーティングの基本的な概念について説明しておく。図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も特定される。すなわち、各ノードにおいて順方向のルーティングが可能となる。尚、優先クラスに関しては優先クラス毎にLPを用意するのではなく、LPのサブセットとして優先クラスを設けるLP方式を前提にしている。
図2(a)ではノードn1からノードn4へのLPを問題としたが、本実施の形態では逆方向RLP(Reverse LP)についても同じラベルを用いる。すなわち、順方向のLPに対して対称な逆方向RLPを用いる。このようにすれば、上り下りについてルーティング情報を共用でき、管理すべきデータ量を減らすことができる。具体的には、逆方向ということが分かって、例えばラベルL3が特定されれば、次のラベルはラベルL2であると特定される。すなわち、各ノードにおいて逆方向のルーティングも可能となる。
但し、このような構成にすると、LPの数及びノード数が増加するほどラベルの数(=LP数×ノード数)も増加するため、管理すべきデータ量が増加する。そこで、本実施の形態では、ラベルマージという考え方を採用する。簡単な例を図3(a)及び(b)に示す。図3(a)に示すように、ノードn10とノードn11とノードn12とノードn13とを含むネットワークにおいて、ノードn10からノードn13への経路をLP10とし、ノードn11からノードn13への経路を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を併せて指定したパケットを送信することになる。仮想ラベルとしては、(a)ドメインに関して一意の順方向LPの先頭ラベル名、(b)発側ネットワークアドレスのパス多重数に対応するラベルのドメイン内において一意なラベル名、(c)発側プレフィックスとパス多重数度に対応するもの等を使用できる。
なお、図3(a)及び(b)は、ドメイン内でのルーティングのみを取り扱うため、ドメイン間のパスを取り扱うためには、後に述べるような付加的な機構が必要となる。
次に図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管理サーバに通知する。但し、使用率の変動が所定範囲内であれば通知を省略する場合もある。なお、以下でも述べるが、ルータ5に接続しているリンクにボトルネックリンクが含まれる場合には、LP管理サーバが重点監視指示を送信してくるので、使用率測定部51は、重点監視指示を受信すると、ボトルネックリンクについての監視周期を短くしたり、所定幅以上使用率に変更があった場合にLP管理サーバに通知する場合には当該所定幅を狭くするなどの処置を講ずる。
次に図2及び図3に示したような基本的な仕組みを実現するためのLP−DBに格納されるデータの一例を図7乃至図9を用いて示す。図7にリンクテーブルの一例を示す。図7の例では、図6と同様に、リンク(Lid)の列と、ラベル(La)の列とが設けられており、リンクと当該リンクに割り当てられたラベルとの対応関係が登録されている。LP−DBにおいては、ネットワーク全体のリンクのデータが登録されている。ネットワークの構成が変更されると、本テーブルのデータについても更新される。
図8にリンクデータ・テーブルの一例を示す。図8の例では、リンク(Lid)の列と、当該リンクの静的な帯域幅(Bs)の列と、当該リンクの両端に接続されるルータのID(RTid)の列と、優先度毎のリンク使用率(Pri-ρ)の列とが設けられている。ここでは説明を簡単にしているため、優先度については0及び1のみが存在するものとしている。ルータ5の使用率測定部51により測定された使用率は管轄LP管理サーバに送信され、本テーブルに登録される。
図9にLPテーブルの一例を示す。図9の例では、発側エッジルータ配下のネットワークアドレス集合(ネットワークアドレスが1つであれば当該ネットワークアドレス。ネットワークアドレスが2つ以上であれば代表ネットワークアドレス)を表す発ネットワークアドレスセット番号(SNo)の列と、着側エッジルータ配下のネットワークアドレス集合を表す着ネットワークアドレスセット番号(SNd)の列と、SNoとSNd間を接続するLPの静的透過帯域順位の列と、障害(上りU/下りD)の状態を表す列と、逆方向LP(RLP)における仮想ラベル(例えばSNoを用いる。逆方向なのでSNoは着側)の列と、LPを構成する各リンクの帯域容量から算出されるLPの静的透過帯域の列と、静的透過帯域についてのボトルネックリンクに対応するラベル(BsBN)の列と、パケットサイズがランダムである場合(M)とパケットサイズ一定の場合(D)のいずれかを登録するための透過帯域計算方式(Cal)の列と、ベストエフォート(0)と最優先(1)との区別を行うための優先度(Pri)の列と、上り側動的透過帯域(BdU)の列と、上り側動的透過帯域についてのボトルネックリンクに対応するラベル(BdUBN)の列と、下り側動的透過帯域(BdD)の列と、下り側動的透過帯域についてのボトルネックリンクに対応するラベル(BdDBN)の列と、ラベルデータの列とを含む。ラベルデータの列には、当該LPを構成するラベル(La)と、当該ラベルに対応するリンクの上り側使用率(ρU)と、当該ラベルに対応するリンクの下り側使用率(ρD)とが含まれる。なお、上でも述べたが優先度については2段階しかない例を示しているが、一般的にはN(Nは正の整数)段階設定することができる。
次に、図2及び図3に示したような基本的な仕組みを実現するためにLP管理サーバにおいて実施される基本的な処理について図10乃至図14Aを用いて説明する。LP管理サーバは、各リンクの帯域幅のデータを取得し、リンクデータ・テーブル(図8)に登録する(ステップS1)。このデータについては、ネットワーク中のノードから自動的に取得しても良いし、管理者の入力データを取得するようにしても良い。次に、LP管理サーバは、別途保持されている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とし、そのときの待ち時間をWrとする。
そうすると、パケットサイズ不定の場合であるM/M/1モデルの場合、Lq=ρ2/(1−ρ)、L=ρ/(1−ρ)、Lr=1/(1−ρ)となる。なお、実際には入力バッファが有限であるから、M/M/N(Nはバッファ長)の方が好ましい。しかし、バッファ長も大きな値をとることができるようになってきており、M/M/1モデルでも十分である。
そして、以下の式が成り立つ。
W=(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−ρ)となる。
そして、以下の式が成り立つ。
W=(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−DBに対するDB更新処理を実施する(ステップS11)。
このDB更新処理については図14Aを用いて説明する。まず、静的ボトルネックリンク(BNL)に対応するルータに対して重点監視指示を送信する(ステップS21)。例えば、各リンクを監視しているルータのデータを別途保持しておき、当該データに基づきステップS9で特定された静的ボトルネックリンクを用いてルータを特定する。なお、重点監視指示を受信したルータの使用率測定部51は、当該静的ボトルネックリンクに対して、通常より監視頻度を上げたり、使用率更新通知の閾値を変更するなどの処理を行う。また、動的ボトルネックリンク(BNL)に対応するルータに対して重点監視指示を送信する(ステップS23)。ステップS21と同様の処理が行われる。なお、静的ボトルネックリンクと動的ボトルネックリンクが同一である場合にはステップS23をスキップしてもよい。
その後、ドメイン内の各ノード(ルータ)からの使用率更新通知を待つ(ステップS25)。そして、いずれかのノードから使用率更新通知を受信すると、当該使用率のデータをリンクデータ・テーブル(図8)及びLPテーブル(図9)に登録すると共に、使用率が更新されたリンクに関連するLPについて動的透過帯域を算出し、LPテーブル(図9)に登録する(ステップS27)。動的透過帯域の算出については、図10のステップS7と同じであるからここでは説明を省略する。ステップS27では、LPのいずれのラベル(リンク)がボトルネックリンク(BNL)であるかが分かるので、当該ボトルネックリンクのラベルを特定する(ステップS29)。そして、LPテーブル(図9)に登録されたボトルネックリンクと、今回特定されたボトルネックリンクとが同一であるか、すなわちボトルネックリンクの移動があるか判断する(ステップS31)。もしボトルネックリンクの移動がなければステップS25に戻る。
一方、ボトルネックリンクの移動があると判断された場合には、ステップS29で特定されたボトルネックリンクのラベルを、LPテーブル(図9)に登録する(ステップS32)。また、移動したボトルネックリンクに対応するルータに対して重点監視指示を送信する(ステップS33)。ステップS23と同様である。また、LPテーブル(図9)を参照して、前のボトルネックリンクが静的ボトルネックリンクではないか確認し、前のボトルネックリンクが静的ボトルネックリンクではない場合には、重点監視解除通知を、前のボトルネックリンクに対応するルータに送信する(ステップS35)。重点監視解除通知を受信したルータは、通常の使用率測定に戻る。すなわち、測定周期をデフォルトの期間に戻し、使用率更新通知の閾値を元に戻す等の処理を行う。
このようなステップS25乃至S35を、例えば明示的な処理終了指示の受付など処理終了の条件が満たされるまで繰り返す(ステップS37)。
図14Aのような処理を実施することにより、ネットワークの性能に大きく影響を与えるボトルネックリンクについては監視を強化し、不要な監視オーバーヘッドを減らすことによって、効率的にLPテーブル(図9)を更新することができるようになる。また、ネットワークの現況を踏まえたルーティングも可能になる。なお、関連する全ルータに、現状の透過帯域幅を通知して、ルータ自身に自己がボトルネックリンクに該当するかを判断させ、LP管理サーバに通知させるようにしても良い。
(ドメイン間最適パス構成方式)
図2乃至図14Aを用いてドメイン内におけるルーティングにおける基本的な構成について説明したが、次にドメイン間のルーティングについて拡張した仕組みについて説明する。本実施の形態において、LP管理サーバは、自ドメイン内におけるルーティングの管理を行い、他のドメインについては必要な情報の提供を受けるのみとする。なお、図1に示すようにドメインAのエッジルータからドメインCのエッジルータまでLPを構成する場合、図14Bに示すように、ドメインAはノードERaからノードGWRaまでであって、ドメインBはノードGWRaに接続されたリンクからノードGWRb2までであって、ドメインCはノードGWRb2に接続されたリンクからノードERcまでであるものとする。
図14Bに示したような状態において、ドメインAに接続したコンピュータのIPアドレス群である発アドレスIPoから着アドレスIPdへのLPを構成する場合には、図15に示すような処理を実施する。すなわち、最初にドメインAを管理するLP管理サーバAは、静的透過帯域をベースにドメインAにおける上位LPグループMPLSGsmAを構成する(ステップS41)。具体的には、発アドレスIPoに関連付けられているノードERaから着アドレスIPdのコンピュータが接続されるドメインCに関連付けられたノードGWRaまで、LP−DBに格納された静的透過帯域に基づき上位所定数のLPを構成する。なお、ここで発アドレスに関連するドメインAにおけるLPの最初のラベル(例えばLPa)が、発アドレスIPoから着アドレスIPdまでのLP全体及びドメインA内におけるパスのLP名となる。但し、ラベルのユニーク性がドメイン内でしか保証されない場合には、先頭にドメイン名ASa(Autonomous System)を付すことにより、ドメイン間のルーティングにおいても識別される。
LPの構成結果は、LP管理サーバAに接続されたLP−DBに格納される。LP−DBに格納される、ドメイン間のLPについてのLPテーブルの一例を図16に示す。このデータは、図9のデータ構造を拡張したものであるが、以下の説明で用いられない一部のデータについては省略されている。図16の例では、発側エッジルータ配下のネットワークアドレス集合(ネットワークアドレスが1つであれば当該ネットワークアドレス。ネットワークアドレスが2つ以上であれば代表ネットワークアドレス)を表す発ネットワークアドレスセット番号(SNo)の列と、着側エッジルータ配下のネットワークアドレス集合を表す着ネットワークアドレスセット番号(SNd)の列と、LPの順位(LP#)の列と、LPを構成する、自ドメイン内の各リンクの帯域容量から算出されるLPの静的透過帯域(Bsa)の列と、LP全体の静的透過帯域(Bstotal)の列と、自ドメインにおける上り側動的透過帯域(BdUa)の列と、自ドメインにおける下り側動的透過帯域(BdDa)の列と、LP全体の上り側動的透過帯域(BdUtotal)の列と、LP全体の下り側動的透過帯域(BdDtotal)の列と、ラベルデータの列とを含む。ラベルデータの列には、当該LPを構成する自ドメイン内のラベル(La)と、当該ラベルに対応するリンクの上り側使用率(ρU)と、当該ラベルに対応するリンクの下り側使用率(ρD)とが含まれる。なお、ドメインA内については上記データ・セットを取得できるのでLP−DBに登録するが、それ以外のドメイン内についてのデータは取得できないので、関連するドメインにつき取得できるデータを登録する。図14Bの例では、ドメインBについてのデータとしては、ノードGWRaからのリンクに付されたラベル(ASb.LPb1)及びドメインBにおけるある時点の上り及び下り動的透過帯域が登録され、ドメインCについてのデータとしてはドメインCを特定するためのデータ(例えばLP管理サーバCのアドレス、ドメインCにおける最初のリンクのラベル)及びドメインCにおけるある時点の上り及び下り動的透過帯域が登録される。動的透過帯域のデータについては図15の処理フローにおいては登録されず、ドメインA内における動的透過帯域のデータについては例えば図14Aに従って自動的に随時更新され、他のドメインについての動的透過帯域は実際のルーティングが必要となった時に登録する。また、本ステップまででは、ドメインB及びドメインCについてのデータについては登録されない。
LP管理サーバB及びLP管理サーバCに接続されたLP−DBにも同様のデータが登録される。但し、LP管理サーバBのLP−DBにおいては、ドメインAについてのデータはドメインAと接続するためのデータ(LP名、ノードGWRaとのリンクに付されたラベル)を含み、ドメインCについてのデータはノードGWRb2からのリンクに付されたラベルを含む。また、LP管理サーバCのLP−DBにおいては、ドメインAについてのデータはドメインAを特定するためのデータ(LP名等)を含み、ドメインBについてのデータはノードGWRb2からのリンクに付されたラベルを含む。発アドレスに関連するドメインA以外のドメインでは他のドメインにおける動的透過帯域は必要とされない。
図15の説明に戻って、次にドメインAを管理するLP管理サーバAは、ノードGWRaに接続されているドメインBのLP管理サーバBに、構成依頼を送信する(ステップS43)。構成依頼には、発アドレスIPo及び着アドレスIPdと、上位LPグループMPLSGsmAに含まれるLP毎にLP名(ASa.LPa等)とドメインAにおける最終接続ノードであるノードGWRaのIPアドレスと静的透過帯域のデータとを含む。
ドメインBを管理するLP管理サーバBは、LP管理サーバAから構成依頼を受信し(ステップS45)、構成依頼に含まれるドメインAにおける静的透過帯域を含む通算の静的透過帯域をベースにドメインBにおける上位LPグループMPLSGsmBを構成する(ステップS47)。具体的には、ノードGWRaから着アドレスIPdのコンピュータが接続されるドメインCに関連付けられているノードGWRb2まで、構成依頼に含まれるドメインAにおける静的透過帯域とLP−DBに格納されているドメインB内における静的透過帯域とを含む通算の静的透過帯域に基づき上位所定数のLPを構成する。ここではLPbをドメインB内のLP名とする。構成結果については、LP管理サーバBに接続されたLP−DBに格納される。
さらに、ドメインBを管理するLP管理サーバBは、ノードGWRb2に接続されているドメインCのLP管理サーバCに、構成依頼を送信する(ステップS49)。構成依頼には、発アドレスIPo及び着アドレスIPdと、受信した構成依頼に含まれる上位LPグループのLP毎にLP名(ASa.LPa等)とドメインBにおける最終接続ノードであるノードGWRb2のIPアドレスと通算の静的透過帯域のデータとを含む。
ドメインCを管理するLP管理サーバCは、LP管理サーバBから構成依頼を受信し(ステップS51)、ドメインA及びドメインBについての静的透過帯域を含む通算の静的透過帯域をベースにドメインCにおける上位LPグループMPLSGsmCを構成する(ステップS53)。具体的には、ノードGWRb2から着アドレスIPdのコンピュータが接続されるノードERcまで、構成依頼に含まれるドメインA及びBの静的透過帯域とLP−DBに格納されたドメイン内の静的透過帯域とを含む通算の静的透過帯域に基づき上位所定数のLPを構成する。ここではLPcをドメインC内のLP名とする。構成結果については、LP管理サーバCに接続されたLP−DBに格納される。
ここまでLPの構成を実施すると、ドメインA内、ドメインAとドメインBの間、ドメインB内、ドメインBとドメインCの間、ドメインC内のパスが決定されるので、ドメインCを管理するLP管理サーバCは、ドメインCの構成情報をドメインBのLP管理サーバBに送信する(ステップS55)。ドメインCの構成情報には、発アドレスIPo及び着アドレスIPdと、受信した構成依頼に含まれる上位LPグループのLP毎にLP名(ASa.LPa等)とドメインCにおける最初の接続ノードであるノードGWRcのIPアドレスと通算の静的透過帯域のデータ(場合によってはドメインCにおける静的透過帯域のデータ)とドメインBの最終接続ノードGWRb2に接続する最初のリンクのラベル(ASc.LPc)とを含む。
さらに、ドメインCを管理するLP管理サーバCは、上位LPグループMPLSGsmCに含まれるLPに関連する、自ドメイン内のノードに対して、ラベルデータを配布してラベルマップ54に格納する(ステップS57)。ノードERcにおけるラベルマップ54に格納されるデータの一例を図17に示す。図17の例では、左から、第1のラベルの列と、仮想ラベルの列と、第2のラベルの列とが設けられており、仮想ラベルは図5とは異なり2列となる。本実施の形態では、ドメイン内の逆方向ルーティングのためのデータとしてドメインCにおける最初のリンクのラベル(ここでは2つのLPがIPo及びIPd間に構成されたものとしてLPc1又はLPc2)と、ドメイン間の逆方向ルーティングのためのデータとしてLP名(ここでは2つのLPがIPo及びIPd間に構成されたものとしてASa.LPa1又はASa.LPa2)とを含む。複数のドメインに渡るLPを構成した場合には、この2つのデータを用いて適切に分岐させる必要があるためである。なお、順方向のルーティングにおいては、第1のラベルから第2のラベルを特定して、第2のラベルに対応するリンクを抽出する。逆方向のルーティングにおいては、第2のラベル及び仮想ラベルから第1のラベルを特定する。すなわち、図3(b)の逆方向ルーティングにおいては、仮想ラベルL11rだけではなく、ASa.LPa1又はASa.LPa2を合わせて用いてルーティングを行う。但し、図14Bのような例において、ノードERcでは仮想ラベルは本来不要であるが、ここではドメインC内のノードの例として記している。
また、ノードGWRcにおけるラベルマップ54に格納されるデータの一例を図18に示す。基本的な構造は図17の例と同一である。第1のラベルについては、ドメインBと接続するリンクとなるので、ASc.LPc1又はASc.LPc2というように、ドメイン名及びドメインC内のLP名とで構成されるラベルが登録されている。なお、ドメイン内の中継ノードは省略されているので、図17の第1ラベルと図18の第2ラベルは一致しない。
ステップS55の構成情報の送信に応答して、ドメインBを管理するLP管理サーバBは、ドメインCのLP管理サーバCからドメインCにおける構成情報を受信し(ステップS59)、ドメインCとの関係を表すデータをLP−DBに登録する(ステップS61)。具体的には、発アドレスIPo及び着アドレスIPdとLP名との組み合わせからレコードを特定し、ドメインBの最終接続ノードGWRb2に接続するリンクのラベル(ASc.LPc)及び通算の静的透過帯域のデータ等を登録する。
そして、ドメインBのLP管理サーバBは、ドメインBの構成情報を、ドメインAを管理するLP管理サーバAに送信する(ステップS63)。ドメインBの構成情報には、発アドレスIPo及び着アドレスIPdと、構成情報に含まれる上位LPグループのLP毎にLP名(ASa.LPa等)とドメインBにおける最初の接続ノードであるノードGWRb1のIPアドレスと通算の静的透過帯域のデータ(場合によってはドメインB及びCにおける各静的透過帯域のデータ)とドメインAの最終接続ノードGWRaに接続する最初のリンクのラベル(ASb.LPb等)とを含む。
さらに、ドメインBのLP管理サーバBは、上位LPグループMPLSGsmBに含まれるLPに関連する、自ドメイン内のノードに対して、ラベルデータ等を配布してラベルマップ54に格納する(ステップS65)。ノードGWRb2におけるラベルマップ54に格納されるデータの一例を図19に示す。データ構造は図17と同じである。但し、ドメインBにおける仮想ラベルとしては、ドメイン内の逆方向ルーティングのためのデータとしてドメインBにおける最初のリンクのラベル(LPb1又はLPb2)と、ドメイン間の逆方向ルーティングのためのデータとしてLP名(ASa.LPa1又はASa.LPa2)とを含む。ノードGWRcと接続されるノードであるため、図18の第1のラベルと図19の第2のラベルは同一となる。なお、ドメインCにおける最初の接続ノードであるノードGWRcのIPアドレスについては、ノードGWRb2においてラベルとリンクとを対応付ける際に必要な場合もあるので、当該ノードGWRb2に通知する。また、ノードGWRb1におけるラベルマップ54に格納されるデータの一例を図20に示す。基本的な構造は図18の例と同一である。なお、ドメイン内の中継ノードは省略されているので図19の第1ラベルと図20の第2ラベルとは一致しない。
ステップS63の構成情報の送信に応答して、ドメインAを管理するLP管理サーバAは、ドメインBのLP管理サーバBからドメインBにおける構成情報を受信し(ステップS67)、ドメインBとの関係を表すデータをLP−DBに登録する(ステップS69)。具体的には、発アドレスIPo及び着アドレスIPdとLPとの組み合わせからレコードを特定し、ドメインAの最終接続ノードGWRaに接続するリンクのラベル(ASb.LPb)及び通算の静的透過帯域のデータを登録する。
そして、ドメインAのLP管理サーバは、上位LPグループMPLSGsmAに含まれるLPに関連する、自ドメイン内のノードに対して、ラベルデータ等を配布してラベルマップ54に格納する(ステップS71)。ノードGWRaにおけるラベルマップ54に格納されるデータの一例を図21に示す。図21の例では、仮想ラベルがドメインAにおける最初のラベル(LPa1又はLPb2)だけとなる。これは既に逆方向ルーティングにおける目的のドメインであるためドメイン間のルーティングを考慮する必要がないためである。なお、ノードGWRb1と接続されるノードであるため、図20の第1のラベルと図21の第2のラベルは同一となる。また、ドメインBにおける最初の接続ノードであるノードGWRb1のIPアドレスについては、ノードGWRaにおいてラベルとリンクとを対応付ける際に必要な場合もあるので、当該ノードGWRaに通知する。また、ノードERaにおけるラベルマップ54に格納されるデータの一例を図22に示す。すでに逆方向ルーティングにおける目的の発アドレスIPoに直接ルーティングできるので、仮想ラベルは登録されない。なお、ドメイン内の中継ノードは省略されているので図21の第1ラベルと図22の第2ラベルとは一致しない。
以上のような処理を行うことによって、ドメイン間におけるルーティングを行うための前処理が完了する。なお、全ての発アドレスIPo及び着アドレスIPdについて処理を行っておく。
次に、図23乃至図28を用いて、実際にルーティングが行われる段階における処理を説明する。まず、ルーティングの前処理として、クライアント端末の例えばWebブラウザから、URLを含むIPアドレスの問い合わせがDNSに対して送信される。そうすると、ノードERa(クライアント端末側のエッジルータ)は、クライアント端末からURLを含むIPアドレスの問い合わせを受信し、DNSに転送する。ノードERaとDNSとの通信は頻繁に発生するので、予めLP管理サーバAにより指定されたLP及びRLPのデータ(LPの最初のラベル及びRLPの最初のラベル及び必要ならば仮想ラベル。なお本データは随時更新されるものとする。)をノードERaが保持しており、当該LP及びRLPのデータを用いて転送を行うものとする。DNSは、ノードERaからURLを含むIPアドレスの問い合わせを受信すると、URLに対応するIPアドレスを検索して抽出し、IPアドレス通知を返信する。返信の際には、RLPのデータ(最初のラベル及び必要であれば仮想ラベル)により経路を特定する。ノードERaは、DNSからIPアドレス通知を受信し、要求元のクライアント端末に転送する。クライアント端末のWebブラウザ等は、ノードERaからIPアドレス通知を受信する。
これにて前処理が完了するので、クライアント端末のWebブラウザ等は、自らのIPアドレス(発アドレスIPo)及び受信した着IPアドレスを含むリクエスト(接続要求)を送信する(図23:ステップS81)。例えばHTTP(Hyper Text Transfer Protocol)の場合には、GETメッセージを送信する。ノードERaは、クライアント端末から発IPアドレスIPo及び着IPアドレスIPdを含むリクエストを受信すると当該リクエストのデータを例えばバッファなどの記憶装置に格納し(ステップS83)、発IPアドレスIPoと着IPアドレスIPd及びポート番号等の宛先データとを含む最適LP問い合わせをLP管理サーバAに送信する(ステップS85)。ノードERaとLP管理サーバAとの通信は頻繁に発生するので、予めLP管理サーバAにより指定されたLP及びRLPのデータをノードERaが保持しておき、当該LP及びRLPのデータを用いて転送を行う。
LP管理サーバAは、ノードERaから発IPアドレスIPoと着IPアドレスIPd及びポート番号など宛先データを含む最適LPの問い合わせを受信すると(ステップS87)、発IPアドレスIPo及び着IPアドレスIPdを用いて図16のようなLP−DBを検索し、動的透過帯域を特定する対象となるLP(そのためのレコード)を特定する(ステップS89)。そうすると各LPについて関連するドメインも特定されるため、当該各ドメインのLP管理サーバに、各LP名を含む、各LPの動的透過帯域データ要求を送信する(ステップS91)。LP管理サーバ間のパスも頻繁に用いられるので、予め特定してデータを保持しておく。各LPに関連するドメインのLP管理サーバは、各LPの動的透過帯域データ要求を受信すると(ステップS93)、各LPについて図16に示したLP−DBから自ドメインについての上り及び下りの動的透過帯域データ(例えばBdUb及びBdDb)を読み出し、LP管理サーバAに返信する(ステップS95)。なお、自ドメインについての上り及び下りの動的透過帯域データは、例えば図14Aなどによって自動的にLP−DBに登録される。
LP管理サーバAは、各LPに関連するドメインのLP管理サーバから、各LPの動的透過帯域データを受信し、LP−DB(図16)に登録する(ステップS97)。例えば、LPa1乃至LPa4がステップS89で特定され、これらのLPにつきステップS97において関連するLP管理サーバB及びCから動的透過帯域データを受信したとすると、自ドメインAについてのデータを合わせて図24に示すようなデータが取得されたと仮定する。なお、LPa1乃至LPa4は静的透過帯域の大きい順に並べられている。各LPの総合の動的透過帯域は、最低の動的透過帯域によって制限されるため、LPa1については上りも下りもドメインAの動的透過帯域と同じ値となり、LPa2については上りはドメインBと下りはドメインAの動的透過帯域と同じ値となり、LPa3については上りも下りもドメインAの動的透過帯域と同じ値となり、LPa4についても上りも下りもドメインAの動的透過帯域と同じ値となる。
このような総合動的透過帯域がLP−DBに登録されると、LP管理サーバAは、最適LP決定処理を実施する(ステップS99)。最適LP決定処理については、図25及び図26を用いて説明する。LP管理サーバAは、最適LP問い合わせの宛先データに含まれるポート番号などからルーティングポリシーを決定する(ステップS101)。ここでは、ルーティングポリシーは、非対称ルーティング、トラフィック上下均等の対称ルーティング、トラフィック上下不均等(上りと下りのトラフィック量が例えば2倍以上異なる場合)の対称ルーティングのいずれかである。例えば、上り下りのルーティングが対称である必要の無いものが非対称ルーティングとして判定される。例えば、IPアドレス及びポートから、IP電話、ファイルダウンロード、ファイルアップロード、Webブラウジングといったアプリケーションであることが特定できれば、対称ルーティングが選択されるものとする。IP電話であればトラフィック上下均等の対称ルーティングが選択され、ファイルダウンロード、ファイルアップロード及びWebブラウジングであればトラフィック上下不均等の対称ルーティングが選択されるものとする。
従って、非対称ルーティングが選択されると(ステップS103:Noルート)、LP−DB(図16)を参照して、上り下りそれぞれについて最大動的透過帯域幅を有するLPを選択する(ステップS105)。そして元の処理に戻る。
一方、対称ルーティングであって(ステップS103:Yesルート)、トラフィック上下均等が選択された場合(ステップS107:Yesルート)、ステップS89で特定されたLPのうち上り下りのうちトラフィック量が少ない方の動的透過帯域幅が規定値以下のものを除外する(ステップS109)。なお、残余のLPが存在しないような場合にはステップS105に移行するようにしても良い。そして残余のLPのうち上り下りの動的透過帯域幅の差が最小のLPを選択する(ステップS111)。ステップS111の代わりに、残余のLPのうち上り下りの動的透過帯域幅の平均値が最大となるLPを選択するようにしても良い。そして元の処理に戻る。
さらに、対称ルーティングであって(ステップS103:Yesルート)、トラフィック上下不均等が選択された場合(ステップS107:Noルート)、ステップS89で特定されたLPのうちトラフィックが少ない方向(上り又は下り)のLPで動的透過帯域幅が規定値以下であるものを除外する(ステップS113)。なお、残余のLPが存在しないような場合にはステップS105に移行するようにしても良い。そして、残余のLPのうちトラフィックが多い方向(上り又は下り)のLPで最大の動的透過帯域幅を有するLPを選択する(ステップS115)。そして元の処理に戻る。
このような処理を実施することにより、通信アプリケーションなどにより特定されるルーティングポリシーに従って最適なLPが選択されるようになる。
図26を用いて図25の処理フローを具体的に説明しておく。図26(a)に示すように、LPa1の静的透過帯域(Bstotal)が100で、上り側動的透過帯域(BdUtotal)が40で下り側動的透過帯域(BdDtotal)が3であり、LPa2の静的透過帯域(Bstotal)が80で、上り側動的透過帯域(BdUtotal)が30で下り側動的透過帯域(BdDtotal)が10であり、LPa3の静的透過帯域(Bstotal)が50で、上り側動的透過帯域(BdUtotal)が20で下り側動的透過帯域(BdDtotal)が30であるとする。非対称ルーティングが選択された場合には、図26(b)に示すように、上りについてはLPa1の動的透過帯域幅が最大となり、下りについてはLPa3の動的透過帯域幅が最大となるため、上り下りについてそれぞれ選択される。一方、図26(c)に示すように、トラフィック上下不均等で対称ルーティングが選択された場合、具体的には上りのトラフィック量が下りのトラフィック量より多い場合には、ステップS113で「下り」について規定値以下のLPとしてLPa1を除外し、ステップS115で上りの動的透過帯域幅が最大となるLPa2を選択する。さらに、図26(d)に示すように、トラフィック上下均等で対称ルーティングが選択された場合、ステップS109で図26(d)の例では下りの動的透過帯域が最小となるLPa1を除外し、ステップS111で上り下りの動的透過帯域幅の差が最小となるLPとしてLPa3が選択される。
図23の処理に戻るが、端子B及びCを介して図27の処理に移行する。なお、クライアント端末の処理については端子Aを介して図28の処理に移行する。まず、図27において、LP管理サーバAは、ステップS99において決定されたLPからLP−DB(図16)を用いて特定される上り下りの開始ラベル(下りのLPについて仮想ラベルが必要であれば当該仮想ラベルも含む。以下同じ。)を含む最適LP通知をノードERaに送信する(ステップS121)。ノードERaは、LP管理サーバAから上り下りの開始ラベルを含む最適LP通知を受信し(ステップS123)、上り下りの開始ラベルを含むようにステップS83で受信したリクエストを変更し、上り下りの開始ラベル及び宛先サーバのIPアドレス等を含むリクエストを宛先サーバ宛に送信する(ステップS125)。なお、ノードERaは、上りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、上りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信したリクエストの上りの開始ラベルを次のラベルで置換してリクエストを更に次のルータに送出する。既に上で述べたようなLPの構成処理を実施しているので、これを繰り返せばドメインCのノードERc(サーバ側のエッジルータ)まで到達する。
ノードERcは、前のルータから、上りのラベル、下りの開始ラベル及び宛先サーバのIPアドレスを含むリクエストを受信し(ステップS127)、下りの開始ラベル及び要求元IPアドレスを例えばメインメモリなどの記憶装置に格納する(ステップS129)。そして、宛先サーバのIPアドレスによりリクエストの送出先を特定し、当該リクエストを宛先サーバに転送する(ステップS131)。
宛先のサーバは、ノードERcからリクエストを受信し(ステップS133)、所定の処理を実施し、応答を生成して送信する(ステップS135)。ノードERcは、宛先サーバから応答を受信する(ステップS137)。処理は端子D及びEを介して図28の処理に移行する。
ノードERcは、ステップS129において格納された下りの開始ラベルを特定し、当該開始ラベル及び要求元のIPアドレスを含む応答を生成し、開始ラベルに従って送信する(ステップS139)。ノードERcは、下りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、下りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信した応答における下りの開始ラベルを次のラベルで置換して当該応答を更に次のルータに送出する。下りについても上りと同様に、LPの構成処理を実施しているので、これを繰り返せばノードERaまで到達する。ノードERaは、下りのラベル及び要求元IPアドレスを含む応答を受信し(ステップS141)、要求元IPアドレスにより当該応答をクライアント端末に転送する(ステップS143)。クライアント端末は、クライアント側のエッジルータから応答を受信し、例えばWebブラウザで表示装置に表示する(ステップS145)。
このような処理を行うことにより、LP管理サーバAが決定した最適なLPに従って、クライアント端末と宛先サーバとの通信が行われるようになる。従って、複数のドメインを含むネットワーク全体においても効率的な通信が行われるようになる。また、ドメイン間で必要なデータのやりとりは最小限に抑えられている。
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、最適サーバ及びLPを特定するための処理において指標を特定しているが、他の算式を定義して当該算式によって算出された指標値を判断の基準に用いるようにしても良い。
また、上で述べたルーティングポリシーについても一例であって他のルーティングポリシーを定義しても良い。その際にはルーティングポリシーの定義に合わせたLPや最適サーバを特定する必要がある。
さらに、LP管理サーバA乃至Cについては、複数のコンピュータにより並列処理するような構成であってもよい。
また、ドメイン毎にラベルが管理されており、ドメイン間では重複するラベルが存在しうる場合について説明したが、ドメイン間で重複するラベルが存在しないようにする場合もある。そのような場合には、LPが1つ決まればそれに含まれるラベルは一意に決まるため、ルータにおける仮想ラベルは不要となる。
上記における仮想ラベル付与に関して、ドメイン内及びドメイン間仮想ラベルとして、“発側ネットワークアドレス.パス多重優先順位”に対応する発ドメイン内一意の仮想ラベルを発ドメイン内の仮想ラベルとし、ドメイン間及び発ドメイン以外のドメインについてはこのドメイン内仮想ラベルに発ドメイン名(AS)を付与したものを用いることもできる。この場合は仮想ラベルは1段で足りる。ここでパス多重優先順位とは特定対地(End to End)間で定義されるLPに付与される順位である。例えば図9のLP#欄の値(1、2又は3)になる。
先頭リンク名をドメインに一意なLP名とする方式だと、ラベル数が(接続エッジルータ2)で効いてくるので接続エッジルータ数が、直ぐに頭打ちになる。現行の20bitのラベル容量だと、1000×1000で頭打ちになりパス多重度=1としても1000拠点しか接続できない。仮想ラベルとして発側のアドレス×パス多重度を用いれば、各LPの先頭ラベル名を用いるものと比べて、ラベルの数を大幅に減らすことができ、現行の20bit・4多重パスでも25万拠点をメッシュで接続できる。
上記における仮想ラベル付与に関して、仮想ラベルとして、ドメイン内およびドメイン間仮想ラベルとして、“発側プレフィックス.パス多重優先順位”を仮想ラベルとして、ドメイン内・ドメイン間を共通に利用することもできる。この場合は、仮想ラベルは1段で足り、AS番号付与も不要になる。ここで発側プレフィックスとは、IPアドレスにおいて発側端のネットワークアドレス長表記を含む発側端のネットワークアドレスを示す。
同様に、仮想ラベルとして“発側プレフィックス.パス多重度”を用いれば、各LPの先頭ラベル名を用いるものと比べて、ラベルの数を大幅に減らすことができ、現行の24bit(クラスC+4多重パス)で1600万拠点をメッシュで接続できる。しかもドメイン番号(AS)を付与せずにドメイン間利用できる。プレフィックスとはネットワークサイズを含むネットワークアドレス情報である。
なお、LP管理サーバA乃至Cは図29に示すようなコンピュータ装置であって、メモリ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のノードと前記第2のドメインに関連付けられた第2のノードとの間における複数のパスを構成し、当該複数のパスのうち帯域幅が上位所定数のパスを登録パスとして特定し、前記発アドレス及び前記着アドレスと前記登録パスの各々につき登録パスに関するデータとをパスデータ格納部に格納するステップと、
前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの帯域幅のデータ及び前記第2のノードのデータとを含む構成依頼を、前記第2のノードに接続された第3のドメインの管理サーバに送信するステップと、
前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第2のノードと前記第3のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第3のドメインの管理サーバから受信した場合、前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記接続リンクに関するデータを前記パスデータ格納部に格納するステップと、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
を含む情報処理方法。
(付記2)
第4のドメインの管理サーバから、前記特定のドメインとは異なるドメインに関連する発アドレス及び着アドレスと候補パスの各々について当該候補パスの帯域幅のデータ及び前記第4のドメインにおける最終中継ノードのデータとを含む構成依頼を受信した場合、前記特定のドメイン内において、前記最終中継ノードと前記構成依頼に含まれる前記着アドレスが関連する第5のドメインに関連付けられた第3のノードとの間に複数のパスを構成し、当該複数のパスのうち前記構成依頼に含まれる前記帯域幅を考慮した通算の帯域幅が上位所定数のパスを前記特定のドメインにおける登録パスとして特定し、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記特定のドメインにおける登録パスに関するデータとを前記パスデータ格納部に格納するステップと、
前記第3のノードに接続された第6のドメインの管理サーバに、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの前記通算の帯域幅のデータ及び前記第3のノードのデータとを含む構成依頼を送信するステップと、
受信した前記構成依頼に含まれる前記発アドレス及び前記着アドレスと送信した前記構成依頼に含まれる前記登録パスの各々につき前記第3のノードと前記第6のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第6のドメインの管理サーバから受信した場合、前記構成情報通知に含まれる前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記構成情報通知に含まれる前記接続リンクに関するデータを前記パスデータ格納部に格納するステップと、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
前記第4のドメインの管理サーバに、前記構成情報通知に含まれる前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第4のドメインにおける最終中継ノードと前記特定のドメインにおける接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を送信するステップと、
をさらに含む付記1記載の情報処理方法。
(付記3)
第5のドメインの管理サーバから、前記特定のドメインに関連付けられた着アドレス及び前記特定のドメイン以外の第8のドメインに関連する発アドレスと候補パスの各々について当該候補パスの帯域幅のデータ及び前記第7のドメインにおける最終中継ノードのデータとを含む構成依頼を受信した場合、前記特定のドメイン内において、前記最終中継ノードと前記構成依頼に含まれる前記着アドレスに関連するノードとの間に複数のパスを構成し、当該複数のパスのうち前記構成依頼に含まれる前記帯域幅を考慮した通算の帯域幅が上位所定数のパスを前記特定のドメインにおける登録パスとして特定し、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記特定のドメインにおける登録パスに関するデータとを前記パスデータ格納部に格納するステップと、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
前記第7のドメインの管理サーバに、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第7のドメインにおける最終中継ノードと前記特定のドメインにおける接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を送信するステップと、
をさらに含む付記1又は2記載の情報処理方法。
(付記4)
前記パスを構成する先頭リンクに、各ドメインにおいて一意のラベルが付されており、
他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、
前記登録パスに関するデータが、前記登録パスを構成するリンクのラベルを含む
ことを特徴とする付記1乃至3のいずれか1つ記載の情報処理方法。
(付記5)
前記パスを構成する先頭リンクに、複数の所定のドメインにおいて一意のラベルが付されており、
前記登録パスに関するデータが、前記登録パスを構成するリンクのラベルを含む
ことを特徴とする付記1乃至3のいずれか1つ記載の情報処理方法。
(付記6)
前記パスを構成する各リンクに、所属ドメインにおけるラベルが付されており、
他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、
複数のパスにおいて共用される共用リンクについては同一のラベルが付されており、
前記パスデータ格納部において、前記登録パスを構成する、前記特定のドメイン内の各リンクのラベルと、前記登録パスを構成する、前記特定のドメイン内のリンクが前記共用リンクを含む場合には前記登録パスの逆方向においてリンクの分岐方向を特定するためのデータとが対応付けられており、
前記特定のドメインにおけるノードに対するルーティングの設定において、特定のラベルから当該特定のラベルに係るリンクを含む前記登録パスにおける次のリンクを特定するためのデータと、前記特定のドメインが前記登録パスの発アドレスに関連するドメイン以外のドメインであって前記登録パスにおいて共用リンクが含まれる場合には前記特定のドメイン内における逆方向ルーティング時に分岐方向を特定するためのデータ及び前記登録パス全体を特定するためのデータとを、ルーティング・データとしてノードに登録する
ことを特徴とする付記2又は3記載の情報処理方法。
(付記7)
複数のドメインを経由して通信を行う場合において通信の発側ドメインにおける管理サーバにより実行される情報処理方法であって、
パケットの送信元及び送信先に関するデータを含むパス設定要求を受信した場合、前記送信元アドレス及び送信先アドレスに対応して候補パスのデータを格納するパスデータ格納部を参照し、前記パス設定要求に係る候補パスを特定する候補パス特定ステップと、
前記パス設定要求に係る前記送信先に関するデータに基づき、前記パケットについてのルーティング・ポリシーを特定するステップと、
特定された前記候補パス上におけるドメインの管理サーバに対して、管轄ドメイン内における、前記候補パスの動的帯域幅のデータを要求するステップと、
前記候補パス上におけるドメインの管理サーバから、前記管轄ドメイン内における、当該候補パスの動的帯域幅のデータを受信した場合、前記発側ドメインにおける動的帯域幅のデータと前記候補パス上におけるドメインにおける前記動的帯域幅のデータとに基づき前記候補パス全体の動的帯域幅を算出し、記憶装置に格納するステップと、
前記候補パス全体の動的帯域幅及び前記ルーティング・ポリシーに基づき、前記候補パスの中から最適パスを決定するパス決定ステップと、
前記最適パスを特定するためのデータをパス設定要求元に送信するステップと、
を含む情報処理方法。
(付記8)
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが上下非対称ルーティングである場合には、前記候補パスの中から上り方向の動的透過帯域幅の値が最大となるパスと下り方向の動的透過帯域幅の値が最大となるパスとを決定するステップと、
を含む付記7記載の情報処理方法。
(付記9)
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが対称ルーティングであって上下方向のトラフィック量の差又は比が所定範囲内であると想定される場合、前記候補パスの中から上下方向の動的透過帯域幅の値が所定の条件を満たすパスを決定するステップと、
をさらに含む付記8記載の情報処理方法。
(付記10)
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが対称ルーティングであって上下方向のトラフィック量の差又は比が所定範囲外であると想定される場合、前記候補パスの中からトラフィック量が多いと想定される方向の動的透過帯域幅の値が最大であるパスを決定するステップと、
をさらに含む付記9記載の情報処理方法。
(付記11)
付記1乃至10のいずれか1つ記載の情報処理方法をコンピュータに実行させるためのプログラム。
(付記12)
特定のドメインにおける任意のノード間のパスの管理を行う管理サーバであって、
前記特定のドメインに関連する発アドレスと前記特定のドメインとは異なる第2のドメインに関連する着アドレスとの間のパスを構成する場合、前記特定のドメイン内において前記発アドレスに関連する第1のノードと前記第2のドメインに関連付けられた第2のノードとの間における複数のパスを構成し、当該複数のパスのうち帯域幅が上位所定数のパスを登録パスとして特定し、前記発アドレス及び前記着アドレスと前記登録パスの各々につき登録パスに関するデータとをパスデータ格納部に格納する手段と、
前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの帯域幅のデータ及び前記第2のノードのデータとを含む構成依頼を、前記第2のノードに接続された第3のドメインの管理サーバに送信する手段と、
前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第2のノードと前記第3のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第3のドメインの管理サーバから受信した場合、前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記接続リンクに関するデータを前記パスデータ格納部に格納する手段と、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行う手段と、
を有する管理サーバ。
(付記13)
複数のドメインを経由して通信を行う場合において通信の発側ドメインにおける管理サーバであって、
パケットの送信元及び送信先に関するデータを含むパス設定要求を受信した場合、前記送信元アドレス及び送信先アドレスに対応して候補パスのデータを格納するパスデータ格納部を参照し、前記パス設定要求に係る候補パスを特定する候補パス特定ステップと、
前記パス設定要求に係る前記送信先に関するデータに基づき、前記パケットについてのルーティング・ポリシーを特定する手段と、
特定された前記候補パスの経路上におけるドメインの管理サーバに対して、管轄ドメイン内における、前記候補パスの動的帯域幅のデータを要求する手段と、
前記候補パスの経路上におけるドメインの管理サーバから、前記管轄ドメイン内における、当該候補パスの動的帯域幅のデータを受信した場合、前記候補パスについて前記発側ドメインにおける動的帯域幅のデータと前記候補パスの経路上におけるドメインにおける前記動的帯域幅のデータとに基づき前記候補パス全体の動的帯域幅を算出し、記憶装置に格納する手段と、
前記候補パス全体の動的帯域幅及び前記ルーティング・ポリシーに基づき、前記候補パスの中から最適パスを決定する手段と、
前記最適パスを特定するためのデータをパス設定要求元に送信する手段と、
を有する管理サーバ。
(付記14)
特定のドメインにおける任意のノード間のパスの管理を行う管理サーバの指示に応じたルーティングを行うルータであって、
当該ルータを経由するパスを構成するリンクのうち直接接続された入力リンク及び出力リンクについてのラベル対と、ラベルとリンクの対応関係とを格納するデータ格納部と、
前記データ格納部を参照し、受信されたパケットに含まれる入力ラベルに対応する出力ラベル及びリンクを特定し、当該受信されたパケットのルーティングを行うルーティング手段と、
を有し、
複数のパスで共用される共用リンクについては同一のラベルが付されており、
前記データ格納部は、
前記ルータを経由するパスが複数のドメインを経由するパスであって前記ルータが属するドメインが当該パスの発ドメイン以外のドメインである場合には、前記ラベル対に対応して、前記ルータが属するドメイン内における、逆方向ルーティング時に分岐方向を特定するためのデータと前記パス全体を特定するためのデータをさらに格納している
ルータ。