(57)【特許請求の範囲】
【請求項１】
資源予約プロトコルを処理するサーバまたはルータにおける簡易ポリシ制御装置であって，
サービスＩＤ，プロトコルＩＤ，送信元アドレス，送信元ポート番号，送信元アドレスネットマスク，送信先アドレス，送信先ポート番号または送信先アドレスネットマスクの少なくともいずれか複数の組み合わせによって通信のグループを定義するグループ定義情報と，そのグループに対する予約可能バンド幅値を定義する情報とを含むポリシデータを記憶するポリシデータ記憶手段と，
前記各グループに対する予約済バンド幅値を記憶する状態管理データ記憶手段と，
前記ポリシデータに従ってバンド幅を予約する通信のグループを決定するグループ判定手段と，
予約を要求した通信の予約要求バンド幅値と，前記グループ判定手段によって決定したグループに対する予約済バンド幅値と，そのグループに対する予約可能バンド幅値とに基づいて，予約受付の可否を判定する予約受付判定手段と，
前記予約受付判定手段により予約を受け付ける場合に，前記状態管理データ記憶手段が記憶する予約済バンド幅値を更新するデータ更新手段とを備える
ことを特徴とする簡易ポリシ制御装置。
【請求項２】
請求項１記載の簡易ポリシ制御装置において，
前記ポリシデータは，あらかじめ用意された，もしくは管理者が設定したグループ判定プログラム内，またはそのグループ判定プログラムが参照する管理者が設定したデータファイル内に記憶され，
前記グループ判定手段は，前記グループ判定プログラムによって通信のグループを決定する
ことを特徴とする簡易ポリシ制御装置。
【請求項３】
請求項１または請求項２記載の簡易ポリシ制御装置において，
前記予約受付判定手段は，あらかじめ用意された，もしくは管理者が設定した予約受付判定プログラム，またはその予約受付判定プログラムと管理者が設定したデータファイルの情報とによって，予約受付の可否を判定する
ことを特徴とする簡易ポリシ制御装置。
【請求項４】
請求項１，請求項２または請求項３記載の簡易ポリシ制御装置において，
前記状態管理データ記憶手段は，すでに予約を受け付けている同一グループに属するマルチキャスト通信の予約済バンド幅値を記憶する手段を有し，
前記予約受付判定手段は，マルチキャスト通信の場合に，予約メッセージ中の予約要求バンド幅値および前記マルチキャスト通信の予約済バンド幅値の中で最大のバンド幅値を予約要求バンド幅値として，受付の可否を判定する
ことを特徴とする簡易ポリシ制御装置。
【請求項５】
資源予約プロトコルを処理するサーバまたはルータにおける簡易ポリシ制御方法であって，
前記サーバまたはルータは，
サービスＩＤ，プロトコルＩＤ，送信元アドレス，送信元ポート番号，送信元アドレスネットマスク，送信先アドレス，送信先ポート番号または送信先アドレスネットマスクの少なくともいずれか複数の組み合わせによって通信のグループを定義するグループ定義情報と，そのグループに対する予約可能バンド幅値を定義する情報とを含むポリシデータを記憶するポリシデータ記憶手段と，
前記各グループに対する予約済バンド幅値を記憶する状態管理データ記憶手段とを用い，
前記ポリシデータ記憶手段に記憶されたポリシデータに従ってバンド幅を予約する通信のグループを決定する過程と，
予約を要求した通信の予約要求バンド幅値と，前記決定したグループに対する前記状態管理データ記憶手段に記憶された予約済バンド幅値と，そのグループに対する前記ポリシデータ記憶手段に記憶された予約可能バンド幅値とに基づいて，予約受付の可否を判定する過程と，
前記予約受付の判定結果により予約を受け付ける場合に，前記状態管理データ記憶手段が記憶する予約済バンド幅値を更新する過程とを有する
ことを特徴とする簡易ポリシ制御方法。
【請求項６】
資源予約プロトコルを処理するサーバまたはルータにおける簡易ポリシ制御用プログラムを記録した計算機読み取り可能な記録媒体であって，
前記サーバまたはルータが備える計算機を，
サービスＩＤ，プロトコルＩＤ，送信元アドレス，送信元ポート番号，送信元アドレスネットマスク，送信先アドレス，送信先ポート番号または送信先アドレスネットマスクの少なくともいずれか複数の組み合わせによって通信のグループを定義するグループ定義情報と，そのグループに対する予約可能バンド幅値を定義する情報とを含むポリシデータを記憶するポリシデータ記憶手段と，
前記各グループに対する予約済バンド幅値を記憶する状態管理データ記憶手段と，
前記ポリシデータに従ってバンド幅を予約する通信のグループを決定するグループ判定手段と，
予約を要求した通信の予約要求バンド幅値と，前記グループ判定手段によって決定したグループに対する予約済バンド幅値と，そのグループに対する予約可能バンド幅値とに基づいて，予約受付の可否を判定する予約受付判定手段と，
前記予約受付判定手段により予約を受け付ける場合に，前記状態管理データ記憶手段が記憶する予約済バンド幅値を更新するデータ更新手段
として機能させるためのプログラムを記録した
ことを特徴とする簡易ポリシ制御プログラム記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，資源予約プロトコル（ＲＳＶＰ：Resource Reservation Protocol)を処理するサーバまたはルータにおいて，送信元または送信先のアドレス，ポート等の情報によって通信をグループ化し，そのグループに対して予約可能な最大帯域幅（バンド幅）を決めておくことにより，グループごとに予約バンド幅の制限を簡易に行うことができるようにした簡易ポリシ制御装置，簡易ポリシ制御方法およびそのプログラム記録媒体に関する。
【０００２】
【従来の技術】
近年，ネットワーク資源の輻輳が深刻化する中で，通信品質を維持するのに必要なバンド幅を予約するために，資源予約プロトコル（ＲＳＶＰ）の標準化および実装が進められている。ＲＳＶＰは，アプリケーションが，ネットワークの通信品質を確保できるように，ネットワーク資源を予約するためのプロトコルである。
【０００３】
しかし，ネットワークが提供できるバンド幅には限りがあり，そのバンド幅を予約し確保することはコストがかかるため，すべての予約を認めるわけにはいかない。さらに，ネットワーク管理の立場からみると，ネットワークの状況に応じて有効な予約が行われるようにしなければならない。
【０００４】
例えば，企業内ネットワークでは，社長からの予約を確保する一方で，一般社員からの予約を制限したい場合があるかもしれない。また，ユーザが限定できない会議室などのホストからの予約を制限，拒否したい場合もある。このように，予約要求を受け付ける段階で，予約元または予約先によっては，なんらかの予約の制限を行うことが必要となる。
【０００５】
【発明が解決しようとする課題】
このような問題を解決するために，ＲＳＶＰでは，POLICY＿DATAオブジェクトを用意している。しかし，POLICY＿DATAオブジェクトの記述形式や使い方に関しては，まだ，ＩＥＴＦ（Internet Engineering Task Force ）において検討段階にあり，確定するには至っていない。
【０００６】
そこで，本発明は，ネットワーク管理者が，送信元／送信先のアドレスやポート番号，プロトコルの種類などによって，予約を要求している通信（フロー）をグループに分け，そのグループに対して予約可能なバンド幅値を設定して，その範囲での予約を受け付けることにより，通信予約を簡易に制御することができる手段を提供することを目的とする。
【０００７】
具体的には，
・特定のサイトもしくはホストからの，または特定のサイトもしくはホストへの過剰な予約の回避，
・不都合なサイトもしくはホストからの，または不都合なサイトもしくはホストへの予約の拒否または制限，
・重要なサイトもしくはホストからの，または重要なサイトもしくはホストへの予約の保護，
・指定サイトもしくはホストからの，または指定サイトもしくはホストへの予約の拒否，
を簡易に実現できるようにすることを目的とする。
【０００８】
【課題を解決するための手段】
本発明は，ネットワーク管理者等が設定したポリシデータに従って，通信（フロー）をグループ化し，グループに属する個々の通信の最大予約可能値を決めておくことにより，またはグループに属する通信の予約累計に対して最大予約可能値を決めておくことにより，予約制限を行うことを最も主要な特徴とする。通信（フロー）とは，送信者から一つ以上の受信者へのトラフィック・ストリームである。
【０００９】
ポリシデータとして，特定サイト（ホスト）の情報とそのグループに属する通信の予約累計に対して，最大予約可能値を設定しておくことにより，
▲１▼  特定サイト（ホスト）から，
▲２▼  特定サイト（ホスト）へ，
▲３▼  または，特定サイト（ホスト）から特定サイト（ホスト）へ，
の予約を制限することができる。
【００１０】
ポリシデータとして，特定サイト（ホスト）の情報とそのグループに属する通信の予約累計に対する最大予約可能値Ａ，それ以外の通信の予約累計に対する最大予約可能値Ｂを，最大予約可能値Ａと最大予約可能値Ｂの和が全資源量となるように設定しておくことにより，
▲１▼  特定サイト（ホスト）から，
▲２▼  特定サイト（ホスト）へ，
▲３▼  または，特定サイト（ホスト）から特定サイト（ホスト）へ，
の予約を保護することができる。
【００１１】
さらに上記ポリシデータに，どのグループにも属さない通信に対する最大予約可能値としてゼロを設定しておくことにより，ネットワーク管理者等が設定したポリシグループに属さない通信からの予約を拒否することができる。
【００１２】
また，予約受付の可否を判定する場合に，ユニキャスト通信のときには，予約メッセージ中の予約値を予約要求値として，またマルチキャストのときには，予約メッセージ中の予約値とすでに予約を受け付けている同一マルチキャストグループに属する通信の予約値の中で最大の予約値を予約要求値として，受付の可否を判定する。これにより，ユニキャスト通信およびマルチキャスト通信のいずれの場合にも適切なポリシ制御が可能になる。
【００１３】
通信をグループ化する場合に，以下のような手段を用いることができる。
▲１▼  あらかじめ用意されたグループ判定プログラム（関数）によって，通信をグループ化する。
【００１４】
▲２▼  管理者が一つまたは複数設定したグループ判定プログラム（関数）によって，通信をグループ化する。
▲３▼  あらかじめ用意されたグループ判定プログラム（関数）と，管理者が設定したポリシデータの一部または全部を含むデータファイルの情報とによって，通信をグループ化する。
【００１５】
▲４▼  管理者が一つまたは複数設定したグループ判定プログラム（関数）と，管理者が設定したポリシデータの一部または全部を含むデータファイルの情報とによって，通信をグループ化する。
【００１６】
また，予約受付の可否を判定する場合に，以下のような手段を用いることができる。
▲１▼  あらかじめ用意された予約可否判定プログラム（関数）によって，予約可否を判定する。
【００１７】
▲２▼  管理者が一つまたは複数設定した予約可否判定プログラム（関数）によって，予約可否を判定する。
▲３▼  あらかじめ用意された予約可否判定プログラム（関数）と，管理者が設定したポリシデータの一部または全部を含むデータファイルの情報とによって，予約可否を判定する。
【００１８】
▲４▼  管理者が一つまたは複数設定した予約可否判定プログラム（関数）と，管理者が設定したポリシデータの一部または全部を含むデータファイルの情報とによって，予約可否を判定する。
【００１９】
以上の各処理手段を計算機によって実現するためのプログラムは，計算機が読み取り可能な可搬媒体メモリ，半導体メモリ，ハードディスクなどの適当な記録媒体に格納することができる。
【００２０】
【発明の実施の形態】
図１は，本発明の構成例を示す図である。簡易ポリシ制御装置１０は，制御データ部１，グループ判定部２，予約受付判定部３，データ更新部４から構成される。
【００２１】
制御データ部１は，制御データとして，通信（フロー）をグループ化するためのグループＩＤごとに，グループを定義する情報と，グループに対する予約可能バンド幅値を定義する情報のポリシデータ１１と，ポリシグループの予約状態を管理する状態管理データ１２を記憶する手段である。
【００２２】
グループ判定部２は，制御データ部１に記憶されたポリシデータ１１をもとに通信（フロー）をグループ化する手段である。
予約受付判定部３は，グループ判定部２によりグループ化された通信について，ポリシデータ１１および状態管理データ１２をもとに，通信の予約受付の許否を判定する手段である。
【００２３】
データ更新部４は，予約受付判定部３の予約受付許否の判定結果にもとづき，制御データ部１に記憶された状態管理データ１２を更新する手段である。
通信の予約メッセージを受信すると，グループ判定部２は，制御データ部１のポリシデータ１１のグループ定義をもとに，その通信が属するグループを判定する。予約受付判定部３は，その通信の予約要求バンド幅について，その通信が属するグループの予約可能バンド幅と現在の予約済バンド幅とにもとづいて，予約を受け付けるかどうかを判定する。予約受付判定部３が予約受付を認めた場合には，データ更新部４は，必要があれば，制御データ部１の状態管理データ１２の予約済バンド幅値を更新する。
【００２４】
なお，予約変更時に予約受付判定部３で，予約の変更が却下された場合には，既存の（古い）予約バンド幅値で予約を続行する。
図１に示す簡易ポリシ制御装置１０は，例えば資源予約プロトコル（ＲＳＶＰ）を処理する部分の一部として，サーバまたはルータに実装される。
【００２５】
図２は，本発明の実装例を示す図である。図２において，ルータ２０は，ネットワークを相互に接続し，ルーチングを行う装置である。簡易ポリシ制御部２１は，図１に示す簡易ポリシ制御装置１０に相当するもの，資源予約プロトコル制御部２２は，ＲＳＶＰに従った処理を行う部分，トラフィック制御部２３は，実際のトラフィックに応じてバンド幅の割り当てを制御する部分である。簡易ポリシ制御部２１は，資源予約プロトコル制御部２２における通信の予約メッセージ処理の一部として組み込まれ，予約メッセージが新規の予約または予約を変更するものであるときに呼び出される。なお，ＲＳＶＰでは，実際の予約は通信の受信者が行う。
【００２６】
図３は，図２に示すルータ２０の本発明に関連する部分の処理概要を示すフローチャートである。
資源予約プロトコル制御部２２は，予約メッセージを受信し（ステップＳ１），それが新規メッセージであるか（ステップＳ２）または予約を変更するものであるときは（ステップＳ３），簡易ポリシ制御部２１を呼び出し，以下の処理を行う。
【００２７】
まず，グループ判定部２により，図１の制御データ部１に記憶されているグループ定義と比較する（ステップＳ４）。比較の結果，該当グループがあるときのみ（ステップＳ５），さらに予約受付判定部３により，予約受付判定を行う（ステップＳ６）。予約受付判定がＯＫの場合，または，グループ判定において該当グループがない場合には，トラフィック制御部２３によるトラフィックコントロールがされ（ステップＳ７），トラフィックコントロールが成功した場合には（ステップＳ８），データ更新部４により，該当グループがある場合にのみ（ステップＳ９），制御データ部１における状態管理データ１２の更新を行う（ステップＳ１０）。
【００２８】
一方，予約受付判定部３で，予約受付判定がＯＫでない場合，またはトラフィックコントロールが成功でない場合には，予約エラーメッセージを送信する（ステップＳ１１）。
【００２９】
以下，図１に示す簡易ポリシ制御装置１０をさらに詳しく説明する。
〔制御データ部〕
図１に示す制御データ部１には，グループＩＤ，ネットワーク管理者が設定するポリシデータ１１，ポリシグループの予約状態を管理する状態管理データ１２が制御データとして記憶される。
【００３０】
図４は，制御データ部１で記憶する制御データのデータ構成例を示す。
グループＩＤごとに，図４に示すようなポリシデータおよび状態管理データが制御データ部１に記憶される。グループＩＤは，ポリシグループの設定順に付番される。
【００３１】
ポリシデータのデータ項目として，サービスＩＤ（ServID），プロトコルＩＤ（ProtoID ），送信元アドレス（SrcAddr ），送信元ポート番号（SrcPort ），送信元アドレスネットマスク（SrcMask ），送信先アドレス（DstAddr ），送信先ポート番号（DstPort ），送信先アドレスネットマスク（DstMask ）等のグループ定義情報と予約可能バンド幅値（MaxBW ）がある。
【００３２】
このポリシデータは，管理者がネットワークの状況に応じて設定するが，ポリシデータのグループ定義は，必ずしも全項目を設定する必要はない。例えば，送信先の情報のみでグループ化したい場合には，送信先に関する項目だけを設定し，その他の項目は，「Don't Care」を設定し，比較の対象としないことが可能である。
【００３３】
また，状態管理データ１２は，予約済バンド幅（AccBW ）と各マルチキャストの予約バンド幅を格納するマルチキャスト管理リスト（MultiBW ）からなる。
状態管理データの初期値は，予約バンド幅（AccBW ）にはゼロ，マルチキャスト管理リスト（MultiBW ）にはNULLが設定される。
【００３４】
一つのポリシグループに属する通信は，ユニキャスト（１対１の通信）またはマルチキャスト（１対多の通信）とに分けられる。一つのポリシグループの中に，複数のマルチキャストグループが存在する場合には，マルチキャストグループごとにマルチキャスト管理リスト（MultiBW ）を持つ。ここでは説明を簡単にするため，一つのポリシグループに属するマルチキャストグループが一つの場合を例とする。
【００３５】
図５は，ユニキャスト通信とマルチキャスト通信の予約を説明する図である。ＲＳＶＰは，ユニキャスト通信に対する予約の場合には，図５（Ａ）に示すとおり，一つの予約メッセージに対して一つの予約を行う。したがって，予約受付判定処理やデータ更新処理を行う際にも，予約バンド幅をそのまま予約可能バント幅値と比較したり，予約済バンド幅として累積する。
【００３６】
一方，マルチキャスト通信に対する予約の場合には，同一マルチキャストグループに属する通信の予約をマージし，それらの予約可能バンド幅値の最大値で予約をする。例えば，図５（Ｂ）に示すような場合に，送信先Ａ，送信先Ｂが同じマルチキャストグループに属し，送信先Ａは１５Ｍbps ，送信先Ｂは３０Ｍbps の予約要求をすると，２つの予約メッセージの合流地点であるルータＢは，２つの予約をマージして予約値のうち大きい値３０Ｍbps で予約を行う。そのため，図１の予約受付判定部３，データ更新部４の処理においても，この予約値のマージを考慮する必要がある。そこで，状態管理データ１２に，マルチキャスト管理リスト（MultiBW ）を設け，各マルチキャスト通信の予約の情報を格納しておき，予約受付判定や制御データ更新の処理には，マルチキャスト管理リストに格納された予約値のうち最大値をマルチキャストグループの代表予約値として，予約可能バンド幅値と比較したり，予約済バンド幅に加算するようにする。
【００３７】
〔グループ判定部〕
図１のグループ判定部２では，ポリシデータ１１のグループ定義に設定されている項目に関して，予約メッセージからデータを取り出し比較する。グループ定義に設定されたすべての項目について一致した場合には，そのグループを該当グループとする。複数のグループが設定されている場合には，設定の順序にしたがって比較し，最初に一致したグループを該当グループとする。そのため，管理者は，グループ設定時にアドレス範囲などの矛盾のないように設定する必要がある。
【００３８】
図６および図７は，グループ判定部の構成例を示す。
グループ判定部２は，通信の予約（Resv）メッセージを入力として，グループ判定プログラム（関数）により，またはグループ判定プログラム（関数）と制御データのデータファイルとの組み合わせにより，その通信がどのグループに属するかを判定する。
【００３９】
図６（Ａ）は，グループ判定部２を，あらかじめ装置に用意されている固定したグループ判定プログラム（関数）によって構成した例を示している。図６（Ｂ）は，グループ判定部２を，管理者などが外部から設定したグループ判定プログラム（関数）によって構成した例を示している。図６（Ａ），（Ｂ）の例では，グループ定義や最大予約バンド幅などのポリシデータは，プログラムまたは関数の中に定数として組み込まれている。
【００４０】
また，図７（Ａ）は，グループ判定部２を，あらかじめ装置に用意されている固定したグループ判定プログラム（関数）と，グループ定義や予約可能バンド幅などのポリシデータが格納されたデータファイルとによって構成した例を示している。さらに，図７（Ｂ）は，グループ判定部２を，管理者などが外部から設定したグループ判定プログラム（関数）と，グループ定義や予約可能バンド幅などのポリシデータが格納されたデータファイルとによって構成した例を示している。
【００４１】
このときのグループ判定プログラム（関数）は，例えば，
『管理者が設定したグループ定義項目について，
ｉｆ（予約メッセージの情報＝＝データファイルの情報）
このグループに属する
ｅｌｓｅ
このグループに属さない』
というような内容になっている。このような関数がグループ判定関数として設定されているときのグループ判定処理の例を，図８に従って説明する。
【００４２】
図８は，グループ判定処理を説明するためのポリシデータと予約メッセージの例を示す。図８に示すポリシデータ１１が定義されていたとする。この場合に，「予約メッセージＭ１」を受け取ったときと，「予約メッセージＭ２」を受け取ったときのグループ判定処理は，それぞれ以下のようになる。
【００４３】
「予約メッセージＭ１」を受け取った場合には，まず，「予約メッセージＭ１」をポリシデータ１１のGroupID=1 のグループ定義と比較する。
サービスＩＤ（ServID）は，ポリシデータ１１が「Don't Care」であるため，予約メッセージＭ１中のサービスＩＤ（ServID）が何であっても一致となる。プロトコルＩＤ（ProtoID ）はどちらもＴＣＰであり，一致する。送信元アドレス（SrcAddr ）は，送信元アドレスネットマスク（SrcMask ）を考慮して，マスク中の１のビット部分だけが比較される。送信元アドレスネットマスク（SrcMask ）において，例えば２５５（１６進数ではＦＦ）の部分は，その送信元アドレス（SrcAddr ）の部分が比較対象となり，０（１６進数では００）の部分は，比較対象から外される。この例では，送信元アドレス（SrcAddr ）はどちらもｄ．ｅ．ｆ．ｇであり，一致する。送信元ポート番号（SrcPort ）はどちらも２３であり，一致する。送信先アドレス（DstAddr は，送信先アドレスネットマスク（DstMask ）を考慮して比較される。マスクの扱いは，送信元アドレスネットマスクの場合と同様である。この例では，ポリシデータ１１中のａ．ｂ．ｃ．０と予約メッセージＭ１中のａ．ｂ．ｃ．ｄとは，送信先アドレスネットマスク（DstMask ）が２５５．２５５．２５５．０であるため，一致する。送信先ポート番号（DstPort ）は，ポリシデータ１１が「Don't Care」であるため，予約メッセージＭ１中の送信先ポート番号（DstPort ）が何であっても一致となる。
【００４４】
以上により，グループ定義の項目についてすべて一致しているので，「予約メッセージＭ１」は，GroupID=1 のグループに該当すると判定される。
次に，「予約メッセージＭ２」を受け取った場合には，１番目に上記と同様にGroupID=1 のグループ定義との比較が行われる。その結果，プロトコルＩＤ（ProtoID ）が不一致であることがわかり，予約メッセージＭ２は，GroupID=1 のグループに属さないと判定される。
【００４５】
したがって，次に２番目のGroupID=2 のグループ定義との比較が行われる。サービスＩＤ（ServID），プロトコルＩＤ（ProtoID ），送信元アドレス（SrcAddr ），送信元アドレスネットマスク（SrcMask ），送信元ポート番号（SrcPort ），送信先ポート番号（DstPort ）は，「Don't Care」であり，送信先アドレス（DstAddr ）も送信先アドレスネットマスク（DstMask ）を考慮して比較すると一致するので, 「予約メッセージＭ２」は，GroupID=2 のグループに該当すると判定される。
【００４６】
〔予約受付判定部〕
図１の予約受付判定部３では，グループ判定部２が判定したグループに認められている予約可能バンド幅値の範囲で予約を受け付ける。
【００４７】
予約受付許否の判定方式としては，例えば以下のものがある。
１）グループに属する個々の通信に対する最大予約可能バンド幅値をもとに予約受付の許否を判定する。
【００４８】
２）グループに属する通信の予約累計に対する最大予約可能バンド幅値をもとに予約受付の許否を判定する。
３）特定サイト（ホスト）の情報とそのグループに属する通信の予約累計に対する最大予約可能バンド幅値をもとに，▲１▼特定サイト（ホスト）からの予約，▲２▼特定サイト（ホスト）への予約，▲３▼特定サイト（ホスト）から他の特定サイト（ホスト）への予約，に関する予約受付の許否を判定する。
【００４９】
４）特定サイト（ホスト）の情報とそのグループに属する通信の予約累計に対する最大予約可能バンド幅値と，それ以外の通信の予約累計に対する最大予約可能バンド幅値との和が全資源量となるように定義しておき，これをもとに，▲１▼特定サイト（ホスト）からの予約，▲２▼特定サイト（ホスト）への予約，▲３▼特定サイト（ホスト）から他の特定サイト（ホスト）への予約，に関する予約受付の許否を判定する。
【００５０】
５）どのグループにも属さない通信に対する最大予約可能バンド幅値をゼロに定義し，予約受付を拒否する。
６）通信がユニキャストの場合には，予約メッセージ中の予約値を予約要求値として，また通信がマルチキャストの場合には，予約メッセージ中の予約値と，既に予約を受け付けている同一マルチキャストグループに属する通信の予約値の中で最大の予約値を予約要求値として，予約受付の許否を判定する。
【００５１】
図９〜図１１は，予約受付判定の処理を説明する図である。
個々の通信に対して最大予約可能バンド幅値を設定している簡易ポリシ制御装置の場合には，予約メッセージ中の予約バンド幅値をResvBW，そのグループの最大予約可能バンド幅値をMaxBW とすると，図９に示すように，ResvBW≦MaxBW かどうかを判定し（ステップＳ２１），ResvBW≦MaxBW であれば受付可とし（ステップＳ２２），ResvBW＞MaxBW であれば受付不可とする（ステップＳ２３）。
【００５２】
グループに属する通信の予約累計値に対して最大予約可能バンド幅値を設定している簡易ポリシ制御装置の場合には，ユニキャスト通信では，図１０に示すように，予約メッセージが新規または予約値の変更であるかどうかを判断して（ステップＳ３１），予約メッセージが新規メッセージの場合には（予約済バンド幅値をAccBW とする），AccBW+ResvBW≦MaxBW であるかどうかを判定する（ステップＳ３２）。AccBW+ResvBW≦MaxBW であれば受付可とし（ステップＳ３３），AccBW+ResvBW＞MaxBW であれば受付不可とする（ステップＳ３４）。
【００５３】
一方，予約メッセージが予約値を変更するものである場合には，変更前の予約バンド幅値をOldResvBW として，AccBW-OldResvBW+ResvBW≦MaxBW かどうかを判定する（ステップＳ３５）。AccBW-OldResvBW+ResvBW≦MaxBW であれば，受付可と判定し（ステップＳ３６），AccBW-OldResvBW+ResvBW＞MaxBW であれば，受付不可と判定する（ステップＳ３７）。
【００５４】
マルチキャスト通信では，図１１に示すように，マルチキャストの予約値を管理するマルチキャスト管理リストMultiBW がNULLかどうかを調べ（ステップＳ４１），MultiBW がNULLのとき，すなわち予約受付済のマルチキャスト通信がない場合には，さらにAccBW+ResvBW≦MaxBW かどうかを判定する（ステップＳ４２）。AccBW+ResvBW≦MaxBW ならば受付可と判定し（ステップＳ４３），AccBW+ResvBW＞MaxBW ならば受付不可と判定する（ステップＳ４４）。
【００５５】
一方，MultiBW がNULLでないときには，すなわち予約受付済のマルチキャスト通信があるときには，MultiBW から最大値を取り出して，それをMaxMultiBWとして，ResvBW≦MaxMultiBWかどうかを判定する（ステップＳ４５）。ResvBW≦MaxMultiBWであれば受付可と判定する（ステップＳ４６）。ResvBW＞MaxMultiBWであれば，さらに，AccBW-MaxMultiBW+ResvBW ≦MaxBW かどうかを判定し（ステップＳ４７），AccBW-MaxMultiBW+ResvBW ≦MaxBW のときには受付可とし（ステップＳ４９），AccBW-MaxMultiBW+ResvBW ＞MaxBW のときには受付不可とする（ステップＳ４８）。
【００５６】
図１２および図１３は，予約受付判定部の構成例を示す。
予約受付判定部３は，通信の予約メッセージを入力として，予約受付判定プログラム（関数）により，または予約受付判定プログラム（関数）と制御データのデータファイルとの組み合わせにより，その通信の予約を受け付けるか否かを判定する。
【００５７】
図１２（Ａ）は，予約受付判定部３を，あらかじめ装置に用意されている固定した予約受付判定プログラム（関数）によって構成した例を示している。図１２（Ｂ）は，予約受付判定部３を，管理者などが外部から設定した予約受付判定プログラム（関数）によって構成した例を示している。図１２（Ａ），（Ｂ）の例では，予約受付判定プログラム（関数）が必要とするポリシデータ等は，プログラムまたは関数の中に定数として組み込まれている。
【００５８】
また，図１３（Ａ）は，予約受付判定部３を，あらかじめ装置に用意されている固定した予約受付判定プログラム（関数）と，プログラムまたは関数が参照するポリシデータが格納されたデータファイルとによって構成した例を示している。さらに，図１３（Ｂ）は，予約受付判定部３を，管理者などが外部から設定した予約受付判定プログラム（関数）と，プログラムまたは関数が参照するポリシデータが格納されたデータファイルとによって構成した例を示している。
【００５９】
〔データ更新部〕
図１のデータ更新部４では，通信がユニキャストかマルチキャストかによって，以下のようにしてデータの更新を行う。
【００６０】
ユニキャスト通信の場合には，次のように更新する。
１）予約メッセージが新規メッセージであるとき，AccBW ＝AccBW+ResvBW（予約メッセージ中の予約バンド幅値をResvBW）とする。
【００６１】
２）予約メッセージが予約値変更であるとき，AccBW ＝AccBW-OldResvBW+ResvBW（変更前の予約バンド幅値をOldResvBW ，予約メッセージ中の予約バンド幅値をResvBW）とする。
【００６２】
３）予約メッセージが通信終了（予約解除）であるとき，AccBW ＝AccBW-ResvBWとする。
一方，マルチキャスト通信の場合には，次のようにする。
【００６３】
１）予約メッセージが新規メッセージであるとき，
▲１▼  MultiBW がNULLのときには，AccBW ＝AccBW+ResvBWとし，MultiBW にResvBWを挿入する。
【００６４】
▲２▼  MultiBW がNULLでないときには，MultiBW から最大値MaxMultiBWを取り出し，MaxMultiBW＜ResvBWのときにはAccBW ＝AccBW-MaxMultiBW+ResvBW とし，MultiBW にResvBWを挿入する。MaxMultiBW≧ResvBWのときには，MultiBW にResvBWを挿入する。
【００６５】
２）予約メッセージが予約値変更であるとき，
▲１▼  MultiBW からOldResvBW を削除する。
▲２▼  MultiBW にResvBWを挿入する。
【００６６】
▲３▼  MultiBW から最大値MaxMultiBWを取り出す。
▲４▼  MaxMultiBW＜OldResvBW のとき，AccBW ＝AccBW-OldResvBW+MaxMultiBWとする。
【００６７】
３）予約メッセージが通信終了（予約解除）であるとき，
▲１▼  MultiBW からResvBWを削除する。
▲２▼  MultiBW から最大値MaxMultiBWを取り出す。
【００６８】
▲３▼  MaxMultiBW＜ResvBWのとき，AccBW ＝AccBW-ResvBW+MaxMultiBW とする。
【００６９】
【実施例】
以下に，本発明のいくつかの実施例を説明する。
〔第１の実施例〕
図１４および図１５は，第１の実施例を説明する図である。
【００７０】
図１４（Ａ）は，本発明が実装されたルータとネットワークを示す。本例では，図１４（Ｂ）のポリシデータｄ１に示すとおり，ルータの供給可能なバンド幅を１００とし，それぞれのグループに対し予約可能バンド幅値５０が設定してある。ルータの供給可能バンド幅と各グループに割り当てられた予約受付可能バンド幅との関係は，図１５（Ａ）に示すようになっている。
【００７１】
このポリシデータｄ１にしたがってグループ判定を行うと，サブネットワークa.b.c.0 からの予約，サブネットワークa.b.d.0 からの予約，サブネットワークa.b.e.0 とサブネットワークa.b.f.0 からの予約に分けることができる。
【００７２】
今，通信はすべてユニキャスト通信であって，図１５（Ｂ）に示すような予約が行われているとする。ここで，ホストa.b.f.1 が新たに予約バンド幅１５で予約をしようとした場合に，この通信は，次のように処理される。
【００７３】
１）グループ判定部２で，グループ３(GroupID=3) に分類される。
２）予約受付判定部３で，１０（AccBW ）＋１５（ResvBW）＜５０（MaxBW ）となり，受付可能と判定され，この通信の予約受付がなされる。
【００７４】
３）データ更新部４では，AccBW ＝１０＋１５＝２５となり，ポリシデータｄ１は，ポリシデータｄ１’のように更新される。
次に，ホストa.b.c.3 が，予約バンド幅値１５で予約しようとした場合を考える。この通信は，以下のような処理になる。
【００７５】
１）グループ判定部２で，グループ１(GroupID=1) に分類される。
２）予約受付判定部３で，４０（AccBW ）＋１５（ResvBW）＞５０（MaxBW ）となり，受付不可と判定される。したがって，この通信は予約受付されず，ポリシデータの更新もされない。
【００７６】
ホストa.b.c.3 からの予約バンド幅値１５の予約は，ルータの供給可能なバンド幅からみれば（全バンド幅＝１００，受付済バンド幅＝８０），受付可能であるが，ポリシデータに設定されたグループごとの予約可能バンド幅値によって制限される。
【００７７】
このように，本発明によって，通信をグループに分け，各グループごとに予約を制限することができる。
〔第２の実施例〕
図１６および図１７は，第２の実施例を説明する図である。
【００７８】
図１６（Ａ）は，本発明が実装されたルータとネットワークを示す。本例では，図１６（Ｂ）のポリシデータｄ２に示すとおり，ルータの供給可能なバンド幅を１００として，サービスクラスがＧＳ（Guaranteed service class）で，かつ送信先アドレスがサブネットワークa.b.c.0 にある通信に対する予約可能バンド幅値を３０と設定している。ルータの供給可能バンド幅と各グループに割り当てられた予約受付可能バンド幅との関係は，図１７（Ａ）に示すようになっている。
【００７９】
今，通信はすべてユニキャスト通信であって，図１７（Ｂ）に示すような予約が行われているとする。ここで，ホストa.b.c.4 が，ＧＳクラス，予約バンド幅値１０で新たに予約をしようとした場合に，この通信は，次のように処理される。
【００８０】
１）グループ判定部２で，グループ１(GroupID=1) に分類される。
２）予約受付判定部３で，２５（AccBW ）＋１０（ResvBW）＞３０（MaxBW ）となり，受付不可と判定される。
【００８１】
したがって，ホストa.b.c.4 からの予約は受け付けられず，ポリシデータｄ２の更新もされない。
次に，ホストa.b.c.1 が，予約バンド幅値を１０から２０に変更しようとした場合には，この予約変更の要求は，次のようになる。
【００８２】
１）グループ判定部２で，グループ１(GroupID=1) に分類される。
２）予約受付判定部３で，２５（AccBW ）−１０（OldResvBW ）＋２０（NewResvBW ）＞３０（MaxBW ）となり，受付不可と判定される。
【００８３】
したがって，ホストa.b.c.1 からの予約変更は受け付けられず，ポリシデータｄ３も更新されない。ホストa.b.c.1 からの予約は既存予約（予約バンド幅＝１０）で続行される。
【００８４】
このように，本発明により，特定のサイトからの予約を制限することができる。
〔第３の実施例〕
図１８および図１９は，第３の実施例を説明する図である。
【００８５】
図１８（Ａ）は，本発明が実装されたルータとネットワークを示す。e.f.g.1 およびe.f.g.2 は，ビデオサーバとする。本例では，図１８（Ｂ）のポリシデータｄ３に示すとおり，ルータの供給可能なバンド幅１００のうち，サービスクラスがＧＳ（Guaranteed service class）で，プロトコルがＵＤＰで，かつ送信元アドレスがサブネットワークe.f.g.0 にある通信に対する予約可能バンド幅値を５０，それ以外の通信に対する予約バンド幅値を５０と設定している。ルータの供給可能バンド幅と各グループに割り当てられた予約受付可能バンド幅との関係は，図１９（Ａ）に示すようになっている。
【００８６】
今，図１９（Ｂ）に示すような予約が行われているとする。ここで，ホストa.b.c.4 が，ＧＳクラス，プロトコルＵＤＰ，送信元アドレスx.y.z.2 のユニキャスト通信に対して，予約バンド幅値＝１０で予約しようとした場合に，この通信は，次のように処理される。
【００８７】
１）グループ判定部２で，グループ２(GroupID=2) に分類される。
２）予約受付判定部３で，５０（AccBW ）＋１０（ResvBW）＞５０（MaxBW ）となり，受付不可と判定される。
【００８８】
したがって，a.b.c.4 からの予約は受け付けられず，ポリシデータｄ３も更新されない。
次に，ホストa.b.c.2 が，ＧＳクラス，プロトコルＵＤＰ，送信元アドレスe.f.g.1 のマルチキャスト通信に対して，予約バンド幅値＝１５で予約しようとした場合を考える。この場合，この通信は次のように処理される。
【００８９】
１）グループ判定部２で，グループ１(GroupID=1) に分類される。
２）予約受付判定部３で，４０（AccBW ）−１０（MaxMultiBW）＋１５（ResvBW）≦５０（MaxBW ）となり，受付可と判定される。
３）データ更新部４で，MultiBW ＝｛１０｝から，１０を取り出してMaxMultiBWとし，１０（MaxMultiBW）＜１５（ResvBW）なので，AccBW ＝４０−１０＋１５＝４５として，予約バンド幅値１５をリストに挿入して，MultiBW ＝｛１５，１０｝とする。
【００９０】
したがって，ホストa.b.c.2 からの予約は受け付けられ，ポリシデータｄ３は，ポリシデータｄ３’のように更新される。
このように，本発明によって，ビデオサーバe.f.g.1 ，ビデオサーバe.f.g.2 以外への予約を制限することにより，ビデオサーバe.f.g.1 ，ビデオサーバe.f.g.2 への予約を保護することができる。
【００９１】
〔第４の実施例〕
図２０は，第４の実施例を説明する図である。
図２０（Ａ）は，本発明が実装されたルータとネットワークを示す。本例では，図２０（Ｂ）のポリシデータｄ４に示すとおり，ルータの供給可能なバンド幅を１００とし，データ送信先アドレスによって３つのグループが設定され，それぞれのグループに属する個々の通信に対して，予約可能バンド幅値が２０，３０，４０と設定してある。
【００９２】
今，通信はすべてユニキャスト通信であって，図２０（Ｃ）に示すような予約が行われているとする。
ここで，ホストa.b.f.1 が，予約バンド幅値＝３０で予約しようとした場合に，この通信は，次のように処理される。
【００９３】
１）グループ判定部２で，グループ３(GroupID=3) に分類される。
２）予約受付判定部３で，３０（ResvBW）＜４０（MaxBW ）となり，受付可能と判定される。
【００９４】
次に，ホストa.b.c.3 が，予約バンド幅値＝３０で予約しようとした場合に，この通信は，次のように処理される。
１）グループ判定部２で，グループ１(GroupID=1) に分類される。
【００９５】
２）予約受付判定部３で，３０（ResvBW）＞２０（MaxBW ）となり，受付不可と判定される。
したがって，ホストa.b.c.3 からの予約は受け付けられない。
【００９６】
このように，本発明によって，通信をグループに分け，各グループごとに個々の通信の予約を制限することができる。
〔第５の実施例〕
図２１および図２２は，第５の実施例を説明する図である。
【００９７】
図２１（Ａ）は，本発明が実装されたルータとネットワークを示す。本例では，図２１（Ｂ）のポリシデータｄ５に示すとおり，ルータの供給可能なバンド幅を１００とし，データ送信先アドレスによって３つのグループが設定され，それぞれのグループの通信に対して，予約可能バンド幅値が５０，５０，０と設定してある。このポリシデータｄ５に従って，グループ判定を行うと，サブネットワークa.b.c.0 からの予約，サブネットワークa.b.d.0 からの予約，それ以外のものからの予約に分けることができる。
【００９８】
今，通信はすべてユニキャスト通信であって，図２２に示すような予約が行われているとする。
ここで，ホストa.b.f.1 が予約バンド幅値＝１５で予約しようとした場合に，この通信は，次のように処理される。
【００９９】
１）グループ判定部２で，グループ３(GroupID=3) に分類される。
２）予約受付判定部３で，０（AccBW ）＋１５（ResvBW）＞０（MaxBW ）となり，受付不可と判定される。
【０１００】
次に，ホストa.b.d.1 が予約バンド幅値＝１５で予約しようとした場合に，この通信は，次のように処理される。
１）グループ判定部２で，グループ２(GroupID=2) に分類される。
【０１０１】
２）予約受付判定部３で，１５（AccBW ）＋１５（ResvBW）＜５０（MaxBW ）となり，受付可と判定される。
３）データ更新部４は，AccBW ＝１５＋１５＝３０として，ポリシデータｄ５を，ポリシデータｄ５’のように更新する。
【０１０２】
このように，本発明によって，ネットワーク管理者が指定ポリシグループ以外の通信の予約を拒否することができる。
【０１０３】
【発明の効果】
以上説明したように，本発明によれば，ネットワーク管理者が，通信を送信元または送信先のアドレスやポート番号，プロトコルの種類などによってグループ化し，そのグループに対して予約可能なバンド幅を予め設定し，その範囲での予約を付け付けることにより，例えば次のようなことが可能になる。
【０１０４】
１）特定のサイトまたはホストに対する過剰な予約の回避。
２）不都合なサイトまたはホストに対する予約の拒否または制限。
３）重要なサイトまたはホストに対する予約の保護。
【０１０５】
４）指定サイトまたはホスト以外に対する予約の拒否。
【図面の簡単な説明】
【図１】本発明の構成例を示す図である。
【図２】本発明の実装の例を示す図である。
【図３】図２に示す装置の処理概要を示すフローチャートである。
【図４】制御データのデータ構成例を示す図である。
【図５】ユニキャスト通信とマルチキャスト通信の予約を説明する図である。
【図６】グループ判定部の構成例を示す図である。
【図７】グループ判定部の構成例を示す図である。
【図８】グループ判定処理を説明するためのポリシデータと予約メッセージの例を示す図である。
【図９】予約受付判定の処理を説明する図である。
【図１０】予約受付判定の処理を説明する図である。
【図１１】予約受付判定の処理を説明する図である。
【図１２】予約受付判定部の構成例を示す図である。
【図１３】予約受付判定部の構成例を示す図である。
【図１４】第１の実施例を説明する図である。
【図１５】第１の実施例を説明する図である。
【図１６】第２の実施例を説明する図である。
【図１７】第２の実施例を説明する図である。
【図１８】第３の実施例を説明する図である。
【図１９】第３の実施例を説明する図である。
【図２０】第４の実施例を説明する図である。
【図２１】第５の実施例を説明する図である。
【図２２】第５の実施例を説明する図である。
【符号の説明】
１  制御データ部
２  グループ判定部
３  予約受付判定部
４  データ更新部
１０  簡易ポリシ制御装置
１１  ポリシデータ
１２  状態管理データ
【図１】
0003665489.tif 000002
【図２】
0003665489.tif 000003
【図３】
0003665489.tif 000004
【図４】
0003665489.tif 000005
【図５】
0003665489.tif 000006
【図６】
0003665489.tif 000007
【図７】
0003665489.tif 000008
【図８】
0003665489.tif 000009
【図９】
0003665489.tif 000010
【図１０】
0003665489.tif 000011
【図１１】
0003665489.tif 000012
【図１２】
0003665489.tif 000013
【図１３】
0003665489.tif 000014
【図１４】
0003665489.tif 000015
【図１５】
0003665489.tif 000016
【図１６】
0003665489.tif 000017
【図１７】
0003665489.tif 000018
【図１８】
0003665489.tif 000019
【図１９】
0003665489.tif 000020
【図２０】
0003665489.tif 000021
【図２１】
0003665489.tif 000022
【図２２】
0003665489.tif 000023