JP2003224598A - ポリシー定義設定方法およびポリシーサーバ - Google Patents

Abstract

(57)【要約】 【課題】 リソース予約リクエストの通知を受けた場合
の処理負荷を軽減してリソース予約時間を短縮し、リソ
ース予約リクエストに対し早急な対応ができるようなポ
リシー定義設定方法およびポリシーサーバを得ること。 【解決手段】 ポリシーサーバは、予め作成された複数
の中継装置を経由して通信装置を接続する通信パスを予
約通信パスとして予約しておき、予約通信パスに基づい
て、フィルタ条件を除くポリシー定義を作成し、作成し
たポリシー定義を中継装置に対して予め配信し、その後
通信装置からリソース予約リクエストを受付けた時に、
フィルタ条件定義を作成して中継装置に配信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＩＰネットワーク
におけるオンデマンドなリクエストに対応したＩＰフロ
ーの転送の通信品質を保証するためにＱｏＳ制御を行う
ポリシー定義設定方法およびポリシーサーバに関するも
のである。

【０００２】

【従来の技術】９０年代に入ってからのインターネット
の普及は目覚しいものがある。インターネットの基本
は、ネットワークが全てのパケットを公平に扱うＢｅｓ
ｔ Ｅｆｆｏｒｔ型、つまり、サービスの品質を保証し
ない通信サービスである。しかし、インターネットの普
及に伴い、インターネットを使用したビジネスが展開さ
れ高品質のサービスや音声、動画通信といったリアルタ
イムのアプリケーションが要求されている。それらの要
求に対応するために、ＱｏＳ（Quality of Services：
通信品質）制御の技術が考えられている。

【０００３】ＱｏＳ制御の技術としてＤｉｆｆｓｅｒｖ
−ＰＩＢ（differentiated ServiceQuality of Service
Policy Information Base）をベースとしたポリシー定
義がある。この技術は、例えば、M. Fine, K. McCloghr
ie, J. Seligson, K. Chan, S. Hahn, A. Smith, Franc
is Reichmeyer "Differentiated Services Qualityof S
ervice Policy Information Base", IEFT Internet Dra
ft, November 24,2000に開示されている。

【０００４】Ｄｉｆｆｓｅｒｖ−ＰＩＢのポリシー定義
には、フィルタ条件定義とアクション定義がある。フィ
ルタ条件定義には、ＩＰネットワーク上のルータが、通
過するＩＰフローを識別し、転送品質ごとのサービスク
ラスに分類するために必要な条件が定義される。アクシ
ョン定義には、ＩＰフローのヘッダ情報にこのＩＰフロ
ーの転送品質のクラスを示すためのサービスクラスを指
定するマーキング設定やルータで行うＱｏＳ制御コマン
ドが定義される。

【０００５】ポリシー定義は、ネットワーク管理者によ
ってポリシーサーバ上で作成され、ポリシーサーバから
ネットワークを介して管理対象となっているそれぞれの
ルータに配信される。ポリシー定義を配信されたルータ
は、ポリシー定義を解釈してＱｏＳ制御コマンドとして
装置に設定し、その設定にしたがったＱｏＳ制御を行
う。つまり、ネットワーク管理者が設定したポリシー定
義に従って、ＩＰフローをサービスクラスごとに分類
し、それぞれのサービスクラスに指定された通信品質で
ＩＰフローを転送するようにしている。

【０００６】ポリシーサーバは、端末からＩＰネットワ
ークを介してリソース予約リクエストを受信すると、ポ
リシーサーバ上のポリシー定義により予約されているリ
ソース量と管理対象となっているルータが持つリソース
量との比較を行い、受信したリソース予約リクエストに
対してリソース確保が可能か否かの検証を行う。この検
証結果、受信したリソース予約リクエストに対してポリ
シーサーバでリソース確保が可能な場合は、ポリシーサ
ーバで受信したリソース予約リクエストに対するポリシ
ー定義を作成し、ＩＰネットワークを介して必要なルー
タに配信しＱｏＳ制御を行うようにしている。

【０００７】

【発明が解決しようとする課題】しかしながら、Ｄｉｆ
ｆｓｅｒｖ−ＰＩＢの従来技術では、オンデマンドなリ
ソース予約リクエストをポリシーサーバが受信するたび
に、ポリシーサーバ上のポリシー定義によって予約され
ているリソース量と管理対象となっているルータが持つ
リソース量との比較を行い、受信したリソース予約リク
エストに対してリソース確保が可能か否かの検証を行っ
てから、リソース予約リクエストに対応したポリシー定
義を作成し、対象ルータにポリシー定義を配信するた
め、端末からのリソース予約リクエストに対して早急な
対応ができないという問題がある。

【０００８】この発明は上記に鑑みてなされたもので、
リソース予約リクエストを受信する前にネットワーク管
理者が予めポリシーサーバに予約通信パスを作成し、ポ
リシーサーバは、その予約通信パスに基づいて、リソー
ス予約検証およびフィルタ条件定義を除くポリシー定義
を作成し、フィルタ条件定義を除くポリシー定義を予め
対象のルータに配信することで、リソース予約リクエス
トの通知を受けた場合の処理負荷を軽減してリソース予
約時間を短縮し、リソース予約リクエストに対し早急な
対応ができるようなポリシー定義設定方法およびポリシ
ーサーバを得ることを目的としている。

【０００９】

【課題を解決するための手段】上記目的を達成するため
に、この発明にかかるポリシー定義設定方法は、ＱｏＳ
制御の指示を行うポリシー定義を作成し、作成したポリ
シー定義を中継装置に配信するポリシーサーバと、前記
ポリシーサーバから配信されたポリシー定義に基づいた
通信品質でＩＰフローを転送してＩＰフローの経路選択
を行う中継装置と、前記中継装置を介してＩＰフローの
送受信が可能な通信装置とを備えるネットワークに適用
され、前記通信装置からオンデマンドに入力されたリソ
ース予約リクエストで指定された通信品質の通信経路を
確保するべく通信経路上の中継装置にポリシー定義を設
定するポリシー定義設定方法において、前記ポリシーサ
ーバは、予め作成された複数の中継装置を経由して通信
装置を接続する通信パスを予約通信パスとして予約して
おき、前記予約通信パスに基づいて、フィルタ条件を除
くポリシー定義を作成し、該作成したポリシー定義を中
継装置に対して予め配信し、その後通信装置からリソー
ス予約リクエストを受付けた時に、フィルタ条件定義を
作成して前記中継装置に配信することを特徴とする。

【００１０】この発明によれば、ポリシーサーバは、予
め作成された複数の中継装置を経由して通信装置を接続
する通信パスを予約通信パスとして予約しておき、予約
通信パスに基づいて、フィルタ条件を除くポリシー定義
を作成し、作成したポリシー定義を中継装置に対して予
め配信し、その後通信装置からリソース予約リクエスト
を受付けた時に、フィルタ条件定義を作成して中継装置
に配信するようにしている。すなわち、予め作成された
複数の中継装置を経由して通信機器を接続する通信パス
を予約通信パスとして予約しておき、予約通信パスに基
づいて、リソース予約リクエストで指定されるＩＰフロ
ーを識別するための条件を用いることなくポリシー定義
を作成し、中継装置に対して配信を行い、リソース予約
リクエストを受付けた時に、フィルタ条件定義を作成し
て中継装置に配信するようにしている。

【００１１】つぎの発明にかかるポリシー定義設定方法
は、上記の発明において、通信装置間のＩＰフローを転
送する複数の中継装置を経由する論理的な通信経路であ
る通信パスを定義する場合、どちらか一方の通信装置を
基準として通信方向を決定し、上り通信と下り通信の通
信経路を一組として前記通信パスの管理を行い、該通信
パスに対応させたポリシー定義の作成および設定を行う
ことを特徴とする。

【００１２】この発明によれば、通信装置間のＩＰフロ
ーを転送する複数の中継装置を経由する論理的な通信経
路である通信パスを定義する場合、どちらか一方の通信
装置を基準として通信方向を決定し、上り通信と下り通
信の通信経路を一組として通信パスの管理を行い、通信
パスに対応させたポリシー定義の作成および設定を行う
ようにしている。

【００１３】つぎの発明にかかるポリシー定義設定方法
は、上記の発明において、前記中継装置は、前記フィル
タ条件を除くポリシー定義を設定した場合、その後前記
ポリシー定義に対応したフィルタ条件が設定されるまで
は、前記ポリシー定義にしたがったＱｏＳ制御を無効に
することを特徴とする。

【００１４】この発明によれば、中継装置は、フィルタ
条件を除くポリシー定義を設定した場合、その後ポリシ
ー定義に対応したフィルタ条件が設定されるまでは、ポ
リシー定義にしたがったＱｏＳ制御を無効にするように
している。

【００１５】つぎの発明にかかるポリシー定義設定方法
は、上記の発明において、前記リソース予約リクエスト
を受信し、前記予約通信パスを割当てる場合、優先度と
利用率の情報に基づき通信パスを決定することを特徴と
する。

【００１６】この発明によれば、リソース予約リクエス
トを受信し、予約通信パスを割当てる場合、優先度と利
用率の情報に基づき通信パスを決定するようにしてい
る。

【００１７】つぎの発明にかかるポリシーサーバは、予
め作成された複数の中継装置を経由して通信装置を接続
する通信パスを予約通信パスとして予約しておき、前記
予約通信パスに基づいて、フィルタ条件を除くポリシー
定義を作成し、該作成したポリシー定義を中継装置に対
して予め配信し、その後通信装置からリソース予約リク
エストを受付けた時に、フィルタ条件定義を作成して前
記中継装置に配信する手段を備えることを特徴とする。

【００１８】この発明によれば、予め作成された複数の
中継装置を経由して通信装置を接続する通信パスを予約
通信パスとして予約しておき、予約通信パスに基づい
て、フィルタ条件を除くポリシー定義を作成し、作成し
たポリシー定義を中継装置に対して予め配信し、その後
通信装置からリソース予約リクエストを受付けた時に、
フィルタ条件定義を作成して中継装置に配信するように
している。

【００１９】つぎの発明にかかるポリシーサーバは、上
記の発明において、通信装置間のＩＰフローを転送する
複数の中継装置を経由する論理的な通信経路である通信
パスを定義する場合、どちらか一方の通信装置を基準と
して通信方向を決定し、上り通信と下り通信の通信経路
を一組として前記通信パスの管理を行い、該通信パスに
対応させたポリシー定義の作成および設定を行うことを
特徴とする。

【００２０】この発明によれば、通信装置間のＩＰフロ
ーを転送する複数の中継装置を経由する論理的な通信経
路である通信パスを定義する場合、どちらか一方の通信
装置を基準として通信方向を決定し、上り通信と下り通
信の通信経路を一組として通信パスの管理を行い、通信
パスに対応させたポリシー定義の作成および設定を行う
ようにしている。

【００２１】つぎの発明にかかるポリシーサーバは、上
記の発明において、前記リソース予約リクエストを受信
し、前記予約通信パスを割当てる場合、優先度と利用率
の情報に基づき通信パスを決定することを特徴とする。

【００２２】この発明によれば、リソース予約リクエス
トを受信し、予約通信パスを割当てる場合、優先度と利
用率の情報に基づき通信パスを決定するようにしてい
る。

【００２３】

【発明の実施の形態】以下に添付図面を参照して、この
発明にかかるポリシー定義設定方法およびポリシーサー
バの実施の形態を詳細に説明する。

【００２４】実施の形態１．図１〜図２７を用いてこの
発明の実施の形態１を説明する。この実施の形態１のポ
リシーサーバは、ネットワーク管理者によって入力され
た通信パス条件定義とサービスクラス定義とアクション
定義と予約通信パス定義と経路定義に基づいて、通信パ
ス条件定義テーブルとサービスクラス定義テーブルとア
クション定義テーブルと予約通信パス定義テーブルと経
路定義テーブルと通信チャンネル定義テーブルと、フィ
ルタ条件定義を除くポリシー定義テーブルを作成し、各
端末にサービスクラス定義を配信し、ルータにはフィル
タ条件定義を除くポリシー定義の配信を行う。フィルタ
条件定義を除くポリシー定義を受信したルータは、受信
したポリシー定義の設定を行う。また、ポリシーサーバ
は、ＩＰネットワーク上に接続されている端末から希望
する通信品質（帯域幅、ジッタ、最大バースト等）での
通信回線を確保するためのリソース予約リクエストを受
信すると、ポリシーサーバは受信したリソース予約リク
エストで指定された条件に基づいて、予め設定済みの通
信パスの中の通信チャンネルを割当て、リソース予約リ
クエストで指定されたＩＰフローを識別するためのフィ
ルタ条件定義を作成し、割当てた通信パスのルータにだ
けフィルタ条件定義の配信を行う。フィルタ条件定義を
受信したルータは、フィルタ条件を設定し、既に設定済
みの条件を有効にして、フィルタ条件で識別されたＩＰ
フローに対応するＱｏＳ制御を開始するものである。

【００２５】図１は、実施の形態１のネットワーク構成
を示すブロック図である。実施の形態１におけるネット
ワークは、ルータに対するＱｏＳ制御を行うための制御
コマンドであるポリシー定義の管理と配信を行うポリシ
ーサーバ１０と、ネットワークを介してＩＰフローのや
り取りによる通信を行う３台の端末（請求の範囲でいう
ところの通信装置）２０ａ〜２０ｃと、ＩＰフローを転
送するための中継装置である７台のルータ３０ａ〜３０
ｇで構成されている。

【００２６】図２は、図１に示したポリシーサーバ１０
の構成を示すブロック図である。ポリシーサーバ１０
は、入力部１１と、表示部１２と、インターフェース部
１３と、制御部１４と、記憶部１５で構成されている。

【００２７】入力部１１は、キーボードやマウスなど一
般的な入力機器で構成され、ポリシー定義を作成するた
めに必要な定義をネットワーク管理者がポリシーサーバ
に設定するための入力手段として使用される。

【００２８】表示部１２は、ＣＲＴ（Cathode-Ray Tub
e）、液晶ディスプレーなどで構成され、ネットワーク
管理者が設定したデータなどの表示手段として使用され
る。

【００２９】インターフェース部１３は、ネットワーク
を介して端末２０ａ〜２０ｃやルータ３０ａ〜３０ｇと
通信するための制御を行う。

【００３０】制御部１４は、各種定義テーブルの作成処
理とポリシーサーバの各構成要素の制御を統括的に行
う。

【００３１】記憶部１５は、ＨＤＤ（Hard Disk Driv
e）などで構成され、ポリシー定義の作成に必要な、通
信パス条件定義テーブル１５ａと、サービスクラス定義
テーブル１５ｂと、アクション定義テーブル１５ｃと、
予約通信パス定義テーブル１５ｄと、経路定義テーブル
１５ｅと、通信チャンネル定義テーブル１５ｆと、ポリ
シー定義テーブル１５ｇと、フィルタ条件定義テーブル
１５ｈを記憶する。

【００３２】通信パス条件定義テーブル１５ａには、端
末２０ａ〜２０ｃからポリシーサーバ１０に通知された
リソース予約リクエストに対して、どの予約通信パスを
割当てるかを決定するための条件が登録される。図５
は、通信パス条件定義テーブル１５ａに対する登録項目
を示すものであり、ここでは登録項目として、送信元Ｉ
Ｐアドレス、送信元アドレスマスク、宛先ＩＰアドレ
ス、宛先アドレスマスク、ポート番号、上りサービスク
ラス、下りサービスクラスと通信パス条件定義テーブル
１５ａ内の各通信パス条件定義を識別するための条件Ｉ
Ｄを挙げている。なお、通信パス条件定義テーブル１５
ａの登録項目としては、これらの項目に限るものではな
く、ＩＰフローを識別するための条件であれば他の項目
でもかまわない。

【００３３】サービスクラス定義テーブル１５ｂには、
図６に示すように、ＩＰフローを転送する際に提供する
通信品質を示すサービスクラス名と、そのサービス内容
が登録される。サービス内容としては、通信品質条件で
ある保証帯域と通信パス全体の伝送遅延時間が挙げられ
る。

【００３４】アクション定義テーブル１５ｃには、図７
に示すように、アクション定義テーブル１５ｃ内で各ア
クション定義を識別するためのアクションＩＤと、サー
ビスクラス定義テーブル１５ｂに登録されたサービスク
ラスの通信品質を実現するべくルータ３０ａ〜３０ｇで
行うＱｏＳ制御のためのＱｏＳ制御パラメータである詳
細定義と、詳細定義に対応するサービスクラス定義テー
ブル１５ｂに登録されているサービスクラス名が登録さ
れる。ここでは、詳細定義として、保証レートと遅延許
容時間を挙げているが、これら２つの項目に限るもので
はなく、ＱｏＳ制御を行うための条件であれば他の項目
でもかまわない。

【００３５】予約通信パス定義テーブル１５ｄには、図
８に示すように、通信パスＩＤと、条件ＩＤと、上り経
路ＩＤと、下り経路ＩＤと、予約通信チャンネル数と、
使用チャンネル数と、利用率と、優先度と、配信フラグ
とが登録される。通信パスＩＤの項目には、予約通信パ
ス定義テーブル１５ｄ内の各予約通信パス定義を識別す
るための通信パスＩＤが登録される。条件ＩＤの項目に
は、通信パス条件定義テーブル１５ａに登録されている
条件ＩＤが登録される。上り経路ＩＤと下り経路ＩＤの
項目には、経路定義テーブル１５ｅに登録されている経
路ＩＤが登録される。予約通信チャンネル数の項目に
は、上り通信チャンネルと下り通信チャンネルを１組に
したチャンネル数が登録される。使用チャンネル数の項
目には、実際にリソース予約リクエストにより使用され
ているチャンネル数が登録される。利用率の項目には、
使用チャンネル数を予約通信チャンネル数で割った値、
つまり、予約通信チャンネルに対しての利用率が登録さ
れる。利用率は、同じサービスクラスのリソース予約リ
クエストが大量にあった場合に複数の通信パスに負荷を
分散させて、特定の通信パスへの負荷の集中を防ぐため
に使用される。優先度の項目には、同じ通信パス条件の
通信パスが複数存在する場合に、どの通信パスを優先的
に使用するかが登録される。配信フラグの項目には、予
約通信パス定義テーブル１５ｄに対応したフィルタ条件
を除くポリシー定義が通信パスの経路上のルータに設定
済みかどうかの情報が登録される。

【００３６】経路定義テーブル１５ｅには、図９に示す
ように、経路定義テーブル１５ｅ内の各経路定義を識別
するための経路ＩＤと、予約通信パス定義テーブル１５
ｄに登録されている通信パスＩＤに対応させて中継装置
であるルータ３０ａ〜３０ｇをどのような順番で接続す
るかを示す経路情報と、経路情報に対応する予約通信パ
ス定義テーブル１５ｄに登録されている通信パスＩＤ
と、通信方向が登録される。

【００３７】通信チャンネル定義テーブル１５ｆには、
図１１に示すように、通信チャンネル定義テーブル１５
ｆ内の各通信チャンネル定義を識別するためのチャンネ
ルＩＤと、予約通信パス定義テーブル１５ｄに登録され
ている通信パスＩＤと、経路定義テーブル１５ｅに登録
されている経路ＩＤと、リソース予約リクエストごとに
割付けられるリクエストＩＤが登録される。

【００３８】ポリシー定義テーブル１５ｇには、図１２
に示すように、ポリシー定義テーブル１５ｇ内で各ポリ
シー定義を識別するためのポリシー定義ＩＤと、通信チ
ャンネル定義テーブル１５ｆに登録されているチャンネ
ルＩＤと、ルータ３０ａ〜３０ｇを指定するノード名
と、フィルタ条件定義テーブル１５ｈに登録されている
ＩＰフローを識別するためのフィルタＩＤと、アクショ
ン定義テーブル１５ｃに登録されているフィルタ定義に
該当したフローに対するＱｏＳ制御の制御パラメータで
あるアクションＩＤと、フィルタ条件に該当したＩＰフ
ロー転送先ルータを指定するＮｅｘｔＨｏｐ（ネクスト
ホップ）情報が登録される。

【００３９】フィルタ条件定義テーブル１５ｈには、図
２１に示すように、フィルタ条件定義テーブル１５ｈ内
で各フィルタ条件を識別するためのフィルタＩＤと、フ
ィルタ条件定義の詳細を定義する詳細定義と、リソース
予約リクエストを識別するためのリクエストＩＤが登録
される。このリクエストＩＤは、リソース解除リクエス
トが通知された場合に対応するフィルタ条件定義を特定
するために使用される。

【００４０】図１に示したルータ３０ａ〜３０ｇは全て
同じ機能を備えている。ここでは、図３に示したルータ
３０ａの構成を示すブロック図を参照してルータの機能
を説明する。ルータ３０ａは、ＩＰフロー識別部３１
と、フィルタ条件情報テーブル３２と、ＱｏＳ制御部３
３と、ＱｏＳ制御情報テーブル３４を備えている。

【００４１】ＩＰフロー識別部３１は、フィルタ条件情
報テーブル３２に登録されている条件にしたがって、Ｉ
Ｐフローを識別する。フィルタ条件情報テーブル３２に
は、図１３に示すように、ポリシーサーバ１０から配信
されたポリシー定義とフィルタ条件から、ポリシー定義
ＩＤに対応したフィルタ条件情報が登録される。ＱｏＳ
制御部３３は、ＱｏＳ制御情報テーブル３４に登録され
ている条件に基づきＱｏＳ制御を行う。ＱｏＳ制御情報
テーブル３４には、図１４に示すように、ポリシーサー
バ１０から配信されたポリシー定義からポリシー定義Ｉ
Ｄに対応したアクション定義情報とＮｅｘｔＨｏｐ情報
が登録される。

【００４２】つぎに、図５〜図２４を参照して、実施の
形態１のポリシー定義設定方法およびポリシーサーバ１
０の動作について、端末２０ａが端末２０ｂと通信を行
うためにポリシーサーバ１０にリソース予約リクエスト
およびリソース解放リクエストの通知した場合を例に挙
げて説明する。

【００４３】ポリシーサーバ１０の動作は、端末２０ａ
からリソース要求リクエストを受信する前にルータ３０
ａ〜３０ｄにフィルタ条件を除くポリシー定義を予め配
信しておく動作と、端末２０ａからリソース要求リクエ
ストを受信してフィルタ条件を作成し、ルータ３０ａ〜
３０ｄに配信する動作と、端末２０ａからリソース解放
リクエストを受信して通信パスを解放する動作とに分け
られる。

【００４４】まず、図５〜図９と図４のフローチャート
を参照して、ネットワーク管理者がポリシーサーバ１０
に通信パス条件定義とサービスクラス定義とアクション
定義と予約通信パス定義と経路定義の設定を行い、その
情報に基づいてポリシーサーバ１０がテーブルを作成す
る動作を説明する。

【００４５】ネットワーク管理者は、端末２０ａ〜２０
ｃから通知されたリソース予約リクエストに対して、ど
の予約通信パスを割当てるかを決定するための条件であ
る通信パス条件定義を作成し、作成した通信パス条件定
義（図５参照）を入力部１１を用いてポリシーサーバ１
０に入力する（図４ステップＳ１００）。制御部１４
は、入力部１１から入力された通信パス条件定義に対し
て通信パス条件定義テーブル１５ａ内で通信パス条件定
義を識別するための条件ＩＤを割付ける（図４ステップ
Ｓ１０１）。条件ＩＤを割付けられた通信パス条件定義
は通信パス条件定義テーブル１５ａに記憶される（図４
ステップＳ１０２）。

【００４６】図５に示される通信パス条件定義テーブル
１５ａの場合は、ネットワーク管理者によって送信元Ｉ
Ｐアドレス「０．０．１．０」、送信元アドレスマスク
「２５５．２５５．２５５．０」、宛先ＩＰアドレス
「０．０．４．０」、宛先アドレスマスク「２５５．２
５５．２５５．０」、ポート番号「指定なし」、上りサ
ービスクラス「クラスＡ」、下りサービスクラス「クラ
スＡ」という通信パス条件が入力されている。つまり、
送信元ＩＰアドレス「０．０．１．０」、送信元アドレ
スマスク「２５５．２５５．２５５．０」から宛先ＩＰ
アドレス「０．０．４．０」、宛先アドレスマスク「２
５５．２５５．２５５．０」へＩＰフローを転送する場
合の上り通信に対して提供する通信品質である上りサー
ビスクラスは「クラスＡ」で行い、下り通信に対する下
りサービスクラスは「クラスＡ」で行い、ポート番号は
「指定なし」という通信パス条件定義がポリシーサーバ
１０に入力され、制御部１４は、入力された通信パス条
件定義に対して、条件ＩＤ「Ｃ−００００１」を割付け
ている。

【００４７】つぎに、ネットワーク管理者は、ＩＰフロ
ーを転送する際に提供する通信品質を示すサービスクラ
ス名と、そのサービス内容を示すサービスクラス定義
（サービスクラス名、保証帯域、伝送遅延時間、図６参
照）を作成し、作成したサービスクラス定義を入力部１
１を用いてポリシーサーバ１０に入力する（図４ステッ
プＳ１０３）。入力部１１から入力されたサービスクラ
ス定義はサービスクラス定義テーブル１５ｂに記憶され
る（図４ステップＳ１０４）。インターフェース部１３
は、サービスクラス定義テーブル１５ｂに記憶されてい
るサービスクラス定義を端末２０ａ〜２０ｃに配信する
（図４ステップＳ１０５）。

【００４８】図６に示されるサービスクラス定義テーブ
ル１５ｂの場合は、ネットワーク管理者が３種のサービ
スクラス「クラスＡ〜Ｃ」を定義している。「クラス
Ａ」は、保証帯域１００Ｋｂｐｓで伝送遅延時間１５０
ｍｓ以下の通信品質で通信を行うことを保証する。「ク
ラスＢ」は、保証帯域１００Ｋｂｐｓで伝送遅延時間の
保証なしという通信品質で通信を行うことを保証する。
「クラスＣ」は、保証帯域１０００Ｋｂｐｓで伝送遅延
時間の保証なしという通信品質で通信を行うことを保証
する。このように、ネットワーク管理者は、保証帯域と
伝送遅延時間の組み合わせで複数のサービスクラスを定
義し、サービスクラス定義テーブル１５ｂに登録するこ
とができる。このサービスクラス定義は、端末２０ａ〜
２０ｃに配信され、端末２０ａ〜２０ｃがリソース予約
リクエストを行う際にサービスクラスの指定に参照され
る。

【００４９】つぎに、ネットワーク管理者は、ルータ３
０ａ〜３０ｇで行うＱｏＳ制御のための制御パラメータ
となる詳細定義とそのサービスクラス名を示すアクショ
ン定義を作成し、入力部１１を用いて作成したアクショ
ン定義（図７参照）をポリシーサーバ１０に入力する
（図４ステップＳ１０６）。制御部１４は、入力部１１
から入力されたアクション定義に対してアクション定義
テーブル１５ｃ内でアクション定義を識別するためのア
クションＩＤを割付ける（図４ステップＳ１０７）。ア
クションＩＤを割付けられたアクション定義はアクショ
ン定義テーブル１５ｃに記憶される（図４ステップＳ１
０８）。

【００５０】図７に示されるアクション定義テーブル１
５ｃの場合は、ネットワーク管理者によって、詳細定義
が「保証レート：＝１００ｋｂｐｓ、許容遅延：＜３０
ｍｓ」でサービスクラス名「クラスＡ」、詳細定義が
「保証レート：＝１００ｋｂｐｓ、許容遅延：指定無
し」でサービスクラス名「クラスＢ」、詳細定義が、
「保証レート：＝１０００ｋｂｐｓ、許容遅延：指定無
し」でサービスクラス名「クラスＣ」というアクション
定義がポリシーサーバ１０に入力され、制御部１４が、
それぞれのアクション定義に対してアクションＩＤ「Ａ
−００００１〜Ａ−００００３」を割付けている。つま
り、アクションＩＤ「Ａ−００００１」が示すアクショ
ン定義は、保証レート１００ｋｂｐｓで許容遅延が３０
ｍｓ以下という詳細定義と、サービスクラス名はクラス
Ａである。

【００５１】つぎに、ネットワーク管理者は、予約通信
パス定義（図８参照）を作成して入力部１１を用いてポ
リシーサーバ１０に入力する（図４ステップＳ１０
９）。ネットワーク管理者が作成する予約通信パス定義
の項目は、通信パス条件定義テーブル１５ａに記憶され
ている条件ＩＤと、上り経路ＩＤおよび下り経路ＩＤ
と、上り通信チャンネルと下り通信チャンネルを１組と
した予約通信チャンネル数と、同じ通信パス条件の通信
パスが複数存在する場合の優先順位を指定する優先度が
ある。上り経路ＩＤと下り経路ＩＤについては、通信パ
ス条件定義テーブル１５ａの条件ＩＤと予約通信パス定
義で指定される予約通信チャンネル数をもとに定義する
通信パスで必要なリソース予約が可能な経路を作成する
経路定義テーブル１５ｅが作成された時にポリシーサー
バ１０が割付ける上り経路ＩＤおよび下り経路ＩＤを登
録する必要があるため、最初は任意のＩＤを入力してお
き、経路定義テーブル１５ｅが作成された時にポリシー
サーバ１０が割付けた上り経路ＩＤおよび下り経路ＩＤ
を再度設定する。制御部１４は、入力部１１から入力さ
れた予約通信パス定義に対して予約通信パス定義テーブ
ル１５ｄ内で予約通信パス定義を識別するための通信パ
スＩＤを割付ける（図４ステップＳ１１０）。通信パス
ＩＤを割付けられた予約通信パス定義は、使用チャンネ
ル数と利用率と配信フラグが初期値に設定され予約通信
パス定義テーブル１５ｄに記憶される（図４ステップＳ
１１１）。

【００５２】図８は、上り経路ＩＤおよび下り経路ＩＤ
が割付けられた後の予約通信パス定義テーブル１５ｄの
内容を示している。ネットワーク管理者によって、条件
ＩＤ「Ｃ−００００１」、上り経路ＩＤ「Ｒ−００００
１」、下り経路ＩＤ「Ｒ−００００２」、予約通信チャ
ンネル数「２」、優先度「１」という予約通信パス定義
がポリシーサーバ１０に入力され、制御部１４は、通信
パスＩＤ「Ｐ−００００１」を割付けている。リソース
予約前であるので、チャンネルは使用されていないこと
から、使用チャンネル数「０」、利用率「０％」に設定
している。また、通信経路が決定していないのでこの通
信パスの経路にあるルータに対してポリシー定義の配信
を行っていないため、配信フラグも「未配信」に設定し
ている。通信パスＩＤ「Ｐ−００００１」で示される予
約通信パス定義は、通信パス条件定義テーブル１５ａの
条件パスＩＤ「Ｃ−００００１」に示される通信パスに
対応する予約通信パス定義となる。

【００５３】つぎに、ネットワーク管理者は、通信パス
条件定義、アクション定義、予約通信パス定義に基づ
き、通信パス条件定義で指定された通信パス条件である
発信元ＩＰアドレスおよび宛先ＩＰアドレスと、アクシ
ョン定義で指定したサービスクラスに対応する詳細定義
と、予約通信パス定義で指定した通信チャンネル数を満
たすリソース予約が可能な経路を作成する。

【００５４】図８で示した予約通信パス定義テーブル１
５ｄの通信パスＩＤ「Ｐ−００００１」の場合は、予約
通信チャンネル数が２チャンネルで、条件ＩＤに「Ｃ−
００００１」が指定されていることから、通信パス条件
定義テーブル１５ａ（図５）より、上りサービスクラス
は「クラスＡ」であることがわかる。アクション定義テ
ーブル１５ｃ（図７）で指定されているクラスＡのアク
ションＩＤは「Ａ−００００１」で、その詳細定義は、
保証レートが１００ｋｂｐｓで許容遅延が３０ｍｓ以下
である。つまり、通信パスＩＤ「Ｐ−００００１」の上
り経路は、リソースとして帯域が２００ｋｂｐｓ（保証
レート１００ｋｂｐｓ×２チャンネル）で、ルータの遅
延が３０ｍｓ未満になる経路をネットワーク管理者が作
成する。下り経路についても、上り経路と同様にリソー
スとして帯域が２００ｋｂｐｓ（保証レート１００ｋｂ
ｐｓ×２チャンネル）で、ルータの遅延が３０ｍｓ未満
になる経路をネットワーク管理者が作成する。

【００５５】ネットワーク管理者は経路を作成する際
に、中継するルータ毎に既存の予約通信パスによる予約
帯域量と、新規に追加する予約通信パスによる予約帯域
量が、ルータの持つ帯域性能以内であることを確認する
リソース予約検証を行う。

【００５６】例えば、通信パスＩＤ「Ｐ−００００１」
に対する経路を作成する場合には、対象となるルータの
帯域性能が１０００Ｍｂｐｓで、既存の予約通信パスに
よる予約帯域が１００Ｍｂｐｓであり、ルータの遅延性
能が２０ｍｓであったとする。この場合、新規に追加す
る通信パスＩＤ「Ｐ−００００１」の上り経路の予約帯
域は２００ｋｂｐｓなので、ルータの帯域性能内にあり
帯域に関しては予約可能であり、遅延についてもルータ
の遅延性能が通信パスＩＤ「Ｐ−００００１」の要求す
る３０ｍｓ未満の条件を満たしているので、新規通信パ
スの上り経路分のリソース予約が可能であると判断され
る。このように、指定する全てのルータに対して、リソ
ース予約検証を行い、ルータを決定して経路を作成して
いく。下り経路のリソース予約検証は、上り経路による
リソース予約量も既存のリソース予約量に含めた形で行
う。

【００５７】つぎに、ネットワーク管理者は、このよう
にしてリソース予約検証を行って決定した経路を経路情
報とし、経路情報と通信パスＩＤと通信方向を指定した
経路定義（図９）を入力部１１を用いて入力する（図４
ステップＳ１１２）。制御部１４は、入力部１１から入
力された経路定義に対して経路定義テーブル１５ｅ内で
経路定義を識別するための経路ＩＤを割付ける（図４ス
テップＳ１１３）。経路ＩＤを割付けられた経路定義
は、経路定義テーブル１５ｅに記憶される（図４ステッ
プＳ１１４）。

【００５８】図９に示される経路定義テーブルの場合
は、ネットワーク管理者によって経路情報「ルータ３０
ａ→ルータ３０ｂ→ルータ３０ｃ→ルータ３０ｄ」、通
信パスＩＤ「Ｐ−００００１」、通信方向「上り」と、
経路情報「ルータ３０ｄ→ルータ３０ｃ→ルータ３０ｂ
→ルータ３０ａ」、通信パスＩＤ「Ｐ−００００１」、
通信方向「下り」という、通信パスＩＤ「Ｐ−００００
１」に対する上り通信と下り通信の経路が経路定義とし
てポリシーサーバ１０に入力され、制御部１４は、上り
通信の経路定義に対して経路ＩＤ「Ｒ−００００１」
を、下り通信の経路定義に対して経路ＩＤ「Ｒ−０００
０２」を割付けている。つまり、経路ＩＤ「Ｒ−０００
０１」が示す経路定義は、通信パスＩＤ「Ｐ−００００
１」の上り経路として、ルータ３０ａ→ルータ３０ｂ→
ルータ３０ｃ→ルータ３０ｄの順にＩＰフローを転送す
るという内容になる。

【００５９】つぎに、図１１〜図１４と図１０のフロー
チャートを参照してネットワーク管理者が指定した定義
に基づいてポリシーサーバ１０が作成した通信パス条件
定義テーブル１５ａと、サービスクラス定義テーブル１
５ｂと、アクション定義テーブル１５ｃと、予約通信パ
ス定義テーブル１５ｄと、経路定義テーブル１５ｅに基
づいてポリシーサーバ１０が通信チャンネル定義テーブ
ル１５ｆとポリシー定義テーブル１５ｇを作成し、作成
したポリシー定義をルータ３０ａ〜３０ｄに配信する動
作を説明する。

【００６０】予約通信パス定義テーブル１５ｄ（図８）
の上り経路ＩＤと下り経路ＩＤの項目に、経路定義テー
ブル１５ｅ（図９）に記憶されている通信方向が上りの
経路ＩＤと通信方向が下りの経路ＩＤが登録されると、
制御部１４は、図１１に示す通信チャンネル定義を作成
する（図１０ステップＳ２００）。通信チャンネル定義
は、予約通信パス定義テーブル１５ｄ（図８）に記憶さ
れている通信パスＩＤと、その通信パスＩＤで示される
予約通信パス定義に定義されている上り経路ＩＤと下り
経路ＩＤと予約通信チャンネル数に基づいて作成され
る。通信チャンネル定義テーブル１５ｆには、端末２０
ａ〜２０ｃからリソース予約リクエストを受信した場合
に割付けられるリクエストＩＤの項目が設けられ、通信
チャンネル定義を通信チャンネル定義テーブル１５ｆ内
で識別するためのチャンネルＩＤが割付けられる。通信
予約チャンネル定義は、１つの通信パスＩＤに対して予
約通信チャンネル数の２倍（上り通信用と下り通信用）
の数だけ作成される。作成された通信チャンネル定義
は、通信チャンネル定義テーブル１５ｆに記憶される
（図１０ステップＳ２０１）。

【００６１】図１１に示される通信チャンネル定義テー
ブル１５ｆの場合は、図８で示された予約通信パス定義
テーブル１５ｄに登録されている通信パスＩＤ「Ｐ−０
０００１」の予約通信チャンネル数が「２」なので、通
信パスＩＤが「Ｐ−００００１」に対して４つの通信チ
ャンネル定義「Ｌ−００００１〜Ｌ−００００４」が作
成され、経路ＩＤには、上り通信用の経路ＩＤ「Ｒ−０
０００１」と下り通信用の経路ＩＤ「Ｒ−００００２」
が登録されている。リクエストＩＤは、リソース予約リ
クエストを受け付けていないので何も登録されていな
い。

【００６２】制御部１４は、１つの通信チャンネル定義
が通信チャンネル定義テーブル１５ｆに記憶されると通
信チャンネルを設定する経路上の中継ルータ分のポリシ
ー定義（図１２）を作成する（図１０ステップＳ２０
２）。ポリシー定義には、通信チャンネル定義テーブル
１５ｆに記憶されているどの通信チャンネルに対するポ
リシー定義かを識別するためのチャンネルＩＤと、ポリ
シー定義を配信するルータを指定するノード名と、リソ
ース予約リクエストを受けて作成されるフィルタ条件定
義に割当てられるフィルタＩＤと、アクション定義テー
ブル１５ｃに記憶されているアクションＩＤと、Ｎｅｘ
ｔＨｏｐ情報があり、フィルタＩＤについては、この段
階では割付けられていないため指定しない。作成された
ポリシー定義はポリシー定義テーブル１５ｇに記憶され
る（図１０ステップＳ２０３）。

【００６３】図１２に示すポリシー定義テーブル１５ｇ
の場合は、通信チャンネル定義テーブル１５ｆ内のチャ
ンネルＩＤ「Ｌ−００００１」で示される通信チャンネ
ル定義が設定されると、チャンネルＩＤに「Ｌ−０００
０１」を指定し、チャンネルＩＤ「Ｌ−００００１」が
示す経路ＩＤ「Ｒ−００００１」から経路定義テーブル
１５ｅ（図９）に記憶されている経路情報を読み出し、
経路情報が示すルータ３０ａ〜３０ｄをノード名に指定
する。この場合は、経路情報に４つのルータが登録され
ているので、ポリシー定義ＩＤ「００００１〜００００
４」の４つのポリシー定義が作成される。ＮｅｘｔＨｏ
ｐ情報には、次にＩＰフローを転送するノード名が指定
されるので、ノード名に「ルータ３０ａ」が指定されて
いるポリシー定義ＩＤ「００００１」のＮｅｘｔＨｏｐ
情報には、経路定義テーブル１５ｅ内の経路ＩＤ「Ｒ−
００００１」が示す経路情報に「ルータ３０ａ→ルータ
３０ｂ→ルータ３０ｃ→ルータ３０ｄ」が登録されてい
るので「ルータ３０ｂ」が指定される。アクションＩＤ
は、チャンネルＩＤ「Ｌ−００００１」で示される通信
チャンネル定義テーブル１５ｆに記憶されている通信パ
スＩＤ「Ｐ−００００１」をキーワードに、通信パスＩ
Ｄ「Ｐ−００００１」が示す予約通信パス定義テーブル
１５ｄに記憶されている条件ＩＤ「Ｃ−００００１」を
読み出す。読み出した条件ＩＤ「Ｃ−００００１」で示
される通信パス条件定義テーブル１５ａに記憶されてい
る上りサービスクラス「クラスＡ」を読み出し、読み出
した「クラスＡ」をアクション定義テーブル１５ｃ（図
７）に記憶されているサービスクラス名からアクション
ＩＤを検索して指定する。フィルタＩＤは、現段階で
は、フィルタ条件定義が作成されていないため、存在し
ないので何も指定しない。

【００６４】このようにして、通信チャンネルＩＤに対
してポリシー定義を作成していくが、通信パスＩＤ「Ｐ
−００００１」に対して、チャンネルＩＤ「Ｌ−０００
０１〜Ｌ００００４」の４つの通信チャンネル定義が作
成されるので、ポリシー定義はポリシーＩＤ「００００
１〜０００１６」の１６個が作成される。

【００６５】全てのポリシー定義が作成され、ポリシー
定義テーブル１５ｇに記憶されると、表示部１２は、ポ
リシー定義の作成が完了したことを表示する（図１０ス
テップＳ２０４）。ネットワーク管理者は、ポリシー定
義を設定対象の各ルータに配信するコマンドを入力部１
１から指定する。配信コマンドを受け付けると、インタ
ーフェース部１３は、設定対象の各ルータにポリシー定
義情報を配信する（図１０ステップＳ２０５）。

【００６６】図１２のポリシー定義テーブル１５ｇの場
合は、ノード名にルータ３０ａが登録されているポリシ
ー定義は、ポリシー定義ＩＤが「００００１」と「００
００８」と「００００９」と「０００１６」の４つであ
る。ルータ３０ａには、４つのポリシー定義ＩＤが示し
ているポリシー定義のＮｅｘｔＨｏｐ情報と、アクショ
ンＩＤが示しているアクション定義テーブル１５ｃの詳
細定義とポリシー定義ＩＤがポリシー定義情報として配
信される。つまり、ポリシー定義ＩＤ「００００１」、
ＮｅｘｔＨｏｐ情報「ルータ３０ｂ」、詳細定義「保証
レート：１００ｋｂｐｓ、許容遅延：＜３０ｍｓ」と、
ポリシー定義ＩＤ「００００８」、詳細定義「保証レー
ト：１００ｋｂｐｓ、許容遅延：＜３０ｍｓ」と、ポリ
シー定義ＩＤ「００００９」、ＮｅｘｔＨｏｐ情報「ル
ータ３０ｂ」、詳細定義「保証レート：１００ｋｂｐ
ｓ、許容遅延：＜３０ｍｓ」と、ポリシー定義ＩＤ「０
００１６」、詳細定義「保証レート：１００ｋｂｐｓ、
許容遅延：＜３０ｍｓ」とがポリシー定義情報として配
信される。同様にしてルータ３０ｂ〜３０ｄに対するポ
リシー定義情報が作成され、ポリシー定義ＩＤ毎に該当
するルータに配信される。

【００６７】つぎに、ポリシー定義情報を受信したルー
タの動作を説明する。ルータ３０ａのＩＰフロー識別部
３１は、ポリシーサーバ１０からポリシー定義を受信す
ると、受信したポリシー定義に基づき、フィルタ条件情
報を作成し、図１３に示すフィルタ条件情報テーブル３
２に記憶する（図１０ステップＳ２０６、Ｓ２０７）。

【００６８】図１３に示すフィルタ条件情報テーブル３
２の場合は、４つのポリシー定義ＩＤ「００００１」と
「００００８」と「００００９」と「０００１６」が登
録されている。フィルタ条件情報については配信されて
いないので何も登録されない。

【００６９】ＱｏＳ制御部３３は、ポリシーサーバ１０
から受信したポリシー定義に基づき、ＱｏＳ制御情報を
作成し、図１４に示すＱｏＳ制御情報テーブル３４に記
憶する（ステップＳ２０８）。フィルタ条件情報テーブ
ル３２とＱｏＳ制御情報テーブル３４にポリシーサーバ
１０から受信したポリシー条件の反映が完了すると、ポ
リシーサーバ１０に設定完了応答を送信する（図１０ス
テップＳ２０９）。

【００７０】図１４に示すＱｏＳ制御情報テーブル３４
の場合は、ポリシー定義ＩＤとアクション定義の詳細情
報が登録されている。ポリシーサーバ１０からポリシー
定義ＩＤ「００００１」、「００００８」、「００００
９」、「０００１６」に対応する４つのポリシー定義情
報が送信されてきたことになる。ＱｏＳ制御部３３は、
このＱｏＳ制御情報テーブル３４の内容に基づいてＱｏ
Ｓ制御を行うが、フィルタ条件情報テーブル３２にフィ
ルタ条件情報が設定されていない場合には、ＱｏＳ制御
情報テーブル３４に設定されているアクション定義とＮ
ｅｘｔＨｏｐ情報は無効になり、ＱｏＳ制御は行われな
い。

【００７１】インターフェース部１３が、ルータから設
定完了応答を受信して設定が完了した通知を受信すると
（図１０ステップＳ２１０）、制御部１４は、予約通信
パス定義テーブル１５ｄの配信フラグを未配信から配信
済みに変更する（図１０ステップＳ２１１）。予約通信
パス定義テーブル１５ｄの配信フラグが配信済みに変更
されると、予約通信パスは、リソース予約リクエストに
対応して割当てが可能となる。

【００７２】つぎに、図１６〜図２４と図１５のフロー
チャートを参照して、端末２０ａからリソース予約リク
エストを受信して通信パスを割当てる動作を説明する。

【００７３】ポリシーサーバ１０は、ポリシー定義をル
ータ３０ａ〜３０ｄに配信し、配信フラグを配信済みに
するとリソース予約リクエストの受信待ちになる（図１
５ステップＳ３００）。インターフェース部１３が、端
末２０ａからリソース予約リクエストを受信すると（図
１５ステップＳ３０１）、制御部１４は、通信パス条件
定義テーブル１５ａ（図１７参照）を読み出し、リソー
ス予約リクエストで指定された条件に適合する通信パス
条件定義を検索する（図１５ステップＳ３０２）。

【００７４】図１６（ａ）は、ポリシーサーバ１０が端
末２０ａから受信したリソース予約リクエストの内容を
示している。端末２０ａからのリソース予約リクエスト
は、発信元ＩＰアドレス「０．０．１．１」、宛先ＩＰ
アドレス「０．０．４．２」、ポート番号「指定無
し」、上りサービスクラス「クラスＡ」、下りサービス
クラス「クラスＡ」という内容である。図１７に示す通
信パス条件定義テーブル１５ａに記憶されている通信パ
ス条件定義の中で端末２０ａからのリクエストで指定さ
れた条件に適合する通信パスを検索すると、条件ＩＤ
「Ｃ−００００１」が示す通信パス条件定義が選択され
る。

【００７５】リソース予約リクエストで指定された条件
に適合する通信パス条件定義が見つかった場合、制御部
１４は、予約通信パス定義テーブル１５ｄ（図１８参
照）を読み出し、検索した通信パス条件の条件ＩＤをも
とに予約通信パス定義テーブル１５ｄに登録されている
予約通信パスの中から未使用の通信チャンネルを検索し
て割当てる（図１５ステップＳ３０３）。

【００７６】図１８に示す予約通信パス定義テーブル１
５ｄの場合、条件ＩＤが「Ｃ−００００１」の通信パス
は通信パスＩＤ「Ｐ−００００１〜Ｐ−００００２」の
２つがある。配信フラグは２つとも配信済みであるの
で、通信パスの割当は可能である。つぎに、優先度を比
較すると、通信パスＩＤ「Ｐ−００００１」の優先度は
「１」であり、通信パスＩＤ「Ｐ−００００２」の優先
度は「２」となっているので、通信パスＩＤ「Ｐ−００
００１」で指定される予約通信パスを選択する。予約通
信パスの選択は、優先度で選択するだけでなく、利用率
を比較して利用率が平均されるように選択したり、優先
度と利用率を合わせた形で選択してもよい。

【００７７】通信パスが決定すると図１９に示す通信チ
ャンネル定義テーブル１５ｆから、通信パスＩＤ「Ｐ−
００００１」が登録されているチャンネルＩＤを検索す
る。図１９の場合、チャンネルＩＤ「Ｌ−００００１〜
Ｌ−００００４」の４つがある。その中から経路ＩＤ
が、通信パスＩＤ「Ｐ−００００１」の上り経路ＩＤ
「Ｒ−００００１」と下り経路ＩＤ「Ｒ−００００２」
と一致して、リクエストＩＤが登録されていないものを
検索する。上り経路ＩＤが一致するチャンネルＩＤは
「Ｌ−００００１」と「Ｌ−００００３」であり、どち
らもリクエストＩＤが登録されていないので、最初に検
索される「Ｌ−００００１」を上り用チャンネルとす
る。下り用通信チャンネルについても同様の検索を行
い、チャンネルＩＤ「Ｌ−００００２」を下り用通信チ
ャンネルに決定する。決定したチャンネルＩＤが示すリ
クエストＩＤには、リソース予約リクエストに割当てた
ことを示すために、図２０に示すように、リクエストＩ
Ｄを割付けて登録する。図２０では、選択された通信チ
ャンネル「Ｌ−００００１〜Ｌ−００００２」に対して
リクエストＩＤ「Ｒｅｑ−００００１」を割当てて登録
している。

【００７８】このように通信チャンネルが端末２０ａの
リソース予約リクエストによって割当てられたので、予
約通信パス定義テーブル１５ｄの通信パスＩＤ「Ｐ−０
０００１」で示される使用チャンネル数はチャンネルを
割当てる前に使用チャンネル数＋１に変更される。ま
た、利用率についても新たに計算されて登録される。

【００７９】通信パスが決定すると、制御部１４は、端
末２０ａから受信したリソース予約リクエストに基づき
フィルタ条件定義を作成し、図２１に示すように、作成
したフィルタ条件定義をフィルタ条件定義テーブル１５
ｈに記憶する（図１５ステップＳ３０４）。

【００８０】図２１は、端末２０ａからのリソース予約
リクエストに基づいて作成されたフィルタ条件定義テー
ブル１５ｈを示している。図１６に示したように、リソ
ース予約リクエストの発信元ＩＰアドレスは「０．０．
１．１」で、宛先ＩＰアドレスは「０．０．４．２」で
あるので、上り通信用のフィルタ条件定義の詳細定義に
は、「Ｓ−Ａｄｄｒ＝００．００．０１．１１，Ｄ−Ａ
ｄｄｒ＝００．００．０４．１２」が登録される。リク
エストＩＤには、通信チャンネルを割当てた時に割り振
られた「Ｒｅｑ−００００１」が登録される。フィルタ
条件定義テーブル１５ｈ内でフィルタ条件を識別するた
めのフィルタＩＤ「Ｆ−００００１」が割付けられて登
録される。下り通信は、発信元ＩＰアドレスと宛先ＩＰ
アドレスが逆になるので、詳細定義には「Ｒ−Ａｄｄｒ
＝００．００．０４．１２，Ｄ−Ａｄｄｒ＝００．０
０．０１．１１」が登録され、リクエストＩＤには、
「Ｒｅｑ−００００１」が登録され、フィルタＩＤ「Ｆ
−００００２」が割当てられている。

【００８１】フィルタ条件定義がフィルタ条件定義テー
ブル１５ｈに登録されると、制御部１４は、ポリシー定
義テーブル１５ｇを読み出し、通信パスを割付けた通信
チャンネルＩＤを検索して、該当するポリシー定義のフ
ィルタＩＤにフィルタ条件定義を作成した時に割付けら
れたフィルタＩＤを登録し、端末２０ａからのリソース
予約リクエストに対応したポリシー定義を作成し、図２
２に示すように、作成したポリシー定義をポリシー定義
テーブル１５ｇに記憶させる（図１５ステップＳ３０
５）。

【００８２】端末２０ａからのリソース予約リクエスト
に対応したポリシー定義が完成すると、制御部１４は、
フィルタ条件通知を作成する。インターフェース部１３
は、作成されたフィルタ条件通知を該当するルータに配
信する（図１５ステップＳ３０６）。

【００８３】端末２０ａから受信したリソース予約リク
エストに対して割当てられた上り用通信チャンネルは、
チャンネルＩＤ「Ｌ−００００１」であった。したがっ
て図２２に示すポリシー定義テーブル１５ｇのチャンネ
ルＩＤを検索すると、チャンネルＩＤが「Ｌ−００００
１」と一致するポリシー定義は、ポリシー定義ＩＤ「０
０００１〜００００４」の４つとなる。これらのポリシ
ー定義ＩＤ「００００１〜００００４」に対応するフィ
ルタＩＤの欄に、フィルタ条件定義を識別するために割
当てられたフィルタＩＤ「Ｆ−００００１」を登録す
る。下り用通信チャンネルも同様に検索を行い、ポリシ
ー定義ＩＤ「００００５〜００００８」に対応するフィ
ルタＩＤの欄に「Ｆ−００００２」を登録してリソース
予約リクエストに対応したポリシー定義を作成する。

【００８４】ポリシーサーバ１０からルータへのフィル
タ条件設定通知の配信は、ポリシー定義テーブル１５ｇ
のフィルタＩＤの欄にフィルタＩＤが登録されているも
のについて実行される。図２２のポリシー定義テーブル
１５ｇの場合は、ポリシー定義ＩＤ「００００１〜００
００８」で示される８つについて、フィルタ条件設定通
知の配信が行われる。ポリシーサーバ１０からルータへ
配信されるフィルタ条件設定通知には、図２３（ａ）に
示すように、ポリシー定義ＩＤとフィルタＩＤで示され
るフィルタ条件定義テーブル１５ｈの詳細内容が設定さ
れる。図２３（ａ）で示すフィルタ条件設定通知には、
ポリシー定義ＩＤ「００００１」とフィルタ条件情報と
して、フィルタ条件定義テーブル１５ｈのフィルタＩＤ
「Ｆ−００００１」で示される詳細定義「Ｓ−Ａｄｄｒ
＝００．００．０１．１１，Ｄ−Ａｄｄｒ＝００．０
０．０４．１２」が設定されている。なお、図２３
（ａ）に示すフィルタ条件設定通知の配信先は、ポリシ
ー定義テーブル１５ｇでポリシー定義ＩＤ「００００
１」で示されるノード名の欄に登録されている「ルータ
３０ａ」となる。

【００８５】ルータ（この場合はルータ３０ａ）のＩＰ
フロー識別部３１は、ポリシーサーバ１０からフィルタ
条件設定通知を受信すると、図２４に示すように、フィ
ルタ条件情報テーブル３２のフィルタ条件情報にフィル
タ条件設定通知に含まれるフィルタ条件情報を設定する
（図１５ステップＳ３０７）。フィルタ条件情報の設定
が完了すると、ＩＰフロー識別部３１は、ＱｏＳ制御部
３３に対してフィルタ条件情報を設定したポリシー定義
ＩＤのポリシー定義有効化リクエストを通知する。

【００８６】ＩＰフロー識別部３１からポリシー定義有
効化リクエストの通知を受けたＱｏＳ制御部３３は、Ｑ
ｏＳ制御情報テーブル３４に登録されているポリシー定
義有効化リクエストに対応するポリシー定義ＩＤのアク
ション定義を有効にして（図１４参照）、図２３（ｂ）
に示すような、フィルタ条件設定応答をポリシーサーバ
１０に送信する（図１５ステップＳ３０８）。その後、
ＱｏＳ制御部３３は、有効になったフィルタ条件情報テ
ーブル３２のフィルタ条件情報に該当するＩＰフローを
検出すると、ＱｏＳ制御情報テーブル３４に登録されて
いるアクション定義とＮｅｘｔＨｏｐ情報に従って、Ｑ
ｏＳ制御を実行する（図１５ステップＳ３０９）。

【００８７】前述した図１５ステップＳ３０７の処理に
おいて、ルータ３０ａが受信したフィルタ条件設定通知
が、ポリシー定義ＩＤ「００００１」、フィルタ条件情
報「Ｓ−Ａｄｄｒ＝００．００．０１．１１，Ｄ−Ａｄ
ｄｒ＝００．００．０４．１２」である場合、フィルタ
条件情報テーブル３２に設定されているポリシー定義Ｉ
Ｄの中から「００００１」を検索し、検索されたポリシ
ー定義ＩＤに対応するフィルタ条件情報に、フィルタ条
件情報「Ｓ−Ａｄｄｒ＝００．００．０１．１１，Ｄ−
Ａｄｄｒ＝００．００．０４．１２」を登録する（図２
４参照）。

【００８８】また、前述した図１５ステップＳ３０８の
処理においては、図２３（ｂ）に示す、フィルタ条件設
定応答をポリシーサーバ１０に送信する。フィルタ条件
設定応答には、設定がされたか否かを示す結果コードと
どのポリシー定義に対するフィルタ条件情報の設定を行
ったかを示すためにポリシー定義ＩＤが含まれている。

【００８９】図２４のフィルタ条件情報テーブル３２の
場合は、ポリシー定義ＩＤ「００００１」にフィルタ条
件情報「Ｓ−Ａｄｄｒ＝００．００．０１．１１，Ｄ−
Ａｄｄｒ＝００．００．０４．１２」が、ポリシー定義
ＩＤ「００００８」にフィルタ条件情報「Ｓ−Ａｄｄｒ
＝００．００．０４．１２，Ｄ−Ａｄｄｒ＝００．０
０．０１．１１」が登録されている。前述した図１５ス
テップＳ３０８の処理においては、フィルタ条件情報が
登録されたポリシー定義ＩＤ「００００１」と「０００
０８」について、ポリシー定義を有効にするので、図１
４に示すＱｏＳ制御情報テーブル３４の場合は、ポリシ
ー定義ＩＤ「００００１」のアクション定義「保証レー
ト：１００Ｋｂｐｓ，遅延：＜３０ｍｓ」、ＮｅｘｔＨ
ｏｐ情報「ルータ３０ｂ」と、ポリシー定義ＩＤ「００
００８」のアクション定義「保証レート：１００Ｋｂｐ
ｓ，遅延：＜３０ｍｓ」、ＮｅｘｔＨｏｐ情報「指定無
し」の２つが有効となる。

【００９０】ポリシーサーバ１０のインターフェース部
１３が、ルータ３０ａから送信されたフィルタ条件設定
応答を受信すると（図１５ステップＳ３１０）、制御部
１４は、端末２０ａに対するリソース予約レスポンスを
作成する。リソース予約レスポンスは、図１６（ｂ）に
示すように、結果コードとリクエストＩＤからなる。結
果コードは、フィルタ条件設定応答に含まれる結果コー
ドで、リソース予約が成功したか失敗したかの結果情報
であり、リクエストＩＤは、リソース予約リクエストを
受け付けたときに通信チャンネル定義テーブル１５ｆ
（図２０参照）に登録したリクエストＩＤで、リソース
の解除を行うときに使用される。インターフェース部１
３は、リソース予約レスポンスを端末２０ａに送信する
（図１５ステップＳ３１１）。

【００９１】つぎに、図２５のフローチャートと図２６
および図２７を参照して通信リソースの使用が完了し
て、通信パスを解放するときの動作を説明する。

【００９２】ポリシーサーバ１０のインターフェース部
１３が、端末２０ａからのリソース解放リクエストを受
信すると（図２５ステップＳ４００）、制御部１４は、
通信チャンネル定義テーブル１５ｆ（図２０）を読み出
し、リソース解放リクエストで指定されたリクエストＩ
Ｄをキーワードに通信チャンネル定義テーブル１５ｆを
検索して通信チャンネル定義を検出する（図２５ステッ
プＳ４０１）。

【００９３】端末２０ａから送信されたリソース解放リ
クエストは、図２６（ａ）で示すように、リクエストＩ
Ｄ「Ｒｅｑ−００００１」が指定されている。図２０で
示す通信チャンネル定義テーブル１５ｆの場合は、リク
エストＩＤ「Ｒｅｑ−００００１」を検索すると、通信
チャンネルＩＤ「Ｌ−００００１〜Ｌ−００００２」で
示される２つの通信チャンネル定義が検出される。

【００９４】通信チャンネル定義テーブル１５ｆの中か
ら、リソース解放リクエストで指定されたリクエストＩ
Ｄが含まれる通信チャンネル定義が検出されると、制御
部１４は、ポリシー定義テーブル１５ｇ（図２２）を読
み出し、検出された通信チャンネル定義を示すチャンネ
ルＩＤをキーワードにポリシー定義テーブル１５ｇを検
索してポリシー定義を検出する（図２５ステップＳ４０
２）。

【００９５】図２２で示すポリシー定義テーブル１５ｇ
の場合は、通信チャンネルＩＤ「Ｌ−００００１」で検
索すると、ポリシー定義ＩＤ「００００１〜００００
４」で示される４つのポリシー定義が検出される。ま
た、通信チャンネルＩＤ「Ｌ−００００２」で検索する
と、ポリシー定義ＩＤ「００００５〜００００８」で示
される４つのポリシー定義が検出される。

【００９６】ポリシー定義テーブル１５ｇの中でフィル
タＩＤが登録されているポリシー定義から、リソース予
約リクエストで指定されたリクエストＩＤに対応する通
信チャンネルＩＤが含まれるポリシー定義が検出される
と、インターフェース部１３は、検出されたポリシー定
義のノード名に指定されているルータにフィルタ条件解
除通知を配信する（図２５ステップＳ４０３）。

【００９７】図２２で示すポリシー定義テーブル１５ｇ
の場合は、フィルタＩＤが登録されているポリシー定義
のうち、ノード名にルータ３０ａが指定されているポリ
シー定義は、ポリシー定義ＩＤ「００００１」と「００
００８」で示される２つが存在する。フィルタ条件解除
通知は、図２７（ａ）で示すようにポリシー定義ＩＤで
構成されているので、ポリシー定義毎に作成する。つま
り、ルータ３０ａに配信されるフィルタ条件解除通知
は、ポリシー定義ＩＤ「００００１」と「００００８」
に対して作成される。ルータ３０ｂ〜ルータ３０ｄにつ
いても同様に、それぞれにフィルタ条件解除通知が２つ
ずつ作成される。作成されたフィルタ条件解除通知は対
応するルータに配信される。

【００９８】ポリシーサーバ１０からフィルタ条件解除
通知を受信すると、ルータのＩＰフロー識別部３１は、
フィルタ条件情報テーブル３２（図２４）を読み出し、
フィルタ条件解除通知で指定されたポリシー定義ＩＤを
キーワードにフィルタ条件情報テーブル３２を検索す
る。そして、フィルタ条件情報テーブル３２の中で、フ
ィルタ条件通知で指定されたポリシー定義ＩＤと一致し
たポリシー定義ＩＤで示されるフィルタ条件情報をフィ
ルタ条件情報テーブル３２から削除する（図２５ステッ
プＳ４０４、Ｓ４０５）。

【００９９】ポリシーサーバ１０から送信されたフィル
タ条件解除通知は、図２７（ａ）で示すように、ポリシ
ー定義ＩＤ「００００１」が指定されている。図２４で
示すフィルタ条件情報テーブル３２の場合は、ポリシー
定義ＩＤが一致するフィルタ条件情報は、「Ｓ−Ａｄｄ
ｒ＝００．００．０１．１１，Ｄ−Ａｄｄｒ＝００．０
０．０４．１２」が存在する。このフィルタ条件情報を
削除する。

【０１００】フィルタ条件情報テーブル３２からフィル
タ条件情報を削除すると、ＩＰフロー識別部３１は、Ｑ
ｏＳ制御部３３にポリシー定義無効化リクエストを通知
する（図２５ステップＳ４０６）。ポリシー定義無効化
リクエストを通知されたＱｏＳ制御部３３は、図１４に
示すＱｏＳ制御情報テーブル３４に登録されているアク
ション定義とＮｅｘｔＨｏｐ情報にしたがったＱｏＳ制
御を終了する（図２５ステップＳ４０７）。

【０１０１】図１４に示すＱｏＳ制御情報テーブル３４
の場合は、ポリシー定義ＩＤ「００００１」で示される
アクション定義「保証レート：１００ｋｂｐｓ，遅延：
＜３０ｍｓ」とＮｅｘｔＨｏｐ情報「ルータ３０ｂ」を
無効にする。

【０１０２】フィルタ条件解除通知で指定されたポリシ
ー定義ＩＤに対して、フィルタ条件情報テーブル３２の
フィルタ条件情報の削除とＱｏＳ制御情報テーブル３４
に登録されたアクション定義とＮｅｘｔＨｏｐ情報を無
効にすると、図２７（ｂ）で示すフィルタ条件解除応答
をポリシーサーバ１０に送信する（図２５ステップＳ４
０８）。

【０１０３】ポリシーサーバ１０のインターフェース部
１３が、ルータ３０ａからのフィルタ条件解除応答を受
信すると（図２５ステップＳ４０９）、制御部１４は、
フィルタ条件定義テーブル１５ｈとポリシー定義テーブ
ル１５ｇを読み出し、フィルタ条件解除通知で削除した
フィルタ定義とフィルタＩＤを削除する（図２５ステッ
プＳ４１０）。制御部１４は、予約通信パス定義テーブ
ル１５ｄを読み出し、予約通信チャンネル数に登録され
ている予約通信チャンネル数−１を登録し、更新した使
用チャンネル数から利用率を計算して登録する（図２５
ステップＳ４１１）。

【０１０４】予約通信パス定義テーブル１５ｄの変更が
完了すると、インターフェース部１３は、図２６（ｂ）
に示すリソース解放レスポンスを端末２０ａに送信する
（図２５ステップＳ４１２）。リソース解放レスポンス
には、結果コードと、リクエストＩＤとが含まれてい
る。

【０１０５】このようにこの実施の形態１のポリシーサ
ーバは、ネットワーク管理者によって入力された通信パ
ス条件定義とサービスクラス定義とアクション定義と予
約通信パス定義と経路定義に基づいて、通信パス条件定
義テーブルとサービスクラス定義テーブルとアクション
定義テーブルと予約通信パス定義テーブルと経路定義テ
ーブルと通信チャンネル定義テーブルと、フィルタ条件
定義を除くポリシー定義テーブルを作成し、各端末にサ
ービスクラス定義を配信し、ルータにはフィルタ条件定
義を除くポリシー定義の配信を行う。フィルタ条件定義
を除くポリシー定義を受信したルータは、受信したポリ
シー定義の設定を行う。また、ポリシーサーバは、ＩＰ
ネットワーク上に接続されている端末から希望する通信
品質での通信回線を確保するためのリソース予約リクエ
ストを受信すると、受信したリソース予約リクエストで
指定された条件に基づいて、予め設定済みの通信パスの
中の通信チャンネルを割当て、リソース予約リクエスト
で指定されたＩＰフローを識別するためのフィルタ条件
定義を作成し、割当てた通信パスのルータにだけフィル
タ条件定義の配信を行う。フィルタ条件定義を受信した
ルータは、フィルタ条件を設定し、既に設定済みの条件
を有効にして、フィルタ条件で識別されたＩＰフローに
対応するＱｏＳ制御を開始するようにしている。このた
め、この実施の形態１によれば、無駄なリソースの確保
を無くし、リソース予約リクエストに対する早急な応答
を実現することができる。

【０１０６】また、端末間のＩＰフローを転送する複数
のルータを経由する論理的な通信経路である通信パスを
定義する場合、どちらか一方の端末を基準として通信方
向を決定し、上り通信と下り通信の通信経路を一組とし
て通信パスの管理を行い、通信パスに対応させたポリシ
ー定義の作成および設定を行うようにしているため、ネ
ットワーク管理者の負担を軽減させることができる。

【０１０７】さらに、リソース予約リクエストを受信
し、予約通信パスを割当てる場合、優先度と利用率の情
報に基づき通信パスを決定するようにしているため、同
一サービスクラスのリソース予約リクエストが大量に発
生した場合でも、複数の通信パスに負荷を分散させて、
特定の通信パスへの負荷の集中を防ぐことができる。

【０１０８】実施の形態２．図２８は、実施の形態２の
ネットワーク構成を示すブロック図である。実施の形態
２におけるネットワーク構成は、電話網５０ａを介して
ＶｏＩＰ（Voice over IP）ゲートウェイ６０ａに接続
されＩＰネットワークでの通信を行う電話機４０ａと、
電話網５０ｂを介してＶｏＩＰゲートウェイ６０ｂに接
続されＩＰネットワークでの通信を行う電話機（請求の
範囲でいうところの通信装置）４０ｂと、ルータに対す
るＱｏＳ制御を行うための制御コマンドであるポリシー
定義の管理と配信を行うポリシーサーバ１０と、ネット
ワークからネットワークにＩＰフローを転送するための
中継装置である７台のルータ３０ａ〜３０ｇと、Ｃａｌ
ｌ Ａｇｅｎｔ（呼制御）サーバ７０で構成されてい
る。図１に示した実施の形態１と同じ機能を持つ構成部
分には同一符号を付し、重複する説明は省略する。

【０１０９】ＶｏＩＰゲートウェイ６０ａ、６０ｂは、
電話機４０ａと電話機４０ｂ間でＩＰネットワークを介
して音声通信を可能にするため、ＩＰネットワークと電
話網の通信データに符号化処理、復号処理、パケット処
理、呼設定処理を行う。

【０１１０】Ｃａｌｌ Ａｇｅｎｔサーバ７０は、Ｖｏ
ＩＰゲートウェイ６０ａ、６０ｂからの呼設定リクエス
トにより相手先電話番号と相手先ＶｏＩＰゲートウェイ
６０ｂ、６０ａのＩＰアドレスを対応付け、ユーザ承認
機能と帯域リクエスト機能を備えている。

【０１１１】実施の形態２では、電話機４０ａと電話機
４０ｂ間で通信を行う場合についての動作を説明する。

【０１１２】ポリシーサーバ１０は、図４のフローチャ
ートに示した通信パスの予約処理にしたがって、ネット
ワーク管理者から入力された通信パス条件定義とサービ
スクラス定義とアクション定義と予約通信パス定義と経
路定義に基づいて、通信パス条件定義テーブル１５ａと
サービスクラス定義テーブル１５ｂとアクション定義テ
ーブル１５ｃと予約通信パス定義テーブル１５ｄと経路
定義テーブル１５ｅを作成する。

【０１１３】つぎに、ポリシーサーバ１０は、図１０の
フローチャートに示したポリシー定義配信処理にしたが
って、ＶｏＩＰゲートウェイ６０ａからＶｏＩＰゲート
ウェイ６０ｂ間に、ルータ３０ａ、ルータ３０ｂ、ルー
タ３０ｃ、ルータ３０ｄを経由する通信パスを作成し、
ルータ３０ａ〜ルータ３０ｄにフィルタ条件を除くポリ
シー定義を配信する。

【０１１４】電話機４０ａからの通話要求は、電話網５
０ａを介してＶｏＩＰゲートウェイ６０ａに通知され
る。電話機４０ａからの通話要求を受信すると、ＶｏＩ
Ｐゲートウェイ６０ａは、Ｃａｌｌ Ａｇｅｎｔサーバ
７０に呼設定要求を通知する。ＶｏＩＰゲートウェイ６
０ａから呼設定要求を受信すると、Ｃａｌｌ Ａｇｅｎ
ｔサーバ７０は、呼用に希望する通信品質での通信回線
を確保するために、ポリシーサーバ１０に対してリソー
ス予約リクエストを通知する。

【０１１５】リソース予約リクエストを受信したポリシ
ーサーバ１０は、図１５のフローチャートに示した通信
パス割当て処理にしたがって、電話機４０ａと電話機４
０ｂ間の通信を可能にするために、ＶｏＩＰゲートウェ
イ６０ａとＶｏＩＰゲートウェイ６０ｂ間に通信パスを
割当てる。

【０１１６】電話機４０ａと電話機４０ｂの通信が終了
すると、Ｃａｌｌ Ａｇｅｎｔサーバ７０は、ポリシー
サーバ１０にリソース解放リクエストを通知する。リソ
ース解放リクエストを受信したポリシーサーバ１０は、
図２５のフローチャートに示す通信パス解放処理にした
がって、ＶｏＩＰゲートウェイ６０ａとＶｏＩＰゲート
ウェイ６０ｂ間に割当てた通信パスを解放する。

【０１１７】このようにこの実施の形態２では、電話網
を介してＶｏＩＰゲートウェイに接続されＩＰネットワ
ークでの通信を行う電話機間の通信においても、Ｃａｌ
ｌＡｇｅｎｔサーバがリソース予約リクエストおよびリ
ソース解放リクエストをポリシーサーバに通知するよう
にして、ネットワーク管理者によって入力された通信パ
ス条件定義とサービスクラス定義とアクション定義と予
約通信パス定義と経路定義に基づいて、通信パス条件定
義テーブルとサービスクラス定義テーブルとアクション
定義テーブルと予約通信パス定義テーブルと経路定義テ
ーブルと通信チャンネル定義テーブルとフィルタ条件定
義を除くポリシー定義テーブルを作成し、Ｃａｌｌ Ａ
ｇｅｎｔサーバにサービスクラス定義を配信し、ルータ
にはフィルタ条件定義を除くポリシー定義の配信を行
う。フィルタ条件定義を除くポリシー定義を受信したル
ータは、受信したポリシー定義の設定を行う。ポリシー
サーバは、ＩＰネットワーク上に接続されている電話機
からの通話要求に連動したＣａｌｌ Ａｇｅｎｔサーバ
からリソース予約リクエストを受信すると、受信したリ
ソース予約リクエストで指定された条件に基づいて、予
め設定済みの通信パスの中の通信チャンネルを割当て、
リソース予約リクエストで指定されたＩＰフローを識別
するためのフィルタ条件定義を作成し、割当てた通信パ
スのルータにだけフィルタ条件定義の配信を行う。フィ
ルタ条件定義を受信したルータは、フィルタ条件を設定
し、既に設定済みの条件を有効にして、フィルタ条件で
識別されたＩＰフローに対応するＱｏＳ制御を開始する
ようにしている。このため、この実施の形態２によれ
ば、無駄なリソースの確保を無くし、リソース予約リク
エストに対する早急な応答を実現することができる。

【０１１８】

【発明の効果】以上説明したように、この発明によれ
ば、ポリシーサーバは、予め作成された複数の中継装置
を経由して通信装置を接続する通信パスを予約通信パス
として予約しておき、予約通信パスに基づいて、フィル
タ条件を除くポリシー定義を作成し、作成したポリシー
定義を中継装置に対して予め配信し、その後通信装置か
らリソース予約リクエストを受付けた時に、フィルタ条
件定義を作成して中継装置に配信するようにしているた
め、無駄なリソースの確保を無くし、リソース予約リク
エストを受付けてからの処理およびルータに転送するデ
ータ量を少なくし、リソース予約リクエストに対する早
急な応答を実現することができる。

【０１１９】つぎの発明によれば、通信装置間のＩＰフ
ローを転送する複数の中継装置を経由する論理的な通信
経路である通信パスを定義する場合、どちらか一方の通
信装置を基準として通信方向を決定し、上り通信と下り
通信の通信経路を一組として通信パスの管理を行い、通
信パスに対応させたポリシー定義の作成および設定を行
うようにしているため、ネットワーク管理者の負担を軽
減させることができる。

【０１２０】つぎの発明によれば、中継装置は、フィル
タ条件を除くポリシー定義を設定した場合、その後ポリ
シー定義に対応したフィルタ条件が設定されるまでは、
ポリシー定義にしたがったＱｏＳ制御を無効にするよう
にしているため、無駄なリソースの確保を無くすことが
できる。

【０１２１】つぎの発明によれば、リソース予約リクエ
ストを受信し、予約通信パスを割当てる場合、優先度と
利用率の情報に基づき通信パスを決定するようにしてい
るため、同一サービスクラスのリソース予約リクエスト
が大量に発生した場合でも、複数の通信パスに負荷を分
散させて、特定の通信パスへの負荷の集中を防ぐことが
できる。

【０１２２】つぎの発明によれば、ポリシーサーバは、
予め作成された複数の中継装置を経由して通信装置を接
続する通信パスを予約通信パスとして予約しておき、予
約通信パスに基づいて、フィルタ条件を除くポリシー定
義を作成し、作成したポリシー定義を中継装置に対して
予め配信し、その後通信装置からリソース予約リクエス
トを受付けた時に、フィルタ条件定義を作成して中継装
置に配信するようにしているため、無駄なリソースの確
保を無くし、リソース予約リクエストを受付けてからの
処理およびルータに転送するデータ量を少なくし、リソ
ース予約リクエストに対する早急な応答を実現すること
ができる。

【０１２３】つぎの発明によれば、通信装置間のＩＰフ
ローを転送する複数の中継装置を経由する論理的な通信
経路である通信パスを定義する場合、どちらか一方の通
信装置を基準として通信方向を決定し、上り通信と下り
通信の通信経路を一組として通信パスの管理を行い、通
信パスに対応させたポリシー定義の作成および設定を行
うようにしているため、ネットワーク管理者の負担を軽
減させることができる。

【０１２４】つぎの発明によれば、リソース予約リクエ
ストを受信し、予約通信パスを割当てる場合、優先度と
利用率の情報に基づき通信パスを決定するようにしてい
るため、同一サービスクラスのリソース予約リクエスト
が大量に発生した場合でも、複数の通信パスに負荷を分
散させて、特定の通信パスへの負荷の集中を防ぐことが
できる。

【図面の簡単な説明】

【図１】 実施の形態１のポリシーサーバが接続されて
いるネットワークの構成を示す図である。

【図２】 図１に示したポリシーサーバの構成を示す図
である。

【図３】 図１に示したルータの構成を示す図である。

【図４】 ネットワーク管理者が設定を行って作成され
るテーブルの作成の動作を説明するためのフローチャー
トである。

【図５】 図２に示した通信パス条件定義テーブルの内
容を示す図である。

【図６】 図２に示したサービスクラス定義テーブルの
内容を示す図である。

【図７】 図２に示したアクション定義テーブルの内容
を示す図である。

【図８】 図２に示した予約通信パス定義テーブルの内
容を示す図である。

【図９】 図２に示した経路定義テーブルの内容を示す
図である。

【図１０】 ポリシーサーバが作成するテーブル作成の
動作を説明するためのフローチャートである。

【図１１】 図２に示した通信チャンネル定義テーブル
の内容を示す図である。

【図１２】 図２に示したポリシー定義テーブルの内容
を示す図である。

【図１３】 フィルタ条件情報テーブルの内容を示す図
である。

【図１４】 アクション定義情報テーブルの内容を示す
図である。

【図１５】 ポリシーサーバがリソース予約リクエスト
を受信した時の動作を説明するためのフローチャートで
ある。

【図１６】 リソース予約リクエストの内容を示す図で
ある。

【図１７】 通信パス条件定義テーブルの内容を示す図
である。

【図１８】 予約通信パス定義テーブルの内容を示す図
である。

【図１９】 通信チャンネル定義テーブルの内容を示す
図である。

【図２０】 通信チャンネル定義テーブルの内容を示す
図である。

【図２１】 フィルタ条件定義テーブルの構成を示す図
である。

【図２２】 ポリシー定義テーブルの内容を示す図であ
る。

【図２３】 フィルタ条件設定通知の内容を示す図であ
る。

【図２４】 フィルタ条件情報テーブルの内容を示す図
である。

【図２５】 ポリシーサーバがリソース解放リクエスト
を受信した時の動作を説明するためのフローチャートで
ある。

【図２６】 リソース解放リクエストの内容を示す図で
ある。

【図２７】 フィルタ条件解除通知の内容を示す図であ
る。

【図２８】 実施の形態２のポリシーサーバが接続され
ているネットワークの構成を示す図である。

【符号の説明】

１０ ポリシーサーバ、１１ 入力部、１２ 表示部、
１３ インターフェース部、１４ 制御部、１５ 記憶
部、１５ａ 通信パス条件定義テーブル、１５ｂ サー
ビスクラス定義テーブル、１５ｃ アクション定義テー
ブル、１５ｄ予約通信パス定義テーブル、１５ｅ 経路
定義テーブル、１５ｆ 通信チャンネル定義テーブル、
１５ｇ ポリシー定義テーブル、１５ｈ フィルタ条件
定義テーブル、２０ａ、２０ｂ、２０ｃ 端末、３０
ａ、３０ｂ、３０ｃ、３０ｄ、３０ｅ、３０ｆ、３０ｇ
ルータ、３１ ＩＰフロー識別部、３２ フィルタ条
件情報テーブル、３３ ＱｏＳ制御部、３４ ＱｏＳ制
御情報テーブル、４０ａ、４０ｂ 電話機、５０ａ、５
０ｂ 電話網、６０ａ、６０ｂ ＶｏＩＰゲートウェ
イ、７０ Ｃａｌｌ Ａｇｅｎｔサーバ。

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ＱｏＳ制御の指示を行うポリシー定義を
   作成し、作成したポリシー定義を中継装置に配信するポ
   リシーサーバと、前記ポリシーサーバから配信されたポ
   リシー定義に基づいた通信品質でＩＰフローを転送して
   ＩＰフローの経路選択を行う中継装置と、前記中継装置
   を介してＩＰフローの送受信が可能な通信装置とを備え
   るネットワークに適用され、前記通信装置からオンデマ
   ンドに入力されたリソース予約リクエストで指定された
   通信品質の通信経路を確保するべく通信経路上の中継装
   置にポリシー定義を設定するポリシー定義設定方法にお
   いて、 前記ポリシーサーバは、予め作成された複数の中継装置
   を経由して通信装置を接続する通信パスを予約通信パス
   として予約しておき、前記予約通信パスに基づいて、フ
   ィルタ条件を除くポリシー定義を作成し、該作成したポ
   リシー定義を中継装置に対して予め配信し、その後通信
   装置からリソース予約リクエストを受付けた時に、フィ
   ルタ条件定義を作成して前記中継装置に配信することを
   特徴とするポリシー定義設定方法。
2. 【請求項２】 通信装置間のＩＰフローを転送する複数
   の中継装置を経由する論理的な通信経路である通信パス
   を定義する場合、どちらか一方の通信装置を基準として
   通信方向を決定し、上り通信と下り通信の通信経路を一
   組として前記通信パスの管理を行い、該通信パスに対応
   させたポリシー定義の作成および設定を行うことを特徴
   とする請求項１に記載のポリシー定義設定方法。
3. 【請求項３】 前記中継装置は、前記フィルタ条件を除
   くポリシー定義を設定した場合、その後前記ポリシー定
   義に対応したフィルタ条件が設定されるまでは、前記ポ
   リシー定義にしたがったＱｏＳ制御を無効にすることを
   特徴とする請求項１または２に記載のポリシー定義設定
   方法。
4. 【請求項４】 前記リソース予約リクエストを受信し、
   前記予約通信パスを割当てる場合、優先度と利用率の情
   報に基づき通信パスを決定することを特徴とする請求項
   １〜３の何れか一つに記載のポリシー定義設定方法。
5. 【請求項５】 ＱｏＳ制御の指示を行うポリシー定義を
   作成し、作成したポリシー定義を中継装置に配信するポ
   リシーサーバと、前記ポリシーサーバから配信されたポ
   リシー定義に基づいた通信品質でＩＰフローを転送して
   ＩＰフローの経路選択を行う中継装置と、前記中継装置
   を介してＩＰフローの送受信が可能な通信装置とを備え
   るネットワークに適用され、前記通信装置からオンデマ
   ンドに入力されたリソース予約リクエストで指定された
   通信品質の通信経路を確保するべく通信経路上の中継装
   置にポリシー定義を設定するポリシーサーバにおいて、 予め作成された複数の中継装置を経由して通信装置を接
   続する通信パスを予約通信パスとして予約しておき、前
   記予約通信パスに基づいて、フィルタ条件を除くポリシ
   ー定義を作成し、該作成したポリシー定義を中継装置に
   対して予め配信し、その後通信装置からリソース予約リ
   クエストを受付けた時に、フィルタ条件定義を作成して
   前記中継装置に配信する手段、 を備えることを特徴とするポリシーサーバ。
6. 【請求項６】 通信装置間のＩＰフローを転送する複数
   の中継装置を経由する論理的な通信経路である通信パス
   を定義する場合、どちらか一方の通信装置を基準として
   通信方向を決定し、上り通信と下り通信の通信経路を一
   組として前記通信パスの管理を行い、該通信パスに対応
   させたポリシー定義の作成および設定を行うことを特徴
   とする請求項５に記載のポリシーサーバ。
7. 【請求項７】 前記リソース予約リクエストを受信し、
   前記予約通信パスを割当てる場合、優先度と利用率の情
   報に基づき通信パスを決定することを特徴とする請求項
   ５または６に記載のポリシーサーバ。