(57)【特許請求の範囲】
【請求項１】
アクティブ制御カードとスタンバイ制御カードとの間のアクティブスタンバイ関係を維持するための、ネットワークエレメントにおいて実行される方法であって、当該方法は、
リモートネットワークエレメントからデータパケットを前記アクティブ制御カード内のアクティブトランスポート制御プロトコル（「ＴＣＰ」）モジュールにおいて受信するステップと、
前記データパケットの少なくとも一部を前記アクティブＴＣＰモジュールから前記アクティブ制御カード内のアクティブアプリケーション（「ＡＰＰ」）モジュールへ通信するステップと、
前記データパケットの前記少なくとも一部を受信することに応じて、ＡＰＰ同期（「ＳＹＮＣ」）メッセージを前記アクティブＡＰＰモジュールから前記スタンバイ制御カード上のスタンバイＡＰＰモジュールへ通信するステップと、
ＡＰＰ  ＳＹＮＣ確認応答（「ＡＣＫ」）メッセージを前記スタンバイＡＰＰモジュールから前記アクティブＡＰＰモジュールにおいて受信するステップと、当該ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージは、前記ＡＰＰ  ＳＹＮＣメッセージの成功裏の伝達を示すことと、
前記ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、ＡＰＰ  ＡＣＫメッセージを前記アクティブＡＰＰモジュールから前記アクティブＴＣＰモジュールへ通信するステップと、
前記ＡＰＰ  ＡＣＫメッセージを受信することに応じて、データＡＣＫメッセージを前記アクティブＴＣＰモジュールから前記リモートネットワークエレメントへ通信するステップと、当該データＡＣＫメッセージは、前記データパケットの成功裏の伝達を示すことと、
を含み、
前記方法は、
前記アクティブＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントからＴＣＰエンドポイント情報を取得するステップと、
ヒットレススイッチオーバを開始するスイッチオーバイベントに先立って、取得される前記ＴＣＰエンドポイント情報を前記スタンバイＡＰＰモジュールへ通信するステップと、
をさらに含み、
前記アクティブＡＰＰモジュールは、アクティブボーダーゲートウェイプロトコル（「ＢＧＰ」）ＡＰＰを含み、前記スタンバイＡＰＰモジュールは、スタンバイＢＧＰ  ＡＰＰを含む、
方法。
【請求項２】
アクティブＡＰＰ状態と前記データパケットの前記少なくとも一部に含まれる情報とに基づいて、１つ以上のアクティブＡＰＰ状態変化のセットを判定するステップと、
前記アクティブＡＰＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成するステップと、
をさらに含む、請求項１に記載の方法。
【請求項３】
前記ＡＰＰ  ＳＹＮＣメッセージは、インタープロセス通信チャネルを介して前記スタンバイＡＰＰモジュールへ通信される、請求項１に記載の方法。
【請求項４】
前記データパケットは、ＢＧＰ更新メッセージを含み、前記ＡＰＰ  ＳＹＮＣメッセージは、状態情報を前記アクティブＢＧＰ  ＡＰＰと同期させるために前記スタンバイＢＧＰ  ＡＰＰによって用いられるデータを含む、請求項１に記載の方法。
【請求項５】
前記ＢＧＰ更新メッセージ中に含まれる１つ以上のＢＧＰルート更新を前記アクティブＢＧＰ  ＡＰＰにおいて読み出すステップと、
ローカルポリシー情報ベースからの１つ以上のポリシーに基づいて、１つ以上のＢＧＰルート更新を前記アクティブＢＧＰ  ＡＰＰにおいて破棄するステップと、
アクティブＢＧＰ  ＡＰＰ状態と、読み出される前記１つ以上のＢＧＰルート更新と、破棄される前記１つ以上のＢＧＰルート更新と、に基づいて、１つ以上のＢＧＰ状態変化のセットを判定するステップと、
前記ＢＧＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成するステップと、
をさらに含む、請求項４に記載の方法。
【請求項６】
前記スイッチオーバイベントを前記スタンバイＡＰＰモジュールにおいて検出するステップと、
過去に通信されたＴＣＰエンドポイント情報を用いてスタンバイＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントを作成するステップと、
前記スイッチオーバイベントを検出することに応じて、スタンバイ制御カードをスタンバイステータスからアクティブステータスへ移行させるヒットレススイッチオーバを実行するステップであって、当該移行は、前記リモートネットワークエレメントに透過的となる、ステップと、
をさらに含む、請求項１に記載の方法。
【請求項７】
第２の制御カードに結合されるべき第１の制御カードであって、当該第１の制御カードは、当該第２の制御カードとのアクティブスタンバイ関係においてアクティブ制御カードとして機能し、当該第１の制御カードは、
１つ以上のラインカードに結合されるべきアクティブトランスポート制御プロトコル（「ＴＣＰ」）モジュールであって、
リモートネットワークエレメントからデータパケットを受信し、
前記データパケットの少なくとも一部をアクティブアプリケーション（「ＡＰＰ」）モジュールへ通信し、
ＡＰＰ確認応答（「ＡＣＫ」）メッセージを受信し、及び、
前記ＡＰＰ  ＡＣＫメッセージを受信することに応じて、データＡＣＫメッセージを前記リモートネットワークエレメントへ通信する
ように構成される、アクティブＴＣＰモジュールと、
前記アクティブＴＣＰモジュールに結合され及び前記第２の制御カード上のスタンバイＡＰＰモジュールにさらに結合されるべき前記アクティブＡＰＰモジュールであって、
前記データパケットの前記少なくとも一部を前記アクティブＴＣＰモジュールから受信し、
ＡＰＰ同期（「ＳＹＮＣ」）メッセージを前記スタンバイＡＰＰモジュールへ通信し、
ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを前記スタンバイＡＰＰモジュールから受信し、及び、
前記ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、ＡＰＰ  ＡＣＫメッセージを前記アクティブＴＣＰモジュールへ通信する、
ように構成される、アクティブＡＰＰモジュールと、
を含み、
前記アクティブＡＰＰモジュールは、
前記アクティブＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントからＴＣＰエンドポイント情報を取得し、及び、
ヒットレススイッチオーバを開始するスイッチオーバイベントに先立って、取得される前記ＴＣＰエンドポイント情報を、スタンバイＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントを作成するために前記スタンバイＡＰＰモジュールによって使用されるように、前記スタンバイＡＰＰモジュールへ通信する、
ようにさらに構成され、
前記アクティブＡＰＰモジュールは、アクティブボーダーゲートウェイプロトコル（「ＢＧＰ」）ＡＰＰを含み、前記スタンバイＡＰＰモジュールは、スタンバイＢＧＰ  ＡＰＰを含む、
第１の制御カード。
【請求項８】
前記アクティブＡＰＰモジュールは、
アクティブＡＰＰ状態と前記データパケットの少なくとも一部に含まれる情報とに基づいて、１つ以上のアクティブＡＰＰ状態変化のセットを判定し、及び、
前記アクティブＡＰＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成する、
ようにさらに構成される、請求項７に記載の第１の制御カード。
【請求項９】
前記アクティブＡＰＰモジュールは、インタープロセス通信チャネルを通じて前記スタンバイＡＰＰモジュールに結合される、請求項７に記載の第１の制御カード。
【請求項１０】
前記データパケットは、ＢＧＰ更新メッセージを含み、前記ＡＰＰ  ＳＹＮＣメッセージは、状態情報を前記アクティブＢＧＰ  ＡＰＰと同期させるために前記スタンバイＢＧＰ  ＡＰＰによって用いられるデータを含む、請求項７に記載の第１の制御カード。
【請求項１１】
前記アクティブＡＰＰモジュールは、
前記ＢＧＰ更新メッセージ中に含まれる１つ以上のＢＧＰルート更新を読み出し、
ローカルポリシー情報ベースからの１つ以上のポリシーに基づいて、１つ以上のＢＧＰルート更新を破棄し、
アクティブＢＧＰ  ＡＰＰ状態と、読み出される前記１つ以上のＢＧＰルート更新と、破棄される前記１つ以上のＢＧＰルート更新と、に基づいて、１つ以上のＢＧＰ状態変化のセットを判定し、及び、
前記ＢＧＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成する、
ようにさらに構成される、請求項１０に記載の第１の制御カード。
【請求項１２】
障害の発生時にヒットレススイッチオーバを実行するためのネットワークエレメントであって、当該ネットワークエレメントは、
ネットワークに結合されるべき複数のラインカードと、
前記複数のラインカードに結合される第１の制御カードであって、アクティブスタンバイ関係においてアクティブ制御カードとして機能し、並びに、
リモートネットワークエレメントからデータパケットを前記複数のラインカードのうちの１つを通じて受信し、
前記データパケットの少なくとも一部をアクティブアプリケーション（「ＡＰＰ」）モジュールへ通信し、
ＡＰＰ確認応答（「ＡＣＫ」）メッセージを受信し、及び、
前記ＡＰＰ  ＡＣＫメッセージを受信することに応じて、データＡＣＫメッセージを前記複数のラインカードのうちの１つを通じて前記リモートネットワークエレメントへ通信する、
ように構成される、アクティブＴＣＰモジュールと、
前記アクティブＴＣＰモジュールに結合され及び第２の制御カード上のスタンバイＡＰＰモジュールにさらに結合されるべきアクティブＡＰＰモジュールであって、
前記データパケットの前記少なくとも一部を前記アクティブＴＣＰモジュールから受信し、
ＡＰＰ同期（「ＳＹＮＣ」）メッセージを前記スタンバイＡＰＰモジュールへ通信し、
ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを前記スタンバイＡＰＰモジュールから受信し、及び、
前記ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、ＡＰＰ  ＡＣＫメッセージを前記アクティブＴＣＰモジュールへ通信する、
ように構成される、アクティブＡＰＰモジュールと、
を含む、第１の制御カードと、
前記複数のラインカード及び前記第１の制御カードに結合される前記第２の制御カードであって、前記第１の制御カードとのアクティブスタンバイ関係においてスタンバイ制御カードとして機能し、並びに、
スタンバイＡＰＰモジュールに結合されるべきスタンバイＴＣＰモジュールであって、
前記複数のラインカードと通信し、及び、
前記スタンバイＡＰＰモジュールと通信する、
ように構成されるスタンバイＴＣＰモジュールと、
前記ＡＰＰ  ＳＹＮＣメッセージを前記アクティブＡＰＰモジュールから受信し、
前記ＡＰＰ  ＳＹＮＣメッセージの受信を示すための前記ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを前記アクティブＡＰＰモジュールへ送る、
ように構成される前記スタンバイＡＰＰモジュールと、
を含む、第２の制御カードと、
を備え、
前記アクティブＡＰＰモジュールは、
前記アクティブＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントからＴＣＰエンドポイント情報を取得し、及び、
ヒットレススイッチオーバを開始するスイッチオーバイベントに先立って、取得される前記ＴＣＰエンドポイント情報を前記スタンバイＡＰＰモジュールへ通信する、
ようにさらに構成され、
前記アクティブＡＰＰモジュールは、アクティブボーダーゲートウェイプロトコル（「ＢＧＰ」）ＡＰＰを含み、前記スタンバイＡＰＰモジュールは、スタンバイＢＧＰ  ＡＰＰを含む、
ネットワークエレメント。
【請求項１３】
前記アクティブＡＰＰモジュールは、
アクティブＡＰＰ状態と前記データパケットの前記少なくとも一部に含まれる情報とに基づいて、アクティブＡＰＰ状態変化のセットを判定し、
前記アクティブＡＰＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成する、
ようにさらに構成される、請求項１２に記載のネットワークエレメント。
【請求項１４】
前記アクティブＡＰＰモジュールは、インタープロセス通信チャネルを通じて前記スタンバイＡＰＰモジュールに結合される、請求項１２に記載のネットワークエレメント。
【請求項１５】
前記データパケットは、ＢＧＰ更新メッセージを含み、前記ＡＰＰ  ＳＹＮＣメッセージは、状態情報を前記アクティブＢＧＰ  ＡＰＰと同期させるために前記スタンバイＢＧＰ  ＡＰＰによって用いられるデータを含む、請求項１２に記載のネットワークエレメント。
【請求項１６】
前記アクティブＡＰＰモジュールは、
前記ＢＧＰ更新メッセージ中に含まれる１つ以上のＢＧＰルート更新を読み出し、
ローカルポリシー情報ベースからの１つ以上のポリシーに基づいて、１つ以上のＢＧＰルート更新を破棄し、
アクティブＢＧＰ  ＡＰＰ状態と、読み出される前記１つ以上のＢＧＰルート更新と、破棄される前記１つ以上のＢＧＰルート更新と、に基づいて、ＢＧＰ状態変化のセットを判定し、及び、
前記ＢＧＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成する、
ようにさらに構成される、請求項１５に記載のネットワークエレメント。
【請求項１７】
前記スタンバイＡＰＰモジュールは、
前記スイッチオーバイベントを検出し、
過去に通信されたＴＣＰエンドポイント情報を用いて前記スタンバイＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントを作成し、及び、
スイッチオーバイベントを検出することに応じて、スタンバイ制御カードをスタンバイステータスからアクティブステータスへ移行させるヒットレススイッチオーバを実行し、当該移行は、前記リモートネットワークエレメントに透過的となる、
ようにさらに構成される、
請求項１２に記載のネットワークエレメント。
【請求項１８】
アクティブ制御カードとスタンバイ制御カードとの間のアクティブスタンバイ関係を維持するための、ネットワークエレメントにおいて実行される方法であって、当該方法は、
アプリケーション（「ＡＰＰ」）同期（「ＳＹＮＣ」）メッセージを前記アクティブ制御カード内のアクティブＡＰＰモジュールから前記スタンバイ制御カード内のスタンバイＡＰＰモジュールへ通信するステップと、当該ＡＰＰ  ＳＹＮＣメッセージは、リモートネットワークエレメントへ送信されるべきＡＰＰデータパケットの少なくとも一部に関連付けられることと、
前記スタンバイＡＰＰモジュールからＡＰＰ  ＳＹＮＣ確認応答（「ＡＣＫ」）メッセージを前記アクティブＡＰＰモジュールにおいて受信するステップと、前記ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージは、当該ＡＰＰ  ＳＹＮＣメッセージの成功裏の伝達を示すことと、
前記ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、前記ＡＰＰデータパケットを前記アクティブＡＰＰモジュールから前記アクティブ制御カード内のアクティブトランスポート制御プロトコル（「ＴＣＰ」）モジュールへ通信するステップと、
前記ＡＰＰデータパケットを前記アクティブＴＣＰモジュールから前記リモートネットワークエレメントへ通信するステップと、
前記リモートネットワークエレメントからリモートＡＣＫメッセージを前記アクティブＴＣＰモジュールにおいて受信するステップと、当該リモートＡＣＫメッセージは、前記リモートネットワークエレメントにおける前記ＡＰＰデータパケットの成功裏の伝達を示すことと、
前記リモートＡＣＫメッセージの少なくとも一部を前記アクティブＴＣＰモジュールから前記アクティブＡＰＰモジュールへ通信するステップと、
前記リモートＡＣＫメッセージの少なくとも一部を前記アクティブＡＰＰモジュールから前記スタンバイＡＰＰモジュールへ通信するステップと、
を含み、
前記方法は、
前記アクティブＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントからＴＣＰエンドポイント情報を取得するステップと、
ヒットレススイッチオーバを開始するスイッチオーバイベントに先立って、取得される前記ＴＣＰエンドポイント情報を前記スタンバイＡＰＰモジュールへ通信するステップと、
をさらに含み、
前記アクティブＡＰＰモジュールは、アクティブボーダーゲートウェイプロトコル（「ＢＧＰ」）ＡＰＰを含み、前記スタンバイＡＰＰモジュールは、スタンバイＢＧＰ  ＡＰＰを含む、
方法。
【請求項１９】
前記アクティブＡＰＰモジュールに関連付けられる第１の再送信リストに第１の再送信エントリを追加するステップと、
前記スタンバイＡＰＰモジュールに関連付けられる第２の再送信リストに第２の再送信エントリを追加するステップと、
前記リモートＡＣＫメッセージを受信することに応じて、前記第１の再送信エントリを前記第１の再送信リストから除去するステップと、
前記リモートＡＣＫメッセージを受信することに応じて、前記第２の再送信エントリを前記第２の再送信リストから除去するステップと、
をさらに含む、請求項１８に記載の方法。
【請求項２０】
アクティブＡＰＰ状態と前記ＡＰＰデータパケットに含まれる情報とに関連付けられる１つ以上のアクティブＡＰＰ状態変化のセットを判定するステップ、をさらに含み、前記ＡＰＰ  ＳＹＮＣメッセージは、当該アクティブＡＰＰ状態変化のセットを含む、請求項１８に記載の方法。
【請求項２１】
前記ＡＰＰ  ＳＹＮＣメッセージは、インタープロセス通信チャネルを介して前記スタンバイＡＰＰモジュールへ通信される、請求項１８に記載の方法。
【請求項２２】
前記データパケットは、ＢＧＰ更新メッセージを含み、前記ＡＰＰ  ＳＹＮＣメッセージは、状態情報を前記アクティブＢＧＰ  ＡＰＰと同期させるために前記スタンバイＢＧＰ  ＡＰＰによって用いられるデータを含む、請求項１８に記載の方法。
【請求項２３】
前記ＢＧＰ更新メッセージ中に含まれる１つ以上のＢＧＰルート更新を前記アクティブＢＧＰ  ＡＰＰにおいて読み出すステップと、
ローカルポリシー情報ベースからの１つ以上のポリシーに基づいて、１つ以上のＢＧＰルート更新を前記アクティブＢＧＰ  ＡＰＰにおいて破棄するステップと、
アクティブＢＧＰ  ＡＰＰ状態と、読み出される前記１つ以上のＢＧＰルート更新と、破棄される前記１つ以上のＢＧＰルート更新と、に基づいて、１つ以上のＢＧＰ状態変化のセットを判定するステップと、
前記ＢＧＰ状態変化のセットを含むように前記ＡＰＰ  ＳＹＮＣメッセージを生成するステップと、
をさらに含む、請求項２２に記載の方法。
【請求項２４】
前記スイッチオーバイベントを前記スタンバイＡＰＰモジュールにおいて検出するステップと、
過去に通信されたＴＣＰエンドポイント情報を用いてスタンバイＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントを作成するステップと、
前記スイッチオーバイベントを検出することに応じて、スタンバイ制御カードをスタンバイステータスからアクティブステータスへ移行させるヒットレススイッチオーバを実行するステップであって、当該移行は、前記リモートネットワークエレメントに透過的となる、ステップと、
をさらに含む、請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、一般に、ネットワークエレメント内のアクティブスタンバイシステムの分野に関し、特に、ネットワークエレメント内のアクティブスタンバイシステムにおけるヒットレススイッチオーバに関する。
【背景技術】
【０００２】
ＴＣＰ（Transmission  Control  Protocol）は、ＩＥＴＦ（Internet  Engineering  Task  Force）のＲＦＣ（Request  for  Comments）７９３、“DARPA  Internet  Program  Protocol  Specification”（１９８１年９月）、及びＩＥＴＦのＲＦＣ１１２２、“Requirements  for  Internet  Host  −  Communication  Layers”（１９８９年１０月）などの種々の文献において説明される信頼できる伝送プロトコルである。コンピュータ上のアプリケーションプログラムは、ＴＣＰを用いて、リモートコンピュータ上に位置する別のアプリケーションプログラムへデータを送信し及び受信する。ＴＣＰは、インターネットプロトコル（ＩＰ）を用いて、データをその宛先へパケットで送信する。ＩＰは、パケットをＩＰ自身の選択によるパスに沿って正確な宛先へ伝達する（deliver）であろう。ＩＰは、少数のパケットを伝達し損ねることがあり、又は、ＩＰは、少数のパケットを当該パケットが送信された順序とは異なる順序で伝達することがある。ＴＣＰは、当該ＴＣＰが送信するデータの各バイトにシーケンス番号を割り当てる。受信側ＴＣＰは、シーケンス番号を用いて受信データを並べ替えて、当該データを送信された順序と同じ順序で受信側のコンピュータ上のアプリケーションプログラムに伝達することができる。受信側ＴＣＰは、欠損データを検出し及び送信側ＴＣＰに当該データを再送信させるためにもシーケンス番号を用いる。ＴＣＰ受信機がデータを受信すると、当該ＴＣＰ受信機は、ＴＣＰ送信機に確認応答を時折送信するであろう。確認応答は、シーケンス番号を含む。これは、確認応答が送信されたシーケンス番号までのシーケンス番号が付いたデータ全てを受信機が成功裏に受信したことを示す。ＴＣＰ受信機は、そのアプリケーションプロセスへ受信データを伝達するであろう。確認応答の受信に応じて、ＴＣＰ送信機は、その再送信リストから確認応答されたデータを除去するであろう。再送信リストは、ＴＣＰ送信機上の、送信されたデータについての一時的なストレージである。アプリケーションプロセスがＴＣＰにデータを送信するように要求すると、送信側ＴＣＰは、その再送信リストに当該データを同時に入れる。時々、種々のＲＦＣにおいて仕様化されているように、ＴＣＰ送信機が送信データについての確認応答を受信しない場合、当該ＴＣＰ送信機は、再送信リスト上のデータを再送信するであろう。このようにして、ＩＰが何らかのデータを失っても、ＴＣＰが当該データを復元することができる。
【０００３】
コンピュータアプリケーションプログラムの高い信頼性を達成するための１つの手法は、アクティブスタンバイ方法を用いることである。単一のスタンバイ／アクティブコンピュータシステムは、２つの完全に機能的な（fully  functional）コンピュータを用いて構築されることができる。一方の機能的なコンピュータは、アクティブコンピュータと呼ばれ、他方は、スタンバイコンピュータと呼ばれる。アクティブコンピュータは、通常通り機能し、スタンバイコンピュータは、アクティブコンピュータが障害を起こした時及び場合に動作をテイクオーバするために待機する。スタンバイがテイクオーバする際のアクティビティは、スイッチオーバと呼ばれる。スイッチオーバ時に、スタンバイコンピュータは、アクティブコンピュータとなる。以前のアクティブコンピュータは、スタンバイ／アクティブコンピュータシステムにおいてもはや機能していない。以前のアクティブコンピュータは、その後、例えば、修復後又はリセット後にスタンバイ／アクティブコンピュータシステムに再び加わり得る。以前のアクティブコンピュータは、アクティブコンピュータの役割を取戻し又はスタンバイコンピュータの役割をテイクオーバして、スタンバイ／アクティブコンピュータシステムに再び加わり得る。
【０００４】
スタンバイコンピュータが中断を引き起こすことなくスイッチオーバすることができる場合、当該スイッチオーバは、ヒットレス（hitless）スイッチオーバと呼ばれる。この場合において、スタンバイ／アクティブコンピュータシステムとインタラクションする他のコンピュータシステムは、この冗長なコンピュータシステムを単一のコンピュータと見なし、及び障害又はスイッチオーバイベントを検出しない。そのため、障害は、スタンバイ／アクティブコンピュータと他のコンピュータとのインタラクションに影響を及ぼすことなく修復されることができる。スイッチオーバをヒットレスとするために、スタンバイコンピュータは、アクティブコンピュータと通信して当該アクティブコンピュータの進行を追跡し、及び全ての必要不可欠なデータを当該データがアクティブコンピュータ上で作成された状態で保存しなければならない。
【０００５】
障害の時点で、スタンバイコンピュータは、アクティブコンピュータからの全てのデータを有していないことがあり得る。全てのデータがアクティブコンピュータからスタンバイコンピュータへ送信され得る前に、アクティブコンピュータとスタンバイコンピュータとの間の通信に障害が起きていたことがあり得るからである。この場合において、スタンバイコンピュータは、スイッチオーバをヒットレスとするために、失われたデータを復元しなければならない。
【０００６】
ヒットレススイッチオーバを達成するためのＴＣＰプロセスについての方法が存在する。しかしながら、それらの方法は、ＴＣＰを用いるアプリケーションプロセスを無視する。ある方法は、リモートＴＣＰピアへ確認応答を送信する前に、インカミングＴＣＰデータをアクティブＴＣＰプロセスからスタンバイＴＣＰプロセスへ送信するであろう。アクティブＴＣＰは、受信データをアクティブアプリケーションへ渡すであろう。次いで、当該アプリケーションは、受信データを処理し及び場合により何らかの更新状態をそのスタンバイアプリケーションへ送って、当該更新状態に同期させるであろう。スタンバイアプリケーションは、同じデータをスタンバイＴＣＰからも受信し、及び当該アプリケーション自体の状態も更新するであろう。アプリケーションプロセスは、典型的に、ＴＣＰ接続以外のソースから来る入力を処理している。既存の解決策では、他の入力及びＴＣＰ入力の処理をアクティブコンピュータとスタンバイコンピュータとの間で同期させることは、複雑であり且つ誤りが発生しやすい。
【０００７】
ＴＣＰ出力データに関して、既存の解決策において、アクティブＴＣＰは、アウトゴーイングデータをリモートＴＣＰピアに送出する前にスタンバイＴＣＰへ送信するであろう。これにより、スタンバイＴＣＰは、スイッチオーバ及び障害が起きた送信の場合にアウトゴーイングデータを再送信することが可能になる。しかしながら、アクティブアプリケーションがスイッチオーバ時に何を送信し及び何を送信していないのかをスタンバイアプリケーションが正確に知得することは、複雑であり且つ誤りが発生しやすい。幾つかのアプリケーションは、アプリケーションの中断を引き起こすことなくアプリケーションレベルでアウトゴーイングデータを再送信することが可能である。ＦＴＰ（file  transfer  protocol）又はエコーサーバなどの幾つかは、アプリケーションに中断を引き起こすことなく、成功裏に送信されたアプリケーションデータを再送信することができない。アプリケーションがスイッチオーバ時に幾らかのデータを再送信することができる場合でも、どれくらいのデータを安全に再送信できるかを当該アプリケーションが知得することは困難である。
【０００８】
それ故に、スタンバイアプリケーションがアクティブアプリケーション及びインカミング／アウトゴーイングＴＣＰ送信のステータスをより正確に追跡することを可能にすることによって、ＴＣＰとアプリケーションプログラムとがヒットレススイッチオーバを簡略化する手法でインタラクションするためのメカニズムを提供することが望ましい。
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明の実施形態は、アクティブ制御カードとスタンバイ制御カードとの間のアクティブスタンバイ関係を維持するための、ネットワークエレメントにおいて実行される方法を含む。ネットワークエレメントは、リモートネットワークエレメントからデータパケットをアクティブ制御カード内のアクティブ送信制御プロトコル（「ＴＣＰ」）モジュールにおいて受信する。ネットワークエレメントは、データパケットの少なくとも一部をアクティブＴＣＰモジュールからアクティブ制御カード内のアクティブアプリケーション（「ＡＰＰ」）モジュールへ通信する。ネットワークエレメントは、データパケットの少なくとも一部を受信することに応じて、ＡＰＰ同期（「ＳＹＮＣ」）メッセージをアクティブＡＰＰモジュールからスタンバイ制御カード上のスタンバイＡＰＰモジュールへ通信する。ネットワークエレメントは、ＡＰＰ  ＳＹＮＣ確認応答（「ＡＣＫ」）メッセージをスタンバイＡＰＰモジュールからアクティブＡＰＰモジュールへ通信し、当該ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージは、ＡＰＰ  ＳＹＮＣメッセージの成功裏の伝達を示す。ネットワークエレメントは、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、ＡＰＰ  ＡＣＫメッセージをアクティブＡＰＰモジュールからアクティブＴＣＰモジュールへ通信する。ネットワークエレメントは、ＡＰＰ  ＡＣＫメッセージを受信することに応じて、データＡＣＫメッセージをアクティブＴＣＰモジュールからリモートネットワークエレメントへ通信し、当該データＡＣＫメッセージは、データパケットの成功裏の伝達を示す。
【００１０】
本発明の実施形態は、第２の制御カードに結合されるべき第１の制御カードを含み、当該第１の制御カードは、当該第２の制御カードとのアクティブスタンバイ関係においてアクティブ制御カードとして機能する。第１の制御カードは、１つ以上のラインカードに結合されるべきアクティブトランスポート制御プロトコル（「ＴＣＰ」）モジュールを含む。アクティブＴＣＰモジュールは、データパケットをリモートネットワークエレメントから受信し、データパケットの少なくとも一部をアクティブアプリケーション（「ＡＰＰ」）モジュールへ通信し、ＡＰＰ確認応答（「ＡＣＫ」）メッセージを受信し、及び、ＡＰＰ  ＡＣＫメッセージを受信することに応じて、データＡＣＫメッセージをリモートネットワークエレメントへ通信するように構成される。アクティブＡＰＰモジュールは、アクティブＴＣＰモジュールに結合され及び第２の制御カード上のスタンバイＡＰＰモジュールにさらに結合されるべきである。アクティブＡＰＰモジュールは、データパケットの上記少なくとも一部をアクティブＴＣＰモジュールから受信し、ＡＰＰ同期（「ＳＹＮＣ」）メッセージをスタンバイＡＰＰモジュールへ通信し、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージをスタンバイＡＰＰモジュールから受信し、及び、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、ＡＰＰ  ＡＣＫメッセージをアクティブＴＣＰモジュールへ通信するように構成される。
【００１１】
本発明の実施形態は、障害の発生時にヒットレススイッチオーバを実行するためのネットワークエレメントを含む。ネットワークエレメントは、ネットワークに結合されるべき複数のラインカードと、当該複数のラインカードに結合される第１の制御カードと、当該複数のラインカードに結合される第２の制御カードと、を備える。第１の制御カードは、アクティブスタンバイ関係においてアクティブ制御カードとして機能すべきものである。第１の制御カードは、リモートネットワークエレメントからデータパケットを複数のラインカードのうちの１つを通じて受信し、データパケットの少なくとも一部をアクティブアプリケーション（「ＡＰＰ」）モジュールへ通信し、ＡＰＰ確認応答（「ＡＣＫ」）メッセージを受信し、及び、ＡＰＰ  ＡＣＫメッセージを受信することに応じて、データＡＣＫメッセージを複数のラインカードのうちの１つを通じてリモートネットワークエレメントへ通信する、ように構成される、アクティブ送信制御プロトコル（「ＴＣＰ」）モジュールを含む。第１の制御カードは、アクティブＴＣＰモジュールに結合され及び第２の制御カード上のスタンバイＡＰＰモジュールにさらに結合されるべきアクティブＡＰＰモジュールをさらに含む。アクティブＡＰＰモジュールは、データパケットの少なくとも一部をアクティブＴＣＰモジュールから受信し、ＡＰＰ同期（「ＳＹＮＣ」）メッセージをスタンバイＡＰＰモジュールへ通信し、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージをスタンバイＡＰＰモジュールから受信し、及び、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、ＡＰＰ  ＡＣＫメッセージをアクティブＴＣＰモジュールへ通信する、ように構成される。第２の制御カードは、複数のラインカード及び第１の制御カードに結合される。第２の制御カードは、第１の制御カードとのアクティブスタンバイ関係においてスタンバイ制御カードとして機能すべきものである。第２の制御カードは、スタンバイＡＰＰモジュールに結合されるべきスタンバイＴＣＰモジュールを含む。スタンバイＴＣＰモジュールは、複数のラインカードと通信し、及び、スタンバイＡＰＰモジュールと通信するように構成される。スタンバイアプリケーションモジュールは、ＡＰＰ  ＳＹＮＣメッセージをアクティブＡＰＰモジュールから受信し、ＡＰＰ  ＳＹＮＣメッセージの受信を示すためのＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージをアクティブＡＰＰモジュールへ送るように構成される。
【図面の簡単な説明】
【００１２】
本発明は、同様の番号が同様の要素を示す添付の図面における図において、限定としてではなく、例として例示される。本開示における「ある（an）」又は「１つの（one）」実施形態への様々な言及は必ずしも同じ実施形態を指さず、そのような言及は少なくとも１つを意味することに留意すべきである。さらに、特定の特徴、構造、又は特性がある実施形態に関連して説明される場合、明示的に説明されるか否かを問わず、そのような特徴、構造、又は特性を他の実施形態との関連において実施をすることは当業者の知識の範囲内である。
【００１３】
本発明は、本発明の実施形態を例示するために用いられる添付の図面及び以下の説明を参照することによって最もよく理解され得る。図面において：
【００１４】
【図１Ａ】本発明の実施形態に係る、アクティブアプリケーションにおいて受信されるデータをスタンバイアプリケーションとの間で同期させるための方法を例示するフローチャートである。
【図１Ｂ】本発明の実施形態に係る、アクティブアプリケーションからリモートピアへ送信されているデータをスタンバイアプリケーションとの間で同期させるための方法を例示するフローチャートである。
【図１Ｃ】本発明の実施形態に係る、図１Ａ及び図１Ｂのアクティブアプリケーションから図１Ａ及び図１Ｂのスタンバイアプリケーションへのヒットレススイッチオーバを実行するための方法を例示するフローチャートである。
【図２】リモートネットワークエレメントにネットワークを介して結合される、ヒットレススイッチオーバを有するアクティブスタンバイＡＰＰ−ＴＣＰシステムを提供するためのアクティブスタンバイネットワークエレメントを例示するブロック図である。
【図３】本発明の実施形態に係る、リモートピアからネットワークエレメントにおいて受信されるデータについての確認応答及びメッセージのパスを例示するデータフロー図である。
【図４】本発明の実施形態に係る、ネットワークエレメントからリモートピアへ送信されるデータについての確認応答及びメッセージのパスを例示するデータフロー図である。
【発明を実施するための形態】
【００１５】
以下の説明は、スタンバイシステムがアクティブモードに移行する際にＴＣＰ接続のヒットレススイッチオーバを実行するアクティブ／スタンバイコンピュータシステムについての方法及び装置を説明する。以下の説明において、本発明のより完全な理解を提供するために、ロジック実装、対立する、オペランドを特定するための手段、リソース分割／共有／複製の実装、システムコンポーネントのタイプ及び相互関係、並びにロジック分割／統合の選択といった多くの具体的な詳細が述べられる。しかしながら、本発明はそのような具体的な詳細なしに実施をされ得ることが当業者によって認識されるであろう。他の例において、本発明を曖昧にしないために、制御構造、ゲートレベル回路及び完全なソフトウェア命令シーケンスは、詳細には示されていない。当業者であれば、包含される説明により、必要以上の実験なしに適当な機能性を実装することが可能であろう。
【００１６】
本明細書における「１つの実施形態」、「ある実施形態」、「例示的な実施形態」等への言及は、説明される実施形態が特定の特徴、構造、又は特性を含み得るが、必ずしも全ての実施形態が当該特定の特徴、構造、又は特性を含むとは限らないことを示す。また、そのような表現は、必ずしも同じ実施形態を指すとは限らない。さらに、特定の特徴、構造、又は特性がある実施形態に関連して説明される場合、明示的に説明されるか否かを問わず、そのような特徴、構造、又は特性を他の実施形態との関連において実施をすることは当業者の知識の範囲内である。
【００１７】
以下の説明及び特許請求の範囲において、「結合される（coupled）」及び「接続される（connected）」という用語がこれらの派生語と共に用いられ得る。これらの用語は互いに同義語として意図されないことが理解されるべきである。「結合される」は、互いに直接物理的に又は電気的に接触してもしなくてもよい２つ以上のエレメントが互いに協働し又はインタラクションすることを示すために用いられる。「接続される」は、互いに結合される２つ以上の要素間における通信の確立を示すために用いられる。
【００１８】
理解を容易にするために、図において破線が用いられて、あるアイテム（例えば、本発明の所与の実装によってサポートされない特徴；所与の実装によってサポートされるが、幾つかの状況において用いられ、他の状況においては用いられない特徴）の随意的な性質が示される。
【００１９】
本発明の実施形態は、アクティブ／スタンバイコンピュータシステム上でＴＣＰを用い、及び計画された又は計画されていないスイッチオーバに応じてリモートピアとのＴＣＰ接続を維持するアプリケーションプログラムを開示する。計画されていないスイッチオーバは、アクティブコンピュータがクラッシュしたとき、又はさもなければ、アクティブコンピュータが機能することを停止し、スタンバイコンピュータがテイクオーバするときに発生する。アプリケーションプログラムは、ＴＣＰエンドポイントを用いてリモートＴＣＰピアと通信している。スイッチオーバは予期外であるため、スタンバイコンピュータは、スイッチオーバに先立ってアクティブコンピュータが到達した正確な状態を知得することができない。アクティブアプリケーションプロセスは、通常動作の期間中、その状態をスタンバイアプリケーションプロセスと同期させ、それによって、スタンバイアプリケーションプロセスは、スイッチオーバ前の状態の大部分を知得することとなるが、当該状態の全ては知得しないかもしれない。
【００２０】
ＴＣＰ接続を維持することに加えて、これは、アプリケーションに幾つかのＴＣＰリモートピアからの入力及び他のソース（例えば、キーボード、マウス、タッチスクリーンからのユーザ入力；外部モニタ；ＣＤ−ＲＯＭ、ハードディスクといったＩ／Ｏデバイス）からの入力を同期させ、並びにスタンバイアプリケーションがアクティブアプリケーションと同じ順序で当該入力を受信することができることを確実にする機会も提供する。幾つかのアプリケーションにおいて、複数の異なるソースからの入力の正確な順序は、異なる出力を生成する。
【００２１】
複数の異なるソースからの入力が異なる出力を生成する順序の一例は、以下の通りである。ＩＥＴＦ  ＲＦＣ  ４２７１、“A  Border  Gateway  Protocol  4  (BGP-4)”（２００６年１月）において説明されるようなボーダーゲートウェイプロトコル（ＢＧＰ）アプリケーションが外部ＢＧＰピアからルートを受信すると仮定する。当該アプリケーションは、当該ルートをその内部ＢＧＰピア全てに再広告する。ＢＧＰアプリケーションが内部ＢＧＰピアからより良好なルートを続いて受信する場合、当該ＢＧＰアプリケーションは、その最初のルートをその内部ＢＧＰピアから撤回する。ＢＧＰアプリケーションがそれらの２つの広告をこの逆の順序で受信する場合、当該ＢＧＰアプリケーションは、如何なる広告も送信しないであろう。なぜなら、その内部ＢＧＰピアは、外部ＢＧＰピアが広告したものよりも良好なルートを既に広告しているからである。スタンバイＢＧＰアプリケーションがアクティブＢＧＰアプリケーションによって受信される順序以外の順序で複数のルートを受信する場合、スタンバイＢＧＰアプリケーションは、スイッチオーバ時に取るべき一連のアクション（例えば、広告される必要があるルート、撤回される必要があるルート、又は何のアクションも必要とされない）を誤って判定し得る。あるルートが外部ＢＧＰピアから受信され、且つより良好なルートが内部ＢＧＰピアから受信される場合であって、スタンバイＢＧＰアプリケーションが当該広告を逆の順序で受信し、且つアクティブＢＧＰアプリケーションが撤回を送信する前にスイッチオーバが発生することとなるとき、スタンバイは、撤回を送信すべきことが決して分からないであろう。
【００２２】
スタンバイアプリケーションがアクティブアプリケーションと同じ順序で入力を受信する実施形態を提供するために、アクティブコンピュータ上のＴＣＰプロセスは、スタンバイコンピュータ上のＴＣＰプロセスとデータを同期させない。これは、帯域幅及びＣＰＵサイクルを節約する利点を有する。その代わりに、アクティブコンピュータ上のＴＣＰプロセスはそのデータをアクティブアプリケーションプロセスと同期させ、アクティブアプリケーションプロセスは、アクティブアプリケーションプロセスとスタンバイアプリケーションプロセスとの間で充分なデータを同期させて、ＴＣＰ状態及びそれ自体の状態を正確に再構築する。スイッチオーバに応じて、スタンバイコンピュータは、確立された状態にある１つ以上のＴＣＰ接続を作成し、及び再送信すべきデータを有するＴＣＰプロセス及びシーケンス番号を供給して、ＴＣＰ接続の円滑な移行を確実にする。上記新たな接続は、新たなＴＣＰ接続が通常行うようにＴＣＰ  ＳＹＮセグメントを対応するＴＣＰリモートピアと交換することはしないであろう。なぜなら、スイッチオーバは、対応するリモートピアには透過的となるからである。
【００２３】
図１Ａは、本発明の実施形態に係る、アクティブアプリケーションにおいて受信されるデータをスタンバイアプリケーションとの間で同期させるための方法を例示するフローチャートである。一実施形態において、図１Ａの方法は、アクティブコンピュータとスタンバイコンピュータとを有するネットワークエレメント内で実行される一方、他の実施形態において、当該方法は、アクティブコンピュータとスタンバイコンピュータとを有する汎用コンピュータシステムによって実行される。アクティブコンピュータとスタンバイコンピュータとは、ネットワークエレメント内のアクティブ制御カードとスタンバイ制御カードとに対応する。また別の実施形態において、アクティブアプリケーションとスタンバイアプリケーションとは、アクティブアプリケーション専用の分離されたリソースのセットとスタンバイアプリケーション専用の分離されたリソースのセットとを有する単一のコンピュータ内に存在し得る。これは、アクティブアプリケーションが上記コンピュータ上の第１のバーチャルマシン内に存在し、スタンバイアプリケーションが当該コンピュータの第２のバーチャルマシン内に存在する場合に当てはまり得る。このシナリオにおいて、第１のバーチャルマシンはアクティブコンピュータであり、第２のコンピュータはスタンバイコンピュータである。
【００２４】
図１Ａは、ブロック１００において開始され、アクティブＴＣＰモジュールは、リモートピアからデータパケットを受信する。例えば、アクティブアプリケーションがＢＧＰルータアプリケーションであり、且つリモートピアがＢＧＰルータである場合、上記データパケットは、ＢＧＰ更新メッセージを含み得る。上記方法は、ブロック１０５へ続き、アクティブＴＣＰモジュールは、データパケットの少なくとも一部をアクティブアプリケーション（ＡＰＰ）モジュールへ通信する。アクティブＴＣＰモジュールは、データパケットをアクティブＡＰＰモジュールへ通信する。
【００２５】
随意的に、上記方法は、破線のブロック１０６へ続き、１つ以上のアクティブなＡＰＰ状態変化のセットを現在のアクティブＡＰＰの状態及び受信データパケットに基づいて判定してもよい。アクティブアプリケーションがＢＧＰルータであり、且つデータパケットがＢＧＰ更新メッセージである例において、上記方法は、破線のブロック１０６Ａへ続き、ＢＧＰ更新メッセージ中の１つ以上のＢＧＰルート更新を読み出す。上記方法は、破線のブロック１０６Ｂへ続き、ローカルポリシー情報ベースからの１つ以上のポリシーに基づいて、１つ以上のＢＧＰルート更新を破棄する。上記方法は、アクティブＢＧＰ  ＡＰＰ状態、１つ以上の読み出されたＢＧＰルート更新、及び１つ以上の破棄されたＢＧＰルート更新に基づいて、１つ以上のＢＧＰルート状態変化のセットを判定する。上記方法は、破線のブロック１０９へ続き、ＢＧＰ  ＡＰＰ状態変化のセットなどのアクティブＡＰＰ状態変化のセットを含むＡＰＰ  ＳＹＮＣメッセージを生成する。
【００２６】
上記方法は、ブロック１１０へ続き、アクティブＡＰＰモジュールは、ＡＰＰ同期（ＳＹＮＣ）メッセージをスタンバイコンピュータ上のスタンバイＡＰＰモジュールへ通信する。一実施形態において、ＡＰＰ  ＳＹＮＣメッセージは、アクティブＴＣＰモジュールによって受信されるデータパケットからの全てのデータを含む。別の実施形態において、ＡＰＰ  ＳＹＮＣメッセージは、アクティブＴＣＰモジュールによって受信されるデータパケットの圧縮された形式を含む。また別の実施形態において、ＡＰＰ  ＳＹＮＣメッセージは、アクティブＡＰＰモジュールがデータパケットに応じて必要とされると判定した１つ以上のアプリケーション状態変化のセットを示す。圧縮された形式は、スタンバイＡＰＰモジュールがアクティブＴＣＰモジュールによって受信されるデータパケットに適当に反応し及び当該データパケットへの応答を再構築するのに充分であるとアクティブＡＰＰモジュールによって判定されるデータを含む。いずれの場合においても、ＡＰＰ  ＳＹＮＣメッセージは、アクティブＴＣＰモジュールによって受信されるデータパケットからのシーケンス番号を含み、それによって、スタンバイＡＰＰモジュールは、アクティブＡＰＰモジュールが当該データパケットを受信したことを認識する。このようにして、スタンバイＡＰＰモジュールは、リモートピアから送信される重複したデータパケットが適切に処理されたが、アクティブＴＣＰモジュールからの対応する確認応答（ＡＣＫ）パケットがリモートピアによって受信されなかった場合、当該パケットを検出し及び破棄する。アクティブＡＰＰモジュールとスタンバイＡＰＰモジュールとは、アプリケーション同期データを搬送するインタープロセス通信（ＩＰＣ：inter-process  communication）チャネルを介して結合される。一実施形態において、ＩＰＣチャネルは、コンピュータシステム内の共有メモリスペースのセットである。他方、他の実施形態におけるＩＰＣチャネルは、信号、パイプ、ソケット、スイッチ、ファブリック、及び（例えば、光学的、イーサネット、同軸、無線）ネットワーキングメディアを含む。また別の実施形態において、ＩＰＣチャネルは、上述されたＩＰＣチャネルのうちの幾つか若しくは全ての組み合わせであり、又はＩＰＣの他の実装を含む。
【００２７】
上記方法は、ブロック１１５へ続き、アクティブＡＰＰモジュールは、スタンバイＡＰＰモジュールからＩＰＣチャネルを通じてＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信する。このメッセージは、スタンバイＡＰＰモジュールがＡＰＰ  ＳＹＮＣメッセージを適切に受信したことをアクティブＡＰＰモジュールに通知する。ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、アクティブＡＰＰモジュールは、ブロック１２０において、アクティブＴＣＰモジュールによって受信されたデータパケットが適切に処理されたこと及びアクティブＴＣＰモジュールはリモートピアにＡＣＫメッセージにより応答すべきであることを示すＡＰＰ  ＡＣＫメッセージをアクティブＴＣＰモジュールに通信する。ＡＰＰ  ＡＣＫメッセージを受信することに応じて、アクティブＴＣＰモジュールは、ブロック１２５において、リモートピアによって送信されたデータパケットをアクティブＴＣＰモジュールが適切に受信したことを示すデータＡＣＫメッセージをリモートピアへ通信する。
【００２８】
従って、アクティブＴＣＰモジュールがインカミングデータをピアから受信する場合、当該アクティブＴＣＰモジュールは、通常のように当該データの受信の確認応答を自動的に送信することはしない。その代わりに、アクティブＴＣＰモジュールは、ＡＣＫをリモートピアへ送信する前に、アクティブＡＰＰモジュールがアクティブＴＣＰモジュールへ当該データに対する確認応答を送信するまで待機する。ただし、アクティブＡＰＰモジュールがスタンバイＡＰＰモジュールと同期させるデータの性質は、アプリケーションに依存する。例えば、ＢＧＰアプリケーションは、キープアライブメッセージを同期しないであろう。更新メッセージについて、ＢＧＰは、当該メッセージ自体ではなく、当該メッセージ中に含まれるルートを同期させ得る。ＢＧＰアプリケーションがこれを行う際、当該ＢＧＰアプリケーションは、ルートを同期させる前に、当該ルートに情報を付加し又は除去する適応性を有する。ＢＧＰアプリケーションは、ポリシーによって付加されたプリファレンス又は他の属性を付加し得る。特に有益なのは、インカミングポリシーによって破棄されるルートを同期させない能力である。これは、さもなければスタンバイＡＰＰモジュールへ破棄されたルートを送信するために必要とされ得る帯域幅及び処理リソースを節約することができる。
【００２９】
アクティブＡＰＰモジュールが全ての受信データをスタンバイＡＰＰモジュールに同期させなくてもよいとしても、又は、当該アクティブＡＰＰモジュールが幾らかの受信データを当該データが受信された形式以外の形式において同期させ得るとしても、アクティブＡＰＰモジュールは、ＴＣＰシーケンス番号又はＴＣＰシーケンス番号を再作成するのに充分な情報を送る。一実施形態において、アクティブＡＰＰモジュールは、シーケンス番号の代わりに受信バイト数をスタンバイＡＰＰモジュールへ通信する。スタンバイＡＰＰモジュールは、最初のシーケンス番号と受信バイト数とを用いて、実際のシーケンス番号を再作成することができる。スイッチオーバが発生する場合、新たなアクティブＡＰＰモジュール（以前のスタンバイＡＰＰモジュール）が、同期された最新のＴＣＰシーケンス番号に対する確認応答をリモートピアへ送信するであろう。以前のアクティブＡＰＰモジュールは、当該シーケンス番号以下の任意のシーケンス番号に対する確認応答をリモートピアへ送信していてもよい。リモートピアは、確認応答が送信されたよりも多くを送信しているかもしれない。その場合、リモートピアは、最後に送信されたシーケンス番号以降を再送信するであろう。このようにして、新たなアクティブＡＰＰモジュールは、インカミングＴＣＰデータストリームを正確に復元することができる。
【００３０】
図１Ｂは、本発明の実施形態に係る、アクティブアプリケーションからリモートピアへ送信されているデータとスタンバイアプリケーションとを同期させるための方法を例示するフローチャートである。アクティブＡＰＰモジュールがデータをリモートピアに送信するにつれて、スタンバイＡＰＰモジュールは、リモートピアが受信に対して確認応答を送信しない場合に備えて当該データを再送信する準備をしなければならない。スイッチオーバが発生する場合には、スタンバイＡＰＰモジュールは、データを再送信する必要がある。
【００３１】
アクティブＡＰＰモジュールがリモートピアへ送信するためのデータを生成することに応じて、アクティブＡＰＰモジュールは、ブロック１３０において、ＡＰＰ  ＳＹＮＣメッセージをスタンバイＡＰＰモジュールへ通信する。アクティブＡＰＰモジュールは、ブロック１３５において、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージをスタンバイＡＰＰモジュールから受信する。ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージは、スタンバイＡＰＰモジュールがＡＰＰ  ＳＹＮＣメッセージを適切に受信したことを示す。ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、アクティブＡＰＰモジュールは、ブロック１４０において、生成されたデータに対応するＡＰＰデータパケットをアクティブＴＣＰモジュールへ通信する。ＡＰＰデータパケットを受信することに応じて、アクティブＴＣＰモジュールは、ブロック１４５において、ＡＰＰデータパケットに対応するデータパケットをリモートピアへ通信する。アクティブＴＣＰモジュールは、ブロック１５０において、データパケットがリモートピアにおいて適切に受信されたことを示すデータＡＣＫメッセージをリモートピアから受信する。一実施形態において、アクティブＴＣＰモジュールは、データＡＣＫメッセージを受信することに応じて、ブロック１５５において、データＡＣＫメッセージをアクティブＡＰＰモジュールへ通信する。一方で、別の実施形態において、アクティブＡＰＰモジュールが同期のために最新のＡＣＫシーケンス番号を必要とする場合、アクティブＡＰＰモジュールは当該最新のＡＣＫシーケンス番号をアクティブＴＣＰモジュールから取得する。アクティブＡＰＰモジュールがデータＡＣＫメッセージをアクティブＴＣＰモジュールから受信することに応じて、アクティブＡＰＰモジュールは、ブロック１６０において、データＡＣＫメッセージをスタンバイＡＰＰモジュールに通信する。データＡＣＫメッセージを受信することに応じて、スタンバイＡＰＰモジュールは、確認応答を送信したデータを当該モジュールの再送信リストから除去するであろう。
【００３２】
全てのアクティブＡＰＰモジュールが、生成された出力を対応するスタンバイＡＰＰモジュールに同期させる必要があるとは限らない。例えば、アクティブコンピュータとスタンバイコンピュータとがエコーサーバアプリケーションを実行する場合、アクティブＡＰＰモジュールは、生成された出力をスタンバイＡＰＰモジュールに送る必要はない。生成された出力は、結局のところ、入力に等しい。アクティブＡＰＰモジュールが受信データパケットを同期させている限り、スタンバイＡＰＰモジュールは、出力を再生成することができる。
【００３３】
ただし、アクティブＡＰＰモジュールは、ＴＣＰシーケンス番号又はそれらを再作成するために充分な情報をスタンバイＡＰＰモジュールとの間で同期させる必要がある。スイッチオーバが発生する場合、新たなアクティブＡＰＰモジュール（以前のスタンバイＡＰＰモジュール）は、確認応答が送信されていない如何なるデータパケットも正確なシーケンス番号と共に再送信するであろう。リモートピアは、このデータのうちの幾らかを以前のアクティブＡＰＰモジュールから既に受信済みであるかもしれない。その場合において、リモートピアは、重複したデータをＴＣＰシーケンス番号から検出し、及びデータストリームを正確に再作成することができる。
【００３４】
従って、スタンバイＡＰＰモジュールがいつ出力を再生成し及びパケットをリモートピアへ送信すべきかを認識するのに充分な、又は、スタンバイＡＰＰモジュールがいつリモートピアがデータパケットを受信したのかを認識して確認応答が送信されたデータを自身の再送信リストから除去するのに充分な情報を、やはりアクティブＡＰＰモジュールは同期させる。
【００３５】
図１Ｃは、本発明の実施形態に係る、図１Ａ及び図１Ｂのアクティブアプリケーションから図１Ａ及び図１Ｂのスタンバイアプリケーションへのヒットレススイッチオーバを実行するための方法を例示するフローチャートである。当該方法は、ブロック１６５において開始され、アクティブＡＰＰモジュールは、アクティブＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントのセットからＴＣＰエンドポイント情報を取得する。ＴＣＰ接続がアクティブＴＣＰモジュールとリモートホストとの間で作成される場合、幾つかのＴＣＰ変数について交渉が行われる。例えば、最初のシーケンス番号、最大セグメントサイズ、ウィンドウスケーリング及び他のＴＣＰオプションである。これらは、静的変数と呼ばれる。幾つかのＴＣＰ変数は、動的変数である。例えば、輻輳ウィンドウは、アクティブＴＣＰモジュールとリモートピアとの間の通信期間中に示されるネットワークの振る舞いに応じて変化する。一実施形態において、ＴＣＰエンドポイント情報は静的変数を含む一方で、他の実施形態において、ＴＣＰエンドポイント情報は静的変数及び動的変数を含む。また別の実施形態において、ＴＣＰエンドポイント情報は、静的変数と動的変数とのサブセットを含み、当該サブセットは、スタンバイＴＣＰモジュールがＴＣＰエンドポイントを再作成するのに充分な変数を含む。それ故に、スタンバイＴＣＰモジュールは、ＴＣＰエンドポイント情報を用いて、スイッチオーバを理由に必要に応じてＴＣＰエンドポイントを再作成する。
【００３６】
上記方法は、ブロック１７０に続き、アクティブＡＰＰモジュールは、取得されたＴＣＰエンドポイント情報をスタンバイＡＰＰモジュールへ通信する。その後、スタンバイＡＰＰモジュールは、ブロック１７５において、アクティブＡＰＰモジュールにアクティブ状態を終了させようとしているスイッチオーバイベントを検出し、それによって、スタンバイＡＰＰモジュールがアクティブ状態に入ることが望ましいこととなる。スイッチオーバイベントの例は、ハードウェア障害、ソフトウェア障害、ソフトウェア更新、計画された停電、スケジューリングされたメンテナンス、不適切な構成、及びネットワークメディア障害を含むが、これらに限定されない。一実施形態において、スタンバイＡＰＰモジュールは、ハートビートリクエストをアクティブＡＰＰモジュールに定期的に送り、及び予期しないハートビート応答又はハートビート応答の欠如に応じて劣化イベント（degrading  event）を検出する。別の実施形態において、アクティブＡＰＰモジュールは、ステータスメッセージをスタンバイＡＰＰモジュールへ定期的に送り、スタンバイＡＰＰモジュールは、ステータスメッセージの内容に応じて又はステータスメッセージの欠如を理由に劣化イベントを検出する。
【００３７】
劣化イベントを検出することに応じて、スタンバイＡＰＰモジュールは、スタンバイステータスからアクティブステータスへの移行を開始すべきことを判定する。ブロック１８０において、スタンバイＡＰＰモジュールは、過去に通信されたＴＣＰエンドポイント情報を用いて、スタンバイＴＣＰモジュールにおける１つ以上のＴＣＰエンドポイントの作成を開始する。他の実施形態において、ＴＣＰエンドポイントは、スタンバイＡＰＰモジュールが劣化イベントを検出することに先立って、スタンバイＴＣＰモジュールにおいて作成される。これは、スイッチオーバを実行するために必要とされる時間を低減する。例えば、ＴＣＰエンドポイントは、ＴＣＰエンドポイント情報を受信することに応じて、スタンバイＴＣＰモジュールにおいて作成され得る。この場合において、スタンバイＴＣＰモジュールは、スタンバイモードにある間、作成されるＴＣＰエンドポイントを宛先とするトラフィックをハンドリングしないであろう。なぜなら、アクティブＴＣＰモジュールが当該トラフィックをハンドリングする責任を負うからである。
【００３８】
過去に通信されたＴＣＰエンドポイント情報によって特定されるＴＣＰエンドポイントを作成することに応じて、上記方法は、ブロック１８５へ続き、ヒットレススイッチオーバを実行する。ヒットレススイッチオーバは、スタンバイＡＰＰモジュール及びスタンバイＴＣＰモジュールをスタンバイモードからアクティブモードへ移行させる。一実施形態において、スイッチオーバが計画されている場合、図１Ａを参照しつつ説明されたようにヒットレススイッチオーバは、アクティブＡＰＰモジュール及びアクティブＴＣＰモジュールをアクティブモードからスタンバイモードへさらに移行させ、新たなアクティブＡＰＰモジュールが新たなスタンバイＡＰＰモジュールとの同期を開始する。別の実施形態において、スイッチオーバが計画されている場合、ヒットレススイッチオーバは、アクティブＡＰＰモジュール及びアクティブＴＣＰモジュールをアクティブモードから非アクティブモードへさらに移行させ、新たなアクティブＡＰＰモジュールと非アクティブＡＰＰモジュールとの間では同期は発生しない。
【００３９】
図２は、リモートネットワークエレメントにネットワークを介して結合される、ヒットレススイッチオーバを有するアクティブスタンバイＡＰＰ−ＴＣＰシステムを提供するためのアクティブスタンバイネットワークエレメントを例示するブロック図である。
【００４０】
本明細書において、ネットワークエレメント（例えば、ルータ、スイッチ、ブリッジ）は、ネットワーク上の他の機器（例えば、他のネットワークエレメント、終端局（end  stations））と通信可能に相互接続される、ハードウェア及びソフトウェアを含む１つのネットワーキング機器である。幾つかのネットワークエレメントは、複数のネットワーキング機能（例えば、ルーティング、ブリッジング、スイッチング、レイヤ２アグリゲーション、セッションボーダー制御、サービス品質（Quality  of  Service）、及び／又は加入者管理）についてのサポートを提供し、及び／又は複数のアプリケーションサービス（例えば、データ、音声、及びビデオ）についてのサポートを提供する「マルチサービスのネットワークエレメント（multiple  services  network  elements）」である。加入者端局（subscriber  end  stations）（例えば、サーバ、ワークステーション、ラップトップ、ネットブック、パームトップ、携帯電話、スマートフォン、マルチメディアフォン、ＶＯＩＰ（Voice  Over  Internet  Protocol）電話、ユーザ機器、端末、ポータブルメディアプレーヤ、ＧＰＳユニット、ゲーム機、セットトップボックス）は、インターネット上で提供されるコンテンツ／サービス及び／又はインターネット上にオーバーレイされる（例えば、インターネットを通じてトンネリングされる）ＶＰＮ（virtual  private  networks）上で提供されるコンテンツ／サービスにアクセスする。コンテンツ及び／又はサービスは、典型的に、サービスプロバイダ若しくはコンテンツプロバイダに属する１つ以上の終端局（例えば、サーバ端局（server  end  stations））又はピアツーピアサービスに参加する終端局によって提供され、及び、例えば、パブリックウェブページ（例えば、無料コンテンツ、ストアフロント、検索サービス）、プライベートウェブページ（例えば、電子メールサービスを提供する、ユーザ名／パスワードによりアクセスされるウェブページ）、及び／又はＶＰＮ上の企業ネットワークを含み得る。典型的に、加入者端局は、（例えば、（無線又は有線で）アクセスネットワークに結合される顧客構内の機器を通じて）エッジネットワークエレメントに結合され、当該エッジネットワークエレメントは、（例えば、１つ以上のコアネットワークエレメントを通じて）他のエッジネットワークエレメントに結合され、当該他のエッジネットワークエレメントは、他の終端局（例えば、サーバ端局）に結合される。
【００４１】
ネットワークエレメントは、一般に、制御プレーンと、（転送プレーン又はメディアプレーンと呼ばれることもある）データプレーンと、に分けられる。ネットワークエレメントがルータである（又は、ルーティングの機能性を実装している）場合、制御プレーンは、典型的に、どのようにデータ（例えば、パケット）がルーティングされるべきか（例えば、データについてのネクストホップ及び当該データについてのアウトゴーイングポート）を判定し、データプレーンは、当該データを転送することを担う。例えば、制御プレーンは、典型的に、他のネットワークエレメントと通信してルートを交換し及び１つ以上のルーティングメトリックに基づいてそれらのルートを選択する１つ以上のルーティングプロトコル（例えば、ボーダーゲートウェイプロトコル（ＢＧＰ）、内部ゲートウェイプロトコル（ＩＧＰ：Interior  Gateway  Protocol(s)）（例えば、ＯＳＰＦ（Open  Shortest  Path  First）、ＲＩＰ（Routing  Information  Protocol）、ＩＳ−ＩＳ（Intermediate  System  to  Intermediate  System））、ラベル配布プロトコル（ＬＤＰ：Label  Distribution  Protocol）、リソース予約プロトコル（ＲＳＶＰ：Resource  Reservation  Protocol））を含む。
【００４２】
ルート及び隣接関係（adjacencies）は、制御プレーン上の１つ以上のルーティング構造（例えば、ルーティング情報ベース（ＲＩＢ：Routing  Information  Base）、ラベル情報ベース（ＬＩＢ：Label  Information  Base）、１つ以上の隣接関係構造）に記憶される。制御プレーンは、ルーティング構造に基づく情報（例えば、隣接関係及びルート情報）を用いてデータプレーンをプログラミングする。例えば、制御プレーンは、データプレーン上の１つ以上の転送構造（例えば、転送情報ベース（ＦＩＢ：Forwarding  Information  Base）、ラベル転送情報ベース（ＬＦＩＢ：Label  Forwarding  Information  Base）、及び１つ以上の隣接関係構造）に隣接関係及びルート情報をプログラミングする。データプレーンは、トラフィックを転送する際、これらの転送構造及び隣接関係構造を用いる。
【００４３】
一実施形態において、ネットワークエレメントは、１つ以上のラインカードのセットと、１つ以上の制御カードのセットと、随意的に１つ以上の（リソースカードと呼ばれることもある）サービスカードのセットと、を備える。これらのカードは、１つ以上のメカニズム（例えば、ラインカードを結合する第１のフルメッシュ及びカードの全てを結合する第２のフルメッシュ）を通じて互いに結合される。ラインカードのセットは、データプレーンを構成する一方、制御カードのセットは、制御プレーンを提供し及びラインカードを通じて外部のネットワークエレメントとパケットを交換する。サービスカードのセットは、特殊な処理（例えば、レイヤ４からレイヤ７のサービス（例えば、ファイアウォール、ＩＰｓｅｃ、ＩＤＳ、Ｐ２Ｐ）、ＶｏＩＰセッションボーダーコントローラ、モバイルワイヤレスゲートウェイ（ＧＧＳＮ、ＥＰＳ（Evolved  Packet  System）ゲートウェイ））を提供することができる。一例として、サービスカードは、ＩＰｓｅｃトンネルを終端させ、並びに付随する認証及び暗号化アルゴリズムを実行するために用いられ得る。代替的な実施形態は、（例えば、ラインカードと制御カードとの分離が存在しない場合）異なるネットワークエレメントアーキテクチャを用い得る。
【００４４】
図２は、図１Ａ、図１Ｂ、及び図１Ｃの例示的な動作を参照しつつ説明されるであろう。ただし、図１Ａ、図１Ｂ、及び図１Ｃの動作は図２を参照しつつ議論される実施形態以外の実施形態によって実行されることができることが理解されるべきである。さらに、図３は、図１Ａ、図１Ｂ、及び図１Ｃを参照しつつ説明される動作とは異なる動作を実行することができる。
【００４５】
図２は、アクティブスタンバイネットワークエレメント２１０を例示する。アクティブスタンバイネットワークエレメント２１０は、アクティブ制御カード２１５と、スタンバイ制御カード２４０と、１つ以上のラインカード２６５Ａ〜２６５Ｎのセットと、を備える。アクティブ制御カード２１５は、通信チャネル２７５Ａを通じて１つ以上のラインカード２６５Ａ〜２６５Ｎのセットに結合され、スタンバイ制御カード２４０は、通信チャネル２７５Ｂを通じて１つ以上のラインカード２６５Ａ〜２６５Ｎのセットに結合される。
【００４６】
アクティブ制御カード２１５は、アクティブＴＣＰモジュール２３５に結合されるアクティブＡＰＰモジュール２３０を含む。スタンバイ制御カード２４０は、スタンバイＴＣＰモジュール２６０に結合されるスタンバイＡＰＰモジュール２５５を含む。アクティブＡＰＰモジュール２３０は、インタープロセス通信チャネル２７０を通じてスタンバイＡＰＰモジュール２５５に結合される。アクティブＡＰＰモジュール２３０は、アクティブプロセス２３２を実行する一方、スタンバイＡＰＰモジュール２５５は、スタンバイプロセス２５７を実行する。一実施形態において、ネットワークエレメント２１０は、アクティブＢＧＰ  ＡＰＰ及びスタンバイＢＧＰ  ＡＰＰを実行するＢＧＰルータである一方、別の実施形態において、当該ネットワークエレメントは、アクティブＬＤＰプロセス及びスタンバイＬＤＰプロセスを実行するマルチプロトコルラベルスイッチング（ＭＰＬＳ）ルータである。また別の実施形態において、ネットワークエレメントは、アクティブＡＮＣＰ（Access  Node  Control  Protocol）プロセス及びスタンバイＡＮＣＰプロセスを実行するブロードバンドリモートアクセスサーバ（ＢＲＡＳ）である。本発明の実施形態が他のアクティブスタンバイアプリケーションについて、特にＴＣＰ送信の状態がアクティブアプリケーションからスタンバイアプリケーションへの適切なスイッチオーバに重要である場合に適切であることを当業者は認識するであろう。一実施形態において、アクティブＡＰＰモジュール２３０、アクティブＴＣＰモジュール２３５、スタンバイＡＰＰモジュール２５５、及びスタンバイＴＣＰモジュール２６０は、図１Ａ、図１Ｂ、及び図１Ｃを参照しつつ説明された機能を実行するように構成される別個のハードウェアモジュールである。別の実施形態において、アクティブＡＰＰモジュール２３０、アクティブＴＣＰモジュール２３５、スタンバイＡＰＰモジュール２５５、及びスタンバイＴＣＰモジュール２６０は、アクティブスタンバイネットワークエレメント２１０内で実行されるソフトウェアモジュールである。また別の実施形態において、アクティブＡＰＰモジュール２３０、アクティブＴＣＰモジュール２３５、スタンバイＡＰＰモジュール２５５、及びスタンバイＴＣＰモジュール２６０は、アクティブスタンバイネットワークエレメント２１０内で実行される専用ハードウェアモジュール及び専用ソフトウェアモジュールの双方から成る。
【００４７】
１つ以上のラインカード２６５Ａ〜２６５Ｎのセットのうちの１つ以上は、ＩＰ通信チャネル２７６Ａを通じてネットワーク２８０に結合され、ネットワーク２８０は、ＩＰ通信チャネル２７６Ｂを通じてリモートネットワークエレメント２００に結合される。リモートネットワークエレメント２００は、リモートＡＰＰモジュール２０７に結合されるリモートＴＣＰモジュール２０５を備える。リモートＡＰＰモジュール２０７は、アクティブプロセス２３２に対応するリモートプロセスを実行する。
【００４８】
図３は、本発明の実施形態に係る、リモートピアからネットワークエレメントにおいて受信されるデータについての確認応答及びメッセージのパスを例示するデータフロー図である。図３は、リモートネットワークエレメント３００と、アクティブ／スタンバイネットワークエレメント３０２と、を含む。リモートネットワークエレメント３００は、リモートＴＣＰモジュール３０１を含む。アクティブ／スタンバイネットワークエレメント３０２は、アクティブ制御カード３０５と、スタンバイ制御カード３１０と、を含む。アクティブ制御カード３０５は、アクティブＴＣＰモジュール３０６と、アクティブＡＰＰモジュール３０７と、を含む。スタンバイ制御カード３１０は、スタンバイａｐｐモジュール３１１と、スタンバイＴＣＰモジュール３１２と、を含む。各モジュールは図３の上部に例示され、縦線は時間の経過を例示し、１つの縦線から別の縦線へ進む線はある瞬間におけるデータの送信を例示する。
【００４９】
リモートＴＣＰモジュール３０１は、データパケット１（ＤＡＴＡ１）  ３１５ＡをアクティブＴＣＰモジュール３０６へ通信することから開始する。アプリケーションデータＤＡＴＡ１  ３１５Ａを受信することに応じて、アクティブＴＣＰモジュール３０６は、ＤＡＴＡ１  ３１５ＢをアクティブＡＰＰモジュール３０７へ通信する。注目すべきことは、アクティブＴＣＰモジュールがリモートＴＣＰモジュール３０１へＡＣＫを送信しないことである。ＤＡＴＡ１  ３１５Ｂを受信することに応じて、アクティブＡＰＰモジュール３０７は、ＤＡＴＡ１  ３１５ＣをスタンバイＡＰＰモジュール３１１へ送る。ＤＡＴＡ１  ３１５Ｃは、アクティブＡＰＰモジュール３０７をスタンバイＡＰＰモジュール３１１に同期させるために当該アクティブＡＰＰモジュール３０７によって用いられるＡＰＰ  ＳＹＮＣメッセージである。スタンバイＡＰＰモジュール３１１は、確認応答パケットＡＣＫ１  ３１６ＡをアクティブＡＰＰモジュール３０７へ通信する。ＡＣＫ１は、ＡＰＰ  ＳＹＮＣメッセージを受信したことに対して確認応答を行うためにスタンバイＡＰＰモジュールによって用いられるＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージである。ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージを受信することに応じて、アクティブＡＰＰモジュール３０７は、ＡＰＰ  ＡＣＫメッセージであるＡＣＫ１  ３１６ＢをアクティブＴＣＰモジュール３０６へ通信する。ＡＣＫ１  ３１６Ｂを受信することに応じて、アクティブＴＣＰモジュール３０６は、ＡＣＫ１  ３１６ＣをリモートＴＣＰモジュール３０１へ通信する。このようにして、アクティブＴＣＰモジュール３０６からリモートＴＣＰモジュール３０１への確認応答は、アクティブＡＰＰモジュール３０７がスタンバイＡＰＰモジュール３１１と同期することが可能になり、ＤＡＴＡ１パケット３１５Ａの処理の期間中にＡＰＰレベル及びＴＣＰレベルの双方における同期が可能となるまで送信されない。
【００５０】
図３は、同様に、リモートＴＣＰモジュール３０１がデータパケット２（ＤＡＴＡ２）  ３２０ＡをアクティブＴＣＰモジュール３０６へ通信し、当該アクティブＴＣＰモジュール３０６がＤＡＴＡ２  ３２０ＢをアクティブＡＰＰモジュール３０７へ通信することを示す。アクティブＡＰＰモジュールは、ＡＰＰ  ＳＹＮＣメッセージであるＤＡＴＡ２  ３２０ＣをスタンバイＡＰＰモジュール３１１へ通信し、当該スタンバイＡＰＰモジュール３１１は、ＡＰＰ  ＳＹＮＣ  ＡＣＫであるＡＣＫ  ２（ＡＣＫ２）  ３２１Ａを用いてアクティブＡＰＰモジュール３１１に応答する。アクティブＡＰＰモジュール３１１は、ＡＰＰ  ＡＣＫであるＡＣＫ２  ３２１Ｂを用いてアクティブＴＣＰモジュール３０６に応答する。しかしながら、アクティブＴＣＰモジュール３０６は、ＡＣＫ２  ３２１Ｂを受信しない。なぜなら、受信する前にスイッチオーバイベント３３０が発生するからである。さらに、リモートＴＣＰモジュール３０１は、劣化イベント３３０に先立って、データパケット（ＤＡＴＡ３）  ３２５Ａを通信する。しかしながら、リモートＴＣＰモジュール３０１がＤＡＴＡ３  ３３２５Ａを送信した後であって、且つアクティブＴＣＰモジュール３０６がＤＡＴＡ３を受信する前に、劣化イベントが発生する。スイッチオーバイベントを検出することに応じて、スタンバイ制御カード３１０は、ヒットレススイッチオーバ３３５を実行し及びアクティブモードへ移行する。
【００５１】
この時点において、リモートＴＣＰモジュール３０１は、ＡＣＫ２又はＡＣＫ３を受信していない。それ故に、リモートＴＣＰモジュールは、ＤＡＴＡ２  ３３７Ａをアクティブ／スタンバイネットワークエレメント３０２へ再送信する。スタンバイＴＣＰモジュール３１２はアクティブモードへ移行済みなので、スタンバイＴＣＰモジュール３１２は、インカミングトラフィックについての責任を引き受けており、ＤＡＴＡ２  ３３７Ａを受信する。スタンバイＴＣＰモジュール３１２は、今やアクティブモードにあるスタンバイＡＰＰモジュール３１１へＤＡＴＡ２  ３３７Ｂを通信する。スタンバイＡＰＰモジュール３１１は、ＤＡＴＡ２  ３３７Ａが以前に受信され及び適切に処理されたことを認識するため、当該スタンバイＡＰＰモジュール３１１は、当該データを破棄し又は無視し、及びＡＰＰ  ＡＣＫメッセージ（ＡＣＫ２）  ３４０ＡをスタンバイＴＣＰモジュール３１２へ通信するであろう。ＡＣＫ２  ３４０Ａを受信することに応じて、スタンバイＴＣＰモジュール３１２は、ＡＣＫ２  ３４０ＢをリモートＴＣＰモジュール３０１へ通信するであろう。さらに、リモートＴＣＰモジュールは、ＤＡＴＡ３  ３４５Ａをアクティブ／スタンバイネットワークエレメント３０２へ再送信する。スタンバイＴＣＰモジュール３１２は、ＤＡＴＡ３  ３４５Ａを受信し及びＤＡＴＡ３  ３４５ＢをスタンバイＡＰＰモジュール３１１へ通信する。スタンバイＡＰＰモジュール３１１は、ＤＡＴＡ３  ３４５Ｂを処理し及びａｐｐ  ＡＣＫメッセージＡＣＫ３  ３５０ＡをスタンバイＴＣＰモジュール３１２へ通信する。ＡＣＫ３  ３５０Ａを受信することに応じて、スタンバイＴＣＰモジュール３１２は、ＡＣＫ３  ３５０ＢをリモートＴＣＰモジュール３０１へ通信する。
【００５２】
図４は、本発明の実施形態に係る、ネットワークエレメントからリモートピアへ送信されるデータについての確認応答及びメッセージのパスを例示するデータフロー図である。図４は、リモートネットワークエレメント４００と、アクティブ／スタンバイネットワークエレメント４０２と、を含む。リモートネットワークエレメント４００は、リモートＴＣＰモジュール４０１を含む。アクティブ／スタンバイネットワークエレメント４０２は、アクティブ制御カード４０５と、スタンバイ制御カード４１０と、を含む。アクティブ制御カード４０５は、アクティブＴＣＰモジュール４０６と、アクティブＡＰＰモジュール４０７と、を含む。スタンバイ制御カード４１０は、スタンバイａｐｐモジュール４１１と、スタンバイＴＣＰモジュール４１２と、を含む。各モジュールは図４の上部に例示され、縦線は時間の経過を例示し、１つの縦線から別の縦線へ進む線はある瞬間におけるデータの送信を例示する。
【００５３】
図４は、アクティブＡＰＰモジュール４０７がＡＰＰ  ＳＹＮＣメッセージＤＡＴＡ１  ４１５ＡをスタンバイＡＰＰモジュール４１１へ通信し、当該スタンバイＡＰＰモジュール４１１がＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージＡＣＫ１  ４１６Ａにより応答することから開始する。ＡＣＫ１  ４１６Ａを受信することに応じて、アクティブＡＰＰモジュール４０７は、アプリケーションデータＤＡＴＡ１  ４１５ＢをアクティブＴＣＰモジュール４０６へ通信し、当該アクティブＴＣＰモジュール４０６は、データパケットＤＡＴＡ１  ４１５ＣをリモートＴＣＰモジュール４０１へ通信する。ＤＡＴＡ１  ４１５Ｃを受信することに応じて、リモートＴＣＰモジュールは、ＡＣＫメッセージＡＣＫ１  ４１６ＢをアクティブＴＣＰモジュール４０６へ通信し、当該アクティブＴＣＰモジュール４０６は、ＡＣＫ１  ４１６ＣをアクティブＡＰＰモジュール４０７へ通信する。ＡＣＫ１  ４１６Ｃを受信することに応じて、アクティブＡＰＰモジュール４０７は、ＡＣＫ１  ４１６ＤをスタンバイＡＰＰモジュール４１１へ通信する。それによって、アクティブＡＰＰモジュール４０７及びスタンバイＡＰＰモジュール４１１の双方は、それらの再送信リストからＤＡＴＡ１を除去する。
【００５４】
同様に、アクティブＡＰＰモジュール４０７は、ＡＰＰ  ＳＹＮＣメッセージＤＡＴＡ２  ４２０ＡをスタンバイＡＰＰモジュール４１１へ通信し、当該スタンバイＡＰＰモジュール４１１は、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージＡＣＫ２  ４２１Ａにより応答する。ＡＣＫ２  ４２１Ａを受信することに応じて、アクティブＡＰＰモジュール４０７は、データパケットＤＡＴＡ２  ４２０ＢをアクティブＴＣＰモジュール４０６へ通信し、当該アクティブＴＣＰモジュール４０６は、データパケットＤＡＴＡ２  ４２０ＣをリモートＴＣＰモジュールリモートＴＣＰモジュール４０１へ通信する。ＤＡＴＡ２  ４２０Ｃを受信することに応じて、リモートＴＣＰモジュールは、ＡＣＫメッセージＡＣＫ２  ４２１ＢをアクティブＴＣＰモジュール４０６へ通信する。しかしながら、アクティブＴＣＰモジュール４０６は、ＡＣＫ２  ４２１Ｂを受信しない。なぜなら、受信の前にスイッチオーバイベント４３０が発生するからである。ＤＡＴＡ２  ４２０ＢをアクティブＴＣＰモジュール４０６へ送信した後で、ただし劣化イベント４３０に先立って、アクティブＡＰＰモジュール４０７は、ＡＰＰ  ＳＹＮＣメッセージＤＡＴＡ３  ４２５ＡをスタンバイＡＰＰモジュール４１１へ通信し、当該スタンバイＡＰＰモジュール４１１は、ＡＰＰ  ＳＹＮＣ  ＡＣＫメッセージＡＣＫ３  ４２６Ａにより応答する。ＡＣＫ３  ４２６Ａを受信することに応じて、アクティブＡＰＰモジュール４０７は、ＤＡＴＡ３  ４２５ＢをアクティブＴＣＰモジュール４０６へ通信するが、受信に先立って劣化イベント４３０が発生する。スイッチオーバイベントを検出することに応じて、スタンバイ制御カード４１０は、ヒットレススイッチオーバ４３５を実行し及びアクティブモードへ移行する。
【００５５】
この時点において、今やアクティブモードにあるスタンバイＡＰＰモジュール４１１は、ＡＣＫ２又はＡＣＫ３を受信しておらず、その再送信リストを用いてどのパケットを再送信すべきかを判定するであろう。スタンバイＡＰＰモジュール４１１は、今やアクティブモードにあるスタンバイＴＣＰモジュール４１２へＤＡＴＡ２  ４４０を通信し、スタンバイＴＣＰモジュール４１２は、ＤＡＴＡ２  ４４０ＢをリモートＴＣＰモジュール４０１へ通信することによって応答するであろう。リモートＴＣＰモジュール４０１は、ＤＡＴＡ２  ４２０Ｃを既に受信済みであり、従って、ＤＡＴＡ  ４４０Ｂは重複する。リモートＴＣＰモジュールは、重複するデータを認識し及びＡＣＫメッセージＡＣＫ２  ４４１Ａを返信することが期待される。スタンバイＴＣＰモジュール４１２は、ＡＣＫ２  ４４１Ａを受信し、及びそれに応じてＡＣＫ２  ４４１ＢをスタンバイＡＰＰモジュール４１１へ通信するであろう。さらに、スタンバイＡＰＰモジュール４１１は、ＤＡＴＡ３を再送する必要があり、及びＤＡＴＡ３  ４４５ＡをスタンバイＴＣＰモジュールへ通信するであろう。スタンバイＴＣＰモジュールは、ＤＡＴＡ３  ４４５ＢをリモートＴＣＰモジュール４０１へ通信することによって応答するであろう。リモートＴＣＰモジュール４０１は、ＡＣＫメッセージＡＣＫ３  ４４６ＡをスタンバイＴＣＰモジュール４１２へ通信することによってＤＡＴＡ３  ４４５Ｂに応じ、スタンバイＴＣＰモジュール４１２は、それに応じてＡＣＫ３  ４４６ＢをスタンバイＡＰＰモジュール４１１へ通信するであろう。それによって、スタンバイＡＰＰモジュール４１１は、ＤＡＴＡ２及びＤＡＴＡ３を、これらのデータをリモートＴＣＰモジュール４０１へ再送するその再送信リストから除去するであろう。
【００５６】
本明細書において、命令は、ある動作を実行するように構成され若しくは所定の機能性を有する特定用途向け集積回路（ＡＳＩＣ：application  specific  integrated  circuit）などのハードウェアの特定の構成、又は非一時的なコンピュータ読取可能な媒体において具現化されるメモリに記憶されるソフトウェア命令を指し得る。従って、図において示される技法は、１つ以上の電子デバイス（例えば、終端局、ネットワークエレメント）上に記憶され及び実行されるコード及びデータを用いて実装されることができる。そのような電子デバイスは、非一時的なコンピュータ読取可能な記憶媒体（例えば、磁気ディスク；光ディスク；ＲＡＭ（random  access  memory）；ＲＯＭ（read  only  memory）；フラッシュメモリデバイス；相変化メモリ）及び一時的なコンピュータ読取可能な媒体（例えば、電気的、光学的、音響的又は他の形式の伝搬信号−搬送波、赤外線信号、デジタル信号など）といったコンピュータ読取可能な媒体を用いて、コード及びデータを記憶し及び（内部的に及び／又はネットワーク上で他の電子デバイスと）通信する。また、そのような電子デバイスは、典型的に、１つ以上のストレージデバイス（非一時的な機械読取可能なストレージメディア）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、及びネットワーク接続といった１つ以上の他のコンポーネントに結合される１つ以上のプロセッサのセットを含む。プロセッサのセットと他のコンポーネントとの結合は、典型的に、１つ以上のバス及び（バスコントローラとも呼ばれる）ブリッジを介する。従って、所与の電子デバイスのストレージデバイスは、典型的に、当該電子デバイスの１つ以上のプロセッサのセット上での実行のためのコード及び／又はデータを記憶する。言うまでもなく、本発明のある実施形態のうちの１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの様々な組み合わせを用いて実装され得る。
【００５７】
代替的な実施形態
図におけるフロー図は本発明のある実施形態によって実行される動作の特定の順序を示すが、そのような順序は例示的である（例えば、代替的な実施形態は、当該動作を異なる順序で実行し、ある動作を結合し、ある動作を重複させる等し得る）ことが理解されるべきである。
【００５８】
本発明は幾つかの実施形態の観点から説明されてきたが、本発明が説明された実施形態に限定されず、添付の特許請求の範囲及び思想内で変形及び変更により実施をされることができることを当業者は認識するであろう。従って、上記説明は、限定ではなく例示として見なされるべきである。
【図１Ａ】
0005981533.tif 000002
【図１Ｂ】
0005981533.tif 000003
【図１Ｃ】
0005981533.tif 000004
【図２】
0005981533.tif 000005
【図３】
0005981533.tif 000006
【図４】
0005981533.tif 000007