JP2015524201A - ダウンストリーム通知パケットを用いたプロトコル独立マルチキャスト（ｐｉｍ）高速再ルーティング方法論の強化 - Google Patents

Abstract

障害検出メカニズムは、ＰＩＭ—ＳＭに基づく高速再ルーティング技術への強化を提供する。ネットワークノードは、接続の損失の検出に応じて、当該ネットワークノードがマルチキャストデータトラフィックを再ルーティングできるかを判定する。上記ネットワークノードが、障害のないセカンダリパスを有しない場合には、上記ネットワークノードは、通知パケットを発信し、当該通知パケットをマルチキャストツリーのダウンストリーム部分へ送信することができる。上記通知パケットは、冗長なセカンダリパスへ切り替えて、上記マルチキャストデータトラフィックを再ルーティングするように、１つ以上のダウンストリームノードをトリガすることができる。【選択図】図４Ｂ

Description

関連出願へのクロスリファレンス
この出願は、２０１２年６月１日に出願された「アップストリームアクティベーションパケットを用いたＰＩＭ高速再ルーティングへの強化（ENHANCEMENTS TO PIM FAST RE-ROUTE WITH DOWNSTREAM NOTIFICATION PACKETS）」と題する出願（代理人整理番号４９０６Ｐ３７６３７ＵＳ１）及び「データプレーン通知を用いたＭｏＦＲＰの失敗範囲の増加（INCREASING FAILURE COVERAGE OF MOFRR WITH DATAPLANE NOTIFICATIONS）」と題する出願（代理人整理番号４９０６Ｐ３６７５６ＵＳ１）と関連する。

本発明の実施形態は、ネットワーク動作の分野、より具体的にはマルチキャスト通信ネットワーク内でのルーティング動作に関する。

ＰＩＭ−ＳＭ（Protocol Independent Multicast Sparse Mode）（２００６年８月のＩＥＴＦ ＲＦＣ４６０１を参照）は、周知であり、インターネットプロトコル（ＩＰ）マルチキャスト通信ネットワーク内のマルチキャストツリーを構築し維持するための一般に採用されるプロトコルである。上記マルチキャスト通信ネットワークの受信ノード（以降、「宛先（destination）」とも呼ばれる）にマルチキャストコンテンツを配信するために、ＰＩＭ−ＳＭは、単一のマルチキャストツリーを使用する。単一のマルチキャストツリーは、ネットワーク障害の場合にマルチキャストトラフィックを再ルーティングするための冗長性に欠ける。

ＰＩＭ−ＳＭは、今日、リアルタイムトラフィック（例えば、インターネットプロトコルテレビジョン（ＩＰＴＶ））のためのマルチキャストパスを構築するために一般に使用される。しかしながら、ＰＩＭ−ＳＭは、ユニキャストルーティングに強く依存するので、ネットワーク障害の場合には、マルチキャストの回復は、ユニキャストルーティングが回復するまで待つ必要がある。よって、ＰＩＭ−ＳＭについての障害のリアクションは、比較的遅く、したがって、リアルタイムアプリケーションについて深刻な欠点である。この欠点を克服するため、２０１０年１月のＩＥＴＦ ＲＦＣ５７１４は、インターネットプロトコル（ＩＰ）高速再ルーティングメカニズム（Internet Protocol (IP) fast re-route mechanism）を提案する。当該ＩＰ高速再ルーティングメカニズムは、ネットワークノードの入力（incoming）マルチキャストストリームのためのセカンダリパスを使用し、それによって、ネットワークノードがプライマリアップストリームネイバノードとの接続を失った場合に即時の代替パスを提供する。しかしながら、提案されたアプローチは、効率的な障害検出技術を提供せず、起こり得る全ての障害シナリオを扱うわけではない。さらに、提案されたアプローチは、「ライブ−ライブ（live-live）」保護技術である。これは、「セカンダリ」トラフィックが障害のない状況であっても常に存在することを意味する。このセカンダリトラフィックは、マルチキャストネットワーク内でかなりの余分な負荷を引き起こし得る。

高速再ルーティングメカニズムが、マルチキャストツリーに冗長性を提供するための一連のセカンダリパスを含むマルチキャスト通信ネットワークのために説明される。上記マルチキャストツリーは、共通ソースノードから１つ以上のマルチキャスト受信ノードへの接続性を提供する。上記マルチキャストツリーのプライマリパスの障害の場合に、上記マルチキャストデータトラフィックは、上記セカンダリパスのうちの１つ以上へ再ルーティングされる。

本発明の実施形態によれば、マルチキャスト通信ネットワーク内のネットワークノードにより実行される方法は、上記ネットワークノードにより、前記ネットワークノードのプライマリパス上のアップストリームネイバへの入力インターフェースで接続の損失を検出することと、上記ネットワークノードが、上記マルチキャストデータトラフィックが上記マルチキャスト受信ノードにより受信されることを可能にするために、上記マルチキャストデータトラフィックを再ルーティングすることができないと判定することと、１つ以上のマルチキャスト受信ノードに向けて下流に通知パケットを送信することと、を含む。上記通知パケットは、１つ以上のダウンストリームノードに、上記セカンダリパスのうちの１つ以上へマルチキャスト受信を切り替えさせて、上記マルチキャストデータトラフィックを再ルーティングさせる。

本発明の実施形態によれば、マルチキャスト通信ネットワーク内のネットワークノードは、マルチキャストデータトラフィックについての転送情報を記憶するメモリと、当該メモリに結合される１つ以上のプロセッサと、当該１つ以上のプロセッサに結合される送信機回路及び受信機回路とを含む。上記１つ以上のプロセッサは、上記ネットワークノードの上記プライマリパス上のアップストリームネイバへの入力インターフェースで接続の損失を検出するように構成される検出モジュールと、上記マルチキャストデータトラフィックが上記マルチキャスト受信ノードにより受信されることを可能にするために上記ネットワークノードが上記マルチキャストトラフィックを再ルーティングできないと判定するように構成される判定モジュールとを含む。上記送信機回路は、１つ以上のマルチキャスト受信ノードに向けて下流に通知パケットを送信するように構成される。上記通知パケットは、１つ以上のダウンストリームノードに、上記セカンダリパスのうちの１つ以上へマルチキャスト受信を切り替えさせて、上記マルチキャストデータトラフィックを再ルーティングさせる。

本発明は、添付の図面の図において、例示のために説明され、限定のために説明されない。図面では、類似の参照番号（reference）は、同様の要素を示す。この開示における「実施形態（”a” embodiment）」又は「一実施形態（”one” embodiment）」への異なる言及（reference）は、必ずしも同じ実施形態へのものではなく、そのような言及は少なくとも１つを意味する、ということに留意されるべきである。さらに、特定の特徴（feature）、構造（structure）又は特性（characteristic）が実施形態に関連して説明される場合に、明示的に説明されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造又は特性をもたらすことは当業者の知識の範囲内であると考えられる。
マルチキャスト通信ネットワークの例を説明する。 マルチキャスト通信ネットワークの例を説明する。 ＭＲＴにより提供されるマルチキャスト冗長ツリーの例を説明する。 ＭＲＴにより提供されるマルチキャスト冗長ツリーの例を説明する。 ＭｏＦＲＲにより提供される冗長なセカンダリパスを伴うマルチキャストツリーの例を説明する。 ＭｏＦＲＲにより提供される冗長なセカンダリパスを伴うマルチキャストツリーの例を説明する。 ＭｏＦＲＲにより提供される冗長なセカンダリパスを伴うマルチキャストツリーの例を説明する。 本発明の一実施形態によるマルチキャスト通信ネットワークのネットワークノードが従うルールの収集を説明する。 通知パケットを処理するための方法の実施形態を説明するフロー図である。 ネットワークノードの実施形態を説明するブロック図である。 ラインカードプロセッサの実施形態を説明するブロック図である。 通知パケットを生成し下流に送信してマルチキャストデータトラフィックを再ルーティングする方法の実施形態を説明するフロー図である。 ＭＲＴに従ってネットワークノード内に記憶される転送テーブルの実施形態を説明する。 ＭｏＦＲＲに従ってネットワークノード内に記憶される転送テーブルの実施形態を説明する。 アクティベーションパケットを生成し送信してセカンダリパスをアクティベートするための方法の実施形態を説明するフロー図である。

以下の説明では、多くの具体的な詳細が説明される。しかしながら、本発明の実施形態はこれらの具体的な詳細の外で実践され得るということが理解される。他の例では、この説明の理解を不明りょうにしないために、周知の回路、構造及び技術は詳細には示されていない。しかしながら、本発明はそのような特定の詳細の外で実践され得るということは当業者により理解されるであろう。当業者は、含まれている説明とともに、過度な実験なしで適当な機能性を実装することができるであろう。

本発明の実施形態は、ＰＩＭ−ＳＭに基づくＩＰ高速再ルーティング技術に強化を提供する。ネットワーク障害が発生する場合に、マルチキャストデータトラフィックは、１つ以上の冗長なセカンダリパスを介して再ルーティングされる。これらのセカンダリパスは、障害の前に予め算出され、プライマリパス及びセカンダリパスに沿った転送情報は、ネットワークノードのデータプレーンに記憶される。よって、障害の検出に応じて、制御プレーンにおけるルーティングコンバージェンスを待つことなく、再ルーティングが高速で実行されることが可能である。本発明の実施形態は、以下に詳細に説明されるように、障害検出の速度及び帯域利用の効率性にも強化を提供する。

本発明の実施形態を説明する前に、ＰＩＭ−ＳＭに従ってネットワークノードがどのようにマルチキャストグループに参加するかを理解することが有用である。ＰＩＭ−ＳＭでは、ネットワークノードは、マルチキャストグループに参加し、又はマルチキャストグループから抜けるために、ユニキャスト転送メッセージを使用する。マルチキャストグループに参加するために、ネットワークノードは、マルチキャストツリーのアップストリーム方向で共通ソースノードへＪＯＩＮメッセージを送信する（「共通ソースノード」という用語は、以下では、マルチキャストソースノード、又は共用ツリーの場合にはランデブーポイントと呼ばれる）。ＪＯＩＮメッセージは、ＭＲＩＢ（Multicast Routing Information Base）テーブルにより決定されるマルチキャストツリーのパスに沿ってルーティングされる。これらのテーブル内でリスト化されたパスは、通常、ユニキャストルーティングテーブルから直接的に得られるが、上記パスは、異なるように得られることも可能である。同様に、マルチキャストグループを抜けたいネットワークノードは、上記マルチキャストツリーの上方に上記共通ネットワークノードへＰＲＵＮＥパケットを送信する。

ＭＲＩＢテーブルは、次にＪＯＩＮメッセージが送信される次ホップネイバを決定するために使用される。ＪＯＩＮメッセージは、マルチキャストコンテンツを既に受信しているネットワークノードに到達するまで、ホップごとベースでルーティングされ、処理される。このホップごとのパスに沿った全てのネットワークノードは、ＪＯＩＮメッセージを処理し、例えば、ＪＯＩＮメッセージが受信された入力インターフェースをマルチキャストの出力インターフェースリストに追加することにより、対応するマルチキャストルーティング情報を導入し、又は更新する。例えば、ノードＸは、ノードＹへの入力インターフェースを介してＪＯＩＮメッセージを受信すると、マルチキャストのための出力インターフェースのリストにノードＹを追加する。マルチキャストコンテンツは、ＪＯＩＮメッセージが受信される方向とは逆の方向でネットワークノードへルーティングされる。

ＭｏＦＲＲ（Multicas only Fast Re-Route）は、ネットワークノードが１つ以上のパスを介してマルチキャストグループに参加するＩＰ高速再ルーティングメカニズムである。マルチキャストグループに参加することは、プライマリパス上でノードからソースに向けてＪＯＩＮメッセージを送信すること、及び、セカンダリパス上で当該ノードから当該ソースに向けて別のＪＯＩＮメッセージを送信することを伴う。デュアル接続（dual-joining）ノードが、プライマリパス上の接続を失うと、当該ノードは、当該ノードが切り替えることができる利用可能なセカンダリパスを即時に有する。

ＭｏＦＲＲによれば、各デュアル接続ノードは、プライマリパス上のプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、セカンダリパス上のセカンダリＵＭＨとを有する。各ＵＭＨは、マルチキャスト入口ノード（Multicast Ingress node：ＭＣＩ）に向かうパス上でノードから上流側の前ホップネイバである。ＭＣＩは、マルチキャストストリームが現在のトランスポート技術（例えば、ＰＩＭ）ドメインに入るノードである。したがって、ＭＣＩを、現在のドメインについてのマルチキャストソースとみなすことが可能である。本明細書において、「ＭＣＩ」という用語は、マルチキャストソースノードと同義語として用いられる。本発明の実施形態は、異なるトランスポート技術ドメイン内に位置するマルチキャストソースノードからのマルチキャストデータをＭＣＩが受信する場合など、ＭＣＩが一般的な意味でマルチキャストノードとは異なるシナリオに適用可能である、ということが理解される。

ＭｏＦＲＲによれば、デュアル接続ノード（Ｊ）のセカンダリＵＭＨを、ノード候補（即ち、前のホップのアップストリームノード）のリストから選択することができる。上記ノード候補は、ＭＣＩに向けたパス上におけるノードＪのＥＣＭＰ又はＬＦＡネイバからくる。ノードＪがプライマリＵＭＨに到達するためのコストと同じコストでノードＮがノードＪから到達可能である場合に、ノードＮはノードＪのＥＣＭＰネイバである。ＲＦＣ５２８９（２００８年９月）に規定されているＬＦＡ基準（criteria）の１つ、又はｄｒａｆｔ−ｋａｒａｎ−ｍｏｆｒｒ−０２（２０１２年３月）において説明されているＭｏＦＲＲについての非ＥＣＭＰモード条件の１つが満たされる場合に、ノードＮは、ノードＪのＬＦＡネイバである。

ＭＲＴ（Maximally Redundant Trees）を用いた高速再ルーティングは、別のＩＰ高速再ルーティングメカニズムである。当該別のＩＰ高速再ルーティングメカニズムは、各宛先ノードに最大限に冗長な２つのツリーを提供する。慣例により、これらの２つのツリーは、ブルー（プライマリ）ツリー及びレッド（セカンダリ）ツリーと呼ばれる。最大限に冗長なツリーのペアが各ノードにおいて算出され定着すれば、単一のリンク又はノードの障害の場合に、全てのノードは、上記ツリーのうちの１つに沿って到達可能なままである。よって、ノードは、レッドツリー（red tree）とブルーツリー（blue tree）の両方にデュアル接続（dual-join）することができ、単一のリンク／ノード障害の場合に、１つのツリーから別のツリーに切り替えることができる。

ＭｏＦＲＲ及びＭＲＴの両方は、デュアル接続ノードがプライマリパス及びセカンダリパスの両方から同一のマルチキャストストリームを受信するライブ−ライブ（live-live）マルチキャスト保護技術を実装する。ネットワークトラフィックがプライマリパス及びセカンダリパスの両方で帯域を継続的に消費するので、ライブ−ライブマルチキャスト保護技術は、障害のないシナリオでは２倍の帯域消費を招く。

二重のパケットがエンドユーザへ転送されるのを防ぐために、ライブ−ライブ保護モードで動作するネットワークでは、デュアル接続ノードは、ＵＭＨのうちの１つからのパケットのみを同時に受け付ける。どちらのＵＭＨが望ましいかは、ＩＧＰ（Interior Gateway Protocol）の到達性（reachability）、リンク状態、ＢＦＤ（Bidirectional Forwarding Detection）、トラフィックフローなどに基づくことができる局所決定である。上記ネットワーク内でいずれの障害も検出されない場合には、より望ましくないＵＭＨへの入力インターフェースをブロックすることにより、二重のパケットの受信を防ぐことができる。即ち、この入力インターフェースから受信されるパケットは、マルチキャストツリー上で転送されない。しかしながら、より望ましいＵＭＨに障害が起こる場合には、トラフィックがダウンストリームを継続することを可能にするために、より望ましくはないＵＭＨへの上記入力インターフェースのブロック解除（unblock）を行うことができる。

本明細書では、「アップストリーム／上流（upstream）」という用語は、パスに沿ってＭＣＩに向かう方向に言及し、「ダウンストリーム／下流（downstream）」という用語は、パスに沿ってＭＣＩから離れる方向に言及する。さらに、「ネイバノード（neighboring node）」は、現在のノードから１ホップ離れたノードである。「前のホップ（previous hop）」は、現在のノードのアップストリームネイバノードであり、「次のホップ（next hop）」は、現在のノードのダウンストリームネイバノードである。「ブランチノード」は、下流に行く１つ以上のパスに結合されるノードである。「マージノード」は、上流から来る１つ以上のパスに結合されるノードである。

さらに、「リンク」、「インターフェース」又は「ネイバ」は、「物理的な」又は「仮想的な」リンク、インターフェース又はネイバを意味し得る。「物理的な」リンクは、２つ以上のノード間の直接的な接続を意味する。物理的なインターフェース又はネイバは、物理的なリンクを介して他のインターフェース／ノードに結合されるインターフェース／ノードを意味する。「仮想的な」リンクは、２つのノード間の低レイヤのトンネル又は複雑なネットワークであり得る。仮想的なインターフェース／ノードは、仮想的なリンクを介して別のインターフェース／ノードに結合されるインターフェース／ノードを意味する。例えば、複雑なイーサネットネットワークを介して接続される２つのＩＰルータは、ＩＰレベルでは「仮想的なネイバ」である。

本発明の実施形態は、ＭｏＦＲＲ及びＭＲＴに基づく既存の技術よりも、帯域効率がより良好であり、リアクションがより高速であるＰＩＭ−ＳＭに基づく高速再ルーティングメカニズム（fast re-route mechanism）を提供する。帯域効率性に関して、本発明の実施形態は、障害の検出までバックアップ（セカンダリ）パスが待機（standby）しているライブ−スタンバイ（待機）（live-standby）モードを提供する。待機パス（standby pass）は、ネットワーク内に障害がない場合には、マルチキャストデータパケットを搬送せず、それによって、ネットワーク帯域の消費を減少させる。一実施形態では、マルチキャストフローがブロックされるネットワークのブランチポイントでアップストリームアクティベーションパケット（ＵＡＰ）が受信される場合に、待機パスがアクティベートされる。障害へのリアクションの速度に関して、本発明の実施形態は、ネットワークノードが障害を検出する場合に当該ネットワークノードのデータプレーン内で生成され処理されるダウンストリーム高速通知パケット（downstream fast notification packet：ＤＦＮＰ）を提供する。ＤＦＮＰの使用は、非局所障害（即ち、遠隔障害、又は、同等に、１つ以上のホップだけ離れたノード又はリンクで発生した障害）へのリアクションについての速度及び信頼性を改善する。ＵＡＰ及び／又はＤＦＮＰは、ＭＲＴ又はＭｏＦＲＲをサポートするマルチキャストネットワーク内で使用されることが可能である。

図１Ａは、複数のネットワークノードを含むマルチキャスト通信ネットワーク１２を説明する。マルチキャストネットワーク１２は、オペレータのネットワークである。共通ソースノード（例えば、ノードＳ１１）は、マルチキャストツリー技術を介して、マルチキャストグループのメンバへマルチキャストデータを送信する。共通ソースノードは、マルチキャストグループのＭＣＩ又はブランチノードであり得る。マルチキャスト出口ノード（Multicast Egress Node：ＭＣＥ）とも呼ばれるマルチキャスト受信ノード（例えば、Ｒ１４）は、マルチキャストの加入者に結合されるノード、又は、マルチキャストの加入者がいるネイバドメインに結合されるドメイン出口ノードである。マルチキャストツリーのリーフノード（leaf node）は、典型的にはＭＣＥである。共通ソースノードとマルチキャストツリーのリーフノードとの間には、多数の内部ノード（例えば、Ｎ１３）がある。マルチキャストデータは、内部ノードを介して共通ソースノードからリーフノードへ下流に流れる。一実施形態では、１つ以上の内部ノードは、ＭＣＥでもあり得る。

