JP2009514478A - インタードメインＱｏＳ予約確立および修正 - Google Patents

Abstract

第１のドメイン内の第１のノードとさらなるドメイン内のさらなるノードとの間のインタードメインＱｏＳ予約を確立および修正するための資源管理装置ノードおよび方法。少なくとも１つのＱｏＳ特性をもつＱｏＳ予約が必要とされていること、またはかかるＱｏＳ予約がリフレッシュされるのを必要としていることを検出した後、第１のドメインとさらなるドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を、第１のノードにおいて取得すること。その後、少なくとも１つのＱｏＳ特性の観点から第１のドメインと第２のドメインとの間のパスの少なくとも１つの選択を決定すること、およびＱｏＳ予約を支援するためのパスを選択すること、およびインタードメインＱｏＳ予約の確立を始動させる予約メッセージを送信すること。
【選択図】図１

Description

本発明は、パケットトラフィックに対するサービスの質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：ＱｏＳ）に関し、より具体的には、自律システム（Ａｕｔｏｎｏｍｏｕｓ Ｓｙｓｔｅｍ：ＡＳ）とも呼ばれるサブネットワークを１つより多く通過するパケットトラフィックに対するＱｏＳ保証の確立および修正に関する。

現在、全面的インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＩＰ）通信への傾向がある。しかし、トラフィックを先入れ先出し（ｆｉｒｓｔ‐ｉｎ ｆｉｒｓｔ‐ｏｕｔ：ＦＩＦＯ）法で節約するベストエフォートパラダイム（ｂｅｓｔ ｅｆｆｏｒｔ ｐａｒａｄｉｇｍ）に、ＩＰは基づいてきた。問題は、時間に影響を受けやすいサービスが最低限のサービスの質（ＱｏＳ）の保証を必要とするという事実にある。この問題を処理するために、多くの解決方法が開発された。結局すべて、ＩＰネットワークの資源活用を最適化する一方、ＩＰネットワークから最良の動作を引き出すことを目的とする。かかる処理は、しばしばトラフィックエンジニアリング（ｔｒａｆｆｉｃ ｅｎｇｉｎｅｅｒｉｎｇ）と呼ばれる。ほとんどのトラフィックエンジニアリング技術は、エンジニアリングされたトラフィックが共通管理（ｃｏｍｍｏｎ ａｄｍｉｎｉｓｔｒａｔｉｏｎ）下の１つまたはいくつかのＩＰネットワーク内に留まるという仮定に基づく。しかし、時間に影響を受けやすいほとんどのサービスは、通常１つよりも多くの自律システム（ＡＳ）（現段階の研究（例、２００２年のパン・ピン（Ｐａｎ Ｐｉｎｇ）による博士論文）によると典型的には２〜８のＡＳ）におよぶであろう。かかる事実は、トラフィックエンジニアリング技術が、１つよりも多くのＡＳにわたるトラフィックを支援する必要があるということを示している。

残念ながら、インターＡＳまたはインタードメイントラフィックエンジニアリングの分野は、ほとんど研究されていない。ＩＰネットワークにおいて使用されるインタードメインルーティングプロトコルである境界ゲートウェイプロトコル（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ：ＢＧＰ）を使用することに、多くの技術が頼っている。ＢＧＰの長さは、インターネットエンジニアリングタスクフォース（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ：ＩＥＴＦ）により、リクエストフォーコメント（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ：ＲＦＣ）第１７７１番および第１７７２番に基づいて決められ、上記ＲＦＣ第１７７１番および第１７７２番を参照してここに組み入れるものとする。現行のインタードメイントラフィックエンジニアリング技術は、共通ＢＧＰパス属性を使用して、いくつかのインタードメインルートを他に優先させる。しかし、横のつながりのある各ＡＳのみでなく、エンドツーエンド全体も視野に入れたＱｏＳ保証が必要な、時間に影響を受けやすいサービスを支援するのに十分な信頼性は、現行のインタードメイントラフィックエンジニアリング技術では提供されない。さらに、現行のインタードメイントラフィックエンジニアリング技術においては、満足な解決方法のさらなる側面がいくつか与えられていない。例えば、ＱｏＳの差別化をフローごとに防止する精度（ｇｒａｎｕｌａｒｉｔｙ）が欠けている。

さらに、現行のインタードメイントラフィックエンジニアリング技術においては、満足な解決方法のさらなる側面がいくつか与えられていない。例えば、エンドツーエンドＱｏＳ割当て（ｅｎｄ‐ｔｏ‐ｅｎｄ ＱｏＳ ａｓｓｉｇｎｍｅｎｔ）の副部分（ｓｕｂ ｐｏｒｔｉｏｎｓ）に取り組むことの難易度として実際には解釈される精度が欠けている。現行のインタードメイントラフィックエンジニアリング技術においては、強固で柔軟で拡張可能な解決方法も十分に提供されてはいない。つまり、現行の解決方法は、時間に影響を受けやすい特定のサービスに関するトラフィックの増加を考慮に入れていない。さらに、ハードウェアの不具合の可能性も適切には取り合われておらず、任意のサービスインスタンスのコースの間で、時間に影響を受けやすいサービスの、保証されたＱｏＳを修正することは不可能である。

パケットがスイッチされたネットワークにおいて、単純かつ効果的な先進的構造を提供するために、現在、マルチプロトコルラベルスイッチング（Ｍｕｌｔｉ‐Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ：ＭＰＬＳ）が様々なネットワーク構成において使用されている。ＭＰＬＳのある主な特徴は、特定のラベルを使用することによる、特定のパス上での単一の通信に関係する全部のパケットにかかわることである。資源予約プロトコル（Ｒｅｓｏｕｒｃｅ ＲｅｓｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＲＳＶＰ）を使用して、ひとたびパスが確立されると、ＭＰＬＳ対応ルータは、単純に全部のパケットをそれぞれのラベルにしたがって転送しなければならない。ＭＰＬＳおよびＲＳＶＰの完全な概観は、ＭＰＬＳについてはＩＥＴＦのＲＦＣ第３０３１番において、ＲＳＶＰについてはＩＥＴＦのＲＦＣ第２２０５番、第２７５０番、および第３２０９番において得られ、以上のＲＦＣすべてを参照して、ここに組み入れるものとする。今日周知のように、典型的にＭＰＬＳは、とりわけラベル属性機構を理由に、独自に管理されるネットワークすなわち自律システム（ＡＳ）内部に配置される。インタードメインのＭＰＬＳの配置の唯一の例は、２つの異なるＡＳの２つのノードの間であり、この例は到達可能性を目的とするものであり、ＱｏＳの目的には反するものである。

了解されるとおり、複数のＡＳにわたり提供される時間に影響を受けやすいサービスの必要性を満たすであろう更新可能なインタードメイントラフィックエンジニアリングの解決方法を提供するには、現行のインタードメイントラフィックエンジニアリング技術では不十分である。

本発明の第１の側面は、第１のドメイン内の第１のノードと第２のドメイン内の第２のノードとの間のインタードメインＱｏＳ予約を確立するための方法に向けられている。第１および第２のドメインは、一連のルータを介して接続されている。少なくとも１つのＱｏＳ特性をもつインタードメインＱｏＳ予約が必要とされていることを第１のノードにおいて検出するステップと、第１のドメインに関連するネットワーク状態情報を第１のノードにおいて取得するステップと、第１のドメインと第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を第１のノードにおいて取得するステップとを、上記方法は含む。その後、少なくとも１つのＱｏＳ特性の観点から、第１のノードと第２のノードとの間のパスの少なくとも１つの選択を第１のノードにおいて決定するステップと、少なくとも１つのパス選択から、インタードメインＱｏＳ予約を支援するための選択パスを第１のノードにおいて選択するステップと、インタードメインＱｏＳ予約の確立を始動させるための予約メッセージを第１のノードから第２のノードへ向けて送信するステップとを上記方法は続けて行う。

任意で、少なくとも１つのＱｏＳ特性に関して、第１のノードと第２のノードとの間のエンドツーエンドパスの少なくとも１つの選択を第１のノードにおいて決定することによって、上記決定ステップは行われる場合がある。少なくとも１つのＱｏＳ特性に関する少なくとも１つのエンドツーエンドパス選択が存在するかどうかを決定するために、第１のドメインと第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報と、第１のドメインに関連するネットワーク状態情報を、第１のノードにおいて連結させることを、上記決定ステップは代わりに含む場合もあり、また、第１のドメインの外側にあり、第２のノードに向かう少なくとも１つのパスの各々に対するＱｏＳ値を第１のノードにおいて計算することを、上記決定ステップは潜在的に含む場合もある。

インタードメインＱｏＳ予約の最終的な確立のために資源を一時的に予約するための一時要求メッセージを、一連のルータから第１のドメインの中間ノードへ向けて、第１のノードから送信することと、第１のドメインの中間ノードから仮予約メッセージを受信することとを、第１のドメインに関連するネットワーク状態情報を取得するステップはさらに含む場合があり、上記仮予約メッセージは、第１のドメインに関連するネットワーク状態情報を含む。

同様に、インタードメインＱｏＳ予約の最終的な確立のために資源を一時的に予約するための一時要求メッセージを、一連のルータから第１のドメインの外の中間ノードへ向けて、第１のノードから送信することと、第１のドメインの外の中間ノードから仮予約メッセージを受信することとを、第１のドメインと第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を取得するステップはさらに含む場合があり、上記仮予約メッセージは、第１のドメインと第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を含む。また上記取得ステップは、既存のテーブルから、少なくとも１つのＱｏＳ特性予約に関する情報を取得することによって行われる場合もある。

予約メッセージを送信するステップは、確認要求メッセージを、第２のノードへ向けて第１のノードから送信することと、予約確認メッセージを受信することとをさらに含む場合があることを、別の任意の実施形態が示唆しており、上記確認要求メッセージは、選択パスによりルーティングされるのに十分な情報を含む。上記予約確認メッセージは、第２のノードから第１のノードへの上記予約確認メッセージのパスにインタードメインＱｏＳ予約を確立した。

さらに上記方法は、予約メッセージを送信するステップに続く特定の時間の後、予約確認メッセージが第１のノードにおいて受信されていないかどうかを決定するステップからさらに再び実行される場合もある。

本発明の第２の側面は、第１のドメイン内の第１のノードと第２のドメイン内の第２のノードとの間のエンドツーエンドパス上に維持される確立されたインタードメインＱｏＳ予約を修正するための方法に向けられている。第１および第２のドメインは、一連のルータを介して接続されている。少なくとも１つのＱｏＳ特性をもつインタードメインＱｏＳ予約がリフレッシュされるのを必要とすることを、一連のルータの中間ノードにおいて検出するステップと、中間ノードのドメインに関連するネットワーク状態情報を中間ノードにおいて取得するステップとを、上記方法は含み、また中間ノードのドメインが第２のドメインでない場合には、中間ノードのドメインと第２のノードとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を中間ノードにおいて取得するステップを上記方法は含む。その後、少なくとも１つのＱｏＳ特性に関して、中間ノードと第２のノードとの間のパスの少なくとも１つの代替選択を中間ノードにおいて決定するステップと、少なくとも１つの代替パス選択から、インタードメインＱｏＳ予約を支援するための選択パスを中間ノードにおいて選択するステップとを、上記方法は続けて行う。また、第２のノードへ向かう、インタードメインＱｏＳ予約のエンドツーエンドパスを選択パスが変える場合には、インタードメインＱｏＳ予約の確立を始動させるための予約メッセージを中間ノードから第２のノードへ向けて送信するステップを、上記方法は続けて行う。

任意で、上記方法は、検出ステップの後、第２のノードへ向かう代替パスを中間ノードが見出せることを検証するステップをさらに含む場合があり、また中間ノードが代替パスを見出せない場合には、中間ノードから第１のノードへ向けて一連のルータを通して、通知メッセージを送信するステップを、上記方法はさらに含む場合があり、通知メッセージは、少なくとも１つのＱｏＳ特性をもつインタードメインＱｏＳ予約がリフレッシュされることを必要とするということを、一連のルータのさらなるノードに認知させるのに十分な情報を含む。

インタードメインＱｏＳ予約の、一連のルータを介して第１のノードに向かうエンドツーエンドパスを、選択パスが変えない場合には、中間ノードから第１のノードへ一連のルータを介して通知メッセージを送信するステップを、上記方法はさらに含む場合もあり、上記通知メッセージは、少なくとも１つのＱｏＳ特性をもつインタードメインＱｏＳ予約がリフレッシュされるのを必要としているということを、一連のルータのさらなるノードに知らせるのに十分な情報を含む。

本発明の第３の側面は、第１のドメイン内の第１のノードと第２のドメイン内の第２のノードとの間のエンドツーエンドパス上でインタードメインＱｏＳ予約を確立および修正するための資源管理装置ノード（Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ Ｎｏｄｅ：ＲＭ）に向けられている。ＲＭは、エンドツーエンド上にあり、予約モジュールと選択計算モジュールとを含む。

予約モジュールは、少なくとも１つのＱｏＳ特性をもつインタードメインＱｏＳ予約が必要とされていること、または少なくとも１つのＱｏＳ特性をもつインタードメインＱｏＳ予約がリフレッシュされるのを必要としていることを検出し、ＲＭと第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を取得し、インタードメインＱｏＳ予約の確立を始動させるための予約メッセージを、ＲＭから第２のノードへ向けて送信する。

選択計算モジュールは、少なくとも１つのＱｏＳ特性に関して、ＲＭと第２のノードとの間のパスの少なくとも１つの選択を決定し、少なくとも１つのパス選択から、インタードメインＱｏＳ予約を支援するための選択パスを選択する。

添付図面と関連させながら、以下の詳細な説明を参照することにより、本発明のより完全な理解を得ることが可能である。

本発明は、インタードメインＱｏＳ予約の確立を最適化するため、およびすでに確立されたインタードメインＱｏＳ予約の再設定を最適化するための機構を提示する。かかる最適化を行うため、本発明は、任意のインタードメインＱｏＳ予約に沿う少なくとも１つの資源管理装置ノードの展開を提示する。必要条件として、資源管理装置ノードは、その資源管理装置ノードが一部となっているネットワークの、すなわち言い換えると、その資源管理装置ノードのＡＳの、トポロジーを認識している必要がある。インタードメインＱｏＳ予約について、資源管理装置ノードのトポロジー認識は、したがって資源管理装置ノードのＡＳ内で送信されるパケットのＱｏＳ処置を予測するために使用される。上記予測は、上記ＡＳを通して、すなわち上記ＡＳの第１の境界ルータから第２の境界ルータへ送信されるパケットのＱｏＳ処置の予測を含む。このように、資源管理装置ノードの主な役割は、上記ＡＳについて認識される様々な種類の情報を使用して、上記ＡＳを通して開始、伝送、または終着するＱｏＳ予約を最適化することである。資源管理装置ノードのこの機能性はルータに属する場合が多く、より特定すると、境界ルータに属する場合が多い。なぜなら、そのより大きなルーティングの責任を理由で、かかる機能性の設置が有利となるからである。しかし、資源管理装置ノードは、本発明の開示に影響されずに、ルーティング装置と共同設置（ｃｏ‐ｌｏｃａｔｅｄ）、または単純にルーティング装置に接続される場合もある。

その基礎構造はルータである場合が多いため、また資源管理装置ノードの目的の１つはパス予約を計算することであるため、本発明の開示は、ＩＥＴＦにおいて現在も研究が進行中の、パス計算エレメント（Ｐａｔｈ Ｃｏｍｐｕｔａｔｉｏｎ Ｅｌｅｍｅｎｔ：ＰＣＥ）の名で知られる研究の拡張として見なされ得るものである。任意のＡＳトポロジーに関する情報がＡＳ内および複数のＡＳ間をどのように循環すべきかを特定することについて、ＩＥＴＦは、参照してここに組み入れる‘ｄｒａｆｔ‐ｉｅｔｆ‐ｐｃｅ‐ａｒｃｈｉｔｅｃｔｕｒｅ‐０２．ｔｘｔ’の中で、要求‐応答プロトコル（ｒｅｑｕｅｓｔ‐ｒｅｓｐｏｎｓｅ ｐｒｏｔｏｃｏｌ）を定義することを試みている。本発明の焦点がインタードメインＱｏＳ予約にあることと比べ、‘ｄｒａｆｔ‐ｉｅｔｆ‐ｐｃｅ‐ａｒｃｈｉｔｅｃｔｕｒｅ‐０２．ｔｘｔ’という文書は、ＰＣＥアーキテクチャ（フレームワーク）のための構築ブロックの組を提供することを主に目的とする。ＩＥＴＦからのさらなる文書‘ｄｒａｆｔ‐ｉｅｔｆ‐ｐｃｅ‐ｃｏｍｍ‐ｐｒｏｔｏｃｏｌ‐ｇｅｎ‐ｒｅｑｓ‐０２．ｔｘｔ’は、技術的解決方法が未だ提供されていない要求をリストにしている。以下の説明は、包括的になされるものであるが、さらに、読者がＰＣＥの観点から読まれることを推奨する。ゆえにＰＣＥは、以下の説明において１つの代替として言及される場合が多い。しかし、ＰＣＥの厳密な観点から実施形態の詳細に言及していなくとも、関係する開示がＰＣＥには適用できないという意味ではない。

図１は、本発明の開示によるネットワーク１００トポロジーの一例を示している。図１は、ＡＳ１ １１０、ＡＳ２ １２０、ＡＳ３ １３０、ＡＳ４ １４０、ＡＳ６ １６０の６つの自律システムを示している。境界ルータおよび資源管理装置ノード（ＲＭ）のみがＡＳ１１０〜１６０に相互に接続されているように示されているが、それは本発明の開示が境界ルータおよび資源管理装置ノードを改善することを主な目的としているためであり、境界ルータと、示される各種ノードによって提供されるＲＭ機能とを使用するノードをＡＳがさらに含む場合も多いということを了解されたい（さらなるノード例として、中間ルータ、端末ノード、サービスノード、データベースノードなどがある）。境界ルータは、その境界ルータが属するＡＳと他のシステム（例えば図１に示されている他のＡＳがあるが、第３の団体のサービスプロバイダや単一ノードなどでも良い）との接続を可能にする。境界ルータとしても動作するＡＳ１ １１０は、ＲＭ１１ １１１およびＲＭ１２ １１２の２つのＲＭを含む。ＡＳ２ １２０は、１つの境界ルータＡＳＢＲ２１ １２１と、ＲＭ２２ １２２およびＲＭ２３ １２３の２つのＲＭとを含み、ＲＭ２２ １２２は、境界ルータとしても動作する。ＡＳ３ １３０〜ＡＳ６ １６０はそれぞれ、ＲＭ３１ １３１およびＲＭ３２ １３２、ＲＭ４１ １４１およびＲＭ４２ １４２、ＲＭ６１ １６１およびＲＭ６２ １６２の、境界ルータとしても動作する２つのＲＭを含む。さらに様々なリンクが、それぞれのＡＳの中の様々なノードと接続しているように示されている。リンクの種類およびそのリンクから生じる関係する接続は、本発明の開示に影響を与えるものではないことを了解されたい。（例えば、地理的な近接性またはサイト間のネットワーク化の必要性に基づき、）図１に太い黒線で示されているように、ＡＳ１１０〜１６０は、適切ならばＡＳ１１０〜１６０のそれぞれの境界ルータを通したインタードメインリンクを介して、さらに相互接続される。相対的に、図１の点線は論理接続を表しており、論理接続では中間ノードが提示される場合が多い。資源管理装置の機能性はＲＭ１１１〜１６２内にしか示されていないとしても、資源管理装置の機能性は、（図１には明示されていない）ＲＭと共同設置される場合、または、（図１には明示されていない）リンクまたはＡＰＩ（例えば、リモートプロシージャコール（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ：ＲＰＣ）、共通オブジェクト要求ブローカアーキテクチャ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ：ＣＯＲＢＡ）インターフェースなど）の組を介してＲＭに使用可能とされる場合があることにも留意されたい。以下の説明において、ドメインおよびＡＳという言葉が、１つの管理統一体（Ａｄｍｉｎｉｓｔｒａｔｉｖｅ ｅｎｔｉｔｙ）によって管理されるネットワークまたはサブネットワークという単一の概念を指す。

