JP2015521448A - 階層的で冗長なマルチキャストルーティングにおける障害カバレッジの増加 - Google Patents

Abstract

強化された高速再ルーティングメカニズムは、マルチキャスト通信ネットワークに増加された障害カバレッジを提供する。ネットワークノードは、障害を検出し、当該ネットワークノードがマルチキャストデータを再ルーティングできないと判定する場合に、ネットワーク内でダウンストリーム高速通知パケット（ＤＦＮＰ）を送信する。上記ＤＦＮＰは、ダウンストリームマージノードに、上記マルチキャストデータの受信をセカンダリパスへ切り替えさせる。その後、上記ネットワークノードは、上記マージノードからアップストリーム高速通知パケット（ＵＦＮＰ）を受信する。上記ネットワークノードは、上記ＵＦＮＰの受信に応じて、ダウンストリームであって、当該ダウンストリーム経由でＵＦＮＰが受信された、当該ダウンストリームから、上記ネットワークノードにより上記マルチキャストデータが受信されるように、転送情報を修正する。上記ＤＦＮＰ及び上記ＵＦＮＰは、上記マルチキャストデータに、上記ネットワークノードと上記マージノードとの間のフロー方向を逆転させる。【選択図】図３Ｂ

Description

関連出願へのクロスリファレンス
この出願は、２０１２年６月１日に出願された「ダウンストリーム通知パケットを用いたＰＩＭ高速再ルーティングへの強化（ENHANCEMENTS TO PIM FAST RE-ROUTE WITH DOWNSTREAM NOTIFICATION PACKETS）」と題する出願（代理人整理番号４９０６Ｐ３６９４７ＵＳ１）、及び「アップストリームアクティベーションパケットを用いたＰＩＭ高速再ルーティングへの強化（ENHANCEMENTS TO PIM FAST RE-ROUTE WITH UPSTREAM ACTIVATION PACKETS）」と題する出願（代理人整理番号４９０６Ｐ３７６３７ＵＳ１）と関連する。

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

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

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

強化された高速再ルーティングメカニズムが、マルチキャスト通信ネットワークに、増加された障害カバレッジを提供する。上記マルチキャスト通信ネットワークは、共通ソースノードから１つ以上のマルチキャスト受信ノードへの接続性を提供するマルチキャストツリーを含む。上記マルチキャスト通信ネットワークは、上記マルチキャストツリーに冗長性を提供する一連のセカンダリパスも含む。

一実施形態では、ネットワークノードは、アップストリームネイバにつながる入力インターフェースで接続の損失を検出する場合に、上記ネットワークノードがマルチキャストデータトラフィックを再ルーティングできるかを判定する。上記ネットワークノードは、上記ネットワークノードが再ルーティングを行うことができないと判定する場合に、ダウンストリーム高速通知パケット（ＤＦＮＰ）をネットワーク内で下流に送信する。上記ＤＦＮＰは、ダウンストリームマージノードに、共通ソースノードにつながるセカンダリパスへ上記マルチキャストデータトラフィックの受信を切り替えさせる。その後、上記ネットワークノードは、上記マージノードからアップストリーム高速通知パケット（ＵＦＮＰ）を受信する。上記ネットワークノードは、上記ＵＦＮＰの受信に応じて、上記ネットワークノードのダウンストリームネイバであって、当該ダウンストリームネイバ経由で上記ＵＦＮＰが受信された、当該ダウンストリームネイバから、上記ネットワークノードにより上記マルチキャストデータトラフィックが受信されるように、転送情報を修正する。

別の実施形態では、ネットワークノードは、マルチキャストトラフィックについての転送情報を保存するように構成されるメモリと、アップストリームネイバへの入力インターフェースで接続の損失を検出するように、且つ、上記マルチキャストデータトラフィックが上記マルチキャスト受信ノードに到達できるように上記ネットワークノードが上記マルチキャストデータトラフィックを再ルーティングできるかを判定するように構成される、１つ以上のプロセッサと、を含む。上記ネットワークノードは、また、上記ネットワークノードが上記マルチキャストデータトラフィックを再ルーティングできないという判定に応じて、ＤＦＮＰを発信するように構成されるダウンストリームモジュールと、上記マルチキャスト受信ノードに向けて下流に上記ＤＦＮＰを送信するように構成される送信機回路と、を含む。上記ＤＦＮＰは、ダウンストリームマージノードに、共通ソースノードにつながるセカンダリパスへ上記マルチキャストデータトラフィックの受信を切り替えさせる。上記ネットワークノードは、また、上記ダウンストリームマージノードからＵＦＮＰを受信するように構成される受信機回路と、上記ＵＦＮＰの受信に応じて、ダウンストリームネイバであって、当該ダウンストリームネイバ経由で上記ＵＦＮＰが受信された、当該ダウンストリームネイバから、上記ネットワークノードにより上記マルチキャストデータトラフィックが受信されるように、転送情報を修正するように構成されるアップストリームモジュールと、を含む。

一実施形態では、上記ＵＦＮＰ及び上記ＤＦＮＰは、上記マルチキャストデータトラフィックに、上記ネットワークノードと上記ダウンストリームマージノードとの間のフローの方向を逆転させ、それによって、上記マルチキャストデータトラフィックを再ルーティングする。

本発明は、添付の図面の図において、例示のために説明され、限定のために説明されない。図面では、類似の参照番号（reference）は、同様の要素を示す。この開示における「実施形態（”a” embodiment）」又は「一実施形態（”one” embodiment）」への異なる言及（reference）は、必ずしも同じ実施形態へのものではなく、そのような言及は少なくとも１つを意味する、ということに留意されるべきである。さらに、特定の特徴（feature）、構造（structure）又は特性（characteristic）が実施形態に関連して説明される場合に、明示的に説明されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造又は特性をもたらすことは当業者の知識の範囲内であると考えられる。
マルチキャスト通信ネットワークの例を説明する。 マルチキャスト通信ネットワークの例を説明する。 ＭｏＦＲＲにより提供される冗長なセカンダリパスを伴うマルチキャストツリーの例を説明する。 ＭｏＦＲＲにより提供される冗長なセカンダリパスを伴うマルチキャストツリーの例を説明する。 マルチキャスト通信ネットワーク内の単純化されたネットワークセグメントを説明する。 ＭｏＦＲＲに従った転送テーブルの例を説明する。 一実施形態における強化されたＭｏＦＲＲに従った転送テーブルの例を説明する。 一実施形態に従って準備フェーズの間にインターフェースを設定するための方法を説明するフロー図である。 一実施形態に従って障害検出ノードを動作させるための方法を説明するフロー図である。 一実施形態に従って障害検出ノードとマージノードとの間の中間ノードを動作させるための方法を説明するフロー図である。 本発明の一実施形態に従ったネットワークノードの図である。 本発明の一実施形態に従ったネットワークノードの図である。

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

本発明の実施形態は、マルチキャストトラフィックに、障害検出ノードとマージノードとの間の方向を逆転させることを可能にすることにより、ＭｏＦＲＲの障害カバレッジを増加させる。

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

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

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

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

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

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

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

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

増加された障害カバレッジをＰＩＭ−ＳＭに基づく高速再ルーティングに提供する強化されたＭｏＦＲＲが、ここで説明される。ネットワークノードが障害を検出する場合に、当該ネットワークノードのデータプレーン内で生成され処理されるダウンストリーム高速通知パケット（ＤＦＮＰ）を使用することにより、障害リアクションのスピードが改善される。ＤＦＮＰの使用は、非ローカス障害（即ち、遠隔障害、又は、同等に、１ホップよりも多く離れたノード又はリンクで発生した障害）へリアクションについてのスピード及び信頼性を改善する。セカンダリＵＭＨを有しないノードに障害カバレッジを提供することにより、障害カバレッジが増加される。強化されたＭｏＦＲＲは、後に詳細に説明される。

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

図１Ｂは、ＭｏＦＲＲにより提供される不十分な障害カバレッジの問題を説明する、マルチキャスト通信ネットワーク１００のセグメントの例である。ネットワークセグメントにおいて、ノードＳは共通ソースノードであり、ノードＭはマージノードであると仮定する。ノードＳからノードＭへの２つの代替的なパスがある。一方は、プライマリパスＳ->Ｆ->Ｎ１->Ｎ２->Ｍであり、他方は、セカンダリパスＳ->Ｆ->Ｎ３->Ｎ４->Ｍである。ノードＮ１及びＮ２は、ノードＭと同様に加入者を有し得る。ＭｏＦＲＲによれば、ノードＭは、ノードＦに障害が起きる場合に、マルチキャスト受信を上記セカンダリパスパスへ切り替えることができる。しかしながら、ノードＮ１及びＮ２は、セカンダリパスには接続されていないので、障害の場合にマルチキャストを受信できないだろう。

上述したように、ＭｏＦＲＲネットワーク内のノードのうちのいくつかは、セカンダリパスに接続されていないかもしれないので、当該ネットワークは、完全な障害カバレッジを提供しない。本発明の実施形態は、プライマリパス上の障害から下流にあるノードを使用して冗長パスを提供することにより、ＭｏＦＲＲの障害カバレッジを増加させる。図１Ｂの例では、（障害から次のホップである）ノードＮ１と（動作中のセカンダリパスを有するノードである）ノードＭとの間でマルチキャストデータトラフィックを逆転させることにより、ノードＮ１及びＮ２のための（点線により示される）冗長パスを提供することができる。ノードＭは、ノードＮ３及びＮ４経由の上記セカンダリパスからマルチキャストを受信するだろう。結果として、ノードＭ、Ｎ１及びＮ２の全ては、ノードＦの障害の前のように、マルチキャストを受信し続けることができる。

図２Ａは、ＭｏＦＲＲをサポートするマルチキャスト通信ネットワーク２００の例を説明する。ＭＣＩ->Ａ->Ｂ->Ｃ->Ｄ->Ｅ及びＭＣＩ->Ｆ->Ｇを接続する細線は、ＰＩＭ−ＳＭにより定義されるマルチキャストツリーを形成する。Ａ->Ｊ->Ｃ、Ｃ->Ｋ->Ｅ、及びＧ->Ｈ->Ｉ->Ｄを接続する太線は、それぞれノードＣ、Ｅ及びＤのためにＭｏＦＲＲにより追加されたセカンダリバックアップパスを表す。したがって、ノードＣ、Ｄ及びＥは、デュアル接続ノードである。ノードＣの、ＭＣＩからのプライマリパスは、ＭＣＩ->Ａ->Ｂ->Ｃであり、ノードＣのセカンダリパスは、ＭＣＩ->Ａ->Ｊ->Ｃである。したがって、ノードＣのプライマリＵＭＨはノードＢであり、セカンダリＵＭＨはノードＪである。ノードＢは、プライマリＵＭＨとしてノードＡを有するが、セカンダリＵＭＨを有しない。

図２Ｂは、マルチキャスト通信ネットワーク２１０の例を説明する。マルチキャスト通信ネットワーク２１０は、ネットワーク２００と同じ構成を有するが、障害が発生したノードＡを伴う。ＭｏＦＲＲのルールに従って、ノードＢ、Ｃ、Ｊ及びＫの各々は、ノードＡの障害から保護することができる動作中のセカンダリパス有しない。強化されたＭｏＦＲＲの実施形態は、高速な予め計算された手法で動作中のセカンダリパスを有しないノードへのマルチキャストストリームを再確立する。Ａの障害を伴う上述した例では、ノードＤは、セカンダリＵＭＨ（即ち、ノードＩ）へ切り替えることができる。ノードＣは、ノードＤへ切り替えることができ、ノードＢ及びＪは、ノードＣへ切り替えることができる。ノードＫは、ノードＣからＤＦＮＰを受信し、（ノードＫはいずれのセカンダリパスも有しないので）それをノードＥへ転送するだろう。しかしながら、（動作中のセカンダＵＭＨを有する）ノードＤは、ＤＦＮＰをノードＥへ転送しないので、ノードＥは、ＤＦＮＰをノードＫから受信するのみであろう。したがって、ノードＥは、セカンダリＵＭＨからのみＤＦＮＰを受信し、それにリアクションしないであろう。結果として、マルチキャストデータトラフィックフローは、ノードＢとノードＤとの間、及び、ノードＪとノードＤとの間で、逆転される。ノードＢ及びＪは、障害からの次のホップであり、ノードＤは、動作中のセカンダリパスを有するノードである。

図２Ｂの例のような障害の場合にトラフィックフローを逆転させる強化されたＭｏＦＲＲを説明する前に、まず障害検出技術を説明する。障害検出は、ダウンストリーム高速通知パケット（ＤＦＮＰ）を使用して、障害の発生と、アップストリームノードが当該障害を修復できないこととを、当該障害から下流のノードに通知する。

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

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

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

以下では、ＤＦＮＰ発信ノードから下流の各ノードが従うルール（Ｒ１−Ｒ４）に関する説明が提供される。一実施形態では、ルールは、図７Ａ及び図７Ｂ内で以下に説明されるネットワークノードなどの各ノードのデータプレーン回路に保存され得る。

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

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

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

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

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

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

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

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

図１Ｂ及び図２Ｂにおいて説明されるマルチキャストフローの逆転を可能にするために、ネットワークノードの各々は、準備フェーズ、第１の障害リアクションフェーズ、及び第２の障害リアクションフェーズという３つのフェーズで動作を実行するように構成される。準備フェーズでは、各ネットワークノードは、障害への高速なリアクションを起こせるように、入力インターフェース（ＩＩＦ）及び出力インターフェース（ＯＩＦ）を準備する。一実施形態では、ＩＩＦ及びＯＩＦは、ネットワークノードのデータプレーンカード（即ち、ラインカード）内の転送情報データベース（ＦＩＤ）又は転送テーブルにインストールされている。

第１の障害リアクションフェーズでは、ＵＭＨの障害を検出するノードから下流にＤＦＮＰが送信される。ノードは、上記ＤＦＮＰを受信する場合に、アップストリーム方向においてＯＩＦのブロック解除を行う。第２の障害リアクションフェーズでは、動作中のセカンダリＵＭＨを有するノード（即ち、上記ルールＲ１−Ｒ４により定義される修復ノード）は、ＭＣＩに向けてブランチの全てに沿って上流にプライマリパス上でアップストリーム高速通知パケット（ＵＦＮＰ）を送信する。ノードは、ＵＦＮＰを受信する場合に、ダウンストリームノードへの入力インターフェースのブロック解除を行う。

３つのフェーズの動作は、以下でさらに詳細に説明される。図３Ａ−３Ｃは、図３Ａのネットワークセグメント３００内のノードＭにより実行される準備フェーズの例を説明する。ノードＭは、プライマリＵＭＨ Ｕ１及びセカンダリＵＭＨ Ｕ２を有する。ノードＭは、２つのダウンストリームノードＤ１及びＤ２も有する。図３Ｂに示されるようにＭｏＦＲＲによれば、ノードＭは、元のＩＩＦ３２１：Ｕ１及び（Ｕ２）のリストと、元のＯＩＦ３２２：Ｄ１及びＤ２のリストとを含む転送テーブル３０２を保存する。インターフェースの周りの丸括弧のペアは、インターフェースがブロックされていることを示す。図３Ｃに示されるような、増加された障害カバレッジを伴う強化されたＭｏＦＲＲの実施形態によれば、ノードＭは、拡張ＩＩＦ３６１：Ｕ１、（Ｕ２）、（Ｄ１）及び（Ｄ２）のリストと、拡張ＯＩＦ３６２：（Ｕ１）、（Ｕ２）、Ｄ１及びＤ２のリストとを含む転送テーブル３０６を保存する。

図２ＡのノードＣを参照すると、ＰＩＭによれば、ノードＣは、ノードＢにつながるＩＩＦと、ノードＤ及びＫにつながる２つのＯＩＦをインストールする。ＭｏＦＲＲによれば、ノードＪは、ノードＣにとってＭＣＩに向かうセカンダリＵＭＨであるので、ノードＣは、ブロック状態のノードＪにつながる追加のＩＩＦもインストールする。ノードＣは、ノードＢ及びＪから同じトラフィックを受信するが、ノードＪからのトラフィックは、破棄される。

強化されたＭｏＦＲＲの一実施形態によれば、ノードＣは、ＩＩＦと同様に、Ｂに向かうインターフェースを、ブロックされたＯＩＦとしてインストールする。ノードＣは、ＯＩＦと同様に、ノードＤ及びＫへのインターフェースも、ブロックされたＩＩＦとしてインストールする。テーブル１−３は、ＭＣＩからのマルチキャストツリーのためにインターフェースをどのようにインストールできるかを示す例を提供する。丸括弧の中のインターフェースは、ブロックされている。

図４は、マルチキャスト通信ネットワークの各ノード内でインターフェースをインストールするための方法４００を説明するフロー図である。方法４００は、各ネットワークノードが、元のＩＩＦのリストを拡張して、ネットワークノードの元のＩＩＦの全てと元のＯＩＦの全てとを含むＩＩＦの拡張リストを形成することから始まる（ブロック４１０）。「元のＩＩＦ」及び「元のＯＩＦ」は、ＭｏＦＲＲに従ってインストールされるインターフェースを表す。その後、各ネットワークノードは、転送テーブル内の元のＯＩＦのリストを拡張して、ネットワークノードの元のＩＩＦの全てと元のＯＩＦの全てとを含むＯＩＦの拡張リストを形成する（ブロック４２０）。続いて、各ネットワークノードは、プライマリＵＭＨにつながる元のＩＩＦを除く、ＩＩＦの拡張リスト内のＩＩＦの全てに、ブロックされているとマーキングする（ブロック４３０）。各ネットワークノードは、ＯＩＦの拡張リスト内の元のＩＩＦの全てにも、ブロックされているとマーキングする（ブロック４４０）。

強化されたＭｏＦＲＲの追加のインターフェースの全てが、ブロック状態でインストールされるので、マルチキャストデータトラフィックは、ネットワーク内に障害がないときにＰＩＭで確立されたマルチキャストツリーへ同様に流れる。ネットワーク内に障害が発生する場合に、ネットワークの動作は、第１の障害リアクションフェーズに入る。当該第１の障害リアクションフェーズの間に、マルチキャストツリーにおいてバックアップパスがアクティベートされる。

ノードは、ＵＭＨの障害を検出する場合に、フォールバックする動作中のセカンダリパスを有しなければ、上述したようにＤＦＮＰを発信する。上記ＤＦＮＰを受信するダウンストリームノードは、以下のような追加の動作で上述したルールＲ１−Ｒ４に従ってＤＦＮＰを処理する。

ダウンストリームノードが、ＵＭＨからＤＦＮＰを受信する場合に、それは、アップストリームノードのいずれも障害を修復できないことの兆候（indication）である。したがって、ダウンストリームノードは、拡張ＯＩＦ内のＵＭＨインターフェースを見つけ、そのインターフェースのブロック解除を行う。

このダウンストリームノードが、障害のないセカンダリパスを有する（即ち、このダウンストリームノードが、セカンダリＵＭＨからＤＦＮＰを受信しないか、又はそうでなければ、セカンダリＵＭＨからいずれの障害も検出しない）場合に、ダウンストリームノードは、拡張ＩＩＦリスト内のセカンダリＵＭＨのブロック解除を行い、且つ、拡張ＩＩＦリスト内のプライマリＵＭＨをブロックする。セカンダリＵＭＨのブロック解除を行うことは、ダウンストリームノードに、マルチキャストデータトラフィックを受信することを可能にする。一実施形態では、このダウンストリームノードはマージノードである。

ＤＦＮＰがこのマージノードに到達する場合に、ネットワークの動作は第２の障害リアクションフェーズに入る。当該第２の障害リアクションフェーズでは、この動作中のセカンダリＵＭＨから受信されるデータトラフィックが、ＤＦＮＰが受信された方向へ送信されるように、マルチキャストツリーが修正される。

第２の障害リアクションフェーズの間に、マージノードは、アップストリーム高速通知パケット（ＵＦＮＰ）を送信する。当該ＵＦＮＰは、データプレーン内で生成され処理される通知である。ＵＦＮＰは、プライマリパス及びセカンダリパスを含む、アップストリーム方向の全てのパスに沿って、ＭＣＩに向かって送信される。ＤＦＮＰと同様に、ＵＦＮＰは、障害により影響を与えられるマルチキャストツリーを一義的に識別する。一実施形態では、ＵＦＮＰは、（例えば、ＩＰソース／宛先アドレスフィールド内に、）マルチキャストソースアドレスと、マルチキャストグループ又はマルチキャストツリーを識別するマルチキャストグループアドレスとを含む。ＵＦＮＰは、（例えばＩＰヘッダ内に）特別なＩＰプロトコル値、又は、ＰＩＭに対応する「１０３」などの特別に割り当てられたユーザデータグラムプロトコル（ＵＤＰ）ポート番号を含むことにより、容易に認識可能である。トラブルシューティング目的のためのいくつかの実施形態では、ペイロードが、ＵＦＮＰを発信するノードのＩＤを含んでもよく、接続性が失われたノードのＩＤ、及び／又は接続性が失われたリンクＩＤも含んでもよい。いくつかの実施形態では、ＵＦＮＰは、ＵＦＮＰの発信の時間を示すタイムスタンプも含んでもよい。

ＵＦＮＰを受信するいずれかのノードは、拡張ＩＦＦリスト内の、ＵＦＮＰが受信されたインターフェースのブロック解除を行い、拡張ＯＩＦリスト内の同じインターフェースをブロックする。ＵＦＮＰは、複数のダウンストリームレッグから受信され得るが、マルチキャストグループについて受信された第１のＵＦＮＰについてのインターフェースのみが、拡張ＩＩＦリストにおいてブロック解除される、ということに留意する。他のＵＦＮＰは、破棄される。ＵＦＮＰは、ＤＦＮＰが発信されたポイントまで上流に送信される。

図２Ｂの例を参照すると、ノードＡへ障害が発生すると、第１のＤＦＮＰが、ノードＢにより発信され、ノードＣへ下流に送信される。第２のＤＦＮＰは、ノードＪにより発信され、ノードＣへ下流に送信される。

ノードＣは、ＤＮＦＰを受信する場合に、拡張ＯＩＦリスト内の、ノードＢにつながるインターフェースのブロック解除を行い、当該ＤＦＮＰのうちの１つをノードＤ及びＫへさらに下に送信する。他のＤＦＮＰは、転送されない。ノードＤは、上記ＤＦＮＰを受信する場合に、拡張ＯＩＦリスト内の、ノードＣにつながるインターフェースのブロック解除を行う。ノードＤは、動作中のセカンダリＵＭＨを有する。そのため、ノードＤは、当該セカンダリＵＭＨへの入力インターフェースのブロック解除を行い、ＵＦＮＰを生成し、当該ＵＦＮＰをノードＣへ上流に送信する。

ノードＣは、上記ＵＦＮＰを受信する場合に、拡張ＩＩＦリスト内の、ノードＤにつながるインターフェースのブロック解除を行い、拡張ＯＩＦリスト内の同じインターフェースをブロックし、上記ＵＦＮＰをノードＢへ上流に転送する。ノードＢは、上記ＵＦＮＰを受信する場合に、拡張ＩＩＦリスト内の、ノードＣにつながるインターフェースのブロック解除を行い、拡張ＯＩＦリスト内の同じインターフェースをブロックし、ＤＦＮＰを発信するノードＢとして上記ＵＦＮＰを破棄する。

ノードＢ、Ｃ及びＤについての、結果として生じる修正されたマルチキャスト転送エントリが、テーブル４−６において以下に示される。丸括弧の中のインターフェースは、ブロックされている。

上述した例から見られるように、強化されたＭｏＦＲＲを用いて、ノードＢ、Ｃ、Ｊ及びＫは、マルチキャストデータストリームを受信することができる。これは、従来型のＭｏＦＲＲでは不可能である。ノードＢ、Ｃ、Ｊ及びＫが、その下の下流に（図２Ｂには示されていない）さらなるノードを有する場合には、本発明の実施形態によれば、これらのダウンストリームノードも、マルチキャストデータトラフィックを受信し続けることができる。

図５は、本発明の一実施形態に従ってマルチキャスト通信ネットワーク内のネットワークノードを動作させるための方法５００を説明するフロー図である。この実施形態の当該ネットワークノードは、障害検出ノードである。方法５００は、ネットワークノードがＵＭＨへの入力インターフェースで接続の損失を検出することから始まる（ブロック５１０）。上記ネットワークノードは、マルチキャストデータトラフィックがマルチキャスト受信ノードにより受信されることを可能にするために上記ネットワークノードが上記マルチキャストデータトラフィックを再ルーティングできるかを判定する。上記ネットワークノードは、上記ネットワークが再ルーティングを行うことができないと判定する場合に（ブロック５２０）、マルチキャスト受信ノードに向けて下流にＤＦＮＰを送信する（ブロック５３０）。上記ＤＦＮＰは、ダウンストリームマージノードに、共通ソースノードにつながるセカンダリパスへマルチキャストデータパケットの受信を切り替えさせ、アップストリームネイバであって、当該アップストリームネイバ経由で上記ＤＦＮＰが受信された、当該アップストリームネイバへ、マルチキャストデータトラフィックを転送させる。続いて、上記ネットワークノードは、上記マージノードからＵＦＮＰを受信する（ブロック５４０）。上記ＵＦＮＰの受信に応じて、上記ネットワークノードは、ダウンストリームネイバであって、当該ダウンストリームネイバ経由で上記ＵＦＮＰが受信された、当該ダウンストリームネイバから、上記ネットワークノードによりマルチキャストデータトラフィックが受信されることができるように、転送情報を修正する（ブロック５５０）。上記ＤＦＮＰ及び上記ＵＦＮＰは、上記マルチキャストデータトラフィックに、上記ネットワークノードと上記ダウンストリームマージノードとの間のフローの方向を逆転させ、それによって、上記マルチキャストデータトラフィックを再ルーティングする。

図６は、本発明の一実施形態に従ってマルチキャスト通信ネットワーク内のネットワークノードを動作させるための方法６００を説明するフロー図である。この実施形態におけるネットワークノードは、障害検出ノードとマージノードとの間
中間ノードである。方法６００は、中間ノードがＤＦＮＰを受信することから始まる（ブロック６１０）。上記中間ノードは、拡張ＯＩＦリスト内の１つ以上のＯＩＦのブロック解除を行って、マルチキャストデータトラフィックが上記中間ノードの１つ以上のアップストリームネイバへ流れることを可能にする（ブロック６２０）。上記中間ノードは、また、拡張ＯＩＦリスト内のその時点でブロックされていない（currently-unblocked）ＯＩＦをブロックする（ブロック６３０）。上記中間ノードは、ＵＦＮＰを受信する場合に（ブロック６４０）、ダウンストリームネイバであって、当該ダウンストリームネイバから上記ＵＦＮＰが受信された、当該ダウンストリームネイバにつながる、拡張ＩＩＦリスト内のＩＩＦのブロック解除を行う（ブロック６５０）。上記中間ノードは、また、拡張ＩＩＦリスト内のその時点でブロックされていないＩＩＦをブロックする（ブロック６６０）。

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

上記データプレーンは、受信機回路７４０及び送信機回路７６０も含む。受信機回路７４０及び送信機回路７６０は、マルチキャストデータ、及び上述したＵＦＮＰ及びＤＦＮＰを含む制御パケットを、それぞれ受信し、送信するように構成される。

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

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

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

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

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

Claims (20)

1. マルチキャスト通信ネットワーク内のネットワークノードにより実行される方法であって、
   前記マルチキャスト通信ネットワークは、共通ソースノードから１つ以上のマルチキャスト受信ノードへの接続性を提供するマルチキャストツリーを含み、
   前記マルチキャスト通信ネットワークは、前記マルチキャストツリーに冗長性を提供する一連のセカンダリパスをさらに含み、
   前記方法は、
   前記ネットワークノードにより、アップストリームネイバへの入力インターフェースで接続の損失を検出するステップと、
   マルチキャストデータトラフィックが前記マルチキャスト受信ノードに到達することを可能にするために、前記ネットワークノードが前記マルチキャストデータトラフィックを再ルーティングすることができない、と判定するステップと、
   前記ネットワークノードから前記マルチキャスト受信ノードに向けて下流にダウンストリーム高速通知パケット（ＤＦＮＰ）を送信するステップと、
   前記ＤＦＮＰは、ダウンストリームマージノードに、前記共通ソースノードにつながるセカンダリパスへ前記マルチキャストデータトラフィックの受信を切り替えさせることと、
   前記ネットワークノードにより、前記ダウンストリームマージノードからのアップストリーム高速通知パケット（ＵＦＮＰ）を受信するステップと、
   前記ネットワークノードのダウンストリームネイバであって、当該ダウンストリームネイバ経由で前記ＵＦＮＰが受信された、当該ダウンストリームネイバから、前記マルチキャストデータトラフィックが前記ネットワークノードにより受信されるように、前記ＵＦＮＰの受信に応じて前記ネットワークノードの転送情報を修正するステップと、
   前記ＤＦＮＰ及び前記ＵＦＮＰは、前記マルチキャストデータトラフィックに、前記ネットワークノードと前記ダウンストリームマージノードとの間のフローの方向を逆転させ、それによって、前記マルチキャストデータトラフィックを再ルーティングすることと、
   を含む、方法。
2. 前記ダウンストリームマージノードは、前記共通ソースノードへのプライマリパス上のプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、前記共通ソースノードへの前記セカンダリパス上のセカンダリＵＭＨと、結合され、
   前記方法は、ＥＣＭＰ（Equal Cost MultiPath）又はＬＦＡ（Loop Free Alternate）に基づいて前記セカンダリＵＭＨを選択するステップをさらに含む、
   請求項１の方法。
