JP4150159B2 - 伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 - Google Patents
伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 Download PDFInfo
- Publication number
- JP4150159B2 JP4150159B2 JP2000376615A JP2000376615A JP4150159B2 JP 4150159 B2 JP4150159 B2 JP 4150159B2 JP 2000376615 A JP2000376615 A JP 2000376615A JP 2000376615 A JP2000376615 A JP 2000376615A JP 4150159 B2 JP4150159 B2 JP 4150159B2
- Authority
- JP
- Japan
- Prior art keywords
- load
- communication device
- transmission path
- traffic
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
- H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
- H04L43/0829—Packet loss
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネットプロトコルネットワーク（以下、インターネットプロトコルをＩＰと略称する場合がある。従って、インターネットプロトコルネットワークはＩＰネットワークと略称される）を構成する通信装置（例えば、ルータ）に設けられる伝送経路制御装置に関し、更には同装置にて実行される伝送経路制御方法並びに同装置で使用される伝送経路制御プログラムを記録した媒体に関する。
【０００２】
【従来の技術】
インターネットは、現在全ての通信アプリケーションをインターネットプロトコル上で扱うことを意図し、急速に普及しつつある。更にインターネットは、元来、コネクションを確立しないコネクションレスなネットワークアーキテクチャを持ち、且つ、ＩＰパケット内に記述されている宛先アドレスを基に、出方路へとルーティングされるようになっている。つまり、かかる機能を持つ通信装置内では、ＩＰパケットが装置に到着した時点で、そのＩＰアドレスに該当する出方路へとＩＰパケットを転送するだけである。
【０００３】
このようなネットワークアーキテクチャを持つインターネットでは、どのＩＰアドレスをどの出方路へ転送するかを決定するために、ルーティングプロトコルと呼ばれる経路決定用のプロトコルが通信装置間で取り扱われている。
現在、ルーティングプロトコル用のアルゴリズムとして、ダイクストラ（Dijkstra）のアルゴリズムを用いた方式が一般的である。しかしながら、かかるルーティングプロトコルでは、着信先までの複数のルートを選択することができなかったり、ネットワークトポロジーが変化したときしか、ルーティングプロトコルが実行されなかったりするという課題がある。
【０００４】
つまり、上記のような技術では、いったんルートが確定してしまうと、そのルートしかＩＰパケットは転送されないことになり、その結果、慢性的な輻輳が発生してしまうおそれがある。
また、上記のような技術では、複数のルートを設定することができないため、あるルートが輻輳していても、別のルートが空いているにもかかわらず、そのルートを使用することができないという課題もある。
【０００５】
そこで、次のような技術が提案されている。
（１−１）OSPF(Open Shortest Path First)における等コストマルチパス(EqualCost Multipath ) 技術
（１−２）IBGP(Internal Border Gateway Protocol)におけるマルチパス(Multipath) 技術
すなわち、（１−１）の技術による手法は、OSPFの機能を用いた手法であり、起点となる通信装置から終点となる通信装置までに、コストが等価なパスを複数本張ることができる機能を用いて、この複数本のパス( マルチパス) 間で負荷の分散を行なうようにしているのである。
【０００６】
また、（１−２）の技術による手法は、IBGPの機能を用いて、パスを複数本張り、この複数本のパス( マルチパス) 間で負荷の分散を行なうようにしているのである。
【０００７】
【発明が解決しようとする課題】
しかしながら、このような上記（１−１）によるOSPFの機能を用いた手法では次のような課題がある。
すなわち、マルチパスはコストが等価でなければならないという制限があり、パス選択の自由度が低く、更にOSPFを使用しているため、リアルタイムでのネットワーク負荷の変動に対処できない。
【０００８】
また、上記（１−２）によるIBGPの機能を用いた手法でも、OSPFの機能を用いた手法での課題と同様、マルチパスはコストが等価でなければならないという制限があり、パス選択の自由度が低いという課題を有する。
なお、ネットワークを相互に接続するデータ処理装置間で、レイヤ３でパスを設定し、レイヤ３でのルート単位で負荷を分散することにより、動的にトラヒック平衡を与えて、ネットワーク性能を改善する技術も提案されているが( 特開平10-224400 号公報参照) 、かかる技術では、ネットワーク間でのトラヒック平衡を与えることはできても、ネットワーク内での負荷分散を行なうことはできず、更にレイヤ３で且つルート単位での負荷分散しか考慮しておらず、負荷分散制御が複雑になるおそれがある。
【０００９】
本発明は、このような課題に鑑み創案されたもので、ネットワーク内の通信装置において、起点となる通信装置（発信元通信装置) から終点となる通信装置（着信先通信装置) までに複数のルート（伝送経路) を設定し、設定されたルート間で負荷の分散を行なえるようにして、ネットワークトポロジーに関係なく、また伝送経路の種類によらないで、インターネット等のネットワーク内でトラヒックエンジニアリングを可能にした、伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体を提供することを目的とする。
【００１０】
【課題を解決するための手段】
図１（ａ），（ｂ）は本発明の原理説明図であるが、まず、本発明にかかる伝送経路制御装置は、図１(a) に示すようなＩＰネットワーク（このＩＰネットワークは、発信元通信装置１Ｓと、着信先通信装置１Ｄと、発信元通信装置１Ｓと着信先通信装置１Ｄとの間に設定可能な複数の伝送経路２−ｉ（ｉ＝１〜Ｎ：Ｎは自然数）と、上記伝送経路２−ｉのいずれかに介装される中継通信装置１Ｒとをそなえている）を構成する通信装置１Ｓ又は１Ｄ又は１Ｒ（以下、発信元通信装置１Ｓ，着信先通信装置１Ｄ，中継通信装置１Ｒを特に区別しないで表記する場合は、単に通信装置１という）に設けられる装置である。
【００１１】
そして、本発明にかかる伝送経路制御装置は、図１（ｂ）に示すように、トラヒック特性収集部３，トラヒック特性通知部４，負荷演算部５，判定部６及び負荷均等化部７をそなえている。
ここで、トラヒック特性収集部３は、通信装置１又は他の通信装置に接続された伝送経路２−ｉのトラヒック特性を収集するものであり、自己の通信装置１でのトラヒック特性を収集するトラヒック特性収集部３Ａと、他の通信装置から通知されるトラヒック特性を受信するトラヒック特性受信部３Ｂとで構成されている。
【００１２】
トラヒック特性通知部４は、トラヒック特性収集部３（特に３Ａ）で収集されたトラヒック特性を他の通信装置に通知するものである。
また、負荷演算部５は、トラヒック特性収集部３で収集されたトラヒック特性に基づいて負荷を演算するものである。
判定部６は、負荷演算部５で求められた負荷情報に基づいて、伝送経路を追加するか削除するかの判定を行なうもので、負荷均等化部７は、負荷演算部５で求められた負荷を前記発信元通信装置１Ｓと前記着信先通信装置１Ｄとの間に設定された複数の伝送経路間で均等化するものである。
【００１３】
なお、発信元通信装置１Ｓ，着信先通信装置１Ｄ，中継通信装置１Ｒのそれぞれに設けられる伝送経路制御装置に、上記のようなトラヒック特性収集部３，トラヒック特性通知部４，負荷演算部５，判定部６及び負荷均等化部７を設けることは勿論可能であるが、発信元通信装置１Ｓに設けられる伝送経路制御装置に、トラヒック特性収集部３，トラヒック特性通知部４，負荷演算部５，判定部６及び負荷均等化部７を設け、発信元通信装置１Ｓ以外の着信先通信装置１Ｄ，中継通信装置１Ｒのそれぞれに設けられる伝送経路制御装置には、トラヒック特性収集部３，トラヒック 特性通知部４だけを設けることは原理上可能である。
【００１４】
なお、トラヒック特性収集部３が、収集したトラヒック特性値を平滑化する手段を有していてもよい。
さらに、発信元通信装置１Ｓに設けられるトラヒック特性収集部３が、発信元通信装置１Ｓに接続された各伝送経路２−ｉの使用率を、中継通信装置１Ｒから収集した中継通信装置１Ｒに接続されている伝送経路２−ｉの使用率に関する情報を基に判定する手段を有していてもよい。
【００１５】
また、発信元通信装置１Ｓに設けられる負荷演算部５が、中継通信装置１Ｒにおいて発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、発信元通信装置１Ｓに設けられる判定部６が、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段を有するとともに、この演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成してもよい。
【００１６】
さらに、発信元通信装置１Ｓに設けられる判定部６が、負荷演算部５で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、この削除候補選択手段により選択された削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、この負荷予測手段により予測された他の伝送経路の負荷を所定の基準値と比較し、この比較結果に応じて、この削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成してもよい。
【００１７】
また、発信元通信装置１Ｓに設けられる負荷均等化部７が、中継通信装置１Ｒにおいて発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有するように構成してもよい。
【００１８】
そして、本発明では、発信元通信装置１Ｓと、着信先通信装置１Ｄと、発信元通信装置１Ｓと着信先通信装置１Ｄとの間に設定可能な複数の伝送経路２−ｉと、伝送経路２−ｉのいずれかに介装される中継通信装置１ＲとをそなえてなるＩＰネットワークを構成する発信元通信装置以外の他の通信装置において、
（Ａ１）他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
（Ａ２）トラヒック特性収集ステップで収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知ステップとが実行されるとともに、上記発信元通信装置１Ｓにおいて、
（Ｂ１）発信元通信装置１Ｓに接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
（Ｂ２）トラヒック特性収集ステップで収集されたトラヒック特性及び他の通信装置から得られたトラヒック特性の一方又は両方に基づいて負荷を演算する負荷演算ステップと、
（Ｂ３）負荷演算ステップで求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定ステップと、
（Ｂ４）負荷演算ステップで求められた負荷を前記発信元通信装置１Ｓと前記着信先通信装置１Ｄとの間に設定された複数の伝送経路間で均等化する負荷均等化ステップとが実行される。
【００１９】
また、上記図１（ａ）に示すＩＰネットワークを構成する１で使用すべく、通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集手段と、トラヒック特性収集手段で収集された該トラヒック特性を他の通信装置に通知するトラヒック特性通知手段と、トラヒック特性収集手段で収集された該トラヒック特性に基づいて負荷を演算する負荷演算手段と、負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定手段と、負荷演算手段で求められた負荷を前記発信元通信装置と前記着信先通信装置との間に設定された複数の伝送経路間で均等化する負荷均等化手段として、上記通信装置を機能させるための伝送経路制御プログラムを記録した媒体も用意されている。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
本発明の実施の形態として、ラベルスイッチ型ルータ（通信装置）としてのＭＰＬＳルータに本伝送経路制御装置を装備して、ＭＰＬＳ(Multi-Protoco1 Label Switching)を用い、ＭＰＬＳのラベル機能を用いて、ルーテイングプロトコルとは異なるルートを設定し、負荷分散を行なう場合について説明する。ここで、ＭＰＬＳとは、レイヤ２のラベルをＩＰに特化して使用することにより、現在のルータでは実現困難なサービスを簡易にかつ効果的に行なうことが可能な方式をいう。
【００２１】
以下においては、ＭＰＬＳの概要を説明した上で、ＭＰＬＳにおける負荷分散手法ないし負荷分散アルゴリズム（作用説明を含む）について説明する。
（２−１）ＭＰＬＳの概要説明
まず、ＭＰＬＳの概要を説明する。図２（ａ），（ｂ）に、ＭＰＬＳのネットワーク構成および基本パケット転送要領を示す。ＭＰＬＳネットワークは、エッジ・ラベル・スイッチング・ルータ（Edge Label Switching Router 、以下、エッジＬＳＲという）１１Ｅやコア・ラベル・スイッチング・ルータ（Core LabelSwitching Router 、以下、コアＬＳＲという）１１Ｃで構成される。これをＭＰＬＳドメインと呼ぶ。
【００２２】
ここで、エッジＬＳＲ１１Ｅは、図２（ａ），（ｂ）に示すように、既存インターネットワークとの境界に位置し、パケットにラベルを付加することによって、高性能、高付加価値のネットワークレイヤサービスを実現するルータであり、このエッジＬＳＲは、ラベル付けされていないフレームベース（Frame Base）のLAN インターフェースを終端するものである。
【００２３】
また、コアＬＳＲ１１Ｃは、ラベルが付加されたパケットやセルをラベル交換するルータであり、このコアＬＳＲ１１Ｃは、ラベル交換ばかりでなく、レイヤ３ルーティングやレイヤ２スイッチングをサポートするように構成することもできる。
また、標準のネットワークレイヤのルーティングプロトコルと連携し、ラベル・スイッチングによるインターネットワーク上のデバイス間でラベル情報を交換しあう際に用いられるプロトコルは、ラベル・ディストリビューション・プロトコル〔 Label Distribution Protoco1 (LDP)〕である。
【００２４】
なお、図２（ａ）の符号９Ｓ，９Ｄはパソコン等の端末を示している。
図２（ａ）に示すようなＭＰＬＳネットワークでは、ＭＰＬＳドメイン内に到着したＩＰパケットに、着信端末へと通じるパスに対応づけられたラベルが、エッジＬＳＲ１１Ｅにより付与される。図２（ｂ）では、ラベルＡが付与され、コアＬＳＲ１１Ｃへと送出される。コアＬＳＲ１１Ｃでは、そのラベルのみを見て、ラベルＡに対応する出力方路へと交換する。交換された出方路にパケットを送出するときには、新たにラベルＢが付与される。これをラベルスワッピングと呼ぶ。このようにＭＰＬＳドメイン内では、ラベルスワッピングを行ないながら、ラベルに従い順次目指す着信端末９Ｄへと転送されていく。ＭＰＬＳドメインの出口のエッジＬＳＲ１１Ｅではラベルは取り除かれ、ＭＰＬＳドメインヘと転送される。
【００２５】
次に、ＭＰＬＳで用いるラベルについて説明する。
まず、ＭＰＬＳを実現するには以下の２つの手法がある。
▲１▼既存スイッチを流用する手法
▲２▼新ラベルを定義する手法
▲１▼による既存スイッチを流用する手法は、非同期転送モード（ATM :Asynchronous Transfer Mode)）やフレームリレー（Frame Relay ，ＦＲとも表記する）といった既存スイッチを用いる手法であり、ATM では仮想パス識別子（VPI ）と仮想チャネル識別子（ VCI）との領域をラベルとして用い、フレームリレーではDLCIをラベルとして用いる。
【００２６】
▲２▼による新ラベルを定義する手法では、シム(Shim)ヘッダと呼ばれる新たに定義されたラベルを用いる。シムヘッダはレイヤ３とレイヤ２との間に挿入されるが、図３にその概要を示す。
シムヘッダには、図３に示すように、ラベルの他、TTL やラベルスタック用のポインタＳが付与されている。ラベルスタックは、ラベルの階層化のために用いられ、このラベルスタックを用いることにより、例えばＭＰＬＳドメイン内で複数のＭＰＬＳドメインを階層化してネットワークを構築することができる。図３では、S ＝1 であると、それが最後のラベルであると認識されるようになっている。
【００２７】
なお、ラベルは、ATM/FR以外に、PPP over S0NET用や、イーサフレーム（ＬＡＮ）用にも定義されている（図３の右側に示されているＰＰＰやＬＡＮを参照）。
また、ラベルは、例えば4 オクテット長で図４のように示される。そして、このラベルは階層構造を持つことが可能であり、その構造をラベル・スタック（Label stack ）と呼ぶ。図４に示すラベルおよびその他の付加情報は、MBLSで定義したＭＰＬＳヘッダに表示されるか、またはL2ヘッダやATM ヘッダにも表示される場合がある。
【００２８】
図４に示す S (Bottom of Stack)は、ラベル・スタックの最下位に位置する最終エントリである場合に、1 にセットされるもので、その他のエントリは全てO にセットされるものである。
また、図４に示す TTL (Time-to-Live) は、TTL をエンコードするために使用されるフィールドを表しており、ラベルドパケット（1abeled packet）がフォワードされる前に1 ずつ減算されるようになっている。減算されて0 になったパケットはそれ以上フォワードしてはならず、この場合、このパケットはそのまま廃棄されるか、ラベル・スタックを取り除かれて、ネットワークレイヤの処理に渡される。そして、ネットワークレイヤの処理に移行した後も決してこのパケットをフォワードしてはならないようになっている。
【００２９】
次に、ラベル・スイッチド・パス(Labe1 Switched Path：ＬＳＰ）について説明する。ＬＳＰとは、図５からもわかるように、入り口のＬＳＲから中間のＬＳＲを経て出口のＬＳＲまでのパスのことをいうが、ＬＳＰに対応づけられて、各ＬＳＲでのラベルが決定されるようになっている。本発明では、後述するが、トラヒック特性の収集を、ＬＳＰごとに行なうようになっている。
【００３０】
さらに、ＬＳＰを確立する手法について説明する。
まず、ＬＳＰを確立する手法として、以下の２方式がIETFで提案されている。
▲１▼LDP(Label Distribution Protoco1)を用いた手法
▲２▼RSVP- トンネル(RSVP-Tunne1) を用いた手法
以下は、▲２▼のRSVP-Tunne1 を用いた手法について説明する。
【００３１】
ＬＳＰ-tunne1 は、従来のRSVPを拡張して実行されるもので、この方式の背景は、ＭＰＬＳがRSVPを搭載している場合、それらを合体させることによりフローをより柔軟に管理可能であるであろうということから来ている。
ＬＳＰ-tunne1 はRSVPに対して以下の5 つの新オブジェクト[ LABEL REQUEST(パスメッセージ(PATH メッセージ) 中で使用するもの)，LABEL(Resvメッセージ中で使用するもの)，EXPLICIT ROUTE(PATHメッセージ中で使用するもの)，RECORD ROUTE(PATHメッセージ，Resvメッセージ中で使用するもの) 及びSESSION ATTRIBUTE(PATHメッセージ中で使用するもの) ] を定義している。
【００３２】
ここで、 LABEL REQUEST オブジェクトは、PATHメッセージ中で使用するものであり、中間ルータと受信ノードで、そのパスに関するラベルを決定するために使用される。パス( ＝ＬＳＰ-tunne1)を確立するために、送信元ＬＳＲはLABEL REQUEST を持つPATHメッセージを生成し、更にLABEL REQUEST を送信したノードは、そのPATHメッセージに対応するResvメッセージを受信する準備をしておかなければならない。もしLABEL REQUEST を含んでいないPATHメッセージを受け取ったならば、それにLABEL REQUEST オブジェクトを書き込んではならないようになっている。
【００３３】
LABEL オブジェクトは、 Resv メッセージ中で使用するものであるが、ＬＳＰ-tunnel では、ラベルはResvメッセージ中に入れて送信元へと返されるようになっている。そして、Resvメッセージは、PATHメッセージの経路に沿って送信元へ向かって返信される。さらに、LABEL オブジェクトを持つResvメッセージを受信した各ノードは、そのラベルをＬＳＰ-tunne1 の出力側のラベルとして使用し、もしそのノードがLABEL REQUEST の送信者でなかったならば、新たなラベルを割り当て、その新ラベルをResvメッセージのLABEL オブジェクトに置くという処理を実行するようになっている。そして、上流に送信したラベルは、そのＬＳＰ-tunne1 の入力側ラベルとして使用される。
【００３４】
EXPLICIT ROUTE オブジェクト(ER0) は、PATHメッセージ中で使用するものであるが、もしこのオブジェクトがPATHメッセージ中に現れたならば、そのPATHメッセージは、ERO によって明記されたパスに沿ってそのメッセージを転送しなければならない。ERO は明示的ルーティングに用いることを意図したものである。
RECORD ROUTE オブジェクトは、PATHメッセージ, Resvメッセージ中で使用するものであるが、これにより送信ノードがＬＳＰ-tunne1 の実際の経路についての情報を受け取ることが可能となる。これはパスベクトル(path vector) と似ていて、ループ検出にも使用できるもののである。
【００３５】
SESSION ATTRIBUTE オブジェクトは、PATHメッセージ中で使用するものであるが、このSESSION ATTRIBUTE オブジェクトは、PATHメッセージに付与されて、セッションの識別と診断に使用できる。更に、このオブジェクトは、プレエミッション(preemption ) , 優先権, ローカルプロテクションなどを持っている。
図６に、RSVPを用いたＬＳＰ-tunnel のメッセージの流れを示す。RSVP-tunnel は、下流からラベルを割り当てていくため、ダウンストリーム・オン・デマンド（Downstream-on-demand）方式である。図６からもわかるように、まず、ＭＰＬＳドメイン内の最初のＭＰＬＳルータ（ＬＳＲ１）が、RSVPのPATHメッセージ中にLABEL REQUEST オブジェクトを入れて下流へと送信する。その後、着信先のノード（ＬＳＲ４）のそのPATHメッセージが到達したならば、着信先ノード（ＬＳＲ４）はResvメッセージ中にLABEL オブジェクトを入れて、その上流へと返す。ラベルの割り当て方は上述した通りである。
【００３６】
本発明では、このRSVPメッセージ中にトラヒック特性値を埋め込んで転送している。
（２−２）ＭＰＬＳにおける負荷分散手法の説明
負荷分散をＭＰＬＳを用いて行なう場合、図７に示すように、上記ＬＳＰを用いて、発信元（source）ＭＰＬＳルータ１１Ｓと着信先（destination ）ＭＰＬＳルータ１１Ｄの間に複数の伝送経路〔パス（path）すなわちＬＳＰ；本実施形態ではパス（path）とＬＳＰとは同義で使用する〕１２−ｉ（ｉ＝１〜Ｎ：Ｎは自然数）を設定する。この場合、ＬＳＰはＭＰＬＳのラベルを用いて設定する。ＬＳＰの設定にはRSVP- ＬＳＰ-Tunne1 のようなＬＳＰ設定プロトコルを用いる。なお、図７において、１１Ｒは中継ＭＰＬＳルータを示す。
【００３７】
また、伝送経路のルータ間の部分をリンクといい、例えば図７において伝送経路１２−１はＭ個のリンク（ｌｉｎｋ１〜ｌｉｎｋＭ）で構成されている。
この図７に示すＭＰＬＳのネットワーク構成も、発信元ＭＰＬＳルータ１１Ｓと、着信先ＭＰＬＳルータ１１Ｄと、発信元ＭＰＬＳルータ１１Ｓと着信先ＭＰＬＳルータ１１Ｄとの間に設定可能な複数の伝送経路１２−ｉ（ｉ＝１〜Ｎ：Ｎは自然数）と、上記伝送経路１２−ｉのいずれかに介装される中継ＭＰＬＳルータ１１ＲとをそなえたＩＰネットワークであることがわかる。なお、この実施形態においても、発信元ＭＰＬＳルータ１１Ｓ，着信先ＭＰＬＳルータ１１Ｄ，中継ＭＰＬＳルータ１１Ｒを特に区別しないで表記する場合は、単にＭＰＬＳルータ１１という。
【００３８】
図８にＩＰネットワークを構成するＭＰＬＳルータの機能ブロック図を示すが、この図８に示すように、ＭＰＬＳルータ１１は、ＩＰパケット転送部１１１，ルーティングプロトコル部１１２，パス選択部１１３，ＬＳＰ選択部１１４， ＬＳＰ設定部１１５及びトラヒックエンジニアリング部１１６をそなえて構成されている。
【００３９】
ここで、ＩＰパケット転送部１１１は入力パケットにＩＰパケット転送処理等の所望の処理を施して他のルータへパケットを転送する機能を有し、ルーティングプロトコル部１１２は他のルータへのトラヒック特性の通知又は他のルータからのトラヒック特性の収集を仲介するものである。なお、このルーティングプロトコル部１１２は、ＭＰＬＳルータがネットワークに接続されると、ルーティングプロトコルを動作させて、ネットワークに接続されている他のＭＰＬＳルータの発見を行なう機能も有している。この発見には一般的にハロー（Hello ）パケットが用いられる。
【００４０】
パス選択部１１３は、ルーティングプロトコルにより、ネットワークのトポロジーが判明すると、パス選択のために、リンク状態データベース(Link State Database) １１３Ａを作成する機能を有している。このリンク状態データベース１１３Ａは、ＬＳＰ選択部１１４を経てＬＳＰ設定部１１５により他ＭＰＬＳルータとの間でＬＳＰを設定する。
【００４１】
ＬＳＰ選択部１１４は、パス選択部１１３のリンク状態データベース１１３Ａと連携し、ＬＳＰ選択のために、代替経路情報データベース１１４Ａを作成する機能を有している。このとき、従来のルーティングプロトコルに無い、ＭＰＬＳ独自のルーティングテーブルが作成される。そして、この代替経路情報データベース１１４Ａは、トラヒックエンジニアリング部１１６と連携し、必要に応じて代替経路をＬＳＰを用いて設定するようになっている。つまり、終点のＭＰＬＳルータとの間に複数のＬＳＰを設定することにより、そのＬＳＰ間で負荷のバランスを行なうようにするためである。
【００４２】
ＬＳＰ設定部１１５は、ＬＳＰ選択部１１４でのＬＳＰ選択結果に応じて終点のＭＰＬＳルータとの間に複数のＬＳＰを設定する機能を有するもので、このＬＳＰ設定部１１５でのＬＳＰ設定結果がＩＰパケット転送部１１１へ伝達され、ＩＰパケット転送部１１１でＩＰパケットの転送態様が設定されるようになっている。
【００４３】
トラヒックエンジニアリング部１１６は、本発明にかかる負荷バランスに関する一連の機能を有するもので、図９に示すように、負荷観測部１１６Ａ，トラヒック特性値計算部１１６Ｂ，トラヒックエンジニアリング計算部１１６Ｃ，負荷調整部１１６Ｄをそなえて構成されている。
負荷観測部１１６Ａは、パケット転送部１１１から送られてくる使用率やパケット損失数といったトラヒック特性値をトラヒック特性値計算部１１６Ｂへ送る機能を有するもので、トラヒック特性値計算部１１６Ｂは、トラヒック特性値のスムージング化や最大値化を行なって、他のＭＰＬＳルータへ送信したり、他ＭＰＬＳルータより送られてきたトラヒック特性値を収集して、トラヒックエンジニアリング計算部１１６Ｃへと送る機能を有する。
【００４４】
トラヒックエンジニアリング計算部１１６Ｃは、実効的な負荷（Effective Load）や実効帯域（Effective Bandwidth ）等の計算を行ない、各ＬＳＰの帯域に応じた負荷の調整を行なう機能を有するもので、トラヒックエンジニアリング計算部１１６Ｃで得られた計算（演算）結果は、負荷調整部１１６Ｄへと送信されるようになっている。
【００４５】
負荷調整部１１６Ｄは、トラヒックエンジニアリング計算部１１６Ｃからの情報に基づいて、トラヒックシェアー（Traffic Share ）の幅を決めて、その結果をＬＳＰ選択部１１４を介してＬＳＰ設定部１１５へ送る機能を有するもので、ＬＳＰ設定部１１５では、その後、トラヒックシェアー幅をＩＰパケット転送部１１１で設定するようになっている。
【００４６】
すなわち、トラヒックエンジニアリング部１１６は、自ＭＰＬＳルータ又は他のＭＰＬＳルータに接続されたＬＳＰ（伝送経路）のトラヒック特性を収集するトラヒック特性収集部と、このトラヒック特性収集部で収集されたトラヒック特性を他のＭＰＬＳルータに通知するトラヒック特性通知部と、トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、この負荷演算部で求められた負荷情報に基づいてＬＳＰを追加するか削除するかの判定を行なう判定部と、負荷演算部で求められた負荷を複数のＬＳＰｉ（ｉは自然数）間で均等化する負荷均等化部との各機能をそなえていることになり、このトラヒックエンジニアリング部１１６が本発明の伝送経路制御装置の主要部をなすことになる。
【００４７】
なお、負荷観測部１１６Ａやトラヒック特性値計算部１１６Ｂがトラヒック特性収集部の機能を、トラヒック特性値計算部１１６Ｂが，トラヒック特性通知部の機能を、トラヒックエンジニアリング計算部１１６Ｃが負荷演算部，判定部，負荷均等化部の機能を主として発揮する。
また、上記のトラヒック特性収集部，トラヒック特性通知部，負荷演算部，判定部及び負荷均等化部の機能をＭＰＬＳルータに持たせるために、通常は上記のトラヒック特性収集部として機能させるためのトラヒック特性収集手段（このトラヒック特性収集手段はこのＭＰＬＳルータ又は他のＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集する機能を有する）と、トラヒック特性通知部として機能させるためのトラヒック特性通知手段（このトラヒック特性通知手段は、トラヒック特性収集手段で収集されたトラヒック特性を他のＭＰＬＳルータに通知する機能を有する）と、負荷演算部として機能させるための負荷演算部手段（この負荷演算部手段はトラヒック特性収集手段で収集されたトラヒック特性に基づいて負荷を演算する機能を有する）と、判定部として機能させるための判定手段（この判定手段は負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう機能を有する）と、負荷均等化部として機能させるための負荷均等化手段（この負荷均等化手段は負荷演算手段で求められた負荷を複数の伝送経路間で均等化する機能を有する）として、ルータを機能させるための伝送経路制御プログラムを記録した媒体から、各ＭＰＬＳルータに上記の伝送経路制御プログラムをインストールすることが行なわれる。
【００４８】
このインストールは、ルータ若しくはルータに接続のコンピュータにフロッピーディスクやＭＯディスク等の記録媒体をセットして行なうほか、ＩＰネットワークを通じて配信された伝送経路制御プログラムを使用して行なってもよい。
なお、実際のＩＰネットワークは、ＭＰＬＳルータをノードとして蜘蛛の巣状に構成されているので、いずれのＭＰＬＳルータも、発信元ＭＰＬＳルータ，着信先ＭＰＬＳルータ，中継ＭＰＬＳルータと成りうるので、本実施形態では、図７に示す発信元ＭＰＬＳルータ１１Ｓ，着信先ＭＰＬＳルータ１１Ｄ，中継ＭＰＬＳルータ１１Ｒのそれぞれのトラヒックエンジニアリング部１１６に、上記のようなトラヒック特性収集部，トラヒック特性通知部，負荷演算部，判定部及び負荷均等化部の機能を全て有する例を示しているが、発信元ＭＰＬＳルータ１１Ｓのトラヒックエンジニアリング部に、トラヒック特性収集部，トラヒック特性受信部，負荷演算部，判定部及び負荷均等化部の機能を持たせ、発信元ＭＰＬＳルータ１１Ｓ以外の着信先ＭＰＬＳルータ１１Ｄ，中継ＭＰＬＳルータ１１Ｒのそれぞれに設けられるトラヒックエンジニアリング部に、トラヒック特性収集部，トラヒック特性通知部の機能だけを持たせることは原理上可能である。
【００４９】
以下、トラヒックエンジニアリング部１１６で行なわれる負荷分散アルゴリズムについて詳述する。
（２−３）各ＭＰＬＳルータ１１で行なわれる負荷分散アルゴリズムについてまず、時間 t1 [ 秒(sec)]毎にトラヒック特性値としての所要のトラヒック項目〔出カポートからの出力パケット量，出カポートでの廃棄パケット数(NLOSS) ，出カポートの論理帯域(LBW) など〕について、ポート毎にトラヒック収集を行なう（手順Ｓ１）。
【００５０】
次に、得られたトラヒック特性値から現在の伝送路使用率CUTYを次式（１）に基づいて算出する（手順Ｓ２）。
CUTY＝出カポートからの出力パケット量／出カポートの論理帯域・・（１）
これにより、トラヒック特性収集部が、収集したトラヒック特性値を基に、上記ルータに接続された各伝送経路の使用率を判定する手段を有していることになる。その結果、各伝送経路の使用状態を詳細に把握することが可能となる。
【００５１】
このとき、得られたトラヒック特性値に関する情報（伝送路使用率CUTY）の加工処理も行なう。
その処理態様は以下のとおりである。
▲１▼平滑化( スムージング) 処理を行なう。かかる平滑化処理は、観測値を得る毎に次式（２）を計算することにより、値MUTYを得ることにより行なう。
【００５２】
MUTY ＝α×CUTY＋ (1 −α) × MUTY ・・（２）
ここで、αは平滑化( スムージング) 係数である。
これにより、トラヒック特性収集部が、収集したトラヒック特性値に関する情報を平滑化する手段を有していることになり、更に具体的には、ＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集した後、その統計値をExponential Moving Average法によって平滑化する手段を有していることになる。その結果、急激なトラヒック変動による影響を少なくできる。
【００５３】
また、上記の様に、得られたトラヒック特性値から求めた現在の伝送路使用率CUTYに対して平滑化を行なうことにより、平滑化手段が、使用率判定手段により判定された使用率を平滑化するように構成されていることになる。これにより、トラヒック変動による影響を排して各伝送経路の使用状態を正確に把握することができる。
【００５４】
▲２▼最大値抽出処理を行なう。かかる最大値抽出処理は、観測値の最大値を算出することにより行なう。すなわち、観測値の最大値を加工値MUTYと置くのである。これを式で表現すれば、下式（３）の通りである。
MUTY＝ max( 観測値) ・・（３）
これにより、トラヒック特性収集部が、収集したトラヒック特性値の最大値をトラヒック特性値の代表値とする手段を有していることになる。その結果、伝送経路選択制御を確実に行なうことができる。
【００５５】
なお、上記の平滑化処理，最大値抽出処理については、平滑化処理及び最大値抽出処理の両処理を施してもよいし、平滑化処理及び最大値抽出処理のうちの一方のみを施してもよい。
▲３▼パケット廃棄数の合計TLOSS を次式（４）に従って算出する。
TLOSS(n)＝ TLOSS(n-1) ＋ NLOSS ・・（４）
ここで、TLOSS(n)は更新後のパケット廃棄数の合計，TLOSS(n-1) は更新前のパケット廃棄数の合計， NLOSSは新たに生じたパケット廃棄数である。
【００５６】
その後は、ルーティングプロトコルのフラッディング（flooding）を利用して、時間t2[sec] 毎に、上記のトラヒック特性値（MUTYやTLOSS など）の配布を行なう。
なお、flooding完了毎にTLOSS はリセット（即ち0 に）する。
また、MUTYとして最大値を採用した場合も、MUTYはリセット（即ち0 に）する。
【００５７】
これにより、トラヒック特性通知部が、トラヒック特性に関する情報をルーティングプロトコルが装備するパケットを利用して通知する手段を有していることになるが、更に具体的には、ＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集した後、その特性値をOSPFやIBGPなどのルーティングプロトコルが装備するパケットを利用して配布し、他のＭＰＬＳルータに情報を伝達する手段を有していることになる。その結果、既存のプロトコルを活用でき、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【００５８】
また、トラヒック特性通知部が、トラヒック特性に関する情報を一定周期t2[sec] 毎に通知する手段を有していることにもなる。その結果、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
そして、この実施形態では、トラヒック特性通知部が、トラヒック特性に関する情報をRSVPのメッセージを拡張して通知する手段を有していることになり、更に具体的には、ＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集した後、その特性値をRSVPのメッセージを拡張して配布し、他のＭＰＬＳルータに情報を伝達する手段をそなえていることになる。その結果、既存のプロトコルを活用することができ、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【００５９】
また、トラヒック特性収集部が、トラヒック特性を収集するフローの束の単位を、ＭＰＬＳで使用するラベル単位で収集する手段を有していることになる。その結果、細かいトラヒック特性の収集が可能になり、収集精度の向上に寄与する。
なお、収集したトラヒック特性値に対して、上記の平滑化処理，最大値抽出処理，パケット廃棄数合計算出処理のうちいずれか若しくは全ての処理を行なってから、現在の伝送路使用率の算出を行なうように構成しても、同様の効果を得ることができる。
一方、伝送路使用率の算出処理を負荷分散の起点となるＭＰＬＳルータ１１Ｓに委ねることにより、中継ＭＰＬＳルータおよび着信先ルータを、伝送路使用率の算出処理以外の各処理（平滑化処理，最大値抽出処理，パケット廃棄数合計算出処理，トラヒック特性値の通知処理）のみを行なうように構成することも可能である。
【００６０】
このように構成した中継ＭＰＬＳルータ１１Ｒ’および着信先ルータ１１Ｄ’（以下、これらのルータを総称して１１’で表す）のトラヒックエンジニアリング部１１６’で行なわれる負荷分散アルゴリズムを、以下に詳述する。
まず、上述したトラヒックエンジニアリング部１１６と同様に、本ＭＰＬＳルータ１１’のトラヒックエンジニアリング部１１６’も、時間 t1 [ 秒(sec)]毎にトラヒック特性値としての所要のトラヒック項目〔出カポートからの出力パケット量(L) ，出カポートでの廃棄パケット数(NLOSS) ，出カポートの論理帯域(LBW) など〕について、ポート毎にトラヒック収集を行なう。
【００６１】
続いて、得られた出力パケット量の平滑化( スムージング) 処理を行なう。かかる平滑化処理は、観測値を得る毎に次式（５）を計算することにより、値ＭＬを得ることにより行なう。
ML＝α×Ｌ＋ (1 −α) × ML' ・・（５）
ここで、αは平滑化( スムージング) 係数、ML' は前回算出されたMLである。
【００６２】
次に、最大化抽出処理を行なう。これは、上述したトラヒックエンジニアリング部１１６と同様に、観測値の最大値を加工値ＭＬと置くことにより行なわれる。なお、この最大化抽出処理については、省略することも可能である。
さらに、上述したトラヒックエンジニアリング部１１６と同様に、パケット廃棄数の合計TLOSS を、（４）式に従って算出する。
【００６３】
その後は、ルーティングプロトコルのFloodingを利用して、時間t2[sec] 毎に、上記のトラヒック特性値（MLやTLOSS など） の配布を行なう。
なお、flooding完了毎に、TLOSS をリセット（即ち0 に） する点、MLとして最大値を採用した場合にはMLもリセット（即ち0 に） する点も、上述したトラヒックエンジニアリング部１１６と同様である。
【００６４】
これにより、本変形例のＭＰＬＳルータ１１’も、上述のＭＰＬＳルータ１１と同様に、平滑化処理，最大値抽出処理，パケット廃棄数合計算出処理，トラヒック特性値の通知処理の各々に伴う効果を得ることができる上に、トラヒック特性に関する情報の平滑化処理を負荷分散の起点となるＭＰＬＳルータ１１Ｓに委ねているので、上述のＭＰＬＳルータ１１よりもトラヒック特性の加工に要する時間が短くて済むとともに、構成を簡素なものとすることができ、コストの低減に寄与する。
【００６５】
（２−４）負荷分散の起点となるＭＰＬＳルータ１１Ｓで行なわれる負荷分散アルゴリズムについて
まず、負荷分散の起点となるＭＰＬＳルータ１１Ｓで通知を受ける flooding 情報は、前記したように、平均リンク使用率（又は観測値の最大値） MUTY （又は平均出力パケット量ML），廃棄パケット数 TLOSS，出カポート論理帯域 LBWなどである。
【００６６】
ここで、このＭＰＬＳルータ１１Ｓが平均出力パケット量MLを受信する場合には、併せて受信する出力ポート論理帯域LBW 等を使用して、各ルータのリンク使用率MUTYを算出することになる。他の中継ルータが平均リンク使用率算出機能を有し、算出した平均リンク使用率MUTYを通知する場合には、このＭＰＬＳルータ１１Ｓ側にはリンク使用率算出機能を設ける必要はない。
【００６７】
そして、この負荷分散の起点となるＭＰＬＳルータ１１Ｓでは、パス状態チェック，実効負荷（ Effective Load ）の算出，負荷調整（ Load Adjusting ）が行なわれる。
パス状態チェックについては、一定周期t3[sec] 毎に発信元ＭＰＬＳルータ（起点ルータ）１１Ｓから着信先ルータ（終点ルータ）１１Ｄまでの各ルートの輻輳状態チェックを以下の要領で実施する。
【００６８】
負荷分散制御の起点となるＭＰＬＳルータ１１Ｓにおいて、このＭＰＬＳルータ１１Ｓには負荷分散制御を終点とするＭＰＬＳルータ１１Ｄ間に複数のパスが張られていて、各パスは複数の中継ＭＰＬＳルータ１１Ｒを経由していることを前提にして、各ルートの輻輳状態チェックは、各パスの使用率を、各中継ＭＰＬＳルータ１１Ｒから収集したものであって、その中継ＭＰＬＳルータ１１Ｒに接続されている伝送経路( リンク) の平均使用率を基に判定する[ この輻輳状態チェック態様をパスi （path i) における各リンクj(1ink j) の平均を取る場合の輻輳状態チェック態様という] 。
【００６９】
これを数式で示すと下式（６）のようになる。
ρpath i＝Average (MUTY(link j, path i) ・・（６）
これにより、この場合は、発信元ＭＰＬＳルータ１１Ｓに設けられるトラヒック特性収集部が、発信元ＭＰＬＳルータに接続された各伝送経路の使用率を、中継ＭＰＬＳルータから収集した中継ＭＰＬＳルータに接続されている伝送経路の平均使用率を基に判定する手段を有していることになる。その結果、ネットワークの使用効率の向上に寄与しうる。
【００７０】
さらに、上記のpath iにおける各 1ink の平均を取る場合の輻輳状態チェック態様と同様の前提で、各ルートの輻輳状態チェックを、各パスの使用率を、各中継ＭＰＬＳルータから収集したものであって、その中継ＭＰＬＳルータに接続されている伝送経路( リンク) の最大使用率を基に判定するような輻輳状態チェックも考えられる（このような輻輳状態チェック態様を path i における全ての 1ink の最大を取る場合の輻輳状態チェック態様という）。
【００７１】
これを数式で示すと下式（７）のようになる。
path i＝ Max(MUTY(1ink j, path i) ・・（７）
これにより、この場合は、発信元ＭＰＬＳルータに設けられるトラヒック特性収集部が、発信元ＭＰＬＳルータに接続された各伝送経路の使用率を、中継ＭＰＬＳルータから収集した中継ＭＰＬＳルータに接続されている伝送経路の最大使用率を基に判定する手段を有していることになる。その結果、伝送経路選択制御を確実に行なうことができる。
なお、path iにおけるパケット廃棄数の合計TLOSS path i は次式（８）で求める。
【００７２】
TLOSS path i ＝ΣTLOSS link j ・・（８）
なお、上記でi はpath（ＬＳＰ）の番号、j は1ink番号である。
そして、発信元ＭＰＬＳルータに設けられるトラヒック特性収集部は、各伝送経路が輻輳しているかどうかを一定周期t3[sec] 毎に判定する手段を有していることにもなる。このようにすることにより、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
【００７３】
実効負荷（ Effective Load ）ρeffective path iの算出については以下の要領で行なわれる。
ここで、実効負荷は、リンクの使用率とこのリンクでのパケット損失数とから計算される、実効的な使用率であると定義される。本来ならば、当該リンクにかかる実際の負荷を計測すればよいが、実際ルータ内部は多段スイッチ構成になっており、直接的に負荷を計測することは困難である。従って、本実施形態では、リンクの使用率とパケット損失数のみを用いて負荷を推定するもので、この推定負荷を実効負荷と言っている。
【００７４】
図１０を用いて、実効負荷を説明する。実効負荷の意味は次のとおりである。即ち、図１０の特性を見れば明らかなように、もしパケット損失が無ければ、リンクでの負荷ρpath iと実効負荷とは一致するが、パケット損失が発生すれば、高めに負荷を計算するように、所定の関数f(TLOSS path i)で修正をかけてこれを実効負荷としている。なお、実効負荷には、上限ρceiling を設けている。これを式で表現すると、下式（９），（１０）のようになる。
【００７５】
ρeffective path i＝ρpath i×f(TLOSS path i) ・・（９）
ρeffective path i＝Min(ρeffective path i, ρcei1ing)・・（１０）
ここで、f(TLOSS path i) はTLOSS path iに関する関数であり、ρceiling は上限負荷、即ち実効負荷ρeffective path iの上限値である。
この機能は、発信元ＭＰＬＳルータに設けられる負荷演算部中の、中継ＭＰＬＳルータにおいて発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段が発揮する。これにより、負荷分散制御の起点となるＭＰＬＳルータにおいて、当該ＭＰＬＳルータには負荷分散制御を終点とするＭＰＬＳルータ間に複数のパスが張られていて、各パスは複数の中継ＭＰＬＳルータを経由している状況下で、通知されたトラヒック特性を基に負荷を計算する場合に、各中継ＭＰＬＳルータにおいて発生したパケット廃棄数TLOSS path iを考慮して、実効的な負荷ρeffective path iを、
i番目のパスの実効的な負荷＝i 番目のパスの負荷×f(パケット廃棄数)
で計算することができるようになっている。なお、f(パケット廃棄数) はパケット廃棄数を変数とする関数である。
【００７６】
その結果、直接的に負荷を計測しなくても、簡素な手法で、実効的な負荷を推定できる。
また、上記の実効的負荷演算手段が、実効的な負荷を演算する際に、実効的な負荷の上限値を設定するように構成されていることになる。これにより、過剰な量の負荷推定を避けることができ、その結果、適切な伝送経路選択制御を行なえる。
【００７７】
負荷調整については以下の要領で行なわれる。
負荷調整は、時間t4[sec] 毎に実施するが、上記のように各パス(LSP) の実効負荷(effective load)を算出できれば、次に全パス(LSP) での使用率を求めることになる。本実施形態では、全パスを一つの仮想的なパイプとみなし、そのパイプの負荷を算出する。
【００７８】
すなわち、この場合、発信元ＭＰＬＳルータに設けられる判定部が、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率を求める手段を有していることになるが、この場合の使用率は次式（１１）で求められる。
全パスを一つの仮想的なパイプとみなしたときの使用率ρeffective all ＝Σ(ρeffective path i×LBW path i)／ΣLBW path i ・・（１１）
ここで、ρeffective path iはパスi の実効負荷、LBW path i はパスi の論理帯域である。
【００７９】
これにより、不必要に新しい伝送経路を追加することを防止できるほか、ネットワークの有効利用にも寄与しうる。
次に、マルチパスの有効性を検証する。
すなわち、式（１１）で得られた使用率と設定された経路追加用基準値ρoffer1とを比較し、得られた使用率の値が経路追加用基準値を超えていた場合に、新伝送経路を追加するとともに、同じく式（１１）で得られた使用率と設定された経路削除用基準値とを比較し、得られた使用率の値が経路削除用基準値ρoffer2を下回っていた場合に負荷が少ないパスを削除するのである。即ち、上記で算出された負荷が多ければ新パスを追加し、少なければ既存パスを削除するのである。
【００８０】
これを論理表現すれば、以下のようになる。
If ρeffective a11 ≧ ρoffer1 then
if timer1 was expired then（左の部分は、「タイマーが既にexpireされていたならば」の意味である。）
search new path and add new path (左の部分は、「代替経路探索処理へ」の意味である。)
endif
elseif ρeffective all ＜ ρoffer2 then
if timer2 was expired then（左の部分は、「タイマーが既に expire されていたならば」の意味である。）
delete path (左の部分は、「代替経路削除処理へ」の意味である。)
endif
endif
これにより、発信元ＭＰＬＳルータに設けられる判定部が、パイプ使用率演算手段で得られたパイプ使用率と設定された基準値とを比較し、比較結果に応じて、伝送経路を追加するか削除するかの判定を行なう手段を有していることになり、パイプ使用率演算手段で得られたパイプ使用率が経路追加用基準値を超えていた場合に、新伝送経路を追加したり、パイプ使用率演算手段で得られたパイプ使用率が経路削除用基準値を下回っていた場合に、負荷が少ない伝送経路を削除したりするようになっている。その結果、アップツーデートに最適な経路選択を実施できる。
【００８１】
なお、上述したマルチパスの有効性の検証手順の変形例として、式（１１）で得られたパイプ使用率（全パス合計の使用率）に加え、パイプ使用率の時間当たりの変化率を算出し、このパイプ使用率の変化量に基づき、伝送経路の追加・削除の判定を行なってもよい。この場合の手順について以下に詳述する。
まず、パイプ使用率の時間当たりの変化率として、微小間隔t4を挟んで得られた２つのパイプ使用率の差分値ΔU(t)を、以下の式（１２）により算出する。
【００８２】
△U(t)＝[ρeffective all(t-1)−ρeffective all(t)]／t4・・（１２）
ここで、ρeffective all(t)は時間tにおける全パス合計の使用率であり、ρeffective all(t-1)は時間tの１つ前の計測時間t-1における全パス合計の使用率である。
なお、式（１１）で得られたパイプ使用率の経時的変化を時間関数として表した上で、ある時点におけるパイプ使用率の微分値を算出し、これをパイプ使用率の時間当たりの変化率としてもよい。これにより、パイプ使用率のより正確な変化率を把握することができる。
【００８３】
次に、式（１１）で得られた使用率と設定された経路追加用基準値ρoffer1とを比較するとともに、式（１２）で得られた変化率と設定された経路追加用基準値ρofferd1とを比較し、得られた使用率及び変化率の値がともに対応する経路追加用基準値を超えていた場合に、新伝送経路を追加する。また、式（１１）で得られた使用率と設定された経路削除用基準値ρoffer2とを比較するとともに、式（１２）で得られた変化率と設定された経路削除用基準値ρofferd2とを比較し、得られた使用率又は変化率の値が対応する経路削除用基準値を下回っていた場合に、負荷が少ないパスを削除する。即ち、この場合も、上記で算出された負荷が多ければ新パスを追加し、少なければ既存パスを削除することになる。
【００８４】
これを論理表現すれば、以下のようになる。
If （ρeffective a11≧ρoffer1 or △U(t)≧ρofferd1） then
if timer1 was expired then（左の部分は、「タイマーが既に expire されていたならば」の意味である。）
search new path and add new path (左の部分は、「代替経路探索処理へ」の意味である。)
endif
elseif(ρeffective all＜ρoffer2 and △U(t)＜ρofferd2) then
if timer2 was expired then（左の部分は、「タイマーが既に expire されていたならば」の意味である。）
delete path (左の部分は、「代替経路削除処理へ」の意味である。)
endif
endif
以上の構成により、パイプ使用率の経時的変化を考慮しながらパスの追加・削除の判定がなされるため、パイプ使用率のみに基づく場合よりも効果的にパスの追加・削除を行なうことができる。
【００８５】
なお、上述の構成では、パスの追加の判定には各比較結果の論理積（and）、パスの削除の判定には各比較結果の論理和（or）を用いているが、パスの追加・削除の判定基準はこの組み合わせに限定されるものではなく、ネットワークの構成や状態に応じて、これらの判定基準（論理積，論理和）を別の組み合わせで用いてもよいし、他の判定基準を用いても構わない。これにより、ネットワークの構成や状態に応じて適切にパイプ使用率の積算量を把握することができる。
【００８６】
また、上述の変化率のみを基準値と比較してパスの追加・削除の判定を行なってもよい。これにより、簡素な構成でパスの追加・削除の判定を行なうことができる。
一方、マルチパスの有効性検証手順の別の変形例として、式（１０）で得られたパイプ使用率（全パス合計の使用率）に加え、パイプ使用率の一定時間における積分量を算出し、これらのパイプ使用率の変化量に基づき、伝送経路の追加・削除の判定を行なってもよい。
【００８７】
この場合、まず、パイプ使用率の一定時間における積算量として、パイプ使用率の一定時間t4における積分値∫MU(t)を、以下の式（１３）により算出する。
【００８８】
【数１】
【００８９】
すなわち、∫MU(t)は、一定時間t〜t＋t4におけるパイプ使用率MUの積分値ということになる。
なお、パイプ使用率が一定時間内にある基準値を超えた回数を算出し、これをパイプ使用率の一定時間における積算量としてもよい。これにより、簡素な構成でパイプ使用率の積算量を把握することができる。
【００９０】
次に、式（１１）で得られた使用率と設定された経路追加用基準値ρoffer1とを比較するとともに、式（１３）で得られた積算量と設定された経路追加用基準値ρofferi1とを比較し、これらの比較結果に基づき新伝送経路を追加する。また、式（１１）で得られた使用率と設定された経路削除用基準値ρoffer2とを比較するとともに、式（１３）で得られた積算量と設定された経路削除用基準値ρofferi2とを比較し、これらの比較結果に基づき負荷が少ないパスを削除する。
【００９１】
この場合も、パスの追加・削除の判定に際しては、ネットワークの構成や状態に応じて、各比較結果の論理和，論理積など、様々な判定基準を任意の組み合わせで用いることにより、適切にパイプ使用率の積算量を把握することができる。また、使用率を用いずに積算量のみに基づいて判定を行なうことにより、簡素な構成でパスの追加・削除の判定を行なうことができる。
【００９２】
以上の構成により、発信元ルータに設けられる判定部が、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報（パイプ使用率，パイプ使用率の変化率，パイプ使用率の積算量）を求める演算手段を有するとともに、この使用率（パイプ使用率，パイプ使用率の変化率，パイプ使用率の積算量の少なくともいずれか一つ）に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成されていることになる。これにより、現在の伝送経路の負荷を考慮して適切に伝送経路の追加及び削除を行なうことが可能となり、効率的に負荷の分散を図ることができるともに、ネットワークの環境やハードウェアの性能に応じて適切な経路選択が可能となる。
【００９３】
また、同じく以上の構成により、発信元ルータに設けられる判定部が、演算手段で得られたパイプ使用率と第１の基準値（ρoffer1，ρoffer2）、演算手段で得られた変化率と第２の基準値（ρofferd1，ρofferd2）、演算手段で得られた積算量と第３の基準値（ρofferi1，ρofferi2）のうちの少なくともいずれか一組の比較を行ない、この比較結果に応じて、伝送経路を追加するか削除するかの判定を行なうように構成されていることになる。より詳しくは、この使用率，変化率及び積算量のうちの少なくともいずれか一つが対応する経路追加用基準値を超えていた場合に、新たな伝送経路を追加する旨の判定をするとともに、少なくともいずれか一つが対応する経路削除用基準値を下回っていた場合に、負荷が少ない伝送経路を削除する旨の判定をすることになる。これにより、ネットワークの環境やハードウェアの性能に応じて、アップツーデートに最適な経路選択を実施できる。
【００９４】
ところで、上述したマルチパスの有効性の検証の際に、伝送経路を削除する旨の判定がされた場合には、幾つかの条件に基づいて削除候補となるパスを選択し、この削除候補となるパスを削除した場合における全パスの使用率（他の伝送経路の負荷）を予測してこれを所定の基準値と比較し、この比較結果に基づいて実際に削除するパスを決定する。
【００９５】
具体的には、以下のアルゴリズムに従ってマルチパスの削除が行なわれる。
▲１▼ 全パスのうち最初に張られたパスは削除の対象外とする。
▲２▼ 全パスのうち使用可能帯域が最小のパスを選択する。
▲３▼ ▲２▼の条件を満たすパス（使用可能帯域が最小のパス）が複数ある場合は、その中で実行負荷が最低のパスを選択する。
▲４▼ ▲２▼▲３▼の条件を満たすパス（使用可能帯域が最小且つ実行負荷が最低のパス）が複数ある場合は、ホップ数が最大のパスを選択する。
▲５▼ ▲２▼▲３▼▲４▼の条件を満たすパス（使用可能帯域が最小，実行負荷が最低，ホップ数が最大のパス）が複数ある場合は、最後に追加されたパスを選択する。
▲６▼ ▲１▼−▲５▼で選択されたパスを削除候補として、このパスを仮想的に削除した場合におけるマルチパス全体の使用率を算出する。
▲７▼ ▲６▼で算出した削除候補パスの削除後におけるマルチパス全体の使用率を、設定した輻輳判定閾値と比較する。削除後のマルチパス全体の使用率がこの閾値以上の場合には、この削除候補パス以外のパスを対象として、再び▲１▼−▲５▼で新たな削除候補パスを選択する。
▲８▼ ▲７▼の比較により、削除後のマルチパス全体の使用率が輻輳判定閾値を下回っていた場合には、その削除候補パスを実際に削除する。
【００９６】
以上のようなアルゴリズムに従ってパスの削除を行なうことにより、発信元ルータに設けられる判定部が、負荷演算部で求められた負荷情報に基づいて削除対象となる伝送経路の候補を選択する手段と、この削除候補選択手段により選択された削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、この負荷予測手段により予測された他の伝送経路の負荷を所定の基準値とを比較した結果に応じてこの削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成されることになる。これにより、各伝送経路を削除した場合の影響を考慮して、削除する伝送経路を適切に選択することが可能となる。
【００９７】
なお、先述したパイプ使用率（全パス合計の使用率）に関する情報（使用率，変化率，積算量）と基準値との比較結果が、伝送経路を削除する旨の判定に繋がるものである場合（例えば、パイプ使用率に関する情報のいずれかが対応する基準値を下回った場合）には、この比較結果をトリガとして上述のパス削除アルゴリズムが実行され、実際のパスの削除が行なわれる。
【００９８】
こうした構成によって、発信元ルータに設けられる判定部が、演算手段で得られたパイプ使用率に関する情報に基づき、上記の選択手段，予測手段及び決定手段の動作トリガをかけるトリガ手段をさらにそなえて構成されていることになる。これにより、ネットワーク全体の状況に応じてアップツーデートに伝送経路を削除できる。
【００９９】
このようにして、マルチパスの有効性を検証した後は、移動する実効的な帯域[Effective Bandwidth (EBW)] を算出する。
即ち、追加された複数の伝送経路間で負荷を均等化する場合、パスの論理帯域に比例して負荷を配分するために、実効帯域(Effective Bandwidth) を式（１４）により計算して、負荷分散を行なう。
【０１００】
その結果、各パス間で負荷のバランシングを行なうことができるが、図１１に実効帯域を説明するための概念図を示す。この図１１において、△EBW i は移動すべき実効帯域を示しており、この実効帯域は 実効負荷に論理帯域LBW を乗算して得られる。結果的に、△EBW は式（１５）を使用して計算できる。
△EBW path i ＝( ρeffective a11 −ρeffective path i）×LBW path i・・（１５）
これにより、発信元ＭＰＬＳルータに設けられる負荷均等化部が、中継ＭＰＬＳルータにおいて発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有していることになる。これによって、伝送経路の帯域を考慮に入れた負荷の均等化を実施できる。
【０１０１】
そして、上記のようにして実効帯域△EBW が求まると、最後に、トラヒックシェアの調整を行なう。
すなわち、式（１４）で計算された移動すべき実効帯域に比例して、流入するＩＰパケットを複数のパスに振り分けるのであるが、この流入するＩＰパケットを複数のパスに振り分ける場合に、ＩＰアドレスを基にハッシュ関数による演算を行ない、この演算結果を基にしてランダムにＩＰトラヒックフローを振り分けるのである。ここでハッシュ関数とは、ある入力値から所定範囲内のランダムな整数値を作成して出力する関数である。
【０１０２】
具体的に、ハッシュ関数としてCRC (cyc1ic redundancy check) 演算を用いた場合について、以下に詳述する。
ここで、Grは負荷調整係数(1/ρceiling ≦Gr≦1/100)、TSはCRC 演算の計算結果の幅(CRC16の場合、TSの幅はO-65535)である。
【０１０３】
Gr : 負荷調整係数
TS : traffic share の幅 ＝ CRC16 の結果の範囲＝65535
上記の式により、負荷調整を行なった場合、負荷調整前と負荷調整後との間の負荷調整分布は図１２のようになる。
この実施形態で、負荷調整の意義を有するトラヒックシェアとは、負荷分散を行なうために用いるパラメ−タで、トラヒックシェアの合計が全パスを通過する実際のトラヒックの合計値となる。トラヒックシェアの幅はCRC (cyc1ic redundancy check）16を用いた場合、前述のごとく、O から65535 までの整数となる。ＩＰパケットがルータに到着したとき、負荷調整装置では、そのＩＰパケットのＩＰアドレス（ホストアドレス，宛先アドレス）を基にCRC 演算を行なうことができ、その結果、O から65535 の間のある値がそのＩＰフローに割り当てられる。つまり本負荷調整機構は、ＩＰアドレスをある整数の幅に縮退させる機能を持つ。言い換えれば、ルータに到着したＩＰフローはランダムに各パスに収容されることとなる。
【０１０４】
これにより、発信元ＭＰＬＳルータに設けられる負荷均等化部が、移動実効帯域演算手段で求められた移動すべき実効帯域に比例して、発信元ＭＰＬＳルータに流入するパケットを複数の伝送経路に振り分ける手段を有し、更にこのとき、アドレスを基にハッシュ関数を用いた演算を行ない、この演算結果に基づいて、ランダムにトラヒックフローを振り分けるように構成されていることになる。その結果、簡素な計算によって、的確にトラヒックフローを振り分けることができる。
【０１０５】
なお、より簡素で高速なハッシュ関数として、入力値の各ビット値に対して位置の入れ替え及び論理演算を行なうことにより、ランダムな整数値を作成してもよい。
例えば、図１３に示すように、まずIPパケットに含まれる32bitの宛先IPアドレスを、8bitずつ4つのエリアに分割する。次に、隣接した２つの8bitの数値を交互に入れ替えた上で、上位16bitと下位16bitの排他的論理和を求める。最後に、こうして作成された16bitの数値を整数に変換し、これをハッシュ値（ハッシュ関数の出力値）とする。
【０１０６】
なお、入力値の各ビット値に対する位置の入れ替え及び論理演算は、これに限定されるものではなく、様々な手法を任意の組み合わせで用いることができる。
以上から、発信元ルータに設けられる負荷均等化部が、ハッシュ関数による演算として、入力値の各ビット値に対して位置の入れ替え及び論理演算の少なくとも一方を行なうことにより、ランダムな整数値を作成するように構成されていることになる。これによって、ハッシュ演算を簡略化することができ、トラヒックフローの振り分けを高速に行なうことができる。
【０１０７】
なお、上述したハッシュ演算の効率を向上させるために、ハッシュ関数の入力値として、パケットに含まれるアドレス（ホストアドレス，宛先アドレス）に併せて、パケットに含まれるアドレス以外の制御値（例えばプロトコルID，ポート番号など）などを用いてもよい。すなわち、発信元ルータに設けられる負荷均等化部を、ハッシュ関数の入力値として、パケットに含まれるアドレス以外の制御値を併せて用いるように構成するのである。これにより、ハッシュ演算による出力値の攪乱度が増し、効率的且つ効果的なトラヒックフローの振り分けを行なうことができる。
【０１０８】
以下に本アルゴリズムの負荷分散例を示す。
（Ａ）計算例１
パス１，２，３の各論理帯域LBW[bit/s]をそれぞれ１０Ｍ，８Ｍ，２Ｍとし、実効負荷ρeffective をそれぞれ0.5 ，0.2 ，0.3 とすると、パス１，２，３の実トラヒック[bit/s] は、それぞれ10M × 0.5＝ 5M ，8M× 0.2＝ 1.6M,2M× 0.3＝ 0.6M となる。
【０１０９】
さらに、この場合の全パスを仮想的な一つのパイプとみなし、平均的な使用率ρave effective を求めると、以下のようになる。
ρave effective ＝ (5M＋ 1.6M ＋ 0.6M) / (10M ＋ 8M ＋ 2M)＝ 0.36
そして、移動する実効帯域(EBW) [bit/s] をパス１，２，３のそれぞれについて算出すると、以下のようになる。
【０１１０】
すなわち、パス１の移動する実効帯域△EBW PATH1 は (0.36− 0.5) × 10M＝−1.4 M となり、パス２の移動する実効帯域△EBW PATH2 は (0.36− 0.2) ×8M＝＋1.28M となり、パス３の移動する実効帯域△EBW PATH3 は (0.36− 0.3) ×2M＝＋0.12M となる。そして、各パスの移動する実効帯域の総和を計算すると、−1.4M＋ 1.28M＋ 0.12M＝ 0 となる。
【０１１１】
この計算結果を基に、トラヒックシェアの調整を行なう。
すなわち、パス１については、 5 M− 1.4 M＝ 3.6 M、パス２については、 1.6 M＋ 1.28M＝ 2.88M、パス３については、 0.6 M＋ 0.12M＝ 0.72Mとなり、パス１，２，３について、 3.6× Gr : 2.88× Gr : 1.2 × Gr の比でトラヒックシェアを変更すればよい。
（Ｂ）計算例２
パス１，２，３，４の各論理帯域LBW[bit/s]をそれぞれ150M, 45M, 150M, 600Mとし、パス１，２，３，４の実効負荷ρeffective をそれぞれ1.2, 1.5, 1.1, 0.8とすると、パス１，２，３，４の実トラヒック[bit/s] は、それぞれ150M× 1.2＝180M ， 45M× 1.5＝67.5M ，150M× 1.1＝ 165M ，600M× 0.8＝ 480M となる。
【０１１２】
また、全パスを仮想的な一つのパイプとみなし、平均的な使用率ρave effective を求めると、次のようになる。
ρave effective ＝ (180M＋ 67.5M＋ 165M ＋ 480M) / (150M＋ 45M＋ 150M ＋ 600M)＝ 892.5/945＝ 0.94
そして、各パス１〜４について、移動する実効帯域 (EBW)を算出すると次のようになる。
【０１１３】
すなわち、パス１の移動する実効帯域△EBW PATH1 は(O.94 −1.2)×150M＝−39M となり、パス２の移動する実効帯域△EBW PATH2 は(0.94 −1.5)× 45M＝−25.2M となり、パス３の移動する実効帯域△EBW PATH3 は(O.94 −1.1)×150M＝−24M となり、パス４の移動する実効帯域△EBW PATH4 は(0.94 −O.8)×600M＝84M となる。
【０１１４】
この計算結果を基に、トラヒックシェアの調整を行なう。
すなわち、パス１については、 180M − 39 M＝141 Mとなり、パス２については、67.5M − 25.2M＝ 42.3Mとなり、パス３については、 165M − 24 M＝141 Mとなり、パス４については、 480M ＋ 84 M＝564 Mとなる。従って、パス１，２，３，４について、 141× Gr : 42.3× Gr : 141 × Gr : 564 × Gr の比でトラヒックシェアを変更すればよい。
【０１１５】
（２−５）作用説明
このような構成により、まず、ＭＰＬＳルータ１１がネットワークに接続されると、ルーティングプロトコルが動作し、ネットワークに接続されている他のＭＰＬＳルータの発見を行なう。かかる発見には一般的にハローパケットが用いられる。ルーティングプロトコルにより、ネットワークのトポロジーが判明すると、パス選択部１１３においてリンク状態データベース１１３Ａが作成される。リンク状態データベース１１３Ａを用いて、ＬＳＰ選択部１１４を経てＬＳＰ設定部１１５により他ＭＰＬＳルータとの間でＬＳＰが設定される。さらに、パス選択部１１３のリンク状態データベース１１３Ａと連携し、ＬＳＰ選択部１１４では代替経路情報データベース１１４Ａが作成され、従来のルーティングプロトコルに無い、ＭＰＬＳ独自のルーティングテーブルが作成される。代替経路情報データベース１１４Ａは、トラヒックエンジニアリング部１１６と連携し、必要に応じて代替経路をＬＳＰを用いて設定する。つまり、終点のＭＰＬＳルータとの間に複数のＬＳＰを設定することにより、そのＬＳＰ間で負荷のバランスを行なうことができるのである。
【０１１６】
なお、負荷のバランスに関する一連の機能はトラヒックエンジニアリング部１１６の機能であるが、かかるトラヒックエンジニアリング部１１６においては、パケット転送部１１１から、使用率やパケット損失数といったトラヒック特性値が負荷観測部１１６Ａへ送られてくる。負荷観測部１１６Ａはそれらの値をトラヒック特性値計算部１１６Ｂへと送る。トラヒック特性値計算部１１６Ｂでは、トラヒック特性値のスムージング化や最大値化を行ない、他ＭＰＬＳルータへと送信する。また他ＭＰＬＳルータより送られてきたトラヒック特性値はトラヒック特性値計算部１１６Ｂで収集され、トラヒックエンジニアリング計算部１１６Ｃへと送られる。トラヒックエンジニアリング計算部１１６Ｃでは、実効負荷や実効帯域の計算が行なわれ、各ＬＳＰの帯域に応じた負荷の調整がなされる。
【０１１７】
その結果は、負荷調整部１１６Ｄへと送信され、トラヒックシェアの幅が決められる。そして、その結果はＬＳＰ設定部１１５を経て、ＩＰパケット転送部１１１で設定される。
このように、発信元ルータ１１Ｓ以外の他のルータ１１Ｒ，１１Ｄにおいて、他のルータに接続された伝送経路のトラヒック特性を収集するとともに、収集されたトラヒック特性を発信元ルータに通知する一方、発信元ルータ１１Ｓにおいては、この発信元ルータに接続された伝送経路のトラヒック特性を収集しながら、収集されたトラヒック特性及び他のルータから得られたトラヒック特性の一方又は両方に基づいて実効負荷を演算し、実効負荷情報に基づいて伝送経路を追加するか削除するかの判定を行ない、更に得られた実効負荷を複数の伝送経路間で均等化することが行なわれるので、各ルータにおいてトラヒック特性の観測機能およびその特性値の通知機能を持たせて、負荷分散の起点となるルータ（発信元ルータ）において、終点となるルータ( 着信先ルータ) までの複数のパスの帯域管理をダイナミックに行なうことができ、その結果、空き帯域に合わせた負荷分散が可能となる。すなわち、ＩＰネットワーク内のルータにおいて、起点となるルータ( 発信元ルータ) から終点となるルータ( 着信先ルータ) までに複数のルート( 伝送経路) を設定し、設定されたルート間で負荷の分散を行なえるので、ネットワークトポロジーに関係なく、また伝送経路の種類によらないで、インターネット等のネットワーク内でトラヒックエンジニアリングを可能にできるのである。
（２−６）実験例
図１４に示す実験用ネットワーク構成を用いて、本発明の負荷分散装置による負荷分散性能の評価を行なった。なお、図１４において、１２０Ｒ−１〜１２０Ｒ−５は本発明の負荷分散装置を備えたＬＳＲで、発信元ＬＳＲであるＬＳＲ１２０Ｒ−１には負荷発生装置１２１が、負荷着信先ＬＳＲであるＬＳＲ１２０Ｒ−５には負荷受信装置１２２が、それぞれ接続されている。また、ＬＳＲ１２０Ｒ−１〜１２０Ｒ−５の間には、複数のリンクｌｉｎｋ１〜ｌｉｎｋ５が張られており、これによって複数の伝送経路１２３−１，１２３−２が形成されている。すなわち、この図１４に示す実験用ネットワーク構成も、図７に示したＭＰＬＳのネットワーク構成の一例として考えることができる。
【０１１８】
各ＬＳＲ１２０Ｒ−１〜１２０Ｒ−５による経路検索機能の動作を確認するために、この図１４に示す実験用ネットワーク構成を用いて負荷分散を行ない、発信元ＬＳＲ１２０Ｒ−１に接続されたリンクｌｉｎｋ１，ｌｉｎｋ３（それぞれ複数の伝送経路１２３−１，１２３−２の入り口に相当する）について、トラヒック移動量とトラヒックの収束時間との関係を、本発明の負荷分散装置による負荷分散性能として評価した。その評価結果を図１５及び図１６に示す。
【０１１９】
図１５では、入力トラヒック（input traffic） 50 Mbit/sec (93 flows)，OSPF によるflooding インターバル（OSPF flooding interval） 10 sec，輻輳判定閾値（congestion threshold） 30 Mbit/sec，ハッシュ粒状度（Hash granularity） 100 ％という条件で負荷分散を行ない、10秒毎に算出したリンクｌｉｎｋ１およびｌｉｎｋ３におけるリンク使用率の時間的変化をグラフに示している。
【０１２０】
実験開始直後はｌｉｎｋ１のリンク使用率（グラフ中の白抜きの丸）が50 Mbit/sec 弱で、輻輳判定閾値である 30 Mbit/sec を超えており、輻輳が生じている。一方、ｌｉｎｋ３のリンク使用率（白抜きの三角）はほぼ0 Mbit/sec であり、これらの２つのリンクｌｉｎｋ１，ｌｉｎｋ３の間に負荷の偏りが生じているのが分かる。
【０１２１】
実験開始40秒後から本発明の負荷分散装置による負荷分散を開始したところ、ｌｉｎｋ１のリンク使用率が急速に減少するとともに、ｌｉｎｋ３のリンク使用率が急速に増加しており、これら２つのリンクｌｉｎｋ１，ｌｉｎｋ３の間で負荷の分散が計られているのが分かる。その後、負荷分散開始20秒後（実験開始70秒後）には２つのリンクｌｉｎｋ１，ｌｉｎｋ３のトラヒックが逆転し、いったんは過制御の状態になるものの、振動を繰り返す間にその差は非常に小さくなり、次第に２つのリンクｌｉｎｋ１，ｌｉｎｋ３のトラヒックの差が収束していった。トラヒックの収束時間（convergence time）は負荷分散開始から120秒であった。
【０１２２】
一方、図１６においては、ハッシュ粒状度（Hash granularity） を20 ％に変更した以外は、図１５と同じ条件で実験を行なった。その結果、トラヒックの収束時間（convergence time）は負荷分散開始から200秒と、図１５に示した結果よりも長くなったものの、トラヒックが逆転して過制御に陥ることはなく、２つのリンクｌｉｎｋ１，ｌｉｎｋ３のトラヒックの差は漸近的に収束しており、安定した状態で負荷の分散が図られたことが分かる。
【０１２３】
すなわち、ハッシュ粒状度（Hash granularity）を高めに設定すれば、過制御によってトラヒックが不安定化するものの、短時間で負荷分散を図ることができる。これに対して、ハッシュ粒状度（Hash granularity）を低めに設定すれば、負荷分散に要する時間は長くなるものの、過制御によるトラヒックの不安定化を防ぎながら、安定した状態で負荷分散を図ることができる。すなわち、ネットワークの状態やハードウェアの性能に合わせて適切にハッシュ粒状度（Hash granularity）を設定することにより、効率的な負荷分散が可能となる。
【０１２４】
（２−７）その他
なお、上記の実施形態では、ＭＰＬＳ (Multi-Protoco1 Label Switching)を用い、ＭＰＬＳのラベル機能を用いて、ルーテイングプロトコルとは異なるルートを設定し、負荷分散を行なうものについて説明したが、その他、 ATM (Asynchronous Transfer Mode) や FR (Frame Relay) などを用い、レイヤ２独自のプロトコルを用いて、レイヤ３( ＩＰ) とは異なるルートを設定し、負荷分散を行なったり、ＩＰでのソースルーティングを用いて、ルーティングプロトコルの経路とは異なるルートを設定し、負荷分散を行なったりする手法を用いても、本発明を適用できることはいうまでもない。
また、上記の実施形態では、通信装置の一例としてルータを用い、これに本発明を適用した場合について説明したが、本発明はこれに限定されるものではなく、他の通信装置（例えば、ゲートウェイなど）に適用することも可能である。
【０１２５】
また、本発明は、上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。
（２−８）付記
［付記１] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記通信装置に設けられる装置であって、
該通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集されたトラヒック特性を他の通信装置に通知するトラヒック特性通知部と、
該トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、
該負荷演算部で求められた負荷情報に基づいて、伝送経路を追加するか削除するかの判定を行なう判定部と、
該負荷演算部で求められた負荷を複数の伝送経路間で均等化する負荷均等化部とをそなえて構成されたことを特徴とする、伝送経路制御装置。
【０１２６】
［付記２] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置に設けられる装置であって、
該発信元通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、
該負荷演算部で求められた負荷情報に基づいて、伝送経路の追加・削除判定を行なう判定部と、
該負荷演算部で求められた負荷を複数の伝送経路間で均等化する負荷均等化部とをそなえて構成されたことを特徴とする、伝送経路制御装置。
【０１２７】
［付記３] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置以外の通信装置に設けられる装置であって、
該通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知部とをそなえて構成されたことを特徴とする、伝送経路制御装置。
【０１２８】
［付記４] 該トラヒック特性収集部が、収集したトラヒック特性に関する情報を平滑化する手段を有していることを特徴とする、付記１〜３のいずれか一項に記載の伝送経路制御装置。
［付記５] 該トラヒック特性収集部が、収集したトラヒック特性値を基に、該通信装置に接続された各伝送経路の使用率を判定する手段を有していることを特徴とする、付記４記載の伝送経路制御装置。
【０１２９】
［付記６] 該トラヒック特性収集部における該平滑化手段が、該使用率判定手段により判定された該使用率を平滑化するように構成されていることを特徴とする、付記５記載の伝送経路制御装置。
［付記７] 該トラヒック特性収集部における該平滑化手段が、収集したトラヒック特性値を平滑化するように構成されるとともに、
該トラヒック特性収集部が、該平滑化手段により平滑化されたトラヒック特性値を基に、該通信装置に接続された各伝送経路の使用率を判定する手段を有していることを特徴とする、付記４記載の伝送経路制御装置。
【０１３０】
［付記８] 該トラヒック特性収集部が、収集したトラヒック特性値の最大値をトラヒック特性値の代表値とする手段を有していることを特徴とする、付記１〜３のいずれか一項に記載の伝送経路制御装置。
［付記９] 該トラヒック特性通知部が、トラヒック特性に関する情報をルーティングプロトコルが装備するパケットを利用して通知する手段を有していることを特徴とする、付記１又は付記３に記載の伝送経路制御装置。
【０１３１】
［付記１０] 該トラヒック特性通知部が、トラヒック特性に関する情報を一定周期毎に通知する手段を有していることを特徴とする、付記１，３，９のいずれか一項に記載の伝送経路制御装置。
［付記１１] 該トラヒック特性通知部が、トラヒック特性に関する情報をRSVPのメッセージを拡張して通知する手段を有していることを特徴とする、付記１又は付記３に記載の伝送経路制御装置。
【０１３２】
［付記１２] 該トラヒック特性収集部が、トラヒック特性を収集するフローの束の単位を、ラベルスイッチ型通信装置で使用するラベル単位で収集する手段を有していることを特徴とする、付記１〜３のいずれか一項に記載の伝送経路制御装置。
［付記１３] 該発信元通信装置に設けられる該トラヒック特性収集部が、該発信元通信装置に接続された各伝送経路の使用率を、該中継通信装置から収集した該中継通信装置に接続されている伝送経路の使用率に関する情報を基に判定する手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３３】
［付記１４] 該発信元通信装置に設けられる該トラヒック特性収集部が、該発信元通信装置に接続された各伝送経路の使用率を、該中継通信装置から収集した該中継通信装置に接続されている伝送経路の平均使用率及び最大使用率の少なくとも一方を基に判定するように構成されていることを特徴とする、付記１３記載の伝送経路制御装置。
【０１３４】
［付記１５] 該発信元通信装置に設けられる該トラヒック特性収集部が、各伝送経路が輻輳しているかどうかを一定周期毎に判定する手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
［付記１６] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３５】
［付記１７] 該実効的負荷演算手段が、該実効的な負荷を演算する際に、該実効的な負荷の上限値を設定するように構成されていることを特徴とする、付記１６記載の伝送経路制御装置。
［付記１８] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有するとともに、
該発信元通信装置に設けられる該判定部が、該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率を求める手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３６】
［付記１９] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、
該発信元通信装置に設けられる該判定部が、
該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段を有するとともに、
該演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３７】
［付記２０] 該判定部における該演算手段が、該パイプ使用率，該パイプ使用率の時間当たりの変化率，該パイプ使用率の一定時間における積算量のうちの少なくとも一つを求めるように構成されるとともに、
該伝送経路追加・削除判定手段が、該演算手段で得られた上記のパイプ使用率，変化率及び積算量のうちの少なくとも一つに基づいて、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、付記１９記載の伝送経路制御装置。
【０１３８】
［付記２１] 該発信元通信装置に設けられる該判定部が、該演算手段で得られたパイプ使用率と第１の基準値、該演算手段で得られた変化率と第２の基準値、該演算手段で得られた該積算量と第３の基準値のうちの少なくともいずれか一組の比較を行ない、この比較結果に応じて、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、付記２０記載の伝送経路制御装置。
【０１３９】
［付記２２] 該発信元通信装置に設けられる該判定部が、該演算手段で得られた上記のパイプ使用率，変化率及び積算量のうちの少なくともいずれか一つが対応する経路追加用基準値を超えていた場合に、新たな伝送経路を追加する旨の判定をするように構成されていることを特徴とする、付記２１記載の伝送経路制御装置。
【０１４０】
［付記２３] 該発信元通信装置に設けられる該判定部が、該演算手段で得られた上記のパイプ使用率，変化率及び積算量のうちの少なくともいずれか一つが対応する経路削除用基準値を下回っていた場合に、負荷が少ない伝送経路を削除する旨の判定をするように構成されていることを特徴とする、付記２１記載の伝送経路制御装置。
【０１４１】
［付記２４] 該演算手段が、微小間隔をおいて得られた２つのパイプ使用率の差分値、及び、ある時点における該パイプ使用率の微分値の少なくともいずれか一方を、該パイプ使用率の時間当たりの該変化率として求めるように構成されていることを特徴とする、付記１９〜２３のいずれか一項に記載の伝送経路制御装置。
【０１４２】
［付記２５] 該演算手段が、該パイプ使用率が一定時間内にある基準値を超えた回数、及び、該パイプ使用率の一定時間における積分値の少なくともいずれか一方を、該パイプ使用率の一定時間における該積算量として求めるように構成されていることを特徴とする、付記１９〜２３のいずれか一項に記載の伝送経路制御装置。
【０１４３】
［付記２６] 該発信元通信装置に設けられる該判定部が、
該負荷演算部で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、
該削除候補選択手段により選択された該削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、
該負荷予測手段により予測された他の伝送経路の負荷を所定の基準値と比較し、該比較結果に応じて、該削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成されていることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１４４】
［付記２７] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、
該発信元通信装置に設けられる該判定部が、
該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段と、
該演算手段で得られたパイプ使用率に関する情報に基づき、上記の選択手段，予測手段及び決定手段の動作トリガをかけるトリガ手段とをさらにそなえて構成されていることを特徴とする、付記２６記載の伝送経路制御装置。
【０１４５】
［付記２８] 該発信元通信装置に設けられる該負荷均等化部が、該中継通信装置において発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１４６】
［付記２９] 該発信元通信装置に設けられる該負荷均等化部が、該移動実効帯域演算手段で求められた移動すべき実効帯域に比例して、該発信元通信装置に流入するパケットを複数の伝送経路に振り分ける手段を有していることを特徴とする、付記２８記載の伝送経路制御装置。
［付記３０] 該発信元通信装置に設けられる該負荷均等化部が、各パケットに含まれるアドレスを基にハッシュ関数を用いた演算を行ない、この演算結果に基づいて、ランダムにトラヒックフローを振り分けるように構成されていることを特徴とする、付記２９記載の伝送経路制御装置。
【０１４７】
［付記３１] 該発信元通信装置に設けられる該負荷均等化部が、該ハッシュ関数としてＣＲＣ（cyclic redundancy check）を用いた演算を行なうことを特徴とする、付記３０記載の伝送経路制御装置。
［付記３２] 該発信元通信装置に設けられる該負荷均等化部が、該ハッシュ関数による演算として、入力値の各ビット値に対して位置の入れ替え及び論理演算の少なくとも一方を行なうことにより、ランダムな整数値を作成することを特徴とする、付記３０記載の伝送経路制御装置。
【０１４８】
［付記３３] 該発信元通信装置に設けられる該負荷均等化部が、該ハッシュ関数の入力値として、パケットに含まれるアドレス以外の制御値を併せて用いることを特徴とする、付記３０記載の伝送経路制御装置。
［付記３４] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置以外の他の通信装置において、
該他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
該トラヒック特性収集ステップで収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知ステップとをそなえるとともに、
上記発信元通信装置において、
該発信元通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
該トラヒック特性収集ステップで収集されたトラヒック特性及び該他の通信装置から得られたトラヒック特性の一方又は両方に基づいて負荷を演算する負荷演算ステップと、
該負荷演算ステップで求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定ステップと、
該負荷演算ステップで求められた負荷を複数の伝送経路間で均等化する負荷均等化ステップとをそなえて構成されたことを特徴とする、伝送経路制御方法。
【０１４９】
［付記３５] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記通信装置で使用すべく、
該通信装置又と他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集手段と、
該トラヒック特性収集手段で収集された該トラヒック特性を他の通信装置に通知するトラヒック特性通知手段と、
該トラヒック特性収集手段で収集された該トラヒック特性に基づいて負荷を演算する負荷演算手段と、
該負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定手段と、
該負荷演算手段で求められた負荷を複数の伝送経路間で均等化する負荷均等化手段として、上記通信装置を機能させるための伝送経路制御プログラムを記録した媒体。
【０１５０】
【発明の効果】
以上詳述したように、本発明によれば、各通信装置においてトラヒック特性の観測機能およびその特性値の通知機能を持たせて、負荷分散の起点となる通信装置（発信元通信装置）において、終点となる通信装置（着信先通信装置)までの複数のパスの帯域管理をダイナミックに行なうことができ、その結果、空き帯域に合わせた負荷分散が可能となる。すなわち、ＩＰネットワーク内の通信装置において、起点となる通信装置（発信元通信装置) から終点となる通信装置（着信先通信装置)までに複数のルート（伝送経路)を設定し、設定されたルート間で負荷の分散を行なえるので、ネットワークトポロジーに関係なく、また伝送経路の種類によらないで、インターネット等のネットワーク内でトラヒックエンジニアリングを可能にできるのである。
【０１５１】
また、トラヒック特性収集部に、収集したトラヒック特性に関する情報を平滑化する手段を設けることができ、このようにすれば、急激なトラヒック変動による 影響を少なくすることができる。
さらに、トラヒック特性収集部に、収集したトラヒック特性値を基に、通信装置に接続された各伝送経路の使用率を判定する手段を設けることができ、このようにすれば、各伝送経路の使用状態を詳細に把握することが可能となる。この場合、平滑化手段が、使用率判定手段により判定された使用率を平滑化するように構成すれば、トラヒック変動による影響を排して各伝送経路の使用状態を正確に把握することができる。また、トラヒック特性収集部に、平滑化手段により平滑化されたトラヒック特性値を基に、通信装置に接続された各伝送経路の使用率を判定する手段を設けても、同様の効果を得ることができる。
【０１５２】
更に、トラヒック特性収集部に、収集したトラヒック特性値の最大値をトラヒック特性値の代表値とする手段を設ければ、伝送経路選択制御を確実に行なうことができる。
また、トラヒック特性通知部に、トラヒック特性に関する情報をルーティングプロトコルが装備するパケットを利用して通知する手段を設けることもでき、このようにすれば、既存のプロトコルを活用でき、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【０１５３】
さらに、トラヒック特性通知部に、トラヒック特性に関する情報を一定周期毎に通知する手段を設けることができ、このようにすれば、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
また、トラヒック特性通知部に、トラヒック特性に関する情報をRSVPのメッセージを拡張して通知する手段を設けることができ、このようにすれば、既存のプロトコルを活用でき、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【０１５４】
さらに、トラヒック特性収集部に、トラヒック特性を収集するフローの束の単位を、ラベルスイッチ型通信装置で使用するラベル単位で収集する手段を設けることができ、このようにすれば、きめ細かくトラヒック特性を収集することが可能になり、収集精度の向上に寄与する。
また、発信元通信装置に設けられるトラヒック特性収集部に、伝送経路の使用率を伝送経路の平均使用率を基に判定する手段を設けることができ、このようにすれば、ネットワークの使用効率の向上に寄与しうる。
【０１５５】
さらに、発信元通信装置に設けられるトラヒック特性収集部に、伝送経路の使用率を伝送経路の最大使用率を基に判定する手段を設けることができ、このようにすれば、伝送経路選択制御を確実に行なうことができる。
また、発信元通信装置に設けられるトラヒック特性収集部に、各伝送経路が輻輳しているかどうかを一定周期毎に判定する手段を設けることができ、このようにすれば、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
【０１５６】
さらに、発信元通信装置に設けられる負荷演算部に、中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を設けることができ、このようにすれば、直接的に負荷を計測しなくても、簡素な手法で、実効的な負荷を推定できる。その際、実効的な負荷の上限値を設定することもでき、このようにすれば、過剰な量の負荷推定を避けることができ、これにより適切な伝送経路選択制御を行なえる。
【０１５７】
また、発信元通信装置に設けられる判定部に、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率を求める手段を設けることもでき、このようにすれば、不必要に新しい伝送経路を追加することを防止できるほか、ネットワークの有効利用にも寄与しうる。
【０１５８】
さらに、演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成することができ、このようにすれば、現在の伝送経路の負荷を考慮して適切に伝送経路の追加及び削除を行なうことが可能となり、効率的に負荷の分散を図ることができる。この場合、伝送経路追加・削除判定手段が、演算手段で得られたパイプ使用率，変化率及び積算量のうちの少なくとも一つに基づいて、伝送経路を追加するか削除するかの判定を行なうように構成することにより、ネットワークの環境やハードウェアの性能に応じて適切な経路選択が可能となる。
【０１５９】
また、演算手段で得られたこれらのパイプ使用率，変化率及び積算量を基準値と比較し、この比較結果に応じて伝送経路を追加するか削除するかの判定を行なうように構成することができ、このようにすれば、アップツーデートに最適な経路選択を実施できる。
さらに、演算手段が、上記のパイプ使用率の変化率として、パイプ使用率の差分値や微分値を求めるように構成したり、上記のパイプ使用率の積算量として、パイプ使用率が基準値を超えた回数やパイプ使用率の積分値を求めたりするように構成してもよく、このようにすれば、ネットワークの環境やハードウェアの性能に応じて計算量を変えることができ、効率的な経路選択が可能となる。
【０１６０】
また、判定部が、負荷演算部で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、選択された削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、予測された他の伝送経路の負荷を所定の基準値と比較し、この比較結果に応じて、削除候補の伝送経路を削除するか否かを決定する手段とをそなえてもよく、このようにすれば、各伝送経路を削除した場合の影響を考慮して、削除する伝送経路を適切に選択することが可能となる。この場合、演算手段で得られたパイプ使用率に関する情報を動作トリガとして用いることにより、ネットワーク全体の状況に応じて効率的に伝送経路を削除できる。
【０１６１】
また、発信元通信装置に設けられる負荷均等化部に、中継通信装置において発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を設けることができ、このようにすれば、伝送経路の帯域を考慮に入れた負荷の均等化を実施できる。
【０１６２】
さらに、発信元通信装置に設けられる負荷均等化部に、移動実効帯域演算手段で求められた移動すべき実効帯域に比例して、発信元通信装置に流入するパケットを複数の伝送経路に振り分ける手段を設けることができ、このようにすれば、的確な負荷の均等化を実施できる。
また、発信元通信装置に設けられる負荷均等化部を、アドレスを基にハッシュ関数を用いた演算を行ない、この演算結果に基づいて、ランダムにトラヒックフローを振り分けるように構成することもでき、このようにすれば、簡素な計算によって、的確にトラヒックフローを振り分けることができる。この場合、負荷均等化部がハッシュ関数として、ＣＲＣ（cyclic redundancy check）を用いた演算や、入力値のビット位置の入れ替えによりランダムな整数値を作成する演算を行なうように構成したり、ハッシュ関数の入力値として、パケットに含まれるアドレス以外の制御値を併せて用いるように構成したりすることにより、効率的且つ効果的なトラヒックフローの振り分けを行なうことができる。
【図面の簡単な説明】
【図１】（ａ），（ｂ）は本発明の原理説明図である。
【図２】（ａ），（ｂ）はＭＰＬＳネットワークを説明する図である。
【図３】ＭＰＬＳで用いるラベルを説明する図である。
【図４】ＭＰＬＳで用いるラベルを説明する図である。
【図５】ＬＳＰを説明する図である。
【図６】ＲＳＶＰ−ＬＳＰ−Ｔｕｎｎｅｌのメッセージの流れを説明する図である。
【図７】本発明の一実施形態に適用されるＭＰＬＳネットワークを説明する図である。
【図８】本発明の一実施形態としてのＭＰＬＳルータの機能ブロック図である。
【図９】本発明の一実施形態としてのＭＰＬＳルータのトラヒックエンジニアリング部の詳細を示す機能ブロック図である。
【図１０】実効負荷を説明する図である。
【図１１】移動する実効帯域を説明する図である。
【図１２】負荷調整要領を説明する図である。
【図１３】ハッシュ関数の一例を説明する図である。
【図１４】負荷調整実験ネットワークを説明する図である。
【図１５】負荷調整性能評価結果の一例を説明する図である。
【図１６】負荷調整性能評価結果の他の例を説明する図である。
【符号の説明】
１ 通信装置
１Ｓ 発信元通信装置
１Ｄ 着信先通信装置
１Ｒ 中継通信装置
２−ｉ 伝送経路
３，３Ａ トラヒック特性収集部
３Ｂ トラヒック特性受信部
４ トラヒック特性通知部
５ 負荷演算部
６ 判定部
７ 負荷均等化部
１１，１１’ ＭＰＬＳルータ（通信装置）
１１Ｓ 発信元ＭＰＬＳルータ（発信元通信装置）
１１Ｄ，１１Ｄ’ 着信先ＭＰＬＳルータ（着信先通信装置）
１１Ｒ，１１Ｒ’ 中継ＭＰＬＳルータ（中継通信装置）
１２−ｉ 伝送経路
１１１ ＩＰパケット転送部
１１２ ルーティングプロトコル部
１１３ パス選択部
１１３Ａ リンク状態データベース
１１４ ＬＳＰ選択部
１１４Ａ 代替経路情報データベース１１４Ａ
１１５ ＬＳＰ設定部
１１６ トラヒックエンジニアリング部
１１６Ａ 負荷観測部
１１６Ｂ トラヒック特性値計算部
１１６Ｃ トラヒックエンジニアリング計算部
１１６Ｄ 負荷調整部
１２０Ｒ−１〜１２０Ｒ−５ ＬＳＲ
１２１ 負荷発生装置
１２２ 負荷受信装置
【発明の属する技術分野】
本発明は、インターネットプロトコルネットワーク（以下、インターネットプロトコルをＩＰと略称する場合がある。従って、インターネットプロトコルネットワークはＩＰネットワークと略称される）を構成する通信装置（例えば、ルータ）に設けられる伝送経路制御装置に関し、更には同装置にて実行される伝送経路制御方法並びに同装置で使用される伝送経路制御プログラムを記録した媒体に関する。
【０００２】
【従来の技術】
インターネットは、現在全ての通信アプリケーションをインターネットプロトコル上で扱うことを意図し、急速に普及しつつある。更にインターネットは、元来、コネクションを確立しないコネクションレスなネットワークアーキテクチャを持ち、且つ、ＩＰパケット内に記述されている宛先アドレスを基に、出方路へとルーティングされるようになっている。つまり、かかる機能を持つ通信装置内では、ＩＰパケットが装置に到着した時点で、そのＩＰアドレスに該当する出方路へとＩＰパケットを転送するだけである。
【０００３】
このようなネットワークアーキテクチャを持つインターネットでは、どのＩＰアドレスをどの出方路へ転送するかを決定するために、ルーティングプロトコルと呼ばれる経路決定用のプロトコルが通信装置間で取り扱われている。
現在、ルーティングプロトコル用のアルゴリズムとして、ダイクストラ（Dijkstra）のアルゴリズムを用いた方式が一般的である。しかしながら、かかるルーティングプロトコルでは、着信先までの複数のルートを選択することができなかったり、ネットワークトポロジーが変化したときしか、ルーティングプロトコルが実行されなかったりするという課題がある。
【０００４】
つまり、上記のような技術では、いったんルートが確定してしまうと、そのルートしかＩＰパケットは転送されないことになり、その結果、慢性的な輻輳が発生してしまうおそれがある。
また、上記のような技術では、複数のルートを設定することができないため、あるルートが輻輳していても、別のルートが空いているにもかかわらず、そのルートを使用することができないという課題もある。
【０００５】
そこで、次のような技術が提案されている。
（１−１）OSPF(Open Shortest Path First)における等コストマルチパス(EqualCost Multipath ) 技術
（１−２）IBGP(Internal Border Gateway Protocol)におけるマルチパス(Multipath) 技術
すなわち、（１−１）の技術による手法は、OSPFの機能を用いた手法であり、起点となる通信装置から終点となる通信装置までに、コストが等価なパスを複数本張ることができる機能を用いて、この複数本のパス( マルチパス) 間で負荷の分散を行なうようにしているのである。
【０００６】
また、（１−２）の技術による手法は、IBGPの機能を用いて、パスを複数本張り、この複数本のパス( マルチパス) 間で負荷の分散を行なうようにしているのである。
【０００７】
【発明が解決しようとする課題】
しかしながら、このような上記（１−１）によるOSPFの機能を用いた手法では次のような課題がある。
すなわち、マルチパスはコストが等価でなければならないという制限があり、パス選択の自由度が低く、更にOSPFを使用しているため、リアルタイムでのネットワーク負荷の変動に対処できない。
【０００８】
また、上記（１−２）によるIBGPの機能を用いた手法でも、OSPFの機能を用いた手法での課題と同様、マルチパスはコストが等価でなければならないという制限があり、パス選択の自由度が低いという課題を有する。
なお、ネットワークを相互に接続するデータ処理装置間で、レイヤ３でパスを設定し、レイヤ３でのルート単位で負荷を分散することにより、動的にトラヒック平衡を与えて、ネットワーク性能を改善する技術も提案されているが( 特開平10-224400 号公報参照) 、かかる技術では、ネットワーク間でのトラヒック平衡を与えることはできても、ネットワーク内での負荷分散を行なうことはできず、更にレイヤ３で且つルート単位での負荷分散しか考慮しておらず、負荷分散制御が複雑になるおそれがある。
【０００９】
本発明は、このような課題に鑑み創案されたもので、ネットワーク内の通信装置において、起点となる通信装置（発信元通信装置) から終点となる通信装置（着信先通信装置) までに複数のルート（伝送経路) を設定し、設定されたルート間で負荷の分散を行なえるようにして、ネットワークトポロジーに関係なく、また伝送経路の種類によらないで、インターネット等のネットワーク内でトラヒックエンジニアリングを可能にした、伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体を提供することを目的とする。
【００１０】
【課題を解決するための手段】
図１（ａ），（ｂ）は本発明の原理説明図であるが、まず、本発明にかかる伝送経路制御装置は、図１(a) に示すようなＩＰネットワーク（このＩＰネットワークは、発信元通信装置１Ｓと、着信先通信装置１Ｄと、発信元通信装置１Ｓと着信先通信装置１Ｄとの間に設定可能な複数の伝送経路２−ｉ（ｉ＝１〜Ｎ：Ｎは自然数）と、上記伝送経路２−ｉのいずれかに介装される中継通信装置１Ｒとをそなえている）を構成する通信装置１Ｓ又は１Ｄ又は１Ｒ（以下、発信元通信装置１Ｓ，着信先通信装置１Ｄ，中継通信装置１Ｒを特に区別しないで表記する場合は、単に通信装置１という）に設けられる装置である。
【００１１】
そして、本発明にかかる伝送経路制御装置は、図１（ｂ）に示すように、トラヒック特性収集部３，トラヒック特性通知部４，負荷演算部５，判定部６及び負荷均等化部７をそなえている。
ここで、トラヒック特性収集部３は、通信装置１又は他の通信装置に接続された伝送経路２−ｉのトラヒック特性を収集するものであり、自己の通信装置１でのトラヒック特性を収集するトラヒック特性収集部３Ａと、他の通信装置から通知されるトラヒック特性を受信するトラヒック特性受信部３Ｂとで構成されている。
【００１２】
トラヒック特性通知部４は、トラヒック特性収集部３（特に３Ａ）で収集されたトラヒック特性を他の通信装置に通知するものである。
また、負荷演算部５は、トラヒック特性収集部３で収集されたトラヒック特性に基づいて負荷を演算するものである。
判定部６は、負荷演算部５で求められた負荷情報に基づいて、伝送経路を追加するか削除するかの判定を行なうもので、負荷均等化部７は、負荷演算部５で求められた負荷を前記発信元通信装置１Ｓと前記着信先通信装置１Ｄとの間に設定された複数の伝送経路間で均等化するものである。
【００１３】
なお、発信元通信装置１Ｓ，着信先通信装置１Ｄ，中継通信装置１Ｒのそれぞれに設けられる伝送経路制御装置に、上記のようなトラヒック特性収集部３，トラヒック特性通知部４，負荷演算部５，判定部６及び負荷均等化部７を設けることは勿論可能であるが、発信元通信装置１Ｓに設けられる伝送経路制御装置に、トラヒック特性収集部３，トラヒック特性通知部４，負荷演算部５，判定部６及び負荷均等化部７を設け、発信元通信装置１Ｓ以外の着信先通信装置１Ｄ，中継通信装置１Ｒのそれぞれに設けられる伝送経路制御装置には、トラヒック特性収集部３，トラヒック 特性通知部４だけを設けることは原理上可能である。
【００１４】
なお、トラヒック特性収集部３が、収集したトラヒック特性値を平滑化する手段を有していてもよい。
さらに、発信元通信装置１Ｓに設けられるトラヒック特性収集部３が、発信元通信装置１Ｓに接続された各伝送経路２−ｉの使用率を、中継通信装置１Ｒから収集した中継通信装置１Ｒに接続されている伝送経路２−ｉの使用率に関する情報を基に判定する手段を有していてもよい。
【００１５】
また、発信元通信装置１Ｓに設けられる負荷演算部５が、中継通信装置１Ｒにおいて発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、発信元通信装置１Ｓに設けられる判定部６が、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段を有するとともに、この演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成してもよい。
【００１６】
さらに、発信元通信装置１Ｓに設けられる判定部６が、負荷演算部５で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、この削除候補選択手段により選択された削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、この負荷予測手段により予測された他の伝送経路の負荷を所定の基準値と比較し、この比較結果に応じて、この削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成してもよい。
【００１７】
また、発信元通信装置１Ｓに設けられる負荷均等化部７が、中継通信装置１Ｒにおいて発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有するように構成してもよい。
【００１８】
そして、本発明では、発信元通信装置１Ｓと、着信先通信装置１Ｄと、発信元通信装置１Ｓと着信先通信装置１Ｄとの間に設定可能な複数の伝送経路２−ｉと、伝送経路２−ｉのいずれかに介装される中継通信装置１ＲとをそなえてなるＩＰネットワークを構成する発信元通信装置以外の他の通信装置において、
（Ａ１）他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
（Ａ２）トラヒック特性収集ステップで収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知ステップとが実行されるとともに、上記発信元通信装置１Ｓにおいて、
（Ｂ１）発信元通信装置１Ｓに接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
（Ｂ２）トラヒック特性収集ステップで収集されたトラヒック特性及び他の通信装置から得られたトラヒック特性の一方又は両方に基づいて負荷を演算する負荷演算ステップと、
（Ｂ３）負荷演算ステップで求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定ステップと、
（Ｂ４）負荷演算ステップで求められた負荷を前記発信元通信装置１Ｓと前記着信先通信装置１Ｄとの間に設定された複数の伝送経路間で均等化する負荷均等化ステップとが実行される。
【００１９】
また、上記図１（ａ）に示すＩＰネットワークを構成する１で使用すべく、通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集手段と、トラヒック特性収集手段で収集された該トラヒック特性を他の通信装置に通知するトラヒック特性通知手段と、トラヒック特性収集手段で収集された該トラヒック特性に基づいて負荷を演算する負荷演算手段と、負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定手段と、負荷演算手段で求められた負荷を前記発信元通信装置と前記着信先通信装置との間に設定された複数の伝送経路間で均等化する負荷均等化手段として、上記通信装置を機能させるための伝送経路制御プログラムを記録した媒体も用意されている。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
本発明の実施の形態として、ラベルスイッチ型ルータ（通信装置）としてのＭＰＬＳルータに本伝送経路制御装置を装備して、ＭＰＬＳ(Multi-Protoco1 Label Switching)を用い、ＭＰＬＳのラベル機能を用いて、ルーテイングプロトコルとは異なるルートを設定し、負荷分散を行なう場合について説明する。ここで、ＭＰＬＳとは、レイヤ２のラベルをＩＰに特化して使用することにより、現在のルータでは実現困難なサービスを簡易にかつ効果的に行なうことが可能な方式をいう。
【００２１】
以下においては、ＭＰＬＳの概要を説明した上で、ＭＰＬＳにおける負荷分散手法ないし負荷分散アルゴリズム（作用説明を含む）について説明する。
（２−１）ＭＰＬＳの概要説明
まず、ＭＰＬＳの概要を説明する。図２（ａ），（ｂ）に、ＭＰＬＳのネットワーク構成および基本パケット転送要領を示す。ＭＰＬＳネットワークは、エッジ・ラベル・スイッチング・ルータ（Edge Label Switching Router 、以下、エッジＬＳＲという）１１Ｅやコア・ラベル・スイッチング・ルータ（Core LabelSwitching Router 、以下、コアＬＳＲという）１１Ｃで構成される。これをＭＰＬＳドメインと呼ぶ。
【００２２】
ここで、エッジＬＳＲ１１Ｅは、図２（ａ），（ｂ）に示すように、既存インターネットワークとの境界に位置し、パケットにラベルを付加することによって、高性能、高付加価値のネットワークレイヤサービスを実現するルータであり、このエッジＬＳＲは、ラベル付けされていないフレームベース（Frame Base）のLAN インターフェースを終端するものである。
【００２３】
また、コアＬＳＲ１１Ｃは、ラベルが付加されたパケットやセルをラベル交換するルータであり、このコアＬＳＲ１１Ｃは、ラベル交換ばかりでなく、レイヤ３ルーティングやレイヤ２スイッチングをサポートするように構成することもできる。
また、標準のネットワークレイヤのルーティングプロトコルと連携し、ラベル・スイッチングによるインターネットワーク上のデバイス間でラベル情報を交換しあう際に用いられるプロトコルは、ラベル・ディストリビューション・プロトコル〔 Label Distribution Protoco1 (LDP)〕である。
【００２４】
なお、図２（ａ）の符号９Ｓ，９Ｄはパソコン等の端末を示している。
図２（ａ）に示すようなＭＰＬＳネットワークでは、ＭＰＬＳドメイン内に到着したＩＰパケットに、着信端末へと通じるパスに対応づけられたラベルが、エッジＬＳＲ１１Ｅにより付与される。図２（ｂ）では、ラベルＡが付与され、コアＬＳＲ１１Ｃへと送出される。コアＬＳＲ１１Ｃでは、そのラベルのみを見て、ラベルＡに対応する出力方路へと交換する。交換された出方路にパケットを送出するときには、新たにラベルＢが付与される。これをラベルスワッピングと呼ぶ。このようにＭＰＬＳドメイン内では、ラベルスワッピングを行ないながら、ラベルに従い順次目指す着信端末９Ｄへと転送されていく。ＭＰＬＳドメインの出口のエッジＬＳＲ１１Ｅではラベルは取り除かれ、ＭＰＬＳドメインヘと転送される。
【００２５】
次に、ＭＰＬＳで用いるラベルについて説明する。
まず、ＭＰＬＳを実現するには以下の２つの手法がある。
▲１▼既存スイッチを流用する手法
▲２▼新ラベルを定義する手法
▲１▼による既存スイッチを流用する手法は、非同期転送モード（ATM :Asynchronous Transfer Mode)）やフレームリレー（Frame Relay ，ＦＲとも表記する）といった既存スイッチを用いる手法であり、ATM では仮想パス識別子（VPI ）と仮想チャネル識別子（ VCI）との領域をラベルとして用い、フレームリレーではDLCIをラベルとして用いる。
【００２６】
▲２▼による新ラベルを定義する手法では、シム(Shim)ヘッダと呼ばれる新たに定義されたラベルを用いる。シムヘッダはレイヤ３とレイヤ２との間に挿入されるが、図３にその概要を示す。
シムヘッダには、図３に示すように、ラベルの他、TTL やラベルスタック用のポインタＳが付与されている。ラベルスタックは、ラベルの階層化のために用いられ、このラベルスタックを用いることにより、例えばＭＰＬＳドメイン内で複数のＭＰＬＳドメインを階層化してネットワークを構築することができる。図３では、S ＝1 であると、それが最後のラベルであると認識されるようになっている。
【００２７】
なお、ラベルは、ATM/FR以外に、PPP over S0NET用や、イーサフレーム（ＬＡＮ）用にも定義されている（図３の右側に示されているＰＰＰやＬＡＮを参照）。
また、ラベルは、例えば4 オクテット長で図４のように示される。そして、このラベルは階層構造を持つことが可能であり、その構造をラベル・スタック（Label stack ）と呼ぶ。図４に示すラベルおよびその他の付加情報は、MBLSで定義したＭＰＬＳヘッダに表示されるか、またはL2ヘッダやATM ヘッダにも表示される場合がある。
【００２８】
図４に示す S (Bottom of Stack)は、ラベル・スタックの最下位に位置する最終エントリである場合に、1 にセットされるもので、その他のエントリは全てO にセットされるものである。
また、図４に示す TTL (Time-to-Live) は、TTL をエンコードするために使用されるフィールドを表しており、ラベルドパケット（1abeled packet）がフォワードされる前に1 ずつ減算されるようになっている。減算されて0 になったパケットはそれ以上フォワードしてはならず、この場合、このパケットはそのまま廃棄されるか、ラベル・スタックを取り除かれて、ネットワークレイヤの処理に渡される。そして、ネットワークレイヤの処理に移行した後も決してこのパケットをフォワードしてはならないようになっている。
【００２９】
次に、ラベル・スイッチド・パス(Labe1 Switched Path：ＬＳＰ）について説明する。ＬＳＰとは、図５からもわかるように、入り口のＬＳＲから中間のＬＳＲを経て出口のＬＳＲまでのパスのことをいうが、ＬＳＰに対応づけられて、各ＬＳＲでのラベルが決定されるようになっている。本発明では、後述するが、トラヒック特性の収集を、ＬＳＰごとに行なうようになっている。
【００３０】
さらに、ＬＳＰを確立する手法について説明する。
まず、ＬＳＰを確立する手法として、以下の２方式がIETFで提案されている。
▲１▼LDP(Label Distribution Protoco1)を用いた手法
▲２▼RSVP- トンネル(RSVP-Tunne1) を用いた手法
以下は、▲２▼のRSVP-Tunne1 を用いた手法について説明する。
【００３１】
ＬＳＰ-tunne1 は、従来のRSVPを拡張して実行されるもので、この方式の背景は、ＭＰＬＳがRSVPを搭載している場合、それらを合体させることによりフローをより柔軟に管理可能であるであろうということから来ている。
ＬＳＰ-tunne1 はRSVPに対して以下の5 つの新オブジェクト[ LABEL REQUEST(パスメッセージ(PATH メッセージ) 中で使用するもの)，LABEL(Resvメッセージ中で使用するもの)，EXPLICIT ROUTE(PATHメッセージ中で使用するもの)，RECORD ROUTE(PATHメッセージ，Resvメッセージ中で使用するもの) 及びSESSION ATTRIBUTE(PATHメッセージ中で使用するもの) ] を定義している。
【００３２】
ここで、 LABEL REQUEST オブジェクトは、PATHメッセージ中で使用するものであり、中間ルータと受信ノードで、そのパスに関するラベルを決定するために使用される。パス( ＝ＬＳＰ-tunne1)を確立するために、送信元ＬＳＲはLABEL REQUEST を持つPATHメッセージを生成し、更にLABEL REQUEST を送信したノードは、そのPATHメッセージに対応するResvメッセージを受信する準備をしておかなければならない。もしLABEL REQUEST を含んでいないPATHメッセージを受け取ったならば、それにLABEL REQUEST オブジェクトを書き込んではならないようになっている。
【００３３】
LABEL オブジェクトは、 Resv メッセージ中で使用するものであるが、ＬＳＰ-tunnel では、ラベルはResvメッセージ中に入れて送信元へと返されるようになっている。そして、Resvメッセージは、PATHメッセージの経路に沿って送信元へ向かって返信される。さらに、LABEL オブジェクトを持つResvメッセージを受信した各ノードは、そのラベルをＬＳＰ-tunne1 の出力側のラベルとして使用し、もしそのノードがLABEL REQUEST の送信者でなかったならば、新たなラベルを割り当て、その新ラベルをResvメッセージのLABEL オブジェクトに置くという処理を実行するようになっている。そして、上流に送信したラベルは、そのＬＳＰ-tunne1 の入力側ラベルとして使用される。
【００３４】
EXPLICIT ROUTE オブジェクト(ER0) は、PATHメッセージ中で使用するものであるが、もしこのオブジェクトがPATHメッセージ中に現れたならば、そのPATHメッセージは、ERO によって明記されたパスに沿ってそのメッセージを転送しなければならない。ERO は明示的ルーティングに用いることを意図したものである。
RECORD ROUTE オブジェクトは、PATHメッセージ, Resvメッセージ中で使用するものであるが、これにより送信ノードがＬＳＰ-tunne1 の実際の経路についての情報を受け取ることが可能となる。これはパスベクトル(path vector) と似ていて、ループ検出にも使用できるもののである。
【００３５】
SESSION ATTRIBUTE オブジェクトは、PATHメッセージ中で使用するものであるが、このSESSION ATTRIBUTE オブジェクトは、PATHメッセージに付与されて、セッションの識別と診断に使用できる。更に、このオブジェクトは、プレエミッション(preemption ) , 優先権, ローカルプロテクションなどを持っている。
図６に、RSVPを用いたＬＳＰ-tunnel のメッセージの流れを示す。RSVP-tunnel は、下流からラベルを割り当てていくため、ダウンストリーム・オン・デマンド（Downstream-on-demand）方式である。図６からもわかるように、まず、ＭＰＬＳドメイン内の最初のＭＰＬＳルータ（ＬＳＲ１）が、RSVPのPATHメッセージ中にLABEL REQUEST オブジェクトを入れて下流へと送信する。その後、着信先のノード（ＬＳＲ４）のそのPATHメッセージが到達したならば、着信先ノード（ＬＳＲ４）はResvメッセージ中にLABEL オブジェクトを入れて、その上流へと返す。ラベルの割り当て方は上述した通りである。
【００３６】
本発明では、このRSVPメッセージ中にトラヒック特性値を埋め込んで転送している。
（２−２）ＭＰＬＳにおける負荷分散手法の説明
負荷分散をＭＰＬＳを用いて行なう場合、図７に示すように、上記ＬＳＰを用いて、発信元（source）ＭＰＬＳルータ１１Ｓと着信先（destination ）ＭＰＬＳルータ１１Ｄの間に複数の伝送経路〔パス（path）すなわちＬＳＰ；本実施形態ではパス（path）とＬＳＰとは同義で使用する〕１２−ｉ（ｉ＝１〜Ｎ：Ｎは自然数）を設定する。この場合、ＬＳＰはＭＰＬＳのラベルを用いて設定する。ＬＳＰの設定にはRSVP- ＬＳＰ-Tunne1 のようなＬＳＰ設定プロトコルを用いる。なお、図７において、１１Ｒは中継ＭＰＬＳルータを示す。
【００３７】
また、伝送経路のルータ間の部分をリンクといい、例えば図７において伝送経路１２−１はＭ個のリンク（ｌｉｎｋ１〜ｌｉｎｋＭ）で構成されている。
この図７に示すＭＰＬＳのネットワーク構成も、発信元ＭＰＬＳルータ１１Ｓと、着信先ＭＰＬＳルータ１１Ｄと、発信元ＭＰＬＳルータ１１Ｓと着信先ＭＰＬＳルータ１１Ｄとの間に設定可能な複数の伝送経路１２−ｉ（ｉ＝１〜Ｎ：Ｎは自然数）と、上記伝送経路１２−ｉのいずれかに介装される中継ＭＰＬＳルータ１１ＲとをそなえたＩＰネットワークであることがわかる。なお、この実施形態においても、発信元ＭＰＬＳルータ１１Ｓ，着信先ＭＰＬＳルータ１１Ｄ，中継ＭＰＬＳルータ１１Ｒを特に区別しないで表記する場合は、単にＭＰＬＳルータ１１という。
【００３８】
図８にＩＰネットワークを構成するＭＰＬＳルータの機能ブロック図を示すが、この図８に示すように、ＭＰＬＳルータ１１は、ＩＰパケット転送部１１１，ルーティングプロトコル部１１２，パス選択部１１３，ＬＳＰ選択部１１４， ＬＳＰ設定部１１５及びトラヒックエンジニアリング部１１６をそなえて構成されている。
【００３９】
ここで、ＩＰパケット転送部１１１は入力パケットにＩＰパケット転送処理等の所望の処理を施して他のルータへパケットを転送する機能を有し、ルーティングプロトコル部１１２は他のルータへのトラヒック特性の通知又は他のルータからのトラヒック特性の収集を仲介するものである。なお、このルーティングプロトコル部１１２は、ＭＰＬＳルータがネットワークに接続されると、ルーティングプロトコルを動作させて、ネットワークに接続されている他のＭＰＬＳルータの発見を行なう機能も有している。この発見には一般的にハロー（Hello ）パケットが用いられる。
【００４０】
パス選択部１１３は、ルーティングプロトコルにより、ネットワークのトポロジーが判明すると、パス選択のために、リンク状態データベース(Link State Database) １１３Ａを作成する機能を有している。このリンク状態データベース１１３Ａは、ＬＳＰ選択部１１４を経てＬＳＰ設定部１１５により他ＭＰＬＳルータとの間でＬＳＰを設定する。
【００４１】
ＬＳＰ選択部１１４は、パス選択部１１３のリンク状態データベース１１３Ａと連携し、ＬＳＰ選択のために、代替経路情報データベース１１４Ａを作成する機能を有している。このとき、従来のルーティングプロトコルに無い、ＭＰＬＳ独自のルーティングテーブルが作成される。そして、この代替経路情報データベース１１４Ａは、トラヒックエンジニアリング部１１６と連携し、必要に応じて代替経路をＬＳＰを用いて設定するようになっている。つまり、終点のＭＰＬＳルータとの間に複数のＬＳＰを設定することにより、そのＬＳＰ間で負荷のバランスを行なうようにするためである。
【００４２】
ＬＳＰ設定部１１５は、ＬＳＰ選択部１１４でのＬＳＰ選択結果に応じて終点のＭＰＬＳルータとの間に複数のＬＳＰを設定する機能を有するもので、このＬＳＰ設定部１１５でのＬＳＰ設定結果がＩＰパケット転送部１１１へ伝達され、ＩＰパケット転送部１１１でＩＰパケットの転送態様が設定されるようになっている。
【００４３】
トラヒックエンジニアリング部１１６は、本発明にかかる負荷バランスに関する一連の機能を有するもので、図９に示すように、負荷観測部１１６Ａ，トラヒック特性値計算部１１６Ｂ，トラヒックエンジニアリング計算部１１６Ｃ，負荷調整部１１６Ｄをそなえて構成されている。
負荷観測部１１６Ａは、パケット転送部１１１から送られてくる使用率やパケット損失数といったトラヒック特性値をトラヒック特性値計算部１１６Ｂへ送る機能を有するもので、トラヒック特性値計算部１１６Ｂは、トラヒック特性値のスムージング化や最大値化を行なって、他のＭＰＬＳルータへ送信したり、他ＭＰＬＳルータより送られてきたトラヒック特性値を収集して、トラヒックエンジニアリング計算部１１６Ｃへと送る機能を有する。
【００４４】
トラヒックエンジニアリング計算部１１６Ｃは、実効的な負荷（Effective Load）や実効帯域（Effective Bandwidth ）等の計算を行ない、各ＬＳＰの帯域に応じた負荷の調整を行なう機能を有するもので、トラヒックエンジニアリング計算部１１６Ｃで得られた計算（演算）結果は、負荷調整部１１６Ｄへと送信されるようになっている。
【００４５】
負荷調整部１１６Ｄは、トラヒックエンジニアリング計算部１１６Ｃからの情報に基づいて、トラヒックシェアー（Traffic Share ）の幅を決めて、その結果をＬＳＰ選択部１１４を介してＬＳＰ設定部１１５へ送る機能を有するもので、ＬＳＰ設定部１１５では、その後、トラヒックシェアー幅をＩＰパケット転送部１１１で設定するようになっている。
【００４６】
すなわち、トラヒックエンジニアリング部１１６は、自ＭＰＬＳルータ又は他のＭＰＬＳルータに接続されたＬＳＰ（伝送経路）のトラヒック特性を収集するトラヒック特性収集部と、このトラヒック特性収集部で収集されたトラヒック特性を他のＭＰＬＳルータに通知するトラヒック特性通知部と、トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、この負荷演算部で求められた負荷情報に基づいてＬＳＰを追加するか削除するかの判定を行なう判定部と、負荷演算部で求められた負荷を複数のＬＳＰｉ（ｉは自然数）間で均等化する負荷均等化部との各機能をそなえていることになり、このトラヒックエンジニアリング部１１６が本発明の伝送経路制御装置の主要部をなすことになる。
【００４７】
なお、負荷観測部１１６Ａやトラヒック特性値計算部１１６Ｂがトラヒック特性収集部の機能を、トラヒック特性値計算部１１６Ｂが，トラヒック特性通知部の機能を、トラヒックエンジニアリング計算部１１６Ｃが負荷演算部，判定部，負荷均等化部の機能を主として発揮する。
また、上記のトラヒック特性収集部，トラヒック特性通知部，負荷演算部，判定部及び負荷均等化部の機能をＭＰＬＳルータに持たせるために、通常は上記のトラヒック特性収集部として機能させるためのトラヒック特性収集手段（このトラヒック特性収集手段はこのＭＰＬＳルータ又は他のＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集する機能を有する）と、トラヒック特性通知部として機能させるためのトラヒック特性通知手段（このトラヒック特性通知手段は、トラヒック特性収集手段で収集されたトラヒック特性を他のＭＰＬＳルータに通知する機能を有する）と、負荷演算部として機能させるための負荷演算部手段（この負荷演算部手段はトラヒック特性収集手段で収集されたトラヒック特性に基づいて負荷を演算する機能を有する）と、判定部として機能させるための判定手段（この判定手段は負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう機能を有する）と、負荷均等化部として機能させるための負荷均等化手段（この負荷均等化手段は負荷演算手段で求められた負荷を複数の伝送経路間で均等化する機能を有する）として、ルータを機能させるための伝送経路制御プログラムを記録した媒体から、各ＭＰＬＳルータに上記の伝送経路制御プログラムをインストールすることが行なわれる。
【００４８】
このインストールは、ルータ若しくはルータに接続のコンピュータにフロッピーディスクやＭＯディスク等の記録媒体をセットして行なうほか、ＩＰネットワークを通じて配信された伝送経路制御プログラムを使用して行なってもよい。
なお、実際のＩＰネットワークは、ＭＰＬＳルータをノードとして蜘蛛の巣状に構成されているので、いずれのＭＰＬＳルータも、発信元ＭＰＬＳルータ，着信先ＭＰＬＳルータ，中継ＭＰＬＳルータと成りうるので、本実施形態では、図７に示す発信元ＭＰＬＳルータ１１Ｓ，着信先ＭＰＬＳルータ１１Ｄ，中継ＭＰＬＳルータ１１Ｒのそれぞれのトラヒックエンジニアリング部１１６に、上記のようなトラヒック特性収集部，トラヒック特性通知部，負荷演算部，判定部及び負荷均等化部の機能を全て有する例を示しているが、発信元ＭＰＬＳルータ１１Ｓのトラヒックエンジニアリング部に、トラヒック特性収集部，トラヒック特性受信部，負荷演算部，判定部及び負荷均等化部の機能を持たせ、発信元ＭＰＬＳルータ１１Ｓ以外の着信先ＭＰＬＳルータ１１Ｄ，中継ＭＰＬＳルータ１１Ｒのそれぞれに設けられるトラヒックエンジニアリング部に、トラヒック特性収集部，トラヒック特性通知部の機能だけを持たせることは原理上可能である。
【００４９】
以下、トラヒックエンジニアリング部１１６で行なわれる負荷分散アルゴリズムについて詳述する。
（２−３）各ＭＰＬＳルータ１１で行なわれる負荷分散アルゴリズムについてまず、時間 t1 [ 秒(sec)]毎にトラヒック特性値としての所要のトラヒック項目〔出カポートからの出力パケット量，出カポートでの廃棄パケット数(NLOSS) ，出カポートの論理帯域(LBW) など〕について、ポート毎にトラヒック収集を行なう（手順Ｓ１）。
【００５０】
次に、得られたトラヒック特性値から現在の伝送路使用率CUTYを次式（１）に基づいて算出する（手順Ｓ２）。
CUTY＝出カポートからの出力パケット量／出カポートの論理帯域・・（１）
これにより、トラヒック特性収集部が、収集したトラヒック特性値を基に、上記ルータに接続された各伝送経路の使用率を判定する手段を有していることになる。その結果、各伝送経路の使用状態を詳細に把握することが可能となる。
【００５１】
このとき、得られたトラヒック特性値に関する情報（伝送路使用率CUTY）の加工処理も行なう。
その処理態様は以下のとおりである。
▲１▼平滑化( スムージング) 処理を行なう。かかる平滑化処理は、観測値を得る毎に次式（２）を計算することにより、値MUTYを得ることにより行なう。
【００５２】
MUTY ＝α×CUTY＋ (1 −α) × MUTY ・・（２）
ここで、αは平滑化( スムージング) 係数である。
これにより、トラヒック特性収集部が、収集したトラヒック特性値に関する情報を平滑化する手段を有していることになり、更に具体的には、ＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集した後、その統計値をExponential Moving Average法によって平滑化する手段を有していることになる。その結果、急激なトラヒック変動による影響を少なくできる。
【００５３】
また、上記の様に、得られたトラヒック特性値から求めた現在の伝送路使用率CUTYに対して平滑化を行なうことにより、平滑化手段が、使用率判定手段により判定された使用率を平滑化するように構成されていることになる。これにより、トラヒック変動による影響を排して各伝送経路の使用状態を正確に把握することができる。
【００５４】
▲２▼最大値抽出処理を行なう。かかる最大値抽出処理は、観測値の最大値を算出することにより行なう。すなわち、観測値の最大値を加工値MUTYと置くのである。これを式で表現すれば、下式（３）の通りである。
MUTY＝ max( 観測値) ・・（３）
これにより、トラヒック特性収集部が、収集したトラヒック特性値の最大値をトラヒック特性値の代表値とする手段を有していることになる。その結果、伝送経路選択制御を確実に行なうことができる。
【００５５】
なお、上記の平滑化処理，最大値抽出処理については、平滑化処理及び最大値抽出処理の両処理を施してもよいし、平滑化処理及び最大値抽出処理のうちの一方のみを施してもよい。
▲３▼パケット廃棄数の合計TLOSS を次式（４）に従って算出する。
TLOSS(n)＝ TLOSS(n-1) ＋ NLOSS ・・（４）
ここで、TLOSS(n)は更新後のパケット廃棄数の合計，TLOSS(n-1) は更新前のパケット廃棄数の合計， NLOSSは新たに生じたパケット廃棄数である。
【００５６】
その後は、ルーティングプロトコルのフラッディング（flooding）を利用して、時間t2[sec] 毎に、上記のトラヒック特性値（MUTYやTLOSS など）の配布を行なう。
なお、flooding完了毎にTLOSS はリセット（即ち0 に）する。
また、MUTYとして最大値を採用した場合も、MUTYはリセット（即ち0 に）する。
【００５７】
これにより、トラヒック特性通知部が、トラヒック特性に関する情報をルーティングプロトコルが装備するパケットを利用して通知する手段を有していることになるが、更に具体的には、ＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集した後、その特性値をOSPFやIBGPなどのルーティングプロトコルが装備するパケットを利用して配布し、他のＭＰＬＳルータに情報を伝達する手段を有していることになる。その結果、既存のプロトコルを活用でき、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【００５８】
また、トラヒック特性通知部が、トラヒック特性に関する情報を一定周期t2[sec] 毎に通知する手段を有していることにもなる。その結果、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
そして、この実施形態では、トラヒック特性通知部が、トラヒック特性に関する情報をRSVPのメッセージを拡張して通知する手段を有していることになり、更に具体的には、ＭＰＬＳルータに接続された伝送経路のトラヒック特性を収集した後、その特性値をRSVPのメッセージを拡張して配布し、他のＭＰＬＳルータに情報を伝達する手段をそなえていることになる。その結果、既存のプロトコルを活用することができ、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【００５９】
また、トラヒック特性収集部が、トラヒック特性を収集するフローの束の単位を、ＭＰＬＳで使用するラベル単位で収集する手段を有していることになる。その結果、細かいトラヒック特性の収集が可能になり、収集精度の向上に寄与する。
なお、収集したトラヒック特性値に対して、上記の平滑化処理，最大値抽出処理，パケット廃棄数合計算出処理のうちいずれか若しくは全ての処理を行なってから、現在の伝送路使用率の算出を行なうように構成しても、同様の効果を得ることができる。
一方、伝送路使用率の算出処理を負荷分散の起点となるＭＰＬＳルータ１１Ｓに委ねることにより、中継ＭＰＬＳルータおよび着信先ルータを、伝送路使用率の算出処理以外の各処理（平滑化処理，最大値抽出処理，パケット廃棄数合計算出処理，トラヒック特性値の通知処理）のみを行なうように構成することも可能である。
【００６０】
このように構成した中継ＭＰＬＳルータ１１Ｒ’および着信先ルータ１１Ｄ’（以下、これらのルータを総称して１１’で表す）のトラヒックエンジニアリング部１１６’で行なわれる負荷分散アルゴリズムを、以下に詳述する。
まず、上述したトラヒックエンジニアリング部１１６と同様に、本ＭＰＬＳルータ１１’のトラヒックエンジニアリング部１１６’も、時間 t1 [ 秒(sec)]毎にトラヒック特性値としての所要のトラヒック項目〔出カポートからの出力パケット量(L) ，出カポートでの廃棄パケット数(NLOSS) ，出カポートの論理帯域(LBW) など〕について、ポート毎にトラヒック収集を行なう。
【００６１】
続いて、得られた出力パケット量の平滑化( スムージング) 処理を行なう。かかる平滑化処理は、観測値を得る毎に次式（５）を計算することにより、値ＭＬを得ることにより行なう。
ML＝α×Ｌ＋ (1 −α) × ML' ・・（５）
ここで、αは平滑化( スムージング) 係数、ML' は前回算出されたMLである。
【００６２】
次に、最大化抽出処理を行なう。これは、上述したトラヒックエンジニアリング部１１６と同様に、観測値の最大値を加工値ＭＬと置くことにより行なわれる。なお、この最大化抽出処理については、省略することも可能である。
さらに、上述したトラヒックエンジニアリング部１１６と同様に、パケット廃棄数の合計TLOSS を、（４）式に従って算出する。
【００６３】
その後は、ルーティングプロトコルのFloodingを利用して、時間t2[sec] 毎に、上記のトラヒック特性値（MLやTLOSS など） の配布を行なう。
なお、flooding完了毎に、TLOSS をリセット（即ち0 に） する点、MLとして最大値を採用した場合にはMLもリセット（即ち0 に） する点も、上述したトラヒックエンジニアリング部１１６と同様である。
【００６４】
これにより、本変形例のＭＰＬＳルータ１１’も、上述のＭＰＬＳルータ１１と同様に、平滑化処理，最大値抽出処理，パケット廃棄数合計算出処理，トラヒック特性値の通知処理の各々に伴う効果を得ることができる上に、トラヒック特性に関する情報の平滑化処理を負荷分散の起点となるＭＰＬＳルータ１１Ｓに委ねているので、上述のＭＰＬＳルータ１１よりもトラヒック特性の加工に要する時間が短くて済むとともに、構成を簡素なものとすることができ、コストの低減に寄与する。
【００６５】
（２−４）負荷分散の起点となるＭＰＬＳルータ１１Ｓで行なわれる負荷分散アルゴリズムについて
まず、負荷分散の起点となるＭＰＬＳルータ１１Ｓで通知を受ける flooding 情報は、前記したように、平均リンク使用率（又は観測値の最大値） MUTY （又は平均出力パケット量ML），廃棄パケット数 TLOSS，出カポート論理帯域 LBWなどである。
【００６６】
ここで、このＭＰＬＳルータ１１Ｓが平均出力パケット量MLを受信する場合には、併せて受信する出力ポート論理帯域LBW 等を使用して、各ルータのリンク使用率MUTYを算出することになる。他の中継ルータが平均リンク使用率算出機能を有し、算出した平均リンク使用率MUTYを通知する場合には、このＭＰＬＳルータ１１Ｓ側にはリンク使用率算出機能を設ける必要はない。
【００６７】
そして、この負荷分散の起点となるＭＰＬＳルータ１１Ｓでは、パス状態チェック，実効負荷（ Effective Load ）の算出，負荷調整（ Load Adjusting ）が行なわれる。
パス状態チェックについては、一定周期t3[sec] 毎に発信元ＭＰＬＳルータ（起点ルータ）１１Ｓから着信先ルータ（終点ルータ）１１Ｄまでの各ルートの輻輳状態チェックを以下の要領で実施する。
【００６８】
負荷分散制御の起点となるＭＰＬＳルータ１１Ｓにおいて、このＭＰＬＳルータ１１Ｓには負荷分散制御を終点とするＭＰＬＳルータ１１Ｄ間に複数のパスが張られていて、各パスは複数の中継ＭＰＬＳルータ１１Ｒを経由していることを前提にして、各ルートの輻輳状態チェックは、各パスの使用率を、各中継ＭＰＬＳルータ１１Ｒから収集したものであって、その中継ＭＰＬＳルータ１１Ｒに接続されている伝送経路( リンク) の平均使用率を基に判定する[ この輻輳状態チェック態様をパスi （path i) における各リンクj(1ink j) の平均を取る場合の輻輳状態チェック態様という] 。
【００６９】
これを数式で示すと下式（６）のようになる。
ρpath i＝Average (MUTY(link j, path i) ・・（６）
これにより、この場合は、発信元ＭＰＬＳルータ１１Ｓに設けられるトラヒック特性収集部が、発信元ＭＰＬＳルータに接続された各伝送経路の使用率を、中継ＭＰＬＳルータから収集した中継ＭＰＬＳルータに接続されている伝送経路の平均使用率を基に判定する手段を有していることになる。その結果、ネットワークの使用効率の向上に寄与しうる。
【００７０】
さらに、上記のpath iにおける各 1ink の平均を取る場合の輻輳状態チェック態様と同様の前提で、各ルートの輻輳状態チェックを、各パスの使用率を、各中継ＭＰＬＳルータから収集したものであって、その中継ＭＰＬＳルータに接続されている伝送経路( リンク) の最大使用率を基に判定するような輻輳状態チェックも考えられる（このような輻輳状態チェック態様を path i における全ての 1ink の最大を取る場合の輻輳状態チェック態様という）。
【００７１】
これを数式で示すと下式（７）のようになる。
path i＝ Max(MUTY(1ink j, path i) ・・（７）
これにより、この場合は、発信元ＭＰＬＳルータに設けられるトラヒック特性収集部が、発信元ＭＰＬＳルータに接続された各伝送経路の使用率を、中継ＭＰＬＳルータから収集した中継ＭＰＬＳルータに接続されている伝送経路の最大使用率を基に判定する手段を有していることになる。その結果、伝送経路選択制御を確実に行なうことができる。
なお、path iにおけるパケット廃棄数の合計TLOSS path i は次式（８）で求める。
【００７２】
TLOSS path i ＝ΣTLOSS link j ・・（８）
なお、上記でi はpath（ＬＳＰ）の番号、j は1ink番号である。
そして、発信元ＭＰＬＳルータに設けられるトラヒック特性収集部は、各伝送経路が輻輳しているかどうかを一定周期t3[sec] 毎に判定する手段を有していることにもなる。このようにすることにより、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
【００７３】
実効負荷（ Effective Load ）ρeffective path iの算出については以下の要領で行なわれる。
ここで、実効負荷は、リンクの使用率とこのリンクでのパケット損失数とから計算される、実効的な使用率であると定義される。本来ならば、当該リンクにかかる実際の負荷を計測すればよいが、実際ルータ内部は多段スイッチ構成になっており、直接的に負荷を計測することは困難である。従って、本実施形態では、リンクの使用率とパケット損失数のみを用いて負荷を推定するもので、この推定負荷を実効負荷と言っている。
【００７４】
図１０を用いて、実効負荷を説明する。実効負荷の意味は次のとおりである。即ち、図１０の特性を見れば明らかなように、もしパケット損失が無ければ、リンクでの負荷ρpath iと実効負荷とは一致するが、パケット損失が発生すれば、高めに負荷を計算するように、所定の関数f(TLOSS path i)で修正をかけてこれを実効負荷としている。なお、実効負荷には、上限ρceiling を設けている。これを式で表現すると、下式（９），（１０）のようになる。
【００７５】
ρeffective path i＝ρpath i×f(TLOSS path i) ・・（９）
ρeffective path i＝Min(ρeffective path i, ρcei1ing)・・（１０）
ここで、f(TLOSS path i) はTLOSS path iに関する関数であり、ρceiling は上限負荷、即ち実効負荷ρeffective path iの上限値である。
この機能は、発信元ＭＰＬＳルータに設けられる負荷演算部中の、中継ＭＰＬＳルータにおいて発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段が発揮する。これにより、負荷分散制御の起点となるＭＰＬＳルータにおいて、当該ＭＰＬＳルータには負荷分散制御を終点とするＭＰＬＳルータ間に複数のパスが張られていて、各パスは複数の中継ＭＰＬＳルータを経由している状況下で、通知されたトラヒック特性を基に負荷を計算する場合に、各中継ＭＰＬＳルータにおいて発生したパケット廃棄数TLOSS path iを考慮して、実効的な負荷ρeffective path iを、
i番目のパスの実効的な負荷＝i 番目のパスの負荷×f(パケット廃棄数)
で計算することができるようになっている。なお、f(パケット廃棄数) はパケット廃棄数を変数とする関数である。
【００７６】
その結果、直接的に負荷を計測しなくても、簡素な手法で、実効的な負荷を推定できる。
また、上記の実効的負荷演算手段が、実効的な負荷を演算する際に、実効的な負荷の上限値を設定するように構成されていることになる。これにより、過剰な量の負荷推定を避けることができ、その結果、適切な伝送経路選択制御を行なえる。
【００７７】
負荷調整については以下の要領で行なわれる。
負荷調整は、時間t4[sec] 毎に実施するが、上記のように各パス(LSP) の実効負荷(effective load)を算出できれば、次に全パス(LSP) での使用率を求めることになる。本実施形態では、全パスを一つの仮想的なパイプとみなし、そのパイプの負荷を算出する。
【００７８】
すなわち、この場合、発信元ＭＰＬＳルータに設けられる判定部が、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率を求める手段を有していることになるが、この場合の使用率は次式（１１）で求められる。
全パスを一つの仮想的なパイプとみなしたときの使用率ρeffective all ＝Σ(ρeffective path i×LBW path i)／ΣLBW path i ・・（１１）
ここで、ρeffective path iはパスi の実効負荷、LBW path i はパスi の論理帯域である。
【００７９】
これにより、不必要に新しい伝送経路を追加することを防止できるほか、ネットワークの有効利用にも寄与しうる。
次に、マルチパスの有効性を検証する。
すなわち、式（１１）で得られた使用率と設定された経路追加用基準値ρoffer1とを比較し、得られた使用率の値が経路追加用基準値を超えていた場合に、新伝送経路を追加するとともに、同じく式（１１）で得られた使用率と設定された経路削除用基準値とを比較し、得られた使用率の値が経路削除用基準値ρoffer2を下回っていた場合に負荷が少ないパスを削除するのである。即ち、上記で算出された負荷が多ければ新パスを追加し、少なければ既存パスを削除するのである。
【００８０】
これを論理表現すれば、以下のようになる。
If ρeffective a11 ≧ ρoffer1 then
if timer1 was expired then（左の部分は、「タイマーが既にexpireされていたならば」の意味である。）
search new path and add new path (左の部分は、「代替経路探索処理へ」の意味である。)
endif
elseif ρeffective all ＜ ρoffer2 then
if timer2 was expired then（左の部分は、「タイマーが既に expire されていたならば」の意味である。）
delete path (左の部分は、「代替経路削除処理へ」の意味である。)
endif
endif
これにより、発信元ＭＰＬＳルータに設けられる判定部が、パイプ使用率演算手段で得られたパイプ使用率と設定された基準値とを比較し、比較結果に応じて、伝送経路を追加するか削除するかの判定を行なう手段を有していることになり、パイプ使用率演算手段で得られたパイプ使用率が経路追加用基準値を超えていた場合に、新伝送経路を追加したり、パイプ使用率演算手段で得られたパイプ使用率が経路削除用基準値を下回っていた場合に、負荷が少ない伝送経路を削除したりするようになっている。その結果、アップツーデートに最適な経路選択を実施できる。
【００８１】
なお、上述したマルチパスの有効性の検証手順の変形例として、式（１１）で得られたパイプ使用率（全パス合計の使用率）に加え、パイプ使用率の時間当たりの変化率を算出し、このパイプ使用率の変化量に基づき、伝送経路の追加・削除の判定を行なってもよい。この場合の手順について以下に詳述する。
まず、パイプ使用率の時間当たりの変化率として、微小間隔t4を挟んで得られた２つのパイプ使用率の差分値ΔU(t)を、以下の式（１２）により算出する。
【００８２】
△U(t)＝[ρeffective all(t-1)−ρeffective all(t)]／t4・・（１２）
ここで、ρeffective all(t)は時間tにおける全パス合計の使用率であり、ρeffective all(t-1)は時間tの１つ前の計測時間t-1における全パス合計の使用率である。
なお、式（１１）で得られたパイプ使用率の経時的変化を時間関数として表した上で、ある時点におけるパイプ使用率の微分値を算出し、これをパイプ使用率の時間当たりの変化率としてもよい。これにより、パイプ使用率のより正確な変化率を把握することができる。
【００８３】
次に、式（１１）で得られた使用率と設定された経路追加用基準値ρoffer1とを比較するとともに、式（１２）で得られた変化率と設定された経路追加用基準値ρofferd1とを比較し、得られた使用率及び変化率の値がともに対応する経路追加用基準値を超えていた場合に、新伝送経路を追加する。また、式（１１）で得られた使用率と設定された経路削除用基準値ρoffer2とを比較するとともに、式（１２）で得られた変化率と設定された経路削除用基準値ρofferd2とを比較し、得られた使用率又は変化率の値が対応する経路削除用基準値を下回っていた場合に、負荷が少ないパスを削除する。即ち、この場合も、上記で算出された負荷が多ければ新パスを追加し、少なければ既存パスを削除することになる。
【００８４】
これを論理表現すれば、以下のようになる。
If （ρeffective a11≧ρoffer1 or △U(t)≧ρofferd1） then
if timer1 was expired then（左の部分は、「タイマーが既に expire されていたならば」の意味である。）
search new path and add new path (左の部分は、「代替経路探索処理へ」の意味である。)
endif
elseif(ρeffective all＜ρoffer2 and △U(t)＜ρofferd2) then
if timer2 was expired then（左の部分は、「タイマーが既に expire されていたならば」の意味である。）
delete path (左の部分は、「代替経路削除処理へ」の意味である。)
endif
endif
以上の構成により、パイプ使用率の経時的変化を考慮しながらパスの追加・削除の判定がなされるため、パイプ使用率のみに基づく場合よりも効果的にパスの追加・削除を行なうことができる。
【００８５】
なお、上述の構成では、パスの追加の判定には各比較結果の論理積（and）、パスの削除の判定には各比較結果の論理和（or）を用いているが、パスの追加・削除の判定基準はこの組み合わせに限定されるものではなく、ネットワークの構成や状態に応じて、これらの判定基準（論理積，論理和）を別の組み合わせで用いてもよいし、他の判定基準を用いても構わない。これにより、ネットワークの構成や状態に応じて適切にパイプ使用率の積算量を把握することができる。
【００８６】
また、上述の変化率のみを基準値と比較してパスの追加・削除の判定を行なってもよい。これにより、簡素な構成でパスの追加・削除の判定を行なうことができる。
一方、マルチパスの有効性検証手順の別の変形例として、式（１０）で得られたパイプ使用率（全パス合計の使用率）に加え、パイプ使用率の一定時間における積分量を算出し、これらのパイプ使用率の変化量に基づき、伝送経路の追加・削除の判定を行なってもよい。
【００８７】
この場合、まず、パイプ使用率の一定時間における積算量として、パイプ使用率の一定時間t4における積分値∫MU(t)を、以下の式（１３）により算出する。
【００８８】
【数１】
すなわち、∫MU(t)は、一定時間t〜t＋t4におけるパイプ使用率MUの積分値ということになる。
なお、パイプ使用率が一定時間内にある基準値を超えた回数を算出し、これをパイプ使用率の一定時間における積算量としてもよい。これにより、簡素な構成でパイプ使用率の積算量を把握することができる。
【００９０】
次に、式（１１）で得られた使用率と設定された経路追加用基準値ρoffer1とを比較するとともに、式（１３）で得られた積算量と設定された経路追加用基準値ρofferi1とを比較し、これらの比較結果に基づき新伝送経路を追加する。また、式（１１）で得られた使用率と設定された経路削除用基準値ρoffer2とを比較するとともに、式（１３）で得られた積算量と設定された経路削除用基準値ρofferi2とを比較し、これらの比較結果に基づき負荷が少ないパスを削除する。
【００９１】
この場合も、パスの追加・削除の判定に際しては、ネットワークの構成や状態に応じて、各比較結果の論理和，論理積など、様々な判定基準を任意の組み合わせで用いることにより、適切にパイプ使用率の積算量を把握することができる。また、使用率を用いずに積算量のみに基づいて判定を行なうことにより、簡素な構成でパスの追加・削除の判定を行なうことができる。
【００９２】
以上の構成により、発信元ルータに設けられる判定部が、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報（パイプ使用率，パイプ使用率の変化率，パイプ使用率の積算量）を求める演算手段を有するとともに、この使用率（パイプ使用率，パイプ使用率の変化率，パイプ使用率の積算量の少なくともいずれか一つ）に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成されていることになる。これにより、現在の伝送経路の負荷を考慮して適切に伝送経路の追加及び削除を行なうことが可能となり、効率的に負荷の分散を図ることができるともに、ネットワークの環境やハードウェアの性能に応じて適切な経路選択が可能となる。
【００９３】
また、同じく以上の構成により、発信元ルータに設けられる判定部が、演算手段で得られたパイプ使用率と第１の基準値（ρoffer1，ρoffer2）、演算手段で得られた変化率と第２の基準値（ρofferd1，ρofferd2）、演算手段で得られた積算量と第３の基準値（ρofferi1，ρofferi2）のうちの少なくともいずれか一組の比較を行ない、この比較結果に応じて、伝送経路を追加するか削除するかの判定を行なうように構成されていることになる。より詳しくは、この使用率，変化率及び積算量のうちの少なくともいずれか一つが対応する経路追加用基準値を超えていた場合に、新たな伝送経路を追加する旨の判定をするとともに、少なくともいずれか一つが対応する経路削除用基準値を下回っていた場合に、負荷が少ない伝送経路を削除する旨の判定をすることになる。これにより、ネットワークの環境やハードウェアの性能に応じて、アップツーデートに最適な経路選択を実施できる。
【００９４】
ところで、上述したマルチパスの有効性の検証の際に、伝送経路を削除する旨の判定がされた場合には、幾つかの条件に基づいて削除候補となるパスを選択し、この削除候補となるパスを削除した場合における全パスの使用率（他の伝送経路の負荷）を予測してこれを所定の基準値と比較し、この比較結果に基づいて実際に削除するパスを決定する。
【００９５】
具体的には、以下のアルゴリズムに従ってマルチパスの削除が行なわれる。
▲１▼ 全パスのうち最初に張られたパスは削除の対象外とする。
▲２▼ 全パスのうち使用可能帯域が最小のパスを選択する。
▲３▼ ▲２▼の条件を満たすパス（使用可能帯域が最小のパス）が複数ある場合は、その中で実行負荷が最低のパスを選択する。
▲４▼ ▲２▼▲３▼の条件を満たすパス（使用可能帯域が最小且つ実行負荷が最低のパス）が複数ある場合は、ホップ数が最大のパスを選択する。
▲５▼ ▲２▼▲３▼▲４▼の条件を満たすパス（使用可能帯域が最小，実行負荷が最低，ホップ数が最大のパス）が複数ある場合は、最後に追加されたパスを選択する。
▲６▼ ▲１▼−▲５▼で選択されたパスを削除候補として、このパスを仮想的に削除した場合におけるマルチパス全体の使用率を算出する。
▲７▼ ▲６▼で算出した削除候補パスの削除後におけるマルチパス全体の使用率を、設定した輻輳判定閾値と比較する。削除後のマルチパス全体の使用率がこの閾値以上の場合には、この削除候補パス以外のパスを対象として、再び▲１▼−▲５▼で新たな削除候補パスを選択する。
▲８▼ ▲７▼の比較により、削除後のマルチパス全体の使用率が輻輳判定閾値を下回っていた場合には、その削除候補パスを実際に削除する。
【００９６】
以上のようなアルゴリズムに従ってパスの削除を行なうことにより、発信元ルータに設けられる判定部が、負荷演算部で求められた負荷情報に基づいて削除対象となる伝送経路の候補を選択する手段と、この削除候補選択手段により選択された削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、この負荷予測手段により予測された他の伝送経路の負荷を所定の基準値とを比較した結果に応じてこの削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成されることになる。これにより、各伝送経路を削除した場合の影響を考慮して、削除する伝送経路を適切に選択することが可能となる。
【００９７】
なお、先述したパイプ使用率（全パス合計の使用率）に関する情報（使用率，変化率，積算量）と基準値との比較結果が、伝送経路を削除する旨の判定に繋がるものである場合（例えば、パイプ使用率に関する情報のいずれかが対応する基準値を下回った場合）には、この比較結果をトリガとして上述のパス削除アルゴリズムが実行され、実際のパスの削除が行なわれる。
【００９８】
こうした構成によって、発信元ルータに設けられる判定部が、演算手段で得られたパイプ使用率に関する情報に基づき、上記の選択手段，予測手段及び決定手段の動作トリガをかけるトリガ手段をさらにそなえて構成されていることになる。これにより、ネットワーク全体の状況に応じてアップツーデートに伝送経路を削除できる。
【００９９】
このようにして、マルチパスの有効性を検証した後は、移動する実効的な帯域[Effective Bandwidth (EBW)] を算出する。
即ち、追加された複数の伝送経路間で負荷を均等化する場合、パスの論理帯域に比例して負荷を配分するために、実効帯域(Effective Bandwidth) を式（１４）により計算して、負荷分散を行なう。
【０１００】
△EBW path i ＝( ρeffective a11 −ρeffective path i）×LBW path i・・（１５）
これにより、発信元ＭＰＬＳルータに設けられる負荷均等化部が、中継ＭＰＬＳルータにおいて発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有していることになる。これによって、伝送経路の帯域を考慮に入れた負荷の均等化を実施できる。
【０１０１】
そして、上記のようにして実効帯域△EBW が求まると、最後に、トラヒックシェアの調整を行なう。
すなわち、式（１４）で計算された移動すべき実効帯域に比例して、流入するＩＰパケットを複数のパスに振り分けるのであるが、この流入するＩＰパケットを複数のパスに振り分ける場合に、ＩＰアドレスを基にハッシュ関数による演算を行ない、この演算結果を基にしてランダムにＩＰトラヒックフローを振り分けるのである。ここでハッシュ関数とは、ある入力値から所定範囲内のランダムな整数値を作成して出力する関数である。
【０１０２】
具体的に、ハッシュ関数としてCRC (cyc1ic redundancy check) 演算を用いた場合について、以下に詳述する。
【０１０３】
Gr : 負荷調整係数
TS : traffic share の幅 ＝ CRC16 の結果の範囲＝65535
上記の式により、負荷調整を行なった場合、負荷調整前と負荷調整後との間の負荷調整分布は図１２のようになる。
この実施形態で、負荷調整の意義を有するトラヒックシェアとは、負荷分散を行なうために用いるパラメ−タで、トラヒックシェアの合計が全パスを通過する実際のトラヒックの合計値となる。トラヒックシェアの幅はCRC (cyc1ic redundancy check）16を用いた場合、前述のごとく、O から65535 までの整数となる。ＩＰパケットがルータに到着したとき、負荷調整装置では、そのＩＰパケットのＩＰアドレス（ホストアドレス，宛先アドレス）を基にCRC 演算を行なうことができ、その結果、O から65535 の間のある値がそのＩＰフローに割り当てられる。つまり本負荷調整機構は、ＩＰアドレスをある整数の幅に縮退させる機能を持つ。言い換えれば、ルータに到着したＩＰフローはランダムに各パスに収容されることとなる。
【０１０４】
これにより、発信元ＭＰＬＳルータに設けられる負荷均等化部が、移動実効帯域演算手段で求められた移動すべき実効帯域に比例して、発信元ＭＰＬＳルータに流入するパケットを複数の伝送経路に振り分ける手段を有し、更にこのとき、アドレスを基にハッシュ関数を用いた演算を行ない、この演算結果に基づいて、ランダムにトラヒックフローを振り分けるように構成されていることになる。その結果、簡素な計算によって、的確にトラヒックフローを振り分けることができる。
【０１０５】
なお、より簡素で高速なハッシュ関数として、入力値の各ビット値に対して位置の入れ替え及び論理演算を行なうことにより、ランダムな整数値を作成してもよい。
例えば、図１３に示すように、まずIPパケットに含まれる32bitの宛先IPアドレスを、8bitずつ4つのエリアに分割する。次に、隣接した２つの8bitの数値を交互に入れ替えた上で、上位16bitと下位16bitの排他的論理和を求める。最後に、こうして作成された16bitの数値を整数に変換し、これをハッシュ値（ハッシュ関数の出力値）とする。
【０１０６】
なお、入力値の各ビット値に対する位置の入れ替え及び論理演算は、これに限定されるものではなく、様々な手法を任意の組み合わせで用いることができる。
以上から、発信元ルータに設けられる負荷均等化部が、ハッシュ関数による演算として、入力値の各ビット値に対して位置の入れ替え及び論理演算の少なくとも一方を行なうことにより、ランダムな整数値を作成するように構成されていることになる。これによって、ハッシュ演算を簡略化することができ、トラヒックフローの振り分けを高速に行なうことができる。
【０１０７】
なお、上述したハッシュ演算の効率を向上させるために、ハッシュ関数の入力値として、パケットに含まれるアドレス（ホストアドレス，宛先アドレス）に併せて、パケットに含まれるアドレス以外の制御値（例えばプロトコルID，ポート番号など）などを用いてもよい。すなわち、発信元ルータに設けられる負荷均等化部を、ハッシュ関数の入力値として、パケットに含まれるアドレス以外の制御値を併せて用いるように構成するのである。これにより、ハッシュ演算による出力値の攪乱度が増し、効率的且つ効果的なトラヒックフローの振り分けを行なうことができる。
【０１０８】
以下に本アルゴリズムの負荷分散例を示す。
（Ａ）計算例１
パス１，２，３の各論理帯域LBW[bit/s]をそれぞれ１０Ｍ，８Ｍ，２Ｍとし、実効負荷ρeffective をそれぞれ0.5 ，0.2 ，0.3 とすると、パス１，２，３の実トラヒック[bit/s] は、それぞれ10M × 0.5＝ 5M ，8M× 0.2＝ 1.6M,2M× 0.3＝ 0.6M となる。
【０１０９】
さらに、この場合の全パスを仮想的な一つのパイプとみなし、平均的な使用率ρave effective を求めると、以下のようになる。
ρave effective ＝ (5M＋ 1.6M ＋ 0.6M) / (10M ＋ 8M ＋ 2M)＝ 0.36
そして、移動する実効帯域(EBW) [bit/s] をパス１，２，３のそれぞれについて算出すると、以下のようになる。
【０１１０】
すなわち、パス１の移動する実効帯域△EBW PATH1 は (0.36− 0.5) × 10M＝−1.4 M となり、パス２の移動する実効帯域△EBW PATH2 は (0.36− 0.2) ×8M＝＋1.28M となり、パス３の移動する実効帯域△EBW PATH3 は (0.36− 0.3) ×2M＝＋0.12M となる。そして、各パスの移動する実効帯域の総和を計算すると、−1.4M＋ 1.28M＋ 0.12M＝ 0 となる。
【０１１１】
この計算結果を基に、トラヒックシェアの調整を行なう。
すなわち、パス１については、 5 M− 1.4 M＝ 3.6 M、パス２については、 1.6 M＋ 1.28M＝ 2.88M、パス３については、 0.6 M＋ 0.12M＝ 0.72Mとなり、パス１，２，３について、 3.6× Gr : 2.88× Gr : 1.2 × Gr の比でトラヒックシェアを変更すればよい。
（Ｂ）計算例２
パス１，２，３，４の各論理帯域LBW[bit/s]をそれぞれ150M, 45M, 150M, 600Mとし、パス１，２，３，４の実効負荷ρeffective をそれぞれ1.2, 1.5, 1.1, 0.8とすると、パス１，２，３，４の実トラヒック[bit/s] は、それぞれ150M× 1.2＝180M ， 45M× 1.5＝67.5M ，150M× 1.1＝ 165M ，600M× 0.8＝ 480M となる。
【０１１２】
また、全パスを仮想的な一つのパイプとみなし、平均的な使用率ρave effective を求めると、次のようになる。
ρave effective ＝ (180M＋ 67.5M＋ 165M ＋ 480M) / (150M＋ 45M＋ 150M ＋ 600M)＝ 892.5/945＝ 0.94
そして、各パス１〜４について、移動する実効帯域 (EBW)を算出すると次のようになる。
【０１１３】
すなわち、パス１の移動する実効帯域△EBW PATH1 は(O.94 −1.2)×150M＝−39M となり、パス２の移動する実効帯域△EBW PATH2 は(0.94 −1.5)× 45M＝−25.2M となり、パス３の移動する実効帯域△EBW PATH3 は(O.94 −1.1)×150M＝−24M となり、パス４の移動する実効帯域△EBW PATH4 は(0.94 −O.8)×600M＝84M となる。
【０１１４】
この計算結果を基に、トラヒックシェアの調整を行なう。
すなわち、パス１については、 180M − 39 M＝141 Mとなり、パス２については、67.5M − 25.2M＝ 42.3Mとなり、パス３については、 165M − 24 M＝141 Mとなり、パス４については、 480M ＋ 84 M＝564 Mとなる。従って、パス１，２，３，４について、 141× Gr : 42.3× Gr : 141 × Gr : 564 × Gr の比でトラヒックシェアを変更すればよい。
【０１１５】
（２−５）作用説明
このような構成により、まず、ＭＰＬＳルータ１１がネットワークに接続されると、ルーティングプロトコルが動作し、ネットワークに接続されている他のＭＰＬＳルータの発見を行なう。かかる発見には一般的にハローパケットが用いられる。ルーティングプロトコルにより、ネットワークのトポロジーが判明すると、パス選択部１１３においてリンク状態データベース１１３Ａが作成される。リンク状態データベース１１３Ａを用いて、ＬＳＰ選択部１１４を経てＬＳＰ設定部１１５により他ＭＰＬＳルータとの間でＬＳＰが設定される。さらに、パス選択部１１３のリンク状態データベース１１３Ａと連携し、ＬＳＰ選択部１１４では代替経路情報データベース１１４Ａが作成され、従来のルーティングプロトコルに無い、ＭＰＬＳ独自のルーティングテーブルが作成される。代替経路情報データベース１１４Ａは、トラヒックエンジニアリング部１１６と連携し、必要に応じて代替経路をＬＳＰを用いて設定する。つまり、終点のＭＰＬＳルータとの間に複数のＬＳＰを設定することにより、そのＬＳＰ間で負荷のバランスを行なうことができるのである。
【０１１６】
なお、負荷のバランスに関する一連の機能はトラヒックエンジニアリング部１１６の機能であるが、かかるトラヒックエンジニアリング部１１６においては、パケット転送部１１１から、使用率やパケット損失数といったトラヒック特性値が負荷観測部１１６Ａへ送られてくる。負荷観測部１１６Ａはそれらの値をトラヒック特性値計算部１１６Ｂへと送る。トラヒック特性値計算部１１６Ｂでは、トラヒック特性値のスムージング化や最大値化を行ない、他ＭＰＬＳルータへと送信する。また他ＭＰＬＳルータより送られてきたトラヒック特性値はトラヒック特性値計算部１１６Ｂで収集され、トラヒックエンジニアリング計算部１１６Ｃへと送られる。トラヒックエンジニアリング計算部１１６Ｃでは、実効負荷や実効帯域の計算が行なわれ、各ＬＳＰの帯域に応じた負荷の調整がなされる。
【０１１７】
その結果は、負荷調整部１１６Ｄへと送信され、トラヒックシェアの幅が決められる。そして、その結果はＬＳＰ設定部１１５を経て、ＩＰパケット転送部１１１で設定される。
このように、発信元ルータ１１Ｓ以外の他のルータ１１Ｒ，１１Ｄにおいて、他のルータに接続された伝送経路のトラヒック特性を収集するとともに、収集されたトラヒック特性を発信元ルータに通知する一方、発信元ルータ１１Ｓにおいては、この発信元ルータに接続された伝送経路のトラヒック特性を収集しながら、収集されたトラヒック特性及び他のルータから得られたトラヒック特性の一方又は両方に基づいて実効負荷を演算し、実効負荷情報に基づいて伝送経路を追加するか削除するかの判定を行ない、更に得られた実効負荷を複数の伝送経路間で均等化することが行なわれるので、各ルータにおいてトラヒック特性の観測機能およびその特性値の通知機能を持たせて、負荷分散の起点となるルータ（発信元ルータ）において、終点となるルータ( 着信先ルータ) までの複数のパスの帯域管理をダイナミックに行なうことができ、その結果、空き帯域に合わせた負荷分散が可能となる。すなわち、ＩＰネットワーク内のルータにおいて、起点となるルータ( 発信元ルータ) から終点となるルータ( 着信先ルータ) までに複数のルート( 伝送経路) を設定し、設定されたルート間で負荷の分散を行なえるので、ネットワークトポロジーに関係なく、また伝送経路の種類によらないで、インターネット等のネットワーク内でトラヒックエンジニアリングを可能にできるのである。
（２−６）実験例
図１４に示す実験用ネットワーク構成を用いて、本発明の負荷分散装置による負荷分散性能の評価を行なった。なお、図１４において、１２０Ｒ−１〜１２０Ｒ−５は本発明の負荷分散装置を備えたＬＳＲで、発信元ＬＳＲであるＬＳＲ１２０Ｒ−１には負荷発生装置１２１が、負荷着信先ＬＳＲであるＬＳＲ１２０Ｒ−５には負荷受信装置１２２が、それぞれ接続されている。また、ＬＳＲ１２０Ｒ−１〜１２０Ｒ−５の間には、複数のリンクｌｉｎｋ１〜ｌｉｎｋ５が張られており、これによって複数の伝送経路１２３−１，１２３−２が形成されている。すなわち、この図１４に示す実験用ネットワーク構成も、図７に示したＭＰＬＳのネットワーク構成の一例として考えることができる。
【０１１８】
各ＬＳＲ１２０Ｒ−１〜１２０Ｒ−５による経路検索機能の動作を確認するために、この図１４に示す実験用ネットワーク構成を用いて負荷分散を行ない、発信元ＬＳＲ１２０Ｒ−１に接続されたリンクｌｉｎｋ１，ｌｉｎｋ３（それぞれ複数の伝送経路１２３−１，１２３−２の入り口に相当する）について、トラヒック移動量とトラヒックの収束時間との関係を、本発明の負荷分散装置による負荷分散性能として評価した。その評価結果を図１５及び図１６に示す。
【０１１９】
図１５では、入力トラヒック（input traffic） 50 Mbit/sec (93 flows)，OSPF によるflooding インターバル（OSPF flooding interval） 10 sec，輻輳判定閾値（congestion threshold） 30 Mbit/sec，ハッシュ粒状度（Hash granularity） 100 ％という条件で負荷分散を行ない、10秒毎に算出したリンクｌｉｎｋ１およびｌｉｎｋ３におけるリンク使用率の時間的変化をグラフに示している。
【０１２０】
実験開始直後はｌｉｎｋ１のリンク使用率（グラフ中の白抜きの丸）が50 Mbit/sec 弱で、輻輳判定閾値である 30 Mbit/sec を超えており、輻輳が生じている。一方、ｌｉｎｋ３のリンク使用率（白抜きの三角）はほぼ0 Mbit/sec であり、これらの２つのリンクｌｉｎｋ１，ｌｉｎｋ３の間に負荷の偏りが生じているのが分かる。
【０１２１】
実験開始40秒後から本発明の負荷分散装置による負荷分散を開始したところ、ｌｉｎｋ１のリンク使用率が急速に減少するとともに、ｌｉｎｋ３のリンク使用率が急速に増加しており、これら２つのリンクｌｉｎｋ１，ｌｉｎｋ３の間で負荷の分散が計られているのが分かる。その後、負荷分散開始20秒後（実験開始70秒後）には２つのリンクｌｉｎｋ１，ｌｉｎｋ３のトラヒックが逆転し、いったんは過制御の状態になるものの、振動を繰り返す間にその差は非常に小さくなり、次第に２つのリンクｌｉｎｋ１，ｌｉｎｋ３のトラヒックの差が収束していった。トラヒックの収束時間（convergence time）は負荷分散開始から120秒であった。
【０１２２】
一方、図１６においては、ハッシュ粒状度（Hash granularity） を20 ％に変更した以外は、図１５と同じ条件で実験を行なった。その結果、トラヒックの収束時間（convergence time）は負荷分散開始から200秒と、図１５に示した結果よりも長くなったものの、トラヒックが逆転して過制御に陥ることはなく、２つのリンクｌｉｎｋ１，ｌｉｎｋ３のトラヒックの差は漸近的に収束しており、安定した状態で負荷の分散が図られたことが分かる。
【０１２３】
すなわち、ハッシュ粒状度（Hash granularity）を高めに設定すれば、過制御によってトラヒックが不安定化するものの、短時間で負荷分散を図ることができる。これに対して、ハッシュ粒状度（Hash granularity）を低めに設定すれば、負荷分散に要する時間は長くなるものの、過制御によるトラヒックの不安定化を防ぎながら、安定した状態で負荷分散を図ることができる。すなわち、ネットワークの状態やハードウェアの性能に合わせて適切にハッシュ粒状度（Hash granularity）を設定することにより、効率的な負荷分散が可能となる。
【０１２４】
（２−７）その他
なお、上記の実施形態では、ＭＰＬＳ (Multi-Protoco1 Label Switching)を用い、ＭＰＬＳのラベル機能を用いて、ルーテイングプロトコルとは異なるルートを設定し、負荷分散を行なうものについて説明したが、その他、 ATM (Asynchronous Transfer Mode) や FR (Frame Relay) などを用い、レイヤ２独自のプロトコルを用いて、レイヤ３( ＩＰ) とは異なるルートを設定し、負荷分散を行なったり、ＩＰでのソースルーティングを用いて、ルーティングプロトコルの経路とは異なるルートを設定し、負荷分散を行なったりする手法を用いても、本発明を適用できることはいうまでもない。
また、上記の実施形態では、通信装置の一例としてルータを用い、これに本発明を適用した場合について説明したが、本発明はこれに限定されるものではなく、他の通信装置（例えば、ゲートウェイなど）に適用することも可能である。
【０１２５】
また、本発明は、上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。
（２−８）付記
［付記１] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記通信装置に設けられる装置であって、
該通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集されたトラヒック特性を他の通信装置に通知するトラヒック特性通知部と、
該トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、
該負荷演算部で求められた負荷情報に基づいて、伝送経路を追加するか削除するかの判定を行なう判定部と、
該負荷演算部で求められた負荷を複数の伝送経路間で均等化する負荷均等化部とをそなえて構成されたことを特徴とする、伝送経路制御装置。
【０１２６】
［付記２] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置に設けられる装置であって、
該発信元通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、
該負荷演算部で求められた負荷情報に基づいて、伝送経路の追加・削除判定を行なう判定部と、
該負荷演算部で求められた負荷を複数の伝送経路間で均等化する負荷均等化部とをそなえて構成されたことを特徴とする、伝送経路制御装置。
【０１２７】
［付記３] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置以外の通信装置に設けられる装置であって、
該通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知部とをそなえて構成されたことを特徴とする、伝送経路制御装置。
【０１２８】
［付記４] 該トラヒック特性収集部が、収集したトラヒック特性に関する情報を平滑化する手段を有していることを特徴とする、付記１〜３のいずれか一項に記載の伝送経路制御装置。
［付記５] 該トラヒック特性収集部が、収集したトラヒック特性値を基に、該通信装置に接続された各伝送経路の使用率を判定する手段を有していることを特徴とする、付記４記載の伝送経路制御装置。
【０１２９】
［付記６] 該トラヒック特性収集部における該平滑化手段が、該使用率判定手段により判定された該使用率を平滑化するように構成されていることを特徴とする、付記５記載の伝送経路制御装置。
［付記７] 該トラヒック特性収集部における該平滑化手段が、収集したトラヒック特性値を平滑化するように構成されるとともに、
該トラヒック特性収集部が、該平滑化手段により平滑化されたトラヒック特性値を基に、該通信装置に接続された各伝送経路の使用率を判定する手段を有していることを特徴とする、付記４記載の伝送経路制御装置。
【０１３０】
［付記８] 該トラヒック特性収集部が、収集したトラヒック特性値の最大値をトラヒック特性値の代表値とする手段を有していることを特徴とする、付記１〜３のいずれか一項に記載の伝送経路制御装置。
［付記９] 該トラヒック特性通知部が、トラヒック特性に関する情報をルーティングプロトコルが装備するパケットを利用して通知する手段を有していることを特徴とする、付記１又は付記３に記載の伝送経路制御装置。
【０１３１】
［付記１０] 該トラヒック特性通知部が、トラヒック特性に関する情報を一定周期毎に通知する手段を有していることを特徴とする、付記１，３，９のいずれか一項に記載の伝送経路制御装置。
［付記１１] 該トラヒック特性通知部が、トラヒック特性に関する情報をRSVPのメッセージを拡張して通知する手段を有していることを特徴とする、付記１又は付記３に記載の伝送経路制御装置。
【０１３２】
［付記１２] 該トラヒック特性収集部が、トラヒック特性を収集するフローの束の単位を、ラベルスイッチ型通信装置で使用するラベル単位で収集する手段を有していることを特徴とする、付記１〜３のいずれか一項に記載の伝送経路制御装置。
［付記１３] 該発信元通信装置に設けられる該トラヒック特性収集部が、該発信元通信装置に接続された各伝送経路の使用率を、該中継通信装置から収集した該中継通信装置に接続されている伝送経路の使用率に関する情報を基に判定する手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３３】
［付記１４] 該発信元通信装置に設けられる該トラヒック特性収集部が、該発信元通信装置に接続された各伝送経路の使用率を、該中継通信装置から収集した該中継通信装置に接続されている伝送経路の平均使用率及び最大使用率の少なくとも一方を基に判定するように構成されていることを特徴とする、付記１３記載の伝送経路制御装置。
【０１３４】
［付記１５] 該発信元通信装置に設けられる該トラヒック特性収集部が、各伝送経路が輻輳しているかどうかを一定周期毎に判定する手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
［付記１６] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３５】
［付記１７] 該実効的負荷演算手段が、該実効的な負荷を演算する際に、該実効的な負荷の上限値を設定するように構成されていることを特徴とする、付記１６記載の伝送経路制御装置。
［付記１８] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有するとともに、
該発信元通信装置に設けられる該判定部が、該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率を求める手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３６】
［付記１９] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、
該発信元通信装置に設けられる該判定部が、
該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段を有するとともに、
該演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１３７】
［付記２０] 該判定部における該演算手段が、該パイプ使用率，該パイプ使用率の時間当たりの変化率，該パイプ使用率の一定時間における積算量のうちの少なくとも一つを求めるように構成されるとともに、
該伝送経路追加・削除判定手段が、該演算手段で得られた上記のパイプ使用率，変化率及び積算量のうちの少なくとも一つに基づいて、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、付記１９記載の伝送経路制御装置。
【０１３８】
［付記２１] 該発信元通信装置に設けられる該判定部が、該演算手段で得られたパイプ使用率と第１の基準値、該演算手段で得られた変化率と第２の基準値、該演算手段で得られた該積算量と第３の基準値のうちの少なくともいずれか一組の比較を行ない、この比較結果に応じて、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、付記２０記載の伝送経路制御装置。
【０１３９】
［付記２２] 該発信元通信装置に設けられる該判定部が、該演算手段で得られた上記のパイプ使用率，変化率及び積算量のうちの少なくともいずれか一つが対応する経路追加用基準値を超えていた場合に、新たな伝送経路を追加する旨の判定をするように構成されていることを特徴とする、付記２１記載の伝送経路制御装置。
【０１４０】
［付記２３] 該発信元通信装置に設けられる該判定部が、該演算手段で得られた上記のパイプ使用率，変化率及び積算量のうちの少なくともいずれか一つが対応する経路削除用基準値を下回っていた場合に、負荷が少ない伝送経路を削除する旨の判定をするように構成されていることを特徴とする、付記２１記載の伝送経路制御装置。
【０１４１】
［付記２４] 該演算手段が、微小間隔をおいて得られた２つのパイプ使用率の差分値、及び、ある時点における該パイプ使用率の微分値の少なくともいずれか一方を、該パイプ使用率の時間当たりの該変化率として求めるように構成されていることを特徴とする、付記１９〜２３のいずれか一項に記載の伝送経路制御装置。
【０１４２】
［付記２５] 該演算手段が、該パイプ使用率が一定時間内にある基準値を超えた回数、及び、該パイプ使用率の一定時間における積分値の少なくともいずれか一方を、該パイプ使用率の一定時間における該積算量として求めるように構成されていることを特徴とする、付記１９〜２３のいずれか一項に記載の伝送経路制御装置。
【０１４３】
［付記２６] 該発信元通信装置に設けられる該判定部が、
該負荷演算部で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、
該削除候補選択手段により選択された該削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、
該負荷予測手段により予測された他の伝送経路の負荷を所定の基準値と比較し、該比較結果に応じて、該削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成されていることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１４４】
［付記２７] 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、
該発信元通信装置に設けられる該判定部が、
該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段と、
該演算手段で得られたパイプ使用率に関する情報に基づき、上記の選択手段，予測手段及び決定手段の動作トリガをかけるトリガ手段とをさらにそなえて構成されていることを特徴とする、付記２６記載の伝送経路制御装置。
【０１４５】
［付記２８] 該発信元通信装置に設けられる該負荷均等化部が、該中継通信装置において発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有していることを特徴とする、付記１又は付記２に記載の伝送経路制御装置。
【０１４６】
［付記２９] 該発信元通信装置に設けられる該負荷均等化部が、該移動実効帯域演算手段で求められた移動すべき実効帯域に比例して、該発信元通信装置に流入するパケットを複数の伝送経路に振り分ける手段を有していることを特徴とする、付記２８記載の伝送経路制御装置。
［付記３０] 該発信元通信装置に設けられる該負荷均等化部が、各パケットに含まれるアドレスを基にハッシュ関数を用いた演算を行ない、この演算結果に基づいて、ランダムにトラヒックフローを振り分けるように構成されていることを特徴とする、付記２９記載の伝送経路制御装置。
【０１４７】
［付記３１] 該発信元通信装置に設けられる該負荷均等化部が、該ハッシュ関数としてＣＲＣ（cyclic redundancy check）を用いた演算を行なうことを特徴とする、付記３０記載の伝送経路制御装置。
［付記３２] 該発信元通信装置に設けられる該負荷均等化部が、該ハッシュ関数による演算として、入力値の各ビット値に対して位置の入れ替え及び論理演算の少なくとも一方を行なうことにより、ランダムな整数値を作成することを特徴とする、付記３０記載の伝送経路制御装置。
【０１４８】
［付記３３] 該発信元通信装置に設けられる該負荷均等化部が、該ハッシュ関数の入力値として、パケットに含まれるアドレス以外の制御値を併せて用いることを特徴とする、付記３０記載の伝送経路制御装置。
［付記３４] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置以外の他の通信装置において、
該他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
該トラヒック特性収集ステップで収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知ステップとをそなえるとともに、
上記発信元通信装置において、
該発信元通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
該トラヒック特性収集ステップで収集されたトラヒック特性及び該他の通信装置から得られたトラヒック特性の一方又は両方に基づいて負荷を演算する負荷演算ステップと、
該負荷演算ステップで求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定ステップと、
該負荷演算ステップで求められた負荷を複数の伝送経路間で均等化する負荷均等化ステップとをそなえて構成されたことを特徴とする、伝送経路制御方法。
【０１４９】
［付記３５] 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記通信装置で使用すべく、
該通信装置又と他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集手段と、
該トラヒック特性収集手段で収集された該トラヒック特性を他の通信装置に通知するトラヒック特性通知手段と、
該トラヒック特性収集手段で収集された該トラヒック特性に基づいて負荷を演算する負荷演算手段と、
該負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定手段と、
該負荷演算手段で求められた負荷を複数の伝送経路間で均等化する負荷均等化手段として、上記通信装置を機能させるための伝送経路制御プログラムを記録した媒体。
【０１５０】
【発明の効果】
以上詳述したように、本発明によれば、各通信装置においてトラヒック特性の観測機能およびその特性値の通知機能を持たせて、負荷分散の起点となる通信装置（発信元通信装置）において、終点となる通信装置（着信先通信装置)までの複数のパスの帯域管理をダイナミックに行なうことができ、その結果、空き帯域に合わせた負荷分散が可能となる。すなわち、ＩＰネットワーク内の通信装置において、起点となる通信装置（発信元通信装置) から終点となる通信装置（着信先通信装置)までに複数のルート（伝送経路)を設定し、設定されたルート間で負荷の分散を行なえるので、ネットワークトポロジーに関係なく、また伝送経路の種類によらないで、インターネット等のネットワーク内でトラヒックエンジニアリングを可能にできるのである。
【０１５１】
また、トラヒック特性収集部に、収集したトラヒック特性に関する情報を平滑化する手段を設けることができ、このようにすれば、急激なトラヒック変動による 影響を少なくすることができる。
さらに、トラヒック特性収集部に、収集したトラヒック特性値を基に、通信装置に接続された各伝送経路の使用率を判定する手段を設けることができ、このようにすれば、各伝送経路の使用状態を詳細に把握することが可能となる。この場合、平滑化手段が、使用率判定手段により判定された使用率を平滑化するように構成すれば、トラヒック変動による影響を排して各伝送経路の使用状態を正確に把握することができる。また、トラヒック特性収集部に、平滑化手段により平滑化されたトラヒック特性値を基に、通信装置に接続された各伝送経路の使用率を判定する手段を設けても、同様の効果を得ることができる。
【０１５２】
更に、トラヒック特性収集部に、収集したトラヒック特性値の最大値をトラヒック特性値の代表値とする手段を設ければ、伝送経路選択制御を確実に行なうことができる。
また、トラヒック特性通知部に、トラヒック特性に関する情報をルーティングプロトコルが装備するパケットを利用して通知する手段を設けることもでき、このようにすれば、既存のプロトコルを活用でき、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【０１５３】
さらに、トラヒック特性通知部に、トラヒック特性に関する情報を一定周期毎に通知する手段を設けることができ、このようにすれば、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
また、トラヒック特性通知部に、トラヒック特性に関する情報をRSVPのメッセージを拡張して通知する手段を設けることができ、このようにすれば、既存のプロトコルを活用でき、これにより新規に専用のルーティングプロトコルを用意する必要がなく、コスト等の低減に寄与しうる。
【０１５４】
さらに、トラヒック特性収集部に、トラヒック特性を収集するフローの束の単位を、ラベルスイッチ型通信装置で使用するラベル単位で収集する手段を設けることができ、このようにすれば、きめ細かくトラヒック特性を収集することが可能になり、収集精度の向上に寄与する。
また、発信元通信装置に設けられるトラヒック特性収集部に、伝送経路の使用率を伝送経路の平均使用率を基に判定する手段を設けることができ、このようにすれば、ネットワークの使用効率の向上に寄与しうる。
【０１５５】
さらに、発信元通信装置に設けられるトラヒック特性収集部に、伝送経路の使用率を伝送経路の最大使用率を基に判定する手段を設けることができ、このようにすれば、伝送経路選択制御を確実に行なうことができる。
また、発信元通信装置に設けられるトラヒック特性収集部に、各伝送経路が輻輳しているかどうかを一定周期毎に判定する手段を設けることができ、このようにすれば、演算等を実行するＣＰＵ等の演算装置にかかる演算負荷を軽減できる。
【０１５６】
さらに、発信元通信装置に設けられる負荷演算部に、中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を設けることができ、このようにすれば、直接的に負荷を計測しなくても、簡素な手法で、実効的な負荷を推定できる。その際、実効的な負荷の上限値を設定することもでき、このようにすれば、過剰な量の負荷推定を避けることができ、これにより適切な伝送経路選択制御を行なえる。
【０１５７】
また、発信元通信装置に設けられる判定部に、実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率を求める手段を設けることもでき、このようにすれば、不必要に新しい伝送経路を追加することを防止できるほか、ネットワークの有効利用にも寄与しうる。
【０１５８】
さらに、演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成することができ、このようにすれば、現在の伝送経路の負荷を考慮して適切に伝送経路の追加及び削除を行なうことが可能となり、効率的に負荷の分散を図ることができる。この場合、伝送経路追加・削除判定手段が、演算手段で得られたパイプ使用率，変化率及び積算量のうちの少なくとも一つに基づいて、伝送経路を追加するか削除するかの判定を行なうように構成することにより、ネットワークの環境やハードウェアの性能に応じて適切な経路選択が可能となる。
【０１５９】
また、演算手段で得られたこれらのパイプ使用率，変化率及び積算量を基準値と比較し、この比較結果に応じて伝送経路を追加するか削除するかの判定を行なうように構成することができ、このようにすれば、アップツーデートに最適な経路選択を実施できる。
さらに、演算手段が、上記のパイプ使用率の変化率として、パイプ使用率の差分値や微分値を求めるように構成したり、上記のパイプ使用率の積算量として、パイプ使用率が基準値を超えた回数やパイプ使用率の積分値を求めたりするように構成してもよく、このようにすれば、ネットワークの環境やハードウェアの性能に応じて計算量を変えることができ、効率的な経路選択が可能となる。
【０１６０】
また、判定部が、負荷演算部で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、選択された削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、予測された他の伝送経路の負荷を所定の基準値と比較し、この比較結果に応じて、削除候補の伝送経路を削除するか否かを決定する手段とをそなえてもよく、このようにすれば、各伝送経路を削除した場合の影響を考慮して、削除する伝送経路を適切に選択することが可能となる。この場合、演算手段で得られたパイプ使用率に関する情報を動作トリガとして用いることにより、ネットワーク全体の状況に応じて効率的に伝送経路を削除できる。
【０１６１】
また、発信元通信装置に設けられる負荷均等化部に、中継通信装置において発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を設けることができ、このようにすれば、伝送経路の帯域を考慮に入れた負荷の均等化を実施できる。
【０１６２】
さらに、発信元通信装置に設けられる負荷均等化部に、移動実効帯域演算手段で求められた移動すべき実効帯域に比例して、発信元通信装置に流入するパケットを複数の伝送経路に振り分ける手段を設けることができ、このようにすれば、的確な負荷の均等化を実施できる。
また、発信元通信装置に設けられる負荷均等化部を、アドレスを基にハッシュ関数を用いた演算を行ない、この演算結果に基づいて、ランダムにトラヒックフローを振り分けるように構成することもでき、このようにすれば、簡素な計算によって、的確にトラヒックフローを振り分けることができる。この場合、負荷均等化部がハッシュ関数として、ＣＲＣ（cyclic redundancy check）を用いた演算や、入力値のビット位置の入れ替えによりランダムな整数値を作成する演算を行なうように構成したり、ハッシュ関数の入力値として、パケットに含まれるアドレス以外の制御値を併せて用いるように構成したりすることにより、効率的且つ効果的なトラヒックフローの振り分けを行なうことができる。
【図面の簡単な説明】
【図１】（ａ），（ｂ）は本発明の原理説明図である。
【図２】（ａ），（ｂ）はＭＰＬＳネットワークを説明する図である。
【図３】ＭＰＬＳで用いるラベルを説明する図である。
【図４】ＭＰＬＳで用いるラベルを説明する図である。
【図５】ＬＳＰを説明する図である。
【図６】ＲＳＶＰ−ＬＳＰ−Ｔｕｎｎｅｌのメッセージの流れを説明する図である。
【図７】本発明の一実施形態に適用されるＭＰＬＳネットワークを説明する図である。
【図８】本発明の一実施形態としてのＭＰＬＳルータの機能ブロック図である。
【図９】本発明の一実施形態としてのＭＰＬＳルータのトラヒックエンジニアリング部の詳細を示す機能ブロック図である。
【図１０】実効負荷を説明する図である。
【図１１】移動する実効帯域を説明する図である。
【図１２】負荷調整要領を説明する図である。
【図１３】ハッシュ関数の一例を説明する図である。
【図１４】負荷調整実験ネットワークを説明する図である。
【図１５】負荷調整性能評価結果の一例を説明する図である。
【図１６】負荷調整性能評価結果の他の例を説明する図である。
【符号の説明】
１ 通信装置
１Ｓ 発信元通信装置
１Ｄ 着信先通信装置
１Ｒ 中継通信装置
２−ｉ 伝送経路
３，３Ａ トラヒック特性収集部
３Ｂ トラヒック特性受信部
４ トラヒック特性通知部
５ 負荷演算部
６ 判定部
７ 負荷均等化部
１１，１１’ ＭＰＬＳルータ（通信装置）
１１Ｓ 発信元ＭＰＬＳルータ（発信元通信装置）
１１Ｄ，１１Ｄ’ 着信先ＭＰＬＳルータ（着信先通信装置）
１１Ｒ，１１Ｒ’ 中継ＭＰＬＳルータ（中継通信装置）
１２−ｉ 伝送経路
１１１ ＩＰパケット転送部
１１２ ルーティングプロトコル部
１１３ パス選択部
１１３Ａ リンク状態データベース
１１４ ＬＳＰ選択部
１１４Ａ 代替経路情報データベース１１４Ａ
１１５ ＬＳＰ設定部
１１６ トラヒックエンジニアリング部
１１６Ａ 負荷観測部
１１６Ｂ トラヒック特性値計算部
１１６Ｃ トラヒックエンジニアリング計算部
１１６Ｄ 負荷調整部
１２０Ｒ−１〜１２０Ｒ−５ ＬＳＲ
１２１ 負荷発生装置
１２２ 負荷受信装置
Claims (9)
- 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記通信装置に設けられる装置であって、
該通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集されたトラヒック特性を他の通信装置に通知するトラヒック特性通知部と、
該トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、
該負荷演算部で求められた負荷情報に基づいて、伝送経路を追加するか削除するかの判定を行なう判定部と、
該負荷演算部で求められた負荷を前記発信元通信装置と前記着信先通信装置との間に設定された複数の伝送経路間で均等化する負荷均等化部とをそなえて構成されたことを特徴とする、伝送経路制御装置。 - 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置に設けられる装置であって、
該発信元通信装置又は他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集部と、
該トラヒック特性収集部で収集されたトラヒック特性に基づいて負荷を演算する負荷演算部と、
該負荷演算部で求められた負荷情報に基づいて、伝送経路の追加・削除判定を行なう判定部と、
該負荷演算部で求められた負荷を前記発信元通信装置と前記着信先通信装置との間に設定された複数の伝送経路間で均等化する負荷均等化部とをそなえて構成されたことを特徴とする、伝送経路制御装置。 - 該トラヒック特性収集部が、収集したトラヒック特性に関する情報を平滑化する手段を有していることを特徴とする、請求項１又は請求項２に記載の伝送経路制御装置。
- 該発信元通信装置に設けられる該トラヒック特性収集部が、該発信元通信装置に接続された各伝送経路の使用率を、該中継通信装置から収集した該中継通信装置に接続されている伝送経路の使用率に関する情報を基に判定する手段を有していることを特徴とする、請求項１又は請求項２に記載の伝送経路制御装置。
- 該発信元通信装置に設けられる該負荷演算部が、該中継通信装置において発生したパケット廃棄数を考慮して、実効的な負荷を演算する手段を有し、且つ、
該発信元通信装置に設けられる該判定部が、
該実効的負荷演算手段で得られた実効的な負荷から実効帯域を演算し、全ての伝送経路を一つの仮想的なパイプとみなして、その使用率に関する情報を求める演算手段を有するとともに、
該演算手段で得られたパイプ使用率に関する情報に基づき、伝送経路を追加するか削除するかの判定を行なうように構成されていることを特徴とする、請求項１又は請求項２に記載の伝送経路制御装置。 - 該発信元通信装置に設けられる該判定部が、
該負荷演算部で求められた負荷情報に基づいて、削除対象となる伝送経路の候補を選択する手段と、
該削除候補選択手段により選択された該削除候補の伝送経路を削除した場合における他の伝送経路の負荷を予測する手段と、
該負荷予測手段により予測された他の伝送経路の負荷を所定の基準値と比較し、該比較結果に応じて、該削除候補の伝送経路を削除するか否かを決定する手段とをそなえて構成されていることを特徴とする、請求項１又は請求項２に記載の伝送経路制御装置。 - 該発信元通信装置に設けられる該負荷均等化部が、該中継通信装置において発生したパケット廃棄数を考慮して得られる実効的な負荷から得られる実効帯域に基づいて全伝送経路について求められた平均実効帯域から、各伝送経路での移動すべき実効帯域を求める移動実効帯域演算手段を有していることを特徴とする、請求項１又は請求項２に記載の伝送経路制御装置。
- 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記発信元通信装置以外の他の通信装置において、
該他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
該トラヒック特性収集ステップで収集された該トラヒック特性を該発信元通信装置に通知するトラヒック特性通知ステップとをそなえるとともに、
上記発信元通信装置において、
該発信元通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集ステップと、
該トラヒック特性収集ステップで収集されたトラヒック特性及び該他の通信装置から得られたトラヒック特性の一方又は両方に基づいて負荷を演算する負荷演算ステップと、
該負荷演算ステップで求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定ステップと、
該負荷演算ステップで求められた負荷を前記発信元通信装置と前記着信先通信装置との間に設定された複数の伝送経路間で均等化する負荷均等化ステップとをそなえて構成されたことを特徴とする、伝送経路制御方法。 - 発信元通信装置と、着信先通信装置と、上記の発信元通信装置と着信先通信装置との間に設定可能な複数の伝送経路と、上記伝送経路のいずれかに介装される中継通信装置とをそなえてなるインターネットプロトコルネットワークを構成する上記通信装置で使用すべく、
該通信装置又と他の通信装置に接続された伝送経路のトラヒック特性を収集するトラヒック特性収集手段と、
該トラヒック特性収集手段で収集された該トラヒック特性を他の通信装置に通知するトラヒック特性通知手段と、
該トラヒック特性収集手段で収集された該トラヒック特性に基づいて負荷を演算する負荷演算手段と、
該負荷演算手段で求められた負荷情報に基づいて伝送経路を追加するか削除するかの判定を行なう判定手段と、
該負荷演算手段で求められた負荷を前記発信元通信装置と前記着信先通信装置との間に設定された複数の伝送経路間で均等化する負荷均等化手段として、上記通信装置を機能させるための伝送経路制御プログラムを記録した媒体。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000376615A JP4150159B2 (ja) | 2000-03-01 | 2000-12-11 | 伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 |
| EP01104498A EP1130849B1 (en) | 2000-03-01 | 2001-03-01 | Transmission path controlling apparatus, method and program |
| US09/797,419 US7136357B2 (en) | 2000-03-01 | 2001-03-01 | Transmission path controlling apparatus and transmission path controlling method as well as medium having transmission path controlling program recorded thereon |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000-56254 | 2000-03-01 | ||
| JP2000056254 | 2000-03-01 | ||
| JP2000376615A JP4150159B2 (ja) | 2000-03-01 | 2000-12-11 | 伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001320420A JP2001320420A (ja) | 2001-11-16 |
| JP4150159B2 true JP4150159B2 (ja) | 2008-09-17 |
Family
ID=26586547
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000376615A Expired - Fee Related JP4150159B2 (ja) | 2000-03-01 | 2000-12-11 | 伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7136357B2 (ja) |
| EP (1) | EP1130849B1 (ja) |
| JP (1) | JP4150159B2 (ja) |
Families Citing this family (133)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0026703D0 (en) | 2000-11-01 | 2000-12-20 | Parc Technologies Ltd | Traffic flow optimisation system |
| US7230924B2 (en) * | 2001-03-28 | 2007-06-12 | At&T Corp. | Method and apparatus for communications traffic engineering |
| AU2002304386A1 (en) * | 2001-06-27 | 2003-03-03 | Nokia Corporation | Method and system for efficient management and transport of traffic over a network |
| JP3857105B2 (ja) * | 2001-10-30 | 2006-12-13 | 富士通株式会社 | データ転送装置 |
| US7856599B2 (en) * | 2001-12-19 | 2010-12-21 | Alcatel-Lucent Canada Inc. | Method and system for IP link management |
| US8040869B2 (en) * | 2001-12-19 | 2011-10-18 | Alcatel Lucent | Method and apparatus for automatic discovery of logical links between network devices |
| US7515546B2 (en) * | 2001-12-19 | 2009-04-07 | Alcatel-Lucent Canada Inc. | Method and apparatus for automatic discovery of network devices with data forwarding capabilities |
| US7499410B2 (en) | 2001-12-26 | 2009-03-03 | Cisco Technology, Inc. | Fibre channel switch that enables end devices in different fabrics to communicate with one another while retaining their unique fibre channel domain—IDs |
| US20040136371A1 (en) * | 2002-01-04 | 2004-07-15 | Muralidhar Rajeev D. | Distributed implementation of control protocols in routers and switches |
| CA2415184C (en) * | 2002-01-15 | 2009-06-30 | Nippon Telegraph And Telephone Corporation | Node, packet communication network, packet communication method, and program |
| CA2416659C (en) | 2002-01-22 | 2007-01-16 | Nippon Telegraph And Telephone Corporation | Capacity variable link apparatus and capacity variable link setting method |
| CA2418384A1 (en) * | 2002-02-06 | 2003-08-06 | Nippon Telegraph And Telephone Corporation | Optical network, optical cross-connect apparatus, photonic-ip network, and node |
| CA2419477C (en) * | 2002-02-28 | 2010-05-04 | Nippon Telegraph And Telephone Corporation | Node used in photonic network, and photonic network |
| JP2003256310A (ja) * | 2002-03-05 | 2003-09-12 | Nec Corp | サーバ負荷分散システム、サーバ負荷分散装置、コンテンツ管理装置、及びサーバ負荷分散プログラム |
| JP3898535B2 (ja) * | 2002-03-14 | 2007-03-28 | 株式会社日立製作所 | データ転送装置 |
| US7616637B1 (en) | 2002-04-01 | 2009-11-10 | Cisco Technology, Inc. | Label switching in fibre channel networks |
| US7477657B1 (en) * | 2002-05-08 | 2009-01-13 | Juniper Networks, Inc. | Aggregating end-to-end QoS signaled packet flows through label switched paths |
| US7280472B2 (en) * | 2002-06-04 | 2007-10-09 | Lucent Technologies Inc. | Protection switching at a network node |
| US7206288B2 (en) | 2002-06-12 | 2007-04-17 | Cisco Technology, Inc. | Methods and apparatus for characterizing a route in fibre channel fabric |
| AU2003232413A1 (en) * | 2002-06-24 | 2004-01-06 | International Business Machines Corporation | Load balancing in data networks |
| JP3923863B2 (ja) * | 2002-07-09 | 2007-06-06 | 株式会社日立製作所 | リクエストルータ装置 |
| JP3715596B2 (ja) | 2002-07-11 | 2005-11-09 | 富士通株式会社 | 広域負荷分散制御システム |
| JP2004140776A (ja) * | 2002-07-12 | 2004-05-13 | Nec Corp | ネットワークにおけるフレーム転送方法及びノード、フレーム転送プログラム |
| JP3521904B2 (ja) * | 2002-08-22 | 2004-04-26 | 日本電気株式会社 | イーサネット（ｒ）におけるフレーム転送方法及びノード |
| CN100459534C (zh) * | 2002-10-07 | 2009-02-04 | 日本电信电话株式会社 | 分层网络节点及通过该节点构成的网络、节点和分层网络 |
| FR2846170A1 (fr) * | 2002-10-18 | 2004-04-23 | Overnetworks | Procede d'optimisation du trafic sur internet. |
| US7433326B2 (en) | 2002-11-27 | 2008-10-07 | Cisco Technology, Inc. | Methods and devices for exchanging peer parameters between network devices |
| CN1310473C (zh) * | 2003-01-07 | 2007-04-11 | 华为技术有限公司 | 基于同步数字传送网的数据传送方法 |
| JP3769544B2 (ja) | 2003-01-31 | 2006-04-26 | 富士通株式会社 | 伝送帯域制御装置 |
| JPWO2004073269A1 (ja) * | 2003-02-13 | 2006-06-01 | 富士通株式会社 | 伝送システム，配信経路制御装置，負荷情報収集装置および配信経路制御方法 |
| US20050195834A1 (en) * | 2003-03-31 | 2005-09-08 | Shunsuke Kikuchi | Load distribution system |
| JPWO2004088940A1 (ja) * | 2003-03-31 | 2006-07-06 | 富士通株式会社 | 負荷分散システム |
| EP2367377B1 (en) | 2003-04-11 | 2015-05-13 | Fujitsu Limited | Mobile communication system of data dispersion |
| US8428117B2 (en) | 2003-04-24 | 2013-04-23 | Fujitsu Semiconductor Limited | Image encoder and image encoding method |
| JP2004336209A (ja) * | 2003-05-01 | 2004-11-25 | Ntt Docomo Inc | トラヒック分散制御装置、トラヒック分散制御方法 |
| US7872976B2 (en) * | 2003-05-02 | 2011-01-18 | Alcatel-Lucent Usa Inc. | System and method for multi-protocol label switching network tuning |
| DE10325017A1 (de) * | 2003-06-03 | 2005-01-20 | Siemens Ag | Statistisches Verfahren für eine Verkehrsverteilung entsprechend Verkehrs-Verteilgewichten in einem paketorientierten Netz mit Mehrwegerouting |
| US20050008014A1 (en) * | 2003-07-07 | 2005-01-13 | Debasis Mitra | Techniques for network traffic engineering |
| US8085765B2 (en) * | 2003-11-03 | 2011-12-27 | Intel Corporation | Distributed exterior gateway protocol |
| WO2005071901A1 (fr) * | 2003-12-26 | 2005-08-04 | France Telecom | Procede de mise a jour d'une table d'informations de routage et routeur correspondant |
| DE102004003548B3 (de) * | 2004-01-23 | 2005-06-30 | Siemens Ag | Optimierung der Verkehrsverteilung bei Mehrwegerouting |
| DE102004007977A1 (de) * | 2004-02-18 | 2005-06-02 | Siemens Ag | Kommunikationssystem und Verfahren zum Optimieren der Auslastung eines Kommunikationssystems mit einer Vielzahl von Netzkoppelelementen |
| US8407365B2 (en) * | 2004-05-24 | 2013-03-26 | Tellabs Operations, Inc. | Method and system for autodiscovery of a network path |
| JP4390649B2 (ja) * | 2004-07-14 | 2009-12-24 | 富士通株式会社 | ネットワークループ検知装置 |
| US7916628B2 (en) | 2004-11-01 | 2011-03-29 | Cisco Technology, Inc. | Trunking for fabric ports in fibre channel switches and attached devices |
| US7496105B2 (en) * | 2004-11-05 | 2009-02-24 | Cisco Technology, Inc. | System and method for retrieving computed paths from a path computation element using encrypted objects |
| US7558276B2 (en) * | 2004-11-05 | 2009-07-07 | Cisco Technology, Inc. | System and method for retrieving computed paths from a path computation element using a path key |
| US7649844B2 (en) | 2004-12-29 | 2010-01-19 | Cisco Technology, Inc. | In-order fibre channel packet delivery |
| US8804653B2 (en) * | 2005-01-13 | 2014-08-12 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for call handoff between circuit switched and packet data wireless networks |
| US9306831B2 (en) * | 2005-02-14 | 2016-04-05 | Cisco Technology, Inc. | Technique for efficient load balancing of TE-LSPs |
| US20060256752A1 (en) * | 2005-05-10 | 2006-11-16 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for call handoff from packet data wireless network to circuit switched wireless network |
| US9654383B2 (en) | 2005-08-17 | 2017-05-16 | Avaya Inc. | Route optimization using measured congestion |
| US8369220B1 (en) | 2005-08-17 | 2013-02-05 | Avaya Inc. | Routing a flow of elastic traffic |
| US8719255B1 (en) * | 2005-08-23 | 2014-05-06 | Amazon Technologies, Inc. | Method and system for determining interest levels of online content based on rates of change of content access |
| JP4606333B2 (ja) * | 2005-09-20 | 2011-01-05 | 富士通株式会社 | ルーティング制御方法 |
| US7697528B2 (en) | 2005-11-01 | 2010-04-13 | Nortel Networks Limited | Multilink trunking for encapsulated traffic |
| US7590123B2 (en) * | 2005-11-22 | 2009-09-15 | Cisco Technology, Inc. | Method of providing an encrypted multipoint VPN service |
| US7630372B1 (en) | 2005-12-30 | 2009-12-08 | At&T Corp. | Method and apparatus for providing access and egress uniform resource identifiers for routing |
| JP4616785B2 (ja) | 2006-03-28 | 2011-01-19 | 富士通株式会社 | サービス品質管理装置及びサービス品質管理方法 |
| US9542642B2 (en) | 2006-04-06 | 2017-01-10 | Samuel F. Wood | Packet data neural network system and method |
| US7796511B2 (en) * | 2006-04-06 | 2010-09-14 | Wood Samuel F | Self-routed layer 4 packet network system and method |
| WO2008004188A1 (en) | 2006-07-05 | 2008-01-10 | Nxp B.V. | Electronic device, system on chip and method for monitoring a data flow |
| JP5179031B2 (ja) * | 2006-09-13 | 2013-04-10 | 株式会社日立製作所 | 空きポートを有効に活用したストレージシステム |
| JP4677978B2 (ja) * | 2006-12-15 | 2011-04-27 | Ｋｄｄｉ株式会社 | ネットワーク管理装置及びプログラム |
| JP5071165B2 (ja) | 2007-03-19 | 2012-11-14 | 日本電気株式会社 | 経路多重化通信システム、通信ノード及び通信方法 |
| US8065429B2 (en) * | 2007-06-28 | 2011-11-22 | Nokia Corporation | System, apparatus and method for associating an anticipated success indication with data delivery |
| US20090086633A1 (en) * | 2007-10-02 | 2009-04-02 | Chenjiang Hu | Using A Link-State Advertisement To Inform Nodes Of The Availability Of Traffic Management Resources |
| US20090287120A1 (en) | 2007-12-18 | 2009-11-19 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
| US9717896B2 (en) | 2007-12-18 | 2017-08-01 | Gearbox, Llc | Treatment indications informed by a priori implant information |
| US8636670B2 (en) | 2008-05-13 | 2014-01-28 | The Invention Science Fund I, Llc | Circulatory monitoring systems and methods |
| CN101534239B (zh) * | 2008-03-13 | 2012-01-25 | 华为技术有限公司 | 路由安装方法和设备 |
| JP5304008B2 (ja) * | 2008-04-23 | 2013-10-02 | 日本電気株式会社 | 通信システム |
| JP5111236B2 (ja) * | 2008-05-22 | 2013-01-09 | 株式会社日立製作所 | データ転送システム |
| JP4957660B2 (ja) * | 2008-06-20 | 2012-06-20 | 富士通株式会社 | ラベルスイッチングネットワークにおける通信装置 |
| JP5239783B2 (ja) * | 2008-11-27 | 2013-07-17 | 富士通株式会社 | 経路計算方法及びノード装置 |
| US7983163B2 (en) * | 2008-12-11 | 2011-07-19 | International Business Machines Corporation | System and method for implementing adaptive load sharing to balance network traffic |
| JP5223717B2 (ja) * | 2009-02-16 | 2013-06-26 | 富士通株式会社 | 経路計算装置及び経路計算方法 |
| US20110063986A1 (en) | 2009-09-14 | 2011-03-17 | International Business Machines Corporation | System and method for load balancing traffic in a mpls network |
| US9185024B2 (en) * | 2010-03-08 | 2015-11-10 | The Chinese University Of Hong Kong | Path selection in streaming video over multi-overlay application layer multicast |
| JP5561006B2 (ja) * | 2010-08-05 | 2014-07-30 | 富士通株式会社 | データ転送装置、データ受信装置、データ転送方法、およびデータ転送プログラム |
| US8553562B2 (en) * | 2010-09-08 | 2013-10-08 | Telefonaktiebolaget L M Ericsson (Publ) | Automated traffic engineering for multi-protocol label switching (MPLS) with link utilization as feedback into the tie-breaking mechanism |
| US8553584B2 (en) * | 2010-09-08 | 2013-10-08 | Telefonaktiebolaget L M Ericsson (Publ) | Automated traffic engineering for 802.1AQ based upon the use of link utilization as feedback into the tie breaking mechanism |
| JP5621576B2 (ja) * | 2010-12-20 | 2014-11-12 | 日本電気株式会社 | パケット中継装置 |
| KR101309582B1 (ko) | 2011-09-05 | 2013-09-17 | 에스케이텔레콤 주식회사 | 멀티 네트워크에서의 로드 밸런싱을 위한 사용자 단말 및 그 방법 |
| US9608899B2 (en) * | 2011-11-21 | 2017-03-28 | Qualcomm Incorporated | Packet-based aggregation of data streams across disparate networking interfaces |
| JP5974665B2 (ja) * | 2012-06-22 | 2016-08-23 | 富士通株式会社 | 情報処理システム、中継装置、情報処理装置および情報処理方法 |
| US10261938B1 (en) | 2012-08-31 | 2019-04-16 | Amazon Technologies, Inc. | Content preloading using predictive models |
| US9369371B2 (en) | 2012-10-05 | 2016-06-14 | Cisco Technologies, Inc. | Method and system for path monitoring using segment routing |
| US9049233B2 (en) | 2012-10-05 | 2015-06-02 | Cisco Technology, Inc. | MPLS segment-routing |
| JP5969352B2 (ja) * | 2012-10-23 | 2016-08-17 | 日本電信電話株式会社 | 信号処理システム |
| US9094337B2 (en) * | 2012-12-21 | 2015-07-28 | Cieno Corporation | Source identification preservation in multiprotocol label switching networks |
| US10447575B1 (en) | 2012-12-27 | 2019-10-15 | Sitting Man, Llc | Routing methods, systems, and computer program products |
| US10397100B1 (en) | 2012-12-27 | 2019-08-27 | Sitting Man, Llc | Routing methods, systems, and computer program products using a region scoped outside-scope identifier |
| US10587505B1 (en) | 2012-12-27 | 2020-03-10 | Sitting Man, Llc | Routing methods, systems, and computer program products |
| US10476787B1 (en) | 2012-12-27 | 2019-11-12 | Sitting Man, Llc | Routing methods, systems, and computer program products |
| US10374938B1 (en) | 2012-12-27 | 2019-08-06 | Sitting Man, Llc | Routing methods, systems, and computer program products |
| US10404582B1 (en) | 2012-12-27 | 2019-09-03 | Sitting Man, Llc | Routing methods, systems, and computer program products using an outside-scope indentifier |
| US10411998B1 (en) | 2012-12-27 | 2019-09-10 | Sitting Man, Llc | Node scope-specific outside-scope identifier-equipped routing methods, systems, and computer program products |
| US10419335B1 (en) | 2012-12-27 | 2019-09-17 | Sitting Man, Llc | Region scope-specific outside-scope indentifier-equipped routing methods, systems, and computer program products |
| US10419334B1 (en) | 2012-12-27 | 2019-09-17 | Sitting Man, Llc | Internet protocol routing methods, systems, and computer program products |
| US10404583B1 (en) | 2012-12-27 | 2019-09-03 | Sitting Man, Llc | Routing methods, systems, and computer program products using multiple outside-scope identifiers |
| US10411997B1 (en) | 2012-12-27 | 2019-09-10 | Sitting Man, Llc | Routing methods, systems, and computer program products for using a region scoped node identifier |
| US10397101B1 (en) | 2012-12-27 | 2019-08-27 | Sitting Man, Llc | Routing methods, systems, and computer program products for mapping identifiers |
| US10212076B1 (en) | 2012-12-27 | 2019-02-19 | Sitting Man, Llc | Routing methods, systems, and computer program products for mapping a node-scope specific identifier |
| US10904144B2 (en) | 2012-12-27 | 2021-01-26 | Sitting Man, Llc | Methods, systems, and computer program products for associating a name with a network path |
| US9553794B1 (en) * | 2013-01-10 | 2017-01-24 | Google Inc. | Traffic engineering for network usage optimization |
| US9559954B2 (en) | 2013-03-11 | 2017-01-31 | Cisco Technology, Inc. | Indexed segment ID |
| US9565160B2 (en) | 2013-03-11 | 2017-02-07 | Cisco Technology, Inc. | Advertisement of adjacency segment identifiers |
| US9537718B2 (en) | 2013-03-15 | 2017-01-03 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
| US9537769B2 (en) | 2013-03-15 | 2017-01-03 | Cisco Technology, Inc. | Opportunistic compression of routing segment identifier stacks |
| JP6167587B2 (ja) | 2013-03-21 | 2017-07-26 | 富士通株式会社 | 通信装置、通信ネットワークシステム、通信装置におけるコンテンツサーバ選択方法 |
| US9185001B2 (en) * | 2013-04-01 | 2015-11-10 | Verizon Patent And Licensing Inc. | Backhaul network performance monitoring using segmented analytics |
| US9160651B2 (en) | 2013-07-24 | 2015-10-13 | Telefonaktiebolaget L M Ericsson (Publ) | Metric biasing for bandwidth aware tie breaking |
| PL404986A1 (pl) | 2013-08-05 | 2015-02-16 | Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie | Urządzenie do rutingu pakietów wieloma ścieżkami w sieciach teleinformatycznych oraz sposób jego zastosowania |
| US9166887B2 (en) | 2013-12-26 | 2015-10-20 | Telefonaktiebolaget L M Ericsson (Publ) | Multicast convergence |
| US9762488B2 (en) | 2014-03-06 | 2017-09-12 | Cisco Technology, Inc. | Segment routing extension headers |
| JP6237397B2 (ja) * | 2014-03-27 | 2017-11-29 | 富士通株式会社 | 制御装置、および、通信方法 |
| JP2015220496A (ja) * | 2014-05-14 | 2015-12-07 | 富士通株式会社 | データ転送方法及びデータ転送システム |
| US9401858B2 (en) | 2014-06-30 | 2016-07-26 | Cisco Technology, Inc. | Loop avoidance during network convergence in switched networks |
| US9807001B2 (en) | 2014-07-17 | 2017-10-31 | Cisco Technology, Inc. | Segment routing using a remote forwarding adjacency identifier |
| JP2016105561A (ja) * | 2014-12-01 | 2016-06-09 | 沖電気工業株式会社 | 通信制御装置及びネットワークシステム |
| US10341221B2 (en) | 2015-02-26 | 2019-07-02 | Cisco Technology, Inc. | Traffic engineering for bit indexed explicit replication |
| EP3270542B1 (en) * | 2015-03-13 | 2019-10-02 | NEC Corporation | Management apparatus, network management method, and storage medium storing program |
| US10686699B2 (en) | 2015-07-28 | 2020-06-16 | Ciena Corporation | Multicast systems and methods for segment routing |
| US10069639B2 (en) | 2015-07-28 | 2018-09-04 | Ciena Corporation | Multicast systems and methods for segment routing |
| TWI618421B (zh) * | 2016-01-07 | 2018-03-11 | Chunghwa Telecom Co Ltd | System and method for dynamically switching protection route to improve bandwidth efficiency of PTN circuit |
| US10263881B2 (en) | 2016-05-26 | 2019-04-16 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
| US11032197B2 (en) | 2016-09-15 | 2021-06-08 | Cisco Technology, Inc. | Reroute detection in segment routing data plane |
| US10541923B2 (en) | 2018-02-05 | 2020-01-21 | Ciena Corporation | Segment routing traffic engineering based on link utilization |
| US11140074B2 (en) | 2019-09-24 | 2021-10-05 | Cisco Technology, Inc. | Communicating packets across multi-domain networks using compact forwarding instructions |
| CN113570103A (zh) * | 2020-09-14 | 2021-10-29 | 宁波舜宇智能科技有限公司 | 路径控制的方法、装置、电子装置和存储介质 |
| US11863464B2 (en) * | 2022-05-24 | 2024-01-02 | Arista Networks, Inc. | Resource utilization in resource reservation protocol split tunnels with adaptive sub-tunneling |
| CN116112712B (zh) * | 2023-01-12 | 2023-09-26 | 联通沃音乐文化有限公司 | 一种自适应影音视频传输播放方法 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0753979A1 (en) * | 1995-07-13 | 1997-01-15 | International Business Machines Corporation | Routing method and system for a high speed packet switching network |
| US6473404B1 (en) * | 1998-11-24 | 2002-10-29 | Connect One, Inc. | Multi-protocol telecommunications routing optimization |
| JP3615057B2 (ja) * | 1998-07-17 | 2005-01-26 | 株式会社東芝 | ラベルスイッチングパス設定方法及びノード装置 |
| US6563793B1 (en) * | 1998-11-25 | 2003-05-13 | Enron Warpspeed Services, Inc. | Method and apparatus for providing guaranteed quality/class of service within and across networks using existing reservation protocols and frame formats |
| JP2000174755A (ja) * | 1998-12-02 | 2000-06-23 | Fujitsu Ltd | 経路選択方式 |
| US6650640B1 (en) * | 1999-03-01 | 2003-11-18 | Sun Microsystems, Inc. | Method and apparatus for managing a network flow in a high performance network interface |
| JP3546764B2 (ja) | 1999-07-02 | 2004-07-28 | 日本電気株式会社 | ネットワークに備えられた負荷分散サーバ及び負荷分散サーバを備えるノード |
| US6363319B1 (en) * | 1999-08-31 | 2002-03-26 | Nortel Networks Limited | Constraint-based route selection using biased cost |
| US6628649B1 (en) * | 1999-10-29 | 2003-09-30 | Cisco Technology, Inc. | Apparatus and methods providing redundant routing in a switched network device |
| US6665273B1 (en) * | 2000-01-11 | 2003-12-16 | Cisco Technology, Inc. | Dynamically adjusting multiprotocol label switching (MPLS) traffic engineering tunnel bandwidth |
-
2000
- 2000-12-11 JP JP2000376615A patent/JP4150159B2/ja not_active Expired - Fee Related
-
2001
- 2001-03-01 EP EP01104498A patent/EP1130849B1/en not_active Expired - Lifetime
- 2001-03-01 US US09/797,419 patent/US7136357B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20010037401A1 (en) | 2001-11-01 |
| EP1130849B1 (en) | 2012-04-25 |
| EP1130849A3 (en) | 2004-09-15 |
| JP2001320420A (ja) | 2001-11-16 |
| EP1130849A2 (en) | 2001-09-05 |
| US7136357B2 (en) | 2006-11-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4150159B2 (ja) | 伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 | |
| Wang et al. | An overview of routing optimization for internet traffic engineering | |
| US7453884B2 (en) | Apparatus and method for scalable and dynamic traffic engineering in a data communication network | |
| US6584071B1 (en) | Routing with service level guarantees between ingress-egress points in a packet network | |
| US6538991B1 (en) | Constraint-based routing between ingress-egress points in a packet network | |
| US7082102B1 (en) | Systems and methods for policy-enabled communications networks | |
| US6956821B2 (en) | Path determination in a data network | |
| US9654383B2 (en) | Route optimization using measured congestion | |
| US9722928B2 (en) | Link policy routing based on link utilization | |
| JP2964957B2 (ja) | 高速ルーティング制御方式 | |
| US9015299B1 (en) | Link grouping for route optimization | |
| JP2002190825A (ja) | トラフィックエンジニアリング方法及びそれを用いたノード装置 | |
| JP5409565B2 (ja) | トランスポート制御サーバ、トランスポート制御システム、及び、トランスポート制御方法 | |
| Lin et al. | QoS routing granularity in MPLS networks | |
| Filsfils et al. | Engineering a multiservice IP backbone to support tight SLAs | |
| Szviatovszki et al. | Minimizing re-routing in MPLS networks with preemption-aware constraint-based routing | |
| Rabbat et al. | Traffic engineering algorithms using MPLS for service differentiation | |
| Nelakuditi et al. | On localized control in QoS routing | |
| JP2004254132A (ja) | パケット伝送方法及びパケット伝送装置 | |
| JP5194025B2 (ja) | 複数のアプリケーション・フローの間での複数のネットワーク・リソースの共有を最適化する方法 | |
| Vutukury et al. | SMART: a scalable multipath architecture for intra-domain QoS provisioning | |
| Lim et al. | Differentiated link based QoS routing algorithms for multimedia traffic in MPLS networks | |
| Alparslan et al. | AIMD-based online MPLS traffic engineering for TCP flows via distributed multi-path routing | |
| Shao et al. | An efficient QoS framework with distributed adaptive resource management in IPv6 networks | |
| Menth et al. | Network admission control for fault-tolerant QoS provisioning |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060222 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071127 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071204 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080123 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080603 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080627 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110704 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110704 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120704 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120704 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130704 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |