JP5137941B2 - ネットワークの負荷バランシングと過負荷制御 - Google Patents

Description

本発明は、一般に通信ネットワークに関し、より詳細にはＩＰマルチメディア・サブシステムＩＭＳネットワークなど、セッション開始プロトコルＳＩＰベースのネットワークと、他のタイプの通信ネットワークにおいて使用するための負荷バランシング技法と過負荷制御技法に関する。

セッション開始プロトコルＳＩＰは、急速に通信ネットワークにおいてユーザ間でマルチメディア・セッションを確立し、修正し、終了するためのデファクト・シグナリング・プロトコルになりつつある。ＳＩＰは、J. Rosenberg他、「SIP: Session Initiation Protocol」、Internet Engineering Task Force（IETF）RFC 3261、2002年6月に記載されており、これは、参照により本明細書中に組み込まれている。ＳＩＰは、ＩＰマルチメディア・サブシステムＩＭＳのために採用されてきてもおり、このＩＰマルチメディア・サブシステムは、第３世代パートナーシップ・プロジェクト３ＧＰＰによって定義されるモバイル・サービスおよび固定サービスについての次世代コア・ネットワーク・アーキテクチャである。

ＳＩＰメッセージを処理し、転送するネットワーク要素は、ＳＩＰの専門用語においてはプロキシ・サーバと呼ばれ、ＩＭＳの専門用語においては呼出しセッション制御ファンクションＣＳＣＦと呼ばれる。３ＧＰＰは、３つのタイプのＣＳＣＦ要素を、すなわちユーザに対するインターフェースであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、異なる管理ドメインにおいて他のサーバに対するインターフェースを提供する問い合わせＣＳＣＦ（Ｉ−ＣＳＣＦ）と、アプリケーション・サーバに対して登録を取り扱い、ポリシーを強制し、インターフェースを提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）とを定義する。そのようなネットワーク要素は、本明細書中においてはＳＩＰ／ＩＭＳサーバと称され、これらおよび他のネットワーク要素を備えるシグナリング・ネットワークは、ＳＩＰベースのネットワークと称される。

ＳＩＰベースのネットワークにおける高レベルの性能を達成するためには、ネットワーク要素にわたってトラフィック負荷を均一に分布させることが重要である。残念ながら、従来の負荷バランシング技法は、多くの場合に、ＳＩＰのコンテキストにおいて使用するためにはあまり適していないこともあり、望ましい性能レベルを提供できない可能性がある。

ＳＩＰベースのネットワークにおける関連した問題は、過負荷制御に関与している。他のネットワーク要素と同様に、ＳＩＰ／ＩＭＳサーバは、トラフィック需要が、その使用可能なリソース、たとえば、その使用可能な処理リソースを超過するときに過負荷になる可能性がある。オーバープロビジョニングを用いてさえも、過負荷は、「フラッシュ・クラウド」効果に起因した一時的トラフィック・サージ、ノードまたはリンクの故障、質の悪い経路指定、メインテナンスおよびサービス拒否攻撃に起因したトラフィック迂回などを含めて、さまざまな理由のために依然として起こる可能性がある。

さまざまな技法が、通信ネットワークにおいて過負荷制御に対処するために開発されてきている。これらは、たとえば、Ｍ／Ｍ／１キューイング・システムに基づいた過負荷制御技法と、シグナリング・システム７（ＳＳ７）のコンテキストにおいて使用するために開発された過負荷制御技法とを含んでいる。

残念ながら、これらおよび他の従来の過負荷制御技法は、ＳＩＰ性能に対する過負荷の定量的な影響に対処することができず、ＳＩＰベースのネットワークにおいて過負荷を取り扱うための特定のアプローチを提供することができず、これらは、多くの場合には、メッセージング・サービスおよびシグナリング・トポロジの観点から、より複雑である。

したがって、とりわけＳＩＰベースのネットワークにおいては、改善された負荷バランシング技法と過負荷制御技法についての必要性が存在することは、明らかである。
J. Rosenberg他、「SIP: Session Initiation Protocol」、Internet Engineering Task Force（IETF）RFC 3261、2002年6月 S. Blake他、「An architecture for differentiated services」、IETF RFC 2475、1998年、12月 J. Nagle、「Congestion control in IP/TCP internetworks」、IETF RFC 896、1984年1月 米国特許第４，９７４，２５６号、B.L. Cry他、「Load balancing and overload control in a distributed processing telecommunication system」、1990年11月27日に発行 S. Kasera他、「Fast and robust signaling overload control」、International Conference on Network Protocols、2001年 S. Floyd他、「Random early detection gateways for congestion avoidance」、IEEE Transactions on Networking、1巻、No.4、397〜413頁、1993年8月

例示の実施形態における本発明は、ＳＩＰベースのネットワーク、または他のタイプの通信ネットワークにおける負荷バランシングと過負荷制御についての改善された技法を提供している。

本発明の一態様に従って、第１のサーバが、第１のサーバとターゲット・サーバとの間のそれぞれ第１の経路と第２の経路に関連する少なくとも第１のダウンストリーム・サーバと第２のダウンストリーム・サーバとを含む、ネットワークのダウンストリーム・サーバから、それぞれのダウンストリーム・サーバについての輻輳測度を含むフィードバック情報を受信する負荷バランシング技法が、提供される。輻輳測度は、たとえば、プロセッサ利用率測度、メッセージ処理負荷、バッファ占有測度、メッセージ処理遅延、または輻輳を示す他の任意のタイプの情報、あるいはそれらの組合せとすることができる。フィードバック情報は、たとえば、拡張ヘッダの形で符号化される１つまたは複数のＳＩＰ１００の応答メッセージの形で、ダウンストリーム・サーバから第１のサーバへと送信することができる。第１のサーバにおけるメッセージ経路指定プロセスは、ダウンストリーム・サーバの輻輳測度の間のアンバランスについて補償するために受信されたフィードバック情報に基づいて調整される。例示の実施形態におけるその調整は、メッセージ経路指定プロセスが、広く行われているネットワーク状態を追跡することを保証するために動的であり、それによってネットワークにおける容量利用率を改善している。

フィードバック情報の上記された受信と、メッセージ経路指定プロセスの関連する調整は、ネットワークにおける各サーバにおいて反復することができる。換言すれば、各サーバは、ネットワークの他のサーバに対して第１のサーバとして動作することができる。

フィードバック情報は、第１のサーバと、ターゲット・サーバとの間の第１または第２の経路における複数のサーバの輻輳測度のうちの最高の輻輳測度を含むことができる。

第１および第２のダウンストリーム・サーバのうちの一方は、ターゲット・サーバそれ自体、または第１のサーバの最も近い隣接サーバとすることができる。

メッセージ経路指定プロセスは、たとえば、第１および第２の経路上で経路指定されるべき与えられた１組のメッセージの相対的パーセンテージを指定する経路指定情報を調整することにより調整することができる。経路指定情報は、経路指定テーブルまたは他の適切なデータ構造に記憶されるそれぞれ第１の経路と第２の経路についての少なくとも第１の経路指定確率と第２の経路指定確率とを含むことができる。

本発明の別の態様に従って、第１のサーバが、第１のサーバとターゲット・サーバとの間の経路に関連する、ネットワークの少なくとも１つのダウンストリーム・サーバから、そのダウンストリーム・サーバの輻輳測度を含むフィードバック情報を受信する過負荷制御技法が提供される。第１のサーバは、フィードバック情報に基づいてユーザ・エージェントに対して配信するためのブロッキング・メッセージを生成する。

ダウンストリーム・サーバは、ターゲット・サーバそれ自体、または第１のサーバの最も近い隣接サーバとすることができる。第１のサーバは、ネットワークのイングレス・サーバ、またはダウンストリーム・サーバの最も近いアップストリーム隣接サーバであるコア・ネットワーク・サーバとすることができる。

この場合にも、以上の第１のサーバに関連するオペレーションは、ネットワークの他のサーバにおいて反復することができる。したがって、負荷バランシング技法および過負荷制御技法は、いかなる中央集中コントローラも必要とせずに、分散方式で実施することができる。

本発明の負荷バランシング技法と、過負荷制御技法とは、単独で、あるいは組み合わせて使用することができる。本発明の例示の実施形態は、両方の技法を組み合わせて、本明細書では「過負荷−安全ＳＩＰ」またはＯＳ−ＳＩＰと称される拡張通信プロトコルを提供する。有利なことに、ＯＳ−ＳＩＰは、より高い容量、ならびに低減されたリング遅延および呼出しセットアップ時間も提供しながら、従来のＳＩＰによって一般的に示される輻輳崩壊問題を回避する。したがってＯＳ−ＳＩＰは、トラフィック負荷とは無関係に、著しい性能改善をもたらし、高信頼性のサービスを提供する。

本発明についてのこれらおよび他の特徴および利点は、添付の図面と以下の詳細な説明からさらに明らかになるであろう。

本発明は、例示のＳＩＰベースのネットワークと、関連する負荷バランシング技法および過負荷制御技法とに関連して以下に説明されることになる。しかしながら、本発明は、例示の実施形態の特定の負荷バランシング技法または過負荷制御技法と共に使用するようにも、特定の任意のタイプのネットワーク、または他の通信ネットワークと共に使用するようにも限定されないことを理解すべきである。開示されている技法は、多種多様な他のシステムと共に、そして非常に多くの代替アプリケーションにおいて使用するために適している。

図１は、本発明の一実施形態が実施されるＳＩＰベースのネットワーク１００の一部分を示している。示されているネットワーク１００の一部分は、第１のエンド・ユーザに関連するユーザ・エージェント・クライアントＵＡＣ１０２と、第１のサーバ１０４と、第２のサーバ１０６と、第２のエンド・ユーザに関連するユーザ・エージェント・サーバＵＡＳ１０８を含む通信経路を含んでいる。ネットワーク１００においては、エンド・ユーザは、ユーザ・エージェントＵＡと称されるそれぞれの論理エンティティによって処理される。そのような各ＵＡは、ＵＡＣもＵＡＳも備える。図１に示されているネットワーク１００の一部分は、説明の簡単のためにかなり簡略化され、典型的なそのようなネットワークは、多数のユーザ・エージェントにサービスする多数のサーバを含むことになる。また、本明細書中で使用されるような用語「経路ｐａｔｈ」は、ネットワークの複数のサーバに関与する任意の通信構成を包含するように広範に解釈されるように意図され、どのような特定のタイプのリンク・セットアップまたは通信プロトコルも必要とするものとみなされるべきではない。したがって、与えられた経路は、通信プロトコルに従ってセットアップすることもできるが、それは必須ではない。

ＵＡＣからＵＡＳへのＳＩＰメッセージは、要求と呼ばれ、逆方向のこれらＳＩＰメッセージは、応答と呼ばれる。この特定の例においては、ＵＡＣ１０２に対応する第１のエンド・ユーザは、要求を送信する（たとえば、呼出しを開始する）呼出し元を表すが、ＵＡＳ１０８に対応する第２のエンド・ユーザは、呼出し元からの要求を受信し、それに応じて応答する呼出し先である。要求と応答は、それぞれ実線１１０と破線１１２によって示されている。明らかなように、ＵＡＣからＵＡＳへの与えられた要求は、サーバの主要な目的がエンド・ユーザに対して、より近くにメッセージを経路指定することである複数のサーバを横切ることができる。サーバは、電子メールアドレスに類似したＳＩＰアドレスからＩＰアドレスを解明するドメイン名システムＤＮＳを利用することができる。

ＳＩＰプロトコルは、複数のレイヤへと構成される。最下部レイヤは、現在ではユーザ・データグラム・プロトコルＵＤＰまたは伝送制御プロトコルＴＣＰを利用することができるトランスポート・レイヤＴＲである。ＳＩＰの中心であるトランザクション・レイヤは、トランスポート・レイヤのサービスを使用し、ＩＰベースのネットワークを介して１つのＳＩＰエンティティから別のものへとメッセージを確実に配信し、このＩＰベースのネットワークは、以前に指摘されるように、一般的に図には明示的に示されていない多数のサーバを含むことになる。特に、トランザクション・レイヤは、メッセージ再送信を提供し、応答を要求に対してマッチングさせ、タイムアウトを容易にする。トランザクション・レイヤは、クライアント・トランザクションＣＴ部分とサーバ・トランザクションＳＴ部分とを含む。クライアント・トランザクションは、トランザクション・ユーザまたはコアであるその上位レイヤから要求を受信し、その要求をそのピア・サーバ・トランザクションに対して確実に送信する。クライアント・トランザクションは、メッセージがそのピアによって受信されることを保証するために、タイマおよび再送信を利用する。サーバ・トランザクションは、トランスポート・レイヤから要求を受信し、そのコアに対してそれらを配信する。さらに、サーバ・トランザクションはまた、そのピア・クライアント・トランザクションに対して適切な応答を送信することにより再送信のフィルタリングも提供する。クライアント・トランザクションとサーバ・トランザクションとの間の対話は、１組の有限状態機械ＦＳＭによって管理される。

ＳＩＰベースのネットワーク１００においては、２つのタイプのサーバ、すなわちステートレス・サーバ１０４とステートフル・サーバ１０６とが存在する。ステートレス・サーバは、トランザクション・レイヤを含まない。そのファンクションは、単にネクスト・ホップに対してメッセージを転送することだけである。他方、ステートフル・サーバは、トランザクション・レイヤを終了し、それによって追加メッセージを生成することもできる。たとえば、そのアップストリーム隣接サーバから要求を受信するとすぐに、ステートフル・サーバは、エンド・ユーザにコンタクトすべき適切なロケーションを決定するために、複数の宛先に対して複数の要求を生成することができ、すなわち「フォーキング」として知られている技法である。

図２は、図１のネットワーク１００など、ＳＩＰベースのネットワークのネットワーク要素の間の呼出しフローを示す図である。この例においては、ＵＡ Ａと示されている第１のＵＡが、第２のＵＡ、ＵＡ Ｂに対する呼出しを開始することが仮定される。ＵＡ ＡとＵＡ Ｂとの間のメッセージは、サーバＡとサーバＢで示されている２つのサーバを通過する。

ＵＡ ＡがＵＡ Ｂに対する呼出しを開始するときに、ＵＡ Ａは、一般的にＵＡ Ａのドメインにサービスするアウトバウンド・サーバ（サーバＡ）に対してＵＡ ＢのＳＩＰアドレスを含むＩＮＶＩＴＥ要求を送信する。ＩＮＶＩＴＥ要求はまた、ＳＩＰによって必要とされる他の関連情報、ならびにベアラ・セッションについて必要とされるメディア・タイプやコーデック・タイプなどの追加情報も含んでいる。ＩＮＶＩＴＥ要求を受信するとすぐに、サーバＡは、もしかすると、ＵＡ Ｂにサービスするインバウンド・サーバ（サーバＢ）の所在を見出すためにＤＮＳクエリ（図示されず）を実行する。次いで、サーバＡは、ＩＮＶＩＴＥ要求をサーバＢに対して転送する。さらに、サーバＡは、ＩＮＶＩＴＥ処理が進行中であることを指し示すために１００Ｔｒｙｉｎｇ応答をＵＡ Ａに対して送信する。

サーバＢが混み合っているため、ＩＮＶＩＴＥ要求が失われるものと仮定する。トランスポート・レイヤが信頼できない（たとえば、ＵＤＰ）場合には、サーバＡにおけるトランザクション・レイヤは、１００Ｔｒｙｉｎｇのないことからの損失を検出し、ＩＮＶＩＴＥ要求を再送信することになる。最終的には、ＩＮＶＩＴＥ要求が宛先に到達するときに、ＵＡ Ｂは、１８０Ｒｉｎｇｉｎｇ応答を用いて応答する。呼出し先がその呼出しに応答しようと決定する場合、２００ＯＫ応答は、呼出し元に対して送信され、この呼出し元は、ＡＣＫを返すことにより、２００ＯＫ応答を確認することができる。このポイントにおいて、ベアラ・チャネルは、確立され、呼出し元と呼出し先との間の通信または他のデータ転送は、開始することができる。セッションの終わりには、いずれのパーティも、ＢＹＥ要求を送信することによりセッションを終了することができる。この例においては、ＵＡ Ａは、ＵＡ Ｂからの２００ＯＫ応答によって肯定応答されるＢＹＥ要求を送信することにより、セッションを終了する。

次に、ＳＩＰベースのネットワークが過負荷になるときに生ずる可能性のある輻輳崩壊問題について、図３を参照して説明することにする。ＳＩＰメッセージ損失は、主として、ＩＰトランスポート・ネットワークにおける、あるいはサーバにおける輻輳のために起こる可能性がある。制御トラフィックとデータ・トラフィックの両方を搬送するうまく設計されたネットワークにおいては、ＳＩＰトラフィックには、ずっとより支配的であるが、あまりクリティカルではないベスト・エフォート・データ・トラフィックよりも高い優先順位が与えられるべき可能性が高いため、ＩＰトランスポート・ネットワークにおけるＳＩＰメッセージ損失は、非常に低いものと予想される可能性がある。これは、たとえば、S. Blake他、「An architecture for differentiated services」、IETF RFC 2475、1998年12月に記載されているように、差別化サービスを使用することにより、達成することができる。したがって、サーバ輻輳に起因したメッセージ損失は、ＳＩＰベースのネットワークにおいてずっとより顕著な役割を果たす可能性が高いことが予想される。

ＳＩＰは、メッセージの信頼できる配信を保証するために、ＡからＫで示されているさまざまなタイマを使用する。サーバが混み合っているときに、タイマは、より多くの輻輳を引き起こす可能性がある、より多くの再送信をトリガーする可能性がある。図３は、サーバが過負荷制御の影響を受けないときの、提供負荷の関数としてのサーバの呼出しスループット性能の一例を示している。そのプロットは、サーバにおける２つのメッセージ・バッファ・サイズ（Ｂ＝１０００メッセージおよびＢ＝３００００メッセージ）を用いて示されている。見て取れるように、過負荷制御が存在しないときには、提供負荷がサーバの容量を超過するときに呼出しスループットは、かなり低下してしまう可能性がある。さらに、呼出しスループット性能は、増大するメッセージ・バッファ・サイズと共に悪くなる。この動作は、データ・トラフィックについての輻輳崩壊と整合している。たとえば、J. Nagle、「Congestion control in IP/TCP internetworks」、IETF RFC 896、1984年1月を参照されたい。

本発明は、図３に示されている輻輳崩壊問題を回避する技法を提供する。例示の一実施形態においては、これらの技法は、負荷バランシング技法と、過負荷制御技法の両方を含んでいる。しかしながら、本明細書中において説明される負荷バランシング技法と過負荷制御技法は、互いに別々に使用することもできることを理解すべきである。すなわち、本発明の与えられた一実施形態は、負荷バランシングだけを実施することができるが、過負荷制御を実施することができず、あるいはその逆の場合も同様である。

本発明に関連して使用するために適しているいくつかの例示の過負荷制御アルゴリズムについて、次に説明することにする。例証の目的のために、アルゴリズムは、サーバのネットワーク上ではなくて単一のサーバにおいて動作するものとして説明される。占有アルゴリズムＯＣＣおよび受け入れレートアルゴリズムとして知られているこれらのアルゴリズムのうちの第１の２つについての従来の態様は、それぞれ、B.L. Cry他の名前で「Load balancing and overload control in a distributed processing telecommunication system」という名称で1990年11月27日に発行された米国特許第４，９７４，２５６号と、S. Kasera他、「Fast and robust signaling overload control」、International Conference on Network Protocols、2001年に説明されている。しかしながら、そのようなアルゴリズムは、これまでＳＩＰのコンテキストにおいて使用するためには適合されてきてはいない。説明されるべき最終的な過負荷制御アルゴリズムは、ＳＩＰベースのネットワークにおいて過負荷制御を提供するために特によく適していると本発明者等が決定している、受け入れレートアルゴリズムの改善されたバージョンである。本発明の実施形態は、占有アルゴリズム、受け入れレートアルゴリズム、改善された受け入れレートアルゴリズム、あるいは別の過負荷制御アルゴリズムを利用することができることを理解すべきである。

占有アルゴリズムにおいては、サーバに対する着信呼出しは、受け入れられる呼出しのフラクションを示す変数ｆによって制御される。したがって、新しい呼出しが、確率ｆで受け入れられ、あるいは同様な意味合いで、確率１−ｆでブロックされる。このアルゴリズムをＳＩＰのコンテキストに適用するに際して、ＩＮＶＩＴＥ要求は、確率ｆで受け入れることができるが、他のメッセージは、サーバにおけるメッセージ・バッファが一杯でない限りは、常に受け入れられる。現在のシステム過負荷状態に基づいて、占有アルゴリズムの目的は、ｆを動的に調整して、高い呼出しスループットを維持することである。過負荷状態は、プロセッサ利用率、ρに基づいており、このプロセッサ利用率は、τ秒ごとに定期的にプローブされる。ｎ番目ごとにプローブされたエポックにおいて、平均プロセッサ利用率

は、アップデートされ、ターゲット利用率ρ_ｔａｒｇと比較される。平均利用率は、以前のｋ個のエポック上の移動平均ＭＡ

として、あるいは指数関数的重み付けされた移動平均ＥＷＭＡ

によって計算することができ、ここで０＜β＜１である。

占有アルゴリズムの基本的アイデアは、

である場合に、ｆを増大させ、そうでない場合にはそれを減少させることである。ｆ（ｎ）は、現在のエポックｎにおいて新しくアップデートされるｆを示すが、ｆ（ｎ−１）は、エポックｎ−１においてアップデートされるｆを示すものとしよう。各エポックにおいてｆをアップデートするアルゴリズムは、以下のように記述される。

式中で、ｆ_ｍｉｎは、受け入れられるトラフィックの最小フラクションについてのしきい値を表す。倍数因子φは、

によって与えられ、式中で、φ_ｍａｘは、１つのエポックから次のエポックへのｆにおける最大の可能性のある乗法的増大を定義するものである。

以上で引用されたS. Kasera他の参考文献においては、ρが１を超過することができないため、占有アルゴリズムは、システムが過負荷にされるときに、１０％よりも多くｆを減少させることはできず、したがって、そのアルゴリズムは、突然のトラフィック・サージの下であまりにもゆっくりと反応する可能性がある。受け入れレートアルゴリズムの基本的アイデアは、

を

の代わりに使用することであり、式中で、

は、システムへの平均呼出し受け入れレートを表す。ターゲット受け入れレートα_ｔａｒｇは、α_ｔａｒｇ＝μρ_ｔａｒｇに設定することができ、式中で、μは、システム呼出し搬送容量であり、このシステム呼出し搬送容量は、

によって推定することができる。α_ｔａｒｇは、

についての平均よりもスムーズな平均を有するＥＷＭＡによってアップデートされることが示唆される。その受け入れレートアルゴリズムは、以下の倍数因子を使用している。

本発明者等は、占有アルゴリズムと受け入れレートアルゴリズムの従来の実施形態は、それらが、完了していない作業をシステムにおいて考慮に入れない点で問題があることを認識している。とりわけ、

である場合、そのときにはメッセージ・キューの内容とは独立にｆ（ｎ）＝ｆ（ｎ−１）である。その代わりに、

であるときには、本発明者等は、キューの内容があまりにも高い場合に、ｆ（ｎ）を減少させたいと思い、キューの内容があまりにも低い場合には、ｆ（ｎ）を増大させたいと思う。第２の観察は、上記アルゴリズムが、ターゲット・パラメータと比較されるべき変数の間の差（正または負）の同じ量についてｆ（ｎ）を減少させるよりもｆ（ｎ）を増大させる傾向があることである。したがって、本発明者等は、以下のように改善された受け入れアルゴリズムのためにφを修正する。

式中で、ｑは、メッセージ到着のたびごとにＥＷＭＡを使用してアップデートされるメッセージの数の形での平均キューの長さであり、ｑ_ｔａｒｇは、キュー・ターゲットであり、Ｎは、呼出し当たりのメッセージの平均の数である。メッセージ到着ごとの平均キューの長さのアップデーティングは、１つのタイプのイベント・ドリブン・アップデーティングとみなすことができる。そのようなイベント・ドリブン・アップデーティングの他の例については、S. Floyd他、「Random early detection gateways for congestion avoidance」、IEEE Transactions on Networking、1巻、No.4、397〜413頁、1993年8月に説明されている。

ＳＩＰ環境における先行する過負荷制御アルゴリズムの性能を評価するために、人は、図１のステートフル・サーバ１０６など、ＳＩＰの完全なトランザクション・レイヤを実施するサーバをシミュレートすることができる。とりわけ、新しい要求または応答が、処理されるときに、クライアント・トランザクションが、作成され、その状態は、後でＦＳＭによって管理される。メッセージが要求であるか、または応答であるかと、メッセージ・タイプが、ＩＮＶＩＴＥであるか、または非ＩＮＶＩＴＥであるかに応じて、ＳＩＰにおいては、４つのタイプのＦＳＭが存在する。

図４は、図１のサーバ１０６などのステートフル・サーバの形で実施することができるキューイング・システム４００の構造を示している。本システム４００は、メッセージ・バッファ４０２と、タイマ・バッファ４０４と、中央演算処理装置ＣＰＵ４０６として例示的に示されているプロセッサとを備える。ステートレス・サーバについての等価システムは、ステートレス・サーバが、フォワーダとして振る舞うようなタイマ・バッファを有してはいない。着信ＩＮＶＩＴＥメッセージは、使用可能なスペースが存在する場合には、メッセージ・バッファにキューされる。本発明者等は、ＦＩＦＯキューの規律を仮定するが、もちろん、他を使用することもできる。ＣＰＵ４０６は、キューの先頭に置いてメッセージにサービスし、必要なＦＳＭを実行し、ネクスト・ホップに対するメッセージを生成し、もしかすると、タイマを開始させる。タイマは、それらのファイアリング時刻に応じてソートされるタイマ・キューに配置される。タイマがファイアするときに、その関連するコンテキストは、メッセージ・バッファにキューされ、タイマのリセット・バージョンは、タイマ・バッファにおいて再キューされる。有効期限が切れたタイマは、単にそのシステムを離れる。新しい呼出しがブロックされる場合には、５００応答が、サーバによって生成される。

図５は、各サーバが小さな円によって示されたサーバの構成を示すＳＩＰベースのネットワークのトポロジの可能な一例を示している。このネットワークは、サーバ１および２として示されているコア・サーバと、サーバ３、４、５、６、および７として示されているイングレス／エグレス（ｅｇｒｅｓｓ）サーバとを含む。イングレス／エグレス・サーバのおのおのは、図示されていないいくつかのＵＡに結合され、そしてコア・サーバ１および２に結合される。このタイプのトポロジを有するネットワークは、以下の図６〜８、１１、および１２を参照して、本発明の負荷バランシング技法と過負荷制御技法を例証するために使用されることになる。

図５に示されているトポロジを有するＳＩＰベースのネットワークの性能を評価するに際して、本発明者等は、無限の母集団のＵＡがポアソン・プロセスに応じてλ個の呼出し／秒の集約レートでエンド・ツー・エンドの呼出しを開始するものと仮定する。与えられた対のＵＡの間のすべてのメッセージは、おのおのが図４に示されているようなキューイング・システムを有する複数のサーバを横切る。本発明者等は、再送信が完全にＳＩＰ ＦＳＭによって管理される点を除いて、図２の呼出しフローに類似した呼出しフローを使用する。過負荷制御アルゴリズムにおいて使用することができるパラメータ値の例が、以下の表１にリストアップされている。これらの個々の値は、例示の例だけとして提示され、他の値、パラメータ・セット、および過負荷制御アルゴリズムが、他の実施形態において使用することができることを理解すべきである。また、前述の仮定と、例示の実施形態を説明するに際して本明細書中において行われる他の仮定は、本発明の限定として解釈されるべきではない。本発明は、これらの仮定のうちの１つまたは複数が適用されない代替実施形態において実施することができる。

本発明者等は、次に本発明の例示の実施形態におけるＳＩＰベースのネットワーク、または他のタイプのネットワークにおいて使用するためのいくつかの過負荷制御技法について説明することにする。

そうでない場合に、従来のＳＩＰメッセージを使用して過負荷を通知するために使用することができるいくつかのアプローチが存在する。１つのアプローチは、過負荷にされたサーバからそのアップストリーム隣接サーバへと５０３サービス使用不可能応答を送信することにより過負荷にされたサーバについての通知を提供することである。この応答は、リトライ・アフター・ヘッダ・フィールドを経由して、過負荷にされたサーバが使用不可能になる時間の量を述べることができる。このメッセージを受信するとすぐに、アップストリーム隣接サーバは、与えられた存続時間にわたって、要求の宛先に関係なしに、過負荷にされたサーバに対して他のどのような要求も送信しないことになる。しかしながら、アップストリーム隣接サーバは、依然として過負荷にされたサーバに対して応答を送信することができる。本発明者等は、５０３応答が、一般的に大量のトラフィックが他の代替サーバに進路をそらされるようにさせ、この代替サーバが次にはどこかで過負荷をもたらすため、このメカニズムが過負荷に対して不十分にしか反応しないことを見出した。他のサーバも同じメカニズムを実施する場合には、過負荷は、１つのサーバから別のサーバへと揺れ動くことになる可能性が高い。

過負荷を通知するために使用することができる別のメッセージは、５００サーバ内部エラーである。グローバルな性質の５０３応答とは違って、５００応答は、与えられた呼出しについてローカルに適用可能であるにすぎない。過負荷を制御するためには、５００応答は、新しい呼出しを拒否するためにＩＮＶＩＴＥ要求に応答して適用されるのが最も効果的である。

代替アプローチは、過負荷を指し示す通知メッセージを明示的に送信することではなく、新しい呼出しをブロックするためにＩＮＶＩＴＥ要求を単に脱落させることである。このアプローチは、一般に、それが多数の再送信を引き起こす可能性があるため、あまりよく機能しない可能性がある。

別の重要な課題は、過負荷通知を開始するサーバのロケーションに関するものである。

本明細書中においてローカル過負荷制御と称される最も簡単なアプローチは、過負荷にされた各サーバが自律的に通知を開始することである。一例が図１１に示されており、ここでは、以下でさらに詳細に説明されることになるように、サーバＳ６は、それ自体のローカル情報を使用して、５００応答をアップストリームに送信することにより呼出しを拒否する。このアプローチの利点は、それが、ローカル情報だけを使用して、決定を行うことである。しかしながら、このアプローチは、呼出しをブロックするための追加リソースを消費する可能性があり、この追加リソースは過負荷にされたサーバをさらに悪化させてしまう可能性がある。

イングレス過負荷制御と呼ばれる別のアプローチは、ターゲットごとに、たとえば、１００Ｔｒｙｉｎｇ応答における新しいヘッダを経由して過負荷ステータス情報をアップストリームに伝搬させることである。この情報を転送する各サーバは、受信されたダウンストリーム過負荷ステータス値と、それ自体の過負荷ステータス値を比較し、２つの過負荷ステータス値のうちの最大値をアップストリームに伝搬させることになる。与えられたターゲットでは、イングレス・サーバは、過負荷ステータス情報に基づいて、新しい呼出しを受け入れ、あるいはブロックするように決定する。一例が、以下でより詳細に説明される予定である図１２に示されている。イングレス過負荷制御は、ネットワーク・コアの中のリソースが、ブロックされた呼出しのために浪費的に消費されないようにする。しかしながら、このアプローチは、複数の経路が与えられたターゲットに対して存在し得るため、実現することが難しい可能性がある。この問題を解決するための一方法は、可能性のある経路のうちから最大の過負荷ステータスを獲得することである。

以前の２つのアプローチの間の中間の第３のアプローチは、ペナルティメイト過負荷制御と呼ばれる。ここでは、過負荷にされたサーバの前のサーバは、新しい呼出しをブロックするサーバである。もう一度、図１１を参照すると、ペナルティメイト・サーバが、サーバＳ４である一例が示されている。したがって、このアプローチもまた、過負荷にされたサーバが、追加リソースを消費しなければならなくなることから解放する。しかしながら、このアプローチは、いつ呼出しを拒否することを開始させ、停止させるかを通知するために、よりインテリジェントなメッセージ交換を必要とする。

上述のように、本発明の例示の実施形態は、負荷バランシング技法と過負荷制御技法の両方を組み込むことができる。例示の負荷バランシング技法は、次に図６から１０を参照してさらに詳細に説明されることになり、それには図１１および１２を参照した例示の過負荷制御技法のさらなる説明が続いている。最終的に、そのような負荷バランシング技法と過負荷制御技法の組み合わせられた使用に帰せられる性能向上についての一例証が、図１３および１４を参照して説明されることになる。

次に図６および７を参照すると、本明細書中においてネクスト・ホップ負荷バランシングと称される１つのアプローチが示されている。図に示されているＳＩＰベースのネットワークにおいては、ＵＡ６００は、図に示されているように、サーバＳ１、Ｓ２、Ｓ５、およびＳ６に結合される。これらのサーバは、図５の例示のトポロジに示されているサーバなどのイングレス／エグレス・サーバである。サーバＳ１、Ｓ２、Ｓ５、およびＳ６のおのおのは、コア・サーバＳ３およびＳ４に結合される。したがって、図６および７、ならびに図８、１１、および１２に示されているネットワークは、図５に示されているタイプのトポロジを有する。この場合にも、このネットワーク・トポロジは、例示的であるにすぎず、説明される技法は、直截的な方法で、非常に多くの代替トポロジに適合化することができる。

ネクスト・ホップ負荷バランシング・アプローチにおいて、各サーバは、これらの隣接サーバから受信される輻輳フィードバック情報に基づいてそのダウンストリーム隣接サーバに対する経路指定確率を独立に、そして動的に調整する。たとえば、図６に示されているように、サーバＳ１は、Ｓ５に接続されたＵＡに対して、すなわちダウンストリーム・サーバＳ３およびＳ４を介してＳＩＰ要求メッセージを送信する２つの経路を有する。Ｓ１からＳＩＰ ＩＮＶＩＴＥメッセージを受信するとすぐに、ネクスト・ホップＳ３およびＳ４は、Ｓ１に戻るＩＮＶＩＴＥに応じて１００Ｔｒｙｉｎｇメッセージにそれらの輻輳測度の情報を添付することにより、それらの輻輳測度を定期的に公示することができる。図６における例においては、Ｓ３は、その輻輳測度が、利用率ｕ＝０．２であることを公示するが、Ｓ４は、その輻輳測度としてｕ＝０．６を独立に公示する。

この例における輻輳測度は、利用率測度であるが、多種多様な他のタイプの輻輳測度を使用することができる。本明細書中において使用されるような用語「輻輳測度」は、したがって、一般的に、たとえばプロセッサ利用率測度、メッセージ処理負荷、バッファ占有測度、メッセージ処理遅延、または輻輳を示す他の任意のタイプの情報、ならびにそのような測度または情報の組合せを包含するように解釈されるべきであるように意図される。

Ｓ３およびＳ４から受信されるフィードバック情報から、Ｓ１は、Ｓ３およびＳ４における輻輳測度を等しくする目的で、その経路指定確率を調整する。経路指定確率におけるそのような調整が、図７に示され、この図は、コア・サーバＳ３およびＳ４における負荷バランシングされた状態を最終的にもたらす経路指定確率における変化を示している。より詳細には、サーバＳ４がサーバＳ３よりも高い利用率を有することを指し示すフィードバック情報に応じて、サーバＳ１は、与えられたメッセージをサーバＳ４に対して経路指定する確率が、たとえば０．４であるが、与えられたメッセージをサーバＳ３に対して経路指定する確率が、たとえば０．６であるように、その経路指定確率を調整する。そのような調整は、サーバＳ４に対して経路指定されるメッセージの数を減少させながら、サーバＳ３に対して経路指定されるメッセージの数を増大させる傾向があることになり、その結果、図に示されているように負荷バランシングされた状態をもたらす。

本発明の与えられた一実施形態において利用することができる別の負荷バランシング・アプローチは、本明細書中においてターゲットベースの負荷バランシングを称される。図８は、前述のように構成されるサーバＳ１からＳ６を備えるＳＩＰベースのネットワークに適用されるものとしてこのアプローチを示している。このアプローチは、ダウンストリーム・サーバからターゲット・サーバへの経路に沿っての輻輳情報を使用する。特に、輻輳測度は、ダウンストリーム・サーバからターゲット・サーバへの最悪の輻輳測度を表す。図において、サーバＳ３、Ｓ４、およびＳ５は、それぞれ０．２、０．６、および０．３の利用率を有することを理解することができる。サーバＳ１とターゲット・サーバＳ５との間に、一方はサーバＳ３を経由し、他方はサーバＳ４を経由した２つの経路が示されている。Ｓ３を経由したＳ５への経路についての最大の利用率は、０．３のＳ５の利用率であり、その結果、利用率は、フィードバック情報としてＳ１へと逆に伝搬させられる。同様に、Ｓ４を経由したＳ５に対する経路についての最大の利用率は、０．６のＳ４の利用率であり、その結果、利用率は、フィードバック情報としてＳ１へと逆に伝搬させられる。次いで、サーバＳ１は、それに応じてその経路指定確率を調整して、負荷バランシングされた状態をもたらす。

