JP2006229516A - 品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム - Google Patents

Abstract

【課題】受付判定として、従来の実効帯域ｅ_ｋを用いて行う判定よりも安全側となり、論理的パケットロスをゼロのままとして、スケーラビリティを向上させ、収容効率を最大とした受付判定を可能とする。
【解決手段】ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法であり、各転送ノードの接続情報、リンクリソースを把握する手順（２０１）、各セッションフローｋへ割り当てる実効帯域を経由するリンクｉｊに依存せず網内で共通した値ｅ_ｋとする手順（Ｄ_ｍｉｎを計算する手順からｅ_ｋを計算）（２０４）、リンク帯域Ｃ_ｉｊと全セッションフローの実効帯域合計値Σｅ_ｋを比較して受付可否を判定する手順（２０６〜２０８）と、σ_ｋ＝ｒ_ｋＤ_ｍｉｎの関係式を用いて上記受付可否を判定する手順を有する。
【選択図】図８

Description

本発明は、ＵＮＩ（Ｕｓｅｒ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）間の品質保証サービスを提供するための品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムに関する。

ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及してきている。それに伴って、様々なサービスがインターネットを介して提供されるようになり、その通信品質が重要視されるようになっている。特に、リアルタイムな映像、音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットでは、そのデータ転送品質を保証する仕組みがないため、従来では、ＩＰ閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。

ＩＰ網においては、データ転送品質を保証するサービスモデルとして、主にＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋｆｏｒｃｅ）（標準化団体）で検討されたＩｎｔｓｅｒｖとＤｉｆｆｓｅｒｖに分けられる。
Ｉｎｔｓｅｒｖは、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルである。Ｉｎｔｓｅｒｖモデルでは、ｅｎｄ−ｔｏ−ｅｎｄでネットワーク経路上の帯域を予約するプロトコルであるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いて、遅延、パケット損失率を厳密に保証するサービスクラス（Ｇｕａｒａｎｔｅｅｄ Ｓｅｒｖｉｃｅ）か、優先サービスクラス（Ｃｏｎｔｒｏｌｌｅｄ−ｌｏａｄ Ｓｅｒｖｉｃｅ）を提供する。

ＲＳＶＰリクエストはネットワーク内の各転送ノードによりフォワーディングされ、リクエストを受ける転送ノードは管理する帯域情報をもとにリクエストされるサービスが提供可能か否かを判断し、提供可能な場合にはｅｎｄ−ｔｏ−ｅｎｄで帯域を確保し、コネクションを確立させる。ＲＳＶＰリクエストはトークンバケットモデルに従ったトラヒック規定を含んでおり、トークンバケットパラメータに従った帯域確保を行なう。
しかしながら、品質保証型のサービスを提供するためには、ＲＳＶＰを用いたＩｎｔｓｅｒｖでは、ネットワーク転送ノードにおいて、ＲＳＶＰに関連する情報を全てリアルタイムに管理し、かつパケット転送を行う必要があるため、統一された受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題がある（例えば、Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｇｅｎｅｒａｌ Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓ ｆｏｒ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１）（非特許文献１参照）、Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４）（非特許文献２参照）。および、Ｓ．Ｓｈｅｎｋｅｒ Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ Ｒ． Ｇｕｅｒｉｎ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ Ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４）（非特許文献３参照））。

一方、Ｄｉｆｆｓｅｒｖは、ネットワーク内において転送パケットにマーキングすることにより、クラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行なうモデルである。Ｄｉｆｆｓｅｒｖモデルでは、規定されたＰＨＢ（Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｒ）により各ネットワーク転送ノードでの転送品質が確保される。サービスクラスに対応するＰＨＢは完全優先であるＥＦ（Ｅｘｐｅｄｉｔｅｄ Ｆｏｒｗａｒｄｉｎｇ）、最低帯域保証であるＡＦ（Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ）が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。

Ｄｉｆｆｓｅｒｖでは、ネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Ｉｎｔｓｅｒｖにおけるスケールしないという課題を解決する。しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題は、依然として残っている（例えば、Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ， ａｎｄ Ｅ．Ｄａｖｉｅｓ， Ｚ．Ｗａｎｇ，Ｗ．Ｗｅｉｓｓ“Ａｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ ２４７５，Ｄｅｃ．１９９８（ｐｐ．８〜ｐｐ．１１）または（ｐｐ．２０〜ｐｐ．２４）（非特許文献４参照）。Ｂ．Ｄａｖｉｅ，Ａ．Ｃｈａｒｎｙ， Ｊ．Ｃ．Ｒ．Ｂｅｎｎｅｔｔ，Ｋ．Ｂｅｎｓｏｎ，Ｊ．Ｙ．ＬｅＢｏｕｄｅｃ，Ｗ．Ｃｏｕｒｔｎｅｙ，Ｓ．Ｄａｖａｒｉ，Ｖ．Ｆｉｒｏｉｕ，ａｎｄ Ｄ．Ｓｔｉｌｉａｄｉｓ，“Ａｎ Ｅｘｐｅｄｉｔｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ（Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｒ），”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ３２４６，Ｍａｒ．２００２（ｐｐ．２−ｐｐ．８）（非特許文献５参照）。
Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ Ｇｒｏｕｐ，”ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ １９９９（ｐｐ．２−ｐｐ．３）（非特許文献６参照）。）

サービス提供品質の規定に関してはＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ｒｅｍｍｅｎｄａｔｉｏｎ）において、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。しかしながら、ＩＴＵ−Ｔ勧告Ｙ．１５４１における規定された転送品質をＹ．１２２１におけるサービスモデルで実現する方法に関しては、検討されておらず、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る（例えば、ＩＴＵ−Ｔ勧告Ｙ．１５４１（ｐｐ．５−ｐｐ．６）（非特許文献７参照）。ＩＴＵ−Ｔ勧告Ｙ．１２２１（ｐｐ．６−ｐｐ．７）（非特許文献８参照）。）。

利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行う，仮想バッファ／トランクモデルがある。仮想バッファ／トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をＯＮ／ＯＦＦトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域（Ｅｆｆｅｃｔｉｖｅ Ｂａｎｄｗｉｄｔｈ）の積み上げ管理を以下の考え方に基づいて行い、論理的パケット損失率ゼロの受付判定を行う。

（トークンバケットから送出されるトラヒックの最悪条件）
トークンバケットで規定されるトラヒックに関しては、図３に示す極値ＯＮ／ＯＦＦ過程（Ｔ_ｏｎの期間はピークレートＰでパケットを送出し、Ｔ_ｏｆｆの期間はパケットを送出しない）が最悪条件と考えられる。すなわち、極値ＯＮ／ＯＦＦ過程はトークンバケットから送出されるトラヒックパターンの中では、ネットワークに対して最も負荷が大きく、極値ＯＮ／ＯＦＦ過程でのトラヒックパターンの受付判定で、論理的パケットロス率がゼロである条件を満足すれば、そのほかのトラヒックパターンにおいても論理的パケットロス率がゼロである条件を十分満足する。時刻０からｔまでの間にトークンバケットから送出されるトラヒック量Ω（ｔ）とトークンバケットパラメータ（トークンレートｒ，バケットサイズσ，ピークレートＰ）、およびＴ_ｏｎ，Ｔ_ｏｆｆの関係は図４に示すように表わすことができ、図１、図２の関係から極値ＯＮ／ＯＦＦ過程におけるＴ_ｏｎ，Ｔ_ｏｆｆはトークンバケットパラメータで表わすことができ、次式（１）（２）で表わされる。

（極値ＯＮ／ＯＦＦ過程トラヒックが使用するリソース量（ｂ，ｃ）の特性）
図５に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
ｖ（ｔ）を時刻ｔにおけるバッファ量，ｂを使用するバッファ量の最大値，ｕ（ｔ）を時刻ｔにおける利用帯域，ｃを利用可能な最大帯域とする。図６に示す“キューイングシステムのバッファ量と滞留している時間”と“キューイングシステムにおいて利用している帯域とその時間”との関係に着目すると、このキューイングシステムサービス窓口でのｂｕｓｙ ｐｅｒｉｏｄ Ｄ_ｏｎとｉｄｌｅ ｐｅｒｉｏｄ Ｄ_ｏｆｆとの関係は、次式（３）（４）で表わされる。

以上の表現を用いてキューイングシステムにおけるｂｕｓｙ ｐｅｒｉｏｄである時間の割合を（３），（４）式を用いて表わすと、次式（５）が成立する。

さらに、上式（５）を変形すると、

が成り立つ。

（仮想バッファ／トランクモデル）
今、トークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）を持つセッションフローｋ（ｋ＝１，２，・・，ｋ）がリソース（バッファ量Ｂ_ｉｊ，リンク帯域Ｃ_ｉｊ）を持つノードｉからノードｊへ至るリンクｉｊに多重されることを考える。このとき、図７に示すように各セッションフローｋに対してリンク帯域ｃ_ｋ（ｒ_ｋ≦ｃ_ｋ≦Ｐ_ｋ）を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Ｃを上回らないようにする。すなわち、

このとき、セッションフローｋが使用する仮想的なバッファリソースの最大値ｂ_ｋは、上式（６）の結果を用いて、

と表わすことができる。

実際のバッファ使用量の最大値ｂは、仮想バッファ使用量の和Σｂ_ｋを上回ることはないので、次式（９）が成り立てば、論理的なパケットロスがゼロになる。

言い換えると、上式（８）を満たすＫ組の仮想リソース（ｂ_ｋ，ｃ_ｋ）に対して、上式（７）および上式（９）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
この方式では、一般的にバッファ量とリンク帯域という２種類のリソース使用量を管理しなければならないが、（ｂ_ｋ，ｃ_ｋ）が下式（１０）を満たせば、バッファ使用量＝リンク使用帯域となるため、どちらか一つのリソース管理を行うだけでよい。

この場合、上式（８）および上式（１０）から仮想リンク帯域ｃ_ｋは、下式（１１）となる。

上式（１１）で与えられたｃ_ｋを、セッションフローｋのリンクｉｊにおける実効帯域ｅ_ｋ，_ｉｊとすれば、この実効帯域ｅ_ｋ，_ｉｊはセッションフローｋを各ノードのＩＦにおいて論理的パケットロスがゼロの状態で多重し、積み上げ計算することができる帯域値である。

しかしながら、サービス提供網内のリソース（バッファ量Ｂ_ｉｊ，リンク帯域Ｃ_ｉｊ）をあらかじめ見積もる必要があるという課題と、実効帯域ｅ_ｋ，_ｉｊはトークンバケットパラメータに依存し、さらにサービス提供網において経由する全てのリンクにおけるリンク帯域とバッファ量に依存するため、実効帯域ｅ_ｋ，_ｉｊを積み上げ帯域として受付判定を行う仮想バッファ／トランクモデルは、論理的パケットロスをゼロにすることはできるが、各リンクごとに実効帯域ｅ_ｋ，_ｉｊを計算するためスケールしないという課題と、申告されるトークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）の組み合わせによっては、実効帯域ｅ_ｋ，_ｉｊが極端に大きくなり、サービス提供網における収容率が下がるという課題と、トークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）の全てを自由に指定することを許可するため、パラメータ数が多く、管理が煩雑になるという課題とがある（例えば、Ａ．Ｅｌｗａｌｉｄ，Ｄ．Ｍｉｔｒａ，ａｎｄ Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，“Ａ Ｎｅｗ Ａｐｐｒｏａｃｈ ｆｏｒ Ａｌｌｏｃａｔｉｎｇ Ｂｕｆｆｅｒｓ ａｎｄ Ｂａｎｄｗｉｄｔｈ ｔｏ Ｈｅｔｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ Ｔｒａｆｆｉｃ ｉｎ ａｎ ＡＴＭ ｎｏｄｅ，”ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，１３（６）：１１１５−１１２７，Ａｕｇ．１９９５．（非特許文献９参照））。

ＩｎｔｓｅｒｖまたはＤｉｆｆｓｅｒｖまたはＩＴＵ−Ｔ勧告Ｙ．１２２１サービスモデルに仮想バッファ／トランクモデルを適用することにより、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖのサービス提供網内で統一された受付判定を行なわなければならないという課題は、解決可能である。
しかしながら、品質保証型のサービスを提供するためには、仮想バッファ／トランクモデルにおける課題が残っており、さらに、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１における，サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る。

Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，"Ｇｅｎｅｒａｌ Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓ ｆｏｒ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１） Ｊ．Ｗｒｏｃｌａｗｓｋｉ，"Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４） Ｓ．Ｓｈｅｎｋｅｒ Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ Ｒ． Ｇｕｅｒｉｎ，"Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ Ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４） Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ， ａｎｄ Ｅ．Ｄａｖｉｅｓ， Ｚ．Ｗａｎｇ，Ｗ．Ｗｅｉｓｓ"Ａｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ ２４７５，Ｄｅｃ．１９９８（ｐｐ．８〜ｐｐ．１１）または（ｐｐ．２０〜ｐｐ．２４）。 Ｂ．Ｄａｖｉｅ，Ａ．Ｃｈａｒｎｙ， Ｊ．Ｃ．Ｒ．Ｂｅｎｎｅｔｔ，Ｋ．Ｂｅｎｓｏｎ，Ｊ．Ｙ．ＬｅＢｏｕｄｅｃ，Ｗ．Ｃｏｕｒｔｎｅｙ，Ｓ．Ｄａｖａｒｉ，Ｖ．Ｆｉｒｏｉｕ，ａｎｄ Ｄ．Ｓｔｉｌｉａｄｉｓ，"Ａｎ Ｅｘｐｅｄｉｔｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ（Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｒ），"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ３２４６，Ｍａｒ．２００２（ｐｐ．２−ｐｐ．８）。 Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，"Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ Ｇｒｏｕｐ，"ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ １９９９（ｐｐ．２−ｐｐ．３） ＩＴＵ−Ｔ勧告Ｙ．１５４１（ｐｐ．５−ｐｐ．６） ＩＴＵ−Ｔ勧告Ｙ．１２２１（ｐｐ．６−ｐｐ．７） Ａ．Ｅｌｗａｌｉｄ，Ｄ．Ｍｉｔｒａ，ａｎｄ Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，"Ａ Ｎｅｗ Ａｐｐｒｏａｃｈ ｆｏｒ Ａｌｌｏｃａｔｉｎｇ Ｂｕｆｆｅｒｓ ａｎｄ Ｂａｎｄｗｉｄｔｈ ｔｏ Ｈｅｔｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ Ｔｒａｆｆｉｃ ｉｎ ａｎ ＡＴＭ ｎｏｄｅ，"ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，１３（６）：１１１５−１１２７，Ａｕｇ．１９９５．

前述のように、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網において、１）仮想バッファ／トランクモデルの、あらかじめサービス提供網内の各ネットワーク転送ノードのリンクにおけるバッファ量を見積もる必要があるという課題があり、また、２）サービス提供網では、ネットワーク内の各リンクごとに実効帯域を計算する必要があるため、スケールしないという課題があり、また、３）ユーザが帯域要求時にトークンバケットパラメータである，トークンレート、バーストサイズ、ピークレートを全て自由に指定することを許可するため、サービス提供網における収容率が上がらないという課題があり、また、４）帯域要求時のサービス提供網側でのパラメータ管理が煩雑になるという課題があった。

（目的）
本発明の目的は、上記１）〜４）の課題を解決し、従来の品質保証型サービスモデルである，Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１におけるサービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題を解決することが可能な品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムを提供することにある。

図１は、本発明による品質保証サービスを実現する受付判定システムの基本構成図であり、図２は本発明において、集線を行わないリンクを受付判定対象外とすることの説明図である。
本発明のサービス提供網の受付判定システムは、図１に示すユーザからの帯域要求に対して受付を行う帯域管理サーバＳと、帯域管理サーバＳに帯域要求やパラメータを送信する際の仲介をするサービス制御サーバＳＳと、ゲートウェイルータＧＷと、コアルータＲで構成されたサービス提供網Ｎに、ユーザ網Ｕ１，Ｕ２におけるターミナル装置（ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指す）ＴＥから流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供する。なお、図１において、Ｎはサービス提供網Ｎ、Ｕ１，Ｕ２はユーザ網である。ユーザ網Ｕ１，Ｕ２のターミナル装置ＴＥから帯域管理サーバＳに対して帯域要求が行われると、それに応じてサーバＳから回答がターミナル装置ＴＥに回答が送られる。
帯域管理サーバＳは、コンピュータ制御により該帯域管理サーバ内のリソースデータベースにおけるサービス提供網Ｎ内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃ_ｉｊ、バッファ網Ｂ_ｉｊ）を管理し、また、帯域管理サーバＳは、該帯域管理サーバ内のリソースデータベースまたは受付判定部の演算回路を動作して種々の演算を実行する。

（請求項１，３について）
本発明のサービス提供網の帯域管理サーバでは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段により、サービス提供網内の各転送ノードにおけるＩＦの接続情報、リンク帯域、ＩＦにおけるバッファ量を取得、または設定を行う。さらに、取得、設定した（Ｃ_ｉｊ，Ｂ_ｉｊ）の値を用いて以下の各リンクｉｊでの許容遅延量Ｄ_ｉｊを計算する。

Ｄ_ｉｊは、サービス提供網内の各ＩＦのリンク帯域、バッファ量に依存した値であるため、この値を含んでいる従来の式（１１）における実効帯域ｅ_ｋ，_ｉｊは各リンクごとに異なった値となり、受付判定を行うためには、各リンクごとに積み上げ帯域を計算しなくてはならない。
ここで、本発明では、論理的パケットロスをゼロとする条件を変えずに、実効帯域ｅ_ｋ，_ｉｊをリンクごとのリソース量により変化しない実効帯域を求める。そのためには、単純にＤ_ｉｊを変化させたときの実効帯域ｅ_ｋ，_ｉｊの最大値を実効帯域とみなすことで安全側の判定となり、論理的パケットロスをゼロとする条件は変わらない。この場合、式（１１）からＤ_ｉｊの最小値を用いることになる。ただし、サービス提供網のリンクの中には、ネットワークの構成上集線をしないために転送待ちが発生せず、受付判定を必要としないリンクも存在する。そのようなリンクでは、通常、Ｄ_ｉｊの値は小さく、そのため単純にＤ_ｉｊの最小値をとると、そのような受付判定の対象とならないリンクを選んでしまい、収容効率が必要以上に悪くなってしまう。そこで、Ｄ_ｉｊの最小値を計算する際のリンクの集合を以下の方法で計算する。

サービス提供網内の全てのリンクの集合Ａの中で、転送ノードｎに直接接続されているリンクでノードｎより他ノードに至るリンクの集合をＳ（ｎ，Ｏ）、他ノードよりノードｎに至るリンクの集合をＳ（ｎ，Ｉ）とする。このとき、一回目の手順として、以下の条件を満たすリンクの集合を求める。

Ｌ（１）に含まれるリンクｉｊは、例えば、図２に示されるリンク３４のように、集線を行っていないリンクであり、ノードｉにおける出力バッファでの待ち合わせによる遅延は発生しない。従って、リンクｉｊは受付判定の対象ではないので、Ｓ（ｉ，Ｏ）から除外する。すなわち、

とする。

さらに、リンクｉｊによりノードｊへ至るトラヒックの最大帯域をＣ_ｉｊとみなすのは過大であり、実際には、Σ_{ｈｉ∈Ｓ（ｉ，Ｉ）−｛ｊｉ｝}Ｃ_ｈｉで抑えられるため、ノードｊに至るリンクの集合からリンクｉｊを除外し、代わりにＳ（ｉ，Ｉ）−｛ｊｉ｝に含まれるリンクを加える。すなわち、下式（１５）とする。

上式（１４），（１５）による変更を上式（１３）に含まれるリンク全てについて行い、集合Ｓ（ｎ，Ｏ），Ｓ（ｎ，Ｉ）の変更を行った後、新たに２回目の手順としてＬ（２）＝｛ｉｊ｜Ｃ_ｉｊ≧Σ_{｛ｈｉ｝∈Ｓ（ｉ，Ｉ）−｛ｊｉ｝}Ｃ_ｈｉ｝を求める。以後、同様の処理を、除かれるリンクがなくなるまで、すなわちＮ回目の手順としてＬ（Ｎ）＝φとなるまで繰り返す。

ここでは、最終的に求められたサービス提供網内のリンクの集合を次式（１６）とし、

次の最小値を計算する。

以上に計算されたＤ_ｍｉｎは、受付判定の対象となるリンクにおけるＤ_ｉｊの中で最小となるため、サービス提供網内で統一的な値として用いる。この値を用いた次式（１８）の実効帯域を計算し、

ｅ_ｋをセッションフローｋ（トークンレートｒ_ｋ，バケットサイズσ_ｋ，ピークレートＰ_ｋ）に対するサービス提供網における統一的な受付判定を行う際の実効帯域とする。ｅ_ｋを用いて積み上げ計算を行い、以下の受付判定を行う。
セッションフローｋが経由するリンクｉｊにおける受付判定

この受付判定は、従来の実効帯域ｅ_ｋ，_ｉｊを用いた受付判定よりも安全側の判定となるため、論理的パケットロスがゼロである条件は変わらない上に、スケーラビリティの阻害要因の一つであるリンクごとの実効帯域の再計算を回避することができる。

（請求項２，４，５について）
さらに、収容効率を考えると、上式（１９）で計算されるｅ_ｋはトークンレートｒ_ｋよりも大きく、ピークレートＰ_ｋよりも小さい値であるため、ｅ_ｋ＝ｒ_ｋとなる場合が一番収容効率が良い。従って、次式（２０）となる。

このときの式（２０）中のＤ_ｍｉｎは、式（１３）〜式（１６）の手順を実施しなくてもよく、サービス提供網内の全てのリンク集合｛ｉｊ｝において以下の単純な最小値を用いてもよい。

上式（２０）を計算すると、

となる。

従って、セッションフローｋのパラメータσ_ｋ，ｒ_ｋおよびネットワークリソース量（Ｃ_ｉｊ，Ｂ_ｉｊ）から計算された固定値Ｄ_ｍｉｎが式（２０）を満たすとき、セッションフローｋの実効帯域はトークンレートｒ_ｋに等しくなる。
上式（２１）は、セッションフローのトークンパラメータが任意の値を取り得る場合には必ずしも成り立たないが、ＵＮＩでセッションフローｋのトークンバケットパラメータに関して規定できるのであれば、上式（２０）を満たすように（バーストサイズσを規定するように）することで収容効率を最大化することができる。具体的な手続きとしては、以下に述べる通りである。

サービス提供条件のＵＮＩトラヒック規定として、セッションフロー接続要求時にフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）に加え、トークンレートｒ_ｋをユーザ網装置からサービス提供網側の帯域管理サーバへ申告し、バケットサイズσ_ｋは式（２１）によりサービス提供網側の帯域管理サーバにおいて自動的に計算する。さらに、ピークレートはユーザ網に接続される物理回線帯域とし、帯域管理サーバでは、帯域要求時にはフロー識別情報からセッションフローが経由するリンクｉｊの集合を計算し、トークンレートｒ_ｋの積み上げ計算により、以下の受付判定を行う。

セッションフローｋが経由するリンクｉｊにおける受付判定

式（２３）による受付判定は式（２２）の条件付きであるため、受付可の場合には、ユーザ網装置に式（２２）によるバケットサイズσ_ｋを通知する必要がある。

（請求項６，７について）
さらに、ＵＮＩトラヒック規定をサービス提供網側で監視する場合、帯域管理サーバは受け付けたセッションフローに対しては、申告されるセッションフロー識別情報と、トークンレートｒ_ｋ，式（２１）で計算されるバケットサイズσ_ｋを用いて、サービス提供網において（セッションフローｋの平均制限帯域）＝（トークンレートｒ_ｋ），（平均バーストサイズ）＝（バケットサイズσ_ｋ）として転送トラヒック流量を監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行う。

（請求項２，４，５について）
本発明によるサービス提供条件のＵＮＩトラヒック規定をまとめると、以下のようになる。
１）トークンレートｒ：ユーザ網から、サービス提供網へ申告
２）バケットサイズσ：式（２２）により、サービス提供網において計算
３）ピークレートＰ：物理回線帯域（リンク帯域）

ここで、図２の説明を行う。
図の１から６は図１に示したサービス提供網Ｎ内のゲートウェイルータ（ＧＷ）あるいはコアルータＲ）のいずれかに相当する。図１のネットワークではルータ３，４に着目したリンク集合として、Ｓ（３，Ｉ）はルータ３に入力する方向のリンク集合を示しており、この集合における各リンク帯域Ｃ_１３，Ｃ_２３，Ｃ_４３とＣ_３４を比較すると、式１３より１０Ｇｂｐｓ＞１Ｇｂｐｓ＋１Ｇｂｐｓであるので、Ｌ（１）＝｛３４｝となる。これは集線を行なっていないリンクであるため、全てのリンク集合の中から除外できる。従って、式（１４）より、Ｓ（３，Ｏ）：＝｛３１，３２｝であり、式（１５）よりＳ（４，Ｉ）：＝｛１３，２３，５４，６４｝である。
一方、ルータ４に着目して同様に考えると、各リンク帯域Ｃ_５４，Ｃ_６４，Ｃ_３４とＣ_４３を比較すると式（１３）より、１０Ｇｂｐｓ＜１０Ｇｂｐｓ＋１０Ｇｂｐｓであるので、Ｌ（１）＝Φとなり、従って、ルータ３，４に着目したときのＬ（１）は、Ｌ（１）＝｛３４｝となる。
同様に、２回目の手順を考えるとＬ（２）＝Φであり、手続きは終了する。
このとき、式（１６）からＳ（２）＝｛３１，３２，４３，４５，４６｝であるから、Ｄｍｉｎ〔Ｂ_３１／Ｃ_３１，Ｂ_３２／Ｃ_３２，Ｂ_４３／Ｃ_４３，Ｂ_４５／Ｃ_４５，Ｂ_４６／Ｃ_４６〕となる。

本発明によれば、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網における受付判定方法とトラヒック制御方法およびシステムにおいて、以下の（課題１）〜（課題５）を解決することができる。

（課題１）帯域要求を受け付ける帯域管理サーバにおいて、セッションフローｋの実効帯域ｅ_ｋを計算すると、このｅ_ｋはリンクｉｊには依存しない値となり、実効帯域ｅ_ｋを用いて、受付判定を行えば、同一セッションフローに対する実効帯域のリンクごとの計算を省略でき、ｅ_ｋ≧ｅ_ｋ，ｉｊとなり、受付判定としては従来のｅ_ｋ，ｉｊを用いて行う判定よりも、安全側となるため、論理的パケットロスを依然としてゼロのままとしている。
従って、本発明における帯域管理サーバにおいて自動的にこのｅ_ｋを計算し、積み上げ管理し、受付判定をすることにより、論理的ロスゼロという転送品質を確保しながら、従来のあらかじめサービス提供網内の各転送ノードのリンクにおけるバッファを見積もる必要があるという課題と、サービス提供網ではネットワーク内の各リンクごとに実効帯域を計算する必要があるためスケールしないという課題を、解決する。

（課題２）さらに、上記実効帯域ｅ_ｋとトークンレートｒ_ｋを等しくし、トークンバケットパラメータに関する関係式を見出すことにより、論理的ロスゼロという転送品質を確保しながら、トークンレートｒ_ｋによる帯域積み上げ計算が可能になり、収容効率を最大とした受付判定が可能となる。これにより、サービス提供網における収容率が上がらないという課題を解決することができる。

（課題３）サービス提供条件としては、ＵＮＩトラヒック規定として、トークンレートｒ_ｋはユーザ網装置からネットワーク側の帯域管理サーバへ申告することとし、バケットサイズσ_ｋは申告されたｒ_ｋをもとに式（２２）によりサービス提供網側で計算され、さらにピークレートＰ_ｋはユーザ網に接続される物理回線帯域とすることにより、帯域要求ごとに申告するパラメータはトークンレートのみとなり、帯域要求時のパラメータ管理が煩雑になるという課題を解決できる。

（課題４）また、ＵＮＩトラヒック規定におけるＤ_ｍｉｎはサービス提供網内のリソース量に応じて計算、規定する値であり、論理的ロスゼロという転送品質を確保しながら、１ｈｏｐでの許容遅延量をＤ_ｍｉｎとする転送品質を規定しており、サービス提供網においてプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定しなければならないという課題を解決することができる。

（課題５）このとき、トークンレートｒ_ｋとバケットサイズσ_ｋを用いてセッションフローｋごとの転送トラヒック流量をサービス提供網側で監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行うことにより、転送品質を監視しなければならないという課題を解決することができる。

以下、本発明の実施例を図面により詳細に説明する。
（実施例１）
図８は、本発明の実施例１に係る受付判定方法の動作フローチャートである。
実施例１においては、ユーザ網におけるＴＥ（ターミナル装置）からの帯域要求がサービス制御サーバを経由し、帯域管理サーバＳに送信され、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。

受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバにおいて、リソースＤＢはサービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣ_ｉｊ、合計のバッファ網をＢ_ｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ２０１）。

帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃ_ｉｊとリンク集合Ｓ（ｎ，Ｉ），Ｓ（ｎ，Ｏ）の情報を元に、条件式（１３）〜（１５）の計算を繰り返し行い、この条件を適用しても、リンクの集合Ｌ（Ｎ）が全て空集合になるまで条件適用を行い、式（１６）によりＳ（Ｎ）を決定する（ステップ２０２，２０３）。
帯域管理サーバＳにおけるリソースＤＢは、式（１７）により許容遅延量Ｄ_ｍｉｎの計算を行う（ステップ２０４）。
ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ２０５）。

帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）を用いて、実効帯域ｅ_ｋを計算し、式（１９）による受付判定を行い（ステップ２０６）、受付許可の場合には、受付許可通知をサービス制御サーバを経由してターミナル装置ＴＥに対して行い（ステップ２０７）、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う（ステップ２０８）。

（実施例２）
図９は、本発明の実施例２に係る品質保証サービスを実現する受付判定方法の動作フローチャートである。
本実施例２においては、図１に示すように、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものである。ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。

受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバＳにおいて、リソースＤＢはサービス提供網ＮのゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得、あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣ_ｉｊ、合計のバッファ量をＢ_ｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ３０１）。
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊの値を元に、式（２１）のＤ_ｍｉｎを計算する（ステップ３０２）。

ユーザ網Ｕ１，２におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒ_ｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ３０３）。
帯域管理サーバにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒ_ｋを用いて、式（２３）による受付判定を行い（ステップ３０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ３０５）。
帯域管理サーバＳにおける監視制御部は、受付可の場合には、申告されたトークンレートｒ_ｋと、式（２２）でバケットサイズσ_ｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ３０６）、サービス制御サーバＳＳを経由して、ターミナル装置ＴＥに対してサービス受付許可通知を行い、バケットサイズσ_ｋを通知する（ステップ３０７）。

（実施例３）
図１０は、本発明の実施例３に係る品質保証サービスを実現する受付判定方法およびトラヒック制御方法の動作フローチャートである。
本実施例３においては、図１に示すように、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由して帯域管理サーバＳに送られ、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。

受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバＳにおいて、リソースＤＢはサービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得、あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣ_ｉｊ、合計のバッファ量をＢ_ｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ４０１）。

帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊの値を元に、式（２１）のＤ_ｍｉｎを計算する（ステップ４０２）。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒ_ｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ４０３）。
帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒ_ｋを用いて、式（２３）による受付判定を行い（ステップ４０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ４０５）。

帯域管理サーバＳにおける監視制御部は、受付可の場合、申告されたトークンレートｒ_ｋと、式（２２）でバケットサイズσ_ｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ４０６）、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒ_ｋ，平均バーストサイズ＝バケットサイズσ_ｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網に透過させるようトラヒック制御を行い（ステップ４０７）、帯域管理サーバＳにおける受付判定部は、受付可の場合には、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う（ステップ４０８）。

（実施例４）
図１１は、本発明の実施例４に係る受付判定システムの構成図である。
本実施例においては、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。

受付判定部Ｓ１およびリソースＤＢ・Ｓ３により構成される帯域管理サーバＳにおいて、リソースＤＢ・Ｓ３は、サービス提供網内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣ_ｉｊ、合計のバッファ量をＢ_ｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う手段１（リソースＤＢ・Ｓ３から延長する矢印）を有する。

また、帯域管理サーバＳにおけるリソースＤＢ・Ｓ３は、取得、設定したリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊの値を元に、条件（１３）〜（１５）の計算を繰り返し行い、この条件を適用しても、リンクの集合Ｌ（Ｎ）が全て空集合になるまで条件適用を行い、式（１６）によりＳ（Ｎ）を決定し、式（１７）により許容遅延量Ｄ_ｍｉｎの計算を行う手段２（リソースＤＢ・Ｓ３の一部を構成する部分）を有する。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサービス制御サーバＳＳに向かう矢印）を有する。

帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンバケットパラメータ（ｒ_ｋ，σ_ｋ，Ｐ_ｋ）を用いて、実効帯域ｅ_ｋを計算し、式（１９）による受付判定を行う手段４（受付判定部の一部を構成する部分）を有する。
受付許可の場合には、受付許可通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行い、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを介してＴＥに延長する矢印）を有する。

（実施例５）
図１２は、本発明の実施例５に係る受付判定システムおよびトラヒック制御システムの構成図である。
本実施例においては、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンパケットモデルに従ったトラヒック転送を行うものとする。

受付判定部Ｓ１、監視制御部Ｓ２、リソースＤＢ・Ｓ３によって構成される帯域管理サーバＳにおいて、リソースＤＢ・Ｓ３は、サービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣ_ｉｊ、合計のバッファ量をＢ_ｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う手段１（リソースＤＢ・Ｓ３から延長する複数の矢印）を有する。

また、帯域管理サーバＳにおけるリソースＤＢ・Ｓ３は、取得，設定したリンク帯域Ｃ_ｉｊとバッファ量Ｂ_ｉｊの値に元に、式（２１）のＤ_ｍｉｎを計算する手段２（リソースＤＢ・Ｓ３の一部を構成する部分）を有する。
また、ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒ_ｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサーバス制御サーバＳＳを経由して帯域管理サーバＳに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒ_ｋを用いて、式（２３）による受付判定を行う手段４（受付判定部Ｓ一の一部を構成する部分）を有する。

また、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを経由してＴＥに延長する矢印）を有する。
また、帯域管理サーバＳにおける監視制御部Ｓ２は、受付可の場合、申告されたトークンレートｒ_ｋと、式（２２）でバケットサイズσ_ｋを計算し、ＵＮＩトラヒック規定値とする手段６（監視制御部Ｓ２からゲートウェイルータＧＷに向う矢印）を有する。
また、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒ_ｋ，平均バーストサイズ＝バケットサイズσ_ｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網Ｎに透過させるようトラヒック制御を行う手段７（帯域管理サーバＳからサービス制御サーバＳＳを経由してＵＮＩに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、受付可の場合、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う手段８（受付判定部Ｓ１の一部を構成する部分）を有する。

なお、本発明における転送トラヒック量監視により違反したトラヒックの扱いについては、廃棄させるか、または、違反トラヒックへのリマーキングをして下位優先度のサービスクラスに送るか、廃棄優先度を高くして廃棄し易くさせる方式を考えることができるが、本発明では、このような転送トラヒック量監視により違反したトラヒックの扱いに関して限定されるものではない。
また、本発明では、ＩＰ電話サービス、映像コミュニケーションサービス、ストリーミング配信等、の要求品質が厳しいサービスをアプリケーションとして利用することができ、上記課題を解決する。従って、本発明はこれらアプリケーションに固有の技術、プロトコルによりその有効性が限定されるものではない。
さらに、本発明では、サービス制御を行うためのプロトコルとして、ＨＴＴＰ、ＳＩＰ、Ｈ．３２３等があるが、これらのシグナリングにより、その有効性が限定されるものではない。

本発明における実施例１〜３に係る受付判定方法の動作説明図である。 本発明における受付判定方法を説明するための図である。 トークンバケットから送出されるトラヒックの最悪パターンである極値ＯＮ／ＯＦＦ過程を説明する図である。 トークンバケットから送出されるトラヒック量とトークンバケットパラメータの関係を説明する図である。 バッファ量と帯域の関係を説明する図である。 キューイングシステムにおけるバッファ量と利用している帯域とそれぞれの時間の関係を説明する図である。 仮想バッファ／トランクモデルを説明する図である。 本発明の実施例１に係る受付判定方法の動作フローチャートである。 本発明の実施例２に係る受付判定方法の動作フローチャートである。 本発明の実施例３に係る受付判定方法とトラヒック制御方法の動作フローチャートである。 本発明の実施例４に係る受付判定システムの構成図である。 本発明の実施例５に係る受付判定システムとトラヒック制御システムの構成図である。

符号の説明

ｒ：セッションフローのトークンレートを表すトークンバケットパラメータ
σ：セッションフローのバケットサイズを表すトークンバケットパラメータ
Ｐ：セッションフローのピークレートを表すトークンバケットパラメータ
Ｔ_０Ｎ：セッションが極値ＯＮ／ＯＦＦ過程に従ってピークレートＰでパケットを送出する期間の長さ
Ｔ_ｏｆｆ：セッションが極値ＯＮ／ＯＦＦ過程に従ってパケットを送出しない期間の長さ
ｂ：ネットワークノードが出力リンク用に割り当てているバッファ容量
ｃ：ネットワークノードからの出力リンクの帯域
Ｄ_ｏｎ：仮想キューイングシステムにおけるｂｕｓｙ期間長
Ｄ_ｏｆｆ：仮想キューイングシステムにおけるｉｄｌｅ期間長
ｒ_ｋ，σ_ｋ，Ｐ_ｋ：特定のセッションフローｋのトークンバケットパラメータ
Ｃ_ｉｊ：ノードｉからノードｊへ至るリンクｉｊのリンク帯域
Ｂ_ｉｊ：ノードｉからノードｊへ至るリンクｉｊに対して、ノードｉの出力インターフェースに用意されるバッファ容量
Ｄ_ｉｊ：ノードｉからノードｊに至るリンクｉｊに対して、ノードｉの出力インターフェースで発生する最大遅延時間
ｃ_ｋ：セッションフローｋに割り当てられる仮想帯域
ｂ_ｋ：セッションフローｋに割り当てられる仮想バッファ容量
ｅ_ｋ，ｉｊ：リンクｉｊ上でセッションフローｋに割り当てられる実効帯域
Ｄ_ｍｉｎ：ネットワーク上の全ノードで統一的に用いられる許容遅延時間
ｅ_ｋ：セッションフローｋに割り当てられるネットワーク上で統一的な実効帯域
Ｓ（ｎ，Ｏ）：ノードｎから他ノードへ至るリンクの集合
Ｓ（ｎ，Ｉ）：他ノードからノードｎへ至るリンクの集合
Ｌ（Ｎ）：Ｎ回目の手順において、あるノードに着目したときの集線効果がなく、受付判定の必要のないリンクの集合

Claims (8)

1. コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法において、
   帯域管理サーバが、該帯域管理サーバ内のリソースデータベースにアクセスして、前記サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃ_ｉｊ、バッファ網Ｂ_ｉｊ）を読み取る手順と、
   前記帯域管理サーバが、該帯域管理サーバ内の受付判定部の演算回路を動作して演算することで、各セッションフローｋへ割り当てる実効帯域ｅ_ｋ，ｉｊを経路を構成するリンクｉｊに依存することなく、前記サービス提供網内で共通した値ｅ_ｋとする手順と、
   前記受付判定部の演算回路で、前記リンク帯域Ｃ_ｉｊと全セッションフローの実効帯域Σ_ｋｅ_ｋを比較演算し、演算結果により前記ユーザ網内装置から要求されたセッションフローの受付可否を判定する手順と
   を有することを特徴とするセッションフローごとの受付判定方法。
2. コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法において、
   帯域管理サーバが、該帯域管理サーバ内のリソースデータベースにアクセスして、前記サービス提供網内の各転送ノードの接続情報、リンク帯域Ｃ_ｉｊおよびバッファ量Ｂ_ｉｊを含むリンクリソース情報を読み取る手順と、
   該帯域管理サーバ内の受付判定部の演算回路を動作して演算することで、前記リンク帯域Ｃ_ｉｊと前記ユーザ網内装置から要求されるセッションフローｋごとのトークンレートｒ_ｋの積み上げ計算値Σ_ｋｒ_ｋを比較して、要求されたセッションフローの受付可否を判定する手順と、
   前記演算回路での演算の結果、受付が可能と判定されたとき、セッションフローｋごとのバケットサイズを前記サービス提供網側で計算し、計算した結果のバケットサイズをＵＮＩトラヒック規定値と決定する手順と
   を有することを特徴とするセッションフローごとの受付判定方法。
3. 請求項１に記載のセッションフローごとの受付判定方法において、
   前記セッションフローｋへ割り当てる実効帯域ｅ_ｋ，ｉｊを経由を構成するリンクｉｊに依存することなく、サービス提供網内で共通した値ｅ_ｋとする手順は、
   前記サービス提供網内の全てのリンクの集合をＡとし、該Ａの中からトラヒックの集線効果のあるリンクを抽出する手順と、
   抽出したリンクの集合をＳとするとき、
   

   

   を計算する手順と、
   セッションフローｋの実効帯域を
   

   

   と計算する手順と
   を有することを特徴とするセッションフローごとの受付判定方法。
4. 請求項２に記載のセッションフローごとの受付判定方法において、
   前記受付が可能なとき、セッションフローｋごとのバケットサイズをサービス提供網側で計算し、ＵＮＩトラヒック規定値とする手順は、
   前記セッションフローｋのバケットサイズσ_ｋを、全てのリンク集合Ａから、
   

   

   としてサービス提供網側で計算する手順
   であることを特徴とするセッションフローごとの受付判定方法。
5. 請求項４に記載のセッションフローごとの受付判定方法において、
   前記セッションフローｋのバケットサイズσ_ｋを、
   

   

   としてサービス提供網側で計算する手順は、
   全てのリンク集合Ａからトラヒックの集線効果のあるリンクを抽出したリンク集合Ｓから
   

   

   として、セッションフローｋのバケットサイズσ_ｋをサービス提供網側で計算する手順
   であることを特徴とするセッションフローごとの受付判定方法。
6. コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網のトラヒック制御方法において、
   帯域管理サーバ内の監視制御部は、受付可の場合、申告されたトークンレートｒ_ｋ，計算済みのバケットサイズσ_ｋのパラメータを用いて、前記サービス提供網がセッションフローごとに（平均制限帯域）＝（トークンレート）、（平均バーストサイズ）＝（バケットサイズ）として転送トラヒック量を監視し、監視流量内のトラヒックのみを前記サービス提供網内に透過させることを特徴とするトラヒック制御方法。
7. コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網のトラヒック制御システムにおいて、
   帯域管理サーバは、
   サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃ_ｉｊ、バッファ網Ｂ_ｉｊ）を把握する手段を有するリソースＤＢと、
   各セッションフローｋへ割り当てる実効帯域ｅ_ｋを用いて受付判定を行う手段を備えた受付判定部と、
   受付可の場合、セッションフローｋごとに（平均制限帯域）＝（トークンレート），（平均バーストサイズ）＝（バケットサイズ）として転送トラヒック量を監視し、監視流量内トラヒックのみを前記サービス提供網に透過させるようにトラヒック制御を行う手段を備えた監視制御部とを有することを特徴とするトラヒック制御システム。
8. コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定システムにおいて、
   帯域管理サーバは、
   サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃ_ｉｊ、バッファ量Ｂ_ｉｊ）を把握する手段、および、各セッションフローｋへの割り当てる実効帯域ｅ_ｋを経路を構成するリンクｉｊに依存せず網内で共通した値ｅ_ｋとする手段を備えたリソースＤＢと、
   リンク帯域Ｃ_ｉｊと全セッションフローの実効帯域Σ_ｋｅ_ｋを比較して、要求されたセッションフローの受付判定を行う受付判定部とを有することを特徴とする受付判定システム。

Images