JP4606249B2 - 情報処理方法及びルータ - Google Patents

Description

本発明は、ネットワークにおける経路制御技術に関する。

従来のネットワークにおける経路制御技術においては、（ａ）輻輳ルートが事前に検出できない、（ｂ）上り下りの対称ルーティングを強制的に行えない、（ｃ）サーバ状況をルーティングに反映できない、（ｄ）ルート状況を調べるのに負荷（時間）がかかる、（ｅ）動的処理に負荷がかかり、遅いなどの問題が存在していた。特に近年非常によく用いられるようになったインターネットは、全体の効率化をあまり考慮することなく発展してきたため、非効率な部分を多く内包している。例えば、ルーティングやスイッチングに関しては、自律動作を前提としているためプロトコルは複雑であり、状況そのものが不明である場合が多い。

このような問題を解決すべくＭＰＬＳ（Multi Protocol Label Switching）の応用が検討されているが、（ａ）ドメインによってルーティングポリシーが異なる、（ｂ）ネットワーク状況を他のドメインに公開するのは避けたいという管理者側の要求がある、（ｃ）ＭＰＬＳの相互運用に不安がある、などの理由から、異なるドメイン間におけるルーティングにおいてＭＰＬＳを適用することはなかった。

なお、特開２００２−１２４９７６号公報には、インタードメインのネットワークにおける経路制御において、上で述べたような問題を解決する技術が開示されている。具体的には、インタードメインのネットワークの経路制御において、送信ドメイン、インタードメインのネットワークリソース付の経路情報に加えて、宛先ドメイン内のネットワークリソース付の経路情報を入手可能にすることで、End-to-Endのネットワークリソースを考慮した経路選択が可能で、かつ送信方向だけでなく受信方向の最適な経路選択も可能とする。さらに、ネットワークリソースだけでなく、サービスノードの処理負荷情報を入手可能にすることでネットワークリソースとの両者を用いた最適なサーバの選択ならびにサーバ宛の最適な経路選択が可能となるものである。但し、ＭＰＬＳについては検討されていない。また、この技術はルーティングプロトコルによりルーティングを行うために、ルータの処理負荷が大きい。
特開２００２−１２４９７６号公報

上で述べたように、従来、ＭＰＬＳを適用したドメイン間の経路制御を行うことについては検討されていない。従って、ＭＰＬＳが適用されているドメイン間の通信において、End-to-Endの最適ルーティングを行うことができない、輻輳回避ができない、対称ルーティングができない、といった問題がある。

従って本発明の目的は、ＭＰＬＳを適用してドメイン間のルーティングを可能とするための技術を提供することである。

本発明の第１の態様に係る情報処理方法（管理サーバによるドメイン間パス設定方法）は、特定のドメインにおける任意のノード間のパスの管理を行う管理サーバにより実行される情報処理方法であって、（ａ）特定のドメインに関連する発アドレスと特定のドメインとは異なる第２のドメインに関連する着アドレスとの間のパスを構成する場合、特定のドメイン内において発アドレスに関連する第１のノードと第２のドメインに関連付けられた第２のノードとの間における複数のパスを構成し、当該複数のパスのうち帯域幅が上位所定数のパスを登録パスとして特定し、発アドレス及び着アドレスと登録パスの各々につき登録パスに関するデータとをパスデータ格納部に格納するステップと、（ｂ）発アドレス及び着アドレスと登録パスの各々について登録パスの帯域幅のデータ及び第２のノードのデータとを含む構成依頼を、第２のノードに接続された第３のドメインの管理サーバに送信するステップと、（ｃ）発アドレス及び着アドレスと登録パスの各々につき第２のノードと第３のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、第３のドメインの管理サーバから受信した場合、発アドレス及び着アドレスと登録パスとの組み合わせに対応して上記接続リンクに関するデータをパスデータ格納部に格納するステップと、（ｄ）パスデータ格納部に格納されたデータを用いて、登録パスに関連する、特定のドメイン内のノードに対し、ルーティングのための設定を行うステップとを含む。

このようにドメイン間においてパスを構成する場合には、自ドメインだけではパスを完成できないので、上記パスが関連するドメインの管理サーバに構成依頼を送信すると共に上記パスが関連するドメインの管理サーバから構成情報を受信することにより、パス全体を構成して、自ドメインにおいても隣のドメインへの接続を可能にする。

なお、第１の態様において、上記パスを構成する各先頭リンクに、各ドメインにおいて一意のラベルが付されており、他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、登録パスに関するデータが、登録パスを構成するリンクのラベルを含むようにしてもよい。

さらに、パスを構成する各先頭リンクに、複数の所定のドメインにおいて一意のラベルが付されており、登録パスに関するデータが、登録パスを構成するリンクのラベルを含むようにしてもよい。

又、第１の態様において、上記パスの仮想ラベル（後述）として、各ドメインにおいて一意のラベルが付されており、他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、登録パスに関するデータが、登録パスを構成するリンクのラベルを含むようにしてもよい。

さらに、上記パスの仮想ラベル（後述）として、複数の所定のドメインにおいて一意のラベルが付されており、登録パスに関するデータが、登録パスを構成するリンクのラベルを含むようにしてもよい。

また、本発明の第２の態様に係る情報処理方法（ドメイン間動的最適パス決定方法）は、複数のドメインを経由して通信を行う場合において通信の発側ドメインにおける管理サーバにより実行される情報処理方法であって、（ａ）パケットの送信元及び送信先に関するデータを含むパス設定要求を例えば発側エッジルータから受信した場合、送信元アドレス及び送信先アドレスに対応して候補パスのデータを格納するパスデータ格納部を参照し、パス設定要求に係る候補パスを特定する候補パス特定ステップと、（ｂ）パス設定要求に係る送信先に関するデータに基づき、パケットについてのルーティング・ポリシーを特定するステップと、（ｃ）特定された候補パスの経路上における他の関連ドメインの管理サーバに対して、管轄ドメイン内における、候補パスの動的帯域幅のデータを要求するステップと、（ｄ）候補パスの経路上におけるドメインの管理サーバから、管轄ドメイン内における、当該候補パスの動的帯域幅のデータを受信した場合、候補パスについて発側ドメインにおける動的帯域幅のデータと上記候補パスの経路上におけるドメインにおける動的帯域幅のデータとに基づき候補パス全体の動的帯域幅を算出し、記憶装置に格納するステップと、（ｅ）記憶装置に格納された候補パス全体の動的帯域幅及び上記ルーティング・ポリシーに基づき、候補パスの中から最適パスを決定するステップと、（ｆ）最適パスを特定するためのデータをパス設定要求元に送信するステップとを含む。

このようにすれば実際にパケットを送信する際に、その時の動的帯域幅のデータ及びルーティング・ポリシーを合わせて考慮してパスを決定するため、より適切なルーティングが可能となる。なお、最適パスは、上り及び下りのパスの指定を含む場合もある。

さらに、本発明の第３の態様に係るルータ（ドメイン間パス制御ルータ）は、特定のドメインにおける任意のノード間のパスの管理を行う管理サーバの指示に応じたルーティングを行うルータであって、当該ルータを経由するパスを構成するリンクのうち直接接続された入力リンク及び出力リンクについてのラベル対と、ラベルとリンクの対応関係とを格納するデータ格納部と、データ格納部を参照し、受信されたパケットに含まれる入力ラベルに対応する出力ラベル及びリンクを特定し、当該受信されたパケットのルーティングを行うルーティング手段とを有する。そして、複数のパスで共用される共用リンクについては同一のラベルが付されており、上で述べたデータ格納部は、本ルータを経由するパスが複数のドメインを経由するパスであって本ルータが属するドメインが当該パスの発ドメイン以外のドメインである場合には、ラベル対に対応して、本ルータが属するドメイン内における、逆方向ルーティング時に分岐方向を特定するためのデータとパス全体を特定するためのデータをさらに格納している。

このようなルータをドメイン内に配置することにより、ドメイン内でもドメイン間でもＭＰＬＳを適用した適切なルーティングが行われるようになる。

本発明に係る情報処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、ＭＰＬＳを適用してドメイン間のルーティングを可能とする。

本発明の一実施の形態に係るネットワーク概念図を図１に示す。本実施の形態においては、ノードＥＲａ（エッジ・ルータ（Edge Router））とノードＲa1及びＲa2とノードＧＷＲa（ゲートウェイ・ルータ（Gateway Router））等のルータを含むドメインＡにＬＰ管理サーバＡが接続されており、ノードＲb1及びＲb2とノードＧＷＲb1，ＧＷＲb2，ＧＷＲb3，ＧＷＲb4等のルータを含むドメインＢにＬＰ管理サーバＢが接続されており、ノードＥＲｃとノードＲc1及びＲc2とノードＧＷＲc等のルータを含むドメインＣにＬＰ管理サーバＣが接続されている。また、ノードＧＷＲaとノードＧＷＲb1及びＧＷＲb2とは接続されており、ノードＧＷＲcとノードＧＷＲb3及びＧＷＲb4とは接続されている。なお、発アドレスＩＰo（所定のサブネットワークのＩＰアドレス群）のコンピュータ等とのリンクを有するルータ及び着アドレスＩＰd（所定のサブネットワークのＩＰアドレス群）のコンピュータ等とのリンクを有するルータをエッジルータＥＲ又はノードＥＲと記し、他のドメインのルータと接続するルータをゲートウェイ・ルータＧＷＲ又はノードＧＷＲと記す。

ＬＰは、ＭＰＬＳ（Multi Protocol Label Switching）におけるラベルスイッチドパス（Label Switched Path）を省略した記号であって、ＬＰ管理サーバＡ、ＬＰ管理サーバＢ及びＬＰ管理サーバＣは、各ドメイン内における任意のノード間の最適な経路（ＬＰ）を決定するものである。すなわち、従来技術のように各ノードによってルーティングが制御されるのではなく、ドメイン内におけるルーティングはＬＰ管理サーバにより集中制御されており、図１において点線で示しているように、各ノードは直接的又は間接的にＬＰ管理サーバにより制御されることになる。このような処理のためＬＰ管理サーバの各々は、ＬＰについてのデータを保持するＬＰ−ＤＢを管理している。ＬＰ−ＤＢに保持されるデータについては後に詳しく述べる。

ここでドメイン内におけるルーティングの基本的な概念について説明しておく。図２（ａ）に示すように、ノードｎ１とノードｎ６の間にリンクｌ１０１が設けられ、ノードｎ６とノードｎ７の間にリンクｌ１０２が設けられ、ノードｎ７とノードｎ４の間にリンクｌ１０３が設けられ、ノードｎ６とノードｎ５の間にリンクｌ１０４が設けられ、ノードｎ５とノードｎ７の間にリンクｌ１０５が設けられ、ノードｎ５とノードｎ２の間にリンクｌ１０６が設けられ、ノードｎ５とノードｎ３の間にリンクｌ１０７が設けられ、ノードｎ１とノードｎ２の間にリンクｌ１０８が設けられ、ノードｎ２とノードｎ３の間にリンクｌ１０９が設けられ、ノードｎ３とノードｎ４の間にリンクｌ１１０が設けられているものとする。

このようなネットワークにおいてノードｎ１からノードｎ４までの経路として、図２（ｂ）に示すようにＬＰ１及びＬＰ２が存在する。ＬＰ１は、リンクｌ１０１とリンクｌ１０２とリンクｌ１０３とから構成される。そして、ＬＰ１という経路の場合に、リンクｌ１０１にはＬ１というラベルが付与され、リンクｌ１０２にはＬ２というラベルが付与され、リンクｌ１０３にはＬ３というラベルが付与される。また、ＬＰ２は、リンクｌ１０８とリンクｌ１０９とリンクｌ１１０とから構成される。ＬＰ２という経路の場合に、リンクｌ１０８にはＬ４というラベルが付与され、リンクｌ１０９にはＬ５というラベルが付与され、リンクｌ１１０にはＬ６というラベルが付与される。

さらにノードｎ１からノードｎ４までの他の経路として、図２（ｃ）に示すようなＬＰ３が存在する。ＬＰ３は、リンクｌ１０１とリンクｌ１０４とリンクｌ１０７とリンクｌ１１０とから構成される。そして、ＬＰ３という経路の場合、リンクｌ１０１にはＬ７というラベルが付与され、リンクｌ１０４にはＬ８というラベルが付与され、リンクｌ１０７にはＬ９というラベルが付与され、リンクｌ１１０にはＬ１０というラベルが付与される。

このように、ＬＰ１とＬＰ３では共にリンクｌ１０１を使用するが、ＬＰ１ではＬ１、ＬＰ３ではＬ７という異なるラベルが付与される。すなわち、基本的には、同じリンクを使用する場合においても、ＬＰが異なれば異なるラベルが付与される。言い換えれば、ラベルは各ＬＰにおいて一意に付与される。ラベルが特定されればＬＰも特定され、特定されたラベルの次のラベルに係るリンクも特定できる。例えばラベルＬ８が指定されれば、ラベルＬ８に係るリンクｌ１０４が特定され、さらに次のラベルＬ９も特定され、ラベルＬ９に係るリンクｌ１０７も特定される。すなわち、各ノードにおいて順方向のルーティングが可能となる。尚、優先クラスに関しては優先クラス毎にＬＰを用意するのではなく、ＬＰのサブセットとして優先クラスを設けるＬＰ方式を前提にしている。

図２（ａ）ではノードｎ１からノードｎ４へのＬＰを問題としたが、本実施の形態では逆方向ＲＬＰ（Reverse LP）についても同じラベルを用いる。すなわち、順方向のＬＰに対して対称な逆方向ＲＬＰを用いる。このようにすれば、上り下りについてルーティング情報を共用でき、管理すべきデータ量を減らすことができる。具体的には、逆方向ということが分かって、例えばラベルＬ３が特定されれば、次のラベルはラベルＬ２であると特定される。すなわち、各ノードにおいて逆方向のルーティングも可能となる。

但し、このような構成にすると、ＬＰの数及びノード数が増加するほどラベルの数（＝ＬＰ数×ノード数）も増加するため、管理すべきデータ量が増加する。そこで、本実施の形態では、ラベルマージという考え方を採用する。簡単な例を図３（ａ）及び（ｂ）に示す。図３（ａ）に示すように、ノードｎ１０とノードｎ１１とノードｎ１２とノードｎ１３とを含むネットワークにおいて、ノードｎ１０からノードｎ１３への経路をＬＰ１０とし、ノードｎ１１からノードｎ１３への経路をＬＰ１１とする。また、ノードｎ１０からノードｎ１２までのリンクをｌ１２１とし、ノードｎ１１からノードｎ１２までのリンクがｌ１２３であり、ノードｎ１２からノードｎ１３までのリンクがｌ１２４であるとする。このような場合、ＬＰ１０とＬＰ１１では同じリンクｌ１２４を使用しているが、図２の説明に従えばＬＰ毎に異なるラベルを登録する必要がある。しかし上で述べたように、管理すべきデータ量の削減のため、リンクｌ１２４についてラベルを集約してＬｍという１つのラベルを付与することにする。すなわち、ＬＰ１０についてはラベルＬ１１とラベルＬｍで構成され、ＬＰ１１についてはラベルＬ１２とラベルＬｍで構成される。ノードｎ１２では、ラベルＬ１１が特定されれば、ＬＰ１０において次のラベルはラベルＬｍであると特定できる。また、同じくノードｎ１２では、ラベルＬ１２が特定されれば、ＬＰ１１において次のラベルはラベルＬｍであると特定できる。

一方図３（ｂ）で示すように、逆方向、すなわちノードｎ１３からノードｎ１０へのＬＰ１０ｒとノードｎ１３からノードｎ１１へのＬＰ１１ｒとの場合には、図２の説明のように順方向から自動的に逆方向が特定されるわけではない。すなわち、ラベルＬｍが特定されても、ＬＰ１０ｒなのかＬＰ１１ｒなのかを特定できない。従って次のラベルも特定できないので、ルーティング不可能となる。そこで、本実施の形態では、ラベルマージを行った場合においても逆方向のルーティングを可能にするため、分岐ノードｎ１２において分岐を行うための仮想ラベルを導入する。

仮想ラベルは、ＬＰを特定するものであって、例えば分岐先ラベルを特定するものである。図３（ｂ）の例では、Ｌ１１ｒという仮想ラベルによってラベルＬ１１の方に分岐するようにする。すなわち、発側のノードｎ１３でＬＰ１０ｒを用いる場合には、ラベルＬｍ及び仮想ラベルＬ１１ｒを併せて指定したパケットを送信することになる。一方、ＬＰ１１ｒを用いる場合には、同様にラベルＬｍ及び仮想ラベルＬ１２ｒを併せて指定したパケットを送信することになる。仮想ラベルとしては、（ａ）ドメインに関して一意の順方向ＬＰの先頭ラベル名、（ｂ）発側ネットワークアドレスのパス多重数に対応するラベルのドメイン内において一意なラベル名、（ｃ）発側プレフィックスとパス多重数度に対応するもの等を使用できる。

なお、図３（ａ）及び（ｂ）は、ドメイン内でのルーティングのみを取り扱うため、ドメイン間のパスを取り扱うためには、後に述べるような付加的な機構が必要となる。

次に図２及び図３に示したような基本的な仕組みを実現するための構成について説明する。まず、ノードに配置されるルータの機能ブロック図を図４に示す。ルータ５は、ラベルマップ５４と、リンクテーブル５５と、従来から存在し且つ例えば８クラスの優先制御のための処理を実施する優先制御部５３と、優先クラス毎にリンクの使用率を測定する使用率測定部５１と、優先制御部５３と協働し、ラベルマップ５４及びリンクテーブル５５を参照してパケットのルーティングを実施するルーティング処理部５２とを有する。

図３（ａ）におけるノードｎ１２におけるラベルマップ５４は、例えば図５に示すようなデータを含む。すなわち、左から、第１のラベルの列と、仮想ラベルの列と、第２のラベルの列とを有しており、各レコードが１つのＬＰに対応する。図５の第１のレコードでは、ＬＰ１０のデータが登録されており、ラベルＬ１１に対応して、分岐ノードである場合には仮想ラベルＬ１１ｒと、ラベルＬｍが登録されている。従って、ノードｎ１０からラベルＬ１１が付されたパケットを受信すると、ラベルＬｍに転送すればよいことが分かる。逆に、ラベルＬｍ及び仮想ラベルＬ１２ｒが付されたパケットを受信すると、ラベルＬ１２に転送すればよいことが分かる。

一方、図３（ａ）におけるノードｎ１２におけるリンクテーブル５５は、例えば図６に示すようなデータを含む。すなわち、リンクの列と、ラベルの列とを有し、リンクとラベルが対応付けられている。このように、ラベルが特定できればリンクも特定でき、ルータ５において当該リンクを構成するケーブルが接続されるポートが特定されるので、パケットのルーティングを行うことができる。

ルータ５における使用率測定部５１は、定期的にリンクの使用率を測定し、ＬＰ管理サーバに通知する。但し、使用率の変動が所定範囲内であれば通知を省略する場合もある。なお、以下でも述べるが、ルータ５に接続しているリンクにボトルネックリンクが含まれる場合には、ＬＰ管理サーバが重点監視指示を送信してくるので、使用率測定部５１は、重点監視指示を受信すると、ボトルネックリンクについての監視周期を短くしたり、所定幅以上使用率に変更があった場合にＬＰ管理サーバに通知する場合には当該所定幅を狭くするなどの処置を講ずる。

次に図２及び図３に示したような基本的な仕組みを実現するためのＬＰ−ＤＢに格納されるデータの一例を図７乃至図９を用いて示す。図７にリンクテーブルの一例を示す。図７の例では、図６と同様に、リンク（Ｌid）の列と、ラベル（Ｌa）の列とが設けられており、リンクと当該リンクに割り当てられたラベルとの対応関係が登録されている。ＬＰ−ＤＢにおいては、ネットワーク全体のリンクのデータが登録されている。ネットワークの構成が変更されると、本テーブルのデータについても更新される。

図８にリンクデータ・テーブルの一例を示す。図８の例では、リンク（Ｌid）の列と、当該リンクの静的な帯域幅（Ｂｓ）の列と、当該リンクの両端に接続されるルータのＩＤ（ＲＴid）の列と、優先度毎のリンク使用率（Ｐri-ρ）の列とが設けられている。ここでは説明を簡単にしているため、優先度については０及び１のみが存在するものとしている。ルータ５の使用率測定部５１により測定された使用率は管轄ＬＰ管理サーバに送信され、本テーブルに登録される。

図９にＬＰテーブルの一例を示す。図９の例では、発側エッジルータ配下のネットワークアドレス集合（ネットワークアドレスが１つであれば当該ネットワークアドレス。ネットワークアドレスが２つ以上であれば代表ネットワークアドレス）を表す発ネットワークアドレスセット番号（ＳＮｏ）の列と、着側エッジルータ配下のネットワークアドレス集合を表す着ネットワークアドレスセット番号（ＳＮｄ）の列と、ＳＮｏとＳＮｄ間を接続するＬＰの静的透過帯域順位の列と、障害（上りＵ／下りＤ）の状態を表す列と、逆方向ＬＰ（ＲＬＰ）における仮想ラベル（例えばＳＮｏを用いる。逆方向なのでＳＮｏは着側）の列と、ＬＰを構成する各リンクの帯域容量から算出されるＬＰの静的透過帯域の列と、静的透過帯域についてのボトルネックリンクに対応するラベル（ＢｓＢＮ）の列と、パケットサイズがランダムである場合（Ｍ）とパケットサイズ一定の場合（Ｄ）のいずれかを登録するための透過帯域計算方式（Ｃａｌ）の列と、ベストエフォート（０）と最優先（１）との区別を行うための優先度（Ｐｒｉ）の列と、上り側動的透過帯域（ＢｄＵ）の列と、上り側動的透過帯域についてのボトルネックリンクに対応するラベル（ＢｄＵＢＮ）の列と、下り側動的透過帯域（ＢｄＤ）の列と、下り側動的透過帯域についてのボトルネックリンクに対応するラベル（ＢｄＤＢＮ）の列と、ラベルデータの列とを含む。ラベルデータの列には、当該ＬＰを構成するラベル（Ｌａ）と、当該ラベルに対応するリンクの上り側使用率（ρＵ）と、当該ラベルに対応するリンクの下り側使用率（ρＤ）とが含まれる。なお、上でも述べたが優先度については２段階しかない例を示しているが、一般的にはＮ（Ｎは正の整数）段階設定することができる。

次に、図２及び図３に示したような基本的な仕組みを実現するためにＬＰ管理サーバにおいて実施される基本的な処理について図１０乃至図１４Ａを用いて説明する。ＬＰ管理サーバは、各リンクの帯域幅のデータを取得し、リンクデータ・テーブル（図８）に登録する（ステップＳ１）。このデータについては、ネットワーク中のノードから自動的に取得しても良いし、管理者の入力データを取得するようにしても良い。次に、ＬＰ管理サーバは、別途保持されているＬＰ定義に基づきＬＰ毎に静的透過帯域幅を算出し、当該静的透過帯域幅に従ってエッジルータ間（すなわち発側ノードから着側ノードまでの間）でＬＰグループＬＰＧｓｍを特定する（ステップＳ３）。

ＬＰ毎の静的透過帯域について図１１（ａ）を用いて説明する。図１１（ａ）において、ラベル（対応するリンク）の帯域幅は上りについては上側の帯の長さで表されており、下りについては下側の帯の長さで表されている。図１１（ａ）の例では、ラベルＬ２の帯域幅が最大で、ラベルＬ４の帯域幅が最小である。通常帯域幅が最小のリンクによってＬＰ全体の静的透過帯域は制限されるので、図１１（ａ）の場合にはラベルＬ４の帯域幅が当該ＬＰの静的透過帯域となる。なお、上下で帯域幅が異なる場合もあり、その場合には上り下りで当該ＬＰの静的透過帯域が異なる場合もある。また、ボトルネックとなるラベルも上り下りで異なる場合もある。このようにして、特定のエッジルータ間において静的透過帯域幅の値が大きいＬＰを上位ｎ（図９の例ではｎ＝３）個選択してＬＰグループＬＰＧｓｍを構成する。このように静的透過帯域幅によって動的透過帯域幅の算出対象を限定することにより、計算量を減らすことができる。各ＬＰグループＬＰＧｓｍに含まれるＬＰのデータ（算出された静的透過帯域幅の値、ＬＰを構成するラベル、仮想ラベルが必要な場合には仮想ラベルなど）をＬＰテーブル（図９）に格納する。

次に、各ルータからリンクの使用率のデータを取得し、リンクデータ・テーブル（図８）及びＬＰテーブル（図９）に格納する（ステップＳ５）。上でも述べたがリンクの使用率は優先度毎に取得する。そして、各ＬＰＧｓｍ内の各ＬＰについて動的透過帯域の値を算出し、ＬＰテーブル（図９）に格納する（ステップＳ７）。動的透過帯域について図１１（ａ）及び図１１（ｂ）を用いて説明する。図１１（ａ）及び図１１（ｂ）の例では、各ラベルの静的な帯域幅を示す帯の中にハッチングが付された使用帯域が示されている。実際の通信においては、各ラベルの静的な帯域幅から使用された帯域幅を除いた部分が使用される。すなわち、図１１（ａ）及び（ｂ）においては白抜きの帯の長さが使用可能な帯域となる。図１１（ａ）の場合、上り下り共にラベルＬ４において白抜きの帯の長さが最短となり、ＬＰの動的透過帯域は、最も少ない、ラベルＬ４の上り帯域幅ａ及び下り帯域幅ｂにより特定される。必ずしも、上り下りとも同じラベルが最低の帯域幅となるわけではない。また、時間によっても各ラベルの使用率は異なる。例えば図１１（ａ）の状態から時間が経って、図１１（ｂ）の状態になるとする。ここでは、ラベルＬ３の上りの使用帯域が多くなり、またラベルＬ２の下りの使用帯域が多くなっている。従って、上りについては最も少ないラベルＬ３の帯域幅ｃと、下りについては最も少ないラベルＬ２の帯域幅ｄとにより、動的透過帯域幅が特定される。

動的透過帯域幅については具体的には以下の方法で算出する。図１２に示すように、中継ノードｊにおいて、入力リンク側の帯域幅Ｂij、入力リンク側の使用率ρij、出力リンク側の帯域幅Ｂoj、出力リンク側の使用率ρoj、出力リンク側の動的な帯域幅Ｂjとする。本実施の形態においては待ち行列モデルを適用して動的な帯域幅Ｂjを算出するものとする。パケットサイズが可変の場合には、Ｍ／Ｍ／１モデルに従って、Ｂj＝Ｂoj（１−ρoj）と算出される。また、パケットサイズが固定である場合には、Ｍ／Ｄ／１モデルに従って、Ｂj＝Ｂoj（１−ρoj）（１−ρoj²／２）と算出される。なお、優先クラスが規定されている場合には、近似的に各優先クラスの使用率ρojを当該優先クラスより上位の全てのクラスによる使用率に置き換えて計算を行う。ＬＰの動的透過帯域幅Ｂは、ＬＰを構成する全てのリンクについての動的な帯域幅Ｂjによって、Ｂ＝Ｍｉｎ｛Ｂj｝で算出される。

待ち行列モデルについては以下に補足しておく。図１３に示すような待ち行列モデルを想定する。すなわち、現在サービス中の要素１０４と、待ち行列中の要素１０２乃至１０３と、最新到着分の要素１０１とから構成されるとする。このとき、要素１０２乃至１０３の行列長をＬｑとし、行列長がＬｑである場合におけるサイズＰ（bit）のパケットが転送される時間をＷｑとし、現在サービス中の要素１０４の行列長をρとし、最新到着分の要素１０１の行列長を１とし、待ち行列長Ｌｑと現在サービス中分の行列長ρとを併せた行列長（Ｌｑ＋ρ）をＬとし、行列長がＬの場合におけるサイズＰ（bit）のパケットが転送される時間をＷ、Ｌ＋１（最新到着分も含めた行列長）をＬｒとし、そのときの待ち時間をＷｒとする。

そうすると、パケットサイズ不定の場合であるＭ／Ｍ／１モデルの場合、Ｌｑ＝ρ²／（１−ρ）、Ｌ＝ρ／（１−ρ）、Ｌｒ＝１／（１−ρ）となる。なお、実際には入力バッファが有限であるから、Ｍ／Ｍ／Ｎ（Ｎはバッファ長）の方が好ましい。しかし、バッファ長も大きな値をとることができるようになってきており、Ｍ／Ｍ／１モデルでも十分である。

そして、以下の式が成り立つ。
Ｗ＝（Ｐ／Ｂ'）×Ｌｒ＝（Ｐ／Ｂ'）／（１−ρ）＝Ｐ／Ｂ" （１）
Ｂ'は静的な帯域幅（bps）であり、Ｂ"は動的な帯域幅である。

（１）式を変形すると、以下のようになる。
（１／Ｂ'）／（１−ρ）＝１／Ｂ"
Ｂ"＝Ｂ×（１−ρ）
このように動的透過帯域幅は静的な帯域幅から使用帯域幅を引いた残余の帯域に等しくなる。

また、パケットサイズ固定の場合であるＭ／Ｄ／１モデルの場合、Ｌｑ'＝１／２×ρ²／（１−ρ）、Ｌ'＝（ρ−１／２×ρ²）／（１−ρ）、Ｌｒ'＝（１−１／２×ρ²）／（１−ρ）となる。

そして、以下の式が成り立つ。
Ｗ＝（Ｐ／Ｂ'）×Ｌｒ＝（Ｐ／Ｂ'）×（１−ρ²／２）／（１−ρ）＝Ｐ／Ｂ" （２）

（２）式を変形すると以下のようになる。
（１／Ｂ）×（１−ρ²／２）／（１−ρ）＝１／Ｂ"
Ｂ"＝Ｂ'×（１−ρ）／（１−ρ²／２）

このように、パケットサイズ固定の場合には、パケットサイズ不定の場合より動的透過帯域幅は広くなる。パケットサイズが１５００バイト以下なので、実際の動的透過帯域幅はパケットサイズ固定の場合に近い。

図１０の説明に戻って、ステップＳ７では、動的透過帯域幅Ｂ＝Ｍｉｎ｛Ｂoj｝を算出するため、動的透過帯域幅Ｂを決定するＢjをもたらすボトルネックリンクを特定し、ＬＰテーブル（図９）に登録する（ステップＳ９）。なお、静的透過帯域についても静的透過帯域幅を決定する帯域幅をもたらすボトルネックリンクを特定し、ＬＰテーブル（図９）に登録する。その後、ＬＰ−ＤＢに対するＤＢ更新処理を実施する（ステップＳ１１）。