上記されたネクスト・ホップ負荷バランシング技法と、ターゲットベースの負荷バランシング技法との間の違いは、図９に示されている。この例においては、ソース・サーバＳは、関連する経路指定確率ｑ１およびｑ２を有する第１および第２の経路を経由してターゲット・サーバＴへとメッセージを経路指定する。第１または上側の経路は、それぞれ利用率０．２および０．６を有するサーバ９０１および９０２を通過する。第２または下側の経路は、それぞれ利用率０．５および０．１を有するサーバ９０３および９０４を通過する。

ネクスト・ホップ負荷バランシング・アプローチにおいては、サーバ９０３の０．５の利用率の値は、サーバ９０１の０．２の利用率の値よりも高いため、サーバＳにおける経路指定確率ｑ１およびｑ２は、サーバ９０１およびサーバ９０３における利用率の値が、実質的に等しくなる、すなわち負荷バランシングされるまで、経路指定確率ｑ１が、増大させられることになるが、経路指定確率ｑ２は、減少させられることになるように調整されることになる。

ターゲットベースの負荷バランシング・アプローチにおいては、第１の経路と、第２の経路における最高の利用率の値は、それぞれ、サーバ９０２についての０．６の利用率の値と、サーバ９０３についての０．５の利用率の値である。第１の経路の最高の利用率の値が、第２の経路の最高の利用率の値よりも高いため、サーバＳにおける経路指定確率ｑ１およびｑ２は、負荷バランシングされた状態がもたらされるまで、経路指定確率ｑ２が増大させられることになるが、経路指定確率ｑ１は、減少させられることになるように調整されることになる。２つのアプローチは、同じ組のサーバ利用率の値について、異なる経路指定確率の結果をもたらす可能性があることを理解することができる。ネクスト・ホップ負荷バランシングは、ある種の状態の下ではターゲットベースの負荷バランシングと同様に実行しない可能性があるが、ネクスト・ホップ負荷バランシングは、ターゲットベースの負荷バランシングよりも実施することが簡単である。

図１０は、フィードバック情報を、ネットワークを介して伝搬し、与えられたノードにおいて経路指定テーブル１０００に記憶することができる方法を示している。この例におけるネットワークは、ソース・ノードａと、それぞれ０．１、０．１、０．２、０．５、０．３、０．４、０．４、０．３、および０．１の利用率を有する追加ノードｉ、ｊ、ｋ、ｌ、ｍ、ｎ、ｒ、ｓ、およびｚとを含んでいる。ａからｚへの経路は、以下の経路：（１）（ａ、ｉ、ｋ、ｍ、ｎ、ｚ）、（ａ、ｉ、ｋ、ｍ、ｒ、ｚ）、（ａ、ｉ、ｋ、ｌ、ｋ、ｍ、ｎ、ｚ）、（ａ、ｊ、...、ｓ、ｚ）などを横切ることができる。特に、経路が（ａ、ｉ、ｋ、ｍ、ｎ、ｚ）に従う場合、ｉからａへと戻されるフィードバック情報は、０．４である。経路が（ａ、ｉ、ｋ、ｌ、ｋ、ｍ、ｎ、ｚ）に従う場合、ｉからａへと戻されるフィードバック情報は、０．５である。この経路の多様性は、ＳＩＰにおいて許容されるスパイラルに起因している。

前述のターゲットベースの負荷バランシング・アプローチに従って、ノードａとノードｚとの間の上側の経路の最高の利用率は、０．４から０．５の範囲内にあるが、ノードａとノードｚとの間の下側の経路の最高の利用率は、０．３である。このフィードバック情報は、ネットワークを介してノードａへと逆に伝搬させられ、ここでそれは、経路指定テーブル１０００に記憶される。さまざまなアプローチを使用して、上側の経路についての輻輳測度の単一の値を指定することができる。簡単なアプローチは、上側の経路の輻輳測度について０．５の最悪ケースの値を取ることである。その経路指定テーブルは、説明を明確にするためにかなり簡略化されているが、一般にターゲット・ノードと、ターゲットへの特定の経路を示す経由ノードと、特定の経路についての最高の利用率と、経路指定確率についての複数の列を含んでいる。もちろん、本発明を実施するに際して、非常に多くの代替経路指定テーブル・フォーマットを使用することができる。

サーバｉで示されている与えられたサーバ内において、上記のネクスト・ホップ負荷バランシング・アプローチ、またはターゲットベースの負荷バランシング・アプローチを実施するに際して使用することができる分散負荷バランシング・アルゴリズムの可能な一例は、以下のようになる。
ｘ_ｉｊ（ｄ）＝（ターゲットｄに方向づけられた）ｉからネクスト・ホップｊを経由したトラフィックのフラクションであるものとする
ｕ_ｉｊ（ｄ）＝サーバｉによって観察されるｊを経由した（ターゲットｄに対する）「平滑化された」利用率であるものとする
アップデートごとに
Δｘ_ｉｊ（ｄ）＝αｘ_ｉｊ（ｄ）（Ｕ_ｉ−ｕ_ｉｊ（ｄ））を計算する
ここで、Ｕ_ｉ＝Σ_ｊｘ_ｉｊ（ｄ）ｕ_ｉｊ（ｄ）
そのときには、新しいトラフィック割当ては、次式によって与えられる：
Ｘ_ｉｊ（ｄ）＝ｍａｘ（０，ｘ_ｉｊ（ｄ）＋Δｘ_ｉｊ（ｄ））
ｘ_ｉｊ（ｄ）＝Ｘ_ｉｊ（ｄ）／Σ_ｊＸ_ｉｊ（ｄ）

この例においては、ｘ_ｉｊ（ｄ）の値は、一般に前述の経路指定確率に対応する。アルゴリズムは、各サーバにおいて、たとえば、Ｔ秒ごとに定期的に実行することができる。本明細書中において説明されるネクスト・ホップ負荷バランシング・アプローチ、またはターゲットベースの負荷バランシング・アプローチを実施するための他の適切なアルゴリズムは、当業者には明らかであろう。

前述のように、前記のローカルな、ペナルティメイト過負荷制御技法およびイングレス過負荷制御技法は、図１１および１２を参照して次に示すことにする。これらの過負荷技法については、すでに本明細書中において説明されているが、それらについては、負荷バランシング技法を示すために図６〜８において使用されるこれらと同様なコンフィギュレーション有する簡略化されたＳＩＰベースのネットワークに関与する特定の例に関してさらに説明することにする。

最初に図１１を参照すると、ローカルな過負荷制御技法が示されている。この例におけるＳＩＰベースのネットワークは、図６〜８の例におけるように相互接続されたＵＡと、サーバＳ１からＳ６とを含んでいる。サーバＳ６が、過負荷になっており、したがって、新しい呼出しが、このサーバによってローカルに拒否されることを理解することができる。この例において過負荷を通知するために使用されるメカニズムは、前述の５００サーバ内部エラー・メッセージである。上記のように、５００応答は、与えられた呼出しについてローカルに適用可能であるにすぎず、ＩＮＶＩＴＥ要求に応じて最も効果的に適用される。したがって、このアプローチは、ローカル情報だけを利用するが、それらの呼出しを拒否するに際して追加のローカル・リソースを消費する。

代替ペナルティメイト過負荷制御アプローチが図１１にも示されており、この代替ペナルティメイト過負荷制御アプローチは、有利に５００応答の生成に関連する追加の処理から過負荷にされたサーバＳ６を解放する。これは、過負荷にされたサーバＳ６においてではなく、サーバＳ４において呼出しを拒否することにより実現される。したがって、Ｓ４は、そのダウンストリーム隣接サーバＳ６からの情報を必要とすることになる。

図１２は、イングレス過負荷制御アプローチを示し、このアプローチにおいては新しい呼出しは、イングレス・ノードにおいて拒否され、このイングレス・ノードは、図に示されている例においてはサーバＳ２である。フィードバック情報は、ネットワークを介してサーバＳ６から伝搬させられ、サーバＳ６において０．９５の利用率の値の形式で過負荷状態を指し示している。サーバＳ２は、この情報を使用して、新しい呼出しがサーバＳ６に向けられないように拒否する。有利なことに、このイングレス過負荷制御アプローチは、呼出しがブロックされるときに、ネットワーク・コアにおけるリソースが不必要に消費されないようにする。しかしながら、イングレス過負荷制御アプローチは、経路情報を使用し、この経路情報は、一部の実施形態においては、簡単に使用可能ではない可能性がある。

前述の説明から明らかなように、図６〜１２の例に関連して説明される例示の実施形態は、フィードバック情報を利用して、負荷バランシングおよび過負荷制御を実現する。本発明の一態様による、このフィードバック情報と、関連する負荷バランシング技法および過負荷制御技法は、本明細書中において「過負荷安全ＳＩＰ」またはＯＳ−ＳＩＰと称される機能強化されたタイプのＳＩＰを提供する。ＯＳ−ＳＩＰは、負荷バランシングと過負荷制御の両方を利用するが、他の実施形態は、負荷バランシング、または過負荷制御のいずれかであるが、両方ではないものを利用することができることに注意すべきである。

図１３および１４は、従来のＳＩＰの性能をＯＳ−ＳＩＰと比較して、提供負荷の関数としてのそれぞれスループットおよびリング遅延のプロットを示している。これらのプロットは、６台のサーバＳ１からＳ６が、これらの図に示されているように相互接続された、図６〜８、１１、および１２に示されているタイプの例示のＳＩＰベースのネットワークについて生成される。基礎となるＩＰネットワークには、輻輳がないこと、それらの呼出しは、ポアソン・プロセスに従って到着することが仮定された。失敗した呼出しは、確率０．１で再試行されるものと仮定される。また、呼出しホールディング時間は、１５０秒の平均値で指数関数的に分散されるように仮定され、リングから応答への遅延は、３秒の平均値で一様に分散されるように仮定されてもいる。サーバＳ１およびＳ２からの経路指定確率は、最初にｑ１＝ｑ３＝０．４と、ｑ２＝ｑ４＝０．６を用いて、それぞれ｛ｑ１，ｑ２｝および｛ｑ３，ｑ４｝によって与えられる。それらのサーバについての相対的なスピードアップ・ファクタは、Ｓ１＝０．６、Ｓ２＝０．６、Ｓ３＝０．６、Ｓ４＝０．３、Ｓ５＝０．５、およびＳ６＝０．５である。また、この例におけるすべてのサーバは、ステートフルであるものと仮定される。

次に図１３を参照すると、提供負荷の関数としてのスループットのプロットは、従来のＳＩＰまたは「プレイン」ＳＩＰをＯＳ−ＳＩＰと比較して示されている。従来のＳＩＰについてのスループットは、実線の曲線に従い、この例においては、毎秒約８００個の呼出しにおいて輻輳崩壊問題を示す。ＯＳ−ＳＩＰ性能は、破線の曲線によって示されている。ＯＳ−ＳＩＰは、過負荷制御の使用に起因して、従来のＳＩＰによって示される輻輳崩壊問題を回避することは簡単に明らかである。ＯＳ−ＳＩＰはまた、毎秒約１０００個の呼出しの最大スループットまでの、従来のＳＩＰと比較した容量の増大を示す。この容量の増大は、本明細書に記載されているような負荷バランシング技法の使用に起因する。図１３におけるプロットは、ＯＳ−ＳＩＰが、トラフィック負荷とは無関係に、著しい性能改善をもたらし、高信頼性のサービスを提供することを実証している。

図１４を参照すると、ＯＳ−ＳＩＰはまた、従来のＳＩＰと比較してリング遅延における実質的な改善を提供することがさらに明らかである。より詳細には、ＯＳ−ＳＩＰは、トラフィック負荷が重くなるときでさえ、受け入れることが可能な遅延性能を保証する。

この場合にも、上記の例示の実施形態の特定のパラメータ、仮定、ネットワーク・トポロジおよび他の特徴が、単なる例としてのみ提示されていることを理解すべきである。ＩＭＳネットワークなど、ＳＩＰベースのネットワークでは特に有用であるが、本明細書中において説明される技法は、いくつかの異なる通信プロトコルのうちの任意のプロトコルを使用して、多種多様な他のタイプの通信ネットワークに対して適用することができる。添付の特許請求の範囲の範囲内におけるこれらの実施形態および非常に多くの他の代替実施形態は、当業者には簡単に明らかであろう。

本発明の一実施形態が実施されるＳＩＰベースのネットワークの一部分の簡略化されたブロック図である。 ＳＩＰベースのネットワークのネットワーク要素の間の呼出しフローを示す図である。 従来のＳＩＰ技法に関連する輻輳崩壊状態を示す、ＳＩＰベースのネットワークにおける提供負荷の関数としてスループットのプロットを示す図である。 図１のネットワークのサーバのうちの特定の１つについての例示のキューイング・システムの簡略化されたブロック図である。 本発明の例示の一実施形態における、ＳＩＰベースのネットワークの例示のトポロジを示す図である。 図５に示されているタイプの１トポロジを有するＳＩＰベースのネットワークにおけるネクスト・ホップ負荷バランシング技法の一実施形態を示す図である。 図５に示されているタイプの１トポロジを有するＳＩＰベースのネットワークにおけるネクスト・ホップ負荷バランシング技法の一実施形態を示す図である。 ＳＩＰベースのネットワークにおける、ターゲットベースの負荷バランシング技法の例示の一実施形態を示す図である。 ネクスト・ホップ負荷バランシング技法と、ターゲットベースの負荷バランシング技法との間の違いを示す図である。 ターゲットベースの負荷バランシングにおけるフィードバック情報の使用の一例を示す図である。 それぞれローカル過負荷制御アプローチおよびイングレス過負荷制御アプローチを利用した過負荷制御を示す図である。 それぞれローカル過負荷制御アプローチおよびイングレス過負荷制御アプローチを利用した過負荷制御を示す図である。 本発明の例示の負荷バランシング技法および過負荷技法が、図３に示されているような輻輳崩壊状態を回避する方法を示す、ＳＩＰベースのネットワークにおける提供負荷の関数としてスループットのプロットを示す図である。 本発明の例示の負荷バランシング技法および過負荷技法が、従来のＳＩＰ技法の使用からもたらされる可能性がある過剰遅延を回避することができる方法を示す、ＳＩＰベースのネットワークにおける提供負荷の関数としてリング遅延のプロットを示す図である。

Claims (10)

1. 複数のサーバを備えるネットワークにおいてメッセージを経路指定する方法であって、
   第１のサーバにおいて、前記第１のサーバとターゲット・サーバとの間のそれぞれ第１の経路と第２の経路に関連する少なくとも第１のダウンストリーム・サーバと第２のダウンストリーム・サーバとを含む、前記ネットワークのダウンストリーム・サーバから、前記それぞれのダウンストリーム・サーバについての輻輳測度を含むフィードバック情報を受信するステップと、
   前記ダウンストリーム・サーバの前記輻輳測度の間のアンバランスについて補償するために、前記受信されたフィードバック情報に基づいて前記第１のサーバにおけるメッセージ経路指定プロセスを調整するステップと
   を含み、
   前記第１および第２の経路のうちの１つにおける前記ダウンストリーム・サーバの少なくとも所与の１つが、前記第１のサーバから前記ターゲット・サーバに送信されたＩＮＶＩＴＥ要求に対する前記ターゲット・サーバからの応答を受信し
   前記所与のダウンストリーム・サーバは、前記ターゲット・サーバからの前記応答に含まれる輻輳測度と前記所与のダウンストリーム・サーバの輻輳測度とを比較し、前記所与のダウンストリーム・サーバの前記輻輳測度が、前記ターゲット・サーバからの前記応答に含まれる前記輻輳測度よりも高い輻輳レベルを示した場合には、前記所与のダウンストリーム・サーバは、前記応答のアップストリームを前記第１のサーバに送信する前に前記所与のダウンストリーム・サーバの前記輻輳測度を含むように前記ターゲット・サーバからの前記応答を変更する、
   方法。
2. 前記フィードバック情報は、前記第１のサーバと、前記ターゲット・サーバとの間の前記の第１の経路と第２の経路における複数のサーバの輻輳測度のうちの最高の輻輳測度を含む、請求項１に記載の方法。
3. 前記の第１のダウンストリーム・サーバと第２のダウンストリーム・サーバのうちの一方は、ターゲット・サーバである、請求項１に記載の方法。
4. 前記の第１のダウンストリーム・サーバと第２のダウンストリーム・サーバのうちの少なくとも一方は、前記第１のサーバの最も近い隣接サーバである、請求項１に記載の方法。
5. 前記フィードバック情報に基づいて前記第１のサーバにおけるメッセージ経路指定プロセスを調整する前記ステップは、前記の第１の経路と第２の経路の上で経路指定されるべき与えられた組のメッセージの相対的パーセンテージを指定する経路指定情報を調整するステップをさらに含む、請求項１に記載の方法。
6. ネットワークにおいてメッセージを経路指定する際に使用するための装置であって、
   第１のサーバと、ターゲット・サーバとの間のそれぞれ第１の経路と第２の経路に関連する少なくとも第１のダウンストリーム・サーバと第２のダウンストリーム・サーバを含む、前記ネットワークのダウンストリーム・サーバから、前記それぞれのダウンストリーム・サーバについての輻輳測度を含むフィードバック情報を受信するように構成される、前記ネットワークの前記第１のサーバを備え、
   前記第１のサーバは、さらに前記ダウンストリーム・サーバの前記輻輳測度の間のアンバランスについて補償するために前記受信されたフィードバック情報に基づいてそのメッセージ経路指定プロセスを調整し、
   前記第１および第２の経路のうちの１つにおける前記ダウンストリーム・サーバの少なくとも所与の１つが、前記第１のサーバから前記ターゲット・サーバに送信されたＩＮＶＩＴＥ要求に対する前記ターゲット・サーバからの応答を受信し
   前記所与のダウンストリーム・サーバは、前記ターゲット・サーバからの前記応答に含まれる輻輳測度と前記所与のダウンストリーム・サーバの輻輳測度とを比較し、前記所与のダウンストリーム・サーバの前記輻輳測度が、前記ターゲット・サーバからの前記応答に含まれる前記輻輳測度よりも高い輻輳レベルを示した場合には、前記所与のダウンストリーム・サーバは、前記応答のアップストリームを前記第１のサーバに送信する前に前記所与のダウンストリーム・サーバの前記輻輳測度を含むように前記ターゲット・サーバからの前記応答を変更する、
   ように構成される装置。
7. 複数のサーバを備えるネットワークにおいてメッセージを経路指定する方法であって、
   第１のサーバにおいて、前記第１のサーバと、ターゲット・サーバとの間の経路に関連している、前記ネットワークの少なくとも１つのダウンストリーム・サーバから、前記ダウンストリーム・サーバについての輻輳測度を含むフィードバック情報を受信するステップと、
   前記フィードバック情報に基づいてユーザ・エージェントに対して配信するための、前記第１のサーバにおけるブロッキング・メッセージを生成するステップとを含み、
   前記ダウンストリーム・サーバが、前記第１のサーバから前記ターゲット・サーバに送信されたＩＮＶＩＴＥ要求に対する前記ターゲット・サーバからの応答を受信し、
   前記ダウンストリーム・サーバは、前記ターゲット・サーバからの前記応答に含まれる輻輳測度と前記ダウンストリーム・サーバの輻輳測度とを比較し、前記ダウンストリーム・サーバの前記輻輳測度が、前記ターゲット・サーバからの前記応答に含まれる前記輻輳測度よりも高い輻輳レベルを示した場合には、前記ダウンストリーム・サーバは、前記応答のアップストリームを前記第１のサーバに送信する前に前記ダウンストリーム・サーバの前記輻輳測度を含むように前記ターゲット・サーバからの前記応答を変更する、
   方法。
8. 前記フィードバック情報は、前記第１のサーバと、前記ターゲット・サーバとの間の前記経路における複数のサーバの輻輳測度のうちの最高の輻輳測度を含む、請求項７に記載の方法。
9. 前記ダウンストリーム・サーバは、前記第１のサーバの最も近い隣接サーバである、請求項７に記載の方法。
10. ネットワークにおいてメッセージを経路指定する際に使用するための装置であって、
    第１のサーバと、ターゲット・サーバとの間の経路に関連している、前記ネットワークの少なくとも１つのダウンストリーム・サーバから、前記ダウンストリーム・サーバについての輻輳測度を含むフィードバック情報を受信するように構成される、前記ネットワークの前記第１のサーバを備え、
    前記第１のサーバは、さらに前記フィードバック情報に基づいてユーザ・エージェントに対して配信するためのブロッキング・メッセージを生成し、
    前記ダウンストリーム・サーバが、前記第１のサーバから前記ターゲット・サーバに送信されたＩＮＶＩＴＥ要求に対する前記ターゲット・サーバからの応答を受信し、
    前記ダウンストリーム・サーバは、前記ターゲット・サーバからの前記応答に含まれる輻輳測度と前記ダウンストリーム・サーバの輻輳測度とを比較し、前記ダウンストリーム・サーバの前記輻輳測度が、前記ターゲット・サーバからの前記応答に含まれる前記輻輳測度よりも高い輻輳レベルを示した場合には、前記ダウンストリーム・サーバは、前記応答のアップストリームを前記第１のサーバに送信する前に前記ダウンストリーム・サーバの前記輻輳測度を含むように前記ターゲット・サーバからの前記応答を変更する、
    ように構成される装置。

Images