(57)【要約】本発明は、ＩＰネットワークのリソースマップを提供するリソースマネジャ、その方法、および前記方法のステップを実行するコンピュータプログラム製品に関するものである。前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別と論理アドレスの量に関する情報を備えたリソース情報と統合し、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースの間のマッピングを実行することにより、リソースマップが得られる。
2005522130.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワーク内で利用可能な物理的リソースのマップを、前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別および論理アドレスの量に関する情報を含むリソース情報と統合する（３０３）ステップを実行することにより作成する方法であって、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースのマッピングを実行する（３０４）さらなるステップを特徴とする方法。
【請求項２】
トポロジーマップがトポロジー認識リソースマネジャにより取得される、請求項１に記載の方法。
【請求項３】
ネットワーク要素、例えばルータなどからＳＮＭＰを用いて情報収集することによりマッピングが実行される、請求項１から２いずれか１項に記載の方法。
【請求項４】
前記マッピングがリソースマネジャにより実行される、請求項１から３までのいずれか１項に記載の方法。
【請求項５】
前記リソースマネジャがルータまたはサーバ内に組み込まれている、請求項４に記載の方法。
【請求項６】
前記論理アドレスがＩＰアドレスである、請求項１から５までのいずれか１項に記載の方法。
【請求項７】
請求項１から６までのいずれか１項に記載のステップを実行するためのソフトウェアコード部分を備えた、ＩＰネットワーク内のサーバおよび／またはルータに直接ロードできるコンピュータプログラム製品。
【請求項８】
ＩＰネットワーク内のサーバおよび／またはルータ内の処理手段に、請求項１から６までのいずれか１項に記載のステップの実行を制御させる、読取可能なプログラムを備えた、コンピュータで使用できる媒体に記憶されたコンピュータプログラム製品。
【請求項９】
ＩＰネットワーク内で利用可能な物理的リソースのマップを作成するリソースマネジャであって、前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別および論理アドレスの量に関する情報を含むリソース情報と統合する手段（５０２）を備えたリソースマネジャにおいて、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースのマッピングを実行する手段（５０４）をさらに備えたことを特徴とするリソースマネジャ。
【請求項１０】
トポロジーマップを作成する手段をさらに備えた、請求項９に記載のリソースマネジャ。
【請求項１１】
ネットワーク要素、例えばルータなどからＳＮＭＰを用いて情報収集することにより物理的なリソース情報を取得する手段をさらに備えた、請求項９から１０いずれか１項に記載のリソースマネジャ。
【請求項１２】
前記リソースマネジャがルータまたはサーバ内に組み込まれている、請求項９から１１いずれか１項に記載のリソースマネジャ。
【請求項１３】
前記論理アドレスがＩＰアドレスである、請求項９から１２いずれか１項に記載のリソースマネジャ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ）ネットワークに関する。
【０００２】
より詳細には、本発明は、ＩＰネットワークの利用可能なネットワークリソースのマップを提供するＩＰネットワーク内のリソースマネジャと、その方法、および前記方法の諸ステップを実行するコンピュータプログラム製品に関する。
【背景技術】
【０００３】
最新のネットワーキングの流行は、有線機器および無線機器に対し「オールＩＰ化」（ＩＰ  ａｌｌ  ｔｈｅ  ｗａｙ）を提供することにある。ある最新の目標は、インフラストラクチャを簡素化し、広範なアプリケーションをサポートし、通信サービスへの多様なユーザの要求に対応することである。このことを可能にするため、サービスの差別化とＩＰネットワーク内での動的なリソース管理に対応できる拡張性のあるソリューションへのニーズがある。
【０００４】
インターネットは今やユビキタスで複合サービス型のネットワークになりつつある。つまり、ネットワーク運営者や機器供給者がＩＰネットワークでサービス品質（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ、ＱｏＳ）の差別化を提供すべき強力な商業的根拠が存在している。
【０００５】
研究・標準化団体では、ＱｏＳサポートの開発は、インターネットの信号型ソリューション（水平型ネットワークに用いられるソリューションと幾分類似したもの）を提供することから進展し、今ではよりステートレス（ｓｔａｔｅｌｅｓｓ）なソリューションが有利であるということを認識するに至っている。ＲＳＶＰ（リソース予約プロトコル）は、経路上でイントサーブ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ、統合型サービス）をサポートするルータにおいてフロー毎のサービス品質を設定するように標準化された信号プロトコルである。経路上の各ルータは許可制御を行い、次いで個別アプリケーションのデータストリームを承認して期待されるサービスを提供する。このモデルは複雑すぎてインターネットの基幹に使われるようには拡張できないという意見がある。このモデルを、ネットワークに近いところまで使用を十分拡張できるという別の意見もある。
【０００６】
ルータにおけるフロー毎のＱｏＳ管理の拡張性の問題は、差別化型サービスアーキテクチャ（ディフサーブ）として知られる新たな手法を生んだ。その目的は、ルータでのフロー毎のステートを避けることにより、拡張性のあるＱｏＳサポートを提供することにある。基本概念は、ＩＰパケットのヘッダーが、パケットがルータから与えられるべき処理（ホップ毎の動作）を識別する小ラベル（ディフサーブ・フィールドとして知られる）を含むということである。
【０００７】
差別化型サービスの1つの利点は、インターネットを成功させた有利な特性をこのモデルが保持していることである。つまり、このモデルは、様々な種類の相互接続された物理的ネットワークを介した、拡張性がありステートレスなフォワーディングをサポートする。しかし、この標準型モデルでは、ルータでの差別化型フォワーディングに限られており、そのため、課題は、エンドユーザに予測可能なサービスを提供することにある。
【０００８】
定量的サービス（ベストエフォート型サービスよりは良いが、トラフィックの送信場所と、その時点で他で負担している負荷に依存している）の提供は、ルータでのディフサーブサポートと、半静的な許可制御とサービス提供のためのリソース管理機構のみに頼って行うことができた。定量的な（最低期待度の）サービスを提供するためには、リソースをリソース管理機構により動的に管理しなければならず、約束したサービスを提供するために十分なリソースがネットワーク内にあることを確認する動的な許可制御を必要とする。
【０００９】
ＩＰネットワーク内でのルーティング
データパケットは、ＯＳＰＦ、ＩＳ−ＩＳあるいはＲＩＰなどの良く知られたルーティングプロトコルのうち１つまたはいくつか用いてＩＰネットワーク内でルーティング(すなわち、パケットがネットワークを介して伝送される伝送経路)される。ＯＳＰＦおよびＩＳ−ＩＳはリンクステート型プロトコルに分類され、ＲＩＰは距離ベクトル型プロトコルに分類される。プロトコルは、経路計算とルーティング情報の配布のために用いるアルゴリズムに基づいている。
【００１０】
ドメイン内でリンクステート型プロトコルを稼動させているすべてのルータは、そのドメイン内のすべてのネットワークとルータを知っていてネットワークの完全なルーティング一覧を有している。この情報に基づき経路は典型的には最短経路をもたらすアルゴリズムを用いて計算される。
【００１１】
距離ベクトル型ルータは、直接接続された直近のルータとネットワークについての知識しかない。各距離ベクトル型ルータは、どのネットワークに到達できるかということと、そのコストを通知する。コストは重量制であり、例えば、ネットワークの速度または別のパラメータと関連づけられている。これらの通知は直接接続された近隣ルータにのみ伝播され、それらのルータは次いでその到達可能性をさらに通知する。この通知はネットワークに到達する「最良」経路のみを含み、すべての可能性のある経路を含んでいるわけではない。
【００１２】
リソースマネジャ
リソースマネジャは、１９９８年にルーレオのルーレオ工科大学コンピュータ通信学部、コンピュータサイエンス・電気工学科（Department of Computer Science and Electrical Engineering, Division of Computer Communication, Lulea University of Technology, Lulea, 1998）のオロフ・シェレン（Olov Schelen）の博士論文、「インターネットにおけるサービス品質エージェント」（Quality of Service Agents in the Internet）に記述されたようにＱｏＳエージェントとして紹介された。
【００１３】
リソースマネジャは、利用可能な物理的リソースを常時監視し、予約し、クライアントから入ってくる物理的リソース要求への許可制御を行う要素である。リソースマネジャはサーバまたはルータ内に組み込まれている。許可制御を実行するため、リソースマネジャは以前に許可されたリソース予約の履歴をも保存している。リソースマネジャは、新たなリソース要求に対する許可の決定を、利用可能なリソースの総量と、事前予約により現在予約済の量と、要求されたリソースの量とに基づいて行う。リソースは経時的にスケジューリングされてもよいし、そうでなくてもよい。1つの要求に、異なる種類のリソースから構成され得る複数のリソースリポジトリへの許可制御が含まれていてもよい。最も一般的な種類の管理対象リソースは帯域幅である。リソース管理機構には特定の要求事項がある。エンドユーザにサービスを提供するためには、リソース管理機構はネットワークリソースについて認識していなければならず、約束したサービスに対しリソースを任意の精度（例えば、ポート範囲に関して、一対のサブネット間の集約トラフィックに関して）でスケジューリングする。
【００１４】
この機構はコアドメインと、それに接続されたリーフドメイン両方での精密なリソース管理を提供できなければならない。リーフドメイン、特に、帯域幅が非常に高価なためスペクトル効率が総合的な目標であるライセンスバンド無線アクセスでは、非常に細密な精度のリソース管理（例えば、アプリケーション毎のデータストリーム）への要求があり得る。その性能は、移動性と頻繁な引渡しを処理するのに十分なものでなければならない。コアドメインでは、動的な集約型リソース管理、例えば、宛先ドメイン毎、ＩＰテレフォニ用のポート範囲毎、等）を拡張性の理由で配設してもよい。インターネットサービス・プロバイダーは、事前予約と時間依存性契約（例えば、時刻、曜日）を用いて、互いに大容量帯域幅を交渉するサポートが必要である。企業ネットワークでは、サイト間相互接続のためにきちんと配備されたＬＡＮと隘路リース回線があることが多い。それらは、一定量のリソースを必要とする新たな内部サービス（例えば、マルチメディア会議）を実施するためのサポートを必要とし、これらのアプリケーションのためのリソース要求を管理するために、他のトラフィックへの過度な悪影響を回避するために制御されなければならない。
【００１５】
上記に論じたリソースマネジャは、ネットワークの動的なトポロジーマップを提供するためにも適合されている。前記リソースマネジャを、トポロジー認識リソースマネジャとも称する。マップはトポロジー・データベースに格納されており、ネットワーク要素がどのように接続されているか、すなわち、データパケットをどのようにルーティングすること可能であるかを示す。正確なルーティングおよびリソース情報の利用可能性は、リソース管理と許可制御を実行するシステムにとっては不可欠である。
【００１６】
集約情報あるいは別の不正確な情報を用いて許可制御を行えば、不確定要素が常に介在し、それはネットワークの高度な使用とともに増加する。集約情報とは、異なるソースから共通のノード、すなわち集約ノードへやって来る一組の情報の流れであり、さらに、その一組の情報はそれに続くノードに伝送される。集約情報は、しばしば個々の情報の流れよりも粗い精度で規定され、集約情報の流れには、個々の情報に関する詳細情報はもはや存在しないということになる。詳細情報が手元にあるということは、不確かさを排除するので、不可欠な利点である。不確かさに付随したリスクは、事前許可済みの全トラフィックにパケット損失をもたらす可能性のある、優先度の高いトラフィックへの許可を含む。
【００１７】
入口ノード、あるいはソースネットワークアドレス、および宛先ネットワークアドレスを与えられると、上述の不確かさの対象とならないリソースマネジャは、どのリソースが影響を受けているかを知るために、そのドメインからの正確な経路を発見できなければならない。そのためにはリソースマネジャがネットワークのトポロジーすなわち、そのドメイン内の各ルータのルーティングテーブルを知っていることを要する。リンクステート型プロトコルを用いて、リソースマネジャは、トポロジー・データベース内の必要な情報を収集するために、自らの経路を通知することなくルーティングに参加することができ、リンクステート型ルータとして働くことができる。リンクステート型プロトコル構築の基となっている基本原理は、トポロジー認識リソースマネジャにより要求される同一で完全な情報を、全ルータが有していることを確実にする。
【００１８】
ドメインが距離ベクトル型プロトコルを用いてルーティングされた場合、あるいは静的なルーティングを用いてルーティングされた場合でさえも、すべてのルータが自らに直接接続された別のネットワーク要素の情報しか持ち合わせていないため、相互接続の単純な方法（すなわち、二つのネットワーク要素が情報を交換する）も使用できない。この場合、必要な情報はネットワーク内のネットワーク要素から、例えば経路探索プロトコルあるいは簡易ネットワーク管理プロトコル（ＳＮＭＰ）による方法を用いて取得することができる。
【００１９】
リソースマップ
物理的リソースのマップは、トポロジー・データベース内のルーティング情報を物理的リソース情報と統合することにより提供される。そのマップをリソースマップと呼び、一例を図２に示す。リソースマップ２００は、ソースから宛先への要求を評価するために用いることができる。したがって、リソースマップ２００はネットワークのトポロジーと、各リンクでの利用可能な物理的リソースの総量を示す。
【００２０】
リソースマップは、ルーティング情報を収集することにより作成され、それによりリソースマネジャはリソース情報を収集することができる。インターフェースの型とインターフェース速度は、収集されリソースマネジャが必要とする二つの重要な情報の例である。第１の収集された情報はネットワークを介したパケットの経路を記述するのに対し、第２の収集された情報は利用可能なリソースの量を記述する。この種のリソースマップはオロフ・シェレンの博士論文の例えばページ２６、４１および８６に記述されている。このリソースマップの欠点は、情報が常に正しいとは限らないことがわかっており、それは、要求されたリソース量を保証するためにはリソースを余分に予約しなければならないことにつながるということである。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
したがって、本発明の目的は、ＩＰネットワークの正確なリソースマップを提供することである。
【課題を解決するための手段】
【００２２】
上述した目的は独立請求項の特徴づけ部分に規定する方法、リソースマネジャおよびコンピュータプログラム製品により達成される。
【００２３】
前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別および論理アドレスの量に関する情報を含むリソース情報と統合するステップと、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースのマッピングを実行するステップを備えた本発明により提供される方法は、正確なリソースマップを提供することを可能にする。
【００２４】
前記方法のステップを実行するソフトウェアコード部分を備えた、本発明により提供されるコンピュータプログラム製品は、正確なリソースマップを提供することを可能にする。
【００２５】
前記方法のステップの実行をＩＰネットワーク内のサーバおよび／またはルータ内の処理手段に制御させる読取可能なプログラムを備えた、本発明により提供されるコンピュータプログラム製品は、正確なリソースマップを提供することを可能にする。
【００２６】
前記ＩＰネットワークのネットワークトポロジーのマップを利用する手段と、前記マップを、論理アドレスの識別と量に関する情報を含むリソース情報と統合する手段と、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースの間のマッピングを実行する手段とを備えたリソースマネジャは、正確なリソースマップを提供することを可能にする。
【００２７】
好適な実施の形態は従属項に規定される。
【発明の効果】
【００２８】
本発明の利点は、利用可能なリソースを過大評価しないので、ネットワーク内で必要とされている量よりも多い量が予約されることがないということである。したがって、ネットワークを行き来しているすべての流れのサービス品質が向上する。
【発明を実施するための最良の形態】
【００２９】
図２は、本発明を組み込んでいてもよい例示的なＩＰネットワーク２０５を示す。ネットワークは複数のルータａ−ｄを備えた少なくとも１つのネットワークドメイン２０１−２０４を備えている。ネットワークは１つまたは複数のサーバをも備えていてよい。同一のネットワークドメインまたは異なるドメインに配置された少なくとも２つのルータは、それぞれリソースマネジャを備えている。
【００３０】
上述したように、従来技術のリソースマップからのリソース情報はしばしば不正確である。図１のように、ルータに依存する本発明によれば、インターフェースとルータポートは高価なネットワーク要素であり、そのためしばしば、いくつかの論理アドレス１００がより高価でないリンク層スイッチ１０４を介した接続により物理的インターフェース１０２のうち１つに割り当てられる。リソースマップは、各論理アドレス用に物理的リソース量が存在すると表示するが、そのとき実際は同じ物理的インターフェースに接続されている全論理アドレス間でその量が共有されている。したがって、物理的リソースを過大評価しているので、リソースマップは利用可能なリソースの正確な表示を提供していない。
【００３１】
本発明により、物理的なリソース情報に、ネットワーク層において物理的リソースがネットワークによりどのように使われるかという情報、すなわち、論理アドレスから物理的リソースへのマッピングを追加することにより、正確なリソースマップが達成される。物理的リソースは物理的インターフェースとも称され、また、論理アドレスは仮想アドレスとも称されることに留意するべきである。物理的なリソース情報は、リンク層上の物理的リソースの識別と量を含む。物理的なリソース情報は、トポロジー認識リソースマネジャから得たトポロジー情報と統合される。トポロジー認識機能は手動で設定されるか、または、別の適切な方法により実施される。トポロジー情報とは、ネットワーク層を行き来するパケットのルートを記述したルーティング情報であり、ネットワークトポロジーの論理マップがこうして提供される。
【００３２】
論理アドレス（例えばＩＰアドレス）から物理的リソースへのマッピングは、本発明により物理的リソースが複数の論理アドレスの間で共有されているかどうかを判定するためにリソースマネジャによって実行される。しかし、マッピングに関して同様の機能を持つ別の要素を用いることも可能である。マッピング情報は、新規ルータが発見されたとき、あるいは手動で設定されたとき、異なるＭＩＢテーブルから情報を収集するＳＮＭＰを用いて取得してもよい。厳密にどのＳＮＭＰにＭＩＢテーブルが情報を要求するかは、ルータがどのＲＦＣ基準をサポートしているかによる。ＲＦＣとは、１つまたは複数の機能の仕様である。ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）はインターネットでｗｗｗ．ｉｅｔｆ．ｏｒｇから入手可能であり、インターネット・エンジニアリング・タスクフォース（ＩＥＴＦ）により管理されている。
【００３３】
以下に、物理的インターフェースがＳＮＭＰを介してＩＰアドレスに基づきどのようにして配置されているかを記述する。初期のＲＦＣでは、それは種々のテーブルに見られるが、後からのＲＦＣではスタック内のルートを見つけなければならない。ＲＦＣは、新規の機能がネットワークに導入されると定期的に更新され、ＲＦＣ内に修正が記述される。
【００３４】
どのＲＦＣがサポートされているかによって異なる種々の選択肢ごとに、論理アドレスから物理的リソースへのマッピングの例を下記に記述する。
【００３５】
ルータがＲＦＣ１１５８（Ｍ．Ｔ．ローズ、ＴＣＰ／ＩＰベースのインターネットのネットワーク管理のための管理情報ベース：ＭＩＢ−ＩＩ[Rose M. T., Management Information Base for Network management of TCP/IP-based Internets: MIB-II, RFC1158]と、ＲＦＣ１２１３（Ｋ．マクローリー他、ＴＣＰ／ＩＰベースのインターネットのネットワーク管理のための管理情報ベース：ＭＩＢ−ＩＩ[McCloghrie K. et Al, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, IETF, RFC 1213]）をサポートしている場合、物理的インターフェースはインターフェーステーブルｉｆＴａｂｌｅに記述されている。ＩＰアドレステーブルと物理的インターフェースの間の実際のマッピングは、アドレッシング情報テーブルｉｐＡｄｄｒＴａｂｌｅ内のインターフェースインデックスｉｐＡｄＥｎｔＩｆＩｎｄｅｘに記述されている。
【００３６】
ＩＰアドレスからルーティングテーブル内の送出物理的インターフェースへのマッピングは、ＲＦＣ１１５８ではＲＣ１１５８ｉｐＲｏｕｔｉｎｇＴａｂｌｅ内のｉｐＲｏｕｔｅＥｎｔＩｆｌｎｄｅｘフィールドにより、あるいは、ＲＦＣ１２１３ではｉｐＲｏｕｔｅＴａｂｌｅにより記述されている。
【００３７】
最後に、論理アドレス（ｉｐＮｅｔＴｏＭｅｄｉａＮｅｔＡｄｄｒｅｓｓ）をその物理的インターフェースインデックスにマッピングするＩＰアドレス変換テーブルｉｐＮｅｔＴｏＭｅｄｉａ内のｉｐＮｅｔＴｏＭｅｄｉａＩｆＩｎｄｅｘフィールドをも用いてもよい。それは、ＲＦＣ１１５８より前にＲＦＣ内で用いられた以前のａｔＴａｂｌｅを廃止する。
【００３８】
ＲＦＣ１３５４（Ｆ．ベーカー、ＩＰフォワーディングテーブルＭＩＢ［Baker F., IP Forwarding Table MIB, RFC1354］）がサポートされている場合、ＲＦＣ１３５４のＩＰフォワーディングテーブルｉｐＦｏｒｗａｒｄＴａｂｌｅがＲＦＣ１２１３のｉｐＲｏｕｔｅＴａｂｌｅに優先する。(ｉｐｒｏｕｔｅｔａｂｌｅはＲＦＣ１１５８には存在せず、ＲＦＣ１２１３には導入されている。)ＩＰフォワーディングテーブルｉｐＦｏｒｗａｒｄＴａｂｌｅでは、マッピングはフィールドｉｐＦｏｒｗａｒｄＩｆＩｎｄｅｘで記述されている。ＲＦＣ２０９６（Ｆ．ベーカー、ＩＰフォワーディングテーブルＭＩＢ［Baker F., IP Forwarding Table MIB, RFC2096］）がサポートされている場合、ＲＦＣ２０９６がＲＦＣ１３５４に優先するが、ｉｐＦｏｒｗａｒｄＩｆＩｎｄｅｘはその変更の間中一貫している。ＲＦＣ２０９６に、ＩＰ ＣＩＤＲ ルートテーブルｉｐＣｉｄｒＲｏｕｔｅＴａｂｌｅが、インターフェースフィールドｉｐＣｉｄｒＲｏｕｔｅＩｆｌｎｄｅｘとともに追加される。
【００３９】
ＲＦＣ２０１１（Ｋ．マクローリー他、ＳＭＩｖ２を用いたインターネットプロトコルのためのＳＭＩｖ２管理情報ベース［McCloghrie K., SNMPv2 Management Information Base for the Internet Protocol using SMIv2］）では、アドレス変換テーブルはテーブルｉｐＮｅｔＴｏＭｅｄｉａｂｌｅ内に記述され、インターフェースフィールドはフィールドｉｐＮｅｔＴｏＭｅｄｉａＩｆｌｎｄｅｘである。フィールド（ｉｐＮｅｔＴｏＭｅｄｉａＩｆｌｎｄｅｘ）はフィールドａｔＴａｂｌｅと同じマッピングを備えている。
【００４０】
ＲＦＣ１５７３（Ｋ．マクローリー他、ＭＩＢ−ＩＩのインターフェースグループの発展［McCloghrie K. et Al, Evolution of the Interface Group of MIB-II, RFC1573］）では、インターフェース間の関係を記述するためにインターフェーススタックの概念が導入された。このことは、インターフェーステーブル内のインターフェースは必ずしも物理的インターフェースでなくてもよくて、物理的インターフェースの副インターフェースまたは副副インターフェースであってもよいことを意味する。このことを図３に示す。物理的リソースをそのようなインターフェースにどうマッピングするか、および、その物理的リソースが複数の仮想インターフェースで共有されている場合、その物理的リソースがどのように共有されているかを判定するため、インターフェーススタックからの情報を収集して分析しなければならない。ＲＦＣ２２３３（Ｋ．マクローリー他、ＳＭＩｖ２を用いたインターフェースグループＭＩＢ［McCloghrie K. et Al, The Interface Group MIB using SMIv2, RFC2233］）がサポートされている場合、ＲＦＣ２２３３はＲＦＣ１５７３に取って代わり、ＲＦＣ２８６３（Ｋ．マクローリー他、インターフェースグループＭＩＢ［McCloghrie K. et Al, The インターフェース Group MIB, RFC2］）がサポートされている場合、ＲＦＣ２８６３はＲＦＣ２２３３に取って代わるが、インターフェースタックはこれらの変化の間中一貫性がある。(番号が大きいＲＦＣは、番号が小さいＲＦＣよりも優先度が高い。有効な機能はＲＦＣに高い優先度で記述されている。)しかし、古いルータは、ＲＦＣ１５７３およびＲＦＣ２２３３などのように凌駕されたＲＦＣに従って稼動してもよい。
【００４１】
ルータがこれらの基準のいずれにも準拠せず、論理インターフェースもインターフェーステーブルに表示されている場合、記述ｉｆＤｅｓｃｒと、インターフェーステーブル内のインターフェースがｉｆＴａｂｌｅをインターフェース接続する型ｉｆＴｙｐｅを収集しなければならない。インターフェースの型と記述を用いることにより、どのインターフェースが論理インターフェースであり、どの物理的インターフェースにそれらが接続されているかを推理するためベンダーごとの解析を行うことが可能となる。
【００４２】
論理的トポロジーマップからの情報と、論理アドレスと物理的リソースの間のマッピングを含む利用可能な物理的リソースの情報を統合することにより、正確なリソースマップが提供される。
【００４３】
したがって、上述した方法を用いることにより、ＩＰネットワークの正確な物理的および論理的表示を構築することができ、それにより利用可能なリソースの正確な量に基づく許可制御を実行することができる。
【００４４】
本方法の1実施例を図４の流れ図に示す。
３００：開始
３０１：ルーティングプロトコルを監視し、トポロジーマップを作成するためにルーティング情報を取得する。
３０２：トポロジーマップへの変更を検出した場合、ルータの変更が発生したかどうかを調査する。
３０３：ルータ変更があった場合、その変更があったルータから情報を得るためにリソース（例えば、そのルータ）を探索する。トポロジー情報を、その変更があったルータから得た情報と統合する。ルータの変更がない場合はステップ３０１を繰り返す。
３０４：利用可能な物理的リソースの情報を得るため、変更があったルータのＩＰアドレスと物理的インターフェース間のマッピングを行う。リソースマップは、トポロジーマップと、利用可能な物理的リソースに関する情報を統合して再構築（または作成）される。
【００４５】
本方法は、本方法のステップを実行するソフトウェアコード手段を備えたコンピュータプログラム製品により実行される。該コンピュータプログラム製品は、ＩＰネットワーク内のルータまたはサーバの処理手段上で稼動される。コンピュータプログラムは、直接読み込むか、または、フレキシブルディスク、ＣＤ、インターネット等のコンピュータで使用できる媒体から読み込む。
【００４６】
本発明に係わる方法はＩＰネットワーク内のルータまたはサーバのリソースマネジャ内で、あるいは、同様の機能を有する別の要素内で実行される。
【００４７】
図５によるリソースマネジャ５００は、前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別と論理アドレスの量に関する情報を備えたリソース情報と統合する手段５０２と、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースの間のマッピングを実行する手段５０４を備えている。
【００４８】
本発明は上述した好適な実施の形態に限定されるものではない。種々の変更形態、変形形態または同様な形態を用いてもよい。したがって、上述の実施例を、添付の請求項により規定される本発明の範囲を限定するものと理解すべきではない。
【図面の簡単な説明】
【００４９】
【図１】従来技術によるコスト効率の良いネットワークデザインの一例を示す。
【図２】リソースマップを示す。
【図３】本発明によって論理アドレスが物理的インターフェースにどのように接続されるかを示す。
【図４】本発明に係わる方法のフローチャートを示す。
【図５】本発明に係わるリソースマネジャを示す。
【符号の説明】
【００５０】
１００  論理アドレス
１０２  物理的インターフェース
１０４  リンク層スイッチ
２００  リソースマップ
２０５  ＩＰネットワーク
５００  リソースマネジャ
５０２  統合手段
５０４  マッピング実行手段
【図１】
2005522130.tif 000003
【図２】
2005522130.tif 000004
【図３】
2005522130.tif 000005
【図４】
2005522130.tif 000006
【図５】
2005522130.tif 000007
【手続補正書】
【提出日】平成16年4月16日(2004.4.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＩＰネットワーク内でインターフェースレベルで利用可能な物理的リソースのマップを作成する方法であって、前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別および論理アドレスの量に関する情報を含むリソース情報と統合する（３０３）ステップを備えた方法において、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースのマッピングを実行する（３０４）さらなるステップを特徴とする方法。
【請求項２】
トポロジーマップがトポロジー認識リソースマネジャにより取得される、請求項１に記載の方法。
【請求項３】
ネットワーク要素、例えばルータなどからＳＮＭＰを用いて情報収集することによりマッピングが実行される、請求項１から２いずれか１項に記載の方法。
【請求項４】
前記マッピングがリソースマネジャにより実行される、請求項１から３までのいずれか１項に記載の方法。
【請求項５】
前記リソースマネジャがルータまたはサーバ内に組み込まれている、請求項４に記載の方法。
【請求項６】
前記論理アドレスがＩＰアドレスである、請求項１から５までのいずれか１項に記載の方法。
【請求項７】
請求項１から６までのいずれか１項に記載のステップを実行するためのソフトウェアコード部分を備えた、ＩＰネットワーク内のサーバおよび／またはルータに直接ロードできるコンピュータプログラム製品。
【請求項８】
ＩＰネットワーク内のサーバおよび／またはルータ内の処理手段に、請求項１から６までのいずれか１項に記載のステップの実行を制御させる、読取可能なプログラムを備えた、コンピュータで使用できる媒体に記憶されたコンピュータプログラム製品。
【請求項９】
ＩＰネットワーク内でインターフェースレベルで利用可能な物理的リソースのマップを作成するリソースマネジャであって、前記ＩＰネットワークのトポロジーマップを、論理アドレスの識別および論理アドレスの量に関する情報を含むリソース情報と統合する手段（５０２）を備えたリソースマネジャにおいて、前記ＩＰネットワーク内で前記論理アドレスと物理的インターフェースのマッピングを実行する手段（５０４）をさらに備えたことを特徴とするリソースマネジャ。
【請求項１０】
トポロジーマップを作成する手段をさらに備えた、請求項９に記載のリソースマネジャ。
【請求項１１】
ネットワーク要素、例えばルータなどからＳＮＭＰを用いて情報収集することにより物理的なリソース情報を取得する手段をさらに備えた、請求項９から１０いずれか１項に記載のリソースマネジャ。
【請求項１２】
前記リソースマネジャがルータまたはサーバ内に組み込まれている、請求項９から１１いずれか１項に記載のリソースマネジャ。
【請求項１３】
前記論理アドレスがＩＰアドレスである、請求項９から１２いずれか１項に記載のリソースマネジャ。
【国際調査報告】
2005522130.tif 000008
2005522130.tif 000009
2005522130.tif 000010