JP2006033124A - トンネル障害通知装置および方法 - Google Patents

トンネル障害通知装置および方法 Download PDF

Info

Publication number
JP2006033124A
JP2006033124A JP2004205595A JP2004205595A JP2006033124A JP 2006033124 A JP2006033124 A JP 2006033124A JP 2004205595 A JP2004205595 A JP 2004205595A JP 2004205595 A JP2004205595 A JP 2004205595A JP 2006033124 A JP2006033124 A JP 2006033124A
Authority
JP
Japan
Prior art keywords
failure
tunnel
line
notification
occurrence
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.)
Withdrawn
Application number
JP2004205595A
Other languages
English (en)
Inventor
Daichi Yasuoka
大知 安岡
Tatsuya Fukuyo
竜也 福世
Atsushi Ito
淳 伊藤
Yukito Shibata
幸人 柴田
Akira Yonenaga
彰 米永
Naomi Oshima
尚美 尾島
Michiko Osawa
美智子 大澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2004205595A priority Critical patent/JP2006033124A/ja
Priority to US11/010,900 priority patent/US20060013126A1/en
Publication of JP2006033124A publication Critical patent/JP2006033124A/ja
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • 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/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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/746—Reaction triggered by a failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】 トンネルを用いてパケットを伝送する通信ネットワークにおいて、回線障害発生時のトンネル障害の検出を高速化し、ネットワークの負荷を低減する。
【解決手段】 Ｃｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間の回線障害が発生すると、Ｃｏｒｅ＃Ｂのルータは、上流のＣｏｒｅ＃Ａに対して、回線単位の障害発生を通知するＨｅｌｌｏメッセージを送信し、Ｃｏｒｅ＃Ａのルータは、そのメッセージを受けて、上流のＨｅａｄ Ｅｎｄに対して障害通知のＨｅｌｌｏメッセージを送信する。Ｈｅａｄ Ｅｎｄのルータは、そのメッセージを受信すると、障害が発生した回線を通過する複数のトンネルの切断処理を行い、復旧通知のＨｅｌｌｏメッセージを受信するまでトンネルの設定を待ち合わせる。
【選択図】図２

Description

本発明は、モバイルＩＰ（Internet Protocol ）ネットワークやＶＯＩＰ（Voice over Internet Protocol）のようなリアルタイムアプリケーション等、トラフィックエンジニアリングを適用し、回線リソース（帯域）を予約して信頼性の高いサービスを提供するＩＰネットワークにおいて、トンネル障害を通知する装置および方法に関する。
トンネル技術は、あるプロトコルで記述されたパケットを別のプロトコルでカプセル化して通信を行う技術である（例えば、特許文献１参照）。この技術によれば、１つの物理回線上に複数のトンネルを構築することが可能である。ＲＦＣ３２０９（非特許文献１）には、ＬＳＰ（Label-Switched Paths）トンネルに対する資源予約プロトコル（Resource ReSerVation Protocol ，以下ＲＳＶＰという）の拡張について記述されている。
ＲＳＶＰによってＩＰパケットの高速伝送のためにトンネル技術を利用した伝送を実施している場合において、ネットワーク上に予約されたトンネル（帯域）が回線障害となった場合、ＲＳＶＰは、回線配下に存在する全トンネルに対して、切断メッセージを隣接ノードに向けて送信する。この際に、トンネル開始ノードであるＨｅａｄ Ｅｎｄが切断メッセージを受信した場合は、受信した切断メッセージを元に該当トンネルの切断処理を行う。トンネルが現用・予備構成を持っている場合は、トンネル切断時にトンネル切り替えを行う。
図２５は、４つのルータからなるＩＰネットワークの構成例を示している。図２５のルータ１１および１４は、それぞれトンネル開始ノード（Ｈｅａｄ Ｅｎｄ）および終了ノード（Ｔａｉｌ Ｅｎｄ）のルータであり、ルータ１２および１３は、開始ノードと終了ノードの間でＩＰパケットを中継する中継ノード（Ｃｏｒｅ＃ＡおよびＣｏｒｅ＃Ｂ）のルータである。
図２６は、図２５のＩＰネットワークにおけるトンネルの構成例を示している。Ｈｅａｄ Ｅｎｄ−Ｃｏｒｅ＃Ａ間、Ｃｏｒｅ＃Ａ−Ｃｏｒｅ＃Ｂ間、およびＣｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間は、１００Ｍの帯域を持つ物理回線２１、２２、および２３によりそれぞれ接続されており、これらの回線上に１Ｍの帯域を持つｎ個のトンネル１〜ｎが確立されている。
このネットワーク構成においてＣｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間の回線障害が発生した場合、図２７に示すように、Ｃｏｒｅ＃Ｂは、上流のＣｏｒｅ＃Ａに対してトンネルｎ個分の障害通知（切断メッセージ）を送信する（ステップ３１）。Ｃｏｒｅ＃Ａは、Ｃｏｒｅ＃Ｂからのトンネルｎ個分の切断メッセージを受けて、上流のＨｅａｄ Ｅｎｄに対してトンネルｎ個分の切断メッセージを送信する。
Ｈｅａｄ Ｅｎｄは、トンネル毎に切断メッセージを受信した契機に、障害発生トンネルの切断処理を行う（ステップ３２−１〜３２−ｎ）。また、Ｈｅａｄ Ｅｎｄの隣接ノードであるＣｏｒｅ＃Ａには障害が発生していないため、Ｅｘｐｌｉｃｉｔで定義トンネルの再確立を行う。ここで、「Ｅｘｐｌｉｃｉｔで」とは、トンネルの経路を明示的に指定することを意味する。回線障害が復旧していない場合は、Ｃｏｒｅ＃Ｂにおいて設定ＮＧとなってしまうが、Ｔａｉｌ Ｅｎｄから設定ＯＫが返送されるまでは、繰り返しトンネル再確立が行われる。
図２８は、８つのルータからなる別のＩＰネットワークの構成例を示している。図２８のルータ４１および４６は、それぞれＨｅａｄ ＥｎｄおよびＴａｉｌ Ｅｎｄのルータであり、ルータ４２〜４５、４７、および４８は、中継ノード（Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、Ｃｏｒｅ＃Ｄ、Ｃｏｒｅ＃Ｅ、およびＣｏｒｅ＃Ｆ）のルータである。
このネットワーク構成において、トンネルの高速障害切り替えであるＦａｓｔ Ｒｅｒｏｕｔｅが実装されている場合、従来技術では現用系と予備系の開始点が一致するノード（Point of Local Repair，ＰＬＲ）であるＣｏｒｅ＃Ａにおいて、現用トンネルと予備トンネルの切り替えが行われる。
現用トンネルは、Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、およびＣｏｒｅ＃Ｄを経由し、予備トンネルは、Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｅ、Ｃｏｒｅ＃Ｆ、およびＣｏｒｅ＃Ｄを経由する。例えば、Ｃｏｒｅ＃Ａの隣接ノードであるＣｏｒｅ＃Ｂに障害が発生した場合、Ｃｏｒｅ＃Ａが予備系側にトンネルを切り替えることができる。
ＲＳＶＰのＨｅｌｌｏ機能は、隣接ノードとＨｅｌｌｏメッセージを一定周期で送受信し、お互いのＲＳＶＰプロトコルが正常状態（サービス状態）であることを確認し合う機能である。Ｈｅｌｌｏメッセージは、各ノードの回線単位でやりとりされる。送受信の周期は、Ｈｅｌｌｏ Ｉｎｔｅｒｖａｌタイマと呼ばれ、このタイマがタイムアウトした場合、Ｈｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）が送信される。
例えば、ノードＡとノードＢの間でＨｅｌｌｏメッセージがやりとりされる場合、図２９に示すように、ノードＡは、ノードＢにＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）を送信した後、Ｈｅｌｌｏ Ｉｎｔｅｒｖａｌタイマをリセットする（ステップ５１）。
ノードＢは、ノードＡからＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）を受信すると、受信したＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）に対してＨｅｌｌｏメッセージ（Ａｃｋ）を返却するので、タイムアウト契機でのＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）の送信は不要となる。そこで、Ｈｅｌｌｏ Ｉｎｔｅｒｖａｌタイマをリセットする（ステップ５２）。また、Ｈｅｌｌｏ Ｌｉｆｅタイマもリセットする（ステップ５３）。
Ｈｅｌｌｏ Ｌｉｆｅタイマの時間内にＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）あるいはＨｅｌｌｏメッセージ（Ａｃｋ）を受信しなかった場合、隣接ノードに障害が発生したものとみなされる。ノードＡは、ノードＢからＨｅｌｌｏメッセージ（Ａｃｋ）を受信したとき、Ｈｅｌｌｏ Ｌｉｆｅタイマをリセットする（ステップ５４）。
特開２００２−３１４５８２号公報 "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, 2001
しかしながら、上述した従来の回線障害通知方法には、以下のような問題がある。
（１）ネットワークトポロジによっては、１つの回線配下に大量のトンネルが存在する場合があり、回線障害発生時に大量のトンネル切断が発生する。これにより、大量のトンネル切断メッセージを隣接ノードに通知しなければならず、ネットワーク内に大量のメッセージが流入し、ネットワークの負荷を上げる恐れがある。また、ＲＳＶＰはＵＤＰ（User Datagram Protocol）であるために、到達確認が行えない。大量のトンネル切断時には、パケットロス等の理由によりメッセージが紛失し、トンネル切断が迅速に行えない可能性がある。
（２）回線障害が復旧していない状態であったとしても、Ｈｅａｄ Ｅｎｄから見た隣接ノード（図２５のＣｏｒｅ＃Ａ）に障害が発生していない場合は、ＲＳＶＰのプロトコル動作としては、切断したトンネルのためのトンネル設定要求を下流ノードに対して送信する（Ｅｘｐｌｉｃｉｔで指定されたトンネルのみ）。したがって、回線障害が復旧するまでの間、不要なメッセージがネットワークに流入し、ネットワークの負荷が上がってしまう恐れがある。
（３）Ｆａｓｔ Ｒｅｒｏｕｔｅは、隣接ノードでの障害発生時のみトンネル切り替えが可能である。図２８のネットワーク構成の場合、Ｃｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間またはＣｏｒｅ＃Ｃ−Ｃｏｒｅ＃Ｄ間で障害が発生すると、Ｆａｓｔ Ｒｅｒｏｕｔｅによるトンネル切り替えを行うことができない。
本発明の課題は、回線障害発生時のトンネル障害の検出を高速化し、ネットワークの負荷を低減することである。
本発明のもう１つの課題は、現用系と予備系の開始点が一致するノードの隣接ノード以外で障害が発生した場合でも、Ｆａｓｔ Ｒｅｒｏｕｔｅを行えるようにすることである。
図１は、本発明のトンネル障害通知装置およびトンネル障害処理装置の原理図である。
本発明の第１の局面において、トンネル障害通知装置は、検出手段１０１および通知手段１０２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知する。検出手段１０１は、通信ネットワーク内の回線上における障害の発生を検出し、通知手段１０２は、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、障害の発生を回線単位で隣接ノードに通知する。
本発明の第２の局面において、第１の局面におけるトンネル障害通知装置は、格納手段１０３をさらに備える。格納手段１０３は、障害が発生した回線の回線情報を格納し、通知手段１０２は、その回線情報が異常を示すとき、障害の発生を隣接ノードに通知する。
第１および第２の局面におけるトンネル障害通知装置によれば、障害が発生した回線配下の複数のトンネルの切断メッセージが１つに集約されて隣接ノードに通知されるので、トンネル障害を高速に通知することができ、ネットワークの負荷が低減される。
本発明の第３の局面において、トンネル障害通知装置は、受信手段１１１および通知手段１１２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知する。受信手段１１１は、通信ネットワーク内の回線上で障害が発生したとき、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信する。通知手段１１２は、受信した障害通知に基づいて、障害の発生を回線単位で第２の隣接ノードに通知する。
本発明の第４の局面において、第３の局面におけるトンネル障害通知装置は、格納手段１１３をさらに備える。格納手段１１３は、障害が発生した回線の回線情報を格納し、通知手段１１２は、その回線情報が異常を示すとき、障害の発生を第２の隣接ノードに通知する。
第３および第４の局面におけるトンネル障害通知装置によれば、第１および第２の局面におけるトンネル障害通知装置の場合と同様に、障害が発生した回線配下の複数のトンネルの切断メッセージが１つに集約されて隣接ノードに通知されるので、トンネル障害を高速に通知することができ、ネットワークの負荷が低減される。
本発明の第５の局面において、トンネル障害通知装置は、受信手段１２１および制御手段１２２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行う。受信手段１２１は、通信ネットワーク内の回線上で障害が発生したとき、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する。制御手段１２２は、受信した障害通知に基づいて、複数のトンネルの切断処理を行った後、障害の復旧を通知する復旧通知を受信するまでそれらのトンネルの再確立を待ち合わせる。
本発明の第６の局面において、第５の局面におけるトンネル障害通知装置は、格納手段１２３および回線管理手段１２４をさらに備える。格納手段１２３は、通信ネットワーク内の複数の回線の回線情報を格納し、回線管理手段１２４は、障害通知を受信したとき、障害が発生した回線の回線情報を正常から異常に変更する。制御手段１２２は、障害が発生した回線の回線情報が異常に変更されたとき、複数のトンネルの切断処理を行う。
第５および第６の局面におけるトンネル障害処理装置によれば、障害が発生した回線配下のトンネルの再確立は障害が復旧するまで行われないので、不要なトンネルの再確立が抑止され、ネットワークの負荷が低減される。
本発明の第７の局面において、トンネル障害通知装置は、受信手段１２１および制御手段１２２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行う。受信手段１２１は、通信ネットワーク内の回線上で障害が発生したとき、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する。制御手段１２２は、受信した障害通知に基づいて、それらのトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う。
本発明の第８の局面において、第７の局面におけるトンネル障害通知装置は、格納手段１２３および回線管理手段１２４をさらに備える。格納手段１２３は、通信ネットワーク内の複数の回線の回線情報を格納し、回線管理手段１２４は、障害通知を受信したとき、障害が発生した回線の回線情報を正常から異常に変更する。制御手段１２２は、障害が発生した回線の回線情報が異常に変更されたとき、現用トンネルから予備トンネルへの切り替え処理を行う。
第７および第８の局面におけるトンネル障害処理装置によれば、現用系と予備系の開始点が一致するノードの隣接ノード以外で障害が発生した場合でも、回線単位の障害通知により回線障害を認識できるので、障害が発生した回線を通過する現用トンネルから、その回線を迂回する予備トンネルへの切り替えを行うことができる。
検出手段１０１は、例えば、後述する図３のルーティング制御モジュール３１３に対応し、通知手段１０２および１１２は、例えば、図３のＨｅｌｌｏ制御モジュール３１６に対応し、受信手段１１１および１２１は、例えば、図３のＳｅｓｓｉｏｎ制御モジュール３１１に対応する。制御手段１２２は、例えば、図３のＳｅｓｓｉｏｎ制御モジュール３１１に対応し、回線管理手段１２４は、例えば、図３の回線管理モジュール３１４に対応する。格納手段１０３、１１３、および１２３は、例えば、ルータ内のメモリに対応する。
本発明によれば、回線障害発生時のトンネル障害を、大量のトンネル切断メッセージを送信することなく、高速に検出することができる。これにより、信頼性の高いサービスを提供することが可能になる。
また、現用系と予備系の開始点が一致するノードの隣接ノード以外で障害が発生した場合でも、Ｆａｓｔ Ｒｅｒｏｕｔｅを行うことが可能になる。
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
本発明における主な改善点は、以下の通りである。
（１）Ｈｅｌｌｏメッセージによる回線単位でのトンネル切断メッセージの送信
従来技術では、回線障害が発生した場合でも、回線配下のトンネル単位に切断メッセージを送信しているが、本発明では回線単位にて切断メッセージを隣接ノードに通知するようにメッセージを集約する。これにより、トンネル障害を高速に通知することができるとともに、ネットワークへの大量のメッセージの流入が抑えられ、ネットワークの負荷を低減させることができる。
（２）不要なトンネル再確立の防止
従来技術では、回線障害が発生している場合でも、トンネル切断後に該当トンネルの再確立を行っている。本発明では、Ｈｅａｄ Ｅｎｄが障害となった回線を認識し、その回線に対応する復旧通知を受信するまでは、該当回線配下のトンネルの再確立を抑止する。復旧通知は、障害通知と同様に回線単位にて行う。これにより、ネットワークへの不要なメッセージの流入が抑えられ、ネットワークの負荷を低減させることができる。
（３）Ｆａｓｔ Ｒｅｒｏｕｔｅへの適用
従来技術では、現用系と予備系の開始点が一致するノードの隣接ノードにて障害が発生した場合にのみ、Ｆａｓｔ Ｒｅｒｏｕｔｅを適用可能である。本発明では、（１）の障害通知を用いて、現用系と予備系の開始点が一致するノードに回線障害を認識させ、隣接ノード以外の障害発生時においても、Ｆａｓｔ Ｒｅｒｏｕｔｅが機能できるようにする。
図２は、上記改善点を盛り込んだ、回線障害発生時の障害通知シーケンスを示している。図２５のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間の回線障害が発生した場合、Ｃｏｒｅ＃Ｂは、上流のＣｏｒｅ＃Ａに対して、回線単位の障害発生を通知するＨｅｌｌｏメッセージを送信する（ステップ２０１）。Ｃｏｒｅ＃Ａは、Ｃｏｒｅ＃ＢからのＨｅｌｌｏメッセージを受けて、上流のＨｅａｄ Ｅｎｄに対して障害通知のＨｅｌｌｏメッセージを送信する。
Ｈｅａｄ Ｅｎｄは、Ｈｅｌｌｏメッセージを受信すると、障害が発生したＣｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間を通過するトンネルを抽出し（ステップ２０２）、トンネルの切断処理を行う（ステップ２０３−１〜２０３−ｎ）。そして、回線障害が復旧するまでトンネルの設定を待ち合わせる（ステップ２０４）。
次に、Ｃｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間の回線障害が復旧すると、Ｃｏｒｅ＃Ｂは、上流のＣｏｒｅ＃Ａに対して、回線単位の障害復旧を通知するＨｅｌｌｏメッセージを送信する（ステップ２０５）。Ｃｏｒｅ＃Ａは、Ｃｏｒｅ＃ＢからのＨｅｌｌｏメッセージを受けて、上流のＨｅａｄ Ｅｎｄに対して復旧通知のＨｅｌｌｏメッセージを送信する。
Ｈｅａｄ Ｅｎｄは、Ｈｅｌｌｏメッセージを受信すると、障害が復旧したＣｏｒｅ＃Ｂ−Ｔａｉｌ Ｅｎｄ間を通過するトンネルを抽出し（ステップ２０６）、Ｅｘｐｌｉｃｉｔで定義トンネルの再確立を行う。
このような障害通知シーケンスによれば、図２７の障害通知シーケンスと比較して、障害通知のための処理数が大幅に軽減される。また、回線障害の復旧通知を受信してからトンネルの設定を行うので、復旧前の不要なトンネル設定処理が削減される。
図３は、本実施形態における各ルータに共通のモジュール構成を示している。図３のルータは、経路管理部３０１およびＲＳＶＰ管理部３０２を備え、ＲＳＶＰ管理部３０２は、Ｓｅｓｓｉｏｎ制御モジュール３１１、メッセージ制御モジュール３１２、ルーティング制御モジュール３１３、回線管理モジュール３１４、タイマ制御モジュール３１５、およびＨｅｌｌｏ制御モジュール３１６を含む。経路管理部３０１は、経路を管理する。
ＲＳＶＰ管理部３０２のＳｅｓｓｉｏｎ制御モジュール３１１は、トンネルの接続、切断、切り替え、Ｒｅｆｒｅｓｈ等、トンネル制御全般を行うとともに、ＲＳＶＰメッセージの受信・送信を実施する。Ｈｅｌｌｏメッセージを受信した場合は、受信したメッセージをＨｅｌｌｏ制御モジュール３１６に渡す。また、トンネル接続時に回線障害が発生している配下トンネルの接続を抑止する機能を備える。
メッセージ制御モジュール３１２は、ＲＳＶＰ Ｓｅｓｓｉｏｎ制御メッセージ・オブジェクトの分析、編集、比較を行う。
ルーティング制御モジュール３１３は、トンネルアドレスについて自局宛判定および出側ルートの特定を実施する。また、Ｅｘｐｌｉｃｉｔの場合のルート情報の妥当性判定および情報の更新も実施する。また、回線障害の通知を受け付けて、Ｈｅｌｌｏ制御モジュール３１６に通知する。
回線管理モジュール３１４は、ＲＳＶＰで使用する回線情報と帯域情報を管理する。また、回線障害発生時のトンネル解放要求も実施する。
タイマ制御モジュール３１５は、Ｓｅｓｓｉｏｎ制御タイマ（ＰａｔｈのＩｎｔｅｒｖａｌ、ＲｅｆｒｅｓｈのＩｎｔｅｒｖａｌ等）を制御する。また、Ｈｅｌｌｏ制御モジュール３１６を周期的に起動する。
Ｈｅｌｌｏ制御モジュール３１６は、Ｈｅｌｌｏメッセージの送受信を行い、メッセージ送信の際に自ノード内に回線障害が発生したか否か、回線障害が復旧したか否かを回線管理モジュール３１４に問い合わせ、障害／復旧情報をＨｅｌｌｏメッセージに付与してメッセージ送信を行う。
また、自ノード内では発生しておらず、受信したＨｅｌｌｏメッセージに障害／復旧情報が付与されていた場合には、回線管理モジュール３１４が管理している回線情報を更新し、イベント駆動にて障害／復旧情報を付与してＨｅｌｌｏメッセージ送信を行う。
新たに隣接ノードからの障害情報を回線情報に設定した場合は復旧メッセージを受信するまで、復旧情報を設定した場合は障害メッセージを受信するまでは、更新された回線情報を保持し、その情報に応じたＨｅｌｌｏメッセージを一定周期で送信する。また、Ｈｅｌｌｏタイマ（Ｉｎｔｅｒｖａｌ、Ｌｉｆｅ）の制御を実施し、Ｈｅｌｌｏエラー検出時にはトンネル解放を実施する。
経路管理部３０１およびＲＳＶＰ管理部３０２の各モジュールの機能は、ハードウェアまたはソフトウェアにより実現される。ソフトウェアにより実現する場合、ルータ内のメモリに、経路管理部３０１およびＲＳＶＰ管理部３０２に対応するプログラムと、回線情報等のデータが格納され、ルータ内のプロセッサがメモリを利用してプログラムを実行することにより、経路管理部３０１およびＲＳＶＰ管理部３０２の処理を行う。
ＲＳＶＰ管理部３０２のプログラムは、Ｓｅｓｓｉｏｎ制御モジュール３１１、メッセージ制御モジュール３１２、ルーティング制御モジュール３１３、回線管理モジュール３１４、タイマ制御モジュール３１５、およびＨｅｌｌｏ制御モジュール３１６の各プログラムを含む。
これらのプログラムおよびデータは、通信ネットワークや可搬記録媒体を介してユーザに提供され、情報処理装置を介してルータ内のメモリにロードされる。このとき、提供者の情報処理装置は、プログラムおよびデータを搬送する搬送信号を生成し、通信ネットワーク上の伝送媒体を介してユーザの情報処理装置に送信する。可搬記録媒体としては、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体が用いられる。
次に、図４から図８までを参照しながら、図２８のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で回線障害が発生した場合の動作を説明する。
図４に示すように、Ｈｅａｄ Ｅｎｄ、Ｔａｉｌ Ｅｎｄ、Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、Ｃｏｒｅ＃Ｄ、Ｃｏｒｅ＃Ｅ、およびＣｏｒｅ＃Ｆのネットワークアドレスを、それぞれ、Ｘ．Ｘ．Ｘ．Ｘ、Ｙ．Ｙ．Ｙ．Ｙ、Ａ．Ａ．Ａ．Ａ、Ｂ．Ｂ．Ｂ．Ｂ、Ｃ．Ｃ．Ｃ．Ｃ、Ｄ．Ｄ．Ｄ．Ｄ、Ｅ．Ｅ．Ｅ．Ｅ、およびＦ．Ｆ．Ｆ．Ｆとする。また、Ｈｅａｄ Ｅｎｄ−Ｔａｉｌ Ｅｎｄ間の現用トンネルとしてトンネル１およびトンネル２が確立されており、予備トンネルとしてトンネル３およびトンネル４が確立されているものとする。
回線管理モジュール３１４が回線情報として管理するデータは、Ｈｅａｄ Ｅｎｄとそれ以外のノードとで保持するデータが異なる。図５は、Ｈｅａｄ Ｅｎｄに保持される回線情報の例を示している。この回線情報には、トンネルが通過するすべての回線の情報が含まれる。回線識別情報は、回線を一意に識別するための情報であり、回線が接続している２つのノードのネットワークアドレスを含む。回線状態は、回線が正常か異常かを表し、配下トンネルは、回線を通過するすべてのトンネルの識別情報を含む。
Ｈｅａｄ Ｅｎｄは、Ｃｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間の障害を認識した時点で、“Ｂ．Ｂ．Ｂ．Ｂ−Ｃ．Ｃ．Ｃ．Ｃ”の回線の回線状態を“正常”から“異常”に更新する。
一方、Ｈｅａｄ Ｅｎｄ以外のノード（Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、Ｃｏｒｅ＃Ｄ、Ｃｏｒｅ＃Ｅ、Ｃｏｒｅ＃Ｆ、Ｔａｉｌ Ｅｎｄ）には、図６に示すような回線情報が保持される。この回線情報は“異常”のみの管理を行うために用いられ、回線障害が発生した時に発生した数だけのデータが作成される。したがって、例えば、新たにＣｏｒｅ＃Ｃ−Ｃｏｒｅ＃Ｄ間で障害が発生した場合は、Ｈｅａｄ Ｅｎｄの回線情報は図７のようになり、それ以外のノードの回線情報は図８のようになる。
回線障害が復旧したとき、Ｈｅａｄ Ｅｎｄが保持するデータは“異常”から“正常”に更新される。また、それ以外のノードが保持するデータは削除される。したがって、障害が発生していない定常時には、Ｈｅａｄ Ｅｎｄ以外のノードは、図６および８に示すようなデータを保持していない。
また、図５〜８に示した回線情報を用いずに、従来技術でトンネルを確立しているときに保持しているトンネル情報内の回線情報を用いて、回線状態を管理してもよい。従来からこの回線状態の正常／異常を管理している場合は、受信したＨｅｌｌｏメッセージを元に回線状態の正常／異常を更新する。回線状態の正常／異常を管理していない場合は、正常／異常を示すフィールドを回線情報に追加すればよい。
次に、図９から図１４までを参照しながら、障害通知に用いられるＨｅｌｌｏメッセージについて説明する。
図９および１０は、それぞれ、ＲＦＣ３２０９で規定されているＲＳＶＰ ＨｅｌｌｏメッセージおよびＲＳＶＰ ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのフォーマットを示している。図９のＲＳＶＰ Ｈｅｌｌｏメッセージに含まれるＣｏｍｍｏｎ Ｈｅａｄｅｒは、図１１に示すようなフォーマットを有する。
本実施形態では、定常時は図９のフォーマットでＨｅｌｌｏメッセージを送信するが、回線障害発生時には、図９と図１０を組み合わせたフォーマットでＨｅｌｌｏメッセージを送信する。後者のＨｅｌｌｏメッセージのフォーマットは、図１２のようになる。
図４のネットワーク構成においてネットワークアドレスＢ．Ｂ．Ｂ．Ｂ（Ｃｏｒｅ＃Ｂ）とＣ．Ｃ．Ｃ．Ｃ（Ｃｏｒｅ＃Ｃ）間において回線障害が発生した場合、障害を検出したノード（Ｃｏｒｅ＃ＢとＣｏｒｅ＃Ｃ）は、回線障害が発生したネットワークアドレスを図１０のＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのＩＰｖ４Ａｄｄｒｅｓｓに書き込み、図１２のフォーマットにて隣接ノードにＨｅｌｌｏメッセージを送信する。図１２のその他のデータメンバには従来と同様のデータが設定される。
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトは、図１３に示すように、従来技術ではＲＳＶＰのＰａｔｈ／Ｒｅｓｖメッセージが転送されたルートを記録する機能として用いられる。Ｈｅａｄ Ｅｎｄルータ１１は、常時ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＰａｔｈメッセージを送信する。
Ｃｏｒｅルータ１２、１３は、受信したＰａｔｈ／ＲｅｓｖメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されている場合にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＰａｔｈ／Ｒｅｓｖメッセージを送信する。Ｔａｉｌ Ｅｎｄルータ１４は、受信したＰａｔｈメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されている場合にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＲｅｓｖメッセージを送信する。
本実施形態では、図１４に示すように、このＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトをＲＳＶＰ Ｈｅｌｌｏメッセージにも適用する。回線障害を検出したノードは、障害検出時にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。それ以降は、通常通り周期起動にて、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。この動作は、障害が復旧するまで継続する。
この例では、ネットワークアドレス“Ｂ．Ｂ．Ｂ．Ｂ”および“Ｃ．Ｃ．Ｃ．Ｃ”が書き込まれたＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを有するＨｅｌｌｏメッセージが送信されている。
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されたＨｅｌｌｏメッセージを受信したノードは、第１回目の受信時には、イベント駆動にて同様にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを設定して隣接ノードにＨｅｌｌｏメッセージを送信する。２回目以降は、通常通り周期起動にて、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。この動作は、障害が復旧するまで継続する。
次に、本発明の障害通知機能を具備していないノードがネットワーク内に存在する場合の処理について説明する。
この場合、障害が認識されない問題を回避するために、ＲＳＶＰ−ＴＥメッセージのＣｏｍｍｏｎ Ｈｅａｄｅｒに含まれるＦｌａｇｓを使用する。Ｆｌａｇｓは、ＲＦＣ３２０９にて未使用と定義されている。そこで、本発明の障害通知を適用するノードは、Ｆｌａｇｓに常時本発明が適用されていることを示すユニークな値（例えば、“３”等）を設定してメッセージを送信する。これにより、本発明が適用されていないノードからは、Ｆｌａｇｓにユニークな値が設定されずに（通常は“０”が設定されて）メッセージが送信されてくるため、本発明の適用可否を判断することが可能である。
次に、図１５から図１９までを参照しながら、障害発生時および復旧時の動作についてより詳細に説明する。
図１５は、障害検出時のノード内処理シーケンスを示している。図４のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で回線障害が発生した場合、Ｃｏｒｅ＃ＢおよびＣｏｒｅ＃Ｃのルーティング制御モジュール３１３は、障害を検出し（ステップ１５０１）、Ｈｅｌｌｏ制御モジュール３１６に障害発生を通知する。
Ｈｅｌｌｏ制御モジュール３１６は、図６のような障害情報データを作成して回線管理モジュール３１４に転送し（ステップ１５０２）、回線管理モジュール３１４は、転送された障害情報データを回線情報としてメモリに格納する。
次に、Ｈｅｌｌｏ制御モジュール３１６は、回線管理モジュール３１４に対して障害情報があるか否かを問い合わせる（ステップ１５０３）。回線管理モジュール３１４は、図６の障害情報データがある場合は、その内容をＨｅｌｌｏ制御モジュール３１６に通知し、障害情報データがない場合は、その旨をＨｅｌｌｏ制御モジュール３１６に通知する。
Ｈｅｌｌｏ制御モジュール３１６は、図６の障害情報データを受け取った場合は、図１０のＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのＩＰｖ４Ａｄｄｒｅｓｓに回線障害が発生したネットワークアドレスを書き込む。そして、Ｓｅｓｓｉｏｎ制御モジュール３１１を介して、図１２のフォーマットにてＨｅｌｌｏメッセージを隣接ノード（Ｃｏｒｅ＃ＡまたはＣｏｒｅ＃Ｄ）に送信する。この場合、Ｈｅｌｌｏメッセージは、周期起動ではなくイベント駆動で送信される。
障害情報データがない場合は、Ｓｅｓｓｉｏｎ制御モジュール３１１を介して、図９のフォーマットにてＨｅｌｌｏメッセージを隣接ノードに送信する。
イベント駆動でＨｅｌｌｏメッセージを送信した後、Ｈｅｌｌｏ制御モジュール３１６は、タイマ制御モジュール３１５により一定周期で起動され、ステップ１５０３と同様の処理を繰り返す（ステップ１５０３）。そして、別回線の障害検出あるいは障害回線の復旧検出がない限り、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。
Ｈｅａｄ Ｅｎｄにおいて回線障害が検出された場合は、ステップ１５０２において、回線管理モジュール３１４は、転送された障害情報データを元に、メモリ内に保持された図５のような回線情報を正常から異常に更新する。
図１６は、障害発生を通知するＨｅｌｌｏメッセージを受信したときのノード内処理シーケンスを示している。Ｓｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏメッセージ受信をＨｅｌｌｏ制御モジュール３１６に通知し、Ｈｅｌｌｏ制御モジュール３１６は、受信したＨｅｌｌｏメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されているか否かをチェックする（ステップ１６０１）。
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されている場合は、障害発生を認識して、そのオブジェクトを元に障害情報データを作成して回線管理モジュール３１４に転送し（ステップ１６０２）、回線管理モジュール３１４は、転送された障害情報データを回線情報としてメモリに格納する。このとき、受信ノードがＨｅａｄ Ｅｎｄであれば、図５のような回線情報が正常から異常に更新され、それ以外のノードであれば、図６のような回線情報が作成される。
次に、Ｈｅｌｌｏ制御モジュール３１６は、図１５のステップ１５０３および１５０４と同様の処理を行って、別回線の障害検出あるいは障害回線の復旧検出がない限り、同様のＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する（ステップ１６０３および１６０４）。
前述したように、従来技術では、回線障害が発生している場合でも、トンネル切断後に該当トンネルの再確立を行っている。例えば、Ｅｘｐｌｉｃｉｔで定義されているトンネルについては、図４のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で回線障害が発生している場合に、Ｈｅａｄ Ｅｎｄでは、Ｃｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間の障害が発生していることをプロトコル動作上認識できないためである。本実施形態では、Ｈｅａｄ Ｅｎｄ内に保持された回線情報を利用して、この問題を回避する。
図１７は、図２の障害通知シーケンスにおいて、トンネルの再確立を抑止する処理を示している。Ｈｅａｄ Ｅｎｄのタイマ制御モジュール３１５は、Ｓｅｓｓｉｏｎ制御モジュール３１１によるトンネル確立処理を一定周期で起動し、Ｓｅｓｓｉｏｎ制御モジュール３１１は、回線管理モジュール３１４に対して、該当トンネルが通過する回線の状態を問い合わせる。回線管理モジュール３１４は、回線情報を参照して、該当回線の回線状態をＳｅｓｓｉｏｎ制御モジュール３１１に通知する。
Ｓｅｓｓｉｏｎ制御モジュール３１１は、受け取った回線状態をチェックし（ステップ１７０１）、異常であれば、トンネル確立要求を送信せずに、回線状態の問い合わせを繰り返す。そして、回線状態が正常になれば、障害復旧を認識して、下流ノードへトンネル確立要求を送信する（ステップ１７０２）。
図１８は、復旧検出時のノード内処理シーケンスを示している。図４のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で発生していた回線障害が復旧した場合、Ｃｏｒｅ＃ＢおよびＣｏｒｅ＃Ｃのルーティング制御モジュール３１３は、復旧を検出し（ステップ１８０１）、Ｈｅｌｌｏ制御モジュール３１６に障害復旧を通知する。Ｈｅｌｌｏ制御モジュール３１６は、回線管理モジュール３１４を介して図６の障害情報データを削除する（ステップ１８０２）。
次に、Ｈｅｌｌｏ制御モジュール３１６は、図１５のステップ１５０３および１５０４と同様の処理を行って、Ｈｅｌｌｏメッセージを送信する。この場合、障害情報データがなくなったので、図１２のＨｅｌｌｏメッセージからＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを削除して、図９のフォーマットにてＨｅｌｌｏメッセージを隣接ノードに送信する（ステップ１８０３）。その後、新たな回線障害や復旧の検出がない限り、Ｈｅｌｌｏメッセージを一定周期で送信する（ステップ１８０４）。
Ｈｅａｄ Ｅｎｄにおいて復旧が検出された場合は、ステップ１８０２において、回線管理モジュール３１４を介して図５の回線情報が異常から正常に更新される。
図１９は、障害復旧を通知するＨｅｌｌｏメッセージを受信したときのノード内処理シーケンスを示している。Ｓｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏメッセージ受信をＨｅｌｌｏ制御モジュール３１６に通知し、Ｈｅｌｌｏ制御モジュール３１６は、受信したＨｅｌｌｏメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されているか否かをチェックする（ステップ１９０１）。
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されていない場合は、障害復旧を認識して、回線管理モジュール３１４を介して回線情報を変更する（ステップ１９０２）。このとき、受信ノードがＨｅａｄ Ｅｎｄであれば、図５のような回線情報が異常から正常に更新され、それ以外のノードであれば、図６のような該当回線の回線情報が削除される。
次に、Ｈｅｌｌｏ制御モジュール３１６は、図１５のステップ１５０３および１５０４と同様の処理を行って、新たな回線障害や復旧の検出がない限り、同様のＨｅｌｌｏメッセージを送信する（ステップ１９０３および１９０４）。
このような障害／復旧検出時の動作は高速トンネル障害切り替え方法であるＦａｓｔ Ｒｅｒｏｕｔｅにも適用可能である。その場合は、上述したＨｅａｄ Ｅｎｄが行う処理をすべてＦａｓｔ Ｒｅｒｏｕｔｅの現用系と予備系の開始点が一致するノードが実施する。したがって、図４のネットワーク構成の場合は、Ｃｏｒｅ＃Ａが図５のような回線情報を保持する。これにより、Ｃｏｒｅ＃ＡがＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間の回線障害を認識して、現用トンネルから予備トンネルに切り替えを行うことができる。
次に、図２０から図２４までを参照しながら、本発明の障害通知機能を具備していないノードがネットワーク内に存在する場合の処理について、より詳細に説明する。
図２０に示すようなネットワーク構成において、ネットワーク上に存在する３つのルータのうち、ルータ＃Ａおよび＃Ｃが本発明の障害通知機能を具備し、ルータ＃Ｂがこの機能を具備していないものとする。
図２１は、これらのルータ間の接続方法を示している。各ルータは複数のスロットを具備し、各スロットは複数の回線位置を有する。ネットワークを構成する際には、一方のルータの１つの回線位置と他方のルータの１つの回線位置がケーブル２１０１〜２１０３で物理的に接続される。
各ルータは、公知の技術により、自ルータから隣接ルータに向けてケーブルが接続されている回線位置を特定することが可能である。例えば、ルータ＃Ａにおいて、ルータ＃Ｃ向けにケーブル２１０１が接続されている回線位置は、（ｓｌｏｔ１，回線２）と認識しており、ルータ＃Ｂ向けにケーブル２１０３が接続されている回線位置は、（ｓｌｏｔ３，回線０）と認識している。ルータ＃Ｂおよび＃Ｃにおいても、同様にして回線位置を認識している。
この場合、ルータ＃Ａおよび＃Ｃは、それぞれ図２２および図２３に示すような管理データをメモリ内に保持する。これらの管理データにおいて、“ＯＮ”は、回線が本発明の障害通知機能を具備していることを表し、“ＯＦＦ”は、回線がその機能を具備していないことを表す。ルータ＃Ａおよび＃Ｃは、隣接ノードからのメッセージ受信時に、図１１のＣｏｍｍｏｎ Ｈｅａｄｅｒ内のＦｌａｇｓの値を分析して、管理データの値を更新する。
図２４は、このようなメッセージ受信時のフラグ分析シーケンスを示している。本発明の障害通知機能を具備するノードのＳｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏメッセージ送信前、つまりトンネル確立を実施する際に送信されるＰａｔｈメッセージ、Ｒｅｓｖメッセージ等の一連のメッセージを受信したとき、各メッセージのＣｏｍｍｏｎ Ｈｅａｄｅｒ内のＦｌａｇｓに含まれている値をチェックし（ステップ２４０１）、その値を所定値と比較する（ステップ２４０２）。
Ｆｌａｇｓの値が所定値であれば、発明動作が可能であることをＨｅｌｌｏ制御モジュール３１６に通知する。これにより、Ｈｅｌｌｏ制御モジュール３１６は、隣接ノードが本発明の障害通知機能を具備していると判断し、回線管理モジュール３１４を介して、メモリ内の管理データの該当回線の状態を“ＯＦＦ”から“ＯＮ”に更新する（ステップ２４０３）。これ以降、該当回線については、図１５〜１９に示した本発明の動作が行われる。
また、Ｆｌａｇｓの値が所定値でなければ、Ｓｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏ制御モジュール３１６に何も通知しない。この場合、管理データの該当回線の状態は“ＯＦＦ”のままとなり、その回線については従来通りの動作が行われる。
（付記１） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
前記通信ネットワーク内の回線上における障害の発生を検出する検出手段と、
前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する通知手段と
を備えることを特徴とするトンネル障害通知装置。
（付記２） 前記障害が発生した回線の回線情報を格納する格納手段をさらに備え、前記通知手段は、該回線情報が異常を示すとき、該障害の発生を前記隣接ノードに通知することを特徴とする付記１記載のトンネル障害通知装置。
（付記３） 前記格納手段は、前記隣接ノードが回線単位での障害通知機能を具備するか否かを示す管理データをさらに格納し、前記通知手段は、該隣接ノードが該障害通知機能を具備するとき、該障害の発生を回線単位で該隣接ノードに通知し、該隣接ノードが該障害通知機能を具備しないとき、前記複数のトンネルの切断メッセージをトンネル単位で該隣接ノードに通知することを特徴とする付記２記載のトンネル障害通知装置。
（付記４） 前記検出手段は、前記回線上における前記障害の復旧を検出し、前記通知手段は、該障害が復旧した回線を通過する複数のトンネルの復旧メッセージを集約して、該障害の復旧を回線単位で前記隣接ノードに通知することを特徴とする付記１または２記載のトンネル障害通知装置。
（付記５） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する通知手段と
を備えることを特徴とするトンネル障害通知装置。
（付記６） 前記障害が発生した回線の回線情報を格納する格納手段をさらに備え、前記通知手段は、該回線情報が異常を示すとき、該障害の発生を前記第２の隣接ノードに通知することを特徴とする付記５記載のトンネル障害通知装置。
（付記７） 前記格納手段は、前記第２の隣接ノードが回線単位での障害通知機能を具備するか否かを示す管理データをさらに格納し、前記通知手段は、該第２の隣接ノードが該障害通知機能を具備するとき、該障害の発生を回線単位で該第２の隣接ノードに通知し、該第２の隣接ノードが該障害通知機能を具備しないとき、前記複数のトンネルの切断メッセージをトンネル単位で該第２の隣接ノードに通知することを特徴とする付記６記載のトンネル障害通知装置。
（付記８） 前記受信手段は、前記回線上で前記障害が復旧したとき、該障害が復旧した回線を通過する複数のトンネルの復旧メッセージを集約して該障害の復旧を回線単位で通知する復旧通知を、前記第１の隣接ノードから受信し、前記通知手段は、受信した復旧通知に基づいて、該障害の復旧を回線単位で前記第２の隣接ノードに通知することを特徴とする付記５または６記載のトンネル障害通知装置。
（付記９） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うトンネル障害処理装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる制御手段と
を備えることを特徴とするトンネル障害処理装置。
（付記１０） 前記通信ネットワーク内の複数の回線の回線情報を格納する格納手段と、前記障害通知を受信したとき、前記障害が発生した回線の回線情報を正常から異常に変更する回線管理手段とをさらに備え、前記制御手段は、該障害が発生した回線の回線情報が異常に変更されたとき、前記複数のトンネルの切断処理を行うことを特徴とする付記９記載のトンネル障害通知装置。
（付記１１） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うトンネル障害処理装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う制御手段と
を備えることを特徴とするトンネル障害処理装置。
（付記１２） 前記通信ネットワーク内の複数の回線の回線情報を格納する格納手段と、前記障害通知を受信したとき、前記障害が発生した回線の回線情報を正常から異常に変更する回線管理手段とをさらに備え、前記制御手段は、該障害が発生した回線の回線情報が異常に変更されたとき、前記現用トンネルから予備トンネルへの切り替え処理を行うことを特徴とする付記１１記載のトンネル障害通知装置。
（付記１３） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知方法であって、
検出手段が、前記通信ネットワーク内の回線上における障害の発生を検出し、
通知手段が、前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する
ことを特徴とするトンネル障害通知方法。
（付記１４） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知方法であって、
受信手段が、前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信し、
通知手段が、受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する
ことを特徴とするトンネル障害通知方法。
（付記１５） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うトンネル障害処理方法であって、
受信手段が、前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
制御手段が、受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる
ことを特徴とするトンネル障害処理方法。
（付記１６） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うトンネル障害処理方法であって、
受信手段が、前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
制御手段が、受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う
ことを特徴とするトンネル障害処理方法。
（付記１７） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上における障害の発生を検出し、
前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する
処理を前記プロセッサに実行させることを特徴とするプログラム。
（付記１８） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信し、
受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する
処理を前記プロセッサに実行させることを特徴とするプログラム。
（付記１９） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる
処理を前記プロセッサに実行させることを特徴とするプログラム。
（付記２０） トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う
処理を前記プロセッサに実行させることを特徴とするプログラム。
本発明のトンネル障害通知装置およびトンネル障害処理装置の原理図である。 本発明の障害通知シーケンスを示す図である。 ルータのモジュール構成を示す図である。 ネットワークアドレスを示す図である。 第１の回線情報を示す図である。 第２の回線情報を示す図である。 第３の回線情報を示す図である。 第４の回線情報を示す図である。 第１のＨｅｌｌｏメッセージのフォーマットを示す図である。 ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのフォーマットを示す図である。 Ｃｏｍｍｏｎ Ｈｅａｄｅｒのフォーマットを示す図である。 第２のＨｅｌｌｏメッセージのフォーマットを示す図である。 Ｐａｔｈメッセージの送信を示す図である。 ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを含むＨｅｌｌｏメッセージの送信を示す図である。 障害検出時の処理シーケンスを示す図である。 第１のＨｅｌｌｏメッセージ受信時の処理シーケンスを示す図である。 トンネルの再確立を抑止する処理シーケンスを示す図である。 復旧検出時の処理シーケンスを示す図である。 第２のＨｅｌｌｏメッセージ受信時の処理シーケンスを示す図である。 ２種類のルータからなるネットワーク構成を示す図である。 ルータ間の接続方法を示す図である。 第１の管理データを示す図である。 第２の管理データを示す図である。 フラグ分析シーケンスを示す図である。 第１のネットワーク構成を示す図である。 トンネル構成を示す図である。 従来の障害通知シーケンスを示す図である。 第２のネットワーク構成を示す図である。 従来のＨｅｌｌｏメッセージのシーケンスを示す図である。
符号の説明
１１、１２、１３、１４、４１、４２、４３、４４、４５、４６、４７、４８ ルータ
２１、２２、２３ 回線
１０１ 検出手段
１０２、１１２ 通知手段
１０３、１１３、１２３ 格納手段
１１１、１２１ 受信手段
１２２ 制御手段
１２４ 回線管理手段
３０１ 経路管理部
３０２ ＲＳＶＰ管理部
３１１ Ｓｅｓｓｉｏｎ制御モジュール
３１２ メッセージ制御モジュール
３１３ ルーティング制御モジュール
３１４ 回線管理モジュール
３１５ タイマ制御モジュール
３１６ Ｈｅｌｌｏ制御モジュール
２１０１、２１０２、２１０３ ケーブル

