JP4268149B2 - リソース管理装置および方法 - Google Patents

Description

本発明は、通信ネットワークにおけるリソースを管理するリソース管理装置および方法に関する。

通信ネットワーク、特にＩＰ（Internet Protocol）ネットワークを利用して音声や映像などのコンテンツを提供する場合には、通信路の容量を超える利用要求によって輻輳が発生すると、パケットの損失などに伴い通信品質が劣化してしまう。このような通信品質の劣化を防ぐことを目的として、ネットワークレイヤにおけるリソース管理が研究されている。この種のリソース管理の一つに、通信ネットワークを構成するルータ（ノード）とは独立したリソース管理装置（リソース管理サーバ）を用いて、通信ネットワークを構成するノード間（リンク）のリソース量とその利用状況を管理するとともに、ユーザ端末などからのリソース確保要求に対して適切なリソースを払い出す方式がある。その従来例を以下に説明する。

通信ネットワークの運用開始前に、まず、その通信ネットワーク内のルーティング情報を収集する。このルーティング情報には、通信ネットワーク中の各リンクのリソース量および接続情報が含まれている。ついで、各リンクの接続情報を基にパケットが通過する通信経路を計算し、その計算結果を基に経路情報テーブルを作成する。また、各リンクのリソース量から、リソース情報テーブルを作成する。このリソース情報テーブルによって、各リンクの総リソース量と、利用可能なリソース残量が管理される。

通信ネットワークの運用開始後にあっては、リソース管理サーバにおいて通信サービスの利用要求（リソース確保要求）を受け付けると、要求された通信の発着ＩＰアドレスを基に、経路情報テーブルから当該通信に必要となるリンクを特定する。そして、リソース情報テーブルを参照し、特定されたリンクのそれぞれについて当該通信に必要となる容量が利用可能か否かをチェックする。

その結果、特定されたすべてのリンクについて十分な容量が利用可能である場合には、リソース確保要求に対して許諾応答するとともに、リソース情報テーブルにおいて、特定されたリンクのリソース残量から当該通信に割り当てられる容量を減算する処理を行う。逆に、いずれかのリンクについて利用可能な容量が不足する場合には、リソース確保要求に対して拒絶応答する（例えば、特許文献１および非特許文献１を参照）。

リソース確保要求の許諾応答を受けて通信サービスを利用することによって、通信品質が担保される。
その後、通信サービスの利用終了時には、それまで確保していたリソースを速やかに解放する。

特開２００３−２５８８５５号公報 矢口他、「大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例」、信学総合大会、Ｂ−６−３１（２００２）

ノード間には通常１本のリンクが接続されるが、２本以上のリンクが並んで接続される場合もある。後者の場合には、起点ノードと宛先ノードとの組合わせが同一のリンクが複数存在する。このような構成を冗長構成と呼ぶ。冗長構成は、例えばＬＡ（Linl Aggrigation：リンクアグリげーション）やＥＣＭＰ（equal cost multi pass：イコールコストマルチパス）などで現れる。

ＬＡとは、ノード間に複数のリンクを並列に接続し、それぞれのリンクの両端のノードのＭＡＣアドレス（物理ＩＦ（ＩＦ：インターフェース）の識別子）に対し、同一のＩＰアドレス（システムＩＰ）を付与することをいう。これにより、１つのＩＰアドレスで通信可能な容量を増大させることができる。
また、ＥＣＭＰとは、ノード間に複数のリンクが並列に接続されている場合に、それぞれのリンクを使用して起点ノードから宛先ノードに至るコストの値（ＯＳＰＦ（Open Shortest Path First）による経路情報におけるコスト値）を等しく設定することをいう。ＥＣＭＰにおいては、それぞれのリンクの両端のノードのＭＡＣアドレスに対して１対１にＩＰアドレスが付与される。

ＬＡおよびＥＣＭＰにおいては、ノード間の複数のリンクのうち、いずれかのリンクが通信の際に使用される。しかし、従来のリソース管理サーバは、通信の際にどのリンクが使用されるのかを判断することができず、正確なリソース管理を行うことができないという問題があった。

本発明は、このような課題を解決するためになされたものであり、その目的は、冗長構成のリソースを管理できるようにすることにある。

このような目的を達成するために、本発明に係るリソース管理装置は、通信ネットワークに属するノードの間を接続するリンクの識別子にこのリンクのリソース量を対応づけたリンク情報を記憶するリンク情報記憶手段と、通信ネットワーク内の通信経路をこの通信経路を構成するリンクの識別子によって表す経路情報を記憶する経路情報記憶手段と、経路情報およびリンク情報を参照し通信経路を構成するリンクのリソース量に基づき、通信ネットワーク内のリソース管理を行なうリソース管理手段とを備え、リンクの識別子は、リンクの起点となる起点ノードと前記リンクの宛先となる宛先ノードとの組合わせが同一の複数のリンクにおいて同一であり、リソース管理手段は、識別子が同一の複数のリンクのリソース量に基づきリソース管理を行ない、前記識別子が同一の前記複数のリンクは、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせが同一の第１のリンク集合体と、それぞれのリンクを使用して前記起点ノードから前記宛先ノードに至るコストが等しく、かつ、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる第２のリンク集合体とからなり、前記リンク情報は、前記リンクが前記第１および第２のリンク集合体のいずれに属するかを表す冗長状態識別子を含むことを特徴とする。
ここで、リソース管理手段は、識別子が同一の複数のリンクのリソース量の合計に基づ
きリソース管理を行なうことができる。

例えば、起点ノードにおけるＩＰアドレスと宛先ノードにおけるＩＰアドレスとの組合わせが同一の複数のリンクに対して、同一の識別子が付与される。具体的には、ＬＡの場合である。
また、それぞれのリンクを使用して起点ノードから宛先ノードに至るコストが等しく、かつ、起点ノードにおけるＩＰアドレスと宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる複数のリンクに対して、同一の識別子が付与される。具体的には、ＥＣＭＰの場合がある。

また、通信経路の起点となる起点ノードと通信経路の終点となる終点ノードとの組合わせが同一の複数の通信経路がある場合に、経路情報が、それぞれの通信経路が使用される優先順位を含むようにしてもよい。起点ノードと終点ノードとの組合わせが同一の複数の通信経路に対し同一の優先順位が付与されている場合に、リソース管理手段は、これらの通信経路のリソースに基づきリソース管理を行なうことができる。

また、本発明に係るリソース管理方法は、通信ネットワークに属するノードの間を接続するリンクの識別子にこのリンクのリソース量を対応づけたリンク情報を作成するステップと、通信ネットワーク内の通信経路をこの通信経路を構成するリンクの識別子によって表す経路情報を作成するステップと、経路情報およびリンク情報を参照し通信経路を構成するリンクのリソース量に基づき、通信ネットワーク内のリソース管理を行うステップとを備え、リンク情報を作成するステップは、リンクの起点となる起点ノードとリンクの宛先となる宛先ノードとの組合わせが同一の複数のリンクに対して同一の識別子を付与し、リソース管理を行うステップは、同一の識別子が付与された複数のリンクのリソース量に基づきリソース管理を行ない、前記同一の識別子が付与された前記複数のリンクは、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせが同一の第１のリンク集合体と、それぞれのリンクを使用して前記起点ノードから前記宛先ノードに至るコストが等しく、かつ、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる第２のリンク集合体とからなり、前記リンク情報を作成するステップは、前記リンクが前記第１および第２のリンク集合体のいずれに属するかを表す冗長状態識別子を前記リンク情報に付加することを特徴とする。
ここで、リソース管理を行なうステップは、同一の識別子が付与された複数のリンクのリソース量の合計に基づきリソース管理を行なうことができる。

リンク情報を作成するステップは、例えば、起点ノードにおけるＩＰアドレスと宛先ノードにおけるＩＰアドレスとの組合わせが同一の複数のリンクに対して同一の識別子を付与することができる。また、起点ノードから宛先ノードに至るコストが等しく、かつ、起点ノードにおけるＩＰアドレスと宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる複数のリンクに対して同一の識別子を付与することができる。

また、通信経路の起点となる起点ノードと通信経路の終点となる終点ノードとの組合わせが同一の複数の通信経路がある場合に、経路情報を作成するステップは、それぞれの通信経路が使用される優先順位を経路情報に付加することができる。起点ノードと終点ノードとの組合わせが同一の複数の通信経路に対し同一の優先順位が付与されている場合に、リソース管理を行なうステップは、これらの通信経路のリソースに基づきリソース管理を行なうことができる。

本発明では、ノード間に複数のリンクが接続された冗長構成において、これら複数のリンクに対して同一の識別子を付与し、これら複数のリンクのリソース量に基づきリソースを管理する。これにより、複数のリンクのうち、通信の際にどのリンクが使用されているのか分からなくても、冗長構成のリソースの管理が可能となる。

また、本発明では、起点ノードと終点ノードとの組合わせが同一の複数の通信経路に対し同一の優先順位が付与されている場合に、これらの通信経路のリソースに基づき起点ノードと終点ノードとの間のリソースを管理する。これにより、複数の通信経路のうち、通信の際にどの経路が使用されているのか分からなくても、起点ノードと終点ノードとの間のリソースの管理が可能となる。

以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
１．第１の実施の形態
図１は、本発明の第１の実施の形態に係るリソース管理サーバが適用されるシステムの全体構成を示すブロック図である。
図１に示すリソース管理サーバ１は、通信ネットワーク２のリソースを管理するリソース管理装置である。

通信ネットワーク２は、インターネットプロトコル（ＩＰ）に基づく通信ネットワークであり、複数のルータＣＲ１〜ＣＲ３，ＥＲ１〜ＥＲ４、Ｌ２スイッチ（図示せず）、端末Ｔ１〜Ｔ６などから構成される。これらを総称してノードと呼ぶ。ノード間は、リンクと呼ばれる通信回線によって接続されている。リンクの起点となるノードを起点ノード、リンクの宛先となるノードを宛先ノードと呼ぶ。ノード間には通常１本のリンクが接続されるが、ＬＡおよびＥＣＭＰの場合はノード間に２本以上のリンクが並列に接続される。
通信ネットワーク２のリソースとは、通信を行う２つの端末間の通信経路を構成するノード間のリンクのことをいう。

アプリケーションサーバ３は、端末Ｔからの各種要求を受けて、その要求に応じたメッセージをリソース管理サーバ１に送信するサーバである。要求メッセージには、端末Ｔと他の端末との間で行う通信に必要なリソースの確保を要求するリソース確保要求メッセージ、確保されたリソースの解放を要求するリソース解放要求メッセージなどがある。それぞれの要求メッセージには、要求メッセージの種類を示すメッセージ番号、通信を行う２つの端末の識別子、通信に必要なリソースの容量などの情報が付加されている。なお、本実施の形態では、端末の識別子としてＩＰアドレスを用いることとする。

１−１．冗長構成のリソース管理
通信ネットワーク２には、ＬＡおよびＥＣＭＰという冗長構成が含まれている。以下、この冗長構成のリソースの管理方法について説明する。

１−１−１．概要
本実施の形態では、ノード間の複数のリンク、すなわち起点ノードと宛先ノードとの組合わせが同一の複数のリンクを、１本のリンクとして管理する。具体的には、これら複数のリンクに対して同一の識別子を付与し、同一の識別子を付与したすべてのリンクのリソース量に基づきリソースの確保および解放といった処理を行う。

この際、ＬＡおよびＥＣＭＰの両方に対応しうるように、リンクの概念を「物理リンク」および「仮想リンク」という２種類に拡張する。ここで、「物理リンク」とは、起点アドレス（source address）と宛先アドレス（destination address）とによって一意に決まるリンクをいう。なお、起点アドレスおよび宛先アドレスは共にＩＰアドレスである。また、「仮想リンク」とは、少なくとも１つの物理リンクを束ねて仮想的に作成されたリンクをいう。
また、冗長状態を識別できるように、冗長状態識別子として「仮想リンクフラグ」を導入する。例えば、冗長のない通常のリンクを「０」、ＬＡを「１」、ＥＣＭＰを「２」で表す。
以下、それぞれの場合について、具体的に説明する。

１−１−２．冗長のない通常のリンク
図２は、冗長のない通常のリンクのモデルを示す図である。
起点ノードＳＮと宛先ノードＤＮとの間に複数のリンクが並列に接続されており、それぞれのリンクの両端のノードのＭＡＣアドレス（□）に対し１：１にＩＰアドレス（○）が付与されている。このような冗長のない通常のリンクを物理リンクとし、それぞれに独自の物理リンクＩＤ（＃１，＃２，…，＃Ｎ）を付与する。

１−１−３．ＬＡ
図３は、ＬＡのモデルを示す図である。
図３（ａ）に示すように、ＬＡでは、起点ノードＳＮと宛先ノードＤＮとの間に複数のリンクが並列に接続されており、それぞれのリンクの両端のノードのＭＡＣアドレス（□）に対し、同一のＩＰアドレス（○）が付与される。したがって、複数のリンクの起点ノードＳＮにおけるＩＰアドレスと宛先ノードＤＮにおけるＩＰアドレスとの組合わせが同一となる。

このような複数のリンクを、本実施の形態では１本の物理リンクとして管理する。具体的には、図３（ｂ）に示すように複数のリンクに独自の物理リンクＩＤ（＃１１）を付与し、これら複数のリンクのリソース量の合計に基づきリソースの確保および解放といった処理を行う。また、仮想リンクとしても１本として管理するため、仮想リンクＩＤとして物理リンクＩＤと同じＩＤを付与する。
なお、起点ノードＳＮと宛先ノードＤＮとの組合わせは、エッジルータとコアルータ、コアルータとコアルータ、エッジルータとエッジルータがある。

このようにＬＡにおいて物理リンクＩＤおよび仮想リンクＩＤを付与した上で、リンクのリソース量を示すリンク情報テーブル、隣接するノードのアドレスを示す隣接情報テーブル、通信経路を構成するリンクを示す経路情報テーブルを作成する。
以下、図４に示すＬＡ区間を含むモデルに基づいて作成した各テーブルの一例を示す。図４では、エッジルータ＃Ａとコアルータ＃Ｃとの間がＬＡ区間であり、物理リンクＩＤ「（１）」が付与されている。また、コアルータ＃Ｃとコアルータ＃Ｄとの間のリンクがＬＡ区間であり、物理リンクＩＤ「（２）」が付与されている。さらに、エッジルータ＃Ｂとコアルータ＃Ｃとの間は通常のリンクであり、物理リンクＩＤ「３」が付与されている。なお、図４において、「０／１」、「０／２」は、物理ＩＦのスロット番号／ポート番号を表す。

図５は、図４に示したモデルに基づいて作成したリンク情報テーブルの一例を示す図である。
図５に示すリンク情報テーブル３２は、「リンク情報を表す識別子」、「物理リンクＩＤ」、「仮想リンクＩＤ」、「総リソース量」、「リソース残量」、「仮想リンクフラグ」からなる。

「物理リンクＩＤ」は、リンクに付与された物理リンクＩＤを表す。
「仮想リンクＩＤ」は、リンクに付与された仮想リンクＩＤを表す。ＬＡおよび冗長のない通常のリンクでは、仮想リンクＩＤは物理リンクＩＤと同じになる。
「総リソース量」は、未使用状態で使用可能なリンクの総リソース量を表す。ＬＡでは、物理リンクを構成する複数のリンクのリソース量の合計を表す。
「リソース残量」は、そのリンクで確保可能なリソースの残量を表す。ＬＡでは、物理リンクを構成する複数のリンクのそれぞれのリソース残量の合計を表す。
「仮想リンクフラグ」は、冗長状態を表す。ＬＡでは「１」、冗長のない通常のリンクでは「０」となる。

図６は、図４に示したモデルに基づいて作成した隣接情報テーブルの一例を示す図である。
図６に示す隣接情報テーブル３３は、「隣接情報を表す識別子」、「物理リンクＩＤ」、「仮想リンクＩＤ」、「起点ノードのＩＰアドレス」、「起点ノードのＭＡＣアドレス」、「宛先ノードのＩＰアドレス」、「宛先ノードのＭＡＣアドレス」、「優先順位」からなる。

「起点ノードのＩＰアドレス」は、リンクの起点ノードのＩＰアドレスを表す。
「起点ノードのＭＡＣアドレス」は、リンクの起点ノードにおける物理ＩＦのＭＡＣアドレスを表す。
「宛先ノードのＩＰアドレス」は、リンクの宛先ノードのＩＰアドレスを表す。
「宛先ノードのＭＡＣアドレス」は、リンクの宛先ノードにおける物理ＩＦのＭＡＣアドレスを表す。
「優先順位」は、このリンクが通信経路に使用される順位を表す。起点ノードから宛先ノードに至るコストの値（ＯＳＰＦによる経路情報におけるコスト値）が高いほど、優先順位が高くなる。コストは、未使用時の総リソース量に置き換えることができる。

ＬＡ区間については、ＭＡＣアドレスの異なるリンク毎に欄が作成される。したがって、ＭＡＣアドレスの値だけが異なり、リンクＩＤやＩＰアドレスなどその他の値が同一の欄が、テーブル３３の縦方向に並ぶことになる。

図７は、図４に示したモデルに基づいて作成した経路情報テーブルの一例を示す図である。
図７に示す経路情報テーブル３４は、「起点ノードのＩＰアドレス」、「終点ノードのＩＰアドレス」、「リンクＩＤのリスト」、「優先順位」からなる。

「起点ノードのＩＰアドレス」は、通信ネットワーク２内の通信経路の起点となるノードのＩＰアドレスである。
「終点ノードのＩＰアドレス」は、通信ネットワーク２内の通信経路の終点となるノードのＩＰアドレスである。
「リンクＩＤのリスト」は、通信ネットワーク２内の通信経路を構成する個々のリンク、すなわち起点ノードと終点ノードとの間を接続する個々のリンクのＩＤのリストである。ＬＡおよび冗長のない通常のリンクの場合には、物理リンクＩＤが使用される。

「優先順位」は、通信ネットワーク２内に起点ノードと終点ノードとの組み合わせが同一の通信経路が複数存在する場合に、通信経路として好ましい順位を表す。起点ノードから終点ノードに至るコストの値（ＯＳＰＦによる経路情報におけるコスト値）が高いほど、優先順位が高くなる。まず優先順位が最も高い通信経路が使用され、この通信経路に故障が発生した場合に、優先順位が同一の他の通信経路、または優先順位が２番目に高い通信経路に置き換えられる。

１−１−４．ＥＣＭＰ
図８は、ＥＣＭＰの第１のモデルを示す図である。
図８（ａ）では、起点ノードＳＮと宛先ノードＤＮとの間に複数のリンクが並列に接続されており、それぞれのリンクの両端のノードのＭＡＣアドレス（□）に対し１：１にＩＰアドレス（○）が付与されている。すなわち、複数のリンクの起点ノードＳＮにおけるＩＰアドレスと宛先ノードＤＮにおけるＩＰアドレスとの組合わせがそれぞれ異なる。したがって、それぞれのリンクを物理リンクとし、独自の物理リンクＩＤ（＃１，＃２，…，＃Ｎ）を付与する。なお、起点ノードＳＮと宛先ノードＤＮとの組合わせは、エッジルータとコアルータ、コアルータとコアルータ、エッジルータとエッジルータがある。

ＥＣＭＰでは、これら複数の物理リンクのそれぞれのコスト値が等しく、優先順位が同じになっている。したがって、これら複数の物理リンクを、本実施の形態では１本の仮想リンクとして管理する。
具体的には、図８（ｂ）に示すように複数の物理リンクに独自の仮想リンクＩＤ（＃１０１）を付与し、これらすべての物理リンクのリソース量に基づきリソースの確保および解放といった処理を行う。仮想リンクがＮ本（Ｎは２以上の整数）の物理リンクからなるとすると、例えばリソースを確保するときには、確保すべきリソース量をＮ等分してすべての物理リンクから減算する。あるいは、Ｎ本の物理リンクにナンバリングし、まず１番目の物理リンクを用いて確保処理を行い、リソース残量がなくなったら２番目の物理リンクを用いて確保処理を行うというようにしてもよい。

図９は、ＥＣＭＰの第２のモデルを示す図である。
このモデルでは、ノードＮ１からノードＮ４に至る通信経路として、ノードＮ２を通過する経路と、ノードＮ３を通過する経路の２つがある。しかし、これら２つの通信経路は、ＯＳＰＦによる経路情報におけるコスト値が等しい。そこで、本実施の形態では、これら２つの通信経路を同一の優先順位として管理する。
具体的には、２つの通信経路のリソース量に基づきリソースの確保および解放といった処理を行う。例えばリソースを確保するときには、確保すべきリソース量の１／２ずつをそれぞれの通信経路において確保する。あるいは、一方の経路を用いて確保処理を行い、リソース残量がなくなったら他方の経路を用いて確保処理を行うというようにしてもよい。

なお、ノードＮ１は、エッジルータまたはコアルータである。ノードＮ４もまた、エッジルータまたはコアルータである。
ここでは２つの経路のコスト値が等しい場合について説明したが、３つ以上の経路のコスト値が等しい場合も同様である。

以下、図１０に示すＥＣＭＰ区間を含むモデルに基づいて作成したリンク情報テーブル、隣接情報テーブル、経路情報テーブルの一例を示す。図１０では、エッジルータ＃Ａとコアルータ＃Ｃとの間がＥＣＭＰ区間であり、各リンクに物理リンクＩＤ「１」，「２」がそれぞれ付与されるとともに、仮想リンクＩＤ「（６）」が共通に付与されている。また、エッジルータ＃Ｃとコアルータ＃Ｄとの間がＥＣＭＰ区間であり、各リンクに物理リンクＩＤ「４」，「５」がそれぞれ付与されるとともに、仮想リンクＩＤ「（７）」が共通に付与されている。さらに、エッジルータ＃Ｂとコアルータ＃Ｃとの間は通常のリンクであり、物理リンクＩＤ「３」が付与されている。

図１１は、図１０に示したモデルに基づいて作成したリンク情報テーブルの一例を示す図である。図１１に示すリンク情報テーブル３２のデータ構造は、図５に示したリンク情報テーブル３２と同じである。
ＥＣＭＰでは、「総リソース量」は、各物理リンクの総リソース量を表す。同一の仮想リンクＩＤが付与された物理リンクの総リソース量の合計ではない。
「リソース残量」は、その物理リンクで確保可能なリソースの残量を表す。同一の仮想リンクＩＤが付与された物理リンクのリソース残量の合計ではない。
「仮想リンクフラグ」は「２」となる。

図１２は、図１０に示したモデルに基づいて作成した隣接情報テーブルの一例を示す図である。図１２に示す隣接情報テーブル３３のデータ構造は、図６に示した隣接情報テーブル３３と同じである。

図１３は、図１０に示したモデルに基づいて作成した経路情報テーブルの一例を示す図である。図１３に示す経路情報テーブル３４のデータ構造は、図７に示した隣接情報テーブル３４と同じである。
図８に示したような隣接するノード間でのＥＣＭＰでは、「リンクＩＤのリスト」に仮想リンクＩＤが使用される。一方、図９に示したような起点ノードと終点ノードとの間でのＥＣＭＰでは、「リンクＩＤのリスト」に物理リンクＩＤが使用される。

１−２．リソース管理サーバ１の構成
次に、リソース管理サーバ１の構成について説明する。
リソース管理サーバ１は、通信機能を有するコンピュータからなる。以下に説明するリソース管理サーバ１の諸機能は、演算装置（ＭＰＵ）や記憶装置（ＲＯＭおよびＲＡＭ等の内部メモリの他、ＨＤＤ等の外部記憶装置を含む）等のコンピュータのハードウェア資源とこのコンピュータにインストールされたコンピュータ・プログラム（ソフトウェア）とが協働することによって実現される。

図１４は、リソース管理サーバ１の構成を示すブロック図である。
図１４に示すように、リソース管理サーバ１は、端末情報入力部１０と、リンク情報収集部１１と、テーブル作成部１２と、テーブル記憶部１３と、送受信部１４と、制御部１５とを有する。

ここで、端末情報入力部１０には、保守者の操作やアプリケーションサーバ３経由によるユーザの操作などによって、端末Ｔ１〜Ｔ６に関する情報が入力される。例えば、通信ネットワーク２に属する端末Ｔ１〜Ｔ６、ルータＥＲ１〜ＥＲ４，ＣＲ１〜ＣＲ３のＩＰアドレスなどが入力される。

リンク情報収集部１１は、通信ネットワーク２に属するルータＥＲ１〜ＥＲ４，ＣＲ１〜ＣＲ３から、ルーティング情報（例えばＯＳＰＦ等のルーティングポリシー）を収集する。ルーティング情報には、リンクのリソース量および接続情報が含まれる。リンクの接続情報とは、どのノードのどのインタフェースと、どのノードのどのインタフェースが接続されているリンクであるかを示す情報である。ルーティング情報の収集には、例えばＳＮＭＰ（Simple Network Management Protocol）やＭＩＢ（Management Information Base）等の汎用プロトコルを用いることができる。

テーブル作成部１２は、端末情報入力部１０に入力された情報およびリンク情報収集部１１によって収集された情報を基に、アドレスリスト３１、リンク情報テーブル３２、隣接情報テーブル３３および経路情報テーブル３４を作成する。
アドレスリスト３１は、通信ネットワーク２に属する端末Ｔ１〜Ｔ６、ルータＥＲ１〜ＥＲ４，ＣＲ１〜ＣＲ３などのＩＰアドレスのリストである。例えば、端末Ｔ１〜Ｔ６のＩＰアドレスと、各端末を収容するエッジノード（例えば、端末Ｔ１を収容するエッジルータＥＲ１）のＩＰアドレスとからなる。

その他のテーブル３２〜３４については、上述した通りである。
ただし、リンク情報テーブル３２において、各リンクには「物理リンクＩＤ」を若い番号から自動的に付与していく。冗長のない通常のリンクおよびＬＡ区間のリンクには、「仮想リンクＩＤ」として「物理リンクＩＤ」と同じ番号を付与する。一方、ＥＣＭＰ区間の各リンクには、「仮想リンクＩＤ」として同一の番号（「物理リンクＩＤ」とは別の番号）を付与する。なお、リンクＩＤを保守者が手動で設定することや、自動設定されたリンクＩＤを保守者が修正することも可能である。これにより、リンクＩＤの自由度が高くなる。

また、経路情報テーブル３４を作成するにあたって、テーブル作成部１２は、リンク情報収集部１１によって収集されたルーティング情報を用いて、利用される可能性のあるすべてのエッジルータＥＲについて、あるエッジルータＥＲ（起点ノード）から他のエッジルータＥＲ（終点ノード）ヘの通信がどのリンクを通過するかという通信経路の算出を行う。可能な場合には、起点ノードと終点ノードとの組み合わせが同一の通信経路を複数算出し、これらの通信経路の間でコスト値に基づく優先順位を決定する。

テーブル３２〜３４を作成する際には、冗長のない通常のリンクか、ＬＡ区間か、ＥＣＭＰ区間かを区別する必要がある。
ＬＡ区間であることは、ルータＥＲ１〜ＥＲ４，ＣＲ１〜ＣＲ３からルータ間のリンクがＬＡ区間であるという情報をリンク情報収集部１１が収集することによって知ることができる。保守者が手動で設定することもできる。また、リンクの未使用時の総リソース量は通常、１０Ｍ、１００Ｍや１０００Ｇとなる。コスト値は「１００÷物理リンクの速度」で表されるため、１もしくは０．１となる。これ以外の端数、例えば０．２５なら、４００Ｍ、つまり１００Ｍ×４と考え、ＬＡ区間であると判断することも可能である。
また、ＥＣＭＰであることは、同一区間のリンクまたは経路が同一の優先順位になっていることから分かる。

なお、テーブル作成部１２は、リンク情報収集部１１によって情報が収集される度に、通信経路の算出およびテーブル３２〜３４の更新を行うようにしてもよい。

テーブル記憶部１３は、テーブル作成部１２によって作成された各テーブル３１〜３４を記憶する。
送受信部１４は、通信インターフェースを備え、アプリケーションサーバ３との間で要求メッセージ等を送信および受信する。
制御部１５は、受信された要求メッセージに応じて、通信ネットワーク２のリソース管理を行なう。具体的には、送受信部１４で受信された要求メッセージを分析するメッセージ解析部５１と、分析結果を基にテーブル３１〜３４を参照しリソースの確保または解放が要求される通信経路を検出し、リソース確保または解放の処理を行うリソース管理部５２と、要求メッセージに対する応答を行なう応答処理部５３とから構成される。

１−３．リソース管理サーバ１の動作
次に、リソース管理サーバ１の動作について説明する。ここでは、端末Ｔ４が端末（以下「配信サーバ」という）Ｔ１による映像配信サービスを利用する際に、リソース管理サーバ１が通信ネットワーク２において必要なリソースを確保する動作について説明する。図１５は、リソース管理サーバ１の動作の流れを示すフローチャートである。

端末Ｔ４が配信サーバＴ１による映像配信サービスの利用要求をアプリケーションサーバ３に送信すると、この利用要求を受けてアプリケーションサーバ３はリソース確保要求メッセージを作成し、リソース管理サーバ１に送信する。リソース確保要求メッセージには、このメッセージがリソース確保要求であることを示すメッセージ番号、映像配信を行う発端末としての配信サーバＴ１のＩＰアドレス、映像配信を受ける着端末としての端末Ｔ４のＩＰアドレス、映像配信に必要なリソース量が付加されている。

このリソース確保要求メッセージを送受信部１４で受信したリソース管理サーバ１では（ステップＳ１，ＹＥＳ）、メッセージ解析部５１が、受信したメッセージに付加されているメッセージ番号から、このメッセージが「リソース確保要求」であると判断する。さらに、メッセージに付加されている配信サーバＴ１および端末Ｔ４のＩＰアドレス、映像配信に必要なリソース量を抽出する（ステップＳ２）。

ついで、リソース管理部５２が、アドレスリスト３１を参照し、メッセージから抽出した配信サーバＴ１および端末Ｔ４のＩＰアドレスをキーにして、配信サーバＴ１および端末Ｔ４をそれぞれ収容するエッジノードを検索し、通信ネットワーク２内における通信経路の起点ノードがエッジルータＥＲ１、終点ノードがエッジルータＥＲ３であることを知る。続いて、経路情報テーブル３４を参照し、エッジルータＥＲ１とエッジルータＥＲ３との間の通信経路を検索する（ステップＳ３）。

検索の結果、通信経路が１つしかない場合には（ステップＳ４，ＹＥＳ）、その通信経路に対してリソース確保処理を行う（ステップＳ５）。このリソース確保処理の詳細については後述する。
一方、通信経路が複数ある場合には（ステップＳ４，ＮＯ）、これらの通信経路の間の優先順位をチェックする。その結果、優先順位「１」の通信経路が１つしかない場合には（ステップＳ７，ＹＥＳ）、その通信経路を選択し（ステップＳ８）、リソース確保処理を行う（ステップＳ５）。
これに対し、複数の通信経路に優先順位「１」が設定されている場合には（ステップＳ７，ＮＯ）、優先順位「１」の複数の通信経路を選択し（ステップＳ９）、これらの通信経路に対してリソース確保処理を行う（ステップＳ１０）。

リソース確保処理の終了後、応答処理部５３がリソース確保を許諾する旨の応答メッセージを作成し、送受信部１４からアプリケーションサーバ３に送信する（ステップＳ６）。

アプリケーションサーバ３は、リソース確保を許諾する旨の応答メッセージを受けると、端末Ｔ４に対し通信品質を保証した上で、配信サーバＴ１による映像配信サービスの利用を許可する。これにより、配信サーバＴ１から端末Ｔ４への高品質な映像配信が開始される。

次に、ステップＳ５のリソース確保処理について説明する。図１６は、この処理の流れを示すフローチャートである。
リソース管理部５２は、経路情報テーブル３４の「リンクＩＤのリスト」を参照し、選択した通信経路を構成するリンクのＩＤ（物理リンクＩＤまたは仮想リンクＩＤ）を読み出す（ステップＳ２１）。続いて、リンク情報テーブル３２を参照し、読み出したＩＤに対応するリンクの「仮想リンクフラグ」をチェックする。

「仮想リンクフラグ」が「０」の場合は（ステップＳ２３，「０」）、冗長のない通常のリンクであるから、従来と同様にリソース確保処理を行えばよい。すなわち、そのリンクの現在の「リソース残量」の値を読み出し、この値から映像配信に必要とされるリソース量の値を減算し、得られた値をそのリンクの「リソース残量」に新たに書き込む（ステップＳ２４）。

「仮想リンクフラグ」が「１」の場合は（ステップＳ２３，「１」）、ＬＡ区間（第１のリンク集合体）である。ＬＡ区間については、リンク情報テーブル３２の「総リソース量」および「リソース残量」の値がＬＡ区間の複数のリンクのリソース量の合計に基づいて計算されているので、冗長のない通常のリンクの場合と同様にリソース確保処理を行うことができる（ステップＳ２４）。

「仮想リンクフラグ」が「２」の場合は（ステップＳ２３，「２」）、ＥＣＭＰ区間（第２のリンク集合体）である。この場合には、当該物理リンクおよびＥＣＭＰ区間の他の物理リンクのリソース量に基づきリソース確保処理を行う。例えば、ＥＣＭＰ区間にＮ本の物理リンクが並列に接続されている場合には、それぞれの物理リンクの現在の「リソース残量」の値を読み出し、この値から映像配信に必要とされるリソース量の値の１／Ｎずつを減算し、得られた値をそれぞれのリンクの「リソース残量」に新たに書き込む（ステップＳ２５）。

なお、ＥＣＭＰ区間の複数の物理リンクには同一の仮想リンクＩＤが付与され、この仮想リンクＩＤが経路情報テーブル３４の「リンクＩＤのリスト」に記載されている。したがって、ステップＳ２１で読み出した仮想リンクＩＤをキーにして、ＥＣＭＰ区間の複数の物理リンクを検索することができる。

通信経路を構成するすべてのリンクについて以上の処理を繰り返し行なうことにより（ステップＳ２１、ステップＳ２６、ステップＳ２７）、リソース確保処理が終了する。これにより、映像配信のためのリソースが確保される。

次に、ステップＳ１０のリソース確保処理について説明する。
優先順位「１」が設定された複数の通信経路はＥＣＭＰであるから、これらすべての通信経路のリソースに基づきリソース確保処理を行う。例えば、Ｍ本（Ｍは２以上の整数）の通信経路に優先順位「１」が設定されているとすると、それぞれの通信経路において、映像配信に必要とされるリソース量の１／Ｍずつを確保する処理を行う。それぞれの通信経路において行われるリソース確保処理は、ステップＳ５のリソース確保処理と同様である。

配信サーバＴ１から端末Ｔ４への映像配信が終了すると、リソース管理サーバ１は映像配信のために確保されていたリソースを解放する。このリソース解放処理は、映像配信のために確保されたリソース量を各リンクのリソース残量に加算する点を除いて、リソース確保処理と概ね同じである。

１−４．本実施の形態の効果
以上のように、本実施の形態では、ノード間に複数のリンクが接続された冗長構成において、これら複数のリンクに対して同一の識別子（物理リンクＩＤまたは仮想リンクＩＤ）を付与し、これら複数のリンクのリソース量に基づきリソースを管理する。これにより、複数のリンクのうち、通信の際にどのリンクが使用されているのか分からなくても、冗長構成のリソースの管理が可能となる。

また、本実施の形態では、起点ノードと終点ノードとの組合わせが同一の複数の通信経路に対し同一の優先順位が付与されている場合に、同一の優先順位が付与されたすべての通信経路のリソースに基づき起点ノードと終点ノードとの間のリソースを管理する。これにより、複数の通信経路のうち、通信の際にどの経路が使用されているのか分からなくても、起点ノードと終点ノードとの間のリソースの管理が可能となる。

２．第２の実施の形態
次に、本発明の第２の実施の形態について説明する。本実施の形態は、通信経路に故障が発生した場合にも、リソース管理を継続して行えるようにするものである。
図１７は、本発明の第２の実施の形態に係るリソース管理サーバの構成を示すブロック図である。この図では、図１４に示した構成要素と同一の要素について、図１４と同一符号を用いている。

テーブル記憶部１１３は、アドレスリスト３１、リンク情報テーブル１３２、隣接情報テーブル３３および経路情報テーブル１３４を保持する。
リンク情報テーブル１３２は、図１８に示すように「故障フラグ」の項目を有する点で、第１の実施の形態におけるリンク情報テーブル３２と異なる。「故障フラグ」は、そのリンクに故障が発生した場合にセットされる。例えば、通常この項目の値は「０」であり、故障が発生した場合に値が「０」から「１」に変化する。

経路情報テーブル１３４は、図１９に示すように「利用中リソース量」および「故障フラグ」の項目を有する点で、第１の実施の形態における経路情報テーブル３４と異なる。「利用中リソース量」は、その通信経路ですでに確保されているリソース量である。「故障フラグ」は、その通信経路に含まれるいずれかのリンクに故障が発生した場合にセットされる。

