【課題】トラヒック制御を適切に行うことを課題とする。
【解決手段】統合ＡＡＡ装置は、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成された場合に、該経路上の装置を監視することにより該装置からトラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する。また、統合ＡＡＡ装置は、取得した情報が予め定められた条件に該当すると判定した場合に、経路上のトラヒックを制御するための指示情報を、該経路を形成する装置に対して送信する。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法に関する。
【背景技術】
【０００２】
近年、複数の拠点間を拠点間接続することで協働空間を提供するサービスが登場した。特に、オンデマンド（on−demand）なサービス、すなわち、要求に応じて時限的に拠点間接続するサービスに対する要望が高い。ここで、「拠点」とは、ＶＰＮ（Virtual Private Network）や地理的条件などによって到達性を制限され孤立しているネットワークドメインのことである。また、「拠点間接続」とは、ある拠点の端末から送信されたパケットをある拠点の端末に対して転送するための情報を該拠点間の経路上に存在する各機器に設定することで、拠点間を通信可能に相互接続することである。また、「協働空間」とは、拠点間接続により生じたネットワークドメインのことであり、相互接続された範囲を新たな到達可能範囲とするネットワークドメインのことである。
【０００３】
ところで、拠点間接続においては、一般に、トラヒック制御が行われると考えられる。例えば、広域ネットワークを介して複数のＶＰＮ間を接続するＶＰＮ間接続においては、広域ネットワーク内のパケット転送を制御する集合仮想ルータに各ＶＰＮが収容され、集合仮想ルータは、１組の経路情報として設定された１つの経路により、１つのＶＰＮ間接続に関するパケットを転送する。このような場合に、例えば、集合仮想ルータは、１つのＶＰＮ間接続に対して、品質保証などのトラヒック制御を行うことができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】小山 高明、唐澤 秀一、岸 和宏、水野 伸太郎、岩村 相哲、「ＶＰＮ間接続管理システムの提案」、信学技報ＩＮ２００９−４８（２００９−０９）、Ｐ．５３−５８
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した従来技術では、トラヒック制御を適切に行うことができないという課題があった。協働空間を提供するサービスにおいては、例えばアプリケーション毎やユーザ毎など、より細かい粒度でのトラヒック制御が望まれる。この点、上述した従来技術では、集合仮想ルータは、１つのＶＰＮ間接続に関するパケットを１つの経路により転送するので、トラヒック制御も、１つのＶＰＮ間接続に対してまとめて行うことしかできない。
【０００６】
開示の技術は、上記に鑑みてなされたものであって、トラヒック制御を適切に行うことが可能なトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法は、一つの態様において、広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示装置であって、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視手段と、前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御手段とを備える。
【０００８】
また、本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法は、一つの態様において、広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示方法であって、コンピュータが、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視工程と、前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御工程とを含む。
【０００９】
また、本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法は、一つの態様において、コンピュータをトラヒック制御指示装置として機能させることを特徴とするトラヒック制御指示プログラムである。
【００１０】
また、本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法は、一つの態様において、広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示システムであって、トラヒック制御指示装置は、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視手段と、前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御手段とを備え、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置は、前記トラヒック制御指示装置から要求された場合に、該トラヒック制御指示装置に対してトラヒックに関する情報を送信する送信手段と、前記トラヒック制御指示装置から前記指示情報を受信した場合に、受信した該指示情報に従ってトラヒックを制御する制御手段とを備える。
【００１１】
また、本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法は、一つの態様において、広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示方法であって、トラヒック制御指示装置としてのコンピュータが、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視工程と、前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御工程とを含み、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置としてのコンピュータが、前記トラヒック制御指示装置から要求された場合に、該トラヒック制御指示装置に対してトラヒックに関する情報を送信する送信工程と、前記トラヒック制御指示装置から前記指示情報を受信した場合に、受信した該指示情報に従ってトラヒックを制御する制御工程とを含む。
【発明の効果】
【００１２】
本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法の一つの態様によれば、トラヒック制御を適切に行うことが可能になるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施例１に係るＶＰＮ間通信システムの概要を説明するための図である。
【図２】図２は、ポリシールーティングを説明するための図である。
【図３】図３は、ＩＰアドレスの払い出し方式（ｉ）を説明するための図である。
【図４】図４は、ＩＰアドレスの払い出し方式（ｉｉ）を説明するための図である。
【図５】図５は、アドレス変換関係を示す図である。
【図６−１】図６−１は、トラヒック種別毎に経路を分離するメリットを説明するための図である。
【図６−２】図６−２は、トラヒック種別毎に経路を分離するメリットを説明するための図である。
【図７】図７は、実施例１に係るトラヒック制御を説明するための図である。
【図８】図８は、実施例１に係る統合ＡＡＡ装置の構成を示すブロック図である。
【図９】図９は、輻輳状態が生じたか否かを判定するための条件を説明するための図である。
【図１０】図１０は、輻輳状態が生じたか否かを判定するための条件を説明するための図である。
【図１１】図１１は、制御情報を説明するための図である。
【図１２】図１２は、実施例１に係るトラヒック制御処理手順を示すフローチャートである。
【図１３】図１３は、実施例２に係るトラヒック制御を説明するための図である。
【図１４】図１４は、実施例２に係る統合ＡＡＡ装置１００の構成を示すブロック図である。
【図１５】図１５は、制御情報を説明するための図である。
【図１６】図１６は、分離情報を説明するための図である。
【図１７】図１７は、実施例２に係るトラヒック制御処理手順を示すフローチャートである。
【図１８】図１８は、実施例３に係るトラヒック制御を説明するための図である。
【図１９】図１９は、実施例３に係る統合ＡＡＡ装置１００の構成を示すブロック図である。
【図２０】図２０は、制御情報を説明するための図である。
【図２１】図２１は、制御情報を説明するための図である。
【図２２】図２２は、設定情報を説明するための図である。
【図２３】図２３は、実施例３に係るトラヒック制御処理手順を示すフローチャートである。
【図２４】図２４は、実施例４に係るトラヒック制御を説明するための図である。
【図２５】図２５は、実施例４に係るトラヒック制御を説明するための図である。
【図２６】図２６は、実施例４に係る統合ＡＡＡ装置１００の構成を示すブロック図である。
【図２７】図２７は、制御情報を説明するための図である。
【図２８】図２８は、アプリケーションサーバの一覧を説明するための図である。
【図２９】図２９は、実施例４に係るトラヒック制御処理手順を示すフローチャートである。
【図３０】図３０は、冗長化された経路を説明するための図である。
【図３１】図３１は、ＶＰＮサービスによって接続された複数のローカルエリアネットワーク群としての拠点を説明するための図である。
【図３２】図３２は、ＶＰＮサービスによって接続された複数のローカルエリアネットワーク群としての拠点を説明するための図である。
【図３３】図３３は、ＶＰＮサービスによって接続された複数のローカルエリアネットワーク群としての拠点を説明するための図である。
【図３４】図３４は、ＶＰＮ間接続管理システム２００の構成を示すブロック図である。
【図３５】図３５は、ＶＰＮ接続情報記憶部２２１を説明するための図である。
【図３６】図３６は、集合仮想ルータの設定パターンの一例である。
【図３７】図３７は、ＶＰＮ終端装置の設定パターンの一例である。
【図３８】図３８は、ＶＰＮ接続要求記憶部２２３を説明するための図である。
【図３９】図３９は、アドレス変換情報記憶部２２４を説明するための図である。
【図４０】図４０は、ルーティング情報記憶部２２５を説明するための図である。
【図４１】図４１は、ルーティング情報記憶部２２５を説明するための図である。
【図４２】図４２は、アタッチメント記憶部２２６を説明するための図である。
【図４３】図４３は、集合仮想ルータの事前設定情報を説明するための図である。
【図４４】図４４は、ＶＰＮ終端装置の事前設定情報を説明するための図である。
【図４５】図４５は、ＶＰＮ接続要求の入力画面の一例を説明するための図である。
【図４６】図４６は、ＶＰＮ間接続管理システム２００による処理手順を示すフローチャートである。
【図４７】図４７は、協働空間におけるアクセスの一例を説明するための図である。
【発明を実施するための形態】
【００１４】
以下に、本願の開示するトラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法の実施例を説明する。また、以下の実施例では、拠点間接続の一例としてＶＰＮ間接続を説明する。実施例１では、実施例１に係るＶＰＮ間通信システムの概要を説明した上で、トラヒック制御の一例として「輻輳制御」を説明する。実施例２では、トラヒック制御の一例として「負荷分散制御」を説明する。実施例３では、トラヒック制御の一例として「故障切替制御」を説明する。実施例４では、トラヒック制御の一例として「リソース貸借制御」を説明する。実施例５は、その他の実施例である。なお、以下の実施例により本発明が限定されるものではなく、例えば、これらのトラヒック制御は任意に組み合わせることができる。
【実施例１】
【００１５】
［実施例１に係るＶＰＮ間通信システムの概要］
まず、図１〜５を用いて、実施例１に係るＶＰＮ間通信システムの概要を説明する。図１は、実施例１に係るＶＰＮ間通信システムの概要を説明するための図である。図１に例示するように、実施例１に係るＶＰＮ間通信システムは、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成されることで、ＶＰＮ間接続を実現する。なお、以下では、ＶＰＮ間接続される拠点を「ＶＰＮ」という。「ＶＰＮ_i」は、ＶＰＮ名である。また、広域ネットワーク内のパケット転送を制御する集合仮想ルータ（「転送制御装置」とも称する）に設定された仮想ルータを「ＶＲＦ」という。「ＶＲＦ_m」は、仮想ルータ名である。なお、ＶＲＦは、Virtual Routing and Forwardingの略である。
【００１６】
図１においては、互いに異なるＶＰＮ_iとＶＰＮ_j（ｉ、ｊは、互いに独立な正の整数値とし、ここでは特にｉ≠ｊとする）とをＶＰＮ間接続し、ＶＰＮ_i配下の端末αとＶＰＮ_j配下の端末βとの間に協働空間が提供される例を示す。図１に例示する集合仮想ルータは、集合仮想ルータに設定された経路情報に従ってＶＰＮ間接続に関するパケットを転送する。ここで、図１に例示する「仮想ルータ」は、物理的な筐体としてのルータ内のリソースを、仮想化技術を用いて分割し、論理的に互いに独立なルータとして機能させるものである。図１においては、集合仮想ルータに、仮想ルータ『ＶＲＦ_m』及び仮想ルータ『ＶＲＦ_n』（ｍ、ｎは、互いに独立な正の整数値とし、ここでは特にｍ≠ｎとする）が設定され、１つのＶＰＮ間接続（１つの協働空間）に関するパケットを転送する経路として、複数の経路が形成されている。これらの複数の経路は、後述するように、トラヒック種別毎に分離された経路である。なお、図１において点線の枠で例示するように、仮想ルータ『ＶＲＦ_m』側の経路及び仮想ルータ『ＶＲＦ_n』側の経路が、協働空間『ＶＣＳ（Virtual Collaboration Space）_α』に対応する。
【００１７】
また、図１に例示する各ＶＰＮ終端装置は、所定のＶＰＮ間接続に属する各ＶＰＮ（ＶＰＮ_i、ＶＰＮ_j）を収容するとともに、収容した各ＶＰＮを広域ネットワーク側で終端する。なお、ＶＰＮ終端装置は、ＶＰＮと広域ネットワークとの境界に設置されたルータやスイッチなどである。また、図１に例示するアドレス変換装置は、ＶＰＮ終端装置から受信したパケットのアドレスを変換し、アドレス変換後のパケットを集合仮想ルータに送信する。また、アドレス変換装置は、集合仮想ルータから受信したパケットのアドレスを変換し、アドレス変換後のパケットをＶＰＮ終端装置に送信する。
【００１８】
ここで、実施例１に係るＶＰＮ間通信システムにおいては、図１に例示するように、ＶＰＮ終端装置とアドレス変換装置との間にトラヒック分離統合装置が設置される。トラヒック分離統合装置は、ＶＰＮ側から受信したトラヒックをトラヒック種別毎に分離し、トラヒック種別毎の複数の経路に送出する。また、トラヒック分離統合装置は、トラヒック種別毎に分離されて仮想ルータを経由したトラヒックを、一つのトラヒックに統合してＶＰＮ側に送出する。
【００１９】
具体的には、実施例１に係るトラヒック分離統合装置は、ポリシーベースのルーティングを行う。ポリシーベースのルーティングとは、トラヒックが予め規定されたある条件に一致した場合に、予め規定された特定の処理（ルーティング）を行うというものである。トラヒック分離統合装置は、その条件をＡＣＬ（Access Control List）として予め記憶する。また、トラヒック分離統合装置は、特定の処理をポリシーとして予め記憶する。そして、トラヒック分離統合装置は、パケットを受信すると、ＡＣＬとして規定された条件に一致するパケットを抽出し、抽出したパケットに対して、ポリシーとして規定された特定の処理を行う。ポリシーには、例えば、アプリケーション毎やユーザ毎に経路が規定されたもの、あるいは、ＱｏＳ（Quality of Service）クラスに対応するＴｏＳ（Type of Service）値に応じて経路が規定されたもの、その他、ＩＰ（Internet Protocol）アドレスやポート番号に応じて経路が規定されたものなどが含まれる。トラヒック分離統合装置は、公知技術により実現可能である。
【００２０】
例えば、実施例１に係るトラヒック分離統合装置が、アプリケーションの種類が『ＡＰＬ（Application）１』のトラヒックについては仮想ルータ『ＶＲＦ_m』の経路にパケットを転送し、アプリケーションの種類が『ＡＰＬ２』のトラヒックについては仮想ルータ『ＶＲＦ_n』の経路にパケットを転送する、と規定するポリシーを記憶していたとする。すると、例えば、トラヒック分離統合装置０は、ＶＰＮ_i側から『ＡＰＬ１』のパケットを受信すると、『Ｉ／Ｆ（interface）０．１』側に強制的に転送する。すなわち、トラヒック分離統合装置０は、仮想ルータ『ＶＲＦ_m』の経路にパケットを転送する。また、例えば、トラヒック分離統合装置０は、ＶＰＮ_i側から『ＡＰＬ２』のパケットを受信すると、『Ｉ／Ｆ０．２』側に強制的に転送する。すなわち、トラヒック分離統合装置０は、仮想ルータ『ＶＲＦ_n』の経路にパケットを転送する。
【００２１】
一方、例えば、トラヒック分離統合装置１は、ＶＰＮ_j側から『ＡＰＬ１』のパケットを受信すると、『Ｉ／Ｆ１．１』側に強制的に転送する。すなわち、トラヒック分離統合装置１は、仮想ルータ『ＶＲＦ_m』の経路にパケットを転送する。また、例えば、トラヒック分離統合装置１は、ＶＰＮ_j側から『ＡＰＬ２』のパケットを受信すると、『Ｉ／Ｆ１．２』側に強制的に転送する。すなわち、トラヒック分離統合装置１は、仮想ルータ『ＶＲＦ_n』の経路にパケットを転送する。
【００２２】
さて、実施例１に係るＶＰＮ間通信システムは、上述したように、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成されることで、ＶＰＮ間接続を実現する。かかるＶＰＮ間接続は、ＶＰＮ間接続管理システム（図１において図示を省略）によって構築され、ＶＰＮ間接続管理システムによってＶＰＮ間接続サービスとして提供される。そこで、このようなＶＰＮ間接続が構築される過程について、簡単に説明する。
【００２３】
所定のＶＰＮ間接続は、例えばユーザからのＶＰＮ間接続要求に応じて構築される。例えば、ＶＰＮ配下の端末を利用するユーザは、ＶＰＮ間接続サービスを提供する事業者に対してＶＰＮ間接続要求を申請する際に、協働空間においてアクセスを許容するサーバの名前とＩＰアドレスとを予め申請する。
【００２４】
例えば、ＶＰＮ_iとＶＰＮ_jとの間のＶＰＮ間接続を考える。ＶＰＮ_j側のサーバをＶＰＮ_i側のユーザに利用させる形態であるとする。ＶＰＮ_j側のユーザは、サーバの名前として、『serverA@vpnj.example.com』、『serverB@vpnj.example.com』、及び『serverC@vpnj.example.com』を申請する。なお、各ＶＰＮにおいてサーバのＩＰアドレスが動的に払い出される場合もある。このような場合には、ＶＰＮ間接続管理システム側で事後的に（払い出された後に）ＩＰアドレスを取得することになるので、必ずしもＩＰアドレスを予め申請する必要はない。
【００２５】
また、ユーザは、協働空間においてアクセスを許容するサーバについて経路をグループ化し、経路グループを申請する。例えば、ＶＰＮ配下の端末を利用するユーザは、各サーバが提供するサービス（アプリケーションなど）を検討し、経路を共通化したいサービス、あるいは、経路を個別化したいサービスなどに応じて、経路をグループ化し、ＶＰＮ間接続サービスを提供する事業者に対してＶＰＮ間接続要求を申請する際に、経路グループを申請する。例えば、ＶＰＮ_j側のユーザは、『経路グループ１』に、メールサーバ（『serverA@vpnj.example.com』）及びＷｅｂサーバ（『serverB@vpnj.example.com』）を含めること、『経路グループ２』に、動画配信サーバ（『serverB@vpnj.example.com』）を含めること、『経路グループ３』に、リアルタイムコラボレーションサーバ（『serverC@vpnj.example.com』）を含めることを申請する。
【００２６】
なお、例えば、ＶＰＮ間接続サービスの仕様として、経路グループと品質保証クラスとの対応付けが規定されていてもよい。例えば、品質保証クラスの４クラスに対応付けて、４種類の経路グループを予め規定しておく。すると、ユーザは、各サーバが提供するサービスに必要な品質保証クラスを検討し、予め規定された４種類の経路グループの中から適切な品質保証クラスの経路グループを選択して、申請すればよい。あるいは、例えば、ユーザが、各サーバが提供するサービスの種別を申請することにより、適切な品質保証クラスの経路グループが自動的に選択されてもよい。
【００２７】
一方、ＶＰＮ間接続管理システムは、ＶＰＮ_i側のユーザからも、端末の名前とＩＰアドレスとの申請を受け付け、これらの情報に基づき、ＶＰＮ_iとＶＰＮ_jとの間に形成する経路を認識する。例えば、ＶＰＮ間接続管理システムは、『経路グループ１』、『経路グループ２』、及び『経路グループ３』が申請されたことに基づいて、ＶＰＮ_iとＶＰＮ_jとの間に３つの経路を形成すべきであることを認識する（例えば、仮想ルータ『ＶＲＦ_l』、『ＶＲＦ_m』、『ＶＲＦ_n』）。
【００２８】
そして、ＶＰＮ間接続管理システムは、経路に応じたＤＮＳ（Domain Name System）登録情報を生成する。例えば、ＶＰＮ間接続管理システムは、『経路グループ１』のメールサーバについては『mail@vcsα.vpnj.example.com』を生成し、Ｗｅｂサーバについては『www@vcsα.vpnj.example.com』を生成し、『経路グループ２』の動画配信サーバについては『movie@vcsα.vpnj.example.com』を生成し、『経路グループ３』のリアルタイムコラボレーションサーバについては『collabo@vcsα.vpnj.example.com』を生成する。なお、これらの情報は、メールや郵送など、あるいは申請用の画面などを通じて、ＶＰＮ_i側のユーザに通知される。
【００２９】
また、ＶＰＮ間接続管理システムは、経路を形成するための設定情報を生成する。例えば、ＶＰＮ間接続管理システムは、３つの経路を形成するための設定情報を生成するが、例えば、集合仮想ルータに設定される３つの仮想ルータの設定情報それぞれは、集合仮想ルータ内で関連付けられるＩ／Ｆが異なる以外は同じ内容となる。また、後述するように、アドレス変換装置に設定される設定情報も同様である。すなわち、ＶＰＮ間接続管理システムは、１つの仮想ルータの設定情報を生成する場合の情報を複製して、３つの仮想ルータの設定情報それぞれを生成すればよい。
【００３０】
その後、ＶＰＮ間接続管理システムは、例えば、ＶＰＮ間接続のサービスを提供する開始時刻になると、経路を形成するための設定情報を、集合仮想ルータやＶＰＮ終端装置、アドレス変換装置などに設定し、また、ＤＮＳ登録情報をＤＮＳ装置に設定する。
【００３１】
また、ＶＰＮ間接続管理システムは、トラヒック分離統合装置に設定されるポリシールーティング情報も生成し、例えば、ＶＰＮ間接続のサービスを提供する開始時刻になると、生成したポリシールーティング情報をトラヒック分離統合装置に設定する。図２を用いて、ポリシールーティングを説明する。図２は、ポリシールーティングを説明するための図である。
【００３２】
まず、ＶＰＮ間接続管理システムは、トラヒック分離統合装置においてポリシールーティングの対象となるトラヒックを、種別毎に分離する。また、ＶＰＮ間接続管理システムは、経路グループ毎にポリシーを規定する。例えば、『ポリシー１』には、『経路グループ１』に対応するメールトラヒック及びＷｅｂトラヒックだけを通過させ、他の種別のトラヒックは通過させないことを規定する。また、『ポリシー２』には、『経路グループ２』に対応する動画配信トラヒックだけを通過させ、他の種別のトラヒックは通過させないことを規定する。『ポリシー３』には、『経路グループ３』に対応するリアルタイムコラボレーショントラヒックだけを通過させ、他の種別のトラヒックは通過させないことを規定する。そして、ＶＰＮ間接続管理システムは、トラヒック分離統合装置の各インタフェースに、各ポリシーを適用する。例えば、図２に例示するように、インタフェース『ether0』に『ポリシー１』を適用し、インタフェース『ether1』に『ポリシー２』を適用し、インタフェース『ether2』に『ポリシー３』を適用する。
【００３３】
なお、このようなＶＰＮ間接続における拡張について説明する。例えば、２つのＶＰＮによるＶＰＮ間接続が既に構築済みの場合に、ここへＶＰＮを１つ追加することで、３つのＶＰＮによるＶＰＮ間接続を構築するとする。このような場合は、ＶＰＮが２つの場合に対し、単にＶＰＮを１つ追加するという設定を行えばよい。例えば、新たに追加されるＶＰＮが、既に形成されている既存の経路グループに含まれるアプリケーションを利用することができるように、既存の経路グループに、新たに追加されるＶＰＮ用の経路を追加する。また、ＶＰＮを新たに追加することに伴いアプリケーションも新たに追加されるような場合であって、既存の経路グループに追加できないアプリケーションについては、３つのＶＰＮが利用することができるように、新たに仮想ルータを生成すればよい。
【００３４】
より一般化して説明すると、Ｎ個のＶＰＮによるＶＰＮ間接続が既に構築済みであると仮定する。ここへＶＰＮを新たに一つ追加することは、ＩＰアドレスが枯渇するまで、常に可能である。新たに追加されるＶＰＮが、既に形成されている既存の経路グループに含まれるアプリケーションを利用することができるように、既存の経路グループに、新たに追加されるＶＰＮ用の経路を追加する。また、ＶＰＮを新たに追加することに伴いアプリケーションも新たに追加されるような場合であって、既存の経路グループに追加できないアプリケーションについては、Ｎ＋１個のＶＰＮが利用することができるように、新たに仮想ルータを生成すればよい。以上の議論から、このように、ＶＰＮの数や仮想ルータの数を、任意の時点で、任意に設定することができる。
【００３５】
［アドレスの払い出し方式について］
ところで、実施例１に係るＶＰＮ間通信システムは、図１に例示したように、アドレス変換装置を備え、アドレス変換装置が、ＩＰアドレスのアドレス変換を行う。ここで、実施例１においては、アドレス変換の技術として、ＩＥＴＦ（Internet Engineering Task Force）によって公開されたＲＦＣ（Request for Comments）２６６３の技術（以下「Ｔｗｉｃｅ−ＮＡＴ」）を用いる。以下、図３及び図４を用いて、アドレスの払い出し方式を説明する。
【００３６】
上述したように、実施例１においては、Ｔｗｉｃｅ−ＮＡＴが用いられる。すなわち、アドレス変換装置は、送信元のＩＰアドレス及び宛先のＩＰアドレスの双方を変換する。ここで、ＶＰＮ間接続に属する各ＶＰＮ配下の端末を該ＶＰＮ内で識別するために払い出されたＩＰアドレスを、「拠点内アドレス」とする。また、通信相手となる他ＶＰＮ配下の端末をＶＰＮ内で識別するためのＩＰアドレスを、「第一アドレス」とする。また、ＶＰＮ間接続に属する各ＶＰＮ配下の端末を集合仮想ルータにて識別するためのＩＰアドレスを、「第二アドレス」とする。
【００３７】
すると、例えば、端末αと端末βとが通信を行う場合、端末αを配下とするＶＰＮ側に設置されたアドレス変換装置は、（送信元アドレス、宛先アドレス）＝（端末αの拠点内アドレス、端末βの第一アドレス）を、（送信元アドレス、宛先アドレス）＝（端末αの第二アドレス、端末βの第二アドレス）に変換する。したがって、アドレス変換情報としては、端末αの拠点内アドレスと端末αの第二アドレスとを変換するアドレス変換情報、端末βの第一アドレスと端末βの第二アドレスとを変換するアドレス変換情報が、アドレス変換装置に登録されることになる。
【００３８】
図３は、ＩＰアドレスの払い出し方式（ｉ）を説明するための図である。図３において、「ａ_i」は、ＶＰＮ_i内で端末αを識別するための拠点内アドレスであり、「ａ_j」は、ＶＰＮ_j内で端末βを識別するための拠点内アドレスである。また、（１）式は、ＶＰＮ_iからＶＲＦ_m向けのアドレス変換を表す変換作用素である。また、（２）式は、ＶＲＦ_mからＶＰＮ_j向けのアドレス変換を表す変換作用素である。
【数１】

【数２】

【００３９】
したがって、図３において、仮想ルータ『ＶＲＦ_m』に属するＶＰＮ_i配下の端末α及びＶＰＮ_j配下の端末βを、集合仮想ルータにて識別するための第二アドレスは、拠点内アドレス「ａ_i」及び拠点内アドレス「ａ_j」がそれぞれアドレス変換装置によって１回変換されたＩＰアドレスとなり、（３）式となる。一方、仮想ルータ『ＶＲＦ_n』に属するＶＰＮ_i配下の端末α及びＶＰＮ_j配下の端末βを、集合仮想ルータにて識別するための第二アドレスは、拠点内アドレス「ａ_i」及び拠点内アドレス「ａ_j」がそれぞれアドレス変換装置によって１回変換されたＩＰアドレスとなり、（４）式となる。
【数３】

【数４】

【００４０】
また、図３において、通信相手となるＶＰＮ_j配下の端末βをＶＰＮ_i内で識別するための第一アドレスは、（５）式及び（６）式となる。同様に、通信相手となるＶＰＮ_i配下の端末αをＶＰＮ_j内で識別するための第一アドレスは、（７）式及び（８）式となる。
【数５】

【数６】

【数７】

【数８】

【００４１】
ここで、ＩＰアドレスの払い出し方式（ｉ）では、通信相手となるＶＰＮ_j配下の端末βをＶＰＮ_i内で識別するための第一アドレスを、経路毎に異なるものにはしない。すなわち、（９）及び（１０）式が成り立つように、第一アドレスを払い出す。なぜなら、実施例１に係るトラヒック分離統合装置は、ＩＰアドレスによるルーティングを行わず、ポリシーベースのルーティングを行うので、第一アドレスが同じであっても、正しくルーティングされるからである。
【数９】

【数１０】

【００４２】
このようなことから、ＩＰアドレスの払い出し方式（ｉ）では、経路が１つの場合と同様にＩＰアドレスの払い出しを行えばよいことになり、仮想ルータそれぞれや、アドレス変換装置それぞれに、同じ設定情報やアドレス変換情報が設定されればよいことになる。
【００４３】
次に、図４は、ＩＰアドレスの払い出し方式（ｉｉ）を説明するための図である。上述したように、ＩＰアドレスの払い出し方式（ｉ）では、上記（９）式及び（１０）式が成立するように、ＩＰアドレスの払い出しがなされた。もっとも、開示の技術は、上記（９）式及び（１０）式が成立するような払い出しに限られるものではない。例えば、上記（９）式及び（１０）式が成立せず、（１１）式及び（１２）式の関係となる場合も考えられる。
【数１１】

【数１２】

【００４４】
このようなＩＰアドレスの払い出しがなされた場合、トラヒック分離統合装置は、ポリシーベースのルーティングを行い、パケットの宛先ＩＰアドレスに基づくルーティングを行わないので、場合によっては、パケットの宛先ＩＰアドレスに基づくルーティングという観点からは仮想ルータ『ＶＲＦ_m』側の経路にルーティングされるべきパケットが、仮想ルータ『ＶＲＦ_n』側の経路に送出されてしまうおそれがある。
【００４５】
例えば、ＶＰＮ_iから仮想ルータ『ＶＲＦ_m』側の経路にルーティングされるパケットは、ＩＰアドレスベースのルーティングという観点からは、宛先のＩＰアドレスが（５）式のパケットであるはずであるが、ポリシーベースのルーティングにより、宛先のＩＰアドレスが（６）式のパケットがルーティングされてしまうおそれがある。そこで、ＩＰアドレスの払い出し方式（ｉｉ）においては、このようにトラヒック分離統合装置においてＩＰアドレスベースのルーティングという観点からは誤ってルーティングされたと考えられるパケットについてもアドレス変換が適切に行われるように、変換規則（１３）及び（１４）に従うアドレス変換情報をアドレス変換装置に対して追加する。同様に、変換規則（１５）及び（１６）に従うアドレス変換情報をアドレス変換装置に対して追加する。
【数１３】

【数１４】

【数１５】

【数１６】

【００４６】
つまり、ポリシーベースのルーティングにより、宛先のＩＰアドレスが（６）式のパケットが仮想ルータ『ＶＲＦ_m』側の経路にルーティングされてしまったとしても、（１３）の変換規則に従ってアドレス変換される。
【００４７】
なお、変換規則（１３）〜（１６）によって示されるアドレス変換情報を変換作用素によって記述すると、以下（１９）式〜（２２）式を新たに定義したことになる。まず、通常のＩＰアドレスベースのルーティングでは（１７）式が成立する。図５は、アドレス変換関係を示す図である。図５に示す関係より（１８）式が成立するので、（１７）式が成立する。
【数１７】

【数１８】

【００４８】
ところが、ＩＰアドレスの払い出し方式（ｉｉ）によってＩＰアドレスが払い出された場合、アドレス変換装置においては上記変換規則（１３）〜（１６）に従うアドレス変換がなされなければならないが、このためには、以下（１９）式〜（２２）式であらわされる変換を新たに定義しなければならない。
【数１９】

【数２０】

【数２１】

【数２２】

【００４９】
すなわち、ＩＰアドレスベースのルーティングでは、宛先のＩＰアドレスが（６）式のパケットが仮想ルータ『ＶＲＦ_m』側の経路にルーティングされてしまうことは考えられないので、（２３）式であらわされる変換は定義されていても（２４）式であらわされる変換は定義されていなかったが、ＩＰアドレスの払い出し方式（ｉｉ）によってＩＰアドレスが払い出された場合には、例えば（２４）式を新たに定義しなければならない。なお、ここで定義されていない変換関係には、意味がなく、値が定まらないことに注意が必要である。例えば、以下に示す変換規則（２５）や変換規則（２６）のような記号には、対応する実際の変換は存在しないため、意味がないものである。
【数２３】

【数２４】

【数２５】

【数２６】

【００５０】
続いて、実施例１に係るＶＰＮ間通信システムのように、トラヒック種別毎に経路を分離するメリットを説明する。図６−１及び６−２は、トラヒック種別毎に経路を分離するメリットを説明するための図である。
【００５１】
例えば、図６−１に例示するＶＰＮ間接続においては、トラヒックの経路は、ＱｏＳ（Quality of Service）のクラス毎（あるいはＳＬＡ（Service Layer Agreement）毎）に分離されている。このように、実施例１に係るＶＰＮ間通信システムにおいては、同じユーザ間のトラヒックであっても、トラヒックの種別により異なる経路が用いられ、異なる仮想ルータ、異なる集合仮想ルータのＩ／Ｆ、異なるキューが用いられる。この結果、例えば、同一のＱｏＳクラスのトラヒックをまとめてトラヒック制御することができる。逆に言えば、異なるＱｏＳクラスのトラヒックを分離した結果、同一のＱｏＳクラスのトラヒックについては、優先制御などの複雑なトラヒック制御をすることなく、全てのパケットを公平に扱えばよくなり、トラヒック制御を単純化することができる。
【００５２】
例えば、図６−２に例示するように、集合仮想ルータ、アドレス変換装置、トラヒック分離統合装置、及びＶＰＮ終端装置の各装置は、入り側のＩ／Ｆにおいて十分なバッファを用意する。次に、出側のＩ／Ｆの帯域を、入り側のＩ／Ｆの帯域の和以上にとれば、ＶＰＮ終端装置から入力され、集合仮想ルータを経由し、別のＶＰＮ終端装置から出ていくまでに、トラヒックが廃棄されることはない。あるいは、出側のＩ／Ｆの帯域が、入り側のＩ／Ｆの帯域の和より少ない場合には、バッファで吸収できない破棄されるパケットが発生する可能性があるが、廃棄されるパケットの数は、トラヒックの量に比例するため、ユーザ間で公平に廃棄されることになる。また、例えば、図６−２に例示するように、集合仮想ルータ、アドレス変換装置、及びトラヒック分離統合装置の各装置は、出側のＩ／Ｆにおいてパケット間隔を整えるためのシェーパーを用意する。各装置は、装置内では優先制御などの複雑なトラヒック制御をすることなく全てのパケットを公平に扱い、出側のＩ／Ｆにおいてトラヒックのシェーピングを確実に行うだけでよく、トラヒック制御を単純化することができる。ＶＰＮの種類によっては厳密なＱｏＳが提供されているので、その場合は、ＶＰＮ終端装置における厳密な優先制御が可能である。したがって、集合仮想ルータ側から送信されてくるクラス別のトラヒックを、トラヒック分離統合装置が、ＶＰＮ終端装置に入るまで十分な帯域をもつ異なる物理経路を通るようにしておけば、ＶＰＮ終端装置でのみ優先制御が行われ、結果として、経路全体にわたるトラヒックのクラス毎に公平なＱｏＳ保証が可能となる。このように、トラヒック毎にルートが分けられることによって、ＶＰＮ終端装置で優先制御を適用すれば、異なる品質クラスやＳＬＡを公平かつ厳密に保証することが可能となる。
【００５３】
また、例えば、各集合仮想ルータにおいてＶＰＮの収容密度を変える（例えば、集合仮想ルータの性能に対し、ＱｏＳクラス１は性能の１００％までしか収容しないが、ＱｏＳクラス２は３００％まで収容するなど）ことによって、ＱｏＳクラス毎のトラヒック制御を、集合仮想ルータへの収容という観点から制御することができる。なお、上記と同様に、ＶＰＮ終端装置で厳密な優先制御が可能であれば、トラヒック分離統合装置や集合仮想ルータにおいては、十分な帯域とバッファとを用意し、同一クラスのトラヒック毎に受信したパケットを到着した順に特別な優先制御をすることなく、そのまま転送すればよい。このようにして、例えば、特別な優先制御機能を全ての装置で持たなくても、経路全体にわたってのクラス毎に公平で厳密なＱｏＳ保証やＳＬＡ保証が可能となる。
【００５４】
［実施例１に係る統合ＡＡＡ装置によるトラヒック制御］
さて、これまで、実施例１に係るＶＰＮ間通信システムについて、その概要を説明してきたが、以下では、本願の開示する技術として、実施例１に係る統合ＡＡＡ（Authentication Authorization Accounting）装置を中心に説明する。
【００５５】
統合ＡＡＡ装置は、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成された場合に、該経路上の装置を監視することにより、該装置から、輻輳状態が生じたか否かを判定するための情報を取得し、取得した情報が予め定められた条件に該当するか否かを判定する。そして、統合ＡＡＡ装置は、取得した情報が条件に該当すると判定した場合に、経路上のトラヒックを制御するための指示情報を、該経路を形成する装置に対して送信する。
【００５６】
輻輳状態が生じたか否かを判定するための情報として、例えば、トラヒックに関する情報やリソースに関する情報がある。具体的に例を挙げると、例えば、『集合仮想ルータのＣＰＵ（Central Processing Unit）使用率』、『集合仮想ルータのＩ／Ｆにて測定される利用中の帯域』、『集合仮想ルータのＩ／Ｆにて測定される空き帯域』、『集合仮想ルータのＩ／Ｆにて測定される帯域の利用率（Ｉ／Ｆに割り当てられている帯域に対する利用中の帯域の割合）』、『集合仮想ルータのＩ／Ｆにて測定されるパケットの転送量（単位時間あたりのパケット数及びパケットのサイズ）』、『集合仮想ルータのＩ／Ｆにて測定されるパケット廃棄率』、『集合仮想ルータのＩ／Ｆにて測定されるＱｕｅｕｅ長』などがある。また、例えば、『経路上を流れる測定用のパケットやユーザパケットの遅延時間』などがある。
【００５７】
この点、以下では、統合ＡＡＡ装置が、輻輳状態が生じたか否かを判定するための情報として『集合仮想ルータのＣＰＵ使用率』を取得する例を用いて説明する。実施例１に係る統合ＡＡＡ装置は、輻輳状態が生じたか否かを判定するための情報として『集合仮想ルータのＣＰＵ使用率』を取得し、取得した情報が予め定められた閾値を超過することにより輻輳状態が生じたか否かを判定する。また、統合ＡＡＡ装置は、輻輳状態が生じたと判定した場合に、複数の経路のうち優先度が低いトラヒック用の経路にてトラヒックを廃棄するように指示する指示情報を、経路を形成する装置に対して送信する。
【００５８】
図７は、実施例１に係るトラヒック制御を説明するための図である。図７に例示するように、実施例１においては、ＶＰＮ１とＶＰＮ２との間に、ＱｏＳクラス毎に分離された複数の経路として、仮想ルータ『ＶＲＦ１』側の経路と、仮想ルータ『ＶＲＦ２』側の経路とが形成されている。なお、仮想ルータ『ＶＲＦ１』側の経路と、仮想ルータ『ＶＲＦ２』側の経路とを併せて一つの協働空間と考える。仮想ルータ『ＶＲＦ１』側の経路は、『Priority Class』のトラヒック用の経路であり、仮想ルータ『ＶＲＦ２』側の経路は、『Best Effort Class』のトラヒック用の経路である。なお、『Best Effort Class』のトラヒックの方が、『Priority Class』のトラヒックよりも優先度が低い。すなわち、仮想ルータ『ＶＲＦ２』側の経路が、優先度の低いトラヒック用の経路である。なお、図７の例においてはＶＰＮが２つであるが、実際には、より多くのＶＰＮが集合仮想ルータに収容され、より多くのトラヒックが集合仮想ルータにて処理されると考えられる。
【００５９】
図７に例示するように、統合ＡＡＡ装置は、輻輳状態が生じたか否かを判定するための情報を、例えば集合仮想ルータから取得し、取得した情報が予め定められた閾値を超過することにより輻輳状態が生じたか否かを判定する。また、統合ＡＡＡ装置は、輻輳状態が生じたと判定した場合に、複数の経路のうち優先度が低いトラヒック用の経路、すなわち仮想ルータ『ＶＲＦ２』側の経路（例えば、集合仮想ルータの入り側のＩ／Ｆ）にてトラヒックを廃棄するように指示する指示情報を、例えば集合仮想ルータに対して送信する。
【００６０】
図８は、実施例１に係る統合ＡＡＡ装置１００の構成を示すブロック図である。図８に例示するように、実施例１に係る統合ＡＡＡ装置１００は、通信部１１０と、入力部１１１と、出力部１１２と、入出力制御Ｉ／Ｆ部１１３と、記憶部１２０と、制御部１３０とを有する。
【００６１】
通信部１１０は、例えばＩＰ（Internet Protocol）通信用の一般的なインタフェースなどであり、集合仮想ルータやトラヒック分離統合装置などとの間で通信を行う。なお、統合ＡＡＡ装置１００と、集合仮想ルータやトラヒック分離統合装置などとの間は、図示しない監視用のネットワークで接続されているものとする。
【００６２】
入力部１１１は、例えばキーボードやマウスなどであり、各種操作の入力などを受け付ける。実施例１において、例えば、入力部１１１は、輻輳状態が生じたか否かを判定するための情報の閾値の入力をキーボードやマウスによって受け付ける。出力部１１２は、例えばディスプレイなどであり、各種操作のための情報などを出力する。実施例１において、出力部１１２は、例えば、閾値を入力するための入力画面を出力する。入出力制御Ｉ／Ｆ（Interface）部１１３は、入力部１１１と、出力部１１２と、記憶部１２０と、制御部１３０との間における入出力を制御する。なお、統合ＡＡＡ装置１００は、必ずしも入力部１１１や出力部１１２を備える必要はなく、例えば、通信部１１０を介して他の管理端末やユーザ用のＷｅｂサーバと通信を行い、入出力に係る情報を送受信してもよい。
【００６３】
記憶部１２０は、例えばＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ（flash memory）などの半導体メモリ素子、ハードディスク、光ディスクなどであり、各種情報を記憶する。具体的には、記憶部１２０は、図７に例示するように、条件記憶部１２１と、制御情報記憶部１２２とを有する。
【００６４】
条件記憶部１２１は、輻輳状態が生じたか否かを判定するための条件を記憶する。具体的には、条件記憶部１２１は、例えばＶＰＮ間接続サービスの運用者などによって入力されることで条件を予め記憶し、条件記憶部１２１が記憶する条件は、後述するトラヒック監視部１３１による処理に用いられる。
【００６５】
図９及び１０は、輻輳状態が生じたか否かを判定するための条件を説明するための図である。集合仮想ルータのＣＰＵ使用率とスループット（Throughput）との間には、図９に例示するような関係がある。すなわち、ＣＰＵ使用率が７０％を超えると、スループットは著しく低下する（品質が著しく劣化する）。また、集合仮想ルータのＣＰＵ使用率とレイテンシ（Latency）との間には、図１０に例示するような関係がある。すなわち、ＣＰＵ使用率が７０％を超えると、レイテンシは著しく増加する（品質が著しく劣化する）。このようなことから、例えば、条件記憶部１２１は、輻輳状態が生じたか否かを判定するための条件として、『ＣＰＵ使用率７０％』という閾値を記憶する。なお、条件記憶部１２１は、輻輳状態が解消されたか否かを判定するための条件を記憶する。例えば、条件記憶部１２１は、『ＣＰＵ使用率５０％の閾値を、継続して５秒間超えなかった』との条件を記憶する。
【００６６】
制御情報記憶部１２２は、統合ＡＡＡ装置１００による制御に用いられる各種情報を記憶する。具体的には、制御情報記憶部１２２は、例えばＶＰＮ間接続サービスの運用者などによって入力されることで制御情報を予め記憶し、制御情報記憶部１２２が記憶する制御情報は、後述するトラヒック監視部１３１やトラヒック制御部１３２による処理に用いられる。
【００６７】
図１１は、制御情報を説明するための図である。例えば、制御情報記憶部１２２は、図１１に例示するように、監視対象となる集合仮想ルータについて、識別情報及びアドレスを記憶する。また、制御情報記憶部１２２は、図１１に例示するように、情報取得の契機、判定条件、条件該当時の制御、条件非該当時の制御などを記憶する。なお、これらの制御情報は一例に過ぎない。例えば、情報取得の契機や判定条件、条件該当時の制御、条件非該当時の制御などは、監視対象となる装置に応じて異なってもよく、また、同種の装置（例えば集合仮想ルータ間など）では、同じになってもよい。
【００６８】
例えば、図１１の例で説明すると、統合ＡＡＡ装置１００によって監視される集合仮想ルータは、『集合仮想ルータ１』（例えば図７に例示する集合仮想ルータが相当する）であり、この集合仮想ルータとの間で通信を行う場合には、『ＩＰアドレス１』を用いる。また、制御情報記憶部１２２は、情報取得の契機、すなわち監視のタイミングとして、例えば『１秒間隔』を記憶する。また、制御情報記憶部１２２は、判定条件として、『条件記憶部１２１に記憶された条件』を記憶する。すなわち、上述したように、『ＣＰＵ使用率７０％』という閾値が判定条件であることを示す。また、制御情報記憶部１２２は、条件に該当した時の制御内容として、「仮想ルータ『ＶＲＦ２』側の経路であって『集合仮想ルータ１』の入り側のＩ／Ｆにて、トラヒックを廃棄するように指示する指示情報を、『集合仮想ルータ１』に対して送信すること」を記憶する。
【００６９】
また、図１１に例示するように、制御情報記憶部１２２は、「条件非該当時の制御」に対応付けて「トラヒックの廃棄を停止するように指示する指示情報を『集合仮想ルータ１』に対して送信すること」を記憶する。すなわち、統合ＡＡＡ装置１００は、監視を継続している中で、輻輳状態が解消したと判定した場合（『ＣＰＵ使用率５０％の閾値を、継続して５秒間超えなかった』との条件に該当した場合）には、トラヒックの廃棄を停止するように指示する指示情報を、該当する装置に対して送信する。
【００７０】
制御部１３０は、統合ＡＡＡ装置１００において実行される各種処理を制御する。具体的には、図８に例示するように、制御部１３０は、トラヒック監視部１３１と、トラヒック制御部１３２とを有する。
【００７１】
トラヒック監視部１３１は、輻輳状態が生じたか否かを判定するための情報を取得し、取得した情報が予め定められた閾値を超過することにより輻輳状態が生じたか否かを判定する。そして、トラヒック監視部１３１は、輻輳状態が生じたと判定した場合には、その旨をトラヒック制御部１３２に通知する。
【００７２】
例えば、トラヒック監視部１３１は、集合仮想ルータとの間で定期的に（または適当なタイミングに）通信を行い、集合仮想ルータにて収集されたＣＰＵ使用率を、輻輳状態が生じたか否かを判定するための情報として集合仮想ルータから受信する。このとき、トラヒック監視部１３１は、制御情報記憶部１２２を参照し、例えば、『ＩＰアドレス１』を用いて『集合仮想ルータ１』との間で通信を行い、情報取得の契機『１秒間隔』に従ってＣＰＵ使用率を受信する。次に、トラヒック監視部１３１は、集合仮想ルータからＣＰＵ使用率を受信すると、条件記憶部１２１を参照し、受信したＣＰＵ使用率が、『ＣＰＵ使用率７０％』という閾値を超過するか否かを判定する。そして、トラヒック監視部１３１は、超過すると判定した場合には、その旨をトラヒック制御部１３２に通知する。
【００７３】
トラヒック制御部１３２は、トラヒック監視部１３１によって輻輳状態が生じたと判定された場合に、複数の経路のうち優先度が低いトラヒック用の経路にてトラヒックを廃棄するように指示する指示情報を、経路を形成する装置に対して送信する。
【００７４】
例えば、トラヒック制御部１３２は、閾値を超過すると判定した旨の通知をトラヒック監視部１３１から受け付けると、制御情報記憶部１２２を参照し、条件該当時の制御内容として記憶された情報を取得する。そして、トラヒック制御部１３２は、仮想ルータ『ＶＲＦ２』側の経路であって集合仮想ルータの入り側のＩ／Ｆにて、『Best Effort Class』のトラヒックを廃棄するように指示する指示情報を、例えば『集合仮想ルータ１』に対して送信する。一般的に、『Priority Class』のトラヒックよりも『Best Effort Class』のトラヒックの方がトラヒック量が多いので、有効性は高いと考えられる。なお、『Best Effort Class』のトラヒックがどの程度であれば通過させ、どの程度であれば廃棄するかについては、予め定めた値に基づいて制御してもよいし、入り側のＩ／Ｆを通過するトラヒック量を測定しながら動的に制御してもよい。
【００７５】
なお、実施例１においては、輻輳状態が生じたか否かを判定するための情報として、『集合仮想ルータのＣＰＵ使用率』を取得する例を説明したが、開示の技術はこれに限られるものではない。上述したように、例えば、輻輳状態が生じたか否かを判定するための情報として、『集合仮想ルータのＩ／Ｆにて測定される利用中の帯域』、『集合仮想ルータのＩ／Ｆにて測定される空き帯域』、『集合仮想ルータのＩ／Ｆにて測定される帯域の利用率（Ｉ／Ｆに割り当てられている帯域に対する利用中の帯域の割合）』、『集合仮想ルータのＩ／Ｆにて測定されるパケットの転送量（単位時間あたりのパケット数及びパケットのサイズ）』、『集合仮想ルータのＩ／Ｆにて測定されるパケット廃棄率』、『集合仮想ルータのＩ／Ｆにて測定されるＱｕｅｕｅ長』などが用いられることもある。
【００７６】
例えば、統合ＡＡＡ装置１００は、『利用中の帯域』が所定の閾値よりも大きければ、輻輳状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、『空き帯域』が所定の閾値よりも小さければ、輻輳状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、『利用率』が所定の閾値よりも高ければ、輻輳状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、『単位時間あたりのパケット数』が所定の閾値よりも多く、かつ、『パケットのサイズ』が所定の閾値よりも小さい場合には、例えばルーティング処理の負荷が高くなるので、輻輳状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、『パケット廃棄率』が所定の閾値よりも大きければ、輻輳状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、『Ｑｕｅｕｅ長』が所定の閾値よりも長ければ、輻輳状態が生じたと判定する。なお、上記したこれらの手法を用いる場合には、統合ＡＡＡ装置１００は、各手法に対応する閾値を条件記憶部１２１に予め記憶する。また、同様に、例えば、統合ＡＡＡ装置１００は、輻輳状態が生じたか否かを判定するための情報として、トラヒック分離統合装置にて収集された『利用中の帯域』、『空帯域』、『帯域の利用率』、『パケットの転送量』、『パケット廃棄率』、『Ｑｕｅｕｅ長』などをトラヒック分離統合装置から取得してもよい。なお、この場合には、統合ＡＡＡ装置１００は、これらの手法に対応する閾値を条件記憶部１２１に予め記憶する。
【００７７】
また、さらに、例えば、統合ＡＡＡ装置１００は、トラヒック分離統合装置との間で定期的に（または適当なタイミングに）通信を行い、例えば、測定用のパケットをトラヒック分離統合装置間で送受信させる。例えば、統合ＡＡＡ装置１００が、一方のトラヒック分離統合装置に対して測定用のパケットを送信し（『Priority Class』のトラヒックに挿入するなど）、他方のトラヒック分離統合装置から測定用のパケットを受信する。そして、統合ＡＡＡ装置１００は、測定用パケットの送信時の間隔と受信時の間隔とを比較し、その変動から空帯域を推定したり、遅延時間の伸びを実測するなどすることで、輻輳状態が生じたか否かを判定するための情報を取得してもよい。なお、この場合には、統合ＡＡＡ装置１００は、空帯域や遅延時間の伸びに対応する閾値を条件記憶部１２１に予め記憶する。
【００７８】
また、例えば、統合ＡＡＡ装置１００は、トラヒック分離統合装置との間で定期的に（または適当なタイミングに）通信を行い、例えば、一方のトラヒック分離統合装置において処理の対象とされたユーザパケットが他方のトラヒック分離統合装置に到達する場合に、２つのトラヒック分離統合装置間におけるユーザパケットの送信時の間隔と受信時の間隔とを比較し、その変動から空帯域を推定したり、遅延時間の伸びを実測するなどすることで、輻輳状態が生じたか否かを判定するための情報を取得してもよい。なお、この場合には、統合ＡＡＡ装置１００は、空帯域や遅延時間の伸びに対応する閾値を条件記憶部１２１に予め記憶する。
【００７９】
また、実施例１においては、統合ＡＡＡ装置１００が自発的に集合仮想ルータから情報を取得する、いわゆるプル型の監視を想定したが、開示の技術はこれに限られるものではなく、例えば、集合仮想ルータにて『ＣＰＵ使用率７０％』という閾値を記憶し、集合仮想ルータが、『ＣＰＵ使用率７０％』という閾値を超過するか否かを例えば１秒間隔に判定し、超過したと判定した場合に、集合仮想ルータが統合ＡＡＡ装置１００に対して通知する、いわゆるプッシュ型の監視でもよい。
【００８０】
また、実施例１においては、集合仮想ルータの入り側のＩ／Ｆにてトラヒックを廃棄する例を説明したが、開示の技術はこれに限られるものではない。例えば、トラヒック分離統合装置やアドレス変換装置などでトラヒックを廃棄してもよい。また、実施例１においては、『Best Effort Class』のトラヒックを廃棄する例を説明したが、これに限られるものではなく、廃棄の対象となるトラヒックと、輻輳状態が生じても廃棄の対象としないトラヒックとを特定する情報を統合ＡＡＡ装置が予め記憶し、この情報に基づいて廃棄を指示する制御を行ってもよい。
【００８１】
［実施例１に係るトラヒック制御処理手順］
図１２は、実施例１に係るトラヒック制御処理手順を示すフローチャートである。図１２に例示するように、統合ＡＡＡ装置１００において、トラヒック監視部１３１が、集合仮想ルータとの間で定期的に（または適当なタイミングに）通信を行い、集合仮想ルータにて収集されたＣＰＵ使用率を、集合仮想ルータから受信することで、トラヒックを監視する（ステップＳ１０１）。
【００８２】
そして、トラヒック監視部１３１は、集合仮想ルータからＣＰＵ使用率を受信すると、条件記憶部１２１を参照し、受信したＣＰＵ使用率が、『ＣＰＵ使用率７０％』という閾値を超過するか否かを判定することで、輻輳状態を判定する（ステップＳ１０２）。
【００８３】
閾値を超過しないと判定した場合には（ステップＳ１０３否定）、トラヒック監視部１３１は、ステップＳ１０１の処理に戻る。一方、閾値を超過すると判定した場合には（ステップＳ１０３肯定）、統合ＡＡＡ装置１００において、トラヒック制御部１３２が、仮想ルータ『ＶＲＦ２』側の経路であって集合仮想ルータの入り側のＩ／Ｆにて、『Best Effort Class』のトラヒックを廃棄するように指示する指示情報を、例えば『集合仮想ルータ１』に対して送信する（ステップＳ１０４）。
【００８４】
［実施例１の効果］
上述したように、実施例１において、統合ＡＡＡ装置１００は、集合仮想ルータと、ＶＰＮ終端装置と、トラヒック分離統合装置とを含むＶＰＮ間通信システムのトラヒックを制御する。具体的には、トラヒック監視部１３１が、集合仮想ルータ、トラヒック分離統合装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する。また、トラヒック制御部１３２が、情報が条件に該当すると判定された場合に、経路上のトラヒックを制御するための指示情報を、集合仮想ルータ、トラヒック分離統合装置のうち、少なくとも一つの装置に対して送信する。
【００８５】
例えば、トラヒック監視部１３は、取得した情報が条件に該当するか否かを判定することにより輻輳状態が生じたか否かを判定し、トラヒック制御部１３２は、輻輳状態が生じたと判定された場合に、複数の経路のうち優先度が低いトラヒック用の経路にてトラヒックを廃棄するように指示する指示情報を、集合仮想ルータ、トラヒック分離統合装置のうち、少なくとも一つの装置に対して送信する。
【００８６】
このようなことから、実施例１によれば、トラヒックを適切に制御することができる。この結果、輻輳を低減し、例えば、優先度の高いトラヒックを救済するといった制御ができることになる。
【実施例２】
【００８７】
［実施例２に係る統合ＡＡＡ装置によるトラヒック制御］
実施例２に係る統合ＡＡＡ装置は、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成された場合に、該経路上の装置を監視することにより、該装置から、高負荷状態が生じたか否かを判定するための情報を取得し、取得した情報が予め定められた条件に該当するか否かを判定する。そして、統合ＡＡＡ装置は、取得した情報が条件に該当すると判定した場合に、経路上のトラヒックを制御するための指示情報を、該経路を形成する装置に対して送信する。
【００８８】
高負荷状態が生じたか否かを判定するための情報として、例えば、トラヒックに関する情報やリソースに関する情報がある。具体的に例を挙げると、例えば、『集合仮想ルータのＣＰＵ使用率』、『集合仮想ルータのＩ／Ｆにて測定される利用中の帯域』、『集合仮想ルータのＩ／Ｆにて測定される空き帯域』、『集合仮想ルータのＩ／Ｆにて測定される帯域の利用率（Ｉ／Ｆに割り当てられている帯域に対する利用中の帯域の割合）』、『集合仮想ルータのＩ／Ｆにて測定されるパケットの転送量（単位時間あたりのパケット数及びパケットのサイズ）』、『集合仮想ルータのメモリ使用率』などがある。
【００８９】
この点、以下では、統合ＡＡＡ装置が、高負荷状態が生じたか否かを判定するための情報として『集合仮想ルータのＣＰＵ使用率』を取得する例を用いて説明する。実施例２に係る統合ＡＡＡ装置は、高負荷状態が生じたか否かを判定するための情報として『集合仮想ルータのＣＰＵ使用率』を取得し、取得した情報が予め定められた閾値を超過することにより高負荷状態が生じたか否かを判定する。また、統合ＡＡＡ装置は、高負荷状態が生じたと判定した場合に、高負荷状態が生じた経路上のトラヒックを他の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【００９０】
図１３は、実施例２に係るトラヒック制御を説明するための図である。図１３に例示するように、実施例２においては、ＶＰＮ１とＶＰＮ２との間に、例えばアプリケーションの種類に応じて分離された複数の経路として、仮想ルータ『ＶＲＦ１』の経路と、仮想ルータ『ＶＲＦ２』の経路と、仮想ルータ『ＶＲＦ３』の経路とが形成されている。なお、それぞれの経路は、いずれも異なる集合仮想ルータに形成されている。
【００９１】
図１３に例示するように、統合ＡＡＡ装置は、高負荷状態が生じたか否かを判定するための情報を、例えば集合仮想ルータから取得し、取得した情報が予め定められた閾値を超過することにより高負荷状態が生じたか否かを判定する。また、統合ＡＡＡ装置は、高負荷状態が生じたと判定した場合に、高負荷状態が生じた経路上のトラヒック、例えば、仮想ルータ『ＶＲＦ２』の経路上のトラヒックを、他の経路、例えば、仮想ルータ『ＶＲＦ１』の経路に割り当てるように指示する指示情報を、例えばトラヒック分離統合装置に対して送信する。
【００９２】
図１４は、実施例２に係る統合ＡＡＡ装置１００の構成を示すブロック図である。図１４に例示するように、実施例２に係る統合ＡＡＡ装置１００は、記憶部１２０に、トラヒック分離情報記憶部１２３を有する点が、実施例１に係る統合ＡＡＡ装置１００と異なる。
【００９３】
実施例２に係る条件記憶部１２１は、高負荷状態が生じたか否かを判定するための条件を記憶する。例えば、条件記憶部１２１は、高負荷状態が生じたか否かを判定するための条件として、『ＣＰＵ使用率７０％』という閾値を記憶する。
【００９４】
実施例２に係る制御情報記憶部１２２は、実施例１と同様、統合ＡＡＡ装置１００による制御に用いられる各種情報を記憶する。図１５は、制御情報を説明するための図である。例えば、制御情報記憶部１２２は、図１５の（Ａ）に例示するように、監視対象となる集合仮想ルータについて、識別情報及びアドレスを記憶する。また、制御情報記憶部１２２は、図１５の（Ａ）に例示するように、情報取得の契機、判定条件、条件該当時の制御、条件非該当時の制御などを記憶する。なお、図１５においては、１つの集合仮想ルータに関する制御情報を例示するが、これに限られるものではなく、制御情報記憶部１２２は、例えば図１３に例示する３つの集合仮想ルータそれぞれに関する制御情報を記憶する。また、制御情報記憶部１２２は、図１５の（Ｂ）に例示するように、トラヒック分離統合装置について、識別情報及びアドレスを記憶する。
【００９５】
なお、これらの制御情報は一例に過ぎない。例えば、情報取得の契機や判定条件、条件該当時の制御、条件非該当時の制御などは、監視対象となる装置に応じて異なってもよく、また、同種の装置（例えば集合仮想ルータ間など）では、同じになってもよい。
【００９６】
例えば、図１５の例で説明すると、統合ＡＡＡ装置１００によって監視される集合仮想ルータは、『集合仮想ルータ１』（例えば図１３に例示する最も左側の集合仮想ルータが相当する）であり、この集合仮想ルータとの間で通信を行う場合には、『ＩＰアドレス１』を用いる。また、制御情報記憶部１２２は、情報取得の契機、すなわち監視のタイミングとして、例えば『１秒間隔』を記憶する。また、制御情報記憶部１２２は、判定条件として、『条件記憶部１２１に記憶された条件』を記憶する。すなわち、上述したように、『ＣＰＵ使用率７０％』という閾値が判定条件であることを示す。
【００９７】
また、制御情報記憶部１２２は、条件に該当した時の制御内容として、「条件に該当しる仮想ルータに割り当てられているアプリケーションを、他の仮想ルータに割り当てるように指示する指示情報を、『トラヒック分離統合装置１、２』に対して送信すること」を記憶する。なお、実施例２においては条件に該当しなくなった場合の制御を行わないが、例えば後述するように、監視を継続している中で閾値を超えなくなったと判定する場合もある。このような場合には、制御情報記憶部１２２は、例えば図１５に例示するように、「経路の割り当てを元に戻すように指示する指示情報を『トラヒック分離統合装置１、２』に対して送信すること」を記憶してもよい。
【００９８】
トラヒック分離情報記憶部１２３は、トラヒック分離統合装置においてどのようなポリシーに従ってトラヒックが分離されているかを示す分離情報を記憶する。トラヒック分離情報記憶部１２３は、例えば統合ＡＡＡ装置１００がトラヒック分離統合装置との間で定期的に通信を行うことによりトラヒック分離統合装置から取得した分離情報を記憶する。トラヒック分離情報記憶部１２３が記憶する分離情報は、トラヒック制御部１３２による処理に用いられる。
【００９９】
図１６は、分離情報を説明するための図である。例えば、トラヒック分離情報記憶部１２３は、図１６に例示するように、経路毎に、該経路に割り当てられたアプリケーションを識別する情報を記憶する。例えば、図１６は、仮想ルータ『ＶＲＦ１』の経路には、アプリケーション『ＡＰ１』及び『ＡＰ２』が割り当てられ、仮想ルータ『ＶＲＦ２』の経路には、アプリケーション『ＡＰ３』及び『ＡＰ４』が割り当てられ、仮想ルータ『ＶＲＦ３』の経路には、アプリケーション『ＡＰ５』及び『ＡＰ６』が割り当てられることを示す。
【０１００】
実施例２に係るトラヒック監視部１３１は、高負荷状態が生じたか否かを判定するための情報を経路毎に取得し、取得した情報が予め定められた閾値を超過することにより高負荷状態が生じたか否かを判定する。そして、トラヒック監視部１３１は、高負荷状態が生じたと判定した場合には、その旨をトラヒック制御部１３２に通知する。
【０１０１】
実施例２に係るトラヒック制御部１３２は、トラヒック監視部１３１によって高負荷状態が生じたと判定された場合に、高負荷状態が生じた経路上のトラヒックを他の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【０１０２】
例えば、トラヒック制御部１３２は、仮想ルータ『ＶＲＦ２』の経路において閾値を超過すると判定した旨の通知をトラヒック監視部１３１から受け付けると、制御情報記憶部１２２を参照し、条件該当時の制御内容として記憶された情報を取得する。そして、トラヒック制御部１３２は、トラヒック分離情報記憶部１２３を参照し、仮想ルータ『ＶＲＦ２』に割り当てられているアプリケーション『ＡＰ３』、『ＡＰ４』のうち少なくともいずれか一つを、他の仮想ルータ『ＶＲＦ１』の経路又は『ＶＲＦ３』の経路に割り当てることを判定する。ここで、他の仮想ルータ『ＶＲＦ１』の経路又は『ＶＲＦ３』の経路のうち、いずれの経路に割り当てるかについては、例えば２つの手法が考えられる。１つは、統合ＡＡＡ装置１００は、集合仮想ルータそれぞれからＣＰＵ使用率を受信しているので、例えば、最も負荷が低い状態（ＣＰＵ使用率が低い状態）の集合仮想ルータに形成された経路を動的に選択して割り当てる手法である。もう１つは、予め割り当てのルールを決定して記憶部に記憶しておき、トラヒック制御部１３２が、このルールに従って経路を選択し、割り当てる手法である。
【０１０３】
そして、トラヒック制御部１３２は、例えば、仮想ルータ『ＶＲＦ２』に割り当てられているアプリケーション『ＡＰ３』を、最も負荷が低い状態であると判定された仮想ルータ『ＶＲＦ１』に割り当てるように指示する指示情報を、例えば『トラヒック分離統合装置１、２』に対して送信する。このとき、トラヒック制御部１３２は、制御情報記憶部１２２を参照し、例えば、『ＩＰアドレスＴ−１』を用いて『トラヒック分離統合装置１』との間で通信を行い、指示情報を送信する。高負荷状態となった経路上のトラヒックを他の経路に割り当てることで、負荷分散を実現することができ、例えば、ユーザ数が増えてきた場合などにも、拡張性高く、ＶＰＮ間接続サービスを提供することができる。
【０１０４】
なお、実施例２においては、高負荷状態が生じたか否かを判定するための情報として、『集合仮想ルータのＣＰＵ使用率』を取得する例を説明したが、開示の技術はこれに限られるものではない。上述したように、例えば、高負荷状態が生じたか否かを判定するための情報として、『集合仮想ルータのＩ／Ｆにて測定される利用中の帯域』、『集合仮想ルータのＩ／Ｆにて測定される空き帯域』、『集合仮想ルータのＩ／Ｆにて測定される帯域の利用率（Ｉ／Ｆに割り当てられている帯域に対する利用中の帯域の割合）』、『集合仮想ルータのＩ／Ｆにて測定されるパケットの転送量（単位時間あたりのパケット数及びパケットのサイズ）』、『集合仮想ルータのメモリ使用率』などが用いられることもある。
【０１０５】
例えば、統合ＡＡＡ装置１００は、あるＩ／Ｆにて測定された『利用中の帯域』が所定の閾値よりも大きければ、このＩ／Ｆに対応する経路にて高負荷状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、あるＩ／Ｆにて測定された『空き帯域』が所定の閾値よりも小さければ、このＩ／Ｆに対応する経路にて高負荷状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、あるＩ／Ｆにて測定された『利用率』が所定の閾値よりも高ければ、このＩ／Ｆに対応する経路にて高負荷状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、あるＩ／Ｆにて測定された『単位時間あたりのパケット数』が所定の閾値よりも多く、かつ、『パケットのサイズ』が所定の閾値よりも小さい場合には、例えばルーティング処理の負荷が高くなるので、このＩ／Ｆに対応する経路にて高負荷状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、ある集合仮想ルータの『メモリ使用率』が所定の閾値よりも高ければ、この集合仮想ルータに対応する経路にて高負荷状態が生じたと判定する。なお、上記したこれらの手法を用いる場合には、統合ＡＡＡ装置１００は、各手法に対応する閾値を条件記憶部１２１に予め記憶する。また、同様に、例えば、統合ＡＡＡ装置１００は、高負荷状態が生じたか否かを判定するための情報として、トラヒック分離統合装置にて収集された『利用中の帯域』、『空帯域』、『帯域の利用率』、『パケットの転送量』などをトラヒック分離統合装置から取得してもよい。なお、この場合には、統合ＡＡＡ装置１００は、これらの手法に対応する閾値を条件記憶部１２１に予め記憶する。
【０１０６】
また、実施例２においては、統合ＡＡＡ装置１００が自発的に集合仮想ルータから情報を取得する、いわゆるプル型の監視を想定したが、開示の技術はこれに限られるものではなく、例えば、集合仮想ルータにて『ＣＰＵ使用率７０％』という閾値を記憶し、集合仮想ルータが、『ＣＰＵ使用率７０％』という閾値を超過するか否かを例えば１秒間隔に判定し、超過したと判定した場合に、集合仮想ルータが統合ＡＡＡ装置１００に対して通知する、いわゆるプッシュ型の監視でもよい。
【０１０７】
また、実施例２においては、統合ＡＡＡ装置１００が集合仮想ルータを監視し、動的に経路の割り当てを変更する例を説明したが、開示の技術はこれに限られるものではない。例えば、ＶＰＮ側からトラヒック分離統合装置へと流入するパケットを、一つ一つ順番に複数の経路に振り分けることで、負荷分散を実現してもよい。このような手法によれば、複数の経路の使用率（それぞれの集合仮想ルータの使用率）が等しく分散され、負荷分散される。
【０１０８】
また、実施例２においては、統合ＡＡＡ装置１００が集合仮想ルータを監視し、ある経路において高負荷状態が生じたことを判定して、経路の割り当てを変更する例を説明したが、開示の技術はこれに限られるものではない。例えば、ＶＰＮ間接続において新たなアプリケーションが利用されたり、新たな端末が接続されるなど、新たにトラヒックが発生した時点で、統合ＡＡＡ装置１００は、経路毎に、負荷状態を示す情報（例えば『集合仮想ルータのＣＰＵ使用率』など）を取得し、取得した情報を用いて経路間の負荷を比較した上で、最も負荷の低い経路に対して新たに発生したトラヒックを割り当てることにより、経路間で負荷が偏らないように制御してもよい。
【０１０９】
すなわち、例えば、条件記憶部１２１は、新たなトラヒックが発生したか否かを判定するための条件を記憶する。例えば、条件記憶部１２１は、『集合仮想ルータから、アプリケーションの追加が行われた旨の通知を受けたこと』や、『ＶＰＮ終端装置から、端末の追加が行われた旨の通知を受けたこと』を記憶する。そして、トラヒック監視部１３１は、集合仮想ルータやＶＰＮ終端装置から上記通知を受け取ると、条件記憶部１２１を参照し、該通知が条件記憶部１２１に記憶されている条件に該当するか否かを判定することで、新たなトラヒックが発生したか否かを判定する。そして、トラヒック制御部１３２が、集合仮想ルータそれぞれから経路毎に『集合仮想ルータのＣＰＵ使用率』を取得し、各経路間の負荷の高さを比較し、最も負荷が低い経路を判定する。すなわち、トラヒック制御部１３２は、比較の結果に基づいて、低負荷状態の経路として最も負荷が低い経路を特定する。続いて、トラヒック制御部１３２は、低負荷状態の経路として特定した経路、すなわち最も負荷が低いと判定された経路に対し、新たに発生したトラヒックを割り当てるように指示する指示情報を、トラヒック分離統合装置に対して送信する。
【０１１０】
さらに、統合ＡＡＡ装置は、監視を継続している中で、経路の割り当てを変更したトラヒックを元の経路に戻しても元の集合仮想ルータの負荷が閾値を超えなくなったと判定した場合には、経路の割り当てを元に戻すように指示する指示情報を、該当する装置に対して送信してもよい。この場合には、例えば、トラヒック制御部１３２が、図１５に例示したように、制御情報記憶部１２２に記憶された「条件非該当時の制御」に従って制御を行えばよい。例えば、上記例では、経路の割り当てを変更するか否かを判定するために、『ＣＰＵ使用率７０％』という閾値を超過するか否かを判定していたが、例えば、集合仮想ルータは、『ＣＰＵ使用率７０％』とは別に『ＣＰＵ使用率５０％』という第二の閾値を記憶し、元の経路に戻してもよいか否かを判定するために、この第二の閾値『ＣＰＵ使用率５０％』を下回るか否かを判定してもよい。もっとも、経路の割り当てを変更したトラヒックを元の経路に戻さずそのまま運用してもよい。すなわち、例えば、一旦経路の割り当てを変更すると、トラヒック制御部１３２は、割り当て後の状態を初期状態として監視を開始し、割り当て後の経路で例えば『ＣＰＵ使用率７０％』という閾値を超過した場合に、再び、経路の割り当てを変更する、といった制御でもよい。なお、新たに発生したトラヒックの割り当て先として、最も負荷が低い経路を特定する例を説明したが、開示の技術はこれに限られるものではない。新たに発生したトラヒックの割り当て先は、最も負荷が低いと特定された経路だけではなく、例えば、Ｎ個の経路中、負荷の低い順にＭ個の経路を低負荷状態の経路と判断し、この低負荷状態の経路のうち１以上の経路を新たに発生したトラヒックの割り当て先としてもよい。このとき、条件記憶部１２１には、下位Ｍ個を判定するための閾値などの条件情報が記憶されていることになる。
【０１１１】
また、例えば、ポリシーベースのルーティングにより、固定的にアプリケーションを割り当てる経路を決定し、静的に負荷分散を実現する手法も考えられる。例えば、特定のアプリケーションやＴｏＳ値などでアプリケーションを分類し、トラヒック分離統合装置においてポリシーベースでルーティングする。
【０１１２】
また、実施例２においては、統合ＡＡＡ装置１００が複数の集合仮想ルータそれぞれを監視し、ある集合仮想ルータから取得されたＣＰＵ使用率が所定の閾値（例えば『ＣＰＵ使用率７０％』）超過することにより、この集合仮想ルータに対応する経路において高負荷状態が生じたことを判定する例を説明したが、開示の技術はこれに限られるものではない。複数の集合仮想ルータそれぞれから取得した情報に基づいて集合仮想ルータ間の負荷の偏りを判定することにより、ある集合仮想ルータに対応する経路において負荷が高い方向に偏っている（すなわち高負荷状態が生じている）ことを判定してもよい。
【０１１３】
例えば、４台の集合仮想ルータが、それぞれ、４つの経路を形成しているとする。条件記憶部１２１は、負荷に偏りが生じているか否かを判定するための条件として、例えば『集合仮想ルータのＣＰＵ使用率』の分散値の閾値を記憶する。そして、トラヒック監視部１３１は、４台の集合仮想ルータそれぞれとの間で定期的に（または適当なタイミングに）通信を行い、集合仮想ルータそれぞれにて収集されたＣＰＵ使用率を、集合仮想ルータそれぞれから受信する。例えば、トラヒック監視部１３１は、『１００％』、『５０％』、『５０％』、『０％』を取得する。
【０１１４】
次に、トラヒック監視部１３１は、取得したこれらの情報を用いて、『集合仮想ルータのＣＰＵ使用率』の分散値を求め、条件記憶部１２１に記憶されている分散値の閾値と比較して、集合仮想ルータ間に負荷の偏りが生じているか否かを判定する。ここで、求めた分散値が閾値を超過していて、負荷の偏りが生じていると判定した場合には、続いて、トラヒック制御部１３２が、トラヒック監視部１３１によって取得された４つのＣＰＵ使用率を比較し、最も高いＣＰＵ使用率を示す集合仮想ルータに対応する経路と、最も低いＣＰＵ使用率を示す集合仮想ルータに対応する経路とを特定する。そして、トラヒック制御部１３２は、最も負荷が低いと判定された経路に対し、最も負荷が高いと判定された経路を流れているトラヒックの一部又は全部を割り当てるように指示する指示情報を、トラヒック分離統合装置に対して送信する。なお、この割り当ては、ユーザ単位、アプリケーション単位、ＱｏＳクラス単位など、任意の単位で行うことができる。例えば、ＣＰＵ使用率『１００％』の集合仮想ルータに対応する経路を１０名のユーザが利用している場合には、５名のユーザのトラヒック分を、ＣＰＵ使用率『０％』の集合仮想ルータに対応する経路に割り当てればよい。このとき、１０名のユーザそれぞれによるＣＰＵ使用率が等しいと仮定すると、これにより、４台の集合仮想ルータのＣＰＵ使用率は、それぞれ５０％となり、負荷の偏りを抑えることになる。また、例えば、最も負荷の高い経路を流れているトラヒックの一部又は全部を、その他の１つ以上の経路にそれぞれ適当に割り当てることによって、負荷の偏りを抑えてもよい。なお、トラヒックを割り当てる際の配分は、上記例に限られるものではなく、負荷の偏りや運用の形態などに応じて任意に変更し得るものである。
【０１１５】
［実施例２に係るトラヒック制御処理手順］
図１７は、実施例２に係るトラヒック制御処理手順を示すフローチャートである。図１７に例示するように、統合ＡＡＡ装置１００において、トラヒック監視部１３１が、集合仮想ルータとの間で定期的に（または適当なタイミングに）通信を行い、集合仮想ルータにて収集されたＣＰＵ使用率を、集合仮想ルータから受信することで、トラヒックを監視する（ステップＳ２０１）。
【０１１６】
そして、トラヒック監視部１３１は、集合仮想ルータからＣＰＵ使用率を受信すると、条件記憶部１２１を参照し、受信したＣＰＵ使用率が、『ＣＰＵ使用率７０％』という閾値を超過するか否かを判定することで、高負荷状態を判定する（ステップＳ２０２）。
【０１１７】
閾値を超過しないと判定した場合には（ステップＳ２０３否定）、トラヒック監視部１３１は、ステップＳ２０１の処理に戻る。一方、閾値を超過すると判定した場合には（ステップＳ２０３肯定）、統合ＡＡＡ装置１００において、トラヒック制御部１３２が、例えば、仮想ルータ『ＶＲＦ２』に割り当てられているアプリケーション『ＡＰ３』を、仮想ルータ『ＶＲＦ１』に割り当てるように指示する指示情報を、トラヒック分離統合装置に対して送信する（ステップＳ２０４）。
【０１１８】
［実施例２の効果］
上述したように、実施例２において、トラヒック監視部１３１は、集合仮想ルータから経路毎に取得した情報が条件に該当するか否かを判定することにより高負荷状態が生じたか否かを判定し、トラヒック制御部１３２は、高負荷状態が生じたと判定された場合に、高負荷状態が生じた経路上のトラヒックを他の経路に割り当てるように指示する指示情報を、少なくともトラヒック分離統合装置に対して送信する。
【０１１９】
あるいは、実施例２において、トラヒック監視部１３１は、取得した情報が条件に該当するか否かを判定することにより、ＶＰＮ間通信システムにおいて制御対象となる新たなトラヒックが発生したことを判定し、トラヒック制御部１３２は、新たなトラヒックが発生したと判定された場合に、集合仮想ルータから経路毎に取得した情報を用いて経路間の負荷状態を比較し、比較の結果に基づいて低負荷状態の経路を特定し、新たに発生したトラヒックを、特定した該経路に割り当てるように指示する指示情報を、少なくともトラヒック分離統合装置に対して送信する。
【０１２０】
このようなことから、実施例２によれば、トラヒックを適切に制御することができる。すなわち、高負荷状態となった経路上のトラヒックを他の経路に割り当てることで、負荷分散を実現することができる。あるいは、新たに発生したトラヒックを、もっとも負荷の低い経路に割り当てることにより、経路間で負荷が偏ることを防ぐように負荷分散を実現することができる。例えば、ユーザ数が増えてきた場合などにも、拡張性高く、ＶＰＮ間接続サービスを提供することができる。
【実施例３】
【０１２１】
［実施例３に係る統合ＡＡＡ装置によるトラヒック制御］
実施例３に係る統合ＡＡＡ装置は、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成された場合に、該経路上の装置を監視することにより、該装置から、故障状態が生じたか否かを判定するための情報を取得し、取得した情報が予め定められた条件に該当するか否かを判定する。そして、統合ＡＡＡ装置は、取得した情報が条件に該当すると判定した場合に、経路上のトラヒックを制御するための指示情報を、該経路を形成する装置に対して送信する。
【０１２２】
故障状態が生じたか否かを判定するための情報として、例えば、トラヒックに関する情報やリソースに関する情報がある。具体的に例を挙げると、例えば、『死活確認パケットの受信状況』、『経路を形成する各装置のＩ／Ｆで観測されるトラヒック量』、『集合仮想ルータに設定された動的なルーティング情報の消滅』などがある。
【０１２３】
この点、以下では、統合ＡＡＡ装置が、故障状態が生じたか否かを判定するための情報として『死活確認パケットの受信状況』を取得する例を用いて説明する。実施例３に係る統合ＡＡＡ装置は、故障状態が生じたか否かを判定するための情報として『死活確認パケットの受信状況』を取得し、『死活確認パケットが正常に受信できない』という判定条件に該当するか否かを判定することにより、故障状態が生じたか否かを判定する。また、統合ＡＡＡ装置は、故障状態が生じたと判定した場合に、故障状態が生じた経路上のトラヒックを予備用の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【０１２４】
図１８は、実施例３に係るトラヒック制御を説明するための図である。図１８に例示するように、実施例３においては、ＶＰＮ１とＶＰＮ２との間に、例えばアプリケーションの種類に応じて分離される等のポリシにより複数の経路として、仮想ルータ『ＶＲＦ１』の経路と、仮想ルータ『ＶＲＦ２』の経路と、仮想ルータ『ＶＲＦ３』の経路とが形成されている。なお、それぞれの経路は、いずれも異なる集合仮想ルータに形成されている。ここで、仮想ルータ『ＶＲＦ３』の経路は、予備用（Back Up用）の経路である。すなわち、仮想ルータ『ＶＲＦ３』が設定された集合仮想ルータは、物理的な接続が完了した状態にある。
【０１２５】
図１８に例示するように、統合ＡＡＡ装置は、故障状態が生じたか否かを判定するための情報を、例えば、集合仮想ルータやトラヒック分離統合装置から取得し、取得した情報が予め定められた条件に該当するか否かを判定することにより故障状態が生じたことを検出する。また、統合ＡＡＡ装置は、故障状態が生じたことを検出した場合に、故障状態が生じた経路上のトラヒック、例えば、仮想ルータ『ＶＲＦ２』上のトラヒックを、予備用の経路、例えば、仮想ルータ『ＶＲＦ３』の経路に割り当てるように指示する指示情報を、例えばトラヒック分離統合装置及びアドレス変換装置に対して送信する。
【０１２６】
図１９は、実施例３に係る統合ＡＡＡ装置１００の構成を示すブロック図である。図１９に例示するように、実施例３に係る統合ＡＡＡ装置１００は、記憶部１２０に、設定情報記憶部１２４を有する点が、実施例１に係る統合ＡＡＡ装置１００と異なる。
【０１２７】
実施例３に係る条件記憶部１２１は、故障状態が生じたか否かを判定するための条件を記憶する。例えば、条件記憶部１２１は、故障状態が生じたか否かを判定するための条件として、『死活確認パケットが正常に受信できない』を記憶する。
【０１２８】
実施例３に係る制御情報記憶部１２２は、実施例１と同様、統合ＡＡＡ装置１００による制御に用いられる各種情報を記憶する。図２０及び２１は、制御情報を説明するための図である。例えば、制御情報記憶部１２２は、図２０の（Ａ）に例示するように、監視対象となるトラヒック分離統合装置及び集合仮想ルータについて、アドレスを記憶する。ここで、後述するように、実施例３に係るトラヒック監視部１３１は、経路毎に、トラヒック分離統合装置、集合仮想ルータ、トラヒック分離統合装置の順で死活確認用のパケットを経路上に流すことで、その経路の死活確認、すなわち故障状態（経路上のいずれかの装置に故障が生じたことにより、経路に故障が生じているか否か）を監視する。このため、実施例３に係る制御情報記憶部１２２は、図２０の（Ａ）に例示するように、経路毎に、死活確認用のパケットを流す順序にて、アドレスを記憶する。
【０１２９】
また、制御情報記憶部１２２は、図２０の（Ｂ）に例示するように、情報取得の契機、判定条件、条件該当時の制御、条件非該当時の制御などを記憶する。また、制御情報記憶部１２２は、図２１の（Ｃ）に例示するように、各装置の識別情報及びアドレスを記憶する。なお、これらの制御情報は一例に過ぎない。例えば、情報取得の契機や判定条件、条件該当時の制御、条件非該当時の制御などは、監視対象となる装置に応じて異なってもよい。
【０１３０】
例えば、図２０の（Ｂ）の例で説明すると、制御情報記憶部１２２は、情報取得の契機、すなわち監視のタイミングとして、例えば『１秒間隔』を記憶する。また、制御情報記憶部１２２は、判定条件として、『条件記憶部１２１に記憶された条件』を記憶する。すなわち、上述したように、『死活確認パケットが正常に受信できない』であることが判定条件であることを示す。
【０１３１】
また、制御情報記憶部１２２は、条件に該当した時の制御内容として、「（１）条件に該当した仮想ルータの設定情報を予備用の集合仮想ルータに送信すること、条件に該当した仮想ルータの経路上のアドレス変換装置にて用いられていたアドレス変換情報を、予備用の経路上のアドレス変換装置に送信すること」を記憶するとともに、「（２）条件に該当した仮想ルータの経路上のトラヒックを予備用の経路に割り当てるように指示する指示情報を、トラヒック分離統合装置に対して送信すること」を記憶する。すなわち、後述するように、トラヒック制御部１３２は、条件に該当した時には、（１）及び（２）の双方に従って制御を行う。
【０１３２】
設定情報記憶部１２４は、経路毎に、仮想ルータの設定情報及びアドレス変換装置の設定情報を記憶する。設定情報記憶部１２４は、例えば集合仮想ルータやアドレス変換装置との間で定期的に通信を行うことにより取得した設定情報を記憶し、設定情報記憶部１２４が記憶する設定情報は、後述するトラヒック監視部１３１による処理に用いられる。
【０１３３】
図２２は、設定情報を説明するための図である。例えば、設定情報記憶部１２４は、図２２に例示するように、経路毎に、該経路を形成するために集合仮想ルータに設定された仮想ルータの設定情報や、該経路を形成するためにアドレス変換装置に設定された設定情報を記憶する。
【０１３４】
実施例３に係るトラヒック監視部１３１は、故障状態が生じたか否かを判定するための情報を取得し、取得した情報が予め定められた条件に該当するか否かを判定することにより故障状態が生じたことを検出する。そして、トラヒック監視部１３１は、故障状態が生じたことを検出した場合には、その旨をトラヒック制御部１３２に通知する。
【０１３５】
例えば、トラヒック監視部１３１は、経路毎に、トラヒック分離統合装置、集合仮想ルータ、トラヒック分離統合装置の順で死活確認用のパケットを経路上に流すことで、その経路の死活確認、すなわち故障状態（経路上のいずれかの装置に故障が生じたことにより、経路に故障が生じているか否か）を監視する。このとき、トラヒック監視部１３１は、制御情報記憶部１２２を参照し、例えば、『ＩＰアドレスＴ−１』を用いてトラヒック分離統合装置との間で通信を行い、情報取得の契機『１秒間隔』に従って、『ＶＲＦ１』の経路に、死活確認用のパケットを流す。また、トラヒック監視部１３１は、『ＩＰアドレスＴ−２』を用いてトラヒック分離統合装置との間で通信を行い、自らが流した死活確認用パケットを受信する。また、トラヒック監視部１３１は、条件記憶部１２１を参照し、『死活確認パケットが正常に受信できない』が判定条件であることを取得しているので、自らが流した死活確認用パケットを受信できないと故障と判定し、その旨をトラヒック制御部１３２に通知する。すなわち、自らが流した死活確認用パケットを受信できない場合とは、経路上のいずれかの装置に故障が生じ、パケットが通らなくなった場合であるので、その経路は故障であると判定する。
【０１３６】
実施例３に係るトラヒック制御部１３２は、トラヒック監視部１３１によって故障状態が生じたと判定された場合に、故障状態が生じた経路上のトラヒックを予備用の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【０１３７】
例えば、トラヒック制御部１３２は、仮想ルータ『ＶＲＦ２』の経路において故障状態が生じたと判定した旨の通知をトラヒック監視部１３１から受け付けると、制御情報記憶部１２２を参照し、条件該当時の制御内容として記憶された情報を取得する。そして、トラヒック制御部１３２は、設定情報記憶部１２４を参照し、仮想ルータ『ＶＲＦ２』に対応付けて記憶されている各種設定情報を取得する。そして、トラヒック制御部１３２は、『ＶＲＦ２の設定情報』を予備用の集合仮想ルータに送信し、仮想ルータ『ＶＲＦ３』の設定に反映するとともに、『アドレス変換装置の設定情報』を、仮想ルータ『ＶＲＦ３』の経路上のアドレス変換装置に送信し、アドレス変換装置の設定に反映する。さらに、トラヒック制御部１３２は、例えば、仮想ルータ『ＶＲＦ２』上のトラヒックを、予備用の経路、例えば、仮想ルータ『ＶＲＦ３』の経路に割り当てるように指示する指示情報を、例えばトラヒック分離統合装置及びアドレス変換装置に対して送信する。その後、例えば、運用者は、故障した装置を取り替えればよい。また、故障した装置の修理後には、今度は予備用の装置として設置すればよい。なお、このような切替及びトラヒックの迂回は、故障時のみならず、例えば、装置のバージョンアップや更改時などにも適用することができる。
【０１３８】
なお、実施例３においては、故障状態を検出した際に、動的に集合仮想ルータやアドレス変換装置に設定される例を説明したが、開示の技術はこれに限られるものではない。例えば、各種設定情報は、予め予備用の集合仮想ルータやアドレス変換装置に設定されていてもよい。例えば、実施例１において説明したアドレスの払い出し方式（１）を適用する場合には、仮想ルータ『ＶＲＦ１』の設定と仮想ルータ『ＶＲＦ２』の設定とは同じであるので、仮想ルータ『ＶＲＦ３』には、仮想ルータ『ＶＲＦ１』（又は『ＶＲＦ２』）と同じ設定をしておけばよい。また、実施例１において説明したアドレスの払い出し方式（２）を適用する場合には、仮想ルータ『ＶＲＦ１』の設定と仮想ルータ『ＶＲＦ２』の設定とは異なるので、仮想ルータ『ＶＲＦ３』には、仮想ルータ『ＶＲＦ１』及び『ＶＲＦ２』それぞれと同じ設定をしておけばよい。
【０１３９】
また、実施例３においては、監視対象の経路で故障状態が生じたか否かを判定するための条件として、『死活確認パケットが正常に受信できない』という閾値を記憶する例を説明したが、開示の技術はこれに限られるものではない。例えば、統合ＡＡＡ装置１００が、集合仮想ルータの入り側のＩ／Ｆのトラヒック量と、出力側のＩ／Ｆのトラヒック量とを取得し、入り側のＩ／Ｆでトラヒックが観測されているにもかかわらず、出力側のＩ／Ｆでトラヒックが観測されないといった点から、故障状態が生じたと判定する手法でもよい。また、集合仮想ルータのＩ／Ｆにおいて観測されるトラヒック量に限られず、経路上の他の装置のＩ／Ｆにおいて観測されるトラヒック量を用いてもよい。また、例えば、集合仮想ルータに設定されたルーティング情報が、所定時間利用されない場合には消滅する、といった動的なものであったとする。このような場合には、統合ＡＡＡ装置１００は、「集合仮想ルータに設定されたルーティング情報が消滅した」との情報を集合仮想ルータから収集することで、消滅したルーティング情報に対応する経路に故障状態が生じたことを判定することができる。
【０１４０】
［実施例３に係るトラヒック制御処理手順］
図２３は、実施例３に係るトラヒック制御処理手順を示すフローチャートである。図２３に例示するように、統合ＡＡＡ装置１００において、トラヒック監視部１３１が、経路毎に、トラヒック分離統合装置、集合仮想ルータ、トラヒック分離統合装置の順で死活確認用のパケットを経路上に流すことで、トラヒックを監視する。（ステップＳ３０１）。
【０１４１】
そして、トラヒック監視部１３１は、条件記憶部１２１を参照し、自らが流した死活確認用パケットを受信できているか否かを判定することで、故障状態を検出する（ステップＳ３０２）。
【０１４２】
自らが流した死活確認用パケットを受信した場合には（ステップＳ３０３否定）、トラヒック監視部１３１は、ステップＳ３０１の処理に戻る。一方、自らが流した死活確認用パケットを受信できない場合、すなわち故障状態を検出した場合には（ステップＳ３０３肯定）、統合ＡＡＡ装置１００において、トラヒック制御部１３２が、例えば、仮想ルータ『ＶＲＦ２』上のトラヒックを、予備用の経路、例えば、仮想ルータ『ＶＲＦ３』の経路に割り当てるように指示する指示情報を、例えばトラヒック分離統合装置及びアドレス変換装置に対して送信する。（ステップＳ３０４）。
【０１４３】
［実施例３の効果］
上述したように、実施例３において、トラヒック監視部１３１は、死活確認を経路毎に実行することで経路の異常を示す情報を取得し、取得した情報が予め定められた条件に該当することにより故障状態が生じたか否かを判定し、トラヒック制御部１３２は、故障状態が生じたと判定された場合に、故障状態が生じた経路上のトラヒックを予備用の経路に割り当てるように指示する指示情報を、少なくともトラヒック分離統合装置に対して送信する。
【０１４４】
このようなことから、実施例３によれば、故障状態を検知し、予備用の経路に切り替えることが可能になり、トラヒックを適切に制御することができる。
【実施例４】
【０１４５】
［実施例４に係る統合ＡＡＡ装置によるトラヒック制御］
実施例４に係る統合ＡＡＡ装置は、ＶＰＮ間にトラヒック種別毎に分離された複数の経路が形成された場合に、該経路上の装置を監視することにより、該装置から、リソース借用の要否を判定するための情報を取得し、取得した情報が予め定められた条件に該当するか否かを判定する。そして、統合ＡＡＡ装置は、取得した情報が条件に該当すると判定した場合に、経路上のトラヒックを制御するための指示情報を、該経路を形成する装置に対して送信する。
【０１４６】
リソース借用の要否を判定するための情報として、例えば、トラヒックに関する情報やリソースに関する情報がある。具体的に例を挙げると、例えば、『アプリケーションサーバ（「サービス提供装置」とも称する）毎のＣＰＵ使用率』、『アプリケーションサーバ毎のディスク空き容量』、『アプリケーションサーバ毎のメモリ使用率』などがある。また、例えば、『経路上を流れる測定用のパケットやユーザパケットにより測定されるアプリケーションのレスポンスタイム』などがある。
【０１４７】
この点、以下では、統合ＡＡＡ装置が、リソース借用の要否を判定するための情報として『アプリケーションサーバ毎のＣＰＵ使用率』を取得する例を用いて説明する。実施例４に係る統合ＡＡＡ装置は、リソース借用の要否を判定するための情報として『アプリケーションサーバ毎のＣＰＵ使用率』を取得し、取得した情報が予め定められた閾値を超過することによりリソース借用が必要な状態（リソース不足状態）が生じたか否かを判定する。また、統合ＡＡＡ装置は、リソース不足状態が生じたと判定した場合に、リソース不足状態が生じたアプリケーションサーバを代替するアプリケーションサーバを探索し、リソース不足状態が生じたアプリケーションサーバ用の経路上のトラヒックを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【０１４８】
図２４及び２５は、実施例４に係るトラヒック制御を説明するための図である。図２４に例示するように、実施例４においては、ＶＰＮ１とＶＰＮ２との間に、例えばアプリケーションの種類に応じて分離された複数の経路として、仮想ルータ『ＶＲＦ１』の経路と、仮想ルータ『ＶＲＦ２』の経路とが形成されている。それぞれの経路は、いずれも異なる集合仮想ルータに形成されている。また、仮想ルータ『ＶＲＦ２』の経路には、２つのアプリケーション『ＡＰＳ（Application Server）１』及び『ＡＰＳ２』が動作するアプリケーションサーバ（物理的な筐体は１つ）が接続されている。図２４において、『東京ＡＰＳ』は、物理的な筐体としてのアプリケーションサーバを示し、『東京ＡＰＳ』上で、『ＡＰＳ１』及び『ＡＰＳ２』が動作しているものとする。
【０１４９】
ところで、図２４に例示する仮想ルータ『ＶＲＦ３』の経路は、代替のアプリケーションサーバ用の経路である。このような経路は、予め構築されていてもよいし、代替のアプリケーションサーバに切り替える時点で、オンデマンドに構築されてもよい。経路の構築は、上述したＶＰＮ間接続管理システムによって行われるので、例えば、オンデマンドに構築される場合には、統合ＡＡＡ装置は、代替のアプリケーションサーバを探索すると、代替のアプリケーションサーバとの間に新たに経路を構築するように、ＶＰＮ間接続管理システムに依頼（ＶＰＮ間接続要求を送信）すればよい。なお、図２４の例においては、仮想ルータ『ＶＲＦ３』の経路はＶＰＮ接続によって形成されているが、例えば、仮想ルータ『ＶＲＦ１』、『ＶＲＦ２』、及び『ＶＲＦ３』が同一事業者によって提供され、例えば地理的な条件が異なるだけの場合には、『ＶＲＦ３』向けの経路は公衆網を通過するわけではないので、ＶＰＮ接続を用いる必要はない。
【０１５０】
さて、図２４に例示するように、統合ＡＡＡ装置は、リソース不足状態が生じたか否かを判定するための情報を、例えば、アプリケーションサーバやそれを監視するオペレーションシステムなどから取得し、取得した情報が予め定められた閾値を超過することによりリソース不足状態が生じたか否かを判定する。なお、統合ＡＡＡ装置は、アプリケーションサーバやオペレーションシステムなどと、図示しない監視用のネットワークで接続されているものとする。
【０１５１】
また、統合ＡＡＡ装置は、リソース不足状態が生じたと判定した場合に、リソース不足状態が生じたアプリケーションサーバ、例えば『ＡＰＳ２』を代替するアプリケーションサーバを探索し、リソース不足状態が生じた『ＡＰＳ２』用の経路（仮想ルータ『ＶＲＦ２』の経路）上のトラヒックを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、例えばトラヒック分離統合装置及びアドレス変換装置に対して送信する。
【０１５２】
ここで、統合ＡＡＡ装置は、上述したように、物理的な筐体としてのアプリケーションサーバ毎に、リソース使用量を示す情報を取得する。このため、統合ＡＡＡ装置は、例えば『東京ＡＰＳ』についてリソース使用量を示す情報を取得し、『東京ＡＰＳ』においてリソース不足状態が生じたと判定することになるが、『東京ＡＰＳ』上では『ＡＰＳ１』及び『ＡＰＳ２』の双方が動作しているので、そのいずれのアプリケーションを代替の経路に割り当てるべきか、別途判断することになる。この点、実施例４において、統合ＡＡＡ装置は、「遅延に強い」アプリケーションを選択し、例えば遅延に強い『ＡＰＳ２』のパケットのみを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、トラヒック分離統合装置及びアドレス変換装置に対して送信する。このように、物理的には同一の筐体で動作する２つのアプリケーションのうち、一部のアプリケーションのみを選択して他の経路に割り当てることができるのは、トラヒック分離統合装置が、ポリシーベースのルーティングを行っているからでもある。
【０１５３】
すると、図２５に例示するように、仮想ルータ『ＶＲＦ２』の経路上のトラヒック（リソース不足状態が生じた『ＡＰＳ２』用の経路上のトラヒック）は、仮想ルータ『ＶＲＦ３』の経路に割り当てられる。
【０１５４】
図２６は、実施例４に係る統合ＡＡＡ装置１００の構成を示すブロック図である。図２６に例示するように、実施例４に係る統合ＡＡＡ装置１００は、記憶部１２０に、ＡＰＳ情報記憶部１２５を有する点が、実施例１に係る統合ＡＡＡ装置１００と異なる。
【０１５５】
実施例４に係る条件記憶部１２１は、リソース不足状態が生じたか否かを判定するための条件を記憶する。例えば、条件記憶部１２１は、リソース不足状態が生じたか否かを判定するための条件として、『ＣＰＵ使用率７０％』という閾値を記憶する。
【０１５６】
実施例４に係る制御情報記憶部１２２は、実施例１と同様、統合ＡＡＡ装置１００による制御に用いられる各種情報を記憶する。図２７は、制御情報を説明するための図である。例えば、制御情報記憶部１２２は、図２７の（Ａ）に例示するように、情報取得の契機、判定条件、条件該当時の制御、条件非該当時の制御などを記憶する。また、制御情報記憶部１２２は、図２７の（Ｂ）に例示するように、各アプリケーションサーバ、オペレーションシステム（特定のネットワーク装置やサーバを監視し、ＣＰＵ使用率やディスク空き容量、メモリ使用率などのリソース使用量を収集しているネットワークマネジメントシステム（ＮＭＳ））、及びトラヒック分離統合装置について、識別情報及びアドレスを記憶する。
【０１５７】
なお、これらの制御情報は一例に過ぎない。例えば、情報取得の契機や判定条件、条件該当時の制御、条件非該当時の制御などは、監視対象となる装置に応じて異なってもよく、また、同種の装置（例えば集合仮想ルータ間など）では、同じになってもよい。
【０１５８】
例えば、図２７の例で説明すると、統合ＡＡＡ装置１００は、『オペレーションシステム』（図２４において図示を省略）を監視対象とし、このオペレーションシステムとの間で通信を行う場合には、『ＩＰアドレスＯ−１』を用いる。また、制御情報記憶部１２２は、情報取得の契機、すなわち監視のタイミングとして、例えば『１分間隔』を記憶する。また、制御情報記憶部１２２は、判定条件として、『条件記憶部１２１に記憶された条件』を記憶する。すなわち、上述したように、『ＣＰＵ使用率７０％』という閾値が判定条件であることを示す。
【０１５９】
また、制御情報記憶部１２２は、条件に該当した時の制御内容として、「条件に該当したアプリケーションサーバを代替するアプリケーションサーバを探索し、探索したアプリケーションサーバ用の経路にトラヒックを割り当てるように指示する指示情報をトラヒック分離統合装置に送信すること」を記憶する。なお、実施例４においては条件に該当しなくなった場合の制御を行わないが、例えば後述するように、監視を継続している中で代替するアプリケーションサーバ用の経路に割り当てたトラヒックを元の経路に戻しても閾値を超えなくなったと判定する場合もある。このような場合には、制御情報記憶部１２２は、例えば図２７に例示するように、「経路の割り当てを元に戻すように指示する指示情報をトラヒック分離統合装置に対して送信すること」を記憶してもよい。
【０１６０】
なお、経路割り当てを元に戻すタイミングは、例えば、トラヒック監視部１３１が、『オペレーションシステム』から、割り当て先のアプリケーションサーバに関するＣＰＵ使用率を取得するとする。この場合に、トラヒック制御部１３２が、取得されたＣＰＵ使用率に基づいて「割り当て先のアプリケーションサーバが使用されていない」と判定したタイミングで、経路割り当てを元に戻してもよい。あるいは、例えば、トラヒック監視部１３１が、『オペレーションシステム』から、リソース不足状態に陥ったアプリケーションサーバに関するＣＰＵ使用率を継続して取得するとする。この場合に、トラヒック制御部１３２が、取得されたＣＰＵ使用率に基づいて「リソース不足状態に陥ったアプリケーションサーバが、現時点においてはリソース不足状態ではない」と判定したタイミングで、経路割り当てを元に戻してもよい。例えば、上記例では、経路の割り当てを変更するか否かを判定するために、『ＣＰＵ使用率７０％』という閾値を超過するか否かを判定していたが、例えば、集合仮想ルータは、『ＣＰＵ使用率７０％』とは別に『ＣＰＵ使用率５０％』という第二の閾値を記憶し、元の経路に戻してもよいか否かを判定するために、この第二の閾値『ＣＰＵ使用率５０％』を下回るか否かを判定してもよい。もっとも、経路の割り当てを変更したトラヒックを元の経路に戻さずそのまま運用してもよい。すなわち、例えば、一旦経路の割り当てを変更すると、トラヒック制御部１３２は、割り当て後の状態を初期状態として監視を開始し、割り当て後の経路で例えば『ＣＰＵ使用率７０％』という閾値を超過した場合に、再び、経路の割り当てを変更する、といった制御でもよい。
【０１６１】
ＡＰＳ情報記憶部１２５は、アプリケーション毎に、該アプリケーションをサービスとして提供するアプリケーションサーバの一覧を記憶する。なお、実施例４において、この一覧には、アプリケーションサーバが設置された地理的な位置情報を含む。ＡＰＳ情報記憶部１２５は、例えばＶＰＮ間接続サービスの運用者などによって入力されることでアプリケーションサーバの一覧を予め記憶する。また、ＡＰＳ情報記憶部１２５が記憶するアプリケーションサーバの一覧は、後述するトラヒック制御部１３２による処理に用いられる。
【０１６２】
図２８は、アプリケーションサーバの一覧を説明するための図である。例えば、ＡＰＳ情報記憶部１２５は、図２８に例示するように、アプリケーション毎に、アプリケーションサーバの名称（地理的な位置情報を含む）と、このアプリケーションサーバが接続する経路のトラヒック分離統合装置のＩ／Ｆ情報とを対応付けて記憶する。例えば、図２８に例示するように、『東京ＡＰＳ１』と『東京ＡＰＳ２』とはそれぞれ異なるアプリケーションであるので、ＡＰＳ識別情報は異なる。もっとも、物理的な筐体『東京ＡＰＳ』は１つであるので、いずれも、接続Ｉ／Ｆは『ＩＦ１−３』で同一である（もっとも、物理的な接続Ｉ／Ｆのサブインタフェース（論理的な接続Ｉ／Ｆ）が異なる場合はある）。なお、実施例４においては、『ＡＰ１』よりも『ＡＰ２』の方が遅延に強いアプリケーションという想定である。
【０１６３】
実施例４に係るトラヒック監視部１３１は、リソース借用の要否を判定するための情報を取得し、取得した情報が予め定められた閾値を超過することによりリソース不足状態が生じたか否かを判定する。そして、トラヒック監視部１３１は、リソース不足状態が生じたと判定した場合には、その旨をトラヒック制御部１３２に通知する。
【０１６４】
実施例４に係るトラヒック制御部１３２は、トラヒック監視部１３１によってリソース不足状態が生じたと判定された場合に、リソース不足状態が生じたアプリケーションサーバを代替するアプリケーションサーバを探索し、リソース不足状態が生じたアプリケーションサーバ用の経路上のトラヒックを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【０１６５】
例えば、トラヒック制御部１３２は、『東京ＡＰＳ』においてリソース不足状態が生じたと判定した旨の通知をトラヒック監視部１３１から受け付けると、制御情報記憶部１２２を参照し、条件該当時の制御内容として記憶された情報を取得する。そして、トラヒック制御部１３２は、ＡＰＳ情報記憶部１２５を参照し、『東京ＡＰＳ』上で『東京ＡＰＳ１』及び『東京ＡＰＳ２』が動作していることを判定する。また、トラヒック制御部１３２は、２つ以上のアプリケーションが動作している場合には、遅延に強い方のアプリケーション（例えば、統合ＡＡＡ装置１００は、『ＡＰ２』が遅延に強いアプリケーションであることを別途情報として記憶している）を選択し、選択したアプリケーションのみを、代替のアプリケーションサーバ用の経路に割り当てる。
【０１６６】
すなわち、トラヒック制御部１３２は、『ＡＰ２』に対応付けて記憶されているアプリケーションサーバの一覧を取得する。そして、トラヒック制御部１３２は、例えば地理的な位置情報から、代替のアプリケーションサーバを探索する。例えば、トラヒック制御部１３２は、『東京ＡＰＳ２』に地理的に近接する『名古屋ＡＰＳ２』もしくは『東北ＡＰＳ２』を、代替のアプリケーションサーバの候補として探索する。そして、例えば、トラヒック制御部１３２は、『名古屋ＡＰＳ２』及び『東北ＡＰＳ２』それぞれのリソース使用量を示す情報を取得して比較し、よりリソースに余裕がある方のアプリケーションサーバを、代替のアプリケーションサーバとして選択する。
【０１６７】
そして、トラヒック制御部１３２は、再びＡＰＳ情報記憶部１２５を参照し、代替のアプリケーションサーバ（例えば『東北ＡＰＳ２』）用の経路、及び、リソース不足状態が生じたアプリケーションサーバ（例えば『東京ＡＰＳ２』）用の経路について、トラヒック分離統合装置のＩ／Ｆ情報を取得する。例えば、トラヒック制御部１３２は、『東北ＡＰＳ２』の経路は、Ｉ／Ｆ情報『Ｉ／Ｆ１−２』、すなわち『トラヒック分離統合装置１』の『第２Ｉ／Ｆ』に接続されていることを示す情報を取得する。また、例えば、トラヒック制御部１３２は、『東京ＡＰＳ２』の経路は、Ｉ／Ｆ情報『Ｉ／Ｆ１−３』、すなわち『トラヒック分離統合装置１』の『第３Ｉ／Ｆ』に接続されていることを示す情報を取得する。そして、トラヒック制御部１３２は、リソース不足状態が生じた『ＡＰＳ２』用の経路（仮想ルータ『ＶＲＦ２』の経路）上のトラヒックを、代替のアプリケーションサーバ（例えば『東北ＡＰＳ２』）用の経路に割り当てるように指示する指示情報を、例えば『トラヒック分離統合装置１』に対して送信する。『トラヒック分離統合装置１』では、『第３Ｉ／Ｆ』にポリシールーティングしていたトラヒックを、以後、『第２Ｉ／Ｆ』にポリシールーティングする。
【０１６８】
なお、『東北ＡＰＳ２』用の経路が既に構築されている場合には、トラヒック制御部１３２は、既に構築されている『東北ＡＰＳ２』用の経路にトラヒックを割り当てるように指示すればよいが、『東北ＡＰＳ２』用の経路が構築されていない場合には、トラヒック制御部１３２は、さらに、『東北ＡＰＳ２』用の経路を構築するように、例えば、ＶＰＮ間接続管理システムに対して指示情報（依頼情報）を送信する必要がある。また、『東北ＡＰＳ２』用の経路として、一般的なＶＰＮを構築してもよい。
【０１６９】
なお、実施例４においては、地理的に近接するアプリケーションサーバを探索する例を説明したが、開示の技術はこれに限られるものではない。例えば、リソース不足状態に陥ったアプリケーションが、遅延に強いアプリケーションであると判定した場合には（遅延に強いアプリケーションであるか否かの情報を予め記憶している）、トラヒック制御部１３２は、地理的な位置情報から代替のアプリケーションサーバを探索するのではなく、例えば、アプリケーションサーバの性能や、集合仮想ルータの性能（信頼性の高低、帯域制御の可否など）などを優先して探索してもよい。あるいは、代替のアプリケーションサーバは、予め決定されていてもよい。この場合には、トラヒック制御部１３２は、予め決定されている代替のアプリケーションサーバを示す情報を記憶部から探索すればよい。
【０１７０】
また、実施例４においては、リソース不足状態が生じたか否かを判定するための条件として、『ＣＰＵ使用率７０％』という閾値を記憶する例を説明したが、開示の技術はこれに限られるものではない。例えば、統合ＡＡＡ装置１００は、リソース借用の要否を判定するための情報として、『アプリケーションサーバ毎のディスク空き容量』、『アプリケーションサーバ毎のメモリ使用率』などが用いられることもある。例えば、統合ＡＡＡ装置１００は、『アプリケーションサーバ毎のディスク空き容量』が所定の閾値よりも小さければ、リソース不足状態が生じたと判定する。また、例えば、統合ＡＡＡ装置１００は、『アプリケーションサーバ毎のメモリ使用率』が所定の閾値よりも大きければ、リソース不足状態が生じたと判定する。なお、上記したこれらの手法を用いる場合には、統合ＡＡＡ装置１００は、各手法に対応する閾値を条件記憶部１２１に予め記憶する。
【０１７１】
また、例えば、統合ＡＡＡ装置１００は、測定用のパケットを経路上に流したり、経路上に流れるユーザパケットを用いて、例えばアプリケーションのレスポンスタイムを測定することにより、その測定値をリソース借用の要否を判定するための情報として取得し、測定値が所定の閾値よりも大きければ、リソース不足状態が生じたと判定してもよい。アプリケーションのレスポンスタイムは、例えば図２５のアドレス変換装置に備えられたファイアウォール機能や、ネットワーク遅延の影響が少ない場所に設定されたプローブなどによって測定することが可能である。例えば、ファイアウォール機能は、パケットを解析することができるので、特定のアプリケーションにおいて送受信される要求パケットと応答パケットとの間のレスポンスタイムを測定することができる。なお、この場合には、統合ＡＡＡ装置１００は、レスポンスタイムに対応する閾値を条件記憶部１２１に予め記憶する。
【０１７２】
また、実施例４においては、統合ＡＡＡ装置１００が自発的にアプリケーションサーバやオペレーションシステムから情報を取得する、いわゆるプル型の監視を想定したが、開示の技術はこれに限られるものではなく、例えば、アプリケーションサーバやオペレーションシステムにて『ＣＰＵ使用率７０％』という閾値を記憶し、アプリケーションサーバやオペレーションシステムが、『ＣＰＵ使用率７０％』という閾値を超過するか否かを例えば１分間隔に判定し、超過したと判定した場合に、アプリケーションサーバやオペレーションシステムが統合ＡＡＡ装置１００に対して通知する、いわゆるプッシュ型の監視でもよい。
【０１７３】
また、実施例４においては、リソース不足状態が生じたアプリケーションサーバ用の経路上のトラヒック全てを、代替のアプリケーションサーバ用の経路に割り当てる例を説明したが、開示の技術はこれに限られるものではない。例えば、代替のアプリケーションサーバが、他の事業者のものであったり、距離的に遠くにあるなど、元のアプリケーションサーバを利用した場合よりもサービス品質が劣化する場合も考えられる。この場合には、『Best Effort Class』のトラヒックから優先的に代替のアプリケーションサーバに誘導する手法や、遅延時間に感受性の低いアプリケーションから優先的に距離的に遠くのアプリケーションサーバに誘導することも考えられる。
【０１７４】
また、実施例４においては、リソース不足状態が生じたアプリケーションサーバ用の経路上のトラヒック全てを、『１つの』代替のアプリケーションサーバ用の経路に割り当てる例を説明したが、開示の技術はこれに限られるものではない。例えば、統合ＡＡＡ装置は、リソース不足状態が生じたアプリケーションサーバを代替するアプリケーションサーバを『複数』探索し、探索した『複数の』代替のアプリケーションサーバ用の経路にトラヒックを割り当てるように指示する指示情報を、経路を形成する装置に対して送信してもよい。例えば、統合ＡＡＡ装置は、トラヒック分離統合装置に対して、「パケットの送信元ＩＰアドレスの末尾８ビットが『１』〜『１２８』を示す場合には、仮想ルータ『ＶＲＦ３』の経路にルーティングし、『１２９』〜『２５５』を示す場合には、仮想ルータ『ＶＲＦ４』の経路にルーティングする」といったポリシールーティングを行うように指示する指示情報を送信すればよい。
【０１７５】
また、実施例４においては、リソース不足状態を判定する手法を説明したが、開示の技術はこれに限られるものではない。例えば、統合ＡＡＡ装置は、アプリケーションサーバ毎のリソース使用量を示す情報を取得し、取得した情報が予め定められた条件（例えば、ＣＰＵ使用率が『０』になったという条件）に該当することによりサーバ停止状態が生じたか否かを判定する。また、統合ＡＡＡ装置は、サーバ停止状態が生じたと判定した場合に、サーバ停止状態が生じたアプリケーションサーバを代替するアプリケーションサーバを探索し、サーバ停止状態が生じたアプリケーションサーバ用の経路上のトラヒックを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、経路を形成する装置に対して送信する。
【０１７６】
［実施例４に係るトラヒック制御処理手順］
図２９は、実施例４に係るトラヒック制御処理手順を示すフローチャートである。図２９に例示するように、統合ＡＡＡ装置１００において、トラヒック監視部１３１が、各アプリケーションサーバやオペレーションシステムとの間で定期的に（または適当なタイミングに）通信を行い、アプリケーションサーバ毎のリソース使用量を示す情報を各アプリケーションサーバやオペレーションシステムから受信することで、トラヒックを監視する（ステップＳ４０１）。
【０１７７】
そして、トラヒック監視部１３１は、各アプリケーションサーバやオペレーションシステムからアプリケーションサーバ毎のリソース使用量を示す情報を受信すると、条件記憶部１２１を参照し、受信したリソース使用量を示す情報が、『ＣＰＵ使用率７０％』という閾値を超過するか否かを判定することで、リソース不足状態を判定する（ステップＳ４０２）。
【０１７８】
閾値を超過しないと判定した場合には（ステップＳ４０３否定）、トラヒック監視部１３１は、ステップＳ４０１の処理に戻る。一方、閾値を超過すると判定した場合には（ステップＳ４０３肯定）、統合ＡＡＡ装置１００において、トラヒック制御部１３２が、例えば『ＡＰＳ２』を代替するアプリケーションサーバを探索し、リソース不足状態が生じた『ＡＰＳ２』用の経路（仮想ルータ『ＶＲＦ２』の経路）上のトラヒックを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、例えばトラヒック分離統合装置に対して送信する（ステップＳ４０４）。
【０１７９】
［実施例４の効果］
上述したように、実施例４において、集合仮想ルータには、ＶＰＮ間接続に属する各ＶＰＮの端末に対してトラヒック種別毎にサービスを提供するアプリケーションサーバが接続され、該端末は、集合仮想ルータによってパケット転送を制御されることでトラヒック種別毎の経路を用いて該アプリケーションサーバにアクセスする。トラヒック監視部１３１は、アプリケーションサーバ又はオペレーションシステムを監視することにより、アプリケーションサーバ又はオペレーションシステムからアプリケーションサーバ毎のリソース使用量を示す情報を取得し、取得した情報が予め定められた条件に該当することによりアプリケーションサーバにおいて予め定められたリソース不足の状態が生じたか否かを判定する。トラヒック制御部１３２は、予め定められたリソース不足の状態が生じたと判定された場合に、リソース不足の状態が生じたアプリケーションサーバを代替するアプリケーションサーバを探索し、リソース不足の状態が生じたアプリケーションサーバ用の経路上のトラヒックを、代替のアプリケーションサーバ用の経路に割り当てるように指示する指示情報を、少なくともトラヒック分離統合装置に対して送信する。
【０１８０】
このようなことから、実施例４によれば、リソース不足状態に対応して他のリソースを貸借することが可能になり、トラヒック制御を適切に行うことができる。例えば、インタークラウド環境においてリソースが不足した場合に、他所のリソースを借りることができる。また、予め、地理的な位置情報（距離）や品質などにおいて借用する仮想ルータを決定しておけば、トラヒックの遅延への耐性や優先度などに応じてトラヒックの制御を行うことができ、適切なサービスレベルを維持することができる。
【実施例５】
【０１８１】
さて、これまで実施例１〜４を説明したが、開示の技術は、上記実施例以外にも種々の異なる形態にて実施されてよいものである。
【０１８２】
［ＶＰＮ間接続管理システムと統合ＡＡＡ装置との関係］
上記実施例においては、ＶＰＮ間接続を構築する「ＶＰＮ間接続管理システム」と「統合ＡＡＡ装置」とが、異なる筐体の装置であり、また、それぞれが独立の機能を有する装置として実現される例を説明したが、開示の技術はこれに限られるものではない。すなわち、ＶＰＮ間接続管理システムと統合ＡＡＡ装置とは、同じ筐体の装置として、また、一体化した機能を有する装置として、実現されてもよい。例えば、統合ＡＡＡ装置は、ＶＰＮ間接続管理システムの一部として動作してもよい。なお、上記実施例においては、１台の筐体の統合ＡＡＡ装置が設置される構成を例示したが、開示の技術はこれに限られるものではない。例えば、複数台の筐体の統合ＡＡＡ装置が設置される構成や、例えば、記憶部など統合ＡＡＡ装置の一部が別の筐体で設置される構成などにも、開示の技術を同様に適用することができる。
【０１８３】
［冗長化構成］
上記実施例におけるＶＰＮ間接続は、経路自体を冗長化するものではなかったが、開示の技術において、ＶＰＮ間接続は、経路自体を冗長化することもできる。図３０は、冗長化された経路を説明するための図である。例えば、ＶＰＮ間接続の経路は、図３０に例示するように冗長化してもよい。具体的には、図３０に例示するＶＰＮ間接続では、現用の集合仮想ルータ（Master（ACT））と予備用の集合仮想ルータ（Backup（SBY））とが設置され、例えば、ＶＲＲＰ（Virtual Router Redundancy Protocol）やＨＳＲＰ（Hot Standby Routing Protocol）などの冗長化プロトコルによって両集合仮想ルータが冗長化されることで、仮想ルータ『ＶＲＦ１』の経路が冗長化される。一方、図３０に例示するように、仮想ルータ『ＶＲＦ２』の経路は、冗長化されていない。なお、冗長化された経路上に存在するアドレス変換装置やトラヒック分離統合装置についても、ＶＲＲＰやＨＳＲＰによって冗長化し、現用の経路から予備用の経路への切り替えに対応するように設定する。
【０１８４】
このような構成の場合、仮想ルータ『ＶＲＦ１』の経路は、信頼性が高い経路であり、一方、仮想ルータ『ＶＲＦ２』の経路は、通常の信頼性の経路である。そこで、例えば、高い信頼性が要求されるトラヒック（例えば基幹系のアプリケーションなど）を仮想ルータ『ＶＲＦ１』の経路に割り当て、通常の信頼性であればよいとされるトラヒックを仮想ルータ『ＶＲＦ2』の経路に割り当てることで、トラヒックの信頼性に応じた複数の経路を形成することができる。言い換えると、冗長化の度合いによって仮想ルータを分類し、要求される信頼性の度合いで分離したトラヒックを、必要な冗長化の度合いによって対応する適切な仮想ルータに収容することにより、トラヒック毎に信頼性のレベルを変えることができる。
【０１８５】
なお、高い信頼性が要求されるトラヒックであるか否かが、例えば、ユーザ（契約におけるＳＬＡなどで定義）、アプリケーションの種別、ＩＰアドレス、ポート番号などによって区別することができる場合には、統合ＡＡＡ装置は、予め、ユーザ、アプリケーションの種別、ＩＰアドレス、ポート番号などに応じて経路を割り当て、その割り当て情報を、トラヒック分離統合装置に対して送信すればよい。
【０１８６】
また、実施例１〜４の各実施例で説明した手法は、組み合わせることが可能である。例えば、アプリケーションサーバにおいてリソース不足状態が生じるよりも先に、集合仮想ルータにおける高負荷状態が生じたり、経路上の故障状態が生じることもある。このような場合には、例えば、実施例４で説明した経路の切り替えよりも前に、実施例２や実施例３で説明した経路の切り替えが行われることになる。
【０１８７】
［拠点の態様］
また、上記実施例では、拠点が、電気通信事業者などによって提供されたＶＰＮサービスに接続するローカルエリアネットワークである場合を想定したが、開示の技術はこれに限られるものではない。拠点は、いわゆるネットワークではなく一端末であってもよい。例えば、拠点に設置されるルータが、物理的なルータではなく端末内のソフトウェアで実現される場合などである。また、拠点は、電気通信事業者などによって提供されたＶＰＮサービスによって接続された複数のローカルエリアネットワーク群による社内網のようなものであってもよい。
【０１８８】
図３１〜３３は、ＶＰＮサービスによって接続された複数のローカルエリアネットワーク群としての拠点を説明するための図である。なお、図３１〜３３においては、２種類の点線を用いて示す。一方は、通常の点線であり、他方は、破線（短い線と長い線との組合せ）である。破線は、同じＶＰＮサービスに属する複数の拠点であって、かつ、例えば同じ社内（例えばＣ社内）の拠点間でＶＰＮを形成していることを示す。一方、点線は、ＶＰＮ間を接続することを示す。例えば、異なるＶＰＮサービスに属する複数の拠点間を接続することや、同じＶＰＮサービスに属する複数の拠点間であっても、異なる会社のＶＰＮ間を接続することを示す。
【０１８９】
図３１に例示するように、例えば、Ｃ社は、ＶＰＮサービス１に属する拠点群を有し、また、ＶＰＮサービス３に属する拠点を有する。一方、Ｄ社は、ＶＰＮサービス２に属する拠点を有し、また、ＶＰＮサービス４に属する拠点を有する。統合ＡＡＡ装置は、このような、異なるＶＰＮサービスに属するＣ社の拠点群とＤ社の拠点群との拠点間接続について、トラヒックを適切に制御することができる。
【０１９０】
また、図３２に例示するように、例えば、Ｃ社は、ＶＰＮサービス３でグループ化された拠点群を有する。一方、Ｄ社は、ＶＰＮサービス４でグループ化された拠点群を有する。統合ＡＡＡ装置は、このような、異なるＶＰＮサービスに属するＣ社の拠点群とＤ社の拠点群との拠点間接続についても、トラヒックを適切に制御することができる。
【０１９１】
また、図３３に例示するように、例えば、Ｃ社及びＤ社は、いずれも、ＶＰＮサービス２でグループ化された拠点群を有する。統合ＡＡＡ装置は、このような、同じＶＰＮサービスに属するＣ社の拠点群とＤ社の拠点群との拠点間接続、言い換えると、同じＶＰＮ終端装置に属する複数の拠点群間の拠点間接続についても、トラヒックを適切に制御することができる。
【０１９２】
［ＶＰＮ間接続管理システムの構成］
以下、上記各実施例にてＶＰＮ間接続を管理するＶＰＮ間接続管理システムを説明する。もっとも、以下に説明するＶＰＮ間接続管理システムは一例にすぎず、上記各実施例において構築されたＶＰＮ間接続は、他のシステムによって構築されたものであってもよい。図３４は、ＶＰＮ間接続管理システム２００の構成を示すブロック図である。図３４に例示するように、ＶＰＮ間接続管理システム２００は、通信部２１０と、入力部２１１と、出力部２１２と、入出力制御Ｉ／Ｆ部２１３と、記憶部２２０と、制御部２３０とを備える。
【０１９３】
通信部２１０は、例えばＩＰ通信用の一般的なインタフェースなどであり、アドレス変換情報やルーティング情報の設定対象となるＶＰＮ終端装置、アドレス変換装置及び集合仮想ルータとの間で通信を行う。なお、ＶＰＮ間接続管理システム２００は、通信部２１０を介して他の管理端末やユーザ用のＷｅｂサーバなどとの間で通信を行うこともでき、他の管理端末やユーザ用のＷｅｂサーバなどからＶＰＮ間接続要求を受信することもできる。
【０１９４】
入力部２１１は、例えばキーボードやマウスなどであり、各種操作の入力などを受け付ける。入力部２１１は、例えば、ＶＰＮ間接続要求の入力をキーボードやマウスによって受け付ける。出力部２１２は、例えばディスプレイなどであり、各種操作のための情報などを出力する。出力部２１２は、例えば、ＶＰＮ間接続要求の入力画面を出力する。入出力制御Ｉ／Ｆ（Interface）部２１３は、入力部２１１と、出力部２１２と、記憶部２２０と、制御部２３０との間における入出力を制御する。なお、ＶＰＮ間接続管理システム２００は、必ずしも入力部２１１や出力部２１２を備える必要はなく、例えば、通信部２１０を介して他の管理端末やユーザ用のＷｅｂサーバと通信を行い、入出力に係る情報を送受信してもよい。
【０１９５】
記憶部２２０は、例えばＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどであり、各種情報を記憶する。具体的には、記憶部２２０は、図３４に例示するように、ＶＰＮ間接続情報記憶部２２１と、設定パターン記憶部２２２と、ＶＰＮ間接続要求記憶部２２３と、アドレス変換情報記憶部２２４と、ルーティング情報記憶部２２５と、アタッチメント記憶部２２６と、装置情報記憶部２２７とを有する。
【０１９６】
ＶＰＮ間接続情報記憶部２２１は、ＶＰＮ間接続情報を記憶する。ここで、ＶＰＮ間接続情報には、拠点を識別する情報や、拠点を収容するＶＰＮ終端装置、アドレス変換装置及び集合仮想ルータを識別する情報が含まれる。また、ＶＰＮ間接続情報には、アドレス変換情報やルーティング情報の作成に必要なその他の情報も含まれる。ＶＰＮ間接続情報記憶部２２１は、例えばＶＰＮ間接続管理システム２００の利用者に入力されることで、ＶＰＮ間接続情報を事前に記憶する。また、ＶＰＮ間接続情報記憶部２２１が記憶するＶＰＮ間接続情報は、後述する仮想ルータ構築部２３２、変換用アドレス決定部２３３、ルーティング情報生成部２３５による処理などに利用される。なお、ＶＰＮ間接続管理システム２００の「利用者」には、電気通信事業者などの運用者と、企業内の情報システム部などの管理者とが含まれる。すなわち、以下では、「運用者」は、ＶＰＮ間接続サービスの運用担当者を意味し、「管理者」は、例えば企業側で拠点の社内網を管理しているネットワーク管理者などを意味する用語として用いる。
【０１９７】
図３５は、ＶＰＮ間接続情報記憶部２２１を説明するための図である。図３５に例示するように、例えば、ＶＰＮ間接続情報記憶部２２１は、ＶＰＮ間接続情報として、集合仮想ルータの識別情報と、集合仮想ルータの設定パターンの識別情報とを対応付けて記憶する。例えば、集合仮想ルータの識別情報『集合仮想ルータ１』と、集合仮想ルータの設定パターンの識別情報『ＶＲ−Ｐ１』とを対応付けて記憶する。『集合仮想ルータ１』によって識別される集合仮想ルータの設定パターンは、『ＶＲ−Ｐ１』によって識別される設定パターンであることを示す。
【０１９８】
また、ＶＰＮ終端装置と集合仮想ルータとは予め対応付けられ、ＶＰＮ終端装置が一意に特定されると、集合仮想ルータも一意に特定される関係にある。すなわち、物理的に１台の集合仮想ルータと、この集合仮想ルータにおいて一つ又は複数の仮想ルータを設定されるＶＰＮ終端装置とは、予め特定される関係にある（なお、開示の技術はこれに限られるものではなく、例えば、あるＶＰＮ終端装置が、複数台の集合仮想ルータそれぞれにおいて仮想ルータを設定されることも可能である）。このようなことから、例えば、ＶＰＮ間接続情報記憶部２２１は、図３５に例示するように、集合仮想ルータの識別情報ごとに、拠点（又は拠点のユーザ）を識別する識別情報（接続先ＩＤ（IDentifier）及び端末名）と、拠点が用いるＶＰＮ種別と、拠点が収容されるＶＰＮ終端装置の識別情報と、ＶＰＮ終端装置の設定パターンの識別情報と、アドレス変換装置の識別情報と、拠点にて用いられている拠点内アドレスとの対応付けのリストを記憶する。
【０１９９】
『接続先ＩＤ』は、例えばＶＰＮ間接続サービスの契約時などにＶＰＮ間接続管理システム２００の運用者によって払い出され、ＶＰＮ間接続情報記憶部２２１に格納される。また、『端末名』は、例えばＶＰＮ間接続サービスの契約時などにユーザからヒアリングされ、ＶＰＮ間接続情報記憶部２２１に格納される。
【０２００】
『ＶＰＮ種別』は、例えばＶＰＮ間接続サービスの契約時などにユーザからヒアリングされ、ＶＰＮ間接続情報記憶部２２１に格納される。『ＶＰＮ終端装置』は、例えばＶＰＮ間接続サービスの契約時などにＶＰＮ間接続管理システム２００の運用者によって決定され、ＶＰＮ間接続情報記憶部２２１に格納される。また、『ＶＰＮ終端装置の設定パターン』は、例えばＶＰＮ間接続サービスの契約時などにＶＰＮ間接続管理システム２００の運用者によって決定され、ＶＰＮ間接続情報記憶部２２１に格納される。『アドレス変換装置』は、例えばＶＰＮ間接続サービスの契約時などにＶＰＮ間接続管理システム２００の運用者によって決定され、ＶＰＮ間接続情報記憶部２２１に格納される。『拠点内アドレス』は、例えばＶＰＮ間接続サービスの契約時などにユーザからヒアリングされ、ＶＰＮ間接続情報記憶部２２１に格納される。
【０２０１】
例えば、接続先ＩＤ『ＵｓｅｒＡ−Ｏｆｆｉｃｅ』、端末名『α１＠ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』、ＶＰＮ種別『ＯｐｅｎＶＰＮ』、ＶＰＮ終端装置『ＶＰＮ終端装置１』、ＶＰＮ終端装置の設定パターン『ＶＰＮ−Ｐ１』、アドレス変換装置『アドレス変換装置１』、拠点内アドレス『１９２．１６８．１．１０／２４』の行について説明する。まず、『ＵｓｅｒＡ−Ｏｆｆｉｃｅ』によって識別される拠点（ＶＰＮ間接続に用いられる端末の端末名は『α１＠ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』）では、『ＯｐｅｎＶＰＮ』が用いられていることを示す。また、『ＵｓｅｒＡ−Ｏｆｆｉｃｅ』によって識別される拠点は『ＶＰＮ終端装置１』に収容されること、また、ＶＰＮ終端装置の設定パターンには『ＶＰＮ−Ｐ１』が用いられることを示す。
【０２０２】
また、『ＵｓｅｒＡ−Ｏｆｆｉｃｅ』によって識別される拠点は『アドレス変換装置１』に収容されること、また、『１９２．１６８．１．１０／２４』の拠点内アドレスが用いられていることを示す。なお、各拠点において用いられている拠点内アドレス（プライベートアドレス）が相互に重複する状況を想定する。
【０２０３】
図３４に戻り、設定パターン記憶部２２２は、ＶＰＮ終端装置、アドレス変換装置、及び転送制御装置の設定パターンを記憶する。具体的には、設定パターン記憶部２２２は、ＶＰＮ終端装置に設定すべき設定情報がＶＰＮ間接続の種別に応じて定型化されたＶＰＮ終端装置の設定パターンを記憶する。また、設定パターン記憶部２２２は、集合仮想ルータに設定すべき設定情報がＶＰＮ間接続の種別に応じて定型化された集合仮想ルータの設定パターンを記憶する。また、設定パターン記憶部２２２は、アドレス変換装置の設定パターンを記憶する。
【０２０４】
設定パターン記憶部２２２は、例えばＶＰＮ間接続管理システム２００の運用者に入力されることで、設定パターンを事前に記憶する。また、設定パターン記憶部２２２が記憶する設定パターンは、後述する変換用アドレス決定部２３３やルーティング情報生成部２３５による処理などに利用される。
【０２０５】
図３６は、集合仮想ルータの設定パターンの一例である。図３６に例示するように、例えば、設定パターン記憶部２２２は、集合仮想ルータの設定パターンとして、設定パターンの各項目を管理するための項番と、設定情報を設定内容に応じて区分けする区分と、設定内容と、設定情報の登録タイミングと、削除タイミングと、設定内容の仕様とを対応付けて記憶する。また、図３６に例示する設定パターンの内、項番１〜項番３が、設定情報の設定パターンであり、項番４が、オプション設定情報の設定パターンである。なお、オプション要求に関する設定情報を一般的な設定情報と区別して用いる場合には、『オプション設定情報』と呼ぶ。また、図３６においては図示を省略するが、設定パターン記憶部２２２は、集合仮想ルータの設定パターンとして、所定のコマンド文をも記憶する。なお、設定パターンは、設定パターンの識別情報によって識別される。
【０２０６】
例えば、項番１の行を説明する。区分『仮想ルータ定義』の設定パターンは、ＶＰＮ間接続要求に基づいて仮想的に構築される伝送路（ＶＰＮ）においてパケット転送を制御する「仮想ルータ」を定義するための設定パターンである。設定内容『仮想ルータ名』は、設定される「仮想ルータ」の名称であり、『半角英数字』で設定すべきことが、仕様として規定されている。また、設定内容『仮想ルータＩＤ』は、設定される「仮想ルータ」のＩＤであり、『１６ビット数値』と『３２ビット数値』とを『：（コロン）』で接続した形式で設定すべきことが、仕様として規定されている。なお、仕様は、例えば、該当する機器の製造業者などによって規定され、機器の利用者に提供されるもので、上記は一例であり、これに限定されない。また、登録タイミング『サービス開始直前』は、項番１の情報は、サービス開始直前にＶＰＮ終端装置に反映されるべきことを示す。また、削除タイミング『サービス終了直後』は、項番１の情報は、サービス終了直後にＶＰＮ終端装置から削除されるべきことを示す。
【０２０７】
また、例えば、項番２の行を説明する。区分『Ｉ／Ｆ設定』の設定パターンは、「仮想ルータ」に設定されるインタフェースの設定パターンである。設定内容『ＩＰアドレス』は、インタフェースに設定するＩＰアドレスは『数字．数字．数字．数字』のように数字をピリオドで区切った形式で設定すべきこと、数字は『０〜２５５』の値を設定すべきことが、仕様として規定されている。また、設定内容『Ｉ／Ｆの指定』は、インタフェースの指定は『Ｉ／Ｆの種別 数字／数字／数字』の形式で設定すべきことが、仕様として規定されている。また、設定内容『所属仮想ルータ』は、インタフェースを設定する仮想ルータ名を指定すべきことが、仕様として規定されている。また、登録タイミング『サービス開始直前』は、項番２の情報は、サービス開始直前にＶＰＮ終端装置に反映されるべきことを示す。また、削除タイミング『サービス終了直後』は、項番２の情報は、サービス終了直後にＶＰＮ終端装置から削除されるべきことを示す。
【０２０８】
また、例えば、項番３の行を説明する。区分『仮想ルータ単位のルーティング設定』の設定パターンは、「仮想ルータ」に設定されるルーティング情報の設定パターンである。設定内容『ルーティング設定』は、ルーティング情報を設定する仮想ルータ名を指定すべきこと、ルーティング情報のＩＰアドレスは『数字．数字．数字．数字』のように数字をピリオドで区切った形式で設定すべきこと、数字は『０〜２５５』の値を設定すべきことが、仕様として規定されている。また、登録タイミング『サービス開始直前』は、項番３の情報は、サービス開始直前にＶＰＮ終端装置に反映されるべきことを示す。また、削除タイミング『サービス終了直後』は、項番３の情報は、サービス終了直後にＶＰＮ終端装置から削除されるべきことを示す。
【０２０９】
また、例えば、項番４の行を説明する。区分『アクセス制御』の設定パターンは、「仮想ルータ」に設定されるアクセス制御の設定パターンである。設定内容『フィルタリング（ＡＣＬ（Access Control List）など）』は、ＩＰアドレスは『数字．数字．数字．数字』のように数字をピリオドで区切った形式で設定すべきこと、数字は『０〜２５５』の値を設定すべきこと、ポート番号は、数字で設定すべきこと、数字は『１〜６５５３５』の値を設定すべきことが、仕様として規定されている。また、登録タイミング『サービス開始直前』は、項番４の情報は、サービス開始直前にＶＰＮ終端装置に反映されるべきことを示す。また、削除タイミング『サービス終了直後』は、項番４の情報は、サービス終了直後にＶＰＮ終端装置から削除されるべきことを示す。
【０２１０】
図３７は、ＶＰＮ終端装置の設定パターンの一例である。図３７に例示するように、例えば、設定パターン記憶部２２２は、ＶＰＮ終端装置の設定パターンとして、設定パターンの各項目を管理するための項番と、設定情報を区分けする区分と、設定内容と、設定情報の登録タイミングと、削除タイミングと、設定内容の仕様とを対応付けて記憶する。また、図３７に例示する設定パターンの内、項番１が、設定情報の設定パターンであり、項番２が、オプション設定情報の設定パターンである。また、図３７においては図示を省略するが、設定パターン記憶部２２２は、ＶＰＮ終端装置の設定パターンとして、所定のコマンド文をも記憶する。なお、設定パターンは、設定パターンの識別情報によって識別される。
【０２１１】
例えば、項番１の行を説明する。区分『ＶＰＮユーザ設定』の設定パターンは、ＶＰＮ間接続要求に基づいてＶＰＮ終端装置に収容する拠点のユーザに関する設定パターンである。設定内容『認証ＩＤ／パスワード』は、拠点のユーザに払い出される認証ＩＤ及びパスワードであり、認証ＩＤ及びパスワードは、『１２８文字以内』の『半角英数字』で設定すべきことが、仕様として規定されている。なお、『認証ＩＤ／パスワード』の替わりにその他の『認証情報』であってもよい。また、登録タイミング『サービス開始直前』は、項番１の情報は、サービス開始直前にＶＰＮ終端装置に反映されるべきことを示す。また、削除タイミング『サービス終了直後』は、項番１の情報は、サービス終了直後にＶＰＮ終端装置から削除されるべきことを示す。
【０２１２】
また、例えば、項番２の行を説明する。区分『アクセス制御』の設定パターンは、「ＶＰＮ終端装置」に設定されるアクセス制御の設定パターンである。設定内容『フィルタリング（ＡＣＬなど）』は、ＩＰアドレスは『数字．数字．数字．数字』のように数字をピリオドで区切った形式で設定すべきこと、数字は『０〜２５５』の値を設定すべきこと、ポート番号は、数字で設定すべきこと、数字は『１〜６５５３５』の値を設定すべきことが、仕様として規定されている。また、登録タイミング『サービス開始直前』は、項番２の情報は、サービス開始直前にＶＰＮ終端装置に反映されるべきことを示す。また、削除タイミング『サービス終了直後』は、項番２の情報は、サービス終了直後にＶＰＮ終端装置から削除されるべきことを示す。
【０２１３】
また、図示を省略したが、設定パターン記憶部２２２は、アドレス変換装置の設定パターンについても同様に記憶する。例えば、設定パターン記憶部２２２は、設定情報の登録タイミングと、削除タイミングと、設定内容の仕様とを対応付けて記憶する。例えば、ＩＰアドレスは『数字．数字．数字．数字』のように数字をピリオドで区切った形式で設定すべきこと、数字は『０〜２５５』の値を設定すべきことなどが、仕様として規定される。また、例えば、『サービス開始直前』にアドレス変換装置に反映されるべきこと、『サービス終了直後』にアドレス変換装置から削除されるべきことなどが、仕様として規定される。また、設定パターン記憶部２２２は、アドレス変換装置の設定パターンとして、所定のコマンド文をも記憶する。
【０２１４】
なお、上記設定パターンはいずれも一例に過ぎず、ＶＰＮ間接続の種別などによって、設定内容、設定情報の登録タイミング、削除タイミング、設定内容の仕様などは異なってくると考えられる。すなわち、例えば、ＶＰＮ間接続の種別が『Ｌ３ＶＰＮ』であれば、ＶＰＮ間接続先とＶＰＮ間接続元とのＩＰアドレスの組や、ＩＰｓｅｃの動作設定情報（認証方式や暗号化アルゴリズム）、事前秘密共有鍵などの項目も、設定パターンに定型化され得る。また、例えば、ＶＰＮ間接続の種別が『Ｌ２ＶＰＮ』であれば、ＶＰＮ間接続先とＶＰＮ間接続元とのＬ２などのＩＤなどの項目も、設定パターンに定型化され得る。このように、設定パターンは、ＶＰＮ間接続の種別などに応じて適切に定型化される。
【０２１５】
図３４に戻り、ＶＰＮ間接続要求記憶部２２３は、ＶＰＮ間接続要求情報を記憶する。ＶＰＮ間接続要求記憶部２２３は、後述するＶＰＮ間接続要求受付部２３１によって格納されることで、ＶＰＮ間接続要求情報を記憶する。また、ＶＰＮ間接続要求記憶部２２３が記憶するＶＰＮ間接続要求情報は、後述する仮想ルータ構築部２３２、変換用アドレス決定部２３３、ルーティング情報生成部２３５による処理などに利用される。
【０２１６】
図３８は、ＶＰＮ間接続要求記憶部２２３を説明するための図である。図３８に例示するように、例えば、ＶＰＮ間接続要求記憶部２２３は、ＶＰＮ間接続要求情報として、ＶＰＮ間接続サービスを開始すべきサービス開始時刻と、ＶＰＮ間接続サービスを終了すべきサービス終了時刻と、ＶＰＮ間接続のＶＣＳ名と、ＶＰＮ間接続が設定される仮想ルータ名と、ＶＰＮ間接続に収容される拠点（又は拠点のユーザ）を識別する識別情報（端末名）とを対応付けて記憶する。
【０２１７】
例えば、サービス開始時刻『ｔ１』と、サービス終了時刻『ｔ３』と、ＶＣＳ名『ＶＣＳ_α』と、仮想ルータ名『ＶＲＦ_m』及び『ＶＲＦ_n』と、端末名『α１＠ｖｃｓα．ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』及び『β１＠ｖｃｓα．ｖｐｎ２．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』とを対応付けて記憶する。時刻『ｔ１』から『ｔ３』までの間、『α１＠ｖｃｓα．ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』と『β１＠ｖｃｓα．ｖｐｎ２．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』とをＶＰＮ間接続するＶＰＮ間接続要求がなされ、当該ＶＰＮ間接続が設定されるＶＣＳ名が『ＶＣＳ_α』であること、仮想ルータ名が『ＶＲＦ_m』及び『ＶＲＦ_n』であることを示す。なお、説明の便宜上、サービス開始時刻やサービス終了時刻を『ｔ１』、『ｔ３』などと記載するが、例えば、『2009/8/21 13:00』といった具体的な年月日や時刻を示す。また、端末名が図３５に例示したものと異なっているが（「ｖｃｓα」が追加されている）、元々ＶＰＮ間接続情報記憶部１２１に登録されていた端末名に、ＶＣＳ名を追加した新たな端末名が、ＶＰＮ間接続要求記憶部１２３には格納される。
【０２１８】
図３４に戻り、アドレス変換情報記憶部２２４は、予約情報及びアドレス変換情報を記憶する。ここで、アドレス変換情報とは、後述する変換用アドレス決定部２３３によって決定されたアドレスがアドレス変換装置を境界として相互に変換されるように変換する変換情報である。なお、ここでは、変換用アドレス決定部２３３が、上述したＩＰアドレス払い出し方式（ｉ）に従ってアドレスを決定することを想定する。
【０２１９】
アドレス変換情報記憶部２２４は、後述する変換用アドレス決定部２３３によって格納されることで、予約情報及びアドレス変換情報を記憶する。また、アドレス変換情報記憶部２２４が記憶する予約情報及びアドレス変換情報は、アドレス変換情報設定部２３４による処理などに利用される。
【０２２０】
図３９は、アドレス変換情報記憶部２２４を説明するための図である。図３９に例示するように、例えば、アドレス変換情報記憶部２２４は、予約情報として、ＶＰＮ間接続サービスを開始すべきサービス開始時刻と、ＶＰＮ間接続サービスを終了すべきサービス終了時刻とを記憶する。また、アドレス変換情報記憶部２２４は、予約情報と対応付けて、アドレス変換情報を記憶する。例えば、アドレス変換情報記憶部２２４は、アドレス変換情報として、ＶＣＳ名と、仮想ルータ名と、アドレス変換装置に設定されるアドレス変換テーブルとを対応付けて記憶する。
【０２２１】
例えば、サービス開始時刻『ｔ１』及びサービス終了時刻『ｔ３』と対応付けて記憶されているアドレス変換情報は、ＶＣＳ名『ＶＣＳ_α』によって識別される仮想ルータに関するアドレス変換情報である。
【０２２２】
また、アドレス変換装置１−１及びアドレス変換装置１−２においては、拠点内アドレス『１９２．１６８．１．１０』と第二アドレス『１０．０．１．１０』とを相互に変換すること、第一アドレス『１７２．１６．２．１０』と第二アドレス『１０．０．２．１０』とを相互に変換することを示す。ここで、拠点内アドレス『１９２．１６８．１．１０』は、拠点にて用いられている拠点内アドレスであり、第一アドレス『１７２．１６．２．１０』は、当該拠点にて通信相手となる他拠点配下の端末を識別するためのアドレスである。
【０２２３】
また、アドレス変換装置２−１及び２−２においては、第一アドレス『１７２．１６．１．１０』と第二アドレス『１０．０．１．１０』とを相互に変換すること、拠点内アドレス『１９２．１６８．１．１０』と第二アドレス『１０．０．２．１０』とを相互に変換することを示す。
【０２２４】
なお、図３９においては、ＶＣＳ名『ＶＣＳ_α』によって識別される仮想ルータに関するアドレス変換情報のみを例示したが、アドレス変換情報記憶部２２４は、ＶＰＮ間接続管理システム２００によって構築された他の仮想ルータに関するアドレス変換情報も記憶している。
【０２２５】
また、図３９においては図示を省略したが、アドレス変換情報記憶部２２４は、プライベートアドレス全体の値、及び、各機器のインタフェースに割り当てられるアドレスとして予め確保されたアドレスも記憶する。
【０２２６】
すなわち、後述するように、変換用アドレス決定部２３３は、プライベートアドレス全体のうち、拠点内アドレス、既に予約されたアドレス、利用中のアドレス以外のアドレスを、新たに払い出すアドレスとして決定する。このため、アドレス変換情報記憶部２２４がプライベートアドレス全体の値を初期値として記憶しておくことで、変換用アドレス決定部２３３は、アドレス変換情報記憶部２２４を参照し、変換用のアドレスを決定することができる。
【０２２７】
また、後述するように、ルーティング情報生成部２３５は、集合仮想ルータのインタフェースに設定するアドレス、ＶＰＮ終端装置のインタフェースに設定するアドレス、アドレス変換装置のインタフェースに設定するアドレスを割り当てるが、変換用アドレス決定部２３３は、各機器のインタフェースに割り当てられたこれらのアドレスとも重複しないように変換用のアドレスを決定しなければならない。このため、アドレス変換情報記憶部２２４が、各機器のインタフェースに割り当てられるアドレスとして予め確保されたアドレスを記憶しておくことで、変換用アドレス決定部２３３は、アドレス変換情報記憶部２２４を参照し、各機器のインタフェースに割り当てられた（あるいは割り当てられる）これらのアドレスと重複しないように、変換用のアドレスを決定することができる。
【０２２８】
図３４に戻り、ルーティング情報記憶部２２５は、予約情報及びルーティング情報を記憶する。ルーティング情報記憶部２２５は、後述する仮想ルータ構築部２３２及びルーティング情報生成部２３５によって格納されることで、予約情報及びルーティング情報を記憶する。また、ルーティング情報記憶部２２５が記憶する予約情報及びルーティング情報は、ルーティング情報設定部２３６による処理などに利用される。
【０２２９】
図４０及び図４１は、ルーティング情報記憶部２２５を説明するための図である。図４０に例示するように、例えば、ルーティング情報記憶部２２５は、予約情報として、ＶＰＮ間接続サービスを開始すべきサービス開始時刻と、ＶＰＮ間接続サービスを終了すべきサービス終了時刻とを記憶する。また、ルーティング情報記憶部２２５は、予約情報と対応付けて、ルーティング情報を記憶する。例えば、ルーティング情報記憶部２２５は、集合仮想ルータに設定される設定情報（ルーティング情報を含む）を設定ファイルの形式で記憶し、ＶＰＮ終端装置に設定される設定情報を設定ファイルの形式で記憶し、アドレス変換装置に設定される設定情報を設定ファイルの形式で記憶する。
【０２３０】
例えば、図４１の（Ａ）は、集合仮想ルータに設定される設定情報の一部を例示するものである。また、例えば、図４１の（Ｂ）は、ＶＰＮ終端装置に設定される設定情報の一部を例示するものである。例えば、図４１の（Ｃ）は、アドレス変換装置に設定される設定情報の一部を例示するものである。
【０２３１】
図３４に戻り、アタッチメント記憶部２２６は、集合仮想ルータごと、ＶＰＮ終端装置ごと、アドレス変換装置ごとに、アタッチメントを記憶する。ここで、アタッチメントとは、アドレス変換情報をアドレス変換装置に反映するためのプログラム、ルーティング情報をＶＰＮ終端装置及び集合仮想ルータに対して反映するためのプログラム、及び、アドレス変換装置に対して反映されたアドレス変換情報を削除するためのプログラム、ＶＰＮ終端装置及び集合仮想ルータに対して反映されたルーティング情報を削除するためのプログラムである。
【０２３２】
また、アタッチメントには、ＶＰＮ間接続管理システム２００とアドレス変換装置との間で用いられる通信プロトコル、ＶＰＮ間接続管理システム２００とＶＰＮ終端装置との間で用いられる通信プロトコルや、ＶＰＮ間接続管理システム２００と集合仮想ルータとの間で用いられる通信プロトコルが規定される。なお、一般に、当該通信プロトコルには、アドレス変換装置のベンダ、ＶＰＮ終端装置のベンダや集合仮想ルータのベンダによって規定される独自仕様の通信プロトコルが用いられる。アタッチメント記憶部２２６は、例えばＶＰＮ間接続管理システム２００の運用者に入力されることで、アタッチメントを事前に記憶する。また、アタッチメント記憶部２２６が記憶するアタッチメントは、後述するアドレス変換情報設定部２３４、ルーティング情報設定部２３６及び削除部２３７による処理に利用される。
【０２３３】
図４２は、アタッチメント記憶部２２６を説明するための図である。図４２に例示するように、例えば、アタッチメント記憶部２２６は、集合仮想ルータ、ＶＰＮ終端装置やアドレス変換装置の装置識別情報とアタッチメントとを対応付けて記憶する。例えば、反映用のアタッチメントには、アドレス変換装置、ＶＰＮ終端装置や集合仮想ルータにログインするためのＩＤ／パスワードや、アドレス変換情報やルーティング情報を格納すべきパスを指定し、指定したパスにアドレス変換情報やルーティング情報を格納するためのコマンド、アドレス変換装置、ＶＰＮ終端装置や集合仮想ルータを再起動させるコマンドなどが記載される。なお、アドレス変換情報やルーティング情報の反映には、格納して再起動することで反映する場合と、格納によって反映する場合とがある。また、反映用のアタッチメントには、ＶＰＮ間接続管理システム２００とアドレス変換装置との間で用いられる通信プロトコル、ＶＰＮ間接続管理システム２００とＶＰＮ終端装置との間で用いられる通信プロトコルや、ＶＰＮ設定システムと集合仮想ルータとの間で用いられる通信プロトコルが規定される。
【０２３４】
また、例えば、削除用のアタッチメントには、アドレス変換装置、ＶＰＮ終端装置や集合仮想ルータにログインするためのＩＤ／パスワードや、アドレス変換情報やルーティング情報が格納されているパスからアドレス変換情報やルーティング情報を削除するためのコマンド、アドレス変換装置、ＶＰＮ終端装置や集合仮想ルータを再起動させるコマンドなどが記載される。また、削除用のアタッチメントには、ＶＰＮ間接続管理システム２００とアドレス変換装置との間で用いられる通信プロトコル、ＶＰＮ間接続管理システム２００とＶＰＮ終端装置との間で用いられる通信プロトコルや、ＶＰＮ設定システムと集合仮想ルータとの間で用いられる通信プロトコルが規定される。
【０２３５】
図３４に戻り、装置情報記憶部２２７は、ＶＰＮ終端装置に事前設定されたＶＰＮ終端装置の事前設定情報、及び、集合仮想ルータに事前設定された集合仮想ルータの事前設定情報を記憶する。装置情報記憶部２２７は、例えばＶＰＮ間接続管理システム２００の運用者に入力されることで、ＶＰＮ終端装置の事前設定情報及び集合仮想ルータの事前設定情報を事前に記憶する。また、装置情報記憶部２２７が記憶する事前設定情報は、後述するルーティング情報生成部２３５による処理などに利用される。
【０２３６】
図４３は、集合仮想ルータの事前設定情報を説明するための図である。図４３に例示するように、例えば、装置情報記憶部２２７は、集合仮想ルータの事前設定情報として、ホスト名（又はルータ名）及びパスワードを記憶する。「ホスト名」は、集合仮想ルータの名称であり、例えば『ｊｐｎ１００』といった名称である。「パスワード」は、集合仮想ルータにログインするためのパスワードであり、例えば『ｒｏｏｔｒｏｏｔ』といったパスワードである。
【０２３７】
図４４は、ＶＰＮ終端装置の事前設定情報を説明するための図である。図４４に例示するように、例えば、装置情報記憶部２２７は、ＶＰＮ終端装置の事前設定情報として、ホスト名（又はルータ名）、パスワード、ＶＰＮ終端装置ＩＤ、ＶＰＮ種別、集合仮想ルータ向けＩＰアドレス、サーバモードを記憶する。また、図４４においては図示を省略するが、装置情報記憶部２２７は、事前設定情報として、例えば、サーバ側待ち受けＩＰアドレス、プロトコル、ポート番号なども記憶する。
【０２３８】
「ホスト名」は、ＶＰＮ終端装置の名称であり、例えば『ｊｐｎ１』といった名称である。「パスワード」は、ＶＰＮ終端装置にログインするためのパスワードであり、例えば『ｒｏｏｔｒｏｏｔ』といったパスワードである。「ＶＰＮ終端装置ＩＤ」は、ＶＰＮ終端装置を識別するＩＤであり、例えば『ＶＰＮ終端装置１』といったＩＤである。「ＶＰＮ種別」は、ＶＰＮ種別であり、例えば『ＯｐｅｎＶＰＮ』といった種別である。
【０２３９】
「集合仮想ルータ向けＩＰアドレス」は、拠点から送出されたパケットを集合仮想ルータに向けて送出する際に転送すべきＩＰアドレスであり、集合仮想ルータに仮想ルータが構築され、集合仮想ルータのインタフェースにＩＰアドレスが割り当てられて初めて決定するものである。このため、図２７においては、未だ割り当てられていないという意味で空欄とする。サーバモードは、ＶＰＮ終端装置が選択したルーティング方式であり、例えばＯｐｅｎＶＰＮを用いる場合、ルーティング方式には『ｒｏｕｔｉｎｇ』と『ｂｒｉｄｇｅ』とがある。
【０２４０】
図３４に戻り、制御部１３０は、ＶＰＮ間接続管理システム２００において実行される各種処理を制御する。具体的には、図３４に例示するように、制御部２３０は、ＶＰＮ間接続要求受付部２３１と、仮想ルータ構築部２３２と、変換用アドレス決定部２３３と、アドレス変換情報設定部２３４と、ルーティング情報生成部２３５と、ルーティング情報設定部２３６と、削除部２３７とを有する。
【０２４１】
ＶＰＮ間接続要求受付部２３１は、ＶＰＮ間接続要求を受け付ける。具体的には、例えば、インターネットなどのネットワークにユーザ用のＷｅｂサーバが設置され、ＶＰＮ間接続要求受付部２３１は、ユーザ用の入力画面をＷｅｂサーバに配信する。ここで、ユーザ用の入力画面とは、ＶＰＮ間接続を行うＶＰＮの管理者から、そのＶＰＮ間接続要求を受け付けるために、ＶＰＮ間接続サービスを提供する電気通信事業者などが提供するものである。すると、例えば拠点それぞれの管理者が、当該Ｗｅｂサーバにアクセスし、ユーザ用の入力画面にＶＰＮ間接続要求を入力することで、ＶＰＮ間接続要求受付部２３１は、ＶＰＮ間接続要求の入力を受け付け、受け付けたＶＰＮ間接続要求をＶＰＮ間接続要求記憶部２２３に格納する。なお、この際、ＶＰＮ間接続要求受付部２３１は、ＶＣＳ名を追加した新たな端末名を、ＶＰＮ間接続要求記憶部１２３に格納する。
【０２４２】
図４５は、ＶＰＮ間接続要求の入力画面の一例を説明するための図である。例えば、ＶＰＮ間接続要求受付部２３１は、まず、図４５の（Ａ）に例示する入力画面を出力する。入力画面には、ＶＰＮ間接続の名前であるところの仮想協働空間（ＶＣＳ）名『ＶＣＳ_α』の入力を受け付ける枠、及び、パスワードの入力を受け付ける枠が設けられる。なお、ＶＣＳ名及びパスワードは、例えば、同じ協働空間に属する予定の『Ａ社』と『Ｂ社』との間で、オフラインで決定されるなどする。こうして、例えば、図４５の（Ａ）に例示するように、『Ａ社』の管理者がＶＣＳ名『ＶＣＳ_α』及びパスワードを入力すると、ＶＰＮ間接続要求受付部２３１は、ＶＣＳ名として『ＶＣＳ_α』を受け付け、続いて、『Ａ社』に関する情報を受け付ける。なお、ＶＰＮ間接続要求として仮想協働空間名の入力を受け付ける例を説明するが、これに限られるものではなく、例えば、ＶＰＮ間接続管理システム２００側で仮想協働空間名を自動的に割り当ててもよい。
【０２４３】
また、図４５の（Ｂ）に例示するように、図４５の（Ａ）に例示する入力画面に続く次の入力画面には、接続先ＩＤ及び端末名の入力を受け付ける枠が設けられる。例えば、『Ａ社』の管理者が、接続先ＩＤとして『ＵｓｅｒＡ−Ｏｆｆｉｃｅ』を入力し、端末名として『α１＠ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』を入力すると、ＶＰＮ間接続要求受付部２３１は、ＶＣＳ名『ＶＣＳ_α』によってＶＰＮ間接続される『Ａ社』側の端末として『α１＠ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』を受け付ける。なお、例えば『Ｍｏｒｅ』のボタンが管理者によって押下されると、ＶＰＮ間接続要求受付部２３１は、入力画面上に、端末名の入力を受け付ける枠をさらに設ける。
【０２４４】
また、入力画面には、予約時間の年月日及び時刻の入力を受け付ける枠が設けられる。例えば、図４５の（Ｂ）に例示するように、管理者が、予約時間『２００９．８．２１ １３：００』〜『２００９．８．２１ １５：００』を入力すると、ＶＰＮ間接続要求受付部２３１は、ＶＰＮ間接続サービス開始時刻として『２００９．８．２１ １３：００』、ＶＰＮ間接続サービス終了時刻として『２００９．８．２１ １５：００』を受け付ける。
【０２４５】
さて、図４５の（Ｂ）に例示する入力画面において、例えば『ＯＫ』ボタンが管理者によって押下されると、ＶＰＮ間接続要求受付部２３１は、ＶＰＮ間接続要求の受け付けを終了する。なお、この後、『Ｂ社』の管理者も同様に、ＶＣＳ名『ＶＣＳ_α』によってＶＰＮ間接続される端末として『β１＠ｖｐｎ２．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』を入力する。
【０２４６】
例えば、『Ｂ社』の管理者が、入力画面にＶＣＳ名『ＶＣＳ_α』及びパスワードを入力すると、ＶＰＮ間接続要求受付部２３１は、ＶＣＳ名として『ＶＣＳ_α』を受け付ける。ここで、ＶＣＳ名『ＶＣＳ_α』によって識別されるＶＰＮ間接続については、既に『Ａ社』の管理者が予約時間の年月日及び時刻の入力を済ませているので、例えば、ＶＰＮ間接続要求受付部２３１は、図４５の（Ｂ）に例示する入力画面のうち、予約時間の年月日及び時刻が入力された状態の入力画面を出力してもよい。すると、例えば、『Ｂ社』の管理者が、接続先ＩＤとして『ＵｓｅｒＢ−Ｏｆｆｉｃｅ』を入力し、端末名として『β１＠ｖｐｎ２．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』を入力すると、ＶＰＮ間接続要求受付部２３１は、ＶＣＳ名『ＶＣＳ_α』によってＶＰＮ間接続される『Ｂ社』側の端末として『β１＠ｖｐｎ２．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』を受け付ける。こうして、『端末α』と『端末β』とを接続するためのＶＰＮ間接続要求として、ＶＣＳ名『ＶＣＳ_α』によって識別されるＶＰＮ間接続要求が受け付けられる。
【０２４７】
なお、ユーザ用の入力画面にＶＰＮ間接続要求を入力させる手法を説明したが、これに限られるものではない。例えば、ＶＰＮ間接続サービスを提供する電気通信事業者などの運用者が、ＶＰＮ間接続管理システム２００の出力部２１２に出力された入力画面に直接ＶＰＮ間接続要求を入力する手法でもよい。
【０２４８】
仮想ルータ構築部２３２は、ＶＰＮ間接続要求に基づき、集合仮想ルータに仮想ルータを構築する。具体的には、仮想ルータ構築部２３２は、ＶＰＮ間接続要求受付部２３１によって受け付けられたＶＰＮ間接続要求に基づき、集合仮想ルータに構築すべき仮想ルータ名を決定する。また、仮想ルータ構築部２３２は、集合仮想ルータに設定する設定情報のうち仮想ルータの構築情報を生成し、生成した仮想ルータの構築情報を予約情報とともにルーティング情報記憶部２２５に格納する。また、仮想ルータ構築部２３２は、変換用アドレス決定部２３３に、アドレス変換情報を生成すべき旨を通知する。
【０２４９】
例えば、仮想ルータ構築部２３２は、ＶＰＮ間接続要求記憶部２２３（図３８に例示）を定期的に参照し、現在時刻とサービス開始時刻とを比較して、仮想ルータを構築すべきタイミングであるか否かを判定する。例えば、仮想ルータ構築部２３２は、現在時刻とサービス開始時刻『ｔ１』とを比較して、仮想ルータを構築すべきタイミングであるか否かを判定する。
【０２５０】
次に、仮想ルータ構築部２３２は、仮想ルータを構築すべきタイミングであると判定すると、ＶＰＮ間接続要求記憶部２２３を参照し、サービス開始時刻に対応付けて記憶されているＶＣＳ名及び端末名を取得する。例えば、仮想ルータ構築部２３２は、サービス開始時刻『ｔ１』に対応付けて記憶されているＶＣＳ名『ＶＣＳ_α』、並びに、端末名『α１＠ｖｃｓα．ｖｐｎ１．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』及び『β１＠ｖｃｓα．ｖｐｎ２．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ』を取得する。
【０２５１】
そして、仮想ルータ構築部２３２は、取得した端末名を用いてＶＰＮ間接続情報記憶部２２１（図３５に例示）を参照し、端末名によって識別される拠点が収容される集合仮想ルータを特定し、設定パターンの識別情報を取得する。例えば、仮想ルータ構築部２３２は、集合仮想ルータ『集合仮想ルータ１』を特定し、設定パターンの識別情報『ＶＲ−Ｐ１』を取得する。
【０２５２】
続いて、仮想ルータ構築部２３２は、取得した設定パターンの識別情報を用いて設定パターン記憶部２２２（図３６に例示）を参照し、区分『仮想ルータ定義』に対応付けて記憶されている仕様を取得する。ここで、図３６には例示しなかったが、設定パターン記憶部２２２は、設定パターンの一つとして、設定情報を集合仮想ルータに反映するための所定のコマンド文も集合仮想ルータごとに記憶する。このため、仮想ルータ構築部２３２は、該当する所定のコマンド文も取得する。
【０２５３】
そして、仮想ルータ構築部２３２は、ＶＰＮ間接続要求記憶部２２３（図３８に例示）を参照してサービス開始時刻及びサービス終了時刻を取得し、取得したサービス開始時刻及びサービス終了時刻をルーティング情報記憶部２２５（図４０に例示）に格納する。例えば、仮想ルータ構築部２３２は、サービス開始時刻『ｔ１』及びサービス終了時刻『ｔ３』をルーティング情報記憶部２２５に格納する。
【０２５４】
次に、仮想ルータ構築部２３２は、取得した仕様やコマンド文を用いて仮想ルータの構築情報をファイルに記載し、サービス開始時刻及びサービス終了時刻に対応付けてルーティング情報記憶部２２５に格納する。例えば、仮想ルータ構築部２３２は、仮想ルータ名『ＶＲＦ_m』を、取得した所定のコマンド文を用いて『ｉｐ ｖｒｆ ｖｒｆｍ』と記載したファイルを作成する。また、仮想ルータ構築部２３２は、作成したファイルに、図３６に例示する仕様に従って決定した仮想ルータＩＤ『１００：１０』を、所定のコマンド文を用いて『ｒｄ １００：１０』と記載する。そして、仮想ルータ構築部２３２は、作成したファイルをサービス開始時刻『ｔ１』及びサービス終了時刻『ｔ３』に対応付けてルーティング情報記憶部２２５に格納する（図４１の（Ａ）を参照）。
【０２５５】
変換用アドレス決定部２３３は、ＶＰＮ間接続要求に基づき、ＶＰＮ間接続に用いられるアドレスを決定する。具体的には、変換用アドレス決定部２３３は、ＶＰＮ間接続要求受付部２３１によって受け付けられたＶＰＮ間接続要求に基づき、ＶＰＮ間接続に用いられるアドレスを決定し、アドレス変換情報を生成する。ここでは、変換用アドレス決定部２３３は、上述したＩＰアドレス払い出し方式（ｉ）によってアドレスを決定する。
【０２５６】
また、ＶＰＮ間接続管理システム２００は、プライベートアドレス全体を、ＶＰＮ間接続サービスに利用することができるアドレスとして管理するものとする。すなわち、ＶＰＮ間接続管理システム２００は、上述したように、アドレス変換情報記憶部２２４が、プライベートアドレス全体の値、及び、各機器のインタフェースに割り当てられるアドレスとして予め確保されたアドレスも記憶する。また、ＶＰＮ間接続管理システム２００は、利用者から事前に申請してもらうことなどにより、拠点ごとに、その拠点にて用いられているプライベートアドレス（ＶＰＮ間接続情報記憶部２２１の『拠点内アドレス』）を管理している。
【０２５７】
このため、変換用アドレス決定部２３３は、アドレス変換情報記憶部２２４を参照し、既に予約されたアドレスを時間軸上で探索する。そして、変換用アドレス決定部２３３は、第一アドレスを決定する際には、プライベートアドレス全体のうち、拠点内アドレス、同じ時間帯に既に予約されたアドレスとして探索されたアドレス、及び各機器のインタフェースに割り当てられるアドレスとして予め確保されたアドレス以外のアドレスを、新たに払い出すアドレスとして決定すればよい。また、変換用アドレス決定部２３３は、第二アドレスを決定する際には、プライベートアドレス全体のうち、同じＶＰＮ間接続について既に予約されたアドレスとして探索されたアドレス、及び各機器のインタフェースに割り当てられるアドレスとして予め確保されたアドレス以外のアドレスを、新たに払い出すアドレスとして決定すればよい。
【０２５８】
なお、この手法に限られるものではない。例えば、ＶＰＮ間接続管理システム２００が、利用者から事前に申請してもらうことなどにより、拠点ごとに、その拠点にて用いることができるプライベートアドレスを管理しているとする。この場合には、変換用アドレス決定部２３３は、既に予約されたアドレスを時間軸上で探索し、その拠点にて用いることができるプライベートアドレスとして管理しているプライベートアドレスのうち、拠点内アドレス及び既に予約されたアドレスとして探索されたアドレス以外のアドレスを、新たに払い出すアドレスとして決定すればよい。なお、この場合には、ＶＰＮ間接続管理システム２００は、拠点にて用いることができるプライベートアドレスの値を、拠点ごとに別途記憶する。例えば、ＶＰＮ間接続管理システム２００は、拠点にて用いることができるプライベートアドレスの値を、ＶＰＮ間接続情報記憶部２２１に記憶する。
【０２５９】
また、変換用アドレス決定部２３３は、生成したアドレス変換情報を予約情報とともにアドレス変換情報記憶部２２４に格納する。また、変換用アドレス決定部２３３は、ルーティング情報生成部２３５に、ルーティング情報を含む設定情報を生成すべき旨を通知する。
【０２６０】
アドレス変換情報設定部２３４は、アドレス変換情報をアドレス変換装置に設定する。具体的には、アドレス変換情報設定部２３４は、変換用アドレス決定部２３３によって決定された第一アドレスと第二アドレスとが、アドレス変換装置を境界として相互に変換されるように、アドレス変換情報をアドレス変換装置に設定する。
【０２６１】
例えば、アドレス変換情報設定部２３４は、アドレス変換情報記憶部２２４（図３９に例示）を定期的に参照し、現在時刻とサービス開始時刻とを比較して、アドレス変換情報を設定すべきタイミングであるか否かを判定する。例えば、アドレス変換情報設定部２３４は、現在時刻とサービス開始時刻『ｔ１』とを比較して、アドレス変換情報を設定すべきタイミングであるか否かを判定する。
【０２６２】
次に、アドレス変換情報設定部２３４は、アドレス変換情報を設定すべきタイミングであると判定すると、アドレス変換情報記憶部２２４を参照し、サービス開始時刻に対応付けて記憶されているアドレス変換情報を取得する。例えば、アドレス変換情報設定部２３４は、『アドレス変換装置１−１、１−２』及び『アドレス変換装置２−１、２−２』に対応付けて記憶されているアドレス変換テーブルを取得する。
【０２６３】
そして、アドレス変換情報設定部２３４は、アタッチメント記憶部２２６（図４２に例示）を参照し、該当するアタッチメントを取得し、取得したアタッチメントを用いて、該当するアドレス変換装置にアドレス変換情報を送信する。例えば、アドレス変換情報設定部２３４は、『アドレス変換装置１−１、１−２』及び『アドレス変換装置２−１、２−２』を用いてアタッチメント記憶部２２６を参照し、アタッチメント『ＮＡＴ１−１．ｅｘｅ』、『ＮＡＴ１−２．ｅｘｅ』、『ＮＡＴ２−１．ｅｘｅ』及び『ＮＡＴ２−２．ｅｘｅ』を取得する。続いて、アドレス変換情報設定部２３４は、取得したアタッチメント『ＮＡＴ１−１．ｅｘｅ』を用いて、アドレス変換情報記憶部２２４において『アドレス変換装置１−１』に対応付けて記憶されているアドレス変換情報を『アドレス変換装置１−１』に送信する。
【０２６４】
なお、アドレス変換情報設定部２３４は、ＶＰＮ間接続サービスを開始する時刻にアドレス変換情報の設定を開始するものとして説明するが、これに限られるものではない。ＶＰＮ間接続サービスを開始する時刻として予約を受け付けた時刻には即時にＶＰＮ間接続が実現されるように、例えば、アドレス変換情報の設定に要する時間を予め予測し、『サービス開始時刻』から、予測した当該時間を差し引いた時刻を、アドレス変換情報の反映を開始する時刻としてもよい。例えば、変換用アドレス決定部２３３が、アドレス変換情報記憶部２２４に予約時間とアドレス変換情報とを格納する際に、アドレス変換情報の設定に要する時間を差し引いた時刻も併せて格納し、アドレス変換情報設定部２３４が、当該時刻であるか否かを判定してアドレス変換情報の設定を開始してもよい。
【０２６５】
ルーティング情報生成部２３５は、ＶＰＮ間接続要求及びアドレス変換情報に基づき、ルーティング情報を生成する。具体的には、ルーティング情報生成部２３５は、各機器（集合仮想ルータ、ＶＰＮ終端装置、アドレス変換装置）のインタフェースに設定するアドレスを、予め確保されたアドレスの中から割り当てる。また、ルーティング情報生成部２３５は、変換用アドレス決定部２３３によって決定されたアドレス変換情報に基づきルーティング情報を生成する。また、ルーティング情報生成部２３５は、生成したルーティング情報を予約情報とともにルーティング情報記憶部２２５に格納する。なお、既に仮想ルータ構築部２３２が、仮想ルータの構築情報をファイルに記載してルーティング情報記憶部２２５に格納しているので、ルーティング情報生成部２３５は、このファイルに、ルーティング情報（ＶＰＮ終端装置（Next Hop）へのルーティング情報）などを追記することになる。また、ルーティング情報生成部２３５は、ＶＰＮ終端装置のファイルには、集合仮想ルータ（Next Hop）へのルーティング情報など、アドレス変換装置のファイルには、パケットの転送情報などを記載することになる。
【０２６６】
まず、集合仮想ルータの設定情報の生成について説明する。例えば、ルーティング情報生成部２３５は、変換用アドレス決定部２３３からルーティング情報を含む設定情報を生成すべき旨の通知を受けると、アドレス変換情報記憶部２２４（図３９に例示）を参照し、アドレス変換装置側Ｉ／Ｆに設定すべきアドレスを決定する。例えば、ルーティング情報生成部２３５は、アドレス変換装置１側のＩ／Ｆとして『１０．０．１０．９７』を決定し、アドレス変換装置２側のＩ／Ｆとして『１０．０．２０．９７』を決定する。
【０２６７】
また、ルーティング情報生成部２３５は、設定パターン記憶部２２２（図３６に例示）を参照し、区分『Ｉ／Ｆの設定』及び『仮想ルータ単位のルーティング設定』に対応付けて記憶されている仕様を取得する。ここで、図３６には例示しなかったが、設定パターン記憶部２２２は、設定パターンの一つとして、設定情報を集合仮想ルータに反映するための所定のコマンド文も集合仮想ルータごとに記憶する。このため、ルーティング情報生成部２３５は、該当する所定のコマンド文も取得する。
【０２６８】
そして、ルーティング情報生成部２３５は、『数字．数字．数字．数字』の仕様に従って「ＩＰアドレス」を決定する。また、例えば、ルーティング情報生成部２３５は、図３６に例示する設定パターンを参照し、『Ｉ／Ｆの種別 数字／数字／数字』の仕様に従って「Ｉ／Ｆの指定」を決定する。
【０２６９】
例えば、ルーティング情報生成部２３５は、アドレス変換装置１−１と接続するインタフェースに設定するＩＰアドレスとして『１０．０．１０．９７ ２５５．２５５．２５５．０』を決定し、Ｉ／Ｆの指定として『ＧｉｇａｂｉｔＥｔｈｅｒｎｅｔ（登録商標）１／０／０』を決定する。
【０２７０】
次に、ルーティング情報生成部２３５は、アドレス変換情報記憶部２２４を参照し、アドレス変換装置に対応付けて記憶されている仮想ルータ側アドレスを取得する。例えば、ルーティング情報生成部２３５は、アドレス変換装置『アドレス変換装置１−１』と対応付けて記憶されている仮想ルータ側アドレス『１０．０．１．１０』及び『１０．０．２．１０』を取得する。
【０２７１】
そして、例えば、ルーティング情報生成部２３５は、図４１の（Ａ）に示すように、アドレス変換装置１−１と接続するインタフェースに設定するＩＰアドレスとして決定した『１０．０．１０．９７ ２５５．２５５．２５５．０』を、所定のコマンド文を用いて『ｉｐ ａｄｄｒｅｓｓ １０．０．１０．９７ ２５５．２５５．２５５．０』と記載する。また、例えば、ルーティング情報生成部２３５は、Ｉ／Ｆの指定として決定した『ＧｉｇａｂｉｔＥｔｈｅｒｎｅｔ（登録商標）１／０／０』を、所定のコマンド文を用いて『ｉｎｔｅｒｆａｃｅ ＧｉｇａｂｉｔＥｔｈｅｒｎｅｔ（登録商標）１／０／０』と記載する。その他、ルーティング情報生成部２３５は、インタフェースを仮想ルータ『ｖｒｆ１』に所属させるコマンドとして、『ｉｐ ｖｒｆ ｆｏｒｗａｒｄｉｎｇ ｖｒｆ１』と記載する。なお、ルーティング情報生成部２３５は、アドレス変換装置２と接続するインタフェースについても同様に記載する。
【０２７２】
また、ルーティング情報生成部２３５は、いわゆるルーティング情報であるルーティング設定コマンドを記載する。ここで、ＮｅｘｔＨｏｐはアドレス変換装置である。例えば、ルーティング情報生成部２３５は、仮想ルータ名『ＶＲＦ_m』と、『１０．０.１．０ ２５５．２５５．２５５．０』と、ＩＰアドレス『１０．０．１０．９８』とを用いて、図３６に例示する仕様に従い所定のコマンド文を用いて『ｉｐ ｒｏｕｔｅ ｖｒｆ ｖｒｆｍ １０．０.１．０ ２５５．２５５．２５５．０ １０．０．１０．９８』と記載する。なお、ルーティング情報生成部２３５は、アドレス変換装置２と接続するインタフェースについても同様に記載する。
【０２７３】
次に、ＶＰＮ終端装置の設定情報の生成について説明する。ルーティング情報生成部２３５は、ＶＰＮ間接続要求受付部２３１によって受け付けられた接続先ＩＤを用いてＶＰＮ間接続情報記憶部２２１を参照し、接続先ＩＤそれぞれと対応付けて記憶されているＶＰＮ終端装置の設定パターンの識別情報を取得する。そして、ルーティング情報生成部２３５は、ＶＰＮ終端装置の設定パターンの識別情報それぞれを用いて設定パターン記憶部２２２を参照し、設定パターン記憶部２２２に記憶されたＶＰＮ終端装置の設定パターンの中から設定情報の生成に利用すべきＶＰＮ終端装置の設定パターンを選択する。そして、ルーティング情報生成部２３５は、選択した設定パターンを用いて設定情報を生成する。
【０２７４】
例えば、ルーティング情報生成部２３５は、ＶＰＮ終端装置のＩ／Ｆ（拠点側及び集合仮想ルータ側）に設定すべきアドレスを決定し、決定したアドレスを用いてルーティング情報を生成する。例えば、ルーティング情報生成部２３５は、図４１の（Ｂ）に示すように、『ＶＰＮ終端装置１』のルーティング情報を生成する。図４１（Ｂ）の最初の４行は、『ＶＰＮ終端装置１』のインタフェースにアドレスを設定するコマンドである。また、図４１（Ｂ）の５行目は、ＮｅｘｔＨｏｐを『アドレス変換装置１』とするためのルーティング設定コマンドである。
【０２７５】
次に、アドレス変換装置の設定情報の生成について説明する。なお、図３６及び図３７においては図示を省略したが、設定パターン記憶部２２２は、アドレス変換装置の設定パターンも記憶する。このため、例えば、ルーティング情報生成部２３５は、ＶＰＮ間接続要求受付部２３１によって受け付けられた接続先ＩＤを用いてＶＰＮ間接続情報記憶部２２１を参照し、接続先ＩＤそれぞれと対応付けて記憶されているアドレス変換装置の識別情報を取得する。そして、ルーティング情報生成部２３５は、アドレス変換装置の設定パターンの識別情報それぞれを用いて設定パターン記憶部２２２を参照し、設定パターン記憶部２２２に記憶されたアドレス変換装置の設定パターンの中から設定情報の生成に利用すべきアドレス変換装置の設定パターンを選択する。そして、ルーティング情報生成部２３５は、選択した設定パターンを用いて設定情報を生成する。
【０２７６】
例えば、ルーティング情報生成部２３５は、アドレス変換装置のＩ／Ｆ（拠点側及び集合仮想ルータ側）に設定すべきアドレスを決定し、決定したアドレスを用いてルーティング情報を生成する。例えば、ルーティング情報生成部２３５は、図４１の（Ｃ）に示すように、『アドレス変換装置１』のルーティング情報を生成する。図４１（Ｃ）の最初の４行は、『アドレス変換装置１』のインタフェースにアドレスを設定するコマンドである。また、図４１（Ｃ）の５行目は、『ＶＰＮ終端装置１』側へのルーティング設定コマンドであり、アドレス変換前のアドレスを設定する。図４１（Ｃ）の６行目は、仮想ルータ『ｖｒｆｍ』側へのルーティング設定コマンドであり、アドレス変換後のアドレスを設定する。
【０２７７】
なお、上述したように、設定情報それぞれは、例えば、図４１に例示するように、設定ファイルの形式で、ルーティング情報記憶部２２５に記憶される。すなわち、ルーティング情報生成部２３５は、生成した設定情報それぞれを、設定ファイルの形式で、ルーティング情報記憶部２２５に格納する。もっとも、これに限られるものではなく、生成した設定情報をデータベースに格納する手法でもよい。あるいは、生成した設定情報をファイル形式で記憶するとともにデータベースにも格納する手法でもよい。これらの手法によれば、設定情報は、検索や参照に適したデータベースに格納されるので、例えば、ルーティング情報生成部２３５は、設定情報を生成する際に、既に生成された設定情報を参照して重複を判定するが、その都度ファイルオープンの処理を実行する必要がなく、処理が効率的になる。
【０２７８】
ルーティング情報設定部２３６は、ルーティング情報をアドレス変換装置、ＶＰＮ終端装置及び集合仮想ルータに設定する。例えば、ルーティング情報設定部２３６は、ルーティング情報記憶部２２５（図４０に例示）を定期的に参照し、現在時刻とサービス開始時刻とを比較して、設定情報を設定すべきタイミングであるか否かを判定する。例えば、ルーティング情報設定部２３６は、現在時刻とサービス開始時刻『ｔ１』とを比較して、設定情報を設定すべきタイミングであるか否かを判定する。
【０２７９】
次に、ルーティング情報設定部２３６は、設定情報を設定すべきタイミングであると判定すると、ルーティング情報記憶部２２５を参照し、サービス開始時刻に対応付けて記憶されている設定情報を取得する。例えば、ルーティング情報設定部２３６は、サービス開始時刻『ｔ１』に対応付けて記憶されている設定情報を取得する。
【０２８０】
そして、ルーティング情報設定部２３６は、アタッチメント記憶部２２６（図４２に例示）を参照し、該当するアタッチメントを取得し、取得したアタッチメントを用いて、該当する集合仮想ルータ、ＶＰＮ終端装置及びアドレス変換装置に設定情報を送信する。例えば、ルーティング情報設定部２３６は、『集合仮想ルータ１』、『ＶＰＮ終端装置１』、『ＶＰＮ終端装置２』、『アドレス変換装置１−１』、『アドレス変換装置１−２』、『アドレス変換装置２−１』、及び『アドレス変換装置２−２』を用いてアタッチメント記憶部２２６を参照し、アタッチメント『ＶＲ１．ｅｘｅ』、『ＶＰＮ１．ｅｘｅ』、『ＶＰＮ２．ｅｘｅ』、『ＮＡＴ１−１．ｅｘｅ』、『ＮＡＴ１−２．ｅｘｅ』、『ＮＡＴ２−１．ｅｘｅ』、及び『ＮＡＴ２−２．ｅｘｅ』を取得する。続いて、ルーティング情報設定部２３６は、取得したアタッチメント『ＶＲ１．ｅｘｅ』を用いて、設定情報を『集合仮想ルータ１』に送信する。同様に、ルーティング情報設定部２３６は、『ＶＰＮ終端装置１』、『ＶＰＮ終端装置２』、『アドレス変換装置１−１』、『アドレス変換装置１−２』、『アドレス変換装置２−１』、及び『アドレス変換装置２−２』にも設定情報を送信する。
【０２８１】
なお、アタッチメントには、例えば、ＶＰＮ間接続管理システム２００から各機器に対してｔｅｌｎｅｔやＳＳＨ（Secure SHell）などを用いて遠隔操作することにより、設定情報を設定する手法が含まれていてもよい。
【０２８２】
また、ルーティング情報設定部２３６は、ＶＰＮ間接続サービスを開始する時刻に設定情報の設定を開始するものとして説明するが、これに限られるものではない。ＶＰＮ間接続サービスを開始する時刻として予約を受け付けた時刻には即時にＶＰＮ間接続が実現されるように、例えば、設定情報の設定に要する時間を予め予測し、『サービス開始時刻』から、予測した当該時間を差し引いた時刻を、設定情報の設定を開始する時刻としてもよい。例えば、仮想ルータ構築部２３２が、ルーティング情報記憶部２２５に予約時間と設定情報とを格納する際に、設定情報の設定に要する時間を差し引いた時刻も併せて格納し、ルーティング情報設定部２３６が、当該時刻であるか否かを判定して設定情報の設定を開始してもよい。
【０２８３】
削除部２３７は、ＶＰＮ終端装置、アドレス変換装置、及び集合仮想ルータに設定されたアドレス変換情報やルーティング情報を削除する。具体的には、削除部２３７は、タイマやポーリングなどによって定期的にアドレス変換情報記憶部２２４やルーティング情報記憶部２２５を参照し、ＶＰＮ間接続サービスを終了する時刻であるか否かを判定する。サービス終了時刻であると判定すると、アタッチメント記憶部２２６を参照し、該当するＶＰＮ終端装置や集合仮想ルータのアタッチメント（削除用）を取得する。そして、削除部２３７は、該当するアタッチメントを用いて、該当するＶＰＮ終端装置や集合仮想ルータから設定情報を削除する。なお、削除部２３７は、アドレス変換情報記憶部２２４やルーティング情報記憶部２２５に記憶されている予約情報なども削除する。
【０２８４】
［ＶＰＮ間接続管理システムによる処理手順］
次に、図４６を用いて、ＶＰＮ間接続管理システム２００による処理手順を説明する。図４６は、ＶＰＮ間接続管理システム２００による処理手順を示すフローチャートである。
【０２８５】
図４６に例示するように、ＶＰＮ間接続管理システム２００は、仮想ルータを構築すべきタイミングであると判定すると（ステップＳ１肯定）、仮想ルータを構築する（ステップＳ２）。具体的には、仮想ルータ構築部２３２が、仮想ルータを構築する。
【０２８６】
次に、ＶＰＮ間接続管理システム２００は、変換用アドレスを決定する（ステップＳ３）。具体的には、変換用アドレス決定部２３３が、変換用アドレスを決定する。
【０２８７】
続いて、ＶＰＮ間接続管理システム２００は、ルーティング情報を生成する（ステップＳ４）。具体的には、ルーティング情報生成部２３５が、ルーティング情報を生成する。
【０２８８】
そして、ＶＰＮ間接続管理システム２００は、アドレス変換情報及びルーティング情報を設定する（ステップＳ５）。具体的には、アドレス変換情報設定部２３４が、該当するアドレス変換装置にアドレス変換情報を設定し、ルーティング情報設定部２３６が、該当する集合仮想ルータ及びＶＰＮ終端装置にルーティング情報を設定する。
【０２８９】
なお、サービス開始時刻までに、アドレス変換情報及びルーティング情報の設定が終了してれば、いつ仮想ルータを構築し、いつアドレス変換情報を決定し、いつルーティング情報を生成し、いつアドレス変換情報やルーティング情報を設定するかは、任意である。例えば、サービス開始時刻よりもかなり早い段階で設定まで終了させておき、ファイアウォールの設定などによりＶＰＮ間接続の通信を行わせないようにしてもよい。この場合には、サービス開始時刻になると、ファイアウォールの設定が変更され、ＶＰＮ間接続が可能になる。
【０２９０】
図４７を用いて、協働空間におけるアクセスの一例を説明する。図４７は、協働空間におけるアクセスの一例を説明するための図である。図４７では、端末αと端末βとの間で、協働空間『ＶＣＳ_α』（仮想ルータ『ＶＲＦm』及び仮想ルータ『ＶＲＦn』）が構築された例を説明する。端末αの協働空間『ＶＣＳ_α』内での名前（協働空間用に割り当てられたもの）は、協働空間内での名前空間のルールに基づき『α１＠vcsα.vpni.example.com』であり、拠点内アドレスは、『１９２．１６８．１．１０』である。
【０２９１】
また、端末βの協働空間『ＶＣＳ_α』内での名前（協働空間用に割り当てられたもの）は、『β１＠vcsα.vpnj.example.com』であり、拠点内アドレスは、『１９２．１６８．１．１０』である。また、端末α側の拠点にて端末βを識別する第一アドレスは、『１７２．１６．２．１０』であり、端末β側の拠点にて端末αを識別する第一アドレスは、『１７２．１６．１．１０』である。このため、図４７に例示するように、ＤＮＳには、『α１＠vcsα.vpni.example.com』と『１７２．１６．１．１０』との対応関係が登録され、『β１＠vcsα.vpnj.example.com』と『１７２．１６．２．１０』との対応関係が登録される。
【０２９２】
また、端末αを仮想ルータ『ＶＲＦm』内で識別する第二アドレスは、『１０．０．１．１０』であり、端末βを仮想ルータ『ＶＲＦm』内で識別する第二アドレスは、『１０．０．２．１０』である。なお、図４７の例では、仮想ルータ『ＶＲＦn』内で識別する第二アドレスも同じアドレスが払い出されるが、これに限られるものではない。
【０２９３】
このため、図４７に例示するように、ＶＰＮ_i側のアドレス変換装置には、拠点内アドレス『１９２．１６８．１．１０』と第二アドレス『１０．０．１．１０』とを変換するアドレス変換情報と、第一アドレス『１７２．１６．２．１０』と第二アドレス『１０．０．２．１０』とを変換するアドレス変換情報が設定される。また、ＶＰＮ_j側のアドレス変換装置には、拠点内アドレス『１９２．１６８．１．１０』と第二アドレス『１０．０．２．１０』とを変換するアドレス変換情報と、第一アドレス『１７２．１６．１．１０』と第二アドレス『１０．０．１．１０』とを変換するアドレス変換情報が設定される。
【０２９４】
また、各仮想ルータには、ルーティング情報が設定される。図４７に例示するように、宛先アドレスが『１０．０．１．１０』のパケットについては、ＶＰＮ_i側のＩ／Ｆにルーティングすること、宛先アドレスが『１０．０．２．１０』のパケットについては、ＶＰＮ_j側のＩ／Ｆにルーティングすることが設定される。
【０２９５】
このような構成のもと、例えば、端末αが端末βに対してパケットを送信する場合を考える。端末αのユーザは、端末βのユーザの端末名『β１＠vcsα.vpnj.example.com』を既知である。このため、端末αは、『β１＠vcsα.vpnj.example.com』を用いてＤＮＳに問い合わせを行う。ＤＮＳは、『β１＠vcsα.vpnj.example.com』を用いて記憶部を参照し、『β１＠vcsα.vpnj.example.com』に対応付けて記憶されている第一アドレス『１７２．１６．２．１０』を応答する。
【０２９６】
そこで、端末αは、パケットの宛先に第一アドレス『１７２．１６．２．１０』、送信元に拠点内アドレス『１９２．１６８．１．１０』が入ったパケットをＶＰＮ終端装置に向けて送信する。トラヒック分離統合装置は、このパケットを受け取ると、ポリシーベースのルーティングをし、アドレス変換装置に送出する。
【０２９７】
すると、アドレス変換装置は、受け取ったパケットのアドレスをアドレス変換情報に基づき変換する。例えば、宛先アドレス『１７２．１６．２．１０』を『１０．０．２．１０』に変換し、送信元アドレス『１９２．１６８．１．１０』を『１０．０．１．１０』に変換する。そして、アドレス変換装置は、アドレス変換後のパケットを集合仮想ルータに送出する。集合仮想ルータにおいては、宛先アドレスに基づくルーティングが行われる。宛先アドレス『１０．０．２．１０』のパケットは、ＶＰＮ_j側のＩ／Ｆにルーティングされる。
【０２９８】
さて、ＶＰＮ_j側のＩ／Ｆにルーティングされたパケットは、ＶＰＮ_j側のアドレス変換装置を到達する。すると、アドレス変換装置は、受け取ったパケットのアドレスをアドレス変換情報に基づき変換する。例えば、宛先アドレス『１０．０．２．１０』を『１９２．１６８．１．１０』に変換し、送信元アドレス『１０．０．１．１０』を『１７２．１６．１．１０』に変換する。そして、アドレス変換装置は、アドレス変換後のパケットをＶＰＮ終端装置に送出する。こうして、端末αから送出されたパケットは、端末βに到達する。
【０２９９】
［その他］
また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０３００】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０３０１】
なお、上記実施例で説明したトラヒック制御指示方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのＩＰネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＭＯ（Magneto-Optical disk）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【符号の説明】
【０３０２】
１００ 統合ＡＡＡ装置
１１０ 通信部
１１１ 入力部
１１２ 出力部
１１３ 入出力制御Ｉ／Ｆ部
１２０ 記憶部
１２１ 条件記憶部
１２２ 制御情報記憶部
１３０ 制御部
１３１ トラヒック監視部
１３２ トラヒック制御部