Claims (4)

  1. トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
    前記通信ネットワーク内の回線上における障害の発生を検出する検出手段と、
    前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する通知手段と
    を備えることを特徴とするトンネル障害通知装置。
  2. トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
    前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信する受信手段と、
    受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する通知手段と
    を備えることを特徴とするトンネル障害通知装置。
  3. トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うトンネル障害処理装置であって、
    前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
    受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる制御手段と
    を備えることを特徴とするトンネル障害処理装置。
  4. トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うトンネル障害処理装置であって、
    前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
    受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う制御手段と
    を備えることを特徴とするトンネル障害処理装置。
JP2004205595A 2004-07-13 2004-07-13 トンネル障害通知装置および方法 Withdrawn JP2006033124A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004205595A JP2006033124A (ja) 2004-07-13 2004-07-13 トンネル障害通知装置および方法
US11/010,900 US20060013126A1 (en) 2004-07-13 2004-12-13 Tunnel failure notification apparatus and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004205595A JP2006033124A (ja) 2004-07-13 2004-07-13 トンネル障害通知装置および方法

Publications (1)

Publication Number Publication Date
JP2006033124A true JP2006033124A (ja) 2006-02-02

Family

ID=35599281

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004205595A Withdrawn JP2006033124A (ja) 2004-07-13 2004-07-13 トンネル障害通知装置および方法

