ノンブロッキングアドミッション制御
ネットワークアクセスを制御するための方法は、ネットワークを介する通信フローを許可するための要求を受信する工程と、要求に対する応答が送信される前に、ネットワークを介する通信フローを一時的に許可する工程とを含む。さらに、１つまたは複数のネットワークリソースにおける利用可能性を判別することができ、この利用可能性は、要求されている通信フローに必要なリソースと比較されてもよい。さらに、通信フローのプライオリティを判別し、利用可能なリソース、要求されたリソース、およびプライオリティに基づいて、一時的に許可された通信フローに応答することができる。
【発明の詳細な説明】
【背景技術】
【０００１】
［0001］ アドミッション制御システムは、帯域幅などのネットワークリソースへのアクセスを、ネットワークリソースに対する要求を許可または拒否することによって仲介する。一般に、アドミッション制御システムは、ネットワークリソースに対する権限が与えられたアクセスを得るために必要な要求−応答メッセージングに関連する遅延の影響を受ける。特定のクラスの高プライオリティのトラフィック、または、遅延許容度の低い特定のユーザーに対しては、アドミッション制御に関連する遅延は、許容できない場合がある。
【０００２】
［0002］ 例えば、手法の１つは、今日の帯域幅ブローカ（bandwidth broker）によって用いられているブロッキングネットワークアドミッション方式を構築することである。ネットワークアドミッションブロッキング方式によれば、全てのアプリケーションは、ネットワークを介して任意のパケットを送る前に、ネットワークアドミッション制御部からの応答を待つ必要がある。したがって、十分な帯域幅が利用可能である場合には特に、通信は不必要に遅れる場合がある。
【０００３】
［0003］ 従来のソリューションは、この問題の一部だけを解決してきた。ソリューションの１つは、オーバープロビジョニング（over-provisioning）であり、この場合、ネットワークは、利用可能な帯域幅の不足が生じることのない十分なリソースによって構築される。しかし、このようなネットワークを構築することは、多大なコストを必要とする。
【０００４】
［0004］ したがって、上記の問題（deficiencies）を鑑みると、十分なリソースと即時アクセスとを提供する、低コストのネットワークが現在、望まれている。
【発明の概要】
【０００５】
［0005］ 本発明の一態様は、ネットワークアクセスを制御するための方法を提供し、この方法は、ネットワークを介する通信フローを許可するための要求を送る工程と、その要求に対する応答が受信される前にそのフローを一時的に開始する工程とを含む。
【０００６】
［0006］ 本発明における別の態様は、ネットワークアクセスを制御するための方法を提供し、この方法は、ネットワークを介する通信フローを許可するための要求を受信する工程と、好ましくは要求に対する応答が送信される前に、ネットワークを介する通信フローを一時的に許可する工程とを含む。この方法は、ネットワークリソースの利用可能性を判別する工程と、要求された通信フローに必要なリソースと、利用可能なリソースとを比較する工程と、通信フローのプライオリティを判別する工程と、利用可能なリソース、要求されたリソース、およびプライオリティに基づいて、一時的に許可された通信フローに応答する工程とをさらに含むことができる。
【０００７】
［0007］ さらに本発明のこの態様によれば、リソースは、帯域幅、待ち時間、ジッタ、および処理時間からなる群から選択される。
【０００８】
［0008］ その上さらに本発明のこの態様によれば、この方法は、プライオリティを指定するために、通信フローにおいて送信されるパケットにマーキングする工程をさらに含むことができる。さらに、この方法は、通信フローのパケットマーキング、通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて、一時的に許可された通信フローに応答するためのポリシーを設定する工程を含むことができる。
【０００９】
［0009］ さらに、この方法は、ネットワークを介して許可された通信フローに割り当てられたリソースを変更する工程を含むことができ、この工程は、許可されたフローより高いプライオリティを有する通信フローのための要求の受信に応じて行われる。
【００１０】
［0010］ さらなる態様によれば、一時的に許可される通信フローは、ネットワークリソースを取っておくことによって事前供給することができる。次に、取っておかれる帯域幅の量は、通信の種類、または、通信のプライオリティの少なくとも１つに基づいて、通信フローごとに変わり得る。通信フローのプライオリティは、パケットマーキングによって指定することができる。プライオリティは、通信フローのコンテンツ、通信フローの種類を定めるアプリケーションなどに基づいていてもよい。したがって、より高いプライオリティでマーキングされたパケットは、通常のマーキングを有するパケットとは別に扱われ得る。この取っておかれる帯域幅は、通信フローをどのように扱うかに関する決定に応じて変更されてもよい。
【００１１】
［0011］ 本発明における別の態様は、ネットワークアクセスを管理するためのシステムを提供し、このシステムは、ネットワークを介して通信するための要求を受信するための入力部と、要求を受信する時にネットワークにおける１つまたは複数の利用可能なリソースを判別するリソース判別ユニットと、ネットワークアドミッションポリシーを記憶するメモリとを含み、ネットワークアドミッションポリシーは、要求に対する応答が送信される前にネットワークを介する一時的通信を許可し、ネットワークアドミッションポリシーは、利用可能な帯域幅、通信によって要求された帯域幅、およびプライオリティの少なくとも１つに基づいて、ネットワークを介して通信するためのどの要求が許可されることになるかを定める。さらに、ネットワークアドミッションポリシー実施ユニットは、ネットワークアドミッションポリシーを実行し、要求に対する応答を送信することができる。一実施形態によれば、このシステムは、ネットワークアドミッションポリシーをユーザーが設定または変更することを可能とするポリシー生成ユニットをさらに含むことができる。さらに、更新機構は、例えば、要求が受信される時にネットワークに対して許可される通信に基づいて、ネットワークアドミッションポリシーを更新することができる。
【００１２】
［0012］ 本発明におけるさらに別の態様は、コンピュータによって実行可能なプログラムを記憶するコンピュータ可読媒体を提供し、このプログラムは、ネットワークへの通信フローを許可するための要求を受信することと、ネットワークへの通信フローを一時的に許可することと、ネットワークにおける利用可能な帯域幅の量を判別することと、要求された通信フローに必要な帯域幅の量と、利用可能な帯域幅の量とを比較することと、通信フローのプライオリティを判別することと、利用可能な帯域幅の量、要求された帯域幅の量、およびプライオリティに基づいて、一時的に許可された通信フローを処理することとを含む。
【００１３】
［0013］ 本発明におけるさらに別の態様は、ネットワークにアクセスするための方法であり、この方法は、クライアントデバイスによって、１つまたは複数のネットワークリソースにアクセスするための要求を送る工程と、要求に対する応答が受信される前に、１つまたは複数のネットワークリソースにアクセスする工程とを含む。
【００１４】
［0014］ 本発明におけるこの態様によれば、この要求は、ネットワークを介する通信フローのための要求を含むことができ、１つまたは複数のネットワークリソースは、帯域幅を含む。さらに、この要求に対する応答は、通信フローを許可する工程、通信フローを終了させる工程、または、通信フローに割り当てられたリソースを変更する工程を含む。
【００１５】
［0015］ その上さらに、この方法は、プライオリティを指定するために、通信フローにおいて送信される１つまたは複数のパケットにマーキングする工程を含むことができる。また、この方法は、アプリケーション層、オペレーティンスシステム、または、エッジルータにおいて１つまたは複数のパケットにマーキングする工程を含むこともできる。さらに、この方法は、クライアントデバイスに対応したポリシーエンジンを用いて、リソースへのアクセスが利用可能となるかどうかを判別する工程を含むことができる。
【００１６】
［0016］ 加えて、判別する工程は、パケットにおけるマーキング、通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて、アクセスを提供するためのポリシーを設定する工程を含むことができる。
【００１７】
［0017］ 本発明における別の態様によれば、ネットワークアクセスを制御するための方法は、ネットワークを介する通信フローを許可するための要求をアプリケーションから受信する工程と、要求された通信フローのプライオリティを判別する工程と、アプリケーションのためのアクセス権を示す応答をアプリケーションに送信する工程とを含むことができる。次に、ネットワークリソースの利用可能性を判別し、ネットワークリソースをアプリケーションに割り当てることができる。さらに、リソースの利用可能性およびプライオリティに基づいて、ネットワークにおける他の通信フローに割り当てられたネットワークリソースが変更されてもよい。
【図面の簡単な説明】
【００１８】
【図１】［0018］本発明の一態様によるアドミッション制御システムを示す図である。
【図２】［0019］本発明の一態様によるアドミッション制御ユニットを示す図である。
【図３】[0020]本発明の一態様によるアドミッション制御方法を示す図である。
【図４】［0021］本発明の一態様によるエンドユーザーデバイスを示す図である。
【図５】［0022］本発明の別の態様によるエンドユーザーデバイスを示す図である。
【図６】［0023］本発明の一態様によるパケット構造を示す図である。
【図７】［0024］本発明の別の態様によるアドミッション制御システムを示す図である。
【発明を実施するための形態】
【００１９】
［0025］ 図１は、ネットワークを介した通信を管理するためのシステム１００を示す。ネットワーク１５０を通じてフローターゲット（flow target）１８０にパケットを送ることを望むフローイニシエータ（flow initiator）１１０は、最初に非同期帯域幅ブローカ１３０に要求を送信することができる。この要求は、インスタントメッセージ（IM）、ボイスオーバーインターネットプロトコル（VoIP）などのアプリケーション用に、一定の時間、一定量の帯域幅を使用するための許可を求めることができる。次に、帯域幅ブローカ１３０は、その要求が許可されたか、または拒否されたかを示す応答をフローイニシエータ１１０に送信することができる。しかし、フローイニシエータ１１０は、フローターゲット１８０にパケットの送信を開始する前に、帯域幅ブローカ１３０からの応答を待つ必要はない。すなわち、フローイニシエータ１１０は、帯域幅ブローカ１３０がアクセスを許可する前にネットワークに入ることを許可され得る（may be admitted to the network）。例えば、フローイニシエータ１１０は、帯域幅ブローカ１３０からの応答を受信する前に、フローイニシエータ１１０がネットワーク１５０を介した送信を開始することができることを取り決めているローカルポリシーエンジン（local policy engine）を含むことができる。帯域幅ブローカ１３０からの応答がフローイニシエータ１１０からの要求を許可する場合、フローイニシエータ１１０は、要求された時間の間、ネットワーク１５０へのアクセスを継続し、指定されたリソースを使うことができる。しかし、帯域幅ブローカ１３０からの応答が要求を拒否する場合には、フローイニシエータ１１０は、通常、そのフローに対するパケットの送信を中止するよう命令されることになる。
【００２０】
［0026］ 本発明の態様によれば、非同期帯域幅ブローカ１３０（asynchronous Bandwidth Broker）すなわちａＢＢ１３０、ならびに、フローの開始を望む任意のポイントまたはノードは、例えば、コードもしくはソフトウェアであるポリシーエンジンまたは付随命令として、ポリシーを実装していることが好ましい。ソースは、一般に、ａＢＢからの応答を受信する前に、どのようにフローを開始し、またどのようにそのフローをマーキングするかについて決定することになるため、通常は、その期間をカバーするためにソース自体のポリシーエンジンを有する必要がある。次いで、ａＢＢのポリシーエンジンは、通常、ソースのローカルポリシーエンジンに事実上優先することになる応答の中の情報の一部を埋めるために用いることができる。
【００２１】
［0027］ 本発明におけるこの態様を実施するシステムの特徴の１つは、ａＢＢからの応答がリソースに対する要求を拒否する場合、その応答は、通常、送信を止めるための命令であるプリエンプション（pre-emption）としてソースに解釈されることになる点である。軍事システムでは、同期帯域幅ブローカすなわちＢＢを有するシステムが存在する。このようなシステムでは、ソースは、ＢＢからの応答を得るまで送信しない。より高いプライオリティのフローが許可されることになる場合、ソースは、プリエンプションのメッセージを後で受信することがあり、その場合には送信を中止する必要がある。商用システムでは、ソースは、ＢＢからの応答が受信されるまで待っている。要求されたリソースをその応答が拒否する場合、フローは許可されずに消滅する。応答が非ゼロである場合、フローは、より高いプライオリティのフローが後に来る場合でも、それらのリソースを保証される。
【００２２】
［0028］ 本発明のさらなる態様によれば、それぞれのポリシーエンジンは、完全なポリシーを有していてもよく、または、そのポリシーエンジンのノード、アプリケーション、もしくは機能に特有である、ポリシーの適合した部分を有していてもよい点に留意されたい。このように、ａＢＢは、通常、ネットワークに生じ得る任意のフローについてプライオリティ、許可するかどうか、およびどのようにマーキングするかの判別を可能にするのに十分なポリシーを有する必要がある。一般には、ａＢＢは、ａＢＢが応答する前にどのようにフローのプライオリティをつけ、フローを許可し、またそのフローをマーキングするかについてポリシーを必要としていない。ソースノードは、通常、ソースノードが生み出し得る任意のフローについてプライオリティをつけ、フローを許可し、またそのフローをマーキングすることを可能とするのに十分なポリシーをそれぞれ必要とする。いくつかの例では、ユーザー、クライアント、またはノードに情報を提供するために、ａＢＢにおける決定の後にそれらのフローをどのように処理するかについてポリシーを有することも有用であり得るが、それは必要ではない。さらには、専用デバイス（例えば、ＶｏＩＰ電話）は、ボイス関連の接続のために、ａＢＢによる決定前のポリシーを単に有することができるが、これは、それらが開始することができる唯一のフローであり得るためである。
【００２３】
［0029］ ネットワーク１５０は、インターネットなどの任意のパブリックネットワークでもよく、または、任意のプライベートネットワークでもよい。例えば、ネットワーク１５０は、インターネット、ローカルエリアネットワーク、または、ワイドエリアネットワークを介して動作する仮想プライベートネットワークでもよい。さらに、ネットワーク１５０は、任意数のサブネットワークを含むことができ、複数の異なるプロトコルまたは規格のうちの任意のものに従って動作してもよい。
【００２４】
［0030］ 図１にはフローイニシエータ１１０およびフローターゲット１８０だけが示されているが、接続されている多数のコンピュータが所与の時間にネットワーク１５０を介して通信していてもよい点を理解されたい。フローイニシエータ１１０およびフローターゲット１８０は、中央処理装置（CPU）、ディスプレイ、ＣＤ−ＲＯＭ、ハードドライブ、マウス、キーボード、モデムなどの、パーソナルコンピュータに通常見られる全ての内部コンポーネントを有する汎用コンピュータでもよい。例えば、フローイニシエータ１１０およびフローターゲット１８０は、モデムを介するか、または、ネットワークカードなどのいくつかの他の通信コンポーネントを介して、ネットワーク１５０を介して通信することができる。フローイニシエータ１１０およびフローターゲット１８０は、人および他のコンピュータからの命令を処理し、また、人および他のコンピュータへデータを送信することが可能な任意のデバイスを備えることができ、このフローイニシエータ１１０およびフローターゲット１８０には、ローカルストレージ機能のないネットワークコンピュータ、モデム付きのＰＤＡ、および、インターネット対応の無線電話が含まれる。また、フローイニシエータ１１０およびフローターゲット１８０は、このようなデバイス上で動作するアプリケーションを含むことができる。例えば、フローイニシエータ１１０上でフローを開始するアプリケーションは、ＶｏＩＰ、ＩＭ、ウェブブラウザ、オンラインゲーム、電子メール、音楽ストリーミングソフトウェアなどでもよい。
【００２５】
［0031］ 同様に、非同期帯域幅ブローカ１３０は、他のコンピュータからの命令を処理し、他のコンピュータにデータを送信することが可能な任意のデバイスでもよい。例えば、帯域幅ブローカ１３０は、汎用コンピュータでもよく、または、ウェブサーバもしくはグループウェアサーバなどの任意の種類の従来型サーバでもよい。
【００２６】
［0032］ 次に図２に移ると、帯域幅ブローカ２３０の詳細図が提供されている。この例では、ネットワークコンピュータ２６２〜２６６（例えば、フローイニシエータ）は、ルータ２６０を介して互いに接続されている。また、ネットワークコンピュータ２６２〜２６６およびルータ２６０には、帯域幅ブローカ２３０が接続されている。帯域幅ブローカ２３０は、ルータ２６０から分離したコンポーネントとして示されているが、ルータ２６０の内部のユニットでもよい点を理解されたい。例えば、帯域幅ブローカ２３０は、ルータ２６０上で動作することができる仮想コンポーネントでもよい。したがって、帯域幅ブローカ２３０およびルータ２６０は、メモリおよび／またはプロセッサなどのコンポーネントを共有することができる。その点に関しては、例えば、クライアントデバイスすなわちフローイニシエータ２６２、２６４、２６６などの全てのホストが同じルータによって処理されることになるわけではない点を理解されたい。
【００２７】
［0033］ 図２の例によれば、帯域幅ブローカ２３０は、様々なフローイニシエータデバイス（flow initiator device）に対する帯域幅の割り当てを管理する際に用いるための複数のコンポーネントを含むことができる。例えば、帯域幅ブローカ２３０は、入力／出力（I/O）ポート２３２、メモリ２３４、アクセスポリシー生成ユニット２４２、および、プロセッサ２４０を含むことができる。プロセッサ２４０は、アクセスポリシー判別ユニット２４３、アクセスポリシー実施ユニット２４４、および、リソース判別ユニット２３６をさらに含むことができる。これらのユニットは、帯域幅ブローカ２３０上で実行可能なソフトウェアモジュールでもよく、または、帯域幅ブローカ２３０における他のコンポーネントとのインタフェースがとられたハードウェアコンポーネントでもよい。さらに、図２ではこれらのユニットが独立したエンティティとして示されているが、いくつかのユニットは、実際には別のコンポーネントの一部でもよい点を理解されたい。例えば、アクセスポリシー生成ユニット２４２は、実際にはメモリ２３４の中に記憶された一組の命令でもよい。
【００２８】
［0034］ プロセッサ２４０は、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ製またはＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ製などの、任意数である周知のハードウェアベースのプロセッサを含むことができる。あるいは、このプロセッサは、ＡＳＩＣなどの、演算を実行するための専用コントローラでもよい。
【００２９】
［0035］ Ｉ／Ｏポート２３２は、ルータ２６０を通じて複数のネットワークコンピュータ２６２〜２６６に接続するために用いることができる。メモリ２３４は、プロセッサ２４０による実行のための命令と、プロセッサ２４０によって検索され、操作され、または記憶されるデータとを含む、プロセッサ２４０によってアクセス可能な情報を記憶する。メモリ２３４は、ハードドライブ、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、書き込み可能なもの、読み出し専用のものなどの、プロセッサによってアクセス可能な情報を記憶することができる任意の種類のものでもよい点を理解されたい。
【００３０】
［0036］ アクセスポリシー生成ユニット２４２は、ネットワークにどの通信フローを許可するかを判別するための判断基準を入力するために、ユーザーに対するインタフェースを提供する。この点に関しては、アクセスポリシー生成ユニット２４２は、メモリ２３４およびＩ／Ｏポート２３２と共に動作して、ユーザーがアクセスポリシーを設定および変更することを可能にしてもよい点を理解されたい。例えば、アクセスポリシー生成ユニット２４２は、通信フローを許可するかどうかの判別がなされるまでネットワークへの一時的アクセスが許可されることを示す一組の命令を受信し、これらの命令を記憶するためにメモリ２３４とのインタフェースをとることができる。また、これらの命令は、このような一時的アクセスに対して利用可能となるネットワーク帯域幅の一部を指定することもできる。さらに、これらの命令は、通信フローにおけるどのアプリケーションと、どのプライオリティレベルとが、帯域幅の利用可能性に応じて許可されることになるかを示すことができる。したがって、アクセスポリシー生成ユニット２４２は、例えば、許可を決定するための数値テーブルおよび／またはアルゴリズムのエントリー及び記憶を行うことができる。さらに、アクセスポリシーは、ネットワークの動作を動的に変えることができる。例えば、ネットワークへのアクセスを許可するためにパケットのマーキングを判定するルール、または、無効にすることを決めるルールは、変更することができる。代替的または付加的に、ネットワークにおける一時的通信のために指定される帯域幅の量は、変更することができる。
【００３１】
［0037］ プロセッサ２４０は、アクセスポリシー生成ユニット２４２を通じて入力された命令を実行することができ、このようなポリシーの実施をもたらし得る。プロセッサ２４０は、例えば、アクセスポリシー判別ユニット２４３、アクセスポリシー実施ユニット２４４、および、リソース判別ユニット２４６を含むことができる。リソース判別ユニット２４６は、ネットワークでどれくらいの帯域幅が所与の時間に利用可能であるかを評価することができる。また、リソース判別ユニット２４６は、要求を出しているアプリケーションによってどれくらいの帯域幅が必要になるかを判別することもできる。プロセッサ２４０は、アクセスポリシー生成ユニット２４２からの命令と共にこの情報を用いて、通信フローがネットワークに入ることを許可するかどうかを判別することができる。すなわち、アクセスポリシー生成ユニット２４２を通じて入力されたポリシーまたは命令は、アクセスポリシー判別ユニット２４３に提供される。フローイニシエータからの要求が受信される場合のように、対象となるイベントが起こると、アクセスポリシー判別ユニット２４３は、ポリシーに基づいて決定を行なう。次にアクセスポリシー判別ユニット２４３は、その決定をアクセスポリシー実施ユニット２４４に伝える。アクセスポリシー実施ユニット２４４は、フローイニシエータに応答を伝える、プロセッサ２４４の中のエンティティでもよい。あるいは、ポリシー実施ユニット２４４は、アクセスポリシー判別ユニット２４３からの応答を受信し、その応答に従って自ら処理するフローイニシエータ自体でもよい。さらに、ポリシー実施ユニット２４４は、ポリシー判別ユニット２４３からの命令に従ってフローイニシエータからのパケットを処理するルータ２６０でもよい。通信が許可されることをプロセッサ２４０が判別する場合、アクセスポリシー実施ユニット２４４は、その通信を許可し、要求を出しているデバイスに応答を送信することができる。しかし、フローを許可することがネットワークに過負荷をかけることになるとプロセッサ２４０が判別する場合には、アクセスポリシー実施ユニット２４４は、所定時間の間、要求を出しているデバイスのさらなる通信を拒否することができる。さらに、アクセスポリシー実施ユニット２４４は、利用可能な帯域幅を増やすために、ネットワークに入ることを既に許可されている通信フローを制御するように用いられてもよい。
【００３２】
［0038］ 図２では同じブロックの中にメモリ２３４とプロセッサ２４０が機能的に示されているが、プロセッサおよびメモリは、実際には同一の物理的ハウジングの中に格納されていても格納されていなくてもよい複数のプロセッサと、複数のメモリとを含むことができる点が、当業者によって理解されるであろう。例えば、命令およびデータの一部または全ては、取り外し可能なＣＤ−ＲＯＭに記憶されてもよく、他のものは、読み出し専用のコンピュータチップの中に記憶されてもよい。命令およびデータの一部または全ては、プロセッサから物理的に離れている場所であって、その上さらに、そのプロセッサによってアクセス可能な場所に記憶されていてもよい。同様に、プロセッサは、実際には並列に動作してもしなくてもよいプロセッサの集まりを含むことができる。
【００３３】
［0039］ 図１〜図２に示されている動作に加えて、本方法の様々な態様による動作を次に説明する。下記の動作は、以下で説明される正確な順序で行なわれる必要はない点を理解されたい。むしろ、様々な工程は、逆の順序で、または同時に処理されてもよい。
【００３４】
［0040］ 図３には、帯域幅の割り当てを管理する方法３００が示されている。この方法３００によれば、帯域幅に対する要求が受信され、その要求は、ネットワークにおいて利用可能な帯域幅の判別と、その要求のプライオリティとに基づいて処理される。
【００３５】
［0041］ 工程３１０では、（例えば、フローイニシエータ１１０からの）帯域幅に対する要求が、帯域幅ブローカ１３０によって受信される。この要求は、どのアプリケーション（例えば、ＩＭ、ＶｏＩＰ、ウェブブラウザなど）がネットワーク１５０にアクセスすることを望んでいるか、要求されているアクセスの継続時間、そのようなアクセスに要求される帯域幅の量などの、様々な情報を含むことができる。さらに、この要求は、ネットワークアクセスにおけるプライオリティの識別を含むことができる。例えば、この要求は、要求されているアクセスを、単にいくつかの例として、緊急、早急、ｘ分待機可、または低プライオリティとして識別することができる。アクセスのプライオリティを指定するために、カラー、コードなどの任意の種類の目印（indicia）を用いることができる点を理解されたい。
【００３６】
［0042］ フローイニシエータ１１０は、帯域幅ブローカ１３０からの応答を待つことなく、要求された通信を開始することができる（すなわち、ネットワーク１５０を介してパケットの送信を開始することができる）。
【００３７】
［0043］ 工程３２０では、帯域幅ブローカ１３０は、要求を満たすのに十分な帯域幅がネットワーク１５０上で利用可能であるかどうかを判別する。例えば、リソース判別ユニット２４６は、ネットワークを通じた既存の通信によってどれくらいの帯域幅が既にとられているかを推定し、要求を出しているデバイスによる追加の帯域幅の使用がネットワーク１５０にどれだけ影響を与えることになるかを評価することができる。
【００３８】
［0044］ 十分な帯域幅がネットワーク１５０において利用可能であり、それによって、ネットワークを通じた他の通信は、フローイニシエータ１１０による帯域幅の追加の使用によって影響を受けないことが、帯域幅ブローカ１３０によって判別される場合がある。したがって、このような通信は、工程３２５で承認され得る。あるいは、フローイニシエータ１３０がネットワーク１５０にアクセスすることを許可することが、ネットワークにおけるいくらかの輻輳をまねくことになると判別される場合がある。ネットワーク１５０におけるいくらかの輻輳は許容できる場合がある一方で、ネットワーク１５０にある程度まで過負荷をかけることは許容できない場合がある。したがって、ネットワーク１５０に著しく負担をかけることのない通信も、工程３２５で承認され得る。承認は、例えばフローイニシエータ１１０に応答を送信することによって、フローイニシエータ１１０に示されてもよい。フローイニシエータ１１０は、ネットワーク１５０を介して既に通信を開始している可能性があるため、そのフローイニシエータ１１０は、単にそれを継続して行なうことができる。また、非同期帯域幅ブローカ１３０からの応答は、多かれ少なかれいくらかのリソースをフローイニシエータ１１０に使用させるようにして、利用可能なリソースを指定することもできる。例えば、フローイニシエータのローカルポリシーエンジンによって用いられる暫定的ポリシーは、ＶｏＩＰフローが、プライオリティレベル３としてマーキングされたパケットによって開始可能であることを指定する場合がある。非同期帯域幅ブローカ１３０のポリシーと、ネットワーク状態の判別とに基づく、非同期帯域幅ブローカ１３０からの応答は、代わりにプライオリティ５でパケットがマーキングされることを指定する場合がある（この場合、５は、より高いプライオリティでもよく、または、より低いプライオリティでもよい）。
【００３９】
［0045］ 工程３２０において、フローイニシエータ１１０からネットワーク１５０へのフローを許可することがネットワーク１５０に過度の負担をかけることになると判別された場合、要求されている通信のプライオリティを工程３３０で評価することができる。このような評価は、帯域幅ブローカ１３０、ルータ、または、このようなコンポーネントの組み合わせによって行なわれてもよい。一態様によれば、この評価によって、要求されている通信のプライオリティと、ネットワーク１５０にアクセスしている通信のプライオリティとが比較され得る。別の態様によれば、この評価によって、所定レベル以上の任意レベルのプライオリティがネットワーク１５０に対して許可されることが、判別され得る。プライオリティは、通信の重要度に基づくものでもよく、いくつかの実施形態では、特定のアプリケーション用に要求された帯域幅に基づくものでもよい。例えば、要求されているＶｏＩＰ通信とインスタントメッセージとは、ほぼ同じ重要度を有し得るが、インスタントメッセージは、より少ない帯域幅を使用することから、ＶｏＩＰ通信を上まわるプライオリティをとることができる。この評価によって、その通信が優先するという決定がもたらされる場合、その通信は承認され得る（工程３２５）。
【００４０】
［0046］ 可能性のある選択肢の１つは、例えば別のフローに先に割り当てられたリソースを減らすことによって、工程３３５で所定の量の帯域幅を開放することであり得る。プライオリティのつけられた通信が可能である場合、この所定の量は、ネットワーク１５０からの輻輳を緩和するのに十分なものでもよい。例えば、開放される帯域幅の量は、フローイニシエータ１１０によって要求された帯域幅の量とほぼ同じでもよい。あるいは、帯域幅の量は一定の値でもよい。
【００４１】
［0047］ 非同期帯域幅ブローカは、複数の方法のうちの任意の方法で帯域幅を開放することができる。例えば、ネットワーク１５０を介する全てのフローにおける帯域幅の許容量を下げることができる。代替的または付加的に、任意のアプリケーション自身に割り当てられた帯域幅をその任意のアプリケーションがもはや利用していないかどうかを判別して、そのような帯域幅を再度割り当てることができる。さらに別の可能性は、例えば最も低いプライオリティである、所定のプライオリティの通信が一時停止または終了され得ることである。
【００４２】
［0048］ 工程３３０におけるプライオリティの評価が、要求されている通信が優先しないという決定をもたらす場合、フローイニシエータ１１０によって送信された帯域幅に対する要求は、工程３４０において拒否され得る。これには、要求が拒否されたことを示す、フローイニシエータ１１０へのメッセージの送信が含まれる。一態様によれば、これは、フローイニシエータ１１０によって既に開始されている、ネットワーク１５０を介したパケットの送信の終了も含み得る。さらに、非同期帯域幅ブローカは、先だって送られたパケットを削除するよう、ネットワークのルータに命令することができる。
【００４３】
［0049］ ネットワークの帯域幅に対するアクセスを提供する場合において本発明が説明されたが、これらの説明は例示的に過ぎない。概して、本発明は、任意のネットワークリソースにおける仲介（brokering）が存在する場合に適用することができる。これらのネットワークリソースには、例えば、待ち時間、ジッタ、または、ネットワーク構成要素の処理時間が含まれ得る。
【００４４】
［0050］ 本発明の一態様によれば、ネットワーク１５０を介する通信のプライオリティは、パケットにおけるマーキングによって指定することができる。このマーキングは、任意の種類の所定コードを含むことができる。プライオリティレベルの設定は、コンテンツ、アプリケーション、ユーザー定義の要件、重み、または、これらもしくは他のパラメータの任意の組み合わせに基づいていてもよい。
【００４５】
［0051］ 図４に示されているように、マーキングは、フローイニシエータ４１０などのコンピューティングデバイス上で動作しているアプリケーション（例えば、要素４１２、４１４、４１６によって示されているアプリケーション１〜３）によって行うことができる。フローイニシエータ４１０は、アプリケーション４１２〜４１６と通信して、それらのアプリケーション４１２〜４１６を制御するオペレーティングシステムのカーネル４２０を含むことができる。それぞれのアプリケーション４１２、４１４、４１６は、パケットマーキングユニット４１３、４１５、４１７などの、パケットマーキングを行なうユニットを含むことができる。例えば、アプリケーション４１２がインスタントメッセージのアプリケーションである場合、そのアプリケーションは、パケットを「５」または「低遅延」として常に指定することができる。あるいは、アプリケーション４１２は、用いるマーキングに関して、ユーザーからの入力を受信することができる。そのため、同じ例に従うと、インスタントメッセージのアプリケーションを用いて送られるパケットは、「１」または「重要」に変更されてもよい。
【００４６】
［0052］ 図５には代替実施形態が示されている。例えば、アプリケーション５１２、５１４、５１６は、パケットマーキングを行なうよう当てにされていなくてもよい。そのため、パケットマーキングは、フローイニシエータ５１０のオペレーティングシステム５２０によって行なうことができる。すなわち、アプリケーション５１２〜５１６は、パケットをオペレーティングシステム５２０に送信することができる。オペレーティングシステム５２０は、アプリケーション５１２〜５１６によって送られたパケットにマーキングを割り当てるパケットマーキングモジュール５２５を含むことができる。図４の例と同様に、このマーキングは、アプリケーション、コンテンツ、または、ユーザー定義の設定に基づくものでもよい。
【００４７】
［0053］ 図６は、ネットワーク１５０を通じて送信される、マーキングされたパケットの構造を示す。この例では、ネットワーク１５０は、ＩＰｖ４ネットワークである。しかし、本発明の原理は、プライオリティをパケットのヘッダーで示す手段を提供する任意のネットワークで実装することができる点を理解されたい。さらに、プライオリティを有さないネットワークでは、本発明は、ネットワークにおけるより大雑把な制御を非同期帯域幅ブローカが有するという制約によって依然として作用することになる。加えて、フローイニシエータのポリシーは、輻輳の面でネットワークがよりいっそう優雅さを欠いて退化することになるため、より従来型に近いものになる。パケットは、インターネットプロトコル（IP）のバージョンと、ＩＰヘッダー長とに関する情報を含むヘッダー６１０を含む。ＩＰバージョンは、インターネットヘッダーのフォーマットを示す。ＩＰヘッダー長は、３２ビットワードにおけるインターネットヘッダーの長さであり、すなわち、データの始まりまでのポイント（point）である。
【００４８】
［0054］ サービスフィールドのタイプ６２０は、所望のサービス品質におけるアブストラクトパラメータ（abstract parameter）の表示を行なう。これらのパラメータは、ネットワーク１５０を通じてパケットを送信する際に、実際のサービスパラメータの選択をガイドする。したがって、サービスフィールドのタイプ６２０は、パケットをどのように扱うかをルータなどが判別できる値を記憶することによって、プライオリティを示すことができる。
【００４９】
［0055］ 合計長フィールド６３０は、インターネットヘッダーとデータを含む、オクテットで測られたパケットの長さである。このフィールドは１６ビットでもよい。
【００５０】
［0056］ 識別フィールド６４０は、パケットの断片を組み立てるときに支援するための識別値を含むことができる。この値は、送信するデバイスによって割り当てられてもよく、また１６ビットの長さでもよい。
【００５１】
［0057］ フラグおよび断片オフセットフィールド６５０は、断片化が可能となっているかどうか、その断片が最後の断片か、または断片がまだあるか、などの様々な制御フラグを含むことができる。また、フラグおよび断片オフセットフィールド６５０は、パケットの中でこの断片が属する場所を示すこともできる。
【００５２】
［0058］ ソースアドレスフィールド６６０および宛先アドレスフィールド６７０は、パケットのソースと宛先をそれぞれ特定することができる。
【００５３】
［0059］ オプションフィールド６８０は、送信されても送信されなくてもよい情報を含む。このような情報の例には、セキュリティ、ルーズソースルーティング、ストリクトソースルーティング、インターネットタイムスタンプなどが含まれる。ペイロードフィールド６９０は、送信される実際のデータを含むことができる。上記の通り、このデータは、パケットに対する適切なマーキングを判別する際に考慮され得る。図７は、本発明の態様に従って帯域幅を管理する例を示す。特に、この例は、図４および図５に関して用いられた技術とは対照的である、パケットマーキングの別の方法を提供する。特に、パケットマーキングを行なうことにフローイニシエータが当てにされていない場合、この手法を用いることができる。
【００５４】
［0060］ この例では、複数のフローイニシエータ７１０〜７１５が、ネットワーク７５０上で動作している。ネットワーク７５０は、通信と、比較的高スピードである複数のアプリケーションの間におけるリソース共有とを可能にする企業ネットワークでもよい。リソースは、非同期帯域幅ブローカによって、ネットワーク７５０を介するそれぞれのフローに割り当てることができる。フローイニシエータ７１０〜７１５は、ネットワーク７５０上のデバイスだけでなく、ネットワーク７５０を越えた他のデバイスとも通信することができる。例えば、ネットワーク７５０は、ルータ７６０を通じて他のネットワークに接続されていてもよい。他のネットワークは、別の企業ネットワーク、または、より低速なネットワークなどの、任意の種類のネットワークでもよい。この例では、エッジルータ７６０は、シェーピング（shaping）とポリシング（policing）（すなわち、非同期帯域幅ブローカによって許可されたリソース範囲を超えるパケットを遅らせること、または削除すること）を行なうことができる。
【００５５】
［0061］ フローイニシエータ７１２は、インスタントメッセージを介してフローイニシエータ７１４および７１５と通信していてもよい。非同期帯域幅ブローカは、このような通信にネットワーク７５０における２０％の帯域幅を割り当てることができ、送信されるパケットは、非同期帯域幅ブローカによって「５」のマーキングを割り当てられてもよい。同時に、フローイニシエータ７１３は、エッジルータ７６０を介して、このネットワークを越えたデバイスとＶｏＩＰセッションを行なっていてもよい。このＶｏＩＰセッションは、ネットワーク帯域幅の６５％を割り当てられていてもよく、送信されるパケットは、非同期帯域幅ブローカによって「３」のマーキングを割り当てられていてもよい。さらに同時に、フローイニシエータ７１１は、インターネットダウンロードを開始するための要求を出すことができる。したがって、フローイニシエータ７１１は、帯域幅に対する要求を非同期帯域幅ブローカに送信することができる。非同期帯域幅ブローカは、ルータ７６０などの図示されている任意のデバイス、または、ネットワーク７５０における他の場所、または、ルータ７６０を越えた比較的大きいネットワークにおけるどこかの場所に、一緒に配置されていても一緒に配置されていなくてもよい。あるいは、非同期帯域幅ブローカは、独立して存在していてもよい。要求は、アプリケーション（すなわち、ウェブダウンロード）、プライオリティ（例えば、低遅延）、ダウンロードの推定時間（例えば、１５分）、および、要求されるおおよその帯域幅（例えば、１０Ｍｂｐｓ）を指定することができる。フローイニシエータ７１１は、帯域幅ブローカからの応答を待つ前に、ダウンロードを開始することができる。その間に、帯域幅ブローカは、要求された１０Ｍｂｐｓがネットワークの帯域幅能力の１５％であり、ネットワーク７５０を介して通信している他のデバイスのために１５％だけが利用可能であることを判別することができる。帯域幅ブローカは、それ以外の場合にはネットワークにおける過剰な輻輳のリスクを避けるためにこのような通信を拒否することができる一方で、その要求がアプリケーション用の高いプライオリティを指定していることを認識することができる。したがって、帯域幅ブローカは、帯域幅に対するその要求を許可することができる。ルータ７６０は、パケットに「２」のマーキングを割り当てることができる。帯域幅ブローカは、ネットワークにおける帯域幅の利用可能性を増すために、５でマーキングされたパケットのアクセスの許可を中止することができる。
【００５６】
［0062］ フローイニシエータは、アドミッション制御要求の送信と、帯域幅ブローカからのアドミッション制御応答の受信との間の一時的期間にネットワークへのアクセスの開始を許可されているため、そのネットワークは、その期間に必要以上の申し込みを受ける可能性がある。許可されている通信フローに対するネットワークにおける影響は、１つまたは複数の技術によって、この一時的期間の間に最小にすることができる。これらの技術は、例えばアクセスポリシー判別ユニット２４３で実装することができる。
【００５７】
［0063］ 許可されたフローに対する影響を最小にする第１の方法によれば、ネットワーク帯域幅の構成可能比率（α）を、一時的期間におけるフロー用にとっておくことができる。一時的期間におけるそれぞれのトラフィックフローは、このあらかじめ割り当てられた帯域幅のうちの構成可能比率（β）を利用するように許可され得る。したがって、一時的期間における任意の単一フローに対する利用可能な帯域幅は、ネットワーク帯域幅の（β×α）を超えないことになる。区分されたクラスのサービスを有するネットワークの場合には、ネットワーク帯域幅におけるこのような構成可能比率は、ベストエフォート（または、アドミッション制御が想定されていないクラス）を除いて、それぞれのクラスのサービス用にとっておくことができる。
【００５８】
［0064］ ネットワークが非常にリソース制限されている場合には、ポリシーは、一時的フローに対してリソースが事前提供されないものとなり得る。このような場合、帯域幅ブローカが許可の決定を行なう前にネットワークにアクセスするためには、ポリシーは、高プライオリティのフローだけが許可されるか、または、どのようなフローも許可されないものとなり得る。付加的または代替的に、ネットワークに入ることを既に許可されている低プライオリティのフローは、一時停止または終了されてもよい。一時的期間においてネットワークの１００％がフローに対して利用可能である極端な別の例では、許可前のフローは、許可後のフローと同じアクセスを有する。
【００５９】
［0065］ 一時的期間においてフローの影響を最小にするための別の方法は、ベストエフォートを利用することである。すなわち、一時的期間におけるフローは、「ベストエフォート」のパケットマーキングを用いてそれらのフローのデータを送り、アプリケーションは、必要なときにいつでも、任意の品質で、許可を要求せずに、または、最初にネットワークに知らせることなく、データを送る。ベストエフォートのサービスの場合、ネットワークは、信頼性、遅延範囲、またはスループットにおけるいかなる保証もない状態で、可能な場合にデータを送出する。このような分類は、例えばサービスフィールドのタイプ６２０において、パケットマーキングに含まれてもよい。ネットワークが必要以下の申し込みを受けている場合にこのマーキングを用いることは、一時的フローによって受けるサービス品質に影響を与えない。しかし、ネットワークが必要以上の申し込みを受けている場合、ベストエフォートのマーキングを用いることは、十分でないレベルのサービスを一時的フローが受ける原因となる場合があり、いくつかの例では、一時的フローは、ネットワークを通じてパケットを全く送ることができない場合がある。したがって、この一時的フローは、許可されたフローに影響を与えないことになる。
【００６０】
［0066］ 許可されたフローに対する影響を最小にするさらに別の方法は、帯域幅をとっておく方法の要素と、ベストエフォートを利用する方法の要素とを組み合わせることができる。この方法によれば、一時的期間のためにあらかじめ割り当てられる帯域幅は、火災警報などの特定の高プライオリティのトラフィックに用いることができる。残りの一時的フローは、アドミッション制御の決定を待ちながらベストエフォートを利用することができる。用いられる手法の決定は、動的ポリシー更新機構を用いて動的に構成することができる。例えば、この機構は、アクセスポリシー生成ユニット２４２の中に実装することができる。この手法を用いて、フローが開始される時間ごとに、（アプリケーションによって要求される帯域幅、ネットワークの現行状態、１日のうちの時間帯、アプリケーションを動作させているユーザーの役割、アプリケーションの地理的／トポロジー的位置などを含む複数の要因に依存し得る）現在のポリシーがチェックされる。非同期帯域幅ブローカは、大概は、ポリシー判別ユニット２４３を用いて適正なマーキングを判別し、そのマーキングを応答の一部としてフローイニシエータに送ることになる。しかし、非同期帯域幅ブローカは、ポリシー判別ユニット２４３とやり取りして、フローイニシエータが分類ｘに割り当てられていることをそのフローイニシエータに通知することができる。次に、フローイニシエータにおけるポリシー判別ユニット２４３は、その分類ｘを、アプリケーションのタイプ、ノードの位置などの他の要因と共に用いて、パケットごとにマーキングを判別する。そのようにして、ノードが移動している場合には、パケットのマーキングは、非同期帯域幅ブローカと再度やり取りすることを必要とせずに時間にわたって変化する場合がある。
【００６１】
［0067］ 本発明の一態様によれば、ネットワークが現在直面している状況より厳しい状況においていくつかのアプリケーションが有することになる帯域幅の割り当てを、それらのアプリケーションに与えるようにアクセスポリシーを構成することができる。例えば、一時的期間の間、非緊急のアプリケーションは、ネットワークが災害モードにある場合に与えられることになるリソースを与えられてもよい。帯域幅ブローカは、許可のための要求に対して応答する場合は、現在のネットワーク動作に対応しているリソースをアプリケーションに与えることになる。同様に、一時的期間の間にそれぞれのフローイニシエータに割り当てられる帯域幅は、アプリケーションに対する影響に基づくものでもよい。例えば、ＶｏＩＰのアプリケーションは、最初は主に、低い帯域幅の、待ち時間の影響を受けにくい（latency insensitive traffice）トラフィックを送る。通話設定が完了する前に、許可要求に対する応答がＶｏＩＰのアプリケーションによって受信されることが予想される場合、最初の帯域幅の割り当ては、通話設定の要件に基づいて設定されている可能性がある。したがって、応答が受信される前にビデオが始まる場合、帯域幅の高いビデオがネットワークを圧倒しないことが確実なものとなる。
【００６２】
［0068］ また、ネットワークの構成は、一時的動作を制御するために利用することもできる。例えば、区分されたサービスを有するネットワークでは、大概は一時的トラフィックを制限するためのパケットマーキングに対する帯域幅の割り当ては、ネットワークにおける現在の動作に応じて下げられてもよく、または、上げられてもよい。さらに、パケットマーキングは、一時的トラフィックと、許可されたトラフィックとが同じパケットマーキングを用いることのないように選択されてもよい。このように、ポリシー実施ユニット２４４またはルータ２６０は、現在のネットワーク状態に基づいて構成することができる。例えば、それぞれのクラスのサービスは、１つは奇数、１つは偶数である、隣接したパケットマーキングに対して提供されてもよい。奇数値は、一時的トラフィックへの割り当て用に、アプリケーションに利用可能となる。偶数値は、ネットワークの許可によって提供されることになる。通常動作では、それぞれのパケットマーキングのペアは、全く同様に扱われることになる。しかし、危機的状況においては、非緊急の一時的パケットマーキング、ならびに、帯域幅の高いアプリケーションに利用可能な一時的パケットマーキングは、削減される場合があり、一方、緊急の一時的パケットマーキングは、緊急のトラフィックとして継続して処理されることになる。対照的に、ネットワークが攻撃を受けている場合、緊急の一時的パケットマーキングは、（アタッカーに対する誘惑の対象と同様に）削減される可能性がある。
【００６３】
［0069］ 本発明の別の態様によれば、要求を出している通信フローに対するアクセスを許可する応答が与えられた後に、ネットワークのプロビジョニングが行なわれてもよい。これは、ネットワークのプロビジョニングが高価である場合には特に有益であり得る。例えば、いくつかのネットワークでは、往復時間（すなわち、アプリケーションからの要求を帯域幅ブローカに送信するための時間と、その要求に対する帯域幅ブローカからの応答を送信するための時間）は、比較的短い可能性がある。したがって、フローイニシエータは、ネットワークを介してパケットを送る前に、通信フローが許可されることを示す帯域幅ブローカからの応答を待つように求められる場合がある。それでもなお、ネットワークへのアクセスは比較的迅速に得られることになる。通信フローを許可するか、または拒否するかの決定は、フローのプライオリティ、フローに必要なおおよその帯域幅などの複数の要因のうちの任意の要因に基づいたものでもよい。次に、帯域幅ブローカは、ネットワークのプロビジョニングを行なうことができる。
【００６４】
［0070］ ネットワークをプロビジョニングする場合、帯域幅ブローカは、ネットワークにおけるリソースの利用可能性を評価することができ、また、そのようなリソースを使う通信フローのプライオリティを考慮することもできる。したがって、帯域幅ブローカは、ネットワークにおける通信フローに対するリソースを再度割り当てることができる。これは、パケットの送信を止めるか、もしくは、使われる帯域幅の量を減らす必要のあるデバイスまたはアプリケーションにメッセージを送信することを含み得る。例えば、初めにアクセスを要求したフローイニシエータは、要求されたフローに対する帯域幅の量を制限する、フローマネージャからの更新を受信する場合がある。さらなる例としては、ネットワークを介して既に通信しているアプリケーションは、それらのリソース使用を制限するメッセージを受信する場合がある。一部のデバイスまたはアプリケーションは、増加した量のリソースを割り当てられてもよい。付加的または代替的に、帯域幅ブローカは、再度割り当てるリソースに対して、既により厳密になされた割り当てを実施することができる。例えば、帯域幅ブローカは、特定のフローに対して帯域幅の制限を実施するようルータに命令することができる。
【００６５】
［0071］ 本発明は、緊急である短時間の通信フローが、アクセスが許可されたという応答を待つことなく、ネットワークを介して即座に通信することが可能になるという点で有利である。さらに、先に許可されたフローのサービス品質は、通常、大きくは影響されないことになる。最悪の場合、先に許可されたフローのサービス品質は、ネットワークが必要以上に申し込まれることになるため、許可の判定がなされるまで一時的に悪化することがある。
【００６６】
［0072］ さらに、本発明は、通常はネットワークが必要以下の申し込みを受けている場合に対して最適化を行なう。冗長性、将来の発展に向けた要件のために、または、単にネットワークが構築される際に適用負荷が十分にわかっていないために、多くのネットワークは、必要な容量より多くの容量を有している。この場合には、アドミッション制御の決定を待つことは、ほんのわずかな利点しか有することのないオーバーヘッドをもたらす。しかし、不具合が発生し、ネットワークが突然必要以上の申し込みを受けることになると、ネットワークのアドミッション制御（および、プリエンプション）は、多くの場合、そのネットワークが価値を提供し続けることができる唯一の方法となる。本発明は、これを低いオーバーヘッドで可能にする。
【００６７】
［0073］ さらに、本発明は、サービスの品質が維持されるタイムリーな方法によって、緊急のフローがネットワークで動作することを可能にする。例えば、火災警報が作動する場合、送られるデータの量は、ネットワークに影響を与えるのに十分に多くはないが、送られるデータは緊急である。それでもなお、帯域幅ブローカがそのフローに気づいていることが重要であり、それによって、多くの火災警報が同時に作動している場合には、その帯域幅ブローカは、ネットワークに必要以上の申し込みを行なうことになる他のトラフィックの許可を回避することができる。
【００６８】
［0074］ 本明細書において、特定の実施形態を参照して本発明が説明されたが、これらの実施形態は、本発明の原理と応用を例示しているに過ぎない点を理解されたい。したがって、例示的実施形態に対して様々な変更がなされてもよく、また、添付の特許請求の範囲によって定義されている本発明の趣旨および範囲から逸脱することなく他の構成が考案され得る点を理解されたい。
【背景技術】
【０００１】
［0001］ アドミッション制御システムは、帯域幅などのネットワークリソースへのアクセスを、ネットワークリソースに対する要求を許可または拒否することによって仲介する。一般に、アドミッション制御システムは、ネットワークリソースに対する権限が与えられたアクセスを得るために必要な要求−応答メッセージングに関連する遅延の影響を受ける。特定のクラスの高プライオリティのトラフィック、または、遅延許容度の低い特定のユーザーに対しては、アドミッション制御に関連する遅延は、許容できない場合がある。
【０００２】
［0002］ 例えば、手法の１つは、今日の帯域幅ブローカ（bandwidth broker）によって用いられているブロッキングネットワークアドミッション方式を構築することである。ネットワークアドミッションブロッキング方式によれば、全てのアプリケーションは、ネットワークを介して任意のパケットを送る前に、ネットワークアドミッション制御部からの応答を待つ必要がある。したがって、十分な帯域幅が利用可能である場合には特に、通信は不必要に遅れる場合がある。
【０００３】
［0003］ 従来のソリューションは、この問題の一部だけを解決してきた。ソリューションの１つは、オーバープロビジョニング（over-provisioning）であり、この場合、ネットワークは、利用可能な帯域幅の不足が生じることのない十分なリソースによって構築される。しかし、このようなネットワークを構築することは、多大なコストを必要とする。
【０００４】
［0004］ したがって、上記の問題（deficiencies）を鑑みると、十分なリソースと即時アクセスとを提供する、低コストのネットワークが現在、望まれている。
【発明の概要】
【０００５】
［0005］ 本発明の一態様は、ネットワークアクセスを制御するための方法を提供し、この方法は、ネットワークを介する通信フローを許可するための要求を送る工程と、その要求に対する応答が受信される前にそのフローを一時的に開始する工程とを含む。
【０００６】
［0006］ 本発明における別の態様は、ネットワークアクセスを制御するための方法を提供し、この方法は、ネットワークを介する通信フローを許可するための要求を受信する工程と、好ましくは要求に対する応答が送信される前に、ネットワークを介する通信フローを一時的に許可する工程とを含む。この方法は、ネットワークリソースの利用可能性を判別する工程と、要求された通信フローに必要なリソースと、利用可能なリソースとを比較する工程と、通信フローのプライオリティを判別する工程と、利用可能なリソース、要求されたリソース、およびプライオリティに基づいて、一時的に許可された通信フローに応答する工程とをさらに含むことができる。
【０００７】
［0007］ さらに本発明のこの態様によれば、リソースは、帯域幅、待ち時間、ジッタ、および処理時間からなる群から選択される。
【０００８】
［0008］ その上さらに本発明のこの態様によれば、この方法は、プライオリティを指定するために、通信フローにおいて送信されるパケットにマーキングする工程をさらに含むことができる。さらに、この方法は、通信フローのパケットマーキング、通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて、一時的に許可された通信フローに応答するためのポリシーを設定する工程を含むことができる。
【０００９】
［0009］ さらに、この方法は、ネットワークを介して許可された通信フローに割り当てられたリソースを変更する工程を含むことができ、この工程は、許可されたフローより高いプライオリティを有する通信フローのための要求の受信に応じて行われる。
【００１０】
［0010］ さらなる態様によれば、一時的に許可される通信フローは、ネットワークリソースを取っておくことによって事前供給することができる。次に、取っておかれる帯域幅の量は、通信の種類、または、通信のプライオリティの少なくとも１つに基づいて、通信フローごとに変わり得る。通信フローのプライオリティは、パケットマーキングによって指定することができる。プライオリティは、通信フローのコンテンツ、通信フローの種類を定めるアプリケーションなどに基づいていてもよい。したがって、より高いプライオリティでマーキングされたパケットは、通常のマーキングを有するパケットとは別に扱われ得る。この取っておかれる帯域幅は、通信フローをどのように扱うかに関する決定に応じて変更されてもよい。
【００１１】
［0011］ 本発明における別の態様は、ネットワークアクセスを管理するためのシステムを提供し、このシステムは、ネットワークを介して通信するための要求を受信するための入力部と、要求を受信する時にネットワークにおける１つまたは複数の利用可能なリソースを判別するリソース判別ユニットと、ネットワークアドミッションポリシーを記憶するメモリとを含み、ネットワークアドミッションポリシーは、要求に対する応答が送信される前にネットワークを介する一時的通信を許可し、ネットワークアドミッションポリシーは、利用可能な帯域幅、通信によって要求された帯域幅、およびプライオリティの少なくとも１つに基づいて、ネットワークを介して通信するためのどの要求が許可されることになるかを定める。さらに、ネットワークアドミッションポリシー実施ユニットは、ネットワークアドミッションポリシーを実行し、要求に対する応答を送信することができる。一実施形態によれば、このシステムは、ネットワークアドミッションポリシーをユーザーが設定または変更することを可能とするポリシー生成ユニットをさらに含むことができる。さらに、更新機構は、例えば、要求が受信される時にネットワークに対して許可される通信に基づいて、ネットワークアドミッションポリシーを更新することができる。
【００１２】
［0012］ 本発明におけるさらに別の態様は、コンピュータによって実行可能なプログラムを記憶するコンピュータ可読媒体を提供し、このプログラムは、ネットワークへの通信フローを許可するための要求を受信することと、ネットワークへの通信フローを一時的に許可することと、ネットワークにおける利用可能な帯域幅の量を判別することと、要求された通信フローに必要な帯域幅の量と、利用可能な帯域幅の量とを比較することと、通信フローのプライオリティを判別することと、利用可能な帯域幅の量、要求された帯域幅の量、およびプライオリティに基づいて、一時的に許可された通信フローを処理することとを含む。
【００１３】
［0013］ 本発明におけるさらに別の態様は、ネットワークにアクセスするための方法であり、この方法は、クライアントデバイスによって、１つまたは複数のネットワークリソースにアクセスするための要求を送る工程と、要求に対する応答が受信される前に、１つまたは複数のネットワークリソースにアクセスする工程とを含む。
【００１４】
［0014］ 本発明におけるこの態様によれば、この要求は、ネットワークを介する通信フローのための要求を含むことができ、１つまたは複数のネットワークリソースは、帯域幅を含む。さらに、この要求に対する応答は、通信フローを許可する工程、通信フローを終了させる工程、または、通信フローに割り当てられたリソースを変更する工程を含む。
【００１５】
［0015］ その上さらに、この方法は、プライオリティを指定するために、通信フローにおいて送信される１つまたは複数のパケットにマーキングする工程を含むことができる。また、この方法は、アプリケーション層、オペレーティンスシステム、または、エッジルータにおいて１つまたは複数のパケットにマーキングする工程を含むこともできる。さらに、この方法は、クライアントデバイスに対応したポリシーエンジンを用いて、リソースへのアクセスが利用可能となるかどうかを判別する工程を含むことができる。
【００１６】
［0016］ 加えて、判別する工程は、パケットにおけるマーキング、通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて、アクセスを提供するためのポリシーを設定する工程を含むことができる。
【００１７】
［0017］ 本発明における別の態様によれば、ネットワークアクセスを制御するための方法は、ネットワークを介する通信フローを許可するための要求をアプリケーションから受信する工程と、要求された通信フローのプライオリティを判別する工程と、アプリケーションのためのアクセス権を示す応答をアプリケーションに送信する工程とを含むことができる。次に、ネットワークリソースの利用可能性を判別し、ネットワークリソースをアプリケーションに割り当てることができる。さらに、リソースの利用可能性およびプライオリティに基づいて、ネットワークにおける他の通信フローに割り当てられたネットワークリソースが変更されてもよい。
【図面の簡単な説明】
【００１８】
【図１】［0018］本発明の一態様によるアドミッション制御システムを示す図である。
【図２】［0019］本発明の一態様によるアドミッション制御ユニットを示す図である。
【図３】[0020]本発明の一態様によるアドミッション制御方法を示す図である。
【図４】［0021］本発明の一態様によるエンドユーザーデバイスを示す図である。
【図５】［0022］本発明の別の態様によるエンドユーザーデバイスを示す図である。
【図６】［0023］本発明の一態様によるパケット構造を示す図である。
【図７】［0024］本発明の別の態様によるアドミッション制御システムを示す図である。
【発明を実施するための形態】
【００１９】
［0025］ 図１は、ネットワークを介した通信を管理するためのシステム１００を示す。ネットワーク１５０を通じてフローターゲット（flow target）１８０にパケットを送ることを望むフローイニシエータ（flow initiator）１１０は、最初に非同期帯域幅ブローカ１３０に要求を送信することができる。この要求は、インスタントメッセージ（IM）、ボイスオーバーインターネットプロトコル（VoIP）などのアプリケーション用に、一定の時間、一定量の帯域幅を使用するための許可を求めることができる。次に、帯域幅ブローカ１３０は、その要求が許可されたか、または拒否されたかを示す応答をフローイニシエータ１１０に送信することができる。しかし、フローイニシエータ１１０は、フローターゲット１８０にパケットの送信を開始する前に、帯域幅ブローカ１３０からの応答を待つ必要はない。すなわち、フローイニシエータ１１０は、帯域幅ブローカ１３０がアクセスを許可する前にネットワークに入ることを許可され得る（may be admitted to the network）。例えば、フローイニシエータ１１０は、帯域幅ブローカ１３０からの応答を受信する前に、フローイニシエータ１１０がネットワーク１５０を介した送信を開始することができることを取り決めているローカルポリシーエンジン（local policy engine）を含むことができる。帯域幅ブローカ１３０からの応答がフローイニシエータ１１０からの要求を許可する場合、フローイニシエータ１１０は、要求された時間の間、ネットワーク１５０へのアクセスを継続し、指定されたリソースを使うことができる。しかし、帯域幅ブローカ１３０からの応答が要求を拒否する場合には、フローイニシエータ１１０は、通常、そのフローに対するパケットの送信を中止するよう命令されることになる。
【００２０】
［0026］ 本発明の態様によれば、非同期帯域幅ブローカ１３０（asynchronous Bandwidth Broker）すなわちａＢＢ１３０、ならびに、フローの開始を望む任意のポイントまたはノードは、例えば、コードもしくはソフトウェアであるポリシーエンジンまたは付随命令として、ポリシーを実装していることが好ましい。ソースは、一般に、ａＢＢからの応答を受信する前に、どのようにフローを開始し、またどのようにそのフローをマーキングするかについて決定することになるため、通常は、その期間をカバーするためにソース自体のポリシーエンジンを有する必要がある。次いで、ａＢＢのポリシーエンジンは、通常、ソースのローカルポリシーエンジンに事実上優先することになる応答の中の情報の一部を埋めるために用いることができる。
【００２１】
［0027］ 本発明におけるこの態様を実施するシステムの特徴の１つは、ａＢＢからの応答がリソースに対する要求を拒否する場合、その応答は、通常、送信を止めるための命令であるプリエンプション（pre-emption）としてソースに解釈されることになる点である。軍事システムでは、同期帯域幅ブローカすなわちＢＢを有するシステムが存在する。このようなシステムでは、ソースは、ＢＢからの応答を得るまで送信しない。より高いプライオリティのフローが許可されることになる場合、ソースは、プリエンプションのメッセージを後で受信することがあり、その場合には送信を中止する必要がある。商用システムでは、ソースは、ＢＢからの応答が受信されるまで待っている。要求されたリソースをその応答が拒否する場合、フローは許可されずに消滅する。応答が非ゼロである場合、フローは、より高いプライオリティのフローが後に来る場合でも、それらのリソースを保証される。
【００２２】
［0028］ 本発明のさらなる態様によれば、それぞれのポリシーエンジンは、完全なポリシーを有していてもよく、または、そのポリシーエンジンのノード、アプリケーション、もしくは機能に特有である、ポリシーの適合した部分を有していてもよい点に留意されたい。このように、ａＢＢは、通常、ネットワークに生じ得る任意のフローについてプライオリティ、許可するかどうか、およびどのようにマーキングするかの判別を可能にするのに十分なポリシーを有する必要がある。一般には、ａＢＢは、ａＢＢが応答する前にどのようにフローのプライオリティをつけ、フローを許可し、またそのフローをマーキングするかについてポリシーを必要としていない。ソースノードは、通常、ソースノードが生み出し得る任意のフローについてプライオリティをつけ、フローを許可し、またそのフローをマーキングすることを可能とするのに十分なポリシーをそれぞれ必要とする。いくつかの例では、ユーザー、クライアント、またはノードに情報を提供するために、ａＢＢにおける決定の後にそれらのフローをどのように処理するかについてポリシーを有することも有用であり得るが、それは必要ではない。さらには、専用デバイス（例えば、ＶｏＩＰ電話）は、ボイス関連の接続のために、ａＢＢによる決定前のポリシーを単に有することができるが、これは、それらが開始することができる唯一のフローであり得るためである。
【００２３】
［0029］ ネットワーク１５０は、インターネットなどの任意のパブリックネットワークでもよく、または、任意のプライベートネットワークでもよい。例えば、ネットワーク１５０は、インターネット、ローカルエリアネットワーク、または、ワイドエリアネットワークを介して動作する仮想プライベートネットワークでもよい。さらに、ネットワーク１５０は、任意数のサブネットワークを含むことができ、複数の異なるプロトコルまたは規格のうちの任意のものに従って動作してもよい。
【００２４】
［0030］ 図１にはフローイニシエータ１１０およびフローターゲット１８０だけが示されているが、接続されている多数のコンピュータが所与の時間にネットワーク１５０を介して通信していてもよい点を理解されたい。フローイニシエータ１１０およびフローターゲット１８０は、中央処理装置（CPU）、ディスプレイ、ＣＤ−ＲＯＭ、ハードドライブ、マウス、キーボード、モデムなどの、パーソナルコンピュータに通常見られる全ての内部コンポーネントを有する汎用コンピュータでもよい。例えば、フローイニシエータ１１０およびフローターゲット１８０は、モデムを介するか、または、ネットワークカードなどのいくつかの他の通信コンポーネントを介して、ネットワーク１５０を介して通信することができる。フローイニシエータ１１０およびフローターゲット１８０は、人および他のコンピュータからの命令を処理し、また、人および他のコンピュータへデータを送信することが可能な任意のデバイスを備えることができ、このフローイニシエータ１１０およびフローターゲット１８０には、ローカルストレージ機能のないネットワークコンピュータ、モデム付きのＰＤＡ、および、インターネット対応の無線電話が含まれる。また、フローイニシエータ１１０およびフローターゲット１８０は、このようなデバイス上で動作するアプリケーションを含むことができる。例えば、フローイニシエータ１１０上でフローを開始するアプリケーションは、ＶｏＩＰ、ＩＭ、ウェブブラウザ、オンラインゲーム、電子メール、音楽ストリーミングソフトウェアなどでもよい。
【００２５】
［0031］ 同様に、非同期帯域幅ブローカ１３０は、他のコンピュータからの命令を処理し、他のコンピュータにデータを送信することが可能な任意のデバイスでもよい。例えば、帯域幅ブローカ１３０は、汎用コンピュータでもよく、または、ウェブサーバもしくはグループウェアサーバなどの任意の種類の従来型サーバでもよい。
【００２６】
［0032］ 次に図２に移ると、帯域幅ブローカ２３０の詳細図が提供されている。この例では、ネットワークコンピュータ２６２〜２６６（例えば、フローイニシエータ）は、ルータ２６０を介して互いに接続されている。また、ネットワークコンピュータ２６２〜２６６およびルータ２６０には、帯域幅ブローカ２３０が接続されている。帯域幅ブローカ２３０は、ルータ２６０から分離したコンポーネントとして示されているが、ルータ２６０の内部のユニットでもよい点を理解されたい。例えば、帯域幅ブローカ２３０は、ルータ２６０上で動作することができる仮想コンポーネントでもよい。したがって、帯域幅ブローカ２３０およびルータ２６０は、メモリおよび／またはプロセッサなどのコンポーネントを共有することができる。その点に関しては、例えば、クライアントデバイスすなわちフローイニシエータ２６２、２６４、２６６などの全てのホストが同じルータによって処理されることになるわけではない点を理解されたい。
【００２７】
［0033］ 図２の例によれば、帯域幅ブローカ２３０は、様々なフローイニシエータデバイス（flow initiator device）に対する帯域幅の割り当てを管理する際に用いるための複数のコンポーネントを含むことができる。例えば、帯域幅ブローカ２３０は、入力／出力（I/O）ポート２３２、メモリ２３４、アクセスポリシー生成ユニット２４２、および、プロセッサ２４０を含むことができる。プロセッサ２４０は、アクセスポリシー判別ユニット２４３、アクセスポリシー実施ユニット２４４、および、リソース判別ユニット２３６をさらに含むことができる。これらのユニットは、帯域幅ブローカ２３０上で実行可能なソフトウェアモジュールでもよく、または、帯域幅ブローカ２３０における他のコンポーネントとのインタフェースがとられたハードウェアコンポーネントでもよい。さらに、図２ではこれらのユニットが独立したエンティティとして示されているが、いくつかのユニットは、実際には別のコンポーネントの一部でもよい点を理解されたい。例えば、アクセスポリシー生成ユニット２４２は、実際にはメモリ２３４の中に記憶された一組の命令でもよい。
【００２８】
［0034］ プロセッサ２４０は、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ製またはＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ製などの、任意数である周知のハードウェアベースのプロセッサを含むことができる。あるいは、このプロセッサは、ＡＳＩＣなどの、演算を実行するための専用コントローラでもよい。
【００２９】
［0035］ Ｉ／Ｏポート２３２は、ルータ２６０を通じて複数のネットワークコンピュータ２６２〜２６６に接続するために用いることができる。メモリ２３４は、プロセッサ２４０による実行のための命令と、プロセッサ２４０によって検索され、操作され、または記憶されるデータとを含む、プロセッサ２４０によってアクセス可能な情報を記憶する。メモリ２３４は、ハードドライブ、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、書き込み可能なもの、読み出し専用のものなどの、プロセッサによってアクセス可能な情報を記憶することができる任意の種類のものでもよい点を理解されたい。
【００３０】
［0036］ アクセスポリシー生成ユニット２４２は、ネットワークにどの通信フローを許可するかを判別するための判断基準を入力するために、ユーザーに対するインタフェースを提供する。この点に関しては、アクセスポリシー生成ユニット２４２は、メモリ２３４およびＩ／Ｏポート２３２と共に動作して、ユーザーがアクセスポリシーを設定および変更することを可能にしてもよい点を理解されたい。例えば、アクセスポリシー生成ユニット２４２は、通信フローを許可するかどうかの判別がなされるまでネットワークへの一時的アクセスが許可されることを示す一組の命令を受信し、これらの命令を記憶するためにメモリ２３４とのインタフェースをとることができる。また、これらの命令は、このような一時的アクセスに対して利用可能となるネットワーク帯域幅の一部を指定することもできる。さらに、これらの命令は、通信フローにおけるどのアプリケーションと、どのプライオリティレベルとが、帯域幅の利用可能性に応じて許可されることになるかを示すことができる。したがって、アクセスポリシー生成ユニット２４２は、例えば、許可を決定するための数値テーブルおよび／またはアルゴリズムのエントリー及び記憶を行うことができる。さらに、アクセスポリシーは、ネットワークの動作を動的に変えることができる。例えば、ネットワークへのアクセスを許可するためにパケットのマーキングを判定するルール、または、無効にすることを決めるルールは、変更することができる。代替的または付加的に、ネットワークにおける一時的通信のために指定される帯域幅の量は、変更することができる。
【００３１】
［0037］ プロセッサ２４０は、アクセスポリシー生成ユニット２４２を通じて入力された命令を実行することができ、このようなポリシーの実施をもたらし得る。プロセッサ２４０は、例えば、アクセスポリシー判別ユニット２４３、アクセスポリシー実施ユニット２４４、および、リソース判別ユニット２４６を含むことができる。リソース判別ユニット２４６は、ネットワークでどれくらいの帯域幅が所与の時間に利用可能であるかを評価することができる。また、リソース判別ユニット２４６は、要求を出しているアプリケーションによってどれくらいの帯域幅が必要になるかを判別することもできる。プロセッサ２４０は、アクセスポリシー生成ユニット２４２からの命令と共にこの情報を用いて、通信フローがネットワークに入ることを許可するかどうかを判別することができる。すなわち、アクセスポリシー生成ユニット２４２を通じて入力されたポリシーまたは命令は、アクセスポリシー判別ユニット２４３に提供される。フローイニシエータからの要求が受信される場合のように、対象となるイベントが起こると、アクセスポリシー判別ユニット２４３は、ポリシーに基づいて決定を行なう。次にアクセスポリシー判別ユニット２４３は、その決定をアクセスポリシー実施ユニット２４４に伝える。アクセスポリシー実施ユニット２４４は、フローイニシエータに応答を伝える、プロセッサ２４４の中のエンティティでもよい。あるいは、ポリシー実施ユニット２４４は、アクセスポリシー判別ユニット２４３からの応答を受信し、その応答に従って自ら処理するフローイニシエータ自体でもよい。さらに、ポリシー実施ユニット２４４は、ポリシー判別ユニット２４３からの命令に従ってフローイニシエータからのパケットを処理するルータ２６０でもよい。通信が許可されることをプロセッサ２４０が判別する場合、アクセスポリシー実施ユニット２４４は、その通信を許可し、要求を出しているデバイスに応答を送信することができる。しかし、フローを許可することがネットワークに過負荷をかけることになるとプロセッサ２４０が判別する場合には、アクセスポリシー実施ユニット２４４は、所定時間の間、要求を出しているデバイスのさらなる通信を拒否することができる。さらに、アクセスポリシー実施ユニット２４４は、利用可能な帯域幅を増やすために、ネットワークに入ることを既に許可されている通信フローを制御するように用いられてもよい。
【００３２】
［0038］ 図２では同じブロックの中にメモリ２３４とプロセッサ２４０が機能的に示されているが、プロセッサおよびメモリは、実際には同一の物理的ハウジングの中に格納されていても格納されていなくてもよい複数のプロセッサと、複数のメモリとを含むことができる点が、当業者によって理解されるであろう。例えば、命令およびデータの一部または全ては、取り外し可能なＣＤ−ＲＯＭに記憶されてもよく、他のものは、読み出し専用のコンピュータチップの中に記憶されてもよい。命令およびデータの一部または全ては、プロセッサから物理的に離れている場所であって、その上さらに、そのプロセッサによってアクセス可能な場所に記憶されていてもよい。同様に、プロセッサは、実際には並列に動作してもしなくてもよいプロセッサの集まりを含むことができる。
【００３３】
［0039］ 図１〜図２に示されている動作に加えて、本方法の様々な態様による動作を次に説明する。下記の動作は、以下で説明される正確な順序で行なわれる必要はない点を理解されたい。むしろ、様々な工程は、逆の順序で、または同時に処理されてもよい。
【００３４】
［0040］ 図３には、帯域幅の割り当てを管理する方法３００が示されている。この方法３００によれば、帯域幅に対する要求が受信され、その要求は、ネットワークにおいて利用可能な帯域幅の判別と、その要求のプライオリティとに基づいて処理される。
【００３５】
［0041］ 工程３１０では、（例えば、フローイニシエータ１１０からの）帯域幅に対する要求が、帯域幅ブローカ１３０によって受信される。この要求は、どのアプリケーション（例えば、ＩＭ、ＶｏＩＰ、ウェブブラウザなど）がネットワーク１５０にアクセスすることを望んでいるか、要求されているアクセスの継続時間、そのようなアクセスに要求される帯域幅の量などの、様々な情報を含むことができる。さらに、この要求は、ネットワークアクセスにおけるプライオリティの識別を含むことができる。例えば、この要求は、要求されているアクセスを、単にいくつかの例として、緊急、早急、ｘ分待機可、または低プライオリティとして識別することができる。アクセスのプライオリティを指定するために、カラー、コードなどの任意の種類の目印（indicia）を用いることができる点を理解されたい。
【００３６】
［0042］ フローイニシエータ１１０は、帯域幅ブローカ１３０からの応答を待つことなく、要求された通信を開始することができる（すなわち、ネットワーク１５０を介してパケットの送信を開始することができる）。
【００３７】
［0043］ 工程３２０では、帯域幅ブローカ１３０は、要求を満たすのに十分な帯域幅がネットワーク１５０上で利用可能であるかどうかを判別する。例えば、リソース判別ユニット２４６は、ネットワークを通じた既存の通信によってどれくらいの帯域幅が既にとられているかを推定し、要求を出しているデバイスによる追加の帯域幅の使用がネットワーク１５０にどれだけ影響を与えることになるかを評価することができる。
【００３８】
［0044］ 十分な帯域幅がネットワーク１５０において利用可能であり、それによって、ネットワークを通じた他の通信は、フローイニシエータ１１０による帯域幅の追加の使用によって影響を受けないことが、帯域幅ブローカ１３０によって判別される場合がある。したがって、このような通信は、工程３２５で承認され得る。あるいは、フローイニシエータ１３０がネットワーク１５０にアクセスすることを許可することが、ネットワークにおけるいくらかの輻輳をまねくことになると判別される場合がある。ネットワーク１５０におけるいくらかの輻輳は許容できる場合がある一方で、ネットワーク１５０にある程度まで過負荷をかけることは許容できない場合がある。したがって、ネットワーク１５０に著しく負担をかけることのない通信も、工程３２５で承認され得る。承認は、例えばフローイニシエータ１１０に応答を送信することによって、フローイニシエータ１１０に示されてもよい。フローイニシエータ１１０は、ネットワーク１５０を介して既に通信を開始している可能性があるため、そのフローイニシエータ１１０は、単にそれを継続して行なうことができる。また、非同期帯域幅ブローカ１３０からの応答は、多かれ少なかれいくらかのリソースをフローイニシエータ１１０に使用させるようにして、利用可能なリソースを指定することもできる。例えば、フローイニシエータのローカルポリシーエンジンによって用いられる暫定的ポリシーは、ＶｏＩＰフローが、プライオリティレベル３としてマーキングされたパケットによって開始可能であることを指定する場合がある。非同期帯域幅ブローカ１３０のポリシーと、ネットワーク状態の判別とに基づく、非同期帯域幅ブローカ１３０からの応答は、代わりにプライオリティ５でパケットがマーキングされることを指定する場合がある（この場合、５は、より高いプライオリティでもよく、または、より低いプライオリティでもよい）。
【００３９】
［0045］ 工程３２０において、フローイニシエータ１１０からネットワーク１５０へのフローを許可することがネットワーク１５０に過度の負担をかけることになると判別された場合、要求されている通信のプライオリティを工程３３０で評価することができる。このような評価は、帯域幅ブローカ１３０、ルータ、または、このようなコンポーネントの組み合わせによって行なわれてもよい。一態様によれば、この評価によって、要求されている通信のプライオリティと、ネットワーク１５０にアクセスしている通信のプライオリティとが比較され得る。別の態様によれば、この評価によって、所定レベル以上の任意レベルのプライオリティがネットワーク１５０に対して許可されることが、判別され得る。プライオリティは、通信の重要度に基づくものでもよく、いくつかの実施形態では、特定のアプリケーション用に要求された帯域幅に基づくものでもよい。例えば、要求されているＶｏＩＰ通信とインスタントメッセージとは、ほぼ同じ重要度を有し得るが、インスタントメッセージは、より少ない帯域幅を使用することから、ＶｏＩＰ通信を上まわるプライオリティをとることができる。この評価によって、その通信が優先するという決定がもたらされる場合、その通信は承認され得る（工程３２５）。
【００４０】
［0046］ 可能性のある選択肢の１つは、例えば別のフローに先に割り当てられたリソースを減らすことによって、工程３３５で所定の量の帯域幅を開放することであり得る。プライオリティのつけられた通信が可能である場合、この所定の量は、ネットワーク１５０からの輻輳を緩和するのに十分なものでもよい。例えば、開放される帯域幅の量は、フローイニシエータ１１０によって要求された帯域幅の量とほぼ同じでもよい。あるいは、帯域幅の量は一定の値でもよい。
【００４１】
［0047］ 非同期帯域幅ブローカは、複数の方法のうちの任意の方法で帯域幅を開放することができる。例えば、ネットワーク１５０を介する全てのフローにおける帯域幅の許容量を下げることができる。代替的または付加的に、任意のアプリケーション自身に割り当てられた帯域幅をその任意のアプリケーションがもはや利用していないかどうかを判別して、そのような帯域幅を再度割り当てることができる。さらに別の可能性は、例えば最も低いプライオリティである、所定のプライオリティの通信が一時停止または終了され得ることである。
【００４２】
［0048］ 工程３３０におけるプライオリティの評価が、要求されている通信が優先しないという決定をもたらす場合、フローイニシエータ１１０によって送信された帯域幅に対する要求は、工程３４０において拒否され得る。これには、要求が拒否されたことを示す、フローイニシエータ１１０へのメッセージの送信が含まれる。一態様によれば、これは、フローイニシエータ１１０によって既に開始されている、ネットワーク１５０を介したパケットの送信の終了も含み得る。さらに、非同期帯域幅ブローカは、先だって送られたパケットを削除するよう、ネットワークのルータに命令することができる。
【００４３】
［0049］ ネットワークの帯域幅に対するアクセスを提供する場合において本発明が説明されたが、これらの説明は例示的に過ぎない。概して、本発明は、任意のネットワークリソースにおける仲介（brokering）が存在する場合に適用することができる。これらのネットワークリソースには、例えば、待ち時間、ジッタ、または、ネットワーク構成要素の処理時間が含まれ得る。
【００４４】
［0050］ 本発明の一態様によれば、ネットワーク１５０を介する通信のプライオリティは、パケットにおけるマーキングによって指定することができる。このマーキングは、任意の種類の所定コードを含むことができる。プライオリティレベルの設定は、コンテンツ、アプリケーション、ユーザー定義の要件、重み、または、これらもしくは他のパラメータの任意の組み合わせに基づいていてもよい。
【００４５】
［0051］ 図４に示されているように、マーキングは、フローイニシエータ４１０などのコンピューティングデバイス上で動作しているアプリケーション（例えば、要素４１２、４１４、４１６によって示されているアプリケーション１〜３）によって行うことができる。フローイニシエータ４１０は、アプリケーション４１２〜４１６と通信して、それらのアプリケーション４１２〜４１６を制御するオペレーティングシステムのカーネル４２０を含むことができる。それぞれのアプリケーション４１２、４１４、４１６は、パケットマーキングユニット４１３、４１５、４１７などの、パケットマーキングを行なうユニットを含むことができる。例えば、アプリケーション４１２がインスタントメッセージのアプリケーションである場合、そのアプリケーションは、パケットを「５」または「低遅延」として常に指定することができる。あるいは、アプリケーション４１２は、用いるマーキングに関して、ユーザーからの入力を受信することができる。そのため、同じ例に従うと、インスタントメッセージのアプリケーションを用いて送られるパケットは、「１」または「重要」に変更されてもよい。
【００４６】
［0052］ 図５には代替実施形態が示されている。例えば、アプリケーション５１２、５１４、５１６は、パケットマーキングを行なうよう当てにされていなくてもよい。そのため、パケットマーキングは、フローイニシエータ５１０のオペレーティングシステム５２０によって行なうことができる。すなわち、アプリケーション５１２〜５１６は、パケットをオペレーティングシステム５２０に送信することができる。オペレーティングシステム５２０は、アプリケーション５１２〜５１６によって送られたパケットにマーキングを割り当てるパケットマーキングモジュール５２５を含むことができる。図４の例と同様に、このマーキングは、アプリケーション、コンテンツ、または、ユーザー定義の設定に基づくものでもよい。
【００４７】
［0053］ 図６は、ネットワーク１５０を通じて送信される、マーキングされたパケットの構造を示す。この例では、ネットワーク１５０は、ＩＰｖ４ネットワークである。しかし、本発明の原理は、プライオリティをパケットのヘッダーで示す手段を提供する任意のネットワークで実装することができる点を理解されたい。さらに、プライオリティを有さないネットワークでは、本発明は、ネットワークにおけるより大雑把な制御を非同期帯域幅ブローカが有するという制約によって依然として作用することになる。加えて、フローイニシエータのポリシーは、輻輳の面でネットワークがよりいっそう優雅さを欠いて退化することになるため、より従来型に近いものになる。パケットは、インターネットプロトコル（IP）のバージョンと、ＩＰヘッダー長とに関する情報を含むヘッダー６１０を含む。ＩＰバージョンは、インターネットヘッダーのフォーマットを示す。ＩＰヘッダー長は、３２ビットワードにおけるインターネットヘッダーの長さであり、すなわち、データの始まりまでのポイント（point）である。
【００４８】
［0054］ サービスフィールドのタイプ６２０は、所望のサービス品質におけるアブストラクトパラメータ（abstract parameter）の表示を行なう。これらのパラメータは、ネットワーク１５０を通じてパケットを送信する際に、実際のサービスパラメータの選択をガイドする。したがって、サービスフィールドのタイプ６２０は、パケットをどのように扱うかをルータなどが判別できる値を記憶することによって、プライオリティを示すことができる。
【００４９】
［0055］ 合計長フィールド６３０は、インターネットヘッダーとデータを含む、オクテットで測られたパケットの長さである。このフィールドは１６ビットでもよい。
【００５０】
［0056］ 識別フィールド６４０は、パケットの断片を組み立てるときに支援するための識別値を含むことができる。この値は、送信するデバイスによって割り当てられてもよく、また１６ビットの長さでもよい。
【００５１】
［0057］ フラグおよび断片オフセットフィールド６５０は、断片化が可能となっているかどうか、その断片が最後の断片か、または断片がまだあるか、などの様々な制御フラグを含むことができる。また、フラグおよび断片オフセットフィールド６５０は、パケットの中でこの断片が属する場所を示すこともできる。
【００５２】
［0058］ ソースアドレスフィールド６６０および宛先アドレスフィールド６７０は、パケットのソースと宛先をそれぞれ特定することができる。
【００５３】
［0059］ オプションフィールド６８０は、送信されても送信されなくてもよい情報を含む。このような情報の例には、セキュリティ、ルーズソースルーティング、ストリクトソースルーティング、インターネットタイムスタンプなどが含まれる。ペイロードフィールド６９０は、送信される実際のデータを含むことができる。上記の通り、このデータは、パケットに対する適切なマーキングを判別する際に考慮され得る。図７は、本発明の態様に従って帯域幅を管理する例を示す。特に、この例は、図４および図５に関して用いられた技術とは対照的である、パケットマーキングの別の方法を提供する。特に、パケットマーキングを行なうことにフローイニシエータが当てにされていない場合、この手法を用いることができる。
【００５４】
［0060］ この例では、複数のフローイニシエータ７１０〜７１５が、ネットワーク７５０上で動作している。ネットワーク７５０は、通信と、比較的高スピードである複数のアプリケーションの間におけるリソース共有とを可能にする企業ネットワークでもよい。リソースは、非同期帯域幅ブローカによって、ネットワーク７５０を介するそれぞれのフローに割り当てることができる。フローイニシエータ７１０〜７１５は、ネットワーク７５０上のデバイスだけでなく、ネットワーク７５０を越えた他のデバイスとも通信することができる。例えば、ネットワーク７５０は、ルータ７６０を通じて他のネットワークに接続されていてもよい。他のネットワークは、別の企業ネットワーク、または、より低速なネットワークなどの、任意の種類のネットワークでもよい。この例では、エッジルータ７６０は、シェーピング（shaping）とポリシング（policing）（すなわち、非同期帯域幅ブローカによって許可されたリソース範囲を超えるパケットを遅らせること、または削除すること）を行なうことができる。
【００５５】
［0061］ フローイニシエータ７１２は、インスタントメッセージを介してフローイニシエータ７１４および７１５と通信していてもよい。非同期帯域幅ブローカは、このような通信にネットワーク７５０における２０％の帯域幅を割り当てることができ、送信されるパケットは、非同期帯域幅ブローカによって「５」のマーキングを割り当てられてもよい。同時に、フローイニシエータ７１３は、エッジルータ７６０を介して、このネットワークを越えたデバイスとＶｏＩＰセッションを行なっていてもよい。このＶｏＩＰセッションは、ネットワーク帯域幅の６５％を割り当てられていてもよく、送信されるパケットは、非同期帯域幅ブローカによって「３」のマーキングを割り当てられていてもよい。さらに同時に、フローイニシエータ７１１は、インターネットダウンロードを開始するための要求を出すことができる。したがって、フローイニシエータ７１１は、帯域幅に対する要求を非同期帯域幅ブローカに送信することができる。非同期帯域幅ブローカは、ルータ７６０などの図示されている任意のデバイス、または、ネットワーク７５０における他の場所、または、ルータ７６０を越えた比較的大きいネットワークにおけるどこかの場所に、一緒に配置されていても一緒に配置されていなくてもよい。あるいは、非同期帯域幅ブローカは、独立して存在していてもよい。要求は、アプリケーション（すなわち、ウェブダウンロード）、プライオリティ（例えば、低遅延）、ダウンロードの推定時間（例えば、１５分）、および、要求されるおおよその帯域幅（例えば、１０Ｍｂｐｓ）を指定することができる。フローイニシエータ７１１は、帯域幅ブローカからの応答を待つ前に、ダウンロードを開始することができる。その間に、帯域幅ブローカは、要求された１０Ｍｂｐｓがネットワークの帯域幅能力の１５％であり、ネットワーク７５０を介して通信している他のデバイスのために１５％だけが利用可能であることを判別することができる。帯域幅ブローカは、それ以外の場合にはネットワークにおける過剰な輻輳のリスクを避けるためにこのような通信を拒否することができる一方で、その要求がアプリケーション用の高いプライオリティを指定していることを認識することができる。したがって、帯域幅ブローカは、帯域幅に対するその要求を許可することができる。ルータ７６０は、パケットに「２」のマーキングを割り当てることができる。帯域幅ブローカは、ネットワークにおける帯域幅の利用可能性を増すために、５でマーキングされたパケットのアクセスの許可を中止することができる。
【００５６】
［0062］ フローイニシエータは、アドミッション制御要求の送信と、帯域幅ブローカからのアドミッション制御応答の受信との間の一時的期間にネットワークへのアクセスの開始を許可されているため、そのネットワークは、その期間に必要以上の申し込みを受ける可能性がある。許可されている通信フローに対するネットワークにおける影響は、１つまたは複数の技術によって、この一時的期間の間に最小にすることができる。これらの技術は、例えばアクセスポリシー判別ユニット２４３で実装することができる。
【００５７】
［0063］ 許可されたフローに対する影響を最小にする第１の方法によれば、ネットワーク帯域幅の構成可能比率（α）を、一時的期間におけるフロー用にとっておくことができる。一時的期間におけるそれぞれのトラフィックフローは、このあらかじめ割り当てられた帯域幅のうちの構成可能比率（β）を利用するように許可され得る。したがって、一時的期間における任意の単一フローに対する利用可能な帯域幅は、ネットワーク帯域幅の（β×α）を超えないことになる。区分されたクラスのサービスを有するネットワークの場合には、ネットワーク帯域幅におけるこのような構成可能比率は、ベストエフォート（または、アドミッション制御が想定されていないクラス）を除いて、それぞれのクラスのサービス用にとっておくことができる。
【００５８】
［0064］ ネットワークが非常にリソース制限されている場合には、ポリシーは、一時的フローに対してリソースが事前提供されないものとなり得る。このような場合、帯域幅ブローカが許可の決定を行なう前にネットワークにアクセスするためには、ポリシーは、高プライオリティのフローだけが許可されるか、または、どのようなフローも許可されないものとなり得る。付加的または代替的に、ネットワークに入ることを既に許可されている低プライオリティのフローは、一時停止または終了されてもよい。一時的期間においてネットワークの１００％がフローに対して利用可能である極端な別の例では、許可前のフローは、許可後のフローと同じアクセスを有する。
【００５９】
［0065］ 一時的期間においてフローの影響を最小にするための別の方法は、ベストエフォートを利用することである。すなわち、一時的期間におけるフローは、「ベストエフォート」のパケットマーキングを用いてそれらのフローのデータを送り、アプリケーションは、必要なときにいつでも、任意の品質で、許可を要求せずに、または、最初にネットワークに知らせることなく、データを送る。ベストエフォートのサービスの場合、ネットワークは、信頼性、遅延範囲、またはスループットにおけるいかなる保証もない状態で、可能な場合にデータを送出する。このような分類は、例えばサービスフィールドのタイプ６２０において、パケットマーキングに含まれてもよい。ネットワークが必要以下の申し込みを受けている場合にこのマーキングを用いることは、一時的フローによって受けるサービス品質に影響を与えない。しかし、ネットワークが必要以上の申し込みを受けている場合、ベストエフォートのマーキングを用いることは、十分でないレベルのサービスを一時的フローが受ける原因となる場合があり、いくつかの例では、一時的フローは、ネットワークを通じてパケットを全く送ることができない場合がある。したがって、この一時的フローは、許可されたフローに影響を与えないことになる。
【００６０】
［0066］ 許可されたフローに対する影響を最小にするさらに別の方法は、帯域幅をとっておく方法の要素と、ベストエフォートを利用する方法の要素とを組み合わせることができる。この方法によれば、一時的期間のためにあらかじめ割り当てられる帯域幅は、火災警報などの特定の高プライオリティのトラフィックに用いることができる。残りの一時的フローは、アドミッション制御の決定を待ちながらベストエフォートを利用することができる。用いられる手法の決定は、動的ポリシー更新機構を用いて動的に構成することができる。例えば、この機構は、アクセスポリシー生成ユニット２４２の中に実装することができる。この手法を用いて、フローが開始される時間ごとに、（アプリケーションによって要求される帯域幅、ネットワークの現行状態、１日のうちの時間帯、アプリケーションを動作させているユーザーの役割、アプリケーションの地理的／トポロジー的位置などを含む複数の要因に依存し得る）現在のポリシーがチェックされる。非同期帯域幅ブローカは、大概は、ポリシー判別ユニット２４３を用いて適正なマーキングを判別し、そのマーキングを応答の一部としてフローイニシエータに送ることになる。しかし、非同期帯域幅ブローカは、ポリシー判別ユニット２４３とやり取りして、フローイニシエータが分類ｘに割り当てられていることをそのフローイニシエータに通知することができる。次に、フローイニシエータにおけるポリシー判別ユニット２４３は、その分類ｘを、アプリケーションのタイプ、ノードの位置などの他の要因と共に用いて、パケットごとにマーキングを判別する。そのようにして、ノードが移動している場合には、パケットのマーキングは、非同期帯域幅ブローカと再度やり取りすることを必要とせずに時間にわたって変化する場合がある。
【００６１】
［0067］ 本発明の一態様によれば、ネットワークが現在直面している状況より厳しい状況においていくつかのアプリケーションが有することになる帯域幅の割り当てを、それらのアプリケーションに与えるようにアクセスポリシーを構成することができる。例えば、一時的期間の間、非緊急のアプリケーションは、ネットワークが災害モードにある場合に与えられることになるリソースを与えられてもよい。帯域幅ブローカは、許可のための要求に対して応答する場合は、現在のネットワーク動作に対応しているリソースをアプリケーションに与えることになる。同様に、一時的期間の間にそれぞれのフローイニシエータに割り当てられる帯域幅は、アプリケーションに対する影響に基づくものでもよい。例えば、ＶｏＩＰのアプリケーションは、最初は主に、低い帯域幅の、待ち時間の影響を受けにくい（latency insensitive traffice）トラフィックを送る。通話設定が完了する前に、許可要求に対する応答がＶｏＩＰのアプリケーションによって受信されることが予想される場合、最初の帯域幅の割り当ては、通話設定の要件に基づいて設定されている可能性がある。したがって、応答が受信される前にビデオが始まる場合、帯域幅の高いビデオがネットワークを圧倒しないことが確実なものとなる。
【００６２】
［0068］ また、ネットワークの構成は、一時的動作を制御するために利用することもできる。例えば、区分されたサービスを有するネットワークでは、大概は一時的トラフィックを制限するためのパケットマーキングに対する帯域幅の割り当ては、ネットワークにおける現在の動作に応じて下げられてもよく、または、上げられてもよい。さらに、パケットマーキングは、一時的トラフィックと、許可されたトラフィックとが同じパケットマーキングを用いることのないように選択されてもよい。このように、ポリシー実施ユニット２４４またはルータ２６０は、現在のネットワーク状態に基づいて構成することができる。例えば、それぞれのクラスのサービスは、１つは奇数、１つは偶数である、隣接したパケットマーキングに対して提供されてもよい。奇数値は、一時的トラフィックへの割り当て用に、アプリケーションに利用可能となる。偶数値は、ネットワークの許可によって提供されることになる。通常動作では、それぞれのパケットマーキングのペアは、全く同様に扱われることになる。しかし、危機的状況においては、非緊急の一時的パケットマーキング、ならびに、帯域幅の高いアプリケーションに利用可能な一時的パケットマーキングは、削減される場合があり、一方、緊急の一時的パケットマーキングは、緊急のトラフィックとして継続して処理されることになる。対照的に、ネットワークが攻撃を受けている場合、緊急の一時的パケットマーキングは、（アタッカーに対する誘惑の対象と同様に）削減される可能性がある。
【００６３】
［0069］ 本発明の別の態様によれば、要求を出している通信フローに対するアクセスを許可する応答が与えられた後に、ネットワークのプロビジョニングが行なわれてもよい。これは、ネットワークのプロビジョニングが高価である場合には特に有益であり得る。例えば、いくつかのネットワークでは、往復時間（すなわち、アプリケーションからの要求を帯域幅ブローカに送信するための時間と、その要求に対する帯域幅ブローカからの応答を送信するための時間）は、比較的短い可能性がある。したがって、フローイニシエータは、ネットワークを介してパケットを送る前に、通信フローが許可されることを示す帯域幅ブローカからの応答を待つように求められる場合がある。それでもなお、ネットワークへのアクセスは比較的迅速に得られることになる。通信フローを許可するか、または拒否するかの決定は、フローのプライオリティ、フローに必要なおおよその帯域幅などの複数の要因のうちの任意の要因に基づいたものでもよい。次に、帯域幅ブローカは、ネットワークのプロビジョニングを行なうことができる。
【００６４】
［0070］ ネットワークをプロビジョニングする場合、帯域幅ブローカは、ネットワークにおけるリソースの利用可能性を評価することができ、また、そのようなリソースを使う通信フローのプライオリティを考慮することもできる。したがって、帯域幅ブローカは、ネットワークにおける通信フローに対するリソースを再度割り当てることができる。これは、パケットの送信を止めるか、もしくは、使われる帯域幅の量を減らす必要のあるデバイスまたはアプリケーションにメッセージを送信することを含み得る。例えば、初めにアクセスを要求したフローイニシエータは、要求されたフローに対する帯域幅の量を制限する、フローマネージャからの更新を受信する場合がある。さらなる例としては、ネットワークを介して既に通信しているアプリケーションは、それらのリソース使用を制限するメッセージを受信する場合がある。一部のデバイスまたはアプリケーションは、増加した量のリソースを割り当てられてもよい。付加的または代替的に、帯域幅ブローカは、再度割り当てるリソースに対して、既により厳密になされた割り当てを実施することができる。例えば、帯域幅ブローカは、特定のフローに対して帯域幅の制限を実施するようルータに命令することができる。
【００６５】
［0071］ 本発明は、緊急である短時間の通信フローが、アクセスが許可されたという応答を待つことなく、ネットワークを介して即座に通信することが可能になるという点で有利である。さらに、先に許可されたフローのサービス品質は、通常、大きくは影響されないことになる。最悪の場合、先に許可されたフローのサービス品質は、ネットワークが必要以上に申し込まれることになるため、許可の判定がなされるまで一時的に悪化することがある。
【００６６】
［0072］ さらに、本発明は、通常はネットワークが必要以下の申し込みを受けている場合に対して最適化を行なう。冗長性、将来の発展に向けた要件のために、または、単にネットワークが構築される際に適用負荷が十分にわかっていないために、多くのネットワークは、必要な容量より多くの容量を有している。この場合には、アドミッション制御の決定を待つことは、ほんのわずかな利点しか有することのないオーバーヘッドをもたらす。しかし、不具合が発生し、ネットワークが突然必要以上の申し込みを受けることになると、ネットワークのアドミッション制御（および、プリエンプション）は、多くの場合、そのネットワークが価値を提供し続けることができる唯一の方法となる。本発明は、これを低いオーバーヘッドで可能にする。
【００６７】
［0073］ さらに、本発明は、サービスの品質が維持されるタイムリーな方法によって、緊急のフローがネットワークで動作することを可能にする。例えば、火災警報が作動する場合、送られるデータの量は、ネットワークに影響を与えるのに十分に多くはないが、送られるデータは緊急である。それでもなお、帯域幅ブローカがそのフローに気づいていることが重要であり、それによって、多くの火災警報が同時に作動している場合には、その帯域幅ブローカは、ネットワークに必要以上の申し込みを行なうことになる他のトラフィックの許可を回避することができる。
【００６８】
［0074］ 本明細書において、特定の実施形態を参照して本発明が説明されたが、これらの実施形態は、本発明の原理と応用を例示しているに過ぎない点を理解されたい。したがって、例示的実施形態に対して様々な変更がなされてもよく、また、添付の特許請求の範囲によって定義されている本発明の趣旨および範囲から逸脱することなく他の構成が考案され得る点を理解されたい。
【特許請求の範囲】
【請求項１】
ネットワークを介する通信フローを許可するための要求を受信する工程と、
前記ネットワークを介する前記通信フローを一時的に許可する工程と、
ネットワークリソースの利用可能性を判別する工程と、
要求された前記通信フローに必要なリソースと、前記利用可能なリソースとを比較する工程と、
前記通信フローのプライオリティを判別する工程と、
前記利用可能なリソース、前記要求されたリソース、および前記プライオリティに基づいて、一時的に許可された前記通信フローに応答する工程と
を含む、ネットワークアクセスを制御するための方法。
【請求項２】
一時的に許可される通信フローのための前記リソースを取っておく工程をさらに含む、請求項１に記載の方法。
【請求項３】
前記リソースが、帯域幅、待ち時間、ジッタ、および処理時間からなる群から選択される、請求項１に記載の方法。
【請求項４】
前記一時的に許可された通信フローに応答する工程が、前記通信フローを許可する工程、前記通信フローを終了させる工程、または、前記通信フローに割り当てられた前記リソースを変更する工程の少なくとも１つを含む、請求項１に記載の方法。
【請求項５】
プライオリティを指定するために、前記通信フローにおいて送信されるパケットにマーキングする工程をさらに含む、請求項１に記載の方法。
【請求項６】
前記一時的に許可された通信フローのパケットマーキング、前記通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて前記一時的に許可された通信フローに応答するためのポリシーを設定する工程をさらに含む、請求項５に記載の方法。
【請求項７】
一時的に許可された通信フローに割り当てられた前記リソースが、通信の種類、または、前記通信におけるプライオリティの少なくとも一方に基づいて変化する、請求項１に記載の方法。
【請求項８】
前記ネットワークを介して許可された通信フローに割り当てられた１つまたは複数のリソースを非同期的に変更する工程、または、前記通信フローを終了させる工程をさらに含む、請求項１に記載の方法。
【請求項９】
前記ネットワークを介して許可された通信フローに割り当てられた前記リソースを変更する工程が、前記許可されたフローより高いプライオリティの通信フローのための要求の受信に応じて行われる、請求項８に記載の方法。
【請求項１０】
ネットワークを介して通信するための要求を受信するための入力部と、
前記要求を受信する時に前記ネットワークにおける１つまたは複数の利用可能なリソースを判別するためのリソース判別ユニットと、
ネットワークアドミッションポリシーに関連する情報を記憶するメモリであって、前記要求に対する応答が送信される前に、前記ネットワークアドミッションポリシーが、前記ネットワークを介する一時的通信を許可し、前記ネットワークアドミッションポリシーが、前記利用可能なリソース、通信のために要求されたリソース、およびプライオリティの少なくとも１つに基づいて、前記ネットワークを介して通信するためのどの要求が許可されることになるかを定める、メモリと、
前記ネットワークアドミッションポリシーを実施し、前記要求に対する応答を送信するためのネットワークアドミッションポリシー実施ユニットと
を備える、ネットワークアクセスを管理するためのシステム。
【請求項１１】
前記ネットワークアドミッションポリシーをユーザーが設定または変更することを可能にするポリシー生成ユニットをさらに備える、請求項１０に記載のシステム。
【請求項１２】
前記ネットワークアドミッションポリシーを更新するための更新機構をさらに備える、請求項１１に記載のシステム。
【請求項１３】
前記更新機構が、前記要求が受信される時に前記ネットワークに対して許可される通信に基づいて、前記ポリシーを更新する、請求項１２に記載のシステム。
【請求項１４】
コンピュータによって実行可能なプログラムを記憶するコンピュータ可読媒体であって、前記プログラムが、
ネットワークへの通信フローを許可するための要求を受信することと、
前記ネットワークへの前記通信フローを一時的に許可することと、
前記ネットワークにおける利用可能なリソースを判別することと、
要求された前記通信フローに必要なリソースと、前記利用可能なリソースとを比較することと、
前記通信フローのプライオリティを判別することと、
前記利用可能なリソース、前記要求されたリソース、および前記プライオリティに基づいて、一時的に許可された前記通信フローを処理することと
を含む、コンピュータ可読媒体。
【請求項１５】
クライアントデバイスによって、１つまたは複数のネットワークリソースにアクセスするための要求を送る工程と、
前記要求に対する応答が受信される前に、前記１つまたは複数のネットワークリソースにアクセスする工程と
を含む、ネットワークにアクセスするための方法。
【請求項１６】
前記要求が、前記ネットワークを介する通信フローのための要求を含み、前記１つまたは複数のネットワークリソースが帯域幅を含む、請求項１５に記載の方法。
【請求項１７】
前記要求に対する応答が、前記通信フローを許可する工程、前記通信フローを終了させる工程、または、前記通信フローに割り当てられた前記リソースを変更する工程を含む、請求項１６に記載の方法。
【請求項１８】
プライオリティを指定するために、前記通信フローにおいて送信される１つまたは複数のパケットにマーキングする工程をさらに含む、請求項１６に記載の方法。
【請求項１９】
アプリケーション層、オペレーティンスシステム、または、エッジルータにおいて前記１つまたは複数のパケットにマーキングする工程をさらに含む、請求項１６に記載の方法。
【請求項２０】
前記クライアントデバイスに対応したポリシーエンジンを用いて、リソースへのアクセスが利用可能となるかどうかを判別する工程をさらに含む、請求項１５に記載の方法。
【請求項２１】
判別する工程が、パケットにおけるマーキング、通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて、アクセスを提供するためのポリシーを設定する工程を含む、請求項２０に記載の方法。
【請求項２２】
ネットワークを介する通信フローを許可するための要求をアプリケーションから受信する工程と、
前記要求された通信フローのプライオリティを判別する工程と、
前記アプリケーションのためのアクセス権を示す応答を前記アプリケーションに送信する工程と、
ネットワークリソースの利用可能性を判別する工程と、
前記リソースの利用可能性およびプライオリティに基づいて、ネットワークリソースを前記通信フローに割り当てる工程と
を含む、ネットワークアクセスを制御するための方法。
【請求項２３】
前記リソースの利用可能性およびプライオリティに基づいて、前記ネットワークにおける他の通信フローに割り当てられたネットワークリソースを変更または強化する工程をさらに含む、請求項２２に記載の方法。
【請求項１】
ネットワークを介する通信フローを許可するための要求を受信する工程と、
前記ネットワークを介する前記通信フローを一時的に許可する工程と、
ネットワークリソースの利用可能性を判別する工程と、
要求された前記通信フローに必要なリソースと、前記利用可能なリソースとを比較する工程と、
前記通信フローのプライオリティを判別する工程と、
前記利用可能なリソース、前記要求されたリソース、および前記プライオリティに基づいて、一時的に許可された前記通信フローに応答する工程と
を含む、ネットワークアクセスを制御するための方法。
【請求項２】
一時的に許可される通信フローのための前記リソースを取っておく工程をさらに含む、請求項１に記載の方法。
【請求項３】
前記リソースが、帯域幅、待ち時間、ジッタ、および処理時間からなる群から選択される、請求項１に記載の方法。
【請求項４】
前記一時的に許可された通信フローに応答する工程が、前記通信フローを許可する工程、前記通信フローを終了させる工程、または、前記通信フローに割り当てられた前記リソースを変更する工程の少なくとも１つを含む、請求項１に記載の方法。
【請求項５】
プライオリティを指定するために、前記通信フローにおいて送信されるパケットにマーキングする工程をさらに含む、請求項１に記載の方法。
【請求項６】
前記一時的に許可された通信フローのパケットマーキング、前記通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて前記一時的に許可された通信フローに応答するためのポリシーを設定する工程をさらに含む、請求項５に記載の方法。
【請求項７】
一時的に許可された通信フローに割り当てられた前記リソースが、通信の種類、または、前記通信におけるプライオリティの少なくとも一方に基づいて変化する、請求項１に記載の方法。
【請求項８】
前記ネットワークを介して許可された通信フローに割り当てられた１つまたは複数のリソースを非同期的に変更する工程、または、前記通信フローを終了させる工程をさらに含む、請求項１に記載の方法。
【請求項９】
前記ネットワークを介して許可された通信フローに割り当てられた前記リソースを変更する工程が、前記許可されたフローより高いプライオリティの通信フローのための要求の受信に応じて行われる、請求項８に記載の方法。
【請求項１０】
ネットワークを介して通信するための要求を受信するための入力部と、
前記要求を受信する時に前記ネットワークにおける１つまたは複数の利用可能なリソースを判別するためのリソース判別ユニットと、
ネットワークアドミッションポリシーに関連する情報を記憶するメモリであって、前記要求に対する応答が送信される前に、前記ネットワークアドミッションポリシーが、前記ネットワークを介する一時的通信を許可し、前記ネットワークアドミッションポリシーが、前記利用可能なリソース、通信のために要求されたリソース、およびプライオリティの少なくとも１つに基づいて、前記ネットワークを介して通信するためのどの要求が許可されることになるかを定める、メモリと、
前記ネットワークアドミッションポリシーを実施し、前記要求に対する応答を送信するためのネットワークアドミッションポリシー実施ユニットと
を備える、ネットワークアクセスを管理するためのシステム。
【請求項１１】
前記ネットワークアドミッションポリシーをユーザーが設定または変更することを可能にするポリシー生成ユニットをさらに備える、請求項１０に記載のシステム。
【請求項１２】
前記ネットワークアドミッションポリシーを更新するための更新機構をさらに備える、請求項１１に記載のシステム。
【請求項１３】
前記更新機構が、前記要求が受信される時に前記ネットワークに対して許可される通信に基づいて、前記ポリシーを更新する、請求項１２に記載のシステム。
【請求項１４】
コンピュータによって実行可能なプログラムを記憶するコンピュータ可読媒体であって、前記プログラムが、
ネットワークへの通信フローを許可するための要求を受信することと、
前記ネットワークへの前記通信フローを一時的に許可することと、
前記ネットワークにおける利用可能なリソースを判別することと、
要求された前記通信フローに必要なリソースと、前記利用可能なリソースとを比較することと、
前記通信フローのプライオリティを判別することと、
前記利用可能なリソース、前記要求されたリソース、および前記プライオリティに基づいて、一時的に許可された前記通信フローを処理することと
を含む、コンピュータ可読媒体。
【請求項１５】
クライアントデバイスによって、１つまたは複数のネットワークリソースにアクセスするための要求を送る工程と、
前記要求に対する応答が受信される前に、前記１つまたは複数のネットワークリソースにアクセスする工程と
を含む、ネットワークにアクセスするための方法。
【請求項１６】
前記要求が、前記ネットワークを介する通信フローのための要求を含み、前記１つまたは複数のネットワークリソースが帯域幅を含む、請求項１５に記載の方法。
【請求項１７】
前記要求に対する応答が、前記通信フローを許可する工程、前記通信フローを終了させる工程、または、前記通信フローに割り当てられた前記リソースを変更する工程を含む、請求項１６に記載の方法。
【請求項１８】
プライオリティを指定するために、前記通信フローにおいて送信される１つまたは複数のパケットにマーキングする工程をさらに含む、請求項１６に記載の方法。
【請求項１９】
アプリケーション層、オペレーティンスシステム、または、エッジルータにおいて前記１つまたは複数のパケットにマーキングする工程をさらに含む、請求項１６に記載の方法。
【請求項２０】
前記クライアントデバイスに対応したポリシーエンジンを用いて、リソースへのアクセスが利用可能となるかどうかを判別する工程をさらに含む、請求項１５に記載の方法。
【請求項２１】
判別する工程が、パケットにおけるマーキング、通信フローのコンテンツ、または、通信フローの種類を定めるアプリケーションに基づいて、アクセスを提供するためのポリシーを設定する工程を含む、請求項２０に記載の方法。
【請求項２２】
ネットワークを介する通信フローを許可するための要求をアプリケーションから受信する工程と、
前記要求された通信フローのプライオリティを判別する工程と、
前記アプリケーションのためのアクセス権を示す応答を前記アプリケーションに送信する工程と、
ネットワークリソースの利用可能性を判別する工程と、
前記リソースの利用可能性およびプライオリティに基づいて、ネットワークリソースを前記通信フローに割り当てる工程と
を含む、ネットワークアクセスを制御するための方法。
【請求項２３】
前記リソースの利用可能性およびプライオリティに基づいて、前記ネットワークにおける他の通信フローに割り当てられたネットワークリソースを変更または強化する工程をさらに含む、請求項２２に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２０１３−５１６１０７（Ｐ２０１３−５１６１０７Ａ）
【公表日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１２−５４６０３１（Ｐ２０１２−５４６０３１）
【出願日】平成２２年１２月１５日（２０１０．１２．１５）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０６０３７３
【国際公開番号】ＷＯ２０１１／０８１９５３
【国際公開日】平成２３年７月７日（２０１１．７．７）
【出願人】（５１１１３０８１８）ティーティーアイ インベンションズ ディー エルエルシー (5)
【Ｆターム（参考）】
【公表日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２２年１２月１５日（２０１０．１２．１５）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０６０３７３
【国際公開番号】ＷＯ２０１１／０８１９５３
【国際公開日】平成２３年７月７日（２０１１．７．７）
【出願人】（５１１１３０８１８）ティーティーアイ インベンションズ ディー エルエルシー (5)
【Ｆターム（参考）】
[ Back to top ]