JP2008541555A - データネットワークにおけるリソースの予約のための方法および構成 - Google Patents

Abstract

この発明は、データネットワークにおけるリソースオブジェクトのためにクライアントから要求されるネットワークリソースを予約するよう適合された帯域幅マネージャ（Bandwidth Manager）ＢＭに関連付けられる方法および構成に関する。この構成は、クライアントからのリソース要求によって規定される必要な第１の量に加えて割当てられるべきリソースの第２の量を決定するための手段を備え、決定されるリソースの第２の量は、割当てられるリソースの第１および第２の量が、より多くのリソースの要求を許可することにより増大し得る速度に依存する。

Description

発明の分野
この発明は、データネットワークにおける大容量リソースの予約を改善するための構成および方法に関する。特に、この発明は、割当てられるべき大容量リソースの量を決定するための構成および方法に関する。

背景
現在のネットワーキングの動向は、ＩＰベースのデータネットワークにおけるワイヤードユニットおよびワイヤレスユニットに「全面的に（all the way）インターネットプロトコル（Internet Protocol）（ＩＰ）」を与えることである。目的には、インフラストラクチャの単純化、幅広い範囲のアプリケーションのサポートおよび通信サービスに関する多様なユーザの要望への対処が含まれる。これらの目的を満たすためには、ＩＰネットワーク内でサービスの差別化および動的な帯域幅管理を提供するスケーラブルでかつ信頼性のあるソリューションが必要である。

ＩＰは最初から一般的な通信ソリューションであるように設計されていた。現在、ＩＰ技術は、安価であり、かつ、伝統的なデータアプリケーションおよび遅延に敏感なリアルタイムのデータアプリケーションの両方をサポートするのに適切であると認識されている。期待されるサービスをリアルタイムのアプリケーションに提供するために、論理的に（および物理的に）別個のＩＰネットワークが使用される。

各ＩＰネットワークは、帯域幅要件がかなり予測可能である敏感なアプリケーションのサブセット（たとえばＩＰテレフォニ）のみに役立つ。アプリケーションの範囲を制限することによって、総帯域幅需要を予測できる。これによって、垂直に最適化されたネットワーク用に使用されるのと同一のトラフィックモデルを使用して、ネットワークを必要な大きさにすることが可能である。ＩＰ技術における動的なサービスプロビジョニングへのサポートを必要とすることなく、安価なＩＰ機器の利点が得られる。

現在、ネットワークオペレータは、いくつかの並列ネットワークを維持するオーバーヘッドコストの削減を目指している。１つの現在の動向は、さまざまなネットワークサービス需要を有するすべての種類のアプリケーションを、同一の論理的なＩＰネットワーク（すなわち次世代マルチサービスネットワーク）の中で、実行させることによってインフラストラクチャを単純化することである。これは、ＩＰネットワークにおけるアプリケーションの異質性が増大しつつあることを意味する。

研究および標準化団体では、サービス品質（Quality of Service）（ＱｏＳ）サポートの発展は、（垂直ネットワークで使用されるソリューションにいくらか類似している）インターネットの信号化ソリューションを提供することから、現在ではよりステートレスな（stateless）ソリューションが好ましいと認識することへと進んできた。

ルータにおいてフローごとのＱｏＳ管理を使用するソリューションのスケーラビリティの問題は、ＩＥＴＦによって規定される差別化されたサービスアーキテクチャをもたらした。このアーキテクチャの目的は、ルータにおいてフローごとの状態を必要とすることなくスケーラブルなＱｏＳサポートを提供することである。基本的な考え方は、ＩＰパケットヘッダが（DiffServフィールドとして公知の）小さなラベルを含み、パケットがルータによって与えられるべきである処理（ホップごとの振舞い）をこの小さなラベルが識別す
るというものである。その結果、コアルータはいくつかの転送クラスで構成され、ラベルはこれらのクラスにパケットをマップするために使用される。このアーキテクチャは、意図されたサービスが確実に提供されるようにネットワークの境界でパケットマーカおよびポリシング機能に頼る。

差別化されたサービスの１つの利点は、モデルが、インターネットを成功させる有利な特性を保つことである。このモデルは、さまざまな種類の相互接続された物理的なネットワークを通じたスケーラブルでかつステートレスな転送をサポートする。しかしながら、標準的なモデルは、ルータにおける差別化された転送に限定され、したがって予測可能なサービスをエンドユーザに提供することには課題がある。

（ベストエフォートサービスよりは比較的よいが、トラフィックが送られる場所およびその時点で他のものによって生じるロードに依存する）定性的なサービスは、ルータにおけるDiffServサポート、および半静的なアドミッション制御ならびにサービスプロビジョニングのための帯域幅管理メカニズムのみに頼ることによって提供され得る。

定量的な（最小期待）サービスを提供するためには、リソースは、帯域幅管理メカニズムによって動的に管理されなければならず、関係するサービスを提供するのに十分なリソースがネットワークに確実に存在するように動的なアドミッション制御を伴わなければならない。

動的なアドミッション制御を行なうエンティティ（entity）は、この明細書では帯域幅マネージャ（bandwidth manager）（ＢＭ）と呼ばれる。ＢＭエンティティは、利用可能なネットワークリソースを追跡するよう適合され、クライアントからの入ってくるリソース予約要求に対してアドミッション制御を行なう。帯域幅マネージャエンティティに対するクライアントは典型的には、伝統的なテレフォニサービスならびにビデオ・オン・デマンド、ビデオテレフォニおよびゲームなどのサービスを提供するさまざまなブロードバンドアプリケーションフレームワークをエミュレートするコールサーバである。これらのクライアントは一般にアプリケーションフレームワーク（application framework）（ＡＦ）と称され、ＡＦという用語はこの明細書ではＢＭに対するクライアントを表わすためにも使用される。

アプリケーションフレームワークからＢＭへの予約要求は典型的には、必要な帯域幅の量、期待される転送品質の記述、およびＩＰアドレスの形態でのターゲットデータストリームについてのエンドポイント識別子を含む。このような要求は、予約の開始および停止時間などの追加の引数も含み得る。

アドミッション制御を行なうために、ＢＭエンティティは以前に許可されたリソース予約の履歴を格納する。ＢＭエンティティは、利用可能なリソースの総量、以前の予約によって現在予約されている量、および新しいリソース要求において要求されるリソースの量に基づいて、新しいリソース要求を許可する決定を下す。

ＢＭエンティティは、アクセスドメインおよびコアドメインの両方において正確なリソース制御を与えるべきである。正確なリソース制御には、ネットワークにおける個々の競合ポイントでリソースを制御するために、ＢＭエンティティが必要である。ネットワークにおける競合ポイントとは、複数のデータストリームが転送容量を共有するポイントである。例には、出力ネットワークインターフェイス、ＭＰＬＳネットワークにおけるトンネルヘッドおよびＡＴＭネットワークにおけるＶＣ／ＣＰの入口が含まれる。

ＢＭシステムは、複数のネットワークドメインを含み得る大型のデータネットワークに配備されるときには、性能、スケーラビリティおよび信頼性の理由で分散させる必要がある。これは、ＢＭインスタンスが１組のハードウェアプラットフォーム上で分散され得ることを意味する。これらのインスタンスは、異なるネットワークドメインにおけるリソース予約サービスがＢＭシステムによってカバーされる状態でＡＦに役立つように通信しなければならない。１組のＢＭインスタンスが、分散したＢＭシステムにいかに配置され得るかについて例を記載する。図１は、複数のＡＦ１００ａ〜ｆを備えるＢＭの配備を示す。ＡＦ１００ａ、ｂは最上部レベルのＢＭエンティティ１０２ａに接続され、ＡＦ１００ｃ、ｄは最上部レベル１０２ｂに接続され、ＡＦ１００ｅ、ｆは最上部レベル１０２ｃに接続される。最上部レベルのＢＭエンティティはさらにサブネットワークＢＭエンティティ１０４ａ〜ｃに接続される。図１に示す例は、アクセスドメイン１０６、１０８、１１０、バックホールドメイン１１２、コアドメイン１１６および相互接続ドメイン１２０における帯域幅管理をカバーする。アクセスネットワークは、加入者宅内機器（Customer Premises Equipment）（ＣＰＥ）およびエンドターミナルを備える。バックホールネットワーク１１２およびコアネットワーク１１６は、１１８で表わされるＩＰエッジを介して接続されるコアネットワーク１１６および相互接続ネットワーク１２０と同様に、ＩＰエッジ１１４を介して接続される。

図１に示すように階層的な態様でＢＭ（インスタンス）の大きさを決めることができ、それによって、階層における各レベルのＢＭエンティティはインターフェイスＩＦ−５を使用して下位レベルのＢＭエンティティからリソースを予約する。下位レベルのＢＭエンティティは、ネットワークの異なるサブドメインを担当する。このようなＢＭエンティティは、サブネットワークＢＭエンティティと称され、Ｓ−ＢＭエンティティと表わされる。最上部レベルのＢＭエンティティは、セッションが交差するサブネットワーク、したがってリソースについて照会されなければならないサブネットワークＢＭエンティティを識別することを担当する。図２は図１と同様のＢＭの配備を示すが、ＢＭエンティティは矢印２０２および２０４によって示すように隣接するピアドメインにおける他のＢＭエンティティからもリソースを要求できる点が異なっている。

分散したＢＭシステムには、階層の中の層にわたっておよびピア間で正しいＢＭエンティティを自動的に見つけるためのメカニズムが設けられる。それによって、ＡＦは下にあるネットワークトポロジーを理解する必要がない。適切なＢＭエンティティを見つけることは、「ソース探索」ＢＭエンティティを使用することによって達成される。このようなＢＭエンティティは、開始しているＢＭエンティティから要求を取得し、予約の実行を担当するＢＭエンティティにこれらの要求を転送する。

階層モデルでは、複数の最上部レベルのＢＭエンティティはＡＦと対話する。各ＡＦは、高レベルのルーティングおよび分散機能を与え、データストリームが横断しなければならないサブネットワークホップを識別する、指定された最上部レベルのＢＭエンティティを有することができる。次いで、最上部レベルのＢＭエンティティは、個々のネットワークにおいてリソースの予約を担当するサブネットワークＢＭエンティティに要求を渡す。

最上部レベルのＢＭのトポロジーモデルおよびルーティング機能のために、予約、発信アクセス、コア、終端アクセスのすべてのホップは最上部レベルのＢＭから派生し得る。いずれのアーキテクチャにも、複数の最上部レベルのＢＭが存在し得る。なぜなら、他のものの予約の状態を理解する必要がある最上部レベルのＢＭは１つもないためである。

最上部レベルのＢＭの下には、下にあるネットワークリソースに予約要求をマップする複数のサブネットワーク帯域幅マネージャが設けられる。これらのＢＭは複数の最上部レ
ベルのＢＭから予約要求を取得し、ネットワークリソースの占有に基づいてコールアドミッション制御（Call Admission Control）（ＣＡＣ）を行なう。

階層的に分散したＢＭアーキテクチャは二次元で大きさが決まる。
予約要求ロードのスケーリングは、複数の最上部レベルのＢＭを配備することによって得られる。個々のセッション／コールについての帯域幅は最上部レベルのＢＭから要求され、最上部レベルのＢＭは、帯域幅集合体を要求する（予め割当てる）ために下位レベルのＢＭと対話することによって、ドメインの中で集合体リソースを共有する。任意の大型のトポロジーへのスケーリングは、ドメイン内で異なるトポロジーのサブドメインを担当するいくつかのＢＭエンティティを底部層に配備することによって得られる。

ＢＭエンティティは、隣接する（ピアリング）サブドメインにおけるＢＭエンティティでリソースを割当てる（集約する）ように構成されてもよく、さらなるスケール次元が達成される。図２に示すようにピアリングと階層モデルを組合せることによって、各最上部レベルのＢＭはサブドメインの各ＢＭと対話する必要がなくなる。これによって事実上より多くのレベルを階層に加えることになる。