Country Status (2)

Country Link
US (1) US20060013126A1 (ja)
JP (1) JP2006033124A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008038390A1 (fr) * 2006-09-28 2008-04-03 Fujitsu Limited système de communication IP mobile
US8971174B2 (en) 2012-03-19 2015-03-03 Fujitsu Limited Restart method and node device

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101265954B1 (ko) * 2005-07-11 2013-05-23 더 트러스티이스 오브 콜롬비아 유니버시티 인 더 시티 오브 뉴욕 아이피 터널링 경로 상의 터널 시그널링을 수행하는 방법및 장치
EP1746762B1 (en) * 2005-07-22 2008-08-27 Alcatel Lucent Recovery of network element configuration
JP4947430B2 (ja) * 2005-08-18 2012-06-06 日本電気株式会社 無線マルチホップネットワークにおける通信経路制御方法および通信端末
US8072879B2 (en) * 2006-02-03 2011-12-06 Cisco Technology, Inc. Technique for determining whether to reestablish fast rerouted primary tunnels based on backup tunnel path quality feedback
CN101087221B (zh) * 2006-06-07 2010-12-08 华为技术有限公司 资源预留协议节点及其交互方法
US7907603B2 (en) * 2007-04-26 2011-03-15 Cisco Technology, Inc. Acceleration of label distribution protocol (LDP) session setup
US8472325B2 (en) * 2007-05-10 2013-06-25 Futurewei Technologies, Inc. Network availability enhancement technique for packet transport networks
US8400912B2 (en) * 2007-06-27 2013-03-19 World Wide Packets, Inc. Activating a tunnel upon receiving a control packet
US8339942B2 (en) * 2009-10-15 2012-12-25 Telefonaktiebolaget L M Ericsson (Publ) RSVP-TE graceful restart under fast re-route conditions
KR101829832B1 (ko) * 2010-03-26 2018-02-19 엘지전자 주식회사 무선 통신 시스템에서 신호 송수신 방법 및 이를 위한 장치
WO2013025311A1 (en) * 2011-08-12 2013-02-21 Rambus Inc. Temporal redundancy
JP5851020B2 (ja) * 2012-03-05 2016-02-03 富士通株式会社 通信システム、及び通信方法
CN102904816B (zh) * 2012-09-26 2017-04-12 华为技术有限公司 业务流量保护方法和装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR0164106B1 (ko) * 1995-12-26 1998-12-01 양승택 에이티엠 가상 경로 교환 시스템에서 예약형 가상 경로 제어를 위한 발신 및 착신 처리 방법
US6614781B1 (en) * 1998-11-20 2003-09-02 Level 3 Communications, Inc. Voice over data telecommunications network architecture
US20020059432A1 (en) * 2000-10-26 2002-05-16 Shigeto Masuda Integrated service network system
CA2327898A1 (en) * 2000-12-08 2002-06-08 Alcatel Canada Inc. System and method for establishing a communication path associated with an mpls implementation on an atm platform
US7085224B1 (en) * 2001-06-14 2006-08-01 Cisco Technology, Inc. Method and apparatus for fast failure detection in switched LAN networks
US7020464B2 (en) * 2001-10-09 2006-03-28 Microsoft Corporation System and method for providing agent-free and no-packet overhead mobility support with transparent session continuity for mobile devices
US6788658B1 (en) * 2002-01-11 2004-09-07 Airflow Networks Wireless communication system architecture having split MAC layer
US7080151B1 (en) * 2002-04-01 2006-07-18 Utstarcom, Inc. Method and system for mobile IP home agent redundancy by using home agent control nodes for managing multiple home agents
JP2003298633A (ja) * 2002-04-05 2003-10-17 Fujitsu Ltd 制御チャネル障害時のデータチャネル障害通知機能を有する伝送装置
US7398321B2 (en) * 2002-05-14 2008-07-08 The Research Foundation Of Suny Segment protection scheme for a network
US20040006640A1 (en) * 2002-07-03 2004-01-08 Inderieden Daniel W. Notification to routing protocols of changes to routing information base
US7197008B1 (en) * 2002-07-05 2007-03-27 Atrica Israel Ltd. End-to-end notification of local protection using OAM protocol
US20040107382A1 (en) * 2002-07-23 2004-06-03 Att Corp. Method for network layer restoration using spare interfaces connected to a reconfigurable transport network
WO2004066564A1 (en) * 2003-01-23 2004-08-05 Research In Motion Limited Methods and apparatus for re-establishing communication for a wireless communication device after a communication loss in a wireless communication network
US8619757B2 (en) * 2003-05-01 2013-12-31 Interdigital Technology Corporation Method and apparatus for delivery of data-based/voice services over piconets and wireless LANs (WLANs) coupled to 3GPP devices including protocol architecture and information elements relating to short message services (SMS) over WLANs
US7539131B2 (en) * 2003-11-26 2009-05-26 Redback Networks Inc. Nexthop fast rerouter for IP and MPLS
US7031262B2 (en) * 2004-05-19 2006-04-18 Cisco Technology, Inc. Reoptimization triggering by path computation elements
JP4460358B2 (ja) * 2004-05-19 2010-05-12 Ｋｄｄｉ株式会社 障害救済処理方法およびプログラム
US7746793B2 (en) * 2004-06-18 2010-06-29 Cisco Technology, Inc. Consistency between MPLS forwarding and control planes
JP4758259B2 (ja) * 2006-01-31 2011-08-24 株式会社クラウド・スコープ・テクノロジーズ ネットワーク監視装置及び方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008038390A1 (fr) * 2006-09-28 2008-04-03 Fujitsu Limited système de communication IP mobile
JPWO2008038390A1 (ja) * 2006-09-28 2010-01-28 富士通株式会社 モバイルｉｐ通信システム
JP4681653B2 (ja) * 2006-09-28 2011-05-11 富士通株式会社 モバイルｉｐ通信システム
US8189510B2 (en) 2006-09-28 2012-05-29 Fujitsu Limited Mobile IP communication system
US8971174B2 (en) 2012-03-19 2015-03-03 Fujitsu Limited Restart method and node device

