JP2007312091A - ルーチング装置および障害復旧方法 - Google Patents
ルーチング装置および障害復旧方法 Download PDFInfo
- Publication number
- JP2007312091A JP2007312091A JP2006138998A JP2006138998A JP2007312091A JP 2007312091 A JP2007312091 A JP 2007312091A JP 2006138998 A JP2006138998 A JP 2006138998A JP 2006138998 A JP2006138998 A JP 2006138998A JP 2007312091 A JP2007312091 A JP 2007312091A
- Authority
- JP
- Japan
- Prior art keywords
- network
- failure
- recovery
- time
- monitoring
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ネットワークの信頼性を向上させること。
【解決手段】障害復旧後にネットワークが安定するために必要な時間を復旧時状況監視用タイマ記憶部140に記憶し、復旧時状況監視部180が障害復旧後に復旧時状況監視用タイマ記憶部140に記憶された時間経過後に障害発生前の現用ルートに復帰するように制御する。また、障害検知用タイマ記憶部120および障害時状況監視用タイマ記憶部130に汎用ネットワークで使用するデフォルト値よりも小さいタイマ値を記憶し、障害検知部150が障害検知用タイマ記憶部120に記憶されたタイマ値に基づいて障害検知を行い、障害時状況監視部160が障害時状況監視用タイマ記憶部130に記憶されたタイマ値に基づいて障害発生を判定する。
【選択図】 図9
【解決手段】障害復旧後にネットワークが安定するために必要な時間を復旧時状況監視用タイマ記憶部140に記憶し、復旧時状況監視部180が障害復旧後に復旧時状況監視用タイマ記憶部140に記憶された時間経過後に障害発生前の現用ルートに復帰するように制御する。また、障害検知用タイマ記憶部120および障害時状況監視用タイマ記憶部130に汎用ネットワークで使用するデフォルト値よりも小さいタイマ値を記憶し、障害検知部150が障害検知用タイマ記憶部120に記憶されたタイマ値に基づいて障害検知を行い、障害時状況監視部160が障害時状況監視用タイマ記憶部130に記憶されたタイマ値に基づいて障害発生を判定する。
【選択図】 図9
Description
この発明は、異なる障害復旧方式が独立に動作するネットワークの構築に用いられるルーチング装置およびルーチング装置によるネットワークの障害復旧方法に関し、特に、ネットワークの信頼性を向上させることができるルーチング装置および障害復旧方法に関するものである。
近年、電力自由化を契機として、電気事業を取り巻く環境は大きく変わろうとしている。事業形態の変化や新しいシステムの導入などに対して柔軟に対応でき、さらに業務の効率化ができる総合的な仕組みが期待されている。そこで、これらの要求を満たす電力用ネットワークを構築するために、分散リアルタイムネットワークアーキテクチャ(DRNA: Distributed Real-time computer Network Architecture)の開発が進められており、これまでに、DRNAの伝達通信機能には、汎用的な技術であり、低コストで導入可能なIP(Internet Protocol)技術が適していることが明らかになっている(非特許文献1〜8参照)。
また、IPルータ、MPLS(Multi Protocol Label Switching)、広域イーサネットの3つの方法を比較すると、DRNAにおける伝達通信機能の構成としてMPLSと広域イーサネットを適用する構成が適していると考えられる(非特許文献5参照)。ここで、MPLSは、IPパケットにラベルを追加することでIPルータより高速に転送できる技術である。また、ラベルによりVPN(Virtual Private Network)の実現、FRR(fast reroute)方式による高速な切り替え、更には従来では困難であったIPパケットの経路指定が可能となる。従って、MPLSを適用すれば、FRRにより高信頼性を確保しつつ、VPNや経路指定により、これまでは別々に構築されていた監視制御系ネットワークと設備保全系ネットワークを統合できる可能性がある。また、MPLSや広域イーサネットは障害回復機能を備え、障害に強いネットワークを構築することができる。
藤川、「ラベルスイッチ技術を用いた電力通信用基幹網の検討と技術課題」、電力中央研究所研究報告:R98022、平成11年3月
藤川、「電力用通信基幹網へのMPLS技術の適用評価」、電力中央研究所研究報告:R99016、平成12年3月
藤川、「MPLSネットワークにおける伝送遅延抑制方法の提案と評価」、電力中央研究所研究報告:R00025、平成13年4月
藤川、「MPLSネットワークにおける伝送遅延時間保証方式の提案と検証」、電力中央研究所研究報告:R01024、平成14年4月
桑原、「MPLSを適用した電力用IPネットワーク構成法の提案と評価」、電力中央研究所研究報告:R01013、平成14年3月
桑原、「MPLSを適用した電力用IPネットワーク構成法の適用」、電力中央研究所研究報告:R02007、平成15年3月
桑原、「分散リアルタイムネットワークアーキテクチャ(DRNA)の開発(その5)」、電力中央研究所研究報告:R02010、平成15年3月
桑原、「分散リアルタイムネットワークアーキテクチャ(DRNA)の開発(その6)」、電力中央研究所研究報告:R03001、平成16年1月
しかしながら、MPLSと広域イーサネットの障害回復機能を単に利用するだけでは、電力用ネットワークに必要な高度な信頼性を確保することができないという問題がある。具体的には、障害回復時間がかかる、あるいは、MPLSと広域イーサネットの障害回復機能は連携がないため障害からの復帰時にパケットロスが発生するといった問題がある。
この発明は、上述した従来技術による問題点を解消するためになされたものであり、電力用ネットワークなどのネットワークの信頼性を向上させることができるルーチング装置および障害復旧方法を提供することを目的とする。
上述した課題を解決し、目的を達成するため、請求項1の発明に係るルーチング装置は、異なる方式で障害復旧が行われる複数のサブネットワークが接続されて構成されるネットワークの構築に用いられるルーチング装置であって、障害復旧の際に、ネットワーク全体が安定するまでの間ネットワーク状況の監視を行う復旧時状況監視手段と、前記復旧時状況監視手段によるネットワーク状況の監視後に障害発生前の状態に復帰させる復帰手段と、を備えたことを特徴とする。
この請求項1の発明によれば、障害復旧の際に、ネットワーク全体が安定するまでの間ネットワーク状況の監視を行い、監視後に障害発生前の状態に復帰させるよう構成したので、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすことができる。
また、請求項2の発明に係るルーチング装置は、請求項1の発明において、前記復旧時状況監視手段は、前記複数のサブネットワークのうちの特定のサブネットワークの経路情報が更新されてネットワーク全体が安定するまでの間ネットワーク状況の監視を行うことを特徴とする。
この請求項2の発明によれば、複数のサブネットワークのうちの特定のサブネットワークの経路情報が更新されてネットワーク全体が安定するまでの間ネットワーク状況の監視を行うよう構成したので、障害復旧後の経路情報に基づいて確実にパケットを転送することができる。
また、請求項3の発明に係るルーチング装置は、請求項2の発明において、前記複数のサブネットワークのうちの特定のサブネットワークの経路情報が更新されてネットワーク全体が安定するまでの時間を計測する復旧時監視時間測定手段をさらに備え、前記復旧時状況監視手段は、障害復旧の際に、前記復旧時監視時間測定手段により測定された時間が経過するまでネットワーク状況の監視を行うことを特徴とする。
この請求項3の発明によれば、複数のサブネットワークのうちの特定のサブネットワークの経路情報が更新されてネットワーク全体が安定するまでの時間を計測し、障害復旧の際に、測定した時間が経過するまでネットワーク状況の監視を行うよう構成したので、ネットワーク全体が安定するまでの時間が変化する場合にも、適切な時間ネットワーク状況の監視を行うことができる。
また、請求項4の発明に係るルーチング装置は、請求項2または3の発明において、前記特定のサブネットワークにはMPLSが適用され、ネットワーク全体が安定するまでの間にVPNラベルテーブルが再構築されることを特徴とする。
この請求項4の発明によれば、特定のサブネットワークにはMPLSが適用され、ネットワーク全体が安定するまでの間にVPNラベルテーブルが再構築されるよう構成したので、MPLSサブネットワークのVPNラベルテーブルが更新されてネットワーク全体が安定するまでの間ネットワーク状況の監視を行うよう構成したので、障害復旧後のVPNラベルテーブルに基づいて確実にパケットを転送することができる。
また、請求項5の発明に係るルーチング装置は、ネットワークの構築に用いられるルーチング装置であって、ルーチング装置間の伝送遅延時間に基づいて設定された障害検知用タイマを用いて前記ネットワークの障害検知を行う障害検知手段を備えたことを特徴とする。
この請求項5の発明によれば、ルーチング装置間の伝送遅延時間に基づいて設定された障害検知用タイマを用いてネットワークの障害検知を行うよう構成したので、障害検知用タイマの値が不必要に大きいことに起因して障害検知が遅れることを防ぐことができる。
また、請求項6の発明に係るルーチング装置は、請求項5に記載の発明において、前記ネットワークは電力用ネットワークであり、前記障害検知用タイマは、ルーチング装置間の伝送遅延時間を下まわらない範囲で汎用ネットワークで用いられる値より小さい値に設定されたことを特徴とする。
この請求項6の発明によれば、電力用ネットワークを対象として、障害検知用タイマは、ルーチング装置間の伝送遅延時間を下まわらない範囲で汎用ネットワークで用いられる値より小さい値に設定されるよう構成したので、汎用ネットワークより短時間で障害検知を行うことができる。
また、請求項7の発明に係るルーチング装置は、請求項6の発明において、障害が検出されたときに、汎用ネットワークで用いられる値より小さい値に設定された障害時状況監視用タイマを用いて前記電力用ネットワークの状況監視を行う障害時状況監視手段をさらに備えたことを特徴とする。
この請求項7の発明によれば、障害が検出されたときに、汎用ネットワークで用いられる値より小さい値に設定された障害時状況監視用タイマを用いて電力用ネットワークの状況監視を行うよう構成したので、汎用ネットワークより短時間で障害対応処理を開始することができる。
また、請求項8の発明に係るルーチング装置は、請求項6または7の発明において、障害復旧の際に、汎用ネットワークで用いられる値より大きい値に設定された復旧時状況監視用タイマを用いて前記電力用ネットワークの状況監視を行う復旧時状況監視手段をさらに備えたことを特徴とする。
この請求項8の発明によれば、障害復旧の際に、汎用ネットワークで用いられる値より大きい値に設定された復旧時状況監視用タイマを用いて電力用ネットワークの状況監視を行うよう構成したので、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすことができる。
また、請求項9の発明に係るルーチング装置は、請求項5〜8のいずれか一つに記載の発明において、前記伝送遅延時間を計測する伝送遅延時間計測手段をさらに備え、前記障害検知手段は、前記伝送遅延時間計測手段により計測された伝送遅延時間に基づいて設定された障害検知用タイマを用いて前記ネットワークの障害検知を行うことを特徴とする。
この請求項9の発明によれば、伝送遅延時間を計測し、計測した伝送遅延時間に基づいて設定された障害検知用タイマを用いてネットワークの障害検知を行うよう構成したので、伝送遅延時間が変化する場合にも、適切に障害検知を行うことができる。
また、請求項10の発明に係る障害復旧方法は、異なる方式で障害復旧が行われる複数のサブネットワークが接続されて構成されるネットワークの構築に用いられるルーチング装置による障害復旧方法であって、障害復旧の際に、ネットワーク全体が安定するまでの間ネットワーク状況の監視を行う復旧時状況監視工程と、前記復旧時状況監視工程によるネットワーク状況の監視後に障害発生前の状態に復帰させる復帰工程と、を含んだことを特徴とする。
この請求項10の発明によれば、障害復旧の際に、ネットワーク全体が安定するまでの間ネットワーク状況の監視を行い、監視後に障害発生前の状態に復帰させるよう構成したので、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすことができる。
また、請求項11の発明に係る障害復旧方法は、ネットワークの構築に用いられるルーチング装置による障害復旧方法であって、ルーチング装置間の伝送遅延時間に基づいて設定された障害検知用タイマを用いて前記ネットワークの障害検知を行う障害検知工程を含んだことを特徴とする。
この請求項11の発明によれば、ルーチング装置間の伝送遅延時間に基づいて設定された障害検知用タイマを用いてネットワークの障害検知を行うよう構成したので、障害検知用タイマの値が不必要に大きいことに起因して障害検知が遅れることを防ぐことができる。
請求項1および10の発明によれば、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすので、ネットワークの信頼性を向上させることができるという効果を奏する。
また、請求項2の発明によれば、障害復旧後の経路情報に基づいて確実にパケットを転送するので、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすことができるという効果を奏する。
また、請求項3の発明によれば、ネットワーク全体が安定するまでの時間が変化する場合にも、適切な時間ネットワーク状況の監視を行って、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすことができるという効果を奏する。
また、請求項4の発明によれば、障害復旧後のVPNラベルテーブルに基づいて確実にパケットを転送するので、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすことができるという効果を奏する。
また、請求項5および11の発明によれば、障害検知用タイマの値が不必要に大きいことに起因して障害検知が遅れることを防ぐので、ネットワークの信頼性を向上させることができるという効果を奏する。
また、請求項6の発明によれば、電力用ネットワークに対しては汎用ネットワークより短時間で障害検知を行うので、電力用ネットワークシステムに必要な信頼性を確保することができるという効果を奏する。
また、請求項7の発明によれば、汎用ネットワークより短時間で障害対応処理を開始するので、電力用ネットワークシステムに必要な信頼性を確保することができるという効果を奏する。
また、請求項8の発明によれば、サブネットワーク間で障害復旧方式が異なることに起因して障害復旧の際に発生するパケットロスをなくすので、電力用ネットワークの信頼性を向上させることができるという効果を奏する。
また、請求項9の発明によれば、伝送遅延時間が変化する場合にも、適切に障害検知を行って障害に対応することができるという効果を奏する。
以下に添付図面を参照して、この発明に係るルーチング装置および障害復旧方法の好適な実施例を詳細に説明する。なお、本実施例では、本発明を電力用IPネットワークに適用した場合を中心に説明する。
まず、本実施例に係る電力用IPネットワークの構成について説明する。図1は、本実施例に係る電力用IPネットワークの構成を示す図である。この電力用IPネットワークでは、ネットワークを論理的に分離する技術であるVLAN(Virtual LAN)とVPNを適用することで、監視制御系ネットワークと設備保全系ネットワークを統合することができる。
図1において、末端の各事業所から制御所等の拠点までのローカル系ネットワーク(以下:ローカル系)については、他の方式より構築コストで有利な広域イーサネット方式を適用する。各事業所に設置されるシステムについては、信頼性を高めるために、システム毎にVLANを分けて、スイッチに接続する構成とする。また、2系統構成とするために、各事業所には系統毎にスイッチを配置し、各拠点にはこれらの事業所からの回線を接続するためのスイッチを系統毎に配置する。ローカル系回線の接続方法は、運用面から2系統とも同一拠点に接続する構成とする。
さらに、各拠点のスイッチ間および、各事業所のスイッチ間を接続することで、ローカル系に障害が発生した場合でも、後述する障害回復方式により迂回することができる。なお、実際には全拠点にスイッチが配置されるが、図中では簡略化のため、拠点A,D以外のスイッチは省略している。
ローカル系とコア系ネットワーク(以下:コア系)を接続するための中継系ネットワーク(以下:中継系)に関しては、冗長構成とするために、系統毎に異なる拠点のMPLSルータと接続する。このため、拠点のMPLSルータが2台とも同時に障害でダウンした場合でも、中継系の障害回復方式により迂回できる。
ネットワークの基幹となるコア系は、2系統構成とするために、各拠点にMPLSルータを2台ずつ設置し、系統毎に独立したネットワークを構築する。系統毎のネットワークトポロジは、各拠点間を結ぶリング構成をベースとし、さらに耐障害性を向上させるために、メッシュ構成とする。ただし、図中では簡略化のため、リング構成として記載している。
また、VLANと同数のVPNを作成し、一対一で対応させることでシステム毎に、エンド−エンド間で論理的に独立したネットワークを構築できる。この構成例では、ネットワーク全体を2重化構成とし、VLANとVPNを適用することで、より信頼性の高いネットワークが実現できる。
また、各ネットワークに障害回復方式を適用することで、片系が障害等でダウンした場合でも直ちに、予備回線が再確立されるため、常に2系統構成が確保される。さらに、両系統が障害等でダウンした場合でも、障害回復方式により迂回できるため、耐障害性に優れた構成となっている。
次に、この構成例に適用できる障害回復方式について説明する。図2に各系に適用可能な障害回復方式を示す。これらの方式はどの組み合わせで適用しても構わないが、本実施例では、ローカル系にはMST(Multiple Spanning Tree)を、中継系にはHSRP(Hot Standby Router Protocol)を、コア系にはパスプロテクションを用いることとする。
ローカル系の障害回復方式にはCST(Common Spanning Tree)とMSTがある。CSTは、IEEE802.1qで規定されている方式で、計算アルゴリズムにはSTP(Spanning Tree Protocol)を用いる。STPは、冗長構成のスイッチネットワークにおいて、ブロードキャストパケットがループすることを防止するためにIEEE802.1dで規定されているプロトコルである。STPの動作としては、スイッチ間で制御パケットをやりとりし、特定のポートをブロックすることで、論理的にツリー状にネットワークを再構築する。障害が発生した場合は、ブロックしたポートを転送状態に移行することで迂回できる。
MSTは、IEEE802.1sで規定されている方式で、計算アルゴリズムにRSTP(Rapid Spanning Tree Protocol)を利用する方式である。RSTPは、障害時にSTPより高速に迂回できるように改良された方式である。また、MSTは論理的なツリーを複数作成することで負荷分散も行えるように改良されている。理論値では、CSTは迂回するまでに最大50秒かかるのに対し、MSTは1秒程度での迂回が可能である。
中継系における障害回復方式には、HSRPとVRRP(Virtual Router Redundancy Protocol)がある。両方式ともIETF(Internet Engineering Task Force)で標準化されているデフォルトゲートウェイの冗長化プロトコルであり、両プロトコルに大きな違いはない。
プロトコルの動作としては図3に示すように、ルータ「R1」と「R3」で共通の仮想IPアドレスを持つ仮想インタフェースを作成する。パソコン「PC1」にはデフォルトゲートウェイアドレスとして仮想IPアドレスを設定しているため、スイッチは「PC1」から外部ネットワーク宛てのパケットを受け取ると、優先度を高く設定されたルータ「R1」へパケットを転送する。
また、「R1」と「R3」との間で生存確認用のパケットをスイッチ経由で定期的にやりとりしているため、もし、図3に示すようにリンクやルータが障害で、ダウンした場合には、「R3」は「R1」からの生存確認用パケットを受信できなくなる。「R3」は一定時間(ホールドタイマ)、生存確認用パケットが受信できないと、障害と判断し、アクティブルータとして通信を引き継ぐようになる。
例えば、HSRPはIETFのRFC2281(Request For Comment 2281)で生存確認用パケット(Helloパケット)の送信間隔(インターバルタイマ)はデフォルトで3秒、ホールドタイマは10秒に推奨されているため、迂回するまでに理論的には図4に示すように7〜10秒程必要である。
また、Preemptと呼ばれる機能により、アクティブルータ「R1」が復旧した場合は、自動的にアクティブ権限をスタンバイルータ「R3」から奪い、障害前の状態に復帰する動作となる。
コア系で利用できる障害回復方式は大きく分けて、ローカルプロテクション、パスプロテクション、リルート、ルーチングの4つに分類される。
ローカルプロテクション方式は、IETFで標準化されているMPLSの障害回復方式の一つであり、リンクプロテクションとノードプロテクションとに分けられる。リンクプロテクションは、リンク障害時に迂回する方式で、ノードプロテクションは、中継ルータ障害時に迂回する方式である。これらの方式が迂回できるパスの条件としては、パスの途中に1つのリンク、あるいは1つのノードしか含めないことである。
パスプロテクション方式は、IETFでドラフト化されているMPLSの障害回復方式の一つである。この方式は、パスの途中に複数のルータ、あるいは複数のリンクが存在しても迂回できるように、ローカルプロテクションを改良した方式である。
また、ローカルプロテクションとパスプロテクションはFRR方式と呼ばれており、50ms以内での高速な切り替えが可能であるが、バックアップパスは事前にラベルを配布し、確立しておく必要がある。
リルート方式は、IETFで標準化されており、バックアップパスの経路だけ指定しておくMPLSの障害回復方式である。障害発生後にバックアップパスとして指定された経路にラベルを配布し、バックアップパスを確立してから迂回するため、切替時間はFRR方式と比較してラベルを配布する処理時間だけ遅れる。運用者がバックアップパスの経路を明示的に指定するのではなく、ルータに動的に計算させる方式もあるが、どちらの場合でも、バックアップパスの経路は障害が発生する前までに決定しているため、切替時間は同じである。ルータに動的に計算させる方式はバックアップパスの経路を運用者が把握しにくいため、電力用IPネットワークには適さないと考えられる。
ルーチング方式は、MPLSの障害回復方式を明示的に設定しない場合に、デフォルトで適用される方式である。この方式はMPLSのラベルテーブルを作成するために必要なルーチングテーブルを作成するための動的ルーチングプロトコルであるOSPF(Open Shortest Path First)による迂回となるため、他の方式と比較して切替時間は最も遅くなる。また、バックアップパスの経路を明示的に指定することができないため、障害後の経路はOSPFが最適と判断した経路に従うようになる。よって、運用者は障害後の経路が把握できないが、多重障害時でも物理的に迂回経路がある限り迂回は可能である。
次に、障害回復方式に関係する設定パラメータのデフォルト値について説明する。例えば、IETF等で標準化されている障害回復方式に関係する設定パラメータのデフォルト値は、RFCで汎用ネットワーク向けの推奨値が明記されているため、多くのルータではこの推奨値がデフォルト値に設定されている。また、IETF等で標準化されていない障害回復方式を実装している場合は、独自のデフォルト値が設定されている。
これらのデフォルト設定値の根拠としては、これらの障害回復方式を最初に標準化、もしくは開発した時代において、汎用ネットワークに許容される値から決められた数値である。現在でも、デフォルト値がその当時から変わっていない理由としては、初期のルータの中にはその数値しか対応していない機器が存在するためである。
これらの障害回復方式の中にはデフォルト設定の場合、障害時に切替時間が10秒程度必要な方式も含まれているため、デフォルト値のまま電力用IPネットワークへ適用した場合に考えられる問題点としては、切替時間が遅いことが挙げられる。
また、これらの各障害回復方式には、障害が復旧すると他の障害回復方式とは連携せずに、独立して現用ルートへ復帰する機能が実装されている。このため、障害回復方式の組み合わせによっては、現用ルートへ復帰するタイミングにより、パケットロスが発生する可能性がある。
そこで、本実施例では、障害回復方式に関係する設定パラメータを、デフォルト値から電力用IPネットワークへ適した値へ変更することで、障害時には高速に切り替わり、復旧時にはパケットロスを発生することなく復帰する、信頼性の高いネットワークを構築している。
次に、障害時に関係する設定パラメータのうち、値を変更した設定パラメータについて説明する。障害時の切り替え動作は、図5に示すように、大きく分けて障害検知、状況監視、経路計算の3つの動作から成り立っているが、経路計算に必要な時間はプロトコルにより決るため、経路計算に関係する設定パラメータには変更するものはない。そこで、障害検知および状況監視に関係する設定パラメータについて説明する。
障害を検知する方法は、障害回復方式により、インタフェースでリンクダウンを検知する方法と、障害検知用パケットによって検知する方法の2通りに分けられる。例えば、HSRPの場合は、リンクダウンによる検知ではなく障害検知用パケットであるHSRP−Helloパケットにより障害を検知する。
それに対し、MPLSの障害回復方式の場合は、デフォルトではリンクダウンにより障害が検知される。リンクダウンにより障害を検知する時間は、各ルータの仕様によって決まっているため、この時間を早めるための設定パラメータはない。このため、ルータの仕様によりリンクダウンを検知する時間が長い場合は、障害検知用パケットを別途適用することで障害検知を早めることができる。別途適用できる障害検知用パケットとしては、MPLSの障害回復方式専用パケットであるRSVP−Helloパケット、UDP(User Datagram Protocol)パケットで障害検知を行うBFD(Bidirectional Forwarding Detection)などがある。
HSRP−Helloパケットを含めたこれらの障害検知用パケットは、ルータ間で相互にやりとりされるパケットである。ある一定期間、このパケットが対向ルータから受信できないと障害と判断するため、このパケットの送信間隔を調整することで、障害検知時間を調整することができる。
電力用IPネットワークでは障害時には高速に切り替わることが要求されていることから、ルータ間のパケット遅延時間を計測し、その値を下回らないように送信間隔をデフォルトの汎用ネットワーク向けの推奨値から短縮することで、高速に障害を検知することができる。ただし、ルータ間の遅延時間は、輻輳時には増加する恐れがあるため、あらかじめ障害検知用パケットを優先的に伝送するように設定する必要がある。これにより、ルータ間の輻輳による遅延時間は考慮しなくてよいため、中継用として設置された伝送装置や、光ケーブルなどの遅延を考慮するだけでよくなる。
図6に伝送機器や光ファイバーにおける遅延時間を示す。例えば、伝送装置を介さずに直接、スイッチからルータまでを光ケーブルで接続した場合には、光ケーブルの遅延時間が1km当たり0.005msであるため、仮に他拠点への伝送距離が100kmとしても、遅延時間は0.5msとなり、この遅延時間は大きな問題になることはない。
従って、電力用IPネットワークに流れるトラヒックは多くないため、ルータのCPU処理が高速であれば、設定パラメータ値をデフォルトの汎用ネットワーク向けの推奨値から数十ms程度に短縮して早く障害を検知する方が、電力向けには適している。
障害時の状況を監視する時間は、フラッピングの影響を少なくするために用意された時間である。フラッピングとは、回線がアップダウンを繰り返すような不安定な状態のことをいい、回線がダウンした情報をルータが受け取る度に迂回経路の計算を行うとルータに過大な負荷がかかってしまう恐れがある。そのため、障害情報を受け取ってもすぐに迂回経路の計算を始めるのではなく、ある一定期間、状況を監視することで、回線のフラッピングの影響を抑制することがこの状況監視の目的である。よって、この状況を監視するタイマを調整することで、状況監視時間を調整することができる。
ルーチングプロトコルであるOSPFにもSPF(Shortest Path First)タイマと呼ばれるフラッピング抑制タイマがある。また、独自のフラッピング抑制タイマを実装してある場合もある。これらのタイマは、フラッピングが頻繁に起こるような不安定なネットワークには適しているが、フラッピングが起こらない安定したネットワークの場合には、切替時間が遅くなる要因となる。従って、本実施例に係る電力用IPネットワークでは、電磁誘導や気象状況等の影響を受けないため、設定パラメータ値を汎用ネットワーク向けの推奨値から、0秒へ短縮することができる。
次に、復旧時に関係する設定パラメータのうち値を変更した設定パラメータについて説明する。復旧時の復帰動作は、基本的に図7に示すように大きく分けて、復旧検知と状況監視の2つの動作から成り立っている。
ここで、復旧を検知する時間はプロトコルにより決まるため、変更する設定パラメータはない。一方、復旧時における状況を監視する時間は、現用ルートが復旧したことを確認後、そのルートが再びダウンしないか、ある一定時間、状況を監視する時間であるため、このタイマを調整することで、復帰する時間を調整することができる。このタイプの設定パラメータとしては、HSRPとVRRPの状況監視用のタイマであるPreemptホールドタイマがある。
障害回復方式は独立して動作するため、障害回復方式の組み合わせによっては、デフォルト設定において、復旧時にパケットロスが発生することがある。このため、このタイマ値をネットワーク全体で経路情報が更新されて、ネットワークが安定した後で、現用ルートへ復帰するように設定パラメータを変更することで、復旧時におけるパケットロスをなくすことができる。
図8は、ルータ設定パラメータの適正化による信頼性向上方策をまとめて示す図である。設定パラメータを図8に示すように電力用に適切に設定することによって、電力用IPネットワークの信頼性を向上することができる。
次に、本実施例に係るMPLSルータの構成について説明する。図9は、本実施例に係るMPLSルータの構成を示す図である。同図に示すように、このMPLSルータ100は、タイマ設定部110と、障害検知用タイマ記憶部120と、障害時状況監視用タイマ記憶部130と、復旧時状況監視用タイマ記憶部140と、障害検知部150と、障害時状況監視部160と、障害対応処理部170と、復旧時状況監視部180と、復旧処理部190とを有する。
タイマ設定部110は、ネットワーク運用者の指示を受け付けて障害検知用タイマ記憶部120、障害時状況監視用タイマ記憶部130および復旧時状況監視用タイマ記憶部140にタイマ値を設定する処理部である。ネットワーク運用者は、MPLSルータ100のタイマのデフォルト値を変更することによって、MPLSルータ100を電力用IPネットワークに適したものにすることができる。
障害検知用タイマ記憶部120は、障害発生の検知に関係する時間を記憶する記憶部であり、MPLSルータ間でやりとりする障害検知用パケットの送信間隔時間と、障害検知用パケットを受信できない場合に障害と判断される一定の時間とを記憶する。
具体的には、この障害検知用タイマ記憶部120は、電力用IPネットワークに適するHSRP−Helloタイマの値として、送信時間間隔(HSRPインターバルタイマ)については汎用ネットワークの設定値より小さい値(例えば50ms)を記憶し、障害検知用パケットを受信できない場合に障害と判断される一定時間(HSRPホールドタイマ)についても汎用ネットワークの設定値より小さい値(例えば200ms)を記憶する。
ただし、HSRP−Helloタイマの値としは、MPLSルータ間の伝送遅延時間を下回らないようにする必要がある。また、この障害検知用タイマ記憶部120は、MPLSの障害復旧方式を採用する場合には、RSVP−Helloタイマの値またはBFDタイマの値を記憶する。
障害時状況監視用タイマ記憶部130は、障害を検知した際にフラッピングの影響を抑制するための監視時間を記憶する記憶部であり、この障害時状況監視用タイマ記憶部130に記憶された時間経過した時点でも障害が検知されている場合に障害と判断される。具体的には、この障害時状況監視用タイマ記憶部130は、SPFタイマの値として汎用ネットワークの設定値より小さい値(例えば1ms)を記憶する。
復旧時状況監視用タイマ記憶部140は、復旧を検知した際にコア系で経路情報が更新されて電力用ネットワーク全体が安定した後に現用ルートへ復帰するための監視時間を記憶する記憶部であり、復旧検知後にこの復旧時状況監視用タイマ記憶部140に記憶された時間経過した時点で現用ルートへの復帰が行われる。具体的には、この復旧時状況監視用タイマ記憶部140は、Preemptホールドタイマの値として汎用ネットワークの設定値より大きい値(例えば60秒)を記憶する。
障害検知部150は、障害検知用パケットを障害検知用タイマ記憶部120に記憶された一定時間受信できない場合に障害を検知したと判断する処理部である。この障害検知部150が、電力用IPネットワークに適するHSRP−Helloタイマの値を用いて障害の発生を検知することによって、障害の継続時間を短縮することができる。
障害時状況監視部160は、障害が検知された際に障害時状況監視用タイマ記憶部130に記憶された時間が経過するまで状況を監視して障害が発生したか否かを判断する処理部である。この障害時状況監視部160が、電力用IPネットワークに適するSPFタイマの値を用いて障害の発生を判断することによって、障害の継続時間を短縮することができる。
障害対応処理部170は、障害時状況監視部160が障害が発生したと判断した場合に、障害箇所を迂回するために必要な経路計算などの処理を行う処理部である。
復旧時状況監視部180は、障害の復旧を検知すると、復旧時状況監視用タイマ記憶部140に記憶された時間だけ状況を監視し、復旧時状況監視用タイマ記憶部140に記憶された時間経過した時点で障害が復旧したと判断して復旧処理部190に復旧を通知する処理部である。
この復旧時状況監視部180が、電力用IPネットワークに適するPreemptホールドタイマの値を用いて復旧状況を監視することによって、コア系で経路情報が更新されてネットワークが安定した後に現用ルートへの復帰を行うことができる。
復旧処理部190は、復旧時状況監視部180から障害復旧の通知を受け取ると、障害前の現用ルートに戻すための処理を行う処理部である。
次に、本実施例に係るMPLSルータ100の処理手順について説明する。図10は、本実施例に係るMPLSルータ100の処理手順を示すフローチャートである。同図に示すように、このMPLSルータ100は、障害検知部150が障害検知用タイマ記憶部120に記憶されたタイマ(HSRPインターバルタイマおよびHSRPホールドタイマ)の値に基づいて障害検知を行う(ステップS1)。
そして、障害検知部150によって障害が検知されると、障害時状況監視部160が障害時状況監視用タイマ記憶部130に記憶されたタイマ(SPFタイマ)の値だけネットワークの状況を監視する(ステップS2)。
そして、タイマ値経過後も障害が検知された状態で障害時状況監視部160が障害が発生したと判断すると、障害対応処理部170が障害発生箇所を迂回するために必要な処理を行う(ステップS3)。
その後、障害が復旧すると、復旧時状況監視部180が復旧時状況監視用タイマ記憶部140に記憶されたタイマ(Preemptホールドタイマ)の値に基づいて復旧状況を監視し、タイマ値の時間が経過すると復旧処理部190に障害復旧を通知する(ステップS4)。そして、復旧処理部190が障害発生前の現用ルートに戻す処理を行う(ステップS5)。
このように、電力用IPネットワークに適した値が設定された障害検知用タイマ記憶部120、障害時状況監視用タイマ記憶部130および復旧時状況監視用タイマ記憶部140に基づいて障害に対応するために必要な処理および障害復旧に必要な処理を行うことによって、復旧時のパケットロスをなくすとともに、障害継続時間を短縮することができる。
次に、本実施例に係る障害復旧方法の評価について説明する。本実施例に係る障害復旧方法の評価は、図1に示した電力用IPネットワークを模擬した評価システムを用いて行った。図11は、評価システムの構成を示す図である。同図に示すように、評価システムは、MPLSルータ4台とスイッチ8台を用いて構成した。なお、評価システムでは、コア系のみ片系の構成とした。
負荷はトラヒックジェネレータを使用し、事業所Xからローカル系-中継系-コア系-中継系-ローカル系-事業所Zへと流れる1方向データフローとした。例えば、監視制御系の場合は、事業所Xからある拠点までが監視情報の流れとなり、ある拠点から事業所Zまでが制御情報の流れを模擬しているということになる。図中の太線はPoS(Packet over SONET)回線を示し、細線はFast Ethernet回線を示している。
また、評価システムでは、評価システム全体において実際に電力用ネットワークへ適用する際の環境に合わせるため、ルータやスイッチには事前に以下に示す代表的な障害回復方式を適用した。
・ローカル系にMSTを適用
・中継系にHSRPを適用
・コア系にパスプロテクションを適用
・事業所のスイッチにVLANを適用
・コア系にVPNを適用(VPN検証時)
・コア系は経由するルータが少ない経路を現用パスに指定し、反対周りにバックアップパスを指定
・中継系にHSRPを適用
・コア系にパスプロテクションを適用
・事業所のスイッチにVLANを適用
・コア系にVPNを適用(VPN検証時)
・コア系は経由するルータが少ない経路を現用パスに指定し、反対周りにバックアップパスを指定
図12は、各ルータや各スイッチに事前に行った設定を示す図である。同図に示すように、事業所スイッチに対してはVLANの設定、エッジポートの指定、トランクモードの設定、MSTの設定を行った。
すなわち、各システムが接続される各ポートには論理的にネットワークを分離するためにVLANを設定した。この評価システムでは、図12に示すように、2つのシステムを収容するイメージで「VLAN1」と「VLAN2」を設定している。
事業所のスイッチの配下には各システムが直接、接続されているため、ブロードキャストがループするような構成にはなっていない。よって、システムをポートに接続した時にはSTPの計算は無視して、直ちに、リンクアップする方が望ましい。このようなブロードキャストがループしないポートのことをエッジポートといい、運用者が明示的にエッジポートに指定することで、そのポートは直ちにリンクアップするようになる。ここでは、ポートファーストコマンドを使用し、このポートをエッジポートに指定した。
各事業所スイッチと、拠点スイッチを接続するポートに関しては、複数のVLAN情報が流れるため、VLANの識別情報を認識できるモードであるトランクモードに設定した。
拠点スイッチ配下のローカル系では障害発生後、MSTにより高速な切り替えを行うことが想定されるため、MSTを設定した。
また、拠点スイッチに対してはトランクモードの設定、エッジポートの指定、MSTの設定を行った。すなわち、各事業所からのローカル系回線が接続されるポートと、MPLSルータとの中継系回線が接続されるポートには複数のVLANのパケットが流れるため、VLANの識別情報を認識できるモードであるトランクモードに設定した。
MPLSルータとの中継回線が接続されるポートは、ブロードキャストストームが発生する恐れがないため、事業所スイッチと同様に、ポートファーストコマンドを使用し、エッジポートに指定した。
拠点スイッチ配下のローカル系では障害発生後、MSTにより高速な切り替えを行うことが想定されるため、事業所スイッチと同様にMSTを設定した。
また、MPLSルータに対しては、VPNの設定、HSRPの設定、パスプロテクションの設定を行った。すなわち、拠点スイッチと接続されるインタフェースに関しては、VLANと同数のサブインタフェースという論理インタフェースを定義し、サブインタフェース毎にVPNを作成した。VLANと一対一で対応させることでシステム毎に、論理的に独立したネットワークを構築することができる。
中継系の障害回復方式のHSRPをサブインタフェース毎に設定し、送信側では、「R1」の優先度を高くした。
障害回復方式としては、高速な切り替えが可能で、MPLSルータ間でもパス管理が可能なパスプロテクションが電力用IPネットワークには適していると考えられるためパスプロテクションを適用した。
コア系のパス設定には、常に高信頼性であることが要求されるため、基本的に自分以外のすべてのルータとパスを設定するのが望ましいと考えられる。パス経路としてはネットワークがリングトポロジの場合には経由するルータの数が少ない経路を現用パス経路として明示的に指定し、バックアップパスは現用パスとは反対周りに明示的に指定した。
ハーフメッシュやフルメッシュの場合でも、ベースはリングトポロジであるため、パスを設定する際には、リングトポロジに従って、経由するルータの数が少ないルートを現用パスに指定した。また、宛先ルータまでルータ数が同じ場合は、右周りを現用パスとして、左周りをバックアップパスとした。
メッシュの中継回線にはパスは設定しない。この中継回線はあくまでも多重障害時用のルーチングによる迂回経路として用いる。評価システムでもこの考え方を適用し、「R1」からは図13に示すように現用パスを設定し、「R3」からは図14に示すように現用パスを設定した。
次に、評価システムによる評価結果について図15および図16を用いて説明する。なお、図中の障害箇所番号と表中の障害箇所番号は一致している。図15は、図11に示したような箇所で障害を起こした場合に、各箇所に関係する設定パラメータ値を変更することで、信頼性が向上するかを評価した結果を示す図である。
図15に示すように、デフォルト設定では障害継続時間は8.7秒程度であった。この時間を短縮するために、HSRPインターバルタイマを50ms、HSRPホールドタイマを200msに変更して評価を行った。その結果、障害継続時間を180ms程度に短縮でき、8秒程度の改善が図れた。また、実機評価によりHSRPインターバルタイマの短縮によるCPU負荷も計測したが、50msに短縮した場合でもCPU使用率の上昇は見られなかった。
このように、電力用IPネットワークへ適用する際に、ルータのCPU負荷を考慮しながら冗長構成をとるルータ間の伝送遅延時間を下回らないように設定パラメータを短縮すると、障害継続時間を改善することができる。
また、MPLSパスの終端ルータ(障害発生箇所5)がダウンした場合には、新しいバックアップパスをOSPFにより再構築する必要があるため、切替時間には、SPFタイマが影響してくる。このことは、パスプロテクション方式に限ることではなく、他のMPLSの障害回復方式でも同じである。
評価システムでは、SPFタイマはデフォルトで5秒に設定されていたため、評価結果でも切替時間は5秒を越える結果となっていた。これを改善するために、SPFタイマをデフォルトの5秒から1msへ短縮し評価を行った。結果は、デフォルト時と比較して5秒程度の短縮を図ることができた。
このように、SPFタイマはネットワークの安定性を考慮して変更する必要がある。例えば、電磁誘導や気象状況の影響がなく安定している回線ではデフォルト値から0秒に設定変更することが考えられる。
なお、OSPFが動いているエリアでは、すべてのルータのSPFタイマ値が一致していないと、個々のルータで経路計算を始める時間が異なるため、ルーチングできない時間が発生してしまう。そのため、エリア内におけるすべてのルータのSPFタイマ値を合わせておく必要がある。
また、図15(障害発生箇所5)に示すように、コア系にVPNを設定した環境で拠点Aのルータが復旧した場合、デフォルト設定では10〜20秒のロスが発生する。これは、中継系のHSRPの復帰する機能とコア系のパスプロテクションの復帰する機能が連携を取らずに独立したタイミングで復帰動作を行うために生じる問題である。
すなわち、ルータが復旧すると、まずHSRPがルータのリンクがアップしたことを検知して、直ちに復帰動作を行う。しかし、この時点でコア系ではVPNラベルテーブルの再構築などの処理を行っているため、中継系から送られてきたパケットを転送できずにパケットロスが発生する。
そこで、この問題を改善するために、コア系の経路計算が完了するまで、HSRPは復帰動作を行わないようにPreemptホールドタイマの設定を変更して評価した。その結果、タイマをデフォルトの0秒からコア系が安定する60秒へ変更すると、デフォルト時に発生していたパケットロスが発生せずに現用ルートへ復帰することが確認できた。
このように、Preemptホールドタイマの設定では、コア系のOSPFのルーチングテーブルやVPN用のテーブルの更新が完了するまでの時間は最低保持させるようにすることが重要である。
なお、HSRPの復帰する機能を無効にする方法もあるが、運用上、パスのルートはできるだけ一定に固定する方が望ましいため、HSRPの復帰する機能は有効にし、タイマをデフォルトから延長してパケットをロスすることなく復帰する方法が電力用IPネットワークには適していると考えられる。
また、VRRPにも同様の復帰する機能があるため、HSRPと同様にPreemptホールドタイマをデフォルト値から最適な値へ変更する必要がある。
図16は、コア系に関して各障害回復方式と対象回線別に評価した結果を示す図である。RSVP−HelloパケットはMPLSの障害回復専用の障害検知パケットであるため、ローカルプロテクション、パスプロテクション、リルートの3方式に有効である。ただし、MPLSの障害回復方式においてRSVP−Helloパケットは必須ではないため、デフォルトでは、RSVP−Helloは設定されていない。従って、インタフェースのリンクダウンをトリガにして切り替え動作を行うようになる。
リンクダウンを検知する速度は、図16に示すように、イーサネット回線の場合は、1秒程かかっていた。この検知時間を短縮するために、送信間隔を10msに設定したRSVP−Helloパケットを適用して評価を行った。ルータはRSVP−Helloパケットを4回受信できないと障害と判断する(40ms程度)ため、デフォルト時と比較してローカルプロテクションでは1秒程度の改善が実現できた。
パスプロテクションで改善が見られない理由としては、評価システムでパスプロテクションはRSVP−Helloパケットがサポートされていなかったためである。よって、もしサポートされていれば、ローカルプロテクションと同様に、1秒程度の改善が図られると考えられる。
リルート方式にもRSVP−Helloパケットは適用できるが、評価システムでは送信間隔を最短で1000msまでしか設定ができなかったため、リンクダウンによる検知の方が高速であることから、適用しても改善は見られなかった。
一方、PoS回線は、RSVP−Helloパケットを適用しないデフォルト状態にもかかわらずローカルプロテクションでは1ms程度の高速な切り替えができていた。これは、本評価システムに限らず、どのルータでもPoSインタフェースの仕様により、リンクダウンを検知する速度が非常に高速であるためである。従って、トラヒックの面からもPoS回線にはRSVP−Helloパケットは使用しない方がよいと考えられる。
なお、イーサネット回線でもリンクダウンを高速に検知できる場合もあるため、そのような場合には、トラヒック状況などを考慮してRSVP−Helloパケットを適用するべきか検討する必要がある。
また、図16に示すように、評価システムではベンダ独自タイマとして、キャリアデレイタイマが設定されていた。このタイマは、PoS回線専用のフラッピング抑制タイマである。目的としては、PoS回線障害をインタフェースで検知した後で直ちに、他のルータへ障害が発生したことを知らせるのではなく、ある一定時間、状態を監視してから、他のルータへ知らせることでフラッピングの影響を抑制している。評価システムでは、デフォルトで2秒が設定されていた。
このキャリアデレイタイマは、ローカルプロテクション方式では無効になっていたため、図16に示すように高速で切り替わっていたが、パスプロテクションでは、このキャリアデレイタイマが有効となっていたために、同じFRR方式にもかかわらず切替時間が2秒を越える結果となっていた。
このように、PoS回線フラッピング抑制タイマが設定されているルータでは、適用するネットワーク環境に応じてタイマ値を調整すると同時に、どの方式で有効になっているかをチェックすることが必要となる。また、SPFタイマと同様に、電磁誘導や気象状況の影響がなく安定している回線の場合は、デフォルト値から0秒に設定変更することによって切替時間を短縮することができる。
上述してきたように、本実施例では、障害復旧後にネットワークが安定するために必要な時間を復旧時状況監視用タイマ記憶部140に記憶し、復旧時状況監視部180が障害復旧後に復旧時状況監視用タイマ記憶部140に記憶された時間経過後に障害発生前の現用ルートに復帰するように制御することとしたので、MST、HSRPおよびパスプロテクションが独立に動作する電力用IPネットワークにおいて障害復旧時のパケットロスを防ぐことができる。
また、本実施例では、障害検知用タイマ記憶部120および障害時状況監視用タイマ記憶部130に汎用ネットワークで使用するデフォルト値よりも小さいタイマ値を記憶し、障害検知部150が障害検知用タイマ記憶部120に記憶されたタイマ値に基づいて障害検知を行い、障害時状況監視部160が障害時状況監視用タイマ記憶部130に記憶されたタイマ値に基づいて障害発生を判定することとしたので、障害継続時間を短縮することができる。
なお、本実施例では、障害回復方式として、ローカル系でMSTを用い、中継系でHSRPを用い、コア系でパスプロテクションを用いる場合を中心に説明したが、本発明はこれに限定されるものではなく、他の障害回復方式を組み合わせる場合にも同様に適用することができる。
また、本実施例では、ローカル系、中継系、コア系から構成される電力用IPネットワークについて説明したが、本発明はこれに限定されるものではなく、異なる障害回復方式が独立に動作するネットワークにも同様に適用することができる。
また、本実施例では、障害検知用タイマ記憶部120や復旧時状況監視用タイマ記憶部140に記憶するタイマ値をタイマ設定部110が運用者からの指示に基づいて設定する場合について説明したが、これらのタイマ値を自動的に変更するようにすることもできる。そこで、これらのタイマ値を自動的に変更する場合について説明する。
図17は、障害検知用タイマ記憶部120および復旧時状況監視用タイマ記憶部140に記憶するタイマ値を自動的に変更するMPLSルータの構成を示す機能ブロック図である。なお、ここでは説明の便宜上、図9に示した各部と同様の役割を果たす機能部については同一符号を付すこととしてその詳細な説明を省略する。
図17に示すように、このMPLSルータ200は、図9に示したMPLSルータ100が有する機能部に加えて、コア系安定時間測定部210と、伝送遅延時間測定部220とを有する。
コア系安定時間測定部210は、障害が復旧してコア系が安定するまでに必要な時間を測定する処理部である。ここで、障害が復旧してコア系が安定するまでに必要な時間とはVPNラベルテーブルの再構築などに必要な時間である。このコア系安定時間測定部210は、ネットワークの物理構成に変更があった際などに、コア系が安定するまでの時間を測定し、測定結果に基づいて復旧時状況監視用タイマ記憶部140に適切なタイマ値を設定する。
伝送遅延時間測定部220は、ルータ間の伝送遅延時間を測定する処理部であり、定期的に伝送遅延時間を測定し、測定結果に基づいて障害検知用タイマ記憶部120に適切なタイマ値を設定する。
このように、コア系安定時間測定部210が、コア系が安定するまでの時間を測定し、測定結果に基づいて復旧時状況監視用タイマ記憶部140に適切なタイマ値を設定し、伝送遅延時間測定部220が、ルータ間の伝送遅延時間を測定し、測定結果に基づいて障害検知用タイマ記憶部120に適切なタイマ値を設定することによって、電力用IPネットワークの状況に適したタイマ値を動的に設定することができる。
以上のように、本発明に係るルーチング装置および障害復旧方法は、複数の障害復旧方式が独立に動作するネットワークに有用であり、特に、電力用ネットワークなど高い信頼性が要求されるネットワークに適している。
100,200 MPLSルータ
110 タイマ設定部
120 障害検知用タイマ記憶部
130 障害時状況監視用タイマ記憶部
140 復旧時状況監視用タイマ記憶部
150 障害検知部
160 障害時状況監視部
170 障害対応処理部
180 復旧時状況監視部
190 復旧処理部
210 コア系安定時間測定部
220 伝送遅延時間測定部
110 タイマ設定部
120 障害検知用タイマ記憶部
130 障害時状況監視用タイマ記憶部
140 復旧時状況監視用タイマ記憶部
150 障害検知部
160 障害時状況監視部
170 障害対応処理部
180 復旧時状況監視部
190 復旧処理部
210 コア系安定時間測定部
220 伝送遅延時間測定部
Claims (11)
- 異なる方式で障害復旧が行われる複数のサブネットワークが接続されて構成されるネットワークの構築に用いられるルーチング装置であって、
障害復旧の際に、ネットワーク全体が安定するまでの間ネットワーク状況の監視を行う復旧時状況監視手段と、
前記復旧時状況監視手段によるネットワーク状況の監視後に障害発生前の状態に復帰させる復帰手段と、
を備えたことを特徴とするルーチング装置。 - 前記復旧時状況監視手段は、前記複数のサブネットワークのうちの特定のサブネットワークの経路情報が更新されてネットワーク全体が安定するまでの間ネットワーク状況の監視を行うことを特徴とする請求項1に記載のルーチング装置。
- 前記複数のサブネットワークのうちの特定のサブネットワークの経路情報が更新されてネットワーク全体が安定するまでの時間を計測する復旧時監視時間測定手段をさらに備え、
前記復旧時状況監視手段は、障害復旧の際に、前記復旧時監視時間測定手段により測定された時間が経過するまでネットワーク状況の監視を行うことを特徴とする請求項2に記載のルーチング装置。 - 前記特定のサブネットワークにはMPLSが適用され、ネットワーク全体が安定するまでの間にVPNラベルテーブルが再構築されることを特徴とする請求項2または3に記載のルーチング装置。
- ネットワークの構築に用いられるルーチング装置であって、
ルーチング装置間の伝送遅延時間に基づいて設定された障害検知用タイマを用いて前記ネットワークの障害検知を行う障害検知手段
を備えたことを特徴とするルーチング装置。 - 前記ネットワークは電力用ネットワークであり、
前記障害検知用タイマは、ルーチング装置間の伝送遅延時間を下まわらない範囲で汎用ネットワークで用いられる値より小さい値に設定されたことを特徴とする請求項5に記載のルーチング装置。 - 障害が検出されたときに、汎用ネットワークで用いられる値より小さい値に設定された障害時状況監視用タイマを用いて前記電力用ネットワークの状況監視を行う障害時状況監視手段をさらに備えたことを特徴とする請求項6に記載のルーチング装置。
- 障害復旧の際に、汎用ネットワークで用いられる値より大きい値に設定された復旧時状況監視用タイマを用いて前記電力用ネットワークの状況監視を行う復旧時状況監視手段をさらに備えたことを特徴とする請求項6または7に記載のルーチング装置。
- 前記伝送遅延時間を計測する伝送遅延時間計測手段をさらに備え、
前記障害検知手段は、前記伝送遅延時間計測手段により計測された伝送遅延時間に基づいて設定された障害検知用タイマを用いて前記ネットワークの障害検知を行うことを特徴とする請求項5〜8のいずれか一つに記載のルーチング装置。 - 異なる方式で障害復旧が行われる複数のサブネットワークが接続されて構成されるネットワークの構築に用いられるルーチング装置による障害復旧方法であって、
障害復旧の際に、ネットワーク全体が安定するまでの間ネットワーク状況の監視を行う復旧時状況監視工程と、
前記復旧時状況監視工程によるネットワーク状況の監視後に障害発生前の状態に復帰させる復帰工程と、
を含んだことを特徴とする障害復旧方法。 - ネットワークの構築に用いられるルーチング装置による障害復旧方法であって、
ルーチング装置間の伝送遅延時間に基づいて設定された障害検知用タイマを用いて前記ネットワークの障害検知を行う障害検知工程
を含んだことを特徴とする障害復旧方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006138998A JP2007312091A (ja) | 2006-05-18 | 2006-05-18 | ルーチング装置および障害復旧方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006138998A JP2007312091A (ja) | 2006-05-18 | 2006-05-18 | ルーチング装置および障害復旧方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007312091A true JP2007312091A (ja) | 2007-11-29 |
Family
ID=38844533
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006138998A Pending JP2007312091A (ja) | 2006-05-18 | 2006-05-18 | ルーチング装置および障害復旧方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007312091A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012134683A (ja) * | 2010-12-21 | 2012-07-12 | Fujitsu Ltd | 通信制御方法,通信制御システム,および通信制御プログラム |
JP2014003389A (ja) * | 2012-06-15 | 2014-01-09 | Nippon Telegr & Teleph Corp <Ntt> | 論理リング切替方法、リングノード、及びリングネットワーク |
WO2014184952A1 (ja) | 2013-05-17 | 2014-11-20 | 三菱電機株式会社 | 通信装置および車両伝送システム |
JP2015527825A (ja) * | 2012-07-27 | 2015-09-17 | アルカテル−ルーセント | グレースフルリスタート対応のネイバのためにrsvphello抑制を使用するシステムおよび方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05336114A (ja) * | 1992-06-03 | 1993-12-17 | Fujitsu Ltd | ネットワーク監視方式 |
JPH06326722A (ja) * | 1993-05-18 | 1994-11-25 | Fujitsu Ltd | パス スイッチ回路 |
-
2006
- 2006-05-18 JP JP2006138998A patent/JP2007312091A/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05336114A (ja) * | 1992-06-03 | 1993-12-17 | Fujitsu Ltd | ネットワーク監視方式 |
JPH06326722A (ja) * | 1993-05-18 | 1994-11-25 | Fujitsu Ltd | パス スイッチ回路 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012134683A (ja) * | 2010-12-21 | 2012-07-12 | Fujitsu Ltd | 通信制御方法,通信制御システム,および通信制御プログラム |
JP2014003389A (ja) * | 2012-06-15 | 2014-01-09 | Nippon Telegr & Teleph Corp <Ntt> | 論理リング切替方法、リングノード、及びリングネットワーク |
JP2015527825A (ja) * | 2012-07-27 | 2015-09-17 | アルカテル−ルーセント | グレースフルリスタート対応のネイバのためにrsvphello抑制を使用するシステムおよび方法 |
US9491046B2 (en) | 2012-07-27 | 2016-11-08 | Alcatel Lucent | System and method for switching traffic from sub-optimal primary P2MP to standby P2MP |
US9705735B2 (en) | 2012-07-27 | 2017-07-11 | Alcatel Lucent | System and method using RSVP hello suppression for graceful restart capable neighbors |
WO2014184952A1 (ja) | 2013-05-17 | 2014-11-20 | 三菱電機株式会社 | 通信装置および車両伝送システム |
US10069709B2 (en) | 2013-05-17 | 2018-09-04 | Mitsubishi Electric Corporation | Communication apparatus and vehicle transmission system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Sharma et al. | OpenFlow: Meeting carrier-grade recovery requirements | |
EP1111860B1 (en) | Automatic protection switching using link-level redundancy supporting multi-protocol label switching | |
US8259563B1 (en) | Fast restoration for provider edge node and access link failures | |
EP2962429B1 (en) | Traffic recovery in openflow networks | |
AU2009237405B2 (en) | Connectivity fault management traffic indication extension | |
JP5566463B2 (ja) | コンピュータネットワークにおけるデータ転送の技術 | |
US8982710B2 (en) | Ethernet operation and maintenance (OAM) with flexible forwarding | |
RU2530338C2 (ru) | Предварительно подготовленное сопряжение на основе состояния линий связи поставщиков (plsb) с маршрутизируемым резервированием | |
CN101931520B (zh) | 一种切换方法及系统 | |
EP2951959B1 (en) | Using ethernet ring protection switching with computer networks | |
JP4682887B2 (ja) | 故障復旧方法およびノードならびにネットワーク | |
EP2498454A1 (en) | Method, device and system for processing service traffic based on pseudo wires | |
US20100315946A1 (en) | Failure protection for access ring topology | |
CN109672619A (zh) | 一种处理报文的方法、设备及系统 | |
EP1802985A2 (en) | Efficient protection mechanisms for protecting multicast traffic in a ring topology network utilizing label switching protocols | |
JP4773981B2 (ja) | 通信制御プログラム | |
CN101159669A (zh) | 一种业务流量切换方法及装置 | |
WO2007016834A1 (fr) | Procede rapide de convergence de services de point a point et dispositif associe cote fournisseur de services | |
JP2009524332A (ja) | リング・ネットワークのvpls障害保護 | |
WO2012171378A1 (zh) | 解决vpls接入l3故障切换导致断流的方法及路由器 | |
EP2658177B1 (en) | Method for detecting tunnel faults and traffic engineering node | |
JP2008271088A (ja) | 映像伝送網統合運用管理システム及び運用管理方法 | |
JP2007312091A (ja) | ルーチング装置および障害復旧方法 | |
CN108023800A (zh) | 一种lte承载网络的保护方法及装置 | |
JP2008177806A (ja) | パケット交換ネットワークおよび障害完成装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090401 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20101222 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110111 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110705 |