JP4033769B2 - ルータ及びルーティング・プロトコル冗長性 - Google Patents

Description

本発明は、ネットワーク及びネットワーク装置の分野に関する。更に具体的には、本発明は、ネットワーク・ルータ及びルーティング・プロトコルに関する。具体的には、本発明は、ルータ及びルーティング・プロトコル冗長性に関する。

ネットワークは、相互に接続された装置の集合であって、ユーザがリソース及びデータにアクできるようにする。通常のタイプのネットワーク装置は、サーバ、ルータ、ブリッジ、スイッチ、ゲートウェイ、及びハブを含む。よく知られたネットワークはインターネットである。インターネットは相互に接続されたネットワークの世界規模システムであって、インターネット・プロトコル（ＩＰ）を走らせてデータ（例えばパケット）を転送する。パケットは、インターネット上の多数のネットワーク境界を越えて行き先へ到着することができるので、ＩＰはルーティング及び転送機能を提供するレイヤー（layer、層）「３」サービスを含み、パケットが最適経路を使用して行き先へ到着できるようにする。

ＩＰレイヤー３サービスを提供する通常のネットワーク装置はルータである。ルータは、その現在のネットワーク・ビューに基づき最適経路を決定することによってパケットを回送し、最適経路を使用して、ネットワーク境界を越えて行き先へパケットを転送する。ルータは、そのネットワーク・ビューに基づいて、ルータに知られた利用可能ルートのルーティング・テーブルを生成及び維持する。ルータは、ルーティング・テーブルを使用して転送情報テーブル（ＦＩＢ）を作り出す。ＦＩＢは、ルータがパケットを行き先へ転送するために使用するルートのテーブルである。

ルータは、ネットワークの整合したビュー（即ち、整合ＦＩＢ）を維持するため、ルーティング・プロトコルを使用して他のルータと情報を交換する。パケットを適正に転送するために、各々のルータはネットワーク上の他のルータと一緒に整合ＦＩＢを有しなければならない。即ち、整合しない転送情報テーブル（ＦＩＢ）を有するルータは、ネットワークを介して予測可能な方法でパケットを転送しないであろう。従って、ルーティング・ループ又はパケットの不適正なルーティングが起こるであろう。

ここで、ネットワークで起こる重大な問題は、ルータ障害である。ルータは、多数の理由、例えば、誤った構成、ハッカーの攻撃、ハードウェア障害、及びソフトウェア障害によって故障する。そのような障害は予測不可能である。都合の悪いことに、ルータ障害は、ネットワークのトポロジを変化させる原因となる。特に、トポロジは、或るリンク又はルートが消滅したために変化する。更に、ノードへ到達できないか、ネットワークを介して情報を伝搬できないために、ルーティング・プロトコル情報が失われる。更に、アドレスへ到達不可能であるために、パケットは行き先に到着できないかもしれない。

こうして、ルータ障害は、多くの問題、例えば、サービス停止、サービス低下（非最適条件ルーティング）、及び長時間のルーティング・テーブル収斂時間に起因するサービス停止を起こす。故障したルータは、他のルータに非最適経路を使用してパケットを転送させ、サービスの低下を起こす。なぜなら、パケットは、より多くの時間を費やして行き先へ到着するからである。故障したルータは、更に、そのピアを介して、そのピア及びネットワーク上の他のルータにルーティング・テーブルを更新させる（「収斂」）。これは、そのような収斂を実行するためのサービス停止又は低下を生じる。

例えば、もしルータが故障し、ピア・ノード又は隣接ルータのルーティング・プロトコルが故障を認識すれば、ルーティング・プロトコルは、ネットワークを介して、故障したルータを知らせ、それに従ってルーティング・テーブルが更新されるようにする。その結果、ネットワークが完全なサービスを再開する前に、作動ルータ内のルーティング・テーブルを更新して相互に整合したＦＩＢを生成することに起因するサービスの停止又は低下が存在する。このネットワーク再構成は、全体のネットワークが回復する前に、数秒、数分、又は数時間を要するかもしれない。きわめて重大なサービスについては、そのような事態は許容されない。

システムの利用可能性を増加するため、ルータ障害を処理する方法は、ハードウェア冗長性を実現することである。このタイプの冗長性は、通常、レイヤー２冗長性と呼ばれる。レイヤー２冗長性システムは、冗長的なライン・カード、ポート、又はコントローラ・カードを含む。もしライン・カード、ポート、又はコントローラ・カードが故障すると、冗長ライン・カード、ポート、又はコントローラ・カードは、動作を再開することができる。しかし、レイヤー２冗長性の欠点は、リアルタイムのルーティング・プロトコル冗長性を提供しないことである。例えば、ルーティング・プロトコルによって生成される多数のソフトウェア状態は、冗長ハードウェアの中にリアルタイムで維持されず、これはプロトコル・セッションのドロップを生じる。従って、レイヤー２冗長性システムにおいて、プロトコル・セッションがドロップされ、これはネットワーク・トポロジの変化、従ってサービス停止又はサービス低下を起こす。

ルータ障害を処理する他の方法は、バックアップ・ルータを備えることである。そのようなスキームは、通常、バーチャル・ルータ冗長性プロトコル（ＶＲＲＰ）と呼ばれる。ＶＲＲＰスキームにおいて、もし、メイン・ルータが故障したことをピア・ルータが認識すると、ピア・ルータはバックアップ・ルータとの通信を開始する。ＶＲＲＰの欠点は、バックアップ・ルータへの切り替えに長い時間（グリッチ・タイム）を取ることである。ＶＲＲＰの他の欠点は、故障したルータのピア・セッションが破壊又は切断され、バックアップ・ルータによって再開されることができず、サービス障害を起こすことである。

ＶＲＲＰの他の欠点は、全てのルーティング・セッションが切断されるか、バックアップ・ルータが、メイン・ルータの同じ隣接ルータと別個のピア・セッションを有し、ルーティング処理に著しいオーバヘッドを生じることである。いずれにせよ、メイン・ルータが故障したとき、メイン・ルータのピア・セッションがドロップされるので、収斂時間が必要となる。

ネットワーク装置のサービス停止又は低下を低減し、従ってネットワーク装置のソフトウェア及びハードウェア障害に起因するネットワークのサービス利用可能性を向上するルータ及びルーティング・プロトコル冗長性が開示される。１つの実施形態において、ネットワーク装置、例えばルータは、アクティブ・コントローラ・システム及びスタンバイ・コントローラ・システムを有する冗長性プラットフォームを含む。ルーティング・プロトコルの状態変化は、アクティブ・コントローラ・システムによって受信又は生成される。受信又は生成されたルーティング・プロトコル状態変化は、スタンバイ・コントローラ・システムへ複写される。ルーティング・プロトコルの状態変化を複写することによって、スタンバイ・コントローラ・システムは、障害がアクティブ・コントローラ・システムで発生する場合に、ネットワーク装置のためにルーティング・プロトコル・セッションを維持することができる。更に、ルーティング・プロトコルによって作り出された動的変化を処理するため、ルーティング・プロトコルの状態はリアルタイムで維持される。

本発明の他の特徴及び利点は、添付の図面及び以下の詳細な説明から明らかになるであろう。

本発明は例として示され、添付図面の図形によって制限されることを意図されず、そこでは、類似の参照記号は類似の要素を示す。

ネットワーク装置のソフトウェア及びハードウェア障害に起因するネットワーク装置のサービスの停止又は低下を低減し、従ってネットワークのサービス利用可能性を向上するルータ及びルーティング・プロトコル冗長性が説明される。１つの実施形態において、ネットワーク装置、例えば、ルータは、アクティブ・コントローラ・システム及びスタンバイ・コントローラ・システムを有する冗長性プラットフォームを含む。ルーティング・プロトコルの状態変化は、アクティブ・コントローラ・システムによって受信又は生成される。受信又は生成されたルーティング・プロトコルの状態変化は、スタンバイ・コントローラ・システムへ複写される。ルーティング・プロトコルの状態変化を複写することによって、スタンバイ・コントローラ・システムは、障害がアクティブ・コントローラ・システムで発生する場合に、ネットワーク装置のためにルーティング・プロトコル・セッションを維持することができる。更に、ルーティング・プロトコルによって作り出された動的変化を処理するため、ルーティング・プロトコルの状態がリアルタイムで維持される。

ここで説明される冗長性手法によって、故障したネットワーク装置は、短い時間でサービスへ復帰し、サービスの停止を回避することができる。冗長性手法によって、更に、バックアップ又はスタンバイ・コントローラ・システムは、故障したネットワーク装置を、故障前のアクティブ・コントローラ・システムの作業状態でサービスするように復帰させることができる。冗長性手法は、更に、ネットワーク装置のピア・ノードが、ネットワーク装置の障害を認識しないようにする。冗長性手法は、更に、アクティブ・コントローラ・システムからスタンバイ・コントローラ・システムへ切り替わる場合に、プロトコル・セッションをリアルタイムで維持することによって、ルーティング・プロトコル・セッションがドロップされないようにする。冗長性手法は、更に、スタンバイ・コントローラ・システムの中にネットワークの整合したビューを維持する。

以下の説明において、冗長性手法は、ネットワーク・ルータ及びルーティング・プロトコルに関して説明される。しかし、ここで説明される冗長性手法は、特定のタイプのネットワーク装置に限定されることを意図されず、ハードウェア及びソフトウェア障害を有するか、ルーティング・プロトコル機能、例えば、ネットワーク・スイッチ、ネットワーク光学スイッチ、ブリッジ、ハブ、又はゲートウェイを実行することができる他のタイプのネットワーク装置を使用して実現されることができる。

更に、以下の説明において、ルータの冗長性とは、ルータがアクティブ・コントローラ・システムのバックアップ・コントローラ・システム（即ち、スタンバイ・コントローラ・システム）を有することを意味する。スタンバイ・コントローラ・システムは、アクティブ・コントローラ・システムが故障した場合に、アクティブ・コントローラ・システムのために動作を再開することができる。更に、ルーティング・プロトコル冗長性とは、アクティブ・コントローラ・システム上で走っているプロトコル・セッションをスタンバイ・コントローラ・システムの中に維持し、アクティブ・コントローラ・システムと整合したルーティング及び転送情報をスタンバイ・コントローラ・システムの中に維持することを意味する。

ルータ及びルーティング・プロトコル冗長性の概観
ルータ冗長性を有する例示的ネットワーク
図１は、本発明が実施されることのできる例示的ネットワーク１００を示す。図１を参照すると、例示的ネットワーク・システムは、複数のピア・ノード１０２Ａ及び１０２Ｂと相互接続されて冗長性プラットフォーム９００を有するノード１０４（「冗長ノード１０４」）を含む。例示のため、３つのノードが示されるが、ネットワーク１００は任意数のノードを含むことができる。ピア・ノード１０２Ａ及び１０２Ｂとは、冗長ノード１０４との「セッション」又は「論理接続」を有するノードである。

１つの実施形態において、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、ネットワーク装置、例えば、ＩＰレイヤー３サービスを実行しているネットワーク・ルータを表す。代替的に、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、ＩＰレイヤー３サービス、又はそれより高いレイヤーレベル・サービスであってアプリケーション・サービスまでを実行することのできる他のタイプのネットワーク装置、例えば、スイッチ、ブリッジ、ハブ、又はゲートウェイであってよい。他の実施形態において、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）サービスを実行することができる。

ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、通常、自立システム（ＡＳ）と呼ばれて同じ管理権限及び制御のもとにある１つの特定のネットワーク・グループを介して情報（即ち、パケット）を転送するために使用されるネットワーク・ルータを表すことができる。従って、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、ゲートウェイ内プロトコル（ＩＧＰ）を走らせて、ＡＳの内部で情報を交換する「内部ルータ」を表すことができる。

ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、もしＩＧＰとして動作していれば、ルーティング・プロトコル、例えば、中間システム−中間システム・プロトコル（ＩＳ−ＩＳ）、オープン最短経路第一プロトコル（ＯＳＰＦ）、及びルーティング情報プロトコル（ＲＩＰ）を動作させることができる。ＩＳ−ＩＳプロトコル及びＯＳＰＦプロトコルは、リンク状態プロトコルである。リンク状態プロトコルはリンク状態パケットを使用して、ネットワークの整合したビューを維持する。ＲＩＰプロトコルは、距離ベクトルに基づく単純なプロトコルで、最短経路の計算を使用する。

代替的に、ノード１０２Ａ及び１０２Ｂ並びに１０４は、ＡＳの間で情報を転送するために使用されるネットワーク・ルータを表すことができる。その場合、ルータは、「外部ルータ」と呼ばれ、外部ゲートウェイ・プロトコル（ＥＧＰ）を走らせる。ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、もしＥＧＰとして動作していれば、ルーティング・プロトコル、例えば、ボーダー・ゲートウェイ・プロトコル（ＢＧＰ）を動作させることができる。ＢＧＰプロトコルは、信頼性のあるトランスポート・プロトコル、例えば、トランスポート・コントロール・プロトコル（ＴＣＰ）を介して接続情報を交換し、エラー制御能力を有しない。しかし、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、内部ルータ又は外部ルータの任意の組み合わせを表すことができ、任意数のルータがネットワーク１００の中で表されることができる。

従って、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、整合したルーティング及びルーティング・プロトコル状態情報を維持することができる。もしルートが更新されると、そのルートはピア・ノードで更新され、ネットワークの整合したビューが維持されなければならない。１つの実施形態において、ノード１０２Ａ及び１０２Ｂ、並びに冗長ノード１０４は、「挨拶」パケットを送信することによって隣接ノードを決定することができる。もし確立されたピア・ノードが或る時間間隔の間に「挨拶」パケットに応答しなければ、ピア・ノードは動作不能又は「故障」と考えられる。

従って、冗長ノード１０４は冗長性プラットフォームを有する特殊なタイプのノードである。この冗長性プラットフォームは、アクティブ・コントローラ・システム（アクティブ・カード９１０）及びスタンバイ・コントローラ・システム（スタンバイ・カード９５０）を有し、ノード内の障害がピア・ノード１０２Ａ及び１０２Ｂによって認識されないようにすることができる。更に、もしアクティブ・コントローラ・システムが故障すると、スタンバイ・コントローラ・システムはピア・ノードとのプロトコル・セッションを再開し、アクティブ・コントローラ・システムが故障したことをピア・ノードが認識しないようにすることができる。例えば、もしノード１０２Ａが「挨拶」パケットを冗長ノード１０４へ送信し、それが何らかの理由で失われ、切り替えが起こり、ノード１０２Ａが挨拶パケットを再送信すると、スタンバイ・コントローラ・システムは、冗長ノード１０４のために動作を再開し、タイムアウト期間の前に、再送信された挨拶パケットの受信通知を送信することができる。従って、ノード１０２Ａはスタンバイ・システムへの切り替えを認識しない。

１つの実施形態において、ノード１０４は、図９で示されるような冗長性プラットフォーム９００を有するルータを表す。冗長性プラットフォーム９００は、アクティブ・カード９１０に障害が存在する場合に動作を再開するため、アクティブ・カード９１０及びスタンバイ・カード９５０を含む。アクティブ・カード９１０及びスタンバイ・カード９５０は、それらの中で動作しているハードウェア及びソフトウェア・モジュールを含む。１つの実施形態において、アクティブ・カード９１０及びスタンバイ・カード９５０の双方は、可能性としてソフトウェアの異なったバージョン又は同じバージョンを走らせることができる。以下で更に詳細に説明するように、冗長性プラットフォーム９００は、ノード１０４のためにルータ及びルーティング・プロトコル冗長性をサポートする。この冗長性は、ピア・ノードが障害を認識しないようにし、冗長ノード１０４のためにピア・ノードとのルーティング・プロトコル・セッションを維持する。

例示的アーキテクチャレイヤーモデル
図２は、１つの実施形態に従って図１で示されるノードによって使用されることのできるアーキテクチャレイヤーモデル２００を示す。１つの実施形態において、アクティブ・カード９１０及びスタンバイ・カード９５０は、アーキテクチャレイヤーモデル２００を使用して動作する。アーキテクチャレイヤーモデル２００は、ネットワーク通信の標準７レイヤー参照モデルに基づくことができる。説明目的のために、アーキテクチャレイヤーモデル２００は、ＩＰルータが動作することのできる異なったレイヤーの１つの実施形態を表す。

図２を参照すると、アーキテクチャレイヤーモデル２００は、物理レイヤー２０２、リンクレイヤー２０４、ＩＰレイヤー２０６、通信制御プロトコル（ＴＣＰ）レイヤー２０８、ユーザ・データグラム・プロトコル（ＵＤＰ）レイヤー２０８、インターネット制御メッセージ・プロトコル（ＩＣＭＰ）２１８、ボーダー・ゲートウェイ・プロトコル（ＢＧＰ）レイヤー２２６、ルーティング・インターネット・プロトコル（ＲＩＰ）レイヤー２２２、開放最短経路第一（ＯＳＰＦ）プロトコルレイヤー２２４、中間システム−中間システム（ＩＳ−ＩＳ）プロトコルレイヤー２１４を含むルーティング・プロトコルレイヤー２２０、ソケットレイヤー２１０、アプリケーションレイヤー２１２を含む。ルーティング・プロトコル２２０は、転送情報テーブル（ＦＩＢ）２１６を生成するためルーティング・テーブルを維持する。ＦＩＢ２１６は、ＩＰレイヤー２０９及びリンクレイヤー２１６によって使用される。前記のレイヤーはネットワークの中でノードへサービスを提供する。

物理レイヤー２０２は、物理リンクを使用してノード間でデータを移動するサービスを提供する。リンクレイヤー２０４は、物理リンク上で転送されているデータを処理するサービスを提供する。ＩＰレイヤー２０９（「ＩＰレイヤー３」）は、物理レイヤー及びリンクレイヤーの上でルーティング及び転送サービスを提供する。ＴＣＰレイヤー２０８は、エラー・チェックを実行し全てのデータが到着したことを確認することによって、完全なデータ転送を保証するサービスを提供する。ＴＣＰレイヤー２０８はＩＰレイヤー３の上で動作する。従って、ネットワーク内のノードは、ＩＰレイヤー３サービスの上でＴＣＰサービスを使用してデータを送信することができる。

ＩＣＭＰレイヤー２１８は、ＩＰレイヤー２０６の上で走り、その一体的部分である。即ち、ＩＰレイヤー３サービスは本来的に信頼性がなく、データ・パケットはドロップされることがある。従って、ＩＣＭＰレイヤー２１８は、ＩＰレイヤー３サービスのためにメッセージ制御及びエラー報告を提供する。ＵＤＰレイヤー２０９は、ＴＣＰレイヤー２０８によって提供されるサービスへの代替サービスを提供する。特に、ＵＤＰレイヤー２０９は、ＩＰレイヤー３サービスレイヤーの上で走って、データグラムを送信するとき、コネクションレス伝送プロトコルを提供する。即ち、ＵＤＰレイヤー２０９は、エンドツーエンドのエラー検出を提供しない。ソケットレイヤー２１０は、ネットワーク上で走っているノードのアプリケーションレイヤー２１２又はルーティング・プロトコル２２０の間の双方向通信の端点を提供する。アプリケーションレイヤー２１２は、ノード上で走っているアプリケーションを含む。アプリケーションレイヤー２１２は、他のノードのアプリケーションと通信するため、下位のレイヤーを使用することができる。

ルーティング・プロトコル２２０は、最適経路（「ルート」）を決定し、パケットを転送し、ルートへの更新がネットワークを通して整合していることを保証するサービスを提供する。全てのルータからのルーティング更新を分析することによって、ルータはネットワークの詳細なビューを構築することができる。ルーティング・プロトコル２２０の中で、多数のルーティング・プロトコルが動作することができる。例えば、ＢＧＰプロトコル２２６、ＲＩＰプロトコル２２２、ＯＳＰＦプロトコル２２４、及びＩＳ−ＩＳプロトコル２２０は、全てルーティング・プロトコルレイヤー２２０の中で動作することができる。ルーティング・プロトコル２２０は、ＩＰレイヤー２０６によって提供されるレイヤー３サービスの中でデータ（例えば、パケット）を送信するため、ＦＩＢ２１６を使用することができる。

ＢＧＰプロトコル２２６は信頼性のあるルーティング・プロトコルではない。従って、ＢＧＰ２２６は、メッセージ又はパケットの転送を信頼できるものにするため、ＴＣＰ２０８の上で走る。特に、ＢＧＰ２２６はメッセージ又はパケットを再送信せず、ＴＣＰ２０８に依存して、失われたメッセージ又はパケットを処理する。ＲＩＰ２２２は、メッセージ又はパケットを転送するためＵＤＰ２０９を使用する。ＯＳＰＦ２２４及びＩＳ−ＩＳ２１４は、それぞれのルーティング・プロトコルの中に、信頼できるデータ転送メカニズムを有する。ＯＳＰＦ２２４はＩＰレイヤー２０６の上で走り、ＩＳ−ＩＳ２１４はリンクレイヤー２０４のすぐ上で走る。

以下で更に詳細に説明するように、冗長ノード１０４の中で動作しているルーティング・プロトコルは、冗長性プラットフォーム９００と一緒に動作して、ルータ及びルーティング・プロトコル冗長性を実現することができる。冗長性プラットフォーム９００は、リアルタイムのルーティング・プロトコル冗長性を実現するために必要なサポートを提供する。即ち、ルーティング・プロトコルはダイナミックであって、ルートの更新は、ルーティング・プロトコルに依存して規則的又は不規則的時間間隔で起こる。完全な冗長性を実現するため、これらの更新はリアルタイムで維持される必要がある。

例えば、冗長ノード１０４のためにアクティブ・カード９１０の上で走っているＲＩＰ２２２、ＯＳＰＦ２２４、ＢＧＰ２２６、及びＩＳ−ＩＳ２１４のルーティング・プロトコル・セッション状態は、冗長性プラットフォーム９００を使用してスタンバイ・カード９５０の上へリアルタイムで維持されることができる。スタンバイ・カード９５０は、アクティブ・カード９１０が故障した場合に、同じルーティング・プロトコル・セッション状態を再開することができる。更に、ＦＩＢ２１６もスタンバイ・カード９５０の中へ維持され、スタンバイ・カード９５０が冗長ノード１０４のために制御を引き継ぐ場合に、スタンバイ・カード９５０が最新のネットワーク・ビューを有するようにされる。

基本的な冗長性動作
図３は、１つの実施形態に従った冗長ノード１０４の基本的動作３００のフローチャートである。次の動作３００は、図１で示されるようなアクティブ・カード９１０及びスタンバイ・カード９５０を有する冗長ノード１０４によって実現されることができる。説明目的のため、冗長ノード１０４は、ＩＰレイヤー３又はＭＰＬＳサービスを実行することのできるネットワーク・ルータ１０４であり、動作３００は動作３０２から始まる。

動作３０２において、冗長ノード１０４は、アクティブ・カード９１０の現在の状態を、スタンバイ・カード９５０の中に維持する。特に、冗長ノード１０４は、冗長性プラットフォーム９００を使用して、アクティブ・カード９１０の中の現在の構成情報、グローバル情報、ルーティング・テーブル情報、転送テーブル情報、プロトコル・セッション情報、又はデータベース情報を、スタンバイ・カード９５０へ複写又はコピーする。

動作３０４において、アクティブ・カード９１０は障害を検出する。例えば、アクティブ・カード９１０は、冗長ノード１０４の中のハードウェア障害又はソフトウェア障害を検出することができる。それによって、冗長ノード１０４は、アクティブ・カード９１０からスタンバイ・カード９５０へ動作を切り替える。

動作３０６において、スタンバイ・カード９５０は、故障前のアクティブ・カード９１０の現在の状態の動作を再開する。スタンバイ・カード９５０は、故障がピア・ノード１０２Ａ又は１０２Ｂによって認識されないように動作を再開する。図４Ａ〜図７で更に詳細に説明されるように、冗長ノード１０４は、アクティブ・カード９１０のルーティング・プロトコル・セッション状態をスタンバイ・カード９５０の中へリアルタイムで維持し、またプロトコル・セッションがドロップされないようにスタンバイ・カード９５０へ高速で切り替えることによって、障害がピア・ノードによって認識されないようにすることができる。従って、ネットワーク・トポロジ変化は、ネットワークを通して伝搬される必要はなく、収斂時間が低減される。

プロトコル・セッション及びルーティング情報の維持
図４Ａは、アクティブ・カード９１０からスタンバイ・カード９５０へルーティング・プロトコル情報プロトコルを複写する図４００を示す。図９で示されるような冗長性プラットフォーム９００は、ルーティング・プロトコル情報をスタンバイ・カード９５０の中へリアルタイムで維持するサポートを提供する。図４Ａを参照すると、冗長ノード１０４と通信するピア・ノード１０２Ａが示される。冗長ノード１０４は、ピア・ノード１０２Ａと通信しているアクティブ・カード９１０を有する冗長性プラットフォーム９００を含む。冗長ノード１０４は、更に、アクティブ・カード９１０に障害が存在する場合に動作を再開するスタンバイ・カード９５０を含む。

１つの実施形態において、ピア・ノード１０２Ａはプロトコル情報４１５を含む。プロトコル情報４１５は、持続データ４１１、セッション状態４１２、及びルーティング・テーブル４１３を含む。ルーティング・テーブル４１３は、ＦＩＢ４３２を生成するために使用される。プロトコル情報４１５は、アクティブ・カード９１０内のプロトコル情報４０５Ａと整合していなければならない。即ち、ピア・ノード１０２Ａの持続データ４１１、セッション状態４１２、及びルーティング・テーブル４１３の情報は、持続データ４０１Ａ、セッション状態４０２Ａ、及びルーティング・テーブル４０３Ａと整合していなければならない。それによって、スタンバイ・カード９５０は同じ情報を複写されて、冗長性を保証することができる。更に、もしルーティング・テーブル４１３及び４０３Ａが整合していなければ、ピア・ノード１０２Ａ内のＦＩＢ４３２は、アクティブ・カード９１０内のＦＩＢ４２２Ａと整合しないであろう。従って、ピア・ノード１０２Ａは、冗長ノード１０４が異なったネットワーク・ビューを有すると考えるかも知れず、冗長ノード１０４とのルーティング・プロトコル・セッションを破壊することができる。

完全な冗長性を実現するため、アクティブ・カード９１０によってプロトコル情報４０５Ａへ受信又は実行された変更は、スタンバイ・カード９５０内のプロトコル情報４０５Ｂへ複写されなければならない。具体的には、アクティブ・カード９１０によって持続データ４０１Ａ、セッション状態４０２Ａ、及びルーティング・テーブル４０３Ａへ受信又は実行された変更は、スタンバイ・カード９５０内の持続データ４０１Ｂ、セッション状態４０２Ｂ、及びルーティング・テーブル４０３Ｂへ複写される。もし変更が維持されなければ、冗長性は破壊される。

プロトコル情報は、ルーティング・プロトコル、例えば、ＢＧＰ、ＲＩＰ、ＯＳＰＦ、及びＩＳ−ＩＳルーティング・プロトコルへ関連づけられることができる。持続データは、各々のルーティング・プロトコルのために構成情報を含むことができる。構成情報は、性質として永続的である。セッション状態情報は、ノードの上で走っている各々のルーティング・プロトコルのためにルーティング・プロトコル状態変化を含む。セッション状態情報は、性質としてダイナミックであって、規則的又は不規則的時間間隔で変化することができる。例えば、ルーティング・プロトコル状態変化データは、各々のルーティング・プロトコルについて、ノード間の通信規則、ピアから受信された全てのルートのステータス、ピアへ送信された全てのルートのステータス、タイムアウト・パラメータ、全てのピアによって削除されつつあるルートの履歴などに関連した情報を含むことができる。ルーティング・テーブル情報は、各々のルーティング・プロトコルについて、ノードによって知られたルートを含む。ルーティング・テーブル情報は、パケットを転送するために使用されるＦＩＢテーブルを生成するために使用される。

スタンバイ・カード９５０は、アクティブ・カード９１０の上で走っている各々のルーティング・プロトコルに必要な関連情報を移植されるので、もし障害がアクティブ・カード９１０で起こると、スタンバイ・カード９５０は、アクティブ・カード９１０と整合したＦＩＢを使用して、アクティブ・カード９１０のルーティング・プロトコル・セッションを再開することができる。従って、スタンバイ・カード９５０は、アクティブ・カード９１０の同じ状態を使用して、同じプロトコル・セッションを再開することができる。そのような場合、ピア・ノード１０２Ａは、依然としてアクティブ・カード９１０と通信しているものと信じながら、スタンバイ・カード９５０と通信するであろう。それによって、サービス停止が回避される。

図４Ｂは、１つの実施形態に従ってルーティング・プロトコル状態変化情報を複写する動作４５０のフローチャートである。次の動作４５０は、図１で示されるようなアクティブ・カード９１０及びスタンバイ・カード９５０を有する冗長ノード１０４によって実現されることができる。説明目的のために、冗長ノード１０４は、ＩＰレイヤー３又はＭＰＬＳサービスを実行するネットワーク・ルータ１０４であり、動作４５０は動作４５２で始まる。

動作４５２において、ルーティング・プロトコル状態変化情報は、アクティブ・カード９１０によって受信又は生成される。例えば、アクティブ・カード９１０は、持続データ４０１Ａ、セッション状態４０２Ａ、及びルーティング・テーブル４０３Ａへの変化を生成することができる。代替的に、アクティブ・カード９１０は、持続データ４０１Ａ、セッション状態４０２Ａ、及びルーティング・テーブル４０３Ａについて、ピア・ノード１０２Ａから変化を受信することができる。

動作４５４において、アクティブ・カード９１０内で受信又は生成されたルーティング・プロトコル状態変化は、スタンバイ・カード９５０へ複写される。例えば、図９で示されるような冗長性プラットフォーム９００は、アクティブ・カード９１０内の持続データ４０１Ａ、セッション状態４０２Ａ、及びルーティング・テーブル４０３Ａが、スタンバイ・カード９５０内のピア持続データ４０１Ｂ、セッション状態４０２Ｂ、及びルーティング・テーブル４０３Ｂへ複写されるときのサポートを提供する。そのような複写動作は、リアルタイムで実行される。従って、もしアクティブ・カード９５０が故障すれば、スタンバイ・カード９５０は、アクティブ・カード９５０内の同じ情報を使用して、動作を再開することができる。

高速切り替え／障害のスプーフィング
図５〜図７は、冗長性プラットフォーム９００を有するノードが、どのようにしてピア・ノードが障害及び切り替えを認識しないようにするかを示す。ネットワークの残りと整合した持続データ、セッション状態、及びルーティング・テーブル情報を、スタンバイ・コントローラ・システム（スタンバイ・カード９５０）の中に維持することによって、シームレス、円滑、及び高速の切り替えを起こすことができる。切り替えは十分に高速であるから（例えば、数ミリ秒内）、切り替えを実行するため冗長ノード１０４が少し遅延したことをピア・ノードは認識しない。

図５は、１つの実施形態に従って高速切り替えを有するスタンバイ・コントローラ・システムによって動作を再開する図３の動作３０６の詳細を示すフローチャートである。説明目的のために、動作３０６は、動作５０２で始まる。

図５を参照すると、動作５０２において、冗長ノード１０４は、アクティブ・カード９１０からスタンバイ・カード９５０への切り替えを実行する。切り替えは、数ミリ秒内で実行されることができる。切り替え（即ち、「突然の不調」）を実行するための時間は非常に短いので、切り替えが起こったことをピア・ノード１０２Ａは認識しない。動作５０４において、スタンバイ・カード３５０は、プロトコル・セッションを破壊することなくピア・ノード１０２Ａとの動作を再開する。即ち、突然の不調は非常に小さいので、冗長ノード１０４に突然の不調が存在したことをピア・ノード１０２Ａは気づかない。

以下は、高速切り替えを詳細に説明する記述である。ＩＰは、本来的に信頼性がないので、パケットはドロップされる可能性がある。パケットがアクティブ・カード９１０によってピア・ノード１０２Ａから受信され、障害が起こって、アクティブ・カード９１０がパケットの受信を通知しない場合、ピア・ノード１０２Ａはパケットを再送信することができる。この場合、切り替えが存在しても、スタンバイ・カード９５０が、ピア・ノード１０２Ａから再送信されているパケットを受信することができ、そのパケットの受信を通知する。従って、ピア・ノード１０２Ａは、通常のように認識し（即ち、パケットを再送信し、再送信されたパケットへの応答を受信する）、パケットがドロップされても冗長ノード１０４内で障害又は切り替えが起こったとは思わないであろう。

切り替えは迅速に実行されるので、スタンバイ・カード９５０は、ルーティング・プロトコル・セッションを破壊することなく、冗長ノード１０４のために動作を再開することができる。例えば、各々のルーティング・プロトコルはタイムアウト期間を含み、もし或る数のパケットが或る時間内に受信を通知されなければ、セッションを破壊する。その結果、幾つかのパケットが切り替えの間にドロップされても、冗長性プラットフォーム９００を有する冗長ノード１０４に対しては、突然の不調は短い。即ち、セッションが破壊されるか冗長ノード１０４のサービスが停止することなしに、スタンバイ・カード９５０はアクティブ・カード９１０のために動作を再開することができる。

図６Ａの６００は、１つの実施形態に従って障害及び切り替えを認識しないようにピア・ノードをだます線図を示す。ルーティング・プロトコルへのリアルタイム局面が存在するから、冗長ノード１０４へのピア・ノード１０２Ａは、アクティブ・カード９１０によってコミットされているトランザクションが、スタンバイ・カード９５０によってもコミットされることを必要とする。例えば、もしアクティブ・カード９１０がルーティング更新へコミットすれば、そのルーティング更新は、スタンバイ・カード９５０の中でも行われなければならない。もしアクティブ・カード９１０によってコミットされたトランザクションが、スタンバイ・カード９５０によってコミットされず、切り替えが起こると、ピア・ノード１０２Ａは冗長ノード１０４とのセッションを破壊するであろう。なぜなら、スタンバイ・カード９５０は、ピア・ノード１０２Ａと整合したネットワーク・ビューを有しないからである。具体的には、スタンバイ・カード９５０は更新へコミットしなかった。

従って、ピア・ノード１０２Ａが冗長ノード１０４とのセッションを破壊しないようにするため、スタンバイ・カード９５０への切り替えは迅速に実行されなければならず、アクティブ・カード９１０によってコミットされたトランザクションは、スタンバイ・カード９５０によってコミットされなければならない。冗長性プラットフォーム９００を有する冗長ノード１０４は、そのような高速切り替えを実行し、スタンバイ・カード９５０内でトランザクションへコミットして、ピア・ノード１０２Ａがプロトコル・セッションを破壊しないようにすることができる。

図６を参照すると、ピア・ノードからメッセージ（ＭＳＧＡ）を受信するアクティブ・カード９１０が示される。メッセージは、例えば、ノード１０２Ｂが故障し、それに従って１０２Ｂへのルートが更新されなければならないことを冗長ノード１０４へ通知するメッセージであってよい。ノード１０２Ａは、ノード１０４がその更新を受信し、必要な変更を実行している（即ち、メッセージへコミットしている）ことの確認を聞く必要がある。もしノード１０４がそのメッセージへコミットしなければ、冗長ノード１０４はピア・ノード１０２Ａとは整合しないネットワーク・ビューを有するであろう。従って、もしピア・ノード１０２Ａが、冗長ノード１０４が整合しないネットワーク・ビューを有すると思えば、冗長ノード１０４とのセッションを破壊し、サービス停止を起こすであろう。

ここで、もしアクティブ・カード９１０がメッセージを処理しており、故障点１又は２で故障し（冗長ノード１０４は、これらの点でメッセージへコミットしなかった）、切り替えがスタンバイ・カード９５０へ起こるならば、ピア・ノード１０２Ａは、ノード１０４とのセッションを破壊しないであろう。なぜなら、ピア・ノード１０２Ａはメッセージを再送信することができ（或る再試行回数まで）、スタンバイ・カード９５０は再送信されたメッセージを受信し、ピア・ノード１０２Ｂが故障したことのルート更新へコミットすることによって応答するからである。切り替えが迅速に起こり、再試行回数が最大数になる前にスタンバイ・カード９５０が動作を再開するかぎり、スタンバイ・カード９５０は冗長ノード１０４のために動作を再開することができ、障害及び切り替えはピア・ノード１０２Ａによって認識されない。

しかし、もしアクティブ・カード９１０のコミット点で障害が起これば、スタンバイ・カード９５０もメッセージへコミットしなければならない。即ち、もしアクティブ・カード９１０がメッセージへコミットし、スタンバイ・カード９５０がメッセージへコミットしなかったならば、冗長性は破壊され、アクティブ・カード９１０及びスタンバイ・カード９５０には情報の不整合が存在し、それはサービス障害を起こす可能性がある。例えば、コミットされたトランザクションがルート更新へ関連づけられ、もしスタンバイ・カード９５０がその更新へコミットしなければ、それはピア・ノード１０２Ａとは整合しないネットワーク・ビューを有するであろう。従って、スタンバイ・カード９５０は、アクティブ・カード９１０によってコミットされたメッセージへコミットしなければならない。

図６Ａの例において、アクティブ・カード９１０によってコミットされたメッセージが、スタンバイ・カード９５０によってコミットされることを確実にするため、スタンバイ・カード９５０がメッセージへコミットしたのでなければ、アクティブ・カード９１０はメッセージへコミットしない。図６Ａで示されるように、ＭＳＧＡを受信した後、アクティブ・カード９１０は、ＭＳＧＡをスタンバイ・カード９５０へ送信する。スタンバイ・カード９５０は、ＭＳＧＡの受信通知（例えば、「ＭＳＧＡを受信し、ＭＳＧＡへコミットした」という通知）をアクティブ・カード９１０へ送信する。アクティブ・カード９１０がスタンバイ・カード９５０から受信通知を受信した後、アクティブ・カード９１０はメッセージへコミットし、そのコミットメント（「ＭＳＧＡがコミットされたことの受信通知」）を遠隔のピアへ送信する。次に、アクティブ・カード９１０は、上位レイヤーを介してＭＳＧＡを送信するであろう。

図６Ｂの６５０は、他の実施形態に従ってピア・ノードが障害及び切り替えを認識しないようにだます線図を示す。図６Ｂの例において、アクティブ・カード９１０はＭＳＧＡをそのまま上位レイヤーへ送信するが、スタンバイ・カード９５０がＭＳＧＡへコミットしたことの受信通知が受信されるまで、ＭＳＧＡへコミットしない。受信通知が受信された時点で、アクティブ・カード９１０は「コミットメント」を遠隔のピアへ送信する。図６Ｂで示されるように、ＭＳＧＡは、図６ＡのＭＳＧＡよりも早くアクティブ・カード９１０の上位レイヤーへ渡される。

冗長性プラットフォーム９００は、アクティブ・カード９１０内でコミットされたトランザクションに関連した情報でスタンバイ・カード９５０を更新するサポートを提供する。以下で説明されるように、コミットされたメッセージ又はトランザクションは、小さな更新又は大きな更新を要求することができる。個々のトランザクションのためには、小さな更新又は「デルタ」更新がスタンバイ・カード９５０へ要求される。トランザクションの長い履歴を再生するためには、大きな更新又は「バルク」更新がスタンバイ・カード９５０へ要求される。従って、アクティブ・カード９１０によってコミットされた全てのトランザクションを、スタンバイ・カード９５０の中に維持することができる。

図７は、１つの実施形態に従ってピア・ノードへコミットメントを送信する動作７００のフローチャートである。図７を参照すると、動作７０２において、メッセージがピア・ノードから受信される。例えば、アクティブ・カード９１０は、ルートのステータスが変化して更新を行う必要がある旨のメッセージを、ピア・ノード１０２Ａから受信することができる。

動作７０４において、メッセージに関連した情報がスタンバイ・カード９５０へ送信される。動作７０６において、スタンバイ・カード９５０はメッセージを処理し、ルートのステータスを変更することによってメッセージへコミットする。メッセージへコミットすることによって、スタンバイ・カード９５０はアクティブ・カード９１０へ受信通知を送信する。従って、アクティブ・カード９１０はスタンバイ・カード９５０からその受信通知を受信する。

動作７０８において、スタンバイ・カード９５０から受信通知を受信した後、アクティブ・カード９１０はメッセージへコミットする。この時点で、スタンバイ・カード９１０もルートのステータスを変更する。

動作７１０において、メッセージへコミットした後、アクティブ・カード９１０は、ルートへの更新が行われたことをピア・ノードへ通知してピア・ノードへ「コミットメント」を送信することができる。従って、アクティブ・カード９１０だけでなくスタンバイ・カード９５０の中でも、整合したネットワーク・ビューが維持される。

ルータの冗長性
ルータ冗長性のハードウェア
図８は、１つの実施形態に従ってアクティブ・コントローラ・システム及び冗長スタンバイ・コントローラ・システムを有するネットワーク装置１０４を示す。図８を参照すると、ネットワーク装置１０４は複数のポート８１４を含む。ポート８１４は、様々なデータ転送レートで電気信号又は光学信号をサポートする。拡大図８１０はネットワーク装置１０４の基本的内部構成部品を示し、ライン・カード８１２Ａ、アクティブ・カード９１０、スタンバイ・カード９５０、ライン・カード８１２、及びカードを相互に結合するバックプレーン８１４を含む。他のタイプの構成部品、例えばシステム・コントローラ・カードも含まれてよい。１つの実施形態において、ネットワーク装置１０４はＩＰレイヤー３サービスを提供するネットワーク・ルータである。他の実施形態において、ネットワーク装置１０４は、アプリケーションレイヤーサービスまでの上位レイヤーレベル・サービスを提供することができる。ネットワーク装置１０４は、更に、マルチプロトコル・レベル・スイッチング（ＭＰＬＳ）サービスを提供することができる。

ルータ１０４を冗長にするため、アクティブ・カード９１０及びスタンバイ・カード９５０は、同じハードウェア及びソフトウェア構成要素又はモジュールを有する。アクティブ・カード９１０及びスタンバイ・カード９５０は、高速ネットワーク・プロセッサ、メモリ装置、例えば、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）装置、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）装置、又は他の類似のメモリ装置を制御する標準メモリ・コントローラを含むことができる。そのようなメモリ装置は、プロトコル情報、グローバル情報、又はカードに関する構成情報を記憶するために使用されることができる。メモリ装置は、更に、命令、ソフトウェア・モジュール、及びカードを制御するオペレーティング・システムを記憶することができる。

１つの実施形態において、バックプレーン８１４は受動的であり、ライン・カード８１２Ａ、アクティブ・カード９１０、スタンバイ・カード９５０、及びライン・カード８１２Ｂの間の通信を可能にする。他の実施形態において、バックプレーン８１４は、３つ以上のライン・カード冗長性をサポートすることができ、アクティブ・カード９１０及びスタンバイ・カード９５０が２つ以上のライン・カードを制御できるようにする。アクティブ・カード９１０は、アクティブ・カード９１０又はライン・カード８１２Ａの中の障害を検出して、動作をスタンバイ・カード９５０へ移すハードウェア及び／又はソフトウェアを含む。スタンバイ・カード９５０もアクティブ・カード９１０が故障したとき、アクティブ・カード９１０のために動作を再開するハードウェア及び／又はソフトウェアを含む。

冗長性プラットフォーム９００に関して更に詳細に説明するように、アクティブ・カード９１０及びスタンバイ・カード９５０は、スタンバイ・カード９５０の中に整合情報を維持するデータ転送及び検索サブシステムを含む。アクティブ・カード９１０は、バックプレーン８１４を介する通信リンク上で、スタンバイ・カード９５０と通信することができる。例えば、通信リンクは周辺制御インタフェース（ＰＣＩ）リンク又はイーサネット・リンクであることができる。

ルータ１０４は、次のタイプのハードウェア又はルータ冗長性を提供することができる。即ち、（ａ）カード・セット冗長性、（ｂ）システム・カード冗長性、（ｃ）ポート冗長性、又は（ｄ）ライン・カード冗長性である。カード・セット冗長性とは、スタンバイ・カード９５０及びライン・カード８１２Ｂが、アクティブ・カード９１０及びライン・カード８１２Ａに対して冗長ペアとして働くことを意味する。１つの実施形態において、ライン・カード８１２Ａ及びアクティブ・カード９１０は、スロット０及び１へ挿入されることができ、スタンバイ・カード９５０及びライン・カード８１２Ｂは、ルータ１０４のためにスロット２及び３の中へ挿入されることができる。従って、ライン・カード８１２Ａ又はアクティブ・カード９１０の障害は、ライン・カード８１２Ｂ及びスタンバイ・カード９５０への切り替えを起こす。

システム・カード冗長性とは、スタンバイ・カード９５０がアクティブ・カード９１０に対して冗長システム・カードとして働くことを意味する。１つの実施形態において、システム・カード冗長性は、ルータ１０４のデフォルト構成であり、ポート冗長性から独立して、ポート冗長性が存在しても存在しなくても作動可能にすることができる。ポート冗長性とは、冗長ポート８１４が設けられることを意味する。例えば、「Ｙ」タイプのケーブル冗長性は、ポート８１４のために実現されることができる。１つの実施形態において、ポート冗長性は個々のライン・カードのみに適用される。ライン・カード冗長性とは、アクティブ・ライン・カードのために冗長ライン・カードが設けられることを意味する。例えば、ライン・カード８１２Ａは冗長ライン・カードを有することができ、ライン・カード８１２Ｂも冗長ライン・カードを有することができる。

カード状態
アクティブ・カード９１０及びスタンバイ・カード９５０は、２つの重要な状態を認識しなければならない。２つの重要な状態とは、「アクティブ状態」及び「スタンバイ状態」である。どの状態でカードが動作しているかに依存して、各々のカードは異なったタイプの動作を実行する。例えば、アクティブ状態で動作しているカードは、構成、状態、及び学習情報を、スタンバイ状態で動作しているスタンバイ・カードに対して更新する。スタンバイ状態で動作しているカードは、アクティブ・カードから情報を受信して、それに従って記憶サブシステムを更新する。以下で更に詳細に説明するように、スタンバイ・カード９５０に対しては２種類の更新が存在する。即ち、大きな（「バルク」）更新と小さな又は増分（「デルタ」）更新である。

もしアクティブ・カード９１０の診断及び自己テストの全てがピア・ノードとの間でデータ・トラフィックを送受信することができ、かつ支配権を有するならば、アクティブ・カード９１０は「アクティブ状態」にあると考えられる。従って、アクティブ・カードは、管理及びプロビジョニング目的のためにアクセス可能である。１つの実施形態において、カードがアクティブであるかどうかの決定は、グローバル・フラグによって行われることができる。更に、ユーザは、ルータ１０４上の発光ダイオード（ＬＥＤ）インディケータ（例えば、緑色のインディケータ）に基づいて、どのカードがアクティブであるかを決定することができる。もしスタンバイ・カード９５０の診断及び自己テストの全てが合格し、アクティブ・カードになることができ、支配権を有しないならば、スタンバイ・カード９５０は「スタンバイ状態」にあると考えられる。１つの実施形態において、スタンバイ・カードは管理のためにアクセス可能であるが、プロビジョニング目的のためにアクセス可能ではない。１つの実施形態において、カードがスタンバイ状態にあるかどうかの決定もグローバル・フラグによって行われることができ、ユーザは、ルータ１０４上のＬＥＤインディケータ（例えば、黄色のインディケータ）に基づいて、どのカードがスタンバイであるかを決定することができる。

もしアクティブ・カード９１０又はスタンバイ・カード９５０が動作可能になることができなければ、カードは「故障状態」へ入る。故障状態もＬＥＤインディケータ（例えば、赤色のインディケータ）によって決定されることができる。もしアクティブ状態の構成が冗長カードの中でミラーリングされるならば、カードは「冗長」であると定義される。冗長性を維持するため、アクティブ・カードとスタンバイ・カードとの間の通信は常時存在しなければならない。特に、アクティブ・カード９１０が故障したとき、冗長カード９５０はアクティブになることが可能でなければならない。

冗長性プラットフォーム
基本要件
図９は、ノード１０４の冗長性プラットフォーム９００の１つの実施形態を示す。ノード１０４によって、ピア・ノードがノードで起こっている障害を認識しないようにするため、冗長性プラットフォーム９００は、（ａ）ノード１０４とピア・ノードとの接続（即ち、ピア・ノード１０２Ａ及び１０２Ｂとのセッション）がドロップされないように維持し、（ｂ）アクティブ・カード９１０及びスタンバイ・カード９５０の中に整合情報を維持することを要求される。従って、もしスタンバイ・カード９５０が、故障したアクティブ・カード９１０のために動作を再開するならば、スタンバイ・カード９５０は、あたかもアクティブ・カード９１０のように動作する。

例示的アーキテクチャ
図９を参照すると、冗長性プラットフォーム９００は、ハードウェア及びソフトウェア構成要素又はモジュールの組み合わせを有する例示的プラットフォーム・アーキテクチャを示す。冗長性プラットフォームは、冗長メモリ・サブシステム及びソフトウェア・モジュールを有するアクティブ・カード９１０及びスタンバイ・カード９５０を含む。例えば、メモリ・サブシステムは、データ構造及び非持続データを記憶するランダム・アクセス・メモリ（ＲＡＭ）、及び持続データを記憶するフラッシュ・ディスクを含む。更に、ソフトウェア・モジュールは、ソフトウェア冗長性マネージャ、アプリケーション・タスク、冗長性制御マネージャ、及びデータストアを含む。

アクティブ・カード９１０は、アプリケーション・タスク９１６と通信するソフトウェア冗長性マネージャ（ＳＲＭ）９１８を含む。アプリケーション・タスク９１６は、ＲＡＭデータ構造９１２及び非持続データ９１４へ情報変化を送信することができる。非持続データ９１４は、更新の後で変化する情報、例えば、ルーティング情報及び状態を記憶する。アプリケーション・タスク９１６は、更新をデータストア９２２へ送信することができる。この場合、ＲＡＭデータ構造９１２及び非持続データ９１４への変更は、フラッシュ・ディスク９２４の中へ永続的及び冗長的に記憶されることができる。冗長性制御マネージャ（ＲＣＭ）９２０は、アプリケーション・タスク９２０及びデータストア９２２と通信することができる。ＲＣＭ９２０は、スタンバイ・カード９５０の中のピアＲＣＭ９６０へ更新情報を送信する。スタンバイ・カード９５０は、アプリケーション・タスク９１６の動作をミラーリングするピア・アプリケーション・タスク９５６を含む。ピア・アプリケーション・タスク９５６は、ＳＲＭ９５８と通信することができ、アクティブ・カード９１０の中で行われた変更を、ＲＡＭデータ構造９５２及び非持続データ９５４へ送信することができる。ＲＣＭ９６０は、更に、フラッシュ・ディスク９２４との整合性を維持するため、データストア９６２へ変更を送信して、フラッシュ・ディスク９６４を更新することができる。

ＲＡＭデータ構造９１２は、アクティブ・カード９１０とピア・ノードとのルーティング・プロトコル・セッションの状態を記憶することができる。スタンバイ・カード９５０の中のＲＡＭデータ構造９５２は、アクティブ・カード９１２の中のＲＡＭデータ構造９１２との整合情報を維持する。非持続データ９１４は、ＲＡＭの中に記憶された情報を表す。特に、非持続データは、バッファの中に一時的に記憶されたパケットであることができる。ＦＩＢ情報は、規則的又は不規則的時間間隔で更新されている非持続データを含むことができる。持続データとは、データストアを使用してフラッシュ・ディスクの中に永続的に記憶されるデータである。例えば、持続データは、頻繁には変更されないルーティング・プロトコル構成データであることができる。

アクティブ・カード９１０の中のＳＲＭ９１８は、ソフトウェア障害を検出し、そのピアＳＲＭ９５８に障害を通知し、スタンバイ・カード９５０へ動作を切り替える責任を有する。特に、アクティブ・カード９１０の中のＳＲＭ９１６は、アクティブ・カード９１０が劣化又は故障しているかを決定する。もしＳＲＭ９１６がアクティブ・カード９１０の中でそのような劣化又は故障を検出すると、ＳＲＭ９１６は、スタンバイ・カード９５０への切り替えを促進し、スタンバイ・カード９５０の上で走っている他のタスクと協調することができる。

ノード１０４が適正に動作するためには、他のモジュールが「作動可能」状態になければならない。特に、ＲＣＭ９６０、ピア・アプリケーション・タスク９５６、及びデータストア９６２は、「作動可能」状態になければならない。作動可能状態とは、シームレスな切り替えが起こることのできる状態である。これは、アクティブ・カード９１０におけるＲＡＭデータ構造９１２、持続データ９１４、フラッシュ・ディスク９２４の情報が、スタンバイ・カード９５０におけるＲＡＭデータ構造９５２、持続データ９５４、及びフラッシュ・ディスク９６４の情報と整合しているときである。

アクティブ・カード９１０の中のＲＣＭ９２０は、スタンバイ・カード９５０の中のＲＣＭ９６０と通信して、アクティブ・カード９１２の中の情報をスタンバイ・カード９５０へ常時「ミラーリング」し、アクティブ・カード９１０のプロセスをスタンバイ・カード９５０と同期する。ＲＣＭ９２０は、スタンバイ・カード９５０へデータを選択的に移動する責任を有する。特に、ＲＣＭ９２０は、「デルタ」更新と呼ばれる小さな個々のトランザクション更新、及び「バルク」更新と呼ばれる大きなトランザクション更新について責任を有する。

カード間の通信
物理レイヤーは、アクティブ・カード９１０とスタンバイ・カード９５０との間のカード間通信をサポートする。例えば、アクティブ・カード９１０とスタンバイ・カード９５０との間の通信をサポートするため、イーサネット・リンクを使用することができる。アクティブ・カード９１０の中のＲＣＭ９２０は、そのようなリンクを使用して、スタンバイ・カード９５０の中のＲＣＭ９６０と通信することができる。

ＲＣＭ９２０及び９６０は、カード間通信の上で走るソフトウェア・モジュールである。冗長性制御マネージャ（ＲＣＭ）は、それぞれのカードについて役割及び支配権を決定する。ＲＣＭは、更に、ハードウェア・ロジックと通信し、役割及び支配権を決定することができる。ＲＣＭは、アクティブ・カード９１０の中の整合情報をスタンバイ・カード９５０へ転送して更新することをサポートする。例えば、ＲＣＭは、アクティブ・カード９１０とスタンバイ・カード９５０との間で、大きな「バルク」更新及び小さな増分「デルタ」更新を制御する。バルク更新は、通常、新しい冗長カードが挿入された場合に実行される。デルタ更新は、スタンバイ更新として考えられ、個々の変更がアクティブ・カード９１０の中で実行されているときに実行される。１つの実施形態において、スタンバイ・カード９５０の中のＲＣＭ９６０は、少数のトランザクションを遅らせて動作し、より効率的な更新プロセスを促進することができる。

基礎に存在するプラットフォーム９００は、カード間通信をサポートし、従ってアクティブ・カード９１０とスタンバイ・カード９５０との間の情報の複写、即ち、バルク更新及びデルタ更新を起こすことができる。カード間通信は、アクティブ・カード９１０とスタンバイ・カード９５０との間でメッセージの受信通知を促進して、アクティブ・カード９１０及びスタンバイ・カード９５０の中で情報の整合性を維持することができる。

支配権
もし冗長システム（即ち、ノード又はルータ１０４のために挿入されたスタンバイ・カード）が存在するならば、支配権の決定問題が起こる。単一カード構成、例えば、アクティブ・カード９１０のみが存在する構成では、アクティブ・カード９１０がルータ１０４のために支配権を自動的に獲得する。１つの実施形態において、アクティブ・カード９１０は、スタンバイ・カード９５０がルータ１０４の中に存在するかどうかを自動的に決定する。もし冗長カードが存在しなければ、アクティブ・カード９１０が支配権を獲得する。しかし、もしアクティブ・カード９１０が、冗長カードが存在することを決定すれば、アクティブ・カード９１０とスタンバイ・カード９５０との間で支配権を決定する決定が行われる。この決定は、ソフトウェア及び／又はハードウェアの中で行うことができる。例えば、支配権を決定するため任意数の手法を使用するアービトレーション・ロジック又は支配権ロジックが、アクティブ・カード９１０及びスタンバイ・カード９５０の双方に存在することができる。例えば、アービトレーション・ロジックは、カードのスロットＩＤに基づいて支配権を決定することができる。例えば、スロットＩＤ１に挿入されたカードは、「アクティブ・カード」として決定されることができ、スロットＩＤ２に挿入されたカードは、「冗長カード」として決定されることができる。代替的に、アービトレーション・ロジックが、カード上のＩＤ番号をチェックして、それがルータのＩＤ番号とマッチするかどうかを調べることができる。もしマッチすれば、そのカードは「アクティブ・カード」となる。明らかであるように、様々な手法を使用して、支配権を決定することができる。

ブート・シーケンス
単一コントローラ・カード構成において、支配権はコントローラ・カードに所属する。しかし、冗長システムにおいては、ブートアップ時に、どのカードが「アクティブ」になるかを決定する決定が行われる。図１０Ａは、１つの実施形態に従ったブート・シーケンスの動作１０００のフローチャートである。

図１０Ａを参照すると、動作１００２において、冗長システムの中のどのカードが、アクティブ又はスタンバイとして動作すべきであるかを調べる決定が行われる。１つの実施形態において、もしカードの１つがブート・シーケンス前にアクティブであったならば、そのカードが支配権を与えられてアクティブとなる。他の実現形態では、どのカードがアクティブ又はスタンバイであるかを決定するため、スロットＩＤが使用される。

動作１００４において、アクティブと決定されたカードが支配権を要求する。他のカードの中でも同じプロセスを起こすことができる。即ち、双方のカードが同時に走り、各々のカードが支配権を獲得するプロセスを走らせることができる。双方のカードが以前にアクティブであって、現在アクティブになることが可能である場合、タイブレーカを破壊するため、任意数の支配権又は選択アルゴリズム又は手法を使用することができる（例えば、乱数手法）。

動作１００４において、アービトレーション・ロジックは、カード９１０又は９５０の１つへ支配権を許可する。説明目的のために、アクティブ・カード９１０の上のアービトレーション・ロジックがアクティブ・カード９１０へ支配権を許可し、スタンバイ・カード９５０の上のアービトレーション・ロジックがスタンバイ・カード９５０へスタンバイ・ステータスを与える。

アクティブ・カード９１０がアクティブとして動作し、スタンバイ・カード９５０がスタンバイとして動作しているものと仮定すれば、スタンバイ・カード９５０はブートアップ・シーケンスの間に、アクティブ・カード９１０をミラーリングするように更新される必要がある。即ち、アクティブ・カード９１０がブートアップし、ＳＲＭ９１８はアクティブ・カード９１０の中の構成及び状態情報を読み取る。従って、アクティブ・カード９１０はアクティブ状態で走り始める。スタンバイ・カード９５０の中のＳＲＭ９５８も、構成及び状態情報を読み取り、スタンバイ状態で走り、作動可能であってスタンバイ状態にあることをＳＲＭ９１８へ通知する。図１０Ｂは、他の実施形態に従ったブート・シーケンスの動作１０１０のフローチャートである。

図１０Ｂを参照すると、動作１０１２において、アクティブ・カード９１０は、アプリケーション・タスク９１６、ＳＲＭ９１８、及びＲＣＭ９２０を使用して、ＲＡＭデータ構造９１２、フラッシュ・ディスク９２４、及び非持続データ９１４に記憶された内容の全てを、スタンバイ・カード９５０の中のピアへバルク・コピーする。例えば、アクティブ・カード９１０の上で走っているルーティング・プロトコル・アプリケーションは、ＲＡＭデータ構造９１２の中の全ての関連情報を、スタンバイ・カード９５０の中のピア９５２へコピーし始める。１つの実施形態において、必須のデータだけが、例えば、状態データ、接続データ、私用ルート・データベースなどが、コピーされなければならない。更に、非必須データ、例えば、カウンタ情報は、コピーされる必要はない。

動作１０１４において、アクティブ・カード９１０は、ピア・ノードから到着する新しいルーティング・メッセージから生成された新しい情報又はデータの増分コピーを実行する。新しい情報は、バルク・コピー動作が完了したかどうかに関わらず、スタンバイ・カード９５０へコピーされなければならない。１つの実施形態において、どの情報が新しく生成されたかを決定するため、マーク・アンド・スイープ手法を使用することができる。他の実施形態において、増分コピー及びバルク・コピーの同時の実行は許されない。そのような場合、冗長性プラットフォーム９００は、バルク・コピー動作の後で増分更新を実行するため、任意数のキューを含むことができる。有効及び整合したルーティング・プロトコル情報を保証するため、データストア９２２は、フラッシュ・ディスク９２４へ変更を行う前に、フラッシュ・ディスク９２４からの冗長性コピーを、スタンバイ・カード９５０の中のデータストア９６２及びフラッシュ・ディスク９６４へ実行する。

動作１０１６において、アクティブ・カード９１０及びスタンバイ・カード９５０の双方は、整合性検査を実行する。例えば、各々のルータ・プロトコルは、アクティブ・カード９１０からスタンバイ・カード９５０へ整合情報がコピー又は複写されたかどうかの検査を実行しなければならない。一度、整合性が検査されると、ルーティング・プロトコルは、スタンバイ・カード９５０におけるそれ自身の冗長性を宣言することができる。もしルーティング・プロトコルが、それら自身の冗長性を宣言すれば、ルータ１０４は、冗長であると宣言される。

猶予切り替え
猶予切り替えとは、制御された方法でユーザ又はソフトウェアによってイニシエートされる切り替えを意味する。例えば、ユーザは、コマンドをコマンド行でイニシエートして、ノード１０４のためにアクティブ・カード９１０からスタンバイ・カード９５０へ動作を切り替えることができる。猶予切り替えにおいて、ＳＲＭ９１８は、スタンバイ・カード９５０への支配権変更を認識する。従って、ＳＲＭ９１８は、より制御された方法で切り替えを準備し、アクティブ・カード９１０はルータ１０４の制御をスタンバイ・カード９５０へ円滑に譲渡することができる。ＳＲＭ９１８は、アクティブ・カード９１０が「アクティブ状態」で機能するために必要な全ての重要機能のビット・マップを維持する。アプリケーション・タスク９１６を介するタスクは、それらの状態をスタンバイ・カード９５０の中のＳＲＭ９１８へ送信し、シームレス及び高速の切り替えが起こるようにする。

図１１Ａ及び図１１Ｂは、１つの実施形態に従ってスタンバイ・カード９５０への猶予切り替えを実行するアクティブ・カード９１０の動作１１００のフローチャートである。次の動作において、高速及び円滑な切り替えを促進するため、アクティブ・カード９１０のＳＲＭ９１８及びＲＣＭ９２０を使用することができる。

図１１Ａ及び図１１Ｂを参照すると、動作１１０２において、アクティブ・カード９１０は、スタンバイ・カード９５０がルータ１０４に挿入されているかどうか、又はスタンバイ・カード９５０がオフラインでないかどうかをチェックすることによって、切り替えがブロックされないことを検査する。アップグレード目的のため、又は他の理由によって、スタンバイ・カード９５０を「オフライン」モードにすることができる。これは、結果的に冗長性機能を除去する。スタンバイ・カード９５０がオンラインかオフラインかを検査するため、カード間通信メカニズムを使用することができる。例えば、ＳＲＭ９１８は、スタンバイ・カード９５０の状態を要求することができる。状態は、カード状態、カード・タイプ、ハードウェア、ソフトウェア、及びデータベース・チェックサムへ関連づけられることができる。従って、もし戻された状態が「オフライン」であれば、アクティブ・カード９１０は切り替えを拒絶するであろう。

動作１１０４において、アクティブ・カード９１０は、スタンバイ・カード９５０がオフラインでないことを検査する。

動作１１０６において、ＳＲＭ９１８は、切り替えが実行されていることを、ルータ１０４の制御プレーン又はアプリケーションレイヤーへ通知する。

動作１１０８において、アクティブ・カード９１０は、フラッシュ・ディスク９２４への全ての新しい更新をブロックする。例えば、ＳＲＭ９１８及びデータストア９２２は、ＲＡＭデータ構造９１２、非持続データ９１４、及びフラッシュ・ディスク９２４への全ての更新をブロックすることができる。１つの実施形態において、ＳＲＭ９１８は、全てのタスクが更新、例えば、フラッシュ・ディスク９２４内のルーティング・テーブルの変更を禁止された旨のメッセージを、アプリケーション・タスク９１６へ送信することができる。このブロックは、更に、スタンバイ・カード９５０への全ての新しい更新をブロックする。これは切り替えに必須である。他の実施形態において、アプリケーション・タスク９１６は、切り替えに致命的ではない或るデータ変更が、ＲＡＭデータ構造９１２及び非持続データ９１４へブロックされないことを決定できる。

動作１１１０において、ＳＲＭ９１８及びＲＣＭ９２０は、データベースの更新を完了するため、ＲＡＭデータ構造９１２、持続データ９１４、及びフラッシュ・ディスク９２４の中の情報を、スタンバイ・カード９５０の中のピアへ複写する。

動作１１１２において、ＳＲＭ９１８は、スタンバイ・カード９５０上の構成情報がアクティブ・カード９１０と同じかどうかを検査する。例えば、ＳＲＭ９５８は、スタンバイ・カード９５０におけるデータベース情報のチェックサムをアクティブ・カード９１０と交換することができる。１つの実施形態において、もしチェックサムがマッチしなければ、ＳＲＭ９５８は、アクティブ・カード９１８の中へデータベースを再び複写し、検査プロセスを再び実行する。もしチェックサムが２回目にマッチしなければ、切り替えは起こらない。

動作１１１４において、ＳＲＭ９１８は、複写が完了した後にアクティブになる準備をすることを、スタンバイ・カード９５０へ通知する。アクティブ・カード９１０は、「アクティブ」になる準備を完了することを、スタンバイ・カード９５０に通知する。１つの実施形態において、アクティブ・カード９１０は、アクティブになる準備を完了するメッセージをスタンバイ・カード９５０に送信する。こうして、アクティブ・カード９１０は受信通知（即ち、「作動可能」又は「非作動可能」）を待つことができる。もしスタンバイ・カード９５０が「非作動可能」を応答すれば、切り替えは破棄される。

動作１１１６において、ＳＲＭ９１８は、走っている或るタスクがスタンバイへ移りつつあることを、アプリケーション・タスク９１６へ選択的に通知する。例えば、ＳＲＭ９１８は、メッセージをタスクの選択グループへ送信する。このメッセージに対しては受信通知が必要である。メッセージは、アクティブ・カード９１０がスタンバイ状態へ変更されつつあることをタスクへ通知する。

動作１１１８において、アクティブ・カード９１０は、ルータ１０４に対する支配権を譲渡する。例えば、ＳＲＭ９１８は、「マスター」状態を主張しないＩ／Ｏドライバを呼び出して、支配権を譲渡することができる。次に、アクティブ・カード９１０のハードウェアは、即時の制御又は支配権をスタンバイ・カード９５０へ与える。従って、このアクションは、ルータ１０４へ来る全てのデータをスタンバイ・カード９５０へ転送する。

動作１１２０において、ＳＲＭ９１８は、タスクの残りがスタンバイへ移ることを、アプリケーション・タスク９１６へ通知する。即ち、或るタスクの機能は、カード状態が変化するにつれて変化する。そのような変化は、全てのタスクへ伝搬されることができる。

動作１１２２において、ＳＲＭ９１８は、タスクの状態をタスクに質問し、タスクがスタンバイになるまで待つ。この動作は、主として、アクティブ・カード９１０だけが実行することのできる機能、例えば、管理ステーションへの応答、又はアップリンク／アクセス・ポート上のデータの送信、ライン・アラームへの応答などを実行しているアクティブ状態のタスクに必要である。この質問／ハンドシェーキングによって、全ての重要なタスクはスタンバイへ移ることを保証される。

動作１１２４において、アクティブ・カード９１０は、持続情報及び非持続情報の双方についてデータベースを同期するため、アクティブ（スタンバイ・カード９５０）との通信を確立する。一度、データベースが同期されると、アクティブ・カード９１０の状態はスタンバイ状態への準備を完了する。

動作１１２６において、ＳＲＭ９１８は、アプリケーション・タスク９１６及びデータストア９２２へ行われたブロックを除去する。

動作１１２８において、アクティブ・カード９１０はスタンバイ状態へ設定される。

上記の動作はアクティブ・カード９１０のイベントに関連する。スタンバイ・カード９５０のイベントは、以下の図１２Ａ及び図１２Ｂとの関連で説明される。

図１２Ａ及び図１２Ｂは、１つの実施形態に従って猶予切り替えを実行するスタンバイ・カード９５０の動作１２００のフローチャートである。以下の動作において、高速及び円滑な切り替えを促進するため、スタンバイ・カード９５０のＳＲＭ９５８及びＲＣＭ９６０を使用することができる。図１２Ａ及び図１２Ｂを参照すると、動作１２０２において、ＳＲＭ９５８は、ＳＲＭ９１８を介してアクティブ・カード９１０へカード状態情報及び自己テスト情報を与える。

動作１２０４において、ＲＣＭ９６０は、アクティブ・カード９１０からスタンバイ・カード９５０の中のピア・データベースを更新する。

動作１２０６において、ＳＲＭ９５８は、ＳＲＭ９１８を介してアクティブ・カード９１０へデータベース・チェックサムを提供する。

動作１２０８において、ＳＲＭ９５８は、或るタスクがアクティブ状態への準備を完了することを、ピア・アプリケーション・タスク９５６へ通知する。

動作１２１０において、アクティブ・カード９１０が支配権を譲渡する時点で、スタンバイ・カード９５０がルータ１０４に対する支配権を獲得する。

動作１２１２において、ＳＲＭ９５８は、タスクの残りがアクティブ・ステータスを有すべきであることを、ピア・アプリケーション・タスク９５６へ通知する。ＳＲＭ９５８は、更に、スタンバイ・カード９５０の中で支配権を有することの状態情報を更新する。

動作１２１４において、ピア・アプリケーション・タスク９５６は、タスクの状態をタスクに質問し、それらのタスクがアクティブ状態になるまで待つ。１つの実施形態において、幾つかのタスクは、もし必要であれば、アクティブとして再スタートしてよい。

動作１２１６において、ＳＲＭ９５８は、スタンバイ・カード９５０上のＲＡＭデータ構造９５２、非持続データ９５４、及びフラッシュ・ディスク９６４への新しいネットワーク更新をブロックする。

動作１２１８において、スタンバイ・カード９５０は、その状態をアクティブへ変更する。

動作１２２０において、ＳＲＭ９５８は、制御プレーン又はスタンバイ・カード９５０上で走っているアプリケーションレイヤーへ切り替えを通知する。

動作１２２２において、ＳＲＭ９５８は、他のカード（アクティブ・カード９１０）がスタンバイ状態になるまで待つ。

動作１２２４において、ＳＲＭ９５８及び／又はＲＣＭ９６０は、スタンバイ・カード９５０におけるデータベースのデータが、アクティブ・カード９１０のデータベースと整合しているかどうかを検査する。

動作１２２６において、ＳＲＭ９５８は、スタンバイ・カード９５０内のデータベースへのプロビジョニング・ブロックを除去する。

非猶予切り替え
非猶予切り替えとは、警告なしにアクティブ・カード９１０内の障害によってイニシエートされた切り替えを意味する。例えば、アクティブ・カード９１０は、以下で詳細に説明するように、幾つかのハードウェア及びソフトウェアの理由によって故障する。非猶予切り替えは、切り替えの準備が存在しないことを除いて、猶予切り替えと非常に類似している。即ち、切り替えは、冗長システムのために任意の時点で起こり、データベースの更新は係属中であるか、データベースは、例えば、ルーティング・テーブル又はＦＩＢの更新の最中であってよい。更に、或る情報は、失われる可能性がある。１つの実施形態において、失われた情報を回復するため、回復メカニズムを実行することができる。

図１３は、１つの実施形態に従った非猶予切り替えを実行するスタンバイ・カード９５０の動作１３００のフローチャートである。動作１３００は、スタンバイ・カード９５０に関連する。１つの実施形態において、アクティブ・カード９１０は、非猶予切り替えのために図１１の動作１１００を実行する。

図１３を参照すると、動作１３０２において、ＳＲＭ９５８は、他のカード（アクティブ・カード９１０）がルータ１０４のために支配権を所有していないこと決定する。

動作１３０４において、ＳＲＭ９５８は、全てのタスクが「アクティブ」へ移行すること、及びスタンバイ・カード９１０の状態が「アクティブ」として更新されることを、ピア・アプリケーション・タスク９５６へ通知する。

動作１３０６において、ＳＲＭ９５８は、タスクの状態をタスクに質問し、それらのタスクが「アクティブ」になるまで待つ。

動作１３０８において、アクティブ・カード９１０の状態が「非アクティブ」又は「スタンバイ」へ変更される。

動作１３１０において、スタンバイ・カード９５０は、スタンバイ・カード９５０がルータ１０４のために支配権を所有していること、及び切り替えが起こったことを、制御プレーン又はアプリケーションレイヤーへ通知する。

スタンバイ・カード冗長性の同期
冗長性がアクティブ・カード９１０及びスタンバイ・カード９５０と一緒に働くために同期されなければならない２つの主な構成要素が存在する。第１に、フラッシュ・ディスク９２４の中に記憶された「持続情報」の同期が存在しなければならない。持続情報は、例えば、構成情報及び関連したファイル、関連した更新、ログ、状態などを含むことができる。第２に、ＲＡＭ（例えば、ＲＡＭデータ構造９１２及び非持続データ９１４）に記憶された「非持続情報」の同期が存在しなければならない。非持続情報は、例えば、ルーティング・テーブル、セッション接続などを含む。ルータ１０４上で走っている全てのタスクは、その設計の一部分として冗長性を有する。即ち、全てのタスクは、「持続情報複写」及び「非持続情報複写」に焦点を置いている。アクティブ・カード９１０及びスタンバイ・カード９５０の中のデータストア・ソフトウェア・モジュールは、持続及び非持続複写又は更新を助ける。

持続更新
図１４は、持続情報をスタンバイ・カード９５０へ更新する動作１４００のフローチャートである。動作１４００は、アクティブ・カード９１０上のデータストア９２２を呼び出して構成情報をフラッシュ・ディスク９２４へ保存するタスクに関連している。データストア９２２は、ローカルのフラッシュ・ディスク９２４を更新した後、スタンバイ・カード９５０内のピア・データストア９６２へメッセージを送信し、同じ情報をフラッシュ・ディスク９６４へコピーする。更に、ＲＡＭデータ構造９５２及び非持続データ９５４を新しい構成情報で更新するため、データストア９６２へのメッセージをピア・アプリケーション・タスク９５６へ送信することができる。１つの実施形態において、全てのトランザクションのために否定応答又は肯定応答が存在してよい。

図１４を参照すると、動作１４０２において、アプリケーション・タスク９１６は、メッセージをデータストア９２２へ送信し、構成情報をフラッシュ・ディスク９２４へ保存する。例えば、メッセージは、更新のためのレコード識別情報を含むことができる。代替的に、単一のトランザクションについて、多数のレコード更新が存在してよい。

動作１４０４において、データストア９２４は構成情報でフラッシュ・ディスク９２４を更新する。ローカルのフラッシュ・ディスク９２４を更新した後、データストア９２４は、フラッシュ・ディスク９２４が更新された旨の受信通知を、アプリケーション・タスク９１６へ送る。次に、データストア９２４は、ＲＣＭ９２０及び９６０を介してスタンバイ・カード９５０内のピア・データストア９６２へ同じメッセージを送信する。

動作１４０６において、スタンバイ・カード９５０内のデータストア９６２は、アクティブ・カード９１０の中のフラッシュ・ディスク９２４に対する同じ更新で、フラッシュ・ディスク９６４を更新する。データストア９６２は、アクティブ・カード９１０の中のデータストア９２２によってアプリケーション・タスク９１６へ送信された同じメッセージ・セットを、ピア・アプリケーション・タスク９５６へ送信する。

動作１４０８において、ピア・アプリケーション・タスク９５６は、メッセージを解釈し、それに従ってＲＡＭデータ構造９５２及び非持続データ９５４を更新する。

非持続更新
図１５は、非持続情報をスタンバイ・カード９５０へ更新する動作１５００のフローチャートである。動作１５００は、アクティブ・カード９１０の中のＲＡＭデータ構造９１２及び非持続データ９１４へ構成変更を送信し、スタンバイ・カード９５０内のピア・アプリケーション・タスク９５６へメッセージを送信して、ＲＡＭデータ構造９５２及び非持続データ９５４を更新するアプリケーション・タスク９１６に関連する。１つの実施形態において、全てのトランザクションに否定応答又は肯定応答を使用することができる。

図１５を参照すると、動作１５０２において、アプリケーション・タスク９１６は、そのＲＡＭデータ構造９５２又は非持続データ９５４を更新し、メッセージをＲＣＭ９２０へ送信して、そのメッセージをスタンバイ・カード９５０へ送信する。

動作１５０４において、ＲＣＭ９２０は、ＲＣＭ９６０を介してメッセージをピア・アプリケーション・タスク９５６へ送信する。ＲＣＭ９２０は、アプリケーション・タスク９１６がアクティブ・カード９１０の中で送信したメッセージの同じセットを、ピア・アプリケーション・タスク９５６へ送信する。

動作１５０６において、ピア・アプリケーション・タスク９５６は、それに従ってそのＲＡＭデータ構造９５２及び非持続データ９５４を更新する。ピア・アプリケーション・タスク９５６は、変更を行った旨の受信通知を、アクティブ・カード９１０の中のアプリケーション・タスク９１６へ送信することができる。

動作１５０８において、アクティブ・カード９１０上のＳＲＭ９１８は、受信通知を受信すると、ＲＡＭデータ構造９１２、非持続データ９１４、及びフラッシュ・ディスク９２４への変更禁止を実行したブロッキング・プロセスをアンブロックする。

上記の更新動作は、「バルク更新」及び「デルタ（小さい）更新」と呼ばれるスタンバイ・カード９５０への２種の更新について実行されることができる。

バルク更新
バルク更新とは、スタンバイ・カード９５０が最初にルータ１０４へ挿入され、アクティブ・カード９１０がアクティブ・モードで動作していたときに行われるスタンバイ・カード９５０への更新を意味する。新しく挿入されたカードは、新しいカード又はスペア・カード又は他のルータからのカードであってよい。アクティブ・カード９１０及びスタンバイ・カード９５０の上で走っているＳＲＭは、それら自身の有効性及びステータスを決定し、アクティブ・ステータス又はスタンバイ・ステータスを決定する。説明目的のために、挿入されたスタンバイ・カード９５０はスタンバイ・ステータスを獲得する。もし挿入されたカードが機能的にスタンバイになることができれば、スタンバイ・カード９５０はアクティブ・カード９１０と同期されなければならない。

この時点において、動作している巨大なルーティング・テーブルを有するアクティブ・カード９１０とスタンバイ・カード９５０との間で、大きな更新「バルク更新」が起こる。特に、更新は「バルク」と呼ばれる。なぜなら、何百万というルーティング・エントリを含むことができるアクティブ・カード９１０の中の全ての情報が、スタンバイ・カード９５０へコピーされなければならないからである。

バルク更新の始めに、ＳＲＭ９１８は、アクティブ・カード９１０の構成への全ての変更、例えば、コマンド・ライン変更又はセッション・セットアップ変更をブロックする。１つの実施形態において、ネットワーク・ルートの更新をキューにすることができる。なぜなら、ネットワーク・トポロジの変化は、バルク更新の間でも、常に認識されていなければならないからである。

アクティブ・カード９１０内のデータストア９２２は、持続データ（即ち、フラッシュ・ディスク９２４の中に記憶された情報）を記憶しているデータベースが、スタンバイ・カード９５０のメモリ又はフラッシュ・ディスク９６４の中へミラーリングされることを確実にする。例えば、ルーティング・テーブル、接続情報などは、アクティブ・カード９１０及びスタンバイ・カード９５０の中にミラーリングされる。ＲＣＭ９２０は、アクティブ・カード９１０上のモジュールへ、スタンバイ・カード９５０の存在を通知する。１つの実施形態において、更新は、アクティブ・カード９１０の上で走っているルーティング・プロトコルの異なったタイプについて使用される各々のアプリケーションごとに異なることができる。

デルタ更新
アクティブ・カード９１０上で起こることのできる変化は２種類存在する。第１の変化は、スタンバイ・カード９５０へ複写又は更新されることが必要な変化である。例えば、構成の変化、ルーティング・テーブルの更新、ノード名の変更などは、スタンバイ・カード９５０の中で更新されることが必要である。第２の変化は、スタンバイ・カード９５０へ更新されることを必要としない変化である。例えば、カウンタの更新又は重要でないアラームは、スタンバイ・カード９５０へ更新される必要はない。しかし、そのような変化をスタンバイ・カード９５０へ複写することができる。

デルタ更新は、持続更新及び非持続更新に関連して説明した動作を使用して実行することができる。１つの実施形態において、デルタ更新が失敗し、スタンバイ・カード９５０が動作を再開した場合でも、デルタ更新の不在は、必ずしもスタンバイ・カード９５０の障害を生じない。なぜなら、ピア・ノードがメッセージを再送信するからである。メッセージがコミットされない限り、スタンバイ・カード９５０は必ずしもデルタ更新を必要とせず、アクティブ・カード９１０が故障した場合に動作を再開する。即ち、もしメッセージ又は変更がアクティブ・カード９１０によってコミットされるならば、それはスタンバイ・カード９５０に対して行われ、デルタ更新でピア・ノードとの整合性を維持しなければならない。

エラーの処理
アクティブ・カード９１０はソフトウェア及びハードウェアのエラー処理能力を含む。例えば、ＳＲＭ９１８は、ソフトウェア・エラーを処理することができ、エラー・ロジックはアクティブ・カード９１０のハードウェア・エラーを処理することができる。図１６は、１つの実施形態に従ってエラー処理を実行する動作１６００のフローチャートである。

図１６を参照すると、動作１６０２において、アクティブ・カード９１０はエラー、例えば、ソフトウェア・エラー又はハードウェア・エラーを検出する。アクティブ・カード９１０は、エラーが切り替えを必要とするかどうかを検出する。もしエラーが切り替えを必要とすれば、アクティブ・カード９１０及びスタンバイ・カード９５０は、前述したような非猶予切り替えを実行することができる。

動作１６０４において、スタンバイ・カード９５０へのハードウェア切り替えが起こる。物理的切り替えを実行するため、数ミリ秒台の或る時間が必要である。

動作１６０６において、スタンバイ・カード９５０はルータ１０４のために動作を再開する。スタンバイ・カード９５０は動作を迅速に再開する必要がある。なぜなら、ルータ１０４とのプロトコル・セッションがタイムアウトになるかもしれないからである。アクティブ・カード９１０への関連情報の変更のため、非持続及び持続情報のデルタ更新が行われるため、スタンバイ・カード９５０はシームレス及び迅速に動作を再開することができる。

ソフトウェア／ハードウェア障害
ソフトウェアの障害は、最も重要なタイプの障害である。即ち、ソフトウェア・エラーは、冗長性システムの中で整合性を必要とする多数のソフトウェア状態及び変数に関連している。更に、ソフトウェア・エラーは検出するのが困難である。通常のタイプのソフトウェア障害は、セグメンテーション障害、メモリ破壊、メモリ不足、アプリケーションの強制切り替え、及び無限ループを含む。

セグメンテーション障害は、メモリへの無効アクセスが存在する場合に起こる。もしメモリへの誤ったアクセスが存在すると、ハードウェア又はソフトウェアは、誤ったアクセスを検出し、ＳＲＭへエラーを生成して切り替えを起こすことができる。特に、メモリへの誤ったアクセスは、正しくない情報を記憶させ、これは整合しないルーティング・テーブル情報を作り出して記憶させる。メモリ不足のエラーは、あまりに多くのメモリ空間が使用される場合に起こる。１つの実施形態において、もし使用されたメモリ空間が警告レベルに達すると、警告が与えられ、もし使用されたメモリ空間が或る閾値を越えると、切り替えが起こる。

アプリケーション強制切り替えは、ユーザがコマンド・ライン命令によって切り替えを強制する場合に、ソフトウェアで起こる。例えば、アクティブ・ステータスを有すべき新しいカードが挿入される場合である。無限ループも、プロセッサが他の命令を処理できないようにする。１つの実施形態において、命令がソフトウェア・エラーを起こす無限ループであるかどうかを決定するため、ウォッチドッグ・タイマを使用することができる。代替的に、プロセッサが他のタスクを無限に処理することに固執しているかどうかを決定するため、低優先度のタスクを使用することができる。即ち、もし低優先度のタスクが決して処理時間を獲得しないならば、無限ループであると決定することができる。

スタンバイ・カード９５０内の冗長ハードウェアのために、ハードウェア障害はソフトウェア障害よりも重大ではない。通常のタイプのハードウェア障害は、ＡＳＩＣ診断障害、バス障害、メモリ障害、又はパワーアップ又はブート・シーケンスの間のカード障害である。そのようなハードウェア障害は、更に、アクティブ・カードの支配権の譲渡、及びスタンバイ・カード９５０への切り替えを起こす。

ルーティング・プロトコルの冗長性
ルーティング・プロトコル冗長性の基本的要件
ルーティング・プロトコル・レベルの冗長性を実現するため、スタンバイ・カード９５０は、アクティブ・カード９１０の上で走っているルーティング・プロトコルの各々のために必要な全ての関連情報を移植されなければならない。アクティブ・カード９１０及びスタンバイ・カード９５０の上で走っている各々のルーティング・プロトコル・モジュールは、アクティブ・カード９１０及びスタンバイ・カード９５０の双方の中で、プロトコル情報のミラーリング・コピーを維持する責任を有する。従って、もしアクティブ・カード９１０が故障すると、スタンバイ・カード９５０は、アクティブ・カード９１０の全てのルーティング・プロトコル・セッションを再開することができる。スタンバイ・カード９５０は、ルーティング・プロトコル・セッション状態がタイムアウトする前に動作を再開し、故障がピア・ノードから認識されないようにする。

ルーティング・プロトコルの例示的インタラクション
図１７の１７００は、１つの実施形態に従ったノードの中のルーティング・プロトコル・インタラクションを示す。図１７を参照すると、各々のルーティング・プロトコルＢＧＰ１７２６、ＯＳＰＦ１７２４及びＩＳ−ＩＳ１７１４は、それぞれ、それ自身のデータベース１７３１、１７３２及び１７３３に関連づけられている。そのようなデータベースは、特定のルーティング・プロトコルのルート又は情報を含むことができる。更に、各々のルーティング・プロトコルのデータベース１７３１、１７３２及び１７３３は、ルーティング・プロトコルＢＧＰ１７２６、ＯＳＰＦ１７２４及びＩＳ−ＩＳ１７１４の中で動作している状態機械及び統計のデータ構造を記憶することができる。

集成された全てのルートは、ＩＰルーティング・テーブル１７０２の中に記憶される。転送テーブル（ＦＩＢ）１７０２は、ＩＰルーティング・テーブル１７０２内のルートに基づいて生成することができる。ＦＩＢ１７１６は、ルータ１０４のためにパケットを転送する転送情報を含むことができる。１つの実施形態において、第３次連想記憶装置（ＴＣＡＭ）１７０６は、ＦＩＢ１７１６の中にルートを記憶することができる。他の実施形態において、ＦＩＢ１７１６を記憶及び維持するため、プロセッサ及びメモリ・システムの任意の組み合わせを使用することができる。

前記のルーティング・プロトコル・インタラクションは、アクティブ・カード９１０が故障した場合に、スタンバイ・カード９５０の上で同じように動作することである。従って、アクティブ・カード９１０におけるＢＧＰ１７２６、ＯＳＰＦ１７２４及びＩＳ−ＩＳに対するデータベース１７３１、１７３２、１７３３の中の情報は、スタンバイ・カード９５０における同等物へ複写される。更に、ＩＰルーティング・テーブル１７０２及びＦＩＢ１７１６は、スタンバイ・カード９５０内の同等物へ複写される。こうして、スタンバイ・カード９５０のＴＣＡＭ１７０６は、ルータ１０４の整合した転送情報を使用して、パケットを切り替えて転送する。

図１８の１８００は、他の実施形態に従ったアクティブ制御点とスタンバイ制御点との間のルーティング・プロトコル・インタラクションを示す。図１８を参照すると、ルーティング・プロトコルＢＧＰ１７２６Ａ、ＯＳＰＦ１７２４Ａ及びＩＳ−ＩＳ１７１４Ａのデータベース１７３１Ａ、１７３２Ａ及び１７３３Ａ内のルーティング情報のコピーが、それぞれ、スタンバイ制御点内のピア・データベースの中に維持される。

１つの実施形態において、アクティブ・カード９１０とスタンバイ・カード９５０との間の接続の過負荷を回避するため、アクティブ・カード９１０は、スタティック・ルート１８２０Ａのみを、スタンバイ制御点内のピア・スタティック・ルート１８２０Ｂへ複写又はコピーする。スタティック・ルートはネイティブ・ルートである。スタンバイ・カード９５０は、ルータ１０４のためにネットワーク１００へ通信するために使用されているポートへのアクセスを有しないことを除いて、アクティブ・カード９１０と同じように走っている。特に、スタンバイ・カード９５０内の正規符号経路は、そのＩＰルーティング・テーブル１７１６を再分配及び移植するだけである。

アクティブ制御点の故障の場合、ルータ１０４は、動作をスタンバイ制御点へ切り替える。ルータ１０４は、トラフィックをシームレスに回送し続ける。なぜなら、スタンバイ制御点は、各々のルーティング・プロトコルの私用データストアから有効な転送テーブルを生成したからである。従って、ルータ１０４と通信しているピア・ノードは、ルータ１０４とのルーティング・プロトコル・セッションを維持することができる。更に、ルータ１０４は、障害がピア・ノードから認識されないようにし、切り替えがピア・ノードから認識されないようにすることができる。

ルーティング・プロトコル冗長性の例示的アーキテクチャ
図１９は、ルーティング・プロトコル冗長性の例示的アーキテクチャ１９００を示す。例示的アーキテクチャ１９００は、ルーティング・プロトコルの冗長性をサポートするアクティブ・カード９１０及びスタンバイ・カード９５０のルーティング・プロトコル・データベース及びモジュールを含む。アクティブ・カード９１０及びスタンバイ・カード９５０のモジュールの各々は、２種類の冗長性データベースを有する。それらは冗長データベース（ＲＤＢ）及び持続データベース（ＰＤＢ）である。

アクティブ・カード９１０は、ＩＧＰ ＲＤＢ １９４２Ａ及びＩＧＰ ＲＤＢ １９２４Ａにアクセスするゲートウェイ内プロトコル（ＩＧＰ）モジュール１９９２Ａを含む。ＩＧＰモジュールは、ＯＳＰＦ、ＲＩＰ、及びＩＳ−ＩＳルーティング・プロトコルのモジュールを含む。アクティブ・カード９１０は、更に、ＢＧＰ ＲＤＢ１９２７Ａ及びＢＧＰ ＰＤＢ１７３１ＡにアクセスするＢＧＰモジュール１７２６Ａ、ＴＣＰ ＲＤＢ１９３３Ａ及びＴＣＰ ＰＤＢ１９２６ＡにアクセスするＴＣＰモジュール１９３２Ａ、及びＩＰ ＲＤＢ１９３１Ａ及びＩＰ ＰＤＢ１９２８ＡにアクセスするＩＰモジュール１９３０Ａを含む。

スタンバイ・カード９５０は、ピアＰＤＢ及びＲＤＢにアクセスするアクティブ・カード９１０のピア・モジュールを含む。特に、スタンバイ・カード９５０は、ＩＧＰ ＲＤＢ１９４２Ｂ及びＩＧＰ ＲＤＢ１９２４ＢにアクセスするＩＧＰモジュール１９９２Ｂを含む。スタンバイ・カード９５０は、更に、ＢＧＰ ＲＤＢ１９２７Ｂ及びＢＧＰ ＰＤＢ１７３１ＢにアクセスするＢＧＰモジュール１７２６Ｂ、ＴＣＰ ＲＤＢ１９３３Ｂ及びＴＣＰ ＰＤＢ１９２６ＢにアクセスするＴＣＰモジュール１９３２Ｂ、及びＩＰ ＲＤＢ１９３１Ｂ及びＩＰ ＰＤＢ１９２８ＢにアクセスするＩＰモジュール１９３０Ｂを含む。

持続データ（ＰＤＢ）及び非持続データ（ＲＤＢ）の冗長性は、異なるように処理される。持続データ冗長性は、各々のアクティブ・カード９１０及びスタンバイ・カード９５０の内部データストア・モジュールによって処理される。もしアクティブ・カード９１０のデータストア・モジュールがデータをフラッシュ・ディスクへ記憶すれば、同じデータは、スタンバイ・カード９５０及びそのフラッシュ・ディスクへトランスペアレントに渡される。更に、スタンバイ・カード９５０内のピア・データストア・モジュールは、変更を通知され、変更されているデータも通知の一部分として渡される。モジュールの各々は、更に、それ自身の非持続データの冗長性に対してのみ責任を有する。例えば、もしＯＳＰＦが或る更新をＢＧＰから受信したのであれば、ＯＳＰＦはそれをスタンバイ・カード９５０へ渡さない。この場合、ＢＧＰはスタンバイ・カード９５０内のそのピアＢＧＰへ更新を送信する。

アクティブ・カード９１０及びスタンバイ・カード９５０は、ルート再分配を同じように実行する。アクティブ・カード９１０及びスタンバイ・カード９５０の上のルーティング・プロトコル・モジュールの各々は、それぞれ、ルーティング・テーブル・マネージャ（ＲＴＭ）１９４０Ａ及び１９４０Ｂへその最良ルートを送信する責任がある。もしアクティブ・カード９１０上のＲＴＭ１９４０Ａが、他のプロトコルへルートを再分配するように構成されていれば、ＲＴＭ１９４０Ａは、同様にスタンバイ・カード９５０の上でそうするであろう。１つの実施形態において、ＲＴＭ再分配のセッティングは構成情報として考えられ、持続データとして冗長にされる。

転送情報テーブル（ＦＩＢ）１７１６Ａ及び１７１６Ｂは、それぞれ、アクティブ・カード９１０及びスタンバイ・カード９５０の上で同じように構築される。ＦＩＢ１７１６Ａ及び１７１６Ｂは、最良ルートに基づいており、各々のプロトコルのために管理距離を構成される。１つの実施形態において、ＲＴＭのプロトコル距離セッティング情報は構成情報として考えられ、持続データとして冗長にされる。第３次連想記憶装置（ＴＣＡＭ）１７０６Ａ及び１７０６Ｂは、それぞれアクティブ・カード９１０及びスタンバイ・カード９５０の上で同じように動作する。ＴＣＡＭ１７０６Ａ及び１７０６Ｂは、異なったモジュールからの持続データ、及びＲＴＭ１９４０Ａ及び１９４０ＢからのダイナミックＦＩＢデータに基づいて、プログラムされることができる。スタンバイ・カード９５０は（もしスタンバイで動作していれば）、ルータ１０４のために接続された物理的線を有しない。従って、スタンバイ・カード９５０は、インタフェース状態がアクティブ・カード９１０と同期するように処理するインタフェース・マネージャとなる責任を有する。即ち、スタンバイ・カード９５０は、そのモジュール及びアクティブ・カード９１０内のピア・モジュールへ情報を提供する。

ボーダー・ゲートウェイ・プロトコル（ＢＧＰ）の冗長性
ＢＧＰ冗長性の基本的要件
ＢＧＰは、インターネット上で最も広く使用されるルーティング・プロトコルである。ＢＧＰは、異なった自律システム（ＡＳ）のルータによって使用される外部ゲートウェイ・プロトコルである。ＢＧＰルータは、ネットワーク境界の間でパケットを回送する。従って、ＢＧＰルーティング又は転送テーブルは非常に大きく、何百万というルートを記憶することができる。しかし、ＢＧＰは、他のルーティング・プロトコルとは異なった難問を提供する。ＢＧＰは、接続及び信頼できるデータ転送を行うためＴＣＰを使用する。その結果、もしＢＧＰがピアとのＴＣＰ接続を失うと、ピアは、その隣接ピアから学習した全てのルートを即時にドロップすることによって反応する。この理由により、ＢＧＰルーティング・プロトコル冗長性を実現するためには、ＴＣＰも冗長にされて、ＢＧＰによって学習されたルートがアクセス不能になるのを回避しなければならない。

次の実施形態において、図９に示された冗長性プラットフォーム９００は、ＢＧＰ及びＴＣＰプロトコル冗長性を実現するサポートを提供する。冗長性プラットフォーム９００によって、スタンバイ・カード９５０は、サービス停止を構成しないような十分短い時間でＢＧＰルーティング及び転送情報を再学習することができる。更に、冗長性プラットフォーム９００は、次の動作をサポートして、ＢＧＰ及びＴＣＰプロトコル冗長性を獲得させる。

ＴＣＰレベル冗長性の要件
ＴＣＰレベルの冗長性は、ＢＧＰルーティング・プロトコル冗長性を実現するための冗長性追加レベルである。次の実施形態は、冗長ノード１０４におけるＢＧＰとＴＣＰとの間の例示的インタラクションを示す。

図２０の２０００は、ＢＧＰ、ＴＣＰ、及びＩＰ間の例示的インタラクションを示す。説明目的のために、２０００は、アクティブ・カード９１０が「アクティブ・モード」にあると考える。図２０を参照すると、２０００は、３つのメッセージをＴＣＰ１９３２Ａへ送信しているＢＧＰ１７２６Ａを示す。メッセージ１は１９バイトの長さである。メッセージ２は７０バイトの長さであり、メッセージ３は２６バイトであって、全部で１１５バイトである。

ＴＣＰ１９３２Ａはバイト・ストリーム・プロトコルである。ＴＣＰ１９３２Ａは、ＢＧＰ１７２６Ａからの３つのメッセージをバイトのストリームとして考える。例えば、ＴＣＰ１９３２Ａは、ＢＧＰ１７２６Ａからの１１５バイトを２つのメッセージとしてＩＰ１９３０Ａへ送信することができる。メッセージ１は８５バイトを有し、メッセージ２は３０バイトを有する。従って、ＩＰ１９３０ＡはＴＣＰ１９３２Ａから２つのメッセージを受信することができる。ＩＰ１９３０Ａは、２つのメッセージを送信バッファ２００２の中に一時的に記憶することができる。

ＴＣＰ１９３２Ａはメッセージを連続バイト・ストリームとして考えるので、ＴＣＰ１９３２Ａはメッセージ内にシーケンス番号を記憶して、メッセージがバイト・ストリームのどこに位置するかを示すことができる。例えば、ＴＣＰ１９３２Ａは、次の送信番号（ＮＳ）及び次の受信番号（ＮＲ）を記憶して、メッセージの順序を決定することができる。ＮＳ番号は、メッセージ又はパケットを識別する識別子である。ＮＲ番号は、遠隔のピアから受信されたバイト・ストリームの中の次のメッセージ又はパケットを識別する識別子である。図２０を参照すると、ＩＰ１９３０Ａへのメッセージ１は、ランダムに生成されたＮＳ番号＝１０００を有する。もしピア・ノードがＮＳ番号＝１０００を有するメッセージ１を受信すれば、ピア・ノードは、次のメッセージ（即ち、メッセージ２）がＮＳ＝１０８５を有しなければならないことを知る。そうでなければ、ピア・ノードは、メッセージがメッセージ１から順序をはずれており、何かが誤っていると決定するであろう。

ＴＣＰ１９３２Ａが使用することのできる他のパラメータは、ウィンドウ・サイズである。ウィンドウ・サイズは、ＴＣＰ１９３２Ａがピア・ノードから受信通知を受信する前に送信することのできる最大数のバイトである。ウィンドウ・サイズ・パラメータは、ピアとの間で交渉されることができる。例えば、ウィンドウ・サイズは８Ｋ又は１６Ｋであることができる。１つの実施形態において、ＢＧＰ１７２６Ａ、ＴＣＰ１９３２Ａ、ＩＰ１９３０Ａ、及び送信バッファ２００２の間を通されるデータは、メッセージが受信ピア・ノードによって受信を通知されるまで、スタンバイ・カード９５０のなかへ複写又はコピーされる。

図２１Ａは、１つの実施形態に従って受信又は生成されたＢＧＰ状態変化を複写する動作２１００のフローチャートである。次の動作２１００は、前述したようなアクティブ・カード９１０及びスタンバイ・カード９５０を有する冗長ノード１０４によって実現されることができる。説明目的のため、動作２１００は動作２１０２で始まる。動作２１０２において、ＢＧＰ状態変化は、アクティブ・カード９１０によって受信又は生成される。例えば、ピア・ノードは、ＢＧＰルートがもはや状態変化として利用できないことを、冗長ノード１０４へ送信することができる。

動作２１０４において、受信又は生成されたＢＧＰ状態変化は、アクティブ・カード９１０からスタンバイ・カード９５０へ複写される。例えば、冗長性プラットフォーム９００は、前述したようなＢＧＰ状態変化の「デルタ更新」をスタンバイ・カード９５０に対して実行することができる。

図２１Ｂは、１つの実施形態に従って受信又は生成されたＴＣＰ状態変化を複写する動作２１５０のフローチャートである。説明目的のために、動作２１５０は動作２１５２で始まる。動作２１５２において、ＴＣＰ状態変化はアクティブ・カード９１０によって受信又は生成される。例えば、ピア・ノードは、ＴＣＰ接続がドロップされ、もはや状態変化として利用できないことを、冗長ノード１０４へ送信することができる。

動作２１０４において、受信又は生成されたＴＣＰ状態変化は、アクティブ・カード９１０からスタンバイ・カード９５０へ複写される。例えば、冗長性プラットフォーム９００は、前述したようなＴＣＰ状態変化の「デルタ更新」をスタンバイ・カード９５０に対して実行することができる。

前記の動作２１００及び２１５０によって、ＢＧＰ及びＴＣＰ状態変化のＢＧＰ及びＴＣＰ冗長性が可能になる。他の実施形態において、ＢＧＰ及びＴＣＰメッセージの選択的冗長性を提供するために、前記の動作２１００及び２１５０を実行することができる。即ち、スタンバイ・カード９５０の中で、ＢＧＰ及びＴＣＰメッセージの幾つか又は全てを冗長にすることができる。

送信されているＢＧＰメッセージのＴＣＰロック・ステップ
１つの実施形態において、ＴＣＰレベルの冗長性の要件は、ＢＧＰ及びＴＣＰの「ロック・ステップ」要件である。ロック・ステップ要件は、アクティブ・カード９１０によって送信又は受信される全てのメッセージについて、アクティブ・カード９１０が他のメッセージを送信又は受信する前に、スタンバイ・カード９５０が送信又は受信されたメッセージを記憶したことの受信通知が存在しなければならないことを要求する。もし切り替えが起こり、スタンバイ・カード９５０がメッセージを保存しなかったならば、冗長性は破壊される。

図２２は、アクティブ・カード９１０の上で動作しているアクティブＴＣＰと、スタンバイ・カード９５０の上で動作しているスタンバイＴＣＰとの間の例示的対話を示し、ピア・ノードへ送信されているＢＧＰメッセージのロック・ステップ要件を示す。図２２を参照すると、対話２２００は、アクティブＢＧＰ１７２６ＡがＢＧＰメッセージ（メッセージ１）をアクティブＴＣＰ１９３２Ａへ送信していることを示す。アクティブ・カード９１０は、メッセージ１をルータ又はピア・ノードへ送信することを計画している。アクティブＴＣＰ１９３２Ａはメッセージ１をスタンバイＴＣＰ１９３２Ｂへ送信し、メッセージ１をスタンバイ・カード９５０へ複写できるようにする。スタンバイ・カード９５０は、メッセージ１を複写したことの受信通知をアクティブＴＣＰ１９３２Ａへ送信する。

１つの実施形態において、冗長性プラットフォーム９００を有する冗長ノード１０４は、メッセージ１が複写されたことの受信通知を受信するまで、ＩＰ１９３２Ａを介してメッセージ１をピア・ノードへ送信しない。更に、冗長ノード１０４は、メッセージ１が保存されたことの受信通知をスタンバイＴＣＰ１９３２Ｂから受信するまで、他のメッセージ（即ち、メッセージ２）を送信しない。前述したように、もしメッセージ１がスタンバイ・カード９５０の中に保存されなければ、冗長性は破壊され、もし切り替えが起これば、スタンバイ・カード９５０はアクティブ・カード９１０の現在の状態で動作を再開することができない。

従って、アクティブＴＣＰ１９３２Ａがメッセージ１の受信通知を受信した後、それは「ａｃｋ」をＢＧＰ１７２６Ａへ送信し、次にＢＧＰ１７２６Ａが第２のメッセージ２を送信することができる。同様に、アクティブ・カード９１０は、スタンバイＴＣＰ１９３２Ｂがスタンバイ・カード９５０の中にメッセージ２を記憶したことの受信通知を受信するまで、ＩＰ１９３２Ａを介してメッセージをピア・ノードへ送信しないであろう。そのようなロック・ステップを維持することによって、ピア・ノードへの送信を計画されているアクティブ・カード９１０の中の同じＢＧＰメッセージをスタンバイ・カード９５０が有することが保証される。

受信されているＢＧＰメッセージのＴＣＰロック・ステップ
図２３は、アクティブ・カード９１０の上で動作しているアクティブＴＣＰと、スタンバイ・カード９５０の上で動作しているスタンバイＴＣＰとの間の例示的対話を示し、ピア・ノードから受信されているＢＧＰメッセージのロック・ステップ要件を示す。図２３を参照すると、対話２３００は、アクティブ・カード９１０の中のアクティブＴＣＰ１９３２Ａが遠隔ノード１０２ＡからＢＧＰメッセージ（メッセージＡ）を受信していることを示す。ＴＣＰ１９３２Ａが遠隔ノード１０２Ａへ受信通知を送信する前に、ＴＣＰ１９３２Ａは、メッセージＡがスタンバイ・カード９５０の中に複写されたことを確認しなければならない。もしメッセージＡがスタンバイ・カード９５０の中に複写されなければ、冗長性は破壊される。

従って、ＴＣＰ１９３２Ａは、そのスタンバイＴＣＰ１９３２ＢへメッセージＡを送信する。スタンバイＴＣＰ１９３２Ｂは、スタンバイ・カード９５０の中のスタンバイＢＧＰ１７２６ＢへメッセージＡを送信する。次に、スタンバイＴＣＰ１９３２Ｂは、メッセージＡが複写されたことの受信通知をアクティブＴＣＰ１９３２Ａへ送信する。スタンバイＴＣＰ１９３２Ｂから受信通知を受信した後、アクティブＴＣＰ１９３２Ａは、メッセージＡをアクティブＢＧＰ１７２６Ａへ送信し、次にメッセージＡの受信通知を遠隔ノード１０２Ａへ送信することができる。