【特許請求の範囲】
【請求項１】
広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示装置であって、
前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視手段と、
前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御手段と
を備えたことを特徴とするトラヒック制御指示装置。
【請求項２】
前記監視手段は、取得した情報が前記条件に該当するか否かを判定することにより輻輳状態が生じたか否かを判定し、
前記制御手段は、輻輳状態が生じたと判定された場合に、前記複数の経路のうち優先度が低いトラヒック用の経路にてトラヒックを廃棄するように指示する指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信することを特徴とする請求項１に記載のトラヒック制御指示装置。
【請求項３】
前記監視手段は、前記転送制御装置から経路毎に取得した情報が前記条件に該当するか否かを判定することにより高負荷状態が生じたか否かを判定し、
前記制御手段は、高負荷状態が生じたと判定された場合に、高負荷状態が生じた経路上のトラヒックを他の経路に割り当てるように指示する指示情報を、少なくとも前記トラヒック制御装置に対して送信することを特徴とする請求項１に記載のトラヒック制御指示装置。
【請求項４】
前記監視手段は、取得した情報が前記条件に該当するか否かを判定することにより、前記拠点間接続システムにおいて制御対象となる新たなトラヒックが発生したことを判定し、
前記制御手段は、新たなトラヒックが発生したと判定された場合に、前記転送制御装置から経路毎に取得した情報を用いて経路間の負荷状態を比較して低負荷状態の経路を特定し、新たに発生した前記トラヒックを、前記低負荷状態の経路に割り当てるように指示する指示情報を、少なくとも前記トラヒック制御装置に対して送信することを特徴とする請求項１に記載のトラヒック制御指示装置。
【請求項５】
前記監視手段は、死活確認を経路毎に実行することで経路の異常を示す情報を取得し、取得した情報が予め定められた条件に該当することにより故障状態が生じたか否かを判定し、
前記制御手段は、故障状態が生じたと判定された場合に、故障状態が生じた経路上のトラヒックを予備用の経路に割り当てるように指示する指示情報を、少なくとも前記トラヒック制御装置に対して送信することを特徴とする請求項１に記載のトラヒック制御指示装置。
【請求項６】
前記転送制御装置には、前記拠点間接続に属する各拠点の端末に対してトラヒック種別毎にサービスを提供するサービス提供装置が接続され、該端末は、該転送制御装置によってパケット転送を制御されることで前記トラヒック種別毎の経路を用いて該サービス提供装置にアクセスするものであって、
前記サービス提供装置または該サービス提供装置を監視する監視システムを監視することにより、該サービス提供装置または該監視システムから前記サービス提供装置毎のリソース使用量を示す情報を取得し、取得した情報が予め定められた条件に該当することによりサービス提供装置において予め定められたリソース不足の状態が生じたか否かを判定するサービス監視手段をさらに備え、
前記制御手段は、予め定められたリソース不足の状態が生じたと判定された場合に、リソース不足の状態が生じたサービス提供装置を代替するサービス提供装置を探索し、リソース不足の状態が生じたサービス提供装置用の経路上のトラヒックを、代替のサービス提供装置用の経路に割り当てるように指示する指示情報を、少なくとも前記トラヒック制御装置に対して送信することを特徴とする請求項１に記載のトラヒック制御指示装置。
【請求項７】
前記拠点間接続はＶＰＮ間接続であることを特徴とする請求項１〜６のいずれか一つに記載のトラヒック制御指示装置。
【請求項８】
広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示方法であって、
コンピュータが、
前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視工程と、
前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御工程と
を含むことを特徴とするトラヒック制御指示方法。
【請求項９】
コンピュータを請求項１〜７のいずれか一つに記載のトラヒック制御指示装置として機能させることを特徴とするトラヒック制御指示プログラム。
【請求項１０】
広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示システムであって、
トラヒック制御指示装置は、
前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視手段と、
前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御手段とを備え、
前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置は、
前記トラヒック制御指示装置から要求された場合に、該トラヒック制御指示装置に対してトラヒックに関する情報を送信する送信手段と、
前記トラヒック制御指示装置から前記指示情報を受信した場合に、受信した該指示情報に従ってトラヒックを制御する制御手段と
を備えたことを特徴とするトラヒック制御指示システム。
【請求項１１】
広域ネットワークのパケット転送を制御する転送制御装置と、前記転送制御装置を経由した拠点間接続に属する各拠点を収容するとともに収容した拠点を終端する終端装置と、拠点側から送信されたパケットをトラヒック種別毎に分離し、前記転送制御装置との間にトラヒック種別毎に形成された複数の経路それぞれに送出するトラヒック制御装置とを含む拠点間接続システムのトラヒックを制御するトラヒック制御指示方法であって、
トラヒック制御指示装置としてのコンピュータが、
前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置を監視することにより、該装置から、トラヒックに関する情報、リソースに関する情報のうち、少なくとも一つを取得し、取得した情報が予め定められた条件に該当するか否かを判定する監視工程と、
前記情報が前記条件に該当すると判定された場合に、前記経路上のトラヒックを制御するための指示情報を、前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置に対して送信する制御工程とを含み、
前記転送制御装置、前記トラヒック制御装置のうち、少なくとも一つの装置としてのコンピュータが、
前記トラヒック制御指示装置から要求された場合に、該トラヒック制御指示装置に対してトラヒックに関する情報を送信する送信工程と、
前記トラヒック制御指示装置から前記指示情報を受信した場合に、受信した該指示情報に従ってトラヒックを制御する制御工程と
を含むことを特徴とするトラヒック制御指示方法。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６−１】

【図６−２】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【公開番号】特開２０１１−２２８８６４（Ｐ２０１１−２２８８６４Ａ）
【公開日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【出願番号】特願２０１０−９５４９３（Ｐ２０１０−９５４９３）
【出願日】平成２２年４月１６日（２０１０．４．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】