JP3993445B2 - ネットワークポリシー制御システムおよびこれに用いるポリシーサーバ - Google Patents
ネットワークポリシー制御システムおよびこれに用いるポリシーサーバ Download PDFInfo
- Publication number
- JP3993445B2 JP3993445B2 JP2002059404A JP2002059404A JP3993445B2 JP 3993445 B2 JP3993445 B2 JP 3993445B2 JP 2002059404 A JP2002059404 A JP 2002059404A JP 2002059404 A JP2002059404 A JP 2002059404A JP 3993445 B2 JP3993445 B2 JP 3993445B2
- Authority
- JP
- Japan
- Prior art keywords
- stream
- communication path
- virtual communication
- call control
- vpn
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ラベルスイッチングルータを備えたＩＰネットワークにおけるセッションストリームの通信品質を保証することが可能なネットワークポリシー制御システムおよびこれに用いるポリシーサーバに関するものである。
【０００２】
【従来の技術】
従来のＩＰ（Internet Protocol）ネットワークにおけるＶｏＩＰ（Voice over Internet Protocol）を使用した通信のＱｏＳ（Quality of Service）保証方法に関する従来技術として、特開２００１−２７４８３３号公報に開示されているＶｏＩＰ用通信品質保証パス設定方法とネットワーク管理システムがある。この従来技術に開示されているＶｏＩＰ用通信品質保証パス設定方法では、ＭＰＬＳ（Multi Protocol Label Switching）／ＩＰネットワーク上で、ＶｏＩＰストリームのためのＱｏＳを保証することを目的としている。
【０００３】
図４４は、この従来技術に開示されているＩＰネットワーク１１７おいて、ＭＰＬＳによりパケット転送を行い、ＱｏＳを保証するシステムの構成図である。この図４４に示されるシステムでは、呼制御装置１０１と、エッジラベルスイッチングルータ（図４４中では、ＥｄｇｅＬＳＲと表記）１１２、１１５と、メディアゲートウェイ（同じく、ＭＧと表記）１１３、１１４と、ラベルスイッチング方式のＭＰＬＳサーバ１２０と、コアラベルスイッチングルータ（同じく、ＣｏｒｅＬＳＲと表記）１２３〜１２７とから構成されている。ここで、エッジラベルスイッチングルータ１１２、１１５はそれぞれ電話機１２８、１２９を収容するメディアゲートウェイ１１３、１１４を収容している。また、呼制御装置１０１は電話機間の呼を制御する装置である。なお、以下では、ラベルスイッチングルータ（Label Switching Router）をＬＳＲと表記する。
【０００４】
電話機１２８が電話機１２９に対して発呼する場合には、呼制御装置１０１を介してセッションが確立される。一方、電話機１２８から電話機１２９の音声データは、メディアゲートウェイ１１３、１１４で音声データとＶｏＩＰストリームとの間の変換がなされ、メディアゲートウェイ１１３とメディアゲートウェイ１１４との間のＩＰネットワーク１１７上では、ＶｏＩＰストリームが転送される。
【０００５】
つぎに、このシステムにおけるＶｏＩＰストリームのＱｏＳ保証について説明する。まず、電話機１２８が電話機１２９に対して発呼し、メディアゲートウェイ１１３とメディアゲートウェイ１１４との間にＶｏＩＰコネクションを確立する際に、ＱｏＳ保証が必要な場合に限り呼制御装置１０１は、ＭＰＬＳサーバ１２０に対してＶｏＩＰストリームを転送するためのリソース予約を要求する。ＭＰＬＳサーバ１２０は、もし、既にエッジＬＳＲ１１２とエッジＬＳＲ１１５との間にそのＶｏＩＰストリームを収容可能なＱｏＳ保証されたラベルスイッチパス（Label Switched Path、以下、ＬＳＰと表記する）が設定されている場合には、ＶｏＩＰストリームを該ＬＳＰに流すためのフィルタ条件をエッジＬＳＲ１１２およびエッジＬＳＲ１１５に対して設定する。また、もし、そのＶｏＩＰストリームを収容するにはそのＱｏＳ保証されたＬＳＰのリソースが不十分であるか、またはＱｏＳ保証されたＬＳＰがエッジＬＳＲ１１２とエッジＬＳＲ１１５との間に設定されていない場合には、エッジＬＳＲ１１２およびエッジＬＳＲ１１５に対してＱｏＳ保証されたＬＳＰを設定するように指示し、この設定したＬＳＰにＶｏＩＰストリームを収容し、ＱｏＳ保証を行っている。
【０００６】
【発明が解決しようとする課題】
しかしながら、上述した従来技術では、エッジＬＳＲ１１２、１１５がＶｏＩＰストリームを受信した時に、それをどのＱｏＳを提供するＬＳＰに転送すれば良いのかについて自律的に判断することができず、ＭＰＬＳサーバ１２０からの設定を必要としていた。つまり、電話機１２８、１２９間で発呼が行われるときに、すなわちセッション確立時に、ＭＰＬＳサーバ１２０からエッジＬＳＲ１１２、１１５に対してその電話機１２８、１２９間のＶｏＩＰストリームを流すためのＱｏＳを含めたＬＳＰの設定、すなわち、受信したパケットをどのＬＳＰに転送するのかを定めたフィルタ条件の設定を行わなければならなかった。また、ＭＰＬＳサーバ１２０は、このフィルタ条件をＬＳＲに設定すると共に、ＬＳＰごとに残存リソース量を管理しなければならず、ＭＰＬＳサーバ１２０に過大な負荷が発生してしまうという問題点があった。
【０００７】
さらに、ＩＰネットワーク１１７が、複数のＶＰＮを収容する機能をもつネットワークである場合には、ＶＰＮ（Virtual Private Network）ごとのリソース管理を行うことができないという問題点があった。さらにまた、ネットワークが大規模になるにつれ、呼数が膨大することが予想されるが、従来のＶｏＩＰ用通信品質保証パス設定方法においては、セッション確立の度に呼制御装置１０１、ＭＰＬＳサーバ１２０およびエッジＬＳＲ１１２、１１５の間でシーケンスが発生するため、過大な負荷が発生してしまうという問題点があった。
【０００８】
この発明は上記に鑑みてなされたもので、エッジＬＳＲが異なるネットワーク内の二つの端末間で送信されるストリームを受信した時に、どのＬＳＰに転送すべきかを自立的に判断することが可能なネットワーク制御システムおよびこれに用いるポリシーサーバを得ることを第一の目的とする。
【０００９】
また、複数のＶＰＮを収容する機能を有するＩＰネットワークにおいて、複数のＶＰＮごとのリソース管理を行うことが可能なネットワーク制御システムおよびこれに用いるポリシーサーバを得ることを第二の目的とする。
【００１０】
さらに、呼数の増大に対しても呼制御装置に対する過大な負荷を抑制することが可能なネットワークポリシー制御システムおよびこれに用いるポリシーサーバを得ることを第三の目的とする。
【００１１】
【課題を解決するための手段】
上記目的を達成するため、この発明にかかるネットワークポリシー制御システムは、複数のＬＳＲを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムであって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ＬＳＲに設定するバーチャル通信パス設定手段と、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、を含むポリシーサーバをさらに備え、前記端末からのストリームを最初に受信した初段ＬＳＲは、前記ストリームのパケットに格納されている宛先アドレスおよびサービスクラスに適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００１２】
この発明によれば、複数のＬＳＲを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備え、前記端末からのストリームを最初に受信した初段ＬＳＲによって、前記ストリームのパケットに格納されている宛先アドレスおよびサービスクラスに適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送されるネットワークポリシー制御システムが提供される。ここで、ポリシーサーバのバーチャル通信パス定義手段によって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるバーチャル通信パスが定義される。また、バーチャル通信パス設定手段によって、該バーチャル通信パスが前記ＬＳＲに設定される。さらに、リソース予約手段によって、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの残存リソース量に前記ストリームのリソース量が収容可能であると判断された場合にはリソース予約が行われる。
【００１３】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースをさらに備え、前記呼制御装置は、前記二つの端末間のセッション確立要求／応答を受信すると、前記利用者情報から取得した前記セッションのストリームに適用するサービスクラスと回線リソース量を取得して前記リソース予約要求を作成し、前記ポリシーサーバに送信するリソース予約要求手段を備えることを特徴とする。
【００１４】
この発明によれば、利用者情報データベースに、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報が格納される。また、前記呼制御装置のリソース予約要求手段によって、前記二つの端末間のセッション確立要求／応答が受信されると、前記利用者情報から取得した前記セッションのストリームに適用するサービスクラスと回線リソース量を取得して前記リソース予約要求が作成され、前記ポリシーサーバに送信される。
【００１５】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記リソース予約手段は、前記バーチャル通信パスの残存リソース量に前記ストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行い、前記ストリームのサービスクラスおよび回線リソース量を前記バーチャル通信パスに確保する機能をさらに備えることを特徴とする。
【００１６】
この発明によれば、前記リソース予約手段によって、前記バーチャル通信パスの残存リソース量に前記ストリームの回線リソース量を収容できないと判断された場合には、前記バーチャル通信パスに回線リソース量の追加が行われ、前記ストリームのサービスクラスおよび回線リソース量が前記バーチャル通信パスに確保される。
【００１７】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記サービスクラスは、前記ストリームが前記ＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスをさらに含むことを特徴とする。
【００１８】
この発明によれば、前記サービスクラスに、前記ストリームが前記ＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスが含まれる。
【００１９】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記回線リソース量は、保証される回線リソースの量によってクラス付けされた回線リソース量クラスによって定義されており、前記リソース予約手段は、前記回線リソース量クラスに対応するリソース量に比べて残存リソース量が十分に大きいＬＳＰを、前記選択したバーチャル通信パスの中から選択する機能を備えることを特徴とする。
【００２０】
この発明によれば、前記回線リソース量は、保証される回線リソースの量によってクラス付けされた回線リソース量クラスによって定義される。また、前記リソース予約手段によって、前記回線リソース量クラスに対応するリソース量に比べて残存リソース量が十分に大きいＬＳＰが、前記選択したバーチャル通信パスの中から選択される。
【００２３】
つぎの発明にかかるネットワークポリシー制御システムは、複数のＬＳＲを備えるＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末におけるセッションの確立および送信されるストリームのポリシー制御を行うネットワークポリシー制御システムであって、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して格納する利用者情報データベースと、前記二つの端末間のＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記ＶＰＮ識別子に対応したセッションに送信するストリームに適用するサービスクラスと回線リソース量を前記利用者情報データベースから取得して前記リソース予約要求を作成し、ポリシーサーバに送信するリソース予約要求手段を備える呼制御装置と、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ＬＳＲに設定するバーチャル通信パス設定手段と、前記二つの端末間のセッションの確立時における前記呼制御装置からのリソース予約要求に対して、該セッションに送信されるストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、を含むポリシーサーバと、を備え、前記端末からのストリームを最初に受信した初段ＬＳＲは、前記ストリームのパケットに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子に適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００２４】
この発明によれば、利用者情報データベースと、呼制御装置と、ポリシーサーバとを備え、複数のＬＳＲを備えるＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末におけるセッションの確立および送信されるストリームのポリシー制御が行われるネットワークシステムにおいて、前記端末からのストリームを最初に受信した初段ＬＳＲによって、前記ストリームのパケットに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子に適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送される。ここで、利用者情報データベースには、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報がＶＰＮごとにＶＰＮ識別子を付して格納されている。また、呼制御装置にはリソース予約要求手段が備えられ、このリソース予約要求手段によって、前記二つの端末間のＶＰＮ識別子を含むセッション確立要求／応答が受信されると、前記ＶＰＮ識別子に対応したセッションに送信するストリームに適用するサービスクラスと回線リソース量が前記利用者情報データベースから取得され、前記リソース予約要求が作成され、そしてポリシーサーバに送信される。さらに、ポリシーサーバにはバーチャル通信パス定義手段と、バーチャル通信パス設定手段と、リソース予約手段とが備えられている。バーチャル通信パス設定手段によって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義される。バーチャル通信パス設定手段によって、定義されたバーチャル通信パスが前記ＬＳＲに設定される。リソース予約手段によって、前記二つの端末間のセッションの確立時における前記呼制御装置からのリソース予約要求に対して、該セッションに送信されるストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断された場合にはリソース予約が行われる。そして、前記端末からのストリームを最初に受信した初段ＬＳＲによって、前記ストリームのパケットに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子に適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送される。
【００２５】
つぎの発明にかかるネットワークポリシー制御システムは、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、前記異なるネットワークに存在する二つの端末間のセッションの確立を行う呼制御装置と、前記二つの端末間のストリームの送信制御を行う呼制御装置およびポリシーサーバとを備えるネットワークポリシー制御システムであって、前記ＶＰＮ内呼制御装置は、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子を取得し、前記セッション確立要求／応答に添付して転送する手段を備え、前記呼制御装置は、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答を受信すると、前記ストリームのリソース予約要求を前記ポリシーサーバに対して送信するリソース予約要求手段を備え、前記ポリシーサーバは、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ＬＳＲに設定するバーチャル通信パス設定手段と、前記ＶＰＮ内呼制御装置からの前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約を行うリソース予約手段と、を備え、前記端末を収容する初段ＬＳＲは、前記端末からのストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００２６】
この発明によれば、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、前記異なるネットワークに存在する二つの端末間のセッションの確立を行う呼制御装置と、前記二つの端末間のストリームの送信制御を行う呼制御装置およびポリシーサーバとを備えるネットワークポリシー制御システムにおいて、前記端末を収容する初段ＬＳＲによって、前記端末からのストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送される。ここで、前記ＶＰＮ内呼制御装置によって、該ＶＰＮ内呼制御装置と収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答が受信されると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子が取得され、前記セッション確立要求／応答に添付して転送される。また、前記呼制御装置はリソース予約要求手段を備え、このリソース予約要求手段によって、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答が受信されると、前記ストリームのリソース予約要求が前記ポリシーサーバに対して送信される。さらに、前記ポリシーサーバは、バーチャル通信パス定義手段と、バーチャル通信パス設定手段と、リソース予約手段とを備えている。バーチャル通信パス定義手段によって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義される。バーチャル通信パス設定手段によって、該バーチャル通信パスが前記ＬＳＲに設定される。そして、リソース予約手段によって、前記ＶＰＮ内呼制御装置からの前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断された場合には、リソース予約が行われる。
【００２９】
つぎの発明にかかるネットワークポリシー制御システムは、複数のＬＳＲを備えるＩＰコアネットワークと、前記異なるＬＳＲに収容される二つの端末と、該二つの端末からのセッション確立要求／応答を前記ＩＰコアネットワーク内で最初に転送処理を行う副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバと、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースとを備えるネットワークポリシー制御システムであって、前記副呼制御装置は、セッション確立要求／応答を受信すると、もう一方の副呼制御装置に収容されている端末を送信先とするストリームに適用するサービスクラス／回線リソース量を前記利用者情報データベースから取得して、該セッション確立要求／応答に添付して転送する手段と、該副呼制御装置に関連付けされている前記副ポリシーサーバに対して、前記ストリームのリソース予約要求を送信する手段と、を備え、前記副ポリシーサーバは、該副ポリシーサーバに関連付けされている前記副呼制御装置から前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスを選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約を行うリソース予約手段を備え、一方の端末を送信先とするストリームのリソース予約処理が、前記ストリームの送信元側の端末に収容された副呼制御装置および副ポリシーサーバによって行われることを特徴とする。
【００３０】
この発明によれば、複数のＬＳＲを備えるＩＰコアネットワークと、前記異なるＬＳＲに収容される二つの端末と、該二つの端末からのセッション確立要求／応答を前記ＩＰコアネットワーク内で最初に転送処理を行う副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバと、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースとを備えるネットワークポリシー制御システムにおいて、一方の端末を送信先とするストリームのリソース予約処理が、前記ストリームの送信元側の端末に収容された副呼制御装置および副ポリシーサーバによって行われる。ここで、前記副呼制御装置は、セッション確立要求／応答を受信すると、もう一方の副呼制御装置に収容されている端末を送信先とするストリームに適用するサービスクラス／回線リソース量を前記利用者情報データベースから取得して、該セッション確立要求／応答に添付して転送する手段と、該副呼制御装置に関連付けされている前記副ポリシーサーバに対して、前記ストリームのリソース予約要求を送信する手段とを備える。また、前記副ポリシーサーバはリソース予約手段を備え、このリソース予約手段によって、該副ポリシーサーバに関連付けされている前記副呼制御装置から前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスが選択され、該選択されたバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約が行われる。
【００３１】
つぎの発明にかかるネットワークポリシー制御システムは、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、該ＶＰＮ内呼制御装置に収容される副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバとを備えるネットワークポリシー制御システムであって、前記ＶＰＮ内呼制御装置は、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子を取得し、前記セッション確立要求／応答に添付して転送する手段を備え、前記副呼制御装置は、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答を受信すると、前記ストリームのリソース予約要求を該副呼制御装置に関連付けされている前記副ポリシーサーバに対して送信するリソース予約要求手段を備え、前記副ポリシーサーバは、前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスを選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段を備え、前記端末を収容する前記ＬＳＲは、前記端末からの前記ストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００３２】
この発明によれば、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、該ＶＰＮ内呼制御装置に収容される副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバとを備えるネットワークポリシー制御システムにおいて、前記端末を収容する前記ＬＳＲによって、前記端末からの前記ストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスが決定され、該決定されたバーチャル通信パスにしたがって前記ストリームが転送される。ここで、前記ＶＰＮ内呼制御装置によって、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答が受信されると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子が取得され、前記セッション確立要求／応答に添付して転送される。また、前記副呼制御装置はリソース予約要求手段を備え、このリソース予約要求手段によって、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答が受信されると、前記ストリームのリソース予約要求が該副呼制御装置に関連付けされている前記副ポリシーサーバに対して送信される。さらに、前記副ポリシーサーバはリソース予約手段を備え、このリソース予約手段によって、前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスが選択され、該選択されたバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約が行われる。
【００３３】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記ネットワークポリシー制御システム内の前記副呼制御装置をまとめて管理する呼制御装置と、前記副ポリシーサーバをまとめて管理するポリシーサーバとを、さらに備えることを特徴とする。
【００３４】
この発明によれば、呼制御装置によって、前記ネットワークポリシー制御システム内の前記副呼制御装置がまとめて管理され、ポリシーサーバによって、前記副ポリシーサーバがまとめて管理される。
【００３５】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記副ポリシーサーバは、複数の副呼制御装置と関連付けすることが可能なことを特徴とする。
【００３６】
この発明によれば、前記副ポリシーサーバによって、複数の副呼制御装置が関連付けされる。
【００３７】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記副呼制御装置と前記副ポリシーサーバとを同一の装置内に備えることを特徴とする。
【００３８】
この発明によれば、前記副呼制御装置と前記副ポリシーサーバとが同一の装置内に備えられる。
【００３９】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記副呼制御装置と前記副ポリシーサーバとを同一の前記ＬＳＲ内に備えることを特徴とする。
【００４０】
この発明によれば、前記副呼制御装置と前記副ポリシーサーバとが同一の前記ＬＳＲ内に備えられる。
【００４１】
つぎの発明にかかるポリシーサーバは、複数のラベルスイッチングルータを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムに用いるポリシーサーバにおいて、前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ラベルスイッチングルータに設定するバーチャル通信パス設定手段と、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、を備えることを特徴とする。
【００４２】
この発明によれば、バーチャル通信パス定義手段と、バーチャル通信パス設定手段と、リソース予約手段とを備えるポリシーサーバであって、複数のラベルスイッチングルータを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムに用いられるポリシーサーバが提供される。まず、バーチャル通信パス定義手段によって、前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるバーチャル通信パスが定義される。つぎに、バーチャル通信パス設定手段によって、該バーチャル通信パスが前記ラベルスイッチングルータに設定される。そして、リソース予約手段によって、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約が行われる。
【００４３】
つぎの発明にかかるポリシーサーバは、上記の発明において、前記バーチャル通信パス定義手段が、前記バーチャル通信パスにさらにＶＰＮごとの回線リソース量を定める機能を備えることを特徴とする。
【００４４】
この発明によれば、前記バーチャル通信パス定義手段によって、前記バーチャル通信パスにさらにＶＰＮごとの回線リソース量がさらに定められる。
【００４７】
【発明の実施の形態】
以下に、添付図面を参照して、この発明にかかるネットワークポリシー制御システムおよびこれに用いるポリシーサーバの好適な実施の形態について詳細に説明する。
【００４８】
実施の形態１．
図１は、この発明にかかるネットワークポリシー制御システムの実施の形態１を示す構成図である。このネットワークシステムは、呼制御装置（図１中では、ＣＡと表記）１と、ポリシーサーバ（同じく、ＰＳと表記）２と、利用者情報データベース（同じく、ＵＤＢと表記）３と、ＩＰコアネットワーク４内で音声ストリームのＭＰＬＳ（Multi Protocol Label Switching）によるルーティング処理を行うＬＳＲ４１〜４６と、ＬＳＲ４１に収容されるゲートウェイ装置（同じく、ＧＷと表記）５と、ＬＳＲ４４に収容されるゲートウェイ装置６と、ＬＳＲ４１に収容されるアクセスネットワーク７と、ＬＳＲ４４に収容されるアクセスネットワーク８と、アクセスネットワーク７に存在する端末９と、アクセスネットワーク８に存在する端末１０とを有している。
【００４９】
この実施の形態１にかかるネットワークポリシー制御システムにおいては、従来技術と同様に、ＬＳＰには複数のセッションストリーム（確立されたセッション上で転送されるパケット群のこと）を収容することができる。また、端末９、１０間のセッションを確立／制御するためのプロトコルとしては、セッションを確立する際に、発呼側が要求（以下、セッション確立要求という）を発行し、着呼側がそれに対して応答（以下、セッション確立応答という）を返す構成を有するＳＩＰ（Session Initiation Protocol）、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication sector）によって勧告されたＨ３２３、またはＳＳ７（Signaling System 7）のようなプロトコルを使用することができる。
【００５０】
つぎに、図１のネットワークシステムにおけるＬＳＲへのバーチャル通信パスを設定する処理手順について、図２のフローチャートを参照しながら説明する。まず、ネットワーク管理者によって、ポリシーサーバ２上で、ネットワーク利用者のサービスグレードを示す利用者情報が定義され（ステップＳ１）、該利用者情報が図３に示される利用者情報データベース３に保存される（ステップＳ２）。この利用者情報には、フロー識別情報（端末アドレス／アドレスマスク、トランスポートプロトコル種別、符号化手法等）、および該フローに適用するサービスグレードを示すＣｏＳ（Class of Service、サービスクラス）、必要回線リソース量が定義されている。
【００５１】
また、ポリシーサーバ２上で、初段ＬＳＲ、最終段ＬＳＲ、これらの初段ＬＳＲと最終段ＬＳＲとの間で必要な回線リソース量、およびＣｏＳを含むバーチャル通信パス情報が、ネットワーク管理者によって定義される（ステップＳ３）。この発明では、バーチャル通信パス情報から特定されるパスをバーチャル通信パスと呼ぶ。すなわち、バーチャル通信パスは［初段ＬＳＲ、最終段ＬＳＲ、ＣｏＳ］の組み合わせによって一意的に識別される。
【００５２】
ポリシーサーバ２はこれらの利用者情報とバーチャル通信情報からなる入力情報を記憶し、バーチャル通信パス情報から、実際にネットワークに設定する複数または単一のＬＳＰを決定する（ステップＳ４）。例えば、図１中で、バーチャル通信パスの初段ＬＳＲがＬＳＲ４１、最終段ＬＳＲがＬＳＲ４４と入力された場合には、「ＬＳＲ４１−ＬＳＲ４２−ＬＳＲ４３−ＬＳＲ４４」と、「ＬＳＲ４１−ＬＳＲ４６−ＬＳＲ４５−ＬＳＲ４４」という２つの経路のＬＳＰが、バーチャル通信パスの構成要素となることが考えられる。そして、ポリシーサーバ２は、これらのＬＳＰの中から、ネットワークトポロジデータベース（ＴＤＢ）を参照して最適なＬＳＰのセットを決定する機能を有している。なお、バーチャル通信パスを構成するこれらＬＳＰの回線リソース量の合計は、バーチャル通信パスの回線リソース量に一致するように決定される。
【００５３】
図４は、属性情報を含むバーチャル通信パスの構成例を示す図である。ここで、バーチャル通信パス識別子（ＶＩＤ）は、バーチャル通信パスを一意的に識別する識別子であり、ＬＳＰ識別子（ＬＳＰＩＤ）は、バーチャル通信パスに所属するＬＳＰを一意的に識別する識別子である。また、宛先アドレス／アドレスマスクはポリシーサーバ２がネットワークトポロジデータベースから取得するものであり、例えば、図１に示されるＬＳＲ４１を初段ＬＳＲとし、ＬＳＲ４４を最終段ＬＳＲとした場合のバーチャル通信パスの場合、宛先アドレス／アドレスマスクはアクセスネットワーク８の宛先アドレス／アドレスマスクとなる。以上で、ＬＳＲ４１〜４６へのＬＳＰの設定処理は終了する。
【００５４】
そして、ポリシーサーバ２は、ネットワーク管理者による操作にしたがって、これらのＬＳＰ群をＩＰコアネットワーク上の個々のＬＳＲ４１〜４６に設定する（ステップＳ５）。具体的には、ＬＳＰの初段ＬＳＲに対して、ＬＳＰに関する情報を通知し、ＩＥＴＦ（Internet Engineering Task Force）において検討されているＲＳＶＰ−ＴＥ（Resource ReSerVation Protocol for Traffic Engineering、ＲＦＣ（Request For Comments）３２０９）等のシグナリングプロトコルで設定するように要求する。この際、いずれかのバーチャル通信パスの初段ＬＳＲとなっているＬＳＲには、バーチャル通信パス識別子、リソース量、ＣｏＳ、宛先アドレス／アドレスマスク、およびＬＳＰ識別子を含むバーチャル通信パスの属性情報もあわせて設定される。
【００５５】
なお、ＬＳＰの設定において、初段ＬＳＲおよび最終段ＬＳＲとして設定された各ＬＳＰのＬＳＲ４１〜４６は、該ＬＳＰにおけるエッジＬＳＲとしての機能を有する。
【００５６】
つぎに、このシステムにおける発呼端末と着呼端末間のセッション確立からセッションストリームを送信するまでの手順について、図５〜図７のフローチャートを参照しながら説明する。ここでは、図１において、端末９が端末１０に対して発呼した場合を例に挙げて説明する。
【００５７】
まず、端末９はセッション確立要求を端末１０に対して送信する（ステップＳ１１）が、該セッション確立要求は端末１０へ送信される前に、呼制御装置１によって受信される（ステップＳ１２）。このセッション確立要求には、一般的に、セッションを一意的に識別するためのセッション識別子、発呼端末アドレス（端末９のアドレス）、着呼端末アドレス（端末１０のアドレス）、セッションストリームが使用するトランスポートプロトコル、トランスポートプロトコルのポート番号および符号化種別等が含まれる。なお、以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。
【００５８】
セッション確立要求を受信した呼制御装置１は、セッションの着呼端末１０から発呼端末９の方向のストリームについて、セッション確立要求の内容と利用者情報データベース３とを照合し、上記ストリームに適用するＣｏＳ／回線リソース量を取得する（ステップＳ１３）。例えば、着呼端末１０から発呼端末９の方向のストリームが図３に示される利用者情報データベース３の１番目のエントリに適合した場合には、呼制御装置１は転送優先度クラス＝１および廃棄優先度クラス＝２であるＣｏＳと、１０Ｍｂｐｓのリソース量を取得する。
【００５９】
そして、呼制御装置１は、セッション識別子、宛先端末アドレス、送信元端末アドレス、ＣｏＳおよびリソース量の情報を含むリソース予約要求をポリシーサーバ２に送信する（ステップＳ１４）。ここで、リソース予約要求に含まれる情報について説明すると、セッション識別子は、セッションを一意的に識別する識別子である。また、宛先端末アドレスは、リソース予約を行うストリームの宛先アドレスであり、この場合には、セッションの着呼端末１０から発呼端末９の方向のストリームに関するリソース予約であるので、宛先端末アドレスは発呼端末９のアドレスとなる。送信元端末は、リソース予約を行うストリームの送信元アドレスであり、この場合には、着呼端末１０のアドレスとなる。ＣｏＳは、利用者情報データベース３から取得したＣｏＳであり、リソース量は、同じく利用者情報データベース３から取得したリソース量である。
【００６０】
ポリシーサーバ２はリソース予約要求を受信する（ステップＳ３１）と、ネットワークトポロジデータベースから、上記リソース予約要求の送信元端末アドレス（すなわち、着呼端末１０のアドレス）を収容するＬＳＲ４４を導き出す（ステップＳ３２）。また、ポリシーサーバ２は、ＬＳＲ４４が初段ＬＳＲとなっているバーチャル通信パスの宛先アドレス／アドレスマスクおよびＣｏＳと、リソース予約要求に含まれる宛先端末アドレス（すなわち、発呼端末９のアドレス）およびＣｏＳとを照合し、一致するバーチャル通信パスを、上記セッションを収容するバーチャル通信パスとして決定する（ステップＳ３３）。
【００６１】
その後、ポリシーサーバ２は、合致するバーチャル通信パスに上記ストリームを収容することが可能であるかを判定する（ステップＳ３４）。すなわち、バーチャル通信パスの残存リソース量が十分で、上記ストリームで必要なリソース量を確保できる場合、または、バーチャル通信パスの残存リソース量は不十分であるが、バーチャル通信パス内のＬＳＰのリソース量の増加もしくは新規ＬＳＰの設定などの手段によって、リソース量の追加が可能である場合には、バーチャル通信パスに上記ストリームを収容可能であると判断する。ここで、バーチャル通信パス内のＬＳＰのリソース量を増加する設定や新規ＬＳＰの設定は、ＬＳＰの初段ＬＳＲに対して上述したシグナリングプロトコルによって行われる。
【００６２】
そして、ポリシーサーバ２は、バーチャル通信パスに上記ストリームが収容可能であると判断する（ステップＳ３４でＹｅｓの場合）と、そのバーチャル通信パスの残存リソース量から上記ストリームのリソース量を減算した該バーチャル通信パスの残存リソース量をバーチャル通信パスに関連付けて、セッション識別子と上記ストリームのリソース量と共に記憶する（ステップＳ３５）。その後、ポリシーサーバ２は、呼制御装置１にリソース予約応答（成功）を返送する（ステップＳ３６）。
【００６３】
一方、上述したステップＳ３４で、バーチャル通信パスに上記ストリームを収容不可能であるとポリシーサーバ２が判断する場合（ステップＳ３４でＮｏの場合）には、ポリシーサーバ２は呼制御装置１に対してリソース予約応答（失敗）を返送する（ステップＳ３７）。以上のステップＳ３１〜Ｓ３７で、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理が終了する。
【００６４】
呼制御装置１はポリシーサーバ２からリソース予約応答を受信する（ステップＳ１５）と、該リソース予約応答が成功か否かについて判断を行う（ステップＳ１６）。リソース予約応答が成功である場合（ステップＳ１６でＹｅｓの場合）には、上述したステップＳ１３で取得したＣｏＳ／回線リソース量をセッション確立要求に添付して、着呼端末１０へ転送する（ステップＳ１７）。
【００６５】
一方、リソース予約応答が失敗である場合（ステップＳ１６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された、発呼端末９にセッション確立応答失敗を通知するメッセージを送信するなどの失敗時のシーケンスを実行し（ステップＳ１９）、処理が終了する。
【００６６】
着呼端末１０は、呼制御装置１からセッション確立要求を受信する（ステップＳ１８）と、セッション確立要求に必要な変更を行ってセッション確立応答を作成し、該セッション確立応答を発呼端末９に対して、呼制御装置１経由で送信する（ステップＳ２０）。呼制御装置１は着呼端末１０からのセッション確立応答を受信すると（ステップＳ２１）、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームに適用するＣｏＳ／回線リソース量を利用者情報データベースから取得する（ステップＳ２２）。なお、このステップＳ２２における着呼端末１０から発呼端末９の方向のストリームのリソース予約確認については、セッション確立要求時に既に行っているが、着呼端末１０でセッション情報のネゴシエーションがなされているために、セッション確立応答時にも必要となる。そして、上記ストリームについてのリソース予約要求をポリシーサーバ２へ送信する（ステップＳ２３）。
【００６７】
ポリシーサーバ２におけるセッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のストリームに対するリソース予約確認は、上述した図７のステップＳ３１〜Ｓ３７と同様の処理によってなされる。すなわち、ポリシーサーバ２は、上記ストリームを収容するバーチャル通信パスを求め、該バーチャル通信パスに上記ストリームを収容することができる場合にはリソース予約応答（成功）を、収容できない場合にはリソース予約応答（失敗）を呼制御装置１に対して送信する。
【００６８】
その後、呼制御装置１がポリシーサーバ２からリソース予約応答を受信する（ステップＳ２４）と、呼制御装置１は該リソース予約応答が成功であるか否かについて判断する（ステップＳ２５）。リソース予約応答が成功であると判断された場合（ステップＳ２５でＹｅｓの場合）には、このリソース予約処理の過程で取得したセッションの発呼端末９から着呼端末１０への方向のストリームに適用するＣｏＳ／回線リソース量を、セッション確立応答に添付して発呼端末９へ転送する（ステップＳ２６）。
【００６９】
一方、リソース予約応答が失敗である場合（ステップＳ２５でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行し（ステップＳ２８）、処理が終了する。失敗時のシーケンスとして、例えば、呼制御装置１が着呼端末１０にセッション確立キャンセルメッセージを送信すると、着呼端末１０はこのメッセージに対して呼制御装置１に成功／失敗を通知し、そして、呼制御装置１は、発呼端末９に対してセッション確立応答失敗を通知するメッセージを送信する処理などが行われる。
【００７０】
発呼端末９はＣｏＳ／回線リソース量を添付したセッション確立応答を受信する（ステップＳ２７）と、発呼端末９と着呼端末１０との間にセッションが確立されたものと認識し、発呼端末９と着呼端末１０との間のセッション確立処理が終了する。
【００７１】
その後、発呼端末９は、発呼端末９と着呼端末１０との間にセッションが確立されたものと認識した後に、該セッションに着呼端末１０へストリームの送信を開始する。この際、ストリームを、セッション確立応答に含まれていたリソース量以下で転送し、ストリームを構成するパケットにはセッション確立応答に含まれていたＣｏＳを付加して転送する。このＣｏＳを設定するパケットのフィールドは、ＩＰｖ４ではＴｏＳフィールドに該当し、ＩＰｖ６ではＦｌｏｗＬａｂｅｌフィールドに該当する。
【００７２】
ＬＳＲ４１は、ゲートウェイ装置５を介して、発呼端末９からのストリームを構成するパケットを受信すると、自身に設定されているバーチャル通信パスの宛先アドレス／アドレスマスクおよびＣｏＳと、ストリームを構成するパケットの宛先アドレスおよびＣｏＳとを照合し、該ストリームを転送するためのバーチャル通信パスを決定する。このＬＳＲ４１が決定したバーチャル通信パスは、上述した図７のステップＳ３３でポリシーサーバ２が決定したバーチャル通信パスと一致するものである。
【００７３】
そして、ストリームのパケットを受信した初段ＬＳＲ４１は、セッションの確立時にリソースが確保されたバーチャル通信パスに該ストリームのパケットを転送する。ここで、バーチャル通信パスを構成するＬＳＰが単一である場合には、そのＬＳＰにストリームを転送する。また、バーチャル通信パスを構成するＬＳＰが複数である場合には、各ＬＳＰのリソース量を超えないように考慮してストリームを各ＬＳＰにスケジューリングしながら転送する。
【００７４】
一方、着呼端末１０は、上述したステップＳ１８でセッション確立要求を受信した段階において、発呼端末９と着呼端末１０との間にセッションが確立されたものと認識する。そして、上述した発呼端末９におけるストリームの送信手順と同様の処理方法によってストリームを構成するパケットの送信を開始する。
【００７５】
ストリームを構成するパケットを、ゲートウェイ装置６を介して、着呼端末１０から受信したＬＳＲ４４は上述したＬＳＲ４１と同様の転送処理方法によって、該ストリームを、バーチャル通信パスを構成するＬＳＰに転送する。このようにして、発呼端末９と着呼端末１０との間でストリームの送信が実現される。
【００７６】
上述したように、この実施の形態１によれば、初段ＬＳＲ、最終段ＬＳＲおよびＣｏＳが同じＬＳＰの集合をバーチャル通信パスと定義し、ポリシーサーバ２によってセッションに対するリソース予約がなされたバーチャル通信パスと、初段ＬＳＲ４１、４４によってストリームの宛先アドレスとＣｏＳとから求められたバーチャル通信パスとは必然的に一致するので、端末９、１０間のセッション確立ごとにポリシーサーバ２はエッジＬＳＲに対して逐一設定を行う必要がないという効果を奏する。また、エッジＬＳＲにおいて、ストリームのパケットごとに、該ストリームの転送を行うか否かを決めるフィルタリング処理が不用になり、エッジＬＳＲの負荷が軽減される。
【００７７】
実施の形態２．
つぎに、図８〜図１０を用いてこの発明の実施の形態２について説明する。この実施の形態２は、上述した実施の形態１において、ネットワーク管理者がＣｏＳを定義する際に、ＩＰコアネットワーク４にストリームが入力されてから出力されるまでにかかる遅延時間をクラス分けしてなる遅延クラスをさらに定義するものである。
【００７８】
図８は、遅延クラスのクラス分けの例を示す図であり、図９は、ＣｏＳに遅延クラスをさらに含めた利用者情報データベース３の構成例を示す図であり、そして図１０は、ＣｏＳに遅延クラスをさらに含めたバーチャル通信パスの構成例を示す図である。
【００７９】
図８の例では、遅延クラスは、最大遅延時間と最小遅延時間との組み合わせによって、１〜４の４段階にクラス分けされている。遅延クラス１は、最大遅延時間が１００ｍｓであり、最小遅延時間は０であり、最も遅延が許されない端末に対して設定される。また、遅延クラス２は、１００ｍｓ〜４００ｍｓの遅延時間であり、遅延クラス３は、４００ｍｓ〜１０００ｍｓの遅延時間であり、そして遅延クラス４は、１０００ｍｓ以上の遅延時間である。
【００８０】
図９に示される利用者情報データベース３は、図３に示される利用者情報データベース３のＣｏＳにおいて、さらに遅延クラスが付加されている。この遅延クラスは、図８に示される遅延クラスによって最大遅延時間と最小遅延時間が定義されている。
【００８１】
また、図１０に示されるバーチャル通信パスは、図４に示されるバーチャル通信パスのＣｏＳにおいて、さらに遅延クラスを属性として定義可能な構成としている。この遅延クラスも、図８に示される遅延クラスによって最大遅延時間と最小遅延時間が定義されている。この遅延クラスは、バーチャル通信パスを構成するＬＳＰの経路を決定する際に使用される。具体的には、ＬＳＰの遅延時間が遅延クラスに定義された最小遅延時間以上で最大遅延時間以下と計算される場合に、該ＬＳＰがバーチャル通信パスを構成するＬＳＰの経路として決定される。なお、遅延時間の計算方法としては、ポリシーサーバ２、エッジＬＳＲ４１、４４が、回線、ＬＳＲの遅延時間を含むネットワークトポロジデータベースから算出することによって行われる。
【００８２】
なお、ＣｏＳに遅延クラスが付加された場合も、実施の形態１の図２および図５〜図７で説明した手順によってセッション確立処理およびポリシー制御処理が行われる。
【００８３】
この実施の形態２によれば、ＩＰコアネットワーク４において遅延時間も考慮した利用者のサービスグレード付けが可能となる。
【００８４】
実施の形態３．
つぎに、図１１〜図１３を用いてこの発明の実施の形態３について説明する。この実施の形態３は、上述した実施の形態２で、ネットワーク管理者がＣｏＳを定義する際、ＩＰコアネットワーク４で保証されるリソース量をさらにクラス分けした回線リソース量クラスを定義するものである。
【００８５】
図１１は、回線リソース量クラスのクラス分けの例を示す図であり、そして図１２は、ＣｏＳに回線リソース量クラスをさらに含めた利用者情報データベース３の構成例を示す図である。なお、この回線リソース量クラスは、バーチャル通信パスに対して属性定義するものではない。
【００８６】
図１１の例では、回線リソース量クラスは、最大帯域と最低保証帯域と最大バーストサイズとの組み合わせによって、１〜４の４段階にクラス分けされている。回線リソース量クラス１は、最大帯域が６４ｋｂｐｓであり、最低保証帯域は８ｋｂｐｓであり、最大バーストサイズは８ｋｂｙｔｅであり、回線リソース量としては最も低いクラスとなっている。回線リソース量クラスの段階が上がるにつれ、内容は高い保証を与えるものとなっており、回線リソース量クラス４は、最大帯域が１６Ｍｂｐｓであり、最低保証帯域が８Ｍｂｐｓであり、最大バーストサイズは８ｋｂｙｔｅであり、回線リソース量としては最も高いクラスとなっている。なお、この回線リソース量クラスとリソース量の対応表は、利用者情報データベース３と、エッジＬＳＲ４１〜４６に設定される。
【００８７】
図１２に示される利用者情報データベース３は、図９に示される利用者情報データベース３の「ＣｏＳ」フィールドにおいて、さらに回線リソース量クラスが付加され、「リソース量」フィールドが削除された構成となっている。この「ＣｏＳ」フィールドの回線リソース量クラスは、上述した図１１に示される回線リソース量クラスによって規定されている。
【００８８】
この実施の形態３における発呼端末９から着呼端末１０へのセッション確立およびポリシー制御の処理手順は、上述した実施の形態１で説明した図５〜図７に示される処理と同様にして行われるので、説明は省略する。ただし、発呼端末９からセッション確立要求を受信した呼制御装置１が、着呼端末１０から発呼端末９のストリームについてのリソース予約確認処理を行う図５のステップＳ１３において、実施の形態１では、呼制御装置１は、セッション確立要求の内容に適合する利用者情報データベース３内のエントリから直接にリソース量を取得していたが、この実施の形態３では、呼制御装置１は、セッション確立要求の内容と利用者情報データベース３とを照合し、利用者情報データベース３内の合致するエントリのＣｏＳフィールドに回線リソース量クラスが定義されている場合に、図１１に示されるような回線リソース量クラスとリソース量の対応表からリソース量を取得する点が異なる。図６のステップＳ２２における発呼端末９から着呼端末１０の方向および着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理も同様である。
【００８９】
発呼端末９および着呼端末１０からストリームが送信された後のＬＳＲのストリームパケットの転送処理について図１３のフローチャートを参照しながら説明する。
【００９０】
発呼端末９から着呼端末１０へのセッションが確立されると、上述した実施の形態１の場合と同じように、発呼端末９および着呼端末１０はストリームの送信を開始する。このとき、バーチャル通信パスの初段ＬＳＲとなっているＬＳＲ４１およびＬＳＲ４４は、ストリームを受信する（ステップＳ４１）と、該ＬＳＲ４１、４４自身に設定されているバーチャル通信パスの宛先アドレス／アドレスマスクおよび回線リソース量クラスを除いたＣｏＳと、上記ストリームを構成するパケットの宛先アドレスおよび回線リソース量クラスを除いたＣｏＳとを照合し（ステップＳ４２）、上記ストリームを転送するためのバーチャル通信パスを決定する（ステップＳ４３）。例えば、図１２に示される情報がＬＳＲに設定されている場合では、転送優先度クラス＝１、廃棄優先度クラス＝２、遅延クラス＝３のバーチャル通信パスが決定される。
【００９１】
そして、図１１に示したような回線リソース量クラスとリソース量の対応表とストリームに含まれるＣｏＳの回線リソース量クラスからリソース量を取得する（ステップＳ４４）。その後、取得したＣｏＳにしたがって、上記ストリームに対するＱｏＳ制御を行う（ステップＳ４５）。
【００９２】
例えば、上記ストリームの回線リソース量クラスとして３が設定されている場合には、ＬＳＲ４１、４４は、図１１からその最低保証帯域１Ｍｂｐｓに比べて十分に大きい残存帯域を有するＬＳＰを、検索されたバーチャル通信パスの中からストリームの転送先として設定する。その後、設定したＬＳＰの残存帯域から最低保証帯域（１Ｍｂｐｓ）を減算する。そして、上記ストリームに対して最大帯域８Ｍｂｐｓでシェーピングを行い、１Ｍｂｐｓの最低保証帯域と８ｋｂｙｔｅの最大バーストサイズを保証する。
【００９３】
その後、ストリームの転送が設定したＬＳＰの間で所定期間行われない場合には、上記したストリームに対する回線リソース量をＬＳＰに確保する設定を解除する。すなわち、ＬＳＰの残存帯域に、上記設定時に減算した最低保証帯域（１Ｍｂｐｓ）を加算する。
【００９４】
以上のように、この実施の形態３によれば、回線リソース量を最大帯域、最低保証帯域および最大バーストサイズの組み合わせによってクラス分けして、ＣｏＳに定義することによって、バーチャル通信パスのエッジＬＳＲにおいて、一層きめ細かなストリームのＱｏＳ制御が可能となる。
【００９５】
実施の形態４．
つぎに、図１４〜図１７を用いてこの発明の実施の形態４について説明する。この実施の形態４は、ＩＰコアネットワークが複数のＶＰＮを収容する機能を有し、しかもＶＰＮごとのリソース管理を行うことが可能なネットワークポリシー制御システムを提供するものである。
【００９６】
図１４は、この発明にかかるネットワークポリシー制御システムの実施の形態４を示す構成図である。このネットワークシステムは、呼制御装置（図１４中では、ＣＡと表記）１と、ポリシーサーバ（同じく、ＰＳと表記）２と、ＩＰコアネットワーク４内でセッションストリームのＭＰＬＳによるルーティング処理を行うＬＳＲ４１〜４６と、ＬＳＲ４１に収容されるゲートウェイ装置（同じく、ＧＷと表記）５−１〜５−ｎと、ＬＳＲ４４に収容されるゲートウェイ装置６−１〜６−ｎと、ＬＳＲ４１に収容されるアクセスネットワーク７−１〜７−ｎと、ＬＳＲ４４に収容されるアクセスネットワーク８−１〜８−ｎと、アクセスネットワーク７−１に存在する端末９と、アクセスネットワーク８−１に存在する端末１０とを有している。
【００９７】
つぎに、ＩＰコアネットワーク４を介したＶＰＮを用いた通信におけるＶＰＮごとのリソース管理の処理方法について説明する。
【００９８】
ネットワーク管理者は、ポリシーサーバ２上でＬＳＰを定義すると共に、定義したＬＳＰをＩＰコアネットワーク４上に存在するＬＳＲ４１〜４６に設定する。このときの設定において、必要回線リソース量と宛先ネットワークとをＶＰＮごとに定義する。
【００９９】
ここで、端末９が端末１０に対して発呼した場合のセッション確立およびポリシー制御の処理手順について図１５〜図１６のフローチャートを参照しながら説明する。
【０１００】
端末９は、まずセッション確立要求を端末１０へ送信する（ステップＳ５１）が、該セッション確立要求は端末１０へ送信される前に、呼制御装置１によって受信される（ステップＳ５２）。このとき、端末９自身に設定されているＶＰＮ−ＩＤが、セッション確立要求に付加されて送信される。なお、以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。
【０１０１】
セッション確立要求を受信した呼制御装置１は、セッションの着呼端末１０から発呼端末９の方向のストリームについて、リソース予約処理を行う（ステップＳ５３）。このリソース予約処理は、呼制御装置１がポリシーサーバ２に対して、セッション識別子、発呼端末アドレス、着呼端末アドレス、上記ストリームに必要な回線リソース量、およびＶＰＮ−ＩＤを含む、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を送信することによって行われる。
【０１０２】
ポリシーサーバ２はリソース予約要求を受信する（ステップＳ７１）と、上記ストリームを収容するＬＳＰの候補を決定し（ステップＳ７２）、そのＬＳＰに上記ストリームを収容可能であるかを、ＬＳＰのＶＰＮに割り当てられたリソース量と上記ストリームに必要なリソース量とを比較することによって判定する（ステップＳ７３）。上記ストリームを収容するのに十分なリソース量を有するＬＳＰが存在する場合（ステップＳ７３でＹｅｓの場合）には、このＬＳＰに上記ストリームを転送するように該ＬＳＰの初段ＬＳＲ４４に設定し（ステップＳ７４）、リソース予約応答（成功）を呼制御装置１に返送する（ステップＳ７５）。
【０１０３】
一方、ステップＳ７３で、上記ストリームを収容するのに十分なリソース量を有するＬＳＰが存在しない場合（ステップＳ７３でＮｏの場合）には、リソース予約応答（失敗）を呼制御装置１に返送する（ステップＳ７６）。以上のポリシーサーバ２によるステップＳ７１〜Ｓ７６の処理工程で、上述したストリームに対するリソース予約処理が完了する。
【０１０４】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ５４）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ５５）。リソース予約応答が成功である場合（ステップＳ５５でＹｅｓの場合）には、呼制御装置１は、セッション確立要求を着呼端末１０へ転送する（ステップＳ５６）。一方、リソース予約応答が失敗である場合（ステップＳ５５でＮｏの場合）には、呼制御装置１はセッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ５７）。
【０１０５】
着呼端末１０は、呼制御装置１からセッション確立要求を受信する（ステップＳ５８）と、セッション確立応答を発呼端末９に対して返送する（ステップＳ５９）。しかし、この場合にも、セッション確立応答は、発呼端末９に送信される前に呼制御装置１によって受信される（ステップＳ６０）。
【０１０６】
呼制御装置１はセッション確立応答を受信すると、このセッション確立応答に含まれる情報を基に、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームに関するリソース予約要求をポリシーサーバ２へ送信し、リソース予約処理を行う（ステップＳ６１）。ポリシーサーバ２では、上述した図１７のステップＳ７１〜Ｓ７６でのリソース予約処理が行われ、リソース予約応答が呼制御装置１に対して送信される。
【０１０７】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ６２）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ６３）。リソース予約応答が成功である場合（ステップＳ６３でＹｅｓの場合）には、セッション確立応答を発呼端末９に転送する（ステップＳ６４）。そして発呼端末９は、セッション確立応答を受信し、セッションの確立処理が終了する。一方、ステップＳ６３でリソース予約応答が失敗である場合（ステップＳ６３でＮｏの場合）には、呼制御装置１はセッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ６６）。
【０１０８】
発呼端末９はセッション確立応答を受信すると、そして着呼端末１０はセッション確立要求を受信すると、セッションストリームの送信をそれぞれ開始する。セッションストリームはＬＳＲ４１、４４において、設定された情報に基づきＬＳＰに転送される。
【０１０９】
以上説明してきたように、この実施の形態４によれば、ＩＰコアネットワーク４においてＶＰＮごとのリソース管理を行うことが可能となる。
【０１１０】
実施の形態５．
つぎに、図１８〜図２４を用いてこの発明の実施の形態５について説明する。この実施の形態５は、ＩＰコアネットワークが複数のＶＰＮを収容する機能を持ち、しかもＶＰＮごとのリソース管理を行うことが可能なネットワークポリシー制御システムを提供するものである。
【０１１１】
図１８は、この発明にかかるネットワークポリシー制御システムの実施の形態５を示す構成図である。このネットワークポリシー制御システムでは、上述した実施の形態４の図１４において、さらに、利用者情報データベース（図１８中では、ＵＤＢと表記）３がさらに付加されたものであり、その他の構成については図１４と同一であるので、その説明は省略する。
【０１１２】
つぎに、ＩＰコアネットワーク４におけるＶＰＮごとのリソース管理の処理方法について説明する。
【０１１３】
図１８のネットワークシステムにおけるＬＳＲのバーチャル通信パスを設定する処理手順について、図１９のフローチャートを参照しながら説明する。まず、ネットワーク管理者によって、ポリシーサーバ２上で、ＶＰＮごとに利用者情報が入力され（ステップＳ８１）、該利用者情報が図２０に示される利用者情報データベース３に、ＶＰＮごとに保存される（ステップＳ８２）。この利用者情報データベースに格納される利用者情報は、基本的には実施の形態１の図３に示した利用者情報データベース３の構成と同じであるが、この実施の形態５の利用者情報データベース３は、フロー識別情報、ＣｏＳおよび必要回線リソース量などの複数の情報が、ＶＰＮごとに定義されている点が異なる。
【０１１４】
その後、ポリシーサーバ２上で、ネットワーク管理者によって、初段ＬＳＲ、最終段ＬＳＲ、必要回線リソース量およびＣｏＳを含むバーチャル通信パス情報が定義される（ステップＳ８３）。このバーチャル通信パスの定義は、上述した実施の形態１におけるバーチャル通信パスの定義方法と基本的には同じであるが、リソース量と宛先アドレス／アドレスマスクをＶＰＮごとに定義する必要がある。ポリシーサーバ２はこのバーチャル通信パス情報を記憶し、バーチャル通信パス情報から、実際にネットワークに設定する複数または単一のＬＳＰを決定し（ステップＳ８４）、このＬＳＰ群をネットワーク上の個々のＬＳＲ４１〜４６に設定する。
【０１１５】
図２１は、属性情報を含むバーチャル通信パスの構成例を示す図である。このバーチャル通信パスの構成は実施の形態１の図４に示されるバーチャル通信パスの構成と基本的には同じであるので、同じ構成を有する部分についての説明は省略する。実施の形態１の図４に示されるバーチャル通信パスの構成と異なるのはリソース量と宛先アドレス／アドレスマスクであり、これらはＶＰＮごとに定義されるようになっている。
【０１１６】
つぎに、このシステムにおける発呼端末と着呼端末との間にＶＰＮを確立し、セッションストリームを転送する場合の処理手順について図２２〜図２４のフローチャートを参照しながら説明する。
【０１１７】
まず、端末９は、自身に設定されているＶＰＮ−ＩＤを付加したセッション確立要求を端末１０に対して送信する（ステップＳ９１）が、該セッション確立要求は端末１０へ送信される前に、呼制御装置１によって受信される（ステップＳ９２）。なお、以下の説明では、端末９を発呼端末といい、端末１０を着呼端末という。
【０１１８】
ＶＰＮ−ＩＤが付加されたセッション確立要求を受信した呼制御装置１は、セッションの着呼端末１０から発呼端末９の方向のストリームについて、セッション確立要求に含まれるＶＰＮ−ＩＤを取得し、セッション確立要求の内容と利用者情報データベース３のＶＰＮの欄とを照合し、上記ストリームに適用するＶＰＮのＣｏＳ／回線リソース量を取得する（ステップＳ９３）。そして呼制御装置１は、これらを、セッション確立要求に含まれていた発呼端末アドレス、着呼端末アドレスおよびセッションを一意に識別する識別子（以下、セッション識別子という）と合わせて、セッションの着呼端末１０から発呼端末９の方向のストリームに関するリソース予約要求としてポリシーサーバ２に対して送信する（ステップＳ９４）。
【０１１９】
ポリシーサーバ２は、リソース予約要求を受信する（ステップＳ１１１）と、実施の形態１の図７に示されるステップＳ３２〜Ｓ３３と同様の方法で、バーチャル通信パスを検索する（ステップＳ１１２〜Ｓ１１３）。その後、バーチャル通信パスにセッションを収容することが可能であるかを判定する（ステップＳ１１４）。すなわち、バーチャル通信パスのＶＰＮに割り当てられた残存リソース量が十分である場合、または、バーチャル通信パスのＶＰＮに割り当てられた残存リソース量が不十分であるが、バーチャル通信パス内のＬＳＰのリソース量増加もしくは新規ＬＳＰの設定の手段によって、リソース量の追加が可能である場合には、ポリシーサーバ２は、バーチャル通信パスに上記ストリームを収容可能であると判断する（ステップＳ１１４でＹｅｓの場合）。そして、ポリシーサーバ２は、該バーチャル通信パスのＶＰＮに割り当てられた残存リソース量からセッションに必要なリソース量を減算し、バーチャル通信パスに関連付けてセッション識別子とそのリソース量を記憶する（ステップＳ１１５）。その後、呼制御装置１にリソース予約応答（成功）を返送する（ステップＳ１１６）。一方、ステップＳ１１４でバーチャル通信パスのＶＰＮに割り当てられた残存リソース量にセッションを収容することが不可能であると判断された場合（ステップＳ１１４でＮｏの場合）には、ポリシーサーバ２は、呼制御装置１にリソース予約応答（失敗）を返送する（ステップＳ１１７）。以上のステップＳ１１１〜Ｓ１１７で、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理が完了する。
【０１２０】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ９５）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ９６）。リソース予約応答が成功である場合（ステップＳ９６でＹｅｓの場合）には、呼制御装置１は、上記のステップＳ９３で取得したＣｏＳ／回線リソース量をセッション確立要求に添付して、着呼端末１０へ転送する（ステップＳ９７）。一方、リソース予約応答が失敗である場合（ステップＳ９６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ９８）。
【０１２１】
着呼端末１０は、セッション確立要求を受信する（ステップＳ９９）と、自身に設定されているＶＰＮ−ＩＤを付加したセッション確立応答を発呼端末９へ送信する（ステップＳ１００）が、該セッション確立応答は発呼端末９に受信される前に呼制御装置１によって受信される（ステップＳ１０１）。
【０１２２】
呼制御装置１はセッション確立応答を受信すると、セッション確立応答中のＶＰＮ−ＩＤを取得し、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームに対して、ＶＰＮのＣｏＳ／回線リソース量を取得する（ステップＳ１０２）。そして、呼制御装置１は、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームについてのリソース予約要求をポリシーサーバ２へ送信し（ステップＳ１０３）、リソース予約確認処理を行う。ポリシーサーバ２によって行われるリソース予約確認処理は、上述した図２４のステップＳ１１１〜ステップＳ１１７での処理と同じであるので、説明を省略する。
【０１２３】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ１０４）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１０５）。リソース予約応答が成功である場合（ステップＳ１０５でＹｅｓの場合）には、呼制御装置１は、上記のステップＳ１０２で取得したセッションの発呼端末９から着呼端末１０の方向のストリームに適用するＣｏＳおよびリソース量を添付して発呼端末９へ転送し（ステップＳ１０６）、発呼端末９はセッション確立応答を受信する（ステップＳ１０７）。一方、リソース予約応答が失敗である場合（ステップＳ１０５でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１０８）。
【０１２４】
このとき、上述した実施の形態１の場合と同様に、発呼端末９はセッション確立応答を受信すると、着呼端末１０はセッション確立要求を受信すると、それぞれセッションストリームの送信を開始する。
【０１２５】
発呼端末９から着呼端末１０へ送信されるストリームの初段ＬＳＲであるＬＳＲ４１は、発呼端末９からのセッションストリームを受信すると、実施の形態１の場合と同様に、セッションストリームを転送するバーチャル通信パスを決定する。そして、セッションストリームの受信インタフェース番号からＶＰＮ−ＩＤのラベルを求め、セッションストリームを構成する各パケットに、該ＶＰＮ−ＩＤのラベルをセカンドラベルとして設定する。なお、トップラベルには、転送するＬＳＰのラベルが設定される。この転送するＬＳＰは、実施の形態１と同様の手法で決定され、セッションストリームがＶＰＮ−ＩＤで定められるＶＰＮを介して転送される。
【０１２６】
一方、着呼端末１０から発呼端末９へ送信されるストリームの初段ＬＳＲであるＬＳＲ４４も、着呼端末１０からのセッションストリームを受信すると、上記したＬＳＲ４１の場合と同様の手順によって、セッションストリームがＬＳＰに転送される。
【０１２７】
以上のように、この実施の形態５によれば、端末９、１０間で確立されるセッションに対してサービスクラスのグレード付けを行ったバーチャル通信パス情報がポリシーサーバ２とともにＬＳＲ４１〜４６に設定されるので、セッション確立時のバーチャル通信パスに対するリソース予約はポリシーサーバ２が行い、セッションストリームの転送はバーチャル通信パスにしたがってＬＳＲ４１〜４６が自律的に行うように構成される。その結果、ポリシーサーバ２がセッション確立時にエッジＬＳＲ４１、４４に逐一設定を行う必要がなくなるので、ポリシーサーバ２の負荷を軽減することが可能となる。また、ＩＰコアネットワーク４においてＶＰＮごとのリソース管理を行うことが可能となる。
【０１２８】
実施の形態６．
つぎに、図２５〜図２８を用いてこの発明の実施の形態６について説明する。この実施の形態６は、アクセスネットワーク７−１〜７−ｎ、８−１〜８−ｎ内の端末９、１０がＩＰコアネットワーク４を経由したセッションを確立する際に、利用者情報等のＶＰＮ内の情報が外部に公開されないネットワーク構成を有するネットワークポリシー制御システムを提供するものである。
【０１２９】
図２５は、この発明にかかるネットワークポリシー制御システムの実施の形態６を示す構成図である。このネットワークシステムは、実施の形態４の図１４で説明したネットワークシステムに、さらに、ＶＰＮ内のポリシー制御を行うＶＰＮ内ポリシーサーバ（図２５中では、ＶＰＳと表記）２５と、ＶＰＮ内の利用者情報を格納するためのＶＰＮ内利用者情報データベース（同じく、ＶＵＤＢと表記）２３、２４と、ＶＰＮのアクセスネットワーク７−１〜７−ｎ、８−１〜８−ｎを収容したＶＰＮ内呼制御装置（同じく、ＶＣＡと表記）２１、２２とを備える構成となっている。
【０１３０】
ここで、ＶＰＮの管理者は、利用者情報を外部に公開されることを欲しないシステム利用者の利用者情報をＶＰＮ内ポリシーサーバ２５上で定義し、該定義した利用者情報をＶＰＮのそれぞれのアクセスネットワークに備えられているＶＰＮ内利用者情報データベース２３、２４に設定する。また、ＶＰＮ内呼制御装置２１、２２には、該ＶＰＮ内呼制御装置２１、２２自身が担当するＶＰＮのＶＰＮ−ＩＤが設定されている。図２５の例では、アクセスネットワーク７−１内の端末９とアクセスネットワーク８−１内の端末１０との間にＶＰＮ１を設定する場合であるので、ＶＰＮ内呼制御装置２１、２２には、ＶＰＮ−ＩＤとして「１」が設定されることになる。
【０１３１】
つぎに、このシステムにおける発呼端末と着呼端末との間のＶＰＮを用いたセッション確立の手順について図２６〜図２８のフローチャートを参照しながら説明する。ここでは、図２５において、アクセスネットワーク７−１内の端末９が、アクセスネットワーク８−１内の端末１０に対して発呼して、ＶＰＮを確立する場合を例に挙げて説明する。
【０１３２】
端末９は、セッション確立要求を端末１０に対して送信する（ステップＳ１２０）。該セッション確立要求は、まず、ＶＰＮ内呼制御装置２１によって受信される（ステップＳ１２１）。ＶＰＮ内呼制御装置２１は、セッション確立要求を受信すると、該セッション確立要求の内容とアクセスネットワーク７−１内のＶＰＮ内利用者情報データベース２３とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立要求に含めて転送する（ステップＳ１２２）。なお、以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。
【０１３３】
呼制御装置１は、ＶＰＮ内呼制御装置２１からセッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤが添付されたセッション確立要求を受信する（ステップＳ１２３）と、該セッション確立要求に含まれている情報を用いて着呼端末１０から発呼端末９への方向のストリームに対するリソース予約要求を生成し、ポリシーサーバ２に対して送信する（ステップＳ１２４）。そして、セッションの着呼端末１０から発呼端末９の方向のストリームに対して、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明したリソース予約確認処理を行う。
【０１３４】
呼制御装置１はポリシーサーバ２からリソース予約応答を受信する（ステップＳ１２５）と、該リソース予約応答が成功か否かを判断する（ステップＳ１２６）。リソース予約応答（成功）である場合（ステップＳ１２６でＹｅｓの場合）には、セッション確立要求を転送する（ステップＳ１２７）。一方、リソース予約応答（失敗）である場合（ステップＳ１２６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１２８）。
【０１３５】
着呼端末１０は、ＶＰＮ内呼制御装置２２を経由して、セッション確立要求を受信する（ステップＳ１２９）と、セッション確立応答を端末９に対して返信する（ステップＳ１３０）。
【０１３６】
ＶＰＮ内呼制御装置２２は、着呼端末１０からのセッション確立応答を受信する（ステップＳ１３１）と、セッション確立応答の内容とアクセスネットワーク８−１内のＶＰＮ内利用者情報データベース２４とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立応答に含めて転送する（ステップＳ１３２）。
【０１３７】
呼制御装置１は、ＶＰＮ内呼制御装置２２からセッション確立応答を受信する（ステップＳ１３３）と、該セッション確立応答に含まれている情報からセッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のストリームに対するリソース予約要求を生成し、リソース予約要求をポリシーサーバ２へ送信する（ステップＳ１３４）。ポリシーサーバ２は、このセッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のストリームに対して、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明したリソース予約確認処理を行う。
【０１３８】
呼制御装置１はポリシーサーバ２からリソース予約応答を受信する（ステップＳ１３５）と、該リソース予約応答が成功か否かを判断する（ステップＳ１３６）。リソース予約応答（成功）である場合（ステップＳ１３６でＹｅｓの場合）には、セッション確立応答を転送する（ステップＳ１３７）。一方、リソース予約応答（失敗）である場合（ステップＳ１３６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行して（ステップＳ１３８）、セッション確立処理が終了する。
【０１３９】
発呼端末９は、ＶＰＮ内呼制御装置２１を経由して、セッション確立応答を受信し（ステップＳ１３９）、発呼端末９と着呼端末１０との間にＶＰＮが確立される。
【０１４０】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、セッションストリームの送信をそれぞれ開始する。ＬＳＲ４１、４４でのセッションストリームの転送方法については、上述した実施の形態５と同様であるので説明を省略する。
【０１４１】
以上で説明したように、この実施の形態６によれば、ＶＰＮ内利用者情報データベースを各ＶＰＮのアクセスネットワーク内に設けたので、利用者情報が外部に公開されることがなく、利用者情報の管理に安全性が保たれる。また、ＶＰＮごとにＩＤ番号（識別子）を付すので、端末ごとにＶＰＮ−ＩＤを設定する必要がなく、ＶＰＮの管理が容易になるという効果がある。
【０１４２】
実施の形態７．
つぎに、図２９〜図３３を用いてこの発明の実施の形態７について説明する。この実施の形態７は、大規模なネットワークにおける呼数の増大に対する呼制御装置、ポリシーサーバおよびエッジＬＳＲとの間における過大な負荷を分散することが可能なネットワークポリシー制御システムおよびその方法を提供するものである。
【０１４３】
図２９は、この発明にかかるネットワークポリシー制御システムの実施の形態７を示す構成図である。このネットワークシステムは、実施の形態１の図１で説明したネットワークシステムに、さらに、エッジＬＳＲ４１、４４を制御する副ポリシーサーバ３３、３４と、該副ポリシーサーバ３３、３４に関連付けされている副呼制御装置３１、３２とを備える構成となっている。その他の構成については、図１と同一であるので、その説明を省略している。
【０１４４】
副呼制御装置３１、３２は、エッジＬＳＲであるＬＳＲ４１、４４が収容するアクセスネットワーク７、８内の端末９、１０が発行したセッション確立要求／応答をＩＰコアネットワーク４内で最初に中継する呼制御装置である。そして、それぞれの副呼制御装置３１、３２に対して、副ポリシーサーバ３３、３４が設置されている。なお、呼制御装置１は、複数存在する副呼制御装置３１、３２を管理し、ポリシーサーバ２は、複数存在する副ポリシーサーバに対してＩＰコアネットワーク４内の複数の副呼制御装置３１、３２と関連付けを行うなどの複数の副ポリシーサーバ３３、３４の管理を行っている。
【０１４５】
つぎに、ＩＰコアネットワーク４におけるＶＰＮごとのリソース管理の処理方法について説明する。
【０１４６】
図２９のネットワークシステムにおけるＬＳＲのＬＳＰを設定する処理手順について、図３０〜図３３のフローチャートを参照しながら説明する。ここで、端末９が端末１０に対して発呼した場合の動作を例に挙げて説明する。
【０１４７】
端末９は、セッション確立要求を端末１０に対して送信する（ステップＳ１４１）が、該セッション確立要求は、副呼制御装置３１および呼制御装置１を経由して、副呼制御装置３２によって受信される（ステップＳ１４２）。副呼制御装置３２は、受信したセッション確立要求に含まれる情報を基に、セッションの端末１０から端末９の方向のストリームについて、セッション識別子、発呼端末アドレス、着呼端末アドレスおよび上記ストリームに必要な回線リソース量を含むリソース予約要求を副ポリシーサーバ３４に対して送信する（ステップＳ１４３）。以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末１０と呼ぶ。
【０１４８】
副ポリシーサーバ３４はリソース予約要求を受信する（ステップＳ１７１）と、上記ストリームを収容するＬＳＰの候補を決定し（ステップＳ１７２）、そのＬＳＰに上記ストリームを収容可能であるかを、ＬＳＰのリソース量と上記ストリームに必要なリソース量とを比較することによって判定する（ステップＳ１７３）。ＬＳＰが十分なリソース量を有する場合（ステップＳ１７３でＹｅｓの場合）には、副ポリシーサーバ３４は、そのＬＳＰに上記ストリームを転送するようにＬＳＰの初段ＬＳＲ（図２９の場合ではＬＳＲ４４）に設定し（ステップＳ１７４）、リソース予約応答（成功）を副呼制御装置３２に返送する（ステップＳ１７５）。一方、ＬＳＰが十分なリソース量を有しない場合（ステップＳ１７３でＮｏの場合）には、副ポリシーサーバ３４はリソース予約応答（失敗）を副呼制御装置３２に返送する（ステップＳ１７６）。以上のステップＳ１７１〜Ｓ１７６で上述した副ポリシーサーバ３４によるリソース予約処理が完了する。
【０１４９】
副呼制御装置３２は、リソース予約応答を受信する（ステップＳ１４４）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１４５）。リソース予約応答（成功）である場合（ステップＳ１４５でＹｅｓの場合）には、セッション確立要求を着呼端末１０に転送する（ステップＳ１４６）。一方、リソース予約応答（失敗）である場合（ステップＳ１４５でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１４７）。
【０１５０】
着呼端末１０はセッション確立要求を受信する（ステップＳ１４８）と、発呼端末９に対して、セッション確立応答を返送する（ステップＳ１４９）。
【０１５１】
セッション確立応答は、まず、副呼制御装置３２によって受信され（ステップＳ１５０）、副呼制御装置３２はセッション確立応答に含まれる情報を基に、上記セッション確立要求受信時と同様に、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を副ポリシーサーバ３４に送信する（ステップＳ１５１）。
【０１５２】
副ポリシーサーバ３４は、副呼制御装置３２からリソース予約要求を受信すると、上述した図３３のステップＳ１７１〜Ｓ１７６で説明したリソース予約確認処理を行い、リソース予約応答を副呼制御装置３２に対して送信する。
【０１５３】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ１５２）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１５３）。リソース予約応答（成功）である場合（ステップＳ１５３でＹｅｓの場合）には、セッション確立応答を転送する（ステップＳ１５４）。一方、リソース予約応答（失敗）である場合（ステップＳ１５３でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１５５）。
【０１５４】
副呼制御装置３２から送信されたセッション確立応答は、呼制御装置１を経由して、副呼制御装置３１によって、受信される（ステップＳ１５６）。副呼制御装置３１は、セッション確立応答に含まれる情報を基に、セッションの発呼端末９から着呼端末１０方向のストリームについてのリソース予約要求を副ポリシーサーバ３３に送信する（ステップＳ１５７）。
【０１５５】
副ポリシーサーバ３３は、副呼制御装置３１からリソース予約要求を受信すると、上述した図３３のステップＳ１７１〜Ｓ１７６で説明したリソース予約確認処理と同様にして発呼端末９から着呼端末１０方向のストリームについてのリソース予約処理を行い、リソース予約応答を副呼制御装置３１に対して送信する。
【０１５６】
副呼制御装置３１はリソース予約応答を受信する（ステップＳ１５８）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ１５９）。リソース予約応答（成功）である場合（ステップＳ１５９でＹｅｓの場合）には、発呼端末９に対してセッション確立応答を転送し（ステップＳ１６０）、発呼端末９は、セッション確立応答を受信する（ステップＳ１６１）。一方、リソース予約応答（失敗）である場合（ステップＳ１５９でＮｏの場合）には、副呼制御装置３１はセッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１６２）。
【０１５７】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、発呼端末９および着呼端末１０はそれぞれセッションストリームの送信を開始する。ここで、セッションストリームはＬＳＲ４１、４４において、上述した工程で設定された情報に基づいてＬＳＰに転送される。
【０１５８】
以上で説明したように、この実施の形態７によれば、セッション確立要求に伴うリソース予約確認処理が副呼制御装置、副ポリシーサーバで処理され、処理の負荷が分散されるので、呼数の増大に対しても対応することができるという効果がある。
【０１５９】
実施の形態８．
つぎに、図３４〜図３８を用いてこの発明の実施の形態８について説明する。この実施の形態８は、大規模なネットワークにおける呼数の増大に対する呼制御装置、ポリシーサーバおよびエッジＬＳＲとの間における過大な負荷を分散することが可能なネットワークポリシー制御方法を提供するものである。
【０１６０】
図３４は、この発明にかかるネットワークポリシー制御システムの実施の形態８を示す構成図である。このネットワークシステムは、実施の形態７の図２９で説明したネットワークシステムにおいて、利用者情報データベース３５、３６が、副呼制御装置３１、３２ごとに設けられている構成となっている。その他の構成については、図２９と同一であるので、その説明を省略している。
【０１６１】
このシステムにおいて、ネットワーク管理者は、実施の形態１と同様に、ポリシーサーバ２上で利用者情報を利用者情報データベース３５、３６に保存する。ただし、この利用者情報データベース３５、３６は副呼制御装置３１、３２に対応する形で設置されている。
【０１６２】
ここで、図３４のネットワークシステムにおけるＬＳＲ４１〜４６のＬＳＰを設定する処理手順について、図３５〜図３８のフローチャートを参照しながら説明する。ここで、端末９が端末１０に対して発呼した場合の動作を例に挙げて説明する。
【０１６３】
まず、端末９は、端末１０に対してセッション確立要求を送信する（ステップＳ１８１）。該セッション確立要求は、副呼制御装置３１および呼制御装置１を介して、副呼制御装置３２によって受信される（ステップＳ１８２）。副呼制御装置３２は、セッション確立要求の内容と利用者情報データベース３６とを照合し、セッションの着呼端末１０から発呼端末９の方向のストリームに適用するＣｏＳ／回線リソース量を取得し（ステップＳ１８３）、そして、副ポリシーサーバ３４に対して着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を送信する（ステップＳ１８４）。
【０１６４】
副ポリシーサーバ３４は、上述した実施の形態１の図７のステップＳ３１〜Ｓ３７で説明したリソース予約確認処理と同様にして、着呼端末１０から発呼端末９の方向のストリームについてのリソース予約処理を行い、リソース予約応答を副呼制御装置３２に対して送信する。
【０１６５】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ１８５）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１８６）。リソース予約応答（成功）である場合（ステップＳ１８６でＹｅｓの場合）には、セッション確立要求を着呼端末１０に対して転送する（ステップＳ１８７）。一方、リソース予約応答（失敗）である場合（ステップＳ１８６でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１８８）。
【０１６６】
着呼端末１０は副呼制御装置３２からセッション確立要求を受信する（ステップＳ１８９）と、セッション確立応答を発呼端末に対して返送する（ステップＳ１９０）。
【０１６７】
副呼制御装置３２はセッション確立応答を受信する（ステップＳ１９１）と、セッション確立応答の内容と利用者情報データベース３６とを照合し、セッションの着呼端末１０から発呼端末９の方向のストリームに適用するＣｏＳ／回線リソース量を取得し（ステップＳ１９２）、そして、副ポリシーサーバ３４に対して着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を送信する（ステップＳ１９３）。なお、着呼端末１０から発呼端末９の方向のリソース予約処理は既に行われているが、着呼端末１０におけるセッション確立要求受信およびセッション確立応答返送時に、セッション情報のネゴシエーションがなされているために、ここでも着呼端末１０から発呼端末９の方向のリソース予約処理が行われている。
【０１６８】
副ポリシーサーバ３４は、副呼制御装置３２からリソース予約要求を受信すると、上述した実施の形態１の図７のステップＳ３１〜Ｓ３７で説明した処理と同様にして、着呼端末１０から発呼端末９の方向のリソース予約確認処理を行い、リソース予約応答を副呼制御装置３２に対して送信する。
【０１６９】
副呼制御装置３２は副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ１９４）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ１９５）。リソース予約応答（成功）である場合（ステップＳ１９５でＹｅｓの場合）には、セッション確立応答を転送する（ステップＳ１９６）。一方、リソース予約応答（失敗）である場合（ステップＳ１９５でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１９７）。
【０１７０】
副呼制御装置３２から送信されたセッション確立応答は、呼制御装置１を介して、副呼制御装置３１によって受信される（ステップＳ１９８）。セッション確立応答を受信した副呼制御装置３１は、セッション確立応答の内容と利用者情報データベース３５とを照合し、セッションの発呼端末９から着呼端末１０の方向のストリームに適用するＣｏＳ／回線リソース量を取得し（ステップＳ１９９）、そして、副ポリシーサーバ３３に対してセッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約要求を送信する（ステップＳ２００）。
【０１７１】
副ポリシーサーバ３３は、副呼制御装置３１からリソース予約要求を受信すると、上述した実施の形態１の図７のステップＳ３１〜Ｓ３７で説明した処理と同様にして、セッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約確認処理を行い、リソース予約応答を副呼制御装置３１に対して送信する。
【０１７２】
副呼制御装置３１はリソース予約応答を受信する（ステップＳ２０１）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ２０２）。リソース予約応答（成功）である場合（ステップＳ２０２でＹｅｓの場合）には、セッション確立応答を発呼端末９に対して転送し（ステップＳ２０３）、発呼端末９はセッション確立応答を受信する（ステップＳ２０４）。一方、リソース予約応答（失敗）である場合（ステップＳ２０２でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２０５）。
【０１７３】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、発呼端末９および着呼端末１０はそれぞれセッションストリームの送信を開始する。また、セッションストリームのＬＳＲにおける転送方法については、実施の形態１と同様なのでその説明を省略する。
【０１７４】
以上説明してきたように、この実施の形態８によれば、端末９、１０間で確立されるセッションに対してサービスクラスのグレード付けを行ったバーチャル通信パス情報がポリシーサーバ２とともにＬＳＲ４１〜４６に設定されるので、セッション確立時のバーチャル通信パスに対するリソース予約はポリシーサーバ２が行い、セッションストリームの転送はバーチャル通信パスにしたがってＬＳＲ４１〜４６が自律的に行うように構成される。その結果、ポリシーサーバ２がセッション確立時にエッジＬＳＲ４１、４４に逐一設定を行う必要がなくなるので、ポリシーサーバ２の負荷を軽減することが可能となる。また、エッジＬＳＲにおいて、セッションストリームごとのフィルタリングが不用なためその分の負荷も軽減される。さらに、セッション確立要求に伴うリソース予約確認処理が副呼制御装置、副ポリシーサーバで処理されるため、それらで行われる処理の負荷が分散されるという効果がある。
【０１７５】
実施の形態９．
つぎに、図３９〜図４３を用いてこの発明の実施の形態９について説明する。この実施の形態９は、アクセスネットワーク７−１〜７−ｎ、８−１〜８−ｎ内の端末９、１０がＩＰコアネットワーク４を経由したセッションを確立する際に、利用者情報等のＶＰＮ内の情報が外部に公開されないネットワーク構成を有すると共に、大規模なネットワークにおける呼数の増大に対する呼制御装置、ポリシーサーバおよびエッジＬＳＲとの間における過大な負荷を分散することが可能なネットワークポリシー制御システムを提供するものである。
【０１７６】
図３９は、この発明にかかるネットワークポリシー制御システムの実施の形態９を示す図である。このネットワークシステムは、実施の形態６の図２５で説明したネットワークシステムにおいて、さらに、エッジＬＳＲ４１、４４を制御する副ポリシーサーバ３３、３４と、該副ポリシーサーバ３３、３４と関連付けされている副呼制御装置３１、３２とを備える構成となっている。これらの装置は実施の形態８の図３４で示したものと同一であるので、また、その他の構成については図２５で示したものと同一であるので、その説明を省略している。なお、呼制御装置１は、複数存在する副呼制御装置３１、３２を管理し、ポリシーサーバ２は、複数存在する副ポリシーサーバ３３、３４を管理している。
【０１７７】
ここで、図３９のネットワークシステムにおけるＶＰＮの確立手順について、図４０〜図４３のフローチャートを参照しながら説明する。ここで、端末９が端末１０に対して発呼した場合の動作を例に挙げて説明する。
【０１７８】
端末９は、端末１０に対してセッション確立要求を送信する（ステップＳ２１０）。以下、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。該セッション確立要求は、まず、ＶＰＮ内呼制御装置２１によって受信される（ステップＳ２１１）。ＶＰＮ内呼制御装置２１は、セッション確立要求を受信すると、該セッション確立要求の内容とアクセスネットワーク７−１内のＶＰＮ内利用者情報データベース２３とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立要求に含めて転送する（ステップＳ２１２）。
【０１７９】
送信されたセッション確立要求は、副呼制御装置３１と呼制御装置１を介して、副呼制御装置３２によって受信される（ステップＳ２１３）。副呼制御装置３２は、セッション確立要求を受信すると、該セッション確立要求に含まれている情報から、セッションの着呼端末１０から発呼端末９の方向のストリームに対してリソース予約要求を生成し、副ポリシーサーバ３４に対して送信する（ステップＳ２１４）。そして、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明した処理と同様にして、副ポリシーサーバ３４は、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理を行う。ただし、図５では、ポリシーサーバ２が処理を行っているが、この実施の形態９では、ステップＳ１１１〜Ｓ１１７の処理は副呼制御装置３２に関連付けされている副ポリシーサーバ３４によって行われる。
【０１８０】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ２１５）と、該リソース予約応答が成功であるか否かについての判断を行う（ステップＳ２１６）。リソース予約応答（成功）である場合（ステップＳ２１６でＹｅｓの場合）には、副呼制御装置３２は、セッション確立要求を転送する（ステップＳ２１７）。一方、リソース予約応答（失敗）である場合（ステップＳ２１６でＮｏの場合）には、呼制御装置は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２１８）。
【０１８１】
副呼制御装置３２によって転送されたセッション確立要求は、ＶＰＮ内呼制御装置２２を介して、着呼端末１０によって受信される（ステップＳ２１９）。セッション確立要求を受信した着呼端末１０は、セッション確立応答を発呼端末９に対して返送する（ステップＳ２２０）。
【０１８２】
着呼端末１０によって送信されたセッション確立応答は、ＶＰＮ内呼制御装置２２によって受信される（ステップＳ２２１）。ＶＰＮ内呼制御装置２２は、セッション確立応答を受信すると、該セッション確立要求の内容とアクセスネットワーク８−１内のＶＰＮ内利用者情報データベース２４とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立要求に含めて転送する（ステップＳ２２２）。
【０１８３】
副呼制御装置３２はセッション確立応答を受信する（ステップＳ２２３）と、セッション確立応答に含まれる情報からセッションの着呼端末１０から発呼端末９の方向のストリームに対してリソース予約要求を生成し、副ポリシーサーバ３４にリソース予約要求を送信して、リソース予約確認処理を行う（ステップＳ２２４）。そして、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明した処理と同様にして、副ポリシーサーバ３４はセッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理を行う。ただし、図５では、ポリシーサーバ２が処理を行っているが、ここでの処理は、副呼制御装置３２に関連付けされている副ポリシーサーバ３４によって行われる。
【０１８４】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ２２５）と、該リソース予約応答が成功であるか否かについて判断を行う（ステップＳ２２６）。リソース予約応答（成功）である場合（ステップＳ２２６でＹｅｓの場合）には、副呼制御装置３２はセッション確立応答を転送する（ステップＳ２２７）。一方、リソース予約応答（失敗）である場合（ステップＳ２２６でＮｏの場合）には、副呼制御装置３２は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２２８）。
【０１８５】
副呼制御装置３２によって送信されたセッション確立応答は、呼制御装置１を介して、副呼制御装置３１によって受信される（ステップＳ２２９）。副呼制御装置３１は、セッション確立応答を受信すると、セッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約要求を生成し、副ポリシーサーバ３３へリソース予約要求を送信して、リソース予約確認処理を行う（ステップＳ２３０）。そして、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明した処理と同様にして、セッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約確認処理が行われる。ただし、図５では、ポリシーサーバ２が処理を行っているが、ここでの処理は、副呼制御装置３１に関連付けされている副ポリシーサーバ３３によって行われる。
【０１８６】
副呼制御装置３１は、副ポリシーサーバ３３からリソース予約応答を受信する（ステップＳ２３１）と、該リソース予約応答が成功であるか否かについて判断を行う（ステップＳ２３２）。リソース予約応答（成功）である場合（ステップＳ２３２でＹｅｓの場合）には、副呼制御装置３１はセッション確立応答を転送する（ステップＳ２３３）。一方、リソース予約応答（失敗）である場合（ステップＳ２３２でＮｏの場合）には、副呼制御装置３１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２３４）。
【０１８７】
そして、副呼制御装置３１によって送信されたセッション確立応答は、ＶＰＮ内呼制御装置２１を介して、発呼端末９によって受信される（ステップＳ２３５）。
【０１８８】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、発呼端末９および着呼端末１０はそれぞれセッションストリームの送信を開始する。また、セッションストリームのＬＳＲにおける転送方法については、実施の形態１と同様なのでその説明を省略する。
【０１８９】
以上で説明したように、この実施の形態９によれば、ＶＰＮ内利用者情報データベースを各ＶＰＮのアクセスネットワーク内に設けたので、利用者情報が外部に公開されることがなく、利用者情報の管理に安全性が保たれる。また、ＶＰＮごとにＩＤ番号を付すので、端末ごとにＶＰＮ−ＩＤを設定する必要がないという効果がある。その結果、ＶＰＮの管理が容易になる。さらに、セッションに対してサービスグレード付けを行い、かつセッション確立ごとにエッジＬＳＲに逐一設定を行うことなく、ＩＰコアネットワークにおいてセッションストリームのためのリソースを確保可能かについて判定することが可能となる。また、エッジＬＳＲにおいて、セッションストリームごとのＬＳＰの設定やフィルタリングが不用なためその分の負荷も軽減される。さらに、セッション確立要求に伴うリソース予約確認処理が副呼制御装置、副ポリシーサーバで処理されるため、それらで行われる処理の負荷が分散されるという効果がある。
【０１９０】
なお、以上で説明した実施の形態において、副呼制御装置３１、３２とそれに関連付けられている副ポリシーサーバ３３、３４およびエッジＬＳＲ４１、４４は、別個の装置であるかのように記載したが、副呼制御装置３１、３２と副ポリシーサーバ３３、３４は、例えばソフトウェアといった処理単位に相当するので、副呼制御装置３１、３２と副ポリシーサーバ３３、３４を同一装置内で動作させるように構成したり、副呼制御装置３１、３２と副ポリシーサーバ３３、３４をエッジＬＳＲ４１、４４内で動作させるように構成したりすることも可能である。
【０１９１】
【発明の効果】
以上説明したように、この発明によれば、ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定されるＬＳＰをまとめてバーチャル通信パスとして定義するように構成したので、ポリシーサーバはバーチャル通信パスの単位でのみポリシー管理を行うことができる。また、ポリシーサーバはセッションに送信されるストリームについてのバーチャル通信パスのリソース予約を行うだけであり、ＬＳＲに対するセッション確立時の設定処理を行う必要がない。その結果、ポリシーサーバの負荷を減らすことができる。さらに、初段ＬＳＲとなるＬＳＲは、受信したストリームのパケットから得られたサービスクラスと宛先アドレスからバーチャル通信パスを選択し、該バーチャル通信パスにストリームを転送する処理だけを行う。そして、従来では必要だった、該ＬＳＲによる受信したストリームのフィルタリング処理を行う必要がないので、ストリームの転送処理の高速化を図ることが可能となる。
【０１９２】
つぎの発明によれば、サービスを利用する端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースを備えるように構成したので、利用者単位でサービスクラスの設定を行うことができ、利用者に応じたサービスを提供することができる。
【０１９３】
つぎの発明によれば、ポリシーサーバは、選択したバーチャル通信パスの残存リソース量がストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行って、前記ストリームのサービスクラスおよび回線リソース量を確保する機能を有するリソース予約手段を備えるように構成したので、多数のセッションが確立され、同じバーチャル通信パス内を転送されるストリームの量が多くなっても、自動的に該バーチャル通信パスの回線リソース量を増加させることによって、利用者に対するサービスの品質を維持することができる。
【０１９４】
つぎの発明によれば、サービスクラスにＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスを備えるように構成したので、利用者に対して一層多様な種類のサービスを提供することができる。
【０１９５】
つぎの発明によれば、回線リソース量は、保証される回線リソース量によってクラス付けされた回線リソース量クラスによって定義されるように構成したので、ストリームを最初に受信する初段ＬＳＲは、該回線リソース量クラスによって前記ストリームに対して一層きめ細かなＱｏＳ制御を行うことができる。
【０１９７】
つぎの発明によれば、初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められるバーチャル通信パスがポリシーサーバとＬＳＲに設定されるように構成されるので、ポリシーサーバはセッションに送信されるストリームについてのバーチャル通信パスのリソース予約を行うだけで、ＬＳＲに対してセッション確立時に設定を行う必要がない。また、ポリシーサーバは、ＩＰコアネットワークにおいて、ＶＰＮごとのリソース管理を行うことが可能となる。さらに、ＬＳＲは、受信したストリームのパケットから得られたサービスクラスと宛先アドレスとＶＰＮ識別子とからバーチャル通信パスを選択し、該バーチャル通信パスにストリームを転送するだけでよく、従来必要であった受信したストリームのフィルタリング処理を行う必要がなくなるので、ストリームの転送処理の高速化を図ることが可能となる。
【０１９８】
つぎの発明によれば、利用者の端末が属するネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付してそれぞれのネットワークごとに格納するＶＰＮ内利用者情報データベースをＶＰＮ内部に備えるように構成したので、利用者情報データベースの外部からの不正な侵入を抑制し、ＶＰＮの安全性を高めることができる。また、ポリシーサーバは、ネットワークに存在する端末ごとにＶＰＮ識別子を設定する必要がないので、ポリシーサーバの処理を軽減することが可能となる。
【０２００】
つぎの発明によれば、副ポリシーサーバは、選択したバーチャル通信パスの残存リソース量がストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行って、前記ストリームのサービスクラスおよび回線リソース量を確保する機能を有するリソース予約手段を備えるように構成したので、多数のセッションが確立され、同じバーチャル通信パス内を転送されるストリームの量が多くなっても、自動的に該バーチャル通信パスの回線リソース量を増加させることができる。その結果、品質を落とすことなく利用者にサービスを提供することが可能となる。また、副呼制御装置と副ポリシーサーバとを備えるように構成したので、ネットワークが大規模になった場合に増大するセッション確立の処理を、一台の呼制御装置とポリシーサーバで行うのではなく、同じ機能を有する複数の副呼制御装置と副ポリシーサーバで実行するので、処理の負荷を分散することが可能となる。
【０２０１】
つぎの発明によれば、利用者の端末が属するネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付してそれぞれのネットワークごとに格納するＶＰＮ内利用者情報データベースをＶＰＮ内部に備えるように構成したので、利用者情報データベースの外部からの不正な侵入を抑制し、ＶＰＮの安全性を高めることができる。また、副呼制御装置と副ポリシーサーバとを備えるように構成したので、ネットワークが大規模になった場合に増大するセッション確立の処理を、一台の呼制御装置とポリシーサーバで行うのではなく、同じ機能を有する複数の副呼制御装置と副ポリシーサーバで実行するので、処理の負荷を分散することが可能となる。
【０２０２】
つぎの発明によれば、副呼制御装置を呼制御装置で管理し、副ポリシーサーバをポリシーサーバで管理するように構成したので、それぞれの副呼制御装置および副ポリシーサーバにおける役割の分担を行うことができ、システム全体での処理の効率化を図ることが可能となる。
【０２０３】
つぎの発明によれば、副ポリシーサーバは複数の副呼制御装置と関連付けできるように構成したので、システム上における副ポリシーサーバの配置を、その負荷の程度を考慮して自由に設計することができる。
【０２０４】
つぎの発明によれば、副呼制御装置と副ポリシーサーバとを同一の装置内に備えるように構成したので、システム内に設置する装置の数を抑えて、システム構成の複雑化を抑制することができる。
【０２０５】
つぎの発明によれば、副呼制御装置と副ポリシーサーバとを同一の前記ＬＳＲ内に備えるように構成したので、システム内に設置する装置の数を抑えて、システム構成の複雑化を抑制することができる。
【０２０６】
つぎの発明によれば、ポリシーサーバは、選択したバーチャル通信パスの残存リソース量がストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行って、前記ストリームのサービスクラスおよび回線リソース量を確保する機能を有するリソース予約手段を備えるように構成したので、多数のセッションが確立され、同じバーチャル通信パス内を転送されるストリームの量が多くなっても、自動的に該バーチャル通信パスの回線リソース量を増加させることによって、利用者に対するサービスの品質を維持することができる。
【０２０７】
つぎの発明によれば、ポリシーサーバのバーチャル通信パス定義手段は、バーチャル通信パスにさらにＶＰＮごとの回線リソース量を定める機能を備えるように構成したので、ＩＰコアネットワークを介して通信を行うネットワーク間にＶＰＮを構築することが可能となる。
【図面の簡単な説明】
【図１】 この発明にかかるネットワークポリシー制御システムの実施の形態１の構成を示すブロック図である。
【図２】 バーチャル通信パスの設定手順を示すフローチャートである。
【図３】 利用者情報データベースの構成の一例を示す図である。
【図４】 属性情報を含むバーチャル通信パスの構成例を示す図である。
【図５】 発呼端末と着呼端末との間におけるセッション確立の処理手順を示すフローチャートである（その１）。
【図６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図８】 この発明の実施の形態２で用いるサービスクラス（ＣｏＳ）の遅延クラスのクラス分けの一例を示す図である。
【図９】 利用者情報データベースの構成の一例を示す図である。
【図１０】 属性情報を含むバーチャル通信パスの構成例を示す図である。
【図１１】 この発明の実施の形態３における回線リソース量のクラス分けの一例を示す図である。
【図１２】 利用者情報データベースの構成の一例を示す図である。
【図１３】 バーチャル通信パスの設定手順を示すフローチャートである。
【図１４】 この発明にかかるネットワークポリシー制御システムの実施の形態４の構成を示すブロック図である。
【図１５】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図１６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図１７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図１８】 この発明にかかるネットワークポリシー制御システムの実施の形態５の構成を示すブロック図である。
【図１９】 バーチャル通信パスの設定手順を示すフローチャートである。
【図２０】 利用者情報データベースの構成の一例を示す図である。
【図２１】 属性情報を含むバーチャル通信パスの構成例を示す図である。
【図２２】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図２３】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図２４】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図２５】 この発明にかかるネットワークポリシー制御システムの実施の形態６の構成を示すブロック図である。
【図２６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図２７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図２８】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図２９】 この発明にかかるネットワークポリシー制御システムの実施の形態７の構成を示すブロック図である。
【図３０】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図３１】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図３２】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図３３】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その４）。
【図３４】 この発明にかかるネットワークポリシー制御システムの実施の形態８の構成を示すブロック図である。
【図３５】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図３６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図３７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図３８】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その４）。
【図３９】 この発明にかかるネットワークポリシー制御システムの実施の形態９の構成を示すブロック図である。
【図４０】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図４１】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図４２】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図４３】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その４）。
【図４４】 ＭＰＬＳ／ＩＰネットワーク上におけるＶｏＩＰストリームのＱｏＳの保証を行うシステムの従来例を示すブロック図である。
【符号の説明】
１ 呼制御装置、２ ポリシーサーバ、３，３５，３６ 利用者情報データベース、４ ＩＰコアネットワーク、５，６ ゲートウェイ、７，８ アクセスネットワーク、９，１０ 端末、２１，２２ ＶＰＮ内呼制御装置、２３，２４ ＶＰＮ内利用者情報データベース、２５ ＶＰＮ内ポリシーサーバ、３１，３２副呼制御装置、３３，３４ 副ポリシーサーバ、４１〜４６ ラベルスイッチングルータ。
【発明の属する技術分野】
本発明は、ラベルスイッチングルータを備えたＩＰネットワークにおけるセッションストリームの通信品質を保証することが可能なネットワークポリシー制御システムおよびこれに用いるポリシーサーバに関するものである。
【０００２】
【従来の技術】
従来のＩＰ（Internet Protocol）ネットワークにおけるＶｏＩＰ（Voice over Internet Protocol）を使用した通信のＱｏＳ（Quality of Service）保証方法に関する従来技術として、特開２００１−２７４８３３号公報に開示されているＶｏＩＰ用通信品質保証パス設定方法とネットワーク管理システムがある。この従来技術に開示されているＶｏＩＰ用通信品質保証パス設定方法では、ＭＰＬＳ（Multi Protocol Label Switching）／ＩＰネットワーク上で、ＶｏＩＰストリームのためのＱｏＳを保証することを目的としている。
【０００３】
図４４は、この従来技術に開示されているＩＰネットワーク１１７おいて、ＭＰＬＳによりパケット転送を行い、ＱｏＳを保証するシステムの構成図である。この図４４に示されるシステムでは、呼制御装置１０１と、エッジラベルスイッチングルータ（図４４中では、ＥｄｇｅＬＳＲと表記）１１２、１１５と、メディアゲートウェイ（同じく、ＭＧと表記）１１３、１１４と、ラベルスイッチング方式のＭＰＬＳサーバ１２０と、コアラベルスイッチングルータ（同じく、ＣｏｒｅＬＳＲと表記）１２３〜１２７とから構成されている。ここで、エッジラベルスイッチングルータ１１２、１１５はそれぞれ電話機１２８、１２９を収容するメディアゲートウェイ１１３、１１４を収容している。また、呼制御装置１０１は電話機間の呼を制御する装置である。なお、以下では、ラベルスイッチングルータ（Label Switching Router）をＬＳＲと表記する。
【０００４】
電話機１２８が電話機１２９に対して発呼する場合には、呼制御装置１０１を介してセッションが確立される。一方、電話機１２８から電話機１２９の音声データは、メディアゲートウェイ１１３、１１４で音声データとＶｏＩＰストリームとの間の変換がなされ、メディアゲートウェイ１１３とメディアゲートウェイ１１４との間のＩＰネットワーク１１７上では、ＶｏＩＰストリームが転送される。
【０００５】
つぎに、このシステムにおけるＶｏＩＰストリームのＱｏＳ保証について説明する。まず、電話機１２８が電話機１２９に対して発呼し、メディアゲートウェイ１１３とメディアゲートウェイ１１４との間にＶｏＩＰコネクションを確立する際に、ＱｏＳ保証が必要な場合に限り呼制御装置１０１は、ＭＰＬＳサーバ１２０に対してＶｏＩＰストリームを転送するためのリソース予約を要求する。ＭＰＬＳサーバ１２０は、もし、既にエッジＬＳＲ１１２とエッジＬＳＲ１１５との間にそのＶｏＩＰストリームを収容可能なＱｏＳ保証されたラベルスイッチパス（Label Switched Path、以下、ＬＳＰと表記する）が設定されている場合には、ＶｏＩＰストリームを該ＬＳＰに流すためのフィルタ条件をエッジＬＳＲ１１２およびエッジＬＳＲ１１５に対して設定する。また、もし、そのＶｏＩＰストリームを収容するにはそのＱｏＳ保証されたＬＳＰのリソースが不十分であるか、またはＱｏＳ保証されたＬＳＰがエッジＬＳＲ１１２とエッジＬＳＲ１１５との間に設定されていない場合には、エッジＬＳＲ１１２およびエッジＬＳＲ１１５に対してＱｏＳ保証されたＬＳＰを設定するように指示し、この設定したＬＳＰにＶｏＩＰストリームを収容し、ＱｏＳ保証を行っている。
【０００６】
【発明が解決しようとする課題】
しかしながら、上述した従来技術では、エッジＬＳＲ１１２、１１５がＶｏＩＰストリームを受信した時に、それをどのＱｏＳを提供するＬＳＰに転送すれば良いのかについて自律的に判断することができず、ＭＰＬＳサーバ１２０からの設定を必要としていた。つまり、電話機１２８、１２９間で発呼が行われるときに、すなわちセッション確立時に、ＭＰＬＳサーバ１２０からエッジＬＳＲ１１２、１１５に対してその電話機１２８、１２９間のＶｏＩＰストリームを流すためのＱｏＳを含めたＬＳＰの設定、すなわち、受信したパケットをどのＬＳＰに転送するのかを定めたフィルタ条件の設定を行わなければならなかった。また、ＭＰＬＳサーバ１２０は、このフィルタ条件をＬＳＲに設定すると共に、ＬＳＰごとに残存リソース量を管理しなければならず、ＭＰＬＳサーバ１２０に過大な負荷が発生してしまうという問題点があった。
【０００７】
さらに、ＩＰネットワーク１１７が、複数のＶＰＮを収容する機能をもつネットワークである場合には、ＶＰＮ（Virtual Private Network）ごとのリソース管理を行うことができないという問題点があった。さらにまた、ネットワークが大規模になるにつれ、呼数が膨大することが予想されるが、従来のＶｏＩＰ用通信品質保証パス設定方法においては、セッション確立の度に呼制御装置１０１、ＭＰＬＳサーバ１２０およびエッジＬＳＲ１１２、１１５の間でシーケンスが発生するため、過大な負荷が発生してしまうという問題点があった。
【０００８】
この発明は上記に鑑みてなされたもので、エッジＬＳＲが異なるネットワーク内の二つの端末間で送信されるストリームを受信した時に、どのＬＳＰに転送すべきかを自立的に判断することが可能なネットワーク制御システムおよびこれに用いるポリシーサーバを得ることを第一の目的とする。
【０００９】
また、複数のＶＰＮを収容する機能を有するＩＰネットワークにおいて、複数のＶＰＮごとのリソース管理を行うことが可能なネットワーク制御システムおよびこれに用いるポリシーサーバを得ることを第二の目的とする。
【００１０】
さらに、呼数の増大に対しても呼制御装置に対する過大な負荷を抑制することが可能なネットワークポリシー制御システムおよびこれに用いるポリシーサーバを得ることを第三の目的とする。
【００１１】
【課題を解決するための手段】
上記目的を達成するため、この発明にかかるネットワークポリシー制御システムは、複数のＬＳＲを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムであって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ＬＳＲに設定するバーチャル通信パス設定手段と、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、を含むポリシーサーバをさらに備え、前記端末からのストリームを最初に受信した初段ＬＳＲは、前記ストリームのパケットに格納されている宛先アドレスおよびサービスクラスに適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００１２】
この発明によれば、複数のＬＳＲを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備え、前記端末からのストリームを最初に受信した初段ＬＳＲによって、前記ストリームのパケットに格納されている宛先アドレスおよびサービスクラスに適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送されるネットワークポリシー制御システムが提供される。ここで、ポリシーサーバのバーチャル通信パス定義手段によって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるバーチャル通信パスが定義される。また、バーチャル通信パス設定手段によって、該バーチャル通信パスが前記ＬＳＲに設定される。さらに、リソース予約手段によって、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの残存リソース量に前記ストリームのリソース量が収容可能であると判断された場合にはリソース予約が行われる。
【００１３】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースをさらに備え、前記呼制御装置は、前記二つの端末間のセッション確立要求／応答を受信すると、前記利用者情報から取得した前記セッションのストリームに適用するサービスクラスと回線リソース量を取得して前記リソース予約要求を作成し、前記ポリシーサーバに送信するリソース予約要求手段を備えることを特徴とする。
【００１４】
この発明によれば、利用者情報データベースに、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報が格納される。また、前記呼制御装置のリソース予約要求手段によって、前記二つの端末間のセッション確立要求／応答が受信されると、前記利用者情報から取得した前記セッションのストリームに適用するサービスクラスと回線リソース量を取得して前記リソース予約要求が作成され、前記ポリシーサーバに送信される。
【００１５】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記リソース予約手段は、前記バーチャル通信パスの残存リソース量に前記ストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行い、前記ストリームのサービスクラスおよび回線リソース量を前記バーチャル通信パスに確保する機能をさらに備えることを特徴とする。
【００１６】
この発明によれば、前記リソース予約手段によって、前記バーチャル通信パスの残存リソース量に前記ストリームの回線リソース量を収容できないと判断された場合には、前記バーチャル通信パスに回線リソース量の追加が行われ、前記ストリームのサービスクラスおよび回線リソース量が前記バーチャル通信パスに確保される。
【００１７】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記サービスクラスは、前記ストリームが前記ＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスをさらに含むことを特徴とする。
【００１８】
この発明によれば、前記サービスクラスに、前記ストリームが前記ＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスが含まれる。
【００１９】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記回線リソース量は、保証される回線リソースの量によってクラス付けされた回線リソース量クラスによって定義されており、前記リソース予約手段は、前記回線リソース量クラスに対応するリソース量に比べて残存リソース量が十分に大きいＬＳＰを、前記選択したバーチャル通信パスの中から選択する機能を備えることを特徴とする。
【００２０】
この発明によれば、前記回線リソース量は、保証される回線リソースの量によってクラス付けされた回線リソース量クラスによって定義される。また、前記リソース予約手段によって、前記回線リソース量クラスに対応するリソース量に比べて残存リソース量が十分に大きいＬＳＰが、前記選択したバーチャル通信パスの中から選択される。
【００２３】
つぎの発明にかかるネットワークポリシー制御システムは、複数のＬＳＲを備えるＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末におけるセッションの確立および送信されるストリームのポリシー制御を行うネットワークポリシー制御システムであって、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して格納する利用者情報データベースと、前記二つの端末間のＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記ＶＰＮ識別子に対応したセッションに送信するストリームに適用するサービスクラスと回線リソース量を前記利用者情報データベースから取得して前記リソース予約要求を作成し、ポリシーサーバに送信するリソース予約要求手段を備える呼制御装置と、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ＬＳＲに設定するバーチャル通信パス設定手段と、前記二つの端末間のセッションの確立時における前記呼制御装置からのリソース予約要求に対して、該セッションに送信されるストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、を含むポリシーサーバと、を備え、前記端末からのストリームを最初に受信した初段ＬＳＲは、前記ストリームのパケットに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子に適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００２４】
この発明によれば、利用者情報データベースと、呼制御装置と、ポリシーサーバとを備え、複数のＬＳＲを備えるＩＰコアネットワーク内の異なるＬＳＲに収容される二つの端末におけるセッションの確立および送信されるストリームのポリシー制御が行われるネットワークシステムにおいて、前記端末からのストリームを最初に受信した初段ＬＳＲによって、前記ストリームのパケットに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子に適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送される。ここで、利用者情報データベースには、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報がＶＰＮごとにＶＰＮ識別子を付して格納されている。また、呼制御装置にはリソース予約要求手段が備えられ、このリソース予約要求手段によって、前記二つの端末間のＶＰＮ識別子を含むセッション確立要求／応答が受信されると、前記ＶＰＮ識別子に対応したセッションに送信するストリームに適用するサービスクラスと回線リソース量が前記利用者情報データベースから取得され、前記リソース予約要求が作成され、そしてポリシーサーバに送信される。さらに、ポリシーサーバにはバーチャル通信パス定義手段と、バーチャル通信パス設定手段と、リソース予約手段とが備えられている。バーチャル通信パス設定手段によって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義される。バーチャル通信パス設定手段によって、定義されたバーチャル通信パスが前記ＬＳＲに設定される。リソース予約手段によって、前記二つの端末間のセッションの確立時における前記呼制御装置からのリソース予約要求に対して、該セッションに送信されるストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断された場合にはリソース予約が行われる。そして、前記端末からのストリームを最初に受信した初段ＬＳＲによって、前記ストリームのパケットに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子に適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送される。
【００２５】
つぎの発明にかかるネットワークポリシー制御システムは、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、前記異なるネットワークに存在する二つの端末間のセッションの確立を行う呼制御装置と、前記二つの端末間のストリームの送信制御を行う呼制御装置およびポリシーサーバとを備えるネットワークポリシー制御システムであって、前記ＶＰＮ内呼制御装置は、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子を取得し、前記セッション確立要求／応答に添付して転送する手段を備え、前記呼制御装置は、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答を受信すると、前記ストリームのリソース予約要求を前記ポリシーサーバに対して送信するリソース予約要求手段を備え、前記ポリシーサーバは、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ＬＳＲに設定するバーチャル通信パス設定手段と、前記ＶＰＮ内呼制御装置からの前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約を行うリソース予約手段と、を備え、前記端末を収容する初段ＬＳＲは、前記端末からのストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００２６】
この発明によれば、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、前記異なるネットワークに存在する二つの端末間のセッションの確立を行う呼制御装置と、前記二つの端末間のストリームの送信制御を行う呼制御装置およびポリシーサーバとを備えるネットワークポリシー制御システムにおいて、前記端末を収容する初段ＬＳＲによって、前記端末からのストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスが決定され、該バーチャル通信パスにしたがって前記ストリームが転送される。ここで、前記ＶＰＮ内呼制御装置によって、該ＶＰＮ内呼制御装置と収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答が受信されると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子が取得され、前記セッション確立要求／応答に添付して転送される。また、前記呼制御装置はリソース予約要求手段を備え、このリソース予約要求手段によって、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答が受信されると、前記ストリームのリソース予約要求が前記ポリシーサーバに対して送信される。さらに、前記ポリシーサーバは、バーチャル通信パス定義手段と、バーチャル通信パス設定手段と、リソース予約手段とを備えている。バーチャル通信パス定義手段によって、前記ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義される。バーチャル通信パス設定手段によって、該バーチャル通信パスが前記ＬＳＲに設定される。そして、リソース予約手段によって、前記ＶＰＮ内呼制御装置からの前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断された場合には、リソース予約が行われる。
【００２９】
つぎの発明にかかるネットワークポリシー制御システムは、複数のＬＳＲを備えるＩＰコアネットワークと、前記異なるＬＳＲに収容される二つの端末と、該二つの端末からのセッション確立要求／応答を前記ＩＰコアネットワーク内で最初に転送処理を行う副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバと、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースとを備えるネットワークポリシー制御システムであって、前記副呼制御装置は、セッション確立要求／応答を受信すると、もう一方の副呼制御装置に収容されている端末を送信先とするストリームに適用するサービスクラス／回線リソース量を前記利用者情報データベースから取得して、該セッション確立要求／応答に添付して転送する手段と、該副呼制御装置に関連付けされている前記副ポリシーサーバに対して、前記ストリームのリソース予約要求を送信する手段と、を備え、前記副ポリシーサーバは、該副ポリシーサーバに関連付けされている前記副呼制御装置から前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスを選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約を行うリソース予約手段を備え、一方の端末を送信先とするストリームのリソース予約処理が、前記ストリームの送信元側の端末に収容された副呼制御装置および副ポリシーサーバによって行われることを特徴とする。
【００３０】
この発明によれば、複数のＬＳＲを備えるＩＰコアネットワークと、前記異なるＬＳＲに収容される二つの端末と、該二つの端末からのセッション確立要求／応答を前記ＩＰコアネットワーク内で最初に転送処理を行う副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバと、前記ＬＳＲに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースとを備えるネットワークポリシー制御システムにおいて、一方の端末を送信先とするストリームのリソース予約処理が、前記ストリームの送信元側の端末に収容された副呼制御装置および副ポリシーサーバによって行われる。ここで、前記副呼制御装置は、セッション確立要求／応答を受信すると、もう一方の副呼制御装置に収容されている端末を送信先とするストリームに適用するサービスクラス／回線リソース量を前記利用者情報データベースから取得して、該セッション確立要求／応答に添付して転送する手段と、該副呼制御装置に関連付けされている前記副ポリシーサーバに対して、前記ストリームのリソース予約要求を送信する手段とを備える。また、前記副ポリシーサーバはリソース予約手段を備え、このリソース予約手段によって、該副ポリシーサーバに関連付けされている前記副呼制御装置から前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスが選択され、該選択されたバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約が行われる。
【００３１】
つぎの発明にかかるネットワークポリシー制御システムは、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、該ＶＰＮ内呼制御装置に収容される副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバとを備えるネットワークポリシー制御システムであって、前記ＶＰＮ内呼制御装置は、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子を取得し、前記セッション確立要求／応答に添付して転送する手段を備え、前記副呼制御装置は、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答を受信すると、前記ストリームのリソース予約要求を該副呼制御装置に関連付けされている前記副ポリシーサーバに対して送信するリソース予約要求手段を備え、前記副ポリシーサーバは、前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスを選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段を備え、前記端末を収容する前記ＬＳＲは、前記端末からの前記ストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とする。
【００３２】
この発明によれば、ＩＰコアネットワーク内の異なるＬＳＲに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、該ＶＰＮ内呼制御装置に収容される副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバとを備えるネットワークポリシー制御システムにおいて、前記端末を収容する前記ＬＳＲによって、前記端末からの前記ストリームに格納されている宛先アドレス、サービスクラスおよびＶＰＮ識別子と適合するバーチャル通信パスが決定され、該決定されたバーチャル通信パスにしたがって前記ストリームが転送される。ここで、前記ＶＰＮ内呼制御装置によって、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答が受信されると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子が取得され、前記セッション確立要求／応答に添付して転送される。また、前記副呼制御装置はリソース予約要求手段を備え、このリソース予約要求手段によって、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答が受信されると、前記ストリームのリソース予約要求が該副呼制御装置に関連付けされている前記副ポリシーサーバに対して送信される。さらに、前記副ポリシーサーバはリソース予約手段を備え、このリソース予約手段によって、前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスとＶＰＮ識別子に適合するバーチャル通信パスが選択され、該選択されたバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約が行われる。
【００３３】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記ネットワークポリシー制御システム内の前記副呼制御装置をまとめて管理する呼制御装置と、前記副ポリシーサーバをまとめて管理するポリシーサーバとを、さらに備えることを特徴とする。
【００３４】
この発明によれば、呼制御装置によって、前記ネットワークポリシー制御システム内の前記副呼制御装置がまとめて管理され、ポリシーサーバによって、前記副ポリシーサーバがまとめて管理される。
【００３５】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記副ポリシーサーバは、複数の副呼制御装置と関連付けすることが可能なことを特徴とする。
【００３６】
この発明によれば、前記副ポリシーサーバによって、複数の副呼制御装置が関連付けされる。
【００３７】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記副呼制御装置と前記副ポリシーサーバとを同一の装置内に備えることを特徴とする。
【００３８】
この発明によれば、前記副呼制御装置と前記副ポリシーサーバとが同一の装置内に備えられる。
【００３９】
つぎの発明にかかるネットワークポリシー制御システムは、上記の発明において、前記副呼制御装置と前記副ポリシーサーバとを同一の前記ＬＳＲ内に備えることを特徴とする。
【００４０】
この発明によれば、前記副呼制御装置と前記副ポリシーサーバとが同一の前記ＬＳＲ内に備えられる。
【００４１】
つぎの発明にかかるポリシーサーバは、複数のラベルスイッチングルータを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムに用いるポリシーサーバにおいて、前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるバーチャル通信パスが定義されるバーチャル通信パス定義手段と、該バーチャル通信パスを前記ラベルスイッチングルータに設定するバーチャル通信パス設定手段と、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、を備えることを特徴とする。
【００４２】
この発明によれば、バーチャル通信パス定義手段と、バーチャル通信パス設定手段と、リソース予約手段とを備えるポリシーサーバであって、複数のラベルスイッチングルータを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムに用いられるポリシーサーバが提供される。まず、バーチャル通信パス定義手段によって、前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるバーチャル通信パスが定義される。つぎに、バーチャル通信パス設定手段によって、該バーチャル通信パスが前記ラベルスイッチングルータに設定される。そして、リソース予約手段によって、前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスが前記バーチャル通信パス定義手段から選択され、該選択されたバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約が行われる。
【００４３】
つぎの発明にかかるポリシーサーバは、上記の発明において、前記バーチャル通信パス定義手段が、前記バーチャル通信パスにさらにＶＰＮごとの回線リソース量を定める機能を備えることを特徴とする。
【００４４】
この発明によれば、前記バーチャル通信パス定義手段によって、前記バーチャル通信パスにさらにＶＰＮごとの回線リソース量がさらに定められる。
【００４７】
【発明の実施の形態】
以下に、添付図面を参照して、この発明にかかるネットワークポリシー制御システムおよびこれに用いるポリシーサーバの好適な実施の形態について詳細に説明する。
【００４８】
実施の形態１．
図１は、この発明にかかるネットワークポリシー制御システムの実施の形態１を示す構成図である。このネットワークシステムは、呼制御装置（図１中では、ＣＡと表記）１と、ポリシーサーバ（同じく、ＰＳと表記）２と、利用者情報データベース（同じく、ＵＤＢと表記）３と、ＩＰコアネットワーク４内で音声ストリームのＭＰＬＳ（Multi Protocol Label Switching）によるルーティング処理を行うＬＳＲ４１〜４６と、ＬＳＲ４１に収容されるゲートウェイ装置（同じく、ＧＷと表記）５と、ＬＳＲ４４に収容されるゲートウェイ装置６と、ＬＳＲ４１に収容されるアクセスネットワーク７と、ＬＳＲ４４に収容されるアクセスネットワーク８と、アクセスネットワーク７に存在する端末９と、アクセスネットワーク８に存在する端末１０とを有している。
【００４９】
この実施の形態１にかかるネットワークポリシー制御システムにおいては、従来技術と同様に、ＬＳＰには複数のセッションストリーム（確立されたセッション上で転送されるパケット群のこと）を収容することができる。また、端末９、１０間のセッションを確立／制御するためのプロトコルとしては、セッションを確立する際に、発呼側が要求（以下、セッション確立要求という）を発行し、着呼側がそれに対して応答（以下、セッション確立応答という）を返す構成を有するＳＩＰ（Session Initiation Protocol）、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication sector）によって勧告されたＨ３２３、またはＳＳ７（Signaling System 7）のようなプロトコルを使用することができる。
【００５０】
つぎに、図１のネットワークシステムにおけるＬＳＲへのバーチャル通信パスを設定する処理手順について、図２のフローチャートを参照しながら説明する。まず、ネットワーク管理者によって、ポリシーサーバ２上で、ネットワーク利用者のサービスグレードを示す利用者情報が定義され（ステップＳ１）、該利用者情報が図３に示される利用者情報データベース３に保存される（ステップＳ２）。この利用者情報には、フロー識別情報（端末アドレス／アドレスマスク、トランスポートプロトコル種別、符号化手法等）、および該フローに適用するサービスグレードを示すＣｏＳ（Class of Service、サービスクラス）、必要回線リソース量が定義されている。
【００５１】
また、ポリシーサーバ２上で、初段ＬＳＲ、最終段ＬＳＲ、これらの初段ＬＳＲと最終段ＬＳＲとの間で必要な回線リソース量、およびＣｏＳを含むバーチャル通信パス情報が、ネットワーク管理者によって定義される（ステップＳ３）。この発明では、バーチャル通信パス情報から特定されるパスをバーチャル通信パスと呼ぶ。すなわち、バーチャル通信パスは［初段ＬＳＲ、最終段ＬＳＲ、ＣｏＳ］の組み合わせによって一意的に識別される。
【００５２】
ポリシーサーバ２はこれらの利用者情報とバーチャル通信情報からなる入力情報を記憶し、バーチャル通信パス情報から、実際にネットワークに設定する複数または単一のＬＳＰを決定する（ステップＳ４）。例えば、図１中で、バーチャル通信パスの初段ＬＳＲがＬＳＲ４１、最終段ＬＳＲがＬＳＲ４４と入力された場合には、「ＬＳＲ４１−ＬＳＲ４２−ＬＳＲ４３−ＬＳＲ４４」と、「ＬＳＲ４１−ＬＳＲ４６−ＬＳＲ４５−ＬＳＲ４４」という２つの経路のＬＳＰが、バーチャル通信パスの構成要素となることが考えられる。そして、ポリシーサーバ２は、これらのＬＳＰの中から、ネットワークトポロジデータベース（ＴＤＢ）を参照して最適なＬＳＰのセットを決定する機能を有している。なお、バーチャル通信パスを構成するこれらＬＳＰの回線リソース量の合計は、バーチャル通信パスの回線リソース量に一致するように決定される。
【００５３】
図４は、属性情報を含むバーチャル通信パスの構成例を示す図である。ここで、バーチャル通信パス識別子（ＶＩＤ）は、バーチャル通信パスを一意的に識別する識別子であり、ＬＳＰ識別子（ＬＳＰＩＤ）は、バーチャル通信パスに所属するＬＳＰを一意的に識別する識別子である。また、宛先アドレス／アドレスマスクはポリシーサーバ２がネットワークトポロジデータベースから取得するものであり、例えば、図１に示されるＬＳＲ４１を初段ＬＳＲとし、ＬＳＲ４４を最終段ＬＳＲとした場合のバーチャル通信パスの場合、宛先アドレス／アドレスマスクはアクセスネットワーク８の宛先アドレス／アドレスマスクとなる。以上で、ＬＳＲ４１〜４６へのＬＳＰの設定処理は終了する。
【００５４】
そして、ポリシーサーバ２は、ネットワーク管理者による操作にしたがって、これらのＬＳＰ群をＩＰコアネットワーク上の個々のＬＳＲ４１〜４６に設定する（ステップＳ５）。具体的には、ＬＳＰの初段ＬＳＲに対して、ＬＳＰに関する情報を通知し、ＩＥＴＦ（Internet Engineering Task Force）において検討されているＲＳＶＰ−ＴＥ（Resource ReSerVation Protocol for Traffic Engineering、ＲＦＣ（Request For Comments）３２０９）等のシグナリングプロトコルで設定するように要求する。この際、いずれかのバーチャル通信パスの初段ＬＳＲとなっているＬＳＲには、バーチャル通信パス識別子、リソース量、ＣｏＳ、宛先アドレス／アドレスマスク、およびＬＳＰ識別子を含むバーチャル通信パスの属性情報もあわせて設定される。
【００５５】
なお、ＬＳＰの設定において、初段ＬＳＲおよび最終段ＬＳＲとして設定された各ＬＳＰのＬＳＲ４１〜４６は、該ＬＳＰにおけるエッジＬＳＲとしての機能を有する。
【００５６】
つぎに、このシステムにおける発呼端末と着呼端末間のセッション確立からセッションストリームを送信するまでの手順について、図５〜図７のフローチャートを参照しながら説明する。ここでは、図１において、端末９が端末１０に対して発呼した場合を例に挙げて説明する。
【００５７】
まず、端末９はセッション確立要求を端末１０に対して送信する（ステップＳ１１）が、該セッション確立要求は端末１０へ送信される前に、呼制御装置１によって受信される（ステップＳ１２）。このセッション確立要求には、一般的に、セッションを一意的に識別するためのセッション識別子、発呼端末アドレス（端末９のアドレス）、着呼端末アドレス（端末１０のアドレス）、セッションストリームが使用するトランスポートプロトコル、トランスポートプロトコルのポート番号および符号化種別等が含まれる。なお、以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。
【００５８】
セッション確立要求を受信した呼制御装置１は、セッションの着呼端末１０から発呼端末９の方向のストリームについて、セッション確立要求の内容と利用者情報データベース３とを照合し、上記ストリームに適用するＣｏＳ／回線リソース量を取得する（ステップＳ１３）。例えば、着呼端末１０から発呼端末９の方向のストリームが図３に示される利用者情報データベース３の１番目のエントリに適合した場合には、呼制御装置１は転送優先度クラス＝１および廃棄優先度クラス＝２であるＣｏＳと、１０Ｍｂｐｓのリソース量を取得する。
【００５９】
そして、呼制御装置１は、セッション識別子、宛先端末アドレス、送信元端末アドレス、ＣｏＳおよびリソース量の情報を含むリソース予約要求をポリシーサーバ２に送信する（ステップＳ１４）。ここで、リソース予約要求に含まれる情報について説明すると、セッション識別子は、セッションを一意的に識別する識別子である。また、宛先端末アドレスは、リソース予約を行うストリームの宛先アドレスであり、この場合には、セッションの着呼端末１０から発呼端末９の方向のストリームに関するリソース予約であるので、宛先端末アドレスは発呼端末９のアドレスとなる。送信元端末は、リソース予約を行うストリームの送信元アドレスであり、この場合には、着呼端末１０のアドレスとなる。ＣｏＳは、利用者情報データベース３から取得したＣｏＳであり、リソース量は、同じく利用者情報データベース３から取得したリソース量である。
【００６０】
ポリシーサーバ２はリソース予約要求を受信する（ステップＳ３１）と、ネットワークトポロジデータベースから、上記リソース予約要求の送信元端末アドレス（すなわち、着呼端末１０のアドレス）を収容するＬＳＲ４４を導き出す（ステップＳ３２）。また、ポリシーサーバ２は、ＬＳＲ４４が初段ＬＳＲとなっているバーチャル通信パスの宛先アドレス／アドレスマスクおよびＣｏＳと、リソース予約要求に含まれる宛先端末アドレス（すなわち、発呼端末９のアドレス）およびＣｏＳとを照合し、一致するバーチャル通信パスを、上記セッションを収容するバーチャル通信パスとして決定する（ステップＳ３３）。
【００６１】
その後、ポリシーサーバ２は、合致するバーチャル通信パスに上記ストリームを収容することが可能であるかを判定する（ステップＳ３４）。すなわち、バーチャル通信パスの残存リソース量が十分で、上記ストリームで必要なリソース量を確保できる場合、または、バーチャル通信パスの残存リソース量は不十分であるが、バーチャル通信パス内のＬＳＰのリソース量の増加もしくは新規ＬＳＰの設定などの手段によって、リソース量の追加が可能である場合には、バーチャル通信パスに上記ストリームを収容可能であると判断する。ここで、バーチャル通信パス内のＬＳＰのリソース量を増加する設定や新規ＬＳＰの設定は、ＬＳＰの初段ＬＳＲに対して上述したシグナリングプロトコルによって行われる。
【００６２】
そして、ポリシーサーバ２は、バーチャル通信パスに上記ストリームが収容可能であると判断する（ステップＳ３４でＹｅｓの場合）と、そのバーチャル通信パスの残存リソース量から上記ストリームのリソース量を減算した該バーチャル通信パスの残存リソース量をバーチャル通信パスに関連付けて、セッション識別子と上記ストリームのリソース量と共に記憶する（ステップＳ３５）。その後、ポリシーサーバ２は、呼制御装置１にリソース予約応答（成功）を返送する（ステップＳ３６）。
【００６３】
一方、上述したステップＳ３４で、バーチャル通信パスに上記ストリームを収容不可能であるとポリシーサーバ２が判断する場合（ステップＳ３４でＮｏの場合）には、ポリシーサーバ２は呼制御装置１に対してリソース予約応答（失敗）を返送する（ステップＳ３７）。以上のステップＳ３１〜Ｓ３７で、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理が終了する。
【００６４】
呼制御装置１はポリシーサーバ２からリソース予約応答を受信する（ステップＳ１５）と、該リソース予約応答が成功か否かについて判断を行う（ステップＳ１６）。リソース予約応答が成功である場合（ステップＳ１６でＹｅｓの場合）には、上述したステップＳ１３で取得したＣｏＳ／回線リソース量をセッション確立要求に添付して、着呼端末１０へ転送する（ステップＳ１７）。
【００６５】
一方、リソース予約応答が失敗である場合（ステップＳ１６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された、発呼端末９にセッション確立応答失敗を通知するメッセージを送信するなどの失敗時のシーケンスを実行し（ステップＳ１９）、処理が終了する。
【００６６】
着呼端末１０は、呼制御装置１からセッション確立要求を受信する（ステップＳ１８）と、セッション確立要求に必要な変更を行ってセッション確立応答を作成し、該セッション確立応答を発呼端末９に対して、呼制御装置１経由で送信する（ステップＳ２０）。呼制御装置１は着呼端末１０からのセッション確立応答を受信すると（ステップＳ２１）、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームに適用するＣｏＳ／回線リソース量を利用者情報データベースから取得する（ステップＳ２２）。なお、このステップＳ２２における着呼端末１０から発呼端末９の方向のストリームのリソース予約確認については、セッション確立要求時に既に行っているが、着呼端末１０でセッション情報のネゴシエーションがなされているために、セッション確立応答時にも必要となる。そして、上記ストリームについてのリソース予約要求をポリシーサーバ２へ送信する（ステップＳ２３）。
【００６７】
ポリシーサーバ２におけるセッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のストリームに対するリソース予約確認は、上述した図７のステップＳ３１〜Ｓ３７と同様の処理によってなされる。すなわち、ポリシーサーバ２は、上記ストリームを収容するバーチャル通信パスを求め、該バーチャル通信パスに上記ストリームを収容することができる場合にはリソース予約応答（成功）を、収容できない場合にはリソース予約応答（失敗）を呼制御装置１に対して送信する。
【００６８】
その後、呼制御装置１がポリシーサーバ２からリソース予約応答を受信する（ステップＳ２４）と、呼制御装置１は該リソース予約応答が成功であるか否かについて判断する（ステップＳ２５）。リソース予約応答が成功であると判断された場合（ステップＳ２５でＹｅｓの場合）には、このリソース予約処理の過程で取得したセッションの発呼端末９から着呼端末１０への方向のストリームに適用するＣｏＳ／回線リソース量を、セッション確立応答に添付して発呼端末９へ転送する（ステップＳ２６）。
【００６９】
一方、リソース予約応答が失敗である場合（ステップＳ２５でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行し（ステップＳ２８）、処理が終了する。失敗時のシーケンスとして、例えば、呼制御装置１が着呼端末１０にセッション確立キャンセルメッセージを送信すると、着呼端末１０はこのメッセージに対して呼制御装置１に成功／失敗を通知し、そして、呼制御装置１は、発呼端末９に対してセッション確立応答失敗を通知するメッセージを送信する処理などが行われる。
【００７０】
発呼端末９はＣｏＳ／回線リソース量を添付したセッション確立応答を受信する（ステップＳ２７）と、発呼端末９と着呼端末１０との間にセッションが確立されたものと認識し、発呼端末９と着呼端末１０との間のセッション確立処理が終了する。
【００７１】
その後、発呼端末９は、発呼端末９と着呼端末１０との間にセッションが確立されたものと認識した後に、該セッションに着呼端末１０へストリームの送信を開始する。この際、ストリームを、セッション確立応答に含まれていたリソース量以下で転送し、ストリームを構成するパケットにはセッション確立応答に含まれていたＣｏＳを付加して転送する。このＣｏＳを設定するパケットのフィールドは、ＩＰｖ４ではＴｏＳフィールドに該当し、ＩＰｖ６ではＦｌｏｗＬａｂｅｌフィールドに該当する。
【００７２】
ＬＳＲ４１は、ゲートウェイ装置５を介して、発呼端末９からのストリームを構成するパケットを受信すると、自身に設定されているバーチャル通信パスの宛先アドレス／アドレスマスクおよびＣｏＳと、ストリームを構成するパケットの宛先アドレスおよびＣｏＳとを照合し、該ストリームを転送するためのバーチャル通信パスを決定する。このＬＳＲ４１が決定したバーチャル通信パスは、上述した図７のステップＳ３３でポリシーサーバ２が決定したバーチャル通信パスと一致するものである。
【００７３】
そして、ストリームのパケットを受信した初段ＬＳＲ４１は、セッションの確立時にリソースが確保されたバーチャル通信パスに該ストリームのパケットを転送する。ここで、バーチャル通信パスを構成するＬＳＰが単一である場合には、そのＬＳＰにストリームを転送する。また、バーチャル通信パスを構成するＬＳＰが複数である場合には、各ＬＳＰのリソース量を超えないように考慮してストリームを各ＬＳＰにスケジューリングしながら転送する。
【００７４】
一方、着呼端末１０は、上述したステップＳ１８でセッション確立要求を受信した段階において、発呼端末９と着呼端末１０との間にセッションが確立されたものと認識する。そして、上述した発呼端末９におけるストリームの送信手順と同様の処理方法によってストリームを構成するパケットの送信を開始する。
【００７５】
ストリームを構成するパケットを、ゲートウェイ装置６を介して、着呼端末１０から受信したＬＳＲ４４は上述したＬＳＲ４１と同様の転送処理方法によって、該ストリームを、バーチャル通信パスを構成するＬＳＰに転送する。このようにして、発呼端末９と着呼端末１０との間でストリームの送信が実現される。
【００７６】
上述したように、この実施の形態１によれば、初段ＬＳＲ、最終段ＬＳＲおよびＣｏＳが同じＬＳＰの集合をバーチャル通信パスと定義し、ポリシーサーバ２によってセッションに対するリソース予約がなされたバーチャル通信パスと、初段ＬＳＲ４１、４４によってストリームの宛先アドレスとＣｏＳとから求められたバーチャル通信パスとは必然的に一致するので、端末９、１０間のセッション確立ごとにポリシーサーバ２はエッジＬＳＲに対して逐一設定を行う必要がないという効果を奏する。また、エッジＬＳＲにおいて、ストリームのパケットごとに、該ストリームの転送を行うか否かを決めるフィルタリング処理が不用になり、エッジＬＳＲの負荷が軽減される。
【００７７】
実施の形態２．
つぎに、図８〜図１０を用いてこの発明の実施の形態２について説明する。この実施の形態２は、上述した実施の形態１において、ネットワーク管理者がＣｏＳを定義する際に、ＩＰコアネットワーク４にストリームが入力されてから出力されるまでにかかる遅延時間をクラス分けしてなる遅延クラスをさらに定義するものである。
【００７８】
図８は、遅延クラスのクラス分けの例を示す図であり、図９は、ＣｏＳに遅延クラスをさらに含めた利用者情報データベース３の構成例を示す図であり、そして図１０は、ＣｏＳに遅延クラスをさらに含めたバーチャル通信パスの構成例を示す図である。
【００７９】
図８の例では、遅延クラスは、最大遅延時間と最小遅延時間との組み合わせによって、１〜４の４段階にクラス分けされている。遅延クラス１は、最大遅延時間が１００ｍｓであり、最小遅延時間は０であり、最も遅延が許されない端末に対して設定される。また、遅延クラス２は、１００ｍｓ〜４００ｍｓの遅延時間であり、遅延クラス３は、４００ｍｓ〜１０００ｍｓの遅延時間であり、そして遅延クラス４は、１０００ｍｓ以上の遅延時間である。
【００８０】
図９に示される利用者情報データベース３は、図３に示される利用者情報データベース３のＣｏＳにおいて、さらに遅延クラスが付加されている。この遅延クラスは、図８に示される遅延クラスによって最大遅延時間と最小遅延時間が定義されている。
【００８１】
また、図１０に示されるバーチャル通信パスは、図４に示されるバーチャル通信パスのＣｏＳにおいて、さらに遅延クラスを属性として定義可能な構成としている。この遅延クラスも、図８に示される遅延クラスによって最大遅延時間と最小遅延時間が定義されている。この遅延クラスは、バーチャル通信パスを構成するＬＳＰの経路を決定する際に使用される。具体的には、ＬＳＰの遅延時間が遅延クラスに定義された最小遅延時間以上で最大遅延時間以下と計算される場合に、該ＬＳＰがバーチャル通信パスを構成するＬＳＰの経路として決定される。なお、遅延時間の計算方法としては、ポリシーサーバ２、エッジＬＳＲ４１、４４が、回線、ＬＳＲの遅延時間を含むネットワークトポロジデータベースから算出することによって行われる。
【００８２】
なお、ＣｏＳに遅延クラスが付加された場合も、実施の形態１の図２および図５〜図７で説明した手順によってセッション確立処理およびポリシー制御処理が行われる。
【００８３】
この実施の形態２によれば、ＩＰコアネットワーク４において遅延時間も考慮した利用者のサービスグレード付けが可能となる。
【００８４】
実施の形態３．
つぎに、図１１〜図１３を用いてこの発明の実施の形態３について説明する。この実施の形態３は、上述した実施の形態２で、ネットワーク管理者がＣｏＳを定義する際、ＩＰコアネットワーク４で保証されるリソース量をさらにクラス分けした回線リソース量クラスを定義するものである。
【００８５】
図１１は、回線リソース量クラスのクラス分けの例を示す図であり、そして図１２は、ＣｏＳに回線リソース量クラスをさらに含めた利用者情報データベース３の構成例を示す図である。なお、この回線リソース量クラスは、バーチャル通信パスに対して属性定義するものではない。
【００８６】
図１１の例では、回線リソース量クラスは、最大帯域と最低保証帯域と最大バーストサイズとの組み合わせによって、１〜４の４段階にクラス分けされている。回線リソース量クラス１は、最大帯域が６４ｋｂｐｓであり、最低保証帯域は８ｋｂｐｓであり、最大バーストサイズは８ｋｂｙｔｅであり、回線リソース量としては最も低いクラスとなっている。回線リソース量クラスの段階が上がるにつれ、内容は高い保証を与えるものとなっており、回線リソース量クラス４は、最大帯域が１６Ｍｂｐｓであり、最低保証帯域が８Ｍｂｐｓであり、最大バーストサイズは８ｋｂｙｔｅであり、回線リソース量としては最も高いクラスとなっている。なお、この回線リソース量クラスとリソース量の対応表は、利用者情報データベース３と、エッジＬＳＲ４１〜４６に設定される。
【００８７】
図１２に示される利用者情報データベース３は、図９に示される利用者情報データベース３の「ＣｏＳ」フィールドにおいて、さらに回線リソース量クラスが付加され、「リソース量」フィールドが削除された構成となっている。この「ＣｏＳ」フィールドの回線リソース量クラスは、上述した図１１に示される回線リソース量クラスによって規定されている。
【００８８】
この実施の形態３における発呼端末９から着呼端末１０へのセッション確立およびポリシー制御の処理手順は、上述した実施の形態１で説明した図５〜図７に示される処理と同様にして行われるので、説明は省略する。ただし、発呼端末９からセッション確立要求を受信した呼制御装置１が、着呼端末１０から発呼端末９のストリームについてのリソース予約確認処理を行う図５のステップＳ１３において、実施の形態１では、呼制御装置１は、セッション確立要求の内容に適合する利用者情報データベース３内のエントリから直接にリソース量を取得していたが、この実施の形態３では、呼制御装置１は、セッション確立要求の内容と利用者情報データベース３とを照合し、利用者情報データベース３内の合致するエントリのＣｏＳフィールドに回線リソース量クラスが定義されている場合に、図１１に示されるような回線リソース量クラスとリソース量の対応表からリソース量を取得する点が異なる。図６のステップＳ２２における発呼端末９から着呼端末１０の方向および着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理も同様である。
【００８９】
発呼端末９および着呼端末１０からストリームが送信された後のＬＳＲのストリームパケットの転送処理について図１３のフローチャートを参照しながら説明する。
【００９０】
発呼端末９から着呼端末１０へのセッションが確立されると、上述した実施の形態１の場合と同じように、発呼端末９および着呼端末１０はストリームの送信を開始する。このとき、バーチャル通信パスの初段ＬＳＲとなっているＬＳＲ４１およびＬＳＲ４４は、ストリームを受信する（ステップＳ４１）と、該ＬＳＲ４１、４４自身に設定されているバーチャル通信パスの宛先アドレス／アドレスマスクおよび回線リソース量クラスを除いたＣｏＳと、上記ストリームを構成するパケットの宛先アドレスおよび回線リソース量クラスを除いたＣｏＳとを照合し（ステップＳ４２）、上記ストリームを転送するためのバーチャル通信パスを決定する（ステップＳ４３）。例えば、図１２に示される情報がＬＳＲに設定されている場合では、転送優先度クラス＝１、廃棄優先度クラス＝２、遅延クラス＝３のバーチャル通信パスが決定される。
【００９１】
そして、図１１に示したような回線リソース量クラスとリソース量の対応表とストリームに含まれるＣｏＳの回線リソース量クラスからリソース量を取得する（ステップＳ４４）。その後、取得したＣｏＳにしたがって、上記ストリームに対するＱｏＳ制御を行う（ステップＳ４５）。
【００９２】
例えば、上記ストリームの回線リソース量クラスとして３が設定されている場合には、ＬＳＲ４１、４４は、図１１からその最低保証帯域１Ｍｂｐｓに比べて十分に大きい残存帯域を有するＬＳＰを、検索されたバーチャル通信パスの中からストリームの転送先として設定する。その後、設定したＬＳＰの残存帯域から最低保証帯域（１Ｍｂｐｓ）を減算する。そして、上記ストリームに対して最大帯域８Ｍｂｐｓでシェーピングを行い、１Ｍｂｐｓの最低保証帯域と８ｋｂｙｔｅの最大バーストサイズを保証する。
【００９３】
その後、ストリームの転送が設定したＬＳＰの間で所定期間行われない場合には、上記したストリームに対する回線リソース量をＬＳＰに確保する設定を解除する。すなわち、ＬＳＰの残存帯域に、上記設定時に減算した最低保証帯域（１Ｍｂｐｓ）を加算する。
【００９４】
以上のように、この実施の形態３によれば、回線リソース量を最大帯域、最低保証帯域および最大バーストサイズの組み合わせによってクラス分けして、ＣｏＳに定義することによって、バーチャル通信パスのエッジＬＳＲにおいて、一層きめ細かなストリームのＱｏＳ制御が可能となる。
【００９５】
実施の形態４．
つぎに、図１４〜図１７を用いてこの発明の実施の形態４について説明する。この実施の形態４は、ＩＰコアネットワークが複数のＶＰＮを収容する機能を有し、しかもＶＰＮごとのリソース管理を行うことが可能なネットワークポリシー制御システムを提供するものである。
【００９６】
図１４は、この発明にかかるネットワークポリシー制御システムの実施の形態４を示す構成図である。このネットワークシステムは、呼制御装置（図１４中では、ＣＡと表記）１と、ポリシーサーバ（同じく、ＰＳと表記）２と、ＩＰコアネットワーク４内でセッションストリームのＭＰＬＳによるルーティング処理を行うＬＳＲ４１〜４６と、ＬＳＲ４１に収容されるゲートウェイ装置（同じく、ＧＷと表記）５−１〜５−ｎと、ＬＳＲ４４に収容されるゲートウェイ装置６−１〜６−ｎと、ＬＳＲ４１に収容されるアクセスネットワーク７−１〜７−ｎと、ＬＳＲ４４に収容されるアクセスネットワーク８−１〜８−ｎと、アクセスネットワーク７−１に存在する端末９と、アクセスネットワーク８−１に存在する端末１０とを有している。
【００９７】
つぎに、ＩＰコアネットワーク４を介したＶＰＮを用いた通信におけるＶＰＮごとのリソース管理の処理方法について説明する。
【００９８】
ネットワーク管理者は、ポリシーサーバ２上でＬＳＰを定義すると共に、定義したＬＳＰをＩＰコアネットワーク４上に存在するＬＳＲ４１〜４６に設定する。このときの設定において、必要回線リソース量と宛先ネットワークとをＶＰＮごとに定義する。
【００９９】
ここで、端末９が端末１０に対して発呼した場合のセッション確立およびポリシー制御の処理手順について図１５〜図１６のフローチャートを参照しながら説明する。
【０１００】
端末９は、まずセッション確立要求を端末１０へ送信する（ステップＳ５１）が、該セッション確立要求は端末１０へ送信される前に、呼制御装置１によって受信される（ステップＳ５２）。このとき、端末９自身に設定されているＶＰＮ−ＩＤが、セッション確立要求に付加されて送信される。なお、以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。
【０１０１】
セッション確立要求を受信した呼制御装置１は、セッションの着呼端末１０から発呼端末９の方向のストリームについて、リソース予約処理を行う（ステップＳ５３）。このリソース予約処理は、呼制御装置１がポリシーサーバ２に対して、セッション識別子、発呼端末アドレス、着呼端末アドレス、上記ストリームに必要な回線リソース量、およびＶＰＮ−ＩＤを含む、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を送信することによって行われる。
【０１０２】
ポリシーサーバ２はリソース予約要求を受信する（ステップＳ７１）と、上記ストリームを収容するＬＳＰの候補を決定し（ステップＳ７２）、そのＬＳＰに上記ストリームを収容可能であるかを、ＬＳＰのＶＰＮに割り当てられたリソース量と上記ストリームに必要なリソース量とを比較することによって判定する（ステップＳ７３）。上記ストリームを収容するのに十分なリソース量を有するＬＳＰが存在する場合（ステップＳ７３でＹｅｓの場合）には、このＬＳＰに上記ストリームを転送するように該ＬＳＰの初段ＬＳＲ４４に設定し（ステップＳ７４）、リソース予約応答（成功）を呼制御装置１に返送する（ステップＳ７５）。
【０１０３】
一方、ステップＳ７３で、上記ストリームを収容するのに十分なリソース量を有するＬＳＰが存在しない場合（ステップＳ７３でＮｏの場合）には、リソース予約応答（失敗）を呼制御装置１に返送する（ステップＳ７６）。以上のポリシーサーバ２によるステップＳ７１〜Ｓ７６の処理工程で、上述したストリームに対するリソース予約処理が完了する。
【０１０４】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ５４）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ５５）。リソース予約応答が成功である場合（ステップＳ５５でＹｅｓの場合）には、呼制御装置１は、セッション確立要求を着呼端末１０へ転送する（ステップＳ５６）。一方、リソース予約応答が失敗である場合（ステップＳ５５でＮｏの場合）には、呼制御装置１はセッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ５７）。
【０１０５】
着呼端末１０は、呼制御装置１からセッション確立要求を受信する（ステップＳ５８）と、セッション確立応答を発呼端末９に対して返送する（ステップＳ５９）。しかし、この場合にも、セッション確立応答は、発呼端末９に送信される前に呼制御装置１によって受信される（ステップＳ６０）。
【０１０６】
呼制御装置１はセッション確立応答を受信すると、このセッション確立応答に含まれる情報を基に、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームに関するリソース予約要求をポリシーサーバ２へ送信し、リソース予約処理を行う（ステップＳ６１）。ポリシーサーバ２では、上述した図１７のステップＳ７１〜Ｓ７６でのリソース予約処理が行われ、リソース予約応答が呼制御装置１に対して送信される。
【０１０７】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ６２）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ６３）。リソース予約応答が成功である場合（ステップＳ６３でＹｅｓの場合）には、セッション確立応答を発呼端末９に転送する（ステップＳ６４）。そして発呼端末９は、セッション確立応答を受信し、セッションの確立処理が終了する。一方、ステップＳ６３でリソース予約応答が失敗である場合（ステップＳ６３でＮｏの場合）には、呼制御装置１はセッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ６６）。
【０１０８】
発呼端末９はセッション確立応答を受信すると、そして着呼端末１０はセッション確立要求を受信すると、セッションストリームの送信をそれぞれ開始する。セッションストリームはＬＳＲ４１、４４において、設定された情報に基づきＬＳＰに転送される。
【０１０９】
以上説明してきたように、この実施の形態４によれば、ＩＰコアネットワーク４においてＶＰＮごとのリソース管理を行うことが可能となる。
【０１１０】
実施の形態５．
つぎに、図１８〜図２４を用いてこの発明の実施の形態５について説明する。この実施の形態５は、ＩＰコアネットワークが複数のＶＰＮを収容する機能を持ち、しかもＶＰＮごとのリソース管理を行うことが可能なネットワークポリシー制御システムを提供するものである。
【０１１１】
図１８は、この発明にかかるネットワークポリシー制御システムの実施の形態５を示す構成図である。このネットワークポリシー制御システムでは、上述した実施の形態４の図１４において、さらに、利用者情報データベース（図１８中では、ＵＤＢと表記）３がさらに付加されたものであり、その他の構成については図１４と同一であるので、その説明は省略する。
【０１１２】
つぎに、ＩＰコアネットワーク４におけるＶＰＮごとのリソース管理の処理方法について説明する。
【０１１３】
図１８のネットワークシステムにおけるＬＳＲのバーチャル通信パスを設定する処理手順について、図１９のフローチャートを参照しながら説明する。まず、ネットワーク管理者によって、ポリシーサーバ２上で、ＶＰＮごとに利用者情報が入力され（ステップＳ８１）、該利用者情報が図２０に示される利用者情報データベース３に、ＶＰＮごとに保存される（ステップＳ８２）。この利用者情報データベースに格納される利用者情報は、基本的には実施の形態１の図３に示した利用者情報データベース３の構成と同じであるが、この実施の形態５の利用者情報データベース３は、フロー識別情報、ＣｏＳおよび必要回線リソース量などの複数の情報が、ＶＰＮごとに定義されている点が異なる。
【０１１４】
その後、ポリシーサーバ２上で、ネットワーク管理者によって、初段ＬＳＲ、最終段ＬＳＲ、必要回線リソース量およびＣｏＳを含むバーチャル通信パス情報が定義される（ステップＳ８３）。このバーチャル通信パスの定義は、上述した実施の形態１におけるバーチャル通信パスの定義方法と基本的には同じであるが、リソース量と宛先アドレス／アドレスマスクをＶＰＮごとに定義する必要がある。ポリシーサーバ２はこのバーチャル通信パス情報を記憶し、バーチャル通信パス情報から、実際にネットワークに設定する複数または単一のＬＳＰを決定し（ステップＳ８４）、このＬＳＰ群をネットワーク上の個々のＬＳＲ４１〜４６に設定する。
【０１１５】
図２１は、属性情報を含むバーチャル通信パスの構成例を示す図である。このバーチャル通信パスの構成は実施の形態１の図４に示されるバーチャル通信パスの構成と基本的には同じであるので、同じ構成を有する部分についての説明は省略する。実施の形態１の図４に示されるバーチャル通信パスの構成と異なるのはリソース量と宛先アドレス／アドレスマスクであり、これらはＶＰＮごとに定義されるようになっている。
【０１１６】
つぎに、このシステムにおける発呼端末と着呼端末との間にＶＰＮを確立し、セッションストリームを転送する場合の処理手順について図２２〜図２４のフローチャートを参照しながら説明する。
【０１１７】
まず、端末９は、自身に設定されているＶＰＮ−ＩＤを付加したセッション確立要求を端末１０に対して送信する（ステップＳ９１）が、該セッション確立要求は端末１０へ送信される前に、呼制御装置１によって受信される（ステップＳ９２）。なお、以下の説明では、端末９を発呼端末といい、端末１０を着呼端末という。
【０１１８】
ＶＰＮ−ＩＤが付加されたセッション確立要求を受信した呼制御装置１は、セッションの着呼端末１０から発呼端末９の方向のストリームについて、セッション確立要求に含まれるＶＰＮ−ＩＤを取得し、セッション確立要求の内容と利用者情報データベース３のＶＰＮの欄とを照合し、上記ストリームに適用するＶＰＮのＣｏＳ／回線リソース量を取得する（ステップＳ９３）。そして呼制御装置１は、これらを、セッション確立要求に含まれていた発呼端末アドレス、着呼端末アドレスおよびセッションを一意に識別する識別子（以下、セッション識別子という）と合わせて、セッションの着呼端末１０から発呼端末９の方向のストリームに関するリソース予約要求としてポリシーサーバ２に対して送信する（ステップＳ９４）。
【０１１９】
ポリシーサーバ２は、リソース予約要求を受信する（ステップＳ１１１）と、実施の形態１の図７に示されるステップＳ３２〜Ｓ３３と同様の方法で、バーチャル通信パスを検索する（ステップＳ１１２〜Ｓ１１３）。その後、バーチャル通信パスにセッションを収容することが可能であるかを判定する（ステップＳ１１４）。すなわち、バーチャル通信パスのＶＰＮに割り当てられた残存リソース量が十分である場合、または、バーチャル通信パスのＶＰＮに割り当てられた残存リソース量が不十分であるが、バーチャル通信パス内のＬＳＰのリソース量増加もしくは新規ＬＳＰの設定の手段によって、リソース量の追加が可能である場合には、ポリシーサーバ２は、バーチャル通信パスに上記ストリームを収容可能であると判断する（ステップＳ１１４でＹｅｓの場合）。そして、ポリシーサーバ２は、該バーチャル通信パスのＶＰＮに割り当てられた残存リソース量からセッションに必要なリソース量を減算し、バーチャル通信パスに関連付けてセッション識別子とそのリソース量を記憶する（ステップＳ１１５）。その後、呼制御装置１にリソース予約応答（成功）を返送する（ステップＳ１１６）。一方、ステップＳ１１４でバーチャル通信パスのＶＰＮに割り当てられた残存リソース量にセッションを収容することが不可能であると判断された場合（ステップＳ１１４でＮｏの場合）には、ポリシーサーバ２は、呼制御装置１にリソース予約応答（失敗）を返送する（ステップＳ１１７）。以上のステップＳ１１１〜Ｓ１１７で、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理が完了する。
【０１２０】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ９５）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ９６）。リソース予約応答が成功である場合（ステップＳ９６でＹｅｓの場合）には、呼制御装置１は、上記のステップＳ９３で取得したＣｏＳ／回線リソース量をセッション確立要求に添付して、着呼端末１０へ転送する（ステップＳ９７）。一方、リソース予約応答が失敗である場合（ステップＳ９６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ９８）。
【０１２１】
着呼端末１０は、セッション確立要求を受信する（ステップＳ９９）と、自身に設定されているＶＰＮ−ＩＤを付加したセッション確立応答を発呼端末９へ送信する（ステップＳ１００）が、該セッション確立応答は発呼端末９に受信される前に呼制御装置１によって受信される（ステップＳ１０１）。
【０１２２】
呼制御装置１はセッション確立応答を受信すると、セッション確立応答中のＶＰＮ−ＩＤを取得し、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームに対して、ＶＰＮのＣｏＳ／回線リソース量を取得する（ステップＳ１０２）。そして、呼制御装置１は、セッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のそれぞれのストリームについてのリソース予約要求をポリシーサーバ２へ送信し（ステップＳ１０３）、リソース予約確認処理を行う。ポリシーサーバ２によって行われるリソース予約確認処理は、上述した図２４のステップＳ１１１〜ステップＳ１１７での処理と同じであるので、説明を省略する。
【０１２３】
呼制御装置１は、ポリシーサーバ２からリソース予約応答を受信する（ステップＳ１０４）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１０５）。リソース予約応答が成功である場合（ステップＳ１０５でＹｅｓの場合）には、呼制御装置１は、上記のステップＳ１０２で取得したセッションの発呼端末９から着呼端末１０の方向のストリームに適用するＣｏＳおよびリソース量を添付して発呼端末９へ転送し（ステップＳ１０６）、発呼端末９はセッション確立応答を受信する（ステップＳ１０７）。一方、リソース予約応答が失敗である場合（ステップＳ１０５でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１０８）。
【０１２４】
このとき、上述した実施の形態１の場合と同様に、発呼端末９はセッション確立応答を受信すると、着呼端末１０はセッション確立要求を受信すると、それぞれセッションストリームの送信を開始する。
【０１２５】
発呼端末９から着呼端末１０へ送信されるストリームの初段ＬＳＲであるＬＳＲ４１は、発呼端末９からのセッションストリームを受信すると、実施の形態１の場合と同様に、セッションストリームを転送するバーチャル通信パスを決定する。そして、セッションストリームの受信インタフェース番号からＶＰＮ−ＩＤのラベルを求め、セッションストリームを構成する各パケットに、該ＶＰＮ−ＩＤのラベルをセカンドラベルとして設定する。なお、トップラベルには、転送するＬＳＰのラベルが設定される。この転送するＬＳＰは、実施の形態１と同様の手法で決定され、セッションストリームがＶＰＮ−ＩＤで定められるＶＰＮを介して転送される。
【０１２６】
一方、着呼端末１０から発呼端末９へ送信されるストリームの初段ＬＳＲであるＬＳＲ４４も、着呼端末１０からのセッションストリームを受信すると、上記したＬＳＲ４１の場合と同様の手順によって、セッションストリームがＬＳＰに転送される。
【０１２７】
以上のように、この実施の形態５によれば、端末９、１０間で確立されるセッションに対してサービスクラスのグレード付けを行ったバーチャル通信パス情報がポリシーサーバ２とともにＬＳＲ４１〜４６に設定されるので、セッション確立時のバーチャル通信パスに対するリソース予約はポリシーサーバ２が行い、セッションストリームの転送はバーチャル通信パスにしたがってＬＳＲ４１〜４６が自律的に行うように構成される。その結果、ポリシーサーバ２がセッション確立時にエッジＬＳＲ４１、４４に逐一設定を行う必要がなくなるので、ポリシーサーバ２の負荷を軽減することが可能となる。また、ＩＰコアネットワーク４においてＶＰＮごとのリソース管理を行うことが可能となる。
【０１２８】
実施の形態６．
つぎに、図２５〜図２８を用いてこの発明の実施の形態６について説明する。この実施の形態６は、アクセスネットワーク７−１〜７−ｎ、８−１〜８−ｎ内の端末９、１０がＩＰコアネットワーク４を経由したセッションを確立する際に、利用者情報等のＶＰＮ内の情報が外部に公開されないネットワーク構成を有するネットワークポリシー制御システムを提供するものである。
【０１２９】
図２５は、この発明にかかるネットワークポリシー制御システムの実施の形態６を示す構成図である。このネットワークシステムは、実施の形態４の図１４で説明したネットワークシステムに、さらに、ＶＰＮ内のポリシー制御を行うＶＰＮ内ポリシーサーバ（図２５中では、ＶＰＳと表記）２５と、ＶＰＮ内の利用者情報を格納するためのＶＰＮ内利用者情報データベース（同じく、ＶＵＤＢと表記）２３、２４と、ＶＰＮのアクセスネットワーク７−１〜７−ｎ、８−１〜８−ｎを収容したＶＰＮ内呼制御装置（同じく、ＶＣＡと表記）２１、２２とを備える構成となっている。
【０１３０】
ここで、ＶＰＮの管理者は、利用者情報を外部に公開されることを欲しないシステム利用者の利用者情報をＶＰＮ内ポリシーサーバ２５上で定義し、該定義した利用者情報をＶＰＮのそれぞれのアクセスネットワークに備えられているＶＰＮ内利用者情報データベース２３、２４に設定する。また、ＶＰＮ内呼制御装置２１、２２には、該ＶＰＮ内呼制御装置２１、２２自身が担当するＶＰＮのＶＰＮ−ＩＤが設定されている。図２５の例では、アクセスネットワーク７−１内の端末９とアクセスネットワーク８−１内の端末１０との間にＶＰＮ１を設定する場合であるので、ＶＰＮ内呼制御装置２１、２２には、ＶＰＮ−ＩＤとして「１」が設定されることになる。
【０１３１】
つぎに、このシステムにおける発呼端末と着呼端末との間のＶＰＮを用いたセッション確立の手順について図２６〜図２８のフローチャートを参照しながら説明する。ここでは、図２５において、アクセスネットワーク７−１内の端末９が、アクセスネットワーク８−１内の端末１０に対して発呼して、ＶＰＮを確立する場合を例に挙げて説明する。
【０１３２】
端末９は、セッション確立要求を端末１０に対して送信する（ステップＳ１２０）。該セッション確立要求は、まず、ＶＰＮ内呼制御装置２１によって受信される（ステップＳ１２１）。ＶＰＮ内呼制御装置２１は、セッション確立要求を受信すると、該セッション確立要求の内容とアクセスネットワーク７−１内のＶＰＮ内利用者情報データベース２３とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立要求に含めて転送する（ステップＳ１２２）。なお、以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。
【０１３３】
呼制御装置１は、ＶＰＮ内呼制御装置２１からセッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤが添付されたセッション確立要求を受信する（ステップＳ１２３）と、該セッション確立要求に含まれている情報を用いて着呼端末１０から発呼端末９への方向のストリームに対するリソース予約要求を生成し、ポリシーサーバ２に対して送信する（ステップＳ１２４）。そして、セッションの着呼端末１０から発呼端末９の方向のストリームに対して、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明したリソース予約確認処理を行う。
【０１３４】
呼制御装置１はポリシーサーバ２からリソース予約応答を受信する（ステップＳ１２５）と、該リソース予約応答が成功か否かを判断する（ステップＳ１２６）。リソース予約応答（成功）である場合（ステップＳ１２６でＹｅｓの場合）には、セッション確立要求を転送する（ステップＳ１２７）。一方、リソース予約応答（失敗）である場合（ステップＳ１２６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１２８）。
【０１３５】
着呼端末１０は、ＶＰＮ内呼制御装置２２を経由して、セッション確立要求を受信する（ステップＳ１２９）と、セッション確立応答を端末９に対して返信する（ステップＳ１３０）。
【０１３６】
ＶＰＮ内呼制御装置２２は、着呼端末１０からのセッション確立応答を受信する（ステップＳ１３１）と、セッション確立応答の内容とアクセスネットワーク８−１内のＶＰＮ内利用者情報データベース２４とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立応答に含めて転送する（ステップＳ１３２）。
【０１３７】
呼制御装置１は、ＶＰＮ内呼制御装置２２からセッション確立応答を受信する（ステップＳ１３３）と、該セッション確立応答に含まれている情報からセッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のストリームに対するリソース予約要求を生成し、リソース予約要求をポリシーサーバ２へ送信する（ステップＳ１３４）。ポリシーサーバ２は、このセッションの発呼端末９から着呼端末１０の方向／着呼端末１０から発呼端末９の方向のストリームに対して、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明したリソース予約確認処理を行う。
【０１３８】
呼制御装置１はポリシーサーバ２からリソース予約応答を受信する（ステップＳ１３５）と、該リソース予約応答が成功か否かを判断する（ステップＳ１３６）。リソース予約応答（成功）である場合（ステップＳ１３６でＹｅｓの場合）には、セッション確立応答を転送する（ステップＳ１３７）。一方、リソース予約応答（失敗）である場合（ステップＳ１３６でＮｏの場合）には、呼制御装置１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行して（ステップＳ１３８）、セッション確立処理が終了する。
【０１３９】
発呼端末９は、ＶＰＮ内呼制御装置２１を経由して、セッション確立応答を受信し（ステップＳ１３９）、発呼端末９と着呼端末１０との間にＶＰＮが確立される。
【０１４０】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、セッションストリームの送信をそれぞれ開始する。ＬＳＲ４１、４４でのセッションストリームの転送方法については、上述した実施の形態５と同様であるので説明を省略する。
【０１４１】
以上で説明したように、この実施の形態６によれば、ＶＰＮ内利用者情報データベースを各ＶＰＮのアクセスネットワーク内に設けたので、利用者情報が外部に公開されることがなく、利用者情報の管理に安全性が保たれる。また、ＶＰＮごとにＩＤ番号（識別子）を付すので、端末ごとにＶＰＮ−ＩＤを設定する必要がなく、ＶＰＮの管理が容易になるという効果がある。
【０１４２】
実施の形態７．
つぎに、図２９〜図３３を用いてこの発明の実施の形態７について説明する。この実施の形態７は、大規模なネットワークにおける呼数の増大に対する呼制御装置、ポリシーサーバおよびエッジＬＳＲとの間における過大な負荷を分散することが可能なネットワークポリシー制御システムおよびその方法を提供するものである。
【０１４３】
図２９は、この発明にかかるネットワークポリシー制御システムの実施の形態７を示す構成図である。このネットワークシステムは、実施の形態１の図１で説明したネットワークシステムに、さらに、エッジＬＳＲ４１、４４を制御する副ポリシーサーバ３３、３４と、該副ポリシーサーバ３３、３４に関連付けされている副呼制御装置３１、３２とを備える構成となっている。その他の構成については、図１と同一であるので、その説明を省略している。
【０１４４】
副呼制御装置３１、３２は、エッジＬＳＲであるＬＳＲ４１、４４が収容するアクセスネットワーク７、８内の端末９、１０が発行したセッション確立要求／応答をＩＰコアネットワーク４内で最初に中継する呼制御装置である。そして、それぞれの副呼制御装置３１、３２に対して、副ポリシーサーバ３３、３４が設置されている。なお、呼制御装置１は、複数存在する副呼制御装置３１、３２を管理し、ポリシーサーバ２は、複数存在する副ポリシーサーバに対してＩＰコアネットワーク４内の複数の副呼制御装置３１、３２と関連付けを行うなどの複数の副ポリシーサーバ３３、３４の管理を行っている。
【０１４５】
つぎに、ＩＰコアネットワーク４におけるＶＰＮごとのリソース管理の処理方法について説明する。
【０１４６】
図２９のネットワークシステムにおけるＬＳＲのＬＳＰを設定する処理手順について、図３０〜図３３のフローチャートを参照しながら説明する。ここで、端末９が端末１０に対して発呼した場合の動作を例に挙げて説明する。
【０１４７】
端末９は、セッション確立要求を端末１０に対して送信する（ステップＳ１４１）が、該セッション確立要求は、副呼制御装置３１および呼制御装置１を経由して、副呼制御装置３２によって受信される（ステップＳ１４２）。副呼制御装置３２は、受信したセッション確立要求に含まれる情報を基に、セッションの端末１０から端末９の方向のストリームについて、セッション識別子、発呼端末アドレス、着呼端末アドレスおよび上記ストリームに必要な回線リソース量を含むリソース予約要求を副ポリシーサーバ３４に対して送信する（ステップＳ１４３）。以下の説明では、端末９を発呼端末と呼び、端末１０を着呼端末１０と呼ぶ。
【０１４８】
副ポリシーサーバ３４はリソース予約要求を受信する（ステップＳ１７１）と、上記ストリームを収容するＬＳＰの候補を決定し（ステップＳ１７２）、そのＬＳＰに上記ストリームを収容可能であるかを、ＬＳＰのリソース量と上記ストリームに必要なリソース量とを比較することによって判定する（ステップＳ１７３）。ＬＳＰが十分なリソース量を有する場合（ステップＳ１７３でＹｅｓの場合）には、副ポリシーサーバ３４は、そのＬＳＰに上記ストリームを転送するようにＬＳＰの初段ＬＳＲ（図２９の場合ではＬＳＲ４４）に設定し（ステップＳ１７４）、リソース予約応答（成功）を副呼制御装置３２に返送する（ステップＳ１７５）。一方、ＬＳＰが十分なリソース量を有しない場合（ステップＳ１７３でＮｏの場合）には、副ポリシーサーバ３４はリソース予約応答（失敗）を副呼制御装置３２に返送する（ステップＳ１７６）。以上のステップＳ１７１〜Ｓ１７６で上述した副ポリシーサーバ３４によるリソース予約処理が完了する。
【０１４９】
副呼制御装置３２は、リソース予約応答を受信する（ステップＳ１４４）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１４５）。リソース予約応答（成功）である場合（ステップＳ１４５でＹｅｓの場合）には、セッション確立要求を着呼端末１０に転送する（ステップＳ１４６）。一方、リソース予約応答（失敗）である場合（ステップＳ１４５でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１４７）。
【０１５０】
着呼端末１０はセッション確立要求を受信する（ステップＳ１４８）と、発呼端末９に対して、セッション確立応答を返送する（ステップＳ１４９）。
【０１５１】
セッション確立応答は、まず、副呼制御装置３２によって受信され（ステップＳ１５０）、副呼制御装置３２はセッション確立応答に含まれる情報を基に、上記セッション確立要求受信時と同様に、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を副ポリシーサーバ３４に送信する（ステップＳ１５１）。
【０１５２】
副ポリシーサーバ３４は、副呼制御装置３２からリソース予約要求を受信すると、上述した図３３のステップＳ１７１〜Ｓ１７６で説明したリソース予約確認処理を行い、リソース予約応答を副呼制御装置３２に対して送信する。
【０１５３】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ１５２）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１５３）。リソース予約応答（成功）である場合（ステップＳ１５３でＹｅｓの場合）には、セッション確立応答を転送する（ステップＳ１５４）。一方、リソース予約応答（失敗）である場合（ステップＳ１５３でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１５５）。
【０１５４】
副呼制御装置３２から送信されたセッション確立応答は、呼制御装置１を経由して、副呼制御装置３１によって、受信される（ステップＳ１５６）。副呼制御装置３１は、セッション確立応答に含まれる情報を基に、セッションの発呼端末９から着呼端末１０方向のストリームについてのリソース予約要求を副ポリシーサーバ３３に送信する（ステップＳ１５７）。
【０１５５】
副ポリシーサーバ３３は、副呼制御装置３１からリソース予約要求を受信すると、上述した図３３のステップＳ１７１〜Ｓ１７６で説明したリソース予約確認処理と同様にして発呼端末９から着呼端末１０方向のストリームについてのリソース予約処理を行い、リソース予約応答を副呼制御装置３１に対して送信する。
【０１５６】
副呼制御装置３１はリソース予約応答を受信する（ステップＳ１５８）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ１５９）。リソース予約応答（成功）である場合（ステップＳ１５９でＹｅｓの場合）には、発呼端末９に対してセッション確立応答を転送し（ステップＳ１６０）、発呼端末９は、セッション確立応答を受信する（ステップＳ１６１）。一方、リソース予約応答（失敗）である場合（ステップＳ１５９でＮｏの場合）には、副呼制御装置３１はセッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１６２）。
【０１５７】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、発呼端末９および着呼端末１０はそれぞれセッションストリームの送信を開始する。ここで、セッションストリームはＬＳＲ４１、４４において、上述した工程で設定された情報に基づいてＬＳＰに転送される。
【０１５８】
以上で説明したように、この実施の形態７によれば、セッション確立要求に伴うリソース予約確認処理が副呼制御装置、副ポリシーサーバで処理され、処理の負荷が分散されるので、呼数の増大に対しても対応することができるという効果がある。
【０１５９】
実施の形態８．
つぎに、図３４〜図３８を用いてこの発明の実施の形態８について説明する。この実施の形態８は、大規模なネットワークにおける呼数の増大に対する呼制御装置、ポリシーサーバおよびエッジＬＳＲとの間における過大な負荷を分散することが可能なネットワークポリシー制御方法を提供するものである。
【０１６０】
図３４は、この発明にかかるネットワークポリシー制御システムの実施の形態８を示す構成図である。このネットワークシステムは、実施の形態７の図２９で説明したネットワークシステムにおいて、利用者情報データベース３５、３６が、副呼制御装置３１、３２ごとに設けられている構成となっている。その他の構成については、図２９と同一であるので、その説明を省略している。
【０１６１】
このシステムにおいて、ネットワーク管理者は、実施の形態１と同様に、ポリシーサーバ２上で利用者情報を利用者情報データベース３５、３６に保存する。ただし、この利用者情報データベース３５、３６は副呼制御装置３１、３２に対応する形で設置されている。
【０１６２】
ここで、図３４のネットワークシステムにおけるＬＳＲ４１〜４６のＬＳＰを設定する処理手順について、図３５〜図３８のフローチャートを参照しながら説明する。ここで、端末９が端末１０に対して発呼した場合の動作を例に挙げて説明する。
【０１６３】
まず、端末９は、端末１０に対してセッション確立要求を送信する（ステップＳ１８１）。該セッション確立要求は、副呼制御装置３１および呼制御装置１を介して、副呼制御装置３２によって受信される（ステップＳ１８２）。副呼制御装置３２は、セッション確立要求の内容と利用者情報データベース３６とを照合し、セッションの着呼端末１０から発呼端末９の方向のストリームに適用するＣｏＳ／回線リソース量を取得し（ステップＳ１８３）、そして、副ポリシーサーバ３４に対して着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を送信する（ステップＳ１８４）。
【０１６４】
副ポリシーサーバ３４は、上述した実施の形態１の図７のステップＳ３１〜Ｓ３７で説明したリソース予約確認処理と同様にして、着呼端末１０から発呼端末９の方向のストリームについてのリソース予約処理を行い、リソース予約応答を副呼制御装置３２に対して送信する。
【０１６５】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ１８５）と、該リソース予約応答が成功であるか否かを判断する（ステップＳ１８６）。リソース予約応答（成功）である場合（ステップＳ１８６でＹｅｓの場合）には、セッション確立要求を着呼端末１０に対して転送する（ステップＳ１８７）。一方、リソース予約応答（失敗）である場合（ステップＳ１８６でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１８８）。
【０１６６】
着呼端末１０は副呼制御装置３２からセッション確立要求を受信する（ステップＳ１８９）と、セッション確立応答を発呼端末に対して返送する（ステップＳ１９０）。
【０１６７】
副呼制御装置３２はセッション確立応答を受信する（ステップＳ１９１）と、セッション確立応答の内容と利用者情報データベース３６とを照合し、セッションの着呼端末１０から発呼端末９の方向のストリームに適用するＣｏＳ／回線リソース量を取得し（ステップＳ１９２）、そして、副ポリシーサーバ３４に対して着呼端末１０から発呼端末９の方向のストリームについてのリソース予約要求を送信する（ステップＳ１９３）。なお、着呼端末１０から発呼端末９の方向のリソース予約処理は既に行われているが、着呼端末１０におけるセッション確立要求受信およびセッション確立応答返送時に、セッション情報のネゴシエーションがなされているために、ここでも着呼端末１０から発呼端末９の方向のリソース予約処理が行われている。
【０１６８】
副ポリシーサーバ３４は、副呼制御装置３２からリソース予約要求を受信すると、上述した実施の形態１の図７のステップＳ３１〜Ｓ３７で説明した処理と同様にして、着呼端末１０から発呼端末９の方向のリソース予約確認処理を行い、リソース予約応答を副呼制御装置３２に対して送信する。
【０１６９】
副呼制御装置３２は副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ１９４）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ１９５）。リソース予約応答（成功）である場合（ステップＳ１９５でＹｅｓの場合）には、セッション確立応答を転送する（ステップＳ１９６）。一方、リソース予約応答（失敗）である場合（ステップＳ１９５でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ１９７）。
【０１７０】
副呼制御装置３２から送信されたセッション確立応答は、呼制御装置１を介して、副呼制御装置３１によって受信される（ステップＳ１９８）。セッション確立応答を受信した副呼制御装置３１は、セッション確立応答の内容と利用者情報データベース３５とを照合し、セッションの発呼端末９から着呼端末１０の方向のストリームに適用するＣｏＳ／回線リソース量を取得し（ステップＳ１９９）、そして、副ポリシーサーバ３３に対してセッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約要求を送信する（ステップＳ２００）。
【０１７１】
副ポリシーサーバ３３は、副呼制御装置３１からリソース予約要求を受信すると、上述した実施の形態１の図７のステップＳ３１〜Ｓ３７で説明した処理と同様にして、セッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約確認処理を行い、リソース予約応答を副呼制御装置３１に対して送信する。
【０１７２】
副呼制御装置３１はリソース予約応答を受信する（ステップＳ２０１）と、該リソース予約応答が成功であるか否かについて判断する（ステップＳ２０２）。リソース予約応答（成功）である場合（ステップＳ２０２でＹｅｓの場合）には、セッション確立応答を発呼端末９に対して転送し（ステップＳ２０３）、発呼端末９はセッション確立応答を受信する（ステップＳ２０４）。一方、リソース予約応答（失敗）である場合（ステップＳ２０２でＮｏの場合）には、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２０５）。
【０１７３】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、発呼端末９および着呼端末１０はそれぞれセッションストリームの送信を開始する。また、セッションストリームのＬＳＲにおける転送方法については、実施の形態１と同様なのでその説明を省略する。
【０１７４】
以上説明してきたように、この実施の形態８によれば、端末９、１０間で確立されるセッションに対してサービスクラスのグレード付けを行ったバーチャル通信パス情報がポリシーサーバ２とともにＬＳＲ４１〜４６に設定されるので、セッション確立時のバーチャル通信パスに対するリソース予約はポリシーサーバ２が行い、セッションストリームの転送はバーチャル通信パスにしたがってＬＳＲ４１〜４６が自律的に行うように構成される。その結果、ポリシーサーバ２がセッション確立時にエッジＬＳＲ４１、４４に逐一設定を行う必要がなくなるので、ポリシーサーバ２の負荷を軽減することが可能となる。また、エッジＬＳＲにおいて、セッションストリームごとのフィルタリングが不用なためその分の負荷も軽減される。さらに、セッション確立要求に伴うリソース予約確認処理が副呼制御装置、副ポリシーサーバで処理されるため、それらで行われる処理の負荷が分散されるという効果がある。
【０１７５】
実施の形態９．
つぎに、図３９〜図４３を用いてこの発明の実施の形態９について説明する。この実施の形態９は、アクセスネットワーク７−１〜７−ｎ、８−１〜８−ｎ内の端末９、１０がＩＰコアネットワーク４を経由したセッションを確立する際に、利用者情報等のＶＰＮ内の情報が外部に公開されないネットワーク構成を有すると共に、大規模なネットワークにおける呼数の増大に対する呼制御装置、ポリシーサーバおよびエッジＬＳＲとの間における過大な負荷を分散することが可能なネットワークポリシー制御システムを提供するものである。
【０１７６】
図３９は、この発明にかかるネットワークポリシー制御システムの実施の形態９を示す図である。このネットワークシステムは、実施の形態６の図２５で説明したネットワークシステムにおいて、さらに、エッジＬＳＲ４１、４４を制御する副ポリシーサーバ３３、３４と、該副ポリシーサーバ３３、３４と関連付けされている副呼制御装置３１、３２とを備える構成となっている。これらの装置は実施の形態８の図３４で示したものと同一であるので、また、その他の構成については図２５で示したものと同一であるので、その説明を省略している。なお、呼制御装置１は、複数存在する副呼制御装置３１、３２を管理し、ポリシーサーバ２は、複数存在する副ポリシーサーバ３３、３４を管理している。
【０１７７】
ここで、図３９のネットワークシステムにおけるＶＰＮの確立手順について、図４０〜図４３のフローチャートを参照しながら説明する。ここで、端末９が端末１０に対して発呼した場合の動作を例に挙げて説明する。
【０１７８】
端末９は、端末１０に対してセッション確立要求を送信する（ステップＳ２１０）。以下、端末９を発呼端末と呼び、端末１０を着呼端末と呼ぶ。該セッション確立要求は、まず、ＶＰＮ内呼制御装置２１によって受信される（ステップＳ２１１）。ＶＰＮ内呼制御装置２１は、セッション確立要求を受信すると、該セッション確立要求の内容とアクセスネットワーク７−１内のＶＰＮ内利用者情報データベース２３とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立要求に含めて転送する（ステップＳ２１２）。
【０１７９】
送信されたセッション確立要求は、副呼制御装置３１と呼制御装置１を介して、副呼制御装置３２によって受信される（ステップＳ２１３）。副呼制御装置３２は、セッション確立要求を受信すると、該セッション確立要求に含まれている情報から、セッションの着呼端末１０から発呼端末９の方向のストリームに対してリソース予約要求を生成し、副ポリシーサーバ３４に対して送信する（ステップＳ２１４）。そして、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明した処理と同様にして、副ポリシーサーバ３４は、セッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理を行う。ただし、図５では、ポリシーサーバ２が処理を行っているが、この実施の形態９では、ステップＳ１１１〜Ｓ１１７の処理は副呼制御装置３２に関連付けされている副ポリシーサーバ３４によって行われる。
【０１８０】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ２１５）と、該リソース予約応答が成功であるか否かについての判断を行う（ステップＳ２１６）。リソース予約応答（成功）である場合（ステップＳ２１６でＹｅｓの場合）には、副呼制御装置３２は、セッション確立要求を転送する（ステップＳ２１７）。一方、リソース予約応答（失敗）である場合（ステップＳ２１６でＮｏの場合）には、呼制御装置は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２１８）。
【０１８１】
副呼制御装置３２によって転送されたセッション確立要求は、ＶＰＮ内呼制御装置２２を介して、着呼端末１０によって受信される（ステップＳ２１９）。セッション確立要求を受信した着呼端末１０は、セッション確立応答を発呼端末９に対して返送する（ステップＳ２２０）。
【０１８２】
着呼端末１０によって送信されたセッション確立応答は、ＶＰＮ内呼制御装置２２によって受信される（ステップＳ２２１）。ＶＰＮ内呼制御装置２２は、セッション確立応答を受信すると、該セッション確立要求の内容とアクセスネットワーク８−１内のＶＰＮ内利用者情報データベース２４とを照合し、セッションストリームに適用するＣｏＳ／回線リソース量およびＶＰＮ−ＩＤを取得し、これらの情報をセッション確立要求に含めて転送する（ステップＳ２２２）。
【０１８３】
副呼制御装置３２はセッション確立応答を受信する（ステップＳ２２３）と、セッション確立応答に含まれる情報からセッションの着呼端末１０から発呼端末９の方向のストリームに対してリソース予約要求を生成し、副ポリシーサーバ３４にリソース予約要求を送信して、リソース予約確認処理を行う（ステップＳ２２４）。そして、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明した処理と同様にして、副ポリシーサーバ３４はセッションの着呼端末１０から発呼端末９の方向のストリームについてのリソース予約確認処理を行う。ただし、図５では、ポリシーサーバ２が処理を行っているが、ここでの処理は、副呼制御装置３２に関連付けされている副ポリシーサーバ３４によって行われる。
【０１８４】
副呼制御装置３２は、副ポリシーサーバ３４からリソース予約応答を受信する（ステップＳ２２５）と、該リソース予約応答が成功であるか否かについて判断を行う（ステップＳ２２６）。リソース予約応答（成功）である場合（ステップＳ２２６でＹｅｓの場合）には、副呼制御装置３２はセッション確立応答を転送する（ステップＳ２２７）。一方、リソース予約応答（失敗）である場合（ステップＳ２２６でＮｏの場合）には、副呼制御装置３２は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２２８）。
【０１８５】
副呼制御装置３２によって送信されたセッション確立応答は、呼制御装置１を介して、副呼制御装置３１によって受信される（ステップＳ２２９）。副呼制御装置３１は、セッション確立応答を受信すると、セッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約要求を生成し、副ポリシーサーバ３３へリソース予約要求を送信して、リソース予約確認処理を行う（ステップＳ２３０）。そして、実施の形態５の図２４のステップＳ１１１〜Ｓ１１７で説明した処理と同様にして、セッションの発呼端末９から着呼端末１０の方向のストリームについてのリソース予約確認処理が行われる。ただし、図５では、ポリシーサーバ２が処理を行っているが、ここでの処理は、副呼制御装置３１に関連付けされている副ポリシーサーバ３３によって行われる。
【０１８６】
副呼制御装置３１は、副ポリシーサーバ３３からリソース予約応答を受信する（ステップＳ２３１）と、該リソース予約応答が成功であるか否かについて判断を行う（ステップＳ２３２）。リソース予約応答（成功）である場合（ステップＳ２３２でＹｅｓの場合）には、副呼制御装置３１はセッション確立応答を転送する（ステップＳ２３３）。一方、リソース予約応答（失敗）である場合（ステップＳ２３２でＮｏの場合）には、副呼制御装置３１は、セッション制御プロトコルで規定された失敗時のシーケンスを実行する（ステップＳ２３４）。
【０１８７】
そして、副呼制御装置３１によって送信されたセッション確立応答は、ＶＰＮ内呼制御装置２１を介して、発呼端末９によって受信される（ステップＳ２３５）。
【０１８８】
以上の工程において、発呼端末９はセッション確立応答を受信すると、そして、着呼端末１０はセッション確立要求を受信すると、発呼端末９および着呼端末１０はそれぞれセッションストリームの送信を開始する。また、セッションストリームのＬＳＲにおける転送方法については、実施の形態１と同様なのでその説明を省略する。
【０１８９】
以上で説明したように、この実施の形態９によれば、ＶＰＮ内利用者情報データベースを各ＶＰＮのアクセスネットワーク内に設けたので、利用者情報が外部に公開されることがなく、利用者情報の管理に安全性が保たれる。また、ＶＰＮごとにＩＤ番号を付すので、端末ごとにＶＰＮ−ＩＤを設定する必要がないという効果がある。その結果、ＶＰＮの管理が容易になる。さらに、セッションに対してサービスグレード付けを行い、かつセッション確立ごとにエッジＬＳＲに逐一設定を行うことなく、ＩＰコアネットワークにおいてセッションストリームのためのリソースを確保可能かについて判定することが可能となる。また、エッジＬＳＲにおいて、セッションストリームごとのＬＳＰの設定やフィルタリングが不用なためその分の負荷も軽減される。さらに、セッション確立要求に伴うリソース予約確認処理が副呼制御装置、副ポリシーサーバで処理されるため、それらで行われる処理の負荷が分散されるという効果がある。
【０１９０】
なお、以上で説明した実施の形態において、副呼制御装置３１、３２とそれに関連付けられている副ポリシーサーバ３３、３４およびエッジＬＳＲ４１、４４は、別個の装置であるかのように記載したが、副呼制御装置３１、３２と副ポリシーサーバ３３、３４は、例えばソフトウェアといった処理単位に相当するので、副呼制御装置３１、３２と副ポリシーサーバ３３、３４を同一装置内で動作させるように構成したり、副呼制御装置３１、３２と副ポリシーサーバ３３、３４をエッジＬＳＲ４１、４４内で動作させるように構成したりすることも可能である。
【０１９１】
【発明の効果】
以上説明したように、この発明によれば、ＩＰコアネットワーク内における初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定されるＬＳＰをまとめてバーチャル通信パスとして定義するように構成したので、ポリシーサーバはバーチャル通信パスの単位でのみポリシー管理を行うことができる。また、ポリシーサーバはセッションに送信されるストリームについてのバーチャル通信パスのリソース予約を行うだけであり、ＬＳＲに対するセッション確立時の設定処理を行う必要がない。その結果、ポリシーサーバの負荷を減らすことができる。さらに、初段ＬＳＲとなるＬＳＲは、受信したストリームのパケットから得られたサービスクラスと宛先アドレスからバーチャル通信パスを選択し、該バーチャル通信パスにストリームを転送する処理だけを行う。そして、従来では必要だった、該ＬＳＲによる受信したストリームのフィルタリング処理を行う必要がないので、ストリームの転送処理の高速化を図ることが可能となる。
【０１９２】
つぎの発明によれば、サービスを利用する端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースを備えるように構成したので、利用者単位でサービスクラスの設定を行うことができ、利用者に応じたサービスを提供することができる。
【０１９３】
つぎの発明によれば、ポリシーサーバは、選択したバーチャル通信パスの残存リソース量がストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行って、前記ストリームのサービスクラスおよび回線リソース量を確保する機能を有するリソース予約手段を備えるように構成したので、多数のセッションが確立され、同じバーチャル通信パス内を転送されるストリームの量が多くなっても、自動的に該バーチャル通信パスの回線リソース量を増加させることによって、利用者に対するサービスの品質を維持することができる。
【０１９４】
つぎの発明によれば、サービスクラスにＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスを備えるように構成したので、利用者に対して一層多様な種類のサービスを提供することができる。
【０１９５】
つぎの発明によれば、回線リソース量は、保証される回線リソース量によってクラス付けされた回線リソース量クラスによって定義されるように構成したので、ストリームを最初に受信する初段ＬＳＲは、該回線リソース量クラスによって前記ストリームに対して一層きめ細かなＱｏＳ制御を行うことができる。
【０１９７】
つぎの発明によれば、初段ＬＳＲ、最終段ＬＳＲおよびサービスクラスの組み合わせで特定され、一以上のＬＳＰから構成されるとともに、ＶＰＮごとの回線リソース量が定められるバーチャル通信パスがポリシーサーバとＬＳＲに設定されるように構成されるので、ポリシーサーバはセッションに送信されるストリームについてのバーチャル通信パスのリソース予約を行うだけで、ＬＳＲに対してセッション確立時に設定を行う必要がない。また、ポリシーサーバは、ＩＰコアネットワークにおいて、ＶＰＮごとのリソース管理を行うことが可能となる。さらに、ＬＳＲは、受信したストリームのパケットから得られたサービスクラスと宛先アドレスとＶＰＮ識別子とからバーチャル通信パスを選択し、該バーチャル通信パスにストリームを転送するだけでよく、従来必要であった受信したストリームのフィルタリング処理を行う必要がなくなるので、ストリームの転送処理の高速化を図ることが可能となる。
【０１９８】
つぎの発明によれば、利用者の端末が属するネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付してそれぞれのネットワークごとに格納するＶＰＮ内利用者情報データベースをＶＰＮ内部に備えるように構成したので、利用者情報データベースの外部からの不正な侵入を抑制し、ＶＰＮの安全性を高めることができる。また、ポリシーサーバは、ネットワークに存在する端末ごとにＶＰＮ識別子を設定する必要がないので、ポリシーサーバの処理を軽減することが可能となる。
【０２００】
つぎの発明によれば、副ポリシーサーバは、選択したバーチャル通信パスの残存リソース量がストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行って、前記ストリームのサービスクラスおよび回線リソース量を確保する機能を有するリソース予約手段を備えるように構成したので、多数のセッションが確立され、同じバーチャル通信パス内を転送されるストリームの量が多くなっても、自動的に該バーチャル通信パスの回線リソース量を増加させることができる。その結果、品質を落とすことなく利用者にサービスを提供することが可能となる。また、副呼制御装置と副ポリシーサーバとを備えるように構成したので、ネットワークが大規模になった場合に増大するセッション確立の処理を、一台の呼制御装置とポリシーサーバで行うのではなく、同じ機能を有する複数の副呼制御装置と副ポリシーサーバで実行するので、処理の負荷を分散することが可能となる。
【０２０１】
つぎの発明によれば、利用者の端末が属するネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付してそれぞれのネットワークごとに格納するＶＰＮ内利用者情報データベースをＶＰＮ内部に備えるように構成したので、利用者情報データベースの外部からの不正な侵入を抑制し、ＶＰＮの安全性を高めることができる。また、副呼制御装置と副ポリシーサーバとを備えるように構成したので、ネットワークが大規模になった場合に増大するセッション確立の処理を、一台の呼制御装置とポリシーサーバで行うのではなく、同じ機能を有する複数の副呼制御装置と副ポリシーサーバで実行するので、処理の負荷を分散することが可能となる。
【０２０２】
つぎの発明によれば、副呼制御装置を呼制御装置で管理し、副ポリシーサーバをポリシーサーバで管理するように構成したので、それぞれの副呼制御装置および副ポリシーサーバにおける役割の分担を行うことができ、システム全体での処理の効率化を図ることが可能となる。
【０２０３】
つぎの発明によれば、副ポリシーサーバは複数の副呼制御装置と関連付けできるように構成したので、システム上における副ポリシーサーバの配置を、その負荷の程度を考慮して自由に設計することができる。
【０２０４】
つぎの発明によれば、副呼制御装置と副ポリシーサーバとを同一の装置内に備えるように構成したので、システム内に設置する装置の数を抑えて、システム構成の複雑化を抑制することができる。
【０２０５】
つぎの発明によれば、副呼制御装置と副ポリシーサーバとを同一の前記ＬＳＲ内に備えるように構成したので、システム内に設置する装置の数を抑えて、システム構成の複雑化を抑制することができる。
【０２０６】
つぎの発明によれば、ポリシーサーバは、選択したバーチャル通信パスの残存リソース量がストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行って、前記ストリームのサービスクラスおよび回線リソース量を確保する機能を有するリソース予約手段を備えるように構成したので、多数のセッションが確立され、同じバーチャル通信パス内を転送されるストリームの量が多くなっても、自動的に該バーチャル通信パスの回線リソース量を増加させることによって、利用者に対するサービスの品質を維持することができる。
【０２０７】
つぎの発明によれば、ポリシーサーバのバーチャル通信パス定義手段は、バーチャル通信パスにさらにＶＰＮごとの回線リソース量を定める機能を備えるように構成したので、ＩＰコアネットワークを介して通信を行うネットワーク間にＶＰＮを構築することが可能となる。
【図面の簡単な説明】
【図１】 この発明にかかるネットワークポリシー制御システムの実施の形態１の構成を示すブロック図である。
【図２】 バーチャル通信パスの設定手順を示すフローチャートである。
【図３】 利用者情報データベースの構成の一例を示す図である。
【図４】 属性情報を含むバーチャル通信パスの構成例を示す図である。
【図５】 発呼端末と着呼端末との間におけるセッション確立の処理手順を示すフローチャートである（その１）。
【図６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図８】 この発明の実施の形態２で用いるサービスクラス（ＣｏＳ）の遅延クラスのクラス分けの一例を示す図である。
【図９】 利用者情報データベースの構成の一例を示す図である。
【図１０】 属性情報を含むバーチャル通信パスの構成例を示す図である。
【図１１】 この発明の実施の形態３における回線リソース量のクラス分けの一例を示す図である。
【図１２】 利用者情報データベースの構成の一例を示す図である。
【図１３】 バーチャル通信パスの設定手順を示すフローチャートである。
【図１４】 この発明にかかるネットワークポリシー制御システムの実施の形態４の構成を示すブロック図である。
【図１５】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図１６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図１７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図１８】 この発明にかかるネットワークポリシー制御システムの実施の形態５の構成を示すブロック図である。
【図１９】 バーチャル通信パスの設定手順を示すフローチャートである。
【図２０】 利用者情報データベースの構成の一例を示す図である。
【図２１】 属性情報を含むバーチャル通信パスの構成例を示す図である。
【図２２】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図２３】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図２４】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図２５】 この発明にかかるネットワークポリシー制御システムの実施の形態６の構成を示すブロック図である。
【図２６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図２７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図２８】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図２９】 この発明にかかるネットワークポリシー制御システムの実施の形態７の構成を示すブロック図である。
【図３０】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図３１】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図３２】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図３３】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その４）。
【図３４】 この発明にかかるネットワークポリシー制御システムの実施の形態８の構成を示すブロック図である。
【図３５】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図３６】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図３７】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図３８】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その４）。
【図３９】 この発明にかかるネットワークポリシー制御システムの実施の形態９の構成を示すブロック図である。
【図４０】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その１）。
【図４１】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その２）。
【図４２】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その３）。
【図４３】 発呼端末と着呼端末との間におけるセッションの確立処理手順を示すフローチャートである（その４）。
【図４４】 ＭＰＬＳ／ＩＰネットワーク上におけるＶｏＩＰストリームのＱｏＳの保証を行うシステムの従来例を示すブロック図である。
【符号の説明】
１ 呼制御装置、２ ポリシーサーバ、３，３５，３６ 利用者情報データベース、４ ＩＰコアネットワーク、５，６ ゲートウェイ、７，８ アクセスネットワーク、９，１０ 端末、２１，２２ ＶＰＮ内呼制御装置、２３，２４ ＶＰＮ内利用者情報データベース、２５ ＶＰＮ内ポリシーサーバ、３１，３２副呼制御装置、３３，３４ 副ポリシーサーバ、４１〜４６ ラベルスイッチングルータ。
Claims (15)
- 複数のラベルスイッチングルータを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムであって、
前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるバーチャル通信パスが定義されるバーチャル通信パス定義手段と、
該バーチャル通信パスを前記ラベルスイッチングルータに設定するバーチャル通信パス設定手段と、
前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、
を含むポリシーサーバをさらに備え、
前記端末からのストリームを最初に受信した初段ラベルスイッチングルータは、前記ストリームのパケットに格納されている宛先アドレスおよびサービスクラスに適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とするネットワークポリシー制御システム。 - 前記ラベルスイッチングルータに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースをさらに備え、
前記呼制御装置は、前記二つの端末間のセッション確立要求／応答を受信すると、前記利用者情報から取得した前記セッションのストリームに適用するサービスクラスと回線リソース量を取得して前記リソース予約要求を作成し、前記ポリシーサーバに送信するリソース予約要求手段を備えることを特徴とする請求項１に記載のネットワークポリシー制御システム。 - 前記リソース予約手段は、前記バーチャル通信パスの残存リソース量に前記ストリームの回線リソース量を収容できないと判断した場合には、前記バーチャル通信パスに回線リソース量の追加を行い、前記ストリームのサービスクラスおよび回線リソース量を前記バーチャル通信パスに確保する機能をさらに備えることを特徴とする請求項１または２に記載のネットワークポリシー制御システム。
- 前記サービスクラスは、前記ストリームが前記ＩＰコアネットワークの入力から出力までにかかる遅延時間をクラス付けした遅延クラスをさらに含むことを特徴とする請求項１〜３のいずれか一つに記載のネットワークポリシー制御システム。
- 前記回線リソース量は、保証される回線リソースの量によってクラス付けされた回線リソース量クラスによって定義されており、
前記リソース予約手段は、前記回線リソース量クラスに対応するリソース量に比べて残存リソース量が十分に大きいラベルスイッチパスを、前記選択したバーチャル通信パスの中から選択する機能を備えることを特徴とする請求項１〜４のいずれか一つに記載のネットワークポリシー制御システム。 - 複数のラベルスイッチングルータを備えるＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末におけるセッションの確立および送信されるストリームのポリシー制御を行うネットワークポリシー制御システムであって、
前記ラベルスイッチングルータに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して格納する利用者情報データベースと、
前記二つの端末間のＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記ＶＰＮ識別子に対応したセッションに送信するストリームに適用するサービスクラスと回線リソース量を前記利用者情報データベースから取得して前記リソース予約要求を作成し、ポリシーサーバに送信するリソース予約要求手段を備える呼制御装置と、
前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義されるバーチャル通信パス定義手段と、
該バーチャル通信パスを前記ラベルスイッチングルータに設定するバーチャル通信パス設定手段と、
前記二つの端末間のセッションの確立時における前記呼制御装置からのリソース予約要求に対して、該セッションに送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、
を含むポリシーサーバと、
を備え、前記端末からのストリームを最初に受信した初段ラベルスイッチングルータは、前記ストリームのパケットに格納されている宛先アドレスおよびサービスクラスに適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とするネットワークポリシー制御システム。 - ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、前記異なるネットワークに存在する二つの端末間のセッションの確立を行う呼制御装置と、前記二つの端末間のストリームの送信制御を行う呼制御装置およびポリシーサーバとを備えるネットワークポリシー制御システムであって、
前記ＶＰＮ内呼制御装置は、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子を取得し、前記セッション確立要求／応答に添付して転送する手段を備え、
前記呼制御装置は、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答を受信すると、前記ストリームのリソース予約要求を前記ポリシーサーバに対して送信するリソース予約要求手段を備え、
前記ポリシーサーバは、
前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるとともに、ＶＰＮごとの回線リソース量が定められているバーチャル通信パスが定義されるバーチャル通信パス定義手段と、
該バーチャル通信パスを前記ラベルスイッチングルータに設定するバーチャル通信パス設定手段と、
前記ＶＰＮ内呼制御装置からの前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約を行うリソース予約手段と、
を備え、
前記端末を収容する初段ラベルスイッチングルータは、前記端末からのストリームに格納されている宛先アドレスおよびサービスクラスと適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とするネットワークポリシー制御システム。 - 複数のラベルスイッチングルータを備えるＩＰコアネットワークと、前記異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末を収容し該二つの端末からのセッション確立要求／応答を前記ＩＰコアネットワーク内で最初に転送処理を行う副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバと、前記ラベルスイッチングルータに収容される端末の端末アドレス、サービスクラスおよび回線リソース量を含む利用者情報を格納する利用者情報データベースとを備えるネットワークポリシー制御システムであって、
前記副呼制御装置は、
セッション確立要求／応答を受信すると、もう一方の副呼制御装置に収容されている端末を送信先とするストリームに適用するサービスクラス／回線リソース量を前記利用者情報データベースから取得して、該セッション確立要求／応答に添付して転送する手段と、
該副呼制御装置に関連付けされている前記副ポリシーサーバに対して、前記ストリームのリソース予約要求を送信する手段と、
を備え、
前記副ポリシーサーバは、該副ポリシーサーバに関連付けされている前記副呼制御装置から前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスを選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合には、リソース予約を行うリソース予約手段を備え、
一方の端末を送信先とするストリームのリソース予約処理が、前記ストリームの送信元側の端末に収容された副呼制御装置および副ポリシーサーバによって行われることを特徴とするネットワークポリシー制御システム。 - ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容されるネットワークと、前記ネットワークのアドレス、サービスクラスおよび回線リソース量を含む利用者情報をＶＰＮごとにＶＰＮ識別子を付して、それぞれのネットワークごとに格納しＶＰＮ内に設置されるＶＰＮ内利用者情報データベースと、前記異なるネットワークのそれぞれに収容されるＶＰＮ内呼制御装置と、該ＶＰＮ内呼制御装置に収容される副呼制御装置と、該副呼制御装置のそれぞれに関連付けされている副ポリシーサーバとを備えるネットワークポリシー制御システムであって、
前記ＶＰＮ内呼制御装置は、該ＶＰＮ内呼制御装置に収容されるネットワーク内の端末からＶＰＮ識別子を含むセッション確立要求／応答を受信すると、前記端末の属するネットワークに設けられた前記ＶＰＮ内利用者情報データベースの前記利用者情報から、前記ＶＰＮ識別子に対応した前記ストリームに適用するサービスクラス／回線リソース量およびＶＰＮ識別子を取得し、前記セッション確立要求／応答に添付して転送する手段を備え、
前記副呼制御装置は、前記ＶＰＮ内呼制御装置から前記サービスクラス／回線リソース量およびＶＰＮ識別子が添付されたセッション確立要求／応答を受信すると、前記ストリームのリソース予約要求を該副呼制御装置に関連付けされている前記副ポリシーサーバに対して送信するリソース予約要求手段を備え、
前記副ポリシーサーバは、前記リソース予約要求に対して、前記ストリームの送信元および宛先端末のアドレスとサービスクラスに適合するバーチャル通信パスを選択し、該選択したバーチャル通信パスの該当するＶＰＮの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段を備え、
前記端末を収容する前記ラベルスイッチングルータは、前記端末からの前記ストリームに格納されている宛先アドレスおよびサービスクラスと適合するバーチャル通信パスを決定し、該バーチャル通信パスにしたがって前記ストリームを転送することを特徴とするネットワークポリシー制御システム。 - 前記ネットワークポリシー制御システム内の前記副呼制御装置をまとめて管理する呼制御装置と、前記副ポリシーサーバをまとめて管理するポリシーサーバとを、さらに備えることを特徴とする請求項８または９に記載のネットワークポリシー制御システム。
- 前記副ポリシーサーバは、複数の副呼制御装置と関連付けすることが可能なことを特徴とする請求項８〜１０のいずれか一つに記載のネットワークポリシー制御システム。
- 前記副呼制御装置と前記副ポリシーサーバとを同一の装置内に備えることを特徴とする請求項８または９に記載のネットワークポリシー制御システム。
- 前記副呼制御装置と前記副ポリシーサーバとを同一の前記ラベルスイッチングルータ内に備えることを特徴とする請求項８または９に記載のネットワークポリシー制御システム。
- 複数のラベルスイッチングルータを備えるＩＰコアネットワークと、該ＩＰコアネットワーク内の異なるラベルスイッチングルータに収容される二つの端末と、該二つの端末間でのセッションの確立処理を行う呼制御装置とを備えるネットワークポリシー制御システムに用いるポリシーサーバにおいて、
前記ＩＰコアネットワーク内における初段ラベルスイッチングルータ、最終段ラベルスイッチングルータおよびサービスクラスの組み合わせで特定され、一以上のラベルスイッチパスから構成されるバーチャル通信パスが定義されるバーチャル通信パス定義手段と、
該バーチャル通信パスを前記ラベルスイッチングルータに設定するバーチャル通信パス設定手段と、
前記二つの端末間のセッション確立時における前記呼制御装置からのリソース予約要求に対して、該セッションで送信されるストリームの送信元および宛先端末のアドレスとサービスクラスに基づき前記ストリームを収容するバーチャル通信パスを前記バーチャル通信パス定義手段から選択し、該選択したバーチャル通信パスの残存リソース量に前記ストリームのリソース量を収容可能と判断した場合にはリソース予約を行うリソース予約手段と、
を備えることを特徴とするポリシーサーバ。 - 前記バーチャル通信パス定義手段は、前記バーチャル通信パスにさらにＶＰＮごとの回線リソース量を定める機能を備えることを特徴とする請求項１４に記載のポリシーサーバ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002059404A JP3993445B2 (ja) | 2002-03-05 | 2002-03-05 | ネットワークポリシー制御システムおよびこれに用いるポリシーサーバ |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002059404A JP3993445B2 (ja) | 2002-03-05 | 2002-03-05 | ネットワークポリシー制御システムおよびこれに用いるポリシーサーバ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003258857A JP2003258857A (ja) | 2003-09-12 |
| JP3993445B2 true JP3993445B2 (ja) | 2007-10-17 |
Family
ID=28669113
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002059404A Expired - Fee Related JP3993445B2 (ja) | 2002-03-05 | 2002-03-05 | ネットワークポリシー制御システムおよびこれに用いるポリシーサーバ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3993445B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100527682C (zh) * | 2003-11-12 | 2009-08-12 | 株式会社日立制作所 | 会话QoS控制装置 |
| US20050147035A1 (en) * | 2003-12-24 | 2005-07-07 | Nortel Networks Limited | Multiple services with policy enforcement over a common network |
| US8578441B2 (en) | 2004-07-22 | 2013-11-05 | Hewlett-Packard Development Company, L.P. | Enforcing network security policies with packet labels |
| CN100544466C (zh) * | 2005-02-02 | 2009-09-23 | 华为技术有限公司 | 实现按键即说业务的蜂窝系统及方法 |
| JP4818186B2 (ja) * | 2007-04-12 | 2011-11-16 | Ｋｄｄｉ株式会社 | ネットワークシステム、資源割り当て方法及び資源割り当てプログラム |
| JP4924485B2 (ja) * | 2008-03-06 | 2012-04-25 | Ｋｄｄｉ株式会社 | ネットワークリソースを管理する品質管理制御装置、通信制御方法およびコンピュータプログラム |
| JP4461192B1 (ja) | 2009-04-10 | 2010-05-12 | 株式会社東芝 | 電子機器および通信制御方法 |
| JP2014155095A (ja) * | 2013-02-12 | 2014-08-25 | Oki Electric Ind Co Ltd | 通信制御装置、プログラム及び通信制御方法 |
| CN114157600A (zh) * | 2020-09-07 | 2022-03-08 | 华为技术有限公司 | 一种转发报文的方法、设备和系统 |
-
2002
- 2002-03-05 JP JP2002059404A patent/JP3993445B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003258857A (ja) | 2003-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7606914B2 (en) | Session QoS control apparatus | |
| KR100461728B1 (ko) | 라우터를 통한 ＤｉｆｆＳｅｒｖ 기반 ＶｏＩＰ ＱｏＳ제공 방법 | |
| US6970930B1 (en) | Method and system of providing differentiated services | |
| US7830886B2 (en) | Router and SIP server | |
| US8588238B2 (en) | Method and apparatus for self-learning of VPNS from combinations of unidirectional tunnels in MPLS/VPN networks | |
| US8254265B2 (en) | Methods and apparatus for routing IP media data based on cost | |
| US7522591B2 (en) | Policy settable peer-to-peer session apparatus | |
| EP1751919B1 (en) | Method and apparatus for dynamically determining when to use quality of service reservation in internet media applications | |
| US8542580B2 (en) | Method and system for transporting service flow securely in an IP network | |
| US20030227907A1 (en) | Apparatus for providing QoS of VoIP traffic on IP router and forwarding method therefor | |
| US20060291447A1 (en) | Virtual circuits in packet networks | |
| US20070074281A1 (en) | Presence-base packet routing control apparatus and packet routing control method | |
| WO2009057005A2 (en) | Topology discovery in heterogeneous networks | |
| JP3993445B2 (ja) | ネットワークポリシー制御システムおよびこれに用いるポリシーサーバ | |
| Adami et al. | Towards an SDN network control application for differentiated traffic routing | |
| US20120163381A1 (en) | Multiple Label Based Processing of Frames | |
| US10212197B2 (en) | Method for setting up a communication link | |
| WO2007140694A1 (fr) | Procédé pour obtenir un réseau de télécommunication à protocole internet et système correspondant | |
| Cisco Systems, Inc | Internetworking technologies handbook | |
| Ikram | Traffic Engineering with MPLS and QOS | |
| Chaieb et al. | A Routing Architecture for MPLS-TE Networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050223 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070320 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070515 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070703 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070724 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070726 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100803 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |