JP4921589B2 - ステートレス領域における優先フローの処理 - Google Patents

Description

本発明は、ステートレスＩＰネットワーク領域における優先フローの処理に関する。詳細には、本発明は、ネットワークに輻輳が発生している場合に高優先フローを維持するためのシステムに関する。

通信ネットワークでは、緊急サービスの提供が重要になってきている。ネットワーク内では、一般に緊急通話や緊急データフローは他の通話やデータフローより優先されなければならない。２００２年５月のＩＴＵ−Ｔ勧告Ｙ．１５４１「Ｎｅｔｗｏｒｋ Ｐｅｒｆｏｒｍａｎｃｅ Ｏｂｊｅｃｔｉｖｅｓ ｆｏｒ ＩＰ−Ｂａｓｅｄ Ｓｅｒｖｉｃｅｓ」は、ＩＰネットワークのためのさまざまな優先タイプを規定している。

ＩＰネットワークでは最近、サービス品質（ＱｏＳ）を保証するため、データ経路に関するリソース管理プロトコルが研究されている。そのようなプロトコルは、ネットワーク領域または自律システムのエッジに到着するデータフローのためのリソースのニーズが満たされていることを保証することと、そして、そのフローのその後の経路に関する情報が領域の内部ノードに提供されることを保証することとに責任を持つ。これによって内部ノードは、ローカルな許可制御(admission control)の決定を行うことができる。フローは通常、経路の中の全ての内部ノードが許可した場合に限って、ネットワーク領域への進入が許可される。フローは、全ての中間領域が肯定の許可決定をした場合に限って、エンド・ツー・エンドで進入が許可される。また、フローの進入許可には、（純粋に測定に基づく許可制御を除いて）全ての内部ノードにおけるリソースの予約が必要である。

Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＩｎｔＳｅｒｖ）は、インターネット内でリアルタイムおよび非リアルタイムのトラヒックのＱｏＳを保証するために採用された１つのアーキテクチャである。Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）標準化機構は、ＲＦＣ２２０５で規定されているように、ＩＰルータの中でリソースを予約するためのＲｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＳＶＰ）を規定している。データ経路沿いの各ルータは、「フロー毎の」予約状態を記憶する。予約状態は、「ソフトな」状態であり、定期的なリフレッシュメッセージを送信することによってリフレッシュされる必要がある。予約状態がリフレッシュされない場合、あるタイムアウト時間枠の後に、状態および対応するリソースは削除される。また、予約は、明示的な除去メッセージによって削除することもできる。ＲＳＶＰメッセージは常にデータ経路をたどって進むため、ＲＳＶＰは、標準的なルーティングプロトコルと並行して動作することができる。トラヒックがルート変更される場合、リフレッシュメッセージは、新たなデータ経路において予約を行う。

大規模ネットワークでは、フローの数、従って予約状態の数は、多い。そのため、各ルータの中でフロー毎の状態を記憶して維持するのに問題が生じる恐れがある。従って、大規模ネットワークにおいてＱｏＳを提供する目的で、もう１つのアーキテクチャであるＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＤｉｆｆＳｅｒｖ）が提案されており、そしてこれはＲＦＣ２４７５の中に記述されている。ＤｉｆｆＳｅｒｖアーキテクチャでは、ネットワークの大規模化を可能にするため、サービスは、フロー毎のベースではなく、集合体（アグリゲート)ベースで提供される。できるだけ多くのフロー毎の状態が、ネットワークのエッジにまとめられ、そして、これらのまとまりについてのさまざまなサービスがルータ内で提供される。これが、ＤｉｆｆＳｅｒｖアーキテクチャのスケーラビリティを提供する。

ＩＰヘッダの中のＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＤＳ）フィールドを用いて、サービスの区別が行われる。パケットは、ＤｉｆｆＳｅｒｖネットワークのエッジノードで、Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｕｒ（ＰＨＢ）グループに分類される。パケットは、メッセージヘッダの中のＤＳフィールドによって示されるＰＨＢに従ってＤｉｆｆＳｅｒｖルータの中で処理される。ＤｉｆｆＳｅｒｖアーキテクチャは、領域外のデバイスには、リソースを動的に予約したり、ネットワークリソースの利用可能性の指標を受信したりするための手段を一切提供しない。実際には、サービスプロバイダは、顧客から受け取るであろうトラヒックのパラメータを静的に定義する、契約時のＳｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔｓ（ＳＬＡｓ）を利用する。

ＩＥＴＦ Ｎｅｘｔ Ｓｔｅｐｓ Ｉｎ Ｓｉｇｎａｌｉｎｇ（ＮＳＩＳ） Ｗｏｒｋｉｎｇ Ｇｒｏｕｐは、ＲＦＣ３７２６に定義されているように、今日のＩＰネットワークの新たなシグナリング要件に合致するためのプロトコルについて現在作業中である。ＮＳＩＳのＱｏＳシグナリング・アプリケーション・プロトコルは、ＲＳＶＰと基本的に類似しているが、いくつか新しい特徴を有しており、その１つは、さまざまなＱｏＳモデルのサポートである。規定されているＱｏＳモデルの１つは、Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ ｉｎ ＤｉｆｆＳｅｒｖ（ＲＭＤ）である。ＲＭＤは、ＤｉｆｆＳｅｒｖネットワークのためのスケーラブルな許可制御方法を定義しており、従って、領域の内側の内部ノードは、フロー毎の状態ではなく集合化された状態の情報を保有する。例えば、内部ノードは、各フローの個別の予約ではなく、集合化された予約帯域幅を知っていてもよい。またＲＭＤは、（ＲＳＶＰと同様に）ソフトな状態を使用し、そして、リソースの明示的な解放も可能である。またＲＭＤは「阻止（プリエンプション）」機能を含んでおり、この機能は、輻輳が生じた場合には、残りのフローに必要なＱｏＳを維持する目的で、必要な数のパケットフローを終了させることができる。これについては、ＷＯ ２００６／０５２１７４に記述されている。