リンク情報収集部１１１は、第１の実施の形態におけるリンク情報収集部１１の機能に加えて、通信ネットワーク２に属するルータＥＲ１〜ＥＲ４，ＣＲ１〜ＣＲ３から、通信ネットワーク２内のリンクやノード、インターフェースボード、Ｌ２ＳＷの故障情報を収集する機能を有する。例えば、ＳＮＭＰや、ＳＮＭＰｔｒａｐ、ＭＩＢ等の汎用プロトコルを用いることができる。各ルータには、リンク等の故障時に故障情報をリソース管理サーバ１に送信するように設定しておけばよい。なお、リンク情報収集部１１１は、故障情報を受信できなかったことを考慮して、故障情報の一斉収集や再収集を定期的に行うようにしてもよい。

テーブル作成部１１２は、第１の実施の形態におけるテーブル作成部１２の機能に加えて、次のような機能を有する。すなわち、リンク情報収集部１１１によって受信された故障情報を基に、故障したリンクを特定し、リンク情報テーブル１３２において、故障したリンクの欄に故障フラグをセットする。また、経路情報テーブル１３４において、故障したリンクを含む通信経路を検索し、その通信経路の欄に故障フラグをセットする。故障したリンクを含む通信経路を「故障経路」と呼ぶ。なお、故障したリンクが回復したときには、リンク情報テーブル１３２および経路情報テーブル１３４において、故障フラグをリセットする。

制御部１１５は、メッセージ解析部５１と、リソース管理部１５２と、応答処理部５３とから構成される。
リソース管理部１５２は、第１の実施の形態におけるリソース管理部５２の機能に加えて、次のような機能を有する。
まず、経路情報テーブル１３４を監視し、いずれかの通信経路の欄に故障フラグがセットされると、その故障経路が現在使用されているか否かを判定する。例えば、故障経路が、故障フラグがセットされていない他の通信経路と比較して最も優先順位が高い場合には、その故障経路は使用中であると判定することができる。

故障経路が現在使用されている場合には、以後その通信経路の使用を中止し、その通信経路と優先順位が同一、またはその通信経路に次いで優先順位が高い通信経路を代わりに使用することとする。代わりに使用される通信経路を「代替経路」と呼ぶ。
この際、経路情報テーブル１３４の「利用中リソース量」を参照して、故障経路においてリソースが確保されているか否かを判定し、リソースが確保されている場合には、確保されているリソースを代替経路に積み替える。リソースの積み替えは次のようにして行う。

まず、故障経路を構成するリンクのＩＤを読み出し、リンク情報テーブル１３２において、読み出したＩＤに対応するリンクの「リソース残量」から、故障経路の「利用中リソース量」を加算する。また、代替経路を構成するリンクのＩＤを読み出し、リンク情報テーブル１３２において、読み出したＩＤに対応するリンクの「リソース残量」から、故障経路の「利用中リソース量」を減算する。さらに、故障経路の「利用中リソース量」の値を代替経路の「利用中リソース量」に書き込み、「利用中リソース量」の値を「０」にする。これにより、リソースの積み替えが完了する。

また、故障したリンクが回復し故障フラグがリセットされたときには、代替経路に確保されているリソースを、回復したリンクを含む元の通信経路に積み戻す。リソースの積み戻しは、上述したリソースの積み替えと同様に行えばよい。

以上のように、リンクに故障が発生したときに、そのリンクを含む通信経路に対して確保されていたリソースを別の通信経路に積み替えることにより、リソース管理を継続して行うことが可能となる。

なお、リソースの積み替え（積み戻しを含む）時に、処理内容を示すメッセージを保守端末（図示せず）に送信するとともに、ログを作成するようにしてもよい。これにより、積み替え先の経路を構成するリンクのリソース残量が不足し、リソースの積み替えを適切に行えなかった場合でも、その検証が容易になる。また、リソースの積み替えに対する非課金を保守者に促すことができる。

以上では、物理ＩＦの識別子として「ＭＡＣアドレス」を用いる例を示したが、ＭＡＣアドレスに代えて「物理ＩＦの位置」を用いることもできる。例えば、「物理ポートの位置」を用いることができる。物理ポートの位置は、同一の装置または同一のＩＦ盤（同一のカードの上に複数のポートをもつ基盤）において、例えば１つのＩＦ盤でポートが３つあるとき、装置（ルータ）はこれらの物理位置をport.1/3，port.2/3，port.3/3のように区別する。

また、装置（ルータ）によっては、それぞれの物理ポートもしくはＩＦ毎に、独自にＩＰアドレスをふって管理する場合がある。これらのＩＰアドレスは、実際の通信で宛先に使われることのないＩＰアドレスである。同じ機能をもつルータ間で複数のリンクを仮想的に束ねて使用したいときに、これらのルータ間のみ、違うセグメント、つまり異なるアドレス体系のＩＰアドレスを使用して接続する。他のルータに対しては、これらのＩＰアドレスは隠蔽し、代わりにアドレス体系に沿ったＩＰアドレスをそれぞれのルータがひとつずつ、一組使用する。

本発明は、通信ネットワークを利用した高品質の通信サービスに利用することができる。

本発明の第１の実施の形態に係るリソース管理サーバが適用されるシステムの全体構成を示すブロック図である。 冗長のない通常のリンクのモデルを示す図である。 ＬＡのモデルを示す図である。 テーブルの作成例を説明するためのＬＡ区間を含むモデルを示す図である。 図４に示したモデルに基づいて作成したリンク情報テーブルの一例を示す図である。 図４に示したモデルに基づいて作成した隣接情報テーブルの一例を示す図である。 図４に示したモデルに基づいて作成した経路情報テーブルの一例を示す図である。 ＥＣＭＰの第１のモデルを示す図である。 ＥＣＭＰの第２のモデルを示す図である。 テーブルの作成例を説明するためのＥＣＭＰ区間を含むモデルを示す図である。 図１０に示したモデルに基づいて作成したリンク情報テーブルの一例を示す図である。 図１０に示したモデルに基づいて作成した隣接情報テーブルの一例を示す図である。 図１０に示したモデルに基づいて作成した経路情報テーブルの一例を示す図である。 本発明の第１の実施の形態に係るリソース管理サーバの構成を示すブロック図である。 本発明の第１の実施の形態に係るリソース管理サーバの動作の流れを示すフローチャートである。 図１５におけるステップＳ５のリソース確保処理の流れを示すフローチャートである。 本発明の第２の実施の形態に係るリソース管理サーバの構成を示すブロック図である。 図４に示したモデルに基づいて作成したリンク情報テーブルの他の例を示す図である。 図４に示したモデルに基づいて作成した経路情報テーブルの他の例を示す図である。

