JP2000209212A - 通信ネットワ―クシステムおよび通信ネットワ―クシステムにおけるサ―ビス管理方法 - Google Patents

Abstract

(57)【要約】 【課題】ネットワークシステムにおける設定作業の負担
を低減させる。 【解決手段】サービスディレクトリサーバ１００は、ネ
ットワーク内に設置されている各サービス提供サーバ１
１０のサービス情報を一元管理しており、自動的にある
いは通信ノード１２０の要求に応じて、管理しているサ
ービス情報を通信ノード１２０に配布する。各通信ノー
ド１２０は、受信したパケットのうち自身宛のものにつ
いて、サービスディレクトリサーバ１００より提供され
たサービス情報に基づいて送り先のサービス提供サーバ
１１０を決定し、当該パケットを当該サーバ１１０に転
送して、サービスを受ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のサービスを
提供する通信ネットワークシステムに関し、特に、大規
模なバックボーンを有するネットワークシステムにおけ
る運用管理コストを低減するための技術に関する。

【０００２】

【従来の技術】ＷＷＷ（World Wide Web）などの出現に
より、ＩＰ（Internet Protocol）を用いたデータ通信
が急速に普及しつつある。ＷＷＷを利用したＩＰによる
通信では、従来のようなデータ中心の通信だけでなく、
音声や映像などのマルチメディア情報を送受信すること
も可能である。このため、より大量のデータをより高速
に転送できる大規模なバックボーンネットワークが求め
られている。

【０００３】

【発明が解決しようとする課題】ところで、ネットワー
クが大規模化するにつれて、ネットワーク内の通信リソ
ースをどう管理するかが問題となる。大量のデータをあ
る一定の通信品質で送受信できるようにするためには、
ネットワーク内のリソースを管理するためのサーバが必
要になってくる。たとえば、高速な処理を必要とするパ
ケット転送サービスを複数の通信ノードが実行し、経路
制御や通信リソース管理など高機能で複雑な処理を必要
とするサービスをサーバが実行するといいった機能分担
を行う必要性が生じてくる。

【０００４】大規模なネットワークサービスを提供する
通信キャリアや大規模インターネットサービスプロバイ
ダにとっては、このような機能分割によって高性能化と
運用管理の低コスト化を両立することが必須になるもの
と思われる。

【０００５】このようなサーバを使用することの利点
は、情報を管理するポイントが限定されるため、ネット
ワーク運用管理者から見たときに管理対象となる装置が
少なくなり運用コストが低減されることにある。

【０００６】しかしながら、ネットワークがさらに大規
模化し、そこで提供されるサービスの種類が増加するに
つれ、通信ノードに各種サービスを提供するためのサー
バの種類も増加する。この場合、新しいサービスを提供
するサーバが設置されたり、あるいは、既存のサーバが
提供するサービスの設定情報が変更される毎に、そのサ
ービスを利用するすべての通信ノードに対して設定情報
を新しいものに変更しなければならない。

【０００７】たとえば、新しいサーバにアクセスするた
めのアドレス情報やサービスを利用するための設定情報
などを、通信ノードに新たに設定しなければならない。

【０００８】多くの通信ノードが稼働する大規模なネッ
トワークシステムでは、このようなサービス導入や設定
変更のための作業量が膨大となる。すなわち、提供され
るサービスの種類が増加するにつれて、このような設定
作業量が増加し、システム管理がより複雑になる。その
結果、新サービスの導入に時間がかかり、運用のための
コストが増加してしまう。また、設定作業量が増加すれ
ば、それだけ設定ミスも発生しやすくなるため、ネット
ワークシステムの信頼性が低下する。

【０００９】本発明は、上記事情に鑑みてなされたもの
であり、本発明の目的は、ネットワークシステムにおけ
る運用管理コストを低減することにある。特に、多くの
通信ノードが稼働する大規模なネットワークシステムに
おいて、サービスを提供するサーバを新たに設置した場
合や既存のサーバが提供するサービスを変更した場合で
も、そのために必要となる設定作業の負担を低減させる
ことで、運用管理コストを低減することにある。

【００１０】

【課題を解決するための手段】上記課題を解決するため
に、本発明では、ネットワーク内に設けられたサービス
を提供するサーバの情報を、前記サービスを提供するサ
ーバとは別個に設けられたディレクトリサーバで集中管
理し、その情報をネットワーク内の各通信ノードに、自
動的にあるいは各通信ノードからの依頼に応じて配布す
るようにしている。

【００１１】具体的には、本発明は、受信したパケット
を当該パケットに付与された宛先に転送する少なくとも
１つの通信ノードと、所定のサービスを提供する少なく
とも１つのサーバと、ディレクトリサーバとを有する通
信ネットワークシステムであって、前記ディレクトリサ
ーバは、前記サーバが提供するサービスを受けるための
条件に関するサービス情報を記憶する記憶手段と、前記
記憶手段に記憶されたサービス情報を前記通信ノードに
提供する情報提供手段と、を備え、前記通信ノードは、
受信したパケットのうち、特定の種類のパケットについ
て、当該パケットを処理すべきサーバを、前記ディレク
トリサーバより提供されたサービス情報に基づいて決定
する決定手段と、前記特定の種類のパケットを、前記決
定手段で決定されたサーバに転送する特定パケット転送
手段と、を備えることを特徴とする。

【００１２】ここで、特定の種類のパケットとは、たと
えば経路制御に関するパケットや通信品質の管理に関す
るパケットなど、ネットワークが提供するあるサービス
に関するパケットを指す。このようなパケットには、通
常、宛先アドレスとして、処理を要求する通信ノードの
アドレスが付される。

【００１３】本発明において、ディレクトリサーバは、
特定のサービスに関するパケットの定義や、そのサービ
スを提供しているサーバのアドレスや、そのサービスを
受信した通信ノードが行わなければならないパケット処
理などを特定するサービス情報を一元管理している。そ
して、そのサービス情報をネットワーク内の各通信ノー
ドに、自動的に、あるいは、各通信ノードからの依頼に
応じて配布する。

【００１４】一方、各通信ノードは、受信したパケット
のうち、特定の種類のパケットについて、当該パケット
を処理すべきサーバを、ディレクトリサーバにより提供
されたサービス情報に基づいて決定する。そして、当該
パケットを前記決定したサーバに転送することにより、
そのサーバに処理させる。

【００１５】したがって、本発明によれば、ネットワー
ク運用管理者は、ネットワークにサーバが新たに追加さ
れた場合や既存のサーバが提供するサービスを変更した
場合でも、各通信ノードに対して設定作業を行う必要が
なくなる。すなわち、ネットワーク運用管理者は、ディ
レクトリサーバに保持されているサービス情報のみを維
持・管理し、必要に応じて変更すればよいので、ネット
ワークの運用管理コストを低減することができる。

【００１６】

【発明の実施の形態】以下、本発明の一実施形態につい
て説明する。

【００１７】図１は、本発明の一実施形態が適用された
統合サービスネットワークシステムの概略構成を示して
いる。

【００１８】図示するように、本実施形態の統合サービ
スネットワークシステムは、サービスディレクトリサー
バ１００と、複数のサービス提供サーバ１１０（１１０
−Ａ〜１１０−Ｃ）と、複数の通信ノード１２０（１２
０−Ａ〜１２０−Ｃ）とが、相互に通信ネットワークで
接続されて構成される。

【００１９】ここで、サービスディレクトリサーバ１０
０は、本実施形態の特徴となるノードである。ネットワ
ーク内に設置されている複数のサービス提供サーバ１１
０各々について、当該サーバのアドレスや当該サーバが
処理するパケットの定義などに関するサービス情報を一
元管理しており、自動的にあるいは通信ノード１２０か
らの要求に応じて、管理しているサービス情報を提供す
る。

【００２０】通信ノード１２０は、ＩＰ（Internet Pro
tocol）ルータとしての機能を備えており、受信したデ
ータパケットを当該パケットに付与された宛先に転送す
る。加えて、サービスディレクトリサーバ１００への問
合せを行うことによってサービス情報を取得し、その情
報に基づいて、適切なサービス提供サーバ１１０にパケ
ット処理を依頼する。

【００２１】サービス提供サーバ１１０は、自身が担当
するサービスのパケットを通信ノード１２０から受信し
て必要な処理を行う。

【００２２】次に、本実施形態の統合サービスネットワ
ークシステムを構成する各装置のハードウエア構成につ
いて説明する。

【００２３】図２は、サービスディレクトリサーバ１０
０、サービス提供サーバ１１０および通信ノード１２０
のハードウエア構成の一例を示す図である。

【００２４】図示するように、本実施形態の統合サービ
スネットワークシステムを構成する各装置は、一般的な
構成を備えた情報処理装置上に構築することが可能であ
る。ここで、ＣＰＵ(Central Processing Unit）２００
は、メモリ２１０に格納されているプログラムを実行す
るためのプロセッサである。メモリ２１０には、装置全
体を制御するためのオペレーティングシステム（ＯＳ）
２１３と、本装置をサービスディレクトリサーバ１００
やサービス提供サーバ１１０や通信ノード１２０として
機能させるための制御プログラム２１５が格納されてい
る。ネットワークコントローラ２２０は、ネットワーク
との送受信を制御する。キーボードコントローラ２３０
は、キーボード２３５からのキー入力を制御する。シリ
アルコントローラ２４０は、シリアルポートに接続され
たマウス２４５などの入出力機器を制御する。ディスプ
レイコントローラ２５０は、ディスプレイモニタ２５５
への画面表示を制御する。ディスクコントローラ２６０
は、ディスク装置２６５への入出力を制御する。

【００２５】図２に示すハードウエア構成例では、制御
プログラム２１５として、サービスデイレクトリサーバ
用制御プログラムを用いることで、後述する図３に示す
機能構成を実現することができ、サービス提供サーバ用
制御プログラムを用いることで、後述する図４に示す機
能構成を実現することができる。また、通信ノード用制
御プログラムを用いることで、後述する図５に示す機能
構成を実現することができる。

【００２６】なお、図２に示すハードウエア構成例は、
あくまでも一例に過ぎない。たとえば、通信ノード１２
０においては、パケットの転送処理を高速化するため、
特別なハードウエア転送機構を設けるようにしてもよ
い。また、サービス提供サーバ１００においては、提供
するサービスの内容に応じて付加的なハードウエア機構
を追加するようにしてもよい。また、制御プログラム２
１５は、ＣＤ−ＲＯＭなどの可搬性を有する記憶媒体に
より提供されるようにしてもよい。すなわち、図示して
いない読取り装置を介して、当該記憶媒体２１５からメ
モリ２１０上にロードするようにしてもよいし、あるい
は、図示していない読み取り装置を介して、当該記憶媒
体２１５からディスク装置２６５に格納し、それから、
メモリ２１０上にロードするようにしてもよい。

【００２７】次に、本実施形態の統合サービスネットワ
ークシステムを構成する各装置の機能構成について説明
する。

【００２８】図３は、サービスディレクトリサーバ１０
０の機能構成図である。

【００２９】図示するように、サービスディレクトリサ
ーバ１００は、入出力制御部３１０と、ネットワークイ
ンタフェース部３５０と、サーバ通信部３６０と、クラ
イアント通信部３４０と、クライアントデータベース
（ＤＢ）３７０と、サービス要求受付部３３０と、サー
ビスデータベース（ＤＢ）管理部３２０と、サービスデ
ータベース（ＤＢ）３７０と、を備えている。

【００３０】ここで、入出力制御部３１０は、キーボー
ドなどの入力装置からの入力やディスプレイなどの出力
装置への出力を制御する。

【００３１】ネットワークインタフェース部３５０は、
ネットワークから受信したパケットを適切な処理モジュ
ールに渡したり、他の処理モジュールからの要求により
パケットをネットワークに送信するなど、ネットワーク
とのインターフェースとして機能する。

【００３２】サービスデータベース３７０には、ネット
ワーク内に設置されている複数のサービス提供サーバ１
１０各々についてのサービス情報が格納されている。

【００３３】サービスデータベース管理部３２０は、サ
ービスデータベース３７０を管理する。また、入出力制
御部２１０を介して受け付けたネットワーク運用管理者
よりの指示にしたがい、サービスデータベース３７０を
更新する。

【００３４】クライアントデータベース３８０には、ネ
ットワーク内に設置されている複数の通信ノード１２０
各々について、アドレスなどの登録情報が格納されてい
る。

【００３５】サーバ通信部３６０は、ネットワークイン
ターフェース部３５０を介して、ネットワーク内に設置
されている複数のサービス提供サーバ１１０各々との通
信を制御・管理する。

【００３６】クライアント通信部３４０は、ネットワー
クインターフェース部３５０を介して、ネットワーク内
に設置されている複数の通信ノード１２０各々との通信
を制御・管理する。たとえば、通信ノード毎のセッショ
ン管理を行う。

【００３７】サービス要求受付部３３０は、ネットワー
クインターフェース部３５０およびクライアント通信部
３４０を介して、サービス情報の提供要求を通信ノード
１２０より受付ける。そして、必要に応じて、サービス
データベース管理部３２０を介してサービスデータベー
ス３７０よりサービス情報を取得し、当該提供要求を送
信した通信ノード１２０に送信する。

【００３８】図４は、サービス提供サーバ１１０の機能
構成図である。

【００３９】図示するように、サービス提供サーバ１１
０は、ネットワークインターフェース部４５０と、サー
バ通信部４６０と、クライアント通信部４４０と、サー
ビス処理部４３０と、を備えている。

【００４０】ネットワークインターフェース部４５０
は、ネットワークから受信したパケットを適切な処理モ
ジュールに渡したり、他の処理モジュールからの要求に
よりパケットをネットワークに送信するなど、ネットワ
ークとのインターフェースとして機能する。

【００４１】サーバ通信部４６０は、ネットワークイン
ターフェース部４５０を介して、サービスディレクトリ
サーバ１００との通信を制御・管理する。

【００４２】クライアント通信部４４０は、ネットワー
クインターフェース部４５０を介して、ネットワーク内
に設置されている複数の通信ノード１２０各々との通信
を制御・管理する。具体的には、ネットワークインター
フェース部４５０を介して受け取った通信ノード１２０
からのパケットをサービス処理部４３０へ渡す。また、
サービス処理部４３０より受け取ったパケットを、ネッ
トワークインターフェース部４５０を介して通信ノード
１２０へ送信する。

【００４３】サービス処理部４３０は、クライアント通
信部４４０から受け取ったパケットに対して特定の処理
を行うことで、所定のサービスを提供する。ここで、所
定の処理としては、たとえば、ＯＳＰＦ（Open Shortes
t Path First）やＢＧＰ（Border Gateway Protocol）
などの経路制御に関するプロトコルの処理や、ＲＳＶＰ
（Resource Reservation Protocol）などの通信品質に
関するプロトコルの処理がある。

【００４４】図５は、通信ノード１２０の機能構成図で
ある。

【００４５】図示するように、通信ノード１２０は、入
出力制御部５０５と、制御・管理部５１０と、設定情報
記憶部５５０と、ネットワークインタフェース部５３５
と、パケット転送処理部５３０と、サービス振分部５２
５と、経路表管理部５４５と、経路表記憶部５６５と、
サーバ通信部５１５と、自律処理部５２０と、サービス
管理部５４０と、サービス表記憶部５６０と、バックア
ップファイル記憶部５５５と、を備えている。

【００４６】ここで、入出力制御部５０５は、キーボー
ドなどの入力装置からの入力やディスプレイなどの出力
装置への出力を制御する。

【００４７】設定情報記憶部５５０には、通信ノード１
２０のＩＰアドレス情報やパケットフィルタリングのた
めの情報など通常のＩＰ転送に必要な設定情報が格納さ
れている。加えて、サービスディレクトリサーバ１００
のアドレスや後述するサービスディレクトリサーバ１０
０への問合せ抑止のためのタイマ情報なども設定情報と
して格納されている。

【００４８】制御・管理部５１０は、設定情報記憶部５
５０に格納されている設定情報を管理する。なお、この
設定情報は、運用管理者よりあらかじめ設定される。制
御・管理部５１０は、入出力制御部５０５を介して受け
付けた運用管理者の指示にしたがい、設定情報記憶部５
５０に設定情報を格納したり、設定情報記憶部５５０に
格納されている設定情報を更新する。

【００４９】ネットワークインタフェース部５３５は、
ネットワークから受信したパケットを適切な処理モジュ
ールに渡したり、他の処理モジュールからの要求により
パケットをネットワークに送信するなど、ネットワーク
とのインターフェースとして機能する。

【００５０】経路表記憶部５６５には、パケット転送の
際に用いる経路表（ルーティングテーブル）が記憶され
ている。なお、この経路表については後述する。

【００５１】経路表管理部５４５は、経路表記憶部５６
５に記憶されている経路表を管理する。

【００５２】サービス表記憶部５６０には、サービスの
種類とそのサービスに対応するサービス提供サーバのア
ドレスなどの情報とを関連付けたサービス表を記憶して
いる。なお、このサービス表については後述する。

【００５３】バックアップファイル記憶部５５５には、
サービス表記憶部５６０に記憶されているサービス表の
バックアップファイルを格納する。

【００５４】パケット転送処理部５３０は、経路表管理
部５４５を介して経路表記憶部５６５に記憶されている
経路表を取得し、この経路表に基づいて、受信したパケ
ットの宛先アドレスに応じたゲートウェイを決定し、ネ
ットワークインターフェース部５３５を介して、受信し
たパケットを当該ゲートウェイに転送する。さらに、自
身の通信ノード宛パケットをサービス振分部５２５に渡
す。

【００５５】サービス振分部５２５は、自身の通信ノー
ド宛パケットを、当該パケットに対応するサービスを提
供するサービス提供サーバ１１０に転送したり、自身の
通信ノード内で処理するための振分処理を行う。具体的
には、サービス管理部５４０を介してサービス表記憶部
５６０に記憶されたサービス表を取得し、当該サービス
表に基づいて、自身の通信ノード宛パケットをサービス
提供サーバ１１０に転送するか、あるいは、自身の通信
ノード内で処理するかを決定し、サービス提供サーバ１
１０に転送する場合はサーバ通信部５１５に当該パケッ
トを送り、自身の通信ノード内で処理を行う場合は自律
処理部５２０に当該パケットを送る。

【００５６】自律処理部５２０は、サービス振分部５２
５からの指示により自身の通信ノード宛パケットを処理
する。その処理内容は、通信ノードの設定によって異な
る。また、自律処理部５２０は、パケット処理の結果に
応じて、経路表管理部５４５を介して経路表記憶部５６
５に記憶されている経路表を更新する。

【００５７】サーバ通信部５１５は、サービス振分部５
２５からの指示にしたがい、ネットワークインタフェー
ス部５３５を介して、自身の通信ノード宛パケットを当
該パケットに対応するサービスを提供するサービス提供
サーバに転送する。また、サービス管理部５４０からの
指示にしたがい、ネットワークインタフェース部５３５
を介して、サービス情報の提供要求をサービスディレク
トリサーバ１００に送信する。さらに、ネットワークイ
ンターフェース部５３０を介してサービスディレクトリ
サーバ１００より提供されたサービス情報を受信して、
サービス管理部５４０へ渡す。

【００５８】サービス管理部５４０は、サービス表記憶
部５６０に記憶されているサービス表を管理する。ま
た、制御・管理部４１０を介して設定情報記憶部５５０
よりサービスディレクトリサーバ１００にアクセスする
ための情報を取得し、当該情報にしたがい、サービスデ
ィレクトリサーバ１００に対するサービス情報の提供要
求をサーバ通信部５１５に渡す。さらに、サーバ通信部
５１５より受け取ったサービス情報にしたがい、サービ
ス表記憶部５６０に記憶されているサービス表を更新す
る。

【００５９】次に、図５に示す通信ノード１２０のサー
ビス表記憶部５６０に記憶されるサービス表について説
明する。

【００６０】図６は、サービス表記憶部５６０に記憶さ
れるサービス表の内容を説明するための図である。

【００６１】図示するように、サービス表には、サービ
スディレクトリサーバ１００より提供されたサービス情
報がテーブル形式で格納される。

【００６２】各サービス情報には、サービス情報を一意
に識別するためのサービスＩＤ６１０と、サービスの種
類を示すサービス名称６２０と、サービス振分部５２５
での振り分け先を決定するための振分条件６３０と、サ
ービスの提供を行うサービス提供サーバ１１０のアドレ
ス６４０と、オプションとしてのクライアント処理スク
リプト６５０と、を含んでいる。

【００６３】ここで、振分条件６３０は、たとえば、パ
ケットのプロトコル番号とポート番号との組合せで構成
される。サービス振分部５２５は、パケットのプロトコ
ル番号およびポート番号を抽出し、これらの情報を振分
条件６３０と比較することで、振り分け先を決定する。
なお、振分条件６３０として、パケットのプロトコル番
号とポート番号との組合せに代えて、パケットに含まれ
る任意の情報を用いるようにしてもよい。

【００６４】クライアント処理スクリプト６５０は、オ
プションとして設けられたものであり、クライアント処
理スクリプト６５０を指定することにより、たとえば、
パケットをサービス提供サーバ１１０に転送するに先立
ち、自律処理部５２０において当該パケットから情報を
取出したり、当該パケットを加工することが可能とな
る。

【００６５】次に、図５に示す通信ノード１２０の経路
表記憶部５６５に記憶される経路表について説明する。

【００６６】図７は、経路表記憶部５６５に記憶される
経路表の内容を説明するための図である。

【００６７】図示するように、経路表には、複数の経路
情報がテーブル形式で格納される。各経路情報には、宛
先アドレス７１０と、ネットマスク７２０と、ゲートウ
ェイアドレス７３０と、インタフェース７４０とが含ま
れる。

【００６８】パケット転送処理部５３０は、受信したパ
ケットに付与された宛先アドレスをキーとして経路表４
６５を検索する。検索を行うときには、一般的なルータ
が行うのと同様にネットマスク情報を使用して、宛先ア
ドレスと最長一致するアドレスを持つ経路情報が選択さ
れる。もし、宛先アドレスと一致する経路情報が見つか
らない場合、パケット転送処理部５３０は、パケットを
破棄し、パケット送信元にエラー通知を行う。宛先アド
レスと一致する経路情報が見つかると、パケット転送処
理部５３０は、ゲートウェイアドレス６３０およびイン
タフェース６４０に基づいてパケットを転送する。

【００６９】次に、以上説明した本実施形態の統合サー
ビスネットワークシステムの動作について説明する。な
お、本実施形態において、各装置間の通信は、ＴＣＰ
（Transmission Control Protocol）によるコネクショ
ンを設定した上で行う。

【００７０】まず、通信ノード１２０の初期化処理につ
いて説明する。

【００７１】図８は、通信ノード１２０の初期化処理シ
ーケンスを示す図である。この図では、通信ノード１２
０−Ａの初期化処理シーケンスを示しているが、他の通
信ノード１２０も同様である。

【００７２】図８において、ネットワーク管理者が通信
ノード１２０に対してサービスディレクトリサーバ１０
０に関する設定情報の初期設定（この設定は、通信ノー
ド１２０を最初に使用する場合に一度だけ行えばよい）
を行うと（シーケンス８００）、通信ノード１２０は、
サービスディレクトリサーバ１００に対してＯＰＥＮメ
ッセージを送信し（シーケンス８０５）、自身の存在を
サービスディレクトリサーバ１００に知らせる。これを
受けて、サービスデーレクトリサーバ１００は、ＯＰＥ
Ｎメッセージを送信した通信ノード１２０の情報をクラ
イアントデータベース３８０に登録する。

【００７３】図９は、通信ノード１２０がサービスディ
レクトリサーバ１００へ送信するＯＰＥＮメッセージの
内容を説明するための図である。ここで、ヘッダ１３０
５は、メッセージタイプやメッセージ長を含むメッセー
ジヘッダである。シーケンス番号１３１０はその後のセ
ッションで使用されるシーケンス番号の初期値を示す。
ノードＩＤ１３２０は、ＯＰＥＮメッセージを送信する
通信ノード１２０を一意に識別するための番号である。
ノードＩＤ１３２０は、ネットワーク内に設置された通
信ノード１２０を一意に特定できるようあらかじめ各通
信ノード１２０に割当てられている。認証情報１３３０
は、受信したＯＰＥＮメッセージが、正しい通信ノード
１２０が送信したものであるか否かをサービスディレク
トリサーバ１００が確認するための情報である。

【００７４】さて、図８に戻り、通信ノード１２０は、
サービスディレクトリサーバ１００に対してサービス情
報提供要求であるＱＵＥＲＹメッセージを送信する（シ
ーケンス８１０）。これを受けて、サービスディレクト
リサーバ１００は、サービス情報を含んだＲＥＰＬＹメ
ッセージを、ＱＵＥＲＹメッセージ送信元の通信ノード
１２０に返す（シーケンス８２０）。

【００７５】図１０は、通信ノード１２０がサービスデ
ィレクトリサーバ１００へ送信するＱＵＥＲＹメッセー
ジの内容を説明するための図である。ここで、ヘッダ１
４０５は，メッセージタイプやメッセージ長を含むメッ
セージヘッダである。シーケンス番号１４１０は、通信
ノード１２０が新たなＱＵＥＲＹメッセージを送信する
毎に１つインクリメントされる番号である。このシーケ
ンス番号１４１０は、後述するＲＥＰＬＹメッセージと
の対応関係を確認するために使用される。プロトコル番
号１４２０およびポート番号１４３０は、問合せ対象と
なるサービス、すなわち情報提供要求の対象となるサー
ビスに対応するプロトコル番号とポート番号である。本
実施形態では、全てのパケットに含まれているプロトコ
ル番号と、サービスの種類によってはパケットに含まれ
るポート番号と呼ばれるフィールドとを見ることによ
り、そのパケットがどのサービスに関するものであるか
を特定するようにしている。

【００７６】通信ノード１２０がサービスディレクトリ
サーバ１００にサービス情報を問合せる場合、そのサー
ビス情報に対応するプロトコル番号とポート番号とを指
定する。ただし、プロトコル番号１４２０が０（ゼロ）
である場合、特定のサービス情報を問合せるのではな
く、サービスディレクトリサーバ１００が持つサービス
情報を１個ずつ順番に返すように要求するものとする。
また、ポート番号を使用しないサービスの場合には、ポ
ート番号１４３０を０（ゼロ）に指定するものとする。

【００７７】図１１は、サービスディレクトリサーバ１
００が通信ノード１２０へ送信するＲＥＰＬＹメッセー
ジの内容を説明するための図である。ここで、ヘッダ１
５０５は、メッセージタイプやメッセージ長を含むメッ
セージヘッダである。シーケンス番号１５１０は、ＲＥ
ＰＬＹメッセージがどのＱＵＥＲＹメッセージに対する
ものかを特定するための番号である。すなわち、ＲＥＰ
ＬＹメッセージに含まれるシーケンス番号１５１０をＸ
とすると、このＲＥＰＬＹメッセージが、シーケンス番
号ＸのＱＵＥＲＹメッセージに対する回答であることが
わかる。プロトコル番号１５２０およびポート番号１５
３０は、サービスに対応するプロトコル番号およびポー
ト番号である。プロトコル番号１５２０およびポート番
号１５３０については、図１０に示すＱＵＥＲＹメッセ
ージに含まれるプロトコル番号１４２０およびポート番
号１４３０と同じ意味を持っている。ただし、プロトコ
ル番号１５２０が０（ゼロ）の場合は、該当するサービ
ス情報がないことを示すものとする。サービス名１５４
０は、サービスの種類を表す文字列であり、特定のサー
ビス情報を管理するための便宜を図るために使用され
る。サーバ情報１５５０は、サービスを提供するサービ
ス提供サーバ１１０に関する情報である。この情報に
は、少なくともサービス提供サーバ１１０のアドレスが
含まれる。

【００７８】クライアント処理スクリプト１５６０は、
サービス提供サーバ１１０がサービスを受けるために、
通信ノード１２０がパケットに対して行うべき一連の処
理を表すプログラムである。クライアント処理を行わな
くてよいサービスの場合にはクライアント処理スクリプ
ト９６０は空欄となる。このように、サービス情報とし
てクライアント処理スクリプトを指定することを可能と
しているので、たとえば、簡単な処理は各通信ノード１
２０が行い、残りの処理をサーバに依頼するといった木
目細かいサービス定義が可能になる。

【００７９】さて、図８に戻り、通信ノード１２０とサ
ービスディレクトリサーバ１００は、このＲＥＰＬＹメ
ッセージとＱＵＥＲＹメッセージとのやり取りを、通信
ノード１２０がサービスディレクトリサーバ１００より
所望のサービス情報を取得するまで繰り返す。

【００８０】次に、図８に示す通信ノード１２０の初期
化処理のシーケンスを、通信ノード１２０側での処理と
サービスディレクトリサーバ１００側での処理とに分け
て、より詳細に説明する。

【００８１】まず、通信ノード１２０側での処理につい
て説明する。

【００８２】図１２は、図８に示すシーケンスにおける
通信ノード１２０側での処理を説明するためのフロー図
である。

【００８３】図１２において、経路表管理部５４５は、
経路表記憶部５６５に記憶されている経路表を初期化す
る（ステップ１７０５）。なお、通常の初期状態では、
経路表には経路情報が含まれていないが、設定情報記憶
部５５０に設定情報として経路情報がデフォルト設定さ
れている場合には、その経路情報を経路表に設定する。

【００８４】次に、サービス管理部５４０は、制御・管
理部５１０を介して、設定情報記憶部５５０に記憶され
ている設定情報の中から、サービスディレクトリサーバ
１００に関する情報を検索する（ステップ１７１０）。
そして、サービスディレクトリサーバ１００に関する情
報が含まれているか否かをチェックする（ステップ１７
１５）。その結果、サービスディレクトリサーバ１００
に関する情報が含まれていない場合は、ステップ１７３
５に移行し、バックアップファイル記憶部５５５に情報
が記憶されてれば、当該情報を用いてサービス表記憶部
５６０に記憶されているサービス表を初期化する。

【００８５】一方、サービスディレクトリサーバ１００
に関する情報が含まれている場合、ステップ１７２０に
移行し、サービス管理部５４０は、サーバ通信部５１５
およびネットワークインターフェース部５３５を介し
て、当該情報により特定されるサービスディレクトリサ
ーバ１００との接続を試みる。そして、サービスディレ
クトリサーバ１００との接続に成功したか否かをチェッ
クする（ステップ１７２５）。その結果、サービスディ
レクトリサーバ１００との接続に失敗した場合は、ステ
ップ１７３５に移行し、バックアップファイル記憶部５
５５に情報が記憶されていれば、当該情報を用いてサー
ビス表記憶部５６０に記憶されているサービス表を初期
化する。

【００８６】一方、サービスディレクトリサーバ１００
との接続に成功した場合、サービス管理部５４０は、サ
ーバ通信部５１５およびネットワークインターフェース
部５３５を介して、上記のＯＰＥＮメッセージをサービ
スディレクトリサーバ１００に送信する（ステップ１７
３０）。これを受けて、サービスディレクトリサーバ１
００は、ＯＰＥＮメッセージを送信した通信ノード１２
０のクライアント登録を行う。

【００８７】次に、通信ノード１２０は、サービスディ
レクトリサーバ１００が持つすべてのサービス情報を取
得するための処理（ステップ１７４０〜１７５５）を行
う。上述したように、ＱＵＥＲＹメッセージのプロトコ
ル番号を０（ゼロ）にすることで、サービスディレクト
リサーバ１００が持つサービス情報を１個ずつ順番に取
得することができる。通信ノード１２０は、この仕組み
を使って、起動時に、サービスディレクトリサーバ１０
０が持つすべてのサービス情報を取得する。

【００８８】このため、先ず、サービス管理部５４０
は、プロトコル番号が０（ゼロ）のＱＵＥＲＹメッセー
ジを作成し、サーバ通信部５１５およびネットワークイ
ンターフェース部５３５を介して、サービスディレクト
リサーバ１００に送信する（ステップ１７４０）。ＱＵ
ＥＲＹメッセージのプロトコル番号が０になっているた
め、サービスディレクトリサーバ１００は、自身が保持
しているサービス情報を１つずつ取出してＲＥＰＬＹメ
ッセージを返信する。

【００８９】次に、サービス管理部５４０は、サーバ通
信部５１５およびネットワークインターフェース部５３
５を介して、サービスディレクトリサーバ１００からＲ
ＥＰＬＹメッセージを受け取ると、そのメッセージに含
まれているプロトコル番号が０か否かをチェックする
（ステップ１７４５）。もし、０ならば、すべてのサー
ビス情報を受信したことになるため処理を終了する。一
方、０でなければ、受信したＲＥＰＬＹメッセージに含
まれるサービス情報を、サービス表記憶部５６０に記憶
しているサービス表に追加する（ステップ１７５０）。
さらに、通信サーバ１２０を再起動した際に、サービス
ディレクトリサーバ１００に問合せなくても済むよう
に、バックアップファイルを更新して（ステップ１７５
５）、ステップ１７４０に戻る。

【００９０】以上の処理により、通信ノード１２０は、
サービスディレクトリサーバ１００が保持するすべての
サービス情報を取得することができ、このサービス情報
に基づいてサービス表を初期化することができる。これ
により、通信ノード１２０は、受信したパケットを、必
要に応じて、適切なサービス提供サーバ１１０に転送す
ることが可能となる。

【００９１】次に、サービスディレクトリサーバ１００
側での処理について説明する。

【００９２】図１３および図１４は、図８に示すシーケ
ンスにおけるサービスディレクトリサーバ１００側での
処理を説明するためのフロー図である。図１３はＯＰＥ
Ｎメッセージを受信した際の処理を示しており、図１４
はＱＵＥＲＹメッセージを受信した際の処理を示してい
る。

【００９３】図１３において、クライアント通信部３４
０は、ネットワークインターフェース部３５０を介し
て、ＯＰＥＮメッセージを受け取ると、当該メッセージ
からノードＩＤおよび認証情報を取り出し、その内容を
解析する（ステップ２５１０）。そして、当該メッセー
ジがネットワーク内に設置された正規の通信ノード１２
０から送られてきたメッセージであるか否かをチェック
する（ステップ２５１５）。ここで、認証情報には、た
とえば、サービスディレクトリサーバ１００と通信ノー
ド１２０との間であらかじめ設定されている秘密情報に
基づいて作成されたＯＰＥＮメッセージに対する電子署
名を用いる。このようにすることで、受け取ったＯＰＥ
Ｎメッセージと、前記秘密情報を用いて電子署名より得
たメッセージとが一致するか否かを検証することによ
り、当該メッセージが正規の通信ノード１２０から送ら
れてきたメッセージであるか否かを認証することができ
る。

【００９４】上記の結果、受信したＯＰＥＮメッセージ
が正当なものである場合、ステップ２５２０に移行し、
当該メッセージに含まれるノードＩＤなどのクライアン
ト情報をクライアントデータベース３８０に登録する
（ステップ２５２０）。一方、受信したＯＰＥＮメッセ
ージが不正なものである場合は、当該メッセージを破棄
する（ステップ２５２５）。

【００９５】また、図１４において、クライアント通信
部３４０は、ネットワークインターフェース部３５０を
介して、ＱＵＥＲＹメッセージを受け取ると、当該メッ
セージからプロトコル番号およびポート番号を取り出
し、サービス要求受付部３３０に渡す。これを受けて、
サービス要求受付部３３０は、プロトコル番号およびポ
ート番号を解析し、問い合わせ内容を確認する（ステッ
プ２６０５）。そして、サービスデータベース管理部３
２０を介して、確認した問い合わせに対応するサービス
情報をサービスデータベース３７０より検索する（ステ
ップ２６１０）。その結果、問い合わせに対応するサー
ビス情報がある場合は、その情報をクライアント通信部
３４０に渡す。これを受けて、クライアント通信部３４
０は、受け取ったサービス情報を含めてＲＥＰＬＹメッ
セージを作成し（ステップ２６２０）、ネットワークイ
ンターフェース部３５０を介して、ＱＵＥＲＹメッセー
ジを送信した通信ノード１２０に送信する（ステップ２
６３０）。一方、問い合わせに対応するサービス情報が
ない場合は、その旨をクライアント通信部３４０に知ら
せる。これを受けて、クライアント通信部３４０は、プ
ロトコル番号をサービス情報がないことを示す０に設定
したＲＥＰＬＹメッセージを作成し（ステップ２６２
５）、ネットワークインターフェース部３５０を介し
て、ＱＵＥＲＹメッセージを送信した通信ノード１２０
に送信する（ステップ２６３０）。

【００９６】以上、通信ノード１２０の初期化処理につ
いて説明した。

【００９７】次に、通信ノード１２０が、自身が保持す
るサービス表に登録されているサービスに関するパケッ
トを受信した場合におけるパケット転送処理（登録済サ
ービス処理）について説明する。

【００９８】図１５は、通信ノード１２０が、自身が保
持するサービス表に登録されているサービスに関するパ
ケットを受信した場合における、当該通信ノード１２０
およびサービス提供サーバ１１０間のパケット転送処理
（登録済サービス処理）シーケンスを示す図である。こ
の図では、通信ノード１２０−Ａおよびサービス提供サ
ーバ１１０間の場合を示しているが、他の通信ノード１
２０の場合も同様である。

【００９９】通信ノード１２０−Ａは、パケットを受信
すると、当該パケットに付与された宛先アドレスを調
べ、自身宛のものか否かを調べる（シーケンス１００
０）。自身宛のものである場合は、サービス表を参照し
て、前記パケットのプロトコル番号およびポート番号よ
り転送先のサービス提供サーバ１１０を調べ、その転送
先サービス提供サーバ１１０に転送する（シーケンス１
０１０）。パケットを受信したサービス提供サーバ１１
０は、当該パケットについて自身が提供するサービスに
応じた処理を行い、その後、処理結果をパケット送信元
の通信ノード１２０−Ａに通知する（シーケンス１０２
０）。

【０１００】次に、図１５に示す通信ノード１２０およ
びサービス提供サーバ１１０間のパケット転送処理（登
録済サービス処理）のシーケンスを、通信ノード１２０
側での処理とサービス提供サーバ１１０側での処理とに
分けて、より詳細に説明する。

【０１０１】まず、通信ノード１２０側での処理につい
て説明する。

【０１０２】図１６は、通信ノード１２０がパケットを
受信した場合の処理を説明するためのフロー図である。

【０１０３】まず、パケット転送処理部５３０は、ネッ
トワークインターフェース部５３５を介して、受け取っ
たパケットの宛先アドレスを調べ、自身宛のパケットで
あるか否かをチェックする（ステップ１８１０）。自身
宛のパケットでない場合は、ステップ１８３０に移行し
て、後述する通信ノード１２０間のパケット転送処理を
行う。

【０１０４】一方、自身宛のパケットである場合は、当
該パケットをサービス振分部５２５に渡す。これを受け
て、サービス振分部５２５は、サービス管理部５４０を
介して、サービス表記憶部５６０に記憶されているサー
ビス表を検索する（ステップ１８１０）。そして、受け
取ったパケットのプロトコル番号およびポート番号と合
致する振分条件を持つサービス情報がサービス表に登録
されているか否かをチェックする（ステップ１８１
５）。

【０１０５】その結果、受け取ったパケットのプロトコ
ル番号およびポート番号と合致する振分条件を持つサー
ビス情報がサービス表に登録されていない場合は、ステ
ップ１８２５に移行し、後述する未登録サービス処理を
行う。

【０１０６】一方、受け取ったパケットのプロトコル番
号およびポート番号と合致する振分条件を持つサービス
情報がサービス表に登録されている場合、ステップ１８
２０に移行し、図１５に示すシーケンスにしたがって、
登録済サービス処理を行う。

【０１０７】図１７は、図１６のステップ１８２０での
処理（登録済サービス処理）を説明するためのフロー図
である。

【０１０８】まず、サービス振分部５２５は、サービス
管理部５４０を介して、サービス表記憶部５６０に記憶
されたサービス表から、受信したパケットのプロトコル
番号およびポート番号に合致する振分条件を持つサービ
ス情報を取得すると（ステップ２００５）、当該情報に
クライアント処理スクリプトが含まれるか否かをチェッ
クする（ステップ２０１０）。クライアント処理が含ま
れる場合は、指定されたクライアント処理を自律処理部
５２０に実行させ（ステップ２０１５）、そうでなけれ
ば次に進む。

【０１０９】次に、サービス振分部５２５は、取得した
サービス情報にサーバ情報が含まれているか否かをチェ
ックし（ステップ２０２０）、含まれていない場合は処
理を終了する。一方、含まれている場合は、そのサーバ
情報により特定されるサービス提供サーバ１１０のアド
レスをパケットとともにサーバ通信部５１５に渡す。こ
れを受けて、サーバ通信部５１５は、ネットワークイン
ターフェース部を介して、受け取ったアドレスにより特
定されるサービス提供サーバ１１０へパケットを転送
し、処理を依頼する（ステップ２０２５）。

【０１１０】次に、サービス提供サーバ１１０側での処
理（サービス提供処理）について説明する。

【０１１１】図１８は、図１５に示すシーケンスでのサ
ービス提供サーバ１１０側での処理を説明するためのフ
ロー図である。

【０１１２】まず、クライアント通信部４４０は、ネッ
トワークインターフェース部４５０を介してパケットを
受け取ると、当該パケットをサービス処理部４３０に渡
す。これを受けて、サービス処理部４３０は、自身が提
供するサービスにしたがい、受け取ったパケットを処理
する（ステップ２０３０）。クライアント通信部４４０
は、サービス処理部４３０での処理結果を、ネットワー
クインターフェース部４５０を介して、パケット送信元
の通信ノード１２０へ通知する（ステップ２０３５）。

【０１１３】以上、通信ノード１２０が、自身が保持す
るサービス表に登録されているサービスに関するパケッ
トを受信した場合におけるパケット転送処理（登録済サ
ービス処理）について説明した。

【０１１４】次に、通信ノード１２０が、自身が保持す
るサービス表に未登録のサービスに関するパケットを受
信した場合におけるパケット転送処理（未登録サービス
処理）について説明する。

【０１１５】図１９は、通信ノード１２０が、自身が保
持するサービス表に未登録のサービスに関するパケット
を受信した場合における、当該通信ノード１２０とサー
ビスディレクトリサーバ１００およびサービス提供サー
バ１１０との間のパケット転送処理（未登録サービス処
理）シーケンスを示す図である。この図では、通信ノー
ド１２０−Ａとサービスディレクトリサーバ１００およ
びサービス提供サーバ１１０との間の場合を示している
が、他の通信ノード１２０の場合も同様である。

【０１１６】通信ノード１２０−Ａは、パケットを受信
すると、当該パケットに付与された宛先アドレスを調
べ、自身宛のものか否かを調べる（シーケンス１１０
０）。自身宛のものである場合は、サービス表を参照し
て、前記パケットのプロトコル番号およびポート番号よ
り転送先のサービス提供サーバを調べる。その結果、パ
ケットのプロトコル番号およびポート番号に対応する転
送先サービス提供サーバ１１０がない場合、そのプロト
コル番号とポート番号とを指定したＱＵＥＲＹメッセー
ジをサービスディレクトリサーバ１００に送信し、当該
パケットに関するサービス情報を問い合わせる（シーケ
ンス１１１０）。

【０１１７】これを受けて、サービスディレクトリサー
バ１００は、受け取ったＱＵＥＲＹメッセージに指定さ
れているプロトコル番号およびポート番号に対応するサ
ービス情報があればこれを含めたＲＥＰＬＹメッセージ
を、対応するサービス情報がなければプロトコル番号を
０に指定したＲＥＰＬＹメッセージを、ＱＵＥＲＹメッ
セージの送信元通信ノード１２０に返す（シーケンス１
１２０）。

【０１１８】通信ノード１２０−Ａは、受け取ったＲＥ
ＰＬＹメッセージより特定される転送先のサービス提供
サーバ１１０にパケットを転送する（シーケンス１０３
０）。パケットを受信したサービス提供サーバ１１０
は、当該パケットについて自身が提供するサービスに応
じた処理を行い、その後、処理結果をパケット送信元の
通信ノード１２０−Ａに通知する（シーケンス１１４
０）。

【０１１９】次に、図１９に示す通信ノード１２０とサ
ービスディレクトリサーバ１００およびサービス提供サ
ーバ１１０との間のパケット転送処理（未登録サービス
処理）のシーケンスを、より詳細に説明する。

【０１２０】なお、サービスディレクトリサーバ１００
側での処理、および、サービス提供サーバ１１０側での
処理は、それぞれ、図１４、図１８に示す処理と同様で
あるので、その説明を省略し、通信ノード１２０側での
処理についてのみ、説明することとする。

【０１２１】図２０は、図１６のステップ１８２５での
処理（未登録サービス処理）を説明するためのフロー図
である。このフローは、図１９に示すシーケンスでの通
信ノード１２０側での処理に対応している。

【０１２２】なお、本実施形態では、未登録のサービス
に関するパケットを受信した場合、通信ノード１２０
は、図１９に示すように、原則としてサービスディレク
トリサーバ１００への問合せを行い、そのサービスを提
供するサーバの情報の確認を行うようにしている。しか
しながら、未登録のサービスに関するパケットを受信す
る毎に、このような問い合わせ処理を行うと、サービス
ディレクトリサーバ１００への問合せのためにパケット
処理性能が大きく低下してしまうおそれがある。そこ
で、本実施形態では、ある未登録のサービスに関してサ
ービスディレクトリサーバ１００への問合せを行った結
果、そのサービスを提供するサーバの情報が得られなか
った場合には、一定時間、同じサービスについてのパケ
ットを問合せ抑止対象に設定することで、同じサービス
に関する問合せを行わないようにしている。

【０１２３】まず、サービス振分部５２５は、サービス
表記憶部５６０に記憶されたサービス表に、受信したパ
ケットのプロトコル番号およびポート番号に合致する振
分条件を持つサービス情報が登録されていないことを確
認すると、当該パケットに関するサービス情報のサービ
スディレクトリサーバ１００への問い合わせが、抑止の
対象となっているか否かをチェックする（ステップ２１
０５）。

【０１２４】その結果、抑止対象である場合は、ステッ
プ２１４０へ移行し、自律処理部５２０に後述する自律
処理を行わせる。一方、抑止対象でない場合は、そのパ
ケットのプロトコル番号およびポート番号をサーバ通信
部５１５に通知する。これを受けて、サーバ通信部５１
５は、受け取ったプロトコル番号およびポート番号を指
定したＱＵＥＲＹメッセージを作成し、ネットワークイ
ンターフェース部５３５を介して、サービスディレクト
リサーバ１００に送信する。これにより、サービス情報
を問い合わせる（ステップ２１１０）。

【０１２５】次に、サーバ通信部５１５は、ネットワー
クインターフェース部５３５を介して、サービスディレ
クトリインターフェース部５３５より、前記ＱＵＥＲＹ
メッセージに対するＲＥＰＬＹメッセージを受け取る
と、当該メッセージに含まれるプロトコル番号を調べる
ことで、前記受信した未登録サービスに関するパケット
について、サービス情報が得られたか否かをチェックす
る（ステップ２１１５）。サービス情報が得られなかっ
た場合は、その旨をサービス振分部５２５に知らせる。
これを受けて、サービス振分部５２５は、内蔵の抑止タ
イマを起動し、当該未登録サービスに関するパケット
を、一定時間、問合せ抑止対象に設定する（ステップ２
１３５）。その後、ステップ２１４０へ移行し、自律処
理部５２０に後述する自律処理を行わせる。

【０１２６】一方、ステップ２１１５において、前記受
信した未登録サービスに関するパケットについて、サー
ビス情報が得られた場合、サーバ通信部５１５は、サー
バ管理部５４０を介して、ＲＥＰＬＹメッセージに含ま
れるサービス情報をサービス表記憶部５６０に記憶され
ているサービス表に登録し（ステップ２１２０）、さら
にバックアップファイル記憶部５５５に記憶されている
バックアップファイルにも登録する（ステップ２１２
５）。その後、図１７に示すフローにしたがって、前記
受信したパケットについて、登録済みサービス処理を行
う（ステップ２１３０）。

【０１２７】図２１は、図２０のステップ２１４０での
処理（自律処理）を説明するためのフロー図である。

【０１２８】図２０において、サービス表に登録されて
おらず、かつサービスディレクトリサーバ１００に問合
せてもサービス情報が得られなかったサービスに関する
パケットは、通信ノード１２０が自律的に処理しなけれ
ばならない。そこで、本実施形態では、通信ノード１２
０にそのようなパケットを処理するためのプログラムが
あらかじめ組み込まれていればそれを使用し、組み込ま
れていなければ処理不能としてパケットを破棄すること
としている。

【０１２９】まず、サービス振分部５２５は、受信した
パケットについて、当該パケットに関するサービス情報
がサービス表に登録されておらず、かつサービスディレ
クトリサーバ１００に問合せても得られなかった場合、
当該パケットを自律処理部５２０に渡す。これを受け
て、自律処理部５２０は、受け取ったパケットのプロト
コル番号およびポート番号に対応するサービスを処理す
るための自律処理プログラムが自身に設定されているか
否かをチェックし（ステップ２２０５）、そのような自
律処理プログラムがある場合は、当該プログラムにした
がってパケットを処理する（ステップ２２１０）。一
方、そのような自律処理プログラムがない場合はパケッ
トを破棄する（ステップ２２１５）。

【０１３０】以上、通信ノード１２０が、自身が保持す
るサービス表に未登録のサービスに関するパケットを受
信した場合におけるパケット転送処理（未登録サービス
処理）について説明した。

【０１３１】次に、通信ノード１２０間のパケット転送
処理について説明する。

【０１３２】図２２は、通信ノード１２０間のパケット
転送処理シーケンスを示す図である。この図では、通信
ノード１２０−Ａから通信ノード１２０−Ｂへパケット
を転送する際の処理を示しているが、他の通信ノード１
２０間の場合も同様である。

【０１３３】通信ノード１２０−Ａは、パケットを受信
すると、当該パケットに付与された宛先アドレスを調
べ、自身宛のものか否かを調べる（シーケンス９０
０）。自身宛のものでない場合は、経路表を参照して、
前記宛先アドレスより転送先のゲートウェイを調べ、そ
の結果、転送先が通信ノード１２０−Ｂであれば、通信
ノード１２０−Ｂに転送する（シーケンス９１０）。パ
ケットを受信した通信ノード１２０−Ｂでも同様の処理
を行い、当該パケットを宛先アドレスに向けて転送する
（シーケンス９２０）。

【０１３４】図２３は、図１６のステップ１８３０での
処理（パケット転送処理）を説明するためのフロー図で
ある。このフローは、図２２に示すシーケンスでの通信
ノード１２０各々での処理に対応している。

【０１３５】まず、パケット転送処理部５３０は、ネッ
トワークインターフェース部５３５を介して受信したパ
ケットの宛先アドレスをキーにして、経路表管理部５４
５を介して、経路表記憶部５６５に記憶されている経路
表を検索し（ステップ１９０５）、当該アドレスに対応
する宛先ゲートウェイに関する情報があるか否かをを調
べる（ステップ１９１０）。その結果、宛先ゲートウェ
イに関する情報がある場合、ネットワークインターフェ
ース部５３５を介して、その宛先ゲートウェイにパケッ
トを転送する（ステップ１９１５）。一方、宛先ゲート
ウェイに関する情報がない場合は、パケットを破棄し
（ステップ１９２０）、当該パケットの送信元に対して
エラーを通知する（ステップ１９２５）。

【０１３６】以上、通信ノード１２０間のパケット転送
処理について説明した。

【０１３７】次に、ネットワークに新たに追加されたサ
ービス提供サーバ１１０、あるいは、提供するサービス
が変更されたサービス提供サーバ１１０が、自身に関す
るサービス情報をサービスディレクトリサーバ１００に
登録する際の処理（サービス登録処理）について説明す
る。

【０１３８】図２４は、ネットワークに新たに追加され
たサービス提供サーバ１１０、あるいは、提供するサー
ビスが変更されたサービス提供サーバ１１０が、自身に
関するサービス情報をサービスディレクトリサーバ１０
０に登録する際の処理（サービス登録処理）シーケンス
を示す図である。

【０１３９】まず、ネットワーク内に新たにサービス提
供サーバ１１０が設置されると、あるいは、あるサービ
ス提供サーバ１１０について、自身が提供するサービス
が変更されると、当該サービス提供サーバ１１０は、自
身が提供するサービスについてのサービス情報をディレ
クトリサーバ１００に送信する（シーケンス１２０
０）。これを受けて、ディレクトリサーバ１００は、受
け取ったサービス情報をサービスデータベースに登録す
るとともに、当該サービス情報を含んだＮＯＴＩＦＹメ
ッセージを各通信ノード１２０−Ａ〜１２０−Ｃへ送信
する（シーケンス１２１０〜１２２０）。

【０１４０】図２５は、サービスディレクトリサーバ１
００が各通信ノード１２０に送信するＮＯＴＩＦＹメッ
セージの内容を説明するための図である。ここで、ヘッ
ダ１６０５は、メッセージタイプやメッセージ長を含む
メッセージヘッダである。プロトコル番号１６１０およ
びポート番号１６２０は、サービスに対応するプロトコ
ル番号およびポート番号である。プロトコル番号１６１
０およびポート番号１６２０については、図１０に示す
ＱＵＥＲＹメッセージに含まれるプロトコル番号１４２
０およびポート番号１４３０と同じ意味を持っている。
サービス名１６３０は、サービスの種類を表す文字列で
あり、特定のサービス情報を管理するための便宜を図る
ために使用される。サーバ情報１６４０は、サービスを
提供するサービス提供サーバ１１０に関する情報であ
る。この情報には、少なくともサービス提供サーバ１１
０のアドレスが含まれる。

【０１４１】クライアント処理スクリプト１６５０は、
サービス提供サーバ１１０がサービスを行うために、通
信ノード１２０がパケットに対して行うべき一連の処理
を表す一種のプログラムである。クライアント処理を行
わなくてよいサービスの場合にはクライアント処理スク
リプト１６５０は空欄となる。

【０１４２】さて、図２４に戻り、ＮＯＴＩＦＹメッセ
ージを受け取った各通信ノード１２０−Ａ〜１２０−Ｃ
は、当該メッセージに含められるサービス情報にしたが
い、自身が所有するサービス表を更新する。

【０１４３】次に、図２４に示すサービス登録処理シー
ケンスを、サービス提供サーバ１１０側での処理と、サ
ービスディレクトリサーバ１１０側での処理と、通信ノ
ード１２０側での処理とに分けて、より詳細に説明す
る。

【０１４４】まず、サービス提供サーバ１１０側での処
理について説明する。

【０１４５】図２６は、図２４に示すシーケンスにおけ
るサービス提供サーバ１１０側での処理を説明するため
のフロー図である。

【０１４６】まず、サーバ通信部４６０は、サービス情
報の通知イベントが発生するのを待つ（ステップ２０４
０）。ここで、サービス情報の通知イベントとは、自身
のサービス提供サーバ１１０がネットワーク内に設置さ
れてから初めて使用される場合や、自身のサービス提供
サーバ１１０が提供するサービスが変更された場合な
ど、サービスディレクトリサーバ１００に対して自身の
サービス情報を通知する必要が生じた場合を指す。サー
ビス情報の通知イベントが発生すると、サーバ通信部４
６０は、ネットワークインターフェース部４５０を介し
て、自身のサービス情報をサービスディレクトリサーバ
１００に通知する（ステップ２０４５）。

【０１４７】次に、サービスディレクトリサーバ１００
側での処理について説明する。

【０１４８】図２７は、図２４に示すシーケンスにおけ
るサービスディレクトリサーバ１００側での処理を説明
するためのフロー図である。

【０１４９】まず、サーバ通信部３６０は、ネットワー
クインターフェース部３５０を介して、サービス提供サ
ーバ１１０よりサービス情報を受け取ると（ステップ２
７０５）、サービスデータベース管理部３２０を介して
サービスデータベース３７０に登録する（ステップ２７
１０）。また、クライアント通信部３４０に当該サービ
ス情報を渡す。これを受けて、クライアント通信部３４
０は、サーバ通信部３４０からの指示にしたがい、クラ
イアントデータベース３８０を検索し、クライアントデ
ータベース３８０にクライアントとして登録されている
通信ノード１２０の情報があるか否かをチェックする
（ステップ２７１５）。そして、当該情報がある場合
は、サービス提供サーバ１１０より受け取ったサービス
情報を含めた上記のＮＯＴＩＦＹメッセージを、ネット
ワークインターフェース部３５０を介して、登録されて
いる全ての通信ノード１２０各々に送信する（ステップ
２７２０、２７２５）。

【０１５０】次に、通信ノード１２０側での処理につい
て説明する。

【０１５１】図２８は、図２４に示すシーケンスにおけ
る通信ノード１２０側での処理を説明するためのフロー
図である。

【０１５２】まず、サーバ通信部５１５は、ネットワー
クインターフェース部５３５を介して、サービスディレ
クトリサーバ１００よりＮＯＴＩＦＹメッセージを受け
取ると、当該メッセージに含まれるサービス情報をサー
ビス管理部５４０に渡す。これを受けて、サービス管理
部５４０は、受け取ったサービス情報に基づいて、サー
ビス表記憶部５６０に記憶されているサービス表を更新
するとともに（ステップ２３１０）、バックアップファ
イル記憶部５５５に記憶されているバックアップファイ
ルを更新する（ステップ２３２０）。

【０１５３】以上、ネットワークに新たに追加されたサ
ービス提供サーバ１１０、あるいは、提供するサービス
が変更されたサービス提供サーバ１１０が、自身に関す
るサービス情報をサービスディレクトリサーバ１００に
登録する際の処理（サービス登録処理）について説明し
た。

【０１５４】最後に、サービスディレクトリサーバ１０
０の初期化処理について説明する。サービスディレクト
リサーバ１００の初期化処理は、サービスディレクトリ
サーバ１００をネットワーク内に設置後、初めて使用す
る際に行われる。

【０１５５】図２９は、サービスディレクトリサーバ１
００の初期化処理について説明するためのフロー図であ
る。

【０１５６】サービスディレクトリサーバ１００が起動
されると、サービスデータベース管理部３２０は、サー
ビスデータベース３７０を初期化し、当該データベース
にたとえばデフォルトのサービス情報を登録する（ステ
ップ２４１０）。また、クライアント通信部３４０は、
クライアントデータベース３８０を初期化し、当該デー
タベースにたとえばデフォルトのクライアント情報を登
録する（ステップ２４２０）。

【０１５７】以上、本発明の一実施形態について説明し
た。

【０１５８】本実施形態において、サービスディレクト
リサーバ１００は、ネットワーク内に設置されている各
サービス提供サーバ１１０のサービス情報を一元管理し
ている。そして、そのサービス情報をネットワーク内の
各通信ノード１２０に、自動的にあるいは各通信ノード
１２０からの依頼に応じて配布している。たとえば、通
信ノード１２０が新たに設置された場合は、当該通信ノ
ード１２０からの問い合わせにより、自身が管理してい
る各サービス提供サーバ１１０のサービス情報を当該通
信サーバ１３０に送信する。また、サービス提供サーバ
１１０よりサービス情報が通知された場合は、自身のク
ライアントデータベース３８０に登録されている各通信
ノード１２０へ、前記通知されたサービス情報を送信す
る。

【０１５９】一方、各通信ノード１２０は、受信したパ
ケットのうち、自身宛のパケットについて、当該パケッ
トを処理すべきサービス提供サーバ１１０を、サービス
ディレクトリサーバ１００により提供されたサービス情
報に基づいて決定し、当該パケットを前記決定したサー
ビス提供サーバ１１０に転送することにより、そのパケ
ットをそのサービス提供サーバ１１０に処理させてい
る。

【０１６０】したがって、本実施形態によれば、ネット
ワーク運用管理者は、ネットワークにサービス提供サー
バ１１０が新たに追加された場合や既存のサービス提供
サーバ１１０が提供するサービスを変更した場合でも、
従来のネットワークシステムと異なり、各通信ノード１
２０に対して設定作業を行う必要がなくなる。すなわ
ち、ネットワーク運用管理者は、サービスディレクトリ
サーバ１００に保持されているサービス情報のみを維持
・管理し、必要に応じて変更すればよいので、ネットワ
ークの運用管理コストを低減することができる。また、
これにより、ネットワーク運用管理者の設定作業量を減
らすことができるので、ネットワーク運用管理者の設定
ミスを低減させることが期待できる。さらに、設定作業
に要する時間を大幅に短縮することができる。

【０１６１】また、本実施形態では、サービスディレク
トリサーバ１００は、クライアント通信部３４０によ
り、各通信ノード１２０とのセッションを管理するよう
にしているので、各通信ノード１２０毎に、提供するサ
ービス情報を変えることもできる。たとえば、複数の通
信ノード１２０をいくつかのグループに分類し、グルー
プごとに異なるサービス提供サーバ１１０を使用するよ
うに提供するサービス情報を変えることも可能である。

【０１６２】また、本実施形態では、サービスディレク
トリサーバ１００が各通信ノード１２０へサービス情報
を自動配布する場合、ＮＯＴＩＦＹメッセージにサービ
ス情報を含めることで行っている。このように、ＮＯＴ
ＩＦＹメッセージを使用することで、サービスディレク
トリサーバ１００は、任意のタイミングで通信ノード１
２０各々にサービス情報を通知することが可能になる。
これにより、たとえば、通信ノード１２０各々が使用す
るサービス提供サーバ１１０を時間帯によって別のサー
ビス提供サーバ１１０に変更したりすることができる。

【０１６３】従来のネットワークシステムでも上記のよ
うな使い方は可能であるが、すべての通信ノード各々に
対して情報設定を行わなければならないため、ネットワ
ーク運用管理者に大きな負担がかかり、実際には困難で
あった。サービスディレクトリサーバ１００を利用すれ
ばサービスディレクトリサーバ１００に設定を行うだけ
で、関係するすべての通信ノードに適切なサービス情報
を配布することができるため、ネットワーク運用管理者
に大きな負担をかけることなく、上記のような新しい利
用形態を提供することができる。

【０１６４】さらに、本実施形態では、サービスディレ
クトリサーバ１００において、ＯＰＥＮメッセージに含
まれる認証情報を用いて、通信ノード１２０のサービス
ディレクトリサーバ１００に対するアクセス権をチェッ
クしている。

【０１６５】このようにすることで、正当な権限を有す
る通信ノード１２０だけがサービスディレクトリサーバ
１００よりサービス情報の提供を受けることができる。
これにより、システムの安全性を高めることができる。

【０１６６】なお、本発明は、上記の実施形態に限定さ
れるものではなく、その要旨の範囲内で数々の変形が可
能である。

【０１６７】たとえば、上記の実施形態では、サービス
ディレクトリサーバ１００において、ＯＰＥＮメッセー
ジに含まれる認証情報を用いて、通信ノード１２０のサ
ービスディレクトリサーバ１００に対するアクセス権を
チェックしている。しかしながら、ネットワーク内に通
信ノード１２０のサービスディレクトリサーバ１００に
対するアクセス権をチェックするための認証サーバを別
途設置し、サービスディレクトリサーバ１００は、通信
ノード１２０からＯＰＥＮメッセージを受け取った場合
に、当該メッセージに含まれる認証情報を前記認証サー
バに転送し、前記認証サーバにて、受け取った認証情報
を用いて、通信ノード１２０のサービスディレクトリサ
ーバ１００に対するアクセス権をチェックするようにし
てもよい。

【０１６８】また、本実施形態では、サービス情報の定
義やネットワーク経由でのサービス情報取得のために独
自のプロトコルを定義して使用しているが、ＬＤＡＰ
（Lightweight Directory Access Protocol）などのデ
ィレクトリアクセスプロトコルやＣＯＲＢＡ（Common O
bject Request Broker Architecture）などの分散オブ
ジェクト技術などを使用するようにしてもよい。

【０１６９】また、本実施形態では、ネットワーク内に
１つのサービスディレクトリサーバ１００を設置してい
るが、サービスディレクトリサーバ１００を２重化して
もよい。そして、通常の運用時には、マスタ（運用系）
のサービスディレクトリサーバ１００を稼働させ、マス
タのサービスディレクトリサーバ１００に障害が発生し
た場合に、稼働対象をスレーブ（準備系）のサービスデ
ィレクトリサーバ１００に切り替えるようにしてもよ
い。

【０１７０】

【発明の効果】以上説明したように、本発明によれば、
ネットワークシステム、特に、多くの通信ノードが稼働
する大規模なネットワークシステムにおいて、サービス
を提供するサーバを新たに設置した場合や既存のサーバ
が提供するサービスを変更した場合でも、そのために必
要となる設定作業の負担を低減させることができる。

【図面の簡単な説明】

【図１】本発明の一実施形態が適用された統合サービス
ネットワークシステムの概略構成図である。

【図２】図１に示すサービスディレクトリサーバ１０
０、サービス提供サーバ１１０および通信ノード１２０
のハードウエア構成の一例を示す図である。

【図３】図１に示すサービスディレクトリサーバ１００
の機能構成図である。

【図４】図１に示すサービス提供サーバ１１０の機能構
成図である。

【図５】図１に示す通信ノード１２０の機能構成図であ
る。

【図６】図５に示すサービス表記憶部５６０に記憶され
るサービス表の内容を説明するための図である。

【図７】図５に示す経路表記憶部５６５に記憶される経
路表の内容を説明するための図である。

【図８】通信ノード１２０の初期化処理シーケンスを示
す図である。

【図９】図８において、通信ノード１２０がサービスデ
ィレクトリサーバ１００へ送信するＯＰＥＮメッセージ
の内容を説明するための図である。

【図１０】図８において、通信ノード１２０がサービス
ディレクトリサーバ１００へ送信するＱＵＥＲＹメッセ
ージの内容を説明するための図である。

【図１１】図８において、サービスディレクトリサーバ
１００が通信ノード１２０へ送信するＲＥＰＬＹメッセ
ージの内容を説明するための図である。

【図１２】図８に示すシーケンスにおける通信ノード１
２０側での処理を説明するためのフロー図である。

【図１３】図８に示すシーケンスにおけるサービスディ
レクトリサーバ１００側での処理を説明するためのフロ
ー図であり、ＯＰＥＮメッセージを受信した際の処理を
示す図である。

【図１４】図８に示すシーケンスにおけるサービスディ
レクトリサーバ１００側での処理を説明するためのフロ
ー図であり、ＱＵＥＲＹメッセージを受信した際の処理
を示す図である。

【図１５】通信ノード１２０が、自身が保持するサービ
ス表に登録されているサービスに関するパケットを受信
した場合における、当該通信ノード１２０およびサービ
ス提供サーバ１１０間のパケット転送処理（登録済サー
ビス処理）シーケンスを示す図である。

【図１６】通信ノード１２０がパケットを受信した場合
の処理を説明するためのフロー図である。

【図１７】図１６のステップ１８２０での処理（登録済
サービス処理）を説明するためのフロー図である。

【図１８】図１５に示すシーケンスでのサービス提供サ
ーバ１１０側での処理を説明するためのフロー図であ
る。

【図１９】通信ノード１２０が、自身が保持するサービ
ス表に未登録のサービスに関するパケットを受信した場
合における、当該通信ノード１２０とサービスディレク
トリサーバ１００およびサービス提供サーバ１１０との
間のパケット転送処理（未登録サービス処理）シーケン
スを示す図である。

【図２０】図１６のステップ１８２５での処理（未登録
サービス処理）を説明するためのフロー図である。

【図２１】図２０のステップ２１４０での処理（自律処
理）を説明するためのフロー図である。

【図２２】通信ノード１２０間のパケット転送処理シー
ケンスを示す図である。

【図２３】図１６のステップ１８３０での処理（パケッ
ト転送処理）を説明するためのフロー図である。

【図２４】ネットワークに新たに追加されたサービス提
供サーバ１１０、あるいは、提供するサービスが変更さ
れたサービス提供サーバ１１０が、自身に関するサービ
ス情報をサービスディレクトリサーバ１００に登録する
際の処理（サービス登録処理）シーケンスを示す図であ
る。

【図２５】図２４において、サービスディレクトリサー
バ１００が各通信ノード１２０に送信するＮＯＴＩＦＹ
メッセージの内容を説明するための図である。

【図２６】図２４に示すシーケンスにおけるサービス提
供サーバ１１０側での処理を説明するためのフロー図で
ある。

【図２７】図２４に示すシーケンスにおけるサービスデ
ィレクトリサーバ１００側での処理を説明するためのフ
ロー図である。

【図２８】図２４に示すシーケンスにおける通信ノード
１２０側での処理を説明するためのフロー図である。

【図２９】サービスディレクトリサーバ１００の初期化
処理について説明するためのフロー図である。

【符号の説明】

１００：サービスディレクトリサーバ １１０−Ａ〜１１０−Ｃ：サービス提供サーバ １２０−Ａ〜１２０−Ｃ：通信ノード ２００：ＣＰＵ、 ２１０：メモリ、 ２１３：ＯＳ ２１５：制御プログラム、 ２２０：ネットワークコン
トローラ ２３０：キーボードコントローラ、 ２３５：キーボー
ド ２４０：シリアルコントローラ、 ２４５：マウス ２５０：ディスプレイコントローラ、 ２５５：ディス
プレイ ２６０：ディスクコントローラ、 ２６５：ディスク装
置 ３１０、５０５：入出力制御部、 ３２０：サービスデ
ータベース管理部 ３３０：サービス要求受付部、 ３４０，４４０：クラ
イアント通信部 ３５０，４５０，５３５：ネットワークインタフェース
部 ３６０，４６０，５１５：サーバ通信部、 ３７０：サ
ービスデータベース ３８０：クライアントデータベース、 ４３０：サービ
ス処理部 ５１０：制御・管理部、 ５２０：自律処理部、 ５２
５：サービス振分部 ５３０：パケット転送処理部、 ５４０：サービス管理
部 ５４５：経路表管理部、 ５５０：設定情報記憶部 ５５５：バックアップファイル記憶部、 ５６０：サー
ビス表記憶部 ５６５：経路表記憶部

フロントページの続き (72)発明者 高田 治 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 瀬戸山 徹 神奈川県横浜市戸塚区戸塚町216番地 株 式会社日立製作所情報通信事業部内 (72)発明者 吉田 健一 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 Ｆターム(参考） 5B089 GA11 HA10 HB02 JA35 JB22 KA10 KA13 KB04 5K033 AA03 BA04 CB01 DB12 DB14 DB16 EC04

Claims (5)

【特許請求の範囲】
1. 【請求項１】受信したパケットを当該パケットに付与さ
   れた宛先に転送する少なくとも１つの通信ノードと、所
   定のサービスを提供する少なくとも１つのサーバと、デ
   ィレクトリサーバとを有する通信ネットワークシステム
   であって、 前記ディレクトリサーバは、 前記サーバが提供するサービスを受けるための条件に関
   するサービス情報を記憶する記憶手段と、 前記記憶手段に記憶されたサービス情報を前記通信ノー
   ドに提供する情報提供手段と、を備え、 前記通信ノードは、 受信したパケットのうち、特定の種類のパケットについ
   て、当該パケットを処理すべきサーバを、前記ディレク
   トリサーバより提供されたサービス情報に基づいて決定
   する決定手段と、 前記特定の種類のパケットを、前記決定手段で決定され
   たサーバに転送する特定パケット転送手段と、を備える
   ことを特徴とする通信ネットワークシステム。
2. 【請求項２】請求項１記載の通信ネットワークシステム
   であって、 前記通信ノードの前記決定手段は、前記特定の種類のパ
   ケットについて、当該パケットを処理すべきサーバが前
   記ディレクトリサーバより提供されたサービス情報に含
   まれていないと判断した場合に、当該特定の種類のパケ
   ットを処理すべきサーバに関する問い合わせを前記ディ
   レクトリサーバに通知し、 前記ディレクトリサーバの前記情報提供手段は、 前記通信ノードより通知された問い合わせ対象となるサ
   ーバに関するサービス情報を前記記憶手段より検索し、
   検索結果を前記問い合わせを通知した前記通信ノードに
   提供することを特徴とする通信ネットワークシステム。
3. 【請求項３】所定のサービスを提供する少なくとも１つ
   のサーバとディレクトリサーバとを有する通信ネットワ
   ークシステムに用いられる、受信したパケットを当該パ
   ケットに付与された宛先に転送する通信ノードであっ
   て、 受信したパケットのうち、特定の種類のパケットについ
   て、当該パケットを処理すべきサーバを、前記ディレク
   トリサーバより提供された、サーバが提供するサービス
   を受けるための条件に関するサービス情報に基づいて決
   定する決定手段と、 前記特定の種類のパケットを、前記決定手段で決定され
   たサーバに転送する特定パケット転送手段と、を備える
   ことを特徴とする通信ノード。
4. 【請求項４】受信したパケットを当該パケットに付与さ
   れた宛先に転送するとともに、受信したパケットのうち
   特定の種類のパケットを当該パケットを処理すべきサー
   バに転送する少なくとも１つの通信ノードと、所定のサ
   ービスを提供する少なくとも１つのサーバとを有する通
   信ネットワークシステムに用いられるディレクトリサー
   バであって、 前記サーバが提供するサービスを受けるための条件に関
   するサービス情報を記憶する記憶手段と、 自動的にあるいは前記通信ノードからの依頼により、前
   記記憶手段に記憶されたサービス情報を前記通信ノード
   に提供する情報提供手段と、を備えることをを特徴とす
   るディレクトリサーバ。
5. 【請求項５】受信したパケットを当該パケットに付与さ
   れた宛先に転送する少なくとも１つの通信ノードと、所
   定のサービスを提供する少なくとも１つのサーバと、デ
   ィレクトリサーバとを有する通信ネットワークシステム
   において、前記通信ノードが前記サーバが提供するサー
   ビスを受けるためのサービス管理方法であって、 前記ディレクトリサーバは、自動的にあるいは前記通信
   ノードからの依頼により、自身が管理している前記少な
   くとも１つのサーバが提供するサービスを受けるための
   条件に関するサービス情報を、前記通信ノードに提供
   し、 前記通信ノードは、受信したパケットのうち、特定の種
   類のパケットについて、当該パケットを処理すべきサー
   バを、前記ディレクトリサーバより提供されたサービス
   情報に基づいて決定し、決定したサーバに転送し、 前記サーバは、受信したパケットを自身が提供するサー
   ビスにしたがい処理し、結果を前記パケットの送信元通
   信ノードに通知することを特徴とする通信ネットワーク
   システムにおけるサービス管理方法。