ピアリングモデルでは、セッションについての正確な「ソース」ＢＭが識別されなければならない。なぜなら、そのＢＭはピアＢＭへのいずれの要求も開始させることを担当しているためである。帯域幅管理層のネットワークトポロジーをＡＦ層に対して隠すために、予約ごとのソースＢＭが具体的にどこに位置するかをＡＦは知る必要がない。ＡＦは任意のＢＭへの要求を開始させる必要があるのみであり、要求はソース探索ＢＭプロセスを介してソースＢＭに転送されることになり、そのためリソースの要求の通常のプロセスを開始できる。

大容量のリソースの予約
所与のＢＭエンティティによってなされる大容量リソースの予約は、ＢＭエンティティによって維持される予約の集合体のために割当てられるリソースの量である。このような大容量の予約は、将来の予約要求の到着の準備をすることに先立って、または予約がＢＭエンティティにおいて要求されたときにすぐに、ＢＭエンティティによってなされ得る。たとえば、所与のネットワークリソースのために１０ユニットの帯域幅が予約され、追加の１ユニットの要求がこのリソースのためにＢＭエンティティに到着する。ＢＭエンティティは次いで、１０ユニットの帯域幅の現在の大容量の予約を必要な追加の１ユニットで更新しようと試みる場合もあれば、到着するかもしれない将来の要求の準備をするために大容量の予約を追加の２以上のユニットで更新しようと試みる場合もある。

したがって、大容量の予約とは、１つ以上の予約またはアプリケーションデータフロー（集合体）をサポートする予約であり、前もってなされてもよいが、そうする必要はない。

大容量のリソースを割当てることについてさらに以下で説明する。ＡＦによって発行される単一の予約要求は、複数のリソースがアドミッション制御プロセスにおいて評価される必要があるという結果になり得る。たとえば、このような要求の経路は２つのアクセスドメインおよび１つのコアドメインに及ぶ。アクセスドメインを通るサブ経路は、トラフィックが競合する２つの独立したネットワークインターフェイスを伴う。コアネットワークを通る経路は３つのこのような競合ポイントを伴う。

以前の段落に記載した経路について７つのリソースが評価される必要がある。大容量の割当てがなければ、この経路におけるリソースの要求は下位レベルのＢＭへの７つの要求をもたらすことになる。これは、すべての競合ポイントが最上部レベルのＢＭの中に表わ
されるときにこのような要求ごとに起こる。

リソースの大容量の割当てがあれば、最上部レベルのＢＭは、ＡＦからの元の予約要求を付与するために必要とされるよりも多くのリソースを下位レベルのＢＭからの各要求において割当てることができる。それによって、ＡＦ要求は帯域幅ＢＭ間により少ない要求をもたらすことになる。たとえば、各ＡＦ要求は複数の独立したリソースを伴い得るが、大容量の割当てがあれば平均して１０００個のＡＦ要求はＢＭ間に１００個の要求をもたらし得るであろう。

以前のセクションに記載した例では、最上部レベルのＢＭは、ＡＦに提供され得る集合体大容量リソースを割当てるために、他のＢＭエンティティと直接的にまたは間接的に通信する必要がある。大容量リソースは、図１に示すように階層状に配置されたＢＭエンティティ間に、または図２に示すようにピアリングＢＭエンティティ間に割当てられる必要もあり得る。当然のことながら、ＢＭは近い将来に必要ではない大容量リソースを戻す必要もある。大容量リソースを割当てることに関わる一連のＢＭエンティティは、階層状にまたはピアとして配置された２つ以上のＢＭエンティティを含み得ることに注目されたい。

大容量リソースは、個々の競合ポイントのために、ネットワークドメインを通る個々の経路のために、またはネットワークドメインのためにＢＭエンティティ間に割当てられることができる。競合ポイント、経路およびネットワークはすべて、リソースを割当てることができるオブジェクトとして表わされることができる。このようなオブジェクトはこの明細書ではリソースオブジェクトと称される。

大容量の集合体リソースを割当てる概念は、（ａ）個々の競合ポイント、ネットワークドメインを通る個々の経路またはネットワークドメインの知識を最上部レベルのＢＭ、中間ＢＭおよび底部レベルのＢＭに格納することを含む。各々のこのようなネットワークリソースの知識は、リソースオブジェクトの中に、または等価にネットワークリソースの知識を格納するための他のコンテナの中に表わされることができる。

ネットワークリソースの知識は、ＡＦ予約要求の経路におけるおそらくすべてのネットワークドメインのために最上部レベルのＢＭによって維持されることができるが、中間ＢＭはＡＦ予約要求の一部のためにネットワークドメインの知識を維持し得る。底部レベルのＢＭは典型的には、直接に担当するネットワークドメインの知識のみを維持する。

個々の競合ポイント、経路またはネットワークの知識を使用して、大容量の概念はさらに、ＢＭシステムにおける他のＢＭから大容量の集合体リソースを割当てることおよび戻すことを含む。

ＢＭ間に大容量リソースを割当てる問題は、１組の要件によって規定され得る。このようなリソース割当ての２つの主な要件は、このような割当てが、アプリケーションフレームワークまたはＢＭによって発行される予約要求への短い応答時間および効率的なリソース利用を可能にしなければならないというものである。

さらに他の要件は、リソースの割当てが激しく変動してはならないことである。使用されるリソースの量に加えて割当てられるリソースの量が変動するとリソースの割当ては変動すると言える。たとえば、１０ユニットの帯域幅がＢＭにおいて予約され、これは次に別のＢＭから１２ユニットを割当てる。第１のＢＭは１４ユニットを割当てることと１０ユニットを割当てることとを交互に繰返す（すなわち４ユニットが繰返し割当てられ、戻される）とさらに仮定されたい。そうであれば、このＢＭによるリソースの割当ては変動
していると言われる。変動は低いリソースの利用に繋がるであろう。したがって、変動は第２の要件によって暗にカバーされる。

発明の概要
大容量の概念は、アプリケーションフレームワークによって発行される予約要求へのより短い応答時間およびより効率的なリソースの利用をもたらす。この発明の目的は、割当てられるべきリソースの量を決定するための構成を得ることによって大容量の概念を改善することである。

さらに他の目的は、リソースの割当ての変動を防ぐことである。
この発明は、帯域幅マネージャ間に割当てられるべきリソースの量を決定するために使用される情報に関する。この発明は、分散した帯域幅マネージャシステムにおいてスケーラブルなリソース制御を改善する。

この発明の目的は、請求項１、１３および１４に従う構成によっておよび請求項７に従う方法によって達成される。

この発明に従う好ましい実施例は従属請求項によって規定される。
データネットワークにおけるリソースオブジェクトのためにクライアントから要求されるネットワークリソースを予約するための方法は、クライアントからのリソース要求によって規定される必要な第１の量に加えて割当てられるべきリソースの第２の量を決定するステップを備え、決定されるリソースの第２の量は、割当てられるリソースの第１および第２の量が、より多くのリソースの要求を許可することにより増大し得る速度に依存し、割当てられるべきリソースの量を決定することによって大容量の概念を改善する。

この発明に従う構成は、データネットワークにおけるリソースオブジェクトのためにクライアントから要求されるネットワークリソースを予約するよう適合された帯域幅マネージャＢＭに関連付けられる。この構成は、クライアントからのリソース要求によって規定される必要な第１の量に加えて割当てられるべきリソースの第２の量を決定するための手段を備え、決定されるリソースの第２の量は、割当てられるリソースの第１および第２の量が、より多くのリソースの要求を許可することにより増大し得る速度に依存し、割当てられるべきリソースの量を決定することによって大容量の概念を改善する。

好ましい実施例に従う構成では、決定されるリソースの第２の量は、個々のリソースオブジェクトごとに要求されるリソースの平均量に依存する。

好ましい実施例に従う構成では、決定されるリソースの第２の量は、個々のリソースオブジェクトごとにＢＭによって発行される予約要求の平均速度に依存する。

好ましい実施例に従う構成では、決定されるリソースの第２の量は、予約要求メッセージの待ち行列によって課される電流信号遅延に依存する。

好ましい実施例に従う構成は、要求されるリソースの総量を決定するための手段を備え、要求されるリソースの量＝σ＋θ＊（１＋ρ）−βであって、σ＝リソースの第１の量、すなわち現在使用されているリソースであり、θ＝リソースの第２の量、すなわち割当て範囲であり、ρ＝割当て範囲を維持するために設定されるべきパラメータであり、β＝別のＢＭから予約されるリソースの量である。

好ましい実施例に従う構成では、ρは０より大きいように設定される。
好ましい実施例に従う構成は、リソース要求によって規定される必要な量から独立して、ベースレベルとして割当てられるべきリソースの量を維持するための手段を備える。

さらに他の局面に従うと、この発明は、データネットワークにおけるルータまたはサーバ内のコンピュータの内部メモリに直接にロード可能なコンピュータプログラムプロダクトに関し、この方法のステップを実行するためのソフトウェアコード部分を備える。

さらに他の局面に従うと、この発明は、コンピュータによって使用可能な媒体に格納されたコンピュータプログラムプロダクトに関し、データネットワークにおけるルータまたはサーバ内のコンピュータにこの方法のステップの実行を制御させるための読取可能なプログラムを備える。

この発明の利点は、この発明によって、リソースが大容量で割当てられる分散した帯域幅マネージャシステムにおいてスケーラブルなリソース制御が可能になることである。この発明を通じて、ターゲット応答時間を短く保つことができる一方で、予め割当てられるリソースの量を最小限に抑えて、それらの応答時間を低減する。これは効率的なリソースの利用を可能にし、それによって、大量のリソースを予め割当てることなく、分散した帯域幅マネージャシステムへのリソース要求に素早く返答できる。このような要求への迅速な回答は重要である。なぜなら、クライアントは遅延した返答をまるで要求が否定されたかのように解釈しなければならない場合があるためである。これはアプリケーションセッション（コール）処理におけるポストセッション開始（ダイヤル）遅延を制限する必要があるためであり、待ち状態のセッション（コール）の試行の量が高容量アプリケーションセッション（コール）処理プラットホームの容量の理由でしばしば制限されなければならないためである。

詳細な説明
この発明について添付の図面を参照して以下でより十分に説明し、この発明の好ましい実施例を添付の図面に示す。しかしながら、この発明は、多くの異なる形態で実施されることができ、本明細書に説明する実施例に限定されるように解釈されるべきではない。むしろ、これらの実施例は、この開示が完璧かつ完全であり、この発明の範囲を当業者に十分に伝えるように提供される。

この発明の目的は、リソース割当て範囲、すなわちリソース要求によって規定される必要な量に加えて割当てられるべきリソースの量を決定するための構成および方法によって達成される。

ＢＭなどの、所与の一対のリソースを管理できるエンティティの間に割当てられるべきリソースの総量は、この発明の一実施例に従って割当て範囲を維持するために集合体大容量リソース割当てアルゴリズムから決定される。

ＢＭによって割当てられるべきリソースの量は、最低でも、ＢＭに対するクライアントによって現在予約されているリソースの量である。このようなクライアントは他のＢＭであってもよく、またはＡＦであってもよい。ＢＭの望ましい特性は、付与される１つ以上の大容量割当て予約要求を待つことなくクライアントからの予約要求に返答する能力である。割当てられるべきリソースの最小量に加えて、この特性を達成するためにより多くのリソースを割当てる必要がある。それによって、ＢＭは、割当てられるべきリソースの最小量に加えてより多くのリソースを割当てることによって、すぐに回答しなければならない新しい予約要求の準備をすることができる。割当てられる必要がある追加のリソースの
量はこの明細書ではリソース割当て範囲と称される。したがって、この発明は、予約要求への応答時間の低減をもたらす、リソースオブジェクトごとのリソース割当て範囲の決定に関する。

この発明に従うと、リソース割当て範囲は、割当てられるリソースの第１および第２の量が、より多くのリソースの要求を許可することにより増大し得る速度、たとえば信号メカニズムによって維持される現在の要求の信号速度に依存する。したがって、低速になればより大きな範囲が必要になり、高速になればより小さな範囲が必要になる。

この発明の実施例に従うと、割当て範囲はさらに、（ｂ）個々のリソースオブジェクトごとに要求されるリソースの平均量、（ｃ）個々のリソースオブジェクトごとにＢＭによって発行される予約要求の平均速度、および／または（ｄ）予約要求メッセージの待ち行列によって課される電流信号遅延に依存する。

なお、（ａ）および（ｄ）はすべてのリソースオブジェクトについて同一であるが、（ｂ）および（ｃ）はすべてのリソースオブジェクトについて個々である。

通信するＢＭを接続するネットワークによって課される伝搬および待ち行列遅延は、ＢＭにおいて作られる要求メッセージの待ち行列によって課される内部遅延と比較して小さければ、無視することが可能である。ネットワーク遅延が内部遅延に近い場合には、ネットワーク遅延は（ｄ）に規定される信号遅延に含まれる必要がある。

この発明のさらに他の実施例は、リソースオブジェクトごとにリソース割当て範囲を維持することに関する。特定のリソースオブジェクトのために維持されるべきリソースの量は、リソースの第１の量、すなわち現在使用されているリソース、すなわちσに、リソースの第２の量、すなわちリソース割当て範囲、すなわちθを加えたものである。リソースを要求する必要があるときには、この発明の実施例に従って割当て範囲を維持するために、以下に示す式１に規定されるリソースの量を要求すべきである。式１では、σは現在使用されているリソースであり、θは割当て範囲であり、βは別のＢＭから現在予約されているリソースの量であり、ρは割当て範囲を維持するためおよび変動を防ぐために設定されるべきパラメータである。リソースオブジェクトのためにリソースを維持するＢＭによってリソース要求が付与されることに起因して、式１が０より大きくなるとリソースが要求される。

要求されるべきリソースの量＝σ＋θ＊（１＋ρ）−β 式１
式１では、ρが０より大きければ、リソース割当て範囲θを維持するために、必要以上のさらに他の追加のリソースの量が要求されることになる。たとえば、ρ＝１は、この量の２倍の量が要求されることを意味する。この追加のリソースの量を割当てることによって、リソースオブジェクトについて発行される予約要求の速度が低減される。ρを０に設定することは、割当て範囲θを変動させる可能性がある。なぜなら、予約要求の速度がリソース割当て範囲を計算するために使用されるためである。使用されるリソースの量に加えて割当てられるリソースの量が変動するとリソースの割当ては変動すると言える。たとえば、１０ユニットの帯域幅がＢＭにおいて予約され、これは次に別のＢＭから１２ユニットを割当てる。第１のＢＭは１４ユニットを割当てることと１０ユニットを割当てることとを交互に繰返す（すなわち４ユニットが繰返し割当てられ、戻される）とさらに仮定されたい。そうであれば、このＢＭによるリソースの割当ては変動していると言われる。リソース要求は割当て範囲θを増大させ、割当て範囲θは、割当て範囲θをさらに増大させる新しいリソース要求を引き起こす。それによって、これらのリソースに対するクライアントの要望が減少するまでθは増大することになる。したがって、ρを０より大きく設定することによって、変動が防止される。

さらに他の実施例に従うと、この構成は、リソース要求によって規定される必要な量から独立して、リソース割当てベースレベル、すなわちベースレベルとして割当てられるべきリソースの量を任意に維持するための手段を備える。任意のリソース割当てベースレベルはより長い時間尺度にわたって維持されることができ、集合体大容量リソース割当てアルゴリズムを使用してより短い時間尺度でリソースの量を適合させる必要性を低減する。

ＢＭによってリソース割当てベースレベルのために割当てられるリソースの量はたとえば、平均的なリソースのニーズ、またはリソース割当てベースレベルが維持される期間中に使用されるリソースの量の任意の所与のパーセンタイル値に基づいて決定されることができる。このような期間は、ＡＦまたは他のリソース要求エンティティによってなされる予約の期間よりも大幅に長い期間であるべきである。

図面および明細書には、この発明の典型的な好ましい実施例を開示しており、具体的な用語が利用されるが、それらは単に総称的および説明的な意味で使用されており、限定の目的で使用されているのではない。この発明の範囲は特許請求の範囲で説明する。

階層的な帯域幅マネージャの配備を示す。 ピアリングを有する階層的な帯域幅マネージャの配備を示す。

Claims (16)

1. データネットワークにおけるリソースオブジェクトのためにクライアントから要求されるネットワークリソースを予約するよう適合された帯域幅マネージャ（Bandwidth Manager）ＢＭに関連付けられる構成であって、
   前記構成は、前記クライアントからのリソース要求によって規定される必要な第１の量に加えて割当てられるべきリソースの第２の量を決定するための手段を備え、前記決定されるリソースの第２の量は、前記割当てられるリソースの第１および第２の量が、より多くのリソースの要求を許可することにより増大し得る速度に依存することを特徴とする、構成。
2. 前記決定されるリソースの第２の量は、個々のリソースオブジェクトごとに要求されるリソースの平均量に依存することを特徴とする、請求項１に記載の構成。
3. 前記決定されるリソースの第２の量は、個々のリソースオブジェクトごとに前記ＢＭによって発行される予約要求の平均速度に依存することを特徴とする、請求項１から２のいずれかに記載の構成。
4. 前記決定されるリソースの第２の量は、予約要求メッセージの待ち行列によって課される電流信号遅延に依存することを特徴とする、請求項１から３のいずれかに記載の構成。
5. 前記構成は要求されるリソースの総量を決定するための手段を備え、要求されるリソースの量＝σ＋θ＊（１＋ρ）−βであって、σ＝前記リソースの第１の量であり、θ＝前記リソースの第２の量であり、ρ＝前記リソースの第２の量を維持するために設定されるべきパラメータであり、β＝別のＢＭから予約されるリソースの量であることを特徴とする、請求項１から４のいずれかに記載の構成。
6. ρは０より大きいように設定されることを特徴とする、請求項１から５のいずれかに記載の構成。
7. 前記構成は、前記リソース要求によって規定される必要な量から独立して、ベースレベルとして割当てられるべきリソースの量を維持するための手段を備えることを特徴とする、請求項１から６のいずれかに記載の構成。
8. データネットワークにおけるリソースオブジェクトのためにクライアントから要求されるネットワークリソースを予約するための方法であって、
   前記クライアントからのリソース要求によって規定される必要な第１の量に加えて割当てられるべきリソースの第２の量を決定するステップを備え、前記決定されるリソースの第２の量は、前記割当てられるリソースの第１および第２の量が、より多くのリソースの要求を許可することにより増大し得る速度に依存することを特徴とする、方法。
9. 前記決定されるリソースの第２の量は、個々のリソースオブジェクトごとに要求されるリソースの平均量に依存することを特徴とする、請求項８に記載の方法。
10. 前記決定されるリソースの第２の量は、個々のリソースオブジェクトごとに前記ＢＭによって発行される予約要求の平均速度に依存することを特徴とする、請求項８から９のいずれかに記載の方法。
11. 前記決定されるリソースの第２の量は、予約要求メッセージの待ち行列によって課される電流信号遅延に依存することを特徴とする、請求項８から１０のいずれかに記載の方法
    。
12. 前記方法は、
    要求されるリソースの総量を決定するさらに他のステップを備え、要求されるリソースの量＝σ＋θ＊（１＋ρ）−βであって、σ＝前記リソースの第１の量であり、θ＝前記リソースの第２の量であり、ρ＝前記リソースの第２の量を維持するために設定されるべきパラメータであり、β＝別のＢＭから予約されるリソースの量であることを特徴とする、請求項８から１１のいずれかに記載の方法。
13. 前記方法は、
    ρを０より大きく設定するさらに他のステップを備えることを特徴とする、請求項８から１２のいずれかに記載の方法。
14. 前記方法は、前記リソース要求によって規定される必要な量から独立して、ベースレベルとして割当てられるべきリソースの量を維持するための手段を備えることを特徴とする、請求項８から１３のいずれかに記載の方法。
15. データネットワークにおけるルータまたはサーバ内のコンピュータの内部メモリに直接にロード可能なコンピュータプログラムプロダクトであって、請求項７から１４のいずれかのステップを実行するためのソフトウェアコード部分を備える、コンピュータプログラムプロダクト。
16. コンピュータによって使用可能な媒体に格納されたコンピュータプログラムプロダクトであって、データネットワークにおけるルータまたはサーバ内のコンピュータに請求項７から１４のいずれかのステップの実行を制御させるための読取可能なプログラムを備える、コンピュータプログラムプロダクト。

Images