JPH10257095A - 通信帯域通知装置、通信システム及び通信帯域確保方法 - Google Patents

Abstract

(57)【要約】 【課題】 一定水準の通信品質を確保するための所定の
制御メッセージの処理を行なう機能を持たない通信端末
が存在しても、該通信端末のために一定水準の通信品質
を確保することの可能な通信帯域通知装置、通信システ
ム及び通信帯域確保方法を提供すること。 【解決手段】 一定水準の通信品質を確保するために送
信端末および受信端末の少なくとも一方が所定の制御メ
ッセージを送信して網内に帯域を確保する通信帯域確保
方式を用いた通信網に接続された通信帯域通知装置であ
って、自装置の対象とする端末が前記送信端末である場
合の該端末が行うべき所定の制御メッセージの送出を含
む処理および自装置の対象とする端末が前記受信端末で
ある場合の該端末が行うべき所定の制御メッセージの送
出を含む処理のうち少なくとも一方を代行する手段を備
えたことを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、パケット通信網に
おける一定水準の通信品質を提供するための通信帯域通
知装置、通信システム及び通信帯域確保方法に関する。

【０００２】

【従来の技術】端末間のパケット転送に供する通信網の
１つにＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網
がある。

【０００３】ＩＰ網では、パケットの転送を行なうルー
タに到着するパケット量が多くなれば、パケットの被る
遅延量は大きくなる。これは、インターネットプロトコ
ルが、通信品質の保証を考慮せずにプロトコル設計され
ているためである。そのため本来ＩＰ網では、ユーザに
対して通信品質を保証することはできない。しかし、例
えば動画像通信を行なうためには、パケット転送遅延等
の通信品質の保証を行なう必要が生じ、そこでＩＰ網に
おいて通信品質の保証を行なうための検討が盛んに行な
われている。

【０００４】例えば、ＩＥＦＴと称する標準化機関で
は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉ
ｏｎ Ｐｒｏｔｏｃｏｌ）と呼ばれる必要帯域を通知す
る方式が提案されている。この方式では、Ｐａｔｈメッ
セージ、Ｒｅｓｖメッセージ、Ｐａｔｈ Ｔｅａｒメッ
セージ、Ｒｅｓｖ Ｔｅａｒメッセージ、Ｐａｔｈ Ｅ
ｒｒメッセージ、Ｒｅｓｖ Ｅｒｒメッセージ、Ｃｏｎ
ｆｉｒｍａｔｉｏｎメッセージと呼ばれる７種類の制御
メッセージが用いられる。ＲＳＶＰの基本動作は、送信
端末がＰａｔｈメッセージと呼ばれる制御メッセージを
用いて送信トラヒック特性を、網および受信端末に通知
し、受信端末がＲｅｓｖメッセージと呼ばれる制御メッ
セージを用いて確保すべき必要帯域を網に通知するとい
うものである。Ｐａｔｈメッセージのフィールドの値が
不適当なものであった場合、網はＰａｔｈ Ｅｒｒメッ
セージを送出し、Ｒｅｓｖメッセージのフィールドの値
が不適当なものであった場合、網はＲｅｓｖ Ｅｒｒメ
ッセージを送出する。また、送信端末からＰａｔｈ Ｔ
ｅａｒメッセージを、あるいは受信端末からＲｅｓｖＴ
ｅａｒメッセージを送出することにより、確保した帯域
をただちに削除することができる。ＲＳＶＰでは、網に
よる通信経路の変更やルータの故障に対応するため、定
期的にＰａｔｈメッセージおよびＲｅｓｖメッセージの
送出を行なっている。

【０００５】図１５は、ＲＳＶＰのＰａｔｈメッセージ
とＲｅｓｖメッセージの流れを示した図である。

【０００６】図１５において、送信端末Ｓ１（図中５０
１）とＳ２（図中５０２）は、受信端末Ｄ１（図中６０
１）とＤ２（図中６０２）の参加するマルチキャストグ
ループに向けてデータパケットを送出している。そし
て、図１５（ａ）に示すように、送信端末Ｓ１とＳ２は
それぞれ、データパケットの宛先アドレスと同じ宛先ア
ドレスを付けたＰａｔｈメッセージを送出する。Ｐａｔ
ｈメッセージの宛先アドレスをデータパケットの宛先ア
ドレスと等しくすることにより、Ｐａｔｈメッセージと
データパケットが同じ経路を通るため、データパケット
の経路上のルータは、Ｐａｔｈメッセージにより送信端
末の送出するトラフィック特性を知ることができ、さら
に前段のルータのアドレスも知ることができる。例えば
ルータ７０１，７０２，７０４は、送信端末Ｓ１の送出
するトラフィック特性を知ることができ、例えばルータ
７０２は前段のルータ７０１のアドレスを知ることがで
きる。

【０００７】また、受信端末は、帯域確保を網に指示す
るため、Ｒｅｓｖメッセージを送出する。図１５（ｂ）
は、受信端末Ｄ１がＲｅｓｖメッセージを送出した場合
のＲｅｓｖメッセージの流れを示している。受信端末Ｄ
１は、前段のルータ７０２に向けてＲｅｓｖメッセージ
を送出し、これが経路上のルータへ転送されていくこと
により、帯域確保の指示が経路上の全ルータ７０２，７
０１，７０３と送信端末Ｓ１とＳ２に伝わる。図１５
（ｃ）は、受信端末Ｄ２が経路上のルータに帯域確保の
要求を行なうために、Ｒｅｓｖメッセージを送出した場
合のＲｅｓｖメッセージの流れを示している。受信端末
Ｄ２は、前段のルータ７０４に向けてＲｅｓｖメッセー
ジを送出し、これが経路上のルータへ転送されていくこ
とにより、帯域確保の要求が経路上の全ルータ７０１〜
７０４と送信端末Ｓ１とＳ２に伝わる。

【０００８】このように、ＲＳＶＰの必要帯域通知の手
順は、送信端末と受信端末が制御メッセージを送信する
ことにより行なわれる。また、この制御メッセージの送
信は定期的に繰り返される。このＲＳＶＰの手順は、イ
ンターネットドラフト“Ｒｅｓｏｕｒｃｅ ＲｅＳｅｒ
Ｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＳＶＰ）−Ｖｅｒ
ｓｉｏｎ１ Ｆｕｎｃｔｉｏｎａｌ Ｓｐｅｃｉｆｉｃ
ａｔｉｏｎ”：（ｄｒａｆｔ−ｉｅｔｆ−ｒｓｖｐ−ｓ
ｐｅｃ１３）に詳しく記載されている。

【０００９】このようにＲＳＶＰでは、ＲＳＶＰメッセ
ージの送受信を端末が行なうため、ＲＳＶＰプロトコル
を動作されるための機能が送信・受信端末の両方に必要
となり、従来のＲＳＶＰ機能を持たない端末に対しては
帯域を確保できないという問題点が生じる。この問題点
は、送信・受信端末の両方がＲＳＶＰ機能を持たない場
合にのみ生じるのではなく、いずれか一方の端末がＲＳ
ＶＰ機能を持たない場合にも生じるため非常に深刻な問
題である。

【００１０】また、ＲＳＶＰは、個々の端末が自分の受
け取るパケット流に対する所望の帯域を網に通知する方
式であるため、宛先アドレスが異なる複数のパケット流
を多重したパケット流に対して帯域を確保することが困
難である。

【００１１】一方、ＰＤＡ等の小型携帯端末に通信機能
を付加し、携帯電話あるいはＰＨＳあるいは有線電話の
回線を利用してデータ通信を行なう製品も発売されてい
る。また、ネットワークコンピュータ（日経コミュニケ
ーション：日経ＢＰ社、ｐｐ．８２−，Ｎｏ．２２６，
１９９６）と呼ばれるネットワーク接続を前提に設計さ
れた端末も提案されている。このようなネットワークコ
ンピュータや小型携帯端末は、ＣＰＵの能力が限定され
る場合が多く、また接続回線の容量も小さい場合が多
い。

【００１２】このようにＣＰＵ能力の限られている小型
携帯端末を用いたインタネット通信にＲＳＶＰを適用す
る場合、ＲＳＶＰでは、制御メッセージを定期的に送受
信する必要のあるため、このメッセージの処理負荷がＣ
ＰＵを圧迫する可能性がある。

【００１３】また、無線回線を経由してインターネット
にＲＳＶＰを適用する場合、繰り返し送信されるＲＳＶ
Ｐ制御メッセージが無線通信路の通信容量を圧迫する可
能性がある。

【００１４】ここでは、具体例として、ＩＰ網における
ＲＳＶＰ方式をあげたが、ＲＳＶＰに限らず、送受信端
末により制御パケットを送信することにより、通信網上
に帯域を確保する方式は存在し、また今後も出現するこ
とが予想され、またＩＰ網のように本来は通信品質を保
証することのできない網は存在し、また今後も出現する
ことが予想される。

【００１５】

【発明が解決しようとする課題】以上説明したように、
ＩＰ網において通信品質を保証するためには、ＲＳＶＰ
等を用いて必要帯域を確保する必要があり、このために
は送受信端末より制御パケットを定期的に送信すること
が必要となる。

【００１６】しかし、ＲＳＶＰ制御メッセージを端末が
送信するためには、端末にこのＲＳＶＰ機能を新たに追
加しなければならず、ＲＳＶＰ機能を持たない端末に対
しては帯域を確保することができないという第１の問題
点がある。

【００１７】また、ＲＳＶＰでは、個々の端末が自分の
受け取るパケット流に対する所望の帯域を網に通知する
方式であるため、宛先アドレスが異なる複数のパケット
流全体に対して帯域を保証することが困難であるという
第２の問題点がある。

【００１８】また、小型携帯端末のようにＣＰＵの処理
能力の低い端末がＲＳＶＰを用いた帯域確保を行なおう
とする場合、定期的に制御メッセージを送信しなければ
ならず、このメッセージの処理が端末のＣＰＵ処理能力
を圧迫するという第３の問題点がある。

【００１９】また、例えば端末を携帯電話とモデムを利
用して網に接続する場合のように、端末と網との接続通
信線の通信容量が小さい場合、ＲＳＶＰの制御メッセー
ジが接続通信回線を圧迫するという第４の問題点があ
る。

【００２０】本発明は、上記事情を考慮してなされたも
ので、一定水準の通信品質を確保するための所定の制御
メッセージの処理を行なう機能を持たない通信端末が存
在しても、該通信端末のために一定水準の通信品質を確
保することの可能な通信帯域通知装置、通信システム及
び通信帯域確保方法を提供することを目的とする。

【００２１】

【課題を解決するための手段】本発明（請求項１）は、
一定水準の通信品質を確保するために送信端末および受
信端末の少なくとも一方が所定の制御メッセージを送信
して網内に帯域を確保する通信帯域確保方式を用いた通
信網に接続された通信帯域通知装置であって、自装置の
対象とする端末が前記送信端末である場合の該端末が行
うべき所定の制御メッセージの送出を含む処理および自
装置の対象とする端末が前記受信端末である場合の該端
末が行うべき所定の制御メッセージの送出を含む処理の
うち少なくとも一方を代行する手段を備えたことを特徴
とする。

【００２２】通信帯域通知装置が前記代行を行う契機
は、送信側では、例えば、自装置が対象とするものとし
て登録されている端末からデータパケットが送出された
ことを検出したこと、あるいは端末からの明示的な要求
を受信したことなどによる。

【００２３】また、受信側では、例えば、自装置が対象
とするものとして登録されている端末宛に所定の制御メ
ッセージが転送されてきたことを検出したこと、あるい
は端末からの明示的な要求を受信したことなどによる。

【００２４】通信帯域通知装置は、自装置が対象とし得
る端末で前記処理を実行する機能を持たないものについ
て、上記の送信側と受信側の両方の処理を代行するのが
好ましい。

【００２５】パケット転送を行う送受信端末において送
信端末の前記処理を代行する通信帯域通知装置と受信端
末の前記処理を代行する他の通信帯域通知装置が存在す
る場合、２つの通信帯域通知装置間で所定の制御メッセ
ージのやり取りなどを行うことで、該２つの通信帯域通
知装置間に必要帯域を確保する。

【００２６】パケット転送を行う送受信端末において送
信端末および受信端末の一方は自装置が前記処理を実行
し、他方は前記通信帯域通知装置が前記処理を代行する
場合、送信端末と通信帯域通知装置との間または通信帯
域通知装置と受信端末との間で所定の制御メッセージの
やり取りなどを行うことで、送信端末と通信帯域通知装
置との間または通信帯域通知装置と受信端末との間に必
要帯域を確保する。

【００２７】なお、パケット転送を行う送受信端末にお
いて送信端末および受信端末の両方が自装置で前記処理
を実行する場合には、従来通り、送信端末と受信装置と
の間で所定の制御メッセージのやり取りなどを行うこと
で、送信端末と受信端末との間に必要帯域を確保する。

【００２８】このように本発明によれば、例えばインタ
ーネットプロトコルにおけるＲＳＶＰメッセージを処理
するような機能を持たない通信端末が存在しても、該通
信端末のために網内に一定水準の通信品質を確保するこ
とができる。

【００２９】本発明（請求項２）は、一定水準の通信品
質を確保するために送信端末および受信端末の少なくと
も一方が所定の制御メッセージを送信して網内に帯域を
確保する通信帯域確保方式を用いた通信システムであっ
て、自装置の対象とする端末が前記送信端末である場合
の該端末が行うべき所定の制御メッセージの送出を含む
処理および自装置の対象とする端末が前記受信端末であ
る場合の該端末が行うべき所定の制御メッセージの送出
を含む処理のうち少なくとも一方を代行する通信帯域通
知装置を、少なくとも１つ備えたことを特徴とする。

【００３０】本発明（請求項３）は、一定水準の通信品
質を確保するために送信端末および受信端末の少なくと
も一方が所定の制御メッセージを送信して網内に帯域を
確保する通信帯域確保方式を用いた通信システムであっ
て、自装置の対象とする端末が前記送信端末である場合
の該端末が行うべき所定の制御メッセージの送出を含む
処理および自装置の対象とする端末が前記受信端末であ
る場合の該端末が行うべき所定の制御メッセージの送出
を含む処理のうち少なくとも一方を代行する通信帯域通
知装置を、少なくとも１つ備え、前記送信端末を対象と
する通信帯域通知装置および前記受信端末を対象とする
他の通信帯域通知装置が存在する場合には、該通信帯域
通知装置間で所定の制御メッセージのやり取りを行っ
て、該通信帯域通知装置間に必要帯域を確保し、前記送
信端末および前記受信端末の少なくとも一方が前記通信
帯域通知装置による代行を利用しないものである場合に
は、前記送信端末もしくは前記受信端末と前記通信帯域
通知装置との間または前記送信端末と前記受信端末との
間で所定の制御メッセージのやり取りを行って、前記送
信端末もしくは前記受信端末と前記通信帯域通知装置と
の間または前記送信端末と前記受信端末との間に必要帯
域を確保することを特徴とする。

【００３１】本発明（請求項４）は、一定水準の通信品
質を確保するために送信端末および受信端末の少なくと
も一方が所定の制御メッセージを送信して網内に帯域を
確保する通信帯域確保方式を用いた通信網での通信帯域
確保方法であって、前記送信端末および受信端末以外の
ノード装置が、前記送信端末または受信端末に代わって
所定の制御メッセージの送信を含む処理を実行して、前
記通信網に必要帯域を確保させることを特徴とする。

【００３２】本発明（請求項５）は、一定水準の通信品
質を確保するために１対の送信端末および受信端末の少
なくとも一方が所定の制御メッセージを送信して網内に
帯域を確保する通信帯域確保方式を用いた通信網での通
信帯域確保方法であって、前記送信端末および受信端末
以外の第１のノード装置が、前記送信端末に代わって所
定の制御メッセージの送信を含む処理を実行し、前記送
信端末および受信端末以外の第２のノード装置が、前記
受信端末に代わって所定の制御メッセージの送信を含む
処理を実行して、前記通信網に必要帯域を確保させるこ
とを特徴とする。

【００３３】好ましくは、前記必要帯域通知手段の送出
する前記制御メッセージを、前記送受信端末間の経路の
一部に流すことにより、前記経路の一部にのみ帯域を確
保するようにしても良い。

【００３４】この場合、無線通信回線のように容量の小
さい通信回線には、制御メッセージを通過させないよう
にすることができる。

【００３５】本発明（請求項７）は、一定水準の通信品
質を確保するために１対の送信端末および受信端末の少
なくとも一方が所定の制御メッセージを送信して網内に
帯域を確保する通信帯域確保方式を用いた通信網での通
信帯域確保方法であって、前記送信端末またはその代行
を行う第１の通信帯域通知装置が所定の制御メッセージ
の送出を含む処理を実行し、前記受信端末またはその代
行を行う第２の通信帯域通知装置が所定の制御メッセー
ジの送出を含む処理を実行して、前記第１の通信帯域通
知装置と前記受信端末との間、前記送信端末と前記第２
の通信帯域通知装置との間、または前記第１および第２
の通信帯域通知装置間に必要帯域を確保することを特徴
とする。

【００３６】好ましくは、前記送信端末の送出するパケ
ットはインターネットプロトコルパケットである。

【００３７】また、好ましくは、前記制御メッセージは
ＲＳＶＰメッセージである。

【００３８】また、好ましくは、前記制御メッセージに
よりパケット流の属性を網に通知し、同一属性を通知さ
れたパケット流全体に対する帯域を網に確保するように
しても良い。

【００３９】ここで、属性とは、帯域を確保するパケッ
ト流のまとまりを示すものであり、陽に識別子により示
されても良いし、暗にアドレスから導きだされるもので
も良い。

【００４０】なお、以上の各方法に係る発明は装置に係
る説明としても成立し、各装置に係る発明は方法に係る
説明としても成立する。

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

【００４２】

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

【００４３】本実施形態では、ＩＰ網にＲＳＶＰを適用
した場合を例に取って説明するが、端末が制御メッセー
ジを送受信するパケット通信方式であれば、ＲＳＶＰを
ＩＰ網に適用した場合と同様に本発明を適用することが
できる。

【００４４】最初に、本発明が適用されるネットワーク
の具体例としてＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃ
ｏｌ）網の一例を示す。

【００４５】図１は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏ
ｔｏｃｏｌ）網の概念図を示す。本ＩＰ網は、複数の端
末１０１〜１０５や複数のルータ２０１〜２０４から構
成され、ルータ・ルータ間またはルータ・端末間または
端末・端末間は接続回線３０１〜３０６を用いて接続し
ている。接続回線は、例えば、イーサネット、ＦＤＤ
Ｉ、ＡＴＭ網、既存電話網、ＰＨＳ網、無線網等の所望
の通信網により実現される。送信元端末から送出された
パケットは、ルータを介するなどして所望の宛先端末ま
で転送される。

【００４６】図１のＩＰ網において、必要帯域の確保・
解放は、端末により送出されるＲＳＶＰメッセージによ
り実現される。端末はＲＳＶＰメッセージを定期的に網
に送信し、ルータ２０１〜２０３は受信した制御メッセ
ージの指示に従い帯域の確保・解放を行なう。このと
き、イーサスイッチ・ＡＴＭスイッチ等のルータ間を接
続するために使用されている他のネットワーク機器もＲ
ＳＶＰメッセージを理解し、ルータ２０１〜２０３と同
様に必要帯域の確保・解放を行なうこともある。