図２は、第１のＡＳ内の第１のノードから端末ＡＳ内の端末ノードとの間でＱｏＳ予約を確立するための、本発明の開示による資源管理装置ノード（ＲＭ）によって使用可能である第１のアルゴリズムの一例を示す。このアルゴリズムは、安定状況（例えば、未処置要求がないなど）のもと、ＲＭにおいて開始する（ステップ２１０）。その後、端末ドメインの端末ノードへ向かうインタードメインＱｏＳ予約の確立を（例えば、端末ドメインを通して到達可能な目標ノードと接続するために）必要とする事象（ステップ２１２）に関する必須情報を、ＲＭは検出または受信する。同ステップの間に、ＲＭは、インタードメイン予約によって要求される少なくとも１つのＱｏＳ特性に関連する。このような応答を引き起こし得る多くの事象の中でも、例としては、インタードメイン予約の影響に対するさらなるＲＭからの特定のメッセージの受信（すなわち、上記ＲＭは、インタードメインＱｏＳ予約に関する中間ＲＭである）、インタードメイン予約の影響に対する終端ノードからの特定のメッセージの受信、さらなるドメインへ向かうパケットの受信、トラフィックロード（ｔｒａｆｆｉｃ ｌｏａｄ）の既定条件の発生などが挙げられる。ＱｏＳ特性の例には、必要な最小帯域幅、最大遅延または遅延ジッタ耐性、最大欠損レート耐性などが含まれる。この時点で、ＲＭは、インタードメインＱｏＳ予約のために、自身のまたは現在のＡＳ内の少なくとも１つのサブパスを計算するのに必要な全部の情報をもっているかどうか決定する（ステップ２１４）。本文脈において、必要な情報とは、様々な種類のネットワーク状態情報に含まれ、少なくとも必要なＱｏＳ特性の観点から評価されるものである。必要な情報は、既存のネットワーク管理システム（例えば、簡易ネットワーク管理プロトコル（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ：ＳＮＭＰ））、知的財産権を有する要求‐応答プロトコル、受動的なプッシュ型プロトコル（ｐａｓｓｉｖｅ ｐｕｓｈ‐ｔｙｐｅ ｐｒｏｔｏｃｏｌ）、または能動的なプル型プロトコル（ａｃｔｉｖｅ ｐｕｌｌ‐ｔｙｐｅ ｐｒｏｔｏｃｏｌ）などを通して取得可能である。必要な情報の例として１つ、現在のＡＳの各境界ルータのための、少なくとも１つのＱｏＳ特性をリストするテーブルがある。このように、ステップ２１４は、本発明を達成する場合もあるが、必ずしも達成する必要がない場合もある（すなわち、プッシュ型プロトコルの場合には必ずしも必要ではない）。ＲＭは、全部の情報はもっていない場合、必要な情報を全部そろえるために、現在ＡＳ内から情報を要求する（ステップ２１６）。以上のステップの後、ＲＭは現在のＡＳに関するネットワーク状態情報を（能動的にまたは受動的に）取得したと言える。

ここから、ＲＭは、現在のＡＳにおけるインタードメインＱｏＳ予約のために資源を予約するために動作すると決める場合がある。このような場合、ＲＭは、上述の既存のテーブルの中で、インタードメインＱｏＳ予約のために最良サブパスを検証する（ステップ２１８）、またはインタードメインＱｏＳ予約のために現在のＡＳに関する少なくとも１つの最良サブパス選択を計算する（ステップ２１９）。その後ＲＭは、インタードメインＱｏＳ予約のために資源を少なくとも一時的に予約するために、適当なメッセージングを送信する（ステップ２２０）。決定を行う前に、インタードメインＱｏＳ予約についてのより多くの詳細を待つ方が有利である場合には、ステップ２１８〜２２０は回避される場合もある。例えば、インタードメインＱｏＳ予約を通して目的地点へ到達するためには、現在のＡＳのエンドツーエンドパスのうちどれが使用されるべきかを決定する前に、全エンドツーエンドパスの候補の最大数に関する必要な情報を受信した後にのみ、ステップ２１８〜２２０における予約する決定は行われる。候補の最大数は、ネットワークトポロジーに大きく依存するため、いくつになりそうなのか予測するのは困難である。例えば、候補が１つだけしか存在しないことも起こり得るし、いくつかの選択に関する情報が未だ入手されていなくとも決定が行われることも起こり得る。

その後、ＲＭは、インタードメインＱｏＳ予約のために、他のＡＳにおける少なくとも１つのサブパスを計算するための全部の必要な情報をもっているかどうかを決定する（ステップ２２２）。前と同様に、ＲＭは必要ならば情報を要求する（ステップ２２４）。ＲＭが 終端ノードがインタードメインＱｏＳ予約に関するドメイン（端末ＡＳ）に位置しているなら、ステップ２２２は必要ではない場合もある。以上のステップの後、ＲＭは、インタードメインＱｏＳ予約に（能動的にまたは受動的に）潜在的に関するその他のＡＳに関するネットワーク状態情報を取得したと言える。

ここから、ＲＭは、その他のＡＳ内のインタードメインＱｏＳ予約のために資源を予約するように動作すると決める場合がある。このような場合、ＲＭは、既存のテーブルの中で、インタードメインＱｏＳ予約のために最良のサブパスを検証する（ステップ２２６）、またはインタードメインＱｏＳ予約のために、現在のＡＳに関して少なくとも１つの最良サブパス選択を計算する（ステップ２２８）。その後ＲＭは、インタードメインＱｏＳ予約のために資源を少なくとも一時的に予約するために、適当なメッセージングを送信する（ステップ２３０）場合がある。決定を行う前に、インタードメインＱｏＳ予約についてのより多くの詳細を待つ方がより有利であるなら、ステップ２２６〜２３０は回避される場合もある。予約または予約を延期する決定の時期および場所の問題に関して、ステップ２１８〜２２０に関連して説明したものと同様の推論がここにもあてはまる。

ＲＭは、現在のＡＳに対するネットワーク状態情報と、インタードメインＱｏＳ予約のための少なくとも最良のパス選択とを取得しており、インタードメインＱｏＳ予約ための少なくとも最良のパス選択を決定または計算する（ステップ２３２）。現在のＡＳおよびインタードメインＱｏＳ予約に関する次のドメインのみから受信されるネットワーク状態情報を分析することによって、その他の関係ドメインのネットワーク状態情報の知識をもたなくとも、かかる処理は達成可能である（ソースドメインから端末ドメインへの決定権限の委託を示している）。本文脈において、最良パスは、必要なＱｏＳ特性の観点から最良の性能を提供するドメインを通して得られる。ステップ２３２は、現在のＡＳおよびインタードメインＱｏＳ予約に関する他のドメインから受信されるネットワーク状態情報を分析することによって達成される場合もあり、それにより少なくとも１つの最良エンドツーエンドパス選択が存在する（決定権限はこのようにソースドメインに維持される）。ステップ２３２において決定または計算されたパスの選択が１つよりも多く存在する場合、ステップ２３４においてＲＭは、必要または適切ならばさらなる決定基準（例えば、リンクのコスト（例えば、時間に応じたもの）、技術性能、サービスレベルアグリーメント（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ：ＳＬＡ）など）に基づき、どのパス選択を選ぶか決定する。ステップ２３４は、ＱｏＳ特性対象によっていくつか基準を変更することによって、さらなる縮小化も可能である。

その後ＲＭは、ステップ２３２および２３４の決定に基づき、インタードメインＱｏＳ予約のために資源を予約するために、適当なメッセージを送信する（ステップ２３６）。予約メッセージの送信に使用されるプロトコルの種類に依存して、その後ＲＭは、安定状態へ戻る（ステップ２１０）前に、ある最大時間、確認メッセージを待つ場合もある（ステップ２３８）。確認メッセージが全部受信されない場合、有効なシナリオを再計算するために、ＲＭはステップ２１４（または、他の確認メッセージが受信されたかどうか、およびどのノードから受信されたかに依存するさらなる中間ステップ）に戻ることに決める場合がある。確認メッセージが必要でなければ、ＲＭはステップ２３６の後２１０へ戻る。

その後インタードメインＱｏＳ予約は予約される。あるプロトコルにおいては、ルータブルフォーマット（ｒｏｕｔａｂｌｅ ｆｏｒｍａｔ）へのインタードメインＱｏＳ予約の変換の最終ステップ（例えば、ＭＰＬＳのＬＳＰラベル確立）が必要となる場合がある。しかし、必要な情報は、インタードメインＱｏＳ予約のセットアップの間に交換されるメッセージにさらに含まれる場合もある。

図３は、本発明の開示によるＲＭによって、第１のＡＳ内の第１のノードと端末ＡＳ内の端末ノードとの間のインタードメインＱｏＳ予約を修正するために使用可能である第１のアルゴリズムの一例を示す。図３について、インタードメインＱｏＳ予約が存在すると、ＲＭは安定状況にある（ステップ３１０）。それから、ＲＭは、インタードメインＱｏＳ予約がリフレッシュされるべきであることを検出する（ステップ３１２）。言い換えると、インタードメインＱｏＳ予約の少なくとも一部の再割当てを評価する必要がある。図２のステップ２１２では、検出は、事象の発生を通して起こる場合が多く、様々な形態をとることが可能である（例えば、タイマーの時間切れ、ＱｏＳ特性がもはや一致しない、リンクの不具合、新しいリンク、サブリンクのコストの変更など）。その後ＲＭは、別のパスを経由して端末ドメインに到達可能かどうかを評価可能である場合がある（ステップ３１４）。評価可能でない場合、ＲＭは、次のレベルのＲＭへ情報を送信し（ステップ３１６）、アルゴリズムを終了する（ステップ３１８）。しかし、ＲＭが、アルゴリズムのさらなるステップを完了して初めて、別のパスを経由して端末ドメインへ到達可能かどうかがわかるという可能性も同等にある。ゆえに、アルゴリズムの後の方で、ＲＭによって取得される情報がかかる決定を可能にした時はいつでも、ステップ３１８〜３２０は実行される場合がある。それ以降、ステップ３２２〜３３８は、ステップ２２２〜２３８と仮想的に同等である。確立段階に関して、前例に多くの共通点が存在するとしても、確立アルゴリズムのために行われる選択（例えば、図２のステップ２１８〜２２０に関連して説明したような決定場所および時期）は、修正アルゴリズムのために行われるものでは必ずしもないということを了解されたい。

図４は、本発明の開示による、第１のＡＳ内の第１のノードと第２のＡＳ内の第２のノードとの間のＱｏＳ予約のセットアップおよび更新の一例の、メッセージシーケンスの流れ図を示す。図４の例は、図１に示すネットワークトポロジーを参照する。ＲＭ１１ １１１は、ＡＳ６ １６０にインタードメインＱｏＳ予約の確立を望む。図４は、ステップごとに、ＲＭ１１ １１１からＲＭ６２ １６２にわたるインタードメインＱｏＳ予約決定の一端を担うＲＭ間で行われる信号送信を示す。少なくとも１つのＱｏＳ特性を維持するであろうインタードメインＱｏＳ予約をＡＳ６ １６０に確立することの必要性をＲＭ１１ １１１が受信または感知すると、この信号送信処理が開始する。ＲＭ１１ １１１およびＲＭ６２ １６２はともに境界ルータである。

ＲＭ１１ １１１は、そのＡＳのトポロジーの知識をもつため、ＡＳ１ １１０の内部に最良のルートを見出し、かかるルートのために資源を一時的に予約するために、適当なメッセージ（示されず）を送信する。一時的な予約の継続期間は、例えばトラフィックの種類およびネットワーク活動の種類の観点から決められることとなるのだが、本発明の主題ではない。このように、ＲＭ１１ １１１は、そのＡＳＢＲ／ＲＭ１２ １１２へ要求メッセージ４１０を送信する。確立されているインタードメインＱｏＳ予約によって満たされる少なくとも１つのＱｏＳ特性とともに、目的地点要求を、要求メッセージ４１０は含む。その後ＲＭ１２ １１２は、その隣のＡＳへＡＳＢＲ２１ １２１、ＲＭ３１ １３１、およびＲＭ４１ １４１を介して要求メッセージを送信する。ＡＳＢＲ２１ １２１は、資源管理装置の機能性をもたないため、要求メッセージ４１２をＲＭ１２３へ転送する。各ＲＭが求める目的地点のために取得可能であるＱｏＳのレベルをＲＭ１２ １１２に通知する仮応答メッセージ４１４で、ＰＣＥ１２に対し、要求メッセージ４１２を受信するＲＭの各々は応答する。さらにＲＭの各々は、仮応答メッセージ４１４でアドバタイズされる資源を一時的に（要求４１２から別のＡＳから発せられてから短時間である場合が多い）予約するように動作する。ステップ４１２および４１４は、ボックス４１３で示されるように、適切ならば、他のＡＳに対しても繰り返される場合がある。その後ＲＭ１２ １１２は、最良の代替、例えばＲＭ３１ １３１を決定し、要求確認メッセージ４１６を上記代替ＲＭ３１ １３１へ送信する。その後ＲＭ３１ １３１は、ＡＳ３ １３０においてすでに行われている一時予約をリフレッシュする。ＲＭ２３ １２３およびＲＭ４１ １４１は、一時予約の期限切れの際に能動的に、または一時予約が要求されるのと同時に一時予約の継続時間が与えられた場合は黙示的に予約していた資源を解放する。その後ＲＭ３１ １３１は、そのＡＳＢＲ／ＲＭ３２ １３２へ要求確認メッセージ４１６を送信する。その後ＲＭ３２ １３２は、その隣のＡＳ、この場合はＲＭ６１ １６１へ要求メッセージ（示されず）を送信する。ＲＭ６１は、ＡＳ６ １６０の内部で最良のパスを見出し、かかるパスを予約し、そのＡＳＢＲ／ＲＭ６２ １６２へ要求確認メッセージ４１６を送信し、上記ＡＳＢＲ／ＲＭ６２は、自身が、要求されたインタードメインＱｏＳ予約の目的地点であることを検出する。ＲＭ６２、６３、３２、３１、および１２は、それぞれ要求確認メッセージ４１６に応答確認メッセージ４１８で応じる。ＲＭ１１ １１１がこの応答確認メッセージ４１８を受信すると、帰路のパスが、望まれた目的地点へ向かう許容可能および潜在的に最適なパスであるということと、かかるパスのための資源はインタードメインＱｏＳ予約のために「予約可能（ｒｅｓｅｒｖａｂｌｅ）」であることとが、ＲＭ１１ １１１にはわかる。

交換されるメッセージは、要求メッセージ４１２、要求確認メッセージ４１６、仮応答メッセージ４１４、および応答確認メッセージ４１８である。要求メッセージ４１２は、それだけでは何ら予約を行わないものである。仮応答メッセージ４１４は、それだけで一時的な予約を、短時間、すなわちインタードメインＱｏＳ予約を確認するための要求確認メッセージ４１６の受信を待つために必要な時間行う。要求確認メッセージ４１６を受信すると、より長い時間、すなわちパスの終点側から応答確認メッセージ４１８を受信するまで、資源が予約されることになる。応答確認メッセージ４１８を受信すると、資源の予約はそれ以降はもう有効ではなくなることとなる。明確さのために、図４の例では、同じＡＳに属するＰＣＥの間で交わされる応答メッセージおよび要求確認メッセージを示していない。

インタードメインＱｏＳ予約を修正する必要性がインタードメインＱｏＳ予約のパス内のリンク上に検出される場合に交わされるメッセージの信号送信の一例を、図４はさらに示している。インタードメインＱｏＳ予約のパスにおけるＡＳＢＲ／ＲＭは、その先の再最適化のために、最適化されたパスの状態を維持してきたと仮定される。このように、ＲＭ６１ １６１は、インタードメインＱｏＳ予約を修正する理由（例えば、ＱｏＳ劣化を引き起こす輻輳（ｃｏｎｇｅｓｔｉｏｎ））を検出し、ＲＭ３２に通知メッセージ４２０で通知する。ＲＭ３２ １３２は、目的地へ向かう代替パスを提供できないため、通知メッセージ４２０をＲＭ３１ １３１へ転送する。同じ理由で、ＲＭ３１ １３１は通知メッセージ４２０をＲＭ１２ １１２へ転送する。するとＲＭ１２ １１２は、要求メッセージ４１２と同様のものである要求メッセージ４１２’を送信する。ＲＭ１２ １１２は、修正要求の原因に応じてＲＭ１３１を含む場合または含まない場合があり（例えば、不具合はＲＭ３１ １３１の包含の要因とはならないが、期間リフレッシュはかかる要因となる）、ＲＭ１２ １１２はこのＲＭ１３１から通知メッセージ４２０を受信している。このように、ＡＳＢＲ２１ １２１は要求メッセージ４１２’をＲＭ２３ １２３へ転送し、ＲＭ２３ １２３は、ＲＭ４１ １４１と同様に、要求された目的地のためにＲＭが取得可能であるＱｏＳのレベルをＲＭ１２ １１２に通知する仮応答メッセージ４１４’で応答する。その後ＲＭ１２ １１２は、最良の代替、ここでの例ではＡＳ２ １２０を通すことを決定し、要求確認メッセージ４１６’をかかる代替ＡＳ２ １２０へ送信する。このように、ＡＳＢＲ２１ １２１は、要求確認メッセージ４１６’をＲＭ２３ １２３へ転送し、ＲＭ２３ １２３は、ＡＳ２ １２０内のパス資源を一時的に予約する。この場合、その他のＡＳは、予約していた資源を解放する。その後ＲＭ２３ １２３は、そのＡＳＢＲ／ＲＭ２２へ要求確認メッセージ４１６’を送信し、ＡＳＢＲ／ＲＭ２２はその隣のＡＳ、この場合ＡＳ６ １６０へ要求確認メッセージ４１６’を送信する。その後受信機（すなわちＲＭ６１ １６１）は、要求確認メッセージ４１６’をＡＳ６ １６０内の既存のパスに対応させる。かかる対応は、要求メッセージ４１６’中のパス要求ＩＤを使用して行われる場合もあるが、多くの他の方法が使用可能である。その後ＲＭ６１ １６１は、応答確認メッセージ４１８’で要求確認メッセージ４１６’に応答し、応答確認メッセージ４１８’は、この後ＲＭ１２ １１２へ再び転送される。応答確認メッセージ４１８’が受信されると、ＲＭ１２ １１２は、帰路のパスが許容可能であること、および最適である可能性があることがわかり、ＡＳ２ １２０を通るパスをとることによって、ＲＭ１２ １１２からＲＭ６１ １６１にわたるインタードメインＱｏＳ予約を再確立する。その後ＲＭ１２ １１２は、適切ならば、最終的にＲＭ３１ １３１に対し、インタードメインＱｏＳ予約のために資源を解放するよう信号を送信する（ステップ４２４）。

前例は輻輳シナリオを考慮している。同種の信号送信は不具合検出の場合に使用される場合もある。また、同様の信号送信は、インタードメインＱｏＳ予約またはその一環によってとられるエンドツーエンドパスを絶えず再最適化するために一定間隔で使用される場合もある。

図５は、本発明の開示によるＲＭ５００のモジュール式表現を示す。ＲＭ５００は、パケットを受信および送信するための少なくとも１つの入力‐出力ポートまたは手段５１０および５１０’をもつ場合が多い。しかし、入力‐出力手段として動作する別のデバイスに置換される場合もある。例えば図２〜４において上で提示した論理を実行するための手段を含む予約モジュール５２０をＲＭ５００は含む。ＲＭ５００は、典型的なルータの慣習的なタスクを行うためのルーティングモジュール５３０をさらに含む場合もある。ルーティングモジュールは予約モジュール５２０と交信し、逆もあり得る。ＲＭ５００は、例えば図２〜４において上で提示した論理を実行するための手段を含む選択計算モジュール５４０をさらに含む。モジュール５２０と５４０との間の機能性の配分は、本発明の開示を限定するものではない。しかし、処理のより高い必要性が要求されるタスクを選択計算モジュール５４０に任せることが有利であり、それによりかかるタスクはさらに最適化可能である。ＲＭ５００の潜在的なハードウェアアーキテクチャ（例えば、メモリ、プロセッサ、データストレージなど）は、本発明の開示には影響を与えないため、図５には示していない。

本発明の数例を添付図面で示し、前述の記述で説明してきたのだが、本発明は開示された実施形態に限定されるものではなく、本発明の開示から逸脱せずに、数多くの再設定、修正、および置換が可能であることが了解されるであろう。一般的に、本発明の記述における説明は、請求する様々な側面のいずれかを必ずしも限定するものではない。さらに、いくつかの説明は、本発明のいくつかの特徴に適用されるが、他の特徴には適用されないこともあり得る。図面において、同類または同様の構成要素は、いくつかの図面にわたり同等の参照番号を用いて指示されており、各種構成要素は必ずしも縮尺どおりに図示されていない。

図１は、本発明の開示によるネットワークトポロジーの一例である。 図２は、本発明の開示による、第１のＡＳ内の第１のノードと第２のＡＳ内の第２のノードとの間のＱｏＳ予約を確立するためのアルゴリズムの流れ図である。 図３は、本発明の開示による、第１のＡＳ内の第１のノードと第２のＡＳ内の第２のノードとの間のＱｏＳ予約を修正するアルゴリズムの流れ図である。 図４は、本発明の開示による、第１のＡＳ内の第１のノードと第２のＡＳ内の第２のノードとの間のＱｏＳ予約のセットアップおよび交信の一例の、メッセージシーケンスの流れ図である。 図５は、本発明の開示による資源管理装置ノードのモジュール式表現である。

Claims (14)

1. 第１のドメイン内の第１のノードと第２のドメイン内の第２のノードとの間のインタードメインＱｏＳ予約を確立するための方法であって、前記第１および第２のドメインは一連のルータを介して接続され、
   前記少なくとも１つのＱｏＳ特性をもつ前記インタードメインＱｏＳ予約が必要とされていることを、前記第１のノードにおいて検出するステップと、
   前記第１のドメインに関連するネットワーク状態情報を、前記第１のノードにおいて取得するステップと、
   前記第１のドメインと前記第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を、前記第１のノードにおいて取得するステップと、
   少なくとも１つのＱｏＳ特性の観点から、前記第１のノードと前記第２のノードとの間のパスの少なくとも１つの選択を、前記第１のノードにおいて決定するステップと、
   前記少なくとも１つのパス選択から、前記インタードメインＱｏＳ予約を支援するための選択パスを、前記第１のノードにおいて選択するステップと、
   前記インタードメインＱｏＳ予約の確立を始動させるための予約メッセージを、前記第１のノードから前記第２のノードへ向けて送信するステップと
   を含む、前記方法。
2. 前記決定ステップは、
   少なくとも１つのＱｏＳ特性に関して、前記第１のノードと前記第２のノードとの間のエンドツーエンドパスの少なくとも１つの選択を、前記第１のノードにおいて決定すること
   によって行われる、請求項１の方法。
3. 前記第１のドメインに関連するネットワーク状態情報を取得する前記ステップは、
   前記インタードメインＱｏＳ予約の最終的な確立のために資源を一時的に予約するための一時要求メッセージを、前記一連のルータから前記第１のドメインの中間ノードへ向けて、前記第１のノードから送信することと、
   前記第１のドメインの前記中間ノードから仮予約メッセージを受信することと、前記仮予約メッセージは、前記第１のドメインに関連する前記ネットワーク状態情報を含むことと、
   をさらに含む、請求項１の方法。
4. 前記第１のドメインと前記第２のドメインとの間のパスの前記少なくとも１つのあり得る選択に関連するネットワーク状態情報を取得する前記ステップは、
   前記インタードメインＱｏＳ予約の最終的な確立のために資源を一時的に予約するための一時要求メッセージを、前記一連のルータから前記第１のドメインの外の中間ノードへ向けて、前記第１のノードから送信することと、
   前記第１のドメインの外の前記中間ノードから仮予約メッセージ受信することと、前記仮予約メッセージは、前記第１のドメインと前記第２のドメインとの間のパスの前記少なくとも１つのあり得る選択に関連する前記ネットワーク状態情報を含むことと
   をさらに含む、請求項１の方法。
5. 前記第１のドメインと前記第２のドメインとの間のパスの前記少なくとも１つのあり得る選択に関連するネットワーク状態情報を取得する前記ステップは、
   前記インタードメインＱｏＳ予約の最終的な確立のために資源を一時的に予約するための一時要求メッセージを、前記一連のルータから前記第１のドメインの外の中間ノードへ向けて、前記第１のノードから送信することと、
   前記第１のドメインの外の前記中間ノードから仮予約メッセージを受信することと、前記仮予約メッセージは、前記第１のドメインと前記第２のドメインとの間のパスの前記少なくとも１つのあり得る選択に関連する前記ネットワーク状態情報を含むことと、
   をさらに含む、請求項３の方法。
6. 前記第１のドメインと前記第２のドメインとの間のパスの前記少なくとも１つのあり得る選択に関連するネットワーク状態情報を取得する前記ステップは、
   既存のテーブルから前記少なくとも１つのＱｏＳ特性予約に関係する情報を取得すること
   をさらに含む、請求項１の方法。
7. 前記少なくとも１つのエンドツーエンドパス選択を決定する前記ステップは、
   前記少なくとも１つのＱｏＳ特性に関する前記少なくとも１つのエンドツーエンドパス選択が存在するかどうかを決定するために、前記第１のドメインと前記第２のドメインとの間のパスの前記少なくとも１つのあり得る選択に関連する前記ネットワーク状態情報と、前記第１のドメインに関連する前記ネットワーク状態情報を、前記第１のノードにおいて連結させること
   を含む、請求項１の方法。
8. 前記少なくとも１つのエンドツーエンドパス選択を決定する前記ステップは、
   前記第１のドメインの外側にあり、前記第２のノードへ向かう少なくとも１つのパスの各々に対するＱｏＳ値を、前記第１のノードにおいて計算すること
   を含む、請求項１の方法。
9. 前記予約メッセージを送信する前記ステップは、
   確認要求メッセージを、前記第２のノードへ向けて前記第１のノードから送信することと、前記確認要求メッセージは、前記選択パスによりルーティングされるのに十分な情報を含むことと、
   予約確認メッセージを受信することと、前記予約確認メッセージは、前記第２のノードから前記第１のノードへの前記予約確認メッセージのパスに前記インタードメインＱｏＳ予約を確立したことと
   をさらに含む、請求項１の方法。
10. 前記方法は、前記予約メッセージを送信する前記ステップに続く特定の時間の後、予約確認メッセージが前記第１のノードにおいて受信されていないかどうかを決定する前記ステップからさらに再び実行される、請求項１の方法。
11. 第１のドメイン内の第１のノードと第２のドメイン内の第２のノードとの間のエンドツーエンドパス上に維持される確立されたインタードメインＱｏＳ予約を修正するための方法であって、前記第１および第２のドメインは一連のルータを介して接続され、
    少なくとも１つのＱｏＳ特性をもつ前記インタードメインＱｏＳ予約がリフレッシュされるのを必要としていることを、前記一連のルータの中間ノードにおいて検出するステップと、
    前記中間ノードのドメインに関連するネットワーク状態情報を、前記中間ノードにおいて取得するステップと、
    前記中間ノードの前記ドメインが前記第２のドメインでない場合、
    前記中間ノードの前記ドメインと前記第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を、前記中間ノードにおいて取得するステップと、
    前記少なくとも１つのＱｏＳ特性に関して、前記中間ノードと前記第２のノードとの間のパスの少なくとも１つの代替選択を、前記中間ノードにおいて決定するステップと、
    前記少なくとも１つの代替パス選択から、前記インタードメインＱｏＳ予約を支援するための選択パスを、前記中間ノードにおいて選択するステップと、
    前記第２のノードへ向かう、前記インタードメインＱｏＳ予約の前記エンドツーエンドパスを、前記選択パスが変える場合、
    前記インタードメインＱｏＳ予約の確立を始動させるための予約メッセージを、前記中間ノードから前記第２のノードへ向けて送信するステップと
    を含む、前記方法。
12. 検出の後、前記中間ノードが、前記第２のノードへ向かう代替パスを見出せることを検証するステップと、
    前記中間ノードが前記代替パスを見出せない場合、前記中間ノードから前記第１のノードへ向けて前記一連のルータを介して、通知メッセージを送信するステップと、前記通知メッセージは、少なくとも１つのＱｏＳ特性をもつ前記インタードメインＱｏＳ予約がリフレッシュされるのを必要としていることを、前記一連のルータのさらなるノードに知らせるのに十分な情報を含むことと
    をさらに含む、請求項１１の方法。
13. 前記第２のノードへ向かう、前記インタードメインＱｏＳ予約の前記エンドツーエンドパスを、前記選択パスが変えない場合、
    前記中間ノードから前記第１のノードへ向けて前記一連のルータを介して、通知メッセージを送信するステップと、前記通知メッセージは、少なくとも１つのＱｏＳ特性をもつ前記インタードメインＱｏＳ予約がリフレッシュされるのを必要としていることを、前記一連のルータのさらなるノードに知らせるのに十分な情報を含むことと
    をさらに含む、請求項１１の方法。
14. 第１のドメイン内の第１のノードと第２のドメイン内の第２のノードとの間のエンドツーエンドパス上のインタードメインＱｏＳ予約を確立および修正するための資源管理装置ノード（ＲＭ）であって、
    その場合、前記ＲＭは、前記エンドツーエンドパス上にあり、
    少なくとも１つのＱｏＳ特性をもつ前記インタードメインＱｏＳ予約が必要とされていること、または前記少なくとも１つのＱｏＳ特性をもつ前記インタードメインＱｏＳ予約がリフレッシュされるのを必要としていることを検出し、
    前記ＲＭと前記第２のドメインとの間のパスの少なくとも１つのあり得る選択に関連するネットワーク状態情報を取得し、
    前記インタードメインＱｏＳ予約の確立を始動させるための予約メッセージを、前記ＲＭから前記第２のノードへ向けて送信する
    予約モジュールと、
    前記少なくとも１つのＱｏＳ特性に関して、前記ＲＭと前記第２のノードとの間のパスの少なくとも１つの選択を決定し、
    前記少なくとも１つのパス選択から、前記インタードメインＱｏＳ予約を支援するための選択パスを選択する
    選択計算モジュールと
    を含む、
    前記資源管理装置ノード。

Images