JP4610621B2 - ネットワークシステム - Google Patents

ネットワークシステム Download PDF

Info

Publication number
JP4610621B2
JP4610621B2 JP2007555846A JP2007555846A JP4610621B2 JP 4610621 B2 JP4610621 B2 JP 4610621B2 JP 2007555846 A JP2007555846 A JP 2007555846A JP 2007555846 A JP2007555846 A JP 2007555846A JP 4610621 B2 JP4610621 B2 JP 4610621B2
Authority
JP
Japan
Prior art keywords
data transfer
transfer device
network
path
data
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
JP2007555846A
Other languages
English (en)
Other versions
JPWO2007086157A1 (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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2007086157A1 publication Critical patent/JPWO2007086157A1/ja
Application granted granted Critical
Publication of JP4610621B2 publication Critical patent/JP4610621B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • 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/437Ring fault isolation or reconfiguration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

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

Description

参照による取り込み
本出願は、2006年1月25日に出願された日本特許出願第2006−015770号の優先権を主張し、その内容を参照することにより本出願に取り込む。
本発明は、マルチキャストパスのプロテクション方法に関するものである。特に、幹線経路から派生する枝経路に対しデータをコピーして送達する形態のネットワークにおける経路管理方法及び経路切り替え方法に関する。
通信経路のプロテクションを行う場合、現用系に対する予備系を設定する必要がある。これまで経路設定及び切り替え条件の簡易性から、ポイントツーポイントでの経路切り替えのみが検討されてきた。SDH、ATMなど従来技術においては、オペレータの手による静的なネットワーク設定を基本とするため、固定的に用意された論理パス若しくは物理パスを用いたポイントツーポイントでの通信が主体であった。ところが、現在及び次世代ネットワークにおいて主流となりつつあるイーサネット(イーサネット、Ethernetは富士ゼロックス社の登録商標です)などのコネクションレスネットワークでは、STP(Spanning Tree Protocol)によるMACアドレス学習やイーサネットに具備される回線自動認識機能、IPネットワークにおけるルーティングプロトコルといった自動化制御が大きな特徴であり、利用者としては便利である半面、オペレータの立場からは経路の把握が難しくなっている。さらに、パケット通信ベースのネットワークでは新たな概念としてマルチキャスト、ブロードキャストという1対多の通信がサポートされたことも、前記自動設定機能の導入と合わせて経路の管理を困難なものにしている。
次世代ネットワーク(NGN;Next Generation Network)構想においてパケット通信ベースのネットワークシステム構築が推進されていること、またイーサネットはその高速化技術が標準化されてきており、適用範囲がLANからWAN、キャリア網へと拡大していることから、コネクションレス通信における品質確保は重要な課題となってきている。イーサネットをはじめとするコネクションレス通信に特徴的なマルチキャスト機能は、今後放送、通信サービスの融合が進む上で不可欠である。
しかしながら、マルチキャストフローの通信経路はユーザのマルチキャストグループ参加状況などにより常時変化する。また、たとえ静的にマルチキャストパスを設定する場合においても、マルチキャストのパスがネットワーク上で相互に部分的に重なることから、管理対象であるパスを把握することが難しい。
一方、イーサネットの適用先としてメトロネットワークがある。メトロ領域においては、ユーザサイドに分散するネットワーク、すなわちキャリアのアクセス網(地域網)、企業サイトなどの個人設置網を収容する。リングネットワークは、個別の地域ネットワークの相互接続性を提供すると共に、ユーザ網をより広い接続性を提供するコア側(WAN側)ネットワークに接続し、より広範囲の通信を実現する(インターネットの利用を可能にする)。
例として現状のテレビ放送のようなマスメディアとしての放送サービスの実現形態を想定すると、ユーザにとってWAN側に設置される放送局の配信装置からユーザに向けてデータストリームが配信されるという形態が想定できる。このとき、上記のような地域網をWAN側広域網で順に収容する階層型ネットワーク構成においては、地域網とWAN側広域網を接続するリング網を経由しての配信となる。また、別の例として、複数の地域網間あるいは個人サイト間において相互に情報共有する場合に、マルチキャスト機能を利用するケースが増えてくる。これらが品質及び秘匿性の確保を要求する通信であった場合に、マルチキャストパスの管理が必須の機能となる。
こうしたリング経由のネットワークの場合、マルチキャストパスがリングを構成するパスと、リングから分岐してユーザに向かう個別パスとに分類できる。この個別パスにおいて、上記のような重なりの問題を回避できる場合を想定すると、マルチキャストパスのプロテクションモデルの一つとして、リングプロテクションとリニアプロテクションの組み合わせと捉えることができ、パス管理を実現できる。
通信障害に対応しつつ、常時エンドツーエンドのパスを維持するためには、リングの幹に関するプロテクションと枝部分に関するプロテクションとを連携しなければならない。これまで2点間のポイントツーポイントパスに対するリニアプロテクション(非特許文献1)、及びリングネットワークにおけるプロテクション(非特許文献2)が議論されてきたが、エンドツーエンドのパス管理を実現するためには、複数(双方)の経路を跨るエンドツーエンドでの通信可否を管理する必要がある。そのため、従来のパス両端における通信状況管理機能に加え、パスの接続点(この場合はリングの幹と枝とを接続するポイントとなる、リングを構成するノード(ステーションともよばれる))における障害情報ハンドリング技術が要求される。
上記サービスからの要求に加え、非特許文献3で規定されているイーサネットOAM (Operation,Administration and Management)機能の設計において、既存製品との互換性とOAMフレーム処理の効率化という観点からマルチキャストアドレスを用いる方式が提案されている。マルチキャストアドレスは、経路を特定するという目的以外に、OAMという「機能」を識別するIDとして使用される。いずれにしてもOSIモデルのデータリンク層においては、マルチキャストアドレスはVLAN(Virtual LAN)内でブロードキャストされるため、パス管理においてはOAM及びユーザフレームを不要な経路に流さないような設計が不可欠である。以上から、リングを介したマルチキャストパス管理においては、ノード(ステーション)におけるパス接続機能と、マルチキャストフレームのフィルタ技術が必要である。
本発明の目的は、従来、エンドツーエンドパス管理が困難であった、コネクションレス通信におけるマルチキャストパスの管理を実現する方法を提案することである。また経路に障害が発生した場合に、最小限の処理により、また同一マルチキャストを配信するツリーの他の部分に与える影響を最小限にすることにより、マルチキャストパスの一部もしくは全部に対する効果的なパスプロテクション機能を提供することである。
本発明は、幹線経路と分岐経路とで構成されるネットワークにおいてマルチキャストパスをエンドツーエンドで管理し、障害発生時に個々のエンドツーエンドパスに対して現用経路から予備経路への切り替えを行うプロテクション機能を実現することを目的とする。そのため、幹線経路上に存在するマルチキャストフローの送出元ノードにおいて、マルチキャストフローの個々の宛先まで論理的に設定されるパスについてのエンドツーエンドの通信状態を管理する。障害時を含む必要な機会に、本ポイントより切り替えを指示することで、同一マルチキャストフローの配信のために一部経路を共有している他のマルチキャストパスの通信状態に影響を与えずに個別パスのプロテクションを行うことを最も主要な特徴とする。
本発明はリング上のマルチキャストフロー発信元(以下、ルートステーションと記述する)において、マルチキャストパスの通信状態を管理することによって、エンドツーエンドに経路情報を把握でき、ネットワーク運用管理、及びサービス管理において重要な品質管理が可能になる。また最小の処理でパス切り替えを実現でき、これによりパス切り替えの処理時間を短縮し、また制御・管理用フレームの処理を低減することによってネットワークリソースの使用効率を向上できる。さらに、幹線と分岐線の接続点における切り替え機能が不要となり、装置における状態遷移が不要であり、送信側では通信可否など切り替え処理の影響を考慮する必要がなくなる。
本発明の第1の実施例では、リング上のマルチキャストフロー発信元(以下、ルートステーションと記述する)において把握する経路情報に基づき、最小の処理でパス切り替えを指示する方法を説明する。この方法ではパス切り替えの処理時間を最も短縮でき、ネットワークリソースの使用率を低減できる。
図1は、本発明を適用するネットワーク構成および該ネットワークを用いたマルチキャスト配信方法を説明する図である。本構成例では、WAN側ネットワーク10000と、ユーザ側ネットワークNXW、NXP(X=1〜4)を接続するためにリングネットワークを備える。リングネットワークは、ノードS0〜S5(以下、ステーションS0〜S5と記述する)により構成される。以下、これらのステーションS0〜S5とそれらをつなぐリングネットワークによって構成される通信経路を幹線と称する。また、各ステーションS1〜S5とユーザ端末131〜136をそれぞれのネットワークNXW、NXP(X=1〜4)で接続する経路を分岐線と称する。ユーザ側ネットワークNXW,NXP(X=1〜4)は、例えば企業サイトのネットワークや、キャリアの地域ネットワークや、ユーザのホームネットワークなどが考えられる。また、その接続形態として、リングから個別サイト網に入る際にルータやスイッチを介して相互接続するLANの形態、また一般家庭や集合住宅、企業ビルにおいて普及が進んでいるPON(Passive Optical Network)システムを介した接続なども考えられる。
マルチキャストデータ配信は、マルチキャストサーバ20000からWAN側ネットワーク10000、リング状の幹線、分岐線を介してユーザ端末に届く。ここで、ステーションS0からユーザ端末131〜136までの経路を確保するため、データの転送経路は冗長構成をとるものとする。通常状態においては、図中の実線で示されるようにステーションS0からS1,S2、の順に通過する経路(順方向経路と呼ぶ)110に沿ってデータを転送し、リング上を一周したデータはステーションS0に戻り、終端される。ステーションS0では、マルチキャストパスの起点1000と終端点2000を備える。予備系に対しては、起点2000と終端点1000の組み合わせとなる。起点1000と終端点2000は、現用系と予備系夫々に独立した機能ブロックを備えてもよい。
各ステーションS1〜S4では、その配下のネットワークNXW、NXP(X=1〜4)に、当該マルチキャストを要求する(マルチキャストグループに属する)ユーザが存在する場合に、リング上で受信したマルチキャストデータをコピーし、分岐線に転送する。リング上の順方向経路110に障害が発生し、順方向通信111が中断される場合、リングはその幹線経路の一部もしくは全部を予備系に切り替えることにより、ステーション間の通信を確保する。図1では、例えば全経路が切り替わった場合の通信例を示している。すなわち、マルチキャストサーバ20000からのデータは、ステーションS0において、予備系経路120へ転送され、ステーションS0からS5、S4、S3の順にリング上を一周してステーションS0で終端される。この方向でのデータフローを逆方向通信121と呼び、図中には点線で示してある。逆方向通信の場合も順方向通信と同様に、各ステーションS4〜S1は、自身の配下のネットワークNXW,NXP(X=1〜4)の先に当該マルチキャスト受信端末が存在する場合に、データをリング上に転送すると共にデータフレームを複製し、それを分岐線に転送する。
リングネットワークでは、通常リングの通信方向は予め決められている。本発明はマルチキャストパスについて、分岐線を含むエンドツーエンドのプロテクションを実現するための方法であり、リングの幹線部分に関するプロテクション制御方法として、例えば、非特許文献5に示されるRPRを用いても良いし、また障害時にリング全体の通信方向を切り替えるのではなく、障害点を避けるように、障害点を挟むステーションにおいて、それぞれ順方向通信と逆方向通信を折り返し接続することにより、障害点を回避してリングを一周する経路を構築するといった方法も可能である。これらの方法のいずれを採用しても本発明の効果を奏する。以下、実施例の説明においては、障害が発生した場合に、リング幹線全体の通信方向を切り替える方法をとるものとする。
NXWとNXP(X=1〜4)は、それぞれ分岐線における現用系と予備系ネットワークである。これらの分岐線における現用系と予備系ネットワークは、リングを構成するステーションSX(X=0〜4)と、エッジノードENX(X=1〜4)をそれぞれ端点とする通信経路において、リニアプロテクション機構を提供するために設定する。N1W及びN1Pを例にとると、通常状態では現用系であるN1Wを介してフレームが転送される。このときのデータフローはステーションS1とエッジノードEN1を結ぶ実線で示す。N1Wの経路上で障害が発生したとき、例えばステーションS0とノード101間の経路が通信不能になったときは、ステーションS0からエッジノードEN1に至る経路としてN1Pを通過する経路を選択し、ユーザ端末131、132へのマルチキャストパスを確保する。予備系フローは点線で示す。
なお、ここで現用系経路N1Wと予備系経路N1Pは互いに独立したネットワークであるように図示しているが、本来パケットベースの通信では、これらは一つのネットワーク内に混在することもできる。つまり、あるフローについて見ると現用系として用いられるパスが、他のフローに対しては予備系となるように設定されている場合も考えられる。以降の説明では、説明を明確にするため、図1に示すように現用系と予備系のネットワークを分離した形で図示する。勿論、経路の役割を区別するための概念的な(論理的な)記述である。
またリニアプロテクションを適用するネットワーク形態として、非特許文献3、非特許文型4において1+1、1:1、1:Nなどの方式が規定されている。本発明ではリニアプロテクションの実現方法も特に限定しない。以降では、まず分岐線においては1:1プロテクションを想定して説明を行う。その他の方法を用いる場合のバリエーションについては、1:1プロテクションに関する実施例を説明した後に追記する。
図1において、リング幹線と分岐線のプロテクションはそれぞれ独立である。ステーションS1〜S5が、幹線と分岐線を相互接続する機能を備えており、その機能を図中ではCPX(X=1〜5)で示す。また、マルチキャストパスの端点であるエッジノードEN1〜4には、それぞれ現用系パスもしくは予備系パスから送られてくるフローを終端する終端機能EP1〜EP4を備える。また、リング上のマルチキャスト起点であるステーションS0には、マルチキャストパスの端点機能CP0を備える。
図1では、ステーションS0がマルチキャストの起点となっているが、本発明は、より一般的に、2つ以上の網間のマルチキャストに対しても適用可能である。つまり、ユーザ端末131からユーザ端末135、136へマルチキャストによってデータを送信する場合、マルチキャストパスの送信側の端点は、ステーションS1となる。また、他方の端点はそれぞれEN3、EN4である。この例においてリング上での現用系と予備系の定義は、それぞれステーションS1からS2に直接向かう経路が現用系、S0を通過する経路が予備系となる。
図2は、図1の実施例におけるOAMフレーム制御方法を説明する図である。ここでは、ネットワークの接続状態を管理する方法として、非特許文献3に従い、CC(Contonuity Check)フレームを送信する方法を説明する。
CCフレームは、一方向毎の通信状態を確認するためのフレームである。ここで、通信状態の確認はマルチキャストパスに対して行うものであり、マルチキャストパスの送信側端点であるステーションS0と個々のユーザ側端点との間には、リング幹線における現用系と予備系との違い、及び分岐線における現用系と予備系との違いにより、計4パスが設定されている。従ってプロテクションを有効に適用するには、これら4パスの通信状態を常時把握しておく必要がある。
CCフレームは、データパス(マルチキャストパス)をトレースするために、データパスと同様のマルチキャストパスを使用する。ここで、個々の終端点EN1〜EN4に対し、それぞれ経由するパスを識別するために、CCフレームのヘッダ部分にパスの識別子を挿入する。ヘッダに挿入するパス識別子は、すなわち分岐線での通信において現用系を用いるか予備系を用いるかを示す。ステーションS0においては、現用系経路に送出するCCフレームのうち、各ステーションで現用系の分岐線に振り分けるものと、予備系分岐線に振り分けるもの、さらにステーションS0から予備系経路に送出するCCフレームのうち現用系分岐線に振り分けるものと、予備系に振り分けるものと、計4フレームを送出する。
ここではN2W、N2Pを例として経路識別方法を説明する。他のユーザネットワークNXW,NXP(X=1〜4)においても同様である。図中で、Aはリング幹線、分岐線共に現用系を通過する経路、Bは現用のリング幹線と予備の分岐線を通過する経路、Cは予備のリング幹線と現用の分岐線を通過する経路、Dはリング幹線、分岐線共に予備系を通過する経路である。CCフレーム201〜204には、それぞれ経路識別子211〜214が含まれている。これらの識別子は、新しいプロトコルフィールドを定義しても良いが、ここでは既存のヘッダフィールドを使用する方法を説明する。すなわち、VLANタグもしくはMPLSラベルを含む、経路制御に用いるプロトコルフィールドにおいて、一マルチキャストアドレスあたり、かつ一受信エッジノードENあたりにVLANタグあるいはMPLSラベルを4種類ずつ設定し、それぞれA〜Dに対応させる。これにより、ステーションS1〜S4では、回線インタフェース毎にVLAN(論理ポート)設定を行うか、MPLSフォワーディングテーブルを用意することにより、現用系と予備系の振り分けが実現できる。VLANタグを用いる場合、A〜Dはそれぞれ異なるVLAN IDを表す。各ステーションS1〜S4における分岐転送の要否についてはマルチキャストアドレスによって転送経路が異なるため、IGMP/MLD snoopingあるいは手動設定によるフィルタを設定するなどの方法を併用しても良い。
図3は、図2と同一パスの逆方向通信について接続性を確認するためのCCフレーム送信方法を示す図である。各エッジノードEN1〜EN4より、ステーションS0に対してCCフレームを送信する場合を示す。
各エッジノードEN1〜EN4から、現用系分岐経路、予備系分岐経路に対してそれぞれCCフレームを送出する。例えば、N1Wではノード101、N1Pではノード102に向けてそれぞれCCフレームを送出する。このときの論理パス識別方法は、例えば、VLANであってもMPLSであっても構わない。OAM及びリニアプロテクション方式の勧告に従ってもよい。いずれにしても本発明を適用できる。
各ステーションS1〜S4は、エッジノードEN1〜EN4よりCCフレームを受信すると、それをリング幹線の現用系もしくは予備系に載せてステーションS0まで送信する。このとき、リング幹線では利用可能な一方の経路を利用すればよい。ステーションS0はCCフレームを終端し、CCフレームに含まれる情報及びCCフレームの受信間隔を含むOAM管理パラメータに基づき、エッジノードENからステーションS0までの経路の状態を確認する。
ここで、CCフレームに用いる宛先アドレスはユニキャストアドレスである。つまりステーションS0の持つ識別子を用いる。その理由は、例えばEN1から発信されたCCフレームが他のステーションにおいて分岐経路に展開されては、リンクの帯域及び中継ノードのCPUリソースを過度に消費するためである。
なお、ステーションS0までのリング幹線上のCCフレーム転送では、使用するリングを予備系にする方法も考えられる。リニアプロテクションでは、通常同一経路を逆方向にトレースするようにCCフレームを送信するが、マルチキャストの分岐数が少ない場合などには、リング幹線については予備系を用いることで、リング幹線でのリソースの節約とパス管理の効率化が期待できる。
図2、3に示すCCフレーム送出の手順は、次のようになる。まずステーションS0よりマルチキャストアドレスを宛先とするCCフレームを送出する。このフレームには、ステーションS0の持つアドレスが送信元アドレスとして含まれており、受信側のエッジノードは、このCCフレーム受信によって、上り方向に送出するCCフレームの宛先を知る。この下りCCフレームから得たステーションS0のアドレスを宛先として、またエッジノード自身のアドレスを送信元アドレスとして、上りCCフレームを送出する。
図4は、本発明を適用したときのマルチキャストフレームの構成図である。
ここではイーサネットフォーマットをベースとしてフレーム構成を説明する。フレームの宛先アドレス301には配信するマルチキャストグループアドレスを示すアドレスが挿入される。また送信元アドレス302には、ブロードキャストドメイン内でマルチキャストフレームの送信元であるノードの出力インタフェースのアドレスが挿入される。イーサタイプフィールド303には、それがOAMフレームであるか、ユーザデータフレームか、また上位プロトコルを識別するために規定されているタイプ値が挿入される。一つもしくは複数のVLANタグを挟み、その他ヘッダ情報305、ペイロード306で構成される。
本実施例では、マルチキャストパスの識別にVLANタグを用いる場合を例に説明する。VLANタグはCOS値310、CFI320、VLAN ID330で構成される。このうち、VLAN IDの一部を、マルチキャストパスを識別するための識別子として用いる。ここでは、VLAN IDをフロー識別子331とパス識別子332に分割し、パス識別子を332−1から332−nのnビットで構成するものとする。
パス識別子の各ビットは、0のときに現用系、1のときに予備系を使用することと定める。332−x(X=1〜n)のXの位置、すなわちビットの位置は、それぞれリングを構成するノード(ステーション)識別子と対応させる。
したがって、マルチキャストフロー識別子331で決められる個々のフローにつき、それぞれリングを構成するステーション数に対しその2倍のVLAN IDを確保しておく。分岐線の障害状況に応じ、パス識別子の各ビットを書き換えてマルチキャストフローを送出することで、ステーションS0からマルチキャストパスを制御できる。
上記パス制御のためのVLANタグ空間は他のサービスと同列に定めておいてもよいし、本発明のリング以下エッジノードまでの経路において使用するタグを別途定めておき、ステーションS0において、つまりはマルチキャストフローが本発明におけるパス管理区間に挿入された時点で付与(スタック)し、エッジノードにおいてそれらを削除することとしてもよい。
図5〜図7は、図1のネットワークにおいて障害が発生した場合の障害情報通知方法を説明する図である。
図5は分岐線における障害がステーションS0へ通知されるまでの動作を示す。ここでは、例としてユーザ側ネットワークN3Wにおける障害発生の場合の処理を説明する。リング幹線、分岐線共に現用系を使用している場合の障害検出例を示す。ステーションS3、中継ノード105、106、エッジノードEN3の間にはそれぞれノード間接続を管理するME(Maintenance Entity)が設定され、またステーションS0とエッジノードEN3間にエンドツーエンドパス管理用のMEが設定されているものとする。図2、図3で説明したCCフレームは、MEの管理に用いるOAMフレームである。
図2に示したように、ステーションS0で挿入されたCCフレームは、現用リング幹線を通過し、ステーションS1、S2、S3、S4を通過する際にそれぞれCP1〜CP4において現用分岐線に接続され、EN1〜EN4にあるパスの終端点EP1〜EP4に到達する。ここでN3Wにおいて中継ノード105、106の間で障害が発生してCCフレームがEN3へ届かない場合、中継ノード106はCCフレームの通信異常を検出してAIS(Alarm Indication Signal)を発行する。AISはさらにMEに沿って中継ノード106からエッジノードEN3へ通知され、エッジノードは通信系路上の障害を認識する。
図6は、障害を検出したエッジノードEN3からマルチキャストパスの送出側端点(ME端点、すなわちステーションS0)への障害情報通知方法を示す。
エッジノードEN3からステーションS3への通信には、予備系経路を使用する。ここではEN3から発行されるRDI(Remote Defect Indication)メッセージが通知される。RDIメッセージはステーションS0の識別アドレスを宛先アドレスとするユニキャストフレームとして送信される。ステーションS3では、RDIメッセージの宛先アドレスを参照し、CP3を介してメッセージをリング幹線に転送し、ステーションS0へRDIメッセージが到達する。これによって、マルチキャストパスの送出端点では配信系路上の障害を認識できる。
なお、リング幹線にRDIメッセージを転送する際の経路は、先に述べたようにリング幹線の制御方法に依存する。ここではリング幹線でActiveなっている経路を利用することを想定しているが、予備系経路を用いてステーションS0へ通知してもよい。この経路選択の自由度は本発明のポイントには影響しない。
図7では、図6で障害情報を受信した後のマルチキャストパスの送出方法を示す。ステーションS0では、図4のフレームフォーマットに示したように、VLANタグもしくはMPLSラベル(ここではVLANタグ使用を想定して説明する)の中で、ステーションS3において参照するビットを書き換える。このビットはフレーム転送時に分岐線の現用系と予備系を参照するために用いるビットであり、通常状態でN3Wを示すよう設定されていたビットを、N3Pを示すものに変更する。ここで書き換えるものはステーションS3が参照するためのビットであり、各ステーションにおいて、転送先分岐線の現用、予備系を識別するために参照するビット位置は個別に用意されているため、ステーションS3に対する指示が他のステーションからの分岐線に影響を与えることはない。
ステーションS0においてフレームヘッダ情報の一部を変更することで容易に経路変更を実現できる。中継点であるステーションS1〜S4においては、VLANタグ別の転送先経路を記録したテーブルを用意しておく他、特別な機能もしくは設定の追加を必要としないため、障害発生時の切り替えが早いこと、マルチキャストパス管理が低コストで実現できることから、実用的な方法である。
図8は、分岐線におけるME設定方法を示す図である。ここでは、N3W、N3Pを例としてME設定方法を説明する。
図8において、ステーションS0に設定された510MEの終端点510a及びエッジノードEN3に設定された終端点510bが、MEP(Maintenance Entity End Point)と呼ばれる点である。MEはこれらMEP間に設定される。510MEは現用系の通信経路を管理するためのMEである。また、同時に予備系を管理するため、ステーションS0とエッジノードEN3との間には570MEが設定される。570MEの端点はそれぞれMEP570a、570bである。予備系経路は中継ノード107を通過する経路であり、現用系と異なる経路となるため、それぞれ個別に図示してある。
これらのMEに沿って、それぞれ下り方向及び上り方向にCCフレームを転送し、パス管理を行う。図8には、現用系MEにて障害が検知された場合のOAMメッセージの通知方法を示している。すなわち、ステーションS0からのSSフレーム560が中継ノード105と106との間に発生した障害によって通信できなくなった場合、CCフレームを受信するはずであったエッジノードEN3は、異常を通知するためRDIメッセージをステーションS0宛てに送信する。RDIフレームは現用系の510MEに沿って逆方向に通知される。
回線切断など物理的障害によっては、RDIをエッジノードEN3からステーションS0に送付する現用系経路が使用できない場合がある。このような場合、リニアプロテクションで用いるAPSメッセージを利用できる。APSメッセージは、管理区間の端点より、予備系経路を介して管理区間の対抗終端点に送信される。ここではステーションS0において、VLAN IDを変更しマルチキャスト送信経路を切り替えるためのトリガとしてAPSを利用する。
図9は、図8と異なりMEを階層的に設定した場合の障害検出動作例を示す図である。具体的には図8とはRDI送出に至るトリガが異なる。
図9のようにMEを階層的に設定する場合、上位レベルのMEほど広範囲を管理する。設定された各ME階層では、それぞれ設定した区間を管理するためCCフレームが送信される。下位レベルのCCフレームにおいて、障害が検知された場合、その障害情報は検知したノード内で上位MEに渡され、上位MEレベルにおいてME上の他のノードに通知される。
ここでは、物理的な障害が発生した場合を想定する。CCフレーム590は、中継ノード105と106の間での通信障害のため、中継ノード106に到達できない。中継ノード106は、532MEにおいて障害を検知し、それをノード内でAIS信号として上位MEである520MEへ通知する。障害情報は、520MEに沿ってエッジノードEN3に通知され、最終端であるEN3では、さらに上位MEである510MEレベルに障害情報が通知され、この障害情報により、RDIメッセージがエッジノードEN3〜ステーションS0に送られる。APSフレームの送信も同様のトリガによる。APS送信経路は図8の場合と同様である。
図10は、図8のケースにおいて、図5〜図7で説明した処理の流れを説明するシーケンス図である。ステーションS0は、分岐線の現用、予備系それぞれに対し定期的にCCフレームを送出する(601)。ここではリング幹線のプロテクションについては考慮しないため、分岐線の経路識別のみに着目し、2系統のフローを図示する。幹線と分岐線とを接続するステーションS3では、フレームヘッダの経路ビットを参照して分岐線パスの現用・予備系のいずれに転送すべきかを決定する(602)。エッジノードでは、障害を検出(603)すると、現用系経路を用いステーションS0に障害を通知するため、RDIメッセージを送信する(604)。また、リニアプロテクションの切り替え手順に従い、利用可能な経路(この場合は予備系)を用い、対向するME端点(すなわちマルチキャスト送信側端点であるステーションS0)に対して経路切り替えを要求するAPSメッセージを送信する(605)。ステーションS0では、受信情報を参照してマルチキャストパスの経路異常を検知すると、該当するステーション以下の分岐線経路を予備系に切り替えるため、マルチキャストフレームに付与するVIDの経路識別ビットを変更する(606)。
図11は、図9のケースにおいて、図5〜図7で説明した処理の流れを説明するシーケンス図である。ステーションS0は、分岐線の現用、予備系それぞれに対し定期的にCCフレームを送出する(651)。ここではリング幹線のプロテクションについては考慮しないため、分岐線の経路識別のみに着目し、2系統のフローを図示する。分岐線を構成するノード106では、障害を検出(652)すると、図9の経路管理方法に基づいて、自装置内で検地されるCCフレーム受信異常を、CCフレームが本来送られるべきMEの終端点に向かって送出する。このときAISメッセージを用いる(653)。エッジノードEN3では、このAISメッセージを受信すると(654)、現用系経路を用いステーションS0に障害を通知するため、RDIメッセージを送信する(604)。また、リニアプロテクションの切り替え手順に従い、利用可能な経路(この場合は予備系)を用い、対向するME端点(すなわちマルチキャスト送信側端点であるステーションS0)に対して経路切り替えを要求するAPSメッセージを送信する(605)。ステーションS0では、受信情報を参照してマルチキャストパスの経路異常を検知すると、該当するステーション以下の分岐線経路を予備系に切り替えるため、マルチキャストフレームに付与するVIDの経路識別ビットを変更する(606)。
次に、マルチキャストパスの分岐線において障害が発生した場合の処理を説明する。図12は、図3に示す経路で定期的に送出されるCCフレームにより、エッジノードからステーションS3へ向かう方向(逆方向、もしくは上り方向と呼ぶ)の通信に障害が検出される場合の、傷害通知方法を示す図である。
エッジノードEN3より定期的にCCフレームが送出される。このCCフレームはステーションS0向けユニキャストフレームである。エッジノードEN3からステーションS0までの経路を構成するノードは、それがOAM機能をサポートするノードの場合、それぞれCCフレームを受信し、そのフレームが当該経路における正しい管理情報を含んでいるか、正しい時間間隔で送信されているか等、OAMフレーム制御の流れに沿ってCCフレームを処理し、宛先アドレスまで転送する。
途中経路(ここでは分岐線)において障害が発生した場合の処理について、以下に二通り例を挙げて説明する。
まず、経路上に図8と同様、エンドツーエンドのMEのみ設定した場合、ステーションS0は予期したCCフレームが到着しないことなどから、直接的に経路障害を知ることができる。
次に、図9のように階層的にMEを設定した場合、経路上のノードは予期したCCフレームが到着しないことから、経路障害を検知してAISシグナルを発行する。このAISシグナルはAISメッセージとして、障害を検出した装置よりもMEの終端点側(MEの下流側)へ発信され、ME終端点、つまりステーションS0では経路障害を検知する。
それぞれのケースにおいて障害を検出した場合、一方向のみの障害であればマルチキャストフローを転送する順方向パスについては現用系を使い続ければよい。しかし回線障害の場合は双方向の通信が同時に不可能となる場合も多い。そこで、図5〜図7、図12に示す障害のいずれかが検知された時点で当該経路を切り替える必要が生じる可能性がある。このときはAISメッセージを受信したステーションS0において、障害の発生している分岐線を予備系に切り替えるよう、マルチキャストフレームに付与するVLANタグの内容を変更する。現用系ネットワークN3Wから予備系N3Pへの切り替え後のマルチキャスト配信経路は、図7と同じである。
図13は図12の説明においてエンドツーエンドMEのみを設定した場合の障害検知の動作を説明する図である。ステーションS0では、予期したOAMパラメータを持つCCフレーム、もしくは予期した周期でCCフレームを受信できない場合に、障害として経路上の異常を検知する。
図14は、図9同様に階層的にMEを設定する場合において、図12に示す障害検知を行うときの処理を説明する図である。
それぞれのMEレベルにおいて、CCフレーム801、802、803が定期的に送信される。ここで、中継ノード106と105との間に回線障害が発生した場合、MEP532b〜送信されたCCフレーム803が、対向MEP532aに到達できず、MEP532aは障害を検知する。するとMEP532aは上位MEレベルへAISシグナル811を通知し、障害情報は520MEに沿ってMEP531aに通知される。同様にMEP531aは上位MEレベルへAISシグナルを通知し、上位MEレベルによってステーションS0へAIS情報が通知される。本実施例のようにリング上に単一のMEのみ設定する構成では、ステーションS0にAIS情報を通知する装置は、ステーションS3である。
図15は、図12の障害検知のケースにおいて、図13のようにMEを設定した場合の障害情報通知処理を説明するシーケンス図である。エッジノードEN3は、分岐線の現用、予備系それぞれに対し定期的にCCフレームを送出する(901)。ここでは図13に示すようにCCを設定する。つまり、リング幹線のプロテクションについては考慮せず、リング幹線と分岐線に跨るエンドツーエンドのパスを設定している。ステーションS0は、CCフレームに含まれるOAMパラメータが予期しないものである場合、またCCフレーム受信間隔が設定値どおりでない場合に障害を検知し、当該エッジノードEN3向けに利用可能な他の経路にパスを変更する(VLAN IDを書き換える)(903)。
図16は、図14のようにCCを設定した場合の障害検知動作を示すシーケンスである。ここでは、最も下位に相当するME532MEにおける障害情報がステーションS0に至るまでの動作を説明する。上位MEは下位MEよりも広範囲をカバーするよう設定されるため、下位のMEでの異常はそのまま上位のMEに影響を及ぼす。したがって、障害を検知した最下位のMEにおいてプロテクション処理を行わなければならない。
中継ノード105は管理区間532MEに沿って定期的にCCフレームを送出する(901)。分岐線を構成するノード106では、障害を検出すると、図14の経路管理方法に基づいて、自装置内で検地されるCCフレーム受信異常を、CCフレームが本来送られるべきMEの終端点S3に向かって送出する。このときAISメッセージを用いる。AISフレームはS0へ転送され、ステーションS0では、このAISメッセージを受信すると経路切り替えを行う。具体的には、受信AIS情報を参照してマルチキャストパスの経路異常を検知すると、該当するステーション以下の分岐線経路を予備系に切り替えるため、マルチキャストフレームに付与するVIDの経路識別ビットを変更する。
図17では、リング幹線経路において障害が発生した場合の処理を示す。本発明ではリング幹線部分はプロテクション機能が用意されていることを想定している。リングプロテクションには非特許文献5のRPRや、非特許文献4のリニアプロテクション方式を適用してもよい。これら幹線部分のプロテクション機能は本発明では何を用いてもよいが、本実施例ではエンドツーエンドのパスを確保するための二通りの方法を例に挙げて説明する。
一つは、ステーションS0において、RPRの制御管理プロトコルを利用し、リング全体の経路を予備系に切り替えるように指示を出す方法である。RPRでは隣接ステーション間のリンクを管理し、またリング全体のトポロジ情報を管理する制御管理プロトコルがある。ノード間のリンクに障害が発生した場合、その障害情報が隣接ノード間で順次通知され、リング経路が予備系に変更される。ステーションS0では、アクティブになった予備系に対してCCフレーム及びマルチキャストフレームを送出する。このとき、フレームに付与するVLAN IDを、リング予備系を使用するマルチキャストパスを示すVLAN IDに切り替える。なお、RPRのように隣接ノード間の接続について、自律管理を適用する場合には、図17の経路1002のように障害情報をステーションS0に通知する必要はなく、S3において直ちにリンク異常を検知し、隣接ノード間で経路切り替えを開始することもできる。
もう一つは、マルチキャストパスの送出側端点と受信側端点に加え、リング幹線の送出側端点と終端側端点に対してMEを設定する方法である。この場合はステーションS0で障害情報を受信する方法には、図12で示したものと同様に二通り考えられる。すなわち、ステーションS0が自身の送出したCCフレームの到着確認を行い、それによって経路状態を管理する場合と、リング幹線に沿ってCCを階層的に構築し、中継ステーションにおいてAISメッセージを発行することによりステーションS0に経路の異常を通知する方法である。前者の場合はCCメッセージ以外にはメッセージのやりとりが発生しない。図17には後者の場合のメッセージ処理を示している。後者の場合、図17の経路1002によって障害情報AISを受信すると、直ちに当該マルチキャストフローに付与する送出VLAN IDを、リング幹線の予備系を通過するように変更する。
図18は、図17の幹線切り替えの説明において第二の切り替え方法を採用した場合の、切替え後のマルチキャストフロー通信経路を示す。
図19、図20、図21、図22は図17で説明した第二の切り替え方法を採用した場合の、障害情報通知から経路切り替えまでの処理を説明するシーケンスである。特に、エンドツーエンドME1210MEを設定する点に関しては、本実施例でステーションS0がマルチキャストパスの状態を把握する上で重要であるが、それ以外の部分、すなわち図20、図22で説明する階層化したME設定において、経路障害を検知し、リング幹線における障害を検出する方法に関しては、非特許文献1あるいは非特許文献4のプロトコルに置き換えても構わない。
図19は図17の説明においてリング幹線の起点(実施例の中ではステーションS0)からリング幹線の終端点(同じくステーションS0)の間にエンドツーエンドME1210MEのみを設定した場合の障害検知の動作を説明する図である。ステーションS0では、自身がリング起点からマルチキャストパスに沿って送出した予期したOAMパラメータを持つCCフレーム、もしくは予期した周期でCCフレームを受信できない場合に、障害として経路上の異常を検知する。
図20は、リング幹線に対して階層的にMEを設定し、リング幹線の障害検知を行う場合の処理を説明する図である。
それぞれのMEレベルにおいて、CCフレーム1201、1202が定期的に送信される。ここで、ステーションS2とS3との間に回線障害が発生した場合、MEP1223bから送信されたCCフレーム1202が、対向MEP1223aに到達できず、MEP1223aは障害を検知する。するとMEP1223aは上位MEレベルへAISシグナル1211を通知し、障害情報は1210MEに沿ってMEP1210aに通知される。
図21は、図19の障害検知のケースにおける障害情報通知処理を説明するシーケンス図である。ステーションS0は、分岐線の現用、予備系それぞれに対し定期的にCCフレーム1201を送出する(1301)。リングを構成するステーションでは、CCフレーム1201をリング終端点まで転送し、ステーションS0は自身がマルチキャストパスに沿って送出したCCフレームを受信して、そこに含まれるOAMパラメータを確認することによりリングの通信状態を把握できる。CCフレームを正しく受信できない場合に、ステーションS0ではリングの障害を検出し(1302)、マルチキャストフレーム送出パスを変更する(1303)。
図22では、図20の経路管理方法に従ってリング幹線の障害を検出する。各ステーション間で設定されたMEに沿ってCCフレームが定期的に送出される。ここではステーションS2とステーションS3間のME1223MEにおいては、CCフレーム1202が送出される(1311)。MEの対向MEPでは、予定するCCフレームが正しく受信されない場合に障害を検出し(1312)、自装置内で検地されるCCフレーム受信異常を知らせるAISフレーム1212を、CCフレームが本来送られるべきMEの終端点に向かって送出する(1313)。ステーションS0では、このAISメッセージを受信すると(1314)、経路切り替えを行う(1303)。具体的には、受信AIS情報を参照してマルチキャストパスの経路異常を検知すると、該当するステーション以下の分岐線経路を予備系に切り替えるため、マルチキャストフレームに付与するVIDの経路識別ビットを変更する。
続いて、本実施例において必要となるノード構成を説明する。マルチキャストパスの受信側ノードENX(X=1〜4)は、OAM機能をサポートする従来のノードを使用できる。また、リングを構成するステーションはリング幹線と分岐線とを接続する相互接続点CPX(X=1〜5)が必要であるが、本第1の実施例においては、CP機能としてはステーションS0から送信されるユーザフレーム及びOAMフレームのヘッダ情報(VLANタグあるいはMPLSラベル)を参照して経路を振り分けるというものであり、転送先を識別するためには既存ノードで用いられるL2、L3等フレーム、パケット転送を実現するOSI層の経路表、もしくはヘッダ変換表が設定されていればよい。マルチキャスト起点となるノードについては、マルチキャストパスの状態管理とマルチキャストフローの送信パス制御のため一部新規機能が必要となる。
図23は、リングを構成し、その上でマルチキャストパスの起点及び終端点となるステーションの構成例を示す機能ブロック図である。
ステーションS0は、装置制御部1400、スイッチ部1420、入出力制御部1410−x(X=1〜N、以下まとめて記述する際には1410を用いる)から構成される。装置制御部1400は、プロセッサ1401、メモリ1402、入出力制御部1403を含む。プロセッサ1401は、メモリ1402に格納されるプログラムを実行するために使用する。この処理には、立ち上げ時等における装置設定の実行、経路表の作成及び更新、メモリからフレームを送出する際のフレーム生成、またファームウエア処理を必要とするフレームの解析及びフレーム情報に基づく装置設定及び制御が含まれる。メモリ1402には、装置制御のためのプログラム、フレーム転送先(ネットワークのトポロジ)を管理する経路表1431、本実施例においてマルチキャストパスの制御、管理を行うマルチキャストパス制御表1430、ステーションS0の各インタフェースにおけるOAMパラメータ設定状況を保持するOAM情報データベース1440、OAMフレームから学習するネットワーク上のOAMトポロジを学習し保持するCCDB(CCデータベース)1441、障害発生時にノード内及びネットワーク上の他ノードに対し障害情報を通知するためのOAMフレームを生成するフレーム生成部1442、を含む。
入出力制御部1403は、プロセッサ1401とメモリ1402とのアクセス制御、プロセッサ1401とスイッチ1420との制御情報通信、メモリからスイッチへのフレーム送出処理、スイッチ1420からメモリへ格納されるフレーム情報のCPUへの通知、を含む、装置制御部1400とスイッチ部1420との間における装置制御情報をハンドリングする。
入出力処理部1410は、通信回線を終端する物理インタフェースPHY511、受信フレームを集約し、ヘッダ解析及びヘッダ変換を行い、必要ならばメモリ1415内に格納されるCCDB1450を参照して、スイッチ部1413又はメモリ1415に転送する受信制御部1412、ヘッダ情報に基づきメモリ1415又は上位スイッチ1420に受信フレームを転送するスイッチ部1413、入出力処理部1410内の各種制御プログラムの実行、スイッチ部1413の制御を行うプロセッサ1414、さらにスイッチ1416より受信したフレームについて、キューイング等による送出制御、内部ヘッダ処理及びヘッダ情報記入・削除といったヘッダ処理を行う送信制御部1416から構成される。
図24は図23のメモリに格納されるマルチキャストパス制御テーブルの構成例である。図4に示したマルチキャストフレームのVLANタグを決定する際に、本テーブルを参照する。テーブルには、転送対象フローを示すマルチキャストアドレス1501、リング状の各ステーションを示す識別子1502、各ステーションにおいて当該マルチキャストフローを下流側に転送すべきか否かを示す転送有効フラグ1503、各ステーションから下流へ転送する際に使用する経路が現用系か予備系か、を示す転送経路フラグ1504、その他パス識別情報1505を含む。転送経路フラグは、例えば0のときに現用系、1のときに予備系を使用する。転送経路フラグ1504は、図4のフレームタグ(ラベル)フィールドに格納し、各ステーションにおける経路制御に用いる。その他パス識別情報1505とは、たとえば同一マルチキャストパスに対するフレーム送出を行う場合であっても、ユーザフレームとOAMフレームとで異なるパスを使用する場合など、より詳細に通信経路を指定する場合に用いる。そこで、本フィールドに格納される情報として、例えばEtherTYPE、OAM種別、フレーム処理の優先度等の情報が含まれる。
本実施例では、マルチキャストパス管理をマルチキャストフロー送信元で行うことができ、ステーションS0からユーザまでのネットワークにおけるエンドツーエンドの通信状況を把握することができる。ステーションS0自身がME起点及び終点であるため、障害元がリング幹線であっても分岐線であっても、通常のOAM管理機能を備えていれば、障害に直ちに対応できるため、最もノード設定が容易で実現し易い方法である。
次に、第2の実施例を説明する。第1の実施例では、ステーションS0と各エッジノードENX(X=1〜4)との間にMEを設定したため、リング幹線においてCCフレームをはじめとしてOAMフレームが、現用、予備の両経路に送信されるため、ステーションが多い場合には帯域を圧迫する可能性がある。一方でマルチキャストパスの管理をステーションS0で行うことが、エンドツーエンドのパス管理には必要である。そこで、第2の実施例では、MEを分岐線のみに設定し、OAM情報を共有することによりステーションS0でパス管理を行う方法を示す。
ユーザ向けマルチキャストフレームの転送経路は図1と同様である。
図25及び図26は、それぞれ分岐線におけるME設定及びCCフレーム送信方法を示す。MEは分岐線のみに設定され、CCフレームは各ステーションからエッジノードへ、現用系と予備系の管理のために定期的に送出する(図25)。逆方向も、現用、予備それぞれにつき経路管理のためにCCフレームを用いる(図26)。この分岐線に関するOAMは、非特許文献3及び4に基づくものであってもよい。
分岐線における障害発生時の処理は、図5〜図7、図12で説明したものと同様の動きになる。以下、これを実現するためのME設定方法及び動作シーケンスを説明する。
図27は、分岐線において単一階層のMEを設定した場合の障害情報処理方法を示す。CCフレームは設定されたME区間においてエッジノードEN3方向に転送される。障害が検出された場合に、ME区間に障害情報がとどまるのではなく、ME外のパス管理装置であるステーションS0にまで障害情報が通知される点が、非特許文献4及び第1の実施例と異なる。具体的にはOAMフレーム1761、1762の転送区間がMEを超えるものであること、が本実施例のポイントとなる。
本来OAMフレームはME区間で終端される。本実施例のように外部まで転送するには、そのこと自体が異常現象としてOAMの障害対象にならないようにする必要がある。OAMが機能していない区間を転送するにはフレームのカプセリングなどが利用できる。具体的には、リング内のみで有効なVLANタグを設定しておき、OAMフレームのステーションS0への通知にはそのタグを使用することにより、本実施例を実現できる。
また、ステーションS0に通知されたOAM情報を、装置内で正しく処理することが必要である。そのためS0のOAM情報データベースには、分岐線に設定されたMEに関して、そのOAMパラメータ及び運用状況を保持しておくことが必要である。
図28は、分岐線に各ノード間のMEを設定し、階層的にMEが存在する場合の障害情報処理方法である。障害情報の検知に関しては図5bと同様である。また、検知した障害情報の転送については、図27と同様である。
図29は図27の場合の障害情報処理シーケンスである。CCフレームの生成と送出元が分岐線の起点となるステーションS3となる(1801)。障害情報受信後のシステム内処理シーケンスについて、図10と異なる点は、ステーションS3からステーションS0へ障害情報を通知する際にリング幹線を通過するためのカプセリング処理1802、1803が入る点である。
図30は、図28の設定をしたときのシーケンスを示す。ステーションS3からステーションS0へ障害情報を通知する際にリング幹線を通過するためのカプセリング処理1802、1803が入る以外は、図11と同様である。
図31、図32は図7のように分岐線の逆方向通信経路における経路管理方法(ME設定方法)及び障害情報処理方法を示す。
図31は単一階層のMEを設定した場合の処理方法を示す。ME終端点であるステーションS3では、CCフレームの到着状況から障害の有無を検出する(2001)。障害が発生した場合、通常のリニアプロテクションでは、ME端点においてパス切り替えを行うところ、本実施例では切り替え機能をステーションS0の備えたために、AISメッセージ1901を用いてME外部のステーションS0に切り替えトリガを通知する。
図32では、エンドツーエンドME510MEが不要となる点が図14と異なる。これにより、分岐線内で検出された障害情報は、ステーションS3で一旦終端される。その後、図31と同様にME外部のステーションS0へ、切り替えトリガとしてAISフレーム1914を送信する。
図33は図31の場合の障害情報処理シーケンスである。CCフレームの生成と送出元がエッジノードEN3となる。障害情報受信後のシステム内処理シーケンスについて、図15と異なる点は、ステーションS3において障害検出2001、ステーションS0へ障害情報を通知する際にリング幹線を通過するためのAISフレーム生成及びカプセリング処理2002が入る点である。
図34は、図32の設定をしたときのシーケンスを示す。ステーションS3における障害検知2004、ステーションS0へ障害情報を通知する際にリング幹線を通過するため、中継ノード105からのAISフレームを転送するためカプセリング処理2005が入る以外は、図16と同様の流れとなる。
実施例2では、ステーションS0で経路状態を把握するという点で実施例1と同様であるが、実施例1ではステーション数が多いためにリング上にCCフレームが太陽に流出する可能性がある。そこで、CCフレームを利用する区間を分岐線に限定することにより、リング幹線のユーザフレーム用の帯域利用効率を向上できること、リング幹線区間のプロテクションに関して、他のプロトコルを併用する場合の連携が行い易いこと、などの利点がある。
なお、本発明の説明では、リング上のマルチキャスト発信ポイントであるステーションS0をマルチキャストパスの起点(端点)とし、S0からユーザ側パス終端点ENX(X=1〜4)までのパスに対するプロテクションを考えたが、マルチキャスト送信側におけるパスの端点がステーションS0の外側にあってもよい。すなわち、ネットワーク10000内のデータ中継ノードあるいはマルチキャスト配信サーバを端点としてマルチキャストパスを設定し、該マルチキャストパスに対するエンドツーエンドのプロテクション機能を実現することも出来る。この場合は、ステーションS0におけるOAM情報管理機能及びプロテクション制御機能が前記中継ノードもしくはマルチキャストサーバ20000に備えられる。
また、ユーザ網間でマルチキャストを行う場合、マルチキャストパスの送信側の端点は、EN1もしくはステーションS1となる。また、他方の端点はそれぞれEN3、EN4である。この例においてリング上での現用系と予備系の定義は、それぞれステーションS1からS2に向かう側が現用、S0に向かう側が予備系となる。
さらに、ここでは、個別の通信パスが存在する場合のそのフローに関する通信状態を監視することを想定するため、CCフレームにはデータフローと同じマルチキャストアドレスを含むこととした。一方で特定の領域を常時監視する方法もあり、その場合はリング幹線と分岐線を含む系全体に対して、リング上のパスの起点からユーザ側のパス終端点に至る全経路をトレースするよう、全ENが受信するマルチキャストアドレスを持つCCフレームを送出することで同様の処理を利用できる。
ユーザ網間のマルチキャストなどを考慮すると、管理すべきマルチキャストパスが膨大になる恐れがある。そこで、マルチキャストパスの設定状態及びリングの構成規模に応じて、ユーザデータと同じマルチキャストアドレスを用いる場合と、上記固定的に割当てられるマルチキャストアドレスを用いる場合とを使い分ける必要が生じる。放送など送信経路がある程度固定されている場合は前者、ユーザ個別に発信されるマルチキャストが多い場合は後者とすることが望ましい。
マルチキャストフレームの経路制御はIP情報を用いても実現できる。上記実施例ではデータリンク層での処理を想定したため、マルチキャストフレームはVLAN内においてブロードキャストされる。そのためマルチキャストパケットを余分な経路へ展開しないためには、IGMP/MLD snoopingあるいは新規マルチキャストフレーム転送経路制御機構を用いる必要がある。ノードがIPパケットを処理できる場合には、オペレータにより静的に、もしくはプロトコルの働きにより動的に設定されるマルチキャスト経路制御テーブルを用いることにより、データフロー及びOAMフレームの経路を特定できる。
1+1プロテクションの場合、分岐線の現用系、予備系双方に同時にデータが送信され、受信側エッジノードにおいてどちらの系からのデータを採用するかを選択する。従って、分岐線における障害情報は下りCCフレームで検出されたものについては、エッジノードからAISフレームを送出する際に、エッジノード内のセレクタ設定を変更する。上り方向については、エッジノードから現用、予備系の双方にCCフレームが送出される。このときの通信障害に関しては、実施例1の場合はステーションS0におけるエッジノードとの間に設定されたME別にセレクタ設定を変更する。また、実施例2においては、各ステーションにおいて一旦MEが終端されるため、ステーションに備えたセレクタの設定を変更することで対応する。
図35は、本発明を適用するネットワークの一般形を示した図である。マルチキャストパスを、幹線と分岐線とに分割し、幹線部分において現用、予備系を設定し、また分岐線において現用、予備系を設定する。これらの接続は、幹線系の現用系、予備系双方からそれぞれ分岐線の現用、予備系に通信できるよう、相互接続点CPは一ノード上に設定されることになる。論理パスに関しては現用、予備系それぞれ独立に存在してもよい。重要なことは、論理パスを集約し、その識別子を相互に対応付ける機能が中継ノードあるいはステーションに備えられる点である。
本システムは、マルチキャストパスの分岐線にアクセス回線を使用する場合にも適用可能である。アクセスシステムとは、例えば非特許文献6に記載されるG−PON(Gigabit−capable Passive Optical Network)システムが代表例である。非特許文献6に示されるように、G−PONシステムは利用者側に設置されるONU(Optical Network Unit)と、加入者回線を終端するOLT(Optical Line Terminal)及びそれらを接続する光ファイバーケーブルとで構成される。この加入者回線における障害を回避するための冗長構成例として、(1)OLTとスプリッタは単一の接続インタフェースを使用し、その間の光ケーブルのみを二重化する方法、(2)OLTのPONインタフェース、スプリッタの接続口とも複数用意し、それぞれを光ファイバで接続する方法、(3)ONU側も複数インタフェースを用意し、OLT−スプリッタ間、スプリッタ−ONU間をそれぞれ複数光ファイバで接続することにより冗長経路を確保する方法、(4)(3)に加えてスプリッタを複数段用意し、スプリッタ間も複数経路で接続することによるボトルネック解消方法、が挙げられる(非特許文献6)。
図36は、本発明をアクセス回線に適用した場合のネットワーク構成を示した図である。ここでは上記(3)の場合のネットワーク構成について説明する。他の場合でも、現用系と予備系として合計二系統の経路を設定することができれば、同様の制御が可能である。冗長構成によって異なるのは、その障害耐性である。
N1W〜N4W、N1P〜N1Wに変えて、それぞれステーションS1〜S4のコネクションポイントCP1〜CP4より、現用系W1〜W4、予備系P1〜P4を設定できる。各PON区間は、スプリッタ3601〜3604で接続された光ファイバで構成されており、光ファイバ経路はOLTからスプリッタを介してONUに至る区間を二重化する。これにより、コネクションポイントCP1〜CP4からエッジ(終端)ポイントEP1〜EP4までのそれぞれの経路について図35までの実施例と同様にOAMを用いることにより、上位装置における経路制御が可能となる。
本発明は、その最も主要な適用先として、リングネットワーク及びリングに接続されたノードを経由してデータを送信する際の、データ転送経路(パス/フローと読み替えても可)の管理及び切り替えが挙げられる。
なお、マルチキャストフロー以外にもユニキャストフローを通信するパスのプロテクション機能としても適用できる。(リング形態の場合、特にリングと枝との接続点においてユニキャストのデータパスを考えてもWorking/Protectionの組合せを選択する必要があり、この点が従来のP2Pプロテクションと異なる。)
上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者に明らかである。
本発明を適用するネットワーク構成および該ネットワークを用いたマルチキャスト配信方法を説明する図である。 図1の実施例におけるOAMフレーム制御方法を説明する図である。 図2と同一パスの逆方向通信について接続性を確認するためのCCフレーム送信方法を示す図である。 本発明を適用したときのマルチキャストフレームの構成図である。 図1のネットワークにおいて障害が発生した場合の障害情報通知方法を説明する図であり、分岐線における障害がステーションS0へ通知されるまでの動作を示す。 障害を検出したエッジノードEN3からマルチキャストパスの送出側端点(ME端点、すなわちステーションS0)への障害情報通知方法を示す。 図6で障害情報を受信した後のマルチキャストパスの送出方法を示す。 分岐線におけるME設定方法を示す図である。 MEを階層的に設定した場合の障害検出動作例を示す図である。 図8のケースにおいて、図5〜図7で説明した処理の流れを説明するシーケンス図である。 図9のケースにおいて、図5〜図7で説明した処理の流れを説明するシーケンス図である。 図3に示す経路で定期的に送出されるCCフレームにより、エッジノードからステーションS3へ向かう方向(逆方向、もしくは上り方向と呼ぶ)の通信に障害が検出される場合の、傷害通知方法を示す図である。 図12の説明においてエンドツーエンドMEのみを設定した場合の障害検知の動作を説明する図である。 図9同様に階層的にMEを設定する場合において、図12に示す障害検知を行うときの処理を説明する図である。 図12の障害検知のケースにおいて、図13のようにMEを設定した場合の障害情報通知処理を説明するシーケンス図である。 図14のようにCCを設定した場合の障害検知動作を示すシーケンスである。 リング幹線経路において障害が発生した場合の処理を示す。 図17の説明において第二の切替え方法を採用した場合の、切替え後のマルチキャストフロー通信経路を示す。 図17の説明においてリング幹線の起点(実施例の中ではステーションS0)からリング幹線の終端点(同じくステーションS0)の間にエンドツーエンドME1210MEのみを設定した場合の障害検知の動作を説明する図である。 リング幹線に対して階層的にMEを設定し、リング幹線の障害検知を行う場合の処理を説明する図である。 図19の障害検知のケースにおける障害情報通知処理を説明するシーケンス図である。 図20の経路管理方法に従ってリング幹線の障害を検出する方法を示すシーケンス図である。 リングを構成し、その上でマルチキャストパスの起点及び終端点となるステーションの構成例を示す機能ブロック図である。 図23のメモリに格納されるマルチキャストパス制御テーブルの構成例である。 分岐線におけるME設定及び順方向へのCCフレーム送信方法を示す。 分岐線におけるME設定及び逆方向へのCCフレーム送信方法を示す。 分岐線において単一階層のMEを設定した場合の障害情報処理方法を示す。 分岐線に各ノード間のMEを設定し、階層的にMEが存在する場合の障害情報処理方法である。 図27の場合の障害情報処理シーケンスである。 図28の設定をしたときのシーケンスを示す。 単一階層のMEを設定した場合の分岐線の逆方向通信経路における経路管理方法(ME設定方法)及び障害情報処理方法を示す。 分岐線の逆方向通信経路における経路管理方法(ME設定方法)及び障害情報処理方法を示す。 図31の場合の障害情報処理シーケンスである。 図32の設定をしたときのシーケンスを示す。 本発明を適用するネットワークの一般形を示した図である。 本発明をアクセス回線に適用した場合のネットワーク構成図である。

Claims (11)

  1. マルチキャストデータを転送する第一及び第二のネットワークと、該第一のネットワークに接続された第一のデータ転送装置と、該第一及び第二のネットワークの両方に接続された第二のデータ転送装置と、該第二のネットワークに接続された第三のデータ転送装置とを有するネットワークシステムであって、
    上記マルチキャストデータは上記第一のデータ転送装置から上記第二のデータ転送装置を介して上記第三のデータ転送装置に転送され、
    上記第一のネットワークにおける上記第一のデータ転送装置と上記第二のデータ転送装置の間の通信経路及び上記第二のネットワークにおける上記第二のデータ転送装置と上記第三のデータ転送装置の間の通信経路にはそれぞれ現用系、予備系の通信経路が設定されており、
    上記第一のデータ転送装置は、上記第一のネットワークの現用系及び第二のネットワークの現用系をつなぐ通信経路用、上記第一のネットワークの現用系及び第二のネットワークの予備系をつなぐ通信経路用、上記第一のネットワークの予備系及び第二のネットワークの現用系をつなぐ通信経路用、並びに上記一のネットワークの予備系及び第二のネットワークの予備系をつなぐ通信経路用のそれぞれの保守管理データを上記第二のデータ転送装置を介して上記第三のデータ転送装置に送信することを特徴とするネットワークシステム。
  2. マルチキャストデータを転送する第一及び第二のネットワークと、該第一のネットワークに接続された第一のデータ転送装置と、該第一及び第二のネットワークの両方に接続された第二のデータ転送装置と、該第二のネットワークに接続された第三のデータ転送装置とを有するネットワークシステムであって、
    上記マルチキャストデータは上記第一のデータ転送装置から上記第二のデータ転送装置を介して上記第三のデータ転送装置に転送され、
    上記第一及び第二のネットワークにはそれぞれ現用系、予備系の通信経路が設定されており、
    上記第三のデータ転送装置は、上記第一のネットワーク及び第二のネットワークの現用系をつなぐ通信経路用、並びに上記第一のネットワーク及び第二のネットワークの予備系をつなぐ通信経路用のそれぞれの保守管理データを上記第二のデータ転送装置を介して上記第一のデータ転送装置に送信することを特徴とするネットワークシステム。
  3. 請求項1記載のネットワークシステムであって、
    上記第一のデータ転送装置が送信する保守管理データの宛先アドレスはマルチキャストアドレスであり、送信元アドレスは該第一のデータ転送装置のアドレスであることを特徴とするネットワークシステム。
  4. 請求項3記載のネットワークシステムであって、
    上記第三のデータ転送装置は、上記第一のデータ転送装置が送信する保守管理データを受信すると、該保守管理データの送信元アドレスに基づいて、上記第一のデータ転送装置宛てに、上記第一のネットワーク及び第二のネットワークの現用系をつなぐ通信経路用、並びに上記一のネットワーク及び第二のネットワークの予備系をつなぐ通信経路用のそれぞれの保守管理データを上記第二のデータ転送装置を介して送信することを特徴とするネットワークシステム。
  5. 請求項1記載のネットワークシステムであって、
    上記保守管理データ内には、上記第一及び第二のネットワークにおける上記現用系及び予備系のいずれの通信経路に関する保守管理データであるかを識別する識別子が含まれることを特徴とするネットワークシステム。
  6. 請求項5記載のネットワークシステムであって、
    上記第二のデータ転送装置は、上記保守管理データを上記第三のデータ転送装置に送信する際に、上記識別子に基づいて送信経路を決定することを特徴とするネットワークシステム。
  7. 請求項5記載のネットワークシステムであって、
    上記保守管理データ内には、VLANタグが含まれており、上記識別子は、該VLANタグ内に含まれていることを特徴とするネットワークシステム。
  8. 請求項5記載のネットワークシステムであって、
    上記保守管理データ内には、MPLSラベルが含まれており、上記識別子は、該MPLSラベル内に含まれていることを特徴とするネットワークシステム。
  9. 請求項1記載のネットワークシステムであって、
    上記第一のデータ転送装置は、
    上記第一及び第二のネットワークにおける上記現用系及び予備系の通信経路のそれぞれに関する保守管理情報を保持する記憶部を有することを特徴とするネットワークシステム。
  10. 請求項1記載のネットワークシステムであって、
    上記第二のネットワークシステムの現用系の通信経路に障害が発生した場合は、
    該障害が上り通信経路に関するものであれば、上記第二のデータ転送装置が上記第一のデータ転送装置に、該障害が下り通信経路に関するものであれば、上記第三のデータ転送装置が上記第二のデータ転送装置を介して上記第一のデータ転送装置に、それぞれ障害通知用データを送信し、
    上記第一のデータ転送装置は、上記障害通知用データを受信した場合は、上記通信経路の切替指示用データを送信することを特徴とするネットワークシステム。
  11. マルチキャストデータを転送する第一及び第二のネットワークと、該第一のネットワークに接続された第一のデータ転送装置と、該第一及び第二のネットワークの両方に接続された第二のデータ転送装置と、該第二のネットワークに接続された第三のデータ転送装置とを有するネットワークシステムであって、
    上記マルチキャストデータは、上記第一のデータ転送装置から上記第二のデータ転送装置を介して上記第三のデータ転送装置に転送され、
    上記第二のネットワークシステムの現用系の通信経路に障害が発生した場合は、
    該障害が上り通信経路に関するものであれば、上記第二のデータ転送装置が上記第一のデータ転送装置に、該障害が下り通信経路に関するものであれば、上記第三のデータ転送装置が上記第二のデータ転送装置を介して上記第一のデータ転送装置に、それぞれ障害通知用データを送信し、
    上記第一のデータ転送装置は、上記障害通知用データを受信した場合は、上記障害の発生した第二のネットワークシステムに関する通信経路の切替指示用データを送信することを特徴とするネットワークシステム。
JP2007555846A 2006-01-25 2006-08-04 ネットワークシステム Expired - Fee Related JP4610621B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2006015770 2006-01-25
JP2006015770 2006-01-25
PCT/JP2006/315494 WO2007086157A1 (ja) 2006-01-25 2006-08-04 ネットワークシステム

Publications (2)

Publication Number Publication Date
JPWO2007086157A1 JPWO2007086157A1 (ja) 2009-06-18
JP4610621B2 true JP4610621B2 (ja) 2011-01-12

Family

ID=38308966

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007555846A Expired - Fee Related JP4610621B2 (ja) 2006-01-25 2006-08-04 ネットワークシステム

Country Status (5)

Country Link
US (1) US8089865B2 (ja)
EP (1) EP1981215B1 (ja)
JP (1) JP4610621B2 (ja)
CN (1) CN101336530B (ja)
WO (1) WO2007086157A1 (ja)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8085676B2 (en) * 2006-06-29 2011-12-27 Nortel Networks Limited Method and system for looping back traffic in QIQ ethernet rings and 1:1 protected PBT trunks
CN101378388B (zh) * 2007-08-28 2012-10-03 华为技术有限公司 一种无源光网络数据传输的方法、系统和设备
US8305884B2 (en) * 2007-09-14 2012-11-06 Ciena Corporation Systems and methods for a self-healing carrier ethernet topology
US8165031B2 (en) * 2007-10-12 2012-04-24 Rockstar Bidco, LP Multi-point and rooted multi-point protection switching
CN101453385A (zh) 2007-11-30 2009-06-10 华为技术有限公司 一种故障通告的方法及设备
US8675506B2 (en) * 2007-12-25 2014-03-18 Hitachi, Ltd. Network system, edge node, and access device
JP2011510534A (ja) * 2008-01-14 2011-03-31 アルカテル−ルーセント イーサネット(登録商標)仮想専用ルート権限付きマルチポイントサービスのスマートプロテクションのための方法およびシステム
KR101393268B1 (ko) * 2008-01-14 2014-05-08 알까뗄 루슨트 이더넷 멀티캐스트의 연속성 체크를 위한 방법 및 시스템
JP2009212875A (ja) * 2008-03-05 2009-09-17 Nec Corp 通信装置及びそれに用いる運用管理方法
JP5039639B2 (ja) 2008-06-09 2012-10-03 株式会社日立製作所 パスプロテクション機能を有する通信装置及びその通信装置を使用するネットワークシステム
US8218433B2 (en) * 2009-01-07 2012-07-10 Alcatel Lucent Monitoring connectivity in ring networks
JP5245896B2 (ja) * 2009-02-18 2013-07-24 富士通株式会社 通信装置、通信システム、通信プログラムおよび制御方法
JP4724763B2 (ja) * 2009-03-31 2011-07-13 富士通株式会社 パケット処理装置およびインタフェースユニット
US8787398B2 (en) * 2009-07-31 2014-07-22 Ciena Corporation Linear route protection
CN102104534B (zh) * 2009-12-17 2014-07-02 中兴通讯股份有限公司 组播业务保护方法及系统
JP5394283B2 (ja) * 2010-02-25 2014-01-22 株式会社日立産機システム 情報処理装置及び制御用ネットワークシステム
JP2011193189A (ja) * 2010-03-15 2011-09-29 Hitachi Ltd ネットワークシステム、エッジノード及び中継ノード
US8774010B2 (en) * 2010-11-02 2014-07-08 Cisco Technology, Inc. System and method for providing proactive fault monitoring in a network environment
US8559341B2 (en) 2010-11-08 2013-10-15 Cisco Technology, Inc. System and method for providing a loop free topology in a network environment
US8982733B2 (en) 2011-03-04 2015-03-17 Cisco Technology, Inc. System and method for managing topology changes in a network environment
US8670326B1 (en) 2011-03-31 2014-03-11 Cisco Technology, Inc. System and method for probing multiple paths in a network environment
US8787155B2 (en) 2011-06-01 2014-07-22 International Business Machines Corporation Sideband error signaling
US8880956B2 (en) 2011-06-01 2014-11-04 International Business Machines Corporation Facilitating processing in a communications environment using stop signaling
US8724517B1 (en) 2011-06-02 2014-05-13 Cisco Technology, Inc. System and method for managing network traffic disruption
US8830875B1 (en) 2011-06-15 2014-09-09 Cisco Technology, Inc. System and method for providing a loop free topology in a network environment
JP5975037B2 (ja) * 2011-09-27 2016-08-23 日本電気株式会社 通信システム、通信装置、障害通知方法、及びプログラム
WO2013131554A1 (en) * 2012-03-05 2013-09-12 Telefonaktiebolaget L M Ericsson (Publ) The handling of data transfers in a network with a ring topology
US9450846B1 (en) 2012-10-17 2016-09-20 Cisco Technology, Inc. System and method for tracking packets in a network environment
CN104125083A (zh) * 2013-04-24 2014-10-29 中兴通讯股份有限公司 一种网络设备的主备倒换方法、装置、设备及系统
JP6359914B2 (ja) * 2014-08-13 2018-07-18 APRESIA Systems株式会社 中継システムおよび中継装置
CN107078974B (zh) 2014-12-19 2020-12-25 慧与发展有限责任合伙企业 网络交换机、由网络交换机执行的方法以及存储器资源
JP6601232B2 (ja) * 2016-01-21 2019-11-06 富士通株式会社 分析方法、分析装置、及び分析プログラム
JP7099088B2 (ja) * 2018-06-29 2022-07-12 日本電信電話株式会社 分散補償システム、および、分散補償方法
WO2020255216A1 (ja) * 2019-06-17 2020-12-24 日本電信電話株式会社 伝送路設計装置、伝送網トポロジ設計方法、および伝送路設計プログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001320392A (ja) * 2000-05-09 2001-11-16 Nec Miyagi Ltd Vcパス警報転送方式
JP2003229876A (ja) * 2002-02-06 2003-08-15 Nec Corp マルチリング制御方法およびそれを用いるノード並びに制御プログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6353593B1 (en) * 1999-06-03 2002-03-05 Fujitsu Network Communications, Inc. Protection architecture for virtual channel connections (VCCS) in a telecommunications network
JP2001285323A (ja) * 2000-04-03 2001-10-12 Hitachi Ltd 光ネットワーク
US7039005B2 (en) * 2001-10-02 2006-05-02 Fujitsu Limited Protection switching in a communications network employing label switching
US7164652B2 (en) * 2001-12-17 2007-01-16 Alcatel Canada Inc. System and method for detecting failures and re-routing connections in a communication network
US7152179B1 (en) * 2002-09-19 2006-12-19 Cisco Technology, Inc. IP redundancy with improved failover notification
JP2006015770A (ja) 2004-06-30 2006-01-19 Mazda Motor Corp 車両の下部車体構造

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001320392A (ja) * 2000-05-09 2001-11-16 Nec Miyagi Ltd Vcパス警報転送方式
JP2003229876A (ja) * 2002-02-06 2003-08-15 Nec Corp マルチリング制御方法およびそれを用いるノード並びに制御プログラム

Also Published As

Publication number Publication date
CN101336530B (zh) 2011-05-11
US8089865B2 (en) 2012-01-03
WO2007086157A1 (ja) 2007-08-02
EP1981215A1 (en) 2008-10-15
EP1981215B1 (en) 2013-01-09
CN101336530A (zh) 2008-12-31
EP1981215A4 (en) 2011-11-23
US20100226244A1 (en) 2010-09-09
JPWO2007086157A1 (ja) 2009-06-18

Similar Documents

Publication Publication Date Title
JP4610621B2 (ja) ネットワークシステム
US7173934B2 (en) System, device, and method for improving communication network reliability using trunk splitting
JP5409609B2 (ja) IEEE802.1agの方法を使用したGPON OAM
US8259590B2 (en) Systems and methods for scalable and rapid Ethernet fault detection
JP4257509B2 (ja) ネットワークシステム、ノード装置、冗長構築方法、および冗長構築プログラム
US8018841B2 (en) Interworking an ethernet ring network and an ethernet network with traffic engineered trunks
JP4777363B2 (ja) ネットワークシステム及びデータ転送装置
EP2033377B1 (en) Forced medium access control (MAC) learning in bridged ethernet networks
US20140321845A1 (en) Passive optical network pon protection method and apparatus
WO2007090346A1 (fr) Système de commande, procédé d'émission de message de données, et dispositif de réseau eternet
US7986619B2 (en) Packet network system
EP2417707A1 (en) In-band signaling for point-multipoint packet protection switching
JP2012019391A (ja) 通信フレームの中継装置および中継方法
JP2008160227A (ja) ネットワーク装置及び通信システム
CN102282805B (zh) 一种业务保护方法及接入设备
CN101617511A (zh) 保护方案
JP2007181010A (ja) パスプロテクション方法及びレイヤ2スイッチ
JP5352502B2 (ja) パケット通信システム及びパケット通信装置制御方法
RU2730390C1 (ru) Способ и устройство для автоматического определения топологии межузловой связи в совместно используемом резервном кольце трансокеанской мультиплексной секции
US20120224488A1 (en) Method of connectivity monitoring by subscriber line terminating apparatus
JP5336343B2 (ja) パス接続性確認方法及び伝送装置
JP5388189B2 (ja) ネットワーク装置
CN1983908B (zh) 一种标签资源管理的自纠错方法
JP5041600B2 (ja) 運用保守管理用のトレース要求を送信する方法、管理端点装置及びプログラム
JP2009194623A (ja) イーサネット光アクセス装置およびイーサネット保守冗長方法

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20100108

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

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

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

Free format text: PAYMENT UNTIL: 20131022

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4610621

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees