JP2008541553A - 帯域幅管理のための、データネットワークにおける方法および構成 - 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 (14)

1. データネットワークにおける第１のエンティティから要求されるネットワークリソースを予約するおよび戻すよう適合された、リソースを管理できるエンティティに関連付けられる構成であって、前記構成は、前記リソースを管理できるエンティティへの予約要求メッセージの速度を制限するよう適合された第１のメッセージ速度制限器手段（３０１）と、前記リソースを管理できるエンティティへのリソース戻しメッセージの速度を制限するよう適合された第２のメッセージ速度制限器手段（３０２）と、予約要求信号ピーク速度と、前記リソースを管理できるエンティティおよびさらに他のリソースを管理できるエンティティ間の通信のために規定される持続速度との間で前記メッセージ速度制限器を調整するよう適合された少なくとも１つのメッセージ速度推定器手段（３０３）とを備えることを特徴とする、構成。
2. 前記構成は、前記予約要求メッセージおよび前記リソース戻しメッセージを待ち行列に入れるよう適合されたバッファリング手段（３０４）を備えることを特徴とする、請求項１に記載の構成。
3. 前記構成は、予約要求を集約するよう適合された集約手段を備えることを特徴とする、請求項１から２のいずれかに記載の構成。
4. 前記メッセージ速度推定器は、トークンバケットであることを特徴とする、請求項１から３のいずれかに記載の構成。
5. 前記メッセージ速度推定器は、移動平均であることを特徴とする、請求項１から３のいずれかに記載の構成。
6. 前記メッセージ速度推定器は、伝送間隔の履歴を格納するよう適合されたテーブルであることを特徴とする、請求項１から３のいずれかに記載の構成。
7. 第１のエンティティから要求されるネットワークリソースを予約するおよび戻すよう適合された少なくとも１つのリソースを管理できるエンティティを備えるデータネットワークにおける方法であって、
   前記リソースを管理できるエンティティへの予約要求メッセージの速度を制限するステップと、
   前記リソースを管理できるエンティティへのリソース戻しメッセージの速度を制限するステップと、
   予約要求信号ピーク速度と、前記リソースを管理できるエンティティおよびさらに他のリソースを管理できるエンティティ間の通信のために規定される持続速度との間でメッセージ速度を調整するステップとを備えることを特徴とする、方法。
8. 前記方法は、
   前記予約要求メッセージおよび前記リソース戻しメッセージを待ち行列に入れるステップを備えることを特徴とする、請求項７に記載の方法。
9. 前記方法は、
   予約要求を集約するステップを備えることを特徴とする、請求項７から８のいずれかに記載の方法。
10. 前記メッセージ速度は、トークンバケットによって推定されることを特徴とする、請求項７から９のいずれかに記載の方法。
11. 前記メッセージ速度は、移動平均によって推定されることを特徴とする、請求項７から９のいずれかに記載の方法。
12. 前記メッセージ速度は、伝送間隔の履歴を格納するよう適合されたテーブルによって推定されることを特徴とする、請求項７から９のいずれかに記載の方法。
13. データネットワークにおける処理手段に直接にロード可能なコンピュータプログラムプロダクトであって、請求項７から１２のいずれかのステップを実行するためのソフトウェアコード手段を備える、コンピュータプログラムプロダクト。
14. コンピュータによって使用可能な媒体に格納されたコンピュータプログラムプロダクトであって、データネットワークにおける処理手段に請求項７から１２のいずれかのステップの実行を制御させるための読取可能なプログラムを備える、コンピュータプログラムプロダクト。