(57)【要約】  複数の通信装置で構成される通信ネットワークと管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する、通信ネットワークの管理方法であって、管理システムが通信パスを設定する際、稼働率の保証が必要な第１のサービスのために、通信ネットワーク上一部でも同じ経路を共有する通信パス同士を集約する、第１の設定ポリシと、稼働率の保証をしない第２のサービスのために、使用する経路を通信ネットワーク全体に分散するように通信パスを設定する、第２の設定ポリシを有し、サービスの種類に応じて上記設定ポリシを変更することを特徴とする、通信ネットワークの管理方法が開示される。
2016194089.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置で構成される通信ネットワークと管理システムを備え、上記管理システムから設定した通信パスを介して上記複数の通信装置間でパケットを転送する、通信ネットワークの管理方法であって、
上記管理システムが上記通信パスを設定する際、
稼働率の保証が必要な第１のサービスのために、上記通信ネットワーク上一部でも同じ経路を共有する通信パス同士を集約する、第１の設定ポリシと、
稼働率の保証をしない第２のサービスのために、使用する経路を上記通信ネットワーク全体に分散するように上記通信パスを設定する、第２の設定ポリシを有し、
上記サービスの種類に応じて上記設定ポリシを変更することを特徴とする、
通信ネットワークの管理方法。
【請求項２】
上記第１の設定ポリシは、
上記通信ネットワーク上の送信ポートと宛先ポートが全く同一の経路の場合、上記通信パス同士を集約する設定ポリシであることを特徴とする、
請求項１記載の通信ネットワークの管理方法。
【請求項３】
上記第１のサービスは、ユーザまたはサービス毎にある一定の帯域を確保するサービスであって、
上記第１の設定ポリシに基づいて上記管理システムは、
同一経路に集約されたサービスの帯域の総和が上記通信パス上のいずれかの回線帯域を超過した場合、同一経路に集約されたサービスの帯域の総和が上記通信パス上のいずれの回線帯域も超過しない新規の経路を検索し、当該経路に上記通信パスを新規に設定し、ユーザやサービスを収容するように制御し、
上記第２の設定ポリシに基づいて上記管理システムは、
経路上の各回線帯域から上記第１のサービス向けに確保された帯域を差し引いた余りの帯域に基づいて、当該余りの帯域に対して上記第２のサービスのための通信パスを分散することを特徴とする、
請求項１記載の通信ネットワークの管理方法。
【請求項４】
上記通信ネットワークに接続された外部システムからの要求に応じて上記通信パスの変更をする際、
上記管理システムは自動的に上記設定ポリシを適用することを特徴とする、
請求項１記載の通信ネットワークの管理方法。
【請求項５】
上記管理システムは、上記第１のサービスに確保する帯域の設定に変更があった場合に、
当該変更により変化した余りの帯域が、上記第２のサービス内のユーザ間で等しい比率になるように再度上記通信パスを分散し、設定し直すことを特徴とする、
請求項３記載の通信ネットワークの管理方法。
【請求項６】
上記管理システムは、
各サービスの経路をユーザ収容する前に検索し、事前に設定しておき、ユーザの収容の設定要求があった場合に、上記通信パスに新規にユーザを収容することを特徴とする、
請求項１記載の通信ネットワークの管理方法。
【請求項７】
複数の上記通信パスの障害を検出した際、上記通信装置は上記第１のサービスに関わる通信パスの障害を優先的に上記管理システムに通知することを特徴とする、
請求項１記載の通信ネットワークの管理方法。
【請求項８】
前記障害通知を受信した上記管理システムは、上記第１のサービスの障害通知を優先的に処理し、折返し試験を自動的に実行する、または、折返し試験の実行をオペレータに促すことを特徴とする、
請求項７記載の通信ネットワークの管理方法。
【請求項９】
通信ネットワークを構成する複数の通信装置に対して、ユーザに対して帯域を保証する第１のサービスのための通信パスと、ユーザに対して帯域を保証しない第２のサービスのための通信パスを設定し、上記通信ネットワーク内に上記第１及び第２のサービスのための通信パスを共存させる、通信ネットワーク管理システムであって、
上記通信ネットワーク管理システムは、
上記第１のサービスのための新規の通信パス設定要求があった場合には、
上記保証帯域分の空き帯域が存在する経路から選ばれた経路に、上記新規の通信パスを設定する第１の設定ポリシを適用し、
上記第２のサービスのための新規の通信パス設定要求があった場合には、
上記第２のサービスのユーザあたりの空き帯域に基づいて選ばれた経路に、上記新規の通信パスを設定する第２の設定ポリシを適用する、
通信ネットワーク管理システム。
【請求項１０】
上記第１の設定ポリシは、
上記保証帯域分の空き帯域が存在する経路から、空き領域が最小あるいは所定閾値以下の経路を選び、上記新規の通信パスを設定し、
上記第２の設定ポリシは、
上記第２のサービスのユーザあたりの空き帯域が最大あるいは所定閾値以上の経路を選び、上記新規の通信パスを設定する、
請求項９記載の通信ネットワーク管理システム。
【請求項１１】
上記ユーザを特定する識別子と、上記ユーザに対して提供されるサービスのＳＬＡ種別と、上記ＳＬＡ種別に適用される前記設定ポリシを、関連付けて記憶するデータを保持する、
請求項９記載の通信ネットワーク管理システム。
【請求項１２】
経路を構成する複数の通信装置と、上記複数の通信装置にユーザの利用に供する通信パスを設定する管理システムを有する通信ネットワークであって、
上記管理システムは、前記ユーザの利用に供するため、ＳＬＡの異なる第１のサービスのための通信パスと、第２のサービスのための通信パスを設定し、
上記第１のサービスに用いる通信パスを設定する場合には、上記第１のサービスに用いる通信パスが上記ネットワーク上の特定の経路に集約されるように設定し、
上記第２のサービスに用いる通信パスを設定する場合には、上記第２のサービスに用いる通信パスが上記ネットワーク上の経路に分散されるように設定することを特徴とする、
通信ネットワーク。
【請求項１３】
上記第１のサービスは、稼働率および帯域が保証されるサービスであり、
上記第１のサービスが提供される複数のユーザのために用いられる複数の通信パスの、上記ネットワーク上の送信ポートと宛先ポートが同一の場合、同一の経路に上記複数の通信パスを設定することを特徴とする、
請求項１２記載の通信ネットワーク。
【請求項１４】
上記第２のサービスは、ベストエフォート型のサービスであり、
上記第１のサービスに用いる通信パスが使用している通信帯域を除外した空き帯域の、上記第２のサービスのユーザ当たりの割り当てが均等になるように、上記第２のサービスに用いる通信パスを設定することを特徴とする、
請求項１２記載の通信ネットワーク。
【請求項１５】
上記通信装置は上記通信パスの障害を管理する障害管理部を有し、
上記障害管理部は、
障害が発生した通信パスが、上記第１のサービスに用いる通信パスか、上記第２のサービスに用いる通信パスか、により、障害対応処理の優先度を変更する、
請求項１２記載の通信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信システムに関し、更に詳しくは、複数の異なるサービスを収容する通信システムに関し、特にＳＬＡ保証が可能なパケット通信システム及び通信装置に関する。
【背景技術】
【０００２】
これまでの通信ネットワークは、提供される通信サービス毎に独立に構築されてきた。これは、各サービスで要求される品質が異なるため、ネットワークの構築や保守の方法がサービス毎に大きく異なっていたためである。例えば、国防や金融などのミッションクリティカルな業務に使用される専用線に代表されるビジネスユーザ向け通信サービスでは、１００％の通信帯域の保証や、１年の稼働率として例えば９９．９９%以上が要求される。【０００３】
一方、有線や携帯電話でのインタネットアクセスなどの一般消費者向け通信サービスでは、保守作業のための数時間のサービス断は許容されるが、急増するトラヒックを効率よく、そしてユーザ間で公平に収容することが求められる。【０００４】
通信事業者は、このような通信品質（帯域や遅延など）保証や稼働率保証などを規定したＳｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ（ＳＬＡ）をユーザと結び、通信サービスを提供している。ＳＬＡを満たせない場合、通信事業者は料金の減額や補償金などが求められるため、ＳＬＡ保証は非常に重要である。【０００５】
ＳＬＡ保証する上で最も重要な内容は、帯域や遅延などの通信品質である。通信帯域や遅延を保証するためには、ネットワーク中で要求値を満たせる経路を検索し、各ユーザやサービスに割り当てる必要がある。従来の通信システムは、ダイクストラ（Ｄｉｊｋｓｔｒａ）アルゴリズムのように、経路上のリンクのコストを合計して、合計値が最小である経路または最大である経路を選択する経路計算方法が採用されている。ここで、通信帯域や遅延は、経路上の各リンクのコストに変換され、計算される。【０００６】
この経路計算方法によれば、例えば、リンクの物理的帯域をリンクのコストとして表し、経路上のリンクのコストの合計値を最大にする経路または最小にする経路を計算することによって、パケット通信のトラフィックをより多く収容することのできる経路が計算される。しかし、この経路計算方法の場合、経路上のリンクのコストの合計値のみを考慮しているため、１つのリンクのコストが極端に小さいまたは大きい場合、当該リンクがボトルネックとなってトラヒックが滞るなどの問題が発生する。これに対し、経路上のリンクのコストの合計値のみを考慮するのではなく、経路上の各リンクのコストの大小にも着目することで、問題を解決するダイクストラの改良方法がある（特許文献１）。本方法を用いることで、ボトルネックを回避し、ＳＬＡ保証が可能なパスを検索することが可能となる。【０００７】
続いて、ＳＬＡの中で稼働率に関しては、保守性に強く依存している。ＳＬＡに稼働率が含まれている専用線サービスなどは、全ての通信装置が通信経路の障害を検出するＯｐｅｒａｔｉｏｎ  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ  ａｎｄ  Ｍａｉｎｔａｉｎａｎｃｅ（ＯＡＭ）ツールを有し、短時間で故障発生を検出し、事前に準備した代替経路に自動的に切替える。この代替経路も故障するような多重障害の場合は、障害が発生した経路に対して折返し試験などの接続検証ＯＡＭツールを用いることで、物理的な故障位置を特定し、部品交換などの保守作業が実施することで、如何なる場合においても稼働率を保証できる。【０００８】
しかし、近年通信ネットワークが汎用化し、利益の源泉がサービスやアプリケーション提供事業者に移っており、通信サービスを提供する通信事業者の収益性は頭打ちになりつつある。このため、通信キャリアは、現状の通信サービスの提供コストの削減と、通信サービスに新たな価値を付加することによる収益性の改善を試みている。そこで、様々な通信サービスを提供する通信事業者は、従来のようなサービス独立のネットワーク構築ではなく、各サービスを統合収容するネットワークにより、装置共有によるサービス提供コスト低減を図っている。さらに、従来は数時間〜数か月を要していたサービス開通やＳＬＡ変更によるネットワーク変更を数秒〜数分に短縮することにより、ユーザやアプリケーション提供事業者からの要求に応じたタイムリーな最適ネットワーク提供で収入増を狙っている。【０００９】
このようなサービスを統合するネットワークを構築するためには、ネットワークを論理的に仮想化し、物理的な回線や通信装置に多重することが必須となる。そのための技術として、Ｍｕｌｔｉｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ（ＭＰＬＳ）をはじめとしたＶｉｒｔａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ（ＶＰＮ）技術が存在する。【００１０】
このようなＶＰＮ技術を使用して複数のサービスを一つのネットワークに収容する場合、各サービスとそのユーザを論理的なパスとしてネットワークに収容する。例えば、ＭＰＬＳにイーサネット（登録商標）を収容する場合、イーサネットの各ユーザやサービスをＰｓｕｄｏ  Ｗｉｒｅ（ＰＷ）にマッピングし、それをＭＰＬＳネットワークのパス（ＭＰＬＳパス）にさらにマッピングする。【００１１】
ＭＰＬＳパスは、パスＩＤで指定されたＭＰＬＳネットワーク中の経路であり、イーサネットからＭＰＬＳ装置に到着したパケットは、このパスＩＤを含むＭＰＬＳラベルでカプセル化をされた後、ＭＰＬＳネットワーク中のこの経路に沿って転送される。このため、各ユーザやサービスにどのパスＩＤを割り当てるかによって、ＭＰＬＳネットワーク中での経路が一意に決定されると共に、物理回線に複数の論理パスを収容することで、複数のサービスを多重することが可能となっている。このサービス毎の仮想的なネットワークを仮想ネットワークと呼ぶ。【００１２】
ＭＰＬＳでは保守性を向上するＯＡＭツールが規定されており、論理パスの始点と終点でＯＡＭパケットを定期的に送受信するＯＡＭツール（非特許文献１）により障害発生を論理パス毎に高速検出することで、代替経路への高速な切替が可能である。【００１３】
さらに、論理パスの始点と終点で検出された障害は、通信装置からネットワーク管理システムを介してオペレータに通知される。その結果、オペレータは障害が発生した論理パス上の障害位置を特定するため、論理パス上の中継地点に対して折返し用のＯＡＭパケットを送信する折返し試験ＯＡＭツール（非特許文献２）を実施する。これにより、論理パス上の障害箇所から物理的な障害箇所が特定されるため、部品効果などの保守作業が可能である。【００１４】
さらに、上記のように複数サービスを統合する仮想ネットワークが動的に変更される環境において、各サービスのＳＬＡを保証するためには、従来のようにオペレータ（人）を介した設定や運用では対応が困難である。そこで、帯域や遅延などの通信品質に関するポリシをサービス毎に規定し、ネットワークを管理するサーバ（ネットワーク管理システム）においてそれに応じた経路を計算し、自動的に論理パスの設定を行うことが考えられる（特許文献２）。これにより、オペレータを介すことなく各サービスの通信品質を保証可能なネットワークの構築や変更が可能となる。【００１５】
以上のように、従来の通信システムは、稼働率に関してはＯＡＭツールにより保証可能としてきたため、経路計算する際には帯域や遅延などの通信品質のみが考慮されてきた。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２００１−２４４９７４号公報
【特許文献２】特開２００４−２３６０３０号公報
【非特許文献】
【００１７】
【非特許文献１】ＩＥＴＦ  ＲＦＣ６４２８（Ｐｒｏａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｖｅｒｉｆｉｃａｔｉｏｎ, Ｃｏｎｔｉｎｕｉｔｙ Ｃｈｅｃｋ, ａｎｄ Ｒｅｍｏｔｅ Ｄｅｆｅｃｔ Ｉｎｄｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ ＭＰＬＳ Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｆｉｌｅ）
【非特許文献２】ＩＥＴＦ  ＲＦＣ６４２６（ＭＰＬＳ Ｏｎ-Ｄｅｍａｎｄ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｖｅｒｉｆｉｃａｔｉｏｎ ａｎｄ Ｒｏｕｔｅ Ｔｒａｃｉｎｇ）
【発明の概要】
【発明が解決しようとする課題】
【００１８】
しかしながら、複数サービスを統合する仮想ネットワークにおいて、通信品質のみを考慮して論理パスの経路計算してしまうと、ネットワーク全体のリソースを無駄なく利用するようにトラヒックを収容することが優先されるため、論理パスは仮想ネットワーク全体に分散して設定されてしまう。【００１９】
インタネットなどを利用する一般消費者の数は、通信品質に加え稼働率の保証が必要なビジネスユーザの数に比べて２ケタ以上大きいため、障害発生時に影響を受けるユーザ数が膨大となる。このため、稼働率の保証が必要なビジネスユーザ用の論理パスで検出された障害を迅速に発見し、折り返し試験を行うことが困難であった。この結果、故障個所の特定とそれによる部品交換がなどの保守作業にかかる時間が増大し、稼働率を保証できなくなってしまうという課題があった。
【課題を解決するための手段】
【００２０】
上記課題を解決するため、本発明の一側面であるパケット通信システムは、複数の通信装置とそれらの管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する通信システムである。このシステムにおいて、管理システムが通信パスを設定する際、保守性を向上するためにネットワーク上一部でも同じ経路を共有するパス同士を集約するものと、トラフィックを効率的に収容するために経路をネットワーク全体に分散するもの、など複数のパス設定ポリシをサービスに応じて変更することを特徴とする。【００２１】
さらに具体的な詳細な例としては、本発明のパケット通信システムに収容するサービスのうちパスを集約するサービスは、ユーザまたはサービス毎にある一定の帯域を確保するサービスであって、同一経路に集約されたサービスの帯域の総和がパス上のいずれかの回線帯域を超過した場合、同一経路に集約されたサービスの帯域の総和がパス上のいずれかの回線帯域も超過しない他の経路を検索して設定するものである。また、パスを分散するサービスは、経路上の各回線帯域からパスを集約するサービス向けに確保された帯域を差し引いた余りの帯域に応じてパスを分散するものである。【００２２】
さらに具体的な詳細な例としては、本発明のパケット通信システムは、インタネット上のユーザや、データセンタなどの、接続された外部システムから要求に応じてパスの変更をする際、管理システムは自動的にパス設定ポリシを適用する。【００２３】
さらに具体的な詳細な例としては、本発明のパケット通信システムの通信装置は、複数のパスの障害を検出した際、稼働率の保証が必要なサービスに関わるパスの障害を優先的に管理システムに通知する。また、管理システムは、稼働率の保証が必要なサービスの障害通知を優先的に処理し、折返し試験を自動的に実行する、または折返し試験の実行をオペレータに促すことを特徴とする。【００２４】
本発明の他の側面は、複数の通信装置で構成される通信ネットワークと管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する、通信ネットワークの管理方法である。この管理方法では、管理システムが通信パスを設定する際、稼働率の保証が必要な第１のサービスのために、通信ネットワーク上一部でも同じ経路を共有する通信パス同士を集約する第１の設定ポリシと、稼働率の保証をしない第２のサービスのために、使用する経路を通信ネットワーク全体に分散するように通信パスを設定する第２の設定ポリシを有し、サービスの種類に応じて設定ポリシを変更することを特徴とする。【００２５】
本発明のさらに他の側面は、通信ネットワークを構成する複数の通信装置に対して、ユーザに対して帯域を保証する第１のサービスのための通信パスと、ユーザに対して帯域を保証しない第２のサービスのための通信パスを設定し、通信ネットワーク内に第１及び第２のサービスのための通信パスを共存させる、通信ネットワーク管理システムである。この通信ネットワーク管理システムは、第１のサービスのための新規の通信パス設定要求があった場合には、保証帯域分の空き帯域が存在する経路から選ばれた経路に、新規の通信パスを設定する第１の設定ポリシを適用し、第２のサービスのための新規の通信パス設定要求があった場合には、第２のサービスのユーザあたりの空き帯域に基づいて選ばれた経路に、新規の通信パスを設定する第２の設定ポリシを適用する。【００２６】
より具体的な構成例を挙げれば、第１の設定ポリシは、保証帯域分の空き帯域が存在する経路から、空き領域が最小の経路を選び、新規の通信パスを設定する。また、第２の設定ポリシは、第２のサービスのユーザあたりの空き帯域が最大の経路を選び、新規の通信パスを設定する。このようなポリシに従えば、第１のサービスのための通信パスは、なるべく経路を共用するように設定され、第２のサービスのための通信パスは、なるべくユーザ間の利用可能帯域が均一になるように設定される。【００２７】
本発明のさらに他の側面は、経路を構成する複数の通信装置と、複数の通信装置にユーザの利用に供する通信パスを設定する管理システムを有する通信ネットワークである。この通信ネットワークでは、管理システムは、ユーザの利用に供するため、ＳＬＡの異なる第１のサービスのための通信パスと、第２のサービスのための通信パスを設定する。そして、第１のサービスに用いる通信パスを設定する場合には、第１のサービスに用いる通信パスがネットワーク上の特定の経路に集約されるように設定し、第２のサービスに用いる通信パスを設定する場合には、第２のサービスに用いる通信パスが上記ネットワーク上の経路に分散されるように設定することを特徴とする。【００２８】
より具体的な構成例を例示すれば、第１のサービスは、稼働率および帯域が保証されるサービスであり、第１のサービスが提供される複数のユーザのために用いられる複数の通信パスの、ネットワーク上の送信ポートと宛先ポートが同一の場合、同一の経路にこれらの複数の通信パスを設定する。また、第２のサービスは、ベストエフォート型のサービスであり、第１のサービスに用いる通信パスが使用している通信帯域を除外した空き帯域の、第２のサービスのユーザ当たりの割り当てが均等になるように、第２のサービスに用いる通信パスを設定することを特徴とする。
【発明の効果】
【００２９】
ＳＬＡの異なる複数サービスを収容する通信ネットワークを構成することができ、通信事業者のサービス統合による提供コスト低減と、タイムリーな最適ネットワーク提供による利便性の向上を実現できる。
【図面の簡単な説明】
【００３０】
【図１】本発明の通信システムの構成の一実施例を示すブロック図。
【図２】本発明のネットワーク管理システムの一実施例を示すブロック図。
【図３】図２のネットワーク管理システムが備えるパス構築ポリシテーブルの一例を示す表図。
【図４】図２のネットワーク管理システムが備えるユーザ管理テーブルの一例を示す表図。
【図５】図２のネットワーク管理システムが備える接続先管理テーブルの一例を示す表図。
【図６】図２のネットワーク管理システムが備えるパス構成テーブルの一例を示す表図。
【図７】図２のネットワーク管理システムが備えるリンク管理テーブルの一例を示す表図。
【図８】本実施例の通信システムに流れるイーサネット通信パケットのフォーマット例を示す表図。
【図９】本実施例の通信システムに流れるＭＰＬＳ通信パケットのフォーマット例を示す表図。
【図１０】本実施例の通信システムに流れるＭＰＬＳ通信のＯＡＭパケットのフォーマット例を示す表図。
【図１１】実施例の通信装置ＮＤ＃ｎの構成例を示すブロック図。
【図１２】通信装置ＮＤ＃ｎの入力パケットに付加される装置内ヘッダのフォーマット例を示す表図。
【図１３】図１１のネットワークインタフェースボード（１０−ｎ）が備えるコネクションＩＤ決定テーブルの例を示す表図。
【図１４】図１１のネットワークインタフェースボード（１０−ｎ）が備える入力ヘッダ処理テーブルの例を示す表図。
【図１５】図１１のネットワークインタフェースボード（１０−ｎ）が備えるラベル設定テーブルの例を示す表図。
【図１６】図１１のネットワークインタフェースボード（１０−ｎ）が備える帯域監視テーブルの例を示す表図。
【図１７】図１１のスイッチ部１１が備えるパケット転送テーブルの例を示す表図。
【図１８】図１１の入力パケット処理部１０３が実行する入力パケット処理Ｓ１００の一例を示すフローチャート。
【図１９】図１１のネットワークインタフェースボード（１０−ｎ）が備える障害管理テーブルの例を示す表図。
【図２０】実施例の通信システムが実行するオペレータからのネットワーク設定シーケンスＳＱ１００の一例を示すシーケンス図。
【図２１】実施例の通信システムが実行するユーザ端末からのネットワーク設定シーケンスＳＱ２００の一例を示すシーケンス図。
【図２２】実施例の通信システムが実行するデータセンタからのネットワーク設定シーケンスＳＱ３００の一例を示すシーケンス図。
【図２３】実施例の通信システムが実行する障害箇所特定シーケンスＳＱ４００の一例を示すシーケンス図。
【図２４】図２のネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２００の一例のフローチャート。
【図２５】図２のネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２００の一例のフローチャートの続き。
【図２６】図１１のネットワークインタフェースボード（１０−ｎ）が実行する障害管理ポーリング処理Ｓ３００の一例のフローチャート。
【図２７】図１１の装置管理部１２が実行する障害通知キュー読出し処理Ｓ４００のフローチャート。
【図２８】本発明の実施例が適用される他の通信システムのネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２８００の一例のフローチャート。
【図２９】本発明の実施例が適用される他の通信システムのネットワーク管理システムが実行するサービスに応じたパス検索処理Ｓ２８００の一例のフローチャートの続き。
【図３０】本発明の実施例が適用される他の通信システムが実行するオペレータからのネットワーク事前設定シーケンスＳＱ１０００の一例のシーケンス図。
【図３１】本発明の実施例のネットワーク管理システムが実行する事前パス検索処理Ｓ５００の一例のフローチャート。
【図３２】本発明の実施例のネットワーク管理システムが備えるパス構成テーブルの他の一例を示す表図。
【発明を実施するための形態】
【００３１】
以下、本発明の実施例について、図面を参照して説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
【００３２】
以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。
【００３３】
本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
【００３４】
図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。
【実施例１】
【００３５】
図１は、本発明の通信システムの一例を示す。このシステムは、複数の通信装置とそれらの管理システムを備え、管理システムから設定した通信パスを介して複数の通信装置間でパケットを転送する通信システムである。ここで、管理システムが通信パスを設定する際、稼働率の保証が必要なサービスのため、迅速に故障個所を特定する目的でネットワーク上一部でも同じ経路を共有するパス同士を集約するものと、稼働率の保証の必要がなく、多数のユーザの大量のトラヒックを収容するサービスのため、多数のユーザで公平にトラヒックを収容する目的で経路をネットワーク全体に分散するもの、など複数のパス設定ポリシをサービスに応じて変更することができる。【００３６】
本実施例の通信装置ＮＤ＃１〜ｎは、ユーザ端末ＴＥ１〜ｎを収容するアクセス装置ＡＥ１〜ｎと、データセンタＤＣまたはインタネットＩＮの間を接続する、通信事業者のネットワークＮＷを構成する。本ネットワークＮＷの通信装置ＮＤ＃１〜ｎのうち、エッジ装置と中継装置の装置構成などは同一でよく、事前設定や入力されるパケットに応じてエッジ装置として動作する場合と中継装置として動作する場合があるのみである。図１では、ネットワークＮＷの位置から便宜上通信装置ＮＤ＃１およびＮＤ＃ｎがエッジ装置動作、通信装置ＮＤ＃２、ＮＤ＃３、ＮＤ＃４およびＮＤ＃５が中継装置動作しているものとする。【００３７】
各通信装置ＮＤ＃１〜ｎは、管理用ネットワークＭＮＷでネットワーク管理システムＮＭＳに接続される。本通信事業者の通信システムと、ユーザやアプリケーション提供事業者の管理を連携させるため、ユーザからの要求を処理するサーバが設置されているインタネットＩＮや、アプリケーション提供事業者が有するデータセンタＤＣも、管理用ネットワークＭＮＷに接続されている。【００３８】
各論理パスはネットワーク管理システムＮＭＳにより設定（図２０のＳＱ１００で後述する）される。ここではパスＰＴＨ＃１およびＰＴＨ＃２が中継装置ＮＤ＃２およびＮＤ＃３を経由、パスＰＴＨ＃ｎが中継装置ＮＤ＃４およびＮＤ＃５を経由するように設定されており、いずれもエッジ装置ＮＤ＃１とエッジ装置ＮＤ＃ｎ間のパスである。図１の例では、パスＰＴＨ#１はビジネスユーザ用通信サービス向けの帯域が保証されるパスのため、ネットワーク管理システムＮＭＳが、パスＰＴＨ＃１に対して、５００Ｍｂｐｓを割り当てているものとする。これは、ユーザ端末ＴＥ１およびＴＥ２を使用しているビジネスユーザが、それぞれ２５０Ｍｂｐｓの通信サービスを契約しているため、そのユーザが収容されるパスＰＴＨ＃１はその積算値である５００Ｍｂｐｓが確保される。一方、一般ユーザ用のユーザ端末ＴＥ３、ＴＥ４およびＴＥｎが使用するパスＰＴＨ＃２およびＰＴＨ＃ｎは、一般消費者用通信サービス向けでありベストエフォートで運用されるため、帯域は確保されず、エッジ装置ＮＤ＃１およびＮＤ＃ｎ間の接続性のみが確保されている。【００３９】
以上のように、図１の通信システムにおいては、ＳＬＡ保証レベルの異なる、ビジネスユーザ用途の通信パスと、個人ユーザ用途の通信パスが、同一の通信装置を経路として用いることを許容している。【００４０】
このようなパスの設定やその変更は、通常ネットワーク管理者であるオペレータＯＰが、監視端末ＭＴを介してネットワーク管理システムＮＭＳに指示を与えることで実行される。しかし、現在の通信事業者はユーザやアプリケーション提供事業者からの要求に応じて最適なネットワークを提供することで新たな収入を得ようと試みており、インタネットＩＮやデータセンタＤＣからもオペレータと同様に、パスの設定やその変更のための指示が到来する。【００４１】
図２は、ネットワーク管理システムＮＭＳの構成の一例を示す。【００４２】
ネットワーク管理システムＮＭＳは通常汎用的なサーバで実現されるため、その構成はプログラムを実行するＭｉｃｒｏ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＭＰＵ）ＮＭＳ−ｍｐｕと、当該プログラムをインストールしたり、プログラムの処理のために必要な情報を保持するＨａｒd Ｄｉｓｋ  Ｄｒｉｖｅ（ＨＤＤ）ＮＭＳ−ｈｄｄと、ＭＰＵ：ＮＭＳ-ｍｐｕの処理のためにこれらの情報を一時的に保持するメモリＮＭＳ−ｍｅｍと、オペレータＯＰが操作する監視端末ＭＴとの信号をやりとする入力部ＮＭＳ−ｉｎと出力部ＮＭＳ−ｏｕｔと、管理用ネットワークＭＮＷと接続するＮｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ（ＮＩＣ）ＮＭＳ−ｎｉｃとから構成される。【００４３】
さらに、ＨＤＤ：ＮＭＳ−ｈｄｄには、本実施例でネットワークＮＷを管理するために必要な情報として、パス構築テーブルＮＭＳ―ｔ１と、ユーザ管理テーブルＮＭＳ−ｔ２と、接続先管理テーブルＮＭＳ−ｔ３と、パス構成テーブルＮＭＳ−ｔ４と、リンク管理テーブルＮＭＳ−ｔ５とが保存されている。これらの情報は、オペレータＯＰから入力、変更されると共に、ネットワークＮＷの状態の変化やユーザ、アプリケーション提供事業者からの要求に応じて変更される。【００４４】
図３に、パス構築ポリシテ−ブルＮＭＳ−ｔ１の例を示す。パス構築ポリシテ−ブルＮＭＳ−ｔ１は、ＳＬＡ種別ＮＭＳ−ｔ１１を検索キーとして、通信品質ＮＭＳ−ｔ１２と、稼働率保証ＮＭＳ−ｔ１３と、パス構築ポリシＮＭＳ−ｔ１４とを示すテーブルエントリを検索するためのものである。【００４５】
ここで、ＳＬＡ種別ＮＭＳ−ｔ１１は、ビジネスユーザ向けの通信サービスや一般消費者向けの通信サービスを示し、ＳＬＡ種別ＮＭＳ−ｔ１１に応じて、通信品質ＮＭＳ−ｔ１２の保証の仕方（帯域保証や公平利用）や、稼働率保証ＮＭＳ−ｔ１３の有無やその基準値、そして集約や分散などのパスの構築ポリシＮＭＳ−ｔ１４が検索可能である。以降、ビジネスユーザ向け通信サービスを保証型サービス、一般消費者向け通信サービスを公平型サービスと称する。本テーブルの使用方法の詳細は後述する。【００４６】
図４に、ユーザ管理テ−ブルＮＭＳ−ｔ２の例を示す。ユーザ管理テ−ブルＮＭＳ−ｔ２は、ユーザＩＤ：ＮＭＳ−ｔ２１を検索キーとして、ＳＬＡ種別ＮＭＳ−ｔ２２と、収容パスＩＤ：ＮＭＳ−ｔ２３と、契約帯域ＮＭＳ−ｔ２４と、接続先ＮＭＳ−ｔ２５とを示すテーブルエントリを検索するためのものである。【００４７】
ここで、ユーザＩＤ：ＮＭＳ−ｔ２１は、ユーザアクセス装置ＡＥｎを介して接続された各サービス端末ＴＥｎを識別するもので、ユーザＩＤ：ＮＭＳ−ｔ２１毎に、ＳＬＡ種別ＮＭＳ−ｔ２２や、当該ユーザ端末ＴＥｎの収容パスＩＤ：ＮＭＳ−ｔ２３、ユーザ端末ＴＥｎ毎に割り当てられる契約帯域ＮＭＳ−ｔ２４、そしてそのユーザ端末ＴＥｎの接続先ＮＭＳ−ｔ２５が検索可能である。さらに、ここで収容パスＩＤ：ＮＭＳ−ｔ２３には、当該ユーザを収容するパスとして後述するパス構成テーブルＮＭＳ−ｔ４の検索キーであるパスＩＤ：ＮＭＳ−ｔ４１のいずれかが設定される。本テーブルの使用方法の詳細は後述する。【００４８】
図５に、接続先管理テ−ブルＮＭＳ−ｔ３の例を示す。接続先管理テ−ブルＮＭＳ−ｔ３は、接続先ＮＭＳ−ｔ３１と接続ポートＩＤ：ＮＭＳ−ｔ３２の組合せを検索キーとして、収容装置ＩＤ：ＮＭＳ−ｔ３３と、収容ポートＩＤ：ＮＭＳ−ｔ３４とを示すテーブルエントリを検索するためのものである。【００４９】
ここで、接続先ＮＭＳ−ｔ３１と接続ポートＩＤ：ＮＭＳ−ｔ３２は、ネットワークＮＷにとってトラヒックの送受信元となるポイントを示し、それらが収容されているネットワークＮＷのポイントである収容装置ＩＤ：ＮＭＳ−ｔ３３と収容ポートＩＤ：ＮＭＳ−ｔ３４が検索可能である。本テーブルの使用方法の詳細は後述する。【００５０】
図６に、パス構成テ−ブルＮＭＳ−ｔ４を示す。パス構成テ−ブルＮＭＳ−ｔ４は、パスＩＤ：ＮＭＳ−ｔ４１を検索キーとして、ＳＬＡ種別ＮＭＳ−ｔ４２と、終端装置ＩＤ：ＮＭＳ−ｔ４３と、経由装置ＩＤ：ＮＭＳ−ｔ４４と、経由リンクＩＤ：ＮＭＳ−ｔ４５と、ＬＳＰラベルＮＭＳ−ｔ４６、割当帯域ＮＭＳ−ｔ４７、収容ユーザＮＭＳ−ｔ４８とを示すテーブルエントリを検索するためのものである。【００５１】
ここで、パスＩＤ：ＮＭＳ−ｔ４１は、ネットワークＮＷ中のパスを統一的に識別するもので、実際にパケットに付与されるＬＳＰラベルとは異なり、通信の双方で同一となるような管理上の値である。このパスＩＤ：ＮＭＳ−ｔ４１毎に、ＳＬＡ種別ＮＭＳ−ｔ４２や、当該パスの終端装置ＩＤ：ＮＭＳ−ｔ４３と経由装置ＩＤ：ＮＭＳ−ｔ４４、経由リンクＩＤ：ＮＭＳ−ｔ４５、ＬＳＰラベルＮＭＳ−ｔ４６が設定されている。【００５２】
そして、当該パスのＳＬＡ種別ＮＭＳ−ｔ４２が保証型サービス（図６の例ではＳＬＡ＃１）を示す場合、収容ユーザＮＭＳ−ｔ４８に記載されている全ユーザの契約帯域の積算値が割当帯域ＮＭＳ−ｔ４７に設定されている。【００５３】
一方、当該パスが公平型サービス（図６の例ではＳＬＡ＃２）のパスであれば、収容ユーザＮＭＳ−ｔ４８として当該パスに収容されている全ユーザが同様に設定され、割当帯域ＮＭＳ−ｔ４７には無効値が設定されている。【００５４】
さらに、上記ＬＳＰラベルＮＭＳ−ｔ４６は、実際にパケットに付与されるＬＳＰラベルであり、通信の向き毎に異なる値が設定される。一般的に、通信装置ＮＤ＃ｎを中継する毎に異なるＬＳＰラベルを設定することも可能であるが、本実施例では簡単のため、中継する毎にＬＳＰラベルを変更せず、ネットワークのエッジ装置間で同一のＬＳＰラベルを用いるものとする。本テーブルの使用方法の詳細は後述する。【００５５】
図７に、リンク管理テ−ブルＮＭＳ−ｔ５を示す。リンク管理テ−ブルＮＭＳ−ｔ５は、リンクＩＤ：ＮＭＳ−ｔ５１を検索キーとして、空き帯域ＮＭＳ−ｔ５２と、透過非優先ユーザ数ＮＭＳ−ｔ５３とを示すテーブルエントリを検索するためのものである。【００５６】
ここで、リンクＩＤ：ＮＭＳ−ｔ５１は、各通信装置間のポート同士の接続関係を示すもので、各リンクの両端の通信装置ＮＤ＃ｎのＩＤとそのポートＩＤの組合せになっている。例えば、通信装置ＮＤ＃１のポートＰＴ＃２と、通信装置ＮＤ＃３のポートＰＴ＃４が接続され、一つのリンクを形成している場合のリンクＩＤ：ＮＭＳ−ｔ５１は「ＬＮＫ＃Ｎ１−２−Ｎ３−４」となる。ここで、同じリンクＩＤで構成されているパス、すなわち送信ポートと宛先ポートの組合せが同一のパスは、同一経路のパスである。【００５７】
当該リンクＩＤ：ＮＭＳ−ｔ５１毎に、当該リンクの物理帯域から、当該リンクを経由するパスの契約帯域の総和を減算したものが空き帯域：ＮＭＳ−ｔ５２として保持され、当該リンクを経由する公平型サービスのパス上のユーザ数が透過非優先ユーザ数ＮＭＳ−ｔ５３として保持され、検索可能である。本テーブルの使用方法の詳細は後述する。【００５８】
図８〜図１０で、本実施例で用いるパケットのフォーマットを説明する。【００５９】
図８は、本実施例において、エッジ装置ＮＤ＃１およびＮＤ＃ｎがアクセス装置ＡＥ＃１〜ｎ、データセンタＤＣおよびインタネットＩＮから受信する通信パケット４０のフォーマットを示す。【００６０】
通信パケット４０は、宛先ＭＡＣアドレス４０１、送信元ＭＡＣアドレス４０２、ＶＬＡＮタグ４０３、後続ヘッダの種類を示すタイプ値４０４からなるＭＡＣヘッダと、ペイロード部４０５と、パケットチェックシーケンス（ＦＣＳ）４０６とからなる。【００６１】
宛先ＭＡＣアドレス４０１と送信元ＭＡＣアドレス４０２には、ユーザ端末ＴＥ１〜ｎ、データセンタＤＣまたはインタネットＩＮのいずれかに付与されたＭＡＣアドレスが格納される。ＶＬＡＮタグ４０３は、フロー識別子となるＶＬＡＮ ＩＤの値（ＶＩＤ♯）と優先度を示すＣｏＳ値が格納されている。【００６２】
図９は、各通信装置ＮＤ＃ｎがネットワークＮＷ内で送受信する通信パケット４１のフォーマットを示す。本実施例では、ＭＰＬＳを用いてイーサネットを収容する際に使用されるＰｓｕｄｏ  Ｗｉｒｅ（ＰＷ）フォーマットを想定している。【００６３】
通信パケット４１は、宛先ＭＡＣアドレス４１１、送信元ＭＡＣアドレス４１２、後続ヘッダの種類を示すタイプ値４１３からなるＭＡＣヘッダと、ＭＰＬＳラベル（ＬＳＰラベル）４１４−１と、ＭＰＬＳラベル（ＰＷラベル）４１４−２と、ペイロード部４１５と、ＦＣＳ：４１６とからなる。【００６４】
ＭＰＬＳラベル４１４−１および４１４−２は、パス識別子となるラベル値と優先度を示すＴＣ値が格納されている。【００６５】
ペイロード部４１５は、図４に示した通信パケット４０のイーサパケットがカプセル化されている場合と、各通信装置ＮＤ＃ｎが生成したＯＡＭに関する情報が格納されている場合がある。本フォーマットは、ＭＰＬＳラベル２段を有しており、１段目のＭＰＬＳラベル（ＬＳＰラベル）４１４−１はネットワークＮＷ内のパスを指定する識別子であり、２段目のＭＰＬＳラベル（ＰＷラベル）４１４−２はユーザまたはＯＡＭパケットであることを識別するために用いられる。ここで、２段目のＭＰＬＳラベル４１４−２のラベル値が予約値である“１３”などを有している場合それはＯＡＭパケット、それ以外はユーザパケット（ペイロード４１５に通信パケット４０のイーサパケットがカプセル化されている）である。【００６６】
図１０は、通信装置ＮＤ＃ｎがネットワークＮＷ内で送受信するＯＡＭパケット４２のフォーマットを示す。【００６７】
ＯＡＭパケット４２は、宛先ＭＡＣアドレス４２１、送信元ＭＡＣアドレス４２２、後続ヘッダの種類を示すタイプ値４２３からなるＭＡＣヘッダと、通信パケット４１と同様の１段目のＭＰＬＳラベル（ＬＳＰラベル）４１４−１と、２段目のＭＰＬＳラベル（ＯＡＭラベル）４１４−３と、ＯＡＭ種別４２４と、ペイロード４２５と、ＦＣＳ４２６とからなる。【００６８】
上述した通り、２段目のＭＰＬＳラベル（ＯＡＭラベル）４１４−３は、図９の２段目のＭＰＬＳラベル（ＰＷラベル）４１４−２のラベル値が予約値である“１３”などを有している場合であり、ここではＯＡＭラベルと称しているが、上記２段目のＭＰＬＳラベル（ＰＷラベル）４１４−２とラベル値以外は同一である。さらに、ＯＡＭ種別４２４は、ＯＡＭパケットの種類を示す識別子であり、本実施例では障害監視パケットまたは折返し試験パケット（折返し要求パケットまたは折返し応答パケット）の識別子が格納される。ペイロード４２５は、ＯＡＭ専用の情報が格納されており、本実施例では、障害監視パケットの場合は終端装置ＩＤ、折返し要求パケットの場合は折返し装置ＩＤ、折返し応答パケットの場合は終端装置ＩＤが格納される。【００６９】
図１１は、通信装置ＮＤ＃ｎの構成を示す。通信装置ＮＤ＃ｎは、複数のネットワークインタフェースボード（ＮＩＦ）１０（１０−１〜１０−ｎ）と、これらのＮＩＦに接続されたスイッチ部１１、装置全体を管理する装置管理部１２からなる。【００７０】
各ＮＩＦ１０は、通信ポートとなる複数の入出力回線インタフェース１０１（１０１−１〜１０１−ｎ）を備え、これらの通信ポートを介して、その他の装置と接続されている。本実施例では、入出力回線インタフェース１０１は、イーサネット用の回線インタフェースとなっている。尚、入出力回線インタフェース１０１は、イーサネット用の回線インタフェースに限られない。【００７１】
各ＮＩＦ：１０−ｎは、これらの入出力回線インタフェース１０１に接続された入力パケット処理部１０３と、スイッチ部１１に接続された複数のＳＷインタフェース１０２（１０２−１〜１０２−ｎ）と、これらのＳＷインタフェースに接続された出力パケット処理部１０４と、ＯＡＭ関連の処理を行う障害管理部１０７と、ＮＩＦを管理するＮＩＦ管理部１０５と、各種設定を保持する設定レジスタ１０６とを有する。【００７２】
ここで、ＳＷインタフェース１０２−ｉは、入出力回線インタフェース１０１−ｉと対応しており、入出力回線インタフェース１０１−ｉで受信した入力パケットは、ＳＷインタフェース１０２−ｉを介してスイッチ部１１に転送される。また、スイッチ部１１からＳＷインタフェース１０２−ｉに振り分けられた出力パケットは、入出力回線インタフェース１０１−ｉを介して、出力回線に送出される。このため、入力パケット処理部１０３、出力パケット処理部１０４は、回線毎に独立な構造となっており、各回線のパケットが混ざり合うことはない。【００７３】
入出力回線インタフェース１０１−ｉは、入力回線から通信パケット４０または４１を受信すると、受信パケットに、図１２に示す装置内ヘッダ４５を付加する。【００７４】
図１２〜図１７で、通信装置ＮＤ＃ｎが保持する各テーブルと、装置内のパケットのフォーマットを説明する。【００７５】
図１２は、装置内ヘッダ４５の例を示す。装置内ヘッダ４５は、コネクションＩＤ：４５１と、受信ポートＩＤ：４５２と、優先度４５３と、パケット長４５４とを示す複数のフィールドとからなっている。【００７６】
図１１の入出力回線インタフェース１０１−ｉが、受信パケットに装置内ヘッダ４５を付加した時点では、設定レジスタ１０６から取得したポートのＩＤを受信ポートＩＤ：４５２に格納すると共に、本パケットの長さをカウントし、パケット長４５４として格納する。一方、コネクションＩＤ：４５１と優先度４５３は空欄となっている。このフィールドには、入力パケット処理部１０３によって有効値が設定される。【００７７】
入力パケット処理部１０３は、後述する入力パケット処理Ｓ１００を実施して、下記の各テ−ブル２１〜２４を参照し、各入力パケットの装置内ヘッダ４５にコネクションＩＤ：４５１および優先度４５３を追加するとともに、その他ヘッダ処理、帯域監視処理などが実施される。入力パケット処理Ｓ１００の結果、入力パケットは、ＳＷ  ＩＦ：１０２に回線毎に振り分けられ転送される。【００７８】
図１３に、コネクションＩＤ決定テ−ブル２１を示す。コネクションＩＤ決定テーブル２１は、入力ポートＩＤ：２１２と、ＶＬＡＮ ＩＤ：２１３との組合わせを検索キーとして、その登録アドレスであるコネクションＩＤ：２１１を取得するためのものである。通常このようなテーブルは、ＣＡＭ（Ｃｏｎｔｅｎｔ−ａｄｄｒｅｓｓａｂｌｅ  ｍｅｍｏｒｙ）で構成される。ここで、コネクションＩＤ：２１１は、本通信装置ＮＤ＃ｎにおいて各コネクションを特定するＩＤであり、双方向で同じＩＤを使用する。本テーブルの使用方法の詳細は後述する。【００７９】
図１４に、入力ヘッダ処理テ−ブル２２を示す。入力ヘッダ処理テーブル２２は、コネクションＩＤ：２２１を検索キーとして、ＶＬＡＮタグ処理２２２と、ＶＬＡＮタグ２２３とを示すテーブルエントリを検索するためのものである。ここで、ＶＬＡＮタグ処理２２２は、入力パケットに対するＶＬＡＮタグ処理を指定し、それに必要なタグ情報がＶＬＡＮタグ２２３に設定される。本テーブルの使用方法の詳細は後述する。【００８０】
図１５に、ラベル設定テ−ブル２３を示す。ラベル設定テ−ブル２３は、コネクションＩＤ：２３１を検索キーとして、ＬＳＰラベル２３２と、ＰＷラベル２３３とを示すテーブルエントリを検索するためのものである。本テーブルの使用方法の詳細は後述する。【００８１】
図１６に、帯域監視テ−ブル２４を示す。帯域監視テ−ブル２４は、コネクションＩＤ：２４１を検索キーとして、契約帯域２４２と、バケツの深さ２４３と、前回のトークン値２４４と、前回時刻２４５とを示すテーブルエントリを検索するためのものである。【００８２】
ここで、保証型サービスの場合、契約帯域２４２には、ユーザ毎の契約帯域と同値が設定され、一般的なトークンバケツアルゴリズムによって契約帯域内のパケットに関しては装置内ヘッダ４５の優先度４５３に高優先を上書きされ、契約帯域を超過したと判定されたパケットに関しては廃棄される。一方、公平型サービスの場合、契約帯域２４２には無効値が設定され、全パケットの装置内ヘッダ４５の優先度４５３に低優先が上書きされる。【００８３】
スイッチ部１１は、各ＮＩＦのＳＷインタフェース１０２−１〜１０２−ｎから入力パケットを受け取り、パケット転送テーブル２６から出力ポートＩＤと出力ラベルを特定し、対応するＳＷインタフェース１０２−iに、出力パケットとして転送する。この際、ＭＰＬＳラベル４１４−１の優先度を示すＴＣに従って、輻輳時には優先度の高いパケットを優先的に転送する。さらに、付与されているＭＰＬＳラベル（ＬＳＰラベル）４１４−１に出力ラベル２７６を上書きする。【００８４】
図１７にパケット転送テーブル２６を示す。パケット転送テーブル２６は、入力ポートＩＤ：２６１と入力ＬＳＰラベル２６２の組合せを検索キーとして、出力ポートＩＤ：２６３と出力ＬＳＰラベル２６４とを示すテーブルエントリを検索するためのものである。【００８５】
スイッチ部１１は、装置内ヘッダ４５の受信ポートＩＤ：４５１および入力パケットのＭＰＬＳラベル（ＬＳＰラベル）４１４−１のＬＳＰ  ＩＤを用いてパケット転送テーブル２６を検索し、出力先を決定する。【００８６】
各ＳＷインタフェース１０２が受信した出力パケットは、次々と出力パケット処理部１０４に供給される。【００８７】
出力パケット処理部１０４は、設定レジスタ１０６に当該ＮＩＦ：１０―ｎの処理モードがイーサネット処理モードと設定してある場合には、出力パケットの宛先ＭＡＣアドレス４１１と、送信元ＭＡＣアドレス４１２と、タイプ値４１３と、ＭＰＬＳラベル（ＬＳＰラベル）４１４−１と、ＭＰＬＳラベル（ＰＷラベル）４１４−２とを削除し、対応する入出力回線インタフェース１０１−ｉにパケットを出力する。【００８８】
一方、設定レジスタ１０６に当該ＮＩＦ：１０―ｎの処理モードがＭＰＬＳ処理モードと設定されている場合には、パケット処理を行うことなくそのまま対応する入出力回線インタフェース１０１−ｉにパケットを出力する。【００８９】
図１８は、通信装置ＮＤ＃ｎの入力パケット処理部１０３が実行する入力パケット処理Ｓ１００のフローチャートを示している。このような処理は、通信装置ＮＤ＃ｎがマイクロコンピュータのようなハードウェア資源を備え、ハードウェア資源をソフトウェアによる情報処理が利用することにより当該処理を実行することができる。【００９０】
入力パケット処理部１０３は、設定レジスタ１０６に設定されている当該ＮＩＦ：１０―ｎの処理モードを判定する（Ｓ１０１）。【００９１】
イーサネット処理モードと設定されている場合には、装置内ヘッダ４５とＶＬＡＮタグ４０３から各情報を抽出し、抽出した受信ポートＩＤ：４５２とＶＩＤを用いて、コネクションＩＤ決定テーブル２１を検索し、当該パケットのコネクションＩＤ：２１１を特定する（Ｓ１０２）。【００９２】
次に、コネクションＩＤ：２１１を装置内ヘッダ：４５に書き込み、入力ヘッダ処理テーブル２２及びラベル設定テーブル２３を検索し、エントリ内容を取得する（Ｓ１０３）。【００９３】
次に、入力ヘッダ処理テーブル２２の内容に従ってＶＬＡＮタグ４０３を編集する（Ｓ１０４）。【００９４】
次に、コネクションＩＤ：２１１（ここではユーザ）毎の帯域監視処理を行い、装置内ヘッダ（図１２、４５）の優先度４５３を追加する（Ｓ１０５）。【００９５】
通信パケット（図９，４１）において、宛先ＭＡＣアドレス４１１と送信元ＭＡＣアドレス４１２に設定レジスタ１０６の設定値、タイプ値４１３にＭＰＬＳであることを示す“８８４７”（１６進数）、ＭＰＬＳラベル（ＬＳＰラベル）４１４−１としてラベル設定テーブル２３のＬＳＰラベル２３２、ＭＰＬＳラベル（ＰＷラベル）４１４−２のラベル値としてラベル設定テーブル２３のＰＷラベル２３３、ＴＣとして装置内ヘッダ４５の優先度４５３を付与する。【００９６】
その後、パケットを転送し（Ｓ１０６）、処理を終了する（Ｓ１１１）。【００９７】
一方、上記Ｓ１０１において、ＭＰＬＳ処理モードと設定されている場合には、通信パケット４１において、２段目のＭＰＬＳラベル４１４−２が予約値（“１３”）であるかを判定し（Ｓ１０７）、予約値でない場合は、ユーザパケットとして当該パケットをそのまま転送し（Ｓ１０８）、処理を終了する（Ｓ１１１）。【００９８】
一方、上記Ｓ１０７において、予約値である場合、ＯＡＭパケットと判定し、当該パケットのペイロード４２５の装置ＩＤが設定レジスタ１０６に設定されている自装置ＩＤと一致するかを判定し（Ｓ１０９）、一致しない場合、透過ＯＡＭパケットとして、上記ユーザパケットと同様にＳ１０８以降の処理を実行する。【００９９】
一方、上記Ｓ１０９において、一致する場合、当該装置で終端するＯＡＭパケットと判定し、当該パケットを障害管理部１０７へ転送し（Ｓ１１０）、処理を終了する（Ｓ１１１）。【０１００】
図１９に、障害管理テ−ブル２５を示す。障害管理テ−ブル２５は、パスＩＤ：２５１を検索キーとして、ＳＬＡ種別２５２と、終端装置ＩＤ：２５３と、経由装置ＩＤ：２５４と、経由リンクＩＤ：２５５と、ＬＳＰラベル値２５６と、障害発生有無２５７とを示すテーブルエントリを検索するためのものである。【０１０１】
ここで、パスＩＤ：２５１、ＳＬＡ種別２５２、終端装置ＩＤ：２５３、経由装置ＩＤ：２５４、経由リンクＩＤ：２５５、ＬＳＰラベル値２５６は、パス構成テーブルＮＭＳ−ｔ４のパスＩＤ：ＮＭＳ−ｔ４１、ＳＬＡ種別ＮＭＳ−ｔ４２、終端装置ＩＤ：ＮＭＳ−ｔ４３、経由装置ＩＤ：ＮＭＳ−ｔ４４、経由リンクＩＤ：ＮＭＳ−ｔ４５、ＬＳＰラベル値ＮＭＳ−ｔ４６とそれぞれ同様である。【０１０２】
障害発生有無２５７は、当該パスで障害が発生しているかどうかを示す情報であり、これをＮＩＦ管理部１０５が後述する障害管理テーブルポーリング処理で読出し、ＳＬＡ種別２５２に応じて優先度を判定し、装置管理部１２に通知する。装置管理部１２が障害通知キュー読出し処理Ｓ４００により、装置全体でのＳＬＡ種別２５２に応じた優先度を判定を実施し、最終的にネットワーク管理システムＮＭＳに通知される。本テーブルの使用方法の詳細は後述する。【０１０３】
障害管理部１０７は、上記障害管理テーブル２５に追加されたパス２５１に対して、障害監視パケットを定期的に送信する。本障害監視パケットには、ＬＳＰラベル４１４−１としてＬＳＰラベル値２５６、ＯＡＭ種別４２４として障害監視パケットを示す識別子、ペイロード４２５に対向の終端装置ＩＤ：ＮＤ＃ｎ、その他の領域には設定レジスタ１０６の設定値が格納される（図１０参照）。  障害管理部１０７は、一定期間当該パスに障害監視パケットが到着しない場合は、障害管理テーブル２５の障害発生有無２５６に障害発生として「有」を上書きする。【０１０４】
障害管理部１０７は、上記入力パケット処理部１０３から自装置宛のＯＡＭパケットを受信すると、ペイロード４２５のＯＡＭ種別４２４をチェックし、当該パケットが障害監視パケットか折返し試験パケット（折返し要求パケットまたは折返し応答パケット）かを判定し、障害監視パケットであった場合には、障害管理テーブル２５の障害発生有無２５６に障害復旧として「無」を上書きする。【０１０５】
障害管理部１０７は、後述する折返し試験において、ネットワーク管理システムから指定されたパスに対して、折返し試験を実施するため、ＬＳＰラベル４１４−１として後述するようにネットワーク管理システムから指定された試験対象パスＩＤ：ＮＭＳ−ｔ４１のＬＳＰラベル２５６、ＯＡＭ種別４２４に本パケットが折返し要求パケットであることを示す識別子、ペイロード４２５に折返し対象となる経由装置ＩＤ：ＮＭＳ−ｔ４４、その他の領域には設定レジスタ１０６の設定値を用いて折返し要求パケットを生成し、送信する。【０１０６】
障害管理部１０７は、上記入力パケット処理部１０３から自装置宛のＯＡＭパケットを受信すると、ペイロード４２５のＯＡＭ種別４２４をチェックし、折返し要求パケットと判断された場合には、ＬＳＰラベル４１４−１として受信した方向とは逆方向のＬＳＰラベル値２５６、ＯＡＭ種別４２４に折返し応答パケットであることを示す識別子、ペイロード４２５に折返し対象となる終端装置ＩＤ：２５３、その他の領域には設定レジスタ１０６の設定値を用いて折返し応答パケットを返送する。【０１０７】
一方、上記において折返し応答パケットと判断された場合には、折返し試験成功となるため、その旨ＮＩＦ管理部１０５と装置管理部１２を介してネットワーク管理システムＮＭＳに通知する。【０１０８】
図２０は、オペレータＯＰからネットワークＮＷを設定する際のシーケンスＳＱ１００を示す。【０１０９】
オペレータＯＰが設定変更として、本変更の要求種別（ユーザ新規追加または削除。設定変更する場合は、オペレータが削除後に新規追加を実施）、ユーザＩＤ、接続先（例えば、アクセス装置＃１とデータセンタＤＣの組合せ）、サービス種別そして変更後の契約帯域を送信する（ＳＱ１０１）。【０１１０】
設定変更を受信したネットワーク管理システムＮＭＳは、後述するサービスに応じたパス検索処理Ｓ２０００により、パス構築ポリシテーブルＮＭＳ−ｔ１などを参照することでサービスのＳＬＡに応じてパスの構築ポリシを変更し、接続先管理テーブルＮＭＳ−ｔ３やリンク管理テーブルＮＭＳ−ｔ５を利用してパスを検索する。その結果を対応する通信装置ＮＤ＃１〜ｎに設定する（ＳＱ１０２−１〜ｎ）。【０１１１】
本設定情報としては、前述したコネクションＩＤ決定テーブル２１、入力ヘッダ処理テーブル２２、ラベル設定テーブル２３、帯域監視テーブル２４、障害管理テーブル２５、そしてパケット転送テーブル２６などの各ユーザやパスの接続関係や帯域設定が含まれる。これらの情報が各通信装置ＮＤ＃ｎに設定されると、ユーザからのトラヒックが設定した経路通りに送受信可能となると共に、パスの終端点となるエッジ装置ＮＤ＃1およびＮＤ＃ｎ間で、障害監視パケットの定期的な送受信が開始される（ＳＱ１０３−１、ＳＱ１０３−ｎ）。【０１１２】
以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳから設定完了通知がオペレータＯＰに送信され（ＳＱ１０４）、本シーケンスが終了となる。【０１１３】
図２１は、ユーザ端末ＴＥｎからの要求によりネットワークＮＷを設定する際のシーケンスＳＱ２００を示す。【０１１４】
ここでは、ユーザからネットワークＮＷの変更が必要となるようなサービス要求を通信事業者が受け付ける手段として、通信事業者が提供するホームページなどを提供するサーバがインタネットＩＮの中に設置されているケースを想定している。仮に、本ネットワークＮＷにおいてインタネットＩＮへの接続性を有しないユーザの場合、他の代替手段、例えばスマートフォンや自宅、または会社で有しているいずれかからインタネットにアクセスすることが可能な手段を有しているとする。【０１１５】
ユーザ端末ＴＥｎからサービス要求が発生すると（ＳＱ２０１）、それを受信したインタネットＩＮの中に設置されたサーバは、それをネットワークＮＷの設定情報に変換し（ＳＱ２０２）、当該設定変更を管理用ネットワークＭＮＷを介してネットワーク管理システムＮＭＳに送信する（ＳＱ２０３）。【０１１６】
それ以降のサービスに応じたパス検索処理Ｓ２０００、通信装置ＮＤ＃ｎへの設定（ＳＱ１０２）、監視パケットによる常時監視の開始（ＳＱ１０３）の処理はＳＱ１００(図２０）と同様である。以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳから設定完了通知が管理用ネットワークＭＮＷを介してインタネットＩＮ上のサーバに送信され（ＳＱ１０４）、さらにそれがユーザ端末ＴＥｎまで通知され（ＳＱ２０５）、本シーケンスが終了となる。【０１１７】
図２２は、データセンタＤＣからの要求によりネットワークＮＷを設定する際のシーケンスＳＱ３００を示す。【０１１８】
データセンタＤＣから管理用ネットワークＭＮＷを介して設定変更の要求が発信されると（ＳＱ３０１）、当該設定変更を処理する。【０１１９】
それ以降のサービスに応じたパス検索処理Ｓ２０００、通信装置ＮＤ＃ｎへの設定（ＳＱ１０２）、監視パケットによる常時監視の開始（ＳＱ１０３）の処理はＳＱ１００(図２０）と同様である。【０１２０】
以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳから設定完了通知が管理用ネットワークＭＮＷを介してデータセンタＤＣに通知され（ＳＱ３０２）、本シーケンスが終了となる。【０１２１】
図２３は、中継装置ＮＤ＃３において障害が発生した場合の、故障個所特定シーケンスＳＱ４００を示す。【０１２２】
中継装置ＮＤ＃３で通信断が発生するような障害が発生すると、エッジ装置ＮＤ＃１とＮＤ＃ｎの間で定期的に送受信している障害監視パケットが到着しなくなる（ＳＱ４０１−１，ＳＱ４０１−ｎ）。【０１２３】
この結果、各エッジ装置ＮＤ＃１及びＮＤ＃ｎは、保証型サービスのパスＰＴＨ＃１において障害が発生したことを検出する（ＳＱ４０２−１、ＳＱ４０２−ｎ）。【０１２４】
この結果、各エッジ装置ＮＤ＃１及びＮＤ＃ｎは、後述する障害通知処理Ｓ３０００を実施し、保証型サービスのパスＰＴＨ＃１の障害を優先的にネットワーク管理システムＮＭＳへ通知する（ＳＱ４０３−１、ＳＱ４０３−ｎ）。【０１２５】
これを受信したネットワーク管理システムＮＭＳは、保証型サービスのパスＰＴＨ＃１で障害が発生した旨の通知をオペレータＯＰに通知すると共に（ＳＱ４０４）、以下の障害箇所判定処理（ＳＱ４０５）を自動実行する。【０１２６】
まず、ネットワーク管理システムＮＭＳは、エッジ装置ＮＤ＃１とそれと隣接する中継装置ＮＤ＃２間の正常性を確認するため、折返し試験要求とそのために必要な情報（試験対象パスＩＤ：ＮＭＳ−ｔ４１、折返し対象となる経由装置ＩＤ：ＮＭＳ−ｔ４４）をエッジ装置ＮＤ＃１に対して通知する（ＳＱ４０５１−１）。【０１２７】
その要求を受け、エッジ装置ＮＤ＃１は、前述の通り折返し要求パケットを送信する（ＳＱ４０５１−１ｒｅｑ）。【０１２８】
本折り返し試験パケットを受信した中継装置ＮＤ＃２は、自装置宛の折返し試験であるため、上述の通り折返し応答パケットを返送する（ＳＱ４０５１−１ｒｐｙ）。【０１２９】
当該折返し応答パケットを受信したエッジ装置ＮＤ＃１は、折返し試験成功通知をネットワーク管理システムＮＭＳに通知する（ＳＱ４０５１−１ｓｕｃ）。【０１３０】
当該折返し試験成功通知を受信したネットワーク管理システムＮＭＳは、障害箇所を特定するため、中継装置ＮＤ＃３との正常性を確認するため、折返し試験要求とそのために必要な情報をエッジ装置ＮＤ＃１に対して通知する（ＳＱ４０５１−２）。【０１３１】
その要求を受け、エッジ装置ＮＤ＃１は、前述の通り折返し要求パケットを送信する（ＳＱ４０５１−２ｒｅｑ）。【０１３２】
本折り返し試験パケットは、中継装置ＮＤ＃３が故障しているため、エッジ装置ＮＤ＃１には返送されない（ＳＱ４０５１−２ｄｅｆ）。【０１３３】
エッジ装置ＮＤ＃１は、一定時間内に折返し応答パケットが返送されないため、折返し試験失敗通知をネットワーク管理システムＮＭＳに通知する（ＳＱ４０５１−２ｆａｉｌ）。【０１３４】
当該折返し試験失敗通知を受信したネットワーク管理システムＮＭＳは、障害箇所を中継装置ＮＤ＃３と特定し（ＳＱ４０５２）、その情報をオペレータＯＰに障害箇所として通知し（ＳＱ４０５３）、本シーケンスが終了となる。【０１３５】
図２４、２５は、ネットワーク管理システムＮＭＳが実行する、サービスに応じたパス検索処理Ｓ２０００を示す。このような処理は、ネットワーク管理システムＮＭＳが図２に示したハードウェア資源を備え、ハードウェア資源をソフトウェアによる情報処理が利用することにより、当該処理を実現することができる。【０１３６】
オペレータＯＰ、あるいは、インタネットＩＮまたはデータセンタＤＣから設定変更を受信したネットワーク管理システムＮＭＳは、設定変更として要求種別、接続先、ＳＬＡ種別、及び契約帯域を取得し（Ｓ２０１）、取得した要求種別をチェック（Ｓ２０２）する。【０１３７】
要求種別が、削除であれば、該当するユーザ管理テーブルＮＭＳ−ｔ２(図４）から該当エントリを削除し、当該ユーザの収容パスＮＭＳ−ｔ２３に該当するパス構成テーブルＮＭＳ−ｔ４(図６）のエントリの情報を更新する。【０１３８】
更新の内容が、保証型サービスであれば、パス構成テーブルＮＭＳ−ｔ４(図６）の割当帯域ＮＭＳ−ｔ４７から、ユーザ管理テーブルＮＭＳ−ｔ２(図４）の契約帯域ＮＭＳ−ｔ２４を減算し、収容ユーザＮＭＳ−ｔ４８から当該ユーザＩＤを削除する。また、公平型サービスであれば、収容ユーザＮＭＳ−ｔ４８から当該ユーザＩＤを削除する。【０１３９】
そして、リンク管理テーブルＮＭＳ−ｔ５(図７）の内、パス構成テーブルＮＭＳ−ｔ４(図６）の経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新する。更新の内容が、保証型サービスであれば、空き帯域ＮＭＳ−ｔ５２から契約帯域ＮＭＳ−ｔ２４を減算する。公平型サービスであれば、透過非優先ユーザ数ＮＭＳ−ｔ５３を１減算する。そして、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知し（Ｓ２１１）、処理を終了する（Ｓ２１６）。【０１４０】
上記Ｓ２０２において、新規追加であった場合、当該接続先の情報を用いて接続先管理テーブルＮＭＳ−ｔ３(図５）を検索し、接続先となり得るポイントとして収容装置（ノード）ＩＤ：ＮＭＳ−ｔ３３と収容ポートＩＤ：ＮＭＳ−ｔ３４の組合せの候補を抽出する（Ｓ２０３）。例えば、図１でアクセス装置ＡＥ＃１を始点としてデータセンタＤＣを終点として指定された場合、その候補は以下となる。【０１４１】
始点ポート候補：
（１）収容装置ＩＤ：ＮＤ＃１の収容ポートＩＤ：ＰＴ＃１
終点ポート候補：
（Ａ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１０
（Ｂ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１１
ここで、始点ポート候補と終点ポート候補間のパスを検索する必要があることを意味する。つまり、この場合、（１）−（Ａ）間および（１）−（Ｂ）間のパスが候補となる。【０１４２】
続いて、上記Ｓ２０１で取得したＳＬＡ種別をチェックし（Ｓ２０４）、保証型であれば、リンク管理テーブルＮＭＳ−ｔ５(図７）を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、指定された契約帯域分の空き帯域が存在し、かつその空き帯域が最小の経路を検索する（Ｓ２０５）。具体的には、例えば、リンク管理テーブルＮＭＳ−ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらのうちコストの合計値（本実施例では空き帯域）が最も少ない経路が選択されることで、保証型サービスのパスは既存パスに集約することが可能となる。なお、コストが最小の経路ではなく、コストが所定閾値以下の経路をランダムに選択する等の方法でも、ある程度の集約効果が得られる。閾値は絶対的な数値を規定する閾値でもよいし、相対的な（例えば下位１０％）規定による閾値でもよい。【０１４３】
続いて、上記Ｓ２０５の結果、条件に合致する経路があるかを判定する（Ｓ２０６）。【０１４４】
判定の結果該当経路がなければ経路なしとしてオペレータに通知し（Ｓ２０７）、処理を終了する（Ｓ２１６）。【０１４５】
一方、上記Ｓ２０６において、該当経路があれば、パス構成テーブルＮＭＳ−ｔ４を利用し、当該経路が既存パスの経路かどうか判定する（Ｓ２０８）。【０１４６】
既存パスの経路があれば、ユーザ管理テーブルＮＭＳ−ｔ２に新規エントリを追加し、既存パスを収容パスＮＭＳ−ｔ２３に設定する。また、該当するパス構成テーブルＮＭＳ−ｔ４のエントリの情報を更新（割当帯域ＮＭＳ−ｔ４７に契約帯域ＮＭＳ−ｔ２４を加算し、収容ユーザＮＭＳ−ｔ４８に新規ユーザＩＤを追加）する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新（空き帯域ＮＭＳ−ｔ５２に契約帯域ＮＭＳ−ｔ２４を加算）する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知し（Ｓ２０９）、処理を終了する（Ｓ２１６）。【０１４７】
一方、上記Ｓ２０８において、既存パスの経路がなければ、ユーザ管理テーブルＮＭＳ−ｔ２に新規エントリを追加し、新規パスを収容パスＮＭＳ−ｔ２３に設定する。また、パス構成テーブルＮＭＳ−ｔ４に新規エントリを追加（割当帯域ＮＭＳ−ｔ４７に契約帯域ＮＭＳ−ｔ２４を設定し、収容ユーザＮＭＳ−ｔ４８に新規ユーザＩＤを追加）する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新（空き帯域ＮＭＳ−ｔ５２に契約帯域ＮＭＳ−ｔ２４を加算）する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知し（Ｓ２１０）、処理を終了する（Ｓ２１６）。【０１４８】
以上の処理によると、図１のＰＴＨ＃１に示すように、保証型のサービスでは、通信ネットワーク上の送信ポートと宛先ポートが同じ経路を有する複数パスは、通信パス同士が集約されていく。このとき、図１のように、エッジ装置ＮＤ＃1およびＮＤ＃ｎ間でネットワーク上の送信ポートと宛先ポートが全く同一の経路を集約できれば理想的であるが、エッジ間の経路の一部のみを集約してもよい。保証型の通信パスを集約することにより、重点的に保守管理すべき物理的範囲を限定することができ、保守点検作業のリソースを集中することができる。【０１４９】
図２５は、上記Ｓ２０４において、公平型と判断された場合の処理を示す。上記Ｓ２０４において、公平型と判断された場合には、リンク管理テーブルＮＭＳ−ｔ５を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、“空き帯域ＮＭＳ−ｔ５２÷透過非優先ユーザ数ＮＭＳ−ｔ５３”が最大の経路を検索する（Ｓ２１２）。【０１５０】
具体的には、例えば、リンク管理テーブルＮＭＳ−ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらのうちコストの合計値（本実施例では“空き帯域ＮＭＳ−ｔ５２÷透過非優先ユーザ数ＮＭＳ−ｔ５３”）が最も大きい経路が選択されることで、公平型サービスは既存パスの中で分散される。なお、値が最大の経路ではなく、値が所定閾値以上の経路をランダムに選択する等の方法でも、ある程度の分散効果が得られる。閾値は絶対的な数値を規定する閾値でもよいし、相対的な（例えば上位１０％）規定による閾値でもよい。【０１５１】
続いて、上記Ｓ２１２の後、パス構成テーブルＮＭＳ−ｔ４を利用し、得られた経路が既存パスの経路かどうか判定する（Ｓ２１３）。【０１５２】
既存パスの経路があれば、ユーザ管理テーブルＮＭＳ−ｔ２に新規エントリを追加し、既存パスを収容パスＮＭＳ−ｔ２３に設定し、該当するパス構成テーブルＮＭＳ−ｔ４のエントリの情報を更新する。具体的には、収容ユーザＮＭＳ−ｔ４８に新規ユーザＩＤを追加する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新する。具体的には、透過非優先ユーザ数ＮＭＳ−ｔ５３に１加算する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知し（Ｓ２１４）、処理を終了する（Ｓ２１６）。【０１５３】
一方、上記Ｓ２１３において、既存パスの経路がなければ、ユーザ管理テーブルＮＭＳ−ｔ２に新規エントリを追加し、新規パスを収容パスＮＭＳ−ｔ２３に設定する。また、パス構成テーブルＮＭＳ−ｔ４に新規エントリを追加する。具体的には、収容ユーザＮＭＳ−ｔ４８に新規ユーザＩＤを追加する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新する。具体的には、透過非優先ユーザ数ＮＭＳ−ｔ５３に１加算する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知し（Ｓ２１５）、処理を終了する（Ｓ２１６）。【０１５４】
以上の処理によると、図１のＰＴＨ＃２、ＰＴＨ＃ｎに示すように、公平型のサービスでは、保証型のサービスの空き帯域に、通信パスが分散されて配置される。【０１５５】
このように、保証型サービスのパスは同一経路に集約し、公平型サービスのパスは収容ユーザ数の比率に応じて分散させることが可能となる。【０１５６】
図２６は、通信装置ＮＤ＃ｎのＮＩＦ管理部１０５が実行する障害通知処理（図２３、Ｓ３０００）における、障害管理テーブルポーリング処理Ｓ３００の詳細を示す。【０１５７】
ＮＩＦ管理部１０５は、装置の電源投入と同時に、本ポーリング処理を開始し、変数ｉを“０”に初期化し（Ｓ３０１）、変数ｉに１を加算する（Ｓ３０２）。【０１５８】
次に、障害管理テーブル２５（図１９）のパスＩＤ：２５１をＰＴＨ＃ｉとして検索し、エントリを取得する（Ｓ３０３）。【０１５９】
次に、当該エントリの障害発生有無（図１９、２５７）をチェックする（Ｓ３０４）。【０１６０】
“有”であれば、ＰＴＨ＃ｉをパスＩＤとし、さらにそのＳＬＡ種別（図１９、２５２）を障害発生通知として装置管理部１２に通知し（Ｓ３０５）、Ｓ３０２以降の処理を継続する。【０１６１】
一方、上記Ｓ３０４において、障害発生有無２５７が“無”であれば、Ｓ３０２以降の処理を継続する。【０１６２】
上記障害発生通知を受信した装置管理部１２は、ＳＬＡ種別が保証型サービス（例えばＳＬＡ＃１）であれば、受信した情報を障害通知キュー（優先）２７−１へ格納し、ＳＬＡ種別が公平型サービス（例えばＳＬＡ＃２）であれば、障害通知キュー（非優先）２７−２に格納する（図１１参照）。【０１６３】
図２７は、通信装置ＮＤ＃ｎの装置管理部１２が実行する障害通知処理Ｓ３０００における障害通知キュー読出し処理Ｓ４００の詳細を示す。【０１６４】
装置管理部１２は、障害通知キュー（優先）２７−１または障害通知キュー（非優先）２７−２のどちらかに障害発生通知が格納されていると判定すると、障害通知キュー（優先）２７−１に通知があるかどうかを判定する（Ｓ４０１）。【０１６５】
障害通知キュー（優先）２７−１に通知があれば、障害通知キュー（優先）２７−１から格納してあるパスＩＤとＳＬＡ種別と共に障害通知としてネットワーク管理システムＮＭＳに通知する（Ｓ４０２）。【０１６６】
次に、障害通知キュー（優先）２７−１または障害通知キュー（非優先）２７−２のどちらかに障害発生通知が格納されているか判定し（Ｓ４０４）、どちらにも通知がなければ処理を終了する（Ｓ４０５）。【０１６７】
一方、上記Ｓ４０１において、障害通知キュー（優先）２７−１に通知がないと判定すると、障害通知キュー（非優先）２７−２から格納してあるパスＩＤとＳＬＡ種別と共に障害通知としてネットワーク管理システムＮＭＳに通知し（Ｓ４０３）、Ｓ４０４以降の処理を実行する。【０１６８】
一方、上記Ｓ４０４において、どちらかのキューに通知があれば、Ｓ４０１以降の処理を継続する。【０１６９】
以上の処理Ｓ３００およびＳ４００により、各通信装置で検出した保証型サービスの障害通知を優先してネットワーク管理システムＮＭＳに通知することが可能となる。ネットワーク管理システムＮＭＳは、先に通知された障害について優先的に処理することで、保証型サービスについて優先的に対応し、稼働率を保証することが容易となる。
【実施例２】
【０１７０】
図２８、２９は、ネットワーク管理システムＮＭＳが実行する本発明の別のサービスに応じたパス検索処理例Ｓ２８００を示す。Ｓ２８００以外の処理は、実施例１と同様である。【０１７１】
Ｓ２８００は、Ｓ２０００（図２４）の内、Ｓ２０９、Ｓ２１０およびＳ２１１の処理の後に、下記Ｓ２００１〜Ｓ２００６を追加したものであり、他の処理はＳ２０００と同様であるため、以下では変更点のみ説明する。【０１７２】
Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスが存在するかをパス構成テーブルＮＭＳ−ｔ４から検索する（Ｓ２００１）。【０１７３】
公平型サービスのパスが存在する場合、経由リンクＩＤ：ＮＭＳ―ｔ４５が全く同様なパスを有している公平型サービスのパスＩＤ：ＮＭＳ−ｔ４１を取得する。そして、リンク管理テーブルＮＭＳ−ｔ５の中で当該パスの経由リンク：ＮＭＳ―ｔ４５に該当する非優先透過ユーザ数ＮＭＳ−ｔ５３を１減算し、暫定リンク管理テーブルＮＭＳ−ｔ５として保持する（Ｓ２００２）。【０１７４】
次に、この暫定リンク管理テーブルＮＭＳ−ｔ５を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、“空き帯域ＮＭＳ−ｔ５２÷透過非優先ユーザ数ＮＭＳ−ｔ５３”が最大の経路を検索する（Ｓ２００３）。【０１７５】
具体的には、例えば、暫定リンク管理テーブルＮＭＳ−ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらのうちコストの合計値（本実施例では“空き帯域ＮＭＳ−ｔ５２÷透過非優先ユーザ数ＮＭＳ−ｔ５３”）が最も大きい経路が選択されることで、公平型サービスは既存パスの中で分散される。【０１７６】
続いて、上記Ｓ２００３の後、パス構成テーブルＮＭＳ−ｔ４を利用し、得られた経路が既存パスの経路かどうか判定する（Ｓ２００４）。【０１７７】
既存パスの経路があれば、Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスの中から一人のユーザを選択し、Ｓ２００３の結果検索されたパスに収容を変更する（Ｓ２００５）。【０１７８】
具体的には、該当するユーザ管理テーブルＮＭＳ−ｔ２から該当エントリを削除し、当該ユーザの収容パスＮＭＳ−ｔ２３に該当するパス構成テーブルＮＭＳ−ｔ４のエントリの情報を更新（収容ユーザＮＭＳ−ｔ４８から当該ユーザＩＤを削除）する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新（透過非優先ユーザ数ＮＭＳ−ｔ５３を１減算）する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新する。さらに、ユーザ管理テーブルＮＭＳ−ｔ２に上記で削除したユーザを追加し、既存パスを収容パスＮＭＳ−ｔ２３に設定する。さらに、該当するパス構成テーブルＮＭＳ−ｔ４のエントリの情報を更新（収容ユーザＮＭＳ−ｔ４８に上記で削除したユーザＩＤを追加）する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新（透過非優先ユーザ数ＮＭＳ−ｔ５３に１加算）する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知する。【０１７９】
続いて、上記Ｓ２００５の処理の後、処理を終了する（Ｓ２１６）。【０１８０】
一方、上記Ｓ２００４において、既存パスの経路がなければ、Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスの中から一人のユーザを選択し、新規パスを設定し、当該パスに収容を変更する（Ｓ２００６）。【０１８１】
具体的には、該当するユーザ管理テーブルＮＭＳ−ｔ２から該当エントリを削除し、当該ユーザの収容パスＮＭＳ−ｔ２３に該当するパス構成テーブルＮＭＳ−ｔ４のエントリの情報を更新する。具体的には、収容ユーザＮＭＳ−ｔ４８から当該ユーザＩＤを削除する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新する。具体的には透過非優先ユーザ数ＮＭＳ−ｔ５３を１減算する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新する。さらに、ユーザ管理テーブルＮＭＳ−ｔ２に上記で削除したユーザを追加し、新規パスを収容パスＮＭＳ−ｔ２３に設定する。また、パス構成テーブルＮＭＳ−ｔ４に新規エントリを追加する。具体的には収容ユーザＮＭＳ−ｔ４８に上記で削除したユーザＩＤを追加する。また、リンク管理テーブルＮＭＳ−ｔ５の内、経由リンクＩＤ：ＮＭＳ−ｔ４５に該当する全エントリを更新する。具体的には透過非優先ユーザ数ＮＭＳ−ｔ５３に１加算する。また、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知する。【０１８２】
続いて、上記Ｓ２００６の処理の後、処理を終了する（Ｓ２１６）。【０１８３】
一方、上記Ｓ２００１において、Ｓ２０９、Ｓ２１０またはＳ２１１の処理の結果、設定を変更したパスと同一経路に公平型サービスのパスは存在しない場合、処理を終了する（Ｓ２１６）。【０１８４】
以上の処理を行うことにより、保証型サービスの確保帯域の変更や、公平型サービスのユーザ数の変化に追従し、公平型ユーザ間で分配される空き帯域の比を常に平等に保つことが可能となる。
【実施例３】
【０１８５】
本発明の別のネットワーク管理システムの実施例を示す。【０１８６】
本実施例のネットワーク管理システムの構成は、図２に示した実施例１のネットワーク管理システムＮＭＳとほぼ同様である。異なる部分を中心に説明すると、パス構成テーブルＮＭＳ-ｔ４に事前にパスを設定する点が異なる。このため、本実施例ではパス構成テーブルをＮＭＳ-ｔ４０と称する。その他、それぞれのブロックの構成は、ネットワーク管理システムＮＭＳと同様である。【０１８７】
図３０は、オペレータからのネットワーク事前設定シーケンスＳＱ１０００を示す。【０１８８】
オペレータＯＰが事前の設定情報として、接続先（例えば、アクセス装置＃１とデータセンタＤＣの組合せ）、サービス種別を送信する（ＳＱ１００１）。【０１８９】
それを受信したネットワーク管理システムＮＭＳは、後述する事前パス検索処理Ｓ５００により、接続先管理テーブルＮＭＳ−ｔ３やリンク管理テーブルＮＭＳ−ｔ５を利用してパスを検索する。その結果を対応する通信装置ＮＤ＃１〜ｎに設定する（ＳＱ１００２−１〜ｎ）。【０１９０】
本設定情報としては、実施例１と同様のコネクションＩＤ決定テーブル２１、入力ヘッダ処理テーブル２２、ラベル設定テーブル２３、帯域監視テーブル２４、障害管理テーブル２５、そしてパケット転送テーブル２６などの各ユーザやパスの接続関係や帯域設定が含まれる。【０１９１】
これらの情報が各通信装置ＮＤ＃ｎに設定されると、パスの終端点となるエッジ装置ＮＤ＃1およびＮＤ＃ｎ間で、障害監視パケットの定期的な送受信が開始される（ＳＱ１００３−１、ＳＱ１００３−ｎ）。【０１９２】
以上より、所望の設定が終了したため、ネットワーク管理システムＮＭＳ２から設定完了通知がオペレータＯＰに送信され（ＳＱ１００４）、本シーケンスが終了となる。【０１９３】
図３１は、ネットワーク管理システムＮＭＳが実行する事前パス検索処理Ｓ５００を示す。オペレータＯＰから事前設定を受信したネットワーク管理システムＮＭＳは、事前設定として接続先及びＳＬＡ種別を取得する（Ｓ５０１）。【０１９４】
次に、当該接続先の情報を用いて接続先管理テーブルＮＭＳ−ｔ３を検索し、接続先となり得るポイントとして収容ノードＩＤ：ＮＭＳ−ｔ３３と収容ポートＩＤ：ＮＭＳ−ｔ３４の組合せの候補を抽出する（Ｓ５０２）。【０１９５】
例えば、アクセス装置ＡＥ＃１を始点としてデータセンタＤＣを終点として指定された場合、その候補は以下となる。【０１９６】
始点ポート候補：
（１）収容装置ＩＤ：ＮＤ＃１の収容ポートＩＤ：ＰＴ＃１
終点ポート候補：
（Ａ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１０
（Ｂ）収容装置ＩＤ：ＮＤ＃ｎの収容ポートＩＤ：ＰＴ＃１１
ここで、始点ポート候補と終点ポート候補間のパスを検索する必要があることを意味する。つまり、この場合、（１）−（Ａ）間および（１）−（Ｂ）間のパスが候補となる。【０１９７】
続いて、Ｓ５０２の後、リンク管理テーブルＮＭＳ−ｔ５を利用し、一般的な経路探索アルゴリズム（マルチルートセレクション法またはダイクストラ法等）を用いて、上記始点と終点が接続可能な経路のリストを検索する（Ｓ５０３）。【０１９８】
具体的には、例えば、リンク管理テーブルＮＭＳ−ｔ５から使用可能と判定されたリンクを経由して、上記始点ポートから終点ポートまで到達する経路が存在する場合、それらの全てを候補リストとして保持する。【０１９９】
続いて、上記Ｓ５０３の結果、条件に合致する全ての経路の新規パスを設定する（Ｓ５０４）。【０２００】
具体的には、ユーザ管理テーブルＮＭＳ−ｔ２に新規エントリを追加し、新規パスを収容パスＮＭＳ−ｔ２３に設定し、パス構成テーブルＮＭＳ−ｔ４に新規エントリを追加（割当帯域ＮＭＳ−ｔ４７には０Ｍｂｐｓ（未使用）、収容ユーザＮＭＳ−ｔ４８に無効値を設定）し、該当する通信装置＃ｎの各種テーブル２１〜２６を更新し、処理の結果をオペレータに通知する。【０２０１】
上記Ｓ５０４の後、処理を終了する（Ｓ５０５）。【０２０２】
図３２は、上記オペレータからのネットワーク事前設定シーケンスＳＱ１０００によって生成されるパス構成テ−ブルＮＭＳ−ｔ４０を示す。パス構成テ−ブルＮＭＳ−ｔ４０は、パスＩＤ：ＮＭＳ−ｔ４０１を検索キーとして、ＳＬＡ種別ＮＭＳ−ｔ４０２と、終端装置ＩＤ：ＮＭＳ−ｔ４０３と、経由装置ＩＤ：ＮＭＳ−ｔ４０４と、経由リンクＩＤ：ＮＭＳ−ｔ４０５と、割当帯域ＮＭＳ−ｔ４０６、収容ユーザＮＭＳ−ｔ４０７とを示すテーブルエントリを検索するためのものである。【０２０３】
ここで、保証型サービスのパスであっても、割当帯域ＮＭＳ−ｔ４０６はユーザ未収用のため０Ｍｂｐｓとなっており、収容ユーザがいない状態である。さらに、公平型サービスのパスについても、収容ユーザ数がいない状態である。【０２０４】
この他、通信システムの構成や、通信装置ＮＤ＃ｎのブロック構成、そして処理なども実施例１と同様である。【０２０５】
以上の処理の処理を接続したい対象全てに実施することにより、事前に各接続先全てに複数の候補パスを設定可能となるため、サービスに応じたパス検索処理Ｓ２０００、Ｓ２８００において、新規ユーザを既存パスへ収容する確率が高まり、より迅速なネットワーク変更が可能となる。【０２０６】
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。【０２０７】
本実施例中、ソフトウエアで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。また、ソフトウエアで構成した機能は、単体のコンピュータ構成で実現してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。【０２０８】
以上説明した本発明の実施例によると、ＳＬＡの異なる複数サービスを収容する仮想ネットワークにおいて、通信品質だけでなく稼働率の保証が必要なビジネスユーザ向け通信サービスのパスは、各ユーザに確保すべき帯域の総和が経路上の物理回線の帯域を超過しない範囲で同一経路のものは集約することで、通信品質を保証しながら障害発生の際の障害検出数を削減可能である。【０２０９】
さらに、ビジネスユーザ向け通信サービスの障害発生を通信装置から優先的に通知し、本通知を受信したネットワーク管理システムが優先的に折返し試験を実行可能することで、ビジネスユーザ向け通信サービスのパスの障害箇所を迅速に特定し、部品交換などの保守作業を迅速に行うことが可能となる。以上より、通信品質と稼働率の両方を満足することが可能となる。【０２１０】
一方、大量のトラヒックを効率的かつユーザ間で公平に収容する必要のある一般消費者向け通信サービス向けのパスは、ビジネスユーザ向け通信パス用に確保された帯域以外の余りの帯域を考慮し、余りの帯域の比率がユーザ毎に等しくなるようにネットワーク全体に分散させることで、大容量のトラヒックを効率的かつユーザ間で公平性を維持して収容することが可能となる。【０２１１】
さらに、ユーザやアプリケーション提供事業者からのネットワーク変更要求に対して、自動的に上記の処理を実施することで、ＳＬＡを保証しながら柔軟に対応することが可能となる。以上の結果、通信事業者のサービス統合による提供コスト低減と、タイムリーな最適ネットワーク提供による収益向上を実現できる。
【産業上の利用可能性】
【０２１２】
種々のサービスに用いるネットワークの運用管理に利用することができる。
【符号の説明】
【０２１３】
ＴＥ１〜ｎ：ユーザ端末
ＡＥ１〜ｎ：アクセス装置
ＮＤ＃１〜ｎ：通信装置
ＤＣ：データセンタ
ＩＮ：インタネット
ＭＮＷ：管理用ネットワーク
ＮＭＳ：ネットワーク管理システム
ＭＴ：監視端末
ＯＰ：オペレータ
【図１】
2016194089.tif 000003
【図２】
2016194089.tif 000004
【図３】
2016194089.tif 000005
【図４】
2016194089.tif 000006
【図５】
2016194089.tif 000007
【図６】
2016194089.tif 000008
【図７】
2016194089.tif 000009
【図８】
2016194089.tif 000010
【図９】
2016194089.tif 000011
【図１０】
2016194089.tif 000012
【図１１】
2016194089.tif 000013
【図１２】
2016194089.tif 000014
【図１３】
2016194089.tif 000015
【図１４】
2016194089.tif 000016
【図１５】
2016194089.tif 000017
【図１６】
2016194089.tif 000018
【図１７】
2016194089.tif 000019
【図１８】
2016194089.tif 000020
【図１９】
2016194089.tif 000021
【図２０】
2016194089.tif 000022
【図２１】
2016194089.tif 000023
【図２２】
2016194089.tif 000024
【図２３】
2016194089.tif 000025
【図２４】
2016194089.tif 000026
【図２５】
2016194089.tif 000027
【図２６】
2016194089.tif 000028
【図２７】
2016194089.tif 000029
【図２８】
2016194089.tif 000030
【図２９】
2016194089.tif 000031
【図３０】
2016194089.tif 000032
【図３１】
2016194089.tif 000033
【図３２】
2016194089.tif 000034
【国際調査報告】
2016194089.tif 000035
2016194089.tif 000036