3. 前記ネットワークノードは、前記ネットワークノードの元の出力インターフェース（ＯＩＦ）のリスト及び元の入力インターフェース（ＩＩＦ）のリストを記録する転送テーブルをメモリ内に備え、
   前記方法は、検出する前記ステップの前に、
   前記転送テーブル内の元のＩＩＦの前記リストを拡張して、前記元のＩＩＦの全てと前記元のＯＩＦの全てとを含むＩＩＦの拡張リストを形成するステップと、
   前記転送テーブル内の元のＯＩＦの前記リストを拡張して、前記元のＩＩＦの全てと前記元のＯＩＦの全てとを含むＯＩＦの拡張リストを形成するステップと、
   前記ネットワークノードのプライマリアップストリームネイバにつながる元のＩＩＦを除く、ＩＩＦの前記拡張リスト内の前記ＩＩＦの全てに、ブロックされているとマーキングするステップと、
   ＯＩＦの前記拡張リスト内の前記元のＩＩＦの全てに、ブロックされているとマーキングするステップと、
   をさらに含む、請求項１の方法。
4. 一連の中間ノードが、前記ネットワークノードと前記ダウンストリームマージノードとの間に位置し、
   前記ＤＦＮＰは、各中間ノードに、前記中間ノードの１つ以上のアップストリームネイバにつながる１つ以上のＯＩＦのブロック解除を行わせ、且つ、その時点でブロックされていないＯＩＦをブロックさせる、
   請求項１の方法。
5. 前記ＤＦＮＰは、前記ダウンストリームマージノードに、前記ダウンストリームマージノードのプライマリアップストリームネイバにつながるＯＩＦのブロック解除を行わせ、前記ダウンストリームマージノードのセカンダリアップストリームネイバにつながるＩＩＦのブロック解除を行わせ、且つ、その時点でブロックされていないＩＩＦをブロックさせる、請求項１に記載の方法。
6. 一連の中間ノードが、前記ネットワークノードと前記ダウンストリームマージノードとの間に位置し、
   前記ＵＦＮＰは、各中間ノードに、前記中間ノードのダウンストリームネイバであって、当該ダウンストリームネイバから前記ＵＦＮＰが受信された、当該ダウンストリームネイバへのＩＩＦのブロック解除を行わせ、且つ、その時点でブロックされていないＩＩＦをブロックさせる、
   請求項１の方法。
7. 判定する前記ステップは、
   前記共通ソースノードを前記ネットワークノードに結合するセカンダリパスを前記ネットワークノードが有しないと判定すること、前記セカンダリパスから障害の標識を前記ネットワークノードが受信すると判定すること、又は、前記セカンダリパス上のセカンダリアップストリームネイバに結合されるＩＩＦで前記ネットワークノードが障害を検出すると判定すること、
   のうちの１つ以上を判定することをさらに含む、請求項１の方法。
8. 前記ＤＦＮＰ及び前記ＵＦＮＰの処理は、データプレーン内の前記ネットワークノードの１つ以上のラインカードに保存される前記転送情報に基づく、請求項１の方法。
9. 前記ＤＦＮＰは、前記ＤＦＮＰが前記ダウンストリームマージノードに到達する場合にさらに下流に転送されない、請求項１の方法。
10. 前記ＵＦＮＰは、前記ＵＦＮＰが前記ネットワークノードに到達する場合にさらに上流に転送されない、請求項１の方法。
11. 共通ソースノードから１つ以上のマルチキャスト受信ノードへの接続性を提供するマルチキャストツリーを含むマルチキャスト通信ネットワーク内のネットワークノードであって、
    前記マルチキャスト通信ネットワークは、前記マルチキャストツリーに冗長性を提供する一連のセカンダリパスをさらに含み、
    前記ネットワークノードは、
    マルチキャストトラフィックについての転送情報を保存するように構成されるメモリと、
    前記メモリに結合される１つ以上のプロセッサであって、アップストリームネイバへの入力インターフェースで接続の損失を検出するように、且つ、マルチキャストデータトラフィックが前記マルチキャスト受信ノードに到達することを可能にするために前記ネットワークノードが前記マルチキャストデータトラフィックを再ルーティングすることができるかを判定するように、構成される前記１つ以上のプロセッサと、
    前記プロセッサに結合されるダウンストリームモジュールであって、前記ネットワークノードが前記マルチキャストデータトラフィックを再ルーティングできないという判定に応じてダウンストリーム高速通知パケット（ＤＦＮＰ）を発信するように構成される前記ダウンストリームモジュールと、
    前記プロセッサに結合される送信機回路であって、前記マルチキャスト受信ノードに向けて下流に前記ＤＦＮＰを送信するように構成される前記送信機回路と、
    を備え、
    前記ＤＦＮＰは、ダウンストリームマージノードに、前記共通ソースノードにつながるセカンダリパスへ前記マルチキャストデータトラフィックの受信を切り替えさせ、
    前記ネットワークノードは、
    前記プロセッサに結合される受信機回路であって、前記ダウンストリームマージノードからのアップストリーム高速通知パケット（ＵＦＮＰ）を受信するように構成される前記受信機回路と、
    前記プロセッサに結合されるアップストリームモジュールであって、前記ネットワークノードのダウンストリームネイバであって、当該ダウンストリームネイバ経由で前記ＵＦＮＰが受信された、当該ダウンストリームネイバから、前記マルチキャストデータトラフィックが前記ネットワークノードにより受信されるように、前記ＵＦＮＰの受信に応じて前記転送情報を修正する、ように構成される前記アップストリームモジュールと、
    を備え、
    前記ＵＦＮＰ及び前記ＤＦＮＰは、前記マルチキャストデータトラフィックに、前記ネットワークノードと前記ダウンストリームマージノードとの間のフローの方向を逆転させ、それによって、前記マルチキャストデータトラフィックを再ルーティングする、
    ネットワークノード。
