JP2002190825A - トラフィックエンジニアリング方法及びそれを用いたノード装置 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、大規模ネットワークであっても高
速にロードバランシングを実行し、障害が発生した場合
も障害ルートのトラフィックロスを高速に救済すること
ができるトラフィックエンジニアリング方法及びそれを
用いたルータ装置を提供することを目的とする。 【解決手段】 ネットワーク全体が複数ノードの集合体
であるエリアに分割されており、ネットワーク全体の資
源の最適化を行うトラフィックエンジニアリング方法に
おいて、各エリア毎にエリア内で閉じたロードバランシ
ングを実行するため、大規模ネットワークであってもロ
ードバランシング実行ノードが必要とするメモリ容量を
大幅に削減でき高速にロードバランシングを実行するこ
とができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、トラフィックエン
ジニアリング方法及びそれを用いたノード装置に関し、
ネットワーク内におけるトラフィックエンジニアリング
方法及びそれを用いたノード装置に関する。

【０００２】現在のインターネット上では、従来のデー
タ通信だけでなく音声や映像のようなリアルタイムサー
ビスに至るまで、実に多種の情報がやり取りされるよう
になって来た。その結果、インターネット上のトラフィ
ックは年々急速に増加しており、輻輳問題の解決が不可
欠となっている。

【０００３】

【従来の技術】複数のノードで構成されるネットワーク
において、パケットをソースからディスティネーション
にフォワーディングする最適ルートを自律的に決定する
ルーティングプロトコルにはＲＩＰ（Ｒｏｕｔｉｎｇ
Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＯＳＰ
Ｆ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓ
ｔ）、ＢＧＰ４（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒ
ｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ４）、ＩＳ−ＩＳ（Ｉ
ｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ ｔｏＩｎｔｅ
ｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ）などが存在する。今
日のネットワークでは、これらのプロトコルを使用して
最適ルートを求め、このルート上でパケットフォワーデ
ィングを行っている。

【０００４】ノードがパケットをフォワーディングする
際、一般的には図１に示すように、各ノード１０，１
１，１２がパケットのディスティネーションアドレスを
参照して行う。

【０００５】これより高速なパケットフォワーディング
を行うための技術としてＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏ
ｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）に代表
されるカットスルー方式が注目されている。ＭＰＬＳで
は、図２に示すように、ルーティングプロトコルにより
算出された最適ルート上にＬＳＰ（Ｌａｂｅｌ Ｓｗｉ
ｔｃｈｅｄ Ｐａｔｈ）が設定される。ここで、ＬＳＰ
の両端に位置するノード１５，１７をエッジノードと呼
び、そのエッジノード間（ＭＰＬＳドメイン内）に位置
するＬＳＰ上の各ノード１６をコアノードと呼ぶ。

【０００６】次に、ＬＤＰ（Ｌａｂｅｌ Ｄｉｓｔｒｉ
ｂｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いて、ＬＳＰ上
の各ノードが転送先方路を決めるためのラベルが配布さ
れる。こうして、ＭＰＬＳドメインの外部より転送され
て来たパケットに対し、まず発側のエッジノードがラベ
ルを付加してからＬＳＰ上にパケット載せて転送を行
い、最終的に着側エッジノードでラベルが取り除かれて
ＭＰＬＳドメインの外部に転送されるまでは、途中のコ
アノードではラベルのみを参照したレイヤ２での転送を
行うだけで良いため、高速な転送処理が可能となる。

【０００７】このようにルーティングプロトコルとＭＰ
ＬＳ技術を使用することにより、最適なルートを使用し
た高速フォワーディングが実現できるのであるが、今日
のインターネットのように加入者増により爆発的にトラ
フィックが増加すると、輻輳やパケットロスが発生して
しまう。ＭＰＬＳは、このように高速フォワーディング
が可能というメリットがあるものの、トラフィックが集
中した場合にＩＰルーティングのようなソフトウェアに
よる臨機応変な経路制御ができないため、輻輳やパケッ
トロスが発生するというデメリットもある。この輻輳や
パケットロスの発生を防止するために、ネットワーク全
体の資源の最適化を自動的に行う制御であるトラフィッ
クエンジニアリング（ＴＥ）が利用出来る。

【０００８】トラフィックエンジニアリング機能自体は
特定のレイヤ２媒体に依存しないのであるが、上記ＭＰ
ＬＳのように発側および着側ノード間でＬＳＰを設定す
るようなネットワーク上での利用が最も効果的である。
トラフィックエンジニアリングの負荷分散方式について
は、例えば特願平１２−１２１９５号に記載のものがあ
る。この方式は、図３に示すように、発側ノード２０か
ら着側エッジノード２１に複数のマルチパスＬＳＰ１，
ＬＳＰ２，ＬＰＳ３を設定し、このマルチパスでトラフ
ィックの分配を行うことで、ネットワーク全体のトラフ
ィックの平均化を行っている。

【０００９】この技術では、トラフィックの現在の負荷
を認識するため、図４に示すように、各ノードはリンク
毎の平均使用率を算出し、全ノードに対して定期的に広
告（Ｆｌｏｏｄｉｎｇ）を行う。発側ノード２０は、広
告により受信した各ノードのリンク毎の平均使用率をも
とに、ＬＳＰ毎の実際のトラフィック（実効ロード）を
算出し、全ＬＳＰの実効ロードが同一値に近づくよう
に、マイクロフロー毎にトラフィックの移動を行い、平
均化を実現している。マイクロフローとは、あるエンド
ユーザ間で使用されるフローを指し、これに対し共通の
宛先を持つマイクロフローをまとめたものはアグリゲー
トフローと呼ぶ。

【００１０】マイクロフローをどのＬＳＰにマッピング
するかの選択は、図５（Ａ）に示すＬＳＰ決定テーブル
を用いて実施され、新規マルチパスの追加の度に、この
ＬＳＰ決定テーブル内で分割される領域数も増加してい
く。まず、発側ノード２０にてパケット内のアドレス情
報をキーとして正規化値を算出する。その正規化値にて
ＬＳＰ決定テーブルをインデックスし、マッピングする
ＬＳＰを決定する。このとき、トラフィックの平均化を
行うためには、図５（Ａ）に示す状態から図５（Ｂ）に
示すように、ＬＳＰ決定テーブルのＬＳＰの境界を移動
することでマッピングするＬＳＰの切り替えを行うこと
により、トラフィック分散を実現している

【発明が解決しようとする課題】従来のトラフィックエ
ンジニアリング技術では、発側ノードが全ノードから定
期的に送られてくる各リンク毎の平均使用率を収集し、
それを基にＬＳＰ毎の実効ロードを算出した上で一括し
てトラフィックの分散処理を行っていた。したがって、
小規模ネットワークでのロードバランシングは可能であ
ったが、ＯＳＰＦルーティングプロトコルなどのように
複数エリアを収容する大規模ネットワークになると、発
側ノードへの負担が重過ぎるためロードバランシングの
適用は不可能であった。

【００１１】また、複数ルートのうち何れかのルートが
障害になった場合、従来のトラフィックエンジニアリン
グでは、発側ノードがネットワークトポロジーの変化や
ＬＤＰのリフレッシュ機能でしか検出できないため、そ
の間は障害ルートを含めた複数パスで負荷分散を実施し
続けることになり、トラフィックの高速な救済ができず
ＴＣＰコネクションなどのマイクロフローなどは救済す
ることが不可能であった。

【００１２】本発明は、上記の点に鑑みなされたもので
あり、大規模ネットワークであっても高速にロードバラ
ンシングを実行し、障害が発生した場合も障害ルートの
トラフィックロスを高速に救済することができるトラフ
ィックエンジニアリング方法及びそれを用いたルータ装
置を提供することを目的とする。

【００１３】

【課題を解決するための手段】請求項１に記載の発明
は、ネットワーク全体が複数ノードの集合体であるエリ
アに分割されており、前記ネットワークのトラフィック
エンジニアリングを行う方法において、各エリア毎にエ
リア内で閉じたロードバランシングを実行するため、大
規模ネットワークであってもロードバランシング実行ノ
ードが必要とするメモリ容量を大幅に削減でき高速にロ
ードバランシングを実行することができる。

【００１４】請求項２に記載の発明は、全体が複数ノー
ドの集合体であるエリアに分割され、かつ、全体の資源
の最適化がトラフィックエンジニアリングにより行われ
るネットワークを構成するノード装置において、各エリ
ア毎にエリア内で閉じたロードバランシングを行うため
のエリア内宛先を決定するエリア内宛先決定手段を有す
るため、エリア内で閉じたロードバランシングを実行す
ることが可能となり、大規模ネットワークであってもロ
ードバランシング実行ノードが必要とするメモリ容量を
大幅に削減でき高速にロードバランシングを実行するこ
とができる。

【００１５】請求項３に記載の発明は、請求項２記載の
ノード装置において、外部からパケットが供給される入
り口ノードを構成するノード装置は、外部から供給され
たパケットのアドレス情報を基にロードバランシングを
行うための正規化値を演算し、前記正規化値を前記パケ
ットのスイッチング情報に付加するスイッチング情報生
成手段とを有するため、エリア境界ノードに正規化値を
通知することが可能となる。

【００１６】請求項４に記載の発明は、請求項２記載の
ノード装置において、エリアの境界にあるエリア境界ノ
ードを構成するノード装置は、隣接エリアから供給され
るパケットのスイッチング情報から、自エリア内で閉じ
たロードバランシングを実行するための正規化値を抽出
する正規化値抽出手段を有するため、エリア境界ノード
では抽出した正規化値を用いてロードバランシングを行
うことができ、プロトコルの識別やヘッダチェックなど
を行う必要がなく高速のロードバランシングを行うこと
ができる。

【００１７】請求項５に記載の発明は、全体が複数ノー
ドの集合体であるエリアに分割され、かつ、全体の資源
の最適化がトラフィックエンジニアリングにより行われ
るネットワークを構成するノード装置において、障害を
検出したときロードバランシングを実行している最も近
い上流側のノードに障害を通知する障害通知手段を有す
るため、ロードバランシングを実行しているノードでト
ラフィックの分配を高速に行うことが可能となる。

【００１８】付記６に記載の発明は、請求項２記載のノ
ード装置において、障害通知を受信した前記入り口ノー
ドまたはエリア境界ノードは、障害が発生したルートに
流していたトラフィックを他のルートに分散しなおすト
ラフィック分散手段を有するため、障害ルートを流れて
いたトラフィックでのトラフィックロスを高速に救済す
ることが可能となる。

【００１９】付記７に記載の発明は、付記６記載のノー
ド装置において、障害通知を受信した前記入り口ノード
またはエリア境界ノードは、障害が発生したルートに流
していたトラフィックを他のルートに分散しなおしたと
きトラフィックロスが発生するか否かを判定する障害通
知受信手段を有するため、障害が発生したルートに流し
ていたトラフィックを他のルートに分散可能か否かを認
識できる。

【００２０】付記８に記載の発明は、付記７記載のノー
ド装置において、前記トラフィック分散手段は、前記障
害通知受信手段でトラフィックロスが発生すると判定し
たとき、前記障害が発生したルートに流していたトラフ
ィックを新たに設定したルートに切り替えるため、障害
ルート以外のルートが高トラフィックの場合でも、障害
ルートに流していたトラフィックを救済することができ
る。

【発明の実施の形態】図６は、本発明のトラフィックエ
ンジニアリング方法を適用したネットワークシステムの
一実施例の構成図を示す。

【００２１】このネットワークではルーティングプロト
コルとしてＯＳＰＦを使用する。ＯＳＰＦでは、ネット
ワーク全体が複数ノードの集合体であるエリアに分割さ
れる。図６においては、ネットワークはエリア２５，２
６，２７から構成されており、エリア２５はノード２５
ａ〜２５ｅより構成され、エリア２６はノード２５ｄ，
２５ｅ，２６ａ〜２６ｃより構成され、エリア２７はノ
ード２６ｃ，２７ａ〜２７ｃより構成されている。ノー
ド２５ａが入り口ノード（Ｉｎｇｒｅｓｓノード）、ノ
ード２７ｃが宛先ノード（Ｅｇｒｅｓｓノード）とする
と、入り口エリア２５と宛先エリア２７の間は、バック
ボーンエリア２６で接続される２階層のトポロジー構造
をとる。ここで、各エリアの境界に位置するノード２５
ｄ、２５ｅ，２６ｃそれぞれは、ＯＳＰＦの機能により
自ノードをエリア境界ノード（ＡＢＲ）として認識す
る。また、このネットワーク内では、高速なスイッチン
グを行うためのカットスルー方式としてＭＰＬＳを使用
する。

【００２２】図７は、本発明方法に適用される発側エッ
ジノードの一実施例のブロック構成図を示す。なお、本
実施例では図６の入り口ノード２５ａが対応する。

【００２３】同図中、Ｌ３インタフェース部３１は、外
部ネットワークから送られたＩＰパケット等のレイヤ３
の受付け処理を行う。バッファ部３２は、各ノードが受
信したレイヤ３のパケットについて、スイッチング情報
を付加して次ノードに向けて送信するまでの間、パケッ
ト情報を保持しておく。Ｌ２インタフェース部３３は、
レイヤ３ヘッダ情報等のマイクロフローを識別する情報
が反映されたレイヤ３パケットを指定出力ポートより次
ノードに向けて送信する。

【００２４】正規化値演算部３４は、パケット情報か
ら、実トラフィックの特性（ソースアドレスやデステネ
ーションアドレス）をもとに、ロードバランシングを実
行するための正規化値を算出する。トラフィック分散部
３５は、算出された正規化値に従って、トラフィックを
ＴＥパスグループ内のどのルートへ割当てるかを決定す
る。また、ルート上の障害発生時に、当該障害ルート以
外の全ルートによるロードバランシングを実行すること
でトラフィックロスが発生するか否かの判定結果を受
け、トラフィックロスが発生しないと認識した場合は、
当該障害ルートに流していたトラフィックをそれ以外の
複数ルートに分散しなおす。逆に、トラフィックロスが
発生すると認識した場合は、新たにルートを設定し当該
障害ルートに流していたトラフィックを、新たに設定し
たルートに切り替えてロードバランシングを実行する。

【００２５】出力ポート／スイッチング情報決定部３６
は、各ノードにおいて、指定された宛先およびパスに対
応するパケット出力ポートを決定し、スイッチング情報
の生成に必要な各パラメータを決定する。ルーティング
制御部３７は、デスティネーションアドレスから自ノー
ドのルーティング情報を検索し、どの宛先ノードへ向け
たルートでロードバランシングを実行するかを選択す
る。エリア内宛先決定部３８は、ロードバランシングを
実行する際に必要な、ネットワーク全体における宛先で
はなく、エリア内の閉じた範囲での宛先決定を行う。

【００２６】スイッチング情報生成部３９は、次ノード
に向けたスイッチング情報を生成し、その情報にソース
アドレスやデスティネーションアドレスを基に算出した
正規化計算値を付加する。障害通知受信部４０は、障害
検出ノードから通知される障害発生通知を受信し、障害
ルート以外の全ルートによるロードバランシングを実行
することでトラフィックロスが発生するか否かの判定を
行う。トラフィック管理部４１は、エリア内の全ノード
から広告されたトラフィック情報を保持する。パス設定
／解放部４３は、ＴＥパスグループを構成するパスの設
定および削除処理を行う。

【００２７】宛先アドレスルックアップテーブル４４
は、宛先アドレスから宛先ノード情報を求めるための検
索テーブルである。エリア内宛先決定テーブル４５は、
宛先ノード情報からエリア内のどの宛先までの範囲でロ
ードバランシングを行うかを決定するための検索テーブ
ルである。閾値テーブル４６は、エリア内でロードバラ
ンシングを行うために、トラフィックの分散先（ＴＥパ
スグループおよびＬＳＰ）を求めるための検索テーブル
である。スイッチング情報決定テーブル４７は、エリア
内の宛先およびトラフィックの分散先に関する情報をも
とに、パケットの出力先とスイッチング情報を求めるた
めの検索テーブルである。

【００２８】本発明において新規に追加された部位はエ
リア内宛先決定部３８、障害通知受信部４０であり、必
要データとしてエリア内宛先決定テーブル４５も追加さ
れている。また、機能が追加された部位はトラフィック
分散部３５、スイッチング情報生成部３９である。

【００２９】入り口側エッジノードであるノード２５ａ
での処理について説明する。Ｌ３インタフェース部３１
では、企業やＩＳＰなどの外部ネットワークからのレイ
ヤ３パケットを受付け、パケット内のアドレス情報を正
規化値演算部３４とＬ３ルーティング制御部３７にそれ
ぞれ通知した後、パケット情報をバッファ部３２に保持
させる。

【００３０】アドレス情報を受けたＬ３ルーティング制
御部３７では、宛先アドレスをもとに宛先アドレスルッ
クアップテーブル４４を検索してパスの終端である宛先
ノードを特定し、その結果をエリア内宛先決定部３８に
通知する。従来は宛先ノードまで範囲でロードバランシ
ングを実施していたのに対し、本発明では各エリアに閉
じた範囲でロードバランシングを行うため、エリア内宛
先決定部３８では、Ｌ３ルーティング制御部３７で求め
た宛先ノード情報をもとにエリア内宛先決定テーブル４
５を検索してエリア内での宛先（エリア境界ノード）を
判定し、その結果を出力ポート／スイッチング情報決定
部３６とトラフィック分散部３５に通知する。

【００３１】一方、Ｌ３インタフェース部３１よりアド
レス情報を受けた正規化値演算部３４では、それらの情
報を正規化関数にかけ、ロードバランシングを実行する
ための正規化値を算出し、その値をトラフィック分散部
３５とスイッチング情報生成部３９に通知する。

【００３２】次に、トラフィック分散部３５では、エリ
ア内宛先決定部３８で求めたエリア内の宛先と、正規化
値演算部３４で算出した正規化値をもとに閾値テーブル
４６を参照して、トラフィックをＴＥパスグループ内の
どのルートへ割当てるかを決定し、その結果を出力ポー
ト／スイッチング情報決定部３６に通知する。また、ト
ラフィック管理部４１は、自エリア内の全ノードから定
期的に広告されるトラフィック情報をＬ２インタフェー
ス部３３より受け取って管理し、トラフィック分散部３
５にトラフィック情報を通知する。

【００３３】トラフィック分散部３５およびエリア内宛
先決定部３８から通知された情報をもとに、出力ポート
／スイッチング情報決定部３６ではスイッチング情報決
定テーブル４７を検索し、パケットを次ノードに転送す
るための出力ポートと、パケット内に設定するスイッチ
ング情報の決定を行った上でスイッチング情報生成部３
９に通知する。

【００３４】ここで、従来は、出力ポート／スイッチン
グ情報決定部からの通知情報をもとにスイッチング情報
生成部で次ノードへのスイッチング情報を生成し、Ｌ２
インタフェース部に渡していたが、本発明では、通常の
スイッチング情報に正規化値演算部３４で算出した正規
化値も付加した上でＬ２インタフェース部３３に通知す
る。その後、スイッチング情報を受けたＬ２インタフェ
ース部３３では、その内容をバッファ部３２で保持して
いたパケットに反映させた後、出力ポートより次ノード
に向けて送信を行う。

【００３５】図８は、本発明方法に適用されるコアノー
ドの一実施例のブロック構成図を示す。なお、本実施例
では図６におけるエリア２５のノード２５ｂ，２５ｃ，
２５ｄ，２５ｅ、エリア２６のノード２６ａ，２６ｂ，
２６ｃ、エリア２７のノード２７ａ，２７ｂ，２７ｃが
対応する。

【００３６】同図中、Ｌ２インタフェース部（上流側）
５１は、トラフィックの上流側のノードから送信された
パケットの受付け処理を行う。また、自ノードがルート
上の障害を検出した場合は、ロードバランシングを実行
する最も近いノードに対して、障害通知を送信する。バ
ッファ部５２は、各ノードが受信したパケットを、スイ
ッチング情報を編集して次ノードに向けて送信するまで
の間、保持しておく。Ｌ２インタフェース部（下流側）
５３は、トラフィックの下流側のスイッチング情報が反
映されたパケットを指定出力ポートより次ノードに向け
送信する。

【００３７】正規化値抽出部５４は、スイッチング情報
内に設定されたロードバランシングを実行するための正
規化値を抽出する。トラフィック分散部５５は、抽出さ
れた正規化値に従って、トラフィックをＴＥパスグルー
プ内のどのルートへ割当てるかを決定する。また、ルー
ト上の障害発生時に、当該障害ルート以外の全ルートに
よるロードバランシングを実行することでトラフィック
ロスが発生するか否かの判定結果を受け、トラフィック
ロスが発生しないと認識した場合は、当該障害ルートに
流していたトラフィックをそれ以外の複数ルートに分散
しなおす。逆に、トラフィックロスが発生すると認識し
た場合は、新たにルートを設定し、当該障害ルートに流
していたトラフィックを新たに設定したルートに切り替
えてロードバランシングを実行する。

【００３８】出力ポート／スイッチング情報決定部５６
は、各ノードにおいて、指定された宛先およびパスに対
応するパケット出力ポートを決定し、スイッチング情報
の生成に必要な各パラメータを設定する。Ｌ２ルーティ
ング制御部５７は、デスティネーションアドレスから自
ノードのルーティング情報を検索し、どの宛先ノードへ
向けたルートでロードバランシングを実行するかを選択
する。エリア内宛先決定部５８は、ロードバランシング
を実行する際に必要な、ネットワーク全体における宛先
ではなく、エリア内の閉じた範囲での宛先決定を行う。

【００３９】スイッチング情報生成部５９は、次ノード
に向けたスイッチング情報を生成し、その情報にソース
アドレスやデスティネーションアドレスを基に算出した
正規化計算値を付加する。障害通知受信部６０は、障害
検出ノードから通知される障害発生通知を受信し、障害
ルート以外の全ルートによるロードバランシングを実行
することでトラフィックロスが発生するか否かの判定を
行う。トラフィック管理部６１は、エリア内の全ノード
から広告されたトラフィック情報を保持する。障害通知
部６２は、あるルート上で何らかの障害が発生した場
合、当該障害を検出したノードよりロードバランシング
を実行している最も近い上流ノードに向けて障害の発生
を通知する。パス設定／解放部６３は、ＴＥパスグルー
プを構成するパスの設定および削除処理を行う。

【００４０】宛先アドレスルックアップテーブル６４
は、宛先アドレスから宛先ノード情報を求めるための検
索テーブルである。エリア内宛先決定テーブル６５は、
宛先ノード情報からエリア内のどの宛先までの範囲でロ
ードバランシングを行うかを決定するための検索テーブ
ルである。閾値テーブル６６は、エリア内でロードバラ
ンシングを行うために、トラフィックの分散先（ＴＥパ
スグループおよびＬＳＰ）を求めるための検索テーブル
である。スイッチング情報決定テーブル６７は、エリア
内の宛先およびトラフィックの分散先に関する情報をも
とに、パケットの出力先とスイッチング情報を求めるた
めの検索テーブルである。

【００４１】本発明において新規に追加された部位は、
正規化抽出部５４、エリア内宛先決定部５８、障害通知
受信部６０、障害通知部６２であり、必要データとして
エリア内宛先決定テーブル６５も追加されている。ま
た、機能が追加された部位は、トラフィック分散部５５
である。なお、コアノードとエッジノードに分けて説明
を行ったが、同一機器で異なる設定をすることでも各ノ
ードの機能を実現可能である。

【００４２】コアノードでの処理について説明する。Ｌ
２インタフェース部５１では、前ノードから転送された
パケットを受付け、パケット内のスイッチング情報を正
規化値抽出部５４およびＬ２ルーティング制御部５７に
それぞれ通知した後、パケット情報をバッファ部５２に
保持させる。

【００４３】自ノードがロードバランシングを実行する
ように設定されたノードで、しかもパス上のエリア境界
ノードであった場合、Ｌ２ルーティング制御部５７では
Ｌ２インタフェース部５１より通知されたスイッチング
情報をもとに宛先アドレスルックアップテーブル６４を
検索してパスの終端である宛先ノードを特定し、その結
果をエリア内宛先決定部５８に通知する。エリア内宛先
決定部５８では、エッジノードと同様に、Ｌ２ルーティ
ング制御部５７で求めた宛先ノード情報をもとにエリア
内宛先決定テーブル６５を検索してエリア内での宛先
（エリア境界ノードまたは宛先ノード）を判定し、その
結果を出力ポート／スイッチング情報決定部５６とトラ
フィック分散部５５に通知する。

【００４４】従来は入り口ノードのみがロードバランシ
ング用の正規化値を入手する必要があったのに対し、本
発明ではエリア内で閉じたロードバランシングを実施す
るため、正規化値抽出部５４が、Ｌ２インタフェース部
５１より受け取ったパケット内情報より、自エリア内に
閉じてロードバランシングを実行するために必要な正規
化値を抽出し、その結果をトラフィック分散部５５に通
知する。

【００４５】次に、トラフィック分散部５５では、エリ
ア内宛先決定部５８で求めたエリア内の宛先と、正規化
値抽出部５４で抽出した正規化値をもとに閾値テーブル
６６を参照して、トラフィックをＴＥパスグループ内の
どのルートへ割当てるかを決定し、その結果を出力ポー
ト／スイッチング情報決定部５６に通知する。またトラ
フィック管理部６１は、自エリア内の全ノードから定期
的に広告されるトラフィック情報をＬ２インタフェース
部５３より受け取って管理し、トラフィック分散部５５
にトラフィック情報を通知する。

【００４６】これに対し、自ノードがロードバランシン
グ実行ノードでない場合は、上記における正規化値抽出
部５４、トラフィック分散部５５の各処理は不要であ
る。以降の出力ポート／スイッチング情報決定部５６、
スイッチング情報生成部５９、Ｌ２インタフェース部５
３の各処理はエッジノードと同様である。また、宛先ノ
ード２７ｃについては、ロードバランシングとは直接関
係しないため説明は省略する。ところで、ロードバラン
シング実行ノードとは、コアノードの内でロードバラン
シングを実行するエリア境界ノードのことである。な
お、エリア境界ノードであっても、ＬＳＰ上に位置しな
いノードであればロードバランシングは実行しない。

【００４７】これにより、エリア内で閉じたロードバラ
ンシングの実施が可能になり、大規模なネットワークに
おいても最適なトラフィックエンジニアリングを行うこ
とができる。また、エッジノードにおいて算出した正規
化値をパケットに入れてエリア境界ノードに通知するこ
とで、カットスルーのパケット転送方式の利点を生かし
たまま、高速フォアーディングにてロードバランシング
を実行できる。

【００４８】次に、上流側エッジノードでの障害処理に
ついて説明する。障害通知受信部４０では、あるルート
上で障害が発生した場合に、障害を検出したコアノード
より送信される障害通知をＬ２インタフェース部３３よ
り受取る。そして、当該障害ルートに流していたトラフ
ィックを、当該障害ルート以外の複数ルートに分散しな
おした場合にトラフィックロスが発生するか否かを、広
告されてきた各ノードのトラフィック情報をもとに判定
し、その判定結果をトラフィック分散部３５に通知す
る。

【００４９】通知を受けたトラフィック分散部３５で
は、トラフィックロスが発生しないという判定結果であ
った場合、当該障害ルートのトラフィックをそれ以外の
全ルートに分配しなおす。逆に、トラフィックロスが発
生するという判定結果を受けた場合は、新たに別ルート
を追加設定した上で、当該障害ルートに流していたトラ
フィックを、新ルートに切り替えてロードバランシング
を行う。

【００５０】次に、コアノードでの障害処理について説
明する。障害通知部６２では、ロードバランシング処理
を行っているルート上での障害発生についてＬ２インタ
フェース部５３より通知を受け、ロードバランシングを
実行している最も近い上流ノード、つまり入り口ノード
あるいはパス上のエリア境界ノードに対して、障害通知
をＬ２インタフェース部５１から送出する。

【００５１】一方、自ノードがロードバランシング実行
ノードであり、障害検出ノードより上記の障害通知を受
けた場合の処理は、エッジノードと同様の処理を行う。
これにより、ルート上で障害が発生した場合でも、当該
障害を検出したノードが、ロードバランシングを実行し
ているノードに障害を通知して、当該障害以外の複数ル
ートでトラフィックを分散しなおすことで、高速なトラ
フィックロスの救済が可能となる。

【００５２】また、当該障害以外のルートへトラフィッ
クを分散しなおすとトラフィックロスが発生すると判断
した場合、新たにルートを設定し、新ルートに当該障害
ルートのトラフィックを切り替えることで、障害ルート
のトラフィック救済が可能となる。

【００５３】更に具体的な実施例について説明する。

【００５４】まず、ＯＳＰＦで算出した最適ルートに従
ってＬＳＰ（デフォルトパス）を設定する。ＬＳＰ設定
用のプロトコルには、ＬＤＰやＲＳＶＰ−ＬＳＰ−Ｔｕ
ｎｎｅｌ（ＲＳＶＰのＭＰＬＳ拡張版）等いくつかの方
法が提案されているが、ＲＳＶＰ−ＬＳＰ−Ｔｕｎｎｅ
ｌを使用するものとし、その場合のデフォルトパス設定
処理の一実施例のフローチャートを図９に示す。

【００５５】図９において、パス設定要求を認識したパ
ス設定／解放部４３，６３は、ステップＳ１０でＯＳＰ
Ｆにてエッジノード間の最適ルートを算出する。ステッ
プＳ１２で、図１０に示すように入り口ノード２５ａか
ら宛先ノード２７ｃに向けて、算出された最適ルートに
沿ったＰａｔｈメッセージをＬ２インタフェース部３
３，５３より送信する。その応答として宛先ノード２７
ｃから逆ルートで受信メッセージ（Ｒｅｓｖメッセー
ジ）が送信され、入り口ノード２５ａが最終的にこの受
信メッセージを受け取ることで、パケットフォワーディ
ング用のデフォルトパスが設定される。

