(57)【特許請求の範囲】
【請求項１】
リンク障害がネットワーク内で起こるときに、データパケットについて再経路指定動作を実施する方法にして、
（ａ）ヘッドエンドＨＥノード（２０）とテールエンドＴＥノード（２３）との間でデータパケットを経路指定するステップと、
（ｂ）データパケットがテールエンドノード（２３）に達する前に、ヘッドエンドノード（２０）とテールエンドノード（２３）との間でリンク障害（２７）を検出するステップと、
（ｃ）ヘッドエンドノード（２０）とテールエンドノード（２３）との間のローカル修復点ＰＬＲノード（２２）においてデータパケットを受信するステップと、
（ｄ）ＰＬＲノード（２２）のバイパストンネル（２８）を通してヘッドエンドノード（２０）にデータパケットを戻しそしてテールエンドノード（２３）上に再経路指定するステップとを含む方法であって、さらに
（ｅ）ヘッドエンドノード（２０）が、ローカルバイパストンネル（２９）を使用して、将来のデータパケットをテールエンドノードに搬送することを可能にするエラーメッセージを、ＰＬＲノード（２２）からヘッドエンドノード（２０）へ伝送するステップと、
バイパストンネル（２８）の使用を停止するメッセージを、ヘッドエンドノード（２０）からＰＬＲノード（２２）へ送信するステップを含み、
バイパストンネル（２８）の使用を停止するヘッドエンドノード（２０）からＰＬＲノード（２２）への前記メッセージが、バイパストンネルをリフレッシュすることを停止し、エラーメッセージを送信することを停止するコマンドをさらに含むことを特徴とする、方法。
【請求項２】
ヘッドエンドノード（２０）がＰＬＲノード（２２）からエラーメッセージを受信するとタイマを始動させ、タイマが終了するまで、ローカルバイパストンネル（２９）を使用するステップをさらに含み、終了時点で、ヘッドエンドノード（２０）からテールエンドノード（２３）への経路指定が、元の経路に復帰する、請求項１に記載の方法。
【請求項３】
ステップが、複数テナントユニットによって実施される、請求項１に記載の方法。
【請求項４】
ステップが、ルータによって実施される、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で行われる開示は、一般に、マルチプロトコルラベルスイッチング（ｍｕｌｔｉ  Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）（ＭＰＬＳ）産業に関する。本明細書で説明される発明は、強化された資源予約プロトコル−トラフィックエンジニアリング（ｅｎｈａｎｃｅｄ  Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ−Ｔｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇ）（ＲＳＶＰ−ＴＥ）の一般的な分類内にある。
【背景技術】
【０００２】
コンピュータネットワークは、ネットワークノード間でデータを伝送する相互接続されたサブネットワークの集合体である。ネットワークノードは、ネットワーク内でデータを送受信することが可能な任意のデバイスである。
【０００３】
インターネットプロトコル（ＩＰ）は、ネットワークを通してデータが移動するときの全てのデータの正確なフォーマットを指定し、経路指定機能を実施し、データがその上で送信されることになる伝送経路を選択する。代表的な経路指定は、経路が輻輳しているときでも、ネットワーク内の最短経路をとる。ルータは、経路指定テーブル内のポートおよびアドレスを利用して、ネットワークを通してノードからノードへデータパケットまたはセルを送信する。
【０００４】
マルチプロトコルラベルスイッチング（ＭＰＬＳ）は、ラベルスイッチングを使用して、データパケットまたはセルを転送する汎用トンネリングメカニズムである。ＭＰＬＳは、ＩＰと違って、２つのノード間で送信されるパケットが、異なるＭＰＬＳラベルに基づいて異なる経路をとることを可能にする。ＭＰＬＳは、ラベル交換経路（ｌａｂｅｌ−ｓｗｉｔｃｈｅｄ  ｐａｔｈ）（ＬＳＰ）を利用して、いくつかの経路を通じてトラフィックを操向する。サービスプロバイダは、資源保存プロトコル−トラフィックエンジニアリング（ＲＳＶＰ−ＴＥ）を使用することによって、明示的な経路を指定しうる。
【０００５】
ＭＰＬＳは、トリプルプレイおよびモビリティ（Ｔｒｉｐｌｅ  Ｐｌａｙ  ａｎｄ  Ｍｏｂｉｌｉｔｙ）のようなサービスをサポートするアクセスリングネットワークにおいてより経済的になるため、ネットワーク障害の場合にトラフィック再経路指定を処理する帯域幅効率的な手段が、より重要になることになる。保護されたＬＳＰ上での高速再経路指定（Ｆａｓｔ  Ｒｅｒｏｕｔｅ）（ＦＲＲ）の現在のＲＳＶＰ−ＴＥ実施態様は、こうしたリングトポロジーにおいて非常に帯域幅非効率的である。
【０００６】
ＭＰＬＳネットワークでは、ローカル障害によって、保護されたＬＳＰをノードがＦＲＲするようにトリガーされると、ノードローカル修復点（ｐｏｉｎｔ  ｏｆ  ｌｏｃａｌ  ｒｅｐａｉｒ）（ＰＬＲ）は、保護されたＬＳＰのテールエンド（ｔａｉｌｅｎｄ）（ＴＥ）ノードに達するように、ヘッドエンド（ｈｅａｄｅｎｄ）（ＨＥ）ノードから受信されるトラフィックを、バイパストンネル内に送信することになる。リングトポロジーでは、このバイパストンネルは、ＬＳＰのＨＥノードに戻る全経路を通過し、次に、元の保護されたＬＳＰ経路の反対方向からＴＥノードに達することになる。これによって、トラフィックは、ＰＬＲノードに流れ、次に、バイパストンネルで戻り、それにより、リング内に不必要な輻輳が生じ、リングの帯域幅効率が減少する。
【０００７】
トラフィックを保護する最も効率的な方法が、障害点にできる限り近い経路を修復し、できる限り早期に元の経路に戻るようにその経路をマージすることであると仮定して、ＦＲＲが、ネットワーク障害に対する収束時間を低減するように現在のところデザインされているため、ＦＲＲの現在の実施態様は、トラフィックが、元のＬＳＰ内でＨＥノードからＰＬＲノードへ移動し、次に、バイパストンネルで反対方向に戻るように移動するようにさせる。この解決策は、ほとんどの場合、まずまず有効であるが、リングトポロジーの場合、帯域幅効率的でない。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
リンク障害が発生するときにネットワークにおいてトラフィックを再経路指定するための、設置するのが好都合で、信頼性があり、安価で、帯域幅効率的な方法についての必要性が当技術分野で存在する。
【課題を解決するための手段】
【０００９】
ＭＰＬＳ−ＦＲＲ帯域幅最適化のためのＲＳＶＰ−ＴＥ強化は、バイパスＬＳＰトンネルが、保護されたＬＳＰの元の直前のホップ（複数可）を通過するトポロジーにおいて、ＦＲＲがＬＳＰトラフィックを保護するときに、ネットワーク資源を最適化するためのＲＳＶＰ−ＴＥプロトコル強化方法である。基本的な考えは、ＦＲＲ保護を提供するノード、ＰＬＲが、バイパストンネル内で元の経路に向かってトラフィックを返送することになるトポロジーにおいて、強化されたメッセージＴＬＶを使用して、ＨＥノードに戻る全経路のノードに報告することになるようにＲＳＶＰ−ＴＥプロトコルを強化することである。ＰＬＲノードに先立つ元の経路上のノード（複数可）は、ネットワーク資源最適化の観点から、（リング内のトラフィックを減少させるために、リングトポロジー内でＨＥノードからのバイパストンネルを使用することなど）ＦＲＲを提供するために使用すべきよりよい代替のバイパストンネルが存在するかどうかをチェックしうる。
【００１０】
本発明は、強化されたメッセージのタイプ、長さ、値（Ｔｙｐｅ  Ｌｅｎｇｔｈ  Ｖａｌｕｅ）（ＴＬＶ）の使用によって帯域幅非効率性を解決する。本発明は、Ａｌｃａｔｅｌ社製７４５０ＥＳＳ、７７５０ＳＲ、および７２５０ＳＡＳのような、アクセスおよび分配スイッチ、ルータ、ならびに複数テナントユニット（Ｍｕｌｔｉｐｌｅ  Ｔｅｎａｎｔ  Ｕｎｉｔｓ）（ＭＴＵ）、競合するシステムに対する利点を与えることになる。本発明はまた、ＨＥノードがリングの一部でない部分的なリングトポロジーシナリオをサポートする。
【００１１】
本発明の方法はまた、この機能を持たないネットワーク要素と共に動作するようにデザインされる。このプロトコル強化を持たない古いシステムは、新しく付加されるＴＬＶメッセージを理解しないことになる。オプションでかつトランジティブであるプロトコル拡張版が提案されているため、影響は副次的であるべきである。メッセージを理解しないノードは、メッセージを単に通過させることになり、メッセージから要求される振舞いの変更は存在しない。
【００１２】
この解決策は、バイパストンネルが、ＬＳＰのＨＥノードに対して後方に移動してもよい任意のネットワークトポロジーに適する。最も一般的なネットワークトポロジーの１つは、リングトポロジーであり、この新しい解決策が最も利益を与えることになる。リングは、電気通信ネットワークに関する残りの一歩の解決策のために広く使用されている。リング内の全てのユーザが帯域幅を共有することになるため、この解決策は、帯域幅効率およびネットワーク全体の性能を大幅に改善することになる。
【００１３】
本発明の好ましい実施形態は、ネットワーク上でトラフィックを再経路指定する方法であって、強化されたメッセージＴＬＶの使用によって、リンク障害が起こるときにＨＥノードとＴＥノードとの間の経路を短縮する、方法を利用する。
【００１４】
本発明の主要な目的は、ネットワーク上でトラフィックを再経路指定する方法であって、ＨＥノードが、そのバイパストンネルを使用していることをＰＬＲノードに信号を送ることを可能にし、それにより、ＰＬＲノードが、予期しない振舞いを生じる可能性があるその保護されたＬＳＰをリフレッシュすることを停止するようにさせる、方法を提供することである。
【００１５】
本発明の別の目的は、ＰＬＲノードが、バイパストンネル経路をチェックすることであり、ＰＬＲノードは、トラフィックがＨＥノードに迂回して戻されるとわかると、ＨＥノードがより効率的なバイパストンネルを使用すべきであることをＨＥノードに通知し、こうした通知を受信することによって、ＨＥノードは、ローカルにトラフィックを迂回させ、保護された経路をもはやリフレッシュしないようにＰＬＲに信号を送ることになる。
【００１６】
本発明の別の目的は、ＰＬＲのバイパストンネルを通る再経路指定されたトラフィックが、その送り先に達することを可能にする方法を提供することである。
【００１７】
本発明の別の目的は、ＨＥノードとＴＥノードとの間を移動する後続のデータが、代替の経路を介してＴＥノード上に移動する前に、ＰＬＲへ移動し、次に、ＨＥへ戻る不必要な経路を移動するのではなく、代替の経路をとることを可能にすることによって帯域幅効率を高める方法を提供することである。
【００１８】
本発明の別の目的は、リンク障害中にＨＥノードからＴＥノードへネットワーク上でトラフィックを伝送する方法であって、設置および維持が比較的安価である、方法を提供することである。
【００１９】
本発明の別の目的は、ネットワークにおいて、リンク障害中にＨＥノードからＴＥノードへネットワーク上でトラフィックを伝送する信頼性がある方法を提供することである。
【００２０】
本発明のなお別の目的は、この新しい技術をサポートしないノードが、振舞いを変更することなく、新しいＴＬＶメッセージを通過させるように、トランスペアレントとなる方法を提供することである。
【図面の簡単な説明】
【００２１】
【図１】リング内のＦＲＲの従来の振舞いを示す図である。
【図２】本発明の好ましい方法を利用した、リング内のＦＲＲの強化された振舞いを示す図である。
【発明を実施するための形態】
【００２２】
図１は、リング内のＦＲＲの従来の振舞いを示す図を示す。第１ノード１０は、ＨＥノードの役をする。時計方向に進むと、第２ノード１１、第３ノード１２、第４ノード１３（この例では、ＴＥノードとも呼ばれる）、第５ノード１４、および第６ノード１５が、リング形態で配列される。
【００２３】
第１ノード１０から第４ノード１３へ送信されるデータパケットは、通常、予め規定された経路１６をたどり、第１ノード１０から第２ノード１１へ、第３ノード１２へ、そして最後に最終送り先−第４ノード１３へ進む。しかし、この例では、リンク障害１７（ボールド体Ｘで示す）が、第３ノード１２から第４ノード１３へのデータパケットの伝送中に起こる。結果として、第３ノード１２は、第４ノード１３に向かって移動するデータパケットを成功裏に受信する最後のノードであるため、ローカル修復点（ＰＬＲ）ノードになる。
【００２４】
第３ノード１２は、その後、そのバイパストンネルによってＦＲＲ保護を実施する。データパケットは、この例では反時計方向にバイパストンネル内を移動し、第６ノード１５および第５ノード１４内を移動し、最後に、第４ノード１３のその元の送り先に移動する前に、第２ノード１１を通過し、第１ノード１０に戻る。
【００２５】
第１ノード１０は、第１ノード１０から第６ノード１５へ、第５ノード１４へ、第４ノード１３へのより短いバイパストンネル１９を有しているが、ネットワーク障害が第１ノード１０のローカルリンク内にないため、後続のトラフィックは、このバイパストンネル１９を直接使用しないことになる。代わりに、トラフィックは、本明細書で述べる長い経路１８を移動し続けることになる。
【００２６】
図２は、本発明の好ましい方法を利用するリング内のＦＲＲの強化された振舞いを示す図を示す。第１ノード２０は、ＨＥノードの役をする。時計方向に進むと、第２ノード２１、第３ノード２２、第４ノード２３（この例では、ＴＥノードとも呼ばれる）、第５ノード２４、および第６ノード２５が、リング形態で配列される。
【００２７】
第１ノード２０から第４ノード２３へ送信されるデータパケットは、通常、予め規定された経路２６をたどり、第１ノード２０から第２ノード２１へ、第３ノード２２へ、そして最後に最終送り先−第４ノード２３へ進む。しかし、この例では、リンク障害２７（ボールド体Ｘで示す）が、第３ノード２２から第４ノード２３へのデータパケットの伝送中に起こる。結果として、第３ノード２２は、第４ノード２３へ移動するデータパケットを成功裏に受信する最後のノードであるため、ローカル修復点（ＰＬＲ）ノードになる。
【００２８】
第３ノード２２は、その後、そのバイパストンネルによってＦＲＲ保護を実施する。データパケットは、この例では反時計方向にバイパストンネル内を移動し、第６ノード２５および第５ノード２４内を移動し、最後に、第４ノード２３のその元の送り先に移動する前に、第２ノード２１を通過し、第１ノード２０に戻る。
【００２９】
図２の方法および図と図１の方法および図との主要な差は、後続のデータパケットが、元のデータパケットと同じ経路をとる必要を可能にし、帯域幅効率を高めるノードから送信される付加的なＴＬＶメッセージにある。ＴＬＶメッセージは、第１ノード２０から第４ノード２３へ送信される後続のデータパケットが、最後に、第６ノード２５、第５ノード２４、次に、第４ノード２３に移動する前に、第２ノード２１を通って第３ノード２２へ、その後、進んで来た同じ経路を戻るように通過する長いルート２８を移動しなければならないのではなく、第６ノード２５および第５ノード２４を通って直接より短いバイパストンネル２９を実施することを防ぐ。
【００３０】
この解決策の最も重要な利点は、帯域幅の節約である。従来のＦＲＲシナリオでは、リンク障害中、第１ノード１０から第４ノード１３へのＬＳＰからのトラフィックは、トラフィックが第３ノード１２に移動し、次に、戻るため、第１ノード１０と第２ノード１１との間、および、第２ノード１１と第３ノード１２との間で２倍になることになる。
【００３１】
この新しい解決策によって、リンク保護中に、第１ノード２０が、トラフィックを搬送するために、第１ノード２０から第６ノード２５へ、第５ノード２４へ、そして第４ノード２３へのローカルバイパストンネル２９を使用することになるため、第１ノード２０から第４ノード２３への保護されたＬＳＰによって帯域幅は消費されないことになる。第１ノード２０、第２ノード２１、および第３ノード２２のトラフィックは、リンク障害によって影響を全く受けない。
【００３２】
提案される強化されたＲＳＶＰ−ＴＥプロトコルは、ＰａｔｈＥｒｒ（ローカル修復の通知）メッセージ、ＲＥＳＶ（リフレッシュ送信の停止）メッセージ、およびＲｅｓｖＥｒｒ（迂回路の放棄）メッセージ内にいくつかの新しいＴＬＶを有することになる。保護されたＬＳＰのＨＥノードは、ＰａｔｈＥｒｒ  ＴＬＶを受信すると、リングの反対方向にトラフィックを送信するためにそのローカルバイパストンネルを使用するように切換える。ＨＥノードは、これ以降、保護されたＬＳＰのトラフィックをＴＥノードへ送信するためにそのバイパストンネルを使用することになる。ＨＥノードはまた、よりよいバイパスが発見され、迂回路が放棄されることを指示するＲｅｓｖＥｒｒメッセージ内に別の新しいＴＬＶを送信することによって、元のＰＬＲに通知し、元のＰＬＲは、トンネルを通してＬＳＰをリフレッシュすることを停止し、ＰａｔｈＥｒｒメッセージをＨＥノードに送信することを停止することになる。
【００３３】
ＨＥノードとＰＬＲノードとの間の相互作用がない場合、ＨＥノードが新しいバイパストンネルに切換わっても、ＰＬＲノードは、保護されたＬＳＰをリフレッシュし続けることになる。この振舞いは、ＨＥノードに予期せぬ振舞いをさせることになり、サービス要求停止をもたらす可能性がある。提案される明示的なシグナリング解決策は、ＨＥノードとＰＬＲノードが共に、新しい振舞いを知っているため、この問題を解決することになる。この機能をサポートしないノードの場合、振舞いの変更が全くない状態で、メッセージが透過的に通過する。
【００３４】
いくつかの実施形態では、後続のデータが、ＨＥノードからＴＥノードへの元の経路に戻ることを可能にするメカニズムが利用されうる。たとえば、タイマは、ＨＥノードが、ＰＬＲノードからのエラーメッセージを受信すると始動しうる。ＨＥノードからＴＥノードへの後続のデータは、タイマが終了するまで、ローカルバイパストンネルを使用することになり、終了時点で、ＨＥノードからＴＥノードへの経路指定が、元のプロトコルに復帰する。リンク障害が、ＰＬＲとＴＥとの間で修正された場合、トラフィックは、元の経路によってＴＥノードまで進むことになる。しかし、リンク障害が、タイマが終了した後に修正されなかった場合、データは、再び、再経路指定され、タイマは、再び始動することになる。
【００３５】
本明細書で述べる方法は、コンピュータ上で実行されるプログラム命令を有するコンピュータ読み取り可能媒体を含むソフトウェア、ハードウェア、ファームウェア、またはその組合せとして実施されうることが考えられる。本明細書で述べる方法はまた、ハードウェアおよび／またはソフトウェアに関する種々の組合せで実施されてもよい。
【００３６】
本発明の幅広い発明の概念から逸脱することなく、上述した実施形態に対して変更または修正が行われてもよいことが当業者に認識されるであろう。したがって、本発明は、本明細書に述べる特定の実施形態に限定されるのではなく、特許請求の範囲に記載される本発明の範囲および精神内にある全ての変更および修正を含むことを意図されることが理解されるべきである。
【図１】
0005420547.tif 000002
【図２】
0005420547.tif 000003