JPH06152681A - Ｃｍｉｐ−ｓｎｍｐゲートウェイ - Google Patents

Abstract

(57)【要約】 【構成】ＯＳＩ管理のマネージャ・システムとインター
ネット管理のエージェント・システム間にＯＳＩ管理の
通信プロトコルであるＣＭＩＰとインターネット管理の
通信プロトコルであるＳＮＭＰのプロトコル変換をおこ
なうＣＭＩＰ−ＳＮＭＰゲートウェイを設ける。ゲート
ウェイは、ＣＭＩＰのＰＤＵ（プロトコル・データ単
位）送受信部と、ＳＮＭＰのＰＤＵの送受信部と、両者
のＰＤＵをそれぞれ他方のＰＤＵに変換する変換部から
なり、この変換部では、ＰＤＵのフォーマット変換だけ
でなく、両方のＰＤＵで運ばれる管理情報の変換もおこ
なう。 【効果】インターネットをＯＳＩ管理によって管理可能
となる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、インターネットのネッ
トワーク管理プロトコルの規格であるSNMPの、ＯＳＩの
ネットワーク管理プロトコルの規格であるＣＭＩＰへの
変換に関する。

【０００２】

【従来の技術】従来は、ＯＳＩの規格に基づいた通信ネ
ットワーク（以下、ＯＳＩネットワークと呼ぶ）と、イ
ンターネットの規格に基づいた通信ネットワーク（以
下、単にインターネットと呼ぶ）は独立していると考え
られていた。

【０００３】このため、ＯＳＩネットワークは、ＯＳＩ
のネットワーク管理の規格であるＯＳＩ管理の規格に基
づいたマネージャ・システム（以下、ＯＳＩマネージャ
と呼ぶ）とエージェント・システム（以下、ＯＳＩエー
ジェントと呼ぶ）によって、インターネットは、インタ
ーネットのネットワーク管理の規格であるインターネッ
ト管理の規格に基づいたマネージャ・システム（以下、
ＳＮＭＰマネージャと呼ぶ）とエージェント・システム
（以下、ＳＮＭＰエージェントと呼ぶ）によって、別々
に管理されていた。

【０００４】したがって、ＯＳＩ管理とインターネット
管理は、独立に規格が定められていた。すなわち、ＯＳ
ＩマネージャとＯＳＩエージェント間の通信プロトコル
は、ＣＭＩＰとして、アイ・エス・オー／アイ・イー・
シー ９５９６−１：1991インフォメーション・テクノ
ロジー − オープン・システムズ・インターコネクシ
ョン − コモン・マネージメント・インフォメーショ
ン・プロトコル −パート１：スペシフィケーション(I
SO／IEC 9596−1：1991 Informationtechnology -
Open Systems Interconnection - Common manageme
ntinformation protocol - Part １：Specificatio
n)で規定されている。また、ＳＮＭＰマネージャとＳＮ
ＭＰエージェント間の通信プロトコルは、ＳＮＭＰとし
て、アール・エフ・シー１１５７ ア・シンプル・ネッ
トワーク・マネージメント・プロトコル(エス・エヌ・
エム・ピー)(RFC1157 A Simple NetworkManagement
Protocol (SNMP))で独立に規定されている。

【０００５】また、ＯＳＩ管理で規定される管理情報
は、アイ・エス・オー／アイ・イー・シー１０１６５−
２ インフォメーション・テクノロジー − オープン
・システムズ・インターコネクション − マネージメ
ント・インフォメーション・サービシズ − ストラク
チャ・オブ・マネージメント・インフォメーション −
パート２：デフィニション・オブ・マネージメント・イ
ンフォメーション(ISO／IEC 10165-2 Information t
echnology - Open Systems Interconnection- Man
agement Information Services - Structure of
ManagementInformation - Part ２：Definition of
management information)、および、アイ・エス・オ
ー／アイ・イー・シー・ディー・アイ・エス１０１６５
−５インフォメーション・テクノロジー − オープン
・システムズ・インターコネクション − マネージメ
ント・インフォメーション・サービシズ − ストラク
チャ・オブ・マネージメント・インフォメーション −
パート５：ジェネリック・マネージメント・インフォ
メーション(ISO／IEC DIS 10165-5 Informati
on technology - Open Systems Interconnection
- Management Information Services -
Structure of Management Information -
Part ５：Generic management information）で規
定されている。

【０００６】インターネット管理で規定される管理情報
は、アール・エフ・シー１２１３マネージメント・イン
フォメーション・ベース・フォー・ネットワーク・マネ
ージメント・オブ・ティー・シー・ピー／アイ・ピー・
ベースド・インターネッツ：エム・アイ・ビー・ツー(R
FC1213 Management Information Base forNetwork
Management of TCP／IP-based internets：MIB-I
I)等で定義されている。

【０００７】ＯＳＩ管理における管理情報構造について
は、アイ・エス・オー／アイ・イー・シー１０１６５−
４ インフォメーション・テクノロジー − オープン
・システムズ・インターコネクション − マネージメ
ント・インフォメーション・サービシズ − ストラク
チャ・オブ・マネージメント・インフォメーション−
パート４：ガイドラインズ・フォー・ザ・デフィニショ
ン・オブ・マネッジド・オブジェクツ(ISO／IEC 10165
-4 Information technology - OpenSystems Inter
connection - Management Information Services
- Structure of Management Information - Part
４：Guidlines for theDefinition of Managed
objects)で規定されている。

【０００８】インターネット管理における管理情報構造
については、アール・エフ・シー１１５５ ストラクチ
ャ・アンド・アイデンティフィケーション・オブ・マネ
ージメント・インフォメーション・フォー・ティー・シ
ー・ピー／アイ・ピー・ベースド・インターネッツ(RFC
1155 Structure and Identification ofManagement
Information for TCP／IP-based Internets），ア
ール・エフ・シー１２１２ コンサイス・エム・アイ・
ビー・デフィニション(RFC1212Concise MIB Definiti
on）、および、アール・エフ・シー１２１５ ア・コン
ベンション・フォー・デファイニング・トラップス・フ
ォー・ユーズ・ウィズ・ザ・エス・エヌ・エム・ピー(R
FC1215 A Convention for Defining Trapsfor us
e with the SNMP)で規定されている。

【０００９】

【発明が解決しようとする課題】しかし、ＯＳＩネット
ワークとインターネットが相互に接続されると、それぞ
れのネットワークを別々に管理することは効率的に問題
となる。したがって、ＯＳＩネットワークとインターネ
ットをひとつのシステムにより統合して管理することが
求められる。

【００１０】そのためのインターネットの規格のひとつ
がアール・エフ・シー１２１４ オー・エス・アイ・イ
ンターネット・マネージメント：マネージメント・イン
フォメーション・ベース(RFC1214 OSI Internet Man
agement：Management Information Base)であ
る。この規格は、インターネット管理で使用される管理
情報構造を、ＯＳＩ管理で使用される管理情報構造に変
換することにより、インターネット管理のための管理情
報の規格のひとつであるＲＦＣ１２１３で規定された管
理情報を、ＯＳＩ管理で使用できる管理情報に変換する
ための規格である。

【００１１】本発明で解決しようとする課題のひとつ
は、ＲＦＣ１２１４の規格を実現する手段を与えること
である。

【００１２】本発明で解決しようとするもう一つの課題
は、インターネット管理で規定された管理情報を、ＯＳ
Ｉ管理で規定される管理情報、すなわちＩＳＯ／IEC101
65−２およびＩＳＯ／ＩＥＣ ＤＩＳ１０１６５−５で
規定される管理情報に変換する手段を与えることであ
る。

【００１３】

【課題を解決するための手段】ＯＳＩネットワークとイ
ンターネットを統合して管理する仕組みのひとつとし
て、ＯＳＩマネージャにより、ＳＮＭＰエージェントを
管理する方法が考えられる。すなわち、図１に示すよう
に、ＯＳＩマネージャ２とＳＮＭＰエージェント３の間
にＣＭＩＰ−ＳＮＭＰゲートウェイ１を設けるというも
のである。

【００１４】前記ＯＳＩマネージャ２と前記ＣＭＩＰ−
ＳＮＭＰゲートウェイ１間の通信プロトコルは、ＣＭＩ
Ｐであり、前記ＳＮＭＰエージェント３と前記ＣＭＩＰ
−ＳＮＭＰゲートウェイ１間の通信プロトコルは、ＳＮ
ＭＰである。

【００１５】前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１
は、インターネット管理で規定された管理情報を、ＯＳ
Ｉ管理で規定された管理情報に変換する処理をおこな
う。あるいは、インターネット管理で規定された管理情
報構造を、ＯＳＩ管理で規定された管理情報構造に変換
することにより、インターネット管理で規定された管理
情報を、ＯＳＩ管理で使用できる管理情報に変換する処
理をおこなう。

【００１６】したがって、前記ＯＳＩマネージャ２と前
記ＣＭＩＰ−ＳＮＭＰゲートウェイ１間では、ＯＳＩ管
理で規定された管理情報、またはＯＳＩ管理で規定され
た管理情報構造に基づいた管理情報が交換される。ま
た、前記ＳＮＭＰエージェント３と前記ＣＭＩＰ−ＳＮ
ＭＰゲートウェイ１間では、インターネット管理で規定
された管理情報が交換される。

【００１７】

【作用】当該ＣＭＩＰ−ＳＮＭＰゲートウェイは、ＯＳ
Ｉ管理の規格をインターネット管理の規格に変換するた
めに、プロトコルの変換と管理情報の変換のふたつの変
換処理をおこなう。

【００１８】当該ＣＭＩＰ−ＳＮＭＰゲートウェイで
は、プロトコルの変換は、ＣＭＩＰプロトコル・データ
単位(以下、ＣＭＩＰ ＰＤＵと記す)を、ＳＮＭＰプロ
トコル・データ単位(以下、ＳＮＭＰ ＰＤＵと記す)に
対応させることでおこなう。

【００１９】ＳＮＭＰ ＰＤＵのほとんどの構成要素は
ＣＭＩＰ ＰＤＵから導きだすことができるが、コミュ
ニティ名は導きだすことができないので、前記コミュニ
ティ名はコミュニティ名を取得する手段により取得す
る。本発明の実施例では、ＩＰアドレス取得テーブルか
らコミュニティ名を取得することでこれを実現してい
る。

【００２０】当該ＣＭＩＰ−ＳＮＭＰゲートウェイは、
ＳＮＭＰ ＰＤＵの送出先であるＳＮＭＰエージェント
のＩＰアドレスを、ＣＭＩＰ ＰＤＵ中の識別名をＩＰ
アドレスに対応させる手段を用いて導きだす。本発明の
実施例ではこれを、ＩＰアドレス取得テーブルで実現し
ている。

【００２１】当該ＣＭＩＰ−ＳＮＭＰゲートウェイは、
ＣＭＩＰ ＰＤＵとＳＮＭＰ PDUを対応させることに
より、双方のプロトコル・シーケンスを制御する。ＯＳ
Ｉマネージャと前記ＣＭＩＰ−ＳＮＭＰゲートウェイ間
で、カーネル機能単位のみを使用する場合が実施例１で
記述される。前記ＯＳＩマネージャと前記ＣＭＩＰ−Ｓ
ＮＭＰゲートウェイ間で、前記カーネル機能単位に加え
て、複数オブジェクト選択機能単位，スコープ機能単
位，フィルタ機能単位を使用する場合は、当該ＣＭＩＰ
−ＳＮＭＰゲートウェイは複数オブジェクト選択機構を
保持し、実施例２で記述される処理をおこなう。すなわ
ち、get-next-requestサービスを使用して、管理オブジ
ェクト(インターネット・オブジェクト)の部分木の検索
をおこなう。

【００２２】また、前記ＣＭＩＰ−ＳＮＭＰゲートウェ
イは、通信に関して以下の処理もおこなう。

【００２３】当該ＣＭＩＰ−ＳＮＭＰゲートウェイは、
前記ＯＳＩマネージャと当該CMIP−ＳＮＭＰゲートウェ
イ間のアソシエーションの管理を、アソシエーション確
立に関する識別情報を保持することによっておこなう。
本発明の実施例ではこれを、アソシエーション・フラグ
を制御することにより実現している。

【００２４】ＣＭＩＰは、リモート・オペレーション・
サービスの仕様により、多重化が可能である。すなわ
ち、前記ＯＳＩマネージャと前記ＣＭＩＰ−ＳＮＭＰゲ
ートウェイ間では一度に複数のＣＭＩＰ ＰＤＵを交換
することができる。また当該ＣＭＩＰ−ＳＮＭＰゲート
ウェイとＳＮＭＰエージェント間はデータグラムで通信
をおこなっているので、ＳＮＭＰ ＰＤＵの多重化が可
能である。したがって、当該ＣＭＩＰ−ＳＮＭＰゲート
ウェイはＳＮＭＰ ＰＤＵ発行多重化機構を持つことに
より、ＳＮＭＰ ＰＤＵ発行の多重化をおこなう。本発
明の実施例では、スケジューリング情報テーブルを用い
たプロトコル処理により、当該ＳＮＭＰＰＤＵ発行多重
化機構を実現している。

【００２５】次に管理情報の変換処理について説明す
る。

【００２６】ＯＳＩ管理もインターネット管理も管理情
報に関する規定は、どちらも２段階の定義になってい
る。すなわち、管理情報の構造についての規定と、管理
情報についての規定から構成されている。そのため、管
理情報の変換処理についてはふたつの方式が考えられ
る。ひとつは管理情報の構造を一方からもう一方へ変換
する方式であり、もうひとつは管理情報を一方からもう
一方へ対応させる方式である。

【００２７】ＲＦＣ１２１４は前者の考えに基づいてい
ることを指摘しておく。実施例１と実施例２では、前者
の考えに基づいた当該ＣＭＩＰ−ＳＮＭＰゲートウェイ
の管理情報の変換処理を実現しており、実施例３では後
者の考えに基づいた当該CMIP−ＳＮＭＰゲートウェイの
管理情報の変換処理を実現している。

【００２８】特に、ＲＦＣ１２１４に基づいた管理情報
の変換処理では、当該ＣＭＩＰ−ＳＮＭＰゲートウェイ
は名称の構造変換をおこなう。実施例１にその処理につ
いて記述している。

【００２９】

【実施例】

〈実施例１〉第１の実施例は、ＣＭＩＰ−ＳＮＭＰゲー
トウェイ１はＣＭＩＰのカーネル機能単位のみを実装
し、ＯＳＩオブジェクトとインターネット・オブジェク
トの変換規則はＲＦＣ１２１４にしたがうというもので
ある。

【００３０】本実施例によるＣＭＩＰ−ＳＮＭＰゲート
ウェイ１の構成を図２を用いて説明する。

【００３１】ＣＭＩＰ−ＳＮＭＰゲートウェイ１は、Ｏ
ＳＩマネージャ２と管理情報を交換するために、ＯＳＩ
通信インタフェース２２を持つ。また、ＳＮＭＰエージ
ェント３と管理情報を交換するために、ＴＣＰ/ＩＰイ
ンタフェース２３を持つ。

【００３２】A-ASSOCIATE処理１２，A-RELEASE処理１
３，A-ABORT処理１４，m-Get処理１５，m-Set処理１
６，m-Event-Reporrt処理１７は、ＣＭＩＰプロトコル
・データのＣＭＩＰ−ＳＮＭＰゲートウェイ１で使用す
る内部表現への変換、および前記内部表現のＣＭＩＰプ
ロトコル・データへの変換をおこなう。

【００３３】get-request処理１８，get-response処理
１９，set-request処理２０，trap処理２１は、ＳＮＭ
Ｐプロトコル・データの内部表現への変換、および前記
内部表現のＳＮＭＰプロトコル・データへの変換をおこ
なう。

【００３４】ＣＭＩＰからＳＮＭＰへのプロトコル変
換，ＳＮＭＰからＣＭＩＰへのプロトコル変換，ＯＳＩ
オブジェクトからＳＮＭＰオブジェクトへの変換、およ
びSNMPオブジェクトからＯＳＩオブジェクトへの変換
は、スケジューラ／プロトコル変換処理１１がおこな
う。

【００３５】ＣＭＩＰのサービスとＳＮＭＰのサービス
の対応を表１に記述する。表１に示すように、ＣＭＩＰ
のA-ASSOCIATE，A-RELEASE，A-ABORT のサービスに対応
するＳＮＭＰのサービスはない。また、ＳＮＭＰのget-
next-requestサービスに対応するＣＭＩＰのサービスは
ない。

【００３６】

【表１】

【００３７】さらにＳＮＭＰエラーのＣＭＩＰエラーへ
の対応の例を表２と表７に示す。

【００３８】

【表２】

【００３９】

【表３】

【００４０】表２はm-Getのエラーの場合の対応例，表
３はm-Setの場合の対応例である。本実施例では、ＳＮ
ＭＰのnoSuchNameエラーにはＣＭＩＰのgetListErrorを
対応させる。ＳＮＭＰのtooBigエラーとgenErrorエラー
にはprocessingFailure エラーを対応させる。それぞれ
のエラーに対してパラメータ・テンプレートを定義す
る。すなわち、ＳＮＭＰのtooBigエラーに対しては、sn
mpTooBigパラメータ・テンプレート(図５)で定義される
ものがＣＭＩＰのprocessingFailureエラーのSpecific
error informationパラメータにマッピングされる。
また、ＳＮＭＰのgenErrorに対しては、snmpGenErrorパ
ラメータ・テンプレート(図６)で定義されるものがＣＭ
ＩＰのprocessingFailureエラーのSpecific errorinfo
rmationパラメータにマッピングされる。

【００４１】ＣＭＩＰ−ＳＮＭＰゲートウェイ１の動作
を次に説明する。

【００４２】図７に示すように、アソシエーション確立
中のときにのみ、ＯＳＩマネージャ２とＣＭＩＰ−ＳＮ
ＭＰゲートウェイ１との間の通信がおこなわれる。すな
わち、図７で示されているように、アソシエーションが
切断されている間に、SNMPエージェントがトラップをＣ
ＭＩＰ−ＳＮＭＰゲートウェイ１に通知したとしても、
当該トラップより生成されるm-Event-Report request
／indication PDUは破棄される。

【００４３】表１で示されたＣＭＩＰとＳＮＭＰの対応
にしたがって、図８に示すようにＣＭＩＰ−ＳＮＭＰの
変換をおこなう。

【００４４】すなわち、ＣＭＩＰ−ＳＮＭＰゲートウェ
イ１がm-Get request／indicationPDU を受信すると、
当該ＣＭＩＰ−ＳＮＭＰゲートウェイ１は、ＳＮＭＰエ
ージェント３にget-request PDUを発行する。前記get-
request PDUに対する応答として、当該ＳＮＭＰエージ
ェント３はget-response PDUを発行する。前記get-res
ponse PDUを当該ＣＭＩＰ−ＳＮＭＰゲートウェイ１を
受信すると、m-Getresponse／confirm PDUを発行す
る。

【００４５】また、ＣＭＩＰ−ＳＮＭＰゲートウェイ１
がm-Set request／indicationPDU を受信すると、当該
ＣＭＩＰ−ＳＮＭＰゲートウェイ１は、ＳＮＭＰエージ
ェント３にset-request PDUを発行する。前記set-requ
est PDUに対する応答として、当該ＳＮＭＰエージェン
ト３はget-response PDUを発行する。前記get-respons
e PDUを当該ＣＭＩＰ−ＳＮＭＰゲートウェイ１を受信
すると、m-Setresponse／confirm PDUを発行する。

【００４６】最後に、ＳＮＭＰエージェント３がtrap
PDUを発行し、当該trap PDUをCMIP−ＳＮＭＰゲートウ
ェイ１を受信すると、当該ＣＭＩＰ−ＳＮＭＰゲートウ
ェイ１はＯＳＩマネージャ２に対してm-Event-Report
request／indication PDUを発行する。

【００４７】次に、ＣＭＩＰからＳＮＭＰへのプロトコ
ル変換、およびＳＮＭＰからCMIPへのプロトコル変換に
ついて説明する。

【００４８】前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１中
のスケジューラ／プロトコル変換処理１１において、Ｃ
ＭＩＰからＳＮＭＰへのプロトコル変換、およびＳＮＭ
ＰからＣＭＩＰへのプロトコル変換をおこなう。

【００４９】スケジューラ／プロトコル変換処理１１の
構成を図３に示す。

【００５０】プロトコル変換ドライバ１１９は、ＯＳＩ
通信インタフェースとＴＣＰ／ＩＰ通信インタフェース
を介してそれぞれＣＭＩＰプロトコル・データとＳＮＭ
Ｐプロトコル・データの送受信、およびスケジューラ／
プロトコル変換処理１１全体の制御をおこなう。

【００５１】アソシエーション・フラグ１１０は、ＯＳ
Ｉマネージャとのアソシエーションの確立状態を表現す
る。すなわち、当該アソシエーション・フラグ１１０が
オンのときは前記アソシエーションが確立されているこ
とをあらわし、当該アソシエーション・フラグ１１０が
オフであるときは、前記アソシエーションは確立されて
いないことをあらわす。

【００５２】ＯＳＩマネージャよりA-ASSOCIATE reque
st／indication PDU を受け取ったときにアソシエーシ
ョン・フラグ１１０はオンとなり、当該ＣＭＩＰ−ＳＮ
ＭＰゲートウェイ１はA-ASSOCIATE response／confirm
PDUを発信する(図１０) 。また、ＯＳＩマネージャよ
りA-RELEASE request／indication PDU，A-ABORTrequ
est／indication PDU、またはA-P-ABORT request／in
dication PDU を受信したときにアソシエーション・フ
ラグ１１０はオフとなる (それぞれ、図１１，図１２，
図１３）。特に、ＯＳＩマネージャよりA-RELEASE req
uest／indication PDU を受信した場合には、当該ＣＭ
ＩＰ−ＳＮＭＰゲートウェイ１はA-RELEASE response
／cofirm PDUを発信する。

【００５３】本実施例では、A-ABORTオペレーションとA
-P-ABORTオペレーションのどちらも前記A-ABORT処理１
４で取り扱われる。

【００５４】ＩＰアドレス取得テーブル１１３は、当該
ＣＭＩＰ−ＳＮＭＰゲートウェイ１が受信したm-Get r
equest／indication PDUやm-Set request／indicatio
n PDU で指定されたオブジェクトを保持しているＳＮ
ＭＰエージェントのＩＰアドレスを取得するために使用
する。

【００５５】当該ＩＰアドレス取得テーブル１１３の構
成を図１４に示す。当該ＩＰアドレス取得テーブル１１
３は、先頭オブジェクト名，ＩＰアドレス，コミュニテ
ィ名の各フィールドから成り立つ。これらのフィールド
の使用方法は後述する。

【００５６】スケジューリング情報テーブル１１８の構
成を図１５に記述する。本実施例では、当該スケジュー
リング情報テーブルをＯＳＩマネージャの発行した要求
に対する応答を作成するために使用する。そのため、当
該スケジューリング情報は、ＩＰアドレス，インボーク
ＩＤ，リクエストＩＤ，クラス，インスタンス，アトリ
ビュートＩＤリストのフィールドを持つ。これらのフィ
ールドの使用方法は後述する。

【００５７】また、本実施例では当該スケジューリング
情報テーブルを用いてＳＮＭＰエージェントへのＳＮＭ
Ｐプロトコル・データ発行のスケジューリングをおこな
う。すなわち、当該スケジューリング情報テーブルに処
理フラグ・フィールドを持たせ、前記処理フラグ・フィ
ールドの値がオンである場合には、当該処理フラグ・フ
ィールドがオフとなるまでＳＮＭＰプロトコル・データ
を発信しない。このようにすることにより、本実施例で
は、ＳＮＭＰエージェント単位での並列処理を可能とし
ている。前記スケジューリング情報テーブルの構造を、
リクエストＩＤ，クラス，インスタンス，アトリビュー
トＩＤリストのフィールドの組を複数個持つ構造とする
ことにより、オブジェクト単位での並列処理が可能とな
る。

【００５８】本実施例におけるm-Get request／indica
tionサービス，m-Get response／confirm サービスの
各パラメータの使用／未使用の区別を表４〜表７に記述
する。

【００５９】

【表４】

【００６０】

【表５】

【００６１】

【表６】

【００６２】

【表７】

【００６３】表４はm-Get request／indicationサービ
スについて、表５は正常応答するときのm-Get respons
e／confirm サービスについて、表６はProcessing fai
lureエラー発生時のm-Get response／confirmサービス
について、表７はGet listerror エラー発生時のm-Get
response／confirmサービスについて記述している。

【００６４】本実施例では、ＣＭＩＰ−ＳＮＭＰゲート
ウェイ１はカーネル機能単位のみを実装するので、Scop
e パラメータ，Filterパラメータ，Access controlパ
ラメータ，Synchronizationパラメータ，Linked ident
ifier パラメータは使用しない。また、Current time
パラメータは、対応する情報がＳＮＭＰプロトコル・デ
ータからは取得できないので使用しない。

【００６５】同様にして、本実施例におけるm-Set req
uest／indicationサービス，m-Setresponse／confirm
サービスの各パラメータの使用／未使用の区別を表８〜
表１１に記述する。

【００６６】

【表８】

【００６７】

【表９】

【００６８】

【表１０】

【００６９】

【表１１】

【００７０】次に、ＣＭＩＰのm-Get request／indica
tion PDUをＳＮＭＰのget-requestPDUに変換する処理に
ついて、図１６を用いて説明する。

【００７１】前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１
が、ＯＳＩマネージャよりm-Get request／indication
PDUを受信する(ステップ２０００)と、ステップ２０
０１によりＩＰアドレスを取得する。

【００７２】ＩＰアドレスの取得方法は、図１７のアル
ゴリズムで示されるように、ＩＰアドレス取得テーブル
１１３を用いて取得する。このアルゴリズムで示される
ように、受信ＰＤＵのBase managed object instanc
e パラメータの先頭の要素であるオブジェクトの名前
(先頭オブジェクト名)から、ＩＰアドレスが取得できる
理由を以下に説明する。

【００７３】ＲＦＣ１２１４の規定によるとインターネ
ット・オブジェクトの包含関係は図１８に示された構造
となる。このため、先頭オブジェクト名は必ずsystemの
名前(アトリビュートsysNameの値) となる。ＲＦＣ１２
１４によるとこれはＩＰアドレスと１対１に対応する。
したがって、先頭オブジェクト名からＩＰアドレスは取
得できる。

【００７４】本実施例では、ＳＮＭＰエージェントのＩ
Ｐアドレスを取得するために前記ＩＰアドレス取得テー
ブルを使用したが、ドメイン・ネーム・システム(ＤＮ
Ｓ)を利用して、前記ＳＮＭＰエージェントのＩＰアド
レスを取得する方法もある。

【００７５】また、ステップ２００１でＩＰアドレスを
取得すると同時にコミュニティ名も取得する(ステップ
２００２）。

【００７６】ステップ２００３では、ＣＭＩＰのm-Get
request／indicationサービスのAttribute identifi
er list パラメータに設定された値を、ＳＮＭＰのget
-requestサービスのvariable-bindingsパラメータに設
定する値に変換する処理をおこなう。その詳細なアルゴ
リズムを図２７から図３７に記述する。

【００７７】Attribute identifier listパラメータ
からvariable-bindingsパラメータへの変換の概略は、
前記Attribute identifier list パラメータ中のア
トリビュートのオブジェクト識別子を、variable-bindi
ngs パラメータのObjectNameサブパラメータへ設定す
る。

【００７８】ただし、ＲＦＣ１２１４で定義されたアト
リビュートの中には、ＳＮＭＰエージェントが保持しな
いアトリビュートもある。このようなアトリビュートと
してはifTableId，atTableId，atEntryId 等がある。こ
れらは、当該アトリビュートのオブジェクト識別子とし
て｛１．３．６．１．２．１．９．６｝をプレフィクス
として持つものである。前記アトリビュートは、ヌルの
アトリビュート値を持つものと、他のアトリビュートの
値から計算することができるものの２種類に大別するこ
とができる。前者の例としては、ifTableId，atTableId
等があげられる。後者の例としては、atEntryId，ipNet
ToMediaEntryId等があげられる。したがって、Attribut
e identifier listからvariable-bindingsに変換する
処理において、前者のアトリビュートのオブジェクト識
別子をvariable-bindings に追加しない。後者のアトリ
ビュートについては、当該アトリビュートの値を計算す
るために必要な値を持っているアトリビュートのオブジ
ェクト識別子をvariable-bindingsに追加する。例え
ば、atEntryIdの場合はatIfIndexとatNetAddressのオブ
ジェクト識別子をvariable-bindings に追加する（ステ
ップ２１０１〜ステップ２１３３）。

【００７９】オブジェクト識別子をvariable-bindings
に追加する場合に、当該オブジェクト識別子が既に登録
されていれば追加しないことにより、variable-binding
s へのオブジェクト識別子の２重登録を避けることもで
きる。

【００８０】またアトリビュートの中には、オブジェク
ト識別子ではなく、オブジェクト識別子にインデックス
を連結したものをvariable-bindings に設定しなければ
ならないものもある。このようなアトリビュートとして
は、ifIndexやifDescr等がある。インデックスとはエン
トリ(atEntryやipNetToMediaEntry等のオブジェクト)を
区別するために使用するものである。具体的には、atEn
try オブジェクトではatEntryIdアトリビュートの値で
あるし、ipNetToMediaEntryオブジェクトではipNeToMed
iaEntryIdアトリビュートのアトリビュート値となる。
これらのアトリビュートの値はm-Get request／indica
tionサービスのBase object instanceパラメータの構
成要素のひとつの値として得ることができるので、それ
を利用する(ステップ２１３４〜ステップ２１４３）。

【００８１】また、スケジューリング情報テーブル１１
８に、前記Attribute identifierlistパラメータに設
定されたアトリビュートのオブジェクト識別子の一覧を
登録する(ステップ２１４４)。

【００８２】さらに、前記スケジューリング情報テーブ
ル１１８には、m-Get request／indicationサービスの
Base object class パラメータとBase object inst
anceパラメータに設定された値を登録する (ステップ２
１４５, ステップ２１４６）。

【００８３】以上のようにして、ＳＮＭＰのget-reques
t PDUを作成し、適切なＩＰアドレスを持つＳＮＭＰエ
ージェントに対して当該get-request PDU を発信する
(ステップ２００４，ステップ２００５）。

【００８４】次に、ＣＭＩＰのm-Set request／indica
tion PDUをＳＮＭＰのset-requestPDUに変換する処理
について図１９に示す。m-Set request／indication
PDUをＳＮＭＰのset-request PDUに変換する処理は、
前記したm-Get request／indication PDUをＳＮＭＰ
のget-request PDU に変換する処理と、本質的に同じ
である。異なる点は、Attribute identifier listパ
ラメータをvariable-bindingsパラメータに変換するか
わりに、m-Set request／indication PDU をset-requ
est PDUに変換する場合は、Modification-listパラメ
ータをvariable-bindingsパラメータに変換することで
ある。しかも、Attribute identifier listパラメー
タをvariable-bindings パラメータに変換する場合に
は、アトリビュートのオブジェクト識別子を変換するだ
けであったが、Modification listパラメータをvariab
le-bindings パラメータに変換する場合、アトリビュー
トのオブジェクト識別子に加えて、アトリビュートの値
もいっしょに変換してvariable-bindings パラメータを
構成することが唯一の違いである。したがって、Modifi
cation list パラメータをvariable-bindingsパラメー
タに変換する処理の詳細は省略する。

【００８５】次にＳＮＭＰよりget-response PDU を受
信した場合の処理について説明する。ＳＮＭＰのプロト
コル仕様より、get-request PDuとset-request PDUの
応答には、どちらもget-response PDU が返ってくる。
したがって、図２０に示すように、get-response PDU
を受信した場合、get-request PDUに対応する応答か、
set-request PDUに対応する応答かをスケジューリング
情報テーブルの処理フラグ・フィールドの値を見て判断
をおこなう。すなわち、処理フラグ・フィールドの値が
m-Get を指示するものである場合(図１５に示す例では
‘Ｇ’のとき)、get-request PDUに対応する処理であ
ると判断し、当該処理フラグ・フィールドの値がm-Set
を指示するものである場合(図１５に示す例では‘Ｓ’
のとき)、set-request PDU に対応する処理であると判
断する。

【００８６】m-Getへの応答処理について次に説明す
る。図２１に示すように、m-Getresponse／confirm PD
Uを作成する前にアソシエーション・フラグをチェック
する。当該アソシエーション・フラグがオフであれば、
受信したget-responseを無視する。なぜならば、当該ア
ソシエーション・フラグがオフである場合は、OSIマネ
ージャとのアソシエーションが断となっているためであ
る。当該アソシエーション・フラグがオンの場合は、受
信したget-response PDU をもとにして、m-Get respo
nse／confirm PDU を作成し、ＯＳＩマネージャに対し
て当該ＰＤＵを応答する。

【００８７】次に図２２を用いてm-Get response／con
firm PDU を作成する処理について説明する。スケジュ
ーラ／プロトコル変換処理は、スケジューリング情報テ
ーブルより、前記m-Get response／confirm PDU に与
えるインボークＩＤの値を得る(ステップ４２００)。ま
た、受信したget-response PDU のerror-statusパラメ
ータの値をチェックする(ステップ４２０１)。

【００８８】前記error-statusパラメータの値は、ＳＮ
ＭＰプロトコルの仕様より、noError，tooBig，noSuchN
ame，genErrorのいずれかである。

【００８９】前記error-statusパラメータの値がtooBig
である場合には、表６に示したサービス・パラメータに
対して、図２３に示されるように、各パラメータの値を
定める。すなわち、Error identifierサブパラメータ
にはオブジェクト識別子｛my_snmp_error １｝を設定
する。スケジューリング情報テーブルのクラス・フィー
ルドとインスタンス・フィールドに設定された値を、そ
れぞれManaged object classパラメータとManaged o
bject instanceパラメータに設定する。

【００９０】前記error-statusパラメータの値がnoSuch
Nameである場合には、表７に示したサービス・パラメー
タに対して、図２４，図２５に示されるように、各パラ
メータの値を定める。すなわち、tooBigの場合と同じよ
うに、スケジューリング情報テーブルを用いて、Manage
d object classパラメータとManaged object ins
tanceパラメータに値を設定する。また、スケジューリ
ング情報テーブルのアトリビュートＩＤリスト・フィー
ルドに設定されたアトリビュートＩＤの一覧を用いてGe
t info listパラメータの値を設定する。ただし、受
信したget- responseのerror-index で指定されるア
トリビュートには、アトリビュート値の取得に失敗した
理由をあらわすerrorStatusサブパラメータにはnoSuchA
ttributeを、それ以外のアトリビュートの場合には、ac
cessDeniedを設定する。

【００９１】前記error-statusパラメータの値がgenErr
orの場合の処理を図２６に示す。

【００９２】Error identifierサブパラメータにはオ
ブジェクト識別子｛my_snmp_error２}を設定することを
除き、tooBigの場合と同じ処理なので説明は省略する。

【００９３】前記error-statusパラメータの値がnoErro
r の場合の処理を図３８から図４３に示す。

【００９４】スケジューリング情報テーブルのアトリビ
ュートＩＤリストに登録されたアトリビュートＩＤの一
覧にしたがって、variable-bindings パラメータに設定
されたアトリビュート値を取得し、Attribute list パ
ラメータを形成する。ただし、前記アトリビュートがif
TableIdやatTableId等の場合、前記variable-bindings
パラメータには対応するアトリビュートの値が設定され
ていないので、図中に示された処理にしたがって他のア
トリビュートの値を利用して当該アトリビュートの値を
計算する。

【００９５】また、tooBigの場合と同じように、スケジ
ューリング情報テーブルを用いて、Managed object c
lassパラメータとManaged object instance パラメー
タに値を設定する。

【００９６】次に、m-Setへの応答処理について説明す
る。

【００９７】m-Setへの応答処理も、m-Getへの応答処理
と同様に、アソシエーション・フラグをチェックし、当
該アソシエーション・フラグがオフの場合は、get-resp
onseを無視し、当該アソシエーション・フラグがオンの
場合は、m-Set response／confirm PDUを作成し、Ｏ
ＳＩマネージャに対して当該ＰＤＵを応答する。

【００９８】次に、図４６を用いてm-Set response／c
onfirm PDU を作成する処理を説明する。m-Get respo
nse／confirm PDU を作成する処理と同じく、スケジュ
ーリング情報テーブルよりインボークＩＤを取得する。

【００９９】次に、error-statusパラメータをチェック
し、当該error-statusパラメータの値にしたがって、適
切なm-Set response／confirm PDUを作成する。

【０１００】すなわち、error-statusパラメータの値が
tooBigである場合と、genErrorである場合は、m-Get r
esponse／confirm PDU 作成処理で記述してあるものと
同じ処理をおこなうので省略する。

【０１０１】error-statusパラメータの値がnoSuchName
である場合と、badValueである場合と、readOnlyである
場合も、m-Get response／confirm PDU 作成処理のno
SuchNameの場合と同様である。ただし、m-Get respons
e／confirm PDU 作成処理ではアトリビュートのオブジ
ェクト識別子とエラー理由が、Get info list パラメ
ータに設定されるが、m-Set response／confirm PDU
作成処理では、Set info list パラメータにアトリビ
ュートのオブジェクト識別子，当該アトリビュートの
値，エラー理由が設定される点が異なる点に注意する必
要がある。また、get-requestのerror-indexパラメータ
で指定されたアトリビュートのエラー理由として、erro
r-statusパラメータの値がnoSuchNameの場合はnoSuchAt
tribute, badValueの場合はinvalidAttributeValue，re
adOnlyの場合はinvalidOperation とする点が異なる事
に注意する必要がある。

【０１０２】次にＳＮＭＰエージェントよりtrap PDU
を受信した場合の処理について説明する。

【０１０３】m-Event-Report request／indication サ
ービス・パラメータの使用条件を表１２に示す。

【０１０４】

【表１２】

【０１０５】ＲＦＣ１２１４に規定されているように、
当該m-Event-Reportオペレーションは非確認型でなけれ
ばならないので、Modeパラメータにはnon-Confirmed モ
ードを指定する。Event time パラメータに設定する内
容のものが、受信したtrapPDUには含まれていないの
で、前記Event timeパラメータは使用しない。

【０１０６】図４７にtrap PDUからm-Event-Report r
equest／indication PDU に変換する処理についての概
略を示す。

【０１０７】trap PDU をＣＭＩＰ−ＳＮＭＰゲートウ
ェイが受信すると、前記ＣＭＩＰ−ＳＮＭＰゲートウェ
イは、アソシエーション・フラグがオンかどうかをチェ
ックする。当該アソシエーション・フラグがオフである
場合、ＯＳＩマネージャとのアソシエーションは切断さ
れているので、当該trap PDUを破棄する。当該trapPDU
を破棄するかわりにログに登録するという実現方法も
ある。

【０１０８】前記アソシエーション・フラグがオンであ
る場合について次に説明する。

【０１０９】ＲＦＣ１２１４にしたがうと、受信したtr
ap PDUをm-Event-Report request／indication PDU
に変換する場合、表１３に示すように、trap PDU の種
類にしたがって前記m-Event-Report request／indicat
ion PDUを発行する管理オブジェクトが特定される。

【０１１０】

【表１３】

【０１１１】図４８から図５４にそれぞれのtrap PDU
の種類にしたがった変換処理を示す。これらの変換処理
の概要を以下に説明する。

【０１１２】m-Event-Report request／indicationサ
ービスのManaged object instanceパラメータに設定
する管理オブジェクトのインスタンス名をＩＰアドレス
取得テーブルと受信したtrapから得る。すなわち、syst
emオブジェクトのインスタンス名はＩＰアドレス取得テ
ーブルより得、ifEntryオブジェクトやNeighBorEntryオ
ブジェクトのインスタンス名はvariable-bindingsパラ
メータより得る。RFC1214によると、図１８に示される
ようにインターネット・オブジェクトの包含関係は定義
されるので、この包含関係に基づくようにインスタンス
名が形成される。

【０１１３】Managed object classパラメータ，Invo
ke identifier パラメータ，Modeパラメータ，Event
typeパラメータ，Event information パラメータに
は、図中に示されるように、それぞれ適切な値が設定さ
れる。

【０１１４】本実施例によると、ＣＭＩＰ−ＳＮＭＰゲ
ートウェイの動作および構成が単純になるという効果が
ある。

【０１１５】〈実施例２〉第１の実施例では、ＣＭＩＰ
−ＳＮＭＰゲートウェイは、ＣＭＩＰのカーネル機能単
位のみを実装していた。このため、ＯＳＩマネージャ
は、一回のＣＭＩＰオペレーションで、複数の管理オブ
ジェクトを指定することができなかった。

【０１１６】第２の実施例では、カーネル機能単位のほ
かに、複数オブジェクト選択機能単位，フィルタ機能単
位，複数応答機能単位を前記ＣＭＩＰ−ＳＮＭＰゲート
ウェイが実装することにより、前記ＯＳＩマネージャ
が、一回のＣＭＩＰオペレーションにおいて、複数の管
理オブジェクトを選択することを可能とする。

【０１１７】ＣＭＩＰのm-Get オペレーションにおける
前記ＣＭＩＰ−ＳＮＭＰゲートウェイのプロトコル処理
を、図５５を用いて説明する。

【０１１８】前記ＣＭＩＰ−ＳＮＭＰゲートウェイがm-
Get request／indication PDU をＯＳＩマネージャよ
り受け取ると、当該ＣＭＩＰ−ＳＮＭＰゲートウェイ
は、ＳＮＭＰエージェントに対して、ＳＮＭＰのget-re
quest PDUを発行する。当該get-request PDUに対する
応答として、前記ＳＮＭＰエージェントより、get-resp
onse PDUが返る。

【０１１９】前記ＣＭＩＰ−ＳＮＭＰゲートウェイがge
t-response PDU を受信すると、当該ＣＭＩＰ−ＳＮＭ
Ｐゲートウェイは受信したget-response PDU で指定さ
れる管理オブジェクトが、前記m-Get request／indica
tion PDUのScopeパラメータで指定された範囲の外に位
置付くものであれば、当該ＣＭＩＰ−ＳＮＭＰゲートウ
ェイはm-Get response／confirm PDU を前記ＯＳＩマ
ネージャに返し、当該プロトコル処理を終了する。当該
m-Get response／confirm PDU の内容は空である。

【０１２０】前記ＳＮＭＰエージェントから応答された
前記get-response PDU で指定される管理オブジェクト
が、前記Scope パラメータで指定された範囲中に位置付
けられる場合、前記m-Get request／indication PDU
のFilter パラメータで指定されたフィルタリング条
件を満足していなければ、当該ＣＭＩＰ−ＳＮＭＰゲー
トウェイは当該get-response PDU で指定された管理オ
ブジェクトの次に位置する管理オブジェクトから管理情
報を得るために、前記ＳＮＭＰエージェントに対してge
t-next-request PDUを発行する。

【０１２１】前記ＳＮＭＰエージェントから応答された
前記get-response PDU で指定される管理オブジェクト
が、前記Scope パラメータで指定された範囲中に位置付
けられ、前記Filterパラメータで指定されたフィルタリ
ング条件を満足している場合、当該ＣＭＩＰ−ＳＮＭＰ
ゲートウェイは当該get-response PDU を、ＣＭＩＰの
m-LinkedReply PDUに変換し、当該m-LinkedReply PDU
を前記ＯＳＩマネージャに対して発行する。また、当該
ＣＭＩＰ−ＳＮＭＰゲートウェイは当該get-response
PDU で指定された管理オブジェクトの次に位置する管理
オブジェクトから管理情報を得るために、前記ＳＮＭＰ
エージェントに対してget-next-request PDUを発行す
る。

【０１２２】前記get-next-request PDU に対する応答
にも、前記ＳＮＭＰエージェントはget-response PDU
を返答する。

【０１２３】次にＣＭＩＰのm-Set オペレーションにお
けるＣＭＩＰ−ＳＮＭＰゲートウェイのプロトコル処理
を、図５６を用いて説明する。

【０１２４】前記ＣＭＩＰ−ＳＮＭＰゲートウェイがm-
Set request／indication PDU をＯＳＩマネージャよ
り受け取ると、当該ＣＭＩＰ−ＳＮＭＰゲートウェイ
は、ＳＮＭＰエージェントに対して、ＳＮＭＰのget-re
quest PDUを発行する。当該get-request PDUに対する
応答として、前記ＳＮＭＰエージェントより、get-resp
onse PDUが返る。

【０１２５】前記ＣＭＩＰ−ＳＮＭＰゲートウェイがge
t-response PDU を受信すると、当該ＣＭＩＰ−ＳＮＭ
Ｐゲートウェイは当該get-response PDUが、get-reque
stPDUまたはget-next-request PDUに対する応答である
か、set-request PDUに対する応答であるかを判断す
る。

【０１２６】当該get-response PDUがget-request PD
Uまたはget-next-request PDUに対する応答である場
合、受信したget-response PDU で指定される管理オブ
ジェクトが、前記m-Set request／indication PDUのS
copeパラメータで指定された範囲の外に位置付くもので
あれば、当該ＣＭＩＰ−ＳＮＭＰゲートウェイはm-Setr
esponse／confirm PDUを前記ＯＳＩマネージャに返
し、当該プロトコル処理を終了する。当該m-Set respo
nse／confirm PDU の内容は空である。

【０１２７】前記get-response PDUがget-request PD
Uまたはget-next-request PDUに対する応答であり、当
該get-response PDU で指定される管理オブジェクト
が、前記Scopeパラメータで指定された範囲中に位置付
けられる場合、前記m-Get request／indication PDU
のFilterパラメータで指定されたフィルタリング条件を
満足していなければ、当該ＣＭＩＰ−ＳＮＭＰゲートウ
ェイは当該get-response PDU で指定された管理オブジ
ェクトの次に位置する管理オブジェクトを選択するため
に、前記ＳＮＭＰエージェントに対してget-next-reque
st PDUを発行する。

【０１２８】前記get-response PDUがget-request PD
Uまたはget-next-request PDUに対する応答であり、当
該get-response PDU で指定される管理オブジェクト
が、前記Scopeパラメータで指定された範囲中に位置付
けられ、前記Filter パラメータで指定されたフィルタ
リング条件を満足している場合、当該ＣＭＩＰ−ＳＮＭ
Ｐゲートウェイは当該get-response PDU で指定される
管理オブジェクトに対して、前記m-Set request／indi
cation PDU の内容をset-request PDUに変換し、前記
SNMPエージェントに対して当該set-request PDUを発行
する。当該set-request PDUに対する応答として、前記
ＳＮＭＰエージェントはget-responsePDUを返す。

【０１２９】前記get-response PDUがset-request に
対する応答である場合、前記CMIP−ＳＮＭＰゲートウェ
イは、当該get-response PDUをＣＭＩＰのm-LinkedRep
lyPDUに変換し、当該m-LinkedReply PDU を前記ＯＳＩ
マネージャに対して発行する。また、当該ＣＭＩＰ−Ｓ
ＮＭＰゲートウェイは当該get-response PDU で指定さ
れた管理オブジェクトの次に位置する管理オブジェクト
から管理情報を得るために、前記ＳＮＭＰエージェント
に対してget-next-request PDU を発行する。

【０１３０】前記ＳＮＭＰエージェントが発行したＳＮ
ＭＰのtrap PDUをＣＭＩＰのm- Event-Report reque
st／indication PDUに変換する処理は、第一の実施例
で記述されたものと同じである。

【０１３１】次にＣＭＩＰのＰＤＵをＳＮＭＰのＰＤＵ
に変換する処理、および、ＳＮＭＰのＰＤＵをＣＭＩＰ
のＰＤＵに変換する処理をおこなう前記ＣＭＩＰ−ＳＮ
ＭＰゲートウェイの構造について図４を用いて説明す
る。

【０１３２】前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１
は、ＯＳＩマネージャとＣＭＩＰを用いて通信をおこな
うために、ＯＳＩ通信インタフェース２２を持つ。

【０１３３】また、ＳＮＭＰエージェントとＳＮＭＰを
用いて通信をおこなうために、TCP／ＩＰ通信インタフ
ェース２３を持つ。

【０１３４】前記ＯＳＩ通信インタフェース２２および
前記ＴＣＰ／ＩＰ通信インタフェース２３を介して受信
したＣＭＩＰのＰＤＵとＳＮＭＰのＰＤＵそれぞれを、
当該ＣＭＩＰ−ＳＮＭＰゲートウェイ１が使用する内部
データ構造に変換する処理、および、前記内部データ構
造をＣＭＩＰのＰＤＵまたはＳＮＭＰのＰＤＵに変換す
る処理を、A-Associate処理１２，A-RELEASE処理１３，
A-ABORT処理１４，m-Get処理１５，m-Linked-Reply処理
２４，m-Set処理１６，m-Event-Report処理１７，get-r
equest処理１８，get-next-request処理２５，get-resp
onse 処理１９，set-request処理２０，trap処理２１で
おこなう。

【０１３５】前記処理モジュール１２〜１９，２４，２
５の処理および機能は第１の実施例で記述した内容と同
じである。

【０１３６】スケジューラ／プロトコル変換処理１１
は、前記各モジュール１２〜１９，２４，２５の動作を
制御し、ＣＭＩＰのＰＤＵのＳＮＭＰのＰＤＵへの変換
処理，ＳＮＭＰのＰＤＵのＣＭＩＰのＰＤＵへの変換処
理，ＣＭＩＰとＳＮＭＰのプロトコル変換による双方の
プロトコルの制御、および、ＣＭＩＰで交換される管理
情報とＳＮＭＰで交換される管理情報の変換処理をおこ
なう。

【０１３７】次に前記スケジューラ／プロトコル変換処
理１１の構成について説明する。

【０１３８】アソシエーション・フラグ１１０は、アソ
シエーションの確立状況をあらわす。すなわち、当該ア
ソシエーション・フラグ１１０がオンである場合は、Ｏ
ＳＩマネージャとの間のアソシエーションが確立されて
いることをあらわし、オフである場合はアソシエーショ
ンが確立されていないことをあらわす。

【０１３９】ＩＰアドレス取得テーブル１１３は、第一
の実施例と同じように、管理オブジェクトを保持してい
るＳＮＭＰエージェントのＩＰアドレスとコミュニティ
名を取得するために使用する。

【０１４０】スケジューリング情報テーブル１１８は、
第一の実施例と同じく、各ＩＰアドレスごとのＣＭＩＰ
とＳＮＭＰの双方のプロトコルについての処理のステー
タス，ＣＭＩＰのＰＤＵで指定されるインボークＩＤ，
ＳＮＭＰのＰＤＵで指定するリクエストＩＤ，前記ＣＭ
ＩＰのＰＤＵで指定された基底となる管理オブジェクト
のオブジェクト・クラスとオブジェクト・インスタンス
の識別情報，前記CMIPのＰＤＵで指定されるアトリビュ
ートＩＤの一覧を持つ。さらに、前記ＣＭＩＰのＰＤＵ
で指定されるスコープ範囲と、フィルタ条件も保持す
る。図６７に、第二の実施例における、当該スケジュー
リング情報テーブルの構成を例示する。

【０１４１】当該スケジューリング情報テーブルの実施
例では、処理フラグ・フィールドは、‘Ｇ’によって単
数Get，‘Ｓ’によって単数Ｓｅｔ，‘ｇ’によって複
数Get，‘ｓ１’によって複数Setのフェーズ１，‘ｓ
２’によって複数Setのフェーズ２という状態をあらわ
している。

【０１４２】クラス情報テーブル１２４は、管理オブジ
ェクトの包含関係のプロトタイプおよび各管理オブジェ
クトのクラスで保持するアトリビュートの一覧に関する
情報を保持している。図６８に、当該クラス情報テーブ
ルの構成を例示する。

【０１４３】第一の実施例と同様に、プロトコル変換ド
ライバ１１９は、スケジューリング情報テーブル１１
８，ＩＰアドレス取得テーブル１１３，クラス情報テー
ブルに記録された情報を利用して、各ＰＤＵ変換処理モ
ジュール（１１１，１１２，１１５，１２０，１２１，
１２２，１２３）を起動することにより、ＣＭＩＰのＰ
ＤＵのＳＮＭＰのＰＤＵへのプロトコル変換、および、
ＳＮＭＰのＰＤＵのＣＭＩＰのＰＤＵへのプロトコル変
換をおこなう。

【０１４４】次に、ＣＭＩＰ−ＳＮＭＰゲートウェイが
m-Get request／indication PDUを受信したときの処
理について、図５７を用いて説明する。前記ＣＭＩＰ−
SNMPゲートウェイがm-Get request／indication PDU
を受信すると、当該ＣＭＩＰ−ＳＮＭＰゲートウェイ
は、受信したm-Get request／indication PDUがScope
パラメータを持たないか、あるいは、Scope パラメータ
はベースオブジェクトのみの指定となっているか確かめ
る。この場合、当該ＣＭＩＰ−ＳＮＭＰゲートウェイ
は、第一の実施例で記述したget-request PDUへの変換
処理をおこなう。このとき、スケジューリング情報テー
ブルの処理フラグ・フィールドには、単数Get を意味す
るものが設定される。

【０１４５】受信したm-Get request／indication PD
UがScopeパラメータを持ち、かつ、ベースオブジェクト
のみの指定となっていない場合には、以下の手順によっ
て、get-request PDUを作成する。

【０１４６】まず、ＩＰアドレス取得テーブルより、受
信したm-Get request／indicationPDU によって指定さ
れる管理オブジェクトを所有しているＳＮＭＰエージェ
ントのＩＰアドレスを取得する。

【０１４７】次に、前記m-Get request／indication
PDU中のScopeパラメータ、および、Filterパラメータに
設定されている内容を、それぞれスケジューリング情報
テーブルのスコープ範囲、および、フィルタ条件フィー
ルドに設定する。

【０１４８】次に、前記m-Get request／indication
PDUを変換して、get-request PDUを作成する。この変
換処理は、第一の実施例で記述した方法と同じである。
また、m-Get request／indication PDUのFilter パラ
メータに指定されているアトリビュートＩＤも利用し
て、get-request PDUのvariable-bindings パラメータ
を形成する、すなわち、前記Filterパラメータに指定さ
れたアトリビュートの値もＳＮＭＰエージェントから取
得できるように前記variable-bindings パラメータを形
成する。

【０１４９】最後に、作成されたget-request PDUを前
記ＳＮＭＰエージェントに送信し、スケジューリング情
報テーブルの処理フラグ・フィールドに複数Get を意味
するものを設定する。

【０１５０】次に、ＣＭＩＰ−ＳＮＭＰゲートウェイが
m-Set request／indication PDUを受信したときの処
理について、図５８を用いて説明する。

【０１５１】この処理は、受信したm-Set request／in
dication PDUがScopeパラメータを持たないか、あるい
は、Scope パラメータはベースオブジェクトのみの指定
となっているか確かめ、そうである場合は、第一の実施
例におけるset-request PDUへの変換処理が実施される
こと、そうでない場合には、m-Set request／indicati
on PDUからget-request PDU へ変換されることの２点
を除いて同様である。スケジューリング情報テーブルの
処理フラグ・フィールドには、前者の場合、単数Setを
意味するものが設定され、後者の場合、複数Setフェー
ズ１を意味するものが設定される。

【０１５２】次に、ＣＭＩＰ−ＳＮＭＰゲートウェイが
get-response PDU を受信したときの処理について、図
５９を用いて説明する。前記ＣＭＩＰ−ＳＮＭＰゲート
ウェイはget-response PDU を受信すると、スケジュー
リング情報テーブルの処理フラグ・フィールドの値をチ
ェックする。

【０１５３】前記処理フラグ・フィールドの値が、単数
Get を意味するものである場合、第一の実施例に記述
されたm-Get response／confirm PDU への変換処理が
実施される。

【０１５４】また、前記処理フラグ・フィールドの値
が、単数Set を意味するものである場合、第一の実施例
に記述されたm-Set response／confirm PDU への変換
処理が実施される。

【０１５５】また、前記処理フラグ・フィールドの値
が、複数Get を意味するものである場合、複数Get処理
を実施する。当該複数Get処理については後述する。

【０１５６】また、前記処理フラグ・フィールドの値
が、複数Set フェーズ１を意味するものである場合は、
複数Setフェーズ１処理を実施する。当該複数Setフェー
ズ１処理については後述する。

【０１５７】また、前記処理フラグ・フィールドの値
が、複数Set フェーズ２を意味するものである場合は、
get-response PDU → m-Linked-Reply(Set)PDU, get
- next-PDU変換処理を実施する。当該get-response PD
U → m-Linked-Reply (Set)PDU, get-next-PDU変換処
理については後述する。

【０１５８】次に、複数Get 処理について説明する。前
記ＣＭＩＰ−ＳＮＭＰゲートウェイは受信したget-resp
onse PDU より、その情報から形成される管理オブジェ
クトを導きだす。そして、当該管理オブジェクトが、ス
ケジューリング情報テーブルのスコープ範囲フィールド
で指定される包含部分木の中に位置付けられるのかを判
断する。

【０１５９】前記管理オブジェクトが前記包含部分木の
中に位置付く場合は、get-responsePDU → m-Linked-
Reply(Get) PDU, get-next-request PDU 変換処理を実
行する。当該get-response PDU → m-Linked-Reply
(Get)PDU, get-next-requestPDU変換処理の詳細につい
ては、後述する。

【０１６０】また、前記管理オブジェクトが前記包含部
分木の中に位置付かない場合は、get-response PDU
→ m-Get response／confirm PDU変換処理を実施す
る。当該get-response PDU → m-Get response／co
nfirm PDU変換処理の詳細については、後述する。この
場合、ＣＭＩＰのGet のプロトコル処理は終了する。次
に、get-response PDU → m-Linked-Reply(Get)PDU,
get-next-requestPDU 変換処理について、図６１を用
いて説明する。前記ＣＭＩＰ−ＳＮＭＰゲートウェイは
受信したget-response PDU とスケジューリング情報テ
ーブルのフィルタ条件フィールドの内容とを比較し、前
記フィルタ条件が満足されていなければ、処理をおこな
わない。これは、前記get-response PDU で指定される
管理オブジェクトの保持している情報が、ＯＳＩマネー
ジャが指定している条件を満足していないことを意味し
ている。

【０１６１】前記フィルタ条件が満足されていれば、前
記get-response PDU に基づいて、m-Linked-Reply PD
Uを形成し、ＯＳＩマネージャに当該m-Linked-Reply P
DUを送信する。また、当該m-Linked-Reply PDUは、Get
に対するm-Linked-Replyである。

【０１６２】フィルタ条件が満足されてもされなくて
も、当該ＣＭＩＰ−ＳＮＭＰゲートウェイは、前記get-
response PDUを利用して、get-next-request PDUを形
成し、ＳＮＭＰエージェントに対して当該get-next-req
uest PDU を発行する。これは、ＳＮＭＰエージェント
から、前記get-response PDU で指定されるかんりオブ
ジェクトの次の位置にある管理オブジェクトから管理情
報を取得するためである。

【０１６３】最後にスケジューリング情報テーブルの処
理フラグ・フィールドに複数Get を意味するものを再設
定する。

【０１６４】次に、get-response PDU → m-Get re
sponse／confirm PDU変換処理について、図６２を用い
て説明する。当該get-response PDU → m-Get resp
onse／confirm PDU 変換処理では、前記ＣＭＩＰ−Ｓ
ＮＭＰゲートウェイはm-Getresponse／confirm PDUを
作成し、ＯＳＩマネージャに対して、当該m-Get resp
onse／confirm PDUを発行する。当該m-Get response
／confirm PDU の中身は空となる。

【０１６５】次に、複数Set フェーズ１の処理につい
て、図６３を用いて説明する。前記ＣＭＩＰ−ＳＮＭＰ
ゲートウェイは受信したget-response PDU より、その
情報から形成される管理オブジェクトを導きだす。そし
て、当該管理オブジェクトが、スケジューリング情報テ
ーブルのスコープ範囲フィールドで指定される包含部分
木の中に位置付けられるのかを判断する。

【０１６６】前記管理オブジェクトが前記包含部分木の
中に位置付く場合は、get-responsePDU → m-Linked-
Reply(Set) PDU, get-next-request PDU 変換処理を実
行する。当該get-response PDU → m-Linked-Reply
(Set) PDU, get-next-requestPDU 変換処理の詳細につ
いては、後述する。

【０１６７】また、前記管理オブジェクトが前記包含部
分木の中に位置付かない場合は、get-response PDU
→ m-Set response／confirm PDU変換処理を実施す
る。当該get-response PDU → m-Set response／co
nfirm PDU変換処理の詳細については、後述する。この
場合、ＣＭＩＰのSet のプロトコル処理は終了する。

【０１６８】次に、get-response PDU → set-reque
st PDU 変換処理について、図６４を用いて説明する。
前記ＣＭＩＰ−ＳＮＭＰゲートウェイは受信したget-re
sponse PDU とスケジューリング情報テーブルのフィル
タ条件フィールドの内容とを比較し、前記フィルタ条件
が満足されていれば、当該get-response PDUとスケジ
ューリング情報テーブルのアトリビュートＩＤリストを
利用してset-request PDUを形成し、ＳＮＭＰエージェ
ントに対して当該set-request PDUを発行する。その
後、スケジューリング情報テーブルの処理フラグ・フィ
ールドに複数Set フェーズ２を意味するものを設定す
る。

【０１６９】前記フィルタ条件が満足されていなけれ
ば、前記get-response PDU を利用して、get-next-req
uest PDUを形成し、当該get-next-request PDUを前記
SNMPエージェントに対して発行する。また、スケジュー
リング情報テーブルの処理フラグ・フィールドには複数
Set フェーズ１を意味するものを設定する。これは、前
記get-request PDUで指定される管理オブジェクトがＯ
ＳＩマネージャが設定したフィルタ条件を満足しなかっ
たことを意味する。また、当該ＣＭＩＰ−SNMPゲートウ
ェイは、前記get-response PDU で指定される管理オブ
ジェクトの次に位置する管理オブジェクトの管理情報の
取得を始めた。

【０１７０】次に、get-response PDU → m-Set re
sponse／confirm PDU変換処理について、図６５を用い
て説明する。当該get-response PDU → m-Set resp
onse／confirm PDU変換処理では、前記ＣＭＩＰ−ＳＮ
ＭＰゲートウェイはm-Set response／confirm PDUを
作成し、ＯＳＩマネージャに対して、当該m-Set res
ponse／confirm PDUを発行する。当該m-Set response
／confirm PDU の中身は空となる。

【０１７１】最後に、get-response PDU → m-Linke
d-Reply(Set) PDU, get-next-request PDU変換処理に
ついて、図６６を用いて説明する。前記ＣＭＩＰ−SNMP
ゲートウェイは、受信したget-response PDU とスケジ
ューリング情報テーブルのアトリビュートＩＤリストを
利用して、m-Linked-Reply PDU を作成し、OSIマネー
ジャに対して当該m-Linked-Reply PDUを発行する。

【０１７２】さらに、前記get-response PDU と、スケ
ジューリング情報テーブルのアトリビュートＩＤリスト
とフィルタ情報を利用して、get-next-request PDU を
作成し、ＳＮＭＰエージェントに対して、当該get-next
-request PDU を発行する。これは、前記get-response
PDU で指定される管理オブジェクトの次に位置する管
理オブジェクトの管理情報を取得し始めたことを意味す
る。

【０１７３】最後に、前記スケジューリング情報テーブ
ルの処理フラグ・フィールドに複数Setフェーズ１を設
定する。

【０１７４】本実施例によれば、ＯＳＩマネージャが一
度に複数の管理オブジェクトを選択し、管理オブジェク
トを選択する条件をＯＳＩマネージャが指定することで
き、ＯＳＩマネージャとＣＭＩＰ−ＳＮＭＰゲートウェ
イ間の通信プロトコルが合理化され、通信の効率が向上
する効果がある。

【０１７５】〈実施例３〉第３の実施例では、ＯＳＩ管
理で定義された汎用管理情報をインターネット管理の管
理情報等にマッピングする例を記述する。

【０１７６】ＯＳＩマネージャから見たインターネット
・ノードの構成例を図６９に示す。すなわち、ＯＳＩマ
ネージャから見ると、概念的には、インターネットを構
成する各ノードが、図６９に示される構成となっている
ことをあらわしている。説明を単純にするために、以下
では、インターネット・ノードそれぞれがＳＮＭＰエー
ジェントを持つと考える。

【０１７７】図６９に示すように、本実施例は、インタ
ーネット・ノードは、システム(system)，サブシステム
(subsystem)，通信エンティティ(communicationEntity)
の管理オブジェクトから構成される。とくに、通信エン
ティティは、ＩＰ通信エンティティ，ＵＤＰ通信エンテ
ィティ，ＴＣＰ通信エンティティの３つの管理オブジェ
クトに分類される。

【０１７８】本実施例であげた管理オブジェクトの他
に、ポート(port)やコネクション(connection)といった
管理オブジェクトを持つ実施例を考えることができる。

【０１７９】次に、ＯＳＩ管理で定義された汎用管理情
報について説明する。

【０１８０】system管理オブジェクトのsystemIDアトリ
ビュートの値は、ＳＮＭＰエージェントの持つsysName
の値とする。当該system 管理オブジェクトは、インタ
ーネット・ノード自体を意味している。

【０１８１】subsystem管理オブジェクトのsubsystemID
アトリビュートの値は、“Internet”とする。この値
は、すべてのインターネット・ノードで共通である。ま
た、この値により、前記system管理オブジェクトがイン
ターネット・プロトコルを処理できることを意味させ
る。

【０１８２】communicationEntity管理オブジェクト
は、communicationEntityIDアトリビュートの値とし
て、“IP”，“UDP”，“TCP”の３つの値をとる。これ
は、それぞれの管理オブジェクトが、ＩＰ通信エンティ
ティ、ＵＤＰ通信エンティティ，ＴＣＰ通信エンティテ
ィであることを意味している。

【０１８３】system管理オブジェクトは、前記systemID
アトリビュートのほかに、operationalStateアトリビュ
ート，usageStateアトリビュート,administrativeState
アトリビュート，managementStateアトリビュートを持
つ。次に、これらのアトリビュートの値の取得方法につ
いて説明する。

【０１８４】operationalStateアトリビュートの値は、
前記system管理オブジェクトに相当するインターネット
・ノードのＩＣＭＰエコー要求パケットに対する応答の
有無によって判断する。

【０１８５】usageStateアトリビュートの値は、アクテ
ィブ・ユーザ・プロトコルによって得られる前記インタ
ーネット・ノードの利用者数により判断する。

【０１８６】administrativeState アトリビュートの値
は、前記インターネット・ノードのＳＮＭＰエージェン
ト・アプリケーションに対するエコー・プロトコル・メ
ッセージへの応答の有無によって判断する。

【０１８７】また、administrativeState アトリビュー
トの値を前記インターネット・ノードに対してＳＮＭＰ
のget-request PDUを発行して、その応答の有無によっ
て判断する方法もある。

【０１８８】次に、第３の実施例を実現するＣＭＩＰ−
ＳＮＭＰゲートウェイの構成について図７０を用いて説
明する。

【０１８９】前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１
は、ＯＳＩマネージャとＯＳＩ通信インタフェース２２
を介して管理情報の交換をおこなう。

【０１９０】前記ＯＳＩマネージャと当該ＣＭＩＰ−Ｓ
ＮＭＰゲートウェイ１間の通信プロトコルはＣＭＩＰで
ある。よって、ＣＭＩＰプロトコル処理５０モジュール
によって、ＣＭＩＰプロトコルの制御をおこなう。

【０１９１】また、前記ＣＭＩＰ−ＳＮＭＰゲートウェ
イ１は、インターネット・ノードでもあるＳＮＭＰエー
ジェントとＴＣＰ／ＩＰ通信インタフェース２３を介し
てインターネットの管理情報を交換する。

【０１９２】前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１と
ＳＮＭＰエージェント間での、インターネットの管理情
報の交換のためのプロトコル処理は、ＳＮＭＰプロトコ
ル処理モジュール５１，エコー・プロトコル処理モジュ
ール５２，アクティブ・ユーザ処理モジュール５３がお
こなう。

【０１９３】ＳＮＭＰプロトコル処理モジュール５１
は、前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１とＳＮＭＰ
エージェントとの間でインターネットの管理情報を交換
するＳＮＭＰプロトコルの制御をおこなう。

【０１９４】エコー・プロトコル処理モジュール５２
は、前記ＣＭＩＰ−ＳＮＭＰゲートウェイ１とインター
ネット・ノード間のエコー・プロトコルの制御をおこな
う。

【０１９５】アクティブ・ユーザ・プロトコル処理モジ
ュール５３は、前記ＣＭＩＰ−SNMPゲートウェイ１とイ
ンターネット・ノード間のアクティブ・ユーザ・プロト
コルの制御をおこなう。

【０１９６】ＯＳＩ管理の管理情報とインターネットの
管理情報の変換は、ＯＳＩ管理／インターネット管理プ
ロトコル変換モジュール５４でおこなう。

【０１９７】ＩＣＭＰエコー要求パケットを送信し、Ｉ
ＣＭＰエコー応答パケットを受信するプロトコル処理の
機能は、前記ＴＣＰ／ＩＰ通信インタフェース２３の機
能に含まれる。

【０１９８】本実施例によれば、ＯＳＩマネージャはＯ
ＳＩ管理で定義された管理情報のみを使用するので、イ
ンターネットの管理を実現することによるＯＳＩマネー
ジャの変更が不要であるという効果がある。

【０１９９】

【発明の効果】本発明によると、インターネットとＯＳ
ＩネットワークをＯＳＩマネージャによって一元管理で
きる効果がある。また、管理者にとって、ＯＳＩ管理の
枠組みの中で統一的に通信ネットワークの管理情報を扱
うことができる効果がある。

【図面の簡単な説明】

【図１】ＣＭＩＰ−ＳＮＭＰゲートウェイとＯＳＩマネ
ージャ，ＳＮＭＰエージェントとの関係をあらわす図。

【図２】ＣＭＩＰ−ＳＮＭＰゲートウェイの構成図。

【図３】スケジューラ／プロトコル変換処理の構成図。

【図４】ＣＭＩＰ−ＳＮＭＰゲートウェイの構成図。

【図５】snmpTooBigパラメータ・テンプレート図。

【図６】snmpGenErrorパラメータ・テンプレート図。

【図７】プロトコル・シーケンス（アソシエーション）
の説明図。

【図８】プロトコル・シーケンス（ＣＭＩＰ−ＳＮＭＰ
変換）図。

【図９】スケジューラ／プロトコル変換処理の構成図。

【図１０】A-ASSOCIATE request／indication PDU受
信時の処理の説明図。

【図１１】A-RELEASE request／indication PDU受信
時の処理の説明図。

【図１２】A-ABORT request／indication PDU受信時
の処理の説明図。

【図１３】A-P-ABORT request／indication PDU受信
時の処理の説明図。

【図１４】ＩＰアドレス取得テーブルの構成図。

【図１５】スケジューリング情報テーブルの構成図。

【図１６】m-Get request／indication PDU受信時の
処理の説明図。

【図１７】ＩＰアドレス取得処理の説明図。

【図１８】インターネット・オブジェクトの包含関係の
説明図。

【図１９】m-Set request／indication PDU受信時の
処理の説明図。

【図２０】get-response PDU受信時の処理の説明図。

【図２１】m-Get応答処理の説明図。

【図２２】m-Get response／confirm PDU作成処理の
説明図。

【図２３】m-Get response／confirm PDU作成処理(to
oBigの場合)の説明図。

【図２４】m-Get response／confirm PDU作成処理(no
SuchNameの場合、その１)の説明図。

【図２５】m-Get response／confirm PDU作成処理(no
SuchNameの場合、その２)の説明図。

【図２６】m-Get response／confirm PDU作成処理(ge
nErrorの場合)の説明図。

【図２７】Attribute identifier list → variabl
e-bindings変換処理(その１)の説明図。

【図２８】Attribute identifier list → variabl
e-bindings変換処理(その２)の説明図。

【図２９】Attribute identifier list → variabl
e-bindings変換処理(その３)の説明図。

【図３０】Attribute identifier list → variabl
e-bindings変換処理(その４)の説明図。

【図３１】Attribute identifier list → variabl
e-bindings変換処理(その５)の説明図。

【図３２】Attribute identifier list → variabl
e-bindings変換処理(その６)の説明図。

【図３３】Attribute identifier list → variabl
e-bindings変換処理(その７)の説明図。

【図３４】Attribute identifier list → variabl
e-bindings変換処理(その８)の説明図。

【図３５】Attribute identifier list → variabl
e-bindings変換処理(その９)の説明図。

【図３６】Attribute identifier list → variabl
e-bindings変換処理(その１０)の説明図。

【図３７】Attribute identifier list → variabl
e-bindings変換処理(その１１)の説明図。

【図３８】m-Get 正常response／confirm PDU作成処理
(その１)の説明図。

【図３９】m-Get 正常response／confirm PDU作成処理
(その２)の説明図。

【図４０】m-Get 正常response／confirm PDU作成処理
(その３)の説明図。

【図４１】m-Get 正常response／confirm PDU作成処理
(その４)の説明図。

【図４２】m-Get 正常response／confirm PDU作成処理
(その５)の説明図。

【図４３】m-Get 正常response／confirm PDU作成処理
(その６)の説明図。

【図４４】m-Get 正常response／confirm PDU作成処理
(その７)の説明図。

【図４５】m-Set応答処理の説明図。

【図４６】m-Set response／confirm PDU作成処理の
説明図。

【図４７】trap → m-Event-Report変換処理の説明
図。

【図４８】trap(coldStart) → m-Event-Report変換処
理の説明図。

【図４９】trap(warmStart) → m-Event-Report変換処
理の説明図。

【図５０】trap(linkDown) → m-Event-Report変換処
理の説明図。

【図５１】trap(linkUp) → m-Event-Report変換処理
の説明図。

【図５２】trap(authenticationFailure) → m-Event-
Report変換処理の説明図。

【図５３】trap(egpNeiborLoss) → m-Event-Report変
換処理の説明図。

【図５４】trap(enterpriseSpecific) → m-Event-Rep
ort変換処理の説明図。

【図５５】複数オブジェクト選択時のプロトコル・シー
ケンス(m-Get)の説明図。

【図５６】複数オブジェクト選択時のプロトコル・シー
ケンス(m-Set)の説明図。

【図５７】m-Get request／indication PDU →get-r
equest PDU 変換処理の説明図。

【図５８】m-Set request／indication PDU →get-r
equest PDU 変換処理の説明図。

【図５９】get-response PDU受信時の処理の説明図。

【図６０】複数Ｇｅｔ処理の説明図。

【図６１】get-request PDU → m-Linked-Reply(Ge
t) PDU，get-next-request PDU変換処理の説明図。

【図６２】get-response PDU → m-Get response／
confirm PDU変換処理の説明図。

【図６３】複数Setフェーズ１処理の説明図。

【図６４】get-response PDU → set-request PDU
変換処理の説明図。

【図６５】get-response PDU → m-Set response／
confirm PDU変換処理の説明図。

【図６６】get-response PDU → m-Linked-Reply(Se
t) PDU，get-next-request PDU変換処理の説明図。

【図６７】スケジューリング情報テーブルの構成図。

【図６８】クラス情報テーブルの構成図。

【図６９】インターネット・ノードの包含関係の構成例
を示す図。

【図７０】ＣＭＩＰ−ＳＮＭＰゲートウェイの構成例を
示す図。

【符号の説明】

１…ＣＭＩＰ−ＳＮＭＰゲートウェイ、２…ＯＳＩマネ
ージャ、３，３ａ〜３ｂ…ＳＮＭＰエージェント、４，
４ａ〜４ｄ…管理オブジェクト、１１…スケジューラ／
プロトコル変換処理、１２…A-ASSOCIATE処理、１３…A
-RELEASE処理、１４…A-ABORT処理、１５…m-Get処理、
１６…m-Set処理、１７…m-Event- Report処理、１８
…get-request処理、１９…get-response処理、２０…s
et- request処理、２１…trap処理、２２…ＯＳＩ通信
インタフェース、２３…TCP／ＩＰ通信インタフェー
ス。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁵ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 12/28 (72)発明者 藤野 修司 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内

Claims (12)

【特許請求の範囲】
1. 【請求項１】ＯＳＩ管理におけるマネージャ・システム
   (以下、ＯＳＩマネージャと呼ぶ)の発行するＣＭＩＰプ
   ロトコル データ単位（以下ＰＤＵ）を、インターネッ
   ト管理におけるエージェント・システム(以下、ＳＮＭ
   Ｐエージェントと呼ぶ)に対するＳＮＭＰ ＰＤＵに変
   換するＣＭＩＰ−ＳＮＭＰゲートウェイにおいて、OSI
   管理の管理情報構造にしたがった管理情報を、インター
   ネット管理の管理情報構造にしたがった管理情報に変換
   する管理情報変換機構を設けたことを特徴とするＣＭＩ
   Ｐ−ＳＮＭＰゲートウェイ。
2. 【請求項２】前記管理情報変換機構が、ＯＳＩ管理で規
   定された管理情報を、インターネット管理で規定された
   管理情報に変換するＣＭＩＰ−ＳＮＭＰゲートウェイ。
3. 【請求項３】前記ＯＳＩマネージャと前記ＣＭＩＰ−Ｓ
   ＮＭＰゲートウェイ間のアソシエーションの確立を、前
   記ＯＳＩマネージャとのアソシエーション確立に関する
   識別情報を持たせることによって行なわしめるＣＭＩＰ
   −ＳＮＭＰゲートウェイ。
4. 【請求項４】請求項１において、受信したＣＭＩＰ Ｐ
   ＤＵ中の識別名を、インターネットにおけるＩＰアドレ
   スと対応させる手段を設けたＣＭＩＰ−ＳＮＭＰゲート
   ウェイ。
5. 【請求項５】請求項４において、受信したＣＭＩＰ Ｐ
   ＤＵ中の識別名を、インターネットにおけるＩＰアドレ
   スに対応させる手段が、コミュニティ名を取得する手段
   を備えたことを特徴とするＣＭＩＰ−ＳＮＭＰゲートウ
   ェイ。
6. 【請求項６】請求項１において、前記ＳＮＭＰエージェ
   ントに対するＳＮＭＰ ＰＤＵの発行を多重化する機構
   を設けたＣＭＩＰ−ＳＮＭＰゲートウェイ。
7. 【請求項７】請求項６において、前記ＳＮＭＰ ＰＤＵ
   発行多重化機構が、当該ＳＮＭＰＰＤＵを発行すること
   による競合の発生を回避する手段を有するＣＭＩＰ−SN
   MPゲートウェイ。
8. 【請求項８】請求項６において、前記ＳＮＭＰ ＰＤＵ
   発行多重化機構が、受信したCMIPＰＤＵの一部または全
   部を保持するＣＭＩＰ−ＳＮＭＰゲートウェイ。
9. 【請求項９】請求項１において、前記ＯＳＩマネージャ
   と前記ＣＭＩＰ−ＳＮＭＰゲートウェイ間の通信プロト
   コルが、所定のテンプレートで規定されるプロセッシン
   グ・フェイリア・エラーを使用するＣＭＩＰ−ＳＮＭＰ
   ゲートウェイ。
10. 【請求項１０】請求項１において、前記ＳＮＭＰエージ
    ェントに対して、get-next-requestPDU発行後、set-req
    uest PDUを発行するという、ＳＮＭＰのプロトコル・デ
    ータ単位の発行順序を持つ複数オブジェクト選択機構を
    備えたＣＭＩＰ−ＳＮＭＰゲートウェイ。
11. 【請求項１１】請求項１０において、複数オブジェクト
    選択機構が、インターネット管理で規定された管理情報
    の包含関係に関する情報を、保持するＣＭＩＰ−ＳＮＭ
    Ｐゲートウェイ。
12. 【請求項１２】請求項２における管理情報変換機構を持
    つＣＭＩＰ−ＳＮＭＰゲートウェイにおいて、エコー・
    プロトコルを処理する機能とアクティブ・ユーザ・プロ
    トコルを処理する機能を保持したＣＭＩＰ−ＳＮＭＰゲ
    ートウェイ。