JP5194021B2 - 復旧方法及びサービス予約システム - Google Patents

Description

本発明はネットワークの技術分野に関連する。

本発明は障害後におけるネットワークサービス予約システムの復旧方法に特に関連する。本方法はループフリーネットワーク（ｌｏｏｐ ｆｒｅｅ ｎｅｔｗｏｒｋ）にも関連し、ループフリーネットワークの場合、ネットワークの２点間を結ぶ固有のパスが存在し、その固有のパスは、ネットワークのトポロジが変わる場合にのみ変更される。本発明では、サービス予約システムは、セントラル化されたシステムであり、そのセントラル化されたシステムは、ループフリーネットワークの２点間のネットワーク経路におけるサービスを保証する。

従来のシステムは、ネットワーク障害が起こり得ることを充分に考慮していない、ということが多々見受けられる。障害が起こった場合、予約システムは「故障（ｃｒａｓｈ）」の被害を被り、平常の状態に復帰しない。

従来、既に、ネットワーク上のリンクを復元する方法及びシステムが知られており、その方法及びシステムは、ネットワーク上の２点間でデータ伝送をやり直す。

ループネットワークの場合、ネットワークの２点間に１つのパス（経路）が存在する。したがってネットワーク障害は、その障害地点におけるデータ伝送を遮断してしまう。そのトラフィックは、ループフリーネットワークでルーティングし直すことができない。データを伝送するリンクをネットワークが再構築すれば、そのトラフィックを回復できる。これは、ネットワーク装置を追加することで、又はスパニングツリープロトコル（ＳＴＰ： Ｓｐａｎｎｉｎｇ Ｔｒｅｅ Ｐｒｏｔｏｃｏｌ）が行うようなプロトコルを介して、「手作業で（ｍａｎｕａｌｌｙ）」実行可能であり、ＳＴＰは、既に非活性な冗長リンクを探し、ループフリーネットワークを形成する。データ伝送を再構築するこの方法は現在有効であり、本発明の対象ではない。

セントラル化されたシステムがサービス予約システムを管理する場合であって、そのサービス予約システムが、サービスへのアクセスを制御し、且つ要求されたアクセスを保証する場合、システムは、ネットワークにおける予約状態（ｔｈｅ ｓｔａｔｕｓ ｏｆ ｔｈｅ ｒｅｓｅｒｖａｔｉｏｎ）を更新している。ネットワーク障害が発生すると、ネットワークのトポロジが修正され：あるネットワークノードは禁止になり、あるリンクのサービス品質は劣化し、あるいはネットワークの部分全体が見えなくなってしまうことさえあり得る。同様に、新たな要素が、特にネットワーク障害後に登場する可能性があり：ネットワークノードが追加され、新たなリンクが登場し、あるいはリンクのサービスが改善することさえあり得る。

ネットワーク障害が起こった場合、サービス予約に関する情報はもはや首尾一貫していない（ｃｏｈｅｒｅｎｔでない）、例えば、消失したネットワークの部分についてサービスが予約されていたようなことが起こり得る。この場合、サービス管理にとって或る内部の手段を設け、情報（より一般的にはサービス管理）を再び首尾一貫したものにするようにする必要がある。

従来技術については例えば特許文献１に記載されており、これは、ＷＤＭ（波長分割多重化）プロトコルによる光通信ネットワークにおいて、データバースト損失が生じた場合にリソースを復旧する方法及びシステムに関する。この米国特許出願は、ネットワーク装置各々のレベルで共有されるリソースの予約を行う手段に関し、その手段を分散したアーキテクチャで実現することを説明している。この従来技術の文献は、コアネトワーク機器の少なくとも１つにおいて、分散アーキテクチャが障害を検出した場合、通信を拒否及び／又は禁止する手段を紹介している。この米国特許出願で使用されているアーキテクチャは、全く分散したものであり、トポロジのセントラル化された情報を当てにしていない。この従来システムの制御／指図は、システムデータの通信だけに起因する波長を使用する。

米国特許出願公開第２００５／００６３７０１号明細書

本発明は、ループフリーネットワークのサービスマネジャに復帰できるようにする、マネジャの内部処理に関する方法を提案することで、従来の欠点を克服しようとしている。

本発明は、トポロジの一括管理により、設定されたリソース予約を回復させるセントラル化された手段に関連する。トポロジマネジャが変化を検出すると、トポロジマネジャは、以前に設定されているリソースの予約に対して、その新しいトポロジにより生じるおそれのある衝突／障害を検出したことを、リソースマネジャに通知し、且つ関連するノードに連絡をとることで又はシステムユーザに警告することで衝突／障害に自動的に対処する。本技法の制御／指図（コマンド）は、固有の識別子（アドレス、ポート番号等）を使用する波家とモードプロトコルを使用することに留意を要し、その識別子はこれらのパケットのやりとりに基づく。

ストリームが予約されている様子を示す図。 サービスユーザがネットワークの利用を止めた様子を示す図。 予約された様々なストリームを伴うネットワーク例を示す図。 図３のネットワークにおいてあるスイッチが故障している場合の様子を示す図。 図４のネットワークでトポロジを再構築した様子を示す図。 本発明方法による様々なステップを示す図。

本発明はセントラル化されたトポロジ情報に基づいているが、ＵＳ２００５／００６３７０１のアーキテクチャは完全に分散している。

上記課題に対処するため、本発明は、最も広義に受け入れられている意味において、障害のあったサービス予約システムの復旧方法に関連し、その方法は、障害に起因してサービス予約システムにとってもはや明確でなくなった少なくともいくつかの予約を無効にする第１ステップと、サービス予約システムにとってもはや明確でなくなった予約を算出し直す一方、障害後のネットワークトポロジで有効な予約を有効化し、障害後のネットワークトポロジで無効な予約を取り消す第２ステップとを有する。

有利なことに、本方法は、ネットワークノードがサービス予約システムから見えなくなる期間における方法である。

特定の形態では、所定の遅延期間の満了後に、サービス予約システムでノードが見えなくなることが起こる。

好ましくは、外的な操作が、インアクティブな予約に関わる要素を非活性化する。

変形例によれば、外的な操作は、手動によるものである。

別の変形例によれば、外的な操作は、外部モジュールによるものである。

本発明はネットワークサービス予約システムにも関連し、当該システムは、
・障害に起因してサービス予約システムにとってもはや明確でなくなった少なくともいくつかの予約を無効にする手段と、
・サービス予約システムにとってもはや明確でなくなった予約を算出し直す手段と、
・障害後のネットワークトポロジで有効な予約を有効化する手段と、
・障害後のネットワークトポロジで無効な予約を取り消す手段と
を有する。

本発明は、添付図面を参照しながら、一例として示される以下の実施例の説明からさらに理解されるであろう。

本発明による方法はループフリーネットワークに適用され、ループフリーネットワークの場合、所与の時点において、ネットワークの２点間を結ぶ固有のパスが存在し、その固有のパスは、ネットワークのトポロジが変わる場合にのみ変更される。本発明では、ネットワーク障害は、ネットワークトポロジにおける変化であって、１つ以上のネットワークリンクを完全に使用不可能にする又は徐々に劣化させる変化を意味する。本発明では、サービス予約システムは、セントラル化されたシステムであり、そのセントラル化されたシステムは、ループフリーネットワークの２点間のネットワーク経路におけるサービスを保証する。

本発明の場合、サービスマネジャはあるエンティティに基づいており、そのエンティティは、サービスマネジャが管理しているネットワークトポロジの現状を提供することができる。

有利なことに、本発明による方法はあるシステムで使用され、該システムは、
・ループフリーネットワークと、
・ネットワークノードに設けられたセントラル化されたサービスマネジャと
を有する。

サービス予約は、ネットワークノード間のパスで行われる。サービスマネジャと、サービス予約リクエストを送るネットワーク機器群との間の通信トラフィックは、最高の優先度を有する。

