JP3897911B2 - ネットワーク管理情報収集方法およびネットワーク管理装置ならびに管理対象装置 - Google Patents
ネットワーク管理情報収集方法およびネットワーク管理装置ならびに管理対象装置 Download PDFInfo
- Publication number
- JP3897911B2 JP3897911B2 JP23864098A JP23864098A JP3897911B2 JP 3897911 B2 JP3897911 B2 JP 3897911B2 JP 23864098 A JP23864098 A JP 23864098A JP 23864098 A JP23864098 A JP 23864098A JP 3897911 B2 JP3897911 B2 JP 3897911B2
- Authority
- JP
- Japan
- Prior art keywords
- mib
- network management
- collection mode
- difference
- request
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
【発明の属する技術分野】
【０００１】
本発明は、複数の管理対象ノード（以下、エージェントともいう）と少なくとも一つのネットワーク管理装置（以下、マネージャともいう）からなるネットワークのネットワーク管理方式に関し、特にネットワーク管理プロトコル（Simple Network Management Protocol：以下、ＳＮＭＰという）を用いて管理情報ベース（Management Information Base：以下、ＭＩＢという）の収集を行うネットワーク管理情報収集方式およびそれに用いるネットワーク管理装置ならびに管理対象ノードに関する。
【０００２】
【従来の技術】
従来、複数のエージェントと少なくとも一つのマネージャからなるネットワークにおいて、ＳＮＭＰを用いてマネージャからエージェントで保持しているＭＩＢを収集する場合のＭＩＢ収集方法としては、
▲１▼「Get-Request」
▲２▼「Get-Next-Request」
▲３▼「Get-Bulk-Request」（ＳＮＭＰｖ２の仕様）
を用いてマネージャからエージェントにＭＩＢの値を問い合わせるコネクション形式の方法と、
▲４▼「Trap」
を用いてエージェントからマネージャに対して自立的に通知するコネクションレス形式の方法があった。
【０００３】
▲１▼「Get-Request」は、マネージャで収集したいＭＩＢを指定してエージェントに問い合わせる方法であり、たとえば１０００個のＭＩＢをエージェントが実装していたとすると、マネージャはＭＩＢを収集する度にエージェントに対して１０００回の問い合わせを行う必要があり、以下の問題が発生した。
・マネージャとエージェント間の通信量が多くなり、それと同じ通信路を共有している他の通信を妨げることや、しいては長時間通信帯域を占有してしまうことがある。
・管理対象ノード数が多いと、全体のＭＩＢを収集するのに多大な時間がかかる。
・管理項目数をさらに増やそうとしたとき、ＭＩＢの収集時間もさらに増えてしまうので安易に増やすことができない。
・マネージャとエージェント間で１０００回の問い合わせを行わなければならないので、その間マネージャのエージェントに対する他のオペレーションが困難になりオペレータの負担になる。
・マネージャおよびエージェントは、１０００回の問い合わせに対する処理を行う必要があるので、それぞれその分の処理負荷がかかってしまう。またそれの是正として高性能な機器を求めようとするとその分、高価な機器を購入する必要が発生しユーザの負担がかかる。
・マネージャがエージェントの状態をリアルタイムにオペレータに伝えるためにエージェントに対してポーリング的にＭＩＢを収集すると、その間通信帯域の占有および処理負荷がかかってしまいネットワーク管理のためにネットワークヘ悪影響を与えてしまう。
【０００４】
▲２▼「Get-Next-Request」は、マネージャでＭＩＢを指定してエージェントに対して問い合わせ、エージェントはそのＭＩＢから名前が辞書順で次に実装されているＭＩＢを探し出してそれ毎に答える方法であり、マネージャがエージェントのＭＩＢ実装状態を認識していないときなどに用いる方法である。この方法も同様の例として１０００個のＭＩＢをマネージャに個々に収集する必要があり「Get-Request」同様の問題が発生する。
【０００５】
▲３▼「Get-Burk-Request」は、マネージャで収集したいＭＩＢを複数個まとめてエージェントから収集できる方法であるが、収集するデータ量は結局同様の例として１０００個になるため、この方法でも通信帯域の占有および処理負荷の増加を招くことが問題となる。
【０００６】
▲４▼「Trap」は、エージェントからマネージャに自立的な状態変化（ＭＩＢの状態変化も含まれる）を通知する方法であるが以下の問題が発生した。
・コネクションレス方式であるので、エージェントからマネージャヘの到達確認が行われず通信経路上で紛失する可能性がある。またその紛失があったときの救済方式も実現方式は存在するがその機能のインプリメントを行う必要が発生し、マネージャおよびエージェントの開発ベンダーに負担がかかってしまう。
・単位時間に状態変化が多発するとその分エージェントからマネージャに対する「Trap」通知の件数が増加してしまい通信帯域の圧迫および、マネージャおよびエージェントの処理負荷の増加が発生してしまう。また「しきい値」による抑止または通知をマネージャおよびエージェントにインプリメントしようとすると、それぞれの開発ベンダーに負担がかかってしまう。
・「Trap」をＭＩＢの項目数分マネージャおよびエージェントでインプリメントする必要があるので（たとえばＭＩＢが１０００個だとTrapも１０００個必要）それぞれの開発ベンダーにそれを開発する負担が発生する。
【０００７】
【発明が解決しようとする課題】
本発明は、マネージャとエージェント間でＭＩＢの収集量および収集時間がかかってしまっていた従来のＭＩＢ収集方式に対して、収集量および収集時間の短縮化がはかれるＭＩＢ収集方式を提供することを課題とする。
さらに、本発明は、ＳＮＭＰｖ１およびＳＮＭＰｖ２双方に実装できるＭＩＢ収集方式を提供することを課題とする。
本発明は、以上に述べた課題を達成するためのネットワーク管理情報収集方式を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明は、上記課題を解決するために、ネットワーク管理装置と、自装置のＭＩＢを記憶する記憶部を有する管理対象装置を通信回線を介して接続したネットワークの管理情報収集方法において、前記ネットワーク管理装置が、前記管理対象装置に対して全てのＭＩＢの収集を行うため、前記管理対象装置に対して標準収集モード指定指示を行うステップと、前記管理対象装置が、前記標準収集モード指定指示を受信すると、自装置を標準収集モードとするステップと、前記ネットワーク管理装置が、標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを収集するステップと、前記ネットワーク管理装置が、前記管理対象装置の全てのＭＩＢを収集した後、前記管理対象装置に対して、差分収集モード指定指示を行うステップと、前記管理対象装置が、前記ネットワーク管理装置より、差分収集モード指定指示を受信すると自装置を標準収集モードから差分収集モードとするステップと、前記ネットワーク管理装置が、前記差分収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の差分のＭＩＢを収集するステップと、前記管理対象装置が、自装置を差分収集モードとした後に、自装置にＭＩＢ削除が発生した場合であって、前記ネットワーク管理装置よりＭＩＢ要求があった場合は、前記ネットワーク管理装置に対して自装置のＭＩＢの削除を通知するステップと、前記ネットワーク管理装置が、前記管理対象装置よりＭＩＢ削除の通知を受信すると、前記収集した前記管理対象装置の全てのＭＩＢを削除するステップと、前記ネットワーク管理装置が、前記全てのＭＩＢの削除を行った後に、前記管理対象装置に対して全てのＭＩＢの収集を行うため、標準収集モード指定指示を行うステップと、前記管理対象装置が、前記標準収集モード指定指示を受信すると、自装置を差分収集モードから標準収集モードとするステップと、前記ネットワーク管理装置が、標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを再収集するステップと、を行うようにした。また、本発明は、管理対象装置の情報を通信回線を介して収集するネットワーク管理装置は、前記ＳＮＭＰマネージャ制御部は、前記管理対象装置の全てのＭＩＢを収集するとともに、前記記憶部に記憶し、前記記憶部に記憶した後、前記管理対象装置に対して、差分収集指示を行う手段と、前記管理対象装置におけるＭＩＢの削除の有無を問合せて、前記管理対象装置よりＭＩＢ削除の応答を受信すると、前記記憶部に記憶した前記管理対象装置の全てのＭＩＢを削除し、当該管理対象装置の全てのＭＩＢの再取得動作を行う手段と、を有する。さらに、本発明は、通信回線を介してネットワーク管理装置に情報を管理される管理対象装置であって、自装置のＭＩＢを記憶する記憶部と、前記ネットワーク管理装置よりのＭＩＢ収集指示に従いＭＩＢを送出するＳＮＭＰエージェント制御部とを有し、前記ＳＮＭＰエージェント制御部は、前記ネットワーク管理装置より、差分収集指示を受信すると自装置を差分収集モードとし、それ以降に前記ネットワーク管理装置よりＭＩＢ収集指示を受信した場合、変化のあるＭＩＢのみを前記ネットワーク管理装置に送信する手段と、前記ネットワーク管理装置よりＭＩＢを削除したかの問合せがあった場合に、自装置のＭＩＢの削除の有無を通知する手段と、を有する。
【０００９】
【作用】
本発明では、マネージャがエージェントからＭＩＢを収集するとき、ＭＩＢの差分のみを収集ればよいので、ＭＩＢの収集量および収集時間を短縮化できる。また、ＭＩＢ定義のインタフェースを用いることで、ＳＮＭＰｖ１およびＳＮＭＰｖ２を用いたそれぞれのネットワーク管理システムに実装が可能となる。
【００１０】
【発明の実施の形態】
以下、図面を用いて本発明にかかるネットワーク管理システムの実施の形態を説明する。
図１を用いて、本発明にかかるネットワーク管理システムのシステム構成例を説明する。図１は、本発明のネットワーク管理システムのシステム構成例を示すブロック図である。
ネットワーク管理システムは、少なくとも一つのネットワーク管理装置（マネージャ）１０と、複数の管理対象ノード（エージェント）２０を通信回線３０で接続して構成される。
ここではネットワークの構成は、スター型のネットワークトポロジーで示してあるが、本発明におけるネットワークは必ずしもスター型に限定されるべきものではなく、メッシュ型や、バス型、リング型をも含むものである。また、エージェントは管理対象ノードに内蔵されるものを示してあるが、外付けの機器をＳＮＭＰで管理するための代理エージェント方式も含むものである。
【００１１】
マネージャ（ネットワーク管理装置）１０は、図３に示す構成例を備えており、エージェント２０に対して図２に示すシーケンスおよび図５に示すＭＩＢを通信回線３０を用いて本発明の実施を行う手段を備えている。
【００１２】
エージェント２０は図４に示す構成例を備えており、マネージャ１０に対して図２に示すシーケンスおよび図５に示すＭＩＢを通信回線３０を用いて本発明の実施を行う手穎を備えている。
【００１３】
図２を用いて、マネージャ１０とエージェント２０間でＭＩＢの設定／参照を実現するＳＮＭＰのプロトコル方式を説明する。図２は、ＳＮＭＰのプロトコル方式図である。
本発明では、マネージャ１０とエージェント２０間で本シーケンスを用いてネットワーク管理情報収集方式を実現する。
【００１４】
第一のシーケンスＰ１は、マネージャからエージェントに対して所定のＭＩＢの取出要求「Get-Request」を送出し、エージェントがこれに応えて対応するＭＩＢの取出応答「Get-Responce」を送出するプロトコルである。
【００１５】
第２のシーケンスＰ２は、マネージャからエージェントに対して所定のＭＩＢの次のＭＩＢの取出要求「Get-Next-Request」を送出し、エージェントがこれに応えて順次ＭＩＢの取出応答「Get-Responce」を送出するプロトコルである。
【００１６】
第３のシーケンスＰ３は、複数のＭＩＢを取得する場合のプロトコルで、マネージャからエージェントに対して複数のＭＩＢの取出要求「Get-Bulk-Request」を送出し、エージェントがこれに応えて複数のＭＩＢの取出応答「Responce」を送出するプロトコルである。
【００１７】
第４のシーケンスＰ４は、エージェントに対してマネージャの要求する値の設定を要求する場合のプロトコルで、マネージャからエージェントに対して「Set-Request」を送出し、エージェントがこれに応えて要求「Get-Responce」を送出するプロトコルであり、具体例としてアラームランプの滅火、回線スピードの改定などを行う。
【００１８】
第５のシーケンスＰ５は、エージェントからマネージャに対して自立的に報告する場合のプロトコルで、エージェントから「Trap」を送出するプロトコルであり、障害発生情報などを送出する。
【００１９】
この実施の形態では、マネージャからの「Get-Next-Request」Ｐ２に対してエージェントがＭＩＢの差分収集に応答する方式を説明するが、必ずしもそれに限ったことではなく、「Get-Bulk-Request」Ｐ３に対してエージェントがＭＩＢの差分収集に応答する方式も含むものである。
【００２０】
図３を用いて、本発明に使用するネットワーク管理装置１０の構成を説明する。図３は、ネットワーク管理装置（マネージャ）１０の構成例を示すブロック図である。
ネットワーク管理装置１０は、下位プロトコルスタック１１と、ＳＮＭＰ処理部１２と、ＳＮＭＰマネージャ制御部１３と、画面制御部１４と、ネットワーク管理情報表示画面１５と、ＭＩＢテーブル記憶部１６とを有して構成される。
【００２１】
下位プロトコルスタック１１は、ハードウエアとソフトウエアから構成されて下位インタフェースを司り、エージェントとの通信を行う通信回線３０に接続される。ＳＮＭＰ処理部１２は、ソフトウエアによって構成され、ＳＮＭＰ送受信処理を行う。ＳＮＭＰマネージャ制御部１３は、本発明のネットワーク管理情報収集方式を制御する。画面制御部１４は、ネットワーク管理装置１０の画面を制御する。ネットワーク管理情報表示画面１５は、管理対象ノードの状態を表示する。ＭＩＢテーブル記憶部１６は、管理対象ノードのＭＩＢの記憶制御を行い、ＭＩＢ情報の記憶媒体として用いるＭＩＢテーブル１６１が設けられる。
【００２２】
図４を用いて、エージェント２０の構成を説明する。図４は、管理対象ノード（エージェント）２０の構成例を示すブロック図である。
管理対象ノード２０は、下位プロトコルスタック２１と、ＳＮＭＰ処理部２２と、ＳＮＭＰエージェント制御部２３と、ＭＩＢテーブル記憶部２４とを有して構成される。
【００２３】
下位プロトコルスタック２１は、ハードウエアとソフトウエアから構成されて下位インタフェースを司り、マネージャとの通信を行う通信回線３０に接続される。ＳＮＭＰ処理部２２は、ソフトウエアによって構成され、ＳＮＭＰ送受信処理を行う。ＳＮＭＰエージェント制御部２３は、本発明のネットワーク管理情報収集方式を制御する。ＭＩＢテーブル記憶部２４は、ＭＩＢの記憶制御を行い、ＭＩＢ情報の記憶媒体として用いるＭＩＢテーブル２４１を備えている。
【００２４】
ここでは、ＭＩＢテーブル記憶部２４およびＭＩＢテーブル２４１として示してあるが必ずしもＭＩＢのデータベースとして制御および記憶しているものではなく、メモリデータとして装置固有の制御および記憶する方式をも含むものである。
【００２５】
図５を用いて、本発明で用いるＭＩＢの定義の例（ＳＮＭＰｖ１）を説明する。
ＭＩＢ定義として、エージェントがマネージャにネットワーク管理情報として見せるべき既存のＭＩＢ情報ＭＩＢ１〜ＭＩＢ４と、特に本発明で用いる差分収集モード実現用ＭＩＢであるＭＩＢ５とＭＩＢ６を備えている。
ＭＩＢ５はマネージャからエージェントに対して差分収集モードまたは標準収集モードの指定または参照を可能とする。ＭＩＢ６はマネージャからエージェントに対してＭＩＢの差分状態を参照可能とする。
【００２６】
ここではＭＩＢ５とＭＩＢ６は１つのＭＩＢグループ（ここではＭＩＢ１〜ＭＩＢ４）に対して１組、差分収集モード実現用にマネージャとエージェント間の取り決めとして定義した例を示したが、必ずしもそれに限ったことではなく、管理対象ノード毎に１組定義する方式や、差分収集したいＭＩＢのエントリ毎に１組定義する方式や、さらには管理する側となるマネージャ毎（マネージャｎ重化用）に１組定義する方式も含むものである。
また、ここではＳＮＭＰｖ１での定義例を示しているが必ずしもそれに限ったことではなくＳＮＭＰｖ２での定義方法をも含むものである。
【００２７】
図６を用いて、差分収集モードの実行シーケンス例を説明する。
まず、マネージャは管理対象ノードのＭＩＢを全収集するために、エージェントに対してシーケンスＳ１に示す「標準収集モード」の指定を行う。エージェントはそれをトリガにマネージャがそれ以降の「Get-Next-Request」に対する応答を標準プロトコル仕様での「Get-Responce」で応答してほしいと要求していることが認識できる。
ＭＩＢの実装数分繰り返されるシーケンスＳ２と、ＭＩＢが終了したことを示すシーケンスＳ３が終わると、それ以降はＭＩＢの差分のみをマネージャが収集すれば良いためマネージャはエージェントに対してシーケンスＳ４に示す「差分収集モード」の指示を行う。エージェントはそれ以降の「Get-Next-Request」に対する応答を差分があるＭＩＢだけに限定すればよいことを認識できる。
定期的な差分収集ではマネージャはまずエージェント側に自立的なＭＩＢの削除があったかどうかシーケンスＳ５にて確認を行う。これはＭＩＢの削除があったとき「Get-Next」では削除ＭＩＢがスキップされるためマネージャがその差分を認識できなくなりマネージャのＭＩＢテーフルに削除ＭＩＢが残ってしまうのを防ぐために行う。その手段は図７，図８で別途説明する。
【００２８】
差分のあるＭＩＢ収集はシーケンスＳ６での「Get-Next」の繰り返しで実現し、差分ＭＩＢの全収集終了のマネージャ側認識手段はシーケンスＳ７の「No-Such-Name」応答があつたことで実現する。これによりたとえば全くＭＩＢの差分がないときは１回目のシーケンスＳ６ですぐ「No-Such-Name」となり、少ない通信でマネージャはエージェントの全ＭＩＢ状態を把握することが可能となり、収集量および収集時間の短縮化をはかることができる。
【００２９】
ここでは差分があるＭＩＢを応答する方式を示したが、これに限ったことではなく、ＭＩＢの状態変化の装置特性に合わせ、変わる可能性のあるＭＩＢだけを差分ありとして扱う簡易的な方式や、マネージャから見て差分はないが状態変化によりもとの状態に戻ったＭＩＢも差分ありとして扱う方式や、例外的に差分が管理できなくなる状態が発生し、全ＭＩＢを差分ありとして扱う方式も含むものである。
【００３０】
図７を用いて、マネージャから差分収集する周期タイミングの間にＭＩＢの削除があったときの実行シーケンス例を説明する。
ＭＩＢ削除が発生したトリガＳ１１の後にマネージャの定期的な差分収集が発生するとマネージャからシーケンスＳ１２のＭＩＢ差分状態確認要求がありエージェントはＭＩＢの削除があったことをその応答として返答する。マネージャはそれをトリガにマネージャ内ＭＩＢの全削除を行う。これはＭＩＢの削除をマネージャが認識する方式の１つの手段であり、最初から全収集することでマネージャ内ＭＩＢとエージェント内ＭＩＢの同期をとることができるために行う。
マネージャはＭＩＢの全収集をするため、エージェントに対してシーケンスＳ１４に示す「標準収集モード」の指示を行う。これがないとエージェントは「差分収集モード」のままの応答形態をとってしまう可能性があるため、これを行う。
この後マネージャはシーケンスＳ１５、Ｓ１６に示すＭＩＢの全収集を行うことで、エージェントとのＭＩＢ状態の同期をとる。
【００３１】
ここではエージェント側のＭＩＢの削除によりマネージャのＭＩＢを全削除しているが、これに限ったことではなく、削除したＭＩＢをリスト形式でマネージャに見せる方式を採用することで、削除ＭＩＢの同期をとる方法をも含むものである。
また、ここでは、マネージャ内ＭＩＢの全削除をＭＩＢの全収集の前に行っているが、ネットワーク管理仕様として全収集の前の状態を保持しておきたいときはその順序が逆になる方式をも含むものである。
また、ここではＭＩＢ差分状態のＭＩＢをマネージャから指定して確認する方式を説明しているが、本ＭＩＢを差分管理対象となるＭＩＢグループの先頭のみまた、は、先頭および最後に定義することで、「Get-Next-Request」だけによるＭＩＢ削除のマネージャ側認識を可能とできる方式をも含むものである。
【００３２】
図８はマネージャから差分収集しているときにＭＩＢの削除があったときの実行シーケンス例を示す図である。
ＭＩＢの削除が発生したトリガＳ２３があるとエージェントは差分収集シーケンスＳ２４に対する応答を「Gen-Error」で応答し、マネージャに差分収集モードでの応答ができなくなったことをマネージャに認識させる。以降の処理は図７でのシーケンスＳ１２以降と同様である。
【００３３】
マネージャのＭＩＢ収集フローの例を示す図９を用いて、マネージャのＭＩＢ収集処理を説明する。
図９は、図６〜図８に示した実行シーケンスのマネージャ側処理をまとめたフローチャートであり、マネージャとエージェント間の差分収集によるＭＩＢ同期あわせを実現するために特にＳＮＭＰマネージャ制御部に有するものである。
マネージャ処理が起動される（Ｓ３１）と、管理対象エージェントを発見する（Ｓ３２）。ついでマネージャ内に当該エージェントのＭＩＢがあればそれを全て削除する（Ｓ３３）。
その後当該エージェントに対して図６に示す「xxxGetNextMode=1」をセットして標準収集モードを指示する（Ｓ３４）。図６に示すシーケンスＳ２，Ｓ３を繰り返してエージェントからＭＩＢの全てを収集する（Ｓ３５）。当該エージェントの全てのＭＩＢの収集が終了すると、当該エージェントに対して図６の「XXXGetNextMode=2」をセットして差分収集モードを指示する（Ｓ３６）。ついで、当該エージェントに対して図６の「XXXMIBStatus」のGetを送信してＭＩＢ差分状態（「XXXMIBStatus」（ＭＩＢ６））を取得する（Ｓ３７）。取得した「XXXMIBStatus」にＭＩＢの削除があるか否かを判断する（Ｓ３８）。
【００３４】
ステップＳ３８において、ＭＩＢの削除がない場合には、当該エージェントからＭＩＢの差分を収集し（Ｓ３９）、エラー状態の有無を判断する（Ｓ４０）。ステップＳ４０においてエラーがないときには、ステップＳ３７に戻って次のＭＩＢの差分状態を収集する。
【００３５】
ステップＳ４０において、エラーが検出されたときには、当該エージェントに対して再度当該ＭＩＢの差分状態の取得を働きかけ（Ｓ４１）、取得した取得した「XXXMIBStatus」にＭＩＢの削除があるか否かを判断する（Ｓ４２）。この判断で、ＭＩＢの削除がない場合には、エラー処理に移行する（Ｓ４３）。
【００３６】
ステップＳ３８、Ｓ４２における判断でＭＩＢ削除がある場合には、ステップＳ３３に戻ってマネージャ内ＭＩＢの全削除から実行しなおす。
【００３７】
図１０を用いて、エージェントのＭＩＢ応答フローを説明する。図１０は、図６〜図８のエージェント側の処理をまとめたフローチャートである。この処理は、マネージャとエージェント間のＭＩＢ同期あわせを実現するために、特にＳＮＭＰエージェント制御部に有する。内容はエージェントの初期設定処理Ｓ５２と、標準収集モードでの処理フローＳ５３〜Ｓ５７と、差分収集モードでの処理フローＳ６０〜Ｓ６６を有している。
【００３８】
エージェント処理が起動されると、エージェント２０は、図１０のＭＩＢ応答処理を開始し（Ｓ５１）、全ＭＩＢの差分フラグを未収集に、ＭＩＢ差分状態をＭＩＢ削除ありに設定する初期設定処理を実行する（Ｓ５２）。
【００３９】
「xxxGetNextMode=1」を受けて標準収集モードを設定し、このＭＩＢの差分フラグを収集済みにし、ＭＩＢ差分状態を編集する（Ｓ５３）。次いで、ＳＮＭＰの受信を監視し（Ｓ５４）、ＳＮＭＰを受信したときには、差分収集モード指示であるか否かを判定する（Ｓ５５）。
ステップＳ５５で差分収集モード指示でないと判断したときには、Get-Rquest/Get-Next-Request/Set-Requestに対して応答する（Ｓ５６）。このときGet-Next-Requestに対しては標準収集モードで対応する。
次いで、ＭＩＢ毎の差分フラグを収集済みに設定しＭＩＢ差分状態の編集処理を行った（Ｓ５７）後、ステップＳ５４に戻りＳＮＭＰの受信を監視する。
【００４０】
ステップＳ５５で受信したＳＮＭＰが差分収集モードを指示していた場合には、差分収集モードを設定し、このＭＩＢの差分フラグを収集済みに設定し、ＭＩＢの差分状態を編集する（Ｓ６０）。
次いで、ＳＮＭＰの受信を監視し（Ｓ６１）、ＳＮＭＰを受信したときには、標準収集モード指示であるか否かを判定する（Ｓ６２）。
ステップＳ６２で標準収集モード指示でないと判断したときには、ＭＩＢ削除あり時のGet-Next-Requestであるか否かを判断する（Ｓ６３）。
ＭＩＢ削除あり時のGet-Next-Requestでないときには、Get-Rquest/Get-Next-Request/Set-Requestに対して応答する（Ｓ６４）。このときGet-Next-Requestに対しては差分収集モードで対応する。
次いで、ＭＩＢ毎の差分フラグを収集済みに設定しＭＩＢ差分状態の編集処理を行った（Ｓ６５）後、ステップＳ６１に戻りＳＮＭＰの受信を監視する。
【００４１】
ステップＳ６２の判断で、ＳＮＭＰが標準収集モードを指示しているときには、ステップＳ５３の標準収集モードに戻る。
ステップＳ６３の判断で、ＭＩＢ削除あり時のGet-Next-Requestであるときには、「Gen-Error」応答して（Ｓ６６）、ステップＳ６１に戻りＳＮＭＰの受信を監視する。
【００４２】
図１１を用いて、エージェント２０のＭＩＢ応答時のステップＳ５３，Ｓ５７，Ｓ６０，Ｓ６５における、ＭＩＢ差分状態の編集処理を説明する。
エージェント２０は、ＭＩＢ差分状態をマネージャ１０に見せるため、処理フローＳ７１〜Ｓ７５を有している。この処理は、ＳＮＭＰエージェント制御部２３に有している。
ＭＩＢ差分状態の編集処理に入ると（Ｓ７１）、全ての差分フラグが収集済みとなっているか否かを判断する（Ｓ７２）。全ての差分フラグが収集済みとされているときには、ＭＩＢ差分状態を判断し、差分があるか否かを判断する（Ｓ７３）。差分があるときには、図５のＭＩＢ６の「INTEGER」の内容を差分なし（none）とするとともに、このＭＩＢの差分フラグを未収集とし（Ｓ７４）、ＭＩＢ差分状態の編集処理を終了する（Ｓ７５）。
ステップＳ７２の差分フラグが収集済み以外であるとき、ステップＳ７３のＭＩＢ差分状態が差分なしであるときには、ＭＩＢ差分状態の編集処理を終了する（Ｓ７５）。
【００４３】
図１２を用いて、エージェント２０のＭＩＢが変化したときの処理を説明する。
この処理は、マネージャ１０からのＳＮＭＰ制御によるＭＩＢの変化ではなく、管理対象ノードの自立的な運用状態の変化によるＭＩＢの変化があった場合の処理である。この処理は、ＳＮＭＰエージェント制御部２３に有している。
エージェント１０は、ＭＩＢに変化が生じると（Ｓ８１）、その変化がＭＩＢの削除であるか否かを判断する（Ｓ８２）。変化がＭＩＢの削除でない場合には、ＭＩＢ差分状態がＭＩＢの削除ありであるか否かを判断する（Ｓ８３）。ＭＩＢの削除ありでない場合には、変化したＭＩＢの差分フラグを未収集に設定するとともにＭＩＢ差分状態をＭＩＢ変更ありまたは追加ありに設定し（Ｓ８５）、この処理を終了する（Ｓ８５）。
【００４４】
ステップＳ８２の判断で、ＭＩＢの削除であったとき、全てのＭＩＢの差分フラグを未収集に設定するとともにＭＩＢ差分状態をＭＩＢ削除ありに設定して（Ｓ８６）、この処理を終了する（Ｓ８５）。
ステップＳ８３の判断で、ＭＩＢの差分状態がＭＩＢの削除ありであったときには、この処理を終了する（Ｓ８５）。
【００４５】
図１３を用いて、エージェントの標準収集モードでのGet-Next応答処理を説明する。
この処理は、ＳＮＭＰでの方式そのものであり参考である。特にＳＮＭＰエージェント制御部２３に有している。
エージェント２０は、「Get-Next-Request」を受信すると（Ｓ９１）、ＭＩＢの辞書の順の次に来るＭＩＢを検索する（Ｓ９２）。ステップＳ９３の判断で全てのＭＩＢの検索が終了しておらず、次に来るＭＩＢが検索できた場合には、そのＭＩＢで正常な応答処理を実行した（Ｓ９４）後、この処理を終了する（Ｓ９６）。
ステップＳ９３の判断で全てのＭＩＢの検索が終了した場合には、「No-Such-Name」の応答を処理を実行し（Ｓ９５）、この処理を終了する（Ｓ９６）。
【００４６】
図１４を用いて、エージェントの差分収集モードでのGet-Next応答処理を説明する。
この処理は、図１３に示した標準収集モードでの「Get-Next-Request」応答処理とほとんとどじであるが、処理フローＳ１０４に示す差分フラグが収集済みか未収集であるかの判断処理を有する点に特徴がある。
エージェント２０は、差分収集モードで「Get-Next-Request」を受信すると（Ｓ１０１）、ＭＩＢの辞書の順の次に来るＭＩＢを検索する（Ｓ１０２）。全てのＭＩＢの差分の収集が終了したか否かを判断し（Ｓ１０３）、終了していないときには、差分フラグを参照して差分を収集済みであるか否かを判断し（Ｓ１０４）、収集していないときには、正常な応答処理を実行した（Ｓ１０５）後、この処理を終了する（Ｓ１０７）。
【００４７】
ステップＳ１０３の判断で全てのＭＩＢの検索が終了した場合には、「No-Such-Name」の応答を処理を実行し（Ｓ１０６）、この処理を終了する（Ｓ１０７）。
ステップＳ１０４の判断で、差分フラグが収集済みとなっているときには、ステップＳ１０２の戻り次のＭＩＢの差分を検索する。
【００４８】
これによってマネージャ１０に対する差分収集モードの応答が可能となる。この処理は、エージェント２０のＳＮＭＰエージェント制御部２３に有している。
ここでは、差分のあるＭＩＢの検索を単純検索方式により実現しているが、差分のあるＭＩＢのみを集めた辞書順ソートファイルを別途用意すれば、応答時間を短縮することができる方式をも含むものである。
【００４９】
図１５以下を用いてマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。図１５はＭＩＢを全て削除したときのマネージャ１０内のＭＩＢテーブル１６１の内容を示している。
ＭＩＢテーブル１６１には、ＭＩＢ毎のオブジェクトＩＤを意味する項欄と、値欄とが関係付けられて設けられている。ＭＩＢ名欄は、本発明の説明を分かり易くするために設けてある。
ＭＩＢを全て削除した場合には、ＭＩＢテーブル１６１の内容の全てが空きになっている。ＭＩＢ削除あり時も本テーブルの内容となる。
【００５０】
図１６を用いて、ＭＩＢの全収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。
例えば、項欄には、１〜９９９，１００１，１００２が記載される。値欄には項，ＭＩＢ名に対応して値が記載される。
例えば、システム情報１〜９９９に対応してそのときの装置状態がそれぞれ最初の値として記憶され、GetNext収集モードに対応して「標準収集モード」、ＭＩＢ差分状態に対応して「ＭＩＢ削除あり」が記載されている。
【００５１】
図１７を用いて、定期的な差分収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。この例では、「システム情報１〜９９９」に変化がないときを示している。
マネージャ１０からエージェント２０に対する「Get-Next-Request」では、１周期目に「ＭＩＢ差分状態＝差分なし」のみの応答となり、２周期目以降は全て「No-Such-Name」となり、それだけでマネージャ１０とエージェント２０間のＭＩＢ同期をとることが可能となる。
【００５２】
図１８を用いて、定期的な差分収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容説明する。この例は、「システム情報９９９」にＭＩＢ状態の変更（９９９から０への変更）があったときを示している。
マネージャ１０からエージェント２０に対する「Get-Next-Request」では１周期目に「システム情報９９９＝０」と「ＭＩＢ差分状態＝ＭＩＢ変更／追加あり」のみの応答となり、さらに２周期目は「ＭＩＢ差分状態＝差分なし」のみの応答となり、３周期目以降は全て「No-Such-Name」で済ませることができる。
【００５３】
図１９を用いて、定期的な差分収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。この例は、「システム情報１０００」がＭＩＢに追加になったときを示している。
マネージャ１０からエージェント２０に対する「Get-Next-Request」では１周期目に「システム情報１０００＝１０００」と「ＭＩＢ差分状態＝ＭＩＢ変更／追加あり」のみの応答となり、さらに２周期目は「ＭＩＢ差分状態＝差分なし」のみの応答となり、３周期目以降は全て「No-Such-Name」で済ませることができる。
【００５４】
以下、図２０〜図２４を用いて、エージェント２０内のＭＩＢテーブル２４１の内容を説明する。
図２０を用いて、全ＭＩＢの差分フラグを未収集にしたときのエージェント２０内のＭＩＢテーブル２４１の内容を説明する。
ＭＩＢテーブル２４１には、ＭＩＢ毎のオブジェクトＩＤを意味する項欄と、値欄と、差分フラグが対応付けられて設けられている。
例えば、項欄には、１〜９９９，１００１，１００２が記載される。値欄にはＭＩＢ名に対応して値が記載される。例えば、システム情報１〜９９９に対応してそのときの装置状態がそれぞれ最初の値として記憶され、GetNext収集モードに対応して「標準収集モード」、ＭＩＢ差分状態に対応して「ＭＩＢ削除あり」が記載されている。
この場合は、実装している全ＭＩＢに対して差分フラグは全て未収集とされる。
ＭＩＢ削除あり時も本テーブルの内容となる。特に図２０〜図２４は管理対象ノード（エージェント）２０のＭＩＢテーブル２４１に記憶されるものである。
【００５５】
図２１を用いて、ＭＩＢの全収集を行った後のエージェント２０内ＭＩＢテーブル２４１の記載内容を説明する。
この状態では、システム情報１からシステム情報９９９および「Get-Next収集モード」の差分フラグ欄は、収集済みとされ、「ＭＩＢ差分状態」をＭＩＢ削除ありから差分なしにエージェントが自立的に変えたため、その差分フラグのみ未収集扱いとなっている。
【００５６】
図２２を用いて、定期的な差分収集を行った後のエージェント２０内ＭＩＢテーブル２４１の内容例を説明する。この例は、「システム情報１〜９９９」に変化がないときを示している。
このときの値欄に記載された値は、図２１の値欄の記載内容と同様である。このように、エージェント２０のＭＩＢテーブル２４１に記載された全てのＭＩＢがマネージャ１０のＭＩＢテーブル１６１内の内容と同期がとれているので、全ての差分フラグが収集済みとなる。
【００５７】
図２３を用いて、定期的な差分収集を行った後のエージェント２０内ＭＩＢテーブル２４１の内容例を説明する。この例は、「システム情報９９９」にＭＩＢ状態の変更（９９９から０に変更）があったときを示す。
マネージャ１００からエージェント２０に対して「Get-Next-Reqest」する前は収集前の差分フラグ欄に示すように、「システム情報９９９」および「ＭＩＢ差分状態」が未収集とされ、その値はそれぞれ０およびＭＩＢ変更／追加ありである。
未収集の差分フラグが設定されたエージェントに対してマネージャ１０から１周期目の「Get-Next-Request」の収集が行われた後の差分フラグは、エージェント２０がＭＩＢ差分状態をＭＩＢ変更／追加ありから差分なしへ自立的に変えたので、そこだけ未収集扱いとされている。未収集の差分フラグが設定されたエージェントに対してマネージャ１０から２周期目以降の「Get-Next-Request」の収集が行われた後は、エージェント２０のＭＩＢテーブル２４１内の全てのＭＩＢがマネージャ２０のＭＩＢテーブル１６１のＭＩＢと同期がとられているので、差分フラグは全て収集済みとなる。
【００５８】
図２４を用いて、定期的な差分収集を行った後のエージェント２０内のＭＩＢテーブル２４１の内容例を説明する。この例は、「システム情報１０００」がＭＩＢ追加になったときを示している。
マネージャ１０からエージェント２０に対して「Get-Next-Reqest」する前は、「システム情報１０００」および「ＭＩＢ差分状態」が未収集とされ、その値はそれぞれ１０００およびＭＩＢ変更／追加ありとなっている。差分フラグが未収集となっているエージェントに対してマネージャ１０から１周期目の「Get-Next-Request」の収集が行われた後の差分フラグは、エージェント２０がＭＩＢ差分状態をＭＩＢ変更／追加ありから差分なしへ自立的に変えたので、そこだけ未収集扱いとなる。未収集の差分フラグが設定されたエージェントに対してマネージャ１０から２周期目以降の「Get-Next-Request」の収集が行われた後は、エージェント２０のＭＩＢテーブル２４１内の全てのＭＩＢがマネージャ１０のＭＩＢテーブル１６１のＭＩＢと同期がとられているので、全て収集済みとなる。
【００５９】
【発明の効果】
本発明のネットワーク管理情報収集方式は、マネージャ１０がエージェント２０からＭＩＢを収集するとき、差分があるＭＩＢの差分のみを収集しＭＩＢの収集量および収集時間を短縮化しているので以下の効果がある。
【００６０】
▲１▼マネージャとエージェント間の通信量が少なくなり、それと同じ通信路を共有している他の通信を妨げる事や、しいては長時間通信帯域を占有してしまう事を防ぐことができる。
【００６１】
▲２▼管理対象ノード数が多数存在する時はその１つの管理対象ノードに対するアクセス量が減るので、全体としての管理情報収集時間を大幅に削減することが可能となる。
【００６２】
▲３▼管理項目数をさらに増やそうとしたとき、その特性が差分の発生しにくい管理項目であれば、ほとんどネットワーク管理情報収集性能のパフォーマンスを下げなくて済む。
【００６３】
▲４▼マネージャとエージェント間で差分があった分の問い合わせだけを行えばよいので．マネージャのエージェントに対する他のオペレーションが困難になるのを防止できオペレータの負担が軽減できる。
【００６４】
▲５▼マネージャおよびエージェントは差分があった分だけの問い合わせ処理を行えばよいのでそれぞれその分、処理負荷を軽減することができる。またそれによって高性能な機器を求める必要がなくなり、ユーザの負担を軽減できる。
【００６５】
▲６▼マネージャがエージェントの状態をリアルタイムにオペレータに伝えるためにエージェントに対してポーリング的にＭＩＢを収集したとき、そのあいだ通信帯域の占有および処理負荷がかかってしまうことを防くことができ、ネットワーク管理のためにネットワークへ悪影響を与えることが少なくできる。
【００６６】
▲７▼「Trap」を用いる必要性が少なくなり、それがコネクションレス方式であるために発生するエージェントからマネージャヘの通信経路上で紛失する問題を防ぐことができる。
また、その紛失があったときの救済方式も機能にインプリメントを行う必要性が少なくなり、マネージャおよびエージェントの開発ベンダーに多く負担をかけなくて済む。
さらに、また単位時間に状態変化が多発してもエージェントからマネージャに対する「Trap」通知の件数が増加しなくて済み通信帯域の圧迫および、マネージャおよびエ−ジェントの処理負荷の増加を招かなくて済む。
また、「しきい値」によってある件数分発生したらそれを抑止又は通知する方式も、実現しなくて済む。
「Trap」自体をＭＩＢの項目数分マネージャおよびエージェントでインブリメントする必要性が少なくなるのでそれぞれの開発ベンダーにそれを開発する負担を軽減できる。
【図面の簡単な説明】
【図１】本発明のネットワーク管理システムのシステム構成例を示す図。
【図２】マネージャ、エージェント間でＭＩＢの設定／参照を実現するプロトコル方式図。
【図３】ネットワーク管理装置のマネージャ構成例を示す図。
【図４】管理対象ノードのエージェント構成例を示す図。
【図５】本発明のＭＩＢ定義例（（ＳＮＭＰｖ１）での例）を示す図。
【図６】差分収集モード実行シーケンス例を示す図。
【図７】マネージャから差分収集していないときにＭＩＢの削除があったときの実行シーケンス例を示す図。
【図８】マネージャから差分収集しているときにＭＩＢの削除があったときの実行シーケンス例を示す図。
【図９】マネージャのＭＩＢ収集フローチャート例を示す図。
【図１０】エージェントのＭＩＢ応答フローチャート例を示す図。
【図１１】エージェントのＭＩＢ差分状態の編集フローチャート例を示す図。
【図１２】エージェントのＭＩＢが変化したときのフローチャート例を示す図。
【図１３】エージェントの標準収集モードでのGet-Next応答フローチャート例を示す図。
【図１４】エージェントの差分収集モードでのGet-Next応答フローチャート例を示す図。
【図１５】マネージャ内ＭＩＢを全削除したときのマネージャ内ＭＩＢテーブル例を示す図。
【図１６】ＭＩＢの全収集を行ったときのマネージャ内ＭＩＢテーブル例を示す図。
【図１７】定期的な差分収集を行ったときのマネージャ内ＭＩＢテーブル例を示す図。（「システム情報１〜９９９」に変化がないとき）
【図１８】定期的な差分収集を行ったときのマネージャ内ＭＩＢテーブル例を示す図。（「システム情報９９９」にＭＩＢ変更［９９９→０への変更］があったとき）
【図１９】定期的な差分収集があったときのマネージャ内ＭＩＢテーブル例を示す図。（「システム情報１０００」がＭＩＢ追加になったとき）
【図２０】全ＭＩＢの差分フラグ＝未収集にしたときのエージェント内ＭＩＢテーブル例を示す図。
【図２１】ＭＩＢの全収集を行った後のエージェント内ＭＩＢテーブル例を示す図。
【図２２】定期的な差分収集を行った後のエージェント内ＭＩＢテーブル例を示す図。（「システム情報１〜９９９」に変化がないとき）
【図２３】定期的な差分収集を行った後のエージェント内ＭＩＢテーブル例を示す図。（「システム情報９９９」にＭＩＢ変更［９９９→０への変更］があったとき）
【図２４】定期的な差分収集を行った後のエージェント内ＭＩＢテーブル例を示す図。
（「システム情報１０００」がＭＩＢ追加になったとき）
【符号の説明】
１０ ネットワーク管理装置（マネージャ）
１１ 下位プロトコルスタック
１２ ＳＮＭＰ処理部
１３ ＳＮＭＰマネージャ制御部
１４ 画面制御部
１５ ネットワーク管理情報表示画面
１６ ＭＩＢテーブル記憶部
１６１ ＭＩＢテーブル
２０ 管理対象ノード（エージェント）
２１ 下位プロトコルスタック
２２ ＳＮＭＰ処理部
１３ ＳＮＭＰエージェント制御部
２４ ＭＩＢテーブル記憶部
２４１ ＭＩＢテーブル
３０ 通信回線
【０００１】
本発明は、複数の管理対象ノード（以下、エージェントともいう）と少なくとも一つのネットワーク管理装置（以下、マネージャともいう）からなるネットワークのネットワーク管理方式に関し、特にネットワーク管理プロトコル（Simple Network Management Protocol：以下、ＳＮＭＰという）を用いて管理情報ベース（Management Information Base：以下、ＭＩＢという）の収集を行うネットワーク管理情報収集方式およびそれに用いるネットワーク管理装置ならびに管理対象ノードに関する。
【０００２】
【従来の技術】
従来、複数のエージェントと少なくとも一つのマネージャからなるネットワークにおいて、ＳＮＭＰを用いてマネージャからエージェントで保持しているＭＩＢを収集する場合のＭＩＢ収集方法としては、
▲１▼「Get-Request」
▲２▼「Get-Next-Request」
▲３▼「Get-Bulk-Request」（ＳＮＭＰｖ２の仕様）
を用いてマネージャからエージェントにＭＩＢの値を問い合わせるコネクション形式の方法と、
▲４▼「Trap」
を用いてエージェントからマネージャに対して自立的に通知するコネクションレス形式の方法があった。
【０００３】
▲１▼「Get-Request」は、マネージャで収集したいＭＩＢを指定してエージェントに問い合わせる方法であり、たとえば１０００個のＭＩＢをエージェントが実装していたとすると、マネージャはＭＩＢを収集する度にエージェントに対して１０００回の問い合わせを行う必要があり、以下の問題が発生した。
・マネージャとエージェント間の通信量が多くなり、それと同じ通信路を共有している他の通信を妨げることや、しいては長時間通信帯域を占有してしまうことがある。
・管理対象ノード数が多いと、全体のＭＩＢを収集するのに多大な時間がかかる。
・管理項目数をさらに増やそうとしたとき、ＭＩＢの収集時間もさらに増えてしまうので安易に増やすことができない。
・マネージャとエージェント間で１０００回の問い合わせを行わなければならないので、その間マネージャのエージェントに対する他のオペレーションが困難になりオペレータの負担になる。
・マネージャおよびエージェントは、１０００回の問い合わせに対する処理を行う必要があるので、それぞれその分の処理負荷がかかってしまう。またそれの是正として高性能な機器を求めようとするとその分、高価な機器を購入する必要が発生しユーザの負担がかかる。
・マネージャがエージェントの状態をリアルタイムにオペレータに伝えるためにエージェントに対してポーリング的にＭＩＢを収集すると、その間通信帯域の占有および処理負荷がかかってしまいネットワーク管理のためにネットワークヘ悪影響を与えてしまう。
【０００４】
▲２▼「Get-Next-Request」は、マネージャでＭＩＢを指定してエージェントに対して問い合わせ、エージェントはそのＭＩＢから名前が辞書順で次に実装されているＭＩＢを探し出してそれ毎に答える方法であり、マネージャがエージェントのＭＩＢ実装状態を認識していないときなどに用いる方法である。この方法も同様の例として１０００個のＭＩＢをマネージャに個々に収集する必要があり「Get-Request」同様の問題が発生する。
【０００５】
▲３▼「Get-Burk-Request」は、マネージャで収集したいＭＩＢを複数個まとめてエージェントから収集できる方法であるが、収集するデータ量は結局同様の例として１０００個になるため、この方法でも通信帯域の占有および処理負荷の増加を招くことが問題となる。
【０００６】
▲４▼「Trap」は、エージェントからマネージャに自立的な状態変化（ＭＩＢの状態変化も含まれる）を通知する方法であるが以下の問題が発生した。
・コネクションレス方式であるので、エージェントからマネージャヘの到達確認が行われず通信経路上で紛失する可能性がある。またその紛失があったときの救済方式も実現方式は存在するがその機能のインプリメントを行う必要が発生し、マネージャおよびエージェントの開発ベンダーに負担がかかってしまう。
・単位時間に状態変化が多発するとその分エージェントからマネージャに対する「Trap」通知の件数が増加してしまい通信帯域の圧迫および、マネージャおよびエージェントの処理負荷の増加が発生してしまう。また「しきい値」による抑止または通知をマネージャおよびエージェントにインプリメントしようとすると、それぞれの開発ベンダーに負担がかかってしまう。
・「Trap」をＭＩＢの項目数分マネージャおよびエージェントでインプリメントする必要があるので（たとえばＭＩＢが１０００個だとTrapも１０００個必要）それぞれの開発ベンダーにそれを開発する負担が発生する。
【０００７】
【発明が解決しようとする課題】
本発明は、マネージャとエージェント間でＭＩＢの収集量および収集時間がかかってしまっていた従来のＭＩＢ収集方式に対して、収集量および収集時間の短縮化がはかれるＭＩＢ収集方式を提供することを課題とする。
さらに、本発明は、ＳＮＭＰｖ１およびＳＮＭＰｖ２双方に実装できるＭＩＢ収集方式を提供することを課題とする。
本発明は、以上に述べた課題を達成するためのネットワーク管理情報収集方式を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明は、上記課題を解決するために、ネットワーク管理装置と、自装置のＭＩＢを記憶する記憶部を有する管理対象装置を通信回線を介して接続したネットワークの管理情報収集方法において、前記ネットワーク管理装置が、前記管理対象装置に対して全てのＭＩＢの収集を行うため、前記管理対象装置に対して標準収集モード指定指示を行うステップと、前記管理対象装置が、前記標準収集モード指定指示を受信すると、自装置を標準収集モードとするステップと、前記ネットワーク管理装置が、標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを収集するステップと、前記ネットワーク管理装置が、前記管理対象装置の全てのＭＩＢを収集した後、前記管理対象装置に対して、差分収集モード指定指示を行うステップと、前記管理対象装置が、前記ネットワーク管理装置より、差分収集モード指定指示を受信すると自装置を標準収集モードから差分収集モードとするステップと、前記ネットワーク管理装置が、前記差分収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の差分のＭＩＢを収集するステップと、前記管理対象装置が、自装置を差分収集モードとした後に、自装置にＭＩＢ削除が発生した場合であって、前記ネットワーク管理装置よりＭＩＢ要求があった場合は、前記ネットワーク管理装置に対して自装置のＭＩＢの削除を通知するステップと、前記ネットワーク管理装置が、前記管理対象装置よりＭＩＢ削除の通知を受信すると、前記収集した前記管理対象装置の全てのＭＩＢを削除するステップと、前記ネットワーク管理装置が、前記全てのＭＩＢの削除を行った後に、前記管理対象装置に対して全てのＭＩＢの収集を行うため、標準収集モード指定指示を行うステップと、前記管理対象装置が、前記標準収集モード指定指示を受信すると、自装置を差分収集モードから標準収集モードとするステップと、前記ネットワーク管理装置が、標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを再収集するステップと、を行うようにした。また、本発明は、管理対象装置の情報を通信回線を介して収集するネットワーク管理装置は、前記ＳＮＭＰマネージャ制御部は、前記管理対象装置の全てのＭＩＢを収集するとともに、前記記憶部に記憶し、前記記憶部に記憶した後、前記管理対象装置に対して、差分収集指示を行う手段と、前記管理対象装置におけるＭＩＢの削除の有無を問合せて、前記管理対象装置よりＭＩＢ削除の応答を受信すると、前記記憶部に記憶した前記管理対象装置の全てのＭＩＢを削除し、当該管理対象装置の全てのＭＩＢの再取得動作を行う手段と、を有する。さらに、本発明は、通信回線を介してネットワーク管理装置に情報を管理される管理対象装置であって、自装置のＭＩＢを記憶する記憶部と、前記ネットワーク管理装置よりのＭＩＢ収集指示に従いＭＩＢを送出するＳＮＭＰエージェント制御部とを有し、前記ＳＮＭＰエージェント制御部は、前記ネットワーク管理装置より、差分収集指示を受信すると自装置を差分収集モードとし、それ以降に前記ネットワーク管理装置よりＭＩＢ収集指示を受信した場合、変化のあるＭＩＢのみを前記ネットワーク管理装置に送信する手段と、前記ネットワーク管理装置よりＭＩＢを削除したかの問合せがあった場合に、自装置のＭＩＢの削除の有無を通知する手段と、を有する。
【０００９】
【作用】
本発明では、マネージャがエージェントからＭＩＢを収集するとき、ＭＩＢの差分のみを収集ればよいので、ＭＩＢの収集量および収集時間を短縮化できる。また、ＭＩＢ定義のインタフェースを用いることで、ＳＮＭＰｖ１およびＳＮＭＰｖ２を用いたそれぞれのネットワーク管理システムに実装が可能となる。
【００１０】
【発明の実施の形態】
以下、図面を用いて本発明にかかるネットワーク管理システムの実施の形態を説明する。
図１を用いて、本発明にかかるネットワーク管理システムのシステム構成例を説明する。図１は、本発明のネットワーク管理システムのシステム構成例を示すブロック図である。
ネットワーク管理システムは、少なくとも一つのネットワーク管理装置（マネージャ）１０と、複数の管理対象ノード（エージェント）２０を通信回線３０で接続して構成される。
ここではネットワークの構成は、スター型のネットワークトポロジーで示してあるが、本発明におけるネットワークは必ずしもスター型に限定されるべきものではなく、メッシュ型や、バス型、リング型をも含むものである。また、エージェントは管理対象ノードに内蔵されるものを示してあるが、外付けの機器をＳＮＭＰで管理するための代理エージェント方式も含むものである。
【００１１】
マネージャ（ネットワーク管理装置）１０は、図３に示す構成例を備えており、エージェント２０に対して図２に示すシーケンスおよび図５に示すＭＩＢを通信回線３０を用いて本発明の実施を行う手段を備えている。
【００１２】
エージェント２０は図４に示す構成例を備えており、マネージャ１０に対して図２に示すシーケンスおよび図５に示すＭＩＢを通信回線３０を用いて本発明の実施を行う手穎を備えている。
【００１３】
図２を用いて、マネージャ１０とエージェント２０間でＭＩＢの設定／参照を実現するＳＮＭＰのプロトコル方式を説明する。図２は、ＳＮＭＰのプロトコル方式図である。
本発明では、マネージャ１０とエージェント２０間で本シーケンスを用いてネットワーク管理情報収集方式を実現する。
【００１４】
第一のシーケンスＰ１は、マネージャからエージェントに対して所定のＭＩＢの取出要求「Get-Request」を送出し、エージェントがこれに応えて対応するＭＩＢの取出応答「Get-Responce」を送出するプロトコルである。
【００１５】
第２のシーケンスＰ２は、マネージャからエージェントに対して所定のＭＩＢの次のＭＩＢの取出要求「Get-Next-Request」を送出し、エージェントがこれに応えて順次ＭＩＢの取出応答「Get-Responce」を送出するプロトコルである。
【００１６】
第３のシーケンスＰ３は、複数のＭＩＢを取得する場合のプロトコルで、マネージャからエージェントに対して複数のＭＩＢの取出要求「Get-Bulk-Request」を送出し、エージェントがこれに応えて複数のＭＩＢの取出応答「Responce」を送出するプロトコルである。
【００１７】
第４のシーケンスＰ４は、エージェントに対してマネージャの要求する値の設定を要求する場合のプロトコルで、マネージャからエージェントに対して「Set-Request」を送出し、エージェントがこれに応えて要求「Get-Responce」を送出するプロトコルであり、具体例としてアラームランプの滅火、回線スピードの改定などを行う。
【００１８】
第５のシーケンスＰ５は、エージェントからマネージャに対して自立的に報告する場合のプロトコルで、エージェントから「Trap」を送出するプロトコルであり、障害発生情報などを送出する。
【００１９】
この実施の形態では、マネージャからの「Get-Next-Request」Ｐ２に対してエージェントがＭＩＢの差分収集に応答する方式を説明するが、必ずしもそれに限ったことではなく、「Get-Bulk-Request」Ｐ３に対してエージェントがＭＩＢの差分収集に応答する方式も含むものである。
【００２０】
図３を用いて、本発明に使用するネットワーク管理装置１０の構成を説明する。図３は、ネットワーク管理装置（マネージャ）１０の構成例を示すブロック図である。
ネットワーク管理装置１０は、下位プロトコルスタック１１と、ＳＮＭＰ処理部１２と、ＳＮＭＰマネージャ制御部１３と、画面制御部１４と、ネットワーク管理情報表示画面１５と、ＭＩＢテーブル記憶部１６とを有して構成される。
【００２１】
下位プロトコルスタック１１は、ハードウエアとソフトウエアから構成されて下位インタフェースを司り、エージェントとの通信を行う通信回線３０に接続される。ＳＮＭＰ処理部１２は、ソフトウエアによって構成され、ＳＮＭＰ送受信処理を行う。ＳＮＭＰマネージャ制御部１３は、本発明のネットワーク管理情報収集方式を制御する。画面制御部１４は、ネットワーク管理装置１０の画面を制御する。ネットワーク管理情報表示画面１５は、管理対象ノードの状態を表示する。ＭＩＢテーブル記憶部１６は、管理対象ノードのＭＩＢの記憶制御を行い、ＭＩＢ情報の記憶媒体として用いるＭＩＢテーブル１６１が設けられる。
【００２２】
図４を用いて、エージェント２０の構成を説明する。図４は、管理対象ノード（エージェント）２０の構成例を示すブロック図である。
管理対象ノード２０は、下位プロトコルスタック２１と、ＳＮＭＰ処理部２２と、ＳＮＭＰエージェント制御部２３と、ＭＩＢテーブル記憶部２４とを有して構成される。
【００２３】
下位プロトコルスタック２１は、ハードウエアとソフトウエアから構成されて下位インタフェースを司り、マネージャとの通信を行う通信回線３０に接続される。ＳＮＭＰ処理部２２は、ソフトウエアによって構成され、ＳＮＭＰ送受信処理を行う。ＳＮＭＰエージェント制御部２３は、本発明のネットワーク管理情報収集方式を制御する。ＭＩＢテーブル記憶部２４は、ＭＩＢの記憶制御を行い、ＭＩＢ情報の記憶媒体として用いるＭＩＢテーブル２４１を備えている。
【００２４】
ここでは、ＭＩＢテーブル記憶部２４およびＭＩＢテーブル２４１として示してあるが必ずしもＭＩＢのデータベースとして制御および記憶しているものではなく、メモリデータとして装置固有の制御および記憶する方式をも含むものである。
【００２５】
図５を用いて、本発明で用いるＭＩＢの定義の例（ＳＮＭＰｖ１）を説明する。
ＭＩＢ定義として、エージェントがマネージャにネットワーク管理情報として見せるべき既存のＭＩＢ情報ＭＩＢ１〜ＭＩＢ４と、特に本発明で用いる差分収集モード実現用ＭＩＢであるＭＩＢ５とＭＩＢ６を備えている。
ＭＩＢ５はマネージャからエージェントに対して差分収集モードまたは標準収集モードの指定または参照を可能とする。ＭＩＢ６はマネージャからエージェントに対してＭＩＢの差分状態を参照可能とする。
【００２６】
ここではＭＩＢ５とＭＩＢ６は１つのＭＩＢグループ（ここではＭＩＢ１〜ＭＩＢ４）に対して１組、差分収集モード実現用にマネージャとエージェント間の取り決めとして定義した例を示したが、必ずしもそれに限ったことではなく、管理対象ノード毎に１組定義する方式や、差分収集したいＭＩＢのエントリ毎に１組定義する方式や、さらには管理する側となるマネージャ毎（マネージャｎ重化用）に１組定義する方式も含むものである。
また、ここではＳＮＭＰｖ１での定義例を示しているが必ずしもそれに限ったことではなくＳＮＭＰｖ２での定義方法をも含むものである。
【００２７】
図６を用いて、差分収集モードの実行シーケンス例を説明する。
まず、マネージャは管理対象ノードのＭＩＢを全収集するために、エージェントに対してシーケンスＳ１に示す「標準収集モード」の指定を行う。エージェントはそれをトリガにマネージャがそれ以降の「Get-Next-Request」に対する応答を標準プロトコル仕様での「Get-Responce」で応答してほしいと要求していることが認識できる。
ＭＩＢの実装数分繰り返されるシーケンスＳ２と、ＭＩＢが終了したことを示すシーケンスＳ３が終わると、それ以降はＭＩＢの差分のみをマネージャが収集すれば良いためマネージャはエージェントに対してシーケンスＳ４に示す「差分収集モード」の指示を行う。エージェントはそれ以降の「Get-Next-Request」に対する応答を差分があるＭＩＢだけに限定すればよいことを認識できる。
定期的な差分収集ではマネージャはまずエージェント側に自立的なＭＩＢの削除があったかどうかシーケンスＳ５にて確認を行う。これはＭＩＢの削除があったとき「Get-Next」では削除ＭＩＢがスキップされるためマネージャがその差分を認識できなくなりマネージャのＭＩＢテーフルに削除ＭＩＢが残ってしまうのを防ぐために行う。その手段は図７，図８で別途説明する。
【００２８】
差分のあるＭＩＢ収集はシーケンスＳ６での「Get-Next」の繰り返しで実現し、差分ＭＩＢの全収集終了のマネージャ側認識手段はシーケンスＳ７の「No-Such-Name」応答があつたことで実現する。これによりたとえば全くＭＩＢの差分がないときは１回目のシーケンスＳ６ですぐ「No-Such-Name」となり、少ない通信でマネージャはエージェントの全ＭＩＢ状態を把握することが可能となり、収集量および収集時間の短縮化をはかることができる。
【００２９】
ここでは差分があるＭＩＢを応答する方式を示したが、これに限ったことではなく、ＭＩＢの状態変化の装置特性に合わせ、変わる可能性のあるＭＩＢだけを差分ありとして扱う簡易的な方式や、マネージャから見て差分はないが状態変化によりもとの状態に戻ったＭＩＢも差分ありとして扱う方式や、例外的に差分が管理できなくなる状態が発生し、全ＭＩＢを差分ありとして扱う方式も含むものである。
【００３０】
図７を用いて、マネージャから差分収集する周期タイミングの間にＭＩＢの削除があったときの実行シーケンス例を説明する。
ＭＩＢ削除が発生したトリガＳ１１の後にマネージャの定期的な差分収集が発生するとマネージャからシーケンスＳ１２のＭＩＢ差分状態確認要求がありエージェントはＭＩＢの削除があったことをその応答として返答する。マネージャはそれをトリガにマネージャ内ＭＩＢの全削除を行う。これはＭＩＢの削除をマネージャが認識する方式の１つの手段であり、最初から全収集することでマネージャ内ＭＩＢとエージェント内ＭＩＢの同期をとることができるために行う。
マネージャはＭＩＢの全収集をするため、エージェントに対してシーケンスＳ１４に示す「標準収集モード」の指示を行う。これがないとエージェントは「差分収集モード」のままの応答形態をとってしまう可能性があるため、これを行う。
この後マネージャはシーケンスＳ１５、Ｓ１６に示すＭＩＢの全収集を行うことで、エージェントとのＭＩＢ状態の同期をとる。
【００３１】
ここではエージェント側のＭＩＢの削除によりマネージャのＭＩＢを全削除しているが、これに限ったことではなく、削除したＭＩＢをリスト形式でマネージャに見せる方式を採用することで、削除ＭＩＢの同期をとる方法をも含むものである。
また、ここでは、マネージャ内ＭＩＢの全削除をＭＩＢの全収集の前に行っているが、ネットワーク管理仕様として全収集の前の状態を保持しておきたいときはその順序が逆になる方式をも含むものである。
また、ここではＭＩＢ差分状態のＭＩＢをマネージャから指定して確認する方式を説明しているが、本ＭＩＢを差分管理対象となるＭＩＢグループの先頭のみまた、は、先頭および最後に定義することで、「Get-Next-Request」だけによるＭＩＢ削除のマネージャ側認識を可能とできる方式をも含むものである。
【００３２】
図８はマネージャから差分収集しているときにＭＩＢの削除があったときの実行シーケンス例を示す図である。
ＭＩＢの削除が発生したトリガＳ２３があるとエージェントは差分収集シーケンスＳ２４に対する応答を「Gen-Error」で応答し、マネージャに差分収集モードでの応答ができなくなったことをマネージャに認識させる。以降の処理は図７でのシーケンスＳ１２以降と同様である。
【００３３】
マネージャのＭＩＢ収集フローの例を示す図９を用いて、マネージャのＭＩＢ収集処理を説明する。
図９は、図６〜図８に示した実行シーケンスのマネージャ側処理をまとめたフローチャートであり、マネージャとエージェント間の差分収集によるＭＩＢ同期あわせを実現するために特にＳＮＭＰマネージャ制御部に有するものである。
マネージャ処理が起動される（Ｓ３１）と、管理対象エージェントを発見する（Ｓ３２）。ついでマネージャ内に当該エージェントのＭＩＢがあればそれを全て削除する（Ｓ３３）。
その後当該エージェントに対して図６に示す「xxxGetNextMode=1」をセットして標準収集モードを指示する（Ｓ３４）。図６に示すシーケンスＳ２，Ｓ３を繰り返してエージェントからＭＩＢの全てを収集する（Ｓ３５）。当該エージェントの全てのＭＩＢの収集が終了すると、当該エージェントに対して図６の「XXXGetNextMode=2」をセットして差分収集モードを指示する（Ｓ３６）。ついで、当該エージェントに対して図６の「XXXMIBStatus」のGetを送信してＭＩＢ差分状態（「XXXMIBStatus」（ＭＩＢ６））を取得する（Ｓ３７）。取得した「XXXMIBStatus」にＭＩＢの削除があるか否かを判断する（Ｓ３８）。
【００３４】
ステップＳ３８において、ＭＩＢの削除がない場合には、当該エージェントからＭＩＢの差分を収集し（Ｓ３９）、エラー状態の有無を判断する（Ｓ４０）。ステップＳ４０においてエラーがないときには、ステップＳ３７に戻って次のＭＩＢの差分状態を収集する。
【００３５】
ステップＳ４０において、エラーが検出されたときには、当該エージェントに対して再度当該ＭＩＢの差分状態の取得を働きかけ（Ｓ４１）、取得した取得した「XXXMIBStatus」にＭＩＢの削除があるか否かを判断する（Ｓ４２）。この判断で、ＭＩＢの削除がない場合には、エラー処理に移行する（Ｓ４３）。
【００３６】
ステップＳ３８、Ｓ４２における判断でＭＩＢ削除がある場合には、ステップＳ３３に戻ってマネージャ内ＭＩＢの全削除から実行しなおす。
【００３７】
図１０を用いて、エージェントのＭＩＢ応答フローを説明する。図１０は、図６〜図８のエージェント側の処理をまとめたフローチャートである。この処理は、マネージャとエージェント間のＭＩＢ同期あわせを実現するために、特にＳＮＭＰエージェント制御部に有する。内容はエージェントの初期設定処理Ｓ５２と、標準収集モードでの処理フローＳ５３〜Ｓ５７と、差分収集モードでの処理フローＳ６０〜Ｓ６６を有している。
【００３８】
エージェント処理が起動されると、エージェント２０は、図１０のＭＩＢ応答処理を開始し（Ｓ５１）、全ＭＩＢの差分フラグを未収集に、ＭＩＢ差分状態をＭＩＢ削除ありに設定する初期設定処理を実行する（Ｓ５２）。
【００３９】
「xxxGetNextMode=1」を受けて標準収集モードを設定し、このＭＩＢの差分フラグを収集済みにし、ＭＩＢ差分状態を編集する（Ｓ５３）。次いで、ＳＮＭＰの受信を監視し（Ｓ５４）、ＳＮＭＰを受信したときには、差分収集モード指示であるか否かを判定する（Ｓ５５）。
ステップＳ５５で差分収集モード指示でないと判断したときには、Get-Rquest/Get-Next-Request/Set-Requestに対して応答する（Ｓ５６）。このときGet-Next-Requestに対しては標準収集モードで対応する。
次いで、ＭＩＢ毎の差分フラグを収集済みに設定しＭＩＢ差分状態の編集処理を行った（Ｓ５７）後、ステップＳ５４に戻りＳＮＭＰの受信を監視する。
【００４０】
ステップＳ５５で受信したＳＮＭＰが差分収集モードを指示していた場合には、差分収集モードを設定し、このＭＩＢの差分フラグを収集済みに設定し、ＭＩＢの差分状態を編集する（Ｓ６０）。
次いで、ＳＮＭＰの受信を監視し（Ｓ６１）、ＳＮＭＰを受信したときには、標準収集モード指示であるか否かを判定する（Ｓ６２）。
ステップＳ６２で標準収集モード指示でないと判断したときには、ＭＩＢ削除あり時のGet-Next-Requestであるか否かを判断する（Ｓ６３）。
ＭＩＢ削除あり時のGet-Next-Requestでないときには、Get-Rquest/Get-Next-Request/Set-Requestに対して応答する（Ｓ６４）。このときGet-Next-Requestに対しては差分収集モードで対応する。
次いで、ＭＩＢ毎の差分フラグを収集済みに設定しＭＩＢ差分状態の編集処理を行った（Ｓ６５）後、ステップＳ６１に戻りＳＮＭＰの受信を監視する。
【００４１】
ステップＳ６２の判断で、ＳＮＭＰが標準収集モードを指示しているときには、ステップＳ５３の標準収集モードに戻る。
ステップＳ６３の判断で、ＭＩＢ削除あり時のGet-Next-Requestであるときには、「Gen-Error」応答して（Ｓ６６）、ステップＳ６１に戻りＳＮＭＰの受信を監視する。
【００４２】
図１１を用いて、エージェント２０のＭＩＢ応答時のステップＳ５３，Ｓ５７，Ｓ６０，Ｓ６５における、ＭＩＢ差分状態の編集処理を説明する。
エージェント２０は、ＭＩＢ差分状態をマネージャ１０に見せるため、処理フローＳ７１〜Ｓ７５を有している。この処理は、ＳＮＭＰエージェント制御部２３に有している。
ＭＩＢ差分状態の編集処理に入ると（Ｓ７１）、全ての差分フラグが収集済みとなっているか否かを判断する（Ｓ７２）。全ての差分フラグが収集済みとされているときには、ＭＩＢ差分状態を判断し、差分があるか否かを判断する（Ｓ７３）。差分があるときには、図５のＭＩＢ６の「INTEGER」の内容を差分なし（none）とするとともに、このＭＩＢの差分フラグを未収集とし（Ｓ７４）、ＭＩＢ差分状態の編集処理を終了する（Ｓ７５）。
ステップＳ７２の差分フラグが収集済み以外であるとき、ステップＳ７３のＭＩＢ差分状態が差分なしであるときには、ＭＩＢ差分状態の編集処理を終了する（Ｓ７５）。
【００４３】
図１２を用いて、エージェント２０のＭＩＢが変化したときの処理を説明する。
この処理は、マネージャ１０からのＳＮＭＰ制御によるＭＩＢの変化ではなく、管理対象ノードの自立的な運用状態の変化によるＭＩＢの変化があった場合の処理である。この処理は、ＳＮＭＰエージェント制御部２３に有している。
エージェント１０は、ＭＩＢに変化が生じると（Ｓ８１）、その変化がＭＩＢの削除であるか否かを判断する（Ｓ８２）。変化がＭＩＢの削除でない場合には、ＭＩＢ差分状態がＭＩＢの削除ありであるか否かを判断する（Ｓ８３）。ＭＩＢの削除ありでない場合には、変化したＭＩＢの差分フラグを未収集に設定するとともにＭＩＢ差分状態をＭＩＢ変更ありまたは追加ありに設定し（Ｓ８５）、この処理を終了する（Ｓ８５）。
【００４４】
ステップＳ８２の判断で、ＭＩＢの削除であったとき、全てのＭＩＢの差分フラグを未収集に設定するとともにＭＩＢ差分状態をＭＩＢ削除ありに設定して（Ｓ８６）、この処理を終了する（Ｓ８５）。
ステップＳ８３の判断で、ＭＩＢの差分状態がＭＩＢの削除ありであったときには、この処理を終了する（Ｓ８５）。
【００４５】
図１３を用いて、エージェントの標準収集モードでのGet-Next応答処理を説明する。
この処理は、ＳＮＭＰでの方式そのものであり参考である。特にＳＮＭＰエージェント制御部２３に有している。
エージェント２０は、「Get-Next-Request」を受信すると（Ｓ９１）、ＭＩＢの辞書の順の次に来るＭＩＢを検索する（Ｓ９２）。ステップＳ９３の判断で全てのＭＩＢの検索が終了しておらず、次に来るＭＩＢが検索できた場合には、そのＭＩＢで正常な応答処理を実行した（Ｓ９４）後、この処理を終了する（Ｓ９６）。
ステップＳ９３の判断で全てのＭＩＢの検索が終了した場合には、「No-Such-Name」の応答を処理を実行し（Ｓ９５）、この処理を終了する（Ｓ９６）。
【００４６】
図１４を用いて、エージェントの差分収集モードでのGet-Next応答処理を説明する。
この処理は、図１３に示した標準収集モードでの「Get-Next-Request」応答処理とほとんとどじであるが、処理フローＳ１０４に示す差分フラグが収集済みか未収集であるかの判断処理を有する点に特徴がある。
エージェント２０は、差分収集モードで「Get-Next-Request」を受信すると（Ｓ１０１）、ＭＩＢの辞書の順の次に来るＭＩＢを検索する（Ｓ１０２）。全てのＭＩＢの差分の収集が終了したか否かを判断し（Ｓ１０３）、終了していないときには、差分フラグを参照して差分を収集済みであるか否かを判断し（Ｓ１０４）、収集していないときには、正常な応答処理を実行した（Ｓ１０５）後、この処理を終了する（Ｓ１０７）。
【００４７】
ステップＳ１０３の判断で全てのＭＩＢの検索が終了した場合には、「No-Such-Name」の応答を処理を実行し（Ｓ１０６）、この処理を終了する（Ｓ１０７）。
ステップＳ１０４の判断で、差分フラグが収集済みとなっているときには、ステップＳ１０２の戻り次のＭＩＢの差分を検索する。
【００４８】
これによってマネージャ１０に対する差分収集モードの応答が可能となる。この処理は、エージェント２０のＳＮＭＰエージェント制御部２３に有している。
ここでは、差分のあるＭＩＢの検索を単純検索方式により実現しているが、差分のあるＭＩＢのみを集めた辞書順ソートファイルを別途用意すれば、応答時間を短縮することができる方式をも含むものである。
【００４９】
図１５以下を用いてマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。図１５はＭＩＢを全て削除したときのマネージャ１０内のＭＩＢテーブル１６１の内容を示している。
ＭＩＢテーブル１６１には、ＭＩＢ毎のオブジェクトＩＤを意味する項欄と、値欄とが関係付けられて設けられている。ＭＩＢ名欄は、本発明の説明を分かり易くするために設けてある。
ＭＩＢを全て削除した場合には、ＭＩＢテーブル１６１の内容の全てが空きになっている。ＭＩＢ削除あり時も本テーブルの内容となる。
【００５０】
図１６を用いて、ＭＩＢの全収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。
例えば、項欄には、１〜９９９，１００１，１００２が記載される。値欄には項，ＭＩＢ名に対応して値が記載される。
例えば、システム情報１〜９９９に対応してそのときの装置状態がそれぞれ最初の値として記憶され、GetNext収集モードに対応して「標準収集モード」、ＭＩＢ差分状態に対応して「ＭＩＢ削除あり」が記載されている。
【００５１】
図１７を用いて、定期的な差分収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。この例では、「システム情報１〜９９９」に変化がないときを示している。
マネージャ１０からエージェント２０に対する「Get-Next-Request」では、１周期目に「ＭＩＢ差分状態＝差分なし」のみの応答となり、２周期目以降は全て「No-Such-Name」となり、それだけでマネージャ１０とエージェント２０間のＭＩＢ同期をとることが可能となる。
【００５２】
図１８を用いて、定期的な差分収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容説明する。この例は、「システム情報９９９」にＭＩＢ状態の変更（９９９から０への変更）があったときを示している。
マネージャ１０からエージェント２０に対する「Get-Next-Request」では１周期目に「システム情報９９９＝０」と「ＭＩＢ差分状態＝ＭＩＢ変更／追加あり」のみの応答となり、さらに２周期目は「ＭＩＢ差分状態＝差分なし」のみの応答となり、３周期目以降は全て「No-Such-Name」で済ませることができる。
【００５３】
図１９を用いて、定期的な差分収集を行ったときのマネージャ１０内のＭＩＢテーブル１６１の内容を説明する。この例は、「システム情報１０００」がＭＩＢに追加になったときを示している。
マネージャ１０からエージェント２０に対する「Get-Next-Request」では１周期目に「システム情報１０００＝１０００」と「ＭＩＢ差分状態＝ＭＩＢ変更／追加あり」のみの応答となり、さらに２周期目は「ＭＩＢ差分状態＝差分なし」のみの応答となり、３周期目以降は全て「No-Such-Name」で済ませることができる。
【００５４】
以下、図２０〜図２４を用いて、エージェント２０内のＭＩＢテーブル２４１の内容を説明する。
図２０を用いて、全ＭＩＢの差分フラグを未収集にしたときのエージェント２０内のＭＩＢテーブル２４１の内容を説明する。
ＭＩＢテーブル２４１には、ＭＩＢ毎のオブジェクトＩＤを意味する項欄と、値欄と、差分フラグが対応付けられて設けられている。
例えば、項欄には、１〜９９９，１００１，１００２が記載される。値欄にはＭＩＢ名に対応して値が記載される。例えば、システム情報１〜９９９に対応してそのときの装置状態がそれぞれ最初の値として記憶され、GetNext収集モードに対応して「標準収集モード」、ＭＩＢ差分状態に対応して「ＭＩＢ削除あり」が記載されている。
この場合は、実装している全ＭＩＢに対して差分フラグは全て未収集とされる。
ＭＩＢ削除あり時も本テーブルの内容となる。特に図２０〜図２４は管理対象ノード（エージェント）２０のＭＩＢテーブル２４１に記憶されるものである。
【００５５】
図２１を用いて、ＭＩＢの全収集を行った後のエージェント２０内ＭＩＢテーブル２４１の記載内容を説明する。
この状態では、システム情報１からシステム情報９９９および「Get-Next収集モード」の差分フラグ欄は、収集済みとされ、「ＭＩＢ差分状態」をＭＩＢ削除ありから差分なしにエージェントが自立的に変えたため、その差分フラグのみ未収集扱いとなっている。
【００５６】
図２２を用いて、定期的な差分収集を行った後のエージェント２０内ＭＩＢテーブル２４１の内容例を説明する。この例は、「システム情報１〜９９９」に変化がないときを示している。
このときの値欄に記載された値は、図２１の値欄の記載内容と同様である。このように、エージェント２０のＭＩＢテーブル２４１に記載された全てのＭＩＢがマネージャ１０のＭＩＢテーブル１６１内の内容と同期がとれているので、全ての差分フラグが収集済みとなる。
【００５７】
図２３を用いて、定期的な差分収集を行った後のエージェント２０内ＭＩＢテーブル２４１の内容例を説明する。この例は、「システム情報９９９」にＭＩＢ状態の変更（９９９から０に変更）があったときを示す。
マネージャ１００からエージェント２０に対して「Get-Next-Reqest」する前は収集前の差分フラグ欄に示すように、「システム情報９９９」および「ＭＩＢ差分状態」が未収集とされ、その値はそれぞれ０およびＭＩＢ変更／追加ありである。
未収集の差分フラグが設定されたエージェントに対してマネージャ１０から１周期目の「Get-Next-Request」の収集が行われた後の差分フラグは、エージェント２０がＭＩＢ差分状態をＭＩＢ変更／追加ありから差分なしへ自立的に変えたので、そこだけ未収集扱いとされている。未収集の差分フラグが設定されたエージェントに対してマネージャ１０から２周期目以降の「Get-Next-Request」の収集が行われた後は、エージェント２０のＭＩＢテーブル２４１内の全てのＭＩＢがマネージャ２０のＭＩＢテーブル１６１のＭＩＢと同期がとられているので、差分フラグは全て収集済みとなる。
【００５８】
図２４を用いて、定期的な差分収集を行った後のエージェント２０内のＭＩＢテーブル２４１の内容例を説明する。この例は、「システム情報１０００」がＭＩＢ追加になったときを示している。
マネージャ１０からエージェント２０に対して「Get-Next-Reqest」する前は、「システム情報１０００」および「ＭＩＢ差分状態」が未収集とされ、その値はそれぞれ１０００およびＭＩＢ変更／追加ありとなっている。差分フラグが未収集となっているエージェントに対してマネージャ１０から１周期目の「Get-Next-Request」の収集が行われた後の差分フラグは、エージェント２０がＭＩＢ差分状態をＭＩＢ変更／追加ありから差分なしへ自立的に変えたので、そこだけ未収集扱いとなる。未収集の差分フラグが設定されたエージェントに対してマネージャ１０から２周期目以降の「Get-Next-Request」の収集が行われた後は、エージェント２０のＭＩＢテーブル２４１内の全てのＭＩＢがマネージャ１０のＭＩＢテーブル１６１のＭＩＢと同期がとられているので、全て収集済みとなる。
【００５９】
【発明の効果】
本発明のネットワーク管理情報収集方式は、マネージャ１０がエージェント２０からＭＩＢを収集するとき、差分があるＭＩＢの差分のみを収集しＭＩＢの収集量および収集時間を短縮化しているので以下の効果がある。
【００６０】
▲１▼マネージャとエージェント間の通信量が少なくなり、それと同じ通信路を共有している他の通信を妨げる事や、しいては長時間通信帯域を占有してしまう事を防ぐことができる。
【００６１】
▲２▼管理対象ノード数が多数存在する時はその１つの管理対象ノードに対するアクセス量が減るので、全体としての管理情報収集時間を大幅に削減することが可能となる。
【００６２】
▲３▼管理項目数をさらに増やそうとしたとき、その特性が差分の発生しにくい管理項目であれば、ほとんどネットワーク管理情報収集性能のパフォーマンスを下げなくて済む。
【００６３】
▲４▼マネージャとエージェント間で差分があった分の問い合わせだけを行えばよいので．マネージャのエージェントに対する他のオペレーションが困難になるのを防止できオペレータの負担が軽減できる。
【００６４】
▲５▼マネージャおよびエージェントは差分があった分だけの問い合わせ処理を行えばよいのでそれぞれその分、処理負荷を軽減することができる。またそれによって高性能な機器を求める必要がなくなり、ユーザの負担を軽減できる。
【００６５】
▲６▼マネージャがエージェントの状態をリアルタイムにオペレータに伝えるためにエージェントに対してポーリング的にＭＩＢを収集したとき、そのあいだ通信帯域の占有および処理負荷がかかってしまうことを防くことができ、ネットワーク管理のためにネットワークへ悪影響を与えることが少なくできる。
【００６６】
▲７▼「Trap」を用いる必要性が少なくなり、それがコネクションレス方式であるために発生するエージェントからマネージャヘの通信経路上で紛失する問題を防ぐことができる。
また、その紛失があったときの救済方式も機能にインプリメントを行う必要性が少なくなり、マネージャおよびエージェントの開発ベンダーに多く負担をかけなくて済む。
さらに、また単位時間に状態変化が多発してもエージェントからマネージャに対する「Trap」通知の件数が増加しなくて済み通信帯域の圧迫および、マネージャおよびエ−ジェントの処理負荷の増加を招かなくて済む。
また、「しきい値」によってある件数分発生したらそれを抑止又は通知する方式も、実現しなくて済む。
「Trap」自体をＭＩＢの項目数分マネージャおよびエージェントでインブリメントする必要性が少なくなるのでそれぞれの開発ベンダーにそれを開発する負担を軽減できる。
【図面の簡単な説明】
【図１】本発明のネットワーク管理システムのシステム構成例を示す図。
【図２】マネージャ、エージェント間でＭＩＢの設定／参照を実現するプロトコル方式図。
【図３】ネットワーク管理装置のマネージャ構成例を示す図。
【図４】管理対象ノードのエージェント構成例を示す図。
【図５】本発明のＭＩＢ定義例（（ＳＮＭＰｖ１）での例）を示す図。
【図６】差分収集モード実行シーケンス例を示す図。
【図７】マネージャから差分収集していないときにＭＩＢの削除があったときの実行シーケンス例を示す図。
【図８】マネージャから差分収集しているときにＭＩＢの削除があったときの実行シーケンス例を示す図。
【図９】マネージャのＭＩＢ収集フローチャート例を示す図。
【図１０】エージェントのＭＩＢ応答フローチャート例を示す図。
【図１１】エージェントのＭＩＢ差分状態の編集フローチャート例を示す図。
【図１２】エージェントのＭＩＢが変化したときのフローチャート例を示す図。
【図１３】エージェントの標準収集モードでのGet-Next応答フローチャート例を示す図。
【図１４】エージェントの差分収集モードでのGet-Next応答フローチャート例を示す図。
【図１５】マネージャ内ＭＩＢを全削除したときのマネージャ内ＭＩＢテーブル例を示す図。
【図１６】ＭＩＢの全収集を行ったときのマネージャ内ＭＩＢテーブル例を示す図。
【図１７】定期的な差分収集を行ったときのマネージャ内ＭＩＢテーブル例を示す図。（「システム情報１〜９９９」に変化がないとき）
【図１８】定期的な差分収集を行ったときのマネージャ内ＭＩＢテーブル例を示す図。（「システム情報９９９」にＭＩＢ変更［９９９→０への変更］があったとき）
【図１９】定期的な差分収集があったときのマネージャ内ＭＩＢテーブル例を示す図。（「システム情報１０００」がＭＩＢ追加になったとき）
【図２０】全ＭＩＢの差分フラグ＝未収集にしたときのエージェント内ＭＩＢテーブル例を示す図。
【図２１】ＭＩＢの全収集を行った後のエージェント内ＭＩＢテーブル例を示す図。
【図２２】定期的な差分収集を行った後のエージェント内ＭＩＢテーブル例を示す図。（「システム情報１〜９９９」に変化がないとき）
【図２３】定期的な差分収集を行った後のエージェント内ＭＩＢテーブル例を示す図。（「システム情報９９９」にＭＩＢ変更［９９９→０への変更］があったとき）
【図２４】定期的な差分収集を行った後のエージェント内ＭＩＢテーブル例を示す図。
（「システム情報１０００」がＭＩＢ追加になったとき）
【符号の説明】
１０ ネットワーク管理装置（マネージャ）
１１ 下位プロトコルスタック
１２ ＳＮＭＰ処理部
１３ ＳＮＭＰマネージャ制御部
１４ 画面制御部
１５ ネットワーク管理情報表示画面
１６ ＭＩＢテーブル記憶部
１６１ ＭＩＢテーブル
２０ 管理対象ノード（エージェント）
２１ 下位プロトコルスタック
２２ ＳＮＭＰ処理部
１３ ＳＮＭＰエージェント制御部
２４ ＭＩＢテーブル記憶部
２４１ ＭＩＢテーブル
３０ 通信回線
Claims (3)
- ネットワーク管理装置と、自装置のＭＩＢを記憶する記憶部を有する管理対象装置を通信回線を介して接続したネットワークの管理情報収集方法において、
前記ネットワーク管理装置が、
前記管理対象装置に対して全てのＭＩＢの収集を行うため、前記管理対象装置に対して標準収集モード指定指示を行うステップと、
前記管理対象装置が、
前記標準収集モード指定指示を受信すると、自装置を標準収集モードとするステップと、
前記ネットワーク管理装置が、
標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを収集するステップと、
前記ネットワーク管理装置が、
前記管理対象装置の全てのＭＩＢを収集した後、前記管理対象装置に対して、差分収集モード指定指示を行うステップと、
前記管理対象装置が、
前記ネットワーク管理装置より、差分収集モード指定指示を受信すると自装置を標準収集モードから差分収集モードとするステップと、
前記ネットワーク管理装置が、
前記差分収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の差分のＭＩＢを収集するステップと、
前記管理対象装置が、
自装置を差分収集モードとした後に、自装置にＭＩＢ削除が発生した場合であって、前記ネットワーク管理装置よりＭＩＢ要求があった場合は、前記ネットワーク管理装置に対して自装置のＭＩＢの削除を通知するステップと、
前記ネットワーク管理装置が、
前記管理対象装置よりＭＩＢ削除の通知を受信すると、前記収集した前記管理対象装置の全てのＭＩＢを削除するステップと、
前記ネットワーク管理装置が、
前記全てのＭＩＢの削除を行った後に、前記管理対象装置に対して全てのＭＩＢの収集を行うため、標準収集モード指定指示を行うステップと、
前記管理対象装置が、
前記標準収集モード指定指示を受信すると、自装置を差分収集モードから標準収集モードとするステップと、
前記ネットワーク管理装置が、
標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを再収集するステップと、
を行うことを特徴とするネットワーク管理情報収集方法。 - 管理対象装置の情報を通信回線を介して収集するネットワーク管理装置であって、
前記管理対象装置のＭＩＢの収集を行うＳＮＭＰマネージャ制御部は、
前記管理対象装置に対して全てのＭＩＢの収集を行うため、標準収集モード指定指示を行い、
標準収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行うとともに前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを収集し、
前記管理対象装置の全てのＭＩＢを収集した後、前記管理対象装置に対して、差分収集 モード指定指示を行い、
前記差分収集モード指定指示を行った後に、前記管理対象装置に対してＭＩＢ要求を行うとともに前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の差分のＭＩＢを収集し、
前記差分のＭＩＢの収集中に、前記管理対象装置よりＭＩＢ削除の通知を受信すると、前記収集した前記管理対象装置の全てのＭＩＢを削除し、
前記管理対象装置に対して全てのＭＩＢの収集を行うため、標準収集モード指定指示を行い、
前記管理対象装置に対してＭＩＢ要求を行い、前記管理対象装置の当該ＭＩＢ要求に対するＭＩＢ応答により、前記管理対象装置の全てのＭＩＢを再収集する
ことを特徴とするネットワーク管理装置。 - 通信回線を介してネットワーク管理装置に情報を管理される管理対象装置であって、
自装置のＭＩＢを記憶する記憶部と、
前記ネットワーク管理装置よりのＭＩＢ収集指示に従いＭＩＢを送出するＳＮＭＰエージェント制御部とを有し、
前記ＳＮＭＰエージェント制御部は、
前記ネットワーク管理装置より、前記標準収集モード指定指示を受信すると、自装置を標準収集モードとし、
自装置を標準収集モードとした後に、前記ネットワーク管理装置よりＭＩＢ要求を受信すると、当該ＭＩＢ要求に対するＭＩＢ応答にて、自装置の全てのＭＩＢを前記ネットワーク管理装置に送信し、
前記ネットワーク管理装置より、差分収集モード指定指示を受信すると自装置を標準収集モードから差分収集モードとし、
自装置を差分収集モードとした後に、前記ネットワーク管理装置よりＭＩＢ要求を受信すると、当該ＭＩＢ要求に対するＭＩＢ応答にて、自装置の差分のＭＩＢを前記ネットワーク管理装置に送信し、
自装置を差分収集モードとした後に、自装置にＭＩＢ削除が発生した場合であって、前記ネットワーク管理装置よりＭＩＢ要求があった場合は、前記ネットワーク管理装置に対して自装置のＭＩＢの削除を通知する
ことを特徴とする管理対象装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23864098A JP3897911B2 (ja) | 1998-08-25 | 1998-08-25 | ネットワーク管理情報収集方法およびネットワーク管理装置ならびに管理対象装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23864098A JP3897911B2 (ja) | 1998-08-25 | 1998-08-25 | ネットワーク管理情報収集方法およびネットワーク管理装置ならびに管理対象装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000066978A JP2000066978A (ja) | 2000-03-03 |
| JP3897911B2 true JP3897911B2 (ja) | 2007-03-28 |
Family
ID=17033152
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP23864098A Expired - Fee Related JP3897911B2 (ja) | 1998-08-25 | 1998-08-25 | ネットワーク管理情報収集方法およびネットワーク管理装置ならびに管理対象装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3897911B2 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10042934A1 (de) * | 2000-08-31 | 2002-03-14 | Rohde & Schwarz | System zum Betrieb, insbesondere zur Fernbedienung und Fernüberwachung von unbemannten Funksendern |
| JP4051906B2 (ja) | 2001-08-20 | 2008-02-27 | ブラザー工業株式会社 | 通信装置及び通信システム |
| CN100343836C (zh) * | 2002-09-18 | 2007-10-17 | 松下电器产业株式会社 | 信息获取装置和信息提供装置 |
| KR101058004B1 (ko) | 2004-04-16 | 2011-08-19 | 삼성전자주식회사 | 네트워크 장치의 고유 관리정보베이스를 이용한 간이망관리 프로토콜 네트워크 관리방법 및 장치 |
| CN101023606A (zh) * | 2004-06-30 | 2007-08-22 | 西门子公司 | 在pon中获得光功率电平的方法和装置 |
| JP4684883B2 (ja) * | 2005-12-21 | 2011-05-18 | 富士通株式会社 | 属性情報収集装置、属性情報収集方法および属性情報収集プログラム |
| JP4631920B2 (ja) * | 2008-03-07 | 2011-02-16 | コニカミノルタビジネステクノロジーズ株式会社 | データ送信装置、プログラム、およびデータ送信方法 |
| JP2011060056A (ja) | 2009-09-11 | 2011-03-24 | Fujitsu Ltd | シェルフ管理装置及びデータ処理システム |
| JP5754192B2 (ja) * | 2011-03-18 | 2015-07-29 | 株式会社リコー | 管理システム及び管理方法 |
| JP2013250691A (ja) * | 2012-05-31 | 2013-12-12 | Hitachi Ltd | 通信装置および方法 |
| US20140185443A1 (en) * | 2012-12-28 | 2014-07-03 | Futurewei Technologies, Inc. | Data optimization technique for the exchange of data at the edge of a wireless local area network |
| JP6091246B2 (ja) * | 2013-02-21 | 2017-03-08 | キヤノン株式会社 | 管理装置、管理装置の制御方法、及びプログラム |
| JP5907927B2 (ja) * | 2013-04-22 | 2016-04-26 | 京セラドキュメントソリューションズ株式会社 | 機器管理システム、電子機器、および機器管理プログラム |
-
1998
- 1998-08-25 JP JP23864098A patent/JP3897911B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000066978A (ja) | 2000-03-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0621706B1 (en) | System and method for monitoring simple network management protocol tables | |
| JP3897911B2 (ja) | ネットワーク管理情報収集方法およびネットワーク管理装置ならびに管理対象装置 | |
| US7756953B2 (en) | Method and apparatus for monitoring responses of configuration commands | |
| US7328260B1 (en) | Mapping discovered devices to SAN-manageable objects using configurable rules | |
| US20020165934A1 (en) | Displaying a subset of network nodes based on discovered attributes | |
| CA2287769C (en) | Management system for a multi-level communication network | |
| US7886031B1 (en) | SAN configuration utility | |
| US8180872B1 (en) | Common data model for heterogeneous SAN components | |
| EP0348331B1 (en) | Method of efficiently updating the topology databases of the nodes in a data communications network | |
| US7024450B1 (en) | Method and apparatus for deploying service modules among service nodes distributed in an intelligent network | |
| US5886643A (en) | Method and apparatus for discovering network topology | |
| CN101061688B (zh) | 基于简单网络管理协议的网络管理设备和方法 | |
| US20060085532A1 (en) | Remote management of communication devices | |
| US20040205689A1 (en) | System and method for managing a component-based system | |
| EP1102433A2 (en) | Method and device for fault monitoring | |
| CN101099398B (zh) | 用于在管理网络中在管理器和代理之间匹配信息的方法和装置 | |
| CN114650226A (zh) | 拓扑管理方法及其装置、网元管理节点、存储介质 | |
| US7376694B2 (en) | Coalescing information from multiple sources based on priority rules | |
| JP4673532B2 (ja) | マルチマネージャ環境における包括アライメントプロセス | |
| US6009430A (en) | Method and system for provisioning databases in an advanced intelligent network | |
| EP1649637B1 (en) | Apparatus and method for managing traps in a network | |
| JPH10210034A (ja) | ネットワーク管理システム | |
| JPH08147231A (ja) | ネットワークノードの検索方法 | |
| Williamson et al. | An architecture for remote network management using the RMON MIB and programmable agents | |
| JP2002169733A (ja) | ネットワーク管理システムの同期制御方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20030228 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20030228 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060207 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060407 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060407 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060919 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061116 |
|
| 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: 20061219 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061220 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100105 Year of fee payment: 3 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100105 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100105 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |