JP3871467B2 - 通信パスの障害復旧装置 - Google Patents
通信パスの障害復旧装置 Download PDFInfo
- Publication number
- JP3871467B2 JP3871467B2 JP8121699A JP8121699A JP3871467B2 JP 3871467 B2 JP3871467 B2 JP 3871467B2 JP 8121699 A JP8121699 A JP 8121699A JP 8121699 A JP8121699 A JP 8121699A JP 3871467 B2 JP3871467 B2 JP 3871467B2
- Authority
- JP
- Japan
- Prior art keywords
- path
- failure
- communication
- layer
- communication path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
- H04L45/247—Multipath using M:N active or standby paths
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は通信パスの障害復旧に関し、特に多重化構造で階層化された通信ネットワークにおける通信パスの障害復旧装置及びその方法に関するものである。
【０００２】
【従来の技術】
図１は通信ネットワーク構成の一例を示しており、また図２はその通信パスの多重化構造の一例を示している。
図１の（ｂ）に示すように、通信ネットワーク上にはＳＤＨ、ＰＤＨ及び図示した等の様々な伝送方式の通信装置が存在し、それらの間は種々の伝送速度の通信パスによって接続される。前記通信パスはまた図１の（ｃ）及びそれを階層表示した図２に示すように通信パスの多重化構造（２Ｍ＿ＳＤＨ、５０Ｍ＿ＳＤＨ、１５０Ｍ＿ＳＤＨ等）に基づいて階層化５〜７されている。
【０００３】
近年、ネットワーク通信網の形態も複雑化され、アクセス網、基幹網、ＰＤＨ網、及びＳＤＨ網等に分割された多種多様なドメインが存在している。図１の（ａ）に示すように各ドメインは内部のクロスコネクト装置等を管理するサブネットワーク管理システム（Ｓｕｂ−ＮＭＳ）２〜４によって管理され、それらはさらに主ネットワーク管理システム（Ｍａｉｎ−ＮＭＳ）１によって管理されている。ＩＴＵ−Ｔ勧告Ｇ．８０５ではこのような複雑な通信パスの管理をレイヤリング（階層構造）の関係を用いて整理する動きが見られる。
【０００４】
ここで、図２に×印で示すように１５０Ｍ＿ＳＤＨレイヤ５上で１５０Mb／ｓの通信パス１１（通信パスＡ）に断線等の障害が発生すると、従来においては前記障害からの早期復旧のために障害が発生した同一レイヤ５内の予備パスを使って前記通信パスの迂回パス１２及び１３を形成していた。もし、同一レイヤ内で復旧できない場合には、障害パスを収容するクライアント側のレイヤ６、７等においてより低速な５０Mb／ｓパスや２Mb／ｓパスを使って復旧が行われていた。
【０００５】
【発明が解決しようとする課題】
上述したように、従来においては伝送速度が高速のレイヤで通信パスの障害が発生した時に先ず同一レイヤ内でその障害復旧が行なわれるため、予め全ての通信パスに高速の予備パスを張っておく必要があった。そのため、例えば障害発生前の前記通信パス１１が全帯域の１０％しか使用していない場合であっても、その迂回路形成のために同じ１５０Mb／ｓの予備パスを用意しておく必要があった。
【０００６】
また、前記１０％の使用率しかない通信パスの障害に一旦割り当てられた１５０Mb／ｓの予備パスは、その後に発生した前記予備パスの使用を本当に必要とする使用率８０％の通信パスの障害に対して割り当てることができなかった。
このように、従来においては通信パス障害に対する予備容量設計の効率が極めて低いという問題があった。
【０００７】
一方、上述したように同一レイヤ内で障害復旧できない場合には、その高速のパスに収容されている低速パスの側での障害復旧が試みられる。この場合、高速レイヤで余分な予備パスを張らなくてすむため予備容量の設計効率は改善される。しかしながら、従来においては低速レイヤ側における多くのパスがその復旧使用の対象となるため障害復旧処理に膨大な時間が係り、かえって障害の影響を拡大させるという問題があった。
【０００８】
そこで本発明の目的は、上記種々の問題に鑑み、通信パスの開設／停止等により流動的に変わる通信ネットワークにおいて、所定の評価関数を用いることによって障害復旧に最適な通信パスを備えたレイヤ及びその通信パスとを適宜選択する通信パスの障害復旧装置及びその方法を提供することにある。その結果、通信パス障害に対する予備容量設計効率が顕著に改善され、且つ迅速な障害復旧が可能となる。
【０００９】
【課題を解決するための手段】
本発明によれば、通信パスが多重化された階層化構造を有する通信ネットワークにおける通信パスの障害復旧装置であって、前記装置は、ネットワーク収集情報によって障害パスを検出する通信パス障害受信部と、前記障害パスに関連する情報を所定の評価関数で判断した結果に基づいて動的に前記障害パスの障害復旧処理を行うための通信レイヤ及びそのレイヤ上の通信パスを選択する通信パス復旧対象選択部と、前記選択された通信レイヤ上の通信パスを使って前記障害パスの障害復旧処理を行う通信パス復旧処理部と、で構成される通信パスの障害復旧装置が提供される。
【００１０】
前記通信パス復旧対象選択部は、前記選択された通信レイヤにおいてさらに前記評価関数による判断を繰り返し、それによって前記障害パスの障害復旧処理を行うための通信レイヤ及びそのレイヤ上の通信パスを選択する。そして、前記評価関数は、前記障害パスが存在する同一レイヤ内でその障害復旧処理を行うか、又はそのパスを収容する他のレイヤのパスを用いて障害復旧処理を行うかの選択判断を行う。
【００１１】
前記評価関数は、障害パスのトラフィック使用率によって前記判断を行い、前記使用率が所定の閾値以下の場合にはクライアント側のレイヤのパスによる障害復旧処理を選択する。前記使用率には、ユーザとの契約帯域による全帯域の割合、ＡＴＭ通信におけるピークセルレートが含まれる。さらに、前記クライアント側の復旧対象パス数が所定値以上の場合には、前記クライアント側の選択が無効とされ、障害パスの同一レイヤ内で障害復旧処理が行われる。
【００１２】
また、前記評価関数は、所定数を超える複数パスの障害発生時にはそのサーバ側のパスを選択する。
前記通信パス復旧対象選択部はさらに迂回パス構成可否情報を有し、前記評価関数は前記迂回パス構成可否情報が否の場合に他のレイヤを選択する。前記通信パス復旧対象選択部はさらに各通信パスに付与したプライオリティ情報を有し、前記評価関数はプライオリティの高い通信パス障害に対し優先的に同一レイヤ内の処理を選択する。
【００１３】
【発明の実施の形態】
図３は、本発明による通信パスの障害復旧装置の基本構成例を示したものである。
図３では、本発明による通信パスの障害復旧装置の機能が主ネットワーク管理システム（Ｍａｉｎ−ＮＭＳ）１内のパス障害復旧機能部２０として備えられる。主ネットワーク管理システム１には複数のサブネットワーク管理システム（Ｓｕｂ−ＮＭＳ）２〜４が接続され、それらの間の通信は前者のマネージャ（Ｍａｎａｇｅｒ）２４と後者のエージェント（Ａｇｅｎｔ）２５とによって行われる。
【００１４】
主ネットワーク管理システム１は、サブネットワーク管理システム２〜４からネットワーク情報を収集したり、各サブネットワークのクロスコネクトに対する制御指示を与える等のネットワーク全体の制御及び管理を行う。これらは大きくネットワークの制御等を行なう機能オブジェクト（本例では２１〜２３に相当）とネットワーク情報等を管理する情報オブジェクト３１〜３６の２つのオブジェクトによって実現される。
【００１５】
前記機能オブシェクトは本発明によるパス障害復旧機能部２０で処理され、また前記情報オブジェクトはＳＤＨ＿ＶＣ１２−ＴＵ１２、ＳＤＨ＿ＶＣ３−ＡＵ３等の各伝送速度に対応したレイヤ単位２４〜２６で処理される。なお、本例では１つの機能オブジェクトが全てのレイヤを管理するが、複数の機能オブジェクトをレイヤ単位に配備してレイヤ毎の管理を行うように構成しても良い。
【００１６】
図４には、本発明による障害復旧制御の基本フロー例を示している。
ここでは、図３のパス障害復旧機能部２０における通信パス障害受信部２１、通信パス復旧対象選択部２２、及び通信パス復旧処理部２３の各部の動作を本制御フローを参照しながら説明する。
【００１７】
先ず、通信パス障害受信部２１が各サブネットワーク管理システム２〜４から収集したネットワーク情報によって障害パスを検出する（Ｓ１０１）。なお、各サブドメイン２〜４内で発生した通信パスの障害は、対応するサブネットワーク管理システムのエージェント２８が主ネットワーク管理システムのマネージャ２７に通知する。
【００１８】
次に、通信パス復旧対象選択部２２が、本発明により所定の評価関数に基づいて予備パス及びその予備パスが存在するレイヤを選択する。これにより、従来のように予め決められたレイヤ内や予備パス等から選択処理が開始されるのではなく、本発明では前記評価関数に基づいて通信パスの障害が発生した時点で最適と推定される予備パス及びその予備パスが存在するレイヤが、障害発生レイヤとの異同に係わらず直ちに選択される（Ｓ１０２及び１０３）。
【００１９】
その結果、通信パス復旧処理部２３が、対応するサブネットワーク管理システムのエージェント２８に対しマネージャ２７を介して前記評価関数に基づいて選択されたレイヤの予備パス設定指示、及び障害復旧処理の指示を行う（Ｓ１０４）。なお、図４には本発明のより具体的な例として前記評価関数に「障害パスの使用率」を用いた場合（Ｓ１０３）を合わせて示している。これについては、以下で説明する本発明の実施例で説明する。
【００２０】
本発明の第１の実施例として、先に示した図２の障害発生の場合に評価関数として図４の「障害パスの使用率」を用いる場合について説明する。また、図５にはその説明に用いるため通信パスの一構成例を示している。
図２に示すように、１５２Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ５の通信パス１１に障害が発生すると、それを主ネットワーク管理システム１の通信パス障害受信部２１が検出する（Ｓ１０１）。
【００２１】
通信パス復旧対象選択部２２は、評価関数「障害パスの使用率（α）」に基づき予備パス及びその予備パスが存在するレイヤを選択する。本例では、障害となった通信パスの使用率αが５０％以下の場合には、その通信パスが存在する同一レイヤ内での障害復旧処理は行わないと規定する。従って、使用率が５０％以下の場合は同一伝送速度の予備パスは使用されない。
＜評価関数１＞
障害パスの使用率＞＝α
【００２２】
図５の（ａ）には図２の各レイヤ５〜７に対応する通信パスの構成例を図式的に示しており、１５０Ｍ＿ＶＣ４−ＡＵ４レイヤ５の１本の通信パス（パスＡ）に５０Ｍ＿ＶＣ３−ＴＵ３レイヤ６の３本の通信パス（パスＡ−１〜３）が、そして５０Ｍ＿ＶＣ３−ＴＵ３レイヤ６の１本の通信パスに２Ｍ＿ＶＣ１２−ＴＵ１２レイヤ７の２１本の通信パス（パスＡ−３−１〜２１）がそれぞれ対応する。
【００２３】
図５の（ｂ）の例では、通信パスＡ、パスＡ−１、及びパスＡ−３がそれぞれ使用率５０％以下となっている。従って、これらの通信パスに障害が発生した時には図４のクライアントパス処理（Ｓ１０２及び１０３）が実行される。その他のパスについては従来の同一レイヤ内で予備パスに切り換える処理が行われる（Ｓ１０２及び１０４）。
【００２４】
例えば、パスＡは使用率４０％のためそのレイヤ５では障害復旧を行なわないで、障害パスＡを収容するクライアント側のより低速なパスＡ−１〜３が検索される（Ｓ１１１）。本例ではパスＡ−２の使用率は１００％のため同一レイヤ内での復旧対象パスとなるが、パスＡ−１，Ａ−３については使用率が５０％を満たしていないためパスＡの復旧対象パスとなる。この処理はさらにパスＡ−１，Ａ−３に収容されているパスについても同様に行われ、使用率５０％に満たないパスは復旧パスとして検索対象となる（Ｓ１１１〜１１４）。この処理を逐次繰り返すことで最終的に復旧対象パスが特定され（Ｓ１１５及び１１６）、そのパスを使った復旧処理が行われる。
【００２５】
ここで、各パスの「使用率」の情報には、図３で示した情報オブジェクト３１〜３６の内の通信パスの情報を管理するトレイル・オブジェクト（Ｔｒａｉｌ）３１の情報を使用する。パスの「使用率」は、下記（Ａ）に下線を付して示してあるようにトレイル・オブジェクト（Ｔｒａｉｌ）３１の属性情報の内のトラフィック項目（ｔｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎ）で管理されている。これらの使用率の情報はパスの開通／停止に伴ってアップデートされる。
【００２６】
（Ａ）Ｔｒａｉｌオブジェクト属性の一例
ＴｒａｉｌＩｄ
ｔｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎ ４０
ｏｐｅｒａｔｉｏｎａｌＳｔａｔｅ
ｄｉｒｅｃｔｉｏｎａｌｉｔｙ
ａＥｎｄＮＷＴＰＬｉｓｔ
ｚＥｎｄＮＷＴＰＬｉｓｔ
………
【００２７】
同様に、評価閾値のほうは、下記（Ｂ）に示すレイヤ内のネットワークドメインを管理するレイヤネットワークドメイン・オブジェクト（ｌａｙｅｒＮｅｔｗｏｒｋＤｏｍａｉｎ）３２の属性情報であるトラフィック閾値項目（ｔｒａｆｆｉｃＴｈｒｅｓｈｏｌｄ）で管理される。
（Ｂ）ｌａｙｅｒＮｅｔｗｏｒｋＤｏｍａｉｎオブジェクト属性の一例
ｌａｙｅｒＮｅｔｗｏｒｋＩｄ
ｔｒａｆｆｉｃＴｈｒｅｓｈｏｌｄ ５０
………
【００２８】
上記本発明の第１の実施例では評価関数として時間とともに変化する「使用率」を使用していたが、以下では本発明の第２の実施例としてより簡易な固定値である「契約帯域α」を使用する例について述べる。従って、評価関数は以下のようになる。
＜評価関数２＞
障害パスの契約帯域＞＝α
【００２９】
ここでは一例として、あるユーザが図５の通信パス６（ＶＣ３−ＴＵ３）の１本と、別の通信パス６に収容された４本の通信パス７（ＶＣ１２−ＴＵ１２）とを契約しているものとする。この場合、各通信パス６及び７の単位（ＶＣ３−ＴＵ３、ＶＣ１２−ＴＵ１２）における「契約帯域」はそれぞれ１００％である。
【００３０】
一方、通信パス６は通信パス７を２１本収容しているため、通信パス６の単位（ＶＣ３−ＴＵ３）でみると、前記４本の通信パス７が契約された通信パス６の契約帯域は１９％（＝４／２１×１００）である。本例ではこの「契約帯域」を第１の実施例の「使用率」と置き換えて、「障害パスの契約帯域」に基づく効率的な障害復旧処理を行なう。
【００３１】
図６は、通信パスの別の構成例を示したものである。ここでは、図６を用いて本発明の第３の実施例を説明する。
図５の通信パス構成例では物理的な伝送速度に対応した通信パスを障害復旧の対象としていたが、本構成例ではバーチャルパス（ＶＰ）をその対象とする。一例として、図５の（ａ）に示すように１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤの通信パス５内にＡＴＭ通信におけるの複数のバーチャルパス（ＶＰ）８が存在すると仮定する。
【００３２】
前記バーチャルパス８は種々の帯域を有しており、それらは帯域規定の一つである「ピークセルレート（ＰＣＲ）」によって管理される。ここでは、図４の「評価関数」として「ピークセル数α」を用いる。従って、図４の評価関数は以下のようになる。
＜評価関数３＞
全ＶＰのピークセル数＞＝α
【００３３】
例えば図６の（ｂ）に示すように、通信パス５内における全てのバーチャルパスのピークセルレートが１０万セルであり、評価関数として通信パス５のピークセルレート閾値（α）をα＝２０万セル数とした場合、各バーチャルパス１、２，３〜（ＶＰ１、２，３〜）のピークセルレート合計値は閾値に達しない。その結果、前記通信パス５が存在する１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ内での復旧処理は行われず、クライアント側のレイヤにおいてバーチャルパス単位の復旧処理が行われる。
【００３４】
以降で説明する本発明の第４〜７の各実施例は、これまで述べてきた本発明の実施例を前提とするが、それに新たな評価条件を付加することによって一層効率的な障害復旧処理を実現しようとするものである。先ず、本例では新たな評価条件として「クライアント側の復旧対象通信パス数β」を用いる。その場合、第１の実施例でいえば評価関数は以下のようになる。
〈評価関数４〉
障害パスの使用率＞＝α ＯＲ クライアント側の復旧対象通信パス数＞＝β
【００３５】
１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤの１本の通信パスは２Ｍ＿ＳＤＨ（ＶＣ１２−ＴＵ１２）レイヤの通信パスを６３本（＝３×２１）収容可能である。一例として、１５２Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤの通信パスの使用率が４８％（＝３０／６３×１００）であり、そして２Ｍ＿ＳＤＨ（ＶＣ１２−ＴＵ１２）レイヤの通信パスが３０本使用されていると仮定する。ここでは、第１の実施例の評価関数である「使用率（α）：５０％」を用いる。
【００３６】
この場合、第１の実施例によれば障害パスの使用率は４８％であるからそのレイヤでの障害復旧は行われずに障害パスＡを収容するクライアント側でパスの検索と復旧処理が行われことになる。しかしながら、本例では、新たな評価条件「クライアント側の復旧対象通信パス数＞＝β」でその閾値を「クライアント側の復旧対象パス数（β）＝２０」と規定した場合には、障害パスの数がクライアント側の復旧対象パス数より大きくなるため上記〈評価関数４〉の条件を満足しなくなる。従って、本例ではクライアント側でのパスの検索と復旧処理が行われず、障害パスの同一レイヤ内で障害復旧処理が行われる。
【００３７】
このように、本実施例によればクライアント側でのパス検索及び復旧処理に要する時間が評価要因として追加される。そのため、通信パスの物理的な空き容量と障害復旧処理時間とが総合的に評価され、予備パスの効率的な運用と障害処理の高速化による障害の拡大防止の両方を考慮した障害復旧処理が行われる。なお、上記評価関数における「クライアント側の復旧対象通信パス数＞＝β」を実施例１の評価関数として単独で用いることも可能である。
【００３８】
本発明の第５の実施例では、新たな評価条件として前述したレイヤネットワークドメイン・オブジェクト（ＬＮＤ）３２に本発明による新たな属性情報「迂回パス構成可否情報（ＸＣｉｎｆｏ属性）」を追加する。その一例を下記（Ｂ’）に示す。
（Ｂ’）ｌａｙｅｒＮｅｔｗｏｒｋＤｏｍａｉｎオブジェクト属性の一例
ｌａｙｅｒＮｅｔｗｏｒｋＩｄ
ｔｒａｆｆｉｃＴｈｒｅｓｈｏｌｄ ５０
ＸＣｉｎｆｏ＝Ｆａｌｓｅ
………
【００３９】
図７に前記ＸＣｉｎｆｏ属性を使った障害復旧処理の一例を示す。
先ずＶＣ４−ＡＵ４レイヤ５で通信パス１１の障害が発生する。そのレイヤの迂回パス構成可否情報は「ＸＣｉｎｆｏ＝ｔｒｕｅ」であるから、前述した「評価関数」が別レイヤを選択した場合にはクライアント側へパス検索・障害復旧処理が移行する。移行先のＶＣ３−ＴＵ３レイヤ６は、その迂回パス構成可否情報「ＸＣｉｎｆｏ＝ｆａｕｌｓｅ」によってレイヤ間にまたがる迂回パスが禁止されている。そのため、さらにクライアント側のＶＣ１２−ＴＵ１２レイヤ７へパス検索・障害復旧処理が移行する。ＶＣ１２−ＴＵ１２レイヤ７は「ＸＣｉｎｆｏ＝ｔｒｕｅ」であるから、そのレイヤでパス検索・障害復旧処理が開始される。
【００４０】
さらに本発明の第６の実施例では、前述したトレイル・オブジェクト（Ｔｒａｉｌ）３１に新たな評価条件としてプライオリティ情報（ｐｒｉｏｒｉｔｙ属性）を設ける。例えば、プライオリティ情報に１〜５の値（５：ｈｉｇｈ，１：ｌｏｗ）を付与し、その内で最も優先度の高い「プライオリティ値＝５」には、障害パスに収容される全ての抽出パスのうちでプライオリティ値＝５の通信パス障害だけを復旧させる旨の定義等をすることができる。
【００４１】
前記プライオリティ情報の一例を下記（Ａ’）に示す。
（Ａ’）Ｔｒａｉｌオブジェクト属性の一例
ＴｒａｉｌＩｄ
ｔｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎ ４０
ｐｒｉｏｒｉｔｙ ５
………
【００４２】
これまで述べた実施例は、すべて回線障害発生時に障害通信パスが存在する同一レイヤ内か又はクライアント側のより低速なレイヤにおいて障害回復処理を行うものであった。次に述べる本発明の第７の実施例は、ある条件下でサーバ側の高速レイヤを選択させることで、一層効率的で且つ柔軟な回線障害回復処理を可能とするものである。
【００４３】
図８は、複数回線障害時における回線障害処理の一例を示している。
図８では、サーバレイヤ側の１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ５に収容されたクライアント側の５０Ｍ＿ＳＤＨ（ＶＣ３−ＴＵ３）レイヤ６上で３本の通信パスに品質劣化等の障害が発生した場合を示している。本例ではこのように複数本（ｘ）の通信パス障害を同時に検出した場合には以下の評価関数を使って、サーバ側の高速レイヤ５で障害復旧を行なう。
【００４４】
〈評価関数〉
検出したレイヤの障害パス数＞＝ｘ
本例によれば、クライアント側で発生した複数本の通信パス障害時に、それらをまとめて収容可能なサーバ側の１本若しくはより少ない数の予備パスに切り換えることが可能となるため、それらの障害処理を同一レイヤ内か又はクライアント側のより低速なレイヤで行うよりも、遅延が少なく且つ効率的な予備パスの運用が可能となる。
【００４５】
このように、先に述べた本発明による第１〜３の実施例に、さらに上述した第４〜７の実施例を適用することで、通信パスのトラフィック状況、ネットワーク階層構成、及び回線の重要度等により柔軟で効率的に対応した回線障害回復処理を行うことが可能となる。なお、本発明による第４〜７の実施例を単独で適用することも当然に可能である。
【００４６】
図９及び１０は、これまで述べた本発明の各実施例を適宜組合せることにより効率的で且つ迅速な回線障害復旧処理を実現した障害復旧フロー例を示したものである。
本例では、障害パスの検出によって最初に収容パスのプライオリティを判断する（Ｓ２０１〜２０３）。高いプライオリティを有するパスについては優先的に障害復旧処理を行い（Ｓ２０６）、それに該当しないパスについてはサーバ側の属性情報ＸＣｉｎｆｏの判断、及び評価関数「同一レイヤの障害パス数＞＝ｘ」を判断する（Ｓ２０４）。
【００４７】
前記属性情報がＸＣｉｎｆｏ＝ｔｒｕｅでレイヤ間の障害処理が可能であり、且つｘ本以上の通信パス障害を検出した場合にはサーバ側で回線復旧処理を行う（Ｓ２０７）。この条件を満足しない場合には、次にクライアント側の属性情報Ｃｉｎｆｏの判断、及び評価関数「障害パスの使用率＞＝α ＯＲ クライアント側の復旧対象通信パス数＞＝β」を判断する（Ｓ２０５）。
【００４８】
前記クライアント側では、クライアントパスを検索し（Ｓ２０８）、さらにそのクライアントパスに対しても同様に属性情報Ｃｉｎｆｏの判断、及び評価関数「障害パスの使用率＞＝α ＯＲ クライアント側の復旧対象通信パス数＞＝β」を判断する（Ｓ２０９〜２１３）。これによって最も効率的且つ迅速処理が可能なクライアントパスを抽出し、その障害復旧処理を行う（Ｓ２１４）。
【００４９】
【発明の効果】
以上述べたように、本発明によれば多重化構造を有する通信パスにおいてパスの使用効率、復旧時間の両方を十分に考慮したレイヤ間の障害パス復旧処理が可能となる。
【００５０】
また、本発明によれば通信パス障害発生時にその回復処理の選択判断を、障害パスのトラフィック、トラフィックのピーク、予備パスの空き状況、障害処理の可否設定、回線重要度、障害パスの本数等、の種々の評価関数を用いて行うことによって、効率的、柔軟且つ迅速に障害回復処理を行うことが可能となる。
【図面の簡単な説明】
【図１】通信ネットワーク構成の一例を示した図である。
【図２】通信パスの多重化構造の一例を示した図である。
【図３】本発明による通信パスの障害復旧装置の基本構成例を示した図である。
【図４】本発明による障害復旧制御の基本フロー例を示した図である。
【図５】通信パスの一構成例を示した図である。
【図６】通信パスの別の構成例を示した図である。
【図７】ＸＣｉｎｆｏ属性を使った障害復旧処理の一例を示した図である。
【図８】複数回線障害時における回線障害処理の一例を示した図である。
【図９】本発明の組合せによる障害復旧フローの一例（１）を示した図である。
【図１０】実施例の組合せによる障害復旧フローの一例（２）を示した図である。
【符号の説明】
１…主ネットワーク管理システム
２〜４…サブネットワーク管理システム
５…１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ
６…５０Ｍ＿ＳＤＨ（ＶＣ３−ＴＵ３）レイヤ
７…２Ｍ＿ＳＤＨ（ＶＣ１２−ＴＵ１２）レイヤ
１１〜１５…通信パス
２０…パス障害復旧機能部
２４〜２６…情報オブジェクト部
２７…マネージャ
２８…エージェント
【発明の属する技術分野】
本発明は通信パスの障害復旧に関し、特に多重化構造で階層化された通信ネットワークにおける通信パスの障害復旧装置及びその方法に関するものである。
【０００２】
【従来の技術】
図１は通信ネットワーク構成の一例を示しており、また図２はその通信パスの多重化構造の一例を示している。
図１の（ｂ）に示すように、通信ネットワーク上にはＳＤＨ、ＰＤＨ及び図示した等の様々な伝送方式の通信装置が存在し、それらの間は種々の伝送速度の通信パスによって接続される。前記通信パスはまた図１の（ｃ）及びそれを階層表示した図２に示すように通信パスの多重化構造（２Ｍ＿ＳＤＨ、５０Ｍ＿ＳＤＨ、１５０Ｍ＿ＳＤＨ等）に基づいて階層化５〜７されている。
【０００３】
近年、ネットワーク通信網の形態も複雑化され、アクセス網、基幹網、ＰＤＨ網、及びＳＤＨ網等に分割された多種多様なドメインが存在している。図１の（ａ）に示すように各ドメインは内部のクロスコネクト装置等を管理するサブネットワーク管理システム（Ｓｕｂ−ＮＭＳ）２〜４によって管理され、それらはさらに主ネットワーク管理システム（Ｍａｉｎ−ＮＭＳ）１によって管理されている。ＩＴＵ−Ｔ勧告Ｇ．８０５ではこのような複雑な通信パスの管理をレイヤリング（階層構造）の関係を用いて整理する動きが見られる。
【０００４】
ここで、図２に×印で示すように１５０Ｍ＿ＳＤＨレイヤ５上で１５０Mb／ｓの通信パス１１（通信パスＡ）に断線等の障害が発生すると、従来においては前記障害からの早期復旧のために障害が発生した同一レイヤ５内の予備パスを使って前記通信パスの迂回パス１２及び１３を形成していた。もし、同一レイヤ内で復旧できない場合には、障害パスを収容するクライアント側のレイヤ６、７等においてより低速な５０Mb／ｓパスや２Mb／ｓパスを使って復旧が行われていた。
【０００５】
【発明が解決しようとする課題】
上述したように、従来においては伝送速度が高速のレイヤで通信パスの障害が発生した時に先ず同一レイヤ内でその障害復旧が行なわれるため、予め全ての通信パスに高速の予備パスを張っておく必要があった。そのため、例えば障害発生前の前記通信パス１１が全帯域の１０％しか使用していない場合であっても、その迂回路形成のために同じ１５０Mb／ｓの予備パスを用意しておく必要があった。
【０００６】
また、前記１０％の使用率しかない通信パスの障害に一旦割り当てられた１５０Mb／ｓの予備パスは、その後に発生した前記予備パスの使用を本当に必要とする使用率８０％の通信パスの障害に対して割り当てることができなかった。
このように、従来においては通信パス障害に対する予備容量設計の効率が極めて低いという問題があった。
【０００７】
一方、上述したように同一レイヤ内で障害復旧できない場合には、その高速のパスに収容されている低速パスの側での障害復旧が試みられる。この場合、高速レイヤで余分な予備パスを張らなくてすむため予備容量の設計効率は改善される。しかしながら、従来においては低速レイヤ側における多くのパスがその復旧使用の対象となるため障害復旧処理に膨大な時間が係り、かえって障害の影響を拡大させるという問題があった。
【０００８】
そこで本発明の目的は、上記種々の問題に鑑み、通信パスの開設／停止等により流動的に変わる通信ネットワークにおいて、所定の評価関数を用いることによって障害復旧に最適な通信パスを備えたレイヤ及びその通信パスとを適宜選択する通信パスの障害復旧装置及びその方法を提供することにある。その結果、通信パス障害に対する予備容量設計効率が顕著に改善され、且つ迅速な障害復旧が可能となる。
【０００９】
【課題を解決するための手段】
本発明によれば、通信パスが多重化された階層化構造を有する通信ネットワークにおける通信パスの障害復旧装置であって、前記装置は、ネットワーク収集情報によって障害パスを検出する通信パス障害受信部と、前記障害パスに関連する情報を所定の評価関数で判断した結果に基づいて動的に前記障害パスの障害復旧処理を行うための通信レイヤ及びそのレイヤ上の通信パスを選択する通信パス復旧対象選択部と、前記選択された通信レイヤ上の通信パスを使って前記障害パスの障害復旧処理を行う通信パス復旧処理部と、で構成される通信パスの障害復旧装置が提供される。
【００１０】
前記通信パス復旧対象選択部は、前記選択された通信レイヤにおいてさらに前記評価関数による判断を繰り返し、それによって前記障害パスの障害復旧処理を行うための通信レイヤ及びそのレイヤ上の通信パスを選択する。そして、前記評価関数は、前記障害パスが存在する同一レイヤ内でその障害復旧処理を行うか、又はそのパスを収容する他のレイヤのパスを用いて障害復旧処理を行うかの選択判断を行う。
【００１１】
前記評価関数は、障害パスのトラフィック使用率によって前記判断を行い、前記使用率が所定の閾値以下の場合にはクライアント側のレイヤのパスによる障害復旧処理を選択する。前記使用率には、ユーザとの契約帯域による全帯域の割合、ＡＴＭ通信におけるピークセルレートが含まれる。さらに、前記クライアント側の復旧対象パス数が所定値以上の場合には、前記クライアント側の選択が無効とされ、障害パスの同一レイヤ内で障害復旧処理が行われる。
【００１２】
また、前記評価関数は、所定数を超える複数パスの障害発生時にはそのサーバ側のパスを選択する。
前記通信パス復旧対象選択部はさらに迂回パス構成可否情報を有し、前記評価関数は前記迂回パス構成可否情報が否の場合に他のレイヤを選択する。前記通信パス復旧対象選択部はさらに各通信パスに付与したプライオリティ情報を有し、前記評価関数はプライオリティの高い通信パス障害に対し優先的に同一レイヤ内の処理を選択する。
【００１３】
【発明の実施の形態】
図３は、本発明による通信パスの障害復旧装置の基本構成例を示したものである。
図３では、本発明による通信パスの障害復旧装置の機能が主ネットワーク管理システム（Ｍａｉｎ−ＮＭＳ）１内のパス障害復旧機能部２０として備えられる。主ネットワーク管理システム１には複数のサブネットワーク管理システム（Ｓｕｂ−ＮＭＳ）２〜４が接続され、それらの間の通信は前者のマネージャ（Ｍａｎａｇｅｒ）２４と後者のエージェント（Ａｇｅｎｔ）２５とによって行われる。
【００１４】
主ネットワーク管理システム１は、サブネットワーク管理システム２〜４からネットワーク情報を収集したり、各サブネットワークのクロスコネクトに対する制御指示を与える等のネットワーク全体の制御及び管理を行う。これらは大きくネットワークの制御等を行なう機能オブジェクト（本例では２１〜２３に相当）とネットワーク情報等を管理する情報オブジェクト３１〜３６の２つのオブジェクトによって実現される。
【００１５】
前記機能オブシェクトは本発明によるパス障害復旧機能部２０で処理され、また前記情報オブジェクトはＳＤＨ＿ＶＣ１２−ＴＵ１２、ＳＤＨ＿ＶＣ３−ＡＵ３等の各伝送速度に対応したレイヤ単位２４〜２６で処理される。なお、本例では１つの機能オブジェクトが全てのレイヤを管理するが、複数の機能オブジェクトをレイヤ単位に配備してレイヤ毎の管理を行うように構成しても良い。
【００１６】
図４には、本発明による障害復旧制御の基本フロー例を示している。
ここでは、図３のパス障害復旧機能部２０における通信パス障害受信部２１、通信パス復旧対象選択部２２、及び通信パス復旧処理部２３の各部の動作を本制御フローを参照しながら説明する。
【００１７】
先ず、通信パス障害受信部２１が各サブネットワーク管理システム２〜４から収集したネットワーク情報によって障害パスを検出する（Ｓ１０１）。なお、各サブドメイン２〜４内で発生した通信パスの障害は、対応するサブネットワーク管理システムのエージェント２８が主ネットワーク管理システムのマネージャ２７に通知する。
【００１８】
次に、通信パス復旧対象選択部２２が、本発明により所定の評価関数に基づいて予備パス及びその予備パスが存在するレイヤを選択する。これにより、従来のように予め決められたレイヤ内や予備パス等から選択処理が開始されるのではなく、本発明では前記評価関数に基づいて通信パスの障害が発生した時点で最適と推定される予備パス及びその予備パスが存在するレイヤが、障害発生レイヤとの異同に係わらず直ちに選択される（Ｓ１０２及び１０３）。
【００１９】
その結果、通信パス復旧処理部２３が、対応するサブネットワーク管理システムのエージェント２８に対しマネージャ２７を介して前記評価関数に基づいて選択されたレイヤの予備パス設定指示、及び障害復旧処理の指示を行う（Ｓ１０４）。なお、図４には本発明のより具体的な例として前記評価関数に「障害パスの使用率」を用いた場合（Ｓ１０３）を合わせて示している。これについては、以下で説明する本発明の実施例で説明する。
【００２０】
本発明の第１の実施例として、先に示した図２の障害発生の場合に評価関数として図４の「障害パスの使用率」を用いる場合について説明する。また、図５にはその説明に用いるため通信パスの一構成例を示している。
図２に示すように、１５２Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ５の通信パス１１に障害が発生すると、それを主ネットワーク管理システム１の通信パス障害受信部２１が検出する（Ｓ１０１）。
【００２１】
通信パス復旧対象選択部２２は、評価関数「障害パスの使用率（α）」に基づき予備パス及びその予備パスが存在するレイヤを選択する。本例では、障害となった通信パスの使用率αが５０％以下の場合には、その通信パスが存在する同一レイヤ内での障害復旧処理は行わないと規定する。従って、使用率が５０％以下の場合は同一伝送速度の予備パスは使用されない。
＜評価関数１＞
障害パスの使用率＞＝α
【００２２】
図５の（ａ）には図２の各レイヤ５〜７に対応する通信パスの構成例を図式的に示しており、１５０Ｍ＿ＶＣ４−ＡＵ４レイヤ５の１本の通信パス（パスＡ）に５０Ｍ＿ＶＣ３−ＴＵ３レイヤ６の３本の通信パス（パスＡ−１〜３）が、そして５０Ｍ＿ＶＣ３−ＴＵ３レイヤ６の１本の通信パスに２Ｍ＿ＶＣ１２−ＴＵ１２レイヤ７の２１本の通信パス（パスＡ−３−１〜２１）がそれぞれ対応する。
【００２３】
図５の（ｂ）の例では、通信パスＡ、パスＡ−１、及びパスＡ−３がそれぞれ使用率５０％以下となっている。従って、これらの通信パスに障害が発生した時には図４のクライアントパス処理（Ｓ１０２及び１０３）が実行される。その他のパスについては従来の同一レイヤ内で予備パスに切り換える処理が行われる（Ｓ１０２及び１０４）。
【００２４】
例えば、パスＡは使用率４０％のためそのレイヤ５では障害復旧を行なわないで、障害パスＡを収容するクライアント側のより低速なパスＡ−１〜３が検索される（Ｓ１１１）。本例ではパスＡ−２の使用率は１００％のため同一レイヤ内での復旧対象パスとなるが、パスＡ−１，Ａ−３については使用率が５０％を満たしていないためパスＡの復旧対象パスとなる。この処理はさらにパスＡ−１，Ａ−３に収容されているパスについても同様に行われ、使用率５０％に満たないパスは復旧パスとして検索対象となる（Ｓ１１１〜１１４）。この処理を逐次繰り返すことで最終的に復旧対象パスが特定され（Ｓ１１５及び１１６）、そのパスを使った復旧処理が行われる。
【００２５】
ここで、各パスの「使用率」の情報には、図３で示した情報オブジェクト３１〜３６の内の通信パスの情報を管理するトレイル・オブジェクト（Ｔｒａｉｌ）３１の情報を使用する。パスの「使用率」は、下記（Ａ）に下線を付して示してあるようにトレイル・オブジェクト（Ｔｒａｉｌ）３１の属性情報の内のトラフィック項目（ｔｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎ）で管理されている。これらの使用率の情報はパスの開通／停止に伴ってアップデートされる。
【００２６】
（Ａ）Ｔｒａｉｌオブジェクト属性の一例
ＴｒａｉｌＩｄ
ｔｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎ ４０
ｏｐｅｒａｔｉｏｎａｌＳｔａｔｅ
ｄｉｒｅｃｔｉｏｎａｌｉｔｙ
ａＥｎｄＮＷＴＰＬｉｓｔ
ｚＥｎｄＮＷＴＰＬｉｓｔ
………
【００２７】
同様に、評価閾値のほうは、下記（Ｂ）に示すレイヤ内のネットワークドメインを管理するレイヤネットワークドメイン・オブジェクト（ｌａｙｅｒＮｅｔｗｏｒｋＤｏｍａｉｎ）３２の属性情報であるトラフィック閾値項目（ｔｒａｆｆｉｃＴｈｒｅｓｈｏｌｄ）で管理される。
（Ｂ）ｌａｙｅｒＮｅｔｗｏｒｋＤｏｍａｉｎオブジェクト属性の一例
ｌａｙｅｒＮｅｔｗｏｒｋＩｄ
ｔｒａｆｆｉｃＴｈｒｅｓｈｏｌｄ ５０
………
【００２８】
上記本発明の第１の実施例では評価関数として時間とともに変化する「使用率」を使用していたが、以下では本発明の第２の実施例としてより簡易な固定値である「契約帯域α」を使用する例について述べる。従って、評価関数は以下のようになる。
＜評価関数２＞
障害パスの契約帯域＞＝α
【００２９】
ここでは一例として、あるユーザが図５の通信パス６（ＶＣ３−ＴＵ３）の１本と、別の通信パス６に収容された４本の通信パス７（ＶＣ１２−ＴＵ１２）とを契約しているものとする。この場合、各通信パス６及び７の単位（ＶＣ３−ＴＵ３、ＶＣ１２−ＴＵ１２）における「契約帯域」はそれぞれ１００％である。
【００３０】
一方、通信パス６は通信パス７を２１本収容しているため、通信パス６の単位（ＶＣ３−ＴＵ３）でみると、前記４本の通信パス７が契約された通信パス６の契約帯域は１９％（＝４／２１×１００）である。本例ではこの「契約帯域」を第１の実施例の「使用率」と置き換えて、「障害パスの契約帯域」に基づく効率的な障害復旧処理を行なう。
【００３１】
図６は、通信パスの別の構成例を示したものである。ここでは、図６を用いて本発明の第３の実施例を説明する。
図５の通信パス構成例では物理的な伝送速度に対応した通信パスを障害復旧の対象としていたが、本構成例ではバーチャルパス（ＶＰ）をその対象とする。一例として、図５の（ａ）に示すように１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤの通信パス５内にＡＴＭ通信におけるの複数のバーチャルパス（ＶＰ）８が存在すると仮定する。
【００３２】
前記バーチャルパス８は種々の帯域を有しており、それらは帯域規定の一つである「ピークセルレート（ＰＣＲ）」によって管理される。ここでは、図４の「評価関数」として「ピークセル数α」を用いる。従って、図４の評価関数は以下のようになる。
＜評価関数３＞
全ＶＰのピークセル数＞＝α
【００３３】
例えば図６の（ｂ）に示すように、通信パス５内における全てのバーチャルパスのピークセルレートが１０万セルであり、評価関数として通信パス５のピークセルレート閾値（α）をα＝２０万セル数とした場合、各バーチャルパス１、２，３〜（ＶＰ１、２，３〜）のピークセルレート合計値は閾値に達しない。その結果、前記通信パス５が存在する１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ内での復旧処理は行われず、クライアント側のレイヤにおいてバーチャルパス単位の復旧処理が行われる。
【００３４】
以降で説明する本発明の第４〜７の各実施例は、これまで述べてきた本発明の実施例を前提とするが、それに新たな評価条件を付加することによって一層効率的な障害復旧処理を実現しようとするものである。先ず、本例では新たな評価条件として「クライアント側の復旧対象通信パス数β」を用いる。その場合、第１の実施例でいえば評価関数は以下のようになる。
〈評価関数４〉
障害パスの使用率＞＝α ＯＲ クライアント側の復旧対象通信パス数＞＝β
【００３５】
１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤの１本の通信パスは２Ｍ＿ＳＤＨ（ＶＣ１２−ＴＵ１２）レイヤの通信パスを６３本（＝３×２１）収容可能である。一例として、１５２Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤの通信パスの使用率が４８％（＝３０／６３×１００）であり、そして２Ｍ＿ＳＤＨ（ＶＣ１２−ＴＵ１２）レイヤの通信パスが３０本使用されていると仮定する。ここでは、第１の実施例の評価関数である「使用率（α）：５０％」を用いる。
【００３６】
この場合、第１の実施例によれば障害パスの使用率は４８％であるからそのレイヤでの障害復旧は行われずに障害パスＡを収容するクライアント側でパスの検索と復旧処理が行われことになる。しかしながら、本例では、新たな評価条件「クライアント側の復旧対象通信パス数＞＝β」でその閾値を「クライアント側の復旧対象パス数（β）＝２０」と規定した場合には、障害パスの数がクライアント側の復旧対象パス数より大きくなるため上記〈評価関数４〉の条件を満足しなくなる。従って、本例ではクライアント側でのパスの検索と復旧処理が行われず、障害パスの同一レイヤ内で障害復旧処理が行われる。
【００３７】
このように、本実施例によればクライアント側でのパス検索及び復旧処理に要する時間が評価要因として追加される。そのため、通信パスの物理的な空き容量と障害復旧処理時間とが総合的に評価され、予備パスの効率的な運用と障害処理の高速化による障害の拡大防止の両方を考慮した障害復旧処理が行われる。なお、上記評価関数における「クライアント側の復旧対象通信パス数＞＝β」を実施例１の評価関数として単独で用いることも可能である。
【００３８】
本発明の第５の実施例では、新たな評価条件として前述したレイヤネットワークドメイン・オブジェクト（ＬＮＤ）３２に本発明による新たな属性情報「迂回パス構成可否情報（ＸＣｉｎｆｏ属性）」を追加する。その一例を下記（Ｂ’）に示す。
（Ｂ’）ｌａｙｅｒＮｅｔｗｏｒｋＤｏｍａｉｎオブジェクト属性の一例
ｌａｙｅｒＮｅｔｗｏｒｋＩｄ
ｔｒａｆｆｉｃＴｈｒｅｓｈｏｌｄ ５０
ＸＣｉｎｆｏ＝Ｆａｌｓｅ
………
【００３９】
図７に前記ＸＣｉｎｆｏ属性を使った障害復旧処理の一例を示す。
先ずＶＣ４−ＡＵ４レイヤ５で通信パス１１の障害が発生する。そのレイヤの迂回パス構成可否情報は「ＸＣｉｎｆｏ＝ｔｒｕｅ」であるから、前述した「評価関数」が別レイヤを選択した場合にはクライアント側へパス検索・障害復旧処理が移行する。移行先のＶＣ３−ＴＵ３レイヤ６は、その迂回パス構成可否情報「ＸＣｉｎｆｏ＝ｆａｕｌｓｅ」によってレイヤ間にまたがる迂回パスが禁止されている。そのため、さらにクライアント側のＶＣ１２−ＴＵ１２レイヤ７へパス検索・障害復旧処理が移行する。ＶＣ１２−ＴＵ１２レイヤ７は「ＸＣｉｎｆｏ＝ｔｒｕｅ」であるから、そのレイヤでパス検索・障害復旧処理が開始される。
【００４０】
さらに本発明の第６の実施例では、前述したトレイル・オブジェクト（Ｔｒａｉｌ）３１に新たな評価条件としてプライオリティ情報（ｐｒｉｏｒｉｔｙ属性）を設ける。例えば、プライオリティ情報に１〜５の値（５：ｈｉｇｈ，１：ｌｏｗ）を付与し、その内で最も優先度の高い「プライオリティ値＝５」には、障害パスに収容される全ての抽出パスのうちでプライオリティ値＝５の通信パス障害だけを復旧させる旨の定義等をすることができる。
【００４１】
前記プライオリティ情報の一例を下記（Ａ’）に示す。
（Ａ’）Ｔｒａｉｌオブジェクト属性の一例
ＴｒａｉｌＩｄ
ｔｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎ ４０
ｐｒｉｏｒｉｔｙ ５
………
【００４２】
これまで述べた実施例は、すべて回線障害発生時に障害通信パスが存在する同一レイヤ内か又はクライアント側のより低速なレイヤにおいて障害回復処理を行うものであった。次に述べる本発明の第７の実施例は、ある条件下でサーバ側の高速レイヤを選択させることで、一層効率的で且つ柔軟な回線障害回復処理を可能とするものである。
【００４３】
図８は、複数回線障害時における回線障害処理の一例を示している。
図８では、サーバレイヤ側の１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ５に収容されたクライアント側の５０Ｍ＿ＳＤＨ（ＶＣ３−ＴＵ３）レイヤ６上で３本の通信パスに品質劣化等の障害が発生した場合を示している。本例ではこのように複数本（ｘ）の通信パス障害を同時に検出した場合には以下の評価関数を使って、サーバ側の高速レイヤ５で障害復旧を行なう。
【００４４】
〈評価関数〉
検出したレイヤの障害パス数＞＝ｘ
本例によれば、クライアント側で発生した複数本の通信パス障害時に、それらをまとめて収容可能なサーバ側の１本若しくはより少ない数の予備パスに切り換えることが可能となるため、それらの障害処理を同一レイヤ内か又はクライアント側のより低速なレイヤで行うよりも、遅延が少なく且つ効率的な予備パスの運用が可能となる。
【００４５】
このように、先に述べた本発明による第１〜３の実施例に、さらに上述した第４〜７の実施例を適用することで、通信パスのトラフィック状況、ネットワーク階層構成、及び回線の重要度等により柔軟で効率的に対応した回線障害回復処理を行うことが可能となる。なお、本発明による第４〜７の実施例を単独で適用することも当然に可能である。
【００４６】
図９及び１０は、これまで述べた本発明の各実施例を適宜組合せることにより効率的で且つ迅速な回線障害復旧処理を実現した障害復旧フロー例を示したものである。
本例では、障害パスの検出によって最初に収容パスのプライオリティを判断する（Ｓ２０１〜２０３）。高いプライオリティを有するパスについては優先的に障害復旧処理を行い（Ｓ２０６）、それに該当しないパスについてはサーバ側の属性情報ＸＣｉｎｆｏの判断、及び評価関数「同一レイヤの障害パス数＞＝ｘ」を判断する（Ｓ２０４）。
【００４７】
前記属性情報がＸＣｉｎｆｏ＝ｔｒｕｅでレイヤ間の障害処理が可能であり、且つｘ本以上の通信パス障害を検出した場合にはサーバ側で回線復旧処理を行う（Ｓ２０７）。この条件を満足しない場合には、次にクライアント側の属性情報Ｃｉｎｆｏの判断、及び評価関数「障害パスの使用率＞＝α ＯＲ クライアント側の復旧対象通信パス数＞＝β」を判断する（Ｓ２０５）。
【００４８】
前記クライアント側では、クライアントパスを検索し（Ｓ２０８）、さらにそのクライアントパスに対しても同様に属性情報Ｃｉｎｆｏの判断、及び評価関数「障害パスの使用率＞＝α ＯＲ クライアント側の復旧対象通信パス数＞＝β」を判断する（Ｓ２０９〜２１３）。これによって最も効率的且つ迅速処理が可能なクライアントパスを抽出し、その障害復旧処理を行う（Ｓ２１４）。
【００４９】
【発明の効果】
以上述べたように、本発明によれば多重化構造を有する通信パスにおいてパスの使用効率、復旧時間の両方を十分に考慮したレイヤ間の障害パス復旧処理が可能となる。
【００５０】
また、本発明によれば通信パス障害発生時にその回復処理の選択判断を、障害パスのトラフィック、トラフィックのピーク、予備パスの空き状況、障害処理の可否設定、回線重要度、障害パスの本数等、の種々の評価関数を用いて行うことによって、効率的、柔軟且つ迅速に障害回復処理を行うことが可能となる。
【図面の簡単な説明】
【図１】通信ネットワーク構成の一例を示した図である。
【図２】通信パスの多重化構造の一例を示した図である。
【図３】本発明による通信パスの障害復旧装置の基本構成例を示した図である。
【図４】本発明による障害復旧制御の基本フロー例を示した図である。
【図５】通信パスの一構成例を示した図である。
【図６】通信パスの別の構成例を示した図である。
【図７】ＸＣｉｎｆｏ属性を使った障害復旧処理の一例を示した図である。
【図８】複数回線障害時における回線障害処理の一例を示した図である。
【図９】本発明の組合せによる障害復旧フローの一例（１）を示した図である。
【図１０】実施例の組合せによる障害復旧フローの一例（２）を示した図である。
【符号の説明】
１…主ネットワーク管理システム
２〜４…サブネットワーク管理システム
５…１５０Ｍ＿ＳＤＨ（ＶＣ４−ＡＵ４）レイヤ
６…５０Ｍ＿ＳＤＨ（ＶＣ３−ＴＵ３）レイヤ
７…２Ｍ＿ＳＤＨ（ＶＣ１２−ＴＵ１２）レイヤ
１１〜１５…通信パス
２０…パス障害復旧機能部
２４〜２６…情報オブジェクト部
２７…マネージャ
２８…エージェント
Claims (8)
- 通信パスが多重化された階層化構造を有する通信ネットワークにおける通信パスの障害復旧装置であって、前記装置は
ネットワーク収集情報によって障害パスを検出する通信パス障害受信部と、
前記障害パスに関連する情報を所定の評価関数で判断した結果に基づいて動的に前記障害パスの障害復旧処理を行うための通信レイヤ及びそのレイヤ上の通信パスを選択する通信パス復旧対象選択部と、
前記選択された通信レイヤ上の通信パスを使って前記障害パスの障害復旧処理を行う通信パス復旧処理部と、で構成され、
前記評価関数は、障害パスのトラフィック使用率によって前記障害パスが存在する同一レイヤ内でその障害復旧処理を行うか、又はそのパスを収容する他のレイヤのパスを用いて障害復旧処理を行うかの選択判断を行い、前記使用率が所定の閾値以下の場合にはクライアント側のレイヤのパスによる障害復旧処理を選択する判断を行うことを特徴とする通信パスの障害復旧装置。 - 前記通信パス復旧対象選択部は、前記選択された通信レイヤにおいてさらに前記評価関数による判断を繰り返し、それによって前記障害パスの障害復旧処理を行うための通信レイヤ及びそのレイヤ上の通信パスを選択する請求項１記載の装置。
- 前記使用率には、ユーザとの契約帯域による全帯域の割合が含まれる請求項１記載の装置。
- 前記使用率には、ＡＴＭ通信におけるピークセルレートが含まれる請求項１記載の装置。
- さらに、前記クライアント側の復旧対象パス数が所定値以上の場合には、前記クライアント側の選択を無効とし、障害パスの同一レイヤ内で障害復旧処理を行なう請求項１〜４のいずれか一つに記載の装置。
- 前記評価関数は、さらに所定数を超える複数パスの障害発生時にはそのサーバ側のパスを選択する請求項１に記載の装置。
- 前記通信パス復旧対象選択部はさらに迂回パス構成可否情報を有し、前記評価関数は前記迂回パス構成可否情報が否の場合に他のレイヤを選択する請求項１記載の装置。
- 前記通信パス復旧対象選択部はさらに各通信パスに付与したプライオリティ情報を有し、前記評価関数はプライオリティの高い通信パス障害に対し優先的に同一レイヤ内の処理を選択する請求項１記載の装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8121699A JP3871467B2 (ja) | 1999-03-25 | 1999-03-25 | 通信パスの障害復旧装置 |
| US09/533,481 US6718480B1 (en) | 1999-03-25 | 2000-03-23 | Communication path fault restoration system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8121699A JP3871467B2 (ja) | 1999-03-25 | 1999-03-25 | 通信パスの障害復旧装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000278285A JP2000278285A (ja) | 2000-10-06 |
| JP3871467B2 true JP3871467B2 (ja) | 2007-01-24 |
Family
ID=13740300
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8121699A Expired - Fee Related JP3871467B2 (ja) | 1999-03-25 | 1999-03-25 | 通信パスの障害復旧装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6718480B1 (ja) |
| JP (1) | JP3871467B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7352692B1 (en) * | 1999-01-15 | 2008-04-01 | Cisco Technology, Inc. | Resource reservation scheme for path restoration in an optical network |
| US6856627B2 (en) * | 1999-01-15 | 2005-02-15 | Cisco Technology, Inc. | Method for routing information over a network |
| US7764596B2 (en) * | 2001-05-16 | 2010-07-27 | Cisco Technology, Inc. | Method for restoring a virtual path in an optical network using dynamic unicast |
| US7050391B1 (en) * | 2000-12-22 | 2006-05-23 | Turin Networks | Method and apparatus for efficient link redundancy |
| US7152178B1 (en) * | 2001-03-22 | 2006-12-19 | Emc Corporation | Method and system for detecting path failure and performing input/output recovery in a multi-path input/output system |
| JP3587250B2 (ja) | 2001-04-27 | 2004-11-10 | 日本電気株式会社 | 自動障害回復を行う通信装置及び自動障害回復方法 |
| US6999468B2 (en) * | 2001-06-04 | 2006-02-14 | Turin Networks | Method and apparatus for line and path selection within SONET/SDH based networks |
| US6931564B2 (en) * | 2001-07-13 | 2005-08-16 | International Business Machines Corporation | Failure isolation in a distributed processing system employing relative location information |
| US6865695B2 (en) * | 2001-07-26 | 2005-03-08 | International Business Machines Corpoation | Robust system bus recovery |
| US20030158925A1 (en) * | 2002-01-18 | 2003-08-21 | Uniacke Mark J. | Management of communications networks |
| WO2006131020A1 (fr) * | 2005-06-06 | 2006-12-14 | Zte Corporation | Procede d'harmonisation pour la restauration de la protection entre reseaux de niveau median dans un reseau optique a commutation automatique |
| KR100960516B1 (ko) | 2008-04-28 | 2010-06-03 | 한국기술교육대학교 산학협력단 | 무선 네트워크의 라우팅 복구 방법 |
| JP6311612B2 (ja) * | 2012-11-16 | 2018-04-18 | 日本電気株式会社 | 通信システム、制御装置、その制御方法及びプログラム |
| WO2015045466A1 (ja) * | 2013-09-30 | 2015-04-02 | 日本電気株式会社 | 通信制御装置、通信制御システム、通信制御方法及び通信制御プログラム |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2180171A5 (ja) * | 1972-04-11 | 1973-11-23 | Materiel Telephonique | |
| JP2937232B2 (ja) * | 1996-05-20 | 1999-08-23 | 日本電気株式会社 | 通信ネットワーク、及び、通信ネットワークの障害回復方式、及び、光通信ネットワーク・ノード |
| JP2933021B2 (ja) | 1996-08-20 | 1999-08-09 | 日本電気株式会社 | 通信網障害回復方式 |
| US6314525B1 (en) * | 1997-05-13 | 2001-11-06 | 3Com Corporation | Means for allowing two or more network interface controller cards to appear as one card to an operating system |
| US6308282B1 (en) * | 1998-11-10 | 2001-10-23 | Honeywell International Inc. | Apparatus and methods for providing fault tolerance of networks and network interface cards |
| US6370654B1 (en) * | 1998-12-17 | 2002-04-09 | Northern Telecom Limited | Method and apparatus to extend the fault-tolerant abilities of a node into a network |
| US6275578B1 (en) * | 1998-12-23 | 2001-08-14 | At&T Corp. | Method and apparatus for providing back-up, in-band signaling in a communications network |
-
1999
- 1999-03-25 JP JP8121699A patent/JP3871467B2/ja not_active Expired - Fee Related
-
2000
- 2000-03-23 US US09/533,481 patent/US6718480B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000278285A (ja) | 2000-10-06 |
| US6718480B1 (en) | 2004-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3871467B2 (ja) | 通信パスの障害復旧装置 | |
| JP2933021B2 (ja) | 通信網障害回復方式 | |
| US6061735A (en) | Network restoration plan regeneration responsive to network topology changes | |
| US7924705B2 (en) | Method and system for span-based connection aggregation | |
| EP1563649A2 (en) | Protection against the effect of equipment failure in a communications system | |
| US20020114031A1 (en) | Ring configuration method, failure recovery method, and node address assignment method when configuring ring in network | |
| US20020141334A1 (en) | Dynamic protection bandwidth allocation in BLSR networks | |
| US8693318B2 (en) | Shared bandwidth reservation in PL, ATM, FR and IP/MPLS networks | |
| WO1999000913A2 (en) | Method and system for augmenting a communications network with spare capacity | |
| Li et al. | Fiber span failure protection in mesh optical networks | |
| US6337846B1 (en) | Quantification of the quality of spare links in a telecommunications network | |
| Grover et al. | Comparative methods and issues in design of mesh-restorable STM and ATM networks | |
| US6580689B1 (en) | Method and apparatus for generating intranode alternate route | |
| Saniee | Optimal Routing Designs in Self‐healing Communications Networks | |
| Veerasamy et al. | Spare capacity assignment in telecom networks using path restoration | |
| Gersht et al. | Real-time bandwidth allocation and path restorations in SONET-based self-healing mesh networks | |
| Murakami | Survivable network management for high-speed ATM networks | |
| Naser et al. | Availability analysis and simulation of mesh restoration networks | |
| Gryseels et al. | Common pool survivability for meshed SDH-based ATM networks | |
| Marzo et al. | Atm network management based on distributed artificial intelligence architecture | |
| Xiong et al. | On state-independent and state-dependent path restoration in self-healing networks | |
| Veitch et al. | A distributed protocol for fast and robust virtual path restoration | |
| Panicker et al. | An improved scheme for self-healing in ATM networks | |
| Sreenath et al. | Design of survivable WDM networks for carrying ATM traffic | |
| Noh | Reconfiguration for capacity efficiency and restoration in ATM networks based on virtual paths |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041105 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060612 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060620 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060817 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060919 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061017 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091027 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131027 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |