JPH07115420A - Ａｔｍ網におけるコネクションのセルフヒーリング方法 - Google Patents

Abstract

(57)【要約】 【目的】 制御用に別線を使用せずに故障時の動的なコ
ネクション救済を可能にするＡＴＭ網におけるコネクシ
ョンのセルフヒーリング方法を提供すること。 【構成】 本発明では、コネクションや網に関する情報
が各交換機に分散管理され、各交換機は他との間に設け
た管理コネクションを用いて網資源の管理などを行うＡ
ＴＭ網において、交換機がコネクション障害を検出する
ステップと、故障箇所に対応して決められた障害時の救
済手続きに従って障害を受けた管理コネクションの回復
を自立分散的に行うステップと、回復した管理コネクシ
ョンを用いて他の交換機に格納された前記統計情報、ユ
ーザコネクション救済の優先度情報などを収集するステ
ップと、それら情報を元にして救済するユーザコネクシ
ョンや迂回経路などを決定するステップと、該決定内容
に従いユーザコネクションの回復を行うステップとを有
することを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ＡＴＭ通信ネットワー
クに関する。

【０００２】

【従来の技術】複数の装置からなる通信網で、それを構
成する一部の装置が故障したとき、網が自律的に網の機
能を維持するための措置を行うことをセルフヒーリング
という。多くの場合セルフヒーリングの対象は網が提供
するコネクション機能である。コネクションについてセ
ルフヒーリングを行うことをコネクションを救済すると
いう。

【０００３】ＡＴＭ網においてコネクションは仮想コネ
クション（以下、ＶＣと略記する）と呼ばれる。これは
発信地から目的地まではそのコネクションが経由するＡ
ＴＭセルスイッチの経路設定が経路を成り立たせている
だけで、かならずしも定常的な信号のやりとりが存在し
ないためである。また、多数の仮想コネクションが一つ
の仮想パス（以下、ＶＰと略記する）に収容され、管理
の容易化がはかられることが多い。

【０００４】従来、ＡＴＭ網についてさまざまな見方か
らセルフヒーリングの技術が提案されている。例えば、
ＶＰの故障検出法や無瞬断切替え技術、予備容量設計法
や、リングトポロジによる高信頼化技術、任意のネット
ワークトポロジにおける経路探索技術などである（戸倉
他ＡＴＭ加入者網構成技術ＮＴＴ Ｐ＆Ｄ ４２：３３
６７〜３８０）。これらの研究によって、予備の網資源
が十分に存在することを前提とすれば全てのＶＰの耐故
障性が保証され、加入者レベルでもサービスの無停止化
の実現が期待できる。

【０００５】これら提案された方式は、予め救済するこ
とが決められたコネクションが存在して、そらにそのコ
ネクションを救済するために十分な網の予備資源がある
という前提の下に救済を実行するための方法である。そ
して、全てのコネクションを救済するか、あるいは一部
のコネクションを救済するならばどのコネクションを対
象にするかは故障が発生する以前に決定されていなけれ
ばならない。

【０００６】従って、このような従来の考え方を実現す
るためには装置が故障する以前に、予想される範囲の装
置の故障から全てのコネクションを回復させられるだけ
の網の予備資源を確保しておくか、予め優先的に救済す
べきコネクションを決定しておきそれに合わせて予備資
源を確保しておくことを前提としなければならない。

【０００７】しかし、予め救済すべき一部のコネクシヨ
ンが決定されている場合には、その時の網の状況に応じ
た動作ができないという欠点がある。例えば、網の予備
容量が十分とれないため救済するコネクションを全体の
１／３に制限しているシステムでは、実際の故障時の網
の利用率が予想よりも低く容量的には全てのコネクショ
ンを救済できるような場合でも固定的に１／３のコネク
ションしか救済できない。

【０００８】また、全てのコネクションを救済できるよ
うに網の予備容量を設計したとすると、非故障時の網の
利用率はハードウェア本来の能力の多くとも１／２を越
えることはできなくなり、システムは著しく冗長なもの
となる。

【０００９】網が混んでいる時には重要なコネクション
だけを救済し、網が空いている時には全てのコネクショ
ンを救済すれば網資源を有効に利用できるが、上述のよ
うにＡＴＭ網におけるセルフヒーリングの方法には網の
予備容量に応じたフレキシブルなコネクションの救済を
考えたものはなかった。

【００１０】一方、ＡＴＭ網以外では網の故障時に動的
に救済すべきコネクションを決定する方式が提案されて
いる。動的なコネクション救済とは、網の利用状況や故
障規模に応じて救済するべき複数のコネクションとその
迂回経路を決定して、その救済を実行する方式である。
動的なコネクション救済を行う従来技術には、共通信号
線方式におけるもの（特開平４−２３８９４１ 平岩、
阿讃坊 植田 リルート制御方式）や、コネクション情
報を中央制御装置で管理し、ＤＳ３転送方式などの光ネ
ットワークをユーザ情報の転送に使い、別のデータ回線
で交換ノードに指示を出すもの（特開平４−３０４７３
１電気通信ネットワークに用いられるサービス復旧シス
テム及びその方法）がある。

【００１１】ところで、実際に上記のような動的なコネ
クション救済を行う場合には、以下に述べる理由によっ
てノード間での管理情報の伝達が必要になる。まず場合
々々の網の利用状況に対応してできるだけ多くのコネク
ションを救済するには、故障発生時の網の利用状況や故
障状況を知る必要がある。このときには故障点を避けた
迂回経路を探索して、その迂廻経路に現在どれだけのリ
ンク空き容量があるかを調べなければならない。

【００１２】しかし、ごく小規模な網を除いて一般にコ
ネクションの管理は網内の各ノードで分散的に行われ
る。従って、迂回経路の利用状況を知るためには、迂回
経路を管理するノードに利用状況についての問い合わせ
を行わなければならない。全てのノードが、ネットワー
ク内の全ての利用状況情報を持っていれば問い合わせを
行う必要はないが、そのためにはノード間で膨大な統計
情報の転送を行わなければならないので実際的ではな
い。

【００１３】また、動的な救済を行っている時に一つの
迂回経路をめぐって複数のコネクションの救済要求が競
合することがある。限られた予備資源の下で、それらの
要求を調停するためには、各々のノードで管理されてい
るコネクションの優先度情報が必要になり、ここでも情
報の伝送が必要になる。

【００１４】このとき、もし上記のような管理情報を伝
達するための専用の信号線がなく信号情報と制御情報が
同一の物理媒体を通過するならば、故障時にはユーザコ
ネクションと同様管理用のコネクションも使用できなく
なる可能性がある。

【００１５】そのような場合には、管理用コネクション
が故障してしまえば、たとえ物理的な迂回経路が存在し
たとしても管理操作がコネクションを利用して行われる
以上、コネクションが設定されていないことには管理用
の通信を行うことはできない。すると、動的なコネクシ
ョン救済を行うために必要な情報を収集することができ
ないため、結局ユーザコネクションを救済することがで
きなくなってしまう。

【００１６】このような問題を回避するため、従来技術
においては統計情報の問い合わせや情報の転送を行うた
めには別の信号線を用いる必要があった。従って管理用
の別線のないＡＴＭ網には従来技術をそのまま適用する
ことができなかった。

【００１７】

【発明が解決しようとする課題】上述のように従来技術
のセルフヒーリングでは、ＡＴＭ通信網のようにユーザ
コネクションと制御コネクションが同一媒体を用いる場
合には動的なコネクション救済が行えず網の利用効率が
下がり、一方動的なコネクション救済を行うためには制
御用の別線が必要であった。

【００１８】本発明は、上記課題を解決するためになさ
れたものであり、制御用に別線を使用することなく故障
時の動的なコネクション救済を可能にするＡＴＭ網にお
けるコネクションのセルフヒーリング方法を提供するこ
とを目的とする。

【００１９】

【課題を解決するための手段】本発明では、網に関する
情報及び網内の各交換機間に設けられたユーザコネクシ
ョンと管理コネクションを含む仮想的なコネクションに
関する情報が各交換機に分散して管理され、各交換機は
前記管理コネクションを利用して網資源の管理及び制御
を行うＡＴＭ通信網におけるコネクションのセルフヒー
リング方法において、前記交換機が、自己に関連する前
記管理コネクション及び前記ユーザコネクションの経路
上に障害が発生したことを検出する障害検出ステップ
と、前記障害検出ステップにおいて障害が検出された場
合、予め前記経路上における故障箇所の組合わせに対応
して決められた迂回経路を含む第１の救済内容に従っ
て、障害を受けた前記管理コネクションの設定変更をし
て回復処理を行う第１の回復処理ステップと、この回復
した管理コネクションを利用して、他の交換機に格納さ
れているユーザコネクション及び網の使用状態の統計情
報、並びにユーザコネクション救済の優先度情報を含む
ユーザコネクション救済情報を収集する情報収集ステッ
プと、この収集した情報を元にして、障害を受けた前記
ユーザコネクションのうち救済すべきユーザコネクショ
ン及び迂回経路を含む第２の救済内容を決定する救済内
容決定ステップと、前記第２の救済内容に従って、該当
するユーザコネクションの設定変更をして回復処理を行
う第２の回復処理ステップとを有することを特徴とす
る。

【００２０】また、前記救済内容決定ステップにおい
て、所定の場合にはいずれかのユーザコネクションの容
量を縮小することとし、縮小するユーザコネクション及
びその縮小後の容量を決定しても良い。

【００２１】

【作用】本発明によれば、前記交換機が障害を受けた管
理コネクションを自立分散的に回復させ、この回復した
管理コネクションを利用して各交換機に分散しているコ
ネクション救済に必要な情報を収集し、この収集した情
報に基づいて動的に救済すべきユーザコネクションや迂
回経路などの救済内容を決定して、ユーザコネクション
の回復処理を行う。

【００２２】すなわち、ＡＴＭ網においてコネクション
の救済のために固定的に確保する予備資源の量を網資源
全体に対して十分小さい管理コネクションの量程度に押
えることができ、動的なコネクション救済を実現する。

【００２３】従って、本発明によれば、網の利用率に応
じて最善のコネクション救済を行うことができ、通常時
の網の利用効率や故障時の救済率を高めることができ
る。また、コネクションに利用者の意志を反映した救済
要求の優先度を指定して、網が混んでいる時には重要な
優先度の高いコネクションだけを救済し、網が空いてい
る時には全てのコネクションを救済することも可能にな
る。

【００２４】

【実施例】以下、本発明の一実施例について図面を参照
しながら説明する。本発明では、コネクションに障害が
発生した場合、まず障害を受けた管理コネクションの救
済処理（回復処理）を行い、次にこの回復した管理コネ
クションを利用して、ユーザコネクションの救済処理を
行う。

【００２５】まず、本発明の一実施例に係る管理コネク
ションの救済処理について説明する。図１に、管理コネ
クションの救済フローを示す。このフローは、ネットワ
ークにおける端点の動作を示している。

【００２６】本実施例では、故障位置情報を含むＯＡＭ
セルを管理コネクションで受信したノード（ステップ
２）は、故障点がコネクション端点でない場合、故障点
対応の予備系パスを検索し（ステップ４）、対応する予
備系パスが存在するときは予備系パスに経路切り替え用
ＯＡＭセルを送出し（ステップ６）、予備系で対向側か
らの切り替え完了通知セルを受信すると、救済成功にて
処理完了となる。

【００２７】また、ステップ６で予備系パスに経路切り
替え用ＯＡＭセルを送出しても、対向側からの切り替え
完了通知セルを受信しなかったときは、メッセージフラ
ッディングによる迂回経路を探索し（ステップ８）、迂
回経路が見付かった場合、迂回経路のパス設定を行い
（ステップ１０）、迂回経路にパス切り替え用ＯＡＭセ
ルを送出して（ステップ１１）、処理を終了する。

【００２８】以下、さらに詳細に管理コネクションの救
済処理について説明する。図２には、本発明を適用する
ネットワークのトポロジの一例を示す。このネットワー
クは、各リンク（２１〜３２）によって接続された交換
ノード１〜１０から構成される。

【００２９】図３には、図２のネットワークにおいて、
ノード１からノード２〜１０に張られた管理コネクショ
ン４２〜５０の経路を示す。管理コネクション４２〜５
０は、それぞれノード１を一方の端点とし、ノード２〜
ノード１０をもう一方の端点として設定されている。

【００３０】図４には、ノード８からノード１〜７及び
ノード９〜１０に張られた管理コネクション６１（４８
と同一）、６２〜６７、６９〜７０の経路を示す。管理
コネクション６１、６２〜６７、６９〜７０は、それぞ
れノード８を一方の端点とし、ノード１〜７、ノード９
〜１０をもう一方の端点として設定されている。

【００３１】管理コネクションは、それぞれのノードが
独立にコネクションを管理することによって分散処理を
実現するため、全てのノードの間で完全結合で張られて
いるものとする。また、全管理コネクションの経路は、
ホップ数について最適化（最小化）されているものとす
る。ここではノード１とノード８のコネクションの救済
の例を説明するので、簡略化のためノード１、ノード８
以外の管理コネクションの図示は省略する。

【００３２】本実施例で想定しているネットワークで
は、ネットワーク内で管理コネクションの完全結合を作
ることによって、網内のノードは全て互いに直接メッシ
セージのやりとりができるため、負荷の分散が容易に行
える。ただし、網の管理が集中的に行なわれている場合
には、１対ｎの結合で十分である。また、非常に大規模
な網では完全結合を作ることが難しいことから、網をい
くつかのドメインに分けてそれぞれのドメインの中で完
全結合または１対ｎ結合を形成し、ドメインの間はゲー
トウェイの役割をするノードが管理コネクションのメッ
セージを中継する方式をとることも考えられる。

【００３３】まず、管理コネクションの救済のために必
要なだけの網資源は予め確保されている。ＡＴＭ網では
管理情報の転送量はリンク、ノード全体のスループット
に比較して十分小さいと考えられるので、このように常
時予備の資源を確保しても全体の資源の利用効率の低下
はごくわずかである。一方、予め予備の資源を確保して
おくことによって、故障時にも確実に管理コネクション
の救済ができる。

【００３４】管理コネクションにはそれぞれ、管理コネ
クションを中継するノードやリンクに対応して、それら
ノードやリンクが故障した場合の予備の経路が定められ
ていて、管理コネクションの端点のノードはその経路を
故障箇所対応に記憶している。なお、ネットワークの構
成と故障箇所によっては予備の経路が存在しない場合も
ありうるが、そのような場合はそもそも如何なる救済措
置をとることもできないのでここでは考えない。

【００３５】これらの予備経路に予めパス設定が行われ
ていて、管理コネクションの端点のノードがそのパスに
予め定められたフォーマットの現用系／予備系切替え用
ＯＡＭセルを送出することによって、速やかに現用系か
ら予備系のパスへの切替を行うことができる。

【００３６】管理コネクションの端点のノードは、中継
ノードまたはリンクの故障を検出すると、故障箇所から
予備系への切替を行う必要のある管理コネクションを検
索して、その管理コネクションと故障箇所に対応した予
備系のパスに切替え用ＯＡＭセルを送出する。

【００３７】故障点対応に予備の経路を記憶しておくこ
とが困難なほど規模の大きいたネットワークのために、
または複数箇所の故障に対応するために、故障発生後に
管理コネクションの端点のノードがメッセージフラッデ
ィングによる迂回経路の探索とパスの設定を行っても良
い。メッセージフラッディングとはあるノードへのパス
を探索したいノードが、そのパスの探索を要求するメッ
セージを網内にブロードキャストすることによって可能
性のある全ての経路を探索するものである。ただしこの
方式をとる場合、パスの探索と再設定を行うため、管理
コネクションの回復までにかかる時間は長い。

【００３８】次に、故障時の管理コネクションの救済動
作を説明する。ここでは、図３、図４のように管理コネ
クションが張られているネットワークにおいてノード１
０が故障した場合を例として説明する。

【００３９】ノード１０が故障すると、ノード１と他の
ノードの間に張られた管理コネクションのうち、管理コ
ネクション４２，４３，４９は残るが、管理コネクショ
ン４４〜４８，５０は切断される。また、ノード８と他
のノードの間に張られた管理コネクションのうち、管理
コネクション６６，６７，６９は残るが、管理コネクシ
ョン６１〜６５，７０は切断される。この時の管理コネ
クションの状態を図５に示す。この状態では、ノード４
及びノード５は、ノード１及びノード８のいずれとも通
信することができないため孤立する。

【００４０】しかし、これらの管理コネクショから孤立
したノード４，５も、管理コネクションを迂回経路に切
替えることによりノード１やノード８との通信を回復す
ることができる。

【００４１】ノード１は、網のＯＡＭ機能によってノー
ド１０の故障を検出する（図１のステップ２）。ノード
１０の故障を検出したノード１は、ノード１０を経路に
含む管理コネクション４４〜４８について、図６に示す
ようにノード１０の故障に対して定めておいた予備の管
理コネクションのパス８４〜８８にパス切替用のＯＡＭ
セルを送信して（ステップ６）、管理コネクションを現
用系から予備系に切替える。

【００４２】これによって、切断された管理コネクショ
ン４４〜４８は、図６に示す故障したノード１０を通ら
ない予備系のパス８４〜８８に切替えられて、ノード２
〜８との間の管理系の通信は回復する。

【００４３】同様に、ノード８は、網のＯＡＭ機能によ
ってノード１０の故障を検出する。ノード１０の故障を
検出したノード８は、ノード１０を経路に含む管理コネ
クション６１（４８と同一）、６２〜６５、６９につい
て、図７に示すノード１０の故障に対して定めておいた
予備の管理コネクションのパス１０１〜１０５、１０９
にパス切替用のＯＡＭセルを送信して、管理コネクショ
ンを現用系から予備系に切替える。

【００４４】これによって、切断された管理コネクショ
ン６１〜６５は、図７に示す故障したノード１０を通ら
ない予備系のパス１０１〜１０５に切替えられてノード
１〜５との間の管理系の通信は回復する。

【００４５】ただし、管理コネクション５０や管理コネ
クション７０は、いずれも故障したノード１０との間に
張られているので回復操作は行わない。次に、この回復
した管理コネクションを利用して行う、ユーザコネクシ
ョンの救済処理について説明する。

【００４６】故障したノード１０以外のノードとの管理
コネクショが迂回経路に切替えられて回復すると、次に
ユーザコネクションの救済を行う。先に述べた通り、ユ
ーザコネクションは管理コネクションに比較して大きな
帯域を占有するため、ユーザコネクションの救済を行う
には単に迂回経路が存在するかどうかだけでなく、救済
するユーザコネクションが迂回経路のリンクの空き容量
に収容できるかどうかを調べなければならない。この操
作は、救済された管理コネクションを用いて行われる。

【００４７】なお、該ＡＴＭ網に非常通信やその網自身
を運転するために必要な制御用信号線が収容されている
場合には、管理コネクションと同様にそれらの救済のた
めの予備資源を予め確保して、管理コネクションと同時
に救済処理を行っても良い。これは、復旧時間の制限が
厳しいコネクションに特に有効である。

【００４８】以下、ユーザコネクションの救済につい
て、３通りの方法を説明する。なお、前述した管理コネ
クションの救済方法については、各ユーザコネクション
の救済方法において共通である。

【００４９】まず、第１のユーザコネクションの救済方
法を、２つのケースに分けて説明する。第１のケースで
は、救済処理決定アルゴンリズムとして、故障コネクシ
ョンには優先度の指定があり、優先度の高いコネクショ
ンを優先的に救済することとして、もし網の空き帯域に
故障コネクションが収容できない時はそのコネクション
を切断する方法をとる。このとき既に迂回経路を通って
いる既存のコネクションの帯域縮小や切断は行わない。

【００５０】優先度を指定する優先度値は、互いに比較
ができればどのようなものでも構わない。例えば、高低
の２つの値のみとっても良いし、ある範囲の整数でも良
い。ここでは優先度は「高、低」の２種類のいずれかが
付与されている。

【００５１】図８に、第１の管理コネクションの救済方
法のアルゴリズムを示す。ここでは、図９のように、故
障したノード１０を経由しているＶＰ１２１，１２２が
設けられている場合を例として説明する。なお、図中の
点線１３１，１３２は、ノード１とノード８との間の２
つの迂回経路を示す（ＶＰではない）。

【００５２】ここで、図１３（ａ）のようにＶＰ１２
１，１２２の占有帯域が、図１３（ｂ）のようにリンク
の占有帯域が設定されているものとする。また、ノード
間のリンクの容量は全て１とする。

【００５３】以下、ノードにある管理エンティティーが
管理コネクションを利用してＶＰ１２１及びＶＰ１２２
のコネクションを救済する手順を説明する。これはノー
ド１とノード８のどちらが主体となって行っても良い
が、ここではノード１が主体となる場合を述べる。

【００５４】ノード間の管理コネクションは、先に説明
した方法によってすでに救済されている。 （ｉ）代替経路の探索（ステップ２２） まず、ＶＰ１２１及びＶＰ１２２の代替経路の探索が行
われる。予めノード１が自ノード内に網の接続状況の情
報を持っていても、故障発生後に管理系コネクションを
使って経路の可能性を問い合わせても良い。

【００５５】探索の結果、代替経路の候補としてノード
２，３，４，５，６，７を経由する迂回経路１３１とノ
ード９を経由する迂回経路１３２が発見できる。 （ii）空き帯域の探索（ステップ２３） ノード１の管理エンティティーは、迂回経路１３１及び
迂回経路１３２の通過リンクにどれだけの空き帯域があ
るかを経路上のノードに問い合わせる。

【００５６】各ノードの管理エンティティーは、自ノー
ドに接続されているリンクの利用率を知っている。ノー
ド１の管理エンティティーは、管理コネクションを通じ
てノード２から７までとノード９の管理エンティティー
にリンクの空き容量及び輻輳状態の問い合わせを発行し
て迂回経路の利用状況を知る。

【００５７】このとき、もしノード１の管理コネクショ
ンの救済が行われていなければノード４，５，６，７の
リンクの利用状況はわからない。また、ノード８が主体
となって救済を行う場合でもノード２から５とは通信不
能であり、ノード４，５はノード１とノード８のいずれ
からも通信不能であり必要な情報を収集することができ
ない。

【００５８】網の利用状況の情報がノードに分散された
システムで、利用状況に対応したコネクションの救済を
行おうとすれば、このように何らかの方法で網情報を収
集することが必要になる。網情報の収集がコネクション
に依存している場合には、情報収集のためのコネクショ
ン（ここでの管理コネクション）を予め救済しておくこ
とが不可欠である。

【００５９】また、網の障害時には異常な輻輳が発生す
ることが多いので、コネクションが網内の単一の管理装
置によって集中管理されているシステムにおいても、輻
輳を避けるために迂回経路のノードに問い合わせを発行
して実時間的に輻輳状態を知り、輻輳状態にない経路を
迂回経路にとることが望ましい。

【００６０】（iii ）救済条件に従った迂回経路の決定
（ステップ２４〜ステップ２８）次に、ステップ２４〜
ステップ２８に示すように、迂回経路のコネクション収
容能力の状態と、障害を受けたユーザコネクションの占
有帯域及び優先度に基づいて、迂回経路および収容する
ユーザコネクションを決定する。

【００６１】例えば、収集した網の利用状況が図９と図
１３（ｂ）に示すごとくであったとする。迂回経路１３
１で利用率の最大値は、リンク２４の“０．３”であっ
た。また、迂回経路１３２の利用率の最大値はリンク２
９の“０．８”であった。従って、迂回経路１３１，１
３２で使用可能な最大容量は、それぞれ“０．７”、
“０．２”である。まず優先度の高いＶＰ１２１を救済
しなければならないが、ＶＰ１２１は“０．３”の容量
なので迂回経路１３２には収容できない。従って、Ｖ１
２１は迂回経路１３１に収容される。ここで、Ｖ１２１
を迂回させた後の迂回経路１３１の空き帯域は“０．
４”残っているが、ＶＰ１２２を収容するには不十分で
ある。ＶＰ１２２は迂回経路１３２にも収容できない。
ＶＰは分割して収容できないものとすると、ＶＰ１２２
は収容できず切断されることになる（以上、ステップ２
４、ステップ２５、ステップ２６、ステップ３０、ステ
ップ２８）。救済後のトラヒック状況を、図１０、図１
３（ｃ）に示す。

【００６２】ここで、救済するコネクション対応に固定
的に予備資源を確保しておく従来の方法においては、救
済するコネクションは予め決められている。従って、こ
の実施例のように図１３（ｂ）のように迂回経路の空き
帯域の合計“０．９”が救済すべきコネクションＶＰ１
２１とＶＰ１２２の合計“１．０”よりも小さくなるよ
うな利用が見込まれる場合には、はじめからＶＰ１２２
は救済しない。その場合には、たとえ以下の（２）で説
明するような網の利用率が低い場合であってもＶＰ１２
２を救済することはできない。また、ＶＰ１２１および
ＶＰ１２２の双方を救済する必要がある場合には迂回経
路のリンク使用率は常にＶＰ１２１とＶＰ１２２を収容
できるだけの予備容量を確保するために、図１３（ｂ）
に示した値より低く制限されてしまう。このため、通常
時の利用効率を高くとることができない。

【００６３】本実施例によれば、このような従来の方法
における不具合を回避することができるわけである。次
に、第２のケースとして、第１のユーザコネクションの
救済方法において、ネットワークの利用状況が異なり、
利用率が低い場合の動作を説明する。

【００６４】故障検出から迂回経路探索までの過程は、
前述した第１のケースと同様である。ここでは、収集し
た網の利用状況が、図１１、図１３（ａ）、図１３
（ｄ）のごとくであったものとする。

【００６５】迂回経路１３１での利用率の最大値はリン
ク２４の“０．２”であった。また迂回経路１３２の利
用率の最大値はリンク２８の“０．５”であった。従っ
て迂回経路１３１，１３２で使用可能な最大容量はそれ
ぞれ“０．８”、“０．５”である。第１のケースと同
様に、まずＶＰ１２１を優先して救済しなければならな
いが、ここではＶＰ１２１の帯域は“０．３”なので迂
回経路１３１にも迂回経路１３２のどちらにも収容でき
る。一方、ＶＰ１２２の帯域は“０．７”なので、収容
できるのは迂回経路１３１だけである。

【００６６】救済の条件はＶＰ１２１を優先することで
あるが、なるべく多くのコネクションを救済することを
含めて判断すると、ＶＰ１２１を迂回経路１３２に収容
し、ＶＰ１２２を迂回経路１３２に収容するのが救済条
件を満たす解である（以上、ステップ２４、ステップ２
５、ステップ２６、ステップ２７、ステップ２８）。救
済後のトラヒック配置を、図１２と図１３（ｅ）に示
す。

【００６７】第１のケースの場合には、正常時の網の利
用率が高いため、障害を受けた２つのＶＰのうち優先度
の低い方が切断されている。一方、第２のケースでは、
正常時の網の利用率が低いため２つのＶＰはともに救済
されている。

【００６８】次に、第２のユーザコネクションの救済方
法を説明する。第１の方法では、救済するコネクション
を収容できるだけの空き帯域がない時は、コネクション
を切断していた。しかし、救済するコネクションの帯域
を縮小すれば収容可能になる場合もあり、故障時のコネ
クション救済の適用範囲を広げることができる。

【００６９】図１４に、救済動作のフローを示す。故障
発生から迂回経路探索までの過程は第１の方法と同様で
ある。この第２の方法では、各コネクションの間に優先
度の違いを設け、高優先度のコネクションを優先的に救
済するが、もし網の空き容量にコネクションが収容でき
ない時は救済するコネクションの帯域を優先度の低いも
のから縮小し（ステップ５０）、既存のコネクションの
帯域はそのままとする点に特徴がある。

【００７０】ここでは、収集した網の利用状況が図１
５、図１７（ａ）、図１７（ｂ）のごとくであったもの
とする。迂回経路１３１の利用率の最大値はリンク２４
の“０．２”であった。また迂回経路１３２の利用率の
最大値はリンク２９の“０．８”であった。従って迂回
経路１２１，１２２で使用可能な最大容量はそれぞれ
“０．８”、“０．２”である。

【００７１】まずＶＰ１を優先して救済しなければなら
ないが、ＶＰ１２１は優先度が高いので帯域を縮小する
ことはできないため、“０．３”の容量が収容できる迂
回経路１３２にしか収容できない。従って、ＶＰ１２１
は優先的に迂回経路１３１に収容することとする。一
方、ＶＰ１を迂回経路１３１に収容すると、迂回経路１
３１の空き容量は“０．５”となる。ＶＰ２の容量は
“０．７”なので、帯域を縮小することなしには迂回経
路１３１にも迂回経路１３２にも収容できない。

【００７２】ＶＰ１２２を迂回経路１３１に収容する時
の帯域の縮小幅は“０．２”、迂回経路１３２に収容す
る時の帯域の縮小幅は“０．５”である。そこで帯域の
縮小量が少なくなるように、帯域を“０．７”から
“０．５”に縮小して迂回経路１３１に収容する（以
上、ステップ４４、ステップ４５、ステップ４６、ステ
ップ５０、ステップ４８）。図１６、図１７（ｃ）に救
済実行後のコネクション配置を示す。

【００７３】次に、第３のユーザコネクションの救済方
法を説明する。図１８には、本方法の救済動作のフロー
を示す。なお、故障発生から迂回経路探索までの過程は
実施例１と同様である。

【００７４】これまでは、故障したコネクションにのみ
優先度を考慮した救済を行う例を示したが、場合によっ
ては迂回経路に収容されている既存コネクションよりも
故障したコネクションの救済を優先させたいこともあ
る。

【００７５】そこで、この第３の方法では、予めネット
ワーク内のコネクションの全てに優先度値を指定し、コ
ネクション毎に経路上のノードに優先度値を格納してお
く。そして、故障時に全ての故障コネクションを救済で
きるだけの空き帯域がない場合、優先度情報が救済され
た管理コネクションを通じて読み出されて、故障したコ
ネクションと既存のコネクションの優先度情報を比較し
て、いずれを優先するかを決定する。故障コネクション
を優先させる時は、既存のコネクションを切断または帯
域縮小する（ステップ７０、ステップ７１）。

【００７６】例えば、故障前のトラヒックと優先度の指
定状態が図１９、図２１（ａ）、図２１（ｂ）のようで
あった時のコネクション救済について以下説明する。ノ
ード内の各コネクションには「高、低」の２種類の優先
度値のいずれかが付与されている。

【００７７】ここでは、優先度はＶＰ１２１，ＶＰ１２
２ともに「高」である。一方、迂回経路１３１におい
て、利用率最大のリンクはリンク２４であり、その利用
率は“０．４”、そこに収容されているコネクションの
優先度は「高」である。また、迂回経路１３２におい
て、利用率最大のリンクはリンク２９であり、その利用
率は“０．８”、コネクションの優先度は「低」であ
る。

【００７８】迂回経路１３１には高優先度のコネクショ
ンがあるので、その帯域を縮小することはできない（同
一優先度の時には既存のコネクションが優先するとす
る）。しかし、迂回経路１３１は既存コネクションの帯
域を縮小することなくＶＰ１２１を収容できる。

【００７９】迂回経路１３２で利用率最大のリンク２９
を通るコネクションの優先度は「低」なので、高優先度
のコネクションの救済のためには帯域縮小が可能であ
る。このリンク２９のコネクションの帯域を“０．８”
から“０．３”に縮小することで、迂回経路１３２にＶ
Ｐ１２２が収容可能になる。救済実行後のコネクション
配置を、図２０、図２１（ｃ）、図２１（ｄ）に示す。

【００８０】このように、第３の方法では、既存コネク
ションの帯域縮小を行うことにより、高優先度の故障コ
ネクションの帯域を縮小することなしに、故障前のトラ
ヒック状態では収容することのできなかったコネクショ
ンを収容、救済することができた。

【００８１】以上説明してきたように、本発明によれ
ば、ＡＴＭ網に対して動的に救済するコネクションを決
定する救済方法がとれるので、網の利用率に応じて最善
のコネクション救済を行うことができ、通常時の網の利
用効率や故障時の救済率を高めることができる。

【００８２】ここに、本発明の救済処理方法を実施する
には網の利用状況や故障状況といったネットワークの下
位レイヤの情報のみならず、既存のコネクションについ
ても優先度のような上位レイヤに属するユーザ情報の伝
達が不可欠である。また、優先度のようなパラメータ情
報に加えて複数の救済処理決定アルゴリズムのうちの一
つを指定するような情報を交換しても良い。

【００８３】また、本実施例ではコネクションの競合が
比較的単純な場合について扱い、優先度値に基づいた救
済処理決定アルゴリズムを用いたが、救済の優先度に多
くの値があり、複数の故障コネクションの救済要求が競
合するような場合は、ネットワークに、コネクション救
済の評価関数を定め、その関数の値に基づいて故障コネ
クションや既存コネクション間の競合を調停して救済処
理動作を決定する方法が有効である。例えば、この評価
関数として、ネットワークの全てのコネクションについ
て優先度値、故障コネクション／既存コネクションの類
別、ＱＯＳ（占有帯域を含む）、当該コネクションの縮
小等の値、変更動作を行なうための処理時間コスト等を
パラメータとし、これらの値がコネクションの救済に伴
い縮小、切断の動作を反映して関数の値が変化するもの
を導入し、この関数の値が取り得る救済動作の範囲内で
最大または最小になるような、もっとも適切な救済処理
動作を決定するように構成しても良い。また、本発明は
上述した実施例に限定されるものではなく、その要旨を
逸脱しない範囲で、種々変形して実施することができ
る。

【００８４】

【発明の効果】本発明のＡＴＭ網におけるコネクション
のセルフヒーリング方法では、網の故障時にまず管理コ
ネクションを救済することによって、迂回経路の利用状
況や優先度情報や故障状況の交換ができるようにする。
その後、これらの情報を元にして真の故障原因の判定や
救済するコネクションを動的に決定するコネクション救
済方法を可能とする。

【００８５】従って、本発明によれば、ＡＴＭ網に対し
て動的に救済するコネクションを決定する救済方法がと
れるので、網の利用率に応じて最善のコネクション救済
を行うことができ、通常時の網の利用効率や故障時の救
済率を高めることができる。

【００８６】また、コネクションに利用者の意志を反映
した救済要求の優先度を指定して、網が混んでいる時に
は重要な優先度の高いコネクションだけを救済し、網が
空いている時には全てのコネクションを救済することも
可能になる。

【図面の簡単な説明】

【図１】本発明の一実施例に係る管理コネクションの救
済動作を示すフローチャート

【図２】同実施例のネットワークのトポロジを示す図

【図３】ノード１について管理コネクションの初期状態
を示す図

【図４】ノード８について管理コネクションの初期状態
を示す図

【図５】ノード１０の故障時に影響を受けない管理コネ
クションを示す図

【図６】ノード１について救済後の管理コネクションを
示す図

【図７】ノード８について救済後の管理コネクションを
示す図

【図８】コネクションの救済動作の一例を示すフローチ
ャート

【図９】故障前のトラヒック配置の一例を示す図

【図１０】救済後のトラヒック配置の一例を示す図

【図１１】故障前のトラヒック配置の他の例を示す図

【図１２】救済後のトラヒック配置の他の例を示す図

【図１３】各ＶＰやリンクの占有帯域等の情報を示す図

【図１４】コネクションの救済動作の他の例を示すフロ
ーチャート

【図１５】故障前のトラヒック配置の一例を示す図

【図１６】救済後のトラヒック配置の一例を示す図

【図１７】各ＶＰやリンクの占有帯域等の情報を示す図

【図１８】コネクションの救済動作のさらに他の例を示
すフローチャート

【図１９】故障前のトラヒック配置の一例を示す図

【図２０】救済後のトラヒック配置の一例を示す図

【図２１】各ＶＰやリンクの占有帯域等の情報を示す図

【符号の説明】

１〜１０…ＡＴＭ交換ノード ２１〜３２…接続リンク ４２〜５０…ノード１と他のノードとの間の管理コネク
ション ６２〜６７、６８〜７０…ノード８と他のノードとの間
の管理コネクション ８４〜８８…ノード１と他のノードとの間の予備系の管
理コネクション １０１〜１０５、１０９…ノード８と他のノードとの間
の予備系の管理コネクション １２１，１２２…ＶＰ、１３１，１３２…迂回経路

Claims (1)

【特許請求の範囲】
1. 【請求項１】網に関する情報及び網内の各交換機間に設
   けられたユーザコネクションと管理コネクションを含む
   仮想的なコネクションに関する情報が各交換機に分散し
   て管理され、各交換機は前記管理コネクションを利用し
   て網資源の管理及び制御を行うＡＴＭ通信網におけるコ
   ネクションのセルフヒーリング方法において、 前記交換機が、自己に関連する前記管理コネクション及
   び前記ユーザコネクションの経路上に障害が発生したこ
   とを検出する障害検出ステップと、 前記障害検出ステップにおいて障害が検出された場合、
   予め前記経路上における故障箇所の組合わせに対応して
   決められた迂回経路を含む第１の救済内容に従って、障
   害を受けた前記管理コネクションの設定変更をして回復
   処理を行う第１の回復処理ステップと、 この回復した管理コネクションを利用して、他の交換機
   に格納されているユーザコネクション及び網の使用状態
   の統計情報、並びにユーザコネクション救済の優先度情
   報を含むユーザコネクション救済情報を収集する情報収
   集ステップと、 この収集した情報を元にして、障害を受けた前記ユーザ
   コネクションのうち救済すべきユーザコネクション及び
   迂回経路を含む第２の救済内容を決定する救済内容決定
   ステップと、 前記第２の救済内容に従って、該当するユーザコネクシ
   ョンの設定変更をして回復処理を行う第２の回復処理ス
   テップとを有することを特徴とするＡＴＭ網におけるコ
   ネクションのセルフヒーリング方法。