JP2000174818A - パケットフロ―制御方法及びル―タ装置 - Google Patents

Abstract

(57)【要約】 【課題】 ルーチング処理や帯域割当制御等を実行する
のに必要なフロー毎の情報を保持するために必要なメモ
リ量の削減や、これらの情報を検索するのに要する時間
の削減が可能なパケットフロー制御方法を提供するこ
と。 【解決手段】 複数のルータ装置を接続して構成される
通信網におけるパケットフロー制御方法において、ある
ルータ装置へ転送されるパケットフローの情報を受信
し、この受信した情報に基づき、該パケットフローにつ
いて、該あるルータ装置へ転送される複数のパケットフ
ローを束ねることにより生成されるアグリゲートフロー
としてのトラヒック特性を規定するか否かを判断し、規
定すると判断した場合に、該パケットフローに属するパ
ケットを該アグリゲートフロー用のパスに転送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のルータ装置
を接続することにより構成される通信網におけるパケッ
トフロー制御方法及びルータ装置に関する。

【０００２】

【従来の技術】近年、ＩＰ（インターネットプロトコ
ル）を用いた通信網、いわゆるインターネットにおい
て、転送遅延値やＩＰパケット廃棄率といった、転送品
質の保証を可能とするための技術が注目されている。こ
れは、従来のインターネットはベストエフォート型の通
信網と呼ばれており、例えば中継ノード（ルータ等）に
トラヒックが集中した場合、中継ノードは最善の努力に
てＩＰパケットの処理を試みるが、処理しきれなくなれ
ば、ＩＰパケットの廃棄が発生してしまうため、転送品
質の保証が不可能であったためである。

【０００３】インターネットにおいて転送品質の保証が
可能な通信を提供するための技術として、ＲＳＶＰと呼
ばれる資源予約プロトコルがＩＥＴＦ（Ｉｎｔｅｒｎｅ
ｔＥｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）に
て提案されている。ＲＳＶＰでは、送信側端末より受信
側端末に対して、送信するＩＰパケットフローのトラヒ
ック特性を記載したメッセージ（Ｐａｔｈメッセージ）
を受信側端末宛に送信する。受信側端末では、希望する
転送品質を記載したメッセージ（Ｒｅｓｖメッセージ）
を送信側端末宛に送信する。中継ノードでは、Ｒｅｓｖ
メッセージを受信すれば、予め受信したＰａｔｈメッセ
ージに記載されていたトラヒック特性をもとに、Ｒｅｓ
ｖメッセージ内に記載された転送品質の提供が可能か否
かを、現在の残余帯域量をもとに判断し、転送品質の提
供が可能であれば、必要な帯域を当該フローに対して確
保した後に、Ｒｅｓｖメッセージをさらに上流へ転送す
る。Ｒｅｓｖメッセージが送信側端末に到達すれば、当
該フローに対する帯域がインターネット上に確保された
ことを意味するので、以降では、希望する転送品質が保
証される、ＩＰパケットの転送サービスが可能となる。

【０００４】上述したような、フロー毎の転送品質の保
証を可能とするＩＰパケットの転送サービスを実現する
ためには、例えば、各々のルータにおいて、ＩＰパケッ
トに対するルーチングポリシーをフロー毎に規定し、当
該ルーチングポリシーに従ったルーチング処理を施す必
要がある。ルーチングポリシーとして規定すべき内容と
しては、例えば、フローに属するＩＰパケットの送信先
ポート、他のフローとの間でのスケジューリング手段、
等が挙げられ、ルーチング表としてルータ内に記憶され
る。

【０００５】この場合、処理すべきフロー数が多いルー
タにおいては、フローに対応して記憶すべきルーチング
ポリシーも多くなるため、ルーチング表は巨大なものと
なってしまい、本表を記憶するために費すメモリ規模が
大きくなってしまう。また、ルーチング表が巨大になっ
てしまうと、到着したＩＰパケットのフローに対応する
ルーチングポリシーの検索に要する時間も大きくなり、
その結果、ルータ内でのルーチング処理に要する時間が
大きくなってしまう。

【０００６】ここで、図２７を参照しながら従来の帯域
割り当て方法について説明する。

【０００７】図２７（ａ）に示した通信網システムにお
いて、端末１０２１より端末１０２３宛に送信されるＩ
Ｐパケットフロー（フローａとする）と、端末１０２２
より端末１０２４宛に送信されるＩＰパケットフロー
（フローｂとする）とに対し、上述したＲＳＶＰにより
帯域が確保された様子を、図２７（ｂ）に示す。図２７
（ｂ）において、１０４１がフローａに対して確保され
た帯域（フローａに対するパスと呼ぶ）、１０４２がフ
ローｂに対して確保された帯域（フローｂに対するパス
と呼ぶ）である。なお、フローａ、フローｂ共に、ルー
タ１０１１とルータ１０１２との間に設定されるパスの
ルート、希望する転送品質は同一であるものとする。

【０００８】図２７のような帯域確保（パス設定）を行
った場合、フローａ、フローｂ共に、ルータ１０１１を
発したＩＰパケットは、同一ルートを通ってルータ１０
１２に転送されるので、ルータ１０１１とルータ１０１
２との間に位置する各々のルータでは、フローａに属す
るＩＰパケット、フローｂに属するＩＰパケットに対し
て施すルーチング処理は、同一なものとなる。しかしな
がら、実際は、これらのＩＰパケットが属するフローは
異なるため、これらのルータにて保持するルーチング表
においては、同一なルーチングポリシーであるにも関わ
らず、別々のエントリとして記載されてしまう。図２７
では、同一ルートを通過するフローが２種類ある場合を
図示しているが、同一ルートを通過するフロー数がさら
に多くなった場合、これによるルーチング表の巨大化に
よるメモリ規模の増大、ルーチングポリシーの検索に要
する時間の増大は無視できないものとなる。

【０００９】新たな問題として、図２７の端末１０２１
の移動に伴い、端末１０２１を収容するルータがルータ
１０１３でなくなった状況を考える。この場合、移動前
にフローａを収容していたパス１０４１は解放され、フ
ローａを収容する新たなパスを、端末１０２１と端末１
０２３との間にて設定することとなる。このようなパス
の再設定が行われている間は、端末１０２１より端末１
０２３宛に送出されるＩＰパケットの転送は一旦中断し
てしまい、これによる転送品質の低下は無視できない。

【００１０】

【発明が解決しようとする課題】従来、フロー毎の転送
品質の保証を可能とするＩＰパケットの転送サービスを
実現するためには、例えば、各々のルータにおいてＩＰ
パケットに対するルーチングポリシーをフロー毎に規定
し当該ルーチングポリシーに従ったルーチング処理を施
す必要があるため、ルーチングポリシーの情報を記憶す
るために費すメモリ規模が大きくなってしまうという問
題があった。また、到着したＩＰパケットのフローに対
応するルーチングポリシーの検索に要する時間も大きく
なり、その結果、ルータ内でのルーチング処理に要する
時間が大きくなってしまうという問題があった。また、
新たな問題として、端末の移動に伴ってパスの再設定が
行われている間、その端末より送出されるＩＰパケット
の転送は一旦中断してしまい、これによる転送品質の低
下が無視できないという問題があった。

【００１１】本発明は、上記事情を考慮してなされたも
ので、ルーチング処理や帯域割当制御等を実行するのに
必要なフロー毎の情報を保持するために必要なメモリ量
の削減や、これらの情報を検索するのに要する時間の削
減を可能とするパケットフロー制御方法及びルータ装置
を提供することを目的とする。

【００１２】また、本発明は、端末の移動に伴うフロー
再設定の範囲を可能な限り狭めることのできるパケット
フロー制御方法及びルータ装置を提供することを目的と
する。

【００１３】

【課題を解決するための手段】本発明（請求項１）は、
複数のルータ装置を接続して構成される通信網（例え
ば、ＩＰ（インターネットプロトコル）を用いた通信
網）におけるパケットフロー制御方法において、あるル
ータ装置へ転送されるパケット（例えば、ＩＰパケッ
ト）フローの情報を受信し、この受信した情報に基づ
き、前記パケットフローについて、前記あるルータ装置
へ転送される複数のパケットフローを束ねることにより
生成されるアグリゲートフローとしてのトラヒック特性
を規定するか否かを判断し、規定すると判断した場合
に、前記パケットフローに属するパケットを前記アグリ
ゲートフロー用のパスに転送することを特徴とする。

【００１４】好ましくは、前記アグリゲートフロー用の
パスの入口と出口の間に位置するルータ装置は、前記複
数のパケットフローについて、前記アグリゲートフロー
として規定したトラヒック特性に従って該アグリゲート
フロー単位でパケット転送を制御するようにしてもよ
い。

【００１５】好ましくは、受信した前記パケットフロー
の情報が、特定のサービスを要求するパケットフローに
ついてのルート設定の契機となる情報である場合に、前
記判断を行うようにしてもよい。

【００１６】好ましくは、前記アグリゲートフロー用の
パスの入口の前段に位置するルータ装置は、前記特定の
サービスを要求するパケットフローについてルート設定
の契機となる情報を受信した場合、該情報を該パケット
フローの宛先に応じた前記入口に位置するルータ装置に
転送するようにしてもよい。

【００１７】好ましくは、前記アグリゲートフロー用の
パスとして、特定のサービスを要求する複数のパケット
フローをアグリゲートするための一定の帯域を確保した
パス（例えば、プレミアムサービス用のパス）を予め設
定しておくようにしてもよい。

【００１８】好ましくは、規定すると判断した場合であ
っても、前記アグリゲートフロー用のパスに割り当てら
れた帯域が、前記アグリゲートフローとして規定したト
ラヒック特性に従ったパケット転送のために必要な帯域
を下回る場合には、前記パケットフローに属するパケッ
トを前記アグリゲートフロー用のパスには転送しないよ
う制御するようにしてもよい。

【００１９】好ましくは、前記アグリゲートフロー用の
パスが存在しない場合に、前記アグリゲートフローとし
て規定したトラヒック特性に従ったパケット転送のため
に必要な帯域を少なくとも割り当てて該パスを設定する
ようにしてもよい。

【００２０】好ましくは、前記アグリゲートフロー用の
パスが存在する場合に、前記アグリゲートフローとして
規定したトラヒック特性に従ったパケット転送のために
必要な帯域を計算し、少なくともその算出された帯域が
該パスに割り当てられるよう制御するようにしてもよ
い。

【００２１】好ましくは、前記アグリゲートフロー用の
パスの入口に位置するルータ装置は、該アグリゲートフ
ロー用のパスに転送すべきパケットに、その本来のフロ
ーの識別情報の代わりとして後段のルータ装置に処理さ
せる該アグリゲートされたフローの識別情報を与えるよ
うにしてもよい。

【００２２】好ましくは、前記アグリゲートフロー用の
パスの入口に位置するルータ装置は、該アグリゲートフ
ローへ収容されるパケットフローに属するパケットの自
装置への到着過程を監視し、該到着過程が予め規定した
アグリゲートフローのトラヒック特性に従う範囲内で、
該アグリゲートフローへのパケットの流入を許可するよ
うにしてもよい。

【００２３】好ましくは、前記複数のパケットフロー
が、その各々を流れるパケットのパケット長が予め定め
られた一定の関係（例えば、全て同一の値）にあり、か
つ、いずれのパケットフローにおいてもパケット転送速
度は変化しない、という条件を満足するか否かに基づい
て、前記アグリゲートフローとしてのトラヒック特性を
規定するか否かを判断するようにしてもよい。

【００２４】好ましくは、前記複数のパケットフロー
が、ＩＰ（インターネットプロトコル）の上位レイヤの
転送プロトコルであるＲＴＰ（リアルタイム転送プロト
コル）により生成されたＲＴＰパケットがＩＰによりパ
ケット化されることにより得られたパケットフローであ
るか否かに基づいて、前記アグリゲートフローとしての
トラヒック特性を規定するか否かを判断するようにして
もよい。

【００２５】好ましくは、前記あるルータ装置へ転送さ
れる複数のパケットフローの各々を流れるパケットのパ
ケット長が予め定められた一定の関係になるように、該
複数のパケットフローの一部または全部についてパケッ
ト長を変えるための処理をＲＴＰレイヤレベルで行い、
このＲＴＰレイヤレベルの処理が行われたパケットフロ
ーについては、前記アグリゲートフローとしてのトラヒ
ック特性を規定すると判断するようにしてもよい。

【００２６】好ましくは、前記アグリゲートフロー用の
パスの入口に位置するルータ装置は、該アグリゲートフ
ローに収容される各々のパケットフローにおけるパケッ
トの転送速度を加算したものを該アグリゲートフローに
おけるパケット転送速度として規定した場合に、前回、
該アグリゲートフローへパケットを流入した時刻から今
回、新たなパケットが自装置へ到着した時刻までの経過
時間が、該アグリゲートフローにおけるパケット転送速
度の逆数を下回らない範囲内で、パケットの該アグリゲ
ートフローへの流入を許可するようにしてもよい。

【００２７】好ましくは、ＩＰの上位レイヤの制御プロ
トコルであるＲＴＣＰ（リアルタイム転送制御プロトコ
ル）で交換される情報に基づいて、前記アグリゲートフ
ロー用のパスに割り当てる帯域を変更するための制御を
ＩＰレイヤレベルで行うようにしてもよい。

【００２８】本発明（請求項１６）は、複数のルータ装
置を接続して構成される通信網に接続されるルータ装置
であって、あるルータ装置へ転送されるパケットフロー
の情報を受信する手段と、この受信した情報に基づき、
前記パケットフローについて、前記あるルータ装置へ転
送される複数のパケットフローを束ねることにより生成
されるアグリゲートフローとしてのトラヒック特性を規
定するか否かを判断する手段と、規定すると判断した場
合に、前記パケットフローに属するパケットを前記アグ
リゲートフロー用のパスに転送する手段とを備えたこと
を特徴とする。

【００２９】本発明（請求項１７）は、複数のルータ装
置を接続して構成され、特定のサービスを要求する複数
のパケットフローをアグリゲートするための一定の帯域
を確保したパスが部分的に予め設定されている通信網
に、接続されるルータ装置であって、前記特定のサービ
スを要求するパケットフローについてルート設定の契機
となる情報を受信する手段と、この情報を、前記パケッ
トフローの宛先に応じた前記パスの入口に位置するルー
タ装置に転送して前記パスを利用したルート設定を行わ
せる手段と、受信したパケットが前記特定のサービスを
要求するパケットフローに属する場合には、該パケット
を前記パスの入口に位置するルータ装置へ転送し、属さ
ない場合には、該パケットを前記パスを利用せずに前記
パケットフローの宛先へ向けて転送するルータ装置へ転
送する手段とを備えたことを特徴とする。

【００３０】なお、装置に係る本発明は方法に係る発明
としても成立し、方法に係る本発明は装置に係る発明と
しても成立する。

【００３１】また、装置または方法に係る本発明は、コ
ンピュータに当該発明に相当する手順を実行させるため
の（あるいはコンピュータを当該発明に相当する手段と
して機能させるための、あるいはコンピュータに当該発
明に相当する機能を実現させるための）プログラムを記
録したコンピュータ読取り可能な記録媒体としても成立
する。

【００３２】本発明によれば、同一なルーチング処理を
施すこととなる複数のパケットフローに対しては、これ
らのパケットフローを束ねたアグリゲートフローを生成
し、本アグリゲートフローに対するルーチング処理、帯
域割当制御を行うことができる。これにより、ルーチン
グ処理や帯域割当制御を実行するのに必要なフロー毎の
情報を保持するために必要なメモリ量が削減でき、これ
らの情報を検索するのに要する時間の削減が可能とな
る。また、端末の移動に伴うフロー再設定の範囲も可能
な限り狭めることが可能となり、フロー再設定に要する
時間の減少が期待できる。

【００３３】

【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。

【００３４】図１は、本発明の適用対象となる通信網シ
ステムの一例である。

【００３５】図１では、端末２１はルータ１３と、端末
２２はルータ１４と、端末２３はルータ１６と、端末２
４はルータ１８と、無線回線を介して各々接続されてい
る。また、ルータ１３、ルータ１４、ルータ１５はルー
タ１１と、ルータ１６、ルータ１７、ルータ１８はルー
タ１２と、有線回線を介して各々接続されている。さら
に、ルータ１１とルータ１２は、直接接続されている
か、もしくは一つ以上のルータを介して接続されてい
る。

【００３６】なお、図１において有線回線にて接続され
ている部分の全部または一部を無線回線に置き換えて接
続した通信網システムや、無線回線にて接続されている
部分の全部または一部を有線回線に置き換えて接続した
通信網システムも、本発明の適用対象としてもよい。

【００３７】図１に示した通信網システムにおいて、Ｉ
Ｐ（インターネットプロトコル）による通信を提供する
場合の帯域割当方法について説明する。

【００３８】なお、以下では、端末２１と端末２３、端
末２２と端末２４とが各々通信を行うものとし、端末２
１と端末２２が送信側端末、端末２３と端末２４が受信
側端末であるものとする。また、端末２１より端末２３
宛へのパケットフローをフローａ、端末２２より端末２
４宛へのパケットフローをフローｂとし、フローａは、
（端末２１）→ルータ１３→ルータ１１→…→ルータ１
２→ルータ１６→（端末２３）のルートを通るものと
し、フローｂは、（端末２２）→ルータ１４→ルータ１
１→…→ルータ１２→ルータ１８→（端末２３）のルー
トを通るものとする。

【００３９】図１に示した通信網システムにおける、フ
ローａ、フローｂに対する帯域割当の方法としては、従
来の方法である図２７のような、フローａ、フローｂの
個々に対して帯域を別々に割り当てる方法の他に、ルー
タ１１とルータ１２との間では、フローａとフローｂが
共に同一ルートを通っている点に着目した、図２に示す
ような帯域割当方法を考えることができる。

【００４０】図２においては、フローａに対する帯域割
当を、端末２１よりルータ１３を介してルータ１１宛の
ルート（パス３１）、ルータ１１よりルータ１２宛のル
ート（パス３５）、ルータ１２よりルータ１６を介して
端末２３宛のルート（パス３２）の３つに分割して行
う。また、フローｂに対する帯域割当を、端末２２より
ルータ１４を介したルータ１１宛のルート（パス３
３）、ルータ１１よりルータ１２宛のルート（パス３
５）、ルータ１２よりルータ１８を介した端末２４宛の
ルート（パス３４）の３つに分割して行う。

【００４１】図２において、パス３５はフローａ、フロ
ーｂの両フローを収容している。その際に、パス３５の
入側ルータ１１において両フローを束ねて、パス３５内
においては、フローａ、フローｂの区別なく、同一のフ
ローとして認識できるようにする。以下、この動作を
「フローのアグリゲート」と呼び、一定の区間内（パス
３５内）において定義される複数のフローを束ねて生成
したフローを「アグリゲートフロー」と呼ぶ。図３に、
パス３５内におけるフローａ、フローｂのアグリゲート
の様子を示す。

【００４２】図３に示すように、同一ルートを通過する
複数のフローをアグリゲートすれば、パス３５上に存在
するルータでは、到着したパケットがフローａ、フロー
ｂのいずれのフローに属しているかを判断する必要がな
く、一つのアグリゲートフローとして、到着パケットの
ルーチング処理、割当帯域に対する品質保証制御を行え
ばよい。アグリゲートフローを用いたＩＰパケット処理
を行うことで、従来のように個々のフロー毎にルーチン
グ処理や品質保証制御を行う方法に比べて、各々のルー
タにおいて識別すべきフロー数の減少がもたらされ、こ
れは、転送先となる出力ポートや割当帯域といった、各
々のルータにおいてフロー毎に記憶すべき情報量の減少
につながる。これにより、各々のルータにおいて、前記
情報を保持するために必要となるメモリ量の削減、ＩＰ
パケットのフローに対応する前記情報の検索に要する時
間の削減が可能となる。これらの効果は、アグリゲート
フローとして束ねるフロー数が増大すると、さらに大き
くなる。以上の点において、図３に示す方法は、図２７
に示したフローａ、フローｂの各々に別個のパスを提供
し、帯域割当を行う従来の方法に比べ、効果的であるこ
とが分かる。

【００４３】アグリゲートフローを用いた通信を実現す
る際には、アグリゲートフローの始点であるルータ１１
では、複数のフロー（本具体例では、フローａとフロー
ｂ）を束ねて新たなアグリゲートフローを生成するため
の機能（フロー統合機能）、そしてアグリゲートフロー
の終点であるルータ１２では、アグリゲートフローを分
離し、アグリゲートフローへの挿入前の各々のフローを
再び形成するための機能（フロー分離機能）が必要とな
る。

【００４４】パス３５内にてアグリゲートフローを定義
する方法としては、例えば次の２つの方法を挙げること
ができる。

【００４５】（１）パケットのカプセル化による方法 図４に示すように、アグリゲートフローの始点であるル
ータ１１において、アグリゲートフロー内に挿入するＩ
Ｐパケットの先頭に、アグリゲートフローを識別するた
めのＩＰパケットヘッダを付与し、パス３５内のみにて
定義される、アグリゲートフロー用の新たなＩＰパケッ
トを生成する。パス３５内のルータは、新たに付与され
たＩＰパケットヘッダに基づきルーチング処理を行う。
つまり、本来のフローのヘッダ（フローａに属するＩＰ
パケットのヘッダ、フローｂに属するＩＰパケットのヘ
ッダ）は、パス３５内ではペイロードの一部として位置
付けられ、ルーチング処理の際には参照されない。付与
されたＩＰパケットヘッダは、アグリゲートフローの終
点であるルータ１２において除去され、以後では、本来
のフローのヘッダを参照したルーチング処理が行われ
る。

【００４６】本方法を用いることで、アグリゲートフロ
ー内では、収容された各々のフローを意識しないルーチ
ング処理が可能となる。

【００４７】（２）フロー識別子（フローラベル）の変
換による方法 本方法では、アグリゲートフロー内にＩＰパケットを挿
入する際に、当該パケットがアグリゲートフローに属す
ることを示すよう、アグリゲートフローの始点であるル
ータ１１にて、ＩＰパケット内に記されている、当該パ
ケットが属するフローを表すフロー識別子を、当該パケ
ットがアグリゲートフロー内に属する旨を表すフロー識
別子に変換する。そして、アグリゲートフローの終点で
あるルータ１２にて、変換したフロー識別子を本来のも
のに戻す。

【００４８】図５に、ＩＰパケットフォーマットとして
ＩＰｖ６（ＩＰバージョン６）を採用した場合の、フロ
ー識別子の変換例を示す。ＩＰｖ６では、ヘッダ内にフ
ローラベルと呼ばれる、フローを識別するために送信側
端末が記載する２８ビット長のフィールドが定義され
る。そこで、図５では、フローラベルとソースアドレス
（１２８ビット長）との組をフロー識別子として扱った
場合の変換例を示している。

【００４９】アグリゲートフローの始点であるルータ１
１では、到着したＩＰパケットが、アグリゲートフロー
に挿入すべきものか否かを、当該パケットのフローラベ
ルとソースアドレスとを調べることにより判断する。そ
の際に、ルータ１１はフローラベル変換表を用いる。本
表は、アグリゲートフロー内に挿入すべきＩＰパケット
の、フローラベルとソースアドレスの組（フロー識別
子）と、アグリゲートフローへの挿入時に置き換えられ
るフローラベルとを対応づけて構成される。なお、図５
においては、フローラベルを１６進数表記しており、ソ
ースアドレスは、送信端末の番号（便宜上、図１〜図３
の端末に付した参照符号と同じ値であるとした）をその
ままアドレスとして用いている。端末として移動端末を
サポートする場合には、本表に記載するソースアドレス
は、移動端末に割り当てられたホームアドレスを記載す
ることが望ましい。

【００５０】図５の例では、ソースアドレス「２１」よ
り送信された、フローラベルが「０１２３４５６」であ
るＩＰパケット（フローａに属するＩＰパケット）につ
いては、フローラベルを「０００１０１２」と変換して
からアグリゲートフロー内に挿入し、ソースアドレス
「２２」より送信された、フローラベルが「１２３４５
６７」であるパケット（フローｂに属するＩＰパケッ
ト）については、フローラベルを「０００２０１２」と
変換してアグリゲートフロー内に挿入している。

【００５１】パス３５内のルータでは、到着したＩＰパ
ケットのフローラベルを参照して、当該パケットがアグ
リゲートフローに収容されているパケットであるか否か
を判断する。ＩＰパケットがアグリゲートフローに属す
る旨を示すフローラベルを保持していれば、パス３５内
のルータは、アグリゲートフローとしてのルーチング処
理を施し、アグリゲートフローに属する旨を示すフロー
ラベルを保持していなければ、通常通りのルーチング処
理を施す。フローラベルに基づくルーチング処理の切替
を行うため、パス３５内のルータは、アグリゲートフロ
ーを表すフローラベルを全て記憶する必要がある。

【００５２】アグリゲートフローの終点であるルータ１
２では、到着したＩＰパケットが、アグリゲートフロー
に属するものであれば、当該パケットのフローラベルと
ソースアドレスとに基づき、フローラベル変換表を用い
て、フローラベルを当初のフローラベル値に戻す。出側
ルータにて保持するフローラベル変換表は、アグリゲー
トフローラベルとソースアドレスの組と、当初のフロー
ラベルとを対応づけて構成される。

【００５３】なお、パス３５内のルータにて、到着した
ＩＰパケットがアグリゲートフローに属するパケットで
あるか否かの判断を容易に行えるようにするため、例え
ば、２８ビットからなるフローラベルの指定したフィー
ルドの値を、アグリゲートフローに属するＩＰパケット
に対しては同一値となるように、フローラベルの変換を
行う。これにより、到着したＩＰパケットのフローラベ
ルのうち当該フィールドの値のみを調べれば、本パケッ
トがアグリゲートフローに属するかを判断することが可
能となる。図５の例では、アグリゲートフローに挿入す
るＩＰパケットに対して、下位１２ビットの値が「０１
２」という値をとるようにフローラベルを割り当ててお
り、本例の場合、パス３５内のルータでは、フローラベ
ル内の下位１２ビットを参照するだけで、アグリゲート
フローとしてのルーチング処理を行うか否かを判断でき
る。

【００５４】上に示したパケットのカプセル化によりア
グリゲートフローを定義する方法、フロー識別子（フロ
ーラベル）の変換によりアグリゲートフローを定義する
方法の他にも、種々の方法が考えられ、例えば、ＭＰＬ
Ｓ（マルチプロトコルラベルスイッチング）を実行可能
なルータにて構成された通信網システムである場合に
は、「ラベル」値を利用してアグリゲートフローを定義
する方法を用いてもよい。

【００５５】なお、複数のアグリゲートフローを設定す
る場合には、各ＩＰパケットがどのアグリゲートフロー
に属するものかを特定することが必要となる。この場
合、例えば、図４の例においては、もとのＩＰパケット
の外側に新たにアグリゲート用のヘッダを付与したが、
このアグリゲート用のヘッダ内にある何らかの情報か
ら、アグリゲートフローを特定可能とすればよい。ま
た、例えば、図５の例では、アグリゲートフローに挿入
するＩＰパケットに対して、下位１２ビットの値が「０
１２」という値をとるようにフローラベルを割り当た
が、アグリゲートフローに挿入するＩＰパケットに対し
て割り当てる下位１２ビットの値の範囲を定め、その値
の違いによりアグリゲートフローを特定可能とすればよ
い。

【００５６】ところで、アグリゲートフローに挿入可能
なＩＰパケットフローは、例えば、プレミアムサービス
を要求する音声データをＩＰパケット化したフローに限
定するようにしてもよい。また、その際に、その音声デ
ータは、ＩＰの上位レイヤの転送プロトコルであるＲＴ
Ｐ（リアルタイム転送プロトコル）により生成されたパ
ケット（ＲＴＰパケット）をＩＰパケット化して転送さ
れるものとしてもよい。

【００５７】以下、このようにした場合について説明す
る。

【００５８】図６に、送信側端末の上位レイヤにＲＴＰ
パケットを搭載した場合の、ＩＰパケットの生成過程の
概略を示す。ＲＴＰでは、一定時間Ｔ毎に、当該時間内
に生成されたアプリケーションデータを抽出してＲＴＰ
パケットを生成する。このとき、データが挿入されなか
ったペイロード領域をパディングすることで、ＲＴＰレ
ベルでは、上記時間Ｔにて定まる固定長ＬのＲＴＰパケ
ットを常に生成することとなる。本ＲＴＰパケットを、
ＵＤＰ（ユーザデータグラムプロトコル）レベルの処理
を介した後にＩＰレベルに引き渡し、ＩＰパケットの生
成を行う。図６より明らかなように、送信側端末の上位
レイヤにＲＴＰパケットを搭載した場合、当該端末より
送出されるＩＰパケットは常に固定長のパケットとな
る。

【００５９】なお、ＲＴＰ、ＵＤＰを介した後に生成さ
れたＩＰパケット（ＩＰ／ＵＤＰ／ＲＴＰパケット）の
オーバーヘッドである、各々のプロトコルレベルにて規
定されるヘッダ部分を圧縮させた後に、通信網上へ送出
するという方法を用いてもよい。具体的には、コンテキ
スト識別子（ＣＩＤ）と圧縮前のパケットのヘッダ内容
とを対応させて覚えておき、同一のヘッダ内容を持つパ
ケットを引続き送信する時には、当該パケット内のＵＤ
Ｐヘッダ部、ＲＴＰヘッダ部を圧縮すると同時に前記Ｃ
ＩＤをパケット内に含ませてから送信し、相手先にて、
ＣＩＤを用いてヘッダ部の復元を行う。

【００６０】アグリゲートフローに収容されるＩＰパケ
ットフローが全て、図６に示すように一定時間Ｔ毎に生
成されるＲＴＰパケットをＩＰパケット化したものであ
れば、当該アグリゲートフローに収容されるＩＰパケッ
トは全て同一パケット長であり、かつ、各々のＩＰパケ
ットフローにおいては、一定速度にてパケット転送が行
われるため、アグリゲートフローのトラヒック特性は、
各々のＩＰパケットにおけるパケット転送速度の総和を
用いて容易に表すことができる。

【００６１】また、アグリゲートフローに収容されるＩ
Ｐパケットのパケット長が全てのフローにおいて同一で
あれば、例えばアグリゲートフローが通過するルータに
おいて、品質保証制御を目的として当該アグリゲートフ
ローのＩＰパケット転送速度の監視を行う場合、前記ル
ータではＩＰパケットの到着時刻のみを把握するだけで
よく、パケット長に関する情報は（全て同一であるの
で）把握する必要がないため、ルータにおけるＩＰパケ
ット処理のさらなる低減が可能となる。

【００６２】なお、アグリゲートフローに収容されるＩ
Ｐパケットフローが全てＲＴＰパケットをＩＰパケット
化したものであっても、ＲＴＰパケットを生成する時間
間隔が送信側端末毎に異なった場合には、当該アグリゲ
ートフローに収容されるＩＰパケットは全て同一パケッ
ト長とはならない。つまり、ＩＰパケットフロー毎に、
転送されるＩＰパケットのパケット長が異なるというこ
とを意味する。このような場合でもアグリゲートフロー
によるＩＰパケット処理は実行可能であるが、各々のル
ータにおいては、アグリゲートフローを転送されるＩＰ
パケットのパケット長を考慮したパケット処理を実行す
る必要がある。

【００６３】このようなアグリゲートフローに対する帯
域割当制御、アグリゲートフローの始点にて実行する、
アグリゲートフローへのＩＰパケットの受付制御の一例
を、以下に示す。

【００６４】（１）帯域割当制御 帯域割当用プロトコルとして、ＲＳＶＰ（リソース予約
プロトコル）を用いた場合を例にとり、説明する。

【００６５】図７に、ＲＳＶＰにて定義されるＰａｔｈ
メッセージ（Ｐａｔｈ ｍｓｇ．）、Ｒｅｓｖメッセー
ジ（Ｒｅｓｖ ｍｓｇ．）の流れの概要を示す。なお、
Ｐａｔｈメッセージは、ＩＰパケットフローのトラヒッ
ク特性を記載して、送信側端末より受信側端末へ送出
し、Ｒｅｓｖメッセージは、ＩＰパケットフローに対す
る予約要求内容を記載して、受信側端末より送信側端末
へ送出する。

【００６６】図７に示すように、アグリゲートフローの
始点であるルータ１１では、当該フローに収容される全
てのフローのＰａｔｈメッセージに基づいてアグリゲー
トＰａｔｈメッセージを生成する。また、アグリゲート
フローの終点であるルータ１２では、当該フローに収容
される全てのフロー（図７では、Ｆｌｏｗ−ａとＦｌｏ
ｗ−ｂ）のＲｅｓｖメッセージに基づいてアグリゲート
Ｒｅｓｖメッセージを生成する。パス３５内のＲＳＶＰ
対応ルータでは、アグリゲートＰａｔｈメッセージ（Ａ
ｇｇｒｅｇａｔｅｄ Ｐａｔｈ ｍｓｇ．）、アグリゲ
ートＲｅｓｖメッセージ（Ａｇｇｒｅｇａｔｅｄ Ｒｅ
ｓｖ ｍｓｇ．）に基づいて、アグリゲートフローに対
する帯域割当制御を行う。

【００６７】なお、アグリゲートフローに収容される個
々のフローのＰａｔｈメッセージ、Ｒｅｓｖメッセージ
も、アグリゲートフロー内に収容するが、これらの制御
メッセージは、パス３５内のＲＳＶＰ対応ルータにおい
て、ＲＳＶＰ規定の処理が行われないようにする必要が
ある。つまり、これら個々のフローにおける制御メッセ
ージは、一つのデータパケットと認識されるようにアグ
リゲートフロー内に収容すべきである。例えば、これら
の制御メッセージの先頭に、アグリゲートフローを識別
するためのＩＰパケットヘッダを付与して、制御メッセ
ージ内容を隠蔽する方法（図４を参照）、または、フロ
ーラベルの変換後の値に基づいて、アグリゲートＰａｔ
ｈメッセージと個々のフローのＰａｔｈメッセージの区
別、アグリゲートＲｅｓｖメッセージと個々のフローの
Ｒｅｓｖメッセージの区別を行う方法（図５を参照）な
どにより、実現可能である。

【００６８】このとき、上位レイヤにＲＴＰを用いて生
成されたＩＰパケットフローのみをアグリゲートする場
合、各々のフロー内にて生成されるＰａｔｈメッセージ
内に記載されるトラヒック特性は、図６にて示したＲＴ
Ｐパケットの生成間隔Ｔにより決定されるＩＰパケット
の転送速度のみで規定可能であるため、アグリゲートＰ
ａｔｈメッセージ内に記載されるトラヒック特性は、各
々のＰａｔｈメッセージ内に記載されているパケット転
送速度の総和にて定義することが可能である。図８の例
では、フローａ、フローｂが各々５Ｍｂｐｓの速度にて
送信されるトラヒックフローをアグリゲートするので、
アグリゲートフローのパケット転送速度は、１０Ｍｂｐ
ｓと容易に規定することができる（図８（ａ））。Ｒｅ
ｓｖメッセージのアグリゲートも同様に、要求帯域の総
和をアグリゲートフローに対して予約すればよい（図８
（ｂ））。

【００６９】アグリゲートフローに割り当てる帯域を、
生成したアグリゲートＲｅｓｖメッセージ内の要求帯域
に等しく割り当てる方法の他に、収容される個々のフロ
ーが要求する要求帯域に関わらず、予め通信網システム
（アグリゲートフローの終端点となるルータ）において
取り決めておいた帯域を割り当てる方法を用いてもよ
い。この場合は、上述したように、アグリゲートＰａｔ
ｈメッセージ、アグリゲートＲｅｓｖメッセージを用い
た、動的な帯域割当を実行する必要はない。また、新た
なフローをアグリゲートフローとして収容することで、
必要となる帯域が予め割り当てられた帯域を上回る場合
には、このフローの収容を拒絶するためフロー受付制御
を搭載する必要がある。

【００７０】（２）ＩＰパケット受付制御 上述したように、上位レイヤにＲＴＰを用いて生成され
たＩＰパケットフローのみをアグリゲートしたアグリゲ
ートフローのトラヒック特性は、当該アグリゲートフロ
ーに収容される各々のフローのパケット転送速度の総和
にて規定可能である。そのため、パス３５の入口にて実
行する、アグリゲートフローへのＩＰパケット受付制御
も、到着パケットのパケット転送速度を監視して、当該
転送速度が本アグリゲートフローにおけるパケット転送
速度の総和を上回らない場合に限り、到着パケットをア
グリゲートフロー内に収容すればよい。

【００７１】さて、次に、本実施形態に係るルータの構
成について説明する。

【００７２】図９に、アグリゲートフローの端点となり
得るルータ（図１の例では、ルータ１１、ルータ１２）
の構成例を示す。

【００７３】図９において、４１はスイッチ部、４２は
プロトコル処理部、４３はパケットヘッダ処理部、４４
はルーチング処理部、４５はポート対応部、４５１はパ
ケット受付制御部である。図９においては、４入力４出
力の場合を例にとり示しており、パケット出力ポート毎
にパケット受付制御部４５１が設置される。

【００７４】ポート対応部４５は、各入出力ポート毎に
設けられ、入力ポートからパケットを入力する処理と出
力ポートからパケットを送出させる処理を行う。

【００７５】スイッチ部４１は、任意のパケット入力ポ
ートより到着したＩＰパケットを、ルーチング処理部４
４により選択されたパケット出力ポートへ出力させるた
めの動作を行う。本スイッチ部４１は、例えばイーサネ
ットスイッチ、ファイバチャネルスイッチ、ＡＴＭスイ
ッチ、などにて構成可能である。

【００７６】プロトコル処理部４２では、スイッチ部４
１に到着したＩＰパケットが、任意のプロトコルにて規
定された制御メッセージであるか否かを判断し、制御メ
ッセージであれば、当該メッセージに基づく処理を行
う。例えば、到着パケットが、ＲＳＶＰにて規定されて
いるＰａｔｈメッセージであれば、Ｐａｔｈメッセージ
内のトラヒック特性を記憶して、パケット受付制御部４
５１へ本特性を通知する。また、到着パケットが、ＲＳ
ＶＰにて規定されているＲｅｓｖメッセージであれば、
Ｒｅｓｖメッセージ内の資源予約要求が受付可能である
か否かを判断し、受付可能であれば、相当するフローに
対する資源の確保を指示する。

【００７７】そして、プロトコル処理部４２では、アグ
リゲートフローの新規設定や解放に伴う処理を行う。

【００７８】また、プロトコル処理部４２では、スイッ
チ部４１に到着したＩＰパケットをアグリゲートフロー
内に挿入すべきパケットであるか否かを判断し、アグリ
ゲートフロー内に挿入すべきパケットであれば、パケッ
トヘッダ処理部４３へ、パケットヘッダの操作を指示す
る。

【００７９】さらに、プロトコル処理部４２では、アグ
リゲートＰａｔｈメッセージ、アグリゲートＲｅｓｖメ
ッセージの生成／終端も行う。

【００８０】パケットヘッダ処理部４３では、スイッチ
部４１に到着したＩＰパケットがアグリゲートフロー内
に挿入されるパケットである場合に、図４にて示したパ
ケットのカプセル化、もしくは図５に示したパケットヘ
ッダ内のフローラベルの変換といった処理を行う。

【００８１】ルーチング処理部４４では、パケットヘッ
ダ処理部４３にて処理されたＩＰパケットのフローラベ
ル、もしくは、アグリゲートフロー内に収容されない、
スイッチ部４１に到着したＩＰパケットのデスティネー
ションアドレス（必要に応じて、ソースアドレス、フロ
ーラベルも参照）を参照して、当該パケットの出力先ポ
ートを決定し、本ポートへ当該パケットをルーチングす
るよう、スイッチ部４１に指示する。

【００８２】パケット受付制御部４５１は、アグリゲー
トフローへ収容するＩＰパケットの受付制御、もしく
は、アグリゲートフローに限定しない任意のフローに対
するＩＰパケットの受付制御を行う。なお、パケット受
付制御部４５１は、図９に示すように各ポート毎に設置
する代わりに、ルーチング処理部４４内に設置して、Ｉ
Ｐパケットのルーチングを決定すると同時に、当該パケ
ットの受付の可否を判断するというように構成してもよ
い。

【００８３】次に、図１０に、アグリゲートフローの生
成手順の一例を示す。

【００８４】図１０では、パケットフローａがサービス
中であるところへ、パケットフローｂが新たにサービス
を開始する場合を例にとり、説明する。

【００８５】フローｂ上にＰａｔｈメッセージが到着す
ると、ルータ１１のプロトコル処理部４２では、フロー
ｂとアグリゲートが可能なフローが、本Ｐａｔｈメッセ
ージの出側ポートと同一のポートより送出されるフロー
の中に存在するかを判断する（図１０（ａ））。例え
ば、両フローともＲＴＰを介して生成されるＩＰパケッ
トであり、固定長のパケットが一定のパケット転送速度
にて送出されるような場合には、フローのアグリゲート
が可能であると判断する。図１０の例では、フローａと
のアグリゲートを試みるものとする。

【００８６】次に、ルータ１１内のプロトコル処理部４
２は、アグリゲートフローの終端ノードとなり得るルー
タの検索を行うためのメッセージ（終端ノード検索メッ
セージ）を生成し、フローｂのＰａｔｈメッセージの宛
先アドレス宛に送信する（図１０（ｂ））。このとき、
終端ノード検索メッセージ内には、アグリゲートの相手
がフローａである旨を記載しておく。

【００８７】終端ノード検索メッセージを受信するルー
タでは、当該メッセージ内の宛先アドレスより決定され
る出側ポートと、当該メッセージ内に記載されているフ
ローａの出側ポートが同一であるかを比較し、同一の出
側ポートを用いていれば、引続き当該メッセージを次段
ルータ宛に送信する。

【００８８】終端ノード検索メッセージ内の宛先アドレ
スより決定される出側ポートと、当該メッセージ内に記
載されているフローａの出側ポートが異なるルータ（ル
ータ１２）に到着すれば、本ルータ内のプロトコル処理
部４２では、自ルータがアグリゲートフローの終端ルー
タとなることを記憶して、それに伴うＩＰパケットのヘ
ッダ処理（アグリゲートフロー用に修正されたＩＰヘッ
ダを、当初のＩＰヘッダへ戻すための処理）を行うよ
う、パケットヘッダ処理部４３へ指示する。そして、ル
ータ１２は、終端ノード検索メッセージが終端ルータに
到達した旨を、当該メッセージを生成したルータ１１に
通知する（図１０（ｃ））。

【００８９】ルータ１１にて、終端ノード検索メッセー
ジが終端ルータに到達した旨を認識すれば、本ルータ内
のプロトコル処理部４２では、自ルータがアグリゲート
フローの開始ルータとなることを記憶して、それら伴う
ＩＰパケットのヘッダ処理（アグリゲートフロー用にＩ
Ｐヘッダを修正するための処理）を行うよう、パケット
ヘッダ処理部４３へ指示する（図１０（ｄ））。

【００９０】次に、図１１に、新規フローのアグリゲー
トフローへの挿入手順の一例を示す。

【００９１】図１１では、パケットフローａとパケット
フローｂとを収容するアグリゲートフローが存在すると
ころへ、パケットフローｃが新たにサービスを開始する
場合を例にとり、説明する。

