JP2009501472A

JP2009501472A - プロトコルプロセスの移動（ｍｉｇｒａｔｉｏｎ）に関する方法およびルータ

Info

Publication number: JP2009501472A
Application number: JP2008520980A
Authority: JP
Inventors: シヴァクマール，カールティック; ボーガヴィリ，スレス; シャー，サミール; シャーウィン，クリストファー
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2005-07-15
Filing date: 2006-07-14
Publication date: 2009-01-15
Anticipated expiration: 2026-07-14
Also published as: ES2406059T3; US7583590B2; CN104917676A; CA2615110A1; CN101268662A; JP4769869B2; EP1905203A1; CN104917676B; US20070014231A1; WO2007010354A1; EP1905203B8; EP1905203B1

Abstract

ルータへのパケットの流れを維持し、かつ、そのルータがリスタート情報を獲得することを支援するためのグレースフルリスタート手順を利用して、１つのルートプロセッサ（ＲＰ）から別のＲＰにルーティングプロトコルプロセスまたは仮想ルータ（ＶＲ）を移動するルータおよび方法。ルータは、第１および第２ＲＰ、および、ネットワーク内の近隣のルータにパケットを転送する転送エンジンを備える。第１ＲＰでルーティングプロトコルプロセスが終了されると、近隣のルータはルータの失敗を検知し、グレースフルリスタート手順を開始する。転送エンジン内のフィルタールールが、転送エンジンによる第２ＲＰ上の新しいルーティングプロトコルプロセスへのパケットの転送を引き起こす。新しいプロセスは、近隣のルータからネットワークトポロジーを学習し、移動はパケットを失うことなく、ネットワークプロトコルスタックに対する複雑な変更もなく、完了される。
【選択図】図１

Description

本発明は、通信システムに関する。限定することを目的としないが、より詳細には、本発明は、グレースフルリスタート手順（ｇｒａｃｅｆｕｌｒｅｓｔａｒｔｐｒｏｃｅｄｕｒｅ）を使用して１つのルートプロセッサから別のルートプロセッサにプロトコルプロセスを移動するための、インターネットプロトコル（ＩＰ：ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）に基づくネットワークでの方法およびルータに関する。

最新技術のＩＰルータでは、制御機能とパケット転送機能とを処理するために異なるプロセッサが備えられている。制御プロセッサで実行中のプロトコルの信号送信およびルーティングが失敗すると、前述のような転送に必要とされる全ての情報がパケット転送プロセッサにとって利用可能であっても、ペイロードのトラフィックは中断される。この中断は、近隣のルータ（ｎｅｉｇｈｂｏｒｒｏｕｔｅｒ）がプロトコルの信号送信およびルーティングの失敗を検出し、ルータ全体が失敗したと認識することが原因で発生する。その結果、近隣のルータは「失敗した」ルータを迂回する代替経路を算出する。この時間、いわゆるルーティング収束時間（ｒｏｕｔｉｎｇｃｏｎｖｅｒｇｅｎｃｅｔｉｍｅ）の間に、トラフィックを消失する可能性がある。

この問題を解決するために、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）は、近隣のルータで失敗したプロトコルプロセスのリスタート（再起動）を手順よく（ｇｒａｃｅｆｕｌｌｙ）処理するプロトコルの信号送信およびルーティングに対する一連の拡張を標準化した。これらの拡張が備えられ、ルータの制御ソフトウェアがリスタートされる必要があると、そのルータの近隣のルータはトラフィックの転送のためにそのルータを使い続ける。近隣のルータは、リスタートされたルータのソフトウェアが失敗する前に知っていた状態を再度学習することを補助もする。

ＩＰネットワーク操作者が、それらが存在する基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の最上部（ｔｏｐ）で、バーチャルプライベートネットワーク（ＶＰＮ：ＶｉｒｔｕａｌＰｒｉｖａｔｅＮｅｔｗｏｒｋ）を構築し、管理し、提供することも既知である。これらのネットワークは、一般に、地理的に離れた場所の間で相互接続（ｉｎｔｅｒｃｏｎｎｅｃｔｉｖｉｔｙ）が必要な企業によって使用される。プライベートネットワークの使用は、プライベートネットワークが侵入者からのある程度の保護を提供するという理由でも魅力的である。テレコムネットワーク操作者も、テレコムトラフィックの様々な種類（ｃｌａｓｓ）の間でのトラフックの分離を提供するためにＶＰＮを使用する。これは、これらのトラフィックの種類に対する異なるサービス品質（ＱｏＳ：ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）およびセキュリティーサービスを提供するために有用である。

