JP2005110261A - 多数のサービスプロバイダ間で出口トラフィック負荷平衡を制御する方法及びシステム - Google Patents

多数のサービスプロバイダ間で出口トラフィック負荷平衡を制御する方法及びシステム Download PDF

Info

Publication number
JP2005110261A
JP2005110261A JP2004279449A JP2004279449A JP2005110261A JP 2005110261 A JP2005110261 A JP 2005110261A JP 2004279449 A JP2004279449 A JP 2004279449A JP 2004279449 A JP2004279449 A JP 2004279449A JP 2005110261 A JP2005110261 A JP 2005110261A
Authority
JP
Japan
Prior art keywords
traffic
content provider
service providers
router
egress traffic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2004279449A
Other languages
English (en)
Inventor
William G Mccollom
ウィリアム・ジー・マッコロム
Valery Kanevsky
バレリー・カネブスキー
Alexander L Tudor
アレキサンダー・エル・タドール
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agilent Technologies Inc
Original Assignee
Agilent Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agilent Technologies Inc filed Critical Agilent Technologies Inc
Publication of JP2005110261A publication Critical patent/JP2005110261A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】コンテンツプロバイダが使用可能な複数のサービスプロバイダ間でコンテンツプロバイダからの出口トラフィック負荷を平衡させるシステム及び方法を提供すること。
【解決手段】複数のサービスプロバイダ間でコンテンツプロバイダ302からの出口トラフィック負荷の割り当てを管理するためのシステム及び方法。ラウンドロビン法又はランダム法等ではなくトラフィックボリュームの解析に基づいてコンテンツプロバイダにより使用される複数のサービスプロバイダ間で負荷平衡を行う。通信ネットワーク301へのアクセスを提供する複数のサービスプロバイダに接続されたコンテンツプロバイダを含むシステムが提供される。該システムは更に、複数のサービスプロバイダの各々のトラフィックボリュームに少なくとも部分的に基づいて複数のサービスプロバイダの各々にルーティングされるべきコンテンツプロバイダの出口トラフィックの最適な平衡を決定するよう動作する出口トラフィックマネージャ304を含む。
【選択図】図３

Description

本発明は、一般に、通信ネットワーク内でのデータのルーティングに関し、特に、最適な性能のために、コンテンツプロバイダが使用可能な複数のサービスプロバイダ間でコンテンツプロバイダからの出口トラフィック負荷を平衡させるシステム及び方法に関する。
通信ネットワーク（例えばコンピュータネットワーク）は一般に、互いに通信するために相互接続された多数のノード（例えばコンピュータ）を備える。ネットワークは、物理的に近い位置にある少数のノードしか含まない場合もあり（例えばサブネットワーク及び／又はローカルエリアネットワーク（LAN）を含む場合がある）、及び／又は広い領域に渡って分散する多くのノードを含む場合もある（例えば広域ネットワーク（WAN））。従来の回線交換型（circuit-switched）ネットワーク内の既存のスイッチにおけるトラフィックの増大と容量の制約により、パケットベースのネットワーク、特にインターネットプロトコル（ＩＰ）ネットワークの発展が促された。典型的なＩＰネットワークは、特にシスコシステム社（シスコ）、アセンドコミュニケーションズ社、ベイネットワーク社、及びニューブリッジ社等が製造する複数のルーティングデバイス（ルータ）を使用して、発呼その他の接続を表すデータパケットを、各パケット内の宛先アドレスに基づいて、発信元から宛先に独立してルーティングする。今日、ＩＰネットワークにおいて最も普及しているルーティング技術の例は、ＯＳＰＦ（Open Shortest Path First）プロトコル及びＢＧＰ（Border Gateway Protocol）である。本質的に、ルータは、デジタル化された情報のパケットを、ネットワーク全体でルーティングし又は導く専門のコンピュータ・ネットワーキング・デバイスである。したがって、ルータは、ネットワーク動作において複雑で重要な役割を果たしている。
相互接続された大きなコンピュータネットワークのシステムの管理は耐え難く重い負荷となり得るので、より小さなコンピュータネットワークのグループを、自律システム（ＡＳ：Autonomous System）又はルーティングドメインとして維持することができる。ルーティングドメイン内のネットワークは典型的には、従来の「ドメイン内（intradomain）」ルータによって結合される。データを交換できるノードの数を増加させるために、ドメイン間ルーティングプロトコルを行う「ドメイン間（interdomain）」ルータを使用して、様々なルーティングドメインのノードを相互接続する。ドメイン間ルーティングプロトコルの一例がＢＧＰであり、ＢＧＰは、システムのドメイン間ルータの間でルーティング及び到達可能性情報を交換することにより、ＡＳ間でルーティングを行う。ＢＧＰルータと呼ばれる、ＢＧＰプロトコルを行うよう構成されたドメイン間ルータは、ルーティングテーブルを維持し、ルーティング更新メッセージを送信し、ルーティングメトリックに基づいてルーティング決定を行う。
各ＢＧＰルータは、特定のネットワークに対して全ての実現可能な経路をリストアップした（ＢＧＰに関連する）ルーティングテーブルを維持する。ＡＳ内に存在するＢＧＰピア・ルータは、所定の状況の下でルーティング情報を交換する。一般には、ルーティングテーブルのインクリメント更新を行う。例えば、ＢＧＰルータが最初にネットワークに接続した際に、ピア・ルータはルーティングテーブルの全内容を交換することができる。その後、かかる内容に変更が生じた場合に、ルータは、ピア・ルータのテーブルを更新するために、ルーティングテーブルのうち変わった部分だけを交換する。ＢＧＰルーティングプロトコルは周知のものであり、非特許文献１,２に詳しく説明されている。
1995年、Y．Rekhter 及び T．Liによる「Request For Comments(RFC)1771」 1992年、Addison Wesley Publishing Company出版の、R．Perlmanによる「Interconnections, Bridges and Routers」、323〜329ページ。
より具体的には、ルータは一般に、プレフィクス（すなわちＩＰアドレスとマスク）、ネクストホップＩＰアドレス、及び他のルーティングパラメータを含む転送テーブルを維持する。転送テーブルは、ＢＧＰ又は他のルーティングプロトコルを介して生成される。ルータが転送テーブルを導出する元の情報は典型的には、宛先ＡＳ番号（終了ＡＳとして知られる）及び該宛先ＡＳに達するためにトラフィックが横切る中間のＡＳ番号のリストといった、ルーティングされるトラフィックの考え得る経路に関する更なる情報を含む。
ルータを使用するインターネットサービスプロバイダは、ルータのベンダが提供するツールを使用して、ルータがルーティングするデータトラフィックを解析することができる。データトラフィック解析はルータが維持するカウンタに基づくものとすることができる。カウンタはデータフローカウントと統合される。該データフローカウントは、２つのインターネットプロトコルエンティティ間で観察されるデータトラフィックのバイト数の合計である。集められたデータフローカウントにより、任意の２つの場所の間で特定のプロトコルを介してリレーされたトラフィックの量を決定することができる。ルータは通常は、これらのデータフローカウンタを他のシステムにリレーし、該システムにおいて記憶し及び／又は解析する。かかるシステムの一例は、イネーブルになって他のシステムにデータフロー情報を流すNETFLOW機能を有するシスコのルータである。システムはデータフローを記憶して集め後から解析するプロセスを実行する。NETFLOW解析により提供される情報は、特定のトラフィック宛先に関するデータトラフィックボリュームを提供するだけである。NETFLOW解析のユーザは、例えば、データトラフィックが移動した中間のネットワークを決定することはできない。NETFLOWユーザは、データトラフィックが終了した場所しか決定できない。
コンテンツ（例えばウェブサイト等の情報又は他のアプリケーション）のオンデマンドでの利用可能性は、多くの会社（例えばウェブサイトを介して業務を行っている会社）にとって非常に重要である。通信ネットワーク（例えばインターネット）の個別の部分に障害が起きても、ネットワーク全体では会社のコンテンツ（例えば会社のウェブサイト）の配布が妨げられないようにするために、会社に通信ネットワークに対するサービスの冗長ポイントを提供して、コンテンツの提供の使用可能性と故障耐性を強化することができる。例えば、ワールドワイドウェブ（ウェブ）上の多くのコンテンツプロバイダは、複数のインターネットサービスプロバイダを使用して、コンテンツをクライアントに提供するための、インターネットへの冗長接続を可能にしている。
コンテンツプロバイダが複数のサービスプロバイダを使用する場合、該コンテンツプロバイダは、かかるサービスプロバイダを使用するために、様々な方法のうち任意の方法を実施することができる。使用し得る１つの方法として、負荷のかかっている各サービスプロバイダの応答時間を短縮させるために冗長サービスプロバイダによるてこ入れを試みないことが挙げられる。その代わりに、１つのサービスプロバイダを使用してクライアントにサービスを提供し、代替的なサービスプロバイダは、保留状態に保持され、故障許容式のコンテンツ提供を行うためだけに存在することになる。この方法は、コンテンツプロバイダに信頼できるバックアップを提供するものとなるが、クライアントの要求に対してサービスを提供するには非効率的な技術である。アイドル状態にあるバックアップサービスプロバイダの冗長リソースは、コンテンツプロバイダが他のサービスプロバイダの故障を許容できる可能性を増やす以外の利益をもたらさない。
他の従来技術として、多数のサービスプロバイダのリソースを利用しようとすることが挙げられる。かかる技術の一例として、「早期結合（early binding）」と呼ばれるものがある。コンテンツの要求者（クライアント）は、サービス提供の静的に割り当てられたインスタンスである。例えば、第１の地理的な領域内の全てのクライアントを第１のサービスプロバイダによりサービスされるよう割り当て、第２の地理的な領域内の全てのクライアントを第２のサービスプロバイダによりサービスされるよう割り当てることが可能である。もちろん、地理的な場所以外の基準に基づいて、又は地理的な場所に加えた更なる基準に基づいて、クライアントを予め割り当てることも可能である。この「早期結合」方法の主な欠点は、コンテンツの要求者（クライアント）とサービスプロバイダとの間の割り当てが静的であることに起因するものである。この方法では、サービスプロバイダの負荷（例えば、各サービスプロバイダを介してコンテンツプロバイダがサービスを提供しているクライアント要求の数）又は状態にシフトが生じても調節することができない。例えば、サービスプロバイダに対する要求の割り当ては、各サービスプロバイダの変動する負荷に応じたものとすることができない。コンテンツ要求者（クライアント）のコミュニティが非常に活動的である場合に、システムは、全ての使用可能なサービスプロバイダにわたって要求を拡散させることはない。要求を拡散させるのではなく、要求者に静的に割り当てられたプロバイダのみを使用して、到来する要求により生成される負荷（要求されたコンテンツをサービスするための出口トラフィックフロー）を処理する。
冗長リソースを利用する別の既存の技術として、「後期結合（late binding）」と呼ばれるものがある。コンテンツプロバイダのコンテンツ要求者（クライアント）は、所与のサービスプロバイダに動的に割り当てられる。このため、システムは、コンテンツプロバイダが使用する複数のサービスプロバイダのうちどのサービスプロバイダが所与のクライアントの要求を処理すべきかを動的に決定する。この決定は、ラウンドロビン、ランダム割り当て等の既知のストラテジーを使用して行うことができる。ラウンドロビン技術の場合には、コンテンツプロバイダに到来するクライアントの要求の各々は、そのコンテンツプロバイダのサービスプロバイダの候補のリストのうちの１つのサービスプロバイダにそれぞれ割り当てられる。候補の選択は、リスト上の候補の順序によって決定される。各サービスプロバイダはサービス要求を順次受信する。このため、この技術は、ラウンドロビン方式でサービスプロバイダに要求を割り当てることによって、サービス要求の負荷の間で平衡をとろうとする。ランダム割り当て方法は、ラウンドロビン方法に似ているが、候補のサービスプロバイダのリストが特定の順序を有さない点が異なる。サービス要求の割り当ては、コンテンツプロバイダの候補のサービスプロバイダのリストからランダムに引き出される。
ラウンドロビンストラテジーとランダム割り当てストラテジーでは、コンテンツプロバイダから要求側クライアントに出口トラフィック（コンテンツ）を提供するために使用すべきサービスプロバイダの割り当てがブラインドアルゴリズムを使用して行われることを理解されたい。この場合には、例えば各サービスプロバイダに対する需要又は負荷が考慮されることはない。
本発明は、複数のサービスプロバイダの間でコンテンツプロバイダからの出口トラフィック負荷の割り当てを管理するためのシステム及び方法に関する。本発明の特定の実施形態は、所定のラウンドロビン法又はランダム法だけでなく、トラフィックボリュームの解析に基づいて、コンテンツプロバイダが使用する複数のサービスプロバイダの間で負荷の平衡をとる。例えば特定の実施形態では、各サービスプロバイダについて収集されたプレフィクス毎の使用データと、コンテンツプロバイダのルータ（複数可）から収集されたルータインタフェイス使用データを使用して、複数のサービスプロバイダの各々に対する出口トラフィックの最適な割り当てを決定する。したがって、本発明の特定の実施形態では、通信ネットワークにアクセスするために複数のサービスプロバイダを使用するコンテンツプロバイダに、出口リンクのプレフィクス毎の割り当てを自動的かつ最適に制御する手段を提供し、これにより、インフラストラクチャを再構成することなく、また遭遇する動的なネットワークトラフィックに応じて、負荷の平衡と冗長性の両方が達成される。
少なくとも１つの実施形態によれば、通信ネットワークに対するアクセスを提供する複数のサービスプロバイダに通信可能な状態で結合されたコンテンツプロバイダを含むシステムが提供される。このシステムは更に、複数のサービスプロバイダの各々のトラフィックボリュームに少なくとも部分的に依存して、複数のサービスプロバイダの各々にルーティングすべきコンテンツプロバイダの出口トラフィックの最適な平衡を決定するよう動作可能な、出口トラフィックマネジャーを含む。
少なくとも１つの実施形態によれば、本発明の方法は、通信ネットワークに対するアクセスをコンテンツプロバイダに提供するために複数のサービスプロバイダを使用することを含む。ここで、コンテンツプロバイダは複数のサービスプロバイダを介してクライアントに出口トラフィックを通信する。この方法は更に、各サービスプロバイダに関するトラフィックボリュームデータを収集することと、収集されたトラフィックボリュームデータに少なくとも部分的に基づいて、コンテンツプロバイダから複数のサービスプロバイダに対する出口トラフィックの割り当てを変えるか否かを決定することを含む。
少なくとも１つの実施形態によれば、コンテンツプロバイダから複数のサービスプロバイダに対するインタフェイス毎に、複数の異なるインターネットプロトコル（ＩＰ）プレフィクスの各々に宛てられたアウトバウンドボリュームを決定する手段を備える出口トラフィックマネジャーが提供される。出口トラフィックマネジャーは更に、各ＩＰプレフィクスに宛てられたアウトバウンドボリュームに少なくとも部分的に基づいて、複数のサービスプロバイダの間でコンテンツプロバイダからのアウトバウンドトラフィックの量を再割り当てするか否かを決定する手段を備える。
少なくとも１つの実施形態によれば、出口トラフィックマネジャーは、コンテンツプロバイダから、通信ネットワークに対するアクセスを提供する複数のサービスプロバイダの各々に対して、少なくとも１つのルータでルーティングされた出口トラフィックのボリュームを反映するデータを収集する、少なくとも１つのデータコレクタモジュールを備える。出口トラフィックマネジャーは更に、収集されたデータに少なくとも部分的に基づいて、少なくとも１つのルータのルーティング・ストラテジーを更新して複数のサービスプロバイダの間で出口トラフィックの割り当てを変更すべきか否かを決定する、決定実行モジュールも備える。
少なくとも１つの実施形態によれば、本発明の方法は、コンテンツプロバイダからの出口トラフィックをルーティングするための少なくとも１つのコンテンツプロバイダルータを実施することを含む。コンテンツプロバイダルータ（複数可）は、コンテンツプロバイダに通信ネットワークへのアクセスを提供する複数のサービスプロバイダの各々に対する少なくとも１つのインタフェイスを有し、コンテンツプロバイダルータ（複数可）は、複数のサービスプロバイダのうちどのサービスプロバイダが、コンテンツプロバイダの出口トラフィックをルーティングするかを決定する元となるルーティングテーブルを含む。この方法は更に、コンテンツプロバイダルータ（複数可）から複数のサービスプロバイダの各々に向けられる出口トラフィックのボリュームを監視することと、コンテンツプロバイダルータ（複数可）から複数のサービスプロバイダのうち任意のサービスプロバイダに対する出口トラフィックのボリュームが、対応する閾値の量を超えたか否かを決定することを含む。複数のサービスプロバイダのうち１つのサービスプロバイダに対する出口トラフィックのボリュームが対応する閾値を超えていると決定された場合、コンテンツプロバイダルータ（複数可）のルーティングテーブルを更新し、コンテンツプロバイダの出口トラフィックを、複数のサービスプロバイダの間で再割り当てする。
上記は、次の本発明の詳細な説明をよりよく理解するために、本発明の特徴と技術上の利点を概略したものである。本発明の追加の特徴及び利点は、本発明の請求項の主題を形成する以下に説明する。開示された概念と特定の実施形態は、本発明と同じ目的を実行するために、他の構造を修正するか又は設計する基礎として容易に使用できることを理解されたい。また、かかる等価の構成も、付随する請求項が説明する本発明から離れるものではないことが理解されるであろう。本発明の特徴と考えられる、本発明の構成と動作の方法に関する新規な特徴、及び、別の目的と利点は、次の説明を付随する図面と共に考慮すればよりよく理解されるであろう。しかし、各図面は図示と説明の目的で提供されたものであり、本発明の限定を定義する意図ではないことを明らかに理解されたい。
本発明をより完全に理解するために、付随する図面と共に次の説明を参照する。
図１は、本発明の一実施形態を使用できる典型的なコンピュータネットワーク100の概略の構成図である。コンピュータネットワーク100は、従来のドメイン内ルータ101及びドメイン間ルータ102等の中間のノードで相互接続された複数の自律システム（ＡＳ）又はルーティングドメインを備える。図１の例に示すように、ＡＳは、ドメイン間ルータ102で相互接続された、インターネットサービスプロバイダ（ＩＳＰ）ドメインと様々なルーティングドメイン（ＡＳ1、ＡＳ2、ＡＳ3）を含んでいてもよい。更に後述するように、一部のコンテンツプロバイダ（図示せず）は、かかる複数の異なるＩＳＰドメインに通信可能な状態で結合することができる。
ドメイン間ルータ102は更に、ローカルエリアネットワーク（ＬＡＮ）等の共有媒体ネットワーク103、及びフレームリレーリンクや非対称転送モードリンク又はその他のシリアルリンク等のポイントツーポイントリンク104によって相互接続することができる。周知のように、ルータ間の通信は典型的には、離散データフレーム又はパケットを、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の予め定義されたプロトコルに従って交換することによって行われる。ルータ101,102は例えばＢＧＰルータを含んでいてもよい。よく知られているように、ＢＧＰは、例えばインターネット内でルータのために一般に使用されている外部ゲートウェイプロトコル（ＥＧＰ）である。
各ルータは典型的には、プロセッサ、メモリ、ネットワークインタフェイスアダプタ等の複数の相互接続された要素を備える。図２は、バス203を介して、メモリ202と複数のネットワークインタフェイスアダプタ204A,204B,204Cに結合されたルートプロセッサ201を備える典型的なドメイン間ルータ102の概略の構成図である。ネットワークインタフェイス204A〜204Cは、外部のドメイン間ルータＲA〜ＲCに結合する。当業界で周知であるように、メモリ202は、プロセッサ201とインタフェイスアダプタ204A〜204Cによってアドレス指定可能で、ソフトウェアプログラムとデータ構造を記憶するための格納場所を備えていてもよい。例えば、メモリ202は、ＢＧＰピアテーブル202Aとルーティング（又は転送）テーブル202B等のデータ構造を記憶していてもよい。
ルートプロセッサ201は、ソフトウェアプログラムを実行しデータ構造を操作する処理要素又は論理を備えていてもよい。一般に一部がメモリ202内に存在しルートプロセッサ201により実行されるオペレーティングシステム（OS）は、とりわけ、ルータ上で実行されるソフトウェアプロセスをサポートするネットワーク動作を呼び出すことにより、ルータを機能的に構成する。当業者であれば、様々なコンピュータ読み取り可能媒体を含む他のプロセッサ及びメモリ手段も、プログラム命令を記憶し実行するためにルータ102内で使用できることが明らかであろう。
当業界でよく知られているように、各ドメイン間ルータ102は一般的に、ＢＧＰプロトコルに従ってルーティング動作を行うために、ルータのピア・ルータを識別するＢＧＰテーブル202Aと、特定のネットワークに対して考え得る全ての経路をリストするルーティングテーブル202Bとを維持する。ルータは更に、ルーティングテーブルが変わったときにルーティング更新メッセージを使用してルーティング情報を交換する。ルーティング更新メッセージは更新側（送信側）ルータが生成し、コンピュータネットワーク全体で、各隣接のピア（受信側）ルータに最適な経路を通知する。これらのルーティング更新によりＡＳのＢＧＰルータは、ネットワークトポロジに関して一貫した最新の見通しを構成することができる。図２には例としてのＢＧＰルータ102を示したが、当業者であれば、現在知られているか又は今後開発されるであろう他のタイプのルータも、本発明の特定の実施形態と共に使用できることが理解されるであろう。
ＢＧＰ、特にＢＧＰのバージョン４（ＢＧＰ４）は、コンテンツプロバイダ（リーフ（leaf）自律システム）をサービスプロバイダ及びインターネットの残りにリンクする一般的な方法である。多くのコンテンツプロバイダはそれぞれの大きさと組織の地理に依存して、２つ又は３つ以上のサービスプロバイダを使用することができる。しばしば多数のサービスプロバイダを使用して、一定の負荷平衡及び冗長性を達成する。これらの目的は、典型的には大規模な計画によって達成され、参加しているルータのＢＧＰ構成という形態で表現される。
ルータの転送技術は通常はそのルータが実行できる負荷平衡のタイプを決定するものとなる。例えば、シスコに関するルータ負荷平衡技術を次の表１にまとめる。これは、他のルータの製造業者を代表するものでもある。
Figure 2005110261


ルータのパケット転送技術には一般に３つの基本的なタイプがあり、すなわち、（a）パケット転送がプロセススイッチ（プロセススイッチング）を必要とするもの、（b）パケット転送が割り込みハンドラ（高速スイッチ）で解決されるもの、又は（c）パケット転送がシスコ・エクスプレス・フォワーディング（ＣＥＦ）等の独自のソフトウェア技術及びハードウェアサポートを含むものである。４つの負荷平衡技術、すなわち、1）パケット毎の技術、2）宛先毎の技術、3）フロー（ネットフロー）毎の技術、及び4）ソース／宛先毎の技術が利用可能である。全ての４つの負荷平衡技術は、ルーティングプロトコルとは独立して使用可能である。上記表１は、各パケット転送技術でどの負荷平衡技術が実施できるかを識別している。例えば、プロセススイッチング又はＣＥＦパケット転送技術を使用するルータは、パケット毎の負荷平衡を提供し、高速パケットスイッチング転送技術を使用するルータは、宛先毎の負荷平衡を提供することができる。
したがって、上記のように、ルータは一定の負荷平衡を提供するように構成することができる。更にＢＧＰを使用する場合には、上記４つの負荷平衡技術を使用して、２つの構成、すなわち、1）多数の物理リンクにわたる単一のＢＧＰセッション、及び、2）多数の物理リンクにわたる多数のＢＧＰセッションで、負荷平衡をとることができる。
しかし、従来のＢＧＰ負荷平衡の主な欠点は、単一のサービスプロバイダだけにしか適用できないことである。例えば、トラフィックがいくつかの経路で特定の宛先ＩＰアドレスにルーティングできるようＢＧＰルータを構成することにより、ＡＳ間の或る程度の負荷平衡をＢＧＰで達成できる。しかし、かかる種類のＢＧＰ負荷平衡は、単一のサービスプロバイダにしか実行できない。言い換えれば、特定の宛先ＩＰアドレスを提供する単一のサービスプロバイダの場合、該プロバイダは、少数の異なる経路をとることはできるが、やはり該経路はその単一のサービスプロバイダに関するものである。したがって、このタイプのＢＧＰ負荷平衡は、複数のサービスプロバイダを有するコンテンツプロバイダに使用可能な追加の帯域幅を利用することができない。
したがって、多数の冗長なサービスプロバイダを使用するコンテンツプロバイダに関する最悪の場合のＢＧＰルータ構成では、一次リンクが故障しない限り、１つ又は２つ以上の冗長サービスプロバイダリンク（複数可）は使用されない。したがって本質的には負荷平衡は発生せず、一次サービスプロバイダの故障に備えて追加のサービスプロバイダは予備のままとなる。コンテンツプロバイダは、所与のプレフィクスに対して最良の（最も短いことが多い）経路を選択するＢＧＰアルゴリズムに従って多数のサービスプロバイダ間で意図せず負荷平衡をとる場合がある。ＢＧＰが各プロバイダから一部のプレフィクスを選択できるようにすることにより、負荷平衡と冗長の組み合わせが達成される。
本明細書で使用する「プレフィクス」という用語は、当業界で周知のものであるため、次に簡単に説明する。周知のように、インターネット上で通信する各コンピュータは、インターネット上で一意にデバイスを識別し、他のコンピュータから区別するインターネットプロトコル（ＩＰ）アドレスを割り当てられている。ＩＰアドレスは32ビットを有し、バイナリ形態ではなく十進法の形態で表された0から255の4オクテットの数として示されることが多い。各32ビットのＩＰアドレスは２つのサブアドレスを含み、１つはネットワークを識別しもう１つはそのネットワークへのホストを識別し、仮想的な境界線がこの２つを分離する。ＩＰアドレスのネットワーク部分とホスト部分の間の境界の位置は、サブネットマスクの使用によって決定される。サブネットマスクはもう１つの32ビットのバイナリ数であり、32ビットのＩＰアドレスに適用されるとフィルタのような役割を果たす。サブネットマスクとＩＰアドレスを比べることにより、システムはＩＰアドレスのどの部分がネットワークに関連し、どの部分がホストに関連するかを決定できる。サブネットマスクが「1」に設定されたビットを有する場所では、そのＩＰアドレスの元のビットはネットワークアドレスの一部であり、サブネットマスクが「0」に設定されている場所では、そのＩＰアドレスの関連するビットはホストアドレスの一部である。RFC1519「クラスレスドメイン間ルーティング（CIDR）」で定義された最近のネットワーク環境では、ネットワークのサブネットマスクは典型的には、ネットワーク番号の後に続く「スラッシュ・プレフィクス」として書かれた形態で注釈をつける。例えば、ＩＰアドレスは10.0.0.0/8と書かれる場合があるが、これは、8というサブネットマスク（プレフィクス）を有する10．0．0．0というアドレスという意味である。スラッシュ・プレフィクス注釈は、一般に人の利便のために使用されるものであり、インフラストラクチャデバイスは典型的には、ネットワークとルータを識別するために内部では32ビットのバイナリサブネットマスクを使用することを理解されたい。
上記のように、負荷の平衡をとる様々な技術が関連技術で使用可能である。しかしこれらの技術は、トラフィックの解析に基づいてコンテンツプロバイダに使用可能な複数のサービスプロバイダの間でのトラフィックの平衡をとることはできない。その代わりに、要求されたコンテンツを供給するサービスプロバイダを選択するために、ラウンドロビン方式又はランダム割り当て方式といった技術を使用する。
更に、従来の負荷平衡技術は、負荷平衡を決定するために、各サービスプロバイダがコンテンツプロバイダの出口トラフィックをどの程度うまく処理しているかを評価することはできない。場合によっては、１つのサービスプロバイダは、他のサービスプロバイダよりもコンテンツプロバイダの出口トラフィックをよりよく処理している場合がある。ラウンドロビン方式又はランダム割り当て方式等を使用する典型的な負荷バランサでは、各サービスプロバイダがどのようにうまくトラフィックを処理しているかにかかわらず、コンテンツプロバイダの出口トラフィックを、サービスプロバイダの間で均等に配分する。例えば、１つのサービスプロバイダには（例えば様々な異なるコンテンツプロバイダから）非常に重いトラフィック負荷がかかっているが、別のサービスプロバイダの負荷ははるかに少ない場合がある。典型的な負荷平衡技術は各サービスプロバイダの負荷（トラフィックのボリューム）を考慮できず、現在有する負荷が小さいサービスプロバイダがトラフィックをうまく処理できても、コンテンツプロバイダからの出口（又はアウトバウンド）トラフィックを各サービスプロバイダへ均等に配分する。
更に以下に説明するように、本発明の実施形態は、複数のサービスプロバイダの間でコンテンツプロバイダからの出口トラフィック負荷の割り当てを管理するシステム及び方法を提供する。本発明の実施形態は、所定のラウンドロビン方式又はランダム方式だけではなく、トラフィックボリュームの解析に基づいて、コンテンツプロバイダが使用する複数のサービスプロバイダの間で負荷の平衡をとる。
本発明の特定の実施形態は、各サービスプロバイダについて収集されたプレフィクス毎の使用データと、コンテンツプロバイダのルータ（複数可）から収集されたルータインタフェイス使用データとを使用し、複数のサービスプロバイダのうち各々に対する出口トラフィックの最適な割り当てを決定する。特定の実施形態では、次の制約に基づいて、多数のサービスプロバイダについて出口トラフィック負荷平衡を最適化するアルゴリズムが提供される。（a）リンク毎の使用率、（b）プレフィクスリンクスイッチング頻度、（c）スイッチングされたプレフィクスの数。制御機構（次に説明する）が出口リンクを変えたときに（例えば１つのサービスプロバイダから別のサービスプロバイダに）、プレフィクスがスイッチングされる。特定の実施形態は、上記の制約に追加するか又は上記の制約の代わりに、スイッチングを決定するときにプレフィクスの安定性及びリンク性能等別の要因を考慮することもできる。
例えば特定の実施形態では、サービスプロバイダにトラフィックがどのように負荷又は分配されているかの解析（例えばサービスプロバイダに対して負荷されたトラフィックのボリューム）は、2001年12月7日に提出された、同時係属中の本出願人の「METHOD AND SYSTEM FOR DETERMINING AUTONOMOUS SYSTEM TRANSIT VOLUMES」と題する米国特許出願第2003//0120769号に記述されている。出口トラフィックマネジャーは、コンテンツプロバイダが各サービスプロバイダのトラフィックボリュームの解析を使用して、所与の時点でコンテンツプロバイダの出口トラフィックについてどのように平衡をとれば一番いいのかを決定するよう実施することができる。したがって、コンテンツプロバイダの出口トラフィックは、異なるサービスプロバイダ間で最適に平衡がとられ、コンテンツをクライアントに提供する最良の性能が達成される。本発明の特定の実施形態は、コンテンツプロバイダからの出口トラフィックをサービスプロバイダ間で動的に平衡をとるために、その実施に特殊目的ハードウェアを必要とせず、使用されているハードウェアを利用する（例えばＢＧＰルーティングプロトコルを使用する）、出口トラフィックマネジャーを提供する。
したがって本発明の実施形態は、通信ネットワークにアクセスするために複数のサービスプロバイダを使用するコンテンツプロバイダに対して、出口リンクのプレフィクス毎の割り当てを自動的かつ最適に制御することによって、インフラストラクチャを再構成せず、動的なネットワークトラフィックダイナミクスに応じて、負荷の平衡と冗長性の両方を達成する手段を提供する。本発明の実施形態は、OSIネットワークレイヤより上で動作するので、スイッチング関連の負荷平衡技術（ルータ内で実施される技術等）又はプロトコルとは独立して適用できる。例えば、特定の実施形態はOSIネットワークレイヤからデータを収集し、このデータをOSIアプリケーションレイヤ内で使用してルーティングを制御することができる。
図３は、本発明の実施形態を実施する例としてのシステム300を示す。より具体的には、例としてのシステム300は、通信ネットワーク301に通信して結合される複数のクライアント、クライアント1、クライアント2、…、クライアントnを含む。各クライアント、クライアント1、クライアント2、…、クライアントnは、通信ネットワーク301に少なくとも一時的に通信して結合することのできる任意のタイプのプロセッサベースのデバイスであってよく、この中には例として、パーソナルコンピュータ（PC）、ラップトップコンピュータ、携帯コンピュータ（例えば携帯情報端末（PDA））、携帯電話等を含む。通信ネットワーク301はインターネット（又は他のWAN）、及び／又は、公共（又は私設）電話ネットワーク、ワイヤレスネットワーク、ケーブルネットワーク、ローカルエリアネットワーク（LAN）、現在知られた任意の通信ネットワーク又は今後開発される任意の通信ネットワーク、上記の任意の組み合わせを含んでいてよい。
コンテンツプロバイダ302はまた、通信ネットワーク301に通信して結合する。この例では、コンテンツプロバイダ302はサービスプロバイダAとサービスプロバイダB等の複数のサービスプロバイダを介して通信ネットワーク301にアクセスを有する。例えば、インターネットにアクセスを提供するサービスプロバイダの例は、スプリント、AT＆T、UUNETホールセールネットワークサービス、レベル3コミュニケーションズ、ケーブルアンドワイヤレス、クエストコミュニケーションズを含む。コンテンツプロバイダ302は、サーバコンピュータ等、通信ネットワーク301を介してクライアントにコンテンツを供給できる任意の適切なプロセッサベースのデバイスを含んでいてよい。コンテンツプロバイダ302は、コンテンツを記憶したデータストレージ303に通信して結合する。データストレージ303はコンテンツプロバイダ302の内部であっても外部であってもよく、データを記憶する任意の適切なタイプのデバイスを含んでいてもよく、この中には、メモリ（例えばランダムアクセスメモリ（RAM））、光ディスク、フロッピーディスク等が含まれるが、これらに限定されるものではない。コンテンツプロバイダ302はデータストレージ303からのコンテンツ等のコンテンツを、通信ネットワーク301を介してクライアント1からクライアントn等のクライアントに供給するように動作可能である。システム300の例として、コンテンツプロバイダ302は、通信ネットワーク301（例えばインターネット）を介して、クライアント1からクライアントn等の要求側クライアントにコンテンツ（ウェブサイト等）を供給するウェブサーバを備えていてよい。
更に次に詳細に示すように、本発明の実施形態は、サービスプロバイダAとサービスプロバイダBを介して要求側クライアントに、コンテンツプロバイダ302からのアウトバウンドコンテンツをルーティングすることを管理するように動作可能な、出口トラフィック管理ロジック（「又は出口トラフィックマネジャー」）304を提供する。例えば、出口トラフィックマネジャー304は、図３の例ではサービスプロバイダA及びサービスプロバイダB等の複数のサービスプロバイダ間で、コンテンツプロバイダ302から供給された出口トラフィックの負荷に関して最適に平衡をとるよう動作可能である。
サービスプロバイダA及びサービスプロバイダBは各々、コンテンツプロバイダ302を通信ネットワーク301に通信して結合するためにルータ306,307等の１つ又は２つ以上のルータ（例えばＢＧＰルータ）をそれぞれ含んでいてもよい。更に図示するように、コンテンツプロバイダ302は出口トラフィックをサービスプロバイダAとサービスプロバイダBにルーティングするために、１つ又は２つ以上のルータ305（例えばＢＧＰルータ）を含んでいてもよい。ルータ（複数可）305は、マネジャー304による出口トラフィックの管理にしたがって、所定のクライアント要求をサービスプロバイダAに（ルータ306を介して）供給するためにアウトバウンドコンテンツを選択的にルーティングし、また、所定の他のクライアント要求をサービスプロバイダBに（ルータ307を介して）供給するためにアウトバンドコンテンツを選択的にルーティングすることができる。更に次に説明するように、出口トラフィックマネジャー304は全てのトラフィックの解析に少なくとも部分的に基づいて、コンテンツプロバイダ302からの出口トラフィックに関してルータを更新する。
図４は、本発明の一実施形態による、出口トラフィックマネジャー304の一例としての構成図である。図示されるように、この出口トラフィックマネジャー304の例としての実施は、プレフィクス毎の使用データコレクタ401、ルータインタフェイス使用データコレクタ402、ＢＧＰスピーカ403、決定実行手段404を含む。プレフィクス毎の使用データコレクタ401、ルータインタフェイス使用データコレクタ402、ＢＧＰスピーカ403、決定実行手段404は各々、ソフトウェア、又は、ハードウェア、又はこれらの組み合わせで実施でき、次に説明するようにそれぞれの機能を提供することができる。また図４の説明を簡単にするために、出口トラフィックマネジャー304の１つ又は２つ以上の構成要素は、それぞれを別々の構成要素として示したが、特定の実施形態ではそれらを組み合わせて（例えば共通のソフトウェア及び／又はハードウェアで）実施することが可能である。
図４の例としての実施形態では、コンテンツプロバイダルータ（複数可）305は、ＢＧＰ4プロトコルを実行しネットフロー（又はデータフロー情報を提供する同様なツール）をサポートするルータ（複数可）を備える。ＢＧＰスピーカ403は、従うように指示されたポリシーに従って、ＢＧＰ更新を受信し、ルートを管理し、更新をコンテンツプロバイダルータ305に送信するZebra（よく知られたオープンソースである。www.zebra.org参照のこと）等のルーティングマネジャーである。出口トラフィックマネジャー304は更に、プレフィクス毎の使用データコレクタ401とルータインタフェイス使用データコレクタ402等の１つ又は２つ以上のデータ収集ホストを含む。プレフィクス毎の使用データコレクタ401は、プレフィクス毎のトラフィックボリューム等の情報を収集する。プレフィクス毎の使用データコレクタ401は例えば、2001年12月7日に提出された、同時係属中の本出願人の「METHOD AND SYSTEM FOR DETERNIMING AUTONOMOUS SYSTEM TRANSIT VOLUMES」と題する米国特許出願第2003/0120769号の教示に従って実施することができる。
例示的なシナリオとして図４に示すように、コンテンツプロバイダのルータ305が、２つのサービスプロバイダ、すなわち、サービスプロバイダA及びサービスプロバイダBに結合されていると仮定する。図４に示すように、ルータ305は、完全なインターネットルーティングテーブルを、サービスプロバイダAのルータ306とサービスプロバイダBのルータ307から外部ＢＧＰ（「EＢＧＰ」）を介して得る。別のモジュール（図示せず）は、制御パラメータで決定実行モジュール404をプログラミングすることができる。例として、かかる制御パラメータは、サービスプロバイダAのリンクが70％の使用率のとき、オーバーフロー・トラフィックをサービスプロバイダBにルーティングするようルーティングを変える等と指定することができる。この例としてのパラメータの代わり又はこのパラメータに追加して、様々な他の制御パラメータを実施することもできる。例えば、制御パラメータは更に、サービスプロバイダAのリンクが70％の使用率であり、サービスプロバイダBのリンクが70％以下の使用率である場合だけ、オーバーフロー出口トラフィックをサービスプロバイダBにルーティングするよう指定することもできる。
ネットフロー（又はデータフロー情報を提供する同様なツール）は、トラフィックマトリックスデータをプレフィクス毎の使用データコレクタモジュール401にエクスポートするように構成される。収集されたトラフィックマトリックスデータは、プレフィクス毎の使用データコレクタモジュール401が処理し、各インタフェイス上で各プレフィクスが寄与するアウトバウンドボリュームを決定する（例えば、サービスプロバイダAに対するインタフェイスとサービスプロバイダBに対するインタフェイスを介して）。各インタフェイス上で各プレフィクスが寄与する決定されたアウトバウンドボリュームを識別するデータを、決定実行モジュール404に送信する。ルータインタフェイス使用データコレクタモジュール402は定期的に、インタフェイス使用情報に関してコンテンツプロバイダルータ305をポーリングする。この情報は決定実行モジュール404にも送信されている。
決定実行モジュール404は、データコレクタモジュール401,402から受信した情報に基づいて、アウトバウンドトラフィック（例えば特定のプレフィクスについて）についてサービスプロバイダAとサービスプロバイダBの間で平衡をとりなおすか否かを決定する（例えば、所定のアウトバウンドトラフィックを１つのサービスプロバイダリンクから他のサービスプロバイダリンクにシフトする）。例えば、プレフィクス10.0.0.0/8がコンテンツプロバイダ（例えば図３のコンテンツプロバイダ302）からトラフィックを要求するクライアントのグループ（ＡＳ）と関連づけられていると仮定する。この例では、サービスプロバイダAとサービスプロバイダBは、それぞれ例えばルート306,307を介してプレフィクス10.0.0.0/8へのルートを提供することを理解されたい。決定実行モジュール404は受信した情報から、（a）サービスプロバイダAは70％の使用率であり、（b）プレフィクス10.0.0.0/8がサービスプロバイダAのリンクでアウトバウンドトラフィックの30％に寄与しているということを決定することが可能である。例えば、サービスプロバイダAはコンテンツプロバイダからのトラフィックを処理するために70％の使用率であり、サービスプロバイダA上のアウトバンドトラフィックの30％は、10.0.0.0/8プレフィクスのクライアントに向けられたアウトバウンドトラフィックであり、サービスプロバイダAのアウトバウンドトラフィックの残りの40％は、他のクライアントに向けられたコンテンツプロバイダからのトラフィックである。したがってこの例では、決定実行モジュール404は、制御パラメータに依存して、プレフィクス10.0.0.0/8に対するアウトバウンドトラフィックをサービスプロバイダBのリンクにシフトすべきことを決定することができる。
この決定はＢＧＰスピーカモジュール403に送信される。ＢＧＰスピーカモジュールは、コンテンツプロバイダのルータ305のカレントテーブルと同一である、完全なカレントテーブルを有する。したがってＢＧＰスピーカモジュール403は、ルータ305のカレントルーティングテーブルから、プレフィクス10.0.0.0/8がネクストホップＩＰサービスプロバイダAのネクストホップ属性と、100のローカルプリファレンスを有することを現在「知っている」。また、ルータ305のルーティングテーブルから、プレフィクス10.0.0.0/8がネクストホップＩＰサービスプロバイダBのネクストホップ属性と80のローカルプリファレンスを有することを知っている。ＢＧＰルーティング決定アルゴリズムによれば、ローカルプリファレンスのより高いルートが好ましい。したがって、サービスプロバイダAは現在、プレフィクス10.0.0.0/8に関するトラフィックをルーティングするために、サービスプロバイダBよりも好ましい。この例では決定実行モジュール404は、プレフィクス10.0.0.0/8のアウトバウンドトラフィックをサービスプロバイダBのリンクにシフトすべきことを決定したため、ＢＧＰスピーカモジュール403はＢＧＰを使用してプレフィクス10.0.0.0/8のローカルプリファレンス属性を逆にする。したがって次のステップが生じる。（a）10.0.0.0/8に対するプレフィクスアナウンスメント更新が、ネクストホップＩＰサービスプロバイダBに設定されたネクストホップ属性を伴うコンテンツプロバイダルータ305に送信される。（b）コンテンツプロバイダルータ305は、ＢＧＰスピーカモジュール403がアナウンスした通りに、より高いローカルプリファレンスをプレフィクス10.0.0.0/8に割り当てるよう構成される。（c）コンテンツプロバイダルータ305は、プレフィクス10.0.0.0/8に対して２つのルート選択を有する（この例でより高いプリファレンスの設定は、リンクがなんらかの理由でダウンしていない限り、サービスプロバイダBを選択することを意味する）。ＢＧＰスピーカ403がアナウンスするプレフィクスはサービスプロバイダBと同一であるが、より高いローカルプリファレンスを有し、より好ましいルートになるという点だけが異なる。
プレフィクス毎の使用データコレクタ401は、ＡＳ伝送を計算し、データフローボリュームを終了させる。これについては、同時係属中の本出願人の「METHOD AND SYSTEM FOR DETERNIMING AUTONOMOUS SYSTEM TRANSIT VOLUMES」と題する米国特許出願第2003/0120769号により詳しく説明されている。少なくとも１つのプレフィクスと少なくとも１つの選択されたＡＳ経路を含むルーティング情報ベースデータは、プレフィクス毎の使用データコレクタ401によって、コンテンツプロバイダ302の各サービスプロバイダのルータから得られる（例えば、サービスプロバイダAのルータ306とサービスプロバイダBのルータ307）。例えば、各サービスプロバイダの合計使用はプレフィクスで決定することができ、各サービスプロバイダの使用量の合計、及び共通プレフィクス（上記の例ではプレフィクス10.0.0.0/8）を有する宛先へコンテンツプロバイダからの出口トラフィックを供給する各サービスプロバイダの使用量を決定することができる。米国特許出願第2003/0120769号に更に説明されるように、ルーティング情報ベースデータは、対応するデータフロー情報に相関させることが可能である。この相関は、複数の自律システム（ＡＳ）番号に関してデータトラフィックボリュームを計算するために行うことができる。例えば、図３及び図４のサービスプロバイダAとサービスプロバイダBの対応するＡＳ番号等である。プレフィクス毎の使用データコレクタ401は、様々なネットワーク伝送プロバイダ（例えばサービスプロバイダAとサービスプロバイダB）のトラフィックボリュームを集計し計算し、ついで、特定のＡＳにおいてどの程度のトラフィックが伝送又は終了したかについての情報を、例えば決定実行モジュール404に提供することができる。
データフロー統計は、ルーティング情報ベースデータ内でどのルートが選択され所与のトラフィックフローが横切ったかを見つけることによって、ルーティング情報ベースデータと相関される。選択されたルートに関してリストされたＡＳ経路を使用し、選択されたルート内にリストされた各ＡＳに関するデータフローのサイズだけカウンタがインクリメントされる。その結果として、各ＡＳにおいて伝送されるか又は終了したデータトラフィックを表す一組のカウンタが得られる。次いでカウンタは、各ＡＳ番号が表すネットワークプロバイダに基づいて組み合わせられる（例えばサービスプロバイダAとサービスプロバイダB）。組み合わされたカウンタから、特定のプロバイダのネットワークにおいてどの程度の量のデータトラフィックが転送又は終了したかを記述するレポートが作成される。このレポートは決定実行モジュール404に通信される。
更に、モジュール402がルータインタフェイス使用データを収集し、決定実行モジュール404がこのデータを使用して、複数のサービスプロバイダの間でコンテンツプロバイダ302からの出口トラフィックの平衡を取り直すか否かを決定することができる。例えば、ルータインタフェイス使用データコレクタ402は定期的に、例えばSNMPクエリーを使用してコンテンツプロバイダルータ（複数可）305をポーリングし、コンテンツプロバイダルータ（複数可）305のインタフェイスが、サービスプロバイダAとサービスプロバイダBの各々についてデータをルーティングするために使用されている量を決定することができる。例えば、コンテンツプロバイダのルータ（複数可）305のサービスプロバイダAのルータ306とのインタフェイスの使用量を決定し、コンテンツプロバイダのルータ（複数可）305とサービスプロバイダBのルータ307とのインタフェイスの使用量を決定する。このデータの解析から、決定実行モジュール404は、各サービスプロバイダにルーティングされているコンテンツプロバイダ302からの出口トラフィックの量（又はボリューム）を決定することができる。
図５を参照すると、コンテンツプロバイダからの出口トラフィックを複数のサービスプロバイダ間で割り当てすることを管理する本発明の実施形態の一例としてのフローチャートが示されている。動作ブロック501で、図３と図４のサービスプロバイダAとサービスプロバイダB等の複数のサービスプロバイダが、通信ネットワーク301へのアクセスをコンテンツプロバイダ302に提供するよう実施される。ブロック502では、トラフィックボリュームデータを各サービスプロバイダについて収集する。例えば、プレフィクス毎の使用データを動作ブロック502Aにおいて収集し（例えばプレフィクス毎の使用データコレクタ401により）、ルータインタフェイス使用データを動作ブロック502Bにおいて収集することが可能である（例えばルータインタフェイス使用データコレクタ402により）。
動作ブロック503では、決定実行モジュール404は、収集されたトラフィックボリュームデータに少なくとも部分的に基づいて、複数のサービスプロバイダの間でコンテンツプロバイダ302からの出口トラフィックの平衡を取り直すか否かを決定する。本書で更に説明するように、かかる決定は、決定実行モジュール404において設定された制御パラメータに基づいて行うことができる。決定実行モジュール404が、コンテンツプロバイダ302からの出口トラフィックの平衡を取り直すことを決定した場合、コンテンツプロバイダのルータ（複数可）305のルーティングテーブルの再構成をトリガし（例えばＢＧＰスピーカ403を介して）、動作ブロック504で所望の（例えば最適な）方法でコンテンツプロバイダの出口トラフィックの平衡を取り直す。例えば、コンテンツプロバイダルータ（複数可）305のルーティングテーブルを再構成し、所定のプレフィクス（複数可。例えばコンテンツプロバイダ302と関連するプレフィクス）に対する出口トラフィックが、この出口トラフィックを最適に処理できるコンテンツプロバイダのサービスプロバイダのうち１つに、ローカルに好ましいルートを有すると指定することができる。例えば、収集されたトラフィックボリュームデータの解析から、決定実行モジュール404は、サービスプロバイダAがサービスプロバイダBよりはるかに多い負荷を有すること、したがってサービスプロバイダBはコンテンツプロバイダの出口トラフィックをよりよく処理できることを決定する場合がある。すると決定実行モジュール404はコンテンツプロバイダルータ（複数可）305の再構成をトリガし、コンテンツプロバイダの出口トラフィックをサービスプロバイダBにルーティングするプリファレンスを確立することができる。
図５の例示的なフローは連続的な動作として示されているが、実際の実施形態はこれとは異なる場合もある。例えば一部の実施では、トラフィックボリュームデータを連続的に収集し、定期的に解析することもできる（例えば所定の構成された内部で）。したがって例えば、動作はブロック504からブロック503に定期的にループして、新しく収集されたトラフィックボリュームデータを解析することができる（ブロック502から）。
本発明の一実施形態により、コンテンツプロバイダ302からの出口トラフィックフローの平衡を、サービスプロバイダAとサービスプロバイダBの間で最適化する技術を説明する一例としての数学的モデルを次に示す。インターネット上の所与の位置が、プレフィクスの組S（t）＝｛1,・・・k（t）｝のどちらかをルーティングすることを指定されたと仮定する。S1＝S1（t）とS2＝S2（t）がSの２つのサブセットであり、L（S1）,L（S2）は、対応するリンクに関連するトラフィックボリュームであると仮定する。例えばL（S1）はサービスプロバイダAのトラフィックボリュームであり、L（S2）はサービスプロバイダBのトラフィックボリュームである。したがって次の性質が存在する。S＝S1∪S2、L（S）＝L（S1）＋L（S2）。
あらゆる種類の平衡動作は、その目的にかかわらず、サブセットS1,S2の展開として記述でき、その結果として、リンク間のトラフィックの再割り当てが得られる。この展開の各ステップは、S1,S2のコンテンツの変化と定義できる。この限定された形の定義を今後使用する。すなわち、S1,S2の新しい状態は、サブセットs1⊂S1をS2に転送すること又はその逆によって識別される。
Figure 2005110261


