JP4275673B2 - 通信網における帯域制御方法およびその装置 - Google Patents

Description

本発明は、ＩＰネットワークにおいて、長時間に渡って帯域を占有するトラヒックを発生するフローの使用帯域を制御する方法に関するものである。

ＩＰネットワークが広く利用されてくるに伴って、ＩＰネットワーク上での通信品質保証に対する要求が高まっている。その一方で、Ｐ２Ｐアプリケーションの出現に伴うトラヒックパターンの急激な変動に代表されるように、各フローのトラヒック特性はますます多種多様となり、それに伴い各種フローの品質要求も多様化している。例えば、Ｐ２Ｐトラヒックのような長時間に渡って帯域を占有するフローを適切にコントロールして、レスポンス時間に敏感なｗｅｂのようなファイルサイズの小さいフローの品質を確保することが要求される場合が想定される。その一方で、通信設備に対するコストを抑える必要がある。従って、与えられた通信帯域を有効利用して各フローの所望の通信品質を維持できるように各フローの使用帯域を適切に制御することが重要となっている。

従来のレート制御技術は、その瞬間（空間方向）の各フローの使用帯域が公平になるように制御するものが一般的である（例えば非特許文献１のＷＦＱ（weighted fair queueing）や非特許文献２のＣＳＦＱ（core-stateless-fair-queueing）や非特許文献８の制御方法等）。しかしながら、このような方法では、空間方向のみしか考慮しないため、Ｐ２Ｐトラヒックのように長時間に渡って存在するフローにも常に一定の帯域を与えることになり、その結果、ｗｅｂのような小さいファイルを転送するだけのフローはその瞬間の公平な帯域分の割当は与えられるのみであり、その結果、該フローは圧迫されてしまう（図１（Ａ））。しかし、図１（Ｂ）に示すように、時間方向も考慮に入れて各フローの帯域を制御すると、Ｐ２Ｐのような長時間フローのファイル転送完了時間も劣化させずに、ｗｅｂのようなサイズの小さいフローのレスポンス時間（ファイル転送時間）を向上させることが可能となる。

時間方向も考慮した帯域制御方式として非特許文献３、４がある。しかしながら、これらは各ノードでフロー毎にキューイングし、フロー毎にパケット転送処理のスケジューリングを行うため、フロー数の多いノードではスケーラビリティに問題があった。そこで、本発明者らは、フロー数に対するスケーラビリティを確保するため、ｄｉｆｆｓｅｒｖアーキテクチャ（非特許文献５参照）を利用して時間方向も考慮した帯域制御方法を特許文献１において考案した。ｄｉｆｆｅｒｖでは、通信網の入口にある境界ノードと、網の内部にある内部ノードで機能分担を行う。本発明では、多重フロー数の少ない境界ノードではユーザフロー毎にトラヒックを監視（ポリシング）し、その監視結果に応じてパケットヘッダにタギングをし（タグを付し）、多重フロー数の多い内部ノードは、フロー毎に状態管理せずにタギングの有無のみをチェックし、そのときの輻輳状況に応じてパケットの選択廃棄・優先制御を実施する。しかしながら、この方法においても、網の境界ノードではフロー毎にトラヒックを監視する必要があるため、今後回線速度の高速化に伴いフロー数も増大していく状況を考えると、そういった場合にはやはり対処できない、という問題点があった。一方、特許文献１では、そのような問題を回避する一手段として、パケットのポート番号をみて、もしもポート番号が６６９９や７７４３を持つフローは、Ｐ２Ｐ型のファイル共有アプリケーションに関するフローであるので、大きなファイルを転送して長時間帯域を占有する可能性が高いと判断できるので、そのようなフローのみを制御対象とする方法について述べていた。しかし、近年のＰ２Ｐアプリケーションはポート番号では識別できないトラヒックが大半を占めるため、この手法では対応できなくなってきている。またＰ２Ｐ以外にもＤＤｏＳのように高レートでトラヒックを出しつづける異常トラヒックも増加しているため、アプリケーションに依存しない方法が必要となってきている。

