JP2000332768A

JP2000332768A - Ａｔｍ用サーバのｍｉｂ統合管理方法

Info

Publication number: JP2000332768A
Application number: JP13500899A
Authority: JP
Inventors: Minoru Hara; 実原; Masahiro Jinnai; 正寛陣内
Original assignee: KYUSHU NIPPON DENKI TSUSHIN SY; KYUSHU NIPPON DENKI TSUSHIN SYSTEM KK; NEC Corp
Current assignee: KYUSHU NIPPON DENKI TSUSHIN SY; KYUSHU NIPPON DENKI TSUSHIN SYSTEM KK; NEC Corp
Priority date: 1999-05-14
Filing date: 1999-05-14
Publication date: 2000-11-30
Also published as: DE60023208D1; DE60023208T2; EP1052870A1; CA2308244C; EP1052870B1; CA2308244A1; US6738812B1

Abstract

(57)【要約】【課題】ＡＴＭスイッチ本体のＣＰＵ処理にかかる負
荷を低減させ、ＳＮＭＰ以外の他の機能の処理能力に与
える影響を最小限に抑える。【解決手段】同一ＡＴＭスイッチ装置内に複数のサー
バを搭載し、ネットワーク管理システム(ＮＭＳ)１１か
らＡＴＭスイッチ１２に対してＳＮＭＰ手順によって、
サーバの管理情報ベースにアクセスする場合において、
複数のサーバの中の一つをマスターサーバ１３、その他
をスレーブサーバ１４ａ、１４ｂ・・・に設定し、ＡＴ
Ｍスイッチ１２からＳＮＭＰ手順によってマスターサー
バに対して代表してアクセスし、マスターサーバからそ
の他のスレーブサーバへはＶＣ（仮想コネクション）に
てアクセスする。ＡＴＭスイッチとマスターサーバ間の
通信にはＰＶＣを用い、マスターサーバとスレーブサー
バとの通信にはＳＶＣを用いる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、非同期転送モード
（Asynchronous Transfer Mode：以下「ＡＴＭ」と記
す）ネットワークを利用して、ＡＴＭセルを送受信する
装置において、複数のＡＴＭ通信用サーバに備えられた
ＭＩＢ（Management Information Base）を統合的に管
理する方法に関するものである。

【０００２】

【従来の技術】従来技術には、次のような問題点があっ
た。第１の問題点は、同一ＡＴＭスイッチ装置内に、様
々なＡＴＭ通信用サーバモジュールを搭載する環境にお
いて、ＡＴＭスイッチ本体がすべてのサーバモジュール
との間でSimple Network Management Protocol（ＳＮＭ
Ｐ）通信を行うと、ＡＴＭスイッチ本体のＣＰＵの処理
に高負荷がかかってしまい、ＳＮＭＰ以外の他の処理に
悪影響を与えてしまう点である。

【０００３】第２の問題点は、同一ＡＴＭスイッチ装置
内に、様々なＡＴＭ通信用サーバモジュールを搭載する
環境において、ＡＴＭスイッチ本体のＣＰＵとサーバの
ＣＰＵの間のＳＮＭＰ通信に、ローカルプロセッサ通信
を用いると、ローカルプロセッサ通信にかかるトラフィ
ックの負荷が増大し、ＳＮＭＰ通信以上に重要な通信、
例えば実装状態管理や装置障害管理の通信に悪影響を与
える点である。

【０００４】第３の問題点は、仮に上記の第２の問題点
が解決され、仮想コネクション（Virtual Connection：
以下「ＶＣ」と記す）通信によりＳＮＭＰ通信を行う場
合にしても、すべてのＶＣを相手固定接続（Permanent
Virtual Connection：以下「ＰＶＣ」と記す）にしてし
まうと、常時必要なＶＣリソースが消費され、リソース
の無駄が多いという点である。

【０００５】第４の問題点は、ＡＴＭスイッチにＳＮＭ
Ｐインタフェースが実装され、サーバモジュールにＭＩ
Ｂ取得インタフェースが実装されることで、サーバモジ
ュールのアプリケーションＭＩＢに追加／変更が行われ
る度に、ＡＴＭスイッチのＳＮＭＰインタフェースにも
追加／変更が必要となる密結合システムであった点であ
る。

【０００６】一方、特開平７−２２６７７７号公報及び
特開平７−３１９７９３号公報には、階層的にネットワ
ークを管理する方法として、統合マネージャとサブマネ
ージャとエージェントとをネットワーク上に別装置とし
て分散配置し、マネージャとエージェント間の通信をＳ
ＮＭＰにて行う方法が開示されているが、これは、ＳＮ
ＭＰを用いてはいるが、ネットワークを介して外部装置
間でＳＮＭＰ通信を行うものである。

【０００７】

【発明が解決しようとする課題】本発明は、同一ＡＴＭ
スイッチ装置内に複数のサーバを搭載し、ネットワーク
管理システムからＡＴＭスイッチに対してＳＮＭＰ手順
によって、サーバの管理情報ベースにアクセスする場合
において、ＡＴＭスイッチ本体のＣＰＵ処理にかかる負
荷を低減させ、ＳＮＭＰ以外の他の機能の処理能力に与
える影響を最小限に抑えることを目的とする。

【０００８】

【課題を解決するための手段】本発明は、同一ＡＴＭス
イッチ装置内に複数のサーバを搭載し、ネットワーク管
理システム(Network Management System：以下「ＮＭ
Ｓ」と記す)からＡＴＭスイッチに対してＳＮＭＰ手順
によって、サーバのＭＩＢ（Management Information B
ase）にアクセスする方法において、複数のサーバの中
の一つをマスターサーバ、その他をスレーブサーバに設
定し、ＡＴＭスイッチからＳＮＭＰ手順によってマスタ
ーサーバに対して代表してアクセスし、マスターサーバ
からその他のスレーブサーバへはＶＣにてアクセスする
ことを特徴とする。

【０００９】ＡＴＭスイッチとマスターサーバ間のＳＮ
ＭＰ通信はＶＣにて行う。この場合、ＡＴＭスイッチと
マスターサーバ間の通信にはＰＶＣ（Permanent Virtua
l Connection）を用い、マスターサーバとスレーブサー
バとの通信にはＳＶＣ（Switched Virtual Connectio
n）を用いる。

【００１０】マスターサーバとスレーブサーバとのＳＶ
Ｃによるセットアップにおいて、スレーブサーバがタイ
マを起動させてその設定時間にてリトライする。

【００１１】マスターサーバにおいて、スレーブサーバ
の管理にインデックス情報を用い、マスター・スレーブ
間でインデックス更新通知／応答を行う。インデックス
収集フェーズにおいては、スレーブサーバからマスター
サーバへのインデックス更新の際に、応答のタイムアウ
ト監視を行う。インデックス更新応答がタイムアウトし
た場合は、インデックス更新通知の再送処理を行う。

【００１２】ＳＮＭＰ動作フェーズにおいて、ＡＴＭス
イッチ本体がマスターサーバと通信する際に、Get/Set
共通関数を用いて、ＭＩＢグループ単位で通信する。ま
た、ＳＮＭＰ動作フェーズにおいて、ＡＴＭスイッチと
マスターサーバ間、およびマスターサーバとスレーブサ
ーバ間で、Get/Set応答のタイムアウト監視を行う。

【００１３】マスターサーバ障害時に、ＡＴＭスイッチ
本体が自動的に障害を検出してスレーブサーバに伝え、
マスター・スレーブ動作を停止する。また、スレーブサ
ーバ障害時に、ＡＴＭスイッチ本体が自動的に障害を検
出してマスターサーバに伝え、マスターサーバが管理し
ているスレーブインデックス番号の登録を削除する。

【００１４】本発明の特徴を図を参照して概説すると、
図２において、ＮＭＳ１１からＡＴＭスイッチ１２に対
して、Simple Network Management Protocol（ＳＮＭ
Ｐ）の手順によって、サーバのＭＩＢへのアクセス（Ｓ
２１）が行われる場合に、ＡＴＭスイッチ１２から配下
の全てのサーバへＳＮＭＰアクセスするのではなく、マ
スターサーバ１３に対して代表してアクセス（Ｓ２２）
し、マスターサーバ１３からその他のスレーブサーバ１
４へアクセスする。また、ＡＴＭスイッチ１２とマスタ
ーサーバ１３間、および、マスターサーバ１３とスレー
ブサーバ１４間のＳＮＭＰ通信には、図４の４Ｂ、４
Ｄ、図５の５Ｃ、５Ｆに示す通り、ＶＣによる接続を用
い、ＡＴＭスイッチ１２とサーバのローカルプロセッサ
間通信を使用しない。

【００１５】これにより、ＡＴＭスイッチ本体にかかる
負荷が低減し、ＳＮＭＰ以外の他の機能の処理能力に与
える影響を最小限にとどめることが可能となる。

【００１６】

【発明の実施の形態】以下、本発明の実施例を図面によ
り説明する。図１は、本発明の前提となる機器構成例を
示している。本構成例は、ネットワーク管理システム(N
etwork Management System：以下「ＮＭＳ」と記す)１
１と、ＡＴＭスイッチ１２と、複数のＡＴＭ通信用サー
バとを含む。このＡＴＭ通信用サーバは、ＭＩＢ（Mana
gement Information Base）管理上の役割に応じてマス
ターサーバ１３と、スレーブサーバ１４に分類でき、複
数あるスレーブサーバはそれぞれ１４ａ〜１４ｄとして
表してある。

【００１７】ＮＭＳ１１は、ＳＮＭＰ（Simple Network
Management Protocol）の手順によって、ＡＴＭスイッ
チ１２とサーバ１３、１４に搭載されているＭＩＢにア
クセスし、管理用のデータを書き込んだり、読み出した
りする。サーバ１３、１４はＡＴＭスイッチ１２の装置
内に搭載され、ＮＭＳ１１からサーバ１３、１４へのア
クセスは全て、ＡＴＭスイッチ本体１２のＳＮＭＰイン
タフェース経由で行われる。

