JP3688525B2 - パケットフロー制御方法及びルータ装置 - Google Patents
パケットフロー制御方法及びルータ装置 Download PDFInfo
- Publication number
- JP3688525B2 JP3688525B2 JP22514399A JP22514399A JP3688525B2 JP 3688525 B2 JP3688525 B2 JP 3688525B2 JP 22514399 A JP22514399 A JP 22514399A JP 22514399 A JP22514399 A JP 22514399A JP 3688525 B2 JP3688525 B2 JP 3688525B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- flow
- aggregate
- path
- router
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のルータ装置を接続することにより構成される通信網におけるパケットフロー制御方法及びルータ装置に関する。
【０００２】
【従来の技術】
近年、ＩＰ（インターネットプロトコル）を用いた通信網、いわゆるインターネットにおいて、転送遅延値やＩＰパケット廃棄率といった、転送品質の保証を可能とするための技術が注目されている。これは、従来のインターネットはベストエフォート型の通信網と呼ばれており、例えば中継ノード（ルータ等）にトラヒックが集中した場合、中継ノードは最善の努力にてＩＰパケットの処理を試みるが、処理しきれなくなれば、ＩＰパケットの廃棄が発生してしまうため、転送品質の保証が不可能であったためである。
【０００３】
インターネットにおいて転送品質の保証が可能な通信を提供するための技術として、ＲＳＶＰと呼ばれる資源予約プロトコルがＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）にて提案されている。ＲＳＶＰでは、送信側端末より受信側端末に対して、送信するＩＰパケットフローのトラヒック特性を記載したメッセージ（Ｐａｔｈメッセージ）を受信側端末宛に送信する。受信側端末では、希望する転送品質を記載したメッセージ（Ｒｅｓｖメッセージ）を送信側端末宛に送信する。中継ノードでは、Ｒｅｓｖメッセージを受信すれば、予め受信したＰａｔｈメッセージに記載されていたトラヒック特性をもとに、Ｒｅｓｖメッセージ内に記載された転送品質の提供が可能か否かを、現在の残余帯域量をもとに判断し、転送品質の提供が可能であれば、必要な帯域を当該フローに対して確保した後に、Ｒｅｓｖメッセージをさらに上流へ転送する。Ｒｅｓｖメッセージが送信側端末に到達すれば、当該フローに対する帯域がインターネット上に確保されたことを意味するので、以降では、希望する転送品質が保証される、ＩＰパケットの転送サービスが可能となる。
【０００４】
上述したような、フロー毎の転送品質の保証を可能とするＩＰパケットの転送サービスを実現するためには、例えば、各々のルータにおいて、ＩＰパケットに対するルーチングポリシーをフロー毎に規定し、当該ルーチングポリシーに従ったルーチング処理を施す必要がある。ルーチングポリシーとして規定すべき内容としては、例えば、フローに属するＩＰパケットの送信先ポート、他のフローとの間でのスケジューリング手段、等が挙げられ、ルーチング表としてルータ内に記憶される。
【０００５】
この場合、処理すべきフロー数が多いルータにおいては、フローに対応して記憶すべきルーチングポリシーも多くなるため、ルーチング表は巨大なものとなってしまい、本表を記憶するために費すメモリ規模が大きくなってしまう。また、ルーチング表が巨大になってしまうと、到着したＩＰパケットのフローに対応するルーチングポリシーの検索に要する時間も大きくなり、その結果、ルータ内でのルーチング処理に要する時間が大きくなってしまう。
【０００６】
ここで、図２７を参照しながら従来の帯域割り当て方法について説明する。
【０００７】
図２７（ａ）に示した通信網システムにおいて、端末１０２１より端末１０２３宛に送信されるＩＰパケットフロー（フローａとする）と、端末１０２２より端末１０２４宛に送信されるＩＰパケットフロー（フローｂとする）とに対し、上述したＲＳＶＰにより帯域が確保された様子を、図２７（ｂ）に示す。図２７（ｂ）において、１０４１がフローａに対して確保された帯域（フローａに対するパスと呼ぶ）、１０４２がフローｂに対して確保された帯域（フローｂに対するパスと呼ぶ）である。なお、フローａ、フローｂ共に、ルータ１０１１とルータ１０１２との間に設定されるパスのルート、希望する転送品質は同一であるものとする。
【０００８】
図２７のような帯域確保（パス設定）を行った場合、フローａ、フローｂ共に、ルータ１０１１を発したＩＰパケットは、同一ルートを通ってルータ１０１２に転送されるので、ルータ１０１１とルータ１０１２との間に位置する各々のルータでは、フローａに属するＩＰパケット、フローｂに属するＩＰパケットに対して施すルーチング処理は、同一なものとなる。しかしながら、実際は、これらのＩＰパケットが属するフローは異なるため、これらのルータにて保持するルーチング表においては、同一なルーチングポリシーであるにも関わらず、別々のエントリとして記載されてしまう。図２７では、同一ルートを通過するフローが２種類ある場合を図示しているが、同一ルートを通過するフロー数がさらに多くなった場合、これによるルーチング表の巨大化によるメモリ規模の増大、ルーチングポリシーの検索に要する時間の増大は無視できないものとなる。
【０００９】
新たな問題として、図２７の端末１０２１の移動に伴い、端末１０２１を収容するルータがルータ１０１３でなくなった状況を考える。この場合、移動前にフローａを収容していたパス１０４１は解放され、フローａを収容する新たなパスを、端末１０２１と端末１０２３との間にて設定することとなる。このようなパスの再設定が行われている間は、端末１０２１より端末１０２３宛に送出されるＩＰパケットの転送は一旦中断してしまい、これによる転送品質の低下は無視できない。
【００１０】
【発明が解決しようとする課題】
従来、フロー毎の転送品質の保証を可能とするＩＰパケットの転送サービスを実現するためには、例えば、各々のルータにおいてＩＰパケットに対するルーチングポリシーをフロー毎に規定し当該ルーチングポリシーに従ったルーチング処理を施す必要があるため、ルーチングポリシーの情報を記憶するために費すメモリ規模が大きくなってしまうという問題があった。また、到着したＩＰパケットのフローに対応するルーチングポリシーの検索に要する時間も大きくなり、その結果、ルータ内でのルーチング処理に要する時間が大きくなってしまうという問題があった。また、新たな問題として、端末の移動に伴ってパスの再設定が行われている間、その端末より送出されるＩＰパケットの転送は一旦中断してしまい、これによる転送品質の低下が無視できないという問題があった。
【００１１】
本発明は、上記事情を考慮してなされたもので、ルーチング処理や帯域割当制御等を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量の削減や、これらの情報を検索するのに要する時間の削減を可能とするパケットフロー制御方法及びルータ装置を提供することを目的とする。
【００１２】
また、本発明は、端末の移動に伴うフロー再設定の範囲を可能な限り狭めることのできるパケットフロー制御方法及びルータ装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、複数のルータ装置を接続して構成される通信網（例えば、ＩＰ（インターネットプロトコル）を用いた通信網）におけるパケット（例えば、ＩＰパケット）フロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスとして、特定のサービスを要求する複数のパケットフローをアグリゲートするための一定の帯域を確保したパス（例えば、プレミアムサービス用のパス）を予め設定しておくことを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、規定すると判断した場合であっても、前記アグリゲートフロー用のパスに割り当てられた帯域が、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を下回る場合には、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスには転送しないよう制御することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスが存在する場合に、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を計算し、少なくともその算出された帯域が該パスに割り当てられるよう制御することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフローへ収容されるパケットフローに属するパケットの自装置への到着過程を監視し、該到着過程が予め規定したアグリゲートフローのトラヒック特性に従う範囲内で、該アグリゲートフローへのパケットの流入を許可することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記複数のパケットフローが、その各々を流れるパケットのパケット長が予め定められた一定の関係（例えば、全て同一の値）にあり、かつ、いずれのパケットフローにおいてもパケット転送速度は変化しない、という条件を満足するか否かに基づいて、前記アグリゲートフローとしてのトラヒック特性を規定するか否かを判断することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記あるルータ装置へ転送される複数のパケットフローの各々を流れるパケットのパケット長が予め定められた一定の関係になるように、該複数のパケットフローの一部または全部についてパケット長を変えるための処理をＲＴＰレイヤレベルで行い、このＲＴＰレイヤレベルの処理が行われたパケットフローについては、前記アグリゲートフローとしてのトラヒック特性を規定すると判断することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフローに収容される各々のパケットフローにおけるパケットの転送速度を加算したものを該アグリゲートフローにおけるパケット転送速度として規定した場合に、前回、該アグリゲートフローへパケットを流入した時刻から今回、新たなパケットが自装置へ到着した時刻までの経過時間が、該アグリゲートフローにおけるパケット転送速度の逆数を下回らない範囲内で、パケットの該アグリゲートフローへの流入を許可することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、ＩＰの上位レイヤの制御プロトコルであるＲＴＣＰ（リアルタイム転送制御プロトコル）で交換される情報に基づいて、前記アグリゲートフロー用のパスに割り当てる帯域を変更するための制御をＩＰレイヤレベルで行うことを特徴とする。
【００３０】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００３１】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００３２】
本発明によれば、同一なルーチング処理を施すこととなる複数のパケットフローに対しては、これらのパケットフローを束ねたアグリゲートフローを生成し、本アグリゲートフローに対するルーチング処理、帯域割当制御を行うことができる。これにより、ルーチング処理や帯域割当制御を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量が削減でき、これらの情報を検索するのに要する時間の削減が可能となる。また、端末の移動に伴うフロー再設定の範囲も可能な限り狭めることが可能となり、フロー再設定に要する時間の減少が期待できる。
【００３３】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３４】
図１は、本発明の適用対象となる通信網システムの一例である。
【００３５】
図１では、端末２１はルータ１３と、端末２２はルータ１４と、端末２３はルータ１６と、端末２４はルータ１８と、無線回線を介して各々接続されている。また、ルータ１３、ルータ１４、ルータ１５はルータ１１と、ルータ１６、ルータ１７、ルータ１８はルータ１２と、有線回線を介して各々接続されている。さらに、ルータ１１とルータ１２は、直接接続されているか、もしくは一つ以上のルータを介して接続されている。
【００３６】
なお、図１において有線回線にて接続されている部分の全部または一部を無線回線に置き換えて接続した通信網システムや、無線回線にて接続されている部分の全部または一部を有線回線に置き換えて接続した通信網システムも、本発明の適用対象としてもよい。
【００３７】
図１に示した通信網システムにおいて、ＩＰ（インターネットプロトコル）による通信を提供する場合の帯域割当方法について説明する。
【００３８】
なお、以下では、端末２１と端末２３、端末２２と端末２４とが各々通信を行うものとし、端末２１と端末２２が送信側端末、端末２３と端末２４が受信側端末であるものとする。また、端末２１より端末２３宛へのパケットフローをフローａ、端末２２より端末２４宛へのパケットフローをフローｂとし、フローａは、（端末２１）→ルータ１３→ルータ１１→…→ルータ１２→ルータ１６→（端末２３）のルートを通るものとし、フローｂは、（端末２２）→ルータ１４→ルータ１１→…→ルータ１２→ルータ１８→（端末２３）のルートを通るものとする。
【００３９】
図１に示した通信網システムにおける、フローａ、フローｂに対する帯域割当の方法としては、従来の方法である図２７のような、フローａ、フローｂの個々に対して帯域を別々に割り当てる方法の他に、ルータ１１とルータ１２との間では、フローａとフローｂが共に同一ルートを通っている点に着目した、図２に示すような帯域割当方法を考えることができる。
【００４０】
図２においては、フローａに対する帯域割当を、端末２１よりルータ１３を介してルータ１１宛のルート（パス３１）、ルータ１１よりルータ１２宛のルート（パス３５）、ルータ１２よりルータ１６を介して端末２３宛のルート（パス３２）の３つに分割して行う。また、フローｂに対する帯域割当を、端末２２よりルータ１４を介したルータ１１宛のルート（パス３３）、ルータ１１よりルータ１２宛のルート（パス３５）、ルータ１２よりルータ１８を介した端末２４宛のルート（パス３４）の３つに分割して行う。
【００４１】
図２において、パス３５はフローａ、フローｂの両フローを収容している。その際に、パス３５の入側ルータ１１において両フローを束ねて、パス３５内においては、フローａ、フローｂの区別なく、同一のフローとして認識できるようにする。以下、この動作を「フローのアグリゲート」と呼び、一定の区間内（パス３５内）において定義される複数のフローを束ねて生成したフローを「アグリゲートフロー」と呼ぶ。図３に、パス３５内におけるフローａ、フローｂのアグリゲートの様子を示す。
【００４２】
図３に示すように、同一ルートを通過する複数のフローをアグリゲートすれば、パス３５上に存在するルータでは、到着したパケットがフローａ、フローｂのいずれのフローに属しているかを判断する必要がなく、一つのアグリゲートフローとして、到着パケットのルーチング処理、割当帯域に対する品質保証制御を行えばよい。アグリゲートフローを用いたＩＰパケット処理を行うことで、従来のように個々のフロー毎にルーチング処理や品質保証制御を行う方法に比べて、各々のルータにおいて識別すべきフロー数の減少がもたらされ、これは、転送先となる出力ポートや割当帯域といった、各々のルータにおいてフロー毎に記憶すべき情報量の減少につながる。これにより、各々のルータにおいて、前記情報を保持するために必要となるメモリ量の削減、ＩＰパケットのフローに対応する前記情報の検索に要する時間の削減が可能となる。これらの効果は、アグリゲートフローとして束ねるフロー数が増大すると、さらに大きくなる。以上の点において、図３に示す方法は、図２７に示したフローａ、フローｂの各々に別個のパスを提供し、帯域割当を行う従来の方法に比べ、効果的であることが分かる。
【００４３】
アグリゲートフローを用いた通信を実現する際には、アグリゲートフローの始点であるルータ１１では、複数のフロー（本具体例では、フローａとフローｂ）を束ねて新たなアグリゲートフローを生成するための機能（フロー統合機能）、そしてアグリゲートフローの終点であるルータ１２では、アグリゲートフローを分離し、アグリゲートフローへの挿入前の各々のフローを再び形成するための機能（フロー分離機能）が必要となる。
【００４４】
パス３５内にてアグリゲートフローを定義する方法としては、例えば次の２つの方法を挙げることができる。
【００４５】
（１）パケットのカプセル化による方法
図４に示すように、アグリゲートフローの始点であるルータ１１において、アグリゲートフロー内に挿入するＩＰパケットの先頭に、アグリゲートフローを識別するためのＩＰパケットヘッダを付与し、パス３５内のみにて定義される、アグリゲートフロー用の新たなＩＰパケットを生成する。パス３５内のルータは、新たに付与されたＩＰパケットヘッダに基づきルーチング処理を行う。つまり、本来のフローのヘッダ（フローａに属するＩＰパケットのヘッダ、フローｂに属するＩＰパケットのヘッダ）は、パス３５内ではペイロードの一部として位置付けられ、ルーチング処理の際には参照されない。付与されたＩＰパケットヘッダは、アグリゲートフローの終点であるルータ１２において除去され、以後では、本来のフローのヘッダを参照したルーチング処理が行われる。
【００４６】
本方法を用いることで、アグリゲートフロー内では、収容された各々のフローを意識しないルーチング処理が可能となる。
【００４７】
（２）フロー識別子（フローラベル）の変換による方法
本方法では、アグリゲートフロー内にＩＰパケットを挿入する際に、当該パケットがアグリゲートフローに属することを示すよう、アグリゲートフローの始点であるルータ１１にて、ＩＰパケット内に記されている、当該パケットが属するフローを表すフロー識別子を、当該パケットがアグリゲートフロー内に属する旨を表すフロー識別子に変換する。そして、アグリゲートフローの終点であるルータ１２にて、変換したフロー識別子を本来のものに戻す。
【００４８】
図５に、ＩＰパケットフォーマットとしてＩＰｖ６（ＩＰバージョン６）を採用した場合の、フロー識別子の変換例を示す。ＩＰｖ６では、ヘッダ内にフローラベルと呼ばれる、フローを識別するために送信側端末が記載する２８ビット長のフィールドが定義される。そこで、図５では、フローラベルとソースアドレス（１２８ビット長）との組をフロー識別子として扱った場合の変換例を示している。
【００４９】
アグリゲートフローの始点であるルータ１１では、到着したＩＰパケットが、アグリゲートフローに挿入すべきものか否かを、当該パケットのフローラベルとソースアドレスとを調べることにより判断する。その際に、ルータ１１はフローラベル変換表を用いる。本表は、アグリゲートフロー内に挿入すべきＩＰパケットの、フローラベルとソースアドレスの組（フロー識別子）と、アグリゲートフローへの挿入時に置き換えられるフローラベルとを対応づけて構成される。なお、図５においては、フローラベルを１６進数表記しており、ソースアドレスは、送信端末の番号（便宜上、図１〜図３の端末に付した参照符号と同じ値であるとした）をそのままアドレスとして用いている。端末として移動端末をサポートする場合には、本表に記載するソースアドレスは、移動端末に割り当てられたホームアドレスを記載することが望ましい。
【００５０】
図５の例では、ソースアドレス「２１」より送信された、フローラベルが「０１２３４５６」であるＩＰパケット（フローａに属するＩＰパケット）については、フローラベルを「０００１０１２」と変換してからアグリゲートフロー内に挿入し、ソースアドレス「２２」より送信された、フローラベルが「１２３４５６７」であるパケット（フローｂに属するＩＰパケット）については、フローラベルを「０００２０１２」と変換してアグリゲートフロー内に挿入している。
【００５１】
パス３５内のルータでは、到着したＩＰパケットのフローラベルを参照して、当該パケットがアグリゲートフローに収容されているパケットであるか否かを判断する。ＩＰパケットがアグリゲートフローに属する旨を示すフローラベルを保持していれば、パス３５内のルータは、アグリゲートフローとしてのルーチング処理を施し、アグリゲートフローに属する旨を示すフローラベルを保持していなければ、通常通りのルーチング処理を施す。フローラベルに基づくルーチング処理の切替を行うため、パス３５内のルータは、アグリゲートフローを表すフローラベルを全て記憶する必要がある。
【００５２】
アグリゲートフローの終点であるルータ１２では、到着したＩＰパケットが、アグリゲートフローに属するものであれば、当該パケットのフローラベルとソースアドレスとに基づき、フローラベル変換表を用いて、フローラベルを当初のフローラベル値に戻す。出側ルータにて保持するフローラベル変換表は、アグリゲートフローラベルとソースアドレスの組と、当初のフローラベルとを対応づけて構成される。
【００５３】
なお、パス３５内のルータにて、到着したＩＰパケットがアグリゲートフローに属するパケットであるか否かの判断を容易に行えるようにするため、例えば、２８ビットからなるフローラベルの指定したフィールドの値を、アグリゲートフローに属するＩＰパケットに対しては同一値となるように、フローラベルの変換を行う。これにより、到着したＩＰパケットのフローラベルのうち当該フィールドの値のみを調べれば、本パケットがアグリゲートフローに属するかを判断することが可能となる。図５の例では、アグリゲートフローに挿入するＩＰパケットに対して、下位１２ビットの値が「０１２」という値をとるようにフローラベルを割り当てており、本例の場合、パス３５内のルータでは、フローラベル内の下位１２ビットを参照するだけで、アグリゲートフローとしてのルーチング処理を行うか否かを判断できる。
【００５４】
上に示したパケットのカプセル化によりアグリゲートフローを定義する方法、フロー識別子（フローラベル）の変換によりアグリゲートフローを定義する方法の他にも、種々の方法が考えられ、例えば、ＭＰＬＳ（マルチプロトコルラベルスイッチング）を実行可能なルータにて構成された通信網システムである場合には、「ラベル」値を利用してアグリゲートフローを定義する方法を用いてもよい。
【００５５】
なお、複数のアグリゲートフローを設定する場合には、各ＩＰパケットがどのアグリゲートフローに属するものかを特定することが必要となる。この場合、例えば、図４の例においては、もとのＩＰパケットの外側に新たにアグリゲート用のヘッダを付与したが、このアグリゲート用のヘッダ内にある何らかの情報から、アグリゲートフローを特定可能とすればよい。また、例えば、図５の例では、アグリゲートフローに挿入するＩＰパケットに対して、下位１２ビットの値が「０１２」という値をとるようにフローラベルを割り当たが、アグリゲートフローに挿入するＩＰパケットに対して割り当てる下位１２ビットの値の範囲を定め、その値の違いによりアグリゲートフローを特定可能とすればよい。
【００５６】
ところで、アグリゲートフローに挿入可能なＩＰパケットフローは、例えば、プレミアムサービスを要求する音声データをＩＰパケット化したフローに限定するようにしてもよい。また、その際に、その音声データは、ＩＰの上位レイヤの転送プロトコルであるＲＴＰ（リアルタイム転送プロトコル）により生成されたパケット（ＲＴＰパケット）をＩＰパケット化して転送されるものとしてもよい。
【００５７】
以下、このようにした場合について説明する。
【００５８】
図６に、送信側端末の上位レイヤにＲＴＰパケットを搭載した場合の、ＩＰパケットの生成過程の概略を示す。ＲＴＰでは、一定時間Ｔ毎に、当該時間内に生成されたアプリケーションデータを抽出してＲＴＰパケットを生成する。このとき、データが挿入されなかったペイロード領域をパディングすることで、ＲＴＰレベルでは、上記時間Ｔにて定まる固定長ＬのＲＴＰパケットを常に生成することとなる。本ＲＴＰパケットを、ＵＤＰ（ユーザデータグラムプロトコル）レベルの処理を介した後にＩＰレベルに引き渡し、ＩＰパケットの生成を行う。図６より明らかなように、送信側端末の上位レイヤにＲＴＰパケットを搭載した場合、当該端末より送出されるＩＰパケットは常に固定長のパケットとなる。
【００５９】
なお、ＲＴＰ、ＵＤＰを介した後に生成されたＩＰパケット（ＩＰ／ＵＤＰ／ＲＴＰパケット）のオーバーヘッドである、各々のプロトコルレベルにて規定されるヘッダ部分を圧縮させた後に、通信網上へ送出するという方法を用いてもよい。具体的には、コンテキスト識別子（ＣＩＤ）と圧縮前のパケットのヘッダ内容とを対応させて覚えておき、同一のヘッダ内容を持つパケットを引続き送信する時には、当該パケット内のＵＤＰヘッダ部、ＲＴＰヘッダ部を圧縮すると同時に前記ＣＩＤをパケット内に含ませてから送信し、相手先にて、ＣＩＤを用いてヘッダ部の復元を行う。
【００６０】
アグリゲートフローに収容されるＩＰパケットフローが全て、図６に示すように一定時間Ｔ毎に生成されるＲＴＰパケットをＩＰパケット化したものであれば、当該アグリゲートフローに収容されるＩＰパケットは全て同一パケット長であり、かつ、各々のＩＰパケットフローにおいては、一定速度にてパケット転送が行われるため、アグリゲートフローのトラヒック特性は、各々のＩＰパケットにおけるパケット転送速度の総和を用いて容易に表すことができる。
【００６１】
また、アグリゲートフローに収容されるＩＰパケットのパケット長が全てのフローにおいて同一であれば、例えばアグリゲートフローが通過するルータにおいて、品質保証制御を目的として当該アグリゲートフローのＩＰパケット転送速度の監視を行う場合、前記ルータではＩＰパケットの到着時刻のみを把握するだけでよく、パケット長に関する情報は（全て同一であるので）把握する必要がないため、ルータにおけるＩＰパケット処理のさらなる低減が可能となる。
【００６２】
なお、アグリゲートフローに収容されるＩＰパケットフローが全てＲＴＰパケットをＩＰパケット化したものであっても、ＲＴＰパケットを生成する時間間隔が送信側端末毎に異なった場合には、当該アグリゲートフローに収容されるＩＰパケットは全て同一パケット長とはならない。つまり、ＩＰパケットフロー毎に、転送されるＩＰパケットのパケット長が異なるということを意味する。このような場合でもアグリゲートフローによるＩＰパケット処理は実行可能であるが、各々のルータにおいては、アグリゲートフローを転送されるＩＰパケットのパケット長を考慮したパケット処理を実行する必要がある。
【００６３】
このようなアグリゲートフローに対する帯域割当制御、アグリゲートフローの始点にて実行する、アグリゲートフローへのＩＰパケットの受付制御の一例を、以下に示す。
【００６４】
（１）帯域割当制御
帯域割当用プロトコルとして、ＲＳＶＰ（リソース予約プロトコル）を用いた場合を例にとり、説明する。
【００６５】
図７に、ＲＳＶＰにて定義されるＰａｔｈメッセージ（Ｐａｔｈ ｍｓｇ．）、Ｒｅｓｖメッセージ（Ｒｅｓｖ ｍｓｇ．）の流れの概要を示す。なお、Ｐａｔｈメッセージは、ＩＰパケットフローのトラヒック特性を記載して、送信側端末より受信側端末へ送出し、Ｒｅｓｖメッセージは、ＩＰパケットフローに対する予約要求内容を記載して、受信側端末より送信側端末へ送出する。
【００６６】
図７に示すように、アグリゲートフローの始点であるルータ１１では、当該フローに収容される全てのフローのＰａｔｈメッセージに基づいてアグリゲートＰａｔｈメッセージを生成する。また、アグリゲートフローの終点であるルータ１２では、当該フローに収容される全てのフロー（図７では、Ｆｌｏｗ−ａとＦｌｏｗ−ｂ）のＲｅｓｖメッセージに基づいてアグリゲートＲｅｓｖメッセージを生成する。パス３５内のＲＳＶＰ対応ルータでは、アグリゲートＰａｔｈメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｐａｔｈ ｍｓｇ．）、アグリゲートＲｅｓｖメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｖ ｍｓｇ．）に基づいて、アグリゲートフローに対する帯域割当制御を行う。
【００６７】
なお、アグリゲートフローに収容される個々のフローのＰａｔｈメッセージ、Ｒｅｓｖメッセージも、アグリゲートフロー内に収容するが、これらの制御メッセージは、パス３５内のＲＳＶＰ対応ルータにおいて、ＲＳＶＰ規定の処理が行われないようにする必要がある。つまり、これら個々のフローにおける制御メッセージは、一つのデータパケットと認識されるようにアグリゲートフロー内に収容すべきである。例えば、これらの制御メッセージの先頭に、アグリゲートフローを識別するためのＩＰパケットヘッダを付与して、制御メッセージ内容を隠蔽する方法（図４を参照）、または、フローラベルの変換後の値に基づいて、アグリゲートＰａｔｈメッセージと個々のフローのＰａｔｈメッセージの区別、アグリゲートＲｅｓｖメッセージと個々のフローのＲｅｓｖメッセージの区別を行う方法（図５を参照）などにより、実現可能である。
【００６８】
このとき、上位レイヤにＲＴＰを用いて生成されたＩＰパケットフローのみをアグリゲートする場合、各々のフロー内にて生成されるＰａｔｈメッセージ内に記載されるトラヒック特性は、図６にて示したＲＴＰパケットの生成間隔Ｔにより決定されるＩＰパケットの転送速度のみで規定可能であるため、アグリゲートＰａｔｈメッセージ内に記載されるトラヒック特性は、各々のＰａｔｈメッセージ内に記載されているパケット転送速度の総和にて定義することが可能である。図８の例では、フローａ、フローｂが各々５Ｍｂｐｓの速度にて送信されるトラヒックフローをアグリゲートするので、アグリゲートフローのパケット転送速度は、１０Ｍｂｐｓと容易に規定することができる（図８（ａ））。Ｒｅｓｖメッセージのアグリゲートも同様に、要求帯域の総和をアグリゲートフローに対して予約すればよい（図８（ｂ））。
【００６９】
アグリゲートフローに割り当てる帯域を、生成したアグリゲートＲｅｓｖメッセージ内の要求帯域に等しく割り当てる方法の他に、収容される個々のフローが要求する要求帯域に関わらず、予め通信網システム（アグリゲートフローの終端点となるルータ）において取り決めておいた帯域を割り当てる方法を用いてもよい。この場合は、上述したように、アグリゲートＰａｔｈメッセージ、アグリゲートＲｅｓｖメッセージを用いた、動的な帯域割当を実行する必要はない。また、新たなフローをアグリゲートフローとして収容することで、必要となる帯域が予め割り当てられた帯域を上回る場合には、このフローの収容を拒絶するためフロー受付制御を搭載する必要がある。
【００７０】
（２）ＩＰパケット受付制御
上述したように、上位レイヤにＲＴＰを用いて生成されたＩＰパケットフローのみをアグリゲートしたアグリゲートフローのトラヒック特性は、当該アグリゲートフローに収容される各々のフローのパケット転送速度の総和にて規定可能である。そのため、パス３５の入口にて実行する、アグリゲートフローへのＩＰパケット受付制御も、到着パケットのパケット転送速度を監視して、当該転送速度が本アグリゲートフローにおけるパケット転送速度の総和を上回らない場合に限り、到着パケットをアグリゲートフロー内に収容すればよい。
【００７１】
さて、次に、本実施形態に係るルータの構成について説明する。
【００７２】
図９に、アグリゲートフローの端点となり得るルータ（図１の例では、ルータ１１、ルータ１２）の構成例を示す。
【００７３】
図９において、４１はスイッチ部、４２はプロトコル処理部、４３はパケットヘッダ処理部、４４はルーチング処理部、４５はポート対応部、４５１はパケット受付制御部である。図９においては、４入力４出力の場合を例にとり示しており、パケット出力ポート毎にパケット受付制御部４５１が設置される。
【００７４】
ポート対応部４５は、各入出力ポート毎に設けられ、入力ポートからパケットを入力する処理と出力ポートからパケットを送出させる処理を行う。
【００７５】
スイッチ部４１は、任意のパケット入力ポートより到着したＩＰパケットを、ルーチング処理部４４により選択されたパケット出力ポートへ出力させるための動作を行う。本スイッチ部４１は、例えばイーサネットスイッチ、ファイバチャネルスイッチ、ＡＴＭスイッチ、などにて構成可能である。
【００７６】
プロトコル処理部４２では、スイッチ部４１に到着したＩＰパケットが、任意のプロトコルにて規定された制御メッセージであるか否かを判断し、制御メッセージであれば、当該メッセージに基づく処理を行う。例えば、到着パケットが、ＲＳＶＰにて規定されているＰａｔｈメッセージであれば、Ｐａｔｈメッセージ内のトラヒック特性を記憶して、パケット受付制御部４５１へ本特性を通知する。また、到着パケットが、ＲＳＶＰにて規定されているＲｅｓｖメッセージであれば、Ｒｅｓｖメッセージ内の資源予約要求が受付可能であるか否かを判断し、受付可能であれば、相当するフローに対する資源の確保を指示する。
【００７７】
そして、プロトコル処理部４２では、アグリゲートフローの新規設定や解放に伴う処理を行う。
【００７８】
また、プロトコル処理部４２では、スイッチ部４１に到着したＩＰパケットをアグリゲートフロー内に挿入すべきパケットであるか否かを判断し、アグリゲートフロー内に挿入すべきパケットであれば、パケットヘッダ処理部４３へ、パケットヘッダの操作を指示する。
【００７９】
さらに、プロトコル処理部４２では、アグリゲートＰａｔｈメッセージ、アグリゲートＲｅｓｖメッセージの生成／終端も行う。
【００８０】
パケットヘッダ処理部４３では、スイッチ部４１に到着したＩＰパケットがアグリゲートフロー内に挿入されるパケットである場合に、図４にて示したパケットのカプセル化、もしくは図５に示したパケットヘッダ内のフローラベルの変換といった処理を行う。
【００８１】
ルーチング処理部４４では、パケットヘッダ処理部４３にて処理されたＩＰパケットのフローラベル、もしくは、アグリゲートフロー内に収容されない、スイッチ部４１に到着したＩＰパケットのデスティネーションアドレス（必要に応じて、ソースアドレス、フローラベルも参照）を参照して、当該パケットの出力先ポートを決定し、本ポートへ当該パケットをルーチングするよう、スイッチ部４１に指示する。
【００８２】
パケット受付制御部４５１は、アグリゲートフローへ収容するＩＰパケットの受付制御、もしくは、アグリゲートフローに限定しない任意のフローに対するＩＰパケットの受付制御を行う。なお、パケット受付制御部４５１は、図９に示すように各ポート毎に設置する代わりに、ルーチング処理部４４内に設置して、ＩＰパケットのルーチングを決定すると同時に、当該パケットの受付の可否を判断するというように構成してもよい。
【００８３】
次に、図１０に、アグリゲートフローの生成手順の一例を示す。
【００８４】
図１０では、パケットフローａがサービス中であるところへ、パケットフローｂが新たにサービスを開始する場合を例にとり、説明する。
【００８５】
フローｂ上にＰａｔｈメッセージが到着すると、ルータ１１のプロトコル処理部４２では、フローｂとアグリゲートが可能なフローが、本Ｐａｔｈメッセージの出側ポートと同一のポートより送出されるフローの中に存在するかを判断する（図１０（ａ））。例えば、両フローともＲＴＰを介して生成されるＩＰパケットであり、固定長のパケットが一定のパケット転送速度にて送出されるような場合には、フローのアグリゲートが可能であると判断する。図１０の例では、フローａとのアグリゲートを試みるものとする。
【００８６】
次に、ルータ１１内のプロトコル処理部４２は、アグリゲートフローの終端ノードとなり得るルータの検索を行うためのメッセージ（終端ノード検索メッセージ）を生成し、フローｂのＰａｔｈメッセージの宛先アドレス宛に送信する（図１０（ｂ））。このとき、終端ノード検索メッセージ内には、アグリゲートの相手がフローａである旨を記載しておく。
【００８７】
終端ノード検索メッセージを受信するルータでは、当該メッセージ内の宛先アドレスより決定される出側ポートと、当該メッセージ内に記載されているフローａの出側ポートが同一であるかを比較し、同一の出側ポートを用いていれば、引続き当該メッセージを次段ルータ宛に送信する。
【００８８】
終端ノード検索メッセージ内の宛先アドレスより決定される出側ポートと、当該メッセージ内に記載されているフローａの出側ポートが異なるルータ（ルータ１２）に到着すれば、本ルータ内のプロトコル処理部４２では、自ルータがアグリゲートフローの終端ルータとなることを記憶して、それに伴うＩＰパケットのヘッダ処理（アグリゲートフロー用に修正されたＩＰヘッダを、当初のＩＰヘッダへ戻すための処理）を行うよう、パケットヘッダ処理部４３へ指示する。そして、ルータ１２は、終端ノード検索メッセージが終端ルータに到達した旨を、当該メッセージを生成したルータ１１に通知する（図１０（ｃ））。
【００８９】
ルータ１１にて、終端ノード検索メッセージが終端ルータに到達した旨を認識すれば、本ルータ内のプロトコル処理部４２では、自ルータがアグリゲートフローの開始ルータとなることを記憶して、それら伴うＩＰパケットのヘッダ処理（アグリゲートフロー用にＩＰヘッダを修正するための処理）を行うよう、パケットヘッダ処理部４３へ指示する（図１０（ｄ））。
【００９０】
次に、図１１に、新規フローのアグリゲートフローへの挿入手順の一例を示す。
【００９１】
図１１では、パケットフローａとパケットフローｂとを収容するアグリゲートフローが存在するところへ、パケットフローｃが新たにサービスを開始する場合を例にとり、説明する。
【００９２】
フローｃ上にＰａｔｈメッセージが到着すると、ルータ１１のプロトコル処理部４２では、フローｃが、フローｃの出側ポートを始点としている既存のアグリゲートフロー内に挿入することが可能であるか否か（アグリゲートフローとのアグリゲートが可能であるか否か）を判断する（図１１（ａ））。
【００９３】
フローｃを、アグリゲートフロー内に挿入可能であると判断すれば、ルータ１１内のプロトコル処理部４２は、アグリゲートフローの終端ノードであるルータ１２に対して、当該アグリゲートフロー内にフローｃを挿入する旨を伝えるメッセージを送信する（図１１（ｂ））。
【００９４】
当該メッセージを受信した、アグリゲートフローの終端ノードであるルータ１２は、フローｃ内のパケットもアグリゲートフローを介して受信される旨を記憶して、それに伴うＩＰパケットのヘッダ処理を行うよう、パケットヘッダ処理部４３へ指示する。そして、当該メッセージが到達した旨を、ルータ１１に通知する（図１１（ｃ））。
【００９５】
ルータ１１にて、当該メッセージが終端ルータに到達した旨を認識すれば、フローｃ内のパケットもアグリゲートフローに挿入するよう、パケットヘッダ処理部４３へ指示する（図１１（ｄ））。
【００９６】
さて、次に、端末の移動に対応可能な通信網システムを提供する際に必要となる機能について、説明する。
【００９７】
図１２には、端末２２の移動に伴い、端末２２の接続先であるルータが、ルータ１４よりルータ１５へ変更となった場合の通信網システム内のフローがとるルートの変更の様子を示す。
【００９８】
端末２２の移動に伴い、フローｂに対しては、端末２４迄の通信を行うための新たなルートが設定される。図１２の例では、フローｂの新たなルートが、（端末２２）→ルータ１５→ルータ１１→…→ルータ１２→ルータ１８→（端末２４）になったものとする。
【００９９】
フローｂが上記ルートを通る場合、フローｂはルータ１１を通過するため、アグリゲートフローの始点であるルータ１１では、端末２２の移動前にフローｂを収容していたアグリゲートフロー内に、フローｂ上を転送するＩＰパケットを引続き収容することが可能である。これは、ルータ１１内のパケットヘッダ処理部４３では、到着したＩＰパケットの入側ポートに関係なく、ＩＰパケット内のフローラベルとソースアドレス（端末２２に固有に割り当てられたアドレス）との組により、到着パケットがフローｂに属することを判断するからである。つまり図１２の例では、端末２２の移動に伴う手続きとしては、パス３３を解放する手続きと、新たにパス３６を設定してパス３６上に必要帯域を確保する手続きとを行うのみでよく、ルータ１１より端末２４までのパス３５，３４に対しては、如何なる変更も施す必要がない。
【０１００】
図１３には、端末２２の移動に伴い、端末２２の接続先であるルータが、ルータ１４よりルータ１９へ変更となった場合の通信網システム内のフローがとるルートの変更の様子を示す。
【０１０１】
図１３の例では、端末２２の移動に伴うフローｂの新たなルートは、（端末２２）→ルータ１９→…ルータ１８→（端末２４）になったものとする。
【０１０２】
フローｂが上記ルートを通る場合、フローｂは、端末２２の移動前のルート上にあるルータ１１を通過せずに宛先である端末２４へ到達する。つまり、移動後のフローｂはルータ１１とルータ１２との間に存在するアグリゲートフローを使用しないこととなる。よって、端末２２と端末２４との間には、新たにパス４３が設定される。なお、ルータ１９とルータ１８との間に、フローｂとのアグリゲートが可能なフローが存在する場合には、図１０にて示した手順に従い、新たにアグリゲートフローを生成することが可能である。また、ルータ１９とルータ１８との間に、フローｂを挿入することが可能な既存のアグリゲートフローが存在する場合には、図１１にて示した手順に従い、既存のアグリゲートフロー内にフローｂを挿入することが可能である。
【０１０３】
なお、端末２２の移動前にフローｂを収容していた、ルータ１１とルータ１２との間のアグリゲートフローは、現在フローａのみを収容しているため、アグリゲートフローを解放して、端末２１と端末２３との間にパス４１を新たに設定する場合もある。
【０１０４】
以上のように本実施形態によれば、同一なルーチング処理を施すこととなる複数のＩＰパケットフローに対しては、これらのＩＰパケットフローを束ねたアグリゲートフローを生成し、本アグリゲートフローに対するルーチング処理、帯域割当制御を行うことができる。これにより、ルーチング処理や帯域割当制御を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量が削減でき、これらの情報を検索するのに要する時間の削減が可能となる。また、端末の移動に伴うフロー再設定の範囲も可能な限り狭めることが可能となり、フロー再設定に要する時間の減少が期待できる。
【０１０５】
次に、本発明を他の通信網システムに適用する場合の例について説明する。
【０１０６】
図１４は、本発明の適用対象となる通信網システムの図１とは異なる一例である。
【０１０７】
図１４では、通信網を、プレミアムサービス用ネットワーク５１と通常サービス用ネットワーク５２との二種類に、論理的もしくは物理的に分割している。なお、プレミアムサービス用ネットワーク５１は、サービスクラス毎のＩＰパケット処理ポリシーの規定が可能な（ＣｏＳ（サービスクラス）サポートのある）ルータにより構成されるネットワークである。なお、図１４において、プレミアムサービス用ネットワーク５１を構成するルータ装置は省略してある（プレミアムサービス用のパスの出入口に位置するルータ装置は、例えば図９のような構成とする）。
【０１０８】
なお、図１４において有線回線にて接続されている部分の全部または一部を無線回線に置き換えて接続した通信網システムにも本発明は適用可能である。
【０１０９】
プレミアムサービス用ネットワークでは、通常サービス用ネットワークからの指示により、通常サービス用ネットワーク内の任意のルータ間での、プレミアムサービスを要求するＩＰパケットの配送を目的としたパスの設定、そして、既に設定されているパスの解放が行われる。図１４の例では、ルータ５４１とルータ５４２との間にて、プレミアムサービスを要求するＩＰパケットの配送のためにパス５３１が、ルータ５４１とルータ５４３との間にて、プレミアムサービスを要求するＩＰパケットの配送のためにパス５３２が、ルータ５４２とルータ５４３との間にて、プレミアムサービスを要求するＩＰパケットの配送のためにパス５３３が、各々設定されている。なお、プレミアムサービスを要求しないＩＰパケットを配送する際には、プレミアムサービス用ネットワークを用いず、通常サービス用ネットワークのみを用いる。
【０１１０】
図１４において、端末５６１より端末５６２宛へのプレミアムサービスでの通信要求が生じた場合を例にとり、プレミアムサービスの通信が開始されるまでを説明する。
【０１１１】
端末５６１を収容する基地局５５１と接続するルータ５４１では、端末５６１より生じたプレミアムサービスでの通信要求を受信すると、当該通信の相手端末である、端末５６２迄の通信ルートの設定を、プレミアムサービス用ネットワーク５１を介して行う。図１４の例では、ルータ５４１にて、通信の相手端末５６２が基地局５５２に収容されていることを認識すれば、ルータ５４１は、基地局５５２と接続するルータ５４２宛へ設定されている、プレミアムサービス用ネットワーク内のパス５３１を用いて通信を行えば良いことが分かる。そこで、ルータ５４１は、当該プレミアムサービスを要求するＩＰパケットをパス５３１内に挿入するようルートを設定する。また、パス５３１の出口に位置するルータ５４２では、パス５３１より到着する当該プレミアムサービスを要求するＩＰパケットを、基地局５５２を介して端末５６２へ送信するよう、ルートを設定する。
【０１１２】
ところで、プレミアムサービスを提供すべき新規ＩＰパケットフローが挿入されることを認識したパス５３１では、収容ＩＰパケットフロー情報の更新を行う。収容ＩＰパケットフロー情報は、例えば図１５のように、ＩＰパケットフローの識別子と当該フローのトラヒック特性とを対応づけて、パスの入口（パス５３１の場合だと、例えばタール５４１）にて保持されるものである。
【０１１３】
そして、現在パスに収容しているＩＰパケットフローを統計多重することにより得られる、アグリゲートフローのトラヒック特性を、当該パス内に収容するＩＰパケットフローが増加、もしくは減少する度に算出し、本アグリゲートフローを収容するのに十分な帯域を、当該パスに割り当てる。図１５の例では、各ＩＰパケットフローが、一定の速度に従いパケット転送を行い、本フローのトラヒック特性がパケット転送速度値のみを用いて表すことのできる例を用いているため、アグリゲートフローのトラヒック特性は、これらのパケット転送速度値の総和にて表すことができる。
【０１１４】
なお、プレミアムサービス用ネットワーク内での帯域割当制御を、ＲＳＶＰを用いて行う方法をとってもよい。この場合、図１６のように、パスの送信側端点に位置するルータにて、図１５にて記載されているアグリゲートフローのトラヒック特性を記載したＰａｔｈメッセージを周期的に生成して送信し、また、パスの受信側端点に位置するルータにて、プレミアムサービスとして必要なサービス品質を記載したＲｅｓｖメッセージを周期的に生成して送信する。これに基づき、プレミアムサービス用ネットワーク内の各ルータでは、受信するＰａｔｈメッセージ、Ｒｅｓｖメッセージに基づいて、各々のパスに対する帯域割当を実行する。
【０１１５】
さらに、プレミアムサービス用ネットワーク内のパスは、当該パスに収容されるフローの有無に関わらず、常に固定的に設定しておく方法を用いてもよい。このとき、当該パスに割り当てる帯域は、予めプレミアムサービス用ネットワークにおいて取り決めておいた帯域を固定的に割り当てておく。
【０１１６】
プレミアムサービス用ネットワーク内に設定されたパスの入口では、ＩＰパケット受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケット受付制御部４５１に相当）を設けて、予め定められたアグリゲートフローのトラヒック特性に合致しないＩＰパケットの、プレミアムサービス用ネットワーク内への流入を防ぐというトラヒック制御を実行するようにしてもよい。
【０１１７】
次に、本発明をさらに他の通信網システムに適用する場合の例について説明する。
【０１１８】
図１７は、本発明の適用対象となる通信網システムの図１および図１４とは異なる一例である。
【０１１９】
図１７では、通信網を、基地局６５１〜６５６を収容する小規模なネットワーク６２〜６４と、ネットワーク６２〜６４を収容する大規模なネットワーク６１との二種類に、論理的もしくは物理的に分割している。なお、ネットワーク６１内には、ネットワーク６２〜６４の任意の二種類のネットワーク間の通信を提供するためのパス６１１〜６１３が固定的に設定されている。なお、図１７において、プレミアムサービス用ネットワーク５１を構成するルータ装置は省略してある（大規模ネットワーク中のパスの出入口に位置するルータ装置は、例えば図９のような構成とする）。
【０１２０】
なお、図１７において有線回線にて接続されている部分の全部または一部を無線回線に置き換えて接続した通信網システムにも本発明は適用可能である。
【０１２１】
ネットワーク６２〜６４では、ＩＰパケットフローに対する帯域予約要求が生じる度に、例えばＲＳＶＰによる帯域予約が、ＩＰパケットフロー毎になされる。また、ネットワーク６１では、ネットワーク６２〜６４の異なるネットワーク間にて生じる通信に対する帯域予約を、パケットのカプセル化やフロー識別子（フローラベル）の変換により生成するアグリゲートフロー毎に、例えばＲＳＶＰを用いてなされる。
【０１２２】
図１７は、端末６６２が基地局６５３に収容されている場合の、端末６６１宛へのＩＰパケットフローに対する帯域予約の例を示したものである。このとき、送信端末６６２を収容する基地局６５３は、受信端末６６１を収容する基地局６５１はネットワーク６２内に存在することを認識し、基地局６５３が存在するネットワーク６３とネットワーク６２とを接続するネットワーク６１内に設定されているパス６１２を用いて通信を行うよう、ルート設定を行う。そして、ネットワーク６３では、基地局６５３とネットワーク６１内のパス６１２の入口とを接続するパス６３１を設定して、本パス６３１に対する帯域予約を行い、ネットワーク６２では、ネットワーク６１内のパス６１２の出口と基地局６５１とを接続するパス６２１を設定して、本パス６２１に対する帯域予約を行う。さらに、ネットワーク６１では、新規フローを新たに束ねたアグリゲートフローを収容するパス６１２において、アグリゲートフロー全体での帯域予約がなされる。なお、先の例と同様に、パス６３１、パス６１２、パス６２１の入口では、ＩＰパケット受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケット受付制御部４５１に相当）を設けて、ＩＰパケットの受付制御を行ってもよい。
【０１２３】
ここで、図１８に示すように、端末６６２の移動により、収容される基地局が基地局６５３より基地局６５６に変更された場合を考える。このとき、端末６６２は、基地局６５６に対して自信が基地局６５６のエリア内に存在することを通知する。本通知を受けた基地局６５６では、端末６５１との間の帯域予約をＲＳＶＰを用いて実行する。
【０１２４】
基地局６５６は、自信が存在するネットワーク６４と、受信端末６６２を収容する基地局６５１が存在するネットワーク６２とを接続する、ネットワーク６１内に設定されているパス６１１を用いて通信を行うよう、ルート設定を行う。そして、ネットワーク６４では、基地局６５６とネットワーク６１内のパス６１１の入口とを接続するパス６４１を設定して、本パス６４１に対する帯域予約を行い、ネットワーク６２では、ネットワーク６１内のパス６１１の出口と基地局６５１とを接続するパス６２２を設定して、本パス６２２に対する帯域予約を行う。さらに、ネットワーク６１では、新規フローを新たに束ねたアグリゲートフローを収容するパス６１１において、アグリゲートフロー全体での帯域予約がなされる。なお、上記と同様に、パス６４１、パス６１１、パス６２２の入口では、ＩＰパケット受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケット受付制御部４５１に相当）を設けて、ＩＰパケットの受付制御を行ってもよい。
【０１２５】
なお、端末６６２が基地局６５３に収容されていた際に設定されたパス６３１、パス６２１に対しては、端末６６２の移動に伴い、Ｐａｔｈメッセージ、Ｒｅｓｖメッセージのパス６３１、パス６２１上の送信がなくなり、一定時間これらのメッセージが受信されなければ、ＲＳＶＰに規定されているタイムアウト機能により、パス６３１、パス６２１に対して確保された帯域は全て解放されることとなる。また、端末６６２より端末６６１宛のＩＰトラヒックフローを収容していたネットワーク６１内のパス６１２においても、当該フローの流入の終了に伴い、当該フローを除いたアグリゲートフローに対する帯域予約が新たに行われる。
【０１２６】
なお、ネットワーク６１内のパス６１１，６１２，６１３が確保する帯域は、収容されているフローの有無に関わらず、固定量を割り当てるという方法を用いてもよい。
【０１２７】
以下では、リアルタイム通信用のプロトコルであるＲＴＰを用いた場合に、ＲＴＰレベルにてパケットのストリームをアグリゲートした場合の制御方法について説明する。なお、ＲＴＰレベルでのアグリゲートの方法は基本的には前述したＩＰレベルでのアグリゲートの方法と同様である（図４、図５参照）。
【０１２８】
図１９に、ＲＴＰレベルでのパケット転送制御の概要を示す。ＲＴＰ自身は、ＱｏＳを保証するためのプロトコルではなく、ＲＴＰパケットにタイムスタンプやシーケンス番号などの付与、そしてＲＴＣＰ（ＲＴＰ制御プロトコル）による送信者と受信者との間の情報交換サービスを提供する。つまり、ＲＴＰとＲＴＣＰを用いることにより、ＲＴＰの上位レイヤ（例えばアプリケーション）は、例えば受信者からの情報よりネットワークの状態が推定できるので、それにより輻輳であると判断すれば、データの送信速度を制限するようなＱｏＳ制御を行うことができる。
【０１２９】
図２０に、ＲＴＰの通信シーケンスを示す。ＲＴＰ通信を開始する際、送信者はＳＤＥＳ（ソース記述アイテム）メッセージを記載したＲＴＣＰパケットを受信者側に送出し、通信で使用するセッション情報等を伝える。ＳＤＥＳメッセージを送出することで、ＲＴＰセッションが確立され、送信者はＲＴＰデータをあるビットレートにて送出する。
【０１３０】
送信者は、ＲＴＰデータを送出した時点から周期的に（例えば一定間隔ΔｔSで）、ＳＲ（送信者報告）メッセージを記載したＲＴＰパケットを送出する。ＳＲメッセージでは、送信者側でのタイムスタンプ値、送信パケット総数とそのオクテット数の総数などの情報メッセージが記載される。
【０１３１】
また、受信者は、ＲＴＰデータを受信した時点から周期的に（例えば一定間隔ΔｔRで）、ＲＲ（受信者報告）メッセージを記載したＲＴＣＰパケットを送出する。ＲＲメッセージでは、パケット損失数、受信者でのシーケンス番号、遅延ジッタ、最後に受信したＳＲメッセージからの遅れなどの情報メッセージが記載される。
【０１３２】
通信終了時には、送信者はＢＹＥメッセージを記載したＲＴＣＰパケットを送出することで、ＲＴＰセッションを開放する。
【０１３３】
送信者と受信者では、上述のようにＳＲメッセージ、ＲＲメッセージを交換し合うことで、帯域にあったビットレートを調整してＲＴＰデータを送出する。
【０１３４】
ＲＴＰでは、「ミキサ」の概念をサポートしている。ミキサは、１つ以上のソースから送信されるＲＴＰパケットのストリーム（以下、ＲＴＰストリームと呼ぶ）を受信し、ＲＴＰパケット内のデータフォーマットを変更したり、ＲＴＰストリームをアグリゲートして新たなストリームを生成し、これを転送するＲＴＰパケットの中継装置である。
【０１３５】
図２１に、ＲＴＰミキサを用いたＲＴＰストリームの生成の一例を示す。図２１では、図１に示した通信網システムにおける例について示したものである。
【０１３６】
図２１では、端末２１より端末２３宛にＲＴＰパケットを送信し、また、端末２２より端末２４宛にＲＴＰパケットを送信する。これらを各々ＲＴＰストリームａ、ＲＴＰストリームｂとする。ＲＴＰミキサ１１（図１におけるルータ１１に相当）では、ＲＴＰストリームａとＲＴＰストリームｂとをアグリゲートし、新たなＲＴＰストリームｃを生成し、ＲＴＰミキサ１２（図１におけるルータ１２に相当）へ送信する。ＲＴＰミキサ１２では、ＲＴＰストリームｃをＲＴＰストリームａとＲＴＰストリームｂとに再び分離し、各々を送信先である端末２３もしくは端末２４へ送信する。なお、以下では、端末２１とＲＴＰミキサ１１間におけるＲＴＰストリームａとＲＴＰミキサ１２と端末２３との間におけるＲＴＰストリームａとを区別するため、ＲＴＰミキサ１２と端末２３との間におけるＲＴＰストリームａについては、ＲＴＰストリームａ’と記載する。同様の理由により、ＲＴＰミキサ１２と端末２４との間におけるＲＴＰストリームｂについては、ＲＴＰストリームｂ’と記載する。
【０１３７】
ＲＴＰストリームの送信者と受信者との間の情報交換を提供するＲＴＣＰパケットが、ＲＴＰストリームの終端ノード間にて行われる。図２１では、ＲＴＰストリームａに対するＲＴＣＰパケットが端末２１とＲＴＰミキサ１１との間で、ＲＴＰストリームｂに対するＲＴＣＰパケットが端末２２とＲＴＰミキサ１１との間で、ＲＴＰストリームｃに対するＲＴＣＰパケットがＲＴＰミキサ１１とＲＴＰミキサ１２との間で、ＲＴＰストリームａ’に対するＲＴＣＰパケットがＲＴＰミキサ１２と端末２３との間で、ＲＴＰストリームｂ’に対するＲＴＣＰパケットがＲＴＰミキサ１２と端末２４との間で各々送受信される。
【０１３８】
図２２は、ＲＴＰストリームａ、ＲＴＰストリームｂ、ＲＴＰストリームａ’が通過する端末、ルータ、ＲＴＰミキサにおけるプロトコルスタックを示す。なお、ＩＰレイヤより下位レイヤにおけるプロトコルスタックについては図示していない。
【０１３９】
図２２に示すように、ルータ１３やルータ１６においては、受信したＩＰパケットをＲＴＰパケットに組み立てることなく、ＩＰパケットのヘッダ情報をもとにルーチング処理を行う。それに対して、ＲＴＰミキサ１１およびＲＴＰミキサ１２においては、受信したＩＰパケットを一旦ＲＴＰパケットに組立てて、ＲＴＰパケットのヘッダ情報をもとにルーチング処理を行う。その際、ＲＴＰミキサ１１では、ＲＴＰストリームａとＲＴＰストリームｂとのアグリゲートを行ってＲＴＰストリームｃを生成し、ＲＴＰミキサ１２では、ＲＴＰストリームｃを分離してＲＴＰストリームａとＲＴＰストリームｂとに再び戻す。
【０１４０】
図２１において、ＲＴＰストリームａとＲＴＰストリームｂとをアグリゲートすることにより生成されたＲＴＰストリームｃに対して実行される輻輳制御方法について以下に示す。
【０１４１】
（ａ）ＲＴＰミキサ１１における、ＲＴＰストリームｃの送信速度の減少
ＲＴＰミキサ１１では、ＲＴＰミキサ１２との間でのＲＴＣＰパケットの交換により、ＲＲメッセージから得られるパケット損失数などの情報に基づき、輻輳の検知が可能となる。
【０１４２】
ＲＴＰミキサ１１では、ＲＴＰストリームａ、ＲＴＰストリームｂより受信したＲＴＰパケットをアグリゲートしてＲＴＰストリームｃとして送出する際に、送信速度を減少させることで、輻輳からの回復を図る。ＲＴＰストリームの送信速度を減少させるための手段としては、
（１）受信したＲＴＰパケットを一旦復号化し、新しいデータ送信速度に合わせて再符号化する方法、
（２）階層符号化等を用いてストリームデータを複数の階層に分けて符号化を行い、新しいデータ送信速度に応じて、復号に必要な階層のデータを含むパケットより送信する方法、
などが挙げられる。
【０１４３】
ところで、（１）に示した方法を実現するためには、ＲＴＰミキサ１１では、ＲＴＰパケットを復号化・再符号化するためのアプリケーションレイヤの処理を実行する必要がある。ＲＴＰミキサでの負荷を考慮すれば、（２）に示した、階層符号化を用いる方法が効率的な制御であると考えられる。
【０１４４】
図２３に示した例では、端末２１と、端末２２（図２３では省略している）は、それぞれ、Ｌ１、Ｌ２、Ｌ３、Ｌ４の４階層に階層符号化されたストリームデータを、ＲＴＰストリームａ、ＲＴＰストリームｂとして送信する。なお、Ｌ１はそのストリームを再生するための最低限の情報量が含まれたデータであり、それ単体でデコードすることが可能である。これに対し、Ｌ２、Ｌ３、Ｌ４は、Ｌ１と合成することで受信品質を改善することが可能なデータであり、Ｌ２、Ｌ３、Ｌ４の順で優先度が低くなる（本例の場合、Ｌ１、Ｌ１とＬ２、Ｌ１〜Ｌ３、Ｌ１〜Ｌ４の４種類がある）。
【０１４５】
図２３では、ＲＴＣＰパケットにより、ＲＴＰストリームｃの転送経路上にて輻輳が発生していることを認識したＲＴＰミキサ１１が、それまでＬ１〜Ｌ４の全てのデータを送信していたところを、Ｌ１とＬ２のデータのみをＲＴＰミキサ１２宛に送信するよう変更している。Ｌ３とＬ４のデータについては、ＲＴＰミキサ１２宛に送信せず、廃棄する。これにより、廃棄されたデータ（上記例では、Ｌ３，Ｌ４）に応じて受信側での品質が劣化するものの、ＲＴＰストリームｃの送信速度が減少され、輻輳の回復が期待される。
【０１４６】
（ｂ）ＲＴＰストリームｃを収容するＩＰアグリゲートフローに対する割り当て帯域量の増加
（ａ）に示したような、ＲＴＰミキサ１２がＲＴＰミキサ１１宛にＲＲメッセージを送信することで、ＲＴＰミキサ１１にＲＴＰストリームｃの送信速度を減少させることで輻輳からの回復を図るという制御の他に、ＩＰレイヤにおいて前記ＲＴＰストリームｃを収容するＩＰアグリゲートフローに割り当てられる帯域を増加することで、輻輳からの回復を図るという制御を、図７に示したアグリゲートＰａｔｈメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｐａｔｈ ｍｓｇ．）、アグリゲートＲｅｓｖメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｖ ｍｓｇ．）を用いて実行する。
【０１４７】
図２４に示した例では、ＲＴＣＰパケットの交換によりＲＴＰストリームｃの転送経路上に輻輳が生じていることをＲＴＰミキサ１２が認識した場合、ＲＴＰミキサ１２は、本ＲＴＰストリームｃを収容するＩＰアグリゲートフローに割り当てる帯域を増加させるよう、ＩＰレイヤにおいて、要求帯域を記載したアグリゲートＲｅｓｖメッセージを生成し、ＲＴＰミキサ１１宛へ送信する。図２４に示していないが、ＲＴＰミキサ１１とＲＴＰミキサ１２との間の全てのルータにおいて、アグリゲートＲｅｓｖメッセージに記載した要求帯域の割り当てが許容されれば、ＩＰアグリゲートフローに対する割当帯域は増加され、その結果、本ＩＰアグリゲートフローに収容されるＲＴＰストリームｃは、輻輳からの回復が可能となる。
【０１４８】
もちろん、上記（ａ）に示したＲＴＣＰパケットの交換（ＲＲメッセージの送出）に基づいたＲＴＰレベルの輻輳制御と、上記（ｂ）に示したＲｅｓｖメッセージに基づいたＩＰレベルの輻輳制御との両者を組み合わせて実行してもよい。
【０１４９】
ところで、ＩＰパケットのパケット長が異なるフロー同士をアグリゲートする場合、ＲＴＰミキサにて、その上位レイヤであるアプリケーションレイヤ処理を併せて実行することで、これらのパケット長が同一となるよう調整することが可能となる。図２５に、この場合の一例を示す。
【０１５０】
ＩＰパケット長は、ＩＰパケットを生成するＲＴＰパケット長、すなわち、アプリケーションレイヤにおける符号化速度と、ＲＴＰレイヤにおけるＲＴＰパケット生成間隔により決定される。図２５において、端末２１にて送信するアプリケーション情報を、符号化速度ｓ１、パケット生成間隔Ｔ１にて生成したＲＴＰパケットをＩＰパケット化した際のＩＰパケット長はｓ１×Ｔ１＋αにて、端末２２にて送信するアプリケーション情報を、符号化速度ｓ２、パケット生成間隔Ｔ２にて生成したＲＴＰパケットをＩＰパケット化した際のＩＰパケット長はｓ２×Ｔ２＋αにて表記できる。なお、αは、ＲＴＰヘッダ長、ＵＤＰヘッダ長、ＩＰヘッダ長の和を示す。
【０１５１】
端末２１にて生成されるＩＰパケットフローと、端末２２にて生成されるＩＰパケットフローとを共に受信するＲＴＰミキサ１１では、受信したＩＰパケットを一旦ＲＴＰパケットに変換し、さらにアプリケーションレイヤにてアプリケーション情報（例えば、アナログ音声信号）への復号化を行う。そして、両方のアプリケーション情報を、同一の符号化速度ｓ、同一のパケット生成間隔ＴにてＲＴＰパケットを生成すれば、それをＩＰパケット化した際のＩＰパケット長が共に、ｓ×Ｔ＋αと同一なものになる。これにより、前述したようにＩＰアグリゲートフローとしてのＩＰパケット処理の負荷が低減される。なお、ｓやＴは、アグリゲートされるいずれかのフローにおけるものと同じ値を用いてもよいし、それらとは異なる別の値を用いてもよい。
【０１５２】
なお、アグリゲートフローの終点であるＲＴＰミキサ１２（図２５では省略している）にて、両パケットフローを分離して各々のフローの送信先端末へ送出するが、その際に、本ＲＴＰミキサにおいて、再びアプリケーション情報への復号化を行い、当初の符号化速度、パケット生成間隔に従ったＲＴＰパケット生成、ＩＰパケット化を行う。
【０１５３】
ところで、図２５の例において、端末２１、端末２２が階層符号化を用いてＲＴＰパケットを生成している場合には、ＲＴＰミキサ１１では、アプリケーションレイヤまで遡った復号化処理等を行う必要がない。その場合のＲＴＰミキサ１１での動作例を図２６に示す。
【０１５４】
ＲＴＰミキサ１１では、受信したＩＰパケットをＲＴＰパケットに変換した後に、端末２１より送出されたＲＴＰパケットａの長さと、端末２２より送出されたＲＴＰパケットｂの長さとが同一となるよう調整する。図２６に示した例では、ＲＴＰミキサ１１にて、パケット長が長いＲＴＰパケットｂのＬ３、Ｌ４のデータを廃棄している。
【０１５５】
両ＲＴＰパケットの長さを同一とするための他の方法として、パケット長が短いＲＴＰパケットａに対してパディングを行い、両ＲＴＰパケットの長さを同一とする方法もある。
【０１５６】
上述したように、ＲＴＰパケット長が同一となれば、本ＲＴＰパケットより生成されるＩＰパケットのパケット長も同一なものとなる。
【０１５７】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１５８】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１５９】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１６０】
【発明の効果】
本発明によれば、同一なルーチング処理を施すこととなる複数のパケットフローに対しては、これらのパケットフローを束ねたアグリゲートフローを生成し、本アグリゲートフローに対するルーチング処理、帯域割当制御を行うことができる。これにより、ルーチング処理や帯域割当制御を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量が削減でき、これらの情報を検索するのに要する時間の削減が可能となる。また、端末の移動に伴うフロー再設定の範囲も可能な限り狭めることが可能となり、フロー再設定に要する時間の減少が期待できる。
【図面の簡単な説明】
【図１】本発明を適用する通信網システムの一例を示す図
【図２】帯域割当方法の一例を説明するための図
【図３】アグリゲートフローについて説明するための図
【図４】アグリゲートフローを定義する方法の一例を示す図
【図５】アグリゲートフローを定義する方法の他の例を示す図
【図６】送信側端末の上位レイヤにＲＴＰパケットを搭載した場合のＩＰパケットの生成過程の概略を示す図
【図７】ＲＳＶＰにて定義されるＰａｔｈメッセージおよびＲｅｓｖメッセージの流れの概要を示す図
【図８】アグリゲートＰａｔｈメッセージ内に記載されるトラヒック特性およびアグリゲートＲｅｓｖメッセージ内に記載される要求帯域を定義する方法の一例を示す図
【図９】アグリゲートフローの端点となり得るルータの構成例を示す図
【図１０】アグリゲートフローの生成手順の一例を説明するための図
【図１１】新規ＩＰパケットフローのアグリゲートフローへの挿入手順の一例を説明するための図
【図１２】端末が移動する場合の通信網システム内のフローのルート変更の一例について説明するための図
【図１３】端末が移動する場合の通信網システム内のフローのルート変更の他の例について説明するための図
【図１４】本発明を適用する通信網システムの他の例を示す図
【図１５】収容ＩＰパケットフロー情報の一例を示す図
【図１６】図１４においてプレミアムサービス用ネットワーク内での帯域割当制御をＲＳＶＰを用いて行う方法の一例について説明するための図
【図１７】本発明を適用する通信網システムのさらに他の例を示す図
【図１８】図１７において端末が移動する場合の通信網システム内のフローのルート変更の一例について説明するための図
【図１９】ＲＴＰレベルでのパケット転送制御の概要を説明するための図
【図２０】ＲＴＰの通信シーケンスを示す図
【図２１】ＲＴＰミキサを用いたＲＴＰストリームの生成の一例を示す図
【図２２】プロトコルスタックの一例を示す図
【図２３】階層符号化を用いてＲＴＰストリームの送信速度を減少させる場合の一例を示す図
【図２４】ＲＴＣＰパケットの交換によりＩＰアグリゲートフローに割り当てる帯域を制御する場合の一例を示す図
【図２５】ＲＴＰミキサにおいてパケット長が異なるＩＰフロー同士をアグリゲートする場合の一例を示す図
【図２６】ＲＴＰミキサにおいてパケット長が異なるＩＰフロー同士をアグリゲートする場合の他の例を示す図
【図２７】従来の帯域割当方法について説明するための図
【符号の説明】
２１〜２４，５６１，５６２，６６１，６６２…端末
１１〜１９，５４１〜５４３…ルータ
５５１〜５５３，６５１〜６５６…基地局
４１…スイッチ部
４２…プロトコル処理部
４３…パケットヘッダ処理部
４４…ルーチング処理部
４５…ポート対応部
４５１…パケット受付制御部（ＰＡＣ部）
５１…プレミアムサービス用ネットワーク
５２…通常サービス用ネットワーク
６１…大規模ネットワーク
６２〜６４…小規模ネットワーク
【発明の属する技術分野】
本発明は、複数のルータ装置を接続することにより構成される通信網におけるパケットフロー制御方法及びルータ装置に関する。
【０００２】
【従来の技術】
近年、ＩＰ（インターネットプロトコル）を用いた通信網、いわゆるインターネットにおいて、転送遅延値やＩＰパケット廃棄率といった、転送品質の保証を可能とするための技術が注目されている。これは、従来のインターネットはベストエフォート型の通信網と呼ばれており、例えば中継ノード（ルータ等）にトラヒックが集中した場合、中継ノードは最善の努力にてＩＰパケットの処理を試みるが、処理しきれなくなれば、ＩＰパケットの廃棄が発生してしまうため、転送品質の保証が不可能であったためである。
【０００３】
インターネットにおいて転送品質の保証が可能な通信を提供するための技術として、ＲＳＶＰと呼ばれる資源予約プロトコルがＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）にて提案されている。ＲＳＶＰでは、送信側端末より受信側端末に対して、送信するＩＰパケットフローのトラヒック特性を記載したメッセージ（Ｐａｔｈメッセージ）を受信側端末宛に送信する。受信側端末では、希望する転送品質を記載したメッセージ（Ｒｅｓｖメッセージ）を送信側端末宛に送信する。中継ノードでは、Ｒｅｓｖメッセージを受信すれば、予め受信したＰａｔｈメッセージに記載されていたトラヒック特性をもとに、Ｒｅｓｖメッセージ内に記載された転送品質の提供が可能か否かを、現在の残余帯域量をもとに判断し、転送品質の提供が可能であれば、必要な帯域を当該フローに対して確保した後に、Ｒｅｓｖメッセージをさらに上流へ転送する。Ｒｅｓｖメッセージが送信側端末に到達すれば、当該フローに対する帯域がインターネット上に確保されたことを意味するので、以降では、希望する転送品質が保証される、ＩＰパケットの転送サービスが可能となる。
【０００４】
上述したような、フロー毎の転送品質の保証を可能とするＩＰパケットの転送サービスを実現するためには、例えば、各々のルータにおいて、ＩＰパケットに対するルーチングポリシーをフロー毎に規定し、当該ルーチングポリシーに従ったルーチング処理を施す必要がある。ルーチングポリシーとして規定すべき内容としては、例えば、フローに属するＩＰパケットの送信先ポート、他のフローとの間でのスケジューリング手段、等が挙げられ、ルーチング表としてルータ内に記憶される。
【０００５】
この場合、処理すべきフロー数が多いルータにおいては、フローに対応して記憶すべきルーチングポリシーも多くなるため、ルーチング表は巨大なものとなってしまい、本表を記憶するために費すメモリ規模が大きくなってしまう。また、ルーチング表が巨大になってしまうと、到着したＩＰパケットのフローに対応するルーチングポリシーの検索に要する時間も大きくなり、その結果、ルータ内でのルーチング処理に要する時間が大きくなってしまう。
【０００６】
ここで、図２７を参照しながら従来の帯域割り当て方法について説明する。
【０００７】
図２７（ａ）に示した通信網システムにおいて、端末１０２１より端末１０２３宛に送信されるＩＰパケットフロー（フローａとする）と、端末１０２２より端末１０２４宛に送信されるＩＰパケットフロー（フローｂとする）とに対し、上述したＲＳＶＰにより帯域が確保された様子を、図２７（ｂ）に示す。図２７（ｂ）において、１０４１がフローａに対して確保された帯域（フローａに対するパスと呼ぶ）、１０４２がフローｂに対して確保された帯域（フローｂに対するパスと呼ぶ）である。なお、フローａ、フローｂ共に、ルータ１０１１とルータ１０１２との間に設定されるパスのルート、希望する転送品質は同一であるものとする。
【０００８】
図２７のような帯域確保（パス設定）を行った場合、フローａ、フローｂ共に、ルータ１０１１を発したＩＰパケットは、同一ルートを通ってルータ１０１２に転送されるので、ルータ１０１１とルータ１０１２との間に位置する各々のルータでは、フローａに属するＩＰパケット、フローｂに属するＩＰパケットに対して施すルーチング処理は、同一なものとなる。しかしながら、実際は、これらのＩＰパケットが属するフローは異なるため、これらのルータにて保持するルーチング表においては、同一なルーチングポリシーであるにも関わらず、別々のエントリとして記載されてしまう。図２７では、同一ルートを通過するフローが２種類ある場合を図示しているが、同一ルートを通過するフロー数がさらに多くなった場合、これによるルーチング表の巨大化によるメモリ規模の増大、ルーチングポリシーの検索に要する時間の増大は無視できないものとなる。
【０００９】
新たな問題として、図２７の端末１０２１の移動に伴い、端末１０２１を収容するルータがルータ１０１３でなくなった状況を考える。この場合、移動前にフローａを収容していたパス１０４１は解放され、フローａを収容する新たなパスを、端末１０２１と端末１０２３との間にて設定することとなる。このようなパスの再設定が行われている間は、端末１０２１より端末１０２３宛に送出されるＩＰパケットの転送は一旦中断してしまい、これによる転送品質の低下は無視できない。
【００１０】
【発明が解決しようとする課題】
従来、フロー毎の転送品質の保証を可能とするＩＰパケットの転送サービスを実現するためには、例えば、各々のルータにおいてＩＰパケットに対するルーチングポリシーをフロー毎に規定し当該ルーチングポリシーに従ったルーチング処理を施す必要があるため、ルーチングポリシーの情報を記憶するために費すメモリ規模が大きくなってしまうという問題があった。また、到着したＩＰパケットのフローに対応するルーチングポリシーの検索に要する時間も大きくなり、その結果、ルータ内でのルーチング処理に要する時間が大きくなってしまうという問題があった。また、新たな問題として、端末の移動に伴ってパスの再設定が行われている間、その端末より送出されるＩＰパケットの転送は一旦中断してしまい、これによる転送品質の低下が無視できないという問題があった。
【００１１】
本発明は、上記事情を考慮してなされたもので、ルーチング処理や帯域割当制御等を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量の削減や、これらの情報を検索するのに要する時間の削減を可能とするパケットフロー制御方法及びルータ装置を提供することを目的とする。
【００１２】
また、本発明は、端末の移動に伴うフロー再設定の範囲を可能な限り狭めることのできるパケットフロー制御方法及びルータ装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、複数のルータ装置を接続して構成される通信網（例えば、ＩＰ（インターネットプロトコル）を用いた通信網）におけるパケット（例えば、ＩＰパケット）フロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスとして、特定のサービスを要求する複数のパケットフローをアグリゲートするための一定の帯域を確保したパス（例えば、プレミアムサービス用のパス）を予め設定しておくことを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、規定すると判断した場合であっても、前記アグリゲートフロー用のパスに割り当てられた帯域が、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を下回る場合には、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスには転送しないよう制御することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスが存在する場合に、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を計算し、少なくともその算出された帯域が該パスに割り当てられるよう制御することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフローへ収容されるパケットフローに属するパケットの自装置への到着過程を監視し、該到着過程が予め規定したアグリゲートフローのトラヒック特性に従う範囲内で、該アグリゲートフローへのパケットの流入を許可することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記複数のパケットフローが、その各々を流れるパケットのパケット長が予め定められた一定の関係（例えば、全て同一の値）にあり、かつ、いずれのパケットフローにおいてもパケット転送速度は変化しない、という条件を満足するか否かに基づいて、前記アグリゲートフローとしてのトラヒック特性を規定するか否かを判断することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記あるルータ装置へ転送される複数のパケットフローの各々を流れるパケットのパケット長が予め定められた一定の関係になるように、該複数のパケットフローの一部または全部についてパケット長を変えるための処理をＲＴＰレイヤレベルで行い、このＲＴＰレイヤレベルの処理が行われたパケットフローについては、前記アグリゲートフローとしてのトラヒック特性を規定すると判断することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフローに収容される各々のパケットフローにおけるパケットの転送速度を加算したものを該アグリゲートフローにおけるパケット転送速度として規定した場合に、前回、該アグリゲートフローへパケットを流入した時刻から今回、新たなパケットが自装置へ到着した時刻までの経過時間が、該アグリゲートフローにおけるパケット転送速度の逆数を下回らない範囲内で、パケットの該アグリゲートフローへの流入を許可することを特徴とする。
また、本発明は、複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、あるルータ装置へ転送されるパケットフローの情報を受信するステップと、この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、ＩＰの上位レイヤの制御プロトコルであるＲＴＣＰ（リアルタイム転送制御プロトコル）で交換される情報に基づいて、前記アグリゲートフロー用のパスに割り当てる帯域を変更するための制御をＩＰレイヤレベルで行うことを特徴とする。
【００３０】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００３１】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００３２】
本発明によれば、同一なルーチング処理を施すこととなる複数のパケットフローに対しては、これらのパケットフローを束ねたアグリゲートフローを生成し、本アグリゲートフローに対するルーチング処理、帯域割当制御を行うことができる。これにより、ルーチング処理や帯域割当制御を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量が削減でき、これらの情報を検索するのに要する時間の削減が可能となる。また、端末の移動に伴うフロー再設定の範囲も可能な限り狭めることが可能となり、フロー再設定に要する時間の減少が期待できる。
【００３３】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３４】
図１は、本発明の適用対象となる通信網システムの一例である。
【００３５】
図１では、端末２１はルータ１３と、端末２２はルータ１４と、端末２３はルータ１６と、端末２４はルータ１８と、無線回線を介して各々接続されている。また、ルータ１３、ルータ１４、ルータ１５はルータ１１と、ルータ１６、ルータ１７、ルータ１８はルータ１２と、有線回線を介して各々接続されている。さらに、ルータ１１とルータ１２は、直接接続されているか、もしくは一つ以上のルータを介して接続されている。
【００３６】
なお、図１において有線回線にて接続されている部分の全部または一部を無線回線に置き換えて接続した通信網システムや、無線回線にて接続されている部分の全部または一部を有線回線に置き換えて接続した通信網システムも、本発明の適用対象としてもよい。
【００３７】
図１に示した通信網システムにおいて、ＩＰ（インターネットプロトコル）による通信を提供する場合の帯域割当方法について説明する。
【００３８】
なお、以下では、端末２１と端末２３、端末２２と端末２４とが各々通信を行うものとし、端末２１と端末２２が送信側端末、端末２３と端末２４が受信側端末であるものとする。また、端末２１より端末２３宛へのパケットフローをフローａ、端末２２より端末２４宛へのパケットフローをフローｂとし、フローａは、（端末２１）→ルータ１３→ルータ１１→…→ルータ１２→ルータ１６→（端末２３）のルートを通るものとし、フローｂは、（端末２２）→ルータ１４→ルータ１１→…→ルータ１２→ルータ１８→（端末２３）のルートを通るものとする。
【００３９】
図１に示した通信網システムにおける、フローａ、フローｂに対する帯域割当の方法としては、従来の方法である図２７のような、フローａ、フローｂの個々に対して帯域を別々に割り当てる方法の他に、ルータ１１とルータ１２との間では、フローａとフローｂが共に同一ルートを通っている点に着目した、図２に示すような帯域割当方法を考えることができる。
【００４０】
図２においては、フローａに対する帯域割当を、端末２１よりルータ１３を介してルータ１１宛のルート（パス３１）、ルータ１１よりルータ１２宛のルート（パス３５）、ルータ１２よりルータ１６を介して端末２３宛のルート（パス３２）の３つに分割して行う。また、フローｂに対する帯域割当を、端末２２よりルータ１４を介したルータ１１宛のルート（パス３３）、ルータ１１よりルータ１２宛のルート（パス３５）、ルータ１２よりルータ１８を介した端末２４宛のルート（パス３４）の３つに分割して行う。
【００４１】
図２において、パス３５はフローａ、フローｂの両フローを収容している。その際に、パス３５の入側ルータ１１において両フローを束ねて、パス３５内においては、フローａ、フローｂの区別なく、同一のフローとして認識できるようにする。以下、この動作を「フローのアグリゲート」と呼び、一定の区間内（パス３５内）において定義される複数のフローを束ねて生成したフローを「アグリゲートフロー」と呼ぶ。図３に、パス３５内におけるフローａ、フローｂのアグリゲートの様子を示す。
【００４２】
図３に示すように、同一ルートを通過する複数のフローをアグリゲートすれば、パス３５上に存在するルータでは、到着したパケットがフローａ、フローｂのいずれのフローに属しているかを判断する必要がなく、一つのアグリゲートフローとして、到着パケットのルーチング処理、割当帯域に対する品質保証制御を行えばよい。アグリゲートフローを用いたＩＰパケット処理を行うことで、従来のように個々のフロー毎にルーチング処理や品質保証制御を行う方法に比べて、各々のルータにおいて識別すべきフロー数の減少がもたらされ、これは、転送先となる出力ポートや割当帯域といった、各々のルータにおいてフロー毎に記憶すべき情報量の減少につながる。これにより、各々のルータにおいて、前記情報を保持するために必要となるメモリ量の削減、ＩＰパケットのフローに対応する前記情報の検索に要する時間の削減が可能となる。これらの効果は、アグリゲートフローとして束ねるフロー数が増大すると、さらに大きくなる。以上の点において、図３に示す方法は、図２７に示したフローａ、フローｂの各々に別個のパスを提供し、帯域割当を行う従来の方法に比べ、効果的であることが分かる。
【００４３】
アグリゲートフローを用いた通信を実現する際には、アグリゲートフローの始点であるルータ１１では、複数のフロー（本具体例では、フローａとフローｂ）を束ねて新たなアグリゲートフローを生成するための機能（フロー統合機能）、そしてアグリゲートフローの終点であるルータ１２では、アグリゲートフローを分離し、アグリゲートフローへの挿入前の各々のフローを再び形成するための機能（フロー分離機能）が必要となる。
【００４４】
パス３５内にてアグリゲートフローを定義する方法としては、例えば次の２つの方法を挙げることができる。
【００４５】
（１）パケットのカプセル化による方法
図４に示すように、アグリゲートフローの始点であるルータ１１において、アグリゲートフロー内に挿入するＩＰパケットの先頭に、アグリゲートフローを識別するためのＩＰパケットヘッダを付与し、パス３５内のみにて定義される、アグリゲートフロー用の新たなＩＰパケットを生成する。パス３５内のルータは、新たに付与されたＩＰパケットヘッダに基づきルーチング処理を行う。つまり、本来のフローのヘッダ（フローａに属するＩＰパケットのヘッダ、フローｂに属するＩＰパケットのヘッダ）は、パス３５内ではペイロードの一部として位置付けられ、ルーチング処理の際には参照されない。付与されたＩＰパケットヘッダは、アグリゲートフローの終点であるルータ１２において除去され、以後では、本来のフローのヘッダを参照したルーチング処理が行われる。
【００４６】
本方法を用いることで、アグリゲートフロー内では、収容された各々のフローを意識しないルーチング処理が可能となる。
【００４７】
（２）フロー識別子（フローラベル）の変換による方法
本方法では、アグリゲートフロー内にＩＰパケットを挿入する際に、当該パケットがアグリゲートフローに属することを示すよう、アグリゲートフローの始点であるルータ１１にて、ＩＰパケット内に記されている、当該パケットが属するフローを表すフロー識別子を、当該パケットがアグリゲートフロー内に属する旨を表すフロー識別子に変換する。そして、アグリゲートフローの終点であるルータ１２にて、変換したフロー識別子を本来のものに戻す。
【００４８】
図５に、ＩＰパケットフォーマットとしてＩＰｖ６（ＩＰバージョン６）を採用した場合の、フロー識別子の変換例を示す。ＩＰｖ６では、ヘッダ内にフローラベルと呼ばれる、フローを識別するために送信側端末が記載する２８ビット長のフィールドが定義される。そこで、図５では、フローラベルとソースアドレス（１２８ビット長）との組をフロー識別子として扱った場合の変換例を示している。
【００４９】
アグリゲートフローの始点であるルータ１１では、到着したＩＰパケットが、アグリゲートフローに挿入すべきものか否かを、当該パケットのフローラベルとソースアドレスとを調べることにより判断する。その際に、ルータ１１はフローラベル変換表を用いる。本表は、アグリゲートフロー内に挿入すべきＩＰパケットの、フローラベルとソースアドレスの組（フロー識別子）と、アグリゲートフローへの挿入時に置き換えられるフローラベルとを対応づけて構成される。なお、図５においては、フローラベルを１６進数表記しており、ソースアドレスは、送信端末の番号（便宜上、図１〜図３の端末に付した参照符号と同じ値であるとした）をそのままアドレスとして用いている。端末として移動端末をサポートする場合には、本表に記載するソースアドレスは、移動端末に割り当てられたホームアドレスを記載することが望ましい。
【００５０】
図５の例では、ソースアドレス「２１」より送信された、フローラベルが「０１２３４５６」であるＩＰパケット（フローａに属するＩＰパケット）については、フローラベルを「０００１０１２」と変換してからアグリゲートフロー内に挿入し、ソースアドレス「２２」より送信された、フローラベルが「１２３４５６７」であるパケット（フローｂに属するＩＰパケット）については、フローラベルを「０００２０１２」と変換してアグリゲートフロー内に挿入している。
【００５１】
パス３５内のルータでは、到着したＩＰパケットのフローラベルを参照して、当該パケットがアグリゲートフローに収容されているパケットであるか否かを判断する。ＩＰパケットがアグリゲートフローに属する旨を示すフローラベルを保持していれば、パス３５内のルータは、アグリゲートフローとしてのルーチング処理を施し、アグリゲートフローに属する旨を示すフローラベルを保持していなければ、通常通りのルーチング処理を施す。フローラベルに基づくルーチング処理の切替を行うため、パス３５内のルータは、アグリゲートフローを表すフローラベルを全て記憶する必要がある。
【００５２】
アグリゲートフローの終点であるルータ１２では、到着したＩＰパケットが、アグリゲートフローに属するものであれば、当該パケットのフローラベルとソースアドレスとに基づき、フローラベル変換表を用いて、フローラベルを当初のフローラベル値に戻す。出側ルータにて保持するフローラベル変換表は、アグリゲートフローラベルとソースアドレスの組と、当初のフローラベルとを対応づけて構成される。
【００５３】
なお、パス３５内のルータにて、到着したＩＰパケットがアグリゲートフローに属するパケットであるか否かの判断を容易に行えるようにするため、例えば、２８ビットからなるフローラベルの指定したフィールドの値を、アグリゲートフローに属するＩＰパケットに対しては同一値となるように、フローラベルの変換を行う。これにより、到着したＩＰパケットのフローラベルのうち当該フィールドの値のみを調べれば、本パケットがアグリゲートフローに属するかを判断することが可能となる。図５の例では、アグリゲートフローに挿入するＩＰパケットに対して、下位１２ビットの値が「０１２」という値をとるようにフローラベルを割り当てており、本例の場合、パス３５内のルータでは、フローラベル内の下位１２ビットを参照するだけで、アグリゲートフローとしてのルーチング処理を行うか否かを判断できる。
【００５４】
上に示したパケットのカプセル化によりアグリゲートフローを定義する方法、フロー識別子（フローラベル）の変換によりアグリゲートフローを定義する方法の他にも、種々の方法が考えられ、例えば、ＭＰＬＳ（マルチプロトコルラベルスイッチング）を実行可能なルータにて構成された通信網システムである場合には、「ラベル」値を利用してアグリゲートフローを定義する方法を用いてもよい。
【００５５】
なお、複数のアグリゲートフローを設定する場合には、各ＩＰパケットがどのアグリゲートフローに属するものかを特定することが必要となる。この場合、例えば、図４の例においては、もとのＩＰパケットの外側に新たにアグリゲート用のヘッダを付与したが、このアグリゲート用のヘッダ内にある何らかの情報から、アグリゲートフローを特定可能とすればよい。また、例えば、図５の例では、アグリゲートフローに挿入するＩＰパケットに対して、下位１２ビットの値が「０１２」という値をとるようにフローラベルを割り当たが、アグリゲートフローに挿入するＩＰパケットに対して割り当てる下位１２ビットの値の範囲を定め、その値の違いによりアグリゲートフローを特定可能とすればよい。
【００５６】
ところで、アグリゲートフローに挿入可能なＩＰパケットフローは、例えば、プレミアムサービスを要求する音声データをＩＰパケット化したフローに限定するようにしてもよい。また、その際に、その音声データは、ＩＰの上位レイヤの転送プロトコルであるＲＴＰ（リアルタイム転送プロトコル）により生成されたパケット（ＲＴＰパケット）をＩＰパケット化して転送されるものとしてもよい。
【００５７】
以下、このようにした場合について説明する。
【００５８】
図６に、送信側端末の上位レイヤにＲＴＰパケットを搭載した場合の、ＩＰパケットの生成過程の概略を示す。ＲＴＰでは、一定時間Ｔ毎に、当該時間内に生成されたアプリケーションデータを抽出してＲＴＰパケットを生成する。このとき、データが挿入されなかったペイロード領域をパディングすることで、ＲＴＰレベルでは、上記時間Ｔにて定まる固定長ＬのＲＴＰパケットを常に生成することとなる。本ＲＴＰパケットを、ＵＤＰ（ユーザデータグラムプロトコル）レベルの処理を介した後にＩＰレベルに引き渡し、ＩＰパケットの生成を行う。図６より明らかなように、送信側端末の上位レイヤにＲＴＰパケットを搭載した場合、当該端末より送出されるＩＰパケットは常に固定長のパケットとなる。
【００５９】
なお、ＲＴＰ、ＵＤＰを介した後に生成されたＩＰパケット（ＩＰ／ＵＤＰ／ＲＴＰパケット）のオーバーヘッドである、各々のプロトコルレベルにて規定されるヘッダ部分を圧縮させた後に、通信網上へ送出するという方法を用いてもよい。具体的には、コンテキスト識別子（ＣＩＤ）と圧縮前のパケットのヘッダ内容とを対応させて覚えておき、同一のヘッダ内容を持つパケットを引続き送信する時には、当該パケット内のＵＤＰヘッダ部、ＲＴＰヘッダ部を圧縮すると同時に前記ＣＩＤをパケット内に含ませてから送信し、相手先にて、ＣＩＤを用いてヘッダ部の復元を行う。
【００６０】
アグリゲートフローに収容されるＩＰパケットフローが全て、図６に示すように一定時間Ｔ毎に生成されるＲＴＰパケットをＩＰパケット化したものであれば、当該アグリゲートフローに収容されるＩＰパケットは全て同一パケット長であり、かつ、各々のＩＰパケットフローにおいては、一定速度にてパケット転送が行われるため、アグリゲートフローのトラヒック特性は、各々のＩＰパケットにおけるパケット転送速度の総和を用いて容易に表すことができる。
【００６１】
また、アグリゲートフローに収容されるＩＰパケットのパケット長が全てのフローにおいて同一であれば、例えばアグリゲートフローが通過するルータにおいて、品質保証制御を目的として当該アグリゲートフローのＩＰパケット転送速度の監視を行う場合、前記ルータではＩＰパケットの到着時刻のみを把握するだけでよく、パケット長に関する情報は（全て同一であるので）把握する必要がないため、ルータにおけるＩＰパケット処理のさらなる低減が可能となる。
【００６２】
なお、アグリゲートフローに収容されるＩＰパケットフローが全てＲＴＰパケットをＩＰパケット化したものであっても、ＲＴＰパケットを生成する時間間隔が送信側端末毎に異なった場合には、当該アグリゲートフローに収容されるＩＰパケットは全て同一パケット長とはならない。つまり、ＩＰパケットフロー毎に、転送されるＩＰパケットのパケット長が異なるということを意味する。このような場合でもアグリゲートフローによるＩＰパケット処理は実行可能であるが、各々のルータにおいては、アグリゲートフローを転送されるＩＰパケットのパケット長を考慮したパケット処理を実行する必要がある。
【００６３】
このようなアグリゲートフローに対する帯域割当制御、アグリゲートフローの始点にて実行する、アグリゲートフローへのＩＰパケットの受付制御の一例を、以下に示す。
【００６４】
（１）帯域割当制御
帯域割当用プロトコルとして、ＲＳＶＰ（リソース予約プロトコル）を用いた場合を例にとり、説明する。
【００６５】
図７に、ＲＳＶＰにて定義されるＰａｔｈメッセージ（Ｐａｔｈ ｍｓｇ．）、Ｒｅｓｖメッセージ（Ｒｅｓｖ ｍｓｇ．）の流れの概要を示す。なお、Ｐａｔｈメッセージは、ＩＰパケットフローのトラヒック特性を記載して、送信側端末より受信側端末へ送出し、Ｒｅｓｖメッセージは、ＩＰパケットフローに対する予約要求内容を記載して、受信側端末より送信側端末へ送出する。
【００６６】
図７に示すように、アグリゲートフローの始点であるルータ１１では、当該フローに収容される全てのフローのＰａｔｈメッセージに基づいてアグリゲートＰａｔｈメッセージを生成する。また、アグリゲートフローの終点であるルータ１２では、当該フローに収容される全てのフロー（図７では、Ｆｌｏｗ−ａとＦｌｏｗ−ｂ）のＲｅｓｖメッセージに基づいてアグリゲートＲｅｓｖメッセージを生成する。パス３５内のＲＳＶＰ対応ルータでは、アグリゲートＰａｔｈメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｐａｔｈ ｍｓｇ．）、アグリゲートＲｅｓｖメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｖ ｍｓｇ．）に基づいて、アグリゲートフローに対する帯域割当制御を行う。
【００６７】
なお、アグリゲートフローに収容される個々のフローのＰａｔｈメッセージ、Ｒｅｓｖメッセージも、アグリゲートフロー内に収容するが、これらの制御メッセージは、パス３５内のＲＳＶＰ対応ルータにおいて、ＲＳＶＰ規定の処理が行われないようにする必要がある。つまり、これら個々のフローにおける制御メッセージは、一つのデータパケットと認識されるようにアグリゲートフロー内に収容すべきである。例えば、これらの制御メッセージの先頭に、アグリゲートフローを識別するためのＩＰパケットヘッダを付与して、制御メッセージ内容を隠蔽する方法（図４を参照）、または、フローラベルの変換後の値に基づいて、アグリゲートＰａｔｈメッセージと個々のフローのＰａｔｈメッセージの区別、アグリゲートＲｅｓｖメッセージと個々のフローのＲｅｓｖメッセージの区別を行う方法（図５を参照）などにより、実現可能である。
【００６８】
このとき、上位レイヤにＲＴＰを用いて生成されたＩＰパケットフローのみをアグリゲートする場合、各々のフロー内にて生成されるＰａｔｈメッセージ内に記載されるトラヒック特性は、図６にて示したＲＴＰパケットの生成間隔Ｔにより決定されるＩＰパケットの転送速度のみで規定可能であるため、アグリゲートＰａｔｈメッセージ内に記載されるトラヒック特性は、各々のＰａｔｈメッセージ内に記載されているパケット転送速度の総和にて定義することが可能である。図８の例では、フローａ、フローｂが各々５Ｍｂｐｓの速度にて送信されるトラヒックフローをアグリゲートするので、アグリゲートフローのパケット転送速度は、１０Ｍｂｐｓと容易に規定することができる（図８（ａ））。Ｒｅｓｖメッセージのアグリゲートも同様に、要求帯域の総和をアグリゲートフローに対して予約すればよい（図８（ｂ））。
【００６９】
アグリゲートフローに割り当てる帯域を、生成したアグリゲートＲｅｓｖメッセージ内の要求帯域に等しく割り当てる方法の他に、収容される個々のフローが要求する要求帯域に関わらず、予め通信網システム（アグリゲートフローの終端点となるルータ）において取り決めておいた帯域を割り当てる方法を用いてもよい。この場合は、上述したように、アグリゲートＰａｔｈメッセージ、アグリゲートＲｅｓｖメッセージを用いた、動的な帯域割当を実行する必要はない。また、新たなフローをアグリゲートフローとして収容することで、必要となる帯域が予め割り当てられた帯域を上回る場合には、このフローの収容を拒絶するためフロー受付制御を搭載する必要がある。
【００７０】
（２）ＩＰパケット受付制御
上述したように、上位レイヤにＲＴＰを用いて生成されたＩＰパケットフローのみをアグリゲートしたアグリゲートフローのトラヒック特性は、当該アグリゲートフローに収容される各々のフローのパケット転送速度の総和にて規定可能である。そのため、パス３５の入口にて実行する、アグリゲートフローへのＩＰパケット受付制御も、到着パケットのパケット転送速度を監視して、当該転送速度が本アグリゲートフローにおけるパケット転送速度の総和を上回らない場合に限り、到着パケットをアグリゲートフロー内に収容すればよい。
【００７１】
さて、次に、本実施形態に係るルータの構成について説明する。
【００７２】
図９に、アグリゲートフローの端点となり得るルータ（図１の例では、ルータ１１、ルータ１２）の構成例を示す。
【００７３】
図９において、４１はスイッチ部、４２はプロトコル処理部、４３はパケットヘッダ処理部、４４はルーチング処理部、４５はポート対応部、４５１はパケット受付制御部である。図９においては、４入力４出力の場合を例にとり示しており、パケット出力ポート毎にパケット受付制御部４５１が設置される。
【００７４】
ポート対応部４５は、各入出力ポート毎に設けられ、入力ポートからパケットを入力する処理と出力ポートからパケットを送出させる処理を行う。
【００７５】
スイッチ部４１は、任意のパケット入力ポートより到着したＩＰパケットを、ルーチング処理部４４により選択されたパケット出力ポートへ出力させるための動作を行う。本スイッチ部４１は、例えばイーサネットスイッチ、ファイバチャネルスイッチ、ＡＴＭスイッチ、などにて構成可能である。
【００７６】
プロトコル処理部４２では、スイッチ部４１に到着したＩＰパケットが、任意のプロトコルにて規定された制御メッセージであるか否かを判断し、制御メッセージであれば、当該メッセージに基づく処理を行う。例えば、到着パケットが、ＲＳＶＰにて規定されているＰａｔｈメッセージであれば、Ｐａｔｈメッセージ内のトラヒック特性を記憶して、パケット受付制御部４５１へ本特性を通知する。また、到着パケットが、ＲＳＶＰにて規定されているＲｅｓｖメッセージであれば、Ｒｅｓｖメッセージ内の資源予約要求が受付可能であるか否かを判断し、受付可能であれば、相当するフローに対する資源の確保を指示する。
【００７７】
そして、プロトコル処理部４２では、アグリゲートフローの新規設定や解放に伴う処理を行う。
【００７８】
また、プロトコル処理部４２では、スイッチ部４１に到着したＩＰパケットをアグリゲートフロー内に挿入すべきパケットであるか否かを判断し、アグリゲートフロー内に挿入すべきパケットであれば、パケットヘッダ処理部４３へ、パケットヘッダの操作を指示する。
【００７９】
さらに、プロトコル処理部４２では、アグリゲートＰａｔｈメッセージ、アグリゲートＲｅｓｖメッセージの生成／終端も行う。
【００８０】
パケットヘッダ処理部４３では、スイッチ部４１に到着したＩＰパケットがアグリゲートフロー内に挿入されるパケットである場合に、図４にて示したパケットのカプセル化、もしくは図５に示したパケットヘッダ内のフローラベルの変換といった処理を行う。
【００８１】
ルーチング処理部４４では、パケットヘッダ処理部４３にて処理されたＩＰパケットのフローラベル、もしくは、アグリゲートフロー内に収容されない、スイッチ部４１に到着したＩＰパケットのデスティネーションアドレス（必要に応じて、ソースアドレス、フローラベルも参照）を参照して、当該パケットの出力先ポートを決定し、本ポートへ当該パケットをルーチングするよう、スイッチ部４１に指示する。
【００８２】
パケット受付制御部４５１は、アグリゲートフローへ収容するＩＰパケットの受付制御、もしくは、アグリゲートフローに限定しない任意のフローに対するＩＰパケットの受付制御を行う。なお、パケット受付制御部４５１は、図９に示すように各ポート毎に設置する代わりに、ルーチング処理部４４内に設置して、ＩＰパケットのルーチングを決定すると同時に、当該パケットの受付の可否を判断するというように構成してもよい。
【００８３】
次に、図１０に、アグリゲートフローの生成手順の一例を示す。
【００８４】
図１０では、パケットフローａがサービス中であるところへ、パケットフローｂが新たにサービスを開始する場合を例にとり、説明する。
【００８５】
フローｂ上にＰａｔｈメッセージが到着すると、ルータ１１のプロトコル処理部４２では、フローｂとアグリゲートが可能なフローが、本Ｐａｔｈメッセージの出側ポートと同一のポートより送出されるフローの中に存在するかを判断する（図１０（ａ））。例えば、両フローともＲＴＰを介して生成されるＩＰパケットであり、固定長のパケットが一定のパケット転送速度にて送出されるような場合には、フローのアグリゲートが可能であると判断する。図１０の例では、フローａとのアグリゲートを試みるものとする。
【００８６】
次に、ルータ１１内のプロトコル処理部４２は、アグリゲートフローの終端ノードとなり得るルータの検索を行うためのメッセージ（終端ノード検索メッセージ）を生成し、フローｂのＰａｔｈメッセージの宛先アドレス宛に送信する（図１０（ｂ））。このとき、終端ノード検索メッセージ内には、アグリゲートの相手がフローａである旨を記載しておく。
【００８７】
終端ノード検索メッセージを受信するルータでは、当該メッセージ内の宛先アドレスより決定される出側ポートと、当該メッセージ内に記載されているフローａの出側ポートが同一であるかを比較し、同一の出側ポートを用いていれば、引続き当該メッセージを次段ルータ宛に送信する。
【００８８】
終端ノード検索メッセージ内の宛先アドレスより決定される出側ポートと、当該メッセージ内に記載されているフローａの出側ポートが異なるルータ（ルータ１２）に到着すれば、本ルータ内のプロトコル処理部４２では、自ルータがアグリゲートフローの終端ルータとなることを記憶して、それに伴うＩＰパケットのヘッダ処理（アグリゲートフロー用に修正されたＩＰヘッダを、当初のＩＰヘッダへ戻すための処理）を行うよう、パケットヘッダ処理部４３へ指示する。そして、ルータ１２は、終端ノード検索メッセージが終端ルータに到達した旨を、当該メッセージを生成したルータ１１に通知する（図１０（ｃ））。
【００８９】
ルータ１１にて、終端ノード検索メッセージが終端ルータに到達した旨を認識すれば、本ルータ内のプロトコル処理部４２では、自ルータがアグリゲートフローの開始ルータとなることを記憶して、それら伴うＩＰパケットのヘッダ処理（アグリゲートフロー用にＩＰヘッダを修正するための処理）を行うよう、パケットヘッダ処理部４３へ指示する（図１０（ｄ））。
【００９０】
次に、図１１に、新規フローのアグリゲートフローへの挿入手順の一例を示す。
【００９１】
図１１では、パケットフローａとパケットフローｂとを収容するアグリゲートフローが存在するところへ、パケットフローｃが新たにサービスを開始する場合を例にとり、説明する。
【００９２】
フローｃ上にＰａｔｈメッセージが到着すると、ルータ１１のプロトコル処理部４２では、フローｃが、フローｃの出側ポートを始点としている既存のアグリゲートフロー内に挿入することが可能であるか否か（アグリゲートフローとのアグリゲートが可能であるか否か）を判断する（図１１（ａ））。
【００９３】
フローｃを、アグリゲートフロー内に挿入可能であると判断すれば、ルータ１１内のプロトコル処理部４２は、アグリゲートフローの終端ノードであるルータ１２に対して、当該アグリゲートフロー内にフローｃを挿入する旨を伝えるメッセージを送信する（図１１（ｂ））。
【００９４】
当該メッセージを受信した、アグリゲートフローの終端ノードであるルータ１２は、フローｃ内のパケットもアグリゲートフローを介して受信される旨を記憶して、それに伴うＩＰパケットのヘッダ処理を行うよう、パケットヘッダ処理部４３へ指示する。そして、当該メッセージが到達した旨を、ルータ１１に通知する（図１１（ｃ））。
【００９５】
ルータ１１にて、当該メッセージが終端ルータに到達した旨を認識すれば、フローｃ内のパケットもアグリゲートフローに挿入するよう、パケットヘッダ処理部４３へ指示する（図１１（ｄ））。
【００９６】
さて、次に、端末の移動に対応可能な通信網システムを提供する際に必要となる機能について、説明する。
【００９７】
図１２には、端末２２の移動に伴い、端末２２の接続先であるルータが、ルータ１４よりルータ１５へ変更となった場合の通信網システム内のフローがとるルートの変更の様子を示す。
【００９８】
端末２２の移動に伴い、フローｂに対しては、端末２４迄の通信を行うための新たなルートが設定される。図１２の例では、フローｂの新たなルートが、（端末２２）→ルータ１５→ルータ１１→…→ルータ１２→ルータ１８→（端末２４）になったものとする。
【００９９】
フローｂが上記ルートを通る場合、フローｂはルータ１１を通過するため、アグリゲートフローの始点であるルータ１１では、端末２２の移動前にフローｂを収容していたアグリゲートフロー内に、フローｂ上を転送するＩＰパケットを引続き収容することが可能である。これは、ルータ１１内のパケットヘッダ処理部４３では、到着したＩＰパケットの入側ポートに関係なく、ＩＰパケット内のフローラベルとソースアドレス（端末２２に固有に割り当てられたアドレス）との組により、到着パケットがフローｂに属することを判断するからである。つまり図１２の例では、端末２２の移動に伴う手続きとしては、パス３３を解放する手続きと、新たにパス３６を設定してパス３６上に必要帯域を確保する手続きとを行うのみでよく、ルータ１１より端末２４までのパス３５，３４に対しては、如何なる変更も施す必要がない。
【０１００】
図１３には、端末２２の移動に伴い、端末２２の接続先であるルータが、ルータ１４よりルータ１９へ変更となった場合の通信網システム内のフローがとるルートの変更の様子を示す。
【０１０１】
図１３の例では、端末２２の移動に伴うフローｂの新たなルートは、（端末２２）→ルータ１９→…ルータ１８→（端末２４）になったものとする。
【０１０２】
フローｂが上記ルートを通る場合、フローｂは、端末２２の移動前のルート上にあるルータ１１を通過せずに宛先である端末２４へ到達する。つまり、移動後のフローｂはルータ１１とルータ１２との間に存在するアグリゲートフローを使用しないこととなる。よって、端末２２と端末２４との間には、新たにパス４３が設定される。なお、ルータ１９とルータ１８との間に、フローｂとのアグリゲートが可能なフローが存在する場合には、図１０にて示した手順に従い、新たにアグリゲートフローを生成することが可能である。また、ルータ１９とルータ１８との間に、フローｂを挿入することが可能な既存のアグリゲートフローが存在する場合には、図１１にて示した手順に従い、既存のアグリゲートフロー内にフローｂを挿入することが可能である。
【０１０３】
なお、端末２２の移動前にフローｂを収容していた、ルータ１１とルータ１２との間のアグリゲートフローは、現在フローａのみを収容しているため、アグリゲートフローを解放して、端末２１と端末２３との間にパス４１を新たに設定する場合もある。
【０１０４】
以上のように本実施形態によれば、同一なルーチング処理を施すこととなる複数のＩＰパケットフローに対しては、これらのＩＰパケットフローを束ねたアグリゲートフローを生成し、本アグリゲートフローに対するルーチング処理、帯域割当制御を行うことができる。これにより、ルーチング処理や帯域割当制御を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量が削減でき、これらの情報を検索するのに要する時間の削減が可能となる。また、端末の移動に伴うフロー再設定の範囲も可能な限り狭めることが可能となり、フロー再設定に要する時間の減少が期待できる。
【０１０５】
次に、本発明を他の通信網システムに適用する場合の例について説明する。
【０１０６】
図１４は、本発明の適用対象となる通信網システムの図１とは異なる一例である。
【０１０７】
図１４では、通信網を、プレミアムサービス用ネットワーク５１と通常サービス用ネットワーク５２との二種類に、論理的もしくは物理的に分割している。なお、プレミアムサービス用ネットワーク５１は、サービスクラス毎のＩＰパケット処理ポリシーの規定が可能な（ＣｏＳ（サービスクラス）サポートのある）ルータにより構成されるネットワークである。なお、図１４において、プレミアムサービス用ネットワーク５１を構成するルータ装置は省略してある（プレミアムサービス用のパスの出入口に位置するルータ装置は、例えば図９のような構成とする）。
【０１０８】
なお、図１４において有線回線にて接続されている部分の全部または一部を無線回線に置き換えて接続した通信網システムにも本発明は適用可能である。
【０１０９】
プレミアムサービス用ネットワークでは、通常サービス用ネットワークからの指示により、通常サービス用ネットワーク内の任意のルータ間での、プレミアムサービスを要求するＩＰパケットの配送を目的としたパスの設定、そして、既に設定されているパスの解放が行われる。図１４の例では、ルータ５４１とルータ５４２との間にて、プレミアムサービスを要求するＩＰパケットの配送のためにパス５３１が、ルータ５４１とルータ５４３との間にて、プレミアムサービスを要求するＩＰパケットの配送のためにパス５３２が、ルータ５４２とルータ５４３との間にて、プレミアムサービスを要求するＩＰパケットの配送のためにパス５３３が、各々設定されている。なお、プレミアムサービスを要求しないＩＰパケットを配送する際には、プレミアムサービス用ネットワークを用いず、通常サービス用ネットワークのみを用いる。
【０１１０】
図１４において、端末５６１より端末５６２宛へのプレミアムサービスでの通信要求が生じた場合を例にとり、プレミアムサービスの通信が開始されるまでを説明する。
【０１１１】
端末５６１を収容する基地局５５１と接続するルータ５４１では、端末５６１より生じたプレミアムサービスでの通信要求を受信すると、当該通信の相手端末である、端末５６２迄の通信ルートの設定を、プレミアムサービス用ネットワーク５１を介して行う。図１４の例では、ルータ５４１にて、通信の相手端末５６２が基地局５５２に収容されていることを認識すれば、ルータ５４１は、基地局５５２と接続するルータ５４２宛へ設定されている、プレミアムサービス用ネットワーク内のパス５３１を用いて通信を行えば良いことが分かる。そこで、ルータ５４１は、当該プレミアムサービスを要求するＩＰパケットをパス５３１内に挿入するようルートを設定する。また、パス５３１の出口に位置するルータ５４２では、パス５３１より到着する当該プレミアムサービスを要求するＩＰパケットを、基地局５５２を介して端末５６２へ送信するよう、ルートを設定する。
【０１１２】
ところで、プレミアムサービスを提供すべき新規ＩＰパケットフローが挿入されることを認識したパス５３１では、収容ＩＰパケットフロー情報の更新を行う。収容ＩＰパケットフロー情報は、例えば図１５のように、ＩＰパケットフローの識別子と当該フローのトラヒック特性とを対応づけて、パスの入口（パス５３１の場合だと、例えばタール５４１）にて保持されるものである。
【０１１３】
そして、現在パスに収容しているＩＰパケットフローを統計多重することにより得られる、アグリゲートフローのトラヒック特性を、当該パス内に収容するＩＰパケットフローが増加、もしくは減少する度に算出し、本アグリゲートフローを収容するのに十分な帯域を、当該パスに割り当てる。図１５の例では、各ＩＰパケットフローが、一定の速度に従いパケット転送を行い、本フローのトラヒック特性がパケット転送速度値のみを用いて表すことのできる例を用いているため、アグリゲートフローのトラヒック特性は、これらのパケット転送速度値の総和にて表すことができる。
【０１１４】
なお、プレミアムサービス用ネットワーク内での帯域割当制御を、ＲＳＶＰを用いて行う方法をとってもよい。この場合、図１６のように、パスの送信側端点に位置するルータにて、図１５にて記載されているアグリゲートフローのトラヒック特性を記載したＰａｔｈメッセージを周期的に生成して送信し、また、パスの受信側端点に位置するルータにて、プレミアムサービスとして必要なサービス品質を記載したＲｅｓｖメッセージを周期的に生成して送信する。これに基づき、プレミアムサービス用ネットワーク内の各ルータでは、受信するＰａｔｈメッセージ、Ｒｅｓｖメッセージに基づいて、各々のパスに対する帯域割当を実行する。
【０１１５】
さらに、プレミアムサービス用ネットワーク内のパスは、当該パスに収容されるフローの有無に関わらず、常に固定的に設定しておく方法を用いてもよい。このとき、当該パスに割り当てる帯域は、予めプレミアムサービス用ネットワークにおいて取り決めておいた帯域を固定的に割り当てておく。
【０１１６】
プレミアムサービス用ネットワーク内に設定されたパスの入口では、ＩＰパケット受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケット受付制御部４５１に相当）を設けて、予め定められたアグリゲートフローのトラヒック特性に合致しないＩＰパケットの、プレミアムサービス用ネットワーク内への流入を防ぐというトラヒック制御を実行するようにしてもよい。
【０１１７】
次に、本発明をさらに他の通信網システムに適用する場合の例について説明する。
【０１１８】
図１７は、本発明の適用対象となる通信網システムの図１および図１４とは異なる一例である。
【０１１９】
図１７では、通信網を、基地局６５１〜６５６を収容する小規模なネットワーク６２〜６４と、ネットワーク６２〜６４を収容する大規模なネットワーク６１との二種類に、論理的もしくは物理的に分割している。なお、ネットワーク６１内には、ネットワーク６２〜６４の任意の二種類のネットワーク間の通信を提供するためのパス６１１〜６１３が固定的に設定されている。なお、図１７において、プレミアムサービス用ネットワーク５１を構成するルータ装置は省略してある（大規模ネットワーク中のパスの出入口に位置するルータ装置は、例えば図９のような構成とする）。
【０１２０】
なお、図１７において有線回線にて接続されている部分の全部または一部を無線回線に置き換えて接続した通信網システムにも本発明は適用可能である。
【０１２１】
ネットワーク６２〜６４では、ＩＰパケットフローに対する帯域予約要求が生じる度に、例えばＲＳＶＰによる帯域予約が、ＩＰパケットフロー毎になされる。また、ネットワーク６１では、ネットワーク６２〜６４の異なるネットワーク間にて生じる通信に対する帯域予約を、パケットのカプセル化やフロー識別子（フローラベル）の変換により生成するアグリゲートフロー毎に、例えばＲＳＶＰを用いてなされる。
【０１２２】
図１７は、端末６６２が基地局６５３に収容されている場合の、端末６６１宛へのＩＰパケットフローに対する帯域予約の例を示したものである。このとき、送信端末６６２を収容する基地局６５３は、受信端末６６１を収容する基地局６５１はネットワーク６２内に存在することを認識し、基地局６５３が存在するネットワーク６３とネットワーク６２とを接続するネットワーク６１内に設定されているパス６１２を用いて通信を行うよう、ルート設定を行う。そして、ネットワーク６３では、基地局６５３とネットワーク６１内のパス６１２の入口とを接続するパス６３１を設定して、本パス６３１に対する帯域予約を行い、ネットワーク６２では、ネットワーク６１内のパス６１２の出口と基地局６５１とを接続するパス６２１を設定して、本パス６２１に対する帯域予約を行う。さらに、ネットワーク６１では、新規フローを新たに束ねたアグリゲートフローを収容するパス６１２において、アグリゲートフロー全体での帯域予約がなされる。なお、先の例と同様に、パス６３１、パス６１２、パス６２１の入口では、ＩＰパケット受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケット受付制御部４５１に相当）を設けて、ＩＰパケットの受付制御を行ってもよい。
【０１２３】
ここで、図１８に示すように、端末６６２の移動により、収容される基地局が基地局６５３より基地局６５６に変更された場合を考える。このとき、端末６６２は、基地局６５６に対して自信が基地局６５６のエリア内に存在することを通知する。本通知を受けた基地局６５６では、端末６５１との間の帯域予約をＲＳＶＰを用いて実行する。
【０１２４】
基地局６５６は、自信が存在するネットワーク６４と、受信端末６６２を収容する基地局６５１が存在するネットワーク６２とを接続する、ネットワーク６１内に設定されているパス６１１を用いて通信を行うよう、ルート設定を行う。そして、ネットワーク６４では、基地局６５６とネットワーク６１内のパス６１１の入口とを接続するパス６４１を設定して、本パス６４１に対する帯域予約を行い、ネットワーク６２では、ネットワーク６１内のパス６１１の出口と基地局６５１とを接続するパス６２２を設定して、本パス６２２に対する帯域予約を行う。さらに、ネットワーク６１では、新規フローを新たに束ねたアグリゲートフローを収容するパス６１１において、アグリゲートフロー全体での帯域予約がなされる。なお、上記と同様に、パス６４１、パス６１１、パス６２２の入口では、ＩＰパケット受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケット受付制御部４５１に相当）を設けて、ＩＰパケットの受付制御を行ってもよい。
【０１２５】
なお、端末６６２が基地局６５３に収容されていた際に設定されたパス６３１、パス６２１に対しては、端末６６２の移動に伴い、Ｐａｔｈメッセージ、Ｒｅｓｖメッセージのパス６３１、パス６２１上の送信がなくなり、一定時間これらのメッセージが受信されなければ、ＲＳＶＰに規定されているタイムアウト機能により、パス６３１、パス６２１に対して確保された帯域は全て解放されることとなる。また、端末６６２より端末６６１宛のＩＰトラヒックフローを収容していたネットワーク６１内のパス６１２においても、当該フローの流入の終了に伴い、当該フローを除いたアグリゲートフローに対する帯域予約が新たに行われる。
【０１２６】
なお、ネットワーク６１内のパス６１１，６１２，６１３が確保する帯域は、収容されているフローの有無に関わらず、固定量を割り当てるという方法を用いてもよい。
【０１２７】
以下では、リアルタイム通信用のプロトコルであるＲＴＰを用いた場合に、ＲＴＰレベルにてパケットのストリームをアグリゲートした場合の制御方法について説明する。なお、ＲＴＰレベルでのアグリゲートの方法は基本的には前述したＩＰレベルでのアグリゲートの方法と同様である（図４、図５参照）。
【０１２８】
図１９に、ＲＴＰレベルでのパケット転送制御の概要を示す。ＲＴＰ自身は、ＱｏＳを保証するためのプロトコルではなく、ＲＴＰパケットにタイムスタンプやシーケンス番号などの付与、そしてＲＴＣＰ（ＲＴＰ制御プロトコル）による送信者と受信者との間の情報交換サービスを提供する。つまり、ＲＴＰとＲＴＣＰを用いることにより、ＲＴＰの上位レイヤ（例えばアプリケーション）は、例えば受信者からの情報よりネットワークの状態が推定できるので、それにより輻輳であると判断すれば、データの送信速度を制限するようなＱｏＳ制御を行うことができる。
【０１２９】
図２０に、ＲＴＰの通信シーケンスを示す。ＲＴＰ通信を開始する際、送信者はＳＤＥＳ（ソース記述アイテム）メッセージを記載したＲＴＣＰパケットを受信者側に送出し、通信で使用するセッション情報等を伝える。ＳＤＥＳメッセージを送出することで、ＲＴＰセッションが確立され、送信者はＲＴＰデータをあるビットレートにて送出する。
【０１３０】
送信者は、ＲＴＰデータを送出した時点から周期的に（例えば一定間隔ΔｔSで）、ＳＲ（送信者報告）メッセージを記載したＲＴＰパケットを送出する。ＳＲメッセージでは、送信者側でのタイムスタンプ値、送信パケット総数とそのオクテット数の総数などの情報メッセージが記載される。
【０１３１】
また、受信者は、ＲＴＰデータを受信した時点から周期的に（例えば一定間隔ΔｔRで）、ＲＲ（受信者報告）メッセージを記載したＲＴＣＰパケットを送出する。ＲＲメッセージでは、パケット損失数、受信者でのシーケンス番号、遅延ジッタ、最後に受信したＳＲメッセージからの遅れなどの情報メッセージが記載される。
【０１３２】
通信終了時には、送信者はＢＹＥメッセージを記載したＲＴＣＰパケットを送出することで、ＲＴＰセッションを開放する。
【０１３３】
送信者と受信者では、上述のようにＳＲメッセージ、ＲＲメッセージを交換し合うことで、帯域にあったビットレートを調整してＲＴＰデータを送出する。
【０１３４】
ＲＴＰでは、「ミキサ」の概念をサポートしている。ミキサは、１つ以上のソースから送信されるＲＴＰパケットのストリーム（以下、ＲＴＰストリームと呼ぶ）を受信し、ＲＴＰパケット内のデータフォーマットを変更したり、ＲＴＰストリームをアグリゲートして新たなストリームを生成し、これを転送するＲＴＰパケットの中継装置である。
【０１３５】
図２１に、ＲＴＰミキサを用いたＲＴＰストリームの生成の一例を示す。図２１では、図１に示した通信網システムにおける例について示したものである。
【０１３６】
図２１では、端末２１より端末２３宛にＲＴＰパケットを送信し、また、端末２２より端末２４宛にＲＴＰパケットを送信する。これらを各々ＲＴＰストリームａ、ＲＴＰストリームｂとする。ＲＴＰミキサ１１（図１におけるルータ１１に相当）では、ＲＴＰストリームａとＲＴＰストリームｂとをアグリゲートし、新たなＲＴＰストリームｃを生成し、ＲＴＰミキサ１２（図１におけるルータ１２に相当）へ送信する。ＲＴＰミキサ１２では、ＲＴＰストリームｃをＲＴＰストリームａとＲＴＰストリームｂとに再び分離し、各々を送信先である端末２３もしくは端末２４へ送信する。なお、以下では、端末２１とＲＴＰミキサ１１間におけるＲＴＰストリームａとＲＴＰミキサ１２と端末２３との間におけるＲＴＰストリームａとを区別するため、ＲＴＰミキサ１２と端末２３との間におけるＲＴＰストリームａについては、ＲＴＰストリームａ’と記載する。同様の理由により、ＲＴＰミキサ１２と端末２４との間におけるＲＴＰストリームｂについては、ＲＴＰストリームｂ’と記載する。
【０１３７】
ＲＴＰストリームの送信者と受信者との間の情報交換を提供するＲＴＣＰパケットが、ＲＴＰストリームの終端ノード間にて行われる。図２１では、ＲＴＰストリームａに対するＲＴＣＰパケットが端末２１とＲＴＰミキサ１１との間で、ＲＴＰストリームｂに対するＲＴＣＰパケットが端末２２とＲＴＰミキサ１１との間で、ＲＴＰストリームｃに対するＲＴＣＰパケットがＲＴＰミキサ１１とＲＴＰミキサ１２との間で、ＲＴＰストリームａ’に対するＲＴＣＰパケットがＲＴＰミキサ１２と端末２３との間で、ＲＴＰストリームｂ’に対するＲＴＣＰパケットがＲＴＰミキサ１２と端末２４との間で各々送受信される。
【０１３８】
図２２は、ＲＴＰストリームａ、ＲＴＰストリームｂ、ＲＴＰストリームａ’が通過する端末、ルータ、ＲＴＰミキサにおけるプロトコルスタックを示す。なお、ＩＰレイヤより下位レイヤにおけるプロトコルスタックについては図示していない。
【０１３９】
図２２に示すように、ルータ１３やルータ１６においては、受信したＩＰパケットをＲＴＰパケットに組み立てることなく、ＩＰパケットのヘッダ情報をもとにルーチング処理を行う。それに対して、ＲＴＰミキサ１１およびＲＴＰミキサ１２においては、受信したＩＰパケットを一旦ＲＴＰパケットに組立てて、ＲＴＰパケットのヘッダ情報をもとにルーチング処理を行う。その際、ＲＴＰミキサ１１では、ＲＴＰストリームａとＲＴＰストリームｂとのアグリゲートを行ってＲＴＰストリームｃを生成し、ＲＴＰミキサ１２では、ＲＴＰストリームｃを分離してＲＴＰストリームａとＲＴＰストリームｂとに再び戻す。
【０１４０】
図２１において、ＲＴＰストリームａとＲＴＰストリームｂとをアグリゲートすることにより生成されたＲＴＰストリームｃに対して実行される輻輳制御方法について以下に示す。
【０１４１】
（ａ）ＲＴＰミキサ１１における、ＲＴＰストリームｃの送信速度の減少
ＲＴＰミキサ１１では、ＲＴＰミキサ１２との間でのＲＴＣＰパケットの交換により、ＲＲメッセージから得られるパケット損失数などの情報に基づき、輻輳の検知が可能となる。
【０１４２】
ＲＴＰミキサ１１では、ＲＴＰストリームａ、ＲＴＰストリームｂより受信したＲＴＰパケットをアグリゲートしてＲＴＰストリームｃとして送出する際に、送信速度を減少させることで、輻輳からの回復を図る。ＲＴＰストリームの送信速度を減少させるための手段としては、
（１）受信したＲＴＰパケットを一旦復号化し、新しいデータ送信速度に合わせて再符号化する方法、
（２）階層符号化等を用いてストリームデータを複数の階層に分けて符号化を行い、新しいデータ送信速度に応じて、復号に必要な階層のデータを含むパケットより送信する方法、
などが挙げられる。
【０１４３】
ところで、（１）に示した方法を実現するためには、ＲＴＰミキサ１１では、ＲＴＰパケットを復号化・再符号化するためのアプリケーションレイヤの処理を実行する必要がある。ＲＴＰミキサでの負荷を考慮すれば、（２）に示した、階層符号化を用いる方法が効率的な制御であると考えられる。
【０１４４】
図２３に示した例では、端末２１と、端末２２（図２３では省略している）は、それぞれ、Ｌ１、Ｌ２、Ｌ３、Ｌ４の４階層に階層符号化されたストリームデータを、ＲＴＰストリームａ、ＲＴＰストリームｂとして送信する。なお、Ｌ１はそのストリームを再生するための最低限の情報量が含まれたデータであり、それ単体でデコードすることが可能である。これに対し、Ｌ２、Ｌ３、Ｌ４は、Ｌ１と合成することで受信品質を改善することが可能なデータであり、Ｌ２、Ｌ３、Ｌ４の順で優先度が低くなる（本例の場合、Ｌ１、Ｌ１とＬ２、Ｌ１〜Ｌ３、Ｌ１〜Ｌ４の４種類がある）。
【０１４５】
図２３では、ＲＴＣＰパケットにより、ＲＴＰストリームｃの転送経路上にて輻輳が発生していることを認識したＲＴＰミキサ１１が、それまでＬ１〜Ｌ４の全てのデータを送信していたところを、Ｌ１とＬ２のデータのみをＲＴＰミキサ１２宛に送信するよう変更している。Ｌ３とＬ４のデータについては、ＲＴＰミキサ１２宛に送信せず、廃棄する。これにより、廃棄されたデータ（上記例では、Ｌ３，Ｌ４）に応じて受信側での品質が劣化するものの、ＲＴＰストリームｃの送信速度が減少され、輻輳の回復が期待される。
【０１４６】
（ｂ）ＲＴＰストリームｃを収容するＩＰアグリゲートフローに対する割り当て帯域量の増加
（ａ）に示したような、ＲＴＰミキサ１２がＲＴＰミキサ１１宛にＲＲメッセージを送信することで、ＲＴＰミキサ１１にＲＴＰストリームｃの送信速度を減少させることで輻輳からの回復を図るという制御の他に、ＩＰレイヤにおいて前記ＲＴＰストリームｃを収容するＩＰアグリゲートフローに割り当てられる帯域を増加することで、輻輳からの回復を図るという制御を、図７に示したアグリゲートＰａｔｈメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｐａｔｈ ｍｓｇ．）、アグリゲートＲｅｓｖメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｖ ｍｓｇ．）を用いて実行する。
【０１４７】
図２４に示した例では、ＲＴＣＰパケットの交換によりＲＴＰストリームｃの転送経路上に輻輳が生じていることをＲＴＰミキサ１２が認識した場合、ＲＴＰミキサ１２は、本ＲＴＰストリームｃを収容するＩＰアグリゲートフローに割り当てる帯域を増加させるよう、ＩＰレイヤにおいて、要求帯域を記載したアグリゲートＲｅｓｖメッセージを生成し、ＲＴＰミキサ１１宛へ送信する。図２４に示していないが、ＲＴＰミキサ１１とＲＴＰミキサ１２との間の全てのルータにおいて、アグリゲートＲｅｓｖメッセージに記載した要求帯域の割り当てが許容されれば、ＩＰアグリゲートフローに対する割当帯域は増加され、その結果、本ＩＰアグリゲートフローに収容されるＲＴＰストリームｃは、輻輳からの回復が可能となる。
【０１４８】
もちろん、上記（ａ）に示したＲＴＣＰパケットの交換（ＲＲメッセージの送出）に基づいたＲＴＰレベルの輻輳制御と、上記（ｂ）に示したＲｅｓｖメッセージに基づいたＩＰレベルの輻輳制御との両者を組み合わせて実行してもよい。
【０１４９】
ところで、ＩＰパケットのパケット長が異なるフロー同士をアグリゲートする場合、ＲＴＰミキサにて、その上位レイヤであるアプリケーションレイヤ処理を併せて実行することで、これらのパケット長が同一となるよう調整することが可能となる。図２５に、この場合の一例を示す。
【０１５０】
ＩＰパケット長は、ＩＰパケットを生成するＲＴＰパケット長、すなわち、アプリケーションレイヤにおける符号化速度と、ＲＴＰレイヤにおけるＲＴＰパケット生成間隔により決定される。図２５において、端末２１にて送信するアプリケーション情報を、符号化速度ｓ１、パケット生成間隔Ｔ１にて生成したＲＴＰパケットをＩＰパケット化した際のＩＰパケット長はｓ１×Ｔ１＋αにて、端末２２にて送信するアプリケーション情報を、符号化速度ｓ２、パケット生成間隔Ｔ２にて生成したＲＴＰパケットをＩＰパケット化した際のＩＰパケット長はｓ２×Ｔ２＋αにて表記できる。なお、αは、ＲＴＰヘッダ長、ＵＤＰヘッダ長、ＩＰヘッダ長の和を示す。
【０１５１】
端末２１にて生成されるＩＰパケットフローと、端末２２にて生成されるＩＰパケットフローとを共に受信するＲＴＰミキサ１１では、受信したＩＰパケットを一旦ＲＴＰパケットに変換し、さらにアプリケーションレイヤにてアプリケーション情報（例えば、アナログ音声信号）への復号化を行う。そして、両方のアプリケーション情報を、同一の符号化速度ｓ、同一のパケット生成間隔ＴにてＲＴＰパケットを生成すれば、それをＩＰパケット化した際のＩＰパケット長が共に、ｓ×Ｔ＋αと同一なものになる。これにより、前述したようにＩＰアグリゲートフローとしてのＩＰパケット処理の負荷が低減される。なお、ｓやＴは、アグリゲートされるいずれかのフローにおけるものと同じ値を用いてもよいし、それらとは異なる別の値を用いてもよい。
【０１５２】
なお、アグリゲートフローの終点であるＲＴＰミキサ１２（図２５では省略している）にて、両パケットフローを分離して各々のフローの送信先端末へ送出するが、その際に、本ＲＴＰミキサにおいて、再びアプリケーション情報への復号化を行い、当初の符号化速度、パケット生成間隔に従ったＲＴＰパケット生成、ＩＰパケット化を行う。
【０１５３】
ところで、図２５の例において、端末２１、端末２２が階層符号化を用いてＲＴＰパケットを生成している場合には、ＲＴＰミキサ１１では、アプリケーションレイヤまで遡った復号化処理等を行う必要がない。その場合のＲＴＰミキサ１１での動作例を図２６に示す。
【０１５４】
ＲＴＰミキサ１１では、受信したＩＰパケットをＲＴＰパケットに変換した後に、端末２１より送出されたＲＴＰパケットａの長さと、端末２２より送出されたＲＴＰパケットｂの長さとが同一となるよう調整する。図２６に示した例では、ＲＴＰミキサ１１にて、パケット長が長いＲＴＰパケットｂのＬ３、Ｌ４のデータを廃棄している。
【０１５５】
両ＲＴＰパケットの長さを同一とするための他の方法として、パケット長が短いＲＴＰパケットａに対してパディングを行い、両ＲＴＰパケットの長さを同一とする方法もある。
【０１５６】
上述したように、ＲＴＰパケット長が同一となれば、本ＲＴＰパケットより生成されるＩＰパケットのパケット長も同一なものとなる。
【０１５７】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１５８】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１５９】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１６０】
【発明の効果】
本発明によれば、同一なルーチング処理を施すこととなる複数のパケットフローに対しては、これらのパケットフローを束ねたアグリゲートフローを生成し、本アグリゲートフローに対するルーチング処理、帯域割当制御を行うことができる。これにより、ルーチング処理や帯域割当制御を実行するのに必要なフロー毎の情報を保持するために必要なメモリ量が削減でき、これらの情報を検索するのに要する時間の削減が可能となる。また、端末の移動に伴うフロー再設定の範囲も可能な限り狭めることが可能となり、フロー再設定に要する時間の減少が期待できる。
【図面の簡単な説明】
【図１】本発明を適用する通信網システムの一例を示す図
【図２】帯域割当方法の一例を説明するための図
【図３】アグリゲートフローについて説明するための図
【図４】アグリゲートフローを定義する方法の一例を示す図
【図５】アグリゲートフローを定義する方法の他の例を示す図
【図６】送信側端末の上位レイヤにＲＴＰパケットを搭載した場合のＩＰパケットの生成過程の概略を示す図
【図７】ＲＳＶＰにて定義されるＰａｔｈメッセージおよびＲｅｓｖメッセージの流れの概要を示す図
【図８】アグリゲートＰａｔｈメッセージ内に記載されるトラヒック特性およびアグリゲートＲｅｓｖメッセージ内に記載される要求帯域を定義する方法の一例を示す図
【図９】アグリゲートフローの端点となり得るルータの構成例を示す図
【図１０】アグリゲートフローの生成手順の一例を説明するための図
【図１１】新規ＩＰパケットフローのアグリゲートフローへの挿入手順の一例を説明するための図
【図１２】端末が移動する場合の通信網システム内のフローのルート変更の一例について説明するための図
【図１３】端末が移動する場合の通信網システム内のフローのルート変更の他の例について説明するための図
【図１４】本発明を適用する通信網システムの他の例を示す図
【図１５】収容ＩＰパケットフロー情報の一例を示す図
【図１６】図１４においてプレミアムサービス用ネットワーク内での帯域割当制御をＲＳＶＰを用いて行う方法の一例について説明するための図
【図１７】本発明を適用する通信網システムのさらに他の例を示す図
【図１８】図１７において端末が移動する場合の通信網システム内のフローのルート変更の一例について説明するための図
【図１９】ＲＴＰレベルでのパケット転送制御の概要を説明するための図
【図２０】ＲＴＰの通信シーケンスを示す図
【図２１】ＲＴＰミキサを用いたＲＴＰストリームの生成の一例を示す図
【図２２】プロトコルスタックの一例を示す図
【図２３】階層符号化を用いてＲＴＰストリームの送信速度を減少させる場合の一例を示す図
【図２４】ＲＴＣＰパケットの交換によりＩＰアグリゲートフローに割り当てる帯域を制御する場合の一例を示す図
【図２５】ＲＴＰミキサにおいてパケット長が異なるＩＰフロー同士をアグリゲートする場合の一例を示す図
【図２６】ＲＴＰミキサにおいてパケット長が異なるＩＰフロー同士をアグリゲートする場合の他の例を示す図
【図２７】従来の帯域割当方法について説明するための図
【符号の説明】
２１〜２４，５６１，５６２，６６１，６６２…端末
１１〜１９，５４１〜５４３…ルータ
５５１〜５５３，６５１〜６５６…基地局
４１…スイッチ部
４２…プロトコル処理部
４３…パケットヘッダ処理部
４４…ルーチング処理部
４５…ポート対応部
４５１…パケット受付制御部（ＰＡＣ部）
５１…プレミアムサービス用ネットワーク
５２…通常サービス用ネットワーク
６１…大規模ネットワーク
６２〜６４…小規模ネットワーク
Claims (20)
- 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
前記アグリゲートフロー用のパスとして、特定のサービスを要求する複数のパケットフローをアグリゲートするための一定の帯域を確保したパスを予め設定しておくことを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
規定すると判断した場合であっても、前記アグリゲートフロー用のパスに割り当てられた帯域が、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を下回る場合には、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスには転送しないよう制御することを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
前記アグリゲートフロー用のパスが存在する場合に、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を計算し、少なくともその算出された帯域が該パスに割り当てられるよう制御することを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフローへ収容されるパケットフローに属するパケットの自装置への到着過程を監視し、該到着過程が予め規定したアグリゲートフローのトラヒック特性に従う範囲内で、該アグリゲートフローへのパケットの流入を許可することを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
前記複数のパケットフローが、その各々を流れるパケットのパケット長が予め定められた一定の関係にあり、かつ、いずれのパケットフローにおいてもパケット転送速度は変化しない、という条件を満足するか否かに基づいて、前記アグリゲートフローとしてのトラヒック特性を規定するか否かを判断することを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
前記あるルータ装置へ転送される複数のパケットフローの各々を流れるパケットのパケット長が予め定められた一定の関係になるように、該複数のパケットフローの一部または全部についてパケット長を変えるための処理をＲＴＰレイヤレベルで行い、
このＲＴＰレイヤレベルの処理が行われたパケットフローについては、前記アグリゲートフローとしてのトラヒック特性を規定すると判断することを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフローに収容される各々のパケットフローにおけるパケットの転送速度を加算したものを該アグリゲートフローにおけるパケット転送速度として規定した場合に、前回、該アグリゲートフローへパケットを流入した時刻から今回、新たなパケットが自装置へ到着した時刻までの経過時間が、該アグリゲートフローにおけるパケット転送速度の逆数を下回らない範囲内で、パケットの該アグリゲートフローへの流入を許可することを特徴とするパケットフロー制御方法。 - 複数のルータ装置を接続して構成される通信網におけるパケットフロー制御方法において、
あるルータ装置へ転送されるパケットフローの情報を受信するステップと、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断するステップと、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送するステップとを有し、
ＩＰの上位レイヤの制御プロトコルであるＲＴＣＰ（リアルタイム転送制御プロトコル）で交換される情報に基づいて、前記アグリゲートフロー用のパスに割り当てる帯域を変更するための制御をＩＰレイヤレベルで行うことを特徴とするパケットフロー制御方法。 - 前記アグリゲートフロー用のパスの入口と出口の間に位置するルータ装置は、前記複数のパケットフローについて、前記アグリゲートフローとして規定したトラヒック特性に従って該アグリゲートフロー単位でパケット転送を制御することを特徴とする請求項１ないし８のいずれか 1 項に記載のパケットフロー制御方法。
- 受信した前記パケットフローの情報が、特定のサービスを要求するパケットフローについてのルート設定の契機となる情報である場合に、前記判断を行うことを特徴とする請求項１ないし８のいずれか 1 項に記載のパケットフロー制御方法。
- 前記アグリゲートフロー用のパスの入口の前段に位置するルータ装置は、前記特定のサービスを要求するパケットフローについてルート設定の契機となる情報を受信した場合、該情報を該パケットフローの宛先に応じた前記入口に位置するルータ装置に転送することを特徴とする請求項１０に記載のパケットフロー制御方法。
- 前記アグリゲートフロー用のパスの入口に位置するルータ装置は、該アグリゲートフロー用のパスに転送すべきパケットに、その本来のフローの識別情報の代わりとして後段のルータ装置に処理させる該アグリゲートされたフローの識別情報を与えることを特徴とする請求項１ないし８のいずれか 1 項に記載のパケットフロー制御方法。
- 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
前記アグリゲートフロー用のパスとして、特定のサービスを要求する複数のパケットフローをアグリゲートするための一定の帯域を確保したパスを予め設定しておくことを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
規定すると判断した場合であっても、前記アグリゲートフロー用のパスに割り当てられた帯域が、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を下回る場合には、前記パケットフローに属するパケットを前記アグ リゲートフロー用のパスには転送しないよう制御することを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
前記アグリゲートフロー用のパスが存在する場合に、前記アグリゲートフローとして規定したトラヒック特性に従ったパケット転送のために必要な帯域を計算し、少なくともその算出された帯域が該パスに割り当てられるよう制御することを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
前記ルータ装置は、前記アグリゲートフロー用のパスの入口に位置するものであり、該アグリゲートフローへ収容されるパケットフローに属するパケットの自装置への到着過程を監視し、該到着過程が予め規定したアグリゲートフローのトラヒック特性に従う範囲内で、該アグリゲートフローへのパケットの流入を許可することを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
前記複数のパケットフローが、その各々を流れるパケットのパケット長が予め定められた一定の関係にあり、かつ、いずれのパケットフローにおいてもパケット転送速度は変化しない、という条件を満足するか否かに基づいて、前記アグリゲートフローとしてのトラヒック特性を規定するか否かを判断することを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
前記あるルータ装置へ転送される複数のパケットフローの各々を流れるパケットのパケット長が予め定められた一定の関係になるように、該複数のパケットフローの一部または全部についてパケット長を変えるための処理をＲＴＰレイヤレベルで行い、
このＲＴＰレイヤレベルの処理が行われたパケットフローについては、前記アグリゲートフローとしてのトラヒック特性を規定すると判断することを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
前記ルータ装置は、前記アグリゲートフロー用のパスの入口に位置するものであり、該アグリゲートフローに収容される各々のパケットフローにおけるパケットの転送速度を加算したものを該アグリゲートフローにおけるパケット転送速度として規定した場合に、前回、該アグリゲートフローへパケットを流入した時刻から今回、新たなパケットが自装置へ到着した時刻までの経過時間が、該アグリゲートフローにおけるパケット転送速度の逆数を下回らない範囲内で、パケットの該アグリゲートフローへの流入を許可することを特徴とするルータ装置。 - 複数のルータ装置を接続して構成される通信網に接続されるルータ装置であって、
あるルータ装置へ転送されるパケットフローの情報を受信する手段と、
この受信した情報に基づき、前記パケットフローについて、前記あるルータ装置へ転送される複数のパケットフローを束ねることにより生成されるアグリゲートフローとしてのトラヒック特性を規定するか否かを判断する手段と、
規定すると判断した場合に、前記パケットフローに属するパケットを前記アグリゲートフロー用のパスに転送する手段とを備え、
ＩＰの上位レイヤの制御プロトコルであるＲＴＣＰ（リアルタイム転送制御プロトコル）で交換される情報に基づいて、前記アグリゲートフロー用のパスに割り当てる帯域を変更するための制御をＩＰレイヤレベルで行うことを特徴とするルータ装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22514399A JP3688525B2 (ja) | 1998-09-29 | 1999-08-09 | パケットフロー制御方法及びルータ装置 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10-276044 | 1998-09-29 | ||
| JP27604498 | 1998-09-29 | ||
| JP22514399A JP3688525B2 (ja) | 1998-09-29 | 1999-08-09 | パケットフロー制御方法及びルータ装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000174818A JP2000174818A (ja) | 2000-06-23 |
| JP3688525B2 true JP3688525B2 (ja) | 2005-08-31 |
Family
ID=26526458
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22514399A Expired - Fee Related JP3688525B2 (ja) | 1998-09-29 | 1999-08-09 | パケットフロー制御方法及びルータ装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3688525B2 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4489925B2 (ja) * | 2000-11-02 | 2010-06-23 | 富士通株式会社 | ネットワーク共有帯域割当て方法及びこれを用いるネットワークシステム |
| JP2003092577A (ja) * | 2001-09-17 | 2003-03-28 | Hitachi Kokusai Electric Inc | 無線アクセスシステム |
| WO2004032434A1 (ja) | 2002-10-02 | 2004-04-15 | Fujitsu Limited | 伝送システム |
| JP4711681B2 (ja) * | 2002-12-04 | 2011-06-29 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 階層化メディアビットストリームのパケット化 |
| CN100426733C (zh) * | 2003-01-16 | 2008-10-15 | 华为技术有限公司 | 网络通信中实现资源分配的系统及其方法 |
| US7525994B2 (en) | 2003-01-30 | 2009-04-28 | Avaya Inc. | Packet data flow identification for multiplexing |
| JP4269176B2 (ja) | 2003-08-20 | 2009-05-27 | 日本電気株式会社 | セッション中継装置及び中継方法 |
| US7447211B1 (en) | 2004-03-23 | 2008-11-04 | Avaya Inc. | Method and apparatus of establishing a communication channel using protected network resources |
| US7680100B1 (en) | 2004-09-30 | 2010-03-16 | Avaya Inc. | Internet protocol appliance manager |
| JP4491397B2 (ja) * | 2005-10-07 | 2010-06-30 | アラクサラネットワークス株式会社 | トラフィック迂回機能を備えるパケット転送装置。 |
| JP4903736B2 (ja) * | 2008-03-13 | 2012-03-28 | 三菱電機株式会社 | データ送受信装置およびデータ送受信システム |
| EP2339793B1 (en) * | 2009-12-23 | 2012-10-17 | Alcatel Lucent | Method and allocation unit for allocating a communication pipe in a communication network |
| US10798012B2 (en) | 2017-10-30 | 2020-10-06 | Cisco Technology, Inc. | Jitter elimination and latency compensation at DetNet transport egress |
-
1999
- 1999-08-09 JP JP22514399A patent/JP3688525B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000174818A (ja) | 2000-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6438123B1 (en) | Method and apparatus for supporting header suppression and multiple microflows in a network | |
| EP1722524B1 (en) | Method and apparatus for processing packet in IPv4/IPv6 combination network | |
| JP3854607B2 (ja) | Ｉｐアクセスネットワークにおいて保証サービス品質を伴うサービスを提供する方法 | |
| EP3522479B1 (en) | Techniques for efficient multipath transmission | |
| US20060133386A1 (en) | Multiprotocol convergence switch (MPCS) and method for use thereof | |
| JP4547339B2 (ja) | 送信制御機能を備えるパケット中継装置 | |
| US8031603B1 (en) | Technique for reducing resources allocated to an existing reservation in a data network | |
| US20080037425A1 (en) | Control Plane to data plane binding | |
| JP2003158543A (ja) | 中継装置及び中継方法 | |
| US6747986B1 (en) | Packet pipe architecture for access networks | |
| JP3688525B2 (ja) | パケットフロー制御方法及びルータ装置 | |
| US20060018255A1 (en) | Defining a static path through a communications network to provide wiretap law compliance | |
| US8218569B2 (en) | Apparatus and method for terminating service emulation instances | |
| CN111555982B (zh) | 一种基于IPv6扩展头的报文智能选路的方法和系统 | |
| US7724779B2 (en) | Transmission system and control method | |
| US7856021B2 (en) | Packet transfer method and apparatus | |
| US20050220059A1 (en) | System and method for providing a multiple-protocol crossconnect | |
| US7277944B1 (en) | Two phase reservations for packet networks | |
| JP4742072B2 (ja) | シェーピング装置およびルータ装置 | |
| WO2009132500A1 (zh) | 层次化有序地址分组网络中数据链路层信息传送和控制管理的方法及装置 | |
| JP4209340B2 (ja) | マルチプレクサの発見とパラメータの交換。 | |
| KR100585934B1 (ko) | 라우터에서의 트래픽 조절기의 파라미터 및 서비스 클래스정의 규칙 테이블의 동적 관리 방법 | |
| JP2004241835A (ja) | 品質保証型データストリームを転送するための受付判定方法、閉域ｉｐ網、そのプログラム | |
| WO2006042470A1 (fr) | Procede de transmission equitable de flux dans un reseau local en boucle mpls | |
| JP2004166080A (ja) | パケットシェーパ、パケット中継装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041201 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041207 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050531 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050608 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090617 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090617 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100617 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100617 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110617 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |