Nothing Special   »   [go: up one dir, main page]

JP4691372B2 - データ中継装置およびデータ中継方法 - Google Patents

データ中継装置およびデータ中継方法 Download PDF

Info

Publication number
JP4691372B2
JP4691372B2 JP2005065835A JP2005065835A JP4691372B2 JP 4691372 B2 JP4691372 B2 JP 4691372B2 JP 2005065835 A JP2005065835 A JP 2005065835A JP 2005065835 A JP2005065835 A JP 2005065835A JP 4691372 B2 JP4691372 B2 JP 4691372B2
Authority
JP
Japan
Prior art keywords
path
working
route
failure
node
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
Application number
JP2005065835A
Other languages
English (en)
Other versions
JP2006253927A (ja
Inventor
慎也 加納
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 JP2005065835A priority Critical patent/JP4691372B2/ja
Priority to US11/166,804 priority patent/US7710860B2/en
Publication of JP2006253927A publication Critical patent/JP2006253927A/ja
Application granted granted Critical
Publication of JP4691372B2 publication Critical patent/JP4691372B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • 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
    • 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/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • 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
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • 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/62—Wavelength based

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Description

この発明は、複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継装置およびデータ中継方法に関し、特に、監視用経路など障害の復旧に用いる経路一つが対応できる現用経路の数を増加させ、もって障害の復旧に用いる経路数を削減することができるデータ中継装置およびデータ中継方法に関するものである。
ＧＭＰＬＳ(Generalized ＭＰＬＳ)／ＭＰＬＳ(Multi Protocol Label Switching)は、ラベル情報に従ってデータ転送を行う技術である。ここで、ラベル情報としては、パケットの先頭に添付された固定長ラベル、時間分割伝送のタイムスロット、光多重伝送における光波長などが該当する。特に、パケットの先頭に添付された固定長ラベルを用いて転送するネットワークをＭＰＬＳ網と呼ぶ。なお、ＧＭＰＬＳ網では、ＭＰＬＳ網で使用される固定長ラベルも含めいずれか、もしくはいくつかのラベル情報が用いられる。
例えば、固定長ラベルを用いるパケット転送では、中継ノード(ＬＳＲ: Label Switched Router)は、入力ラベル＆入力ＩＦ（インタフェース）に対する出力ラベル＆出力ＩＦの関係を示すラベルテーブルを保持する。そして、パケット中継時に、アドレスではなく、受信したパケットに添付されているラベルに従って出力ＩＦを決定し、パケットに添付されているラベルを出力ラベルに書き換え中継する。これを繰り返すことにより、宛先までパケットを送信する。なお、ＭＰＬＳ網の入口の中継ノード(始点ノード)が最初にラベルを添付する。ＭＰＬＳは、このような高速パケット中継技術である。
図３４は、固定長ラベルを用いたパケット転送を説明するための説明図である。同図は、「ＬＳＲ１」から「ＬＳＲ４」へパケットを転送する例を示す。まず、「ＬＳＲ１」は転送するパケットにラベルａを添付する。そして、「ＬＳＲ２」は、ラベルaを持つパケットを「ＩＦ＃１」から受信すると、ラベルテーブルを検索し、出力ＩＦ及び出力ラベルを獲得する。そして、パケットのラベルを出力ラベルに書き換えた後、パケットを出力ＩＦに出力する。ＭＰＬＳでは、このような処理を各ＬＳＲが繰り返すことによって、終端の「ＬＳＲ４」(終点ノード)までパケットを転送する。
このように、ＭＰＬＳは、固定長のラベルに従ってパケットを転送することにより、パケット中継の高速化を図ることができる。また、ＭＰＬＳは、中継ノードにおいて帯域制御と各ラベルを関連付けることにより、各パケットフローに対して帯域保証を行うことができる。
また、時分割伝送では、各ノードが入力タイムスロット＆入力ＩＦに対する出力タイムスロット＆出力ＩＦの関係を示すラベルテーブルを保持する。そして、各ノードは、受信ＩＦと受信タイムスロットに従って、出力ＩＦと出力タイムスロットを決定し、データを出力ＩＦの出力タイムスロットに出力する。これを繰り返すことにより、宛先までデータを送信する。
また、光多重伝送では、各ノードが入力光波長＆入力ＩＦに対する出力光波長＆出力ＩＦの関係を示すラベルテーブルを保持する。そして、各ノードは、受信ＩＦと受信光波長に従って、出力ＩＦと出力光波長を決定し、受信光波長を出力光波長に変換し、出力ＩＦに出力する。これを繰り返すことにより、宛先までデータを送信する。
ＧＭＰＬＳとは、上記のような、固定長ラベル、タイムスロット、光波長をラベルとして扱うことにより、同一の仕組みで転送を行う技術である。
ＧＭＰＬＳ／ＭＰＬＳでは、各ノードでラベルテーブルを構築する必要があり、ラベルテーブルの構築には、パス（経路）確立シグナリングプロトコル(CR-LDP/RSVP-TE等)が用いられる。以下ではRSVP-TEを例に取り、ラベルテーブルを構築することによるパス確立の動作を説明する。
図３５は、パス確立シグナリングプロトコル(RSVP-TE)の動作を説明するための説明図である。同図に示すように、パス確立を要求する始点ノードは、パスの終点ノードまでパス確立要求メッセージ(Pathメッセージ)をHop-by-Hopで送信する。なお、図３５では、明示的に経路を指定するため、Pathメッセージ中に経由する中継ノードの情報を挿入している。
Pathメッセージを受信した終点ノードは、ラベルの割り当てを行うパス確立応答メッセージ(Resvメッセージ)をPathメッセージが送られてきた経路に沿って始点ノードへ返信する。このとき、Resvメッセージに格納されているラベルをラベルテーブルに登録することにより、データを転送するためのラベルテーブルが構築される。Path/ResvメッセージともにパスＩＤが格納されており、ラベルテーブルにはパスＩＤも合わせて登録される。
パス確立シグナリングプロトコルには、パス確立要求を示すPathメッセージとその応答であるResvメッセージの他に、確立したパスにエラーが発生したことを通知するエラーメッセージとして、PathErr/ResvTear/Notifyメッセージが用いられる。
図３６は、PathErr/ResvTearメッセージを用いたエラーメッセージの転送を示す図である。同図に示すように、PathErr/ResvTearメッセージは、パスに沿ってHop-by-Hopで始点ノードまで転送される。一方、Notifyメッセージは、メッセージの宛先である始点ノードに直接転送される。そのため、Notifyメッセージは、パスと異なる経路によって始点ノードに到着する場合もある。なお、エラーメッセージにはPath/Resvメッセージに格納されていたパスＩＤと同じパスＩＤが格納され、エラーとパスの対応付けを行うことができる。
ＧＭＰＬＳ／ＭＰＬＳでは、データを転送する現用パスに障害が発生すると、現用パスを迂回する予備パスを用いてデータの転送が行われる。例えば、ＭＰＬＳでは、監視用パスを用いて現用パスを監視し、現用パスに障害が発生すると、予備パスに切り替える障害復旧方式が開発されている（特許文献１を参照。）。
図３７は、このような、監視用パスを用いた障害復旧方式を説明するための説明図である。同図に示すように、監視用パスを用いた障害復旧では、まず、パス確立シグナリングプロトコルを用いて、現用パスと、障害発生時に現用パス上のトラヒックを迂回させるための予備パスを確立する。このとき、予備パスは現用パスと同じ始点ノードと終点ノードの間で確立される。
さらに、現用パスの状態を監視するための監視用パスをパス確立シグナリングプロトコルを用いて確立する。監視用パスは、図３７に示すように、現用パスに沿って、下流方向／上流方向の両方に２本確立する。そして、２本の監視用パス上で監視パケットを定期的に往復させる。この監視パケットは、監視用パス上を送信されるため、ラベル付きのパケットとなる。
現用パス上で障害が発生すると、以下の手法のいずれかにより、始点ノード「ＬＳＲ１」は障害を検出する。一つ目の手法は、定期的に送受信されている監視パケットが一定時間内に到着しないことによる検出である。もう一つの手法は、その上流の中継ノードが障害を検出し、その中継ノードが障害通知パケットをラベル付きパケットで始点ノードへ転送する。
障害が発生したことを上記二つの手法のいずれかで認識した始点ノードは、現用パスへ送信していたトラヒックを予備パスへ送信することによって、障害を迂回させる。なお、図３７で示したように、監視用パスは、同一の経路で確立される複数の現用パスに対して一つを確立してもよい。これにより、監視用パスの総数を減らすことができる。
特開２００３−３３８８３１号公報
しかしながら、かかる従来技術には、同一の経路を持った複数パスにのみ予備パスが限定されるため、１監視用パスの数で対応できる現用パス数を増加させることができない。そのため、監視用パス数が増加するという問題がある。
さらに、一つの区間に対して２本の監視用パスを確立する必要があることも、監視用パス数を増加させる要因になる。その結果、ネットワークで管理する監視用パス数が増加し、管理負荷が増大するという問題がある。
また、定期的に監視パケットを送受信する必要があるため、通常時においても監視パケットが帯域を消費してしまう。また、障害通知用の通知パケットは、パスの入口ノードからでなく、中継ノードから挿入されるため、パスの中継部分からパケットを挿入する機能を新たに設ける必要がある。
この発明は、上述した従来技術による問題点を解消するためになされたものであり、監視用パスなどの障害の復旧に用いる経路一つが対応できる現用経路の数を増加させ、もって障害の復旧に用いる経路数を削減することができるデータ中継装置およびデータ中継方法を提供することを目的とする。
なお、障害復旧方式としては、この他に、シグナリングプロトコルのエラーメッセージを用いたパス迂回、IETFで検討されているFast ReRouting方式(Internet Draft: draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt)、障害情報の同報を用いたパス迂回（藤井泰希、宮崎啓二、伊勢田衡平、「プリプラン型障害復旧方式の検討」、信学技報TM2000-60、pp.67-72、Nov2000）などがある。
しかし、シグナリングプロトコルのエラーメッセージを用いたパス迂回には、複数パスに影響を及ぼす傷害が発生した場合、多数のエラーメッセージが発生し、ネットワーク負荷が増大するという問題があり、Fast ReRouting方式には、現用パスが通過するリンクの数だけ予備パス数を確立する必要があり、予備パス数が増加するという問題があり、障害情報の同報を用いたパス迂回には、同報パケットを用いるため、関係のないノードへのパケットが発生するという問題がある。
上述した課題を解決し、目的を達成するため、請求項１の発明に係るデータ中継装置は、複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継装置であって、始点となる予備経路について障害の監視専用に用いる監視用経路と現用経路と予備経路とを対応させた障害復旧情報を記憶した障害復旧情報記憶手段と、経路に発生した障害の通知である障害発生通知を監視用経路により受信する障害発生通知受信手段と、前記障害発生通知受信手段により障害発生通知が受信された監視用経路である障害発生監視用経路に対応する現用経路および予備経路を前記障害復旧情報を用いて検索する現用予備経路検索手段と、前記現用予備経路検索手段により現用経路および予備経路が検索された場合に、該現用経路を用いて転送されるデータが該予備経路を用いて転送されるように経路切替処理を行う経路切替処理手段と、を備えたことを特徴とする。
この請求項１の発明によれば、始点となる予備経路について障害の監視専用に用いる監視用経路と現用経路と予備経路とを対応させた障害復旧情報を記憶し、経路に発生した障害の通知である障害発生通知を監視用経路により受信し、障害発生通知を受信した監視用経路である障害発生監視用経路に対応する現用経路および予備経路を障害復旧情報を用いて検索し、現用経路および予備経路を検索した場合に、現用経路を用いて転送されるデータが予備経路を用いて転送されるように経路切替処理を行うよう構成したので、監視用経路一つが対応できる現用経路の数を増加させることができる。
また、請求項２の発明に係るデータ中継装置は、請求項１の発明において、前記監視用経路として、一部の区間が共通である複数の現用経路に対して共通である区間を含む一つの経路を設定することを特徴とする。
この請求項２の発明によれば、監視用経路として、一部の区間が共通である複数の現用経路に対して共通である区間を含む一つの経路を設定するよう構成したので、監視用経路一つが対応できる現用経路の数を増加させることができる。
また、請求項３の発明に係るデータ中継装置は、請求項２の発明において、複数の現用経路に対応する複数の予備経路の始点が異なる場合には、前記監視用経路として該異なる始点を全て含む経路を設定し、前記障害発生通知は監視用経路の各データ中継装置を一つずつ経由して送信されることを特徴とする。
この請求項３の発明によれば、複数の現用経路に対応する複数の予備経路の始点が異なる場合には、監視用経路として異なる始点を全て含む経路を設定し、障害発生通知は監視用経路の各データ中継装置を一つずつ経由して送信されるよう構成したので、監視用経路一つが対応できる現用経路の数を増加させることができる。
また、請求項４の発明に係るデータ中継装置は、請求項１の発明において、経路が同一である複数の予備経路に対しては、迂回トンネルを用いることを特徴とする。
この請求項４の発明によれば、経路が同一である複数の予備経路に対しては、迂回トンネルを用いるよう構成したので、複数の現用経路からの切替をまとめて行うことができる。
また、請求項５の発明に係るデータ中継装置は、請求項１の発明において、データの中継に使用するラベルテーブルに新規の現用経路に関する情報を登録する際に、既存の監視用経路が共有される経路を新規の現用経路として優先的に登録することを特徴とする。
この請求項５の発明によれば、データの中継に使用するラベルテーブルに新規の現用経路に関する情報を登録する際に、既存の監視用経路が共有される経路を新規の現用経路として優先的に登録するよう構成したので、監視用経路一つが対応できる現用経路の数を増加させることができる。
また、請求項６の発明に係るデータ中継装置は、請求項１の発明において、前記監視用経路の識別には、監視用経路であることを識別可能な監視用経路用識別子を用いることを特徴とする。
この請求項６の発明によれば、監視用経路の識別には、監視用経路であることを識別可能な監視用経路用識別子を用いるよう構成したので、監視用経路を容易に識別することができる。
また、請求項７の発明に係るデータ中継装置は、複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継装置であって、始点となる予備経路について現用経路と予備経路とを対応させた障害復旧情報を記憶した障害復旧情報記憶手段と、現用経路に発生した障害の通知である障害発生通知を受信する障害発生通知受信手段と、前記障害発生通知受信手段により障害発生通知が受信された現用経路である障害発生現用経路に対応する予備経路を前記障害復旧情報を用いて検索する予備経路検索手段と、前記予備経路検索手段により予備経路が検索された場合に、前記障害発生現用経路を用いて転送されるデータが予備経路を用いて転送されるように経路切替処理を行う経路切替処理手段と、を備え、前記障害が複数の現用経路で使用されている箇所で発生した場合に、前記障害発生通知受信手段は、前記複数の現用経路のうち監視用に用いられる経路である代表経路により前記障害発生通知を受信することを特徴とする。
この請求項７の発明によれば、障害が複数の現用経路で使用されている箇所で発生した場合に、複数の現用経路のうち監視用に用いられる経路である代表経路により障害発生通知を受信するよう構成したので、代表経路一つが対応できる現用経路の数を増加させることができる。
また、請求項８の発明に係るデータ中継装置は、請求項１の発明において、前記経路切替処理手段は、前記現用予備経路検索手段により検索された現用経路および予備経路について、既に経路切替処理が行われている場合には経路切替処理を行わないことを特徴とする。
この請求項８の発明によれば、既に経路切替処理が行われている障害発生現用経路については経路切替処理を行わないよう構成したので、一つの現用経路が対応できる現用経路の数を増加させることができる。
また、請求項９の発明に係るデータ中継方法は、複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継方法であって、経路に発生した障害の通知である障害発生通知を障害の監視専用に用いる監視用経路により、該障害が発生した監視用経路である障害発生監視用経路に対応する予備経路の始点である始点データ中継装置が受信する障害発生通知受信工程と、前記障害発生監視用経路に対応する現用経路および予備経路を前記始点データ中継装置が監視用経路と現用経路と予備経路とを対応させた障害復旧情報を用いて検索する現用予備経路検索工程と、前記現用予備経路検索工程により検索された現用経路を用いて転送されるデータが前記現用予備経路検索工程により検索された予備経路を用いて転送されるように前記始点データ中継装置が経路切替処理を行う経路切替処理工程と、を含んだことを特徴とする。
この請求項９の発明によれば、経路に発生した障害の通知である障害発生通知を障害の監視専用に用いる監視用経路により、障害が発生した監視用経路である障害発生監視用経路に対応する予備経路の始点である始点データ中継装置が受信し、障害発生監視用経路に対応する現用経路および予備経路を始点データ中継装置が監視用経路と現用経路と予備経路とを対応させた障害復旧情報を用いて検索し、検索した現用経路を用いて転送されるデータが、検索した予備経路を用いて転送されるように始点データ中継装置が経路切替処理を行うよう構成したので、監視用経路一つが対応できる現用経路の数を増加させることができる。
また、請求項１、２、３、５および９の発明によれば、監視用経路一つが対応できる現用経路の数を増加させるので、監視用経路の数を削減することができるという効果を奏する。
また、請求項４の発明によれば、複数の現用経路からの切替をまとめて行うので、現用経路からの切替を効率良く行うことができるという効果を奏する。
また、請求項６の発明によれば、監視用経路を容易に識別するので、監視用経路に対する処理を効率良く行うことができるという効果を奏する。
また、請求項７の発明によれば、代表経路一つが対応できる現用経路の数を増加させるので、代表経路の数を削減することができるという効果を奏する。
また、請求項８の発明によれば、一つの現用経路が対応できる現用経路の数を増加させることができるので、障害の復旧に用いる経路数を削減することができるという効果を奏する。
以下に添付図面を参照して、この発明に係るデータ中継装置およびデータ中継方法の好適な実施例を詳細に説明する。
まず、本実施例に係る中継装置の構成について説明する。図１は、本実施例に係る中継装置の構成を示す機能ブロック図である。同図に示すように、この中継装置１００は、データ受信部１１０と、データ送信部１２０と、データ中継部１３０と、中継用ラベルテーブル１４０ａと、予備パス用ラベルテーブル１４０ｂと、監視パス用ラベルテーブル１４０ｃと、制御パケット受信部１５０と、制御パケット送信部１６０と、障害復旧テーブル１７０と、現用パス制御部１８０ａと、予備パス制御部１８０ｂと、監視用パス制御部１８０ｃと、経路切替処理部１９０とを有する。
データ受信部１１０は、ネットワークからデータを受信し、受信したデータをデータ中継部１３０に渡す処理部である。データ送信部１２０は、データ中継部１３０からデータを受け取り、受け取ったデータをネットワークに送信する処理部である。
データ中継部１３０は、中継用ラベルテーブル１４０ａを用いてデータを中継する処理部である。すなわち、このデータ中継部１３０は、データ受信部１１０からデータおよび入力ＩＦを受け取り、中継用ラベルテーブル１４０ａを用いて入力ラベルおよび入力ＩＦから出力ラベルおよび出力ＩＦを検索する。そして、入力ラベルを出力ラベルに置き換え、出力ＩＦを指定してデータをデータ送信部１２０に渡す。
中継用ラベルテーブル１４０ａは、中継に用いるラベル情報を記憶したテーブルである。図２は、中継用ラベルテーブル１４０ａの一例を示す図である。同図に示すように、この中継用ラベルテーブル１４０ａは、パスを識別するパスＩＤと、入力ＩＦと、入力ラベルと、出力ＩＦと、出力ラベルとを現用パスごとに記憶する。
予備パス用ラベルテーブル１４０ｂは、予備パスごとにラベル情報を記憶したテーブルであり、中継用ラベルテーブル１４０ａと同様のデータ構造を有する。監視パス用ラベルテーブル１４０ｃは、監視用パスごとにラベル情報を記憶したテーブルであり、中継用ラベルテーブル１４０ａと同様のデータ構造を有する。
制御パケット受信部１５０は、ネットワークから制御パケットを受信する処理部であり、受け取った制御パケットのパスに関する情報に基づいて、制御パケットを現用パス制御部１８０ａ、予備パス制御部１８０ｂまたは監視用パス制御部１８０ｃのいずれかに渡す。
ここで、制御パケットとしては、パス確立要求メッセージ(PATHメッセージ)、パス確立応答メッセージ(RESV)、エラーメッセージがある。パス確立要求メッセージは、現用パス、予備パス、監視用パスのパス確立を要求するメッセージであり、このメッセージには、パスＩＤが格納されている。
パス確立応答メッセージ(RESVメッセージ)は、現用パス、予備パス、監視用パスの確立要求メッセージに対する応答メッセージであり、このメッセージには、パスＩＤと割り当てるラベルが格納されている。
エラーメッセージは、パス上でエラーが発生したことを始点ノードに通知するメッセージであり、このメッセージには、エラーが発生した場所に関する情報、パスＩＤが格納されている。また、このエラーメッセージは、監視用パス制御部１８０ｃに渡される。
制御パケット送信部１６０は、現用パス制御部１８０ａ、予備パス制御部１８０ｂまたは監視用パス制御部１８０ｃから制御パケットを受け取り、受け取った制御パケットをネットワークに送信する処理部である。
障害復旧テーブル１７０は、現用パスに障害が発生した場合に、現用パスを予備パスに切り替えるために経路切替処理部１９０により使用されるテーブルである。図３は、障害復旧テーブル１７０の一例を示す図である。同図に示すように、この障害復旧テーブル１７０は、自装置が始点である予備パスについて、現用パスを識別する現用パスＩＤと、予備パスを識別する予備パスＩＤと、監視用パスを識別する監視用パスＩＤとを対応させて記憶する。
この障害復旧テーブル１７０が、自装置が始点である予備パスについて現用パスと監視用パスを対応させて記憶することによって、予備パスの始点が監視用パスに含まれていさえすれば予備パスの始点と監視用パスの始点とを異なるものとすることができる。
現用パス制御部１８０ａは、現用パスに関する制御パケットを処理する処理部である。すなわち、この現用パス制御部１８０ａは、現用パスのパス確立を要求するPATHメッセージに格納されている現用パスの通過ノード情報に従い、PATHメッセージを転送し、さらにはPATHメッセージの送信ノードを記憶しておく。
そして、RESVメッセージを受信すると、その受信インタフェースを出力ＩＦに、受信したRESVメッセージに格納されているラベル情報を出力ラベルとして割り当てる。また、PATHメッセージを受信したインタフェースを入力ＩＦに、PATHメッセージに格納されていたラベル情報を入力ラベルとして割り当てる。
そして、受信したRESVメッセージのラベルを入力ラベルに置き換えて、PATHメッセージの送信ノードに返信する。また、割り当てたインタフェース、ラベル情報を中継用ラベルテーブル１４０ａに登録する。また、パスＩＤを障害復旧テーブル１７０の現用パスＩＤに登録する。
予備パス制御部１８０ｂは、現用パスに関する制御パケットに対して現用パス制御部１８０ａが行う処理と同様の処理を予備パスに関する制御パケットに対して行う処理部であり、割り当てたインタフェース、ラベル情報は、中継用ラベルテーブル１４０ａの代わりに予備パス用ラベルテーブル１４０ｂに登録する。
また、この予備パス制御部１８０ｂは、自装置が予備パスの始点である場合には、障害復旧テーブル１７０に登録されている現用パスＩＤに対応させて予備パスＩＤを登録し、自装置が予備パスの始点でない場合には、予備パスＩＤに対応する障害復旧テーブル１７０の現用パスＩＤを削除する。
監視用パス制御部１８０ｃは、現用パスに関する制御パケットに対して現用パス制御部１８０ａが行う処理と同様の処理を監視用パスに関する制御パケットに対して行う処理部であり、割り当てたインタフェース、ラベル情報は、中継用ラベルテーブル１４０ａの代わりに監視パス用ラベルテーブル１４０ｃに登録する。
また、この監視用パス制御部１８０ｃは、自装置が予備パスの始点である場合には、障害復旧テーブル１７０に登録されている現用パスＩＤおよび予備パスＩＤに対応させて監視用パスＩＤを登録する。また、この監視用パス制御部１８０ｃは、エラーメッセージを受信すると、経路切替処理部１９０にパス上でエラーが発生したことを通知してエラーメッセージを渡す。
経路切替処理部１９０は、監視用パス制御部１８０ｃからエラーメッセージを受信したことを通知されると、現用パスから予備パスへの切替処理を行う処理部である。すなわち、この経路切替処理部１９０は、障害復旧テーブル１７０を参照し、エラーメッセージに格納されている監視用パスＩＤが登録されているか否かを判定する。そして、監視用パスＩＤが登録されている場合には、自装置が予備パスの始点であるので、監視用パスＩＤに対応する現用パス、予備パスを特定する。そして、該当の予備パスの情報を予備パス用ラベル-テーブル１４０ｂから抽出し、中継用ラベルテーブル１４０ａに登録する。これにより、現用パス上のトラヒックが予備パスへ転送される。
このように、この経路切替処理部１９０が、エラーメッセージに格納されている監視用パスＩＤが障害復旧テーブル１７０に登録されているか否かを判定し、監視用パスＩＤが登録されている場合に監視用パスＩＤに対応する現用パス、予備パスを特定し、現用パス上のトラヒックが予備パスへ転送されるように経路を切り替える処理を行うことによって、現用パスの障害を復旧することができる。
次に、本実施例に係る中継装置１００による障害復旧動作について、いくつかのケースを対象に説明する。まず、ケース１として、７ノードで構成されるネットワークを対象に、本実施例に係る中継装置１００による障害復旧動作について図４〜図９を用いて説明する。ここで、ノードとは、中継装置のことである。また、以下では、中継用ラベルテーブル１４０ａ、予備パス用ラベルテーブル１４０ｂ、監視パス用ラベルテーブル１４０ｃを合わせてラベルテーブルと呼ぶ。
まず、パス確立シグナリングプロトコル(RSVP-TE)を用いて、「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」の経路の現用パスを確立する（図４）。すると、図４に示されている「ノード２」が保持するラベルテーブルと同様のテーブルが現用パス上の全ノードで構築される。
そして、現用パス上の「ノード２」−「ノード３」−「ノード４」で発生する障害に対応するため、「ノード２」を始点とし「ノード４」を終点とする、「ノード２」→「ノード６」→「ノード７」→「ノード４」の経路の予備パスを確立する。この予備パスも現用パスと同様にパス確立シグナリングプロトコル(RSVP-TE)を用いて確立する（図５）。すると、図５に示されている「ノード２」、「ノード６」が保持するラベルテーブルと同様のテーブルが予備パス上の全ノードで構築される。
また、「ノード２」、「ノード４」は、予備パスのPATHメッセージに格納されている現用パスとの対応付け情報に基づき、対応する現用パスのラベル、インタフェース情報を合わせて登録する。上記の現用パスとの対応付け情報として、既に関連付けルールに従ってパスＩＤを決定する方法や現用パス情報をPATHメッセージに格納する方法等がある。図５中の「ノード２」のラベルテーブルでは、「現用パス１」の入力ラベル、入力インタフェースの情報が登録されている。
また、障害時に経路切り替えノードとなる「ノード２」は、現用パスと予備パスとの対応表である障害復旧テーブル１７０を保持する。なお、ここでは、現用パスＩＤを「＃１」、予備パスＩＤを「＃１０」とする。
そして、現用パスが通過する「ノード２」−「ノード３」−「ノード４」間で発生する障害を監視するため、同一の経路で、監視用パスを確立する（図６）。監視用パスの確立のために、パス確立シグナリングプロトコル(RSVP-TE)を用いる。
また、パス確立シグナリングを行う際に、確立されたパスが監視用パスであることを示すために、PATHメッセージに監視用パスであることを示すフラグやオブジェクトなどの情報を埋め込む、あるいは、監視用パスであることを示すパスＩＤを割り当てる。
その結果、図６に示されている「ノード２」が保持するラベルテーブルと同様のテーブルが監視用パス上の全ノードで構築される。なお、図６中の「ノード２」のラベルテーブルでは、「ノード２」が監視用パスの始点ノードであるため、入力ラベル、入力インタフェースの情報は登録されていない。
また、障害時に経路切り替えノードとなる「ノード２」は、予備パスと監視用パスとの対応表である障害復旧テーブル１７０を保持する（図７）。なお、ここでは、監視用パスのＩＤを「＃１００」とする。
なお、すでに説明したように、パス確立シグナリングプロトコルには、パス確立要求を示すPathメッセージとその応答であるResvメッセージの他に、確立したパスにエラーが発生したことを通知するエラーメッセージがある。PathErr/ResvTear/Notifyメッセージがそれに相当する。これらはエラーの種類に応じて使用されるが、どのエラーメッセージを用いても以下の動作を実現することが可能である。また、エラーメッセージにはパス確立時にPath/Resvメッセージに格納されていたパスＩＤが格納される。
そして、「ノード２」−「ノード３」−「ノード４」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード３」−「ノード４」間で障害が発生したとして説明する。障害を検出した「ノード３」は、経路の切り替え「ノード２」に障害が発生したことを通知するため、監視用パスに対するエラーメッセージを「ノード２」に送信する（図８）。この監視用パスに対するエラーメッセージには監視用パスのＩＤが格納されている。
このエラーメッセージを受信した「ノード２」は、エラーメッセージに格納されているパスＩＤに基づき、障害復旧テーブル１７０を検索し、現用パスと予備パスを特定する。そして、検索された現用パスのトラヒックを対応する予備パスへ送信することによって、障害から回復させる（図９）。
このケース１では、「ノード３」−「ノード４」間で障害が発生したとき、障害を検出した「ノード３」は、監視用パスに対するエラーメッセージを「ノード２」に送信し、現用パスに対しては送信しない。このように、パス確立シグナリングプロトコルで規定されているエラーメッセージを現用パスに対して送信する機能を抑制することによって、必要のないエラーメッセージを削減することができる。
また、このケース１では、１現用パスに対して１監視用パスを対応づけているため、大きな効果は得られないが、以降で説明するケース２のように複数の現用パスに対して一つの監視用パスを対応付けている場合には障害発生時に生成されるメッセージ数を大幅に削減することができる。
また、このケース１では、「ノード３」−「ノード４」間で障害が発生したとき、障害を検出した「ノード３」は、監視用パスに対するエラーメッセージを「ノード２」に送信した。しかし、パス確立シグナリングプロトコルで現用パスでのエラーメッセージの送信が規定されている。したがって、ケース１に示した動作を実現するためには、現用パスでのエラーメッセージ送信の抑制機能を追加する必要がある。
一方、現用パスのエラーメッセージが送信されるよりも前に監視用パスのエラーメッセージを優先して送信することで、現用パスでのエラーメッセージ送信の抑制機能を追加せずに上記動作を実現することもできる。すなわち、ほぼ同時に二つのパケットが送信された場合、後に到着したパケットは中継されるときに中継ノードの負荷・処理能力により廃棄される可能性がある。そこで、監視用パスのエラーパケットを初めに送信することによって、監視用パスのエラーパケットの廃棄を回避し、切り替えノードに到達させることができる。
また、このケース１では、現用パスを確立した後、予備パスを確立し、監視用パスを確立していた。しかし、予備パスと監視用パスの確立順を逆にし、監視用パスを確立した後に予備パスを確立してもよい。予備パスを先に確立する上記のケース１では、監視用パスが確立されるまでの間に障害が発生した場合には現用パスから予備パスへトラヒックを迂回できなくなる可能性があるが、監視用パスを先に確立した場合には予備パス確立後はいつ障害が発生したとしても現用パスから予備パスへトラヒックを迂回できる。
また、このケース１では、現用パスの一部区間だけに対して予備パスを確立し、その区間で障害が起こった場合にだけトラヒックを迂回させている。しかし、一部区間だけに予備パスを確立することに限定する必要はなく、必要に応じて他の区間にも予備パスを確立することができる。一般的には、現用パス上のいずれの箇所で障害が発生したとしても障害を回避させるために複数の予備パスを確立する。
また、エラーメッセージを監視用パスの始点ノードへ転送する際に、エラーメッセージとしてPathErr/ResvTearメッセージを用いた場合には、エラーメッセージは監視用パス上をHop-by-Hopで転送される。一方、エラーメッセージとしてNotifyメッセージを用いた場合には、エラーメッセージはパケットの宛先である始点ノードまで直接転送される。そのため、監視用パスと異なる経路を転送される場合もある。
また、現用パス、予備パス、監視パスを確立するためにパス確立シグナリングプロトコル(RSVP-TE)を用いるのではなく、人手で各装置にラベルテーブル、障害復旧テーブルを構築する場合もある。
次に、ケース２として、９ノードで構成されるネットワークを対象に、本実施例に係る中継装置１００による障害復旧動作について図１０〜図１３を用いて説明する。まず、パス確立シグナリングプロトコル(RSVP-TE)を用いて、「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」の経路の「現用パス１」と、「ノード８」→「ノード２」→「ノード３」→「ノード４」→「ノード９」の経路の「現用パス２」を確立する。
そして、「ノード２」−「ノード３」−「ノード４」で発生する障害に対応するため、「ノード２」を始点とし「ノード４」を終点とする、「ノード２」→「ノード６」→「ノード７」→「ノード４」の経路の「予備パス１」、「予備パス２」を確立する。「予備パス１」は、「現用パス１」の迂回路として、「予備パス２」は、「現用パス２」の迂回路として使用される。この「予備パス１」、「予備パス２」も現用パスと同様にパス確立シグナリングプロトコル(RSVP-TE)を用いて確立する。
また、障害時に経路切り替えノードとなる「ノード２」は、現用パスと予備パスとの対応表である障害復旧テーブル１７０を保持する。なお、ここでは、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、「予備パス１」、「予備パス２」のパスＩＤをそれぞれ「＃１０」、「＃２０」とする。
「現用パス１」と「現用パス２」は同じ区間(「ノード２」−「ノード３」−「ノード４」)を通過する。そこで、この区間で発生する障害を監視するため、同一の経路で、監視用パスを確立する。監視用パスの確立のために、パス確立シグナリングプロトコル(RSVP-TE)を用いる。
また、パス確立シグナリングを行う際に、確立されたパスが監視用パスであることを示すために、PATHメッセージに監視用パスであることを示すフラグやオブジェクトなどの情報を埋め込む、あるいは、監視用パスであることを示すパスＩＤを割り当てる。
図１０に、確立された「現用パス１」、「現用パス２」、「予備パス１」、「予備パス２」、監視用パスを示す。また、パス確立シグナリングプロトコルで構築されるラベルテーブルの例も図１０に合わせて示す。
また、障害時に経路切り替えノードとなる「ノード２」は、予備パスと監視用パスとの対応表である障害復旧テーブル１７０を保持する。ここでは、監視用パスのパスＩＤを「＃１００」とすると、障害復旧テーブル１７０は、図１１に示すようになる。
そして、「ノード２」−「ノード３」−「ノード４」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード３」−「ノード４」間で障害が発生したとして説明する。障害を検出した「ノード３」は、経路の切り替え「ノード２」に障害が発生したことを通知するため、監視用パスに対するエラーメッセージを「ノード２」に送信する。監視用パスに対するエラーメッセージには監視用パスのパスＩＤが格納されている（図１２）。
このエラーメッセージを受信した「ノード２」は、エラーメッセージに格納されているパスＩＤに基づき、障害復旧テーブル１７０を検索し、現用パスと予備パスを特定する。このケース２では、２組の現用パスと予備パスが得られる。そして、「ノード２」は、得られた現用パス上のトラヒックを対応する予備パスへ転送することによって、障害から回復させる。その結果、一つの監視用パスのエラーメッセージを受信することによって、障害の影響を受けた二つの現用パスを障害から回復させることができる（図１３）。
このように、本実施例に係る中継装置１００を用いることによって、複数の現用パスに対して一つの監視用パスを設定することが可能になり、監視用パス数を削減することができ、かつ、障害発生時に生成されるエラーメッセージを削減することができる。
次に、ケース３として、９ノードで構成されるネットワークを対象に、本実施例に係る中継装置１００による障害復旧動作について図１４〜図１７を用いて説明する。まず、パス確立シグナリングプロトコル(RSVP-TE)を用いて、「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」の経路の「現用パス１」と、「ノード８」→「ノード２」→「ノード３」→「ノード４」→「ノード９」の経路の「現用パス２」を確立する。
そして、「ノード２」−「ノード３」−「ノード４」で発生する障害を迂回するため、「ノード２」を始点とし「ノード４」を終点とする、「ノード２」→「ノード６」→「ノード７」→「ノード４」の経路のBypassトンネルを確立する。このBypassトンネルも現用パスと同様にパス確立シグナリングプロトコル(RSVP-TE)を用いて確立する。
障害発生時には、現用パスの方路がBypassトンネルへ変えられる。なお、Bypassトンネル上を転送されるトラヒックは現用パスのラベルの前にBypassトンネルのラベルが付加される。また、「ノード４」がBypassトンネルを転送されたトラヒックを現用パスへ転送できるように、「ノード２」は障害前に「ノード４」が使用していたラベルを現用ラベルとしてトラヒックに添付する。
また、障害時に経路切り替えノードとなる「ノード２」は、現用パスと予備パスとの対応表である障害復旧テーブル１７０を保持する。なお、ここでは、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、BypassのパスＩＤを「＃１０００」とする。
「現用パス１」と「現用パス２」は同じ区間(「ノード２」−「ノード３」−「ノード４」)を通過する。そこで、この区間で発生する障害を監視するため、同一の経路で、監視用パスを確立する。監視用パスの確立のために、パス確立シグナリングプロトコル(RSVP-TE)を用いる。
また、パス確立シグナリングを行う際に、確立されたパスが監視用パスであることを示すために、PATHメッセージに監視用パスであることを示すフラグやオブジェクトなどの情報を埋め込む、あるいは、監視用パスであることを示すパスＩＤを割り当てる。
図１４に、確立された「現用パス１」、「現用パス２」、Bypassトンネル、監視用パスを示す。また、パス確立シグナリングプロトコルで構築されるラベルテーブルの例も合わせて図１４に示す。
また、障害時に経路切り替えノードとなる「ノード２」は、Bypassトンネルと監視用パスとの対応表である障害復旧テーブルを保持する（図１５）。なお、ここでは、監視用パスのパスＩＤを「＃１００」とする。
そして、「ノード２」−「ノード３」−「ノード４」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード３」−「ノード４」間で障害が発生したとして説明する。障害を検出した「ノード３」は、経路の切り替え「ノード２」に障害が発生したことを通知するため、監視用パスに対するエラーメッセージを「ノード２」に送信する（図１６）。監視用パスに対するエラーメッセージには監視用パスのパスＩＤが格納されている。
このエラーメッセージを受信した「ノード２」は、エラーメッセージに格納されているパスＩＤに基づき、障害復旧テーブルを検索し、現用パスとBypassトンネルを特定する。このケース２では、２組の現用パスとBypassトンネルが得られる。そして、得られた現用パスをBypassトンネル上に方路を変える。
具体的には、トラヒックに障害時に使用する出力ラベルを添付し、さらにBypassトンネルのラベルを添付した後、Bypassトンネル側へ転送する。これにより障害から回復できる（図１７）。その結果、一つの監視用パスのエラーメッセージを受信することによって、障害の影響を受けた二つの現用パスを障害から回復させることができる。
このように、本実施例に係る中継装置１００を用いることによって、複数の現用パスに対して一つの監視用パスを設定することが可能になり、監視用パス数を削減することができ、かつ、障害発生時に生成されるエラーメッセージを削減することができる。
これまでの説明では、予備パスの始点ノード、終点ノードが、監視用パスの始点ノード、終点ノードと同一である場合について説明してきた。しかし、予備パスの始点ノード、終点ノードと、監視用パスの始点ノード、終点ノードを異なるノードとすることも可能である。そこで、ケース４として、予備パスの終点ノードと監視用パスの終点ノードが異なる場合について図１８を用いて説明する。
まず、「ノード１」→「ノード２」→「ノード３」→「ノード４」→「「ノード１３」→「ノード１４」の経路の「現用パス１」を確立し、「ノード１２」→「ノード２」→「ノード３」→「ノード４」→「ノード５」→「ノード６」の経路の「現用パス２」を確立する（図１８）。
ここで、「現用パス１」と「現用パス２」がともに通過する共通区間は「ノード２」−「ノード３」−「ノード４」である。そこで、この共通区間で発生した障害を迂回する予備パスを確立する。「現用パス１」に対する「予備パス１」は「ノード２」→「ノード７」→「ノード８」→「ノード１３」の経路で確立され、「現用パス２」に対する「予備パス２」は「ノード２」→「ノード９」→「ノード１０」→「ノード１１」→「ノード５」の経路で確立される。
また、このケース４では、予備パスの終点ノードと、監視用パスの終点ノードを同一にする必要がないため、「現用パス１」と「現用パス２」がともに通過する共通区間（「ノード２」−「ノード３」−「ノード４」）で発生する障害を監視する監視用パスを確立する。
そして、「ノード２」は、監視用パスと「予備パス１」、「予備パス２」とを関連付け、障害復旧テーブル１７０に登録する。ここでは、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、「予備パス１」、「予備パス２」のパスＩＤをそれぞれ「＃１０」、「＃２０」とする。また、監視用パスのパスＩＤを「＃１００」とする。
そして、「ノード２」−「ノード３」−「ノード４」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード３」−「ノード４」間で障害が発生したとして説明する。障害を検出した「ノード３」は、経路の切り替え「ノード２」に障害が発生したことを通知するため、監視用パスに対するエラーメッセージを「ノード２」に送信する。監視用パスに対するエラーメッセージには監視用パスのパスＩＤが格納されている。
このエラーメッセージを受信した「ノード２」は、エラーメッセージに格納されているパスＩＤに基づき、障害復旧テーブル１７０を検索し、現用パスと予備パスを特定する。このケース４では、２組の現用パスと予備パスが得られる。そして、得られた現用パス上のトラヒックを対応する予備パスへ転送することによって、障害から回復させる。その結果、一つの監視用パスのエラーメッセージを受信することによって、障害の影響を受けた二つの現用パスを障害から回復させることができる。
このように、本実施例に係る中継装置１００を用いることによって、異なる区間を迂回する複数の予備パスを一つの監視用パスで管理することが可能であるため、監視用パス数を削減することができる。
なお、このケース４では、現用パスの一部区間だけに対して予備パスを確立し、その区間で障害が起こった場合にだけトラヒックを迂回させている。しかし、一部区間だけに予備パスを確立することに限定する必要はなく、必要に応じて他の区間にも予備パスを確立することができる。すなわち、この説明の中では、簡単のためネットワークの一部だけを切り出して説明を行っている。
すなわち、このケース４では、「現用パス１」に関して設定できる迂回路は、「ノード２」−「ノード３」−「ノード４」−「ノード１３」であるが、実際のネットワークでは、その他の部分に対しても迂回路を確立できる。例えば、「ノード１４」−「ノード５」間にリンクが存在する場合、「ノード４」−「ノード１３」−「ノード１４」を迂回する「予備パス１'」が確立できる。
このような場合には、「ノード４」−「ノード１３」−「ノード１４」間に監視パスを確立し、同様の障害復旧メカニズムを適用することができる。このように、現用パスの全リンクに対して迂回路が設定されるようにすることで、現用パス全体を障害から保護することが可能になる。
これまでは、複数の現用パスの共通区間に監視用パスを確立し、その監視用パスと予備パスを関連付ける手法について説明してきた。しかし、複数の現用パスの共通区間以外に監視用パスを設けることもできる。そこで、ケース５として、共通区間よりも上流方向に大きい区間に確立した監視用パスと予備パスとを対応付けることによって、さらに監視用パス数を削減する手法について図１９を用いて説明する。
まず、「ノード１２」→「ノード３」→「ノード４」→「ノード５」→「ノード１３」の経路の「現用パス１」と、「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」→「ノード６」の経路の「現用パス２」を確立する。そして、それぞれに対応する「予備パス１」、「予備パス２」が図１９のように確立されているとする。
このとき、「予備パス１」、「予備パス２」が迂回する両区間を含む監視用パスを「ノード２」→「ノード３」→「ノード４」→「ノード５」で確立する。監視用パスを確立した「ノード２」→「ノード３」→「ノード４」→「ノード５」は、「現用パス１」と「現用パス２」の共通区間よりも上流方向に大きい区間である。そのため、監視パスの始点ノードと全ての予備パスの始点ノードが同一にはならない。
ここで、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、「予備パス１」、「予備パス２」のパスＩＤをそれぞれ「＃１０」、「＃２０」とする。また、監視用パスのパスＩＤを「＃１００」とする。そして、「予備パス２」の始点である「ノード２」は、「予備パス２」と監視用パスとの関連付けを行い、障害復旧テーブル１７０に登録する。また、「予備パス１」の始点である「ノード３」は、「予備パス１」と監視用パスとの関連付けを行い、障害復旧テーブル１７０に登録する。
そして、「ノード２」−「ノード３」−「ノード４」−「ノード５」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード４」−「ノード５」間で障害が発生したとして説明する。障害を検出した「ノード４」は、監視パスの始点ノードである「ノード２」に障害が発生したことを通知するため、監視用パスに対するエラーメッセージを「ノード２」に送信する。ここでは、エラーメッセージとしてPathErr/Resvエラーを用いる。
この場合、エラーメッセージは監視用パス上をHop-by-Hop転送されるため、エラーメッセージの送信ノードより上流にある監視用パス上の全ノード(この場合には、中継ノードである「ノード３」と始点ノードである「ノード２」)はエラーメッセージを扱うことができるようになる。
そして、このエラーメッセージを中継した「ノード３」および「ノード２」は、エラーメッセージに格納されているパスＩＤに基づき、障害復旧テーブル１７０を検索し、現用パスと予備パスを特定する。「ノード２」では「現用パス２」と「予備パス２」が、「ノード３」では「現用パス１」と「予備パス１」が得られる。そして、得られた現用パス上のトラヒックを対応する予備パスへ転送することによって、障害から回復させる。
このように、本実施例に係る中継装置１００を用いることによって、一つの監視用パスに関するエラーメッセージによって、区間の異なる複数の予備パスへトラヒックを迂回させることができるため、監視用パス数を削減することができる。
次に、ケース６として、図２０に示すように、既に１組の「現用パス２」、「予備パス２」、監視用パスが確立されているときに、新たに「ノード１」から「ノード５」へのパスを追加する場合の手順について説明する。「ノード１」が「ノード１」から「ノード５」への経路を計算するとき、既に確立されている監視用パスを共有することによりネットワーク全体での監視用パス数を少なくする経路を算出する。
すなわち、図２０では、「ノード１」→「ノード６」→「ノード７」→「ノード５」が最短経路であるが、監視用パスを共有するため、「ノード１」は「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」を選択した（図２１）。そして、「ノード１」は、パス確立シグナリングプロトコル(RSVP-TE)を用いて、「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」の経路の「現用パス１」を確立する。
このとき、「ノード２」は、既に確立されている監視用パスと同一の経路を「現用パス１」が通過することを認識すると、監視用パスの始点ノード、終点ノードである「ノード２」から「ノード４」への「予備パス１」を、「ノード２」→「ノード６」→「ノード７」→「ノード４」の経路で確立する。そして、「現用パス１」に対する「予備パス１」、監視用パスを障害復旧テーブル１７０に登録する。
ここでは、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、「予備パス１」、「予備パス２」のパスＩＤをそれぞれ「＃１０」、「＃２０」とする。また、監視用パスのパスＩＤを「＃１００」とすると障害復旧テーブル１７０は図２２のようになる。
このように、経路を選択する際に、監視用パスを共有させる経路を選択することにより、ネットワーク全体での監視用パス数を削減することができる。また、パス確立時に現用パス、予備パス、監視用パスの対応付けを人手を介さず自動にすることで、短時間でパス設定を完了させることができる。
これまでは、監視用パスを用いてエラーメッセージを転送する場合について説明したが、監視用パスを確立することなく、一つのエラーメッセージにより複数パスの障害を復旧することもできる。そこで、ケース７として、９ノードで構成されるネットワークを対象に、監視用パスを用いない障害復旧動作について図２３〜図２７を用いて説明する。
まず、パス確立シグナリングプロトコル(RSVP-TE)を用いて、２本の現用パスを確立する。一つは「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」の経路の「現用パス１」、もう一つは「ノード８」→「ノード２」→「ノード３」→「ノード４」→「ノード９」の経路の「現用パス２」である。
そして、「ノード２」−「ノード３」−「ノード４」で発生する障害に対応するため、「ノード２」を始点とし「ノード４」を終点とする、「ノード２」→「ノード６」→「ノード７」→「ノード４」の経路の「予備パス１」、「予備パス２」を確立する。「予備パス１」は、「現用パス１」の迂回路として、「予備パス２」は、「現用パス２」の迂回路として使用される。この「予備パス１」、「予備パス２」も現用パスと同様にパス確立シグナリングプロトコル(RSVP-TE)を用いて確立する。
図２３に、確立された「現用パス１」、「現用パス２」、「予備パス１」、「予備パス２」を示す。また、パス確立シグナリングプロトコルで構築されるラベルテーブルの例も合わせて図２３に示す。
「現用パス１」と「現用パス２」は同じ区間(「ノード２」−「ノード３」−「ノード４」)を通過する。したがって、この区間で発生する障害が発生した場合には、「現用パス１」、「現用パス２」ともに予備パスに経路を切り替え、トラヒックを迂回させる。
これまでのケースでは、この共通区間に対して監視用パスを確立していた。しかし、ここでは、監視用パスを確立せずに現用パスの一本を代表パスとして定義し（図２４）、代表パスを用いてエラーメッセージを転送する。
この場合、代表パスである現用パスを確立時に、パス確立シグナリングプロトコルのPATHメッセージに代表フラグとどの区間で代表パスになるかを示す区間の始点情報と区間の終点情報を格納する。例えば、代表パスになる区間として、始点ノードＩＤである「ノード２」、終点ノードＩＤである「ノード４」を格納する。
また、障害時に経路切り替えノードとなる「ノード２」は、予備パスと代表パスとの対応表として図２５に示す障害復旧テーブルを保持する。この障害復旧テーブルには、現用パスＩＤと、予備パスＩＤと、代表パスＩＤと、障害区間とが対応させて登録される。なお、ここでは、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、「予備パス１」、「予備パス２」のパスＩＤをそれぞれ「＃１０」、「＃２０」とする。また、「現用パス１」を代表パスとする。
そして、「ノード２」−「ノード３」−「ノード４」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード３」−「ノード４」間で障害が発生したとして説明する。障害を検出した「ノード３」は、確立されている代表パスを検索する。そして、経路の切り替えノードである「ノード２」に障害が発生したことを通知するため、代表パスに対するエラーメッセージを他のエラーメッセージに先立ち「ノード２」に送信する。あるいは、代表パスのみのエラーメッセージを「ノード２」に送信する。このエラーメッセージには代表パスのパスＩＤ、および障害ポイントのアドレスが格納されている（図２６）。
このエラーメッセージを受信した「ノード２」は、エラーメッセージに格納されているパスＩＤおよび障害ポイントのアドレスに基づき、障害復旧テーブルを検索し、現用パスと予備パスを特定する。このケースでは２組の現用パスと予備パスが得られる。そして、得られた現用パス上のトラヒックを対応する予備パスへ転送することによって、障害から回復させる。その結果、一つの代表パスのエラーメッセージを受信することによって、障害の影響を受けた二つの現用パスを障害から回復させることができる（図２７）。
このように、代表パスを用いることによって、監視用パスを新たに確立することなく、一つのエラーメッセージにより複数パスの障害復旧を実現することができる。
次に、ケース８として、監視用パスも代表パスも用いない場合について、図２８〜図３３を用いて説明する。まず、パス確立シグナリングプロトコル(RSVP-TE)を用いて、２本の現用パスを確立する。一つは「ノード１」→「ノード２」→「ノード３」→「ノード４」→「ノード５」の経路の「現用パス１」、もう一つは「ノード８」→「ノード２」→「ノード３」→「ノード４」→「ノード９」の経路の「現用パス２」である。
そして、「ノード２」−「ノード３」−「ノード４」で発生する障害に対応するため、「ノード２」を始点とし「ノード４」を終点とする、「ノード２」→「ノード６」→「ノード７」→「ノード４」の経路の「予備パス１」、「予備パス２」を確立する。「予備パス１」は、「現用パス１」の迂回路として、「予備パス２」は、「現用パス２」の迂回路として使用される。この「予備パス１」、「予備パス２」も現用パスと同様にパス確立シグナリングプロトコル(RSVP-TE)を用いて確立する。
図２８に、確立された「現用パス１」、「現用パス２」、「予備パス１」、「予備パス２」を示す。また、パス確立シグナリングプロトコルで構築されるラベルテーブルの例も合わせて図２８に示す。
「現用パス１」と「現用パス２」は同じ区間(「ノード２」−「ノード３」−「ノード４」)を通過する。この区間で発生する障害が発生した場合には、「現用パス１」、「現用パス２」ともに予備パスに経路を切り替え、トラヒックを迂回させる。これまでのケースでは、この共通区間に確立された監視用パス、あるいは代表パスを使用していた。しかし、ここでは、監視用パス、代表パスのいずれも用いずに単一のエラーメッセージで複数パスの切り替えを実現する。
そこで、障害時に経路切り替えノードとなる「ノード２」は、どの障害に対して現用パスを予備パスに切り替えるかを判別するため、図２９に示すような、予備パスと障害区間との対応表である障害復旧テーブルを保持する（図３０）。この障害復旧テーブルには、現用パスＩＤと、予備パスＩＤと、障害区間とが対応させて登録される。なお、ここでは、「現用パス１」、「現用パス２」のパスＩＤをそれぞれ「＃１」、「＃２」とし、「予備パス１」、「予備パス２」のパスＩＤをそれぞれ「＃１０」、「＃２０」とする。
そして、「ノード２」−「ノード３」−「ノード４」間で障害が発生すると、その上流の中継ノードが障害を検出する。ここでは、「ノード３」−「ノード４」間で障害が発生したとして説明する。障害を検出した「ノード３」は、経路の切り替え「ノード２」に障害が発生したことを通知するため、各現用パスに対するエラーメッセージをそれぞれの始点ノードに送信する。このエラーメッセージには障害ポイントのアドレスが格納されている（図３１）。
エラーメッセージを受信する「ノード２」は、最初に到着したエラーメッセージに対してまず以下の処理を行う。最初に到着したエラーメッセージに格納されている障害ポイントのアドレスに基づき、障害復旧テーブルを検索し、現用パスと予備パスを特定する。このとき得られる現用パスと予備パスは２組である。得られた現用パス上のトラヒックを対応する予備パスへ転送することによって、障害から回復させる。次に到着したエラーメッセージについても同等の処理を行うが、検索した結果得られた現用パスの経路が既に切り替えていた場合にその現用パスが無視される。
このケース８では、現用パス毎にエラーメッセージが生成されるため、障害発生時にはエラーメッセージが大量に発生し、輻輳が発生する可能性がある。しかし、到着した最初のエラーメッセージに基づいて、障害の影響を受けた全ての現用パスの経路を変更することによって、輻輳によりエラーメッセージが発生した場合にも高速に障害から回復させることができる（図３２）。
なお、図２９に示した障害復旧テーブルは、パス毎にリストされているが、図３３に示すように、障害区間ごとにリストすることによって、高速に対応する現用パス、予備パスを検索することができる。
上述してきたように、本実施例では、同一経路を有する複数の現用パスだけでなく、一部の区間を共有する複数の現用パスに対して予備パスおよび監視用パスを設定し、予備パスの始点ノードが、現用パスと予備パスと監視用パスとを対応させた障害復旧テーブル１７０を備え、監視用パス制御部１８０ｃが、エラーメッセージを受信すると経路切替処理部１９０に通知し、経路切替処理部１９０が、経路切替が必要な現用パスおよび対応する予備パスを障害復旧テーブル１７０を用いて特定し、特定した現用パスから対応する予備パスに経路を切り替える処理行うこととしたので、監視用パスの数を減らし、障害発生時のネットワーク負荷の増加を抑えることができる。
また、監視用パスの代わりに代表パスを用いることによって、監視用パスをなくすことができる。さらに、単一エラーメッセージにより複数の切り替えを行うことで、代表パスをなくすこともできる。
また、本実施例では、現用パス制御部１８０ａ、予備パス制御部１８０ｂおよび監視用パス制御部１８０ｃが各パスを確立する際に順に障害復旧テーブル１７０を作成していく場合について説明したが、本発明はこれに限定されるものではなく、パスの確立とは別に、障害復旧テーブル１７０を作成する場合にも同様に適用することができる。
（付記１）複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継装置であって、
始点となる予備経路について現用経路と予備経路とを対応させた障害復旧情報を記憶した障害復旧情報記憶手段と、
現用経路に発生した障害の通知である障害発生通知を受信する障害発生通知受信手段と、
前記障発生通知受信手段により障害発生通知が受信された現用経路である障害発生現用経路に対応する予備経路を前記障害復旧情報を用いて検索する予備経路検索手段と、
前記予備経路検索手段により予備経路が検索された場合に、前記障害発生現用経路を用いて転送されるデータが予備経路を用いて転送されるように経路切替処理を行う経路切替処理手段と、
を備えたことを特徴とするデータ中継装置。
（付記２）前記障害発生通知受信手段は、障害の監視専用に用いる監視用経路により前記障害発生通知を受信することを特徴とする付記１に記載のデータ中継装置。
（付記３）前記障害発生通知受信手段が障害発生通知を受信する監視用経路として、一部の区間が共通である複数の現用経路に対して共通である区間を含む一つの経路を設定することを特徴とする付記２に記載のデータ中継装置。
（付記４）前記監視用経路が設定される複数の予備経路の終点が異なることを特徴とする付記３に記載のデータ中継装置。
（付記５）複数の現用経路に対応する複数の予備経路の始点が異なる場合には、前記障害発生通知受信手段が障害発生通知を受信する監視用経路として該異なる始点を全て含む経路を設定し、該障害発生通知は監視用経路の各データ中継装置を一つずつ経由して送信されることを特徴とする付記３に記載のデータ中継装置。
（付記６）経路が同一である複数の予備経路に対しては、迂回トンネルを用いることを特徴とする付記２に記載のデータ中継装置。
（付記７）データの中継に使用するラベルテーブルに新規の現用経路に関する情報を登録する際に、既存の監視用経路が共有される経路を新規の現用経路として優先的に登録することを特徴とする付記２に記載のデータ中継装置。
（付記８）前記障害発生通知受信手段が障害発生通知を受信する監視用経路の識別には、監視用経路であることを識別可能な監視用経路用識別子を用いることを特徴とする付記２に記載のデータ中継装置。
（付記９）前記障害が複数の現用経路で使用されている箇所で発生した場合に、
前記障害発生通知受信手段は、前記複数の現用経路のうち監視用に用いられる経路である代表経路により前記障害発生通知を受信することを特徴とする付記１に記載のデータ中継装置。
（付記１０）前記障害が複数の現用経路で使用されている箇所で発生した場合に、
前記障害発生通知受信手段は、前記複数の現用経路にそれぞれ対応する複数の障害発生通知を受信し、
前記予備経路検索手段は、前記障害発生通知受信手段により障害発生通知が受信された複数の障害発生現用経路にそれぞれ対応する複数の予備経路を前記障害復旧情報を用いて検索し、
前記経路切替処理手段は、前記予備経路検索手段により予備経路が検索された障害発生現用経路のうち、前記複数の障害発生通知のいずれかの障害発生通知により既に経路切替処理が行われている障害発生現用経路については経路切替処理を行わないことを特徴とする付記１に記載のデータ中継装置。
（付記１１）複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継方法であって、
現用経路に発生した障害の通知である障害発生通知を該障害が発生した現用経路である障害発生現用経路に対応する予備経路の始点である始点データ中継装置が受信する障害発生通知受信工程と、
前記障発生通知受信工程により障害発生通知が受信された障害発生現用経路に対応する予備経路を前記始点データ中継装置が現用経路と予備経路とを対応させた障害復旧情報を用いて検索する予備経路検索工程と、
前記障害発生現用経路を用いて転送されるデータが前記予備経路検索工程により検索された予備経路を用いて転送されるように前記始点データ中継装置が経路切替処理を行う経路切替処理工程と、
を含んだことを特徴とするデータ中継方法。
（付記１２）前記障害発生通知受信工程は、障害の監視専用に用いる監視用経路により前記障害発生通知を受信することを特徴とする付記１１に記載のデータ中継方法。
（付記１３）前記障害発生通知受信工程が障害発生通知を受信する監視用経路として、一部の区間が共通である複数の現用経路に対して共通である区間を含む一つの経路を設定することを特徴とする付記１２に記載のデータ中継方法。
（付記１４）前記監視用経路が設定される複数の予備経路の終点が異なることを特徴とする付記１３に記載のデータ中継方法。
（付記１５）複数の現用経路に対応する複数の予備経路の始点が異なる場合には、前記障害発生通知受信工程が障害発生通知を受信する監視用経路として該異なる始点を全て含む経路を設定し、該障害発生通知は監視用経路の各データ中継装置を一つずつ経由して送信されることを特徴とする付記１３に記載のデータ中継方法。
（付記１６）経路が同一である複数の予備経路に対しては、迂回トンネルを用いることを特徴とする付記１２に記載のデータ中継方法。
（付記１７）データの中継に使用するラベルテーブルに新規の現用経路に関する情報を登録する際に、既存の監視用経路が共有される経路を新規の現用経路として優先的に登録することを特徴とする付記１２に記載のデータ中継方法。
（付記１８）前記障害発生通知受信工程が障害発生通知を受信する監視用経路の識別には、監視用経路であることを識別可能な監視用経路用識別子を用いることを特徴とする付記１２に記載のデータ中継方法。
（付記１９）前記障害が複数の現用経路で使用されている箇所で発生した場合に、
前記障害発生通知受信工程は、前記複数の現用経路のうち監視用に用いられる経路である代表経路により前記障害発生通知を受信することを特徴とする付記１１に記載のデータ中継方法。
（付記２０）前記障害が複数の現用経路で使用されている箇所で発生した場合に、
前記障害発生通知受信工程は、前記複数の現用経路にそれぞれ対応する複数の障害発生通知を受信し、
前記予備経路検索工程は、前記障害発生通知受信工程により障害発生通知が受信された複数の障害発生現用経路にそれぞれ対応する複数の予備経路を前記障害復旧情報を用いて検索し、
前記経路切替処理工程は、前記予備経路検索工程により予備経路が検索された障害発生現用経路のうち、前記複数の障害発生通知のいずれかの障害発生通知により既に経路切替処理が行われている障害発生現用経路については経路切替処理を行わないことを特徴とする付記１１に記載のデータ中継方法。
以上のように、本発明に係るデータ中継装置およびデータ中継方法は、ＧＭＰＬＳ網／ＭＰＬＳ網で有用であり、特に、監視用パスの数を減らし、障害発生時のネットワーク負荷の増加を抑えたい場合に適している。
本実施例に係る中継装置の構成を示す機能ブロック図である。 中継用ラベルテーブルの一例を示す図である。 障害復旧テーブルの一例を示す図である。 現用パスの確立を示す図である。 予備パスの確立を示す図である。 監視用パスの確立を示す図である。 現用パス、予備パス、監視用パスの対応付けを示す図である。 障害発生時のエラーメッセージ転送を示す図である。 障害迂回のための経路切り替えを示す図である。 現用パス、予備パス、監視用パスの確立を示す図である。 現用パス、予備パス、監視用パスの対応付けを示す図である。 障害発生時のエラーメッセージ転送を示す図である。 障害迂回のための経路切り替えを示す図である。 現用パス、Bypassトンネル、監視用パスの確立を示す図である。 現用パス、Bypassトンネル、監視用パスの対応付けを示す図である。 障害発生時のエラーメッセージ転送を示す図である。 障害迂回のための経路切り替えを示す図である。 異なる迂回区間の複数の予備パスに対応する監視用パス（その１）を示す図である。 異なる迂回区間の複数の予備パスに対応する監視用パス（その２）を示す図である。 確立済みの現用パス、予備パス、監視用パスを示す図である。 現用パスの追加を示す図である。 現用パス、予備パス、監視用パスの対応付けを示す図である。 現用パス、予備パスの確立を示す図である。 現用パス、予備パス、代表パスの対応付けを示す図である。 代表パスを用いる場合の障害復旧テーブルの一例を示す図である。 障害発生時のエラーメッセージ転送を示す図である。 障害迂回のための経路切り替えを示す図である。 現用パス、予備パスの確立を示す図である。 単一のエラーメッセージで複数のパスを切り替える場合の障害復旧テーブルの一例を示す図である。 現用パス、予備パスの対応付けを示す図である。 障害発生時のエラーメッセージ転送を示す図である。 障害迂回のための経路切り替えを示す図である。 単一のエラーメッセージで複数のパスを切り替える場合の障害復旧テーブルの他の例を示す図である。 固定長ラベルを用いたパケット転送を説明するための説明図である。 パス確立シグナリングプロトコル(RSVP-TE)の動作を説明するための説明図である。 PathErr/ResvTearメッセージを用いたエラーメッセージの転送を示す図である。 監視用パスを用いた障害復旧方式を説明するための説明図である。
符号の説明
１００ 中継装置
１１０ データ受信部
１２０ データ送信部
１３０ データ中継部
１４０ａ 中継用ラベルテーブル
１４０ｂ 予備パス用ラベルテーブル
１４０ｃ 監視パス用ラベルテーブル
１５０ 制御パケット受信部
１６０ 制御パケット送信部
１７０ 障害復旧テーブル
１８０ａ 現用パス制御部
１８０ｂ 予備パス制御部
１８０ｃ 監視用パス制御部
１９０ 経路切替処理部

Claims (9)

  1. 複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継装置であって、
    始点となる予備経路について障害の監視専用に用いる監視用経路と現用経路と予備経路とを対応させた障害復旧情報を記憶した障害復旧情報記憶手段と、
    経路に発生した障害の通知である障害発生通知を監視用経路により受信する障害発生通知受信手段と、
    前記障害発生通知受信手段により障害発生通知が受信された監視用経路である障害発生監視用経路に対応する現用経路および予備経路を前記障害復旧情報を用いて検索する現用予備経路検索手段と、
    前記現用予備経路検索手段により現用経路および予備経路が検索された場合に、該現用経路を用いて転送されるデータが該予備経路を用いて転送されるように経路切替処理を行う経路切替処理手段と、
    を備えたことを特徴とするデータ中継装置。
  2. 前記監視用経路として、一部の区間が共通である複数の現用経路に対して共通である区間を含む一つの経路を設定することを特徴とする請求項１に記載のデータ中継装置。
  3. 複数の現用経路に対応する複数の予備経路の始点が異なる場合には、前記監視用経路として該異なる始点を全て含む経路を設定し、前記障害発生通知は監視用経路の各データ中継装置を一つずつ経由して送信されることを特徴とする請求項２に記載のデータ中継装置。
  4. 経路が同一である複数の予備経路に対しては、迂回トンネルを用いることを特徴とする請求項１に記載のデータ中継装置。
  5. データの中継に使用するラベルテーブルに新規の現用経路に関する情報を登録する際に、既存の監視用経路が共有される経路を新規の現用経路として優先的に登録することを特徴とする請求項１に記載のデータ中継装置。
  6. 前記監視用経路の識別には、監視用経路であることを識別可能な監視用経路用識別子を用いることを特徴とする請求項１に記載のデータ中継装置。
  7. 複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継装置であって、
    始点となる予備経路について現用経路と予備経路とを対応させた障害復旧情報を記憶した障害復旧情報記憶手段と、
    現用経路に発生した障害の通知である障害発生通知を受信する障害発生通知受信手段と、
    前記障害発生通知受信手段により障害発生通知が受信された現用経路である障害発生現用経路に対応する予備経路を前記障害復旧情報を用いて検索する予備経路検索手段と、
    前記予備経路検索手段により予備経路が検索された場合に、前記障害発生現用経路を用いて転送されるデータが予備経路を用いて転送されるように経路切替処理を行う経路切替処理手段と、
    を備え、
    前記障害が複数の現用経路で使用されている箇所で発生した場合に、
    前記障害発生通知受信手段は、前記複数の現用経路のうち監視用に用いられる経路である代表経路により前記障害発生通知を受信することを特徴とするデータ中継装置。
  8. 前記経路切替処理手段は、前記現用予備経路検索手段により検索された現用経路および予備経路について、既に経路切替処理が行われている場合には経路切替処理を行わないことを特徴とする請求項１に記載のデータ中継装置。
  9. 複数のデータ中継装置を経由してデータを転送する経路として使用中の現用経路のいずれかの箇所に障害が発生すると該障害発生箇所を迂回する予備経路への切替によって障害復旧を行うネットワークでデータを中継するデータ中継方法であって、
    経路に発生した障害の通知である障害発生通知を障害の監視専用に用いる監視用経路により、該障害が発生した監視用経路である障害発生監視用経路に対応する予備経路の始点である始点データ中継装置が受信する障害発生通知受信工程と、
    前記障害発生監視用経路に対応する現用経路および予備経路を前記始点データ中継装置が監視用経路と現用経路と予備経路とを対応させた障害復旧情報を用いて検索する現用予備経路検索工程と、
    前記現用予備経路検索工程により検索された現用経路を用いて転送されるデータが前記現用予備経路検索工程により検索された予備経路を用いて転送されるように前記始点データ中継装置が経路切替処理を行う経路切替処理工程と、
    を含んだことを特徴とするデータ中継方法。
JP2005065835A 2005-03-09 2005-03-09 データ中継装置およびデータ中継方法 Expired - Fee Related JP4691372B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2005065835A JP4691372B2 (ja) 2005-03-09 2005-03-09 データ中継装置およびデータ中継方法
US11/166,804 US7710860B2 (en) 2005-03-09 2005-06-24 Data relay apparatus and data relay method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005065835A JP4691372B2 (ja) 2005-03-09 2005-03-09 データ中継装置およびデータ中継方法

Publications (2)

Publication Number Publication Date
JP2006253927A JP2006253927A (ja) 2006-09-21
JP4691372B2 true JP4691372B2 (ja) 2011-06-01

Family

ID=36970773

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005065835A Expired - Fee Related JP4691372B2 (ja) 2005-03-09 2005-03-09 データ中継装置およびデータ中継方法

Country Status (2)

Country Link
US (1) US7710860B2 (ja)
JP (1) JP4691372B2 (ja)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060215567A1 (en) * 2005-03-25 2006-09-28 Arun Raghunath Method and apparatus for monitoring path statistics
JP4545658B2 (ja) * 2005-08-11 2010-09-15 富士通株式会社 コネクション型ネットワークノード
US7593323B2 (en) * 2005-08-17 2009-09-22 Honeywell International Inc. Apparatus and methods for managing nodes on a fault tolerant network
US7990848B1 (en) * 2005-11-30 2011-08-02 At&T Intellectual Property Ii, L.P. System and method for long haul optical protection for storage area network (SAN) transport
CN1866806B (zh) * 2005-12-22 2011-11-02 华为技术有限公司 共享格状网恢复的实现方法
WO2008044646A1 (fr) * 2006-10-06 2008-04-17 Nippon Telegraph And Telephone Corporation Appareil de nœud de communication, systÈme de communication, et procÉDÉ d'affectation de ressources de trajet
JP2008199311A (ja) * 2007-02-13 2008-08-28 Fujitsu Ltd スイッチ装置およびパス監視設定方法
JP2008271088A (ja) * 2007-04-19 2008-11-06 Kddi Corp 映像伝送網統合運用管理システム及び運用管理方法
WO2009042856A1 (en) * 2007-09-28 2009-04-02 Allied Telesis, Inc. Method and apparatus for preventing network conflict
JP2009259161A (ja) * 2008-04-21 2009-11-05 Nec Corp ナレッジ型障害復旧支援システム、ユーザ端末、中継サーバ及びナレッジ提供サーバ並びにデータ中継方法
RU2474969C2 (ru) * 2008-04-28 2013-02-10 Хуавэй Текнолоджиз Ко., Лтд. Прозрачный обходной путь и соответствующие механизмы
JP2009296230A (ja) * 2008-06-04 2009-12-17 Nec Corp 伝送ネットワーク、伝送装置、伝送ネットワークの回線切替方法及びプログラム
WO2010023510A1 (en) * 2008-08-26 2010-03-04 Alcatel Lucent Methods for establishing a traffic connection and an associated monitoring connection
WO2010023511A1 (en) * 2008-08-26 2010-03-04 Alcatel Lucent Methods for establishing a traffic connection and an associated monitoring connection
JP5402150B2 (ja) * 2009-03-27 2014-01-29 日本電気株式会社 ルーティング装置、通信システム、及びルーティング方法
US8908677B2 (en) * 2009-06-09 2014-12-09 Telefonaktiebolaget L M Ericsson (Publ) Communications network and a method in a communications network
EP2441219B1 (en) * 2009-06-09 2013-03-13 Telefonaktiebolaget L M Ericsson (publ) Power-saving functions in communications networks
CN101945308B (zh) * 2009-07-07 2013-05-08 中兴通讯股份有限公司 一种自动交换光网络中业务迁移的方法和装置
JP5392050B2 (ja) * 2009-12-11 2014-01-22 富士通株式会社 中継装置、中継方法および通信システム
JP5545720B2 (ja) * 2010-02-04 2014-07-09 富士通テレコムネットワークス株式会社 通信制御装置
JP5533112B2 (ja) * 2010-03-24 2014-06-25 富士通株式会社 監視装置，監視方法および監視プログラム
KR101136375B1 (ko) * 2010-07-12 2012-04-18 아주대학교산학협력단 멀티-홉 네트워크에서의 라우팅 경로 설정 방법 및 이를 위한 장치
EP2408128B1 (en) * 2010-07-15 2017-06-07 Alcatel Lucent Interworking agent adapted to interact between network and Precision Time Protocol entities
JP5617586B2 (ja) * 2010-12-10 2014-11-05 富士通株式会社 情報処理プログラム、中継装置及び中継管理装置
EP2472779A1 (en) * 2010-12-30 2012-07-04 Nokia Siemens Networks Oy Method for data communication networks and system
US8879385B2 (en) 2011-03-23 2014-11-04 Telefonaktiebolaget L M Ericsson (Publ) Use of sub path maintenance elements (SPMES) for multiprotocol label switching (MPLS) shared mesh protection
JP5857815B2 (ja) * 2012-03-14 2016-02-10 富士通株式会社 中継装置、中継処理のための情報処理方法及びプログラム、経路制御装置、経路制御のための情報処理方法及びプログラム、並びに情報処理システム
US8891360B2 (en) * 2012-05-04 2014-11-18 Infinera Corporation Optimal segment identification for shared mesh protection
US9178812B2 (en) 2013-06-05 2015-11-03 Cisco Technology, Inc. Stacking metadata contexts for service chains
US9444675B2 (en) * 2013-06-07 2016-09-13 Cisco Technology, Inc. Determining the operations performed along a service path/service chain
US9426059B2 (en) * 2013-06-10 2016-08-23 Fujitsu Limited Systems and methods for utilizing protection paths
KR101505624B1 (ko) 2014-01-03 2015-03-24 아주대학교산학협력단 상대적 접근 특성 기반의 이동성 예측 방법 및 그 장치
JP6357953B2 (ja) * 2014-08-04 2018-07-18 富士通株式会社 伝送装置およびアクティベーション方法
US9450916B2 (en) 2014-08-22 2016-09-20 Honeywell International Inc. Hardware assist for redundant ethernet network
US9590845B1 (en) * 2014-12-30 2017-03-07 Juniper Networks, Inc. Inter-area LDP node protection
US9590844B1 (en) 2014-12-30 2017-03-07 Juniper Networks, Inc. Intra-area LDP node protection
JP6523810B2 (ja) * 2015-06-16 2019-06-05 株式会社東芝 無線中継システム、無線中継システムの子機、及び、無線中継システムの復帰方法
BR112018000616A2 (pt) * 2015-07-15 2018-09-18 Nec Corp sistema de comunicação, dispositivo de comunicação e método para controlar o percurso de comunicação
US10476811B2 (en) * 2017-03-10 2019-11-12 Juniper Networks, Inc Apparatus, system, and method for providing node protection across label-switched paths that share labels

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003078553A (ja) * 2001-08-31 2003-03-14 Hitachi Ltd パケット転送方法
JP2003179628A (ja) * 2001-12-10 2003-06-27 Mitsubishi Electric Corp ラベル節減パスプロテクション通信装置
JP2003229888A (ja) * 2002-02-01 2003-08-15 Nec Corp ラベルスイッチングネットワーク及びそれに用いるラベルスイッチングパス設定方法
JP2003244202A (ja) * 2002-02-20 2003-08-29 Nippon Telegr & Teleph Corp <Ntt> パス切替システムと方法および通信装置とプログラム
JP2003338831A (ja) * 2002-05-22 2003-11-28 Nec Corp Ｍｐｌｓネットワークの切替え方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4647835B2 (ja) * 2001-05-17 2011-03-09 富士通株式会社 伝送装置及び障害回避方法
JP2004173136A (ja) * 2002-11-22 2004-06-17 Fujitsu Ltd ネットワーク管理装置
JP4617847B2 (ja) * 2004-11-04 2011-01-26 株式会社日立製作所 情報処理システム及びアクセス方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003078553A (ja) * 2001-08-31 2003-03-14 Hitachi Ltd パケット転送方法
JP2003179628A (ja) * 2001-12-10 2003-06-27 Mitsubishi Electric Corp ラベル節減パスプロテクション通信装置
JP2003229888A (ja) * 2002-02-01 2003-08-15 Nec Corp ラベルスイッチングネットワーク及びそれに用いるラベルスイッチングパス設定方法
JP2003244202A (ja) * 2002-02-20 2003-08-29 Nippon Telegr & Teleph Corp <Ntt> パス切替システムと方法および通信装置とプログラム
JP2003338831A (ja) * 2002-05-22 2003-11-28 Nec Corp Ｍｐｌｓネットワークの切替え方法

Also Published As

Publication number Publication date
US20060203720A1 (en) 2006-09-14
JP2006253927A (ja) 2006-09-21
US7710860B2 (en) 2010-05-04

Similar Documents

Publication Publication Date Title
JP4691372B2 (ja) データ中継装置およびデータ中継方法
US7590048B2 (en) Restoration and protection method and an apparatus thereof
EP1845656B1 (en) A method for implementing master and backup transmission path
JP4434867B2 (ja) Ｍｐｌｓネットワークシステム及びノード
JP4682887B2 (ja) 故障復旧方法およびノードならびにネットワーク
US20080304494A1 (en) Communication device
WO2009119571A1 (ja) 通信ネットワークシステム、通信装置、経路設計装置及び障害回復方法
US7978596B2 (en) Connection-oriented network node
CN105245452A (zh) 多协议标签交换流量工程隧道建立方法及设备
JP2010011039A (ja) ノード装置及び経路設定方法
KR101750844B1 (ko) 링형 네트워크 보호에 있어서 레이블을 자동적으로 분배하는 방법 및 시스템
CN113056891B (zh) 源路由隧道入节点保护
JP2010226393A (ja) 自律分散制御によるパス設定方法およびシステム並びに通信装置
US6848062B1 (en) Mesh protection service in a communications network
WO2015149358A1 (en) Apparatus and method for establishing a repair path
EP1921797B1 (en) Recovery method and apparatus for optical network lsp occuring abnormal delete
US20100054262A1 (en) Method and apparatus for setting communication paths in a network
CN101192990A (zh) 一种mpls网络中实现快速重路由的方法及设备及系统
JP4443442B2 (ja) 中継装置
JP4509885B2 (ja) シグナリング装置
US20060221816A1 (en) Transmission device and label allocation method
JP4392386B2 (ja) リカバリ方法、ならびに、そのリカバリ方法を実行する発信者ノード装置、中継ノード装置、および、着信者ノード装置
WO2015024163A1 (zh) 一种1+1端到端双向倒换的方法、系统和节点
JP2009188673A (ja) 伝送装置およびパス設定方法
JP2010233074A (ja) ルーティング装置、通信システム、及びルーティング方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070710

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090824

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091201

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101130

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110126

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: 20110215

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110221

R150 Certificate of patent or registration of utility model

Ref document number: 4691372

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140225

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees