(57)【要約】  本発明は、リソースおよび承認制御機能（ＲＡＣＦ）装置を使用して、暗黙的な予約モデルに関する終端間のサービス品質（ＱｏＳ）予約をサポートするための機構を特定する。本発明は、ＩＴＵ−Ｔ内で標準化されているオープンスタンダードなリソースおよび承認制御機能（ＲＡＣＦ）を使用して、暗黙的なリソース予約をどのように実施するかを教示する。いくつかの方法が網羅される。１）第１の方法の場合、一般的な分散型アプローチが特定されている。２）第２の方法の場合、着信ＲＡＣＦは予約状態を維持し、したがって、結果として生じるプロトコルは比較的簡単かつ頑強であり、実施しやすい。３）上の方法のどちらかまたはそれらの組合せに基づくことが可能である第３の方法は、着信ＲＡＣＦ終点と発信ＲＡＣＦ終点の両方で予約を開始し、ミートミーポイントに向けて進む。
2009528775.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク内の発信点と着信点の間の所与の予約に関するリソース要求を受信するステップと、
前記予約のための経路が利用可能であるかどうか、および前記予約のために必要な帯域幅が利用可能であるかどうかを決定するために、所与の領域向けの中央コントローラによってその領域に関する前記要求を処理するステップと、
前記経路および前記帯域幅が利用可能である場合、前記所与の領域内の前記予約を確認し、前記予約要求を、前記予約要求を満たすために要求されるリソースを有する次の領域向けのもう１つの中央コントローラに引き渡すステップと
を含む、複数の領域を有する通信ネットワーク内のリソース管理のための方法。
【請求項２】
予約要求が、要求に関する識別と、前記予約に関する発信終点および着信終点と、前記予約に関して要求される帯域幅およびポリシー要求のセットとを含む、請求項１に記載の方法。
【請求項３】
前記予約の前記発信点と前記着信点の間の経路内の各中央コントローラが、前記予約要求に関する状態を維持する、請求項１に記載の方法。
【請求項４】
前記予約の前記発信点と前記着信点の間の経路内の１つだけの着信中央コントローラが、前記予約要求に関する状態を維持する、請求項１に記載の方法。
【請求項５】
前記予約の前記発信点と前記着信点の間の経路内の各終端中央コントローラが、前記要求の前記発信点と前記着信点の間の点に収斂する前記予約要求に関する状態を維持し、各中央コントローラの状態情報が次いで共有される、請求項１に記載の方法。
【請求項６】
複数の領域を有する通信ネットワーク内のリソース管理のための装置であって、前記リソース管理が全領域ベースで達成されており、
前記ネットワーク内の発信点と着信点の間の所与の予約に関するリソース要求を受信するために動作可能なコントローラを含み、
前記コントローラが、前記予約のための経路が利用可能であるかどうか、および前記予約のために必要な帯域幅が利用可能であるかどうかを決定するために、所与の領域に関してさらに動作可能であり、
前記経路および前記帯域幅が利用可能である場合、前記所与の領域内の前記予約を確認して、前記予約要求を、前記予約要求を満たすために要求されるリソースを有する次の領域向けのもう１つのコントローラに引き渡す、装置。
【請求項７】
前記コントローラが、要求に関する識別と、前記予約に関する発信終点および着信終点と、前記予約に関して要求される帯域幅およびポリシー要求のセットとを含む予約要求を処理するように動作可能である、請求項６に記載の装置。
【請求項８】
前記予約の前記発信点と前記着信点の間の経路内の各中央コントローラが、前記予約要求に関する状態を維持する、請求項６に記載の装置。
【請求項９】
前記予約の前記発信点と前記着信点の間の経路内の１つだけの終端中央コントローラが、前記予約要求に関する状態を維持する、請求項６に記載の装置。
【請求項１０】
前記予約の前記発信点と前記着信点の間の経路内の各終端中央コントローラが、前記要求の前記発信点と前記着信点の間の点に収斂する前記予約要求に関する状態を維持し、各中央コントローラの状態情報が次いで共有される、請求項９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、電気通信の分野に関し、より詳細には、次世代ネットワークにおけるリソース管理に関する。
【背景技術】
【０００２】
次世代ネットワーク（ＮＧＮ）は、中でも、終端間のパケット転送のためのインターネットプロトコル（ＩＰ）を一般的に使用することを特徴とする。しかし、ＮＧＮの主な使命は、パケットインフラストラクチャ全体にわたる、リアルタイムマルチメディアを含む幅広いアプリケーションの完璧なサポートである。この要件とセキュリティおよび信頼性のための要件とは共に幅広くかつ多様であり、その結果、ＮＧＮは分散された汎用コンピューティングエンジンと想定することが可能である。この点で、「ベストエフォート」パイプなど、ネットワークの初期のインターネットモデルは、超大型コンピュータなど、情報技術と電気通信とを組み合わせた現代的なネットワークモデルに収斂される。結果として、ＮＧＮの責任は、単に接続性をサポートすることから、サービス品質を包括的に保証することに拡大する。
【０００３】
この拡大された任務を満たすための手掛かりは、動的なリソース管理である。実際に、現在のＮＧＮに関する調査開発における最も活発なトピックの中に、リアルタイムのアプリケーション駆動のリソース管理（ｒｅａｌ−ｔｉｍｅ  ａｐｐｌｉｃａｔｉｏｎ−ｄｒｉｖｅｎ  ｒｅｓｏｕｒｃｅ  ｍａｎａｇｅｍｅｎｔ）がある。管理される必要があるリソースは、
１．帯域幅、
２．ＩＰアドレス、
３．トランスポート（ＴＣＰおよびＵＤＰ）ポート、
４．様々なデータベース記録、
５．ＭＰＬＳラベル交換パス（ｌａｂｅｌ−ｓｗｉｔｃｈｅｄ−ｐａｔｈｓ）、および多くのその他のもの
を含む。実際に、非常に多数のこれらの「その他」は、リソース概念の抽象概念とこの抽象概念に基づく適切な機構の開発とを必要とするものである。
【０００４】
サービス制御とトランスポートリソース制御とを結合する必要により、ＮＧＮにおいて特に重要なリソース管理のアプリケーション駆動の側面およびリアルタイムの側面に焦点を当てる必要がある。第一に、かかる結合は、性能が主な差別要因（ｄｉｆｆｅｒｅｎｔｉａｔｏｒ）である、（ＩＰ電話技術、ＩＰ  ＴＶ、およびＩＰゲームなど）新しいサービスの素早い導入を可能にする。第二に、かかる結合は、サービスがパケットトランスポート技術と関係なく展開することを可能にする。
【０００５】
ＩＥＴＦ  ＲＦＣ２７５３は、ポリシーベースの承認制御に関する枠組を特定する。この枠組は、３ＧＰＰ  ＴＳ２３．２０７内で特定されたＩＰマルチメディアサブシステム（ＩＭＳ）サービスベースの局所ポリシー制御を支持する。これは、ＥＴＳＩ（または、むしろ、より具体的には、ＥＴＳＩ  ＴＩＳＰＡＮプロジェクト）とＩＴＵ−Ｔ研究グループ１１および１３の両方で標準化されている、リソースベース承認制御機構およびポリシーベース承認制御機構の基礎になった。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
新生の標準機構は、（ＩＭＳまたは非ＩＭＳサポートされた）サービス要求に関する承認決定が、ポリシーおよびトランスポートリソース利用可能性の両方を考慮に入れることを可能にするように設計されている。これらの標準機構は、サービス制御とトランスポートリソース管理とを橋渡しすることによって、性能保証および境界制御（例えば、ＮＡＰＴ、ＮＡＴトラバーサル、およびゲート）を可能にする。機構は、ＥＴＳＩ  ＴＩＳＰＡＮプロジェクト内のリソースおよび承認制御（Ｒｅｓｏｕｒｃｅ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ）サブシステム（ＲＡＣＳ）およびＩＴＵ−Ｔ内のリソースおよび承認制御機能（ＲＡＣＦ）の一部として定義されるが、次世代ネットワークにおけるリアルタイムのアプリケーション駆動のリソース管理に関する機能性は、まだ開発されていない。
【課題を解決するための手段】
【０００７】
本発明の原理に従って、本発明がリソースおよび承認制御機能（ＲＡＣＦ）装置を使用して、暗黙的な予約モデルに関する終端間のサービス品質（ＱｏＳ）予約をサポートするための機構を特定する、先進技術を超えた進展がもたらされる。一実施形態では、通信ネットワーク内の発信点と着信点の間の所与の予約に関するリソース要求を受信するステップと、前記予約のための経路が利用可能であるかどうか、および前記予約のために必要な帯域幅が利用可能であるかどうかを決定するために、所与の領域向けの中央コントローラによってその領域に関する前記要求を処理するステップとを含む、複数の領域を有する通信ネットワーク内のリソース管理のための方法が教示される。経路および帯域幅が利用可能である場合、前記所与の領域内の前記予約を確認することが確認され、前記予約要求は、前記予約要求を満たすために要求されるリソースを有する次の領域向けのもう１つの中央コントローラに引き渡される。本発明の一実施形態では、予約の発信点と着信点の間の経路内の各中央コントローラは予約要求に関する状態を維持する。もう１つの実施形態では、予約の発信点と着信点の間の経路内の１つの終端中央コントローラだけが、予約要求に関する状態を維持する。さらなる実施形態では、予約の発信点と着信点の間の経路内の各終端中央コントローラが、前記要求の発信点と着信点の間の点に向けて収斂する予約要求に関する状態を維持し、各中央コントローラの状態情報は、次いで共有される。
【０００８】
複数の領域を有する通信ネットワーク内のリソース管理のための装置も説明される。リソース管理は、全領域ベースで達成され、前記装置は、前記ネットワーク内の発信点と着信点の間の所与の予約に関するリソース要求を受信するために動作可能なコントローラを含む。コントローラは、前記予約のための経路が利用可能であるかどうか、および前記予約のために必要な帯域幅が利用可能であるかどうかを決定するために所与の領域に関してさらに動作可能である。経路および帯域幅が利用可能である場合、前記装置は、前記所与の領域内の前記予約を確認して、前記予約要求を、前記予約要求を満たすために要求されるリソースを有する次の領域向けのもう１つのコントローラに引き渡す。
【０００９】
本発明の教示は、添付の図面と共に、以下の詳細な説明を考慮することによって容易に理解され得る。
【発明を実施するための最良の形態】
【００１０】
本発明は、リソースおよび承認制御機能（ＲＡＣＦ）装置を使用して、暗黙的な予約モデルに関する終端間のサービス品質（ＱｏＳ）予約をサポートするための機構を特定する。本発明はＲＡＣＦに関して説明されるが、類似の機能性を含むその他の装置も本発明に関して利用され得る点を理解されよう。
【００１１】
暗黙的なリソース予約は、利用可能な（供給されたまたは予め予約された）ファットパイプ（ｆａｔ  ｐｉｐｅ）に関する記憶された情報に依存する。そのような場合、システムは、関係するネットワーク要素を（アクティブなセッションの状態を維持することによって）解釈することまたは監査することによって、使用された利用可能な帯域幅を追跡しなければならない。
【００１２】
本発明は、ＩＴＵ−Ｔ内で標準化されている、オープンスタンダードなリソースおよび承認制御機能（ＲＡＣＦ）を使用して、暗黙的なリソース予約をどのように実施するかを教示する。
【００１３】
いくつかの方法が網羅される。
１）第１の方法の場合、一般的な分散型手法が特定されている。
２）第２の方法の場合、着信ＲＡＣＦが予約状態を維持し、したがって、結果として生じるプロトコルは比較的簡単かつ頑強であり、実施しやすい。
３）上の方法のどちらかまたはそれらの組合せに基づくことが可能であり得る第３の方法は、着信ＲＡＣＦ終点と発信ＲＡＣＦ終点の両方で予約を開始し、ミートミーポイント（ｍｅｅｔ−ｍｅ−ｐｏｉｎｔ）（ＭＭＰ）に向けて進む。
【００１４】
本発明は、所与の領域向けまたは領域の一部向けの中央コントローラが所与の予約要求に関してその領域内のリソースの割当てを追跡するという点で先行技術を超えた進展である。より詳細には、コントローラは、一定の経路が領域内で利用可能であり、それらの経路に関連する帯域幅も利用可能であることを保証することができる。先行技術の多くの方法は、かかる情報を追跡するために経路に沿って個々のルータを使用し、これは、理解されるように、非常に厄介になっており、より重要なことには、拡張可能でない。加えて、これまでの技術の方法は、単方向の流れ予約をサポートしたが、対照的に、本発明は単方向予約と双方向予約の両方をサポートする。
【００１５】
図１に示されるように、ＲＡＣＳおよびＲＡＣＦ１０１は、次世代ネットワークアーキテクチャ１０３全体の中で同じ位置を有する。ＲＡＣＦはより一般的であるため、ＲＡＣＦという状況に関してリソース管理機構を考察する。
【００１６】
図２に示されるように、ＮＧＮ内のその他の機能エンティティを用いて示されたＲＡＣＦ２０１は２つの主な機能エンティティを含む。すなわち、ポリシー決定機能（ＰＤＦ）２０３およびトランスポートリソース制御機能（ＴＲＣＦ）２０５である。
【００１７】
ハイレベルで、ＰＤＦ２０３は、ポリシーならびにリソースの利用可能性に基づいてリソース要求を許可して、様々な制御をトランスポートエンティティに応用する責任を有する。制御は、ポートの開閉と、ＮＡＰＴと、ＮＡＴトラバーサルと、パケットマーキングとを含む。
【００１８】
ＴＲＣＦ２０５は、トランスポートリソース使用とネットワークトポロジー情報とにアクセスでき、したがって、ＰＤＦの要求に対してリソース利用可能性を検査することが可能である。ＰＤＦはＲｑ’基準点を介してＴＲＣＦと相互に作用する。
【００１９】
ＲＡＣＦは、Ｇｑ’およびＧｏ’を含む様々な基準点を介して、サービス層２０７で（ＩＭＳプロキシ呼状態制御機能［Ｐ−ＣＳＣＦ］が一例である、サービス制御プロキシ機能２０９などの）サービス制御機能エンティティと、トランスポート層２１１で（境界ゲートウェイ機能などの）機能エンティティと関係を有する。
【００２０】
加えて、承認制御は、ネットワークの輻輳を防止および包括するための基本的なＲＡＣＦ能力である。結果として、ネットワークは常に、所望される性能を用いてその技術的能力内で動作することが可能である。承認決定は、ネットワークリソースの利用可能性またはネットワークリソースへのアクセスの運営、管理および制御のためのポリシー規則など、様々な要因に依存する可能性がある。ポリシー規則は、サービスプロバイダのニーズ特有であり得、またはカスタマとサービスプロバイダの間の合意を反映することが可能である。後者の合意は、ある期間にわたる信頼性要件および利用可能性要件を特定することが可能である。一定のサービス（例えば、緊急通信）に関する信頼性ニーズと利用可能性ニーズとを満たすために、ネットワークへの承認に関して、通常の優先順位より高い優先順位が関連するトラフィックに与えられることが可能である。
【００２１】
アプリケーション駆動の環境において、サービス品質を保証するためには、リソースの利用可能性がアプリケーション要求を許可するための意思決定の一部であるように、承認制御がサービス制御（またはセッション志向のアプリケーションの場合はセッション管理）に結合されることが最も重要である。リソースの利用可能性情報の正確さ（すなわち、ノード、リンクまたは経路の現在の負荷をどの程度近く反映する必要があるか）に注意すべきである。リソースの最適使用とそれを達成するための計算コストの間にバランスの必要が存在する。同様に、信頼性要件およびセキュリティ要件は、通常、追加のリソース要求を生み出すため、どこでバランスを決めるかを理解することが重要である。ＩＣＩＮ’０４文書Ｈｏｕｃｋ  Ｄ．、およびＨ．Ｕｚｕｎａｌｉｏｇｌｕ、Ａｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ａｌｇｏｒｉｔｈｍ  ｆｏｒ  Ｍｕｌｔｉ−Ｐｒｉｏｒｉｔｙ  Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ（ＶｏＩＰ）Ｃａｌｌｓ。２００４年１０月、フランス、ボルドー、呼承認制御／呼承認管理に関する、Ｉｎｔｅｌｌｉｇｅｎｃｅ  ｉｎ  Ｓｅｒｖｉｃｅ  Ｄｅｌｉｖｅｒｙ  Ｎｅｔｗｏｒｋｓに関する第９回国際会議の会報がより詳細にこの主題を扱っている。
【００２２】
リソース割当て
本発明を説明するという状況に関して、特にＩＭＳ環境に最も重要な、リソース割当てをトリガするのはアプリケーション要求である事例に重点を置く。要求は、（ＩＭＳ  Ｐ−ＣＳＣＦなどの）サービス制御機能を経由して引き渡され、ＲＡＣＦはその受信者である。
【００２３】
ＲＡＣＦによって管理されるリソースのタイプは、（ネットワークの境界で送信トラフィックに割り当てられた）公開ＩＰアドレスおよびポート番号と、帯域幅とを含む。ＩＰアドレスおよびポート番号の割当ては、これらのタイプのリソースの１つのプールを有する１つの特定のネットワークだけを必要とするため、比較的簡単である。この場合、主な課題は、トランザクション制御、ならびにデッドロックおよび許可の防止である。
【００２４】
複数の領域にわたる帯域幅の割当ては、問題の分散性により、追加の要件を課す。これらの追加の要件のいくつかは、１）トラフィック優先順位を表示するための差別化サービス（ｄｉｆｆｓｅｒｖ）コードポイントの割当て、および２）マルチプロトコルラベルスイッチング（ＭＰＬＳ）ラベル交換パス（ＬＳＰ）の選択および割当てを含む。第二に、ネットワークの輻輳は、新たに作られた流れだけでなく、すべての進行中の流れの性能に悪影響を及ぼす可能性があるため、まさしくネットワーク内に特定の流れを承認するかどうかの決定も帯域幅管理の問題である。このため、これまでの項で承認制御を別々に扱った。
【００２５】
デッドロック防止
デッドロックの簡単な例は、２つのサービスプロセスのうちの各々が２つのリソース（例えば、ＩＰアドレスと最後に利用可能な帯域幅量）の同じセットの獲得のために争う場合である。１つのプロセスが、もう１つのプロセスと反対の順序で要求を発行し、各プロセスがすでに割り当てられたリソースを保持する場合、どちらのプロセスも進展しないことになる（また、これらのプロセスのいずれかを待つ任意のその他のプロセスも進展しないことになる）。一般に、デッドロックは、プロセスが、それらの独自のリソースを保持すると同時に、その他のプロセスによって保持されるリソースを要求するために発生する可能性がある。
【００２６】
デッドロックに対処するための３つの等級の戦略が存在する。
１．検出および回復
２．（リアルタイムの）回避、および
３．防止
一般的な場合、これらのうち、防止だけが現実的であり、これはデッドロックに関する４つの必要条件、すなわち、相互排除、非プリエンプション（ｎｏｎ−ｐｒｅｅｍｐｔｉｏｎ）、不定待機、および部分的割当て（すなわち、いくつかのリソースを保持すると同時にその他のリソースを要求する）のうちの少なくとも１つを拒否することによって達成される。ＲＡＣＦの場合、相互排除はプリエンプトされない場合がある。実際に、相互排除はすべての場合に実施されなければならない。部分的割込みを拒否することは、リソースの利用を必然的に低下させることになる。したがって、（タイマ値の慎重な選択によって達成されるべきである）待機の制限を用いた（すべてのリソースが１つの初期の予約で要求され、これらのリソースが解放されるまでその他の予約は行われ得ない）全体要求方法（ｃｏｌｌｅｃｔｉｖｅ−ｒｅｑｕｅｓｔｓ  ｍｅｔｈｏｄ）の組合せは、多くの場合、唯一の賢明な戦略であると思われる。
【００２７】
帯域幅割当て
帯域幅予約は、明示的または暗黙的であり得る。明示的な予約は、通常、それを介して、リソースがネットワーク要素にわたって動的に予約される（リソース予約プロトコル（ＲＦＣ２５０５）またはネクストステップインシグナリング（Ｎｅｘｔ  Ｓｔｅｐ  ｉｎ  Ｓｉｇｎａｌｉｎｇ）（ＮＳＩＳ）プロトコルＲＦＣ４０８０などの）シグナリングプロトコルに依存する。対照的に、暗黙的なリソース予約は、利用可能な（供給されたまたは予め予約された）ファットパイプに関する記憶された情報に依存する。そのような場合、帯域幅マネージャは、関係するネットワーク要素を（アクティブなセッションの状態を維持することによって）解釈することまたは監査することによって、使用された利用可能な帯域幅を追跡する。
【００２８】
次に、２つの暗黙的なリソース予約手法の適用可能性とそれらの改変形態とを考察する。明示的な予約の主題は、一見、暗黙的な予約の主題よりもより狭義に見えるにもかかわらず、複数領域にわたる明示的な予約の主題をサポートするプロトコル設計問題は、複数領域にわたる暗黙的な予約の主題をサポートするプロトコル設計問題とほとんど同じくらい複雑であることは興味深い。図３に示される状態を考慮する。その最も簡単な形で流れに関して領域Ｘ内で帯域幅予約を行う場合、
１．帯域幅と、
２．第１の点、すなわち隣接する領域Ｙの入口境界ゲートウェイを識別する点ａ、および第２の点、すなわち領域Ｚの出口境界ゲートウェイを識別する点ｂである、２つの点（それらのＩＰアドレスによって表される）と
を特定する必要がある。
【００２９】
領域Ｙは、かかる要求の受信時に、領域Ｚの途中でその独自の適切な出口境界ゲートウェイ、ならびに、その領域内で適切な入口境界ゲートウェイを発見しなければならない。帯域幅保証された入口／出口ルータ選択のための機構は、［ＲＦＣ３２７２］およびＨｏ、Ｋ．、Ｎ．Ｗａｎｇ、Ｐ．ＴｒｉｍｉｎｔｚｉｏｓおよびＧ．Ｐａｖｌｏｕ、Ｍｕｌｔｉ−ｏｂｊｅｃｔｉｖｅ  Ｅｇｒｅｓｓ  Ｒｏｕｔｅｒ  Ｓｅｌｅｃｔｉｏｎ  Ｐｏｌｉｃｉｅｓ  ｆｏｒ  Ｉｎｔｅｒ−ｄｏｍａｉｎ  Ｔｒａｆｆｉｃ  ｗｉｔｈ  Ｂａｎｄｗｉｄｔｈ  Ｇｕａｒａｎｔｅｅｓで扱われている。２００４年５月、ギリシャ、アテネ、ＩＦＩＰネットワーク会議（ネットワーキング’２００４）の会報は、その内容が参照によって本明細書に組み込まれている。
【００３０】
次に、ＲＡＣＦを用いた暗黙的な要約のための機構を議論する。２つの手法を考慮する。第１の手法は、完全に分散され、すべての領域内でかなりの量の状態が維持されることを要求する。第２の手法は、結果として、より簡単なプロトコルをもたらすが、状態の大部分は１つの領域内に維持される。（出願人は、この状態が着信ドメイン内に維持されることを提案し、その理由を説明する。）いずれの場合も、帯域幅の暗黙的な予約および解放は、４つのメッセージ、すなわち、予約、確認、拒絶、および解放を用いてそれぞれ達成される。
【００３１】
考慮するいずれの場合においても、予約は着信ＲＡＣＦ（すなわち、着信当事者が常駐する領域に属するＲＡＣＦ）によってだけ開始されるが、両方法は、着信ＲＡＣＦによってまたは発信ＲＡＣＦおよび着信ＲＡＣＦの両方によって同時に（二重ＲＡＣＦ手法）予約を開始するために使用されることが可能である。概して、着信当事者は、多くの場合、発信当事者が完全なアドレスおよび帯域幅情報を知る前に完全なアドレスおよび帯域幅情報を知り、したがって、予約プロセスをより早く開始し、シグナリング遅延を低下させることが可能であるため、着信ＲＡＣＦ手法は非常に望ましい。二重手法は、呼セットアップ遅延をさらに低下させることが可能である。
【００３２】
いくつかのインテリジェントネットワークサポートされた収斂されたサービスの場合、発信当事者はＲＡＣＦと相互に作用しないネットワークサーバであり得る点に留意されたい。
【００３３】
二重手法に関して、以下の問題が追加として考慮されるべきである。
１．簡単で単純な方法で二重手法を行うことは、結果として、部分的な割当て、したがって、デッドロックの潜在的危険をもたらす可能性がある。一方は、予約を完成する可能性があるものの、もう一方は失敗することになる。
２．ネットワーク内で維持されるべき状態の量も二倍にする可能性がある。
両方の問題に対する１つの解決法は、両方の予約がネットワーク内の共通点に達するまで、両方の予約を互いに向けて進めることである。（図３の）領域が互いのＲＡＣＦアドレスを知るように、領域がすべて互いを信頼すると仮定することによって、そのモデルを意図的に簡素化した点にも留意する。実際には、多くの領域がすべてのその他の領域とかかるアドレスを共有しないことになる可能性は非常に高い。そのような場合にはそれぞれ、その他の解決法との相互作用を慎重に考慮しなければならない。
【００３４】
分散型手法
図４に示される一般的な場合、ネットワーク４００内でｎ個の領域Ａ１からＡｎに及ぶ予約を考慮する。第１の領域Ａ１内のＲＡＣＦ４０２は、着信状態制御機能ＳＣＦから要求を受信する場合、まずそのＰＤＦ４０４を調べて、許可を取得する。次いで、当該ＲＡＣＦ４０２は、ａが領域Ａ２内に位置していることを発見する目的で、適切なネットワーク区分（ａ、ｂ）を発見するために、そのＴＲＣＦ４０６のトポロジー・リソース割当てデータベース（Ｔｏｐｏｌｏｇｙ  ａｎｄ  Ｒｅｓｏｕｒｃｅ  Ａｌｌｏｃａｔｉｏｎ  Ｄａｔａｂａｓｅ）（ＴＲＡＤ）４０８を検査する。ＲＡＣＦは（中でも、利用可能な帯域幅を減らして、それを予約にリンクさせることによって）ＴＲＡＤを更新し、以下のパラメータを用いて予約要求を発行する。
１．この特定の予約に対して基準の役割を果たす要求識別Ｃ、
２．（当初、Ａ１だけを含む）受信側ｂの途中の領域のリスト、
３．区分着信点、すなわちａおよびｂ、
４．帯域幅Ｂ、ならびに
５．（トラフィック優先順位、回避されるべき領域のセットなどを含み得る）ポリシー要求のセット。
【００３５】
この予約要求の受信時に、領域Ａ２内のＲＡＣＦ４１０は、
１．そのデータベースを考察し、その独自のＰＤＦ４１２およびＴＲＡＤ４１４を調べ、次の領域が領域リスト内に存在しない（したがって、サイクルを回避する）実行可能な経路が存在することを確実にし、
２．（帯域幅が不十分またはＰ内に含まれるポリシー要件を満たすことが不可能など、拒絶の理由を特定する拒絶メッセージを返信することによって）要求を拒絶する、または
３．関係する適切な出口点および入口点を決定して、ＴＲＡＤを更新し、予約要求を伝播する。
いずれの予約が拒絶された場合、各ＲＡＣＦが予約の記録を破壊して、それに応じて、そのＴＲＡＤを更新することができるように、当該予約は予約に関係するすべての領域で渡し戻される。
【００３６】
すべてが順調である場合、領域Ａｎ内のＲＡＣＦ４２０は予約を完了する。（予約に特定の一部の情報も含み得る）確認が経路に沿って返信される。
【００３７】
パイプが使用されていると同時に、ＲＡＣＦはもう１つの出口ルータを使用することを望むことが可能であることを決定することができる。入口ルータの変更が必要とされない限り、ＲＡＣＦはそのＴＲＡＤを更新するだけでよい。より複雑なシナリオでは、領域のもう１つのセットが横断される必要があることになる。そうでない場合、新しい区分パラメータを用いて、しかし、同じ予約識別ＩＤを用いて、予約を再送信する必要があることになる。それにより、未使用部分に関する帯域幅は解放されることになる。
【００３８】
この手法をサポートするために、各ＲＡＣＦは（経路によって横断されたすべての領域のリストを含めて）完全な状態情報を維持する必要がある。経路の区分だけが変更される場合、解放は新しい区分が確立された後で古い区分に沿って伝播される必要がある。
【００３９】
リソースの解放の一般的な場合と同様、これはこの手法を多少複雑に（すなわち、ＢＧＰ−ＴＥとほとんど同じように複雑に）する。二重ＲＡＣＦ予約の場合、着信ＲＡＣＦおよび発信ＲＡＣＦは両方とも状態情報を維持することになる。
【００４０】
着信ＲＡＣＦ制御手法および二重ＲＡＣＦ制御手法
図５に示される着信ＲＡＣＦ手法の場合、期せずしてｎ個の領域Ａ１からＡｎのセットに及ぶ、前と同じ経路（ａ、ｂ）がネットワーク５００に関して考慮される。先の場合のように、発信ＲＡＣＦ５０２は、当初隣接する領域Ａ２以外のすべての領域を認識しない。発信ＲＡＣＦ５０２はまた、前と同じ初期のステップにも従うが、プロトコルはより簡単である。予約要求は、要求識別Ｃと、区分終点ａおよびｂと、帯域幅Ｂと、（トラフィック優先順位、回避されるべき領域のセットなどを含み得る）ポリシー要求のセットとを依然として含む。要求は伝搬されないため、省略される１つのパラメータは領域リストである。
【００４１】
代わりに、この予約を受信し、その予約を満たすことが可能であることを発見するとすぐ、領域Ａ２内のＲＡＣＦ５０８は、関係する適切な出口ノードおよび入口ノードを決定して、ＴＲＡＤ５１０を更新し、確認メッセージを用いて応答し、そのパラメータリストがこの時、要求識別Ｃに加えて、出口ルータのアドレスａ１と、次の領域Ａ３と、次の領域の入口ルータのアドレスａ２と、追加の情報＜ｉｎｆｏ＞とを含む。（これは、例えば、将来の基準を簡素化するために、予約に対するＲＡＣＦハンドルを含み得る。）
【００４２】
着信ＲＡＣＦは、予約要求をＡ３に送信することなどによって、次の区分に関して予約を取得するために、これらのパラメータを使用する。したがって、着信ＲＡＣＦだけが予約の状態を維持する。横断された領域内で、各ＲＡＣＦは、発信ＲＡＣＦのアドレスと共に、要求Ｃに関連する帯域幅の量を記憶するだけでよい。（現在の実施形態は、着信ＲＡＣＦで状態を維持することの望ましさを提案するが、本発明は、状態を維持するために発信ＲＡＣＦも選択され得ることを企図する点を理解されよう。）
【００４３】
いずれの領域内のＲＡＣＦも帯域幅を割り当てることができない場合、当該ＲＡＣＦは拒絶を返信し、次いで、発信ＲＡＣＦは（まず、経路に沿って１つまたは複数のこれまでの予約を解放し、次いで、予約の代替セットを試みることによって）もう一度試みることが可能であり、または経路に沿ってすべての予約を解放することが可能である。
【００４４】
着信手法は、分散型手法と同じくらい多くのメッセージを要求する。しかし、（リソースおよび経路修復を解放することを含めて）多くのタスクをより簡単にする。詳細には、特定の接続が失われた（またはルータが過負荷された）場合を考慮する。ＴＲＣＦがこの情報を受信すると、ＲＡＣＦはＴＲＡＤを検査して、すべての影響を受けた領域内のＲＡＣＦに、拒絶メッセージを送信することが可能である。
【００４５】
二重ＲＡＣＦ手法の場合、同じ手順は、発信ＲＡＣＦおよび着信ＲＡＣＦの両方がミートミーポイントに達するまで互いに向けて進む発信ＲＡＣＦおよび着信ＲＡＣＦの両方で開始される。これは、呼セットアップ時間をかなり改善することが可能である。（これまでに説明されたように、状態を維持するための分散型の手法も二重ＲＡＣＦ手法で利用され得る。）
【００４６】
最後に、すべての上の手法は明示的な予約と相互に作用することが可能である点に留意する。すなわち、これらの手法は、１つまたは複数の中間領域が提供されたパイプを有さない場合でさえ使用され得る。この場合、ＲＡＣＦは、予約期間の間、かかるパイプを確立する（および維持する）ために、発信ホストとして、領域の入口ルータでＲＳＶＰプロトコルまたはＮＳＩＳプロトコルを応用し、出口ルータでそれを終了することが可能である。この混成手法は、配備の際に慎重に検討されなければならない、タイミング問題をもたらす可能性がある。
【００４７】
前述の説明は、本発明の原理を単に例示する。したがって、当業者は、本明細書で明示的に説明または示されはされないが、本発明の原理を実施し、その精神および範囲内に含まれる様々な構成を考案することが可能であることが理解されよう。さらに、列挙されたすべての例および条件的な言葉は、読者が本発明の原理と、技術を促進するために発明者によって寄与された概念とを理解するのを助けるための教訓的な目的のみとなることが特に明示的に意図され、かかる詳細に列挙された例および条件への限定なしに解釈されるべきである。さらに、本発明の原理、態様、および実施形態を列挙する本明細書のすべての記述、ならびにそれらの特定の例は、それらの構造的均等物および機能的均等物の両方を包括することが意図される。加えて、かかる均等物は、現在知られている均等物ならびに将来に開発される均等物、すなわち、構造にかかわらず、同じ機能を実行する、開発された任意の要素の両方を含むことが意図される。
【００４８】
その特許請求の範囲において、特定された機能を実行するための手段として表現される任意の要素は、例えば、ａ）その機能を実行する回路要素の組合せ、ｂ）その機能を実行するために、ソフトウェアを実行するための適切な回路と組み合わされた、任意の形の、したがって、ファームウェア、マイクロコードなどを含むソフトウェアを含めて、その機能を実行する任意の手段を包括することが意図される。かかる特許請求の範囲によって定義される本発明は、様々な列挙された手段によって提供される機能性が、特許請求の範囲が要求するように、組み合わされ、まとめられるという事実にある。出願人は、したがって、これらの機能性を提供することが可能な任意の手段を本明細書で示された手段と同等であると見なす。本発明の原理の多くのその他の修正形態および応用例は、本明細書の教示によって、当業者に明らかになり、当業者によって企図される。したがって、本発明の範囲は特許請求の範囲によってだけ限定される。
【図面の簡単な説明】
【００４９】
【図１】ＮＧＮにおけるＲＡＣＦおよびＲＡＣＳの位置の簡素化されたブロック図である。
【図２】例示的なＲＡＣＦアーキテクチャの図である。
【図３】その中に複数の領域間の通信を有する例示的なネットワークを示す図である。
【図４】所与の予約に関するリソースを予約するために本発明を利用する例示的なネットワークを示す図である。
【図５】所与の予約に関するリソースを予約するための本発明のもう１つの例示的な実施形態を示す図である。
【図１】
2009528775.tif 000003
【図２】
2009528775.tif 000004
【図３】
2009528775.tif 000005
【図４】
2009528775.tif 000006
【図５】
2009528775.tif 000007
【国際調査報告】
2009528775.tif 000008
2009528775.tif 000009
2009528775.tif 000010