(57)【要約】      （修正有）【課題】大規模データベースを構築することなく、少ない光伝送リソースで、トラヒックパターン変動時にもサービスを継続可能なネットワークを提供する。【解決手段】網管理装置２５及びサービス管理装置２６は、網管理装置が管理するパケットトランスポート網の経路及びサービス管理装置が管理するサイト間の経路を一意に識別する経路識別子を共通に管理し、網管理装置はサービス管理装置から受信する構成変更要求に含まれる経路識別子に対応する論理パスの帯域を運用状態帯域から非運用状態帯域にまたは非運用状態帯域から運用状態帯域に変更するための設定変更要求をＰＴＮ１６〜２４へ送信し、サービス管理装置は構成変更要求に対する応答を受信すると、構成変更要求に含まれる経路識別子で識別される経路上のサーバに宛先アドレスの変更等を指示する。【選択図】図１
2016092459.tif 000002
【特許請求の範囲】
【請求項１】
網管理装置と、サービス管理装置と、複数のサーバ装置と、前記複数のサーバ装置の間を接続する複数の通信装置と、を備える通信システムであって、
前記網管理装置は、
前記複数のサーバ装置が提供するサービスのデータ転送経路を識別する経路識別子と、前記経路識別子で識別される前記複数の通信装置の間を接続する一以上の論理パスと、前記論理パスが運用状態であるか非運用状態であるかを示す運用状況と、前記論理パスが運用状態の場合に該論理パスに設定される帯域である運用時帯域と、前記論理パスが非運用状態の場合に該論理パスに設定される帯域である非運用時帯域と、の第１の対応関係を保持し、
前記サービス管理装置は、
前記経路識別子と、前記経路識別子で識別される前記複数のサーバ間の経路と、の第２の対応関係を保持し、
前記サービス管理装置は、
前記経路識別子と、前記経路識別子で識別される論理パスの運用状況の運用化または非運用化を示す情報と、を含む構成変更要求を前記網管理装置へ送信し、
前記網管理装置は、
前記構成変更要求を受信すると、前記第１の対応関係を参照して、前記構成変更要求に含まれる経路識別子に対応する前記論理パスの帯域を、前記運用状態帯域から前記非運用状態帯域にまたは前記非運用状態帯域から前記運用状態帯域に変更するための設定変更要求を前記複数の通信装置のうち１以上の通信装置へ送信し、
前記サービス管理装置に前記構成変更要求に対する応答を送信し、
前記サービス管理装置は、
前記構成変更要求に対する応答を受信すると、前記第２の対応関係を参照して、前記構成変更要求に含まれる前記経路識別子で識別される前記複数のサーバ間の経路の経路上のサーバに、サービスの停止、サービスの開始、または、宛先アドレスの変更の少なくともいずれかを指示する接続変更通知を送信することを特徴とする通信システム。
【請求項２】
前記網管理装置は、
前記第１の対応関係において、前記１つの経路識別子に対応づけて前記複数の通信装置の間を接続する複数の論理パスの経路を保持し、
前記サービス管理装置は、
前記第２の対応関係において、前記１つの経路識別子に対応づけて前記複数のサーバ間の複数の経路と、前記経路識別子で識別される複数の経路が有効であるか無効であるかを示す有効状態と、を対応づけて保持し、
前記サービス管理装置は、
前記第２の対応関係を参照して、有効化を要求する経路識別子を含む構成変更要求を前記網管理装置へ送信し、
前記網管理装置は、
前記構成変更要求を受信すると、前記第１の対応関係を参照して、前記構成変更要求に含まれる有効化を要求する経路識別子に対応する前記複数の論理パスの帯域を、前記運用状態帯域から前記非運用状態帯域にまたは前記非運用状態帯域から前記運用状態帯域に変更するための設定変更要求を前記複数の通信装置へ送信し、
前記サービス管理装置に前記構成変更要求に対する応答を送信し、
前記サービス管理装置は、
前記構成変更要求に対する応答を受信すると、前記構成変更要求に含まれる前記経路識別子で識別される経路上のサーバに接続変更通知を送信することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記サービス管理装置は、
前記複数のサーバ装置の障害発生、前記複数のサーバ装置の障害復旧、仮想的なサービス提供機能の配備変更、前記サービスの新規追加、若しくは、前記サービスの最大転送データ量の変更を検出したとき、または、前記網構成装置が前記通信装置から受信する障害通知を契機に前記サービス管理装置に送信した障害通知を受信したとき、前記構成変更要求を前記網管理装置に送信することを特徴とする請求項１または２に記載の通信システム。
【請求項４】
前記サービス管理装置は、
前記構成変更要求を前記サーバ装置の障害発生または前記サーバ装置の障害復旧または前記サーバ装置の処理機能の追加または削除を通知したサーバ装置に送信し、
前記サーバ装置は、
前記受信する構成変更要求を、前記複数の通信装置を介して前記網管理装置に転送し、
前記網管理装置は、
前記構成変更要求に対する応答を、前記複数の通信装置を介して前記構成変更要求を送信したサーバ装置に転送し、
前記構成変更要求に対する応答を受信したサーバ装置は、
前記構成変更要求に対する応答を前記サービス管理装置に転送することを特徴とする請求項１に記載の通信システム。
【請求項５】
前記運用時帯域は、前記網管理装置に外部から予め入力される帯域であり、
前記非運用時帯域は、前記構成変更要求に従って新たな経路識別子を前記第２の対応関係に登録するとき、前記通信装置間で接続監視フレームを送受信するために設定される帯域であることを特徴とする請求項１に記載の通信システム。
【請求項６】
前記サービス管理装置は、
前記第２の対応関係において、前記１つの経路識別子に対応して、複数のサービス種別を保持し、前記各サービス種別毎に予備の経路を示す経路識別子を保持し、
前記サービス管理装置は、
前記各サービス種別に対応する複数の予備の経路を示す経路識別子を含む構成変更要求を前記網管理装置へ送信し、
前記網管理装置は、
前記構成変更要求を受信すると、前記第１の対応関係を参照して、前記構成変更要求に含まれる複数の予備の経路を示す経路識別子に対応する前記複数の論理パスの帯域を、前記前記非運用状態帯域から前記運用状態帯域に変更するための設定変更要求を前記複数の通信装置へ送信し、
前記サービス管理装置に前記構成変更要求に対する応答を送信し、
前記サービス管理装置は、
前記構成変更要求に対する応答を受信すると、前記第２の対応関係を参照して、前記構成変更要求に含まれる前記予備の経路を示す経路識別子で識別される経路上の各サーバにサービス種別及びサービスの開始、を指示する接続変更通知を送信することを特徴とする請求項１に記載の通信システム
【請求項７】
前記複数の通信装置は、複数の光伝送装置を介して接続され、
前記複数の光伝送装置間には、複数の光波長経路が設定され、
前記一つの光波長経路で伝送可能な光伝送リソースは固定値であり、
前記一つの光波長経路に対して複数の前記論理パスが設定されることを特徴とする請求項１に記載の通信システム。
【請求項８】
複数のサーバが提供するサービスのデータを中継する複数の通信装置を管理する網管理装置であって、
前記複数のサーバ装置が提供するサービスのデータ転送経路を識別し、前記複数のサーバ装置を管理するサービス管理装置と共通で管理する経路識別子と、前記経路識別子で識別される前記複数の通信装置の間を接続する一以上の論理パスと、前記論理パスが運用状態であるか非運用状態であるかを示す運用状況と、前記論理パスが運用状態の場合に該論理パスに設定される帯域である運用時帯域と、前記論理パスが非運用状態の場合に該論理パスに設定される帯域である非運用時帯域と、の第１の対応関係を保持し、
前記サービス管理装置から、前記経路識別子と、前記経路識別子で識別される論理パスの運用状況の運用化または非運用化を示す情報と、を含む構成変更要求を受信すると、前記第１の対応関係を参照して、前記構成変更要求に含まれる経路識別子に対応する前記論理パスの帯域を、前記運用状態帯域から前記非運用状態帯域にまたは前記非運用状態帯域から前記運用状態帯域に変更するための設定変更要求を前記複数の通信装置のうち１以上の通信装置へ送信し、記サービス管理装置へ前記構成変更要求に対する応答を送信することを特徴とする網管理装置。
【請求項９】
前記通信装置から受信する障害通知を受信すると、前記サービス管理装置に障害通知を送信することを特徴とする請求項８に記載の網管理装置。
【請求項１０】
前記第１の対応関係において、前記１つの経路識別子に対応づけて前記複数の通信装置の間を接続する複数の論理パスの経路を保持し、
前記サービス管理装置から有効化を要求する経路識別子を含む構成変更要求を受信すると、前記第１の対応関係を参照して、前記構成変更要求に含まれる有効化を要求する経路識別子に対応する前記複数の論理パスの帯域を、前記運用状態帯域から前記非運用状態帯域にまたは前記非運用状態帯域から前記運用状態帯域に変更するための設定変更要求を前記複数の通信装置へ送信し、
前記サービス管理装置に前記構成変更要求に対する応答を送信することを特徴とする請求項８に記載の網管理装置。
【請求項１１】
前記構成変更要求を前記通信装置から受信し、前記構成変更要求に対する応答を前記通信装置に送信することを特徴とする請求項８に記載の網管理装置。
【請求項１２】
複数のサーバ装置に接続するサービス管理装置であって、
前記サービス管理装置は、
前記複数のサーバ装置が提供するサービスのデータ転送経路を識別し、サービスデータを中継する通信装置を管理する網管理装置との間で共有に管理する経路識別子と、前記経路識別子で識別される前記複数のサーバ間の経路と、の第２の対応関係を保持し、
前記経路識別子と、前記経路識別子で識別される論理パスの運用状況の運用化または非運用化を示す情報と、を含む構成変更要求を前記網管理装置へ送信し、
前記網管理装置から前記構成変更要求に対する応答を受信すると、前記第２の対応関係を参照して、前記構成変更要求に含まれる前記経路識別子で識別される前記複数のサーバ間の経路の経路上のサーバにサービスの停止、サービスの開始、または、宛先アドレスの変更の少なくともいずれかを指示する接続変更通知を送信することを特徴とするサービス管理装置。、
【請求項１３】
前記複数のサーバ装置の障害発生、前記複数のサーバ装置の障害復旧、仮想的なサービス提供機能の配備変更、前記サービスの新規追加、若しくは、前記サービスの最大転送データ量の変更を検出したとき、または、前記網構成装置が前記通信装置から受信する障害通知を契機に前記サービス管理装置に送信した障害通知を受信したとき、前記構成変更要求を前記網管理装置に送信することを特徴とする請求項１２のサービス管理装置。
【請求項１４】
前記第２の対応関係において、前記１つの経路識別子に対応づけて前記複数のサーバ間の複数の経路と、前記経路識別子で識別される複数の経路が有効であるか無効であるかを示す有効状態と、を対応づけて保持し、
前記第２の対応関係を参照して、有効化を要求する経路識別子を含む構成変更要求を前記網管理装置へ送信し、
前記構成変更要求に対する応答を受信すると、前記構成変更要求に含まれる前記経路識別子で識別される経路上のサーバに接続変更通知を送信することを特徴とする請求項１２に記載のサービス管理装置。
【請求項１５】
前記構成変更要求を前記サーバ装置に送信し、
前記サーバ装置から前記構成変更要求に対する応答を受信することを特徴とする請求項１２に記載のサービス管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してフレームを転送するシステムに関し、特に、データ配信におけるプロテクション技術に関する。
【背景技術】
【０００２】
通信事業者は、企業向け専用線サービス、クラウドサービス、インターネット接続サービスなど、多様なサービスを企業ユーザやコンシューマなどのエンドユーザに提供する。近年、これらのエンドユーザは増加しており、トラヒック量は増加の一途を辿っている。
【０００３】
通信事業者またはサービスプロバイダは、これらのサービスをエンドユーザへ提供するため、複数のデータセンタにサーバを配備する。例えば、クラウドサービスを提供するサーバと、インターネット接続サービスを提供するサーバは、異なるデータセンタ拠点（以下、通信事業者網に接続するサービスプロバイダまたはエンドユーザの拠点を「サイト」と言い、データセンタ拠点を含む）に配備される。さらに、通信事業者は各サイトのサーバ間を接続するネットワークを構築する。エンドユーザが複数のサービスを同時に利用する際は、異なるサイトのサーバ間で通信する。例えば、エンドユーザがクラウド環境でインターネット接続サービスを利用する場合は、クラウドサービスを提供するサーバと、インターネット接続サービスを提供するサーバが通信する。
【０００４】
また、地震等の災害により、特定サイトのサーバが稼働不可となった場合は、地理的に離れた他のサイトのサーバが処理を引き継ぐ。これにより、サイトが被災した場合においても、エンドユーザは継続してサービスを利用できる。
【０００５】
通信事業者は、地理的に離れた複数のサイト間で大容量のトラヒックを転送するため、高速かつ大容量の通信に適した技術であるＷＤＭ（Ｗａｖｅｌｅｎｇｔｈ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘ）を適用する。さらに、通信事業者は、サーバ間の論理接続を制御するための方式として、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ルーティングを適用する。通信事業者は、異なるサイトのサーバ間の通信に必要な帯域を確保するため、光ファイバを敷設して光伝送リソースを確保する。さらに、通信事業者は、オペレーションシステム（Ｏｐｅｒａｔｉｏｎ  Ｓｙｓｔｅｍ、以下ＯｐＳ）を用いてサイト間を接続するネットワークを管理する。
【０００６】
一方、帯域を管理する標準技術としては、論理的な通信経路を予めエンド・トゥー・エンドで静的に設定するＭＰＬＳ−ＴＰ  （Ｍｕｌｔｉ  Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ  -  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｆｉｌｅ）がある。ＭＰＬＳ−ＴＰは、ＩＰパケットにラベルを付与し、ラベルを参照してＩＰパケットを転送するＭＰＬＳ（Ｍｕｌｔｉ  Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）技術の一種である。通信経路（すなわち、論理パス）毎に帯域を設定し、通信経路上の通信装置が設定帯域に従ってポリシング、シェーピング等の帯域制御を行う。また、他の帯域管理技術として、ＧＭＰＬＳ（Ｇｅｎｅｒａｌｉｚｅｄ  Ｍｕｌｔｉ  Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）もある。ＧＭＰＬＳは、光波長の制御によって帯域管理する技術である。
【０００７】
さらに、特許文献１には、２つのレイヤを備える通信システムにおいて、各レイヤを管理する２つの網管理装置と、２つの網管理装置を接続するクロスレイヤ連携装置と、を備え、クロスレイヤ連携装置が各レイヤのパス識別子や帯域等を管理すること、システム管理者が一方のレイヤの網管理装置を用いて設定変更を行うと、クロスレイヤ連携装置が他方のレイヤに必要な帯域変更を実施することが開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−３０４７２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
サイト被災や、サイトに配備されたサーバの仮想化機能であるＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）のマイグレーション等が発生すると、サイト間を接続するネットワークのトラヒック転送経路や帯域等のトラヒックパターンが変動する。通信事業者またはサービスプロバイダが、トラヒックパターンが変動した時にもエンドユーザにサービスを継続して提供するために、サイト間を接続するネットワークに高い信頼性が求められる。
【００１０】
また、通信事業者は、サービストラヒックの増加に対応するため、サイト間を接続するネットワークの光伝送リソースを確保する必要がある。ここで、「サービストラヒック」とは、各サイトがサービスを提供するために通信されるトラヒックである。さらに、通信事業者は、エンドユーザの増加に伴い大規模化するＯｐＳのコストを削減する必要がある。  通信事業者は、ＷＤＭ装置とＩＰルータを用いてサイト間を接続するネットワークを構築することができる。ＷＤＭ装置とＩＰルータとを用いてサイト間を接続するネットワークでは、地理的に離れた複数のサイト間で大容量のトラヒックを転送するため高速かつ大容量の通信に適したＷＤＭ装置を適用し、さらに、サーバ間の論理接続を制御するためＩＰルーティングに従ってトラフィックを転送するルータを適用する。各サイトのサービスを提供するサーバから送出されるトラヒックは、ルータを介してＷＤＭ装置に転送され、ＷＤＭ装置間を転送された後に、通信先のサイトのサーバに接続されるルータに転送され、その後にエンドユーザが接続されるサイトのサーバに転送される。
【００１１】
しかし、通信事業者は、トラヒックパターンが変動した時にもエンドユーザにサービスを継続して提供するためには、ＷＤＭ装置間において、現用経路の通信に必要な帯域だけではなく、サイト障害等のトラヒックパターン変動に応じた全ての予備経路の帯域を常時確保しておく必要がある。そのため、ＷＤＭ装置間において、全ての現用経路と全ての予備経路の帯域を常時確保可能な光伝送リソースが配備されていないと、トラヒックパターン変動時にサービスを継続して提供できない課題があった。そのため、全ての現用経路と全ての予備経路の帯域を常時確保するためのＷＤＭ装置間の光ファイバ敷設コストが生じる課題であった。
【００１２】
また、特許文献１において、一方のネットワークをＭＰＬＳ−ＴＰレイヤに、他方をＩＰレイヤとすれば、全ての予備経路の帯域を常時確保することなく、サイト被災やＶＭマイグレーション発生時に必要な帯域確保が可能となる。各サイトのサービスを提供するサーバから送出されるトラヒックは、ルータを介してＭＰＬＳ−ＴＰ装置に転送され、ＭＰＬＳ−ＴＰ装置間を転送された後に、通信先のサイトのサーバに接続されるルータに転送され、エンドユーザが接続されるサイトのサーバに転送される。ここで、ＭＰＬＳ−ＴＰ装置は物理的に配備されるネットワークリソースの中でデータ転送に割り当てる帯域を論理設定により柔軟に変更できる。よって、トラヒックパターンの変化に応じて必要な予備経路の帯域を確保することにより、全ての予備経路の帯域を常時確保することなく、トラヒックパターン変化の都度、必要な帯域を確保できる。
【００１３】
しかし、特許文献１の構成では、通信事業者及びサービスプロバイダは、サーバを管理するサービス管理装置と、ＭＰＬＳ−ＴＰネットワークを管理する網管理装置に加え、ＩＰレイヤとＭＰＬＳ−ＴＰレイヤのクロスレイヤ連携装置を備える必要がある。クロスレイヤ連携装置は、２つのレイヤの管理情報であるパス識別子、サービス識別子、帯域等を全て管理するため、データベース大規模化のコストが発生する課題があった。さらに、パス識別子と帯域値を網管理装置とクロスレイヤ連携装置との両装置が管理し、サービス識別子をサービス管理装置とクロスレイヤ連携装置との両装置が管理する必要があった。同一のデータを複数の装置で管理するため、片方の装置でデータが更新された時に、他方の装置のデータに対して、同じデータに更新を行う同期処理が課題であった。
【００１４】
一方、前述したＷＤＭ装置とＩＰルータを用いてサイト間を接続するネットワークにおいて、ＧＭＰＬＳを用いて、被災サイトやＶＭマイグレーションの対象となるサイトに応じてＷＤＭ装置間の帯域制御をすれば、使用していない光伝送路の予備経路の帯域開放が可能である。具体的には、利用している経路の帯域のみを確保し、利用していない予備経路の帯域は確保せず、必要になったときに必要な帯域を確保することができる。これにより、通信事業者は、ネットワーク全体としてのトラヒック収容効率を向上できるため、ＷＤＭ装置間の光ファイバ敷設コストを削減できる。しかし、ＧＭＰＬＳは、光波長レイヤの制御を伴うため、例えばＭＰＬＳ−ＴＰのように論理経路の帯域設定をする場合と比較して、帯域設定の変更に長時間を要する。そのためサービスの稼働率が低下（すなわち、サービスを提供出来ない時間が発生）し、通信事業者またはサービスプロバイはエンドユーザが求めるサービス品質を担保できないという課題があった。
【００１５】
本発明は、大規模データベースを構築することなく、かつ、少ない光伝送リソースで、サイト障害やＶＭマイグレーション等に起因するトラヒックパターン変動時にも、サービスを継続して提供可能である、サイト間を接続するネットワークを実現することを目的とする。
【課題を解決するための手段】
【００１６】
上記の課題を解決するために、網管理装置とサービス管理装置と複数のサーバ装置と前記複数のサーバ装置の間を接続する複数の通信装置とを備える通信システムであって、前記網管理装置及びサービス管理装置は、前記網管理装置が管理するパケットトランスポート網の経路、及び、サービス管理装置が管理するサイト間の経路を一意に識別する経路識別子を共通に管理し、前記サービス管理装置は、前記経路識別子と、前記経路識別子で識別される論理パスの運用状況の運用化または非運用化を示す情報と、を含む構成変更要求を前記網管理装置へ送信し、前記網管理装置は、前記構成変更要求を受信すると、前記構成変更要求に含まれる経路識別子に対応する前記論理パスの帯域を、運用状態帯域から非運用状態帯域にまたは非運用状態帯域から運用状態帯域に変更するための設定変更要求を前記複数の通信装置へ送信し、前記サービス管理装置に前記構成変更要求に対する応答を送信し、前記サービス管理装置は、前記構成変更要求に対する応答を受信すると、前記構成変更要求に含まれる前記経路識別子で識別される経路上のサーバにサービスの停止、サービスの開始、または、宛先アドレスの変更の少なくともいずれかを指示する接続変更通知を送信することを特徴の一つとする。
【発明の効果】
【００１７】
本発明により、大規模データベースを構築することなく、かつ、少ない光伝送リソースで、サイト障害やＶＭマイグレーション等に起因するトラヒックパターン変動時にも、サービスを継続して提供することができる。
【図面の簡単な説明】
【００１８】
【図１】第１の実施形態を示し、本発明を適用する通信システムの構成例を示す図である。
【図２】第１の実施形態を示し、本発明を適用する通信システムの構成例を示す図である。
【図３】第１の実施形態を示し、本発明を適用する通信システムの構成例を示す図である。
【図４】第１の実施形態を示し、本発明を適用する通信システムの構成例を示す図である。
【図５】第１の実施形態を示し、本発明を適用する通信システムの構成例を示す図である。
【図６】第１の実施形態を示し、網管理装置の構成の一例を示すブロック図である。
【図７】第１の実施形態を示し、サービス管理装置の構成の一例を示すブロック図である。
【図８】第１の実施形態を示し、網構成管理部の一例を示すフローチャート。
【図９】第１の実施形態を示し、サービス構成管理部の一例を示すフローチャートである。
【図１０Ａ】第１の実施形態を示し、サービス管理表の一例を示す説明図である。
【図１０Ｂ】第１の実施形態を示し、サービス管理表の一例を示す説明図である。
【図１０Ｃ】第１の実施形態を示し、サービス管理表の一例を示す説明図である。
【図１０Ｄ】第１の実施形態を示し、サービス管理表の一例を示す説明図である。
【図１１Ａ】第１の実施形態を示し、網構成管理表の一例を示す説明図である。
【図１１Ｂ】第１の実施形態を示し、網構成管理表の一例を示す説明図である。
【図１１Ｃ】第１の実施形態を示し、網構成管理表の一例を示す説明図である。
【図１１Ｄ】第１の実施形態を示し、網構成管理表の一例を示す説明図である。
【図１１Ｅ】第１の実施形態を示し、網構成管理表の一例を示す説明図である。
【図１２】第１の実施形態を示し、帯域制御の一例を示すシーケンス図である。
【図１３】第１の実施形態を示し、帯域制御の一例を示すシーケンス図である。
【図１４】第１の実施形態を示し、帯域制御の一例を示すシーケンス図である。
【図１５】第１の実施形態を示し、帯域制御の一例を示すシーケンス図である。
【図１６】第１の実施形態を示し、帯域制御の一例を示すシーケンス図である。
【図１７】第２の実施形態を示し、サービス管理表の一例を示す説明図である。
【図１８】第２の実施形態を示し、サービス管理表の一例を示す説明図である。
【図１９】第２の実施形態を示し、サービス管理表の一例を示す説明図である。
【図２０Ａ】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２０Ｂ】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２０Ｃ】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２１】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２２】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２３】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２４】第２の実施形態を示し、網構成管理表の一例を示す説明図である。
【図２５】第３の実施形態を示し、帯域制御の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１９】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００２０】
図１は、本発明を適用する網管理装置、サービス管理装置、通信ノード、及びサーバが構成する通信システムの一例を示すブロック図である。本発明による通信システムは、複数のサイト（ＳｉｔｅＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２）に配備された複数のサーバ（ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２）、複数のルータ１〜６、複数のＷＤＭ装置７〜１５、複数のパケットトランスポート装置（Ｐａｃｋｅｔ  Ｔｒａｎｓｐｏｒｔ  Ｎｏｄｅ  以下ＰＴＮ）１６〜２４、ＰＴＮ１６〜２４が構成するパケットトランスポート網を管理する網管理装置２５、及び、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２を管理するサービス管理装置２６から構成される。ここで、ＰＴＮとＷＤＭ装置は一体であってもよい。
【００２１】
通信事業者は、ルータ１〜６、ＷＤＭ装置７〜１５、ＰＴＮ１６〜２４、及び、網管理装置２５を管理する。サービスプロバイダは、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２、及び、サービス管理装置２６を管理する。なお、同一の事業者がルータ１〜６、ＷＤＭ装置７〜１５、ＰＴＮ１６〜２４、網管理装置２５、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２、及び、サービス管理装置２６を管理しても良い。
【００２２】
ＷＤＭ装置間には、一つ以上の光波長を設定することにより光伝送リソースを確保する。具体的には、ＷＤＭ装置に光波長を設定すると、一つの光波長あたり固定値の光伝送リソースを利用可能となる。例えば、ＷＤＭ装置１３とＷＤＭ装置１４の間を接続する光伝送路は、１００Ｇｂｐｓの光波長が設定される。
【００２３】
通信事業者からの入力を受けて、網管理装置２５はＰＴＮ間に予めＰａｔｈを設定する。図１では、予め設定されたＰａｔｈ１〜９のうち運用Ｐａｔｈとして設定されているＰａｔｈ１〜３を図示している。図１で図示していないが、後述するＰａｔｈ４〜９が非運用Ｐａｔｈとして設定されている。Ｐａｔｈ１〜９は現用経路または予備経路の区別が設定され、さらに、各ＰａｔｈはＰａｔｈの運用状態が設定される。運用Ｐａｔｈとは、ＰａｔｈがＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送するよう設定されている運用状態にあるＰａｔｈである。一方、非運用Ｐａｔｈとは、ＰａｔｈがＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送せず、接続性監視フレーム等制御フレームのみを転送するよう設定されている非運用状態にあるＰａｔｈである。運用Ｐａｔｈには運用時帯域が確保され、非運用Ｐａｔｈには非運用時帯域が確保されるよう、各Ｐａｔｈ上のＰＴＮには帯域が設定されている。運用時帯域はサービストラヒック及び接続性監視フレーム等の制御フレームを転送するために必要と定めた帯域であり、非運用時は接続性監視フレームを転送するために通信事業者が予め設定する帯域である。Ｐａｔｈは、ＰＴＮ間を接続する論理的な通信経路であり、例えばＭＰＬＳ−ＴＰのＬＳＰ（Ｌａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ）がある。Ｐａｔｈ１〜３はサイト障害が発生していない時にＳｅｒｖｅｒＡ１及びＡ２の間、ＳｅｒｖｅｒＢ１及びＢ２の間、ＳｅｒｖｅｒＣ１及びＣ２の間でそれぞれ通信するために、予めＰＴＮ間に設定されるＰａｔｈである。
【００２４】
例えば、ＳｉｔｅＡ１被災時にＳｅｒｖｅｒＣ１がＳｅｒｖｅｒＡ１に代わりエンドユーザへサービス提供するためのＰａｔｈであるＰａｔｈ５は、ＰＴＮ２２、ＰＴＮ２３、ＰＴＮ１７、ＰＴＮ１８間に設定される。ＳｉｔｅＣ１被災時にＳｅｒｖｅｒＡ１がＳｅｒｖｅｒＣ１に代わりエンドユーザへサービス提供するためのＰａｔｈであるＰａｔｈ７は、ＰＴＮ１６、ＰＴＮ１７、ＰＴＮ２３、ＰＴＮ２４間に設定される。Ｐａｔｈ５及びＰａｔｈ７の運用時帯域は１００Ｇｂｐｓ、非運用時帯域は０．００１Ｇｂｐｓに設定される。ここで、Ｐａｔｈ５及びＰａｔｈ７は、ＷＤＭ装置１３とＷＤＭ装置１４間の１００Ｇｂｐｓの１つの光波長を共有するよう設定される。Ｐａｔｈ５とＰａｔｈ７が同時に運用状態となることはないため、Ｐａｔｈ５及びＰａｔｈ７に対して、Ｐａｔｈ５及びＰａｔｈ７の運用時トラヒックの合計値である２００Ｇｂｐｓの光伝送路リソースを確保する必要がなく、１００Ｇｂｐｓの光伝送路リソースを確保すればよい。このように、一つの光波長経路に対して複数の論理パスを設定し、後述するサービス管理装置と網管理装置との処理によりトラヒックパターンの変動に応じて論理パスの運用時帯域と非運用時帯域の設定を変更することで、大規模データベースを構築することなく、かつ、少ない光伝送リソースで、サイト障害やＶＭマイグレーション等に起因するトラヒックパターン変動時にも、サービスを継続して提供することができる。
【００２５】
ユーザ端末２６〜２９はエンドユーザが操作する端末であり、ユーザ端末２６はＳｅｒｖｅｒＡ２、ユーザ端末２７はＳｅｒｖｅｒＢ２、ユーザ端末２８及び２９はＳｅｒｖｅｒＣ２に接続する。例えば、ユーザ端末２６を操作するエンドユーザは、ＳｅｒｖｅｒＡ２が提供するサービスを利用すると同時に、Ｐａｔｈ１によって帯域確保されたＳｅｒｖｅｒＡ１、Ａ２間の通信経路によりＳｅｒｖｅｒＡ２が提供するサービスを利用できる。
【００２６】
網管理装置２５とサービス管理装置２６は互いに接続する。網管理装置２５はサービス管理装置２６からの要求に応じてＰＴＮ１６〜２４の設定帯域を運用時帯域から非運用時帯域または非運用時帯域から運用時帯域に更新する。よって、ＩＰレイヤの状況に応じたパケットトランスポート網の帯域制御が可能となる。ＩＰレイヤとは、ＩＰアドレスに従ってパケットの転送経路を決定するネットワーク階層であり、サーバ間の経路に存在する。ＩＰレイヤの処理はサーバ及びルータが行う。また、ＭＰＬＳ−ＴＰレイヤとは、ＭＰＬＳラベルに従ってパケットの転送経路を決定するネットワーク階層であり、ＰＴＮ間の経路に存在する。ＭＰＬＳ−ＴＰレイヤの処理はＰＴＮが行う。
【００２７】
ＳｉｔｅＡ１のＳｅｒｖｅｒＡ１からＳｉｔｅＡ２のＳｅｒｖｅｒＡ２へのトラヒックの流れを一例として説明する。ＳｅｒｖｅｒＡ１から送出されるトラヒックは、ルータ１においてＩＰパケットのＩＰアドレスに従ってＩＰルーティングの結果ＰＴＮ１６に向け送出される。ＰＴＮ１６は、ＩＰパケットのＩＰアドレスに従って適切なＰａｔｈ（ここではＰａｔｈ１）を特定し、ＩＰパケットを特定したＰａｔｈを示すＭＰＬＳラベルを含むＭＰＬＳ−ＴＰパケットに変換し、変換したＭＰＬＳ−ＴＰパケットを宛先に従ったポートからＷＤＭ装置７に送出する。ＷＤＭ装置７は、ＭＰＬＳ−ＴＰパケットを光パケットに変換し、入力ポートに応じた出力ポートから光パケットを出力する。光パケットはＷＤＭ装置１３で受信され、ＷＤＭ装置１３は光パケットをＭＰＬＳ−ＴＰパケットに変換し、ＷＤＭ装置１３と接続されたＰＴＮ１７に向け送出する。ＰＴＮ１７は、受信したＭＰＬＳ−ＴＰパケットの宛先ラベルと自装置が保持する経路情報とに従って、適切なポートからＭＰＬＳ−ＴＰパケットを出力する。ＷＤＭ装置１３は、ＰＴＮ１７からＭＰＬＳ−ＴＰパケットを受信すると、ＭＰＬＳ−ＴＰパケットを光パケットに変換し、入力ポートに応じた出力ポートから光パケットを出力する。ＷＤＭ装置１３から送出された光パケットはＷＤＭ装置８で受信され、ＷＤＭ装置８は、ＷＤＭ装置１３は光パケットをＭＰＬＳ−ＴＰパケットに変換し、ＭＰＬＳ−ＴＰパケットの宛先ラベルに応じたＰＴＮ１８に向け出力する。ＰＴＮ１８は、ＷＤＭ装置８からＭＰＬＳ−ＴＰパケットを受信すると、宛先ＩＰアドレスを特定し、ＭＰＬＳ−ＴＰパケットをＩＰパケットに変換してルータ２に送出する。ルータ２は、ＩＰパケットのＩＰアドレスに従ってＩＰパケットをＳｅｒｖｅｒＡ２に転送する。ＳｉｔｅＡ１のＳｅｒｖｅｒＡ２からＳｉｔｅＡ１のＳｅｒｖｅｒＡ２へのトラヒックの流れはこの逆である。
【００２８】
ここで、ＷＤＭ装置のみでルータ間を接続する場合とは異なり、ＷＤＭ装置１３において、ＰＴＮ１７にＭＰＬＳ―ＴＰパケットを転送し、ＰＴＮ１７が宛先ラベルに応じたＷＤＭ装置１３のポートにＭＰＬＳ−ＴＰパケットを送出することで、ＷＤＭ装置１３からＷＤＭ装置８（Ｐａｔｈ１）、ＷＤＭ装置１３からＷＤＭ装置１５（Ｐａｔｈ６）、ＷＤＭ装置１３からＷＤＭ装置１４（Ｐａｔｈ７）に光パケットを送出することが出来る。
【００２９】
以上のように通信システムを構成し、帯域を設定し、後述の処理によりＰａｔｈの帯域を非運用時帯域と運用時帯域との間で設定を変更することで、大規模データベースを構築することなく、かつ、少ない光伝送リソースで、サイト障害やＶＭマイグレーション等に起因するトラヒックパターン変動時にも、サービスを継続して提供することができる。
【００３０】
図２は、本発明を適用する網管理装置、サービス管理装置、通信ノード、及びサーバが構成する通信システムにおいて、ＳｉｔｅＡ１の被災が発生した時の運用Ｐａｔｈと非運用Ｐａｔｈの設定を変更した場合の運用Ｐａｔｈを図示した構成の一例を示す図である。Ｐａｔｈ４は、ＳｉｔｅＡ１被災時に、ＳｅｒｖｅｒＢ１がＳｅｒｖｅｒＡ１に代わりエンドユーザへサービス提供するためのＰａｔｈである。Ｐａｔｈ５は、ＳｉｔｅＡ１被災時に、ＳｅｒｖｅｒＣ１がＳｅｒｖｅｒＡ１に代わりエンドユーザへサービス提供するためのＰａｔｈである。Ｐａｔｈ４は、通信事業者からの入力に応じて網管理装置２５が予め設定するＰａｔｈである。Ｐａｔｈ５は、ＳｅｒｖｅｒＡ１の提供サービス追加に伴い、網管理装置２５がサービス管理装置２６からの要求に基づいて設定するＰａｔｈである。
【００３１】
ＳｉｔｅＡ１に障害が発生すると、後述するサービス管理装置２６及び網管理装置の処理により、Ｐａｔｈ１は運用Ｐａｔｈから非運用Ｐａｔｈに変更され、Ｐａｔｈ４及びＰａｔｈ５は非運用Ｐａｔｈから運用Ｐａｔｈに変更される。さらに、ＳｉｔｅＡ２のサーバに接続先変更を通知する。これにより、ＳｉｔｅＡ１障害時、ＳｅｒｖｅｒＢ１及びＳｅｒｖｅｒＣ１がＳｅｒｖｅｒＡ１に代わりエンドユーザへサービスを継続して提供できる。
【００３２】
図３は、本発明を適用する網管理装置、サービス管理装置、通信ノード、及びサーバが構成する通信システムにおいてＳｉｔｅＢ１の被災が発生した時の運用Ｐａｔｈと非運用Ｐａｔｈの設定を変更した場合の運用Ｐａｔｈを図示した構成の一例を示す図である。Ｐａｔｈ６は、ＳｉｔｅＢ１被災時に、ＳｅｒｖｅｒＡ１がＳｅｒｖｅｒＢ１に代わりエンドユーザへサービス提供するために、通信事業者からの入力を受けて網管理装置２５が予め設定するＰａｔｈである。ＳｉｔｅＢ１に障害が発生すると、後述するサービス管理装置２６及び網管理装置の処理により、Ｐａｔｈ２は運用Ｐａｔｈから非運用Ｐａｔｈに変更され、Ｐａｔｈ６は非運用Ｐａｔｈから運用Ｐａｔｈに変更される。さらに、ＳｉｔｅＢ２のサーバに接続先変更を通知する。これにより、網管理装置２５がＰａｔｈ６を設定することにより、ＳｉｔｅＢ１障害時、ＳｅｒｖｅｒＡ１がＳｅｒｖｅｒＢ１に代わりエンドユーザへ継続してサービスを提供できる。
【００３３】
図４は、本発明を適用する網管理装置、サービス管理装置、通信ノード、及びサーバが構成する通信システムでＳｉｔｅＢ１の被災が発生した時の運用Ｐａｔｈと非運用Ｐａｔｈの設定を変更した場合の運用Ｐａｔｈを図示した構成の他の一例を示す図である。Ｐａｔｈ９は、ＳｉｔｅＢ１被災時に、ＳｅｒｖｅｒＣ１がＳｅｒｖｅｒＢ１に代わりエンドユーザへサービス提供するために、通信事業者からの入力を受けて網管理装置２５が予め設定するＰａｔｈである。ＳｉｔｅＢ１に障害が発生すると、後述するサービス管理装置２６及び網管理装置の処理により、Ｐａｔｈ２は運用Ｐａｔｈから非運用Ｐａｔｈに変更され、Ｐａｔｈ９は非運用Ｐａｔｈから運用Ｐａｔｈに変更される。さらに、ＳｉｔｅＢ１のサーバに接続先変更を通知する。網管理装置２５がＰａｔｈ９を設定することにより、ＳｉｔｅＢ１障害時、ＳｅｒｖｅｒＣ１がＳｅｒｖｅｒＢ１に代わりエンドユーザへサービスを継続して提供できる。
【００３４】
図５は、本発明を適用する網管理装置、サービス管理装置、通信ノード、及びサーバが構成する通信システムでＳｉｔｅＣ１の被災が発生した時の運用Ｐａｔｈと非運用Ｐａｔｈをの設定を変更した場合の運用Ｐａｔｈを図示した構成の一例を示す図である。Ｐａｔｈ７は、ＳｉｔｅＣ１被災時に、ＳｅｒｖｅｒＡ１がＳｅｒｖｅｒＣ１に代わりエンドユーザへサービス提供するためのＰａｔｈである。Ｐａｔｈ８は、ＳｉｔｅＣ１被災時に、ＳｅｒｖｅｒＢ１がＳｅｒｖｅｒＣ１に代わりエンドユーザへサービス提供するためのＰａｔｈである。Ｐａｔｈ７及びＰａｔｈ８は、通信事業者からの入力を受けて網管理装置２５が予め設定するＰａｔｈである。網管理装置２５がＰａｔｈ７及びＰａｔｈ８を設定することにより、ＳｉｔｅＣ１に障害が発生すると、後述するサービス管理装置２６及び網管理装置２５の処理により、Ｐａｔｈ３は運用Ｐａｔｈから非運用Ｐａｔｈに変更され、Ｐａｔｈ７及びＰａｔｈ８は非運用Ｐａｔｈから運用Ｐａｔｈに変更される。さらに、ＳｉｔｅＣ１のサーバに接続先変更を通知する。これにより、ＳｉｔｅＣ１障害時、ＳｅｒｖｅｒＡ１及びＳｅｒｖｅｒＢ１がＳｅｒｖｅｒＣ１に代わりエンドユーザへサービスを継続して提供できる。
【００３５】
図６は網管理装置２５の構成の一例を示すブロック図である。網管理装置２５は、ＰＴＮ１６〜２４、及び、サービス管理装置２６と接続する回線１０１（１０１ａ、１０１ｂ）を収容するインタフェース部（ＩＦ）１０２（１０２ａ、１０２ｂ）と、ＣＰＵ１０４と、メモリ１０５と、ハードディスク１０６とから構成される。各構成要素は、バス１０３で接続される。
【００３６】
メモリ１０５には、ＰＴＮ１６〜２４との通信処理を行うプログラムであるＰＴＮ通信処理部１０７、サービス管理装置２６との通信処理を行うプログラムであるサービス管理装置通信処理部１０８、ＰＴＮ１６〜２４が構成するパケットトランスポート網の構成管理を行うプログラムである網構成管理部１０９、及び、ＰＴＮ１６〜２４が構成するパケットトランスポート網の障害管理を行うプログラムであるＰＴＮ障害管理部１１０が記憶されている。
【００３７】
ＰＴＮ通信処理部１０７は、インタフェース部（ＩＦ）１０２を介してＰＴＮ１６〜２４との間でメッセージを送信または受信する。ＰＴＮ通信処理部１０７がＰＴＮ１６〜２４との間で送信または受信するメッセージとしては、例えばＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）メッセージがある。
【００３８】
サービス管理装置通信処理部１０８は、インタフェース部（ＩＦ）１０２を介してサービス管理装置２６との間でメッセージを送信または受信する。
【００３９】
網構成管理部１０９は、ＰＴＮ１６〜２４の間を接続するＰａｔｈ１〜９の経路及び帯域を管理する。
【００４０】
ＰＴＮ障害管理部１１０は、ＰＴＮ１６〜２４から受信するＰＴＮ１６〜２４、及び、Ｐａｔｈ１〜９の障害の発生通知及び回復通知の内容に基づいて、ＰＴＮ１６〜２４、及び、Ｐａｔｈ１〜９の障害状態を管理する。
【００４１】
ハードディスク１０６は、ＰＴＮ１６〜２４の構成情報を管理する網構成管理表１１１から構成される。
【００４２】
図１１Ａは、網管理装置２５に格納される網構成管理表１１１のテーブル構成の一例である。
【００４３】
網構成管理表１１１は、サービス管理装置２６と網管理装置との両方で共通に管理しサービスのデータ転送経路を識別する経路識別子である接続ＩＤ３１１を保持する。接続ＩＤ３１１は、網管理装置が管理するパケットトランスポート網の経路、及び、サービス管理装置が管理するサイト間の経路を一意に識別する経路識別子である。さらに、網構成管理表１１１は、接続ＩＤ３１１に対応するＰａｔｈの識別子であるＰａｔｈ  ＩＤ３１２、ＰａｔｈＩＤ３１２が示すＰａｔｈの端点を備えるＰＴＮのうち、Ｐａｔｈの一方の端点を備えるＰＴＮであるＰＴＮ１６、１９、２２のいずれかを示す情報であるＺ点ＰＴＮ３１３、ＰａｔｈＩＤ３１２が示すＰａｔｈの中継点を備えるＰＴＮを示す情報である中継ＰＴＮ３１４、ＰａｔｈＩＤ３１２が示すＰａｔｈの端点を備えるＰＴＮのうち、Ｐａｔｈの他方の端点を備えるＰＴＮであるＰＴＮ１８、２１、２４のいずれかを示す情報であるＡ点ＰＴＮ３１５、ＰａｔｈＩＤ３１２が示すＰａｔｈがＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送するときの設定帯域である運用時帯域３１６、ＰａｔｈＩＤ３１２が示すＰａｔｈがＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送しない時の設定帯域である非運用時帯域３１７、Ｚ点ＰＴＮ３１３とＡ点ＰＴＮ３１５の間で定期的に送受信する接続性監視フレームによる導通監視結果を示す情報である導通監視３１８、及び、ＰａｔｈＩＤ３１２が示すＰａｔｈがＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送する運用状態にあるか、それともサービストラヒックを転送しない非運用状態にあるか、を示す情報である運用／非運用３１９の対応情報を管理する。Ｚ点ＰＴＮ３１３とＡ点ＰＴＮ３１５の間で定期的に送受信する接続性監視フレームによる導通監視の方式としては、例えばＭＰＬＳ−ＴＰのＯＡＭ（Ｏｐｅｒａｔｉｏｎ、Ａｄｍｉｎｉｓｔｒａｔｉｏｎ、ａｎｄ  Ｍａｉｎｔｅｎａｎｃｅ）フレームによるＰｒｏａｃｔｉｖｅ  ＣＣ（Ｃｏｎｔｉｎｕｉｔｙ  Ｃｈｅｃｋ）／ＣＶ（Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｖｅｒｉｆｉｃａｔｉｏｎ）がある。
【００４４】
網管理装置２５は、運用／非運用３１９が運用あるいは非運用状態に関わらず全てのＰａｔｈの導通監視３１８を管理する。網管理装置２５は、サービス管理装置２６からの構成変更要求に対して、確実にサービストラヒックを転送できる導通監視３１８が「ＯＫ」である非運用状態のＰａｔｈを運用状態に切り替える。これにより、ＰＴＮ１６〜２４がサービストラヒックを確実に転送できる。
【００４５】
図７はサービス管理装置２６の構成の一例を示すブロック図である。サービス管理装置２６は、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２、及び、網管理装置２５と接続する回線１３１（１３１ａ、１３１ｂ）を収容するインタフェース部（ＩＦ）１３２（１３２ａ、１３２ｂ）と、ＣＰＵ１３４と、メモリ１３５と、ハードディスク１３６とから構成される。各構成要素は、バス１３３で接続される。サービス管理装置２６は、網管理装置２５との接続インタフェース１３２bを備えることにより、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の状態に応じて網管理装置２５に対してＰＴＮ１６〜２４が構成するパケットトランスポート網の構成変更要求を送信できる。
【００４６】
メモリ１３５には、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２との通信処理を行うプログラムであるＳｅｒｖｅｒ通信処理部１３７、網管理装置２５との通信処理を行うプログラムである網管理装置通信処理部１３８、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２が提供するサービスを管理するプログラムであるサービス構成管理部１３９、及び、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の障害管理を行うプログラムであるサーバ障害管理部１４０が記憶されている。
【００４７】
サーバ通信処理部１３７は、インタフェース部（ＩＦ）１３２を介してＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２との間でメッセージを送信または受信する。
【００４８】
網管理装置通信処理部１３８は、インタフェース部（ＩＦ）１３２を介して網管理装置２５との間でメッセージを送信または受信する。
【００４９】
サービス構成管理部１３９は、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間で送受信されるサービストラヒックの経路を管理する。
【００５０】
サーバ障害管理部１４０は、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の稼働状態を常時監視することにより、各Ｓｅｒｖｅｒの障害状態を管理する。
【００５１】
ハードディスク１３６は、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間で送受信されるサービストラヒックの経路を管理するサービス管理表１４１から構成される。
【００５２】
図１０Ａは、サービス管理装置２６に格納されるサービス管理表１４１のテーブル構成の一例である。サービス管理表１４１は、サービス管理装置２６と網管理装置の両方で共通に管理する経路識別子である接続ＩＤ３０１、接続ＩＤ３０１に対応するサイト間の経路の端点に位置するＳｅｒｖｅｒが配備されたサイトのうち、経路の端点に位置するサ一方のサイトであるＳｉｔｅＡ２、Ｂ２、Ｃ２のいずれかを示す情報であるＺ点Ｓｉｔｅ、接続ＩＤ３０１に対応するサイト間の経路の端点に位置するＳｅｒｖｅｒが配備されたサイトのうち他方のサイトである、ＳｉｔｅＡ１、Ｂ１、Ｃ１のいずれかを示す情報であるＡ点Ｓｉｔｅ、接続ＩＤ３０１に対応するサイトで提供されるサービス種別として、例えばインターネットサービス、クラウドサービス、モバイルサービス等を示す情報であるサービス種別３０４、接続ＩＤ３０１でサービストラヒックを転送するときに流れ最大転送データ量を示す運用時トラヒック３０５、接続ＩＤ３０１が示す経路が、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２、及びＰＴＮ１６〜２４が構成するパケットトランスポート網で障害が発生していない時あるいは所定の条件が発生していない時にサービストラヒックを流す現用経路と、障害が発生している時あるいはトラヒックパターンの変更が発生する所定の事象が発生した時に現用経路に代わってサービストラヒックを流す予備経路のいずれかを示す情報である現用／予備３０６、接続ＩＤ３０１が示す経路が現用経路である場合はその予備経路を示す情報である予備接続ＩＤ３０７、及び、接続ＩＤ３１１が示す経路がＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送する運用状態にあるか、それともサービストラヒックを転送しない非運用状態にあるか、を示す情報である運用／非運用３０８の対応情報を管理する。トラヒックパターンの変更が発生する所定の事象とは、例えば、サイト障害、ＶＭのサイト間マイグレーション、時間帯に応じたエンドユーザの消費帯域変化などである。
【００５３】
サービスプロバイダは、ひとつの接続ＩＤ３０１に対して予備接続ＩＤ３０７を複数対応づけることができる。サーバまたはパケットトランスポート網の障害により、接続ＩＤ５でサービストラヒックを転送できない状態になった場合は、第１予備の予備接続ＩＤ３０７である接続ＩＤ４が示す経路でサービストラヒックを転送することにより、サーバがサービスを継続して提供できる。接続ＩＤ４が示す経路も障害によりサービストラヒックを転送できない場合は、第２予備の予備接続ＩＤ３０７である接続ＩＤ６が示す経路でサービストラヒックを転送することにより、サーバがサービスを継続して提供できる。また、サーバまたはパケットトランスポート網の障害により、接続ＩＤ９でサービストラヒックを転送できない状態になった場合は、予備接続ＩＤ３０７として設定された接続ＩＤ７、及び接続ＩＤ８が示す２つの経路にサービストラヒックを分散して転送することにより、サーバがサービスを継続して提供できる。
【００５４】
サービス管理装置２６がサーバ通信処理部１３７、網管理装置通信処理部１３８、サーバ構成管理部１３９、サーバ障害管理部１４０、及びサービス管理表１４１を管理することにより、サービス管理装置２６は、サービスの新規追加、ユーザのサービスに対する需要増加、及び、サイトの障害が発生したときに網管理装置２５へＰａｔｈの新規追加や設定帯域の変更要求を送信するとともに、サービストラヒックの転送経路を変更できる。これにより、サービス事業者がエンドユーザにサービスを継続して提供できる。
【００５５】
さらに、ひとつの接続ＩＤ３０１に対して複数の予備接続ＩＤ３０７を設定できることにより、現用／予備３０６が現用である接続経路と、その予備接続経路のうちの１つで同時に障害が発生した場合にも、サービスプロバイダがエンドユーザに継続してサービスを提供できるので、サービスの稼働率を高めることができる。
【００５６】
さらに、ひとつの接続ＩＤ３０１に対して複数の予備接続ＩＤ３０７を設定できることにより、サーバが提供できるサービスの種別に応じてサービストラヒックを分散させることが可能となる。例えば、ＳｅｒｖｅｒＡ１がインターネット接続サービスとクラウドサービスの両方を提供できるが、ＳｅｒｖｅｒＢ１はインターネット接続サービスのみ、ＳｅｒｖｅｒＣ１はクラウドサービスのみを提供できる場合は、ＳｅｒｖｅｒＡ１のサービストラヒックを転送する経路の接続ＩＤに対する予備接続ＩＤとしてＳｅｒｖｅｒＢ１とＳｅｒｖｅｒＣ１が端点となる経路でサービストラヒックを分散することにより、ＳｉｔｅＡ１が被災した場合であってもサービスの継続提供が可能となる。
【００５７】
図１２に示すシーケンスに従って、サービスプロバイダがサービス管理装置２６を用いてＳｅｒｖｅｒＡ１の提供サービス種別及び収容トラヒック量の追加を行う手順、及び、ＳｉｔｅＡ１障害時にＳｅｒｖｅｒＡ１の提供サービスをＳｅｒｖｅｒＢ１、Ｃ１が継続して提供する手順を説明する。
【００５８】
サービス管理装置２６は、サービスプロバイダから、マウス、キーボード、ディスプレイ等の入出力インタフェースを介して、ＳｅｒｖｅｒＡ１が提供するサービスとしてクラウドサービスの追加設定、さらに、ＳｅｒｖｅｒＡ１が提供するインターネット接続サービスの収容トラヒック増加の設定を受け付ける。サービス管理装置２６は、サービスプロバイダから、Ｚ点Ｓｉｔｅ、Ａ点Ｓｉｔｅの情報、及び、接続ＩＤ１で提供するサービス種別としてクラウドサービスの追加設定を受付、その予備接続ＩＤとしてＳｉｔｅＡ２とＳｉｔｅＣ１の間を接続する経路である接続ＩＤ３の追加設定を受付る。さらに、サービス管理装置２６は、サービスプロバイダから、接続ＩＤ１で提供するインターネット接続サービスの収容トラヒック、及び、その予備接続ＩＤ３の収容トラヒック設定を５０Ｇｂｐｓから１００Ｇｂｐｓに変更する要求を受け付ける。サービス管理装置２６のサービス構成管理部１３９は、これらの入力を受付、処理し、サービス管理表１４１を、図１０Ａの状態から図１０Ｂの状態に更新する７０１）。ここでは、接続ＩＤ１のサービス種別インターネットに対応する運用時トラヒックが５０Ｇｂｐsから１００Ｇｂｐｓに更新され、接続ＩＤ１のサービス種別にクラウドが追加され、追加されたサービス種別クラウドに対応して運用時トラフィック１００Ｇｂｐs及び予備接続ＩＤ３が追加されている。また、接続ＩＤ３のエントリが追加される。
【００５９】
サービス管理装置２６のサービス構成管理部１３９が、サービス追加、または、収容トラヒックの変更を設定すると、サービス構成管理部１３９は、サービス管理表１４１を参照して構成変更要求を網管理装置２５に送信する（７０２）。
【００６０】
図９にサービス構成管理部１３９の各処理ステップを示す。図９で、サービス構成管理部１３９は、処理開始（５２１）後、サービス管理表１４１を参照してサービスの新規追加、仮想的なサービス提供機能の配備変更（すなわち、サーバ装置の処理機能の追加または削除）、またはサービストラヒック変更設定（例えば、サービスの最大転送データ量の変更）があるか確認する（５２２）。ステップ５２２でサービスの追加またはトラヒック変更設定がない場合、サーバ障害管理部１４０でのサイト障害検出またはサイト障害回復の検出、または、網管理装置２５からの障害通知受信があるかを確認する（５２３）。ここではサービス管理表１４１が図１０Ａの状態から図１０Ｂの状態に更新されたため、ステップ５２２においてサービスの追加及びトラヒック変更設定があったと判定し、ステップ５２２からステップ５２４に進み、サービス構成管理部１３９はインタフェース部１３２を介して構成変更要求を網管理装置２５に送信する（５２４）。
【００６１】
構成変更要求は、接続ＩＤ１及び接続ＩＤ２のトラヒック量の変更と、接続ＩＤ３追加の情報を含む。なお、サービス管理装置２６は、各Ｓｉｔｅに接続するＰＴＮの情報を管理しており、接続ＩＤ３追加の情報には、ＳｉｔｅＡ２と接続するＰＴＮであるＰＴＮ１８と、ＳｉｔｅＣ１と接続するＰＴＮであるＰＴＮ２２の情報を含むものとする。なお、サービス管理装置２６が各Ｓｉｔｅに接続するＰＴＮの情報を管理せず、構成変更要求にはＳｉｔｅＡ２とＳｉｔｅＣ１の情報を含み、網管理装置２５が各Ｓｉｔｅと接続するＰＴＮの対応を管理しても良い。
【００６２】
図１２に戻り、網管理装置２５がサービス管理装置２６から構成変更要求７０２を受信すると、網管理装置２５が備える網構成管理部１０９はＰａｔｈ設定変更要求をＰＴＮに送信する（７０３、７０４）。
【００６３】
図８に網構成管理部１０９の各処理ステップを示す。図８の処理開始（５０１）後、網構成管理部１０９は、サービス管理装置２６から構成変更要求７０２を受信したか確認する（５０２）。網構成管理部１０９は、サービス管理装置２６から構成変更要求７０２を受信すると、構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含むかを確認する（５０３）。構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含まない場合、網構成管理部１０９は、網構成管理表１１１を参照し、構成変更要求７０２の内容に従ってＰＴＮ１６〜２４にＰａｔｈ設定変更要求をインタフェース部１０２を介して送信する（５０５）。その後、Ｐａｔｈ設定変更要求の全ての送信先ＰＴＮからＯＫ応答を受信すると（５０６）、網構成管理部１０９は、網構成管理表１１１を更新する。その結果、網構成管理表１１１は図１１Ａの状態から図１１Ｂの状態に更新される。ここでは、接続ＩＤ１のＰａｔｈ１の運用時トラヒックが５０Ｇｂｐsから２００Ｇｂｐｓに更新され、接続ＩＤ２のＰａｔｈ４の運用時トラフィックが５０Ｇｂｐsから１００Ｇｂｐsに更新され、さらに、接続ＩＤ３のエントリが追加される。接続ＩＤ３のエントリには、網構成管理部１０９が割り当てるパス識別子であるＰａｔh５，構成変更要求で通知されるＺ点ＰＴＮ、Ａ点ＰＴＮ、網構成管理部１０９で決定される中継ＰＴＮ、構成変更要求で通知される運用状態が格納される。さらに、構成変更要求で通知される運用時トラフィックの値を運用時帯域に格納する。また、網構成管理部は、非運用時帯域には、通信装置間で接続性監視フレームを送受信するために必要な所定の帯域（ここでは、０．００１Ｇｂｐｓ）を格納する。続いて、網構成管理部１０９は、サービス管理装置２６へ構成変更要求７０２に対するＯＫ応答を送信する（５０７）。以上の処理を完了すると、ステップ５０２へ戻る。
【００６４】
図１２の説明に戻る。網管理装置２５は、図８の説明で述べたように、網構成変更（７０３）の処理で構成変更要求７０２にＰａｔｈの運用／非運用の変更を含まないことを確認し、その後、網管理装置２５は、網構成管理表１１１を参照し、構成変更要求７０２の内容に従って、Ｐａｔｈ１の帯域設定を５０Ｇｂｐｓから２００Ｇｂｐｓに変更するＰａｔｈ設定変更要求をＰＴＮ１６〜１８に送信し、Ｐａｔｈ５を開通し、帯域設定を０．００１Ｇｂｐｓに設定するＰａｔｈ設定変更要求をＰＴＮ１７、１８、２２、２３に送信する（７０４）。
【００６５】
ＰＴＮ１６〜１８、２２、２３は、設定変更要求７０４を受信するとＰａｔｈ５の新規開通またはＰａｔｈ１のポリサ、シェーパ等の帯域設定値変更を行い（７０５）、ＯＫ応答（７０６）を網管理装置２５に送信する。その後、網管理装置２５は、サービス管理装置２６へ構成変更要求７０２に対するＯＫ応答を送信する（７０７）。
【００６６】
図９に示すサービス構成管理部１３９の処理ステップの中で、サービス構成管理部１３９は、網管理装置からＯＫ応答を受信すると（５２５）、各Ｓｅｒｖｅｒへ接続変更または収容トラヒック量変更の要求をインタフェース部１３２を介して送信する（５２６）。その後ステップ５２７に進み、サービス構成管理部１３９は、サイト障害検出、サイト障害回復の検出、または、網管理装置からの障害通知受信による構成変更要求送信処理ではない場合、ステップ５２７では処理をせずにステップ５２２へ戻る。
【００６７】
図１２に戻り、サービス管理装置２６は網管理装置２５からＯＫ応答（７０７）を受信すると、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｃ１に対して接続変更要求７０８を送信する。ここでは、接続変更要求７０８は、ＳｅｒｖｅｒＡ１とＳｅｒｖｅｒＡ２に向けクラウドサービスの提供開始を許可する情報、ＳｅｒｖｅｒＡ１とＳｅｒｖｅｒＡ２が提供するインタネットサービスの最大転送データ量を５０Ｇｂｐｓから１００Ｇｂｐｓに変更する旨を指示する情報を含む。また接続変更要求７０８は、ＳｅｒｖｅｒＢ１、ＳｅｒｖｅｒＣ１が、ＳｅｒｖｅｒＡ１の提供サービスであるインタネットサービス及びクラウドサービスのスタンバイ設定を含む。ここで、スタンバイ設定は、ＳｅｒｖｅｒＡ１とのデータ同期処理の開始や、最大データ転送量の変化に応じた処理能力の割当を含む。
【００６８】
接続先変更要求７０８を受信すると、ＳｅｒｖｅｒＡ１はＳｅｒｖｅｒＡ２に向けクラウドサービスのトラヒック送受信を開始する。また、すでに提供しているＳｅｒｖｅｒＡ２へのインタネットサービスの最大転送データ量を５０Ｇｂｐｓから１００Ｇｂｐｓに変更する。ＳｅｒｖｅｒＢ１、ＳｅｒｖｅｒＣ１は、ＳｅｒｖｅｒＡ１が提供スルサービスであるインタネットサービス及びクラウドサービスのスタンバイ設定を行う。
【００６９】
以上の手順により、サービスの追加・収容トラヒックの変更が発生した際に、パケットトランスポート網のＰａｔｈ開通、または、帯域設定の変更が可能となる。これにより、サービスの需要変化に追従したサービス提供が可能となる。
【００７０】
次に、ＳｉｔｅＡ１被災時にＳｅｒｖｅｒＡ１の提供サービスをＳｅｒｖｅｒＢ１、Ｃ１が継続して提供する手順を説明する。ＳｉｔｅＡ１が被災すると（７０９）、サービス管理装置２６は、サーバ障害管理部１４０においてＳｅｒｖｅｒＡ１の接続監視断を検出することにより（７１０）、ＳｉｔｅＡ１障害と判定する（７１１）。
【００７１】
ここで、サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３で、サイト障害検出、サイト障害回復の検出、または、網管理装置２５からの障害通知受信があるかを確認する（５２３）。サービス構成管理部１３９は、サイト障害検出、サイト障害回復の検出、または、網管理装置２５からの障害通知受信のうち、いずれも検出または確認されない場合は再度ステップ５２２に進む。サービス構成管理部１３９は、サイト障害検出、サイト障害回復の検出、または、網管理装置２５からの障害通知受信のいずれか検出または確認される場合はステップ５２４へ進む。ステップ５２４で、サービス構成管理部１３９は、図１０Ｂの状態のサービス管理表１４１を参照し、現用／予備３０６が現用であり、かつＺ点Ｓｉｔｅ３０２またはＡ点Ｓｉｔｅ３０３に、接続監視断が検出されたＳｉｔｅＡ１が登録されている接続ＩＤ３０１を検索する。ここでは、接続ＩＤ１が検索の結果ヒットする。続いてサービス構成管理部１３９は、接続ＩＤ１の予備接続ＩＤ３０７を確認し、インターネットサービスの予備接続ＩＤとして接続ＩＤ２、クラウドサービスの予備接続ＩＤとして接続ＩＤ３が設定されていることを確認する。そして、サービス構成管理部１３９は、インタフェース部１３２を介して、網管理装置２５に、接続ＩＤ１の非運用化と接続ＩＤ２及び接続ＩＤ３の運用化を要求する構成変更要求を送信する（５２４）。
【００７２】
図１２に戻り、網管理装置２５は、サービス管理装置２６から構成変更要求７１２を受信すると、網管理装置２５が備える網構成管理部１０９は、構成変更要求７１２の要求内容に従って、Ｐａｔｈ設定変更要求をＰＴＮに送信する（７１３、７１４）。
【００７３】
図８に示した網構成管理部１０９の各処理ステップの中で、網管理装置２５がサービス管理装置２６から構成変更要求７１２を受信すると（５０２）、網構成管理部１０９は、構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含むかを確認する（５０３）。構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含む場合、網構成管理部１０９は、網構成管理表１１１を参照し、運用化を要求された接続ＩＤの導通監視３１８を確認する（５０４）。ここでは、運用化を要求された接続ＩＤ２、及び接続ＩＤ３の導通監視３１８が、図１１Ｂの網構成管理表１１１でいずれもＯＫであるので、ステップ５０５に進み、Ｐａｔｈ設定変更要求をＰＴＮ１６〜１９、ＰＴＮ２０、ＰＴＮ２２〜２３に送信する。
【００７４】
接続ＩＤ１を非運用化するＰａｔｈ１設定変更要求は、網管理装置２５が、図１１Ｂの網構成管理表１１１で接続ＩＤ１のＺ点ＰＴＮ３１３、中継ＰＴＮ３１４、及びＡ点ＰＴＮ３１５として登録されたＰＴＮ１６〜１８に送信するメッセージであり、運用時帯域３１６の値２００Ｇｂｐｓから非運用時帯域３１７の値０．００１Ｇｂｐｓに帯域値を変更する要求メッセージである。接続ＩＤ２を運用化するＰａｔｈ４設定変更要求は、網管理装置２５が、図１１Ｂの網構成管理表１１１で接続ＩＤ２のＺ点ＰＴＮ３１３、中継ＰＴＮ３１４、及びＡ点ＰＴＮ３１５として登録されたＰＴＮ１７〜２０に送信するメッセージであり、非運用時帯域３１７の値０．００１Ｇｂｐｓから運用時帯域３１６の値１００Ｇｂｐｓに帯域値を変更する要求メッセージである。接続ＩＤ３を運用化するＰａｔｈ５設定変更要求は、網管理装置２５が、図１１Ｂの網構成管理表１１１で接続ＩＤ３のＺ点ＰＴＮ３１３、中継ＰＴＮ３１４、及びＡ点ＰＴＮ３１５として登録されたＰＴＮ１７〜１８、ＰＴＮ２２〜２３に送信するメッセージであり、非運用時帯域３１７の値０．００１Ｇｂｐｓから運用時帯域３１６の値１００Ｇｂｐｓに帯域値を変更する要求メッセージである。
【００７５】
その後、Ｐａｔｈ設定変更要求の送信先ＰＴＮ全てからＯＫ応答を受信すると（５０６）、網構成管理部１０９は網構成管理表１１１を更新する。その結果、網構成管理表１１１は図１１Ｂの状態から図１１Ｃの状態に更新される。ここでは、Ｐａｔｈ１の運用/非運用３１９が運用から非運用に更新され、Ｐａｔｈ２及びＰａｔｈ３の運用/非運用３１９が非運用から運用に更新される。
【００７６】
続いて、網構成管理部１０９は、サービス管理装置２６へ構成変更要求７０２に対するＯＫ応答を送信する（５０７）。以上の処理を完了すると、ステップ５０２へ戻る。
【００７７】
図１２に戻り、ＰＴＮ１６〜２０、２２、２３は、設定変更要求７１４を受信するとＰａｔｈ１、４、５に関するポリサ、シェーパ等の帯域設定値変更を行い（７１５）、ＯＫ応答（７１６）を網管理装置２５に送信する。その後、網管理装置２５はサービス管理装置２６へ構成変更要求７１２に対するＯＫ応答を送信する（７１７）。
【００７８】
図９に示すサービス構成管理部１３９の処理ステップの中で、サービス管理装置２６が網管理装置からの応答待ち状態５２５でＯＫ応答を受信すると、サービス構成管理部１３９は、各Ｓｅｒｖｅｒへ接続変更または収容トラヒック量変更の要求を送信する（５２６）。その後、ここではサイト障害により構成変更要求を網管理装置２５へ送信したため、サービス管理表を更新する（５２７）。ステップ５２４で、非運用化の対象とした接続ＩＤ１の運用／非運用３０８を非運用に変更し、運用化の対象とした接続ＩＤ２及び接続ＩＤ３の運用／非運用３０８を運用に変更する。その結果、サービス管理表１４１は図１０Ｂの状態から図１０Ｃの状態に更新される。以上の処理が完了すると、ステップ５２２に戻る。
【００７９】
図１２に戻り、サービス管理装置２６は、網管理装置２５からＯＫ応答（７１７）を受信すると、サービス管理表１４１を更新し、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｃ１に対して接続変更要求を送信する（７１８、７１９）。接続先変更要求は、ＳｅｒｖｅｒＡ１にインタネットサービス及びクラウドサービスを停止、ＳｅｒｖｅｒＢ１にＳｅｒｖｅｒＡ２に対するインタネットサービスの開始、ＳｅｒｖｅｒＣ１にＳｅｒｖｅｒＡ２に対するクラウドサービスの開始、ＳｅｒｖｅｒＡ２に、インタネットサービスに関するトラヒックにはＳｅｒｖｅｒＢ１宛てのＩＰアドレスを、クラウドサービスに関するトラヒックにはＳｅｒｖｅｒＣ１宛てのＩＰアドレスを付与するよう指示する情報を含む。
【００８０】
ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｃ１は、接続変更要求７１９を受信すると、サービストラヒックの宛先経路を変更し（７２０）、ＯＫ応答７２１をサービス管理装置２６に送信する（７２１）。サービストラヒックの宛先経路とは具体的には、ＳｅｒｖｅｒＡ１は接続先変更要求を受信すると、ＳｅｒｖｅｒＡ２へのサービス提供を停止する。ＳｅｒｖｅｒＢ１は、ＳｅｒｖｅｒＡ２へのインタネットサービスの提供を開始し、ＳｅｒｖｅｒＣ１は、ＳｅｒｖｅｒＡ２へのクラウドサービスの提供を開始し、ＳｅｒｖｅｒＡ２は、インタネットサービスに関するトラヒックはＳｅｒｖｅｒＢ１宛てのＩＰアドレスを、クラウドサービスに関するトラヒックはＳｅｒｖｅｒＣ１宛てのＩＰアドレスを付与する。
【００８１】
以上、図１２の７０９から７２１の処理により、ＳｉｔｅＡ１で障害が発生した時、図２に示したように、ＳｉｔｅＡ２を介してＳｉｔｅＡ１からＳｉｔｅＡ２に接続するエンドユーザに提供されるインタネットサービス及びクラウドサービスは、ＳｉｔｅＢ１からＰａｔｈ４及びＳｉｔｅＣ１からＰａｔｈ５を介した経路で提供されるように経路が切り替わる。ここで、予備経路は予め設定されており、構成変更要求を受信した時にＰＴＮの帯域設定を変更し、ＳｅｒｖｅｒＡ２が接続変更要求に従って宛先ＩＰアドレスを変更し、ＳｅｒｖｅｒＢ１及びＳｅｒｖｅｒＣ１が接続変更要求を受信するとサービス提供を開始すればよいので、エンドユーザはサービスを継続して利用することが可能となる。特に、本方式では、トラヒックパターン変更時にはＰＴＮの論理設定である帯域設定の変更を行い、光波長の設定を直接変更することがないため、設定変更にかかる時間が短い。そのため、光波長の設定を変更する方式と比較して、短時間でサービスを復旧することが可能となる。
【００８２】
以上により、サービスプロバイダが新サービス追加またはサービス収容トラヒックの変更をした時、及び、サイトが被災した場合に、サービス管理装置２６が網管理装置２５に構成変更要求を送ることにより、網管理装置２５はＰＴＮ１６〜２４に対して、サービストラヒックの転送経路及び帯域の変更に応じたＰａｔｈ設定変更を行う。これにより、サービストラヒックの転送経路及び帯域の変更が発生した場合に、エンドユーザはサービスを継続して利用することが可能となる。
【００８３】
続いて、図１３に示すシーケンスに従って、ＳｉｔｅＡ１が被災から復旧した場合の切り戻し処理手順を説明する。
【００８４】
ＳｉｔｅＡが被災から復旧すると（７３１）、サービス管理装置７３２のサーバ障害管理部１４０は、ＳｅｒｖｅｒＡ１の監視復旧を検出する（７３２）。
【００８５】
図９に示したサービス構成管理部１３９の処理のステップ５２３で、サービス管理装置２６は、サイト障害回復の検出があった場合はステップ５２４へ進む。ステップ５２４で、サービス構成管理部１３９、図１０Ｃの状態のサービス管理表１４１を参照し、現用／予備３０６が現用であり、かつＺ点Ｓｉｔｅ３０２またはＡ点Ｓｉｔｅ３０３として、ＳｉｔｅＡ１が登録されている接続ＩＤ３０１を検索する。ここでは、条件を満たす接続ＩＤとして、接続ＩＤ１がヒットする。サービス構成管理部１３９は、接続ＩＤ１の予備接続ＩＤ３０７を確認し、インターネットサービスの予備接続ＩＤとして接続ＩＤ２、クラウドサービスの予備接続ＩＤとして接続ＩＤ３が設定されていることを確認する。そして、サービス管理装置２６は、接続ＩＤ１の運用化を要求する構成変更要求を網管理装置２５に送信する（５２４）。
【００８６】
図１３に戻り、網管理装置２５がサービス管理装置２６から構成変更要求７３４を受信すると、網管理装置２５が備える網構成管理部１０９は、網構成管理表１１１を参照し、構成変更要求７３４の内容に従って、Ｐａｔｈ１の帯域設定を非運用時帯域の０．００１Ｇｂｐｓから運用時帯域の２００Ｇｂｐｓに変更するＰａｔｈ設定変更要求をＰＴＮ１６〜１８に送信する（７３６）。ＰＴＮ１６〜１８は、設定変更要求７３６を受信するとＰａｔｈ１のポリサ、シェーパ等の帯域設定値変更を行い（７３７）、ＯＫ応答（７３８）を網管理装置２５に送信する。その後、網管理装置２５はサービス管理装置２６へ構成変更要求７３４に対するＯＫ応答を送信する（７３９）。
【００８７】
サービス管理装置２６は網管理装置２５からＯＫ応答（７３９）を受信すると、サービス管理装置２６は、図９に示すサービス構成管理部１３９の処理ステップ５２７で、サービス管理表を更新する（５２７）。ここでは接続ＩＤ１の運用／非運用３０８を、運用に変更し、接続ＩＤ２、及び接続ＩＤ３の運用／非運用３０８を、非運用に変更する。その結果、サービス管理表１４１は図１０Ｃの状態から図１０Ｂの状態に更新される。その後、サービス管理装置２６は、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｃ１に対して接続変更要求を送信する（７４１）。接続先変更要求は、ＳｅｒｖｅｒＡ１にインタネットサービス及びクラウドサービスを開始、ＳｅｒｖｅｒＢ１にＳｅｒｖｅｒＡ２に対するインタネットサービスの停止、ＳｅｒｖｅｒＣ１にＳｅｒｖｅｒＡ２に対するクラウドサービスの停止、ＳｅｒｖｅｒＡ２に、インタネットサービス及びクラウドサービスに関するトラヒックにＳｅｒｖｅｒＡ１宛てのＩＰアドレスを付与するよう指示する情報を含む。
【００８８】
ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｃ１は、接続変更要求７４１を受信すると、サービストラヒックの宛先経路を変更し（７４２）、ＯＫ応答７４３をサービス管理装置２６に送信する。サービストラヒックの宛先経路とは具体的には、ＳｅｒｖｅｒＡ１は接続先変更要求を受信すると、ＳｅｒｖｅｒＡ２へのインタネットサービス及びクラウドサービスの提供を開始する。ＳｅｒｖｅｒＢ１は、ＳｅｒｖｅｒＡ２へのインタネットサービスの提供を停止し、ＳｅｒｖｅｒＣ１は、ＳｅｒｖｅｒＡ２へのクラウドサービスの提供を停止し、ＳｅｒｖｅｒＡ２は、インタネットサービス及びクラウドサービスに関するトラヒックはＳｅｒｖｅｒＡ１宛てのＩＰアドレスを付与する。
【００８９】
続いてサービス管理装置２６は、接続ＩＤ２及び接続ＩＤ３の非運用化を要求する構成変更要求を網管理装置２５に送信する（７４４）。網管理装置２５がサービス管理装置２６から構成変更要求７４４を受信すると、網管理装置２５が備える網構成管理部１０９は網構成管理表１１１を参照し、構成変更要求７４４の内容に従って、Ｐａｔｈ４、及びＰａｔｈ５の帯域設定を運用時帯域１００Ｇｂｐsから非運用時帯域０．００１Ｇｂｐｓに変更するＰａｔｈ設定変更要求をＰＴＮ１７〜２０、ＰＴＮ２２、及びＰＴＮ２３に送信する（７４６）。ＰＴＮ１７〜２０、ＰＴＮ２２、及びＰＴＮ２３は、設定変更要求７４６を受信するとＰａｔｈ４、及びＰａｔｈ５のポリサ、シェーパ等の帯域設定値変更を行い（７４７）、ＯＫ応答（７４８）を網管理装置２５に送信する。その後、網管理装置２５の網構成管理部１０９は、図８のステップ５０７の処理で網構成管理表１１１を更新する。その結果、網構成管理表１１１は図１１Ｂの状態に更新される。その後、網管理装置２５はサービス管理装置２６へ、構成変更要求７４４に対するＯＫ応答を送信する（７４９）。
【００９０】
以上、図１３で説明した処理により、図２に示したＳｉｔｅＡ２に接続するエンドユーザに提供されるインターネットサービス及びクラウドサービスがＳｉｔｅＢ１からＰａｔｈ４及びＳｉｔｅＣ１からＰａｔｈ５を介して提供されていた経路が、図１で示すＳｉｔｅＡ１からＰａｔｈ１を介してＳｉｔｅＡ２にトラフィックが転送される経路に切り替わる。
【００９１】
以上の手順により、サイト障害復旧時は、網管理装置２５が切り戻し先のＰａｔｈの帯域を運用時帯域に変更してから、サービス管理装置２６がサービストラヒックの経路切り戻しを実行する。その後、網管理装置２５が、切り戻し前にサービストラヒックを転送していたＰａｔｈの帯域を非運用時帯域に変更する。これにより、サービストラヒック断のない切り戻し処理が可能となる。その結果、エンドユーザは切り戻し処理時にもサービスを利用可能となる。
【００９２】
続いて、図１４に示すシーケンスに従って、Ｐａｔｈ６の導通監視３１８がＮＧの時に、ＳｉｔｅＢ１で被災が発生した場合に、ＳｅｒｖｅｒＢ１の提供サービスをＳｅｒｖｅｒＣ１が継続して提供する手順を説明する。図１で示した経路から図４に示した経路に切り替わる場合である。
【００９３】
ＳｉｔｅＢ１が被災すると（７６１）、サービス管理装置２６のサービス障害管理部１４０は、ＳｅｒｖｅｒＢ１の接続監視断を検出することにより（７６２）、ＳｉｔｅＢ１障害と判定する（７６３）。
【００９４】
サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３でサイト障害検出を確認すると、ステップ５２４へ進む。ステップ５２４で、サービス構成管理部１３９は、図１０Ｂの状態のサービス管理表１４１を参照し、現用／予備３０６が現用であり、かつＺ点Ｓｉｔｅ３０２またはＡ点Ｓｉｔｅ３０３として、ＳｉｔｅＢ１が登録されている接続ＩＤ３０１を検索する。ここでは、条件を満たす接続ＩＤとして、接続ＩＤ５がヒットする。続いてサービス構成管理部１３９は、接続ＩＤ５の予備接続ＩＤ３０７を確認し、第１予備の接続ＩＤとして接続ＩＤ４が設定されていることを確認する。そして、サービス管理装置２６は、接続ＩＤ５の非運用化と接続ＩＤ４の運用化を要求する構成変更要求を網管理装置２５に送信する（５２４）。
【００９５】
図１４に戻り、サービス管理装置２６は、網管理装置２５に構成変更要求７６４を送信する。網管理装置２５がサービス管理装置２６から構成変更要求７６４を受信すると、網管理装置２５が備える網構成管理部１０９は、図８の網構成変更処理を行う（７６５）。
【００９６】
網管理装置２５の網構成管理部１０９は、図８に示した処理のステップ５０４で、網構成管理表１１１を参照し、運用化を要求された接続ＩＤの導通監視３１８を確認する（５０４）。ここでは、運用化を要求された接続ＩＤ４の導通監視３１８が、図１１Ｄの網構成管理表１１１でＮＧであるので、ステップ５０８に進み、網管理装置２５は、サービス管理装置２６へＮＧ応答を送信する。
【００９７】
図１４に戻り、網管理装置２５はサービス管理装置２６へＮＧ応答を送信する。
サービス管理装置２６は、図９に示すサービス構成管理部１３９の処理ステップの中で、網管理装置からＮＧ応答を受信すると（５２５）、再度ステップ５２４へ進む。ステップ５２４で、サービス管理装置２６は、図１０Ｂの状態のサービス管理表１４１を参照し、接続ＩＤ５の予備接続ＩＤ３０７を確認し、第２予備の接続ＩＤとして接続ＩＤ６が設定されていることを確認する。そして、サービス管理装置２６は、網管理装置２５に対して、接続ＩＤ５の非運用化と接続ＩＤ６の運用化を要求する構成変更要求を送信する（５２４）。
【００９８】
図１４に戻り、サービス管理装置２６は網管理装置２５に構成変更要求７６８を送信する。網管理装置２５がサービス管理装置２６から構成変更要求７６８を受信すると、網管理装置２５が備える網構成管理部１０９は、構成変更要求７６４の要求内容に従って、Ｐａｔｈ設定変更要求をＰＴＮに送信する（７６９、７７０）。
【００９９】
網管理装置２５は、図８に示した網構成管理部１０９の処理のステップ５０４で、網構成管理表１１１を参照し、運用化を要求された接続ＩＤの導通監視３１８を確認する（５０４）。ここでは、運用化を要求された接続ＩＤ６の導通監視３１８が、図１１Ｄの網構成管理表１１１でＯＫであるので、ステップ５０５に進み、Ｐａｔｈ設定変更要求をＰＴＮ１９〜２３に送信する。
【０１００】
接続ＩＤ５を非運用化するＰａｔｈ２設定変更要求は、網管理装置２５が図１１Ｄの網構成管理表１１１で接続ＩＤ５のＺ点ＰＴＮ３１３、中継ＰＴＮ３１４、及びＡ点ＰＴＮ３１５として登録されたＰＴＮ１９〜２１に送信するメッセージであり、運用時帯域３１６の値１００Ｇｂｐｓから非運用時帯域３１７の値０．００１Ｇｂｐｓに帯域値を変更する要求メッセージである。接続ＩＤ６を運用化するＰａｔｈ９設定変更要求は、網管理装置２５が図１１Ｄの網構成管理表１１１で接続ＩＤ６のＺ点ＰＴＮ３１３、中継ＰＴＮ３１４、及びＡ点ＰＴＮ３１５として登録されたＰＴＮ２０〜２３に送信するメッセージであり、非運用時帯域３１７の値０．００１Ｇｂｐｓから運用時帯域３１６の値１００Ｇｂｐｓに帯域値を変更する要求メッセージである。
【０１０１】
その後、網管理装置２５は、Ｐａｔｈ設定変更要求の送信先ＰＴＮ全てからＯＫ応答を受信すると（５０６）、網構成管理表１１１を更新する。その結果、網構成管理表１１１は図１１Ｄの状態から図１１Ｅの状態に更新される。続いて、網管理装置２５は、サービス管理装置２６へ構成変更要求７６８に対するＯＫ応答を送信する（５０７）。以上の処理を完了すると、ステップ５０２へ戻る。
【０１０２】
図１４に戻り、ＰＴＮ１９〜２３は、設定変更要求７７０を受信するとＰａｔｈ２、Ｐａｔｈ９に関するポリサ、シェーパ等の帯域設定値変更を行い（７７１）、ＯＫ応答（７７２）を網管理装置２５に送信する。その後、網管理装置２５はサービス管理装置２６へ構成変更要求７６８に対するＯＫ応答を送信する（７７３）。
【０１０３】
図９に示すサービス構成管理部１３９の処理ステップの中で、サービス管理装置２６は、網管理装置からの応答待ち状態５２５でＯＫ応答を受信すると、各Ｓｅｒｖｅｒへ接続変更または収容トラヒック量変更の要求を送信する（５２６）。その後、ここではサイト障害により構成変更要求を網管理装置２５へ送信したため、サービス管理表を更新する（５２７）。ステップ５２４で、非運用化の対象とした接続ＩＤ５の運用／非運用３０８を、非運用に変更し、運用化の対象とした接続ＩＤ６の運用／非運用３０８を、運用に変更する。その結果、サービス管理表１４１は図１０Ｃの状態から図１０Ｄの状態に更新される。以上の処理が完了すると、ステップ５２２に戻る。
【０１０４】
図１４に戻り、サービス管理装置２６は網管理装置２５からＯＫ応答（７７３）を受信すると、サービス管理表１４１を更新し、ＳｅｒｖｅｒＢ１、Ｂ２、Ｃ１に対して接続変更要求を送信する（７７４、７７５）。ＳｅｒｖｅｒＢ１、Ｂ２、Ｃ１は、接続変更要求７７５を受信すると、サービストラヒックの宛先経路を変更し（７７６）、ＯＫ応答７７７をサービス管理装置２６に送信する。
【０１０５】
サービス管理装置２６が網管理装置２５へ構成変更要求を送った時、第１予備接続ＩＤが示すＰａｔｈの導通監視３１８がＮＧの場合は、網管理装置２５がサービス管理装置２６へＮＧ応答を送信する。続いて、サービス管理装置２６は、改めて第２予備接続ＩＤが示すＰａｔｈの運用化を含む構成変更要求を網管理装置２５に送信する。網管理装置２５がＰａｔｈの導通状態を常時監視し、導通監視３１８がＯＫのＰａｔｈを運用化することにより、確実にサービストラヒックの導通が可能なＰａｔｈを運用化し、サービストラヒックの経路を切り替えることができる。
【０１０６】
続いて、図１５に示すシーケンスに従って、Ｐａｔｈ１で障害が発生した場合に、ＳｅｒｖｅｒＡ１の提供サービスをＳｅｒｖｅｒＢ１、Ｃ１が継続して提供する手順を説明する。
【０１０７】
ＰＴＮ１６とＰＴＮ１８は、互いに接続性監視フレームをＰａｔｈ１上で定期的に送受信する。接続性監視の方式としては、例えばＭＰＬＳ−ＴＰのＰｒｏａｃｔｉｖｅ  ＣＣ／ＣＶを用いる。ＰＴＮ１６は、接続性監視フレームの疎通断時、Ｐａｔｈ１の障害を検出して（７９１）、網管理装置２５へＰａｔｈ１の障害通知を送信する（７９２）。
【０１０８】
網管理装置２５は、図８に示した網構成管理部１０９の処理のステップ５０９で、ＰＴＮからＰａｔｈ障害通知またはＰａｔｈ障害回復通知を受信したかを確認し、受信していなければステップ５０２に戻る。ＰＴＮからＰａｔｈ障害通知またはＰａｔｈ障害回復通知を受信していたら、ステップ５１０に進み、Ｐａｔｈ障害回復時のみ、回復パスの運用化を実施する。続いてステップ５１１で、網管理装置２５は、網構成管理表１１１を参照し、障害発生Ｐａｔｈまたは障害回復Ｐａｔｈに対応する接続ＩＤの障害発生または回復通知をサービス管理装置２６に送信する。その後、ステップ５０２に戻る。
【０１０９】
図１５に戻り、網管理装置２５は、Ｐａｔｈ１に対応する接続ＩＤ１の障害通知をサービス管理装置２６に送信する（７９３）。サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３で、網管理装置２５から接続ＩＤの障害通知または回復通知を受信すると、ステップ５２４へ進む。ここでは、接続ＩＤ１の予備接続ＩＤ３０７を確認し、インターネットサービスの予備接続ＩＤとして接続ＩＤ２、クラウドサービスの予備接続ＩＤとして接続ＩＤ３が設定されていることを確認する（７９４）。そして、サービス管理装置２６は網管理装置２５に対して、接続ＩＤ１の非運用化と接続ＩＤ２、及び接続ＩＤ３の運用化を要求する構成変更要求を送信する（５２４、７９５）。
【０１１０】
図１５のステップ７９６〜８０４の手順は、図１２のステップ７１３〜７２１と同じである。
【０１１１】
運用状態のＰａｔｈで障害が発生すると、網管理装置２５がサービス管理装置２６へ障害通知を送信することにより、サービストラヒックの経路を変更できる。これにより、パケットトランスポート網で障害が発生した時に、エンドユーザはサービスを継続して利用できる。
【０１１２】
なお、サービス管理装置２６は網管理装置２５から障害通知を受信したら、サーバに配備したＶＭの再配置、及び、サービスデータの転送経路再設定をしても良い。これにより、網の障害状態に応じて必要なサーバ機能配備とエンドユーザへのサービス提供が可能となる。
【０１１３】
続いて、図１６に示すシーケンスに従って、Ｐａｔｈ１の障害が回復した時の処理手順を説明する。
【０１１４】
ＰＴＮ１６は、接続性監視フレームの疎通回復時、Ｐａｔｈ１の障害回復を検出して（８２１）、網管理装置２５へＰａｔｈ１の障害回復通知を送信する（８２２）。
【０１１５】
網管理装置２５は、図８に示した網構成管理部１０９の処理のステップ５０９で、ＰＴＮ障害管理部１１０においてＰＴＮからＰａｔｈ障害通知またはＰａｔｈ障害回復通知を受信したかを確認し、受信していなければステップ５０２に戻る。受信していたら、ステップ５１０に進み、Ｐａｔｈ障害回復時のみ、回復パスの運用化を実施する。続いてステップ５１１で、網管理装置２５は網構成管理表１１１を参照し、障害発生Ｐａｔｈまたは障害回復Ｐａｔｈに対応する接続ＩＤの障害発生または回復通知をサービス管理装置２６に送信する。その後、ステップ５０２に戻る。
【０１１６】
図１６に戻り、網管理装置２５はＰａｔｈ１回復通知８２２を受信すると、網構成変更処理８２３で、Ｐａｔｈ１の運用化を実施する。ステップ８２４〜８２６の処理手順は、図１３のステップ７３６〜７３８の処理手順と同じである。続いて、網管理装置２５は、接続ＩＤ１の回復通知をサービス管理装置に送信する（８２７）。ステップ８２８〜８３７の処理手順は、図１３のステップ７４０〜７４９の処理手順と同じである。
【０１１７】
以上の手順により、Ｐａｔｈ障害回復時は、網管理装置２５が切り戻し先のＰａｔｈの帯域を運用時帯域に変更してから、サービス管理装置２６がサービストラヒックの経路切り戻しを実行する。その後、網管理装置２５が、切り戻し前にサービストラヒックを転送していたＰａｔｈの帯域を非運用時帯域に変更する。これにより、サービストラヒック断のない切り戻し処理が可能となる。その結果、エンドユーザは切り戻し処理時にもサービスを利用可能となる。
【０１１８】
以上に記載した第１の実施の形態によると、運用状態のＰａｔｈについては、サービストラヒックの転送に必要な運用時帯域を設定し、非運用状態のＰａｔｈについては、接続性監視フレームの導通に必要な帯域のみを設定する。これにより、非運用状態のＰａｔｈに対して、サービストラヒックの転送に必要な帯域を設定が不要となる。例えば、ＷＤＭ装置１３とＷＤＭ装置１４の間を接続する光伝送路は、運用時帯域が１００ＧｂｐｓのＰａｔｈ５とＰａｔｈ７を収容するが、これらの合算値である２００Ｇｂｐｓの光伝送路リソースを確保する必要がなく、１００Ｇｂｐｓの光伝送路リソースのみで運用可能となる。これにより、大規模なデータベースを構築することなく、かつ、全予備経路の帯域確保に必要な光伝送リソースを配備せずに、トラヒックの転送経路または帯域変更時のサービス継続提供が可能となる。さらに、高効率なトラヒック収容による光伝送リソースの有効活用、及び、光ファイバ敷設コストの削減が可能となる。
【０１１９】
また、予め非運用状態のＰａｔｈを開通しておき、サイト被災等によるサービストラヒックの経路・帯域変動時は網管理装置２５がＰａｔｈの帯域変更要求をＰＴＮへ送信することにより、サービストラヒックの転送に必要なＰａｔｈの迅速な設定が可能となる。これにより、サービス稼働率を向上できる。
【０１２０】
さらに、網管理装置２５とサービス管理装置２６が共通の接続管理情報である接続ＩＤを管理し、サービストラヒックの経路変更や帯域変更時は接続ＩＤを用いて構成変更要求を送受信する。これにより、網管理装置２５及びサービス管理装置２６の他に、他の管理装置を配備することなく、ＩＰレイヤとＭＰＬＳ−ＴＰレイヤの連携による帯域制御が可能となる。
【０１２１】
＜第２実施形態＞
本発明の第２の実施の形態を、第１の実施の形態との違いを中心に、図面を用いて説明する。第２の実施形態は、網管理装置２５とサービス管理装置２６が、サービス管理装置２６と網管理装置との両方で共通に管理しサービスのデータ転送経路を識別する経路識別子として接続ＩＤではなくトラヒックパターンＩＤを管理することを特徴とする。トラヒックパターンＩＤとは、網管理装置が管理するサービストラヒックのパケットトランスポート網の複数の経路、及び、サービス管理装置が管理するサイト間の複数の経路からなるグループを一意に識別する識別子である。
【０１２２】
図２０Ａ〜Ｃは、網管理装置２５に格納される網構成管理表１１１のテーブル構成の一例を、３つに分割して表現したものである。網構成管理表１１１は、サービス管理装置２６と網管理装置の両方で共通に管理するトラヒックパターンＩＤ３４６、トラヒックパターンＩＤ３４６に対応する複数のＰａｔｈの識別子であるＰａｔｈ  ＩＤ３４７、ＰａｔｈＩＤ３４７が示すＰａｔｈの端点を備えるＰＴＮのうち、ＰＴＮ１６、１９、２２のいずれかを示す情報であるＺ点ＰＴＮ３４８、ＰａｔｈＩＤ３４７が示すＰａｔｈの中継点を備えるＰＴＮを示す情報である中継ＰＴＮ３４９、ＰａｔｈＩＤ３４７が示すＰａｔｈの端点を備えるＰＴＮのうち、ＰＴＮ１８、２１、２４のいずれかを示す情報であるＡ点ＰＴＮ３５０、トラヒックパターンＩＤ３４６が有効の状態でＰａｔｈＩＤ３４７が示すＰａｔｈの帯域３５１、Ｚ点ＰＴＮ３１３とＡ点ＰＴＮ３１５の間で定期的に送受信する接続性監視フレームによる導通監視結果を示す情報である導通監視３５２、ＰａｔｈＩＤ３１２が示すＰａｔｈがＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２の間を流れるサービストラヒックを転送する運用状態にあるか、それともサービストラヒックを転送しない非運用状態にあるか、を示す情報である運用／非運用３５３、及び、トラヒックパターンＩＤ３４６が有効か無効かを表す有効／無効３５４の対応情報を管理する。
【０１２３】
図１７は、サービス管理装置２６に格納されるサービス管理表１４１のテーブル構成の一例である。サービス管理表１４１は、サービス管理装置２６と網管理装置の両方で共通に管理するトラヒックパターンＩＤ３４６、トラヒックパターンＩＤ３４６が有効の状態のときサービストラヒックの処理及び転送を行うサイトのうちＳｉｔｅＡ２、Ｂ２、Ｃ２のいずれかを示す情報である複数のＺ点Ｓｉｔｅ３４２、ＳｉｔｅＡ１、Ｂ１、Ｃ１のいずれかを示す情報である複数のＡ点Ｓｉｔｅ３４３、Ｚ点ＳｉｔｅとＡ点Ｓｉｔｅの間を転送されるトラヒック３４４、トラヒックパターンＩＤ３４１の有効化条件となる障害パターンを示すＳｉｔｅ障害３４５、及び、トラヒックパターンＩＤ３４１が有効か無効かを表す有効／無効３４６の対応情報を管理する。
【０１２４】
図１２に示すシーケンスに従って、ＳｉｔｅＡ１被災時にＳｅｒｖｅｒＡ１の提供サービスをＳｅｒｖｅｒＢ１、Ｃ１が継続して提供する手順を説明する。ＳｉｔｅＡ１が被災すると（７０９）、サービス管理装置２６はＳｅｒｖｅｒＡ１の接続監視断を検出することにより（７１０）、ＳｉｔｅＡ１障害と判定する（７１１）。
【０１２５】
サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３で、ＳｉｔｅＡ１障害検出により、ステップ５２４へ進む。サービス管理装置２６は、図１７の状態のサービス管理表１４１を参照し、有効／無効３４６が有効であるトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ１がヒットする。さらに、Ｓｉｔｅ障害３４５が“ＳｉｔｅＡ１障害（予備面）”であるトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ２がヒットする。そして、サービス管理装置２６は網管理装置２５に対して、トラヒックパターンＩＤ１からトラヒックパターンＩＤ２への変更を要求する構成変更要求を送信する（５２４）。構成変更要求には、少なくとも有効化を要求するトラヒックパターンＩＤを含む。
【０１２６】
図１２に戻り、網管理装置２５はサービス管理装置２６から構成変更要求７１２を受信すると、網管理装置２５が備える網構成管理部１０９は、構成変更要求７１２の要求内容に従って、Ｐａｔｈ設定変更要求をＰＴＮに送信する（７１３、７１４）。
【０１２７】
図８に示した網構成管理部１０９の各処理ステップの中で、網管理装置２５は、サービス管理装置２６から構成変更要求７１２を受信すると（５０２）、構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含むかを確認する（５０３）。ここで、Ｐａｔｈの運用／非運用の変更は、トラヒックパターンＩＤの変更そのものも含むものとする。構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含む場合、網管理装置２５は、網構成管理表１１１を参照し、有効化を要求されたトラヒックパターンＩＤで、運用／非運用３５３が運用であるＰａｔｈの導通監視３５２を確認する（５０４）。図２０Ａで、トラヒックパターンＩＤ２で運用／非運用３５３が運用であるＰａｔｈ２〜５の導通監視３１８が全てＯＫなので、ステップ５０５に進み、Ｐａｔｈ設定変更要求をＰＴＮ１６〜１９、ＰＴＮ２０、ＰＴＮ２２〜２３に送信する。
【０１２８】
図１２に戻り、ステップ７１４〜７１６の手順は第１の実施の形態と同じである。網管理装置２５はＰＴＮ１６〜１９、ＰＴＮ２０、ＰＴＮ２２〜２３からＯＫ応答７１６を受信すると、図８のステップ５０７で網構成管理表１１１を更新する。ここでは、トラヒックパターンＩＤ１の有効／無効３５４を無効に変更し、トラヒックパターンＩＤ２の有効／無効３５４を有効に変更する。図２１に、変更後の網構成管理表１１１のうち、トラヒックパターンＩＤ３４６が１、及び、２のフィールドを示す。トラヒックパターンＩＤ３４６が３〜９のフィールドは、図２０Ａ〜Ｃと同じである。
【０１２９】
その後、網管理装置２５はサービス管理装置２６へ構成変更要求７１２に対するＯＫ応答を送信する（７１７）。
【０１３０】
図９に示すサービス構成管理部１３９の処理ステップの中で、サービス管理装置２６は網管理装置からの応答待ち状態５２５でＯＫ応答を受信すると、各Ｓｅｒｖｅｒへ接続変更または収容トラヒック量変更の要求を送信する（５２６、７１８、７１９）。その後、ここではサイト障害により構成変更要求を網管理装置２５へ送信したため、サービス管理表を更新する（５２７）。サービス管理装置２６はステップ５２４で、トラヒックパターンＩＤ１からトラヒックパターンＩＤ２への変更を要求する構成変更要求を網管理装置２５へ送信したので、トラヒックパターンＩＤ１の有効／無効３４６を無効に変更し、トラヒックパターンＩＤ２の有効／無効３４６を有効に変更する。その結果、サービス管理表１４１は図１７の状態から図１８の状態に更新される。以上の処理が完了すると、ステップ５２２に戻る。
【０１３１】
図１２のステップ７１９〜７２１の手順は第１の実施の形態と同じである。
【０１３２】
サービス管理表１４１がサイト被災パターン毎にトラヒックパターンＩＤ３４１を管理し、網管理装置２５にトラヒックパターンＩＤの変更を含む構成変更要求を送信する。これにより、サイト被災時にサービストラヒックの転送に必要な帯域を確保できるので、エンドユーザはサービスを継続して利用できる。
【０１３３】
続いて、図１３に示すシーケンスに従って、ＳｉｔｅＡ１が被災から復旧した場合の切り戻し処理手順を説明する。
【０１３４】
ＳｉｔｅＡが被災から復旧すると（７３１）、サービス管理装置７３２はＳｅｒｖｅｒＡ１の監視復旧を検出する（７３２）。
【０１３５】
サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３で、サイト障害回復の検出があった場合はステップ５２４へ進む。ステップ５２４で、サービス管理装置２６は、図１８の状態のサービス管理表１４１を参照し、有効／無効３４６として有効が設定されているトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ２がヒットする。トラヒックパターンＩＤ２のＳｉｔｅ障害３４５がＳｉｔｅＡ１障害（予備面）であることを確認すると、Ｓｉｔｅ障害３４５がＳｉｔｅＡ１障害（過渡面）であるトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ６がヒットする。そして、サービス管理装置２６は網管理装置２５に対して、トラヒックパターンＩＤの２から６への変更を要求する構成変更要求を送信する（５２４）。
【０１３６】
図１３に戻り、網管理装置２５はサービス管理装置２６から構成変更要求７３４を受信すると、網管理装置２５が備える網構成管理部１０９は、構成変更要求７３４の要求内容に従って、Ｐａｔｈ設定変更要求をＰＴＮに送信する（７３５、７３６）。図８に示した網構成管理部１０９の各処理ステップの中で、網管理装置２５は、サービス管理装置２６から構成変更要求７３４を受信すると（５０２）、構成変更要求７０２の内容にＰａｔｈの運用／非運用の変更を含むかを確認する（５０３）。ここで、Ｐａｔｈの運用／非運用の変更は、トラヒックパターンＩＤの変更を含むものとする。Ｐａｔｈの運用／非運用の変更またはトラヒックパターンＩＤの変更を含む場合、網管理装置２５は、網構成管理表１１１を参照し、有効化を要求されたトラヒックパターンＩＤ６で、運用／非運用３５３が運用であるＰａｔｈの導通監視３５２を確認する（５０４）。全てＯＫの場合は、ステップ５０５に進み、トラヒックパターンＩＤ２から６へ変更するためにＰａｔｈ１の設定変更要求をＰＴＮ１６〜１８に送信する。
【０１３７】
図１３のステップ７３６〜７３９は、第１の実施の形態と同じである。この時点での網構成管理表１１１の一部を図２２に示す。トラヒックパターンＩＤ６の有効／無効３５４が有効、トラヒックパターンＩＤ１の有効／無効３５４は無効のままである。トラヒックパターンＩＤ２〜５、７〜９のフィールドは、図２０Ａ〜Ｃと同じである。
【０１３８】
サービス管理装置２６は網管理装置２５からＯＫ応答（７３９）を受信すると、サービス管理装置２６は、図９に示すサービス構成管理部１３９の処理ステップ５２７で、サービス管理表を更新する（５２７）。ここではトラヒックパターンＩＤ２の有効／無効３４６を無効に変更し、トラヒックパターンＩＤ１の有効／無効３４６を有効に変更する。その結果、サービス管理表１４１は図１８の状態から図１７の状態に更新される。その後、ステップ７４１〜７４３の処理手順は第１の実施の形態と同じである。
【０１３９】
続いてサービス管理装置２６は網管理装置２５に対して、トラヒックパターンＩＤの６から１への変更を要求する構成変更要求を送信する（７４４）。ステップ７４５〜７４９の処理手順は、ステップ７３５〜７３９で、トラヒックパターンＩＤ２を６に置き換え、トラヒックパターンＩＤ６を１に置き換え、Ｐａｔｈ１をＰａｔｈ４、及び５に置き換えたものと同じである。
【０１４０】
以上の手順により、サイト障害復旧時は、網管理装置２５が切り戻し先のＰａｔｈの帯域を運用時帯域に変更してから、サービス管理装置２６がサービストラヒックの経路切り戻しを実行する。その後、網管理装置２５が、切り戻し前にサービストラヒックを転送していたＰａｔｈの帯域を非運用時帯域に変更する。これにより、サービストラヒック断のない切り戻し処理が可能となる。その結果、エンドユーザは切り戻し処理時にもサービスを利用可能となる。
【０１４１】
続いて、図１４に示すシーケンスに従って、Ｐａｔｈ６の導通監視３１８がＮＧの時に、ＳｉｔｅＢ１で被災が発生した場合に、ＳｅｒｖｅｒＢ１の提供サービスをＳｅｒｖｅｒＣ１が継続して提供する手順を説明する。
【０１４２】
ＳｉｔｅＢ１が被災すると（７６１）、サービス管理装置２６はＳｅｒｖｅｒＢ１の接続監視断を検出することにより（７６２）、ＳｉｔｅＢ１障害と判定する（７６３）。
【０１４３】
サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３で、ＳｉｔｅＢ１障害検出により、ステップ５２４へ進む。サービス管理装置２６は、図１７の状態のサービス管理表１４１を参照し、有効／無効３４６が有効であるトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ１がヒットする。さらに、Ｓｉｔｅ障害３４５が“ＳｉｔｅＢ１障害（予備面その１）”であるトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ３がヒットする。そして、サービス管理装置２６は網管理装置２５に対して、トラヒックパターンＩＤ１からトラヒックパターンＩＤ３への変更を要求する構成変更要求を送信する（５２４）。
【０１４４】
図１４に戻り、サービス管理装置２６は網管理装置２５に構成変更要求７６４を送信する。網管理装置２５はサービス管理装置２６から構成変更要求７６４を受信すると、網管理装置２５が備える網構成管理部１０９は、網構成変更処理を行う（７６５）。
【０１４５】
網管理装置２５は、図８に示した網構成管理部１０９の処理のステップ５０４で、網構成管理表１１１を参照し、有効化を要求されたトラヒックパターンＩＤで、運用／非運用３５３が運用であるＰａｔｈの導通監視３５２を確認する（５０４）。ここで参照する網構成管理表１１１の一部を図２３に示す。トラヒックパターンＩＤ３で運用／非運用３５３が運用であるＰａｔｈ６の導通監視がＮＧなので、ステップ５０８に進み、サービス管理装置２６へＮＧ応答を送信する。
【０１４６】
図１４に戻り、網管理装置２５はサービス管理装置２６へＮＧ応答を送信する。
サービス管理装置２６は、図９に示すサービス構成管理部１３９の処理ステップの中で、網管理装置からＮＧ応答を受信すると（５２５）、再度ステップ５２４へ進む。ステップ５２４で、サービス管理装置２６は、図１７の状態のサービス管理表１４１でＳｉｔｅ障害３４５が“ＳｉｔｅＢ１障害（予備面その２）”であるトラヒックパターンＩＤ３４１を検索し、トラヒックパターンＩＤ４がヒットする。そして、サービス管理装置２６は網管理装置２５に対して、トラヒックパターンＩＤ１からトラヒックパターンＩＤ４への変更を要求する構成変更要求を送信する（５２４）。
【０１４７】
図１４のステップ７６９〜７７７の処理手順は、図１２のステップ７１３〜７２１で、トラヒックパターンＩＤ２をトラヒックパターンＩＤ４、Ｐａｔｈ１、４及び５をＰａｔｈ２及び９、ＰＴＮ１６〜２０、２２、及び２３をＰＴＮ１９〜２３、ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｃ１をＳｅｒｖｅｒＢ１、Ｂ２、Ｃ１にそれぞれ置き換えたものと同様である。
【０１４８】
サービス管理装置２６が網管理装置２５へ構成変更要求を送った時、予備面その１で運用すべきＰａｔｈの導通監視３１８がＮＧの場合は、網管理装置２５がサービス管理装置２６へＮＧ応答を送信する。続いて、サービス管理装置２６は、改めて予備面その２の運用化を含む構成変更要求を網管理装置２５に送信する。網管理装置２５がＰａｔｈの導通状態を常時監視し、導通監視３１８がＯＫのＰａｔｈを運用化することにより、確実にサービストラヒックの導通が可能なＰａｔｈを運用化し、サービストラヒックの経路を切り替えることができる。
【０１４９】
続いて、図１５に示すシーケンスに従って、Ｐａｔｈ１で障害が発生した場合に、ＳｅｒｖｅｒＡ１の提供サービスをＳｅｒｖｅｒＢ１、Ｃ１が継続して提供する手順を説明する。ＰＴＮ１６は、接続性監視フレームの疎通断時、Ｐａｔｈ１の障害を検出して（７９１）、網管理装置２５へ障害通知を送信する（７９２）。障害通知には、例えば、Ｐａｔｈ１の導通監視３５２がＮＧとなったことにより有効化できないトラヒックパターンＩＤ１及び３〜９を含む。
【０１５０】
網管理装置２５は、図８に示した網構成管理部１０９の処理のステップ５０９で、ＰＴＮからＰａｔｈ障害通知またはＰａｔｈ障害回復通知を受信したかを確認し、受信していなければステップ５０２に戻る。受信していたら、ステップ５１０に進み、Ｐａｔｈ障害回復時のみ、回復パスの運用化を実施する。続いてステップ５１１で、網管理装置２５は網構成管理表１１１を参照し、障害発生通知または回復通知をサービス管理装置２６に送信する。その後、ステップ５０２に戻る。
【０１５１】
図１５に戻り、網管理装置２５は、Ｐａｔｈ１の導通監視３５２がＮＧとなったことにより有効化できないトラヒックパターンＩＤ１及び３〜９を含む正体通知をサービス管理装置２６に送信する（７９３）。サービス管理装置２６は、図９に示したサービス構成管理部１３９の処理のステップ５２３で、網管理装置２５から障害通知または回復通知を受信すると、ステップ５２４へ進む。ここでは、
有効化可能なトラヒックパターンＩＤ２に変更することを選択する（７９４）。そして、サービス管理装置２６は網管理装置２５に対して、トラヒックパターンＩＤ１から２への変更を要求する構成変更要求を送信する（５２４、７９５）。
【０１５２】
図１５のステップ７９６〜８０４の手順は、図１２のステップ７１３〜７２１と同じである。
【０１５３】
運用状態のＰａｔｈで障害が発生したら、網管理装置２５がサービス管理装置２６へ障害通知を送信することにより、サービストラヒックの経路を変更できる。これにより、パケットトランスポート網で障害が発生した時に、エンドユーザはサービスを継続して利用できる。
【０１５４】
なお、サービス管理装置２６は網管理装置２５から障害通知を受信したら、サーバに配備したＶＭの再配置、及び、サービスデータの転送経路再設定をしても良い。これにより、網の障害状態に応じて必要なサーバ機能配備とエンドユーザへのサービス提供が可能となる。
【０１５５】
続いて、図１６に示すシーケンスに従って、Ｐａｔｈ１の障害が回復した時の処理手順を説明する。
【０１５６】
ＰＴＮ１６は、接続性監視フレームの疎通回復時、Ｐａｔｈ１の障害回復を検出して（８２１）、網管理装置２５へＰａｔｈ１の障害回復通知を送信する（８２２）。網管理装置２５は、図８に示した網構成管理部１０９の処理のステップ５０９で、ＰＴＮからＰａｔｈ障害通知またはＰａｔｈ障害回復通知を受信したかを確認し、受信していなければステップ５０２に戻る。受信していたら、ステップ５１０に進み、Ｐａｔｈ障害回復時のみ、回復パスの運用化を実施する。続いてステップ５１１で、網管理装置２５は網構成管理表１１１を参照し、障害発生通知または回復通知をサービス管理装置２６に送信する。その後、ステップ５０２に戻る。
【０１５７】
図１６に戻り、網管理装置２５はＰａｔｈ１回復通知８２２を受信すると、網構成変更処理８２３で、トラヒックパターンＩＤ２から６へ変更するための設定をＰＴＮ１６〜１８に送信し、Ｐａｔｈ１を運用化する。
【０１５８】
ステップ８２４〜８２６の処理手順は、図１３のステップ７３６〜７３８の処理手順と同じである。続いて、網管理装置２５は、回復通知をサービス管理装置に送信する（８２７）。ここで、回復通知には、例えば有効化可能なトラヒックパターンＩＤ１〜９の情報を含むものとする。サービス管理装置８２８は、回復通知８２７を受信し、Ｓｉｔｅ障害３４５が“Ｓｉｔｅ障害なし（現用）”であるトラヒックパターンＩＤ１を有効化可能であることを確認すると、トラヒックパターンＩＤを２から１に変更することを選択する。その後、ステップ８２８〜８３７の処理手順は、図１３のステップ７４０〜７４９の処理手順と同じである。
【０１５９】
以上の手順により、Ｐａｔｈ障害回復時は、網管理装置２５が切り戻し先のＰａｔｈの帯域を運用時帯域に変更してから、サービス管理装置２６がサービストラヒックの経路切り戻しを実行する。その後、網管理装置２５が、切り戻し前にサービストラヒックを転送していたＰａｔｈの帯域を非運用時帯域に変更する。これにより、サービストラヒック断のない切り戻し処理が可能となる。その結果、エンドユーザは切り戻し処理時にもサービスを利用可能となる。
【０１６０】
第２の実施の形態によると、各サイト被災時のトラヒックパターンを予め網構成管理表１１１及びサービス管理表１４１が管理する。これにより、サイト被災が発生した際に、サービスプロバイダ及び通信事業者が予め設定した予備の網構成でサービスを継続提供することが可能となる。
【０１６１】
＜第３実施形態＞
本発明の第３の実施の形態を、第１の実施の形態との違いを中心に、図面を用いて説明する。第３の実施形態は、網管理装置２５とサービス管理装置２６との間を直接接続するインタフェースを設けず、ＳｅｒｖｅｒとＰＴＮを介して構成変更要求を送受信することを特徴とする。
【０１６２】
図２５に示すシーケンスに従って、サービスプロバイダがサービス管理装置２６を用いてＳｉｔｅＡ１障害時にＳｅｒｖｅｒＡ１の提供サービスをＳｅｒｖｅｒＢ１、Ｃ１が継続して提供する手順を説明する。
【０１６３】
ＳｉｔｅＡ１が被災すると（９１１）、ＳｅｒｖｅｒＡ１とサービストラヒックを送受信するＳｅｒｖｅｒＡ２が接続断（９１２）を検出することにより、ＳｉｔｅＡ１障害を検出する（９１３）。続いてＳｅｒｖｅｒＡ２はＳｉｔｅＡ１障害通知をサービス管理装置２６に送信する。サービス管理装置２６は、運用化及び非運用化対象の接続ＩＤを決定する（９１５）。ステップ９１５の処理は図１２のステップ７１１で行う運用化及び非運用化対象の接続ＩＤの決定処理と同じである。続いて、サービス管理装置２６は、構成変更要求をＳｅｒｖｅｒＡ２に送信する（９１６）。ＳｅｒｅｒＡ２は直接接続するＰＴＮ１８へ、構成変更要求９１７を転送する（９１７、９１８）。ＰＴＮ１８は、構成変更要求９１８を受信すると、網管理装置２５へ転送する（９１９、９２０）。ステップ９２１〜９２４は、図１２のステップ７１３〜７１６と同じである。ステップ９２５の手順は、ＯＫ応答の転送経路がＰＴＮ１８、及びＳｅｒｖｅｒＡ２を経由している点を除き、図１２のステップ７１７と同じである。ステップ９２６〜９２９は図１２のステップ７１８から７２１と同じである。
【０１６４】
第３の実施の形態によると、網管理装置２５とサービス管理装置２６がＳｅｒｖｅｒとＰＴＮを介して構成変更要求を送受信する。これにより、網管理装置２５とサービス管理装置２６との間を直接接続できない場合に、サービストラヒックの転送経路や収容帯域が変化した時に、パケットトランスポート網の帯域を変更できる。これにより、エンドユーザはサービスを継続して利用できる。
【０１６５】
また、第３の実施の形態によると、Ｓｉｔｅ障害を、障害Ｓｉｔｅに配備されたサーバとサービストラヒックを送受信する他のサーバが検出する。これにより、例えばサービス管理装置２６がサーバ障害管理部１４０の故障によりＳｉｔｅ障害を検出できない場合でも、パケットトランスポート網のＰａｔｈの帯域設定変更、及びサービストラヒックの転送経路や帯域値の変更が可能となる。
【符号の説明】
【０１６６】
ＳｉｔｅＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２  サイト
ＳｅｒｖｅｒＡ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２  サーバ
１〜６  ルータ
７〜１５  ＷＤＭ装置
１６〜２４  ＰＴＮ
２５  網管理装置
２６  サービス管理装置
１０９  網構成管理部
１１１  網構成管理表
１３９  サービス構成管理部
１４１  サービス管理表
【図１】
2016092459.tif 000003
【図２】
2016092459.tif 000004
【図３】
2016092459.tif 000005
【図４】
2016092459.tif 000006
【図５】
2016092459.tif 000007
【図６】
2016092459.tif 000008
【図７】
2016092459.tif 000009
【図８】
2016092459.tif 000010
【図９】
2016092459.tif 000011
【図１０Ａ】
2016092459.tif 000012
【図１０Ｂ】
2016092459.tif 000013
【図１０Ｃ】
2016092459.tif 000014
【図１０Ｄ】
2016092459.tif 000015
【図１１Ａ】
2016092459.tif 000016
【図１１Ｂ】
2016092459.tif 000017
【図１１Ｃ】
2016092459.tif 000018
【図１１Ｄ】
2016092459.tif 000019
【図１１Ｅ】
2016092459.tif 000020
【図１２】
2016092459.tif 000021
【図１３】
2016092459.tif 000022
【図１４】
2016092459.tif 000023
【図１５】
2016092459.tif 000024
【図１６】
2016092459.tif 000025
【図１７】
2016092459.tif 000026
【図１８】
2016092459.tif 000027
【図１９】
2016092459.tif 000028
【図２０Ａ】
2016092459.tif 000029
【図２０Ｂ】
2016092459.tif 000030
【図２０Ｃ】
2016092459.tif 000031
【図２１】
2016092459.tif 000032
【図２２】
2016092459.tif 000033
【図２３】
2016092459.tif 000034
【図２４】
2016092459.tif 000035
【図２５】
2016092459.tif 000036