最近のＩｎｔｅｒｎｅｔ Ｄｒａｆｔ（“ＲＳＶＰ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｅｍｅｒｇｅｎｃｙ Ｓｅｒｖｉｃｅｓ”、Ｆ．Ｌｅ Ｆａｕｃｈｅｕｒ他、ｄｒａｆｔ−ｌｅｆａｕｃｈｅｕｒ−ｅｍｅｒｇｅｎｃｙ−ｒｓｖｐ−０２．ｔｘｔ）には、緊急サービスをサポートするためのＲＳＶＰの拡張が規定されている。これは、ＲＳＶＰのための優先ポリシー要素を定義するものであり、許可の優先度のための帯域幅割り当てモデルの例について記述している。

フロー毎の方法が用いられる場合（ＲＳＶＰあるいはＱｏＳ−ＮＳＬＰシグナリングを伴うＩｎｔＳｅｒｖ）、各ノードはフロー毎の状態を維持するのだから、高優先フローの処理は問題にはならない。フローを許可するかまたは阻止するかという決定を行わなければならない場合、各ルータの中でフローの優先度を考慮することができる。例えばＲＭＤやＲＳＶＰの集合体のような「ステートレス」領域においては、内部ノードは、フロー毎の状態情報を維持せず、集合化された状態だけ（例えばクラス毎）を維持する。従って、それらはデータパケットを優先度情報と関連付けることができない。ステートレスによる方法では、エッジノードが、フローの許可と阻止とに責任を持ち、そしてそれらは、優先度の決定を行う必要もある。

Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ「ＲＳＶＰ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｅｍｅｒｇｅｎｃｙ Ｓｅｒｖｉｃｅｓ」（Ｆ．Ｌｅ Ｆａｕｃｈｅｕｒ他、ｄｒａｆｔ−ｌｅｆａｕｃｈｅｕｒ−ｅｍｅｒｇｅｎｃｙ−ｒｓｖｐ−０２．ｔｘｔ）の中に記述された方法の中で、許可の優先度が考慮されている。これは、これらの方法によって、優先度の高いフローが優先度の低いフローより優先されて、ネットワークへの進入を許可されうることが保証されることを意味する。しかし、これらの解決策は、ゆっくりと変化する環境を（すなわち、呼が比較的ゆっくり増加し、トポロジが変化しないことを）想定している。リンクの障害あるいはノードの障害の場合のＱｏＳのサポートや優先度の処理は、フロー毎の状態に基づいており、これは、ＲＭＤのようなステートレスプロトコルと一緒には利用できない。

ＲＭＤは、（例えばリンクの障害あるいはノードの障害が原因で）ルート変更が生じた場合にステートレスＤｉｆｆｓｅｒｖ領域においてＱｏＳを保証するための、重度輻輳アルゴリズムとして知られる方法について記述している。ルータに重度の輻輳が発生している（例えば多数のパケットを破棄している）場合、ＲＭＤのエッジノードは、残りのフローのためのＱｏＳを維持する目的で、一部のフローを終了させる。低優先フローを優先的に破棄することによってフローの優先度を考慮することは可能だが、問題が完全に解決したわけではない。

このことは、図１に図解する状況を考えれば理解できる。図１は、ステートレス領域内の選択されたノードの概略図である。図は、入口エッジ１０１と、内部ルータ１０２と、出口エッジ１０３とを示す。内部ルータ１０２で輻輳が発生していると仮定する。ＲＭＤの重度輻輳アルゴリズムによると、輻輳についてエッジノードに通知することを目的として、内部ルータはデータパケットにマークを付ける。マークされたバイトの数は、超過トラヒックを表す。各出口エッジノード１０３では、マークされたバイトの数が測定され、対応する数のフローを終了させるための決定が行われる。これは、必要とされるフローを終了させるため、出口エッジ１０３が入口エッジ１０１へメッセージを送信することによって達成される。低優先フローを選択して終了させることによって、優先度が考慮される。

しかし、全ての低優先フローを終了させても輻輳を解消するのにはまだ十分ではないことがあるであろうし、その場合には高優先フローも終了させることになるだろう。例えば、出口エッジノード１０３でのトラヒック構成１０４では、フローの９０％が高優先呼１０５であると仮定しよう。このようなことは、例えば、このノードがトラヒックを緊急センタに宛てて送るために生じることがある。全トラヒックのうち４０％を終了させることが必要な場合には、低優先呼１０６全部（全体の１０％）を終了させるであろうが、輻輳は依然として存在するであろう。輻輳は、低優先呼全部に加えて高優先トラヒックの約３０％を終了させることによって初めて解消されうる。

しかし、輻輳ルータ１０２を通過する低優先呼が多量に存在しているのに、それらは他の出口ノードを経由してネットワークを出て行くと仮定しよう。この状況を、図１に示す領域に類似した領域におけるノードを示す図２に図解する。今度は、この領域は、低優先トラヒックおよび高優先トラヒックに関する異なる構成１０４および２０４を有する２つの異なる出口エッジノード１０３と２０３とを有する。この例では、第１の出口エッジノード１０３は、前の例と同じく１０％の低優先トラヒック１０６と９０％の高優先トラヒック１０５とを有する。第２の出口ノード２０３は、８０％の低優先トラヒック２０６と２０％の高優先トラヒック２０５とを有する。今度は、ルータ１０２で４０％の過負荷がある場合、出口ノードは両方共、トラヒックの４０％を終了させるであろう。第２の出口エッジノード２０３は、低優先フローだけを終了させることができるであろうが、第１の出口エッジノード１０３は、やはり（前の例と同じく）その高優先トラヒックの３０％を終了させるであろう。第２の出口エッジノード２０３は、やはり、第１の出口ノード１０３での高優先フローより優先的に終了させることができるはずの低優先フロー２０６を有していることから、これは望ましくない。第２の出口ノード２０３がもっと多くの低優先フロー２０６を終了させるならば、第１の出口ノード１０３が高優先フロー１０５を終了させる必要はないであろう。

加えて考慮すべきなのは、緊急の状況（すなわち、高優先フローが多数ある場合）では、通常の条件下よりも高い確率でリンクやノードの障害が発生し、輻輳が発生することである。従って、重度の輻輳と多数の高優先フローとが同時に発生する可能性が極めて高い。従って、ネットワークがこの問題を適切に処理することが重要である。

本発明は、ステートレスネットワーク領域において優先トラヒックを処理するための許可制御の方法および阻止の方法について記述する。許可制御アルゴリズムは、通常の動作条件におけるＱｏＳと優先度とを保証する。阻止アルゴリズムは、許可制御によっては解決されない、予期せぬ状況を処理する。

本発明の一態様によれば、少なくとも２つの優先度レベルを持つ複数のデータフローを送信するＩＰネットワークにおいてサービス品質を管理する方法であって、
前記ネットワークの出口エッジノードにおいて、前記ネットワーク内の１以上のルータに輻輳が存在することを確認するステップと、
前記輻輳を解消するために、終了させるデータフローを選択するステップと、
前記選択されたデータフローを特定する少なくとも１つのフロー終了通知を、前記ネットワークの前記出口エッジノードから入口エッジノードへ送信するステップと、
前記入口エッジノードにおいて、前記選択されたデータフローのうちの低優先フローを速やかに終了させるステップと、
所定の遅延期間の後に依然として輻輳が存在する場合にのみ、前記入口エッジノードにおいて、前記選択されたデータフローのうちの高優先フローを終了させるステップと、
を備えることを特徴とする方法が提供される。

従って、輻輳が最初に確認された場合、低優先フローは速やかに終了されるが、高優先フローが終了されるまでには遅延が存在する。これによって、他の出口エッジノードを通過する低優先フローを終了させることが可能になり、他に選択肢がない訳ではない限り、高優先フローを終了させないことが保証される。遅延の後でも依然として輻輳が存在する場合には、高優先フローも同じく終了させ始める以外に、選択肢はない。

遅延は、入口エッジノードと出口エッジノードのいずれか一方に導入されることが好ましい。遅延が入口エッジノードに導入される場合、出口エッジノードは通常通りに動作し、終了させるために選択された全てのデータフローを特定する最初のフロー終了通知を送信することができる。ＱｏＳの解決策が帯域ブローカー（ＢＢ）に基づいている場合、遅延は、ＢＢによって導入されてもよい。入口エッジノードは最初のフロー終了通知を受信すると、低優先フローだけを終了させる。これで輻輳が解決しない場合、出口エッジノードは、フローを終了させる命令を伴う後続のフロー終了通知を入口エッジノードに対して送信し続けるであろう。遅延の後、このような後続の終了通知が到着し続ける場合、入口エッジノードは高優先フローを終了させる。

遅延が出口エッジノードに導入される場合、入口エッジノードは通常通りに動作し、フロー終了通知によってそうするように指示され次第、全てのフローを終了させることができる。出口エッジが輻輳を確認すると、出口エッジは最初に低優先フロー終了通知を入口エッジノードへ送信して、低優先フローだけの終了を指示する。他の出口ノードは、同じことを同時に行っているはずである。これらの通知が輻輳の解消に成功しない場合、出口エッジノードは、遅延の後、高優先フロー終了通知を送信し、こうして、終了させるべき低優先フローが残っていない場合に限って高優先フローを終了させる。

パケットが輻輳ルータを通過したことを示すために、ネットワーク内のルータがそこを通過するデータパケットのヘッダに輻輳フラグでマークを付けた結果として、ネットワーク内に輻輳があることを出口エッジノードが確認することが好ましい。フロー終了通知は、ＱｏＳ−ＮＳＬＰプロトコルメッセージであることが好ましい。

ネットワークが高優先フローのための十分なリソースを有することを保証することを目的として、入口エッジノードは、ネットワーク内のリソースが閾値を超える場合に限って、低優先フローがネットワーク内に進入する許可を与えることが好ましい。この閾値は、高優先フローの所与の数に対応してもよい。

閾値は、入口エッジノードのための静的な数字であってもよいが、できれば、高優先フローのためのアクティブなリソース予約の数と、低優先フローのためのアクティブなリソース予約の数と、高優先フローのためのリソース要求の割合と、低優先フローのためのリソース要求の割合とのうちの１以上に基づいて動的に判定されることが好ましい。高優先フローのためのリソース要求の割合は、特に重要であり、これが増える場合、（低優先フローが許可されるかどうかについて決定が行われるときには）高優先フローのために予約されるリソースが増やされてもよい。一実施形態では、閾値は、高優先フローのためのリソース要求の割合の一次関数として計算される。

次いで高優先フローは、自動的に、あるいは少なくとも１つのポリシーに基づいて、ネットワークへの進入を許可されてもよい。これによって、高優先フローができる限り小さい遅延でネットワークに進入することが保証される。輻輳が生じた場合、上述の阻止プロセスが輻輳を確認し、そして低優先フローを終了させ始めるであろう。

入口エッジノードが、ネットワークを通じて予約メッセージを出口エッジノードへ送信し、その予約メッセージは、データ経路沿いのリソースを予約するためのリソース予約オブジェクトと、データ経路沿いの利用可能なリソースについての情報を収集するためのリソース利用可能性オブジェクトとを含んでいることが好ましい。出口エッジノードは、入口エッジノードへの応答を送信してもよく、その応答は、リソース予約が成功したかどうかを表し、そして、データ経路沿いの利用可能なリソースを表す。

また本発明は、上記の方法のいずれかを実行するように構成されたＩＰネットワーク、入口エッジノード、および／または出口エッジノードを提供する。

ＩＰネットワークの出口エッジノードであって、
前記ネットワーク内の１以上のルータに輻輳が存在することを確認し、
前記輻輳を解消するために、低優先フロー及び高優先フローのうちの少なくとも一方を含む、終了させるデータフローを選択し、
前記選択されたデータフローのうちの前記低優先フローを特定する低優先フロー終了通知を、前記ネットワークの入口エッジノードへ送信し、
所定の遅延期間の後に再び前記輻輳を監視し、
前記所定の遅延期間の後に依然として前記輻輳が存在する場合に、終了させるために選択された前記データフローのうちの前記高優先フローを特定する高優先フロー終了通知を、前記入口エッジノードへ送信する
ように構成されることを特徴とする出口エッジノードが提供される。

本発明の別の態様によれば、ＩＰネットワークの入口エッジノードであって、
前記ネットワークにおいて状態を予約し、
前記予約した状態に基づいてデータフローを前記ネットワークへ転送し、
終了させるために選択されたデータフローを特定する最初のフロー終了通知を、前記ネットワークの出口エッジノードから受信し、
前記選択されたデータフローのうちの低優先フローを終了させ、
所定の遅延期間、待機し、
前記最初のフロー終了通知に含まれる高優先フローを含む、終了させるために選択された更なるデータフローを含む、後続のフロー終了通知が、前記所定の遅延期間の後に前記出口エッジノードから受信された場合にのみ、前記選択されたデータフローのうちの前記高優先フローを終了させる
ように構成されることを特徴とする入口エッジノードが提供される。

本発明の更に別の態様によれば、ＩＰネットワークの入口エッジノードであって、
前記ネットワークにおいて状態を予約し、
前記予約した状態に基づいてデータフローを前記ネットワークへ転送する
ように構成され、
前記ネットワークで利用可能なリソースが閾値より多い場合にのみ、低優先フローが前記ネットワークへ転送され、最低限の数の高優先フローのための十分なリソースを保証する
ことを特徴とする入口エッジノードが提供される。閾値は、高優先フローのためのリソース要求の割合に基づいて動的に判定されることが好ましい。

輻輳が発生しているＩＰ ＤｉｆｆＳｅｒｖ領域の要素を略示する図である。 図１と同様のＩＰ ＤｉｆｆＳｅｒｖ領域を略示する図である。 許可制御プロセスを図解する、ＩＰ ＤｉｆｆＳｅｒｖ領域を略示する図である。 輻輳制御プロセスを図解する、ＩＰ ＤｉｆｆＳｅｒｖ領域を略示する図である。

典型的なＩＰ ＤｉｆｆＳｅｒｖ領域、例えば図１に例示するＤｉｆｆＳｅｒｖ領域は、入口エッジノードと、出口エッジノードと、内部ルータとを含む。ＤｉｆｆＳｅｒｖ領域は、低優先データフローと高優先データフローとを配信する。優先度は、「呼レベル」での記述子であり、このことは、「転送」についての優先度が、「許可」や「阻止」についての優先度とは異なりうることを意味する。低優先トラヒックが、高優先トラヒックと同じ、パケットレベルでのＱｏＳ要件を有する可能性がある。この一例として、音声通話の事例があげられる。通常の音声通話は、パケットレベルでは、緊急通話と同じ遅延／ジッタ要件を有する。しかし、輻輳がある場合、緊急通話は、通常の音声通話より優先されるべきである。パケットヘッダは、Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ Ｃｏｄｅ Ｐｏｉｎｔ（ＤＳＣＰ）として知られる分類フィールドを含んでおり、高優先フローと低優先フローとで異なるＤＳＣＰを用いることができる。これは、それらがＤｉｆｆＳｅｒｖにおいて異なるＰＨＢを割り当てられうることを意味する。

しかし、高優先フローおよび低優先フローについて同じＤＳＣＰが用いられた場合、いずれの優先度のパケットも同じ転送の振る舞いの下で動作する可能性がある。さらに、利用可能なＤＳＣＰの数は限られている。これは、利用可能なコードポイント空間が非常に少ないという、ＤｉｆｆＳｅｒｖの一般的な問題に関連する。従って、別のＤＳＣＰを用いることによって高優先フローと低優先フローとを区別することはしないことが望ましい。下記のシステムでは、高優先フローと低優先フローとは、呼レベルで区別される。パケットレベルでは、それらは同様の振る舞いを行い、すなわち、同じＤＳＣＰを使用する可能性がある。

通常の条件下と予期せぬ条件下とのいずれの場合でもＱｏＳと正確な優先度割当てとを保証する目的で、許可制御プロセスおよび阻止プロセスが用いられてもよい。

許可制御プロセスは、フローがネットワークへの進入を許可される前に用いられる。ステートレス領域の入口エッジノードへ新規の低優先フローの要求が到着すると、入口エッジノードは、ステートレス領域を通して予約メッセージを送信することによって、そのフローのためのリソースの予約を試行する。予約に加えて、高優先呼のためのリソースの利用可能性がチェックされる。利用可能なリソースは、ＲＳＶＰにおけるＡｄＳｐｅｃオブジェクトを用いることによってかまたはＱｏＳ−ＮＳＬＰにおけるＡｖａｉｌａｂｌｅ ＱｏＳを用いることによって、データ経路内で収集することができる。低優先呼は、利用可能なリソースが閾値の値を超える場合に限って、進入を許可される。閾値の値は、入口エッジで予想される優先呼の数と新規のリソース要求の頻度との関数である。このようにして、低優先呼を許可する場合に、リソース要求の急な増加を考慮に入れることができる。低優先フローが許可されるときに高優先フローのためのリソースのリソース利用可能性がチェックされるのだから、高優先フローのためのステートレス領域での追加のリソース予約は不要である。高優先フローの許可制御は、入口エッジにおける単一のポリシー決定に基づいてもよい。これによって、ステートレス領域内での高優先フローのための予約を行う必要がないのだから、優先呼のための迅速な許可が保証される。

このプロセスは、図３を参照して理解することができ、図３は、２つの入口エッジノード３０１および３０２と、２つの出口エッジノード３０３および３０４と、３つの内部ルータ３０５、３０６、３０７とを有するＩＰ ＤｉｆｆＳｅｒｖ領域３００の概略図である。呼またはデータフローがＤｉｆｆＳｅｒｖ領域３００への進入を許可される前に、フローの必要リソースと優先度とを示すシグナリング要求が入口エッジ３０１に到着する。入口エッジ３０１が要求されたフローの優先度をチェックする。それが高優先であれば、フローは許可される。例えば、許可される優先フローの最大数かまたは優先フローのために予約されたリソースの最大量に達したかどうかを確認するためにチェックすることによって優先フローを制限するという、追加のポリシーが適用されてもよい。これは、入口ノード毎のやり方（ホース・モデル）で行われてもよいし、入口−出口ペア毎のやり方（トランク・モデル）で行われてもよい。

要求が低優先フローに属する場合、シグナリングメッセージが、領域内のリソースを要求しながら、かつ、領域内で追加リソースの利用可能性をチェックしながら、領域の中を通って送信される。低優先フローは、
（１）領域内の予約が成功し、且つ、
（２）利用可能なリソースが、Ａで表される閾値の値を超えている
場合に許可される。

Ａは、入口エッジ３０１のために設定された定数であってもよい。あるいは、それぞれｎ_ｌｏｗ、ｒ_ｌｏｗ、ｎ_ｈｉｇｈ、ｒ_ｈｉｇｈで表される、低優先フローおよび高優先フローに関するアクティブなリソース予約の数とリソース要求の頻度との関数であってもよい。
Ａ＝Ｆ（ｎ_ｌｏｗ，ｒ_ｌｏｗ，ｎ_ｈｉｇｈ，ｒ_ｈｉｇｈ）

簡単な例として、Ａは、高優先の呼要求の頻度の割合の一次関数であってもよい。
Ａ＝ａ＋ｂ＊ｒ_ｈｉｇｈ

ここで、ａは、高優先フローのために予約された強制リソースを示す。ｂ＊ｒ_ｈｉｇｈの項によって、フローの大幅な増加を考慮に入れることが可能になる。例えば、緊急事態が原因で緊急呼の数が大幅に増加する場合、ｒ_ｈｉｇｈが増加し、従って、高優先呼のために多くのリソースが予約される（高優先呼の数も大幅に増加すると予想される）。

利用可能なリソースをチェックして、低優先フローのための帯域幅を予約するのに、２つの選択肢が利用できる。一方の選択肢では、閾値Ａは、入口ノード３０１の中で設定される。他方の選択肢では、Ａは、各ノードの中で決定される。

