JP2000236348A - インターネットプロトコルを用いた遠隔機器の管理システム - Google Patents

Abstract

(57)【要約】 【課題】インターネットプロトコルを用いて非ＩＰ機器
を遠隔管理するシステムを提供する。 【解決手段】インターネットプロトコル（ＩＰ）で通信
を行うことができない遠隔機器を、見かけ上インターネ
ットプロトコルで管理するための管理システムであっ
て、前記遠隔機器に対応する数の論理ＩＰアドレスを割
り当てられ、インターネットプロトコルで運用されるネ
ットワークに接続されたネットワークインタフェース・
カードと、複数の前記論理ＩＰアドレスに対応する複数
のソケットを有し、該ソケットの１つが前記ネットワー
クから要求パケットを受信することに応答して当該ソケ
ットに対応する前記遠隔機器に前記要求パケットの内容
を該遠隔機器対応のプロトコルで転送する管理部とを備
える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワークに接続さ
れる機器の遠隔管理に関する。

【０００２】

【従来技術】インターネット通信のプロトコルは、下位
から順にハードウェア、ネットワークインターフェース
層、インターネット層（ＩＰ、ＩＣＭＰ）、トランスポ
ート層（ＴＣＰ、ＵＤＰ）、およびアプリケーション層
（ＨＴＴＰ、ＨＴＭＬ、ＳＮＭＰ、ＭＩＢその他）の階
層からなる。

【０００３】インターネットプロトコル（ＩＰ）で通信
ができる機器をＩＰ機器、インターネットプロトコル以
外の通信プロトコルでしか通信ができない機器を非ＩＰ
機器と呼ぶ。ＩＰ機器のネットワーク管理においては、
Simple Network ManagementProtocol(SNMP)が事実上の
標準として広く実用化されている。ＳＮＭＰは、アプリ
ケーション層のプロトコルで、トランスポート層のプロ
トコルであるユーザデータグラムプロトコル(User Data
gram Protocol: UDP)上で動作する。また、ＵＤＰは、
インターネット層のプロトコルであるインターネットプ
ロトコル(IP)上で動作する。

【０００４】ＳＮＭＰでは管理する側をマネージャ（ネ
ットワーク監視端末）、管理される側をエージェントと
いう。このマネージャとエージェントとの間の通信のプ
ロトコルがＳＮＭＰである。ＳＮＭＰでは、情報要求、
前回要求した次の情報要求、情報要求応答、設定要求、
イベント通知（トラップ：trap）という５つの操作を行
うことができる。

【０００５】通常の動作では、情報要求・情報要求応答
によって定期的に機器の動作をチェックしたり、設定要
求によって機器設定を変更したりする。ＳＮＭＰの操作
は、機器へのデータの書き込みと読み込みという２つの
操作に集約することができ、コンピュータの入出力など
の基本的な動作と同じである。

【０００６】トラップは、なんらかの原因でネットワー
ク機器の状況が変化した場合に、状況の変化をＳＮＭＰ
でマネージャに通知させたい場合に利用される。トラッ
プの場合には、エージェントに問い合わせなくても、機
器の状態が変化したときにエージェントの方から通知さ
れる。トラップの役割はコンピュータの割り込み通知に
似ている。

【０００７】さらに、ＩＰ上で動作するプロトコルとし
て、インターネットコントロールメッセージ・プロトコ
ル(ICMP)がある。ＩＰはコネクションレス型のプロトコ
ルであり、パケットを中継する最大限の努力をするが、
パケットの到達性は保証しない。ＩＰデータグラムが何
らかの障害によって到達できなかったときは、ＩＣＭＰ
プロトコルにより障害の通知が行われる。ＩＣＭＰは、
通常オペレーティングシステムが処理しており、アプリ
ケーションでは送受信できない。

【０００８】ＩＣＭＰには、様々な種類のメッセージが
あるが、この明細書で重要となるのは、ＩＣＭＰエコー
リクエストとＩＣＭＰエコーリプライである。これは、
対象となる機器のネットワークインタフェースが正常に
動作していることと、その機器までの経路が存在してい
ることを確認するためのものである。対象となる機器
は、ＩＣＭＰエコーリクエストパケットを受信したら、
単にＩＣＭＰエコーリプライパケットを返答するだけで
ある。一般に、マネージャ側では、ping(PacketInterNe
twork Groper)コマンドを使うことが多い。pingコマン
ドは、相手先ホストへの到達可能性を調べるコマンド
で、ＩＣＭＰエコーリクエストパケットを送り、一定時
間内にＩＣＭＰエコーリプライパケットが返ってくるか
どうかを確認し、往復にかかった時間、成功率などを表
示する。

【０００９】トランスポート層のプロトコルには、ＴＣ
ＰとＵＤＰがある。ＴＣＰがコネクション指向で信頼性
のあるストリーム型のプロトコルであるのに対し、ＵＤ
Ｐは、信頼性の低いデータグラム（データのかたまり）
型のプロトコルで細かい処理は上位層のアプリケーショ
ンが決定する。どちらのプロトコルが使われているかは
ＩＰヘッダの中で示される。

【００１０】ＴＣＰまたはＵＤＰでは、パケットの宛先
であるアプリケーションをポート番号によって指定す
る。すなわち、ポート番号は、同一のコンピュータ内の
プログラムを識別するためのもので、プログラムのアド
レスと呼ぶことができる。コンピュータにはこのポート
番号に対応してソケットが設けられている。ソケット
は、アプリケーションプログラムがネットワークを通じ
て通信を行うために、オペレーティングシステムが提供
するインタフェースである。コンピュータは、ソケット
にパケットが到着することに応答して、該当するアプリ
ケーションにソケットの内容を渡す。

【００１１】ローソケット(raw socket)は、特殊なソケ
ットで、予め指定されて種類のパケットとか、予め指定
された宛先アドレスまたは送信元アドレスのパケットな
ど任意のパケットを受信することができる。これを使用
すると、通常のソケットでは参照できないＩＰヘッダ部
分を、アプリケーションで参照及び操作することができ
る。例えば、自分のＩＰアドレス宛ではないパケットを
受信したり、ヘッダの送信元ＩＰアドレスに自分以外の
ＩＰアドレスを付けて送信することができる。具体的に
は、ホストの通信制御部がネットワーク上のパケットを
モニターし、予め指定した種類のパケットまたは予め指
定した宛先アドレスまたは送信元アドレスのパケットを
取り込む。

【００１２】ＩＰヘッダは、ネットワーク上で送信され
るパケットに付けられるヘッダで、宛先のコンピュータ
（ホスト）のＩＰアドレス、宛先コンピュータ内の宛先
ポート番号、送信元のコンピュータのＩＰアドレス、送
信元コンピュータ内の送信元ポート番号などを含んでい
る。

【００１３】インターネットプロトコルに関しては、参
考文献「詳解TCP/IP」W.R.Stevens著／橘康雄訳／井上
尚司監、ソフトバンク、１９９７を、また、ネットワー
クアドレス変換に関しては、「RFC1631 The IP network
Address Translator (NAT)」K.Egevang／P.Francis、
１９９４ 参照していだたきたい。

【００１４】図１に従来例を示す。ＩＰ用ネットワーク
管理アプリケーション６０は、ＩＰ機器Ａ１０やＩＰ機
器Ｂ２０をＳＮＭＰで管理している。一方、同じ遠隔機
器の管理でありながら、非ＩＰ機器の場合には、ＳＮＭ
Ｐのような標準プロトコルは存在せず、機器メーカ各社
が、独自の仕様で、遠隔管理している。図１の例では、
ＩＰ用ネットワーク管理アプリケーション６０とは別
に、非ＩＰ用ネットワーク管理アプリケーション６５を
用意し、非ＩＰ機器Ａ３０や、非ＩＰ機器Ｂ４０を管理
している。

【００１５】非ＩＰ機器の代表的な例は、ケーブルテレ
ビ網において一定の間隔ごとに設置された増幅器（アン
プ）である。このアンプは通常屋外に設置されており、
雨水が入ったり、交通事故で壊されたり、落雷で壊れた
りと、トラブルを生じることが多い。このアンプは、セ
ンターからメーカー独自のプロトコルを用いて遠隔管理
されている。このプロトコルはコンピュータ分野で標準
となっているインターネットプロトコルとは全く異なっ
ている。

【００１６】

【発明が解決しようとする課題】従来技術によると、非
ＩＰ機器の管理には、独立した非ＩＰ用管理アプリケー
ション６５を用意しなくてはならないため、ユーザは、
遠隔管理という同じ目的のために、２種類の管理アプリ
ケーションを使わなくてはならず、使い勝手が悪く、管
理効率が悪かった。そこで、この発明は、インターネッ
トプロトコルを用いて非ＩＰ機器を遠隔管理するシステ
ムを提供することを目的とする。

【００１７】

【課題を解決するための手段】管理効率を上げるため
に、非ＩＰ機器に対しても架空のＩＰアドレスを割り当
て、あたかもＩＰ機器であるかのように、ひとつのネッ
トワーク管理アプリケーションで管理できるような管理
手法を開発した。

【００１８】請求項１記載の発明は、インターネットプ
ロトコル（ＩＰ）で通信を行うことができない遠隔機器
を、見かけ上インターネットプロトコルで管理するため
の管理システムであって、前記遠隔機器に対応する数の
論理ＩＰアドレスを割り当てられ、インターネットプロ
トコルで運用されるネットワークに接続されたネットワ
ークインタフェース・カードと、複数の前記論理ＩＰア
ドレスに対応する複数のソケットを有し、該ソケットの
１つが前記ネットワークから要求パケットを受信するこ
とに応答して当該ソケットに対応する前記遠隔機器に前
記要求パケットの内容を該遠隔機器対応のプロトコルで
転送する管理部とを備えるという構成をとる。

【００１９】請求項１の発明によると、同じネットワー
ク管理アプリケーションで、インターネットプロトコル
で通信するＩＰ機器とインターネットプロトコル以外の
プロトコルで通信する非ＩＰ機器を一元管理することが
できる。ネットワーク管理アプリケーション側から見る
と、ＩＰ機器のネットワーク管理プロトコルの業界標準
であるＳＮＭＰで、非ＩＰ機器を管理できるので、管理
アプリケーションの開発が容易になるとともに、選択肢
が増大し、より付加価値の高い、管理アプリケーション
を使用できる可能性が高くなる。

【００２０】請求項２記載の発明は、インターネットプ
ロトコル（ＩＰ）で通信を行うことができない遠隔機器
を、見かけ上インターネットプロトコルで管理するため
の管理システムであって、前記遠隔機器にはそれぞれ固
有の架空ＩＰアドレスが割り当てられており、ＩＰアド
レスを持ち、前記遠隔機器に対応するポート番号の複数
のポートを有するネットワークインターフェースと、前
記複数のポートに対応する複数のソケットを有し、該ソ
ケットの１つにパケットが受信されることに応答して、
該ソケットに対応する前記遠隔機器に該パケットの内容
を該遠隔機器対応のプロトコルで転送する管理部と、前
記遠隔機器に固有の架空ＩＰアドレスを宛先ＩＰアドレ
スとする要求パケットを受信することに応答して、該要
求パケットのＩＰヘッダに含まれる宛先ＩＰアドレスお
よび宛先ポートを前記ホストのＩＰアドレス、および対
応する前記遠隔機器の前記ポート番号に変更して変更後
のパケットを送信する変換サーバとを有するという構成
をとる。

【００２１】請求項２の発明によっても請求項１の発明
と同様の利点が得られる。また、請求項２記載の発明
は、請求項３記載の発明と同時に使用することができ
る。

【００２２】請求項３記載の発明は、インターネットプ
ロトコルで通信を行うことができない遠隔機器を、見か
け上、インターネットプロトコルで管理するための管理
システムであって、前記遠隔機器にはそれぞれ固有の架
空ＩＰアドレスが割り当てられており、前記遠隔機器対
応のプロトコルによって該遠隔機器と通信することがで
きるホストと、任意のパケットを受け取ることができる
ソケットを用いて、前記遠隔機器に割り当てられた架空
ＩＰアドレスに対するＩＣＭＰエコーリクエストパケッ
トを受信し、前記ＩＣＭＰエコーリクエストパケットを
ユーザデータグラム・パケットに内包化して送信するＩ
ＣＭＰ・ＵＤＰ変換サーバとを備え、前記ホストは、前
記送信されたユーザデータグラム・パケットを受信し、
内包化されている前記ＩＣＭＰエコーリクエストパケッ
トに応答して、前記遠隔機器対応のプロトコルを用い
て、このパケット中で指定されている前記架空ＩＰアド
レスに対応する前記遠隔機器と通信を行うようにしたと
いう構成をとる。

【００２３】請求項３の発明によると、インターネット
の管理において標準であるインターネットコントロール
メッセージプロトコルＩＣＭＰ（具体的にはpingコマン
ド）を使って、非ＩＰ機器との通信状況を簡単に確認す
ることができる。

【００２４】

【発明の実施の形態】図２に、この発明の一つの実施形
態を示す。ネットワーク管理アプリケーション６１は、
ネットワーク上のＩＰ機器１０、２０を管理するアプリ
ケーションで、典型的にはヒューレット・パッカード社
のOpenView（商標）というミドルウェア上で動作するネ
ットワークノードマネージャである。プロキシエージェ
ント７０は、この発明における管理部を構成する部分で
ある。図２にはネットワーク管理アプリケーション６１
がホスト９１上で動作し、プロキシ・エージェント７０
がホスト９０上で動作するように示してあるが、これら
のアプリケーションは同じホスト上で動作してもよい。

【００２５】プロキシ・エージェント７０は、インター
ネットプロトコルとは異なるプロトコルで通信する非Ｉ
Ｐ機器３０、４０を、ネットワーク管理アプリケーショ
ン６１がインターネットプロトコルで管理することがで
きるようにするためにネットワーク管理アプリケーショ
ン６１と非ＩＰ機器との間に設けられ、異なる二つのプ
ロトコルの翻訳を行う。非ＩＰ機器３０、４０にはそれ
ぞれ架空ＩＰアドレスが割り当てられている。

【００２６】図３に、非IP機器３台を管理するためのプ
ロキシ・エージェントの構成の一例を示す。ネットワー
クインタフェース・カードに、非ＩＰ機器に割り当てら
れた３つの架空ＩＰアドレスを割り当て、それぞれにソ
ケットをひとつずつ割り当てる。プロキシ・エージェン
ト７０は、この３つのソケットを周期的にチェックす
る。

【００２７】ネットワーク管理アプリケーション６１
は、例えば、非ＩＰ機器Ａ（３０）の情報を得ようとす
ると、非ＩＰ機器Ａに対応する論理ＩＰアドレスＡ（１
１０）を宛先ＩＰアドレス、標準ＳＮＭＰポート１４０
のポート番号を宛先ポート番号に指定したＩＰヘッダを
付けてＳＮＭＰプロトコルによるリード（読み込み）要
求パケットをネットワークに送る。インターネットプロ
トコルにおいて非常に広く使われるアプリケーションプ
ログラムについては、使用するポート番号がウェルノウ
ンポート番号として決められており、ネットワーク管理
プログラムＳＮＭＰに対しては１６１番が割り当てられ
ている。

【００２８】ホスト９０は、ネットワークインターフェ
ース・カード１００を介してこのリード要求パケットを
受け取り、ＩＰヘッダに含まれる宛先アドレスおよび宛
先ポート番号をデコードし、論理ＩＰアドレスAに対応
するソケットＡ（７１）にリード要求パケットを転送す
る。

【００２９】一般に、インターネット・プロトコルで送
信されるパケットは、データの頭にＩＰヘッダを付けた
構造になっており、典型的には表１に示すような構成に
なっている。

【００３０】

【表１】

【００３１】プロキシ・エージェント７０は、このリー
ド要求パケットがソケットＡ（７１）に到着したことか
ら、このリード要求パケットが非ＩＰ機器Ａ（３０）に
対するものであると判断し、非ＩＰ機器デバイスドライ
バ７４に指示を出して、非ＩＰ機器対応のプロトコルに
よって非ＩＰ機器Ａ（３０）にアクセスし、必要な情報
を得る。プロキシ・エージェント７０は、この読み込ん
だ情報を前記リード要求パケットに対する返答パケット
に組み込み、これをソケットＡ７１から、ネットワーク
管理アプリケーションに向けて送信する。この返答パケ
ットのＩＰヘッダは、リード要求パケットの送信元ＩＰ
アドレスを宛先ＩＰアドレスとし、リード要求パケット
の送信元ポート番号を宛先ポート番号に指定し、非ＩＰ
機器Ａの論理ＩＰアドレスを送信元ＩＰアドレスとして
含んでいる。

【００３２】この返答パケットを受け取るネットワーク
管理アプリケーション６１側からは、あたかも論理ＩＰ
アドレスＡ（１１０）から、返答があったかのように見
える。上記の動作は、ライト（書き込み）要求パケット
の場合でも、同様である。また、非ＩＰ機器側からのイ
ベント発生通知（トラップ）に対しては、ネットワーク
管理アプリケーション６１側からの要求がなくても、プ
ロキシ・エージェント７０から自発的に、トラップパケ
ットを送信する。その場合も、各非ＩＰ機器に割り当て
られた論理ＩＰアドレスに対応するソケットから送信さ
れるので、ネットワーク管理アプリケーション６１は、
論理ＩＰアドレスＡからトラップパケットが来たものと
判断する。

【００３３】図４に、もう１つの発明の実施形態を示
す。ネットワーク管理アプリケーション６１はホスト９
１上で動作し、ＳＮＭＰを用いてネットワーク上のＩＰ
機器１０、２０を管理し、ホスト９２上で動作するアド
レス・ポート変換サーバ８０およびホスト９０上で動作
するプロキシ・エージェント７８を介して非ＩＰ機器３
０、４０をもＩＰ機器と同様に管理する。ここで、プロ
キシ・エージェント７８、アドレス・ポート変換サーバ
８０、およびネットワーク管理アプリケーション６１
は、同じホスト上で動作してもよい。ネットワーク管理
アプリケーション６１、プロキシ・エージェント７８、
アドレス・ポート変換サーバ８０はインターネット・プ
ロトコルを使用したネットワークに接続されている。ア
ドレス・ポート変換サーバ８０は、ローソケットを用い
て、自身が動作しているホストのＩＰアドレス以外を宛
先とするパケットをも受信することができる。

【００３４】図５は、図４のプロキシ・エージェント７
８の構成を示す。プロキシ・エージェント７８が動作す
るホスト９０にはＩＰアドレス１５０が割り当てられて
おり、非ＩＰ機器Ａ（３０）、Ｂ（４０）、およびＣ
（５０）のそれぞれに対応してポート番号Ａ、Ｂ、Ｃが
割り当てられている。各非ＩＰ機器に対応して用意され
るソケット７１、７２、７３では、共通のＩＰアドレス
１５０が使用されるが、ポート番号が異なっている。

【００３５】各非ＩＰ機器にはそれぞれ架空のＩＰアド
レスが割り当てられている。ネットワーク管理アプリケ
ーション６１は、たとえば非ＩＰ機器Ａに対して要求パ
ケットを送るとき、ＩＰヘッダの宛先ＩＰアドレス・フ
ィールドに非ＩＰ機器Ａの架空ＩＰアドレスを入れ、ポ
ート番号として標準ＳＮＭＰポート番号を入れてネット
ワークに送り出す。

【００３６】アドレス・ポート変換サーバ８０は、各非
ＩＰ機器の架空ＩＰアドレス宛に送られた要求パケット
を取り込んで、ＩＰヘッダに含まれる宛先ＩＰアドレス
をホスト９０のＩＰアドレス１５０に変換し、かつＩＰ
ヘッダに含まれる宛先標準ＳＮＭＰポート番号を元の宛
先ＩＰアドレスすなわち架空ＩＰアドレスに対応する非
ＩＰ機器のポート番号、この例ではポート番号Ａに変換
する。次いで、アドレス・ポート変換サーバは、変更し
たＩＰヘッダを付けた要求パケットをネットワークに送
る。

【００３７】ホスト９０は、こうして変更されたＩＰヘ
ッダを持つ要求パケットを受け取り、指定されたポート
番号Ａに対応するソケットＡに渡す。プロキシ・エージ
ェント７８は、ソケットＡに要求パケットが受信された
ことに応答して対応する非ＩＰ機器Ａと非ＩＰ機器ドラ
イバ７４を介して通信を行う。

【００３８】表２は、変換する前のＩＰヘッダと変換後
のＩＰヘッダの関係を示す。前述したように標準ＳＮＭ
Ｐポート番号は、１６１が割り当てられている。

【００３９】

【表２】

【００４０】プロキシ・エージェント７８は、非ＩＰ機
器Ａから得られたデータを返答パケットに組立て、ネッ
トワークに送りだす。次の表３は、この返答パケットの
ＩＰヘッダと、これがアドレス・ポート変換サーバ８０
で変換された後のＩＰヘッダとの関係を示す。

【００４１】

【表３】

【００４２】アドレス・ポート変換サーバ８０は、ネッ
トワーク管理アプリケーション６１が返答パケットを受
信できるよう、表３に従ってＩＰヘッダ部分を変更し、
再送信する。

【００４３】次の表４は、トラップパケットに対するＩ
Ｐヘッダ部分の変更を示す。標準ＳＮＭＰトラップポー
ト番号は、１６２が割り当てられている。

【００４４】

【表４】

【００４５】いずれの場合にも、プロキシ・エージェン
ト側の送受信ポートの番号が各非ＩＰ機器と対応してお
り、この情報をもとに、アドレス・ポート変換サーバ８
０は、その非ＩＰ機器に割り当てられている、適切な架
空ＩＰアドレスを知ることができる。

【００４６】図６は、ネットワーク管理アプリケーショ
ン６１が、自らの要求により、非ＩＰ機器３１に関す
る、何らかの情報を得る場合の、パケット伝送の流れを
示したものである。まず、ネットワーク管理アプリケー
ション６１より、ＳＮＭＰのフォーマットで、最終ター
ゲットである、非ＩＰ機器３１の架空ＩＰアドレス宛
に、変換前要求パケット２００が送信される。これを、
アドレス・ポート変換サーバ８０が受信し、ＩＰヘッダ
部分を表１に従って変更し、変換後要求パケット２１０
を送信する。これを、プロキシ・エージェント７８が受
信し、受信したポートの番号から、非ＩＰ機器３１を選
択し、これに対して、非ＩＰ要求メッセージ２２０を送
信する。この部分は、機器メーカ独自のプロトコルであ
る。

【００４７】プロキシ・エージェント７８は、非ＩＰ機
器３１が返す、非ＩＰ返答メッセージ２３０を受け取る
と、ＳＮＭＰのフォーマットで、変換前返答パケット２
４０を作成し、アドレス・ポート変換サーバ８０に送信
する。アドレス・ポート変換サーバ８０は、これを受信
し、ＩＰヘッダ部分を表２に従って変更し、ネットワー
ク管理アプリケーション６１に再送信する。ネットワー
ク管理アプリケーション６１は、あたかも、返答パケッ
トが前記架空ＩＰアドレスから送信されたものとして、
受信する。

【００４８】図７は、ネットワーク管理アプリケーショ
ン６１からの要求ではなく、非ＩＰ機器３１側から、自
発的にイベントの通知を行う場合のパケット伝送の流れ
を示したものである。非ＩＰ機器３１は、あらかじめ定
義された異常状態を検出すると、プロキシ・エージェン
ト７８からの要求パケットを待たずに、自発的に非ＩＰ
イベント通知メッセージ２６０を送信する。プロキシ・
エージェント７８は、このメッセージを受信すると、直
ちに変換前トラップパケット２７０をアドレス・ポート
変換サーバに向けて送信する。イベントの内容によって
は、いったん、非ＩＰ機器３１と通信をして、詳細を確
認する場合もある。

【００４９】アドレス・ポート変換サーバ８０は、ＩＰ
ヘッダ部分を表３に従って変更し、ネットワーク管理ア
プリケーション６１に再送信する。ネットワーク管理ア
プリケーション６１は、あたかも、トラップパケットが
非ＩＰ機器３１に割り当てられた架空ＩＰアドレスから
送信されたものとして受信する。

【００５０】図８は、この発明のさらにもう一つの実施
形態の例を示す。ここで、プロキシ・エージェント７９
はホスト９０上で動作し、ホスト９３上で動作するＩＣ
ＭＰ・ＵＤＰ変換サーバ８５およびホスト９１上で動作
するネットワーク管理アプリケーション６１とインター
ネット・プロトコルのネットワークに接続されている。
これらのアプリケーションは同じホスト上で動作しても
よく、たとえばＩＣＭＰ・ＵＤＰ変換サーバ８５はプロ
キシ・エージェント７９が動作するホスト９０に組み込
まれていても良い。

【００５１】ネットワーク管理アプリケーション６１
は、ネットワークに接続されたＩＰ機器１０、２０にＩ
ＣＭＰ(Internet Control Message Protocol)パケット
を送ってＩＰ機器の管理を行う。

【００５２】プロキシ・エージェント７９およびＩＣＭ
Ｐ・ＵＤＰサーバ８５は、インターネットプロトコルで
通信することができない非ＩＰ機器３０、４０をＩＰ機
器１０、２０と同様にインターネットプロトコルで管理
することができるようにするためにネットワークに接続
されている。非ＩＰ機器３０、４０にはそれぞれ架空の
ＩＰアドレスが割り当てられている。

【００５３】ＩＣＭＰ・ＵＤＰサーバ８５は、ローソケ
ットを用い、自身が動作しているホスト以外に宛てたＩ
ＣＭＰパケットも受信することができる。ネットワーク
管理アプリケーション６１は、非ＩＰ機器３０、４０に
ＩＣＭＰパケットを送信する際、非ＩＰ機器の架空ＩＰ
アドレスを宛先ＩＰアドレスとしてＩＰヘッダに入れ
る。ＩＣＭＰ・ＵＤＰサーバは、非ＩＰ機器に割り当て
られた架空ＩＰアドレス宛のＩＣＭＰエコーリクエスト
パケットを受信し、これを前記非ＩＰ機器宛のＵＤＰパ
ケットに内包化してネットワークに再送信する。ここで
内包化するとは、ＩＣＭＰヘッダ、ＩＰヘッダ、および
データ部を含むＩＣＭＰパケット全体をＵＤＰのデータ
部に入れ、新たにＵＤＰヘッダを付けることをいう。

【００５４】図９に示すように、プロキシ・エージェン
ト７９の動作するホスト９０は、ＩＣＭＰパケットを内
包化したＵＤＰパケットを送受信するための専用のＩＣ
ＭＰポート１９０をもっている。このＩＣＭＰポート１
９０でＵＤＰパケットが受信された場合、プロキシ・エ
ージェント７９は、前記ＵＤＰパケットに内包化されて
いる、ＩＣＭＰエコーリクエストパケットを取り出し、
その中の宛先アドレスに対応する非ＩＰ機器と通信を行
い、正常に通信ができれば、ＩＣＭＰエコーリプライパ
ケットを、ＵＤＰパケットに内包化してＩＣＭＰ・ＵＤ
Ｐ変換サーバ８５に送信する。ＩＣＭＰ変換サーバ８５
では、前記ＵＤＰパケットの中から、ＩＣＭＰエコーリ
プライパケットを取り出して、これをネットワーク管理
アプリケーション６１に送る。

【００５５】図１０に、パケット伝送の様子を示す。ネ
ットワーク管理アプリケーション６１が、非ＩＰ機器３
１の架空ＩＰアドレス宛に、送信したＩＣＭＰエコーリ
クエストパケット２９０は、ＩＣＭＰ・ＵＤＰ変換サー
バ８５で受信され、ＵＤＰ要求パケット３００に内包化
される。ＵＤＰ要求パケット３００は、プロキシ・エー
ジェント７９の専用ポート１９０に向けて、送信され
る。

【００５６】プロキシ・エージェント７９は、専用ポー
ト１９０で受信されたパケットには、ＩＣＭＰエコーリ
クエストパケットが内包化されていることを知っている
ので、前記ＩＣＭＰエコーリクエストパケットを取り出
し、その中に指定されているＩＰアドレスから、非ＩＰ
機器３１を選択し、非ＩＰ機器ドライバ７４を介して非
ＩＰ機器対応のプロトコルで要求メッセージ２２０を送
信する。非ＩＰ機器３１が一定時間内に変更メッセージ
２３０を返してくれば、通信が正常にできているので、
ＩＣＭＰエコーリプライパケットを作成し、これをＵＤ
Ｐ返答パケット３３０に内包化して、ＩＣＭＰ・ＵＤＰ
変換サーバ８５の特定のポートに送る。

【００５７】ＩＣＭＰ・ＵＤＰ変換サーバ８５は、前記
ポートで受信されるパケットには、ＩＣＭＰエコーリプ
ライパケットが内包化されていることを知っているの
で、これを取り出し、ネットワーク管理アプリケーショ
ン６１に向けて、送信する。ネットワーク管理アプリケ
ーション６１は、あたかも非ＩＰ機器３１に割り当てら
れた架空のＩＰアドレスから、ＩＣＭＰエコーリプライ
パケットがあったものとして受信する。

【００５８】以上にこの発明を具体的な実施例を用いて
説明したが、この発明はこのような実施例に限定される
ものではない。

【００５９】

【発明の効果】請求項１記載の発明および請求項２記載
の発明によると、同じネットワーク管理アプリケーショ
ンで、ＩＰ機器と非ＩＰ機器を一元管理することができ
る。

【００６０】請求項３記載の発明によると、インターネ
ットで標準であるＩＣＭＰ（代表的にはpingコマンド）
を使って、非ＩＰ機器との通信状況を簡単に確認するこ
とができる。

【図面の簡単な説明】

【図１】従来例の構成を示す図。

【図２】この発明の一実施形態の構成を示す図。

【図３】図２の発明のプロキシ・エージェントの内部構
成を示す図。

【図４】この発明のもう一つの実施形態の構成を示す
図。

【図５】図４の実施形態のプロキシ・エージェントの内
部構成を示す図。

【図６】図４の実施形態における要求パケットと返答パ
ケットの伝送を示す図。

【図７】図４の実施形態におけるトラップパケットの伝
送を示す図。

【図８】この発明のさらに別の実施形態の構成を示す
図。

【図９】図８の実施形態のプロキシ・エージェントの内
部構成を示す図。

【図１０】図８の実施形態におけるパケットの伝送を示
す図。

