JP2012531867A - トラフィック負荷を管理する方法 - Google Patents

Abstract

本発明は、ネットワークノード２のトラフィック負荷を管理する方法、ならびにこの方法を実行するためのネットワークノード２およびコンピュータプログラム製品に関する。ネットワークノード２は、パケット交換網１００において１つまたは多数の同時発生アプリケーションストリームから集約されたパケットトラフィックを受信する。１つまたは多数の同時発生アプリケーションストリームの数は、パケットトラフィックの粒度として推定される。推定された粒度およびネットワークノード２の現在のトラフィック負荷に基づいて、ドロップ確率Ｐａが計算される。計算されたドロップ確率Ｐｄは、輻輳制御のために提供される。

Description

本発明は、パケット交換網において多数の短期間のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノードのトラフィック負荷を管理する方法、ならびに上記方法を実行するためのネットワークノードおよびコンピュータプログラム製品に関する。

ＲＦＣ２３０９は、パケットトラフィックを処理する現在のルータで一般的に使用される輻輳通知アルゴリズムであるランダム初期検知（Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｅｔｅｃｔｉｏｎ＝ＲＥＤ）アルゴリズムについて記載している。詳細には、ＲＥＤアルゴリズムは、ルータまたはスイッチのようなネットワークノードにおいてトラフィック負荷の管理に使用される。

「Ｂａｎｄｗｉｄｔｈ Ｄｉｍｅｎｓｉｏｎｉｎｇ ｉｎ Ｐａｃｋｅｔ−ｂａｓｅｄ Ａｇｇｒｅｇａｔｉｏｎ Ｎｅｔｗｏｒｋｓ」、Ｌａｕｔｅｎｓｃｈｌａｇｅｒ，Ｗ．およびＦｒｏｈｂｅｒｇ，Ｗ．、Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ Ｂｅｌｌ Ｌａｂｓ、Ｍｕｒｒａｙ Ｈｉｌｌ、ＮＪ、ＵＳＡ、Ｔｈｅ １３ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｎｅｔｗｏｒｋ Ｓｔｒａｔｅｇｙ ａｎｄ Ｐｌａｎｎｉｎｇ Ｓｙｍｐｏｓｉｕｍ ２００８（略してＮｅｔｗｏｒｋｓ ２００８）、Ｂｕｄａｐｅｓｔ ２００８年９月２８日−２００８年１０月２日、１−１８頁、ＩＳＢＮ：９７８−９６３−８１１１−６８−５、ｈｔｔｐ：／／ｉｅｅｅｘｐｌｏｒｅ．ｉｅｅｅ．ｏｒｇ／ ＩＴＵ／ＩＴＣ Ｔｅｌｅｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ Ｈａｎｄｂｏｏｋ、ＩＴＵ−Ｄ Ｓｔｕｄｙ Ｇｒｏｕｐ２、Ｑｕｅｓｔｉｏｎ １６／２、Ｇｅｎｅｖａ、２００４年３月、ｈｔｔｐ：／／ｗｗｗ．ｃｏｍ．ｄｔｕ．ｄｋ／ｔｅｌｅｔｒａｆｆｉｃ／ Ｆｌｏｙｄ、Ｓ．およびＪａｃｏｂｓｏｎ、Ｖ．、Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｅｔｅｃｔｉｏｎ Ｇａｔｅｗａｙｓ ｆｏｒ Ｃｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ、ＩＥＥＥ／ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｎｅｔｗｏｒｋｉｎｇ，Ｖ．１ Ｎ．４，１９９３年８月、３９７−４１３頁

ネットワークノードのトラフィック負荷の改善された管理を提供することが、本発明の目的である。

本発明の第１の目的は、ａ）ネットワークノードの伝送容量Ｂに適合するアプリケーションストリームの最大数としてパケットトラフィックの粒度を推定するステップと、ｂ）推定された粒度およびネットワークノードのトラフィック負荷に基づいてドロップ確率Ｐ_ｄを計算するステップと、ｃ）輻輳制御のために計算されたドロップ確率Ｐ_ｄを提供するステップとを含む、パケット交換網において多数のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノードのトラフィック負荷を管理する方法によって達成される。本発明の第２の目的は、パケット交換網において多数のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノードによって達成され、このネットワークノードは、ネットワークノードの伝送容量Ｂに適合するアプリケーションストリームの最大数としてパケットトラフィックの粒度を推定し、推定された粒度およびネットワークノードのトラフィック負荷に基づいてドロップ確率Ｐ_ｄを計算し、計算されたドロップ確率Ｐ_ｄを輻輳制御のために提供するように構成された制御ユニットを含む。本発明の第３の目的は、パケット交換網において多数のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノードのトラフィック負荷を管理するためのコンピュータプログラム製品によって達成され、このコンピュータプログラム製品は、ネットワークノードによって実行されるとき、ネットワークノードの伝送容量Ｂに適合するアプリケーションストリームの最大数としてパケットトラフィックの粒度を推定するステップと、推定された粒度およびネットワークノードのトラフィック負荷に基づいてドロップ確率Ｐ_ｄを計算するステップと、計算されたドロップ確率Ｐ_ｄを輻輳制御のために提供するステップとを行う。

アプリケーションストリームは、同時発生アプリケーションストリーム、すなわちその存続期間が互いと重なり合うアプリケーションストリームである。ネットワークノードは、エンドポイント間、例えば送信元と宛先との間のパケットトラフィックの伝送における中間ノードである。ネットワークノードは、送信元と宛先との間の伝送機能を表す。ネットワークノードは、パケットを処理するために、例えばルーティングするために、パケットトラフィックを受信する。パケットトラフィックの伝送手段として、ネットワークノードは、ある一定の伝送容量Ｂを所有する。ネットワークノードがルータまたはスイッチである場合、ネットワークノードの伝送容量は、パケットがルータまたはスイッチを介してそれぞれルーティングまたは交換されるレートによって限定される。ネットワークノードが伝送リンク、より正確にはそのエントリポイントである場合、伝送容量は、単にリンクの伝送速度である。パケットトラフィックの量がゼロである場合、ネットワークノードによって表されるリンクの負荷、すなわちリンク負荷もまたゼロ、すなわちその最小値である。パケットトラフィックの量が伝送容量に等しい場合、ネットワークノードのリンク負荷は１、すなわちその最大値である。パケットトラフィックの量が伝送容量より大きい場合、リンク負荷は１より大きい、すなわちネットワークノードは過負荷状態である。

パケットトラフィックは、多数の短期間のアプリケーションストリームから多重化される。本発明は統計的方法に基づいているので、本方法は、統計的に有意な数の同時発生アプリケーションストリームにより良く機能する。考慮されるタイムスケールにわたって多数のアプリケーションストリームが含まれているが、ある一定の時点では、１つまたは少数のアプリケーションストリームのパケットのみがネットワークノードに到着している場合があることに注意されたい。「短期間」という用語は、アプリケーションストリームの継続時間が有限の長さであり、好ましくは少なくとも、輻輳制御に含まれる、例えばネットワークノードなどのシステムの典型的なサービス時間よりもかなり短いことを意味する。特定のアプリケーションストリームは、エンドユーザアプリケーションの通信イベントを表す。これは、ビットレート、サイズ、および／または継続時間によって特徴付けられる。アプリケーションストリームは、例えばパケットベースの集約ネットワークを介して上記ノードに接続された多数のエンドユーザによってランダムに、また互いとは無関係に、開始される。同時発生アプリケーションストリームの平均数および平均ビットレートは、パケットトラフィックの粒度と呼ばれ、すなわち時間の所与の瞬間において開始されたがまだ終了されていないアプリケーションストリームの数である。

一時的に高くなるパケットの負荷を吸収することができるように、ネットワークノードは、バッファを含むこと、すなわち新しく到着した受信パケットが、そのパケットの処理される順番が来るまでバッファされることが好ましい。時間の所与の瞬間にバッファが満杯である場合、受信パケットはバッファされることが可能ではなく、ドロップされなければならない、すなわちパケットは失われる。

イーサネット（登録商標）／ＩＰのような無接続方式のパケット伝送網では、これらのネットワークにおける広く用いられている輻輳緩和は、弾性的トラフィックの概念である（ＩＰ＝Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、インターネットプロトコル）。トラフィック源は、現在の送信レートを下げる要求とともに輻輳状態について知らされる。この本発明の説明では、「現在の」という用語は、現在の時間、好ましくは現時点に開始される、現時点を含んだ、所定の非ゼロの時間間隔の間続く時間、または現時点に終わる、現時点を含んだ、所定の非ゼロの時間間隔の間続いた時間を意味する。理論的に言えばこれは、すべてのソースが公平に共有されて、１００％のリソース利用に近い平衡、およびごくわずかな低損失をもたらす。実際に、最も一般的な弾性的トラフィックの実行は、ＴＣＰプロトコルである（ＴＣＰ＝Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、伝送制御プロトコル）。ＴＣＰは、失われたパケットを再送するために、接続エンドポイントへのパケットの到着の記録をとる。同時に、記録されたパケットの損失は、暗黙の輻輳通知として解釈される。適正なＴＣＰ実行は、それに応じてその送信レートを下げる。本発明の諸実施形態は、オーバフローがまれな例外となるように弾性的トラフィック（例えばＴＣＰ）を管理するために使用されることが可能である。本発明の諸実施形態は、既存のＴＣＰ／ＩＰ網に導入されることが可能であるルーティングノードまたはスイッチングノードの構成可能な機能を提供する。利点は、ＴＣＰ接続の流れが非常に滑らかになり、待ち行列のジッタが大いに縮小され、バッファがより小さくなることである。本発明の諸実施形態は、例えばルータまたはスイッチなど、ＴＣＰプロトコルに従うパケット伝送機器における輻輳処理を提供する。

中間ルータまたはスイッチにおけるパケットのドロップによる上述の暗黙的輻輳通知は、特定のドロップ方式によって実行されることが可能である。直接的実行は、パケットが到着するがバッファが満杯であるときに必ずパケットのドロップが発生する単純なＦＩＦＯとしてバッファを調べることである（ＦＩＦＯ＝Ｆｉｒｓｔ Ｉｎ − Ｆｉｒｓｔ Ｏｕｔ、先入れ先出し）。どのパケットがドロップされるかによって、末尾ドロップ（Ｔａｉｌ Ｄｒｏｐ）、先頭ドロップ（Ｈｅａｄ Ｄｒｏｐ）、またはランダムドロップ（Ｒａｎｄｏｍ Ｄｒｏｐ）の方式は区別されることが可能である。残念ながら、こうした前述の単純なオーバフロードロップ方式は、いくつかの深刻な欠点を有する：いわゆるグローバル同期の危険がある、すなわち、影響を受けるすべての接続が、同期してその送信レートを下げ、再確立し、過負荷期間と利用期間とを交互に繰り返す結果となる。第２に、不公平なリソース割り当ての恐れがある。この種の誤った振る舞いの基となる根本的原因は、一般に受け入れられているＴＣＰ理論ではランダムに分散されるパケット損失の仮定とは対照的であるバッファのオーバフローの場合のパケットのドロップをバースト様にクラスタ化することである可能性が高い。上述の問題に対して十分に確立され、実行されている緩和策が、十分に確立されたランダム初期検知アルゴリズムである。現在のバッファのオーバフローの場合の単純なランダムドロップではなく、ＲＥＤは平均待ち行列のサイズに依拠する。パケットスイッチの平均待ち行列サイズは、差し迫るオーバフローの初期表示として使用される。平均待ち行列サイズが一定の閾値を超えてバッファの満杯状態に向かう場合、ランダムパケットドロップが開始されて、理想的には耐え難いバッファのオーバフローが発生する前の早い時期に、ＴＣＰエンドポイントにやがて起こるオーバフローを通知する。このプロセスは、パケット損失の危険なバースト化を回避するためである。本発明の諸実施形態は、ＲＥＤの拡張を行う。

ＲＥＤアルゴリズムは、制御メトリックとして平均待ち行列サイズを計算する。最近の研究は、この測定が、意図された定常状態の待ち行列サイズではなく経時的なオーバフロー状態の割合を指し示すことを明らかにしている。バッファの充填は、一般的に、「ほぼ空」と「ほとんど満杯」の間で変動しており、「ほぼ空」に重点を有するが、低い確率で間のどこか（単に２つの端点の間の過渡事象）となる。この観点から、ＲＥＤで使用される「平均待ち行列サイズ」は、経時的なオーバフロー状態の割合を示す幾分人工的な尺度である。言い換えれば、ＲＥＤにおける定常状態の待ち行列サイズの仮定は有効ではない。ＲＥＤは実際に機能するが、そのあらゆる好ましくない結果（クラスタ化されたパケットの損失、大規模な待ち行列のジッタなど）を伴ってバッファのオーバフローを本当には回避しない。さらにＲＥＤは、特定の転送プロセスには必要とされず、負荷測定デバイスとして誤用されるだけのバッファのディメンショニングにさらなる負担を与える。ＲＥＤは基本的にバッファのオーバフローによってトリガされるが、本発明は、バッファのオーバフローに依拠しない、ＲＥＤに代わるものを意味する。

本発明の諸実施形態は、滑らかに流れるＴＣＰ接続、より優れたリソースの利用、より少ないジッタを提供する。本発明の諸実施形態は、面倒な分類／優先順位付けなしに、バッファ空間要件を縮小し、サービスの共存を可能にする。ＲＦＣ２３０９と比べると、本発明の諸実施形態は、輻輳通知が時間とともにより良く広められる。本発明の諸実施形態は、ＴＣＰおよび上位（アプリケーション）層におけるクラスタ化された損失の重大な影響を回避する。

ＲＥＤの前述の縮小を避けるための１つの直接的考えは、輻輳通知を単に現在のトラフィック負荷にリンクさせることである。特定のネットワーク装置において平均負荷が容量の限界に近づいている場合、ランダムドロップにより、エンドポイントにおいてＴＣＰ伝送機による負荷軽減を起動することができる。この直接的手法が機能しない重大なポイントは、所与の容量の耐えられる負荷は、トラフィックの揮発性（ｖｏｌａｔｉｌｉｔｙ）によって決まり、これは、時間について、またあらゆる種類のネットワークについて決して均一ではないことである。先の手法に比べると、本発明は、トラフィックの揮発性に配慮する。

本発明は、面倒な分類および優先順位付けの方式なしに、多様なサービスのサービス品質に達することができる新しいパケット伝送網のパラダイムに設定される。本発明が設定される大域的考えは、極めて例外的な場合にのみ過負荷が発生するようにトラフィックを統計的に管理することである。

提案する発明は、現在のトラフィック負荷およびトラフィック揮発性によりドロップ確率を決定する。ＲＥＤとは違い、本発明の諸実施形態により決定されるドロップ確率は、バッファ負荷状態に依拠しない。本発明の諸実施形態によって決定されるドロップ確率は、バッファ空間とは無関係の大きさになる。このように、損失を滑らかに分散し（ＴＣＰフレンドリ）、待ち行列のジッタを低くして、バッファのオーバフローが十分に回避されることが可能である。副次的効果として、バッファ空間は小さく維持されることが可能である。

理論的には、パケットトラフィックの粒度もまた、例えばパケットの送信元アドレスおよび宛先アドレスなど、パケットプロトコルを調べることによって決定されることが可能である。しかしながらこれは、すべての中間ネットワークノードにおいて、どれが多くのリソースをバインドし、大量のデータ比較を必要とする時間のかかる手順であるかを見つけ出すステートフル接続を必要とする。

従属請求項によって示される本発明の諸実施形態によって、さらなる利点が得られる。

ステップｂ）は、次のステップ：平均Ａアプリケーションストリームを有するパケットトラフィックが、ｋアプリケーションストリームからなる確率Ｐ（ｋ）は、Ｐ（ｋ）＝Ａ^ｋｅ^−Ａ／ｋ！としてポアソン分布に従うと仮定するステップ、そのトラフィック量がネットワークノードの容量Ｂよりも小さい同時発生アプリケーションストリームの推定最大数がＮである場合、ｋ＞Ｎについて確率Ｐ（ｋ）の合計としてオーバフロー確率Ｐ_ｏｖを計算するステップ、ドロップ確率Ｐ_ｄはオーバフロー確率Ｐ_ｏｖよりも小さいと仮定するステップ、を含むことが可能である。Ｎは、そのトラフィック量がネットワークノードの容量Ｂよりも小さいアプリケーションストリームの推定最大数である。

ｈｔｔｐ：／／ｉｅｅｅｘｐｌｏｒｅ．ｉｅｅｅ．ｏｒｇ／から検索できる、文献「Ｂａｎｄｗｉｄｔｈ Ｄｉｍｅｎｓｉｏｎｉｎｇ ｉｎ Ｐａｃｋｅｔ−ｂａｓｅｄ Ａｇｇｒｅｇａｔｉｏｎ Ｎｅｔｗｏｒｋｓ」、Ｌａｕｔｅｎｓｃｈｌａｇｅｒ，Ｗ．およびＦｒｏｈｂｅｒｇ，Ｗ．、Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ Ｂｅｌｌ Ｌａｂｓ、Ｍｕｒｒａｙ Ｈｉｌｌ、ＮＪ、ＵＳＡ、Ｔｈｅ １３ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｎｅｔｗｏｒｋ Ｓｔｒａｔｅｇｙ ａｎｄ Ｐｌａｎｎｉｎｇ Ｓｙｍｐｏｓｉｕｍ ２００８（略してＮｅｔｗｏｒｋｓ ２００８）、Ｂｕｄａｐｅｓｔ ２００８年９月２８日−２００８年１０月２日、１−１８頁、ＩＳＢＮ：９７８−９６３−８１１１−６８−５によれば、トラフィックの揮発性は、基本的に、現在のトラフィック負荷を構成する同時発生アプリケーションストリーム数によって決まる。所与の負荷が多数の狭いアプリケーションストリームによって形成される場合には、その変動は低くなる。これは、（発生の可能性が低い）多数の追加ストリームを要求して、特定の伝送容量を過負荷にする。反対の場合、すなわち、少数の膨大なアプリケーションストリームがある場合、予想される変動は高くなる。ただ１つの追加アプリケーションストリームでさえリンクを過負荷にする可能性があり、これはいつでも起こる可能性がある。この影響は、次のように数学的に説明されることが可能である：同時発生アプリケーションストリームがランダムに発生するシステムでは、現在のストリーム数の確率分布は、ポアソン分布に従う：

