JP5111256B2 - 通信システムおよびサーバ装置 - Google Patents
通信システムおよびサーバ装置 Download PDFInfo
- Publication number
- JP5111256B2 JP5111256B2 JP2008162883A JP2008162883A JP5111256B2 JP 5111256 B2 JP5111256 B2 JP 5111256B2 JP 2008162883 A JP2008162883 A JP 2008162883A JP 2008162883 A JP2008162883 A JP 2008162883A JP 5111256 B2 JP5111256 B2 JP 5111256B2
- Authority
- JP
- Japan
- Prior art keywords
- setting information
- unit
- node device
- request
- control
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
Description
本発明は、通信システムおよびサーバ装置に係り、特に、通信事業者がサービス提供する仮想プライベートネットワークを構成するシステムにおいてネットワークリソースを制御する通信システムおよびサーバ装置に関する。
広域ＩＰ網を企業の通信インフラとして利用する仕組みとしては、広域イーサネット（登録商標）やＩＰ−ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）と呼ばれる通信事業者が提供するサービスがあった。これらのサービスでは、拠点の増減やＶＰＮ帯域の変更といったエンドユーザからのサービス要求は、書面やフォーム入力などを通じてサービス提供事業者に連絡を行い、要求を受け取ったサービス提供事業者は、網設備のリソース利用状況を考慮して受付の可否判断を行い、網設備に対する設定変更を行うという流れであった。
ＶＰＮを提供する事業者と、ＶＰＮを構築する広域ＩＰ網を提供する事業者とが異なる場合における、ユーザからのサービス変更の流れに関しては、例えば、特許文献１の図１で紹介されている。この場合のエンドユーザからのサービス要求は、ユーザ側のＶＰＮ管理者が仲介する形で広域ＩＰ網管理者に申し込みを行うという形態であった。特許文献１の技術では、サービス要求発生から実際にサービス変更が行われるまでのタイムラグを削減する仕組みとして、広域ＩＰ網ポリシーとＶＰＮポリシーを共に格納し、広域ＩＰ網に対するＶＰＮポリシーの検証や、ＶＰＮポリシーに対するサービス要求検証を行うＶＰＮポリシー管理装置が開示されている。
ＶＰＮを提供する事業者と、ＶＰＮを構築する広域ＩＰ網を提供する事業者とが異なる場合における、ユーザからのサービス変更の流れに関しては、例えば、特許文献１の図１で紹介されている。この場合のエンドユーザからのサービス要求は、ユーザ側のＶＰＮ管理者が仲介する形で広域ＩＰ網管理者に申し込みを行うという形態であった。特許文献１の技術では、サービス要求発生から実際にサービス変更が行われるまでのタイムラグを削減する仕組みとして、広域ＩＰ網ポリシーとＶＰＮポリシーを共に格納し、広域ＩＰ網に対するＶＰＮポリシーの検証や、ＶＰＮポリシーに対するサービス要求検証を行うＶＰＮポリシー管理装置が開示されている。
また、特許文献２では、広域ＩＰ網を跨るＶＰＮのリソース割当要求に対する応答時間を短縮する仕組みとして、ＩＰ−ＶＰＮ広域網のポリシーとして割り当てた通信機器のリソース情報を、ＶＰＮリソース情報としてＶＰＮポリシーサーバに設定するＩＰ−ＶＰＮポリシーサーバが開示されている。
一方、特許文献３では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合に、送信元ユーザノード別に帯域を確保しつつ、あるユーザノードから受信したデータ量に応じて、他のユーザノードからの出力速度を変更する方法が開示されている。
更に、特許文献４では、複数のユーザ要求受付部を設けることにより、ユーザ要求部の処理負荷を軽減して性能の低下を抑制し、受付制御機能全体の性能低下を回避する方法が開示されている。
一方、特許文献３では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合に、送信元ユーザノード別に帯域を確保しつつ、あるユーザノードから受信したデータ量に応じて、他のユーザノードからの出力速度を変更する方法が開示されている。
更に、特許文献４では、複数のユーザ要求受付部を設けることにより、ユーザ要求部の処理負荷を軽減して性能の低下を抑制し、受付制御機能全体の性能低下を回避する方法が開示されている。
本発明が解決しようとする課題のひとつは、広域ＩＰ網を企業の通信インフラとして利用できるようなサービスを提供する通信事業者のネットワークシステムにおいて、ユーザが自社設備の設定変更を行うのと同様の即応性で、利用サービスに関わる設定変更を行えるような設定インタフェースを提供することである。
特に、上記のような設定インタフェースをユーザに開放すると、複数のユーザが通信事業者網の設備に関わる設定変更を行う可能性がある。よって、複数の変更要求が発生した場合にも、ユーザの待ち時間を抑えつつ、それぞれの変更要求を反映させることによって、通信事業者網に矛盾や不整合が発生しないよう調整しながら網設備の設定変更を行う必要がある。
特許文献１や特許文献２では、上記のような複数のユーザが変更要求を発行する際の課題については触れられていない。
特許文献３では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合の帯域制御方法については述べられているが、新たに発生した複数の要求が、同一のユーザノードへのトラフィック集中となる場合の判定制御等については考慮されていない。
特に、上記のような設定インタフェースをユーザに開放すると、複数のユーザが通信事業者網の設備に関わる設定変更を行う可能性がある。よって、複数の変更要求が発生した場合にも、ユーザの待ち時間を抑えつつ、それぞれの変更要求を反映させることによって、通信事業者網に矛盾や不整合が発生しないよう調整しながら網設備の設定変更を行う必要がある。
特許文献１や特許文献２では、上記のような複数のユーザが変更要求を発行する際の課題については触れられていない。
特許文献３では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合の帯域制御方法については述べられているが、新たに発生した複数の要求が、同一のユーザノードへのトラフィック集中となる場合の判定制御等については考慮されていない。
特許文献４では、ユーザ要求受付部を複数設けることにより、ユーザ要求部の処理負荷を軽減する方法については述べられているが、複数のユーザ要求が影響する転送装置およびリンクが重複する場合については考慮されていない。ユーザ要求の範囲が複数の帯域管理部に跨る場合については記載されているが、要求順に一つずつ判定処理を行っていくという形を採る。そのため、ある帯域管理部への要求が複数発生した場合には、最後の要求を処理するまでに時間がかかり、即応性が失われる可能性がある。
本発明は、以上の点に鑑み、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することを目的とする。
本発明は、以上の点に鑑み、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することを目的とする。
本発明は、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報だけを参照するのでは無く、重複するユーザ要求を管理するキューに先に積まれた要求内容を加味して受付判定を行うことを特徴のひとつとする。
更に、本発明は、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダすることを特徴のひとつとする。
更に、本発明は、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダすることを特徴のひとつとする。
本発明の第１の解決手段によると、
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する端末と、
前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システムが提供される。
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する端末と、
前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システムが提供される。
本発明の第２の解決手段によると、
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置が提供される。
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置が提供される。
本発明によると、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することができる。
以下、図面を用いて本実施の形態を説明する。
図１は、本実施の形態の一例を示すネットワーク構成図である。
通信事業者は、複数の地域拠点に跨る同一企業の網（ユーザ網２）同士を繋ぐ通信インフラとして、広域ＩＰ網をサービス提供する。
各ユーザ網２と通信事業者がサービス提供するネットワークとは、アクセス網４を介して接続する。ユーザ網２側のアクセス網４との接続は、ユーザノード３を介して行われる。
通信事業者側のネットワークは、コア網８を、幾つかの分割した地域ごとに設置する地域網７同士を相互に接続することにより構成する。各地域網はコアノード６を備え、地域網７同士の間は、それぞれの地域網７を構成するコアノード６を相互に接続する。例えば、地域網７ａと地域網７ｂの間ならば、コアノード６ｃとコアノード６ｄを相互に接続する。地域網７とアクセス網４の間は、コアノード６とエッジノード５で相互に接続する。コアノードとエッジノードの関係は１対１とは限らず、１台のコアノード（例：６ａ）は、複数台のエッジノード（例：５ａ、５ｂ）と相互に接続してもよい。同様に、エッジノード（例：５ａ）もアクセス網４ａを介して、複数のユーザ拠点（例：３０、３１）を収容する。このような木構造でネットワークが構成されるため、上流の装置には自ずと複数のユーザ拠点からのトラヒックが集まる形となる。
図１は、本実施の形態の一例を示すネットワーク構成図である。
通信事業者は、複数の地域拠点に跨る同一企業の網（ユーザ網２）同士を繋ぐ通信インフラとして、広域ＩＰ網をサービス提供する。
各ユーザ網２と通信事業者がサービス提供するネットワークとは、アクセス網４を介して接続する。ユーザ網２側のアクセス網４との接続は、ユーザノード３を介して行われる。
通信事業者側のネットワークは、コア網８を、幾つかの分割した地域ごとに設置する地域網７同士を相互に接続することにより構成する。各地域網はコアノード６を備え、地域網７同士の間は、それぞれの地域網７を構成するコアノード６を相互に接続する。例えば、地域網７ａと地域網７ｂの間ならば、コアノード６ｃとコアノード６ｄを相互に接続する。地域網７とアクセス網４の間は、コアノード６とエッジノード５で相互に接続する。コアノードとエッジノードの関係は１対１とは限らず、１台のコアノード（例：６ａ）は、複数台のエッジノード（例：５ａ、５ｂ）と相互に接続してもよい。同様に、エッジノード（例：５ａ）もアクセス網４ａを介して、複数のユーザ拠点（例：３０、３１）を収容する。このような木構造でネットワークが構成されるため、上流の装置には自ずと複数のユーザ拠点からのトラヒックが集まる形となる。
本実施の形態では、上記のような、企業拠点間を接続する通信インフラを提供するサービスにおいて、企業ユーザが利用する通信回線に関わる設定を、ユーザが自由かつリアルタイムに変更できるようにする。特に、複数のユーザが同時に設定変更を行っても、通信事業者網に矛盾や不整合を起こさず、且つ、ユーザの待ち時間を抑えた設定変更を提供できるようにする。
このような設定変更機能を提供する際のネットワーク構成は、上記コア網８と管理用ネットワーク９を、それぞれコアノード６ｅとエッジノード５ｄで接続し、管理用ネットワーク９内にリソース制御受付装置（サーバ装置）１０を設ける。
ユーザ企業のネットワーク管理者は、本サービスを利用して設定変更を行う際には、自身のネットワーク（ユーザ網２）内の端末１から、リソース制御受付装置１０にリクエストを発行する。端末１は、例えば、拠点（ユーザネットワーク）間のＩＰ−ＶＰＮ（論理回線）の設定情報を入力する入力部と、設定情報をリソース制御受付装置１０に送信する送信部とを有する。
このような設定変更機能を提供する際のネットワーク構成は、上記コア網８と管理用ネットワーク９を、それぞれコアノード６ｅとエッジノード５ｄで接続し、管理用ネットワーク９内にリソース制御受付装置（サーバ装置）１０を設ける。
ユーザ企業のネットワーク管理者は、本サービスを利用して設定変更を行う際には、自身のネットワーク（ユーザ網２）内の端末１から、リソース制御受付装置１０にリクエストを発行する。端末１は、例えば、拠点（ユーザネットワーク）間のＩＰ−ＶＰＮ（論理回線）の設定情報を入力する入力部と、設定情報をリソース制御受付装置１０に送信する送信部とを有する。
この時の、ユーザ端末１とリソース制御受付装置１０の間の通信方式は、独自のクライアントアプリケーションと独自の通信方式で行っても構わないし、後に示す図９のようなブラウザ画面からの入力形式とＨＴＴＰ／ＨＴＴＰＳを用いた通信方式で実現しても構わない。図９に示すようなブラウザ画面からの入力形式を採る場合は、管理用ネットワーク９内にＷｅｂサーバも必要になるが、こちらは汎用的なＷｅｂサーバ／技術を活用すれば良いため、図１では省略している。なお、図９については、後ほど詳細を説明する。
話を戻して、複数のユーザが同時に設定変更を行った場合の課題について、図１を用いて補足説明する。複数のユーザによる設定変更が影響するポイントは、例えば、複数のユーザ拠点からのトラヒックが集まって相乗りする回線である。上記木構造のネットワークの末端では、装置上は複数ユーザのトラヒックが集線されるかもしれないが、ポート／論理インタフェースはユーザ個別となるため、トラヒックの相乗りという状況は発生しない。しかし、上流のコアノードでは、全ユーザの個別トラヒックを対象に資源を割り当てることは不可能であるため、必然的に同一回線にトラヒックが相乗りする形となる。一般的に上流のネットワークになる程、回線帯域は太くなるよう構築するが、全ての回線が均一では無い。例えば、地域網１（７ａ）と地域網２（７ｂ）の間、コアノード６ｃとコアノード６ｄの間など、他のコア網／地域網内の回線より細くなる場合がある。このような回線では、あるユーザが行う設定変更が、他のユーザのトラヒックに影響を与えることになる。
話を戻して、複数のユーザが同時に設定変更を行った場合の課題について、図１を用いて補足説明する。複数のユーザによる設定変更が影響するポイントは、例えば、複数のユーザ拠点からのトラヒックが集まって相乗りする回線である。上記木構造のネットワークの末端では、装置上は複数ユーザのトラヒックが集線されるかもしれないが、ポート／論理インタフェースはユーザ個別となるため、トラヒックの相乗りという状況は発生しない。しかし、上流のコアノードでは、全ユーザの個別トラヒックを対象に資源を割り当てることは不可能であるため、必然的に同一回線にトラヒックが相乗りする形となる。一般的に上流のネットワークになる程、回線帯域は太くなるよう構築するが、全ての回線が均一では無い。例えば、地域網１（７ａ）と地域網２（７ｂ）の間、コアノード６ｃとコアノード６ｄの間など、他のコア網／地域網内の回線より細くなる場合がある。このような回線では、あるユーザが行う設定変更が、他のユーザのトラヒックに影響を与えることになる。
一例として、図１の拠点３０、３１、３２が、同一企業の拠点と仮定する。各拠点はユーザＮＷがはられている。このユーザ企業のネットワーク管理者が、当初、拠点３０と３１の間で開設していたＶＰＮ回線を、拠点３０と３２の間に変更した場合など、本設定変更により、地域網１（７ａ）と地域網２（７ｂ）を繋ぐ回線には、新たなトラヒックがかかることになる。
上記のようなポイントに関しては、設定要求の受付可否を判定する必要があるが、同様の設定変更を複数のユーザが同時に行う可能性もある。その際に、リクエストの到着順にシーケンシャルに処理を行うというアプローチもあるが、後にまわされたユーザは待ち時間に対して不満を抱くかもしれない。シーケンシャルに処理を行うアプローチの課題に関しては、図２を用いて説明する。
上記のようなポイントに関しては、設定要求の受付可否を判定する必要があるが、同様の設定変更を複数のユーザが同時に行う可能性もある。その際に、リクエストの到着順にシーケンシャルに処理を行うというアプローチもあるが、後にまわされたユーザは待ち時間に対して不満を抱くかもしれない。シーケンシャルに処理を行うアプローチの課題に関しては、図２を用いて説明する。
図２は、複数の要求をシーケンシャルに処理する場合の課題を説明する為のシーケンス図である。
図中表記のユーザ端末は、本サービスを利用する企業のネットワーク管理者により操作されるユーザ網内の端末を指し、サービスに関わる変更要求を発行する。最初は、変更内容を入力するためのシステムへのログインである（Ｓ１）。図では省略しているが、このステップで認証確認などを行う。
ユーザからの要求は、リソース制御受付装置１０で処理する。システムにユーザがログインする際には、ユーザ入力画面を生成して提示する（Ｓ２）。
図９は、提示されるユーザ入力画面の例である。
契約情報である拠点や契約帯域の情報は、例えば、拠点ごとに提示する（９０、９１）。また、ユーザ設定済みの情報に関しても、例えば、拠点単位に分類して提示する（９２、９３、９４）。
図１６は、契約情報テーブルの構成図である。図１７は、設定情報テーブルの構成図である。契約情報や設定情報は、例えば、それぞれ契約情報テーブルを管理するデータベース（契約情報ＤＢ、図１６）、設定情報テーブルを管理するデータベース（設定情報ＤＢ、図１７）から取得することができる。契約情報テーブルは、例えば、ユーザ識別子と拠点識別子と契約帯域とが対応して記憶される。設定情報テーブルは、ユーザ識別子と拠点識別子とＶＰＮ−ＩＤと帯域情報と優先度情報とが対応して記憶される。各テーブルから情報が読みだされて、図９のユーザ入力画面の生成に利用される。
また、後述する図３でリソース制御受付装置１０の機能ブロック図を示しているが、ここまでの手順は汎用的な技術を活用すれば良いため、機能ブロック図では省略している。契約情報ＤＢ、設定情報ＤＢは共にリソース制御受付装置１０とは異なる装置に実装しても構わない。その場合は、リソース制御受付装置１０と同様、管理用ネットワーク９内に設置する。
図中表記のユーザ端末は、本サービスを利用する企業のネットワーク管理者により操作されるユーザ網内の端末を指し、サービスに関わる変更要求を発行する。最初は、変更内容を入力するためのシステムへのログインである（Ｓ１）。図では省略しているが、このステップで認証確認などを行う。
ユーザからの要求は、リソース制御受付装置１０で処理する。システムにユーザがログインする際には、ユーザ入力画面を生成して提示する（Ｓ２）。
図９は、提示されるユーザ入力画面の例である。
契約情報である拠点や契約帯域の情報は、例えば、拠点ごとに提示する（９０、９１）。また、ユーザ設定済みの情報に関しても、例えば、拠点単位に分類して提示する（９２、９３、９４）。
図１６は、契約情報テーブルの構成図である。図１７は、設定情報テーブルの構成図である。契約情報や設定情報は、例えば、それぞれ契約情報テーブルを管理するデータベース（契約情報ＤＢ、図１６）、設定情報テーブルを管理するデータベース（設定情報ＤＢ、図１７）から取得することができる。契約情報テーブルは、例えば、ユーザ識別子と拠点識別子と契約帯域とが対応して記憶される。設定情報テーブルは、ユーザ識別子と拠点識別子とＶＰＮ−ＩＤと帯域情報と優先度情報とが対応して記憶される。各テーブルから情報が読みだされて、図９のユーザ入力画面の生成に利用される。
また、後述する図３でリソース制御受付装置１０の機能ブロック図を示しているが、ここまでの手順は汎用的な技術を活用すれば良いため、機能ブロック図では省略している。契約情報ＤＢ、設定情報ＤＢは共にリソース制御受付装置１０とは異なる装置に実装しても構わない。その場合は、リソース制御受付装置１０と同様、管理用ネットワーク９内に設置する。
既存の設定の変更は、変更前の情報を参照しながら、変更後の情報を入力したり（９７）選択したり（９８）する。既存の設定自体を消去する場合は、該当する設定に付随する削除ボタン９６を利用し、新たに設定を追加する場合は、追加ボタン９５を利用する。追加ボタンを押下した場合には、ダイアログボックスなどで追加するＶＬＡＮ−ＩＤの入力を促した後で、９２に例示したような入力画面を生成して提示する。但し、追加時には変更前の設定情報は無い。追加や変更で入力した帯域情報の合計値が、拠点の合計帯域（契約帯域）を超過した場合は、入力時にユーザに警告を発する。すなわち、更新ボタンを押下しても、変更要求がリソース制御サーバ１０には飛ばないように制御し、入力内容のエラー通知を行う。
以上、図９では、拠点ごとの設定情報を纏めたイメージのユーザ入力画面例を提示したが、ＶＬＡＮ−ＩＤ単位にソーティングした設定情報を提示する形式でも構わない。また、図９のようなＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）ベースのユーザ入力方法ではなく、ＣＵＩ（Ｃｏｍｍａｎｄ−ｌｉｎｅ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）ベースのユーザ入力方法を提供し、ユーザノード３に対する設定変更と同じ様な操作性を提供する形態でも構わない。
再び図２の説明に戻ると、図９のような画面を利用して、ユーザ端末は設定変更する情報を例えばキーボードやマウス等の入力部から入力して、更新ボタンが押下されることにより要求を発行する（Ｓ３）。設定変更要求Ｓ３を受け取ったリソース制御受付装置は、設定変更要求の受付可否判定を行う（Ｓ４）。受付られない場合はその旨を返信し、受付可能な場合は、該当するノード装置に対して設定変更要求を発行する（Ｓ５）。設定変更要求Ｓ５を受け取ったノード装置は、変更の可否判定を行い（Ｓ６）、設定の変更を実施する（Ｓ７）。要求に対するノード装置からの応答を受け取ったリソース制御受付装置は、ユーザ端末に結果を通知して（Ｓ８）、次の要求処理に移る（Ｓ９）。
再び図２の説明に戻ると、図９のような画面を利用して、ユーザ端末は設定変更する情報を例えばキーボードやマウス等の入力部から入力して、更新ボタンが押下されることにより要求を発行する（Ｓ３）。設定変更要求Ｓ３を受け取ったリソース制御受付装置は、設定変更要求の受付可否判定を行う（Ｓ４）。受付られない場合はその旨を返信し、受付可能な場合は、該当するノード装置に対して設定変更要求を発行する（Ｓ５）。設定変更要求Ｓ５を受け取ったノード装置は、変更の可否判定を行い（Ｓ６）、設定の変更を実施する（Ｓ７）。要求に対するノード装置からの応答を受け取ったリソース制御受付装置は、ユーザ端末に結果を通知して（Ｓ８）、次の要求処理に移る（Ｓ９）。
設定変更要求に対する処理を上記のように行う場合、あるユーザからの要求Ｓ３を受け取った直後に、ほぼ同時期に発行された別のユーザからの要求を受け取っても、処理キューの順番で後ろに積まれた要求は、先に積まれた要求を処理し終わるまで扱われない。上記の例で言い換えるなら、Ｓ３からＳ８までの間が待ち時間となってしまう。変更要求の受付判定処理と、ノード装置に対する設定変更処理を独立に動作させることで、先に積まれた要求の受付判定処理が終わったら、速やかに次に積まれた要求の受付判定を行うことは可能になる。しかしながら、最終的に設定が反映されて利用可能となるのは、ノード装置に対する設定変更が完了した後になるため、受付判定結果が判るまでの時間は短縮されるかもしれないが、設定が反映されて利用可能となるまでの時間は改善されないという課題が残る。
本実施の形態では、このように複数の要求が集中した場合にも、ユーザに対する待ち時間を抑えたリソース制御処理を実現する。本実施の形態では、ネットワークリソース制御システム等が、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行い、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行い、ユーザ要求に対する判定の待ち時間を短くする。また、本実施の形態では、ネットワーク制御システムが、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダし、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減する。
本実施の形態では、このように複数の要求が集中した場合にも、ユーザに対する待ち時間を抑えたリソース制御処理を実現する。本実施の形態では、ネットワークリソース制御システム等が、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行い、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行い、ユーザ要求に対する判定の待ち時間を短くする。また、本実施の形態では、ネットワーク制御システムが、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダし、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減する。
図１８は、本実施の形態のリソース制御受付装置１０の構成図である。
本実施の形態のリソース制御受付装置１０は、プロセッサ３０１、メモリ３０２、記憶装置３０３及びネットワークインタフェース（３０４および３０５）を備える。例えば、汎用的なサーバ装置に、リソース制御受付プログラム３０９を搭載する。リソース制御受付プログラム３０９は、記憶装置３０４に格納され、プログラム実行時にメモリ３０２上にロードされて、プロセッサ３０１により動かされる。
経路情報管理部１７は、一般的なネットワーク管理システムが管理するものと同様であり、各ノード装置に設定されている経路情報を集約したものである。図１８に示したように、経路情報管理部１７は、ＣＰＵ３１１、メモリ３１２、記憶装置３１３、ネットワークインタフェース３１４を備えた汎用的なデータベース装置３１０で管理されるテーブル情報である。
本実施の形態のリソース制御受付装置１０は、プロセッサ３０１、メモリ３０２、記憶装置３０３及びネットワークインタフェース（３０４および３０５）を備える。例えば、汎用的なサーバ装置に、リソース制御受付プログラム３０９を搭載する。リソース制御受付プログラム３０９は、記憶装置３０４に格納され、プログラム実行時にメモリ３０２上にロードされて、プロセッサ３０１により動かされる。
経路情報管理部１７は、一般的なネットワーク管理システムが管理するものと同様であり、各ノード装置に設定されている経路情報を集約したものである。図１８に示したように、経路情報管理部１７は、ＣＰＵ３１１、メモリ３１２、記憶装置３１３、ネットワークインタフェース３１４を備えた汎用的なデータベース装置３１０で管理されるテーブル情報である。
図１５に、経路情報管理テーブルの一構成例を示す。
経路情報管理テーブルは、ＶＰＮ−ＩＤ１５０と、送信元１５２および送信先１５４と、経路情報１５６とが記憶される。経路情報１５６は、例えば、ＶＰＮ−ＩＤ１５０で特定される経路、または、送信元１５２及び１５４で特定される経路にあるノード装置の識別子、インタフェースの識別子が記憶される。
一方、対象リスト管理部１８は、ユーザの設定変更が他のユーザのトラヒックにも影響を与えるポイント（回線）を含むノード装置およびインタフェースを登録管理する。図１８に示したように、対象リスト管理部１８は、ＣＰＵ３２１、メモリ３２２、記憶装置３２３、ネットワークインタフェース３２４を備えた汎用的なデータベース装置３２０で管理されるテーブル情報である。こちらは、図１の説明の中で例示したような、回線帯域が細くなるポイント（図１では、６ｃと６ｄの間を例に説明）のノード装置（例えば、６ｃや６ｄ）および対象インタフェースを、当該ネットワークの管理者（通信事業者網の管理者）が事前に登録しておく（図１３）。
リソース管理部１９の構成は従来のネットワーク管理システムやノード管理システムで用いられているものと同様で構わない。リソース管理部１９は、図１８に示したように、ＣＰＵ３３１、メモリ３３２、記憶装置３３３、ネットワークインタフェース３３４を備えた汎用的なデータベース装置３３０で管理されるテーブル情報である。限界値の設定としては、物理回線の帯域と等しい値による運用でも構わないし、システムのコンフィグレーションで設定する許容幅の値を、物理回線の帯域に上乗せする運用でも構わない（図１４）。
経路情報管理テーブルは、ＶＰＮ−ＩＤ１５０と、送信元１５２および送信先１５４と、経路情報１５６とが記憶される。経路情報１５６は、例えば、ＶＰＮ−ＩＤ１５０で特定される経路、または、送信元１５２及び１５４で特定される経路にあるノード装置の識別子、インタフェースの識別子が記憶される。
一方、対象リスト管理部１８は、ユーザの設定変更が他のユーザのトラヒックにも影響を与えるポイント（回線）を含むノード装置およびインタフェースを登録管理する。図１８に示したように、対象リスト管理部１８は、ＣＰＵ３２１、メモリ３２２、記憶装置３２３、ネットワークインタフェース３２４を備えた汎用的なデータベース装置３２０で管理されるテーブル情報である。こちらは、図１の説明の中で例示したような、回線帯域が細くなるポイント（図１では、６ｃと６ｄの間を例に説明）のノード装置（例えば、６ｃや６ｄ）および対象インタフェースを、当該ネットワークの管理者（通信事業者網の管理者）が事前に登録しておく（図１３）。
リソース管理部１９の構成は従来のネットワーク管理システムやノード管理システムで用いられているものと同様で構わない。リソース管理部１９は、図１８に示したように、ＣＰＵ３３１、メモリ３３２、記憶装置３３３、ネットワークインタフェース３３４を備えた汎用的なデータベース装置３３０で管理されるテーブル情報である。限界値の設定としては、物理回線の帯域と等しい値による運用でも構わないし、システムのコンフィグレーションで設定する許容幅の値を、物理回線の帯域に上乗せする運用でも構わない（図１４）。
図１４に、リソース管理テーブルの一構成例を示す。リソース管理テーブルは、ノード識別子１４０と、インタフェース識別子１４２と、上限帯域１４４と、予約済帯域１４６とが対応して記憶される。
ちなみに図１８では、経路情報管理部１７を格納するデータベース装置３１０、対象リスト管理部１８を格納するデータベース装置３２０、リソース管理部１９を格納するデータベース装置３３０を、それぞれ別装置で構成するイメージで示したが、これらの情報は同一のデータベース装置で管理する構成であっても構わない。
図３は、リソース制御受付プログラム３０９の機能ブロック図である。
リソース制御受付プログラム３０９は、例えば、要求受付部１１と、判定制御部１５と、制御実行部１６とを有する。判定制御部１５は、制御要求分類部２０と、制御要求管理部２１と、受付判定部２２と、制御発行部２３とを有する。
図３では、設定変更要求（Ｓ３）を受け取った後の処理に関わる機能ブロックのみを記載している。
ちなみに図１８では、経路情報管理部１７を格納するデータベース装置３１０、対象リスト管理部１８を格納するデータベース装置３２０、リソース管理部１９を格納するデータベース装置３３０を、それぞれ別装置で構成するイメージで示したが、これらの情報は同一のデータベース装置で管理する構成であっても構わない。
図３は、リソース制御受付プログラム３０９の機能ブロック図である。
リソース制御受付プログラム３０９は、例えば、要求受付部１１と、判定制御部１５と、制御実行部１６とを有する。判定制御部１５は、制御要求分類部２０と、制御要求管理部２１と、受付判定部２２と、制御発行部２３とを有する。
図３では、設定変更要求（Ｓ３）を受け取った後の処理に関わる機能ブロックのみを記載している。
リソース制御受付装置１０では、ユーザ端末（ユーザ網２内の端末）１からの変更要求（ユーザ要求、設定変更要求、設定情報）を、要求受付部１１で受信する。ここで受信する一要求には、図９のようなユーザ設定画面を通じて入力される内容一式が含まれる。つまり、変更内容が複数の拠点、複数の設定（例えば、９２の設定と９３の設定と９４の設定）に及ぶ場合には、一要求メッセージの中に複数の設定変更項目が含まれることになる。逆に、変更内容が単一拠点の単一設定であるならば、一要求メッセージに含まれる設定変更項目も一つになる。
制御要求分類部２０では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとの要求として分類を行う。分類結果は、制御が完了するまで制御要求管理部２１に一次的に記録する。
図４に、制御要求管理部２１のテーブル構成例を示す。
変更内容４１は、対象ノードおよび対象インタフェース（４０）毎に分類する。この時、対象ノードおよび対象インタフェースは、経路情報管理部１７と対象リスト管理部１８を参照して特定する。
制御要求分類部２０では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとの要求として分類を行う。分類結果は、制御が完了するまで制御要求管理部２１に一次的に記録する。
図４に、制御要求管理部２１のテーブル構成例を示す。
変更内容４１は、対象ノードおよび対象インタフェース（４０）毎に分類する。この時、対象ノードおよび対象インタフェースは、経路情報管理部１７と対象リスト管理部１８を参照して特定する。
制御要求分類部２０が行う処理手順としては、変更内容に含まれるフロー識別情報（例えば、ＶＰＮ−ＩＤや、送信元アドレスと送信先アドレスなど）を検索キーとして経路情報管理部１７を調べ、対象経路上のノード装置やインタフェースを抽出する（図１０、ステップ１０１）。次に、抽出したノード装置やインタフェースが、対象リスト管理部１８に登録されているか確認する（図１０、ステップ１０２）。対象リスト管理部１８の情報と照合した結果、合致した場合は、これを合致したノード装置・インタフェースに関する変更内容として、制御要求管理部２１に登録する（図１０、ステップ１０３）。対象経路に含まれるエッジノード５に関しては、通信事業者網の境界点にあたる装置として、設定変更の直接の対象となるため、全て制御要求管理部２１に抽出する。エッジノードに関する装置およびインタフェースの情報も、対象リスト管理部１８に登録しておくと、上記手順の流れで制御要求を管理部２１に分類することができる。
引き続き、図４に示した残りの要素について説明する。差分欄（ｄｉｆｆ）４２は、要求帯域に変更がある場合の、変更前帯域と変更後帯域の差分を登録する欄である。後の受付判定部２２の処理を行う際に算出する形でも構わないが、変更内容欄４１に情報を登録する流れで、制御要求分類部２０の処理として行った方がデータの読み出しなどに無駄が無い。
引き続き、図４に示した残りの要素について説明する。差分欄（ｄｉｆｆ）４２は、要求帯域に変更がある場合の、変更前帯域と変更後帯域の差分を登録する欄である。後の受付判定部２２の処理を行う際に算出する形でも構わないが、変更内容欄４１に情報を登録する流れで、制御要求分類部２０の処理として行った方がデータの読み出しなどに無駄が無い。
要求ＩＤ欄（Ｒｅｑ−Ｉｄ）４３は、各変更要求に対して本システムが一意に設定する識別子である。制御要求管理部２１に登録する際に、他の変更要求と重複が無いように設定する。但し、同一の変更要求から派生した変更要求で、対象ノードおよびインタフェースが異なるものに対しては、同じ要求ＩＤを付与する。
状態欄（Ｓｔａｔｕｓ）４４は、変更要求の処理状況を管理する欄である。制御要求分類部２０で各変更要求を対象ノード、対象インタフェース毎に分離し、制御要求管理部２１に登録した際には、「未」の状態となる。以降、受付判定部２２で変更要求の受付判定を行った結果、受付が可能な場合は「ＯＫ」に、受付が出来ない場合は「ＮＧ」に登録内容を変更する。同一の要求ＩＤに対する受付判定結果が全て「ＯＫ」となった場合は、制御発行部２３でノード装置に対する設定変更を実施した後に、制御要求管理テーブルから削除する。一方、一つでも「ＮＧ」となった要求ＩＤの変更要求に関しては、要求内容では受け付けることが出来ないため、その旨を、要求受付部１１を介してユーザに返信する。
図４の説明の中で部分的に説明を行ったが、再び図３に戻って説明を続ける。制御要求分類部２０で制御要求管理部２１に分類登録を行った後は、受付判定部２２において制御要求管理部２１に新たに登録された制御要求の受付判定を行う。この時に対象となるのは、図４に示した制御要求管理テーブルの項目で状態欄４４が「未」のものである。
状態欄（Ｓｔａｔｕｓ）４４は、変更要求の処理状況を管理する欄である。制御要求分類部２０で各変更要求を対象ノード、対象インタフェース毎に分離し、制御要求管理部２１に登録した際には、「未」の状態となる。以降、受付判定部２２で変更要求の受付判定を行った結果、受付が可能な場合は「ＯＫ」に、受付が出来ない場合は「ＮＧ」に登録内容を変更する。同一の要求ＩＤに対する受付判定結果が全て「ＯＫ」となった場合は、制御発行部２３でノード装置に対する設定変更を実施した後に、制御要求管理テーブルから削除する。一方、一つでも「ＮＧ」となった要求ＩＤの変更要求に関しては、要求内容では受け付けることが出来ないため、その旨を、要求受付部１１を介してユーザに返信する。
図４の説明の中で部分的に説明を行ったが、再び図３に戻って説明を続ける。制御要求分類部２０で制御要求管理部２１に分類登録を行った後は、受付判定部２２において制御要求管理部２１に新たに登録された制御要求の受付判定を行う。この時に対象となるのは、図４に示した制御要求管理テーブルの項目で状態欄４４が「未」のものである。
本システムの特徴的な判定手順としては、各制御要求を単独で判定するのでは無く、同一の対象ノード、同一の対象インタフェースに対する制御要求を纏めて判定する。例えば、図４では判定結果が出た状態を示しているが、エントリ＃１と＃２や＃１０と＃１１のように、同一の対象ノード、同一の対象インタフェースに対する制御要求の処理状態が「未」であったなら、＃１と＃２、＃１０と＃１１はそれぞれ纏めて判定を行う。具体的には、同一対象への複数の制御要求を全て適用できるか否かといった判定を行う。＃１と＃２の場合ならば、それぞれの変更要求は７Ｍの帯域増加と２Ｍの帯域減少であるが、制御対象への影響としては５Ｍの帯域増加となるので、経路上の制御対象ノード、インタフェースにおいて５Ｍの帯域増加が可能かという観点で判定を行う。＃１０と＃１１の場合も同様に、制御対象において１５Ｍの帯域増加が可能かという観点で判定を行う。纏めた要求内容が受け入れられない場合もありうるが、その際には、後に積まれた要求から順に削って再度判定を行うという方法を用いることができる。また、検索処理で良く用いられる２分岐探索のように、要求数の半分の内容で一次判定を行い、判定結果が可ならば残る要求数の更に半分の内容を上積みして判定を行い、判定結果が不可ならば更に半分の要求数の内容で判定を行うといった判定を繰り返すことにより、許容される境界点を導き出すという方法を用いることができる。図４の＃１０と＃１１では、＃１０の要求までは受け入れられたが、＃１１の要求は受け入れられなかったケースを例示している。判定結果が不可となった要求に関しては結果を端末１に通知する。また、判定結果が可となった要求に関しても同様に、受付判定結果が出た時点の結果を通知するようにしても構わない。
上記のような判定を行う際の、制御対象における既存のリソース使用状況や限界値の情報は、リソース管理部１９から取得する。
上記のような判定を行う際の、制御対象における既存のリソース使用状況や限界値の情報は、リソース管理部１９から取得する。
以上のような手順を経て判定結果が出たら、次は制御発行部２３の処理を行う。制御発行部２３では制御対象への要求を生成し、制御実行部１６を通じて制御を実施する。対象となるのは、受付判定の結果が「ＯＫ」となった制御要求だが、ここでも要求ごとに制御を行うのではなく、制御対象ごとに纏めた要求内容で制御を実施する。例えば、図４の＃１と＃２のような同一のノードに対する要求は、設定変更メッセージ（制御要求）を一つに纏めて制御を実行する。制御内容としては、例えば、ＶＰＮ／ラベル／フロー単位でのシェイピング設定などを行う。制御要求のインタフェース仕様はノード装置が備えるインタフェースに依存するが、ｔｅｌｎｅｔなどで対象ノードにログインして制御コマンドを発行するという方法でも構わないし、ＩＥＴＦ（ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で策定されたＮＥＴＣＯＮＦ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＦＣ４７４１）を用いても構わない。この時に、同一ノード／同一インタフェースに対する複数の制御要求を、ノード装置に対して１制御コマンド／１制御メッセージで行えるか否かは、対象ノードが備えるインタフェース仕様に依存する。なお、上記「制御対象ごとに纏めた要求内容で制御を実施する」のは、リソース制御受付装置１０の制御発行部２３の処理である。
最後に、対象となるノード装置への制御が完了したら、結果をリソース制御部１９に反映すると共にユーザ端末に対しても通知を行う。
ここまでが、図３に示したリソース制御受付装置１０の一連の処理の流れになる。図３では、制御要求分類部２０、受付判定部２２、制御発行部２３が、全て一台の装置上に実装された形態を示したが、要求受付部１１と制御要求分類部２０を実装する装置、受付判定部２２を実装する装置、制御発行部２３と制御実行部１６を実装する装置を分けて、それぞれの装置が、制御要求管理部２１を実装した装置と通信を行いながら動作するシステムの形態を採っても構わない。
また、図４は帯域幅の設定変更に伴う制御要求管理に焦点を当てたテーブル構成例であるが、優先度の設定変更に伴う、優先度毎の帯域割当の変動を検査する必要がある場合は、対象ノードおよびインタフェースに加えて優先度を分類項目に加える。つまり、図４の項目４０に優先度という条件を加えて分類整理する。同様に、図１４に示したリソース管理テーブルも、優先度という条件を加えて分類整理する形となる（例えば、１４２と１４４の間に列を追加して分類する）。
ここまでが、図３に示したリソース制御受付装置１０の一連の処理の流れになる。図３では、制御要求分類部２０、受付判定部２２、制御発行部２３が、全て一台の装置上に実装された形態を示したが、要求受付部１１と制御要求分類部２０を実装する装置、受付判定部２２を実装する装置、制御発行部２３と制御実行部１６を実装する装置を分けて、それぞれの装置が、制御要求管理部２１を実装した装置と通信を行いながら動作するシステムの形態を採っても構わない。
また、図４は帯域幅の設定変更に伴う制御要求管理に焦点を当てたテーブル構成例であるが、優先度の設定変更に伴う、優先度毎の帯域割当の変動を検査する必要がある場合は、対象ノードおよびインタフェースに加えて優先度を分類項目に加える。つまり、図４の項目４０に優先度という条件を加えて分類整理する。同様に、図１４に示したリソース管理テーブルも、優先度という条件を加えて分類整理する形となる（例えば、１４２と１４４の間に列を追加して分類する）。
次に、図３で説明したリソース制御受付装置１０の処理手順を、フローチャートを用いてさらに説明する。
図５は、ユーザ要求受信時のリソース制御受付装置の処理手順を示すフローチャートである。
全体的な流れとしては、既に図３で説明したように、ユーザ要求を要求受付部１１で受け取る要求受付処理５０を行い、次に、判定制御部１５で行う判定制御処理５２を行う。判定制御処理５２については、後に図６を用いて詳細に説明する。判定制御処理５２を行ったら、制御実行部１６でノード装置に対する制御５４を実行する。
図６は、判定制御部１５の判定制御処理を示すフローチャートである。
要求分類処理６１は制御要求分類部２０の処理に相当し、受付判定処理６３は受付判定部２２の処理に相当する。また、制御発行処理６５は制御発行部２３の処理に相当する。基本的な流れは、図３で説明したように、要求分類処理６１、受付判定処理６３、制御発行処理６５を順に行っていく形でだが、ここでは処理間の遷移のタイミングを中心に掘り下げて説明する。いずれの処理も、未処理の内容は全て処理した上で、次の処理に遷移させる。要求分類処理６１であれば、未処理の要求が無くなるまで処理を行い、未処理の要求が無くなった時点で、次の受付判定処理に遷移する（ステップ６０）。受付判定処理６３では、未判定の処理が無ければ次の制御発行処理に遷移するが、未判定の処理があれば（ステップ６２）、これら全ての受付判定処理を行う（ステップ６３）。同様に、制御発行処理６５では、未制御の処理が無ければ再び要求分類処理に遷移するが、未制御の処理があれば（ステップ６４）、これら全ての制御発行処理を行う（ステップ６５）。
未処理キューの実現方式としては、図７のような方式と、図８のような方式が考えられるが、次に図６の流れを、各処理キューの構成に従って説明する。
図５は、ユーザ要求受信時のリソース制御受付装置の処理手順を示すフローチャートである。
全体的な流れとしては、既に図３で説明したように、ユーザ要求を要求受付部１１で受け取る要求受付処理５０を行い、次に、判定制御部１５で行う判定制御処理５２を行う。判定制御処理５２については、後に図６を用いて詳細に説明する。判定制御処理５２を行ったら、制御実行部１６でノード装置に対する制御５４を実行する。
図６は、判定制御部１５の判定制御処理を示すフローチャートである。
要求分類処理６１は制御要求分類部２０の処理に相当し、受付判定処理６３は受付判定部２２の処理に相当する。また、制御発行処理６５は制御発行部２３の処理に相当する。基本的な流れは、図３で説明したように、要求分類処理６１、受付判定処理６３、制御発行処理６５を順に行っていく形でだが、ここでは処理間の遷移のタイミングを中心に掘り下げて説明する。いずれの処理も、未処理の内容は全て処理した上で、次の処理に遷移させる。要求分類処理６１であれば、未処理の要求が無くなるまで処理を行い、未処理の要求が無くなった時点で、次の受付判定処理に遷移する（ステップ６０）。受付判定処理６３では、未判定の処理が無ければ次の制御発行処理に遷移するが、未判定の処理があれば（ステップ６２）、これら全ての受付判定処理を行う（ステップ６３）。同様に、制御発行処理６５では、未制御の処理が無ければ再び要求分類処理に遷移するが、未制御の処理があれば（ステップ６４）、これら全ての制御発行処理を行う（ステップ６５）。
未処理キューの実現方式としては、図７のような方式と、図８のような方式が考えられるが、次に図６の流れを、各処理キューの構成に従って説明する。
先ずは、図７のような処理キューの構成を採る場合について説明する。
このモデルは処理に依存しない統一キューを設ける方式で、各処理は発生した時点で当該キューに積まれる。図７に示す例のような形で各処理が積まれている場合、７２の処理Ａ６が終わるまでは、ステップ６０の未処理の要求確認で「有」と判定されるため、繰り返し要求分類処理６１が行われる。要求の分類が終わると、各処理Ａ４〜Ａ６は新たな受付判定待ち処理Ｂ４〜Ｂ６となるが、これらは７６の後ろに順次積む形となる。７３の処理Ｂ２に順番がまわってくると、ステップ６０の未処理の要求確認には該当せず「無」と判定され、ステップ６２の未処理の判定確認で「有」と判定されるため、受付判定処理６３が行われる。７４の処理Ｂ３が終わるまでは、ステップ６２の未処理の判定確認で「有」と判定されるため、繰り返し受付判定処理６３が行われる。次の７５の処理Ａ７は、ステップ６４の未処理の制御確認には該当しないため、再びステップ６０に戻って、ステップ６１の要求分類処理を行う。次の７６の処理Ｃ１は、ステップ６０にもステップ６２にも該当しないため、ステップ６４に遷移してステップ６５の制御発行処理を行うという流れになる。なお、受付判定処理、制御発行処理は、例えば、Ｂ２、Ｂ３を繰り返し処理する以外にもまとめて処理することができる。
このモデルは処理に依存しない統一キューを設ける方式で、各処理は発生した時点で当該キューに積まれる。図７に示す例のような形で各処理が積まれている場合、７２の処理Ａ６が終わるまでは、ステップ６０の未処理の要求確認で「有」と判定されるため、繰り返し要求分類処理６１が行われる。要求の分類が終わると、各処理Ａ４〜Ａ６は新たな受付判定待ち処理Ｂ４〜Ｂ６となるが、これらは７６の後ろに順次積む形となる。７３の処理Ｂ２に順番がまわってくると、ステップ６０の未処理の要求確認には該当せず「無」と判定され、ステップ６２の未処理の判定確認で「有」と判定されるため、受付判定処理６３が行われる。７４の処理Ｂ３が終わるまでは、ステップ６２の未処理の判定確認で「有」と判定されるため、繰り返し受付判定処理６３が行われる。次の７５の処理Ａ７は、ステップ６４の未処理の制御確認には該当しないため、再びステップ６０に戻って、ステップ６１の要求分類処理を行う。次の７６の処理Ｃ１は、ステップ６０にもステップ６２にも該当しないため、ステップ６４に遷移してステップ６５の制御発行処理を行うという流れになる。なお、受付判定処理、制御発行処理は、例えば、Ｂ２、Ｂ３を繰り返し処理する以外にもまとめて処理することができる。
以上のように、図７のモデルでは、統一キューに積まれた順に処理が行われ、同一処理が連続する間はその処理を続ける。このように処理することで、例えば７１から７２の処理などは、要求分類処理が終わった後は要求判定待ち状態となり、再び統一キューに同じように積まれるため、同時期に連続して発生した要求は、ほぼ同じ周期に処理が進められるようになる。ちなみに、キューに積まれる処理の単位は要求ＩＤ４３だが、順番がまわってきたことを切っ掛けに処理される単位は、受付判定処理６３と制御発行処理６５では制御対象ノードおよび制御対象インタフェース単位であるため、制御対象が同一である処理は、キューの処理順番がまわってくる前に一編に処理される可能性もある。
次に、図８のような処理キューの構成を採る場合について説明する。
こちらのモデルは処理ごとにキューを用意する方式で、要求分類処理６１、受付判定処理６３、制御発行処理６５を、例えば、複数のＣＰＵにより並列に動作させる場合などに適する。厳密には、制御要求管理テーブル２１を共有する都合上、排他制御により各処理は時分割されることになるが、処理間の割当時間（順序）７９が巡ってきた際に、積まれている同種の処理を一気に裁く形態としては適している。例えば、予め定められたタイミング７９毎に各キューに積まれた処理を実行する。また、キューに予め定められた量がたまったら、まとめて処理を実行するようにしてもよい。
要求分類処理６１、受付判定処理６３、制御発行処理６５について、フローチャートを用いて補足する。
図１０に要求分類処理６１のフローチャートを示す。要求分類処理については、図４の説明の中で、制御要求分類部２０が行う処理手順として、図１０の符号を参照して述べているため省略する。
次に、図８のような処理キューの構成を採る場合について説明する。
こちらのモデルは処理ごとにキューを用意する方式で、要求分類処理６１、受付判定処理６３、制御発行処理６５を、例えば、複数のＣＰＵにより並列に動作させる場合などに適する。厳密には、制御要求管理テーブル２１を共有する都合上、排他制御により各処理は時分割されることになるが、処理間の割当時間（順序）７９が巡ってきた際に、積まれている同種の処理を一気に裁く形態としては適している。例えば、予め定められたタイミング７９毎に各キューに積まれた処理を実行する。また、キューに予め定められた量がたまったら、まとめて処理を実行するようにしてもよい。
要求分類処理６１、受付判定処理６３、制御発行処理６５について、フローチャートを用いて補足する。
図１０に要求分類処理６１のフローチャートを示す。要求分類処理については、図４の説明の中で、制御要求分類部２０が行う処理手順として、図１０の符号を参照して述べているため省略する。
図１１に受付判定処理６３のフローチャートを示す。
受付判定処理については、図３の後半の説明の中で受付判定部２２の処理として触れているが、ここではフローチャートの手順に従って説明する。受付判定処理では、制御要求管理テーブルの状態欄４４が「未」の要求（処理状態が「未」の要求）を対象に処理を行う（ステップ１１１）。処理状態が「未」の要求を抽出する際には、同一のノードおよびインタフェース単位に抽出する（ステップ１１２）。制御要求管理テーブルの要求は、対象ノードおよび対象インタフェース毎に分類（４０）されているので、順に検索を行えば良い。同一のノードおよびインタフェースに対する未処理要求を一括り抽出したら、抽出した複数の要求を纏めた要求内容が許容されるか、リソース管理部１９の対応ノードおよびインタフェースの情報を照合する（ステップ１１３）。纏めた要求内容の許容判定については、図３の後半の受付判定部２２の説明で述べているので省略する。判定結果は状態欄４４に反映し（ステップ１１４）、次のノードおよびインタフェースに対する要求の判定に移る（ステップ１１５）。ここで判定結果は、状態欄４４への反映と共に、ユーザ端末に対して通知しても構わない。
受付判定処理については、図３の後半の説明の中で受付判定部２２の処理として触れているが、ここではフローチャートの手順に従って説明する。受付判定処理では、制御要求管理テーブルの状態欄４４が「未」の要求（処理状態が「未」の要求）を対象に処理を行う（ステップ１１１）。処理状態が「未」の要求を抽出する際には、同一のノードおよびインタフェース単位に抽出する（ステップ１１２）。制御要求管理テーブルの要求は、対象ノードおよび対象インタフェース毎に分類（４０）されているので、順に検索を行えば良い。同一のノードおよびインタフェースに対する未処理要求を一括り抽出したら、抽出した複数の要求を纏めた要求内容が許容されるか、リソース管理部１９の対応ノードおよびインタフェースの情報を照合する（ステップ１１３）。纏めた要求内容の許容判定については、図３の後半の受付判定部２２の説明で述べているので省略する。判定結果は状態欄４４に反映し（ステップ１１４）、次のノードおよびインタフェースに対する要求の判定に移る（ステップ１１５）。ここで判定結果は、状態欄４４への反映と共に、ユーザ端末に対して通知しても構わない。
本実施の形態のネットワーク制御システムは、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行うため、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行うことができ、ユーザ要求に対する判定の待ち時間を短くできるという利点がある。
図１２に制御発行処理６５のフローチャートを示す。
制御発行処理についても、図３の後半の説明の中で制御発行部２３の処理として触れているが、ここではフローチャートの手順に従って説明する。制御発行処理では、制御要求管理テーブルの状態欄４４が「ＯＫ」の要求を対象に処理を行う（ステップ１２１）。受付判定処理と同様に、ここでも同一のノードおよびインタフェース単位に抽出を行う（ステップ１２２）。同一のノードおよびインタフェースに対する要求を抽出したら、要求内容を纏めて、対象ノードに対する制御要求を発行する（ステップ１２３）。制御実行部１６に制御要求を渡した処理済の要求は、制御要求管理テーブルから削除する（ステップ１２４）。ここで再び処理状況をユーザ端末に通知しても構わない。制御要求管理テーブルの状態欄４４が「ＯＫ」の全ノードおよびインタフェースに対する処理が完了したら（ステップ１２５）、状態欄４４に記載された判定結果が「ＮＧ」の要求を纏めて削除する（ステップ１２６）。但し、判定結果が「ＮＧ」の要求を削除するタイミングに関しては、受付判定処理の最後に行っても構わないし、制御発行処理の最初に行っても構わない。
本実施の形態のネットワーク制御システムは、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダするため、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減することができる。
図１２に制御発行処理６５のフローチャートを示す。
制御発行処理についても、図３の後半の説明の中で制御発行部２３の処理として触れているが、ここではフローチャートの手順に従って説明する。制御発行処理では、制御要求管理テーブルの状態欄４４が「ＯＫ」の要求を対象に処理を行う（ステップ１２１）。受付判定処理と同様に、ここでも同一のノードおよびインタフェース単位に抽出を行う（ステップ１２２）。同一のノードおよびインタフェースに対する要求を抽出したら、要求内容を纏めて、対象ノードに対する制御要求を発行する（ステップ１２３）。制御実行部１６に制御要求を渡した処理済の要求は、制御要求管理テーブルから削除する（ステップ１２４）。ここで再び処理状況をユーザ端末に通知しても構わない。制御要求管理テーブルの状態欄４４が「ＯＫ」の全ノードおよびインタフェースに対する処理が完了したら（ステップ１２５）、状態欄４４に記載された判定結果が「ＮＧ」の要求を纏めて削除する（ステップ１２６）。但し、判定結果が「ＮＧ」の要求を削除するタイミングに関しては、受付判定処理の最後に行っても構わないし、制御発行処理の最初に行っても構わない。
本実施の形態のネットワーク制御システムは、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダするため、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減することができる。
ここまでは、複数のユーザが同時に設定変更を行う場合への対策方法として本実施の形態を説明してきたが、ここからは、複数の接続拠点を管理する単一ユーザが複数の設定を変更する場合にも、本実施の形態の構成が適用でき、有効であることについて説明する。
再び、図１の拠点３０、３１、３２が、同一企業の拠点と仮定する。例えば、当初、拠点３０と拠点３２の間でのみＶＰＮ回線を開設したところに、新たに、拠点３１と拠点３２の間でも別のＶＰＮ回線を開設しようとしたとする。また、拠点３０と拠点３２の間のＶＰＮ回線の帯域も同時に増量しようとしたとする。
この時、発信側の拠点３０と３１に関しては、それぞれの変更要求が契約帯域内に収まっているかもしれないが、この要求を受け付けられるか否かは、拠点３２側の状況を加味した上で判断を行う。拠点３２は、拠点３０と拠点３１からの異なるＶＰＮトラヒックが合流する形となる。合計トラヒック量が拠点３２の契約帯域を遥かにオーバしていた場合、この設定変更で要求されている通信帯域を保証できなるため、ユーザには要求内容では受け付けられないことを伝える。
このように、設定変更の結果、複数のトラヒックが合流するポイントが発生する場合、リソース制御受付装置１０は次のようにこれらの要求を扱う。要求受付部１１で受信する要求は一要求が対象となるが、前述のとおり、一要求の中には複数の設定変更項目が含まれる可能性がある。設定要求分析部２０では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとに要求を分類して制御要求管理部２１に一次記録する。ここで、設定変更項目とは、例えば、新たなＶＰＮ回線の開設、現在のＶＰＮ回線の帯域の増量についてである。
再び、図１の拠点３０、３１、３２が、同一企業の拠点と仮定する。例えば、当初、拠点３０と拠点３２の間でのみＶＰＮ回線を開設したところに、新たに、拠点３１と拠点３２の間でも別のＶＰＮ回線を開設しようとしたとする。また、拠点３０と拠点３２の間のＶＰＮ回線の帯域も同時に増量しようとしたとする。
この時、発信側の拠点３０と３１に関しては、それぞれの変更要求が契約帯域内に収まっているかもしれないが、この要求を受け付けられるか否かは、拠点３２側の状況を加味した上で判断を行う。拠点３２は、拠点３０と拠点３１からの異なるＶＰＮトラヒックが合流する形となる。合計トラヒック量が拠点３２の契約帯域を遥かにオーバしていた場合、この設定変更で要求されている通信帯域を保証できなるため、ユーザには要求内容では受け付けられないことを伝える。
このように、設定変更の結果、複数のトラヒックが合流するポイントが発生する場合、リソース制御受付装置１０は次のようにこれらの要求を扱う。要求受付部１１で受信する要求は一要求が対象となるが、前述のとおり、一要求の中には複数の設定変更項目が含まれる可能性がある。設定要求分析部２０では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとに要求を分類して制御要求管理部２１に一次記録する。ここで、設定変更項目とは、例えば、新たなＶＰＮ回線の開設、現在のＶＰＮ回線の帯域の増量についてである。
具体的には、変更要求に含まれるフロー識別情報（例えば、ＶＰＮ−ＩＤや、送信元アドレスと送信先アドレスなど）を検索キーとして、経路情報管理部１７を調べる。対象経路上のノード装置やインタフェースのうち、特にエッジノードに関する情報は常に対象となるため、送信先で合流するポイントに関わる設定変更項目も漏れなく抽出される。これらの情報は、制御要求管理部２１には、例えば、図４の＃１と＃２のように分類整理される。
受付判定部２２では、同一の対象ノード、同一の対象インタフェースに関する制御要求は纏めて判定を行うため、複数のトラヒックが合流するポイントに対して、複合する設定変更が受け付けが可能か否かも判定できる。以降の処理は同様である。
受付判定部２２では、同一の対象ノード、同一の対象インタフェースに関する制御要求は纏めて判定を行うため、複数のトラヒックが合流するポイントに対して、複合する設定変更が受け付けが可能か否かも判定できる。以降の処理は同様である。
本ネットワーク制御システムは、例えば、ユーザに対して、利用サービスに関わる設定変更を自由に行うことができるインタフェースを提供する通信事業者のネットワークシステムに有用であり、特に、複数のユーザがそれぞれ同時に網設備に関わる設定変更を行うことを許容するネットワークシステムに適している。
１ ユーザ端末
２ ユーザネットワーク
３ ユーザノード
４ アクセス網
５ エッジノード
６ コアノード
７ 地域網
８ コア網
９ 管理用ネットワーク
１０ リソース制御受付装置
１１ 要求受付部
１５ 判定制御部
１６ 制御実行部
１７ 経路情報管理部
１８ 対象リスト管理部
１９ リソース管理部
２０ 制御要求分類部
２１ 制御要求管理部
２２ 受付判定部
２３ 制御発行部
３０９ リソース制御受付プログラム
２ ユーザネットワーク
３ ユーザノード
４ アクセス網
５ エッジノード
６ コアノード
７ 地域網
８ コア網
９ 管理用ネットワーク
１０ リソース制御受付装置
１１ 要求受付部
１５ 判定制御部
１６ 制御実行部
１７ 経路情報管理部
１８ 対象リスト管理部
１９ リソース管理部
２０ 制御要求分類部
２１ 制御要求管理部
２２ 受付判定部
２３ 制御発行部
３０９ リソース制御受付プログラム
Claims (20)
- 複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する複数の端末と、
前記端末から複数の前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、同一ノード装置のインタフェースに対する設定情報については纏めて設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システム。 - 請求項１に記載の通信システムにおいて、
前記論理回線の識別情報に対応して、該論理回線の経路上にある前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を記憶した経路情報管理部
をさらに備え、
前記サーバ装置の前記分類部は、
前記設定情報に含まれる論理回線の識別情報を基に、前記経路情報管理部を参照して、通信経路上の前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を抽出する手段と、
抽出された前記ノード装置の識別子及び該ノード装置のインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶する手段と
を有することを特徴とする通信システム。 - 請求項２に記載の通信システムにおいて、
制御対象の前記ノード装置の識別子を管理する対象リスト管理部
をさらに備え、
前記サーバ装置の前記分類部は、
抽出された前記ノード装置の識別子と、前記対象リスト管理部で管理された制御対象の前記ノード装置の識別子とを照合し、
照合した結果が合致した場合に、制御対象となる前記ノード装置の識別子及び該ノードのインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶することを特徴とする通信システム。 - 請求項１に記載の通信システムにおいて、
前記受付判定部は、
前記要求記憶部に記憶された同一のノード装置及び同一のインタフェースの複数の設定情報を纏めて受付可否判定して、判定結果を前記要求記憶部に記憶することを特徴とする通信システム。 - 請求項４に記載の通信システムにおいて、
前記受付判定部は、
受付可否判定の結果が否となった場合には、後から登録された設定情報から順に削って受付可否判定を繰り返し、受付可能な設定情報と受付不能な設定情報とを分類して、結果を前記要求記憶部に記憶することを特徴とする通信システム。 - 請求項４に記載の通信システムにおいて、
前記受付判定部は、
受付可否判定の結果が否となった場合には、２分岐探索法を用いて受付可能な設定情報と受付不能な設定情報とを分類し、結果を前記要求記憶部に記憶することを特徴とする通信システム。 - 請求項１に記載の通信システムにおいて、
前記制御発行部は、
前記受付判定部で受付可能と判定された設定情報を、前記要求記憶部に記憶された同一のノード装置及び同一のインタフェース単位で纏めて、該ノード装置への制御要求を生成することを特徴とする通信システム。 - 請求項１に記載の通信システムにおいて、
前記サーバ装置は、
前記受信部が、複数の設定情報を受信し、
設定情報を受信すると、分類処理待ちをキューに積み、
分類処理を実行すると、受付判定処理待ちを前記キューに積み、
受付判定処理を実行すると、制御発行処理待ちを前記キューに積み、
前記受付判定部は、前記キューに連続して積まれた複数の設定情報についての受付判定処理待ちに対して纏めて受付可否を判定し、及び、前記制御発行部は前記キューに連続して積まれた複数の設定情報についての制御発行処理待ちに対して纏めて制御要求を生成する通信システム。 - 請求項１に記載の通信システムにおいて、
前記サーバ装置は、
前記受信部が、複数の設定情報を受信し、
予め定められたタイミング毎に、前記受付判定部は複数の設定情報について纏めて受付可否を判定し、及び、前記制御発行部は複数の設定情報について纏めて制御要求を生成する通信システム。 - 請求項１に記載の通信システムにおいて、
前記設定情報は、前記論理回線の帯域情報及び優先度のいずれかを含む通信システム。 - 請求項１に記載の通信システムにおいて、
前記端末を複数備え、
前記サーバ装置の前記受信部は、複数の前記端末から複数の設定情報を受信する通信システム。 - 複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する複数の端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を複数受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、同一ノード装置のインタフェースに対する設定情報については纏めて設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置。 - 請求項１２に記載のサーバ装置において、
前記分類部は、
前記論理回線の識別情報に対応して、該論理回線の経路上にある前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を記憶した経路情報管理部を参照して、
前記設定情報に含まれる論理回線の識別情報を基に、通信経路上の前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を抽出する手段と、
抽出された前記ノード装置の識別子及び該ノード装置のインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶する手段と
を有することを特徴とするサーバ装置。 - 請求項１３に記載のサーバ装置において、
前記分類部は、
抽出された前記ノード装置の識別子と、制御対象の前記ノード装置の識別子を管理する対象リスト管理部で管理された制御対象の前記ノード装置の識別子とを照合し、
照合した結果が合致した場合に、制御対象となる前記ノード装置の識別子及び該ノードのインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶することを特徴とするサーバ装置。 - 請求項１２に記載のサーバ装置において、
前記受付判定部は、
前記要求記憶部に記憶された同一のノード装置及び同一のインタフェースの複数の設定情報を纏めて受付可否判定して、判定結果を前記要求記憶部に記憶することを特徴とするサーバ装置。 - 請求項１５に記載のサーバ装置において、
前記受付判定部は、
受付可否判定の結果が否となった場合には、後から登録された設定情報から順に削って受付可否判定を繰り返し、受付可能な設定情報と受付不能な設定情報とを分類して、結果を前記要求記憶部に記憶することを特徴とするサーバ装置。 - 請求項１５に記載のサーバ装置において、
前記受付判定部は、
受付可否判定の結果が否となった場合には、２分岐探索法を用いて受付可能な設定情報と受付不能な設定情報とを分類し、結果を前記要求記憶部に記憶することを特徴とするサーバ装置。 - 請求項１２に記載のサーバ装置において、
前記制御発行部は、
前記受付判定部で受付可能と判定された設定情報を、前記要求記憶部に記憶された同一のノード装置及び同一のインタフェース単位で纏めて、該ノード装置への制御要求を生成することを特徴とするサーバ装置。 - 請求項１２に記載のサーバ装置において、
前記受信部が、複数の設定情報を受信し、
設定情報を受信すると、分類処理待ちをキューに積み、
分類処理を実行すると、受付判定処理待ちを前記キューに積み、
受付判定処理を実行すると、制御発行処理待ちを前記キューに積み、
前記受付判定部は前記キューに連続して積まれた複数の設定情報についての受付判定処理待ちに対して纏めて受付可否を判定し、及び、前記制御発行部は前記キューに連続して積まれた複数の設定情報についての制御発行処理待ちに対して纏めて制御要求を生成するサーバ装置。 - 請求項１２に記載のサーバ装置において、
前記受信部が、複数の設定情報を受信し、
予め定められたタイミング毎に、前記受付判定部は複数の設定情報について纏めて受付可否を判定し、及び、前記制御発行部は複数の設定情報について纏めて制御要求を生成するサーバ装置。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008162883A JP5111256B2 (ja) | 2008-06-23 | 2008-06-23 | 通信システムおよびサーバ装置 |
| US12/389,136 US8848522B2 (en) | 2008-06-23 | 2009-02-19 | Telecommunications system and server apparatus |
| CN2009100041922A CN101616073B (zh) | 2008-06-23 | 2009-02-20 | 通信系统以及服务器装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008162883A JP5111256B2 (ja) | 2008-06-23 | 2008-06-23 | 通信システムおよびサーバ装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010004426A JP2010004426A (ja) | 2010-01-07 |
| JP5111256B2 true JP5111256B2 (ja) | 2013-01-09 |
Family
ID=41431191
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008162883A Expired - Fee Related JP5111256B2 (ja) | 2008-06-23 | 2008-06-23 | 通信システムおよびサーバ装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US8848522B2 (ja) |
| JP (1) | JP5111256B2 (ja) |
| CN (1) | CN101616073B (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4898932B2 (ja) * | 2010-02-15 | 2012-03-21 | 株式会社日立製作所 | ネットワークノード、情報処理システムおよび方法 |
| US10075384B2 (en) | 2013-03-15 | 2018-09-11 | Advanced Elemental Technologies, Inc. | Purposeful computing |
| US9378065B2 (en) | 2013-03-15 | 2016-06-28 | Advanced Elemental Technologies, Inc. | Purposeful computing |
| US9721086B2 (en) | 2013-03-15 | 2017-08-01 | Advanced Elemental Technologies, Inc. | Methods and systems for secure and reliable identity-based computing |
| US10993068B2 (en) * | 2016-08-17 | 2021-04-27 | Ntt Docomo, Inc. | Communication control device and communication control method |
| US10958517B2 (en) * | 2019-02-15 | 2021-03-23 | At&T Intellectual Property I, L.P. | Conflict-free change deployment |
| JPWO2022044339A1 (ja) * | 2020-08-31 | 2022-03-03 | ||
| JP7435807B2 (ja) * | 2020-09-28 | 2024-02-21 | 日本電信電話株式会社 | 帯域推定装置、帯域推定方法、及びプログラム |
| CN115334162B (zh) * | 2022-07-26 | 2023-12-05 | 国家能源集团江苏电力有限公司 | 一种基于用户请求的电力服务管理的安全通信方法及系统 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3736173B2 (ja) * | 1998-05-19 | 2006-01-18 | 株式会社日立製作所 | ネットワーク管理システム |
| JP3621324B2 (ja) * | 2000-03-02 | 2005-02-16 | 日本電信電話株式会社 | 仮想プライベートネットワーク利用規定管理方法及びその装置 |
| AU2001260190A1 (en) * | 2000-04-13 | 2001-10-30 | Operax Ab | Network optimisation method |
| JP3696815B2 (ja) | 2001-08-24 | 2005-09-21 | 日本電信電話株式会社 | 受付制御システムおよび方法 |
| JP3901487B2 (ja) * | 2001-10-18 | 2007-04-04 | 富士通株式会社 | Ｖｐｎサービス管理システム、ｖｐｎサービスマネージャ及びｖｐｎサービスエージェント |
| US7486696B2 (en) * | 2002-06-25 | 2009-02-03 | Avaya, Inc. | System and method for providing bandwidth management for VPNs |
| US7324447B1 (en) * | 2002-09-30 | 2008-01-29 | Packeteer, Inc. | Methods, apparatuses and systems facilitating concurrent classification and control of tunneled and non-tunneled network traffic |
| JP2005039644A (ja) * | 2003-07-17 | 2005-02-10 | Mitsubishi Electric Corp | ＩＰ−ＶＰＮ広域網におけるＱｏＳポリシー管理システム |
| CN100438476C (zh) * | 2003-11-04 | 2008-11-26 | 深圳市深信服电子科技有限公司 | 多路复用vpn隧道的连接方法 |
| US7684322B2 (en) * | 2004-07-01 | 2010-03-23 | Nortel Networks Limited | Flow admission control in an IP network |
| JP4347268B2 (ja) | 2005-06-08 | 2009-10-21 | Ｎｅｃアクセステクニカ株式会社 | ルータ制御装置、ルータ、ｉｐ−ｖｐｎシステム、及び、ルータ制御方法 |
| CN100433731C (zh) * | 2006-10-13 | 2008-11-12 | 中国移动通信集团公司 | 一种实现vpn组播的方法 |
-
2008
- 2008-06-23 JP JP2008162883A patent/JP5111256B2/ja not_active Expired - Fee Related
-
2009
- 2009-02-19 US US12/389,136 patent/US8848522B2/en not_active Expired - Fee Related
- 2009-02-20 CN CN2009100041922A patent/CN101616073B/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20090316600A1 (en) | 2009-12-24 |
| US8848522B2 (en) | 2014-09-30 |
| CN101616073B (zh) | 2012-01-18 |
| CN101616073A (zh) | 2009-12-30 |
| JP2010004426A (ja) | 2010-01-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5111256B2 (ja) | 通信システムおよびサーバ装置 | |
| AU2018236712B2 (en) | Interconnection platform for real-time configuration and management of a cloud-based services exchange | |
| US11552841B2 (en) | Method and apparatus for configuring service | |
| KR101703088B1 (ko) | Sdn 기반의 통합 라우팅 방법 및 그 시스템 | |
| CN109561108B (zh) | 一种基于策略的容器网络资源隔离控制方法 | |
| US9654395B2 (en) | SDN-based service chaining system | |
| CN110178342A (zh) | Sdn网络的可扩缩应用级别监视 | |
| CN112166579B (zh) | 提供虚拟化网络功能的多服务器架构集群 | |
| CN105812257B (zh) | 业务链路由管理系统及其使用方法 | |
| KR101746105B1 (ko) | 서비스 체이닝이 가능한 오픈플로우 스위치 | |
| Chou et al. | A security service on-demand architecture in SDN | |
| US9912592B2 (en) | Troubleshooting openflow networks | |
| KR101729944B1 (ko) | Sdn 기반의 멀티 테넌트 지원 네트워크 시스템의 ip 주소 제공 방법 | |
| Hagos | Software-defined networking for scalable cloud-based services to improve system performance of hadoop-based big data applications | |
| US10333792B2 (en) | Modular controller in software-defined networking environment and operating method thereof | |
| KR101729945B1 (ko) | Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 | |
| KR101729939B1 (ko) | Sdn 기반의 멀티 테넌트 지원 네트워크 시스템 | |
| US11032138B2 (en) | Managing traffic control in a network mitigating DDOS | |
| CN112751701B (zh) | 用于管理网络装置的系统、方法及计算机可读介质 | |
| WO2016068238A1 (ja) | ネットワークの制御システム、制御装置、ネットワーク情報の管理方法及びプログラム | |
| KR101739097B1 (ko) | 오픈플로우 스위치의 서비스 체이닝 방법 | |
| KR101739100B1 (ko) | 서비스 체이닝 가능한 오픈플로우 스위치 제어 방법 및 그 제어기 | |
| KR101806376B1 (ko) | Ip 주소 제공하는 sdn 기반의 멀티 테넌트 지원 네트워크 시스템 | |
| Lehocine et al. | VINEMA: Towards automated management of virtual networks in SDN infrastructures | |
| Romanov et al. | Construction and Methods for Solving Problems at the SDN Control Level |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110301 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120509 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120710 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120907 |
|
| 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: 20120925 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121009 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20151019 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |