JP2000286921A

JP2000286921A - ネットワーク機器制御装置及び通信システム

Info

Publication number: JP2000286921A
Application number: JP9109499A
Authority: JP
Inventors: Kazuyo Miyamoto; 和代宮本; Shinya Kano; 慎也加納; Yoshiharu Kurose; 義敏黒瀬; Yuji Nomura; 祐士野村
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1999-03-31
Filing date: 1999-03-31
Publication date: 2000-10-13
Anticipated expiration: 2019-03-31
Also published as: JP3469501B2; EP1041794A3; EP1041794A2

Abstract

(57)【要約】【課題】クライアントへの設定をサーバ主導で行える
ようにする。【解決手段】ネットワークを構成するネットワーク機
器１３₁〜１３₃と、ネットワーク機器からの要求に対し
て所定の処理を行って応答するネットワーク機器制御装
置１４を備え、クライアントであるネットワーク機器１
３₁〜１３₃とサーバであるネットワーク機器制御装置１
４間でクライアント・サーバ型のプロトコルに従って情
報送受を行う通信システムにおいて、クライアント１３
₁〜１３₃はサーバ１４に対して、サーバに主導権を付与
するサーバ主導権許可メッセージを送信し、サーバは該
メッセージ受信後、該クライアントに対し適宜必要な設
定を指示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は通信システム及びネ
ットワーク機器制御装置に係わり、特に、ネットワーク
を構成するルータ等のネットワーク機器と該ネットワー
ク機器からの要求に対して所定の処理を行って応答する
ネットワーク機器制御装置を備え、クライアント・サー
バ型のプロトコルに従ってネットワーク機器制御装置が
ネットワーク機器に各種設定を行う通信システム及びネ
ットワーク機器制御装置に関する。

【０００２】ネットワークの普及により、ネットワーク
の利用人数、接続ホスト数が増加しており、それに伴い
トラフィックも増加、多様化してきている。このような
状況下において、ネットワークの運用やユーザに対する
帯域の保証等を効率よく行うために、ネットワーク上の
資源をあるポリシーに基づき一元管理するメカニズムが
提案されている。かかる一元管理メカニズムを実現する
ために、サーバとしてのネットワーク機器制御装置にポ
リシー情報を持たせ、サーバがクライアントであるネッ
トワーク機器からの要求に対してポリシー情報に基づい
て処理を行ってクライアントに応答するようになってい
る。サーバとクライアント間でのポリシー情報送受のた
めに使用するプロトコルとしてIETFで標準化作業中であ
るCOPS(common open policy protocol)がある。本発明
はCOPSプロトコルのようなクライアント・サーバ型のプ
ロトコルに従って情報送受を行い、サーバがポリシー情
報に従ってクライアントに各種設定を行う通信システム
及びそのネットワーク機器制御装置に関するものであ
る。

【０００３】

【従来の技術】(a) 企業内ネットワークにおける現状 IP(internet protocol)ベースのネットワークの普及に
伴い、企業内ネットワークにおいても、従来のデータト
ラフィックのみならず、音声・動画等のマルチメディア
トラフィックを含め、IPによる統合化が進みつつある。
このように各種トラフィックを統合して収容する企業内
ネットワークにおける現状の主な問題点及びそれに対す
る要求条件は以下の２点である。

【０００４】(1) 運用・管理の簡素化ネットワークの構成要素であるルータ、スイッチ、更に
は、エンド端末（ホスト）等のネットワーク機器を適切
に運用するためには、各ネットワーク機器に対し、その
機器に適した動作設定が必要である。このような機器設
定においては、機器の特性、ネットワーク構成、ネット
ワーク利用状況、ユーザの要求など多くの情報を必要と
する。これらの情報はネットワークの大規模化、高機能
化に伴って増加するため、それに比例して設定も複雑化
し、かつ、運用管理コストの増大を招く恐れがある。そ
こで、ネットワーク機器に対する動作設定の簡素化、自
動化が求められている。

【０００５】(2) 各種情報の一元管理企業内ネットワークでは、ユーザ情報、提供アプリケー
ショの情報、機器情報、更には、運用ポリシー等を管理
する必要がある。しかし、このような各種情報の管理主
体が企業内ネットワークに複数存在すると、情報の不整
合や、設定ミスにより、ネットワークの運用に支障を来
す恐れがある。このような問題を回避するためには、ネ
ットワーク内において、各種情報の一元管理が必要とな
る。ポリシーサーバによるネットワーク機器の集中制御
及び集中管理を前提としたPBN(policy based Networkin
g)アーキテクチャは上記企業内ネットワークに対する要
求条件を満たす目的として提案、検討されている技術で
ある。その基本的なアプローチは、ネットワーク管理者
がネットワークを運用する際に予め知識や経験として持
っているポリシーをポリシーサーバに持たせ、ポリシー
サーバがその保持情報に従って、自律的に運用・管理を
行っていくことである。すなわち、ポリシーサーバに対
し運用ポリシーを明示的に与えることで、ネットワーク
内の各機器は、その情報を参照することが可能となり、
結果的に各機器には、与えられた運用ポリシーを反映し
た制御・設定が実行される。

【０００６】IETFのRAP-WG(RSVP Admission Policy Wor
king Group)では、RSVP要求に対する資源の割り当てや
ユーザに関するアドミッション制御をポリシーベースで
行うためのPBNアーキテクチャを提案している。RSVP(re
source reservationprotocol)などon demandでネット
ワーク機器に対してなされる資源確保要求に対してアド
ミッション制御をするには、PBNを用いない従来の手法
ではネットワーク管理者が事前にすべてのRSVPルータに
アドミッション情報を与える必要がある。しかしこのよ
うな手法は、情報の一元管理ができない問題がある。

【０００７】一方、アドミッション制御におけるPBNア
ーキテクチャでは、管理者がポリシー情報をポリシーサ
ーバに与えるだけでよく、情報の一元管理ができる。PB
Nアーキテクチャでは、アドミッション制御の要求を行
うルータ(ネットワーク機器)は、RSVPにより資源確保要
求があると、COPS(common open policy service)プロト
コルを用いてポリシーサーバにアドミッションの判断を
要求する。ポリシーサーバはネットワーク機器よりアド
ミッション制御要求を受信すれば、ポリシー情報に基づ
いてアドミッションの可否判断を行い、判断結果をネッ
トワーク機器に送信する。

【０００８】図２２はポリシーサーバを用いた従来のア
ドミッション制御説明図である。 (1) 端末(ユーザ)１は、reserveメッセージ(RESV)をル
ータ３に送信する。 (2) reserveメッセージ(RESV)を受信したルータ３はCOP
Sプロトコルに従って、予約要求を受理してよいか否か
をポリシーサーバ５へ問い合わせる。 (3) 問い合わせを受けたポリシーサーバ５は、予約要求
を送信した端末(ユーザ)１に予約の権利があるか否かを
判定する。

【０００９】(4) 予約要求を送信した端末(ユーザ)１に
予約する権利があれば、ポリシーサーバ５はルータ３に
予約を許可することを通知する。 (5) 予約許可を受けたルータ３は端末（ユーザ）１から
受信したreserveメッセージ(RESV)を次のルータ４に転
送する。 (6) ルータ４はルータ３と同様にCOPSプロトコルに従っ
て予約要求を受理してよいか否かをポリシーサーバ５へ
問い合わせ、以後、同様の動作を繰り返えす。 (7) 最終的にreserveメッセージ(RESV)を通信相手端末
２が受信すると、予約が終了する。つまり、予約要求端
末１と通信相手端末２との間のすべてのルータ３，４で
資源が確保され、予約要求端末１と通信相手端末２の通
信品質が保証される。以上のようにPBNアーキテクチャでは、ポリシー情報を
ポリシーサーバに与えるだけで、複数の機器に対するア
ドミッション制御ができ、これにより各ルータ毎にポリ
シー情報を設定することが不要になる。

【００１０】大規模なネットワークにおけるアドミッシ
ョン制御には、複数のポリシーサーバが必要になり、各
ポリシーサーバで参照するポリシー情報の一元管理が課
題になる。この解決案としては図２３に示すようにディ
レクトリサーバ６を設け、該ディレクトリサーバ６がユ
ーザ情報、アプリケーション情報、ネットワーク機器情
報、ポリシー情報などを統合管理することである。ポリ
シーサーバ５ａ，５ｂとディレクトリ６間の情報授受は
周知のLDAP(Lightweight Directory AccessProtocol)に
従って行い、ネットワーク機器とポリシーサーバ間の情
報授受はCOPS(common open policy protocol)プロトコ
ルに従って行う。

【００１１】（ｂ） COSPプロトコル COPSプロトコルは、現在IETFで策定中のポリシ制御プロ
トコルであり、一元管理メカニズムにおいて、ポリシサ
ーバとクライアント（ルータ等）間の情報交換を行うプ
ロトコルとしてこれらに実装される。COPSプロトコルは
図２４に示すメッセージ、図２５に示すオブジェクトを
有している。ポリシーサーバ（PDP：Policy Decision P
oint）、クライアント(PEP：Policy Enforcement Point
s)は、これらメッセージ、オブジェクトを組み合わせて
送信情報を作成し、該情報の送受を行い、ポリシーサー
バPDPのポリシーに基づいてクライアントPEPの制御、資
源管理等を可能にしている。

【００１２】(b-1) メッセージメッセージには図２４に示すように、(1) Request (RE
Q)、(2) Decision (DEC)、(3) Report State(RPT)、(4)
Delete Request State (DRQ)、(5) SyncronizeState R
eq (SSQ)、(6) Client-Open(OPN)、(7) Client-Accept
(CAT)、(8) Keep-Alive(KA)、(9) Client-Close(CC)、
(10) Synchronize State Complete(SSC)の10種類があ
る。 (1) Request (REQ)：REQメッセージは、クライアントPE
PからサーバPDPに設定指示を要求する際に使用されるメ
ッセージである。REQメッセージは以前に要求した設定
内容の更新要求にも使用され、その際は、以前に発行し
たREQメッセージと同じハンドル値(後述)を含む。

【００１３】(2) Decision (DEC)：DECメッセージには2
種類ある。第1のメッセージはsolicitedなDECメッセー
ジ(要求に対する応答メッセージ)である。この第1のDEC
メッセージは、クライアントPEPからサーバPDPに出され
たポリシー決定の問い合わせ要求(REQ)について、サー
バPDPより応答するメッセージであり、問い合わせ結果
のデシジョンが含まれている。REQメッセージの内容が
エラーのときは、このDECメッセージにエラー情報が設
定されて返される。第２のメッセージは、unsolicited
なDECメッセージで、サーバPDPが一方的にデシジョンを
与えるためのメッセージである。 (3) Report State(RPT)：RPTメッセージは、サーバPDP
からDECメッセージを受けたクライアントPEPが、その設
定処理を遂行できたか、できなかったかを返答するため
に使用するメッセージである。

【００１４】(4) Delete Request State (DRQ)：DRQメ
ッセージはクライアントPEPからのみ発行されるメッセ
ージで、それまでREQメッセージやDECメッセージで使用
されていたハンドル値の削除、又、そのハンドル値に関
連付けられたリクエストステート状態(設定状態)を削除
するものである。クライアントPEPがDRQメッセージによ
って明示的に削除しないリクエストステートは、クライ
アントPEP，サーバPDPの両者で保持しつづけられる。 (5) Syncronize State Req (SSQ)：SSQメッセージは、
サーバPDPがクライアントPEPへハンドル値で指定したリ
クエストステート情報をREQメッセージで再送するよう
に要求するメッセージである。 (6) Client-Open(OPN)：OPNメッセージは、クライアン
トPEPからサーバPDPへCOPSセッションの開始を要求する
メッセージである。

【００１５】(7) Client-Accept(CAT)：CATメッセージ
は、サーバPDPがOPNメッセージに対して接続許可を与え
るメッセージである。このメッセージ中には、サーバPD
Pから指定するKeep-Aliveのタイマ値や定期RPTメッセー
ジの送信間隔(ACCTタイマ)値が入っている。 (8) Keep-Alive(KA)：KAメッセージはクライアントPEP
とサーバPDPの間で何の通信活動も行われないとき、コ
ネクション維持のために送信されるメッセージである。
送信タイミングは、クライアントPEPで作られる。クラ
イアントPEPは、サーバPDPとの間で何の通信活動もされ
なくなってから、その基本KAタイマ値の1/4〜3/4が経過
したときにKAメッセージを送信する。サーバPDPでは、
クライアントPEPからのKAメッセージを受信したタイミ
ングでKAメッセージをクライアントPEPに送信をする。
クライアントPEP、サーバPDPの両者はCATメッセージで
指定されたKAタイマ値が示す時間を経過しても何の通信
活動もなされなかったとき、コネクションがダウンして
いると判断する。

【００１６】(9) Client-Close(CC)：CCメッセージは、
COPSセッションの終了を通知するためのメッセージであ
る。その要因としてエラーコードを設定しなければなら
ない。 (10) Synchronize State Complete(SSC)：SSCメッセー
ジは同期要求SSQメッセージに対して、同期要求が完了
したことを通知するメッセージである。クライアントPE
Pは、SSQメッセージ受信後、同期のためのREQメッセー
ジをすべて送信した後、このメッセージを送信する。

【００１７】上記10種類の各COPSメッセージは図２６に
示す共通のCOPSヘッダを持ち、その共通ヘッダの下に図
２７に示すフォーマットを有するオブジェクトが複数接
続する構成を有している(図３０に複数オブジェクトを
有するREQメッセージが、図３１に複数オブジェクトを
有するDECメッセージがそれぞれ示されている)。COPS共
通ヘッダ(図２６)において、CH1は4ビットのCOPSバージ
ョン番号、CH2はメッセージのオペレーションコード（8
ビット)、CH3はクライアントタイプ、CH4はメッセージ
長である。オペレーションコードCH2はメッセージを識
別するもの、クライアントタイプCH3はクライアントを
識別するもので、企業固有の値を有し、オブジェクトの
解釈はこのクライアントタイプに依存する。メッセージ
長CH4はオクテット長で表されるサイズで、COPS共通ヘ
ッダ、カプセル化された全てのオブジェクトが含まれ
る。

【００１８】(b-2) オブジェクトオブジェクトは図２５に示す16種類があり、それぞれ、
図２７に示すフォーマットを備えている。OB1はオブジ
ェクト長で、オブジェクトを構成するヘッダを含むオク
テット数、OB2はオブジェクトに含まれる情報（オブジ
ェクト内容）を識別するためのクラス番号(C-Num)、OB3
はクラスタイプ(C-Type)で、オブジェクトに含まれる情
報のサブタイプ、バージョン等を識別するもの、OB4は
オブジェクト内容である。主要なオブジェクトは以下の
意味を有している。 (1) ハンドルオブジェクト(C-Num=１、C-Type=１):ハン
ドルオブジェクトは、インストール（設定）されたリク
エストステートを識別するためのユニークな値(ハンド
ル値)をカプセル化するもので、図２８(Ａ)に示すフォ
ーマットを有している。ハンドル値はクライアントPEP
により最初に選ばれ、不要になったらクライアントPEP
によって削除される。REQメッセージ、RPTメッセージ、
DRQメッセージでハンドル値を指定し、サーバPDPではこ
のハンドル値によりクライアントPEPの要求を一意に識
別する。

【００１９】(2) コンテキストオブジェクト(C-Num=3、
C-Type=１)：コンテキストオブジェクトはREQメッセー
ジによる要求(問い合わせ)のトリガとなったイベントタ
イプを指定するもので、図２８(Ｂ)に示すフォーマット
を有している。16ビットのR-Type(Request Type Flag)
は0001,002,004,0008の値をとり、以下の要求 0001:アドミッション制御要求 0002:リソース割り当て要求 0004:出力メッセージ要求 0008:コンフィギュレーション要求をするものである。尚、コンフィギュレーション要求
は、キュー構成情報(キュー数、各キューの帯域、優先
度オン/オフ)、フィルタエントリ情報(どのフローをキ
ューにエンキューするか決定する情報)、その他の情報
の設定を要求するものである。

【００２０】(3) デシジョンオブジェクト(C-Num=7、C-
Type=1または5):デシジョンオブジェクトはサーバPDPに
よって行われるデシジョンをDECメッセージでクライア
ントPEPに通知するオブジェクトであり、図２８（Ｃ）
に示すように、クライアントタイプに依存しないデシジ
ョンオブジェクト(C-Num=7,C-Type=1)とクライアントタ
イプに依存するデシジョンオブジェクト(C-Num=7,C-Typ
e=5)がある。クライアントタイプに依存しないデシジョ
ンオブジェクトは以下に示すフラグによりデシジョンを
通知するものである。又、クライアントタイプに依存す
るデシジョンオブジェクトはNamed Decision データを
添付してクライアントPEPのコンフィグレーション、リ
ソースの割り当て等を指示するものである。クライアン
トタイプに依存しないデシジョンオブジェクト(C-Num=
7,C-Type=1)のフラグには0x01, 0x08, 0x10、 0x20, 0x
40, 0x200があり、それぞれ以下の意味を有している。

【００２１】 0x01：Admit Signaled(フラグがセットされるとリクエ
ストREQ拒絶) 0x08：トリガエラー(フラグがセットされるとトリガエ
ラーメッセージ) 0x10：Null configuration(フラグがセットされるとcon
figuration無し) 0x20：Install configuration(フラグがセットされると
named data 設定) 0x40：Remove configuration(フラグがセットされると
named data 除去) 0x200：Soliciated Decision (フラグがセットされると
REQメッセージに対するsolicited Decisionメッセージ
であることを意味する)。

【００２２】(4) エラーオブジェクト(C-Num=9、C-Type
=１):エラーオブジェクトは特定のCOPSプロトコルエラ
ーを識別するためのもので、図２８（Ｄ）に示すフォー
マットを有している。エラーコード１はハ．ンドル値が
正しくないことを意味するもの、エラーコード３はサー
バPDPが受信したREQメッセージの異常を認識した場合、
DECメッセージに付加するエラーオブジェクトのエラー
コード、...、エラーコード９はＫＡ受信タイムアウト
発生時にＣＣメッセージに付加するエラーオブジェクト
のエラーコードである。 (5) クライアント特定情報オブジェクト(C-Num=10、C-T
ype=2):このオブジェクトはクライアントを特定する情
報を示すもので図２８（Ｅ）に示すフォーマットを有
し、REQメッセージ, OPNメッセージ, RPTメッセージ等
で必要とされる。クライアント特定情報ClientSIは、例
えば、ルータであればインタフェースカード名等であ
る。

【００２３】(6) KeepAliveタイマオブジェクト(C-Num=
11、C-Type=1):このオブジェクトはＫＡタイマ値をセッ
トするもので、図２８（Ｆ）に示すフォーマットを有し
ている。 (7) レポートタイプオブジェクト(C-Num=13、C-Type=
1):レポートタイプオブジェクトはクライアントPEPにDE
Cメッセージで指示された設定の成功/失敗(Named confi
gurationの設定成功/失敗)をRPTメッセージでサーバPDP
に報告するためのオブジェクトであり、図２８（Ｇ）に
示すフォーマットを有している。Report-Typeとして1〜
7があり、以下の意味を有している。 Report-Type 1= Commit(クライアントPEPのローカル資
源が割り当てられた) Report-Type 2= Accounting Report-Type 3=No Commit (クライアントPEPの資源割り
当て失敗) Report-Type 4=Installed (Named Configuration がイ
ンストールされた) Report-Type 5=Removed (Named Configuration が削除
された) Report-Type 6=Not Installed (Named Configuration
がインストールできなかった) Report-Type 7=Not Removed (Named Configuration が
削除できなかった)