平衡動作は反復的なものであるので、この式は、sがセットS1とS2の何れに含まれるかに依存して、所与のプレフィクスsに対するトラフィックがL1又はL2にルーティングされるように、リンクL1とL2に対するプレフィクスS1とS2の次のサブセットを計算する方法を示している。組S1とS2の次の反復は次の何れかによって計算する。
（a） 所定のサブセットs1をS1から除去し、それと同じサブセットを追加する（例えば、オペレータが、s2を指定するためのパラメータをS2から得ることが可能である）。
（b） 所定のサブセットs2をS1に加え、この同じサブセットs2をS2から除去する。
サブセットs1とs2の選択基準は、決定実行モジュール404上で実施される決定ルールといった目的関数によって決定することができる。実施可能なかかる決定ルールの例として、L（t）を所与のルータにおける合計出力トラフィック負荷と仮定する。更に、L1（t、A）とL2（t、A）がそれぞれ、サービスプロバイダAとサービスプロバイダBのリンク上の合計トラフィックを表すと仮定する。これは時間tにおいて使用可能な制御Aのクラスから一定の制御Aを適用することから生じる（すなわち、制御パラメータ「制御A」は、決定実行モジュール404上で実施される）。この例ではクラスAは正の実数の全ての有限なストリングのクラスである。各ストリングは、連続した制御動作の間の時間間隔のシーケンスとして解釈される。例えば、A＝（15.5,8.3,13.01）は、合計で３つの制御動作が行われたということを意味する。第１は「開始後」15.5時間単位（time units）（例えば秒、分、時間）を要し、第２は第１の後に8.3時間単位を要し、第３は第２の後に13.01時間単位を要している。したがって、次のように認識することができる。L（t）＝L1（t,A）＋L2（t,A）。
リンクの負荷の瞬間値に対する制約があるものと仮定する。
Figure 2005110261


すなわち、一定の瞬間には、各リンクは負荷をサポートするための所与の容量を有することが仮定されている。
負荷平衡における所定の目的を達成するために、観察／測定されたトラフィックボリュームの点で制御が定義される。より具体的には、次の制御動作Tj＋1の瞬間は、前のトラフィックパターンに基づいて計算すべきである。したがって、τi＋1を、サービスプロバイダAとサービスプロバイダBの２つのリンク上の前のトラフィックボリュームの関数と定義すると充分である。Ti＝τ1＋・・・＋τiが第iの制御動作までに経過した時間となるように、A＝（τ1、・・・τk）を制御と仮定する。（数1）を、TiにおけるTi＋1の前の制御動作の後の対応するリンク1（サービスプロバイダA）と2（サービスプロバイダB）上の負荷値とする。i＋1制御動作の瞬間は再帰的にTi＋1＝Ti＋τi＋1と定義される。
Figure 2005110261


ε1、ε2は安全範囲である。すなわち、トラフィックボリュームのうち１つが前の制御動作の後最初に安全閾値を超えたときに、次の制御動作が発生しなければならない。上記の方式（1）は制御に対応することができ、制御動作の瞬間は、トラフィックボリュームの導関数にも依存する。例えば、決定実行モジュール404による決定は、瞬間的なトラフィック値だけではなく、その変化の速度にも基づいて行うことができる。
決定ルールが導入されると、元のトラフィックL1（t）、L2（t）がL1（t,A）、L2（t,A）に修正される。これは次のように定義できる。
Figure 2005110261


目的関数は、「最適な」リンクの使用のためのトラフィック負荷平衡に関連する、異なる要因の相対的な重要性に対するユーザの認識を反映しなければならない。トラフィック負荷平衡と関連づけられたかかる要因は例えば、オーバーフロー、制御動作の頻度、リダイレクトされたプレフィクスの数という点から見た現在のトラフィックの障害等を含んでいてもよい。関心の対象となる他の要因も同様に処理することができる。
多数の対象がある場合、対応する最適化問題に対処する方法は少なくとも２つある。１つは、これらの要因のうち１つを対象として選択し、これを残りに対する制御に対して最適化することである。もう１つは、例えば、各々が対応する要因から生じる「部分対象」の重み付け合計等全ての要因に依存する関数を導入し、ついで、この「グローバル」対象の最適な値を探す方法である。どちらの最適化の技術も、本発明の実施形態の中で使用できる。
例えば、オーバーフローの量が所与の期間（0,T）に渡って蓄積された場合、部分対象は次のように表現できる。
Figure 2005110261


ここで導関数Dj（t）は次のように定義される。
Figure 2005110261


任意の時間Δにわたる制御動作の頻度q（Δ）は、＃｛i：TiεΔ｝／Δに等しい。この特徴に関する要因Qは例えば、q（Δ）：Q＝max｛q（Δ）：Δε（0,T）｝の最も高い値となる。
第３の要因は、リンク間でトラフィックの一部の量を再割り当てする必要性から生じる。この場合、対応するトラフィックボリュームが制御動作を完成させることのできる、最も小さいプレフィクスのサブセットサイズを選択することによって、システムの障害を可能な低いレベルで維持することに対して有用である。
特定の実施形態で決定実行モジュール404が使用できる最適化問題の１つの公式は、次の制約の下で所定のAの組に渡ってminF（T,A）を見つけることである。
Q＜a
濃度(cardinality)（a）＜b
具体的に言えば、各制御動作（i＋1）は２つのオブジェクト、すなわち、1）前の制御動作の後の時間間隔τi＋1、及び 2）対応するトラフィックをリダイレクトしなければならないプレフィクスのサブセットs⊂S。を決定する。
時間間隔τi＋1は、上記等式（1）で再帰的に指定される。各制御動作に関する２つのオブジェクトを扱うアルゴリズムは、Sからのプレフィクス毎、及び、プレフィクスのサブセットs毎に生成されたトラフィックの量に関する履歴データに基づいていてもよい。
ＢＧＰを本発明の一実施形態である上記の例に使用したが、当業者であれば本発明の実施形態は上記に限定されるものではなく、一定の実施形態はＢＧＰから離れた実施でも行えることが理解されるであろう。更に、上記の例としての技術は、説明を簡単にするために２つのサービスプロバイダリンクの間でコンテンツプロバイダ302からの出口トラフィック負荷に関して最適に平衡をとるシナリオを中心としたが、当業者であれば、かかる技術は、任意の数のサービスプロバイダリンクの間で最適な平衡を決定することに容易に拡大できることを理解されるであろう。
次に図６を見ると、本発明の一実施形態による出口トラフィックマネジャー304の動作フローチャートの例が示されている。動作ブロック601では、コンテンツプロバイダルータ（複数可）305は、コンテンツプロバイダ302とインタフェイスし通信ネットワーク301へのアクセスを提供する複数のサービスプロバイダの各々のルータからルーティングテーブルを得る。例えば、図３と図４の例では、コンテンツプロバイダルータ（複数可）305は、コンテンツプロバイダ302をサービスプロバイダAとサービスプロバイダBとそれぞれインタフェイスするルータであるルータ306と307からルーティングテーブルを得る。動作ブロック602では決定実行モジュール404は、例えば、出口トラフィックをコンテンツプロバイダのサービスプロバイダの間で再割り当てする条件（例えば閾値）を指定する制御パラメータを受信する。
動作ブロック603では、プレフィクス毎の使用データコレクタ401はプレフィクスマトリックスデータをキャプチャし、このデータから、各インタフェイス上で各プレフィクスが寄与するアウトバンドボリュームを決定する。すなわち、プレフィクス毎の使用データコレクタ401は、L（S1）とL（S2）を決定する。ブロック604では、ルータインタフェイス使用データコレクタ402は、インタフェイス使用情報に関してコンテンツプロバイダのルータ（複数可）305をポーリングする。例えば、ルータインタフェイス使用データコレクタ402は、例えば、SNMPクエリーを使用してコンテンツプロバイダルータ（複数可）305をポーリングし、コンテンツプロバイダルータ（複数可）305のインタフェイスがサービスプロバイダAとサービスプロバイダBの各々にデータをルーティングするために使用されている量を決定することができる。例えば、コンテンツプロバイダルータ（複数可）305とサービスプロバイダAルータ306のインタフェイスの使用量が決定され、コンテンツプロバイダルータ（複数可）305とサービスプロバイダBルータ306のインタフェイスの使用量が決定される。
プレフィクス毎の使用データコレクタ401とルータインタフェイス使用データコレクタ402から決定されたデータを決定実行モジュール404に提供し、ブロック605では、決定実行モジュール404は受信したデータを解析して、コンテンツプロバイダルータ（複数可）305のインタフェイス上のトラフィックボリュームが制御パラメータの安全閾値を超えているか否かを決定する。上記のように特定の実施形態では、１つのサービスプロバイダから別のサービスプロバイダにトラフィックの一部を再割り当てする「制御動作」を起動するか否かの決定は、インタフェイス上のアウトバウンドトラフィックの決定されたボリュームに基づくだけではなく、かかるアウトバウンドトラフィックのボリュームがこのインタフェイス上で増加又は減少しているレートにも基づいていてよい。上記のように、特定の実施形態では、決定実行モジュール404上で実施される管理アルゴリズムは、次の制約に基づいて複数のサービスプロバイダの間で出口トラフィック負荷の平衡を制御することができる。（a）リンク毎の使用率、（b）プレフィクスリンクスイッチング頻度、（c）スイッチされたプレフィクスの数（すなわち、異なるサービスプロバイダにトラフィックを再割り当てするために、出口リンクが変えられたプレフィクスの数）。リンク毎の使用率は、ルータインタフェイス使用データコレクタ402によって決定することができる。プレフィクスリンクスイッチング頻度は、以前の決定に基づいて決定実行モジュール404が決定することができる（例えば、異なるサービスプロバイダを介して所与のプリフィクスに対してトラフィックをルーティングする必要があると決定された頻度）。特定の実施形態では、プレフィクスリンクスイッチング頻度はコンフィギュラブルパラメータであってもよい（例えば、オペレータは、「一日にN回以上プレフィクスについてルートをスイッチしない」と指定するようにパラメータを設定することができる）。プレフィクス毎の使用データコレクタ402は、ルーティングされたトラフィックのプレフィクスの合計数を知っており、ＢＧＰスピーカ403は可能なプレフィクスの合計数を知っている。
決定実行モジュール404が、設定された制御パラメータに基づいて、コンテンツプロバイダの出口トラフィックの一部の量を異なるサービスプロバイダに再割り当てするべきだと決定した場合（例えば、サービスプロバイダに関して制御パラメータが確立した安全閾値を超えたため等）、動作はブロック606に進み、コンテンツプロバイダの出口トラフィックのうち適切な量を１つのサービスプロバイダから別のサービスプロバイダに再割り当てする。より具体的には、決定実行モジュール404はＢＧＰスピーカ403をトリガし、所定のプレフィクスに関する出口トラフィックが、異なるサービスプロバイダにルーティングされるローカルなプリファレンスを有するように、コンテンツプロバイダルータ（複数可）305のルーティングテーブルを再構成する。その後、動作はブロック603に戻り、ブロック603〜606のデータ収集と解析ステップを定期的に反復する。決定実行モジュール404がブロック605で、コンテンツプロバイダの出口トラフィックの再割り当てが不必要であることを決定した場合（例えば、サービスプロバイダについて制御パラメータが確立した安全閾値を超えていない等）、動作はブロック603に戻り、ブロック603〜606のデータ収集と解析ステップを定期的に反復する。時々、ユーザが決定実行モジュール404の制御パラメータを変えたい場合、このパラメータをそのように変えることができる（例えば、動作を動作ブロック602に戻すことによって）。
コンピュータ実行可能命令を介して実施した場合、本発明の実施形態の出口トラフィックマネジャーの様々な要素は本質的には、動作を定義するソフトウェアコードである。実行可能命令又はソフトウェアコードは、読み取り可能媒体（例えばハードドライブ媒体、及び／又は、光媒体、EPROM、EEPROM、テープ媒体、カートリッジ媒体、フラッシュメモリ、ROM、メモリスティック等）から得ることができるか、又は、通信媒体（例えばインターネット）からデータ信号を介して通信することができる。実際、読み取り可能媒体は、情報を記憶又は転送できる任意の媒体を含んでいてよい。
図７は、上記の出口トラフィックマネジャーを実施するために本発明の一実施形態によって構成された例としてのコンピュータシステム700を示す。すなわち、コンピュータシステム700は、本発明の実施形態を実施することのできる例としてのシステムを含み、その中には、図４の例としての出口トラフィクマネジャーのモジュール401〜404を含む。中央演算処理装置（CPU）701はシステムバス702に結合する。CPU701は任意の汎用CPUであってよく、CPU701が上記の本発明の動作をサポートする限り、本発明はCPU701のアーキテクチャに制限されるものではない。CPU701は本発明の実施形態に従い、様々な倫理インストラクションを実行することができる。例えば、CPU701は図５と図６に関して説明した動作の例に従ってマシンレベルの命令を実行することができる。
コンピュータシステム700は好ましくは、ランダムアクセスメモリ（RAM）703を含み、これはSRAM、DRAM、SDRAM等であってよい。コンピュータシステム700は好ましくは、リードオンリーメモリ（ROM）704を含み、これはPROM、EPROM、EEPROM等であってよい。当業界でよく知られているように、RAM703とROM704は、図４の例としての出口トラフィックマネジャーのモジュール401〜404と関連づけられたデータ等、ユーザとシステムのデータとプログラムを保持する。
コンピュータシステム700はまた好ましくは、入力／出力（I／O）アダプタ705、通信アダプタ711、ユーザインタフェイスアダプタ708、ディスプレイアダプタ709を含む。特定の実施形態では、I／Oアダプタ705、及び／又は、ユーザインタフェイスアダプタ708、通信アダプタ711は、ユーザがコンピュータシステム700と相互作用し、図４の決定実行モジュール404の制御パラメータ等の情報を入力できるようにすることができる。
I／Oアダプタ705は好ましくは、ハードドライブ、コンパクトディスク（CD）ドライブ、フロッピーディスクドライブ、テープドライブ等のうち１つ又は２つ以上である記憶装置（複数可）706を、コンピュータシステム700に接続する。記憶装置は、RAM703が出口トラフィックマネジャーのデータを記憶することに関連づけられたメモリ要件に対して不十分であるときに使用することができる。通信アダプタ711は好ましくはコンピュータシステム700をネットワーク712に結合するように構成される（例えば、コンテンツプロバイダルータ（複数可）305を介して複数の異なるサービスプロバイダに結合する）。ユーザインタフェイスアダプタ708は、キーボード713、ポインティングデバイス707、マイクロフォン714等のユーザ入力装置、及び／又は、スピーカ（複数可）715等の出力装置をコンピュータシステム700に結合する。ディスプレイアダプタ709はCPU701が駆動し、ディスプレイデバイス710上のディスプレイを制御して、例えば、ユーザインタフェイスを表示する（例えば、ユーザからの入力情報を受信するか、及び／又は、複数の異なるサービスプロバイダの間の出口トラフィックの平衡に関する情報を出力する）。
本発明はシステム700のアーキテクチャに限定されないことを理解されたい。例えば、任意の適切なプロセッサベースのデバイスを使用することができ、その中にはパーソナルコンピュータ、ラップトップコンピュータ、コンピュータワークステーション、マルチプロセッササーバが含まれるが、これらに限定されるものではない。更に、本発明の実施形態は、特定用途向け集積回路（ＡＳＩＣ）又は超大規模集積回路（VLSI）上でも実施できる。実際、当業者であれば、本発明の実施形態にしたがって論理的に動作を実行することのできる任意の数の適切な構造を使用することができる。
本発明と本発明の利点を詳細に説明したが、付随する請求項が定義する本発明から離れることなく、様々な変更、代替、改変を行えることを理解されたい。更に、本出願は本明細書に記述されたプロセス、マシン、製造物、組成、手段、方法、ステップの特定の実施形態に限定することを意図するものではない。当業者であれば本開示から、現在存在するか又は後から開発され、本明細書に説明された対応する実施形態と実質的に同じ機能を実行するか又は実質的に同じ結果を達成できるプロセス、マシン、製造物、組成、手段、方法、ステップを使用できることが理解されよう。したがって、付随する請求項の範囲は、かかるプロセス、マシン、製造物、組成、手段、方法、ステップを含むことを目的としている。
本発明の実施形態を使用することのできる典型的なコンピュータネットワークの概略の構成図である。 ＢＧＰルータ等の典型的等メイン間ルータの概略の構成図である。 本発明の一実施形態を実施する例としてのシステムを示す図である。 本発明の一実施形態による、コンテンツプロバイダのための出口トラフィックマネジャーの例としての構成図である。 本発明の一実施形態による、複数のサービスプロバイダの間でコンテンツプロバイダからの出口トラフィックの割り当てを管理する例としてのフローチャートである。 本発明の一実施形態による、出口トラフィックマネジャーの動作に関する例としてのフローチャートである。 本発明の実施形態を実施できる例としてのコンピュータシステムを示す図である。
符号の説明
100 コンピュータネットワーク
101 ドメイン内ルータ
102 ドメイン間ルータ
103 共有媒体ネットワーク
104 ポイントツーポイントリンク
201 ルートプロセッサ
202 メモリ
202A ＢＧＰピアテーブル
202B ルーティングテーブル
203 バス
204A〜204C ネットワークインターフェースアダプタ
300 システム
301 通信ネットワーク
302 コンテンツプロバイダ
303 データストレージ
304 出口トラフィックマネジャー
305 ルータ
306 ルータ
307 ルータ
401 プレフィクス毎の使用データコレクタ
402 ルータインタフェイス使用データコレクタ
403 ＢＧＰスピーカ
404 決定実行
501,502A、502B、503,504,601,602 動作ブロック
700 コンピュータシステム
701 中央演算処理装置
702 システムバス
703 ランダムアクセスメモリ
704 リードオンリーメモリ
705 入力／出力アダプタ
706 記憶装置
707 ポインティングデバイス
708 ユーザインタフェイスアダプタ
709 ディスプレイアダプタ
710 ディスプレイデバイス
711 通信アダプタ
712 ネットワーク
713 キーボード
714 マイクロフォン

Claims (10)

  1. 通信ネットワーク301へのアクセスを提供する複数のサービスプロバイダに通信可能な状態で結合するコンテンツプロバイダ302と、
    前記複数のサービスプロバイダの各々のトラフィックボリュームに少なくとも部分的に基づいて、該複数のサービスプロバイダの各々にルーティングすべき前記コンテンツプロバイダの出口トラフィックの最適な平衡を決定するように動作可能な出口トラフィックマネジャー304とを含むシステム。
  2. 前記コンテンツプロバイダの出口トラフィックを前記複数のサービスプロバイダにルーティングするための少なくとも１つのルータ305を更に含む、請求項１に記載のシステム。
  3. 前記出口トラフィックマネジャーが、前記最適な平衡を達成するために前記少なくとも１つのルータを更新するよう動作可能である、請求項２に記載のシステム。
  4. 前記出口トラフィックマネジャーが、前記少なくとも１つのルータのルーティングテーブル202Bを更新するよう動作可能である、請求項３に記載のシステム。
  5. 前記出口トラフィックマネジャーが、前記トラフィックボリュームを反映するデータを収集するよう動作可能な少なくとも１つのデータコレクタモジュール401,402を含む、請求項１に記載のシステム。
  6. 複数のサービスプロバイダを使用して、通信ネットワーク301へのアクセスをコンテンツプロバイダ302に提供し（501）、この場合に、前記コンテンツプロバイダが、その出口トラフィックを前記複数のサービスプロバイダを介してクライアントに通信し、
    各サービスプロバイダに関するトラフィックボリュームデータを収集し（502）、
    該収集したトラフィックボリュームデータに少なくとも部分的に基づいて、前記複数のサービスプロバイダの間で前記コンテンツプロバイダからの出口トラフィックの割り当てを変えるか否かを決定する（503）、
    という各ステップを含む方法。
  7. 割り当てを変えるよう決定された場合に、前記出口トラフィックが所望の方法で前記複数のサービスプロバイダの間で割り当てられるように、前記コンテンツプロバイダから前記サービスプロバイダへ出口トラフィックをルーティングする少なくとも１つのルータ305を再構成するステップ（504）を更に含む、請求項６に記載の方法。
  8. 出口トラフィックマネジャー304であって、
    少なくとも１つのルータ305が、コンテンツプロバイダ302から、通信ネットワーク301にアクセスを提供する複数のサービスプロバイダの各々にルーティングした出口トラフィックのボリュームを反映するデータを収集する少なくとも１つのデータコレクタモジュール401,402と、
    前記収集されたデータに少なくとも部分的に基づいて、前記少なくとも１つのルータのルーティング・ストラテジーを更新して前記複数のサービスプロバイダの間で出口トラフィックの割り当てを変えるべきか否かを決定するための決定実行モジュール404と
    を含む、出口トラフィックマネジャー304。
  9. 前記少なくとも１つのデータコレクタモジュールが、
    前記コンテンツプロバイダの出口トラフィックを前記コンテンツプロバイダから前記複数のサービスプロバイダにルーティングする少なくとも１つのルータの、インタフェイス毎のトラフィックボリュームを反映するインタフェイス使用データを収集する、ルータインタフェイス使用データコレクタモジュール402と、
    前記コンテンツプロバイダの出口トラフィックの宛先になっているプレフィクス毎のトラフィックボリュームを反映する、プレフィクス毎の使用データを収集するように動作可能なプレフィクス毎の使用データコレクタモジュール401と
    を含む、請求項８に記載の出口トラフィックマネジャー。
  10. コンテンツプロバイダ302からの出口トラフィックをルーティングするための少なくとも１つのコンテンツプロバイダルータ305を実施し、該少なくとも１つのコンテンツプロバイダルータが、通信ネットワーク301に対するアクセスを前記コンテンツプロバイダに提供する複数のサービスプロバイダの各々に対して少なくとも１つのインタフェイスを有し、及び前記複数のサービスプロバイダのうちどのサービスプロバイダが前記コンテンツプロバイダの出口トラフィックをルーティングするかを決定する元となるルーティングテーブル202Bを含み、
    前記少なくとも１つのコンテンツプロバイダルータから、前記複数のサービスプロバイダの各々に向けられた出口トラフィックのボリュームを監視し、
    前記少なくとも１つのコンテンツプロバイダルータから前記複数のサービスプロバイダのうち任意の１つのサービスプロバイダへの出口トラフィックのボリュームが、対応する閾値を超えたか否かを決定し（605）、
    前記複数のサービスプロバイダのうち１つのサービスプロバイダへの出口トラフィックのボリュームが対応する閾値を超えたと決定された場合に、前記複数のサービスプロバイダの間で前記コンテンツプロバイダの出口トラフィックを再割り当てするために、前記少なくとも１つのコンテンツプロバイダのルータのルーティングテーブルを更新する（606）、
    という各ステップを含む方法。
JP2004279449A 2003-09-26 2004-09-27 多数のサービスプロバイダ間で出口トラフィック負荷平衡を制御する方法及びシステム Pending JP2005110261A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/672,918 US20050071469A1 (en) 2003-09-26 2003-09-26 Method and system for controlling egress traffic load balancing between multiple service providers

Publications (1)

Publication Number Publication Date
JP2005110261A true JP2005110261A (ja) 2005-04-21

Family

ID=34194877

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004279449A Pending JP2005110261A (ja) 2003-09-26 2004-09-27 多数のサービスプロバイダ間で出口トラフィック負荷平衡を制御する方法及びシステム

Country Status (3)

Country Link
US (1) US20050071469A1 (ja)
EP (1) EP1519533A1 (ja)
JP (1) JP2005110261A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016517240A (ja) * 2013-04-16 2016-06-09 フェイスブック，インク． サーバ管理されたルーティングシステム

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7571239B2 (en) * 2002-01-08 2009-08-04 Avaya Inc. Credential management and network querying
US7426577B2 (en) * 2003-06-19 2008-09-16 Avaya Technology Corp. Detection of load balanced links in internet protocol netwoks
WO2005109153A2 (en) * 2004-05-04 2005-11-17 Nexthop Technologies, Inc. Method and apparatus for bgp peer prefix limits exchange with multi-level control
US20060083215A1 (en) * 2004-10-19 2006-04-20 James Uttaro Method and apparatus for providing a scalable route reflector topology for networks
US20060198322A1 (en) * 2005-03-03 2006-09-07 Susan Hares Method and apparatus for BGP peer prefix limits exchange with multi-level control
US7961625B2 (en) * 2005-08-01 2011-06-14 Limelight Networks, Inc. Routing under heavy loading
US7706280B2 (en) * 2005-08-01 2010-04-27 Limelight Networks, Inc. Heavy load packet-switched routing
US20070061663A1 (en) * 2005-08-12 2007-03-15 Loyd Aaron J Method and system for identifying root cause of network protocol layer failures
CN1917511A (zh) * 2005-08-16 2007-02-21 华为技术有限公司 一种流量工程的实现方法和装置
US8837275B2 (en) 2006-02-09 2014-09-16 International Business Machines Corporation System, method and program for re-routing internet packets
WO2008016634A2 (en) * 2006-08-02 2008-02-07 Tellytopia, Inc. System, device, and method for delivering multimedia
US8141164B2 (en) 2006-08-21 2012-03-20 Citrix Systems, Inc. Systems and methods for dynamic decentralized load balancing across multiple sites
US20080278582A1 (en) * 2007-05-07 2008-11-13 Sentinel Ave Llc Video Fusion Display Systems
US8739123B2 (en) * 2007-05-28 2014-05-27 Google Inc. Incorporating gadget functionality on webpages
US7809785B2 (en) * 2007-05-28 2010-10-05 Google Inc. System using router in a web browser for inter-domain communication
US20090168648A1 (en) * 2007-12-29 2009-07-02 Arbor Networks, Inc. Method and System for Annotating Network Flow Information
US8706878B1 (en) * 2008-08-21 2014-04-22 United Services Automobile Association Preferential loading in data centers
US8767734B1 (en) * 2008-10-07 2014-07-01 BCK Networks, Inc. Stream basis set division multiplexing
US8515910B1 (en) * 2010-08-26 2013-08-20 Amazon Technologies, Inc. Data set capture management with forecasting
US20120144044A1 (en) * 2010-12-06 2012-06-07 Verizon Patent And Licensing Inc. System for and method of dynamically deploying servers
EP2525533B1 (en) * 2011-05-16 2014-02-26 Alcatel Lucent Method and apparatus for providing bidirectional communication between segments of a home network
US8885462B2 (en) * 2011-12-03 2014-11-11 Cisco Technology, Inc. Fast repair of a bundled link interface using packet replication
US8831019B2 (en) 2012-05-18 2014-09-09 Renesys Path reconstruction and interconnection modeling (PRIM)
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US10038626B2 (en) 2013-04-16 2018-07-31 Amazon Technologies, Inc. Multipath routing in a distributed load balancer
US10069903B2 (en) * 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
US9553809B2 (en) 2013-04-16 2017-01-24 Amazon Technologies, Inc. Asymmetric packet flow in a distributed load balancer
US9762707B2 (en) * 2013-06-24 2017-09-12 International Business Machines Corporation Management of outbound transactions to an enterprise information system
CN104348732B (zh) * 2013-07-25 2018-09-07 华为技术有限公司 拓扑结构发现方法及装置
US9338223B2 (en) * 2013-08-14 2016-05-10 Verizon Patent And Licensing Inc. Private cloud topology management system
CN104426936A (zh) * 2013-08-22 2015-03-18 中兴通讯股份有限公司 一种负载均衡方法及系统
WO2015084151A1 (en) * 2013-12-06 2015-06-11 Mimos Berhad Method and system for access point load balancing
US9621468B1 (en) 2014-12-05 2017-04-11 Amazon Technologies, Inc. Packet transmission scheduler
FR3030168B1 (fr) * 2014-12-15 2017-01-13 Thales Sa Procede de choix d'au moins un service et dispositif associe
US9787560B2 (en) 2015-06-04 2017-10-10 Microsoft Technology Licensing Llc Effective service node traffic routing
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US10645008B1 (en) 2018-12-06 2020-05-05 Verizon Digital Media Services Inc. Predictive Anycast traffic shaping
US11252090B1 (en) * 2019-12-04 2022-02-15 Juniper Networks, Inc Systems and methods for predicting future traffic loads of outgoing interfaces on network devices
US11316765B2 (en) * 2020-02-12 2022-04-26 Kyndryl, Inc. Load balancing across bandwidth carrying circuits

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7349994B2 (en) * 2000-10-17 2008-03-25 Avaya Technology Corp. Method and apparatus for coordinating routing parameters via a back-channel communication medium
US7080161B2 (en) * 2000-10-17 2006-07-18 Avaya Technology Corp. Routing information exchange
US20030120769A1 (en) * 2001-12-07 2003-06-26 Mccollom William Girard Method and system for determining autonomous system transit volumes
US7197040B2 (en) * 2002-07-01 2007-03-27 Lucent Technologies Inc. System and method for optimally configuring border gateway selection for transit traffic flows in a computer network
US20040073640A1 (en) * 2002-09-23 2004-04-15 Cricket Technologies Llc Network load management apparatus, system, method, and electronically stored computer product

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016517240A (ja) * 2013-04-16 2016-06-09 フェイスブック，インク． サーバ管理されたルーティングシステム

Also Published As

Publication number Publication date
US20050071469A1 (en) 2005-03-31
EP1519533A1 (en) 2005-03-30

Similar Documents

Publication Publication Date Title
JP2005110261A (ja) 多数のサービスプロバイダ間で出口トラフィック負荷平衡を制御する方法及びシステム
US10715414B2 (en) Network communication methods and apparatus
Fortz et al. Traffic engineering with traditional IP routing protocols
US8503310B2 (en) Technique for policy conflict resolution using priority with variance
Quoitin et al. Interdomain traffic engineering with BGP
EP2911348B1 (en) Control device discovery in networks having separate control and forwarding devices
US6084858A (en) Distribution of communication load over multiple paths based upon link utilization
Li et al. An effective path load balancing mechanism based on SDN
US7961638B2 (en) Routing method and system
US8824286B2 (en) Network aware global load balancing system and method
Bressoud et al. Optimal configuration for BGP route selection
JP4212566B2 (ja) Ｉｐ網内配分用ルート選択方法及び装置
CN102014049B (zh) 用于网络中功率受限通信的方法和系统
Kotronis et al. Stitching inter-domain paths over IXPs
JP6510115B2 (ja) 負荷分散を実現するための方法、装置、およびネットワークシステム
US20140075048A1 (en) Apparatus, System, and Method for Cloud-Assisted Routing
US10924408B2 (en) System and method for optimizing traffic in packet-switched networks with internet exchanges
Altın et al. Intra-domain traffic engineering with shortest path routing protocols
EP3090528A1 (en) Network communication methods and apparatus
JP5943431B2 (ja) ネットワーク、データ転送ノード、通信方法およびプログラム
JP2005057487A (ja) 複数経路を選択する経路制御装置、経路選択方法およびそのプログラムと記録媒体
US11483210B2 (en) Interdomain path calculation based on an abstract topology
Lin et al. Proactive multipath routing with a predictive mechanism in software‐defined networks
Dey et al. CAR: Cloud-assisted routing
Viji Dynamic Routing Mechanism to Reduce Energy Consumption in a Software-Defined Network