エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法
ａ． 故障が発生するラベルスイッチパスＬＳＰがあるかどうかを検知・判断し、なければ、ステップａに戻り、あれば、ステップｂを実行する。ｂ． 現在の故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、バックアップＬＳＰがあれば、エッジルータ又は転送ルータは一定のポリシーにより、現在の故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのバックアップＬＳＰ上に切換え、バックアップＬＳＰがなければ、リソース制御機能エンティティは現在のトポロジーにより、現在故障ＬＳＰ上のサービスフローに新しいＬＳＰを配置して、故障ＬＳＰ上のサービスフローを新しく配置されたＬＳＰ上に切換え、サービスフローを切換える前に占用されたパスリソースを解放する。当該方法はベアラネットワークにおいて、サービスの連続性及びネットワークＱｏＳの信頼性を保証できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス品質を保障する技術に関し、特にラベルスイッチパス（ＬＳＰ）のホットスイッチを利用してベアラネットワークにおいてエンド・ツー・エンドのサービス品質（ＱｏＳ）の信頼性の保証を実現する方法に関する。
【背景技術】
【０００２】
インターネット規模の絶えぬ拡大に従って、様々なネットワークサービスが大量に出現し、先進的なマルチメディアシステムも次々と現れる。リアルタイムサービスがネットワークの伝送遅延、遅延ジッタなどの特性に対してより敏感であるため、ネットワークにて突発性の高いファイルの伝送（ＦＴＰ）或いは画像ファイルを含むハイパーテキストの伝送（ＨＴＴＰ）などのサービスが発生する時、リアルタイムサービスは大きな影響を与えられる。また、マルチメディアサービスが大きな帯域幅を占用するため、現有ネットワークで保証すべき大事なサービスの伝送の信頼性を確保しにくくなる。そこで、大事なサービスの伝送の信頼性を保証するため、各種のサービス品質（ＱｏＳ、Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の技術が必要に応じて生まれている。インターネット工程任務組（ＩＥＴＦ， Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）はＱｏＳの需要を満足するため、既に多くのサービスモデルとメカニズムを提案している。現在、業界で比較的に認可されたのがネットワークのアクセス或いはエッジで統合サービス（Ｉｎｔ−Ｓｅｒｖ，Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ）モデルを使用し、またネットワークのコアで差別化サービス（Ｄｉｆｆ−ｓｅｒｖ，Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ）モデルが使用されている。
【０００３】
Ｄｉｆｆ−ｓｅｒｖモデルは優先度を設定するだけの措置でＱｏＳを保証し、当該モデルは回線の利用率が高いという特徴はあるが、具体的な効果の予測は難しい。そのため、業界はバックボーンネットワークのＤｉｆｆ−Ｓｅｒｖモデルに独立のベアラ制御層を導入し、一連の専門のＤｉｆｆ−Ｓｅｒｖ ＱｏＳシグナリングメカニズムを確立した。そして専門的にＤｉｆｆ−Ｓｅｒｖネットワークに一つのリソース管理層を確立して、ネットワークのトポロジーのリソースを管理する。このようなリソース管理Ｄｉｆｆ−Ｓｅｒｖ方式は独立のベアラ制御層を持つＤｉｆｆ−Ｓｅｒｖモデルと呼ばれる。図１は当該モデルを示す図である。そのうち、１０１はサービスサーバーであり、サービス制御層に属し、ソフトスイッチなどの機能の実現に用いる。１０２はベアラネットワークのリソース管理器であり、ベアラ制御層に属する。１０３に示すように中が詰まった円はエッジルータ（ＥＲ，Ｅｄｇｅ Ｒｏｕｔｅｒ）であり、１０４に示すように空腹の円はコアルータ（ＣＲ，Ｃｏｒｅ Ｒｏｕｔｅｒ）であり、１０５に示すように斜線で穴埋めされた円は境界ルータ（ＢＲ，Ｂｏｒｄｅｒ Ｒｏｕｔｅｒ）であり、ＥＲ、ＣＲ、ＢＲは全てベアラネットワークに属し、接続ノード（ＣＮ，Ｃｏｎｎｅｃｔｉｏｎ Ｎｏｄｅ）と総称し、ＣＲとＢＲは共に転送ルータ（ＴＲ，Ｔｒａｎｓｍｉｔ Ｒｏｕｔｅｒ）と呼ぶことができる。図１で、ベアラネットワークの中の各点線の楕円は一つの管理域であり、一つのベアラネットワークのリソース管理器によって管理され、各域の中はＢＲ或いはＥＲ、及び若干のＣＲを含む。
【０００４】
図１に示されたモデルにおいて、ベアラネットワークのリソース管理器は管理のルールとネットワークのトポロジーを配置し、クライアントのサービス帯域幅のためにリソースの割り当てを申し込む。各管理域のベアラネットワークのリソース管理器との間では、シグナリングを通してクライアントのサービス帯域幅の申し込みの請求と結果及び各ベアラネットワークのリソース管理器がサービスのために申し込んで割り当てたパスの情報などを伝送する。ベアラ制御層がユーザのサービス帯域幅の申し込みを処理する時、ユーザのサービスのパスを確定し、ベアラネットワークのリソース管理器はＥＲに指定のパスによりサービスフローを転送することを通知する。
【０００５】
ベアラネットワークのリソース管理器におけるルーティングはシグナリングルーティングとサービスルーティングとを含み、シグナリングルーティングとは各ベアラネットワークのリソース管理器がどのようして次ホップのベアラネットワークのリソース管理器を探すかの過程であり、サービスルーティングとはベアラネットワークのリソース管理器がどのようにサービスフローの情報により適当なベアラＬＳＰを探すかの過程であり、具体的に域内でのルーティングと域間でのルーティングとを含む。
【０００６】
通常、ベアラネットワークはベアラ制御層で確定されたパスによってユーザのサービスフローが指定するルートにより転送されることを実現する。現在、業界は主にマルチプロトコルラベルスイッチング（ＭＰＬＳ）技術を利用し、リソースの予約方式を使用してベアラ制御層に指定されたサービスフローパスに沿ってＬＳＰを確立し、或いは流量工事に基づくリソース予約プロトコル（ＲＳＶＰ−ＴＥ）又はルーティングを制限するラベル配布プロトコル（ＣＲ−ＬＤＰ）のディスプレールーティングメカニズムを使用してエンド・ツー・エンドのＬＳＰを確立する。
【０００７】
ベアラネットワークにおいて、信頼性の保証は非常に重要である。現在、ベアラネットワークでは既に信頼性の保証方法が多くあり、一番簡単なのはコールドバックアップである。コールドバックアップとは一つのネットワークエンティティを別のネットワークエンティティの完全のバックアップにすることを指す。例えば、ネットワークエンティティＢをネットワークエンティティＡのコールドバックアップにすると、バックアップのエンティティＢは元のエンティティＡが故障の時、完全に元のエンティティＡを取って代わることができる。当然、元のエンティティＡに対応されたベアラ接続とサービス接続は全て再建しなければならない。
【０００８】
コールドバックアップの方法はネットワークの確立初期で簡単に実現できる。それは、ノードがリアルタイム的にスクランブル（Ｓｃｒａｍｂｌｅ）と平滑を行う必要がないためである。しかし、コールドバックアップはただ小型ネットワークのみに適用できる。それは、小型ネットワークでサービス量が小さいかつリアルタイム性の要求も高くないため、中断して再建することが許され、ＬＳＰが実際の情況によりホットスイッチを行うことができないためである。
【０００９】
独立のベアラ制御層を持つネットワークにおいて、ＬＳＰをサービスデータフローのパスとして採用する時、現有の技術方法はＬＳＰに対する有効な保護に不足し、ＬＳＰに故障が発生する場合、当該ＬＳＰ上にベアされたサービスデータフローに中断が発生して、ユーザのサービス体験に対して重大な好ましくない影響を与える。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上記に鑑みて、本発明の主たる目的は、エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法を提供することにより、ベアラネットワークでのサービスの連続性及びネットワークＱｏＳの信頼性を保証することである。
【課題を解決するための手段】
【００１１】
上記の目的に達するため、本発明の技術方法は下記のように実現されたものである。
エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法であって、
ａ． 故障が発生するラベルスイッチパスＬＳＰがあるかどうかを検知・判断する、なければ、ステップａに戻り、あれば、当該故障ＬＳＰの所属するリソース制御機能エンティティが故障ＬＳＰの利用可能状態を更新してから、ステップｂを実行するステップと、
ｂ． 前記故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、バックアップＬＳＰがあれば、エッジルータ又は転送ルータは一定のポリシーにより、現在の故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのバックアップＬＳＰ上に切換え、バックアップＬＳＰがなければ、リソース制御機能エンティティは現在のトポロジーにより、現在故障ＬＳＰ上のサービスフローに新しいＬＳＰを配置して、故障ＬＳＰ上のサービスフローを新しく配置されたＬＳＰ上に切換え、サービスフローを切換える前に占用されたパスリソースを解放するステップとを含む方法。
【００１２】
ステップａにおいて、前記検知は、エッジルータ又は境界ルータが自体を経由するＬＳＰに故障が発生するかどうかをリアルタイム的に検知することであり、故障が発生したら、ステップａは、エッジルータ又は境界ルータは故障ＬＳＰの情報を自体の所属するリソース制御機能エンティティに報告し、リソース制御機能エンティティは報告された情報により故障ＬＳＰのリソースの利用可能状態を更新することを更に含む。或いは、ステップａにおいて、前記検知は、リソース制御機能エンティティが管轄の全てのＬＳＰに故障が発生するかどうかを検知することであってもいい。
【００１３】
当該方法は、サービス制御機能エンティティから送信された故障ＬＳＰ上のサービスフローを含むサービスフローの解放コマンドを受信したかどうかを判断し、受信した場合、リソース制御機能エンティティとエッジルータ又は境界ルータは相応のサービスフローのリソースを解放して、リソース制御機能エンティティでの相応のＬＳＰのリソースの利用可能状態を更新し、さもなければ、解放操作を実行しないことを更に含む。
【００１４】
上記方案で、ステップｂの後に、前記故障ＬＳＰが他の管理域でのＬＳＰと接続されたかどうかを判断し、接続された場合、リソース制御機能エンティティは新しいサービスＬＳＰの情報をベアラ接続制御シグナリングを通して相手の管理域での関連ＬＳＰの所属するリソース制御機能エンティティに通知して、相手のリソース制御機能エンティティの確認を獲得することを更に含む。
【００１５】
上記方案で、ステップｂにおいて、前記ポリシーは、サービスフローのクィンタプレッツ、サービスフローのサービスパスラベルスタックを含む。すると、当該方法は、リソース制御機能エンティティは故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新してから、更新後の現在故障ＬＳＰ上にベアされた全てのサービスフローのサービスパスラベルスタックをエッジルータ又は境界ルータに送信し、或いは、ルーティング設備が制御コマンドにより故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新することを更に含む。その中で、前記更新は、選定されたバックアップＬＳＰ又は故障ＬＳＰに再配置された新しいＬＳＰのラベル値で元の故障ＬＳＰのラベル値を取り替えることである。
【００１６】
ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置する時、リソース制御機能エンティティとエッジルータ又は境界ルータとの間で共通オープンポリシーサービスインターフェイスプロトコルを採用する。
【００１７】
上記方案で、ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置することは、リソース制御機能エンティティはルーティングマトリックステーブルを使って故障ＬＳＰ上のサービスフローが同一管理域での等価パスを計算することである。
【００１８】
当該方法は、予めＬＳＰに一本或いは一本以上のバックアップＬＳＰを設置し、設置されたバックアップ関係をリソース制御機能エンティティに記録・保存することを更に含む。
【００１９】
ステップａにおいてＬＳＰの故障が確定されたら、当該故障ＬＳＰの所属するリソース制御機能エンティティは故障ＬＳＰのリソースの利用可能状態を更新することを更に含む。
【発明の効果】
【００２０】
本発明に提供されたエンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法において、ＬＳＰに故障が発生した場合、ＬＳＰの一部分のホットスイッチを通してサービスデータフローがＬＳＰの故障時での連続性を保証して、故障ＬＳＰ上にベアされたサービスデータフローに中断が発生されなくようにして、ユーザがサービスの体験に不良影響を生じないことを確保し、且つ、エンド・ツー・エンドＱｏＳアーキテクチャーの信頼性を大いに高める。各種のサービスの異なる情況に対して、ネットワークの具体的な情況に応じてユーザのサービスに対するＱｏＳの需要を満足させることができる。当該方法は簡単に実現でき、維持管理も容易になり、ネットワークの構造に制限されなくて、いかなる規模のネットワークに適用することができる。
【発明を実施するための最良の形態】
【００２１】
本発明の発明構想の核心は、独立のベアラ制御層を持つネットワークに対して、ベアラ層ＬＳＰに故障が発生する時、ベアされたサービスデータフローを中断しない方法を提出する。即ち、ルーティング設備は一本のＬＳＰに故障が発生したことを検出すると、直ちに当該ＬＳＰ上にベアされた全てのサービスフローに対して高速な再ルーティングを行う。具体的に言うと、現在故障の発生したＬＳＰにバックアップＬＳＰがあるかどうかを判断して、あれば、故障ＬＳＰ上のサービスデータフローを当該故障ＬＳＰに設置されたバックアップＬＳＰ上に確実に交換する。故障ＬＳＰにいかなるバックアップＬＳＰも配置していない場合、リソース制御機能エンティティは故障ＬＳＰ上にベアされたサービスデータフローに速やかに新しいパスを配置し、この前で選択されたパスリソースを解放する。
【００２２】
ここで、上記リソース制御機能エンティティはベアラ制御層のエンティティであり、ベアラネットワークのリソース管理器としても用いられる。上記ルーティング設備はエッジルータ又は転送ルータであり、これらのルーティング設備はマルチプロトコルラベルスイッチングの操作維持管理（ＭＰＬＳ ＯＡＭ）メカニズムを支援でき、少なくともＬＳＰの検知メカニズムを支援することである。例えば、ＩＴＵ−Ｔ Ｙ．１７７１及びＹ．１７２０プロトコルと一致のＭＰＬＳ ＫＳＰの高速故障検知と保護交換メカニズムである。
【００２３】
上記故障ＬＳＰに設置されるバックアップＬＳＰは一本又は数本であって、バックアップＬＳＰの確立に対して、スタティック的な配置又はラベルスイッチシグナリング、例えばＣＲ−ＬＤＰ、ＲＳＶＰ−ＴＥプロトコルの交互を通して、エッジルータの間、或いはエッジルータと転送ルータの間でバックアップのＬＳＰチャネルを確立する。図４に示すように、現在サービスデータフローをベアするＬＳＰはサービスＬＳＰと呼ばれ、当該サービスＬＳＰのために設置されたバックアップのＬＳＰは当該サービスＬＳＰに対してバックアップＬＳＰと呼ばれる。リソース制御機能エンティティ（ＲＣＦ）の中には確立された全てのバックアップ関係を持つＬＳＰが記録してあり、一般的には、スタティック的な配置又はダイナミック的なコレクションを通して、ＲＣＦでバックアップＬＳＰデータベースを確立し、当該データベースではまた各ＬＳＰの現在のリソースの利用可能状態が保存してある。当該リソースの利用可能状態は当該ＬＳＰ現在の状態を含み、例えば、故障中或いは正常中、また当該ＬＳＰ上にベアされたサービスフローの情況及び当該サービスフローの現在の状態も含む。
【００２４】
設置されたお互いにバックアップとしての二本或いは数本のＬＳＰに対して、正常な作業状態において、主バックアップ状態にあってもいいし、また負荷を分担する目的を達するように各自が独立で異なるサービスフローをベアしてもいい。お互いにバックアップであるＬＳＰの中で、あるＬＳＰに故障が発生した後、故障ＬＳＰ上にベアされたサービスフローはすぐバックアップＬＳＰ上に切換えられ、同時に、バックアップＬＳＰ上にベアされた元のサービスフローはまた継続に伝送される。
【００２５】
再ルーティングを行う時、なるべく同一のサービスフローに同一の管理域内で故障前のパスと等価のパスを探す必要である。高速の再ルーティングに対して、ルーティングマトリックステーブルが用いられることができるがこれに限定されなくて、サービスフローの等価のパスを計算・保存し、テーブルでのパラメータはサービスのタイプ、利用可能のリソース、ポリシー、特定のＱｏＳ需要などの情報を含むがこれらに限定されない。このようにすると、相応のパラメータ情報により、パスは再計算と即時の交換を得ることができる。
【００２６】
図５に示すように、本発明の方法は下記のステップが含まれている。
ステップ５０１〜５０２で、故障が発生するＬＳＰがあるかどうかを検知・判断して、なければ、ステップ５０１に戻り、あれば、ステップ５０３を実行する。当然、故障が発生したＬＳＰがある場合、当該故障ＬＳＰの所属するリソース制御機能エンティティはまず故障ＬＳＰのリソースの利用可能状態を更新してから、ステップ５０３を実行していい。
【００２７】
故障ＬＳＰが正常に回復された場合、自動的に現在サービスフローを伝送しているＬＳＰのバックアップＬＳＰになり、同時に相応のリソース制御機能エンティティは当該ＬＳＰのリソースの利用可能状態を修正する。
【００２８】
本ステップの具体的な実現は下記の二種類の情況に分けることができる。一つは、エッジルータ又は境界ルータが自体を経由するＬＳＰに故障が発生するかどうかを検知し、報告する。もう一つは、リソース制御機能エンティティがどのＬＳＰに故障が発生するかどうかを検知する。第一番目の情況に対して、エッジルータ又は境界ルータは自体の支援するＬＳＰ検知メカニズムにより、自体を経由するＬＳＰに故障が発生するかどうかをリアルタイム的に検知して、あるＬＳＰに故障が発生した場合、この故障ＬＳＰの相応の情報を自体の所属するリソース制御機能エンティティに報告し、リソース制御機能エンティティは受け取った情報により自体データベースでの故障ＬＳＰのリソースの利用可能状態を修正する。第二番目の情況に対して、リソース制御機能エンティティは管轄の全てのＬＳＰに故障が発生するかどうかを検知して、あるＬＳＰに故障が発生したことを検出すると、自体データベースでの当該故障ＬＳＰのリソースの利用可能状態を修正する。
【００２９】
ステップ５０３〜５０４で、現在、サービス制御機能エンティティ（ＳＣＦ）から出された、故障ＬＳＰ上のサービスフローを含むサービスフローの解放コマンドを受信したかどうかを判断し、受信した場合、リソース制御機能エンティティとエッジルータ又は境界ルータは相応のサービスフローのリソースを解放し、そして、リソース制御機能エンティティでの相応のＬＳＰのリソースの利用可能状態を更新してから、ステップ５０５を実行する。受信しなかった場合、直接にステップ５０５を実行する。即ち、いま解放しているサービスフローに対しては、新しいサービスＬＳＰ上に切換える必要はない。
【００３０】
ステップ５０５で、当該故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、あれば、エッジルータ又は転送ルータは一定のポリシーにより、現在故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのあるバックアップＬＳＰに速やかに切換えて、そのバックアップＬＳＰが新しいサービスＬＳＰになるようにする。なければ、ＲＣＦは現在のトポロジーにより、速やかに故障ＬＳＰ上のサービスフローに新しいＬＳＰパスを配置して、故障ＬＳＰ上の相応のサービスフローを新しく配置したＬＳＰ上に切換えて、サービスフローを切換える前に占用したパスリソースを解放する。これはＲＣＦがリアルタイム的にあるＬＳＰをバックアップＬＳＰと指定することに当たる。切換えが終わった後、ＲＣＦは自体の保存した相応ＬＳＰのリソースの利用可能状態を更新する必要である。
【００３１】
そのうち、上記一定のポリシーはＲＣＦからリアルタイム的に出されてエッジルータ又は転送ルータに保存されたものであり、上記ポリシーはサービスフローのクィンタプレッツ（送り元アドレス、宛先アドレス、送り元ポート、宛先ポート、プロトコルタイプ）、サービスフローのサービスパスラベルスタックを含む。
【００３２】
各サービスフローに皆一つのサービスパスラベルスタックがあり、当該サービスパスラベルスタックに当該サービスフローの経由した全てのＬＳＰのラベル値が保存してあるため、もしどのＬＳＰに故障が発生したら、サービスパスラベルスタック中の故障ＬＳＰのラベル値を利用可能のＬＳＰのラベル値に取り替えさえすれば、或いは制御コマンドを通してルーティング設備で選定された新しいサービスＬＳＰのラベル値と故障ＬＳＰのラベル値を交換しさえすれば、サービスフローは自然に新しいＬＳＰパスに沿って継続に伝送される。ここで、制御コマンドはリソース制御機能エンティティ又はその他の故障を検出したエンティティ、例えばルーティング設備自体のアプリケーション層から出されたものであり、ルーティング設備はエッジルータ或いは転送ルータを指す。
【００３３】
前記状況で、前記過程は更に下記の内容を含むことができる。リソース制御機能エンティティは故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新し、即ち、サービスフローのサービスパスラベルスタックにおいて、選定されたバックアップＬＳＰ或いは故障ＬＳＰに再配置された新しいＬＳＰのラベル値で元の故障ＬＳＰのラベル値を取り替えてから、ＲＣＦは新しいＬＳＰの関連情報から構成された更新後のサービスフローのサービスパスラベルスタックを、プロトコルを通してエッジルータ又は境界ルータに送信して、新しいサービスデータフローのチャネルを確立し、故障ＬＳＰ上のサービスフローがバックアップＬＳＰへの高速の切換えを完成するようにする。その後、エッジルータ又は境界ルータはまた送信されたポリシーにより、故障ＬＳＰ上にベアされたサービスフローを直接にバックアップＬＳＰ上に切換える。当然、上記バックアップＬＳＰを新しいサービスＬＳＰに変わる具体的な実現方式は、新しいサービスＬＳＰと故障ＬＳＰのラベル値を交換することにより、またこれに限定されずに、サービスパスラベルスタックの更新を実現できることである。
【００３４】
ここで、上記ＲＣＦが新しいＬＳＰを配置する時、ＲＣＦとＥＲ又はＴＲの間で採用されたインターフェイスプロトコルは共通オープンポリシーサービス（ＣＯＰＳ）プロトコルであるが、これに限定されない。ＲＣＦはルーティングマトリックステーブルを使っているが、これに限定されずに、故障ＬＳＰ上のサービスフローの等価パスを計算・保存する。マトリックステーブルでのパラメータはサービスのタイプ、利用可能のリソース、ポリシー、特定のＱｏＳ需要などの情報を含むが、これらに限定されない。このようにすると、相応のパラメータ情報により、パスは再計算と即時の交換を得ることができる。
【００３５】
実際に応用する場合、ステップ５０３と５０４とを省略しでもいい、即ち、サービスフローが現在解放の必要があるサービスフローであるかどうかに関わらず、直接に故障ＬＳＰ上の全てのサービスフローを一緒にバックアップＬＳＰ上に切換える。またステップ５０３と５０４とをステップ５０５〜５０７の後で実行させてもいい、即ち、まず故障ＬＳＰ上の現在解放の必要があるサービスフローを全てのサービスフローと一緒にバックアップＬＳＰ上に切換えてから、相応サービスフローの解放過程を実行する。
【００３６】
前記過程で、更に下記の内容を含むことができる。当該故障ＬＳＰが他の管理域でのＬＳＰと接続されたかどうかを判断し、接続された場合、ＲＣＦは新しいサービスＬＳＰの情報をベアラ接続制御シグナリングにより相手の管理域での関連ＬＳＰの所属するＲＣＦに通知し、そして相手のＲＣＦの確認を獲得する。二つのＲＣＦとの間の交互は既存の交互プロトコルとプロセスにより実現できる。以上は、本発明の好ましい実施例だけであり、本発明の保護の範囲を限定するものではない。
【図面の簡単な説明】
【００３７】
【図１】従来の技術における独立のベアラ制御層ネットワークのモデルを示す図である。
【図２】本発明におけるバックアップＬＳＰを確立するバックアップ関係を示す図である。
【図３】本発明の方法の具体的な実現フローチャートである。
【符号の説明】
【００３８】
ＥＲ エッジルータ
ＴＲ 転送ルータ
【技術分野】
【０００１】
本発明は、サービス品質を保障する技術に関し、特にラベルスイッチパス（ＬＳＰ）のホットスイッチを利用してベアラネットワークにおいてエンド・ツー・エンドのサービス品質（ＱｏＳ）の信頼性の保証を実現する方法に関する。
【背景技術】
【０００２】
インターネット規模の絶えぬ拡大に従って、様々なネットワークサービスが大量に出現し、先進的なマルチメディアシステムも次々と現れる。リアルタイムサービスがネットワークの伝送遅延、遅延ジッタなどの特性に対してより敏感であるため、ネットワークにて突発性の高いファイルの伝送（ＦＴＰ）或いは画像ファイルを含むハイパーテキストの伝送（ＨＴＴＰ）などのサービスが発生する時、リアルタイムサービスは大きな影響を与えられる。また、マルチメディアサービスが大きな帯域幅を占用するため、現有ネットワークで保証すべき大事なサービスの伝送の信頼性を確保しにくくなる。そこで、大事なサービスの伝送の信頼性を保証するため、各種のサービス品質（ＱｏＳ、Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の技術が必要に応じて生まれている。インターネット工程任務組（ＩＥＴＦ， Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）はＱｏＳの需要を満足するため、既に多くのサービスモデルとメカニズムを提案している。現在、業界で比較的に認可されたのがネットワークのアクセス或いはエッジで統合サービス（Ｉｎｔ−Ｓｅｒｖ，Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ）モデルを使用し、またネットワークのコアで差別化サービス（Ｄｉｆｆ−ｓｅｒｖ，Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ）モデルが使用されている。
【０００３】
Ｄｉｆｆ−ｓｅｒｖモデルは優先度を設定するだけの措置でＱｏＳを保証し、当該モデルは回線の利用率が高いという特徴はあるが、具体的な効果の予測は難しい。そのため、業界はバックボーンネットワークのＤｉｆｆ−Ｓｅｒｖモデルに独立のベアラ制御層を導入し、一連の専門のＤｉｆｆ−Ｓｅｒｖ ＱｏＳシグナリングメカニズムを確立した。そして専門的にＤｉｆｆ−Ｓｅｒｖネットワークに一つのリソース管理層を確立して、ネットワークのトポロジーのリソースを管理する。このようなリソース管理Ｄｉｆｆ−Ｓｅｒｖ方式は独立のベアラ制御層を持つＤｉｆｆ−Ｓｅｒｖモデルと呼ばれる。図１は当該モデルを示す図である。そのうち、１０１はサービスサーバーであり、サービス制御層に属し、ソフトスイッチなどの機能の実現に用いる。１０２はベアラネットワークのリソース管理器であり、ベアラ制御層に属する。１０３に示すように中が詰まった円はエッジルータ（ＥＲ，Ｅｄｇｅ Ｒｏｕｔｅｒ）であり、１０４に示すように空腹の円はコアルータ（ＣＲ，Ｃｏｒｅ Ｒｏｕｔｅｒ）であり、１０５に示すように斜線で穴埋めされた円は境界ルータ（ＢＲ，Ｂｏｒｄｅｒ Ｒｏｕｔｅｒ）であり、ＥＲ、ＣＲ、ＢＲは全てベアラネットワークに属し、接続ノード（ＣＮ，Ｃｏｎｎｅｃｔｉｏｎ Ｎｏｄｅ）と総称し、ＣＲとＢＲは共に転送ルータ（ＴＲ，Ｔｒａｎｓｍｉｔ Ｒｏｕｔｅｒ）と呼ぶことができる。図１で、ベアラネットワークの中の各点線の楕円は一つの管理域であり、一つのベアラネットワークのリソース管理器によって管理され、各域の中はＢＲ或いはＥＲ、及び若干のＣＲを含む。
【０００４】
図１に示されたモデルにおいて、ベアラネットワークのリソース管理器は管理のルールとネットワークのトポロジーを配置し、クライアントのサービス帯域幅のためにリソースの割り当てを申し込む。各管理域のベアラネットワークのリソース管理器との間では、シグナリングを通してクライアントのサービス帯域幅の申し込みの請求と結果及び各ベアラネットワークのリソース管理器がサービスのために申し込んで割り当てたパスの情報などを伝送する。ベアラ制御層がユーザのサービス帯域幅の申し込みを処理する時、ユーザのサービスのパスを確定し、ベアラネットワークのリソース管理器はＥＲに指定のパスによりサービスフローを転送することを通知する。
【０００５】
ベアラネットワークのリソース管理器におけるルーティングはシグナリングルーティングとサービスルーティングとを含み、シグナリングルーティングとは各ベアラネットワークのリソース管理器がどのようして次ホップのベアラネットワークのリソース管理器を探すかの過程であり、サービスルーティングとはベアラネットワークのリソース管理器がどのようにサービスフローの情報により適当なベアラＬＳＰを探すかの過程であり、具体的に域内でのルーティングと域間でのルーティングとを含む。
【０００６】
通常、ベアラネットワークはベアラ制御層で確定されたパスによってユーザのサービスフローが指定するルートにより転送されることを実現する。現在、業界は主にマルチプロトコルラベルスイッチング（ＭＰＬＳ）技術を利用し、リソースの予約方式を使用してベアラ制御層に指定されたサービスフローパスに沿ってＬＳＰを確立し、或いは流量工事に基づくリソース予約プロトコル（ＲＳＶＰ−ＴＥ）又はルーティングを制限するラベル配布プロトコル（ＣＲ−ＬＤＰ）のディスプレールーティングメカニズムを使用してエンド・ツー・エンドのＬＳＰを確立する。
【０００７】
ベアラネットワークにおいて、信頼性の保証は非常に重要である。現在、ベアラネットワークでは既に信頼性の保証方法が多くあり、一番簡単なのはコールドバックアップである。コールドバックアップとは一つのネットワークエンティティを別のネットワークエンティティの完全のバックアップにすることを指す。例えば、ネットワークエンティティＢをネットワークエンティティＡのコールドバックアップにすると、バックアップのエンティティＢは元のエンティティＡが故障の時、完全に元のエンティティＡを取って代わることができる。当然、元のエンティティＡに対応されたベアラ接続とサービス接続は全て再建しなければならない。
【０００８】
コールドバックアップの方法はネットワークの確立初期で簡単に実現できる。それは、ノードがリアルタイム的にスクランブル（Ｓｃｒａｍｂｌｅ）と平滑を行う必要がないためである。しかし、コールドバックアップはただ小型ネットワークのみに適用できる。それは、小型ネットワークでサービス量が小さいかつリアルタイム性の要求も高くないため、中断して再建することが許され、ＬＳＰが実際の情況によりホットスイッチを行うことができないためである。
【０００９】
独立のベアラ制御層を持つネットワークにおいて、ＬＳＰをサービスデータフローのパスとして採用する時、現有の技術方法はＬＳＰに対する有効な保護に不足し、ＬＳＰに故障が発生する場合、当該ＬＳＰ上にベアされたサービスデータフローに中断が発生して、ユーザのサービス体験に対して重大な好ましくない影響を与える。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上記に鑑みて、本発明の主たる目的は、エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法を提供することにより、ベアラネットワークでのサービスの連続性及びネットワークＱｏＳの信頼性を保証することである。
【課題を解決するための手段】
【００１１】
上記の目的に達するため、本発明の技術方法は下記のように実現されたものである。
エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法であって、
ａ． 故障が発生するラベルスイッチパスＬＳＰがあるかどうかを検知・判断する、なければ、ステップａに戻り、あれば、当該故障ＬＳＰの所属するリソース制御機能エンティティが故障ＬＳＰの利用可能状態を更新してから、ステップｂを実行するステップと、
ｂ． 前記故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、バックアップＬＳＰがあれば、エッジルータ又は転送ルータは一定のポリシーにより、現在の故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのバックアップＬＳＰ上に切換え、バックアップＬＳＰがなければ、リソース制御機能エンティティは現在のトポロジーにより、現在故障ＬＳＰ上のサービスフローに新しいＬＳＰを配置して、故障ＬＳＰ上のサービスフローを新しく配置されたＬＳＰ上に切換え、サービスフローを切換える前に占用されたパスリソースを解放するステップとを含む方法。
【００１２】
ステップａにおいて、前記検知は、エッジルータ又は境界ルータが自体を経由するＬＳＰに故障が発生するかどうかをリアルタイム的に検知することであり、故障が発生したら、ステップａは、エッジルータ又は境界ルータは故障ＬＳＰの情報を自体の所属するリソース制御機能エンティティに報告し、リソース制御機能エンティティは報告された情報により故障ＬＳＰのリソースの利用可能状態を更新することを更に含む。或いは、ステップａにおいて、前記検知は、リソース制御機能エンティティが管轄の全てのＬＳＰに故障が発生するかどうかを検知することであってもいい。
【００１３】
当該方法は、サービス制御機能エンティティから送信された故障ＬＳＰ上のサービスフローを含むサービスフローの解放コマンドを受信したかどうかを判断し、受信した場合、リソース制御機能エンティティとエッジルータ又は境界ルータは相応のサービスフローのリソースを解放して、リソース制御機能エンティティでの相応のＬＳＰのリソースの利用可能状態を更新し、さもなければ、解放操作を実行しないことを更に含む。
【００１４】
上記方案で、ステップｂの後に、前記故障ＬＳＰが他の管理域でのＬＳＰと接続されたかどうかを判断し、接続された場合、リソース制御機能エンティティは新しいサービスＬＳＰの情報をベアラ接続制御シグナリングを通して相手の管理域での関連ＬＳＰの所属するリソース制御機能エンティティに通知して、相手のリソース制御機能エンティティの確認を獲得することを更に含む。
【００１５】
上記方案で、ステップｂにおいて、前記ポリシーは、サービスフローのクィンタプレッツ、サービスフローのサービスパスラベルスタックを含む。すると、当該方法は、リソース制御機能エンティティは故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新してから、更新後の現在故障ＬＳＰ上にベアされた全てのサービスフローのサービスパスラベルスタックをエッジルータ又は境界ルータに送信し、或いは、ルーティング設備が制御コマンドにより故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新することを更に含む。その中で、前記更新は、選定されたバックアップＬＳＰ又は故障ＬＳＰに再配置された新しいＬＳＰのラベル値で元の故障ＬＳＰのラベル値を取り替えることである。
【００１６】
ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置する時、リソース制御機能エンティティとエッジルータ又は境界ルータとの間で共通オープンポリシーサービスインターフェイスプロトコルを採用する。
【００１７】
上記方案で、ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置することは、リソース制御機能エンティティはルーティングマトリックステーブルを使って故障ＬＳＰ上のサービスフローが同一管理域での等価パスを計算することである。
【００１８】
当該方法は、予めＬＳＰに一本或いは一本以上のバックアップＬＳＰを設置し、設置されたバックアップ関係をリソース制御機能エンティティに記録・保存することを更に含む。
【００１９】
ステップａにおいてＬＳＰの故障が確定されたら、当該故障ＬＳＰの所属するリソース制御機能エンティティは故障ＬＳＰのリソースの利用可能状態を更新することを更に含む。
【発明の効果】
【００２０】
本発明に提供されたエンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法において、ＬＳＰに故障が発生した場合、ＬＳＰの一部分のホットスイッチを通してサービスデータフローがＬＳＰの故障時での連続性を保証して、故障ＬＳＰ上にベアされたサービスデータフローに中断が発生されなくようにして、ユーザがサービスの体験に不良影響を生じないことを確保し、且つ、エンド・ツー・エンドＱｏＳアーキテクチャーの信頼性を大いに高める。各種のサービスの異なる情況に対して、ネットワークの具体的な情況に応じてユーザのサービスに対するＱｏＳの需要を満足させることができる。当該方法は簡単に実現でき、維持管理も容易になり、ネットワークの構造に制限されなくて、いかなる規模のネットワークに適用することができる。
【発明を実施するための最良の形態】
【００２１】
本発明の発明構想の核心は、独立のベアラ制御層を持つネットワークに対して、ベアラ層ＬＳＰに故障が発生する時、ベアされたサービスデータフローを中断しない方法を提出する。即ち、ルーティング設備は一本のＬＳＰに故障が発生したことを検出すると、直ちに当該ＬＳＰ上にベアされた全てのサービスフローに対して高速な再ルーティングを行う。具体的に言うと、現在故障の発生したＬＳＰにバックアップＬＳＰがあるかどうかを判断して、あれば、故障ＬＳＰ上のサービスデータフローを当該故障ＬＳＰに設置されたバックアップＬＳＰ上に確実に交換する。故障ＬＳＰにいかなるバックアップＬＳＰも配置していない場合、リソース制御機能エンティティは故障ＬＳＰ上にベアされたサービスデータフローに速やかに新しいパスを配置し、この前で選択されたパスリソースを解放する。
【００２２】
ここで、上記リソース制御機能エンティティはベアラ制御層のエンティティであり、ベアラネットワークのリソース管理器としても用いられる。上記ルーティング設備はエッジルータ又は転送ルータであり、これらのルーティング設備はマルチプロトコルラベルスイッチングの操作維持管理（ＭＰＬＳ ＯＡＭ）メカニズムを支援でき、少なくともＬＳＰの検知メカニズムを支援することである。例えば、ＩＴＵ−Ｔ Ｙ．１７７１及びＹ．１７２０プロトコルと一致のＭＰＬＳ ＫＳＰの高速故障検知と保護交換メカニズムである。
【００２３】
上記故障ＬＳＰに設置されるバックアップＬＳＰは一本又は数本であって、バックアップＬＳＰの確立に対して、スタティック的な配置又はラベルスイッチシグナリング、例えばＣＲ−ＬＤＰ、ＲＳＶＰ−ＴＥプロトコルの交互を通して、エッジルータの間、或いはエッジルータと転送ルータの間でバックアップのＬＳＰチャネルを確立する。図４に示すように、現在サービスデータフローをベアするＬＳＰはサービスＬＳＰと呼ばれ、当該サービスＬＳＰのために設置されたバックアップのＬＳＰは当該サービスＬＳＰに対してバックアップＬＳＰと呼ばれる。リソース制御機能エンティティ（ＲＣＦ）の中には確立された全てのバックアップ関係を持つＬＳＰが記録してあり、一般的には、スタティック的な配置又はダイナミック的なコレクションを通して、ＲＣＦでバックアップＬＳＰデータベースを確立し、当該データベースではまた各ＬＳＰの現在のリソースの利用可能状態が保存してある。当該リソースの利用可能状態は当該ＬＳＰ現在の状態を含み、例えば、故障中或いは正常中、また当該ＬＳＰ上にベアされたサービスフローの情況及び当該サービスフローの現在の状態も含む。
【００２４】
設置されたお互いにバックアップとしての二本或いは数本のＬＳＰに対して、正常な作業状態において、主バックアップ状態にあってもいいし、また負荷を分担する目的を達するように各自が独立で異なるサービスフローをベアしてもいい。お互いにバックアップであるＬＳＰの中で、あるＬＳＰに故障が発生した後、故障ＬＳＰ上にベアされたサービスフローはすぐバックアップＬＳＰ上に切換えられ、同時に、バックアップＬＳＰ上にベアされた元のサービスフローはまた継続に伝送される。
【００２５】
再ルーティングを行う時、なるべく同一のサービスフローに同一の管理域内で故障前のパスと等価のパスを探す必要である。高速の再ルーティングに対して、ルーティングマトリックステーブルが用いられることができるがこれに限定されなくて、サービスフローの等価のパスを計算・保存し、テーブルでのパラメータはサービスのタイプ、利用可能のリソース、ポリシー、特定のＱｏＳ需要などの情報を含むがこれらに限定されない。このようにすると、相応のパラメータ情報により、パスは再計算と即時の交換を得ることができる。
【００２６】
図５に示すように、本発明の方法は下記のステップが含まれている。
ステップ５０１〜５０２で、故障が発生するＬＳＰがあるかどうかを検知・判断して、なければ、ステップ５０１に戻り、あれば、ステップ５０３を実行する。当然、故障が発生したＬＳＰがある場合、当該故障ＬＳＰの所属するリソース制御機能エンティティはまず故障ＬＳＰのリソースの利用可能状態を更新してから、ステップ５０３を実行していい。
【００２７】
故障ＬＳＰが正常に回復された場合、自動的に現在サービスフローを伝送しているＬＳＰのバックアップＬＳＰになり、同時に相応のリソース制御機能エンティティは当該ＬＳＰのリソースの利用可能状態を修正する。
【００２８】
本ステップの具体的な実現は下記の二種類の情況に分けることができる。一つは、エッジルータ又は境界ルータが自体を経由するＬＳＰに故障が発生するかどうかを検知し、報告する。もう一つは、リソース制御機能エンティティがどのＬＳＰに故障が発生するかどうかを検知する。第一番目の情況に対して、エッジルータ又は境界ルータは自体の支援するＬＳＰ検知メカニズムにより、自体を経由するＬＳＰに故障が発生するかどうかをリアルタイム的に検知して、あるＬＳＰに故障が発生した場合、この故障ＬＳＰの相応の情報を自体の所属するリソース制御機能エンティティに報告し、リソース制御機能エンティティは受け取った情報により自体データベースでの故障ＬＳＰのリソースの利用可能状態を修正する。第二番目の情況に対して、リソース制御機能エンティティは管轄の全てのＬＳＰに故障が発生するかどうかを検知して、あるＬＳＰに故障が発生したことを検出すると、自体データベースでの当該故障ＬＳＰのリソースの利用可能状態を修正する。
【００２９】
ステップ５０３〜５０４で、現在、サービス制御機能エンティティ（ＳＣＦ）から出された、故障ＬＳＰ上のサービスフローを含むサービスフローの解放コマンドを受信したかどうかを判断し、受信した場合、リソース制御機能エンティティとエッジルータ又は境界ルータは相応のサービスフローのリソースを解放し、そして、リソース制御機能エンティティでの相応のＬＳＰのリソースの利用可能状態を更新してから、ステップ５０５を実行する。受信しなかった場合、直接にステップ５０５を実行する。即ち、いま解放しているサービスフローに対しては、新しいサービスＬＳＰ上に切換える必要はない。
【００３０】
ステップ５０５で、当該故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、あれば、エッジルータ又は転送ルータは一定のポリシーにより、現在故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのあるバックアップＬＳＰに速やかに切換えて、そのバックアップＬＳＰが新しいサービスＬＳＰになるようにする。なければ、ＲＣＦは現在のトポロジーにより、速やかに故障ＬＳＰ上のサービスフローに新しいＬＳＰパスを配置して、故障ＬＳＰ上の相応のサービスフローを新しく配置したＬＳＰ上に切換えて、サービスフローを切換える前に占用したパスリソースを解放する。これはＲＣＦがリアルタイム的にあるＬＳＰをバックアップＬＳＰと指定することに当たる。切換えが終わった後、ＲＣＦは自体の保存した相応ＬＳＰのリソースの利用可能状態を更新する必要である。
【００３１】
そのうち、上記一定のポリシーはＲＣＦからリアルタイム的に出されてエッジルータ又は転送ルータに保存されたものであり、上記ポリシーはサービスフローのクィンタプレッツ（送り元アドレス、宛先アドレス、送り元ポート、宛先ポート、プロトコルタイプ）、サービスフローのサービスパスラベルスタックを含む。
【００３２】
各サービスフローに皆一つのサービスパスラベルスタックがあり、当該サービスパスラベルスタックに当該サービスフローの経由した全てのＬＳＰのラベル値が保存してあるため、もしどのＬＳＰに故障が発生したら、サービスパスラベルスタック中の故障ＬＳＰのラベル値を利用可能のＬＳＰのラベル値に取り替えさえすれば、或いは制御コマンドを通してルーティング設備で選定された新しいサービスＬＳＰのラベル値と故障ＬＳＰのラベル値を交換しさえすれば、サービスフローは自然に新しいＬＳＰパスに沿って継続に伝送される。ここで、制御コマンドはリソース制御機能エンティティ又はその他の故障を検出したエンティティ、例えばルーティング設備自体のアプリケーション層から出されたものであり、ルーティング設備はエッジルータ或いは転送ルータを指す。
【００３３】
前記状況で、前記過程は更に下記の内容を含むことができる。リソース制御機能エンティティは故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新し、即ち、サービスフローのサービスパスラベルスタックにおいて、選定されたバックアップＬＳＰ或いは故障ＬＳＰに再配置された新しいＬＳＰのラベル値で元の故障ＬＳＰのラベル値を取り替えてから、ＲＣＦは新しいＬＳＰの関連情報から構成された更新後のサービスフローのサービスパスラベルスタックを、プロトコルを通してエッジルータ又は境界ルータに送信して、新しいサービスデータフローのチャネルを確立し、故障ＬＳＰ上のサービスフローがバックアップＬＳＰへの高速の切換えを完成するようにする。その後、エッジルータ又は境界ルータはまた送信されたポリシーにより、故障ＬＳＰ上にベアされたサービスフローを直接にバックアップＬＳＰ上に切換える。当然、上記バックアップＬＳＰを新しいサービスＬＳＰに変わる具体的な実現方式は、新しいサービスＬＳＰと故障ＬＳＰのラベル値を交換することにより、またこれに限定されずに、サービスパスラベルスタックの更新を実現できることである。
【００３４】
ここで、上記ＲＣＦが新しいＬＳＰを配置する時、ＲＣＦとＥＲ又はＴＲの間で採用されたインターフェイスプロトコルは共通オープンポリシーサービス（ＣＯＰＳ）プロトコルであるが、これに限定されない。ＲＣＦはルーティングマトリックステーブルを使っているが、これに限定されずに、故障ＬＳＰ上のサービスフローの等価パスを計算・保存する。マトリックステーブルでのパラメータはサービスのタイプ、利用可能のリソース、ポリシー、特定のＱｏＳ需要などの情報を含むが、これらに限定されない。このようにすると、相応のパラメータ情報により、パスは再計算と即時の交換を得ることができる。
【００３５】
実際に応用する場合、ステップ５０３と５０４とを省略しでもいい、即ち、サービスフローが現在解放の必要があるサービスフローであるかどうかに関わらず、直接に故障ＬＳＰ上の全てのサービスフローを一緒にバックアップＬＳＰ上に切換える。またステップ５０３と５０４とをステップ５０５〜５０７の後で実行させてもいい、即ち、まず故障ＬＳＰ上の現在解放の必要があるサービスフローを全てのサービスフローと一緒にバックアップＬＳＰ上に切換えてから、相応サービスフローの解放過程を実行する。
【００３６】
前記過程で、更に下記の内容を含むことができる。当該故障ＬＳＰが他の管理域でのＬＳＰと接続されたかどうかを判断し、接続された場合、ＲＣＦは新しいサービスＬＳＰの情報をベアラ接続制御シグナリングにより相手の管理域での関連ＬＳＰの所属するＲＣＦに通知し、そして相手のＲＣＦの確認を獲得する。二つのＲＣＦとの間の交互は既存の交互プロトコルとプロセスにより実現できる。以上は、本発明の好ましい実施例だけであり、本発明の保護の範囲を限定するものではない。
【図面の簡単な説明】
【００３７】
【図１】従来の技術における独立のベアラ制御層ネットワークのモデルを示す図である。
【図２】本発明におけるバックアップＬＳＰを確立するバックアップ関係を示す図である。
【図３】本発明の方法の具体的な実現フローチャートである。
【符号の説明】
【００３８】
ＥＲ エッジルータ
ＴＲ 転送ルータ
【特許請求の範囲】
【請求項１】
エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法であって、
ａ．故障が発生するラベルスイッチパスＬＳＰがあるかどうかを検知・判断する、なければ、ステップａに戻り、あれば、ステップｂを実行するステップと、
ｂ．前記故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、バックアップＬＳＰがあれば、エッジルータ又は転送ルータは一定のポリシーにより、現在の故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのバックアップＬＳＰ上に切換え、バックアップＬＳＰがなければ、リソース制御機能エンティティは現在のトポロジーにより、現在故障ＬＳＰ上のサービスフローに新しいＬＳＰを配置して、故障ＬＳＰ上のサービスフローを新しく配置されたＬＳＰ上に切換え、サービスフローを切換える前に占用されたパスリソースを解放するステップとを含むことを特徴とする方法。
【請求項２】
ステップａにおいて、前記検知は、エッジルータ又は境界ルータが自体を経由するＬＳＰに故障が発生するかどうかをリアルタイム的に検知することであり、
故障が発生したら、ステップａは、
エッジルータ又は境界ルータは故障ＬＳＰの情報を自体の所属するリソース制御機能エンティティに報告し、リソース制御機能エンティティは報告された情報により故障ＬＳＰのリソースの利用可能状態を更新することを更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
ステップａにおいて、前記検知は、リソース制御機能エンティティが管轄の全てのＬＳＰに故障が発生するかどうかを検知することであることを特徴とする請求項１に記載の方法。
【請求項４】
サービス制御機能エンティティから送信された故障ＬＳＰ上のサービスフローを含むサービスフローの解放コマンドを受信したかどうかを判断し、受信した場合、リソース制御機能エンティティとエッジルータ又は境界ルータは相応のサービスフローのリソースを解放して、リソース制御機能エンティティでの相応のＬＳＰのリソースの利用可能状態を更新し、受信しなかった場合、解放操作を実行しないことを更に含むことを特徴とする請求項１又は２又は３に記載の方法。
【請求項５】
ステップｂの後に、
前記故障ＬＳＰが非本管理域でのＬＳＰと接続されたかどうかを判断し、接続された場合、リソース制御機能エンティティは新しいサービスＬＳＰの情報をベアラ接続制御シグナリングを通して相手の管理域での関連ＬＳＰの所属するリソース制御機能エンティティに通知して、相手のリソース制御機能エンティティの確認を獲得することを更に含むことを特徴とする請求項１又は２又は３に記載の方法。
【請求項６】
ステップｂにおいて、前記ポリシーは、サービスフローのクィンタプレッツ、サービスフローのサービスパスラベルスタックを含むことを特徴とする請求項１又は２又は３に記載の方法。
【請求項７】
リソース制御機能エンティティは故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新してから、更新後の現在故障ＬＳＰ上にベアされた全てのサービスフローのサービスパスラベルスタックをエッジルータ又は境界ルータに送信し、或いは、ルーティング設備が制御コマンドにより故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新することを更に含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記更新とは、選定されたバックアップＬＳＰ又は故障ＬＳＰに再配置された新しいＬＳＰのラベル値で元の故障ＬＳＰのラベル値を取り替えることであることを特徴とする請求項７に記載の方法。
【請求項９】
ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置する時、リソース制御機能エンティティとエッジルータ又は境界ルータとの間で共通オープンポリシーサービスインターフェイスプロトコルを採用することを特徴とする請求項１又は２又は３に記載の方法。
【請求項１０】
ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置することは、リソース制御機能エンティティはルーティングマトリックステーブルを使って故障ＬＳＰ上のサービスフローが同一管理域での等価パスを計算することであることを特徴とする請求項１又は２又は３に記載の方法。
【請求項１１】
予めＬＳＰに一本或いは一本以上のバックアップＬＳＰを設置し、設置されたバックアップ関係をリソース制御機能エンティティに記録・保存することを更に含むことを特徴とする請求項１に記載の方法。
【請求項１２】
ステップａにおいてＬＳＰの故障が確定されたら、
当該故障ＬＳＰの所属するリソース制御機能エンティティは故障ＬＳＰのリソースの利用可能状態を更新することを更に含むことを特徴とする請求項１に記載の方法。
【請求項１】
エンド・ツー・エンドのサービス品質の信頼性の保証を実現する方法であって、
ａ．故障が発生するラベルスイッチパスＬＳＰがあるかどうかを検知・判断する、なければ、ステップａに戻り、あれば、ステップｂを実行するステップと、
ｂ．前記故障ＬＳＰにバックアップＬＳＰがあるかどうかを判断し、バックアップＬＳＰがあれば、エッジルータ又は転送ルータは一定のポリシーにより、現在の故障ＬＳＰ上にベアされたサービスフロー及び相応のリソースを当該故障ＬＳＰのバックアップＬＳＰ上に切換え、バックアップＬＳＰがなければ、リソース制御機能エンティティは現在のトポロジーにより、現在故障ＬＳＰ上のサービスフローに新しいＬＳＰを配置して、故障ＬＳＰ上のサービスフローを新しく配置されたＬＳＰ上に切換え、サービスフローを切換える前に占用されたパスリソースを解放するステップとを含むことを特徴とする方法。
【請求項２】
ステップａにおいて、前記検知は、エッジルータ又は境界ルータが自体を経由するＬＳＰに故障が発生するかどうかをリアルタイム的に検知することであり、
故障が発生したら、ステップａは、
エッジルータ又は境界ルータは故障ＬＳＰの情報を自体の所属するリソース制御機能エンティティに報告し、リソース制御機能エンティティは報告された情報により故障ＬＳＰのリソースの利用可能状態を更新することを更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
ステップａにおいて、前記検知は、リソース制御機能エンティティが管轄の全てのＬＳＰに故障が発生するかどうかを検知することであることを特徴とする請求項１に記載の方法。
【請求項４】
サービス制御機能エンティティから送信された故障ＬＳＰ上のサービスフローを含むサービスフローの解放コマンドを受信したかどうかを判断し、受信した場合、リソース制御機能エンティティとエッジルータ又は境界ルータは相応のサービスフローのリソースを解放して、リソース制御機能エンティティでの相応のＬＳＰのリソースの利用可能状態を更新し、受信しなかった場合、解放操作を実行しないことを更に含むことを特徴とする請求項１又は２又は３に記載の方法。
【請求項５】
ステップｂの後に、
前記故障ＬＳＰが非本管理域でのＬＳＰと接続されたかどうかを判断し、接続された場合、リソース制御機能エンティティは新しいサービスＬＳＰの情報をベアラ接続制御シグナリングを通して相手の管理域での関連ＬＳＰの所属するリソース制御機能エンティティに通知して、相手のリソース制御機能エンティティの確認を獲得することを更に含むことを特徴とする請求項１又は２又は３に記載の方法。
【請求項６】
ステップｂにおいて、前記ポリシーは、サービスフローのクィンタプレッツ、サービスフローのサービスパスラベルスタックを含むことを特徴とする請求項１又は２又は３に記載の方法。
【請求項７】
リソース制御機能エンティティは故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新してから、更新後の現在故障ＬＳＰ上にベアされた全てのサービスフローのサービスパスラベルスタックをエッジルータ又は境界ルータに送信し、或いは、ルーティング設備が制御コマンドにより故障ＬＳＰ上にベアされた各サービスフローのサービスパスラベルスタックを更新することを更に含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記更新とは、選定されたバックアップＬＳＰ又は故障ＬＳＰに再配置された新しいＬＳＰのラベル値で元の故障ＬＳＰのラベル値を取り替えることであることを特徴とする請求項７に記載の方法。
【請求項９】
ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置する時、リソース制御機能エンティティとエッジルータ又は境界ルータとの間で共通オープンポリシーサービスインターフェイスプロトコルを採用することを特徴とする請求項１又は２又は３に記載の方法。
【請求項１０】
ステップｂにおいて、前記リソース制御機能エンティティが新しいＬＳＰを配置することは、リソース制御機能エンティティはルーティングマトリックステーブルを使って故障ＬＳＰ上のサービスフローが同一管理域での等価パスを計算することであることを特徴とする請求項１又は２又は３に記載の方法。
【請求項１１】
予めＬＳＰに一本或いは一本以上のバックアップＬＳＰを設置し、設置されたバックアップ関係をリソース制御機能エンティティに記録・保存することを更に含むことを特徴とする請求項１に記載の方法。
【請求項１２】
ステップａにおいてＬＳＰの故障が確定されたら、
当該故障ＬＳＰの所属するリソース制御機能エンティティは故障ＬＳＰのリソースの利用可能状態を更新することを更に含むことを特徴とする請求項１に記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００８−５０３１１７（Ｐ２００８−５０３１１７Ａ）
【公表日】平成２０年１月３１日（２００８．１．３１）
【国際特許分類】
【出願番号】特願２００７−５１５７６５（Ｐ２００７−５１５７６５）
【出願日】平成１７年６月１４日（２００５．６．１４）
【国際出願番号】ＰＣＴ／ＣＮ２００５／０００８４８
【国際公開番号】ＷＯ２００５／１２２４７２
【国際公開日】平成１７年１２月２２日（２００５．１２．２２）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
【公表日】平成２０年１月３１日（２００８．１．３１）
【国際特許分類】
【出願日】平成１７年６月１４日（２００５．６．１４）
【国際出願番号】ＰＣＴ／ＣＮ２００５／０００８４８
【国際公開番号】ＷＯ２００５／１２２４７２
【国際公開日】平成１７年１２月２２日（２００５．１２．２２）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
[ Back to top ]