ｋは現在のストリーム数、Ｐ（ｋ）は、Ａ同時発生アプリケーションストリームの平均転送トラフィックを有するリンク上のその数ｋがわかる確率とする。「現在の」という用語は、アプリケーションストリームの平均継続時間よりも実質的に短い現在の期間を指す。厳密に言えば任意の時点では、伝送リンク、例えばネットワークノードは、１００％パケットで占有されるか、またはアイドル状態／占有されていない状態となるので、概して本発明は現在の期間を指し、現在の時点を指さない。好ましくは短い期間を考えるときのみ、パケットトラフィックの粒度が明らかになる。

「リンク」という用語は、例えば、データ線またはデータリンクなど、受信パケットトラフィックを処理するネットワークノードと関連するパケット伝送機能を指す。リンクは、例えば、ビット／秒（＝ｂｐｓ）で測定される、限られた伝送容量Ｂを有する。ネットワーク要素の特定の容量Ｂが最大Ｎの同時発生アプリケーションストリームを処理できる場合、オーバフロー確率Ｐ_ｏｖは、ｋ＞Ｎでは式（１）の確率の合計である：

オーバフローの場合には、すべてのパケットが失われるとは限らず、わずかなオーバシュート剰余があり、実際の損失確率Ｐ_ｄ（＝ドロップ確率）は、オーバフロー確率Ｐ_ｏｖよりもわずかに小さい。より詳細な導出は、ＬａｕｔｅｎｓｃｈｌａｇｅｒおよびＦｒｏｈｂｅｒｇの上述の文献に掲載されている。Ｐ_ｄの対応する式は、以下の式（１４）に示す。

アプリケーションストリームは、パケット伝送網で宣言されず、均一サイズでもない。そこでトラフィック負荷もリンク容量も、前述の考えによれば負荷分布を拡散するための決定的パラメータである粒度がわからない。上記の式（１）および（２）による損失の確率の予測は、推定を利用しなければならない。

本発明の一実施形態によれば、ステップａ）は、次のステップ：伝送容量Ｂに対するネットワークノードのトラフィック負荷の時間平均率として容量利用率ｘを決定するステップであって、０≦ｘ≦１および時間平均が第１の時間スケールであるステップ、容量利用率ｘの時間平均値ｍ_１および容量利用率ｘの２乗ｘ^２の時間平均値ｍ_２を決定するステップであって、時間平均が第１の時間スケールよりも長い第２の時間スケールであるステップ、およびネットワークノードの伝送容量Ｂに適合するアプリケーションストリームの上述の推定最大数として、Ｎ＝ｍ_１／（ｍ_２−（ｍ_１）^２）を計算するステップ、を含む。

所与の集約パケットフローの粒度は、次の手段によって推定される。第１の平均化ステップにおいて、ネットワークノードに到着するパケットトラフィックは、ネットワークノードの、詳細には、パケットトラフィックが伝送されるリンク上のネットワークノードのデータリンクの利用可能容量Ｂに関連して設定される。本発明の一実施形態によれば、第１の平均化ステップは、関連ネットワークノードのバッファ保持時間に匹敵する第１の時間スケールで行われる。この第１の時間スケールは、およそ、パケットの伝送に要する時間、または２つの連続したパケット間の時間的距離とすることができる。本発明の一実施形態によれば、第１の時間スケールは、５００μｓから１００ｍｓの範囲、好ましくは１から１０ｍｓの範囲にある。結果として生じる「容量利用率」ｘは、０から１の値である。

容量利用率ｘは、相対トラフィック負荷とも呼ばれる。トラフィック負荷ｒは、時間単位あたりのデータユニットの率として、例えばビット／秒の単位で求められるデータレートとして測定される。相対トラフィック負荷ｘは、伝送容量Ｂに絶対トラフィック負荷ｒを関連させる０から１の範囲の無次元量である。

第２の平均化ステップでは、第２の時間スケールで時間について平均化することによって容量利用率ｘから第１のモーメントｍ_１が導出される。まず容量利用率ｘを２乗して、次にこの２乗した値を第２の時間スケールで時間について平均化することによって、容量利用率ｘから第２のモーメントｍ_２が導出される。「モーメント」という用語は、数理統計学において明確に規定された量である。ｍ_１およびｍ_２を作り出すために時間について平均化することは、同一パラメータを用いて行われる。この第２の時間平均化ステップは、極めてアプリケーションに依拠するが、上記の第１の時間平均化ステップと対照的に、第２の時間スケールは数分またはより大きい範囲にある。第２の時間スケールは、含まれるネットワーク数に依拠することが可能である。本発明の一実施形態によれば、第２の時間スケールは、１秒より大きい範囲にある。本発明の一実施形態によれば、第２の時間スケールは、第１の時間スケールより少なくとも１００倍大きい。

上記の第１および第２のモーメントの推定に、例えば、１カ月内の毎日の負荷曲線の対応する時間間隔について平均化するなど、他の平均化方法が適用されることも可能である。

モーメントｍ_１およびｍ_２から、同時発生アプリケーションストリームの推定最大数Ｎが計算され、すなわち、容量Ｂ（例えばビット／秒で求められる）は、ストリームの整数に変換される：

式（３）の導出について、次に説明する。総データレートｒを有する現在のトラフィックフローは、それぞれ（未知の）データレートｂ_ｒの多数のアプリケーションストリームのオーバレイであると仮定される。さらに、アプリケーションストリームが大規模（無限大に近い）ユーザ群からランダムに、互いと無関係に到着すると仮定される。ＩＴＵ／ＩＴＣ Ｔｅｌｅｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ Ｈａｎｄｂｏｏｋ、ＩＴＵ−Ｄ Ｓｔｕｄｙ Ｇｒｏｕｐ２、Ｑｕｅｓｔｉｏｎ １６／２、Ｇｅｎｅｖａ、２００４年３月、ｈｔｔｐ：／／ｗｗｗ．ｃｏｍ．ｄｔｕ．ｄｋ／ｔｅｌｅｔｒａｆｆｉｃ／から、この場合、現在の同時発生ストリーム数は、ポアソン分布に従う乱数ｋであることがわかる：

ここで、強度λは、同時発生ストリームの平均数に等しい（「必要トラフィック」としても知られ、「平均保持時間あたりの発呼数」としても知られる）。強度λは、次のように計算されることが可能である：

ｒは現在のトラフィックレート、Ｅ［ｒ］はｒの期待値とし、ｂ_ｒは単一アプリケーションストリームの未知のデータレートとする。同時に、利用可能な容量Ｂは、データレートｂ_ｒの最大Ｎアプリケーションストリームで搬送することができる：

式（５）および式（６）から、以下のように導出されることが可能である：

ここで、ｒ／Ｂは、（負荷対容量の）容量利用率ｘである。

ポアソン分布の標準偏差は、以下のとおりとわかっている：
σ^２＝λ 式（８）

一方、観測される同時発生アプリケーションストリームの数は、ｋ^＊＝ｒ／ｂ_ｒである。したがって、観測から導出される標準偏差は以下のようである：

式（７）、（８）、および（９）から、以下のように導出されることが可能である：

有限アプリケーションストリームを仮定すると、期待値は、時間についての平均値に置き換えられることが可能である：

帯域幅容量Ｂ内の同時発生アプリケーションストリームの推定最大許容数Ｎはわかっているので、期待パケットドロップ確率Ｐ_ｄは、次の用に計算されることが可能である：

転送トラフィックＡ＝Ｎ・ｍ_１とする。 式（１５）

所与の負荷レベルｍ_１におけるドロップ確率Ｐ_ｄは、負荷自体だけでなく、数Ｎで表される、トラフィックの粒度、すなわち同時発生ストリームの最大許容数にも依拠することは、明らかである。

検討されるトラフィックを供給される容量Ｂのネットワークノードは、ほぼ推定確率Ｐ_ｄでパケットをドロップすると予想されることが可能である。残念ながら、実際のドロップは、時間についてよく分散されていないが、詳細には現在の負荷ｘが許容限度を超えるときに、短いバーストにクラスタ化される。実際のドロップ率をクラスタ化することは、ＴＣＰで広く利用されているにもかかわらず、輻輳通知には不適切とする。

本発明の別の実施形態によれば、実際のドロップの代わりに、推定ドロップ確率Ｐ_ｄ（式（１４）参照）が輻輳通知に使用されることが可能である。これは、上記の第２の平均化演算の時間スケールである程度一定である。

上記解決法はさらに、ＴＣＰエンドポイントによるトラフィック適応への反応が遅れるという欠点を有する。これを克服するために、本発明の別の実施形態は、次のように発見的（ヒューリスティック）手法を導入する：平均負荷ｍ_１の代わりに、現在の負荷ｘ_ｃ、または、ｍ_１とｘ_ｃの両方の組合せが式（１５）に使用され、すなわち、

ｍ_１の代わりに現在の負荷ｘ_ｃを使用することは、トラフィック変化の力学（ｄｙｎａｍｉｃ）を輻輳通知信号に再び導入するが、依然としてクラスタ化を回避し、また輻輳時のトラフィック粒度の影響力を重視する。ｍ_１とｘ_ｃの組合せは、長期平均ｍ_１から、現在の負荷ｘ_ｃの任意の例外的な大きい偏差の影響を飽和させるのに有益である。

式（１４）−（１７）から導出されるヒューリスティック関数Ｐ_ｄ＝ｆ（Ｎ，ｍ_１，ｘ）は、ＬａｕｔｅｎｓｃｈｌａｇｅｒおよびＦｒｏｈｂｅｒｇの損失確率の計算に基づく（上記参照）。この関数ｆ（Ｎ，ｍ，ｘ）は、比較的平らな面を構成し、したがって、補間テーブルによって実行されることが可能である。関数ｆ（Ｎ，ｍ，ｘ）は、現在の負荷ｘ_ｃだけでなく、過去の平均負荷ｍ＝ｍ_１も考慮に入れて、例外的な不測の偏差の場合に著しくドロップすることを回避する。さらに、ヒューリスティックは、もともとのＲＥＤアルゴリズムに含まれるように、閾値メカニズムおよびスケーリング係数を含む。

ヒューリスティックは、推定損失がランダムドロップ確率Ｐ_ｄによって予想されるという仮定に基づく。バーストにクラスタ化されるオーバフロー損失以外は、ランダムドロップは、Ｆｌｏｙｄ、Ｓ．およびＪａｃｏｂｓｏｎ、Ｖ．、Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｅｔｅｃｔｉｏｎ Ｇａｔｅｗａｙｓ ｆｏｒ Ｃｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ、ＩＥＥＥ／ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｎｅｔｗｏｒｋｉｎｇ，Ｖ．１ Ｎ．４，１９９３年８月、３９７−４１３頁に説明されているように、滑らかに分散されることが可能である。したがって、これによりＴＣＰおよびアプリケーションに適したパケット損失プロファイルになる。

計算されたドロップ確率Ｐ_ｄは、輻輳制御のために提供される。提供されたドロップ確率Ｐ_ｄによって、輻輳通知が起動されることが可能である。本発明の別の実施形態によれば、この方法はさらに、計算されたドロップ確率Ｐ_ｄに従って受信されているパケットトラフィックのパケットをドロップするステップおよび／またはマーキングするステップを含む。ネットワークノードでパケットをドロップするステップは、ネットワークノードのトラフィック負荷を軽減する効果を有することができる。パケットをドロップするステップおよび／またはマーキングするステップの後に、輻輳通知が起動されることが可能である。ドロップ確率Ｐ_ｄは、パケットの宛先アドレスにより、ネットワークノードによって単にルーティングされないが、ネットワークノードによって特別な方法で処理されるパケットのパーセンテージを指定する。パケットの特別な処置は、パケットがネットワークノードによってドロップされること、例えばパケットが削除されることを意味することが可能である。本発明の諸実施形態は、ＲＥＤの改善として使用されることが可能であり、ドロップされるパケットは、暗黙的な輻輳通知の効果を有する。ネットワークノードによるパケットの特別の処置は、パケットが印を付けられる（例えば輻輳マーキングなど、フラグまたはビットを設定する）、カウントされる、特別な宛先アドレスにルーティングされるなどを意味することもまた可能である。パケットをドロップすることおよび／またはパケットにマーキングすることは、知られている輻輳回避処理を起動して、データパケットの伝送をいつ送信するか、または遅らせるかを決定する。アプリケーションストリームのエンドポイントは、輻輳通知によって通知されることが可能であり、これらのエンドポイントは、送信元によって送信されるパケットの量を減少させるよう要求される。

