JP6641288B2 - ワイド・エリア・ネットワークを介したデーター転送に対する長期スケジュールの計算 - Google Patents

Description

[0001] ワイド・エリア・ネットワーク（ＷＡＮ）は、至る所に存在するようになりつつあり、比較的大きなボリュームのデーターが、ＷＡＮにおいて計算デバイス間で転送されることも多い。大きなボリュームのデーターの転送をサポートするために、それぞれのＷＡＮの運営業者は、かなりの量のリソースをコンピューター・ネットワーキング・ハードウェアに投資して、ＷＡＮにおける計算デバイス間のデーター転送を促進する。ＷＡＮにおけるこのようなコンピューター・ネットワーキング・ハードウェアの利用を最大化することは、したがって、効率の観点から望ましいことである。

[0002] 生憎、ネットワーク・データー・トラフィックを生成する、ＷＡＮにおけるデーター転送の要求元(requestor)は、互いに知らないのが通例である。つまり、データー転送の要求元は、ＷＡＮが要求を処理できるという期待をもって要求を出し、このデーター転送は直ちに開始される。これは比較的小さいボリュームのネットワーク・トラフィックでは大して問題にならないが、比較的大きなボリュームのデーターを伴うデーター転送が時間的に重複すると、ＷＡＮに過度に負担が強いられるおそれがある。このような重複転送は、１人以上の要求元が彼らの転送を他の時間に遅らせる選択肢を有していても、発生する可能性がある。何故なら、このようなデーター転送の時間をずらすことができるメカニズムが提供されていないからである。その結果、この柔軟性欠如が過度のネットワーク負担期間を生じさせるおそれがあるだけでなく、他の時間期間では、比較的少量のネットワーク・トラフィックしかないこともあるので、ＷＡＮのハードウェア・リソースが過小利用される時間期間もおそれがある。したがって、ＷＡＮの運営業者は、大きなボリュームのデーターがＷＡＮ上で転送される高デマンド時間期間に対処するために、費用がかかるコンピューター・ネットワーキング・ハードウェアを購入することを強いられることが多い。この結果、通例、ＷＡＮが過剰にプロビジョニングされ、このような費用がかかるコンピューター・ネットワーキング・ハードウェアがその寿命の大部分にわたって過小利用され続けることになる。

[0003] 以下は、本明細書において更に詳しく説明する主題の端的な摘要である。この摘要は、請求項の範囲のように限定することを意図するのではない。
[0004] 本明細書において説明するのは、複数のデーター転送要求に基づいて、ワイド・エリア・ネットワーク（ＷＡＮ）のようなネットワークにおけるデーター転送のスケジュールに関する種々の技術であり、要求(request)はそれぞれのデッドラインを有し、データー転送はそれぞれのデッドラインに前に完了されなければならない。実施形態例では、ネットワークは複数のデーター・センタ（各々複数の計算デバイスを含む）を含むことができ、データーを転送する要求は、第１データー・センタにおける計算デバイスから第２データー・センタにおける計算デバイスにデーターを転送する要求とすることができる。ネットワークにおけるデーター・センタは、パブリック・クラウドまたはプライベート・クラウドに含まれることも可能である。パブリック・クラウドは、インターネットによって、データー・センタのリソース（例えば、アプリケーションおよびストレージ）を一般公衆に露出する。対照的に、プライベート・クラウドは、データー・センタのリソースを、データー・センタを運営する私的企業に露出する。

[0005] 更に、ネットワークは、当該ネットワークにおけるデバイス間のデーター転送を促進する複数のデバイスを含む。これら複数のデバイスは、データーを格納し処理するように構成された複数の計算デバイスを含み、この複数の計算デバイスはネットワークのエッジに存在する。例えば、複数の計算デバイスは、データー・センタにおいてサーバー計算デバイスを含むことができる。加えて、複数のデバイスは、複数の計算デバイスにおける計算デバイス間で(among and between)データーの転送を導く(direct)ように構成されたネットワーク・インフラストラクチャー・デバイス（例えば、スイッチ、ルーター、ハブ、ゲートウェイ等）も含む。

[0006] また、ネットワークは、このネットワークを介したデーター転送をスケジューリングするように構成された制御計算デバイス(controller computing device)も含む。例えば、制御計算デバイスは、ネットワークにおけるそれぞれの計算デバイス間でデーターを転送する複数の要求を受けることができ、各要求は、１）それぞれの送信元計算デバイス（例えば、ここからデーターが転送される）、２）それぞれの受信先計算デバイス（例えば、ここにデーターが転送される）、３）送信元計算デバイスから受信先計算デバイスに転送されるそれぞれのデーター量、および４）それぞれのデッドラインを識別することができ、送信元計算デバイスから受信先計算デバイスへのデーター転送は、デッドラインの前に完了されなければならない。制御計算デバイスは、これらの要求を任意の時刻に受けることができ、要求は異なる量のデーターおよび異なるデッドラインを指定することができる。例えば、第１データー転送要求を第１時点において受けることができ、第１時点に近いデッドラインを指定することによって、このデーターの転送が比較的緊急であることを示すことができる。第２データー転送要求は、第２時点において受けることができ（第１時点および第２時点は近い）、第２時点から比較的遠いデッドラインを指定することによって、このデーター転送が特に時間には厳しくないことを示すことができる。

[0007] 制御計算デバイスは、このような要求を受けて、ネットワークにおけるデーターの転送に対して長期スケジュールを計算する。長期スケジュールは、複数の（潜在的に均一の）時間単位をカバーする(cover)ができ、ネットワークを通るデーター・フローは、長期スケジュールによってカバーされる時間単位毎に長期スケジュールにおいて定められる。このため、長期スケジュールは長期スケジュールによってカバーされる時間単位毎にサブスケジュールを含む。非限定的な例では、長期スケジュールは１２回の５分間隔をカバーすることができ、時間単位は５分間隔となる。長期スケジュールにおけるこれらの時間単位の各々に対して、長期スケジュールはそれぞれのサブスケジュールを含むことができる。サブスケジュールは、どの計算デバイスがそのサブスケジュールの時間単位の間送信元計算デバイスとして機能するか、計算デバイスがデーターを出力するそれぞれのレート、データーが送信元計算デバイスと受信先計算デバイスとの間を進むそれぞれの経路等を識別することができる。したがって、制御計算デバイスは、ネットワーク・リソースの利用を最大化しつつ、それぞれのデッドラインの前に、要求されたデーター転送の完了を促進するために、長期スケジュールを計算することを確認することができる。このために、一例では、制御計算デバイスは、長期スケジュールに基づいて、新たに受けたデーター転送要求を受け入れるかまたは拒否するか決定することができる（例えば、制御計算デバイスは、長期スケジュール、以前に受けたがデーター転送が未だ完了していない要求、およびそれらのそれぞれのデッドラインに基づいて、その指定されたデッドラインよりも前に、要求されたデーター転送を完了することができるか否か判定することができる）。制御計算デバイスは、新たに受けた要求、ネットワークにおける変化、満たされた要求（それぞれのデーター転送が完了した）等を考慮に入れるために、時の経過に連れて長期スケジュールを再計算する。実施形態例では、制御計算デバイスは、最適化プロセスを実行することによって、長期スケジュールを計算することができる。例えば、最適化プロセスは、混合パッキングおよびカバリング・アルゴリズム(mixed packing and covering algorithm)を含むことができる。

[0008] 制御計算デバイスは、更に、長期スケジュールに基づいて短期スケジュールを計算することができる。短期スケジュールは、長期スケジュールよりも少ない時間ユニットしかカバーすることができない。例えば、短期スケジュールは、現在の時間単位（例えば、５分間隔）の直後にある１つの時間単位をカバーすることができる。短期スケジュールは、１）ネットワークにおけるそれぞれのネットワーク・インフラストラクチャー・デバイスに対するルーティング・テーブル、ならびに２）送信元計算デバイスによって出力されるデーター、および送信元計算デバイスによってデーターが出力されるそれぞれのレートを識別する、送信元計算デバイスのための命令を含む。制御計算デバイスは、長期スケジュールにしたがってデーター転送の完了を促進するために短期スケジュールを計算する。制御計算デバイスは、ルーティング・テーブルおよび命令を短期スケジュールにおいて、ネットワークにおけるそれぞれのネットワーク・インフラストラクチャー・デバイスおよび送信元計算デバイスに送信する。

[0009] ネットワークがパブリック・クラウドにおいて露出された計算デバイス間におけるデーター転送をサポートする実施形態例では、制御計算デバイスは、パブリック・クラウドの運営業者の顧客に露出される価格設定スケジュール(pricing schedule)を計算することができる。制御計算デバイスは、経時的に要求を平滑化するために価格スケジュール(price schedule)を計算し、これによってネットワークのネットワーク・リソースの利用最大化を促進することができる。例えば、価格設定スケジュールは、緊急性が高いデマンド(demand)の要求(request)と比較して、緊急性が低いデマンドの要求程、転送されるデーター単位毎に少ない料金が関連付けられることを示すことができる。他の例では、価格設定スケジュールは、特定の時間期間内にデッドラインが関連付けられたデーター転送は、他の時間期間（特定の時間期間よりも少ないデマンドに関連付けられた）内にデッドラインが関連付けられたデーター転送と比較して、一般に、転送されるデーターの単位毎に課金が多くなることを示すことができる。更にまた、データー転送の価格は、送信元および／または宛先計算デバイス（１つまたは複数）に基づくこともできる。

[0010] 以上の摘要は、本明細書において説明するシステムおよび／または方法の一部の形態の基本的な理解が得られるようにするために、簡略化した摘要を紹介する。この摘要は、本明細書において説明するシステムおよび／または方法の広範が全体像ではない。主要となる／必須のエレメントを識別することや、このようなシステムおよび／または方法の範囲を正確に定めることを意図するのではない。その唯一の目的は、後に紹介する更に詳細な説明に対する序説として、一部の概念を簡略化した形態で紹介することである。

図１は、ネットワークにおける計算デバイス間におけるデーター転送のスケジューリングを容易にするシステム例の機能ブロック図である。 図２は、ネットワークにおけるデーター転送に対する長期スケジュール例である。 図３は、ネットワークにおけるデーター転送に対する短期スケジュール例である。 図４は、ＷＡＮにおけるデーター転送に対して長期スケジュールおよび短期スケジュールを生成することができるスケジューラー・コンポーネント例の機能ブロック図である。 図５は、ネットワーク・グラフ例である。 図６は、ネットワークを介したデーター転送の要求受領を促進するために、顧客に露出することができるグラフィカル・ユーザー・インターフェース例である。 図７は、ネットワークにおいてデーター転送をスケジューリングする方法例を示す流れ図である。 図８は、ネットワークにおけるデーター転送に対して長期スケジュールを計算する方法例を示す流れ図である。 図９は、ネットワークにおけるデーターの転送に対応する価格スケジュールを露出する方法例を示す流れ図である。 図１０は、計算システム例である。

[0021] これより図面を参照して、ネットワーク（ワイド・エリア・ネットワーク（ＷＡＮ）のような）における計算デバイス間のデーター転送に関する種々の技術について説明する。図面においては、同様のエレメントを示すために全体を通じて同様の参照番号が使用される。以下の説明では、説明の目的に限って、１つ以上の形態の完全な理解が得られるようにするために、数多くの具体的な詳細を説明する。しかしながら、このような形態（１つまたは複数）は、これら具体的な詳細がなくても実施できることは明らかであろう。その一方で、周知の構造およびデバイスは、１つ以上の形態を説明し易くするために、ブロック図形態で示される。更に、１つのシステム・コンポーネントによって実行されると説明される機能が、複数のコンポーネントによって実行されてもよいことは理解されよう。同様に、例えば、１つのコンポーネントが、複数のコンポーネントによって実行されると説明される機能を実行するように構成される場合もある。

[0022] 更に、「または」(or)という用語は、排他的な「または」ではなく、包含的な「または」を意味することを意図している。即ち、別段指定されない限り、または文脈から明らかでない限り、「ＸはＡまたはＢを採用する」という句は、自然な包含的置換(natural inclusive permutation)のいずれかを意味することを意図している。即ち、「ＸはＡまたはＢを採用する」という句は、以下の実例、ＸはＡを採用する、ＸはＢを採用する、またはＸはＡおよびＢ双方を採用するのいずれによっても満たされる。加えて、冠詞「ａ」および「ａｎ」は、本願および添付する特許請求の範囲において使用する場合、一般に、別段指定されない限り、または文脈から単数形に向けられることが明らかでない限り、「１つ以上」を意味するように解釈されてしかるべきである。

[0023] 更に、本明細書において使用する場合、「コンポーネント」および「システム」という用語は、プロセッサーによって実行されるとある種の機能を実行させるコンピューター実行可能命令が構成されたコンピューター読み取り可能データー・ストレージを含むことを意図している。コンピューター実行可能命令は、ルーチン、関数等を含むことができる。また、コンポーネントまたはシステムは１つのデバイス上に配置されても、または様々なデバイスにわたって分散されてもよいことも理解されよう。更に、本明細書において使用する場合、「例示的」(exemplary)という用語は、あるものの実証例または一例として役割を果たすことを意味することを意図しており、好み(preference)を示すことを意図するのではない。

[0024] これより図１を参照すると、ネットワーク１０２においてデーター転送に対して長期スケジュールを計算するように構成された制御計算デバイス例１００が示されている。例えば、ネットワーク１０２はＷＡＮとすることができる。制御計算デバイス１００はネットワークに対して外部であるように示されているが、これは例示の目的のためであって、制御計算デバイス１００はネットワーク１０２内に含まれることは理解されよう。更に、制御計算デバイス１００は１つの計算デバイスであるように示され説明されるが、制御計算デバイス１００は、論理的な集中制御システムも含み、制御計算デバイス１００によって実行されると説明される機能は、様々な計算デバイスにまたがって分散されてもよい。

[0025] ネットワーク１０２は、ネットワーク１０２のエッジ上に存在する複数の計算デバイス１０４〜１１０を含む。実施形態例では、複数の計算デバイス１０４〜１１０における計算デバイスの台数は、１０台の計算デバイスおよび３０００台の計算デバイスの間であることができる。他の実施形態例では、複数の計算デバイス１０４〜１１０における計算デバイスの台数は、１０台の計算デバイスおよび１００，０００台の計算デバイスの間であることができる。実施形態例では、計算デバイス１０４〜１１０は、それぞれのサーバー・ラック内に存在するサーバー計算デバイスであることができる。更に、一例では、計算デバイス１０４〜１１０がそれぞれの異なるデーター・センタにあってもよく、各データー・センタが、互いに通信可能なそれぞれの複数の計算デバイスを含む。データー・センタは、パブリックおよび／またはプライベート・クラウドのプロビジョニングを容易にするために採用することができる。パブリック・クラウドは、インターネットによってデーター・センタのリソースを公衆に露出し（例えば、費用について）、一方プライベート・クラウドは、データー・センタのリソースを、このデーター・センタを運営する企業に露出する。更に、ネットワーク１０２は、計算デバイス１０４〜１１０間におけるデーターの転送を促進する複数のネットワーク・インフラストラクチャー・デバイス１１２〜１１４も含む。例えば、ネットワーク・インフラストラクチャー・デバイス１１２〜１１４は、スイッチ、ルーター、ハブ、ゲートウェイ等とすることができ、またはこれらを含むことができる。一例によれば、複数のネットワーク・インフラストラクチャー・デバイスにおけるネットワーク・インフラストラクチャー・デバイスの台数は、１０台のデバイスおよび１０００台のデバイスの間であることができる。他の例では、複数のネットワーク・インフラストラクチャー・デバイスにおけるネットワーク・インフラストラクチャー・デバイスの台数は、１００台のデバイスおよび１００００台のデバイスの間であることができる。

[0026] 一例では、計算デバイス１０４〜１１０の内１つに保持されたデーターの所有者が、このようなデーターを計算デバイス１０４〜１１０の内他のものに転送することを望む場合がある。従来では、例えば、第１計算デバイス１０４から第３計算デバイス１０８にデーターを転送する要求を受けたとき、スケジューリングは殆ど必要とされない。代わりに、第１計算デバイス１０４はできるだけ高いレートでデーターを転送し始め、データーは、１本以上の経路に沿って進んでネットワーク１０２を通過して第３計算デバイス１０８に達し、ネットワーク１０２のインフラストラクチャーに負担をかける可能性がある。具体的には、ネットワーク・インフラストラクチャー・デバイス１１２〜１１４には、通例、意図する受信先（第３計算デバイス１０８）までデーターを導くとき、ネットワーク・リンクを通って送信される負荷の均衡を取るための命令が構成される(configure)。この手法は、 ＷＡＮ１０２の運営業者が最大データー転送デマンドを満たす十分なネットワーク容量を提供する、プロビジョニング過剰なネットワークにとっては有効である。しかしながら、これは、ネットワーク１０２のリソース使用が非効率的になる傾向がある。

[0027] 以下で更に詳しく説明するが、制御計算デバイス１００は、ネットワーク１０２上におけるデーター転送に対して長期スケジュールを計算し、その結果、経時的にネットワーク１０２上におけるトラフィックのボリュームを円滑化し、こうしてネットワーク１０２の利用効率を高めることができる。このために、制御計算デバイス１００は、従来の手法とは対照的に、ネットワーク１０２におけるデーター転送に対して長期スケジュール（計画）を計算するときに、転送デッドライン（異なる時刻に受信され、異なる期間を有する）を考慮する(contemplate)。

[0028] 長期スケジュールの計算に関して更に詳細に説明すると、制御計算デバイス１００は、複数のデーター転送要求を受けることができる受信コンポーネント１１６を含む。例えば、ネットワーク１０２は同時に１００，０００の別々のトラフィック・フロー（例えば、計算デバイス１０４〜１１０における計算デバイス間のデーター転送）をサポートするように構成することができる。受信コンポーネント１１６が受けるデーター転送要求は、送信されるデーターの送信元のそれぞれの識別、送信されるデーターの意図する受信先のそれぞれの識別、ＷＡＮ１０２上で送信されるデーターのそれぞれのボリューム、およびそれぞれのデッドラインを含む。更に特定すると、受信コンポーネント１１６が受けるデーター転送要求は、１）データーが転送される元である送信元計算デバイスの識別、２）転送されるデーターの指示、３）転送されるデーターを受信する受信先計算デバイスの識別、４）送信元計算デバイスから受信先計算デバイスに転送されるデーターのボリューム、および５）デッドラインを含み、このボリュームのデーターは、送信元計算デバイスから受信先計算デバイスにデッドラインよりも前に転送されなければならない。更に、要求は複数の可能なデッドラインを含むことができ、転送のための費用はデッドラインに依存して変化することは理解されよう。受信コンポーネント１１６は、送信元計算デバイスから、受信先計算デバイスから、または送信元計算デバイスから受信先計算デバイスに転送されるデーターの所有者によって操作される他の計算デバイスから、データー転送要求を受けることができる。データー転送要求は、計算デバイス１０４〜１１０におけるデバイスの内任意のものから受けることができ、あるいはデーターが転送される元であるサーバー（１つまたは複数）を識別するシステムまたはコンポーネントから受けることができる。一例では、以上で言及したシステムまたはコンポーネントは、特定の送信元および目標計算デバイスを要求において識別する必要はない。つまり、要求はもっと一般的であることが可能であり、ネットワークにおける経路についての情報、転送レート等を求める。

[0029] 非限定的な例では、受信コンポーネント１１６は第１データー転送要求を受けることができ、第１データー転送要求は、第１計算デバイス１０４を送信元計算デバイスとして識別し、転送されるデーターを識別し、第３計算デバイス１０８を受信先計算デバイスとして識別し、データーのボリュームが５０テラバイトであることを識別し、このような転送は、データー転送要求の日の午後４時よりも前に完了しなければならないことを確認する。同様に、受信コンポーネント１１６はＭ番目のデーター転送要求を受けることができ、Ｍ番目のデーター転送要求は、第２計算デバイス１０６を送信元計算デバイスとして識別し、転送されるデーターを識別し、第１計算デバイス１０４を受信先計算デバイスとして識別し、このデーターのボリュームが５ペタバイトであることを識別し、このようなデーター転送が次の日の午前５時までに完了しなければならないことを確認する。

[0030] 加えて、制御計算デバイス１００は、受信コンポーネント１１６と通信するスケジューラー・コンポーネント１１８を含む。制御計算デバイス１００は、データー・ストア１２０にアクセスすることができ、データー・ストア１２０はネットワーク・マップ１２２を含む。ネットワーク・マップ１２２は、ネットワーク１０２の物理的トポグラフィ(physical topography)を表す。例えば、ネットワーク・マップ１２２は、ネットワーク１０２を表すコンピューター実装グラフであってもよく、このグラフは、ネットワーク１０２におけるデバイス（例えば、計算デバイス１０４〜１１０、およびネットワーク・インフラストラクチャー・デバイス１１２〜１１４）を表すノード、およびそれぞれのデバイス間における通信リンクを表すエッジを含む。更に、ネットワーク・マップ１２２は、ネットワーク１０２のそれぞれのリンクの容量というような、ネットワーク１０２の制約(constraint)を識別するデーターを含むことができる。実施形態例では、ネットワーク・マップ１２２は、ネットワーク１０２のデバイスから受信されるデーターに基づいて適時更新することができる。例えば、特定のリンクが故障していることを示すデーターを、ネットワーク１０２におけるデバイスから受信することができる。他の例では、特定のリンクが復旧したことを示すデーターを、ネットワーク１０２におけるデバイスから受信することができる。ネットワーク・マップ１２２は、ネットワーク１０２のトポロジーにおけるこれらの変更を反映するために適宜更新することができる。

[0031] スケジューラー・コンポーネント１１８は、複数のデーター転送要求（時の経過に連れて）およびデーター・レポジトリー１２０からのネットワーク・マップ１２２を受信し、このデーター転送要求およびネットワーク・マップ１２２に基づいてネットワーク１０２におけるデーター転送に対して長期スケジュール１２４を計算し、長期スケジュール１２４をデーター・レポジトリー１２０に格納する。加えて、図示しないが、スケジューラー・コンポーネント１１８は、過去のネットワーク利用に基づいて長期スケジュールを計算することもできる。例えば、顧客が過去に毎日特定の時刻にデーターの転送を要求したことがある場合、受信コンポーネント１１６がこの顧客からデーター転送要求を未だ受けていなくても、スケジューラー・コンポーネント１１８は、長期スケジュールにおいてこの顧客のためにネットワーク・リソースを確保することができる。更にまた、スケジューラー・コンポーネント１１８は、長期スケジュールを計算するとき、その場限りの(ad-hoc)要求のためにネットワーク・リソースを確保することができる。その場限りの要求とは、通例、デッドラインが指定されず、比較的小さなボリュームのデーターをネットワーク１０２上で転送することを要求するものである。一例では、そして以下で更に詳しく説明するように、スケジューラー・コンポーネント１１８は、長期スケジュール１２４を計算するときに、最適化プロセスを実行することができる。最適化プロセスは、混合パッキングおよびカバリング・アルゴリムの実行を含むことができる。

[0032] 長期スケジュール１２４に関する追加の詳細についてこれより説明する。長期スケジュール１２４は、時間的に先行する複数の時間単位（例えば、今後の時間単位）をカバーする。実施形態例では、長期スケジュール１２４によってカバーされる時間単位は、これらの時間単位が共通の期間を有するように、均一にすることができる。他の実施形態例では、長期スケジュールによってカバーされる時間単位は非均一でもよく、この場合、長期スケジュール１２４によってカバーされ現在の時刻に時間的に近接する時間単位の期間は、長期スケジュールによってカバーされ時間的に現在の時刻から離れている時間単位よりも短い。一例によれば、長期スケジュール１２４は、２４０の連続する１分の時間枠（例えば、４時間の総時間枠）をカバーすることができ、長期スケジュール１２４によってカバーされる時間単位は１分の枠である。長期スケジュール１２４は、長期スケジュール１２４によってカバーされる時間単位毎に、それぞれのサブスケジュールを含み、サブスケジュールはその時間単位中においてネットワーク１０２を通過するデーター・フローを定める。

[0033] 例えば、サブスケジュールは、計算デバイス１０４〜１１０においてどの計算デバイスが送信元計算デバイスであるか識別し、計算デバイス１０４〜１１０においてどの計算デバイスが受信先計算デバイスであるか識別し（１つの計算デバイスが送信元計算デバイスおよび受信先計算デバイスの双方であることが可能である）、それぞれの送信元計算デバイスがデーターを出力するレートを識別し、データーが送信元計算デバイスから受信先計算デバイスに転送されるときに通る経路を識別することができる。時間が先に進むに連れて長期スケジュールが特定の期間の時間枠をカバーするように、スケジューラー・コンポーネント１１８は、時間が経過するに連れて長期スケジュール１２４を再計算する。長期スケジュールの再計算によって、更に、新たなデーター転送要求（その場限りまたはデッドライン指定）を想定する(contemplate）こと、ネットワーク１０２のトポロジー変化を想定すること、要求の完了を想定すること等が可能になる。この長期スケジュール１２４の計算を実行するプロセス例について、以下で説明する。

[0034] スケジューラー・コンポーネント１１８は、長期スケジュール１２４に基づいて、短期スケジュール１２６を計算することができ、短期スケジュール１２６をデーター・レポジトリー１２０に格納することができる。短期スケジュール１２６は、現在の時間単位の直後にある時間単位（例えば、次の１分時間枠）の間においてネットワーク１０２を通過するデーター・フローを定める。したがって、短期スケジュール１２６は、長期スケジュール１２４よりも少ない時間単位をカバーする。実施形態例では、短期スケジュール１２６は１つの時間単位をカバーすることができる。短期スケジュール１２６は、１）ネットワーク・インフラストラクチャー・デバイス１１２〜１１４のそれぞれのためのルーティング・テーブル、および短期スケジュール１２６によってカバーされる時間中に特定のデーターを出力するか否かについて、計算デバイス１０４〜１１０における送信元計算デバイスに対する命令、およびこの特定のデーターを出力するレートを含む。制御計算デバイス１００は、それぞれのルーティング・テーブルをネットワーク・インフラストラクチャー・デバイス１１２〜１１４に送信することができ、それぞれの命令を計算デバイス１０４〜１１０の１つ以上に送信することができる。

[0035] したがって、それぞれのデッドラインよりも前に、受け入れられたデーター転送要求に対応する、要求されたデーター転送の完了を促進するために、スケジューラー・コンポーネント１１８が長期スケジュール１２４および短期スケジュール１２６を計算することを確認することができる。他の例では、データー転送の完了が可能でない場合、スケジューラー・コンポーネント１１８は、収益の損失を最小限に抑えるため、要求のあるパーセンテージを満たす（例えば、全ての要求の内９５％を満たす）ことを可能にする等のために、長期スケジュール１２４を計算することができる。加えて、先に注記したようにスケジューラー・コンポーネント１１８は、長期スケジュール１２４に基づいて、受けたデーター転送要求を受け入れるかまたは拒否するか決定することができる。一例によれば、長期スケジュール１２４は、特定の時間枠に対して、ネットワーク１０２における一定のリンクが最大容量でデーターを送信するようにスケジューリングされていることを示すことができる。この情報に基づいて、スケジューラー・コンポーネント１１８は、デッドラインよりも前にデーター転送要求を完了することができないという指示を要求元に出力することができる（このデーター転送要求によって生じる容量増大を、リンクがサポートできないため）。スケジューラー・コンポーネント１１８は、加えて、データー転送をスケジューリングするときに他の分析を行うこともできる。例えば、パブリック・クラウドにおいて動作するとき、スケジューラー・コンポーネント１１８は、利益を最大化するため、損失を極力抑えるため等で、受けた要求を受け入れるかまたは拒否するか決定するように構成することができる。

[0036] 加えて、制御計算デバイス１００は、価格設定コンポーネント１２８を含むことができる。価格設定コンポーネント１２８は、長期スケジュール１２４に基づいて、価格設定スケジュールを顧客に露出することができる。例えば、計算デバイス１０４〜１１０の少なくとも１つが、パブリック・クラウドによってリソースを露出するデーター・センタに含まれるとき、このパブリック・クラウドの顧客はデーターの転送に対して料金を支払うこともあり得る。価格設定コンポーネント１２８は、データー転送に対する価格を、データー転送要求におけるデッドライン（の長さ）、転送を完了させる時刻等の関数として設定することができる。例えば、価格設定コンポーネント１２８は、データー転送要求のデッドラインが現在時刻よりも時間的に離れているときに転送されるデーターの単位当たりに設定する価格を低くすることができる。価格設定コンポーネント１２８は、ネットワーク利用を所望の動作点（operating point)に引き上げるように価格スケジュールを計算することができる。即ち、価格設定コンポーネント１２８は、デッドライン・ベースのデーター転送要求に基づいて、ネットワーク１０２におけるデーター転送要求を操作するために価格を設定することができる。つまり、コスト削減を達成するために、データー転送要求の発起側(initiator) に、デッドラインを長くする動機付けをさせるのでもよい。更に、価格設定コンポーネント１２８は、価格の申し出を受け入れるまたは拒否するように構成することができる。例えば、要求は複数のデッドラインを識別することができ、各デッドラインには特定の価格が関係付けられる（例えば、転送される単位毎）。例えば、転送が第１時点までに完了した場合、要求元は第１価格を支払う用意があり、転送が第２時点までに完了した場合、要求元は第２価格を支払う用意がある等を、要求が示すことができる。価格設定コンポーネント１２８は、価格（つまり、デッドライン）を選択するように動作することができ、価格設定コンポーネント１２８の動作(action)に基づいて、長期スケジュールを計算することができる。

[0037] これより図２を参照して、スケジューラー・コンポーネント１１８によって計算される長期スケジュール１２４の図示例を示す。確認できるように、長期スケジュール１２４は複数の時間単位（時間単位１〜時間単位P)をカバーすることができる。したがって、長期スケジュール１２４は、複数のサブスケジュール２０２〜２１０を含み、時間単位毎に１つのサブスケジュールがあることが認められる。サブスケジュール２０２〜２１０における各サブスケジュールは、そのそれぞれの時間単位の間データーがどのようにネットワーク１０２を通過するか定めることができる。例えば、長期スケジュール１２４における第１サブスケジュール２０２は、第１時間単位（例えば、第１時間単位によって表される５分間）の間、データーがどのようにネットワーク１０２を通過するか定めることができる。したがって、第１サブスケジュール２０２は、送信元計算デバイスと受信先計算デバイスとの間におけるデーター転送（トラフィック・フロー）毎に送信元がデーターを出力するレート、出力データーが受信先計算デバイスに到達するために進む経路（１本または複数）を定めることができる。したがって、第１サブスケジュール２０２は、種々のトラフィック・フローのレートおよび経路を構成する（または指定する）ことができ、各トラフィック・フローはそれ自体の送信元および受信先計算デバイスを有し、各トラフィック・フローには、このトラフィック・フローが送信元計算デバイスから受信先計算デバイスまで進む経路（１本または複数）が定められる。先に示したように、時間単位１〜Pは共通の期間を有してもよく、一例では、１分および５分の間にすることができる。他の例では、時間単位１〜Pが異なる期間を有してもよい。例えば、第１時間単位は、P番目の時間単位よりも短い期間を有してもよい。特定の例によれば、第１サブスケジュール２０２の第１時間単位は１分の時間期間を有するのでもよく、一方P番目のスケジュール２１０のＰ番目の時間単位は１０分の時間期間を有するのでもよい。

[0038] これより図３を参照して、短期スケジュール１２６の図示例を示す。短期スケジュール１２６は、直後の時間単位（時間単位０）をカバーする。短期スケジュール１２６は、それぞれ、複数のネットワーク・インフラストラクチャー・デバイス１１２〜１１４ に対応する複数のルーティング・テーブル３０２〜３０６、および複数の計算デバイス１０４〜１１０にそれぞれ対応する複数の命令３０８〜３１２を含む。複数の命令３０８〜３１２は、計算デバイス１０４〜１１０の内、データー転送要求を満足するためにデーター出力し始めるもの、そして計算デバイス（１つまたは複数）がこのようなデーターを出力するレート（１つまたは複数）を定める。スケジューラー・コンポーネント１１８は、ルーティング・テーブル３０２〜３０６をそれぞれのネットワーク・インフラストラクチャー・デバイス１１２〜１１４に送信することができ、スケジューラー・コンポーネント１１８は、命令３０８〜３１２をそれぞれの計算デバイス１０４〜１１０に送信することができる。このように、第１ルーティング・テーブル３０２は第１ネットワーク・インフラストラクチャー・デバイス１１２に送信され、Ｎ番目のルーティング・テーブル３０６はN番目のネットワーク・インフラストラクチャー・デバイス１１４に送信される。第１ネットワーク・インフラストラクチャー・デバイス１１２は、第１ルーティング・テーブル３０２を受信したことに応答して、ルーティング・テーブル３０２が構成され（時間単位０の間）、第１ルーティング・テーブル３０２の内容にしたがって、ネットワーク・インフラストラクチャー・デバイス１１２によって受信されたデーターを導く。同様に、第１命令３１０は第１計算デバイス３０４に送信され、Ｚ番目の命令３１２はＺ番目の計算デバイス１１０に送信される。したがって、一例では、第１計算デバイス３０４は、第１命令３１０の受信に応答して、第１命令３１０にしたがってデーターを出力する。

[0039] これより図４を参照すると、スケジューラー・コンポーネント１１８の詳細な図が示されている。スケジューラー・コンポーネント１１８は、データー・レポジトリー１２０にアクセスし、ネットワーク・マップ１２２を引き出すことができる。スケジューラー・コンポーネント１１８は、ネットワーク・マップ１２２を受信するネットワーク・グラフ構築コンポーネント４０１を含み、ネットワーク・マップ１２２および長期スケジュール１２４によってカバーされる複数の時間単位に基づいて、ネットワーク・グラフ４０２を構築する。スケジューラー・コンポーネント１１８は、ネットワーク・グラフ４０２をデーター・レポジトリー１２０内に保持させる。ネットワーク・グラフ４０２を構築するとき、ネットワーク・グラフ構築コンポーネント４０１は、ネットワーク・マップ１２２の複数のインスタンスを、つまり、長期スケジュール１２４によってカバーされる時間単位毎に１つのインスタンスを生成することができる。ネットワーク・グラフ構築コンポーネント４０１は、同じデバイスを表すネットワーク・マップ１２２のインスタンスにおけるノードを結合するエッジを生成することによって、ネットワーク・マップ１２２の異なるインスタンスを結合することができる。

[0040] 端的に図５を参照すると、ネットワーク・グラフ構築コンポーネント４０１によって構築することができるネットワーク・グラフ例５００が示されている。ネットワーク・グラフ例５００は、第１時間単位に対するネットワーク・マップの第１インスタンス５０１ａ、および第２時間単位に対するネットワーク・マップの第２インスタンス５０１ｂを含む。ネットワーク・マップ１２２の第１インスタンス５０１ａは、それぞれネットワーク１０２の計算デバイス１０４〜１１０を表す第１複数のノード５０２ａ〜５０８ａと、それぞれネットワーク・インフラストラクチャー・デバイス１１２〜１１４を表す第２複数のノード５１０ａ〜５１２ａとを含む。ネットワーク・マップ１２２の第１インスタンス５０１ａは、ネットワーク１０２におけるデバイス間の物理リンクを表すエッジ（実線で示す）を含む。加えて、ネットワーク・マップ１２２の第２インスタンス５０１ｂもこのようなエッジを含む。一例では、エッジには、ネットワーク・マップ１２２のインスタンスにおいて異なる重み付けを行うことができる。例えば、第２時間単位と比較して、第１時間単位の間にはネットワーク１０２における特定のリンクにより多くの帯域幅を確保することが望ましい場合がある。これは、ネットワーク・グラフ５００において、ネットワーク・マップ１２２の第１インスタンス５０１ａおよびネットワーク・マップ１２２の第２インスタンス５０１ｂにおけるリンクへの異なる重みの指定によって表すことができる。

[0041] また、ネットワーク・グラフ４０２は複数のエッジ５１４〜５２４も含む。エッジ５１４〜５２４は、ネットワーク・マップ１２２のインスタンス５０１ａおよび５０１ｂ間において、同じデバイスを表すノードを結合する。例えば、第１エッジ５１４はノード５０４ａをノード５０４ｂと結合し、５０４ａおよび５０４ｂは双方共第２計算デバイス１０６を表す。同様に、第２エッジ５１６は、ノード５０２ａをノード５０２ｂに結合し、ノード５０２ａおよび５０２ｂは双方共ネットワーク１０２における第１計算デバイス１０４を表す。実施形態例では、比較的高い重みをエッジ５１４〜５２４に指定することができる。したがって、ネットワーク・グラフ４０２によって、複数の異なる時間単位においてネットワーク１０２を表すことができる。実線で示すエッジには、例えば、このようなエッジによって表される物理ネットワーク・リンクの容量、これらの時間単位におけるこれらの物理リンクの過去のデマンド、これらの何らかの組み合わせなどに基づいて重み付けすることができる。図示しないが、ネットワーク・グラフ５００が、第３時間単位に対応するネットワーク・マップ１２２の第３インスタンスを含む場合、ＷＡＮマップ１２２の第３インスタンスにおける各ノードは、ネットワーク・グラフ５００において同じデバイスを表す全てのノードに結合される。

[0042] 図４に戻り、スケジューラー・コンポーネント１１８は、更に、経路制約コンポーネント４０４も含むことができる。経路制約コンポーネント４０４は、ネットワーク・グラフ４０２を受け、経路に基づく制約をネットワーク・グラフ４０２に適用する。例えば、計算の複雑さを減らすために、経路制約コンポーネント４０４は、送信元と宛先との間に可能な経路の本数を、何らかの閾値本数の経路に制約することができ、送信元計算デバイスと宛先計算デバイスとの間におけるネットワーク・ホップの回数に基づいて経路を制約することができ（例えば、送信元と宛先との間で閾値数よりも多いホップを有するネットワーク経路は、送信元と受信先との間で経路を決定するときに考慮されない）、または他の適した制約が可能である。制約をネットワーク・グラフ４０２に適用したことに応答して、スケジューラー・コンポーネント１１８は制約グラフ４０６をデーター・レポジトリー１２０に格納することができる。

[0043] スケジューラー・コンポーネント１１８は、更に、最適化コンポーネント４０８も含むことができる。最適化コンポーネント４０８は、制約グラフ４０６、および全ての保留中のデーター転送要求（例えば、既に受領され受け入れられたデーター転送要求であり、それぞれのデーター転送は未完了である）に関係するデーターを受け、保留中のデーター転送要求、それらのそれぞれのステータス（例えば、転送されるデーター量、要求のそれぞれのデッドラインよりも前の時間量等）、および制約グラフ４０６に基づいて、長期スケジュール１２４を出力する。先に示したように、最適化コンポーネント４０８は、長期スケジュールを計算するために適した最適化プロセスを実行することができる。実施形態例では、最適化プロセスは、混合パッキングおよびカバリング・アルゴリズムの実行を含むことができ、最適化コンポーネント４０８は、（例えば）経時的なネットワーク利用を平滑化し要求のデッドラインを満たすために、長期スケジュール１２４を計算する。実施形態例では、最適化コンポーネント４０８は、並列化バージョンの混合パッキングおよびカバリング・アルゴリズムを実行することができる。並列化は、状況が変化するにつれて時の経過と共に長期スケジュール１２４の繰り返し計算を可能にするために必要となる場合がある。予測−最大化手法(expectation-maximization approaches)、線形プログラミング・プロセス等を含む他のタイプの最適化手法も、長期スケジュール１２４を生成するために使用することができる。最適化コンポーネント４０８は、長期スケジュール１２４に基づいて、短期スケジュール１２６を生成することができる。

[0044] ここで最適化コンポーネント４０８によって実行することができる最適化プロセス例に関する更なる詳細について説明する。一般に、最適化コンポーネント４０８は、コンピューター実装グラフＧ＝（Ｖ，Ｅ）を受ける。ここで、｜Ｖ｜= nおよび｜Ｅ｜= mであり、負でないエッジ容量 ｃ：Ｅ→Ｒ_＋である。長期要求は、タプル（ａ_ｉ、ｂ _ｉ、ｄ_ｉ、Ｄ_ｉ、ｓ_ｉ、ｔ_ｉ、Ｐ_ｉ）によって定めることができる。ここで、ａ_ｉは、最適化コンポーネント４０８が要求を認識した認識時点であり、b_iは、デマンドをスケジューリングすることができる開始時点であり、ｄ_ｉは、デッドラインであり、その後には要求をスケジューリングすることができない。Ｄ_ｉは、要求のデマンド(demand of the request)であり、ｓ_ｉは、要求を導かなければならない送信元ノードであり、ｔ_ｉは、要求を受け入れなければならない先のターゲット・ノードであり、Ｐ_ｉは、要求のｓ_ｉからｔ_ｉまでの受入可能な経路の集合体である。

[0045] 時間ステップτが始まるとき、最適化コンポーネント４０８は全ての長期要求ｉを認識する。ここで、α_ｉ＝τである。加えて、最適化コンポーネント４０８は、時点τにおける高い優先順位（例えば、その場限り）の要求によって必要とされ得るエッジｅの容量ｃ_ｅの端数(fraction)についての推定値Ｘ_ｅ，τを有することができる。Ｘ_ｅ，τは推定値であるので、その場限りの要求にサービスするために必要とされる容量の実際の端数は、時間τの開始時に分かる（そのような時点において行われる長期要求と共に）。

[0046] 先に示したように、最適化コンポーネント４０８は、スケジューリング問題を混合パッキングおよびカバリング問題として扱うことができ、したがってパッキングおよびカバリング制約を使用してスケジュールを生成することができる。例えば、最適化コンポーネント４０８は、時間τにおいて経路ｐ∈Ｐ_ｉ上における要求ｉに割り当てられるフローの量に対応する変数ｆ_{ｉ，ｐ，τ}を使用することができる。ここで、ｂ_ｉ≦τ≦ｄ_ｉである。これらの変数を使用して、割り当ての実現可能性をアサートする線形パッキングおよびカバリング不等式を定式化することができ、あらゆる時間においておよびあらゆるエッジに対して、それに割り当てられるフロー全体がその容量を超えることはない。各長期要求ｉには、そのデッドラインまで、そのデマンドＤ_ｉの少なくとも端数α_ｉが割り当てられる。

[0047] これらの不等式は、様々な理由のために、時の経過と共に発展し変化する。その理由とは、新たな長期要求が届くこと、エッジの高優先順位使用の確率的実現（例えば、その場限りの要求にサービスするため）が解明されること、そして遠い未来におけるエッジの過小割り当てが、時間が進むに連れて減少することである。最適化コンポーネント４０８は、不等式の変化に応答して、変数ｆ_{ｉ，ｐ，τ}を調節することによって、スケジュールを適応させる。尚、この手法は、現時間インスタンス(time instance)に対するスケジュールだけを計算する方式を改良することを注記しておく。何故なら、最適化コンポーネント４０８は、比較的遠い未来にフローをスケジューリングし、ｉ番目の要求(request)が受けたデマンド(demand)の端数において約束されたα_ｉの出力を可能にするからである。

[0048] 更に、示したように、最適化コンポーネント４０８は高優先順位（その場だけ）のデーター転送要求を訂正することができる。Ｘ_ｅ，τは、時点τにおいて高優先順位デマンドによって必要とされるエッジｅの容量の端数の推定値である。つまり、先の不等式を定式化するとき、時点τにおける容量ｃ_ｅを使用する代わりに、最適化コンポーネント４０８は（１−Ｘ_ｅ，τ）・ｃ_ｅを使用することができる。一旦時点τに到達し、このような端数の実現が観察されたなら、最適化コンポーネント４０８は、そのエッジｅが過剰使用されていること、例えば、ｅにおけるフロー全体がその容量を超えていることを発見することができる。これが発生したとき、最適化コンポーネント４０８は、ｅ∈ｐが成り立ついくつかの予めスケジューリングされているフローｆ_{ｉ、ｐ、τ}を減らすことができる。これは、最適化コンポーネント４０８によって出力された約束(promise)α_ｉに対する影響を最小限に抑えるために、小さな線形プログラム（そのサイズは、元のコンピューター実装グラフＧのサイズのみに依存し、τには依存しない）を定式化することによって行うことができる。

[0049] 更に、最適化コンポーネント４０８は、遠い未来にあるエッジを過小利用し（例えば、グラフＧに制約をかける）、時間が進むに連れてこの制限を緩和するように構成することができる。例えば、パラメータβ_{ｅ、ｔ、τ}を使用して、時点τにおいて最適化コンポーネント４０８によって利用することができる（１−Ｘ_ｅ，τ）・ｃ_ｅの端数を判定することができる。時間τが進むにつれて、β_{ｅ、ｔ、τ}は増大することができる（例えば、過小利用制限が緩和する）。

[0050] 実施形態例では、最適化コンポーネント４０８は、「公平な」目的に対応する最悪の約束αを最大化するように構成することができる。αを最大化するにも拘わらず、ネットワーク１０２のある部分が過小利用されてもよく、より多くのフローを割り当てることができる。この問題に取り組むために、最適化コンポーネント４０８は副ユーティリティ関数(secondary utility function)を採用し、例えば、平均約束δを最大化することができ、これによって、ネットワークをより多く利用するスケジュールが得られる。このユーティリティは、カバリング不等式として定式化することができる。

[0051] 尚、過度に長い、例えば、ｄ_ｉ−ａ_ｉが非常に大きい長期要求は、最適化コンポーネント４０８の実行時間を遅らせる可能性があることを確認することができる。解を比較的素速く計算するのを促進するために、最適化コンポーネント４０８は、スライディング・ウィンドウ手法を採用することができ、この場合、最適化コンポーネント４０８は固定数の時間ステップを今後に考慮する。それぞれのデッドラインがスライディング・ウィンドウを超える要求は、もっと小さな要求に分解することができる。このような場合、最適化コンポーネント４０８は、その元のデマンド(original demand)および既に割り当てられているフロー全体に基づいて、もっと小さい要求のデマンド(request's demand)を更新することができる。

[0052] 最適化コンポーネント４０８の設計および動作に関する更なる詳細についてこれより説明する。説明の目的のために、プロセスは段階的に得られ、オフライン・ケースから開始し、オンライン・ケースに進み、次いでβパラメータによるトラフィック平滑化、容量制約の猶予(grace)または違反(violation)、有界範囲(bounded horizon)による要求分割、および異なる優先順位の処理というような、追加の機能を追加する。更に、本明細書において示される例はネットワークにおける計算トラフィック・フローのスケジュールに言及するが、本明細書において説明する混合パッキングおよびカバリング手法は、他のシナリオでも使用できることは理解されよう。例えば、解を出力するためにデーターを受けるときの不等式の動的変更が考えられる。加えて、混合パッキングおよびカバリング・アルゴリズムの並列化も一般に考えられ、ネットワーク・トラフィック・フローに対して長期スケジュールを計算するためにそうすることは、混合パッキングおよびカバリング・アルゴリズムを並列化することが望ましいと考えられる１つのシナリオ例に過ぎない。更にまた、ネットワークにおいて高優先順位のトラフィックを推定し、目標を満たすためにネットワーク・リンクの残りの帯域幅を割り当てる一般的な手法も考えられる。このような場合、リンクの帯域幅の割り当ては、実際の高優先順位のトラフィックが推定値と異なるときには、目標に対して起こる混乱を最小限に抑えつつ、動的に更新することができる。

[0053] 先に示したように、Ｇ＝（Ｖ，Ｅ）であり、ここで、｜Ｖ｜＝ｎおよび｜Ｅ｜＝ｍであり、負でないエッジ容量ｃ：Ｅ→Ｒ_＋である。長期要求は、タプル（ａ_ｉ、ｂ _ｉ、ｄ_ｉ、Ｄ_ｉ、ｓ_ｉ、ｔ_ｉ、Ｐ_ｉ）によって定めることができる。加えて、別段指定されなければ、要求のそれぞれのデッドラインに上限を設ける絶対的なサイズＴ（大きくてもよい）があると仮定することができる。例えば、Ｔ≧ｄ_ｉ∀１≦ｉ≦ｋである。

[0054] オフライン・ケースにおける最適化コンポーネント４０８についてこれより説明するが、最適化コンポーネント４０８は最初から全ての要求を認識していると仮定する。例えば、全ての要求１＜ｉ≦ｋに対してａ_ｉ≡０である。グラフＧおよびｋ個の要求全てを仮定して、容量の制約を尊重しつつ各要求のデマンドの少なくともａの端数を導くことができるように、最も大きなα、０≦α≦１を突き止めることが望ましいという可能性がある。これを「同時多品種流通」問題と呼び、線形パッキングおよびカバリング制約のシステムを断片的に解く問題の特殊なケースである。αが与えられた場合、線形問題によってオフライン・ケース（ユーティリティなし）を解くために必要とされる線形不等式のシステムは以下のようになる。

以上で説明した例では、最適化プロセスは最良のαを繰り返し検索する（例えば、ライン検索方法を使用する）。各繰り返しにおいて、線形プログラムが実現可能か否か確認する。実現可能である場合、実現可能な解を出力することができる。この実現可能性問題を解くプロセス例を以下に紹介する。

初期化

[0055] 以上で言及した初期化およびｙ_ｅ、ｔおよびｚ_ｉの更新は、以下の式が成り立つように行われる。

[0056] このプロセスの各ステップにおいて、１つの（慎重に選択された）フロー変数ｆ_ｉ ^＊ _、ｐ ^＊ _、ｔ ^＊を増加させる。この変数は、「最悪」ピッキングの増大（例えば、ネットワーク１０２において、容量が最も違反(being violated)に近いリンク）が、「最悪」カバリング制約（例えば、そのデマンド制約から最も離れている要求）の増大よりも小さくなるように選択することができる。パッキングおよびカバリング問題に関する既存のプロセスは、最大および最小演算子の平滑近似の使用によって、この要件を満たすことができる。近似要件は不等式（＊）において実証され、ｙ_ｅ、ｔを、パッキング制約を表す内部変数と見なすことができ、一方ｚ_ｉは、カバリング制約を表す内部変数と見なすことができる。

[0057] 既存のパッキングおよびカバリング・アルゴリズムの出力は、カバリング制約が満たされる（αが実現可能であると仮定する）ことを保証する。（＊）は、最大および最小の平滑近似の微分(derivative)の比率であるので（制約の値の変化の比率ではなく）、出力は小さな乗算係数だけパッキング制約を違反する。この係数は、精度パラメータεを０に減少させるに連れて、単調に１に減少する。このような保証は、以下の定理において、公式が作られる(made formal)。
定理１：線形プログラムが実現可能である場合、あらゆる０＜ε≦１／２に対して、プロセスの出力は以下の式を満たす。

定理２：あらゆる０＜ε≦１／２に対して、実現可能性チェック・プロセスは、せいぜい、

回の繰り返しの後終了する。
[0058] εの選択は、プロセスの精度（パッキング制約がどのくらい逸脱するか）と実行時間との間に必要とされるトレードオフを反映する。容量制約における小さな違反は、βパラメータによるトラフィック平滑化の概念のときに受入可能であってもよい。これは、違反とは、容量ｃ_ｅの予め指定された端数だけが超えられるのであって、容量全体ではないからである。

[0059] 確認できるように、αの最大化は、公正目的(fairness objective)に対応し、各要求のデマンドからのαの端数がそのデッドラインによって導かれることを保証する。これだけでは不十分な場合もある。何故なら、最良のαを達成する解がネットワークの部分を利用できず、それでもより多くのフローが導かれる可能性があるからである。したがって、追加のユーティリティ関数、例えば、平均、

を使用してもよい。これは、元の公正目的の最適解全てに沿って最大化される必要がある（例えば、前述の「最悪の」αの最大化）。
[0060] 以下の形式の任意のユーティリティを導入することができる。

ここで、ｕ_{ｉ、ｐ、ｔ}≧０である。具体的には、前述の平均αユーティリティは、

を選択することによって得ることができる。尚、「ソフト・デッドライン」をモデル化するために、

を使用できることが認められる。例えば、要求ｉを固定することができ、ユーティリティ係数ｕ_{ｉ、ｐ、ｔ}＝ｈ_ｉ（ｔ）を、ｔ＞Ｄ（Ｄはある時間ステップ）に対して指数的に速く減衰する関数ｈ_ｉ（ｔ）について考慮することができる。この関数は、Ｄが要求ｉに対してソフト・デッドラインであるという事実をモデル化する。

[0061] ｇの最大値のある予測(guess)Ｕに対して、先に参照した線形プログラムに、以下の制約を追加することができる。

従来のパッキングおよびカバリング・アルゴリズムは任意のパッキングおよびカバリング制約に作用するので、以上の線形カバリング制約を追加することが可能である。この制約を仮定すると、以上で参照したプロセスに以下の変更を行うことができる。内部ｒ変数を追加する。ｒを１に初期化する。ｆ_ｉ ^＊ _、ｐ ^＊ _、ｔ ^＊を増大させるとき、ｒを以下のように更新する。

条件（＊）を以下のように変更する。

新たな制約が最初に満たされるとき、即ち、

であるとき、内部変数ｒは（＊）から削除され、もはや更新されない。このプロセスの停止条件は、全てのカバリング制約（要求ｉおよび追加のユーティリティ制約

毎に１つずつ）が満たされることである。γが以下の式によって選択される。

変数ｒは、以下の式が成り立つように、以上のように初期化される。

[0062] 最適化コンポーネント４０８のオンライン・ケースにおける動作では、最適化コンポーネント４０８は要求を受け、要求の受領に応答して長期スケジュールを適応させる。これより、この動作について説明する。最適化コンポーネント４０８は時点ｔ＝０、例えば、α_ｉ≡０において全ての要求を認識しているというオフライン・ケースにおいて行われた仮定は、不合理である可能性がある。オンラインで使用されるときに最適化コンポーネント４０８によって採用することができるプロセス例は、次の３つの主要なプロパティを有する。要求のオンライン処理を可能にする。新たな要求が届く毎に解に対して増分変化を行う。約束されたα値を累進的に更新する。

[0063] このようなプロセスに関して、時間をτによってインデックス化することができる。時間ステップτが開始するとき、最適化コンポーネント４０８によって採用されたプロセスは、認識時点がτである、例えば、α_ｉ＝τの要求ｉを認識する。時点τにおいて関連がある要求の集合体をＲ（τ）＝｛ｉ：α_ｉ≦τ，ｄ_ｉ≧τ｝によって示すことができる。このようなプロセスの導出について、ここでは段階毎に説明する。

[0064] 第１の設計を紹介する。ここでは、プロセスは性質上増分的であり、値を欲張って(greedily)選択する。線形プログラムＬＰ（τ）によって時点τにおいて解くためにオンライン・プロセスが利用する不等式のシステムは、以下のように表される。

は、要求ｉ∈Ｒ（τ）に対して時点τより前にプロセスによって既に導かれた全フローとして、そして、α_ｉ、プロセスがスケジューリングした要求ｉのデマンドの約束された端数(promised fraction of request i's demand)によって定めることができる。尚、Ｆ_{ｉ、τ−１}は、時間ステップτで動作するときは定数であることが認められる。

[0065] 時点τにおけるオンライン・プロセスは、直前の時間ステップからの解をその開始点として使用する。その後、α_ｉに対する値が与えられると、プロセスはオフライン・アルゴリズムを実行して、所与のα_ｉ値に対して実現可能な解があるか否か判定することができる。プロセスはα_ｉ個の値を決定することができる。何故なら、新しくない要求ｉ、例えば、α_ｉ＜τ、は、直前の時間ステップから約束されたα_ｉ個の値を既に有するからである。新たに認識された要求ｉ、例えば、α_ｉ＝τは、初期状態ではα_ｉ＝０で有すると設定することができる。プロセスは、「注水」プロセスを導くことができ、ＬＰ（τ）が実現可能である限り、最も低いαスコアを増大させる。

[0066] オフライン・プロセスに関して、以下の変更を行うことができる。条件（＊）を以下のように変更する。

ｆ_ｉ ^＊ _、ｐ ^＊ _、ｔ ^＊を増大させるとき、変数ｚ_ｉ ^＊を以下のように更新する。

γは、

にしたがって変化させられる。ｉ^＊は、

のとき、Ｒから削除される。このアルゴリズムの停止条件は、全ての「新たな」カバリング制約が満たされることである。式（１）および式（２）と同様、ｙ_ｅ、ｔおよびｚ_ｉは、以下の定義を保持するために維持される。

[0067] 以上のオンライン増分解に伴って存在する問題は、本質的にαの値を欲張って選択することであり、シーケンスα_０、α_１、．．．に広いばらつきを生ずるおそれがあり、あるαは非常に小さな値を有する場合もある。

[0068] 経時的な公正さを維持するために、トラフィック平滑化の概念を導入することができる。直観的に、これは、増分オンライン・プロセスが使用できる容量を限定し、今後の要求のためにある容量を空にしておくことによって行うことができる。定式的には、β_{ｅ、ｔ、τ}が、時間ステップτにおいて実行しているときに、オンライン増分プロセスによって使用することができる、未来時点ｔにおけるエッジｅの容量の端数を示すことができる。これは、ＬＰ（τ）の容量制約を以下のように変化させる。

エッジｅ∈Ｅおよび時点ｔを仮定すると、以下の関数はτにおいて非減少（non-decreasing)である。

β_{ｅ、ｔ、τ}を１に設定することができる。何故なら、オンライン・プロセスが時間ステップτ＝ｔに達したとき、今後の使用のために空の容量を取っておく必要がないので、エッジの容量全体を使用することができるからである。例えば、ある選択例では、ある定数ｃに対して、β_{ｅ、ｔ、τ}＝ｅｘｐ（−（ｔ−τ）／ｃ）となる。

[0069] 以上のことに基づいて、式（１）に対する以下の変更を実施することができる。ｙ_ｅ、ｔ ^＊に対する規則を更新することができる。ここで、

条件（＊）は、以下のように変化する。

ｙ_ｅ，ｔは、初期化され、以下の定義を維持するように更新される。

[0070] オンライン・ケースでは、時点τにおいて動作するとき、トラフィック平滑化手法によって得られる結果を改良することができる。最適化コンポーネント４０８は、オンライン・プロセスを採用するとき、各時間ステップτにおいて満水(water filling)を適用するので、α値の一部を改良できることもなくはない。各時間ステップτにおいて、オンライン・プロセス（トラフィック平滑化が終了している）後に、同じアルゴリズム手法にユーティリティ制約を適用することができる。ＬＰ’（τ）は、オンライン・プロセスが時点τにおいてユーティリティ

によって解く必要がある不等式のシステムを示すことができる。

は、要求ｉ∈Ｒ（τ）に対して時点τより前にプロセスによって既に導かれたフローの全ユーティリティとして定めることができる。尚、Ｕ_{ｉ，τ−１}は、時間ステップτにおいて動作するときの定数であることが認められる。

[0071] 第２の制約は、要求ｉの全フローがその全デマンドＤ_ｉを超えてはならないことを規定する（これはパッキング制約である）。第３の制約は、全ユーティリティが少なくともある所与の値Ｆであることを規定する（これはカバリング制約である）。尚、第２の制約は、ＬＰおよびＬＰ（τ）では必要とされないが、ここではＬＰ’（τ）によって必要とされることが認められる。

[0072] このような制約を考慮するとき、式（１）に対する以下の変更を最適化コンポーネント４０８に組み込むことができ、内部変数ｓ_ｉを追加することができる。ここで、∀ｉ∈Ｒ（τ）。ｆ_ｉ ^＊ _，ｐ ^＊ _，ｔ ^＊を増大させるとき、ｓ_ｉ ^＊が以下のように更新される。

条件（＊）は以下のように変更される。

このプロセスの停止条件は、ユーティリティ制約が満たされることであり、γは、

となるように選択される。内部変数ｙ_ｅ、ｔ、ｓ_ｉ、およびｒは、式（６）が変化しないままであり続けるように維持され、以下の式が成り立つ。

[0073] 定理１において示したように、最適化コンポーネント４０８は、せいぜい（１＋３ε）の小さな乗算係数だけ容量制約を違反する解を生成する場合がある。これは、トラフィック平滑化およびユーティリティ組み込みの双方において起こり得る。しかしながら、これは問題にはならない。何故なら、時点τおよびエッジの容量ｃ_ｅにおいてオンライン・プロセスによってスケジューリングされた時点ｔにおけるエッジｅ上のフローのβ_{ｅ、ｔ、τ}・Ｃ_ｅ単位を超えるからである。この手法によって、最終出力において容量を実際には全く違反せずに最適化コンポーネント４０８によって生成される小さな容量違反の容認が可能になり、更に高いα値が得られる結果となる。

[0074] 尚、オンライン・ケースは理論的な動作保証(performance guarantee)がないことを確認することができるが、不等式のしかるべきシステムが実現可能であるとき、最適化コンポーネント４０８によって使用されるプロセスは抜け出せないことはないことは証明することができる。即ち、常に増加することができる変数ｆ_ｉ ^＊ _，ｐ ^＊ _，ｔ ^＊があり、最悪のパッキング制約の平滑化の微分(derivative)と、最悪のパッキング制約の平滑化の微分(derivative)との比率が１を上限とされていることを含意する。これは、任意の現在の解

に対して成り立つ。これは、以下の定理によって要約される。
定理３：任意の

に対して、ＬＰ、ＬＰ（τ）、およびＬＰ’（τ）が実現可能である場合、常に、それぞれの条件（＊）が成り立つようなｉ^＊，ｐ^＊，ｔ^＊がある。
[0075] 先に参照したように、高優先順位の要求（例えば、その場限りの要求）は満たされることが望ましい。全ての高優先順位の要求が小さなチャンクに分解され、各々、ａ_ｉ＝ｂ_ｉ＝ｄ_ｉを有する、例えば、各高優先順位要求が正確に１回の時間ステップに及ぶと仮定することができる。先に参照したプロセスは、高優先順位の要求に必要とされる、時点ｔにおけるエッジｅの容量ｃ_ｅの端数の以前の推定を有する。この端数をＸ_ｅ，ｔで示すことができる。これは、以前に述べたプロセスの以下の改変を招く。即ち、ｃ_ｅが（１−Ｘ_ｅ，ｔ）・ｃ_ｅと置き換えられる。Ｘは推定であるので、一旦時間ステップｔに達し、プロセスが実際の高優先順位要求を認識してから、エッジｅの容量のＸ_ｅ，ｔ端数よりも多くが必要とされることが明らかになるということもあり得る。この場合、プロセスは、エッジｅにおいてある予めスケジューリングされているフローを削減するように構成することができ、これは、最適化コンポーネント４０８によって与えられる約束保証α_ｉに対する影響を最小限に抑えつつ、エッジｅにおいて予めスケジューリングされているフローを訂正する小さな線形プログラムを定式化することによって遂行することができる。

[0076] 他の実施形態例では、実行時間を短縮するために、スライディング・ウィンドウ手法の使用を考慮することが望まれる場合もある。ウィンドウ・サイズＷを仮定し、オンライン・プロセスが時間ステップτにある場合、その先にはＷ個の時間ステップしか見えない。この手法に伴う可能性がある問題は、ｄ_ｉ−ａ_ｉ＞Ｗとなる要求ｉがあり得ることである。例えば、プロセスが要求ｉを認識する時点において、現在のウィンドウの後にそれが終了する。

[0077] この可能性がある問題に対する解決策は、この要求をもっと小さい要求に分解することである。具体的には、以上のように、一旦プロセスが時点τにおいて要求ｉを認識したなら、そのデッドラインを、スライディング・ウィンドウの現在の終了時点、τ＋Ｗであると見なす。加えて、そのデマンドが、その元のデマンドの内現在のスライディング・ウィンドウに収まる割合に設定される。更に特定すれば、最適化コンポーネント４０８のオンライン・プロセスが時点τにあるとき以下の式によってデマンドを決定することができる。

それ以外の場合
任意の後続の時間ステップにおいて、スケジューリングされた要求ｉのフローの合計をＤｉから減算することができる。

[0078] 最適化コンポーネント４０８は比較的厳しい時間幅で動作しなければならないことを確認することができる。したがって、以上で説明したプロセスは、その実行の促進を容易にするために変更することができる。例えば、最短経路問題(shortest path problem)を分解することができる。（＊）を満たす（ｉ、ｔ、ｐ）タプルを発見することは、拡張グラフ上において全対最短経路プロセス(all-pairs shortest path process)を実行することと実質的に同様であり、拡張グラフはあらゆる時間インスタンス(time instance)において元のネットワークのコピーを含む。しかしながら、このように行うのは、スケジューラー・コンポーネント１１８によって考慮されるとよい大きな問題のインスタンスに鑑みると、負担が大きすぎるおそれがある。つまり、先に暗示したように、ネットワーク・グラフ４０２に制約を設けることができる。例えば、送信元−宛先対毎に、経路を長さでソートしたリストを、グラフのコピー毎に保持することができる（経路の長さは、そのエッジの長さの和であり、エッジの長さは、

によって与えられる）。全てのコピー間で最小長経路を求めることによって、送信元／宛先対毎に最短経路を得ることができる。このような分解の利点は、遙かに小さなグラフ上において最短経路を検索できることである。

[0079] 以上のことを考慮すると、プロセスの任意の繰り返しにおいて、最後の更新に対応する時間インスタンスに対してのみ、最短経路を計算できることを観察することができる（例えば、このような時間インスタンスがｔで示される場合）。更に、最短経路（時点ｔに対応する）は、現在の最短経路が、フローが増強された経路との接合エッジを有するユーザーに対してだけ計算すれば済む。この結果、各繰り返しにおける更新が少なくなり、プロセスが一層効率的になる。

[0080] 更に、以上で説明したプロセスを並列化することができる。時間次元において競争(contention)がなく、更に一度に１つのスレッドだけに要求が指定される限り、フロー変数ｆ_{ｉ，ｐ，ｔ}を増分することと、対応する内部変数ｙ_ｅ，ｔおよびｚ_ｉを更新することとを並列して行うことができる。これらの制約に従うために、全時間を時間範囲に分割することができ、各時間範囲が異なるスレッドに指定される。各範囲における「負荷」（要求数）がほぼ等しくなるように、特定の時間範囲を選択することができる。並列化は、各要求が正確に１つの時間範囲内で「生きている」ときは単純である。しかしながら、要求が複数の時間範囲に跨がる場合もある。この課題に取り組むために、要求を特定の時間範囲に、その時間範囲における要求の相対的質量(relative mass)に等しい確率で、指定することができる。このような指定により、以上で説明した制約が実際に行使されることが保証される。散乱フェーズ(scatter phase)では、各スレッドが所与の繰り返し回数だけ実行する（例えば、１０^４に設定することができる）。次いで、続く収集フェーズ(gather phase)において、全ての変数の値を更新する。あるカバリング制約が満たされないままであり、条件＊に基づくｆ_{ｉ，ｐ，ｔ}に対する実現可能な編集は可能なままであるが、最適化コンポーネント４０８は以上の散乱フェーズおよび収集フェーズを繰り返す。尚、複数の時間範囲に跨がる要求を異なる散乱フェーズにおける異なるスレッドに指定できることを注記しておく。実行の終了に向かって、満たされない要求の数が小さくなり、プロセスは一スレッド実行に切り替えることができる（例えば、並列化のオーバーヘッドが有意になる）。

[0081] 以上のことの少なくとも一部を要約すると、最適化コンポーネント４０８によって使用することができるアルゴリズム例を混合パッキングおよびカバリング・アルゴリズムとして分類することができる。このプロセスは、パッキング制約においてオーバーシュート違反に制限ができるように、小さいが確率が高い安全な変更を変数に対して行うことによって、解を識別する。新たな制約が現われたとき（例えば、次の時間ステップにおける新たな転送、またはネットワーク条件の変化）、本プロセスは「古い」収束された状態を使用することができる（例えば、問題を一度に解決する必要はなく、以前に収束された状態から開始することができる）。このプロセスは、要求元に約束することを可能とし、約束は、新たな到達、高い優先順位（その場限りの）要求、およびネットワーク条件の変化があっても、転送要求が満たされることを保証する。これは、今後のネットワーク・リソースの内特定の量を別に取っておくことによって遂行することができ、次の時間ステップにおいて（現在の時点から）、リソースを全体的に割り当てることができ、一方今後の時間ステップでは、割り当てずに残すリソースの量を増やすことができる。更に、このようなプロセスは、実用的な実施のために並列化することができる。

[0082] 図６を参照すると、ネットワーク１０２の少なくとも１つの計算デバイスに保持されたデーターの所有者に露出することができるグラフィカル・ユーザー・インターフェース例６００が示されている。グラフィカル・ユーザー・インターフェース６００は、送信元計算デバイスから受信先計算デバイスに転送されるデーターの識別を受けるように構成されたデーター・フィールド６０２を含む。例えば、データー・フィールド６０２において参照されたデーターの識別に基づいて、送信元計算デバイスから受信先計算デバイスに転送されることが要求されているデーターのボリュームを確認することができる。

[0083] 加えて、グラフィカル・ユーザー・インターフェース６００は、ネットワーク１０２において受信先計算デバイスを識別する受信先ＩＤフィールド６０４を含む。グラフィカル・ユーザー・インターフェース６００は、任意に、開始フィールド６０６を含んでもよい。開始フィールド６０６は、受信先ＩＤフィールド６０４において識別された受信先計算デバイスへのデーターの転送を開始することができる時刻の識別を受けるように構成される。開始フィールド６０６がグラフィカル・ユーザー・インターフェース６００から省略される場合、または開始時刻が指定されない場合、データーの転送は直ちに開始できると仮定することができる。また、グラフィカル・ユーザー・インターフェース６００は、デッドライン・フィールド６０８も含む。デッドライン・フィールド６０８は、受信先ＩＤフィールド６０４において識別された受信先計算デバイスへの送信元計算デバイスからのデーターの転送が完了するときの指示を受けることができる。フィールド６０２〜６０８において説明したデーターに基づいて、価格設定フィールド６１０に価格設定情報を提示することができる。価格設定情報は、例えば、デッドライン・フィールド６０８において説明したデッドラインが変化するとき、データー・フィールド６０２におけるデーターの量が変化するとき等に、変化することができる。したがって、グラフィカル・ユーザー・インターフェース６００は、データーの転送をデッドラインよりも前に完了させなければならないときに、絶対的なデッドラインの指定を容易にすることを確認することができる。スケジューラー・コンポーネント１１８は、要求を受け入れるかまたは拒否するか決定するときにデッドラインを考慮することができ、このデッドラインに基づいて長期スケジュール１２４および短期スケジュール１２６を計算することができる。

[0084] 図７〜図９は、ネットワークにおけるデーター転送のスケジューリングに関する方法例を示す。これらの方法は、順序通りに実行される一連のアクトであるとして示され説明されるが、これらの方法は実行の順序(order of the sequence)によって限定されないことは理解され、認められよう。例えば、一部のアクトは、ここで説明するのとは異なる順序で行うことができる。加えて、１つのアクトが他のアクトと同時に行うこともできる。更に、場合によっては、ここで説明する方法を実現するために全てのアクトが必要でないこともある。

[0085] 更に、本明細書において説明するアクトは、１つ以上のプロセッサーによって実現され、および／または１つまたは複数のコンピューター読み取り可能媒体に格納することができるコンピューター実行可能命令であってもよい。コンピューター実行可能命令は、ルーチン、サブルーチン、プログラム、実行のスレッド等を含むことができる。更にまた、これらの方法のアクトの結果は、コンピューター読み取り可能媒体に格納すること、ディスプレイ・デバイス上に表示すること等が可能である。

[0086] これより図７を参照すると、長期スケジュールの計算を容易にする方法例７００が示されている。方法７００は７０２において開始し、７０４において、ネットワークにおける第１計算デバイスからネットワークにおける第２計算デバイスにデーターを転送する要求を受ける。先に示したように、要求は、第２計算デバイスを識別する第１データー、要求にしたがって第１計算デバイスから第２計算デバイスに転送されるデーターのボリュームを識別する第２データー、およびデッドラインを識別する第３データーを含み、第１計算デバイスから第２計算デバイスへのデーターの転送は、デッドラインよりも前に完了されなければならない。

[0087] 要求を受けたことに応答して、そして少なくとも部分的にこの要求に基づいて、７０６において、ネットワークにおけるデーター転送に対する長期スケジュールを生成する。先に示したように、長期スケジュールを計算するために最適化プロセスが使用される。長期スケジュールは、複数の今後の時間単位をカバーし、デッドラインよりも前における第１計算デバイスから第２計算デバイスへのデーターのボリュームの転送の完了を促進するために生成される。更に、長期スケジュールは、複数の今後の時間単位における少なくとも１つの今後の時間単位に対して、データーが第１計算デバイスから第２計算デバイスに転送されるネットワークにおける経路を識別する。

[0088] ７０８において、長期スケジュールに基づいて、ネットワークにおけるデーター転送に対して短期スケジュールを生成する。短期スケジュールは、デッドラインよりも前における第１計算デバイスから第２計算デバイスへのデーターの転送の完了を促進するために生成される。短期スケジュールは、ネットワークにおけるネットワーク・インフラストラクチャー・デバイスに対するルーティング・テーブルを含む。ルーティング・テーブルは、ネットワーク・インフラストラクチャー・デバイスによって受信されたデーターが転送される少なくとも１つのデバイスを識別する。７１０において、ルーティング・テーブルをネットワーク・インフラストラクチャー・デバイスに送信し、方法７００は７１２において完了する。

[0089] これより図８を参照すると、長期スケジュールの生成を容易にする方法例８００が示されている。方法８００は８０２において開始し、８０４において、ネットワークのマップを受信する。先に示したように、ネットワークのマップは、ＷＡＮにおけるデバイスを表す複数のノードと、ネットワークにおけるデバイス間のネットワーク・リンクを表す複数のエッジとを含む。８０６において、ネットワークのマップに基づいて、ネットワーク・グラフを構築する。ネットワーク・グラフは、ネットワークのマップの複数のインスタンスを含み、長期スケジュールによってカバーされる時間単位毎に、ネットワークのマップの１つのインスタンスがある。８０８において、データー転送に対する経路制約を受ける。このような経路制約は、送信元計算デバイスから受信先計算デバイスに転送されるデーターが進むことができる経路に制約を設けることができる。

[0090] ８１０において、保留中のデーター転送要求についての情報を受信する。このような情報は、情報の中でもとりわけ、要求毎に転送されるために残っているそれぞれのデーター・ボリューム、要求のそれぞれのデッドラインを含むことができる。８１２において、ネットワーク・グラフ、経路制約、および８１０において受信した情報に基づいて、ネットワーク・グラフに対して混合パッキングおよびカバリング・アルゴリズムを並列に実行する。尚、長期スケジュールを計算するためには、他のタイプのアルゴリズムも考えられることが考えられることは理解されよう。例えば、長期スケジュールの計算に関連して線形プログラムを解決することができる。方法８００は８１４において完了する。

[0091] これより図９に移ると、ネットワークを介したデーター転送についての価格設定情報を露出するのを容易にする方法例９００が示されている。この方法は９０２において開始し、９０４において、ネットワークを介したデーター転送に対する長期スケジュールを受信する。９０６において、長期スケジュールに基づいて、データー転送に対する価格設定スケジュールを生成する。この価格設定スケジュールは、経時的にネットワークにおけるデーター転送のデマンドを平滑化することにより、ネットワークのハードウェア・リソースの利用効率を高めるように構成することができる。９０８において、ＷＡＮ上のデーター転送要求を受ける。この要求は、転送するデーターの量、および転送が完了されなければならないデッドラインを含む。９１０において、価格設定スケジュールおよび受領した要求に基づいて、価格設定情報を要求元に露出する。次いで、データー転送の要求元は、価格を受け入れるか、または価格設定情報に基づいて要求を変更することができる。方法９００は９１２において完了する。

[0092] これより図１０を参照すると、本明細書において開示したシステムおよび方法にしたがって使用することができる計算デバイス例１０００の上位図が示されている。例えば、計算デバイス１０００は、ネットワークにおけるデーター転送に対して長期スケジュールの計算をサポートするシステムにおいて使用することができる。他の例として、計算デバイス１０００は、ネットワーク１０２における送信元計算デバイスまたは受信先計算デバイスであることも可能である。計算デバイス１０００は、メモリー１００４に格納されている命令を実行する少なくとも１つのプロセッサー１００２を含む。命令は、例えば、以上で説明した１つ以上のコンポーネントによって実行されると説明された機能を実現するための命令、または以上で説明した方法の内１つ以上を実現するための命令であってもよい。プロセッサー１００２は、システム・バス１００６を介してメモリー１００４にアクセスすることができる。実行可能命令を格納することに加えて、メモリー１００４は、ルーティング・テーブル、長期スケジュール、短期スケジュール等も格納することができる。

[0093] 加えて、計算デバイス１０００は、システム・バス１００６を介してプロセッサー１００２によってアクセス可能なデーター・ストア１００８も含む。データー・ストア１００８は、実行可能命令、データー転送スケジュール等を含むことができる。また、計算デバイス１０００は、外部デバイスが計算デバイス１０００と通信することを可能にする入力インターフェース１０１０も含む。例えば、入力インターフェース１０１０は、外部コンピューター・デバイスから、ユーザーから等で命令を受けるために使用することができる。また、計算デバイス１０００は出力インターフェース１０１２も含む。出力インターフェース１０１２は、計算デバイス１０００を１つ以上の外部デバイスとインターフェースする。例えば、計算デバイス１０００は、出力インターフェース１０１２を介して、テキスト、画像等を表示することができる。

[0094] 尚、入力インターフェース１０１０および出力インターフェース１０１２を介して計算デバイス１０００と通信する外部デバイスは、ユーザーが対話処理することができる実質的にあらゆるタイプのユーザー・インターフェースを設ける環境に含むことができると考えられる。ユーザー・インターフェース・タイプの例には、グラフィカル・ユーザー・インターフェース、自然ユーザー・インターフェース等が含まれる。例えば、グラフィカル・ユーザー・インターフェースは、キーボード、マウス、リモコン等のような入力デバイス（１つまたは複数）を使用するユーザーから入力を受け入れ、ディスプレイのような出力デバイス上に出力を供給することができる。更に、自然ユーザー・インターフェースは、ユーザーが、キーボード、マウス、リモコン等のような入力デバイスによって強いられる制約を受けないように、計算デバイス１０００と対話処理することを可能にするのでもよい。逆に、自然ユーザー・インターフェースは、音声認識、タッチおよびスタイラス認識、画面上および画面近く双方におけるジェスチャー認識、エア・ジェスチャー、頭部および眼球追跡、声および発話(voice and speech)、視覚、接触、ジェスチャー、機械インテリジェンス等に頼るのでもよい。

[0095] 加えて、１つのシステムとして例示したが、計算デバイス１０００は分散型システムであってもよいことは理解されよう。つまり、例えば、様々なデバイスがネットワーク接続を介して通信することができ、計算デバイス１０００によって実行されると説明したタスクを、集合的に実行するのでもよい。

[0096] 本明細書において説明した種々の機能は、ハードウェア、ソフトウェア、またはこれらの任意の組み合わせで実現することができる。ソフトウェアで実現する場合、機能は、コンピューター読み取り可能媒体上の１つ以上の命令またはコードとして格納することまたは送信することができる。コンピューター読み取り可能媒体は、コンピューター読み取り可能記憶媒体を含む。コンピューター読み取り可能記憶媒体は、コンピューターによってアクセスすることができる任意の入手可能な記憶媒体とすることができる。一例として、そして限定ではなく、このようなコンピューター読み取り可能記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいは命令またはデーター構造の形態で所望のプログラム・コードを搬送または格納するために使用することができ、コンピューターによってアクセスすることができる任意の他の媒体を含むことができる。ディスク(disk and disc)は、本明細書において使用する場合、コンパクト・ディスク（ＣＤ）、レーザ・ディスク、光ディスク、ディジタル・バーサタイル・ディスク（ＤＶＤ）、フロッピー・ディスク、ブルーレイ・ディスク（ＢＤ）を含み、ディスク(disk)は通常データーを磁気的に再生し、ディスク(disc)は通常レーザを使用してデーターを光学的に再生する。更に、伝搬信号は、コンピューター読み取り可能記憶媒体の範囲には含まれない。また、コンピューター読み取り可能媒体は、１つの場所から他の場所へのコンピューター・プログラムの転送を容易にする任意の媒体を含む通信媒体も含む。例えば、接続は通信媒体となることができる。例えば、ソフトウェアがウェブサイト、サーバー、または他の離れた送信元から、同軸ケーブル、光ファイバ・ケーブル、撚り線対、ディジタル加入者回線（ＤＳＬ）、あるいは赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバ・ケーブル、撚り線対、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、通信媒体の定義に含まれる。以上のものの組み合わせも、コンピューター読み取り可能媒体の範囲に含まれてしかるべきである。

[0097] あるいは、または加えて、本明細書において説明した機能は、少なくとも部分的に、１つ以上のハードウェア・ロジック・コンポーネントによって実行することができる。例えば、そして限定ではなく、使用することができる実証的なタイプのハードウェア・ロジック・コンポーネントには、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定プログラム集積回路（ＡＳＩＣ）、特定プログラム標準的製品（ＡＳＳＰ）、システム・オン・チップ・システム（ＳＯＣ）、複合プログラマブル・ロジック・デバイス（ＣＰＬＤ）等が含まれる。

[0098] 以上で説明したことには、１つ以上の実施形態の例が含まれる。勿論、以上のデバイスまたは方法の着想可能なあらゆる変更(modification)および変形(alteration)を、先に述べた態様を説明する目的で記載することは不可能であるが、種々の態様には多くの更に他の変更および置換が可能であることを、当業者は認めることができよう。したがって、説明した態様は、添付する請求項の主旨および範囲に該当する、このような変形、変更、および変種(variation)を全て包含することを意図している。更に、「含む」(includes)という用語が詳細な説明または特許請求の範囲において使用される限りにおいて、このような用語は、「備える」(comprising)という用語が請求項において移行性単語として採用されるときに「備える」が解釈されるときと同様に、包含的であることを意図している。

Claims (9)

1. 方法であって、
   ネットワークにおける第１計算デバイスから前記ネットワークにおける第２計算デバイスにデーターを転送する要求を受けるステップであって、前記要求が、
   前記第２計算デバイスの識別と、
   前記要求にしたがって前記第１計算デバイスから前記第２計算デバイスに転送されるデーターのボリュームの識別と、
   時刻を識別するデッドラインであって、前記第１計算デバイスから前記第２計算デバイスへのデーターの転送が、前記デッドラインにおいて識別された前記時刻よりも前に完了される、デッドラインと、
   を含む、ステップと、
   前記要求を受けたことに応答して、かつ前記要求に基づいて、複数の時間単位をカバーする長期スケジュールを計算するステップであって、前記長期スケジュールが、前記第１計算デバイスから前記第２計算デバイスへのデーターの転送の前記デッドラインにおいて識別された前記時刻よりも前における完了を促進するために生成され、前記長期スケジュールが、前記複数の時間単位における１つの時間単位に対して、前記データーが前記第１計算デバイスから前記第２計算デバイスに転送されるネットワークにおける少なくとも１つの経路を識別する、ステップと、
   前記長期スケジュールに基づいて、現在の時間単位の直後の時間単位をカバーする短期スケジュールを計算するステップであって、前記短期スケジュールが、前記長期スケジュールよりも少ない時間単位を含み、前記短期スケジュールが、前記第１計算デバイスから前記第２計算デバイスへの前記ボリュームのデーターの転送の前記デッドラインにおいて識別された時刻よりも前における完了を促進するために計算され、前記短期スケジュールが、前記ネットワークにおけるネットワーク・インフラストラクチャー・デバイスに対するルーティング・テーブルを含み、前記ルーティング・テーブルが、前記ネットワーク・インフラストラクチャー・デバイスによって受信されたデーターが転送される少なくとも１つのデバイスを識別する、ステップと、
   前記ルーティング・テーブルを前記ネットワーク・インフラストラクチャー・デバイスに送信するステップであって、前記ネットワーク・インフラストラクチャー・デバイスが、前記ルーティング・テーブルにしたがって前記少なくとも１つのデバイスに対し前記データーを転送する、ステップと、
   を含む、方法。
2. 請求項１記載の方法であって、更に、
   前記ネットワークのマップを受信するステップであって、前記ネットワークのマップが、前記ネットワークにおけるデバイスをそれぞれ表す複数のノードを含み、前記ネットワークのマップが、更に、前記ネットワークにおけるそれぞれのデバイス間のリンクを表す複数のエッジを含む、ステップと、
   前記ネットワークのマップに基づいて、前記長期スケジュールを生成するステップと、
   を含む、方法。
3. 請求項２記載の方法であって、更に、
   前記ネットワークのマップの受信に応答して、前記複数の時間単位にわたる前記ネットワークを表すネットワーク・グラフを構築するステップであって、前記ネットワーク・グラフが、前記複数の時間単位にそれぞれ対応する前記ネットワークのマップの複数のインスタンスを含み、前記ネットワークのマップの前記複数のインスタンスが、共通のデバイスを表す前記ネットワークのマップの前記複数のインスタンスにおけるノード間のエッジを介して互いに接続され、前記長期スケジュールが前記ネットワーク・グラフに基づいて生成される、ステップを含む、方法。
4. 請求項３記載の方法であって、更に、前記第１計算デバイスと前記第２計算デバイスとの間における前記データー転送に対して、前記ネットワーク・グラフにおいて表された経路の内、前記第１計算デバイスから前記第２計算デバイスに前記データーを転送するために使用することができる経路の数を、可能な閾値数の経路に制約するステップを含み、前記長期スケジュールの生成が、前記可能な閾値数の経路に基づく、方法。
5. 請求項１記載の方法であって、更に、
   前記ネットワークにおける種々の計算デバイス間におけるそれぞれの複数のデーター転送に対する複数の要求を受けるステップであって、前記複数の要求が、それぞれの複数のデッドラインを識別し、前記それぞれの複数のデッドラインが異なる、ステップと、
   前記複数の要求に基づいて前記長期スケジュールを生成するステップであって、前記長期スケジュールが、前記ネットワークにおける前記種々の計算デバイス間における前記データー転送のそれぞれの複数のデッドラインよりも前における完了を促進するために生成される、ステップと、
   を含む、方法。
6. 請求項１記載の方法において、前記長期スケジュールが、複数のプロセッサー・コアに跨がって並列に計算される、方法。
7. 請求項１記載の方法において、前記長期スケジュールの計算が、前記長期スケジュールを計算するために混合パッキングおよびカバリング・アルゴリズムの実行を含む、方法。
8. 制御計算デバイスであって、
   少なくとも１つのプロセッサーと、
   命令を格納するメモリーと、
   を含み、前記命令が前記少なくとも１つのプロセッサーにより実行されると前記少なくとも１つのプロセッサーに動作を実行させ、該動作が、
   複数のデーター転送要求を受ける動作であって、各データー転送要求が、
   転送されるデーターのボリュームの識別と、
   それぞれの時刻を識別するデッドラインであって、各データー転送要求が、複数のネットワーク・インフラストラクチャー・デバイスを含むネットワークを介してデーターを転送する要求であり、各データー転送要求が、前記デッドラインにおいて識別された前記それぞれの時刻よりも前に完了される、デッドラインと、
   を含む、動作と、
   前記複数のデーター転送要求に基づいて長期スケジュールを計算する動作であって、前記長期スケジュールが複数の時間単位をカバーし、前記長期スケジュールが、前記複数の時間単位における各時間単位に対する前記ネットワークを介したトラフィックのフローを定める、動作と、
   前記長期スケジュールに基づいて、現在の時間単位の直後の時間単位をカバーする短期スケジュールを計算する動作であって、前記短期スケジュールが前記長期スケジュールよりも少ない時間単位を含む、動作と、
   前記短期スケジュールに基づいてそれぞれのルーティング・テーブルを前記複数のネットワーク・インフラストラクチャー・デバイスに送信させる動作であって、前記複数のネットワーク・インフラストラクチャー・デバイスが、前記ルーティング・テーブルに基づいて、データー・パケットを前記ネットワークにおいて導く、動作と、
   を含む、制御計算デバイス。
9. 請求項８記載の計算デバイスにおいて、前記長期スケジュールを計算する動作が、混合パッキングおよびカバリング・アルゴリズムを実行することを含む、計算デバイス。

Images