符号の説明

１，１０１…リソース管理サーバ、２…通信ネットワーク、３…アプリケーションサーバ、１０…端末情報入力部、１１，１１１…リンク情報収集部、１２，１１２…テーブル作成部、１３，１１３…テーブル記憶部、１４…送受信部、１５，１１５…制御部、３１…アドレスリスト、３２，１３２…リンク情報テーブル、３３…隣接情報テーブル、３４，１３４…経路情報テーブル、５１…メッセージ解析部、５２，１５２…リソース管理部、５３…応答処理部、ＣＲ１〜ＣＲ３，ＣＲ＃Ｃ，ＣＲ＃Ｄ…コアルータ、ＤＮ…宛先ノード、ＥＲ１〜ＥＲ４，ＥＲ＃Ａ，ＥＲ＃Ｂ…エッジルータ、Ｌ２ＳＷ…レイヤ２スイッチ、Ｎ１〜Ｎ４…ノード、Ｓ１〜Ｓ１０，Ｓ２１〜Ｓ２７…ステップ、ＳＮ…起点ノード、Ｔ１〜Ｔ６…端末（Ｔ１…配信サーバ）。

Claims (10)

1. 通信ネットワークに属するノードの間を接続するリンクの識別子にこのリンクのリソース量を対応づけたリンク情報を記憶するリンク情報記憶手段と、前記通信ネットワーク内の通信経路をこの通信経路を構成するリンクの識別子によって表す経路情報を記憶する経路情報記憶手段と、前記経路情報および前記リンク情報を参照し前記通信経路を構成するリンクのリソース量に基づき、前記通信ネットワーク内のリソース管理を行なうリソース管理手段とを備えるリソース管理装置において、
   前記識別子は、前記リンクの起点となる起点ノードと前記リンクの宛先となる宛先ノードとの組合わせが同一の複数のリンクにおいて同一であり、
   前記リソース管理手段は、前記識別子が同一の前記複数のリンクのリソース量に基づきリソース管理を行ない、
   前記識別子が同一の前記複数のリンクは、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせが同一の第１のリンク集合体と、それぞれのリンクを使用して前記起点ノードから前記宛先ノードに至るコストが等しく、かつ、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる第２のリンク集合体とからなり、
   前記リンク情報は、前記リンクが前記第１および第２のリンク集合体のいずれに属するかを表す冗長状態識別子を含むことを特徴とするリソース管理装置。
2. 請求項１に記載のリソース管理装置において、
   前記リソース管理手段は、前記識別子が同一の前記複数のリンクのリソース量の合計に基づきリソース管理を行なうことを特徴とするリソース管理装置。
3. 請求項１または２に記載のリソース管理装置において、
   前記識別子が同一の前記複数のリンクは、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせが同一であることを特徴とするリソース管理装置。
4. 請求項１または２に記載のリソース管理装置において、
   前記識別子が同一の前記複数のリンクは、それぞれのリンクを使用して前記起点ノードから前記宛先ノードに至るコストが等しく、かつ、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なることを特徴とするリソース管理装置。
5. 請求項１〜４の何れか１項に記載のリソース管理装置において、
   前記経路情報は、前記通信経路の起点となる起点ノードと前記通信経路の終点となる終点ノードとの組合わせが同一の複数の通信経路がある場合に、それぞれの通信経路が使用される優先順位を含み、
   前記リソース管理手段は、前記起点ノードと前記終点ノードとの組合わせが同一の複数の通信経路に対し同一の優先順位が付与されている場合に、これらの通信経路のリソースに基づきリソース管理を行なうことを特徴とするリソース管理装置。
6. 通信ネットワークに属するノードの間を接続するリンクの識別子にこのリンクのリソース量を対応づけたリンク情報を作成するステップと、前記通信ネットワーク内の通信経路をこの通信経路を構成するリンクの識別子によって表す経路情報を作成するステップと、前記経路情報および前記リンク情報を参照し前記通信経路を構成するリンクのリソース量に基づき、前記通信ネットワーク内のリソース管理を行うステップとを備えるリソース管理方法において、
   前記リンク情報を作成するステップは、前記リンクの起点となる起点ノードと前記リンクの宛先となる宛先ノードとの組合わせが同一の複数のリンクに対して同一の識別子を付与し、
   前記リソース管理を行うステップは、前記同一の識別子が付与された前記複数のリンクのリソース量に基づきリソース管理を行ない、
   前記同一の識別子が付与された前記複数のリンクは、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせが同一の第１のリンク集合体と、それぞれのリンクを使用して前記起点ノードから前記宛先ノードに至るコストが等しく、かつ、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる第２のリンク集合体とからなり、
   前記リンク情報を作成するステップは、前記リンクが前記第１および第２のリンク集合体のいずれに属するかを表す冗長状態識別子を前記リンク情報に付加することを特徴とするリソース管理方法。
7. 請求項６に記載のリソース管理方法において、
   前記リソース管理を行なうステップは、前記同一の識別子が付与された前記複数のリンクのリソース量の合計に基づきリソース管理を行なうことを特徴とするリソース管理方法。
8. 請求項６または７に記載のリソース管理方法において、
   前記リンク情報を作成するステップは、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせが同一の複数のリンクに対して前記同一の識別子を付与することを特徴とするリソース管理方法。
9. 請求項６または７に記載のリソース管理方法において、
   前記リンク情報を作成するステップは、前記起点ノードから前記宛先ノードに至るコストが等しく、かつ、前記起点ノードにおけるＩＰアドレスと前記宛先ノードにおけるＩＰアドレスとの組合わせがそれぞれ異なる複数のリンクに対して前記同一の識別子を付与することを特徴とするリソース管理方法。
10. 請求項６〜９の何れか１項に記載のリソース管理方法において、
    前記経路情報を作成するステップは、前記通信経路の起点となる起点ノードと前記通信経路の終点となる終点ノードとの組合わせが同一の複数の通信経路がある場合に、それぞれの通信経路が使用される優先順位を前記経路情報に付加し、
    前記リソース管理を行なうステップは、前記起点ノードと前記終点ノードとの組合わせが同一の複数の通信経路に対し同一の優先順位が付与されている場合に、これらの通信経路のリソースに基づきリソース管理を行なうことを特徴とするリソース管理方法。

Images