ＩＰネットワークのスピードおよび大きさの成長に伴い、ルータまたはパケット処理ノードは、拡張可能である必要がある。そうでなければ、処理能力の増加が要求されるにつれて、またはより多くの顧客ＶＰＮが構成されるにつれて、追加される複雑な操作と費用とを伴って、さらに多くのルータが備えられなくてはならない。ＩＰネットワークおよびテレコムネットワークの回復力（ｒｅｓｉｌｉｅｎｃｙ）および拡張性（ｓｃａｌａｂｉｌｉｔｙ）のニーズに対処するため、ルータまたはパケット処理ノードは、ますますプロセッサのクラスタを使用して設計される。回復力のニーズに対処するために、クラスタ管理ソフトウェアとして知られているミドルウェアは、複数のプロセッサに処理の負荷を分散する。処理要求の増加は、クラスタにさらにプロセッサを追加し、新しいプロセッサにプロセスを移動することによって解決される。プロセスが必要とするあらゆる状態（ｓｔａｔｅ）もクラスタ管理ソフトウェアによって新しい場所に移動される。効果的ではあるが、プロセッサのクラスタの使用は、ルータの実装の費用および複雑さを増加する。

ノードの失敗に対する回復力を提供する代替案は、１以上の制御プロセッサ（一般的にルートプロセッサまたはＲＰとして知られている）を、主系のＲＰをバックアップするために、ホットスタンバイの状態で維持することである。プロトコルの状態は、主系ＲＰとバックアップ系ＲＰとの間で複製される。主系ＲＰが失敗した場合、バックアップ系ＲＰが引き継いで、そのルータの近隣のルータから失敗を隠す（ｍａｓｋ）。この方法の複雑さは、主系ＲＰとバックアップ系ＲＰとの間で状態情報（ｓｔａｔｅｉｎｆｏｒｍａｔｉｏｎ）の同期を行うところにある。ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）上で実行されるＬＤＰ（ＬａｂｅｌＤｉｓｔｒｉｂｕｔｉｏｎＰｒｏｔｏｃｏｌ）およびＢＧＰ（ＢｏｒｄｅｒＧａｔｅｗａｙＰｒｏｔｏｃｏｌ）のようなプロトコルに関して、（シーケンス番号、輻輳ウィンドウパラメータ（ｃｏｎｇｅｓｔｉｏｎｗｉｎｄｏｗｐａｒａｍｅｔｅｒ）等の）ＴＣＰセッション状態も複製される必要がある。

このように、従来のシステムおよび方法の問題点を解決することが可能な、ＩＰネットワークおよびテレコムネットワークの回復力および拡張性のニーズに対処するより効果的な方法が技術的に求められている。本発明はそのようなルータおよび方法を提供する。

本発明は、グレースフルリスタート手順を使用して１つのルートプロセッサ（ＲＰ：ＲｏｕｔｅＰｒｏｃｅｓｓｏｒ）から別のルートプロセッサにルーティングプロトコルプロセスを移動する方法およびルータを提供する。前述の複数のＲＰは、同じルータにあってもよいし、別のルータにあってもよい。同様のメカニズムが、仮想ルータ（ＶＲ：ＶｉｒｔｕａｌＲｏｕｔｅｒ）と、それに関する全てのプロセスを１つのＲＰから別のＲＰに移動するために利用される。

このように、一実施形態では、本発明は、インターネットプロトコル（ＩＰ）に基づくネットワーク内のルータで、第１ルートプロセッサから、第２ルートプロセッサにルーティングプロトコルプロセスを移動する方法に関する。前記ルータは、前記ネットワーク内の近隣のルータにパケットを転送するための転送エンジンを備え、前記近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータが失敗した場合に前記ルータを支援するためのグレースフルリスタート手順を備える。本方法は、前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了し、そのことによって前記近隣のルータに前記ルータが失敗したことを示し、前記近隣のルータが前記グレースフルリスタート手順を開始する原因となるステップ、および、前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートするステップを含む。本方法は、前記転送エンジンによって、前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットが、前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換されるステップ、および、前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスが、前記近隣のルータから前記ネットワークトポロジーに関する情報を受信するステップを含む。本実施形態では、ルーティングプロトコルプロセスは、例えば、ＢＧＰ（ＢｏｒｄｅｒＧａｔｅｗａｙＰｒｏｔｏｃｏｌ）プロセスであってもよい。

別の一実施形態では、本方法は、前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了するステップと、前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了した後に前記転送エンジンにフィルタールールを追加するステップとを含んでもよい。前記フィルタールールは、前記転送エンジンが前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットを前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換する原因となる。本方法は、前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートするステップと、前記近隣のルータがグレースフルリスタート手順を開始することを要求するメッセージを、それぞれの前記近隣のルータに送信するステップと、前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスが、前記近隣のルータから前記ネットワークトポロジーに関する情報を受信するステップと、も含む。本実施形態では、ルーティングプロトコルプロセスは、例えば、ＯＳＰＦ（ＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔ）プロセス、または、ＩＳ−ＩＳプロトコル（ＩｎｔｅｒｍｅｄｉａｔｅＳｙｓｔｅｍｔｏＩｎｔｅｒｍｅｄｉａｔｅＳｙｓｔｅｍＰｒｏｔｏｃｏｌ）プロセスであってもよい。

更なる別の一実施形態では、ルーティングプロトコルプロセスが定義されたグレースフルリスタート手順を有さない場合、前記方法は、前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了するステップと、前記転送エンジンにフィルタールールを追加するステップと、前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートするステップと、それぞれの前記近隣のルータから、プロトコル状態に関する周期的なリフレッシュメッセージを受信するステップと、を含む。前記リフレッシュメッセージは前記ネットワークのルーティングドメイン内の全てのルータに対応する情報を含む。前記ルータは、その後、前記ルータが操作可能であることを通知するメッセージを、それぞれの前記近隣のルータに送信する。本実施形態では、ルーティングプロトコルプロセスは、例えば、ＲＩＰ（ＲｏｕｔｉｎｇＩｎｆｏｒｍａｔｉｏｎＰｒｏｔｏｃｏｌ）であってもよい。

更なる別の一実施形態では、本発明は、ＩＰに基づくネットワーク内のルータで、第１ルートプロセッサから、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサに仮想ルータ（ＶＲ）を移動する方法に関する。前記ルータは、前記ネットワーク内の近隣のルータにパケットを転送するための転送エンジンを備え、前記ＶＲは、ルーティングおよびシグナリングプロトコルプロセスと、前記転送エンジンで使用される転送情報基盤（ｆｏｒｗａｒｄｉｎｇｉｎｆｏｒｍａｔｉｏｎｂａｓｅ）を算出するルートテーブルマネージャ（ＲＴＭ）とを含み、前記近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータが失敗した場合に前記ルータを支援するためのグレースフルリスタート手順を備える。前記方法は、前記第１ルートプロセッサで前記ＶＲのルーティングおよびシグナリングプロトコルプロセスを終了し、そのことによって前記近隣のルータに前記ルータが失敗したことを示し、前記近隣のルータが前記グレースフルリスタート手順を開始する原因となるステップと、前記第２ルートプロセッサで前記ＶＲのルーティングおよびシグナリングプロトコルプロセスをリスタートするステップと、前記転送エンジンによって、前記第１ルートプロセッサ上の前記ＶＲのルーティングおよびシグナリングプロトコルプロセス宛のパケットが、前記第２ルートプロセッサ上でリスタートされた前記ＶＲのルーティングおよびシグナリングプロトコルプロセスに方向転換されるステップと、を含む。前記方法は、前記第２ルートプロセッサ上でリスタートされた前記ＶＲのルーティングおよびシグナリングプロトコルプロセスが、前記近隣のルータから前記ネットワークトポロジーに関する情報を受信するステップと、前記第２ルートプロセッサ上で前記ＶＲのＲＴＭをリスタートするステップと、前記リスタートされたＶＲのＲＴＭは、前記リスタートされたＶＲのルーティングおよびシグナリングプロトコルプロセスから前記ネットワークトポロジーに関する情報を受信し、そのことによってルーティング状態を確立するステップと、も含む。前記方法は、前記リスタートされたＶＲのＲＴＭは、前記転送エンジンから現在の転送情報基盤に関する情報を受信し、そのことによって転送情報状態を確立するステップと、前記ＲＴＭは、前記転送情報基盤と前記ルーティング状態とを同期するステップと、も含む。

更なる別の一実施形態では、本発明は、ルータが失敗した場合に、近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータを支援するためのグレースフルリスタート手順を備える、ＩＰに基づくネットワーク内のルータに関する。前記ルータは、前記ネットワーク内の前記近隣のルータにパケットを転送するための転送エンジンと、ルーティングプロトコルプロセスを実行するために、前記転送エンジンに接続された（ｃｏｎｎｅｃｔｅｄｔｏ）第１ルートプロセッサと、ルーティングプロトコルプロセスを実行するために、前記転送エンジンに接続され（ｃｏｎｎｅｃｔｅｄｔｏ）ており、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサと、
前記ネットワークプロトコルスタックへの変更を要求せずに、前記ルーティングプロトコルプロセスを移動する間にパケットの損失を回避するための手段を含む、前記ルーティングプロトコルプロセスを前記第１ルートプロセッサから前記第２ルートプロセッサへ移動する手段と、を含む。

以下では、本発明は、図に示される例示的な実施形態を参照して記載される。本発明は、グレースフルリスタート手順を使用して１つのルートプロセッサ（ＲＰ：ＲｏｕｔｅＰｒｏｃｅｓｓｏｒ）から別のルートプロセッサにルーティングプロトコルプロセスを移動する（ｍｉｇｒａｔｅ）方法およびルータを提供する。前述の複数のＲＰは、同じルータにあってもよいし、別のルータにあってもよい。同様のメカニズムが、仮想ルータ（ＶＲ：ＶｉｒｔｕａｌＲｏｕｔｅｒ）と、それに関する全てのプロセスを１つのＲＰから別のＲＰに移動するために利用される。ＢＧＰ（ＢｏｒｄｅｒＧａｔｅｗａｙＰｒｏｔｏｃｏｌ）、ＯＳＰＦ（ＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔ）、ＩＳ−ＩＳプロトコル（ＩｎｔｅｒｍｅｄｉａｔｅＳｙｓｔｅｍｔｏＩｎｔｅｒｍｅｄｉａｔｅＳｙｓｔｅｍＰｒｏｔｏｃｏｌ）ＲＩＰ（ＲｏｕｔｉｎｇＩｎｆｏｒｍａｔｉｏｎＰｒｏｔｏｃｏｌ）等のルーティングプロトコルは、これらのプロセス間の通信を隠すＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）を使用してルートテーブルマネージャ（ＲＴＭ：ＲｏｕｔｅＴａｂｌｅＭａｎａｇｅｒ）と通信する。このような通信方法では、各プロセスは、どこに通信チャネルの他端が位置しているかを正確に知らない。このことは、ルーティングプロトコルが第１ＲＰに存在し、一方、ＲＴＭが異なるＲＰに存在する、または、逆にルーティングプロトコルおよびＲＴＭが全て同じＲＰに存在することを可能とすることによって、柔軟性を提供する。

図１は、本発明の一実施形態にかかるルータ（ルータＡ）１０の簡略化されたブロック図である。ルータＡは、ルータのコントロールプレーンを格納する（ｈｏｕｓｅ）１以上のルートプロセッサボード（ＲＰボード）１１ａ〜１１ｎを備える。ＲＰは、ルーティングプロトコル１２ａ〜１２ｎ、および、ＲＴＭ１３ａ〜１３ｎを備えてもよい。ルータ内の複数の転送エンジン１４は、ルータのパケット転送機能を実行する。コントロールプレーンは、特定の近隣ルータと通信し、パケット転送を提供する転送エンジンを調整する（ｓｅｔｕｐ）ために、転送エンジン上のインターフェースを使用する。

本稿で記載される実施形態では、ルーティングプロトコル１２およびＲＴＭプロセス１３は、１以上のＲＰボード１１で実行される。１つのＲＰボードのみが存在する場合、全てのプロセスは１つのＲＰで動作する。２以上のＲＰが存在する場合、ルーティングプロトコルおよびＲＴＭは、利用可能な分かれたＲＰで動作してもよい。複数のルーティングプロトコルおよびＲＴＭ間のプロセス間通信（ＩＰＣ：ＩｎｔｅｒＰｒｏｃｅｓｓＣｏｍｍｕｎｉｃａｔｉｏｎ）は、プロセスが動作しているＲＰボードに関わらず、全てのプロセスが互いに通信（ｔａｌｋｔｏ）可能となることを確実にする。同様に、１以上のＶＲは、ＶＲのプロセスの処理要求に依存して、複数のＲＰボードでインスタンス化される（ｉｎｓｔａｎｔｉａｔｅ）。

＜プロセス移動に関するＢＧＰのグレースフルリスタート＞
ＢＧＰは、ルーティングドメインの全域で（across）ルーティング接続を確立するために最初に使用されるパスベクトル型ルーティングプロトコルである。ＢＧＰは、ルータで非常によく使用される重要なプロトコルである。ＢＧＰは、２つの近隣のルータ（ｎｅｉｇｈｂｏｒｒｏｕｔｅｒ）間でＴＣＰソケット接続を確立することによって機能する。全体のＢＧＰ接続は、ＴＣＰ接続が継続して存在するかどうかに依存する。ＴＣＰ接続が失敗すると、必ずＢＧＰセッションは失われ、さらに、転送能力が失われ、このことがネットワーク機能に深刻な損害を与える。

ＢＧＰ要求に関するグレースフルリスタート手順は、ＴＣＰ接続の失敗が、失敗したルータの近隣にある受信ルータへの信号であることを要求する。本手順は、リスタートされたルータによってそうするなと通知されない限り、受信ルータが失敗したルータを転送のために使用し続けることを要求する。この手順は、ルータ上のＢＧＰプロセスのみが停止した場合、ＢＧＰプロセスが自分自身をリスタートする間にトラフィックが転送され続けることを確実とし、このようにして、ネットワークトラフィックが消失されないことを確実とする。

ＢＧＰプロセスの移動では、プロセスが１つのＲＰから別のＲＰに移動する期間に、ＴＣＰ接続が維持され続けていることが必要である。これは、いまだに研究されている非常に複雑な問題であり、この技術の実装の成功は非常に少ない。従来の技術では、ルータの全体のＴＣＰ／ＩＰネットワークスタックが、ＴＣＰ接続の移動を処理するよう改良される必要がある。

図２は、ＢＧＰプロセスをルータＡ１０の第１ルートプロセッサ（ＲＰ−１）１１ａから第２ルートプロセッサ（ＲＰ−２）１１ｂに移動する場合の、本発明の方法の一実施形態のステップを示したフローチャートである。本発明では、ＴＣＰ接続の移動は必須ではない。その代わりに、ＢＧＰプロセスは、ＲＰ−２に移動する準備ができると、ステップ２１でそれ自身を終了する。ステップ２２では、ルータＡの近隣のルータは、ルータＡの失敗を検出する。このことは、近隣のルータがステップ２３でグレースフルリスタート状態に達する原因となる。ステップ２４では、終了したＢＧＰプロセス宛のＴＣＰパケットを検出するために、フィルタールールが転送エンジン１４に追加され、ＲＰ−２上の新しいＢＧＰプロセス行きにそのパケットを方向転換する（ｄｉｖｅｒｔ）。ステップ２５では、ＢＧＰプロセスがＲＰ−２上で起動し、近隣のルータとピア関係（ｐｅｅｒｉｎｇｒｅｌａｔｉｏｎ）を確立する。ステップ２６では、新しいＢＧＰプロセスは、近隣のルータに補助されてネットワークの接続形態トポロジーを学習する。

このように、本発明にかかるＢＧＰプロセスの移動に関するグレースフルリスタートを使用すると、ＴＣＰ／ＩＰネットワークスタックの複雑な操作をする必要がなくなる。本発明は、さらに、あらゆるストックされた、既に溜められているネットワークスタックで利用されてもよい。したがって、本発明は、ＢＧＰプロセスに関するプロセスの移動の実装の複雑さを、劇的に減少させる。これは、販売者の開発費用および消費者の購入費用を減少させる。

＜ＢＧＰ以外のプロトコルの移動＞

ＯＳＰＦ、ＩＳ−ＩＳ、およびＲＩＰ等のプロトコルは、ＴＣＰでは動作せず、したがって、ＲＰ上で動作するオペレーティングシステムの内部で保持されるセッション状態は存在しない。しかし、プロトコルプロセスはプロトコル状態を保持しないので、プロトコルプロセスが新しいＲＰ上で再開しされると、この状態は再度学習される必要がある。ＯＳＰＦおよびＩＳ−ＩＳプロトコルは、定義されたグレースフルリスタート手順を有するが、ＲＩＰはそうではない。

図３は、ＯＳＰＦまたはＩＳ−ＩＳプロセスを第１のＲＰ−１から第２のＲＰ−２に移動するときの、本発明の一実施形態にかかる方法のステップを示したフローチャートである。プロトコルプロセスがＲＰ−２に移動する準備ができると、ステップ３１で、プロトコルプロセスは、ＲＰ−１上で終了する。ステップ３２で、古いＯＳＰＦ／ＩＳ−ＩＳプロセス宛のプロトコルパケットを検出するために、および、そのパケットをＲＰ−２上の新しいＯＳＰＦ／ＩＳ−ＩＳプロセスに方向転換するために、フィルタールールが転送エンジンに追加される。その後、ステップ３３で、そのプロトコルプロセスはＲＰ−２上でリスタートされる。プロセスがＯＳＰＦプロセスであった場合、ステップ３４に続き、リスタートされたＯＳＰＦは、近隣のルータからのグレースフルリスタート支援を要求する不透明な（ｏｐａｑｕｅ）リンク状態通知（ＬＳＡ：ＬｉｎｋＳｔａｔｅＡｄｖｅｒｔｉｓｅｍｅｎｔ）を送信する。プロセスがＩＳ−ＩＳプロセスであった場合、ステップ３４ではなくステップ３５に続き、リスタートされたＩＳ−ＩＳは、リスタート要求（ＲＲ：ＲｅｓｔａｒｔＲｅｑｕｅｓｔ）フラグセットと共に、ＩＳ−ＩＳのハローメッセージ内で、リスタートのタイプ、長さ、および値（ＴＬＶ：ＴｙｐｅＬｅｎｇｔｈａｎｄＶａｌｕｅ）フィールドを、送信する。このように、近隣のルータにプロセスがリスタートすることを示す。ステップ３６で、新しいＯＳＰＦ／ＩＳ−ＩＳプロセスは、近隣のルータに補助されてネットワークトポロジーを学習する。このように、全てのルーティング近接（ａｄｊａｃｅｎｃｙ）は、グレースフルリスタート手順を使用してトラフィックの転送に影響を与えることなく行われる。

図４は、ＲＩＰプロセスを第１のＲＰ−１から第２のＲＰ−２に移動するときの、本発明の一実施形態にかかる方法のステップを示したフローチャートである。ＲＩＰプロトコルは、定義されたグレースフルリスタート手順を有さない。しかし、ＲＩＰは、別の距離ベクトル型（ｄｉｓｔａｎｃｅ−ｖｅｃｔｏｒ）のプロトコルであり、ＲＩＰは、ルーティングドメイン上の全ての経路を周期的にリフレッシュする。新しいＲＰ上でのＲＩＰプロセスのリスタートは、単に、プロトコル状態の通知の前にプロトコル状態を再度学習するために十分な時間待つだけである。それは、パケット転送に影響を与えることなくプロセスの移動を達成する。

このように、プロトコルプロセスがＲＰ−２に移動する準備ができると、ステップ４１で、プロトコルプロセスは、ＲＰ−１上で終了する。ステップ４２で、古いＲＩＰプロセス宛のプロトコルパケットを検出するために、および、そのパケットをＲＰ−２上の新しいＲＩＰプロセスに方向転換するために、フィルタールールが転送エンジンに追加される。その後、ステップ４３で、ＲＩＰプロセスはＲＰ−２上でリスタートされる。ステップ４４で、新しいＲＩＰプロセスは、ルーティングドメイン上の全ての経路の周期的なリフレッシュを受信する。ステップ４５で新しいＲＩＰプロセスは、ＲＩＰプロセスがそのプロトコル状態を再度学習した後に、近隣のルータに通知を送る。

＜ＶＲのプロトコルの移動＞
図５は、仮想ルータ（ＶＲ：ＶｉｒｔｕａｌＲｏｕｔｅｒ）を第１のＲＰ−１から第２のＲＰ−２に移動するときの、本発明の一実施形態にかかる方法のステップを示したフローチャートである。ＶＲは、一般にルーティングおよびシグナリングプロトコルプロセスと、転送エンジンで使用される転送情報基盤（ｆｏｒｗａｒｄｉｎｇｉｎｆｏｒｍａｔｉｏｎｂａｓｅ）を算出するＲＴＭとから構成される。ＶＲを移動するためには、全てのこれらのプロセスが新しいＲＰ上に移動される必要がある。ＶＲのルーティングおよびシグナリングプロトコルは、前述されたように、終了されて新しいＲＰ上でリスタートされる。ＲＴＭの移動は、新しいＲＰ上でＲＴＭをリスタートすることと、ＲＴＭがルーティングプロトコルからルーティング状態を再度学習することを可能とすることと、を含む。ＲＴＭは現在の転送情報基盤を転送エンジンから学習し、２つの状態を同期する。

このように、ＶＲがＲＰ−２に移動する準備ができると、ステップ５１で、ＶＲのルーティングおよびシグナリングプロトコルプロセスはＲＰ−１上で終了する。ルーティングおよびシグナリングプロトコルプロセスが定義されたグレースフルリスタート手順を有すると仮定すると、ステップ５２でルータＡの近隣のルータはルータＡの失敗を検知し、ステップ５３でグレースフルリスタートに達する。ステップ５４で、ＶＲの終了されたルーティングおよびシグナリングプロトコルプロセス宛のＴＣＰパケットを検出するために、および、そのパケットをＲＰ−２上の新しいルーティングおよびシグナリングプロトコルプロセスに方向転換するために、フィルタールールが転送エンジン１４に追加される。ステップ５５で、ＲＴＭは、ＲＰ−２上でリスタートされる。ステップ５６で、ルーティングおよびシグナリングプロトコルプロセスは、ＲＰ−２上でリスタートし、近隣のルータとピア関係を確立する。ステップ５７で、新しいルーティングおよびシグナリングプロトコルプロセスは、近隣のルータに補助されてネットワークトポロジーを学習する。ステップ５８で、ＲＴＭは、ルーティングおよびシグナリングプロトコルプロセスからルーティング状態を学習する。ステップ５９で、ＲＴＭは、現在の転送情報基盤を転送エンジンから学習し、転送情報の状態をルーティング状態と同期する。

本発明の属する技術の分野における通常の知識を有する者によって認識されるように、本特許出願で記載された革新的な概念は、本出願の広い範囲にわたって修正および変更されうる。したがって、特許権が主張される題材の範囲は、前述された特定の例の開示に限定されるものではなく、特許請求の範囲で定義されるものである。

本発明の一実施形態にかかるルータの簡略化されたブロック図である。ＢＧＰプロセスを第１ルートプロセッサから別のルートプロセッサに移動する場合の、本発明の方法の一実施形態のステップを示したフローチャートである。ＯＳＰＦまたはＩＳ−ＩＳプロセスを第１ルートプロセッサから別のルートプロセッサに移動する場合の、本発明の方法の一実施形態のステップを示したフローチャートである。ＲＩＰプロセスを第１ルートプロセッサから別のルートプロセッサに移動する場合の、本発明の方法の一実施形態のステップを示したフローチャートである。仮想ルータ（ＶＲ）を第１ルートプロセッサから別のルートプロセッサに移動する場合の、本発明の方法の一実施形態のステップを示したフローチャートである。

Claims

インターネットプロトコル（ＩＰ）に基づくネットワーク内のルータで、第１ルートプロセッサから、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサにルーティングプロトコルプロセスを移動する方法であって、
前記ルータは、前記ネットワーク内の近隣のルータにパケットを転送するための転送エンジンを備え、
前記近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータが失敗した場合に前記ルータを支援するためのグレースフルリスタート手順を備え、
前記方法は、
前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了し、そのことによって前記近隣のルータに前記ルータが失敗したことを示し、前記近隣のルータが前記グレースフルリスタート手順を開始する原因となるステップと、
前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートするステップと、
前記転送エンジンによって、前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットが、前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換されるステップと、
前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスが、前記近隣のルータから前記ネットワークトポロジーに関する情報を受信するステップと、
より構成される方法。
前記第１ルートプロセッサおよび前記第２ルートプロセッサは、１つのルータ内にある、請求項１に記載の方法。
前記第１ルートプロセッサおよび前記第２ルートプロセッサは、異なるルータ内にある、請求項１に記載の方法。
前記方法は、ルータの拡張性を増大するために、複数のルートプロセッサ間で共有される処理のロードが再分配される（redistributed）必要があることを決定するステップより先行する、請求項１に記載の方法。
前記転送エンジンによってパケットが方向転換されるステップは、前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了した後に前記転送エンジンにフィルタールールを追加し、前記フィルタールールは、前記転送エンジンが前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットを前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換する原因となるステップを含む、請求項１に記載の方法。
前記第２ルートプロセッサ上で前記ルーティングプロトコルプロセスをリスタートするステップは、前記近隣のルータとピア関係を確立することを含む、請求項１に記載の方法。
前記ルーティングプロトコルプロセスは、ＢＧＰプロセスである、請求項１に記載の方法。
インターネットプロトコル（ＩＰ）に基づくネットワーク内のルータで、第１ルートプロセッサから、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサにルーティングプロトコルプロセスを移動する方法であって、
前記ルータは、前記ネットワーク内の近隣のルータにパケットを転送するための転送エンジンを備え、
前記近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータが失敗した場合に前記ルータを支援するためのグレースフルリスタート手順を備え、
前記方法は、
前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了するステップと、
前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了した後に前記転送エンジンにフィルタールールを追加し、前記フィルタールールは、前記転送エンジンが前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットを前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換する原因となるステップと、
前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートするステップと、
前記近隣のルータがグレースフルリスタート手順を開始することを要求するメッセージを、それぞれの前記近隣のルータに送信するステップと、
前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスが、前記近隣のルータから前記ネットワークトポロジーに関する情報を受信するステップと、
より構成される方法。
前記ルーティングプロトコルプロセスは、ＯＳＰＦプロセスであり、前記それぞれの前記近隣のルータにメッセージを送信するステップは、不透明なリンク状態通知を前記それぞれの前記近隣のルータに送信することを含む、請求項８に記載の方法。
前記ルーティングプロトコルプロセスは、ＯＳＰＦプロセスであり、前記それぞれの前記近隣のルータにメッセージを送信するステップは、前記第１ルートプロセッサで前記プロセスを終了する前に前記メッセージを前記近隣のルータに送信することを含む、請求項８に記載の方法。
前記ルーティングプロトコルプロセスは、ＩＳ−ＩＳプロセスであり、前記それぞれの前記近隣のルータにメッセージを送信するステップは、前記ルータがリスタートすることを示すＴＬＶフィールドを有するメッセージを、前記それぞれの前記近隣のルータに送信することを含む、請求項８に記載の方法。
インターネットプロトコル（ＩＰ）に基づくネットワーク内のルータで、第１ルートプロセッサから、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサにルーティングプロトコルプロセスを移動する方法であって、
前記ルータは、前記ネットワーク内の近隣のルータにパケットを転送するための転送エンジンを備え、
前記ルーティングプロトコルプロセスは、定義されたグレースフルリスタート手順を有さず、
前記方法は、
前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了するステップと、
前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了した後に前記転送エンジンにフィルタールールを追加し、前記フィルタールールは、前記転送エンジンが前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットを前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換する原因となるステップと、
前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートするステップと、
それぞれの前記近隣のルータから、プロトコル状態に関する周期的なリフレッシュメッセージを受信し、前記リフレッシュメッセージは前記ネットワークのルーティングドメイン内の全てのルータに対応する情報を含むステップと、
前記ルータが操作可能であることを通知するメッセージを、それぞれの前記近隣のルータに送信するステップと、
より構成される方法。
前記ルーティングプロトコルプロセスは、ＲＩＰプロセスである、請求項１２に記載の方法。
インターネットプロトコル（ＩＰ）に基づくネットワーク内のルータで、第１ルートプロセッサから、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサに仮想ルータ（ＶＲ）を移動する方法であって、
前記ルータは、前記ネットワーク内の近隣のルータにパケットを転送するための転送エンジンを備え、
前記ＶＲは、ルーティングおよびシグナリングプロトコルプロセスと、前記転送エンジンで使用される転送情報基盤を算出するルートテーブルマネージャ（ＲＴＭ）とを含み、
前記近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータが失敗した場合に前記ルータを支援するためのグレースフルリスタート手順を備え、
前記方法は、
前記第１ルートプロセッサで前記ＶＲのルーティングおよびシグナリングプロトコルプロセスを終了し、そのことによって前記近隣のルータに前記ルータが失敗したことを示し、前記近隣のルータが前記グレースフルリスタート手順を開始する原因となるステップと、
前記第２ルートプロセッサで前記ＶＲのルーティングおよびシグナリングプロトコルプロセスをリスタートするステップと、
前記転送エンジンによって、前記第１ルートプロセッサ上の前記ＶＲのルーティングおよびシグナリングプロトコルプロセス宛のパケットが、前記第２ルートプロセッサ上でリスタートされた前記ＶＲのルーティングおよびシグナリングプロトコルプロセスに方向転換されるステップと、
前記第２ルートプロセッサ上でリスタートされた前記ＶＲのルーティングおよびシグナリングプロトコルプロセスが、前記近隣のルータから前記ネットワークトポロジーに関する情報を受信するステップと、
前記第２ルートプロセッサ上で前記ＶＲのＲＴＭをリスタートするステップと、
前記リスタートされたＶＲのＲＴＭは、前記リスタートされたＶＲのルーティングおよびシグナリングプロトコルプロセスから前記ネットワークトポロジーに関する情報を受信し、そのことによってルーティング状態を確立するステップと、
前記リスタートされたＶＲのＲＴＭは、前記転送エンジンから現在の転送情報基盤に関する情報を受信し、そのことによって転送情報状態を確立するステップと、
前記ＲＴＭは、前記転送情報基盤と前記ルーティング状態とを同期するステップと、
より構成される方法。
前記第１ルートプロセッサおよび前記第２ルートプロセッサは、１つのルータ内にある、請求項１４に記載の方法。
前記第１ルートプロセッサおよび前記第２ルートプロセッサは、異なるルータ内にある、請求項１４に記載の方法。
前記転送エンジンによってパケットが方向転換されるステップは、前記第１ルートプロセッサで前記ＶＲのルーティングおよびシグナリングプロトコルプロセスを終了した後に前記転送エンジンにフィルタールールを追加し、前記フィルタールールは、前記転送エンジンが前記第１ルートプロセッサ上の前記ＶＲのルーティングおよびシグナリングプロトコルプロセス宛のパケットを前記第２ルートプロセッサ上でリスタートされた前記ＶＲのルーティングおよびシグナリングプロトコルプロセスに方向転換する原因となるステップを含む、請求項１４に記載の方法。
前記第２ルートプロセッサ上で前記ルーティングプロトコルプロセスをリスタートするステップは、前記近隣のルータとピア関係を確立することを含む、
請求項１４に記載の方法。
ルータが失敗した場合に、近隣のルータは、前記ルータへのパケットの流れを維持し、前記ルータを支援するためのグレースフルリスタート手順を備える、インターネットプロトコル（ＩＰ）に基づくネットワーク内のルータであって、
前記ルータは、
前記ネットワーク内の前記近隣のルータにパケットを転送するための転送エンジンと、
ルーティングプロトコルプロセスを実行するために、前記転送エンジンに接続された第１ルートプロセッサと、
ルーティングプロトコルプロセスを実行するために、前記転送エンジンに接続されており、前記第１ルートプロセッサとは独立して操作する第２ルートプロセッサと、
前記ネットワークプロトコルスタックへの変更を要求せずに、前記ルーティングプロトコルプロセスを移動する間にパケットの損失を回避するための手段を含む、前記ルーティングプロトコルプロセスを前記第１ルートプロセッサから前記第２ルートプロセッサへ移動する手段と、
より構成される、ルータ。
前記ルーティングプロトコルプロセスを移動する間にパケットの損失を回避するための手段は、前記ルーティングプロトコルプロセスが移動される間に前記ルーティングプロトコルプロセスが前記ルータ宛のパケットの流れを維持する、定義されたグレースフルリスタート手順を開始する手段を含む、請求項１９に記載の方法。
前記グレースフルリスタート手順を開始する手段は、前記第１ルートプロセッサで前記ルーティングプロトコルプロセスを終了し、そのことによって前記近隣のルータに前記ルータが失敗したことを示し、前記近隣のルータが前記グレースフルリスタート手順を開始する原因となる手段を含む、請求項２０に記載の方法。
前記ルーティングプロトコルプロセスを移動する手段は、前記第２ルートプロセッサで前記ルーティングプロトコルプロセスをリスタートすることを含む、請求項２１に記載の方法。
前記ルーティングプロトコルプロセスを移動する間にパケットの損失を回避するための手段は、前記ルーティングプロトコルプロセスを移動する間に前記転送エンジンにフィルタールールを追加するための手段を含み、前記フィルタールールは、前記転送エンジンが前記第１ルートプロセッサ上の前記ルーティングプロトコルプロセス宛のパケットを前記第２ルートプロセッサ上でリスタートされた前記ルーティングプロトコルプロセスに方向転換する原因となる、請求項２２に記載の方法。