図１Ｂは、マルチキャスト通信ネットワーク１００についてのネットワーク構成の例を説明する。１つ以上のノードは、ＭＣＩとノードＡとの間で図１Ｂから省略され得る。マルチキャスト通信ネットワーク１００は、以下の説明において例示的なネットワークとして使用される。

図２Ａ及び図２Ｂは、図１のマルチキャスト通信ネットワーク１００に基づいて構成されるＭＲＴマルチキャストツリー（ブルーツリー２１０及びレッドツリー２２０）の例を説明する。ブルーツリー２１０及びレッドツリー２２０の両方は、有向ツリー（directed tree）である。図２Ａのブルーツリー２１０をプライマリマルチキャストツリーとして指定することができる。ブルーツリー２１０内の各細い矢印は、ＭＣＩと所与のノードとの間のプライマリパス又はその一部を示す。図２Ｂのレッドツリー２２０をセカンダリマルチキャストツリーとして指定することができる。レッドツリー２２０内の各太い矢印は、ＭＣＩと所与のノードとの間のセカンダリパス又はその一部を示す。「ライブ−ライブ」保護モードが実装されるシナリオでは、ネットワーク内に障害がない場合であっても、ブルーツリー２１０及びレッドツリー２２０の両方が帯域を消費する。レッドツリー２２０内の太い矢印は、ネットワーク内で障害がない場合において余分である帯域消費を示す。後に詳細に説明される本発明の実施形態によれば、ＭＲＴマルチキャストツリーは、ノード／リンクの障害が検出されるまでレッドツリー２２０がいずれの帯域も消費しない「ライブ−スタンバイ」モードで動作し得る。

図３Ａ−図３Ｃは、ＭｏＦＲＲをサポートするネットワークセグメントの例を説明する。図３Ａは、図１のマルチキャスト通信ネットワーク１００内のネットワークセグメント３１０の例を説明する。ノードＣは、ネットワークセグメント３１０内で唯一のＭＣＥであると仮定する。ＭＣＩ→Ａ→Ｂ→Ｃを接続するトップの細い線は、ＰＩＭ−ＳＭにより定義されるプライマリマルチキャストツリーを形成する。このマルチキャストツリー内の各リンクは、プライマリパスを表す。Ａ→Ｊ→Ｃを接続する太い線は、ノードＣのためにＭｏＦＲＲにより追加されるセカンダリバックアップパスを表す。よって、ノードＣは、この例ではデュアル接続ノードである。「ライブ−ライブ」保護モードでは、これらの太い線は、ネットワーク内に障害が存在しない場合における余分な帯域の利用を表す。「ライブ−スタンバイ」モードでは、太い線は、いずれの帯域も消費しない。ＭｏＦＲＲは、必ずしも全てのノードにバックアップパスを提供するわけではない。例えば、ノードＡの障害のための保護はない。

図３Ｂは、図１のマルチキャスト通信ネットワーク１００内のネットワークセグメント３２０の別の例を説明する。ノードＣ、Ｅ及びＧがネットワークセグメント３２０内のＭＣＥであると仮定する。ＭＣＩ→Ａ→Ｂ→Ｃ→Ｄ→Ｅ及びＭＣＩ→Ｆ→Ｇを接続するトップの細い線は、ＰＩＭ−ＳＭにより定義されるマルチキャストツリーを形成する。ノードＪ及びＫを接続する太い線は、ノードＣ及びＥのためにＭｏＦＲＲにより追加されるセカンダリバックアップパスを表す。よって、ノードＣ及びＥは、この例では両方ともデュアル接続ノードである。「ライブ−ライブ」保護モードでは、これらの太い線は、ネットワーク内に障害が存在しない場合における余分な帯域の利用を表す。「ライブ−スタンバイ」モードでは、太い線は、いずれの帯域も消費しない。ネットワークセグメント３２０では、ＭｏＦＲＲは、ノードＡ、Ｃ又はＦの障害のために、いずれの保護も又は十分な保護を提供しない。

図３Ｃは、図１のマルチキャスト通信ネットワーク内のネットワークセグメント３３０のさらに別の例を説明する。ノードＣ、Ｅ及びＧは、マルチキャストストリームのためのＭＣＥである。ノードＣ、Ｅ及びＧは、マルチキャストストリームのためのＭＣＥである。この例では、ＭｏＦＲＲは、ノードＣ及びＥに加えてノードＤに保護を提供する。ノードＧからノードＤまでを接続する太い線は、ノードＤのためにＭｏＦＲＲにより追加されるセカンダリバックアップパスを表す。よって、ノードＣ、Ｄ及びＥは、この例では両方ともデュアル接続ノードである。「ライブ−ライブ」保護モードでは、これらの太い線は、ネットワーク内に障害が存在しない場合における余分な帯域の利用を表す。「ライブ−スタンバイ」モードでは、太い線は、いずれの帯域も消費しない。しかしながら、図３Ｃでは、ノードＡ又はＦの障害のために、いずれの保護も又は十分な保護がまだない。

上述の例では、各デュアル接続ノードはプライマリＵＭＨ及びセカンダリＵＭＨを有すると見ることができる。ＭｏＦＲＲに基づく実施形態について、各デュアル接続ノードは、ＥＣＭＰ又はＬＦＡに基づいてセカンダリＵＭＨを選択する。ＭＲＴに基づく実施形態について、各デュアル接続ノードは、冗長ツリー（redundancy tree）（例えば、ブルーツリー及びレッドツリー）に基づいて、ＥＣＭＰ又はＬＦＡに基づいてセカンダリＵＭＨを選択する。例えば、図２Ａ及び図２Ｂでは、ノードＩは、ＭＣＩからのノードＤのプライマリパス上にあり、ノードＣは、ＭＣＩからのノードＤのセカンダリパス上にあるので、ノードＤのプライマリＵＭＨは、ノードＩであり、セカンダリＵＭＨは、ノードＣである。図３Ｃの例では、ＭＣＩからのノードＣのプライマリパスは、ＭＣＩ→Ａ→Ｂ→Ｃであり、ＭＣＩからのノードＣのセカンダリパスは、ＭＣＩ→Ａ→Ｊ→Ｃである。よって、ノードＣのプライマリＵＭＨは、ノードＢであり、セカンダリＵＭＨは、ノードＪである。ノードＢは、プライマリＵＭＨとしてノードＡを有するが、セカンダリＵＭＨを有しない。

一実施形態では、（プライマリＵＭＨ又はプライマリＵＭＨへ接続するリンクの障害により引き起こされ得る）局所障害をノードが検出する場合に、ノードは、マルチキャストグループ内のダウンストリームノードに接続する全てのダウンストリームブランチへＤＦＮＰを発信する。ＭＲＴ又はＭｏＦＲＲに基づくマルチキャストネットワークのためにＤＦＮＰを使用することができる。ＭｏＦＲＲに基づく実施形態について、ダウンストリームブランチは、ダウンストリームノードに続くプライマリパス及びセカンダリパス上の全てのリンクを含む。ＭＲＴに基づく実施形態について、ダウンストリームブランチは、障害が検出されるツリー上のダウンストリームノードに続く全てのブランチを含む。ＤＦＮＰを発信するノードは、フォールバックできる障害のないセカンダリパスを有する障害検出ノードである。上記障害検出ノードは、利用可能なセカンダリパスを有する場合には、セカンダリパスを使用してマルチキャストデータを受信することができ、ＤＦＮＰは生成されない。ＤＦＮＰが生成される場合には、利用可能なセカンダリパスを有するダウンストリームノードは、ＤＦＮＰによりトリガされて、セカンダリパスへの切替えを行うことができる。

制御プレーンからの入力なしでデータプレーン内で利用可能な転送情報のみを使用して、データプレーン内でＤＦＮＰを生成することができる。ＤＦＮＰが受信される場合に、データプレーン内で当該ＤＦＮＰを処理することもできる。ＤＦＮＰを送受信するのに必要な全ての情報は、ネットワーク障害の発生前にデータプレーン内で利用可能である。データプレーンのみのアプローチは、障害の発生時にリアクション時間を大幅に減らす。一実施形態では、データプレーン内の１つ以上のラインカード内でＤＦＮＰの発信及び処理を行うことができる。リアルタイムでの障害復旧に影響を与えずに制御プレーン（例えば、ルーティングテーブル）の更新をすぐ後に行うことができる。

障害が非局所アップストリーム位置で発生する場合には、デュアル接続ノードは、アップストリーム障害を検出するための高速で信頼できるメカニズムが必要である。ＭｏＦＲＲに基づく実施形態について、デュアル接続ノードは、他のアップストリームノードが障害を迂回することができないことを知ることも必要である。トラフィック監視に基づく既存の方法は、範囲が限定されており、安定状態のパケットフローを用いて最良に機能する。例えば、ネットワーク内に一定で大量のマルチキャストトラフィックがある場合に、トラフィックフロー内の障害は、障害の標識としての役割を果たす。対照的に、ＤＦＮＰは、独立してパケットフローの状態である。ＤＦＮＰは、非局所障害の標識であり、セカンダリバックアップパスのブロック解除をトリガすることができる。

図４Ａは、ＤＦＮＰ発信ノードから下流への各ノードが従うルールの実施形態を説明する。一実施形態では、ルールは、図５Ａ及び図５Ｂ内で以下に説明されるネットワークノードなどの各ネットワークノードのデータプレーン回路に記憶され得る。

（Ｒ１）（ブロック４１１）ノードが、プライマリＵＭＨからＤＦＮＰを受信し、障害のないセカンダリパスを有する（例えば、セカンダリＵＭＨからＤＦＮＰを受信しない、又は、セカンダリＵＭＨへの接続で障害を検出しない）場合には、上記ノードは、修復ノード（repair node）である。ＤＦＮＰの受信に応じて、この修復ノードは、セカンダリＵＭＨへのセカンダリパスのブロック解除を行う。上記修復ノードは、上記ＤＦＮＰをさらに下流に転送しない。

（Ｒ２）（ブロック４１２）ノードが、プライマリＵＭＨからＤＦＮＰを受信するが、セカンダリＵＭＨを有しない場合には、当該ノードは、修復ノードではない。ＤＦＮＰの受信に応じて、このノードは、全てのダウンストリームノードへＤＦＮＰを転送する。ＭｏＦＲＲに基づく実施形態について、上記ダウンストリームノードは、さらに下流においてプライマリパス及びセカンダリパスのブランチ上にある全てのノードを含む。ＭＲＴに基づく実施形態について、上記ダウンストリームノードは、障害が検出されるツリー上のダウンストリームブランチ上の全てのノードを含む。

（Ｒ３）（ブロック４１３）ノードが、２つのＤＦＮＰ（プライマリＵＭＨからの１つ及びセカンダリＵＭＨからの１つ）を受信する場合に、このノードも、修復ノードではない。個別のＵＭＨから２つのＤＦＮＰを受信することは、プライマリパス及びセカンダリパスの両方に障害があることの標識である。２つのＤＦＮＰの受信に応じて、上記ノードは、（Ｒ２のように）全てのダウンストリームノードへＤＦＮＰの一方を転送する。他方のＤＦＮＰは、破棄され得る（転送されないのと等しい）。シナリオでは、ノードは、プライマリパスからのＤＦＮＰの受信に応じて、所定量の時間の間待機して、セカンダリパスから別のＤＦＮＰを受信するかを見ることができる。別のＤＦＮＰがセカンダリパスから受信される場合には、ブロック解除は障害を修復できないので、上記ノードは、セカンダリパスのブロック解除を行わなくてもよい。別のシナリオでは、ノードは、プライマリパスからのＤＦＮＰの受信に応じて、セカンダリパスのブロック解除を即座に行い、受信されたＤＦＮＰを破棄することができる。上記ノードが、その後、マルチキャストデータトラフィックを受信しないが、代わりにセカンダリＵＭＨから別のＤＦＮＰを受信する場合には、上記ノードは、全てのダウンストリームノードへこの別のＤＦＮＰを転送する。

（Ｒ４）（ブロック４１４）ノードのセカンダリＵＭＨからのみ受信されるＤＦＮＰは、破棄される。

図３ＣのＭｏＦＲＲの例を使用して、上述したルールの適用を説明することができる。ノードＡに障害が発生する場合に、ノードＢ及びＪは、両方とも、（例えば、個別の入力インターフェースで）局所的に障害を検出し、ＤＦＮＰをそれぞれ発信する。両方のＤＦＮＰは、ノードＣに向けて下流に送信される。ノードＣは、プライマリＵＭＨ（ノードＢ）及びセカンダリＵＭＨ（ノードＪ）から２つのＤＦＮＰを受信するので、修復ノードではない。ノードＣは、修復ノードではないので、（ルールＲ３に従って）Ｋ及びＤに向けてＤＦＮＰの一方を転送する。ノードＫは、マルチキャストツリーのためのセカンダリＵＭＨを有さず、そのため、（ルールＲ２に従って）ノードＥに向けて下流にＤＦＮＰを送信する。ノードＤは、動作中のセカンダリＵＭＨ（ノードＩ）を有し、そのため、ノードＤは、（ルールＲ１を適用して）修復ノードである。ノードＥは、ルールＲ４を適用する。結果として、ノードＤ及びＥにいる加入者、又はノードＤ及びＥから下流にいる加入者は、マルチキャストトラフィックを受信し続ける。

ＭＲＴに基づく実施形態について、修復ノードは、セカンダリツリー内の障害のないセカンダリパスを有するのみではなく、ダウンストリームノードのためにプライマリツリーから上記セカンダリツリーへマルチキャストパケットのヘッダを変換する能力も有するノードである。ＭＲＴに基づく同じ実施形態において、マルチキャストパケットは、パケットが横切るツリーを識別するためのツリーＩＤをヘッダ内で搬送する。１つのシナリオ（Ｉ）では、全てのノードが、他のノードのために１つのツリーから別のツリーへパケットのヘッダを変換することができる。よって、障害検出ノードは、セカンダリツリーへマルチキャスト受信を切り替え、プライマリツリー上のダウンストリームノードのためにパケットを変換し得る。このシナリオ（Ｉ）では、ＤＦＮＰが必要である。別のシナリオ（ＩＩ）では、いくつかのネットワークノード（例えば、内部ノード）が、別のノードのためではなく加入者のみのために１つのツリーから別のツリーへパケットヘッダを変換できてもよい。よって、内部ノードである障害検出ノードは、セカンダリツリーへマルチキャスト受信を切り替え、プライマリツリー上のダウンストリームノードもマルチ受信を上記セカンダリツリーへ切り替えることができるように、これらのダウンストリームノードへＤＦＮＰを送信してもよい。本明細書では、ＭＲＴについて、「プライマリ／セカンダリツリー」及び「プライマリ／セカンダリパス」という用語は、置き換え可能なように使用される。

例えば、図２Ａのブルーツリー２１０がプライマリツリーであり、図２Ｂのレッドツリー２２０がセカンダリツリーであり、ノードＩをノードＤへ接続するリンク上で障害が発生すると仮定する。ネットワークがライブ−ライブモードで動作する場合に、ツリー２１０及びツリー２２０の両方が、マルチキャストトラフィックを搬送するが、各ノードは、（レッドツリー２２０上の）セカンダリパスへの入力インターフェースをブロックする。ノードは、単に、セカンダリＵＭＨへの入力インターフェースのブロック解除を行って、マルチキャストトラフィックを受信することができるので、障害が検出される場合にＵＡＰは生成されない。内部ノードが他のノードのために１つのツリーから別のツリーへ変換することができるシナリオ（Ｉ）では、プライマリＵＭＨの障害の検出に応じて、ノードＤは、単に、ノードＣからのセカンダリパスのブロック解除を行い、セカンダリＵＭＨ（ノードＣ）からのトラフィックをプライマリツリー上へ下流に（例えば、ノードＥ、Ｋ、Ｃ、Ｊ、Ｂ及びＡのために）複製し変換する。この場合に、ノードＤは、ＤＦＮＰを生成しない。

内部ノードが他のノードのために１つのツリーから別のツリーへ変換することができないシナリオ（ＩＩ）では、ノードＤは、障害の検出に応じて、ノードＥ、Ｋ、Ｃ、Ｊ、Ｂ及びＡへプライマリツリー上で下流にＤＦＮＰを送信する。ＤＦＮＰは、これらのノードの各々により使用されて、セカンダリＵＭＨへの入力インターフェースのブロック解除が行われる。例えば、ノードＫは、ＤＦＮＰの受信に応じて、セカンダリＵＭＨ（即ち、ノードＣからの入力インターフェース）のブロック解除を即時に行い、加入者のためにマルチキャストデータパケットを変換し始めることができる。

図４Ｂは、受信されるＤＦＮＰを処理するための方法４００の実施形態を説明するフロー図である。ネットワークノードは、ＤＦＮＰを受信する場合に（ブロック４１０）、上記ＤＦＮＰがプライマリＵＭＨから受信されるかを判定する（ブロック４２０）。上記ＤＦＮＰがセカンダリＵＭＨのみから受信される場合に、上記ネットワークノードは、上記ＤＦＮＰを破棄する（ブロック４３０）。ＤＦＮＰがプライマリＵＭＨから受信される場合に、上記ネットワークノードは、上記ネットワークノードがセカンダリＵＭＨからもＤＦＮＰを受信するかを判定する（ブロック４４０）。上記ネットワークノードは、２つのＵＭＨから２つのＤＦＮＰを受信する場合に、１つのＤＦＮＰのみをさらに下流に転送する（ブロック４５０）。上記ネットワークノードは、プライマリＵＭＨのみからＤＦＮＰを受信する場合に、上記ネットワークノードがＭＣＩへの障害のないセカンダリパスを有するかを判定する（ブロック４６０）。上記ネットワークノードがそのような障害のないセカンダリパスを有しない場合には、上記ネットワークノードは、ＤＦＮＰをさらに下流に転送する（ブロック４７０）。ネットワークノードは、セカンダリＵＭＨへの接続の局所検出に基づいて、又は、ブロック４４０で判定されるように非局所障害を示すＤＦＮＰをセカンダリＵＭＨから上記ノードが受信するかに基づいて、上記ネットワークノードがＭＣＩへの障害のないセカンダリパスを有するかを判定してもよい。

上記ネットワークノードが障害のないセカンダリパスを有する場合に（ブロック４６０）、上記ネットワークノードは、セカンダリＵＭＨへマルチキャスト受信を切り替え（ブロック４８０）、上記ＤＦＮＰをさらに転送しない（ブロック４９０）上記ネットワークノードは、セカンダリＵＭＨの入力インターフェースのブロック解除を行うことにより、マルチキャスト受信を切り替え得る。ＭＲＴに基づくネットワークの実施形態について、ブロック４８０の後に、上記ネットワークノードが上記プライマリツリー上のダウンストリームノードのために１つのツリーから別のツリーへマルチキャストパケットを変換できるかも判定される（Ｓ４８５）。上記ネットワークノードが他のノードのためにマルチキャストパケットを変換できない場合には、上記ネットワークノードは、さらに下流にＤＦＮＰを転送する（ブロック４７０）。上記ネットワークノードが他のノードのためにマルチキャストパケットを変換できる場合には、上記ネットワークノードは、パケットを変換し始め、さらにＤＦＮＰを転送しない（Ｓ４９０）。

ＤＦＮＰを転送するかの決定を以下のように要約することができる。ノードがセカンダリパスからのみＤＦＮＰを受信する場合、又は、当該ノードがプライマリパスからＤＦＮＰを受信し、セカンダリパスが動作している可能性がある（例えば、局所検出により、又はセカンダリＵＭＨから受信されるＤＦＮＰにより、セカンダリＵＭＨの「ダウンステータス」が確認されていない）場合に、上記ノードは、ＤＦＮＰをさらに下流に転送しない。ノードがプライマリパスからＤＦＮＰを受信し、当該ノードについてセカンダリパスが存在しない場合、又は、上記ノードがプライマリパス及びセカンダリパスの一方からＤＦＮＰを受信し、別のＤＦＮＰがプライマリパス及びセカンダリパスの他方から前に受信された場合に、上記ノードは、ＤＦＮＰをさらに下流に転送する。

ネットワークがライブ−スタンバイモードで動作するいくつかの実施形態では、セカンダリパスへのマルチキャストデータフローをブロックするアップストリームノードが、対応する出力インターフェースのブロック解除を行って、セカンダリパスをアクティベートするように、ネットワークノードは、セカンダリパスに沿ってアップストリームアクティベーションパケット（ＵＡＰ）を送信し得る（ブロック４８０）。ＵＡＰについてのさらなる詳細は、ライブ−スタンバイモードの動作に関連して後に説明される。

ＤＦＮＰは、障害から下流のノードに、障害により影響を受けるマルチキャストツリーを一義的に識別することを可能にする。一実施形態では、ＤＦＮＰは、（例えば、ＩＰソース／宛先アドレスフィールド内に）マルチキャストソースアドレス、及び、マルチキャストグループ又はマルチキャストツリーを識別するマルチキャストグループアドレスを含む。

ＤＦＮＰは、受信ノードにより認識するのが容易である。一実施形態では、マルチキャストストリーム内の通常のデータパケットからＤＦＮＰを区別するために、（例えば、ＩＰヘッダ内の）特別なＩＰプロトコル値（special IP protocol value）、又は、特別に割り当てられたユーザデータグラムプロトコル（ＵＤＰ）ポート番号を使用することができる。特別なＵＤＰポート番号が使用される場合には、ＩＰプロトコルフィールドは、ＰＩＭに対応する「１０３」などの容易に認識可能な値に設定され得る。トラブルシューティング目的のいくつかの実施形態では、ペイロードが、ＤＦＮＰを発信するノードのＩＤを含み得る。当該ペイロードは、接続性が失われたノードのＩＤ、及び／又は接続性が失われたリンクＩＤも含み得る。いくつかの実施形態では、ＤＦＮＰは、その発信の時間を示すタイムスタンプも含み得る。

図５Ａは、本発明の実施形態を実装するために使用され得るネットワークノード５００の例を説明する。ネットワークノード５００は、図２Ａ−２Ｂ及び図３Ａ−３Ｃにおいて上述したネットワークノードＡ−Ｋのいずれかであってもよい。図５において示されるように、ネットワークノード５００は、データプレーンを含み、当該データプレーンは、スイッチ構造（switching fabric）５３０、多数のラインカード５５０及び複数のＩ／Ｏポート５８０をさらに含む。各ラインカード５５０は、Ｉ／Ｏポート５８０を通じて受信されるデータに関する機能を実行するラインカードプロセッサ５５１を含む。図５Ｂにおいて示されるように、ラインカードプロセッサ５５１の実施形態は、ＤＦＮＰを生成し処理するように構成されるダウンストリーム通知モジュール５１１を含む。上記データプレーンは、ネットワークノード５００がメンバである各マルチキャストグループのための１つ以上の転送テーブル５５３も含む。転送テーブルは、ネットワークノードのアップストリームネイバ（例えば、ＵＭＨ）、ダウンストリームネイバ、及びこれらのネイバのインターフェースを追跡するための転送情報を記憶する。スイッチ構造２３０は、ラインカード５５０間でデータを切り替える。

ネットワークノード５００は、制御プレーンも含む。上記制御プレーンは、ネットワークトラフィックのルーティング及び管理を扱うように構成される制御ロジックを含む１つ以上のノードプロセッサ５１０をさらに含む。上記制御プレーンは、１つ以上のルーティングテーブル５２１を記憶するメモリ５２０も含んで、ネットワークのルーティング情報を維持する。ネットワークノード５００は上述したもの以外にさらなる要素及び情報を含み得るということが理解される。

図６は、障害の場合にマルチキャスト高速再ルーティングを提供するための方法６００の実施形態を説明する。一実施形態では、方法６００は、図５Ａのネットワークノード５００などの、マルチキャスト通信ネットワーク内のネットワークノードにより実行されることが可能である。

方法６００は、ネットワークノードがアップストリームネイバへの接続の損失（loss of connection）を検出した場合に開始する（ブロック６１０）。一実施形態では、アップストリームネイバは、マルチキャストグループについてのネットワークノードのプライマリＵＭＨである。障害検出ノードが、マルチキャストデータトラフィックがマルチキャストグループの受信ノードにより受信されることを可能にするために、当該マルチキャストデータトラフィックを再ルーティングすることができない、と上記障害検出ノードが判定する場合に、上記障害検出ノードは、通知パケットを生成する（ブロック６２０）。ＭＲＴに基づく実施形態（上述したシナリオ（Ｉ））では、再ルーティングは、上記障害検出ノードによりレッドツリーへマルチキャスト受信を切り替えること、及び、ブルーツリー内の全てのダウンストリームノードのマルチキャストパケットを変換することを伴ってもよい。ＭＲＴに基づく実施形態（上述したシナリオ（ＩＩ））では、再ルーティングは、上記障害検出ノードにより、及び、ブルーツリー内のいくつかの又は全てのダウンストリームノードにより、レッドツリーへマルチキャスト受信を切り替えることを、伴ってもよい。ＭｏＦＲＲに基づく実施形態では、再ルーティングは、ＭＣＩへの動作中のセカンダリパスを有する、障害から下流のマージノードにより、セカンダリＵＭＨへマルチキャスト受信を切り替えることを、伴ってもよい。よって、ブロック６２０での判定に応じて、上記ノードは、マルチキャストグループの受信ノード向けて下流に通知パケット（例えば、ＤＦＮＰ）を生成し送信する（ブロック６３０）。上記通知パケットは、１つ以上のダウンストリームノードに、マルチキャスト通信ネットワーク内の１つ以上の冗長セカンダリパスへマルチキャスト受信を切り替えさせて、それによって、上記マルチキャストデータトラフィックを再ルーティングさせる。

一実施形態では、マルチキャスト受信は、受信側のノードによって、例えば、セカンダリＵＭＨへの入力インターフェースのブロック解除を行うことにより、プライマリパスからセカンダリパスへ切り替えられ得る。別の実施形態では、マルチキャスト受信は、送信側のノードによって、例えば、セカンダリパス上のダウンストリームネイバへの出力インターフェースのブロック解除を行うことにより、プライマリパスからセカンダリパスへ切り替えられてもよい。ライブ−ライブモードで動作する（送信側の）ブランチノードは、プライマリダウンストリームネイバ及びセカンダリダウンストリームネイバへの、ブロック解除された出力インターフェースを有し、複製されたマルチキャストデータトラフィックをセカンダリパス上で流れさせる。（受信側の）対応するマージノードは、障害がない限り複製されたトラフィックの受信を妨げるためにセカンダリＵＭＨへのブロックされた入力インターフェースを有する。対照的に、本発明の実施形態によれば、ライブ−スタンバイモードで動作するブランチノードは、セカンダリパスへのブロックされた出力インターフェースを有し、対応するマージノードは、セカンダリパスへの、ブロック解除された入力インターフェースを有する。結果として、マルチキャスト複製が回避され、マルチキャスト帯域消費が最適化される。

図７Ａ及び図７Ｂは、本発明の実施形態に従って多数のネットワークノードがライブ−スタンバイモードでそれらのインターフェースをどのようにブロックし得るかを説明する。図７Ａは、図２Ａ（ブルーツリー）及び図２Ｂ（レッドツリー）のノードＢ、Ｃ及びＤのデータプレーンに記憶される図５Ａの転送テーブル５５３の実施形態を説明する。図７Ｂは、図３Ｃの同じノードの転送テーブル５５３の実施形態を説明する。各マルチキャストグループについて、各ネイバノード内の転送テーブル５５３は、ノードのアップストリームネイバ（即ち、ＵＭＨ）を識別するための、入力インターフェース（入力ＩＦ）のリスト７１０と、マルチキャストグループ内の上記ノードのダウンストリームネイバを識別するための出力インターフェース（出力ＩＦ）のリスト７２０とを記憶する。インターフェースのうちのいくつかは、ブロックされ得る（丸括弧のペアにより示される）。いくつかの実施形態では、ブロックされたインターフェースに関連付けられたフラグが、ブロック状態を示すようにセットされ得る。図７Ａに示されるＭＲＴに基づく実施形態では、ブルーツリーがプライマリツリーであり、レッドツリーがセカンダリツリーであると仮定される。障害のないシナリオでは、全てのブルーツリーインターフェースは、ブロック解除されている。２つのオプション（レッドツリー（Ａ）及びレッドツリー（Ｂ））が、ライブ−スタンバイモードで動作するネットワークのために示される。障害のないシナリオにおけるレッドツリー（Ａ）のオプションについて、ＭＣＩのみがレッドツリーへの出力インターフェースをブロックするので、レッドツリー内の全てのインターフェースがブロック解除されている。障害のないシナリオにおけるレッドツリー（Ｂ）のオプションについて、全てのノードは、レッドツリー内の出力インターフェースをブロックする。（示されていない）他の実施形態において、ノードは、レッドツリー内の入力インターフェース及び出力インターフェースの両方をブロックしてもよい。図７Ｂに示されるように、ＭｏＦＲＲに基づき、ライブ−スタンバイモードで動作するネットワークの実施形態において、複製されたマルチキャストデータパケットがセカンダリパス上で送信されるのを防ぐために、セカンダリＤＭＨへのブランチノードの出力インターフェースをブロックすることができる。例えば、ノードＫへのノードＣの出力インターフェースはブロックされる。

