JP2012533246A - ポイント・ツー・マルチポイントのトラヒックのための復旧メカニズム - Google Patents
ポイント・ツー・マルチポイントのトラヒックのための復旧メカニズム Download PDFInfo
- Publication number
- JP2012533246A JP2012533246A JP2012519896A JP2012519896A JP2012533246A JP 2012533246 A JP2012533246 A JP 2012533246A JP 2012519896 A JP2012519896 A JP 2012519896A JP 2012519896 A JP2012519896 A JP 2012519896A JP 2012533246 A JP2012533246 A JP 2012533246A
- Authority
- JP
- Japan
- Prior art keywords
- node
- path
- point
- multipoint
- working path
- 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.)
- Pending
Links
- 238000011084 recovery Methods 0.000 title claims description 28
- 230000007246 mechanism Effects 0.000 title description 10
- 238000000034 method Methods 0.000 claims description 32
- 230000011664 signaling Effects 0.000 claims description 25
- 238000012546 transfer Methods 0.000 claims description 11
- 230000005540 biological transmission Effects 0.000 claims 1
- 238000001514 detection method Methods 0.000 abstract description 5
- 238000010586 diagram Methods 0.000 description 13
- 238000004891 communication Methods 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 3
- 239000000969 carrier Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000009916 joint effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
- H04L12/437—Ring fault isolation or reconfiguration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/10—Routing in connection-oriented networks, e.g. X.25 or ATM
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
- H04L45/247—Multipath using M:N active or standby paths
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
コネクション型ネットワーク(5)が、ソースノード(A)と複数の宛先ノード(B−F)との間のポイント・ツー・マルチポイントのワーキングパス(10)を有する。ワーキングパスの障害を検出した時点で、障害発生位置を特定する障害の指標が、第1のノード(例えばノードA)へ送られる。指標は、ネットワークの制御プレーンを介して送られる。第1のノードが、障害発生位置に基づいて、複数のポイント・ツー・マルチポイントのバックアップパス(21−25)のうちの1つを選択する。バックアップパスの各々が、第1のノードを複数の宛先ノードに接続する。ワーキングパスにおける潜在的に障害が発生しうる位置の各々には、ポイント・ツー・マルチポイントのバックアップパス(21−25)が設けられる。バックアップパス(21−25)は、トラヒックを搬送するため、障害検出の前に事前構成されてもよい。あるいは、第1のノードが、選択されたバックアップパスの各ノードにシグナリングして、必要に応じてバックアップパスを完全に確立させてもよい。
Description
本発明は、コネクション型のネットワーク、例えばGMPLS(Generalised Multi−Protocol Label Switching)、MPLS(Multi−Protocol Label Switching)、またはMPLS−TP(Multi−Protocol Label Switching Transport Profile)ネットワークにおけるポイント・ツー・マルチポイント(P2MP)のトラヒックパスのための復旧メカニズムに関する。
MPLS−TP(Multi−Protocol Label Switching Transport Profile)は、ITU−T(International Telecommunications Union)とIETF(Internet Engineering Task Force)との共同活動であり、ITU−Tによって定義されるパケットトランスポートネットワークの能力および機能性をサポートするため、MPLS Transport Profileを、IETF MPLSアーキテクチャの中に含めようとするものである。
RFC4872
IETF Internet−Draft「P2MP traffic protection in MPLS−TP ring topology(MPLS−TPリング型トポロジーにおけるP2MPトラヒック保護)」draft−ceccarelli−mpls−tp−p2mp−ring−00、D.Ceccarelli他、2009年1月
通信事業者の多くは、SDH(Synchronous Digital Hierarchy)ネットワークを有している。MPLS−TPの1つの目標は、既存のSDHネットワークからパケットネットワークへの円滑な移行を可能にし、それによって、通信事業者のコストを最小化することである。既存のSDHネットワークはリング型トポロジーに基づいていることが多いため、MPLS−TPの解決策は、この種のネットワークトポロジーで機能することが望ましい。既存の通信事業者のネットワークは、ネットワーク障害の検出と復旧とを行うための復旧メカニズムを有しており、MPLS−TPネットワークも障害に対する回復力を有することが望ましい。しかし、既存のSDHネットワークで使用されている復旧メカニズムは、ラベル・スイッチ・パスを用いるネットワークに直接適用することはできない。
RFC4872は、エンド・ツー・エンドのGMPLS復旧をサポートするシグナリングを記述しているが、この文書の範囲は、ポイント・ツー・ポイント(P2P)パスに限られている。
国際公開第2008/080418号は、リング型トポロジーを有するMPLSネットワークについての保護スキームを記述している。一次パスが、発側ノードを複数の着側ノードに接続している。また、事前構成された二次パスも、発側ノードを複数の着側ノードに接続している。障害が発生した場合、トラヒックは一次パスと二次パスとの両方に沿って送信され、従って、着側ノードの各々が一次パスまたは二次パスを介してトラヒックを受信することが、保証されている。
IETF Internet−Draft「P2MP traffic protection in MPLS−TP ring topology(MPLS−TPリング型トポロジーにおけるP2MPトラヒック保護)」draft−ceccarelli−mpls−tp−p2mp−ring−00、D.Ceccarelli他、2009年1月、は、リング型トポロジーのネットワーク経由のP2MPトラヒックの分配および復旧のためのデータプレーンによる解決策を記述している。
本発明は、トラヒック復旧の別法を提供しようとするものである。
通信事業者の多くは、SDH(Synchronous Digital Hierarchy)ネットワークを有している。MPLS−TPの1つの目標は、既存のSDHネットワークからパケットネットワークへの円滑な移行を可能にし、それによって、通信事業者のコストを最小化することである。既存のSDHネットワークはリング型トポロジーに基づいていることが多いため、MPLS−TPの解決策は、この種のネットワークトポロジーで機能することが望ましい。既存の通信事業者のネットワークは、ネットワーク障害の検出と復旧とを行うための復旧メカニズムを有しており、MPLS−TPネットワークも障害に対する回復力を有することが望ましい。しかし、既存のSDHネットワークで使用されている復旧メカニズムは、ラベル・スイッチ・パスを用いるネットワークに直接適用することはできない。
RFC4872は、エンド・ツー・エンドのGMPLS復旧をサポートするシグナリングを記述しているが、この文書の範囲は、ポイント・ツー・ポイント(P2P)パスに限られている。
国際公開第2008/080418号は、リング型トポロジーを有するMPLSネットワークについての保護スキームを記述している。一次パスが、発側ノードを複数の着側ノードに接続している。また、事前構成された二次パスも、発側ノードを複数の着側ノードに接続している。障害が発生した場合、トラヒックは一次パスと二次パスとの両方に沿って送信され、従って、着側ノードの各々が一次パスまたは二次パスを介してトラヒックを受信することが、保証されている。
IETF Internet−Draft「P2MP traffic protection in MPLS−TP ring topology(MPLS−TPリング型トポロジーにおけるP2MPトラヒック保護)」draft−ceccarelli−mpls−tp−p2mp−ring−00、D.Ceccarelli他、2009年1月、は、リング型トポロジーのネットワーク経由のP2MPトラヒックの分配および復旧のためのデータプレーンによる解決策を記述している。
本発明は、トラヒック復旧の別法を提供しようとするものである。
本発明の一態様では、請求項1によって、トラヒック復旧を実現するため、コネクション型ネットワーク内の第1のノードを操作する方法を提供する。
第1のノードは、障害発生位置に適したバックアップパスを選択することができ、それによって、障害が発生した場合にトラヒックを効率的にリルートすることができる。これによって、ネットワークのデータプレーンレベルに実装されているMPLS Fast Rerouting(FRR)技術において頻繁に発生しうるような、通信リンク上でトラヒックを前方向および後方向に送信する必要性が、最小化または回避される。ワーキングパス(現用パス)の代わりに用いられ、ワーキングパスの宛先ノードに接続するバックアップパス(予備パス)の使用によって、ノードがワーキングパスとバックアップパスとを介して同じデータパケットを受信するような状況が回避される。
有利なことに、一時に用いられるのは、複数のバックアップパスのうち1つだけである。これによって、特にリング型トポロジーの場合、1組のバックアップパスが、1組の予約された共通リソースを共有することが可能になる。1組のポイント・ツー・ポイント(P2P)パスを利用することに比べて、ポイント・ツー・マルチポイントのバックアップパスでは、ネットワークリソースを効率的に利用することができる。
第1のノードは、ポイント・ツー・マルチポイントのワーキングパスのソースノードまたはヘッドノードであってもよい。トラヒックがバックアップパスに沿って送信される場合に前方向および後方向に通過する通信リンクの数を最小化することから、これは、最も効率の良い配置である。しかし、代替的配置では、第1のノードは、ワーキングパスに沿ってソースノードの下り側に位置してもよい。
本発明の別の態様では、請求項11によって、コネクション型ネットワークにおけるトラヒック復旧の方法を提供する。
方法は、さまざまな異なるネットワークトポロジー、例えばメッシュ型ネットワークに適用することができるが、リング型トポロジーに適用された場合に特に有利である。
有利なことに、復旧スキームは、GMPLS(Generalised Multi−Protocol Label Switching)またはMPLS(Multi−Protocol Label Switching)制御プレーンを有するネットワーク内で用いられる。データプレーン接続は、パケットベースであってもよいし、さまざまな他のデータプレーン技術のいずれか、例えば、波長分割多重トラヒック(lambda)、あるいは時分割多重(TDM)トラヒック、例えばSDH(Synchronous Digital Hierarchy)を用いてもよい。データプレーンは、MPLSまたはMPLS−TPデータプレーンであってもよい。また、復旧スキームが、他のコネクション型技術、例えばコネクション型のイーサネット(登録商標)、またはPBB−TE(Provider Backbone Bridging Traffic Engineering)、IEEE802.1Qayに適用されてもよい。
本発明の別の態様では、これらの方法を実行するための装置を提供する。
本書で記述する機能性は、ソフトウェアとして、ハードウェアとして、あるいはこれらを組み合わせて実装されうる。機能性は、複数の別個の要素を含むハードウェアによって、そして、適切にプログラムされた処理装置によって実装されうる。処理装置は、コンピュータ、プロセッサ、状態機械、ロジック・アレー、あるいはいずれかの他の適切な処理装置を含んでいてもよい。処理装置は、必要なタスクを汎用プロセッサに行わせるソフトウェアを実行する汎用プロセッサであってもよいし、処理装置は、必要な諸機能を行うための専用であってもよい。本発明の別の態様では、プロセッサによって実行された場合に上記の方法のいずれかを行う、機械可読命令を提供する。機械可読命令は、電子メモリデバイス、ハードディスク、光ディスク、またはその他の機械可読記憶媒体上に記憶されてもよい。機械可読命令は、ネットワーク接続を介して処理デバイスにダウンロードされうる。
本発明の実施形態について、添付の図面を参照しながら、例示するために記述しよう。
図1は、リング型トポロジーを有する通信ネットワーク5を示す図である。ノードA乃至Fは、通信リンク11によって接続されているが、通信リンクは、光学的、電気的、無線、またはその他の技術を採用していてもよい。有利なことに、ネットワークは、MPLS(マルチプロトコル・ラベルスイッチング)またはMPLS−TP(マルチプロトコル・ラベルスイッチング・トランスポートプロファイル)をサポートしている。これらは、LSP(ラベル・スイッチ・パス)がネットワーク全域で確立されているコネクション型技術である。A乃至Fの各ノードには、受信したトランスポートユニットのヘッダの中で搬送されるラベルを調べることによってトランスポートユニットについての転送決定を実行するラベルスイッチング・ルーター(LSR)が存在する。理解されるであろうが、図1に示すリングは、より複雑なトポロジーを有するネットワーク全体のうちの一部を成すことがある。トランスポートユニットは、パケットまたは非パケットのデジタル信号であってもよい。
図1は、ソースノードAと宛先ノードB、C、D、E、Fとの間のポイント・ツー・マルチポイント(P2MP)のラベル・スイッチ・パスの一例を示す。周知のとおり、LSP(ラベル・スイッチ・パス)は、管理プレーンまたは制御プレーンによって構成される。管理プレーンによってLSPを構成するには、NMS(Network Management System:ネットワーク管理システム)がパス沿いの各ノードA乃至Fに指示して、必要な転送動作を実行させる。制御プレーンによってLSPを構成するには、ヘッドノードが所望のパス沿いの他のノードに信号を送り、そして各ノードが、LSPをサポートするのに必要な転送動作を設定する。P2MPパス10は、トラヒックをソース(発側)ノードAから着側(宛先)ノードB乃至Fの各々へ配信する。P2MP LSPは一方向であってもよく、例えばIPTV(Internet Protocol Television)のように、複数の宛先に同じデータを送信する必要がある場合に特に有益である。P2MP LSPは双方向であってもよく、例えば、同じP2MPパス10が、ノードB乃至FのいずれかからノードAへの戻り方向でトラヒックを配信する。
ノードAはリングのヘッドノードと呼ばれており、P2MP LSP10のルートノードでもある。パスの通信リンク11は、通信リンク障害またはノード障害を検出するため、監視されている。障害の検出は、MPLS−TPによって提供されるOAM(Operations、Administraion、Management)ツール、またはいずれかのその他の適切なメカニズムを用いて行うことができる。障害検出メカニズムの1つの形では、ノードのペアの間でContinuity Checkメッセージを周期的に交換する。所定の時間枠の範囲内に応答が受信されなかった場合、警報が発せられる。
ここで、或る障害がノードCとノードDとの間のリンクに影響を及ぼすと考えよう。この障害は、トラヒックがノードD、E、Fに到達することを妨げるわけだから、P2MP LSP10に影響を及ぼしている。図2は、最初のLSP10の在圏ノードへの接続を復旧させる方策を示す。バックアップパスLSPは、発側ノードAをノードB乃至Fに接続するP2MP LSP20を含んでいる。
ノードAは、事前に計算され、事前にシグナリングされた一組のバックアップP2MP LSPを、ネットワーク障害が発生しうる位置にそれぞれ1つずつ備えている。どの程度のバックアップパスが設定されるかについて以下に述べるが、それは、「復旧(リカバリー)」または「保護(プロテクション)」が必要かどうかによって異なる。図1のワーキングパスLSPについての見込まれるバックアップLSPのフルセットを、図3A乃至3Eに示す。各バックアップLSPは、ネットワーク障害が発生しうる位置に適した接続性(コネクティビティ)を有する。図3Aは、リンクA−Bの障害についてのバックアップLSPを示す図である。バックアップLSPは、ノードF、E、D、C、Bを介してリングの周りを反時計方向に延在している。ノードF、E、D、Cは、トラヒックをドロップ(抽出)し、かつ、当該トラヒックをそのまま継続して転送するように構成されており、ノードBはトラヒックをドロップするように構成される。図3Bは、リンクB−Cの障害についてのバックアップLSPを示しており、第1の分岐が、リングの周りを時計方向にノードBに達するように延在しており、第2の分岐が、リングの周りを反時計方向にノードF、E、D、Cを介して延在している。一般にN個のノードを含むリング型ネットワークでは、N−1個のバックアップLSPが必要である。バックアップLSPは、PROTECTIONオブジェクトを搬送するRSVP−TE Pathメッセージを用いて、設定時にシグナリングされてもよい。
ノード障害またはリンク障害の場合、復旧メカニズムを起動させるために、シグナリングメッセージが、障害を検出したノード(図2では、障害を検出したノードはノードCであろう)から発側ノードAへ送信される。ノードAは、リンクC−D上の障害位置についてのバックアップLSPを選択する。このバックアップLSPは、ノードAをルートとして有するP2MP LSPであり、ノードB、E、Fはトラヒックをドロップし、さらにトラヒックの転送を継続し、ノードC、Dはトラヒックを単純にドロップする。
バックアップLSPは、リングをリンク障害(例えばリンクC−D)およびノード障害(例えばノードD)から保護することができる。ノード障害は、リンク障害に用いられるのと同じメカニズム(例えばOAM、RSVP−TE hello)を用いて検出されてもよい。ノード障害の場合、障害が発生したノードにトラヒックをルーティングすることや、その中を通すことはできない。
障害を検出したノードから送信されるシグナリングメッセージは、ReSource ReserVation Protocol−Traffic Engineering(RSVP−TE)のNotifyメッセージであってもよい。このメッセージは、ネットワークの制御プレーンを介して送信される。
(i)復旧および(ii)保護を実行するには、2つの方策がありうる。
(i)復旧スキーム
復旧スキームでは、バックアップバス21乃至25に要する資源(リソース)は、障害の前にはデータプレーンレベルでクロスコネクトされていない。このため、他のLSPは、バックアップパスの帯域幅をそれらが必要となるまで使用することができる。このスキームでは、障害の検出に続いて、リソースをクロスコネクトする目的でバックアップパス沿いのノードにシグナリングするための若干の時間が新たに必要となる。選択されたバックアップLSPは、各ノードにおいてデータプレーンレベルでリソースをクロスコネクトすることによって起動される。次いでトラヒックは、ワーキングLSP10から、使用されるように準備されたばかりのバックアップLSP20へスイッチされる。バックアップLSPは、PROTECTIONオブジェクトの中でSビットが0に設定された修正Pathメッセージを用いて起動されてもよい。この時点で、リンクリソースおよびノードリソースは、一次LSPとなる(通常のトラヒックを搬送する用意ができた)このLSPに割り当てられなければならない。
復旧スキームでは、バックアップバス21乃至25に要する資源(リソース)は、障害の前にはデータプレーンレベルでクロスコネクトされていない。このため、他のLSPは、バックアップパスの帯域幅をそれらが必要となるまで使用することができる。このスキームでは、障害の検出に続いて、リソースをクロスコネクトする目的でバックアップパス沿いのノードにシグナリングするための若干の時間が新たに必要となる。選択されたバックアップLSPは、各ノードにおいてデータプレーンレベルでリソースをクロスコネクトすることによって起動される。次いでトラヒックは、ワーキングLSP10から、使用されるように準備されたばかりのバックアップLSP20へスイッチされる。バックアップLSPは、PROTECTIONオブジェクトの中でSビットが0に設定された修正Pathメッセージを用いて起動されてもよい。この時点で、リンクリソースおよびノードリソースは、一次LSPとなる(通常のトラヒックを搬送する用意ができた)このLSPに割り当てられなければならない。
バックアップパスを設定する最初の段階(障害発生以前)では、バックアップLSPはシグナリングされるが、リソースがデータプレーンレベルで関与しているわけではない。リソースは、制御プレーンレベルで事前に予約されているだけである。シグナリングは、LSPがそれぞれ「ワーキング(稼働中)」および「保護」のタイプであることを(PROTECTIONオブジェクトの中の)Pathメッセージの中で示すことによって行われる。バックアップ(起動されていない)LSPのために事前に予約された帯域幅を追加トラヒック用に利用可能にするために、この帯域幅が、保護しているLSPのHolding Priorityより低い優先度で(数値的により高いことを意味する)、アドバタイズ(広告)されたUnreserved Bandwidthに含まれてもよいだろう。加えて、Interface Switching Capability Descriptor sub−TLVの中のMax LSP Bandwidthフィールドは、保護しているLSPのために事前に予約された帯域幅が、追加トラヒック用に利用可能であるという事実を反映するべきである。次いで、(Pathメッセージの中の)SESSION_ATTRIBUTEオブジェクトのSetup PriorityフィールドをXに設定し(ここでXは、保護しているLSPのSetup Priorityである)、Holding Priorityフィールドを少なくともX+1に設定することによって、追加トラヒック用のLSPを確立することができる。また、保護しているLSPのために事前に予約されたリソースが低優先度のLSPによって使用されている場合、保護しているLSPが起動された時に、これらのLSPは代わられるべきである。
(ii)保護スキーム
保護スキームでは、バックアップパスに要するリソースは、障害以前にデータプレーンレベルでクロスコネクトされている。これによって、必要なバックアップパスへの迅速なスイッチが可能になるが、バックアップバスのリソースが予約されるため、帯域幅の点で不利益が生じる。バックアップバスの予約されたリソースは、バックアップバス沿いのトラヒックを搬送するために予約されたリソースが必要になる時刻まで、「ベストエフォート」トラヒックのような、他のトラヒックを搬送するのにも使用することができる。
保護スキームでは、バックアップパスに要するリソースは、障害以前にデータプレーンレベルでクロスコネクトされている。これによって、必要なバックアップパスへの迅速なスイッチが可能になるが、バックアップバスのリソースが予約されるため、帯域幅の点で不利益が生じる。バックアップバスの予約されたリソースは、バックアップバス沿いのトラヒックを搬送するために予約されたリソースが必要になる時刻まで、「ベストエフォート」トラヒックのような、他のトラヒックを搬送するのにも使用することができる。
バックアップLSPがワーキングパスLSP10と同じ帯域幅を有する場合、図3A乃至3Eに示す一組のバックアップパスは、ワーキングパスのそれに等しい量のリソースを必要とするにすぎない。例えば、ワーキングパスLSP10が、リンクA−B上に帯域幅Xを有すると仮定する。バックアップのワーキングパスも帯域幅Xを有する。図3B乃至3Eに示すさまざまなバックアップパスは、すべて、帯域幅XのリンクA−Bを使用する。いかなる時点でも、図3B乃至3Eに示すバックアップパスのうち1つだけが使用されるのだから、帯域幅Xの予約は1つだけ行われれば十分であり、すなわち、図3B乃至3Eに示す4つのパスは、4Xの予約は必要ない。ワーキングパスと1つ以上のバックアップパスとが同じルーティングを有するような状況では、ワーキングパスかバックアップパスの集合のうちの1つかいずれか一方だけがいかなる時点でも使用されるのだから、それらは同じリソースを共用することができる。一例として、ワーキングパス25の中のリンクA−Bは、図3B乃至3Eに示すバックアップパスにおいても使用される。これらのパスはすべて、同じリソースを共有することができる。
保護スイッチをもたらした元の障害からワーキングパスが復旧した時、トラヒックは、ワーキングパスLSP10へと戻される。各ノードは、障害を検出するのと同じやり方で(例えばOAM−CC、RSVP−TE hello)、ワーキングパスが動作中であることを検出する。障害が終了したことをノードが検出した場合、ノードは、RSVP−TE NOTIFYメッセージを用いて発側ノードにその情報を通知してもよい。
ここで、ネットワーク内のノードの動作について詳細に記述しよう。図4は、ノードの1つにおけるクロスコネクト機能60を略示する図である。ノードは、発側または着側通信リンクに接続しているポート61、62、63を有する。ノードが次のノードへトラヒックを転送する必要がある時、クロスコネクト機能60は、リング上の前のノードからトラヒックを受信する発側ポート61を、リング上の次のノードに接続する着側ポート62に接続する。結果として生じるクロスコネクト64を、ポート61とポート62とを接続する実線として示す。ノードが、リングから分岐して行くスパー(支線)にトラヒックを転送する必要がある時、クロスコネクトは、リング上の前のノードからトラヒックを受信する発側ポート61を、リングから分岐して行くスパー(支線)に接続する着側ポート63に接続するであろう。結果として生じるクロスコネクト65を、ポート61とポート63とを接続する点線として示す。ノードが、逆方向パスに沿って転送を行ってもよい。
図5は、ネットワークノードにおけるLSR40を略示する図である。LSR40は、他のLSRからトランスポートユニット(例えばパケットまたはデータのフレーム)を受信するためのネットワークインタフェース41を有する。ネットワークインタフェース41は、制御プレーンのシグナリングメッセージおよび管理プレーンメッセージを受信することもできる。システムバス42が、ネットワークインタフェース41を記憶装置(ストレージ)50およびコントローラ(制御装置)52に接続する。ストレージ50は、受信されたパケットが転送される前に、それらのための一時的なストレージ(記憶)機能を提供する。また、ストレージ50は、LSR40の転送動作を制御する制御データ51を記憶する。IETF用語では、転送データ51は、Label Forwarding Information Base(LFIB)と呼ばれる。
制御装置52は、LSRの動作を制御する一組の機能性モジュール53乃至57を含んでいる。制御プレーンモジュール53は、シグナリングおよびルーティングメッセージを他のネットワークノードと交換するわけだが、IPルーティングおよびLabel Distribution Protocolのための機能を内蔵していてもよい。制御プレーンモジュール53は、RSVP−TEシグナリングをサポートしてもよく、障害の発生をシグナリングして必要なバックアップLSPを起動させることによるトラヒック復旧動作を実施するためにLSR40が他のノードにシグナリングできるようにしてもよい。(もしあれば)管理プレーンモジュール54は、ネットワーク管理システムとのシグナリングを行って、LSPをセットアップできるようにする。OAMモジュール55は、リンク障害またはノード障害の発生を検出するために、OAMシグナリング、例えばContinuity Checkシグナリングをサポートする。データプレーン転送モジュール56は、受信されたトランスポートユニット(パケット)の転送をサポートするために、ラベルのルックアップおよびスイッチングを行う。データプレーン転送モジュール56は、LFIB51の中に記憶された転送データを使用する。データプレーン転送モジュール56とLFIB51との組み合わせが、図4に示すクロスコネクト機能を行う。復旧モジュール57は、適切なバックアップパスを選択する機能と、トラヒックを選択されたバックアップパスにスイッチする機能とを行う。これらの一組のモジュールは、機械で実行可能なコードのブロックとして実装されてもよく、それらが汎用プロセッサによって、または1つ以上の専用プロセッサまたは処理装置によって実行されてもよい。モジュールは、ハードウェアとして、またはハードウェアとソフトウェアとの組み合わせとして実装されてもよい。装置の機能性は、別個のモジュールの集合として示されているが、もっと小さな、またはもっと大きな集合がその機能性を実現しうるということは理解されるであろう。
図5には、ストレージエンティティ50が1つ示されているが、異なるタイプのデータを記憶するために複数のストレージエンティティが提供されうることは理解されるであろう。同様に、制御装置52が1つ示されているが、各種の制御機能を行うために複数の制御装置が提供されうることは理解されるであろう。例えば、パケットの転送は専用の高性能プロセッサによって行われ、その他の機能は別個のプロセッサによって行われてもよい。
図6は、ネットワークの管理プレーンの一部を成すネットワーク管理エンティティ30における装置を略示する図である。エンティティ30は、ネットワーク内のノードとの間でシグナリングメッセージを送受信するためのネットワークインタフェース31を有する。システムバス32は、ネットワークインタフェース31をストレージ33および制御装置36に接続している。ストレージ33は、ネットワークについての制御データ34、35を記憶している。制御装置36は、ワーキングパスおよびバックアップパスのためのルーティングを計算するパス演算モジュール38を含んでいる。シグナリングモジュール39は、ワーキングパスおよびバックアップパスを実施するための転送命令を記憶するようノードに指示するため、ノードと通信する。
図7は、ネットワーク内で復旧を構成するための方法のステップを要約した図である。ステップ71では、P2MPワーキングパスが、ソースノードと宛先ノードとの間で確立される。ステップ72では、ネットワーク障害が発生しうる位置について一組のP2MPバックアップパスが構成される。P2MPバックアップパスの各々は、ワーキングパスのノード(例えばヘッドノード)を、P2MPワーキングパスの宛先ノードに接続する。次のステップは、復旧スキームまたは保護スキームが必要かどうかによって決まる。
復旧スキームの場合には、方法は、ステップ73へ、そしてノードへのシグナリングへと進む。シグナリングは、バックアップパスをサポートするため、適切なリソース、例えば帯域幅を予約するようにノードに命令することを含んでもよい。しかし、ノードは、データプレーンレベルでリソースをクロスコネクトするように命令されることはない。これは、バックアップパスが完全に確立されていないことを意味し、従って、バックアップパスを完全に確立するためには、障害検出時に別のシグナリングが必要となる。
保護スキームの場合には、方法は、ステップ74へ、そしてノードへのシグナリングへと進む。シグナリングは、使用する準備が整うようにバックアップパスを完全に確立するようノードに命令する。これには、バックアップパスをサポートするため、適切なリソース、例えば帯域幅を予約することが含まれる。また、ノードは、データプレーンレベルでリソースをクロスコネクトするよう命令される。これは、バックアップパスが完全に確立されていることを意味し、従って、障害検出時にトラヒックを搬送する目的で別のシグナリングを行う必要がないことがありうる。
図8は、バックアップスイッチングの方法を実施するための、ネットワークのノードで行われるステップを要約した図である。有利には、ノードは、発側ノード、すなわちワーキングパスのヘッドノードであるが、ヘッドノードの下り側のノードであってもよいだろう。ステップ81で、ノードは、P2MPワーキングパスの一部を成すように構成される。ステップ82で、一組のP2MPバックアップパスが構成される。バックアップパスの各々は、ネットワーク障害が発生しうる位置に関連している。ステップ83で、ノードは、ワーキングパスで障害が発生したというインジケーション(指標)を受信して、障害発生位置(例えばリンクまたはノード)を特定する。次いで、ノードは、発生したばかりの障害発生位置に適したバックアップパスを選択して、バックアップパスをセットアップするためにバックアップ沿いのノードにシグナリングする。有利には、ノードは、必要なバックアップパスをサポートするために、バックアップパス沿いのノードに命令してデータプレーンでリソースをクロスコネクトさせる。バックアップパスがセットアップされたという指標をノードが受信すると、ステップ84でトラヒックがバックアップパスにスイッチされる。ステップ84のしばらく後で行われるステップ85で、ノードは、ワーキングパスが有効であるという指標を受信する。ステップ86で、ノードは、トラヒックを復旧させてワーキングパスへ戻す。
図1に示す、例示するP2MPワーキングパスLSP10は、ノードAにヘッドノードを有し、リングの周りをノードB乃至Fを介して時計回り方向に延在している分岐を1つ有する。理解されるであろうが、ワーキングパスLSP10は、異なるルーティングを有してもよいだろうし、バックアップパスの各々は、ワーキングパスLSPのルーティングをサポートするための適切なバックアップパスを提供するためのルーティングを有してもよいだろう。
図9および図10は、メッシュ型トポロジーを有するネットワークに適用されるP2MPワーキングパス91の一例を示す図である。P2MPワーキングパス91は、ノードAにルートノードを有し、F、H、I、Mに宛先ノードを有する。以前の例と同様、バックアップパスが、ワーキングパスの障害が発生しうる位置の各々について設けられている。図10に示すような、リンクA−Bの障害について考えてみよう。この障害発生位置について見込まれるバックアップLSP92を図10に示す。これは、パスA−C−B−F経由の宛先ノードFへの接続を提供する。図11は、この障害発生位置についての別の見込まれるバックアップLSP93を示す図であるが、こちらは、A−C−H−G−Fというパスを介して宛先ノードFへの接続を提供し、ノードHはワーキングパスのもう1つの宛先ノードである。バックアップパスは、例えばパスの長さ、パスの容量、パスのコストのような因子に基づいてプランニング(計画)されるであろう。
バックアップパスに必要なのは、ワーキングパスの宛先ノードと、宛先ノードに到達するために中継(通過)に参加しなければならないノードとに接続することだけである。図1、図2および図3A乃至3Eに示す例では、ワーキングパスは、ノードAを一組のノードB乃至Fに接続するのだが、それらはすべて宛先ノードであり、すなわち、トラヒックはこれらのノードにおいてリングに到着するのだから、トラヒックはB−Fの各ノードに到達しなければならない。従って、図3A乃至3Eに示す一組のバックアップLSPは、ノードAをノードB−Eの各々に接続する。図12は、図1と同じリング型トポロジーと、ルートノードとしてノードAを有し、宛先ノードとしてノードB、C、Fだけを有するワーキングパス26とを示す。ワーキングパス26は、ノードDおよびEを通るが、トラヒックはこれらのノード宛てではないのだから、これらは「中継」ノードであるにすぎない。図13は、リンクC−Dに障害がある場合のバックアップパス27を示す図である。バックアップパス27は、ノードAをノードB、C、Fだけに接続する。ノードDまたはEに接続する必要はない。また、同様に、図9乃至11のメッシュ型ネットワークの例は、ワーキングパスの宛先ノードと、宛先ノードに到達するために中継に参加する必要があるノードとに限って、バックアップパスがどのように接続するのかを表している。図13では、バックアップパス93はノードBを通らないが、それはノードBがワーキングパスの宛先ノードではないからである。
本書で開示された発明の修正形態およびその他の実施形態は、前述の記述および関連の図面の中に提示された教示内容の利点を有する当業者には思い当たるであろう。従って、理解されるべきだが、本発明は、開示された特定の実施形態に限定されるのではなく、修正形態およびその他の実施形態は、本開示の範囲内に含まれることが意図されている。本書では特定の用語が採用されていることがあるが、それらは一般的な説明的な意味においてのみ用いられているのであって、限定を目的としていない。
Claims (22)
- コネクション型のネットワークにおける第1ノードにトラフィックのリカバリーを実行させる方法であって、ポイント・ツー・マルチポイント型の現用パスがソースノードと複数の宛先ノードとの間に確立され、前記第1ノードは前記現用パスに接続しており、
前記第1ノードにおいて、前記現用パスにおいて障害が発生したことを示すインジケーションであって、障害の発生位置を識別するためのインジケーションを、受信する受信ステップと、
前記障害の発生位置に基づいて、複数のポイント・ツー・マルチポイント型の予備パスの1つを選択する選択ステップであって、当該複数のポイント・ツー・マルチポイント型の予備パスは、前記第1ノードと前記複数の宛先ノードとを接続しており、前記現用パスにおける複数の潜在的な障害の発生位置それぞれにポイント・ツー・マルチポイント型の予備パスが設けられているところの、前記選択ステップと、
前記選択ステップで選択されたポイント・ツー・マルチポイント型の予備パスでトラフィックを送信する送信ステップと
を有することを特徴とする方法。 - 前記インジケーションは、前記ネットワークにおける制御プレーンを介して受信されるシグナリングメッセージであることを特徴とする請求項1に記載の方法。
- 前記シグナリングメッセージは、RSVP−TEメッセージであることを特徴とする請求項2に記載の方法。
- 前記第1ノードは、前記ポイント・ツー・マルチポイント型の現用パスの前記ソースノードであることを特徴とする請求項1ないし3のいずれか1項に記載の方法。
- 前記選択ステップは、前記選択された予備パスを確立するために、データプレーンのレベルでリソースをクロスコネクトするよう、前記選択された予備パス上にある複数のノードにシグナリングで伝達することを特徴とする請求項1ないし4のいずれか1項に記載の方法。
- 前記複数のポイント・ツー・マルチポイント型の予備パスは、前記受信ステップにおいて障害が発生したことを示すインジケーションを受信するのに先立って、トラフィックを転送できるように設定されることを特徴とする請求項1ないし4のいずれか1項に記載の方法。
- 前記コネクション型のネットワークは、リング型のトポロジーを有していることを特徴とする請求項1ないし6のいずれか1項に記載の方法。
- 前記現用パスは、リングにおける第1の方向に沿って転送するように設定されており、
前記予備パスは、前記リングにおける反対方向に沿って転送するブランチを有していることを特徴とする請求項7に記載の方法。 - 前記複数の予備パスは、複数のリソースからなる共通のセットを共用していることを特徴とする請求項1ないし8のいずれか1項に記載の方法。
- 前記現用パスおよび前記予備パスは、マルチプロトコル・ラベルスイッチング(MPLS)またはマルチプロトコル・ラベルスイッチング・トランスポートプロファイル(MPLS−TP)型のコネクションであることを特徴とする請求項1ないし9のいずれか1項に記載の方法。
- コネクション型のネットワークにおいてトラフィックをリカバリーする方法であって、
前記ネットワークにおいて、ソースノードと複数の宛先ノードとの間にポイント・ツー・マルチポイント型の現用パスを設定する設定ステップと、
障害を検出するのに先立って、前記現用パスの第1ノードと、前記現用パスの前記複数の宛先ノードとの間に、複数のポイント・ツー・マルチポイント型の予備パスをプランニングするプランニングステップと
を有し、
前記現用パスにおける複数の潜在的な障害の発生位置それぞれにポイント・ツー・マルチポイント型の予備パスが設けられることを特徴とする方法。 - 前記第1ノードは、前記ソースノードであることを特徴とする請求項11に記載の方法。
- 前記ポイント・ツー・マルチポイント型の予備パスは、前記現用パスの宛先ノードと、前記現用パスの前記宛先ノードに至る際に通過することになるノードとにだけ接続されていることを特徴とする請求項11または12に記載の方法。
- 前記プランニングステップは、
前記障害を検出するのに先立って、前記複数のマルチポイント型の予備パスを設定するよう、ノードにシグナリングで伝達するステップを含み、
前記シグナリングによって、データプレーンのレベルでのリソースをクロスコネクトするよう、前記ノードが指示されることで、前記設定された予備パスがトラフィックを転送できる状態となることを特徴とする請求項11または12に記載の方法。 - 前記コネクション型のネットワークは、リング型のトポロジーを有していることを特徴とする請求項11ないし14のいずれか1項に記載の方法。
- 前記現用パスは、リングにおける第1の方向に沿って転送するように設定されており、
前記予備パスは、前記リングにおける反対方向に沿って転送するブランチを有していることを特徴とする請求項15に記載の方法。 - 前記複数の予備パスは、複数のリソースからなる共通のセットを共用していることを特徴とする請求項11ないし16のいずれか1項に記載の方法。
- 前記現用パスおよび前記予備パスは、マルチプロトコル・ラベルスイッチング(MPLS)またはマルチプロトコル・ラベルスイッチング・トランスポートプロファイル(MPLS−TP)型のコネクションであることを特徴とする請求項11ないし17のいずれか1項に記載の方法。
- コネクション型のネットワークの第1ノードで使用される装置であって、
ソースノードと複数の宛先ノードとの間のポイント・ツー・マルチポイント型の現用パスの一部を形成すよう、前記第1ノードを設定するための指示を受信するように構成された第1モジュールと、
前記現用パスの前記複数の宛先ノードに前記第1ノードを接続するポイント・ツー・マルチポイント型の予備パスの一部を形成するよう、前記第1ノードを設定するための指示を受信するように構成された第2モジュールであって、前記複数のポイント・ツー・マルチポイント型の予備パスは前記第1ノードを前記複数の宛先ノードへ接続し、前記現用パスにおける複数の潜在的な障害の発生位置それぞれにポイント・ツー・マルチポイント型の予備パスが設けられているところの、前記第2モジュールと、
前記現用パスにおける障害を示すインジケーションを受信するように構成された第3モジュールと、
前記障害の発生位置に基づいて、前記複数のポイント・ツー・マルチポイント型の予備パスのうちの1つを選択し、前記選択したポイント・ツー・マルチポイント型の予備パスにトラフィックを切り替えるように構成された第4モジュールと
を備えたことを特徴とする装置。 - 前記第1ノードは、前記現用パスにおける前記ソースノードであることを特徴とする請求項19項に記載の装置。
- 複数のノードを備えたコネクション型のネットワークにおける制御エンティティ装置であって、
前記ネットワークの複数の宛先ノードとソースノードとの間にポイント・ツー・マルチポイント型の現用パスを設定し、
障害を検出するのに先立って、前記現用パスの第1ノードと、前記現用パスの前記複数の宛先ノードとの間に、複数のポイント・ツー・マルチポイント型の予備パスをプランニングする
ように構成されていることを特徴とし、前記現用パスにおける複数の潜在的な障害の発生位置それぞれにポイント・ツー・マルチポイント型の予備パスが設けられている、制御エンティティ装置。 - 請求項1ないし18のいずれか1項に記載された方法をプロセッサに実行させることを特徴とする装置可読のプログラム。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2009/059150 WO2011006541A1 (en) | 2009-07-16 | 2009-07-16 | Recovery mechanism for point-to-multipoint traffic |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2012533246A true JP2012533246A (ja) | 2012-12-20 |
Family
ID=41059988
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012519896A Pending JP2012533246A (ja) | 2009-07-16 | 2009-07-16 | ポイント・ツー・マルチポイントのトラヒックのための復旧メカニズム |
Country Status (7)
Country | Link |
---|---|
US (1) | US20120207017A1 (ja) |
EP (1) | EP2454855A1 (ja) |
JP (1) | JP2012533246A (ja) |
CN (1) | CN102474446A (ja) |
BR (1) | BR112012000839A2 (ja) |
IL (1) | IL216890A0 (ja) |
WO (1) | WO2011006541A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015012531A (ja) * | 2013-07-01 | 2015-01-19 | 日本電気株式会社 | 通信システム、通信ノード、通信経路切替方法及びプログラム |
JP2017521965A (ja) * | 2014-07-24 | 2017-08-03 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | 複数ドメインネットワークにおけるセグメントルーティング |
JP7558921B2 (ja) | 2021-12-21 | 2024-10-01 | 古河電気工業株式会社 | 通信装置、路側装置、ネットワークシステム及び通信方法 |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8406243B2 (en) * | 2010-02-22 | 2013-03-26 | Telefonaktiebolaget L M Ericsson (Publ) | Fast LSP alert mechanism |
US8467289B2 (en) * | 2010-02-22 | 2013-06-18 | Telefonaktiebolaget L M Ericsson (Publ) | Optimized fast re-route in MPLS ring topologies |
WO2012079630A1 (en) * | 2010-12-15 | 2012-06-21 | Telefonaktiebolaget L M Ericsson (Publ) | Segment recovery in connection-oriented network |
CN102572618B (zh) * | 2010-12-17 | 2015-09-16 | 中兴通讯股份有限公司 | 一种基于g.709的多级复用路由控制方法和网关网元 |
JP5655696B2 (ja) | 2011-05-11 | 2015-01-21 | 富士通株式会社 | ネットワーク及びその障害救済方法 |
CN103210626A (zh) * | 2011-09-06 | 2013-07-17 | 华为技术有限公司 | 在环形拓扑上生成标签转发表的方法、装置和系统 |
CN102377601B (zh) * | 2011-10-14 | 2014-03-26 | 杭州华三通信技术有限公司 | 一种lsp故障通告方法和装置 |
CN102523160B (zh) * | 2011-12-15 | 2015-03-11 | 盛科网络(苏州)有限公司 | 以太网线性保护中快速切换的芯片实现方法及系统 |
JP2014064252A (ja) * | 2012-09-24 | 2014-04-10 | Hitachi Ltd | ネットワークシステム、伝送装置、及び障害情報通知方法 |
WO2015010324A1 (zh) * | 2013-07-26 | 2015-01-29 | 华为技术有限公司 | 一种预留中继资源的方法及装置 |
CN104767665B (zh) * | 2014-01-07 | 2018-01-12 | 维谛技术有限公司 | 一种环形通信网络主站冗余的方法、装置及系统 |
US9736558B2 (en) * | 2014-01-17 | 2017-08-15 | Cisco Technology, Inc. | Optical path fault recovery |
US9692693B2 (en) * | 2014-06-30 | 2017-06-27 | Juniper Networks, Inc. | Bandwidth control for ring-based multi-protocol label switched paths |
US9729455B2 (en) | 2014-06-30 | 2017-08-08 | Juniper Networks, Inc. | Multi-protocol label switching rings |
US10218611B2 (en) | 2014-06-30 | 2019-02-26 | Juniper Networks, Inc. | Label distribution protocol (LDP) signaled multi-protocol label switching rings |
CN105991434B (zh) * | 2015-02-05 | 2019-12-06 | 华为技术有限公司 | 一种环网中mpls报文转发的方法及网络节点 |
CN105337872B (zh) * | 2015-11-18 | 2018-05-04 | 东北大学 | 一种基于能效优先的控制层面网络划分方法 |
US11233748B1 (en) | 2018-08-30 | 2022-01-25 | Juniper Networks, Inc. | Bandwidth management for resource reservation label switched path of a ring network |
US20200136894A1 (en) * | 2018-10-24 | 2020-04-30 | General Electric Company | System and method for establishing reliable time-sensitive networks |
CN111294226B (zh) * | 2018-12-10 | 2023-05-09 | 华为技术有限公司 | 通信方法和装置 |
CN113079041B (zh) * | 2021-03-24 | 2023-12-05 | 国网上海市电力公司 | 一种业务流传输方法、装置、设备和存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004080532A (ja) * | 2002-08-20 | 2004-03-11 | Nippon Telegr & Teleph Corp <Ntt> | マルチキャストプロテクション方法及び装置及びマルチキャストプロテクションプログラム及びマルチキャストプロテクションプログラムを格納した記憶媒体 |
WO2006030435A2 (en) * | 2004-09-16 | 2006-03-23 | Alcatel Optical Networks Israel Ltd. | Efficient protection mechanisms for protecting multicast traffic in a ring topology network utilizing label switching protocols |
US20070201355A1 (en) * | 2006-02-27 | 2007-08-30 | Vasseur Jean P | Method and apparatus for determining a preferred backup tunnel to protect point-to-multipoint label switch paths |
JP2008206050A (ja) * | 2007-02-22 | 2008-09-04 | Nippon Telegr & Teleph Corp <Ntt> | 障害迂回方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体 |
WO2009080124A1 (en) * | 2007-12-21 | 2009-07-02 | Telecom Italia S.P.A. | Protecting an ethernet network having a ring architecture |
JP2011019092A (ja) * | 2009-07-09 | 2011-01-27 | Fujitsu Ltd | 通信装置および通信パス提供方法 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1754352B (zh) * | 2003-02-21 | 2011-09-21 | 日本电信电话株式会社 | 用于进行通信网络中的通道的故障救济的装置和方法 |
US7339887B2 (en) * | 2003-05-06 | 2008-03-04 | Overture Networks, Inc. | Multipoint protected switching ring |
US20060274645A1 (en) * | 2005-06-07 | 2006-12-07 | Richard Bradford | Methods and apparatus for error recovery in opaque networks using encrypted error locations |
US9166807B2 (en) * | 2005-07-28 | 2015-10-20 | Juniper Networks, Inc. | Transmission of layer two (L2) multicast traffic over multi-protocol label switching networks |
CN1866806B (zh) * | 2005-12-22 | 2011-11-02 | 华为技术有限公司 | 共享格状网恢复的实现方法 |
US9083551B2 (en) * | 2006-03-17 | 2015-07-14 | Tellabs Operations, Inc. | Method and apparatus for media distribution using VPLS in a ring topology |
WO2008107883A2 (en) * | 2007-03-08 | 2008-09-12 | Corrigent Systems Ltd. | Prevention of frame duplication in interconnected ring networks |
US8625410B2 (en) * | 2009-05-11 | 2014-01-07 | Ciena Corporation | Dual homed E-spring protection for network domain interworking |
-
2009
- 2009-07-16 JP JP2012519896A patent/JP2012533246A/ja active Pending
- 2009-07-16 US US13/384,054 patent/US20120207017A1/en not_active Abandoned
- 2009-07-16 EP EP09780708A patent/EP2454855A1/en not_active Withdrawn
- 2009-07-16 BR BR112012000839A patent/BR112012000839A2/pt not_active IP Right Cessation
- 2009-07-16 CN CN2009801606001A patent/CN102474446A/zh active Pending
- 2009-07-16 WO PCT/EP2009/059150 patent/WO2011006541A1/en active Application Filing
-
2011
- 2011-12-11 IL IL216890A patent/IL216890A0/en unknown
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004080532A (ja) * | 2002-08-20 | 2004-03-11 | Nippon Telegr & Teleph Corp <Ntt> | マルチキャストプロテクション方法及び装置及びマルチキャストプロテクションプログラム及びマルチキャストプロテクションプログラムを格納した記憶媒体 |
WO2006030435A2 (en) * | 2004-09-16 | 2006-03-23 | Alcatel Optical Networks Israel Ltd. | Efficient protection mechanisms for protecting multicast traffic in a ring topology network utilizing label switching protocols |
US20070201355A1 (en) * | 2006-02-27 | 2007-08-30 | Vasseur Jean P | Method and apparatus for determining a preferred backup tunnel to protect point-to-multipoint label switch paths |
JP2008206050A (ja) * | 2007-02-22 | 2008-09-04 | Nippon Telegr & Teleph Corp <Ntt> | 障害迂回方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体 |
WO2009080124A1 (en) * | 2007-12-21 | 2009-07-02 | Telecom Italia S.P.A. | Protecting an ethernet network having a ring architecture |
JP2011019092A (ja) * | 2009-07-09 | 2011-01-27 | Fujitsu Ltd | 通信装置および通信パス提供方法 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015012531A (ja) * | 2013-07-01 | 2015-01-19 | 日本電気株式会社 | 通信システム、通信ノード、通信経路切替方法及びプログラム |
JP2017521965A (ja) * | 2014-07-24 | 2017-08-03 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | 複数ドメインネットワークにおけるセグメントルーティング |
JP7558921B2 (ja) | 2021-12-21 | 2024-10-01 | 古河電気工業株式会社 | 通信装置、路側装置、ネットワークシステム及び通信方法 |
Also Published As
Publication number | Publication date |
---|---|
BR112012000839A2 (pt) | 2019-09-24 |
EP2454855A1 (en) | 2012-05-23 |
CN102474446A (zh) | 2012-05-23 |
IL216890A0 (en) | 2012-02-29 |
WO2011006541A1 (en) | 2011-01-20 |
US20120207017A1 (en) | 2012-08-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2012533246A (ja) | ポイント・ツー・マルチポイントのトラヒックのための復旧メカニズム | |
EP1111860B1 (en) | Automatic protection switching using link-level redundancy supporting multi-protocol label switching | |
JP5200169B2 (ja) | ラベルスイッチパスの入口および出口の保護 | |
CN101286892B (zh) | 进行业务恢复的装置和方法 | |
US7133358B2 (en) | Failure control unit | |
US7835267B2 (en) | Dynamic path protection in an optical network | |
EP1986370B1 (en) | Control system, data message transmission method and network device in the ethernet | |
EP1845656B1 (en) | A method for implementing master and backup transmission path | |
EP2068497B1 (en) | Method and device for providing multicast service with multiple types of protection and recovery | |
US8335154B2 (en) | Method and system for providing fault detection and notification for composite transport groups | |
US9450778B2 (en) | P2MP traffic protection in MPLS-TP ring topology | |
CN101459535A (zh) | 进行业务恢复的装置和方法 | |
EP2652918B1 (en) | Segment recovery in connection-oriented network | |
EP3869747A1 (en) | Resolving label depth and protection in segment routing | |
Papán et al. | Overview of IP fast reroute solutions | |
EP2658177B1 (en) | Method for detecting tunnel faults and traffic engineering node | |
JP6408615B2 (ja) | 二重接続リングネットワーク保護方法及び装置 | |
CN101483491A (zh) | 共享保护环及其组播源路由保护方法和节点 | |
WO2011079967A1 (en) | Shared path recovery scheme | |
EP3139527B1 (en) | Protection switching method, node and control device | |
EP2101452A1 (en) | Methods and systems for recovery of bidirectional connections | |
EP2975809B1 (en) | Providing protection to a service in a communication network | |
Kamal | Gmpls-based hybrid 1+ N link protection over p-cycles: Design and performance | |
CN117979331A (zh) | 小颗粒跨域业务保护倒换方法、系统及设备 | |
Lackovic et al. | Overview of resilience schemes in photonic transmission network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130520 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130524 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20131018 |