12. 前記ダウンストリームマージノードは、前記共通ソースノードへのプライマリパス上のプライマリアップストリームマルチキャストホップ（ＵＭＨ）と、前記共通ソースノードへの前記セカンダリパス上のセカンダリＵＭＨと、結合され、
    前記セカンダリＵＭＨは、ＥＣＭＰ（Equal Cost MultiPath）又はＬＦＡ（Loop Free Alternate）に基づいて選択される、
    請求項１１のネットワークノード。
13. 前記ネットワークノードは、前記ネットワークノードの元の出力インターフェース（ＯＩＦ）のリスト及び元の入力インターフェース（ＩＩＦ）のリストを記録する転送テーブルを備え、
    前記ネットワークノードは、前記接続の損失の検出の前に、
    前記転送テーブル内の元のＩＩＦの前記リストを拡張して、前記元のＩＩＦの全てと前記元のＯＩＦの全てとを含むＩＩＦの拡張リストを形成し、
    前記転送テーブル内の元のＯＩＦの前記リストを拡張して、前記元のＩＩＦの全てと前記元のＯＩＦの全てとを含むＯＩＦの拡張リストを形成し、
    前記ネットワークノードのプライマリアップストリームネイバにつながる元のＩＩＦを除く、ＩＩＦの前記拡張リスト内の前記ＩＩＦの全てに、ブロックされているとマーキングし、
    ＯＩＦの前記拡張リスト内の前記元のＩＩＦの全てに、ブロックされているとマーキングする
    ように構成される、請求項１１のネットワークノード。
14. 一連の中間ノードが、前記ネットワークノードと前記ダウンストリームマージノードとの間に位置し、
    前記ＤＦＮＰは、各中間ノードに、前記中間ノードの１つ以上のアップストリームネイバにつながる１つ以上のＯＩＦのブロック解除を行わせ、且つ、その時点でブロックされていないＯＩＦをブロックさせる、
    請求項１１のネットワークノード。
15. 前記ＤＦＮＰは、前記ダウンストリームマージノードに、前記ダウンストリームマージノードのプライマリアップストリームネイバにつながるＯＩＦのブロック解除を行わせ、前記ダウンストリームマージノードのセカンダリアップストリームネイバにつながるＩＩＦのブロック解除を行わせ、且つ、その時点でブロックされていないＩＩＦをブロックさせる、請求項１１のネットワークノード。
16. 一連の中間ノードが、前記ネットワークノードと前記ダウンストリームマージノードとの間に位置し、
    前記ＵＦＮＰは、各中間ノードに、前記中間ノードのダウンストリームネイバであって、当該ダウンストリームネイバから前記ＵＦＮＰが受信された、当該ダウンストリームネイバへのＩＩＦのブロック解除を行わせ、且つ、その時点でブロックされていないＩＩＦをブロックさせる、
    請求項１１のネットワークノード。
17. 前記１つ以上のプロセッサは、前記共通ソースノードを前記ネットワークノードに結合するセカンダリパスを前記ネットワークノードが有しないこと、前記セカンダリパスから障害の標識を前記ネットワークノードが受信すること、又は、前記セカンダリパス上のセカンダリアップストリームネイバに結合されるＩＩＦで前記ネットワークノードが障害を検出すること、のうちの１つ以上に基づいて、前記ネットワークノードが前記マルチキャストデータトラフィックを再ルーティングできないと判定するように構成される、請求項１１のネットワークノード。
18. 前記ネットワークノードは、データプレーン内に１つ以上のラインカードをさらに備え、前記ネットワークノードは、前記１つ以上のラインカードに保存される前記転送情報に基づいて前記ＤＦＮＰ及び前記ＵＦＮＰを処理するようにさらに構成される、請求項１１のネットワークノード。
19. 前記ＤＦＮＰは、前記ＤＦＮＰが前記ダウンストリームマージノードに到達する場合にさらに下流に転送されない、請求項１１のネットワークノード。
20. 前記ＵＦＮＰは、前記ＵＦＮＰが前記ネットワークノードに到達する場合にさらに上流に転送されない、請求項１１のネットワークノード。
    

Images