本発明の別の実施形態は、輻輳プライシングまたはアカウンティングに予想されるドロップ確率Ｐ_ｄを使用する。この場合、２つの異なるネットワークドメイン間の相互接続ゲートウェイにおいて、送信網は、送信網が受信網に送り込む輻輳の程度を明らかにされる。

本発明の別の実施形態によれば、輻輳通知は、パケットトラフィックのレートを下げるためのトリガとして使用される。計算されたドロップ確率Ｐ_ｄによって、トラフィックの送信元は、現在の送信レートを下げる要求とともに、輻輳状態について知らされる。理想的には、これは、すべての送信元が公平に共有されて、１００％のリソース利用、および無視できる低損失に近い平衡につながる。実際には、最も一般的な弾性的トラフィックの実装は、ＴＣＰプロトコルである。ＴＣＰは、失ったパケットを再送するために、接続エンドポイントへのパケットの到着を記録する。同時に、記録されたパケットの損失は、暗黙の輻輳通知として解釈される。それに応じて正確なＴＣＰの実行は、その送信レートを下げる。本発明の諸実施形態は、ＴＣＰの実行と協働する。

本発明のこれらの特徴ならびにさらなる特徴、および利点は、添付の図面と関連して次の例示的実施形態の詳細な説明を読むことによってより良く理解されるであろう。

本発明の基となる発見的手法を説明する図である。一般に、相対的トラフィック負荷ｘの関数として、またＮをパラメータとする関数ｆ（Ｎ，ｍ）によって導出される、ドロップ確率Ｐ_ｄを示す。 本発明の基となる発見的手法を説明する図である。長期平均ｍ_１または現在（短期）の値ｘ_ｃのどちらかによって、相対的トラフィック負荷ｘが図１ａの関数にどのように適用されるかを示す。 本発明の一実施例によるネットワークノードのブロック図である。

図１ａおよび１ｂは、ドロップ確率Ｐ_ｄがネットワークノードにおける相対的トラフィック負荷ｘの測定からどのように導出されることが可能であるかの一例である。図１ａは、ドロップ確率Ｐ_ｄを０≦ｘ≦１で容量利用率ｘの関数とする曲線の概形を示す。この概形は、同時発生アプリケーションストリームの５つの異なる推定最大数Ｎに対して、すなわち、Ｎ＝１，３，１０，３０および１００に対して、５つの数値的に決定されたＰ_ｄの曲線を示す。図１ａに示す関数Ｐｄ＝ｆ（Ｎ，ｍ）は、式（１４）によって選択されたＮの値に対して数値的に取得された。

図１ｂは、容量利用率ｘを時間ｔの関数とする曲線の概形を示す。第１に、概形は、現在の容量利用率ｘ_ｃの非常に変動する値を示す。現在の容量利用率ｘ_ｃは、ネットワークのノードの容量Ｂに対するネットワークノードのトラフィック負荷ｒの時間平均率であり、時間平均化は、例えばミリ秒など、第１の時間スケールに基づく。第２に、概形は、容量利用率ｘの時間平均値である一定の値ｍ_１を示し、平均化は、数分の時間スケールに基づく。

ドロップ確率Ｐ_ｄの計算にどの容量利用率ｘが使用されるかによって、ドロップ確率Ｐ_ｄの著しく異なる値が得られる。また、結果として生じるドロップ確率Ｐ_ｄは、同時発生アプリケーションストリームの推定最大数Ｎに著しく依拠する。

Ｎ＝１０のドロップ確率Ｐ_ｄは、例示的に図１ａにおいて、相対トラフィック負荷ｘの３つの異なる値について決定される：平均値ｘ＝ｍ１≒０．３５は（１点鎖線矢印に従う）ドロップ確率Ｐ_ｄ≒２．５・１０^−４を示し、相対トラフィック負荷の最小値ｘ_{ｃ，ｍｉｎ}≒０．１８は（破線矢印に従う）ドロップ確率Ｐ_ｄ≒２・１０^−６を示し、相対トラフィック負荷の最大値ｘ_{ｃ，ｍａｘ}≒０．６５は（点線矢印に従う）ドロップ確率Ｐ_ｄ≒１．５・１０^−２を示す。図１ａおよび１ｂは、計算されるドロップ確率Ｐ_ｄがパケットトラフィックの推定粒度Ｎおよび相対トラフィック負荷ｘにどれだけ依拠するかを示す。所与の相対負荷レベルｘ、ここではｍ_１またはｘ_ｃにおけるドロップ確率Ｐ_ｄは、負荷ｘそのものにだけでなく、トラフィックの粒度Ｎ、すなわち同時発生ストリームの最大許容数にも依拠することが明らかになる。

図２は、本発明の一実施形態によるネットワークノードを示すブロック図である。図２は、例えばインターネットなどのパケット交換網１００において受信リンク６と多数の送出リンク２３０とを有する、例えばルータまたはスイッチなどのネットワークノード２を示す。パケット交換網は、コネクションレスパケット伝送網とも呼ばれる。受信リンク６では、多数の送信元から集約されたパケットトラフィックがルータ２に、すなわち入力インタフェース２１を介してデータリンク上に届く。ルータ２は、制御ユニット４、ルーティングユニット２３、およびルーティングテーブル２５を備える。受信パケットは、入力インタフェース２１から接続２１０を介してルーティングユニット２３へ送信される。まず、パケットは、ルーティングユニット２３のバッファ２３１に入れられる。パケットの変わり目である場合、またパケットがドロップされるよう選択されない場合（以下参照）、ルーティングユニット２３は、受信パケットからルーティングに関する情報、例えばパケットのパケットヘッダから宛先アドレスなどを抜き出し、ルーティングテーブル２５で対応するルーティングデータを調べ、多数の出力リンク２３０の１つまたは多数においてルーティングデータに従ってパケットを転送する。

制御ユニット４は、第１のモジュール４２と、２乗デバイス（ｓｑｕａｒｉｎｇ ｄｅｖｉｃｅ）４４と、第１の平均化デバイス４６ａおよび第２の平均化デバイス４６ｂと、粒度計算機４８と、確率計算機４９とを含む。制御ユニット４は、１つまたは多数の相互にリンクされたコンピュータ、すなわち、ハードウェアプラットフォーム、ハードウェアプラットフォームに基づいたソフトウェアプラットフォーム、および、ソフトウェアおよびハードウェアプラットフォームによって形成されるシステムプラットフォームによって実行されるいくつかのアプリケーションプログラムからなる。制御ユニット４の機能は、こうしたアプリケーションプログラムを実行することによって提供される。アプリケーションプログラムまたはこれらのアプリケーションプログラムの選択された部分は、システムプラットフォームで実行されるとき、次に説明する確率計算サービスを提供するコンピュータソフトウェア製品を構成する。さらに、このようなコンピュータソフトウェア製品は、これらのアプリケーションプログラムまたは上記アプリケーションプログラムの選択された部分を格納する記憶媒体によって構成される。

制御ユニット４は、ドロップ確率Ｐ_ｄをルーティングユニット２３に提供する。ドロップ確率Ｐ_ｄに応じて、ルーティングユニット２３は、対応するパーセンテージの受信パケットを、ドロップする２２０、またはマーキングする、または他の何らかの方法で輻輳状態に関してこれに通知する、すなわちそれらのパケットを削除する２２０。一例として、ドロップ確率が０．０５である場合、ルーティングユニット２３は、統計的手法で５パーセントの受信パケットをドロップする。ルーティングユニット２３は、それ自体でどのパケットをドロップするかを決定することができる。好ましくは、ドロップされるパケットの選択は、乱数発生器によって実行される。

ルータ２の第１の分配ノード２４では、受信パケットトラフィックの信号が、２つの接続に分配される。パケットトラフィックは、ルーティングユニット２３に転送される。また、パケットトラフィックは、第１のモジュール４２に送信される４１。第１のモジュール４２への別の入力は、ルータ２の現在の容量Ｂであり、例えばルーティングユニット２３の処理容量である。第１のモジュール４２は、到着パケットトラフィックの量（例えばビット／秒で測定する）を利用可能容量Ｂ（例えばビット／秒で測定する）と関連して設定し、この比を平均する平均化デバイスである。平均化は、ルータ２のバッファ２３１の保持時間に匹敵する時間スケールで行われる。例えばこれは、１から１００ｍｓの範囲とすることができる。到着パケットトラフィックの量および利用可能容量Ｂの時間平均率は、容量利用率ｘと呼ばれ、これは、ミリ秒の分解能で０から１の範囲の値である。

第２の分配ノード４３では、容量利用率ｘは、３つの接続に分配される。容量利用率ｘは、接続４３ａを介して第１の平均化デバイス４６ａに送信される。また、容量利用率ｘは、接続４３ｂを介して２乗デバイス４４に送信される。また、容量利用率ｘは、接続４３ｃを介して確率計算機４９に送信される。

第１の平均化デバイス４６ａは、時間について容量利用率ｘを平均化する。平均化は、秒から分以上の範囲の時間スケールで行われる。例えば、この時間スケールは１秒、１０秒、１０分のうちの３分とすることができる。容量利用率ｘの時間平均値は、ｍ_１と呼ばれる。数量ｍ_１は、接続４７ａで粒度計算機４８へ、接続４７ｂで確率計算機４９へ転送される。

２乗デバイス４４は、容量利用率ｘを２乗し、２乗された容量利用率ｘ^２を第２の平均化デバイス４６ｂへ転送する。

第２の平均化デバイス４６ｂは、２乗された容量利用率ｘ^２を時間について平均化する。平均化は、第１の平均化デバイス４６ａの平均化と同一の時間スケールで行われる。好ましくは、第１の平均化デバイス４６ａおよび第２の平均化デバイス４６ｂは、同一の時間平均化装置であり、単に異なる入力が平均化される。２乗された容量利用率ｘ^２の時間平均化された値は、ｍ_２と呼ばれる。数量ｍ_２は、接続５０で粒度計算機４８へ転送される。

粒度計算機４８は、ルータ２の容量Ｂを下回る同時発生アプリケーションストリームの推定最大数として数量Ｎ＝ｍ_１／（ｍ_２−（ｍ_１）^２）を、受信された数量ｍ_１およびｍ_２から計算する。粒度計算機４８は、計算された数量Ｎを接続５２で確率計算機４９へ転送する。

確率計算機４９は、受信された数量ｍ_１（単にｍとも呼ばれる）、受信された数量Ｎ、および受信された容量利用率ｘから、確率Ｐ＝ｆ（Ｎ，ｍ，ｘ）を計算する。確率計算機４９は、計算された確率Ｐをルーティングユニット２３に送信し、ルーティングユニット２３は、詳細にはどのパケット部分にマーキングするまたはこれをドロップするべきかという輻輳通知に確率Ｐを使用する。

ルーティングユニット２３はパケットをドロップし、これがＴＣＰ接続の受信者への暗黙的輻輳通知となるか、例えばパケットにマーキングすることによって、または明示的メッセージによって、通信エンドポイントの１つに明示的輻輳通知を送信する。このように、制御ユニット４からルーティングユニット２３に提供される計算されたドロップ確率Ｐ_ｄは、輻輳通知を制御する、すなわち、輻輳通知は、計算されたドロップ確率Ｐ_ｄによって決まる。計算されたドロップ確率Ｐ_ｄがゼロである場合、輻輳通知は起動されない。計算されたドロップ確率Ｐ_ｄが１である場合、輻輳通知は確実に起動される。計算されたドロップ確率Ｐ_ｄがゼロと１の間である場合、輻輳通知は計算されたドロップ確率Ｐ_ｄの値次第で起動される。

