ＡＴＭ用サーバのＭＩＢ統合管理方法
【課題】 ＡＴＭスイッチ本体のＣＰＵ処理にかかる負荷を低減させ、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限に抑える。
【解決手段】 同一ＡＴＭスイッチ装置内に複数のサーバを搭載し、ネットワーク管理システム(ＮＭＳ)１１からＡＴＭスイッチ１２に対してＳＮＭＰ手順によって、サーバの管理情報ベースにアクセスする場合において、複数のサーバの中の一つをマスターサーバ１３、その他をスレーブサーバ１４ａ、１４ｂ・・・に設定し、ＡＴＭスイッチ１２からＳＮＭＰ手順によってマスターサーバに対して代表してアクセスし、マスターサーバからその他のスレーブサーバへはＶＣ（仮想コネクション）にてアクセスする。ＡＴＭスイッチとマスターサーバ間の通信にはＰＶＣを用い、マスターサーバとスレーブサーバとの通信にはＳＶＣを用いる。
【解決手段】 同一ＡＴＭスイッチ装置内に複数のサーバを搭載し、ネットワーク管理システム(ＮＭＳ)１１からＡＴＭスイッチ１２に対してＳＮＭＰ手順によって、サーバの管理情報ベースにアクセスする場合において、複数のサーバの中の一つをマスターサーバ１３、その他をスレーブサーバ１４ａ、１４ｂ・・・に設定し、ＡＴＭスイッチ１２からＳＮＭＰ手順によってマスターサーバに対して代表してアクセスし、マスターサーバからその他のスレーブサーバへはＶＣ（仮想コネクション）にてアクセスする。ＡＴＭスイッチとマスターサーバ間の通信にはＰＶＣを用い、マスターサーバとスレーブサーバとの通信にはＳＶＣを用いる。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、非同期転送モード（Asynchronous Transfer Mode：以下「ＡＴＭ」と記す）ネットワークを利用して、ＡＴＭセルを送受信する装置において、複数のＡＴＭ通信用サーバに備えられたＭＩＢ（Management Information Base）を統合的に管理する方法に関するものである。
【０００２】
【従来の技術】従来技術には、次のような問題点があった。第１の問題点は、同一ＡＴＭスイッチ装置内に、様々なＡＴＭ通信用サーバモジュールを搭載する環境において、ＡＴＭスイッチ本体がすべてのサーバモジュールとの間でSimple Network Management Protocol（ＳＮＭＰ）通信を行うと、ＡＴＭスイッチ本体のＣＰＵの処理に高負荷がかかってしまい、ＳＮＭＰ以外の他の処理に悪影響を与えてしまう点である。
【０００３】第２の問題点は、同一ＡＴＭスイッチ装置内に、様々なＡＴＭ通信用サーバモジュールを搭載する環境において、ＡＴＭスイッチ本体のＣＰＵとサーバのＣＰＵの間のＳＮＭＰ通信に、ローカルプロセッサ通信を用いると、ローカルプロセッサ通信にかかるトラフィックの負荷が増大し、ＳＮＭＰ通信以上に重要な通信、例えば実装状態管理や装置障害管理の通信に悪影響を与える点である。
【０００４】第３の問題点は、仮に上記の第２の問題点が解決され、仮想コネクション（Virtual Connection：以下「ＶＣ」と記す）通信によりＳＮＭＰ通信を行う場合にしても、すべてのＶＣを相手固定接続（Permanent Virtual Connection：以下「ＰＶＣ」と記す）にしてしまうと、常時必要なＶＣリソースが消費され、リソースの無駄が多いという点である。
【０００５】第４の問題点は、ＡＴＭスイッチにＳＮＭＰインタフェースが実装され、サーバモジュールにＭＩＢ取得インタフェースが実装されることで、サーバモジュールのアプリケーションＭＩＢに追加／変更が行われる度に、ＡＴＭスイッチのＳＮＭＰインタフェースにも追加／変更が必要となる密結合システムであった点である。
【０００６】一方、特開平７−２２６７７７号公報及び特開平７−３１９７９３号公報には、階層的にネットワークを管理する方法として、統合マネージャとサブマネージャとエージェントとをネットワーク上に別装置として分散配置し、マネージャとエージェント間の通信をＳＮＭＰにて行う方法が開示されているが、これは、ＳＮＭＰを用いてはいるが、ネットワークを介して外部装置間でＳＮＭＰ通信を行うものである。
【０００７】
【発明が解決しようとする課題】本発明は、同一ＡＴＭスイッチ装置内に複数のサーバを搭載し、ネットワーク管理システムからＡＴＭスイッチに対してＳＮＭＰ手順によって、サーバの管理情報ベースにアクセスする場合において、ＡＴＭスイッチ本体のＣＰＵ処理にかかる負荷を低減させ、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限に抑えることを目的とする。
【０００８】
【課題を解決するための手段】本発明は、同一ＡＴＭスイッチ装置内に複数のサーバを搭載し、ネットワーク管理システム(Network Management System：以下「ＮＭＳ」と記す)からＡＴＭスイッチに対してＳＮＭＰ手順によって、サーバのＭＩＢ（Management Information Base）にアクセスする方法において、複数のサーバの中の一つをマスターサーバ、その他をスレーブサーバに設定し、ＡＴＭスイッチからＳＮＭＰ手順によってマスターサーバに対して代表してアクセスし、マスターサーバからその他のスレーブサーバへはＶＣにてアクセスすることを特徴とする。
【０００９】ＡＴＭスイッチとマスターサーバ間のＳＮＭＰ通信はＶＣにて行う。この場合、ＡＴＭスイッチとマスターサーバ間の通信にはＰＶＣ（Permanent Virtual Connection）を用い、マスターサーバとスレーブサーバとの通信にはＳＶＣ（Switched Virtual Connection）を用いる。
【００１０】マスターサーバとスレーブサーバとのＳＶＣによるセットアップにおいて、スレーブサーバがタイマを起動させてその設定時間にてリトライする。
【００１１】マスターサーバにおいて、スレーブサーバの管理にインデックス情報を用い、マスター・スレーブ間でインデックス更新通知／応答を行う。インデックス収集フェーズにおいては、スレーブサーバからマスターサーバへのインデックス更新の際に、応答のタイムアウト監視を行う。インデックス更新応答がタイムアウトした場合は、インデックス更新通知の再送処理を行う。
【００１２】ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチ本体がマスターサーバと通信する際に、Get/Set共通関数を用いて、ＭＩＢグループ単位で通信する。また、ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチとマスターサーバ間、およびマスターサーバとスレーブサーバ間で、Get/Set応答のタイムアウト監視を行う。
【００１３】マスターサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してスレーブサーバに伝え、マスター・スレーブ動作を停止する。また、スレーブサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してマスターサーバに伝え、マスターサーバが管理しているスレーブインデックス番号の登録を削除する。
【００１４】本発明の特徴を図を参照して概説すると、図２において、ＮＭＳ１１からＡＴＭスイッチ１２に対して、Simple Network Management Protocol（ＳＮＭＰ）の手順によって、サーバのＭＩＢへのアクセス（Ｓ２１）が行われる場合に、ＡＴＭスイッチ１２から配下の全てのサーバへＳＮＭＰアクセスするのではなく、マスターサーバ１３に対して代表してアクセス（Ｓ２２）し、マスターサーバ１３からその他のスレーブサーバ１４へアクセスする。また、ＡＴＭスイッチ１２とマスターサーバ１３間、および、マスターサーバ１３とスレーブサーバ１４間のＳＮＭＰ通信には、図４の４Ｂ、４Ｄ、図５の５Ｃ、５Ｆに示す通り、ＶＣによる接続を用い、ＡＴＭスイッチ１２とサーバのローカルプロセッサ間通信を使用しない。
【００１５】これにより、ＡＴＭスイッチ本体にかかる負荷が低減し、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限にとどめることが可能となる。
【００１６】
【発明の実施の形態】以下、本発明の実施例を図面により説明する。図１は、本発明の前提となる機器構成例を示している。本構成例は、ネットワーク管理システム(Network Management System：以下「ＮＭＳ」と記す)１１と、ＡＴＭスイッチ１２と、複数のＡＴＭ通信用サーバとを含む。このＡＴＭ通信用サーバは、ＭＩＢ（Management Information Base）管理上の役割に応じてマスターサーバ１３と、スレーブサーバ１４に分類でき、複数あるスレーブサーバはそれぞれ１４ａ〜１４ｄとして表してある。
【００１７】ＮＭＳ１１は、ＳＮＭＰ（Simple Network Management Protocol）の手順によって、ＡＴＭスイッチ１２とサーバ１３、１４に搭載されているＭＩＢにアクセスし、管理用のデータを書き込んだり、読み出したりする。サーバ１３、１４はＡＴＭスイッチ１２の装置内に搭載され、ＮＭＳ１１からサーバ１３、１４へのアクセスは全て、ＡＴＭスイッチ本体１２のＳＮＭＰインタフェース経由で行われる。
【００１８】ここで、ＡＴＭ通信用サーバの種類は本発明で規定するところではないが、下記のようなものを想定している。
(1) ATM Forum "LAN Emulatin Over ATM Version 2" (AF-LANE-0084.000）
LAN Emulation Server（ＬＥＳ）
LAN Emulation Configuration Server（ＬＥＣＳ）
Broadcast and Unknown Server（ＢＵＳ)(2) ATM Forum "Multi-Protocol Over ATM Version 1.0" (MPOA: AF-MPOA-0087.000)MPOA Server（ＭＰＳ）
Next Hop Server（ＮＨＳ）
(3) IETF "Classical IP and ARP over ATM" (RFC1577)ARP Server
【００１９】この他、ＡＴＭ通信を実現するための、クライアント・サーバ方式における「サーバ」は全て本発明の適用範囲内とする。
【００２０】次に、図２を用いて、各構成機器間のＳＮＭＰ通信の概要について説明する。ＮＭＳ１１からサーバのＭＩＢに対してＳＮＭＰの手順によるアクセスをする際、ＭＩＢに対するデータ読み出しはGet Request、データ書き込みはSet Requestメッセージ（Ｓ２１）を、まずＡＴＭスイッチ１２に対して送信する。ＡＴＭスイッチ１２は、この要求をマスターサーバ１３に転送する（Ｓ２２）。要求を受信したマスターサーバ１３は、第１のスレーブサーバ（１４ａ）に対してGet/Set Request（Ｓ２３）を送信し、返答としてGet/Set Response（Ｓ２４）を受信する。
【００２１】続いてマスターサーバ１３から、第２のスレーブサーバ（１４ｂ）に対してGet/Set Request（Ｓ２５）を送信し、返答としてGet/Set Response（Ｓ２６）を受信する。この際、ＡＴＭスイッチ本体１２とスレーブサーバ１４の間でＳＮＭＰメッセージを直接やりとりすることはない。スレーブサーバ１４の返答をすべて受信したマスターサーバ１３は、その返答をまとめてＡＴＭスイッチ１２へ送信し（Ｓ２７）、最終的にＮＭＳ１１へ送信される（Ｓ２８）。
【００２２】マスターサーバ１３とスレーブサーバ１４の間の通信は、ＡＴＭスイッチ本体１２の情報処理能力に影響を与えないために、ＶＣ（Virtual Connection）による通信を採用する。また、サーバの搭載状況やモジュール数は変動するため、あらかじめＶＣを固定的に設定しておくことはできない。
【００２３】したがって、ＳＶＣ（Switched Virtual Connection）により、サーバ間の通信の必要性に応じてＶＣを確保する。サーバ間でＳＶＣを設定するためには、ＡＴＭシグナリング手順（ATM Forum "ATM User-Network Specification Version3.1"他）を用いる必要があり、そのために、マスターサーバ１３とスレーブサーバ１４にそれぞれシグナリング終端用のＡＴＭアドレスを割り当てなければならない。
【００２４】図３は、マスターサーバ１３とスレーブサーバ１４に対するＡＴＭアドレスの割当て方法を表している。管理コマンドによって「マスター設定」をサーバに対して行うと、図３(a)のように、Network Prefix（ＮＰ）部はＡＴＭスイッチと同様の１３バイト、End System Identifier（ＥＳＩ）部は製造者識別番号４バイト＋"ffff"固定の計６バイト、セレクタ（ＳＥＬ）部は"ff"固定１バイトをそれぞれ割り当てる。これに対し、管理コマンドによって「スレーブ設定」をサーバに対して行うと、図３（ｂ）のように、ＮＰ部はＡＴＭスイッチおよびマスター設定と同様の１３バイト、ＥＳＩ部はサーバのハードウェア固有のＭＡＣアドレス（IEEE LAN SpecificationsのMedia Access Control protocol）６バイト、ＳＥＬはＡＴＭスイッチ装置内における該当サーバの実装位置（スロット番号やモジュール番号など）１バイトを割り当てる。
【００２５】マスターサーバ１３のＡＴＭアドレスは、スレーブサーバ１４から見ると固定的に決定しているため、シグナリング手順はスレーブサーバ１４側からのＳＥＴＵＰ要求で始まる。また、スレーブサーバ１４が複数モジュール存在しても、ＭＡＣアドレスと実装位置がユニークに割り当てられているため、同一ＡＴＭアドレスが割り当てられることがない仕組みである。マスターサーバ１３における全スレーブサーバ１４のＭＩＢの一元管理は、このＳＶＣによる１対多の双方向通信により実現される。
【００２６】以上のように、マスターサーバ１３が、全スレーブサーバ１４のＭＩＢ管理を、統合的に行えるような構成になっている。
【００２７】次に、図面を参照して本実施例の動作について詳細に説明する。
1. 初期化フェーズ初期化フェーズでは、ＡＴＭスイッチ本体１２とマスターサーバ１３間、マスターサーバ１３とスレーブサーバ１４間のＶＣを確立し、それぞれの間でＳＮＭＰ通信を行うための準備をする。
【００２８】1.1 コマンド設定による初期化図４を用いて説明する。いま、ＡＴＭスイッチ１２にサーバが２つ搭載されており、一方をマスターサーバ１３、他方をスレーブサーバ１４として設定する。管理者がコマンドによって「ＭＡＳＴＥＲ設定」を行うと、その設定がマスターサーバ１３の設定データ（実装位置情報）としてＡＴＭスイッチ本体１２に保存される（４Ａ）。この設定データを以下「局データ」と呼ぶ。局データが設定されると、ＡＴＭスイッチ１２からマスターサーバ１３に対して、プロセス間通信でＭＡＳＴＥＲ指示（Ｓ４１）が送信され、マスターサーバ１３は自身がマスターとして動作することを知る。その後、ＡＴＭスイッチ１２とマスターサーバ１３間にＰＶＣ（Permanent Virtual Connection）（４Ｂ）を確立し、ＳＮＭＰ通信に備える。
【００２９】その後、マスターサーバ１３は、図３（ａ）で示した自身のＡＴＭアドレスを、ＡＴＭスイッチ１２にダイナミックルーティング登録（Ｓ４２）する。このダイナミックルーティング情報は、後程スレーブ側からＳＶＣ（Switched VirtualConnection）確立のためのＳＥＴＵＰメッセージをマスター側へ転送するために必要となる。この時点でマスターサーバ１３は、スレーブサーバ１４からのＳＥＴＵＰ待ちとなる。
【００３０】管理者がコマンドによって「ＳＬＡＶＥ設定」を行うと、その設定がスレーブサーバ１４の局データ（実装位置情報）としてＡＴＭスイッチ本体１２に保存され（４Ｃ）、プロセス間通信でＳＬＡＶＥ指示（Ｓ４３）がスレーブサーバ１４へ送信される。ＳＬＡＶＥ指示を受けたスレーブサーバ１４では、ＡＴＭスイッチ１２経由でマスターサーバ１３へＴ１[sec]周期でＳＥＴＵＰを送信（Ｓ４４）し、マスターサーバ１３へＳＶＣを確立できるまで再試行（Ｓ４７）する。
【００３１】スレーブサーバ１４は、図３（ｂ）で示したＡＴＭアドレスを用い、マスターサーバ１３の宛先ＡＴＭアドレスに対してダイナミックルーティングによってＳＥＴＵＰが送信される。ＳＶＣ確立のシグナリング手順に成功すると、マスターサーバ１３に対してConnect Indication（Ｓ４５）を通知し、ＳＶＣ要求元のスレーブサーバ１４に対してSet Response(OK)（Ｓ４６）を返送することにより、ＳＶＣが確立する（４Ｄ）。
【００３２】1.2 Power-On再開、またはサーバ挿入による初期化図５を用いて、ＡＴＭスイッチ装置全体の電源投入時や、ＡＴＭスイッチ運用中のサーバモジュール挿入の初期化処理を説明する。
【００３３】マスターサーバ１３が起動し、再開処理（５Ａ）が完了すると、ＡＴＭスイッチ１２に対してＵＰ通知（Ｓ５１）を行う。ＡＴＭスイッチ１２は、ＵＰ通知送信元のサーバの局データを展開し（５Ｂ）、マスターサーバ１３であることがわかると、ＭＡＳＴＥＲ指示（Ｓ５２）を行う。以下は「コマンド設定による初期化」と同様に、ＰＶＣ確立（５Ｃ）とダイナミックルーティング登録（Ｓ５３）が行われる。
【００３４】同様に、スレーブサーバ１４が起動し、再開処理（５Ｄ）が完了すると、ＡＴＭスイッチ１２に対してＵＰ通知（Ｓ５４）を行う。ＡＴＭスイッチ１２は、ＵＰ通知送信元のサーバの局データを展開し（５Ｅ）、スレーブサーバ１４であることがわかると、ＳＬＡＶＥ指示（Ｓ５５）を行う。以下は「コマンド設定による初期化」と同様に、ＳＥＴＵＰ（Ｓ５６）、Connect Indication（Ｓ５７）、Set Response(OK)（Ｓ５８）のやりとりを経て、ＳＶＣが確立される（５Ｆ）。
【００３５】なお、サーバ起動時に、マスターとスレーブの局データ設定がまだ存在しない場合には、管理者によるコマンド入力によって初めて、図４と同様の初期化処理が行われる。
【００３６】2. インデックス収集フェーズマスターサーバ１３は、その管理下にある全てのスレーブサーバ１４のインデックスを管理する。図６のように、スレーブサーバ１４上のアプリケーション（以下「ＡＰＬ」と記す）に対するコマンド投入による設定データ追加／削除や、ＡＰＬ動作にともなう状態遷移によるＭＩＢの追加／削除時には、マスターサーバ１３へインデックス更新通知（Ｓ６１）し、同期させる必要がある。インデックス更新通知を受けたマスターサーバ１３はインデックス更新（６Ａ）し、スレーブサーバ１４へインデックス更新応答（Ｓ６２）を返す。
【００３７】図７は、スレーブサーバ１４に、LAN Emulation Server（ＬＥＳ）が搭載されているときの例である。スロット番号５と２にスレーブサーバモジュールが搭載されており、２つのモジュール上にＬＥＳのＭＩＢエントリ"lesConfEntry"が合計５個存在する。これら５個のＭＩＢに対して、インデックス番号１〜５が割り当てられている。
【００３８】2.1 再開時のインデックス更新図８を用いて、スレーブサーバ再開時のインデックス更新について説明する。ここでは、動作説明のため、スレーブサーバ１４をスレーブタスク１５とＡＰＬ１６に分ける。スレーブサーバ１４が再開（８Ａ）すると、スレーブタスク１５からＡＰＬ１６に対してインデックス通知要求（Ｓ８１）を送る。ＡＰＬ１６は、この後インデックス更新が完了するまで、ＭＩＢ登録／削除処理ルーチン（８Ｂ）に入る。ＡＰＬ１６からスレーブタスク１５にインデックス通知（Ｓ８２）が送られると、スレーブタスク１５はフレーム生成（８Ｃ）を行い、マスターサーバ１３へインデックス更新通知（Ｓ８３）を送る。マスターサーバ１３でインデックス更新が完了すると、スレーブタスク１５に対してインデックス更新応答（Ｓ８４）を送信し、さらにスレーブタスク１５からＡＰＬ１６へＲＥＴＵＲＮ（Ｓ８５）が送られる。
【００３９】Ｓ８２からＳ８５までの処理は、ＡＰＬ１６上に存在する全インデックス番号分繰り返し処理され、完了すると、ＭＩＢ登録／削除処理ルーチン（８Ｂ）が終了する。
【００４０】2.2 ＡＰＬコマンドによるインデックス更新図９を用いて、ＡＰＬコマンドによるインデックス更新について説明する。スレーブサーバ１４のＡＰＬ１６に対して、管理者がコマンド入力により設定追加／削除（Ｓ９１）を行うと、ＭＩＢ登録／削除処理ルーチン（９Ａ）が起動する。この後は、前述した図８の８Ｂ以降の処理と同様にインデックス更新が行われる。（図９の９Ａ、Ｓ９２〜Ｓ９５）
【００４１】2.3 ＡＰＬ状態遷移によるインデックス更新図１０を用いて、ＡＰＬ状態遷移によるインデックス更新について説明する。スレーブサーバ再開や、ＡＰＬコマンド入力以外の要因により、スレーブサーバ１４のＡＰＬ１６の状態に変化が起こり、スレーブサーバ登録状態を更新する必要がある場合は、この処理が行われる。ＡＰＬ１６の状態が遷移（１０Ａ）すると、ＭＩＢ登録／削除処理ルーチン（１０Ｂ）が起動する。この後は、図８の８Ｂ以降および図９の９Ａ以降の処理と同様にインデックス更新が行われる。（図１０の１０Ｂ、Ｓ１０１〜Ｓ１０４）
【００４２】2.4 インデックス更新タイマー監視スレーブサーバ１４がマスターサーバ１３に対して、インデックス更新通知を送信すると、インデックス更新応答が返送されてくるまで、スレーブサーバ１４のスレーブタスク１５は応答待機状態となる。インデックス更新通知の時点からある特定時間経っても更新応答がない場合は、マスター側の障害と判断できるように、タイムアウト監視処理を設ける。
【００４３】2.4.1 正常処理図１１を用いて、インデックス更新タイマー監視の正常処理について説明する。スレーブタスク１５が、ＡＰＬ１６からインデックス通知（Ｓ１１１）を受信すると、スレーブタスク１５上では、スレーブタスク処理（１１Ａ）が起動する。インデックス更新フェーズで説明した通り、スレーブタスク１５は、フレーム生成（１１Ｂ）を行い、マスターサーバ１３にインデックス更新通知（Ｓ１１２）を行う。スレーブタスク１５上では、タイムアウト監視（１１Ｃ）がスタートし、規定時間Ｔ２[sec]内にインデックス更新応答（Ｓ１１３）が受信できるか監視する。受信すると、インデックス更新が正常に処理されたとみなし、タイムアウト監視（１１Ｃ）を解除し、ＡＰＬ１６に対してＲＥＴＵＲＮ（Ｓ１１４）を送信する。
【００４４】2.4.2 タイムアウト処理図１２を用いて、インデックス更新タイマー監視のタイムアウト処理について説明する。正常処理の時と同様、スレーブタスク１５が、ＡＰＬ１６からインデックス通知（Ｓ１２１）を受信すると、スレーブタスク処理（１２Ａ）が起動し、フレーム生成（１２Ｂ）を行い、マスターサーバ１３にインデックス更新通知（Ｓ１２２）を行う。スレーブタスク１５上では、タイムアウト監視（１２Ｃ）がスタートし、規定時間Ｔ２[sec]内にインデックス更新応答が受信できるか監視する。Ｔ２[sec]経過後、更新応答未受信であれば、再送処理（１２Ｄ）を行い、インデックス更新通知を再送（Ｓ１２３）する。再送は決められた回数ｎ回行われる。
【００４５】なお、最終回の再送後Ｔ２[sec]経過しても更新応答が受信できない場合は、マスターサーバ１３において何らかの障害や処理遅延が発生したものとみなし、ＡＰＬ１６へタイムアウトのＲＥＴＵＲＮ（Ｓ１２４）を送信し、ＡＰＬ１６に対してインデックス更新が失敗したことを通知する。この時点でタイムアウト監視（１２Ｃ）を解除する。
【００４６】タイムアウト監視解除後に、Ｓ１２５のようにインデックス更新応答を受信した場合は、無効とみなされ、スレーブタスク１５においてフレームが破棄される。
【００４７】3. ＳＮＭＰ動作フェーズＮＭＳ１１、ＡＴＭスイッチ本体１２、マスターサーバ１３、スレーブサーバ１４それぞれの間のメッセージのやりとりは、ＳＮＭＰのプロトコルに従って行われる。以下でＳＮＭＰ動作フェーズの正常処理とタイムアウト処理の説明を行う。
【００４８】3.1 正常処理図１３を用いて、ＳＮＭＰ動作フェーズの正常処理について説明する。ＡＴＭスイッチ１２では、ＳＮＭＰエージェントが管理している管理オブジェクトのインスタンス値に対するGet要求やSet要求（Ｓ１３１）がＮＭＳ１１からあった場合、Get/Set共通関数（１３Ａ）において、VarBind毎にマスターサーバ１３に対してオブジェクト値のGet/Set要求（Ｓ１３２）を行う。マスターサーバ１３においては、ＡＴＭスイッチ本体１２とは別に、独自のGet/Set要求関数（１３Ｂ）を持っている。
【００４９】以下、図１３中のＡＴＭスイッチ１２、マスターサーバ１３、スレーブサーバ１４それぞれの間のGet/Set要求／応答について説明する。なお、初期化フェーズで説明した通り、ＡＴＭスイッチ１２とマスターサーバ１３間の通信はＰＶＣを用い、マスターサーバ１３とスレーブサーバ１４間の通信はＳＶＣを用いる。
【００５０】（１）ＡＴＭスイッチからマスターサーバへ（Ｓ１３２）
ＡＴＭスイッチ１２でデコードされたGet/Set要求（Ｓ１３１）は、OID, OID長, offsetなどの情報全てをフレーム化し、ＰＶＣを通じてマスターサーバ１３へ送信（Ｓ１３２）される。このGet/Set要求（Ｓ１３２）は、ＭＩＢグループ単位で行われたものが送信される。ここで、「ＭＩＢグループ単位」とは、例えばＬＡＮエミュレーションの場合、atmfLanEmulationツリー配下では、leClientMIB/elanMIB/lesMIB/busMIB単位で共通Get/Setインターフェースを用意することを意味する。
【００５１】（２）マスターサーバからスレーブサーバへ（Ｓ１３３）
Get/Set要求（Ｓ１３２）のフレームを受信したマスターサーバ１３では、Get/Set要求関数（１３Ｂ）において、OIDを内部IDに変換し、インデックステーブルを検索する。これにより、要求OIDを持つスレーブサーバ１４の実装位置（スロット番号）が判明し、該当スレーブサーバ１４へＳＶＣで、ＭＩＢのGet/Set要求（Ｓ１３３）を送信する。
【００５２】（３）スレーブサーバからマスターサーバへ（Ｓ１３４）
Get/Set要求（Ｓ１３３）を受信したスレーブサーバ１４では、ＡＰＬ１６のＭＩＢ取得/設定処理（図１０の１０Ｂを参照）操作を行ない、取得データ/設定状態などの応答情報をＳＶＣでマスターサーバ１３へGet/Set応答（Ｓ１３４）として送信する。マスターサーバ１３では、Get/Set要求（Ｓ１３３）からGet/Set応答（Ｓ１３４）までの間、Ｔ３[sec]のタイムアウト監視を行う。
【００５３】（４）マスターサーバからＡＴＭスイッチへ（Ｓ１３５）
スレーブサーバ１４からのGet/Set応答（Ｓ１３５）をマスターサーバ１３が受信すると、内部ID/OID変換を行うのみで応答情報をGet/Set応答（Ｓ１３５）としてＰＶＣを通じてＡＴＭスイッチ１２へ返信する。ＡＴＭスイッチ１２ではGet/Set要求（Ｓ１３２）からGet/Set応答（Ｓ１３５）までの間、Ｔ４[sec]のタイムアウト監視を行う。マスターサーバ１３からの応答が規定時間Ｔ４[sec]内に返ってくれば、ＮＭＳ１１にGet/Set応答（Ｓ１３６）として正常に値を返却する。
【００５４】3.2 タイムアウト処理図１４のように、ＡＴＭスイッチ１２がマスターサーバ１３へGet/Set要求（Ｓ１４２）を送信してから、規定時間Ｔ４[sec]内にマスターサーバ１３からのGet/Set応答が受信できない場合は、Get/Set共通関数（１４Ａ）においてタイムアウトと判断し、ＮＭＳ１１へエラー（Ｓ１４６）を返却する。タイムアウト後に応答（Ｓ１４５）が返ってきた場合は、ＡＴＭスイッチ１２のGet/Set共通関数で破棄する。
【００５５】同様に、図１５のように、マスターサーバ１３がスレーブサーバ１４へGet/Set要求（Ｓ１５３）を送信してから、規定時間Ｔ３[sec]内にスレーブサーバ１４からのGet/Set応答が受信できない場合は、Get/Set要求関数（１５Ｂ）においてタイムアウトと判断し、ＡＴＭスイッチ１２へエラー（Ｓ１５５）を返却する。タイムアウト後に応答（Ｓ１５４）が返ってきた場合は、マスターサーバ１３のGet/Set要求関数で破棄する。
【００５６】4. 障害処理4.1 マスターサーバ障害時図１６のように、マスターサーバ１３において障害が発生（Ｓ１６１）した場合、ＡＴＭスイッチ本体１２において、ＳＳＣＯＰ断（リンク断）を検知し、さらに装置管理処理により障害認識される（１６Ａ）。その後、ＡＴＭスイッチ１２からスレーブサーバ１４へDelete Indication（Ｓ１６２）が通知され、マスタースレーブ動作が停止する。
【００５７】4.2 スレーブサーバ障害時図１７のように、スレーブサーバ１４において障害が発生（Ｓ１７１）した場合、ＡＴＭスイッチ本体１２において、ＳＳＣＯＰ断（リンク断）を検知し、さらに装置管理処理により障害認識される（１７Ａ）。その後、ＡＴＭスイッチ１２からマスターサーバ１３へDelete Indication（Ｓ１７２）が通知され、マスターサーバ１３はスレーブインデックス登録を削除する（１７Ｂ）。
【００５８】
【発明の効果】本発明の第１の効果は、すべてのスレーブサーバとのＳＮＭＰ（Simple Network Management Protocol）通信を、マスターサーバにまかせることにより、ＡＴＭスイッチ本体のＣＰＵ処理にかかる負荷が低減し、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限にとどめることが可能となる点である。
【００５９】第２の効果は、ＡＴＭスイッチ本体−マスターサーバ−スレーブサーバの間のＳＮＭＰ通信において、ローカルプロセッサ間通信を使用せず、ＶＣ接続による通信を用いることにより、ローカルプロセッサ間通信トラフィックを低減させることができ、ＳＮＭＰ以外の他のローカルプロセッサ間通信に与える影響を最小限にとどめることが可能となる点である。
【００６０】第３の効果は、マスターサーバとスレーブサーバの間の通信をＳＶＣ化することにより、常時ＰＶＣで接続する場合と比べ、消費リソースが最小限にとどめることが可能となる点である。
【図面の簡単な説明】
【図１】本発明の実施例の機器構成図である。
【図２】図１の各構成機器間のＳＮＭＰ通信の概要を示すシーケンスチャートである。
【図３】サーバへのＡＴＭアドレス割当て方法の解説図である。
【図４】コマンド設定による初期化のシーケンスチャートである。
【図５】Power-On再開、またはサーバ挿入による初期化のシーケンスチャートである。
【図６】インデックス収集フェーズを示すシーケンスチャートである。
【図７】LAN Emulation Serverのインデックス番号テーブルの一例を示す図である。
【図８】再開時のインデックス更新のシーケンスチャートである。
【図９】ＡＰＬコマンドによるインデックス更新のシーケンスチャートである。
【図１０】ＡＰＬ状態遷移によるインデックス更新のシーケンスチャートである。
【図１１】インデックス更新タイマー監視（正常処理）のシーケンスチャートである。
【図１２】インデックス更新タイマー監視（タイムアウト処理）のシーケンスチャートである。
【図１３】ＳＮＭＰ動作フェーズ（正常処理）のシーケンスチャートである。
【図１４】ＳＮＭＰ動作フェーズ（タイムアウト処理）のシーケンスチャートである。
【図１５】ＳＮＭＰ動作フェーズ（タイムアウト処理）の図１４とは異なるシーケンスチャートである。
【図１６】マスターサーバ障害時の動作のシーケンスチャートである。
【図１７】スレーブサーバ障害時の動作のシーケンスチャートである。
【符号の説明】
１１ ネットワーク管理システム（ＮＭＳ）
１２ ＡＴＭスイッチ
１３ マスターサーバ
１４ａ〜１４ｄ スレーブサーバ
【０００１】
【発明の属する技術分野】本発明は、非同期転送モード（Asynchronous Transfer Mode：以下「ＡＴＭ」と記す）ネットワークを利用して、ＡＴＭセルを送受信する装置において、複数のＡＴＭ通信用サーバに備えられたＭＩＢ（Management Information Base）を統合的に管理する方法に関するものである。
【０００２】
【従来の技術】従来技術には、次のような問題点があった。第１の問題点は、同一ＡＴＭスイッチ装置内に、様々なＡＴＭ通信用サーバモジュールを搭載する環境において、ＡＴＭスイッチ本体がすべてのサーバモジュールとの間でSimple Network Management Protocol（ＳＮＭＰ）通信を行うと、ＡＴＭスイッチ本体のＣＰＵの処理に高負荷がかかってしまい、ＳＮＭＰ以外の他の処理に悪影響を与えてしまう点である。
【０００３】第２の問題点は、同一ＡＴＭスイッチ装置内に、様々なＡＴＭ通信用サーバモジュールを搭載する環境において、ＡＴＭスイッチ本体のＣＰＵとサーバのＣＰＵの間のＳＮＭＰ通信に、ローカルプロセッサ通信を用いると、ローカルプロセッサ通信にかかるトラフィックの負荷が増大し、ＳＮＭＰ通信以上に重要な通信、例えば実装状態管理や装置障害管理の通信に悪影響を与える点である。
【０００４】第３の問題点は、仮に上記の第２の問題点が解決され、仮想コネクション（Virtual Connection：以下「ＶＣ」と記す）通信によりＳＮＭＰ通信を行う場合にしても、すべてのＶＣを相手固定接続（Permanent Virtual Connection：以下「ＰＶＣ」と記す）にしてしまうと、常時必要なＶＣリソースが消費され、リソースの無駄が多いという点である。
【０００５】第４の問題点は、ＡＴＭスイッチにＳＮＭＰインタフェースが実装され、サーバモジュールにＭＩＢ取得インタフェースが実装されることで、サーバモジュールのアプリケーションＭＩＢに追加／変更が行われる度に、ＡＴＭスイッチのＳＮＭＰインタフェースにも追加／変更が必要となる密結合システムであった点である。
【０００６】一方、特開平７−２２６７７７号公報及び特開平７−３１９７９３号公報には、階層的にネットワークを管理する方法として、統合マネージャとサブマネージャとエージェントとをネットワーク上に別装置として分散配置し、マネージャとエージェント間の通信をＳＮＭＰにて行う方法が開示されているが、これは、ＳＮＭＰを用いてはいるが、ネットワークを介して外部装置間でＳＮＭＰ通信を行うものである。
【０００７】
【発明が解決しようとする課題】本発明は、同一ＡＴＭスイッチ装置内に複数のサーバを搭載し、ネットワーク管理システムからＡＴＭスイッチに対してＳＮＭＰ手順によって、サーバの管理情報ベースにアクセスする場合において、ＡＴＭスイッチ本体のＣＰＵ処理にかかる負荷を低減させ、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限に抑えることを目的とする。
【０００８】
【課題を解決するための手段】本発明は、同一ＡＴＭスイッチ装置内に複数のサーバを搭載し、ネットワーク管理システム(Network Management System：以下「ＮＭＳ」と記す)からＡＴＭスイッチに対してＳＮＭＰ手順によって、サーバのＭＩＢ（Management Information Base）にアクセスする方法において、複数のサーバの中の一つをマスターサーバ、その他をスレーブサーバに設定し、ＡＴＭスイッチからＳＮＭＰ手順によってマスターサーバに対して代表してアクセスし、マスターサーバからその他のスレーブサーバへはＶＣにてアクセスすることを特徴とする。
【０００９】ＡＴＭスイッチとマスターサーバ間のＳＮＭＰ通信はＶＣにて行う。この場合、ＡＴＭスイッチとマスターサーバ間の通信にはＰＶＣ（Permanent Virtual Connection）を用い、マスターサーバとスレーブサーバとの通信にはＳＶＣ（Switched Virtual Connection）を用いる。
【００１０】マスターサーバとスレーブサーバとのＳＶＣによるセットアップにおいて、スレーブサーバがタイマを起動させてその設定時間にてリトライする。
【００１１】マスターサーバにおいて、スレーブサーバの管理にインデックス情報を用い、マスター・スレーブ間でインデックス更新通知／応答を行う。インデックス収集フェーズにおいては、スレーブサーバからマスターサーバへのインデックス更新の際に、応答のタイムアウト監視を行う。インデックス更新応答がタイムアウトした場合は、インデックス更新通知の再送処理を行う。
【００１２】ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチ本体がマスターサーバと通信する際に、Get/Set共通関数を用いて、ＭＩＢグループ単位で通信する。また、ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチとマスターサーバ間、およびマスターサーバとスレーブサーバ間で、Get/Set応答のタイムアウト監視を行う。
【００１３】マスターサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してスレーブサーバに伝え、マスター・スレーブ動作を停止する。また、スレーブサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してマスターサーバに伝え、マスターサーバが管理しているスレーブインデックス番号の登録を削除する。
【００１４】本発明の特徴を図を参照して概説すると、図２において、ＮＭＳ１１からＡＴＭスイッチ１２に対して、Simple Network Management Protocol（ＳＮＭＰ）の手順によって、サーバのＭＩＢへのアクセス（Ｓ２１）が行われる場合に、ＡＴＭスイッチ１２から配下の全てのサーバへＳＮＭＰアクセスするのではなく、マスターサーバ１３に対して代表してアクセス（Ｓ２２）し、マスターサーバ１３からその他のスレーブサーバ１４へアクセスする。また、ＡＴＭスイッチ１２とマスターサーバ１３間、および、マスターサーバ１３とスレーブサーバ１４間のＳＮＭＰ通信には、図４の４Ｂ、４Ｄ、図５の５Ｃ、５Ｆに示す通り、ＶＣによる接続を用い、ＡＴＭスイッチ１２とサーバのローカルプロセッサ間通信を使用しない。
【００１５】これにより、ＡＴＭスイッチ本体にかかる負荷が低減し、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限にとどめることが可能となる。
【００１６】
【発明の実施の形態】以下、本発明の実施例を図面により説明する。図１は、本発明の前提となる機器構成例を示している。本構成例は、ネットワーク管理システム(Network Management System：以下「ＮＭＳ」と記す)１１と、ＡＴＭスイッチ１２と、複数のＡＴＭ通信用サーバとを含む。このＡＴＭ通信用サーバは、ＭＩＢ（Management Information Base）管理上の役割に応じてマスターサーバ１３と、スレーブサーバ１４に分類でき、複数あるスレーブサーバはそれぞれ１４ａ〜１４ｄとして表してある。
【００１７】ＮＭＳ１１は、ＳＮＭＰ（Simple Network Management Protocol）の手順によって、ＡＴＭスイッチ１２とサーバ１３、１４に搭載されているＭＩＢにアクセスし、管理用のデータを書き込んだり、読み出したりする。サーバ１３、１４はＡＴＭスイッチ１２の装置内に搭載され、ＮＭＳ１１からサーバ１３、１４へのアクセスは全て、ＡＴＭスイッチ本体１２のＳＮＭＰインタフェース経由で行われる。
【００１８】ここで、ＡＴＭ通信用サーバの種類は本発明で規定するところではないが、下記のようなものを想定している。
(1) ATM Forum "LAN Emulatin Over ATM Version 2" (AF-LANE-0084.000）
LAN Emulation Server（ＬＥＳ）
LAN Emulation Configuration Server（ＬＥＣＳ）
Broadcast and Unknown Server（ＢＵＳ)(2) ATM Forum "Multi-Protocol Over ATM Version 1.0" (MPOA: AF-MPOA-0087.000)MPOA Server（ＭＰＳ）
Next Hop Server（ＮＨＳ）
(3) IETF "Classical IP and ARP over ATM" (RFC1577)ARP Server
【００１９】この他、ＡＴＭ通信を実現するための、クライアント・サーバ方式における「サーバ」は全て本発明の適用範囲内とする。
【００２０】次に、図２を用いて、各構成機器間のＳＮＭＰ通信の概要について説明する。ＮＭＳ１１からサーバのＭＩＢに対してＳＮＭＰの手順によるアクセスをする際、ＭＩＢに対するデータ読み出しはGet Request、データ書き込みはSet Requestメッセージ（Ｓ２１）を、まずＡＴＭスイッチ１２に対して送信する。ＡＴＭスイッチ１２は、この要求をマスターサーバ１３に転送する（Ｓ２２）。要求を受信したマスターサーバ１３は、第１のスレーブサーバ（１４ａ）に対してGet/Set Request（Ｓ２３）を送信し、返答としてGet/Set Response（Ｓ２４）を受信する。
【００２１】続いてマスターサーバ１３から、第２のスレーブサーバ（１４ｂ）に対してGet/Set Request（Ｓ２５）を送信し、返答としてGet/Set Response（Ｓ２６）を受信する。この際、ＡＴＭスイッチ本体１２とスレーブサーバ１４の間でＳＮＭＰメッセージを直接やりとりすることはない。スレーブサーバ１４の返答をすべて受信したマスターサーバ１３は、その返答をまとめてＡＴＭスイッチ１２へ送信し（Ｓ２７）、最終的にＮＭＳ１１へ送信される（Ｓ２８）。
【００２２】マスターサーバ１３とスレーブサーバ１４の間の通信は、ＡＴＭスイッチ本体１２の情報処理能力に影響を与えないために、ＶＣ（Virtual Connection）による通信を採用する。また、サーバの搭載状況やモジュール数は変動するため、あらかじめＶＣを固定的に設定しておくことはできない。
【００２３】したがって、ＳＶＣ（Switched Virtual Connection）により、サーバ間の通信の必要性に応じてＶＣを確保する。サーバ間でＳＶＣを設定するためには、ＡＴＭシグナリング手順（ATM Forum "ATM User-Network Specification Version3.1"他）を用いる必要があり、そのために、マスターサーバ１３とスレーブサーバ１４にそれぞれシグナリング終端用のＡＴＭアドレスを割り当てなければならない。
【００２４】図３は、マスターサーバ１３とスレーブサーバ１４に対するＡＴＭアドレスの割当て方法を表している。管理コマンドによって「マスター設定」をサーバに対して行うと、図３(a)のように、Network Prefix（ＮＰ）部はＡＴＭスイッチと同様の１３バイト、End System Identifier（ＥＳＩ）部は製造者識別番号４バイト＋"ffff"固定の計６バイト、セレクタ（ＳＥＬ）部は"ff"固定１バイトをそれぞれ割り当てる。これに対し、管理コマンドによって「スレーブ設定」をサーバに対して行うと、図３（ｂ）のように、ＮＰ部はＡＴＭスイッチおよびマスター設定と同様の１３バイト、ＥＳＩ部はサーバのハードウェア固有のＭＡＣアドレス（IEEE LAN SpecificationsのMedia Access Control protocol）６バイト、ＳＥＬはＡＴＭスイッチ装置内における該当サーバの実装位置（スロット番号やモジュール番号など）１バイトを割り当てる。
【００２５】マスターサーバ１３のＡＴＭアドレスは、スレーブサーバ１４から見ると固定的に決定しているため、シグナリング手順はスレーブサーバ１４側からのＳＥＴＵＰ要求で始まる。また、スレーブサーバ１４が複数モジュール存在しても、ＭＡＣアドレスと実装位置がユニークに割り当てられているため、同一ＡＴＭアドレスが割り当てられることがない仕組みである。マスターサーバ１３における全スレーブサーバ１４のＭＩＢの一元管理は、このＳＶＣによる１対多の双方向通信により実現される。
【００２６】以上のように、マスターサーバ１３が、全スレーブサーバ１４のＭＩＢ管理を、統合的に行えるような構成になっている。
【００２７】次に、図面を参照して本実施例の動作について詳細に説明する。
1. 初期化フェーズ初期化フェーズでは、ＡＴＭスイッチ本体１２とマスターサーバ１３間、マスターサーバ１３とスレーブサーバ１４間のＶＣを確立し、それぞれの間でＳＮＭＰ通信を行うための準備をする。
【００２８】1.1 コマンド設定による初期化図４を用いて説明する。いま、ＡＴＭスイッチ１２にサーバが２つ搭載されており、一方をマスターサーバ１３、他方をスレーブサーバ１４として設定する。管理者がコマンドによって「ＭＡＳＴＥＲ設定」を行うと、その設定がマスターサーバ１３の設定データ（実装位置情報）としてＡＴＭスイッチ本体１２に保存される（４Ａ）。この設定データを以下「局データ」と呼ぶ。局データが設定されると、ＡＴＭスイッチ１２からマスターサーバ１３に対して、プロセス間通信でＭＡＳＴＥＲ指示（Ｓ４１）が送信され、マスターサーバ１３は自身がマスターとして動作することを知る。その後、ＡＴＭスイッチ１２とマスターサーバ１３間にＰＶＣ（Permanent Virtual Connection）（４Ｂ）を確立し、ＳＮＭＰ通信に備える。
【００２９】その後、マスターサーバ１３は、図３（ａ）で示した自身のＡＴＭアドレスを、ＡＴＭスイッチ１２にダイナミックルーティング登録（Ｓ４２）する。このダイナミックルーティング情報は、後程スレーブ側からＳＶＣ（Switched VirtualConnection）確立のためのＳＥＴＵＰメッセージをマスター側へ転送するために必要となる。この時点でマスターサーバ１３は、スレーブサーバ１４からのＳＥＴＵＰ待ちとなる。
【００３０】管理者がコマンドによって「ＳＬＡＶＥ設定」を行うと、その設定がスレーブサーバ１４の局データ（実装位置情報）としてＡＴＭスイッチ本体１２に保存され（４Ｃ）、プロセス間通信でＳＬＡＶＥ指示（Ｓ４３）がスレーブサーバ１４へ送信される。ＳＬＡＶＥ指示を受けたスレーブサーバ１４では、ＡＴＭスイッチ１２経由でマスターサーバ１３へＴ１[sec]周期でＳＥＴＵＰを送信（Ｓ４４）し、マスターサーバ１３へＳＶＣを確立できるまで再試行（Ｓ４７）する。
【００３１】スレーブサーバ１４は、図３（ｂ）で示したＡＴＭアドレスを用い、マスターサーバ１３の宛先ＡＴＭアドレスに対してダイナミックルーティングによってＳＥＴＵＰが送信される。ＳＶＣ確立のシグナリング手順に成功すると、マスターサーバ１３に対してConnect Indication（Ｓ４５）を通知し、ＳＶＣ要求元のスレーブサーバ１４に対してSet Response(OK)（Ｓ４６）を返送することにより、ＳＶＣが確立する（４Ｄ）。
【００３２】1.2 Power-On再開、またはサーバ挿入による初期化図５を用いて、ＡＴＭスイッチ装置全体の電源投入時や、ＡＴＭスイッチ運用中のサーバモジュール挿入の初期化処理を説明する。
【００３３】マスターサーバ１３が起動し、再開処理（５Ａ）が完了すると、ＡＴＭスイッチ１２に対してＵＰ通知（Ｓ５１）を行う。ＡＴＭスイッチ１２は、ＵＰ通知送信元のサーバの局データを展開し（５Ｂ）、マスターサーバ１３であることがわかると、ＭＡＳＴＥＲ指示（Ｓ５２）を行う。以下は「コマンド設定による初期化」と同様に、ＰＶＣ確立（５Ｃ）とダイナミックルーティング登録（Ｓ５３）が行われる。
【００３４】同様に、スレーブサーバ１４が起動し、再開処理（５Ｄ）が完了すると、ＡＴＭスイッチ１２に対してＵＰ通知（Ｓ５４）を行う。ＡＴＭスイッチ１２は、ＵＰ通知送信元のサーバの局データを展開し（５Ｅ）、スレーブサーバ１４であることがわかると、ＳＬＡＶＥ指示（Ｓ５５）を行う。以下は「コマンド設定による初期化」と同様に、ＳＥＴＵＰ（Ｓ５６）、Connect Indication（Ｓ５７）、Set Response(OK)（Ｓ５８）のやりとりを経て、ＳＶＣが確立される（５Ｆ）。
【００３５】なお、サーバ起動時に、マスターとスレーブの局データ設定がまだ存在しない場合には、管理者によるコマンド入力によって初めて、図４と同様の初期化処理が行われる。
【００３６】2. インデックス収集フェーズマスターサーバ１３は、その管理下にある全てのスレーブサーバ１４のインデックスを管理する。図６のように、スレーブサーバ１４上のアプリケーション（以下「ＡＰＬ」と記す）に対するコマンド投入による設定データ追加／削除や、ＡＰＬ動作にともなう状態遷移によるＭＩＢの追加／削除時には、マスターサーバ１３へインデックス更新通知（Ｓ６１）し、同期させる必要がある。インデックス更新通知を受けたマスターサーバ１３はインデックス更新（６Ａ）し、スレーブサーバ１４へインデックス更新応答（Ｓ６２）を返す。
【００３７】図７は、スレーブサーバ１４に、LAN Emulation Server（ＬＥＳ）が搭載されているときの例である。スロット番号５と２にスレーブサーバモジュールが搭載されており、２つのモジュール上にＬＥＳのＭＩＢエントリ"lesConfEntry"が合計５個存在する。これら５個のＭＩＢに対して、インデックス番号１〜５が割り当てられている。
【００３８】2.1 再開時のインデックス更新図８を用いて、スレーブサーバ再開時のインデックス更新について説明する。ここでは、動作説明のため、スレーブサーバ１４をスレーブタスク１５とＡＰＬ１６に分ける。スレーブサーバ１４が再開（８Ａ）すると、スレーブタスク１５からＡＰＬ１６に対してインデックス通知要求（Ｓ８１）を送る。ＡＰＬ１６は、この後インデックス更新が完了するまで、ＭＩＢ登録／削除処理ルーチン（８Ｂ）に入る。ＡＰＬ１６からスレーブタスク１５にインデックス通知（Ｓ８２）が送られると、スレーブタスク１５はフレーム生成（８Ｃ）を行い、マスターサーバ１３へインデックス更新通知（Ｓ８３）を送る。マスターサーバ１３でインデックス更新が完了すると、スレーブタスク１５に対してインデックス更新応答（Ｓ８４）を送信し、さらにスレーブタスク１５からＡＰＬ１６へＲＥＴＵＲＮ（Ｓ８５）が送られる。
【００３９】Ｓ８２からＳ８５までの処理は、ＡＰＬ１６上に存在する全インデックス番号分繰り返し処理され、完了すると、ＭＩＢ登録／削除処理ルーチン（８Ｂ）が終了する。
【００４０】2.2 ＡＰＬコマンドによるインデックス更新図９を用いて、ＡＰＬコマンドによるインデックス更新について説明する。スレーブサーバ１４のＡＰＬ１６に対して、管理者がコマンド入力により設定追加／削除（Ｓ９１）を行うと、ＭＩＢ登録／削除処理ルーチン（９Ａ）が起動する。この後は、前述した図８の８Ｂ以降の処理と同様にインデックス更新が行われる。（図９の９Ａ、Ｓ９２〜Ｓ９５）
【００４１】2.3 ＡＰＬ状態遷移によるインデックス更新図１０を用いて、ＡＰＬ状態遷移によるインデックス更新について説明する。スレーブサーバ再開や、ＡＰＬコマンド入力以外の要因により、スレーブサーバ１４のＡＰＬ１６の状態に変化が起こり、スレーブサーバ登録状態を更新する必要がある場合は、この処理が行われる。ＡＰＬ１６の状態が遷移（１０Ａ）すると、ＭＩＢ登録／削除処理ルーチン（１０Ｂ）が起動する。この後は、図８の８Ｂ以降および図９の９Ａ以降の処理と同様にインデックス更新が行われる。（図１０の１０Ｂ、Ｓ１０１〜Ｓ１０４）
【００４２】2.4 インデックス更新タイマー監視スレーブサーバ１４がマスターサーバ１３に対して、インデックス更新通知を送信すると、インデックス更新応答が返送されてくるまで、スレーブサーバ１４のスレーブタスク１５は応答待機状態となる。インデックス更新通知の時点からある特定時間経っても更新応答がない場合は、マスター側の障害と判断できるように、タイムアウト監視処理を設ける。
【００４３】2.4.1 正常処理図１１を用いて、インデックス更新タイマー監視の正常処理について説明する。スレーブタスク１５が、ＡＰＬ１６からインデックス通知（Ｓ１１１）を受信すると、スレーブタスク１５上では、スレーブタスク処理（１１Ａ）が起動する。インデックス更新フェーズで説明した通り、スレーブタスク１５は、フレーム生成（１１Ｂ）を行い、マスターサーバ１３にインデックス更新通知（Ｓ１１２）を行う。スレーブタスク１５上では、タイムアウト監視（１１Ｃ）がスタートし、規定時間Ｔ２[sec]内にインデックス更新応答（Ｓ１１３）が受信できるか監視する。受信すると、インデックス更新が正常に処理されたとみなし、タイムアウト監視（１１Ｃ）を解除し、ＡＰＬ１６に対してＲＥＴＵＲＮ（Ｓ１１４）を送信する。
【００４４】2.4.2 タイムアウト処理図１２を用いて、インデックス更新タイマー監視のタイムアウト処理について説明する。正常処理の時と同様、スレーブタスク１５が、ＡＰＬ１６からインデックス通知（Ｓ１２１）を受信すると、スレーブタスク処理（１２Ａ）が起動し、フレーム生成（１２Ｂ）を行い、マスターサーバ１３にインデックス更新通知（Ｓ１２２）を行う。スレーブタスク１５上では、タイムアウト監視（１２Ｃ）がスタートし、規定時間Ｔ２[sec]内にインデックス更新応答が受信できるか監視する。Ｔ２[sec]経過後、更新応答未受信であれば、再送処理（１２Ｄ）を行い、インデックス更新通知を再送（Ｓ１２３）する。再送は決められた回数ｎ回行われる。
【００４５】なお、最終回の再送後Ｔ２[sec]経過しても更新応答が受信できない場合は、マスターサーバ１３において何らかの障害や処理遅延が発生したものとみなし、ＡＰＬ１６へタイムアウトのＲＥＴＵＲＮ（Ｓ１２４）を送信し、ＡＰＬ１６に対してインデックス更新が失敗したことを通知する。この時点でタイムアウト監視（１２Ｃ）を解除する。
【００４６】タイムアウト監視解除後に、Ｓ１２５のようにインデックス更新応答を受信した場合は、無効とみなされ、スレーブタスク１５においてフレームが破棄される。
【００４７】3. ＳＮＭＰ動作フェーズＮＭＳ１１、ＡＴＭスイッチ本体１２、マスターサーバ１３、スレーブサーバ１４それぞれの間のメッセージのやりとりは、ＳＮＭＰのプロトコルに従って行われる。以下でＳＮＭＰ動作フェーズの正常処理とタイムアウト処理の説明を行う。
【００４８】3.1 正常処理図１３を用いて、ＳＮＭＰ動作フェーズの正常処理について説明する。ＡＴＭスイッチ１２では、ＳＮＭＰエージェントが管理している管理オブジェクトのインスタンス値に対するGet要求やSet要求（Ｓ１３１）がＮＭＳ１１からあった場合、Get/Set共通関数（１３Ａ）において、VarBind毎にマスターサーバ１３に対してオブジェクト値のGet/Set要求（Ｓ１３２）を行う。マスターサーバ１３においては、ＡＴＭスイッチ本体１２とは別に、独自のGet/Set要求関数（１３Ｂ）を持っている。
【００４９】以下、図１３中のＡＴＭスイッチ１２、マスターサーバ１３、スレーブサーバ１４それぞれの間のGet/Set要求／応答について説明する。なお、初期化フェーズで説明した通り、ＡＴＭスイッチ１２とマスターサーバ１３間の通信はＰＶＣを用い、マスターサーバ１３とスレーブサーバ１４間の通信はＳＶＣを用いる。
【００５０】（１）ＡＴＭスイッチからマスターサーバへ（Ｓ１３２）
ＡＴＭスイッチ１２でデコードされたGet/Set要求（Ｓ１３１）は、OID, OID長, offsetなどの情報全てをフレーム化し、ＰＶＣを通じてマスターサーバ１３へ送信（Ｓ１３２）される。このGet/Set要求（Ｓ１３２）は、ＭＩＢグループ単位で行われたものが送信される。ここで、「ＭＩＢグループ単位」とは、例えばＬＡＮエミュレーションの場合、atmfLanEmulationツリー配下では、leClientMIB/elanMIB/lesMIB/busMIB単位で共通Get/Setインターフェースを用意することを意味する。
【００５１】（２）マスターサーバからスレーブサーバへ（Ｓ１３３）
Get/Set要求（Ｓ１３２）のフレームを受信したマスターサーバ１３では、Get/Set要求関数（１３Ｂ）において、OIDを内部IDに変換し、インデックステーブルを検索する。これにより、要求OIDを持つスレーブサーバ１４の実装位置（スロット番号）が判明し、該当スレーブサーバ１４へＳＶＣで、ＭＩＢのGet/Set要求（Ｓ１３３）を送信する。
【００５２】（３）スレーブサーバからマスターサーバへ（Ｓ１３４）
Get/Set要求（Ｓ１３３）を受信したスレーブサーバ１４では、ＡＰＬ１６のＭＩＢ取得/設定処理（図１０の１０Ｂを参照）操作を行ない、取得データ/設定状態などの応答情報をＳＶＣでマスターサーバ１３へGet/Set応答（Ｓ１３４）として送信する。マスターサーバ１３では、Get/Set要求（Ｓ１３３）からGet/Set応答（Ｓ１３４）までの間、Ｔ３[sec]のタイムアウト監視を行う。
【００５３】（４）マスターサーバからＡＴＭスイッチへ（Ｓ１３５）
スレーブサーバ１４からのGet/Set応答（Ｓ１３５）をマスターサーバ１３が受信すると、内部ID/OID変換を行うのみで応答情報をGet/Set応答（Ｓ１３５）としてＰＶＣを通じてＡＴＭスイッチ１２へ返信する。ＡＴＭスイッチ１２ではGet/Set要求（Ｓ１３２）からGet/Set応答（Ｓ１３５）までの間、Ｔ４[sec]のタイムアウト監視を行う。マスターサーバ１３からの応答が規定時間Ｔ４[sec]内に返ってくれば、ＮＭＳ１１にGet/Set応答（Ｓ１３６）として正常に値を返却する。
【００５４】3.2 タイムアウト処理図１４のように、ＡＴＭスイッチ１２がマスターサーバ１３へGet/Set要求（Ｓ１４２）を送信してから、規定時間Ｔ４[sec]内にマスターサーバ１３からのGet/Set応答が受信できない場合は、Get/Set共通関数（１４Ａ）においてタイムアウトと判断し、ＮＭＳ１１へエラー（Ｓ１４６）を返却する。タイムアウト後に応答（Ｓ１４５）が返ってきた場合は、ＡＴＭスイッチ１２のGet/Set共通関数で破棄する。
【００５５】同様に、図１５のように、マスターサーバ１３がスレーブサーバ１４へGet/Set要求（Ｓ１５３）を送信してから、規定時間Ｔ３[sec]内にスレーブサーバ１４からのGet/Set応答が受信できない場合は、Get/Set要求関数（１５Ｂ）においてタイムアウトと判断し、ＡＴＭスイッチ１２へエラー（Ｓ１５５）を返却する。タイムアウト後に応答（Ｓ１５４）が返ってきた場合は、マスターサーバ１３のGet/Set要求関数で破棄する。
【００５６】4. 障害処理4.1 マスターサーバ障害時図１６のように、マスターサーバ１３において障害が発生（Ｓ１６１）した場合、ＡＴＭスイッチ本体１２において、ＳＳＣＯＰ断（リンク断）を検知し、さらに装置管理処理により障害認識される（１６Ａ）。その後、ＡＴＭスイッチ１２からスレーブサーバ１４へDelete Indication（Ｓ１６２）が通知され、マスタースレーブ動作が停止する。
【００５７】4.2 スレーブサーバ障害時図１７のように、スレーブサーバ１４において障害が発生（Ｓ１７１）した場合、ＡＴＭスイッチ本体１２において、ＳＳＣＯＰ断（リンク断）を検知し、さらに装置管理処理により障害認識される（１７Ａ）。その後、ＡＴＭスイッチ１２からマスターサーバ１３へDelete Indication（Ｓ１７２）が通知され、マスターサーバ１３はスレーブインデックス登録を削除する（１７Ｂ）。
【００５８】
【発明の効果】本発明の第１の効果は、すべてのスレーブサーバとのＳＮＭＰ（Simple Network Management Protocol）通信を、マスターサーバにまかせることにより、ＡＴＭスイッチ本体のＣＰＵ処理にかかる負荷が低減し、ＳＮＭＰ以外の他の機能の処理能力に与える影響を最小限にとどめることが可能となる点である。
【００５９】第２の効果は、ＡＴＭスイッチ本体−マスターサーバ−スレーブサーバの間のＳＮＭＰ通信において、ローカルプロセッサ間通信を使用せず、ＶＣ接続による通信を用いることにより、ローカルプロセッサ間通信トラフィックを低減させることができ、ＳＮＭＰ以外の他のローカルプロセッサ間通信に与える影響を最小限にとどめることが可能となる点である。
【００６０】第３の効果は、マスターサーバとスレーブサーバの間の通信をＳＶＣ化することにより、常時ＰＶＣで接続する場合と比べ、消費リソースが最小限にとどめることが可能となる点である。
【図面の簡単な説明】
【図１】本発明の実施例の機器構成図である。
【図２】図１の各構成機器間のＳＮＭＰ通信の概要を示すシーケンスチャートである。
【図３】サーバへのＡＴＭアドレス割当て方法の解説図である。
【図４】コマンド設定による初期化のシーケンスチャートである。
【図５】Power-On再開、またはサーバ挿入による初期化のシーケンスチャートである。
【図６】インデックス収集フェーズを示すシーケンスチャートである。
【図７】LAN Emulation Serverのインデックス番号テーブルの一例を示す図である。
【図８】再開時のインデックス更新のシーケンスチャートである。
【図９】ＡＰＬコマンドによるインデックス更新のシーケンスチャートである。
【図１０】ＡＰＬ状態遷移によるインデックス更新のシーケンスチャートである。
【図１１】インデックス更新タイマー監視（正常処理）のシーケンスチャートである。
【図１２】インデックス更新タイマー監視（タイムアウト処理）のシーケンスチャートである。
【図１３】ＳＮＭＰ動作フェーズ（正常処理）のシーケンスチャートである。
【図１４】ＳＮＭＰ動作フェーズ（タイムアウト処理）のシーケンスチャートである。
【図１５】ＳＮＭＰ動作フェーズ（タイムアウト処理）の図１４とは異なるシーケンスチャートである。
【図１６】マスターサーバ障害時の動作のシーケンスチャートである。
【図１７】スレーブサーバ障害時の動作のシーケンスチャートである。
【符号の説明】
１１ ネットワーク管理システム（ＮＭＳ）
１２ ＡＴＭスイッチ
１３ マスターサーバ
１４ａ〜１４ｄ スレーブサーバ
【特許請求の範囲】
【請求項１】同一ＡＴＭ（Asynchronous Transfer Mode）スイッチ装置内に複数のサーバを搭載し、ネットワーク管理システムからＡＴＭスイッチに対してＳＮＭＰ（Simple Network Management Protocol）手順によって、サーバのＭＩＢ（ManagementInformation Base）にアクセスする方法において、前記複数のサーバの中の一つをマスターサーバ、その他をスレーブサーバに設定し、前記ＡＴＭスイッチからＳＮＭＰ手順によって前記マスターサーバに対して代表してアクセスし、マスターサーバからその他のスレーブサーバへはＶＣ（Virtual Connection）にてアクセスすることを特徴とする、ＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項２】ＡＴＭスイッチとマスターサーバ間のＳＮＭＰ通信はＶＣにて行うことを特徴とする、請求項１記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項３】ＡＴＭスイッチとマスターサーバ間の通信にはＰＶＣ（Permanent Virtual Connection）を用い、マスターサーバとスレーブサーバとの通信にはＳＶＣ（Switched Virtual Connection）を用いることを特徴とする、請求項２記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項４】マスターサーバとスレーブサーバとのＳＶＣによるセットアップにおいて、スレーブサーバがタイマを起動させてその設定時間にてリトライすることを特徴とする、請求項３記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項５】マスターサーバにおいて、スレーブサーバの管理にインデックス情報を用い、マスター・スレーブ間でインデックス更新通知／応答を行うことを特徴とする、請求項１、２、３又は４記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項６】インデックス収集フェーズにおいて、スレーブサーバからマスターサーバへのインデックス更新の際に、応答のタイムアウト監視を行うことを特徴とする、請求項５記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項７】インデックス更新応答がタイムアウトした場合に、インデックス更新通知の再送処理を行うことを特徴とする、請求項６記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項８】ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチ本体がマスターサーバと通信する際に、Get/Set共通関数を用いて、ＭＩＢグループ単位で通信することを特徴とする、請求項１、２、３、４、５、６又は７記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項９】ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチとマスターサーバ間、およびマスターサーバとスレーブサーバ間で、Get/Set応答のタイムアウト監視を行うことを特徴とする、請求項８記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項１０】マスターサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してスレーブサーバに伝え、マスター・スレーブ動作を停止することを特徴とする、請求項１、２、３、４、５、６、７、８又は９記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項１１】スレーブサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してマスターサーバに伝え、マスターサーバが管理しているスレーブインデックス番号の登録を削除することを請求項１、２、３、４、５、６、７、８又は９記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項１】同一ＡＴＭ（Asynchronous Transfer Mode）スイッチ装置内に複数のサーバを搭載し、ネットワーク管理システムからＡＴＭスイッチに対してＳＮＭＰ（Simple Network Management Protocol）手順によって、サーバのＭＩＢ（ManagementInformation Base）にアクセスする方法において、前記複数のサーバの中の一つをマスターサーバ、その他をスレーブサーバに設定し、前記ＡＴＭスイッチからＳＮＭＰ手順によって前記マスターサーバに対して代表してアクセスし、マスターサーバからその他のスレーブサーバへはＶＣ（Virtual Connection）にてアクセスすることを特徴とする、ＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項２】ＡＴＭスイッチとマスターサーバ間のＳＮＭＰ通信はＶＣにて行うことを特徴とする、請求項１記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項３】ＡＴＭスイッチとマスターサーバ間の通信にはＰＶＣ（Permanent Virtual Connection）を用い、マスターサーバとスレーブサーバとの通信にはＳＶＣ（Switched Virtual Connection）を用いることを特徴とする、請求項２記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項４】マスターサーバとスレーブサーバとのＳＶＣによるセットアップにおいて、スレーブサーバがタイマを起動させてその設定時間にてリトライすることを特徴とする、請求項３記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項５】マスターサーバにおいて、スレーブサーバの管理にインデックス情報を用い、マスター・スレーブ間でインデックス更新通知／応答を行うことを特徴とする、請求項１、２、３又は４記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項６】インデックス収集フェーズにおいて、スレーブサーバからマスターサーバへのインデックス更新の際に、応答のタイムアウト監視を行うことを特徴とする、請求項５記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項７】インデックス更新応答がタイムアウトした場合に、インデックス更新通知の再送処理を行うことを特徴とする、請求項６記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項８】ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチ本体がマスターサーバと通信する際に、Get/Set共通関数を用いて、ＭＩＢグループ単位で通信することを特徴とする、請求項１、２、３、４、５、６又は７記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項９】ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチとマスターサーバ間、およびマスターサーバとスレーブサーバ間で、Get/Set応答のタイムアウト監視を行うことを特徴とする、請求項８記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項１０】マスターサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してスレーブサーバに伝え、マスター・スレーブ動作を停止することを特徴とする、請求項１、２、３、４、５、６、７、８又は９記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項１１】スレーブサーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検出してマスターサーバに伝え、マスターサーバが管理しているスレーブインデックス番号の登録を削除することを請求項１、２、３、４、５、６、７、８又は９記載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【図１】
【図２】
【図３】
【図４】
【図６】
【図５】
【図７】
【図８】
【図９】
【図１３】
【図１０】
【図１１】
【図１２】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図６】
【図５】
【図７】
【図８】
【図９】
【図１３】
【図１０】
【図１１】
【図１２】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０００−３３２７６８（Ｐ２０００−３３２７６８Ａ）
【公開日】平成１２年１１月３０日（２０００．１１．３０）
【国際特許分類】
【出願番号】特願平１１−１３５００８
【出願日】平成１１年５月１４日（１９９９．５．１４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【出願人】（３９１０４３４２４）九州日本電気通信システム株式会社 (1)
【Ｆターム（参考）】
【公開日】平成１２年１１月３０日（２０００．１１．３０）
【国際特許分類】
【出願日】平成１１年５月１４日（１９９９．５．１４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【出願人】（３９１０４３４２４）九州日本電気通信システム株式会社 (1)
【Ｆターム（参考）】
[ Back to top ]