【００２４】(b-3) REQ/DECメッセージ通信図２９はREQ/DECメッセージ通信の手順説明図であり、
クライアントPEPからサーバPDPに対してREQメッセージ
で設定の指示を要求し、サーバがポリシー情報に基づい
て要求に対する判断を行い、判断結果（設定指示）をク
ライアントPEPにDECメッセージで通知する場合である。 (1) クライアントPEPは図３０に示すREQメッセージ(REQ
#n)を作成し、例えば帯域割り当てを実行して良いか否
かの判断をサーバPDPに要求する。尚、REQメッセージの
ハンドル値#nはリクエストREQを識別するものであり、
クライアントPEPにより削除されるまで、サーバPDP、ク
ライアントPEPにインストールされる。以後、この要求
に対する応答、変更、削除は該ハンドル値を参照して行
われる。

【００２５】(2) サーバPDPはREQメッセージ(REQ#n)を
受信すると、ポリシー情報に基づいて該REQメッセージ
で要求された帯域の割り当てが可能であるか不可能であ
るかを判断し、判断結果に基づいて図３１に示すDECメ
ッセージを作成してクライアントPEPに送信する。この
例ではDECメッセージは「ユーザＡに３Ｍバイトの帯域
を確保」する指示を含んでいる。 (3) クライアントPEPは、DECメッセージを受信すれば、
該DECメッセージの指示に従ってユーザＡに３Ｍバイト
の帯域を確保するための設定を行う。又、クライアント
PEPは設定結果、すなわち、DECメッセージで指示された
帯域を確保できたか否かをサーバPDPにRPTメッセージ
(図３１）を作成して報告する。このRPTメッセージによ
り、サーバPDPは帯域確保が成功したことを認識する。

【００２６】(4) 以後、サーバPDPはネットワーク環境
の変化等により、すでに判断を行ったREQメッセージREQ
#nの要求に対して追加の判断をすれば、該追加判断結果
に基づいてDECメッセージ(DEC#n(unsolicited))をクラ
イアントPEPに送信する。 (5) クライアントPEPは、DECメッセージを受信すれば、
該DECメッセージの指示に従った設定変更を行う。又、
クライアントPEPは設定結果をサーバPDPにRPTメッセー
ジを作成して報告する。

【００２７】

【発明が解決しようとする課題】以上のように、COPSメ
ッセージ通信では、サーバPDPはクライアントPEPから設
定指示要求があった時、ポリシー情報に基づいて判断
し、判断結果をクライアントに応答するものであり、あ
らかじめREQメッセージによりハンドル値を指定されな
い限り、DECメッセージの自発的な発信は行わない。そ
のため、図２９に示したようにポリシーの判断要求は常
にクライアントPEPからの発信となり、要求がない限
り、サーバPDPはクライアントPEPに何らの設定指示も行
わず、その状態を管理、制御することはしない。しかし
ながら、ネットワークの一元管理システムにおいて、よ
り効率的なネットワーク上の資源の活用、より満足度の
高いサービスの提供を実現するには、サーバが、ネット
ワークの状況の変化を把握し、それに応じた最適な設定
をクライアントに行うのが望ましい。そのためには、ク
ライアントからの要求を待つ従来のメッセージ通信方法
では、不十分であり、サーバが必要性を感じた時に、自
発的にクライアントに多様な設定のためのメッセージを
送ることができる通信システムが必要である。

【００２８】以上から本発明の目的は、クライアントへ
の設定をサーバ主導で行えるようにし、サーバが必要に
応じて自発的にクライアントに設定を指示できるように
することである。本発明の別の目的は、クライアントに
対する個々の設定を識別し、各設定を個別に管理(変
更、削除)できるようにすることである。

【００２９】

【課題を解決するための手段】第１の本発明では、クラ
イアントであるネットワーク機器(ルータ等)とサーバで
あるネットワーク機器制御装置間でクライアント・サー
バ型のプロトコルに従って情報送受を行う通信システム
において、クライアントは、サーバに主導権を付与する
サーバ主導権許可メッセージを送信し、サーバは該メッ
セージ受信後、該クライアントに対し、サーバ主導で所
定の設定を指示するメッセージを順次送信し、クライア
ントは該設定メッセージに基づいて複数の異なる設定を
行う。このようにすれば、サーバが必要性を感じた時
に、自発的にクライアントに多様な設定のためのメッセ
ージを送ることができる。

【００３０】又、第２の本発明では、クライアントであ
るネットワーク機器(ルータ等)とサーバであるネットワ
ーク機器制御装置間でクライアント・サーバ型のプロト
コルに従って情報送受を行う通信システムにおいて、ク
ライアントは、サーバに主導権を付与するサーバ主導権
許可メッセージを送信し、サーバは該メッセージの受信
によりサーバ主導で該クライアントに必要な設定を指示
するメッセージを送信し、クライアントは該メッセージ
により指示された設定を行うと共にサーバに新たなサー
バ主導権許可メッセージを送信し、以後同様にしてサー
バからの各設定を独立して管理する。以上のようにすれ
ば、サーバが必要性を感じた時に、クライアントに自発
的に多様な設定のためのメッセージを送ることができ、
しかも、サーバからの各設定を異なるハンドル値で識別
可能に管理できる。

【００３１】

【発明の実施の形態】（ａ）ネットワークの構成図１は本発明のネットワークの構成図である。１１，１
２はパソコン等のエンド端末（ホスト装置）、１３₁〜
１３₃はネットワークを構成するルータでありクライア
ントとして動作するもの、１４はポリシー情報に基づい
てクライアントに各種設定を行うポリシーサーバ、１５
はディレクトリサーバである。ディレクトリサーバ１５
は、運用ポリシー情報、ユーザに関する情報(ユーザ情
報)、ルータ等の機器固有情報、トポロジ/経路情報等を
データベースとして備えている。ポリシーサーバ１４も
一部それらの情報を備えているが、必要に応じてディレ
クトリサーバ１５より自分が保有していないそれら情報
をLDAP(Lightweight Directory Access Protocol)に従
って取得する。

【００３２】図２はユーザ情報例であり、ユーザＡの属
性とし、ユーザ識別子、ユーザが専らアクセスする
重要ホストのIPアドレス、ユーザがネットワークを利
用する時の優先度、ユーザがネットワークを使用する
ときの帯域、その他のユーザ固有情報を保持してい
る。図３はルータ情報例であり、ルータＡの属性とし
て、ルータのIPアドレス、キュー制御方式(priorit
yという名前が入っており、優先制御方式であることを
意味している)、キュー数(=2)、設定プロトコル（C
OPS)、キューそれぞれの名前（キュー１、キュー
２）、各キューの属性(優先度、帯域等)、その他ル
ータ固有情報を保持している。図４はルータ１３の優先
制御方式の説明図であり、優先度１（高優先度）のキュ
ー１３ａと、優先度２（低優先度）のキュー１３ｂと、
入力パケットをキュー１３ａ，１３ｂに振り分ける振り
分け部１３ｃと、高優先度のキュー１３ａよりパケット
を到来順に読出して出力し、高優先度キューにパケット
が存在しないときのみ低優先度キュー１３ｂよりパケッ
トを到来順に読出して回線に出力する読出し制御部１３
ｄを有している。所定のパケットを高優先処理するに
は、パケット識別データと共に該パケットを高優先度で
処理することを振り分け部１３ｃに設定する(フィルタ
エントリ)。これにより、振り分け部１３ｃは到来する
パケットのうち該識別データを有するパケットを高優先
度キュー１３ａに入力し、高優先処理する。

【００３３】図５はトポロジ情報の説明図であり、(c)
に示すようにルータＡ〜Ｅが接続されている場合、ルー
タＡのトポロジ情報は(a) に示すように隣接ルータのIP
アドレスをリストとしたものとなり、ルータＢのトポロ
ジ情報は(b) に示すように隣接ルータのIPアドレスをリ
ストとしたものとなる。すなわち、(a)は192.168.15.1
というIPアドレスを有するルータＡが３つのルータＢ〜
Ｄに接続されていることを表現している。３つのルータ
のうち、192.168.10.1というアドレスを持つルータＢに
関しては、(b)に示すように隣接する２つのルータＡ，
Ｅがあることを示している。このようにあるルータが接
続されているルータを列挙したものを１つの表として表
現し、それをノードの個数分用意することでネットワー
クのトポロジを表現して保持する。

【００３４】図６はポリシーサーバの構成図であり、デ
ータベース部１４ａ、イベント検出部１４ｂ、設定判定
部１４ｃ、設定機器選択部１４ｄ、設定情報生成部１４
ｅ、設定情報送信部１４ｆを備えている。データベース
１４ａは、トポロジ／経路情報及び機器固有情報を保持
する網リソース情報保持部14a-1、ユーザ情報及び運用
ポリシー情報を保持するポリシー情報保持部14a-2を備
え、適宜必要な情報をLDAPプロトコルに従ってディレク
トリサーバ１５より補充するようになっている。イベン
ト検出部１４ｂや設定情報送信部１４ｆは、COPSプロト
コルに従ってホスト１１，１２やルータ１３〜１３₃と
の間でメッセージの送受を行う。イベント検出部１４ｂ
は、ホストやルータから入力するCOPSメッセージを受信
し、該メッセージに基づいてそれらからの要求を識別、
検出する。設定判定部１４ｃはイベントに基づいてルー
タなどに所定の設定を行うべきであるか否かを判断す
る。例えば、ユーザ（ホスト１１）から帯域Ｂ、優先度
Ｐ、ホスト１２宛の通信が要求された時、設定判定部１
４ｃはユーザ情報を参照し、ユーザに該要求された帯域
Ｂ、優先度Ｐの通信が許されているか調べる。許されて
いなければ通信要求を拒絶し、許されていれば設定機器
選択部１４ｄにホスト１１−１２間の経路上のルータの
選択を指示する。

【００３５】設定機器選択部１４ｄは設定判定部１４ｃ
からの指示に基づいてイベントに応じた所定の設定をす
べきルータを選択する。上記例では、設定機器選択部１
４ｄはIPルーチングプロトコル(例えばOSPF:open short
est path first protocol)に基づいてホスト１１−１２
間の経路上のルータ１３₁〜１３₃を選択する。設定情報
生成部１４ｅは、選択されたルータ１３₁〜１３₃の機器
固有情報とユーザからの要求に基づいて該ルータに設定
すべき内容を含むメッセージ(DECメッセージ)を作成
し、該メッセージをCOPSプロトコルに従って設定情報送
信部１４ｆよりルータ１３₁〜１３₃に送信する。

【００３６】（ｂ）サーバ主導のポリシー制御従来のポリシー制御において、ポリシーサーバはクライ
アントであるルータから要求があった時のみ、ポリシー
情報に基づいて所定の設定をクライアントに行うもので
自発的な設定指示はしない。これに対して、本発明で
は、クライアントよりポリシーサーバに対してサーバ主
導権許可メッセージを送信し、ポリシーサーバは該主導
権許可メッセージを受信すれば、以後サーバ主導で自発
的に任意の設定指示をクライアントに行う。このポリシ
ー制御には２つの方法がある。

【００３７】(b-1) 第１のポリシー制御手順図７は本発明のサーバ主導による第１のポリシー制御手
順説明図である。 (1) クライアント１３は、自分自身が設定可能となる
と、サーバ１４に主導権を付与するために、図８に示す
REQメッセージREQ#n（サーバ主導権許可メッセージ）を
該サーバに発信する。但し、REQメッセージREQ#nをサー
バ主導権許可メッセージとするには、クライアント特定
情報オブジェクトOBJcにおけるクライアント特定情報
（ClientSI)を空(Null)にする。

【００３８】(2) サーバ１４は、サーバ主導権許可メッ
セージの受信後、所定の項目についてクライアント１３
に設定の必要が生じれば、該設定を指示するDECメッセ
ージ(DEC#n)を作成してクライアント１３に発信する。
この場合、DECメッセージのハンドル値はサーバ主導権
許可メッセージのハンドル値#nと同じである。クライア
ント１３はDECメッセージDEC#nが指示する設定を行い、
RPTメッセージ(図示せず)により設定結果をサーバ１４
に通知する。図９はDECメッセージ(DEC#n)の例であり、
ディシジョンオブジェクトOBJdに設定指示を記述したNa
med Decision データNDDを添付することにより、サーバ
１４はクライアント１３のコンフィグレーションやリソ
ース割り当て等の管理、制御を実現する。Named Decisi
on データによるポリシーの実行要求(設定指示)として
は、例えば、“ユーザＡに３Ｍバイトの帯域を確保”、
“ユーザＢに高優先度を与える”等がある。 (3)以後、サーバ１４はクライアント１３に設定の必要
が生じる毎に、サーバ主導権許可メッセージと同一のハ
ンドル値#nを有するDECメッセージ(DEC#n)を作成してク
ライアント１３に発信し、所定の設定を指示する。以上
により、サーバ主導でネットワーク状態に応じた設定を
指示するDECメッセージ(DEC#n)を順次クライアント１３
に送信し、クライアント１３は該DECメッセージの設定
指示に基づいて複数の異なる設定を行う。以上では、RE
Qメッセージにおけるクライアント特定情報（ClientSI)
がNullであるか否かで主導権許可メッセージであるか否
かを区別したが、クライアント特定情報（ClientSI)を
サーバ１４とクライアント１３間で合意のとれた任意の
記述（例えば“all”)とすることで主導権許可メッセー
ジであるか否かを区別することもできる。

【００３９】(b-2) 第２のポリシー制御手順図１０は本発明のサーバ主導による第２のポリシー制御
手順説明図である。 (1) クライアント１３は、自分自身が設定可能となる
と、サーバ１４に主導権を付与するために、図８に示す
REQメッセージ（ハンドル値#nのサーバ主導権許可メッ
セージ）を該サーバに発信する。 (2) サーバ１４は、サーバ主導権許可メッセージの受信
後、所定の項目についてクライアント１３に設定の必要
が生じれば、該設定を指示するDECメッセージ(DEC#n)を
作成してクライアント１３に発信する。この場合、DEC
メッセージのハンドル値はサーバ主導権許可メッセージ
のハンドル値#nと同じである。すなわち、サーバ１４は
ある項目について設定の必要が生じた際（例えば，ルー
タ障害に伴い、関連するルータのルーティング情報をサ
ーバが一括して変更する場合、あるいは各ルータを通過
するトラフィック量を制限する場合など）、DECメッセ
ージでクライアント１３に必要な設定を指示する。

【００４０】(3) クライアント１３は該DECメッセージ
(DEC#n)が指示する設定を行い、RPTメッセージ(図示せ
ず)により設定結果をサーバ１４に通知する。しかる
後、クライアント１３は、サーバ１４に主導権を付与す
るためのREQメッセージ（ハンドル値#n+1のサーバ主導
権許可メッセージ）を発信する。 (4) サーバ１４は、サーバ主導権許可メッセージの受信
後、別の項目についてクライアント１３に設定の必要が
生じれば、該設定を指示するハンドル値#n+1のDECメッ
セージ(DEC#n+1)を作成してクライアント１３に発信す
る。 (5) クライアント１３はDECメッセージ(DEC#n+1)が指示
する設定を行う。又、RPTメッセージ(図示せず)により
設定結果をサーバ１４に通知する。しかる後、クライア
ント１３は、サーバ１４に主導権を付与するためのREQ
メッセージ（ハンドル値#n+2のサーバ主導権許可メッセ
ージ）を発信する。 (6) 以後、サーバ、クライアントは上記と同様の処理を
クライアントが設定可能な状態にある限り、ハンドル値
をインクリメントしながら繰り返す。

【００４１】（ｃ）サーバ主導による設定の具体例 (c-1) ルータ起動時におけるデフォルト値の設定図１１はポリシーサーバ１４からの自発的な設定指示に
よるコンフィグレーション設定例であり、ルータ起動時
にデフォルト設定する場合の説明図である。ただし、サ
ーバ主導による第２のポリシー制御手順(図１０）に従
ってデフォルト設定するものとする。 (1) 起動時、クライアントとしてのルータ１３₁〜１３₃
はサーバ１４に主導権を与えるためのREQメッセージREQ
#1（主導権許可メッセージ）を発信する。 (2) ポリシーサーバ１４は主導権許可メッセージを受信
すれば、必要に応じてディレクトリサーバ１５から該ク
ライアントのルータ情報を取得し、該ルータ情報に基づ
いてデフォルトのキュー構成（キュー数、各キューの優
先度、帯域など）を構築する。ついで、該キュー構成を
クライアントに設定するためのDECメッセージDEC#1を作
成してクライアントに送信する。

【００４２】(3) クライアント１３₁〜１３₃はDECメッ
セージ(DEC#1)が指示するキュー構成の設定を行い、RPT
メッセージRPT#1により設定結果(例えば設定成功)をサ
ーバ１４に通知する。 (4) しかる後、クライアント１３₁〜１３₃は、サーバ１
４に主導権を付与するためのREQメッセージ（ハンドル
値#2のサーバ主導権許可メッセージ）を発信する。 (5) サーバ１４は、新たなサーバ主導権許可メッセージ
を受信すれば、ルータ情報に基づいてデフォルトのフィ
ルタエントリ情報を作成する。ついで、該フィルタエン
トリ情報をクライアントに設定するためのDECメッセー
ジDEC#2を作成してクライアントに送信する。以後、サ
ーバ１４は上記と同様に各種設定処理をクライアント１
３₁〜１３₃が設定可能な状態にある限り、ハンドル値を
インクリメントしながら繰り返す。

【００４３】(c-2) ユーザからの要求に従い、キュー構
成を変更図１２はユーザからの要求に従い、ポリシーサーバ主導
でキュー構成を変更する具体例である。 (1) クライアントとしてのルータ１３₁〜１３₃はサーバ
１４に主導権を与えるためのREQメッセージREQ#1（主導
権許可メッセージ）を発信する。 (2) ポリシーサーバ１４は主導権許可メッセージを受信
すれば、ネットワーク状態の変化に伴うクライアントへ
の新規設定、設定変更をサーバ主導で行う。例えば、ホ
スト１１（ユーザＡ）からホスト１２（ユーザＢ）宛の
通信要求が発生すると、ポリシーサーバ１４はディレク
トリサーバ１５より必要に応じてユーザＡのユーザ情報
及びルータのトポロジ情報を取得する。ついで、ポリシ
ーサーバ１４は、ルータのトポロジ情報とユーザＡ，Ｂ
のIPアドレスから、ダイクストラDijkstraのアルゴリズ
ムを用いて最短パスを計算し、ユーザＡからユーザＢへ
のIPルーチング情報を求め、該ＩＰルーチング情報を用
いて、ユーザＡ，Ｂ間を中継するルータ１３₁〜１３₃を
特定する。又、ユーザＡ情報より帯域（＝3MB)及び優先
度（=8）を把握する。

【００４４】(3) ついで、帯域3MBの優先キューをクラ
イアント１３₁〜１３₃に構築するためのDECメッセージD
EC#1を作成してクライアントに送信する。 (4) クライアント１３₁〜１３₃はDECメッセージ(DEC#1)
が指示する優先キューの構築を行い、RPTメッセージRPT
#1により設定結果(例えば設定成功)をサーバ１４に通知
する。 (5) しかる後、クライアント１３₁〜１３₃は、サーバ１
４に主導権を付与するための新たなREQメッセージ（ハ
ンドル値#2のサーバ主導権許可メッセージ）を発信す
る。

【００４５】(6) サーバ１４は、新たなサーバ主導権許
可メッセージREQ#2を受信すれば、優先キューにユーザ
ＡからユーザＢ宛のフローをエンキューするためのフィ
ルタエントリ情報を作成する。ついで、該フィルタエン
トリ情報をクライアントに設定するためのDECメッセー
ジDEC#2を作成してクライアント１３₁〜１３₃に送信す
る。 (7) クライアント１３₁〜１３₃はDECメッセージ(DEC#2)
が指示するフィルタエントリ情報の設定を行い、RPTメ
ッセージRPT#2により設定結果(例えば設定成功)をサー
バ１４に通知する。これにより、ユーザＡ→Ｂへの3MB
の帯域が保証される。 (8) しかる後、クライアント１３₁〜１３₃は、サーバ１
４に主導権を付与するための新たなREQメッセージREQ#3
（ハンドル値#3のサーバ主導権許可メッセージ）を発信
する。以後、サーバ１４はクライアント１３₁〜１３₃が
設定可能な状態にある限り、ネットワーク状態の変化に
従って適宜各クライアントに所定の設定あるいは設定変
更を行う。

【００４６】(c-3) 障害時のルーチング情報の変更 CATメッセージで指定されたKeep-Aliveのタイマ値の1/4
〜3/4が経過してもポリシーサーバ１４とクライアント
１３₁〜１３₃間で何の通信活動も行われなければ、クラ
イアントはポリシーサーバに対してKAメッセージを送信
し、ポリシーサーバ１４はクライアントからのKAメッセ
ージ受信により該クライアントにKAメッセージ送信をす
る。この結果、KAタイマ値が示す時間内にKAメッセージ
を受信することによりクライアント、ポリシーサーバは
コネクションが正常であると認識する。しかし、KAタイ
マ値が示す時間内に何の通信活動も無ければ、ポリシー
サーバ１４はクライアントがダウンしたと判断する。

【００４７】図１３は障害時のルーチング情報の変更を
ポリシーサーバ主導で行う具体例である。 (1) クライアントとしてのルータ１３₁〜１３₃はポリシ
ーサーバ１４に主導権を与えるためのREQメッセージREQ
#n（主導権許可メッセージ）を発信する。ポリシーサー
バ１４は主導権許可メッセージを受信すれば、ネットワ
ーク状態の変化に伴うクライアントへの新規設定、設定
変更をサーバ主導で行う。 (2) かかる状態において、KAタイマ値が示す時間内にポ
リシーサーバ１４とクライアント１３₂間で何の通信活
動も無ければ、(3) ポリシーサーバ１４はクライアント
１３₂がダウンしたと判断する。 (4) ポリシーサーバ１４は、トポロジ情報より障害発生
クライアント１３₂に隣接するクライアント１３₁，１３
₃を求める。ついで、クライアント１３₁に対しそのルー
チングテーブルよりルータ１３₂へのパスを削除するた
めのDECメッセージDEC#nを作成して送信する。又、クラ
イアント１３₃に対しそのルーチングテーブルよりルー
タ１３₂へのパスを削除するためのDECメッセージDEC#n
を作成して送信する。

【００４８】(5) クライアント１３₁，１３₃はDECメッ
セージDEC#nによりルーチングテーブルよりクライアン
ト１３₂へのパスを削除し、削除結果を図示しないRPTメ
ッセージでサーバ１４に通知し、しかる後、ポリシーサ
ーバ１４に主導権を与えるための新たなREQメッセージR
EQ#n+1（主導権許可メッセージ）を発信する。 (6) サーバ１４は主導権許可メッセージを受信すれば、
クライアント１３₁に対しそのルーチングテーブルにル
ータ１３₄へのパスを追加設定するためのDECメッセージ
DEC#n+1を作成して送信する。又、クライアント１３₃に
対しそのルーチングテーブルにルータ１３₄へのパスを
追加設定するためのDECメッセージDEC#n+1を作成して送
信する。 (7) クライアント１３₁，１３₃はDECメッセージDEC#n+1
によりルーチングテーブルにクライアント１３₄へのパ
スを追加設定し、設定結果を図示しないRPTメッセージ
でサーバ１４に通知し、しかる後、ポリシーサーバ１４
に主導権を与えるための新たなREQメッセージREQ#n+2
（主導権許可メッセージ）を発信する。

【００４９】(8)〜(12) サーバ１４は新たな主導権許可
メッセージの受信後、クライアント１３₂が復旧する
と、クライアント１３₁，１３₃間で元のルーチングテー
ブルに戻すためのメッセージの送受を行う。 (13) 一方、復旧したクライアント１３₂は起動すると、
サーバ１４に主導権を与えるためのREQメッセージREQ#1
（主導権許可メッセージ）を発信する。 (14) サーバ１４は主導権許可メッセージREQ#1を受信す
れば、ディレクトリサーバ１５から該クライアントのル
ーチングテーブルを取得し、該ルーチングテーブルをク
ライアント１３₂に設定するためのDECメッセージDEC#1
を作成してクライアント１３₂に送信する。 (15) クライアント１３₂はDECメッセージ(DEC#２)が指
示するルーチングテーブルの設定を行い、RPTメッセー
ジにより設定結果(例えば設定成功)をサーバ１４に通知
すると共に、サーバ１４に主導権を付与するための新た
なREQメッセージREQ#2（ハンドル値#2のサーバ主導権許
可メッセージ）を発信する。以後、サーバ１４はクライ
アント１３₁〜１３₃が設定可能な状態にある限り、ネッ
トワーク状態の変化に従って適宜各クライアントに所定
の設定あるいは設定変更を行う。

【００５０】（ｄ）DECメッセージの受信監視タイマ処
理サーバ主導でクライアントに対し自発的に設定指示可能
な状態にあるためには、サーバが主導権許可メッセージ
を受信している必要がある。そのため、クライアントは
主導権許可メッセージを発信した時、該メッセージがサ
ーバに到着したことを認識する手段、および、メッセー
ジの到着を確認できなかった場合のリトライ処理を行う
手段が必要となる。本発明ではDECメッセージの受信監
視を行うことでこれら手段を提供する。

【００５１】(d-1) 主導権許可メッセージ受信応答有り
の場合図１４（Ａ）はDECメッセージの受信監視タイマ処理に
おいて、サーバより主導権許可メッセージの受信応答が
あった場合の手順説明図である。 (1) COPSクライアント１３はCOPSサーバ１４に主導権許
可メッセージ（クライアント特定情報ClientSI=ヌルのR
EQメッセージREQ#1)を発信する。 (2) 主導権許可メッセージ発信後、クライアント１３は
solicitedなDECメッセージ受信のための監視タイマー
をセットする。solicitedなDECメッセージとは、クライ
アントの要求に対するDEC応答である。 (3) 一方、サーバ１４は、クライアント１３から主導権
許可メッセージを受信すれば、ただちに、solicitedなD
ECメッセージDEC#1により、主導権許可メッセージを受
け取ったことを、クライアント１３に通知する。

【００５２】(4) クライアント１３は監視タイマ時間Ｔ
_S1以内にsolicitedなDECメッセージDEC#1を受信すれ
ば、正しく主導権許可メッセージがサーバに届いたと認
識してタイマをクリアし、サーバ１４からの設定指示を
待つ。 (5) 以後、ネットワークの変化等により、クライアント
１３に新たな設定あるいは設定変更をする必要が生じれ
ば、サーバ１４はunsolicitedなDECメッセージを作成し
てクライアントに発信する。クライアント１３はこのDE
Cメッセージに含まれる設定指示に基づいて所定の設定
を行う。unsolicitedなDECメッセージとは、既にクライ
アントから要求されたハンドル値#1を持つ主導権許可メ
ッセージREQ#1に対するサーバからの追加設定のDECメッ
セージである。

【００５３】(d-2) 主導権許可メッセージ受信応答無し
の場合図１４（Ｂ）はDECメッセージの受信監視タイマ処理に
おいて、サーバより主導権許可メッセージの受信応答が
ない場合の手順説明図である。 (1) クライアント１３は、サーバ１４に主導権許可メッ
セージREQ#1（ハンドル値が#1で、クライアント特定情
報ClientSIがヌルのREQメッセージ)を発信する。(2)
又、同時に、solicitedなDECメッセージ受信のための監
視タイマーをセットする。

【００５４】(3) クライアント１３は、監視タイマ時間
Ｔ_S1を越えてもsolicitedなDECメッセージDEC#1を受信
しなければ、通信障害とみなし、DRQメッセージDRQ#1を
サーバ１４に送信し、主導権許可メッセージREQ#1のハ
ンドル値#1を廃棄する。 (4) ついで、クライアント１３はサーバ１４に再度主導
権許可メッセージREQ#2（ハンドル値が#2で、クライア
ント特定情報ClientSIがヌルのREQメッセージ)を発信
し、(5) 同時に、solicitedなDECメッセージ受信のため
の監視タイマーをセットする。以後、監視タイマ時間Ｔ
_S1以内にsolicitedなDECメッセージDEC#1を受信すれ
ば、クライアント１３は正しく主導権許可メッセージが
サーバ１４に届いたと認識してタイマをクリアし、サー
バ１４からの設定指示を待つ。

【００５５】（ｅ）RPTメッセージの受信監視タイマ処
理サーバ主導でクライアントに対して自発的に設定を指示
するためには、サーバ１４がクライアント１３の状態を
一元的に管理する必要がある。そのためには、サーバか
らの設定指示に基づいたクライアントにおける設定結果
をサーバが知る手段、およびそれが実現できなかった場
合の復旧処理を行う手段が必要となる。本発明ではRPT
メッセージの受信監視を行うことでこれら手段を提供す
る。

【００５６】(e-1) RPTメッセージ受信有りの場合図１５（Ａ）はRPTメッセージの受信監視タイマ処理に
おいて、クライアントからのRPTメッセージの受信があ
った場合の手順説明図である。 (1) クライアント１３はサーバ１４に主導権許可メッセ
ージ（クライアント特定情報ClientSI=ヌルのREQメッセ
ージREQ#1)を発信する。 (2) サーバ１４は、クライアント１３から主導権許可メ
ッセージを受信すれば、ただちに、solicitedなDECメッ
セージDEC#1により、主導権許可メッセージを受け取っ
たことを、クライアント１３に通知する。 (3) クライアント１３はsolicitedなDECメッセージDEC#
1の受信により正しく主導権許可メッセージがサーバに
届いたと認識し、以後、サーバ１４からの設定指示を待
つ。

【００５７】(4) ネットワークの変化等により、クライ
アント１３に新たな設定(設定Ａ)をする必要が生じれ
ば、サーバ１４はunsolicitedなDECメッセージを作成し
てクライアントに発信する。 (5) 又、サーバ１４は、RPTメッセージ受信のための監
視タイマーをセットする。 (6) クライアント１３はこのDECメッセージに基づいて
設定Ａを行い、設定結果をRPTメッセージでサーバ１４
に通知する。 (7) サーバ１４は監視タイマ時間Ｔ_S2以内にRPTメッセ
ージRPT#1を受信すれば、タイマをクリアする。この結
果、サーバ１４はクライアント１３に要求した設定の実
行結果を知ることができ、クライアント１３の状態を一
元管理することができる。

【００５８】(e-1) RPTメッセージ受信応答無しの場合図１５（Ｂ）はRPTメッセージの受信監視タイマ処理に
おいて、クライアントからのRPTメッセージの受信がな
かった場合の手順説明図である。 (1) クライアント１３はサーバ１４に主導権許可メッセ
ージ（クライアント特定情報ClientSI=ヌルのREQメッセ
ージREQ#1)を発信する。 (2) サーバ１４は、クライアント１３から主導権許可メ
ッセージを受信すれば、ただちに、solicitedなDECメッ
セージDEC#1により主導権許可メッセージを受け取った
ことを、クライアント１３に通知する。 (3) クライアント１３はsolicitedなDECメッセージDEC#
1の受信により正しく主導権許可メッセージがサーバに
届いたと認識し、以後、サーバ１４からの設定指示を待
つ。

【００５９】(4) ネットワークの変化等により、クライ
アント１３に新たな設定(設定Ａ)をする必要が生じれ
ば、サーバ１４はunsolicitedなDECメッセージを作成し
てクライアントに発信する。 (5) 又、サーバ１４は、RPTメッセージ受信のための監
視タイマーをセットする。 (6) サーバ１４は設定時間Ｔ_S2が経過してもRPTメッセ
ージがクライアントより返ってこなければ、通信障害と
みなし、設定要求を出したDECメッセージと同じハンド
ル値#1を持つリクエストステートの削除要求を出す。 (7) クライアント１３はハンドル値#1のリクエストステ
ート削除指示に基づいて削除処理を行い、削除結果をRS
Tメッセージでサーバ１４に報告する。これにより、サ
ーバ１４はハンドル値#1のリクエストステートが削除さ
れたことを認識する。 (8) ついで、クライアント１３はDRQメッセージDRQ#1を
サーバ１４に送信し、主導権許可メッセージREQ#1のハ
ンドル値#1を廃棄するよう指示する。サーバ１４はDRQ
メッセージによりハンドル値＃１を削除する。以後、ク
ライアント１３は別のハンドル値#2を有する新たな主導
権許可メッセージREQ#2をサーバ１４に発信してサーバ
主導状態にする。

【００６０】（ｆ）メッセージ通信障害時における復旧
処理サーバ、クライアント間のメッセージ通信において、通
信障害が生じた場合、サーバ、クライアントそれぞれに
おける設定の不整合を防ぐ必要がある。すなわち、通信
障害時のメッセージに含まれるハンドル値が示す設定状
態（ステート）をサーバ、クライアントで互いに一致さ
せる必要がある。例えば、サーバ、クライアント間のメ
ッセージ通信において、ハンドル値#1を使ったサーバ１
４からの自発的な設定要求に対して、クライアント１３
からRPTメッセージが規定時間内に返ってこなければ、
以後のポリシ制御の確実性、メッセージの整合性を保つ
ために、ハンドル値#1を持つステートを全て削除し、再
設定しなくてはならない。しかし、図７のサーバ主導に
よる第１のポリシー制御では、１つのハンドル値#1に複
数のステートが関連づけられている可能性があり、それ
らのステートを全て求めて再設定する必要があり、多大
の時間を必要とする。そこで、本発明はクライアント及
びサーバの状態を迅速に障害前の同一状態に戻すため
に、サーバにおいてクライアントへの設定履歴を保存し
ておき、主導権許可メッセージの再受信後、該保存して
ある設定値をクライアントに再設定するようにする。

【００６１】(f-1) 第１の復旧処理図１６はメッセージ通信障害時における復旧処理手順説
明図である。 (1) クライアント１３はサーバ１４に主導権許可メッセ
ージ（クライアント特定情報ClientSI=ヌルのREQメッセ
ージREQ#1)を発信する。 (2) サーバ１４は、クライアント１３から主導権許可メ
ッセージを受信すれば、ただちに、solicitedなDECメッ
セージDEC#1により、主導権許可メッセージを受け取っ
たことを、クライアント１３に通知する。 (3) クライアント１３はsolicitedなDECメッセージDEC#
1の受信により正しく主導権許可メッセージがサーバに
届いたと認識し、以後、サーバ１４からの設定指示を待
つ。

【００６２】(4) ネットワークの変化等により、クライ
アント１３に新たな設定(設定Ａ)をする必要が生じれ
ば、サーバ１４はunsolicitedなDECメッセージDEC#1(設
定A)を作成してクライアントに発信する。 (5) 又、サーバ１４は、RPTメッセージ受信のための監
視タイマーをセットし、(6) 以後、設定時間Ｔ_S2内にRP
Tメッセージを受信するか監視する。 (7) 設定時間Ｔ_S2内にRPTメッセージを受信するとタイ
マーをクリアする。 (8) その後、クライアントに新たな設定(B,C,D)を行う
必要が生じれば、(4)〜(7)をくり返す。 (9) 設定時間Ｔ_S2が経過してもRPTメッセージがクライ
アントより返ってこなければ(タイムアウト)、通信障害
とみなす。 (10) タイムアウトにより、サーバ１４はハンドル値#1
の既存のリクエストステート(設定履歴A,B,C)を保存す
る。 (11) ついで、サーバ１４は、設定Ｄの要求を出したDEC
メッセージDEC#1と同じハンドル値#1で指示した設定(A,
B,C,D)の破棄要求を出す。

【００６３】(12) クライアント１３はハンドル値#1の
設定破棄指示に基づいて処理を行い、その結果をRPTメ
ッセージでサーバ１４に報告する。これにより、サーバ
１４はクライアントよりハンドル値#1で指示した設定
(A,B,C,D)が破棄されたことを認識する。 (13) ついで、クライアント１３はDRQメッセージDRQ#1
をサーバ１４に送信し、主導権許可メッセージREQ#1の
ハンドル値#1を削除するよう指示する。サーバ１４はDR
Qメッセージによりハンドル値＃１を削除する。 (14) 以後、クライアント１３は別のハンドル値#2を有
する新たな主導権許可メッセージREQ#2（クライアント
特定情報ClientSI=ヌルのREQメッセージREQ#2）を発信
してサーバ主導状態にする。

【００６４】(15) サーバ１４は、クライアント１３か
ら主導権許可メッセージを受信すれば、ただちに、soli
citedなDECメッセージDEC#2により主導権許可メッセー
ジを受け取ったことを、クライアント１３に通知する。 (16) クライアント１３はsolicitedなDECメッセージDEC
#2の受信により正しく主導権許可メッセージがサーバに
届いたと認識し、以後、サーバ１４からの設定指示を待
つ。 (17) サーバ１４はsolicitedなDECメッセージDEC#2送出
後、(8)で保存してあるステート(A,B,C)をクライアント
に再設定するために、該ステートを全てハンドル値#2に
関連付けてunsolicitedなDECメッセージDEC#2を作成し
てクライアント１３に送信する。 (18) クライアント１３はこのDECメッセージに基づいて
再設定を行い、設定結果をRPTメッセージでサーバ１４
に通知する。以後、クライアントは次の設定指示を待
つ。以上のようにサーバに設定履歴を保存し、サーバは
該設定履歴を用いてクライアントに再設定するため、再
設定に要する時間を短縮できる。

【００６５】(f-2) 第２の復旧処理以上では、サーバに設定履歴を保存させたが、クライア
ントに設定履歴を保存し、サーバからの再設定を待たず
クライアントにおいて自発的に保存した履歴を使用して
再設定をするように構成することもできる。図１７はメ
ッセージ通信障害時における別の復旧処理手順説明図で
あり、(1)〜(9)までは図１６の手順と同じである。 (10) 設定時間Ｔ_S2が経過してもRPTメッセージがクライ
アントより返ってこなければ（タイムアウト）、サーバ
１４は(8)で設定Ｄの要求を出したDECメッセージDEC#1
と同じハンドル値#1で指定した設定(A,B,C,D)の破棄要
求を出す。 (11) クライアント１３は破棄要求を受信すれば、ハン
ドル値#1の既存ステート(設定履歴A,B,C(設定が正常に
終了していればＤもいれてよい）)を保存する。 (12) しかる後、破棄処理を行い、削除結果をRPTメッセ
ージでサーバ１４に報告する。これにより、サーバ１４
はクライアントよりハンドル値#1で指示した設定が破棄
されたことを認識する。

【００６６】(13) ついで、クライアント１３はDRQメッ
セージDRQ#1をサーバ１４に送信し、主導権許可メッセ
ージREQ#1のハンドル値#1を削除するよう指示する。サ
ーバ１４はDRQメッセージによりハンドル値＃１を削除
する。 (14) しかる後、クライアント１３は別のハンドル値#2
を有する新たな主導権許可メッセージREQ#2（クライア
ント特定情報ClientSI=ヌルのREQメッセージREQ#2）を
発信してサーバ主導状態にする。 (15) サーバ１４は、クライアント１３から主導権許可
メッセージを受信すれば、ただちに、solicitedなDECメ
ッセージDEC#2により主導権許可メッセージを受け取っ
たことを、クライアント１３に通知する。

【００６７】(16) クライアント１３はsolicitedなDEC
メッセージDEC#2の受信により正しく主導権許可メッセ
ージがサーバに届いたと認識し、以後サーバからの設定
を待つ（サーバ主導状態が確立される）。 (17) クライアントはREQ#3を作成して(11)で保存してあ
るステート状態を関連づけ、再設定する許可をサーバに
求める。 (18) サーバはREQ#3に関連付けしてあるステートを実行
してよいかどうかを判断し、その結果をDEC#3に関連づ
けクライアントに送出する。以後、クライアントはサー
バからの設定指示を待つ。 (19) クライアントは、サーバからの指示に従って設定
を行い、その結果をRPT#3でサーバに通知する。以上の
ようにクライアントに設定履歴を保存し、該設定履歴を
用いてクライアント、サーバに再設定するため、再設定
に要する時間を短縮できる。

【００６８】（ｇ）クライアントの機能構成図１８はクライアントの機能構成図である。２１は管理
コンソール、２２はCOPS管理コンソールプロセス部、２
３はCOPSクライアントプロセス部、２４はプロセス間通
信部、２５はカーネル部、２６はTCPソケット通信部で
ある。管理コンソール２１は、COPSサーバとの間でCO
PSセッションを開始するためにCOPSセッション開始コマ
ンドを入力したり、COPSサーバとの間のCOPSセッショ
ンを停止するためにCOPSセッション停止コマンドを入力
したり、リクエストステート情報を収集するためにリ
クエストステート情報収集コマンドを入力する。プロセ
ス間通信部２４はプロセス部２２，２３間の通信を制御
する。TCPソケット通信部２６は通信アプリケーション
ソケットを通じて外部のアプリケーション(ポリシーサ
ーバ)と通信する。カーネルは種々の制御、例えば、構
築されたキュー構成に基づいたキュー制御を行う。

【００６９】COPSクライアントプロセス部２３は、メイ
ン処理部３１、リソース管理部３２、ＰＥＰ部３３、CO
PSプロトコル処理部３４、キュー制御処理部３５を備え
ている。リソース管理部３２は、COPS起動用コンフィグ
レーション情報及びリクエストステート情報などを保持
するデータベース４１を備え、ＰＥＰ部３３はＰＥＰ部
管理情報データベース４２を備え、COPSプロトコル処理
部３４はCOPSセッション制御情報データベース４３を備
えている。

【００７０】図１９はリソース管理部３２が備えるデー
タベース説明図である。データベースとして、第１、第
２のデータベース部４１ａ，４１ｂがある。第１データ
ベース部４１ａには、COPS起動用コンフィグレーション
情報(COPSセッションを確立するための接続先サーバア
ドレス、COPSシーケンスに必要なタイマ設定情報等)が
記憶される。第２データベース部４１ｂには、リクエス
トステート情報等が記憶される。クライアントはサーバ
にREQメッセージを用いて所定の要求をし、その要求が
サーバにより許可された場合、要求した情報、要求によ
り設定された情報をリクエストステート情報としてハン
ドル値に対応させてデータベース４１ｂに保持する。リ
クエストステート情報は、サーバからのDECメッセージ
受信時などにおいてＰＥＰ部３３の制御で更新され、あ
るいは新規作成される。

【００７１】図２０はＰＥＰ部３３が備えるデータベー
ス説明図である。データベース４２には、DEC待ち情報
(ハンドル値、DEC待ちタイマ、REQメッセージ等)、空き
ハンドル値等が記憶される。図２１はCOPSプロトコル処
理部３４が備えるデータベース説明図である。データベ
ース４３には、COPSメッセージを送受信するための必要
最小限の情報が保持され、クライアントタイプやKAの制
御を行うための情報、TCPコネクションとCOPSコネクシ
ョンの接続／連携処理を行うための情報などが保持され
ている。

【００７２】図１８における各機能部間のインタフェー
ス(1)〜(11)の概略は以下のとおりである。インタフェ
ース(1)は、プロセス間通信部２４からメイン処理部３
１への通知を行うインタフェースであり、管理コンソー
ルプロセス部２２から送出されるCOPSコマンドをメイン
処理部３１に通知する。インタフェース(2)は、TCPソケ
ット通信部２６からメイン処理部３１への通知を行うイ
ンタフェースであり、受信したCOPSメッセージをメイン
処理部３１に通知する。インタフェース(3)は、メイン
処理部３１とリソース管理部３２間のインタフェースで
あり、COPS起動時に、メイン処理部３１よりリソース管
理部３２にCOPS起動用コンフィグレーション情報等の初
期設定を要求する。

【００７３】インタフェース部(4)は、メイン処理部３
１とＰＥＰ部３３間のインタフェースであり、メイン処
理部３１よりＰＥＰ部３３へ、ＰＥＰ部初期設定要求・応答、 COPSオープンコマンド要求・応答、 COPSクローズコマンド要求・応答、リクエストステート情報参照要求・応答、タイムアウト発生通知、等を行う。インタフェース(5)は、メイン処理部３１とC
OPSプロトコル処理部３４間のインタフェースであり、
メイン処理部３１よりCOPSプロトコル処理部３４へ、ソケットの受信発生通知と応答、タイムアウト発生通知を行う。

【００７４】インタフェース(6)は、ＰＥＰ部３３とリ
ソース管理部３２間のインタフェースであり、ＰＥＰ部
３３よりリソース管理部３２へ、リクエストステート情報の作成要求と応答、リクエストステート情報の参照要求と応答、リクエストステート情報の削除要求と応答を行う。

【００７５】インタフェース(7)はＰＥＰ部３３とCOPS
プロトコル処理部３４間のインタフェースであり、ＰＥ
Ｐ部３３よりCOPSプロトコル処理部３４へ、 COPSセッションオープンの要求・応答、 COPSセッションクローズの要求・応答、各種COPSメッセージ送信の要求・応答を行う。又、COPSプロトコル処理部３４よりＰＥＰ部３
３へ、各種COPSメッセージの受信通知、 COPSセションの切断通知、 KA受信監視タイマのタイムアウト通知、 OPNメッセージ送信のリトライアウト通知を行う。

【００７６】インタフェース(8)はＰＥＰ部３３とキュ
ー制御処理部３５間のインタフェースであり、ＰＥＰ部
３３からキュー制御処理部３５へ、初期設定要求・応答優先度情報の新規設定／更新／削除の要求・応答キュー情報の新規設定／更新／削除の要求・応答フィルタ情報の新規設定／更新／削除の要求・応答を行う。インタフェース(9)はキュー制御処理部３５と
カーネル２５間のインタフェースで、キュー制御処理部
３５からカーネル２５へ、初期設定の要求・応答優先度情報の設定要求・応答キュー情報の設定／削除要求・応答フィルタ情報の設定／削除要求・応答を行う。

【００７７】インタフェース(10)はCOPSプロトコル処理
部３４とTCPソケット通信部２６間のインタフェースで
あり、COPSプロトコル処理部３４からTCPソケット通信
部２６へ、 COPSメッセージの送信要求 COPSソケットのオープン要求 COPSソケットのクローズ要求を行う。インタフェース部(11)は管理コンソール２１か
らのコマンド入力に基づいてプロセス間通信部２４に COPSセッションのオープン要求 COPSセッションのクローズ要求リクエストステート情報の参照要求行う。

【００７８】管理コンソール２１よりCOPSセッション開
始コマンドを入力すれば、プロセス間通信部２４はメイ
ン処理部３１に該コマンドを通知する。これにより、メ
イン処理部３１はリソース管理部３２にCOPS起動用コン
フィグレーション情報をデータベース４１に保存させ
る。又、メイン処理部３１はＰＥＰ部３３にCOPSオープ
ンコマンドを要求し、ＰＥＰ部３３はCOPSプロトコル処
理部３４にCOPSセッションオープンを要求する。COPSプ
ロトコル処理部３４がCOPSセッションをオープンすれ
ば、ＰＥＰ部３３は主導権許可メッセージREQ#nを作成
し、COPSプロトコル処理部３４→TCPソケット通信部２
６を介してポリシーサーバに発信する。

【００７９】又、ポリシーサーバからのDECメッセージD
EC#nはTCPソケット通信部２６→メイン処理部３１→COP
Sプロトコル処理部３４を介してＰＥＰ部３３に通知さ
れる。ＰＥＰ部３３は受信したDECメッセージDEC#nがキ
ュー構成の変更を指示するメッセージであれば、キュー
御処理部３５にキュー構成情報を入力し、キュー制御処
理部３５は入力されたキュー構成情報に基づいてキュー
構成を変更する。又、ＰＥＰ部３１はリソース管理部３
２にリクエストステート情報の新規作成／変更／参照／
削除を指示する。以上、本発明を実施例により説明した
が、本発明は請求の範囲に記載した本発明の主旨に従い
種々の変形が可能であり、本発明はこれらを排除するも
のではない。

【００８０】

【発明の効果】以上の本発明によれば、以下の効果があ
る。 (1) クライアントが設定可能な状態になれば、サーバか
らの自発的な任意の設定指示が随時可能となる。したが
って、擬似的にサーバに設定の主導権を与えたのと同様
の効果を得ることができ、サーバは、ネットワークの状
況の変化（輻輳、障害）等によって、新規の設定や設定
の変更等を必要とする際、クライアントからの要求を待
つことなしに、サーバとクライアントの間で合意のとれ
た全ての項目に対し、迅速に指示することが可能とな
る。 (2) 又、サーバ主導による第２のポリシー制御法によれ
ば、個々の設定指示をハンドル値を用いて識別すること
ができるため、設定の追加、変更、削除を容易に行うこ
とができ、障害の対応が容易となる。

【００８１】(3) クライアントはサーバ主導状態にある
か否かを認識することができるので、サーバ主導状態に
ない場合は、直ちに、サーバ主導権許可メッセージを再
送することができる。これにより、クライアントに対す
るサーバからの自発的な、任意の設定が常に可能な状態
（サーバ主導状態）にすることができる。 (4) クライアントはサーバ主導権許可メッセージが規定
時間経過してもサーバに到達しなければ、直ちに該メッ
セージの再送を行うようにしたから、通信障害による処
理の中断を最小限にできると共にシステムの信頼性を向
上できる。 (5) サーバは、RPTメッセージによりクライアントに指
示した設定の実行が、成功したか否かを知る事ができる
ので、サーバは、クライアントの状態を確実に把握する
ことができる。

【００８２】(6) サーバは、設定を指示するDECメッセ
ージが規定の時間を経過してもクライアントに到達しな
ければ、処理の再実行を行うようにしたから、通信障害
による処理の中断を最小限にすることが可能となると共
に、処理の再実行によって、システムの信頼性を向上で
きる。 (7) サーバ、クライアント間のメッセージ通信におい
て、通信障害が生じた場合、サーバは設定履歴を保存
し、該設定履歴を用いてクライアントに再設定するか
ら、再設定に要する時間を短縮できる。 (8) 主導権許可メッセージが削除された際、直ちに、新
たな主導権許可メッセージがクライアントから発信され
るため、サーバ主導による設定制御を継続して行うこと
ができる。 (9) サーバ、クライアント間のメッセージ通信におい
て、通信障害が生じた場合、クライアントは設定履歴を
保存し、サーバからの再設定を待たずクライアントにお
いて自発的に保存した履歴を使用した再設定をするよう
にしたから、再設定に要する時間を短縮できる。

【図面の簡単な説明】

【図１】本発明のネットワーク構成例である。

【図２】ディレクトリサーバに格納されているユーザ情
報の例を示す図である。

【図３】ディレクトリサーバに格納されているルータ情
報例である。

【図４】優先制御説明図である。

【図５】ネットワーク機器のトポロジを示す図表であ
る。

【図６】ポリシーサーバの構成図である。

【図７】サーバ主導による第１のポリシー制御手順であ
る。

【図８】ポリシーサーバに設定の主導権を与えるＲＥＱ
メッセージの例である。

【図９】ポリシーサーバに設定の主導権を与えた時のＤ
ＥＣメッセージ例である。

【図１０】サーバ主導による第２のポリシー制御手順で
ある。

【図１１】ポリシーサーバからの自発的な設定要求によ
るコンフィグレーションの例（ルータ起動時にデフォル
トの設定を実行）である。

【図１２】ポリシーサーバからの自発的設定要求による
コンフィグレーションの例（ユーザからの要求に従い、
ルータのキュー構成を変更）である。

【図１３】ポリシーサーバからの自発的な設定要求によ
るコンフィグレーションの例（障害時のルーティング情
報の変更を行う）である。

【図１４】ＤＥＣ受信監視タイマ処理である。

【図１５】ＲＰＴ受信監視タイマ処理である。

【図１６】メッセージ通信障害時における復旧処理であ
る。

【図１７】メッセージ通信障害時における別の復旧処理
である。

【図１８】クライアントの機能構成である。

【図１９】リソース管理部の備えるデータベース説明図
である。

【図２０】ＰＥＰ部が備えるデータベース説明図であ
る。

【図２１】ＣＯＰＳプロトコル処理部が備えるデータベ
ース説明図である。

【図２２】ポリシーサーバを用いた従来のアドミッショ
ン制御説明図である。

【図２３】大規模ネットワークの一元管理アーキテクチ
ャである。

【図２４】ＣＯＰＳメッセージ一覧である。

【図２５】ＣＯＰＳオブジェクト一覧である。

【図２６】共通ヘッダである。

【図２７】オブジェクトの一般的なフォーマットであ
る。

【図２８】各種オブジェクトの具体的なフォーマットで
ある。

【図２９】ＲＥＱ／ＤＥＣメッセージ通信の手順説明図
である。

【図３０】ＲＥＱメッセージ説明図である。

【図３１】ＤＥＣメッセージ説明図である。

【図３２】ＲＰＴメッセージ説明図である。

【符号の説明】

１１，１２・・エンド端末（ホスト装置）１３₁〜１３₃・・ルータ（クライアント）１４・・ポリシーサーバ１５・・ディレクトリサーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者黒瀬義敏神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内 (72)発明者野村祐士神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内Ｆターム(参考） 5K030 GA16 HA05 HB11 HD03 JT02 MD07 5K033 AA04 CB01 DA01 EC02 EC03 5K034 AA14 AA17 BB06 DD03 EE09 HH63 JJ11 9A001 CC03 CC06 CC07 LL09

Claims

【特許請求の範囲】

【請求項１】ネットワークを構成するネットワーク機
器と、ネットワーク機器からの要求に対して所定の処理
を行って応答するネットワーク機器制御装置を備え、ク
ライアントであるネットワーク機器とサーバであるネッ
トワーク機器制御装置間で通信プロトコルに従って情報
送受を行う通信システムにおいて、クライアントはサーバに対して、サーバに主導権を付与
するサーバ主導権許可メッセージを送信し、サーバは該メッセージ受信後、クライアントに設定が必
要になったときにサーバ主導で該クライアントに必要な
設定を指示する１つ以上のメッセージを送信し、クライアントは該各設定メッセージに基づいて設定を行
う、ことを特徴とする通信システム。
【請求項２】クライアントは前記サーバ主導権許可メ
ッセージにハンドル値を含ませ、サーバは前記設定メッ
セージに該ハンドル値を含めてクライアントに必要な設
定を指示し、クライアント及びサーバは各設定を１つの
ハンドル値で管理する、ことを特徴とする請求項１記載の通信システム。
【請求項３】サーバはサーバ主導権許可メッセージを
受信した時、該メッセージを受信したことを示すデシジ
ョンメッセージをクライアントに送信する、ことを特徴とする請求項１記載の通信システム。
【請求項４】クライアントはサーバ主導権許可メッセ
ージ送信後に前記デシジョンメッセージの受信を監視
し、規定時間以内にデシジョンメッセージを受信しなけ
れば、該サーバ主導権許可メッセージを送信した状態か
ら送信する前の状態に戻し、新たなサーバ主導権許可メ
ッセージを送信する、ことを特徴とする請求項３記載の通信システム。
【請求項５】クライアントはサーバから指示された設
定の実行結果を報告するメッセージをサーバに送信し、
サーバは該メッセージに基づいてクライアントの設定状
態を一元管理する、ことを特徴とする請求項１記載の通信システム。
【請求項６】サーバは設定メッセージ送信後に前記報
告メッセージの受信を監視し、規定時間以内に報告メッ
セージを受信しなければ、これまでに設定メッセージに
より指示した設定を破棄し、サーバ主導状態の取り消し
を指示するメッセージをクライアントに発信する、ことを特徴とする請求項５記載の通信システム。
【請求項７】サーバは、設定を破棄し、サーバ主導状
態の取り消しを指示する前記メッセージをクライアント
に発信する前にそれまでクライアントに設定した設定履
歴を保存し、破棄を指示するメッセージをクライアントに発信後、ク
ライアントより主導権許可メッセージが再送されてきた
時、サーバは保存してある前記設定履歴に基づいて設定
メッセージを作成してクライアントに送信すること、を特徴とする請求項６記載の通信システム。
【請求項８】クライアントは、サーバよりこれまでに
設定メッセージにより指示された設定を破棄する前記メ
ッセージを受信した時、それ迄の設定履歴を保存し、該破棄メッセージに応じた破棄処理を実行後、新たな主
導権許可メッセージをサーバへ送出し、しかる後、前記保存履歴に基づき、サーバに設定許可を
要求するメッセージを作成して送信する、ことを特徴とする請求項６記載の通信システム。
【請求項９】クライアントは何らかの理由でサーバ主
導状態を取り消した場合、新たな主導権許可メッセージ
をサーバに発信する、ことを特徴とする請求項１記載の通信システム。
【請求項１０】ネットワークを構成するネットワーク
機器と、ネットワーク機器からの要求に対して所定の処
理を行って応答するネットワーク機器制御装置を備え、
クライアントであるネットワーク機器とサーバであるネ
ットワーク機器制御装置間で通信プロトコルに従って情
報送受を行う通信システムにおいて、クライアントはサーバに対して、サーバに主導権を付与
するサーバ主導権許可メッセージを送信し、サーバは該メッセージの受信によりサーバ主導で該クラ
イアントに必要な設定を指示するメッセージを送信し、クライアントは該メッセージにより指示された設定を行
うと共にサーバに新たなサーバ主導権許可メッセージを
送信し、以後同様にしてサーバからの各設定を独立して
管理する、ことを特徴とする通信システム。
【請求項１１】クライアントは前記サーバ主導権許可
メッセージにハンドル値を含ませ、サーバは前記設定メ
ッセージに該ハンドル値を含めて必要な設定を要求する
ことにより、クライアント及びサーバは各設定をハンド
ル値により独立して管理する、ことを特徴とする請求項１０記載の通信システム。
【請求項１２】サーバはサーバ主導権許可メッセージ
を受信した時、該メッセージを受信したことを示すデシ
ジョンメッセージをクライアントに送信する、ことを
特徴とする請求項１０記載の通信システム。
【請求項１３】クライアントはサーバ主導権許可メッ
セージ送信後に前記デシジョンメッセージの受信を監視
し、規定時間以内にデシジョンメッセージを受信しなけ
れば、該サーバ主導権許可メッセージを送信した状態か
ら送信する前の状態に戻し、新たなサーバ主導許可メッ
セージを送信する、ことを特徴とする請求項１２記載の通信システム。
【請求項１４】クライアントはサーバから指示された
設定の実行結果を報告するメッセージをサーバに送信
し、サーバは該メッセージに基づいてクライアントの設
定履歴を一元管理する、ことを特徴とする請求項１０記載の通信システム。
【請求項１５】サーバは設定メッセージ送信後に前記
報告メッセージの受信を監視し、規定時間以内に報告メ
ッセージを受信しなければ、該設定メッセージによる設
定履歴の破棄とサーバ主導状態の取り消しを指示するメ
ッセージをクライアントに発信する、ことを特徴とする請求項１４記載の通信システム。
【請求項１６】クライアントは何らかの理由でサーバ
主導状態を取り消した場合、新たなサーバ主導権許可メ
ッセージをサーバに発信する、ことを特徴とする請求項１０記載の通信システム。
【請求項１７】ネットワークを構成するネットワーク
機器と、ネットワーク機器からの要求に対して所定の処
理を行って応答するネットワーク機器制御装置を備え、
クライアントであるネットワーク機器とサーバであるネ
ットワーク機器制御装置間で通信プロトコルに従って情
報送受を行う通信システムにおけるネットワーク機器制
御装置において、ネットワーク機器制御装置は、ネットワーク機器より主
導権を付与するサーバ主導権許可メッセージを受信し、
該メッセージの受信を契機に、ネットワーク機器に設定
が必要になったときに必要な設定を指示する１つ以上の
メッセージを作成し、該各メッセージを送信してネット
ワーク機器に各メッセージに基づいて設定を行う手段を
有することを特徴とするネットワーク機器制御装置。
【請求項１８】ネットワークを構成するネットワーク
機器と、ネットワーク機器からの要求に対して所定の処
理を行って応答するネットワーク機器制御装置を備え、
クライアントであるネットワーク機器とサーバであるネ
ットワーク機器制御装置間で通信プロトコルに従って情
報送受を行う通信システムにおけるネットワーク機器制
御装置において、ネットワーク機器制御装置は、ネットワーク機器より主
導権を付与するサーバ主導権許可メッセージを受信し、
該サーバ主導権許可メッセージを受信する毎にネットワ
ーク機器に必要な設定を指示するメッセージを作成し、
該メッセージをネットワーク機器に送信してネットワー
ク機器に設定を行う手段を有することを特徴とするネッ
トワーク機器制御装置。
【請求項１９】ネットワークを構成するネットワーク
機器と、ネットワーク機器からの要求に対して所定の処
理を行って応答するネットワーク機器制御装置を備え、
クライアントであるネットワーク機器とサーバであるネ
ットワーク機器制御装置間で通信プロトコルに従って情
報送受を行う通信システムにおけるネットワーク機器に
おいて、ネットワーク機器は、ネットワーク機器制御装置に主導
権を付与するサーバ主導権許可メッセージを送信する手
段、ネットワーク機器制御装置からの指示により必要な
設定を行う手段を有することを特徴とするネットワーク
機器。