Claims (11)

1. パケット交換網（１００）において多数のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノード（２）のトラフィック負荷を管理する方法であって、
   ａ）ネットワークノード（２）の伝送容量Ｂに適合するアプリケーションストリームの最大数としてパケットトラフィックの粒度を推定するステップと、
   ｂ）推定された粒度およびネットワークノード（２）のトラフィック負荷に基づいてドロップ確率Ｐ_ｄを計算するステップと、
   ｃ）計算されたドロップ確率Ｐ_ｄを輻輳制御のために提供するステップと
   を含む方法において、
   ステップａ）が、
   伝送容量Ｂに対するネットワークノード（２）のトラフィック負荷の時間平均率として容量利用率ｘを決定するステップであって、０≦ｘ≦１および時間平均化は第１の時間スケールであるステップと、
   容量利用率ｘの時間平均値ｍ_１および容量利用率ｘの２乗ｘ^２の時間平均値ｍ_２を決定するステップであって、時間平均化は、第１の時間スケールよりも長い第２の時間スケールであるステップと、
   ネットワークノード（２）の伝送容量Ｂに適合する、アプリケーションストリームの前記推定された最大数として、Ｎ＝ｍ_１／（ｍ_２−（ｍ_１）^２）を計算するステップと
   を含むことを特徴とする、方法。
2. 第１の時間スケールが、ネットワークノード（２）のバッファ保持時間に匹敵する
   ことを特徴とする、請求項１に記載の方法。
3. 第１の時間スケールが、５００μｓから１００ｍｓの範囲、好ましくは１から１０ｍｓの範囲にある
   ことを特徴とする、請求項１に記載の方法。
4. 第２の時間スケールが、１ｓよりも大きい
   ことを特徴とする、請求項１に記載の方法。
5. 第２の時間スケールが、第１の時間スケールよりも少なくとも１００倍大きい
   ことを特徴とする、請求項１に記載の方法。
6. ステップｂ）が、
   Ａアプリケーションストリームの平均を有するパケットトラフィックがｋアプリケーションストリームからなる確率Ｐ（ｋ）が、Ｐ（ｋ）＝Ａ^ｋｅ^−Ａ／ｋ！としてポアソン分布に従うと仮定するステップと、
   Ｎがネットワークノード（２）の伝送容量Ｂに適合するアプリケーションストリームの最大数である場合、ｋ＞Ｎについて確率Ｐ（ｋ）の合計として、オーバフロー確率Ｐ_ｏｖを計算するステップと、
   ドロップ確率Ｐ_ｄをオーバフロー確率Ｐ_ｏｖよりも小さいと仮定するステップと
   を含む
   ことを特徴とする、請求項１に記載の方法。
7. 計算されたドロップ確率Ｐ_ｄに従って受信されているパケットトラフィックのパケットをドロップするおよび／またはこのパケットにマーキングするステップ
   をさらに含む
   ことを特徴とする、請求項１に記載の方法。
8. 計算されたドロップ確率Ｐ_ｄに従って輻輳通知を起動するステップ
   をさらに含む
   ことを特徴とする、請求項１に記載の方法。
9. 輻輳通知によってトリガされ、パケットトラフィックのレートを下げるステップ
   をさらに含む
   ことを特徴とする、請求項８に記載の方法。
10. パケット交換網（１００）において多数のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノード（２）であって、ネットワークノード（２）の伝送容量Ｂに適合するアプリケーションストリームの最大数としてパケットトラフィックの粒度を推定し、推定された粒度およびネットワークノード（２）のトラフィック負荷に基づいてドロップ確率Ｐ_ｄを計算し、計算されたドロップ確率Ｐ_ｄを輻輳制御のために提供するように構成された制御ユニット（４）を含むネットワークノード（２）において、
    制御ユニット（４）が、パケットトラフィックの粒度の上記推定のために、さらに、
    伝送容量Ｂに対するネットワークノード（２）のトラフィック負荷の時間平均率として容量利用率ｘを決定し、０≦ｘ≦１であって、時間平均化は第１の時間スケールに基づく、
    容量利用率ｘの時間平均値ｍ_１および容量利用率ｘの２乗ｘ^２の時間平均値ｍ_２を決定し、時間平均化は第１の時間スケールよりも長い第２の時間スケールに基づく、
    ネットワークノード（２）の伝送容量Ｂに適合する、アプリケーションストリームの前記推定された最大数として、Ｎ＝ｍ_１／（ｍ_２−（ｍ_１）^２）を計算する
    ように構成されることを特徴とする、ネットワークノード（２）。
11. パケット交換網（１００）において多数のアプリケーションストリームから集約されたパケットトラフィックを受信するネットワークノード（２）のトラフィック負荷を管理するためのコンピュータプログラム製品であって、ネットワークノード（２）によって実行されるとき、
    ａ）ネットワークノード（２）の伝送容量Ｂに適合するアプリケーションストリームの最大数としてパケットトラフィックの粒度を推定するステップと、
    ｂ）推定された粒度およびネットワークノード（２）のトラフィック負荷に基づいてドロップ確率Ｐ_ｄを計算する計算するステップと、
    ｃ）計算されたドロップ確率Ｐ_ｄを輻輳制御のために提供するステップと
    を実行するコンピュータプログラム製品において、
    ステップａ）が、
    伝送容量Ｂに対するネットワークノード（２）のトラフィック負荷の時間平均率として容量利用率ｘを決定し、０≦ｘ≦１および時間平均化が第１の時間スケールに基づくステップと、
    容量利用率ｘの時間平均値ｍ_１および容量利用率ｘの２乗ｘ^２の時間平均値ｍ_２を決定し、時間平均化が、第１の時間スケールよりも長い第２の時間スケールに基づくステップと、
    ネットワークノード（２）の伝送容量Ｂに適合する、アプリケーションストリームの前記推定された最大数として、Ｎ＝ｍ_１／（ｍ_２−（ｍ_１）^２）を計算するステップと
    を含むことを特徴とする、コンピュータプログラム製品。

Images