特許 5876493 ネットワーク障害から復旧するための高速フラッディングベースの高速収束

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5876493

(24)【登録日】2016年1月29日

(45)【発行日】2016年3月2日

(54)【発明の名称】ネットワーク障害から復旧するための高速フラッディングベースの高速収束

(51)【国際特許分類】

   H04L 12/703 20130101AFI20160218BHJP

【ＦＩ】

   H04L12/703

【請求項の数】22

【全頁数】39

(21)【出願番号】特願2013-530831(P2013-530831)

(86)(22)【出願日】2011年9月22日

(65)【公表番号】特表2013-542662(P2013-542662A)

(43)【公表日】2013年11月21日

(86)【国際出願番号】IB2011054156

(87)【国際公開番号】WO2012042440

(87)【国際公開日】20120405

【審査請求日】2014年8月22日

(31)【優先権主張番号】13/091,081

(32)【優先日】2011年4月20日

(33)【優先権主張国】US

(31)【優先権主張番号】61/447,669

(32)【優先日】2011年2月28日

(33)【優先権主張国】US

(31)【優先権主張番号】61/406,420

(32)【優先日】2010年10月25日

(33)【優先権主張国】US

(31)【優先権主張番号】61/387,511

(32)【優先日】2010年9月29日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エル エム エリクソン（パブル）

(74)【代理人】

【識別番号】100095957

【弁理士】

【氏名又は名称】亀谷 美明

(74)【代理人】

【識別番号】100096389

【弁理士】

【氏名又は名称】金本 哲男

(74)【代理人】

【識別番号】100101557

【弁理士】

【氏名又は名称】萩原 康司

(74)【代理人】

【識別番号】100128587

【弁理士】

【氏名又は名称】松本 一騎

(72)【発明者】

【氏名】ルー、ウェンフー

(72)【発明者】

【氏名】ティアン、アルバート ジニン

【審査官】 衣鳩 文彦

(56)【参考文献】

【文献】 米国特許第０６９２８４８３（ＵＳ，Ｂ１）

【文献】 米国特許第０６６５０６２６（ＵＳ，Ｂ１）

【文献】 米国特許第０６６０６３２５（ＵＳ，Ｂ１）

【文献】 特開２０１１−０６１４７４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００〜１２／９５５

(57)【特許請求の範囲】

【請求項1】

ネットワーク障害から復旧するために高速フラッディングベースの高速収束を開始するためのルータにおける方法であって、当該方法は、
ネットワーク障害を検出するステップと、
検出された前記ネットワーク障害に応じて、前記ルータの１つ以上のインタフェースのセットから高速障害通知メッセージをフラッディングするステップと、
前記高速障害通知メッセージは、前記ネットワーク障害を識別する情報を含むことと、
前記高速障害通知メッセージは、そのソースＭＡＣ（Media Access Control）アドレスとして、検出された前記ネットワーク障害に結合され且つ前記ルータの前記インタフェースのセットの一部ではないインタフェースに割り当てられるＭＡＣアドレスを含むことと、
前記ネットワーク障害を反映するためにルーティングテーブルを更新するステップと、
を含み、
前記ルータの前記インタフェースのセットから前記高速障害通知メッセージをフラッディングすることは、前記ネットワーク障害を反映するための前記ルーティングテーブルの更新の完了に先立って実行される、
方法。

【請求項2】

前記ネットワーク障害を検出するステップは、レイヤ２のリンクイベントモニタリング及びシグナリング、並びに双方向転送検出（ＢＦＤ）のうちの１つ以上によって実行される、請求項１に記載の方法。

【請求項3】

前記ネットワーク障害を反映するためにルーティングテーブルを更新するステップの後に、前記ネットワーク障害を示すメッセージの通常のフラッディングを開始するステップ、
をさらに含む、請求項１に記載の方法。

【請求項4】

前記高速障害通知メッセージは、その宛先ＭＡＣアドレスとして、高速障害通知メッセージフラッディングのために予約されるＭＡＣアドレスをさらに含み、
当該高速障害通知メッセージは、当該高速障害通知メッセージを受信することとなる前記ルータに、そのルーティングテーブルを更新すべきかを判定する前に、そのデータトランスポート層において当該高速障害通知メッセージを１つ以上のそのインタフェースのセットからフラッディングすべきかを判定することを指示する、
請求項１に記載の方法。

【請求項5】

前記高速障害通知メッセージは、プロトコル非依存なフォーマットを有し、前記ルータのデータプレーンによって発行される、請求項１に記載の方法。

【請求項6】

前記高速障害通知メッセージは、特定のＩＧＰルーティングプロトコルに固有のＩＧＰ ＰＤＵ（Interior Gateway Protocol Protocol Data Unit）パケットフォーマットを有する、請求項１に記載の方法。

【請求項7】

ネットワーク障害から復旧するために高速フラッディングベースの高速収束を開始するためのルータであって、当該ルータは、
当該ルータを複数の他のルータに結合するための複数のインタフェース、及び、
検出されたネットワーク障害に応答して、前記ネットワーク障害を識別する情報を含み、検出された前記ネットワーク障害に結合される前記インタフェースに割り当てられるＭＡＣアドレスをそのソースＭＡＣアドレスとして含む高速障害通知メッセージを、前記複数のインタフェースのうちの１つ以上からフラッディングするように構成される高速障害通知（ＦＦＮ）モジュール、
を含む、データトランスポート層と、
検出された前記ネットワーク障害に応答してルーティングテーブルを更新するように構成されるルーティングプロトコルモジュールを含むアプリケーション層と、
を備え、
前記ＦＦＮモジュールは、前記ルーティングプロトコルモジュールによって実行されることとなる前記ルーティングテーブルの更新とは独立に、前記複数のインタフェースのうちの前記１つ以上から前記高速障害通知メッセージをフラッディングするようにさらに構成される、
ルータ。

【請求項8】

前記ルータは、レイヤ２のリンクイベントモニタリング及びシグナリング、並びに双方向転送検出（ＢＦＤ）のうちの１つ以上によって、前記ネットワーク障害を検出するようにさらに構成される、請求項７に記載のルータ。

【請求項9】

前記ルーティングプロトコルモジュールは、当該ルーティングプロトコルモジュールが前記ルーティングテーブルを更新した後に、前記ネットワーク障害を示すメッセージの通常のフラッディングを開始するようにさらに構成される、請求項７に記載のルータ。

【請求項10】

前記高速障害通知メッセージは、その宛先ＭＡＣアドレスとして、高速障害通知メッセージフラッディングのために予約されるＭＡＣアドレスをさらに含み、
当該高速障害通知メッセージは、当該高速障害通知メッセージを受信することとなる前記ルータに、そのルーティングプロトコルモジュールが前記ネットワーク障害を反映するためにそのルーティングテーブルを更新することとは独立に、そのデータトランスポート層において当該高速障害通知メッセージを１つ以上のそのインタフェースのセットからフラッディングすべきかを判定することを指示する、
請求項７に記載のルータ。

【請求項11】

前記高速障害通知メッセージは、プロトコル非依存なフォーマットを有し、前記ルータのデータプレーンによって発行される、請求項７に記載のルータ。

【請求項12】

前記ルーティングプロトコルモジュールは、ＩＧＰ（Interior Gateway Protocol）モジュールであり、
前記高速障害通知メッセージは、当該ＩＧＰモジュールに固有のＩＧＰ ＰＤＵ（Protocol Data Unit）パケットフォーマットを有する、
請求項７に記載のルータ。

【請求項13】

ネットワーク障害から復旧するために高速フラッディングベースの高速収束に参加するためのルータにおける方法であって、当該方法は、
ネットワーク障害を識別する情報を含む第１の高速障害通知メッセージを前記ルータのインタフェース上で受信するステップと、
前記第１の高速障害通知メッセージのソースＭＡＣ（Media Access Control）アドレスは前記インタフェースに関連付けられていないと判定することに応じて、
前記ソースＭＡＣアドレスとインタフェースとのペアを前記ルータのブリッジＭＡＣテーブルに追加するステップ、
１つ以上の他のルータへの伝送のために１つ以上の他のインタフェースに前記第１の高速障害通知メッセージをフラッディングするステップ、及び、
前記ネットワーク障害を反映するためにルーティングテーブルを更新するステップ、
を実行するステップと、
を含み、
前記第１の高速障害通知メッセージをフラッディングするステップは、前記ネットワーク障害を反映するために前記ルーティングテーブルを更新するステップの完了に先立って実行される、
方法。

【請求項14】

ネットワーク障害を識別する情報を含む第２の高速障害通知メッセージを前記ルータの前記インタフェース上で受信するステップと、
当該第２の高速障害通知メッセージのソースＭＡＣアドレスは前記インタフェースに関連付けられていると判定することに応じて、前記第２の高速障害通知メッセージを破棄するステップと、
をさらに含む、請求項１３に記載の方法。

【請求項15】

前記第１及び第２の高速障害通知メッセージは、高速フラッディングベースの高速収束のために予約される固有の宛先ＭＡＣアドレスの識別を通じて識別される、請求項１４に記載の方法。

【請求項16】

前記第１の高速障害通知メッセージは、プロトコル非依存なフォーマットを有する、請求項１３に記載の方法。

【請求項17】

前記第１の高速障害通知メッセージは、特定のＩＧＰルーティングプロトコルに固有のＩＧＰ ＰＤＵ（Interior Gateway Protocol Protocol Data Unit）パケットフォーマットを有する、請求項１３に記載の方法。

【請求項18】

ネットワーク障害から復旧するために高速フラッディングベースの高速収束に参加するためのルータであって、当該ルータは、
ルーティングテーブルを管理するように構成されるルーティングプロトコルモジュールを含むアプリケーション層と、
前記ルータを複数の他のルータに結合するための複数のインタフェース、
ＭＡＣアドレスとインタフェースとの関連付けを記憶するためのブリッジＭＡＣ（Media Access Control）テーブル、並びに、
ネットワーク障害を識別する情報を含む第１の高速障害通知メッセージを前記複数のインタフェースのうちの１つにおいて受信することに応答して、
前記第１の高速障害通知メッセージのソースＭＡＣ（Media Access Control）アドレスは当該第１の高速障害通知メッセージが受信された前記インタフェースに関連付けられていないという判定に応じて、前記ソースＭＡＣアドレス及びインタフェースを前記ブリッジＭＡＣテーブルに関連付け、前記複数のインタフェースのうちの１つ以上の他のインタフェースに前記第１の高速障害通知メッセージをフラッディングし、及び前記ネットワーク障害を反映するために前記ルーティングテーブルを更新すべく前記第１の高速障害通知メッセージを前記ルーティングプロトコルモジュールに送ること、
を実行するように構成される高速障害通知（ＦＦＮ）モジュール、
を含む、データトランスポート層と、
を備え、
前記ＦＦＮモジュールは、前記ルーティングプロトコルモジュールが前記ネットワーク障害を反映するための前記ルーティングテーブルの更新を完了することに先立って、前記複数のインタフェースのうちの前記１つ以上の他のインタフェースに前記第１の高速障害通知メッセージをフラッディングする、
ルータ。

【請求項19】

前記ＦＦＮモジュールは、ネットワーク障害を識別する情報を含む第２の高速障害通知メッセージを前記複数のインタフェースのうちの１つにおいて受信することに応答して、
前記第２の高速障害通知メッセージのソースＭＡＣアドレスは当該第２の高速障害通知メッセージが受信された前記インタフェースに関連付けられていると判定することに応じて、前記第２の高速障害通知メッセージを破棄すること、
を実行するようにさらに構成される、請求項１８に記載のルータ。

【請求項20】

前記第１及び第２の高速障害通知メッセージは、高速フラッディングベースの高速収束のために予約される固有の宛先ＭＡＣアドレスの識別を通じて識別される、請求項１９に記載のルータ。

【請求項21】

前記第１の高速障害通知メッセージは、プロトコル非依存なフォーマットを有する、請求項１８に記載のルータ。

【請求項22】

前記ルーティングプロトコルモジュールは、ＩＧＰ（Interior Gateway Protocol）モジュールであり、
前記第１の高速障害通知メッセージは、当該ＩＧＰモジュールに固有のＩＧＰ ＰＤＵ（Protocol Data Unit）パケットフォーマットを有する、請求項１８に記載のルータ。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願への相互参照
本願は、２０１１年２月２８日に出願された米国仮出願第６１／４４７，６６９号、２０１０年１０月２５日に出願された米国仮出願第６１／４０６，４２０号、及び２０１０年９月２９日に出願された米国仮出願第６１／３８７，５１１号の利益を主張し、これらの各々が参照によって本明細書に包含される。

【0002】

本発明の実施形態は、ネットワーキングの分野に関し、特に、ネットワーク障害からの高速収束に関する。

【背景技術】

【0003】

ネットワーク障害から迅速に復旧する能力は、最も求められるネットワーク特性のうちの１つである。この問題に満足の行くように対処する解決策は少ない。そのような解決策の１つは、ＲＦＣ（Request For Comments）５７１４において説明されるＩＰＦＲＲ（IP Fast Re-Route）である。ＩＰＦＲＲは、ＭＰＬＳ−ＦＲＲ（Multi-Protocol Label Switching-Fast Re-Route）がパスベース、又は言い換えればソースルーティングベースである点を除いて、ＭＰＬＳ−ＦＲＲの解決策を模倣する。これは、リルーティングの決定は、ネットワークにおける他のＬＳＲ（Label Switched Routers）の協力無しに、ＰＬＲ（point-of-local-repair）ルータ単独で実行されることができることを意味する。しかしながら、ＩＰベースのＦＲＲは、本来、ソースルーティングベースではない。結果として、そのリルーティングの決定は、ネットワークにおける他のルータによって尊重されず、これはトラフィックの故障又はルーティングループといった深刻な結果につながり得る。

【0004】

ＩＰＦＲＲコンセプトをめぐって幾つかの手法が提案されてきた。１つの手法は、ＲＦＣ５２８６において説明されるＬＦＡ（Loop Free Alternative）である。ＬＦＡアプローチは、大量の計算を必要とし、カバレッジの問題を有する。別の手法は、２０１０年１０月２１日のＩＥＴＦのドラフト“draft-ietf-rtgwg-ipfrr-notvia-address-06”において説明されるＮｏｔ−Ｖｉａである。Ｎｏｔ−Ｖｉａアプローチは、複雑であり、有用にするには高くつく。ＩＰＦＲＲコンセプトをめぐって提案された上記アプローチにおける困難さの主な理由は、ＲＦＣ５７１４のセクション１、第１段落の下記の一節から明らかである：「しかしながら、代替的なアプローチが存在し、当該アプローチは、他のルータに障害を通知する即時の必要性無しに障害を検出するルータによって障害がローカルに回復されることを可能にするバックアップルートを算出することである」。「他のルータに障害を通知する即時の必要性無しに」という句は、ドメインワイドな同期が重要であるＩＰネットワークの本質に反する。

【0005】

一般に、通常のリンク状態ルーティング動作において、ルータがリンク障害又は他のネットワーク途絶を検出すると、当該ルータは、その周囲の近隣ルータの全てに通知をフラッディングし、当該近隣ルータは、何らかの処理（例えば、ルーティングテーブル及び／又は転送テーブルの更新）の後、いずれのルータも更新され及び同期されるまで、さらに他のルータに情報を伝搬する。このフラッディングメカニズムは、遅く、完了までに比較的長い時間を要し、ネットワークの構造及びサイズに依存する。

【発明の概要】

【課題を解決するための手段】

【0006】

高速フラッディングベースの高速収束アーキテクチャが説明される。一実施形態において、高速障害通知メッセージのための伝達メカニズムは、ブリッジベース（bridged based）である。ブリッジベースの高速フラッディングベースの高速収束を開始するためのルータは、ネットワーク障害を検出し、当該障害に応じて、当該ルータの１つ以上のインタフェースのセットから高速障害通知メッセージをフラッディングする。高速障害通知メッセージは、ネットワーク障害を識別する情報を含み、そのソースＭＡＣ（Media Access Control）アドレスとして、検出されたネットワーク障害に結合され且つルータのインタフェースのセットの一部ではないインタフェースに割り当てられるＭＡＣアドレスを含む。ルータは、ネットワーク障害を反映するためにルーティングテーブルを更新する。高速障害通知メッセージの送信は、ネットワーク障害を反映するためのルーティングテーブルの更新の完了に先立って実行される。一実施形態において、高速障害通知メッセージは、受信側ルータに、そのルーティングテーブルを更新すべきかを判定する前に、そのデータトランスポート層において当該高速障害通知メッセージを１つ以上のそのインタフェースのセットからフラッディングすべきかを判定することを指示する。一実施形態において、ブリッジベースの高速フラッディングを開始するルータは、データトランスポート層と、アプリケーション層と、を含む。データトランスポート層は、検出されたネットワーク障害に応答してそのインタフェースのうちの１つ以上から高速障害通知メッセージをフラッディングするように構成される高速障害通知（ＦＦＮ）モジュールを含む。アプリケーション層は、検出されたネットワーク障害に応答してルーティングテーブルを更新するように構成されるルーティングプロトコルモジュールを含む。

【0007】

ブリッジベースの高速障害通知メッセージを受信するためのルータが説明される。高速障害通知メッセージをインタフェース上で受信することに応じて、及び高速障害通知メッセージのソースＭＡＣアドレスは当該インタフェースに関連付けられていないと判定することに応じて、ルータは、当該ソースＭＡＣアドレスとインタフェースとのペアを当該ルータのブリッジＭＡＣテーブルに追加し、１つ以上の他のルータへの伝送のために１つ以上の他のインタフェースに高速障害通知メッセージをフラッディングし、及びネットワーク障害を反映するためにルーティングテーブルを更新する。高速障害通知メッセージのフラッディングは、ネットワーク障害を反映するためにルーティングテーブルを更新するステップの完了に先立って実行される。一実施形態において、ブリッジベースの高速フラッディングについての受信側ルータは、データトランスポート層と、アプリケーション層と、を含む。アプリケーション層は、ルーティングテーブルを管理するように構成されるルーティングプロトコルモジュールを含む。データトランスポート層は、ＭＡＣアドレスとインタフェースとの関連付けを記憶するためのブリッジＭＡＣテーブルと、受信される高速障害通知メッセージに応答して及びそのソースＭＡＣアドレスは当該メッセージが受信されたインタフェースと関連付けられていないと判定することに応じて、当該ソースＭＡＣアドレスを当該インタフェースに関連付け、高速障害通知メッセージを１つ以上の他のインタフェースにフラッディングし、及びネットワーク障害を反映するためにルーティングテーブルを更新すべく高速障害通知メッセージをルーティングプロトコルモジュールに送るように構成されるＦＦＮモジュールと、を含む。ＦＦＮモジュールは、ルーティングプロトコルモジュールがそのルーティングテーブルの更新を完了することに先立って、高速障害通知メッセージをフラッディングする。

【0008】

一実施形態において、高速障害通知メッセージのための伝達メカニズムは、スパニングツリープロトコル（ＳＴＰ）を用いるレイヤ２のブリッジネットワークを介する。高速フラッディングベースの高速収束を開始するルータは、ネットワーク障害を検出し、当該障害に応じてレイヤ２の高速障害通知メッセージを１つ以上のインタフェースからフラッディングし、及びネットワーク障害を反映するためにそのルーティングテーブルを更新する。高速障害通知メッセージは、ネットワーク障害を識別する情報を含み、当該高速障害通知メッセージを受信するルータに、ネットワーク障害を反映するためにそのルーティングテーブルを更新することとは独立に、ＳＴＰによってブロックされないそのインタフェースから高速障害通知メッセージをフラッディングすることを指示する。一実施形態において、ルータは、データトランスポート層と、アプリケーション層と、を含む。データトランスポート層は、検出されたネットワーク障害に応答してそのインタフェースの１つ以上からレイヤ２の高速障害通知メッセージをフラッディングするように構成される高速障害通知（ＦＦＮ）モジュールを含む。アプリケーション層は、検出されたネットワーク障害に応答してルーティングテーブルを更新するように構成されるルーティングプロトコルモジュールを含む。

【0009】

レイヤ２のブリッジネットワークにおいて受信される高速障害通知メッセージを受信し及び応答するためのルータも説明される。ルータは、ネットワーク障害を識別する情報を含む高速障害通知メッセージを受信する。ルータは、ＳＴＰによってブロックされないそのインタフェースのうちの１つ以上から高速障害通知メッセージをフラッディングし、ネットワーク障害を反映するためにルーティングテーブルを更新する。ルータは、ネットワーク障害を反映するためのルーティングテーブルの更新の完了に先立って、高速障害通知メッセージをフラッディングする。一実施形態において、ルータは、データトランスポート層と、アプリケーション層と、を含む。アプリケーション層は、ルーティングテーブルを管理するように構成されるルーティングプロトコルモジュールを含む。データトランスポート層は、高速障害通知メッセージを受信することに応答して、ＳＴＰによってブロックされない１つ以上のインタフェースから当該メッセージをフラッディングし、ネットワーク障害を反映するためにルーティングテーブルを更新すべく当該メッセージをアプリケーション層上のルーティングプロトコルモジュールに送るように構成されるＦＦＮモジュールを含む。

【0010】

一実施形態において、高速障害通知メッセージのための伝達メカニズムは、ユニキャストベースである。ルータは、ネットワーク障害を検出し、当該障害に応じて、当該ネットワーク障害を識別する情報を含む高速障害通知メッセージを当該ルータと同じドメイン中に存在する他の各ルータに送信し、及び当該ネットワーク障害を反映するためにルーティングテーブルを更新する。高速障害通知メッセージは、ネットワーク障害を反映するためにルーティングテーブルを更新することとは独立に、それらのルータに送信される。一実施形態において、ルータは、データトランスポート層と、アプリケーション層と、を含む。アプリケーション層は、ルーティングテーブルを更新するように構成されるルーティングプロトコルモジュールを含む。データトランスポート層は、検出されたネットワーク障害に応答して当該ルータと同じドメイン中に存在する他の各ルータに高速障害通知メッセージを送信するように構成されるＦＦＮモジュールを含む。

【0011】

ユニキャストベースの高速障害通知メッセージを受信し及び応答するためのルータも説明される。一実施形態において、ルータは、ネットワーク障害を識別する情報を含むユニキャスト高速障害通知メッセージを受信し、高速障害通知メッセージについての隣接関係チェックを迂回し、及び当該ネットワーク障害を反映するためにルーティングテーブルを更新する。一実施形態において、ルータは、ユニキャスト高速障害通知メッセージを受信し及び当該高速障害通知メッセージについての隣接関係チェックを迂回するルーティングプロトコルモジュールに送り、高速障害通知メッセージにおけるネットワーク障害を反映するためにルーティングテーブルを更新するように構成されるインタフェースを含む。

【0012】

一実施形態において、高速障害通知メッセージのための伝達メカニズムは、マルチキャストベースである。ルータは、ネットワーク障害を検出し、当該障害に応じて、マルチキャストグループアドレスに高速障害通知メッセージを送信する。高速障害通知メッセージは、ネットワーク障害を識別する情報を含み、マルチキャストグループに加入しており且つ高速障害通知メッセージを受信することとなる複数のルータの各々に、当該ルータがそのルーティングテーブルを更新することとは独立に、そのインタフェースに高速障害通知メッセージをマルチキャストすべきかを判定することをさらに指示する。ルータは、ネットワーク障害を反映するためにそのルーティングテーブルも更新する。ルータは、ネットワーク障害を反映するためにルーティングテーブルを更新することとは独立に、高速障害通知メッセージを送信する。一実施形態において、ルータは、データトランスポート層と、アプリケーション層と、を含む。アプリケーション層は、検出されたネットワーク障害に応答してルーティングテーブルを更新するように構成されるルーティングプロトコルモジュールを含む。データトランスポート層は、検出されたネットワーク障害に応答してマルチキャストグループアドレスに高速障害通知メッセージを送信するように構成されるＦＦＮモジュールを含む。

【0013】

マルチキャストベースの高速障害通知メッセージを受信し及び応答するためのルータも説明される。一実施形態において、ルータは、高速障害通知メッセージを受信すると、ＲＰＦ（Reverse Path Forwarding）チェックを実行する。ルータは、マルチキャストグループに加入し、当該マルチキャストグループに関連付けられるアドレスを宛先とする高速障害通知メッセージを受信する。高速障害通知メッセージが受信されたインタフェースはルータによって当該高速障害通知メッセージのソースルータに到達するために用いられるインタフェースと同じであるという判定に応じて、ルータは、少なくとも１つの他のインタフェースに当該メッセージをマルチキャストする。ルータは、ネットワーク障害を反映するためにルーティングテーブルを更新する。ルータは、ルーティングテーブルの更新の完了に先立って、高速障害通知メッセージをマルチキャストする。一実施形態において、ルータは、データトランスポート層と、アプリケーション層と、を含む。データトランスポート層は、高速障害通知メッセージを受信することに応答して及び当該メッセージが受信されたインタフェースは当該メッセージのソースルータに到達するために用いられるインタフェースと同じであるという判定に応じて、そのインタフェースのうちの他のインタフェースに当該メッセージをマルチキャストし、ルーティングテーブルを更新するためにアプリケーション層上のルーティングプロトコルモジュールに当該メッセージを送るように構成されるＦＦＮモジュールを含む。

【0014】

一実施形態において、マルチキャストベースの高速障害通知メッセージを受信するルータは、当該高速障害通知メッセージをマルチキャストする際に、最短パス優先（ＳＰＦ：shortest path first）ツリー（ＳＰＴ）を用いる。ルータは、同じネットワーク中の複数のルータのうちの１つをＳＰＴのルートノードに選択し、現行のネットワークトポロジーを用いてＳＰＴを構築する。ルータは、マルチキャストグループに加入し、当該マルチキャストグループに関連付けられるアドレスを宛先とする高速障害通知メッセージを受信する。ルータは、ＳＰＴに従って高速障害通知メッセージをマルチキャストし、高速障害通知メッセージにおいて示されるネットワーク障害を反映するためにルーティングテーブルを更新する。ルータは、ルーティングテーブルを更新することの完了に先立って、ＳＰＴに従って高速障害通知メッセージをマルチキャストする。一実施形態において、ルータは、アプリケーション層と、データトランスポート層と、を含む。データトランスポート層は、ＳＰＴと、高速障害通知メッセージの受信に応答して、当該メッセージをＳＰＴに従ってマルチキャストし、ネットワーク障害を反映するルーティングテーブルを更新すべく当該メッセージをアプリケーション層上のルーティングプロトコルモジュールに送るように構成されるＦＦＮモジュールと、を含む。

【0015】

一実施形態において、マルチキャストベースの高速障害通知メッセージを受信するルータは、ＰＩＭ（Protocol Independent Multicast）プロトコルの実装を用いて構築される双方向マルチキャストツリーを用いる。ルータは、ＰＩＭを用いて双方向ツリーを構築し、マルチキャストグループに加入する。ルータは、当該マルチキャストグループに関連付けられるアドレスを宛先とし且つネットワーク障害を識別する情報を含む高速障害通知メッセージを受信し、当該メッセージを双方向マルチキャストツリーに従ってマルチキャストし、及びネットワーク障害を反映するためにルーティングテーブルを更新する。ルータは、ルーティングテーブルの更新の完了に先立って、高速障害通知メッセージを双方向マルチキャストツリーに従ってマルチキャストする。一実施形態において、ルータは、アプリケーション層と、データトランスポート層と、を含む。データトランスポート層は、ＰＩＭを用いて構築される双方向マルチキャストツリーと、高速障害通知メッセージを受信することに応答して、当該メッセージを双方向マルチキャストツリーに従ってマルチキャストし、ルーティングテーブルを更新するために高速障害通知メッセージをアプリケーション層上のルーティングプロトコルモジュールに送るように構成されるＦＦＮモジュールと、を含む。

【図面の簡単な説明】

【0016】

本発明は、下記の説明及び本発明の実施形態を図示するために用いられる添付の図面を参照することによって、最もよく理解され得る。図面において：

【0017】

【図1】一実施形態に係る、ネットワークにおけるルータ上で具現化される高速フラッディングベースの高速収束（ＦＦＦＣ）アーキテクチャを図示する。

【図2】一実施形態に係るＦＦＦＣアーキテクチャを用いる高速障害通知アプリケーションを用いる例示的なネットワークを図示する。

【図3】一実施形態に係る、ネットワーク障害を検出してドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示するフロー図である。

【図4】一実施形態に係る、高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図5】一実施形態に係る、高速障害通知を拡散するためのブリッジベースのフラッディングを用いる例示的なネットワークを図示する。

【図6】一実施形態に係る、ネットワーク障害を検出して、ブリッジベースの高速障害通知メッセージフラッディングを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示するフロー図である。

【図7】一実施形態に係る、ブリッジベースの高速障害通知メッセージフラッディングを用いるＦＦＦＣアーキテクチャにおいて高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図8】一実施形態に係る、ネットワーク障害を検出して、ＳＴＰベースのフラッディングを用いてドメインワイドなＦＦＦＣを開始するレイヤ２のブリッジネットワークにおけるルータ上で実行される例示的な動作を図示するフロー図である。

【図9】一実施形態に係る、レイヤ２の高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図10】一実施形態に係る、ユニキャストベースの高速障害通知メッセージフラッディングを用いる例示的なネットワークを図示する。

【図11】一実施形態に係る、ネットワーク障害を検出し、ユニキャストベースの高速障害通知メッセージフラッディングを用いるルータによって実行される例示的な動作を図示するフロー図である。

【図12】一実施形態に係る、ユニキャストベースの伝送技法を用いて伝送される高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図13】一実施形態に係る、ゲーテッドマルチキャスト高速障害通知メッセージフラッディングを用いる例示的なネットワークを図示する。

【図14】一実施形態に係る、ネットワーク障害を検出して、ゲーテッドマルチキャストベースの高速障害通知メッセージフラッディングを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示するフロー図である。

【図15】一実施形態に係る、ゲーテッドマルチキャスト高速障害通知メッセージフラッディングアプリケーションにおいて、マルチキャスト高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図16】一実施形態に係る、ルータにおいて実行されるＳＰＦ（Shortest Path First）算出に基づいてＳＰＴ（Shortest Path Tree）を構築するための例示的な動作を図示する。

【図17】一実施形態に係る、ネットワーク障害を検出して、ＳＰＦ選択ルートノード算出に基づくＳＰＴを用いてマルチキャストベースの高速障害通知メッセージを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示する。

【図18】一実施形態に係る、ＳＰＴ選択ルートノードベースのＦＦＦＣアプリケーションにおいてマルチキャスト高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図19】一実施形態に係る、ネットワーク障害を検出して、ＰＩＭプロトコルを用いて構築される双方向マルチキャストツリーを用いてマルチキャスト高速障害通知メッセージを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示する。

【図20】一実施形態に係る、ＰＩＭプロトコルを用いて構築される双方向マルチキャストツリーを用いるＦＦＦＣアプリケーションにおいてマルチキャスト高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。

【図21】一実施形態に係る、高速障害通知メッセージについての例示的なフォーマットを図示する。

【発明を実施するための形態】

【0018】

下記の説明において、多くの具体的な詳細が述べられる。しかしながら、本発明の実施形態はこれらの具体的な詳細無しに実施をされ得ることが理解される。他の例において、周知の回路、構造及び技法は、本説明の理解を曖昧にしないために、詳細には示されていない。当業者であれば、本明細書に含められる説明によって、必要以上の実験無しに適当な機能性を実装することが可能であろう。

【0019】

本明細書における「一実施形態」、「ある実施形態」、「例示的な実施形態」等への言及は、説明される実施形態が特定の機能、構造、又は特性を含み得るが、全ての実施形態が必ずしも当該特定の機能、構造、又は特性を含まなくてもよいことを示す。また、そのような表現は、必ずしも同じ実施形態に言及しない。さらに、特定の機能、構造、又は特性がある実施形態に関連して説明される場合、明示的に説明されていてもいなくても、そのような機能、構造、又は特性を他の実施形態に関連して達成することは当業者の知識の範囲内であることが提示される。

【0020】

下記の説明及び特許請求の範囲においては、「結合される（coupled）」及び「接続される（connected）」という用語がこれらの派生語と共に用いられ得る。これらの用語は互いに同義語として意図されないことが理解されるべきである。「結合される」は、互いに直接物理的に又は電気的に接触してもしなくてもよい２つ以上のエレメントが互いに協働し又はインタラクションすることを示すために用いられる。「接続される」は、互いに結合される２つ以上のエレメント間における通信の確立を示すために用いられる。

【0021】

高速フラッディングベースの高速収束（ＦＦＦＣ：fast flooding based fast convergence）アーキテクチャが説明される。ＦＦＦＣアーキテクチャは、ネットワーク障害が起きた場合（例えば、リンク又は機器の障害時）にはネットワークダウンタイムを最小限にする。本発明の一実施形態において、ＦＦＦＣアーキテクチャは、ネットワークにおける対象の受信機全てへのイベントの迅速な拡散のために、イベントフレームワークを用いる。イベントフレームワークは、基礎となる伝達メカニズムから独立している。従って、様々な要件に適した様々な特性を有する様々な伝達メカニズムが用いられ得る。例えば、単純さについて最適化される何らかの伝達メカニズムが用いられ得る一方で、信頼性を改善する他の伝達メカニズムも用いられ得る。

【0022】

イベントフレームワークは、複数の異なるアプリケーションがイベントを生成し及び／又はイベントを受信するように登録することができるという点において、アプリケーション非依存（independent）である。一実施形態において、ＴＬＶ（type-length-value）ベースのイベントフレームワークがアプリケーションと伝達メカニズムとの間を確かなものにするために用いられる。イベントフレームワークを用いるアプリケーションの一例は、高速障害通知（Fast Failure Notification）である。高速障害通知は、ネットワーク収束時間を改善するために用いられる。例えば、ネットワークにおいて障害が発生する場合、障害に隣接するルータは、当該障害を検出し、領域の全体にわたる他のルータに障害通知を素早く拡散させることができる。異なるルータ上のルーティングプロトコル（例えば、ＯＳＰＦ（Open Shortest Path First）及びＩＳ−ＩＳ（Intermediate System to Intermediate System）といったリンク状態ＩＧＰ（Interior Gateway Protocol）ルーティングプロトコル）は、そのような障害通知を登録し及び受信し、障害に素早く反応して高速な収束を達成することができる。高速障害通知におけるイベントは、リンクダウンイベント又はノードダウンイベントである。アップイベント（例えば、リンクアップ又はノードアップ）は、ネットワーク安定性の同じものについてフラッディングされない。

【0023】

図１は、一実施形態に係る、ネットワークにおけるルータ上で具現化される高速フラッディングベースの高速収束（ＦＦＦＣ）アーキテクチャを図示する。例示的なＦＦＦＣアーキテクチャは、種々のルーティング機能がルータの各々上に配置される層状構造である。図１に図示されるように、ＦＦＦＣアーキテクチャは、アプリケーション層１０５と、データトランスポート層１０７と、を含む。アプリケーション層１０５は、ルーティングプロトコル固有の機能性を含み、典型的には、それぞれのルータの制御プレーンの一部である。データトランスポート層１０７は、本明細書において説明される高速フラッディングメカニズムのための機能性を含み（例えば、ネットワークにおける対象の受信機全てへのネットワークイベントの迅速な拡散に関与する）、典型的には、それぞれのルータのデータプレーンの一部である。具体的には、アプリケーション層１０５は、ルータ１２０Ａ〜Ｎ上にそれぞれルーティングプロトコルモジュール１１０Ａ〜Ｎを含み、データトランスポート層１０７は、ルータ１２０Ａ〜Ｎ上にそれぞれ高速フラッディングモジュール１１５Ａ〜Ｎを含む。

【0024】

ルーティングプロトコルモジュール１１０Ａ〜Ｎは、それぞれ高速フラッディングモジュール１１５Ａ〜Ｎからイベントを受信するように登録されている。一実施形態において、高速フラッディングモジュールは、ルータ１２０がネットワークにおける他のルータ１２０にネットワーク障害通知を拡散させることを可能にし、当該他のルータは、対応するルーティングプロトコルモジュール１１０にさらなる処理（例えば、ルーティングテーブル及び／又は転送テーブルの更新）のために転送することができる。従って、高速フラッディングメカニズムは、アプリケーション層１０５から切り離され、データトランスポート層１０７上に移行される。

【0025】

蓄積転送（store-and-forward）方式においてフラッディングを実行する、ネットワーク障害から復旧するための通例のルーティングプロトコル処理は、信頼でき（例えば、再送信を含む）及び安全である（例えば、隣接関係チェックを含む）が、当該処理は、制御プレーン動作及び制御プレーン／データプレーン間通信に関与し、これはネットワークワイドな収束を減速させる。しかしながら、本明細書において説明されるＦＦＦＣアーキテクチャは、ネットワーク障害通知のフラッディングをアプリケーション層１０５から切り離し、データトランスポート層１０７上に移行させる。従って、データトランスポート層１０７は、データトラフィック速度でルーティング制御メッセージを伝達することができるドメインワイドな高速フラッディングプラットフォームを提供し、それにより、ルーティングドメイン全体は、ドメインワイドの高速な収束を実現することができる。一実施形態において、通常のフラッディング機能は、意図されたルータに高速フラッディング通知が到達しない場合に備えて、最終的な（ultimate）同期を確保するために、依然としてアプリケーション層に含まれる。通常のフラッディング機能は、障害通知メッセージが送信される前に、ルーティングテーブル及び転送テーブルが更新されることを必要とする。

【0026】

図２は、一実施形態に係る、ＦＦＦＣアーキテクチャを用いる高速障害通知アプリケーションを用いる例示的なネットワークを図示する。当該例示的なネットワークは、ルータ２２０Ａ〜Ｎを含み、リング型トポロジーを形成する。ルータ２２０Ａとルータ２２０Ｂとは、リンク２５２によって結合される。ルータ２２０Ｂとルータ２２０Ｃとは、リンク２５４によって結合される。ルータ２２０Ｃとルータ２２０Ｎとは、リンク２５６によって結合される（ルータ２２０Ｃとルータ２２０Ｎとの間にはゼロ個以上のルータが存在し得る）。ルータ２２０Ｎとルータ２２０Ａとは、リンク２５０によって結合される。ルータ２２０Ａ〜Ｎは、それぞれＩＧＰモジュール２１０Ａ〜Ｎと、高速障害通知（ＦＦＮ：Fast Failure Notification）モジュール２１５Ａ〜Ｎと、を含む。ＩＧＰモジュール２１０Ａ〜Ｎは、それぞれルータ２２０Ａ〜Ｎのアプリケーション層の一部であり、ＦＦＮモジュール２１５Ａ〜Ｎは、それぞれルータ２２０Ａ〜Ｎのデータトランスポート層の一部である。

【0027】

図２に図示される例において、ルータ２２０Ｃは、ルータ２２０Ａを宛先とするパケットのソースである。通常の動作期間中、パケットは、ルータ２２０Ｃからルータ２２０Ｂを介して宛先ルータ２２０Ａに到達するパスを選択する。図２に図示されるように、ネットワークは、ネットワーク障害を経験しており、具体的には、リンク２５２が障害を起こしている。結果として、ルータ２２０Ｂは、ルータ２２０Ａにリンク２５２上でパケットを転送することができない。従って、ルータ２２０Ｃからのパケットは、ルータ２２０Ｂを介して宛先ルータ２２０Ａに到達しないであろう。しかしながら、ルータ２２０Ｃからのパケットは、ルータＮを介して宛先ルータ２２０Ａに到達することができる。

【0028】

説明の目的のため、ルータ２２０Ｂは、リンク２５２の障害を検出する。ただし、ルータ２２０Ａも障害を検出し得ることが理解されるべきである。障害の検出は、異なる実施形態においては異なる手法で実行され得る。一実施形態において、レイヤ２のリンクのイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ：Bidirectional Forwarding Detection）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクのイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。リンク２５２の障害の検出は、イベントフレームワークにおけるイベントである。従って、ＩＧＰモジュール２１０Ｂにリンク２５２の障害を通知するメッセージが、ＩＧＰモジュール２１０Ｂに送られ、ＩＧＰモジュール２１０Ｂは、ルータ２２０Ｂのルーティングテーブル及び転送テーブルを更新して、リンク２５２の障害を反映することができる。

【0029】

ルータ２２０Ｂは障害を検出するため、一実施形態において、ルータ２２０Ｂは、ＦＦＦＣ処理を開始し、高速障害通知メッセージフラッディングのための始点となる。従って、障害を検出した後のあるときに、ルータＢは、リンク２５２上の障害を示す高速障害通知メッセージを発信する。高速障害通知メッセージは、当該タイプのメッセージを受信するように登録した他のルータに障害を通知するために用いられる。例えば、高速障害通知メッセージは、リンク２５２上に障害が存在することを示す。また、高速障害通知メッセージは、受信側ルータに、収束を待たずに高速障害通知メッセージをその次のホップに転送することを含む高速フラッディング処理が実行されるべきであることも示す。例えば、高速障害通知メッセージは、そのようなルータによって、それらのアプリケーション層からのインタラクション無しに転送されるべきである。図２について、ルータ２２０Ａ〜Ｎの各々は、高速障害通知メッセージを受信するように登録している。

【0030】

一実施形態において、高速障害通知メッセージは、既存のＩＧＰ ＰＤＵ（Protocol Data Unit）パケットフォーマットを用いる。例えば、ＩＧＰがＯＳＰＦである場合、崩壊した隣接関係（ルータが少ないあるリンク）を反映するＯＳＰＦルータのＬＳＡ（link state advertisement）は、高速障害通知メッセージとして用いられ、特別な変形無しにルータに高速フラッディングされることができる。これは、受信機、例えばルータ２２０Ａ及び２２０Ｃ〜Ｎが、それらの通常の手法でパケットを処理することを可能にする。また、パケットは通常のフラッディングにおいて用いられるものと異ならないため、通常のフラッディングが本明細書において説明される高速フラッディングに追い付く場合、推移がシームレスであることを保証する。また、通常のパケットを用いることは、高速収束と低速収束との間で冗長な取り組み（effort）が存在しないであろうことを意味する。換言すれば、ルータが更新される（例えば、高速障害通知メッセージを既に高速フラッディングした）場合には常にフラッディングは停止する。しかしながら、高速障害通知メッセージについて既存のＩＧＰ ＰＤＵパケットフォーマットを用いることは、当該メッセージを複数のプロトコルについて均一にできないことを意味する。例えば、ＯＳＰＦについての既存のＩＧＰ ＰＤＵパケットフォーマットは、ＩＳ−ＩＳのそれとは異なる。従って、ＩＳ−ＩＳについては、ＯＳＰＦについてのものとは異なるフォーマットが用いられなければならない。また、ＩＳ−ＩＳ ＰＤＵはＩＰベースではないため、場合によってはカプセル化を必要とし得る。さらに、欠点の１つは、信頼できない相手からのＤｏＳ（Denial of Service）攻撃又はＰＤＵリプレイを回避するために、通常のＩＧＰフラッディングメカニズムが隣接関係チェックを用いることである。高速障害通知メッセージが受け取られるようにするためには、この隣接関係チェックが迂回される必要があり、これはＤｏＳ攻撃又はＰＤＵリプレイ攻撃に機会を与えてしまう。しかしながら、これらのタイプの攻撃を防ぐために、ドメインワイドな認証が用いられる。

【0031】

別の実施形態において、高速障害通知メッセージは、プロトコルに関わらず共通のメッセージフォーマットを用いる。このフォーマットは、障害を起こしたリンクに関する充分な情報を考慮し、本明細書において説明されるイベントフレームワークにおけるローカルなイベントとして受信側ルータ上で扱われる。一実施形態において、均一なフォーマットは、ＴＬＶベースである。一実施形態において、共通のメッセージフォーマットを用いる高速障害通知メッセージがバグ又は他のエラー状態に起因して誤ってフラッディングされる場合を防ぐために、タイムアウト機構（machinery）が用いられる。本明細書において後により詳細に説明されるであろう図２１は、ＩＧＰプロトコルに依存せず、データトランスポート層によって発されたレイヤ２のプロトコルパケットである例示的なメッセージフォーマットを図示する。

【0032】

一実施形態において、高速障害通知メッセージは、当該メッセージが本明細書において説明されるＦＦＦＣアーキテクチャについてのものであることを受信側ルータに示す固有の宛先ＩＰアドレス又はＭＡＣアドレスを含む。

【0033】

高速障害通知メッセージを発信した後、検出側ルータ２２０Ｂは、高速障害通知メッセージをフラッディングする。図２に示されるように、ルータ２２０Ｂは、高速障害通知メッセージ２６０をリンク２５４上でルータ２２０Ｃにフラッディングする。これは、ＦＦＮモジュール２１５ＢからＦＦＮモジュール２１５Ｃに送られるものとして概念的に図示される。高速フラッディングを実行するための任意の数のメカニズムが用いられ得る。一実施形態において、用いられるフラッディングメカニズムは、信頼でき（障害が発生した後でも全ての参加者に到達し）、ループフリーで、単純で、認証されることができる。

【0034】

一実施形態において、ルータ２２０Ｂは、リンク２５２の障害を（当該障害が収束する前に）反映するためにルータ２２０Ｂがそのルーティングテーブル及び転送テーブルの更新を完了する前に、高速障害通知メッセージを生成し及び送信する。従って、ルータ２２０Ｂは、ルーティングテーブル及び転送テーブルを更新することとは独立に、高速障害通知メッセージを生成し及び送信する。

【0035】

受信側ルータ２２０Ｃは、高速障害通知メッセージ２６０を受信する。当該通知メッセージ２６０は、本明細書において説明されるイベントフレームワークにおけるイベントであり、ＩＧＰモジュール２１０Ｃは、当該イベントについてのメッセージを受信するように登録されている。一実施形態において、高速障害通知メッセージ２６０は、当該メッセージが固有の宛先ＩＰアドレス又はＭＡＣアドレスを有することに基づいて、ＦＦＦＣアーキテクチャについてのメッセージとして識別される。従って、当該メッセージを受信した後、リンク２５２の障害を示す高速障害通知メッセージ２７２をそのＩＧＰモジュール２１０Ｃに転送し、それにより、当該ＩＧＰモジュール２１０Ｃは、障害に反応し及び収束処理を開始することができる。一実施形態において、ＩＧＰモジュール２１０Ｃは、隣接関係チェックを控えること（foregoing）によってメッセージの受け取り基準を緩和する。高速障害通知メッセージ２７２を受信した後、ＩＧＰモジュールは、リンク２５２の障害を反映するために適当にルーティングテーブル及び転送テーブルを更新することを含めて当該メッセージを処理する。一実施形態において、収束時間を改善するために、変更はデータプレーンに（例えば、転送テーブルに）予めダウンロードされる。

【0036】

高速障害通知メッセージ２７２をＩＧＰモジュール２１０Ｃに転送することに加えて、ＦＦＮモジュール２１５Ｃは、高速障害通知メッセージのコピーをフラッディングする。例示の目的のため、ＦＦＮモジュール２１５Ｃは、高速障害通知メッセージ２６２をリンク２５６上でルータ２２０Ｎにフラッディングする。高速障害通知メッセージ２６２は、高速障害通知メッセージ２７２の前に又は同時に送られることができる。従って、一実施形態によれば、高速障害通知メッセージ２６２はＩＧＰモジュール２１０Ｃと如何なるインタラクションも無く次のルータにフラッディングされ、これは収束時間を低減する。

【0037】

高速障害通知メッセージ２６２を受信することに応答してルータ２２０Ｎによって実行される処理は、高速障害通知メッセージ２６０を受信することに応答してルータ２２０Ｃによって実行される処理と同様である。高速障害通知メッセージ２６２は、ＩＧＰモジュール２１０Ｎが登録しているフレームワークにおけるイベントである。従って、ＦＦＮモジュール２１５Ｎは、ＩＧＰモジュール２１０Ｎに、リンク２５２の障害を示す高速障害通知メッセージ２７４を送る。ＩＧＰモジュール２１０Ｎは、リンク２５２の障害を反映するためにルーティングテーブル及び転送テーブルを適当に更新する。ＦＦＮモジュール２１５Ｎは、リンク２５０上でルータ２２０Ａに高速障害通知メッセージ２６４もフラッディングする。高速障害通知メッセージ２６４は、高速障害通知メッセージ２７４の転送の前に又は同時に転送されることができる。高速障害通知メッセージ２６４を受信することに応じて、高速フラッディングメカニズム２１５Ａは、高速障害通知メッセージ２７６をＩＧＰモジュール２１０Ａに転送し、それにより、ＩＧＰモジュール２１０Ａは、当該通知及びリンク２５２の障害に反応することができる。

【0038】

一実施形態において、高速障害通知メッセージ２６０、２６２、及び２６４は、データトランスポート層において処理されるため、データトラフィックと同じ速度で送信される。特定の例として、ルータ２２０Ｃからルータ２２０Ｎへリンク２５６上で送られる高速障害通知メッセージ２６２は、ルータ２２０Ｃからルータ２２０Ｎへリンク２５６上で送られるデータトラフィックと同じ速度で伝わる。高速障害通知メッセージ２６０、２６２、２６４はデータトラフィックと同じ速度で伝わるため、同じ計算能力とすれば、ネクストホップのルータは、当該通知メッセージの処理について先行するルータと同じ時間を有する。例えば、ルータ２２０Ｃ及び２２０Ｎが同じ計算能力を有するとすれば、ルータ２２０Ｃが通知メッセージ２６０を処理するために有する時間と同じ時間をルータ２２０Ｎは通知メッセージ２６２を処理するために有する。

【0039】

ルータ２２０Ａ〜Ｎは同時に収束しないことが理解されるべきである。これは、高速障害通知メッセージの伝搬遅延に起因する。例えば、ルータ２２０Ｃがリンク２５２の障害を示す高速障害通知メッセージを受信するのは、ルータ２２０Ｎが同様のメッセージを受信するよりも前になるであろう。しかしながら、本明細書において説明されるＦＦＦＣアーキテクチャを用いれば、最初のルータが回復した後、トラフィックロスは直ちに無くなる。これは、データトラフィックが高速障害通知メッセージと同じ伝搬遅延を経験し、これは遠隔のルータにおける収束の遅い開始を補償するためである。

【0040】

例として、ルータ２２０Ａ〜Ｎの各々が、５０ミリ秒の収束時間、及び各ホップについて２０ミリ秒の送信遅延を有すると仮定する。収束時間は、ロスしたパケットの数をドメイン中の任意の２つのルータ間のトラフィックフローレートで除算することによって測定される。これは、全ての個々のルータが同じ計算能力及び同じ収束時間を有する場合、ドメインワイドなネットワーク収束時間と等しくなるべきである。例えば、リンク２５２の障害時に、ルータ２２０Ｂは、ルータ２２０Ｃに高速転送通知メッセージ２６０（例えば、リンク状態更新）を送り、その収束を開始する。下記の表１は、収束タイムラインを示す。

【0041】

【表1】

【0042】

ルータ２２０Ｂは、リンク２５２の障害の後、時刻０においてその収束を開始する。また、ルータ２２０Ｂは、同時に、高速転送通知メッセージ２６０をルータ２２０Ｃに送る。最初の５０ミリ秒の期間中、（リンク２５２の障害に起因して）ルータ２２０Ｂからルータ２２０Ａへのリンク２５２上のパケットは破棄される（dropped）。高速転送通知メッセージ２６０は、２０ミリ秒後にルータ２２０Ｃに到達し、その時点で、ルータ２２０Ｃはその収束を開始する。従って、ルータ２２０Ｂがその収束を終了する前に、ルータ２２０Ｃはその収束を開始する。ルータ２２０Ｃも、ネクストホップのルータ（例えば、ルータ２２０Ｎ）に高速障害通知メッセージ２６２を送る。実質的に５０ミリ秒経ち且つルータ２２０Ｂが収束した後、ルータ２２０Ｂは、ルータ２２０Ａを宛先とするパケットを、ルータ２２０Ｃに向けてリルーティングする。このようなパケットは、ルータ２２０Ｃに到達するまでに２０ミリ秒を要し、従って、リンク２５２の障害の７０ミリ秒後に到達するであろう。ルータ２２０Ｃは、高速転送通知メッセージ２６０を受信して５０ミリ秒後に収束し、これはリンク２５２の障害の７０ミリ秒後である。従って、データトラフィックパケットは、ルータ２２０Ｃが収束するのとおよそ同じ時刻に到達するであろう。この処理はドメインワイドに継続する。ルータ２２０Ｃ及びそれ以外の全ての下流のルータは、データパケットが到達することとなる前に１つずつ収束するため、データパケットは修正後のパスを介して成功裏に宛先（ルータ２２０Ａ）に到達する。

【0043】

ルータ２２０Ａ〜Ｎが異なる収束時間を有する場合、パケットは１つ以上のループの後にやはり伝達されるであろうが、マイクロルーピングが形成されるかも知れない。例えば、同じリンク障害のシナリオである（リンク２５２が障害を起こす）が、ルータ２２０Ｃが収束するために９０ミリ秒を必要とする一方、それ以外のルータは５０ミリ秒で収束すると仮定する。ルータ２２０Ｂが、リンク２５２の障害の７０ミリ秒後にパケットをルータ２２０Ｃへリルーティングする場合、ルータ２２０Ｃはその更新をまだ完了していないであろう。従って、ルータ２２０Ｃは、依然としてその古い転送テーブルを用い続けており、ルータ２２０Ａを宛先とするパケットをルータ２２０Ｂに送信し得る。これは、それらのパケットをルータ２２０Ｃに再度リルーティングすることになる。これらのパケットがルータ２２０Ｃに到達することになる時間は、障害の１１０ミリ秒後であり、ルータ２２０Ｃは更新を終了し当該パケットを正確に転送するであろう。この例において、パケットは１回ループされるが、状況によっては複数回のループが存在し得ることが理解されるべきである。パケットは、異なる収束タイムラインに起因して並び替えられ、パケットは一時的に間違った方向へ転送され得る。パケットの並び替えは、新たなシーケンス番号を付されたパケットがより古いものよりも先に到達し得るという点でＴＣＰ通信に悪影響を及ぼす。

【0044】

本明細書において説明されるＦＦＦＣアーキテクチャは、ルータの全てが収束することとは対照的に、影響を受けるルータが収束するとすぐにデータトラフィックがリルーティングされることを可能にする。また、影響を受けるルータが収束すると、本明細書において説明されるＦＦＦＣアーキテクチャは、影響を受ける全てのトラフィックについて正確なルートを保証する。本明細書において説明されるＦＦＦＣアーキテクチャは、如何なるサイズ及び如何なるトポロジーのネットワークに対してもスケーリング性を有し、少なくとも通常のＩＧＰフラッディングには劣らない。

【0045】

図３は、一実施形態に係る、ネットワーク障害を検出してドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示するフロー図である。動作３１０において、ルータは、ネットワーク障害を検出する。一実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作３１５に移る。

【0046】

動作３１５において、ルータは、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。また、高速障害通知メッセージは、収束を待たずに（ルーティングテーブル及び転送テーブルが更新されることを待たずに）受信側ルータのネクストホップに高速障害通知メッセージを転送することを含めて高速フラッディング処理が実行されるべきであることも受信側ルータに示す。例えば、高速障害通知メッセージは、それらのルータによってそれらのアプリケーション層からのインタラクション無しに転送されるべきである。一実施形態において、高速障害通知メッセージは、ＦＦＦＣ専用である固有の宛先ＩＰアドレス又はＭＡＣアドレスを含む。従って、高速障害通知メッセージは、受信側ルータがそのルーティングテーブル及び転送テーブルを更新してネットワーク障害を反映することを可能にし、当該ルーティングテーブル及び転送テーブルの双方を更新することとは独立して高速障害通知がそれらのネクストホップのルータに転送されるべきであるという情報を含む。

【0047】

上述の通り、高速障害通知メッセージは、既存のＩＧＰ ＰＤＵパケットフォーマットを用いても、又はプロトコルに関わらず共通のメッセージフォーマットを用いてもよい。フローは次いで動作３２０に移り、ルータは高速障害通知メッセージを１つ以上のルータにフラッディングする。フローは次いで動作３２５に移り、ルータは、ネットワーク障害を反映するために、そのルーティングテーブル及び転送テーブルを更新する。ルータがそのルーティングテーブル及び転送テーブルを更新した後、データパケットはネットワーク障害を回避するためにリルーティングされるであろう。

【0048】

動作３２５は、幾つかの実施形態において、動作３１５及び／又は３２０と同時に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージが生成され及び送信される後まで完了されないことが理解されるべきである。ルータは、高速障害通知メッセージを生成し及び送信する前に、ルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0049】

図４は、一実施形態に係る、高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作４１０において、ルータは、ネットワーク障害に関する情報を含む高速障害通知メッセージを受信する。高速障害通知メッセージは、当該メッセージがＦＦＦＣアーキテクチャにおいて扱われるべきであることも示す。例えば、高速障害通知メッセージは、本明細書において説明されるＦＦＦＣ専用である固有の宛先ＩＰアドレス又はＭＡＣアドレスを含み得る。フローは次いで動作４１５に移る。

【0050】

動作４１５において、高速フラッディングメッセージは、さらなる処理のためにルータ上の適当なルーティングプロトコルモジュール（例えば、ルータ上のＩＧＰモジュール）に送られる。ルータがネクストホップのルータを含む場合、フローは動作４２０に移り、高速障害通知メッセージがネクストホップのルータにフラッディングされる。これは高速障害通知メッセージであるため、ルータは高速障害通知メッセージをそのネクストホップのルータにフラッディングする前にそのルーティングテーブル及び転送テーブルを更新するまで待たないことが理解されるべきである。フローは次いで動作４２５に移り、ルータは、ネットワーク障害を反映するために、そのルーティングテーブル及び転送テーブルを更新する。ルータがそのルーティングテーブル及び転送テーブルを更新した後、データパケットは、ネットワーク障害を回避するためにリルーティングされるであろう。

【0051】

動作４２５は、幾つかの実施形態において、動作４２０と同時に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージがフラッディングされた後まで完了されないことが理解されるべきである。ルータは、高速障害通知メッセージをフラッディングする前にルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。従って、受信された高速障害通知メッセージをそのネクストホップのルータにフラッディングすることは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0052】

ブリッジベースの高速障害通知メッセージフラッディング
一実施形態において、高速障害通知メッセージフラッディングのための伝達メカニズムは、ブリッジベース（bridged based）である。高速障害通知メッセージのためのブリッジベースの伝達メカニズムは、ツリーベースの伝達メカニズムのように、リンク破損に起因するツリーの区分化（tree partition）の影響を受けることがない。全てのツリーベースの高速フラッディングスキームは、ルータが障害を起こす場合又は複数のリンクが同時に障害を起こす（例えば、ラインカード障害）場合に、フラッディングが区分化されてしまい、それ故にトポロジーの異なる部分におけるルータがトポロジー変化について異なる認知を有しかねないという限界がある。結果として、ルーティングループ及び／又はブラックホールを形成し得る。本明細書において説明されるブリッジベースの伝達メカニズムは、フラッディングが区分化されることに影響を受けない。

【0053】

図５は、一実施形態に係る、高速障害通知を拡散させるためのブリッジベースのフラッディングを用いる例示的なネットワーク５００を図示する。ネットワーク５００は、ルータ５２０Ａ〜Ｄを含み、これらは全て、エリア中の全てのノード及びリンクを含むブリッジネットワークの一部である。ルータ５２０Ａ〜Ｄは、それぞれブリッジバーチャルインタフェース（ＢＶＩ）５１５Ａ〜Ｄと、ＩＧＰモジュール５１０Ａ〜Ｄと、を含む。ＢＶＩ５１５Ａ〜Ｄは、それぞれ本明細書において説明される高速障害通知を発信し及び受信するように構成され、ルータ５２０Ａ〜Ｄのデータトランスポート層の一部である。ＢＶＩ５１５Ａ〜Ｄは、高速障害通知（ＦＦＮ）モジュールの一タイプである。

【0054】

ＩＧＰモジュール５１０Ａ〜Ｄは、それぞれルータ５２０Ａ〜Ｄのアプリケーション層の一部である。ルータ５２０Ａは、インタフェースＡｂ５７０を含む。ルータ５２０Ｂは、インタフェースＢａ５７２、Ｂｃ５７４、Ｂｄ５７６を含む。ルータ５２０Ｃは、インタフェースＣｂ５７８及びＣｄ５８０を含む。ルータ５２０Ｄは、インタフェースＤｂ５８２及びＤｃ５８４を含む。インタフェースＡｂ５７０とインタフェースＢａ５７２とは、リンク５５２によって結合される。インタフェースＢｃ５７４とインタフェースＣｂ５７８とは、リンク５５４によって結合される。インタフェースＣｄ５８０とインタフェースＤｃ５８４とは、リンク５５６によって結合される。インタフェースＢｄ５７６とインタフェースＤｂ５８２とは、リンク５５０によって結合される。

【0055】

図５に図示されるように、ルータはリング型トポロジーを形成する。従って、ネットワークにおいてルーピングが発生する可能性がある。ＭＡＣムーブ検出は、ブリッジネットワークにおいてループを防ぐための周知の手法である。ただし、制御プレーンがその決定をルータの異なるラインカード上の全てのインタフェースに設定する（populate）ための時間（例えば、数ミリ秒）は、ネットワークを麻痺させることがある。本発明の一実施形態においては、一回学習（learning-once）フラッディングスキームが導入され、ネットワークにおけるループを回避するために用いられる。高速転送通知メッセージがブリッジインタフェースに到達する場合、ブリッジはその通常のＭＡＣ学習処理を開始する。これは、典型的に、当該メッセージのソースＭＡＣアドレスは当該メッセージが受信されたインタフェースに関連づけられているかをブリッジが判定することを含む。ＭＡＣアドレスとインタフェースとの関連付けは、典型的にブリッジＭＡＣテーブルに記憶される。エントリが存在しない（ＭＡＣアドレスとインタフェースとの関連付けが新しい）場合、通例のＭＡＣ学習及びフラッディング処理が実行される（高速障害通知が当該ブリッジグループの他のインタフェース全てにフラッディングされるであろう）。しかしながら、エントリが存在する（ＭＡＣアドレスとインタフェースとの関連付けが既知である）場合、高速障害通知メッセージは破棄され、それ以上の処理は実行されない。

【0056】

一回学習フラッディングスキームのループ回避メカニズムは、各インタフェースが高速障害通知メッセージを受信し、当該メッセージを他のインタフェースに最大で１回フラッディングすることとなることを保証する。従って、ｎ個のインタフェースを有するブリッジは、高速障害通知メッセージを最大でｎ回フラッディングすることとなる。

【0057】

図５に図示される例においては、インタフェースＡｂ５７０とインタフェースＢａ５７２との間のリンク５５２が障害を起こしている。説明の目的のため、ルータ５２０Ｂが、リンク５５２の障害を検出する。ただし、ルータ５２０Ａも障害を検出し得ることが理解されるべきである。障害の検出は、様々な実施形態において様々な手法で実行され得る。一実施形態においては、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。リンク５５２の障害の検出は、イベントフレームワークにおけるイベントである。

【0058】

障害を検出すると、リンク５５２上の障害を示す高速障害通知メッセージがＢＶＩインタフェース５１５Ｂを介して送られて、高速フラッディング処理が開始される。具体的には、高速障害通知メッセージ５６０がインタフェースＢｃ５７４及びＢｄ５７６を介してフラッディングされる。高速障害通知メッセージ５６０は、インタフェースＢａ５７２に割り当てられるソースＭＡＣアドレスを有する。この例の目的のために、フラッディングの方向は、高速障害通知メッセージ５６０がインタフェースＢｃ５７４を介してフラッディングされることを基準として説明されるであろう。ただし、高速障害通知メッセージ５６０がインタフェースＢｄ５７６を介してフラッディングされることを基準として同様の動作が実行されることが理解されるべきである。

【0059】

高速障害通知メッセージ５６０は、リンク５５４をわたって送られ、ルータ５２０ＣのインタフェースＣｂ５７８において受信される。これは高速障害通知メッセージ５６０のソースＭＡＣアドレスを有するパケットがインタフェースＣｂ５７８上で受信される初回であると仮定すると、インタフェースとＭＡＣアドレスとの関連付け（例えば、インタフェースＣｂ５７８とインタフェースのＭＡＣアドレスとの関連付け）が学習される（例えば、ブリッジＭＡＣテーブルに追加される）。高速障害通知メッセージ５６０は、ＢＶＩ５１５Ｃ及びインタフェースＣｄ５８０を介して外部にもフラッディングされる。ＢＶＩ５１５Ｃは、処理する（例えば、リンク５５２の障害を反映するために、ルータ５２０Ｃのルーティングテーブル及び／又は転送テーブルを更新する）ために、当該通知をＩＧＰモジュール５１０Ｃに転送する。

【0060】

高速障害通知メッセージ５６０は、リンク５５６をわたって送られ、ルータ５２０ＤのインタフェースＤｃ５８４において受信される。ルータ５２０Ｃに関して説明されたのと同様の処理において、これが高速障害通知メッセージ５６０のソースＭＡＣアドレスを有するパケットがインタフェースＤｃ５８４上で受信される初回であると仮定すると、インタフェースとＭＡＣアドレスとの関連付け（例えば、インタフェースＤｃ５８４とインタフェースのＭＡＣアドレスとの関連付け）が学習される（例えば、ブリッジＭＡＣテーブルに追加される）。高速障害通知メッセージ５６０は、ＢＶＩ５１５Ｄ及びインタフェースＤｂ５８２を介して外部にもフラッディングされる。ＢＶＩ５１５Ｄは、処理する（例えば、リンク５５２の障害を反映するために、ルータ５２０Ｄのルーティングテーブル及び／又は転送テーブルを更新する）ために、当該通知をＩＧＰモジュール５１０Ｄに転送する。

【0061】

高速障害通知メッセージ５６０は、リンク５５０をわたって送られ、ルータ５２０ＢのインタフェースＢｄ５７６において受信される。ルータ５２０Ｃ及び５２０Ｄに関して説明されたのと同様の処理において、これが高速障害通知メッセージ５６０のソースＭＡＣアドレスを有するパケットが（外部のソースから）インタフェースＢｄ５７６において受信される初回であると仮定すると、インタフェースとＭＡＣアドレスとの関連付け（例えば、インタフェースＢｄ５７６とインタフェースのＭＡＣアドレスとの関連付け）が学習される（例えば、ブリッジＭＡＣテーブルに追加される）。高速障害通知メッセージ５６０は、ＢＶＩ５１５Ｂ及びインタフェースＢｃ５７４を介して外部にもフラッディングされる。

【0062】

高速障害通知メッセージ５６０は、再度リンク５５４をわたって送られ、インタフェースＣｂ５７８において受信される。しかしながら、高速障害通知メッセージ５６０はインタフェースＣｂ５７８において既に受信されているため、高速障害通知メッセージは破棄され、ループは停止する。

【0063】

図６は、一実施形態に係る、ネットワーク障害を検出して、ブリッジベースの高速障害通知メッセージフラッディングを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示するフロー図である。動作６１０において、ルータはネットワーク障害を検出する。一実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態において、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作６１５に移る。

【0064】

動作６１５において、ルータは、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、リンク障害に関係のあるルータ上のインタフェースのソースＭＡＣアドレスを含む。例えば、図５を参照し、リンク５５２が障害を起こしたと仮定すると、ルータ５２０Ｂは、インタフェースＢａ５７２のソースＭＡＣアドレスを含む高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。例えば、高速障害通知メッセージは、受信側ルータの各々に、収束を待つこと無く（ルーティングテーブル及び／又は転送テーブルが更新されることを待つこと無く）そのデータトランスポート層におけるそのインタフェースの１つ以上から高速障害通知メッセージをフラッディングし、ルーティングテーブル及び／又は転送テーブルを適当に更新して高速障害通知メッセージにおいて示されるネットワーク障害を反映すべきかを判定すべきであることを示す。従って、高速障害通知メッセージは、受信側ルータに、データトランスポート層（例えば、入口ポート）によって、アプリケーション層（又はさもなければ制御プレーン）とのインタラクション無しに、従って回線レートで、ＭＡＣ学習及びルックアップが実行されるべきであり、アプリケーション層はフラッディング処理とは独立にルーティングテーブル及び／又は転送テーブルを適当に更新すべきであることを示す。一実施形態において、高速障害通知メッセージは、当該メッセージを高速障害通知メッセージとして扱うべきであることを受信側ルータに示すためのＦＦＦＣ専用の固有の宛先ＭＡＣアドレスを含む。従って、高速障害通知メッセージは、受信側ルータが高速障害通知メッセージを回線レートでフラッディングすること並びにそれらのルーティングテーブル及び／又は転送テーブルを更新してネットワーク障害を反映することの双方を可能にする情報を含む。

【0065】

フローは次いで動作６２０に移り、ルータは、高速障害通知メッセージをブリッジグループにフラッディングする。ブリッジグループは、同じブロードキャストドメインの一部である１つ以上のネットワークインタフェースを含む。例えば、図５を参照すると、ルータ５２０Ｂは、高速障害通知メッセージ５６０をインタフェースＢｃ５７４及びＢｄ５７６を介してフラッディングする。フローは次いで動作６２５に移り、ルータは、ネットワーク障害を反映するために、そのルーティングテーブル及び転送テーブルを更新する。ルータがそのルーティングテーブル及び転送テーブルを更新した後、データパケットは、ネットワーク障害を回避するためにリルーティングされるであろう。

【0066】

動作６２５は、幾つかの実施形態において、動作６１５及び／又は６２０と同時又はその前に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージが生成され及び送信される後まで完了されないことが理解されるべきである。ルータは高速障害通知メッセージを生成し及び送信する前にルーティングテーブル及び転送テーブルの更新が終了するまで待たないことも理解されるべきである。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0067】

図７は、一実施形態に係る、ブリッジベースの高速障害通知メッセージフラッディングを用いるＦＦＦＣアーキテクチャにおいて高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作７１０において、ルータは、ネットワーク障害に関する情報を含む高速障害通知メッセージを、インタフェース上で受信する。高速障害通知メッセージは、当該メッセージがＦＦＦＣアーキテクチャにおいて扱われるべきであることも示す。例えば、高速障害通知メッセージは、本明細書において説明されるＦＦＦＣ専用の固有の宛先ＩＰアドレス又はＭＡＣアドレスを含み得る。フローは次いで動作７１５に移る。

【0068】

動作７１５において、ルータは、高速障害通知メッセージのソースＭＡＣアドレスは当該メッセージが受信されたインタフェースに関連付けられているかを判定する。例えば、ルータは、ブリッジＭＡＣテーブルにアクセスして、ソースＭＡＣアドレスがインタフェースに関連付けられているかを判定する。ソースＭＡＣアドレスがインタフェースに関連付けられていない場合、フローは動作７２０に移る。ソースＭＡＣアドレスがインタフェースと既に関連付けられている場合（これは典型的には高速障害通知メッセージが当該インタフェース上で既に受信されたことを意味する）、フローは動作７４０に移り、パケットが破棄される。前述の通り、パケットが既知である場合に当該パケットを破棄することは、ネットワークにおけるループを回避するために用いられる。また、一実施形態において、ＭＡＣ学習及びルックアップは、回線レートで入口インタフェース内において実行され、ルータの制御プレーンとのインタラクション無しに実行される。従って、本発明の実施形態の一回学習フラッディング技法は、ループを回避するために用いられ、ＭＡＣムーブ検出などの他の一般に用いられるループ回避技法よりも高速である（例えば、当該フラッディング技法は回線レートで動作する）。

【0069】

動作７２０において、ルータは、高速障害通知メッセージに含まれるソースＭＡＣアドレスを、当該メッセージが受信されたルータのインタフェースに関連付ける。例えば、ルータは、ソースＭＡＣアドレスとインタフェースとのペアをブリッジＭＡＣテーブルに追加する。フローは次いで動作７２５に移り、ルータは、高速障害通知メッセージを、もしあればブリッジグループの他のインタフェース全てにフラッディングして、高速障害通知メッセージが隣接するルータに送られるようにする。フローは次いで動作７３０に移り、高速障害通知メッセージは、さらなる処理のためのルーティングプロトコル（例えば、ルータ上のＩＧＰモジュール）に向けて、ＢＶＩに送られる。フローは次いで動作７３５に移り、ルータ（例えば、ＩＧＰモジュール）は、障害を反映するために、ルーティングテーブル及び／又は転送テーブルを更新する。

【0070】

一実施形態において、非ＦＦＦＣの目的からのブリッジの使用を抑制するために、専用のＭＡＣアドレスが予約され及び高速障害通知メッセージについての宛先ＭＡＣアドレスとして用いられる。一実施形態において、ブリッジがＦＦＦＣ目的のための専用のＭＡＣアドレスのみを受け取るように、ＡＣＬ（access control list：アクセス制御リスト）が設定される。

【0071】

レイヤ２のブリッジネットワーク上のＳＴＰベースの高速障害通知メッセージフラッディング
一実施形態において、レイヤ２のブリッジネットワーク上の高速障害通知メッセージフラッディングのための伝達メカニズムは、スパニングツリープロトコル（ＳＴＰ）を用いる。レイヤ２のブリッジネットワークにおけるフラッディングは、明確に定義されており、高速障害通知メッセージを伝達するために用いられることができる。ブリッジグループは参加している各ルータ上で設定され、ＳＴＰは全てのブリッジ上で有効化される（enabled）。ＳＴＰは、ルータのスパニングツリーを作成することによってブリッジのループを回避するために用いられ、当該ツリーの一部ではないインタフェースをブロックする。ＳＴＰは、ＩＥＥＥ８０２．１Ｄにおいて定義されている。このタイプのマシンは、ブルータ（brouter）と呼ばれる。ＩＰパケットを受信すると、ブルータは、ＩＰパケットをルーティングする。他のタイプのパケットを受信すると、ブルータは、パケットをブリッジする。ブルータはＩＰパケットをルーティングするため、レイヤ２のブリッジネットワーク上のＳＴＰベースの高速障害通知メッセージフラッディングにおいて用いられる高速障害通知メッセージは、ＩＰ転送テーブルに従って転送されることを回避するためにレイヤ２のパケットである。

【0072】

図８は、一実施形態に係る、ネットワーク障害を検出して、ＳＴＰベースのフラッディングを用いてドメインワイドなＦＦＦＣを開始するレイヤ２のブリッジネットワークにおけるルータ（例えば、ブルータ）上で実行される例示的な動作を図示するフロー図である。動作８１０において、ルータは、ネットワーク障害を検出する。一実施形態においては、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作８１５に移る。

【0073】

動作８１５において、ルータ（例えば、当該ルータ上のＦＦＮモジュール）は、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、レイヤ２のパケットである。レイヤ２の高速障害通知メッセージについての例示的なフォーマットは、図２１を参照しつつさらに詳細に説明されるであろう。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。例えば、高速障害通知メッセージを受信するルータは、収束を待つこと無く、ＳＴＰによってブロックされない他のインタフェース全てにパケットをフラッディングすべきである。従って、高速障害通知メッセージは、受信側ルータに、そのデータトランスポート層がＳＴＰによってブロックされない他のポート全てに、アプリケーション層とのインタラクション無しに、従って回線レートでパケットをフラッディングすべきであること、及びそのアプリケーション層はルーティングテーブル及び／又は転送テーブルを適当に更新すべきであることを示す。従って、高速障害通知メッセージは、受信側ルータに当該高速障害通知メッセージを回線レートでフラッディングすること並びにそれらのルーティングテーブル及び／又は転送テーブルを更新してネットワーク障害を反映することの双方を可能にする情報を含む。

【0074】

フローは次いで動作８２０に移り、ルータは、レイヤ２の高速障害通知メッセージをブリッジグループのメンバにフラッディングする。フローは次いで動作８２５に移り、ルータは、障害を反映するために、そのルーティングテーブル及び／又は転送テーブルを適当に更新する（例えば、ＩＧＰモジュールが、そのルーティングテーブル及び／又は転送テーブルを適当に更新する）。動作８２５は、幾つかの実施形態において、動作８１５及び／又は８２０と同時に又はその前に開始されてもよい。ただし、上記更新は、典型的には、高速障害通知メッセージが生成され及び送信される後まで終了されないことが理解されるべきである。高速障害通知メッセージを生成し及び送信する前にルーティングテーブル及び転送テーブルの更新が終了されるまでルータは待たないことも理解されるべきである。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0075】

図９は、一実施形態に係る、レイヤ２の高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作９１０において、ルータは、ネットワーク障害に関する情報を含むレイヤ２の高速障害通知メッセージを受信する。例えば、当該ルータの（データトランスポート層上の）ＦＦＮモジュールは、レイヤ２の高速障害通知メッセージを受信する。フローは次いで動作９１５に移り、ルータ（例えば、当該ルータのＦＦＮモジュール）は、ＳＴＰによってブロックされない他のインタフェース全てに高速障害通知メッセージをフラッディングする。フローは次いで動作９２０に移り、高速障害通知メッセージは、さらなる処理のためにルータ上のルーティングプロトコルモジュール（例えば、ＩＧＰモジュール）に送られる。フローは次いで動作９２５に移り、ルーティングプロトコルモジュールは、ルーティングテーブル及び転送テーブルを更新してネットワーク障害を反映する。動作９２０及び９２５は、幾つかの実施形態において、動作９１５の前に又は同時に開始されてもよい。ただし、上記更新は、典型的には、高速障害通知メッセージがフラッディングされる後まで完了されないことが理解されるべきである。高速障害通知メッセージのフラッディングの前にルーティングテーブル及び転送テーブルの更新が終了されるまでルータは待たないことも理解されるべきである。

【0076】

レイヤ２のブリッジネットワーク上のＳＴＰフラッディングは、単純且つ高速である。しかしながら、ＳＴＰフラッディングは、ターンアラウンド（次のヒットのために準備すること）については比較的長い時間を要し、ツリーパーティション問題の対象ともなり、これは同時に起こる複数のリンク障害に対処できないことを意味する。

【0077】

ユニキャストベースの高速障害通知メッセージフラッディング
一実施形態において、高速障害通知メッセージフラッディングのための伝達メカニズムは、ユニキャストベースである。ネットワーク障害を検出するルータは、高速障害通知メッセージを生成し、ドメイン中の各ルータにコピーを送る。ドメイン中のルータのＩＤは、ルータ上のルーティングテーブル及び／又は転送テーブルに記憶される。これらのユニキャスト高速障害通知メッセージは、通例のＩＰデータトラフィックが転送されるのと同様の手法で、宛先ルータにデータプレーン速度で転送される。

【0078】

図１０は、一実施形態に係る、ユニキャストベースの高速障害通知メッセージフラッディングを用いる例示的なネットワークを図示する。ネットワーク１０００は、ルータ１０２０Ａ〜Ｄを含む。ルータ１０２０Ａとルータ１０２０Ｂとは、リンク１０５２によって結合される。ルータ１０２０Ｂとルータ１０２０Ｃとは、リンク１０５４によって結合される。ルータ１０２０Ｃとルータ１０２０Ｄとは、リンク１０５６によって結合される。ルータ１０２０Ａとルータ１０２０Ｄとは、リンク１０５０によって結合される。ルータ１０２０Ａ〜Ｄは、それぞれＩＧＰモジュール１０１０Ａ〜Ｄ及びＦＦＮモジュール１０１５Ａ〜Ｄを含む。ＩＧＰモジュール１０１０Ａ〜Ｄは、それぞれルータ１０２０Ａ〜Ｄのアプリケーション層の一部であり、ＦＦＮモジュール１０１５Ａ〜Ｄは、それぞれルータ１０２０Ａ〜Ｄのデータトランスポート層の一部である。

【0079】

図１０に図示される例において、ネットワーク１０００は、ネットワーク障害を経験している。具体的には、リンク１０５２が障害を起こしている。説明の目的のため、ルータ１０２０Ｂは、リンク１０５２の障害を検出する。ただし、ルータ１０２０Ａも障害を検出し、ルータ１０２０Ｂと同様の動作を実行し得ることが理解されるべきである。障害の検出は、様々な実施形態において様々な手法で実行され得る。一実施形態においては、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。リンク１０５２の障害の検出は、イベントフレームワークにおけるイベントである。従って、リンク１０５２の障害をＩＧＰモジュール１０１０Ｂに通知するメッセージは、ＩＧＰモジュール１０１０Ｂに送られ、ＩＧＰモジュール１０１０Ｂは、リンク１０５２の障害を反映するために、ルータ１０２０Ｂのルーティングテーブル及び転送テーブルを更新することができる。

【0080】

障害を検出した後のあるときに、ルータ１０２０Ｂは、リンク１０５２上の障害を示す高速障害通知メッセージを発信する。高速障害通知メッセージは、当該タイプのメッセージを受信するように登録した他のルータに障害を通知するために用いられる。例えば、高速障害通知メッセージは、リンク１０５２上に障害が存在することを示す。ルータ１０２０Ｂは、ＩＰドメイン中のルータの各々に高速障害通知メッセージを送る。図１０を参照すると、リンク１０５２の障害を示すユニキャスト高速障害通知メッセージ１０６０は、ルータ１０２０Ｃの宛先ＩＰアドレスに送られ、及びルータ１０２０Ｄの宛先ＩＰアドレスに送られる。また、ユニキャスト高速障害通知メッセージ１０６０は、ルータ１０２０Ａの宛先アドレスにも送られ得る。

【0081】

ルータが高速障害通知メッセージを受信すると、当該ルータは、そのルーティングテーブル及び／又は転送テーブルを適当に更新することを含めて当該高速障害通知メッセージを処理する。例えば、ルータ１０２０Ｃが高速障害通知メッセージ１０６０を受信すると、当該メッセージは、ルーティングテーブル及び／又は転送テーブルを更新することを含むさらなる処理のためにＩＧＰモジュール１０１０Ｃに転送されるであろう。幾つかの実施形態において、受信側ルータのＩＧＰモジュールは、パケット検証の期間における隣接関係チェックを控えることによって、高速障害通知メッセージのその受け取り基準を緩和する。隣接関係チェックが迂回される場合、ＤｏＳ攻撃又はＰＤＵリプレイ攻撃を回避するために、ドメインワイドな認証が用いられ得る。

【0082】

本明細書において説明される他の高速障害通知メッセージ伝送技法とは異なり、高速障害通知メッセージをフラッディングすることについて、障害を検出するルータが責任を有する。従って、高速障害通知メッセージを受信するルータは、それらのネクストホップのルータに当該メッセージを転送し又は中継する必要がない。

【0083】

図１１は、一実施形態に係る、ネットワーク障害を検出し、ユニキャストベースの高速障害通知メッセージフラッディングを用いるルータによって実行される例示的な動作を図示するフロー図である。動作１１１０において、ルータは、ネットワーク障害を検出する。一実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作１１１５に移る。

【0084】

動作１１１５において、ルータは、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。従って、高速障害通知メッセージは、受信側ルータがそれらのルーティングテーブル及び転送テーブル更新してネットワーク障害を反映することを可能にする情報を含む。フローは次いで動作１１２０に移る。上述の通り、高速障害通知メッセージは、既存のＩＧＰ ＰＤＵパケットフォーマットを用いても、又はプロトコルに関わらず共通のメッセージフォーマットを用いてもよい。

【0085】

動作１１２０において、高速障害通知のコピーは、（例えば、ルータのルーティングテーブル及び／又は転送テーブルにおいて識別される）ＩＰドメイン中の各ルータに送られる。例えば、ＩＰドメイン中の各ルータについて、パケットの宛先ＩＰアドレスが当該ルータに設定される。フローは次いで動作１１２５に移り、ルータはそのルーティングテーブル及び転送テーブルを更新してネットワーク障害を反映する。

【0086】

動作１１２５は、幾つかの実施形態において、動作１１１５及び／又は１１２０の前に又は同時に開始されてもよい。幾つかの実施形態において、ルータは、高速障害通知メッセージを送信する前にルーティングテーブル及び／又は転送テーブルの更新が終了されるまで待たない。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0087】

図１２は、一実施形態に係る、ユニキャストベースの伝送技法を用いて伝送される高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作１２１０において、ルータは、ネットワーク障害に関する情報を含む高速障害通知メッセージを受信する。フローは次いで動作１２１５に移る。動作１２１５において、高速フラッディングメッセージは、さらなる処理のためにルータ上の適当なルーティングプロトコルモジュール（例えば、ルータ上のＩＧＰモジュール）に送られる。フローは次いで動作１２２０に移り、（ルーティングプロトコルモジュールが隣接関係チェックを実行するように構成される場合）典型的にルーティングプロトコルモジュールによって実行される隣接関係チェックは、迂回される。フローは次いで動作１２２５に移り、ルーティングプロトコルモジュールは、ネットワーク障害を反映するために、ルーティングテーブル及び／又は転送テーブルを更新する。

【0088】

ユニキャストベースの高速障害通知メッセージフラッディング技法は、ネットワーク障害を検出して高速フラッディング通知を生成し及びＩＰドメイン中のその他のルータに送信するルータに依存するため、パケットを送る試みを複数回繰り返さなければならない発信側ルータへの負担が重すぎるように思われるかもしれない。しかしながら、発信側ルータ上の負担は無視できることを実験は示している。適当な（decent）サイズである、１００個のルータを含むネットワークの場合、発信側ルータが１００個の高速フラッディング通知パケットを生成し及び送信するための総時間は、７ミリ秒である。発信側ルータ上のこの小さな遅延は、高速障害通知メッセージパケットをデータプレーンに予めダウンロードすることによって最小化されることができる。データプレーンはＩＧＰルーティングテーブルの一部である全てのルータのリストを既に有しているため、データプレーンは、パケットを直接ディスパッチすることができる。

【0089】

基本的に、ユニキャストベースの高速障害通知メッセージフラッディング技法は、マルチキャストツリーと同様のツリーベースである。しかしながら、高速障害通知メッセージフラッディングの目的のために生成される特別なツリーは存在しない。代わりに、通常のルーティングテーブルが用いられ、これはＳＰＦ（shortest path first：最短パス優先）ツリー（ＳＰＴ）である。これは、フラッディングが（ルーティングテーブルによって判定される通りの）最短パスに従うこと、及びフラッディングループが作成されないことを保証する。故障したリンクがＳＰＴ上に存在する状況においては、ツリーは区分化され、発信側ルータからのフラッディングはツリーの一部にしか到達しないであろう。しかしながら、リンクの他端側のルータは同様のユニキャストベースの高速障害通知処理を実行してツリーの他の部分のルータをカバーすることができるため、ツリー全体に障害が通知されるであろう。例えば、図１０を参照すると、ルータ１０２０Ｂがリンク障害１０５２を検出することに応じてユニキャスト高速障害通知メッセージを生成し及びドメイン中のその他のルータに送信することに加えて、ルータ１０２０Ａもリンク障害１０５２を検出することに応じてユニキャスト高速障害通知メッセージを生成し及びドメイン中のその他のルータに送信することができる。

【0090】

ＲＰＦチェック高速障害通知メッセージフラッディングを通じたゲーテッド（gated）マルチキャスト
一実施形態において、高速障害通知メッセージフラッディングのための伝達メカニズムは、マルチキャストベースであり、フラッディングループはＲＰＦチェックを通じて回避される。ゲーテッドマルチキャストベースのフラッディングは、マルチキャストツリーが確立されることを必要とせず、むしろ、その他のルータに高速障害通知メッセージをフラッディングする前に、ＩＧＰモジュールによって算出されたものと同じＳＰＴ及び当該ＳＰＴを用いるＲＰＦチェックを用いる。ＲＰＦチェックは、高速障害通知メッセージが受信されるインタフェースが高速障害通知メッセージのソースに到達するためのアウトゴーイングインタフェースでもあるのかを判定する。

【0091】

一実施形態において、専用のマルチキャストアドレスが定義され、ゲーテッドマルチキャストベースの高速障害通知メッセージフラッディングのために用いられる。この専用のマルチキャストアドレスは、高速フラッディングのための高速障害通知メッセージを識別するために用いられる。ルータが当該マルチキャストアドレスにおいて高速障害通知メッセージを受信すると、当該ルータは、ＲＰＦチェックを実行する。例えば、ルータは、発信側ルータ（障害を検出し、高速障害通知メッセージを発信したルータ）についてのＩＰユニキャストルーティングテーブル（例えば、ＩＧＰモジュールによって算出されるＳＰＴ）にアクセスして、発信側ルータに到達するためのアウトゴーイングインタフェースを発見する。高速障害通知メッセージの到着インタフェースが発信側ルータに到達するためのアウトゴーイングインタフェースと同じである場合、ＲＰＦチェックにパスし、ルータは他のインタフェースに通知をフラッディングする。高速障害通知メッセージの到着インタフェースが発信側ルータに到達するために用いられるアウトゴーイングインタフェースと同じではない場合、ルータはパケットを破棄し、それによって、ループを回避する。

【0092】

図１３は、一実施形態に係る、ゲーテッドマルチキャスト高速障害通知メッセージフラッディングを用いる例示的なネットワーク１３００を図示する。例示的なネットワーク１３００は、ルータ１３２０Ａ〜Ｄを含み、当該ルータ１３２０Ａ〜Ｄは、それぞれＩＧＰモジュール１３１０Ａ〜Ｄ及びＦＦＮモジュール１３１５Ａ〜Ｄを含む。ルータ１３２０Ａは、ルータ１３２０Ｂにリンク１３５０を介して結合され、ルータ１３２０Ｃにリンク１３５２上で結合され、及びルータ１３２０Ｄにリンク１３５６上で結合される。ルータ１３２０Ｂも、ルータ１３２０Ｃにリンク１３５４上で、及びルータ１３２０Ｄにリンク１３６０上で結合される。ルータ１３２０Ｃも、ルータ１３２０Ｄにリンク１３５８上で結合される。

【0093】

ルータ１３２０Ａ〜ＤのＩＧＰモジュール１３１０Ａ〜Ｄの各々は、（当該ＩＧＰモジュールによって算出される）そのＳＰＴが双方向マルチキャストツリーとして用いられるように複製し、当該双方向マルチキャストツリーがルータのデータプレーンにダウンロードされるようにし（例えば、当該データプレーンの１つ以上のラインカード上にインストールし）、及びゲーテッドマルチキャストベースの高速障害通知メッセージフラッディング専用のマルチキャストグループアドレスを当該マルチキャストグループに加入するために追加する。

【0094】

図１３を参照すると、ルータ１３２０Ａをルートとする（rooted）ＳＰＴは、ルータ１３２０Ｂに到達するためのリンク１３５０、ルータ１３２０Ｃに到達するためのリンク１３５２、並びにルータ１３２０Ｄに到達するためのリンク１３５０及び１３６０を含む。例えば、ルータ１３２０Ａがルータ１３２０Ｄにパケットを送る際、当該パケットは、リンク１３５０及びリンク１３６０に沿って伝わる。リンク１３５４、１３５６、及び１３５８は、ルータ１３２０ＡをルートとするＳＰＴの一部ではない。

【0095】

説明の目的のため、ルータ１３２０Ａは、リンク又はノードの障害を検出する。これは、本発明の理解を曖昧にしないために図示されていない。上述の通り、障害の検出は、様々な実施形態において様々な手法で実行され得る。一実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。ネットワーク障害の検出は、イベントフレームワークにおけるイベントである。

【0096】

ネットワーク障害を検出した後のあるときに、ルータ１３２０Ａは、当該障害を識別する情報を含む高速障害通知メッセージを生成する。例えば、ＦＦＮモジュール１３１５Ａは、高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータに、ゲーテッド高速フラッディング処理が実行されるべきであることを示す。例えば、高速障害通知メッセージは、受信側ルータに、そのアプリケーション層がルーティングテーブル及び／又は転送テーブルを更新して高速障害通知メッセージにおいて示されるネットワーク障害を反映することとは独立に、そのデータトランスポート層が高速障害通知メッセージをそのインタフェースにマルチキャストすべきかを判定（及び、適切な場合には当該メッセージをマルチキャスト）すべきであることを示す。

【0097】

データトランスポート層は、高速障害通知メッセージを、当該メッセージの宛先アドレスに基づいて識別する（高速障害通知メッセージは、ゲーテッド高速障害通知メッセージ専用のマルチキャスト宛先アドレスを有する）。ルータ１３２０Ｂ〜Ｄの各々は、専用のマルチキャストアドレスを有するマルチキャストパケットをリッスンし、結果として、ルータ１３２０Ｂ〜Ｄの各々は、マルチキャスト高速フラッディング通知メッセージ１３６０を受信する。ルータ１３２０Ａ〜Ｄはメッシュ状に配置されるため、ルータが高速障害通知メッセージ１３６０の複数のコピーを受信し得る可能性がある。例えば、ルータ１３２０Ｃは、ルータ１３２０Ａからリンク１３５２上で高速障害通知メッセージ１３６０を受信し、ルータ１３２０Ｂからもリンク１３５４上で高速障害通知メッセージ１３６０を受信し得る。ただし、ループを回避するために、ＲＰＦチェックが実行される。例えば、ルータ１３２０Ｃは、ルータ１３２０Ａからルータ１３２０Ｂを介して受信される高速障害通知メッセージ１３６０を破棄するであろう。なぜなら、ルータ１３２０Ｂは、ルータ１３２０Ａへのルータ１３２０ＣのＲＰＦネクストホップではないためである。

【0098】

図１４は、一実施形態に係る、ネットワーク障害を検出して、ゲーテッドマルチキャストベースの高速障害通知メッセージフラッディングを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示するフロー図である。動作１４１０において、ルータはネットワーク障害を検出する。一実施形態においては、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作１４１５に移る。

【0099】

動作１４１５において、ルータ（例えば、当該ルータ上のＦＦＮモジュール）は、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。また、高速障害通知メッセージは、受信側ルータに、ゲーテッドマルチキャスト高速フラッディング処理が実行されるべきであることも示す。当該処理は、ＲＰＦチェックを実行することを含み、高速障害通知を他のインタフェースにマルチキャストすることを含み得る。高速障害通知メッセージは、マルチキャストゲーテッド高速障害通知専用のマルチキャストアドレスの宛先アドレスを有する。アプリケーション層がネットワーク障害後のトポロジーにおける変化を反映するためにルーティングテーブル及び／又は転送テーブルを更新することとは独立に、高速障害通知メッセージは（転送が発生すべき場合には）それらのルータによって転送されるべきである。従って、高速障害通知メッセージは、受信側ルータに、ネットワーク障害を反映するためにそれらのルーティングテーブル及び／又は転送テーブルを更新すること、並びに、当該更新とは独立に、ゲーテッドマルチキャスト高速フラッディング処理を実行することの双方を示す情報を含む。フローは次いで動作１４２０に移り、ルータは、マルチキャストゲーテッド高速障害通知専用のマルチキャストグループアドレスにパケットを送る。フローは次いで動作１４２５に移り、ルータは、障害を反映するために、そのルーティングテーブル及び／又は転送テーブルを適当に更新する（例えば、ＩＧＰモジュールが、そのルーティングテーブル及び／又は転送テーブルを適当に更新する）。

【0100】

動作１４２５は、幾つかの実施形態において、動作１４１５及び／又は１４２０の前に又は同時に開始されてもよい。ただし、上記更新は、典型的には、高速障害通知メッセージが生成され及び送信される後までは完了されないことが理解されるべきである。ルータは、高速障害通知メッセージを生成し及び送信する前にルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0101】

図１５は、一実施形態に係る、ゲーテッドマルチキャスト高速障害通知メッセージフラッディングアプリケーションにおいて、マルチキャスト高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作１５０１０において、ルータは、ネットワーク障害に関する情報を含むマルチキャスト高速障害通知メッセージを受信する。例えば、当該ルータのＦＦＮモジュールは、マルチキャスト高速障害通知メッセージを受信する。また、高速障害通知メッセージは、ルータに、ゲーテッドマルチキャスト高速フラッディング処理が実行されるべきであることも示す。当該処理は、ＲＰＦチェックを実行することを含み、高速障害通知を他のインタフェースにマルチキャストすることを含み得る。フローは次いで動作１５１５に移り、ルータ（例えば、ＦＦＮモジュール）は、ＲＰＦチェックを実行する。当該ＲＰＦチェックは、高速障害通知メッセージの到着インタフェースが、発信側ルータに到達するためのアウトゴーイングインタフェースと同じであるかを判定することを含む。例えば、ルータは、マルチキャスト高速障害通知パケットのソースであるルータについてのＩＰユニキャストルーティングテーブルにアクセスして、当該ルータに到達するためのアウトゴーイングインタフェースを判定する。具体的な例として、受信側ルータのＦＦＮモジュールは、ＳＰＴに基づいて生成されたデータプレーン上の双方向マルチキャストツリーを用いて、マルチキャスト高速障害通知パケットのソースに到達するためのアウトゴーイングインタフェースを判定する。高速障害通知メッセージのインカミングインタフェースが当該高速障害通知メッセージを発信したルータに到達するためのアウトゴーイングインタフェースと同じである場合、フローは動作１５２０に移る。そうでない場合、フローは動作１５４０に移り、パケットは破棄される。

【0102】

動作１５２０において、ルータ（例えば、当該ルータのＦＦＮモジュール）は、当該ルータのその他のインタフェースに高速障害通知をマルチキャストする。例えば、図１３を参照すると、ルータ１３２０Ｂがマルチキャスト高速障害通知メッセージ１３６０をリンク１３５０上で受信し及びリンク１３５０に対応するインタフェースはルータ１３２０Ａに到達するために用いられるインタフェースと同じであると判定することに応じて、ＦＦＮモジュール１３１５Ｂは、リンク１３５４及び１３６０に対応するインタフェースから高速障害通知メッセージ１３６０をマルチキャストする。フローは動作１５２０から動作１５２５に移り、ＦＦＮモジュールは、当該ルータのルーティングプロトコルモジュール（例えば、ＩＧＰモジュール）に高速障害通知を転送する。フローは次いで動作１５３０に移り、ルーティングプロトコルモジュールは、ネットワーク障害を反映するためにルーティングテーブル及び転送テーブルを更新する。

【0103】

動作１５３０は、幾つかの実施形態において、動作１５２０の前に又は同時に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージがフラッディングされた後まで完了されないことが理解されるべきである。ルータは、高速障害通知メッセージをフラッディングする前にルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。

【0104】

最短パスツリー（ＳＰＴ）選択ルート高速障害通知メッセージフラッディング
一実施形態において、高速障害通知メッセージのための伝達メカニズムは、ルータのうちの１つをルートノードとして選択するＳＰＦ算出に基づくＳＰＴを用いるマルチキャストベースである。ツリーは双方向マルチキャストツリーと同様であるが、ＩＧＰ処理によって直接構築される。ネットワークにおけるルータは、ルータのうちの１つをルートノードとして選択し、ＩＧＰモジュールは、現行のネットワークトポロジーに基づいて、選択されたルータをルートとするＳＰＴを構築する。一実施形態において、ルータは、最上位のルータＩＤを有するルータがルートノードとなるように選択する。双方向マルチキャスト転送エントリは、構築されたＳＰＴに基づいてＩＧＰモジュール（例えば、ＩＳ−ＩＳ又はＯＳＰＦ）によって作成され、高速障害通知メッセージを広める際に用いられるためにデータプレーン（例えば、ルータの１つ以上のラインカード）にダウンロードされることができる。高速障害通知メッセージは、ダウンロードされた双方向マルチキャスト転送エントリを用いる通常のマルチキャストプロトコルを用いて転送される。

【0105】

図１６は、一実施形態に係る、ルータにおいて実行されるＳＰＦ算出に基づいてＳＰＴを構築するための例示的な動作を図示する。動作１６１０において、ルータは、ルートノードとなるネットワークのルータを選択する。選択されたルータは、必ずしも動作１６１０を実行しているルータではない。一実施形態において、ルートノードとして選択されたルータは、最上位のルータＩＤを有する。当然ながら、ルートノードの選択は、異なる実施形態においては異なる手法で実行され得る（例えば、最下位のルータＩＤを有するルータ）。ただし、いずれの場合にも、ネットワークにおけるルータは、どのルータがルートノードであるかについて合意する必要がある。フローは次いで動作１６１５に移り、ルータは、現行のネットワークトポロジーに基づいて、選択されたルートノードをルートとするＳＰＴを構築する。例えば、ルータは、（例えば、ＯＳＰＦ又はＩＳ−ＩＳを用いる場合）ルータのＬＳＤＢ（link state database）上でＳＰＦの実装を実行する。フローは次いで動作１６２０に移り、構築されたＳＰＴは、高速障害通知メッセージを広める際に用いられるための双方向マルチキャストツリーとして、ルータのデータプレーン（例えば、ルータのデータトランスポート層）にダウンロードされる。

【0106】

図１７は、一実施形態に係る、ネットワーク障害を検出して、ＳＰＦ選択ルートノード算出に基づくＳＰＴを用いてマルチキャストベースの高速障害通知メッセージを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示する。動作１７１０において、ルータは、ネットワーク障害を検出する。一実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作１７１５に移る。

【0107】

動作１７１５において、ルータ（例えば、当該ルータ上のＦＦＮモジュール）は、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。高速障害通知メッセージは、受信側ルータに、ＳＰＴ選択ルートノード算出に基づくＳＰＴを用いてマルチキャスト高速フラッディング処理が実行されるべきであることを示す。当該処理は、高速障害通知をマルチキャストすることを含み得る。一実施形態において、高速障害通知メッセージは、マルチキャスト高速障害通知専用のマルチキャストアドレスの宛先アドレスを有する。マルチキャストの決定及び結果として生じるルータによる高速障害通知メッセージの如何なるマルチキャストも、アプリケーション層がルーティングテーブル及び／又は転送テーブルを更新することとは独立に発生する。従って、高速障害通知メッセージは、受信側ルータに、高速障害通知メッセージを回線レートでマルチキャストすること、並びにネットワーク障害を反映するためにそれらのルーティングテーブル及び／又は転送テーブルを更新することの双方を示す。

【0108】

フローは動作１７１５から動作１７２０に移り、ルータは、マルチキャスト高速障害通知専用のマルチキャストグループアドレスにパケットを送る。フローは次いで動作１７２５に移り、ルータは、そのルーティングテーブル及び／又は転送テーブルを適当に更新して、障害を反映する（例えば、ＩＧＰモジュールは、そのルーティングテーブル及び／又は転送テーブルを適当に更新する）。

【0109】

動作１７２５は、幾つかの実施形態において、動作１７１５及び／又は１７２０の前に又は同時に開始されてもよい。ただし、上記更新は、典型的には、高速障害通知メッセージが生成され及び送信される後までは完了されないことが理解されるべきである。ルータは、高速障害通知メッセージを生成し及び送信する前にルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0110】

図１８は、一実施形態に係る、ＳＰＴ選択ルートノードベースのＦＦＦＣアプリケーションにおいてマルチキャスト高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作１８１０において、ルータは、ネットワーク障害に関する情報を含むマルチキャスト高速障害通知メッセージを受信する。例えば、当該ルータのＦＦＮモジュールは、マルチキャスト高速障害通知メッセージを受信する。高速障害通知メッセージは、ルータに、ＳＰＴ選択ルートノードベースのマルチキャスト高速フラッディング処理が実行されるべきであることを示す。当該処理は、（上記のＳＰＴ選択ルート処理に基づく双方向マルチキャストツリーによって示される）他のインタフェースに高速障害通知をマルチキャストすることを含む。フローは動作１８１０から動作１８１５に移る。

【0111】

動作１８１５において、ルータ（たとえば、ルータのＦＦＮモジュール）は、（上記のＳＰＴ選択ルート処理に基づいて生成される）そのデータプレーンにおける双方向マルチキャストツリーによって示される他のルータに、高速障害通知メッセージをマルチキャストする。双方向マルチキャストツリーにおいて示されるルータから下流にマルチキャストの受け手（例えば、別のルータ）が存在しない場合、当該ルータはパケットをマルチキャストしないことが理解されるべきである。一実施形態においては、ループ回避処理（例えば、ＲＰＦチェック）も実行され得る。フローは動作１８１５から動作１８２０に移り、高速障害通知メッセージは、ルーティングプロトコルモジュールに送られる。例えば、ルータのＦＦＮモジュールは、高速障害通知をさらなる処理のために当該ルータ上のＩＧＰモジュールに転送する。フローは次いで動作１８２５に移り、ルーティングプロトコルモジュールは、ネットワーク障害を反映するためにルーティングテーブル及び／又は転送テーブルを適当に更新する。動作１８２０及び／又は１８２５は、幾つかの実施形態において、動作１８１５の前に又は同時に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージのマルチキャスト後まで完了されないことが理解されるべきである。ルータは、高速障害通知メッセージをマルチキャストする前に、ルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。

【0112】

ＰＩＭ双方向マルチキャスト配信ツリー高速障害通知メッセージフラッディング
一実施形態において、高速障害通知メッセージのための伝達メカニズムは、ＰＩＭ（Protocol Independent Multicast）プロトコルを用いて構築される双方向マルチキャスト配信ツリーを用いる。構築された双方向マルチキャスト配信ツリーは、高速障害通知メッセージ専用である。特定の実施形態において、双方向ＰＩＭ（ＢＩＤＩＲ−ＰＩＭ：bidirectional PIM）プロトコルが用いられて、高速障害通知メッセージの高速フラッディングのための双方向マルチキャストツリーが確立される。しかしながら、他の実施形態においては、ＰＩＭプロトコルの他の変形例（例えば、ＰＩＭ−ＡＳＭ（Any-Source Multicast）、ＰＩＭ−ＳＳＭ（Source-Specific Multicast））が用いられて、高速障害通知メッセージの高速フラッディングのためのマルチキャストツリーが構築される。

【0113】

一実施形態においては、専用のマルチキャストアドレスが定義され、高速障害通知メッセージフラッディングのために用いられる。この専用のマルチキャストアドレスは、高速フラッディングのための高速障害通知メッセージを識別するために用いられる。ネットワークにおける参加している各ルータは、ＢＩＤＩＲ−ＰＩＭプロトコルの実装を含み、当該ＢＩＤＩＲ−ＰＩＭプロトコルを設定し及び実行して、双方向マルチキャストツリーを生成し、当該マルチキャストツリーがルータのデータプレーンにダウンロードされる（例えば、１つ以上のラインカードにインストールされる）ようにする。ＢＩＤＩＲ−ＰＩＭプロトコルは、双方向マルチキャストツリーを構築する際に、ルーティングプロトコル（例えば、ＩＧＰモジュール）から得られる情報を用いる。双方向マルチキャストツリーは、高速障害通知メッセージを広める際に用いられる。また、各ルータは、マルチキャストグループに加えるための専用のマルチキャストアドレスを追加する。高速障害通知メッセージは、ダウンロードされた双方向マルチキャストツリーを用いる通常のマルチキャストプロトコルを用いて転送される。

【0114】

図１９は、一実施形態に係る、ネットワーク障害を検出して、ＰＩＭプロトコルを用いて構築される双方向マルチキャストツリーを用いてマルチキャスト高速障害通知メッセージを用いるドメインワイドなＦＦＦＣを開始するルータによって実行される例示的な動作を図示する。動作１９１０において、ルータは、ネットワーク障害を検出する。一実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングが用いられて、障害が検出される。別の実施形態においては、双方向転送検出（ＢＦＤ）が用いられて、障害が検出される。別の実施形態において、レイヤ２のリンクイベントモニタリング及びシグナリングとＢＦＤとの組み合わせが用いられて、障害が検出される。フローは次いで動作１７１５に移る。

【0115】

動作１９１５において、ルータ（例えば、当該ルータ上のＦＦＮモジュール）は、ネットワーク障害に関する情報を含む高速障害通知メッセージを生成する。高速障害通知メッセージは、受信側ルータ上で高速フラッディングイベントとして扱われるべきである。高速障害通知メッセージは、受信側ルータに、ＰＩＭプロトコルを用いて構築される双方向マルチキャストツリーを用いてマルチキャスト高速フラッディング処理が実行されるべきであることを示す。当該処理は、高速障害通知をマルチキャストすることを含み得る。一実施形態において、高速障害通知メッセージは、マルチキャスト高速障害通知専用のマルチキャストアドレスの宛先アドレスを有する。アプリケーション層がネットワーク障害を反映するためにルーティングテーブル及び／又は転送テーブルを更新することとは独立に、高速障害通知メッセージは、（転送が発生すべき場合には）それらのルータによって転送されるべきである。従って、高速障害通知メッセージは、受信側ルータに、高速障害通知メッセージを回線レートでマルチキャストすること、並びにネットワーク障害を反映するために当該受信側ルータのルーティングテーブル及び／又は転送テーブルを更新することの双方を示す。

【0116】

フローは動作１９１５から動作１９２０に移り、ルータは、マルチキャスト高速障害通知専用のマルチキャストグループアドレスにパケットを送る。フローは次いで動作１９２５に移り、ルータは、障害を反映するためにそのルーティングテーブル及び／又は転送テーブルを適当に更新する（例えば、ＩＧＰモジュールが、そのルーティングテーブル及び／又は転送テーブルを適当に更新する）。

【0117】

動作１９２５は、幾つかの実施形態において、動作１９１５及び／又は１９２０の前に又は同時に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージが生成され及び送信される後まで完了されないことが理解されるべきである。ルータは、高速障害通知メッセージを生成し及び送信する前に、ルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。従って、高速障害通知メッセージを生成し及び送信することは、ルーティングテーブル及び転送テーブルの更新とは独立に実行される。

【0118】

図２０は、一実施形態に係る、ＰＩＭプロトコルを用いて構築される双方向マルチキャストツリーを用いるＦＦＦＣアプリケーションにおいてマルチキャスト高速障害通知メッセージを受信するルータによって実行される例示的な動作を図示するフロー図である。動作２０１０において、ルータは、ネットワーク障害に関する情報を含むマルチキャスト高速障害通知メッセージを受信する。例えば、当該ルータのＦＦＮモジュールは、高速障害通知メッセージを受信する。また、高速障害通知メッセージは、ルータに、マルチキャスト高速フラッディング処理が実行されるべきであることも示す。当該処理は、（ＰＩＭプロトコルを用いて構築される双方向マルチキャストツリーによって示される）他のインタフェースに高速障害通知をマルチキャストすることを含み得る。フローは動作２０１０から２０１５に移る。

【0119】

動作２０１５において、ルータ（例えば、ルータのＦＦＮモジュール）は、（ＰＩＭプロトコルによって生成される）そのデータプレーンにおける双方向マルチキャストツリーによって示される他のルータに高速障害通知メッセージをマルチキャストする。双方向マルチキャストツリーにおいて示されるルータから下流にマルチキャストの受け手（例えば、別のルータ）が存在しない場合にルータはパケットをマルチキャストしないことが理解されるべきである。一実施形態において、ループ回避処理（例えば、ＲＰＦチェック）も実行され得る。フローは動作２０１５から動作２０２０に移り、高速障害通知メッセージは、ルーティングプロトコルモジュールに送られる。例えば、ルータのＦＦＮモジュールは、さらなる処理のためにルータ上のＩＧＰモジュールに高速障害通知を転送する。フローは次いで動作２０２５に移り、ルーティングプロトコルモジュールは、ネットワーク障害を反映するためにルーティングテーブル及び／又は転送テーブルを適当に更新する。動作２０２０及び／又は２０２５は、幾つかの実施形態において、動作２０１５の前に又は同時に開始されてもよい。ただし、上記更新は、典型的に、高速障害通知メッセージのマルチキャスト後まで完了されないことが理解されるべきである（メッセージがマルチキャストされるべき場合）。ルータは、高速障害通知メッセージをマルチキャストする前に、ルーティングテーブル及び転送テーブルの更新が終了されるまで待たないことも理解されるべきである。

【0120】

高速障害通知メッセージをフラッディングするためのＰＩＭベースの解決策は、現在のところ多くのルータがＰＩＭを実行するケイパビリティを有しているため、書き込まれる必要がある追加的なコードの量がほとんど最小限で済むという利点を有する。また、（レイヤ２のメカニズムである）高速障害通知メッセージを広めるためのブリッジベースのフラッディング技法と比較して、ＰＩＭベースの解決策は、レイヤ３のメカニズムを用いており、レイヤ３のルーティングアプリケーション／転送アプリケーションにとってより容易であると見なされ得る。しかしながら、ＰＩＭベースの解決策は、ネットワークにおけるツリー状態を維持するために、ルータ設定及びシグナリングにおけるオーバーヘッドを増加させてしまう。また、ＰＩＭベースの解決策は、ブリッジングよりも複雑であり、ネットワーク障害のハンドリングの観点からはロバスト性がより低くなり得る。

【0121】

高速障害通知メッセージのフォーマット
一実施形態において、本明細書において説明される高速障害通知メッセージは、ＩＧＰに依存しないメッセージフォーマットを用い、レイヤ２プロトコルのパケットであり、データトランスポート層によって発行される。前述の通り、高速障害通知メッセージについてのメッセージフォーマットは、既存のＩＧＰ ＰＤＵパケットフォーマットを用い得る。例えば、ＩＧＰがＯＳＰＦである場合には、崩壊した隣接関係（ルータが少ないあるリンク）を反映するＯＳＰＦルータＬＳＡ（link state advertisement）は、高速障害通知メッセージとして用いられ、特別な変形無しにルータに高速フラッディングされることができる。既存のＩＧＰ ＰＤＵパケットフォーマットを用いることは、当該フォーマットが既に存在し（追加的なデータフォーマットが必要とされず）、同じＬＳＡが到来する際に低速のフラッディングに自然に一体化するという利点を有する。しかしながら、既存のＩＧＰ ＰＤＵパケットフォーマットを用いることは、当該フォーマットがＩＧＰプロトコルごとに異なり（例えば、ＯＳＰＦについての既存のＩＧＰ ＰＤＵパケットフォーマットは、ＩＳ−ＩＳのそれとは異なる）、メッセージフォーマットが典型的には制御プレーンに存在するＩＧＰモジュールによって発信されるか、又はさもなければ事前の演算を必要とし、データプレーン（トランスポート層）のディスパッチングメカニズムを依然として必要とするという不利益も有する。

【0122】

本明細書において説明される独立したメッセージフォーマットは、ＩＧＰに依存せず（従って、同じメッセージフォーマットが、異なるＩＧＰの実装について用いられ得る）、データプレーン（データトランスポート層）によって発行され、トリガリングポイントにより近くなる結果、イベントパスごとに短くなるという利点を有する。

【0123】

独立したメッセージフォーマットは、ＴＬＶベースである。ＴＬＶは、基礎となる高速フラッディングトランスポートの要件に依存して、ＩＰパケットにパックされても又はパックされなくてもよい。図２１は、一実施形態に係る、高速障害通知メッセージについての例示的な独立したメッセージフォーマットを図示する。例示的な高速障害通知メッセージフォーマット２１１０は、メッセージが高速障害通知メッセージであることを示すタイプフィールド２１１５、長さフィールド２１２０、並びに、複数の可変値フィールド、即ち、広告ルータＩＤフィールド２１２５、広告リンクＩＤフィールド２１３０、ピアルータＩＤフィールド２１３５、及びピアリンクＩＤフィールド２１４０を含む。これらのフィールドは、高速障害通知メッセージを発信するルータ及びリンク、並びに障害を経験しているルータ及びリンクを識別する。ＴＬＶベースの独立したメッセージフォーマットは、将来的な開発及び拡張を可能にする。

【0124】

独立したメッセージフォーマットは、高速障害通知メッセージのハンドリングがＩＧＰ処理に依存しないことを可能にする。ＩＧＰ非依存のフォーマットを用いる高速障害通知メッセージを受信すると、ルータは、当該メッセージを、本明細書において説明されるイベントフレームワークにおけるローカルイベントとして扱う。一実施形態において、独立したメッセージフォーマットを用いる高速障害通知メッセージがバグ若しくは他のエラー状態又はサービス攻撃の拒否に起因して誤ってフラッディングされる場合を防ぐために、タイムアウト機構が用いられる。タイマが満了すると、ルータは、システムをロールバックして、エラーが長続きせず自己回復可能であることを確実にする。

【0125】

一実施形態において、高速障害通知メッセージについての独立したメッセージは、通例の通知メッセージに取って代わらない。従って、プロトコル非依存の高速障害通知メッセージが本明細書において説明されるＦＦＦＣアーキテクチャを介して最初に転送され、ネットワーク障害を反映する通例のＩＧＰフラッディングが後に続く。

【0126】

プロトコル非依存なメッセージフォーマットを用いる高速障害通知を受信した後、当該メッセージは、処理のためにＩＧＰモジュールに送られるであろう。例えば、ＩＧＰモジュールは、そのルーティングトポロジーデータベース（例えば、そのＬＳＤＢ）を適宜更新し、（実装されている場合には）セーフティタイマをキャンセルし、最短パス優先（ＳＰＦ）処理を更新後のデータベースに実行して、ルーティングテーブル及び／又は転送テーブルを適宜更新すべきかを判定するであろう。ルータは、用いられるトランスポートに依存して、高速障害通知メッセージも拡散させ得る。

【0127】

本明細書において説明されるように、ＦＦＦＣアーキテクチャは、ネットワーク障害通知メッセージを転送することをアプリケーション層から切り離し、データトランスポート層上へ移行させる。結果として、ネットワークワイドな収束のために必要な時間を低減するネットワーク障害通知メッセージを転送するために制御プレーンとデータプレーンとの間のインタラクションは必要とされない。これは、ネットワーク障害が起きた場合におけるネットワークダウンタイムを最小限にする。

【0128】

本明細書において説明されるように、動作は、ある動作を実行するように構成され又は所定の機能性を有する特定用途向け集積回路（ＡＳＩＣ）などのハードウェアの特定の構成、又は非一時的な（non-transitory）コンピュータ読取可能な媒体において具現化されるメモリに記憶されるソフトウェア命令を指し得る。従って、図面に示される技法は、１つ以上の電子デバイス（例えば、ルータ）上に記憶され及び実行されるコード及びデータを用いて実装されることができる。そのような電子デバイスは、非一時的なコンピュータ読取可能な記憶媒体（例えば、磁気ディスク、光ディスク、ＲＡＭ、ＲＯＭ、フラッシュメモリデバイス、相変化メモリ）、及び一時的なコンピュータ読取可能な通信媒体（例えば、搬送波、赤外線信号、デジタル信号といった、電気的、光学的、音響的又は他の形態の伝搬信号）といったコンピュータ読取可能な媒体を用いて、コード及びデータを記憶し並びに（内部的に、及び／又は、ネットワーク上で他の電子デバイスと）通信する。また、そのような電子デバイスは、典型的に、１つ以上の記憶装置（非一時的な機械読み取り可能な記憶媒体）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、並びにネットワーク接続といった１つ以上の他のコンポーネントに結合される１つ以上のプロセッサのセットを含む。プロセッサのセットと他のコンポーネントとの結合は、典型的に、１つ以上のバス及び（バスコントローラとも称される）ブリッジを介する。従って、所与の電子デバイスの記憶装置は、典型的に、当該電子デバイスの１つ以上のプロセッサのセット上での実行のためのコード及び／又はデータを記憶する。当然ながら、本発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの様々な組み合わせを用いて実装され得る。

【0129】

図面におけるフロー図は本発明のある実施形態によって実行される動作の特定の順序を示すが、そのような順序は例示である（例えば、別の実施形態は、当該動作を異なる順序で実行し、ある動作を組み合わせ、ある動作を重複させる等し得る）ことが理解されるべきである。

【0130】

本発明は幾つかの実施形態の観点から説明されたが、本発明が説明された実施形態に限定されず、添付の特許請求の範囲の思想及び範囲内における変形及び変更と共に実施をされることができることを当業者は認識するであろう。従って、説明は限定ではなく例示として考慮されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】