(57)【要約】【課題】同時に劣化することを回避できるパケット伝送方法を提供する。【解決手段】同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより古いフローに属するパケットに、通信開始時刻がより新しいフローに属するパケットよりも、高い優先度を付与する、パケット伝送方法。クラシファイアでトークン閾値を、優先制御機構で廃棄閾値を、フロー毎に管理して、条件判断に利用する。【選択図】　図１
2004032157.tif 000002
【特許請求の範囲】
【請求項１】
ＱｏＳ保証を行うパケット伝送方法であって、
同一優先度のパケットから構成される、複数のフローが、保証帯域を共用する場合、これらのフローのうち、少なくとも１つのフローに属するパケットの優先度と、これらのフローのうち、この１つのフローとは異なるフローに属するパケットの優先度とに、差を付けて取り扱う、パケット伝送方法。
【請求項２】
フローの通信開始時刻による先着順に従って、優先度に差を付ける、請求項１記載のパケット伝送方法。
【請求項３】
同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより古いフローに属するパケットの優先度が、通信開始時刻がより新しいフローに属するパケットの優先度よりも、高い優先度となるように、取り扱う、請求項１から２記載のパケット伝送方法。
【請求項４】
同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより古いフローに属するパケットに、通信開始時刻がより新しいフローに属するパケットよりも、高い優先度を付与する、請求項１から３記載のパケット伝送方法。
【請求項５】
同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより新しいフローに属するパケットを、通信開始時刻がより古いフローに属するパケットよりも、先に廃棄する、請求項１から４記載のパケット伝送方法。
【請求項６】
トークンを計測し、パケットの優先度を設定する計測優先度設定部と、
パケットを入力し、高優先度のパケットを前記計測優先度設定部へ出力し、低優先度のパケットを外部へ出力するＭＦクラシファイアと、
フロー毎にトークンパラメータを保持するフロー管理部とを備え、
前記フロー管理部は、前記ＭＦクラシファイアからパケットのフロー情報を入力し、このフロー情報に対応するトークンパラメータを前記計測優先度設定部へ出力し、
前記計測優先度設定部は、トークンを、前記フロー管理部から入力するトークンパラメータにより修正したものと、パケットのパケット長とを、大小比較し、比較結果に従って、パケットの優先度を設定する、トラフィックコンディショナ。
【請求項７】
前記計測優先度設定部は、複数のフローについて、共用される、請求項６記載のトラフィックコンディショナ。
【請求項８】
トークンパラメータは、前記計測優先度設定部の修正において、トークンから差し引かれるトークン閾値であり、フロー情報は、パケットのヘッダ情報である請求項６から７記載のトラフィックコンディショナ。
【請求項９】
前記フロー管理部は、フローの通信開始時刻による先着順に従い、より早く通信が開始されたフローが有利になるように、トークンパラメータを設定する、請求項６から８記載のトラフィックコンディショナ。
【請求項１０】
前記フロー管理部は、一定時間以上通信が継続しているフローのトークンパラメータを、このフローが不利になるように変更する請求項６から９記載のトラフィックコンディショナ。
【請求項１１】
前記フロー管理部は、累積使用量が一定量を超えたフローのトークンパラメータを、このフローが不利になるように変更する請求項６から９記載のトラフィックコンディショナ。
【請求項１２】
前記フロー管理部は、フロー毎にパケットカウンタを有し、パケット到着毎に該当フローのパケットカウンタをゼロにし、それ以外のフローのパケットカウンタを１インクリメントし、パケットカウンタが一定の値を越えたフローについて、管理を終了する請求項６から１１記載のトラフィックコンディショナ。
【請求項１３】
パケットの優先度のクラス毎に設けられる複数のキューと、
パケットを入力し、優先度に従ってパケットを分類するクラシファイアと、
前記クラシファイアが分類したパケットを入力し、パケットに係る廃棄条件が満たされない限り、パケットを、前記複数のキューのいずれかに挿入するキュー管理部と、
フロー毎に廃棄パラメータを保持するフロー管理部とを備え、
前記フロー管理部は、前記クラシファイアからパケットのフロー情報を入力し、このフロー情報に対応する廃棄パラメータを前記キュー管理部へ出力し、
廃棄条件は、パケットのパケット長と、このパケットに係るキューのキュー長と、このパケットに係るフローの廃棄パラメータとに基づいて定められる、優先制御機構。
【請求項１４】
廃棄条件は、パケットのパケット長と、このパケットに係るキューのキュー長との和が、廃棄パラメータより大であるとき、このパケットを廃棄することを示すものである、請求項１３記載の優先制御機構。
【請求項１５】
前記キュー管理部は、複数のフローについて、共用される、請求項１３から１４記載の優先制御機構。
【請求項１６】
前記フロー管理部は、フローの通信開始時刻による先着順に従い、より早く通信が開始されたフローが有利になるように、廃棄パラメータを設定する、請求項１３から１５記載の優先制御機構。
【請求項１７】
前記フロー管理部は、一定時間以上通信が継続しているフローの廃棄パラメータを、このフローが不利になるように変更する請求項１３から１６記載の優先制御機構。
【請求項１８】
前記フロー管理部は、累積使用量が一定量を超えたフローの廃棄パラメータを、このフローが不利になるように変更する請求項１３から１７記載の優先制御機構。
【請求項１９】
前記フロー管理部は、フロー毎にパケットカウンタを有し、パケット到着毎に該当フローのパケットカウンタをゼロにし、それ以外のフローのパケットカウンタを１インクリメントし、パケットカウンタが一定の値を越えたフローについて、管理を終了する請求項１３から１８記載の優先制御機構。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ：サービス品質）保証を行うパケット伝送方法及びその関連技術に関するものである。
【０００２】
【従来の技術】
ＩＰネットワークにおける、従来のＱｏＳ技術として、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）において規定されるＤｉｆｆＳｅｒｖ（ＲＦＣ２４７５）がある。
【０００３】
次に、図８を用いて、ＤｉｆｆＳｅｒｖのアーキテクチャを説明する。ここで、ＤｉｆｆＳｅｒｖでは、ＥＦ（仮想専用線）クラス、ＡＦ（最低帯域保証）クラス、ＢＥ（ベストエフォート）クラスという、ＱｏＳクラスが、標準として規定されている。
【０００４】
また、ＤｉｆｆＳｅｒｖでは、品質保証に関する同じルールを適用できる範囲を「ＤＳドメイン」１と呼ぶ。このＤＳドメイン１は、例えば、ＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）網や企業網等として利用される。
【０００５】
そして、ＤＳドメイン１の境界に位置するパケット伝送装置（ルータ、スイッチ、ゲートウェイ等）は、「エッジノード」２、３、４と呼ばれ、ＤＳドメイン１の内部に位置する、パケット伝送装置は、「コアノード」５、６と呼ばれる。
【０００６】
エッジノード２、３、４の入力インターフェイスには、ＤＳドメイン１に流入してくるパケット１１を監視する、トラフィックコンディショナ（Ｔｒａｆｆｉｃ　Ｃｏｎｄｉｔｉｏｎｅｒ）１０が設けられる（図９参照）。
【０００７】
このトラフィックコンディショナ１０は、ＭＦ（Ｍｕｌｔｉ−Ｆｉｅｌｄ）クラシファイア１２を持つ。ＭＦクラシファイア１２は、流入してくるパケット１１のヘッダ情報を見て、どのＱｏＳクラスのパケットか分類し、ＱｏＳクラス毎に使用帯域を計測する。
【０００８】
そして、ＭＦクラシファイア１２は、契約違反の有無に応じて、流入してくるパケット１１のＤＳＣＰ（ＤｉｆｆＳｅｒｖ　Ｃｏｄｅ　Ｐｏｉｎｔ：優先度に相当）フィールドに、値を設定する。
【０００９】
また、コアノード５、６は、図１０に示すように、ＢＡ（Ｂｅｈａｖｉｏｒ　Ａｇｇｒｅｇａｔｅ）クラシファイア２１を備えた、優先制御機構を持つ。このクラシファイア２１は、エッジノード２、３、４で設定された、ＤＳＣＰの値のみを参照して分類を行い、ＤＳＣＰの値に応じて、パケット１１の転送処理（優先制御）を行う。
【００１０】
【発明が解決しようとする課題】
（問題点１）トラフィックコンディショナの関連
従来のＤｉｆｆＳｅｒｖでは、トークンバケツと言う機構を用いて、トラッフィクの計測やＤＳＣＰのマーキング（優先度の設定）、パケットの廃棄を行っている。
【００１１】
以下、簡単のために、ＡＦクラス（高優先度）とＡＦクラス以外（低優先度）との、二つのクラスがある場合を例にとり、図９を用いて説明する。
【００１２】
図９は、従来のトラフィックコンディショナのブロック図である。このトラフィックコンディショナ１０は、エッジノード２、３、４の入力インターフェイスとして使用され、パケット１１の監視を行う。
【００１３】
ここで、ＡＦクラスでは、契約帯域として最低保証帯域が決められており、ＭＦクラシファイア１２は、パケット１１がＡＦクラスのパケットか否かをチェックする。
【００１４】
パケット１１がＡＦクラス以外であれば、ＭＦクラシファイア１２は、このパケット１１に、ＡＦクラス以外のクラスの優先度のマーク（ＤＳＣＰ３）を設定し、トラフィックコンディショナ１０の外部へ出力する。
【００１５】
パケット１１がＡＦクラスであれば、ＭＦクラシファイア１２は、パケット１１をトークンバケツ機構を持つ計測優先度設定部１３へ出力する。
【００１６】
計測優先度設定部１３は、所定レートｒでトークン１５が蓄積される、トークンバッファ１４を持つ。計測優先度設定部１３は、パケット１１を入力すると、そのパケット長と入力時にトークンバッファ１４に蓄積されているトークン量を比較する。
【００１７】
ここで、トークン量≧パケット長ならば、計測優先度設定部１３は、保証帯域内であると判定し、パケット１１に高優先度のマーク（ＤＳＣＰ１）を設定し、パケット１１をトラフィックコンディショナ１０の外部へ出力する。このとき、トークンバッファ１４内のトークンは、パケット１１のパケット長分、減らされる。
【００１８】
一方、トークン量＜パケット長ならば、計測優先度設定部１３は、保証帯域を超えていると判定し、パケット１１に低優先度のマーク（ＤＳＣＰ２）を設定し、パケット１１をトラフィックコンディショナ１０の外部へ出力する。
【００１９】
このように、従来のトラフィックコンディショナ１０では、ＡＦクラスのフローが複数ある場合にも、これらのフローを区別することなく、同一の計測優先度設定部１３で計測し、同一優先度のフローの合計帯域が、保証帯域内であるか、あるいは、保証帯域をオーバーしているかを、チェックしている。
【００２０】
ここで、同一優先度のフローの合計帯域が、保証帯域を超えた場合、複数のＡＦクラス（高優先度）のフローのうち、保証帯域を超えた分のパケットが、フローの区別なく、ＤＳＣＰ２（低優先度）とマークされてしまう。
【００２１】
ＤＳＣＰ２のパケットは、帯域保証されないから、輻輳が発生すると、破棄されてしまう。即ち、どのＡＦクラスのフローも、区別なく一様に廃棄されるおそれがある。
【００２２】
これを現象的に説明すると、つぎのようになる。即ち、複数のユーザが、ＡＦクラスのパケット通信を使用して、映像を受信し、これを見ているような場合、輻輳が発生すると、全てのユーザが見ている映像が、同時に乱れてしまうことになる。
【００２３】
（問題点２）優先制御機構の関連
図１０は、従来の優先制御機構のブロック図である。図８に示す、コアノード５、６やエッジノード２、３、４の出力インターフェイスとして、図１０に示す優先制御機構２０が使用される。
【００２４】
優先制御機構２０は、エッジノード２、３、４でマークされたＤＳＣＰによって、パケット１１を分類し、ＤＳＣＰに応じた転送処理（キューイング、スケジューリング）を行う。なお以下、簡単のため、２クラスの場合を説明する。
【００２５】
クラシファイア２１は、ＤＳＣＰに基づいて、パケット１１が、どのＱｏＳクラスに属するか分類する。
【００２６】
クラシファイア２１は、クラス１のパケットをキュー２２に挿入し、クラス２のパケットを、キュー２３へ挿入する。但し、キュー２２、２３が、パケットで一杯の場合は、パケットは、キュー２２、２３に挿入されず廃棄される。
【００２７】
スケジューラ２４は、これらのキュー２２、２３に関し、ＰＱ（Ｐｒｉｏｒｉｔｙ　Ｑｕｅｕｉｎｇ）やＷＲＲ（Ｗｅｉｇｈｔｅｄ　Ｒｏｕｎｄ　Ｒｏｂｉｎ）等のアルゴリズムに従って、取り出すキューと、送出するパケット量を決定する。そして、この決定に従い、キュー２２またはキュー２３から、パケットが優先制御機構２０の外部へ出力される。
【００２８】
ここで、ＡＦ（最低帯域保証）クラスのような場合には、輻輳時と非輻輳時とで、スケジューラ２４によりサービスされる、パケットレート、即ち、使用可能な帯域が異なる。
【００２９】
もし、輻輳時に、契約帯域を超えてしまうと、本来優先されるべき、ＤＳＣＰ２のパケットが、廃棄される事態が発生する。
【００３０】
また、パケットの計測と優先度設定（ＤＳＣＰ１やＤＳＣＰ２等の）は、ＤＳドメインへのパケット入力時に行われ、パケットの発信者に依存している。
【００３１】
しかしながら、ＤＳドメイン１を出て行くパケットに関し、受信者の利用帯域に応じた帯域保証を行いたい場合もある。このような場合、発信者のベースでは、ＤＳＣＰ１（高優先度）とマークされたパケットであっても、その総計が受信者の保証帯域を超えると、破棄されてしまう事態が発生する。
【００３２】
そこで本発明は、輻輳が発生し、使用可能帯域が減少した場合でも、全てのフローの通信品質が、同時に劣化することを回避できるパケット伝送方法及びその関連技術を提供することを目的とする。
【００３３】
【課題を解決するための手段】
請求項１記載のパケット伝送方法では、同一優先度のパケットから構成される、複数のフローが、保証帯域を共用する場合、これらのフローのうち、少なくとも１つのフローに属するパケットの優先度と、これらのフローのうち、この１つのフローとは異なるフローに属するパケットの優先度とに、差を付けて取り扱う。
【００３４】
この構成により、フローの優先度に差が付けられるため、相対的に有利になるフローに属するパケットは、廃棄を免れることになり、このフローの通信品質は維持される。その結果、輻輳が発生し、使用可能帯域が減少した場合でも、全てのフローの通信品質が、同時に劣化する事態を回避できる
【００３５】
請求項２記載のパケット伝送方法では、フローの通信開始時刻による先着順に従って、優先度に差を付ける。
【００３６】
請求項３記載のパケット伝送方法では、同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより古いフローに属するパケットの優先度が、通信開始時刻がより新しいフローに属するパケットの優先度よりも、高い優先度となるように、取り扱う。
【００３７】
請求項４記載のパケット伝送方法では、同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより古いフローに属するパケットに、通信開始時刻がより新しいフローに属するパケットよりも、高い優先度を付与する。
【００３８】
請求項５記載のパケット伝送方法では、同一優先度のパケットから構成される、複数のフローの帯域の和が、これらのフローが共有する保証帯域を超えた場合、フローの通信開始時刻による先着順に従って、通信開始時刻がより新しいフローに属するパケットを、通信開始時刻がより古いフローに属するパケットよりも、先に廃棄する。
【００３９】
これらの構成により、通信開始時刻が早いフローは、有利に扱われることになり、新参のフローにより、古参のフローの品質が劣化することがなく、合理的な通信制御を行える。
【００４０】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態を説明する。
（実施の形態１）
本形態は、エッジノードの入力インターフェイスとして使用され、ＤＳドメインに流入してくるパケットを監視する、トラフィックコンディショナに関する。
【００４１】
以下、簡単のために、ＡＦクラス（高優先度）とＡＦクラス以外（低優先度）との、２つのクラスがある場合を例にとり説明するが、本形態は、３つ以上のクラスがある場合にも、同様に適用できる。
【００４２】
図１は、本発明の実施の形態１におけるトラフィックコンディショナのブロック図である。図１に示すように、このトラフィックコンディショナ３０は、次の要素を有する。
【００４３】
まず、計測優先度設定部３２は、トークンを計測し、パケット１１の優先度を設定するものであり、所定レートｒでトークン３５が蓄積される、トークンバッファ３４を持つ。
【００４４】
ＭＦクラシファイア３１は、パケット１１を入力し、高優先度のパケット（ＡＦクラス）を、計測優先度設定部３２へ出力し、低優先度のパケット（ＡＦクラス以外）を、トラフィックコンディショナ３０の外部へ出力する。
【００４５】
フロー管理部３３は、図２に示すように、フロー毎にトークンパラメータを保持する、フロー管理テーブル４０と、このテーブル４０から所定のデータを検索したり、このテーブル４０に所定のデータを登録したりする、フロー検索登録部４１とを有する。
【００４６】
本形態では、このテーブル４０は、フローＮｏ．、ヘッダ情報、トークン閾値の、３つのフィールドを持ち、フロー毎にデータを管理する。このトークン閾値は、トークンパラメータに相当する値である。トークンパラメータとしては、他に、トークン量に乗ずる係数などがある。
【００４７】
図１に示すように、ＭＦクラシファイア３１は、パケット１１を入力すると、そのヘッダ情報を、フロー情報として、フロー管理部３３に出力する。
【００４８】
フロー管理部３３は、ＭＦクラシファイア３３からヘッダ情報を入力すると、フロー検索登録部４１とフロー管理テーブル４０を用いて、このヘッダ情報に対応するフローの、トークン閾値Ａを、計測優先度設定部３２へ出力する。
【００４９】
計測優先度設定部３２は、ＭＦクラシファイア３１から、パケット１１（ＡＦパケット）を入力すると、そのパケット長と入力時にトークンバッファ１４に蓄積されているトークン量を比較する。
【００５０】
計測優先度設定部３２は、トークンバッファ３４のトークン量からフロー管理部３３から得た、トークン閾値Ａを引いた値（トークンを、フロー管理部３３から入力するトークンパラメータにより修正したもの）と、パケット１１のパケット長とを、大小比較する。
【００５１】
すなわち、（トークンバッファ３４の現在のトークン量−トークン閾値Ａ）≧パケット長の場合は、計測優先度設定部３２は、保証帯域内として、このパケット１１に高優先度のマーク（ＤＳＣＰ１）を付与して出力する。
【００５２】
逆に、（トークンバッファ３４の現在のトークン量−トークン閾値Ａ）＜パケット長の場合は、計測優先度設定部３２は、保証帯域をオーバーしているとして、このパケット１１に低優先度のマーク（ＤＳＣＰ２）を付与して出力する。
【００５３】
なお、（トークンバッファ３４の現在のトークン量−トークン閾値Ａ）＝パケット長の場合は、上記によらず、保証帯域をオーバーしているとして、低優先度のマーク（ＤＳＣＰ２）を付与して、パケット１１を出力するようにしてもよい。
【００５４】
ここで、フロー管理部３３は、図２に例示しているように、先に開始されたフローから順に小さなトークン閾値を付与する。
【００５５】
例えば、フローＡ、フローＢ、フローＣの順で、３つのフローが、通信開始された場合、フロー管理部３３では、これらのフローに対するトークン閾値Ｔａ、Ｔｂ、ＴｃがＴａ＜Ｔｂ＜Ｔｃになるように値を割り当てる。
【００５６】
図２の例では、フローＮｏ．１、Ｎｏ．２、Ｎｏ．３の順に通信が開始されているため、これらのトークン閾値は、この順に「０」、「３０００」、「６０００」となっている。
【００５７】
また、フロー管理部３３は、一定時間以上パケットが到着しないフローに関しては、フロー管理テーブル４０からエントリを削除する。
【００５８】
こうすることにより、先に始まったフローほどトークンを獲得しやすくなり、先に始まったフローから優先的にＤＳＣＰ１（高優先のマーク）が付与される。
【００５９】
これにより、ネットワークの輻輳時にＤＳＣＰ２のパケットが廃棄されるような状況においても、先に始まったフローで、かつ、保証帯域内に収まっているフローに関してはパケットの廃棄が発生せず、輻輳時の全フローにわたるパケット廃棄を防止でき、映像通信の場合での全映像の同時劣化を抑制できる。
【００６０】
以上のように、本形態のトラフィックコンディショナによれば、次のようなパケット伝送が実現できる。
【００６１】
即ち、ＱｏＳ保証を行うネットワークにおいて、複数のフロー（同一優先度のパケットからなる）が、保証帯域を共用する場合、あるフローに属するパケットの優先度と、別のフローに属するパケットの優先度とに、差が付けられる。
【００６２】
より具体的には、フローの通信開始時刻による先着順に従って、通信開始時刻がより古いフローに属するパケットに、通信開始時刻がより新しいフローに属するパケットよりも、高い優先度が付与される。
【００６３】
したがって、通信開始時刻がより新しいフローに属するパケットは、通信開始時刻がより古いフローに属するパケットよりも、先に廃棄されることになる。
【００６４】
なお、図１に示すように、計測優先度設定部３２は、複数のフローについて、共用されている。ここで、計測優先度設定部３２を、フローの数だけ設けることも考えられる。しかし、こうすると、システムリソースの負担が大きい。
【００６５】
本形態では、この点を考慮し、トークン閾値という値だけを、図２に示すように、フロー毎に区別して持つことにより、フロー毎に処理を異ならしめることと、システムリソースの負担を軽くすることを、一度に実現している。
【００６６】
（実施の形態２）
本形態は、コアノードやエッジノードの出力インターフェイスとして使用される、優先制御機構に関する。この優先制御機構は、エッジノードでマークされたＤＳＣＰによって、パケット１１を分類し、ＤＳＣＰに応じた転送処理（キューイング、スケジューリング）を行う。
なお以下、簡単のため、実施の形態１と同様に、２クラスの場合を説明するが、本形態は、３以上のクラスが存在する場合にも、キューの数を増やすなどして、同様に適用できる。
【００６７】
図３は、本発明の実施の形態２における優先制御機構のブロック図である。図３に示すように、この優先制御機構５０は、次の要素を有する。
【００６８】
まず、優先制御機構５０は、パケット１１の優先度のクラス毎（本例では２クラス）に設けられる複数のキュー５３、５４を有する。キュー５３には、クラス１のパケットが挿入され、キュー５４には、クラス２のパケットが挿入される。勿論、後述する廃棄条件が満たされる場合は、パケットはいずれのキューにも挿入されず廃棄される。
【００６９】
クラシファイア５１は、パケット１１を入力し、優先度に従って、クラス１とクラス２とに、パケットを分類する。
【００７０】
キュー管理部５２は、クラシファイア５１が分類したパケットを入力し、パケットに係る廃棄条件が満たされない限り、パケットを、キュー５３、５４のいずれかに挿入する。
【００７１】
スケジューラ５５は、ＰＱやＷＲＲ等のアルゴリズムに従って、キュー５３、５４から順次パケットを取り出して、優先制御機構５０の外部へ出力する。
【００７２】
フロー管理部５６は、実施の形態１のフロー管理部３３とよく似た構成を持つ。即ち、図４に示すように、フロー管理部５６は、フロー管理テーブル５７、５８と、これらのテーブル５７、５８から所定のデータを検索したり、これらのテーブル５７、５８に所定のデータを登録したりする、フロー検索登録部５９とを有する。これらのテーブル５７、５８は、フロー毎に廃棄閾値を、保持する、
【００７３】
ここで、本形態では、フロー管理テーブル５７、５８を、クラス毎に設けたが、情報が交錯しないように留意すれば、１つのテーブルで構成しても良い。
【００７４】
また、本形態では、これらのテーブル５７、５８は、フローＮｏ．、ヘッダ情報、廃棄閾値の、３つのフィールドを持ち、フロー毎にデータを管理する。この廃棄閾値は、廃棄パラメータに相当する値である。廃棄パラメータとしては、他に、キュー長に乗ずる係数などがある。
【００７５】
フロー管理部５６は、クラシファイア５１からヘッダ情報（フロー情報に相当）を入力すると、フロー検索登録部５９とフロー管理テーブル５７、５８を用いて、このヘッダ情報に対応するフローの、廃棄閾値を、キュー管理部５２へ出力する。
【００７６】
キュー管理部５２は、クラシファイア５１から受け取ったパケットに対応するクラスの、現在のキュー長と、フロー管理部５６から受け取った廃棄閾値とを用いて、次の廃棄条件により、パケットをキューに挿入するか、あるいは、廃棄するかの判定を行う。
【００７７】
すなわち、（現在のキュー長＋パケット長）＞廃棄閾値の場合は該パケットを廃棄し、（現在のキュー長＋パケット長）≦廃棄閾値の場合は、該パケットを該当するクラスのキューに挿入する。
【００７８】
ここで、フロー管理部５６は、図４に例示しているように、早く開始されたフローから順に大きな廃棄閾値を付与する。
【００７９】
例えば、フローＸ、フローＹ、フローＺの順で、３つのフローの通信が、開始された場合、フロー管理部では、これらのフローに対する廃棄閾値がＴｘ、Ｔｙ、ＴｚがＴｘ＞Ｔｙ＞Ｔｚになるように値を割り当てある。
【００８０】
因みに、図４の例では、クラス１を管理するフロー管理テーブル５７につき、フローＮｏ．１が最も先に通信を開始しており、以下、フローＮｏ．２、フローＮｏ．３の順になっている。このため、この順で、廃棄閾値が、「６００００」、「５５０００」、「５００００」というように、順に小さくなっている。
【００８１】
また、フロー管理部５６は、一定時間以上パケットが到着しないフローに関しては、フロー管理テーブル５７、５８からそのエントリを削除する。
【００８２】
こうすることにより、先に始まったフローほど廃棄されにくくなり、先に始まったフローから優先的にキューに挿入され、スケジューラによるサービスを受けられる。
【００８３】
これにより、ネットワークの輻輳時にスケジューラでサービスされるレートが減少し、キューにパケットが蓄積していく場合でも、先に始まったフローで、かつ、保証帯域内に収まっているフローのパケットに関しては優先的にキューに挿入され、パケットの廃棄が発生しない。
【００８４】
このようにしたので、輻輳時の全フローにわたるパケット廃棄を防止でき、映像通信の場合での全映像の同時劣化を抑制できる。
【００８５】
なお、図３に示すように、キュー管理部５２は、複数のフローについて、共用されている。ここで、キュー管理部５２を、フローの数だけ設けることも考えられる。しかし、こうすると、システムリソースの負担が大きい。
【００８６】
本形態では、この点を考慮し、廃棄閾値という値だけを、図４に示すように、フロー毎に区別して持つことにより、フロー毎に処理を異ならしめることと、システムリソースの負担を軽くすることを、一度に実現している。
【００８７】
（変形例１）
次に、実施の形態１及び２の変形例を説明する。以下の変形例１〜３は、実施の形態１における図２のフロー管理部３３及び実施の形態２におけるフロー管理部５６を変形したものであり、実施の形態１における「トークン閾値」を、実施の形態２における「廃棄閾値」と読み替えれば、同様に適用できる。
【００８８】
したがって、以下、説明の重複を避けるため、実施の形態１に沿ってのみ説明し、実施の形態２に沿う説明は省略する。
【００８９】
図５に示すように、変形例１に係る、フロー管理部６０は、一定時間以上通信が継続しているフローのトークン閾値（実施の形態２では廃棄閾値）を、このフローが不利になるように変更する。
【００９０】
即ち、フロー管理部６０におけるフロー管理テーブル６２に、新たに「継続時間」のフィールドを追加し、該当フローが開始されてからの継続時間をフロー管理部６０において計測する。
【００９１】
継続時間がある一定の時間を超えたフローに関しては、最初に設定されたトークン閾値を、現在フロー管理テーブル６２にある一番大きなトークン閾値よりもさらに大きな値に変更する。この結果、このフローは、不利な取り扱いを受けることになる。
【００９２】
例えば、図５のフローＮｏ．１は、継続時間が長いので、そのトークン閾値を、現在の値「０」から一番大きなトークン閾値よりも大きな値（例えば、「９０００」など）とするものである。
【００９３】
これにより、一定時間を経過したフローのパケットは、最もＤＳＣＰ２（低優先）のマークを設定される可能性が高くなり、先着順で優先的に保護されているフローが、長時間、帯域を占領しつづけることを防止できる。
【００９４】
（変形例２）
本例は、変形例１の「継続時間」を、「累積使用量」に変えたものである。
【００９５】
図６に示すように、変形例２に係る、フロー管理部７０は、累積使用量が一定値以上となるフローのトークン閾値（実施の形態２では廃棄閾値）を、このフローが不利になるように変更する。
【００９６】
即ち、フロー管理部７０におけるフロー管理テーブル７２に、新たに「累積使用量」のフィールドを追加し、該当フローが開始されてからの累積使用量をフロー管理部７０において計測する。
【００９７】
累積使用量がある一定値を超えたフローに関しては、最初に設定されたトークン閾値を、現在フロー管理テーブル７２にある一番大きなトークン閾値よりもさらに大きな値に変更する。この結果、このフローは、不利な取り扱いを受けることになる。
【００９８】
例えば、図５のフローＮｏ．１は、累積使用量が多いで、そのトークン閾値を、現在の値「０」から一番大きなトークン閾値よりも大きな値（例えば、「９０００」など）とするものである。
【００９９】
これにより、累積使用量が一定値を超えたフローのパケットは、最もＤＳＣＰ２（低優先）のマークを設定される可能性が高くなり、先着順で優先的に保護されているフローが、長時間、帯域を占領しつづけることを防止できる。
【０１００】
このように、量で制限することにより、大きな帯域を必要とするフローほど短い時間で制限を受けることになる。
【０１０１】
（変形例３）
本例は、図７に示すように、フロー毎にタイマーを設け、終了判定する方式に比べて、ハードウェアリソースが少なくて済み、ハードウェアでの実現が容易となるように、フロー管理部８０の構成に工夫したものである。
【０１０２】
即ち、本例による、フロー管理部８０は、フロー検索登録部８１、フロー管理テーブル８２の他に、カウンタ１、２、３を有する。これらのカウンタ１、２、３は、パケットカウンタとして動作する。
【０１０３】
フロー検索登録部８１は、パケットが到着したら該パケットの属するフローのパケットカウンタを０にし、かつ、その他のフローのパケットカウンタを１インクリメントする。
【０１０４】
これにより、パケットが継続的に到着しているフローに係るカウンタは、パケット到着の都度、０リセットされるが、パケットが全然到着しないフローのカウンタ値は、増加していく。
【０１０５】
そして、フロー検索登録部８１は、パケットカウンタが一定の値になったフローについて、終了したものと判定し、フロー管理テーブル８２からそのエントリを削除する。
【０１０６】
ここで、フロー管理をソフトウェアで行う場合は、フロー毎にタイマーを持ち、一定時間以上パケットの到着がなかったフローに関してはフローが終了したものとして、フロー管理テーブルから削除すれば良い。
【０１０７】
しかしながら、このようにすると、ハードウエア化しにくい。なぜなら、フローの数は、場合によって、かなり大きなものになる可能性もあり、システムリソースの限界から、多量のタイマーを設けるのは、困難だからである。
【０１０８】
本形態では、上述のようなカウンタを設けることにより、システムリソースの負担が軽く、しかも、多量のタイマーを設けたのと同等の処理を実現できる。
【０１０９】
【発明の効果】
本発明によれば、次の効果がある。
輻輳時において、使用可能帯域が減少した場合でも、全フローのパケットが一様に廃棄されることを防止でき、全フローへの通信品質劣化を抑制できる。
【０１１０】
ＤｉｆｆＳｅｒｖ方式の通信品質保証ネットワークにおける最低帯域保証サービスを用いて、複数の映像通信を行うような場合に、輻輳が発生し、使用可能帯域が減少した時でも、全映像の同時画質劣化を防止できる。
【０１１１】
ＤｉｆｆＳｅｒｖ方式をとるか否かに関わらず、一般的な通信品質保証方式において、サービス可能な帯域が変動するようなサービスを用いて、複数の映像通信を行うような場合に、輻輳が発生し、使用可能帯域が減少した時でも、全映像の同時画質劣化を防止できる。
【０１１２】
先着順で優先的に保護されているフローが、長時間帯域を使用しつづけることを防止することが可能となる。
【０１１３】
先着順で優先的に保護されているフローが、大きな帯域を使用しつづけることを防止することが可能となる。
【０１１４】
量で制限をもうけることにより大きな帯域を必要とするフローほど短い時間で制限を受けることになる。
【０１１５】
フロー毎にタイマーを設け、終了判定する方式に比べて、ハードウェアリソースが少なくて済み、ハードウェアでの実現が容易となる。
【図面の簡単な説明】
【図１】本発明の実施の形態１におけるトラフィックコンディショナのブロック図
【図２】同フロー管理部のブロック図
【図３】本発明の実施の形態２における優先制御機構のブロック図
【図４】同フロー管理部のブロック図
【図５】本発明の変形例１におけるフロー管理部のブロック図
【図６】本発明の変形例２におけるフロー管理部のブロック図
【図７】本発明の変形例３におけるフロー管理部のブロック図
【図８】ＤｉｆｆＳｅｒｖアーキテクチャの説明図
【図９】従来のトラフィックコンディショナのブロック図
【図１０】従来の優先制御機構のブロック図
【符号の説明】
１１　パケット
３０　トラフィックコンディショナ
３１　ＭＦクラシファイア
３２　計測優先度設定部
３３、５６、６０、７０、８０　フロー管理部
３４　トークンバッファ
３５　トークン
４０、５７、５８、６２、７２、８２　フロー管理テーブル
４１、５９、６１、７１、８１　フロー検索登録部
５０　優先制御機構
５１　クラシファイア
５２　キュー管理部
５３、５４　キュー
５５　スケジューラ
【図１】
2004032157.tif 000003
【図２】
2004032157.tif 000004
【図３】
2004032157.tif 000005
【図４】
2004032157.tif 000006
【図５】
2004032157.tif 000007
【図６】
2004032157.tif 000008
【図７】
2004032157.tif 000009
【図８】
2004032157.tif 000010
【図９】
2004032157.tif 000011
【図１０】
2004032157.tif 000012