JP4372098B2 - ネットワークにおける特定サービスの最適ルーティング方法並びに同ネットワークに用いられるサーバ及びルーティングノード - Google Patents

Description

本発明は、ネットワークにおける特定サービスの最適ルーティング方法並びに同ネットワークに用いられるサーバ及びルーティングノードに関し、例えば、特定のサービスを提供しているサーバ（マスター）と、それと同一のサービス内容を反映し、別のサーバにて同一のサービス内容を提供しているサーバ群（ミラー）が存在する状況で、それらの位置（アドレス）や稼動状況を端末が意識することなく、端末から最適と思われるサーバに対してアクセスを行なうことができるようにするのに好適な技術に関する。

現在、インターネット等のネットワーク上には様々なサービスを提供するサーバが存在し、アクセスが集中するサービスに対する方策として、ネットワーク上で物理的に離れた別のサーバが、サービス内容だけを同一にして提供し、ユーザに自分で宛先を選んでアクセスしてもらう方法がある。また、特定サービスを提供しているサーバに接続している負
荷分散装置間で、最適な宛先に転送する方法もある。

ここで、前者の方法では、ユーザは該当サービスがどこにあるのかを知っていなければならない。また、サービスのリストを提供している場所もあるが、どれを選択するかはユーザ任せなので、負荷が効率的に分散できないという課題がある。また、サービスが一時的に停止してしまっているサーバがリスト中のどれなのかといった情報も与えられないため、アクセスしたがサービスを受けられないといった状況が発生するといった課題もある。さらに、それら情報を端末から自動的に認識させるには、収集しなければならない情報が膨大となり、事実上不可能である。

これに対し、後者の方法では、負荷分散装置が、自分の配下に接続しているサーバの内容を知らなければならないが、サーバを追加しても負荷分散装置は自動的には認識しないため、それら情報を負荷分散装置に教えなければならない。また、負荷分散装置間がネットワーク上で離れた位置に存在する場合は、ネットワークの状況によって最適な宛先が異なる場合があるが、負荷分散装置ではネットワークの内部状況を把握していないため、効果的な負荷分散が実現できていない場合もある。

また他に、従来技術として、下記の特許文献１や特許文献２により提案されている技術がある。
特許文献１に記載された技術は、ルーティングプロトコルに帯域情報に関する属性を新たに設け、ルーティング情報と併せて他ネットワークから流入したトラヒックの帯域情報を自ネットワーク内の他ボーダルータに通知し自ネットワーク内から流出するトラヒックの帯域情報を他ネットワークのボーダルータに通知するというものである。これにより、特許文献１の技術では、少ない設備投資および改造により、入力可能帯域情報を自動的に全ボーダルータに通知することができて、ネットワーク管理者の手間を省くとともに、人為的なミスを抑えることが可能となる。

一方、特許文献２に記載された技術は、分散型データベースの管理方法に関するもので、複数個のサーバを、用途（サービス）別に分類（グループ化）したサーバ情報管理テーブルに基づいてサーバを選択するが、その際、サーバ毎の負荷テーブルを設けて、最も負荷の低いサーバを選択したり、複数のサーバの記憶媒体（ディスク，テープ等）の使用状況テーブルを設けて、最も空き容量の多いサーバを選択したり、用途別の情報検索キーと、情報格納先のサーバＩＤを、格納先管理用のサーバに検索キー・サーバＩＤテーブルとして登録しておき、利用者からの只１回のサービス要求に基づいて、サーバを意識することなく、必要なサービスを利用できるようにしたものである。
特開２００２−３７４２９３号公報 特開平６−２５９３０８号公報

しかしながら、特許文献１に記載の技術では、ネットワークの帯域管理は行なえても、アクセスが集中するサーバへのアクセスの宛先を変更して、負荷を分散させるという制御は行なえない。
また、特許文献２に記載の技術では、サーバの負荷や記憶容量の使用状況などに応じて最適なサーバを選択することができるが、データベースのサーバとして何があり、どのサーバがどの情報をもつかを事前にサーバ情報管理テーブルにもっていなければならない。即ち、あくまで、サーバ負荷や記憶容量の使用状況のみが更新対象である。
これは、ネットワークの世界では前述した負荷分散装置で既に実現している方法と同じである。そのため、前述したものと同様の課題がある。また、上記特許文献２には、上記のサーバ情報管理テーブルをルータにもたせることも可能である旨が開示されているが、単にルータにサーバ管理情報をもたせても、ネットワーク上のサーバ群の情報をネットワーク内で自動的に認識して共有・更新し、当該ネットワークで現在提供されているサービスの内容や稼動状況をユーザが意識することなく、ネットワーク独自に最適な宛先を選択
することは不可能である。

本発明は、以上のような課題に鑑み創案されたもので、ネットワーク上のサーバ群の情報（位置情報やサービス稼動状況等）をネットワーク内（ルータ等）で自動的に認識して共有・更新することを可能とし、サーバ群それぞれの位置情報やサービス稼動状況をユーザが意識することなく、ネットワーク独自に最適な宛先を選択できるようにして、多数のユーザ端末からのアクセスを効果的に振り分けられるようにすることを目的とする。

上記の目的を達成するために、本発明のネットワークにおける特定サービスの最適ルーティング方法は、複数のサーバと、該サーバに対するサービスアクセス要求を当該サービスアクセス要求に付与されている宛先情報に従ってルーティングする複数のルーティングノードとをそなえたネットワークにおいて、該サーバで提供するサービス内容に関する情報（以下、サービス情報という）を、該ルーティングノード間の経路制御に用いられるルーティングプロトコルに従って前記各ルーティングノード間で交換されるルーティング情報に含めて送受することにより、各ルーティングノードにおいて登録・更新し、該ルーティングノードが、それぞれ、自己の保有する該サービス情報に基づいて該サービスアクセス要求の宛先情報を選択的に変更して最適な宛先へルーティングし、さらに、同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、該ミラーサーバが、自己の提供するサービス内容の更新を行なうためのアクセス要求を該ミラーサーバと接続されているルーティングノードへ送信し、該ルーティングノードは、該アクセス要求の宛先情報を該マスターサーバへの直接アクセスを可能とする直接アクセス用宛先情報に変換して該アクセス要求データのルーティングを行なうことを特徴としている。

ここで、該サーバで提供するサービス種別を示すサービス識別子を含む該サービス情報を、該ルーティングプロトコルを用いて各ルーティングノードにおいて登録・更新し、該ルーティングノードが、それぞれ、該サービス識別子に基づいて該サービス種別単位で該サービスアクセス要求のルーティングを行なってもよい。
また、該サービス識別子として、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）を用いることもできる。

さらに、該サーバが、自己のサービス稼動状況をサービス稼動状況通知メッセージにより自己が接続されているルーティングノードに通知し、当該ルーティングノードが、該サービス稼動状況通知メッセージにより通知されたサービス稼動状況に応じて自己が保有する該サービス情報を更新するとともに、該サービス情報の更新を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることもできる。

また、該サーバが、自己の提供する該サービス内容が更新される毎にサービス更新メッセージを当該サーバが接続されているルーティングノードに送信し、該ルーティングノードが、該サーバから該サービス更新メッセージを一定期間受信しないときは該サービス内容についてのサービス情報の登録を削除するとともに、当該サービス情報の削除を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることもできる。

さらに、該ルーティングノードが、該サービス更新メッセージを一定期間受信しない場合でも非更新対象のサービス内容についてのサービス情報の登録は維持することもできる。
さらに、同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、該マスターサーバが、定期的に該サービス稼動状況通知メッセージを自己が接続されているルーティングノードへ通知し、該ルーティングノードが、該サービス稼動状況通知メッセージにより該マスターサーバが一定期間稼動停止していると判断すると、該ミラーサーバについての該サービス情報の登録を削除するとともに、当該サービス情報の削除を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることもできる。

また、該ルーティングノードが、それぞれ、他のルーティングノードから該ルーティングプロトコルにより定期的に受信されるべき生死確認情報の受信を監視することにより該他のルーティングノードの稼動状況を監視し、該他のルーティングノードの稼動停止が確認されると、自己が保有するサービス情報のうち当該稼動停止した他のルーティングノードについてのサービス情報を削除するとともに、当該サービス情報の削除を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることもできる。

さらに、本発明のネットワークに用いられるサーバは、複数のサーバと、該サーバに対するサービスアクセス要求を当該サービスアクセス要求に付与されている宛先情報に従ってルーティングする複数のルーティングノードとをそなえたネットワークに用いられるものであって、自己が提供するサービス内容に関する情報（サービス情報）を自己と接続されているルーティングノードに通知するサービス通知手段と、自己のサービス稼動状況を該ルーティングノードに通知するサービス稼動状況通知手段とをそなえるとともに、自己以外に自己と同一のサービス内容を提供するミラーサーバが存在する場合において、該ミラーサーバが、該ミラーサーバの提供するサービス内容の更新を行なう際に自己への直接アクセスを可能とする直接アクセス用宛先情報を自己に接続されているルーティングノードへ通知する直接アクセス用宛先情報通知手段をそなえたことを特徴としている。

ここで、該サービス通知手段は、該サービス内容に更新があると、更新後の該サービス内容に関する情報を該ルーティングノードへ通知するサービス更新通知手段をそなえて構成されていてもよい。
さらに、本発明のネットワークに用いられるルーティングノードは、複数のサーバと、該サーバに対するサービスアクセス要求を当該サービスアクセス要求に付与されている宛先情報に従ってルーティングする複数のルーティングノードとをそなえたネットワークに用いられるものであって、自己と接続されているサーバ又は他のルーティングノードから該サーバで提供するサービス内容に関する情報（サービス情報）を受信して、該サービス情報の登録及び更新を管理するサービス情報管理手段と、該サービス情報管理手段での該サービス情報の登録・更新に伴って、該サービス情報を、該ルーティングノード間の経路制御に用いられるルーティングプロトコルに従って前記各ルーティングノード間で交換されるルーティング情報に含めてさらに他のルーティングノードへ伝達するサービス情報伝達手段と、該サービス情報管理手段の該サービス情報に基づいて該サービスアクセス要求の宛先情報を選択的に変更して最適な宛先へルーティングするルーティング制御手段とをそなえ、さらに、同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、該サービス情報管理手段が、該マスターサーバへ該ミラーサーバが自己の提供するサービス内容の更新を行なう際に該マスターサーバへの直接アクセスを可能とする直接アクセス用宛先情報を要求する手段と、該要求に対して該マスターサーバから受信される該直接アクセス用宛先情報を該サービス情報に含めて他のルーティングノードに伝達する手段とをそなえたことを特徴としている。

ここで、該サービス情報管理手段は、該サーバの提供するサービス種別を示すサービス識別子を含む該サービス情報を保持・管理するように構成されるとともに、該ルーティング制御手段は、該サービス識別子に基づいて該サービス種別単位で該サービスアクセス要求のルーティングを行なうように構成されていてもよい。
また、該サービス情報管理手段は、該サービス識別子としてＵＲＬを保持・管理するのが好ましい。

さらに、該サービス情報管理手段は、該サーバから通知される当該サーバのサービス稼動状況に応じて該サービス情報を更新する手段をそなえていてもよい。
また、該サービス情報管理手段は、該サーバから当該サーバの提供する該サービス内容が更新される毎に通知されるサービス更新メッセージを一定期間受信しないときは当該サービス内容についてのサービス情報の登録を削除する手段をそなえていてもよい。

さらに、該サービス情報管理手段は、該サービス更新メッセージを一定期間受信しない場合でも非更新対象のサービス内容についてのサービス情報の登録は維持する手段をそなえていてもよい。
また、同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、該サービス情報管理手段は、該マスターサーバが定期的に発行するサービス稼動状況通知メッセージにより該マスターサーバが一定期間稼動停止しているか否かを判断する手段と、該マスターサーバが稼動停止していると判断すると、該サービス情報管理手段における該ミラーサーバについての該サービス情報の登録を削除する手段とをそなえていてもよい。

さらに、該サービス情報管理手段は、他のルーティングノードから該ルーティングプロトコルにより定期的に受信されるべき生死確認情報の受信を監視することにより該他のルーティングノードの稼動状況を監視する手段と、該監視により該他のルーティングノードの稼動停止が確認されると、該サービス情報管理手段において自己が保有するサービス情報のうち当該稼動停止した他のルーティングノードについてのサービス情報を削除する手段とをそなえていてもよい。

また、該ルーティング制御手段は、該ミラーサーバから受信されるアクセス要求の宛先情報を該直接アクセス用宛先情報に変換する宛先変換手段をそなえていてもよい。

図１は本発明の一実施形態に係るネットワーク構成を示すブロック図で、この図１に示すネットワークは、複数のサーバ１，２と、複数のルータ（ルーティングノード）３と、複数のユーザ端末（以下、単に「端末」ともいう）５，６とをそなえて構成されており、この場合は、サーバ１及びユーザ端末５がルータ３Ａに接続され、サーバ２及びユーザ端末６がルータ３Ｂに接続されている。なお、以下において、ルータ３Ａ，３Ｂを区別しない場合は「ルータ３」と表記する。

サーバ１，２は、それぞれ、ユーザ端末（以下、単に「端末」ともいう）５，６に対して或る特定のサービスを提供するものであるが、ここでは、例えば、サーバ１をマスターサーバ、サーバ２をマスターサーバ１が提供するサービスと同一サービス内容を提供するミラーサーバとする。なお、この図１では、サーバ，ルータ，ユーザ端末をそれぞれ２台ずつしか図示していないが、これらの台数は、勿論、この図１に示すものに限定されるものではない。

そして、本実施形態では、ルータ３間でＢＧＰ４（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ４）等の所定のルーティングプロトコルに従って経路情報
の送受等に用いられる制御メッセージに、ネットワーク上で提供されているサービスに関する情報（どのサーバ１，２がどのようなサービスを提供しているか等の情報）も付加す
るようになっている。

これにより、ネットワーク全体が各種サービスの場所を認識することができるようになるため、ルータ３において最適な宛先への中継（ルーティング）を行なうことが可能となる。また、ルータ３間の既存の制御メッセージに付加することで、ルータ３の稼動状況も直接的もしくは間接的に認識でき、それら情報によって最適な宛先を変更することも可能となる。

さらに、サービスを提供するサーバ１，２が、それぞれ、自己の提供するサービスの種別や稼動状況を自己と接続されているルータ３Ａ，３Ｂに伝え、ルータ３，４がそれを認識することで、サーバの追加等に対してもネットワーク上のルータ３Ａ，３Ｂは自動的に認識でき、サーバの追加等の後においても最適な宛先決定を行なうことが可能となる。また、ルータ３Ａ，３Ｂは、それぞれ、自己と接続されているサーバ１，２についてのみ状態の監視を行ない、他ルータ３に接続しているサーバについては、ルータ３間の制御メッセージに付加されたサービス情報から得ることで、ネットワーク上の全サーバを単一の装置で認識・管理する必要はなく、サーバの認識処理に膨大な時間がかかることもない。

以下、このような本実施形態の最適ルーティング方式の詳細について説明する。まず、サーバ１，２が提供するサービス内容をルータ３Ａ，３Ｂが認識するための方式について述べ、次に、ルータ３間で送受するルーティングプロトコルの付加情報（サービス内容の通知）の内容と、それを送受する方式について述べる。
〔Ａ〕サーバによる提供サービス内容通知及び稼動状況通知方式
まず、サーバ１（又は２）と当該サーバ１（又は２）に接続されているルータ３Ａ，３Ｂとの間でやりとりするプロトコルＡＳＲＰ（ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅｓ
Ｒｅｇｉｓｔｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を定義する。登録したいサービスがあるサーバ１（又は２）は、現在の自己からネットワークに繋がるルータ（ＡＳＲＰをサポートしているルータ）３Ａ（３Ｂ）との間にＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）コネクションを設定する。なお、ＡＳＲＰのＴＣＰポート番号
は周知（Ｗｅｌｌ−Ｋｎｏｗｎ）のポートでなければ何でもよいが、例えば、未使用（ｕｎｓｉｇｎｅｄ）のポート番号“４６３４”を使用する。

ＴＣＰコネクションを設定した後は、サーバ１（又は２）は、ＡＳＲＰで定義するコマンド（パケット）をルータ３Ａ（又は３Ｂ）に発行することでサービスの状態や種別等を通知する。ここで、ＡＳＲＰのコマンドパケットフォーマットは、例えば図２に示すように定義する。即ち、本コマンドパケット３０は、当該コマンドの種類を表すコマンドフィールド３１（２オクテット）と、当該コマンドフィールド３１に続くデータ長を示す長さ（ｌｅｎｇｔｈ）フィールド３２（２オクテット）と、コマンド種類に応じて必要なパラメータ等が格納された「コマンドデータ」フィールド３３（可変長）とを有して構成される。

ここで、コマンド（メッセージ）には、以下の７種類を定義する。
１．ＡＤＤ＿ＳＥＲＶＩＣＥ（ｃｏｍｍａｎｄ値：１）
自サーバ１，２が提供するサービス内容を通知するためのコマンドである。ｌｅｎｇｔｈ値は可変であり、コマンドデータ内容は図３に示すように定義する。この図３に示すように、ＡＤＤ＿ＳＥＲＶＩＣＥコマンドの場合、コマンドデータフィールド３３には、以下の各種パラメータが設定される。

（１）サービスタイプ（ｓｅｒｖｉｃｅ ｔｙｐｅ）（１オクテット）
サービスの種類を表す。ビット０のみ定義。例えば、ビット０が“０”ならサービス内容更新処理対象外、“１”ならサービス内容更新処理対象を表す。なお、サービス内容更
新処理とは、提供しているサービスの内容が更新された際、そのことを通知する処理であり、ルータ３Ａ，３Ｂにおけるサービスの稼動判別に用いられる。

（２）サーバタイブ（ｓｅｒｖｅｒ ｔｙｐｅ）（１オクテット）
例えば、“１”で自サーバが該当サービスのマスターであることを示し、“２”で自サーバがミラーであることを示す。
（３）サービス識別子長（２オクテット）
次のサービス識別子の長さを格納する。

（４）サービス識別子（可変長）
サーバ１（２）で行なっているサービスの種別を示す。サーバ１，２が提供しているサービス内容が一意に認識できる値を格納する。一例として、ＷＷＷサーバであれば、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｂａｒ／”といったＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とする。なお、「サービスタイプ」が「ミラー」であっても、マ
スターサーバ１で提供しているＵＲＬの内容を格納する。これにより、マスターサーバ１のサービスと同一であることが判別可能となる。

（５）ポート数（２オクテット）
そのサービスの提供しているポート番号の数（下記のポート１〜ポートｎの、ｎの値）を格納する。
（６）ポート番号１〜ｎ（各２オクテット）
そのサービスの提供しているポート番号を表す。一例として、ｈｔｔｐ（ｈｙｐｅｒ
ｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）であれば８０が格納される。
２．ＫＥＥＰＡＬＩＶＥ（ｃｏｍｍａｎｄ値：２）
自サーバ１（２）が稼動していることを通知するためのメッセージである。ｌｅｎｇｔｈ値は０とする（コマンドデータ内容はない）。
３．ＳＥＲＶＩＣＥ＿ＤＯＷＮ（ｃｏｍｍａｎｄ値：３）
自サーバ１（２）で提供している特定のサービスが何らかの原因でダウンした際に、それを通知するメッセージである。ｌｅｎｇｔｈ値は可変であり、コマンドデータの内容は例えば図４に示すように定義する。この図４における各種パラメータの内容は上記のＡＤＤ＿ＳＥＲＶＩＣＥコマンドの場合と同一である。
４．ＣＬＯＳＥ＿ＳＥＲＶＥＲ（ｃｏｍｍａｎｄ値：４）
サーバ１（２）自体がシャットダウン等でサービスの提供ができなくなる際に通知するメッセージである。ｌｅｎｇｔｈ値は０とする（コマンドデータ内容はない）。
５．ＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥ（ｃｏｍｍａｎｄ値：５）
サービス内容更新処理対象のサービスに対してのみ通知が行なわれるメッセージである。自サーバ１（２）で提供しているサービスの内容が更新された際に通知を行なう。ｌｅｎｇｔｈ値は０とする（コマンドデータ内容はない）。
６．ＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＱ（ｃｏｍｍａｎｄ値：６）
本メッセージのみルータ３Ａ（又は３Ｂ）からサーバ１（又は２）に対して送信される。マスターサーバ１の直接アクセス用アドレス（後述）の要求メッセージである。ｌｅｎｇｔｈ値は０とする（コマンドデータ内容はない）。
７．ＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＳＰ（ｃｏｍｍａｎｄ値：７）
上記ＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＱに対する応答であり、自己がマスターサーバ１である時は直接アクセス用アドレスを返すメッセージである。ｌｅｎｇｔｈ値は直接アクセス用アドレスの長さを格納し、コマンドデータ内容は、直接アクセス用アドレスの内容を格納する。

ここで、上記の「直接アクセス用アドレス」とは、ミラーサーバ２がマスターサーバ１に対して直接アクセスを行なえるようにするためのダミーアドレスであり、マスターサー
バ１を立ち上げる際に、サーバ１側で少なくとも１つ用意する。この「直接アクセス用アドレス」は、どのユーザ端末５，６でも使用していないアドレスである必要がある。ちなみに、直接アクセス用アドレスの指定においては、マスターサーバ１のアドレスにおけるサブネットと同一のサブネットをもたせるようにする。これは、マスターサーバ１のアドレス宛と直接アクセス用アドレス宛の双方が同一方向にルーティングされるようにする必要があるからである。

つまり、本実施形態のサーバ１，２は、少なくとも次のような機能を実装していることになる。
（１）ＡＤＤ＿ＳＥＲＶＩＣＥメッセージを生成して自己に接続されているルータ３に発行することにより、自サーバ１，２で提供するサービス内容に関する情報を当該ルータ３に通知するサービス通知部としての機能
（２）上記のＫＥＥＰＡＬＩＶＥ，ＳＥＲＶＩＣＥ＿ＤＯＷＮ，ＣＬＯＳＥ＿ＳＥＲＶＥＲメッセージを生成して同ルータ３に発行することにより、自サーバ１，２のサービス稼動状況をルータ３に通知するサービス稼動状況通知部としての機能
（３）サービス内容に更新があると、更新後のサービス内容に関する情報をＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥメッセージにより自サーバ１，２に接続されているルータ３に通知するサービス更新通知部としての機能
（４）自サーバ１以外に自サーバ１と同一のサービス内容を提供するミラーサーバ２が存在する場合において、ミラーサーバ２が、当該ミラーサーバ２で提供するサービス内容の更新を行なう際に、自サーバ１への直接アクセスを可能とする直接アクセス用アドレスをＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＳＰメッセージにより自サーバ１に接続されているルータ３に通知する直接アクセス用アドレス通知部としての機能
そして、サーバ１（２）のＡＳＲＰによる動作（ＴＣＰコネクションを設定した後）は以下の通りとなる。

（１）まず、自サーバ１（２）が提供しているサービス全てについて、ＡＤＤ＿ＳＥＲＶＩＣＥパケットをルータ３に送信する。
（２）その後は、定期的にＫＥＥＰＡＬＩＶＥメッセージを送信する。
（３）自サーバ１（２）において、あるサービスが停止したことを認識した場合は、ＳＥＲＶＩＣＥ＿ＤＯＷＮパケットを送信する。

（４）自サーバ１（２）がシャットダウン等で停止することを認識した場合は、ＣＬＯＳＥ＿ＳＥＲＶＥＲパケットを送信する。
（５）提供しているサービスがサービス内容更新処理の対象であり、且つ、該当サービスの内容を更新した際は、ＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥパケットを送信する。
（６）ルータ３側からＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＱメッセージを受信し、且つ、自サーバ１（２）が提供しているサービスにマスターサーバがあった場合、直接アクセス用アドレスをＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＳＰメッセージに格納して、ルータ３に送信する。

一方、ルータ３には、例えば図５に示すような登録サービステーブル２１を用意する。この図５中に示す各パラメータは、上述したＡＳＲＰのＡＤＤ＿ＳＥＲＶＩＣＥパケット中の内容と同一である。ここで、「サーバアドレス」とは、ＡＤＤ＿ＳＥＲＶＩＣＥを受信したパケットの送信元アドレスである。また、「サービス満了（ｅｘｐｉｒｅ）時間」には、サービス内容更新処理対象時、サービス対象から外れる時刻が格納される。対象外のエントリに関しては、本エリアには０が格納される。

次に、以下のフラグを定義する。
（１）サービス内容更新処理フラグ
ユーザが設定可能な値。サービス内容更新処理を行なう／行なわないの別を指定する（例えば、行なう場合は“１”、行なわない場合は“０”とする）。
（２）サービス内容満了（ｅｘｐｉｒｅ）時間
ユーザが設定可能な値。サービス内容が更新されてからサービス内容が「満了（ｅｘｐｉｒｅ）」と認識されるまでの時間を設定する。

そして、ルータ３は、サーバ１（２）からＡＤＤ＿ＳＥＲＶＩＣＥパケットを受信した場合は、登録サービステーブル２１にエントリを追加する。ただし、サービス識別子とサーバアドレスの双方が一致するエントリがあった場合は、その内容を更新する。ここで、ＡＤＤ＿ＳＥＲＶＩＣＥパケット内のサービス内容更新処理ビットが“１”であり、且つ、サービス内容更新処理実行フラグが“１”であった場合は、登録サービステーブル２１中の「サービス満了時間」に、現在の時刻からサービス内容満了時間を加算した時刻を設定する。それ以外の場合は「サービス内容満了時間」を“０”に設定する。

次に、ＡＤＤ＿ＳＥＲＶＩＣＥパケット中の「サーバタイプ」が「マスター」であった場合は、送信元のサーバ１（２）に対してＤＩＲＥＣＴ＿ＡＤＤ＿ＲＥＱメッセージを送信し、当該ＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＳＰメッセージに対する返答（ＤＩＲＥＣＴ＿ＡＤＤＲ＿ＲＥＳＰメッセージ）を待ち、返答を受信したら、当該受信メッセージ内に設定されている「直接アクセス用アドレス」を、現在追加している登録サービステーブル２１（図５参照）中のエントリにある「直接アクセス用アドレス」フィールドに格納する。

その後、ルータ３（４）は、コネクションを設定したサーバ全てに対して、ＫＥＥＰＡＬＩＶＥパケットの到着チェックを行なう。ＫＥＥＰＡＬＩＶＥパケットが一定時間受信できなくなった場合は、そのサーバのアドレス値をサーバアドレス値にもつ、登録サービステーブル２１内の全エントリを削除する。なお、サーバ１（２）からＣＬＯＳＥ＿ＳＥＲＶＥＲパケットを受信した場合は、ＫＥＥＰＡＬＩＶＥパケットが一定時間受信できなくなった場合と同一の処理を行なう。

また、サーバ１（２）からＳＥＲＶＩＣＥ＿ＤＯＷＮパケットを受信した場合は、当該ＳＥＲＶＩＣＥ＿ＤＯＷＮパケット中の「サービス識別子」と同じ「サービス識別子」をもち、且つ、「サーバアドレス」が受信したＳＥＲＶＩＣＥ＿ＤＯＷＮパケットの送信元アドレスと同一である、登録サービステーブル２１中のエントリを削除する。
なお、サービス内容更新処理実行フラグが“１”の時は、以下の処理を追加で行なう。即ち、サーバ１（２）からＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥパケットを受信した場合は、当該ＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥパケット中の「サービス識別子」と同一の「サービス識別子」をもち、且つ、「サーバアドレス」がＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥパケットの送信元アドレスと同一である、登録サービステーブル２１中のエントリを検索し、そのエントリ中にあるサービスｅｘｐｉｒｅ時間を、現在の時刻からサービス内容満了時間を加算した時刻に変更する。そして、登録サービステーブル２１の全エントリを検索し、サービス満了時間が設定されており、且つ、その時刻が現在時刻よりも過去の時刻であるエントリを削除する。

以上により、あるルータ３に接続しているサーバ１（２）に関するサービス内容は、ルータ３の登録サービステーブル２１に全て登録されることになり、また、サービスの稼動状況に応じてその内容が適宜更新されることになる。
〔Ｂ〕ルータ間でのサービス情報のやりとり
次に、ルータ３間でのサービス情報のやりとりを行なう方式について説明する。

ルータ３間では、通常、宛先決定（経路制御）のためのルーティングプロトコルをやりとりしている。本実施形態では、インターネットでも使用されているルーティングプロト
コルであるＢＧＰ４（ＢｏｒｄｅｒＧａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ４）を拡張して、上述したＡＳＲＰによって得られた各サーバ１，２のサービス情報を付加する。

即ち、ＢＧＰ４では、ルータ３間で通知する、ルーティング情報（経路情報）の経路毎に、その経路に対する特徴を表す「パス属性」を記述することができるため、そのパス属性にＡＳＲＰで得られたサービス情報を追加記載することで、サービス情報の交換を行なう。これにより、ネットワーク上の各ルータ３にサーバ１，２で提供するサービス情報が伝達されて各ルータ３で共有されることになる。

図６に、ＢＧＰ４で経路情報を通知する際に使用する更新（ＵＰＤＡＴＥ）メッセージのフォーマット例を示す。この図６に示すように、ＵＰＤＡＴＥメッセージには、利用不能経路長フィールド４１（２オクテット），取消経路フィールド４２（可変長），パス属性長フィールド４３（２オクテット），パス属性フィールド４４（可変長）及びネットワーク層到達可能性情報フィールド４５がある。

そして、利用不能経路長フィールド４１には取消経路フィールド４２のフィールド長が格納され、取消経路フィールド４２には利用不能となった経路情報が格納され、パス属性長フィールド４３にはパス属性フィールド４４のフィールド長が格納され、パス属性フィールド４４には経路の特徴を表す情報（本実施形態では、当該フィールドにサービス情報を付加する）が格納され、ネットワーク層到達可能情報フィールド４５には、利用可能な経路情報が格納されるようになっている。

また、図７に、この図６におけるパス属性フィールド４４のフォーマット例を示す。この図７に示すように、パス属性フィールド４４は、属性フラグフィールド４４１（１オクテット），属性タイプコードフィールド４４２（１オクテット），属性長フィールド４４３（１又は２オクテット），属性値フィールド４４４（可変長）から成る。なお、この図７において、サービス情報の内容は、属性値フィールド４４４にそれぞれ格納されることとなる（内容詳細は後述）。その他のフィールドは以下のように定義する。

（１）属性フラグフィールド４４１
ビット毎に意味がある。それぞれの内容とサービス情報の属性を記述する際の設定値は以下のように定義する。
（ａ）ビット０：オプショナルビット
“０”はｗｅｌｌ−ｋｎｏｗｎを示し、ＢＧＰ４をサポートする全ルータ３が理解できなければならない属性を示す。“１”ならオプショナルを示し、全ルータ３が知っているとは限らない属性を示す。サービス情報の内容は追加で定義するものなので、本ビット“１”とする。

（ｂ）ビット１：通過ビット
“０”は非通過を示し、この属性をサポートしていないルータ３において、本属性を削除することを示す。“１”は通過を示し、この属性をサポートしていないルータ３は、本属性を通過、伝搬させることを示す。サービス情報は、全ルータ３に渡らなければならないため、本ビットは“１”とする。

（ｃ）ビット２：通過ビット
ルータ３が本属性を理解できずに通過させた時、“１”を設定するビット。
（ｄ）ビット３（属性長フィールドの長さ）：“０”ならば、「属性長」フィールドが１オクテット長であることを示す。“１”ならば「属性長」フィールドが２オクテット長であることを示す。本フィールドは属性の値の長さに応じて決定する。

（ｅ）ビット４〜７（未使用）：常に“０”とする。
（２）属性タイプコードフィールド４４２
属性の種別を示す。ＢＧＰ４ではｗｅｌｌ−ｋｎｏｗｎ，オプショナル双方で１〜１０，１４〜１６が定義されている。サービス情報の属性を記述するためには、いくつかの追加属性が必要であるが、既に定義されている値以外で一意にタイプコードを設定する。詳細については後述する。

ここで、ＢＧＰ４のＵＰＤＡＴＥメッセージで通知される経路情報は、ＡＳ（ＡｕｔｏｎｏｍｏｕｓＳｙｓｔｅｍ）単位で集約されたメッセージが基本である。その集約されたネットワーク上には、各種サービスを提供するサーバが複数あることも当然考えられる。集約経路毎に複数のサービスがある場合は、その経路に対するＵＰＤＡＴＥメッセージを複数回投げることで、全てのサービス情報を通知する。

また、ＡＳＲＰによって登録サービステーブルが更新された時は、必ずそのサービス更新内容を含んだＵＰＤＡＴＥメッセージをピアのルータ３に通知する。これにより、ピアのルータ３に当該サービス更新内容が反映されて、ネットワーク上の各ルータ３が保有するサービス情報の更新（同期）が可能となる。
次に、或る１つのサービス情報を通知する際に必要となる、追加属性の属性タイプコード，属性値を以下の表１に示すように定義する。ここで、各属性における属性タイプコード値を定義しているが、定義した値はこの限りではなく、全体で一意に決定されていればよい。

サービス情報を通知する際は、上記３種の属性を必ず設定し、ピアのルータ３に通知する。これによって、各サービス情報が、本拡張を理解できる全ルータ３に対して認識されることになる。
〔Ｃ〕サービス情報に基づくサービス毎の最適経路の決定・更新方式
次に、上述したメッセージによって得られたサービス情報から、ルータ３において、サービス毎に最適経路を決定，更新する方式について説明する。

ここで、ルータ３に通知されてきた全サービス情報の最適経路情報を保持するため、ルータ３には、図１１に示すような宛先サーバ選択テーブル２２を用意する。ルータ３に得られたサービス情報は、全てこの宛先サーバ選択テーブル２２にまとめられ、この情報を基にサービスの負荷分散処理を行なう。なお、この宛先サーバ選択テーブル２２の各フィールドの内容は以下の通りである。

（１）サービス識別子長／サービス識別子
登録サービステーブル２１（図５参照）の「サービス識別子長」，「サービス識別子」に相当する情報である。
（２）マスターアドレス：登録サービステーブル２１の「サーバアドレス」に相当する情報である。

（３）直接アクセス用アドレス
マスターサーバ１に対する「直接アクセス用アドレス」に相当する情報である。
（４）最適アドレス
登録サービステーブル２１の「サーバアドレス」に相当する情報である。ただし、それぞれのサービスにおいて、自ルータ３における最適な宛先アドレスが指定される。

（５）ポート数（マスター）／ポート数１〜ｎ（マスター）
登録サービステーブル２１の「ポート数」，「ポート番号１」〜「ポート番号ｎ」に相当する情報である。ただし、それぞれのサービスにおけるマスターサーバ１のポート情報が指定される。
（６）ポート数（最適）／ポート数１〜ｎ（最適）
登録サービステーブル２１の「ポート数」，「ポート番号１〜ｎ」に相当する情報である。ただし、それぞれのサービスにおける最適な宛先アドレスにおけるポート情報が指定される。

（７）マスター満了（ｅｘｐｉｒｅ）時刻
サービスを提供するマスターサーバ１が停止したことを認識した際の、サービス満了（ｅｘｐｉｒｅ）時刻が設定される。マスターサーバ１が停止していなければ本領域は０とする。なお、本領域の詳細については後述する。
そして、各ルータ３では、ピアのルータからＵＰＤＡＴＥメッセージが送信された時、もしくは、自ルータ３の登録サービステーブル内容が更新された時、宛先サーバ選択テーブル２２の内容を更新（サービスを追加／更新）する。

即ち、例えば図１５に示すように、ルータ３は、登録サービステーブル２１の内容に追加があった時、もしくは、ピアのルータ３からＵＰＤＡＴＥメッセージを受信し、その中のＡＰＰ＿ＡＴＴＲ＿ＡＤＤＲ属性値のｔｙｐｅ情報が「ｕｐｄａｔｅ」であった時（これらの情報を、以後、更新データと称する）、更新データのサービス識別子が宛先サーバ選択テーブル２２に存在するかどうか検索する（ステップＡ１）。

存在する場合（ステップＡ１でＹｅｓの場合）は、一致したエントリ（宛先サーバ選択テーブル２２内のエントリ）をＥ＿ｔとし（ステップＡ２）、当該エントリＥ＿ｔ内の最適アドレスと自ルータ３との距離（ホップ数：宛先までの距離）を、ルーティングテーブルから獲得する（Ｅ＿ｈｏｐとする）（ステップＡ３）。
そして、上記の検索で該当した宛先サーバ選択テーブル２２のエントリＥ＿ｔ内のサーバアドレス（Ｕ＿ａｄｄｒ）と自ルータ３との距離（ホップ数）をルーティングテーブルから獲得し（Ｕ＿ｈｏｐとする）（ステップＡ４）、獲得した２つのホップ数Ｅ＿ｈｏｐ，Ｕ＿ｈｏｐを比較する（ステップＡ５）。

その結果、更新データのアドレスに対するホップ数Ｕ＿ｈｏｐの方が小さければ（ステップＡ５でＹｅｓの場合）、該当する宛先サーバ選択テーブル２２のエントリＥ＿ｔ内の最適アドレス，ポート数（最適），ポート数１〜ｎ（最適）の情報を、更新データに入っている情報〔最適アドレス＝Ｕ＿ａｄｄｒ，ポート数（最適）＝Ｕ＿ｐｏｒｔ，ポート番号１〜ｎ＝Ｕ＿ｐ１〜Ｕ＿ｐｎ〕に書き換える（ステップＡ６）。なお、ホップ数Ｅ＿ｈｏｐの大きい場合（ステップＡ５でＮｏの場合）は、かかる書き換えは行なわずに既存の登録内容を維持する。

次に、更新データにある「サーバタイプ（ｓｅｒｖｅｒ ｔｙｐｅ）」が「マスター」
であるかをチェックし（ステップＡ７）、「マスター」である場合は、該当する宛先サーバ選択テーブル２２中のエントリＥ＿ｔにあるマスターアドレス，直接アクセス用アドレス，ポート数（マスター），ポート数１〜ｎ（マスター）の内容を、更新データの内容〔マスターアドレス＝Ｕ＿ａｄｄｒ，直接アクセス用アドレス＝Ｕ＿ｄａｄｄｒ，ポート数（マスター）＝Ｕ＿ｐｏｒｔ，ポート番号１〜ｎ（マスター）＝Ｕ＿ｐ１〜Ｕｐｎ〕にそれぞれ書き換える（ステップＡ８）。なお、「サーバタイプ（ｓｅｒｖｅｒｔｙｐｅ）」が「マスター」でない（「ミラー」）であった場合（ステップＡ７でＮｏの場合）は、かかる書き換えは行なわず、既存の登録内容が維持される。

一方、更新データの「サービス識別子」が宛先サーバ選択テーブル２２になかった場合（ステップＡ１でＮｏの場合）は、ＢＧＰテーブル及び登録サービステーブル２１から、更新データに入っている「サービス識別子」と同一の「サービス識別子」をもつエントリを全て検索し、それらのエントリ中で、「サーバタイプ」が「マスター」であるエントリを検索する（ステップＡ９，Ａ１０）。なお、「ＢＧＰテーブル」とは、ＢＧＰ４にてピアのルータ３から受け取った経路情報（表１で追加した属性内容も含む）を全て格納したテーブルである。

その結果、該当するエントリがあれば（ステップＡ１０でＹｅｓであれば）、宛先サーバ選択テーブル２２のエントリを１つ追加し、サービス識別子長，サービス識別子，マスターアドレス，直接アクセス用アドレス，ポート数（マスター），ポート数１〜ｎ（マスター）の内容を検索したエントリの内容に設定する（ステップＡ１１）。該当エントリがない場合（ステップＡ１０でＮｏの場合）は処理を終了する。

その後、ルータ３は、追加エントリのマスター満了時刻を“０”に設定し（ステップＡ１２）、検索した全エントリのサーバアドレスにおいて、自ルータ３との距離（ホップ数）をルーティングテーブルから獲得する（ステップＡ１３）。そして、獲得したホップ数の中で最小のエントリを検索し、先ほど追加した宛先サーバ選択テーブル２２中のエントリ内にある最適アドレス，ポート数（最適），ポート数１〜ｎ（最適）の内容を、ホップ数最小のエントリ内容に設定する（ステップＡ１４）。

これに対し、登録サービステーブル２１の内容が削除された時、もしくは、ピアのルータ３から更新（ＵＰＤＡＴＥ）メッセージを受信し、その中のＡＰＰ＿ＡＴＴＲ＿ＡＤＤＲ属性値のタイプ情報が「削除（ｄｅｌｅｔｅ）」であった時（これらの情報を、以後、「削除データ」と称する）は、次のようなサービスの削除処理が行なわれる。なお、削除されたサービスのサービス識別子，サーバアドレス，サービスタイプをそれぞれＤ＿ｓｉｄ，Ｄ＿ａｄｄｒ，Ｄ＿ｓｔｙｐｅとする。

即ち、例えば図１６に示すように、宛先サーバ選択テーブル２２のエントリを検索して、削除データのサービス識別子（Ｄ＿ｓｉｄ）に一致するエントリ（Ｄ＿ｔ）が宛先サーバ選択テーブル２２に存在するかどうかをチェックし（ステップＢ１）、なければ処理を
終了し（ステップＢ１のＮｏルート）、エントリＤ＿ｔがあれば（ステップＢ１のＹｅｓルートからステップＢ２）、削除データのサーバタイプが「マスター」であるか否かをチェックする（ステップＢ３）。

その結果、削除データのサーバタイプが「マスター」である場合は、宛先サーバ選択テーブル２２のエントリＤ＿ｔを削除した上で（ステップＢ３のＹｅｓルートからステップＢ４）、削除データが登録サービステーブル２１の内容かどうかを確認する（ステップＢ５）。登録サービステーブル２１の内容でない場合は処理を終了するが（ステップＢ５のＮｏルート）、登録サービステーブル２１の内容であった場合（削除データがピアのルータ３からのＵＰＤＡＴＥメッセージであった場合）は、該当サービスの再追加を行なう。

即ち、ＢＧＰテーブル及び登録サービステーブル２１において、削除データのサービス識別子Ｄ＿ｓｉｄと同じサービス識別子をもつエントリを全て検索し（ステップＢ５のＮｏルートからステップＢ６）、検索したエントリの中に、「サーバタイプ」が「マスター」のエントリが存在するかをチェックする（ステップＢ７）。
その結果、「マスター」のエントリが存在しない場合は処理を終了するが（ステップＢ７のＮｏルート）、存在する場合は、宛先サーバ選択テーブル２２にエントリを１つ追加（エントリＡ＿ｔとする）し、検索したマスターサーバのエントリ内容〔サービス識別子長，サービス識別子，マスターアドレス，直接アクセス用アドレス，ポート数（マスター），ポート番号１〜ｎ（マスター）〕を設定する（ステップＢ７のＹｅｓルートからステップＢ８）。

そして、現在の時刻からマスター満了時刻を足した時刻をエントリＡ＿ｔ内のマスター満了時刻に設定し（ステップＢ９）、検索した全エントリのサーバアドレスにおいて、自ルータ３との距離（ホップ数）をルーティングテーブルから獲得し（ステップＢ１０）、獲得したホップ数が最小のエントリ内容〔最適アドレス，ポート数（最適），ポート番号１〜ｎ（最適）〕を、エントリＡ＿ｔに設定する（ステップＢ１１）。

一方、上記のステップＢ３において、削除データのサーバタイプが「マスター」でなかった場合は、サーバアドレスＤ＿ａｄｄｒが、エントリＤ＿ｔ内の最適アドレスと一致するか否かをチェックし（ステップＢ３のＮｏルートからステップＢ１２）、一致しなければ処理を終了するが（ステップＢ１２のＮｏルート）、一致する場合は以下の処理を行なう。

即ち、ＢＧＰテーブル及び登録サービステーブル２１において、削除データのサービス識別子Ｄ＿ｓｉｄと同一のサービス識別子をもつエントリを全て検索し（ステップＢ１２のＹｅｓルートからステップＢ１３）、検索した全エントリのサーバアドレスに対し、ルーティングテーブルからそれぞれ自ルータ３との距離（ホップ数）を獲得し（ステップＢ１４）、獲得したホップ数の中で最小のエントリを検索し、エントリＤ＿ｔ内の最適アドレス，ポート数（最適），ポート数１〜ｎ（最適）の内容を、ホップ数最小のエントリ内容に変更する（ステップＢ１５）。

つまり、上記の更新方式は、ピアのルータ３がダウンしたことを認識した際（ＢＧＰ４では、ピアのルータ３間でＫＥＥＰＡＬＩＶＥメッセージをやりとりすることで生死確認を行なっている。ＫＥＥＰＡＬＩＶＥメッセージが受信されなくなったらピアのルータ３がダウンしたことを識別する）、ＢＰＧテーブルから該当ルータ３からの情報を除外し、除外した状態で、再度、ルーティングテーブルを構築するが、その際、削除されたＢＧＰテーブル中で、ＡＰＰ＿ＡＴＴＲ＿ＡＤＤＲ属性をもつエントリが削除されたとみなし、上記フローの削除処理を行なうのである。これにより、たとえルータ３が停止（ダウン）してしまった場合でも、そのルータ３が停止した時のネットワーク状況（ネットワークト
ポロジの変化）に応じて、最適な宛先を選択することが可能となる。

次に、「マスター満了時刻」に関する処理について記述する。「マスター満了」とは、サービスのマスターサーバ１がサービス停止（満了）した時に、ミラーサーバ２も停止（ｅｘｐｉｒｅ）させるための処理である。マスターサーバ１が一時的な停止であった場合は、ミラーサーバ２で処理を継続させる必要があるが、マスターサーバ１のサービスが長期にわたって停止したり、恒久的にサービス停止をしたりした場合は、ミラーサーバ２に関してもサービスを停止させる必要性があることから、ｅｘｐｉｒｅ時刻を設けている。

即ち、ルータ３は、マスターサーバ１のサービスが停止してから、マスター満了までの時間を「マスター満了時間」としてもち、以下の処理を行なう。なお、「マスター満了時間」は、ユーザから自由に設定できるようにする。
まず、ルータ３は、宛先サーバ選択テーブル２２の全エントリにおけるマスター満了時刻をチェックし、“０”でない場合、現在時刻とマスター満了時刻とを比較し、マスター満了時刻の方が古い時刻であった場合は、該当エントリを削除する。これにより、マスター満了時間によるサービス停止処理が行なえることとなる。

〔Ｄ〕ルータの実施例
次に、上述した処理を実現するルータ３の実施例を図１７に示す。なお、この図１７には、本実施形態の要部を示しており、ルータ全体の構成を示してはいない。この図１７に示すように、本実施形態のルータ３は、それぞれ、パケット識別部１０，テーブル設定部１１，ミラーサーバアクセス用アドレス変換部１２，最適宛先決定部（負荷分散処理部）１３，マスターサーバ宛アドレス変換部１４，ルーティング処理部１５，ＡＳＲＰ処理部１６及びＢＧＰ４処理部１７等をそなえて構成されている。ただし、ＡＳＲＰ処理部１６は、少なくとも、サーバ１，２に接続されているルータ３Ａ，３Ｂに実装されていればよく、他のルータ３については必ずしも必要ない。

ここで、パケット識別部１０は、受信パケットの種別〔ＡＳＲＰパケット，ＢＧＰ４の制御パケット（ＵＰＤＡＴＥメッセージ等），ユーザパケット（サービスアクセス要求等）〕を識別する機能を有するもので、ＡＳＲＰパケットはＡＳＲＰ処理部１７へ、ＢＧＰ４の制御パケットはＢＧＰ４処理部１６へ、サービスアクセス要求等のユーザパケットは、ミラーサーバアクセス用アドレス変換部１２へそれぞれ振り分けられるようになっている。

ＢＧＰ４処理部１６は、上述したルータ３間のＢＧＰ４等のルーティングプロトコルによるメッセージの送受を処理するもので、前述したように「属性タイプコード」を拡張したメッセージの送受を行なうようになっている。また、ＡＳＲＰ処理部１７は、自ルータ３に接続されているサーバ１，２との間での前記ＡＳＲＰメッセージの送受を処理するものである。

テーブル設定部１１は、ＡＳＲＰ処理部１７及びＢＧＰ４処理部１６で得られるサービス情報を基に、上述した登録サービステーブル２１，宛先サーバ選択テーブル２２，ＢＧＰ４テーブルの内容、および、それぞれ後述するミラーサーバアクセス用アドレス変換部１２におけるマスターサーバ宛変更テーブル２３（図１２参照），最適宛先決定部１３における宛先変更テーブル２４（図１３参照），マスターサーバ宛アドレス変換部１４におけるマスターサーバ復旧テーブル２５の内容を設定・管理するもので、登録サービステーブル２１，宛先サーバ選択テーブル２２の更新に伴って、ミラーサーバアクセス用アドレス変換部１２，最適宛先決定部（負荷分散処理部）１３，マスターサーバ宛アドレス変換部１４に対する必要なエントリ追加／削除の指令を発するようになっている。なお、上記の各種テーブルは、それぞれ、ＲＡＭ等の所要の記録媒体に記録される。

つまり、上記のテーブル設定部１１，ＢＧＰ４処理部１６及びＡＳＲＰ処理部１７は、自己と接続されているサーバ１，２又は他ルータ３からサーバ１，２で提供するサービス内容に関する情報を受信して、当該サービス情報の登録及び更新を管理するサービス情報管理部１８としての機能を果たしており、ＢＧＰ４処理部１６は、このサービス情報管理部１８でのサービス情報の登録・更新に伴って、サービス情報をルータ３間の経路制御に用いられるルーティングプロトコルを用いてさらに他ルータ３へ伝達するサービス情報伝達部としての機能を果たしていることになる。

そして、テーブル設定部１１は、さらに、次のような機能（括弧書きで示す部分により主としてその機能が実現されていることを示す）を有していることになる。
（１）サーバ１，２の提供するサービス種別を示すサービス識別子（ＵＲＬ）を含むサービス情報を保持・管理する機能（テーブル設定部１１）
（２）サーバ１，２からＡＳＲＰによるＫＥＥＰＡＬＩＶＥパケットやＳＥＲＶＩＣＥ＿ＤＯＷＮパケット，ＣＬＯＳＥ＿ＳＥＲＶＥＲパケット等により通知される当該サーバのサービス稼動状況に応じてサービス情報を更新する機能（ＡＳＲＰ処理部１７，テーブル設定部１１）
（３）サーバ１，２から当該サーバ１，２の提供するサービス内容が更新される毎に通知されるＡＳＲＰによるＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥパケット（サービス更新メッセージ）を一定期間受信しないときは当該サービス内容についてのサービス情報の登録を削除する機能（ＡＳＲＰ処理部１７，テーブル設定部１１）
（４）ＡＳＲＰによるＳＥＲＶＩＣＥ＿ＵＰＤＡＴＥパケットを一定期間受信しない場合でも非更新対象のサービス内容についてのサービス情報の登録は維持する機能（ＡＳＲＰ処理部１７，テーブル設定部１１）
（５）マスターサーバ１がＡＳＲＰにより定期的に発行するＫＥＥＰＡＬＩＶＥパケット（サービス稼動状況通知メッセージ）によりマスターサーバ１が一定期間稼動停止しているか否かを判断する機能（ＡＳＲＰ処理部１７）
（６）当該機能によりマスターサーバ１が稼動停止していると判断すると、テーブル設定部１１におけるミラーサーバ２についてのサービス情報の登録を削除する機能（テーブル設定部１１）
（７）他ルータ３からＢＧＰ４により定期的に受信されるべきＫＥＥＰＡＬＩＶＥメッセージ（生死確認情報）の受信を監視することにより当該他ルータ３の稼動状況を監視する機能（ＢＧＰ４処理部１６）
（８）当該ＢＧＰ４のＫＥＥＰＡＬＩＶＥメッセージの監視により他ルータ３の稼動停止が確認されると、テーブル設定部１１において自己が保有するサービス情報のうち当該稼動停止した他ルータ３についてのサービス情報を削除する機能（テーブル設定部１１）
（９）マスターサーバ１へミラーサーバ２が自己の提供するサービス内容の更新を行なう際に該マスターサーバへの直接アクセスを可能とする直接アクセス用アドレスを要求する機能（ＡＳＲＰ処理部１７）
（１０）当該要求に対してマスターサーバ１から受信される直接アクセス用アドレスをサービス情報に含めて他ルータ３に伝達する機能（ＢＧＰ４処理部１６）
次に、ミラーサーバアクセス用アドレス変換部１２，最適宛先決定部１３，マスターサーバ宛アドレス変換部１４及びルーティング処理部１５は、上述したサービス情報管理部１８でのサービス情報（宛先サーバ選択テーブル２２，下記のマスターサーバ宛変更テーブル２３及び宛先変更テーブル２４）に基づいてサービスアクセス要求の宛先情報（アドレス）をサービス内容（サービス識別子）単位で選択的に変更して最適な宛先へルーティングするルーティング制御部１９としての機能を実現するものである。

具体的には、ミラーサーバアクセス用アドレス変換部１２は、ミラーサーバ２がサービス内容の更新処理を行なう際、マスターサーバ１に対して行なう通信を最適宛先の決定対
象から除外する（マスターサーバ１への直接アクセスを可能にする）ための機能を有するもので、ここでは、例えば図１２に示すようなマスターサーバ宛変更テーブル２３を有している。

このマスターサーバ宛変更テーブル２３には、送信元アドレス，送信先アドレス及び変更アドレスの組がエントリして登録されるようになっており、本アドレス変換部１２は、入力フレームの送信元アドレスと送信先アドレスとを取り出し、当該テーブル２３の送信元アドレス及び送信先アドレスの双方が一致するエントリを検索し、双方が一致するエントリが存在する場合に、当該入力フレームの送信先アドレスを、そのエントリの変更アドレス（具体的には、「直接アクセス用アドレス」）に変換するようになっている。

そして、このマスターサーバ宛変更テーブル２３のエントリの追加／削除処理は、テーブル設定部１１により次のようにして行なわれる。即ち、登録サービステーブル２１にエントリが追加された場合は、テーブル設定部１１は、図１８に示すように、追加エントリのサービス識別子をＡ１２＿ｓｉｄ、サーバタイプをＡ１２＿ｓｔｙｐｅ、サーバアドレスＡ１２＿ｓａｄｄｒとして（ステップＣ１）、まず、追加エントリの「サーバタイプ（Ａ１２＿ｓｔｙｐｅ）」が「マスター」であるか否かをチェックする（ステップＣ２）。

「サーバタイプ」が「マスター」である場合、テーブル設定部１１は、何もせずに処理を終了するが（ステップＣ２のＹｅｓルート）、「ミラー」である場合は、宛先サーバ選択テーブル２２から、追加エントリと同一のサービス識別子Ａ１２＿ｓｉｄをもつエントリを検索し（ステップＣ２のＮｏルートからステップＣ３）、そのエントリ中の「マスターアドレス（Ｓ１２＿ｍａｄｄｒ）」と「直接アクセス用アドレス（Ｓ１２＿ｄａｄｄｒ）」とを獲得する（ステップＣ４）。

そして、マスターサーバ宛変更テーブル２３にエントリを１つ追加し、当該エントリに、追加エントリのサーバアドレス（Ａ１２＿ｓａｄｄｒ），獲得したマスターアドレス（Ｓ１２＿ｍａｄｄｒ），獲得した直接アクセス用アドレス（Ｓ１２＿ｄａｄｄｒ）を、順に、マスターサーバ宛変更テーブル２３の送信元アドレス，送信先アドレス，変更アドレスに設定する（ステップＣ５）。

これに対し、登録サービステーブル２１からエントリが削除された場合、テーブル設定部１１は、図１９に示すように、削除されたエントリのサービス識別子をＤ１２＿ｓｉｄ、サーバタイプをＤ１２＿ｓｔｙｐｅ、サーバアドレスをＤ１２＿ｓａｄｄｒとして（ステップＤ１）、まず、削除エントリの「サーバタイプ」が「マスター」であるかどうかをチェックする（ステップＤ２）。

その結果、削除エントリの「サーバタイプ」が「マスター」であれば、テーブル設定部１１は、何もせずに処理を終了するが（ステップＤ２のＹｅｓルート）、削除エントリの「サーバタイプ」が「ミラー」である場合、宛先サーバ選択テーブル２３から、削除エントリと同一のサービス識別子（Ｄ１２＿ｓｉｄ）をもつエントリを検索し（ステップＤ２のＮｏルートからステップＤ３）、そのエントリ中の「マスターアドレス（Ｓ１２＿ｍａｄｄｒ）」と「直接アクセス用アドレス（Ｓ１２＿ｄａｄｄｒ）」とを獲得する（ステップＤ４）。

そして、テーブル設定部１１は、マスターサーバ宛変更テーブル２３において、送信元アドレスがＤ１２＿ｓａｄｄｒ、送信先アドレスがＳ１２＿ｍａｄｄｒ、変更アドレスがＳ１２＿ｄａｄｄｒとなっているエントリを検索し、そのエントリを削除する（ステップＤ５）。
以上の処理によって、ミラーサーバ２からマスターサーバ１宛のフレームのみ、宛先ア
ドレスが「直接アクセス用アドレス」に変換されることとなる。

次に、最適宛先決定部１３は、上述のサービス情報を基に、入力フレームが該当サービス宛であった場合、最適な宛先に変更するためのもので、このために、例えば図１３に示すような宛先変更テーブル２４を有している。
この宛先変更テーブル２４には、アドレス（マスター），ポート（マスター），アドレス（最適）およびポート（最適）の組がエントリとして登録されるようになっており、最適宛先決定部１３は、ミラーサーバアクセス用アドレス変換部１２からの入力フレームの送信先アドレス及び送信先ポート番号を抽出し、それぞれをアドレス（マスター）及びポート（マスター）とみなして、同一内容をもつエントリがあるかどうかをこの宛先変更テーブル２４において検索し、エントリがあった場合は、入力フレームの送信先アドレス及び送信先ポート番号をそれぞれ宛先変更テーブル２４のアドレス（最適）及びポート（最適）の内容に変更して出力する。

これにより、マスターサーバ１宛で、かつ、該当サービスに対するアクセスについてのみ、最適な宛先に変更されることとなる。なお、宛先の変更情報（どこからきたフレームは、どの宛先に変更しているか）の保持や、宛先変更テーブルが変化した後でも通信（コネクション）の持続性（ｐｅｒｓｉｓｔｅｎｔ）を保つ方式に関しては、公知の負荷分散装置が実現している方式を適用すればよい。

具体的に、テーブル設定部１１による上記宛先変更テーブル２４に対するエントリの追加／削除は次のようにして行なわれる。
即ち、宛先サーバ選択テーブル２２にエントリが追加された場合、テーブル設定部１１は、図２０に示すように、当該追加エントリのマスターアドレスをＡ１３＿ｍａｄｄｒ、最適アドレスをＡ１３＿ｓａｄｄｒ、ポート数（マスター）をＡ１３＿ｐｏｒｔ、ポート番号１〜ｎ（マスター）をＡ１３＿ｍｐ１〜Ａ１３＿ｍｐｎ、ポート番号１〜ｎ（最適）をＡ１３＿ｓｐ１〜Ａ１３＿ｓｐｎとして（ステップＥ１）、宛先変更テーブル２４にエントリを１つ追加して、当該追加エントリのアドレス（マスター）としてＡ１３＿ｍａｄｄｒ、ポート（マスター）としてＡ１３＿ｍｐｋ（ただし、ｋ＝１〜Ａ１３＿ｐｏｒｔ）、アドレス（最適）としてＡ１３＿ｓａｄｄｒ、ポート（最適）としてＡ１３＿ｓｐｋをそれぞれ設定する。なお、宛先サーバ選択テーブル２２に追加されたエントリのポート数Ａ１３＿ｐｏｒｔが複数（ｎ個）ある時は、上記の処理が全てのポートについて順に行なわれて、ｎ個のエントリが追加されることになる（ステップＥ２）。

これに対し、宛先サーバ選択テーブル２２からエントリが削除された場合、テーブル設定部１１は、図２１に示すように、まず、削除されたエントリのマスターアドレスをＤ１３＿ｍａｄｄｒ、最適アドレスをＤ１３＿ｓａｄｄｒ、ポート数（マスター）をＤ１３＿ｐｏｒｔ、ポート番号１〜ｎ（マスター）をＤ１３＿ｍｐ１〜Ｄ１３＿ｍｐｎ、ポート番号１〜ｎ（最適）をＤ１３＿ｓｐ１〜Ｄ１３＿ｓｐｎとして（ステップＦ１）、宛先変更テーブル２４を検索して、同一内容をもつ宛先変更テーブル２４中のエントリを削除する（ステップＦ２）。なお、削除処理の場合も、削除エントリのポート数が複数（ｎ個）ある時は、上記の処理が全てのポートについて順に行なわれて、ｎ個のエントリが削除されることになる。

次に、マスターサーバ宛アドレス変換部１４は、入力フレームがマスターサーバ１の「直接アクセス用アドレス」であった場合に、マスターアドレスに変更する機能を有するもので、ここでは、例えば図１４に示すようなマスターサーバ宛復旧テーブル２５をそなえている。
このマスターサーバ宛復旧テーブル２５には、直接アクセス用アドレスと変更アドレスとの組がエントリとして登録されるようになっており、マスターサーバ宛アドレス変換部
１４は、最適宛先決定部１３からの入力フレームの送信先アドレスを抽出し、その内容をマスターサーバ宛復旧テーブル２５中の「直接アクセス用アドレス」とみなし、同一のアドレスをもつエントリを検索し、エントリが存在する場合は、入力フレームの送信先アドレスをテーブル２５中の対応する変更アドレスに変更して出力するようになっている。これにより、マスターサーバ１宛に直接送るフレーム（直接アクセス用アドレスをもっているフレーム）は、実際のマスターサーバ宛フレームに変更されることとなる。

このマスターサーバ宛復旧テーブル２５に対するエントリの追加／削除は、テーブル設定部１１によって次のようにして行なわれる。即ち、登録サービステーブル２１にエントリが追加された場合、テーブル設定部１１は、図２２に示すように、追加されたエントリのサーバタイプをＡ１４＿ｓｔｙｐｅ、サーバアドレスをＡ１４＿ｓａｄｄｒ、直接アクセス用アドレスをＡ１４＿ｄａｄｄｒとして（ステップＧ１）、まず、当該追加エントリのサーバタイプが「ミラー」かどうかをチェックする（ステップＧ２）。

その結果、追加エントリの「サーバタイプ」が「ミラー」である時は、テーブル設定部１１は、何もせずに処理を終了するが（ステップＧ２のＹｅｓルート）、追加エントリの「サーバタイプ」が「マスター」である時は、追加エントリ中の直接アクセス用アドレス（Ａ１４＿ｄａｄｄｒ）及びサーバアドレス（Ａ１４＿ｓａｄｄｒ）を、それぞれ、マスターサーバ宛復旧テーブル２５の直接アクセス用アドレス及び変更アドレスとして設定する（ステップＧ２のＮｏルートからステップＧ３）。

これに対し、登録サービステーブル２１からエントリが削除された場合、テーブル設定部１１は、図２３に示すように、削除されたエントリの「サーバタイプ」をＤ１４＿ｓｔｙｐｅ、サーバアドレスをＤ１４＿ｓａｄｄｒ、直接アクセス用アドレスをＤ１４＿ｄａｄｄｒとして（ステップＨ１）、まず、追加エントリの「サーバタイプ」が「ミラー」かどうかをチェックする（ステップＨ２）。

その結果、追加エントリの「サーバタイプ」が「ミラー」である時は、テーブル設定部１１は、何もせずに処理を終了するが（ステップＨ２のＹｅｓルート）、削除エントリの「サーバタイプ」が「マスター」である時は、当該削除エントリ中の直接アクセス用アドレス（Ｄ１４＿ｄａｄｄｒ）及びサーバアドレス（Ｄ１４＿ｓａｄｄｒ）とそれぞれ一致する内容をもつエントリをマスターサーバ宛復旧テーブル２５において検索し、そのエントリをマスターサーバ宛復旧テーブル２５から削除する（ステップＨ２のＮｏルートからステップＨ３）。

なお、ルーティング処理部１５は、上述のようにして各種変更が行なわれた後のフレームに対して所定のルーティングテーブルに基づくルーティング処理を行なうためのもので、公知のルータが実現しているルーティング処理と同一もしくは同様の処理を行なう。
〔Ｅ〕最適宛先決定の動作例
以下、上述したルータ３の実装機能に基づく実際の動作（最適宛先決定）例について図２４を参照しながら説明する。なお、この図２４において、マスターサーバ１のアドレスはａ、直接アクセス用アドレスはＡ、ミラーサーバ２のアドレスはｂとし、マスターサーバ１及びミラーサーバ２は、それぞれ、サービス識別子としての或るＵＲＬ（例えば、“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｂａｒ／”）により特定されるサービスを提供しているものとする。また、マスターサーバ１ではポート番号＝８０、ミラーサーバ２ではポート番号＝８０８０でそれぞれ同一サービスを提供している。さらに、この図２４では、ルータ３Ａ，３Ｂにおける、マスターサーバ１とミラーサーバ２から得られた上記の各種テーブル２１，２２，２３，２４，２５の内容も図示している。

さて、この図２４において、例えば、端末５から上記ＵＲＬにアクセスを行なう場合は
、端末５（アドレスはｃ）から送信元アドレス＝ｃ，送信先アドレス＝ａ，ポート番号＝８０のフレーム（パケット）が送信される。このパケットは、ルータ３Ａに到着し、ルータ３Ａ内で宛先変更処理が行なわれる。
この場合、ルータ３Ａのマスターサーバ宛変更テーブル２３には、送信元アドレス＝ｃ及び送信先アドレス＝ａと一致するエントリが無いので、ミラーサーバアクセス用アドレス変換部１２によるアドレス変換は行なわれず、受信パケットは最適宛先決定部１３に入力される。

最適宛先決定部１３では、宛先変更テーブル２４により宛先が変更されるが、この場合は、同一内容に変換されるので、結果として変換されずにマスターサーバ宛アドレス変換部１４に入力されることになる。そして、マスターサーバ宛アドレス変換部１４でも、マスターサーバ宛復旧テーブル２５においてヒットするエントリが無いため、アドレス変換は行なわれない。よって、この場合は、そのままアドレス「ａ」宛（マスターサーバ１宛）にフレームが中継されることになる。

一方、端末６から上記ＵＲＬにアクセスを行なう場合は、端末６から送信元アドレス＝ｃ，送信先アドレス＝ａ、ポート番号＝８０のフレーム（パケット）が送信され、当該パケットがルータ４に到着し、ルータ３Ｂにおいて宛先変更処理が行なわれる。
即ち、まず、ミラーサーバアクセス用アドレス変換部１２では、マスターサーバ宛先変更テーブル２３のエントリと送信元アドレスが異なるためヒットせず、アドレス変換は行なわれない。次に、最適宛先決定部１３では、宛先変更テーブル２４に、送信先アドレス＝ａ及びポート番号＝８０をそれぞれ送信先アドレス＝ｂ及びポート番号＝８０８０に変更するエントリが存在するので、送信先アドレスを「ａ」から「ｂ」に、ポート番号を「８０」から「８０８０」にそれぞれ変更する。

そして、マスターサーバ宛アドレス変換部１４では、マスターサーバ宛復旧テーブル２５に該当エントリが無いため、アドレス変換は行なわれない。よって、端末６からのアクセスにおいては、送信先アドレス及びポート番号がそれぞれアドレス＝ｂ及びポート番号＝８０８０宛に変更されるので、ミラーサーバ２に対してアクセスが行なわれることになる。

以上のようにして、各ルータ３が保有するサービス情報に基づいて選択的にサービスアクセス要求の宛先アドレスが選択的に変更されることにより、端末５，６は、その場所（アドレス）に応じて、サーバ１又は２に最短経路でアクセスすることが可能となる。
次に、ミラーサーバ２がマスターサーバ１のウェブコンテンツを更新する際の処理について説明する。

この場合は、ミラーサーバ２からマスターサーバ１に対して、上記ＵＲＬにアクセスが行なわれる。よって、この場合は送信元アドレス＝ｂ，送信先アドレス＝ａ，ポート番号＝８０のフレーム（パケット）がミラーサーバ２から送信される。このパケットは、ルータ３Ｂに到着し、ルータ３Ｂにおいて宛先変更処理が行なわれる。
即ち、まず、ミラーサーバアクセス用アドレス変換部１２では、マスターサーバ変更テーブル２３に、送信元アドレス＝ｂ，送信先アドレス＝ａのフレームについては、送信先アドレスを「Ａ」に変更するエントリが存在しているため、当該受信フレームの送信先アドレスを「Ａ」に変更する。

次に、最適宛先決定部１３では、宛先変更テーブル２４に、宛先アドレス＝ａ，ポート番号＝８０に対するアドレス／ポート番号変更エントリが存在するが、上記の変更によって宛先アドレスが「Ａ」となっているため、本エントリにはヒットしない。そのため、宛先変更テーブル２４によるアドレス変換は行なわれない。最後に、マスターサーバ宛アド
レス変換部１４では、マスターサーバ復旧テーブル２５にヒットするエントリがないため、アドレス変換は行なわない。

さて、このようにしてルータ３Ｂにて宛先アドレスが「Ａ」に変更されたので、ルーティング処理によって、当該フレームはルータ３Ａに中継され、ルータ３Ａにおいても宛先変更処理が行なわれる。
まず、ミラーサーバアクセス用アドレス変換部１２では、マスターサーバ宛変更テーブル２３にヒットするエントリが無いため、アドレス変換は行なわれない。次に、最適宛先決定部１３においても、宛先変更テーブル２４にヒットするエントリが無いため、アドレス変換は行なわれない。最後に、マスターサーバ宛アドレス変換部１４では、マスターサーバ宛復旧テーブル２５に、送信先アドレスＡをアドレス＝ａに変更するエントリが存在するため、当該フレームの送信先アドレスを「ａ」に変更する。

以上により、ルータ３Ａにて宛先アドレスが「ａ」となり、それによってマスターサーバ１にフレームが中継されることになる。このようにして、ミラーサーバ２からマスターサーバ１へのサービス内容更新に対する要求は、上記のような最適サーバの選択を行なわずに、直接、マスターサーバ１へ届くことになる。
〔Ｆ〕本実施形態の効果ないし利点
以上のように、本実施形態によれば、ルータ３間で用いられるルーティングプロトコルであるＢＧＰ４のメッセージに、ネットワーク上に散在するサーバ１，２で提供しているサービスの内容に関する情報（サービス情報）を追加することで、ネットワーク上の全サービスに対する情報をネットワーク全体で共有することが可能となっているため、ネットワーク上で提供されている各種サービスの種別及び場所をルータ３が自動認識することができ、端末５，６がその情報を意識することなく、最適な宛先へのルーティングが可能となる。したがって、特定のサーバ（サービス）への負荷を効率良く分散させて負荷集中を抑制することが可能となる。

また、本実施形態では、ルータ３間のルーティングプロトコルのメッセージにサービス情報を付加しているので、ルータ３の稼動状況に応じて最適な宛先をその都度決定し、常に最適な宛先への中継が行なえることとなる。また、サービスを提供しているサーバ１，２とルータ３との間でもＡＳＲＰによりサービス情報の送受を行なうので、ネットワーク上にサーバを新たに増設する場合でも、ルータ３に対して別途設定を行なうこと必要はなく、自動的に最適宛先決定の対象として追加することが可能である。

さらに、ＡＳＲＰやＢＧＰ４に追加したサービス情報にサービス識別子を含めているので、ルータでは、各種サーバ１，２がどのようなサービスを行なっているかが認識可能となる。その結果、ルータ３は、サービス毎に個別の最適宛先選択を行なうことが可能である。そして、サービス識別子の内容の一例として、ｈｔｔｐの場合は上記のようにＵＲＬを指定することにより、「ウェブサービス」というサービスは同一でもコンテンツが異なる場合はＵＲＬが異なるため、ルータ３は、サービス内容まで一致していることを認識することが可能となり、それぞれ個別に宛先選択を行なうことが可能である。

また、本実施形態のＡＳＲＰにおいて、サーバ１，２は一定周期でＫＥＥＰＡＬＩＶＥメッセージを送信し、ルータ３は、それによってサーバの稼動状況を判別できるようになっているので、サービスを提供するサーバ群それぞれのサービス稼動状況を常に認識して、サービス稼動状況の変更に応じて最適経路の更新が可能である。
さらに、本実施形態のＡＳＲＰに或るサービス内容更新処理対象の情報が処理対象であった場合、及び、ルータ３に設定された一定期間の間サービス内容更新の通知を受信しなかった場合、ルータ３では、登録サービステーブル２１から該当サーバのエントリ（サービス情報）を削除するので、一定期間サービス内容の更新を行なっていなかった場合は、
該当サーバがサービスを稼動していても、中継先のリストから外れることとなる。

つまり、特定サービスの提供元（マスターサーバ１）のもつ情報に対して、同一のサービス内容を反映している他のサーバ群（ミラーサーバ２）の情報が古いと認識した場合、サービス稼動していても、その宛先を対象から外すことが可能になる。したがって、ユーザ（端末５，６）は、常に、最新のサービス内容を提供しているサーバに意識することなくアクセスすることが可能となる。

また、サービス内容更新処理対象の情報は、サーバ１，２毎にＡＳＲＰによってルータに通知されるため、ルータ３は、サーバ１，２毎に更新処理対象／非対象を認識することができる。したがって、たとえサービス内容の更新が滞っているサーバであっても、サービス内容更新処理対象外であれば、登録サービスから削除されることはないので、該当サーバへの中継が継続されることになる。これにより、ミラーサーバ２のサービス内容がマスターサーバ１のものに比べて古いと認識した場合でも、ルータ３は、サービス提供に問題のないサービスである場合は、宛先対象から除外しないようにすることを選択可能となる。

さらに、本実施形態では、マスター満了（ｅｘｐｉｒｅ）時間を設け、ルータ３において、マスターサーバ１が稼動停止してから一定時間後に、宛先サーバ選択テーブル２２から該当サービス情報を削除するので、マスターサーバ１の停止状況に応じてミラーサーバ２への中継も停止することが可能となる。つまり、特定サービスの提供元（マスターサーバ１）が稼動しておらず、かつ、その状況が一定時間続いた場合は、同一のサービス内容を反映している他のサーバ群（ミラーサーバ２）がたとえ稼動していても、一定時間後にはミラーサーバ２のサービス全てを宛先対象から除外することで、サービスを提供していないように見せることが可能になるのである。

また、本実施形態のＡＳＲＰを、ネットワーク上のサーバ１，２にそれぞれ実装することで、当該サーバ１，２のサービス内容をルータ３に通知することができるため、サービス内容を追加又は削除した場合はＡＳＲＰによって当該追加又は削除がルータ３の認識するところとなり、その情報はルーティングプロトコルに付加された属性情報によって全ネットワークが認識することとなる。したがって、特定のサービス内容が追加又は削除された場合でも、ルータ３は、その情報を自動的に認識し、サービスを利用するユーザ端末５，６がその状態を認識しなくても最適の宛先に対してアクセスが行なわれることになる。

さらに、本実施形態では、ルータ３において、宛先のサーバ１，２とそのポート、それに対する最適な宛先とそのポートを最適宛先決定部１３に通知しているため、端末５，６からのサーバに対するアクセスが、最適な宛先に変換された上で中継される。したがって、サービスを利用する端末５，６は、そのサービスの提供元の場所（アドレス）や稼動状況を意識することなく所望のサービスを受けることができる。

また、本実施形態では、ピアのルータ３が停止した時（ＢＧＰ４のＫＥＥＰＡＬＩＶＥメッセージが途絶えた時）は、そのピアのルータ３が送信していた（保有していた）全てのサービス情報に対して削除処理を行なうので、ルータ３が停止して最適な宛先が変化した場合でも、それに対応した宛先を再決定することが可能である。したがって、ネットワーク上のルータ３の稼動状況によってネットワークトポロジが変化しても、その変化した後の状態に応じて最適な宛先を選択することが可能である。

さらに、本実施形態のルータ３では、ＡＳＲＰやＢＧＰ４に追加した属性情報（直接アクセス用アドレス）から、ミラーサーバアクセス用アドレス変換部１２やマスターサーバ宛アドレス変換部１４によって、ミラーサーバ２からマスターサーバ１宛となる通信に対
しては、最適宛先決定部１３での宛先変換対象とならないようにしているため、ミラーサーバ２がマスターサーバ１に対してアクセスを行なう際は、最適宛先経路の選択は行なわずに、必ずマスターサーバ１宛へ通信が行なわれることとなる。したがって、特定サービス内容を反映しているサーバ群（ミラーサーバ２）は、提供しているサービス内容の更新を確実かつ正確に行なえることになる。

以上のように、本発明によれば、ネットワーク上のルーティングノード間で用いられるルーティングプロトコルを用いてサーバで提供しているサービスの内容に関する情報を伝達することで、ネットワーク上の全サービスに関する情報をネットワーク全体で自動的に共有・更新することが可能となるため、ネットワーク上で提供されている各種サービスの種別及び場所等をユーザ端末が意識することなく、サービスアクセスをネットワーク内で常に最適な宛先へルーティングすることが可能となる。したがって、特定サービスへの負荷を効率良く分散させて負荷集中を抑制することができ、ネットワーク通信分野において極めて有用な技術を考えられる。

本発明の一実施形態に係るネットワーク構成を示すブロック図である。 本実施形態で用いるＡＳＲＰパケットのフォーマット例を示す図である。 本実施形態で用いるＡＳＲＰのＡＤＤ＿ＳＥＲＶＩＣＥメッセージのコマンドデータフォーマット例を示す図である。 本実施形態で用いるＡＳＲＰのＳＥＲＶＩＣＥ＿ＤＯＷＮメッセージのコマンドデータフォーマット例を示す図である。 本実施形態で用いる登録サービステーブルの一例を示す図である。 本実施形態で用いるＢＧＰ４のＵＰＤＡＴＥメッセージのフォーマット例を示す図である。 図６に示すＵＰＤＡＴＥメッセージのパス属性フォーマット例を示す図である。 図７に示すＵＰＤＡＴＥメッセージの追加属性の属性タイプコード及び属性値のフォーマット例を示す図である。 図７に示すＵＰＤＡＴＥメッセージの追加属性の属性タイプコード及び属性値のフォーマット例を示す図である。 図７に示すＵＰＤＡＴＥメッセージの追加属性の属性タイプコード及び属性値のフォーマット例を示す図である。 本実施形態で用いる宛先サーバ選択テーブルの一例を示す図である。 本実施形態で用いるマスターサーバ宛変更テーブルの一例を示す図である。 本実施形態で用いる宛先変更テーブルの一例を示す図である。 本実施形態で用いるマスターサーバ宛復旧テーブルの一例を示す図である。 本実施形態のルータにおけるサービス情報の追加，更新処理を説明するためのフローチャートである。 本実施形態のルータにおけるサービス情報の削除処理を説明するためのフローチャートである。 本実施形態のルータの構成を示すブロック図である。 図１７に示すルータのサーバアクセス用アドレス変換部がもつマスターサーバ宛変更テーブルの設定処理（エントリ追加時）を説明するためのフローチャートである。 図１７に示すルータのサーバアクセス用アドレス変換部がもつマスターサーバ宛変更テーブルの設定処理（エントリ削除時）を説明するためのフローチャートである。 図１７に示すルータの最適宛先決定部がもつ宛先変更テーブルの設定処理（エントリ追加時）を説明するためのフローチャートである。 図１７に示すルータの最適宛先決定部がもつ宛先変更テーブルの設定処理（エントリ削除時）を説明するためのフローチャートである。 図１７に示すルータのサーバ宛アドレス変換部がもつ宛先変更テーブルの設定処理（エントリ追加時）を説明するためのフローチャートである。 図１７に示すルータのサーバ宛アドレス変換部がもつ宛先変更テーブルの設定処理（エントリ削除時）を説明するためのフローチャートである。 本実施形態のネットワークの動作を説明するための図である。

Claims (19)

1. 複数のサーバと、該サーバに対するサービスアクセス要求を当該サービスアクセス要求に付与されている宛先情報に従ってルーティングする複数のルーティングノードとをそなえたネットワークにおいて、
   該サーバで提供するサービス内容に関する情報（以下、サービス情報という）を、該ルーティングノード間の経路制御に用いられるルーティングプロトコルに従って前記各ルーティングノード間で高官されるルーティング情報に含めて送受することにより、各ルーティングノードにおいて登録・更新し、
   該ルーティングノードが、それぞれ、自己の保有する該サービス情報に基づいて該サービスアクセス要求の宛先情報を選択的に変更して最適な宛先へルーティングし、さらに、
   同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、
   該ミラーサーバが、自己の提供するサービス内容の更新を行なうためのアクセス要求を該ミラーサーバと接続されているルーティングノードへ送信し、
   該ルーティングノードは、該アクセス要求の宛先情報を該マスターサーバへの直接アクセスを可能とする直接アクセス用宛先情報に変換して該アクセス要求データのルーティングを行なうことを特徴とする、ネットワークにおける特定サービスの最適ルーティング方法。
2. 該サーバで提供するサービス種別を示すサービス識別子を含む該サービス情報を、該ルーティングプロトコルを用いて各ルーティングノードにおいて登録・更新し、
   該ルーティングノードが、それぞれ、該サービス識別子に基づいて該サービス種別単位で該サービスアクセス要求のルーティングを行なうことを特徴とする、請求項１に記載のネットワークにおける特定サービスの最適ルーティング方法。
3. 該サービス識別子として、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）を用いることを特徴とする、請求項２に記載のネットワークにおける特定サービスの最適ルーティング方法。
4. 該サーバが、自己のサービス稼動状況をサービス稼動状況通知メッセージにより自己が接続されているルーティングノードに通知し、
   当該ルーティングノードが、該サービス稼動状況通知メッセージにより通知されたサービス稼動状況に応じて自己が保有する該サービス情報を更新するとともに、該サービス情報の更新を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることを特徴とする、請求項１に記載のネットワークにおける特定サービスの最適ルーティング方法。
5. 該サーバが、自己の提供する該サービス内容が更新される毎にサービス更新メッセージを当該サーバが接続されているルーティングノードに送信し、
   該ルーティングノードが、該サーバから該サービス更新メッセージを一定期間受信しないときは該サービス内容についてのサービス情報の登録を削除するとともに、当該サービス情報の削除を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることを特徴とする、請求項１に記載のネットワークにおける特定サービスの最適ルーティング方法。
6. 該ルーティングノードが、該サービス更新メッセージを一定期間受信しない場合でも非更新対象のサービス内容についてのサービス情報の登録は維持することを特徴とする、請求項５に記載のネットワークにおける特定サービスの最適ルーティング方法。
7. 同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、
   該マスターサーバが、定期的に該サービス稼動状況通知メッセージを自己が接続されているルーティングノードへ通知し、
   該ルーティングノードが、該サービス稼動状況通知メッセージにより該マスターサーバが一定期間稼動停止していると判断すると、該ミラーサーバについての該サービス情報の登録を削除するとともに、当該サービス情報の削除を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることを特徴とする、請求項４に記載のネットワークにおける特定サービスの最適ルーティング方法。
8. 該ルーティングノードが、それぞれ、他のルーティングノードから該ルーティングプロトコルにより定期的に受信されるべき生死確認情報の受信を監視することにより該他のルーティングノードの稼動状況を監視し、該他のルーティングノードの稼動停止が確認されると、自己が保有するサービス情報のうち当該稼動停止した他のルーティングノードについてのサービス情報を削除するとともに、当該サービス情報の削除を該ルーティングプロトコルにより該ネットワーク内の各ルーティングノードに伝達して反映させることを特徴とする、請求項１に記載のネットワークにおける特定サービスの最適ルーティング方法。
9. 複数のサーバと、該サーバに対するサービスアクセス要求を当該サービスアクセス要求に付与されている宛先情報に従ってルーティングする複数のルーティングノードとをそなえたネットワークに用いられる該サーバであって、
   自己が提供するサービス内容に関する情報（以下、サービス情報という）を自己と接続されているルーティングノードに通知するサービス通知手段と、
   自己のサービス稼動状況を該ルーティングノードに通知するサービス稼動状況通知手段とをそなえるとともに、
   自己以外に自己と同一のサービス内容を提供するミラーサーバが存在する場合において、該ミラーサーバが、該ミラーサーバの提供するサービス内容の更新を行なう際に自己への直接アクセスを可能とする直接アクセス用宛先情報を自己に接続されているルーティングノードへ通知する直接アクセス用宛先情報通知手段をそなえたことを特徴とする、ネットワークに用いられるサーバ。
10. 該サービス通知手段が、
    該サービス内容に更新があると、更新後の該サービス内容に関する情報を該ルーティングノードへ通知するサービス更新通知手段をそなえて構成されたことを特徴とする、請求項９に記載のネットワークに用いられるサーバ。
11. 複数のサーバと、該サーバに対するサービスアクセス要求を当該サービスアクセス要求に付与されている宛先情報に従ってルーティングする複数のルーティングノードとをそなえたネットワークに用いられる該ルーティングノードであって、
    自己と接続されているサーバ又は他のルーティングノードから該サーバで提供するサービス内容に関する情報（以下、サービス情報という）を受信して、該サービス情報の登録及び更新を管理するサービス情報管理手段と、
    該サービス情報管理手段での該サービス情報の登録・更新に伴って、該サービス情報を、該ルーティングノード間の経路制御に用いられるルーティングプロトコルに従って前記各ルーティングノード間で交換されるルーティング情報に含めてさらに他のルーティングノードへ伝達するサービス情報伝達手段と、
    該サービス情報管理手段の該サービス情報に基づいて該サービスアクセス要求の宛先情報を選択的に変更して最適な宛先へルーティングするルーティング制御手段とをそなえ、さらに、
    同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、
    該サービス情報管理手段が、
    該マスターサーバへ該ミラーサーバが自己の提供するサービス内容の更新を行なう際に該マスターサーバへの直接アクセスを可能とする直接アクセス用宛先情報を要求する手段と、
    該要求に対して該マスターサーバから受信される該直接アクセス用宛先情報を該サービス情報に含めて他のルーティングノードに伝達する手段とをそなえたことを特徴とする、ネットワークに用いられるルーティングノード。
12. 該サービス情報管理手段が、該サーバの提供するサービス種別を示すサービス識別子を含む該サービス情報を保持・管理するように構成されるとともに、
    該ルーティング制御手段が、該サービス識別子に基づいて該サービス種別単位で該サービスアクセス要求のルーティングを行なうように構成されたことを特徴とする、請求項１１に記載のネットワークに用いられるルーティングノード。
13. 該サービス情報管理手段が、該サービス識別子としてＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）を保持・管理することを特徴とする、請求項１２に記載のネットワークに用いられるルーティングノード。
14. 該サービス情報管理手段が、
    該サーバから通知される当該サーバのサービス稼動状況に応じて該サービス情報を更新する手段をそなえたことを特徴とする、請求項１１に記載のネットワークに用いられるルーティングノード。
15. 該サービス情報管理手段が、
    該サーバから当該サーバの提供する該サービス内容が更新される毎に通知されるサービス更新メッセージを一定期間受信しないときは当該サービス内容についてのサービス情報の登録を削除する手段をそなえたことを特徴とする、請求項１１に記載のネットワークに用いられるルーティングノード。
16. 該サービス情報管理手段が、
    該サービス更新メッセージを一定期間受信しない場合でも非更新対象のサービス内容についてのサービス情報の登録は維持する手段をそなえたことを特徴とする、請求項１５に記載のネットワークに用いられるルーティングノード。
17. 同一のサービス内容を提供する該サーバとしてマスターサーバとミラーサーバとが存在する場合において、
    該サービス情報管理手段が、
    該マスターサーバが定期的に発行するサービス稼動状況通知メッセージにより該マスターサーバが一定期間稼動停止しているか否かを判断する手段と、
    該マスターサーバが稼動停止していると判断すると、該サービス情報管理手段における該ミラーサーバについての該サービス情報の登録を削除する手段とをそなえたことを特徴とする、請求項１１に記載のネットワークに用いられるルーティングノード。
18. 該サービス情報管理手段が、
    他のルーティングノードから該ルーティングプロトコルにより定期的に受信されるべき生死確認情報の受信を監視することにより該他のルーティングノードの稼動状況を監視する手段と、
    該監視により該他のルーティングノードの稼動停止が確認されると、該サービス情報管理手段において自己が保有するサービス情報のうち当該稼動停止した他のルーティングノードについてのサービス情報を削除する手段とをそなえたことを特徴とする、請求項１１に記載のネットワークに用いられるルーティングノード。
19. 該ルーティング制御手段が、
    該ミラーサーバから受信されるアクセス要求の宛先情報を該直接アクセス用宛先情報に変換する宛先変換手段をそなえたことを特徴とする、請求項１２に記載のネットワークに用いられるルーティングノード。

Images