【００５６】このデフォルトパスに沿ってトラフィック
が流れ始めると、ＬＳＰ上の各ノード２５ａ，２５ｄ，
２６ａ，２６ｃ，２７ａ，２７ｃでは、自ノードにおけ
るトラフィックの現在の負荷状況を認識するために、図
１１に示すように、ハードウエアにより出側ポートの物
理リンク（物理チャネル）毎のパケット転送数およびパ
ケット廃棄数を統計情報として周期的に収集し、それら
をもとに物理リンク毎の使用率を算出して統計情報に加
える。

【００５７】各ノードは、上記で求めた物理リンク毎の
統計情報（平均使用率を含む）を、ＯＳＰＦのＯｐａｑ
ｕｅＬＳＡを使用して、自エリア内の他ノード全てに対
して広告する。なお、ＯｐａｑｕｅＬＳＡとは、ＯＳＰ
Ｆのメッセージによって各ノード間の状態を交換する際
にメッセージのパケットに含まれるＬＳＡ（リンク状態
広告）を使用者が目的に応じて汎用的に使えるよう拡張
したものである。図１２に、ＯＳＰＦのＯｐａｑｕｅＬ
ＳＡのフォーマットを示す。ＯＳＰＦのＯｐａｑｕｅＬ
ＳＡでは、ＯＳＰＦパケットヘッダ、ＯｐａｑｕｅＬＳ
Ａの後に、カード毎の統計情報がカード数だけ格納され
る。

【００５８】図１３に広告の様子を示す。同図中、エリ
ア＃１０内のノードＡは全ての隣接ノードＢ，Ｃ，Ｄに
ＯｐａｑｕｅＬＳＡを広告し、ノードＢ，Ｃ，Ｄも受信
したＯｐａｑｕｅＬＳＡを全ての隣接ノードに広告する
が、受信済みのノードは同じＯｐａｑｕｅＬＳＡを受信
したときは破棄する。

【００５９】この広告情報を収集して管理するのが、従
来は入り口ノードのみであったのに対し、本発明では入
り口ノードだけでなく、ＬＳＰ上で自分をエリア境界ノ
ードとして認識しているノードもロードバランシングを
行う必要があるため、それらのノードのトラフィック管
理部４１，６１も広告情報を収集して管理する。

【００６０】次に、ロードバランシング実行ノードの処
理について説明する。図１４は、ロードバランシング処
理の第１実施例のフローチャートを示す。同図中、ステ
ップＳ２０でロードバランシング実行ノードであるか否
かを判別し、ロードバランシング実行ノードである場合
にのみステップＳ２２に進む。ステップＳ２２でロード
バランシング実行ノードのトラフィック分散部３５，５
５は、広告により受信したエリア内各ノードのリンク毎
の平均使用率をトラフィック管理部４１，６１より受取
り、それをもとにＴＥ（トラフィックエンジニアリン
グ）パスグループのトラフィックを算出する。

【００６１】ここで言うＴＥパスグループとは、デフォ
ルトパスとそれに対する全ＴＥマルチパスを合わせて一
つのグループとしたものを意味し、従来から用いられて
いる考え方である。ＴＥパスグループの算出例として
は、図１５に示すように、あるＬＳＰ１（デフォルトパ
ス）が複数リンク（Ｌｉｎｋ１、２、…ｉ…ｎ）で構成
されている場合、広告で得られた各リンクのトラフィッ
ク情報をもとにＬＳＰ１の実効負荷を算出し、さらにＬ
ＳＰ１を含むＴＥパスグループ（ＬＳＰ１、２、…ｉ…
ｎ）としての使用率を算出する。

【００６２】ステップＳ２４でトラフィック分散部４
１，６１は、図１６に示すようにＴＥパスグループの使
用率を定期的に算出し、その実効負荷がある上限の閾値
を一定時間連続して越えていたらデフォルトパスが輻輳
していると判断する。輻輳と判断すると、ステップＳ２
６でパス設定／解放部４３，６３に指示を送り、ＴＥマ
ルチパスを追加設定する。

【００６３】ここまでの処理で従来と異なるのは、従来
のＴＥマルチパスの設定範囲がデフォルトパスと同様に
入り口ノードから宛先ノードまでであったのに対し、本
発明では図１７に示すように、各エリア２５，２６，２
７それぞれの閉じた範囲でＴＥマルチパスの設定を行う
点である。なお、図１７中、実線はデフォルトパスのＬ
ＳＰを示し、一点鎖線は既存のマルチパスのＬＳＰを示
し、破線は新規追加のマルチパスのＬＳＰを示してお
り、ノード２５ａ，２５ｄ，２６ｃがロードバランシン
グ実行ノードである。

【００６４】こうして、ロードバランシング実行ノード
では、輻輳状況に応じて上記の処理を繰り返し、トラフ
ィックがさらに増加してＴＥパスグループが輻輳したと
判断する度に、新たなＴＥマルチパスを追加し、逆に一
定時間トラフィックが下限の閾値を下回れば輻輳が解除
されたと判断して、ステップＳ２８でＴＥマルチパスを
削除する。

【００６５】次に、図１８は、ロードバランシング処理
の第２実施例のフローチャートを示す。この処理は、入
り口ノード２５ａがＭＰＬＳドメイン外よりＬ３インタ
フェース部３１を介してパケットを受信した場合に実行
される。

【００６６】同図中、ステップＳ３０で自ノードが入り
口ノードか否かを判別し、入り口ノードの場合はステッ
プＳ３２に進み、Ｌ３ルーティング制御部３７がパケッ
トから抽出した宛先アドレス（デスティネーションアド
レス）をもとに、図１９に示す構成の宛先アドレスルッ
クアップテーブル４４を検索して、パスの終端である宛
先ノードに対応した識別子（Ａｓｓｏｃｉａｔｅ Ｐｏ
ｉｎｔｅｒ）を決定する。そして、得られた識別子をも
とにエリア内宛先決定部３８が図２０に示す構造のエリ
ア内宛先決定テーブル４５を検索し、ロードバランシン
グの宛先に対応した識別子（Ｌ．Ｂ．Ｔａｂｌｅ Ｐｏ
ｉｎｔｅｒ）を決定する。ここで言う宛先とは、従来の
宛先ノードまでの宛先ではなく、エリア内でロードバラ
ンシングを実施するための宛先である。その後、ステッ
プＳ３４で受信パケット内のＩＰソースアドレス及びＩ
Ｐデスティネーションアドレスをもとに、正規化値演算
部３４がハッシュ関数（ＣＲＣ１６）を用いて正規化値
（０〜６５５３５）を求めステップＳ４２に進む。

【００６７】一方、入り口ノードでない場合はステップ
Ｓ３６に進み、自ノードがロードバランシング実行ノー
ドであるか否かを判別する。ロードバランシング実行ノ
ードの場合、つまり、エリア境界ノードである場合には
ステップＳ３８に進み、ＭＰＬＳがパケットに付加する
ラベルの値をもとにＬ２ルーティング制御部５７が宛先
アドレスルックアップテーブルを検索して同様の識別子
を得る。なお、検索にはＣＡＭなどの特殊メモリを持つ
ハードウェアを用いて高速化しても良い。そして、得ら
れた識別子をもとにエリア内宛先決定部５８がエリア内
宛先決定テーブル６５を検索し、ロードバランシングの
宛先に対応した識別子（Ｌ．Ｂ．Ｔａｂｌｅ Ｐｏｉｎ
ｔｅｒ）を決定する。その後、ステップＳ４０でスイッ
チング情報に付加されている正規化値を抽出してステッ
プＳ４２に進む。

【００６８】ステップＳ４２では、上記のエリア内宛先
に対応する識別子をもとに、トラフィック分散部３５，
５５が図２１に示す構造の閾値テーブル４６，６６を検
索した先の領域には、該当ＴＥパスグループ内の各ＬＳ
Ｐに対して、どの割合でロードバランシングを実施する
べきかを示す閾値が設定されている。例えばデフォルト
パス１本、ＴＥマルチパス２本で構成されるＴＥパスグ
ループがロードバランシングを行っていた場合、図２３
（Ａ）に示すように、閾値テーブル４６，６６を検索し
た先の領域は２つの負荷分散境界値によってＬＳＰ１，
ＬＳＰ２，ＬＳＰ３に対応した３領域に分割される。

【００６９】ここで、上記で求めたＬＳＰ１，ＬＳＰ
２，ＬＳＰ３の総領域は、正規化値（０〜６５５３５）
の範囲で割当てられているため、トラフィック分散部３
３，３５が正規化値と閾値テーブル４６，６６内の領域
を照らし合わせることにより、そのトラフィックがＴＥ
パスグループ内のどのＬＳＰに負荷分散されるかが一意
に決まる。また、図１４のフローチャートにおいてＴＥ
マルチパスが追加または削除される度に、この領域の負
荷分散境界の数も増減するため、それに従い領域の再設
定が行われる。

【００７０】ステップＳ４４では、出力ポート／スイッ
チング情報決定部３６，５６は、エリア内宛先決定部３
８，５８よりエリア内のロードバランシング実行宛先を
受け取り、トラフィック分散部３５，５５よりどのＬＳ
Ｐがトラフィックの分散先であるかの情報を受け取り、
それをもとに図２２に示す構造のスイッチング情報決定
テーブル４７，６７を検索して、パケットを次ノードに
出力する際に付加するラベル情報およびパケットの出力
ポートを求める。

【００７１】次ノードに送出するパケットのスイッチン
グ情報はスイッチング情報生成部３９，５９で生成する
が、ステップＳ４５で自ノードが入り口ノードか否かを
判別し、入り口ノードの場合にのみステップＳ４６に進
み、図２３（Ｂ）に示すように、通常のスイッチング情
報の他に、ハッシュ演算により算出した正規化値も一緒
に付加する。これが従来と異なる点である。

【００７２】これは、本発明ではエリア境界ノードもロ
ードバランシングを実行するため、パケットを受信した
エリア境界ノードの正規化抽出部５４が、図２３（Ｃ）
に示すように、入り口ノードがパケットに付加した正規
化値を参照することで、エリア境界ノードも入り口ノー
ドと同様の付加分散処理が行えるようにするものであ
る。つまり、ロードバランシングノードがエリア境界ノ
ードの場合は、新たに宛先アドレスから正規化値を算出
する必要がなく、入り口ノードにて計算された値を流用
するだけで済む為、より高速なフォワーディングが実現
できる。

【００７３】上記の手法により複数パスによるロードバ
ランシングが実行されている場合を前提として、パス上
で障害が発生した状況について説明する。

【００７４】図２４に示すように、ロードバランシング
を実行中のマルチパス上でリンクまたはノード障害が発
生した場合、従来はデフォルト３０秒の比較的長い周期
により隣接ノード間で送出し合うＯＳＰＦのＨｅｌｌｏ
プロトコル等を利用してトポロジー変化を認識し障害を
検出していたのに対し、本発明では、既存のハード機能
であるリンク毎のＬＯＳ（Ｌｏｓｓ ｏｆ ｓｉｇｎａ
ｌ）あるいはＬＯＦ（Ｌｏｓｓ ｏｆ ｆｒａｍｅ）の
検出をトリガに障害通知を行うことで、より早い段階で
障害を認識する。図２４においては、コアノード２６ａ
が障害を認識している。

【００７５】図２５は、障害を検出したノードの障害通
知部６２が実行する障害検出処理の一実施例のフローチ
ャートを示す。同図中、ステップＳ５０で自ノードがロ
ードバランシング実行ノードか否かを判別し、ロードバ
ランシング実行ノードの場合は通知を行う必要が無いた
め、後述の障害通知受信処理を実行する。バランシング
実行ノードでなければステップＳ５４で、ロードバラン
シングを実施している最も近い上流側ノード（入り口ノ
ードまたはエリア境界ノード）宛に障害の発生を通知す
る。図２６では障害を認識したコアノード２６ａがエリ
ア境界ノード２５ｄに障害の発生を通知している。

【００７６】障害の通知方法としては、図２７に示す構
造のＲＳＶＰ−ＬＳＰ−ＴｕｎｎｅｌのＲｅｓｖ Ｔｅ
ａｒメッセージをＬ２インタフェース部５１から送信す
ることで可能である。その他にもホップｂｙホップによ
るリンク単位での通知や、トラフィックと逆方向に障害
通知用のＬＳＰを設定する方法も考えられる。Ｒｅｓｖ
Ｔｅａｒメッセージを使用する場合の例として、パス
設定時に送信するＰａｔｈメッセージのＳＥＳＳＩＯＮ
オブジェクト内にロードバランシング実行ノードのアド
レスを設定する。このロードバランシング実行ノードの
アドレスは、図２８に示すようにＰａｔｈメッセージが
ロードバランシング実行ノードを通過する度に順次置き
換えられる。パス上の各ノードは、Ｐａｔｈメッセージ
通過時にこのアドレスを自ノードに保存しておき、障害
検出時には、保存されたロードバランシング実行ノード
のアドレスに向けてＲｅｓｖ Ｔｅａｒメッセージを送
信することで障害を通知できる。

【００７７】図２９は、障害通知を受信したロードバラ
ンシング実行ノードが実行する障害通知受信処理の一実
施例のフローチャートを示す。

【００７８】同図中、ステップＳ６０で自ノードがロー
ドバランシング実行ノードか否かを判別し、ロードバラ
ンシング実行ノードであれば、ステップＳ６２で障害通
知受信部６０で当該障害ルートに流していたトラフィッ
クについて、当該障害ルート以外の全ルートでの負荷分
散が実行可能かどうか判定を行う。この判定方法として
は、ロードバランシング時に収集した各ＬＳＰの使用率
を利用する。

【００７９】例えば図３０（Ａ）に示すようにＴＥパス
グループ内の各ＬＳＰ１（１０Ｍｂｐｓ中の６Ｍｂｐｓ
を使用）、ＬＳＰ２（３０Ｍｂｐｓ中の２５Ｍｂｐｓを
使用）、ＬＳＰ３（１０Ｍｂｐｓ中の４Ｍｂｐｓを使
用）において、図に示す使用率でロードバランシングを
実行中に、ＬＳＰ１上で障害が発生したとする。この場
合、ＴＥパスグループ全体での空き帯域（１５Ｍｂｐ
ｓ）からＬＳＰ１の空き帯域（４Ｍｂｐｓ）を引いた結
果と、ＬＳＰ１の実行負荷（６Ｍｂｐｓ）とを比較す
る。この場合、引いた結果が当該障害ルート（ＬＳＰ
１）の実効負荷よりも大いので、再分散を実施してもト
ラフィックロスは発生しないものとステップＳ６２で判
定し、ステップＳ６４でトラフィック分散部３５により
当該障害ルート以外の全ルートＬＳＰ２，ＬＳＰ３に対
してトラフィックが再分散される。この時、閾値テーブ
ル４６については、図３１（Ａ）に示すように負荷分散
境界の数を１つ減らし（当該障害ＬＳＰ１の領域が削除
されるため）、残りのＬＳＰ２，ＬＳＰ３で領域の再分
配を行う。この様子を図３２（Ａ）に模式的に示す。

【００８０】逆に、ステップＳ６２で図３０（Ｂ）に示
すように、再分散すればトラフィックロスが発生すると
判定した場合、ステップＳ６６でトラフィック分散部３
５よりパス設定／解放部４３に対して、新たにエリア内
に閉じたＴＥマルチパスを追加設定するよう指示が出さ
れる。新しいＴＥマルチパスの追加方法は、通常のロー
ドバランシングにおけるＴＥマルチパスの追加処理と同
様である。ＴＥマルチパスを追加した後、ステップＳ６
８で当該障害ルートに流していたトラフィックが新たに
設定したＬＳＰのルートに対してトラフィック分散部３
５により切替えられる。この時の閾値テーブルの領域は
図３１（Ｂ）に示すように変更される。この様子を図３
２（Ｂ）に模式的に示す。

【００８１】以上の処理を通して、ロードバランシング
を実施しているパス上で障害が起きた際のトラフィック
ロスを高速に救済することが可能になる。つまり、例え
ばＯＳＰＦのネットワークを介したユーザ間でＴＣＰを
使用したサービス（Ｔｅｌｎｅｔ等）実施中にルート上
で障害が発生した場合、通常であれば障害を検出復旧す
るまでＡｃｋを受信出来ないため、コネクションが切断
されてしまう可能性があるが、高速な障害検出トラフィ
ック救済を実施することで、それが回避可能となる。

【００８２】このように、ＯＳＰＦのエリアなどの階層
化の概念を用いた大規模なルーティングプロトコルネッ
トワークにて、エリア内で閉じたロードバランシングを
行うことにより、各ノードはエリア内の全トラフィック
データを持つだけでよく、トラフィックエンジニアリン
グに使用する全エリアのデータを保持する必要がないた
め、ロードバランシング実行ノードが必要とするメモリ
容量を大幅に削減でき、既存技術では不可能であった大
規模ネットワークにおいても最適なトラフィックエンジ
ニアリングが可能となる。

【００８３】また、エッジノードにてソースアドレスや
デスティネーションアドレスなどを基にロードバランシ
ングを行う正規化値を算出し、当該正規化値をエリア境
界ノードに通知し、エリア境界ノードは当該正規化値を
使用して、ロードバランシングを実行することにより、
エリア境界ノードにてＩＰやＩＰＸなどのプロトコルの
識別やＩＰプロトコルなどのヘッダチェックなどを行う
必要がないため、カットスルー方式のパケット転送方式
の利点を生かしたまま高速フォワーディングにてロード
バランシングが可能となる。

【００８４】また、複数のルートを用いてロードバラン
シングを行っている状態において、１つのルートで何ら
かの障害が発生した場合、当該障害を検出したノード
が、ロードバランシングを実行しているノードに障害を
通知し、障害通知を受信したロードバランシング実行ノ
ードが当該障害ルートに流していたトラフィックを、そ
れ以外の複数ルートに分配することにより、障害ルート
を流れていたトラフィックでのトラフィックロスを高速
に救済することが可能となる。また、これまではー変化
を待って、ユーザトリガのコネクション再確立が必要で
あったが、トラフィックロスを高速に救済できることか
ら、アグリゲートされたＴＣＰコネクションなどのマイ
クロフローの救済も可能となる。

【００８５】更に、障害通知を受信したロードバランシ
ング実行ノードが当該障害ルートに流していたトラフィ
ックを、それ以外の複数ルートに分配するとトラフィッ
クロスが発生すると判断した場合、新たにルートを設定
し、当該障害ルートに流していたトラフィックを、新た
に設定したルートに切替を行うことにより、障害ルート
以外のルートが高トラフィックの場合でも、障害ルート
に流していたトラフィックを救済することができ、より
信頼性の高いコネクションレスパケット転送サービスを
提供可能となる。

【００８６】なお、エリア内宛先決定部３８，５８が請
求項記載のエリア内宛先決定手段に対応し、スイッチン
グ情報生成手段がスイッチング情報生成部３９に対応
し、正規化値抽出部５４が正規化値抽出手段に対応し、
障害通知部６２が障害通知手段に対応し、障害通知受信
部４０が障害通知受信手段に対応する。

【００８７】（付記１） ネットワーク全体が複数ノー
ドの集合体であるエリアに分割されており、前記ネット
ワークのトラフィックエンジニアリングを行う方法にお
いて、各エリア毎にエリア内で閉じたロードバランシン
グを実行することを特徴とするトラフィックエンジニア
リング方法。

【００８８】（付記２） 全体が複数ノードの集合体で
あるエリアに分割され、かつ、全体の資源の最適化がト
ラフィックエンジニアリングにより行われるネットワー
クを構成するノード装置において、各エリア毎にエリア
内で閉じたロードバランシングを行うためのエリア内宛
先を決定するエリア内宛先決定手段を有することを特徴
とするノード装置。

【００８９】（付記３） 付記２記載のノード装置にお
いて、外部からパケットが供給される入り口ノードを構
成するノード装置は、外部から供給されたパケットのア
ドレス情報を基にロードバランシングを行うための正規
化値を演算し、前記正規化値を前記パケットのスイッチ
ング情報に付加するスイッチング情報生成手段とを有す
ることを特徴とするノード装置。

【００９０】（付記４） 付記２記載のノード装置にお
いて、エリアの境界にあるエリア境界ノードを構成する
ノード装置は、隣接エリアから供給されるパケットのス
イッチング情報から、自エリア内で閉じたロードバラン
シングを実行するための正規化値を抽出する正規化値抽
出手段を有することを特徴とするノード装置。

【００９１】（付記５） 全体が複数ノードの集合体で
あるエリアに分割され、かつ、全体の資源の最適化がト
ラフィックエンジニアリングにより行われるネットワー
クを構成するノード装置において、障害を検出したとき
ロードバランシングを実行している最も近い上流側のノ
ードに障害を通知する障害通知手段を有することを特徴
とするノード装置。

【００９２】（付記６） 付記２記載のノード装置にお
いて、障害通知を受信した前記入り口ノードまたはエリ
ア境界ノードは、障害が発生したルートに流していたト
ラフィックを他のルートに分散しなおすトラフィック分
散手段を有することを特徴とするノード装置。

【００９３】（付記７） 付記６記載のノード装置にお
いて、障害通知を受信した前記入り口ノードまたはエリ
ア境界ノードは、障害が発生したルートに流していたト
ラフィックを他のルートに分散しなおしたときトラフィ
ックロスが発生するか否かを判定する障害通知受信手段
を有することを特徴とするノード装置。

【００９４】（付記８） 付記７記載のノード装置にお
いて、前記トラフィック分散手段は、前記障害通知受信
手段でトラフィックロスが発生すると判定したとき、前
記障害が発生したルートに流していたトラフィックを新
たに設定したルートに切り替えることを特徴とするノー
ド装置。

【００９５】

【発明の効果】上述の如く、請求項１に記載の発明は、
各エリア毎にエリア内で閉じたロードバランシングを実
行するため、大規模ネットワークであってもロードバラ
ンシング実行ノードが必要とするメモリ容量を大幅に削
減でき高速にロードバランシングを実行することができ
る。

【００９６】請求項２に記載の発明は、各エリア毎にエ
リア内で閉じたロードバランシングを行うためのエリア
内宛先を決定するエリア内宛先決定手段を有するため、
エリア内で閉じたロードバランシングを実行することが
可能となり、大規模ネットワークであってもロードバラ
ンシング実行ノードが必要とするメモリ容量を大幅に削
減でき高速にロードバランシングを実行することができ
る。

【００９７】請求項３に記載の発明は、外部からパケッ
トが供給される入り口ノードを構成するノード装置は、
外部から供給されたパケットのアドレス情報を基にロー
ドバランシングを行うための正規化値を演算する正規化
値演算手段と、正規化値を、パケットのスイッチング情
報に付加するスイッチング情報生成手段とを有するた
め、エリア境界ノードに正規化値を通知することが可能
となる。

【００９８】請求項４に記載の発明は、エリアの境界に
あるエリア境界ノードを構成するノード装置は、隣接エ
リアから供給されるパケットのスイッチング情報から、
自エリア内で閉じたロードバランシングを実行するため
の正規化値を抽出する正規化値抽出手段を有するため、
エリア境界ノードでは抽出した正規化値を用いてロード
バランシングを行うことができ、プロトコルの識別やヘ
ッダチェックなどを行う必要がなく高速のロードバラン
シングを行うことができる。

【００９９】請求項５に記載の発明は、障害を検出した
ときロードバランシングを実行している最も近い上流側
のノードに障害を通知する障害通知手段を有するため、
ロードバランシングを実行しているノードでトラフィッ
クの分配を高速に行うことが可能となる。

【０１００】付記６に記載の発明は、障害通知を受信し
た入り口ノードまたはエリア境界ノードは、障害が発生
したルートに流していたトラフィックを他のルートに分
散しなおすトラフィック分散手段を有するため、障害ル
ートを流れていたトラフィックでのトラフィックロスを
高速に救済することが可能となる。

【０１０１】付記７に記載の発明は、障害通知を受信し
た入り口ノードまたはエリア境界ノードは、障害が発生
したルートに流していたトラフィックを他のルートに分
散しなおしたときトラフィックロスが発生するか否かを
判定する障害通知受信手段を有するため、障害が発生し
たルートに流していたトラフィックを他のルートに分散
可能か否かを認識できる。

【０１０２】付記８に記載の発明は、トラフィック分散
手段は、障害通知受信手段でトラフィックロスが発生す
ると判定したとき、障害が発生したルートに流していた
トラフィックを新たに設定したルートに切り替えるた
め、障害ルート以外のルートが高トラフィックの場合で
も、障害ルートに流していたトラフィックを救済するこ
とができる。

【図面の簡単な説明】

【図１】従来の一般的なＩＰパケットフォワーディング
処理を示す図である。

【図２】従来のＭＰＬＳによるＩＰパケットフォワーデ
ィング処理を示す図である。

【図３】従来のトラフィックエンジニアリング方式を説
明するための図である。

【図４】従来のトラフィック分散方式を説明するための
図である。

【図５】ＬＳＰ決定テーブルのＬＳＰの境界を移動を説
明するための図である。

【図６】本発明のトラフィックエンジニアリング方法を
適用したネットワークシステムの一実施例の構成図であ
る。

【図７】本発明方法に適用される発側エッジノードの一
実施例のブロック構成図である。

【図８】本発明方法に適用されるコアノードの一実施例
のブロック構成図である。

【図９】デフォルトパス設定処理の一実施例のフローチ
ャートである。

【図１０】デフォルトパス設定を説明するための図であ
る。

【図１１】ハードウエアによるトラフィック情報収集を
示す図である。

【図１２】ＯＳＰＦのＯｐａｑｕｅＬＳＡのフォーマッ
トを示す図である。

【図１３】広告の様子を示す図である。

【図１４】ロードバランシング処理の第１実施例のフロ
ーチャートである。

【図１５】ＴＥパスグループの使用率算出を説明するた
めの図である。

【図１６】輻輳状況の監視と判定を説明するための図で
ある。

【図１７】エリア単位のＴＥマルチパスの設定を示す図
である。

【図１８】ロードバランシング処理の第２実施例のフロ
ーチャートである。

【図１９】宛先アドレスルックアップテーブル４４の構
成を示す図である。

【図２０】エリア内宛先決定テーブル４５の構造を示す
図である。

【図２１】構造の閾値テーブル４６，６６の構造を示す
図である。

【図２２】スイッチング情報決定テーブル４７，６７の
構造を示す図である。

【図２３】付加分散実施を説明するための図である。

【図２４】ロードバランシング中での障害検出を説明す
るための図である。

【図２５】障害を検出したノードの障害通知部６２が実
行する障害検出処理の一実施例のフローチャートであ
る。

【図２６】ロードバランシング実行ノードへの障害通知
を説明するための図である。

【図２７】ＲＳＶＰ−ＬＳＰ−ＴｕｎｎｅｌのＲｅｓｖ
Ｔｅａｒメッセージの構造を示す図である。

【図２８】各ノードへの障害通知を説明するための図で
ある。

【図２９】障害通知を受信したロードバランシング実行
ノードが実行する障害通知受信処理の一実施例のフロー
チャートである。

【図３０】再分散によるトラフィックロス発生判定を説
明するための図である。

【図３１】再分散による閾値テーブルの変化を説明する
ための図である。

【図３２】障害検出後の負荷分散を説明するための図で
ある。

【符号の説明】

３１ Ｌ３インタフェース部 ３２，５２ バッファ部 ３３，５１，５３ Ｌ２インタフェース部 ３４ 正規化値演算部 ３５，５５ トラフィック分散部 ３６，５６ 出力ポート／スイッチング情報決定部 ３７，５７ ルーティング制御部 ３８，５８ エリア内宛先決定部 ３９，５９ スイッチング情報生成部 ４０，６０ 障害通知受信部 ４１，６１ トラフィック管理部 ４３，６３ パス設定／解放部 ４４，６４ 宛先アドレスルックアップテーブル ４５，６５ エリア内宛先決定テーブル ４６，６６ 閾値テーブル ４７，６７ スイッチング情報決定テーブル ５４ 正規化値抽出部 ６２ 障害通知部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 木下 博 福岡県福岡市早良区百道浜２丁目２番１号 富士通西日本コミュニケーション・シス テムズ株式会社内 Ｆターム(参考） 5K030 HA08 HC01 HD05 KA05 LB05 LC09 LE03 LE17 MB01

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ネットワーク全体が複数ノードの集合体
   であるエリアに分割されており、前記ネットワークのト
   ラフィックエンジニアリングを行う方法において、 各エリア毎にエリア内で閉じたロードバランシングを実
   行することを特徴とするトラフィックエンジニアリング
   方法。
2. 【請求項２】 全体が複数ノードの集合体であるエリア
   に分割され、かつ、全体の資源の最適化がトラフィック
   エンジニアリングにより行われるネットワークを構成す
   るノード装置において、 各エリア毎にエリア内で閉じたロードバランシングを行
   うためのエリア内宛先を決定するエリア内宛先決定手段
   を有することを特徴とするノード装置。
3. 【請求項３】 請求項２記載のノード装置において、 外部からパケットが供給される入り口ノードを構成する
   ノード装置は、外部から供給されたパケットのアドレス
   情報を基にロードバランシングを行うための正規化値を
   演算し、前記正規化値を前記パケットのスイッチング情
   報に付加するスイッチング情報生成手段とを有すること
   を特徴とするノード装置。
4. 【請求項４】 請求項２記載のノード装置において、 エリアの境界にあるエリア境界ノードを構成するノード
   装置は、隣接エリアから供給されるパケットのスイッチ
   ング情報から、自エリア内で閉じたロードバランシング
   を実行するための正規化値を抽出する正規化値抽出手段
   を有することを特徴とするノード装置。
5. 【請求項５】 全体が複数ノードの集合体であるエリア
   に分割され、かつ、全体の資源の最適化がトラフィック
   エンジニアリングにより行われるネットワークを構成す
   るノード装置において、 障害を検出したときロードバランシングを実行している
   最も近い上流側のノードに障害を通知する障害通知手段
   を有することを特徴とするノード装置。