【符号の説明】

１０、２０：ＩＰ機器 ３０、４０、５０：非ＩＰ機器 ６１：ネットワーク管理アプリケーション ７０、７８、７９：プロキシ・エージェント ７１、７２、７３：ソケット ７４：非ＩＰ機器ドライバ ７５：ＩＣＭＰ用ソケット ８０：アドレス・ポート変換サーバ ８５：ＩＣＭＰ・ＵＤＰ変換サーバ ９０：ホスト １００：ネットワークインターフェース・カード １１０、１２０、１３０：論理アドレス １４０、１６０、１７０、１８０：ポート １５０：ＩＰアドレス ２００：変換前要求パケット ２１０：変換後要求パケット ２２０：非ＩＰ要求メッセージ ２３０：非ＩＰ返答メッセージ ２４０：変換前返答パケット ２５０：変換後返答パケット ２６０：非ＩＰイベント通知メッセージ ２７０：変換前トラップパケット ２８０：変換後トラップパケット ２９０：ＩＣＭＰエコーリクエストパケット ３００：ＵＤＰ要求パケット ３３０：ＵＤＰ返答パケット ３４０：ＩＣＭＰエコーリプライパケット

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5K030 GA14 GA17 HC01 HD01 JA05 JA10 MA01 5K033 AA09 BA08 CC01 DA05 5K048 AA00 BA21 BA31 DA02 EA14 EB01 EB03 HA01 HA02 9A001 CC03 CC07 JJ25 KK56 LL09

Claims (3)

【特許請求の範囲】
1. 【請求項１】インターネットプロトコルで通信を行うこ
   とができない遠隔機器を、見かけ上インターネットプロ
   トコルで管理するための管理システムであって、 前記遠隔機器に対応する数の論理ＩＰアドレスを割り当
   てられ、インターネットプロトコルで運用されるネット
   ワークに接続されたネットワークインタフェース・カー
   ドと、 複数の前記論理ＩＰアドレスに対応する複数のソケット
   を有し、該ソケットの１つが前記ネットワークから要求
   パケットを受信することに応答して当該ソケットに対応
   する前記遠隔機器に前記要求パケットの内容を該遠隔機
   器対応のプロトコルで転送する管理部とを備える管理シ
   ステム。
2. 【請求項２】インターネットプロトコルで通信を行うこ
   とができない遠隔機器を、見かけ上インターネットプロ
   トコルで管理するための管理システムであって、 前記遠隔機器にはそれぞれ固有の架空ＩＰアドレスが割
   り当てられており、 ＩＰアドレスを持ち、前記遠隔機器に対応するポート番
   号の複数のポートを有するネットワークインターフェー
   スと、前記複数のポートに対応する複数のソケットを有
   し、該ソケットの１つにパケットが受信されることに応
   答して、該ソケットに対応する前記遠隔機器に該パケッ
   トの内容を該遠隔機器対応のプロトコルで転送する管理
   部と、 前記遠隔機器に固有の架空ＩＰアドレスを宛先ＩＰアド
   レスとする要求パケットを受信することに応答して、該
   要求パケットのＩＰヘッダに含まれる宛先ＩＰアドレス
   および宛先ポートを前記ホストのＩＰアドレス、および
   対応する前記遠隔機器の前記ポート番号に変更して変更
   後のパケットを送信する変換サーバと、 を有する管理システム。
3. 【請求項３】インターネットプロトコルで通信を行うこ
   とができない遠隔機器を、見かけ上、インターネットプ
   ロトコルで管理するための管理システムであって、 前記遠隔機器にはそれぞれ固有の架空ＩＰアドレスが割
   り当てられており、 前記遠隔機器対応のプロトコルによって該遠隔機器と通
   信することができるホストと、 任意のパケットを受け取ることができるソケットを用い
   て、前記遠隔機器に割り当てられた架空ＩＰアドレスに
   対するＩＣＭＰエコーリクエストパケットを受信し、前
   記ＩＣＭＰエコーリクエストパケットをユーザデータグ
   ラム・パケットに内包化して送信するＩＣＭＰ・ＵＤＰ
   変換サーバとを備え、 前記ホストは、前記送信されたユーザデータグラム・パ
   ケットを受信し、内包化されている前記ＩＣＭＰエコー
   リクエストパケットに応答して、前記遠隔機器対応のプ
   ロトコルを用いて、このパケット中で指定されている前
   記架空ＩＰアドレスに対応する前記遠隔機器と通信を行
   うようにした管理システム。