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

Abstract

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

Description

本発明は、リングネットワークを形成する通信装置に関する。

ＥＲＰ（Ethernet Ring Protection）は、イーサＯＡＭ（Ether OAM）を使用したレイヤ２の冗長化／ループ防止プロトコルである（非特許文献１，２参照）。ＥＲＰはＲＰＲ（Resilient Packet Ring）やＳＤＨ（Synchronous Digital Hierarchy）と同等の障害時切替時間（具体的には５０ミリ秒以下）を実現しており、電力・交通分野やメトロポリタンエリアネットワーク等の広域ネットワークの分野での利用が期待されている。

また、ＥＲＰネットワークを他サブネットと接続することは一般に広く行われており、その際にはＯＳＰＦ（Open Shortest Path First）やＲＩＰ（Routing Information Protocol）などのレイヤ３ルーチングプロトコルが使用される（非特許文献３など参照）。また、仮想ルータやマルチキャストルーチングなどのレイヤ３機能が合わせて利用されるケースも多い。また、非特許文献４には、ＭＬＤ（Multicast Listener Discovery）を使用してマルチキャスト制御を行い、かつマルチキャストパケットの送信端末がレイヤ３ネットワークに、リスナがレイヤ２ネットワークにそれぞれ存在する場合において、冗長化されているＭＬＤプロキシの中からＭＬＤクエリアを再選定する処理を高速に行うための技術が開示されている。

"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

ＥＲＰ上でレイヤ３プロトコルを動作させた場合、リンクダウンによる障害検出を用いることができないため、タイマベースによる障害検出を行う必要がある。タイマによる障害検出に必要な時間はプロトコルによって異なるものの、例えば、ＯＳＰＦでは障害発生から検出までに４０秒が必要となり、ＭＬＤ−Ｐｒｏｘｙ（Multicast Listener Discovery-Proxy）では最大２５５秒が必要となる。これは、ＥＲＰの５０ミリ秒以内という障害検出時間と比較して非常に長く、ＥＲＰによるレイヤ２の経路切替は高速に実現しているにも関わらず、レイヤ３プロトコルの障害切替に必要とされる時間（障害発生から検出までの時間）が非常に長いため、障害が発生した後、Ｅｎｄ−ｔｏ−Ｅｎｄで完全なサービスが利用できる状態に復帰するまでに時間がかかるという問題があった。

本発明は、上記に鑑みてなされたものであって、ＥＲＰ上でレイヤ３プロトコルを動作させている状態において、障害発生からＥｎｄ−ｔｏ−Ｅｎｄで完全なサービスが利用できる状態に復帰するまでの所要時間を短縮可能な通信装置および通信システムを得ることを目的とする。また、本発明を適用した通信装置と本発明を適用していない通信装置が混在するリングネットワークにおいても障害発生からサービス利用が可能な状態に復帰するまでの所要時間を短縮可能な通信装置および通信システムを得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、リングネットワークを形成する通信装置であって、前記リングネットワークの障害検出を含むＥＲＰ制御を行うＥＲＰ処理手段と、前記リングネットワークのトポロジ情報が登録されたトポロジ情報テーブルと、前記ＥＲＰ処理手段の動作監視を行うことにより前記リングネットワークを形成している各通信装置の識別情報および位置情報を収集し、当該収集した情報に基づいて前記トポロジ情報テーブルを更新するトポロジ情報テーブル更新手段と、前記ＥＲＰ処理手段により障害が検出された場合に、当該検出された障害が装置障害とリンク障害のいずれに該当するかを前記トポロジ情報テーブルに基づいて判別し、装置障害の場合、障害が発生した装置を特定するとともに、当該特定結果を上位プロトコルに通知する障害箇所特定手段と、を備えることを特徴とする。

本発明によれば、レイヤ３プロトコルがネットワーク障害を短時間で検知することができ、障害発生から経路切替を実施するまでの所要時間を短縮できる。この結果、Ｅｎｄ−ｔｏ−Ｅｎｄでのサービス停止時間を削減できる、という効果を奏する。

図１は、本発明にかかる通信装置においてトポロジ構成の認識処理を実行するブロックの構成例を示す図である。 図２は、ＥＲＰネットワークの一例を示す図である。 図３は、トポロジ情報テーブルの一例を示す図である。 図４は、実施の形態１の通信装置の構成例を示す図である。 図５は、実施の形態２の通信装置の構成例を示す図である。 図６は、実施の形態３の通信装置の構成例を示す図である。 図７は、実施の形態４の通信装置の構成例を示す図である。 図８は、実施の形態５の通信装置の構成例を示す図である。 図９は、実施の形態５の通信システムにおけるＭＬＤクエリア選定動作の一例を示す図である。 図１０は、実施の形態６の通信装置の構成例を示す図である。

以下に、本発明にかかる通信装置および通信システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態１．
まず、本発明にかかる通信装置において、リングネットワークの構成（以下、トポロジ）を認識するためのブロックについて説明する。詳細については後述するが、本発明にかかる通信装置では、トポロジの情報を利用して障害発生箇所を特定し、障害回復までの所要時間を短縮化している。

図１は、本発明にかかる通信装置においてトポロジ構成の認識処理を実行するブロックの構成例を示す図である。図示したように、本発明にかかる通信装置は、ＥＲＰモジュール１、トポロジ情報収集モジュール２、物理ポート３およびトポロジ情報テーブル４を備えている。

ＥＲＰ処理手段として動作するＥＲＰモジュール１は、上記非特許文献１に定義された各機能を具備しており、ＥＲＰネットワーク（ＥＲＰを適用したリングネットワーク）における経路制御と管理パケット送受信を行う。物理ポート３は、他の通信装置とのインタフェースであり、各種信号の送受信を行う。トポロジ情報テーブル４は、トポロジ情報収集モジュール２により生成されたトポロジ情報を格納するテーブルであり、トポロジ情報としてＥＲＰネットワークを形成している通信装置の識別情報（ＩＤ）および各通信装置の並び順の情報が登録される。識別情報としては、例えば、上記非特許文献２で定義されたLink Trace Requestパケット内に含まれるノードの識別情報（ＩＰアドレス）を用いる。これ以外の識別情報を使用しても構わない。

トポロジ情報テーブル更新手段として動作するトポロジ情報収集モジュール２は、ＥＲＰモジュール１の動作監視を行ってトポロジ情報を収集するモジュールであり、Link Trace Request送信制御部２１、Link Trace Response監視部２２およびトポロジ情報計算部２３を備えている。

Link Trace Request送信制御部２１は、自装置がＲＰＬ（Ring Protection Link）オーナー（RPL Owner）に設定されている場合、事前に決定しておいたＴＴＬ値を持つリンクトレースリクエスト（Link Trace Request）を送信するよう、所定のタイミングでＥＲＰモジュールに指示を行う。なお、ＲＰＬオーナーとは、ループ発生を防止するためにポート閉塞を行っているノードを示す。事前に決定しておいたＴＴＬ値（リンクトレースリクエスト送信時に設定するＴＴＬの初期値）は、ＥＲＰネットワークを形成しているノード（通信装置）の数よりも大きな値とし、また、ＥＲＰネットワーク内のノードのうち本発明を適用している全てのノードがＴＴＬ初期値を認識しているものとする。そのため、リンクトレースリクエストに設定可能なＴＴＬの最大値として定義されている２５５を用いるのが最も適当である。ただし、ＴＴＬ初期値を事前に全ノードが共有できておりかつＥＲＰネットワークを形成しているノード数よりも大きな値であればＴＴＬ＝２５５とは異なる値を用いても良い。リンクトレースリクエストの送信指示は、例えば、他の通信装置と物理的に接続されたことを検出した場合に行う。物理的な接続を検出後、所定時間が経過するごとに再送信するよう指示を行うようにしてもよい。

Link Trace Response監視部２２は、ＥＲＰモジュール１が受信したリンクトレースレスポンスの監視を行い、その結果得られた情報をＲｅｓｐｏｎｓｅ情報としてトポロジ情報計算部２３に伝達する。監視対象とするリンクトレースレスポンスは、自装置からリンクトレースリクエストの送信元通信装置宛に送信するリンクトレースレスポンスと、他の通信装置から送信され、ＥＲＰモジュール１が中継するリンクトレースレスポンスとの双方とする。トポロジ情報計算部２３に対しては、少なくとも、受信ポート、ＴＴＬ値、およびリンクトレースレスポンスの送信元装置の識別情報（ＩＤ）の３情報を伝達する。

トポロジ情報計算部２３は、Link Trace Response監視部２２から伝送された情報に基づいて、トポロジ情報を算出する。具体的なトポロジ算出手順について、図２および図３を用いて説明する。図２は、５台のノードにより形成されたＥＲＰネットワークの一例を示す図であり、この図２に示したＥＲＰネットワークにおいて、各ノードがトポロジ情報を計算する手順を以下に示す。

ここで、ノードＡがＲＰＬオーナーであるとすると、ノードＡは事前に決められたＴＴＬ値（図の例ではＴＴＬ＝２５５）を用いてリンクトレースリクエスト１０１を送信する。ノードＡにおいて、リンクトレースリクエスト１０１の送信は、トポロジ情報収集モジュール２内のLink Trace Request送信制御部２１に指示に従い、ＥＲＰモジュール１が実行する。

リンクトレースリクエスト１０１を受信した各ノード（ノードＢ，Ｃ，Ｄ，Ｅ）は、上記非特許文献１の記載内容に従った動作を行い、受信したリンクトレースリクエスト１０１を中継（受信した側と反対側のノードへ転送）するとともに、リンクトレースレスポンス１０２を返送する。なお、図示した夫々の矢印に付与されたＴＴＬ値は、それぞれ、リンクトレースリクエスト１０１およびリンクトレースレスポンス１０２に設定されているＴＴＬ値を示す。ＲＰＬオーナー以外の各ノードにおいては、ＥＲＰモジュール１が、リンクトレースリクエスト１０１の受信および転送とリンクトレースレスポンス１０２の返送とを行う。また、図２では、ノードＡからノードＢの方向（右方向とする）へ送信するリンクトレースリクエスト１０１およびこれに対するリンクトレースレスポンス１０２のみを示しているが、実際には、左方向（ノードＡからノードＥの方向）に対しても、ノードＡはリンクトレースリクエストを送信し、これを受信した各ノードは、リンクトレースリクエストの転送とリンクトレースレスポンスの返送を行う。

リンクトレースリクエスト１０１を受信した各ノードは、リンクトレースリクエスト１０１の転送およびリンクトレースレスポンス１０２による返答を行うとともに、自装置から送信するリンクトレースレスポンス１０２を含む全てのリンクトレースレスポンス１０２の監視を行う。なお、各ノードにおいて、リンクトレースレスポンス１０２の監視はリンクトポロジ情報収集モジュール２内のLink Trace Response監視部２２が行う。監視の結果、各ノードのLink Trace Response監視部２２が得る情報の例を図３に示す。図３は、図２に示したノードのうちノードＣが取得した情報の一例（トポロジ情報テーブル４の構成例）を示している。

ノードＣにおいて、トポロジ情報収集モジュール２のトポロジ情報計算部２３は、始めに、自身が右方向（ノードＤ）および左方向（ノードＢ）に送信したリンクトレースレスポンスのＴＴＬのうち、右方向に送信したものが２５２、左方向に送信したものが２５３であることから、ＲＰＬオーナーのノードＡは自身から数えて右方向に２Ｈｏｐ、左方向に３ｈｏｐの位置にあることを認識する。また、ＴＴＬ＝２５１かつノードＢを示すＩＤを含んだ左方向へのリンクトレースレスポンスを受信（右側から受信）した場合、自身が左方向へ送信したリンクトレースレスポンスのＴＴＬ＝２５２よりもＴＴＬの値が一つ小さいことから、この信号の送信元のノードＢが右に１Ｈｏｐの位置にあると認識する。同様に、ノードＤのＩＤを含んだリンクトレースレスポンスおよびノードＥのＩＤを含んだリンクトレースレスポンスを受信することにより、その受信方法（リンクトレースレスポンスの送信方向）および設定されているＴＴＬ値から、ノードＤは左に１Ｈｏｐの位置、ノードＥは左に２Ｈｏｐの位置にあることを認識する。このようにして収集した情報を全て纏めることにより、ＥＲＰネットワークを形成している全てのノードの配置を把握することが出来る。

トポロジ情報計算部２３は、各ノードの位置を把握すると、収集した情報と把握した位置の情報を図３に例示したような構成のトポロジ情報テーブル４に登録し、トポロジ情報テーブル４を更新する。図３において、“Request”はリンクトレースリクエスト、“Response”はリンクトレースレスポンスを示す。“右からのResponse”の列に記載されたＴＴＬ値のうち、送信元がノードＣ（自装置）以外のものは、他のノードから左方向に向けて（右回りに）送信されたリンクトレースレスポンスに設定されているＴＴＬ値を示している。“左からのResponse”の列に記載されたＴＴＬ値のうち、送信元がノードＣ（自装置）以外のものは、他のノードから右方向に向けて（左回りに）送信されたリンクトレースレスポンスに設定されているＴＴＬ値を示している。“ノードＣ（自装置）”の行に記載されたＴＴＬ値のうち、“右からのResponse”に対応するものは、左方向（右回り）に送信するリンクトレースレスポンス（左回りに送信されたリクエストに対するレスポンス）に設定されたＴＴＬ値、“左からのResponse”に対応するものは、右方向（左回り）に送信するリンクトレースレスポンス（右回りに送信されたリクエストに対するレスポンス）に設定されたＴＴＬ値である。

ここでは、ノードＣを例にとって説明したが、ＥＲＰネットワーク内のノードのうち、本発明を適用した全ノードが同様の手順によりＥＲＰネットワークを形成しているノードの並び順情報を取得する。ＲＰＬオーナーであるノードＡは、リンクトレースリクエストに対する各ノードからのリンクトレースレスポンスに設定されたＴＴＬ値を解析し、ＥＲＰネットワークを形成しているノードの並び順情報を取得する。なお、本発明を適用していないノードについては上記の処理を実行しない（ＥＲＰネットワークを形成しているノードの並び順情報を取得しない）が、リンクトレースリクエストを受信した際にリンクトレースレスポンスを返す処理は非特許文献１に記載された標準動作であり、本発明を適用していないノードがＥＲＰネットワーク内に混在していたとしても、本発明を適用したノードがトポロジ情報を取得する処理の妨げにならない。また、上記処理が本発明を適用していないノードの動作に悪影響を与えることもない。

このように、本発明を適用したノードは、ＥＲＰネットワークのトポロジ情報を簡単に取得することができる。なお、取得したトポロジ情報は、後述する障害発生箇所特定動作で使用するとともに、ネットワーク管理者から要求があった場合に提供する。

つづいて、本実施の形態の通信装置の特徴的な動作、具体的には、ＥＲＰネットワークにおける障害を検知した場合の動作について説明する。

図４は、実施の形態１の通信装置の構成例を示す図である。なお、説明を簡単化するために、特徴的な動作に関連する構成要素のみを記載している。

図示したように、本実施の形態の通信装置は、主たる構成として、ＥＲＰモジュール１、トポロジ情報収集モジュール２、物理ポート３、トポロジ情報テーブル４、ＯＳＰＦモジュール５、障害箇所特定モジュール６および経路テーブル７を備えている。ＥＲＰモジュール１、トポロジ情報収集モジュール２、物理ポート３およびトポロジ情報テーブル４は図１に示したＥＲＰモジュール１、トポロジ情報収集モジュール２、物理ポート３およびトポロジ情報テーブル４と同じものであるため、詳細説明は省略する。本実施の形態では、レイヤ３ルーチングプロトコルとしてＯＳＰＦ（Open Shortest Path First）を使用する。

障害箇所特定モジュール６は、障害発生箇所特定動作を実行する。具体的には、ＥＲＰモジュール１から提供された障害情報（ＥＲＰによる障害検知結果）と、トポロジ情報テーブル４に格納されたトポロジ情報とに基づき、障害が発生した装置を特定する。また、特定結果を示す情報（障害情報）をＯＳＰＦモジュール５に通知する。ＯＳＰＦモジュール５に通知する障害情報は、例えば、障害が発生した通信装置のＩＰアドレスとする。

ＯＳＰＦモジュール５は、ＯＳＰＦによりレイヤ３ルーチングを行うモジュールであり、障害箇所特定モジュール６から障害情報（上記の特定結果を示す情報）を受け取った場合、受け取った障害情報を元に障害切替を実施する（経路テーブル７を更新する）。ＯＳＰＦモジュール５は、障害発生装置が消滅したと看做して経路の再計算を行っても良いし、障害発生装置に接続されたリンクが全て切断された、もしくはパスコストが非常に大きな値になったと看做して経路の再計算を行っても良い。なお、この処理は装置障害の場合のみ実施し、リンク障害時には実施しない。リンク障害であるか装置障害であるかは、障害箇所特定モジュール６が、ＥＲＰモジュール１から通知された障害情報とトポロジ情報とに基づいて障害箇所を特定する際に判定する。すなわち、障害範囲に装置が含まれていれば装置障害、含まれていなければリンク障害とする。ＥＲＰネットワークにおいて障害が発生した場合、障害範囲の両端に位置する通信装置（障害を検知した通信装置）は、障害発生側のポートを閉塞し、障害が発生していない側に障害検知を示す信号（障害検知信号）を送信するので、障害箇所特定モジュール６は、右回りと左回りの２方向から受信する障害検知信号の送信元装置とトポロジ情報を比較することにより障害範囲に装置が含まれているかどうかを判別できる。例えば、図２に示した構成のＥＲＰネットワークにおいて、ノードＤで障害が発生した場合には、ノードＣおよびノードＥが障害発生を検知し、障害検知信号を送信するので、これらの信号を受信した各ノードは、ノードＤで障害が発生したと判断できる。ノードＣとノードＤの間のリンクで障害が発生した場合には、ノードＣおよびノードＤが障害検知信号を送信するので、これらの信号を受信した各ノードは、リンク障害が発生したと判断できる。

このように、本実施の形態の通信装置は、ＥＲＰのリンクトレースレスポンス送受信結果に基づいて、リングネットワークを形成している各通信装置の識別情報と位置情報（並び順の情報）を収集し、トポロジ情報としてトポロジ情報テーブルに登録して保持しておき、ＥＲＰにより障害が検出された場合、障害検出結果とトポロジ情報テーブルに登録されているトポロジ情報とに基づいて、障害の種別（装置障害とリンク障害のいずれか）を判別するとともに、装置障害の場合には障害が発生した装置を特定し、特定結果を上位レイヤ（レイヤ３）に通知することとした。これにより、レイヤ３プロトコル（ＯＳＰＦプロトコル）がネットワーク障害を短時間で検知することができ、障害発生から経路切替を実施するまでの所要時間を短縮できる。この結果、Ｅｎｄ−ｔｏ−Ｅｎｄでのサービス停止時間を短縮できる。

ところで、ＥＲＰネットワーク内に本発明を適用した装置と実施していない装置が混在している環境では、本実施の形態で示した上記の各処理を実行することにより、本発明を適用した装置におけるＯＳＰＦ経路切替は高速に行われるが、本発明を適用していない装置はＥＲＰからの障害発生情報（レイヤ２からの障害発生情報）を取得することが出来ないため、レイヤ３では高速な障害検出を行うことは出来ない。ここで、仮に本発明を適用した装置がＯＳＰＦプロトコルを適用したネットワークの代表ルータである場合、代表ルータがＥＲＰからの情報により障害を検知すると、ＯＳＰＦプロトコルに定義された処理の一つであるＬＳＡ（Link State Advertisement）交換をＥＲＰネットワーク内の他の装置と速やかに行うので、ＥＲＰネットワーク内の各装置が持つ経路情報が代表ルータの持つ情報と同期される。すなわち、ＥＲＰネットワークにおける代表ルータとして本発明を適用した装置を使用することにより、本発明を適用していない装置がＥＲＰネットワーク内に混在している場合においても、ＥＲＰネットワーク内の全機器のＯＳＰＦ経路切替を高速化できる。従って、代表ルータが本発明を適用した装置の場合は、ＥＲＰネットワークに本発明を適用していない装置が混在していたとしても、ＥＲＰネットワーク内の全装置のＯＳＰＦ経路切替を短時間で完了させることができる。