サービス予約メッセージにはいくつかのタイプがあり、そのいくつかは次のようなものである：
・新たなせービス予約、及び
・サービス予約の解放。

サービスマネジャは、許可されたサービス予約のリストを保持する。このリストは、次のような形式をとってもよい：

サービス申込者は、そのサービスを利用する２つのネットワークノード以外でもよい。

あるイベントが、サービス予約システムを不安定にするおそれがある。

サービスユーザがネットワークを止める場合、そのユーザは、ネットワークを止める前に総てのサービス予約を解放する必要がある。

図１に示されるカメラ（サービスユーザ）は、監視を行うため、帯域マネジャに帯域の予約を要求している。この予約は許可されており、ネットワークは適切に動作している。データ通信はスイッチＳ２を介して行われる。

図２では、サービス予約を解放せずに、カメラはネットワークの利用を止めている。この場合、その予約を帯域マネジャはまだ考慮しているが、帯域の利用は実際にはない。

サービスマネジャは、そのトポロジに関し、サービスユーザはもはやそこに存在しないことを理解し、及び以下の２つの筋書き（シナリオ）を予測できる：
・サービスユーザは活動を終了し、そのサービスの利用をもはや希望していない。この場合、サービスマネジャはその予約を解放しなければならない。

・あるいは、サービスユーザがある問題に遭遇し、しばらくユーザの活動を継続できないが、後に活動を再開することを希望している。この場合、サービスマネジャは予約を解放できない。

何れの場合も、サービス予約を解放するよう決定可能である：サービスを再利用するには、サービスユーザは、新たなサービス予約リクエストを実行しなければならない。但しこのようにすると問題が生じる。サービスユーザがネットワークの利用を止めた後復帰し、ユーザが自身のサービス予約がまだ有効であると考えている場合である。この場合、（そのサービスの）ユーザは、予約されていないサービスを利用しようとしてしまう。

上記の例の場合、図２のカメラは、リンクがもはや有効でないことを検出できず、したがって、リンクが再構築された場合でも、帯域が予約されていることを想定しながら、依然としてトラフィックを送信しようとする。

以下においては、サービスユーザはネットワークの障害の可能性に気付いていないことが考えられる。これは、サービスユーザがネットワークの利用を止めようとする場合、ユーザは、ネットワークの利用を止める前に自身のサービス予約総てを解放しなければならないことの理由である。

以下の例では、ネットワーク障害は、ネットワークトポロジを修正することで修復される。この修正は、予約同士の間で競合（コンフリクト）を引き起こす。

この場合、サービスは帯域である。サービスマネジャにより管理されるサービスの他の例は、例えば次のようなものである：
・電話サービス：このサービスは、回線接続の開設である。サービスの量（定量化）は、リンク上で認められている接続数で表現されてもよい。サービスの劣化は、認められている接続数の減少になり得る。

・オンデマンドビデオサービス：このサービスは、サーバから視聴者へビデオを提供することである。サービスの量（定量化）は、ビデオの品質で表現されてもよい。サービスが劣化している場合は、サーバがビデオを提供し続けてはいるが低品質であるような場合である。

・道路の保証時間（Ｇｕａｒａｎｔｅｅ ｔｉｍｅ ｏｆ ａ ｒｏａｄ ｐａｔｈ）：このサービスは、ある地点から別の地点へ向かう経路の時間を提供する。サービスの定量化は、道路網の混雑状態で表現されてもよい。サービスの劣化は、交通渋滞が生じた場合に生じ得る。

・パッケージ転送サービス：このサービスは、荷物（パッケージ）が或る街から別の場所へ移送されることを保証する。サービスの定量化は、２つの街の間で転送される荷物の数で表現されてもよい。サービスの劣化は、２つの街の間で転送される荷物の最大数の減少になり得る。

目下の実施例の場合、リンクは概して１００Ｍｂｐｓのイーサーネットであるが、スイッチ３及び４の間では１Ｇｂｐｓである。

本発明は帯域幅に限定されない：本発明は、ループフリーネットワークの２点間において、例えば上記のように、他のサービスタイプに適用されてもよい。

図３に示されるネットワーク例の場合、カメラ４からモニタ４へ、カメラ３からモニタ３へ、カメラ２からモニタ２へ及びカメラ１からモニタ１へ、帯域マネジャにより、予約ストリームが許可されている。

サービスマネジャの（帯域幅）管理テーブル例は次のようなものである。

図６には本発明の実施例による方法の様々なステップが示されている。この図６は、リンク又は機器アイテムの完全な障害の際に予約を復旧する動作を表す。

（完全な障害ではなく）リンク又は機器アイテムで徐々に進行する品質劣化に対処する方法については、後述される。

Ａ−完全な障害
この図で示される状態図は、予約の処理を表す。上記の例の様々な予約（表２）は、「有効」
とあるので、初期状態になっていることが分かる。

次に、スイッチ５が故障する。サービス／帯域幅マネジャは、ネットワークの左側（スイッチ１、スイッチ２、スイッチ３、スイッチ４、モニタ１、モニタ２及びカメラ１）を見るだけになる。図４にはスイッチ５が故障している様子が示されている。

サービス／帯域幅マネジャは、ネットワークトポロジから部分的に失われた総ての予約を管理テーブルから削除することを選択し、その結果、予約１が残るのみである。しかしながら、この判断はある問題をかかえている。すなわち、予約４は依然として有効であり、それ故に、ネットワークが修復された場合、この予約は除去されるべきではない（常に有効だったからである）。したがって、予約は無効になる可能性があるが、まだ未確認であることを表現するため、「有効（Ｖａｌｉｄ）」の値は、「待機（Ｉｎ Ｓｔａｎｄｂｙ）」に変更される必要がある。状態マシンにおける予約２，３及び４（図６）は、「待機」状態を通過する。予約１のリンクは消失していないので、その状態は「有効」のまま残る。

したがって、どの予約エントリもサービスマネジャのテーブルから削除されるべきではない。

サービスマネジャのテーブルは次のようになる。

スイッチ５に到着する総てのストリームは、スイッチ２にルーティングされていた。現在「待機」状態の予約ソース／宛先の総てがネットワークで再び現れている。状態マシンで図６に示されているように、予約２，３，４は「復旧（Ｒｅｓｔｏｒａｔｉｏｎ）」の状態に進む。この状態は、「有効性（Ｖａｌｉｄｉｔｙ）」の値を「復旧」にする。

図５には、ネットワークトポロジを再構築した様子が示されている。

サービスマネジャが、サービス予約に関わっているネットワーク要素を再び発見した場合、サービスマネジャは、「復旧可能な（ｒｅｓｔｏｒａｂｌｅ）」予約の総てを復旧する必要があり、復旧可能な予約は、２つのネットワークノード及びパスがその現在のネットワークのトポロジに存在している予約である。当然に、２つのネットワークノード又はパスが存在しなかった場合、その予約についての処理を実現することはできない。

２つのネットワークノード及びパスの消失後に検出された「復旧可能でない（ｎｏｎ−ｒｅｓｔｏｒａｂｌｅ）」予約は、確定的なものと考えられる。この確定的な属性は、再現遅延（ｒｅａｐｐｅａｒａｎｃｅ ｄｅｌａｙ）を用いて確認可能である。この消失の確定的な属性が検出される以前では、「復旧可能でない」予約は、「待機」状態のままである。

「復旧可能でない」予約に適用される本方法については後述される。

復旧の第１ステップは、「復旧可能な」予約総ての処理である。サービスマネジャは、有効である予約を正当化しなければならず、且つ不可能な予約を削除しなければならない。

そして、スイッチ６はサービスマネジャから確認可能であり、予約４は、パスが故障以前と同じであるという事実に起因して再度正当化される。トポロジが再構築された後、帯域幅は依然として利用可能である。したがって、予約４に関する状態マシンは「有効」状態に戻る。「有効性」の値は、「有効」に戻される。

