JP2001136199A - ルーティング計算方式、ルーティング装置及びルーティング・システム - Google Patents

Abstract

(57)【要約】 【課題】 ネットワーク（ＮＷ）に付与されるメトリッ
クが頻繁に変更される場合においても、ルーティングの
ための計算量の肥大化を防止することができるルーティ
ング計算方式、ルーティングのための計算負荷の肥大化
を防止できるルーティング装置、及び、ＮＷが転送すべ
きコンテンツの伝送容量を保つことができるルーティン
グ・システムを提供する。 【解決手段】 ルーティング計算方式については、ＮＷ
を構成する各ノードを境界ノードとする最終ツリーか
ら、境界ノードからの距離順に全てのノードを連結した
距離順グラフを作成しておき、ＮＷのリンクに付与され
るメトリックが変更された時に、該距離順グラフにおい
て、当該リンクの両端ノードのうち境界ノードに近い最
短ノード以降のＮＷについてルーティング計算をする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ルーティング計算
方式、ルーティング装置及びルーティング・システムに
係り、特に、ネットワーク内のリンクに付与されるメト
リック（Metrics:ここでは、ネットワークの使用に伴う
価格など、パス又はルートを選択する基準を意味す
る。）が頻繁に変更される場合においても、ルーティン
グのための計算量の肥大化を防止することができるルー
ティング計算方式、ネットワーク内のリンクに付される
メトリックが頻繁に変更される場合においても、ルーテ
ィングのための計算負荷の肥大化を防止できるルーティ
ング装置、及び、ネットワークが転送すべきコンテンツ
（例えば、ビデオ・オン・デマンド・システムにおける
画像情報及び音声帯域情報のように、ビデオ・オン・デ
マンド・サービスを受けるユーザが必要とする情報のこ
とを意味する。）の伝送容量を保つことができるルーテ
ィング・システムに関する。

【０００２】インターネットの急速な普及に伴い、広域
のマルチメディア・ネットワークにおけるネットワーク
・プロバイダや、ビデオ・オン・デマンド・サービスな
ど情報を提供するインフォメーション・プロバイダが急
速に成長している。当然、これと共にネットワークを自
在に駆使してインフォメーションを獲得するユーザの数
も爆発的に伸びている。

【０００３】そして、近い将来には、インターネットで
はＩＥＴＦのIntegrated ServicesWorking Group やDif
ferentiated Services Working Group で検討されてい
るように、保証されたサービス品質による、異なる品質
のサービスが同一ネットワークで提供されると想定され
る。

【０００４】その際には、サービス品質別のネットワー
ク提供価格をどのように決定するかが重要な課題になる
と考えられる。ユーザの立場では高品質のサービスを低
価格で提供されることが望ましく、ネットワーク・プロ
バイダの立場では収益が最大になることが望ましく、社
会インフラとしてはネットワーク・リソースが最大に有
効活用されることが望ましいからである。

【０００５】このような、サービス品質を保証するサー
ビスが主流になる時代におけるサービス価格戦略は、ネ
ットワーク・プロバイダの収益とユーザの便益の和が大
きくなるという意味で、固定価格制に対して変動価格制
の方が優れているという検討結果がある。

【０００６】このように考えれば、将来は、ネットワー
クの利用率などによってメトリックが頻繁に変更される
ことが予想される。

【０００７】ところで、メトリックが頻繁に変更される
と、ルーティングのための計算量が肥大化し、又、当該
メトリック変更をネットワーク全体の構成要素に伝達
（flooding）する必要があるためにネットワークにおけ
るコンテンツの伝送容量を制限することになる。

【０００８】従って、メトリックが頻繁に変更される場
合においても、ルーティングのための計算量の肥大化を
防止することができるルーティング計算方式と、ルーテ
ィングのための計算負荷の肥大化を防止できるルーティ
ング装置、及び、ネットワークが転送すべきコンテンツ
の伝送容量を保つことができるルーティング・システム
の実現が必要になる。

【０００９】

【従来の技術】従来のルーティング計算の基本は、最短
パス優先（ＳＰＦ：Shortest Path First 又はＯＳＰ
Ｆ：Open Shortest Path First）アルゴリズムによるル
ーティング計算である。これは、ダイクストラ（Dijkst
ra）のアルゴリズムとも呼ばれる。

【００１０】図１７は、最短パス優先アルゴリズムを説
明するためのネットワーク・トポロジの例である。

【００１１】図１７においては、ａからｌまでの１２の
ノードによって構成される単純なネットワークが示され
ている。そして、ノード間に引かれた実線がネットワー
クを構成するリンクで、リンクの脇に記載されているア
ラビア数字は当該リンクのメトリックである。最短パス
優先アルゴリズムという名にあやかれば、メトリックは
距離であるとしてもよいが、当該リンクのを使用する時
の価格であるとしてもよい。即ち、メトリックはルート
を選択するための基準となりうる物理量なら何でもよ
い。

【００１２】図１８は、最短パス優先アルゴリズムを説
明するフローチャートである。

【００１３】又、図１９乃至図２３は、最短パス優先ア
ルゴリズムによる最終ツリーの作成を説明する図で、図
１９は最短パス優先アルゴリズムによる最終ツリーの作
成（その１）であり、図２３は最短パス優先アルゴリズ
ムによる最終ツリーの作成（その５）である。これら
は、最終ツリーの作成までを１ステップ毎に図示したも
のである。

【００１４】以降、図１９乃至図２３を参考にしなが
ら、図１８の符号に沿って最短パス優先アルゴリズムを
説明する。

【００１５】尚、元々ダイクストラのアルゴリズムは、
リンクの長さをメトリックとしてルーティング計算をす
るものであるので、最短パスとか、ノードが近いか遠い
という表現を用いるが、メトリックとして他の選択基準
を採用する場合にも、同じ手法でルーティング計算でき
る。従って、以降において距離的感覚の言葉はあまり意
味がなく、習慣に従って使っているだけであると理解さ
れたい。

【００１６】Ｓ６１．ネットワークのノードの中から境
界ノードを１つ選定する。

【００１７】図１９乃至図２３の例では、ノードａを境
界ノードに設定している。

【００１８】Ｓ６２．境界ノードに隣接するノード（こ
れを「隣接ノード」と呼ぶことにする。）を抽出する。
抽出される隣接ノードの数をｍ（ｍは正の整数）とす
る。

【００１９】これは、実際には、各ノードに接続される
ノードをノード毎に求めたテーブルを参照して行なう
が、ここでは視覚的に表現する。即ち、図１９（イ）の
中間ツリーに示す如く、ノードｂとノードｃが隣接ノー
ドとして抽出される。従って、この場合にはｍ＝２であ
る。

【００２０】Ｓ６３．抽出された隣接ノード毎にメトリ
ックが最小のリンクを選択して、始点となるノード（即
ちノードａ）と連結する。

【００２１】この場合、ノードｂへのリンクは唯一であ
るからリンクａｂが選択され、ノードａとノードｂが連
結される。

【００２２】そして、ノードａとノードｂを連結する時
には、同時に、ノードａとノードｂとの間の距離が計算
されて、格納される。

【００２３】Ｓ６４．（ｍ−１）を計算してｍを更新す
る。

【００２４】この場合、最初のｍは２であるから、（ｍ
−１）＝１に更新される。

【００２５】Ｓ６５．更新されたｍが０であるか否かを
判定する。

【００２６】Ｓ６６．更新されたｍが０でない場合（Ｎ
ｏ）には、始点ノードに連結されたノードを抽出ノード
から除外して、ステップＳ６３にジャンプする。