特開２００５−２１７８２３号公報（通信網におけるレート制御方法およびレート制御システム） A.K.Parekh and R.G.Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Single-Node Case," IEEE/ACM Transactions on Networking vol.1, no.3 (June 1993) pp.344-357. I.Stoica, S.Shenker, and H.Zhang, "Core-Stateless Fair Queueing: Achieving Approximately Fair Bandwidth Allocations in High Speed Networks," proceedings of ACM SIGCOMM98, pp.118-130, 1998. T.S.Eugene Ng, D.C.Stephens, I.Stoica, and H.Zhang, "Supporting Best-Effort Traffic with Fair Service Curve," IEEE Globecom99, pp.1799-1807, 1999. 山垣、戸出、村上、"フロー継続状況を考慮に入れたフロー管理型パケット廃棄制御方式"、電子情報通信学会論文誌 Ｖｏｌ．Ｊ８６−Ｂ、Ｎｏ．８、ｐｐ．１５７８−１５８８、２００３． An Architecture for Differentiated Services, IETF RFC2475. T.Mori, M.Uchida, R.Kawahara, J.Pan, and S.Goto, "Identifying Elephant Flows Through Periodically Sampled Packets," ACM SIGCOMM Internet Measurement Conference, 2004. C.Estan and G.Varghese, "New Directions in Traffic Measurement and Accounting," Proceedings of ACM SIGCOMM, August2002. Ratul Mahajan, Sally Floyd, and David Wetherall, "Controlling High-Bandwidth Flows at the Congested Router," 9th International Conference on Network Protocols (ICNP), November 2001. D.Clark and W.Fang, "Explicit Allocation of Best-Effort Packet Delivery Service," IEEE/ACM Trans. on Networking, vol.6, no.4, pp.362-373, August 1998.

本発明の目的は、上述の問題点に鑑み、各ノードでフロー毎に状態管理することなく、長時間帯域占有フローを適切に制御することにより、各フローの通信品質を維持できるような帯域制御方法、および帯域制御装置を提供することにある。

管理フロー数を削減するため、本発明ではパケットサンプリング技術を用いる。これは、図２に例示すように、複数のフローからのパケットが到着する場合を考える。なお、フローの定義は、例として、ここでは、同一の（送信元ＩＰアドレス、着信先ＩＰアドレス、送信元ポート番号、着信先ポート番号、プロトコル番号）を持つパケット群をフローと定義する。図２において、長方形がパケットを表しており、各パケットはフロー別に別のパターンで図示している。したがって、同じパターンのパケットが同じフローに属している。ここで、Ｎ個（Ｎは２以上の整数、図２ではＮ＝３）に１個のパケットをサンプルし、サンプルされたパケットの属するフローのみを管理対象とすると、図２の例では管理フロー数を２本に削減できている。すなわち、図２の上部に示すようにサンプルせずに全フローのパケットを管理対象にすると管理フローが多くなるが（図２の場合５本のフロー）、図２の下部に示すようにサンプルされたフローのパケットのみを管理対象にすれば管理フローを削減できる（図２の場合は２本のフロー）。このようにサンプリングにより管理フロー数を削減できる。また、図２をみると分かるように、パケット数の多いフローの方がサンプルされやすい。したがって、今、制御対象としたいのは、長時間に渡って帯域を占有するフロー、つまりパケット数の多いフローなので、パケットがサンプルされたフローのみを対象とすれば十分であるということになる。

なお、パケットサンプリングを用いた関連技術として、例えば非特許文献６、７があるが、これらは高レートフローをどのように検出するかのみを検討しており、ネットワーク管理者への通知を目的としている。それに対し本発明では、検出後にどのように制御するかも含めて考案している。
本明細書において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の第１の方法においては、通信網の入口にある境界ノードにおいてユーザフロー毎にトラヒックを監視し、その監視結果に応じてパケットヘッダにタギングをし、通信網の内部に位置する各内部ノードは、タギングの有無とそのときの輻輳状況に応じてパケットの選択廃棄・優先制御を実施して、各フローの使用帯域を制御するトラヒック制御方法において、境界ノードでは、フロー情報を管理するテーブルを用意しておき、パケット到着毎に該パケットがどのフローからのパケットから調査し、該フローが既に前記テーブルにエントリされていれば、該パケットをトラヒックポリシング対象とする。そうでなければ、Ｎ個に１個のパケットサンプリングを実施し、パケットがサンプルされたら、そのパケットの属するフローを前記テーブルに新規エントリする。このようにしてサンプルされたフローのみをトラヒックポリシングし、長時間に渡って帯域を占有していると判断されたら該フローからのパケットにタギングをし、内部ノードでは網が輻輳した場合にはタギングされたパケットを優先的に廃棄することを特徴とする。

本発明の第２の方法においては、第１の方法における境界ノードにおいて、前記テーブルでは、パケットがサンプルされたフローｊの許可レートＡＲｊ［ｂｐｓ］、到着パケット数Ｘｊ、超過バイト数ＮＢｊ、最後に到着したパケットの時刻Ｔｌａｓｔ＿ｊを保持し、Ｘｊ ｍｏｄ Ｍ＝０となる毎に、ＡＲｊ←ｍａｘ｛α１×ＡＲｊ，α２×ＡＲ０｝と更新する。なお、Ｍは予め定める正の整数、α１、α２は予め定めるパラメータであり０＜α２≦α１＜１の値をとる。ＡＲ０はＡＲｊの初期値を意味する。また、パケット到着毎にＮＢｊ←ｍａｘ｛ＮＢｊ一ＡＲｊ（Ｔｎｏｗ−Ｔｌａｓｔ＿ｊ）、０｝＋Ｓｐｋｔとする（ここで、Ｔｎｏｗ現時刻、Ｓｐｋｔはパケットサイズ）。ＮＢｊがしきい値を超えたら、該パケットをタギングすることを特徴とする。

ここでＮＢｊは、もし仮にＡＲｊでパケット送出レートをシェーピングしていたとしたときの該シェーパでのキューに滞留するバイト数、を意味する。つまり、フローｊがパケットを許可レートＡＲｊ以下で送出していれば、ＮＢｊは常に高々１パケット分のバイト数（Ｓｐｋｔ）となり、許可レートＡＲｊよりも大きいレートでパケットを送出し続けると、ＮＢｊは発散する。したがってＮＢｊをしきい値と比較してパケットをタギングするか否かを判定することにより、帯域を占有しているフローに適切にタギングをすることが可能となる。また、第２の方法に記載のように許可レートＡＲｊを段階的に減少させていくことによって、長時間に渡って帯域を占有しているフローに対して、よりタギングを行うことが可能となる。

本発明の第３の方法においては、第１の方法において網の境界ノードでタギングし、網の内部ノードでタギングされたパケットを廃棄していた代わりに、単一のノードにおいて、ノードの入口でタギングし、同ノードからの出力リンクが輻輳したら該出力待ちキューにおいてタギングされたパケットを廃棄することを特徴とする。

第１の方法では、ｄｉｆｆｅｒｖアーキテクチャ（非特許文献５参照）を利用して、通信網の入口にある境界ノードと、網の内部にある内部ノードで機能分担を行っていたが、この第３の方法では、単一ノード内においてタギング機能とパケット廃棄機能を配備する形態を取っている。これは、パケットサンプリングにより管理フロー数を減らせているので、単一ノード内にこのように両者の機能を配備してもスケーラブルに動作可能であるからである。

本発明の帯域制御装置においては、第１に記載の方法で、パケットがサンプルされたフローのみをトラヒックポリシング対象とする手段、第２に記載の方法で、該フローの許可レートを動的に変更させて許可レート超過分のパケットにタギングする手段、第１または３に記載のいずれかの方法で網の内部ノードまたはトラヒックポリシングを行っているノードと同じノード内においてタギングされたパケットを廃棄する手段を具備することを特徴とする。

本発明によれば、各ノードでフロー毎に状態管理することなく、帯域占有トラヒックを発生するフローを適切に制御し、ｗｅｂのような小さいサイズのフローのレスポンス時間を向上させて、与えられた帯域を有効利用することを可能とする、帯域制御方法およびその装置を提供することが可能となる。

以下、図面を用いて本発明の実施例を説明する。

図３は本発明が適用されるＩＰネットワークの基本構成の一例を示す構成図である。図３において、３１はＩＰネットワークであり、３２はエンドユーザの端末であり、３３はＩＰネットワーク３１の境界に配置された境界ノードであり、３４はＩＰネットワーク３１の内部に配置された内部ノードである。図３に示す境界ノード３３および内部ノード３４に必要な機能を配備することによって、本発明の実施例の帯域制御装置は構築される。なお、図３においては、境界ノード３３は、ＩＰネットワーク３１とエンドユーザの端末３２の境界に位置しているが、ＩＰネットワーク３１と他のネットワークとの境界に位置するノードであってもよい。また、３１はＩＰネットワーク以外の通信網でもよい。

本実施例は、ＩＰネットワーク３１の入口にある境界ノード３３においてユーザフロー毎にトラヒックを監視し、その監視結果に応じてパケットヘッダにタギングをし（タグを付し）、ＩＰネットワーク３１の内部に位置する内部ノード３４は、タギングの有無とそのときの輻輳状況に応じてパケットの選択廃棄を実施して、各フローの使用帯域を制御するトラヒック制御を行うものである。

図４は本実施例の帯域制御装置における境界ノード３３の構成例を表すブロック図であり、図５は本実施例の帯域制御装置における内部ノード３４の構成例を表すブロック図である。図６は境界ノード３３のパケットヘッダ解析部での処理手順の例を示す図である。

境界ノード３３は、図４に示すように、パケットヘッダを解析するパケットヘッダ解析部４１と、フローを管理するフロー管理部４２と、タギングを行う違反タギング部４３と、パケットを転送するパケット転送部４４と、を備える。フロー管理部４２はフロー管理テーブル４５を備える。

図４に示されている通り、エンドユーザから到着したパケットはパケットヘッダ解析部４１において（送信元ＩＰアドレス、着信先ＩＰアドレス、送信元ポート番号、着信先ポート番号、プロトコル番号）を読み取った後、図６に記載の処理手順に従う。まず、該パケットの属するフローが既にフロー管理部４２内にあるフロー管理テーブル４５にエントリされているかどうか調べる（ステップ６１）。なお、フロー管理テーブル４５では、同一の（送信元ＩＰアドレス、着信先ＩＰアドレス、送信元ポート番号、着信先ポート番号、プロトコル番号）を持つパケット群をフローと定義し、各フローの状態を管理している。もし該フローが既にエントリされていれば（ステップ６１でｙｅｓ）、該パケットを違反タギング部４３へ転送する（ステップ６２）。そうでなければ（ステップ６１でｎｏ）、Ｎ個に１個のパケットサンプリングを実施する。Ｎ番目のパケット、２Ｎ番目のパケット、・・・というように周期的にパケットをサンプルしてもよいし、パケット到着毎に０から１の一様乱数を発生させてその結果が１／Ｎ以下であれば、該パケットをサンプルする、としてもよい。もしもパケットがサンプルされたら（ステップ６３でｙｅｓ）、そのパケットの属するフローをフロー管理テーブル４５に新規エントリするよう、フロー管理部４２へ通知し（ステップ６４）、その後、該パケットをパケット転送部４４へ転送する。もしサンプルされなかったら（ステップ６３でｎｏ）、そのパケットを単にパケット転送部４４へ転送する（ステップ６５）。

フロー管理部４２は、フロー毎に状態を管理するフロー管理テーブル４５を予め用意しておく。そのフロー管理テーブル４５では、フローｊの許可レートＡＲｊ［ｂｐｓ］、到着パケット数Ｘｊ、超過バイト数ＮＢｊ、最後に到着したパケットの時刻Ｔｌａｓｔ＿ｊを保持している。パケットヘッダ解析部４１から、新規フローエントリの通知があったら、該フローに対するエントリを行う。このとき、ＡＲｊ←ＡＲ０、Ｔｌａｓｔ＿ｊ←Ｔｎｏｗ、ＮＢｊ←０、Ｘｊ←０と設定する。なお、ＡＲ０は許可レートＡＲｊの初期値を意味するレートであり、予め定めるパラメータである。またＴｎｏｗは現在の時刻を表す。「←」は代入することを意味する。

一方、違反タギング部４３は、既にエントリ済みのフローからのパケットがパケットヘッダ解析部４１から転送されてきたら、フロー管理部４２から到着パケット数Ｘｊを読み出し、Ｘｊ←Ｘｊ＋１とし、その後にＸｊ ｍｏｄ Ｍ＝０となるかどうかをチェックする。ここで、Ｍは予め定める正の整数である。なお、「Ｘｊ ｍｏｄ Ｍ＝０」はＸｊをＭで割ったときの余りが０であること、すなわち割り切れたことを意味する。もし、これが成り立てば、フロー管理部４２から許可レートＡＲｊ、超過バイト数ＮＢｊ、最後に到着したパケットの時刻Ｔｌａｓｔ＿ｊを読み出し、ＡＲｊ←ｍａｘ｛α１×ＡＲｊ，α２×ＡＲ０｝と更新する。なお、α１、α２は予め定めるパラメータであり、０＜α２≦α１＜１の値をとる。その後、Ｘｊ ｍｏｄ Ｍ＝０かどうかにかかわらず、ＮＢｊ←ｍａｘ｛ＮＢｊ−ＡＲｊ（Ｔｎｏｗ−Ｔｌａｓｔ＿ｊ），０｝＋Ｓｐｋｔとする（ここで、Ｔｎｏｗは現時刻、Ｓｐｋｔはパケットサイズ）。また、Ｔｌａｓｔ＿ｊ←Ｔｎｏｗと更新する。このとき、超過バイト数ＮＢｊが予め定めるしきい値を超えたら、該パケットをタギングしてからパケット転送部４４へ転送し、超過バイト数ＮＢｊをＮＢｊ←ＮＢｊ−Ｓｐｋｔとする。そうでなければ、タギングはしないで、超過バイト数ＮＢｊの値も更新後のままとし、該パケットをパケット転送部４４へ転送する。以上の手順が終了後、違反タギング部４３において更新された到着パケット数Ｘｊ、許可レートＡＲｊ、超過バイト数ＮＢｊ、最後に到着したパケットの時刻Ｔｌａｓｔ＿ｊの値をフロー管理部４２へ通知する。

以上のようにして、境界ノード３３は、フロー情報を管理するフロー管理テーブル４５を備え、パケット到着毎に該パケットがどのフローからのパケットかを調査し、該フローが既にフロー管理テーブル４５にエントリされていれば、該パケットをトラヒックポリシング対象とし、そうでなければ、パケットサンプリングを実施し、パケットがサンプルされたら、そのパケットの属するフローをフロー管理テーブル４５に新規エントリし、長時間に渡って帯域を占有していると判断されたらフロー管理テーブル４５にエントリされているフローからのパケットにタギングを行う。

一方、内部ノード３４は、図５に示すように、パケットヘッダを解析するパケットヘッダ解析部５１と、パケットの廃棄を決定するパケット廃棄決定部５２と、キュー長を監視するキュー長監視部５３と、パケットを転送するパケット転送部５４と、を備える。

図５の内部ノード３４では、出力リンク毎に以下に示す機能を有する。境界ノード３３から到着したパケットは、パケットヘッダ解析部５１において該パケットヘッダを読み出し、タギングされているかどうかを調べる。また該パケットはパケット廃棄決定部５２へ転送する。もしタギングされていたら、キュー長監視部５３へタギングされていたことを通知し、キュー長監視部５３はリンクへの出力待ちバッファにおいてバッファ内キュー長Ｑを読み出し、その値をパケット廃棄決定部５２へ通知する。

パケット廃棄決定部５２は、バッファ内キュー長Ｑの値を廃棄確率決定関数ｆ（Ｑ）に代入して、廃棄確率ｐを計算する。ここで、廃棄確率決定関数ｐ＝ｆ（Ｑ）は、

で与えられる。ここで、Ｑ＿ｔｈ＿ｍｉｎ、Ｑ＿ｔｈ＿ｍａｘ、γは予め定めるしきい値、あるいはパラメータである。Ｑ＿ｔｈ＿ｍｉｎ＜Ｑ＿ｔｈ＿ｍａｘである。なお、この方法は、例として、非特許文献９で示されているパケット廃棄方法を用いているが、他の方法でもよい。計算された確率ｐに基づいて、パケットを廃棄するか否かを決定し、到着したパケットを廃棄しないと決定されれば、該パケットをパケット転送部５４に転送する。パケット転送部５４ではリンク出力待ちバッファを持ち、受信したパケットをバッファに格納する。到着したパケットを廃棄すると決定されれば、該パケットを廃棄する。

一方、パケットがタギングされていない場合は、別の廃棄確率決定関数ｐ＿ｎｏｎ＝ｇ（Ｑ）を用いる。関数ｇ（Ｑ）は、

で与えられる。ここで

と設定しておくことにより、タギングされたパケットを優先的に廃棄することが可能となる。計算された確率ｐ＿ｎｏｎに基づいて、パケットを廃棄するか否かを決定し、到着したパケットを廃棄しないと決定されれば、該パケットをパケット転送部５４に転送する。パケット転送部ではリンク出力待ちバッファを持ち、受信したパケットをバッファに格納する。到着したパケットを廃棄すると決定されれば、該パケットを廃棄する。

パケット転送部５４は、バッファにパケットが格納したら、パケットを受け付けた旨をキュー長監視部５３に通知する。キュー長監視部５３は、パケット受け付けの通知を受け取ったら、バッファ内キュー長Ｑを、Ｑ←Ｑ＋１により更新する。パケット転送部５４は、出力リンク帯域に従ってパケットを送出する。パケットを送出したら、キュー長監視部５３にその旨を通知し、それを受け取ったキュー長監視部５３は、Ｑ←Ｑ−１により更新する。
以上のようにして、内部ノード３４は、通信網が輻輳した場合にはタギングされたパケットを優先的に廃棄する。

実施例２においては、実施例１において通信網の境界ノード３３でタギングし、通信網の内部ノード３４でタギングされたパケットを廃棄していた代わりに、単一ノード内において、ノードの入口でタギングし、同ノード内のリンクへの出力待ちキュー長に応じてタギングされたパケットを廃棄する。実施例２のノードは、例えば、図４の装置の後段に図５の装置を設けることによって構成することができる。

以上説明したように、実施例１、２によれば、各ノードでフロー毎に状態管理することなく、帯域占有トラヒックを発生するフローを適切に制御し、ｗｅｂのような小さいサイズのフローのレスポンス時間を向上させて、与えられた帯域を有効利用することを可能とする、帯域制御方法およびその装置を提供することが可能となる。

本効果をシミュレーションにより確認した結果を以下で示す。１０Ｍｂｐｓのボトルネックリンクに、帯域占有トラヒックを発生するフローとして、平均１０ＭＢのファイルを発生するＰ２Ｐフローを多重し、通常のｗｅｂフローとして平均１００ＫＢのファイルを発生するフローも多重するシミュレーションを行った。フローの発生比率は、Ｐ２Ｐフロー：ｗｅｂフロー＝１：９とした。各フローの発生間隔を調整してリンクへの負荷を変化させ、各リンク負荷におけるｗｅｂフロー転送時間の平均を評価した（図７（Ａ））。このとき、比較として、制御しない場合の結果も併せて示す。図７（Ａ）において縦軸はｗｅｂフローの転送時間［ｓ］であり、横軸はリンク負荷である。○で示す制御なしの場合と比較して、◆で示す制御ありの場合はｗｅｂフローの転送時間が大幅に低下しており、本制御によりｗｅｂフローの転送時間を改善できることが分かる。また、Ｐ２Ｐフローの転送時間も図７（Ｂ）に示す。図７（Ｂ）において縦軸はＰ２Ｐフローの転送時間［ｓ］であり、横軸はリンク負荷である。○で示す制御なしの場合と◆で示す制御ありの場合とでＰ２Ｐフローの転送時間はほぼ同じであり、Ｐ２Ｐフローの転送時間の劣化はあまり生じていないことが分かる。

以上説明した実施例１、２の各ノードの各部はコンピュータと記プログラムで構成できる。また、そのプログラムの一部または全部に代えてハードウェアで構成してもよい。また、フロー管理テーブルは記憶装置に記憶させることができる。

以上、本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

本発明における制御の動作例を説明する図である。 本発明で用いるパケットサンプリングの動作を説明する図である。 本発明が適用されるＩＰネットワークの基本構成の一例を示す構成図である。 本発明における帯域制御装置を構成する境界ノードの構成例を示すブロック図である。 本発明における帯域制御装置を構成する内部ノードの構成例を示すブロック図である。 本発明における境界ノードでのパケットヘッダ解析部での処理手順の例を示す図である。 本発明の効果を示すためのシミュレーション評価結果である。

符号の説明

３１…ＩＰネットワーク、３２…エンドユーザの端末、３３…境界ノード、３４…内部ノード、４１…パケットヘッダ解析部、４２…フロー管理部、４３…違反タギング部、４４…パケット転送部、４５…フロー管理テーブル、５１…パケットヘッダ解析部、５２…パケット廃棄決定部、５３…キュー長監視部、５４…パケット転送部

Claims (6)

1. 通信網の入口にある境界ノードが、ユーザフロー毎にトラヒックを監視し、その監視結果に応じてパケットヘッダにタギングをし、前記通信網の内部に位置する内部ノードが、タギングの有無とそのときの輻輳状況に応じてパケットの選択廃棄を実施して、各フローの使用帯域を制御するトラヒック制御方法であって、
   前記境界ノードは、
   フロー情報を管理するテーブルを備え、
   パケット到着毎に該パケットがどのフローからのパケットかを調査し、該フローが既に前記テーブルにエントリされていれば、該パケットをトラヒックポリシング対象とし、そうでなければ、パケットサンプリングを実施し、パケットがサンプルされたら、そのパケットの属するフローを前記テーブルに新規エントリし、
   前記テーブルにエントリされているフローのうち、あるフローが長時間に渡って帯域を占有していると判断したら、該フローからのパケットにタギングをし、
   前記内部ノードは、通信網が輻輳した場合にはタギングされたパケットを優先的に廃棄することを特徴とする帯域制御方法。
2. 請求項１に記載の帯域制御方法において、
   前記境界ノードは、
   前記テーブルに、パケットがサンプルされたフローｊの許可レートＡＲｊ［ｂｐｓ］、到着パケット数Ｘｊ、超過バイト数ＮＢｊ、最後に到着したパケットの時刻Ｔｌａｓｔ＿ｊを保持し、
   Ｘｊ ｍｏｄ Ｍ＝０となる毎に、ＡＲｊ←ｍａｘ｛α１×ＡＲｊ、α２×ＡＲ０｝と更新し（ここで、Ｍは予め定める正の整数、α１、α２は０＜α２≦α１＜１の値をとる予め定めるパラメータ、ＡＲ０はＡＲｊの初期値）、
   またパケット到着毎に、Ｘｊ←Ｘｊ＋１、ＮＢｊ←ｍａｘ｛ＮＢｊ−ＡＲｊ（Ｔｎｏｗ−Ｔｌａｓｔ＿ｊ），０｝＋Ｓｐｋｔとし（ここで、Ｔｎｏｗは現時刻、Ｓｐｋｔはパケットサイズ）、
   ＮＢｊがしきい値を超えたら、該パケットをタギングする
   ことを特徴とする帯域制御方法。
3. 請求項１に記載の帯域制御方法において
   通信網の境界ノードでタギングし、通信網の内部ノードでタギングされたパケットを廃棄する代わりに、単一のノード内において、ノードの入口でタギングし、同ノードからの出力リンクが輻輳したら該出力待ちキューにおいてタギングされたパケットを廃棄することを特徴とする帯域制御方法。
4. 通信網の入口にある境界ノードが、ユーザフロー毎にトラヒックを監視し、その監視結果に応じてパケットヘッダにタギングをし、前記通信網の内部に位置する内部ノードが、タギングの有無とそのときの輻輳状況に応じてパケットの選択廃棄を実施して、各フローの使用帯域を制御する帯域制御装置において、
   前記境界ノードは、
   フロー情報を管理するテーブルと、
   パケット到着毎に該パケットがどのフローからのパケットかを調査し、該フローが既に前記テーブルにエントリされていれば、該パケットをトラヒックポリシング対象とし、そうでなければ、パケットサンプリングを実施し、パケットがサンプルされたら、そのパケットの属するフローを前記テーブルに新規エントリする手段と、
   前記テーブルにエントリされているフローのうち、あるフローが長時間に渡って帯域を占有していると判断したら、該フローからのパケットにタギングをする手段と、
   を備え、
   前記内部ノードは、通信網が輻輳した場合にはタギングされたパケットを優先的に廃棄する手段を備える
   ことを特徴とする帯域制御装置。
5. 請求項４に記載の帯域制御装置において、
   前記境界ノードは、
   前記テーブルに、パケットがサンプルされたフローｊの許可レートＡＲｊ［ｂｐｓ］、到着パケット数Ｘｊ、超過バイト数ＮＢｊ、最後に到着したパケットの時刻Ｔｌａｓｔ＿ｊを保持し、
   Ｘｊ ｍｏｄ Ｍ＝０となる毎に、ＡＲｊ←ｍａｘ｛α１×ＡＲｊ、α２×ＡＲ０｝と更新し（ここで、Ｍは予め定める正の整数、α１、α２は０＜α２≦α１＜１の値をとる予め定めるパラメータ、ＡＲ０はＡＲｊの初期値）、
   またパケット到着毎に、Ｘｊ←Ｘｊ＋１、ＮＢｊ←ｍａｘ｛ＮＢｊ−ＡＲｊ（Ｔｎｏｗ−Ｔｌａｓｔ＿ｊ），０｝＋Ｓｐｋｔとし（ここで、Ｔｎｏｗは現時刻、Ｓｐｋｔはパケットサイズ）、
   ＮＢｊがしきい値を超えたら、該パケットをタギングする
   ことを特徴とする帯域制御装置。
6. 請求項４に記載の帯域制御装置において
   通信網の境界ノードでタギングし、通信網の内部ノードでタギングされたパケットを廃棄する代わりに、単一のノード内において、ノードの入口でタギングし、同ノードからの出力リンクが輻輳したら該出力待ちキューにおいてタギングされたパケットを廃棄することを特徴とする帯域制御装置。

Images