Also Published As

Publication number Publication date
US20060013126A1 (en) 2006-01-19

Similar Documents

Publication Publication Date Title
CN101427501B (zh) 确保mpls转发和控制平面之间一致性的方法和设备
EP2224644B1 (en) A protection method, system and device in the packet transport network
EP1111860B1 (en) Automatic protection switching using link-level redundancy supporting multi-protocol label switching
EP2658182B1 (en) Ring network protection method, network node and ring network
KR101468763B1 (ko) Ｍｐｌｓ―ｆｒｒ 대역폭 최적화를 위한 ｒｓｖｐ―ｔｅ 강화
KR101750844B1 (ko) 링형 네트워크 보호에 있어서 레이블을 자동적으로 분배하는 방법 및 시스템
CN101369958A (zh) 一种快速重路由方法及标签交换路由器
WO2008046358A1 (fr) Procédé et dispositif destinés à réaliser une pénétration d'un statut de liaison de réseau point à multipoint
JP2006033124A (ja) トンネル障害通知装置および方法
WO2012037820A1 (zh) 多协议标签交换***、节点设备及双向隧道的建立方法
US8934335B2 (en) System and method for enhancing loop free alternative coverage
CN101465859A (zh) 一种触发主备用接口板倒换的方法及装置
EP3029883B1 (en) Network protection method and apparatus, next-ring node, and system
JP2004523979A (ja) リング・トポロジーに対する選択的保護
EP2254289B1 (en) Method, device, and system for establishing label switching path in fast rerouting switching
EP2658177B1 (en) Method for detecting tunnel faults and traffic engineering node
Papán et al. Overview of IP fast reroute solutions
CN101299722B (zh) 一种改进的快速重路由方法和一种网络设备
CN101374106A (zh) 一种mpls lsp上转发数据包的方法、网络节点和***
US8223629B2 (en) Core router capable of securing the output router of an autonomous system
KR20150002474A (ko) 통신 네트워크에서 장애 복구 방법
WO2021143524A1 (zh) 一种故障检测方法及设备
CN101902396A (zh) 一种多协议标签交换流量工程中隧道保护的方法和***
US10715420B2 (en) System, method and apparatus for implementing fast reroute (FRR)
Kim et al. Protection switching methods for point‐to‐multipoint connections in packet transport networks

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070608

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20090114