このＤＢ更新処理については図１４Ａを用いて説明する。まず、静的ボトルネックリンク（ＢＮＬ）に対応するルータに対して重点監視指示を送信する（ステップＳ２１）。例えば、各リンクを監視しているルータのデータを別途保持しておき、当該データに基づきステップＳ９で特定された静的ボトルネックリンクを用いてルータを特定する。なお、重点監視指示を受信したルータの使用率測定部５１は、当該静的ボトルネックリンクに対して、通常より監視頻度を上げたり、使用率更新通知の閾値を変更するなどの処理を行う。また、動的ボトルネックリンク（ＢＮＬ）に対応するルータに対して重点監視指示を送信する（ステップＳ２３）。ステップＳ２１と同様の処理が行われる。なお、静的ボトルネックリンクと動的ボトルネックリンクが同一である場合にはステップＳ２３をスキップしてもよい。

その後、ドメイン内の各ノード（ルータ）からの使用率更新通知を待つ（ステップＳ２５）。そして、いずれかのノードから使用率更新通知を受信すると、当該使用率のデータをリンクデータ・テーブル（図８）及びＬＰテーブル（図９）に登録すると共に、使用率が更新されたリンクに関連するＬＰについて動的透過帯域を算出し、ＬＰテーブル（図９）に登録する（ステップＳ２７）。動的透過帯域の算出については、図１０のステップＳ７と同じであるからここでは説明を省略する。ステップＳ２７では、ＬＰのいずれのラベル（リンク）がボトルネックリンク（ＢＮＬ）であるかが分かるので、当該ボトルネックリンクのラベルを特定する（ステップＳ２９）。そして、ＬＰテーブル（図９）に登録されたボトルネックリンクと、今回特定されたボトルネックリンクとが同一であるか、すなわちボトルネックリンクの移動があるか判断する（ステップＳ３１）。もしボトルネックリンクの移動がなければステップＳ２５に戻る。

一方、ボトルネックリンクの移動があると判断された場合には、ステップＳ２９で特定されたボトルネックリンクのラベルを、ＬＰテーブル（図９）に登録する（ステップＳ３２）。また、移動したボトルネックリンクに対応するルータに対して重点監視指示を送信する（ステップＳ３３）。ステップＳ２３と同様である。また、ＬＰテーブル（図９）を参照して、前のボトルネックリンクが静的ボトルネックリンクではないか確認し、前のボトルネックリンクが静的ボトルネックリンクではない場合には、重点監視解除通知を、前のボトルネックリンクに対応するルータに送信する（ステップＳ３５）。重点監視解除通知を受信したルータは、通常の使用率測定に戻る。すなわち、測定周期をデフォルトの期間に戻し、使用率更新通知の閾値を元に戻す等の処理を行う。

このようなステップＳ２５乃至Ｓ３５を、例えば明示的な処理終了指示の受付など処理終了の条件が満たされるまで繰り返す（ステップＳ３７）。

図１４Ａのような処理を実施することにより、ネットワークの性能に大きく影響を与えるボトルネックリンクについては監視を強化し、不要な監視オーバーヘッドを減らすことによって、効率的にＬＰテーブル（図９）を更新することができるようになる。また、ネットワークの現況を踏まえたルーティングも可能になる。なお、関連する全ルータに、現状の透過帯域幅を通知して、ルータ自身に自己がボトルネックリンクに該当するかを判断させ、ＬＰ管理サーバに通知させるようにしても良い。

（ドメイン間最適パス構成方式）
図２乃至図１４Ａを用いてドメイン内におけるルーティングにおける基本的な構成について説明したが、次にドメイン間のルーティングについて拡張した仕組みについて説明する。本実施の形態において、ＬＰ管理サーバは、自ドメイン内におけるルーティングの管理を行い、他のドメインについては必要な情報の提供を受けるのみとする。なお、図１に示すようにドメインＡのエッジルータからドメインＣのエッジルータまでＬＰを構成する場合、図１４Ｂに示すように、ドメインＡはノードＥＲaからノードＧＷＲaまでであって、ドメインＢはノードＧＷＲaに接続されたリンクからノードＧＷＲb2までであって、ドメインＣはノードＧＷＲb2に接続されたリンクからノードＥＲcまでであるものとする。

図１４Ｂに示したような状態において、ドメインＡに接続したコンピュータのＩＰアドレス群である発アドレスＩＰoから着アドレスＩＰdへのＬＰを構成する場合には、図１５に示すような処理を実施する。すなわち、最初にドメインＡを管理するＬＰ管理サーバＡは、静的透過帯域をベースにドメインＡにおける上位ＬＰグループＭＰＬＳＧsmAを構成する（ステップＳ４１）。具体的には、発アドレスＩＰoに関連付けられているノードＥＲaから着アドレスＩＰdのコンピュータが接続されるドメインＣに関連付けられたノードＧＷＲaまで、ＬＰ−ＤＢに格納された静的透過帯域に基づき上位所定数のＬＰを構成する。なお、ここで発アドレスに関連するドメインＡにおけるＬＰの最初のラベル（例えばＬＰa）が、発アドレスＩＰoから着アドレスＩＰdまでのＬＰ全体及びドメインＡ内におけるパスのＬＰ名となる。但し、ラベルのユニーク性がドメイン内でしか保証されない場合には、先頭にドメイン名ＡＳa（Autonomous System）を付すことにより、ドメイン間のルーティングにおいても識別される。

ＬＰの構成結果は、ＬＰ管理サーバＡに接続されたＬＰ−ＤＢに格納される。ＬＰ−ＤＢに格納される、ドメイン間のＬＰについてのＬＰテーブルの一例を図１６に示す。このデータは、図９のデータ構造を拡張したものであるが、以下の説明で用いられない一部のデータについては省略されている。図１６の例では、発側エッジルータ配下のネットワークアドレス集合（ネットワークアドレスが１つであれば当該ネットワークアドレス。ネットワークアドレスが２つ以上であれば代表ネットワークアドレス）を表す発ネットワークアドレスセット番号（ＳＮｏ）の列と、着側エッジルータ配下のネットワークアドレス集合を表す着ネットワークアドレスセット番号（ＳＮｄ）の列と、ＬＰの順位（ＬＰ＃）の列と、ＬＰを構成する、自ドメイン内の各リンクの帯域容量から算出されるＬＰの静的透過帯域（Ｂsa）の列と、ＬＰ全体の静的透過帯域（Ｂstotal）の列と、自ドメインにおける上り側動的透過帯域（ＢｄＵa）の列と、自ドメインにおける下り側動的透過帯域（ＢｄＤa）の列と、ＬＰ全体の上り側動的透過帯域（ＢｄＵtotal）の列と、ＬＰ全体の下り側動的透過帯域（ＢｄＤtotal）の列と、ラベルデータの列とを含む。ラベルデータの列には、当該ＬＰを構成する自ドメイン内のラベル（Ｌａ）と、当該ラベルに対応するリンクの上り側使用率（ρＵ）と、当該ラベルに対応するリンクの下り側使用率（ρＤ）とが含まれる。なお、ドメインＡ内については上記データ・セットを取得できるのでＬＰ−ＤＢに登録するが、それ以外のドメイン内についてのデータは取得できないので、関連するドメインにつき取得できるデータを登録する。図１４Ｂの例では、ドメインＢについてのデータとしては、ノードＧＷＲaからのリンクに付されたラベル（ＡＳb.ＬＰb1）及びドメインＢにおけるある時点の上り及び下り動的透過帯域が登録され、ドメインＣについてのデータとしてはドメインＣを特定するためのデータ（例えばＬＰ管理サーバＣのアドレス、ドメインＣにおける最初のリンクのラベル）及びドメインＣにおけるある時点の上り及び下り動的透過帯域が登録される。動的透過帯域のデータについては図１５の処理フローにおいては登録されず、ドメインＡ内における動的透過帯域のデータについては例えば図１４Ａに従って自動的に随時更新され、他のドメインについての動的透過帯域は実際のルーティングが必要となった時に登録する。また、本ステップまででは、ドメインＢ及びドメインＣについてのデータについては登録されない。

ＬＰ管理サーバＢ及びＬＰ管理サーバＣに接続されたＬＰ−ＤＢにも同様のデータが登録される。但し、ＬＰ管理サーバＢのＬＰ−ＤＢにおいては、ドメインＡについてのデータはドメインＡと接続するためのデータ（ＬＰ名、ノードＧＷＲaとのリンクに付されたラベル）を含み、ドメインＣについてのデータはノードＧＷＲb2からのリンクに付されたラベルを含む。また、ＬＰ管理サーバＣのＬＰ−ＤＢにおいては、ドメインＡについてのデータはドメインＡを特定するためのデータ（ＬＰ名等）を含み、ドメインＢについてのデータはノードＧＷＲb2からのリンクに付されたラベルを含む。発アドレスに関連するドメインＡ以外のドメインでは他のドメインにおける動的透過帯域は必要とされない。

図１５の説明に戻って、次にドメインＡを管理するＬＰ管理サーバＡは、ノードＧＷＲaに接続されているドメインＢのＬＰ管理サーバＢに、構成依頼を送信する（ステップＳ４３）。構成依頼には、発アドレスＩＰo及び着アドレスＩＰdと、上位ＬＰグループＭＰＬＳＧsmAに含まれるＬＰ毎にＬＰ名（ＡＳa.ＬＰa等）とドメインＡにおける最終接続ノードであるノードＧＷＲaのＩＰアドレスと静的透過帯域のデータとを含む。

ドメインＢを管理するＬＰ管理サーバＢは、ＬＰ管理サーバＡから構成依頼を受信し（ステップＳ４５）、構成依頼に含まれるドメインＡにおける静的透過帯域を含む通算の静的透過帯域をベースにドメインＢにおける上位ＬＰグループＭＰＬＳＧsmBを構成する（ステップＳ４７）。具体的には、ノードＧＷＲaから着アドレスＩＰdのコンピュータが接続されるドメインＣに関連付けられているノードＧＷＲb2まで、構成依頼に含まれるドメインＡにおける静的透過帯域とＬＰ−ＤＢに格納されているドメインＢ内における静的透過帯域とを含む通算の静的透過帯域に基づき上位所定数のＬＰを構成する。ここではＬＰbをドメインＢ内のＬＰ名とする。構成結果については、ＬＰ管理サーバＢに接続されたＬＰ−ＤＢに格納される。

さらに、ドメインＢを管理するＬＰ管理サーバＢは、ノードＧＷＲb2に接続されているドメインＣのＬＰ管理サーバＣに、構成依頼を送信する（ステップＳ４９）。構成依頼には、発アドレスＩＰo及び着アドレスＩＰdと、受信した構成依頼に含まれる上位ＬＰグループのＬＰ毎にＬＰ名（ＡＳa.ＬＰa等）とドメインＢにおける最終接続ノードであるノードＧＷＲb2のＩＰアドレスと通算の静的透過帯域のデータとを含む。

ドメインＣを管理するＬＰ管理サーバＣは、ＬＰ管理サーバＢから構成依頼を受信し（ステップＳ５１）、ドメインＡ及びドメインＢについての静的透過帯域を含む通算の静的透過帯域をベースにドメインＣにおける上位ＬＰグループＭＰＬＳＧsmCを構成する（ステップＳ５３）。具体的には、ノードＧＷＲb2から着アドレスＩＰdのコンピュータが接続されるノードＥＲcまで、構成依頼に含まれるドメインＡ及びＢの静的透過帯域とＬＰ−ＤＢに格納されたドメイン内の静的透過帯域とを含む通算の静的透過帯域に基づき上位所定数のＬＰを構成する。ここではＬＰcをドメインＣ内のＬＰ名とする。構成結果については、ＬＰ管理サーバＣに接続されたＬＰ−ＤＢに格納される。

ここまでＬＰの構成を実施すると、ドメインＡ内、ドメインＡとドメインＢの間、ドメインＢ内、ドメインＢとドメインＣの間、ドメインＣ内のパスが決定されるので、ドメインＣを管理するＬＰ管理サーバＣは、ドメインＣの構成情報をドメインＢのＬＰ管理サーバＢに送信する（ステップＳ５５）。ドメインＣの構成情報には、発アドレスＩＰo及び着アドレスＩＰdと、受信した構成依頼に含まれる上位ＬＰグループのＬＰ毎にＬＰ名（ＡＳa.ＬＰa等）とドメインＣにおける最初の接続ノードであるノードＧＷＲcのＩＰアドレスと通算の静的透過帯域のデータ（場合によってはドメインＣにおける静的透過帯域のデータ）とドメインＢの最終接続ノードＧＷＲb2に接続する最初のリンクのラベル（ＡＳc.ＬＰc）とを含む。

さらに、ドメインＣを管理するＬＰ管理サーバＣは、上位ＬＰグループＭＰＬＳＧsmCに含まれるＬＰに関連する、自ドメイン内のノードに対して、ラベルデータを配布してラベルマップ５４に格納する（ステップＳ５７）。ノードＥＲcにおけるラベルマップ５４に格納されるデータの一例を図１７に示す。図１７の例では、左から、第１のラベルの列と、仮想ラベルの列と、第２のラベルの列とが設けられており、仮想ラベルは図５とは異なり２列となる。本実施の形態では、ドメイン内の逆方向ルーティングのためのデータとしてドメインＣにおける最初のリンクのラベル（ここでは２つのＬＰがＩＰo及びＩＰd間に構成されたものとしてＬＰc1又はＬＰc2）と、ドメイン間の逆方向ルーティングのためのデータとしてＬＰ名（ここでは２つのＬＰがＩＰo及びＩＰd間に構成されたものとしてＡＳa.ＬＰa1又はＡＳa.ＬＰa2）とを含む。複数のドメインに渡るＬＰを構成した場合には、この２つのデータを用いて適切に分岐させる必要があるためである。なお、順方向のルーティングにおいては、第１のラベルから第２のラベルを特定して、第２のラベルに対応するリンクを抽出する。逆方向のルーティングにおいては、第２のラベル及び仮想ラベルから第１のラベルを特定する。すなわち、図３（ｂ）の逆方向ルーティングにおいては、仮想ラベルＬ１１ｒだけではなく、ＡＳa.ＬＰa1又はＡＳa.ＬＰa2を合わせて用いてルーティングを行う。但し、図１４Ｂのような例において、ノードＥＲcでは仮想ラベルは本来不要であるが、ここではドメインＣ内のノードの例として記している。

また、ノードＧＷＲcにおけるラベルマップ５４に格納されるデータの一例を図１８に示す。基本的な構造は図１７の例と同一である。第１のラベルについては、ドメインＢと接続するリンクとなるので、ＡＳc.ＬＰc1又はＡＳc.ＬＰc2というように、ドメイン名及びドメインＣ内のＬＰ名とで構成されるラベルが登録されている。なお、ドメイン内の中継ノードは省略されているので、図１７の第１ラベルと図１８の第２ラベルは一致しない。

ステップＳ５５の構成情報の送信に応答して、ドメインＢを管理するＬＰ管理サーバＢは、ドメインＣのＬＰ管理サーバＣからドメインＣにおける構成情報を受信し（ステップＳ５９）、ドメインＣとの関係を表すデータをＬＰ−ＤＢに登録する（ステップＳ６１）。具体的には、発アドレスＩＰo及び着アドレスＩＰdとＬＰ名との組み合わせからレコードを特定し、ドメインＢの最終接続ノードＧＷＲb2に接続するリンクのラベル（ＡＳc.ＬＰc）及び通算の静的透過帯域のデータ等を登録する。

そして、ドメインＢのＬＰ管理サーバＢは、ドメインＢの構成情報を、ドメインＡを管理するＬＰ管理サーバＡに送信する（ステップＳ６３）。ドメインＢの構成情報は、発アドレスＩＰo及び着アドレスＩＰdと、構成情報に含まれる上位ＬＰグループのＬＰ毎にＬＰ名（ＡＳa.ＬＰa等）とドメインＢにおける最初の接続ノードであるノードＧＷＲb1のＩＰアドレスと通算の静的透過帯域のデータ（場合によってはドメインＢ及びＣにおける各静的透過帯域のデータ）とドメインＡの最終接続ノードＧＷＲaに接続する最初のリンクのラベル（ＡＳb.ＬＰb等）とを含む。

さらに、ドメインＢのＬＰ管理サーバＢは、上位ＬＰグループＭＰＬＳＧsmBに含まれるＬＰに関連する、自ドメイン内のノードに対して、ラベルデータ等を配布してラベルマップ５４に格納する（ステップＳ６５）。ノードＧＷＲb2におけるラベルマップ５４に格納されるデータの一例を図１９に示す。データ構造は図１７と同じである。但し、ドメインＢにおける仮想ラベルとしては、ドメイン内の逆方向ルーティングのためのデータとしてドメインＢにおける最初のリンクのラベル（ＬＰb1又はＬＰb2）と、ドメイン間の逆方向ルーティングのためのデータとしてＬＰ名（ＡＳa.ＬＰa1又はＡＳa.ＬＰa2）とを含む。ノードＧＷＲcと接続されるノードであるため、図１８の第１のラベルと図１９の第２のラベルは同一となる。なお、ドメインＣにおける最初の接続ノードであるノードＧＷＲcのＩＰアドレスについては、ノードＧＷＲb2においてラベルとリンクとを対応付ける際に必要な場合もあるので、当該ノードＧＷＲb2に通知する。また、ノードＧＷＲb1におけるラベルマップ５４に格納されるデータの一例を図２０に示す。基本的な構造は図１８の例と同一である。なお、ドメイン内の中継ノードは省略されているので図１９の第１ラベルと図２０の第２ラベルとは一致しない。

ステップＳ６３の構成情報の送信に応答して、ドメインＡを管理するＬＰ管理サーバＡは、ドメインＢのＬＰ管理サーバＢからドメインＢにおける構成情報を受信し（ステップＳ６７）、ドメインＢとの関係を表すデータをＬＰ−ＤＢに登録する（ステップＳ６９）。具体的には、発アドレスＩＰo及び着アドレスＩＰdとＬＰとの組み合わせからレコードを特定し、ドメインＡの最終接続ノードＧＷＲaに接続するリンクのラベル（ＡＳb.ＬＰb）及び通算の静的透過帯域のデータを登録する。

そして、ドメインＡのＬＰ管理サーバは、上位ＬＰグループＭＰＬＳＧsmAに含まれるＬＰに関連する、自ドメイン内のノードに対して、ラベルデータ等を配布してラベルマップ５４に格納する（ステップＳ７１）。ノードＧＷＲaにおけるラベルマップ５４に格納されるデータの一例を図２１に示す。図２１の例では、仮想ラベルがドメインＡにおける最初のラベル（ＬＰa1又はＬＰb2）だけとなる。これは既に逆方向ルーティングにおける目的のドメインであるためドメイン間のルーティングを考慮する必要がないためである。なお、ノードＧＷＲb1と接続されるノードであるため、図２０の第１のラベルと図２１の第２のラベルは同一となる。また、ドメインＢにおける最初の接続ノードであるノードＧＷＲb1のＩＰアドレスについては、ノードＧＷＲaにおいてラベルとリンクとを対応付ける際に必要な場合もあるので、当該ノードＧＷＲaに通知する。また、ノードＥＲaにおけるラベルマップ５４に格納されるデータの一例を図２２に示す。すでに逆方向ルーティングにおける目的の発アドレスＩＰoに直接ルーティングできるので、仮想ラベルは登録されない。なお、ドメイン内の中継ノードは省略されているので図２１の第１ラベルと図２２の第２ラベルとは一致しない。

以上のような処理を行うことによって、ドメイン間におけるルーティングを行うための前処理が完了する。なお、全ての発アドレスＩＰo及び着アドレスＩＰdについて処理を行っておく。

次に、図２３乃至図２８を用いて、実際にルーティングが行われる段階における処理を説明する。まず、ルーティングの前処理として、クライアント端末の例えばＷｅｂブラウザから、ＵＲＬを含むＩＰアドレスの問い合わせがＤＮＳに対して送信される。そうすると、ノードＥＲa（クライアント端末側のエッジルータ）は、クライアント端末からＵＲＬを含むＩＰアドレスの問い合わせを受信し、ＤＮＳに転送する。ノードＥＲaとＤＮＳとの通信は頻繁に発生するので、予めＬＰ管理サーバＡにより指定されたＬＰ及びＲＬＰのデータ（ＬＰの最初のラベル及びＲＬＰの最初のラベル及び必要ならば仮想ラベル。なお本データは随時更新されるものとする。）をノードＥＲaが保持しており、当該ＬＰ及びＲＬＰのデータを用いて転送を行うものとする。ＤＮＳは、ノードＥＲaからＵＲＬを含むＩＰアドレスの問い合わせを受信すると、ＵＲＬに対応するＩＰアドレスを検索して抽出し、ＩＰアドレス通知を返信する。返信の際には、ＲＬＰのデータ（最初のラベル及び必要であれば仮想ラベル）により経路を特定する。ノードＥＲaは、ＤＮＳからＩＰアドレス通知を受信し、要求元のクライアント端末に転送する。クライアント端末のＷｅｂブラウザ等は、ノードＥＲaからＩＰアドレス通知を受信する。

これにて前処理が完了するので、クライアント端末のＷｅｂブラウザ等は、自らのＩＰアドレス（発アドレスＩＰo）及び受信した着ＩＰアドレスを含むリクエスト（接続要求）を送信する（図２３：ステップＳ８１）。例えばＨＴＴＰ（Hyper Text Transfer Protocol）の場合には、ＧＥＴメッセージを送信する。ノードＥＲaは、クライアント端末から発ＩＰアドレスＩＰo及び着ＩＰアドレスＩＰdを含むリクエストを受信すると当該リクエストのデータを例えばバッファなどの記憶装置に格納し（ステップＳ８３）、発ＩＰアドレスＩＰoと着ＩＰアドレスＩＰd及びポート番号等の宛先データとを含む最適ＬＰ問い合わせをＬＰ管理サーバＡに送信する（ステップＳ８５）。ノードＥＲaとＬＰ管理サーバＡとの通信は頻繁に発生するので、予めＬＰ管理サーバＡにより指定されたＬＰ及びＲＬＰのデータをノードＥＲaが保持しておき、当該ＬＰ及びＲＬＰのデータを用いて転送を行う。

ＬＰ管理サーバＡは、ノードＥＲaから発ＩＰアドレスＩＰoと着ＩＰアドレスＩＰd及びポート番号など宛先データを含む最適ＬＰの問い合わせを受信すると（ステップＳ８７）、発ＩＰアドレスＩＰo及び着ＩＰアドレスＩＰdを用いて図１６のようなＬＰ−ＤＢを検索し、動的透過帯域を特定する対象となるＬＰ（そのためのレコード）を特定する（ステップＳ８９）。そうすると各ＬＰについて関連するドメインも特定されるため、当該各ドメインのＬＰ管理サーバに、各ＬＰ名を含む、各ＬＰの動的透過帯域データ要求を送信する（ステップＳ９１）。ＬＰ管理サーバ間のパスも頻繁に用いられるので、予め特定してデータを保持しておく。各ＬＰに関連するドメインのＬＰ管理サーバは、各ＬＰの動的透過帯域データ要求を受信すると（ステップＳ９３）、各ＬＰについて図１６に示したＬＰ−ＤＢから自ドメインについての上り及び下りの動的透過帯域データ（例えばＢｄＵb及びＢｄＤb）を読み出し、ＬＰ管理サーバＡに返信する（ステップＳ９５）。なお、自ドメインについての上り及び下りの動的透過帯域データは、例えば図１４Ａなどによって自動的にＬＰ−ＤＢに登録される。

ＬＰ管理サーバＡは、各ＬＰに関連するドメインのＬＰ管理サーバから、各ＬＰの動的透過帯域データを受信し、ＬＰ−ＤＢ（図１６）に登録する（ステップＳ９７）。例えば、ＬＰa1乃至ＬＰa4がステップＳ８９で特定され、これらのＬＰにつきステップＳ９７において関連するＬＰ管理サーバＢ及びＣから動的透過帯域データを受信したとすると、自ドメインＡについてのデータを合わせて図２４に示すようなデータが取得されたと仮定する。なお、ＬＰa1乃至ＬＰa4は静的透過帯域の大きい順に並べられている。各ＬＰの総合の動的透過帯域は、最低の動的透過帯域によって制限されるため、ＬＰa1については上りも下りもドメインＡの動的透過帯域と同じ値となり、ＬＰa2については上りはドメインＢと下りはドメインＡの動的透過帯域と同じ値となり、ＬＰa3については上りも下りもドメインＡの動的透過帯域と同じ値となり、ＬＰa4についても上りも下りもドメインＡの動的透過帯域と同じ値となる。

このような総合動的透過帯域がＬＰ−ＤＢに登録されると、ＬＰ管理サーバＡは、最適ＬＰ決定処理を実施する（ステップＳ９９）。最適ＬＰ決定処理については、図２５及び図２６を用いて説明する。ＬＰ管理サーバＡは、最適ＬＰ問い合わせの宛先データに含まれるポート番号などからルーティングポリシーを決定する（ステップＳ１０１）。ここでは、ルーティングポリシーは、非対称ルーティング、トラフィック上下均等の対称ルーティング、トラフィック上下不均等（上りと下りのトラフィック量が例えば２倍以上異なる場合）の対称ルーティングのいずれかである。例えば、上り下りのルーティングが対称である必要の無いものが非対称ルーティングとして判定される。例えば、ＩＰアドレス及びポートから、ＩＰ電話、ファイルダウンロード、ファイルアップロード、Ｗｅｂブラウジングといったアプリケーションであることが特定できれば、対称ルーティングが選択されるものとする。ＩＰ電話であればトラフィック上下均等の対称ルーティングが選択され、ファイルダウンロード、ファイルアップロード及びＷｅｂブラウジングであればトラフィック上下不均等の対称ルーティングが選択されるものとする。

従って、非対称ルーティングが選択されると（ステップＳ１０３：Ｎｏルート）、ＬＰ−ＤＢ（図１６）を参照して、上り下りそれぞれについて最大動的透過帯域幅を有するＬＰを選択する（ステップＳ１０５）。そして元の処理に戻る。

一方、対称ルーティングであって（ステップＳ１０３：Ｙｅｓルート）、トラフィック上下均等が選択された場合（ステップＳ１０７：Ｙｅｓルート）、ステップＳ８９で特定されたＬＰのうち上り下りのうちトラフィック量が少ない方の動的透過帯域幅が規定値以下のものを除外する（ステップＳ１０９）。なお、残余のＬＰが存在しないような場合にはステップＳ１０５に移行するようにしても良い。そして残余のＬＰのうち上り下りの動的透過帯域幅の差が最小のＬＰを選択する（ステップＳ１１１）。ステップＳ１１１の代わりに、残余のＬＰのうち上り下りの動的透過帯域幅の平均値が最大となるＬＰを選択するようにしても良い。そして元の処理に戻る。

さらに、対称ルーティングであって（ステップＳ１０３：Ｙｅｓルート）、トラフィック上下不均等が選択された場合（ステップＳ１０７：Ｎｏルート）、ステップＳ８９で特定されたＬＰのうちトラフィックが少ない方向（上り又は下り）のＬＰで動的透過帯域幅が規定値以下であるものを除外する（ステップＳ１１３）。なお、残余のＬＰが存在しないような場合にはステップＳ１０５に移行するようにしても良い。そして、残余のＬＰのうちトラフィックが多い方向（上り又は下り）のＬＰで最大の動的透過帯域幅を有するＬＰを選択する（ステップＳ１１５）。そして元の処理に戻る。

このような処理を実施することにより、通信アプリケーションなどにより特定されるルーティングポリシーに従って最適なＬＰが選択されるようになる。

図２６を用いて図２５の処理フローを具体的に説明しておく。図２６（ａ）に示すように、ＬＰa1の静的透過帯域（Ｂｓtotal）が１００で、上り側動的透過帯域（ＢｄＵtotal）が４０で下り側動的透過帯域（ＢｄＤtotal）が３であり、ＬＰa2の静的透過帯域（Ｂｓtotal）が８０で、上り側動的透過帯域（ＢｄＵtotal）が３０で下り側動的透過帯域（ＢｄＤtotal）が１０であり、ＬＰa3の静的透過帯域（Ｂｓtotal）が５０で、上り側動的透過帯域（ＢｄＵtotal）が２０で下り側動的透過帯域（ＢｄＤtotal）が３０であるとする。非対称ルーティングが選択された場合には、図２６（ｂ）に示すように、上りについてはＬＰa1の動的透過帯域幅が最大となり、下りについてはＬＰa3の動的透過帯域幅が最大となるため、上り下りについてそれぞれ選択される。一方、図２６（ｃ）に示すように、トラフィック上下不均等で対称ルーティングが選択された場合、具体的には上りのトラフィック量が下りのトラフィック量より多い場合には、ステップＳ１１３で「下り」について規定値以下のＬＰとしてＬＰa1を除外し、ステップＳ１１５で上りの動的透過帯域幅が最大となるＬＰa2を選択する。さらに、図２６（ｄ）に示すように、トラフィック上下均等で対称ルーティングが選択された場合、ステップＳ１０９で図２６（ｄ）の例では下りの動的透過帯域が最小となるＬＰa1を除外し、ステップＳ１１１で上り下りの動的透過帯域幅の差が最小となるＬＰとしてＬＰa3が選択される。

図２３の処理に戻るが、端子Ｂ及びＣを介して図２７の処理に移行する。なお、クライアント端末の処理については端子Ａを介して図２８の処理に移行する。まず、図２７において、ＬＰ管理サーバＡは、ステップＳ９９において決定されたＬＰからＬＰ−ＤＢ（図１６）を用いて特定される上り下りの開始ラベル（下りのＬＰについて仮想ラベルが必要であれば当該仮想ラベルも含む。以下同じ。）を含む最適ＬＰ通知をノードＥＲaに送信する（ステップＳ１２１）。ノードＥＲaは、ＬＰ管理サーバＡから上り下りの開始ラベルを含む最適ＬＰ通知を受信し（ステップＳ１２３）、上り下りの開始ラベルを含むようにステップＳ８３で受信したリクエストを変更し、上り下りの開始ラベル及び宛先サーバのＩＰアドレス等を含むリクエストを宛先サーバ宛に送信する（ステップＳ１２５）。なお、ノードＥＲaは、上りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、上りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信したリクエストの上りの開始ラベルを次のラベルで置換してリクエストを更に次のルータに送出する。既に上で述べたようなＬＰの構成処理を実施しているので、これを繰り返せばドメインＣのノードＥＲc（サーバ側のエッジルータ）まで到達する。

ノードＥＲcは、前のルータから、上りのラベル、下りの開始ラベル及び宛先サーバのＩＰアドレスを含むリクエストを受信し（ステップＳ１２７）、下りの開始ラベル及び要求元ＩＰアドレスを例えばメインメモリなどの記憶装置に格納する（ステップＳ１２９）。そして、宛先サーバのＩＰアドレスによりリクエストの送出先を特定し、当該リクエストを宛先サーバに転送する（ステップＳ１３１）。

宛先のサーバは、ノードＥＲcからリクエストを受信し（ステップＳ１３３）、所定の処理を実施し、応答を生成して送信する（ステップＳ１３５）。ノードＥＲcは、宛先サーバから応答を受信する（ステップＳ１３７）。処理は端子Ｄ及びＥを介して図２８の処理に移行する。

ノードＥＲcは、ステップＳ１２９において格納された下りの開始ラベルを特定し、当該開始ラベル及び要求元のＩＰアドレスを含む応答を生成し、開始ラベルに従って送信する（ステップＳ１３９）。ノードＥＲcは、下りの開始ラベルでリンクテーブルを参照することにより送出先のリンクを特定する。次のルータでは、下りの開始ラベルでラベルテーブルを参照することにより次のラベルを特定し、さらに当該次のラベルでリンクテーブルを参照することにより送出先リンクを特定する。そして、受信した応答における下りの開始ラベルを次のラベルで置換して当該応答を更に次のルータに送出する。下りについても上りと同様に、ＬＰの構成処理を実施しているので、これを繰り返せばノードＥＲaまで到達する。ノードＥＲaは、下りのラベル及び要求元ＩＰアドレスを含む応答を受信し（ステップＳ１４１）、要求元ＩＰアドレスにより当該応答をクライアント端末に転送する（ステップＳ１４３）。クライアント端末は、クライアント側のエッジルータから応答を受信し、例えばＷｅｂブラウザで表示装置に表示する（ステップＳ１４５）。

このような処理を行うことにより、ＬＰ管理サーバＡが決定した最適なＬＰに従って、クライアント端末と宛先サーバとの通信が行われるようになる。従って、複数のドメインを含むネットワーク全体においても効率的な通信が行われるようになる。また、ドメイン間で必要なデータのやりとりは最小限に抑えられている。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、最適サーバ及びＬＰを特定するための処理において指標を特定しているが、他の算式を定義して当該算式によって算出された指標値を判断の基準に用いるようにしても良い。

また、上で述べたルーティングポリシーについても一例であって他のルーティングポリシーを定義しても良い。その際にはルーティングポリシーの定義に合わせたＬＰや最適サーバを特定する必要がある。

さらに、ＬＰ管理サーバＡ乃至Ｃについては、複数のコンピュータにより並列処理するような構成であってもよい。

また、ドメイン毎にラベルが管理されており、ドメイン間では重複するラベルが存在しうる場合について説明したが、ドメイン間で重複するラベルが存在しないようにする場合もある。そのような場合には、ＬＰが１つ決まればそれに含まれるラベルは一意に決まるため、ルータにおける仮想ラベルは不要となる。

上記における仮想ラベル付与に関して、ドメイン内及びドメイン間仮想ラベルとして、“発側ネットワークアドレス．パス多重優先順位”に対応する発ドメイン内一意の仮想ラベルを発ドメイン内の仮想ラベルとし、ドメイン間及び発ドメイン以外のドメインについてはこのドメイン内仮想ラベルに発ドメイン名（ＡＳ）を付与したものを用いることもできる。この場合は仮想ラベルは１段で足りる。ここでパス多重優先順位とは特定対地（Ｅｎｄ to Ｅｎｄ）間で定義されるＬＰに付与される順位である。例えば図９のＬＰ＃欄の値（１、２又は３）になる。

先頭リンク名をドメインに一意なＬＰ名とする方式だと、ラベル数が（接続エッジルータ²）で効いてくるので接続エッジルータ数が、直ぐに頭打ちになる。現行の２０ｂｉｔのラベル容量だと、１０００×１０００で頭打ちになりパス多重度＝１としても１０００拠点しか接続できない。仮想ラベルとして発側のアドレス×パス多重度を用いれば、各ＬＰの先頭ラベル名を用いるものと比べて、ラベルの数を大幅に減らすことができ、現行の２０ｂｉｔ・４多重パスでも２５万拠点をメッシュで接続できる。

上記における仮想ラベル付与に関して、仮想ラベルとして、ドメイン内およびドメイン間仮想ラベルとして、“発側プレフィックス．パス多重優先順位”を仮想ラベルとして、ドメイン内・ドメイン間を共通に利用することもできる。この場合は、仮想ラベルは１段で足り、ＡＳ番号付与も不要になる。ここで発側プレフィックスとは、ＩＰアドレスにおいて発側端のネットワークアドレス長表記を含む発側端のネットワークアドレスを示す。

同様に、仮想ラベルとして“発側プレフィックス．パス多重度”を用いれば、各ＬＰの先頭ラベル名を用いるものと比べて、ラベルの数を大幅に減らすことができ、現行の２４ｂｉｔ（クラスＣ＋４多重パス）で１６００万拠点をメッシュで接続できる。しかもドメイン番号（ＡＳ）を付与せずにドメイン間利用できる。プレフィックスとはネットワークサイズを含むネットワークアドレス情報である。

なお、ＬＰ管理サーバＡ乃至Ｃは図２９に示すようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
特定のドメインにおける任意のノード間のパスの管理を行う管理サーバにより実行される情報処理方法であって、
前記特定のドメインに関連する発アドレスと前記特定のドメインとは異なる第２のドメインに関連する着アドレスとの間のパスを構成する場合、前記特定のドメイン内において前記発アドレスに関連する第１のノードと前記第２のドメインに関連付けられた第２のノードとの間における複数のパスを構成し、当該複数のパスのうち帯域幅が上位所定数のパスを登録パスとして特定し、前記発アドレス及び前記着アドレスと前記登録パスの各々につき登録パスに関するデータとをパスデータ格納部に格納するステップと、
前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの帯域幅のデータ及び前記第２のノードのデータとを含む構成依頼を、前記第２のノードに接続された第３のドメインの管理サーバに送信するステップと、
前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第２のノードと前記第３のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第３のドメインの管理サーバから受信した場合、前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記接続リンクに関するデータを前記パスデータ格納部に格納するステップと、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
を含む情報処理方法。

（付記２）
第４のドメインの管理サーバから、前記特定のドメインとは異なるドメインに関連する発アドレス及び着アドレスと候補パスの各々について当該候補パスの帯域幅のデータ及び前記第４のドメインにおける最終中継ノードのデータとを含む構成依頼を受信した場合、前記特定のドメイン内において、前記最終中継ノードと前記構成依頼に含まれる前記着アドレスが関連する第５のドメインに関連付けられた第３のノードとの間に複数のパスを構成し、当該複数のパスのうち前記構成依頼に含まれる前記帯域幅を考慮した通算の帯域幅が上位所定数のパスを前記特定のドメインにおける登録パスとして特定し、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記特定のドメインにおける登録パスに関するデータとを前記パスデータ格納部に格納するステップと、
前記第３のノードに接続された第６のドメインの管理サーバに、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの前記通算の帯域幅のデータ及び前記第３のノードのデータとを含む構成依頼を送信するステップと、
受信した前記構成依頼に含まれる前記発アドレス及び前記着アドレスと送信した前記構成依頼に含まれる前記登録パスの各々につき前記第３のノードと前記第６のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第６のドメインの管理サーバから受信した場合、前記構成情報通知に含まれる前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記構成情報通知に含まれる前記接続リンクに関するデータを前記パスデータ格納部に格納するステップと、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
前記第４のドメインの管理サーバに、前記構成情報通知に含まれる前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第４のドメインにおける最終中継ノードと前記特定のドメインにおける接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を送信するステップと、
をさらに含む付記１記載の情報処理方法。

（付記３）
第５のドメインの管理サーバから、前記特定のドメインに関連付けられた着アドレス及び前記特定のドメイン以外の第８のドメインに関連する発アドレスと候補パスの各々について当該候補パスの帯域幅のデータ及び前記第７のドメインにおける最終中継ノードのデータとを含む構成依頼を受信した場合、前記特定のドメイン内において、前記最終中継ノードと前記構成依頼に含まれる前記着アドレスに関連するノードとの間に複数のパスを構成し、当該複数のパスのうち前記構成依頼に含まれる前記帯域幅を考慮した通算の帯域幅が上位所定数のパスを前記特定のドメインにおける登録パスとして特定し、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記特定のドメインにおける登録パスに関するデータとを前記パスデータ格納部に格納するステップと、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
前記第７のドメインの管理サーバに、前記構成依頼に含まれる前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第７のドメインにおける最終中継ノードと前記特定のドメインにおける接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を送信するステップと、
をさらに含む付記１又は２記載の情報処理方法。

（付記４）
前記パスを構成する先頭リンクに、各ドメインにおいて一意のラベルが付されており、
他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、
前記登録パスに関するデータが、前記登録パスを構成するリンクのラベルを含む
ことを特徴とする付記１乃至３のいずれか１つ記載の情報処理方法。

（付記５）
前記パスを構成する先頭リンクに、複数の所定のドメインにおいて一意のラベルが付されており、
前記登録パスに関するデータが、前記登録パスを構成するリンクのラベルを含む
ことを特徴とする付記１乃至３のいずれか１つ記載の情報処理方法。

（付記６）
前記パスを構成する各リンクに、所属ドメインにおけるラベルが付されており、
他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、
複数のパスにおいて共用される共用リンクについては同一のラベルが付されており、
前記パスデータ格納部において、前記登録パスを構成する、前記特定のドメイン内の各リンクのラベルと、前記登録パスを構成する、前記特定のドメイン内のリンクが前記共用リンクを含む場合には前記登録パスの逆方向においてリンクの分岐方向を特定するためのデータとが対応付けられており、
前記特定のドメインにおけるノードに対するルーティングの設定において、特定のラベルから当該特定のラベルに係るリンクを含む前記登録パスにおける次のリンクを特定するためのデータと、前記特定のドメインが前記登録パスの発アドレスに関連するドメイン以外のドメインであって前記登録パスにおいて共用リンクが含まれる場合には前記特定のドメイン内における逆方向ルーティング時に分岐方向を特定するためのデータ及び前記登録パス全体を特定するためのデータとを、ルーティング・データとしてノードに登録する
ことを特徴とする付記２又は３記載の情報処理方法。

（付記７）
複数のドメインを経由して通信を行う場合において通信の発側ドメインにおける管理サーバにより実行される情報処理方法であって、
パケットの送信元及び送信先に関するデータを含むパス設定要求を受信した場合、前記送信元アドレス及び送信先アドレスに対応して候補パスのデータを格納するパスデータ格納部を参照し、前記パス設定要求に係る候補パスを特定する候補パス特定ステップと、
前記パス設定要求に係る前記送信先に関するデータに基づき、前記パケットについてのルーティング・ポリシーを特定するステップと、
特定された前記候補パス上におけるドメインの管理サーバに対して、管轄ドメイン内における、前記候補パスの動的帯域幅のデータを要求するステップと、
前記候補パス上におけるドメインの管理サーバから、前記管轄ドメイン内における、当該候補パスの動的帯域幅のデータを受信した場合、前記発側ドメインにおける動的帯域幅のデータと前記候補パス上におけるドメインにおける前記動的帯域幅のデータとに基づき前記候補パス全体の動的帯域幅を算出し、記憶装置に格納するステップと、
前記候補パス全体の動的帯域幅及び前記ルーティング・ポリシーに基づき、前記候補パスの中から最適パスを決定するパス決定ステップと、
前記最適パスを特定するためのデータをパス設定要求元に送信するステップと、
を含む情報処理方法。

（付記８）
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが上下非対称ルーティングである場合には、前記候補パスの中から上り方向の動的透過帯域幅の値が最大となるパスと下り方向の動的透過帯域幅の値が最大となるパスとを決定するステップと、
を含む付記７記載の情報処理方法。

（付記９）
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが対称ルーティングであって上下方向のトラフィック量の差又は比が所定範囲内であると想定される場合、前記候補パスの中から上下方向の動的透過帯域幅の値が所定の条件を満たすパスを決定するステップと、
をさらに含む付記８記載の情報処理方法。

（付記１０）
前記パス決定ステップが、
特定された前記ルーティング・ポリシーが対称ルーティングであって上下方向のトラフィック量の差又は比が所定範囲外であると想定される場合、前記候補パスの中からトラフィック量が多いと想定される方向の動的透過帯域幅の値が最大であるパスを決定するステップと、
をさらに含む付記９記載の情報処理方法。

（付記１１）
付記１乃至１０のいずれか１つ記載の情報処理方法をコンピュータに実行させるためのプログラム。

（付記１２）
特定のドメインにおける任意のノード間のパスの管理を行う管理サーバであって、
前記特定のドメインに関連する発アドレスと前記特定のドメインとは異なる第２のドメインに関連する着アドレスとの間のパスを構成する場合、前記特定のドメイン内において前記発アドレスに関連する第１のノードと前記第２のドメインに関連付けられた第２のノードとの間における複数のパスを構成し、当該複数のパスのうち帯域幅が上位所定数のパスを登録パスとして特定し、前記発アドレス及び前記着アドレスと前記登録パスの各々につき登録パスに関するデータとをパスデータ格納部に格納する手段と、
前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの帯域幅のデータ及び前記第２のノードのデータとを含む構成依頼を、前記第２のノードに接続された第３のドメインの管理サーバに送信する手段と、
前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第２のノードと前記第３のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第３のドメインの管理サーバから受信した場合、前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記接続リンクに関するデータを前記パスデータ格納部に格納する手段と、
前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行う手段と、
を有する管理サーバ。

（付記１３）
複数のドメインを経由して通信を行う場合において通信の発側ドメインにおける管理サーバであって、
パケットの送信元及び送信先に関するデータを含むパス設定要求を受信した場合、前記送信元アドレス及び送信先アドレスに対応して候補パスのデータを格納するパスデータ格納部を参照し、前記パス設定要求に係る候補パスを特定する候補パス特定ステップと、
前記パス設定要求に係る前記送信先に関するデータに基づき、前記パケットについてのルーティング・ポリシーを特定する手段と、
特定された前記候補パスの経路上におけるドメインの管理サーバに対して、管轄ドメイン内における、前記候補パスの動的帯域幅のデータを要求する手段と、
前記候補パスの経路上におけるドメインの管理サーバから、前記管轄ドメイン内における、当該候補パスの動的帯域幅のデータを受信した場合、前記候補パスについて前記発側ドメインにおける動的帯域幅のデータと前記候補パスの経路上におけるドメインにおける前記動的帯域幅のデータとに基づき前記候補パス全体の動的帯域幅を算出し、記憶装置に格納する手段と、
前記候補パス全体の動的帯域幅及び前記ルーティング・ポリシーに基づき、前記候補パスの中から最適パスを決定する手段と、
前記最適パスを特定するためのデータをパス設定要求元に送信する手段と、
を有する管理サーバ。

（付記１４）
特定のドメインにおける任意のノード間のパスの管理を行う管理サーバの指示に応じたルーティングを行うルータであって、
当該ルータを経由するパスを構成するリンクのうち直接接続された入力リンク及び出力リンクについてのラベル対と、ラベルとリンクの対応関係とを格納するデータ格納部と、
前記データ格納部を参照し、受信されたパケットに含まれる入力ラベルに対応する出力ラベル及びリンクを特定し、当該受信されたパケットのルーティングを行うルーティング手段と、
を有し、
複数のパスで共用される共用リンクについては同一のラベルが付されており、
前記データ格納部は、
前記ルータを経由するパスが複数のドメインを経由するパスであって前記ルータが属するドメインが当該パスの発ドメイン以外のドメインである場合には、前記ラベル対に対応して、前記ルータが属するドメイン内における、逆方向ルーティング時に分岐方向を特定するためのデータと前記パス全体を特定するためのデータをさらに格納している
ルータ。

本発明の実施の形態に係るネットワークの概要を説明するための図である。 （ａ）乃至（ｃ）は、ネットワークの概念図である。 （ａ）及び（ｂ）は、仮想ラベルを説明するための図である。 ルータの機能ブロック図である。 ラベルマップの一例を示す図である。 ルータのリンクテーブルの一例を示す図である。 ＬＰ管理サーバのリンクテーブルの一例を示す図である。 リンクデータ・テーブルの一例を示す図である。 ＬＰテーブルの一例を示す図である。 ＬＰ管理サーバの基本処理の処理フローを示す図である。 （ａ）及び（ｂ）は、静的透過帯域及び動的透過帯域について説明するための図である。 中継ノードと使用率及び動的な帯域幅の関係を説明するための図である。 待ち行列モデルを説明するための図である。 ＤＢ更新処理の処理フローを示す図である。 ドメインの範囲を説明するための図である。 複数のドメインを介したＬＰを構成するための処理フローを示す図である。 複数のドメインを経由するルーティングに用いられるＬＰ−ＤＢに格納されるデータの一例を示す図である。 ノードＥＲcにおけるラベルマップの一例を示す図である。 ノードＧＷＲcにおけるラベルマップの一例を示す図である。 ノードＧＷＲb2におけるラベルマップの一例を示す図である。 ノードＧＷＲb1におけるラベルマップの一例を示す図である。 ノードＧＷＲaにおけるラベルマップの一例を示す図である。 ノードＥＲaにおけるラベルマップの一例を示す図である。 最適ＬＰによりルーティングするための処理フロー（第１部分）を示す図である。 動的透過帯域を決定する際の具体例を示す図である。 最適ＬＰ決定処理の処理フローを示す図である。 （ａ）乃至（ｄ）は最適ＬＰ決定処理の具体例を示す図である。 最適ＬＰによりルーティングするための処理フロー（第２部分）を示す図である。 最適ＬＰによりルーティングするための処理フロー（第３部分）を示す図である。 コンピュータシステムの機能ブロック図である。

５ ルータ
５１ 使用率測定部 ５２ ルーティング処理部
５３ 優先制御部 ５４ ラベルマップ
５５ リンクテーブル

Claims (3)

1. 特定のドメインにおける任意のノード間のパスの管理を行う管理サーバにより実行される情報処理方法であって、
   前記特定のドメインに関連する発アドレスと前記特定のドメインとは異なるドメインに関連する着アドレスとの間のパスを構成する場合、前記特定のドメイン内において前記発アドレスに関連する第１のノードと、前記特定のドメイン内において第２のドメインに接続された第２のノードとの間における複数のパスを構成し、当該複数のパスのうち帯域幅が上位所定数のパスを登録パスとして特定し、前記発アドレス及び前記着アドレスと前記登録パスの各々につき登録パスに関するデータとをパスデータ格納部に格納するステップと、
   前記発アドレス及び前記着アドレスと前記登録パスの各々について前記登録パスの帯域幅のデータ及び前記第２のノードのデータとを含む構成依頼を、前記第２のドメインの管理サーバに送信するステップと、
   前記発アドレス及び前記着アドレスと前記登録パスの各々につき前記第２のドメイン側の接続ノードとの間の接続リンクに関するデータとを含む構成情報通知を、前記第２のドメインの管理サーバから受信した場合、前記発アドレス及び前記着アドレスと前記登録パスとの組み合わせに対応して前記接続リンクに関するデータを前記パスデータ格納部に格納するステップと、
   前記パスデータ格納部に格納されたデータを用いて、前記登録パスに関連する、前記特定のドメイン内のノードに対し、ルーティングのための設定を行うステップと、
   を含み、
   前記接続リンクに関するデータが、前記第２のノード以降の経路を代表する情報を含む
   ことを特徴とする情報処理方法。
2. 前記パスを構成する先頭リンクに、各ドメインにおいて一意のラベルが付されており、
   他のドメインとの接続部分のリンクについては、当該リンクが所属するドメインの識別情報及び当該ドメイン内のラベルにより特定され、
   前記登録パスに関するデータが、前記登録パスを構成するリンクのラベルを含む
   ことを特徴とする請求項１記載の情報処理方法。
3. 前記パスを構成する先頭リンクに、複数の所定のドメインにおいて一意のラベルが付されており、
   前記登録パスに関するデータが、前記登録パスを構成するリンクのラベルを含む
   ことを特徴とする請求項１記載の情報処理方法。

Images