説明

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

【課題】リングネットワークにおいて、障害発生から復帰までの所要時間を短縮可能な通信装置を提供する。
【解決手段】リングネットワークの障害検出を含むERP(Ethernet Ring Protection)制御を行うERPモジュール1と、リングネットワークのトポロジ情報が登録されたトポロジ情報テーブル4と、ERPモジュール1の動作監視を行うことによりリングネットワークを形成している各通信装置の識別情報および位置情報を収集し、収集した情報に基づいてトポロジ情報テーブル4を更新するトポロジ情報収集モジュール2と、ERPモジュール1により障害が検出された場合に、検出された障害が装置障害とリンク障害のいずれに該当するかをトポロジ情報テーブル4に基づいて判別し、装置障害の場合、障害が発生した装置を特定するとともに、特定結果を上位プロトコルに通知する障害箇所特定モジュール6と、を備える。

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

【特許請求の範囲】
【請求項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台以上備えることを特徴とする通信システム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate


【公開番号】特開2013−46090(P2013−46090A)
【公開日】平成25年3月4日(2013.3.4)
【国際特許分類】
【出願番号】特願2011−180299(P2011−180299)
【出願日】平成23年8月22日(2011.8.22)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ETHERNET
2.イーサネット
【出願人】(000006013)三菱電機株式会社 (33,312)
【Fターム(参考)】