【００１８】ここで、ＡＴＭ通信用サーバの種類は本発
明で規定するところではないが、下記のようなものを想
定している。 (1) ATM Forum "LAN Emulatin Over ATM Version 2" (A
F-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 Respo
nse（Ｓ２４）を受信する。

【００２１】続いてマスターサーバ１３から、第２のス
レーブサーバ（１４ｂ）に対してGet/Set Request（Ｓ
２５）を送信し、返答としてGet/Set Response（Ｓ２
６）を受信する。この際、ＡＴＭスイッチ本体１２とス
レーブサーバ１４の間でＳＮＭＰメッセージを直接やり
とりすることはない。スレーブサーバ１４の返答をすべ
て受信したマスターサーバ１３は、その返答をまとめて
ＡＴＭスイッチ１２へ送信し（Ｓ２７）、最終的にＮＭ
Ｓ１１へ送信される（Ｓ２８）。

【００２２】マスターサーバ１３とスレーブサーバ１４
の間の通信は、ＡＴＭスイッチ本体１２の情報処理能力
に影響を与えないために、ＶＣ（Virtual Connection）
による通信を採用する。また、サーバの搭載状況やモジ
ュール数は変動するため、あらかじめＶＣを固定的に設
定しておくことはできない。

【００２３】したがって、ＳＶＣ（Switched Virtual C
onnection）により、サーバ間の通信の必要性に応じて
ＶＣを確保する。サーバ間でＳＶＣを設定するために
は、ＡＴＭシグナリング手順（ATM Forum "ATM User-Ne
twork Specification Version3.1"他）を用いる必要が
あり、そのために、マスターサーバ１３とスレーブサー
バ１４にそれぞれシグナリング終端用のＡＴＭアドレス
を割り当てなければならない。

【００２４】図３は、マスターサーバ１３とスレーブサ
ーバ１４に対するＡＴＭアドレスの割当て方法を表して
いる。管理コマンドによって「マスター設定」をサーバ
に対して行うと、図３(a)のように、Network Prefix
（ＮＰ）部はＡＴＭスイッチと同様の１３バイト、End
System Identifier（ＥＳＩ）部は製造者識別番号４バ
イト＋"ffff"固定の計６バイト、セレクタ（ＳＥＬ）部
は"ff"固定１バイトをそれぞれ割り当てる。これに対
し、管理コマンドによって「スレーブ設定」をサーバに
対して行うと、図３（ｂ）のように、ＮＰ部はＡＴＭス
イッチおよびマスター設定と同様の１３バイト、ＥＳＩ
部はサーバのハードウェア固有のＭＡＣアドレス（IEEE
LAN SpecificationsのMedia Access Control protoco
l）６バイト、ＳＥＬはＡＴＭスイッチ装置内における
該当サーバの実装位置（スロット番号やモジュール番号
など）１バイトを割り当てる。

【００２５】マスターサーバ１３のＡＴＭアドレスは、
スレーブサーバ１４から見ると固定的に決定しているた
め、シグナリング手順はスレーブサーバ１４側からのＳ
ＥＴＵＰ要求で始まる。また、スレーブサーバ１４が複
数モジュール存在しても、ＭＡＣアドレスと実装位置が
ユニークに割り当てられているため、同一ＡＴＭアドレ
スが割り当てられることがない仕組みである。マスター
サーバ１３における全スレーブサーバ１４のＭＩＢの一
元管理は、このＳＶＣによる１対多の双方向通信により
実現される。

【００２６】以上のように、マスターサーバ１３が、全
スレーブサーバ１４のＭＩＢ管理を、統合的に行えるよ
うな構成になっている。

【００２７】次に、図面を参照して本実施例の動作につ
いて詳細に説明する。 1. 初期化フェーズ初期化フェーズでは、ＡＴＭスイッチ本体１２とマスタ
ーサーバ１３間、マスターサーバ１３とスレーブサーバ
１４間のＶＣを確立し、それぞれの間でＳＮＭＰ通信を
行うための準備をする。

【００２８】1.1 コマンド設定による初期化図４を用いて説明する。いま、ＡＴＭスイッチ１２にサ
ーバが２つ搭載されており、一方をマスターサーバ１
３、他方をスレーブサーバ１４として設定する。管理者
がコマンドによって「ＭＡＳＴＥＲ設定」を行うと、そ
の設定がマスターサーバ１３の設定データ（実装位置情
報）としてＡＴＭスイッチ本体１２に保存される（４
Ａ）。この設定データを以下「局データ」と呼ぶ。局デ
ータが設定されると、ＡＴＭスイッチ１２からマスター
サーバ１３に対して、プロセス間通信でＭＡＳＴＥＲ指
示（Ｓ４１）が送信され、マスターサーバ１３は自身が
マスターとして動作することを知る。その後、ＡＴＭス
イッチ１２とマスターサーバ１３間にＰＶＣ（Permanen
t Virtual Connection）（４Ｂ）を確立し、ＳＮＭＰ通
信に備える。

【００２９】その後、マスターサーバ１３は、図３
（ａ）で示した自身のＡＴＭアドレスを、ＡＴＭスイッ
チ１２にダイナミックルーティング登録（Ｓ４２）す
る。このダイナミックルーティング情報は、後程スレー
ブ側からＳＶＣ（Switched VirtualConnection）確立の
ためのＳＥＴＵＰメッセージをマスター側へ転送するた
めに必要となる。この時点でマスターサーバ１３は、ス
レーブサーバ１４からのＳＥＴＵＰ待ちとなる。

【００３０】管理者がコマンドによって「ＳＬＡＶＥ設
定」を行うと、その設定がスレーブサーバ１４の局デー
タ（実装位置情報）としてＡＴＭスイッチ本体１２に保
存され（４Ｃ）、プロセス間通信でＳＬＡＶＥ指示（Ｓ
４３）がスレーブサーバ１４へ送信される。ＳＬＡＶＥ
指示を受けたスレーブサーバ１４では、ＡＴＭスイッチ
１２経由でマスターサーバ１３へＴ１[sec]周期でＳＥ
ＴＵＰを送信（Ｓ４４）し、マスターサーバ１３へＳＶ
Ｃを確立できるまで再試行（Ｓ４７）する。

【００３１】スレーブサーバ１４は、図３（ｂ）で示し
たＡＴＭアドレスを用い、マスターサーバ１３の宛先Ａ
ＴＭアドレスに対してダイナミックルーティングによっ
てＳＥＴＵＰが送信される。ＳＶＣ確立のシグナリング
手順に成功すると、マスターサーバ１３に対してConnec
t Indication（Ｓ４５）を通知し、ＳＶＣ要求元のスレ
ーブサーバ１４に対してSet Response(OK)（Ｓ４６）を
返送することにより、ＳＶＣが確立する（４Ｄ）。

【００３２】1.2 Power-On再開、またはサーバ挿入に
よる初期化図５を用いて、ＡＴＭスイッチ装置全体の電源投入時
や、ＡＴＭスイッチ運用中のサーバモジュール挿入の初
期化処理を説明する。

【００３３】マスターサーバ１３が起動し、再開処理
（５Ａ）が完了すると、ＡＴＭスイッチ１２に対してＵ
Ｐ通知（Ｓ５１）を行う。ＡＴＭスイッチ１２は、ＵＰ
通知送信元のサーバの局データを展開し（５Ｂ）、マス
ターサーバ１３であることがわかると、ＭＡＳＴＥＲ指
示（Ｓ５２）を行う。以下は「コマンド設定による初期
化」と同様に、ＰＶＣ確立（５Ｃ）とダイナミックルー
ティング登録（Ｓ５３）が行われる。

【００３４】同様に、スレーブサーバ１４が起動し、再
開処理（５Ｄ）が完了すると、ＡＴＭスイッチ１２に対
してＵＰ通知（Ｓ５４）を行う。ＡＴＭスイッチ１２
は、ＵＰ通知送信元のサーバの局データを展開し（５
Ｅ）、スレーブサーバ１４であることがわかると、ＳＬ
ＡＶＥ指示（Ｓ５５）を行う。以下は「コマンド設定に
よる初期化」と同様に、ＳＥＴＵＰ（Ｓ５６）、Connec
t Indication（Ｓ５７）、Set Response(OK)（Ｓ５８）
のやりとりを経て、ＳＶＣが確立される（５Ｆ）。

【００３５】なお、サーバ起動時に、マスターとスレー
ブの局データ設定がまだ存在しない場合には、管理者に
よるコマンド入力によって初めて、図４と同様の初期化
処理が行われる。

【００３６】2. インデックス収集フェーズマスターサーバ１３は、その管理下にある全てのスレー
ブサーバ１４のインデックスを管理する。図６のよう
に、スレーブサーバ１４上のアプリケーション（以下
「ＡＰＬ」と記す）に対するコマンド投入による設定デ
ータ追加／削除や、ＡＰＬ動作にともなう状態遷移によ
るＭＩＢの追加／削除時には、マスターサーバ１３へイ
ンデックス更新通知（Ｓ６１）し、同期させる必要があ
る。インデックス更新通知を受けたマスターサーバ１３
はインデックス更新（６Ａ）し、スレーブサーバ１４へ
インデックス更新応答（Ｓ６２）を返す。

【００３７】図７は、スレーブサーバ１４に、LAN Emul
ation Server（ＬＥＳ）が搭載されているときの例であ
る。スロット番号５と２にスレーブサーバモジュールが
搭載されており、２つのモジュール上にＬＥＳのＭＩＢ
エントリ"lesConfEntry"が合計５個存在する。これら５
個のＭＩＢに対して、インデックス番号１〜５が割り当
てられている。

【００３８】2.1 再開時のインデックス更新図８を用いて、スレーブサーバ再開時のインデックス更
新について説明する。ここでは、動作説明のため、スレ
ーブサーバ１４をスレーブタスク１５とＡＰＬ１６に分
ける。スレーブサーバ１４が再開（８Ａ）すると、スレ
ーブタスク１５からＡＰＬ１６に対してインデックス通
知要求（Ｓ８１）を送る。ＡＰＬ１６は、この後インデ
ックス更新が完了するまで、ＭＩＢ登録／削除処理ルー
チン（８Ｂ）に入る。ＡＰＬ１６からスレーブタスク１
５にインデックス通知（Ｓ８２）が送られると、スレー
ブタスク１５はフレーム生成（８Ｃ）を行い、マスター
サーバ１３へインデックス更新通知（Ｓ８３）を送る。
マスターサーバ１３でインデックス更新が完了すると、
スレーブタスク１５に対してインデックス更新応答（Ｓ
８４）を送信し、さらにスレーブタスク１５からＡＰＬ
１６へＲＥＴＵＲＮ（Ｓ８５）が送られる。

【００３９】Ｓ８２からＳ８５までの処理は、ＡＰＬ１
６上に存在する全インデックス番号分繰り返し処理さ
れ、完了すると、ＭＩＢ登録／削除処理ルーチン（８
Ｂ）が終了する。

【００４０】2.2 ＡＰＬコマンドによるインデックス更
新図９を用いて、ＡＰＬコマンドによるインデックス更新
について説明する。スレーブサーバ１４のＡＰＬ１６に
対して、管理者がコマンド入力により設定追加／削除
（Ｓ９１）を行うと、ＭＩＢ登録／削除処理ルーチン
（９Ａ）が起動する。この後は、前述した図８の８Ｂ以
降の処理と同様にインデックス更新が行われる。（図９
の９Ａ、Ｓ９２〜Ｓ９５）

【００４１】2.3 ＡＰＬ状態遷移によるインデックス更
新図１０を用いて、ＡＰＬ状態遷移によるインデックス更
新について説明する。スレーブサーバ再開や、ＡＰＬコ
マンド入力以外の要因により、スレーブサーバ１４のＡ
ＰＬ１６の状態に変化が起こり、スレーブサーバ登録状
態を更新する必要がある場合は、この処理が行われる。
ＡＰＬ１６の状態が遷移（１０Ａ）すると、ＭＩＢ登録
／削除処理ルーチン（１０Ｂ）が起動する。この後は、
図８の８Ｂ以降および図９の９Ａ以降の処理と同様にイ
ンデックス更新が行われる。（図１０の１０Ｂ、Ｓ１０
１〜Ｓ１０４）

【００４２】2.4 インデックス更新タイマー監視スレーブサーバ１４がマスターサーバ１３に対して、イ
ンデックス更新通知を送信すると、インデックス更新応
答が返送されてくるまで、スレーブサーバ１４のスレー
ブタスク１５は応答待機状態となる。インデックス更新
通知の時点からある特定時間経っても更新応答がない場
合は、マスター側の障害と判断できるように、タイムア
ウト監視処理を設ける。

【００４３】2.4.1 正常処理図１１を用いて、インデックス更新タイマー監視の正常
処理について説明する。スレーブタスク１５が、ＡＰＬ
１６からインデックス通知（Ｓ１１１）を受信すると、
スレーブタスク１５上では、スレーブタスク処理（１１
Ａ）が起動する。インデックス更新フェーズで説明した
通り、スレーブタスク１５は、フレーム生成（１１Ｂ）
を行い、マスターサーバ１３にインデックス更新通知
（Ｓ１１２）を行う。スレーブタスク１５上では、タイ
ムアウト監視（１１Ｃ）がスタートし、規定時間Ｔ２[s
ec]内にインデックス更新応答（Ｓ１１３）が受信でき
るか監視する。受信すると、インデックス更新が正常に
処理されたとみなし、タイムアウト監視（１１Ｃ）を解
除し、ＡＰＬ１６に対してＲＥＴＵＲＮ（Ｓ１１４）を
送信する。

【００４４】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/S
et要求関数（１５Ｂ）においてタイムアウトと判断し、
ＡＴＭスイッチ１２へエラー（Ｓ１５５）を返却する。
タイムアウト後に応答（Ｓ１５４）が返ってきた場合
は、マスターサーバ１３のGet/Set要求関数で破棄す
る。

【００５６】4. 障害処理 4.1 マスターサーバ障害時図１６のように、マスターサーバ１３において障害が発
生（Ｓ１６１）した場合、ＡＴＭスイッチ本体１２にお
いて、ＳＳＣＯＰ断（リンク断）を検知し、さらに装置
管理処理により障害認識される（１６Ａ）。その後、Ａ
ＴＭスイッチ１２からスレーブサーバ１４へDelete Ind
ication（Ｓ１６２）が通知され、マスタースレーブ動
作が停止する。

【００５７】4.2 スレーブサーバ障害時図１７のように、スレーブサーバ１４において障害が発
生（Ｓ１７１）した場合、ＡＴＭスイッチ本体１２にお
いて、ＳＳＣＯＰ断（リンク断）を検知し、さらに装置
管理処理により障害認識される（１７Ａ）。その後、Ａ
ＴＭスイッチ１２からマスターサーバ１３へDelete Ind
ication（Ｓ１７２）が通知され、マスターサーバ１３
はスレーブインデックス登録を削除する（１７Ｂ）。

【００５８】

【発明の効果】本発明の第１の効果は、すべてのスレー
ブサーバとのＳＮＭＰ（Simple Network Management Pr
otocol）通信を、マスターサーバにまかせることによ
り、ＡＴＭスイッチ本体のＣＰＵ処理にかかる負荷が低
減し、ＳＮＭＰ以外の他の機能の処理能力に与える影響
を最小限にとどめることが可能となる点である。

【００５９】第２の効果は、ＡＴＭスイッチ本体−マス
ターサーバ−スレーブサーバの間のＳＮＭＰ通信におい
て、ローカルプロセッサ間通信を使用せず、ＶＣ接続に
よる通信を用いることにより、ローカルプロセッサ間通
信トラフィックを低減させることができ、ＳＮＭＰ以外
の他のローカルプロセッサ間通信に与える影響を最小限
にとどめることが可能となる点である。

【００６０】第３の効果は、マスターサーバとスレーブ
サーバの間の通信をＳＶＣ化することにより、常時ＰＶ
Ｃで接続する場合と比べ、消費リソースが最小限にとど
めることが可能となる点である。

【図面の簡単な説明】

【図１】本発明の実施例の機器構成図である。

【図２】図１の各構成機器間のＳＮＭＰ通信の概要を示
すシーケンスチャートである。

【図３】サーバへのＡＴＭアドレス割当て方法の解説図
である。

【図４】コマンド設定による初期化のシーケンスチャー
トである。

【図５】Power-On再開、またはサーバ挿入による初期化
のシーケンスチャートである。

【図６】インデックス収集フェーズを示すシーケンスチ
ャートである。

【図７】LAN Emulation Serverのインデックス番号テー
ブルの一例を示す図である。

【図８】再開時のインデックス更新のシーケンスチャー
トである。

【図９】ＡＰＬコマンドによるインデックス更新のシー
ケンスチャートである。

【図１０】ＡＰＬ状態遷移によるインデックス更新のシ
ーケンスチャートである。

【図１１】インデックス更新タイマー監視（正常処理）
のシーケンスチャートである。

【図１２】インデックス更新タイマー監視（タイムアウ
ト処理）のシーケンスチャートである。

【図１３】ＳＮＭＰ動作フェーズ（正常処理）のシーケ
ンスチャートである。

【図１４】ＳＮＭＰ動作フェーズ（タイムアウト処理）
のシーケンスチャートである。

【図１５】ＳＮＭＰ動作フェーズ（タイムアウト処理）
の図１４とは異なるシーケンスチャートである。

【図１６】マスターサーバ障害時の動作のシーケンスチ
ャートである。

【図１７】スレーブサーバ障害時の動作のシーケンスチ
ャートである。

【符号の説明】

１１ネットワーク管理システム（ＮＭＳ）１２ＡＴＭスイッチ１３マスターサーバ１４ａ〜１４ｄスレーブサーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者陣内正寛福岡県福岡市早良区百道浜二丁目４番１号九州日本電気通信システム株式会社内Ｆターム(参考） 5B089 GA11 GB02 HA05 HB06 JB22 KA06 KB04 KB06 MC06 5K030 GA08 GA12 HA10 HB08 JA10 KA21 LB19 LE03 MA01 9A001 CC02 CC06 CC07 JJ18 JJ27

Claims

【特許請求の範囲】

【請求項１】同一ＡＴＭ（Asynchronous Transfer Mod
e）スイッチ装置内に複数のサーバを搭載し、ネットワ
ーク管理システムからＡＴＭスイッチに対してＳＮＭＰ
（Simple Network Management Protocol）手順によっ
て、サーバのＭＩＢ（ManagementInformation Base）に
アクセスする方法において、前記複数のサーバの中の一
つをマスターサーバ、その他をスレーブサーバに設定
し、前記ＡＴＭスイッチからＳＮＭＰ手順によって前記
マスターサーバに対して代表してアクセスし、マスター
サーバからその他のスレーブサーバへはＶＣ（Virtual
Connection）にてアクセスすることを特徴とする、ＡＴ
Ｍ用サーバのＭＩＢ統合管理方法。
【請求項２】ＡＴＭスイッチとマスターサーバ間のＳＮ
ＭＰ通信はＶＣにて行うことを特徴とする、請求項１記
載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項３】ＡＴＭスイッチとマスターサーバ間の通信
にはＰＶＣ（Permanent Virtual Connection）を用い、
マスターサーバとスレーブサーバとの通信にはＳＶＣ
（Switched Virtual Connection）を用いることを特徴
とする、請求項２記載のＡＴＭ用サーバのＭＩＢ統合管
理方法。
【請求項４】マスターサーバとスレーブサーバとのＳＶ
Ｃによるセットアップにおいて、スレーブサーバがタイ
マを起動させてその設定時間にてリトライすることを特
徴とする、請求項３記載のＡＴＭ用サーバのＭＩＢ統合
管理方法。
【請求項５】マスターサーバにおいて、スレーブサーバ
の管理にインデックス情報を用い、マスター・スレーブ
間でインデックス更新通知／応答を行うことを特徴とす
る、請求項１、２、３又は４記載のＡＴＭ用サーバのＭ
ＩＢ統合管理方法。
【請求項６】インデックス収集フェーズにおいて、スレ
ーブサーバからマスターサーバへのインデックス更新の
際に、応答のタイムアウト監視を行うことを特徴とす
る、請求項５記載のＡＴＭ用サーバのＭＩＢ統合管理方
法。
【請求項７】インデックス更新応答がタイムアウトした
場合に、インデックス更新通知の再送処理を行うことを
特徴とする、請求項６記載のＡＴＭ用サーバのＭＩＢ統
合管理方法。
【請求項８】ＳＮＭＰ動作フェーズにおいて、ＡＴＭス
イッチ本体がマスターサーバと通信する際に、Get/Set
共通関数を用いて、ＭＩＢグループ単位で通信すること
を特徴とする、請求項１、２、３、４、５、６又は７記
載のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項９】ＳＮＭＰ動作フェーズにおいて、ＡＴＭス
イッチとマスターサーバ間、およびマスターサーバとス
レーブサーバ間で、Get/Set応答のタイムアウト監視を
行うことを特徴とする、請求項８記載のＡＴＭ用サーバ
のＭＩＢ統合管理方法。
【請求項１０】マスターサーバ障害時に、ＡＴＭスイッ
チ本体が自動的に障害を検出してスレーブサーバに伝
え、マスター・スレーブ動作を停止することを特徴とす
る、請求項１、２、３、４、５、６、７、８又は９記載
のＡＴＭ用サーバのＭＩＢ統合管理方法。
【請求項１１】スレーブサーバ障害時に、ＡＴＭスイッ
チ本体が自動的に障害を検出してマスターサーバに伝
え、マスターサーバが管理しているスレーブインデック
ス番号の登録を削除することを請求項１、２、３、４、
５、６、７、８又は９記載のＡＴＭ用サーバのＭＩＢ統
合管理方法。