JP5618946B2 - 通信装置および通信システム - Google Patents

通信装置および通信システム Download PDF

Info

Publication number
JP5618946B2
JP5618946B2 JP2011180299A JP2011180299A JP5618946B2 JP 5618946 B2 JP5618946 B2 JP 5618946B2 JP 2011180299 A JP2011180299 A JP 2011180299A JP 2011180299 A JP2011180299 A JP 2011180299A JP 5618946 B2 JP5618946 B2 JP 5618946B2
Authority
JP
Japan
Prior art keywords
failure
communication
erp
ospf
communication device
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.)
Active
Application number
JP2011180299A
Other languages
English (en)
Other versions
JP2013046090A (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.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
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 Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2011180299A priority Critical patent/JP5618946B2/ja
Publication of JP2013046090A publication Critical patent/JP2013046090A/ja
Application granted granted Critical
Publication of JP5618946B2 publication Critical patent/JP5618946B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42Loop networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42Loop networks
    • H04L12/427Loop networks with decentralised control
    • H04L12/43Loop networks with decentralised control with synchronous transmission, e.g. time division multiplex [TDM], slotted rings

Description

本発明は、リングネットワークを形成する通信装置に関する。
ERP(Ethernet Ring Protection)は、イーサOAM(Ether OAM)を使用したレイヤ2の冗長化/ループ防止プロトコルである(非特許文献1,2参照)。ERPはRPR(Resilient Packet Ring)やSDH(Synchronous Digital Hierarchy)と同等の障害時切替時間(具体的には50ミリ秒以下)を実現しており、電力・交通分野やメトロポリタンエリアネットワーク等の広域ネットワークの分野での利用が期待されている。
また、ERPネットワークを他サブネットと接続することは一般に広く行われており、その際にはOSPF(Open Shortest Path First)やRIP(Routing Information Protocol)などのレイヤ3ルーチングプロトコルが使用される(非特許文献3など参照)。また、仮想ルータやマルチキャストルーチングなどのレイヤ3機能が合わせて利用されるケースも多い。また、非特許文献4には、MLD(Multicast Listener Discovery)を使用してマルチキャスト制御を行い、かつマルチキャストパケットの送信端末がレイヤ3ネットワークに、リスナがレイヤ2ネットワークにそれぞれ存在する場合において、冗長化されているMLDプロキシの中からMLDクエリアを再選定する処理を高速に行うための技術が開示されている。
"G.8032/Y.1344 Ethernet ring protection switching", ITU-T, Jun.2008 "Y.1731 OAM functions and mechanisms for Ethernet based networks", ITU-T, Feb.2008 "RFC2453 RIP Version 2", Internet Engineering Task Force, Nov.1998 "イーサネットリングにおける障害時のMLDクエリアの高速再選定の検討", 落合徳彦, 濱田和樹, 小川裕二, 鹿島和幸, 山中秀昭, 電子情報通信学会2011年総合大会予稿集 B-6-94, Mar.2011
ERP上でレイヤ3プロトコルを動作させた場合、リンクダウンによる障害検出を用いることができないため、タイマベースによる障害検出を行う必要がある。タイマによる障害検出に必要な時間はプロトコルによって異なるものの、例えば、OSPFでは障害発生から検出までに40秒が必要となり、MLD−Proxy(Multicast Listener Discovery-Proxy)では最大255秒が必要となる。これは、ERPの50ミリ秒以内という障害検出時間と比較して非常に長く、ERPによるレイヤ2の経路切替は高速に実現しているにも関わらず、レイヤ3プロトコルの障害切替に必要とされる時間(障害発生から検出までの時間)が非常に長いため、障害が発生した後、End−to−Endで完全なサービスが利用できる状態に復帰するまでに時間がかかるという問題があった。
本発明は、上記に鑑みてなされたものであって、ERP上でレイヤ3プロトコルを動作させている状態において、障害発生からEnd−to−Endで完全なサービスが利用できる状態に復帰するまでの所要時間を短縮可能な通信装置および通信システムを得ることを目的とする。また、本発明を適用した通信装置と本発明を適用していない通信装置が混在するリングネットワークにおいても障害発生からサービス利用が可能な状態に復帰するまでの所要時間を短縮可能な通信装置および通信システムを得ることを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、リングネットワークを形成する通信装置であって、前記リングネットワークの障害検出を含むERP制御を行うERP処理手段と、前記リングネットワークのトポロジ情報が登録されたトポロジ情報テーブルと、前記ERP処理手段の動作監視を行うことにより前記リングネットワークを形成している各通信装置の識別情報および位置情報を収集し、当該収集した情報に基づいて前記トポロジ情報テーブルを更新するトポロジ情報テーブル更新手段と、前記ERP処理手段により障害が検出された場合に、当該検出された障害が装置障害とリンク障害のいずれに該当するかを前記トポロジ情報テーブルに基づいて判別し、装置障害の場合、障害が発生した装置を特定するとともに、当該特定結果を上位プロトコルに通知する障害箇所特定手段と、を備えることを特徴とする。
本発明によれば、レイヤ3プロトコルがネットワーク障害を短時間で検知することができ、障害発生から経路切替を実施するまでの所要時間を短縮できる。この結果、End−to−Endでのサービス停止時間を削減できる、という効果を奏する。
図1は、本発明にかかる通信装置においてトポロジ構成の認識処理を実行するブロックの構成例を示す図である。 図2は、ERPネットワークの一例を示す図である。 図3は、トポロジ情報テーブルの一例を示す図である。 図4は、実施の形態1の通信装置の構成例を示す図である。 図5は、実施の形態2の通信装置の構成例を示す図である。 図6は、実施の形態3の通信装置の構成例を示す図である。 図7は、実施の形態4の通信装置の構成例を示す図である。 図8は、実施の形態5の通信装置の構成例を示す図である。 図9は、実施の形態5の通信システムにおけるMLDクエリア選定動作の一例を示す図である。 図10は、実施の形態6の通信装置の構成例を示す図である。
以下に、本発明にかかる通信装置および通信システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
実施の形態1.
まず、本発明にかかる通信装置において、リングネットワークの構成(以下、トポロジ)を認識するためのブロックについて説明する。詳細については後述するが、本発明にかかる通信装置では、トポロジの情報を利用して障害発生箇所を特定し、障害回復までの所要時間を短縮化している。
図1は、本発明にかかる通信装置においてトポロジ構成の認識処理を実行するブロックの構成例を示す図である。図示したように、本発明にかかる通信装置は、ERPモジュール1、トポロジ情報収集モジュール2、物理ポート3およびトポロジ情報テーブル4を備えている。
ERP処理手段として動作するERPモジュール1は、上記非特許文献1に定義された各機能を具備しており、ERPネットワーク(ERPを適用したリングネットワーク)における経路制御と管理パケット送受信を行う。物理ポート3は、他の通信装置とのインタフェースであり、各種信号の送受信を行う。トポロジ情報テーブル4は、トポロジ情報収集モジュール2により生成されたトポロジ情報を格納するテーブルであり、トポロジ情報としてERPネットワークを形成している通信装置の識別情報(ID)および各通信装置の並び順の情報が登録される。識別情報としては、例えば、上記非特許文献2で定義されたLink Trace Requestパケット内に含まれるノードの識別情報(IPアドレス)を用いる。これ以外の識別情報を使用しても構わない。
トポロジ情報テーブル更新手段として動作するトポロジ情報収集モジュール2は、ERPモジュール1の動作監視を行ってトポロジ情報を収集するモジュールであり、Link Trace Request送信制御部21、Link Trace Response監視部22およびトポロジ情報計算部23を備えている。
Link Trace Request送信制御部21は、自装置がRPL(Ring Protection Link)オーナー(RPL Owner)に設定されている場合、事前に決定しておいたTTL値を持つリンクトレースリクエスト(Link Trace Request)を送信するよう、所定のタイミングでERPモジュールに指示を行う。なお、RPLオーナーとは、ループ発生を防止するためにポート閉塞を行っているノードを示す。事前に決定しておいたTTL値(リンクトレースリクエスト送信時に設定するTTLの初期値)は、ERPネットワークを形成しているノード(通信装置)の数よりも大きな値とし、また、ERPネットワーク内のノードのうち本発明を適用している全てのノードがTTL初期値を認識しているものとする。そのため、リンクトレースリクエストに設定可能なTTLの最大値として定義されている255を用いるのが最も適当である。ただし、TTL初期値を事前に全ノードが共有できておりかつERPネットワークを形成しているノード数よりも大きな値であればTTL=255とは異なる値を用いても良い。リンクトレースリクエストの送信指示は、例えば、他の通信装置と物理的に接続されたことを検出した場合に行う。物理的な接続を検出後、所定時間が経過するごとに再送信するよう指示を行うようにしてもよい。
Link Trace Response監視部22は、ERPモジュール1が受信したリンクトレースレスポンスの監視を行い、その結果得られた情報をResponse情報としてトポロジ情報計算部23に伝達する。監視対象とするリンクトレースレスポンスは、自装置からリンクトレースリクエストの送信元通信装置宛に送信するリンクトレースレスポンスと、他の通信装置から送信され、ERPモジュール1が中継するリンクトレースレスポンスとの双方とする。トポロジ情報計算部23に対しては、少なくとも、受信ポート、TTL値、およびリンクトレースレスポンスの送信元装置の識別情報(ID)の3情報を伝達する。
トポロジ情報計算部23は、Link Trace Response監視部22から伝送された情報に基づいて、トポロジ情報を算出する。具体的なトポロジ算出手順について、図2および図3を用いて説明する。図2は、5台のノードにより形成されたERPネットワークの一例を示す図であり、この図2に示したERPネットワークにおいて、各ノードがトポロジ情報を計算する手順を以下に示す。
ここで、ノードAがRPLオーナーであるとすると、ノードAは事前に決められたTTL値(図の例ではTTL=255)を用いてリンクトレースリクエスト101を送信する。ノードAにおいて、リンクトレースリクエスト101の送信は、トポロジ情報収集モジュール2内のLink Trace Request送信制御部21に指示に従い、ERPモジュール1が実行する。
リンクトレースリクエスト101を受信した各ノード(ノードB,C,D,E)は、上記非特許文献1の記載内容に従った動作を行い、受信したリンクトレースリクエスト101を中継(受信した側と反対側のノードへ転送)するとともに、リンクトレースレスポンス102を返送する。なお、図示した夫々の矢印に付与されたTTL値は、それぞれ、リンクトレースリクエスト101およびリンクトレースレスポンス102に設定されているTTL値を示す。RPLオーナー以外の各ノードにおいては、ERPモジュール1が、リンクトレースリクエスト101の受信および転送とリンクトレースレスポンス102の返送とを行う。また、図2では、ノードAからノードBの方向(右方向とする)へ送信するリンクトレースリクエスト101およびこれに対するリンクトレースレスポンス102のみを示しているが、実際には、左方向(ノードAからノードEの方向)に対しても、ノードAはリンクトレースリクエストを送信し、これを受信した各ノードは、リンクトレースリクエストの転送とリンクトレースレスポンスの返送を行う。
リンクトレースリクエスト101を受信した各ノードは、リンクトレースリクエスト101の転送およびリンクトレースレスポンス102による返答を行うとともに、自装置から送信するリンクトレースレスポンス102を含む全てのリンクトレースレスポンス102の監視を行う。なお、各ノードにおいて、リンクトレースレスポンス102の監視はリンクトポロジ情報収集モジュール2内のLink Trace Response監視部22が行う。監視の結果、各ノードのLink Trace Response監視部22が得る情報の例を図3に示す。図3は、図2に示したノードのうちノードCが取得した情報の一例(トポロジ情報テーブル4の構成例)を示している。
ノードCにおいて、トポロジ情報収集モジュール2のトポロジ情報計算部23は、始めに、自身が右方向(ノードD)および左方向(ノードB)に送信したリンクトレースレスポンスのTTLのうち、右方向に送信したものが252、左方向に送信したものが253であることから、RPLオーナーのノードAは自身から数えて右方向に2Hop、左方向に3hopの位置にあることを認識する。また、TTL=251かつノードBを示すIDを含んだ左方向へのリンクトレースレスポンスを受信(右側から受信)した場合、自身が左方向へ送信したリンクトレースレスポンスのTTL=252よりもTTLの値が一つ小さいことから、この信号の送信元のノードBが右に1Hopの位置にあると認識する。同様に、ノードDのIDを含んだリンクトレースレスポンスおよびノードEのIDを含んだリンクトレースレスポンスを受信することにより、その受信方法(リンクトレースレスポンスの送信方向)および設定されているTTL値から、ノードDは左に1Hopの位置、ノードEは左に2Hopの位置にあることを認識する。このようにして収集した情報を全て纏めることにより、ERPネットワークを形成している全てのノードの配置を把握することが出来る。
トポロジ情報計算部23は、各ノードの位置を把握すると、収集した情報と把握した位置の情報を図3に例示したような構成のトポロジ情報テーブル4に登録し、トポロジ情報テーブル4を更新する。図3において、“Request”はリンクトレースリクエスト、“Response”はリンクトレースレスポンスを示す。“右からのResponse”の列に記載されたTTL値のうち、送信元がノードC(自装置)以外のものは、他のノードから左方向に向けて(右回りに)送信されたリンクトレースレスポンスに設定されているTTL値を示している。“左からのResponse”の列に記載されたTTL値のうち、送信元がノードC(自装置)以外のものは、他のノードから右方向に向けて(左回りに)送信されたリンクトレースレスポンスに設定されているTTL値を示している。“ノードC(自装置)”の行に記載されたTTL値のうち、“右からのResponse”に対応するものは、左方向(右回り)に送信するリンクトレースレスポンス(左回りに送信されたリクエストに対するレスポンス)に設定されたTTL値、“左からのResponse”に対応するものは、右方向(左回り)に送信するリンクトレースレスポンス(右回りに送信されたリクエストに対するレスポンス)に設定されたTTL値である。
ここでは、ノードCを例にとって説明したが、ERPネットワーク内のノードのうち、本発明を適用した全ノードが同様の手順によりERPネットワークを形成しているノードの並び順情報を取得する。RPLオーナーであるノードAは、リンクトレースリクエストに対する各ノードからのリンクトレースレスポンスに設定されたTTL値を解析し、ERPネットワークを形成しているノードの並び順情報を取得する。なお、本発明を適用していないノードについては上記の処理を実行しない(ERPネットワークを形成しているノードの並び順情報を取得しない)が、リンクトレースリクエストを受信した際にリンクトレースレスポンスを返す処理は非特許文献1に記載された標準動作であり、本発明を適用していないノードがERPネットワーク内に混在していたとしても、本発明を適用したノードがトポロジ情報を取得する処理の妨げにならない。また、上記処理が本発明を適用していないノードの動作に悪影響を与えることもない。
このように、本発明を適用したノードは、ERPネットワークのトポロジ情報を簡単に取得することができる。なお、取得したトポロジ情報は、後述する障害発生箇所特定動作で使用するとともに、ネットワーク管理者から要求があった場合に提供する。
つづいて、本実施の形態の通信装置の特徴的な動作、具体的には、ERPネットワークにおける障害を検知した場合の動作について説明する。
図4は、実施の形態1の通信装置の構成例を示す図である。なお、説明を簡単化するために、特徴的な動作に関連する構成要素のみを記載している。
図示したように、本実施の形態の通信装置は、主たる構成として、ERPモジュール1、トポロジ情報収集モジュール2、物理ポート3、トポロジ情報テーブル4、OSPFモジュール5、障害箇所特定モジュール6および経路テーブル7を備えている。ERPモジュール1、トポロジ情報収集モジュール2、物理ポート3およびトポロジ情報テーブル4は図1に示したERPモジュール1、トポロジ情報収集モジュール2、物理ポート3およびトポロジ情報テーブル4と同じものであるため、詳細説明は省略する。本実施の形態では、レイヤ3ルーチングプロトコルとしてOSPF(Open Shortest Path First)を使用する。
障害箇所特定モジュール6は、障害発生箇所特定動作を実行する。具体的には、ERPモジュール1から提供された障害情報(ERPによる障害検知結果)と、トポロジ情報テーブル4に格納されたトポロジ情報とに基づき、障害が発生した装置を特定する。また、特定結果を示す情報(障害情報)をOSPFモジュール5に通知する。OSPFモジュール5に通知する障害情報は、例えば、障害が発生した通信装置のIPアドレスとする。
OSPFモジュール5は、OSPFによりレイヤ3ルーチングを行うモジュールであり、障害箇所特定モジュール6から障害情報(上記の特定結果を示す情報)を受け取った場合、受け取った障害情報を元に障害切替を実施する(経路テーブル7を更新する)。OSPFモジュール5は、障害発生装置が消滅したと看做して経路の再計算を行っても良いし、障害発生装置に接続されたリンクが全て切断された、もしくはパスコストが非常に大きな値になったと看做して経路の再計算を行っても良い。なお、この処理は装置障害の場合のみ実施し、リンク障害時には実施しない。リンク障害であるか装置障害であるかは、障害箇所特定モジュール6が、ERPモジュール1から通知された障害情報とトポロジ情報とに基づいて障害箇所を特定する際に判定する。すなわち、障害範囲に装置が含まれていれば装置障害、含まれていなければリンク障害とする。ERPネットワークにおいて障害が発生した場合、障害範囲の両端に位置する通信装置(障害を検知した通信装置)は、障害発生側のポートを閉塞し、障害が発生していない側に障害検知を示す信号(障害検知信号)を送信するので、障害箇所特定モジュール6は、右回りと左回りの2方向から受信する障害検知信号の送信元装置とトポロジ情報を比較することにより障害範囲に装置が含まれているかどうかを判別できる。例えば、図2に示した構成のERPネットワークにおいて、ノードDで障害が発生した場合には、ノードCおよびノードEが障害発生を検知し、障害検知信号を送信するので、これらの信号を受信した各ノードは、ノードDで障害が発生したと判断できる。ノードCとノードDの間のリンクで障害が発生した場合には、ノードCおよびノードDが障害検知信号を送信するので、これらの信号を受信した各ノードは、リンク障害が発生したと判断できる。
このように、本実施の形態の通信装置は、ERPのリンクトレースレスポンス送受信結果に基づいて、リングネットワークを形成している各通信装置の識別情報と位置情報(並び順の情報)を収集し、トポロジ情報としてトポロジ情報テーブルに登録して保持しておき、ERPにより障害が検出された場合、障害検出結果とトポロジ情報テーブルに登録されているトポロジ情報とに基づいて、障害の種別(装置障害とリンク障害のいずれか)を判別するとともに、装置障害の場合には障害が発生した装置を特定し、特定結果を上位レイヤ(レイヤ3)に通知することとした。これにより、レイヤ3プロトコル(OSPFプロトコル)がネットワーク障害を短時間で検知することができ、障害発生から経路切替を実施するまでの所要時間を短縮できる。この結果、End−to−Endでのサービス停止時間を短縮できる。
ところで、ERPネットワーク内に本発明を適用した装置と実施していない装置が混在している環境では、本実施の形態で示した上記の各処理を実行することにより、本発明を適用した装置におけるOSPF経路切替は高速に行われるが、本発明を適用していない装置はERPからの障害発生情報(レイヤ2からの障害発生情報)を取得することが出来ないため、レイヤ3では高速な障害検出を行うことは出来ない。ここで、仮に本発明を適用した装置がOSPFプロトコルを適用したネットワークの代表ルータである場合、代表ルータがERPからの情報により障害を検知すると、OSPFプロトコルに定義された処理の一つであるLSA(Link State Advertisement)交換をERPネットワーク内の他の装置と速やかに行うので、ERPネットワーク内の各装置が持つ経路情報が代表ルータの持つ情報と同期される。すなわち、ERPネットワークにおける代表ルータとして本発明を適用した装置を使用することにより、本発明を適用していない装置がERPネットワーク内に混在している場合においても、ERPネットワーク内の全機器のOSPF経路切替を高速化できる。従って、代表ルータが本発明を適用した装置の場合は、ERPネットワークに本発明を適用していない装置が混在していたとしても、ERPネットワーク内の全装置のOSPF経路切替を短時間で完了させることができる。
実施の形態2.
図5は、実施の形態2の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態1で説明した通信装置(図4参照)に対してOSPF障害検出通知モジュール8を追加した構成をとる。このOSPF障害検出通知モジュール8以外の各構成要素は実施の形態1の通信装置が備えていたものと同様であるため、OSPF障害検出通知モジュール8以外については説明を省略する。
OSPF障害検出通知モジュール8は、本発明を適用していない通信装置に障害切替を実施させるため、OSPFモジュール5から出力される障害情報に基づいて所定のOSPFプロトコルパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。OSPFモジュール5から出力される障害情報は、障害が発生した装置のIPアドレスまたはMACアドレスとする。OSPFプロトコルパケットの宛先は本発明を適用していない通信装置のみに限定してもよいし、発明を適用している通信装置を含む全ての通信装置としてもよい。通信装置のIPアドレスは、トポロジ情報テーブル4から得ることができる。
本実施の形態においては、ERPネットワーク内の装置において障害が発生した場合、障害が発生した装置以外の各装置のうち、本発明を適用した装置のうちのいずれか1台の装置が、障害が発生した装置からのパスが無効であることを示すパケットを送信することによって、本発明を適用していない装置に障害切替を実施させる。送信するパケットにおいては、例えば、障害発生装置に接続されたリンクのパスコストを65535とする。パスコスト65535はOSPFプロトコルにおいて到達不能を示す。また障害が発生していないリンクと比較して十分に大きなパスコストを設定するなどの方法により、当該パスを通過するパスが存在しなくなるようにする方法でも良く、またその他任意の方法を用いることも妨げない。ただし、パスコストを65535とする方法を用いる事で確実に障害発生を通知することが可能であるため、パスコストを65535とする方法を採ることが望ましい。障害発生装置に接続されたリンクのパスコストを65535としてOSPFプロトコルパケットを送信することにより、このパケットを受信した通信装置ではOSPF経路切替が実施され、正常な状態に復帰する。
障害が発生していない装置の中に本発明を適用した通信装置が複数存在している場合において、障害が発生した装置からのパスが無効であることを示すパケットを他の通信装置へ送信する通信装置1台を選出する方法としては、本発明を適用した通信装置同士で装置の情報を交換して送信担当装置を事前に選出しておく方法がある。また別の方法として、管理者等により固定設定を行う方法を用いても良く、その他任意の方法を用いても良い。
なお、OSPF障害検出通知モジュール8の機能をOSPFモジュール5に持たせてもよい。また、自装置がOSPFの代表ルータの場合、OSPF障害検出通知モジュール8は上記動作(本発明を適用していない通信装置に障害切替を実施させる目的でOSPFパケットを送信する動作)を行わなくてもよい。
このように、本実施の形態の通信装置は、実施の形態1の通信装置に対してOSPF障害検出通知モジュール8を追加し、障害発生を検知した場合には他の通信装置(本発明を適用しておらず、レイヤ2で検出した障害がレイヤ3プロトコルに通知されない通信装置)に対して、十分大きなパスコストを設定したOSPFプロトコルパケットを送信して擬似的に障害発生を通知し、障害切替を実施させることとした。これにより、OSPFプロトコルを適用したネットワークの代表ルータが本発明を適用した通信装置ではない場合においてもOSPF経路切替を高速に行うことが可能な通信システムを実現できる。もちろん、本実施の形態の通信装置を代表ルータとしても構わない。
実施の形態3.
図6は、実施の形態3の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態2で説明した通信装置(図5参照)のOSPFモジュール5およびOSPF障害検出通知モジュール8をRIPモジュール9およびRIP障害検出通知モジュール10にそれぞれ置き換えたものである。RIPモジュール9およびRIP障害検出通知モジュール10以外の各構成要素は実施の形態1の通信装置が備えていたものと同様であるため、説明を省略する。
RIPモジュール9は、RIP(Routing Information Protocol)によりレイヤ3ルーチングを行うモジュールであり、障害箇所特定モジュール6から障害情報を受け取った場合、受け取った障害情報を元に障害切替を実施する(経路テーブル7を更新する)。
RIP障害検出通知モジュール10は、本発明を適用していない通信装置に障害切替を実施させるため、RIPモジュール9から出力される障害情報に基づいて所定のRIPパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。RIPモジュール9から出力される障害情報は、障害が発生した装置のIPアドレスまたはMACアドレスとする。
本実施の形態においては、ERPネットワーク内の装置において障害が発生した場合、障害が発生した装置以外の各装置のうち、本発明を適用した装置のうちのいずれか1台の装置が、障害が発生した装置からのパスが無効であることを示すパケットを送信することによって、本発明を適用していない装置に障害切替を実施させる。送信するパケットにおいては、例えば、障害発生装置までのメトリックを16とする。メトリック16はRIPにおいて到達不能を示す。RIPにおいては、上記非特許文献3に従った動作の場合、自装置以外の各装置から広告された経路情報の全てを保持しているわけではないため、広告された全ての経路情報を取得する手順が必要となる。例えば、本実施の形態では、障害が発生する前の定常状態において各装置が広告している全ての経路情報を各装置内に保持しておくことにより経路情報を事前に収集する。ERPネットワークを形成する装置は256台以下と規定されているため、全経路情報を保持しておくことは一般的に容易である。
また、上記非特許文献3に従った動作を行う通信装置においても当該装置をNext Hopとしている装置の情報は保持しているため、その情報に限ってメトリック16の経路情報を送信する形式とすることも可能である。ただしこの方法によると全ての経路が削除されないため、一部経路の復旧に必要な処理時間が長くことから、全ての情報を保持する手法の使用が推奨される。
障害が発生していない装置の中に本発明を適用した通信装置が複数存在している場合において、障害が発生した装置からのパスが無効であることを示すパケットを他の通信装置へ送信する通信装置1台を選出する方法としては、本発明を適用した通信装置同士で自ブリッジの情報を交換して送信担当装置を事前に選出する方法がある。また別の方法として、管理者等により固定設定を行う方法を用いても良く、その他任意の方法を用いても良い。
このように、本実施の形態の通信装置は、実施の形態2の通信装置のOSPFモジュール5およびOSPF障害検出通知モジュール8をRIPモジュール9およびRIP障害検出通知モジュール10にそれぞれ置き換えたので、RIPによりレイヤ3ルーチングを行う場合においても、実施の形態2の通信システムと同様に、レイヤ3の経路切替を高速に行うことができる。
実施の形態4.
図7は、実施の形態4の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態2で説明した通信装置(図5参照)のOSPFモジュール5、経路テーブル7およびOSPF障害検出通知モジュール8をVRRPモジュール11およびVRRP障害検出通知モジュール12に置き換えたものである。VRRPモジュール11およびVRRP障害検出通知モジュール12以外の各構成要素は実施の形態1の通信装置が備えていたものと同様であるため、説明を省略する。
本実施の形態では、ERPネットワークを形成している通信装置がルータとして動作し、かつ図7に示した通信装置(本発明を適用した通信装置)と本発明を適用していない通信装置が混在し、ERPネットワークを形成している各通信装置(ルータ)は、VRRP(Virtual Router Redundancy Protocol)に従い、1台以上の他の通信装置とともに仮想的な1台のルータとして動作する場合を想定する。
VRRPモジュール11は、障害箇所特定モジュール6から障害情報を受け取るなどした場合、自装置がマスタールータとして動作するか否かを決定する。また、マスタールータとして動作する場合には、ルーチング制御を実施する。
VRRP障害検出通知モジュール12は、マスタールータの再選定(マスタールータとして動作するか否かの判断)を他の通信装置に実行させるため、VRRPモジュール11から出力される障害情報に基づいて所定のVRRPパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。VRRPモジュール11から出力される障害情報は障害が発生した装置のIPアドレスまたはMACアドレスとする。
本実施の形態においては、ERPネットワーク内の装置において障害が発生した場合、障害が発生した装置以外の各装置のうち、本発明を適用した装置のうちのいずれか1台の装置が、障害が発生した装置からのパスが無効であることを示すパケットを送信することによって、本発明を適用していない装置にマスタールータの再選定を実施させる。具体的には、Priority=0としたVRRPアドバタイズを送信する。Priority=0としたVRRPアドバタイズを送信することにより、これを受信した通信装置はマスタールータの選定動作を実施する。なお、VRRPにおいてはPriority=0の情報を複数回受信しても動作に影響は無いため、ERPネットワーク内に本発明を適用した装置が複数台ある場合に、複数の装置からPriority=0のVRRPアドバタイズを送信するようにしても構わない。
このように、本実施の形態の通信装置は、ERPネットワークを形成するとともに仮想ルータを形成し、ERPネットワークにおいて装置障害を検出した場合、マスタールータとして動作するか否かの判定(マスタールータの再選定)を行うとともに、Priority=0としたVRRPアドバタイズを他の通信装置へ送信してマスタールータの再選定を実施させることとした。これにより、マスタールータとして動作している通信装置で障害が発生した場合のマスタールータ切替を迅速に行うことができ、End−to−Endでのサービス停止時間を短縮できる。
実施の形態5.
図8は、実施の形態5の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態2で説明した通信装置(図5参照)のOSPFモジュール5、経路テーブル7およびOSPF障害検出通知モジュール8をMLD−Proxyモジュール13に置き換えたものである。MLD−Proxyモジュール13以外の各構成要素は実施の形態1の通信装置が備えていたものと同様であるため、説明を省略する。
本実施の形態では、ERPネットワークを形成している各通信装置が非特許文献4に示したMLD(Multicast Listener Discovery)プロキシとして動作し、かつ図8に示した通信装置(本発明を適用した通信装置)と本発明を適用していない通信装置が混在している場合を想定する。
本実施の形態にかかる通信装置において、MLD−Proxyモジュール13は、障害箇所特定モジュール6により特定された障害発生装置がMLDクエリアであった場合、非特許文献4の記載に従ってMLDクエリアの再選定を実施する。
ここで、本発明を適用していない通信装置では、タイマベースによる障害検出を行うため、非特許文献4にも記載しているように、MLDクエリアに選定されている装置で障害が発生した場合の障害検出までの所要時間が非常に長くなる。そのため、本発明を適用している通信装置がMLDクエリアの再選定を実施した後、しばらく経ってからMLDクエリアの再選定を実施することになり、図9に示すように、1度の障害発生に対してMLDクエリアの切替が複数回発生する可能性がある。しかし、2度目以降のMLDクエリア選定時にはEnd−to−Endでのマルチキャスト送信停止は発生しないため、本発明を適用した通信装置と適用していない通信装置が混在している場合におけるマルチキャストパケットの通信停止時間を、非混在の場合(本発明を適用した通信装置のみでERPネットワークが形成されている場合)と同程度の数百ミリ秒とすることが出来る。
図9に示した制御動作(MLDクエリア選定動作)例では、ERP障害検出直後のクエリア再選定(1)において、本発明を適用した通信装置(図8に示した構成の通信装置)の中で優先度が最も高いものがクエリアとして動作を開始し、マルチキャストパケットの中継が再開される。その後、本発明を適用していない通信装置がMLD−Proxyプロトコルにおいて定義された障害検出処理に従って障害発生を検知すると、クエリア再選定(2)が実施され、本発明を適用していない装置の中の最高優先度の装置がクエリア動作を開始するが、マルチキャストパケット中継停止は発生しない。なお、図9では、本発明を適用していない通信装置の中に最高優先度の装置が含まれているため、クエリア再選定(2)においてクエリアの切替(本発明を適用していない装置の中で最高優先度のものが新たなクエリアとして動作を開始するとともに本発明を適用した装置の中で最高優先度の装置がクエリア動作を停止する処理)が発生しているが、本発明を適用した通信装置の中に最高優先度の装置が含まれている場合には、クエリア再選定(2)において、クエリアの切替は発生しない。
このように、本実施の形態の通信装置は、MLDプロキシとして動作し、ERPネットワークにおいて装置障害を検出した場合、MLDクエリアの再選定を行うこととした。これにより、MLDクエリアで障害が発生した場合に、MLDクエリア切替を迅速に行うことができ、End−to−Endでのサービス停止時間を短縮できる。
実施の形態6.
図10は、実施の形態6の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態2で説明した通信装置(図5参照)のOSPFモジュール5およびOSPF障害検出通知モジュール8をPIM−SMモジュール14およびPIM−SM障害検出通知モジュール15に置き換えたものである。PIM−SMモジュール14およびPIM−SM障害検出通知モジュール15以外の各構成要素は実施の形態1の通信装置が備えていたものと同様であるため、説明を省略する。
本実施の形態では、ERPネットワークを形成している通信装置がPIM−SM(Protocol Independent Multicast-Sparse Mode)プロトコルに従ってマルチキャストパケットの中継を行う場合を想定する。
PIM−SMモジュール14は、PIM−SMによりマルチキャストパケットのルーチングを行うモジュールであり、障害箇所特定モジュール6から障害情報を受け取った場合、受け取った障害情報を元に、必要に応じて障害切替を実施する(経路テーブル7を更新する)。PIM−SM障害検出通知モジュール15は、PIM−SMモジュール14により障害切替の実施が必要と判断された場合に、本発明を適用していない通信装置に障害切替を実施させるため、PIM−SMモジュール14から出力される障害情報に基づいて所定のPIM−SMプロトコルパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。
PIM−SMにおいては、同一サブネット内においてマルチキャストパケットの中継を担当するForwarderと、PIM制御メッセージの送信を担当する代表ルータ(DR)がそれぞれ選定される。本実施の形態のERPネットワークにおいては、装置障害が発生し、かつ障害が発生した装置がForwarderもしくは代表ルータであった場合、それぞれ以下に示す手順により障害切替を実施する。障害が発生した装置がForwarderと代表ルータのいずれとも異なる場合、障害がマルチキャストパケットの送信に影響することは無いので、以下に示す処理は不要である。また、障害が発生した装置がForwarderかつ代表ルータとなっている場合もあり、その場合は以下に示す2つの手順の両方を実施する。
(障害が発生した通信装置がForwarderである場合の動作)
この場合、本発明を適用しかつ障害が発生していない通信装置のうちの中の1台において、PIM−SM障害検出通知モジュール15が、障害が発生した通信装置のPreferenceおよびmetricの値を非常に低優先としたPIM-Assertパケットを生成し、障害が発生した装置のIPアドレスを使用して送信を行う。なお、障害が発生した装置のIPアドレスは、PIM−SMモジュール14からPIM−SM障害検出通知モジュール15へ障害情報として通知される。当該PIM-Assertパケットで用いるpreference及びmetricの値はERPネットワークを形成している各装置に設定されたいずれのものよりも低優先な値とする。通常は他の装置が使用しているpreference及びmetricを知ることは出来ないため、PIM-Assertプロトコルで定められたpreference及びmetricの値域内において最も低優先の値を使うことが望ましい。しかし、これに制限するものではなく十分低優先であり上記条件を満たすものであれば他の値を用いても良い。なお、前記パケットを送信する装置はERPネットワーク内に1台と限定する必要は無く、本発明を適用した2台以上の装置または全ての装置が送信処理を行っても良い。
(障害が発生した通信装置が代表ルータである場合の動作)
この場合、本発明を適用しかつ障害が発生していない通信装置のうちの中の1台において、PIM−SM障害検出通知モジュール15が、障害が発生した通信装置のDR優先度を低くしたHelloパケットを生成し、障害が発生した装置のアドレスを使用して送信を行う。当該Helloパケットで用いる優先度の値はERPネットワークを形成しているどの装置に設定された値よりも低優先の値とする。通常は他装置が使用しているDR優先度の値を知ることは出来ないため、DP優先度の値域内において最も低優先の値を使うことが望ましい。しかし、これに制限するものではなく十分低優先の値であり上記条件を満たすものであれば他の値を用いても良い。なお、前記パケットを送信する装置はERPネットワーク内に1台と限定する必要は無く、本発明を適用した2台以上の装置または全ての装置が送信処理を行っても良い。
このように、本実施の形態の通信装置は、PIM−SMによりマルチキャストパケットのルーチングを行うこととし、ERPネットワークにおいて装置障害を検出した場合、検出した装置がForwarderまたは代表ルータの場合、障害切替を実施するとともに、本発明を適用していない通信装置に障害切替を実施させるためのPIM−SMプロトコルパケットを生成して送信することとした。これにより、PIM−SMのForwarderまたは代表ルータで障害が発生した場合の障害切替を迅速に行うことができ、End−to−Endでのサービス停止時間を短縮できる。
なお、上述した各実施の形態のうち、同時並列的に使用可能なL3プロトコルを適用しているもの同士については、複合して実施しても良い。すなわち、実施の形態2と3を複合させることはできないが、その他の組み合わせは実施可能である。たとえば、実施の形態2の通信装置(図5参照)に対して、実施の形態4の通信装置(図7参照)が備えていたVRRPモジュール11およびVRRP障害検出通知モジュール12を追加した構成としてもよい。
以上のように、本発明にかかる通信装置は、ERPネットワークを形成する通信装置として有用である。
1 ERPモジュール
2 トポロジ情報収集モジュール
3 物理ポート
4 トポロジ情報テーブル
5 OSPFモジュール
6 障害箇所特定モジュール
7 経路テーブル
8 OSPF障害検出通知モジュール
9 RIPモジュール
10 RIP障害検出通知モジュール
11 VRRPモジュール
12 VRRP障害検出通知モジュール
13 MLD−Proxyモジュール
14 PIM−SMモジュール
15 PIM−SM障害検出通知モジュール
21 Link Trace Request送信制御部
22 Link Trace Response監視部
23 トポロジ情報計算部
101 リンクトレースリクエスト
102 リンクトレースレスポンス

Claims (16)

  1. リングネットワークを形成する通信装置であって、
    前記リングネットワークの障害検出を含むERP制御を行うERP処理手段と、
    前記リングネットワークのトポロジ情報が登録されたトポロジ情報テーブルと、
    前記ERP処理手段の動作監視を行うことにより前記リングネットワークを形成している各通信装置の識別情報および位置情報を収集し、当該収集した情報に基づいて前記トポロジ情報テーブルを更新するトポロジ情報テーブル更新手段と、
    前記ERP処理手段により障害が検出された場合に、当該検出された障害が装置障害とリンク障害のいずれに該当するかを前記トポロジ情報テーブルに基づいて判別し、装置障害の場合、障害が発生した装置を特定するとともに、当該特定した装置を上位プロトコルに通知する障害箇所特定手段と、
    を備えることを特徴とする通信装置。
  2. トポロジ情報テーブル更新手段は、
    システムで予め規定され、前記リングネットワークを形成している各通信装置が共有しているTTL値が初期値として設定されたリンクトレースリクエストに対する応答として送信されたリンクトレースレスポンスを前記ERP処理手段が受信した場合に、当該受信したリンクトレースレスポンスに設定されているTTL値および送信元装置の識別情報と、リンクトレースレスポンスを受信したポートの情報とを取得する情報取得手段と、
    前記情報取得手段により取得されたTTL値およびポートの情報に基づいて、前記リンクトレースレスポンスの送信元装置の位置を特定し、当該特定した位置および前記取得された識別情報を対応付けて前記トポロジ情報テーブルに登録する装置位置特定手段と、
    を備えることを特徴とする請求項1に記載の通信装置。
  3. トポロジ情報テーブル更新手段は、
    自装置がRPLオーナーとされている場合に、システムで予め規定され、前記リングネットワークを形成している各通信装置が共有しているTTL値、を設定してリンクトレースリクエストを送信するよう前記ERP処理手段に指示を行う送信指示手段、
    をさらに備えることを特徴とする請求項2に記載の通信装置。
  4. 前記上位プロトコルをOSPFとし、
    OSPFによりL3ルーチングを行う通信システムの代表ルータとして動作することを特徴とする請求項1、2または3に記載の通信装置。
  5. 前記上位プロトコルをOSPFとし、
    前記ERP処理手段により検出された障害が装置障害である場合に、前記障害箇所特定手段により特定された障害発生装置までのパスコストを到達不能であることを示す値、もしくは障害が発生していない経路のパスコストと比較して十分に大きな値としたOSPFプロトコルパケットを他の通信装置へ送信するOSPFプロトコルパケット送信手段、
    をさらに備えることを特徴とする請求項1、2または3に記載の通信装置。
  6. 前記上位プロトコルをRIPとし、
    前記ERP処理手段により検出された障害が装置障害である場合に、前記障害箇所特定手段により特定された障害発生装置までのメトリックを到達不能であることを示す値、もしくは障害が発生していない経路のメトリックと比較して十分に大きな値としたERPパケットを他の通信装置へ送信するERPパケット送信手段、
    をさらに備えることを特徴とする請求項1、2または3に記載の通信装置。
  7. 前記上位プロトコルをVRRPとし、かつ、前記リングネットワークを形成している他の通信装置とともに仮想ルータを形成し、
    前記ERP処理手段により検出された障害が装置障害である場合に、優先度を「0」に設定したVRRPアドバタイズパケットを前記リングネットワーク内の他の通信装置へ送信するVRRPパケット送信手段、
    をさらに備えることを特徴とする請求項1、2または3に記載の通信装置。
  8. 前記上位プロトコルをMLDとし、かつMLDプロキシとして動作し、
    前記ERP処理手段により検出された障害が装置障害であり、かつ前記障害箇所特定手段により特定された装置がMLDクエリアである場合に、MLDクエリアの再選定動作を実施するMLDクエリア再選定手段、
    をさらに備えることを特徴とする請求項1、2または3に記載の通信装置。
  9. 前記上位プロトコルをPIM−SMとし、
    前記ERP処理手段により検出された障害が装置障害であり、かつ前記障害箇所特定手段により特定された装置がPIM−SMのForwarderである場合に、前記特定された装置のPreferenceおよびmetricを前記リングネットワーク内の他のいずれの通信装置よりも低い値に設定したPIM-Assertパケットを前記特定された装置のIPアドレスを使用して送信するPIM-Assertパケット送信手段、
    をさらに備えることを特徴とする請求項1、2または3に記載の通信装置。
  10. 前記上位プロトコルをPIM−SMとし、
    前記ERP処理手段により検出された障害が装置障害であり、かつ前記障害箇所特定手段により特定された装置がPIM−SMの代表ルータである場合に、前記特定された装置のDR優先度を最も低い優先度に設定したHelloパケットを前記特定された装置のIPアドレスを使用して送信するHelloパケット送信手段、
    をさらに備えることを特徴とする請求項1〜3、9のいずれか一つに記載の通信装置。
  11. OSPFによりL3ルーチングを行う通信システムであって、
    請求項1、2または3に記載の通信装置をOSPFの代表ルータとし、当該通信装置の障害箇所特定手段が前記特定した装置を通知する上位プロトコルをOSPFとすることを特徴とする通信システム。
  12. OSPFによりL3ルーチングを行う通信システムであって、
    請求項5に記載の通信装置を1台以上備えることを特徴とする通信システム。
  13. RIPによりL3ルーチングを行う通信システムであって、
    請求項6に記載の通信装置を1台以上備えることを特徴とする通信システム。
  14. 請求項7に記載の通信装置を1台以上含む複数の通信装置により形成された仮想ルータを備えることを特徴とする通信システム。
  15. MLDによりL3マルチキャスト制御を行う通信システムであって、
    MLDプロキシとして動作する通信装置として、請求項8に記載の通信装置を1台以上備えることを特徴とする通信システム。
  16. PIM−SMによりL3マルチキャストルーチングを行う通信システムであって、
    請求項9または10に記載の通信装置を1台以上備えることを特徴とする通信システム。
JP2011180299A 2011-08-22 2011-08-22 通信装置および通信システム Active JP5618946B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011180299A JP5618946B2 (ja) 2011-08-22 2011-08-22 通信装置および通信システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011180299A JP5618946B2 (ja) 2011-08-22 2011-08-22 通信装置および通信システム

Publications (2)

Publication Number Publication Date
JP2013046090A JP2013046090A (ja) 2013-03-04
JP5618946B2 true JP5618946B2 (ja) 2014-11-05

Family

ID=48009690

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011180299A Active JP5618946B2 (ja) 2011-08-22 2011-08-22 通信装置および通信システム

Country Status (1)

Country Link
JP (1) JP5618946B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6443909B2 (ja) * 2014-04-02 2018-12-26 Necフィールディング株式会社 障害検出装置、障害検出システム、障害検出方法、および、プログラム
JP6683090B2 (ja) 2016-09-26 2020-04-15 株式会社デンソー 中継装置
JP6797050B2 (ja) * 2017-03-09 2020-12-09 三菱電機株式会社 パケット交換装置
JP6466630B1 (ja) * 2018-04-27 2019-02-06 三菱電機株式会社 監視装置、ネットワークシステム、トポロジ管理方法および監視プログラム
JP6833144B2 (ja) * 2018-12-28 2021-02-24 三菱電機株式会社 監視装置、ネットワークシステム、トポロジ管理方法および監視プログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001268101A (ja) * 2000-03-17 2001-09-28 Toshiba Corp ネットワークシステム
JP3956685B2 (ja) * 2001-05-31 2007-08-08 古河電気工業株式会社 ネットワーク間接続方法、仮想ネットワーク間接続装置およびその装置を用いたネットワーク間接続システム
JP4034782B2 (ja) * 2003-04-24 2008-01-16 富士通株式会社 リング間接続装置、及びデータ転送制御方法
JP4421458B2 (ja) * 2004-11-30 2010-02-24 三菱電機株式会社 ネットワークノード装置およびその経路情報更新方法
JP4569377B2 (ja) * 2005-05-13 2010-10-27 パナソニック株式会社 ルータ装置及びルータ監視方法
EP1983713A1 (en) * 2007-04-16 2008-10-22 Nokia Siemens Networks Oy Method for operating a network element and according device as well as communication system comprising such device
JP5340062B2 (ja) * 2009-07-14 2013-11-13 アラクサラネットワークス株式会社 ネットワーク中継装置およびネットワークシステム
JP2011146977A (ja) * 2010-01-15 2011-07-28 Mitsubishi Electric Corp 経路切替方法、通信装置および通信システム

Also Published As

Publication number Publication date
JP2013046090A (ja) 2013-03-04

Similar Documents

Publication Publication Date Title
JP5899305B2 (ja) ネットワークノードを動作させる技術
EP3151488B1 (en) Multicast only fast re-route over remote loop-free alternate backup path
US8218429B2 (en) Method and device for multicast traffic redundancy protection
JP4743201B2 (ja) パケットリングネットワークシステム、パケットリング間の接続方法、およびリング間接続ノード
JP5876493B2 (ja) ネットワーク障害から復旧するための高速フラッディングベースの高速収束
JP5484590B2 (ja) 擬似ワイヤに基づいてサービストラヒックを処理するための方法、デバイスおよびシステム
US8665711B2 (en) Fast restoration for provider edge node and access link failures
JP2009284486A (ja) リングネットワークルーティング方法およびリングネットワークノード
CN112422307B (zh) Evpn和vpls共存双活的方法、设备及系统
WO2012068996A1 (zh) 链路状态检测方法和装置
WO2012130034A1 (zh) 一种vpls快速重路由方法和设备
JP2009303092A (ja) ネットワーク装置および回線切替方法
JP5618946B2 (ja) 通信装置および通信システム
WO2012171378A1 (zh) 解决vpls接入l3故障切换导致断流的方法及路由器
JP6295137B2 (ja) 中継システムおよびスイッチ装置
US8929200B2 (en) Communication device, communication system, and communication method
GB2494385A (en) Transmitting and Forwarding Data
Huynh et al. RRR: Rapid ring recovery submillisecond decentralized recovery for ethernet ring
WO2011011934A1 (zh) 一种以太网隧道分段保护方法和装置
CN107547330B (zh) 一种传输业务数据的方法和节点设备
JP2011146977A (ja) 経路切替方法、通信装置および通信システム
CN111885630B (zh) 数据传输方法及通信装置
JP5506714B2 (ja) ネットワーク接続装置
JP2013046164A (ja) ネットワークシステムおよびネットワーク故障回避方法
EP2769504A1 (en) Reconnection in a transmission tree

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20131118

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140424

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140430

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140616

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140916

R150 Certificate of patent or registration of utility model

Ref document number: 5618946

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250