【００９２】フローｃ上にＰａｔｈメッセージが到着す
ると、ルータ１１のプロトコル処理部４２では、フロー
ｃが、フローｃの出側ポートを始点としている既存のア
グリゲートフロー内に挿入することが可能であるか否か
（アグリゲートフローとのアグリゲートが可能であるか
否か）を判断する（図１１（ａ））。

【００９３】フローｃを、アグリゲートフロー内に挿入
可能であると判断すれば、ルータ１１内のプロトコル処
理部４２は、アグリゲートフローの終端ノードであるル
ータ１２に対して、当該アグリゲートフロー内にフロー
ｃを挿入する旨を伝えるメッセージを送信する（図１１
（ｂ））。

【００９４】当該メッセージを受信した、アグリゲート
フローの終端ノードであるルータ１２は、フローｃ内の
パケットもアグリゲートフローを介して受信される旨を
記憶して、それに伴うＩＰパケットのヘッダ処理を行う
よう、パケットヘッダ処理部４３へ指示する。そして、
当該メッセージが到達した旨を、ルータ１１に通知する
（図１１（ｃ））。

【００９５】ルータ１１にて、当該メッセージが終端ル
ータに到達した旨を認識すれば、フローｃ内のパケット
もアグリゲートフローに挿入するよう、パケットヘッダ
処理部４３へ指示する（図１１（ｄ））。

【００９６】さて、次に、端末の移動に対応可能な通信
網システムを提供する際に必要となる機能について、説
明する。

【００９７】図１２には、端末２２の移動に伴い、端末
２２の接続先であるルータが、ルータ１４よりルータ１
５へ変更となった場合の通信網システム内のフローがと
るルートの変更の様子を示す。

【００９８】端末２２の移動に伴い、フローｂに対して
は、端末２４迄の通信を行うための新たなルートが設定
される。図１２の例では、フローｂの新たなルートが、
（端末２２）→ルータ１５→ルータ１１→…→ルータ１
２→ルータ１８→（端末２４）になったものとする。

【００９９】フローｂが上記ルートを通る場合、フロー
ｂはルータ１１を通過するため、アグリゲートフローの
始点であるルータ１１では、端末２２の移動前にフロー
ｂを収容していたアグリゲートフロー内に、フローｂ上
を転送するＩＰパケットを引続き収容することが可能で
ある。これは、ルータ１１内のパケットヘッダ処理部４
３では、到着したＩＰパケットの入側ポートに関係な
く、ＩＰパケット内のフローラベルとソースアドレス
（端末２２に固有に割り当てられたアドレス）との組に
より、到着パケットがフローｂに属することを判断する
からである。つまり図１２の例では、端末２２の移動に
伴う手続きとしては、パス３３を解放する手続きと、新
たにパス３６を設定してパス３６上に必要帯域を確保す
る手続きとを行うのみでよく、ルータ１１より端末２４
までのパス３５，３４に対しては、如何なる変更も施す
必要がない。

【０１００】図１３には、端末２２の移動に伴い、端末
２２の接続先であるルータが、ルータ１４よりルータ１
９へ変更となった場合の通信網システム内のフローがと
るルートの変更の様子を示す。

【０１０１】図１３の例では、端末２２の移動に伴うフ
ローｂの新たなルートは、（端末２２）→ルータ１９→
…ルータ１８→（端末２４）になったものとする。

【０１０２】フローｂが上記ルートを通る場合、フロー
ｂは、端末２２の移動前のルート上にあるルータ１１を
通過せずに宛先である端末２４へ到達する。つまり、移
動後のフローｂはルータ１１とルータ１２との間に存在
するアグリゲートフローを使用しないこととなる。よっ
て、端末２２と端末２４との間には、新たにパス４３が
設定される。なお、ルータ１９とルータ１８との間に、
フローｂとのアグリゲートが可能なフローが存在する場
合には、図１０にて示した手順に従い、新たにアグリゲ
ートフローを生成することが可能である。また、ルータ
１９とルータ１８との間に、フローｂを挿入することが
可能な既存のアグリゲートフローが存在する場合には、
図１１にて示した手順に従い、既存のアグリゲートフロ
ー内にフローｂを挿入することが可能である。

【０１０３】なお、端末２２の移動前にフローｂを収容
していた、ルータ１１とルータ１２との間のアグリゲー
トフローは、現在フローａのみを収容しているため、ア
グリゲートフローを解放して、端末２１と端末２３との
間にパス４１を新たに設定する場合もある。

【０１０４】以上のように本実施形態によれば、同一な
ルーチング処理を施すこととなる複数のＩＰパケットフ
ローに対しては、これらのＩＰパケットフローを束ねた
アグリゲートフローを生成し、本アグリゲートフローに
対するルーチング処理、帯域割当制御を行うことができ
る。これにより、ルーチング処理や帯域割当制御を実行
するのに必要なフロー毎の情報を保持するために必要な
メモリ量が削減でき、これらの情報を検索するのに要す
る時間の削減が可能となる。また、端末の移動に伴うフ
ロー再設定の範囲も可能な限り狭めることが可能とな
り、フロー再設定に要する時間の減少が期待できる。

【０１０５】次に、本発明を他の通信網システムに適用
する場合の例について説明する。

【０１０６】図１４は、本発明の適用対象となる通信網
システムの図１とは異なる一例である。

【０１０７】図１４では、通信網を、プレミアムサービ
ス用ネットワーク５１と通常サービス用ネットワーク５
２との二種類に、論理的もしくは物理的に分割してい
る。なお、プレミアムサービス用ネットワーク５１は、
サービスクラス毎のＩＰパケット処理ポリシーの規定が
可能な（ＣｏＳ（サービスクラス）サポートのある）ル
ータにより構成されるネットワークである。なお、図１
４において、プレミアムサービス用ネットワーク５１を
構成するルータ装置は省略してある（プレミアムサービ
ス用のパスの出入口に位置するルータ装置は、例えば図
９のような構成とする）。

【０１０８】なお、図１４において有線回線にて接続さ
れている部分の全部または一部を無線回線に置き換えて
接続した通信網システムにも本発明は適用可能である。

【０１０９】プレミアムサービス用ネットワークでは、
通常サービス用ネットワークからの指示により、通常サ
ービス用ネットワーク内の任意のルータ間での、プレミ
アムサービスを要求するＩＰパケットの配送を目的とし
たパスの設定、そして、既に設定されているパスの解放
が行われる。図１４の例では、ルータ５４１とルータ５
４２との間にて、プレミアムサービスを要求するＩＰパ
ケットの配送のためにパス５３１が、ルータ５４１とル
ータ５４３との間にて、プレミアムサービスを要求する
ＩＰパケットの配送のためにパス５３２が、ルータ５４
２とルータ５４３との間にて、プレミアムサービスを要
求するＩＰパケットの配送のためにパス５３３が、各々
設定されている。なお、プレミアムサービスを要求しな
いＩＰパケットを配送する際には、プレミアムサービス
用ネットワークを用いず、通常サービス用ネットワーク
のみを用いる。

【０１１０】図１４において、端末５６１より端末５６
２宛へのプレミアムサービスでの通信要求が生じた場合
を例にとり、プレミアムサービスの通信が開始されるま
でを説明する。

【０１１１】端末５６１を収容する基地局５５１と接続
するルータ５４１では、端末５６１より生じたプレミア
ムサービスでの通信要求を受信すると、当該通信の相手
端末である、端末５６２迄の通信ルートの設定を、プレ
ミアムサービス用ネットワーク５１を介して行う。図１
４の例では、ルータ５４１にて、通信の相手端末５６２
が基地局５５２に収容されていることを認識すれば、ル
ータ５４１は、基地局５５２と接続するルータ５４２宛
へ設定されている、プレミアムサービス用ネットワーク
内のパス５３１を用いて通信を行えば良いことが分か
る。そこで、ルータ５４１は、当該プレミアムサービス
を要求するＩＰパケットをパス５３１内に挿入するよう
ルートを設定する。また、パス５３１の出口に位置する
ルータ５４２では、パス５３１より到着する当該プレミ
アムサービスを要求するＩＰパケットを、基地局５５２
を介して端末５６２へ送信するよう、ルートを設定す
る。

【０１１２】ところで、プレミアムサービスを提供すべ
き新規ＩＰパケットフローが挿入されることを認識した
パス５３１では、収容ＩＰパケットフロー情報の更新を
行う。収容ＩＰパケットフロー情報は、例えば図１５の
ように、ＩＰパケットフローの識別子と当該フローのト
ラヒック特性とを対応づけて、パスの入口（パス５３１
の場合だと、例えばタール５４１）にて保持されるもの
である。

【０１１３】そして、現在パスに収容しているＩＰパケ
ットフローを統計多重することにより得られる、アグリ
ゲートフローのトラヒック特性を、当該パス内に収容す
るＩＰパケットフローが増加、もしくは減少する度に算
出し、本アグリゲートフローを収容するのに十分な帯域
を、当該パスに割り当てる。図１５の例では、各ＩＰパ
ケットフローが、一定の速度に従いパケット転送を行
い、本フローのトラヒック特性がパケット転送速度値の
みを用いて表すことのできる例を用いているため、アグ
リゲートフローのトラヒック特性は、これらのパケット
転送速度値の総和にて表すことができる。

【０１１４】なお、プレミアムサービス用ネットワーク
内での帯域割当制御を、ＲＳＶＰを用いて行う方法をと
ってもよい。この場合、図１６のように、パスの送信側
端点に位置するルータにて、図１５にて記載されている
アグリゲートフローのトラヒック特性を記載したＰａｔ
ｈメッセージを周期的に生成して送信し、また、パスの
受信側端点に位置するルータにて、プレミアムサービス
として必要なサービス品質を記載したＲｅｓｖメッセー
ジを周期的に生成して送信する。これに基づき、プレミ
アムサービス用ネットワーク内の各ルータでは、受信す
るＰａｔｈメッセージ、Ｒｅｓｖメッセージに基づい
て、各々のパスに対する帯域割当を実行する。

【０１１５】さらに、プレミアムサービス用ネットワー
ク内のパスは、当該パスに収容されるフローの有無に関
わらず、常に固定的に設定しておく方法を用いてもよ
い。このとき、当該パスに割り当てる帯域は、予めプレ
ミアムサービス用ネットワークにおいて取り決めておい
た帯域を固定的に割り当てておく。

【０１１６】プレミアムサービス用ネットワーク内に設
定されたパスの入口では、ＩＰパケット受付制御機能
（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９のパケ
ット受付制御部４５１に相当）を設けて、予め定められ
たアグリゲートフローのトラヒック特性に合致しないＩ
Ｐパケットの、プレミアムサービス用ネットワーク内へ
の流入を防ぐというトラヒック制御を実行するようにし
てもよい。

【０１１７】次に、本発明をさらに他の通信網システム
に適用する場合の例について説明する。

【０１１８】図１７は、本発明の適用対象となる通信網
システムの図１および図１４とは異なる一例である。

【０１１９】図１７では、通信網を、基地局６５１〜６
５６を収容する小規模なネットワーク６２〜６４と、ネ
ットワーク６２〜６４を収容する大規模なネットワーク
６１との二種類に、論理的もしくは物理的に分割してい
る。なお、ネットワーク６１内には、ネットワーク６２
〜６４の任意の二種類のネットワーク間の通信を提供す
るためのパス６１１〜６１３が固定的に設定されてい
る。なお、図１７において、プレミアムサービス用ネッ
トワーク５１を構成するルータ装置は省略してある（大
規模ネットワーク中のパスの出入口に位置するルータ装
置は、例えば図９のような構成とする）。

【０１２０】なお、図１７において有線回線にて接続さ
れている部分の全部または一部を無線回線に置き換えて
接続した通信網システムにも本発明は適用可能である。

【０１２１】ネットワーク６２〜６４では、ＩＰパケッ
トフローに対する帯域予約要求が生じる度に、例えばＲ
ＳＶＰによる帯域予約が、ＩＰパケットフロー毎になさ
れる。また、ネットワーク６１では、ネットワーク６２
〜６４の異なるネットワーク間にて生じる通信に対する
帯域予約を、パケットのカプセル化やフロー識別子（フ
ローラベル）の変換により生成するアグリゲートフロー
毎に、例えばＲＳＶＰを用いてなされる。

【０１２２】図１７は、端末６６２が基地局６５３に収
容されている場合の、端末６６１宛へのＩＰパケットフ
ローに対する帯域予約の例を示したものである。このと
き、送信端末６６２を収容する基地局６５３は、受信端
末６６１を収容する基地局６５１はネットワーク６２内
に存在することを認識し、基地局６５３が存在するネッ
トワーク６３とネットワーク６２とを接続するネットワ
ーク６１内に設定されているパス６１２を用いて通信を
行うよう、ルート設定を行う。そして、ネットワーク６
３では、基地局６５３とネットワーク６１内のパス６１
２の入口とを接続するパス６３１を設定して、本パス６
３１に対する帯域予約を行い、ネットワーク６２では、
ネットワーク６１内のパス６１２の出口と基地局６５１
とを接続するパス６２１を設定して、本パス６２１に対
する帯域予約を行う。さらに、ネットワーク６１では、
新規フローを新たに束ねたアグリゲートフローを収容す
るパス６１２において、アグリゲートフロー全体での帯
域予約がなされる。なお、先の例と同様に、パス６３
１、パス６１２、パス６２１の入口では、ＩＰパケット
受付制御機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）
（図９のパケット受付制御部４５１に相当）を設けて、
ＩＰパケットの受付制御を行ってもよい。

【０１２３】ここで、図１８に示すように、端末６６２
の移動により、収容される基地局が基地局６５３より基
地局６５６に変更された場合を考える。このとき、端末
６６２は、基地局６５６に対して自信が基地局６５６の
エリア内に存在することを通知する。本通知を受けた基
地局６５６では、端末６５１との間の帯域予約をＲＳＶ
Ｐを用いて実行する。

【０１２４】基地局６５６は、自信が存在するネットワ
ーク６４と、受信端末６６２を収容する基地局６５１が
存在するネットワーク６２とを接続する、ネットワーク
６１内に設定されているパス６１１を用いて通信を行う
よう、ルート設定を行う。そして、ネットワーク６４で
は、基地局６５６とネットワーク６１内のパス６１１の
入口とを接続するパス６４１を設定して、本パス６４１
に対する帯域予約を行い、ネットワーク６２では、ネッ
トワーク６１内のパス６１１の出口と基地局６５１とを
接続するパス６２２を設定して、本パス６２２に対する
帯域予約を行う。さらに、ネットワーク６１では、新規
フローを新たに束ねたアグリゲートフローを収容するパ
ス６１１において、アグリゲートフロー全体での帯域予
約がなされる。なお、上記と同様に、パス６４１、パス
６１１、パス６２２の入口では、ＩＰパケット受付制御
機能（ＰＡＣ部；図中では「ＰＡＣ」で示す）（図９の
パケット受付制御部４５１に相当）を設けて、ＩＰパケ
ットの受付制御を行ってもよい。

【０１２５】なお、端末６６２が基地局６５３に収容さ
れていた際に設定されたパス６３１、パス６２１に対し
ては、端末６６２の移動に伴い、Ｐａｔｈメッセージ、
Ｒｅｓｖメッセージのパス６３１、パス６２１上の送信
がなくなり、一定時間これらのメッセージが受信されな
ければ、ＲＳＶＰに規定されているタイムアウト機能に
より、パス６３１、パス６２１に対して確保された帯域
は全て解放されることとなる。また、端末６６２より端
末６６１宛のＩＰトラヒックフローを収容していたネッ
トワーク６１内のパス６１２においても、当該フローの
流入の終了に伴い、当該フローを除いたアグリゲートフ
ローに対する帯域予約が新たに行われる。

【０１２６】なお、ネットワーク６１内のパス６１１，
６１２，６１３が確保する帯域は、収容されているフロ
ーの有無に関わらず、固定量を割り当てるという方法を
用いてもよい。

【０１２７】以下では、リアルタイム通信用のプロトコ
ルであるＲＴＰを用いた場合に、ＲＴＰレベルにてパケ
ットのストリームをアグリゲートした場合の制御方法に
ついて説明する。なお、ＲＴＰレベルでのアグリゲート
の方法は基本的には前述したＩＰレベルでのアグリゲー
トの方法と同様である（図４、図５参照）。

【０１２８】図１９に、ＲＴＰレベルでのパケット転送
制御の概要を示す。ＲＴＰ自身は、ＱｏＳを保証するた
めのプロトコルではなく、ＲＴＰパケットにタイムスタ
ンプやシーケンス番号などの付与、そしてＲＴＣＰ（Ｒ
ＴＰ制御プロトコル）による送信者と受信者との間の情
報交換サービスを提供する。つまり、ＲＴＰとＲＴＣＰ
を用いることにより、ＲＴＰの上位レイヤ（例えばアプ
リケーション）は、例えば受信者からの情報よりネット
ワークの状態が推定できるので、それにより輻輳である
と判断すれば、データの送信速度を制限するようなＱｏ
Ｓ制御を行うことができる。

【０１２９】図２０に、ＲＴＰの通信シーケンスを示
す。ＲＴＰ通信を開始する際、送信者はＳＤＥＳ（ソー
ス記述アイテム）メッセージを記載したＲＴＣＰパケッ
トを受信者側に送出し、通信で使用するセッション情報
等を伝える。ＳＤＥＳメッセージを送出することで、Ｒ
ＴＰセッションが確立され、送信者はＲＴＰデータをあ
るビットレートにて送出する。

【０１３０】送信者は、ＲＴＰデータを送出した時点か
ら周期的に（例えば一定間隔Δｔ_Sで）、ＳＲ（送信者
報告）メッセージを記載したＲＴＰパケットを送出す
る。ＳＲメッセージでは、送信者側でのタイムスタンプ
値、送信パケット総数とそのオクテット数の総数などの
情報メッセージが記載される。

【０１３１】また、受信者は、ＲＴＰデータを受信した
時点から周期的に（例えば一定間隔Δｔ_Rで）、ＲＲ
（受信者報告）メッセージを記載したＲＴＣＰパケット
を送出する。ＲＲメッセージでは、パケット損失数、受
信者でのシーケンス番号、遅延ジッタ、最後に受信した
ＳＲメッセージからの遅れなどの情報メッセージが記載
される。

【０１３２】通信終了時には、送信者はＢＹＥメッセー
ジを記載したＲＴＣＰパケットを送出することで、ＲＴ
Ｐセッションを開放する。

【０１３３】送信者と受信者では、上述のようにＳＲメ
ッセージ、ＲＲメッセージを交換し合うことで、帯域に
あったビットレートを調整してＲＴＰデータを送出す
る。

【０１３４】ＲＴＰでは、「ミキサ」の概念をサポート
している。ミキサは、１つ以上のソースから送信される
ＲＴＰパケットのストリーム（以下、ＲＴＰストリーム
と呼ぶ）を受信し、ＲＴＰパケット内のデータフォーマ
ットを変更したり、ＲＴＰストリームをアグリゲートし
て新たなストリームを生成し、これを転送するＲＴＰパ
ケットの中継装置である。

【０１３５】図２１に、ＲＴＰミキサを用いたＲＴＰス
トリームの生成の一例を示す。図２１では、図１に示し
た通信網システムにおける例について示したものであ
る。

【０１３６】図２１では、端末２１より端末２３宛にＲ
ＴＰパケットを送信し、また、端末２２より端末２４宛
にＲＴＰパケットを送信する。これらを各々ＲＴＰスト
リームａ、ＲＴＰストリームｂとする。ＲＴＰミキサ１
１（図１におけるルータ１１に相当）では、ＲＴＰスト
リームａとＲＴＰストリームｂとをアグリゲートし、新
たなＲＴＰストリームｃを生成し、ＲＴＰミキサ１２
（図１におけるルータ１２に相当）へ送信する。ＲＴＰ
ミキサ１２では、ＲＴＰストリームｃをＲＴＰストリー
ムａとＲＴＰストリームｂとに再び分離し、各々を送信
先である端末２３もしくは端末２４へ送信する。なお、
以下では、端末２１とＲＴＰミキサ１１間におけるＲＴ
ＰストリームａとＲＴＰミキサ１２と端末２３との間に
おけるＲＴＰストリームａとを区別するため、ＲＴＰミ
キサ１２と端末２３との間におけるＲＴＰストリームａ
については、ＲＴＰストリームａ’と記載する。同様の
理由により、ＲＴＰミキサ１２と端末２４との間におけ
るＲＴＰストリームｂについては、ＲＴＰストリーム
ｂ’と記載する。

【０１３７】ＲＴＰストリームの送信者と受信者との間
の情報交換を提供するＲＴＣＰパケットが、ＲＴＰスト
リームの終端ノード間にて行われる。図２１では、ＲＴ
Ｐストリームａに対するＲＴＣＰパケットが端末２１と
ＲＴＰミキサ１１との間で、ＲＴＰストリームｂに対す
るＲＴＣＰパケットが端末２２とＲＴＰミキサ１１との
間で、ＲＴＰストリームｃに対するＲＴＣＰパケットが
ＲＴＰミキサ１１とＲＴＰミキサ１２との間で、ＲＴＰ
ストリームａ’に対するＲＴＣＰパケットがＲＴＰミキ
サ１２と端末２３との間で、ＲＴＰストリームｂ’に対
するＲＴＣＰパケットがＲＴＰミキサ１２と端末２４と
の間で各々送受信される。

【０１３８】図２２は、ＲＴＰストリームａ、ＲＴＰス
トリームｂ、ＲＴＰストリームａ’が通過する端末、ル
ータ、ＲＴＰミキサにおけるプロトコルスタックを示
す。なお、ＩＰレイヤより下位レイヤにおけるプロトコ
ルスタックについては図示していない。