【００４７】以上に、本発明が適用されるネットワーク
の具体例を示した。

【００４８】（第１の実施形態）まず、本発明の第１の
実施形態について説明する。

【００４９】本実施形態では、送信端末に代わってＲＳ
ＶＰメッセージを送出し、また受信したＲＳＶＰメッセ
ージの処理を行う、必要帯域通知装置について説明す
る。

【００５０】図２に、本実施形態に係る通信システムの
構成例を示す。

【００５１】図２において、送信端末８０１からＩＰ網
１１００を介して受信端末９０１へ向けデータパケット
を送出する場合を考える。本実施形態では、送信端末８
０１はＲＳＶＰメッセージの送出は行なわずデータパケ
ットのみの送出を行ない、必要帯域通知装置１００１が
Ｐａｔｈメッセージ等の送信端末が送出すべきＲＳＶＰ
メッセージを送信端末８０１に代わって送出する。

【００５２】必要帯域通知装置１００１の送出したＲＳ
ＶＰメッセージはＩＰ網１１００を通過して受信端末９
０１に到着し、そして受信端末９０１が送出したＲｅｓ
ｖメッセージはＩＰ網１１００を介して必要帯域通知装
置１００１に到着し、この必要帯域通知装置１００１が
到着したＲｅｓｖメッセージに対する必要な処理を送信
端末８０１の代わりに行なう。このとき、受信端末９０
１により送信されたＲＳＶＰメッセージは、必要帯域通
知装置１００１にてブロックし、送信端末８０１への接
続回線１２０１へは転送しないことが望ましい。

【００５３】必要帯域通知装置１００１が送信端末８０
１に代わってＲＳＶＰ処理を行なうことにより、送信端
末８０１はＲＳＶＰ処理を理解する必要がなく、送信端
末８０１にＲＳＶＰを動作させる機能がなくとも、ＩＰ
網１１００に帯域を確保することが可能となる。また、
送信端末でＲＳＶＰメッセージの処理を行なう必要がな
いため、送信端末８０１の処理負荷を減ずることが可能
となる。また、送信端末８０１と必要帯域通知装置１０
０１との間の接続回線１２０１をＲＳＶＰメッセージが
通過しないため、接続回線１２０１の通信容量をＲＳＶ
Ｐメッセージで圧迫することもない。

【００５４】ただし、必要帯域通知装置１００１の送出
するＰａｔｈメッセージや他のＲＳＶＰメッセージは、
あたかも送信端末８０１が送出したかのようにＩＰ網１
１００のルータに理解されるようＩＰヘッダのソースア
ドレスおよびＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェ
クトには、送信端末８０１のアドレスが記述されている
ことが望ましい。

【００５５】なお、図２では、送信端末８０１と必要帯
域通知装置１００１との間は直接接続されているが、そ
うではなく図２中の送信端末８０２のように公衆電話網
１２０２を介して必要帯域通知装置１００１とが接続さ
れていても、またＰＨＳ等の無線網やルータ網等の他の
形態のネットワークを介して送信端末と必要帯域通知装
置１００１とが接続されていても構わない。

【００５６】次に、本実施形態の必要帯域通知装置１０
０１が送信端末に代わってＰａｔｈメッセージを出す契
機を与えるためのいくつかの方法について説明する。

【００５７】まず、静的に設定されるテーブルを用いる
方法について説明する。

【００５８】必要帯域通知装置１００１がＰａｔｈメッ
セージを送出するためには、代行する送信端末とその受
信端末のアドレス、ポート番号等の情報が必要である。
この情報を、必要帯域通知装置１００１が参照可能なテ
ーブルに予め設定することにより、必要帯域通知装置１
００１はＰａｔｈメッセージを送出することができる。
図３にこのテーブルの構成例を示す。

【００５９】必要帯域通知装置１００１は、図３に示す
ようなＴｓｐｅｃ検索テーブルを参照し、各エントリに
対応するＰａｔｈメッセージを送出する。例えば、図３
のＴｓｐｅｃ検索テーブルの最初のエントリに対応し
て、必要帯域通知装置１００１は、セッションオ（ＳＥ
ＳＳＩＯＮ）ブジェクトに、宛先アドレス２２２．３
３．４４．５５、宛先ポート番号２０００、プロトコル
番号１７を記し、ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブ
ジェクトに送信元アドレス１１１．２２２．３３．４
４、送信元ポート１０００を記し、ＳＥＮＤＥＲ＿ＴＳ
ＰＥＣオブジェクトにＡという値を記したＰａｔｈメッ
セージを定期的に送出する。

【００６０】なお、必要帯域通知装置１００１は、図３
のテーブルに登録された送信元アドレス，送信元ポート
番号，宛先アドレス，宛先ポート番号，プロトコル番号
の値をヘッダに持つデータパケットを検出した場合にＰ
ａｔｈメッセージの送出を開始するようにするのが好ま
しい。

【００６１】なお、Ａは現在の仕様ではベクトル量であ
り、トークン・バケット・レート（Ｔｏｋｅｎ ｂａｃ
ｋｅｔ ｒａｔｅ），トークン・バケット・デプス（Ｔ
ｏｋｅｎ ｂａｃｋｅｔ ｄｅｐｔｈ），ピーク・レー
ト（ｐｅａｋ ｒａｔｅ），ミニマム・ポリスド・ユニ
ット（ｍｉｎｉｍｕｍ ｐｏｌｉｃｅｄ ｕｎｉｔ），
マキシマム・パケット・サイズ（Ｍａｘｉｍｕｍ ｐａ
ｃｋｅｔ ｓｉｚｅ）からなる。このＴｓｐｅｃに関し
ては、“Ｔｈｅ Ｕｓｅ ｏｆ ＲＳＶＰ ｗｉｔｈ
ＩＥＴＦ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ”
（ｄｒａｆｔ−ｉｅｔｆ−ｉｎｔｓｅｒｖ−ｒｓｖｐ−
ｕｓｅ−００．ｔｘｔ）に詳しい。

【００６２】図３のＴｓｐｅｃ検索テーブルのエントリ
は、網の管理者により設定される。あるいは、端末の起
動時にその端末に関するエントリをその端末からロード
しても良い。

【００６３】次に、端末からのデータパケットの観測に
よりＰａｔｈメッセージの送出を開始する方法について
説明する。

【００６４】必要帯域通知装置１００１は、送信端末が
データパケットを送出するのを発見すると、そのデータ
パケットのアドレス、ポート番号等からＰａｔｈメッセ
ージを送出するか否かを判断し、Ｐａｔｈメッセージを
送出すると判断した場合には、予め定められたＴｓｐｅ
ｃの値を書き込んだＰａｔｈメッセージを送出する。

【００６５】図４に、Ｐａｔｈメッセージを送出するか
否かの判断をし、Ｐａｔｈメッセージを送出する場合に
はそのＴｓｐｅｃの値を決定するためのＴｓｐｅｃ検索
テーブルの構成例を示す。この場合、Ｔｓｐｅｃ検索テ
ーブルに該当するエントリが存在すれば、ＲＳＶＰのフ
ローを定義するデータパケットの送信元アドレス・送信
ポート番号・宛先アドレス・宛先ポート番号・プロトコ
ル番号とからＴｓｐｅｃの値を求めて、Ｐａｔｈメッセ
ージの送出を開始し、Ｔｓｐｅｃ検索テーブルに該当す
るエントリが存在しないならば、Ｐａｔｈメッセージの
送出は行わない。なお、図４において示される記号＊
（アスタリスク）は任意の値を意味する。もし、Ｔｓｐ
ｅｃ検索テーブルに一致するエントリが複数存在する場
合、明に一致する部分が長いエントリを採用することと
する。

【００６６】例えば、必要帯域通知手段１００１は、送
信元アドレス１１１．２２２．３３．４４、送信元ポー
ト番号１０００、宛先アドレス２２２．３３．４４．５
５、宛先ポート番号２０００、プロトコル番号１７のパ
ケットを検出した場合には、Ｔｓｐｅｃの値がＤである
Ｐａｔｈメッセージの送出を開始し、また送信元アドレ
ス１１１．２２２．３３．４４、送信元ポート番号１０
００で宛先アドレスが２２２．３３３．０．０から２２
２．３３３．２５５．２５５迄でしかも２２２．３３．
４４．５５以外のパケットを検出した場合には、宛先ポ
ート番号、プロトコル番号に関係なくＴｓｐｅｃの値が
ＥのＰａｔｈメッセージの送出を開始する。

【００６７】次に、端末から明にＴｓｐｅｃを教えても
らう方法について説明する。

【００６８】Ｐａｔｈメッセージの送出の開始を指示す
るために、その旨を記したＰａｔｈ送出要求メッセージ
を、端末８０１が必要帯域通知装置１００１に送出して
も良い。必要帯域通知装置１００１が、Ｐａｔｈメッセ
ージを送出するために必要なＴｓｐｅｃ等の情報を、こ
のＰａｔｈ送出要求メッセージに記すことにより、必要
帯域通知装置１００１はＰａｔｈメッセージを送出する
ことができる。このＰａｔｈ送出要求メッセージのパケ
ットフォーマットの例を図５に示す。

【００６９】次に、本必要帯域通知装置のＰａｔｈメッ
セージの送出を止める契機を与える方法について説明す
る。

【００７０】必要帯域通知装置１００１は、データパケ
ットの有無に関わらずＰａｔｈメッセージを出し続けて
も良いが、データパケットをある一定時間みつけること
ができなかった場合に、それに該当するＰａｔｈメッセ
ージの送出を停止することが望ましい。これにより送信
端末８０１はデータの送出を停止するだけで必要帯域通
知装置１００１によるＰａｔｈメッセージの送出を停止
させることができる。

【００７１】次に、本実施形態においてＲＳＶＰを処理
する機能を持つＲＳＶＰ端末の扱いについて説明する。

【００７２】必要帯域通知装置１００１は、送信端末８
０３がＲＳＶＰ機能を持つ場合、送信端末８０３に関す
るＲＳＶＰメッセージの処理を行なう必要はない。送信
端末８０３がＲＳＶＰ機能を持つか否かは、必要帯域通
知装置１００１に予め送信端末８０３がＲＳＶＰ機能を
持つか否かを設定することにより判断することができ
る。あるいは、送信端末８０３が送出したＲＳＶＰメッ
セージを発見した場合に、送信端末８０３がＲＳＶＰ機
能を持つと判断しても良い。

【００７３】また、図２では、送信端末にて送出された
パケットが必要帯域通知装置１００１を経由するように
示しているが、必要帯域通知装置１００１が図３に示し
た予め設定されるテーブルを用いてＲＳＶＰ処理を行な
う場合には、送信端末８０１〜８０３のパケットのＩＰ
網１１００内の経路と、必要帯域通知装置１００１の送
出するＲＳＶＰメッセージのＩＰ網１１００内の経路と
が同じであれば、送信端末の送出したパケットが必要帯
域通知装置１００１を経由しないようにしても構わな
い。

【００７４】（第２の実施形態）次に、本発明の第２の
実施形態について説明する。

【００７５】本実施形態では、受信端末に代わってＲＳ
ＶＰメッセージを受信し、また受信したＲＳＶＰメッセ
ージの処理を行う、必要帯域通知装置について説明す
る。

【００７６】図６に、本実施形態に係る通信システムの
構成例を示す。

【００７７】図６において、送信端末８０１からＩＰ網
１１００を介して受信端末９０１へ向けデータパケット
を送出する場合を考える。本実施形態では、送信端末８
０１はＩＰ網１１００を介して受信端末９０１へ向けデ
ータパケットを送出し、またＰａｔｈメッセージの送出
も行なっている。必要帯域通知装置１００２は送信端末
８０１から送出されたＲＳＶＰメッセージを受信し、Ｒ
ｅｓｖメッセージ等の受信端末９０１が送出すべきＲＳ
ＶＰメッセージを受信端末９０１の代わりに送出して、
送信端末８０１と必要帯域通知装置１００２との間に帯
域を確保する。このとき、必要帯域通知装置１００２
は、送信端末８０１の送出したＲＳＶＰメッセージをブ
ロックして受信端末への接続回線１２０１へは転送しな
いことが望ましい。

【００７８】必要帯域通知装置１００２が受信端末９０
１の代わりにＲＳＶＰ処理を行なうことにより、受信端
末９０１はＲＳＶＰを理解する必要がなく、受信端末９
０１にＲＳＶＰを動作させる機能がなくとも、ＩＰ網１
１００に帯域を確保することが可能となる。また、受信
端末でＲＳＶＰメッセージの処理を行なう必要がないた
め、受信端末９０１の処理負荷を減ずることが可能とな
る。また、受信端末９０１と必要帯域通知装置１００２
との間の接続回線１２０１にＲＳＶＰメッセージを通過
させなくとも良いため、接続回線１２０１の通信容量を
ＲＳＶＰメッセージで圧迫することもない。

【００７９】なお、図６では、受信端末９０１と必要帯
域通知装置１００２との間は直接接続されているが、そ
うではなくＰＨＳ等の無線網あるいは公衆電話網あるい
はルータ網等のネットワークを介して受信端末と必要帯
域通知装置１００２とが接続されていても構わない。

【００８０】次に、本実施形態の必要帯域通知装置１０
０２が送信端末に代わってＲｅｓｖメッセージを出す契
機を与えるためのいくつかの方法について説明する。

【００８１】まず、ｆｌｏｗｓｐｅｃの決定にテーブル
を用いる方法について説明する。

【００８２】必要帯域通知装置１００２は、受信端末９
０１宛のＰａｔｈメッセージを発見すると、そのＰａｔ
ｈメッセージのアドレス、ポート番号等からＲｅｓｖメ
ッセージを送出するか否かを判断し、Ｒｅｓｖメッセー
ジを送出すると判断した場合には、予め定められたｆｌ
ｏｗｓｐｅｃの値を書き込んだＲｅｓｖメッセージを送
出するようにする。

【００８３】図７は、Ｒｅｓｖメッセージを送出するか
否かの判断をし、Ｒｅｓｖメッセージを送出する場合に
はそのサービスクラス、リザベーションスタイル、ｆｌ
ｏｗｓｐｅｃの値等のＲｅｓｖメッセージのパラメータ
を決定するためのリザーブパラメータ検索テーブルを示
す。図７では、Ｃｏｎｔｒｏｌｌｅｄ Ｌｏａｄ Ｓｅ
ｒｖｉｃｅと呼ばれるサービスクラスをＣＬで、Ｇｕａ
ｒａｎｔｅｅｄ Ｓｅｒｖｉｃｅと呼ばれるサービスク
ラスをＧで示している。また、Ｆｉｘｅｄ−Ｆｉｌｔｅ
ｒと呼ばれるリザベーションスタイルをＦＦで、Ｓｈａ
ｒｅｄ−Ｅｘｐｌｉｃｉｔと呼ばれるリザベーションス
タイルをＳＥで、Ｗｉｌｄｃａｒｄ−Ｆｉｌｔｅｒと呼
ばれるリザベーションスタイルをＷＦで示している。

【００８４】このリザーブパラメータ検索テーブルを用
いることにより、ＲＳＶＰフローを定義する送信元アド
レス・送信元ポート番号・宛先アドレス・宛先ポート番
号・プロトコル番号とからｆｌｏｗｓｐｅｃ等の値を求
めることができる。もし、リザーブパラメータ検索テー
ブルに該当するエントリが存在しない場合、Ｒｅｓｖメ
ッセージを送出しない。また、図７において示される記
号＊（アスタリスク）は任意の値を意味する。もし、リ
ザーブパラメータ検索テーブルに一致するエントリが複
数存在する場合、明に一致する部分が長いエントリが採
用される。

【００８５】例えば、必要帯域通知手段１００２は、送
信元アドレス１１１．２２２．３３．４４、送信元ポー
ト番号１０００、宛先アドレス２２２．３３．４４．５
５、宛先ポート番号２０００、プロトコル番号１７のパ
ケットを検出した場合、サービスクラスとしてＧｕａｒ
ａｎｔｅｅｄ Ｓｅｒｖｉｃｅを、リザベーションスタ
イルとしてＦｉｘｅｄ−Ｆｉｌｔｅｒスタイルを、ｆｌ
ｏｗｓｐｅｃの値としてａを記したＲｅｓｖメッセージ
の送出を開始し、また、送信元ポート番号１０００、宛
先アドレス２２２．３３．４４．５５、宛先ポート番号
２０００、プロトコル番号１７、送信元アドレスが１１
１．２２２．３３．０から１１１．２２２．３３．２５
５でかつ１１１．２２２．３３．４４以外の値を記した
Ｐａｔｈメッセージを検出した場合には、サービスクラ
スとしてＧｕａｒａｎｔｅｅｄＳｅｒｖｉｃｅを、リザ
ベーションスタイルとしてＦｉｘｅｄ−Ｆｉｌｔｅｒス
タイルを、ｆｌｏｗｓｐｅｃの値としてｃを記したＲｅ
ｓｖメッセージの送出を開始する。

【００８６】なお、第１の実施形態と同様に静的に設定
されるテーブルによる方法を用いてよい。

【００８７】次に、端末から明にｆｌｏｗｓｐｅｃを教
えてもらう方法について説明する。

【００８８】Ｒｅｓｖメッセージの送出の開始を指示す
るために、その旨を記したＲｅｓｖ送出要求メッセージ
を、受信端末９０１が必要帯域通知装置１００２に送出
しても良い。ｆｌｏｗｓｐｅｃ等の必要帯域通知装置１
００２がＲｅｓｖメッセージを送出するために必要な情
報をこのＲｅｓｖ送出要求メッセージに記すことによ
り、必要帯域通知装置１００２は容易にＲｅｓｖメッセ
ージを送出することができる。このＲｅｓｖ送出要求メ
ッセージのパケットフォーマットの例を図８に示す。

【００８９】次に、端末から通信品質を教えてもらう方
法について説明する。

【００９０】受信端末９０１が受信フローに対する通信
品質を、例えば“良い”、“適切”、“悪い”の三段階
で、必要帯域通知装置１００２に通知し、必要帯域通知
装置１００２はこの情報を基にＲｅｓｖメッセージの送
出を開始しても良い。必要帯域通知装置１００２がＲｅ
ｓｖメッセージの送出を行なっていない場合に、受信端
末９０１から通信品質が“悪い”旨を通知されたとき、
必要帯域通知装置１００２はＲｅｓｖメッセージの送出
を開始する。また、必要帯域通知装置１００２がＲｅｓ
ｖメッセージの送出を行なっている場合に、通信品質が
“悪い”旨を通知されたとき、必要帯域通知装置１００
２はｆｌｏｗｓｐｅｃの値を確保帯域が大きくなるよう
に変更してＲｅｓｖメッセージを送出する。また、必要
帯域通知装置１００２がＲｅｓｖメッセージの送出を行
なっている場合に、通信品質が“良い”を通知された場
合、必要帯域通知装置１００２はｆｌｏｗｓｐｅｃの値
を確保帯域が小さくなるように変更してＲｅｓｖメッセ
ージを送出する。

【００９１】図９に、受信端末９０１が受信フローの通
信品質を、通信帯域通知装置１００２に通知するための
通信品質通知メッセージのフォーマット例を示す。通信
品質メッセージの通信品質フィールドに、通信品質が
“良い”または“適切”または“悪い”のいずれかを記
載することにより、必要帯域通知装置１００２に受信フ
ローの通信品質を通知することができる。

【００９２】次に、本必要帯域通知装置のＲｅｓｖメッ
セージの送出を止める契機を与える方法について説明す
る。

【００９３】必要帯域通知装置１００２は、送信端末８
０１からのＰａｔｈメッセージをある一定期間みつける
ことができなかった場合にそれに該当するＲｅｓｖメッ
セージの送出を停止する。あるいは、送信端末８０１か
らのデータパケットをある一定期間みつけることができ
なかった場合にそれに該当するＲｅｓｖメッセージの送
出を停止しても良い。

【００９４】次に、本実施形態においてＲＳＶＰを処理
する機能を持つＲＳＶＰ端末の扱いについて説明する。

【００９５】必要帯域通知装置１００２は、受信端末９
０３がＲＳＶＰ機能を持つ場合、受信端末９０３に関す
るＲＳＶＰメッセージの処理を行なう必要はない。受信
端末９０３がＲＳＶＰ機能を持つか否かは、必要帯域通
知装置１００２に予め受信端末９０３がＲＳＶＰ機能を
持つか否かを設定することにより判断することができ
る。

【００９６】以上説明してきた第１の実施形態に係る必
要帯域通知装置は送信端末に代わってＲＳＶＰメッセー
ジの処理を行うものであり、第２の実施形態に係る必要
帯域通知装置は受信端末に代わってＲＳＶＰの処理を行
なうものであるが、必要帯域通知装置はこの両方の機能
を合わせ持つことが望ましい。このようにすれば自装置
が対象とする端末装置が送信側になる場合であっても受
信側になる場合であってもＲＳＶＰの処理を代行するこ
とができる。

【００９７】（第３の実施形態）次に、本発明の第３の
実施形態について説明する。

【００９８】本実施形態では、送信端末に代わってＲＳ
ＶＰメッセージを送出し、また受信したＲＳＶＰメッセ
ージの処理を行う、必要帯域通知装置について説明す
る。

【００９９】図１０に、本実施形態に係る通信システム
の構成例を示す。

【０１００】図１０において、送信端末８０１〜８０３
と通信帯域通知装置１００１は、イーサネット１２０１
を介してＩＰ網１１００に接続されている。イーサネッ
ト１２０１はブロードキャスト型のデータリンクであ
り、このイーサネット１２０１上に送出されたパケット
は、同一イーサネット１２０１に接続された任意の端末
により受信することが可能である。ここでは、端末を接
続する接続回線の具体例としてイーサネットを用いる
が、無線を用いて接続回線が実現されている場合のよう
に送信端末の送出したパケットを必要帯域通知装置１０
０１が受信できるものであれば、送信端末８０１〜８０
３と必要帯域通知装置１００１とＩＰ網１１００を接続
する接続回線はイーサネットである必要はない。

【０１０１】図１０において、送信端末８０１からＩＰ
網１１００を介して受信端末９０１へ向けデータパケッ
トを送出する場合を考える。本実施形態では、送信端末
８０１はＲＳＶＰメッセージの送出は行なわずデータパ
ケットのみの送出を行なっている。必要帯域通知装置１
００１はＰａｔｈメッセージ等の送信端末が送出すべき
ＲＳＶＰメッセージを送信端末８０１の代わりに送出し
ている。

【０１０２】必要帯域通知装置１００１の送出したＲＳ
ＶＰメッセージはＩＰ網１１００を通過して、受信端末
９０１に到着する。受信端末９０１が送出したＲｅｓｖ
メッセージはＩＰ網１１００を介してイーサネット１２
０１に到着する。必要帯域通知装置１００１は到着した
Ｒｅｓｖメッセージを受信して、これに対する必要なＲ
ＳＶＰの処理を送信端末８０１の代わりに行なう。

【０１０３】必要帯域通知装置１００１が送信端末８０
１に代わってＲＳＶＰ処理を行なうことにより、送信端
末８０１はＲＳＶＰを理解する必要がなく、送信端末８
０１にＲＳＶＰを動作させる機能がなくとも、ＩＰ網１
１００に帯域を確保することが可能となる。また、送信
端末でＲＳＶＰメッセージの処理を行なう必要がないた
め、送信端末８０１の処理負荷を減ずることが可能とな
る。

【０１０４】ただし、必要帯域通知装置１００１の送出
するＰａｔｈメッセージや他のＲＳＶＰメッセージは、
あたかも送信端末８０１が送出したかのようにＩＰ網１
１００のルータに理解されるようＩＰヘッダのソースア
ドレスおよびＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェ
クトには、送信端末８０１のアドレスが記述されている
ことが望ましい。

【０１０５】なお、図１０では、送信端末８０１と必要
帯域通知装置１００１とは同一イーサネット１２０１で
接続されているが、そうではなくＰＨＳ等の無線網ある
いは公衆電話網あるいはルータ網等のネットワークを介
して送信端末とイーサネット１２０１が接続されていて
も構わない。

【０１０６】次に、本実施形態の必要帯域通知装置１０
０１が送信端末に代わってＰａｔｈメッセージを出す契
機を与えるためのいくつかの方法について説明する。

【０１０７】まず、静的に設定されるテーブルを用いる
方法について説明する。

【０１０８】必要帯域通知装置１００１がＰａｔｈメッ
セージを送出するためには、代行する送信端末とその受
信端末のアドレス、ポート番号等の情報が必要である。
この情報を、必要帯域通知装置１００１が参照可能なテ
ーブルに予め設定することにより、必要帯域通知装置１
００１はＰａｔｈメッセージを送出することができる。
図３にこのテーブルの構成例を示す。

【０１０９】必要帯域通知装置１００１は、図３に示す
ようなＴｓｐｅｃ検索テーブルを参照し、各エントリに
対応するＰａｔｈメッセージを送出する。例えば、図３
のＴｓｐｅｃ検索テーブルの最初のエントリに対応し
て、必要帯域通知装置１００１は、セッション（ＳＥＳ
ＳＩＯＮ）オブジェクトに、宛先アドレス２２２．３
３．４４．５５、宛先ポート番号２０００、プロトコル
番号１７を記し、ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブ
ジェクトに送信元アドレス１１１．２２２．３３．４
４、送信元ポート１０００を記し、ＳＥＮＤＥＲ＿ＴＳ
ＰＥＣオブジェクトにＡという値を記したＰａｔｈメッ
セージを定期的に送出する。

【０１１０】なお、必要帯域通知装置１００１は、図３
のテーブルに登録された送信元アドレス，送信元ポート
番号，宛先アドレス，宛先ポート番号，プロトコル番号
の値をヘッダに持つデータパケットを検出した場合にＰ
ａｔｈメッセージの送出を開始するようにするのが好ま
しい。

【０１１１】図３のＴｓｐｅｃ検索テーブルのエントリ
は、網の管理者により設定される。あるいは、端末の起
動時にその端末に関するエントリをその端末からロード
しても良い。

【０１１２】次に、端末からのデータパケットの観測に
よりＰａｔｈメッセージの送出を開始する方法について
説明する。

【０１１３】必要帯域通知装置１００１は、送信端末が
データパケットを送出するのを発見すると、そのデータ
パケットのアドレス、ポート番号等からＰａｔｈメッセ
ージを送出するか否かを判断し、Ｐａｔｈメッセージを
送出すると判断した場合には、予め定められたＴｓｐｅ
ｃの値を書き込んだＰａｔｈメッセージを送出しても良
い。

【０１１４】図４は、Ｐａｔｈメッセージを送出するか
否かの判断をし、Ｐａｔｈメッセージを送出する場合に
はそのＴｓｐｅｃの値を決定するためのＴｓｐｅｃ検索
テーブルの構成例を示す。これを用いることにより、第
１の実施形態と同様にして、Ｐａｔｈメッセージを送出
するか否かの判断を行ない、Ｐａｔｈメッセージを送出
する場合には、そのＴｓｐｅｃの値を決定することがで
きる。

【０１１５】次に、端末から明にＴｓｐｅｃを教えても
らう方法について説明する。

【０１１６】Ｐａｔｈメッセージの送出の開始を指示す
るために、その旨記したＰａｔｈ送出要求メッセージ
を、端末８０１が必要帯域通知装置１００１に送出して
も良い。Ｔｓｐｅｃ等の必要帯域通知装置１００１がＰ
ａｔｈメッセージを送出するために必要な情報をこのＰ
ａｔｈ送出要求メッセージに記すことにより、必要帯域
通知装置１００１はＰａｔｈメッセージを送出すること
ができる。このＰａｔｈ送出要求メッセージのパケット
フォーマットの例を図５に示す。

【０１１７】次に、本必要帯域通知装置のＰａｔｈメッ
セージの送出を止める契機を与える方法について説明す
る。

【０１１８】必要帯域通知装置１００１は、データパケ
ットの有無に関わらずＰａｔｈメッセージを出し続けて
も良いが、データパケットをある一定時間みつけること
ができなかった場合に、それに該当するＰａｔｈメッセ
ージの送出を停止することが望ましい。これにより送信
端末８０１はデータの送出を停止するだけで必要帯域通
知装置１００１によるＰａｔｈメッセージの送出を停止
させることができる。

【０１１９】次に、本実施形態においてＲＳＶＰを処理
する機能を持つＲＳＶＰ端末の扱いについて説明する。

【０１２０】必要帯域通知装置１００１は、送信端末８
０２がＲＳＶＰ機能を持つ場合、送信端末８０２に関す
るＲＳＶＰメッセージの処理を行なう必要はない。送信
端末８０２がＲＳＶＰ機能を持つか否かは、必要帯域通
知装置１００１に予め送信端末８０２がＲＳＶＰ機能を
持つか否かを設定することにより判断することができ
る。あるいは、送信端末８０２が送出したＲＳＶＰメッ
セージを発見した場合に、送信端末８０３がＲＳＶＰ機
能を持つと判断しても良い。

【０１２１】（第４の実施形態）次に、本発明の第４の
実施形態について説明する。

【０１２２】本実施形態では、受信端末に代わってＲＳ
ＶＰメッセージを受信し、また受信したＲＳＶＰメッセ
ージの処理を行う、必要帯域通知装置について説明す
る。

【０１２３】図１１に、本実施形態に係る通信システム
の構成例を示す。

【０１２４】図１１において、受信端末９０１〜９０３
と通信帯域通知装置１００２は、イーサネット１２０１
を介してＩＰ網１１００に接続されている。イーサネッ
ト１２０１はブロードキャスト型のデータリンクであ
り、このイーサネット１２０１上に送出されたパケット
は、同一イーサネット１２０１に接続された任意の端末
により受信することが可能である。ここでは、端末を接
続する接続回線の具体例としてイーサネットを用いる
が、接続回線が無線を用いて実現されている場合のよう
に受信端末へ送出されたパケットを必要帯域通知装置１
００２が受信できるものであれば、受信端末９０１〜９
０３と必要帯域通知装置１００２とＩＰ網１１００を接
続する接続回線はイーサネットである必要はない。

【０１２５】図１１において、送信端末８０１からＩＰ
網１１００を介して受信端末９０１へ向けデータパケッ
トを送出する場合を考える。本実施形態では、送信端末
８０１がＩＰ網１１００を介して受信端末９０１へ向け
データパケットを送出するとともにＰａｔｈメッセージ
を送出しており、必要帯域通知装置１００２はＲｅｓｖ
メッセージ等の受信端末９０１が送出すべきＲＳＶＰメ
ッセージを受信端末９０１の代わりに送出して、ＩＰ網
１１００に受信端末９０１のための帯域を確保する。こ
れにより、受信端末９０１はＲＳＶＰを理解する必要が
なく、受信端末９０１にＲＳＶＰを動作させる機能がな
くとも、ＩＰ網１１００に帯域を確保することが可能と
なる。また、受信端末でＲＳＶＰメッセージの処理を行
なう必要がないため、受信端末９０１の処理負荷を減ず
ることが可能となる。

【０１２６】なお、図１１では、受信端末９０１と必要
帯域通知装置１００２とは同一イーサネット１２０１で
接続されているが、そうではなくＰＨＳ等の無線網ある
いは公衆電話網あるいはルータ網等のネットワークを介
して受信端末とイーサネット１２０１が接続されていて
も構わない。

【０１２７】次に、本実施形態の必要帯域通知装置１０
０２が送信端末に代わってＲｅｓｖメッセージを出す契
機を与えるためのいくつかの方法について説明する。

【０１２８】まず、ｆｌｏｗｓｐｅｃの決定にテーブル
を用いる方法について説明する。

【０１２９】必要帯域通知装置１００２は、受信端末９
０１宛のＰａｔｈメッセージを発見すると、そのＰａｔ
ｈメッセージのアドレス、ポート番号等からＲｅｓｖメ
ッセージを送出するか否かを判断し、Ｒｅｓｖメッセー
ジを送出すると判断した場合には、予め定められたｆｌ
ｏｗｓｐｅｃの値を書き込んだＲｅｓｖメッセージを送
出するようにする。

【０１３０】図７に示すリザーブパラメータ検索テーブ
ルを用いることにより、第２の実施形態の場合と同様に
して、Ｒｅｓｖメッセージを送出するか否かの判断を
し、Ｒｅｓｖメッセージを送出する場合には、そのサー
ビスクラス、リザベーションスタイル、ｆｌｏｗｓｐｅ
ｃの値等のＲｅｓｖメッセージのパラメータを決定する
ことができる。

【０１３１】なお、第３の実施形態と同様に静的に設定
されるテーブルによる方法を用いてよい。

【０１３２】次に、端末から明にＴｓｐｅｃを教えても
らう方法について説明する。

【０１３３】Ｒｅｓｖメッセージの送出の開始を指示す
るために、その旨を記したＲｅｓｖ送出要求メッセージ
を、受信端末９０１が必要帯域通知装置１００２に送出
しても良い。必要帯域通知装置１００２がＲｅｓｖメッ
セージを送出するために必要なｆｌｏｗｓｐｅｃ等の情
報をこのＲｅｓｖ送出要求メッセージに記すことによ
り、必要帯域通知装置１００２は容易にＲｅｓｖメッセ
ージを送出することができる。このＲｅｓｖ送出要求メ
ッセージのパケットフォーマットの例を図８に示す。

【０１３４】次に、端末から通信品質を教えてもらう方
法について説明する。

【０１３５】受信端末９０１が受信フローに対する通信
品質を、例えば“良い”、“適切”、“悪い”の三段階
で、必要帯域通知装置１００２に通知し、必要帯域通知
装置１００２はこの情報を基にＲｅｓｖメッセージの送
出を開始しても良い。第２の実施形態と同様に、必要帯
域通知装置１００２がＲｅｓｖメッセージの送出を行な
っていない場合に、受信端末９０１から通信品質が“悪
い”旨を通知されたとき、必要帯域通知装置１００２は
Ｒｅｓｖメッセージの送出を開始する。また、必要帯域
通知装置１００２がＲｅｓｖメッセージの送出を行なっ
ている場合に、通信品質が“悪い”旨を通知されたと
き、必要帯域通知装置１００２はｆｌｏｗｓｐｅｃの値
を確保帯域が大きくなるように変更してＲｅｓｖメッセ
ージを送出する。また、必要帯域通知装置１００２がＲ
ｅｓｖメッセージの送出を行なっている場合に、通信品
質が“良い”を通知された場合、必要帯域通知装置１０
０２はｆｌｏｗｓｐｅｃの値を確保帯域が小さくなるよ
うに変更してＲｅｓｖメッセージを送出する。

【０１３６】次に、本必要帯域通知装置のＲｅｓｖメッ
セージの送出を止める契機を与える方法について説明す
る。

【０１３７】必要帯域通知装置１００２は、送信端末８
０１からのＰａｔｈメッセージをある一定期間みつける
ことができなかった場合にそれに該当するＲｅｓｖメッ
セージの送出を停止する。あるいは、送信端末８０１か
らのデータパケットをある一定期間みつけることができ
なかった場合にそれに該当するＲｅｓｖメッセージの送
出を停止しても良い。

【０１３８】次に、本実施形態においてＲＳＶＰを処理
する機能を持つＲＳＶＰ端末の扱いについて説明する。

【０１３９】必要帯域通知装置１００２は、受信端末９
０２がＲＳＶＰ機能を持つ場合、受信端末９０２に関す
るＲＳＶＰメッセージの処理を行なう必要はない。受信
端末９０２がＲＳＶＰ機能を持つか否かは、必要帯域通
知装置１００２に予め受信端末９０２がＲＳＶＰ機能を
持つか否かを設定することにより判断することができ
る。

【０１４０】以上説明してきた第３の実施形態に係る必
要帯域通知装置は送信端末に代わってＲＳＶＰメッセー
ジの処理を行うものであり、第４の実施形態に係る必要
帯域通知装置は受信端末に代わってＲＳＶＰの処理を行
なうものであるが、必要帯域通知装置はこの両方の機能
を合わせ持つことが望ましい。このようにすれば自装置
が対象とする端末装置が送信側になる場合であっても受
信側になる場合であってもＲＳＶＰの処理を代行するこ
とができる。

【０１４１】次に、本発明の第５の実施形態について説
明する。

【０１４２】図１２に、本実施形態に係る通信システム
の構成例を示す。

【０１４３】図１２において、送信端末８０１からＩＰ
網１１００を介して受信端末９０１へ向けデータパケッ
トを送出する場合を考える。本実施形態では、送信端末
８０１はＩＰ網１１００を介して受信端末９０１へ向け
データパケットを送出している。同様に送信端末８０２
は受信端末９０２へ、送信端末９０２は受信端末９０２
へデータパケットを送出している。必要帯域通知装置１
００１は送信端末８０１〜８０３に代わってＰａｔｈメ
ッセージを送出する等のＲＳＶＰの動作を行なってい
る。必要帯域通知装置１００２は受信端末９０１〜９０
２に代わってＲｅｓｖメッセージを送出する等のＲＳＶ
Ｐを動作を行なっている。これにより。送信端末・受信
端末にＲＳＶＰ機能を持たなくとも、ＩＰ網１１００に
帯域の確保を行なうことができる。

【０１４４】このとき、送信端末側の必要帯域通知装置
１００１は、第１の実施形態に示した動作を行なうこと
により、送信端末になり代わってＲＳＶＰ処理を行なう
ことができる。

【０１４５】また、受信端末側の必要帯域通知装置１０
０２は、第２の実施形態に示した動作を行なうことによ
り、受信端末にまり代わりＲＳＶＰ処理を行なうことが
できる。

【０１４６】次に、複数のフローをまとめて帯域確保を
する場合について説明する。

【０１４７】本実施形態に係る必要帯域通知装置の送出
するＲＳＶＰメッセージは、ＲＳＶＰの仕様を定めたイ
ンタネットドラフト“Ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶ
ａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＳＶＰ）−Ｖｅｒｓ
ｉｏｎ１ Ｆｕｎｃｔｉｏｎａｌ Ｓｐｅｃｉｆｉｃａ
ｔｉｏｎ”：（ｄｒａｆｔ−ｉｅｔｆ−ｒｓｖｐ−ｓｐ
ｅｃ１３）に記載された通りのフォーマットを用いても
良いが、そうではなく、仕様とは異なるフォーマットの
独自のＲｅｓｖメッセージを用いても良い。

【０１４８】仕様通りのＲｅｓｖメッセージを送出した
場合、各図におけるＩＰ網１１００にて確保される帯域
は、セッションの異なる複数フローに対して帯域を確保
することはできない。しかしながら、独自のＲｅｓｖメ
ッセージを用いることによりセッションの異なる複数の
フローに対する帯域を確保することができる。ここで、
セッションとは、宛先アドレスと宛先ポート番号とプロ
トコル番号により定義されるものとし、フローとは、送
信元アドレス，送信元ポート番号，宛先アドレス，宛先
ポート番号，プロトコル番号で定義されるものとする。

【０１４９】図１３は、このＲｅｓｖメッセージの拡張
フォーマットの一例を示す。Ｒｅｓｖの仕様と異なる部
分は、メッセージにｒｅｓｅｒｖｅ ｌａｂｅｌフィー
ルドが追加されていることである。このｒｅｓｅｒｖｅ
ｌａｂｅｌは０以上の整数値を取る。この拡張Ｒｅｓ
ｖメッセージを受け取ったＩＰ網１１００内のルータ
は、同じｒｅｓｅｒｖｅ ｌａｂｅｌの値を持つフロー
に属するパケット流全体に対して、帯域を確保する。こ
れにより、複数のフローに対して帯域の確保を行なうこ
とができる。

【０１５０】ただし、このｒｅｓｅｒｖｅ ｌａｂｅｌ
は、通信プロトコルとしてＩＰｖ６を用いる場合には、
ＩＰｖ６ヘッダ内のｆｌｏｗ ｌａｂｅｌを用いること
もできる。ＩＰｖ６に関しては、ＩＥＴＦ ＲＦＣ１８
８３（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓ
ｉｏｎ ６（ＩＰｖ６） Ｓｐｅｓｉｆｉｃａｔｉｏ
ｎ）に詳しい。

【０１５１】通常のＲＳＶＰの動作との互換性を保つた
めに、ｒｅｓｅｒｖｅ ｌａｂｅｌの特定の値、例えば
０、を予約しておき、ｒｅｓｅｒｖｅ ｌａｂｅｌの値
が０の拡張Ｒｅｓｖメッセージを受け取ったルータは、
このｒｅｓｅｒｖｅ ｌａｂｅｌのフィールドを無視し
てＲｅｓｖの仕様書通りにセッション毎の帯域確保を行
なっても良い。

【０１５２】ＩＰ網１１００のルータがこの拡張Ｒｅｓ
ｖメッセージを受け取った場合の動作を次に示す。 （動作１） 受信Ｒｅｓｖメッセージより、フローｘと
ｒｅｓｅｒｖｅ ｌａｂｅｌ ｉを読み込む。 （動作２）もし、ｉ＝０であれば、通常のＲＳＶＰの動
作を行なう。 （動作３）もし、ｉ≠０であれば、ｒｅｓｅｒｖｅ ｌ
ａｂｅｌの値がｉであるフローの集合Ｘにフローｘを加
え、この新たなフローの集合Ｘ´（＝Ｘ＋ｘ）に対し
て、帯域を確保する。

【０１５３】次に、通信プロトコルとしてＩＰｖ６を用
い、ｒｅｓｅｒｖｅ ｌａｂｅｌとしてＩＰｖ６ヘッダ
内のｆｌｏｗ ｌａｂｅｌを用いる場合の例についての
説明を行う。

【０１５４】図１２のネットワーク構成を用いて説明す
ると、送信端末側の必要帯域通知装置１００１は、ある
フロー群に対応するｒｅｓｅｒｖｅ ｌａｂｅｌの値を
書き込んだ拡張Ｐａｔｈメッセージを生成し、これをデ
ータパケットの経路上へ送出する。この拡張Ｐａｔｈメ
ッセージのフォーマットの例を図１６に示す。拡張Ｐａ
ｔｈメッセージのｓｅｎｄｅｒ ｄｅｓｃｒｉｐｔｏｒ
フィールド内のＴｓｐｅｃの値は、もともと各送信端末
の送出するトラヒック特性を示すものであるが、この場
合フロー群全体のトラヒック特性を示すＴｓｐｅｃの値
を拡張Ｐａｔｈメッセージに記す。次に、拡張Ｐａｔｈ
メッセージを受け取った受信端末側の必要帯域通知装置
１００２は、受信した拡張Ｐａｔｈメッセージと同じ値
のｒｅｓｅｒｖｅ ｌａｂｅｌを持つ拡張Ｒｅｓｖメッ
セージを上流に向けて送出する。図１７にこの例に用い
る拡張Ｒｅｓｖメッセージのフォーマットの例を示す。
必要帯域通知装置１００１と１００２との間にあるＩＰ
網１１００内のルータは、ｒｅｓｅｒｖｅ ｌａｂｅｌ
と同じ値のｆｌｏｗ ｌａｂｅｌを持つデータパケット
に対して拡張Ｒｅｓｖメッセージで指示された帯域を確
保する。これにより、ＩＰ網１１００内のルータは各フ
ローを識別してＲＳＶＰのステートを保持する必要はな
く、ｒｅｓｅｒｖｅ ｌａｂｅｌ毎にＲＳＶＰのステー
トを保持すれば良く、ルータの必要メモリ量・処理負荷
を削減することが可能となる。

【０１５５】この例において拡張Ｐａｔｈメッセージは
必要帯域通知装置１００２より下流側には流さないこと
が望ましく、拡張Ｒｅｓｖメッセージは必要帯域通知装
置１００１より上流側には流さないことが望ましい。こ
の例において、拡張ＰａｔｈメッセージのＴｓｐｅｃの
値は、予め定められた値を用いても良いし、送信端末か
らＰａｔｈメッセージが送出される場合には、送出され
たＰａｔｈメッセージのＴｓｐｅｃの値を基に求められ
た値を用いても良い。また、拡張Ｒｅｓｖメッセージの
ｆｌｏｗ ｄｅｓｃｒｉｐｔｏｒの値は、予め定められ
た値を用いても良いし、受信端末からＲｅｓｖメッセー
ジが送出される場合には、送出されたＲｅｓｖメッセー
ジのｆｌｏｗ ｄｅｓｃｒｉｐｔｏｒの値を基に求めた
値を用いても良い。

【０１５６】図１２のネットワーク構成では、データパ
ケットは必要帯域通知装置１００１，１００２を通過す
るようになっているが、拡張Ｐａｔｈメッセージと拡張
Ｒｅｓｖメッセージを帯域確保を行うべき経路に流すこ
とができれば、必要帯域通知装置の位置は図１２の構成
に囚われない。

【０１５７】図１２のネットワーク構成のように、デー
タパケットが必要帯域通知装置１００１，１００２を通
過する場合、必要帯域通知装置１００１が帯域を確保す
べきデータパケットのＩＰｖ６ヘッダ内のｆｌｏｗ ｌ
ａｂｅｌの値を、拡張Ｐａｔｈメッセージに記したｒｅ
ｓｅｒｖｅ ｌａｂｅｌの値に書き換えて、ＩＰ網１１
００へ送出しても良い。この場合、必要帯域通知装置１
００２がデータパケットのｆｌｏｗ ｌａｂｅｌの値を
基に戻すことが望ましい。

【０１５８】次に、上記のｒｅｓｅｒｖｅ ｌａｂｅｌ
の代わりにＳＥＳＳＩＯＮオブジェクトのアドレスを利
用する例について説明する。

【０１５９】パケット流の属性を示すために、図１３の
拡張Ｒｅｓｖメッセージを用いるのではなく、仕様書通
りのＲｅｓｖメッセージのフォーマットを用いても良
い。仕様に従ったＲｅｓｖメッセージのフォーマットを
図１４に示す。この場合、ＳＥＳＳＩＯＮオブジェクト
に宛先アドレス・宛先ポート番号・プロトコル番号をそ
のまま記すのではなく、一部を０により置き換えてお
く。例えば、ＳＥＳＳＩＯＮオブジェクトに（宛先アド
レス、宛先ポート番号、プロトコル番号）として（１１
１．２２．３３．０，１０００，１７）というアドレス
を記していた場合、このセッションオブジェクトの値を
属性として扱う。これにより、宛先アドレスが１１１．
２２．３３．０〜１１１．２２．３３．２５５、宛先ポ
ート番号が１０００、プロトコル番号が１７のパケット
流全体に対する帯域の確保をＩＰ網１１００のルータに
指示することができる。このとき、例えば、（１１１．
２２．３３．４４，１０００，１７）を記したＲｅｓｖ
メッセージも併せて送出した場合は、宛先アドレスが１
１１．２２．３３．４４、宛先ポート番号が１０００、
プロトコル番号が１７のパケット流と、宛先アドレスが
１１１．２２．３３．０〜１１１．２２．３３．２５５
でかつ１１１．２２．３３．４４以外であり、宛先ポー
ト番号が１０００、プロトコル番号が１７のパケット流
との帯域を別個に確保することを意味する。

【０１６０】上記の例では、属性として（宛先アドレ
ス、宛先ポート番号、プロトコル番号）の組を用いた
が、そうではなく例えば宛先アドレスのみを用いて属性
を示しても良い。この場合、（宛先アドレス、宛先ポー
ト番号、プロトコル番号）＝（１１１．２２．３３．
０，１０００，１７）をＳＥＳＳＩＯＮオブジェクトに
記したＲｅｓｖメッセージは、宛先アドレスが１１１．
２２．３３．０〜１１１．２２．３３．２５５のパケッ
ト流全体に対する帯域の確保を意味する。

【０１６１】なお、端末が拡張Ｒｅｓｖメッセージを送
出してもよい。例えば、図１２において、受信端末９０
３はＲＳＶＰ機能を持っており、拡張Ｒｅｓｖメッセー
ジを送出する場合には、必要帯域通知装置１００２は、
受信端末９０３に対するＲＳＶＰの処理を行なわなくと
も良い。

【０１６２】また、端末がＰａｔｈメッセージを送出し
ても良い。例えば、送信端末８０３がＲＳＶＰ機能を持
つ場合には、必要帯域通知装置１００１は送信端末８０
３に対するＲＳＶＰの処理を行なわなくとも良い。

【０１６３】なお、図１２では、端末８０１〜８０３と
必要帯域通知装置１００１とは直接接続されているが、
この間をつなぐ接続回線１２０１〜１２０３は、例え
ば、イーサネット、ＦＤＤＩ、ＡＴＭ網、無線（ＰＨ
Ｓ）網、ルータ網、公衆電話網により実現されていても
構わない。

【０１６４】同様に、受信端末９０１〜９０３と必要帯
域通知装置１００１とは直接接続されているが、この間
をつなぐ接続回線１２０４〜１２０６は、例えば、イー
サネット、ＦＤＤＩ、ＡＴＭ網、無線（ＰＨＳ）網、ル
ータ網、公衆電話網により実現されていても構わない。

【０１６５】また、図１２では、送信端末により送出さ
れたパケットが必要帯域通知装置１００１を経由するよ
うに示しているが、必要帯域通知装置１００１が予め設
定された情報を用いてＲＳＶＰ処理を行なう場合には、
送信端末８０１〜８０３のパケットのＩＰ網１１００内
の経路と、必要帯域通知装置１００１の送出するＲＳＶ
ＰメッセージのＩＰ網１１００内の経路とが同じであれ
ば、送信端末の送出したパケットが必要帯域通知装置１
００１を経由しないようにしても構わない。

【０１６６】なお、必要帯域通知装置１００１と１００
２にそれぞれ、第１の実施形態および第２の実施形態の
両方の機能を持たせることにより、自装置が処理対象と
する端末が送信側と受信側のいずれになっても、ＲＳＶ
Ｐ処理を代行するころができる。

【０１６７】また、この実施形態にて説明した点は、第
３および第４の実施形態についても同様のことが言え
る。

【０１６８】さらに、上記した複数のフローをまとめて
帯域確保をするための構成については、他の実施形態に
ついても同様のことが言える。

【０１６９】また、以上の各機能は、ソフトウェアとし
ても実現可能である。また、上記した各手順あるいは手
段をコンピュータに実行させるためのプログラムを記録
した機械読取り可能な媒体として実施することもでき
る。

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

【０１７１】

【発明の効果】本発明によれば、必要帯域確保のための
所定の制御メッセージを処理する機能を持たない通信端
末が存在しても、該通信端末のために網内に一定水準の
通信品質を確保することができる。

【図面の簡単な説明】

【図１】ＩＰ網の概念図

【図２】必要帯域通知装置をＩＰ網と送信端末との間に
設置した場合の構成図

【図３】Ｔｓｐｅｃ検索テーブルの構成例を示す図

【図４】Ｔｓｐｅｃ検索テーブルの構成例を示す図

【図５】Ｐａｔｈ送出要求メッセージのフォーマットを
示す図

【図６】必要帯域通知装置をＩＰ網と受信端末との間に
設置した場合の構成図

【図７】リザーブパラメータ検索テーブルの構成例を示
す図

【図８】Ｒｅｓｖ送出要求メッセージのフォーマットを
示す図

【図９】通信品質通知メッセージのフォーマットの例を
示す図

【図１０】イーサネットに必要帯域通知装置を接続した
場合の構成図

【図１１】イーサネットに必要帯域通知装置を接続した
場合の構成図

【図１２】必要帯域通知装置を使用した通信方式を示す
図

【図１３】拡張Ｒｅｓｖメッセージのフォーマットの例
を示す図

【図１４】Ｒｅｓｖメッセージのフォーマットを示す図

【図１５】ＲＳＶＰのメッセージの流れを示す図

【図１６】拡張Ｐａｔｈメッセージ（ＩＰｖ６用）のフ
ォーマットを示す図

【図１７】拡張Ｒｅｓｖメッセージ（ＩＰｖ６用）のフ
ォーマットを示す図

【符号の説明】

１０１〜１０５，８０１〜８０３，９０１〜９０３…端
末 ２０１〜２０４，７０１，７０２…ルータ ３０１〜３０６，１２０１，１２０２…接続回線 １００１，１００２…必要帯域通知装置 １１００，１１０１…ＩＰ網

Claims (10)

【特許請求の範囲】
1. 【請求項１】一定水準の通信品質を確保するために送信
   端末および受信端末の少なくとも一方が所定の制御メッ
   セージを送信して網内に帯域を確保する通信帯域確保方
   式を用いた通信網に接続された通信帯域通知装置であっ
   て、 自装置の対象とする端末が前記送信端末である場合の該
   端末が行うべき所定の制御メッセージの送出を含む処理
   および自装置の対象とする端末が前記受信端末である場
   合の該端末が行うべき所定の制御メッセージの送出を含
   む処理のうち少なくとも一方を代行する手段を備えたこ
   とを特徴とする通信帯域通知装置。
2. 【請求項２】一定水準の通信品質を確保するために送信
   端末および受信端末の少なくとも一方が所定の制御メッ
   セージを送信して網内に帯域を確保する通信帯域確保方
   式を用いた通信システムであって、 自装置の対象とする端末が前記送信端末である場合の該
   端末が行うべき所定の制御メッセージの送出を含む処理
   および自装置の対象とする端末が前記受信端末である場
   合の該端末が行うべき所定の制御メッセージの送出を含
   む処理のうち少なくとも一方を代行する通信帯域通知装
   置を、少なくとも１つ備えたことを特徴とする通信シス
   テム。
3. 【請求項３】一定水準の通信品質を確保するために送信
   端末および受信端末の少なくとも一方が所定の制御メッ
   セージを送信して網内に帯域を確保する通信帯域確保方
   式を用いた通信システムであって、 自装置の対象とする端末が前記送信端末である場合の該
   端末が行うべき所定の制御メッセージの送出を含む処理
   および自装置の対象とする端末が前記受信端末である場
   合の該端末が行うべき所定の制御メッセージの送出を含
   む処理のうち少なくとも一方を代行する通信帯域通知装
   置を、少なくとも１つ備え、 前記送信端末を対象とする通信帯域通知装置および前記
   受信端末を対象とする他の通信帯域通知装置が存在する
   場合には、該通信帯域通知装置間で所定の制御メッセー
   ジのやり取りを行って、該通信帯域通知装置間に必要帯
   域を確保し、 前記送信端末および前記受信端末の少なくとも一方が前
   記通信帯域通知装置による代行を利用しないものである
   場合には、前記送信端末もしくは前記受信端末と前記通
   信帯域通知装置との間または前記送信端末と前記受信端
   末との間で所定の制御メッセージのやり取りを行って、
   前記送信端末もしくは前記受信端末と前記通信帯域通知
   装置との間または前記送信端末と前記受信端末との間に
   必要帯域を確保することを特徴とする通信システム。
4. 【請求項４】一定水準の通信品質を確保するために送信
   端末および受信端末の少なくとも一方が所定の制御メッ
   セージを送信して網内に帯域を確保する通信帯域確保方
   式を用いた通信網での通信帯域確保方法であって、 前記送信端末および受信端末以外のノード装置が、前記
   送信端末または受信端末に代わって所定の制御メッセー
   ジの送信を含む処理を実行して、前記通信網に必要帯域
   を確保させることを特徴とする通信帯域確保方法。
5. 【請求項５】一定水準の通信品質を確保するために送信
   端末および受信端末の少なくとも一方が所定の制御メッ
   セージを送信して網内に帯域を確保する通信帯域確保方
   式を用いた通信網での通信帯域確保方法であって、 前記送信端末および受信端末以外の第１のノード装置
   が、前記送信端末に代わって所定の制御メッセージの送
   信を含む処理を実行し、 前記送信端末および受信端末以外の第２のノード装置
   が、前記受信端末に代わって所定の制御メッセージの送
   信を含む処理を実行して、前記通信網に必要帯域を確保
   させることを特徴とする通信帯域確保方法。
6. 【請求項６】前記必要帯域通知手段の送出する前記制御
   メッセージを、前記送受信端末間の経路の一部に流すこ
   とにより、前記経路の一部にのみ帯域を確保することを
   特徴とする請求項４または５に記載の通信帯域確保方
   法。
7. 【請求項７】一定水準の通信品質を確保するために１対
   の送信端末および受信端末の少なくとも一方が所定の制
   御メッセージを送信して網内に帯域を確保する通信帯域
   確保方式を用いた通信網での通信帯域確保方法であっ
   て、 前記送信端末またはその代行を行う第１の通信帯域通知
   装置が所定の制御メッセージの送出を含む処理を実行
   し、 前記受信端末またはその代行を行う第２の通信帯域通知
   装置が所定の制御メッセージの送出を含む処理を実行し
   て、 前記第１の通信帯域通知装置と前記受信端末との間、前
   記送信端末と前記第２の通信帯域通知装置との間、また
   は前記第１および第２の通信帯域通知装置間に必要帯域
   を確保することを特徴とする通信帯域確保方法。
8. 【請求項８】前記送信端末の送出するパケットはインタ
   ーネットプロトコルパケットであることを特徴とする請
   求項４ないし６のいずれか１項に記載の通信帯域確保方
   法。
9. 【請求項９】前記制御メッセージはＲＳＶＰメッセージ
   であることを特徴とする請求項８に記載の通信帯域確保
   方法。
10. 【請求項１０】前記制御メッセージによりパケット流の
    属性を網に通知し、同一属性を通知されたパケット流全
    体に対する帯域を網に確保することを特徴とする請求項
    ４ないし９のいずれか１項に記載の通信帯域確保方法。