(57)【要約】ＳＮＭＰプロキシエージェントは、ＳＮＭＰを管理プロトコルとしない被監視装置から受信される管理情報をＳＮＭＰに対応する形式に変換する形式変換部と、上記管理情報に含まれる上記被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換するＩＰアドレス変換部と、上記仮想ＩＰアドレスが送信元に設定され変換後の管理情報を含むＳＮＭＰトラップを生成するトラップ生成部と、上記生成されたＳＮＭＰトラップをＳＮＭＰマネージャに送信する送信部とを備える。
2004071014.tif 000002
【特許請求の範囲】
【請求項１】
ＳＮＭＰを管理プロトコルとしない被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換する手段と、
前記仮想ＩＰアドレスが送信元に設定されたＳＮＭＰマネージャ宛のＳＮＭＰトラップを生成する手段とを備えるＳＮＭＰプロキシエージェント。
【請求項２】
ＳＮＭＰを管理プロトコルとしない被監視装置から受信される管理情報をＳＮＭＰに対応する形式に変換する形式変換手段と、
前記管理情報に含まれる前記被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換するＩＰアドレス変換手段と、
前記仮想ＩＰアドレスが送信元に設定され変換後の管理情報を含むＳＮＭＰトラップを生成するトラップ生成手段と、
前記生成されたＳＮＭＰトラップをＳＮＭＰマネージャに送信する送信手段とを備えるＳＮＭＰプロキシエージェント。
【請求項３】
前記トラップ生成手段は、ＳＮＭＰを管理プロトコルとする他の被監視装置からの管理情報が受信された場合には、その被監視装置が保持する実際のＩＰアドレスが送信元に設定されたトラップを生成する
請求の範囲１又は２記載のＳＮＭＰプロキシエージェント。
【請求項４】
前記トラップ生成手段は、前記被監視装置に対応するＳＮＭＰのバージョンがバージョン１の場合には、前記仮想ＩＰアドレスをＳＮＭＰバージョン１のトラップフォーマットのエージェントアドレス部に制御情報として設定する請求の範囲１又は２記載のＳＮＭＰプロキシエージェント。
【請求項５】
前記トラップ生成手段は、前記被監視装置に対応するＳＮＭＰのバージョンがバージョン２の場合には、前記仮想ＩＰアドレスをＳＮＭＰバージョン２のトラップフォーマットのデータ本体部にオブジェクトとして設定する
請求の範囲１又は２記載のＳＮＭＰプロキシエージェント。
【請求項６】
前記トラップ生成手段は、前記被監視装置に対応するＳＮＭＰのバージョンがバージョン３の場合には、前記仮想ＩＰアドレスをＳＮＭＰバージョン３のトラップフォーマットのデータ本体部にオブジェクトとして設定する
請求の範囲１又は２記載のＳＮＭＰプロキシエージェント。
【請求項７】
ＳＮＭＰプロキシエージェントとして機能するコンピュータがＳＮＭＰマネージャの管理対象となる被監視装置からの管理情報を中継する方法であって、
ＳＮＭＰを管理プロトコルとしない被監視装置から受信される管理情報をＳＮＭＰに対応する形式に変換するステップと、
前記管理情報に含まれる前記被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換するステップと、
前記仮想ＩＰアドレスが送信元に設定され変換後の管理情報を含むＳＮＭＰトラップを生成するステップと、
前記生成されたＳＮＭＰトラップをＳＮＭＰマネージャに送信するステップとを含む管理情報中継方法。
【発明の詳細な説明】
【技術分野】  本発明はＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ：簡易ネットワーク管理プロトコル）などのマネージャ・エージェント構造を持つマネージャ・エージェントモデルシステムに関する。更に詳細には、本発明はＳＮＭＰを管理プロトコルとしない被監視装置をＳＮＭＰマネージャで監視するために，被監視装置の監視プロトコルをＳＮＭＰに変換するＳＮＭＰプロキシエージェントに関する。
【背景技術】  従来、複数のネットワーク構成装置（伝送装置などの被監視装置）とこれらのネットワーク構成装置を接続する伝送路とを含むネットワーク（管理対象システム）と、このネットワークを監視して管理情報を収集する監視装置（管理ステーション）とから構成されるネットワーク管理システムが種々存在する。
例えば、ＳＮＭＰに則ってＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスを持たない複数の非ＳＮＭＰ対応の伝送装置（エージェント）を監視するために、ＳＮＭＰプロキシエージェントをエージェントとマネージャとの間に配置しているネットワーク管理システムとしてのマネージャ・エージェントモデルシステムがある。
従来のＳＮＭＰプロキシエージェントでは、ＳＮＭＰを管理プロトコルとしない被監視装置から送信される障害情報及び装置状態情報などの管理情報に関しては、それら管理情報をＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）形式に変換してＳＮＭＰマネージャに通知する際、送信元アドレスとしてＳＮＭＰプロキシエージェントのＩＰアドレスを設定していた。そのため、ＳＮＭＰマネージャにて管理情報の送信元である被監視装置を識別するために、被監視装置のローカルアドレス（本発明では、ＩＰアドレス以外の装置名、装置番号等を示す）をＭＩＢのインデックス情報として使用することになり、様々な形式で存在するローカルアドレスにより装置を識別していた。これに対し、「特許第３０１７０８９号公報：ネットワーク管理装置および方法（特許文献１）」で示されるように、ＳＮＭＰマネージャにおいて被監視装置のローカルアドレスを仮想ＩＰアドレスに変換し、その仮想ＩＰアドレスをＳＮＭＰマネージャ内部で送信元アドレスに設定し直すことで統一形式により識別を行うなどの工夫を行っていた。その他に、「特開２０００−２３６３４８号公報：インターネットプロトコルを用いた遠隔機器の管理システム（特許文献２）」で示されるように、プロキシエージェントに仮想的なＩＰアドレスを持たせ、そのＩＰアドレスの仮想的に割り当てられたソケットを送信元として、マネージャと通信を行う構成を採用していた。
上述のように、従来では、被監視装置のローカルアドレスをインデックスとするため、装置を識別するための情報がＩＰアドレス以外の形式で混在し、ＳＮＭＰマネージャの管理方法が統一できず、ＳＮＭＰマネージャの管理や操作が煩雑になるといった問題があった。その問題に対して、「特許第３０１７０８９号公報（特許文献１）」に示されるような、ＳＮＭＰマネージャにおいてローカルアドレスからＩＰアドレスへの変換を行う方法では、ＩＰアドレスで統一的に管理が可能となるが、ＳＮＭＰマネージャ内部において被監視装置のローカルアドレスを管理する必要があるため、新たにサポートする非ＳＮＭＰ系装置が追加になった場合には、ＳＮＭＰプロキシエージェントと共に前記アドレス変換部も改造する必要があった。即ち、システムの管理元であるＳＮＭＰマネージャを改造することになるため、改造が複雑になり手間がかかるという問題があった。また、「特開２０００−２３６３４８号公報（特許文献２）」に示されるような、ＩＰアドレスを仮想的に割り当てたソケットを送信元とする方法では、新たにサポートする非ＳＮＭＰ系装置が追加になった場合には、プロキシエージェント自体のＩＰアドレス設定の変更（ソケットの増加）を行う必要が生じ、ＯＳレベルのシステム変更が必須になる上、さらに、非ＳＮＭＰ系装置が増加し続けると、システム全体の通信性能が落ち、システムの資源の枯渇に繋がるという問題があった。
【特許文献１】特許第３０１７０８９号公報
【特許文献２】特開２０００−２３６３４８号公報
【発明の開示】
本発明は、上述した問題点を解決するためになされたものである。即ち、本発明の目的の一つは、ＳＮＭＰマネージャの管理方法が統一でき、管理や操作が容易になるＳＮＭＰプロキシエージェントを提供することにある。
また、本発明の目的の一つは、新たにサポートする非ＳＮＭＰ系装置が追加になった場合でもＳＮＭＰエージェントのＩＰアドレス管理に関する改造を必要としないＳＮＭＰプロキシエージェントを提供することにある。
本発明は、上記課題を解決するために、以下の手段を採用した。即ち、本発明は、
ＳＮＭＰを管理プロトコルとしない被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換する手段と、
上記仮想ＩＰアドレスが送信元に設定されたＳＮＭＰマネージャ宛のＳＮＭＰトラップを生成する手段とを備えるＳＮＭＰプロキシエージェントである。
更に詳しくは、本発明は、
ＳＮＭＰを管理プロトコルとしない被監視装置から受信される管理情報をＳＮＭＰに対応する形式に変換する形式変換手段と、
上記管理情報に含まれる上記被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換するＩＰアドレス変換手段と、
上記仮想ＩＰアドレスが送信元に設定され変換後の管理情報を含むＳＮＭＰトラップを生成するトラップ生成手段と、
上記生成されたＳＮＭＰトラップをＳＮＭＰマネージャに送信する送信手段とを備えるＳＮＭＰプロキシエージェントである。
これにより、ＳＮＭＰを管理プロトコルとしない被監視装置から受信される管理情報とその管理情報の送信元である被監視装置を識別する際に、ＳＮＭＰマネージャ側で、ＩＰアドレスにより統一的な形式で管理することができる。
好ましくは、上記トラップ生成手段は、ＳＮＭＰを管理プロトコルとする他の被監視装置からの管理情報が受信された場合には、その被監視装置が保持する実際のＩＰアドレスが送信元に設定されたトラップを生成すればよい。
これにより、ＳＮＭＰを管理プロトコルとする被監視装置から受信される管理情報についても、ＳＮＭＰマネージャ側で、ＳＮＭＰを管理プロトコルとしない被監視装置と同様に管理することができる。
好ましくは、上記トラップ生成手段は、上記被監視装置に対応するＳＮＭＰのバージョンがバージョン１の場合には、上記仮想ＩＰアドレスをＳＮＭＰバージョン１のトラップフォーマットのエージェントアドレス部に制御情報として設定すればよい。
好ましくは、上記トラップ生成手段は、上記被監視装置に対応するＳＮＭＰのバージョンがバージョン２の場合には、上記仮想ＩＰアドレスをＳＮＭＰバージョン２のトラップフォーマットのデータ本体部にオブジェクトとして設定すればよい。
好ましくは、上記トラップ生成手段は、上記被監視装置に対応するＳＮＭＰのバージョンがバージョン３の場合には、上記仮想ＩＰアドレスをＳＮＭＰバージョン３のトラップフォーマットのデータ本体部にオブジェクトとして設定すればよい。
これにより、ＳＮＭＰのバージョンに応じたトラップを生成して、ＳＮＭＰマネージャ側に送信することができる。
本発明は、コンピュータが、以上のいずれかの処理を実行する方法であってもよい。即ち、本発明は、
ＳＮＭＰプロキシエージェントとして機能するコンピュータがＳＮＭＰマネージャの管理対象となる被監視装置からの管理情報を中継する方法であって、
ＳＮＭＰを管理プロトコルとしない被監視装置から受信される管理情報をＳＮＭＰに対応する形式に変換するステップと、
上記管理情報に含まれる上記被監視装置の特定情報をこの被監視装置を示す仮想ＩＰアドレスに変換するステップと、
上記仮想ＩＰアドレスが送信元に設定され変換後の管理情報を含むＳＮＭＰトラップを生成するステップと、
上記生成されたＳＮＭＰトラップをＳＮＭＰマネージャに送信するステップとを含む管理情報中継方法である。
このようにＳＮＭＰプロキシエージェントを被監視装置とＳＮＭＰマネージャの間に設置して管理情報を中継することにより、ＳＮＭＰマネージャの管理対象となる被監視装置からの管理情報がＳＮＭＰマネージャに送信される場合、ＳＮＭＰマネージャ側で管理し易いアドレス形式やデータ形式となる管理情報をトラップとしてＳＮＭＰマネージャに与えることができる。
本発明によれば、ＳＮＭＰプロキシエージェントにおいて、送信される管理情報に含まれる被監視装置を特定する情報を仮想なＩＰアドレス形式に変換するため、ＳＮＭＰマネージャ側では、被監視情報を特定するための情報をすべてＩＰアドレス形式で認識でき、管理方法が統一できるため、管理や操作が容易になる。
また、本発明によれば、ＳＮＭＰマネージャ上で被監視装置のローカルアドレスを管理する必要が無いため、新たにサポートする非ＳＮＭＰ系装置が追加になった場合でもＳＮＭＰエージェントのＩＰアドレス管理に関する改造が不要となる。
【図面の簡単な説明】  ＦＩＧ．１は、本発明の一実施の形態のマネージャ・エージェントモデルシステムを示すブロック図であり、
ＦＩＧ．２は、ＦＩＧ．１に示すプロキシエージェントの構成及び動作について説明するためのブロック図であり、
ＦＩＧ．３は、ＩＰ変換テーブルのデータ構造を示す図であり、
ＦＩＧ．４は、ＩＰフレームのデータ構造を示す図であり、
ＦＩＧ．５は、ＳＮＭＰｖ１におけるトラップのデータ構造を示す図であり、
ＦＩＧ．６は、ＳＮＭＰｖ２（ｖ３）におけるトラップのデータ構造を示す図であり、
ＦＩＧ．７は、ＩＰアドレス変換部における処理を示すフローチャートであり、
ＦＩＧ．８は、トラップ生成部における処理を示すフローチャートである。
【発明を実施するための最良の形態】  次に、本発明の実施の形態について図面を参照して説明する。
〔マネージャ・エージェントモデルシステムの構成〕
ＦＩＧ．１は、本発明の一実施の形態のマネージャ・エージェントモデルシステムを示すブロック図である。
本発明の一実施の形態を示すＦＩＧ．１を参照すると、ネットワーク管理プロトコルとしてのＳＮＭＰのマネージャ・エージェント構造を持つマネージャ・エージェントモデルシステムは、非ＳＮＭＰ対応エージェントのネットワーク構成装置としての複数の被監視装置（ＮＥ＃１，＃２・・・）と、これらの被監視装置を後に詳述するプロキシエージェント１に接続する伝送路及びＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）とを含む非ＳＮＭＰネットワーク２（管理対象システム）を備える。
また、マネージャ・エージェントモデルシステムは、ＳＮＭＰ対応エージェントのネットワーク構成装置としての複数の被監視装置（ＮＥ＃１１〜＃１２）と、これらの被監視装置をプロキシエージェント１に接続するＩＰネットワークとしてのＬＡＮとを含むＳＮＭＰネットワーク３（管理対象システム）を備える。
このマネージャ・エージェントモデルシステムは、更にＩＰネットワークとしてのＬＡＮを通してプロキシエージェント１に接続され、管理対象システムを監視して障害情報及び装置の状態変化情報などの管理情報を収集する監視装置としてのＳＮＭＰマネージャを有するＳＮＭＰネットワーク４（管理ステーション）を備えている。
管理対象システムの非ＳＮＭＰネットワーク２及びＳＮＭＰネットワーク３をそれぞれ構成する被監視装置のそれぞれは、具体的には伝送装置などであり、図示省略の複数の端末装置を収容している。ここでは、非ＳＮＭＰネットワーク２の被監視装置は、伝送路を介して縦続接続形態を採っているが、リング型（ループ状）接続など他の接続形態を採ることも可能である。
管理対象システム２、３における各被監視装置は、プロキシエージェント１を介し、ネットワークの障害や被監視装置の状態等を管理ステーション４におけるＳＮＭＰマネージャに知らせるために、コネクションレス型プロトコルＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）上で動作するネットワーク管理のための管理情報の交換プロトコルであるＳＮＭＰに則ったメッセージのうちのトラップ（ＴＲＡＰ）を使用する。
このトラップは、管理対象システム２、３における各被監視装置から管理ステーション４におけるマネージャにプロキシエージェント１を介し、自律的にかつ単方向に送信される。
〔プロキシエージェントのシステム構成及び動作の概要〕
次に、ＦＩＧ．１に示すプロキシエージェント１の構成及び動作についてＦＩＧ．２を用いて説明する。
ＦＩＧ．２は、ＳＮＭＰプロキシエージェント１のシステムの一例を示すブロック図である。ＳＮＭＰプロキシエージェント１は、システムの管理対象である被監視装置５（ＮＥ）とシステムの管理元であるＳＮＭＰマネージャ６との間に接続される。ＳＮＭＰプロキシエージェント１は、例えば、サーバマシン等のコンピュータで構成され、図示しないが、ＣＰＵ等のプロセッサと、主記憶装置と、補助記憶装置と、通信制御装置と、入力装置と、出力装置とを備え、更に、ＦＩＧ．２に示すように、ＮＥ通信部１０と、ＭＩＢ変換部２０と、ＩＰアドレス変換部３０と、トラップ生成部４０と、マネージャ通信部５０と、ＩＰ変換テーブル６０とを含む装置として機能する。
次に、ＳＮＭＰプロキシエージェント１内で機能する各構成要素の動作の概要について説明する。ＮＥ通信部１０は、被監視装置５（ＮＥ）から送信される管理情報（障害情報、装置の状態変化情報など）を受信し、その受信した内容をＭＩＢ変換部２０に通知する。ＭＩＢ変換部２０は、ＮＥ通信部１０から通知される情報を受信し、その内容をＭＩＢ形式に変換して、ＩＰアドレス変換部３０に通知する。ＩＰアドレス変換部３０は、ＭＩＢ変換部２０から通知された情報に含まれる送信元（発生元）のＩＰアドレスを条件によって変換し、変換後のＩＰアドレスを送信元（発生元）ＩＰアドレスとしてトラップ生成部４０に通知する。送信元ＩＰアドレスは、ＩＰ変換テーブル６０を参照することにより取得する。即ち、被監視装置を特定する情報であるローカルアドレス（ＮＥＮｏ．；装置番号）と各ＩＰアドレスの組を登録したＩＰ変換テーブル６０を参照して、被監視装置を特定する情報であるローカルアドレス（ＮＥＮｏ．；装置番号）と仮想ＩＰアドレスとを変換する。
トラップ生成部４０は、ＩＰアドレス変換部３０から通知された情報を元にトラップを生成して、その内容をマネージャ通信部５０に通知する。即ち、通知された仮想ＩＰアドレスと管理情報（障害情報、装置の状態変化情報など）を元に、その仮想ＩＰアドレスを送信元としたトラップを生成する。なお、トラップ生成部４０は、ＩＰプロトコルを管理プロトコルの下位レイヤで使用している被監視装置に対しては、被監視装置の実ＩＰアドレスを送信元としたトラップを生成する。マネージャ通信部５０は、トラップ生成部４０から受信したトラップを含むＩＰフレームをＳＮＭＰマネージャ６に対して送信する。この時、ＩＰフレームのＩＰヘッダの送信元アドレスには、仮想ＩＰアドレスが設定される。
〔データ構成〕
次に、各データ６０〜９０のデータ構造について、ＦＩＧ．３〜ＦＩＧ．６を用いて説明する。
《ＩＰ変換テーブル》
ＦＩＧ．３は、ＩＰ変換テーブル６０のデータ構造の例を示す。ＩＰ変換テーブル６０において、ＮＥＮｏ．は、被監視装置に対して付けられた被監視装置を識別するための装置番号である。本実施形態では、ＮＥＮｏ．（装置番号）をローカルアドレスとして示している。仮想ＩＰアドレスは、各被監視装置（ＮＥＮｏ．）に対応する仮想的なＩＰアドレスである。なお、被監視装置がＳＮＭＰに対応している場合には、仮想ＩＰアドレスを示すフィールド部に被監視装置の実ＩＰアドレスが格納される。ＳＮＭＰＶｅｒ．は、各被監視装置（ＮＥＮｏ．）に対応するＳＮＭＰのバージョン情報を示す。
《ＩＰフレーム》
ＦＩＧ．４は、ＩＰフレーム７０のデータ構造の例を示す。ＩＰフレーム７０は、データの識別情報や処理の優先順位等の制御情報を含むＩＰヘッダ部と送信データ本体を含むＩＰデータ部とから構成される。ＩＰヘッダ部の構成については、既に知られているため詳細な説明は省略し、本実施形態に関連する要素のみを説明する。ＩＰヘッダ部は、主な要素として、送信元アドレス（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）と、送信先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）とを示す各フィールド部を有する。ＩＰヘッダの送信元アドレス部（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）には、トラップ生成部４０において、ＩＰアドレス変換部３０より得られた被監視装置の仮想ＩＰアドレスが設定される。ＩＰヘッダの送信先アドレス部（Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）には、ＳＮＭＰマネージャ６のＩＰアドレスが設定される。ＩＰデータ部は、送信データ本体（障害情報、装置の状態変化情報などの管理情報）にトランスポート層のヘッダ（本実施形態では、ＵＤＰヘッダとなる）を付加した構成となる。
《トラップデータ》
次に、本実施形態において、被監視装置から送信される管理情報に対して、ＳＮＭＰプロキシエージェント１とＳＮＭＰマネージャ６間で授受されるＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）であるトラップのデータ構造について説明する。トラップは、エージェント側で発生したイベント（障害、装置の状態変化）をマネージャに通知するために使用される。本実施形態において、トラップは、ＳＮＭＰｖ１、ｖ２、ｖ３において適用できるため、各トラップについてＦＩＧ．５〜ＦＩＧ．７を用いて説明する。なお、各トラップのデータ構造については、一般に知られているため詳細な説明は省略し、本発明に関連する主な要素のみを説明する。
ＦＩＧ．５には、ＳＮＭＰｖ１におけるトラップ８０のデータ構造の例を示す。トラップ８０は、制御情報等を含むヘッダ部と管理情報であるデータ本体を含むデータ部（Ｖａｒｉａｂｌｅ  ｂｉｎｄｉｎｇ：可変結合部）とから構成される。ヘッダ部は、主な要素として、送信元アドレス（Ａｇｅｎｔ  Ａｄｄｒｅｓｓ）を示すフィールド部を有する。送信元アドレス部（Ａｇｅｎｔ  Ａｄｄｒｅｓｓ）には、トラップ生成部４０において、ＩＰアドレス変換部３０より得られた被監視装置の仮想ＩＰアドレスが設定される。データ部は、ＭＩＢオブジェクト識別子とデータの組み合わせを設定する各フィールドを有する。トラップ８０は、情報をオブジェクトとして扱い、それぞれのフィールド部にオブジェクト識別子を付けて情報を管理する。
ＦＩＧ．６には、ＳＮＭＰｖ２（ｖ３）におけるトラップ９０のデータ構造の例を示す。このトラップ９０は、ＳＮＭＰｖ２に対応する。トラップ９０は、制御情報等を含むヘッダ部と管理情報であるデータ本体を含むデータ部（Ｖａｒｉａｂｌｅ  ｂｉｎｄｉｎｇ：可変結合部）とから構成される。ヘッダ部の構成は、本発明に深く関連しないので、詳細な説明については省略する。データ部は、ＭＩＢオブジェクト識別子とデータとの組み合わせを含む送信元アドレス（ＩＰ  Ａｄｄｒｅｓｓ）を示すフィールド部を有する。送信元アドレス部（ＩＰ  Ａｄｄｒｅｓｓ）には、トラップ生成部４０において、ＩＰアドレス変換部３０より得られた被監視装置の仮想ＩＰアドレスが設定される。トラップ９０は、トラップ８０と同様に、情報をオブジェクトとして扱う。
なお、ＳＮＭＰｖ３のトラップのデータ構造は、ＦＩＧ．６に示すＳＮＭＰｖ２のトラップのデータ構造と同じであるため、詳細な説明については省略する。ＳＮＭＰｖ３のトラップは、各被監視装置（ＮＥＮｏ．）に対応するＳＮＭＰのバージョンがｖ３の時に適用される。
〔ＩＰアドレス変換部における動作フロー〕
次に、ＳＮＭＰプロキシエージェント１内のＩＰアドレス変換部３０の具体的な処理について、ＦＩＧ．７を用いて説明する。
ＦＩＧ．７は、ＩＰアドレス変換部３０における動作フローの例である。ＩＰアドレス変換部３０は、ＭＩＢ変換部２０から通知された管理情報に対し、その管理情報に含まれる、送信元となる被監視装置を特定するための情報であるローカルアドレスを条件によって変換し、変換後のＩＰアドレスを送信元のＩＰアドレスとしてトラップ生成部４０に通知する。
まず、ＩＰアドレス変換部３０は、ＭＩＢ変換部２０から情報の通知があるか否かを判断する（Ｓ１）。ＭＩＢ変換部２０から情報の通知があった場合には、その情報の送信元である被監視装置がＩＰアドレスを保持している装置であるか否かを判断する（Ｓ２）。ＭＩＢ変換部２０から通知された情報において、該当する被監視装置がＩＰアドレスを持たない装置であれば、ＦＩＧ．３に示すような予め設定されているＩＰ変換テーブル６０を参照し、対応する仮想ＩＰアドレスを送信元ＩＰアドレスとして設定する（Ｓ３）。また、該当する被監視装置がＩＰアドレスを持つ装置であれば、ＩＰアドレスを変換せず、その被監視装置の持つ実ＩＰアドレスをそのまま送信元ＩＰアドレスとして設定する（Ｓ４）。ＭＩＢ変換部２０から通知された管理情報と得られた送信元ＩＰアドレスとをトラップ生成部４０に通知する（Ｓ５）。このようにして、ＩＰアドレス変換部３０は、管理情報（障害情報、装置の状態変化情報など）を送信した送信元となる被監視装置を特定する情報であるローカルアドレス（ＮＥＮｏ．；装置番号）から、そのローカルアドレスに対応する仮想ＩＰアドレスをＩＰ変換テーブル６０より求め、得られた仮想ＩＰアドレスを含む情報をトラップ生成部４０に通知する。
これにより、被監視装置がＩＰアドレスを持たない場合（被監視装置がＳＮＭＰに対応しない場合）でも、ＩＰアドレス以外の被監視装置を特定する情報（装置名、装置番号等）を仮想的なＩＰアドレスに変換でき、アドレスの形式をＩＰアドレス形式に統一することができる。
〔トラップ生成部における動作フロー〕
次に、ＳＮＭＰプロキシエージェント１内のトラップ生成部４０の具体的な処理について、ＦＩＧ．８を用いて説明する。
ＦＩＧ．８は、トラップ生成部４０における動作フローの例である。
トラップ生成部４０は、ＩＰアドレス変換部３０から通知された管理情報と送信元ＩＰアドレスとを元にトラップを生成して、その内容をマネージャ通信部５０に通知する。
まず、トラップ生成部４０は、ＩＰアドレス変換部３０からトラップ生成部４０に対して、情報の通知があるか否かを判断する（Ｓ１１）。ＩＰアドレス変換部３０から情報の通知があった場合には、トラップを生成する（Ｓ１２）。そして、ＩＰアドレス変換部３０から通知された送信元ＩＰアドレスを、ＩＰヘッダの送信元アドレス部（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）に設定する（Ｓ１３）。
次に、通知された情報を元に管理情報の送信元である被監視装置におけるＳＮＭＰのバージョン情報の判断をする（Ｓ１４）。このバージョン情報は、ＩＰアドレス変換部３０から通知される情報に含まれる。ＳＮＭＰのバージョン情報の判断において、対応するＳＮＭＰのバージョンがｖ１の場合は、ＩＰアドレス変換部３０から通知された送信元ＩＰアドレスをＳＮＭＰトラップＰＤＵの送信元アドレス部（ａｇｅｎｔ  ａｄｄｒｅｓｓ）に設定する（Ｓ１５）。また、対応するＳＮＭＰのバージョンがｖ２、ｖ３の場合は、ＩＰアドレス変換部３０から受信した送信元ＩＰアドレスをＳＮＭＰｖ２（ｖ３）トラップＰＤＵの可変結合部（Ｖａｒｉａｂｌｅ  Ｂｉｎｄｉｎｇ）にオブジェクトとして設定する（Ｓ１６）。
最終的に完成したトラップ情報をマネージャ通信部５０に通知する。なお、非ＳＮＭＰ対応の被監視装置からのアドレスは、各トラップＰＤＵに仮想ＩＰアドレスとして設定されるので、必ずしもＩＰヘッダ部の送信元アドレス部（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）に送信元ＩＰアドレスを設定する必要はなく、ＳＮＭＰマネージャの管理方法に応じて設定すればよい。
これにより、被監視装置がＩＰアドレスを持たない場合（被監視装置がＳＮＭＰに対応しない場合）でも、その被監視装置からの管理情報の送信元をＩＰアドレス形式に統一したトラップを生成することができる。
〔プロキシエージェントの具体的動作例〕
次に、ＳＮＭＰプロキシエージェント１の具体的動作例について、ＦＩＧ．１からＦＩＧ．８を併せ参照して説明する。
具体的には、非ＳＮＭＰ対応のネットワーク上の装置Ｎｏ．「＃２」に状態変化が生じた場合を例に説明する。
ＮＥ通信部１０は、非ＳＮＭＰ対応のネットワーク上の装置「＃２」から管理情報として装置Ｎｏ．情報を含む状態変化情報を受信し、その内容をＭＩＢ変換部１１へと通知する。
ＭＩＢ変換部１１は、ＮＥ通信部１０から通知された管理情報を受信し、その管理情報をＭＩＢ形式に変換してＩＰアドレス変換部３０に通知する。即ち、ＭＩＢ変換部１１は、被監視装置からの管理情報をＳＮＭＰに対応する形式に変換する。
ＩＰアドレス変換部３０は、ＭＩＢ変換部１１からＭＩＢ形式に変換された情報を受信すると、その情報の送信元である被監視装置がＩＰアドレスを保持しているか否かを判別する。この具体例では、装置Ｎｏ．「＃２」はＩＰアドレスを保持しない被監視装置であるので、ＦＩＧ．３に示した、予め設定されているＩＰ変換テーブル６０を参照し、対応する仮想ＩＰアドレス「１９２．１６８．１．１０２」を取得する。この仮想ＩＰアドレスは、管理情報の送信元ＩＰアドレスとしてトラップ生成部４０に通知される。また、ＳＮＭＰに対応するＩＰアドレスを保持する被監視装置の場合は、ＩＰアドレスを変換せず、被監視装置の実ＩＰアドレスを送信元ＩＰアドレスとしてトラップ生成部４０に通知する。
トラップ生成部４０は、ＩＰアドレス変換部３０から通知された送信元ＩＰアドレス「１９２．１６８．１．１０２」を、ＦＩＧ．４に示すＩＰフレームのＩＰヘッダにおける送信元アドレス部（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）に設定する。また、トラップ生成部４０には、ＩＰアドレス変換部３０により、ＦＩＧ．３に示したＩＰ変換テーブル６０を参照することにより取得された、送信元ＩＰアドレス「１９２．１６８．１．１０２」に対応するＳＮＭＰのバージョン情報が通知される。トラップ生成部４０では、このバージョン情報を用いてトラップを生成する。この具体例の場合では、送信元ＩＰアドレス「１９２．１６８．１．１０２」に対応するＳＮＭＰのバージョンは「ｖ２」であるため、ＦＩＧ．６に示すＳＮＭＰｖ２トラップを生成し、トラップＰＤＵの可変結合部（Ｖａｒｉａｂｌｅ  ｂｉｎｄｉｎｇ）にオブジェクトとして送信元ＩＰアドレス「１９２．１６８．１．１０２」を設定する。こうして生成されたトラップをマネージャ通信部５０に通知する。
マネージャ通信部５０は、トラップ生成部４０から通知された、仮想ＩＰアドレス「１９２．１６８．１．１０２」が設定されたＳＮＭＰｖ２トラップをＳＮＭＰマネージャ６に対して送信する。
このように、本発明では、ＩＰアドレスを持たない被監視装置（ＳＮＭＰを管理プロトコルとしない被監視装置）とＩＰアドレスを持つ被監視装置（ＳＮＭＰを管理プロトコルとする被監視装置）とから通知される管理情報をすべてＩＰアドレスという形式により統一的に管理することができる。
以上の実施形態は、一例である。具体的な構成は例の実施形態に限るものではなく、本発明の要旨を逸脱しない限りの設計変更等はこの発明に含まれるものとする。
【産業上の利用可能性】  本発明は、ＳＮＭＰを管理プロトコルとしない被監視装置とＳＮＭＰを管理プロトコルとする被監視装置とをＳＮＭＰマネージャにおいて統一的に管理するシステムに適応可能である。
【図１】
2004071014.tif 000003
【図２】
2004071014.tif 000004
【図３】
2004071014.tif 000005
【図４】
2004071014.tif 000006
【図５】
2004071014.tif 000007
【図６】
2004071014.tif 000008
【図７】
2004071014.tif 000009
【図８】
2004071014.tif 000010
【国際調査報告】
2004071014.tif 000011
2004071014.tif 000012
2004071014.tif 000013
2004071014.tif 000014