【０１３９】図２２に示すように、ルータ１３やルータ
１６においては、受信したＩＰパケットをＲＴＰパケッ
トに組み立てることなく、ＩＰパケットのヘッダ情報を
もとにルーチング処理を行う。それに対して、ＲＴＰミ
キサ１１およびＲＴＰミキサ１２においては、受信した
ＩＰパケットを一旦ＲＴＰパケットに組立てて、ＲＴＰ
パケットのヘッダ情報をもとにルーチング処理を行う。
その際、ＲＴＰミキサ１１では、ＲＴＰストリームａと
ＲＴＰストリームｂとのアグリゲートを行ってＲＴＰス
トリームｃを生成し、ＲＴＰミキサ１２では、ＲＴＰス
トリームｃを分離してＲＴＰストリームａとＲＴＰスト
リームｂとに再び戻す。

【０１４０】図２１において、ＲＴＰストリームａとＲ
ＴＰストリームｂとをアグリゲートすることにより生成
されたＲＴＰストリームｃに対して実行される輻輳制御
方法について以下に示す。

【０１４１】（ａ）ＲＴＰミキサ１１における、ＲＴＰ
ストリームｃの送信速度の減少 ＲＴＰミキサ１１では、ＲＴＰミキサ１２との間でのＲ
ＴＣＰパケットの交換により、ＲＲメッセージから得ら
れるパケット損失数などの情報に基づき、輻輳の検知が
可能となる。

【０１４２】ＲＴＰミキサ１１では、ＲＴＰストリーム
ａ、ＲＴＰストリームｂより受信したＲＴＰパケットを
アグリゲートしてＲＴＰストリームｃとして送出する際
に、送信速度を減少させることで、輻輳からの回復を図
る。ＲＴＰストリームの送信速度を減少させるための手
段としては、（１）受信したＲＴＰパケットを一旦復号
化し、新しいデータ送信速度に合わせて再符号化する方
法、（２）階層符号化等を用いてストリームデータを複
数の階層に分けて符号化を行い、新しいデータ送信速度
に応じて、復号に必要な階層のデータを含むパケットよ
り送信する方法、などが挙げられる。

【０１４３】ところで、（１）に示した方法を実現する
ためには、ＲＴＰミキサ１１では、ＲＴＰパケットを復
号化・再符号化するためのアプリケーションレイヤの処
理を実行する必要がある。ＲＴＰミキサでの負荷を考慮
すれば、（２）に示した、階層符号化を用いる方法が効
率的な制御であると考えられる。

【０１４４】図２３に示した例では、端末２１と、端末
２２（図２３では省略している）は、それぞれ、Ｌ１、
Ｌ２、Ｌ３、Ｌ４の４階層に階層符号化されたストリー
ムデータを、ＲＴＰストリームａ、ＲＴＰストリームｂ
として送信する。なお、Ｌ１はそのストリームを再生す
るための最低限の情報量が含まれたデータであり、それ
単体でデコードすることが可能である。これに対し、Ｌ
２、Ｌ３、Ｌ４は、Ｌ１と合成することで受信品質を改
善することが可能なデータであり、Ｌ２、Ｌ３、Ｌ４の
順で優先度が低くなる（本例の場合、Ｌ１、Ｌ１とＬ
２、Ｌ１〜Ｌ３、Ｌ１〜Ｌ４の４種類がある）。

【０１４５】図２３では、ＲＴＣＰパケットにより、Ｒ
ＴＰストリームｃの転送経路上にて輻輳が発生している
ことを認識したＲＴＰミキサ１１が、それまでＬ１〜Ｌ
４の全てのデータを送信していたところを、Ｌ１とＬ２
のデータのみをＲＴＰミキサ１２宛に送信するよう変更
している。Ｌ３とＬ４のデータについては、ＲＴＰミキ
サ１２宛に送信せず、廃棄する。これにより、廃棄され
たデータ（上記例では、Ｌ３，Ｌ４）に応じて受信側で
の品質が劣化するものの、ＲＴＰストリームｃの送信速
度が減少され、輻輳の回復が期待される。

【０１４６】（ｂ）ＲＴＰストリームｃを収容するＩＰ
アグリゲートフローに対する割り当て帯域量の増加 （ａ）に示したような、ＲＴＰミキサ１２がＲＴＰミキ
サ１１宛にＲＲメッセージを送信することで、ＲＴＰミ
キサ１１にＲＴＰストリームｃの送信速度を減少させる
ことで輻輳からの回復を図るという制御の他に、ＩＰレ
イヤにおいて前記ＲＴＰストリームｃを収容するＩＰア
グリゲートフローに割り当てられる帯域を増加すること
で、輻輳からの回復を図るという制御を、図７に示した
アグリゲートＰａｔｈメッセージ（Ａｇｇｒｅｇａｔｅ
ｄ Ｐａｔｈ ｍｓｇ．）、アグリゲートＲｅｓｖメッ
セージ（Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｖ ｍｓｇ．）
を用いて実行する。

【０１４７】図２４に示した例では、ＲＴＣＰパケット
の交換によりＲＴＰストリームｃの転送経路上に輻輳が
生じていることをＲＴＰミキサ１２が認識した場合、Ｒ
ＴＰミキサ１２は、本ＲＴＰストリームｃを収容するＩ
Ｐアグリゲートフローに割り当てる帯域を増加させるよ
う、ＩＰレイヤにおいて、要求帯域を記載したアグリゲ
ートＲｅｓｖメッセージを生成し、ＲＴＰミキサ１１宛
へ送信する。図２４に示していないが、ＲＴＰミキサ１
１とＲＴＰミキサ１２との間の全てのルータにおいて、
アグリゲートＲｅｓｖメッセージに記載した要求帯域の
割り当てが許容されれば、ＩＰアグリゲートフローに対
する割当帯域は増加され、その結果、本ＩＰアグリゲー
トフローに収容されるＲＴＰストリームｃは、輻輳から
の回復が可能となる。

【０１４８】もちろん、上記（ａ）に示したＲＴＣＰパ
ケットの交換（ＲＲメッセージの送出）に基づいたＲＴ
Ｐレベルの輻輳制御と、上記（ｂ）に示したＲｅｓｖメ
ッセージに基づいたＩＰレベルの輻輳制御との両者を組
み合わせて実行してもよい。

【０１４９】ところで、ＩＰパケットのパケット長が異
なるフロー同士をアグリゲートする場合、ＲＴＰミキサ
にて、その上位レイヤであるアプリケーションレイヤ処
理を併せて実行することで、これらのパケット長が同一
となるよう調整することが可能となる。図２５に、この
場合の一例を示す。

【０１５０】ＩＰパケット長は、ＩＰパケットを生成す
るＲＴＰパケット長、すなわち、アプリケーションレイ
ヤにおける符号化速度と、ＲＴＰレイヤにおけるＲＴＰ
パケット生成間隔により決定される。図２５において、
端末２１にて送信するアプリケーション情報を、符号化
速度ｓ１、パケット生成間隔Ｔ１にて生成したＲＴＰパ
ケットをＩＰパケット化した際のＩＰパケット長はｓ１
×Ｔ１＋αにて、端末２２にて送信するアプリケーショ
ン情報を、符号化速度ｓ２、パケット生成間隔Ｔ２にて
生成したＲＴＰパケットをＩＰパケット化した際のＩＰ
パケット長はｓ２×Ｔ２＋αにて表記できる。なお、α
は、ＲＴＰヘッダ長、ＵＤＰヘッダ長、ＩＰヘッダ長の
和を示す。

【０１５１】端末２１にて生成されるＩＰパケットフロ
ーと、端末２２にて生成されるＩＰパケットフローとを
共に受信するＲＴＰミキサ１１では、受信したＩＰパケ
ットを一旦ＲＴＰパケットに変換し、さらにアプリケー
ションレイヤにてアプリケーション情報（例えば、アナ
ログ音声信号）への復号化を行う。そして、両方のアプ
リケーション情報を、同一の符号化速度ｓ、同一のパケ
ット生成間隔ＴにてＲＴＰパケットを生成すれば、それ
をＩＰパケット化した際のＩＰパケット長が共に、ｓ×
Ｔ＋αと同一なものになる。これにより、前述したよう
にＩＰアグリゲートフローとしてのＩＰパケット処理の
負荷が低減される。なお、ｓやＴは、アグリゲートされ
るいずれかのフローにおけるものと同じ値を用いてもよ
いし、それらとは異なる別の値を用いてもよい。

【０１５２】なお、アグリゲートフローの終点であるＲ
ＴＰミキサ１２（図２５では省略している）にて、両パ
ケットフローを分離して各々のフローの送信先端末へ送
出するが、その際に、本ＲＴＰミキサにおいて、再びア
プリケーション情報への復号化を行い、当初の符号化速
度、パケット生成間隔に従ったＲＴＰパケット生成、Ｉ
Ｐパケット化を行う。

【０１５３】ところで、図２５の例において、端末２
１、端末２２が階層符号化を用いてＲＴＰパケットを生
成している場合には、ＲＴＰミキサ１１では、アプリケ
ーションレイヤまで遡った復号化処理等を行う必要がな
い。その場合のＲＴＰミキサ１１での動作例を図２６に
示す。

【０１５４】ＲＴＰミキサ１１では、受信したＩＰパケ
ットをＲＴＰパケットに変換した後に、端末２１より送
出されたＲＴＰパケットａの長さと、端末２２より送出
されたＲＴＰパケットｂの長さとが同一となるよう調整
する。図２６に示した例では、ＲＴＰミキサ１１にて、
パケット長が長いＲＴＰパケットｂのＬ３、Ｌ４のデー
タを廃棄している。

【０１５５】両ＲＴＰパケットの長さを同一とするため
の他の方法として、パケット長が短いＲＴＰパケットａ
に対してパディングを行い、両ＲＴＰパケットの長さを
同一とする方法もある。

【０１５６】上述したように、ＲＴＰパケット長が同一
となれば、本ＲＴＰパケットより生成されるＩＰパケッ
トのパケット長も同一なものとなる。

【０１５７】なお、以上の各機能は、ソフトウェアとし
ても実現可能である。

【０１５８】また、本実施形態は、コンピュータに所定
の手段を実行させるための（あるいはコンピュータを所
定の手段として機能させるための、あるいはコンピュー
タに所定の機能を実現させるための）プログラムを記録
したコンピュータ読取り可能な記録媒体としても実施す
ることもできる。

【０１５９】本発明は、上述した実施の形態に限定され
るものではなく、その技術的範囲において種々変形して
実施することができる。

【０１６０】

【発明の効果】本発明によれば、同一なルーチング処理
を施すこととなる複数のパケットフローに対しては、こ
れらのパケットフローを束ねたアグリゲートフローを生
成し、本アグリゲートフローに対するルーチング処理、
帯域割当制御を行うことができる。これにより、ルーチ
ング処理や帯域割当制御を実行するのに必要なフロー毎
の情報を保持するために必要なメモリ量が削減でき、こ
れらの情報を検索するのに要する時間の削減が可能とな
る。また、端末の移動に伴うフロー再設定の範囲も可能
な限り狭めることが可能となり、フロー再設定に要する
時間の減少が期待できる。

【図面の簡単な説明】

【図１】本発明を適用する通信網システムの一例を示す
図

【図２】帯域割当方法の一例を説明するための図

【図３】アグリゲートフローについて説明するための図

【図４】アグリゲートフローを定義する方法の一例を示
す図

【図５】アグリゲートフローを定義する方法の他の例を
示す図

【図６】送信側端末の上位レイヤにＲＴＰパケットを搭
載した場合のＩＰパケットの生成過程の概略を示す図

【図７】ＲＳＶＰにて定義されるＰａｔｈメッセージお
よびＲｅｓｖメッセージの流れの概要を示す図

【図８】アグリゲートＰａｔｈメッセージ内に記載され
るトラヒック特性およびアグリゲートＲｅｓｖメッセー
ジ内に記載される要求帯域を定義する方法の一例を示す
図

【図９】アグリゲートフローの端点となり得るルータの
構成例を示す図

【図１０】アグリゲートフローの生成手順の一例を説明
するための図

【図１１】新規ＩＰパケットフローのアグリゲートフロ
ーへの挿入手順の一例を説明するための図

【図１２】端末が移動する場合の通信網システム内のフ
ローのルート変更の一例について説明するための図

【図１３】端末が移動する場合の通信網システム内のフ
ローのルート変更の他の例について説明するための図

【図１４】本発明を適用する通信網システムの他の例を
示す図

【図１５】収容ＩＰパケットフロー情報の一例を示す図

【図１６】図１４においてプレミアムサービス用ネット
ワーク内での帯域割当制御をＲＳＶＰを用いて行う方法
の一例について説明するための図

【図１７】本発明を適用する通信網システムのさらに他
の例を示す図

【図１８】図１７において端末が移動する場合の通信網
システム内のフローのルート変更の一例について説明す
るための図

【図１９】ＲＴＰレベルでのパケット転送制御の概要を
説明するための図

【図２０】ＲＴＰの通信シーケンスを示す図

【図２１】ＲＴＰミキサを用いたＲＴＰストリームの生
成の一例を示す図

【図２２】プロトコルスタックの一例を示す図

【図２３】階層符号化を用いてＲＴＰストリームの送信
速度を減少させる場合の一例を示す図

【図２４】ＲＴＣＰパケットの交換によりＩＰアグリゲ
ートフローに割り当てる帯域を制御する場合の一例を示
す図

【図２５】ＲＴＰミキサにおいてパケット長が異なるＩ
Ｐフロー同士をアグリゲートする場合の一例を示す図

【図２６】ＲＴＰミキサにおいてパケット長が異なるＩ
Ｐフロー同士をアグリゲートする場合の他の例を示す図

【図２７】従来の帯域割当方法について説明するための
図

【符号の説明】

２１〜２４，５６１，５６２，６６１，６６２…端末 １１〜１９，５４１〜５４３…ルータ ５５１〜５５３，６５１〜６５６…基地局 ４１…スイッチ部 ４２…プロトコル処理部 ４３…パケットヘッダ処理部 ４４…ルーチング処理部 ４５…ポート対応部 ４５１…パケット受付制御部（ＰＡＣ部） ５１…プレミアムサービス用ネットワーク ５２…通常サービス用ネットワーク ６１…大規模ネットワーク ６２〜６４…小規模ネットワーク

Claims (17)

【特許請求の範囲】
1. 【請求項１】複数のルータ装置を接続して構成される通
   信網におけるパケットフロー制御方法において、 あるルータ装置へ転送されるパケットフローの情報を受
   信し、 この受信した情報に基づき、前記パケットフローについ
   て、前記あるルータ装置へ転送される複数のパケットフ
   ローを束ねることにより生成されるアグリゲートフロー
   としてのトラヒック特性を規定するか否かを判断し、 規定すると判断した場合に、前記パケットフローに属す
   るパケットを前記アグリゲートフロー用のパスに転送す
   ることを特徴とするパケットフロー制御方法。
2. 【請求項２】前記アグリゲートフロー用のパスの入口と
   出口の間に位置するルータ装置は、前記複数のパケット
   フローについて、前記アグリゲートフローとして規定し
   たトラヒック特性に従って該アグリゲートフロー単位で
   パケット転送を制御することを特徴とする請求項１に記
   載のパケットフロー制御方法。
3. 【請求項３】受信した前記パケットフローの情報が、特
   定のサービスを要求するパケットフローについてのルー
   ト設定の契機となる情報である場合に、前記判断を行う
   ことを特徴とする請求項１に記載のパケットフロー制御
   方法。
4. 【請求項４】前記アグリゲートフロー用のパスの入口の
   前段に位置するルータ装置は、前記特定のサービスを要
   求するパケットフローについてルート設定の契機となる
   情報を受信した場合、該情報を該パケットフローの宛先
   に応じた前記入口に位置するルータ装置に転送すること
   を特徴とする請求項３に記載のパケットフロー制御方
   法。
5. 【請求項５】前記アグリゲートフロー用のパスとして、
   特定のサービスを要求する複数のパケットフローをアグ
   リゲートするための一定の帯域を確保したパスを予め設
   定しておくことを特徴とする請求項１に記載のパケット
   フロー制御方法。
6. 【請求項６】規定すると判断した場合であっても、前記
   アグリゲートフロー用のパスに割り当てられた帯域が、
   前記アグリゲートフローとして規定したトラヒック特性
   に従ったパケット転送のために必要な帯域を下回る場合
   には、前記パケットフローに属するパケットを前記アグ
   リゲートフロー用のパスには転送しないよう制御するこ
   とを特徴とする請求項１に記載のパケットフロー制御方
   法。
7. 【請求項７】前記アグリゲートフロー用のパスが存在し
   ない場合に、前記アグリゲートフローとして規定したト
   ラヒック特性に従ったパケット転送のために必要な帯域
   を少なくとも割り当てて該パスを設定することを特徴と
   する請求項１に記載のパケットフロー制御方法。
8. 【請求項８】前記アグリゲートフロー用のパスが存在す
   る場合に、前記アグリゲートフローとして規定したトラ
   ヒック特性に従ったパケット転送のために必要な帯域を
   計算し、少なくともその算出された帯域が該パスに割り
   当てられるよう制御することを特徴とする請求項１に記
   載のパケットフロー制御方法。
9. 【請求項９】前記アグリゲートフロー用のパスの入口に
   位置するルータ装置は、該アグリゲートフロー用のパス
   に転送すべきパケットに、その本来のフローの識別情報
   の代わりとして後段のルータ装置に処理させる該アグリ
   ゲートされたフローの識別情報を与えることを特徴とす
   る請求項１に記載のパケットフロー制御方法。
10. 【請求項１０】前記アグリゲートフロー用のパスの入口
    に位置するルータ装置は、該アグリゲートフローへ収容
    されるパケットフローに属するパケットの自装置への到
    着過程を監視し、該到着過程が予め規定したアグリゲー
    トフローのトラヒック特性に従う範囲内で、該アグリゲ
    ートフローへのパケットの流入を許可することを特徴と
    する請求項１に記載のパケットフロー制御方法。
11. 【請求項１１】前記複数のパケットフローが、その各々
    を流れるパケットのパケット長が予め定められた一定の
    関係にあり、かつ、いずれのパケットフローにおいても
    パケット転送速度は変化しない、という条件を満足する
    か否かに基づいて、前記アグリゲートフローとしてのト
    ラヒック特性を規定するか否かを判断することを特徴と
    する請求項１に記載のパケットフロー制御方法。
12. 【請求項１２】前記複数のパケットフローが、ＩＰ（イ
    ンターネットプロトコル）の上位レイヤの転送プロトコ
    ルであるＲＴＰ（リアルタイム転送プロトコル）により
    生成されたＲＴＰパケットがＩＰによりパケット化され
    ることにより得られたパケットフローであるか否かに基
    づいて、前記アグリゲートフローとしてのトラヒック特
    性を規定するか否かを判断することを特徴とする請求項
    １に記載のパケットフロー制御方法。
13. 【請求項１３】前記あるルータ装置へ転送される複数の
    パケットフローの各々を流れるパケットのパケット長が
    予め定められた一定の関係になるように、該複数のパケ
    ットフローの一部または全部についてパケット長を変え
    るための処理をＲＴＰレイヤレベルで行い、 このＲＴＰレイヤレベルの処理が行われたパケットフロ
    ーについては、前記アグリゲートフローとしてのトラヒ
    ック特性を規定すると判断することを特徴とする請求項
    １に記載のパケットフロー制御方法。
14. 【請求項１４】前記アグリゲートフロー用のパスの入口
    に位置するルータ装置は、該アグリゲートフローに収容
    される各々のパケットフローにおけるパケットの転送速
    度を加算したものを該アグリゲートフローにおけるパケ
    ット転送速度として規定した場合に、前回、該アグリゲ
    ートフローへパケットを流入した時刻から今回、新たな
    パケットが自装置へ到着した時刻までの経過時間が、該
    アグリゲートフローにおけるパケット転送速度の逆数を
    下回らない範囲内で、パケットの該アグリゲートフロー
    への流入を許可することを特徴とする請求項１１ないし
    １３のいずれか１項に記載のパケットフロー制御方法。
15. 【請求項１５】ＩＰの上位レイヤの制御プロトコルであ
    るＲＴＣＰ（リアルタイム転送制御プロトコル）で交換
    される情報に基づいて、前記アグリゲートフロー用のパ
    スに割り当てる帯域を変更するための制御をＩＰレイヤ
    レベルで行うことを特徴とする請求項１に記載のパケッ
    トフロー制御方法。
16. 【請求項１６】複数のルータ装置を接続して構成される
    通信網に接続されるルータ装置であって、 あるルータ装置へ転送されるパケットフローの情報を受
    信する手段と、 この受信した情報に基づき、前記パケットフローについ
    て、前記あるルータ装置へ転送される複数のパケットフ
    ローを束ねることにより生成されるアグリゲートフロー
    としてのトラヒック特性を規定するか否かを判断する手
    段と、 規定すると判断した場合に、前記パケットフローに属す
    るパケットを前記アグリゲートフロー用のパスに転送す
    る手段とを備えたことを特徴とするルータ装置。
17. 【請求項１７】複数のルータ装置を接続して構成され、
    特定のサービスを要求する複数のパケットフローをアグ
    リゲートするための一定の帯域を確保したパスが部分的
    に予め設定されている通信網に、接続されるルータ装置
    であって、 前記特定のサービスを要求するパケットフローについて
    ルート設定の契機となる情報を受信する手段と、 この情報を、前記パケットフローの宛先に応じた前記パ
    スの入口に位置するルータ装置に転送して前記パスを利
    用したルート設定を行わせる手段と、 受信したパケットが前記特定のサービスを要求するパケ
    ットフローに属する場合には、該パケットを前記パスの
    入口に位置するルータ装置へ転送し、属さない場合に
    は、該パケットを前記パスを利用せずに前記パケットフ
    ローの宛先へ向けて転送するルータ装置へ転送する手段
    とを備えたことを特徴とするルータ装置。