予約３の場合、ソース及び宛先の間にパスが依然として存在している。違いは、ストリームがスイッチ５を介するのではなく、スイッチ２を介して進行する点である。予約４の場合と同様に、予約３は再び正当化される。その状態マシンは「有効」状態に戻り、「有効性」の値は、「有効」に戻される。

サービスマネジャのテーブルは現在次のようになっている。

予約２は、「不可能な（ｉｍｐｏｓｓｉｂｌｅ）」予約であるという問題を含んでいる。サービスマネジャが解放要求をカメラ２に送信したとしても、カメラ２は、ネットワークに接続する前にそれを受信していない。したがって、サービスマネジャからの解放要求を受信する前に、カメラ２は、新しいネットワークトポロジでストリームを送信してしまうおそれが多分にある。この場合、スイッチ２及びスイッチ４間における１００Ｍｂｐｓのリンクは、８０Ｍｂｐｓのストリーム２つをサポートすることはできない。したがって、（予約１と予約２の）２つのストリームは適切には伝送されない。トポロジの再構築前にスイッチ５の不具合の影響を被っていなかった予約１についてのサービスが、もはや保証されなくなってしまう。

不可能な予約は、新たなネットワークトポロジで保証することが不可能な「復旧可能な」予約である。これらの予約は「失敗（Ｆａｉｌｅｄ）」状態と記される必要がある。

この例の場合、サービスマネジャのテーブルは次のようになる。

次のステップは、「失敗」状態と記された予約の解放を要求し、サービス予約システムの首尾一貫した（ｃｏｈｅｒｅｎｔ）処理を行うようにすることを含む。

目下の例の場合、予約１が存在することに起因して、スイッチ２及び４間のリンクにおいて予約をサポートできないので、サービスマネジャは、予約２について解放を要求する必要がある。予約２の解放が実行されると、予約マネジャはテーブルからその予約を削除する。サービス予約システムは再び首尾一貫したものとなり、テーブルは、「待機」状態や「失敗」状態の予約をもはや含んではいない：サービス予約が再び保証される。

この例の場合、サービスマネジャのテーブルは次のようになる。

サービス予約システムを復旧する第２ステップは、予約が「復旧可能でない」ことを有効にすることである。この状況では、サービス予約に関するいくつかのノードがネットワークトポロジに復帰していない。

この見えなくなったことが確定的であると考えられる場合、予約のマシン状態は、「復旧可能でない」状態に移る。この場合、サービスマネジャにより自動的には処理できない。

図６には、本発明による方法の様々なステップが示されている。

外的な判断は、これらの予約を解放する必要がある。本発明における外的判断（ｅｘｔｅｒｎａｌ ｄｅｃｉｓｉｏｎ）は、そのサービスタイプについて重要度の高いコマンドや多くの情報を有する個々の人物又はモジュールによる判断として理解され、以下のステップを管理できるようにする：
１．２人のサービスユーザがネットワークに再び接続する前に、彼らが自身のサービス予約の利用を解放していることを保証すること。

２．サービスマネジャのレベルで予約を取り消すこと。

「外的判断」は、解放される予約に関与する様々な装置情報の首尾一貫性を保証しなければならない。

Ｂ−劣化が進行する場合
本発明による方法を利用して、ネットワーク障害後に予約システムを復旧することができる。このような障害は、本発明では、リンクや機器アイテムの完全な不具合だけでなく、リンクや機器アイテムの劣化が徐々に進行する場合も含む。

このような徐々に進行する劣化の場合、サービスを保証する手段をネットワークが徐々に失ってゆき、許可されたサービス予約をもはや保証できない状況に至ってしまうことが、管理可能である。

サービスマネジャは、サービス予約時点におけるネットワーク状態に基づいて、サービス予約を保証する。ネットワークの状態が時間と共に変化するにつれて、サービス予約に必要ないくつかのパラメータが劣化を示すようになる。この時点以降に問題が生じ、これらのパラメータの劣化は、ネットワークリンクにおける目下のサービスをもはや保証できないという重要情報を示す。

以下の２つの理由から、ネットワークの劣化は、完全なネットワーク障害の場合とは異なって処理される必要がある：
・劣化は徐々に進行するので、予約が「失敗」状態に陥る前に確認可能である。これは、劣化に対処するように外的判断がなされることを可能にする。

・この場合、ネットワーク障害は克服可能である。サービスマネジャとサービス予約の申込者との間に依然としてネットワーク接続が存在するので、この場合は「有効化可能な（ｃａｎ ｂｅ ａｃｔｉｖａｔｅｄ）」場合である。

要求されたパラメータがネットワークトポロジに関するパラメータであった場合、サービスマネジャは、劣化が進行していることを検出し、サービス予約に関する２つのノードにその劣化を通知する。

ネットワークの劣化が非常に深刻になり、予約が「失敗」状態に陥る場合、サービス予約システムは、その「有効化可能な」予約を復旧する。ネットワークリンクが完全な失敗状態に陥ってない限り、管理トラフィックは最高の優先度を有するので、管理トラフィックはリンクを伝送する。サービスマネジャとアプリカント（申込者）との間の通信は、次のようなものである：
・サービスマネジャが、「失敗」のサービス予約を解放するリクエストを送信する。申込者はこのリクエストを拒否できない。

・申込者は、サービス予約を解放し、サービス予約の利用を中断し、その予約が解放されたことを示す解放メッセージを送信する。

・サービス管理者は、内部の管理テーブルを更新する。

劣化によるサービス予約の障害の後、サービス予約システムは復旧する。

本発明は一実施例と共に説明されてきた。当業者は、本発明の範囲から逸脱せずに、本発明の変形例を認識できるであろう。

Claims (7)

1. セントラル化されたサービス予約システムによりループフリーネットワークの障害を検出した後に該ループフリーネットワークにおいて該セントラル化されたサービス予約システムを復旧させる方法であって、
   前記障害に起因して前記サービス予約システムにとってもはや明確でなくなった少なくともいくつかの予約を無効にする第１ステップと、
   前記サービス予約システムにとってもはや明確でなくなった予約を算出し直す一方、前記障害の後のネットワークトポロジで有効な予約を正当化し、前記障害の後のネットワークトポロジで無効な予約を取り消す第２ステップと、
   前記障害の後に前記ネットワークトポロジで保証することができない復旧可能でない予約を検出する第３ステップと
   を有する方法。
2. 前記第３ステップにおいて、前記サービス予約システムにとってもはや明確でなくなった少なくとも１つのネットワークノードを検出する、請求項１記載のサービス予約システムを復旧させる方法。
3. 所定の遅延時間を利用して、前記サービス予約システムにとってもはや明確でなくなった少なくとも１つのネットワークノードを検出する、請求項２記載のサービス予約システムを復旧させる方法。
4. 前記障害の後に前記ネットワークトポロジで無効な予約に関わる前記ループフリーネットワークのネットワークノードを、外的な操作により非活性化する、請求項１ないし３の何れか１項に記載のサービス予約システムを復旧させる方法。
5. 前記外的な操作は、ユーザにより手動で行われる、請求項４記載のサービス予約システムを復旧させる方法。
6. 前記外的な操作は、外部モジュールにより行われる、請求項４記載のサービス予約システムを復旧させる方法。
7. 障害に起因してサービス予約システムにとってもはや明確でなくなった少なくともいくつかの予約を無効にする手段と、
   前記障害の後に、前記サービス予約システムにとってもはや明確でなくなった予約を算出し直す手段と、
   障害の後のネットワークトポロジで有効な予約を正当化する手段と、
   障害の後の前記ネットワークトポロジで無効な予約を取り消す手段と、
   前記障害の後に前記ネットワークトポロジで保証することができない復旧可能でない予約を検出する手段と
   を有する、セントラル化されたループフリーネットワークのサービス予約システム。

Images