ライブ−ライブモードで動作するネットワークのアップストリーム位置で障害が検出される場合に、ダウンストリームノードは、セカンダリパスへの入力インターフェースのブロック解除を行うことにより、マルチキャストデータを受信し始めることができる。しかしながら、ライブ−スタンバイモードで動作するネットワーク内で障害が検出される場合には、ダウンストリームノードは、当該ダウンストリームノードのアップストリームノードがセカンダリパスへの出力インターフェースのブロック解除を行わなければ、当該セカンダリパスからマルチキャストデータを受信することができない。上述したＤＦＮＰは、ＭＣＩへの動作中のセカンダリパスを有するダウンストリームノードに障害情報を渡す。ダウンストリームノードがマルチキャストを受信し始めるために、セカンダリパスの送信側に位置するアップストリームノードは、上記マルチキャストデータがセカンダリパス上で流れることを可能にするために、当該アップストリームノードの出力インターフェースのブロック解除を行う必要がある。

本発明の実施形態は、アップストリームアクティベーションパケット（ＵＡＰ）を提供する。当該ＵＡＰは、障害の検出に応じてセカンダリパス上で送信されて、セカンダリパス上のトラフィックを明示的にアクティベートする。障害がない場合にはマルチキャストデータトラフィックはこれらのセカンダリパス上で流れていないので、ＵＡＰを送信することは、これらの出力インターフェースをアクティベートする。よって、ネットワークは、セカンダリパスを待機（standby）モードに（即ち、負荷なしに）維持することができ、それによって、大幅に（例えば、５０％程度）帯域消費を減らすことができる。

ライブ−スタンバイモードで動作する本発明の実施形態によれば、プライマリパス上の上流のどこかで発生したネットワーク障害（例えば、ノード障害又はリンク障害）の標識に応じて、ＵＡＰは、生成され、ＭＣＩに向けてセカンダリパスを介して上流に送信される。上記ＵＡＰは、ＭＣＩへの障害のあるプライマリパスと、ＭＣＩへの動作中のセカンダリパスとを有するノードにより、生成されることが可能である。より具体的には、ＵＡＰ出力ノードは、いずれかの障害検出技術により、アップストリーム障害を検出し又は通知されるノードであり、ＭＣＩに向けた動作中のセカンダリパスを有するノードでもある。ＵＡＰ発信ノードは、プライマリパスからのＤＦＮＰを受信することにより、アップストリーム障害を通知されてもよい。あるいは、ＵＡＰ発信ノードは、プライマリＵＭＨへの入力インターフェースでの接続の損失を検出してもよい。いくつかの実施形態では、ＵＡＰ発信ノードは、ＤＦＮＰとは無関係ないずれかの手段を使用して、アップストリーム障害を検出してもよい。例えば、ハートビート信号が、安定したペースで、ＭＣＩからマルチキャスト受信ノードへ送信されてもよい。これらの信号は、マルチキャストデータストリームと同じマルチキャストツリーに沿って転送されてもよい。そのようなハートビートがないことは、障害の存在を示す。いくつかの他の実施形態では、ＵＡＰ発信ノードは、プライマリパス上でのマルチキャストデータトラフィックを監視することにより、アップストリーム障害を検出してもよい。上述した全てのシナリオでは、ＵＡＰ発信ノードは、ＵＡＰを送信可能な動作中のセカンダリＵＭＨを有する必要がある。即ち、ＵＡＰ発信ノードのセカンダリパス上でアップストリーム障害の標識がない可能性がある。例えば、ＤＦＮＰがセカンダリＵＭＨから受信されず、又は、セカンダリＵＭＨへの接続の損失がない。

ＵＡＰは、当該ＵＡＰが受信されるいずれかのブロックされた出力インターフェースをアクティベートする。どの出力インターフェースがブロックされ、又はブロック解除されているかは、どのようにセカンダリパスが構築されたかに依存している。ライブ−スタンバイモードでは、セカンダリパスは、専用の待機（バックアップ）状態を用いて構築される。専用の待機状態を伴うセカンダリパスを構築するために、一実施形態では、接続ノードにより送信されるＪＯＩＮ要求（例えば、ＰＩＭ ＪＯＩＮメッセージ）を、待機状態を示すフラグを用いてマークすることができる（ＭＲＴに基づく実施形態について、当該フラグは、ツリーのうちのどの１つが参加されているかを示すツリーＩＤであってもよい）。この要求が、マルチキャストツリー内のアップストリームノードに到達する場合に、当該アップストリームノードは、データプレーン内のセカンダリパスへの出力インターフェースを導入する。マルチキャストツリー内の上記アップストリームノードの位置によっては、出力インターフェースは、当該出力インターフェースがブロックされていることを示すフラグを用いて導入されてもよい。アクティベーションパケット（例えば、ＵＡＰ）が、ブロックされた出力インターフェースをアクティベートしない限り、パケットは、当該ブロックされた出力インターフェースへは転送されない。

ＭｏＦＲＲに基づく発明の実施形態について、ブランチノードのみが、セカンダリパスについての出力インターフェースをブロックされた状態に維持する必要がある。セカンダリ参加（join）要求は、マージノードから、プライマリパス上にはないいくつかのホップを通じて上方に伝達される。しかしながら、ブランチノードの出力インターフェースがブロックされているので、セカンダリのみノードは、当該ブランチノードからパケットを受信しない。したがって、これらのセカンダリのみノードは、それらのインターフェースをブロックする必要はない。ブランチノードは、ＵＡＰの受信に応じて、セカンダリパスへの出力インターフェースのブロック解除を行い、上記ＵＡＰを破棄することができる。即ち、ブランチノードは、さらに上流に上記ＵＡＰを転送する必要はない。ＭＲＴに基づく実施形態について、このブランチノードはＭＣＩである。ＭｏＦＲＲに基づく実施形態について、このブランチノードは、必ずしもＭＣＩではない。例えば、（図３Ｃにおける）ノードＣが、ノードＢへの入力インターフェースで接続の損失を検出するが、ノードＪへの入力インターフェースで障害を検出しない場合に、ノードＣは、ＭＣＩへのセカンダリパスに沿ってＵＡＰを送信することができる。ノードＡ（ノードＣから上流において第１のブランチノード）は、このＵＡＰを遮り、ノードＪへの出力インターフェースのブロック解除を行い、上記ＵＡＰを破棄する。

ＭＲＴに基づく実施形態について、ＭＲＴマルチキャストツリーが構築された際にどの出力インターフェースがブロックされたかによって、ＵＡＰを扱うための２つの代替オプション（Ａ）及び（Ｂ）がある。（図７Ａのレッドツリーオプション（Ａ）に示されるように）ＭＣＩのみがセカンダリ出力インターフェースをブロックされた状態に維持する第１のオプション（Ａ）では、ＵＡＰは、ＭＣＩのみにより処理される。ＭＣＩは、ＵＡＰを受けて、（Ａ１）セカンダリツリー上の全ての出力インターフェースのブロック解除を行うこと、又は、（Ａ２）ＵＡＰが受信された出力インターフェースのみのブロック解除を行うことを、実行する。第１のケース（Ａ１）では、セカンダリツリー全体がただちにアクティベートされる。第２のケース（Ａ２）では、マルチキャストを再ルーティングするために必要なブランチのみが、アクティベートされる。（図７Aのレッドツリーオプション（Ｂ）に示されるように）マルチキャストグループ内の全てのノードがセカンダリツリーについての出力インターフェースをブロックする第２のオプション（Ｂ）では、各ノードは、ＭＣＩに向かってＵＡＰが転送される間に当該ＵＡＰが受信された出力インターフェースのブロック解除を行う。オプション（Ｂ）は、アクティベートされる唯一のパスは、マルチキャストを再ルーティングするのに必要なセカンダリツリー上のパスである、という効果を有する。対照的に、オプション（Ａ１）は、セカンダリツリー全体をアクティベートし、オプション（Ａ２）は、全てのサブツリーをアクティベートする。例えば、（図２Ｂにおける）ノードＣが、ノードＪへの入力インターフェースで接続の損失を検出する場合には、ノードＣは、ＭＣＩへのセカンダリパス（即ち、レッドツリー２２０）に沿ってＵＡＰを送信することができる。ＵＡＰは、ＭＣＩに（オプション（Ａ））、又は、ＭＣＩ、ノードＡ及びノードＢの全てに（オプション（Ｂ））、出力インターフェースのブロック解除を行わせる。

さらに、内部ノードが他のノードのために１つのツリーから別のツリーへマルチキャストパケットヘッダを変換できるかによって、内部障害検出ノードが、ＤＦＮＰ若しくはＵＡＰを生成してもよく、又は生成しなくてもよい。以下では、ブルーツリー２１０がプライマリツリーであり、レッドツリー２２０がセカンダリツリーであり、ノードＩをノードＤに接続するリンク上で障害が発生すると仮定して、ライブ−スタンバイモードで動作するＭＲＴベースのネットワークについての２つのシナリオが説明される。

内部ノードが他のノードのために１つのツリーから別のツリーへ変換できるシナリオ（１）では、ノードＤが障害を検出する場合に、ノードＤは、ノードＤが切り替えることができる動作中のセカンダリパスを有する。しかしながら、当該セカンダリパスは、現在アクティブではない。よって、Ｄは、ＤＦＮＰを送信する必要はないが、ＭＣＩに到達するためにノードＣ、Ｂ及びＡを介してセカンダリパス上でＵＡＰを送信する必要がある。このＵＡＰは、（ＭＣＩのみがレッドツリーへの出力インターフェースをブロックする）オプション（Ａ）及び（ＭＣＩ並びにノードＣ、Ｂ及びＡがレッドツリーへの個別の出力インターフェースをブロックする）オプション（Ｂ）の両方について、セカンダリパスをアクティベートする。

内部ノードが他のノードのために１つのツリーから別のツリーへ変換できないシナリオ（２）では、ノードＤは、障害の検出に応じて、ノードＣを通じてＭＣＩへＵＡＰを送信することにより、セカンダリパスをアクティベートする。ノードＤは、ブルーツリーに沿ってノードＥ、Ｋ、Ｃ、Ｊ、Ｂ及びAへ下流にＤＦＮＰも送信する。各ノードは、ＤＦＮＰの受信に応じて、セカンダリパスに沿って上流にＵＡＰを送信することにより、セカンダリパスをアクティベートする。例えば、ノードＫは、ノードＤからのＤＦＮＰを受信した後に、セカンダリパスがトラフィックを受信するようにノードＣを通じてＭＣＩへＵＡＰを送信する。この時までに、ノードＣは、ノードＤからのＵＡＰにより、レッドツリー上のインターフェースを既にアクティベートし得る。そのため、ノードＣは、ノードＫからＭＣＩに向かってＵＡＰを転送する必要はない。

一実施形態では、ＵＡＰのソースＩＰアドレスは、ＵＡＰを発信するノードを識別し、宛先（destination）ＩＰアドレスは、ＭＣＩを識別する。ＵＡＰは、ＭＣＩに向けてアップストリーム（上流）方向にセカンダリパス上で送信される。ＵＡＰは、（ＩＰヘッダ内に）特別なＩＰプロトコル値、又は特別に割り当てられたＵＤＰポート番号を含むので、当該ＵＡＰは、受信ノードにより容易に認識可能である。特別なＵＤＰポート番号が使用される場合には、ＩＰプロトコルフィールドは、ＰＩＭに対応する値（１０３）に設定されてもよい。ＵＡＰのペイロードは、マルチキャストソースアドレスと、識別のためのマルチキャストグループのグループアドレスとを含む。いくつかの実施形態では、トラブルシューティング目的で、ＵＡＰのペイロードは、接続性が失われたノードのＩＤ、及び／又は接続性が失われたリンクＩＤを含んでもよい。いくつかの実施形態では、タイムスタンプを上記ＵＡＰに追加することもできる。

図８は、障害の場合に待機パスをアクティベートするための方法８００の実施形態を説明する。一実施形態では、方法８００は、図５Ａのネットワーク５００などの、マルチキャスト通信ネットワーク内のネットワークノードにより実行されることが可能である。

方法８００は、ネットワークノードがマルチキャストツリーのプライマリパスへの接続の損失の標識を受信する場合に開始する（ブロック８１０）。マルチキャストツリーは、帯域利用を減らすために、ライブ−スタンバイモードで動作している。ライブ−スタンバイモードでは、ネットワーク内で障害がない場合には、マルチキャストデータトラフィックはセカンダリパス上を流れない。ネットワークノードは、当該ネットワークノードがソースノードへの障害のないセカンダリパスを有すると判定する場合に（ブロック８２０）、上記障害のないセカンダリパスを介して共通ソースノードに向けて上流にアクティベーションパケット（例えば、ＵＡＰ）を送信する。上記ＵＡＰは、障害のないセカンダリパス上での上記マルチキャストデータトラフィック送信のフローをアクティベートする。上記ＵＡＰは、１つ以上のアップリンクノードに個別の１つ以上の出力インターフェースのブロック解除を行わせて、それによって、上記障害のないセカンダリパス上のマルチキャストデータトラフィックの送信をアクティベートする（ブロック８３０）。

図６及び図８の図の動作は、図５Ａの例示的な実施形態を参照して説明された。しかしながら、図６及び図８の図の動作は、図５Ａを参照して説明した実施形態以外の本発明の実施形態により実行されることが可能であるということ、並びに、図５Ａを参照して説明された実施形態は、図６及び図８の図を参照して説明した動作とは異なる動作を実行することができるということが、理解されるべきである。図６及び図８の図は、本発明のある実施形態により実行される動作の特定の順序を示しているが、そのような順序は例示であるということが、理解されるべきである（例えば、代替の実施形態は、異なる順序で動作を実行してもよく、ある動作を組み合せてもよく、ある動作が重複してもよい、など）。

本発明の異なる実施形態は、ソフトウェア、ファームウェア及び／又はハードウェアの異なる組合せを使用して実装され得る。よって、図において示される技術は、１つ以上の電子装置（例えば、終端局、ネットワーク要素など）上で記憶され実行されるコード及びデータを使用して実装されることが可能である。そのような電子装置は、非一時的なコンピュータに読込み可能な記憶媒体（例えば、磁気ディスク、光ディスク、ランダムアクセスメモリ、リードオンリーメモリ、フラッシュメモリ装置、位相変化メモリ）、及び一時的なコンピュータに読込み可能な送信媒体（例えば、搬送波、赤外線信号、デジタル信号などの、電気、光、音響、又は他の形式の伝搬信号）などの、コンピュータに読込み可能な媒体を使用して、コード及びデータを記憶し、（内部で、及び／又はネットワークを通じて他の電子装置と）伝達する。さらに、そのような電子装置は、典型的には、１つ以上の記憶装置（非一時的な機械に読込み可能な記憶媒体）、ユーザ入力／出力装置（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）並びにネットワーク接続などの１つ以上の他のコンポーネントに結合された１つ以上のプロセッサのセットを含む。プロセッサの上記セットと他のコンポーネントとの結合は、典型的には、１つ以上のバス及びブリッジ（バスコントローラとも呼ばれる）を通じる。よって、所与の電子装置の記憶装置は、典型的には、電子装置の１つ以上のプロセッサのセット上で実行するためのコード及び／又はデータを記憶する。

本明細書で使用されるように、ネットワーク要素（例えば、ルータ、スイッチ、ブリッジ、コントローラ）は、ネットワーク上の他の機器（例えば、他のネットワーク要素、終端局）と通信で（communicatively）相互接続する、ハードウェア及びソフトウェアを含むネットワーク機器の一部である。いくつかのネットワーク要素は、複数のネットワーキング機能（例えば、ルーティング、ブリッジ、スイッチング、レイヤ２アグリゲーション、セッションボーダー制御、サービス品質、及び／若しくは加入者管理）のサポートを提供し、並びに／又は、複数のアプリケーションサービス（例えば、データ、音声、及び映像）のサポートを提供する「マルチサービスネットワーク要素」である。加入者終端局（例えば、サーバ、ワークステーション、ラップトップ、ネットブック、パームトップ、携帯電話、スマートフォン、マルチメディア電話、ＶｏＩＰ（Voice over Internet Protocol））電話、ユーザ機器、端末、ポータブルメディアプレイヤ、ＧＰＳユニット、ゲームシステム、セットトップボックス）は、インターネットを通じて提供されるコンテンツ／サービス、及び／又は、インターネット上に重ねられた（例えば、インターネットを通じてトンネルされた）ＶＰＮ（Virtual Private Network）上で提供されるコンテンツ／サービスにアクセスする。コンテンツ及び／又はサービスは、典型的には、サービスプロバイダ又はコンテンツプロバイダに属する１つ以上の終端局（例えば、サーバ終端局）、又はピアツーピアサービスに参加している終端局により提供され、例えば、公開ウェブページ（例えば、フリーコンテンツ、店頭、サーチサービス）、プライベートウェブページ（例えば、電子メールサービスを提供する、ユーザ名／パスワードでアクセスされるウェブページ）及び／又はＶＰＮを通じた企業ネットワークを含み得る。典型的には、加入者終端局は、（例えば、（有線又は無線で）アクセスネットワークに結合されるカスタマ構内設備（customer premise equipment）を通じて）エッジネットワーク要素に結合される。当該エッジネットワーク要素は、（例えば、１つ以上のネットワーク要素を通じて）他のエッジネットワーク要素に結合される。当該他のエッジネットワーク要素は、他の終端局（例えば、サーバ終端局）に結合される。

本発明が様々な実施形態の観点から説明されたが、本発明は、説明された実施形態に限定されず、添付の請求項の趣旨及び範囲内で修正及び変更を伴って実行されることが可能であるということを、当業者は認識するであろう。よって、説明は、限定の代わりに、例示としてみなされる。

Claims (26)

1. マルチキャスト通信ネットワーク内のネットワークノードにより実行される方法であって、
   前記マルチキャスト通信ネットワークは、共通ソースノードから１つ以上のマルチキャスト受信ノードへの接続性を提供するためのマルチキャストツリーを含み、
   前記マルチキャスト通信ネットワークは、前記マルチキャストツリー内の障害の場合にマルチキャストデータトラフィックが１つ以上のセカンダリパスへ再ルーティングされるように前記マルチキャストツリーに冗長性を提供するための一連のセカンダリパスをさらに含み、
   前記方法は、
   前記ネットワークノードにより、前記ネットワークノードのアップストリームネイバへの入力インターフェースで接続の損失を検出するステップと、
   前記ネットワークノードが、前記マルチキャストデータトラフィックが前記マルチキャスト受信ノードにより受信されることを可能にするために、前記マルチキャストデータトラフィックを再ルーティングすることができないと判定するステップと、
   前記１つ以上のマルチキャスト受信ノードに向けて下流に通知パケットを送信するステップと、
   を含み、
   前記通知パケットは、１つ以上のダウンストリームノードに、前記セカンダリパスのうちの１つ以上へマルチキャスト受信を切り替えさせて、前記マルチキャストデータトラフィックを再ルーティングさせる、
   方法。
2. 前記マルチキャスト通信ネットワークは、一連のデュアル接続ノードを含み、
   各デュアル接続ノードは、前記共通ソースノードへの個別のプライマリパス上でプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、前記共通ソースノードへの個別のセカンダリパス上でセカンダリＵＭＨと、結合され、
   前記方法は、ＥＣＭＰ（Equal Cost MultiPath）、ＬＦＡ（Loop Free Alternate）又はＭｏＦＲＲ（Multicast-only Fast Re-Route）に基づいて、前記セカンダリＵＭＨを選択するステップ、をさらに含む、
   請求項１の方法。
3. 前記マルチキャスト通信ネットワークは、一連のデュアル接続ノードを含み、
   各デュアル接続ノードは、前記共通ソースノードへの個別のプライマリパス上でプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、前記共通ソースノードへの個別のセカンダリパス上でセカンダリＵＭＨと、結合され、
   前記方法は、ＭＲＴ（Maximally Redundant Trees）に基づいて、前記プライマリＵＭＨ及び前記セカンダリＵＭＨを選択するステップ、をさらに含む、
   請求項１の方法。
4. 前記通知パケットは、前記共通ソースノードへの障害のないセカンダリパスを有するダウンストリームマージノードに、前記障害のないセカンダリパスへの入力インターフェースのブロック解除を行わせる、請求項１の方法。
5. 前記通知パケットは、前記共通ソースノードへの障害のないセカンダリパスを有するダウンストリームマージノードに、前記一連のセカンダリパスが待機している場合にアクティベーションパケットを生成させ、前記共通ソースノードに向けて前記障害のないセカンダリパスを介して前記アクティベーションパケットを送信させて、前記アクティベーションパケットの受信ノードに前記マルチキャストデータトラフィックのための出力インターフェースのブロック解除を行わせる、請求項１の方法。
6. 前記通知パケットが前記通知パケットの受信ノードのセカンダリパスから受信される場合、又は、前記通知パケットが前記受信ノードのプリマリパスから受信され、前記セカンダリパスが動作している可能性がある場合に、前記通知パケットは、前記通知パケットの前記受信ノードによりさらに下流に転送されない、請求項１の方法。
7. 前記通知パケットが前記通知パケットの受信ノードのプライマリパスから受信され、当該受信ノードについていずれのセカンダリパスも存在しない場合、又は、前記通知パケットが前記受信ノードの前記プライマリパス及び前記セカンダリパスのうちの一方から受信され、別の通知パケットが前記プライマリパス及び前記セカンダリパスの他方から前に受信された場合に、前記通知パケットは、前記通知パケットの前記受信ノードによりさらに下流に転送さる、請求項１の方法。
8. 送信する前記ステップは、前記ネットワークノードから下流に、前記マルチキャストツリー及び前記１つ以上のセカンダリパス内の全てのブランチへ、前記通知パケットを送信するステップさらに含む、請求項１の方法。
9. 送信する前記ステップは、２つのマルチキャストツリーのうちの前記接続の損失が検出された１つのマルチキャストツリーに沿って下流に前記通知パケットを送信するステップをさらに含む、請求項１の方法。
10. 前記通知パケットは、前記マルチキャストデータトラフィックが送信されるマルチキャストグループを識別するためのマルチキャストグループアドレスとマルチキャストソースアドレスとを含む、請求項１の方法。
11. 前記通知パケットは、前記ネットワークノードの１つ以上のラインカードに記憶される情報に基づいて生成され、
    前記情報は、前記接続の損失の前に前記１つ以上のラインカード内に記憶されている、
    請求項１の方法。
12. 前記通知パケットは、ＩＰヘッダ内に特別なインターネットプロトコル（ＩＰ）値を含み、又は、特別に割り当てられたユーザデータグラムプロトコル（ＵＤＰ）ポート番号を含む、請求項１の方法。
13. 前記通知パケットは、接続性が失われたノードの識別子、当該接続性が失われたリンクの識別子、及び、前記接続の損失がいつ検出されたかを示すタイムスタンプのうちの、１つ以上を含む、請求項１の方法。
14. 共通ソースノードから１つ以上のマルチキャスト受信ノードへの接続性を提供するためのマルチキャストツリーを含むマルチキャスト通信ネットワーク内のネットワークノードであって、
    前記マルチキャスト通信ネットワークは、前記マルチキャストツリー内の障害の場合にマルチキャストデータトラフィックが１つ以上のセカンダリパスへ再ルーティングされるように前記マルチキャストツリーに冗長性を提供するための一連のセカンダリパスをさらに含み、
    前記ネットワークノードは、
    前記マルチキャストデータトラフィックについての転送情報を記憶するように構成されるメモリと、
    前記マルチキャストデータトラフィックを受信するように構成される受信機回路と、
    前記メモリ及び前記受信機回路に結合される１つ以上のプロセッサであって、前記ネットワークノードのアップストリームネイバへの入力インターフェースで接続の損失を検出し、前記ネットワークノードが、前記マルチキャストデータトラフィックが前記マルチキャスト受信ノードに到達することを可能にするために、前記マルチキャストデータトラフィックを再ルーティングすることができるか、を判定するように構成される前記１つ以上のプロセッサと、
    前記１つ以上のプロセッサに結合されるダウンストリーム通知モジュールであって、前記ネットワークノードが前記マルチキャストデータトラフィックを再ルーティングできないという判定に応じて通知パケットを発信するように構成される前記ダウンストリーム通知モジュールと、
    前記１つ以上のプロセッサに結合される送信機回路であって、前記１つ以上のマルチキャスト受信ノードに向けて下流に前記通知パケットを送信するように構成される前記送信機回路と、
    を備え、
    前記通知パケットは、１つ以上のダウンストリームノードに、前記セカンダリパスのうちの１つ以上へマルチキャスト受信を切り替えさせて、前記マルチキャストデータトラフィックを再ルーティングさせる、
    ネットワークノード。
15. 前記ネットワークは、一連のデュアル接続ノードを含み、
    各デュアル接続ノードは、前記共通ソースノードへの個別のプライマリパス上でプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、前記共通ソースノードへの個別のセカンダリパス上でセカンダリＵＭＨと、結合され、
    前記セカンダリＵＭＨは、ＥＣＭＰ（Equal Cost MultiPath）、ＬＦＡ（Loop Free Alternate）又はＭｏＦＲＲ（Multicast-only Fast Re-Route）に基づいて選択される、
    請求項１４のネットワークノード。
16. 前記ネットワークは、一連のデュアル接続ノードを含み、
    各デュアル接続ノードは、前記共通ソースノードへの個別のプライマリパス上でプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、前記共通ソースノードへの個別のセカンダリパス上でセカンダリＵＭＨと、結合され、
    前記セカンダリＵＭＨは、ＭＲＴ（Maximally Redundant Trees）に基づいて選択される、
    請求項１４のネットワークノード。
17. 前記通知パケットは、前記共通ソースノードへの障害のないセカンダリパスを有するダウンストリームマージノードに、前記障害のないセカンダリパスへの入力インターフェースのブロック解除を行わせる、請求項１４のネットワークノード。
18. 前記通知パケットは、前記共通ソースノードへの障害のないセカンダリパスを有するダウンストリームマージノードに、前記一連のセカンダリパスが待機している場合にアクティベーションパケットを生成させ、前記共通ソースノードに向けて前記障害のないセカンダリパスを介して前記アクティベーションパケットを送信させて、前記アクティベーションパケットの受信ノードに前記マルチキャストデータトラフィックのための出力インターフェースのブロック解除を行わせる、請求項１４のネットワークノード。
19. 前記通知パケットが前記通知パケットの受信ノードのセカンダリパスから受信される場合、又は、前記通知パケットが前記受信ノードのプリマリパスから受信され、前記セカンダリパスが動作している可能性がある場合に、前記通知パケットは、前記通知パケットの前記受信ノードによりさらに下流に転送されない、請求項１４のネットワークノード。
20. 前記通知パケットが前記通知パケットの受信ノードのプライマリパスから受信され、当該受信ノードについていずれのセカンダリパスも存在しない場合、又は、前記通知パケットが前記受信ノードの前記プライマリパス及び前記セカンダリパスのうちの一方から受信され、別の通知パケットが前記プライマリパス及び前記セカンダリパスの他方から前に受信された場合に、前記通知パケットは、前記通知パケットの前記受信ノードによりさらに下流に転送さる、請求項１４のネットワークノード。
21. 前記送信機回路は、前記ネットワークノードから下流に、前記マルチキャストツリー及び前記１つ以上のセカンダリパス内の全てのブランチへ、前記通知パケットを送信するように、構成される、請求項１４のネットワークノード。
22. 前記送信機回路は、２つのマルチキャストツリーのうちの前記接続の損失が検出された１つのマルチキャストツリーに沿って下流に前記通知パケットを送信するように構成される、請求項１４のネットワークノード。
23. 前記通知パケットは、前記マルチキャストデータトラフィックが送信されるマルチキャストグループを識別するためのマルチキャストグループアドレスとマルチキャストソースアドレスとを含む、請求項１４のネットワークノード。
24. 前記通知パケットは、１つ以上のラインカードに記憶される情報に基づいて生成され、
    前記情報は、前記接続の損失の前に前記１つ以上のラインカード内に記憶されている、
    請求項１４のネットワークノード。
25. 前記通知パケットは、ＩＰヘッダ内に特別なインターネットプロトコル（ＩＰ）値を含み、又は、特別に割り当てられたユーザデータグラムプロトコル（ＵＤＰ）ポート番号を含む、請求項１４のネットワークノード。
26. 前記通知パケットは、接続性が失われたノードの識別子、当該接続性が失われたリンクの識別子、及び、前記接続の損失がいつ検出されたかを示すタイムスタンプのうちの、１つ以上を含む、請求項１４のネットワークノード。

Images