Ａが、（入口エッジ３０１で設定された）入口毎のパラメータである場合には、ＮＳＩＳプロトコルを用いて、予約のためのいろいろなプロセスがＱｏＳ−ＮＳＬＰおよびＱＳｐｅｃ Ｔｅｍｐｌａｔｅの中に記述される。送信者が開始する１つの起こりうる予約プロセスは以下の通りである。入口エッジノード３０１が、「ＱｏＳ Ｄｅｓｉｒｅｄ」オブジェクトと「ＱｏＳ Ａｖａｉｌａｂｌｅ」オブジェクトとを含むＲＥＳＥＲＶＥメッセージを出口エッジノード３０３へ送信する。「ＱｏＳ Ｄｅｓｉｒｅｄ」は、経路沿いの必要なリソースを予約するのに用いられる。「ＱｏＳ Ａｖａｉｌａｂｌｅ」は、利用可能なリソースを収集する。それに応じて、出口エッジノード３０３は、予約が成功したか否かを示すＲＥＳＰＯＮＳＥメッセージを送信する。またＲＥＳＰＯＮＳＥメッセージは、データ経路沿いの利用可能なリソースを入口エッジノード３０１に示す。入口エッジノード３０１は、利用可能なリソースがＡを超える場合に限って、低優先フローを許可する。この条件が満たされない場合、（たった今予約されたばかりの）リソースは削除される。

他方の選択肢では、Ａは、各ホップの中で設定される。この場合、ＲＥＳＥＲＶＥメッセージは、入口３０１から出口３０３へ進むにつれて、各ホップにおいて二重の許可条件に直面する。各ノードは、通常の予約に基づく条件で動作するだけでなく、ローカルリンクの空き容量をＡと比較する。予約が完了して、全てのローカルリンクが、それらのローカルなリソースパラメータと比較して十分なリソースを有する場合、フローは許可される。

許可制御プロセスは、通常の動作条件下で許可されたフローのためのＱｏＳを提供する。呼の割合の大幅な増加および／またはリンクもしくはノードの障害などの異常な条件（その結果、高優先フローの予期せぬ大規模なバーストが起こることがある）を処理する目的で、阻止アルゴリズムが必要になる可能性もある。阻止アルゴリズムは、一部のフローを、他のフローのＱｏＳを維持する目的で、終了させるのに用いられる。前述の阻止アルゴリズムは、低優先フローを終了させて高優先フローを維持することを保証する。

理解されるであろうが、終了させうる低優先トラヒックフローが十分にない場合には、優先度の高い呼も同じく終了させられるであろう。終了させうる、低い優先度のフローがない場合に限って高優先フローを終了させることを、阻止アルゴリズムが保証する。また、阻止アルゴリズムは、ルート変更の後の重度の輻輳、例えばリンクまたはノードの障害の場合には、低優先呼を終了させることに責任を持つ。

予期せぬ条件下では、トラヒックが、ルータもしくはリンクの容量を超える可能性がある。一例を図４に示すが、これは、図３に示す領域３００を図解している。図４に示す状況では、データ経路内のリンク４０８が、内部ルータ３０６と３０７との間で故障する。リンクの障害を検出した後、ルーティングプロトコルは、リンク４０９および４１０と、ルータ３０５および３０６とを経由する代替データ経路へとトラヒックをルート変更する。この状況では、ルート変更の前には許可制御はなく、従って、トラヒックが、新規経路の中の１つ以上のルータ３０５および３０６や、リンク４０９および４１０の容量を超えてしまう可能性がある。輻輳ルータ３０５は、処理できないパケットを破棄する。

ＲＭＤは、パケットが単純に破棄されるのを防ぐための重度輻輳処理機能を定義する。ＲＭＤでは、各ルータ３０５、３０６、３０７が、破棄されたバイトの数を定期的に測定し、輻輳ルータを通過するパケットに再度マークを付ける。パケットのＤＳＣＰフィールドにマークが付けられる。再度マークされたバイトの数は、超過トラヒックを示す。内部ルータの動作は、ＩＥＴＦドラフト［進行中のＡ．Ｂａｄｅｒ他、「ＲＭＤ−ＱＯＳＭ：Ａｎ ＮＳＩＳ ＱｏＳ Ｓｉｇｎａｌｉｎｇ Ｐｏｌｉｃｙ Ｍｏｄｅｌ ｆｏｒ Ｎｅｔｗｏｒｋｓ Ｕｓｉｎｇ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ ｉｎ ＤｉｆｆＳｅｒｖ（ＲＭＤ）」］およびＷＯ ２００６／０５２１７４に記述されているものとほぼ同じである。

出口エッジノード３０３および３０４は、領域内の重度の輻輳を処理するための専用の機能を有する。出口エッジノード３０３および３０４は、再度マークされたパケットがあるかどうかを監視し、そして、再度マークされたパケットが検出された場合、マークされたバイトの数を定期的に測定する。また、影響を受けたフローを識別して、輻輳を緩和するために、どのくらいの数のフローを、そして、どのフローを終了させるべきかを判定する。終了させるべきフローは、それらのポリシーに従って選択される。優先度が低いフローが最初に選択される。終了させうる低優先フローが十分にはない場合、優先度が高いフローも同じく選択される。出口エッジノード３０４、３０５は、選択されたフローを終了させることを目的として、選択された各フローについて、通知メッセージ４１１を（フローの起源である）対応する入口ノード３０１へ送信する。

この通知メッセージ４１１が受信されると、入口エッジノード３０１は、対応するフローの優先度と、その終了メッセージがどの出口エッジノード３０３から到着したかとをチェックする。優先度が低い場合、フローを即座に終了させる。

通知メッセージが高優先フローに対応する場合、フローを即座には終了させない。代わりに、フローを終了させるべきかどうかの決定は、Ｔ_{ｄｅｌａｙ}の時間枠だけ延期され、それは典型的には２乃至３測定時間枠という長さである。同じ出口エッジからの終了メッセージがＴ_{ｄｅｌａｙ}の後も依然として受信されている場合に限って、選択された高優先フローを終了させる。高優先フローについて更なる通知メッセージが存在しない場合、選択された高優先フローは、終了させない。輻輳ノード３０５を通過するけれども別の出口エッジノード３０４を通って領域３００を出て行く低優先フローが依然として存在する場合に、高優先フローの代わりにこれらの低優先フローを終了させるであろうということを、アルゴリズムは保証する。従って、高優先フローの終了は回避される。

終了させるために選択されたフローのビットレートを入口エッジノード３０１が（例えば測定によって、またはトラヒックタイプによって）知っている場合、アルゴリズムはさらに改良されうる。この場合、入口エッジノード３０１は、選択された高優先フローのトラヒック量を監視することができ、そして、遅延時間の後、実際の過負荷に対応するこれらのフローを終了させればよい。

別の実施形態では、フローを優先度に応じて終了させるべきか否かを入口ノードに指示するＢａｎｄｗｉｄｔｈ Ｂｒｏｋｅｒ（ＢＢ）によって、遅延が導入され、監視されてもよい。

別の実施形態では、出口エッジノード３０３、３０４は、輻輳を表すマーク付きのパケットを最初に受信した場合、高優先フローの終了通知メッセージ４１１を保留する。高優先フローの終了通知メッセージ４１１は、輻輳のある高優先フローを示すマーク付きパケットが遅延時間Ｔ_{ｄｅｌａｙ}の後も依然として受信されている場合に限って、送信される。この実施形態では、入口エッジノード３０１は、高優先フローについても低優先フローについても同じやり方で振舞い、通知メッセージ４１１が受信された直後にそれらを終了させる。

また、阻止アルゴリズムは、入口エッジノード３０１で要求された高優先フローのためのリソースがＡを超える場合に高優先トラヒックのＱｏＳを維持することにも責任を持つ。この場合、許可制御プロセスは、（別のポリシーによって妨げられない限り）依然として高優先フローを自動的に許可する。これが輻輳につながった場合には、すぐ前に述べたように、同じデータ経路の中の低優先フローを、阻止アルゴリズムによって終了させるであろう。

上述のプロセスは、このように高優先トラヒックおよび低優先トラヒックを動的に処理する。許可制御プロセスは、高優先フローのためのリソースが存在するであろうということと、許可される場合には低優先フローのためのリソースが存在するであろうということとを保証する。しかし、高優先フローのために帯域幅を予約する必要はない。従って、リソースは一層効率よく使われる。

高優先フローの許可は迅速に行われるが、それは、これらのフローについてはＤｉｆｆＳｅｒｖ領域内にリソース予約が存在しないからである。

許可制御プロセスおよび阻止プロセスは一緒に、ロバストなＱｏＳサポートを提供する。ネットワーク内のゆっくりした変化は、許可制御によって処理される。トラヒック量が急激に変化する場合、阻止アルゴリズムは、変化に対して反応することができ、高優先フローに係る大半の呼もしくは全ての呼についてＱｏＳを回復させることができる。

従って、上述のプロセスは、高優先フローのための予約要求の大幅な増加を効率よく処理することができる。プロセスは、クラス毎の状態に基づいており、従って、ＲＭＤのようなステートレスプロトコルに適用可能である。フロー毎の状態がなくても、上記のプロセスは、ルート変更が原因の重度の輻輳を解決する。許可制御は、さらに帯域幅効率が良い。高優先トラヒックの代わりに優先度が低いトラヒックを終了させることは、一定の状況では回避できる。

理解されるであろうが、上記の実施形態の変形形態は、本発明の範囲内に入ることができる。

Claims (21)

1. 少なくとも２つの優先度レベルを持つ複数のデータフローを送信するＩＰネットワークにおいてサービス品質を管理する方法であって、
   前記ネットワークの出口エッジノードにおいて、前記ネットワーク内の１以上のルータに輻輳が存在することを確認するステップと、
   前記輻輳を解消するために、終了させるデータフローを選択するステップと、
   前記選択されたデータフローを特定する最初のフロー終了通知を、前記ネットワークの前記出口エッジノードから入口エッジノードへ送信するステップと、
   前記入口エッジノードにおいて、前記最初のフロー終了通知が受信されると、前記選択されたデータフローのうちの低優先フローを終了させるステップと、
   前記出口エッジノードにおいて、所定の測定期間の後に、依然として輻輳が存在するか否かを確認し、存在する場合、終了させるための更なるデータフローを選択し、当該更なるデータフローを特定する後続のフロー終了通知を前記入口エッジノードへ送信するステップと、
   前記入口エッジノードにおいて、前記選択されたデータフローのうちの高優先フローを終了させるステップであって、
   前記最初のフロー終了通知の受信から所定の遅延期間が経過した後に、少なくとも１つの前記後続のフロー終了通知が前記入口エッジノードによって受信され、且つ、
   前記所定の遅延期間の後に受信された前記少なくとも１つの前記後続のフロー終了通知が、前記選択された前記終了させるための更なるデータフローの中に同一の高優先フローを含む
   場合にのみ、前記選択されたデータフローのうちの高優先フローを終了させるステップと、
   を備えることを特徴とする方法。
2. 前記選択された高優先フローのビットレートが前記入口エッジノードによって知られており、前記輻輳を軽減するために必要とされるより多くの高優先フローは終了されないことを特徴とする請求項１に記載の方法。
3. 前記所定の遅延期間は、帯域ブローカーによって導入されることを特徴とする請求項１に記載の方法。
4. 前記帯域ブローカーは、前記最初の終了通知が受信された場合に前記選択されたデータフローのうちの前記低優先フローを終了するように前記入口エッジノードに指示し、
   前記所定の遅延期間の後に少なくとも１つの前記後続の終了通知メッセージが前記入口エッジノードによって受信され、且つ、
   前記所定の遅延期間の後に受信された前記少なくとも１つの前記後続の終了通知メッセージが、前記終了させるために選択された更なるデータフローの中に同一の高優先フローを含む
   場合にのみ、前記選択されたデータフローのうちの前記高優先フローを終了するように前記入口エッジノードに指示する
   ことを特徴とする請求項３に記載の方法。
5. 前記１以上のルータが、前記１以上のルータを通過するデータパケットのヘッダに、当該パケットが輻輳しているルータを通過したということを示す輻輳フラグによりマークを付けることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記フロー終了通知はＱｏＳ−ＮＳＬＰプロトコルメッセージであることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記入口エッジノードが低優先データフローの要求を受信した場合、当該低優先データフローは、前記ネットワークで利用可能なリソースが閾値より多い場合にのみ、前記ネットワークに進入することを許可されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記閾値は、所定数の高優先フローのために十分なリソースを利用可能であることを保証するように決定されることを特徴とする請求項７に記載の方法。
9. 前記閾値は、高優先フローのためのアクティブなリソース予約の数と、低優先フローのためのアクティブなリソース予約の数と、高優先フローのためのリソース要求の割合と、低優先フローのためのリソース要求の割合と、のうちの１以上に基づいて決定されることを特徴とする請求項７又は８に記載の方法。
10. 前記閾値は、高優先フローのためのリソース要求の割合の一次関数であることを特徴とする請求項９に記載の方法。
11. 前記低優先データフローは、前記ネットワークを通るデータ経路が予約された場合にのみ、前記ネットワークに進入することを許可されることを特徴とする請求項７乃至１０のいずれか１項に記載の方法。
12. 前記入口エッジノードが前記低優先データフローの前記要求を受信した場合、予約メッセージが前記出口エッジノードへ送信され、
    前記予約メッセージは、前記データ経路に沿ってリソースを予約するためのリソース予約オブジェクトと、前記データ経路に沿って利用可能なリソースに関する情報を収集するためのリソース利用可能性オブジェクトと、を含む
    ことを特徴とする請求項１１に記載の方法。
13. 前記出口エッジノードは、前記入口エッジノードへ応答を送信することによって前記予約メッセージの受信に応答し、
    前記応答は、前記リソース予約が成功したか否かを示し、且つ、前記データ経路に沿って利用可能なリソースを示す
    ことを特徴とする請求項１２に記載の方法。
14. 前記入口エッジノードが高優先データフローの要求を受信した場合、当該高優先データフローは、単一のポリシー決定に基づいて、前記ネットワークに進入することを許可されることを特徴とする請求項７乃至１３のいずれか１項に記載の方法。
15. 前記入口エッジノードが高優先データフローの要求を受信した場合、当該高優先データフローは、自動的に、前記ネットワークに進入することを許可されることを特徴とする請求項７乃至１３のいずれか１項に記載の方法。
16. 前記ＩＰネットワークはＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ａｒｃｈｉｔｅｃｔｕｒｅを用いて構築されることを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
17. 請求項１乃至１６のいずれか１項に記載の方法を実行するように構成されたＩＰネットワーク。
18. ＩＰネットワークの入口エッジノードであって、
    前記ネットワークにおいて状態を予約し、
    前記予約した状態に基づいてデータフローを前記ネットワークへ転送し、
    終了させるために選択されたデータフローを特定する最初のフロー終了通知を、前記ネットワークの出口エッジノードから受信し、
    前記選択されたデータフローのうちの低優先フローを終了させ、
    所定の遅延期間、待機し、
    前記最初のフロー終了通知に含まれる高優先フローを含む、終了させるために選択された更なるデータフローを含む、後続のフロー終了通知が、前記所定の遅延期間の後に前記出口エッジノードから受信された場合にのみ、前記選択されたデータフローのうちの前記高優先フローを終了させる
    ように構成されることを特徴とする入口エッジノード。
19. 前記ネットワークで利用可能なリソースが閾値より多い場合にのみ、低優先フローが前記ネットワークへ転送され、最低限の数の高優先フローのための十分なリソースを保証するように構成されることを特徴とする請求項１８に記載の入口エッジノード。
20. 前記閾値は、高優先フローのためのリソース予約の割合に少なくとも基づいて決定されることを特徴とする請求項１９に記載の入口エッジノード。
21. 前記入口エッジノードが高優先データフローの要求を受信した場合、当該高優先データフローは、単一のポリシー決定に基づいて、前記ネットワークに進入することを許可されるように構成されることを特徴とする請求項１９又は２０に記載の入口エッジノード。

Images