JPH08292922A - ネットワーク管理装置 - Google Patents
ネットワーク管理装置Info
- Publication number
- JPH08292922A JPH08292922A JP7097247A JP9724795A JPH08292922A JP H08292922 A JPH08292922 A JP H08292922A JP 7097247 A JP7097247 A JP 7097247A JP 9724795 A JP9724795 A JP 9724795A JP H08292922 A JPH08292922 A JP H08292922A
- Authority
- JP
- Japan
- Prior art keywords
- management
- attribute
- error
- request
- network management
- 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.)
- Pending
Links
Abstract
(57)【要約】
【目的】 簡易ネットワーク管理プロトコル（ＳＮＭ
Ｐ）等を用いた管理装置において、管理属性の取得や設
定の際に要求パケットを最適化し、またエラーリカバリ
ーを行ってネットワークトラフィックを最小にする。 【構成】 管理コンピュータ（マネージャ）１００の主
メモリ１０１に予めＭＩＢ定義を読み込み、各属性の応
答に必要なデータサイズ、ＭＩＢグループ等をプログラ
ム内部に記憶する。オペレータから複数属性の取得要求
等があった場合、ＣＰＵ１０３はエージェントに出す要
求パケットが最小となるように、また同一グループの属
性を同一パケットにしてエージェントでのエラー発生率
が最小となるように最適化ルーチン１０２Ａで最適化す
る。また、エラーリカバリールーチン１０２Ｂを用いて
データサイズが大きすぎる場合にはパケットを自動分割
し、それ以外のエラーは当該属性を削除して再送する。
Ｐ）等を用いた管理装置において、管理属性の取得や設
定の際に要求パケットを最適化し、またエラーリカバリ
ーを行ってネットワークトラフィックを最小にする。 【構成】 管理コンピュータ（マネージャ）１００の主
メモリ１０１に予めＭＩＢ定義を読み込み、各属性の応
答に必要なデータサイズ、ＭＩＢグループ等をプログラ
ム内部に記憶する。オペレータから複数属性の取得要求
等があった場合、ＣＰＵ１０３はエージェントに出す要
求パケットが最小となるように、また同一グループの属
性を同一パケットにしてエージェントでのエラー発生率
が最小となるように最適化ルーチン１０２Ａで最適化す
る。また、エラーリカバリールーチン１０２Ｂを用いて
データサイズが大きすぎる場合にはパケットを自動分割
し、それ以外のエラーは当該属性を削除して再送する。
Description
【０００１】
【産業上の利用分野】本発明は簡易ネットワーク管理プ
ロトコル（以下、ＳＮＭＰという）またはそれに類する
管理プロトコルを用いたネットワーク管理装置、特にネ
ットワーク上の機器を管理する場合の通信の最適化処理
及びリカバリー処理に関する。
ロトコル（以下、ＳＮＭＰという）またはそれに類する
管理プロトコルを用いたネットワーク管理装置、特にネ
ットワーク上の機器を管理する場合の通信の最適化処理
及びリカバリー処理に関する。
【０００２】
【従来の技術】コンピュータのネットワークの通信プロ
トコルとして、伝送制御プロトコル／インターネットプ
ロトコル（ＴＣＰ／ＩＰ）がある。これはもともとアメ
リカの防衛高度研究企画庁（ＤＡＲＰＡ）により開発さ
れたものであるが、現在は国内でも、大学、産業界に広
く普及している。前記のようなインターネットワーク上
の機器等を管理するために、ＳＮＭＰが考案され、イン
ターネットワーク上の機器を管理する際の通信プロトコ
ルとして普及し始めている（但し、ＳＮＭＰはＴＣＰ／
ＩＰのような伝送制御を行わないＵＤＰ／ＩＰプロトコ
ルを基礎としている）。
トコルとして、伝送制御プロトコル／インターネットプ
ロトコル（ＴＣＰ／ＩＰ）がある。これはもともとアメ
リカの防衛高度研究企画庁（ＤＡＲＰＡ）により開発さ
れたものであるが、現在は国内でも、大学、産業界に広
く普及している。前記のようなインターネットワーク上
の機器等を管理するために、ＳＮＭＰが考案され、イン
ターネットワーク上の機器を管理する際の通信プロトコ
ルとして普及し始めている（但し、ＳＮＭＰはＴＣＰ／
ＩＰのような伝送制御を行わないＵＤＰ／ＩＰプロトコ
ルを基礎としている）。
【０００３】ここで、インターネットワーク上の管理装
置は、前記のようなＳＮＭＰを基礎として一般に管理さ
れる機器（被管理装置）上で動作し被管理装置の管理情
報を収集・設定するＳＮＭＰエージェントプログラム
と、複数の被管理装置の情報をＳＮＭＰエージェント経
由で収集・設定して集中管理するネットワーク管理装置
（ＳＮＭＰマネージャ）から構成されている。
置は、前記のようなＳＮＭＰを基礎として一般に管理さ
れる機器（被管理装置）上で動作し被管理装置の管理情
報を収集・設定するＳＮＭＰエージェントプログラム
と、複数の被管理装置の情報をＳＮＭＰエージェント経
由で収集・設定して集中管理するネットワーク管理装置
（ＳＮＭＰマネージャ）から構成されている。
【０００４】
【発明が解決しようとする課題】しかしながら、従来の
ネットワーク管理装置（ＳＮＭＰマネージャ）では、ネ
ットワーク管理のための通信がネットワークに及ぼす影
響について考慮しておらず、そのため管理用の通信が通
信全体に対してかなり大きな比率を占めてしまう不都合
が生じる場合があった。
ネットワーク管理装置（ＳＮＭＰマネージャ）では、ネ
ットワーク管理のための通信がネットワークに及ぼす影
響について考慮しておらず、そのため管理用の通信が通
信全体に対してかなり大きな比率を占めてしまう不都合
が生じる場合があった。
【０００５】また、従来のネットワーク管理装置では、
ＳＮＭＰエージェントでエラーが発生した場合の対策を
特に施しておらず、複数の管理属性を収集する等の際に
不都合が生じる場合があった。
ＳＮＭＰエージェントでエラーが発生した場合の対策を
特に施しておらず、複数の管理属性を収集する等の際に
不都合が生じる場合があった。
【０００６】ネットワーク管理のための管理通信が増大
してしまう原因は、ＳＮＭＰ自体が本来的に抱えている
問題ではあるが、従来技術の問題点を明らかにするため
に具体的に説明する。
してしまう原因は、ＳＮＭＰ自体が本来的に抱えている
問題ではあるが、従来技術の問題点を明らかにするため
に具体的に説明する。
【０００７】図１２に示すように、オペレータが被管理
Ａステーション１００２の管理属性ａ1 、ａ2 、・・
・、ａn を管理ステーション１００１から取得する場合
を想定する。この場合、管理ステーション１００１上の
ＳＮＭＰマネージャプログラムはオペレータからの要求
を図１３のように各管理属性毎に各々別のプロトコルデ
ータユニット（以下、ＰＤＵという）に分割して ＳＮＭＰ−Ｇｅｔ（ａ1 ） ＳＮＭＰ−Ｇｅｔ（ａ2 ） ・・ ＳＮＭＰ−Ｇｅｔ（ｍ） の如く要求し、その応答を ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ａ1 ） ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ａ2 ） ・・ ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ｍ） のように受信し、それをプログラム内部でまとめて図１
４に示すように表示装置上に表示する方法が採用されて
いた。しかし、このような方法では、ｎ個の管理属性を
取得するためにはｎ回の管理通信を実行する必要があ
り、管理通信量が増大してしまう問題が生じる。
Ａステーション１００２の管理属性ａ1 、ａ2 、・・
・、ａn を管理ステーション１００１から取得する場合
を想定する。この場合、管理ステーション１００１上の
ＳＮＭＰマネージャプログラムはオペレータからの要求
を図１３のように各管理属性毎に各々別のプロトコルデ
ータユニット（以下、ＰＤＵという）に分割して ＳＮＭＰ−Ｇｅｔ（ａ1 ） ＳＮＭＰ−Ｇｅｔ（ａ2 ） ・・ ＳＮＭＰ−Ｇｅｔ（ｍ） の如く要求し、その応答を ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ａ1 ） ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ａ2 ） ・・ ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ｍ） のように受信し、それをプログラム内部でまとめて図１
４に示すように表示装置上に表示する方法が採用されて
いた。しかし、このような方法では、ｎ個の管理属性を
取得するためにはｎ回の管理通信を実行する必要があ
り、管理通信量が増大してしまう問題が生じる。
【０００８】また、管理通信量を削減するために、上記
方法とは別の方法として、オペレータからの要求を図１
５に示すように単純に一つのＰＤＵ ＳＮＭＰ−Ｇｅｔ（ａ1 、ａ2 、・・、ｍ） で要求し、その応答 ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ａ1 、ａ2 、・・、
ｍ） を受信して表示する方法も考えられる。しかし、このよ
うな方法では、管理属性の数が増大するとＳＮＭＰの下
位のプロトコルであるＵＤＰ等で決められているデータ
サイズの上限値をある時点で越えてしまい、被管理ステ
ーション側でエラー（Ｔｏｏ−ＢＩＧ：応答に要するデ
ータサイズが大きくなりすぎて応答できない）が発生し
まう問題が生じる。
方法とは別の方法として、オペレータからの要求を図１
５に示すように単純に一つのＰＤＵ ＳＮＭＰ−Ｇｅｔ（ａ1 、ａ2 、・・、ｍ） で要求し、その応答 ＳＮＭＰ−Ｇｅｔ−Ｒｅｓｕｌｔ（ａ1 、ａ2 、・・、
ｍ） を受信して表示する方法も考えられる。しかし、このよ
うな方法では、管理属性の数が増大するとＳＮＭＰの下
位のプロトコルであるＵＤＰ等で決められているデータ
サイズの上限値をある時点で越えてしまい、被管理ステ
ーション側でエラー（Ｔｏｏ−ＢＩＧ：応答に要するデ
ータサイズが大きくなりすぎて応答できない）が発生し
まう問題が生じる。
【０００９】さらに、複数の管理属性を取得（ＳＮＭＰ
−Ｇｅｔ）する場合の問題として、ＳＮＭＰでは被管理
装置（ＳＮＭＰエージェント）がサポートしていない管
理属性を要求された場合は、最初にサポートしていない
管理属性を見つけた時点でその属性へのエラーインデッ
クスを付加してエラー（ＮＯ−ＳＵＣＨ−ＮＡＭＥ）を
返すことができ、その場合サポートしている管理属性の
値を入れなくてもよいという規則なので、ユーザ等の負
担を減らすためにはマネージャプログラムはエラーとな
った原因の属性を除いて再送する等の処理を行う必要が
あるが、従来ではほとんど考慮されていなかった。
−Ｇｅｔ）する場合の問題として、ＳＮＭＰでは被管理
装置（ＳＮＭＰエージェント）がサポートしていない管
理属性を要求された場合は、最初にサポートしていない
管理属性を見つけた時点でその属性へのエラーインデッ
クスを付加してエラー（ＮＯ−ＳＵＣＨ−ＮＡＭＥ）を
返すことができ、その場合サポートしている管理属性の
値を入れなくてもよいという規則なので、ユーザ等の負
担を減らすためにはマネージャプログラムはエラーとな
った原因の属性を除いて再送する等の処理を行う必要が
あるが、従来ではほとんど考慮されていなかった。
【００１０】本発明は上記従来技術の有する課題に鑑み
なされたものであり、第１の目的は、ＳＮＭＰでネット
ワークを管理する際に、管理装置側で管理用の通信を最
適化するように調整して通信業務の通信に影響を及ぼす
ことのない管理装置を提供することにある。
なされたものであり、第１の目的は、ＳＮＭＰでネット
ワークを管理する際に、管理装置側で管理用の通信を最
適化するように調整して通信業務の通信に影響を及ぼす
ことのない管理装置を提供することにある。
【００１１】また、第２の目的は、管理通信でエラーが
発生した際にもそのリカバリーを自動化し、ユーザの負
担を軽減することが可能な管理装置を提供することにあ
る。
発生した際にもそのリカバリーを自動化し、ユーザの負
担を軽減することが可能な管理装置を提供することにあ
る。
【００１２】
【課題を解決するための手段】上記目的を達成するため
に、本発明のネットワーク管理装置は、少なくとも前記
被管理装置が応答可能なデータサイズの最大値及び各管
理属性の応答に必要なデータサイズを記憶する記憶手段
と、複数の管理属性の属性取得要求や属性設定要求の際
に、前記記憶手段に記憶された情報を用いて管理通信を
最適化する処理手段を有することを特徴とする。
に、本発明のネットワーク管理装置は、少なくとも前記
被管理装置が応答可能なデータサイズの最大値及び各管
理属性の応答に必要なデータサイズを記憶する記憶手段
と、複数の管理属性の属性取得要求や属性設定要求の際
に、前記記憶手段に記憶された情報を用いて管理通信を
最適化する処理手段を有することを特徴とする。
【００１３】また、上記目的を達成するために、本発明
のネットワーク管理装置は、前記記憶手段が、さらに少
なくとも各管理属性のグループまたはアクセス権を記憶
することを特徴とする。
のネットワーク管理装置は、前記記憶手段が、さらに少
なくとも各管理属性のグループまたはアクセス権を記憶
することを特徴とする。
【００１４】また、上記目的を達成するために、本発明
のネットワーク管理装置は、前記処理手段が、複数の管
理属性の属性取得要求や属性設定要求の際に、前記各管
理属性の応用に必要なデータサイズを順次加算して前記
データサイズの最大値と大小比較し、前記データサイズ
の最大値を越えた場合に複数の要求ＰＤＵを作成するこ
とを特徴とする。
のネットワーク管理装置は、前記処理手段が、複数の管
理属性の属性取得要求や属性設定要求の際に、前記各管
理属性の応用に必要なデータサイズを順次加算して前記
データサイズの最大値と大小比較し、前記データサイズ
の最大値を越えた場合に複数の要求ＰＤＵを作成するこ
とを特徴とする。
【００１５】また、上記目的を達成するために、本発明
のネットワーク管理装置は、前記処理手段が、複数の管
理属性の属性取得要求や属性設定要求の際に、少なくと
も同じ属性グループまたはアクセス権からなる要求ＰＤ
Ｕを生成することを特徴とする。
のネットワーク管理装置は、前記処理手段が、複数の管
理属性の属性取得要求や属性設定要求の際に、少なくと
も同じ属性グループまたはアクセス権からなる要求ＰＤ
Ｕを生成することを特徴とする。
【００１６】また、上記目的を達成するために、本発明
のネットワーク管理装置は、属性取得要求や属性設定要
求の際に管理通信のエラーを検出するエラー検出手段
と、前記エラーが発生した管理属性に対して所定のリカ
バリー処理を行い、再度属性取得要求や属性設定要求を
実行する処理手段を有することを特徴とする。
のネットワーク管理装置は、属性取得要求や属性設定要
求の際に管理通信のエラーを検出するエラー検出手段
と、前記エラーが発生した管理属性に対して所定のリカ
バリー処理を行い、再度属性取得要求や属性設定要求を
実行する処理手段を有することを特徴とする。
【００１７】また、上記目的を達成するために、本発明
のネットワーク管理装置は、前記処理手段が、前記エラ
ーが発生した管理属性の前後でＰＤＵを分割するリカバ
リー処理を行うことを特徴とする。
のネットワーク管理装置は、前記処理手段が、前記エラ
ーが発生した管理属性の前後でＰＤＵを分割するリカバ
リー処理を行うことを特徴とする。
【００１８】また、上記目的を達成するために、本発明
のネットワーク管理装置は、前記処理手段が、前記エラ
ーが発生した管理属性を削除するリカバリー処理を行う
ことを特徴とする。
のネットワーク管理装置は、前記処理手段が、前記エラ
ーが発生した管理属性を削除するリカバリー処理を行う
ことを特徴とする。
【００１９】
【作用】ＳＮＭＰでは、管理装置側（マネージャ）と被
管理装置側（エージェント）で管理属性のデータ構造や
そのＩＤ等の合意をとるために、一般にＳＭＩ（ＲＦＣ
１１５５、ＲＦＣ１２１２等）という方法で管理属性の
データ構造やそのＩＤ、属性を定義する（管理情報ベー
ス：ＭＩＢ定義）。本発明では、ＳＭＩまたはこれに類
する方法で記述された定義を予め管理装置が記憶してそ
れを解析し、これを用いて管理通信をマネージャ側で最
適化する。管理通信を行う際に、一回の属性読み出し要
求（ＳＮＭＰ−Ｇｅｔ）または書き込み要求（ＳＮＭＰ
−ＳＥＴ）において最適な数だけ属性をまとめて被管理
装置（エージェント）に要求する場合を想定する。記憶
手段に記憶されたＳＭＩを読み込むことで、マネージャ
はある管理属性の応答にエージェントが最大どのくらい
のサイズが必要かを予測できる。一方、上述したよう
に、あまりに多くの属性要求を一回の要求に入れるとエ
ージェントが応答に必要なデータサイズを越えてしまっ
てエラーが発生し、通信効率が低下する。
管理装置側（エージェント）で管理属性のデータ構造や
そのＩＤ等の合意をとるために、一般にＳＭＩ（ＲＦＣ
１１５５、ＲＦＣ１２１２等）という方法で管理属性の
データ構造やそのＩＤ、属性を定義する（管理情報ベー
ス：ＭＩＢ定義）。本発明では、ＳＭＩまたはこれに類
する方法で記述された定義を予め管理装置が記憶してそ
れを解析し、これを用いて管理通信をマネージャ側で最
適化する。管理通信を行う際に、一回の属性読み出し要
求（ＳＮＭＰ−Ｇｅｔ）または書き込み要求（ＳＮＭＰ
−ＳＥＴ）において最適な数だけ属性をまとめて被管理
装置（エージェント）に要求する場合を想定する。記憶
手段に記憶されたＳＭＩを読み込むことで、マネージャ
はある管理属性の応答にエージェントが最大どのくらい
のサイズが必要かを予測できる。一方、上述したよう
に、あまりに多くの属性要求を一回の要求に入れるとエ
ージェントが応答に必要なデータサイズを越えてしまっ
てエラーが発生し、通信効率が低下する。
【００２０】そこで、本発明では処理手段がエージェン
トが応答を返せると考えられる最大のＰＤＵサイズにな
るまで管理属性値を入れてＰＤＵを作成し、エージェン
トに対して要求することで管理通信を最適化することが
できる。
トが応答を返せると考えられる最大のＰＤＵサイズにな
るまで管理属性値を入れてＰＤＵを作成し、エージェン
トに対して要求することで管理通信を最適化することが
できる。
【００２１】また、ＳＮＭＰエージェントがサポートす
る管理属性（ＭＩＢ）にはグループがあり、サポートは
グループ単位で行われることが多い。そこで、ＳＮＭＰ
−ＧｅｔやＳＮＭＰ−ＳＥＴを行う際に、ＭＩＢのグル
ープ毎にまとめて要求を出した方が全体としてエラーの
生じる確率が低下する。そこで、処理手段がグループ毎
にＰＤＵを作成することにより、管理通信量を減らすこ
とが可能となる。
る管理属性（ＭＩＢ）にはグループがあり、サポートは
グループ単位で行われることが多い。そこで、ＳＮＭＰ
−ＧｅｔやＳＮＭＰ−ＳＥＴを行う際に、ＭＩＢのグル
ープ毎にまとめて要求を出した方が全体としてエラーの
生じる確率が低下する。そこで、処理手段がグループ毎
にＰＤＵを作成することにより、管理通信量を減らすこ
とが可能となる。
【００２２】また、ＳＭＩでは管理属性が書き込み可能
かどうかなどのアクセス権の定義もされており、この定
義を予め記憶手段に記憶して書き込み権、読み出し権の
同じ管理属性を同一の要求ＰＤＵにまとめることによ
り、エージェントでのエラー発生確率を低減することが
できる。
かどうかなどのアクセス権の定義もされており、この定
義を予め記憶手段に記憶して書き込み権、読み出し権の
同じ管理属性を同一の要求ＰＤＵにまとめることによ
り、エージェントでのエラー発生確率を低減することが
できる。
【００２３】また、本発明では、エラーを検出した場合
に処理手段が自動的にリカバリー処理を実行するので、
ユーザの管理操作の負担が減少する。ここで、本発明の
リカバリー処理はエラーの種類に応じて以下のように行
われる。すなわち、要求または応答時にデータサイズが
大きすぎる（Ｔｏｏ−Ｂｉｇ）というエラーの場合は、
エラーインデックスが付加されている属性の前後でＰＤ
Ｕを分割し、分割した２つのＰＤＵについてそれぞれＳ
ＮＭＰ−Ｇｅｔ要求もしくはＳＮＭＰ−ＳＥＴ要求を再
度出す。
に処理手段が自動的にリカバリー処理を実行するので、
ユーザの管理操作の負担が減少する。ここで、本発明の
リカバリー処理はエラーの種類に応じて以下のように行
われる。すなわち、要求または応答時にデータサイズが
大きすぎる（Ｔｏｏ−Ｂｉｇ）というエラーの場合は、
エラーインデックスが付加されている属性の前後でＰＤ
Ｕを分割し、分割した２つのＰＤＵについてそれぞれＳ
ＮＭＰ−Ｇｅｔ要求もしくはＳＮＭＰ−ＳＥＴ要求を再
度出す。
【００２４】一方、該当する属性値がないというエラー
（ＮＯ−ＳＵＣＨ−ＮＡＭＥ）の場合は、ＳＮＭＰエー
ジェントがサポートしていない属性値に参照ポインタを
付加してエラー応答するので、処理手段は当該エラーの
発生した属性値を削除する処理を行った後、残りの属性
値群について再度要求を出す。この処理は、エラーが発
生しなくなるまで、もしくは、要求属性値がなくなるま
で実行する。
（ＮＯ−ＳＵＣＨ−ＮＡＭＥ）の場合は、ＳＮＭＰエー
ジェントがサポートしていない属性値に参照ポインタを
付加してエラー応答するので、処理手段は当該エラーの
発生した属性値を削除する処理を行った後、残りの属性
値群について再度要求を出す。この処理は、エラーが発
生しなくなるまで、もしくは、要求属性値がなくなるま
で実行する。
【００２５】なお、その他の一般的なエラー（ＧＥＮ−
ＥＲＲ：カテゴライズできないエラー）、ＳＮＭＰ−Ｓ
ＥＴの場合に起こる設定しようとする値が適当でないと
いうエラー（ＢＡＤ−ＶＡＬＵＥ）、読み込みのみの属
性値に値を設定しようとしたエラー（ＲＥＡＤ−ＯＮＬ
Ｙ）の場合も、当該属性値を削除する処理を行って再度
要求を出すリカバリー処理により対処できる。
ＥＲＲ：カテゴライズできないエラー）、ＳＮＭＰ−Ｓ
ＥＴの場合に起こる設定しようとする値が適当でないと
いうエラー（ＢＡＤ−ＶＡＬＵＥ）、読み込みのみの属
性値に値を設定しようとしたエラー（ＲＥＡＤ−ＯＮＬ
Ｙ）の場合も、当該属性値を削除する処理を行って再度
要求を出すリカバリー処理により対処できる。
【００２６】
【実施例】以下、図面に基づき本発明の実施例について
説明する。
説明する。
【００２７】図１は本発明の管理通信最適化システム、
エラー処理システムを含み、管理ステーションとして用
いるコンピュータ１００のハードウェア構成図である。
エラー処理システムを含み、管理ステーションとして用
いるコンピュータ１００のハードウェア構成図である。
【００２８】図１において、１０１は主メモリ、１０２
はこの主メモリ１０１に記憶させたネットワーク管理ソ
フトウェアで、最適化ルーチン１０２Ａ、エラーリカバ
リールーチン１０２Ｂを有するとともに、図３に示すよ
うな定義ファイルデータの読み込み領域１０２Ｃ、及び
要求待ちキュー領域１０２Ｄを有する。１０４は前記主
メモリ１０１に記憶させたネットワークソフトウェア、
１０５は同オペレーティングシステム、１０６は前記主
メモリ１０１が接続されたシステムバスで、このシステ
ムバス１０６にはキーボード１０７、表示装置１０８、
ネットワークインターフェース１０９、ディスク装置１
１０、及びプリンタ１１１が接続されている。また、１
１２は前記ネットワークインターフェース１０９に接続
されたネットワーク、１０３は前記システムバスを経て
各構成要素を制御するＣＰＵである。
はこの主メモリ１０１に記憶させたネットワーク管理ソ
フトウェアで、最適化ルーチン１０２Ａ、エラーリカバ
リールーチン１０２Ｂを有するとともに、図３に示すよ
うな定義ファイルデータの読み込み領域１０２Ｃ、及び
要求待ちキュー領域１０２Ｄを有する。１０４は前記主
メモリ１０１に記憶させたネットワークソフトウェア、
１０５は同オペレーティングシステム、１０６は前記主
メモリ１０１が接続されたシステムバスで、このシステ
ムバス１０６にはキーボード１０７、表示装置１０８、
ネットワークインターフェース１０９、ディスク装置１
１０、及びプリンタ１１１が接続されている。また、１
１２は前記ネットワークインターフェース１０９に接続
されたネットワーク、１０３は前記システムバスを経て
各構成要素を制御するＣＰＵである。
【００２９】＜最適化処理＞まず、この構成図の管理通
信最適化ルーチンの実施例について説明する。最適化ル
ーチンでは、図２に示すように通信を最適化するように
パケットを生成する処理（Ｓ２１）とその送信処理（Ｓ
２２）に大別される。例えば、図１のデイスク装置１１
０に図３のような定義ファイルを格納し、各属性値に応
答する際のデータの最大値を予め定義しておく。なお、
図３において３０１はオブジェクト識別子であり、３０
２はそのオブジェクトの大きさである。このファイルを
図１の最適化ルーチン１０２Ａ及びエラーリカバリール
ーチン１０２Ｂの初期化時に読み込むことにより、各属
性の応答に必要なデータサイズを定義ファイルデータ読
み込み領域１０２Ｃに保持しておく。また、エージェン
トが処理可能なデータサイズの最大値をディスク装置１
１０に格納された定義ファイル等から主メモリ１０１に
保持しておく。
信最適化ルーチンの実施例について説明する。最適化ル
ーチンでは、図２に示すように通信を最適化するように
パケットを生成する処理（Ｓ２１）とその送信処理（Ｓ
２２）に大別される。例えば、図１のデイスク装置１１
０に図３のような定義ファイルを格納し、各属性値に応
答する際のデータの最大値を予め定義しておく。なお、
図３において３０１はオブジェクト識別子であり、３０
２はそのオブジェクトの大きさである。このファイルを
図１の最適化ルーチン１０２Ａ及びエラーリカバリール
ーチン１０２Ｂの初期化時に読み込むことにより、各属
性の応答に必要なデータサイズを定義ファイルデータ読
み込み領域１０２Ｃに保持しておく。また、エージェン
トが処理可能なデータサイズの最大値をディスク装置１
１０に格納された定義ファイル等から主メモリ１０１に
保持しておく。
【００３０】処理可能データサイズが例えば５１２バイ
トの、ある被管理ステーションからその管理属性値（図
３に示すａ1 、ａ2 、ａ3 、ａ4 ）を取得したい場合
の、ＰＤＵ作成手順を図４のフローチャートを用いて説
明する。
トの、ある被管理ステーションからその管理属性値（図
３に示すａ1 、ａ2 、ａ3 、ａ4 ）を取得したい場合
の、ＰＤＵ作成手順を図４のフローチャートを用いて説
明する。
【００３１】図４において、まずＳ４１では、新しいＰ
ＤＵの生成であるから、ＰＤＵ−ｓｉｚｅは初期値（＝
０）に設定される。次に、Ｓ４２で一番目の管理属性ａ
1 の応答に必要なサイズ（この例の場合、図３より２５
６バイト）を求め、求めたサイズ（ａｔｔ−ｓｉｚｅ）
をＳ４３でＰＤＵ−ｓｉｚｅに加え、ＰＤＵ−ｓｉｚｅ
を更新する。
ＤＵの生成であるから、ＰＤＵ−ｓｉｚｅは初期値（＝
０）に設定される。次に、Ｓ４２で一番目の管理属性ａ
1 の応答に必要なサイズ（この例の場合、図３より２５
６バイト）を求め、求めたサイズ（ａｔｔ−ｓｉｚｅ）
をＳ４３でＰＤＵ−ｓｉｚｅに加え、ＰＤＵ−ｓｉｚｅ
を更新する。
【００３２】次に、Ｓ４４でＰＤＵ−ｓｉｚｅが対象と
なる被管理ステーションの処理可能データサイズ（最大
ＰＤＵ−ｓｉｚｅ：この場合５１２バイト）を越えてい
ないか否かを判断する。当然ながら最初のＰＤＵ−ｓｉ
ｚｅは最大ＰＤＵ−ｓｉｚｅ以下であるからＳ４５に進
み、Ｓ４５で要求ＰＤＵに一番目の管理属性ａ1 を追加
し、Ｓ４６に進む。まだ、要求したい３種類の管理属性
（ａ2 、ａ3 、ａ4 ）が残っているから、Ｓ４６からＳ
４２に戻り、以下同様にして２、３番目の管理属性ａ2
、ａ3 についてＳ４２〜Ｓ４６の処理を繰り返す。
なる被管理ステーションの処理可能データサイズ（最大
ＰＤＵ−ｓｉｚｅ：この場合５１２バイト）を越えてい
ないか否かを判断する。当然ながら最初のＰＤＵ−ｓｉ
ｚｅは最大ＰＤＵ−ｓｉｚｅ以下であるからＳ４５に進
み、Ｓ４５で要求ＰＤＵに一番目の管理属性ａ1 を追加
し、Ｓ４６に進む。まだ、要求したい３種類の管理属性
（ａ2 、ａ3 、ａ4 ）が残っているから、Ｓ４６からＳ
４２に戻り、以下同様にして２、３番目の管理属性ａ2
、ａ3 についてＳ４２〜Ｓ４６の処理を繰り返す。
【００３３】そして、４番目の管理属性（ａ4 ）につい
てのＳ４２〜Ｓ４３の処理において、ＰＤＵ−ｓｉｚｅ
は２５６＋４＋４＋２５６＝５２０バイトとなって最大
ＰＤＵ−ｓｉｚｅを越えることになるから、Ｓ４４にお
いてＳ４８に移行し、それまでの要求ＰＤＵ（１〜３番
目の管理属性までの分）を要求待ちキュー領域１０２Ｄ
に格納しＳ４９へ進む。Ｓ４９では、４番目の管理属性
ａ4 についての新しい要求ＰＤＵを生成するとともに、
ＰＤＵ−ｓｉｚｅをａｔｔ−ｓｉｚｅ（４番目の管理属
性のサイズ）に設定し、Ｓ４６へ進む。この場合には、
さらに取得したい管理属性がないので、Ｓ４９により生
成した要求ＰＤＵをＳ４７で要求待ちキュー領域１０２
Ｄに格納し、要求ＰＤＵの作成を終了する。
てのＳ４２〜Ｓ４３の処理において、ＰＤＵ−ｓｉｚｅ
は２５６＋４＋４＋２５６＝５２０バイトとなって最大
ＰＤＵ−ｓｉｚｅを越えることになるから、Ｓ４４にお
いてＳ４８に移行し、それまでの要求ＰＤＵ（１〜３番
目の管理属性までの分）を要求待ちキュー領域１０２Ｄ
に格納しＳ４９へ進む。Ｓ４９では、４番目の管理属性
ａ4 についての新しい要求ＰＤＵを生成するとともに、
ＰＤＵ−ｓｉｚｅをａｔｔ−ｓｉｚｅ（４番目の管理属
性のサイズ）に設定し、Ｓ４６へ進む。この場合には、
さらに取得したい管理属性がないので、Ｓ４９により生
成した要求ＰＤＵをＳ４７で要求待ちキュー領域１０２
Ｄに格納し、要求ＰＤＵの作成を終了する。
【００３４】このようにして要求待ちキュー領域１０２
Ｄに要求ＰＤＵが格納されると、図２のＳ２２の処理、
すなわち要求待ちキュー領域１０２Ｄが空となるまでＳ
ＮＭＰ要求を出して管理属性の収集あるいは設定を行
う。
Ｄに要求ＰＤＵが格納されると、図２のＳ２２の処理、
すなわち要求待ちキュー領域１０２Ｄが空となるまでＳ
ＮＭＰ要求を出して管理属性の収集あるいは設定を行
う。
【００３５】なお、図４ではＰＤＵサイズを最適化する
例を示したが、ＰＤＵ作成の際に他にも属性のアクセス
権別にＰＤＵを作成すると、さらに管理通信が最適化で
きる。すなわち、図５に示すような定義を読み込むこと
で、各属性が読み込み可能か、書き込み可能か等をプロ
グラム内部に記録する。ここで、図５における５０１は
ＭＩＢへのアクセス権である。そして、ＰＤＵ生成時に
は、読み込み権まである属性と、書き込み権しかない属
性、アクセス自体が禁止されている属性を別々のＰＤＵ
に分けることで、全体としてのエラーの発生を抑えるこ
とができ、ひいては管理通信を減少させることができ
る。
例を示したが、ＰＤＵ作成の際に他にも属性のアクセス
権別にＰＤＵを作成すると、さらに管理通信が最適化で
きる。すなわち、図５に示すような定義を読み込むこと
で、各属性が読み込み可能か、書き込み可能か等をプロ
グラム内部に記録する。ここで、図５における５０１は
ＭＩＢへのアクセス権である。そして、ＰＤＵ生成時に
は、読み込み権まである属性と、書き込み権しかない属
性、アクセス自体が禁止されている属性を別々のＰＤＵ
に分けることで、全体としてのエラーの発生を抑えるこ
とができ、ひいては管理通信を減少させることができ
る。
【００３６】また、ＳＮＭＰエージェントはグループ毎
にＭＩＢをサポートするので、図６に示すような定義フ
ァイル（図において６０１はＭＩＢのグループ定義を表
す）を用意し、それを初期化時に読み込んでプログラム
内部に記録することによりＰＤＵ生成時に同じグループ
を同一のＰＤＵにまとめれば、エージェントでのエラー
発生率が低下し、ひいては管理通信を減少させることが
できる。
にＭＩＢをサポートするので、図６に示すような定義フ
ァイル（図において６０１はＭＩＢのグループ定義を表
す）を用意し、それを初期化時に読み込んでプログラム
内部に記録することによりＰＤＵ生成時に同じグループ
を同一のＰＤＵにまとめれば、エージェントでのエラー
発生率が低下し、ひいては管理通信を減少させることが
できる。
【００３７】なお、上記の各定義は必ずしもＳＭＩであ
る必要はなく、それに類する定義を主メモリ１０１に持
つことにより同様の機能を実現することができる。
る必要はなく、それに類する定義を主メモリ１０１に持
つことにより同様の機能を実現することができる。
【００３８】＜リカバリー処理＞次に、本実施例におけ
るエラーリカバリー処理について説明する。ＳＮＭＰの
応答メッセージを受信した場合、図７に示すように、Ｃ
ＰＵ１０３はＳ７１で成功応答か失敗応答かを判断す
る。成功応答の場合には、表示装置１０８に表示する等
し、失敗応答の場合には、失敗の原因を取り除いた後、
リトライ処理を行う。
るエラーリカバリー処理について説明する。ＳＮＭＰの
応答メッセージを受信した場合、図７に示すように、Ｃ
ＰＵ１０３はＳ７１で成功応答か失敗応答かを判断す
る。成功応答の場合には、表示装置１０８に表示する等
し、失敗応答の場合には、失敗の原因を取り除いた後、
リトライ処理を行う。
【００３９】エラー処理は、２種類に大別され、Ｔｏｏ
−Ｂｉｇエラーとそれ以外のエラーの場合である。Ｔｏ
ｏ−Ｂｉｇエラーの場合は、エージェントが応答しよう
とすると大きなＰＤＵとなってしまうか、もしくはロー
カルシステム内で既に処理できない程ＰＤＵになってし
まっているかのどちらかである。そこで、Ｓ７２でＴｏ
ｏ−Ｂｉｇエラーであると判断した場合には、Ｓ７４に
移行してＰＤＵを分割するエラー処理を行う。
−Ｂｉｇエラーとそれ以外のエラーの場合である。Ｔｏ
ｏ−Ｂｉｇエラーの場合は、エージェントが応答しよう
とすると大きなＰＤＵとなってしまうか、もしくはロー
カルシステム内で既に処理できない程ＰＤＵになってし
まっているかのどちらかである。そこで、Ｓ７２でＴｏ
ｏ−Ｂｉｇエラーであると判断した場合には、Ｓ７４に
移行してＰＤＵを分割するエラー処理を行う。
【００４０】図８にはＳ７４で行われるＴｏｏ−Ｂｉｇ
エラー処理の詳細フローチャートが示されている。ま
ず、Ｓ８１でエージェントから返った属性値が一つか否
かを判断する。一つでない場合には、Ｓ８２に移行して
エラーインデックスがついた属性値の前後でＰＤＵを２
分割し、生成した２つのＰＤＵを再度要求待ちキュー領
域１０２Ｄに入れる。また、返った属性値が一つの場合
には、Ｓ８３に移行してエラーとなった属性値をエラー
属性値リストに入れる。
エラー処理の詳細フローチャートが示されている。ま
ず、Ｓ８１でエージェントから返った属性値が一つか否
かを判断する。一つでない場合には、Ｓ８２に移行して
エラーインデックスがついた属性値の前後でＰＤＵを２
分割し、生成した２つのＰＤＵを再度要求待ちキュー領
域１０２Ｄに入れる。また、返った属性値が一つの場合
には、Ｓ８３に移行してエラーとなった属性値をエラー
属性値リストに入れる。
【００４１】また、Ｔｏｏ−Ｂｉｇエラー以外の場合に
は、図７に示すようにＳ７３に移行し、エラーが生じた
属性値についての収集はあきらめ、残りの属性値を収集
するように再送処理を行う。
は、図７に示すようにＳ７３に移行し、エラーが生じた
属性値についての収集はあきらめ、残りの属性値を収集
するように再送処理を行う。
【００４２】図９にはＳ７３で行われるＴｏｏ−Ｂｉｇ
エラー以外のエラー処理の詳細フローチャートが示され
ている。まず、Ｓ９１でエージェントから返った属性値
が一つか否かを判断する。一つでない場合には、Ｓ９２
に移行してエラーインデックスのついた属性値を除いた
ＰＤＵを生成し、生成したＰＤＵを要求待ちキュー領域
１０２Ｄに入れる。そして、Ｓ９３でエラーとなった属
性値をエらー属性値リストに入れる。一方、返った属性
値が一つの場合には、Ｓ９３に移行して直ちにエラーと
なった属性値をエラーリストに入れる。そして、これら
の処理をエラーが起こらなくなるか、あるいは属性値が
なくなるまで繰り返し実行する。
エラー以外のエラー処理の詳細フローチャートが示され
ている。まず、Ｓ９１でエージェントから返った属性値
が一つか否かを判断する。一つでない場合には、Ｓ９２
に移行してエラーインデックスのついた属性値を除いた
ＰＤＵを生成し、生成したＰＤＵを要求待ちキュー領域
１０２Ｄに入れる。そして、Ｓ９３でエラーとなった属
性値をエらー属性値リストに入れる。一方、返った属性
値が一つの場合には、Ｓ９３に移行して直ちにエラーと
なった属性値をエラーリストに入れる。そして、これら
の処理をエラーが起こらなくなるか、あるいは属性値が
なくなるまで繰り返し実行する。
【００４３】以上のようにしてエラーリカバリー処理が
実行されるが、上述した最適化処理あるいはリカバリー
処理はＳＮＭＰマネージャのみならず、図１０に示すよ
うなプロトコル変換を行う中間マネージャを実現する場
合にも応用することが可能である。図１０はＩＳＯ（国
際標準化機構）で定められた管理プロトコルＣＭＩＰを
使用して広域ネットワークを管理する管理マネージャ１
６０１が、ＣＭＩＰとＳＮＭＰ間プロトコル変換を行う
中間マネージャ１６０２を介してＳＮＭＰネットワーク
１６０４を管理する図である。このような管理形態は、
大規模なネットワークを管理する場合に採用されること
が多い。ここで、中間マネージャ１６０２ではＣＭＩＰ
とＳＮＭＰ間のプロトコル及びデータの変換が行われ
る。中間マネージャはＣＭＩＰ１６０１に対してはＣＭ
ＩＰのエージェントとして機能し、また、ＳＮＭＰネッ
トワーク１６０４に対してはＳＮＭＰマネージャとして
機能することになる。
実行されるが、上述した最適化処理あるいはリカバリー
処理はＳＮＭＰマネージャのみならず、図１０に示すよ
うなプロトコル変換を行う中間マネージャを実現する場
合にも応用することが可能である。図１０はＩＳＯ（国
際標準化機構）で定められた管理プロトコルＣＭＩＰを
使用して広域ネットワークを管理する管理マネージャ１
６０１が、ＣＭＩＰとＳＮＭＰ間プロトコル変換を行う
中間マネージャ１６０２を介してＳＮＭＰネットワーク
１６０４を管理する図である。このような管理形態は、
大規模なネットワークを管理する場合に採用されること
が多い。ここで、中間マネージャ１６０２ではＣＭＩＰ
とＳＮＭＰ間のプロトコル及びデータの変換が行われ
る。中間マネージャはＣＭＩＰ１６０１に対してはＣＭ
ＩＰのエージェントとして機能し、また、ＳＮＭＰネッ
トワーク１６０４に対してはＳＮＭＰマネージャとして
機能することになる。
【００４４】さて、ＣＭＩＰのデータは構造化されたデ
ータであるため、一般にＣＭＩＰデータ一つに対して複
数のＳＮＭＰデータにマッピングされることが多い。例
えば、図１１においてＣＭＩＰマネージャ１７０１から
値の識別子からＡ1 及びＢ1である属性の取得要求（Ｃ
ＭＩＰ−ｇｅｔ−ｒｅｑ（Ａ1 、Ｂ1 ））を出す場合、
この要求は中間マネージャ１７０２部分でプロトコルは
ＳＮＭＰ−ｇｅｔ−ｒｅｑにマッピングされるが、ＣＭ
ＩＰのデータＡ1 、Ｂ1 は構造型であるためＡ1 はＳＮ
ＭＰデータａ1 、ａ2 に、Ｂ1 はＳＮＭＰデータｂ1 、
ｂ2 にマッピングしなければならない場合を想定する。
さらに、ＳＮＭＰエージェント１７０３がデータａ1 、
ａ2 はサポートしているもののデータｂ1 、ｂ2 はサポ
ートしていない場合を想定すると、ＳＮＭＰエージェン
トの応答にはｂ1 、ｂ2 をサポートしていないというこ
とで識別子ｂ1 、ｂ2 はもとよりａ1 、ａ2 についても
一般に値が返らないことになる。
ータであるため、一般にＣＭＩＰデータ一つに対して複
数のＳＮＭＰデータにマッピングされることが多い。例
えば、図１１においてＣＭＩＰマネージャ１７０１から
値の識別子からＡ1 及びＢ1である属性の取得要求（Ｃ
ＭＩＰ−ｇｅｔ−ｒｅｑ（Ａ1 、Ｂ1 ））を出す場合、
この要求は中間マネージャ１７０２部分でプロトコルは
ＳＮＭＰ−ｇｅｔ−ｒｅｑにマッピングされるが、ＣＭ
ＩＰのデータＡ1 、Ｂ1 は構造型であるためＡ1 はＳＮ
ＭＰデータａ1 、ａ2 に、Ｂ1 はＳＮＭＰデータｂ1 、
ｂ2 にマッピングしなければならない場合を想定する。
さらに、ＳＮＭＰエージェント１７０３がデータａ1 、
ａ2 はサポートしているもののデータｂ1 、ｂ2 はサポ
ートしていない場合を想定すると、ＳＮＭＰエージェン
トの応答にはｂ1 、ｂ2 をサポートしていないというこ
とで識別子ｂ1 、ｂ2 はもとよりａ1 、ａ2 についても
一般に値が返らないことになる。
【００４５】ｂ1 、ｂ2 に対応するＣＭＩＰの識別子Ｂ
1 の値が返せないのは最終的にマッピングしたＳＮＭＰ
の値（ｂ1 、ｂ2 ）をＳＮＭＰエージェント１７０３で
サポートしていないので当然であるが、中間マネージャ
１７０２でこのままエラーリカバリーを行わなければＡ
1 についても値が返せないことになり不都合である。な
ぜなら、ＣＭＩＰマネージャ１７０１からＡ1 のみを取
得する要求を同一対象のＳＮＭＰエージェント１７０３
に出せば今度はＳＮＭＰエージェント１７０３はａ1 、
ａ2 はサポートしているのでＳＮＭＰレベルで値が返
り、このままマッピングできるのでＣＭＩＰの属性Ａ1
の値も返ることになる。すなわち、ＣＭＩＰマネージャ
１７０１から見ればＡ1 単数でＣＭＩＰ取得要求を出せ
ば値が返るが、Ａ1 、Ｂ1 でＣＭＩＰ取得要求を出すと
Ａ1 に対する回答も得られなくなってしまうのである。
1 の値が返せないのは最終的にマッピングしたＳＮＭＰ
の値（ｂ1 、ｂ2 ）をＳＮＭＰエージェント１７０３で
サポートしていないので当然であるが、中間マネージャ
１７０２でこのままエラーリカバリーを行わなければＡ
1 についても値が返せないことになり不都合である。な
ぜなら、ＣＭＩＰマネージャ１７０１からＡ1 のみを取
得する要求を同一対象のＳＮＭＰエージェント１７０３
に出せば今度はＳＮＭＰエージェント１７０３はａ1 、
ａ2 はサポートしているのでＳＮＭＰレベルで値が返
り、このままマッピングできるのでＣＭＩＰの属性Ａ1
の値も返ることになる。すなわち、ＣＭＩＰマネージャ
１７０１から見ればＡ1 単数でＣＭＩＰ取得要求を出せ
ば値が返るが、Ａ1 、Ｂ1 でＣＭＩＰ取得要求を出すと
Ａ1 に対する回答も得られなくなってしまうのである。
【００４６】そこで、このような場合でも中間マネージ
ャ１７０２において上述したエラーリカバリー処理を行
うことにより上記不都合を解消することができ、Ａ1 、
Ｂ1複数要求の時もＡ1 のみの要求と同様に少なくとも
Ａ1 については回答を得ることが可能となる。また、一
般にＣＭＩＰのデータは構造化されたデータ形式が多い
のに対し、対応するＳＮＭＰのデータは単純な構造をと
ることが多いため、マッピングした場合ＳＮＭＰのデー
タ数はＣＭＩＰのデータ数に対して数が増大する場合が
多い。従って、一般には一つのＣＭＩＰ要求に対して一
つのＳＮＭＰ要求では対応できず、一つのＣＭＩＰ要求
に対して複数のＳＮＭＰ要求を中間マネージャが生成し
てマッピングすることになる。このような場合、ＳＮＭ
Ｐ領域１７０５で管理するためのパケットが増大するこ
とになるから、なるべく管理パケットを減らして最適化
することが必要となる。
ャ１７０２において上述したエラーリカバリー処理を行
うことにより上記不都合を解消することができ、Ａ1 、
Ｂ1複数要求の時もＡ1 のみの要求と同様に少なくとも
Ａ1 については回答を得ることが可能となる。また、一
般にＣＭＩＰのデータは構造化されたデータ形式が多い
のに対し、対応するＳＮＭＰのデータは単純な構造をと
ることが多いため、マッピングした場合ＳＮＭＰのデー
タ数はＣＭＩＰのデータ数に対して数が増大する場合が
多い。従って、一般には一つのＣＭＩＰ要求に対して一
つのＳＮＭＰ要求では対応できず、一つのＣＭＩＰ要求
に対して複数のＳＮＭＰ要求を中間マネージャが生成し
てマッピングすることになる。このような場合、ＳＮＭ
Ｐ領域１７０５で管理するためのパケットが増大するこ
とになるから、なるべく管理パケットを減らして最適化
することが必要となる。
【００４７】そこで、中間マネージャ１７０２におい
て、上述した最適化処理を実行してＳＮＭＰ領域１７０
５の管理パケットが少なくなるように最適化すれば、ネ
ットワーク管理によるネットワークの負荷を減らすこと
ができる。
て、上述した最適化処理を実行してＳＮＭＰ領域１７０
５の管理パケットが少なくなるように最適化すれば、ネ
ットワーク管理によるネットワークの負荷を減らすこと
ができる。
【００４８】
【発明の効果】以上説明したように、本発明によれば、
ＳＮＭＰまたはそれに類した管理プロトコルを使用した
ネットワーク管理において、被管理装置に最適の属性取
得要求や属性設定要求を出すことができ、管理通信を減
らすことができる。
ＳＮＭＰまたはそれに類した管理プロトコルを使用した
ネットワーク管理において、被管理装置に最適の属性取
得要求や属性設定要求を出すことができ、管理通信を減
らすことができる。
【００４９】また、本発明によれば、少なくとも各管理
属性のグループまたはアクセスの種類を記憶するので、
これらのデータを用いてＰＤＵを最適化することができ
る。
属性のグループまたはアクセスの種類を記憶するので、
これらのデータを用いてＰＤＵを最適化することができ
る。
【００５０】また、本発明によれば、被管理装置に属性
取得要求や属性設定要求を出す際に各ＰＤＵのデータ量
を最適化することができるので、徒にＰＤＵ数を増大さ
せることなく、管理通信を減らすことができる。
取得要求や属性設定要求を出す際に各ＰＤＵのデータ量
を最適化することができるので、徒にＰＤＵ数を増大さ
せることなく、管理通信を減らすことができる。
【００５１】また、本発明によれば、少なくとも各属性
のグループ毎またはアクセスの種類毎にＰＤＵを生成す
ることができるので、全体としてエラーの生じる確率が
低くなり、管理通信を減らすことができる。
のグループ毎またはアクセスの種類毎にＰＤＵを生成す
ることができるので、全体としてエラーの生じる確率が
低くなり、管理通信を減らすことができる。
【００５２】また、本発明によれば、管理通信において
エラーが生じた場合でもそのリカバリーを自動的に実行
するのでユーザの負担を軽減することができる。
エラーが生じた場合でもそのリカバリーを自動的に実行
するのでユーザの負担を軽減することができる。
【００５３】また、本発明によれば、被管理装置側（エ
ージェント側）で応答に要するデータサイズが大きくな
りすぎて応答できないエラーが生じた場合でも、自動的
にＰＤＵを分割処理して再送するので、管理操作の負担
を軽減することができる。
ージェント側）で応答に要するデータサイズが大きくな
りすぎて応答できないエラーが生じた場合でも、自動的
にＰＤＵを分割処理して再送するので、管理操作の負担
を軽減することができる。
【００５４】また、本発明によれば、その他のエラーが
生じた場合でも、自動的にエラーの生じた当該属性を削
除して再送するので、管理操作の負担を軽減することが
できる。
生じた場合でも、自動的にエラーの生じた当該属性を削
除して再送するので、管理操作の負担を軽減することが
できる。
【００５５】なお、本発明におけるリカバリー処理機能
は、ユーザの負担を軽減するのみならず、管理プロトコ
ルのゲートウェイ装置にも適用可能でネットワークの効
率化を図ることができる。
は、ユーザの負担を軽減するのみならず、管理プロトコ
ルのゲートウェイ装置にも適用可能でネットワークの効
率化を図ることができる。
【図１】 本発明の実施例のハードウェア構成図であ
る。
る。
【図２】 同実施例の要求パケット送出時の基本フロー
チャートである。
チャートである。
【図３】 同実施例におけるパケット長最適化のための
定義ファイル説明図である。
定義ファイル説明図である。
【図４】 同実施例における複数属性値を一括要求する
場合の処理フローチャートである。
場合の処理フローチャートである。
【図５】 同実施例におけるアクセスエラー率を低下さ
せるための定義ファイル説明図である。
せるための定義ファイル説明図である。
【図６】 同実施例におけるグループ定義ファイル説明
図である。
図である。
【図７】 同実施例におけるエラーリカバリー処理のフ
ローチャートである。
ローチャートである。
【図８】 同実施例におけるＴｏｏ−Ｂｉｇエラーの処
理フローチャートである。
理フローチャートである。
【図９】 同実施例におけるＴｏｏ−Ｂｉｇエラー以外
のエラーの処理フローチャートである。
のエラーの処理フローチャートである。
【図１０】 本発明の他の実施例における階層化管理説
明図である。
明図である。
【図１１】 ＣＭＩＰとＳＮＭＰのマッピングを行う中
間マネージャの説明図である。
間マネージャの説明図である。
【図１２】 従来のネットワーク構成図である。
【図１３】 従来の第１の手法による管理属性取得要求
説明図である。
説明図である。
【図１４】 従来の受信した属性の表示例を示す図であ
る。
る。
【図１５】 従来の第２の手法による管理属性取得要求
説明図である。
説明図である。
１００ コンピュータシステム、１０１ 主メモリ、１
０２Ａ 管理通信最適化プログラム、１０２Ｂ 管理通
信エラーリカバリープログラム、１０２Ｃ 定義ファイ
ルデータ読み込み領域、１０２Ｄ 要求待ちキュー領
域、１０３ ＣＰＵ、１０４ ネットワークソフトウェ
ア、１０５ オペレーティングシステム、１０６ 内部
システムバス、１０７ キーボード、１０８ 表示装
置、１０９ネットワークインターフェース、１１０ デ
ィスク、１１１ プリンタ、１１２ネットワーク、３０
１ オブジェクト識別子、３０２ オブジェクトの大き
さ、５０１ ＭＩＢへのアクセス、６０１ ＭＩＢのグ
ループ定義、１００１ 管理ステーション、１００２
被管理ステーション、１６０１ ＣＭＩＰマネージャ、
１６０２ 中間マネージャ、１６０３ ＳＮＭＰマネー
ジャ、１６０４ ＳＮＭＰ領域、１７０１ ＣＭＩＰマ
ネージャ、１７０２ 中間マネージャ、１７０３ ＳＮ
ＭＰエージェント、１７０４ ＣＭＩＰ領域、１７０５
ＳＮＭＰ領域。
０２Ａ 管理通信最適化プログラム、１０２Ｂ 管理通
信エラーリカバリープログラム、１０２Ｃ 定義ファイ
ルデータ読み込み領域、１０２Ｄ 要求待ちキュー領
域、１０３ ＣＰＵ、１０４ ネットワークソフトウェ
ア、１０５ オペレーティングシステム、１０６ 内部
システムバス、１０７ キーボード、１０８ 表示装
置、１０９ネットワークインターフェース、１１０ デ
ィスク、１１１ プリンタ、１１２ネットワーク、３０
１ オブジェクト識別子、３０２ オブジェクトの大き
さ、５０１ ＭＩＢへのアクセス、６０１ ＭＩＢのグ
ループ定義、１００１ 管理ステーション、１００２
被管理ステーション、１６０１ ＣＭＩＰマネージャ、
１６０２ 中間マネージャ、１６０３ ＳＮＭＰマネー
ジャ、１６０４ ＳＮＭＰ領域、１７０１ ＣＭＩＰマ
ネージャ、１７０２ 中間マネージャ、１７０３ ＳＮ
ＭＰエージェント、１７０４ ＣＭＩＰ領域、１７０５
ＳＮＭＰ領域。
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.6 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 29/14
Claims (7)
- 【請求項１】 所定のネットワーク管理プロトコルを用
いて被管理装置との間で管理情報の通信を行うネットワ
ーク管理装置であって、 少なくとも前記被管理装置が応答可能なデータサイズの
最大値及び各管理属性の応答に必要なデータサイズを記
憶する記憶手段と、 複数の管理属性の属性取得要求や属性設定要求の際に、
前記記憶手段に記憶された情報を用いて管理通信を最適
化する処理手段と、 を有することを特徴とするネットワーク管理装置。 - 【請求項２】 前記記憶手段は、さらに、少なくとも各
管理属性のグループまたはアクセス権を記憶することを
特徴とする請求項１記載のネットワーク管理装置。 - 【請求項３】 前記処理手段は、複数の管理属性の属性
取得要求や属性設定要求の際に、前記各管理属性の応用
に必要なデータサイズを順次加算して前記データサイズ
の最大値と大小比較し、前記データサイズの最大値を越
えた場合に複数の要求プロトコルデータユニットを作成
することを特徴とする請求項１記載のネットワーク管理
装置。 - 【請求項４】 前記処理手段は、複数の管理属性の属性
取得要求や属性設定要求の際に、少なくとも同じ属性グ
ループまたはアクセス権からなる要求プロトコルデータ
ユニットを生成することを特徴とする請求項２記載のネ
ットワーク管理装置。 - 【請求項５】 所定のネットワーク管理プロトコルを用
いて被管理装置との間で管理情報の通信を行うネットワ
ーク管理装置であって、 属性取得要求や属性設定要求の際に管理通信のエラーを
検出するエラー検出手段と、 前記エラーが発生した管理属性に対して所定のリカバリ
ー処理を行い、再度属性取得要求や属性設定要求を実行
する処理手段と、 を有することを特徴とするネットワーク管理装置。 - 【請求項６】 前記処理手段は、前記エラーが発生した
管理属性の前後でプロトコルデータユニットを分割する
リカバリー処理を行うことを特徴とする請求項５記載の
ネットワーク管理装置。 - 【請求項７】 前記処理手段は、前記エラーが発生した
管理属性を削除するリカバリー処理を行うことを特徴と
する請求項５記載のネットワーク管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7097247A JPH08292922A (ja) | 1995-04-21 | 1995-04-21 | ネットワーク管理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7097247A JPH08292922A (ja) | 1995-04-21 | 1995-04-21 | ネットワーク管理装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH08292922A true JPH08292922A (ja) | 1996-11-05 |
Family
ID=14187261
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP7097247A Pending JPH08292922A (ja) | 1995-04-21 | 1995-04-21 | ネットワーク管理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH08292922A (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20000025701A (ko) * | 1998-10-13 | 2000-05-06 | 윤종용 | 객체지향 기법을 이용한 응용 프로그램 인터페이스 제공 방법 |
| KR100487125B1 (ko) * | 2002-11-28 | 2005-05-03 | 삼성전자주식회사 | 운용자 정보를 통합관리하기 위한 네트워크 시스템 및 그방법 |
| KR100633224B1 (ko) * | 1999-12-30 | 2006-10-11 | 주식회사 케이티 | 종합망관리시스템에서의 장애상관관계를 이용한 트래픽제어 방법 |
| JP2008504765A (ja) * | 2004-06-30 | 2008-02-14 | シーメンス アクチエンゲゼルシヤフト | Ｐｏｎの光出力レベルを取得する方法および装置 |
| US7395325B2 (en) | 2002-03-22 | 2008-07-01 | Brother Kogyo Kabushiki Kaisha | Network management system, apparatus to be managed, management apparatus and program |
| JP2009232180A (ja) * | 2008-03-24 | 2009-10-08 | Seiko Epson Corp | 通信システム、処理要求装置、処理応答装置及びそのプログラム |
| US10439863B2 (en) | 2015-05-29 | 2019-10-08 | Canon Kabushiki Kaisha | Information processing apparatus, information processing method, and computer-readable medium |
-
1995
- 1995-04-21 JP JP7097247A patent/JPH08292922A/ja active Pending
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20000025701A (ko) * | 1998-10-13 | 2000-05-06 | 윤종용 | 객체지향 기법을 이용한 응용 프로그램 인터페이스 제공 방법 |
| KR100633224B1 (ko) * | 1999-12-30 | 2006-10-11 | 주식회사 케이티 | 종합망관리시스템에서의 장애상관관계를 이용한 트래픽제어 방법 |
| US7395325B2 (en) | 2002-03-22 | 2008-07-01 | Brother Kogyo Kabushiki Kaisha | Network management system, apparatus to be managed, management apparatus and program |
| KR100487125B1 (ko) * | 2002-11-28 | 2005-05-03 | 삼성전자주식회사 | 운용자 정보를 통합관리하기 위한 네트워크 시스템 및 그방법 |
| JP2008504765A (ja) * | 2004-06-30 | 2008-02-14 | シーメンス アクチエンゲゼルシヤフト | Ｐｏｎの光出力レベルを取得する方法および装置 |
| JP2009232180A (ja) * | 2008-03-24 | 2009-10-08 | Seiko Epson Corp | 通信システム、処理要求装置、処理応答装置及びそのプログラム |
| US10439863B2 (en) | 2015-05-29 | 2019-10-08 | Canon Kabushiki Kaisha | Information processing apparatus, information processing method, and computer-readable medium |
| US11240094B2 (en) | 2015-05-29 | 2022-02-01 | Canon Kabushiki Kaisha | Information processing apparatus, information processing method, and computer-readable medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3812236B2 (ja) | イベント制御手段を備えたネットワーク管理システム | |
| JP4509916B2 (ja) | Ｓｎｍｐ基盤のネットワーク管理装置および方法 | |
| US7016957B2 (en) | Distributed data processing system and error analysis information saving method appropriate therefor | |
| US7716355B2 (en) | Method and apparatus for processing simple network management protocol (SNMP) requests for bulk information | |
| US20040117452A1 (en) | XML-based network management system and method for configuration management of heterogeneous network devices | |
| US20080086561A1 (en) | Method for obtaining log information from network element device by network management server, a network element device and a network management server | |
| US7307962B2 (en) | System for inference of presence of network infrastructure devices | |
| US20020165934A1 (en) | Displaying a subset of network nodes based on discovered attributes | |
| US6654799B1 (en) | Network management system uses managed object instances which are hierarchically organized in inclusion relation for recursively creating processing object and recuresively returning information | |
| CN106959820A (zh) | 一种数据提取方法和系统 | |
| JPH08292922A (ja) | ネットワーク管理装置 | |
| WO1999034557A1 (en) | Method and system for software version management in a network management system | |
| CN110471897A (zh) | 文件管理方法及装置 | |
| CN113626139B (zh) | 一种高可用的虚拟机存储方法及装置 | |
| US20030101252A1 (en) | System and method for supporting SNMP managed networks | |
| JP3890154B2 (ja) | 多階層管理システム | |
| CN108718285A (zh) | 云计算集群的流量控制方法、装置及服务器 | |
| JP2001265614A (ja) | 動的連携情報引継ぎ方法，連携処理システムおよびそのプログラム記録媒体 | |
| JPH11288408A (ja) | 分散処理システムおよび障害解析情報の保存方法 | |
| TWI758179B (zh) | 依據回應時間選擇網域名稱系統服務之客戶端連線方法 | |
| KR100237395B1 (ko) | 폴트의 수집 및 관리방법 | |
| CN111464520B (zh) | 一种数据处理方法、装置、存储介质及电子设备 | |
| CN116483543A (zh) | 一种任务处理方法、装置、设备及存储介质 | |
| JP2001209625A (ja) | 並列計算機システムにおけるネットワークインタフェース選択方法及び装置 | |
| CN112905348A (zh) | 一种智能云计算管理系统 |