【００２７】この時には、抽出されたノードのうちノー
ドｃが残っているので、ノードｃとノードａの間の最短
リンクを抽出して始点ノード（ノードａ）と連結する。

【００２８】次いで、ステップＳ６４で（ｍ−１）を計
算してｍを更新する。ここでは、ｍは０に更新される。

【００２９】そして、ステップＳ６５ではｍは０に等し
いと判定される（Ｙｅｓ）ので、ステップＳ６７に移行
する。

【００３０】Ｓ６７．全てのノードを最終ツリーに連結
したか否か判定する。

【００３１】Ｓ６８．全てのノードを最終ツリーに連結
していなければ（Ｎｏ）、この段階での最終ツリーに対
する隣接ノードを抽出（この場合にも、隣接ノード数を
ｍとする。）して、ステップＳ６３にジャンプする。

【００３２】この場合には、図２０に示す如く、ノード
ｄ、ノードｅ及びノードｆが抽出され、以降、この３つ
のノードが連結されるまでステップＳ６３乃至ステップ
Ｓ６６を繰り返す。

【００３３】既に詳細に説明したので、図２０以降の説
明は簡単にする。

【００３４】この中で、特殊なケースは図２１である。

【００３５】図２１（イ）の中間ツリーは、ノードｆと
ノードｅとノードｄを端のノードとする最終ツリーに隣
接する隣接ノードを抽出した段階であり、図２１（ロ）
の最終ツリーは、ノードａから最短のノードを連結した
段階である。

【００３６】ここで、リンクｆｅは中間ツリーに入って
いるが、先に求められているルートａｂｅの距離と、こ
の段階におけるルートａｃｆｅの距離が等しいので、最
終ツリーからは除外されている。

【００３７】上記のようにして最終ツリーが拡充、作成
されてゆき、図２３（ロ）の最終ツリーに示す如き最短
パス優先アルゴリズムによるツリーができあがる。

【００３８】Ｓ６９．ステップＳ６７で、全てのノード
を最終ツリーに連結したと判定された場合（Ｙｅｓ）に
は、全てのノードを境界ノードとして最終ツリーを作成
したか否かを判定する。

【００３９】全てのノードを境界ノードとして最終ツリ
ーを作成していないと判定された場合（Ｎｏ）には、ス
テップＳ６１にジャンプして、全てのノードを境界ノー
ドとして最終ツリーを作成するまで、ステップＳ６１乃
至ステップＳ６９を繰り返す。

【００４０】そして、最終的に、全てのノードを境界ノ
ードとして最終ツリーを作成することができるので、全
てのノードを境界ノードして最終ツリーを作成したと判
定されて（Ｙｅｓ）、最短パス優先アルゴリズムによる
ルーティング計算を終了する。

【００４１】そして、このようにして作成された全ての
最終ツリーを参照してルーティングが行なわれる。

【００４２】例えば、ノードａを始点ノードとしてノー
ドｈとの間でルーティングする場合には、ノードａを境
界ノードとした最終ツリーにおいて、ノードｈがノード
ａと連結されるルートを検索すればよく、この場合、ル
ートａｂｄｈが選択される。又、ノードｅを始点ノード
としてノードｋを終点ノードとするルートを検索するに
は、ノードｅを境界ノードとした最終ツリーにおいて、
ノードｋがノードｅと連結されるルートを検索すればよ
く、図示はしないが、ルートｅｆｉｋが選択される。

【００４３】従って、全てのノードを境界ノードとした
最終ツリーを作成しておけば、始点ノードと終点ノード
を指定することによって最短ルートを容易に選定するこ
とができる。この意味で、最短パス優先アルゴリズム又
はダイクストラのアルゴリズムはルーティング・アルゴ
リズムの基本とされているのである。

【００４４】

【発明が解決しようとする課題】しかし、全てのノード
を境界ノードとした最終ツリーを作成しておき、始点ノ
ードと終点ノードを指定することによって最短ルートを
容易に選定することができるのは、既存のインターネッ
トの如く、リンクに付与されるメトリックが固定の場合
である。

【００４５】最初に、インターネットの急速な普及に伴
って広域のマルチメディア・サービスが急速に成長して
いると記載したが、既存のインターネットで提供されて
いるサービスはベスト・エフォート型のサービスで、そ
の時々のトラフィック状態によってサービス・グレード
が変わるという、信頼性の低いサービスである。

【００４６】さて、インターネットでのルートの選択
は、転送すべきコンテンツを流すルートを決定すること
である。しかも、マルチメディア化に伴って、コンテン
ツの多様化が進んでおり、且つ、画像や音声の如く切れ
目なく転送できることが必要なコンテンツの割合が増加
している。

【００４７】このような背景にあっては、トラフィック
状態にかかわらずサービス品質（Quality of Service：
ＱｏＳ又はＱＯＳと略記される。）を保証することがで
きるサービスが必要であり、マルチメディア化の一層の
発展によって、サービス品質保証型のサービスが主流に
なると考えられる。

【００４８】このような、サービス品質を保証するサー
ビスが主流になる時代におけるサービス価格戦略は、ネ
ットワーク・プロバイダの収益とユーザの便益の和が大
きくなるという意味で、固定価格制に対して変動価格制
の方が優れているので、将来は、ネットワークの利用率
などによってメトリックが頻繁に変更されるようにな
る。

【００４９】しかし、メトリックが頻繁に変更される
と、まず第一に、ルーティングのための計算量が肥大化
し、ネットワークに対する負荷が大きくなるという問題
が生ずる。

【００５０】又、第二に、当該メトリック変更をネット
ワーク全体の構成要素に伝達（flooding）する必要があ
るためにネットワークにおけるコンテンツの伝送容量を
制限することになるという問題が生ずる。

【００５１】本発明は、かかる問題点に鑑みネットワー
ク内のリンクに付与されるメトリックが頻繁に変更され
る場合においても、ルーティングのための計算量の肥大
化を防止することができるルーティング計算方式、ネッ
トワーク内のリンクに付されるメトリックが頻繁に変更
される場合においても、ルーティングのための計算負荷
の肥大化を防止できるルーティング装置、及び、ネット
ワークが転送すべきコンテンツの伝送容量を保つことが
できるルーティング・システムを提供することを目的と
する。

【００５２】

【課題を解決するための手段】本発明の第一の手段は、
メトリックに変更があってもルーティングのための計算
量が肥大化しないルーティング計算方式である。

【００５３】ルーティング計算方式の説明に先立って、
「距離順グラフ」と「距離順最短ルートテーブル」につ
いて説明しておく。

【００５４】図４が距離順グラフと最短変更ノードの例
で、図５が距離順最短ルート・テーブルの例で、双方共
図１７に示したネットワーク・トポロジから作成したも
のである。

【００５５】図１７に示したネットワーク・トポロジに
おいて、境界ノードがノードａの場合の最終ツリーは図
２３のようになるが、最終ツリーにおいて境界ノードａ
からの距離順に、形式的にノードを連ねたものが図４
（イ）の距離順グラフである。そして、境界ノードａか
らの距離順に各ノードを並べ、ノードａからのメトリッ
クの和と、最終ツリー上でのノードａからのルートを示
したものが図５の距離順最短ルート・テーブルである。
いずれも同一情報を示すものであるが、ルーティング計
算方式の説明には距離順グラフを用いる。

【００５６】尚、「最短変更ノード」については、後に
説明される。

【００５７】図１は、メトリック変更時にルーティング
計算を行なう場合の手順で、本発明のルーティング計算
方式における第一の手順である。尚、図１は、図１７の
ネットワーク・トポロジにおいて、ノードｅとノードｆ
間のリンクのメトリックが変更になった場合を例にした
ものである。

【００５８】該第一の手順においては、図１７のネット
ワーク・トポロジにおいて、ノードｅとノードｆ間のリ
ンクのメトリックが変更になった場合、先ず、距離順グ
ラフにおいてメトリックが変更になったリンクの両端の
ノード（これを「両端ノード」と呼ぶことにする。）を
抽出し、次いで、両端ノードのうち境界ノードであるノ
ードａに近い方のノード（これを「最短変更ノード」と
呼ぶことにする。）を抽出し、最終的に、最短変更ノー
ド以降について最短パス優先アルゴリズムによってルー
ティング計算を行なう。図１の例の場合、ノードｆ以降
についてルーティング計算をやり直す。即ち、当該メト
リック変更には無関係なノードａからノードｆまではル
ーティング計算を行なわない。

【００５９】該第一の手順によれば、メトリックに変更
があった場合にネットワーク・トポロジ全体にわたって
ルーティング計算をせずに、当該メトリック変更の影響
を受ける可能性のある最短変更ノード以降についてのみ
ルーティング計算のやり直しをするので、メトリック変
更に伴うルーティング計算の負荷を軽減することができ
る。そして、パスの要求があった場合には、上記ルーテ
ィング計算の結果を参照してルーティングを行なう。

【００６０】図２は、ネットワークのユーザからのパス
要求時にルーティング計算を行なう場合の手順で、本発
明のルーティング計算方式における第二の手順である。
尚、図２は、図１７のネットワーク・トポロジを基本に
したものである。

【００６１】さて、ルーティング計算はパス要求時に行
なうが、それとは無関係にネットワーク・プロバイダが
メトリックが変更されることがある。

【００６２】従って、該第二の手順においては次の手順
によってルーティング計算を実施する。

【００６３】先ず、メトリックに変更があった場合に
は、最短変更ノードの更新が必要か否かを判断して、最
短変更ノードの更新が必要な場合には最短変更ノードの
変更を行なっておく。

【００６４】図２（イ）が上記処理を示している。これ
は、当初の最短変更ノードがノードｄであった時に、ノ
ードｅとノードｆとの間のリンクのメトリックが変更に
なった場合を例に示している。

【００６５】図２（イ）に示している距離順グラフにお
いて、両端ノードはノードｆとノードｅである。このう
ち境界ノードａに近いノードはノードｆであるから、ノ
ードｆとノードｄのいずれが境界ノードａに近いかを判
定する。

【００６６】この例では、ノードｆがノードｄよりノー
ドａに近いので、最短変更ノードをノードｆに変更して
おく。

【００６７】一方、ノードｅとノードｇの間のリンクで
メトリックが変更になったとすると、両端ノードのうち
ノードａに近いノードｅは、ノードａからの距離がノー
ドｄより大きいので、この場合には最短変更ノードの更
新は行なわない。

【００６８】次いで、パス要求があった時にルーティン
グ計算を行なう。即ち、要求パスの両端ノードのうち境
界ノードに近いノードより、最短変更ノードが境界ノー
ドに近い場合に、図２（ロ）に示す如く、パス要求があ
った時に最短変更ノードであるノードｆ以降終点ノード
までについてルーティング計算を行ない、最短変更ノー
ド・テーブルの格納ノードを該終点ノードに更新し、要
求パスの両端ノードのうち境界ノードに近いノードよ
り、最短変更ノードが境界ノードから遠い場合に、ルー
ティング計算を行なわない。

【００６９】該第二の手順によれば、メトリックに変更
があった場合には最短変更ノードのみを更新しておき、
パス要求時には、要求パスの両端ノードのうち境界ノー
ドに近いノードより、最短変更ノードが境界ノードに近
い場合に、図２（ロ）に示す如く、パス要求があった時
に最短変更ノードであるノードｆ以降終点ノードまでに
ついてルーティング計算を行ない、最短変更ノード・テ
ーブルの格納ノードを該終点ノードに更新し、要求パス
の両端ノードのうち境界ノードに近いノードより、最短
変更ノードが境界ノードから遠い場合に、ルーティング
計算を行なわないので、メトリックの変更に伴うルーテ
ィング計算の負荷を軽減することができる。

【００７０】本発明の第二の手段は、メトリックの変更
とパスの要求を受け付け、上記ルーティング計算方式の
第一の手順と第二の手順とを備えて、両手順の計算量の
大小によって第一の手順又は第二の手順を選択してルー
ティング計算を行ない、ルーティング計算の結果を回答
するルーティング装置である。

【００７１】図３はルーティング計算の計算量を示す図
である。

【００７２】図３において、縦軸はルーティング計算の
計算量、横軸はメトリック変更頻度である。

【００７３】メトリックの変更時にルーティング計算を
行なう場合の計算内容は最短パス優先アルゴリズムによ
るルーティング計算だけであり、当然、メトリック変更
頻度に比例する。

【００７４】一方、パス要求時にルーティング計算を行
なう場合の計算内容は、最短変更ノードの更新に伴う計
算と、最短パス優先アルゴリズムによるルーティング計
算である。

【００７５】従って、この場合の計算量は、最短変更ノ
ードの更新に伴う計算の計算量と、パス要求時の最短パ
ス優先アルゴリズムによるルーティング計算の計算量の
和に等しくなる。そして、メトリック変更頻度が低い間
は最短パス優先アルゴリズムによるルーティング計算の
計算量はパス要求頻度に比例する。

【００７６】このため、メトリック変更時にルーティン
グ計算をする場合の計算量と、パス要求時にルーティン
グ計算をする場合の計算量の関係は、パス要求頻度が高
い場合には図３の如く、メトリック変更頻度が場合には
パス要求時にルーティング計算をする方が、メトリック
変更時にルーティング計算をするより計算量が大きくな
る可能性がある。

【００７７】しかし、この場合においても、メトリック
の変更頻度が高くなると、最短変更ノードが徐々に境界
ノードに近くなって最短変更ノードの更新が不要になる
ケースが増加し、最短変更ノードの更新が不要になるケ
ースが増加すれば、最短変更ノードに更新がない場合に
は両端ノードのうち境界ノードに近いノード以降につい
てのみ最短パス優先アルゴリズムによるルーティング計
算をすればよいケースが増加する。

【００７８】このため、パス要求時にルーティング計算
をする場合の計算量は、メトリック変更頻度が高くなる
と、メトリック変更時にルーティングをする場合の計算
量より少なくなり、両者の計算量は図３に示すように交
叉する可能性がある。

【００７９】又、メトリックに変更があってもパス要求
が非常に少なければ、パス変更時にルーティング計算を
する方が、メトリック変更時にルーティング計算するよ
り常に計算量が少ない可能性もある。

【００８０】そこで、本発明の第二の手段によって、そ
の時々のメトリック変更頻度とパス要求頻度に対するル
ーティング計算の計算量を推定して、両者の計算量の大
小によってルーティング計算方式を選択することによっ
て、メトリック変更に伴うルーティング計算の計算量を
抑圧することができる。

【００８１】この事実から、その時々のメトリック変更
頻度とパス要求頻度に対するルーティング計算の計算量
を推定して、両者の計算量の大小によってルーティング
計算方式を選択するルーティング装置をネットワーク内
に設けることによって、メトリック変更に伴うネットワ
ークの計算負荷を低下させることができる。

【００８２】本発明の第三の手段は、該ルーティング装
置をネットワーク内に配置するに当たって、メトリック
の変更とパスの要求とルーティング計算の結果の回答を
転送するネットワークを、コンテンツを転送するネット
ワークから独立させるルーティング・システムである。

【００８３】本発明の第三の手段によれば、メトリック
の変更をコンテンツを転送するネットワークによって伝
達する必要がなくなり、ルーティング情報をコンテンツ
を転送するネットワークによって伝達する必要がなくな
るので、コンテンツを転送するネットワークの伝送容量
を圧迫することがなくなる。

【００８４】又、該ルーティング装置は、ネットワーク
・プロバイダが保有するネットワークに対応して配置す
る必要がない。従って、ルーティング装置自体の数が少
なくてもよく、ルーティング・システムを構成するネッ
トワーク・リソースの肥大化を防止することができる。

【００８５】更に、上記の如くルーティング・システム
をネットワーク・プロバイダが保有するネットワークか
ら独立させることにより、ネットワーク・プロバイダに
よる恣意的なネットワーキングを防止することができる
ので、公正なネットワーク運営が可能になるという利点
も生ずる。

【００８６】

【発明の実施の形態】図６は、メトリック変更時にルー
ティング計算をする場合の処理手順（その１）で、メト
リック変更時に行なうルーティング計算の手順を示して
いる。

【００８７】又、図８は、メトリック変更時のルーティ
ング計算に必要なデータで、この場合には、距離順最短
ルート情報が必要である。尚、図８の距離順最短ルート
情報は、図１７のネットワーク・トポロジに基づくもの
で、しかも、ノードａを境界ノードとする距離順最短ル
ート情報である。

【００８８】以降、図８を参照しながら、図６の符号に
沿ってメトリック変更時に行なうルーティング計算の手
順を説明する。

【００８９】Ｓ１．常に、メトリックに変更があったか
否かを判定している。

【００９０】メトリックに変更がない場合（Ｎｏ）に
は、メトリックに変更があったか否かの判定を継続して
行なう。

【００９１】Ｓ２．ステップＳ１で、メトリックに変更
があったと判定した場合（Ｙｅｓ）には、メトリックに
変更があったリンクの両端ノードを抽出する。

【００９２】図１７のネットワーク・トポロジにおい
て、ノードｅとノードｆの間のリンクでメトリックが変
更になったとすれば、抽出される両端ノードはノードｅ
とノードｆである。

【００９３】Ｓ３．距離順最短ノード・テーブルから、
境界ノードを指定して距離順最短ルート情報を読み出
す。

【００９４】今は、ノードａを境界ノードとする距離順
最短ルート情報が読み出されている（図８）。

【００９５】Ｓ４．ステップＳ３で読み出した距離順最
短ルート情報において、最短変更ノードを抽出する。

【００９６】ステップＳ２で抽出された両端ノードは、
ノードｅとノードｆである。これと図８の距離順最短ル
ート情報を対比すると、最短変更ノードはノードｆであ
ることが判る。

【００９７】Ｓ５．最短変更ノード以降のネットワーク
について、最短パス優先アルゴリズムによるルーティン
グ計算を行なう（図では、単に「ＳＰＦ」と略記してい
る。同様な標記法を以降も使用することがある。）。

【００９８】従って、ノードｆ以降のネットワークにつ
いて最短パス優先アルゴリズムによるルーティング計算
を行なう。

【００９９】Ｓ６．ステップＳ５で行なったルーティン
グ計算の結果によって、ステップＳ３で読み出した距離
順最短ルート情報を更新する。

【０１００】Ｓ７．全ての境界ノードに対して、メトリ
ック変更に伴う距離順最短ルート情報の更新を行なった
か否か判定する。

【０１０１】全ての境界ノードに対して、メトリック変
更に伴う距離順最短ルート情報の更新を行なっていない
と判定した場合（Ｎｏ）には、ステップＳ３にジャンプ
して、全ての境界ノードに対してメトリック変更に伴う
距離順最短ルート情報の更新を完了するまで、ステップ
Ｓ３乃至ステップＳ７の処理を継続する。

【０１０２】一方、全ての境界ノードに対して、メトリ
ック変更に伴う距離順最短ルート情報の更新を行なった
と判定した場合（Ｙｅｓ）には、この処理を終了する。

【０１０３】図７は、メトリック変更時にルーティング
計算をする場合の処理手順（その２）で、パス要求があ
った時の手順を示している。

【０１０４】以降、図７の符号に沿ってパス要求があっ
た時の手順を説明する。

【０１０５】Ｓ１１．常に、パス要求があったか否かを
判定している。

【０１０６】パス要求がなかったと判定した場合（Ｎ
ｏ）には、パス要求があったか否かの判定を継続する。

【０１０７】Ｓ１２．ステップＳ１１で、パス要求があ
ったと判定した場合（Ｙｅｓ）には、距離順最短ルート
・テーブルを検索して、要求されたパスの始点ノードと
同じノードが境界ノードになっている距離順最短ルート
情報を読み出す。

【０１０８】尚、パスの要求には、ユーザが希望するメ
トリックとパスの特性が添付されている。

【０１０９】Ｓ１３．ステップＳ１２で読み出された距
離順最短ルート情報において、要求されたルートの終点
ノードを検索し、始点ノード（境界ノードと同じノード
である。）から終点ノードまでのメトリックを読み出
す。

【０１１０】例えば、始点ノードがノードａで、終点ノ
ードがノードｇである場合には、図８の距離順最短ルー
ト情報から、要求されたルートのメトリックは１５であ
ることが判る。

【０１１１】Ｓ１４．ステップＳ１３で求められたメト
リックは、パス要求時に指定されたメトリックを満足す
るか否かを判定する。

【０１１２】Ｓ１５．ステップＳ１４で、ステップＳ１
３で求められたメトリックがパス要求時に指定されたメ
トリックを満足すると判定した場合（Ｙｅｓ）には、パ
スの特性を格納しているパス特性テーブルを検索して、
要求されたパスの特性（パスの特性はとりもなおさずサ
ービス品質であるので、図では、「ＱＯＳ」と略記して
いる。同様な標記法を以降も使用することがある。）を
読み出す。

【０１１３】尚、パスの特性としては、伝播遅延時間、
ジッターや符号誤り率などが考えられる。

【０１１４】Ｓ１６．ステップＳ１５で読み出したサー
ビス品質はパス要求に付されていたサービス品質を満足
するか否か判定する。

【０１１５】Ｓ１７．ステップＳ１６で、ステップＳ１
５で読み出したサービス品質がパス要求に付されていた
サービス品質を満足すると判定された場合（Ｙｅｓ）に
は、要求されたパスがユーザの要求を満足する旨（Ｏ
Ｋ）と、要求されたパスのルートと、当該ルートのサー
ビス品質を返信して処理を終了する。

【０１１６】一方、ステップＳ１４で、要求パスに対応
するルートのメトリックが要求されたメトリックを満足
しないと判定された場合（Ｎｏ）、又は、ステップＳ１
６で、要求パスに対応するルートのサービス品質が要求
されたサービス品質を満足しないと判定された場合（Ｎ
ｏ）には、要求されたパスがユーザの要求を満足しない
旨（ＮＧ）を返信して処理を終了する。

【０１１７】もし、パス要求に付されているメトリック
やサービス品質が複数ある場合には、複数の要求メトリ
ックに対してメトリックの高い順にステップＳ１４の判
定を行ない、全てを満足しない場合のみ要求メトリック
を満足しない旨（ＮＧ）を返信し、又、複数の要求サー
ビス品質に対してサービス品質が高い順にステップＳ１
６の判定を行ない、全てを満足しない場合のみ要求サー
ビス品質を満足しない旨（ＮＧ）を返信し、メトリック
やサービス品質の妥協が成立したところで要求されたパ
スがユーザの要求を満足する旨（ＯＫ）を返信すればよ
い。

【０１１８】上記の処理手順は、当業者には容易に想到
しうるので、ここでは図示を省略する。

【０１１９】即ち、メトリック変更時にルーティング計
算をする場合には、メトリック変更時に全ての境界ノー
ドについて距離順最短ルート情報を更新しておき、パス
要求があった時に当該パスの始点ノードと同じ境界ノー
ドを有する距離順最短ルート上で選択されるルートが要
求メトリックと要求サービス品質を満足するか否かを判
定してルートを決定するという手順をとる。

【０１２０】従って、ルーティング計算の計算量を縮減
することができる。

【０１２１】次いで、パス要求時にルーティング計算を
する場合の処理手順について説明する。

【０１２２】図９は、パス要求時にルーティング計算を
する場合の処理手順（その１）で、メトリックに変更が
あった時の手順を示している。

【０１２３】又、図１１には、パス要求時のルーティン
グ計算に必要なデータを示している。

【０１２４】以降、図１１を参照しながら、図９の符号
に沿ってメトリックに変更があった時の手順について説
明する。

【０１２５】Ｓ２１．常に、メトリックに変更があった
か否かを監視している。

【０１２６】メトリックに変更がなかったと判定された
場合（Ｎｏ）には、メトリックに変更があったか否かの
監視を継続する。

【０１２７】Ｓ２２．ステップＳ２１で、メトリックに
変更があったと判定された場合（Ｙｅｓ）には、メトリ
ックが変更されたリンクの両端ノードを抽出する。

【０１２８】この場合、ノードｅとノードｆとによって
形成されるリンクでメトリックが変更されたものとする
と、両端ノードはノードｅとノードｆである。

【０１２９】Ｓ２３．距離順最短ノード・テーブルか
ら、境界ノードを指定して距離順最短ルート情報（図１
１（イ））と、最短変更ノード情報（図１１（ロ））を
読み出す。

【０１３０】今は、ノードａを境界ノードとする距離順
最短ルート情報と、最短変更ノード情報としてノードｄ
が読み出されている。

【０１３１】Ｓ２４．ステップＳ２２で抽出した両端ノ
ードのうち、境界ノードに近いノードを抽出する。

【０１３２】この場合、境界ノードに近いノードはノー
ドｆである。

【０１３３】Ｓ２５．境界ノードに対して、最短変更ノ
ードはステップＳ２２で抽出した両端ノードのうち、境
界ノードに近いノード（図では「最近ノード」と略記し
ている。以降も、同様な標記法を使用することがあ
る。）より近いか否かを判定する。

【０１３４】Ｓ２６．ステップＳ２５で、境界ノードに
対して、最短変更ノードは、ステップＳ２２で抽出した
両端ノードのうち境界ノードに近いノードより遠いと判
定された場合（Ｎｏ）には、最短変更ノード・テーブル
に格納するノードを、ステップＳ２２で抽出した両端ノ
ードのうち境界ノードに近いノードに更新する。

【０１３５】この場合、ノードｆはノードｄより境界ノ
ードに近いので、最短変更ノード・テーブルに格納する
ノードをノードｆに更新する。

【０１３６】一方、ステップＳ２５で、境界ノードに対
して、最短変更ノードは、ステップＳ２２で抽出した両
端ノードのうち境界ノードに近いノードより近いと判定
された場合（Ｙｅｓ）には、最短変更ノード・テーブル
に格納するノードを更新しない。

【０１３７】Ｓ２７．ステップＳ２５で境界ノードに対
して、最短変更ノードは、ステップＳ２２で抽出した両
端ノードのうち境界ノードに近いノードより近いと判定
された場合（Ｙｅｓ）、又は、ステップＳ２６の処理を
終了した場合、全ての距離順最短ルート情報に対して上
記処理をしたか否か判定する。

【０１３８】全ての距離順最短ルート情報に対して上記
処理をしてないと判定された場合（Ｎｏ）には、ステッ
プＳ２３にジャンプして、全ての距離順最短ルート情報
に対して上記処理を完了するまで、ステップＳ２３乃至
ステップＳ２７を繰り返す。

【０１３９】一方、全ての距離順最短ルート情報に対し
て上記処理を完了したと判定された場合（Ｙｅｓ）に
は、上記処理を終了する。

【０１４０】図１０は、パス要求時にルーティング計算
をする場合の処理手順（その２）で、パス要求があった
時の手順を示している。

【０１４１】以降、図１０の符号に沿ってパス要求があ
った時の手順を説明する。

【０１４２】Ｓ３１．常に、パス要求があったか否かを
判定している。

【０１４３】パス要求がなかったと判定した場合（Ｎ
ｏ）には、パス要求があったか否かの判定を継続する。

【０１４４】Ｓ３２．ステップＳ３１で、パス要求があ
ったと判定した場合（Ｙｅｓ）には、距離順最短ルート
・テーブルを検索して、要求されたパスの始点ノードと
同じノードが境界ノードになっている距離順最短ルート
情報と、付随する最短変更ノード情報を読み出す。

【０１４５】更に、距離順最短ルート情報において、要
求されたルートの終点ノードを検索する。

【０１４６】尚、パスの要求には、ユーザが希望するメ
トリックとパスの特性が添付されている。

【０１４７】Ｓ３３．境界ノードに対して、要求終点ノ
ードは最短変更ノードより近いか否かを判定する。

【０１４８】Ｓ３４．ステップＳ３３で、境界ノードに
対して、要求終点ノードは最短変更ノードより遠いと判
定された場合（Ｎｏ）には、最短変更ノード以降要求終
点ノードまで最短パス優先アルゴリズムによるルーティ
ング計算を行なう。

【０１４９】Ｓ３５．最短変更ノード・テーブルに格納
するノードを、要求終点ノードに更新する。

【０１５０】これは、最短変更ノード以前のネットワー
クについてはルーティング計算が確定しており、今、最
短変更ノード以降要求終点ノードまでのルーティング計
算が確定したので、形式的に要求終点ノードを最短変更
ノードとすればよいからである。

【０１５１】Ｓ３６．ステップＳ３３で、境界ノードに
対して、要求終点ノードは最短変更ノードより近いと判
定された場合（Ｙｅｓ）、又は、ステップＳ３５の処理
が終了したら、要求されたパスの始点ノード（境界ノー
ドと同じノードである。）から終点ノードまでのメトリ
ックを読み出す。

【０１５２】例えば、始点ノードがノードａで、終点ノ
ードがノードｇである場合には、図１１の距離順最短ル
ート情報から、要求されたルートのメトリックは１５で
あることが判る。

【０１５３】Ｓ３７．ステップＳ３６で求められたメト
リックは、パス要求時に指定されたメトリックを満足す
るか否かを判定する。

【０１５４】Ｓ３８．ステップＳ３７で、ステップＳ３
６で求められたメトリックがパス要求時に指定されたメ
トリックを満足すると判定した場合（Ｙｅｓ）には、パ
スの特性を格納しているパス特性テーブルを検索して、
要求されたサービス品質を読み出す。

【０１５５】尚、パスの特性としては、伝播遅延時間、
ジッターや符号誤り率などが考えられる。

【０１５６】Ｓ３９．ステップＳ３８で読み出したサー
ビス品質はパス要求に付されていたサービス品質を満足
するか否か判定する。

【０１５７】Ｓ４０．ステップＳ３９で、ステップＳ３
８で読み出したサービス品質がパス要求に付されていた
サービス品質を満足すると判定された場合（Ｙｅｓ）に
は、要求されたパスがユーザの要求を満足する旨（Ｏ
Ｋ）と、要求されたパスのルートと、当該ルートのサー
ビス品質を返信して処理を終了する。

【０１５８】一方、ステップＳ３７で、要求パスに対応
するルートのメトリックが要求されたメトリックを満足
しないと判定された場合（Ｎｏ）、又は、ステップＳ３
９で、要求パスに対応するルートのサービス品質が要求
されたサービス品質を満足しないと判定された場合（Ｎ
ｏ）には、要求されたパスがユーザの要求を満足しない
旨（ＮＧ）を返信して処理を終了する。

【０１５９】もし、パス要求に付されているメトリック
やサービス品質が複数ある場合には、複数の要求メトリ
ックに対してメトリックの高い順にステップＳ３７の判
定を行ない、全てを満足しない場合のみ要求メトリック
を満足しない旨（ＮＧ）を返信し、又、複数の要求サー
ビス品質に対してサービス品質が高い順にステップＳ３
９の判定を行ない、全てを満足しない場合のみ要求サー
ビス品質を満足しない旨（ＮＧ）を返信し、メトリック
やサービス品質の妥協が成立したところで要求されたパ
スがユーザの要求を満足する旨（ＯＫ）を返信すればよ
い。

【０１６０】ただ、上記の処理手順は、当業者には容易
に想到しうるので、ここでは図示を省略する。

【０１６１】即ち、パス要求時にルーティング計算をす
る場合には、メトリック変更時に全ての境界ノードにつ
いて最短変更ノード情報を更新しておき、パス要求があ
った時に当該パスの始点ノードと同じ境界ノードを有す
る距離順最短ルート上で選択すべきルートを計算し、当
該ルートが要求メトリックと要求サービス品質を満足す
るか否かを判定してルートを決定するという手順をと
る。

【０１６２】従って、ルーティング計算の計算量を縮減
することが可能になる。

【０１６３】さて、図６以降図１１によって説明したル
ーティング計算の対象となったネットワークは図１７に
示したネットワークで、単独のノードを連結した形態の
ネットワーク、即ち、自律ネットワークであるが、本発
明のルーティング計算方式は自律ネットワーク内に限ら
れるものではない。

【０１６４】図１２は、自律ネットワークを含むネット
ワークにおける最短パス優先アルゴリズムの適用を説明
する図である。

【０１６５】図１２は、単独ノードであるノードａ、ノ
ードｂ及びノードｃと、自律ネットワークＡ及び自律ネ
ットワークＢよりなるネットワークによって、全体のネ
ットワークが構成されている例を示している。

【０１６６】ここで、自律ネットワークＡは、外部との
インタフェースとなるノード（これを、インタフェース
・ノードと呼ぶことにする。）として、ノードｄ、ノー
ドｅ及びノードｆを備えており、自律ネットワークＢ
は、インタフェース・ノードとしてノードｇ、ノードｈ
及びノードｉを備えているものとする。

【０１６７】尚、自律ネットワークＡ及び自律ネットワ
ークＢは上記ノードだけではなく、もっと多数のノード
を備えた複雑なネットワークであるが、自律ネットワー
クの外部からはインタフェース・ノードだけが見えるこ
とを図１２では示している。

【０１６８】そして、図１２では、ノードａに収容され
ているユーザＡと、自律ネットワークＢの中のインタフ
ェース・ノードｉに収容されているユーザＢの間で最短
パス優先アルゴリズムによるルーティング計算を行なう
ものとして、自律ネットワークを含むネットワークにお
ける最短パス優先アルゴリズムの適用を説明する。

【０１６９】この場合、自律ネットワーク内のメトリッ
クとしては、自律ネットワークＡ内におけるネットワー
ク・トポロジの詳細は無視し、自律ネットワーク内のイ
ンタフェース・ノード間の等価的メトリックを用いる。

【０１７０】即ち、自律ネットワークＡについては、図
１２に破線で示している如く、インタフェース・ノード
ｄ、インタフェース・ノードｅ及びインタフェース・ノ
ードｆ間のメトリックだけに着目し、自律ネットワーク
Ｂについては、図１２に破線で示している如く、インタ
フェース・ノードｇ、インタフェース・ノードｈ及びイ
ンタフェース・ノードｉ間のメトリックだけに着目して
ルーティング計算をする。

【０１７１】このように、自律ネットワークをインタフ
ェース・ノードだけで表現した等価的ネットワークに置
き換えれば、単独のノードによって構成されるネットワ
ークにおいてルーティング計算するのと同じになる。

【０１７２】つまり、ユーザＡとユーザＢの間でルーテ
ィング計算をする場合には、距離順最短ルート・テーブ
ルからノードａを境界ノードとする距離順最短ルート情
報を読み出し、既に説明した手順によって始点ノードａ
から終点ノードｉの間のルートについてメトリックを読
み出すか計算して、当該ルートに対するサービス品質を
読み出せばよい。

【０１７３】又、図１２では単独ノードと自律ネットワ
ークが混在するネットワークを例に説明したが、ネット
ワークが自律ネットワークのみによって構成されていて
も、全く同様にルーティング計算をすることができるこ
とは明白である。

【０１７４】即ち、本発明のルーティング計算は任意の
トポロジのネットワークについて適用することが可能で
ある。

【０１７５】図１３は、上記の如きルーティング計算を
司るルーティング装置を適用したルーティング・システ
ムの構成を示す図である。

【０１７６】図１３において、１はユーザＡ、２はユー
ザＢである。

【０１７７】又、３はネットワーク・プロバイダＡ（図
では「ＮＷプロバイダＡ」と略記している。以降も、こ
のような標記法を適用することがある。）が運営する自
律ネットワークＡ、４はネットワーク・プロバイダＢが
運営する自律ネットワークＢ、５はネットワーク・プロ
バイダＣが運営する自律ネットワークＣである。

【０１７８】また、６はサービス・プロバイダａが運営
するノードａである。

【０１７９】更に、７はルーティング装置Ｘ、７ａはル
ーティング装置Ｙである。

【０１８０】ここでは、ネットワークの概要を説明す
る。

【０１８１】まず、ユーザＡと自律ネットワークＡの
間、及び、ユーザＢと自律ネットワークＣの間、ノード
ａと自律ネットワークＡ、自律ネットワークＢ及び自律
ネットワークＣとの間の回線は、所謂ｘＤＳＬ（ＤＳＬ
は、「Digital SubscriberLine」の頭文字による略語
で、デジタル加入者線を意味する。又、「ｘ」は、デジ
タル加入者線の方式を一般的に示す文字で、例えば、ｘ
が「Ａ」であれば、「Asymmetric Digital Subscriber
Line」を意味する。）である。

【０１８２】又、自律ネットワーク間の回線はＡＴＭ回
線（Asynchronous Transfer Mode：非同期転送モード）
やコネクションレス（ＣＬ）ネットワークなどで、これ
らを通してＩＰｖ４（Internet Protocol version 4)や
ＩＰｖ６によってコンテンツの転送が行なわれる。

【０１８３】そして、ルーティング装置間、ルーティン
グ装置と自律ネットワーク間の回線も、ＡＴＭ回線やコ
ネクションレスネットワークなどで、ネットワーク・プ
ロバイダによるメトリックの変更の情報や、ユーザによ
るパス要求の情報、及びルーティング装置からのパス情
報が転送される。

【０１８４】即ち、ルーティング装置は、ネットワーク
・プロバイダからの自律ネットワーク内のメトリック変
更情報と、ユーザからのパス要求情報を受け付けて、既
に説明した処理を行なって、ユーザに対して処理結果を
通知し、ネットワーク・プロバイダに対してルートの予
約を行なう。

【０１８５】図１３のルーティング・システムの特徴
は、ルーティング装置間、ルーティング装置と自律ネッ
トワークとの間の、メトリック変更情報やルーティング
計算結果を転送するネットワークと、自律ネットワーク
間のコンテンツを転送するネットワークを分離している
点にある。

【０１８６】このように、２種類のネットワークを分離
することによって、メトリックの変更やルーティング情
報をコンテンツを転送するネットワークによって伝達す
る必要がなくなり、コンテンツを転送するネットワーク
の伝送容量を圧迫することがなくなる。

【０１８７】又、該ルーティング装置は、ネットワーク
・プロバイダが保有するネットワークに対応して配置す
る必要がない。従って、ルーティング装置自体の数が少
なくてもよく、ルーティング・システムを構成するネッ
トワーク・リソースの肥大化を防止することができる。

【０１８８】更に、上記の如くルーティング装置をネッ
トワーク・プロバイダが保有するネットワークから独立
させることにより、ネットワーク・プロバイダによる恣
意的なネットワーキングを防止することができるので、
公正なネットワーク運営が可能になるという利点も生ず
る。

【０１８９】図１４は、ルーティング装置の機能構成例
である。

【０１９０】図１４において、７１は外部との通信を行
なう通信インタフェース、７２はルーティング計算を行
なうルーティング管理部、７３はネットワークの障害を
監視する障害管理部、７４は課金などを管理する価格管
理部、７５はサービス品質を含めてリソースを管理する
リソース管理部である。

【０１９１】通信インタフェースを介して、ネットワー
ク・プロバイダからはメトリック変更情報が受け付けら
れ、ユーザからはパス要求が受け付けられるので、ルー
ティング管理部は既に説明した処理を行なうが、その際
に、通信インタフェースを介して受信されて障害管理部
にもたらされる障害情報や、リソース管理部が保有して
いるサービス品質を参照する。又、価格管理部からもた
らされる課金情報を通信インタフェースを介してネット
ワーク・プロバイダやユーザに送信する。

【０１９２】尚、価格管理部とリソース管理部は障害情
報を参照して管理機能を果たしている。

【０１９３】ルーティング装置の概要は以上の通りであ
るが、以降、本発明において最も重要なルーティング管
理部について説明する。

【０１９４】図１５は、ルーティング管理部の論理的機
能構成である。

【０１９５】図１５において、７２−１はネットワーク
・プロバイダからのメトリック変更情報やユーザからの
パス要求情報を受け付け、ルーティング計算の契機を決
定し、ユーザにルーティング計算結果を返信し、ネット
ワーク・プロバイダにユーザが要求したパスの予約情報
を転送する受付制御部、７２−２は受付制御部７２−１
の指示によりメトリック変更時にルーティング計算を行
なうメトリック変更時ルーティング部、７２−３は受付
制御部７２−１の指示によりパス要求時にルーティング
計算を行なうパス要求時ルーティング部、７２−４はメ
トリック変更時ルーティング部７２−２及びパス要求時
ルーティング部７２−３がルーティング計算をする際に
参照する距離順最短ルート・テーブル、７２−５はパス
要求時ルーティング部７２−３が管理していて、ルーテ
ィング計算時に参照する最短変更ノード・テーブル、７
２−６はメトリック変更時ルーティング部７２−２及び
パス要求時ルーティング部７２−３が、求めたルートに
関してサービス品質を参照するルート特性テーブルであ
る。

【０１９６】即ち、ルーティング管理部の主要な部位
は、受付制御部７２−１、メトリック変更時ルーティン
グ部７２−２及びパス要求時ルーティング部７２−３で
ある。

【０１９７】このうち、メトリック変更時ルーティング
部７２−２の動作は、既に図６乃至図８によって説明し
てある。

【０１９８】又、パス要求時ルーティング部７２−３の
動作は、既に図９乃至図１１によって説明してある。

【０１９９】従って、ここでは受付制御部の動作につい
てのみ説明するが、メトリック変更情報やパス要求情報
の受け付け、計算結果の返信、パスの予約情報の転送に
関する技術は公知、公用の技術であるので、ルーティン
グ計算の契機の決定に関する説明だけに止める。

【０２００】図１６は、ルーティング計算の契機の決定
法である。

【０２０１】以降、図１６の符号に沿ってルーティング
計算の契機の決定法について説明する。

【０２０２】Ｓ５１．自己設備の計算能力を算出してお
く。これをＣ_x とする。

【０２０３】Ｓ５２．メトリック変更要求、パス要求の
頻度を計測している。

【０２０４】Ｓ５３．所定時間が経過したか否か判定す
る。

【０２０５】所定時間が経過していないと判定された場
合（Ｎｏ）には、ステップＳ５２に戻って、メトリック
変更要求、パス要求の頻度の計測を継続する。

【０２０６】Ｓ５４．ステップＳ５３で、所定時間が経
過したと判定された場合（Ｙｅｓ）には、ステップＳ５
２の計測結果に基づいてパス要求時の計算量を確定し、
Ｓ５５．同様に、ステップＳ５２の計測結果に基づいて
メトリック変更時の計算量を確定する。

【０２０７】Ｓ５６．パス要求時の計算量がメトリック
変更時の計算量より多いか否か判定する。

【０２０８】Ｓ５７．ステップＳ５６で、パス要求時の
計算量がメトリック変更時の計算量より小さいと判定さ
れた場合（Ｎｏ）には、メトリック変更時の計算量が、
ステップＳ５１で求めた計算能力Ｃ_X より多いか否か判
定する。

【０２０９】Ｓ５８．ステップＳ５７で、メトリック変
更時の計算量が計算能力Ｃ_X より多いと判定された場合
（Ｙｅｓ）には、パス要求時の計算量がメトリック平衡
時の計算量より少なく、且つ、メトリック変更時の計算
量が計算能力Ｃ_X を超えているので、パス要求時にルー
ティング計算するものと決定する。

【０２１０】Ｓ５９．ステップＳ５６で、パス要求時の
計算量がメトリック変更時の計算量より多いと判定され
た場合（Ｙｅｓ）には、当然、メトリック変更時にルー
ティング計算するものと決定する。

【０２１１】又、ステップＳ５７で、メトリック変更時
の計算量が計算能力Ｃ_X より少ないと判定された場合
（Ｎｏ）には、メトリック変更時にルーティング計算す
るものとしてもよい。

【０２１２】さて、図１６では、ステップＳ５７で、メ
トリック変更時の計算量と計算能力Ｃ_X の比較をして、
メトリック変更時の計算量が計算能力を下回っている場
合にはメトリック変更時にルーティング計算するものと
決定する例を示したが、もっと単純に、パス要求時の計
算量とメトリック変更時の計算量の比較結果によってい
ずれかを選択してもよい。そして、この場合には、自己
設備の計算能力の算出は不要になる。

【０２１３】いずれにしても、既に説明したメトリック
変更時のルーティング計算の計算量も、パス要求時のル
ーティング計算の計算量も、従来のルーティング計算の
計算量より少なく、その上、上記の如く、その時々の状
況によってルーティング計算の契機を選択するので、本
発明のルーティング装置による計算量は従来のルーティ
ング計算の計算量より少なくなる。

【０２１４】

【発明の効果】本発明の第一の手段の第一の手順によれ
ば、メトリックに変更があった場合にネットワーク・ト
ポロジ全体にわたってルーティング計算をせずに、当該
メトリック変更の影響を受ける可能性のある最短変更ノ
ード以降についてのみルーティング計算のやり直しをす
るので、メトリック変更に伴うルーティング計算の負荷
を軽減することができる。

【０２１５】本発明の第一の手段の第二の手順によれ
ば、メトリックに変更があった場合には最短変更ノード
のみを更新しておき、パス要求時には、最短変更ノード
が更新された場合には最短変更ノード以降についてルー
ティング計算のやり直しをし、最短変更ノードが更新さ
れなかった場合には両端ノードのうち境界ノードに近い
ノード以降についてルーティングのやり直しをするの
で、メトリックの変更に伴うルーティング計算の負荷を
軽減することができる。

【０２１６】本発明の第二の手段によれば、その時々の
メトリック変更頻度とパス要求頻度に対するルーティン
グ計算の計算量を推定して、両者の計算量の大小によっ
てルーティング計算方式を選択することによって、メト
リック変更に伴うルーティング計算の計算量を抑圧する
ことができる。

【０２１７】本発明の第三の手段によれば、メトリック
の変更をコンテンツを転送するネットワークによって伝
達する必要がなくなり、ルーティング情報をコンテンツ
を転送するネットワークによって伝達する必要がなくな
るので、コンテンツを転送するネットワークの伝送容量
を圧迫することがなくなる。

【０２１８】又、該ルーティング装置は、ネットワーク
・プロバイダが保有するネットワークに対応して配置す
る必要がない。従って、ルーティング装置自体の数が少
なくてもよく、本発明のルーティング・システムを適用
することによってネットワーク・リソースの肥大化を防
止することができる。

【０２１９】更に、上記の如くルーティング・システム
をネットワーク・プロバイダが保有するネットワークか
ら独立させることにより、ネットワーク・プロバイダに
よる恣意的なネットワーキングを防止することができる
ので、公正なネットワーク運営が可能になるという利点
も生ずる。

【図面の簡単な説明】

【図１】 メトリック変更時にルーティング計算を行な
う場合の手順。

【図２】 パス要求時にルーティング計算を行なう場合
の手順。

【図３】 ルーティング計算の計算量。

【図４】 距離順グラフと最短変更ノード。

【図５】 距離順最短ルート情報。

【図６】 メトリック変更時にルーティング計算をする
場合の処理手順（その１）。

【図７】 メトリック変更時にルーティング計算をする
場合の処理手順（その２）。

【図８】 メトリック変更時のルーティング計算に必要
なデータ。

【図９】 パス要求時にルーティング計算をする場合の
処理手順（その１）。

【図１０】 パス要求時にルーティング計算をする場合
の処理手順（その２）。

【図１１】 パス要求時のルーティング計算に必要なデ
ータ。

【図１２】 自律ネットワークを含むネットワークにお
ける最短パス優先アルゴリズムの適用。

【図１３】 ルーティング装置を適用したルーティング
・システム。

【図１４】 ルーティング装置の機能構成例。

【図１５】 ルーティング管理部の論理的機能構成。

【図１６】 ルーティング計算の契機の決定法。

【図１７】 最短パス優先アルゴリズムを説明するため
のネットワーク・トポロジの例。

【図１８】 最短パス優先アルゴリズムのフローチャー
ト。

【図１９】 最短パス優先アルゴリズムによる最終ツリ
ーの作成（その１）。

【図２０】 最短パス優先アルゴリズムによる最終ツリ
ーの作成（その２）。

【図２１】 最短パス優先アルゴリズムによる最終ツリ
ーの作成（その３）。

【図２２】 最短パス優先アルゴリズムによる最終ツリ
ーの作成（その４）。

【図２３】 最短パス優先アルゴリズムによる最終ツリ
ーの作成（その５）。

【符号の説明】

１ ユーザＡ ２ ユーザＢ ３ 自律ネットワークＡ ４ 自律ネットワークＢ ５ 自律ネットワークＣ ６ ノードａ ７ ルーティング装置 ７ａ ルーティング装置 ７１ 通信インタフェース ７２ ルーティング管理部 ７３ 障害管理部 ７４ 価格管理部 ７５ リソース管理部 ７２−１ 受付制御部 ７２−２ メトリック変更時ルーティング部 ７２−３ パス要求時ルーティング部 ７２−４ 距離順最短ルート・テーブル ７２−５ 最短変更ノード・テーブル ７２−６ ルート特性テーブル

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｑ 3/495

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ネットワークを構成するノードを境界ノ
   ードとする最終ツリーから、該境界ノードからの距離順
   に全てのノードを連結した距離順グラフをネットワーク
   を構成するノード毎に作成しておき、 ネットワークのリンクに付与されるメトリックが変更さ
   れた時に、該距離順グラフにおいて、当該リンクの両端
   ノードのうち境界ノードに近い最短ノード以降のネット
   ワークについてルーティング計算をすることを特徴とす
   るルーティング計算方式。
2. 【請求項２】 ネットワークを構成するノードを境界ノ
   ードとする最終ツリーから、境界ノードからの距離順に
   全てのノードを連結した距離順グラフをネットワークを
   構成するノード毎に作成しておくと共に、 過去にメトリックが変更になったリンクの両端ノードの
   うち、最も境界ノードに近いノードをネットワークを構
   成するノード毎の最短変更ノード・テーブルに格納して
   おき、 ネットワークのリンクに付与されるメトリックが変更さ
   れた時に、メトリックが変更されたリンクの両端ノード
   のうち境界ノードに近いノードが、該最短変更ノード・
   テーブルに格納されているノードより境界ノードに近い
   場合のみ該最短変更ノード・テーブルに格納するノード
   を更新し、 パスの要求があった時に、 該最短変更ノード・テーブルに格納されているノードが
   要求パスの終点ノードより境界ノードに近い場合のみ、
   該最短変更ノード・テーブルに格納されているノードか
   ら終点ノードまでついて最短パス優先アルゴリズムによ
   るルーティング計算を行ない、該最短変更ノード・テー
   ブルの格納ノードを終点ノードに更新することを特徴と
   するルーティング計算方式。
3. 【請求項３】 コンテンツを転送するネットワーク側か
   ら、メトリックの変更とパスの要求を受け付け、ルーテ
   ィング計算の結果を回答するルーティング装置であっ
   て、 請求項１記載のルーティング計算方式及び請求項２記載
   のルーティング計算方式を備えており、 メトリックの変更頻度及びパス要求頻度に対応するルー
   ティング計算の計算量が少ない方のルーティング計算方
   式を選択してルーティング計算を行なうことを特徴とす
   るルーティング装置。
4. 【請求項４】 請求項３記載のルーティング装置をネッ
   トワーク内に配置するに当たって、 メトリックの変更とパスの要求とルーティング計算の結
   果の回答を転送するネットワークをコンテンツを転送す
   るネットワークから独立させることを特徴とするルーテ
   ィング・システム。