もし２番目のＢＧＰメッセージ（メッセージＢ）がアクティブＴＣＰ１９３２Ａによって受信されると、それはメッセージＡと同じ動作を実行し、メッセージＢをスタンバイ・カード９５０の中に複写して、メッセージＢが複写されたことの受信通知を待つ。スタンバイＴＣＰ１９３２Ｂから受信通知を受信した後、アクティブＴＣＰ１９３２Ａは、メッセージＢをアクティブＢＧＰ１７２６Ａへ送信し、次にメッセージＢへの受信通知を遠隔ノード１０２Ａへ送信することができる。メッセージＢの受信通知は、メッセージＡが複写されるまで起こらないであろう。従って、そのようなロック・ステップを維持することによって、アクティブ・カード９１０によって受信された同じＢＧＰメッセージをスタンバイ・カード９５０が有することが保証される。

ＢＧＰプロトコル冗長性の増分（デルタ）更新
図２４及び図２５は、前記の図２２によって示されるＴＣＰロック・ステップ要件を実現するピア・ノードへ送信されている個々のＢＧＰメッセージをデルタ更新する変形の実施形態を示す。図２６は、前記の図２３で示されたＴＣＰロック・ステップ要件を実現するピア・ノードから受信されている個々のＢＧＰメッセージをデルタ更新する実施形態を示す。

図２４は、ＢＧＰアーキテクチャ２４００を示し、１つの実施形態に従ってピア・ノードへ送信されている個々のＢＧＰメッセージのデルタ更新を示す。ＢＧＰアーキテクチャ２４００は、図９で示される冗長性プラットフォーム９００の上で動作する。次のアーキテクチャ２４００において、アクティブ・カード９１０上で走っているＢＧＰプロトコルによって生成された各々のＢＧＰメッセージは、スタンバイ・カード９５０の中へ更新又は複写される。ＢＧＰメッセージは多数のバッファ・ステージを通過する。これは全てのステージで冗長性を必要とする。

図２４を参照して、アーキテクチャ２４００の動作が、参照点１〜３４に関して今から説明される。参照点１において、ＢＧＰ１９２６Ａは、ＢＧＰバッファ１９２７Ａに記憶されるメッセージを送信する。参照点２において、メッセージはスタンバイ・カード９５０の中にミラーリング又は複写されなければならない。従って、メッセージは冗長性マネージャ９２０へ送信される。参照点３において、冗長性マネージャ９２０は、カード間リンク（例えば、「ワイヤ」）を介してスタンバイ・カード９５０の中のピア冗長性マネージャ９６０へメッセージを送信する。冗長性マネージャ９６０は、ここでＢＧＰバッファ１９２７Ｂをメッセージで更新し、それによってＢＧＰバッファ１９２７Ａの中に記憶されたメッセージのミラーリング・コピーを有する。

参照点５において、メッセージが更新されたことの受信通知が冗長性マネージャ９６０へ送信される。参照点６において、スタンバイ・カード９５０の中の冗長性マネージャ９６０は、アクティブ・カード９１０の中の冗長性マネージャ９２０へ受信通知を送信する。従って、冗長性マネージャ９２０は、受信通知をＢＧＰバッファ１９２７の中に記憶する。その後、メッセージはソケット・キュー２４０３Ａへ渡される。

ここで、上記の動作は参照点９〜２８で実行され、メッセージはアクティブ・カード９１０内のソケット・キュー２４０３Ａ、ソケット・バッファ２４０４Ａ、及びＴＣＰバッファ１９３３Ａを通して伝搬される。従って、ソケット・キュー２４０３Ａ、ソケット・バッファ２４０４Ａ、及びＴＣＰバッファ１９３３Ａを通して伝搬されているメッセージは、スタンバイ・カード９５０内のピア・ソケット・キュー２４０３Ｂ、ソケット・バッファ２４０４Ｂ、及びＴＣＰバッファ１９３３Ｂへミラーリング又は複写される。メッセージがＴＣＰバッファ１９３３Ａに記憶された後、参照点２９〜３４において、メッセージはＩＰ１９３０Ａ、プロトコル・チェーン・マネージャ（ＰＣＭ）キュー２４０５Ａ、ＰＣＭ２００６Ａ、ドライバ・キュー２４０７Ａ、及びドライバ２４０８Ａを介してワイヤ上をピア・ノードへ渡される。ソケット・キューは、ＢＧＰプロトコルのために端点情報を記憶する。その場合、端点情報は他のノードの上を走っているＢＧＰプロトコルに関連している。ＰＣＭは、ルーティング・プロトコルの各々のタイプに指定されたメッセージを管理する。ＰＣＭキューは、個々のルーティング・プロトコルのためにメッセージを記憶する。

図２５は、例示的ＢＧＰアーキテクチャ２５００を示し、他の実施形態に従ったデータ送信冗長性である個々のＢＧＰメッセージのデルタ更新を示す。例示的ＢＧＰアーキテクチャ２５００は、ＢＧＰとＴＣＰ／ＩＰとの間のバッファ・ステージの数を低減する。特に、ＢＧＰは、ＴＣＰ／ＩＰによって使用されるバッファへメッセージ（「パケット」）を直接送信することができる。例えば、バッファは「リング・バッファ」であることができる。ＢＧＰはリング・バッファへの「書き込み」ポインタを制御することができ、ＴＣＰ／ＩＰはリング・バッファへの「読み出し」ポインタを制御することができる。

図２５を参照して、アーキテクチャ２５００の動作は、ここで参照点１〜１３に関して説明される。参照点１において、ＢＧＰ１９２６Ａは、送信データ・リング２５０８Ａへ記憶されるメッセージ「パケット」を送信する。参照点２において、メッセージはスタンバイ・カード９５０の中へミラーリング又は複写されなければならない。従って、メッセージは冗長性マネージャ９２０へ送信される。参照点３において、冗長性マネージャ９２０は、カード間リンク（例えば、「ワイヤ」）を介して、スタンバイ・カード９５０の中のピア冗長性マネージャ９６０へメッセージを送信する。冗長性マネージャ９６０は、ここで送信データ・リング２１０８Ｂをメッセージで更新し、それによって送信データ・リング２５０８Ａに記憶されたメッセージのミラー・コピーが実現される。

参照点５において、メッセージが更新されたことの受信通知が冗長性マネージャ９６０へ送信される。参照点６において、スタンバイ・カード９５０の中の冗長性マネージャ９６０は、アクティブ・カード９１０の中の冗長性マネージャ９２０へ受信通知を送信する。従って、冗長性マネージャ９２０は、送信データ・リング２５０８Ａの中に受信通知を記憶する。その後、メッセージは、ＴＣＰ／ＩＰ１９３０Ａ、ＰＣＭキュー２４０５Ａ、ＰＣＭ２４０６Ａ、ドライバ・キュー２４０７Ａ、及びドライバ２４０８Ａを通されてワイヤ上をピア・ノードへ渡される。

図２６は、１つの実施形態に従ったデータ受信の例示的ＢＧＰアーキテクチャ２６００を示す。例示的ＢＧＰアーキテクチャ２６００は、データ・リング・バッファ（即ち、受信データ・リング・バッファ２６６０Ａ及び２６６０Ｂ）が追加されたＢＧＰアーキテクチャ２５００と同じである。特に、ＢＧＰは、データ・リング・バッファからＢＧＰメッセージを受信することができる。

図２６を参照して、アーキテクチャ２６００の動作が、ここで参照点１〜１４に関して説明されるであろう。参照点１において、スタンバイ・カード９１０はドライバ２４０８Ａによってワイヤ接続からＢＧＰメッセージを受信する。参照点２において、ドライバ２４０８ＡはメッセージをＰＣＭキュー２４０５Ａへ送信する。参照点３において、ＰＣＭキュー２４０５ＡはメッセージをＰＣＭ２４０６Ａへ送信する。参照点４において、ＰＣＭ２４０６ＡはメッセージをＴＣＰ／ＩＰキュー２６３１Ａへ送信する。参照点５において、ＴＣＰ／ＩＰキュー２６３１ＡはメッセージをＴＣＰ／ＩＰ１９３０Ａへ送信する。参照点６において、ＴＣＰ／ＩＰ１９３０Ａはメッセージをデータ受信リング・バッファ２６６０Ａへ送信する。

参照点７において、データ受信リング・バッファ２６６０Ａは、メッセージを冗長性マネージャ９２０へ送信する。参照点８において、冗長性マネージャ９２０は、複写されるスタンバイ・カード９５０の中の冗長性マネージャ９６０へメッセージを送信する。参照点９において、冗長性マネージャ９６０はメッセージをデータ受信リング・バッファ２６６０Ｂへ送信する。参照点１０において、メッセージの受信通知が送信リング・データ・バッファ２５５０Ｂの中に記憶される。参照点１１及び１１ａにおいて、メッセージがＢＧＰ１７２６Ｂへ送信され、受信通知が冗長性マネージャ９６０へ送信される。参照点１２において、受信通知が冗長性マネージャ９２０へ送信される。

参照点１３において、冗長性マネージャ９２０はデータ受信リング・バッファ２６６０Ａへ受信通知を送信する。参照点１４において、冗長性マネージャ９６０からの受信通知が送信リング・バッファ２５５０Ａへ記憶される。参照点１５において、メッセージがＢＧＰ１７２６Ａへ送信される。前記の動作において、アクティブ・カード９１０によって受信されたメッセージは、ＢＧＰ１７２６Ｂによって受信されるまで、ＢＧＰ１７２６Ａへ送信されないであろう。更に、前記の動作は、ピア・ノード又は隣接ノードから受信されたＢＧＰメッセージの増分更新を示す。

図２７は、１つの実施形態に従ってＢＧＰメッセージへコミットする動作２７００のフローチャートである。以下の動作２７００は、前述したようなアクティブ・カード９１０及びスタンバイ・カード９５０を有する冗長ノード１０４によって実行されることができる。説明目的のために、動作２７００は、図１９を参照し、動作２７０２で始まる。

動作２７０２において、ＢＧＰメッセージがアクティブ・カード９１０によって受信される。アクティブ・カード９１０は、上位レイヤーを通ってアプリケーション（ＢＧＰ）、即ちＢＧＰ１７２６Ａまでメッセージを送信する。アクティブ・カード９１０は、更に、スタンバイ・カード９５０の中のＴＣＰ１９３２Ｂへメッセージを送信する。

動作２７０４において、アクティブ・カード９１０はメッセージへコミットする。

動作２７０６において、スタンバイ・カード９５０はメッセージを受信し、ＴＣＰ１９３２Ｂからスタンバイ上のアプリケーション（ＢＧＰ）、即ちＢＧＰ１７２６Ｂへメッセージを送信する。

動作２７０８において、スタンバイ・カード９５０はメッセージへコミットし、そのコミットメントをアクティブ・カード９５０内のＴＣＰ１９３２Ａへ送信する。

動作２７１０において、スタンバイ・カード９１０はスタンバイ・カード９５０からコミットメントを受信し、そのコミットメントをシステム・コミットメントへ変換する。

動作２７１２において、アクティブ・カード９１０はシステム・コミットメントを遠隔ピアへ送信する。

上記の動作２７００は、冗長性マネージャ９２０及び９６０を使用し、アクティブ・カード９１０とスタンバイ・カード９５０との間で、メッセージの転送を促進する。他の実施形態において、動作２７０２〜２７１０は、他のメッセージのために繰り返されることができるが、特定のメッセージのシステム・コミットメントは、スタンバイ・カード９５０がコミットするまで、ピア・ノードへ送信されないであろう。上記の動作によって、ＢＧＰメッセージは、アクティブ・カード９１０及びスタンバイ・カード９５０の双方の上で、上位レイヤーへ迅速に渡される。

ＢＧＰプロトコル冗長性のためのブート・シーケンス／バルク更新
図２８は、１つの実施形態に従ってＢＧＰプロトコル冗長性のためにバルク更新を実行する動作２８００のフローチャートである。説明目的のために、動作２８００は、アクティブ・カード９１０及びスタンバイ・カード９５０がルータ１０４の中で動作しているブート・シーケンスを参照する。

図２８を参照すると、動作２８０２において、ＢＧＰ及びＴＣＰデータベースは、アクティブ・カード９１０からスタンバイ・カード９５０へ複写される。例えば、図１９で示されるように、アクティブ・カード９１０内のＢＧＰ ＲＤＢ１９２７Ａ及びＢＧＰ ＰＤＢ１７３１Ａは、スタンバイ・カード９５０内のＢＧＰ ＲＤＢ１９２７Ｂ及びＢＧＰ ＰＤＢ１７３１Ｂへ複写される。ＢＧＰデータベースを複写するため、冗長性プラットフォーム９００のところで説明したようなバルク更新動作を使用することができる。更に、アクティブ・カード９１０内のＴＣＰ ＲＤＢ１９３３Ａ及びＴＣＰ ＰＤＢ１９２６Ａが、ＢＧＰデータベースに対する同じ動作を使用して、スタンバイ・カード９５０内のＴＣＰ ＲＤＢ１９３３Ｂ及びＴＣＰ ＰＤＢ１９２６Ｂへ複写される。代替的に、不揮発性メモリ及び他のデータベースも複写することができる。

動作２８０４において、受信又は送信されたＢＧＰメッセージがキューにされるので、それらはバルク更新プロセスの後でスタンバイ・カード９５０の中で作られることができる。動作２８０６において、受信又は送信されたＢＧＰメッセージが、図２４〜図２６で示されたようなデルタ更新動作を使用して、スタンバイ・カード９５０へデルタ更新される。

中間システム−中間システム・プロトコル（ＩＳ−ＩＳ）の冗長性
ＩＳ−ＩＳプロトコル冗長性の基本的要件
ＩＳ−ＩＳプロトコルは、リンクステートプロトコルである。ＩＳ−ＩＳプロトコルパケットを生成するエリア／ドメインにおけるルータは、パケットでエリア／ドメイン内のすべてのルータに送出する。すなわち、１つのＩＳ−ＩＳルータによって生成されるパケットは、そのエリア／ドメイン内のあらゆるＩＳ−ＩＳルータに格納される。従って、各ＩＳ−ＩＳルータは、他のＩＳ−ＩＳルータのネットワークの完全で、そして、無矛盾のビューを有している。これらのパケットは、リンクステートプロトコル（ＬＳＰ）と呼ばれる。ＬＳＰパケットは、パケットを生成するＩＳルータについての情報を含んでいる。それ自体、ＩＳ−ＩＳプロトコルを実行する各ルータは、ＬＳＰデータベース、あるいは、ＬＳＰパケットを格納するＩＳ−ＩＳデータベースを含んでいる。

ＩＳ−ＩＳプロトコル冗長を有するために、待機コントローラシステムは、アクティブコントローラシステムにおけるコンフィギュレーション／グローバル情報、回線情報、隣接情報およびリンクステートパケット（ＬＳＰ）情報を維持するか、あるいは、知っている必要がある。コンフィギュレーション情報は、アクティブカード９１０のグローバルなステート、すなわち、アクティブ中か、あるいは、待機中かなどのグローバル情報を含んでいる。回線情報は、実行している回線のステートを含んでいる。たとえば、その回線は、使用可能か／使用禁止か。隣接情報は、アクティブの隣接についての情報、すなわち、その隣接者は誰かということを含んでいる。リンクステート情報は、ＬＳＰパケット情報を含んでいる。冗長プラットフォーム９００は、ＩＳ−ＩＳプロトコル冗長を維持するためのサポートを供給する。
ＩＳ−ＩＳプロトコル冗長のためのブートシーケンス／バルクアップデート
図２９は、１つの実施の形態により、ＩＳ−ＩＳプロトコル冗長のためのバルクアップデートを達成するオペレーション２９００のフローチャートを示している。説明のために、オペレーション２９００は、アクティブカード９１０および待機カード９５０が、ルータ１０４内で動作するブートシーケンスに適用している。

図２９を参照すると、オペレーション２９０２で、ＩＳ−ＩＳデータベースは、アクティブカード９１０から待機カード９５０に複製される。たとえば、図１９に示されるように、アクティブカード９１０におけるＩＧＰ ＲＤＢ １９４２Ａ、ＩＧＰ ＰＤＢ １９２４ＡおよびＦＩＢ １７１６Ａは、待機カード９５０におけるＩＧＰ ＲＤＢ１９４２Ｂ、ＩＧＰ ＰＤＢ １９２４ＢおよびＦＩＢ１７１６Ｂに複製される。ＩＧＰデータベースは、まさに、ＩＳ−ＩＳデータベース情報のために選択的にコピーされることが可能である。冗長プラットフォーム９００において説明されるようにバルクアップデートオペレーションは、ＩＧＰ ＩＳ−ＩＳデータベースを複製するのに使用されることが可能である。

オペレーション２９０４で、受信されるか、あるいは、送信されるあらゆるＩＳ−ＩＳメッセージは、バルクアップデートプロセス後、それらが待機カード９５０において作られることが可能なようにキューに入れられる。オペレーション２９０６で、受信されるか、あるいは、送信されるあらゆるＩＳ−ＩＳメッセージは、図２４から図２６に示されるようなデルタアップデートオペレーションを使用して、待機カード９５０にデルタアップデートされる。
ＩＳ−ＩＳプロトコル冗長のためのインクリメンタル（デルタ）アップデート
図３０は、１つの実施の形態により、受信されるか、あるいは、送信される個々のＩＳ−ＩＳメッセージのためのインクリメンタル（デルタ）アップデーティングを達成するオペレーション３０００のフローチャートを示している。説明のために、オペレーション３０００は、アクティブカード９１０および待機カード９５０を有するルータに適用している。

図３０を参照すると、オペレーション３００２で、ＩＳ−ＩＳメッセージは、受信されるか、あるいは、生成される。たとえば、ＩＳ−ＩＳプロトコルは、ＬＳＰを生成することが可能か、あるいは、ピアノードからＬＳＰを受信することが可能である。オペレーション３００４で、アクティブカード９１０は、ＬＳＰパケットを、隣接者として処理される待機カード９５０に送信する。従って、待機カード９５０は、ＬＳＰパケットを複製する。

最適経路の第１のプロトコル（ＯＰＳＦ）冗長
ＯＳＰＦプロトコル冗長のための基本必要条件
ＯＳＰＦプロトコルは、リンクステートドメイン内ルーティングプロトコルであり、そして、パケットを伝送して、受信するためのＩＰプロトコルをあてにする。ＯＳＰＦは、パケットの高信頼転送のためにＴＣＰ、あるいは、ＵＤＰを使用しない。ＯＳＰＦプロトコルは、ピアノードでネットワーク情報を交換することによって、ピアノード隣接者との隣接に基づかせる。ＯＳＰＦは、ＦＩＢにアップデートし、そして、他のプロトコルは、ルーティングテーブルマネージャ（ＲＴＭ）によって作られる。ＯＳＰＦプロトコル冗長のための基本必要条件は、ピアノード上のＲＴＭで待機カード９１０上のＲＴＭのためにＯＳＰＦプロトコルサービスを乱されないで維持することである。それゆえに、ＯＳＰＦプロトコル冗長のために、すべてのプロトコルステート情報、ＯＳＰＦデータベース情報およびコンフィギュレーション情報は、待機カード９５０内に維持される必要がある。

ＯＳＰＦプロトコル冗長のためのブートシーケンス／バルクアップデート
図３１は、１つの実施の形態により、ＯＳＰＦプロトコル冗長のためのバルクアップデーティングを達成するオペレーション３１００のフローチャートを示している。説明のために、オペレーション３１００は、アクティブカード９１０および待機カード９５０がルータ１０４内で動作するブートシーケンスに適用している。

図３１を参照すると、オペレーション３１０２で、ＯＳＰＦデータベースは、アクティブカード９１０から待機カード９５０に複製される。たとえば、図１９に示されるように、アクティブカード９１０におけるＩＧＰ ＲＤＢ １９４２Ａ、ＩＧＰ ＰＤＢ １９２４ＡおよびＦＩＢ １７１６Ａは、待機カード９５０におけるＩＧＰ ＲＤＢ１９４２Ｂ、ＩＧＰ ＰＤＢ １９２４ＢおよびＦＩＢ１７１６Ｂに複製される。ＩＧＰデータベースは、まさに、ＯＳＰＦデータベース情報のために選択的にコピーされることが可能である。冗長プラットフォーム９００において説明されるようなバルクアップデートオペレーションは、ＩＧＰ ＯＳＰＦデータベースを複製するのに使用されることが可能である。

オペレーション３１０４で、受信されるか、あるいは、生成されるあらゆるＯＳＰＦメッセージは、バルクアップデートプロセス後、それらが待機カード９５０において作られることが可能なようにキューに入れられる。オペレーション３１０６で、受信されるか、あるいは、送信されるあらゆるＯＳＰＦメッセージは、図２４から図２６に示されるようなデルタアップデートオペレーションを使用して、待機カード９５０にデルタアップデートされる。

ＯＳＰＦプロトコル冗長のためのインクリメンタル（デルタ）アップデート
図３２は、１つの実施の形態により、受信されるか、あるいは、送信される個々のＯＳＰＦメッセージのためのインクリメンタル（デルタ）アップデーティングを達成するオペレーション３２００のフローチャートを示している。説明のために、オペレーション３２００は、アクティブカード９１０および待機カード９５０を有するルータに適用している。図３２を参照すると、オペレーション３２０２で、ＯＳＰＦメッセージは、受信されるか、あるいは、生成される。オペレーション３００４で、アクティブカード９１０は、冗長プラットフォーム９００で説明されるようなデルタアップデートを使用して、受信されたか、あるいは、生成されたＯＳＰＦメッセージを待機カード９５０に送信する。上記に記述されたルーティングプロトコル冗長テクニックおよびオペレーションは、本質的に例示的であり、そして、たとえば、Ｒｏｕｔｉｎｇ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ルーティングインターネットプロトコル）（ＲＩＰ）などの他のタイプのルーティングプロトコルに適用されることが可能である。たとえば、冗長プラットフォーム９００は、上記に記述されるようなＲＩＰ情報のためのバルク、デルタ、非永続、および永続データアップデーティングを達成するのに使用されることが可能である。

上記ルータおよびルーティングプロトコル冗長オペレーションは、プロセッサによって実行されるソフトウェアルーチンとして実施されることが可能である。所定のプロセッサのために、ソフトウェアルーチンは、固定記憶装置などのストレージデバイスに格納されることが可能である。別の方法として、ソフトウェアルーチンは、ディスケット、ＣＤ−ＲＯＭ、磁気テープ、ディジタルビデオディスク、あるいは、汎用ディスク（ＤＶＤ）、レーザディスク、ＲＯＭ、Ｆｌａｓｈ（フラッシュ）メモリ、他の同様なメモリデバイスなどのあらゆる機械読取り可能ストレージ媒体に格納される機械実行可能命令でよい。一連の命令は、局部的に格納される必要はなく、そして、ネットワーク上のサーバなどのリモートストレージデバイス、ＣＤ−ＲＯＭデバイス、フロッピーディスクなどから受領されることが可能である。その命令は、ストレージデバイスから一時記憶装置にコピーされ、そして、次に、アクセスされて、プロセッサによって実行されることができる。１つの実施の形態において、このようなソフトウェアルーチンは、Ｃプログラミング言語で書き込みされることが可能である。とはいえ、これらのルーチンは、広範囲にわたる様々なプログラミング言語のいずれかで実施されることができることは高く評価されるべきことである。

別の実施の形態について、ルータおよびルーティングプロトコル冗長オペレーションは、離散型ハードウェア、あるいは、ソフトウェアにおいて実施されることが可能である。たとえば、１つ以上の専用集積回路（ＡＳＩＣｓ）は、上記に記述された冗長オペレーションを達成するためにプログラムされることが可能である。別の例示において、冗長オペレーションは、追加の回路基板上の１つ以上のＡＳＩＣｓにおいて実施されることが可能であり、そして、その回路基板は、上記に記述されるような冗長を有するルータ、あるいは、ノードに挿入されることが可能である。別の例示において、書替え可能ゲートアレイ（ＦＰＧＡｓ）、あるいは、静的プログラマブルゲートアレイ（ＳＰＧＡ）は、ここに記述されている冗長オペレーションを実施するのに使用されることが可能である。さらに別の例示において、ハードウェアとソフトウェアの組合せが、ここに記述される冗長オペレーションを実施するのに使用されることが可能である。

このように、ルータおよびルーティングプロトコル冗長について記述してきた。前述の明細書において、本発明は、特定の例示的な実施の形態を参照して記述してきた。しかしながら、様々な修正および変更が、添付されている請求の範囲に述べられるような本発明の広範囲にわたる精神と範囲から逸脱することなく行われることができることは明らかだ。明細書および図面は、従って、制限的な意味ではなく、例示としての意味であると考えられるべきである。

本発明を実施することのできる例示的ネットワークを示す。 １つの実施形態に従って図１に示されるノードによって使用されることのできるアーキテクチャレイヤーモデルを示す。 １つの実施形態に従った冗長ノードの基本動作のフローチャートである。 アクティブ・カードからスタンバイ・カードへルーティング・プロトコル情報を複写することを示す図である。 １つの実施形態に従ってルーティング・プロトコル状態変化情報を複写する動作のフローチャートである。 １つの実施形態に従ってスタンバイ・コントローラ・システムへの高速切り替えを有する図３の再開動作を詳細な動作で示すフローチャートである。 １つの実施形態に従って障害及び切り替えを認識しないようにピア・ノードをだますことを示す図である。 他の実施形態に従って障害及び切り替えを認識しないようにピア・ノードをだますことを示す図である。 １つの実施形態に従ってピア・ノードへコミットメントを送信する動作のフローチャートである。 １つの実施形態に従ってアクティブ・コントローラ・システム及びスタンバイ・コントローラ・システムを有するネットワーク装置を示す。 １つの実施形態に従ったネットワーク装置の冗長性プラットフォームを示す。 １つの実施形態に従ったブート・シーケンス動作のフローチャートである。 他の実施形態に従ったブート・シーケンス動作のフローチャートである。 １つの実施形態に従ってアクティブ・カードがスタンバイ・カードへ猶予切り替えを実行する動作のフローチャートである。 １つの実施形態に従ってアクティブ・カードがスタンバイ・カードへ猶予切り替えを実行する動作のフローチャートである。 １つの実施形態に従ってスタンバイ・カードが猶予切り替えを実行する動作のフローチャートである。 １つの実施形態に従ってスタンバイ・カードが猶予切り替えを実行する動作のフローチャートである。 １つの実施形態に従ってスタンバイ・カードが非猶予切り替えを実行する動作のフローチャートである。 １つの実施形態に従ってスタンバイ・カードへ持続情報を更新する動作のフローチャートである。 １つの実施形態に従ってスタンバイ・カードへ非持続情報を更新する動作のフローチャートである。 １つの実施形態に従ってエラー処理を実行する動作のフローチャートである。 １つの実施形態に従ったネットワーク装置内のルーティング・プロトコル・インタラクションを示す図である。 １つの実施形態に従ったアクティブ・カード及びスタンバイ・カード間のルーティング・プロトコル・インタラクションを示す図である。 １つの実施形態に従ったルーティング・プロトコル冗長性のアーキテクチャを示す。 ＢＧＰ、ＴＣＰ、及びＩＰ間の例示的インタラクションを示す図である。 １つの実施形態に従って受信又は生成されたＢＧＰ状態変化を複写する動作のフローチャートである。 １つの実施形態に従って受信又は生成されたＴＣＰ状態変化を複写する動作のフローチャートである。 アクティブ・カード上で動作しているアクティブＴＣＰと、スタンバイ・カード上で動作しているスタンバイＴＣＰとの間の対話の１つの実施形態を示し、ピア・ノードへ送信されているＢＧＰメッセージのロック・ステップ要件を示す図である。 アクティブ・カード上で動作しているアクティブＴＣＰと、スタンバイ・カード上で動作しているスタンバイＴＣＰとの間の対話の１つの実施形態を示し、ピア・ノードから受信されているＢＧＰメッセージのロック・ステップ要件を示す図である。 １つの実施形態に従ってピア・ノードへ送信されている個々のＢＧＰ情報のデルタ更新を示すＢＧＰアーキテクチャを示す。 １つの実施形態に従ってピア・ノードへ送信されている個々のＢＧＰ情報のデルタ更新を示すＢＧＰアーキテクチャを示す。 １つの実施形態に従ってピア・ノードから受信されている個々のＢＧＰ情報のデルタ更新を示すＢＧＰアーキテクチャを示す。 １つの実施形態に従ってＢＧＰメッセージへコミットするフローチャートである。 １つの実施形態に従ってＢＧＰプロトコル冗長性のためにバルク更新を実行する動作のフローチャートである。 １つの実施形態に従ってＩＳ−ＩＳプロトコル冗長性のためにバルク更新を実行する動作のフローチャートである。 １つの実施形態に従って受信又は送信されているＩＳ−ＩＳメッセージのためにデルタ更新を実行する動作のフローチャートである。 １つの実施形態に従ってＯＳＰＦのためにバルク更新を実行する動作のフローチャートである。 １つの実施形態に従って受信又は送信されているＯＳＰＦメッセージのためにデルタ更新を実行する動作のフローチャートである。

符号の説明

１０４ ネットワーク装置（ルータ）
２２０ ルーティング・プロトコル
９００ 冗長性プラットフォーム

Claims (19)

1. ピアノードからルーティングプロトコル状態変化を受信し、
   前記ルーティングプロトコル状態変化を第２のコントローラに送信し、
   前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラから受信し、
   前記第２のコントローラから前記コミットメントを受信した後に前記ルーティングプロトコル状態変化を完遂し、
   前記ルーティングプロトコル状態変化を完遂した後に前記コミットメントを前記ピアノードに送信するように構成された第１のコントローラ。
2. 別のコントローラから前記コミットメントを受信した後に前記ルーティングプロトコル状態変化をルーティングプロトコルに送信するように構成された請求項１に記載の第１のコントローラ。
3. 前記ピアノードから前記ルーティングプロトコル状態変化を受信した後に前記ルーティングプロトコル状態変化をルーティングプロトコルに送信するように構成された請求項１に記載の第１のコントローラ。
4. 前記ルーティングプロトコル状態変化が、境界ゲートウェイプロトコル（ＢＧＰ）状態変化、ルーティングインターネットプロトコル（ＲＩＰ）状態変化、最適経路の第１のプロトコル（ＯＳＰＦ）状態変化、あるいは、中間システム間のプロトコル（ＩＳ−ＩＳ）状態変化を含む請求項１に記載の第１のコントローラ。
5. ルーティングプロトコルメッセージを受信又は生成し、当該受信又は生成したルーティングプロトコルメッセージを前記第２のコントローラに選択的に複製する請求項１に記載の第１のコントローラ。
6. 故障を検出するように構成された請求項１に記載の第１のコントローラであって、
   前記第２のコントローラが、故障前に、前記第１のコントローラにおけるのと同一のルーティングプロトコル状態変化を維持するように構成されている、
   請求項１に記載の第１のコントローラ。
7. ピアノードのためにルーティングプロトコル状態変化を生成し、
   前記ルーティングプロトコル状態変化を第２のコントローラに送信し、
   前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラから受信し、
   前記第２のコントローラから前記コミットメントを受信した後に前記ルーティングプロトコル状態変化を完遂し、
   前記ルーティングプロトコル状態変化を完遂した後に前記コミットメントを前記ピアノードに送信するように構成された第１のコントローラ。
8. 前記第２のコントローラから前記コミットメントを受信した後に前記ルーティングプロトコル状態変化をルーティングプロトコルに送信するように構成された請求項７に記載の第１のコントローラ。
9. 前記ルーティングプロトコル状態変化が、境界ゲートウェイプロトコル（ＢＧＰ）状態変化、ルーティングインターネットプロトコル（ＲＩＰ）状態変化、最適経路の第１のプロトコル（ＯＳＰＦ）状態変化、あるいは、中間システム間のプロトコル（ＩＳ−ＩＳ）状態変化を含む請求項７に記載の第１のコントローラ。
10. ルーティングプロトコルメッセージを受信又は生成し、当該受信又は生成したルーティングプロトコルメッセージを前記第２のコントローラに選択的に複製するように構成された請求項７に記載の第１のコントローラ。
11. 故障を検出するように構成された請求項７に記載の第１のコントローラであって、
    前記第２のコントローラが、故障前に、前記第１のコントローラにおけるのと同一のルーティングプロトコル状態変化を維持するように構成されている、
    請求項７に記載の第１のコントローラ。
12. ルーティングプロトコル状態変化を第２のコントローラから受信し、
    前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラに送信し、
    前記コミットメントを前記第２のコントローラに送信した後に前記ルーティングプロトコル状態変化を完遂し、
    前記ルーティングプロトコル状態変化を完遂した後に前記コミットメントをピアノードに送信するように構成された第１のコントローラ。
13. 冗長プラットフォームを有するネットワークデバイスにおける方法であって、
    第１のコントローラが、ピアノードからルーティングプロトコル状態変化を受信するステップと、
    前記ルーティングプロトコル状態変化を第２のコントローラに送信するステップと、
    前記第１のコントローラが、前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラから受信するステップと、
    前記第１のコントローラにおける前記ルーティングプロトコル状態変化を完遂するステップと、
    前記ルーティングプロトコル状態変化を完遂した後に、前記第１のコントローラが前記コミットメントを前記ピアノードに送信するステップと、
    を備えることを特徴とする方法。
14. 前記第２のコントローラから前記コミットメントを受信した後に前記ルーティングプロトコル状態変化をルーティングプロトコルに送信するステップ、
    を更に備えることを特徴とする請求項１３に記載の方法。
15. 前記ピアノードから前記ルーティングプロトコル状態変化を受信した後に前記ルーティングプロトコル状態変化をルーティングプロトコルに送信するステップ、
    を更に備えることを特徴とする請求項１３に記載の方法。
16. 冗長プラットフォームを有するネットワークデバイスにおける方法であって、
    第１のコントローラが、ピアノードのためにルーティングプロトコル状態変化を生成するステップと、
    前記ルーティングプロトコル状態変化を第２のコントローラに送信するステップと、
    前記第１のコントローラが、前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラから受信するステップと、
    前記第１のコントローラにおける前記ルーティングプロトコル状態変化を完遂するステップと、
    前記ルーティングプロトコル状態変化を完遂した後に、前記第１のコントローラが前記コミットメントを前記ピアノードに送信するステップと、
    を備えることを特徴とする方法。
17. 前記第２のコントローラのために前記コミットメントを生成した後に前記ルーティングプロトコル状態変化をルーティングプロトコルに送信するステップ、
    を更に備えることを特徴とする請求項１６に記載の方法。
18. 冗長プラットフォームを有するデバイスであって、
    第１のコントローラを用いて、ピアノードからルーティングプロトコル状態変化を受信する第１の受信手段と、
    前記ルーティングプロトコル状態変化を第２のコントローラに送信する第１の送信手段と、
    前記第１のコントローラを用いて、前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラから受信する第２の受信手段と、
    前記第１のコントローラにおける前記ルーティングプロトコル状態変化を完遂する完遂手段と、
    前記ルーティングプロトコル状態変化を完遂した後に、前記第１のコントローラを用いて前記コミットメントを前記ピアノードに送信する第２の送信手段と、
    を備えることを特徴とするデバイス。
19. 冗長プラットフォームを有するデバイスであって、
    第１のコントローラを用いて、ピアノードのためにルーティングプロトコル状態変化を生成する生成手段と、
    前記ルーティングプロトコル状態変化を第２のコントローラに送信する第１の送信手段と、
    前記第１のコントローラを用いて、前記ルーティングプロトコル状態変化へのコミットメントを前記第２のコントローラから受信する受信手段と、
    前記第１のコントローラにおける前記ルーティングプロトコル状態変化を完遂する完遂手段と、
    前記ルーティングプロトコル状態変化を完遂した後に、前記第１のコントローラを用いて前記コミットメントを前記ピアノードに送信する第２の送信手段と、
    を備えることを特徴とするデバイス。

Images