実施の形態２．
図５は、実施の形態２の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態１で説明した通信装置（図４参照）に対してＯＳＰＦ障害検出通知モジュール８を追加した構成をとる。このＯＳＰＦ障害検出通知モジュール８以外の各構成要素は実施の形態１の通信装置が備えていたものと同様であるため、ＯＳＰＦ障害検出通知モジュール８以外については説明を省略する。

ＯＳＰＦ障害検出通知モジュール８は、本発明を適用していない通信装置に障害切替を実施させるため、ＯＳＰＦモジュール５から出力される障害情報に基づいて所定のＯＳＰＦプロトコルパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。ＯＳＰＦモジュール５から出力される障害情報は、障害が発生した装置のＩＰアドレスまたはＭＡＣアドレスとする。ＯＳＰＦプロトコルパケットの宛先は本発明を適用していない通信装置のみに限定してもよいし、発明を適用している通信装置を含む全ての通信装置としてもよい。通信装置のＩＰアドレスは、トポロジ情報テーブル４から得ることができる。

本実施の形態においては、ＥＲＰネットワーク内の装置において障害が発生した場合、障害が発生した装置以外の各装置のうち、本発明を適用した装置のうちのいずれか１台の装置が、障害が発生した装置からのパスが無効であることを示すパケットを送信することによって、本発明を適用していない装置に障害切替を実施させる。送信するパケットにおいては、例えば、障害発生装置に接続されたリンクのパスコストを６５５３５とする。パスコスト６５５３５はＯＳＰＦプロトコルにおいて到達不能を示す。また障害が発生していないリンクと比較して十分に大きなパスコストを設定するなどの方法により、当該パスを通過するパスが存在しなくなるようにする方法でも良く、またその他任意の方法を用いることも妨げない。ただし、パスコストを６５５３５とする方法を用いる事で確実に障害発生を通知することが可能であるため、パスコストを６５５３５とする方法を採ることが望ましい。障害発生装置に接続されたリンクのパスコストを６５５３５としてＯＳＰＦプロトコルパケットを送信することにより、このパケットを受信した通信装置ではＯＳＰＦ経路切替が実施され、正常な状態に復帰する。

障害が発生していない装置の中に本発明を適用した通信装置が複数存在している場合において、障害が発生した装置からのパスが無効であることを示すパケットを他の通信装置へ送信する通信装置１台を選出する方法としては、本発明を適用した通信装置同士で装置の情報を交換して送信担当装置を事前に選出しておく方法がある。また別の方法として、管理者等により固定設定を行う方法を用いても良く、その他任意の方法を用いても良い。

なお、ＯＳＰＦ障害検出通知モジュール８の機能をＯＳＰＦモジュール５に持たせてもよい。また、自装置がＯＳＰＦの代表ルータの場合、ＯＳＰＦ障害検出通知モジュール８は上記動作（本発明を適用していない通信装置に障害切替を実施させる目的でＯＳＰＦパケットを送信する動作）を行わなくてもよい。

このように、本実施の形態の通信装置は、実施の形態１の通信装置に対してＯＳＰＦ障害検出通知モジュール８を追加し、障害発生を検知した場合には他の通信装置（本発明を適用しておらず、レイヤ２で検出した障害がレイヤ３プロトコルに通知されない通信装置）に対して、十分大きなパスコストを設定したＯＳＰＦプロトコルパケットを送信して擬似的に障害発生を通知し、障害切替を実施させることとした。これにより、ＯＳＰＦプロトコルを適用したネットワークの代表ルータが本発明を適用した通信装置ではない場合においてもＯＳＰＦ経路切替を高速に行うことが可能な通信システムを実現できる。もちろん、本実施の形態の通信装置を代表ルータとしても構わない。

実施の形態３．
図６は、実施の形態３の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態２で説明した通信装置（図５参照）のＯＳＰＦモジュール５およびＯＳＰＦ障害検出通知モジュール８をＲＩＰモジュール９およびＲＩＰ障害検出通知モジュール１０にそれぞれ置き換えたものである。ＲＩＰモジュール９およびＲＩＰ障害検出通知モジュール１０以外の各構成要素は実施の形態１の通信装置が備えていたものと同様であるため、説明を省略する。

ＲＩＰモジュール９は、ＲＩＰ（Routing Information Protocol）によりレイヤ３ルーチングを行うモジュールであり、障害箇所特定モジュール６から障害情報を受け取った場合、受け取った障害情報を元に障害切替を実施する（経路テーブル７を更新する）。

ＲＩＰ障害検出通知モジュール１０は、本発明を適用していない通信装置に障害切替を実施させるため、ＲＩＰモジュール９から出力される障害情報に基づいて所定のＲＩＰパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。ＲＩＰモジュール９から出力される障害情報は、障害が発生した装置のＩＰアドレスまたはＭＡＣアドレスとする。

本実施の形態においては、ＥＲＰネットワーク内の装置において障害が発生した場合、障害が発生した装置以外の各装置のうち、本発明を適用した装置のうちのいずれか１台の装置が、障害が発生した装置からのパスが無効であることを示すパケットを送信することによって、本発明を適用していない装置に障害切替を実施させる。送信するパケットにおいては、例えば、障害発生装置までのメトリックを１６とする。メトリック１６はＲＩＰにおいて到達不能を示す。ＲＩＰにおいては、上記非特許文献３に従った動作の場合、自装置以外の各装置から広告された経路情報の全てを保持しているわけではないため、広告された全ての経路情報を取得する手順が必要となる。例えば、本実施の形態では、障害が発生する前の定常状態において各装置が広告している全ての経路情報を各装置内に保持しておくことにより経路情報を事前に収集する。ＥＲＰネットワークを形成する装置は２５６台以下と規定されているため、全経路情報を保持しておくことは一般的に容易である。

また、上記非特許文献３に従った動作を行う通信装置においても当該装置をNext Hopとしている装置の情報は保持しているため、その情報に限ってメトリック１６の経路情報を送信する形式とすることも可能である。ただしこの方法によると全ての経路が削除されないため、一部経路の復旧に必要な処理時間が長くことから、全ての情報を保持する手法の使用が推奨される。

障害が発生していない装置の中に本発明を適用した通信装置が複数存在している場合において、障害が発生した装置からのパスが無効であることを示すパケットを他の通信装置へ送信する通信装置１台を選出する方法としては、本発明を適用した通信装置同士で自ブリッジの情報を交換して送信担当装置を事前に選出する方法がある。また別の方法として、管理者等により固定設定を行う方法を用いても良く、その他任意の方法を用いても良い。

このように、本実施の形態の通信装置は、実施の形態２の通信装置のＯＳＰＦモジュール５およびＯＳＰＦ障害検出通知モジュール８をＲＩＰモジュール９およびＲＩＰ障害検出通知モジュール１０にそれぞれ置き換えたので、ＲＩＰによりレイヤ３ルーチングを行う場合においても、実施の形態２の通信システムと同様に、レイヤ３の経路切替を高速に行うことができる。

実施の形態４．
図７は、実施の形態４の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態２で説明した通信装置（図５参照）のＯＳＰＦモジュール５、経路テーブル７およびＯＳＰＦ障害検出通知モジュール８をＶＲＲＰモジュール１１およびＶＲＲＰ障害検出通知モジュール１２に置き換えたものである。ＶＲＲＰモジュール１１およびＶＲＲＰ障害検出通知モジュール１２以外の各構成要素は実施の形態１の通信装置が備えていたものと同様であるため、説明を省略する。

本実施の形態では、ＥＲＰネットワークを形成している通信装置がルータとして動作し、かつ図７に示した通信装置（本発明を適用した通信装置）と本発明を適用していない通信装置が混在し、ＥＲＰネットワークを形成している各通信装置（ルータ）は、ＶＲＲＰ（Virtual Router Redundancy Protocol）に従い、１台以上の他の通信装置とともに仮想的な１台のルータとして動作する場合を想定する。

ＶＲＲＰモジュール１１は、障害箇所特定モジュール６から障害情報を受け取るなどした場合、自装置がマスタールータとして動作するか否かを決定する。また、マスタールータとして動作する場合には、ルーチング制御を実施する。

ＶＲＲＰ障害検出通知モジュール１２は、マスタールータの再選定（マスタールータとして動作するか否かの判断）を他の通信装置に実行させるため、ＶＲＲＰモジュール１１から出力される障害情報に基づいて所定のＶＲＲＰパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。ＶＲＲＰモジュール１１から出力される障害情報は障害が発生した装置のＩＰアドレスまたはＭＡＣアドレスとする。

本実施の形態においては、ＥＲＰネットワーク内の装置において障害が発生した場合、障害が発生した装置以外の各装置のうち、本発明を適用した装置のうちのいずれか１台の装置が、障害が発生した装置からのパスが無効であることを示すパケットを送信することによって、本発明を適用していない装置にマスタールータの再選定を実施させる。具体的には、Priority=0としたＶＲＲＰアドバタイズを送信する。Priority=0としたＶＲＲＰアドバタイズを送信することにより、これを受信した通信装置はマスタールータの選定動作を実施する。なお、ＶＲＲＰにおいてはPriority=0の情報を複数回受信しても動作に影響は無いため、ＥＲＰネットワーク内に本発明を適用した装置が複数台ある場合に、複数の装置からPriority=0のＶＲＲＰアドバタイズを送信するようにしても構わない。

このように、本実施の形態の通信装置は、ＥＲＰネットワークを形成するとともに仮想ルータを形成し、ＥＲＰネットワークにおいて装置障害を検出した場合、マスタールータとして動作するか否かの判定（マスタールータの再選定）を行うとともに、Priority=0としたＶＲＲＰアドバタイズを他の通信装置へ送信してマスタールータの再選定を実施させることとした。これにより、マスタールータとして動作している通信装置で障害が発生した場合のマスタールータ切替を迅速に行うことができ、Ｅｎｄ−ｔｏ−Ｅｎｄでのサービス停止時間を短縮できる。

実施の形態５．
図８は、実施の形態５の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態２で説明した通信装置（図５参照）のＯＳＰＦモジュール５、経路テーブル７およびＯＳＰＦ障害検出通知モジュール８をＭＬＤ−Ｐｒｏｘｙモジュール１３に置き換えたものである。ＭＬＤ−Ｐｒｏｘｙモジュール１３以外の各構成要素は実施の形態１の通信装置が備えていたものと同様であるため、説明を省略する。

本実施の形態では、ＥＲＰネットワークを形成している各通信装置が非特許文献４に示したＭＬＤ（Multicast Listener Discovery）プロキシとして動作し、かつ図８に示した通信装置（本発明を適用した通信装置）と本発明を適用していない通信装置が混在している場合を想定する。

本実施の形態にかかる通信装置において、ＭＬＤ−Ｐｒｏｘｙモジュール１３は、障害箇所特定モジュール６により特定された障害発生装置がＭＬＤクエリアであった場合、非特許文献４の記載に従ってＭＬＤクエリアの再選定を実施する。

ここで、本発明を適用していない通信装置では、タイマベースによる障害検出を行うため、非特許文献４にも記載しているように、ＭＬＤクエリアに選定されている装置で障害が発生した場合の障害検出までの所要時間が非常に長くなる。そのため、本発明を適用している通信装置がＭＬＤクエリアの再選定を実施した後、しばらく経ってからＭＬＤクエリアの再選定を実施することになり、図９に示すように、１度の障害発生に対してＭＬＤクエリアの切替が複数回発生する可能性がある。しかし、２度目以降のＭＬＤクエリア選定時にはＥｎｄ−ｔｏ−Ｅｎｄでのマルチキャスト送信停止は発生しないため、本発明を適用した通信装置と適用していない通信装置が混在している場合におけるマルチキャストパケットの通信停止時間を、非混在の場合（本発明を適用した通信装置のみでＥＲＰネットワークが形成されている場合）と同程度の数百ミリ秒とすることが出来る。

図９に示した制御動作（ＭＬＤクエリア選定動作）例では、ＥＲＰ障害検出直後のクエリア再選定（１）において、本発明を適用した通信装置（図８に示した構成の通信装置）の中で優先度が最も高いものがクエリアとして動作を開始し、マルチキャストパケットの中継が再開される。その後、本発明を適用していない通信装置がＭＬＤ−Ｐｒｏｘｙプロトコルにおいて定義された障害検出処理に従って障害発生を検知すると、クエリア再選定（２）が実施され、本発明を適用していない装置の中の最高優先度の装置がクエリア動作を開始するが、マルチキャストパケット中継停止は発生しない。なお、図９では、本発明を適用していない通信装置の中に最高優先度の装置が含まれているため、クエリア再選定（２）においてクエリアの切替（本発明を適用していない装置の中で最高優先度のものが新たなクエリアとして動作を開始するとともに本発明を適用した装置の中で最高優先度の装置がクエリア動作を停止する処理）が発生しているが、本発明を適用した通信装置の中に最高優先度の装置が含まれている場合には、クエリア再選定（２）において、クエリアの切替は発生しない。

このように、本実施の形態の通信装置は、ＭＬＤプロキシとして動作し、ＥＲＰネットワークにおいて装置障害を検出した場合、ＭＬＤクエリアの再選定を行うこととした。これにより、ＭＬＤクエリアで障害が発生した場合に、ＭＬＤクエリア切替を迅速に行うことができ、Ｅｎｄ−ｔｏ−Ｅｎｄでのサービス停止時間を短縮できる。

実施の形態６．
図１０は、実施の形態６の通信装置の構成例を示す図である。本実施の形態の通信装置は、実施の形態２で説明した通信装置（図５参照）のＯＳＰＦモジュール５およびＯＳＰＦ障害検出通知モジュール８をＰＩＭ−ＳＭモジュール１４およびＰＩＭ−ＳＭ障害検出通知モジュール１５に置き換えたものである。ＰＩＭ−ＳＭモジュール１４およびＰＩＭ−ＳＭ障害検出通知モジュール１５以外の各構成要素は実施の形態１の通信装置が備えていたものと同様であるため、説明を省略する。

本実施の形態では、ＥＲＰネットワークを形成している通信装置がＰＩＭ−ＳＭ（Protocol Independent Multicast-Sparse Mode）プロトコルに従ってマルチキャストパケットの中継を行う場合を想定する。

ＰＩＭ−ＳＭモジュール１４は、ＰＩＭ−ＳＭによりマルチキャストパケットのルーチングを行うモジュールであり、障害箇所特定モジュール６から障害情報を受け取った場合、受け取った障害情報を元に、必要に応じて障害切替を実施する（経路テーブル７を更新する）。ＰＩＭ−ＳＭ障害検出通知モジュール１５は、ＰＩＭ−ＳＭモジュール１４により障害切替の実施が必要と判断された場合に、本発明を適用していない通信装置に障害切替を実施させるため、ＰＩＭ−ＳＭモジュール１４から出力される障害情報に基づいて所定のＰＩＭ−ＳＭプロトコルパケットを生成し、本発明を適用していない通信装置を含む他の通信装置に向けて送信する。

ＰＩＭ−ＳＭにおいては、同一サブネット内においてマルチキャストパケットの中継を担当するForwarderと、ＰＩＭ制御メッセージの送信を担当する代表ルータ（ＤＲ）がそれぞれ選定される。本実施の形態のＥＲＰネットワークにおいては、装置障害が発生し、かつ障害が発生した装置がForwarderもしくは代表ルータであった場合、それぞれ以下に示す手順により障害切替を実施する。障害が発生した装置がForwarderと代表ルータのいずれとも異なる場合、障害がマルチキャストパケットの送信に影響することは無いので、以下に示す処理は不要である。また、障害が発生した装置がForwarderかつ代表ルータとなっている場合もあり、その場合は以下に示す２つの手順の両方を実施する。

（障害が発生した通信装置がForwarderである場合の動作）
この場合、本発明を適用しかつ障害が発生していない通信装置のうちの中の１台において、ＰＩＭ−ＳＭ障害検出通知モジュール１５が、障害が発生した通信装置のPreferenceおよびmetricの値を非常に低優先としたPIM-Assertパケットを生成し、障害が発生した装置のＩＰアドレスを使用して送信を行う。なお、障害が発生した装置のＩＰアドレスは、ＰＩＭ−ＳＭモジュール１４からＰＩＭ−ＳＭ障害検出通知モジュール１５へ障害情報として通知される。当該PIM-Assertパケットで用いるpreference及びmetricの値はＥＲＰネットワークを形成している各装置に設定されたいずれのものよりも低優先な値とする。通常は他の装置が使用しているpreference及びmetricを知ることは出来ないため、PIM-Assertプロトコルで定められたpreference及びmetricの値域内において最も低優先の値を使うことが望ましい。しかし、これに制限するものではなく十分低優先であり上記条件を満たすものであれば他の値を用いても良い。なお、前記パケットを送信する装置はＥＲＰネットワーク内に１台と限定する必要は無く、本発明を適用した２台以上の装置または全ての装置が送信処理を行っても良い。

（障害が発生した通信装置が代表ルータである場合の動作）
この場合、本発明を適用しかつ障害が発生していない通信装置のうちの中の１台において、ＰＩＭ−ＳＭ障害検出通知モジュール１５が、障害が発生した通信装置のDR優先度を低くしたHelloパケットを生成し、障害が発生した装置のアドレスを使用して送信を行う。当該Helloパケットで用いる優先度の値はＥＲＰネットワークを形成しているどの装置に設定された値よりも低優先の値とする。通常は他装置が使用しているDR優先度の値を知ることは出来ないため、DP優先度の値域内において最も低優先の値を使うことが望ましい。しかし、これに制限するものではなく十分低優先の値であり上記条件を満たすものであれば他の値を用いても良い。なお、前記パケットを送信する装置はＥＲＰネットワーク内に１台と限定する必要は無く、本発明を適用した２台以上の装置または全ての装置が送信処理を行っても良い。

このように、本実施の形態の通信装置は、ＰＩＭ−ＳＭによりマルチキャストパケットのルーチングを行うこととし、ＥＲＰネットワークにおいて装置障害を検出した場合、検出した装置がForwarderまたは代表ルータの場合、障害切替を実施するとともに、本発明を適用していない通信装置に障害切替を実施させるためのＰＩＭ−ＳＭプロトコルパケットを生成して送信することとした。これにより、ＰＩＭ−ＳＭのForwarderまたは代表ルータで障害が発生した場合の障害切替を迅速に行うことができ、Ｅｎｄ−ｔｏ−Ｅｎｄでのサービス停止時間を短縮できる。

なお、上述した各実施の形態のうち、同時並列的に使用可能なＬ３プロトコルを適用しているもの同士については、複合して実施しても良い。すなわち、実施の形態２と３を複合させることはできないが、その他の組み合わせは実施可能である。たとえば、実施の形態２の通信装置（図５参照）に対して、実施の形態４の通信装置（図７参照）が備えていたＶＲＲＰモジュール１１およびＶＲＲＰ障害検出通知モジュール１２を追加した構成としてもよい。

以上のように、本発明にかかる通信装置は、ＥＲＰネットワークを形成する通信装置として有用である。

１ ＥＲＰモジュール
２ トポロジ情報収集モジュール
３ 物理ポート
４ トポロジ情報テーブル
５ ＯＳＰＦモジュール
６ 障害箇所特定モジュール
７ 経路テーブル
８ ＯＳＰＦ障害検出通知モジュール
９ ＲＩＰモジュール
１０ ＲＩＰ障害検出通知モジュール
１１ ＶＲＲＰモジュール
１２ ＶＲＲＰ障害検出通知モジュール
１３ ＭＬＤ−Ｐｒｏｘｙモジュール
１４ ＰＩＭ−ＳＭモジュール
１５ ＰＩＭ−ＳＭ障害検出通知モジュール
２１ Ｌｉｎｋ Ｔｒａｃｅ Ｒｅｑｕｅｓｔ送信制御部
２２ Ｌｉｎｋ Ｔｒａｃｅ Ｒｅｓｐｏｎｓｅ監視部
２３ トポロジ情報計算部
１０１ リンクトレースリクエスト
１０２ リンクトレースレスポンス

Claims (16)

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

Images