通信システムおよびサーバ装置
【課題】広域IP網を企業の通信インフラとして利用できるようなサービスを提供する通信事業者のネットワークシステムで、特に、ユーザが利用サービスに関わる設定変更を自由に行えるような設定インタフェースを開放するネットワークシステムにおいて、複数のユーザが同時に設定変更を行うことができるようにする
【解決手段】ユーザ端末からの設定変更要求を分類する制御要求分類部20において、要求内容を制御対象ノードおよびインタフェースごとに分類し、制御要求管理部21に記憶する。受付判定部22は、要求の受付可否を制御対象ごとに纏めて判定する。制御発行部23は、ノード装置に対する設定更新の際も、受付認可された同一ノードに対する要求をまとめてオーダする。
【解決手段】ユーザ端末からの設定変更要求を分類する制御要求分類部20において、要求内容を制御対象ノードおよびインタフェースごとに分類し、制御要求管理部21に記憶する。受付判定部22は、要求の受付可否を制御対象ごとに纏めて判定する。制御発行部23は、ノード装置に対する設定更新の際も、受付認可された同一ノードに対する要求をまとめてオーダする。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信システムおよびサーバ装置に係り、特に、通信事業者がサービス提供する仮想プライベートネットワークを構成するシステムにおいてネットワークリソースを制御する通信システムおよびサーバ装置に関する。
【背景技術】
【0002】
広域IP網を企業の通信インフラとして利用する仕組みとしては、広域イーサネット(登録商標)やIP−VPN(Virtual Private Network)と呼ばれる通信事業者が提供するサービスがあった。これらのサービスでは、拠点の増減やVPN帯域の変更といったエンドユーザからのサービス要求は、書面やフォーム入力などを通じてサービス提供事業者に連絡を行い、要求を受け取ったサービス提供事業者は、網設備のリソース利用状況を考慮して受付の可否判断を行い、網設備に対する設定変更を行うという流れであった。
VPNを提供する事業者と、VPNを構築する広域IP網を提供する事業者とが異なる場合における、ユーザからのサービス変更の流れに関しては、例えば、特許文献1の図1で紹介されている。この場合のエンドユーザからのサービス要求は、ユーザ側のVPN管理者が仲介する形で広域IP網管理者に申し込みを行うという形態であった。特許文献1の技術では、サービス要求発生から実際にサービス変更が行われるまでのタイムラグを削減する仕組みとして、広域IP網ポリシーとVPNポリシーを共に格納し、広域IP網に対するVPNポリシーの検証や、VPNポリシーに対するサービス要求検証を行うVPNポリシー管理装置が開示されている。
【0003】
また、特許文献2では、広域IP網を跨るVPNのリソース割当要求に対する応答時間を短縮する仕組みとして、IP−VPN広域網のポリシーとして割り当てた通信機器のリソース情報を、VPNリソース情報としてVPNポリシーサーバに設定するIP−VPNポリシーサーバが開示されている。
一方、特許文献3では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合に、送信元ユーザノード別に帯域を確保しつつ、あるユーザノードから受信したデータ量に応じて、他のユーザノードからの出力速度を変更する方法が開示されている。
更に、特許文献4では、複数のユーザ要求受付部を設けることにより、ユーザ要求部の処理負荷を軽減して性能の低下を抑制し、受付制御機能全体の性能低下を回避する方法が開示されている。
【0004】
【特許文献1】特開2001−251307号公報
【特許文献2】特開2005−39644号公報
【特許文献3】特開2006−345173号公報
【特許文献4】特開2003−69635号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
本発明が解決しようとする課題のひとつは、広域IP網を企業の通信インフラとして利用できるようなサービスを提供する通信事業者のネットワークシステムにおいて、ユーザが自社設備の設定変更を行うのと同様の即応性で、利用サービスに関わる設定変更を行えるような設定インタフェースを提供することである。
特に、上記のような設定インタフェースをユーザに開放すると、複数のユーザが通信事業者網の設備に関わる設定変更を行う可能性がある。よって、複数の変更要求が発生した場合にも、ユーザの待ち時間を抑えつつ、それぞれの変更要求を反映させることによって、通信事業者網に矛盾や不整合が発生しないよう調整しながら網設備の設定変更を行う必要がある。
特許文献1や特許文献2では、上記のような複数のユーザが変更要求を発行する際の課題については触れられていない。
特許文献3では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合の帯域制御方法については述べられているが、新たに発生した複数の要求が、同一のユーザノードへのトラフィック集中となる場合の判定制御等については考慮されていない。
【0006】
特許文献4では、ユーザ要求受付部を複数設けることにより、ユーザ要求部の処理負荷を軽減する方法については述べられているが、複数のユーザ要求が影響する転送装置およびリンクが重複する場合については考慮されていない。ユーザ要求の範囲が複数の帯域管理部に跨る場合については記載されているが、要求順に一つずつ判定処理を行っていくという形を採る。そのため、ある帯域管理部への要求が複数発生した場合には、最後の要求を処理するまでに時間がかかり、即応性が失われる可能性がある。
本発明は、以上の点に鑑み、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明は、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報だけを参照するのでは無く、重複するユーザ要求を管理するキューに先に積まれた要求内容を加味して受付判定を行うことを特徴のひとつとする。
更に、本発明は、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダすることを特徴のひとつとする。
【0008】
本発明の第1の解決手段によると、
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する端末と、
前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システムが提供される。
【0009】
本発明の第2の解決手段によると、
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置が提供される。
【発明の効果】
【0010】
本発明によると、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することができる。
【発明を実施するための最良の形態】
【0011】
以下、図面を用いて本実施の形態を説明する。
図1は、本実施の形態の一例を示すネットワーク構成図である。
通信事業者は、複数の地域拠点に跨る同一企業の網(ユーザ網2)同士を繋ぐ通信インフラとして、広域IP網をサービス提供する。
各ユーザ網2と通信事業者がサービス提供するネットワークとは、アクセス網4を介して接続する。ユーザ網2側のアクセス網4との接続は、ユーザノード3を介して行われる。
通信事業者側のネットワークは、コア網8を、幾つかの分割した地域ごとに設置する地域網7同士を相互に接続することにより構成する。各地域網はコアノード6を備え、地域網7同士の間は、それぞれの地域網7を構成するコアノード6を相互に接続する。例えば、地域網7aと地域網7bの間ならば、コアノード6cとコアノード6dを相互に接続する。地域網7とアクセス網4の間は、コアノード6とエッジノード5で相互に接続する。コアノードとエッジノードの関係は1対1とは限らず、1台のコアノード(例:6a)は、複数台のエッジノード(例:5a、5b)と相互に接続してもよい。同様に、エッジノード(例:5a)もアクセス網4aを介して、複数のユーザ拠点(例:30、31)を収容する。このような木構造でネットワークが構成されるため、上流の装置には自ずと複数のユーザ拠点からのトラヒックが集まる形となる。
【0012】
本実施の形態では、上記のような、企業拠点間を接続する通信インフラを提供するサービスにおいて、企業ユーザが利用する通信回線に関わる設定を、ユーザが自由かつリアルタイムに変更できるようにする。特に、複数のユーザが同時に設定変更を行っても、通信事業者網に矛盾や不整合を起こさず、且つ、ユーザの待ち時間を抑えた設定変更を提供できるようにする。
このような設定変更機能を提供する際のネットワーク構成は、上記コア網8と管理用ネットワーク9を、それぞれコアノード6eとエッジノード5dで接続し、管理用ネットワーク9内にリソース制御受付装置(サーバ装置)10を設ける。
ユーザ企業のネットワーク管理者は、本サービスを利用して設定変更を行う際には、自身のネットワーク(ユーザ網2)内の端末1から、リソース制御受付装置10にリクエストを発行する。端末1は、例えば、拠点(ユーザネットワーク)間のIP−VPN(論理回線)の設定情報を入力する入力部と、設定情報をリソース制御受付装置10に送信する送信部とを有する。
【0013】
この時の、ユーザ端末1とリソース制御受付装置10の間の通信方式は、独自のクライアントアプリケーションと独自の通信方式で行っても構わないし、後に示す図9のようなブラウザ画面からの入力形式とHTTP/HTTPSを用いた通信方式で実現しても構わない。図9に示すようなブラウザ画面からの入力形式を採る場合は、管理用ネットワーク9内にWebサーバも必要になるが、こちらは汎用的なWebサーバ/技術を活用すれば良いため、図1では省略している。なお、図9については、後ほど詳細を説明する。
話を戻して、複数のユーザが同時に設定変更を行った場合の課題について、図1を用いて補足説明する。複数のユーザによる設定変更が影響するポイントは、例えば、複数のユーザ拠点からのトラヒックが集まって相乗りする回線である。上記木構造のネットワークの末端では、装置上は複数ユーザのトラヒックが集線されるかもしれないが、ポート/論理インタフェースはユーザ個別となるため、トラヒックの相乗りという状況は発生しない。しかし、上流のコアノードでは、全ユーザの個別トラヒックを対象に資源を割り当てることは不可能であるため、必然的に同一回線にトラヒックが相乗りする形となる。一般的に上流のネットワークになる程、回線帯域は太くなるよう構築するが、全ての回線が均一では無い。例えば、地域網1(7a)と地域網2(7b)の間、コアノード6cとコアノード6dの間など、他のコア網/地域網内の回線より細くなる場合がある。このような回線では、あるユーザが行う設定変更が、他のユーザのトラヒックに影響を与えることになる。
【0014】
一例として、図1の拠点30、31、32が、同一企業の拠点と仮定する。各拠点はユーザNWがはられている。このユーザ企業のネットワーク管理者が、当初、拠点30と31の間で開設していたVPN回線を、拠点30と32の間に変更した場合など、本設定変更により、地域網1(7a)と地域網2(7b)を繋ぐ回線には、新たなトラヒックがかかることになる。
上記のようなポイントに関しては、設定要求の受付可否を判定する必要があるが、同様の設定変更を複数のユーザが同時に行う可能性もある。その際に、リクエストの到着順にシーケンシャルに処理を行うというアプローチもあるが、後にまわされたユーザは待ち時間に対して不満を抱くかもしれない。シーケンシャルに処理を行うアプローチの課題に関しては、図2を用いて説明する。
【0015】
図2は、複数の要求をシーケンシャルに処理する場合の課題を説明する為のシーケンス図である。
図中表記のユーザ端末は、本サービスを利用する企業のネットワーク管理者により操作されるユーザ網内の端末を指し、サービスに関わる変更要求を発行する。最初は、変更内容を入力するためのシステムへのログインである(S1)。図では省略しているが、このステップで認証確認などを行う。
ユーザからの要求は、リソース制御受付装置10で処理する。システムにユーザがログインする際には、ユーザ入力画面を生成して提示する(S2)。
図9は、提示されるユーザ入力画面の例である。
契約情報である拠点や契約帯域の情報は、例えば、拠点ごとに提示する(90、91)。また、ユーザ設定済みの情報に関しても、例えば、拠点単位に分類して提示する(92、93、94)。
図16は、契約情報テーブルの構成図である。図17は、設定情報テーブルの構成図である。契約情報や設定情報は、例えば、それぞれ契約情報テーブルを管理するデータベース(契約情報DB、図16)、設定情報テーブルを管理するデータベース(設定情報DB、図17)から取得することができる。契約情報テーブルは、例えば、ユーザ識別子と拠点識別子と契約帯域とが対応して記憶される。設定情報テーブルは、ユーザ識別子と拠点識別子とVPN−IDと帯域情報と優先度情報とが対応して記憶される。各テーブルから情報が読みだされて、図9のユーザ入力画面の生成に利用される。
また、後述する図3でリソース制御受付装置10の機能ブロック図を示しているが、ここまでの手順は汎用的な技術を活用すれば良いため、機能ブロック図では省略している。契約情報DB、設定情報DBは共にリソース制御受付装置10とは異なる装置に実装しても構わない。その場合は、リソース制御受付装置10と同様、管理用ネットワーク9内に設置する。
【0016】
既存の設定の変更は、変更前の情報を参照しながら、変更後の情報を入力したり(97)選択したり(98)する。既存の設定自体を消去する場合は、該当する設定に付随する削除ボタン96を利用し、新たに設定を追加する場合は、追加ボタン95を利用する。追加ボタンを押下した場合には、ダイアログボックスなどで追加するVLAN−IDの入力を促した後で、92に例示したような入力画面を生成して提示する。但し、追加時には変更前の設定情報は無い。追加や変更で入力した帯域情報の合計値が、拠点の合計帯域(契約帯域)を超過した場合は、入力時にユーザに警告を発する。すなわち、更新ボタンを押下しても、変更要求がリソース制御サーバ10には飛ばないように制御し、入力内容のエラー通知を行う。
【0017】
以上、図9では、拠点ごとの設定情報を纏めたイメージのユーザ入力画面例を提示したが、VLAN−ID単位にソーティングした設定情報を提示する形式でも構わない。また、図9のようなGUI(Graphical User Interface)ベースのユーザ入力方法ではなく、CUI(Command−line User Interface)ベースのユーザ入力方法を提供し、ユーザノード3に対する設定変更と同じ様な操作性を提供する形態でも構わない。
再び図2の説明に戻ると、図9のような画面を利用して、ユーザ端末は設定変更する情報を例えばキーボードやマウス等の入力部から入力して、更新ボタンが押下されることにより要求を発行する(S3)。設定変更要求S3を受け取ったリソース制御受付装置は、設定変更要求の受付可否判定を行う(S4)。受付られない場合はその旨を返信し、受付可能な場合は、該当するノード装置に対して設定変更要求を発行する(S5)。設定変更要求S5を受け取ったノード装置は、変更の可否判定を行い(S6)、設定の変更を実施する(S7)。要求に対するノード装置からの応答を受け取ったリソース制御受付装置は、ユーザ端末に結果を通知して(S8)、次の要求処理に移る(S9)。
【0018】
設定変更要求に対する処理を上記のように行う場合、あるユーザからの要求S3を受け取った直後に、ほぼ同時期に発行された別のユーザからの要求を受け取っても、処理キューの順番で後ろに積まれた要求は、先に積まれた要求を処理し終わるまで扱われない。上記の例で言い換えるなら、S3からS8までの間が待ち時間となってしまう。変更要求の受付判定処理と、ノード装置に対する設定変更処理を独立に動作させることで、先に積まれた要求の受付判定処理が終わったら、速やかに次に積まれた要求の受付判定を行うことは可能になる。しかしながら、最終的に設定が反映されて利用可能となるのは、ノード装置に対する設定変更が完了した後になるため、受付判定結果が判るまでの時間は短縮されるかもしれないが、設定が反映されて利用可能となるまでの時間は改善されないという課題が残る。
本実施の形態では、このように複数の要求が集中した場合にも、ユーザに対する待ち時間を抑えたリソース制御処理を実現する。本実施の形態では、ネットワークリソース制御システム等が、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行い、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行い、ユーザ要求に対する判定の待ち時間を短くする。また、本実施の形態では、ネットワーク制御システムが、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダし、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減する。
【0019】
図18は、本実施の形態のリソース制御受付装置10の構成図である。
本実施の形態のリソース制御受付装置10は、プロセッサ301、メモリ302、記憶装置303及びネットワークインタフェース(304および305)を備える。例えば、汎用的なサーバ装置に、リソース制御受付プログラム309を搭載する。リソース制御受付プログラム309は、記憶装置304に格納され、プログラム実行時にメモリ302上にロードされて、プロセッサ301により動かされる。
経路情報管理部17は、一般的なネットワーク管理システムが管理するものと同様であり、各ノード装置に設定されている経路情報を集約したものである。図18に示したように、経路情報管理部17は、CPU311、メモリ312、記憶装置313、ネットワークインタフェース314を備えた汎用的なデータベース装置310で管理されるテーブル情報である。
【0020】
図15に、経路情報管理テーブルの一構成例を示す。
経路情報管理テーブルは、VPN−ID150と、送信元152および送信先154と、経路情報156とが記憶される。経路情報156は、例えば、VPN−ID150で特定される経路、または、送信元152及び154で特定される経路にあるノード装置の識別子、インタフェースの識別子が記憶される。
一方、対象リスト管理部18は、ユーザの設定変更が他のユーザのトラヒックにも影響を与えるポイント(回線)を含むノード装置およびインタフェースを登録管理する。図18に示したように、対象リスト管理部18は、CPU321、メモリ322、記憶装置323、ネットワークインタフェース324を備えた汎用的なデータベース装置320で管理されるテーブル情報である。こちらは、図1の説明の中で例示したような、回線帯域が細くなるポイント(図1では、6cと6dの間を例に説明)のノード装置(例えば、6cや6d)および対象インタフェースを、当該ネットワークの管理者(通信事業者網の管理者)が事前に登録しておく(図13)。
リソース管理部19の構成は従来のネットワーク管理システムやノード管理システムで用いられているものと同様で構わない。リソース管理部19は、図18に示したように、CPU331、メモリ332、記憶装置333、ネットワークインタフェース334を備えた汎用的なデータベース装置330で管理されるテーブル情報である。限界値の設定としては、物理回線の帯域と等しい値による運用でも構わないし、システムのコンフィグレーションで設定する許容幅の値を、物理回線の帯域に上乗せする運用でも構わない(図14)。
【0021】
図14に、リソース管理テーブルの一構成例を示す。リソース管理テーブルは、ノード識別子140と、インタフェース識別子142と、上限帯域144と、予約済帯域146とが対応して記憶される。
ちなみに図18では、経路情報管理部17を格納するデータベース装置310、対象リスト管理部18を格納するデータベース装置320、リソース管理部19を格納するデータベース装置330を、それぞれ別装置で構成するイメージで示したが、これらの情報は同一のデータベース装置で管理する構成であっても構わない。
図3は、リソース制御受付プログラム309の機能ブロック図である。
リソース制御受付プログラム309は、例えば、要求受付部11と、判定制御部15と、制御実行部16とを有する。判定制御部15は、制御要求分類部20と、制御要求管理部21と、受付判定部22と、制御発行部23とを有する。
図3では、設定変更要求(S3)を受け取った後の処理に関わる機能ブロックのみを記載している。
【0022】
リソース制御受付装置10では、ユーザ端末(ユーザ網2内の端末)1からの変更要求(ユーザ要求、設定変更要求、設定情報)を、要求受付部11で受信する。ここで受信する一要求には、図9のようなユーザ設定画面を通じて入力される内容一式が含まれる。つまり、変更内容が複数の拠点、複数の設定(例えば、92の設定と93の設定と94の設定)に及ぶ場合には、一要求メッセージの中に複数の設定変更項目が含まれることになる。逆に、変更内容が単一拠点の単一設定であるならば、一要求メッセージに含まれる設定変更項目も一つになる。
制御要求分類部20では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとの要求として分類を行う。分類結果は、制御が完了するまで制御要求管理部21に一次的に記録する。
図4に、制御要求管理部21のテーブル構成例を示す。
変更内容41は、対象ノードおよび対象インタフェース(40)毎に分類する。この時、対象ノードおよび対象インタフェースは、経路情報管理部17と対象リスト管理部18を参照して特定する。
【0023】
制御要求分類部20が行う処理手順としては、変更内容に含まれるフロー識別情報(例えば、VPN−IDや、送信元アドレスと送信先アドレスなど)を検索キーとして経路情報管理部17を調べ、対象経路上のノード装置やインタフェースを抽出する(図10、ステップ101)。次に、抽出したノード装置やインタフェースが、対象リスト管理部18に登録されているか確認する(図10、ステップ102)。対象リスト管理部18の情報と照合した結果、合致した場合は、これを合致したノード装置・インタフェースに関する変更内容として、制御要求管理部21に登録する(図10、ステップ103)。対象経路に含まれるエッジノード5に関しては、通信事業者網の境界点にあたる装置として、設定変更の直接の対象となるため、全て制御要求管理部21に抽出する。エッジノードに関する装置およびインタフェースの情報も、対象リスト管理部18に登録しておくと、上記手順の流れで制御要求を管理部21に分類することができる。
引き続き、図4に示した残りの要素について説明する。差分欄(diff)42は、要求帯域に変更がある場合の、変更前帯域と変更後帯域の差分を登録する欄である。後の受付判定部22の処理を行う際に算出する形でも構わないが、変更内容欄41に情報を登録する流れで、制御要求分類部20の処理として行った方がデータの読み出しなどに無駄が無い。
【0024】
要求ID欄(Req−Id)43は、各変更要求に対して本システムが一意に設定する識別子である。制御要求管理部21に登録する際に、他の変更要求と重複が無いように設定する。但し、同一の変更要求から派生した変更要求で、対象ノードおよびインタフェースが異なるものに対しては、同じ要求IDを付与する。
状態欄(Status)44は、変更要求の処理状況を管理する欄である。制御要求分類部20で各変更要求を対象ノード、対象インタフェース毎に分離し、制御要求管理部21に登録した際には、「未」の状態となる。以降、受付判定部22で変更要求の受付判定を行った結果、受付が可能な場合は「OK」に、受付が出来ない場合は「NG」に登録内容を変更する。同一の要求IDに対する受付判定結果が全て「OK」となった場合は、制御発行部23でノード装置に対する設定変更を実施した後に、制御要求管理テーブルから削除する。一方、一つでも「NG」となった要求IDの変更要求に関しては、要求内容では受け付けることが出来ないため、その旨を、要求受付部11を介してユーザに返信する。
図4の説明の中で部分的に説明を行ったが、再び図3に戻って説明を続ける。制御要求分類部20で制御要求管理部21に分類登録を行った後は、受付判定部22において制御要求管理部21に新たに登録された制御要求の受付判定を行う。この時に対象となるのは、図4に示した制御要求管理テーブルの項目で状態欄44が「未」のものである。
【0025】
本システムの特徴的な判定手順としては、各制御要求を単独で判定するのでは無く、同一の対象ノード、同一の対象インタフェースに対する制御要求を纏めて判定する。例えば、図4では判定結果が出た状態を示しているが、エントリ#1と#2や#10と#11のように、同一の対象ノード、同一の対象インタフェースに対する制御要求の処理状態が「未」であったなら、#1と#2、#10と#11はそれぞれ纏めて判定を行う。具体的には、同一対象への複数の制御要求を全て適用できるか否かといった判定を行う。#1と#2の場合ならば、それぞれの変更要求は7Mの帯域増加と2Mの帯域減少であるが、制御対象への影響としては5Mの帯域増加となるので、経路上の制御対象ノード、インタフェースにおいて5Mの帯域増加が可能かという観点で判定を行う。#10と#11の場合も同様に、制御対象において15Mの帯域増加が可能かという観点で判定を行う。纏めた要求内容が受け入れられない場合もありうるが、その際には、後に積まれた要求から順に削って再度判定を行うという方法を用いることができる。また、検索処理で良く用いられる2分岐探索のように、要求数の半分の内容で一次判定を行い、判定結果が可ならば残る要求数の更に半分の内容を上積みして判定を行い、判定結果が不可ならば更に半分の要求数の内容で判定を行うといった判定を繰り返すことにより、許容される境界点を導き出すという方法を用いることができる。図4の#10と#11では、#10の要求までは受け入れられたが、#11の要求は受け入れられなかったケースを例示している。判定結果が不可となった要求に関しては結果を端末1に通知する。また、判定結果が可となった要求に関しても同様に、受付判定結果が出た時点の結果を通知するようにしても構わない。
上記のような判定を行う際の、制御対象における既存のリソース使用状況や限界値の情報は、リソース管理部19から取得する。
【0026】
以上のような手順を経て判定結果が出たら、次は制御発行部23の処理を行う。制御発行部23では制御対象への要求を生成し、制御実行部16を通じて制御を実施する。対象となるのは、受付判定の結果が「OK」となった制御要求だが、ここでも要求ごとに制御を行うのではなく、制御対象ごとに纏めた要求内容で制御を実施する。例えば、図4の#1と#2のような同一のノードに対する要求は、設定変更メッセージ(制御要求)を一つに纏めて制御を実行する。制御内容としては、例えば、VPN/ラベル/フロー単位でのシェイピング設定などを行う。制御要求のインタフェース仕様はノード装置が備えるインタフェースに依存するが、telnetなどで対象ノードにログインして制御コマンドを発行するという方法でも構わないし、IETF(the Internet Engineering Task Force)で策定されたNETCONF Configuration Protocol(RFC4741)を用いても構わない。この時に、同一ノード/同一インタフェースに対する複数の制御要求を、ノード装置に対して1制御コマンド/1制御メッセージで行えるか否かは、対象ノードが備えるインタフェース仕様に依存する。なお、上記「制御対象ごとに纏めた要求内容で制御を実施する」のは、リソース制御受付装置10の制御発行部23の処理である。
【0027】
最後に、対象となるノード装置への制御が完了したら、結果をリソース制御部19に反映すると共にユーザ端末に対しても通知を行う。
ここまでが、図3に示したリソース制御受付装置10の一連の処理の流れになる。図3では、制御要求分類部20、受付判定部22、制御発行部23が、全て一台の装置上に実装された形態を示したが、要求受付部11と制御要求分類部20を実装する装置、受付判定部22を実装する装置、制御発行部23と制御実行部16を実装する装置を分けて、それぞれの装置が、制御要求管理部21を実装した装置と通信を行いながら動作するシステムの形態を採っても構わない。
また、図4は帯域幅の設定変更に伴う制御要求管理に焦点を当てたテーブル構成例であるが、優先度の設定変更に伴う、優先度毎の帯域割当の変動を検査する必要がある場合は、対象ノードおよびインタフェースに加えて優先度を分類項目に加える。つまり、図4の項目40に優先度という条件を加えて分類整理する。同様に、図14に示したリソース管理テーブルも、優先度という条件を加えて分類整理する形となる(例えば、142と144の間に列を追加して分類する)。
【0028】
次に、図3で説明したリソース制御受付装置10の処理手順を、フローチャートを用いてさらに説明する。
図5は、ユーザ要求受信時のリソース制御受付装置の処理手順を示すフローチャートである。
全体的な流れとしては、既に図3で説明したように、ユーザ要求を要求受付部11で受け取る要求受付処理50を行い、次に、判定制御部15で行う判定制御処理52を行う。判定制御処理52については、後に図6を用いて詳細に説明する。判定制御処理52を行ったら、制御実行部16でノード装置に対する制御54を実行する。
図6は、判定制御部15の判定制御処理を示すフローチャートである。
要求分類処理61は制御要求分類部20の処理に相当し、受付判定処理63は受付判定部22の処理に相当する。また、制御発行処理65は制御発行部23の処理に相当する。基本的な流れは、図3で説明したように、要求分類処理61、受付判定処理63、制御発行処理65を順に行っていく形でだが、ここでは処理間の遷移のタイミングを中心に掘り下げて説明する。いずれの処理も、未処理の内容は全て処理した上で、次の処理に遷移させる。要求分類処理61であれば、未処理の要求が無くなるまで処理を行い、未処理の要求が無くなった時点で、次の受付判定処理に遷移する(ステップ60)。受付判定処理63では、未判定の処理が無ければ次の制御発行処理に遷移するが、未判定の処理があれば(ステップ62)、これら全ての受付判定処理を行う(ステップ63)。同様に、制御発行処理65では、未制御の処理が無ければ再び要求分類処理に遷移するが、未制御の処理があれば(ステップ64)、これら全ての制御発行処理を行う(ステップ65)。
未処理キューの実現方式としては、図7のような方式と、図8のような方式が考えられるが、次に図6の流れを、各処理キューの構成に従って説明する。
【0029】
先ずは、図7のような処理キューの構成を採る場合について説明する。
このモデルは処理に依存しない統一キューを設ける方式で、各処理は発生した時点で当該キューに積まれる。図7に示す例のような形で各処理が積まれている場合、72の処理A6が終わるまでは、ステップ60の未処理の要求確認で「有」と判定されるため、繰り返し要求分類処理61が行われる。要求の分類が終わると、各処理A4〜A6は新たな受付判定待ち処理B4〜B6となるが、これらは76の後ろに順次積む形となる。73の処理B2に順番がまわってくると、ステップ60の未処理の要求確認には該当せず「無」と判定され、ステップ62の未処理の判定確認で「有」と判定されるため、受付判定処理63が行われる。74の処理B3が終わるまでは、ステップ62の未処理の判定確認で「有」と判定されるため、繰り返し受付判定処理63が行われる。次の75の処理A7は、ステップ64の未処理の制御確認には該当しないため、再びステップ60に戻って、ステップ61の要求分類処理を行う。次の76の処理C1は、ステップ60にもステップ62にも該当しないため、ステップ64に遷移してステップ65の制御発行処理を行うという流れになる。なお、受付判定処理、制御発行処理は、例えば、B2、B3を繰り返し処理する以外にもまとめて処理することができる。
【0030】
以上のように、図7のモデルでは、統一キューに積まれた順に処理が行われ、同一処理が連続する間はその処理を続ける。このように処理することで、例えば71から72の処理などは、要求分類処理が終わった後は要求判定待ち状態となり、再び統一キューに同じように積まれるため、同時期に連続して発生した要求は、ほぼ同じ周期に処理が進められるようになる。ちなみに、キューに積まれる処理の単位は要求ID43だが、順番がまわってきたことを切っ掛けに処理される単位は、受付判定処理63と制御発行処理65では制御対象ノードおよび制御対象インタフェース単位であるため、制御対象が同一である処理は、キューの処理順番がまわってくる前に一編に処理される可能性もある。
次に、図8のような処理キューの構成を採る場合について説明する。
こちらのモデルは処理ごとにキューを用意する方式で、要求分類処理61、受付判定処理63、制御発行処理65を、例えば、複数のCPUにより並列に動作させる場合などに適する。厳密には、制御要求管理テーブル21を共有する都合上、排他制御により各処理は時分割されることになるが、処理間の割当時間(順序)79が巡ってきた際に、積まれている同種の処理を一気に裁く形態としては適している。例えば、予め定められたタイミング79毎に各キューに積まれた処理を実行する。また、キューに予め定められた量がたまったら、まとめて処理を実行するようにしてもよい。
要求分類処理61、受付判定処理63、制御発行処理65について、フローチャートを用いて補足する。
図10に要求分類処理61のフローチャートを示す。要求分類処理については、図4の説明の中で、制御要求分類部20が行う処理手順として、図10の符号を参照して述べているため省略する。
【0031】
図11に受付判定処理63のフローチャートを示す。
受付判定処理については、図3の後半の説明の中で受付判定部22の処理として触れているが、ここではフローチャートの手順に従って説明する。受付判定処理では、制御要求管理テーブルの状態欄44が「未」の要求(処理状態が「未」の要求)を対象に処理を行う(ステップ111)。処理状態が「未」の要求を抽出する際には、同一のノードおよびインタフェース単位に抽出する(ステップ112)。制御要求管理テーブルの要求は、対象ノードおよび対象インタフェース毎に分類(40)されているので、順に検索を行えば良い。同一のノードおよびインタフェースに対する未処理要求を一括り抽出したら、抽出した複数の要求を纏めた要求内容が許容されるか、リソース管理部19の対応ノードおよびインタフェースの情報を照合する(ステップ113)。纏めた要求内容の許容判定については、図3の後半の受付判定部22の説明で述べているので省略する。判定結果は状態欄44に反映し(ステップ114)、次のノードおよびインタフェースに対する要求の判定に移る(ステップ115)。ここで判定結果は、状態欄44への反映と共に、ユーザ端末に対して通知しても構わない。
【0032】
本実施の形態のネットワーク制御システムは、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行うため、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行うことができ、ユーザ要求に対する判定の待ち時間を短くできるという利点がある。
図12に制御発行処理65のフローチャートを示す。
制御発行処理についても、図3の後半の説明の中で制御発行部23の処理として触れているが、ここではフローチャートの手順に従って説明する。制御発行処理では、制御要求管理テーブルの状態欄44が「OK」の要求を対象に処理を行う(ステップ121)。受付判定処理と同様に、ここでも同一のノードおよびインタフェース単位に抽出を行う(ステップ122)。同一のノードおよびインタフェースに対する要求を抽出したら、要求内容を纏めて、対象ノードに対する制御要求を発行する(ステップ123)。制御実行部16に制御要求を渡した処理済の要求は、制御要求管理テーブルから削除する(ステップ124)。ここで再び処理状況をユーザ端末に通知しても構わない。制御要求管理テーブルの状態欄44が「OK」の全ノードおよびインタフェースに対する処理が完了したら(ステップ125)、状態欄44に記載された判定結果が「NG」の要求を纏めて削除する(ステップ126)。但し、判定結果が「NG」の要求を削除するタイミングに関しては、受付判定処理の最後に行っても構わないし、制御発行処理の最初に行っても構わない。
本実施の形態のネットワーク制御システムは、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダするため、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減することができる。
【0033】
ここまでは、複数のユーザが同時に設定変更を行う場合への対策方法として本実施の形態を説明してきたが、ここからは、複数の接続拠点を管理する単一ユーザが複数の設定を変更する場合にも、本実施の形態の構成が適用でき、有効であることについて説明する。
再び、図1の拠点30、31、32が、同一企業の拠点と仮定する。例えば、当初、拠点30と拠点32の間でのみVPN回線を開設したところに、新たに、拠点31と拠点32の間でも別のVPN回線を開設しようとしたとする。また、拠点30と拠点32の間のVPN回線の帯域も同時に増量しようとしたとする。
この時、発信側の拠点30と31に関しては、それぞれの変更要求が契約帯域内に収まっているかもしれないが、この要求を受け付けられるか否かは、拠点32側の状況を加味した上で判断を行う。拠点32は、拠点30と拠点31からの異なるVPNトラヒックが合流する形となる。合計トラヒック量が拠点32の契約帯域を遥かにオーバしていた場合、この設定変更で要求されている通信帯域を保証できなるため、ユーザには要求内容では受け付けられないことを伝える。
このように、設定変更の結果、複数のトラヒックが合流するポイントが発生する場合、リソース制御受付装置10は次のようにこれらの要求を扱う。要求受付部11で受信する要求は一要求が対象となるが、前述のとおり、一要求の中には複数の設定変更項目が含まれる可能性がある。設定要求分析部20では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとに要求を分類して制御要求管理部21に一次記録する。ここで、設定変更項目とは、例えば、新たなVPN回線の開設、現在のVPN回線の帯域の増量についてである。
【0034】
具体的には、変更要求に含まれるフロー識別情報(例えば、VPN−IDや、送信元アドレスと送信先アドレスなど)を検索キーとして、経路情報管理部17を調べる。対象経路上のノード装置やインタフェースのうち、特にエッジノードに関する情報は常に対象となるため、送信先で合流するポイントに関わる設定変更項目も漏れなく抽出される。これらの情報は、制御要求管理部21には、例えば、図4の#1と#2のように分類整理される。
受付判定部22では、同一の対象ノード、同一の対象インタフェースに関する制御要求は纏めて判定を行うため、複数のトラヒックが合流するポイントに対して、複合する設定変更が受け付けが可能か否かも判定できる。以降の処理は同様である。
【産業上の利用可能性】
【0035】
本ネットワーク制御システムは、例えば、ユーザに対して、利用サービスに関わる設定変更を自由に行うことができるインタフェースを提供する通信事業者のネットワークシステムに有用であり、特に、複数のユーザがそれぞれ同時に網設備に関わる設定変更を行うことを許容するネットワークシステムに適している。
【図面の簡単な説明】
【0036】
【図1】本発明の実施の形態の一例を示すネットワーク構成図。
【図2】複数の要求をシーケンシャルに処理する場合の課題を説明するフローチャート。
【図3】リソース制御受付プログラムの機能ブロック図。
【図4】本実施の形態における制御要求管理テーブルの一構成例を示す図。
【図5】ユーザ要求受信時のリソース制御受付装置の処理手順を示すフローチャート。
【図6】判定制御部の処理手順を示すフローチャート。
【図7】判定制御部における処理キューの一構成例を示す図。
【図8】判定制御部における処理キューの別の構成例を示す図。
【図9】ユーザ要求の設定画面の一例を示す図。
【図10】要求分類処理の処理手順を示すフローチャート。
【図11】受付判定処理の処理手順を示すフローチャート。
【図12】制御発行処理の処理手順を示すフローチャート。
【図13】対象リスト管理テーブルの一構成例を示す図。
【図14】リソース管理テーブルの一構成例を示す図。
【図15】経路情報管理テーブルの一構成例を示す図。
【図16】契約情報管理テーブルの一構成例を示す図。
【図17】設定情報管理テーブルの一構成例を示す図。
【図18】本実施の形態のリソース制御受付装置の構成図。
【符号の説明】
【0037】
1 ユーザ端末
2 ユーザネットワーク
3 ユーザノード
4 アクセス網
5 エッジノード
6 コアノード
7 地域網
8 コア網
9 管理用ネットワーク
10 リソース制御受付装置
11 要求受付部
15 判定制御部
16 制御実行部
17 経路情報管理部
18 対象リスト管理部
19 リソース管理部
20 制御要求分類部
21 制御要求管理部
22 受付判定部
23 制御発行部
309 リソース制御受付プログラム
【技術分野】
【0001】
本発明は、通信システムおよびサーバ装置に係り、特に、通信事業者がサービス提供する仮想プライベートネットワークを構成するシステムにおいてネットワークリソースを制御する通信システムおよびサーバ装置に関する。
【背景技術】
【0002】
広域IP網を企業の通信インフラとして利用する仕組みとしては、広域イーサネット(登録商標)やIP−VPN(Virtual Private Network)と呼ばれる通信事業者が提供するサービスがあった。これらのサービスでは、拠点の増減やVPN帯域の変更といったエンドユーザからのサービス要求は、書面やフォーム入力などを通じてサービス提供事業者に連絡を行い、要求を受け取ったサービス提供事業者は、網設備のリソース利用状況を考慮して受付の可否判断を行い、網設備に対する設定変更を行うという流れであった。
VPNを提供する事業者と、VPNを構築する広域IP網を提供する事業者とが異なる場合における、ユーザからのサービス変更の流れに関しては、例えば、特許文献1の図1で紹介されている。この場合のエンドユーザからのサービス要求は、ユーザ側のVPN管理者が仲介する形で広域IP網管理者に申し込みを行うという形態であった。特許文献1の技術では、サービス要求発生から実際にサービス変更が行われるまでのタイムラグを削減する仕組みとして、広域IP網ポリシーとVPNポリシーを共に格納し、広域IP網に対するVPNポリシーの検証や、VPNポリシーに対するサービス要求検証を行うVPNポリシー管理装置が開示されている。
【0003】
また、特許文献2では、広域IP網を跨るVPNのリソース割当要求に対する応答時間を短縮する仕組みとして、IP−VPN広域網のポリシーとして割り当てた通信機器のリソース情報を、VPNリソース情報としてVPNポリシーサーバに設定するIP−VPNポリシーサーバが開示されている。
一方、特許文献3では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合に、送信元ユーザノード別に帯域を確保しつつ、あるユーザノードから受信したデータ量に応じて、他のユーザノードからの出力速度を変更する方法が開示されている。
更に、特許文献4では、複数のユーザ要求受付部を設けることにより、ユーザ要求部の処理負荷を軽減して性能の低下を抑制し、受付制御機能全体の性能低下を回避する方法が開示されている。
【0004】
【特許文献1】特開2001−251307号公報
【特許文献2】特開2005−39644号公報
【特許文献3】特開2006−345173号公報
【特許文献4】特開2003−69635号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
本発明が解決しようとする課題のひとつは、広域IP網を企業の通信インフラとして利用できるようなサービスを提供する通信事業者のネットワークシステムにおいて、ユーザが自社設備の設定変更を行うのと同様の即応性で、利用サービスに関わる設定変更を行えるような設定インタフェースを提供することである。
特に、上記のような設定インタフェースをユーザに開放すると、複数のユーザが通信事業者網の設備に関わる設定変更を行う可能性がある。よって、複数の変更要求が発生した場合にも、ユーザの待ち時間を抑えつつ、それぞれの変更要求を反映させることによって、通信事業者網に矛盾や不整合が発生しないよう調整しながら網設備の設定変更を行う必要がある。
特許文献1や特許文献2では、上記のような複数のユーザが変更要求を発行する際の課題については触れられていない。
特許文献3では、複数のユーザノードから、ひとつのユーザノードにトラフィックが集中する場合の帯域制御方法については述べられているが、新たに発生した複数の要求が、同一のユーザノードへのトラフィック集中となる場合の判定制御等については考慮されていない。
【0006】
特許文献4では、ユーザ要求受付部を複数設けることにより、ユーザ要求部の処理負荷を軽減する方法については述べられているが、複数のユーザ要求が影響する転送装置およびリンクが重複する場合については考慮されていない。ユーザ要求の範囲が複数の帯域管理部に跨る場合については記載されているが、要求順に一つずつ判定処理を行っていくという形を採る。そのため、ある帯域管理部への要求が複数発生した場合には、最後の要求を処理するまでに時間がかかり、即応性が失われる可能性がある。
本発明は、以上の点に鑑み、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明は、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報だけを参照するのでは無く、重複するユーザ要求を管理するキューに先に積まれた要求内容を加味して受付判定を行うことを特徴のひとつとする。
更に、本発明は、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダすることを特徴のひとつとする。
【0008】
本発明の第1の解決手段によると、
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する端末と、
前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システムが提供される。
【0009】
本発明の第2の解決手段によると、
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置が提供される。
【発明の効果】
【0010】
本発明によると、複数のユーザが設定変更要求を発行した場合にも、ユーザの待ち時間を抑えつつ、通信事業者網に矛盾や不整合が生じないよう制御しながら、網設備の設定変更を行う通信システムおよびサーバ装置を提供することができる。
【発明を実施するための最良の形態】
【0011】
以下、図面を用いて本実施の形態を説明する。
図1は、本実施の形態の一例を示すネットワーク構成図である。
通信事業者は、複数の地域拠点に跨る同一企業の網(ユーザ網2)同士を繋ぐ通信インフラとして、広域IP網をサービス提供する。
各ユーザ網2と通信事業者がサービス提供するネットワークとは、アクセス網4を介して接続する。ユーザ網2側のアクセス網4との接続は、ユーザノード3を介して行われる。
通信事業者側のネットワークは、コア網8を、幾つかの分割した地域ごとに設置する地域網7同士を相互に接続することにより構成する。各地域網はコアノード6を備え、地域網7同士の間は、それぞれの地域網7を構成するコアノード6を相互に接続する。例えば、地域網7aと地域網7bの間ならば、コアノード6cとコアノード6dを相互に接続する。地域網7とアクセス網4の間は、コアノード6とエッジノード5で相互に接続する。コアノードとエッジノードの関係は1対1とは限らず、1台のコアノード(例:6a)は、複数台のエッジノード(例:5a、5b)と相互に接続してもよい。同様に、エッジノード(例:5a)もアクセス網4aを介して、複数のユーザ拠点(例:30、31)を収容する。このような木構造でネットワークが構成されるため、上流の装置には自ずと複数のユーザ拠点からのトラヒックが集まる形となる。
【0012】
本実施の形態では、上記のような、企業拠点間を接続する通信インフラを提供するサービスにおいて、企業ユーザが利用する通信回線に関わる設定を、ユーザが自由かつリアルタイムに変更できるようにする。特に、複数のユーザが同時に設定変更を行っても、通信事業者網に矛盾や不整合を起こさず、且つ、ユーザの待ち時間を抑えた設定変更を提供できるようにする。
このような設定変更機能を提供する際のネットワーク構成は、上記コア網8と管理用ネットワーク9を、それぞれコアノード6eとエッジノード5dで接続し、管理用ネットワーク9内にリソース制御受付装置(サーバ装置)10を設ける。
ユーザ企業のネットワーク管理者は、本サービスを利用して設定変更を行う際には、自身のネットワーク(ユーザ網2)内の端末1から、リソース制御受付装置10にリクエストを発行する。端末1は、例えば、拠点(ユーザネットワーク)間のIP−VPN(論理回線)の設定情報を入力する入力部と、設定情報をリソース制御受付装置10に送信する送信部とを有する。
【0013】
この時の、ユーザ端末1とリソース制御受付装置10の間の通信方式は、独自のクライアントアプリケーションと独自の通信方式で行っても構わないし、後に示す図9のようなブラウザ画面からの入力形式とHTTP/HTTPSを用いた通信方式で実現しても構わない。図9に示すようなブラウザ画面からの入力形式を採る場合は、管理用ネットワーク9内にWebサーバも必要になるが、こちらは汎用的なWebサーバ/技術を活用すれば良いため、図1では省略している。なお、図9については、後ほど詳細を説明する。
話を戻して、複数のユーザが同時に設定変更を行った場合の課題について、図1を用いて補足説明する。複数のユーザによる設定変更が影響するポイントは、例えば、複数のユーザ拠点からのトラヒックが集まって相乗りする回線である。上記木構造のネットワークの末端では、装置上は複数ユーザのトラヒックが集線されるかもしれないが、ポート/論理インタフェースはユーザ個別となるため、トラヒックの相乗りという状況は発生しない。しかし、上流のコアノードでは、全ユーザの個別トラヒックを対象に資源を割り当てることは不可能であるため、必然的に同一回線にトラヒックが相乗りする形となる。一般的に上流のネットワークになる程、回線帯域は太くなるよう構築するが、全ての回線が均一では無い。例えば、地域網1(7a)と地域網2(7b)の間、コアノード6cとコアノード6dの間など、他のコア網/地域網内の回線より細くなる場合がある。このような回線では、あるユーザが行う設定変更が、他のユーザのトラヒックに影響を与えることになる。
【0014】
一例として、図1の拠点30、31、32が、同一企業の拠点と仮定する。各拠点はユーザNWがはられている。このユーザ企業のネットワーク管理者が、当初、拠点30と31の間で開設していたVPN回線を、拠点30と32の間に変更した場合など、本設定変更により、地域網1(7a)と地域網2(7b)を繋ぐ回線には、新たなトラヒックがかかることになる。
上記のようなポイントに関しては、設定要求の受付可否を判定する必要があるが、同様の設定変更を複数のユーザが同時に行う可能性もある。その際に、リクエストの到着順にシーケンシャルに処理を行うというアプローチもあるが、後にまわされたユーザは待ち時間に対して不満を抱くかもしれない。シーケンシャルに処理を行うアプローチの課題に関しては、図2を用いて説明する。
【0015】
図2は、複数の要求をシーケンシャルに処理する場合の課題を説明する為のシーケンス図である。
図中表記のユーザ端末は、本サービスを利用する企業のネットワーク管理者により操作されるユーザ網内の端末を指し、サービスに関わる変更要求を発行する。最初は、変更内容を入力するためのシステムへのログインである(S1)。図では省略しているが、このステップで認証確認などを行う。
ユーザからの要求は、リソース制御受付装置10で処理する。システムにユーザがログインする際には、ユーザ入力画面を生成して提示する(S2)。
図9は、提示されるユーザ入力画面の例である。
契約情報である拠点や契約帯域の情報は、例えば、拠点ごとに提示する(90、91)。また、ユーザ設定済みの情報に関しても、例えば、拠点単位に分類して提示する(92、93、94)。
図16は、契約情報テーブルの構成図である。図17は、設定情報テーブルの構成図である。契約情報や設定情報は、例えば、それぞれ契約情報テーブルを管理するデータベース(契約情報DB、図16)、設定情報テーブルを管理するデータベース(設定情報DB、図17)から取得することができる。契約情報テーブルは、例えば、ユーザ識別子と拠点識別子と契約帯域とが対応して記憶される。設定情報テーブルは、ユーザ識別子と拠点識別子とVPN−IDと帯域情報と優先度情報とが対応して記憶される。各テーブルから情報が読みだされて、図9のユーザ入力画面の生成に利用される。
また、後述する図3でリソース制御受付装置10の機能ブロック図を示しているが、ここまでの手順は汎用的な技術を活用すれば良いため、機能ブロック図では省略している。契約情報DB、設定情報DBは共にリソース制御受付装置10とは異なる装置に実装しても構わない。その場合は、リソース制御受付装置10と同様、管理用ネットワーク9内に設置する。
【0016】
既存の設定の変更は、変更前の情報を参照しながら、変更後の情報を入力したり(97)選択したり(98)する。既存の設定自体を消去する場合は、該当する設定に付随する削除ボタン96を利用し、新たに設定を追加する場合は、追加ボタン95を利用する。追加ボタンを押下した場合には、ダイアログボックスなどで追加するVLAN−IDの入力を促した後で、92に例示したような入力画面を生成して提示する。但し、追加時には変更前の設定情報は無い。追加や変更で入力した帯域情報の合計値が、拠点の合計帯域(契約帯域)を超過した場合は、入力時にユーザに警告を発する。すなわち、更新ボタンを押下しても、変更要求がリソース制御サーバ10には飛ばないように制御し、入力内容のエラー通知を行う。
【0017】
以上、図9では、拠点ごとの設定情報を纏めたイメージのユーザ入力画面例を提示したが、VLAN−ID単位にソーティングした設定情報を提示する形式でも構わない。また、図9のようなGUI(Graphical User Interface)ベースのユーザ入力方法ではなく、CUI(Command−line User Interface)ベースのユーザ入力方法を提供し、ユーザノード3に対する設定変更と同じ様な操作性を提供する形態でも構わない。
再び図2の説明に戻ると、図9のような画面を利用して、ユーザ端末は設定変更する情報を例えばキーボードやマウス等の入力部から入力して、更新ボタンが押下されることにより要求を発行する(S3)。設定変更要求S3を受け取ったリソース制御受付装置は、設定変更要求の受付可否判定を行う(S4)。受付られない場合はその旨を返信し、受付可能な場合は、該当するノード装置に対して設定変更要求を発行する(S5)。設定変更要求S5を受け取ったノード装置は、変更の可否判定を行い(S6)、設定の変更を実施する(S7)。要求に対するノード装置からの応答を受け取ったリソース制御受付装置は、ユーザ端末に結果を通知して(S8)、次の要求処理に移る(S9)。
【0018】
設定変更要求に対する処理を上記のように行う場合、あるユーザからの要求S3を受け取った直後に、ほぼ同時期に発行された別のユーザからの要求を受け取っても、処理キューの順番で後ろに積まれた要求は、先に積まれた要求を処理し終わるまで扱われない。上記の例で言い換えるなら、S3からS8までの間が待ち時間となってしまう。変更要求の受付判定処理と、ノード装置に対する設定変更処理を独立に動作させることで、先に積まれた要求の受付判定処理が終わったら、速やかに次に積まれた要求の受付判定を行うことは可能になる。しかしながら、最終的に設定が反映されて利用可能となるのは、ノード装置に対する設定変更が完了した後になるため、受付判定結果が判るまでの時間は短縮されるかもしれないが、設定が反映されて利用可能となるまでの時間は改善されないという課題が残る。
本実施の形態では、このように複数の要求が集中した場合にも、ユーザに対する待ち時間を抑えたリソース制御処理を実現する。本実施の形態では、ネットワークリソース制御システム等が、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行い、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行い、ユーザ要求に対する判定の待ち時間を短くする。また、本実施の形態では、ネットワーク制御システムが、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダし、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減する。
【0019】
図18は、本実施の形態のリソース制御受付装置10の構成図である。
本実施の形態のリソース制御受付装置10は、プロセッサ301、メモリ302、記憶装置303及びネットワークインタフェース(304および305)を備える。例えば、汎用的なサーバ装置に、リソース制御受付プログラム309を搭載する。リソース制御受付プログラム309は、記憶装置304に格納され、プログラム実行時にメモリ302上にロードされて、プロセッサ301により動かされる。
経路情報管理部17は、一般的なネットワーク管理システムが管理するものと同様であり、各ノード装置に設定されている経路情報を集約したものである。図18に示したように、経路情報管理部17は、CPU311、メモリ312、記憶装置313、ネットワークインタフェース314を備えた汎用的なデータベース装置310で管理されるテーブル情報である。
【0020】
図15に、経路情報管理テーブルの一構成例を示す。
経路情報管理テーブルは、VPN−ID150と、送信元152および送信先154と、経路情報156とが記憶される。経路情報156は、例えば、VPN−ID150で特定される経路、または、送信元152及び154で特定される経路にあるノード装置の識別子、インタフェースの識別子が記憶される。
一方、対象リスト管理部18は、ユーザの設定変更が他のユーザのトラヒックにも影響を与えるポイント(回線)を含むノード装置およびインタフェースを登録管理する。図18に示したように、対象リスト管理部18は、CPU321、メモリ322、記憶装置323、ネットワークインタフェース324を備えた汎用的なデータベース装置320で管理されるテーブル情報である。こちらは、図1の説明の中で例示したような、回線帯域が細くなるポイント(図1では、6cと6dの間を例に説明)のノード装置(例えば、6cや6d)および対象インタフェースを、当該ネットワークの管理者(通信事業者網の管理者)が事前に登録しておく(図13)。
リソース管理部19の構成は従来のネットワーク管理システムやノード管理システムで用いられているものと同様で構わない。リソース管理部19は、図18に示したように、CPU331、メモリ332、記憶装置333、ネットワークインタフェース334を備えた汎用的なデータベース装置330で管理されるテーブル情報である。限界値の設定としては、物理回線の帯域と等しい値による運用でも構わないし、システムのコンフィグレーションで設定する許容幅の値を、物理回線の帯域に上乗せする運用でも構わない(図14)。
【0021】
図14に、リソース管理テーブルの一構成例を示す。リソース管理テーブルは、ノード識別子140と、インタフェース識別子142と、上限帯域144と、予約済帯域146とが対応して記憶される。
ちなみに図18では、経路情報管理部17を格納するデータベース装置310、対象リスト管理部18を格納するデータベース装置320、リソース管理部19を格納するデータベース装置330を、それぞれ別装置で構成するイメージで示したが、これらの情報は同一のデータベース装置で管理する構成であっても構わない。
図3は、リソース制御受付プログラム309の機能ブロック図である。
リソース制御受付プログラム309は、例えば、要求受付部11と、判定制御部15と、制御実行部16とを有する。判定制御部15は、制御要求分類部20と、制御要求管理部21と、受付判定部22と、制御発行部23とを有する。
図3では、設定変更要求(S3)を受け取った後の処理に関わる機能ブロックのみを記載している。
【0022】
リソース制御受付装置10では、ユーザ端末(ユーザ網2内の端末)1からの変更要求(ユーザ要求、設定変更要求、設定情報)を、要求受付部11で受信する。ここで受信する一要求には、図9のようなユーザ設定画面を通じて入力される内容一式が含まれる。つまり、変更内容が複数の拠点、複数の設定(例えば、92の設定と93の設定と94の設定)に及ぶ場合には、一要求メッセージの中に複数の設定変更項目が含まれることになる。逆に、変更内容が単一拠点の単一設定であるならば、一要求メッセージに含まれる設定変更項目も一つになる。
制御要求分類部20では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとの要求として分類を行う。分類結果は、制御が完了するまで制御要求管理部21に一次的に記録する。
図4に、制御要求管理部21のテーブル構成例を示す。
変更内容41は、対象ノードおよび対象インタフェース(40)毎に分類する。この時、対象ノードおよび対象インタフェースは、経路情報管理部17と対象リスト管理部18を参照して特定する。
【0023】
制御要求分類部20が行う処理手順としては、変更内容に含まれるフロー識別情報(例えば、VPN−IDや、送信元アドレスと送信先アドレスなど)を検索キーとして経路情報管理部17を調べ、対象経路上のノード装置やインタフェースを抽出する(図10、ステップ101)。次に、抽出したノード装置やインタフェースが、対象リスト管理部18に登録されているか確認する(図10、ステップ102)。対象リスト管理部18の情報と照合した結果、合致した場合は、これを合致したノード装置・インタフェースに関する変更内容として、制御要求管理部21に登録する(図10、ステップ103)。対象経路に含まれるエッジノード5に関しては、通信事業者網の境界点にあたる装置として、設定変更の直接の対象となるため、全て制御要求管理部21に抽出する。エッジノードに関する装置およびインタフェースの情報も、対象リスト管理部18に登録しておくと、上記手順の流れで制御要求を管理部21に分類することができる。
引き続き、図4に示した残りの要素について説明する。差分欄(diff)42は、要求帯域に変更がある場合の、変更前帯域と変更後帯域の差分を登録する欄である。後の受付判定部22の処理を行う際に算出する形でも構わないが、変更内容欄41に情報を登録する流れで、制御要求分類部20の処理として行った方がデータの読み出しなどに無駄が無い。
【0024】
要求ID欄(Req−Id)43は、各変更要求に対して本システムが一意に設定する識別子である。制御要求管理部21に登録する際に、他の変更要求と重複が無いように設定する。但し、同一の変更要求から派生した変更要求で、対象ノードおよびインタフェースが異なるものに対しては、同じ要求IDを付与する。
状態欄(Status)44は、変更要求の処理状況を管理する欄である。制御要求分類部20で各変更要求を対象ノード、対象インタフェース毎に分離し、制御要求管理部21に登録した際には、「未」の状態となる。以降、受付判定部22で変更要求の受付判定を行った結果、受付が可能な場合は「OK」に、受付が出来ない場合は「NG」に登録内容を変更する。同一の要求IDに対する受付判定結果が全て「OK」となった場合は、制御発行部23でノード装置に対する設定変更を実施した後に、制御要求管理テーブルから削除する。一方、一つでも「NG」となった要求IDの変更要求に関しては、要求内容では受け付けることが出来ないため、その旨を、要求受付部11を介してユーザに返信する。
図4の説明の中で部分的に説明を行ったが、再び図3に戻って説明を続ける。制御要求分類部20で制御要求管理部21に分類登録を行った後は、受付判定部22において制御要求管理部21に新たに登録された制御要求の受付判定を行う。この時に対象となるのは、図4に示した制御要求管理テーブルの項目で状態欄44が「未」のものである。
【0025】
本システムの特徴的な判定手順としては、各制御要求を単独で判定するのでは無く、同一の対象ノード、同一の対象インタフェースに対する制御要求を纏めて判定する。例えば、図4では判定結果が出た状態を示しているが、エントリ#1と#2や#10と#11のように、同一の対象ノード、同一の対象インタフェースに対する制御要求の処理状態が「未」であったなら、#1と#2、#10と#11はそれぞれ纏めて判定を行う。具体的には、同一対象への複数の制御要求を全て適用できるか否かといった判定を行う。#1と#2の場合ならば、それぞれの変更要求は7Mの帯域増加と2Mの帯域減少であるが、制御対象への影響としては5Mの帯域増加となるので、経路上の制御対象ノード、インタフェースにおいて5Mの帯域増加が可能かという観点で判定を行う。#10と#11の場合も同様に、制御対象において15Mの帯域増加が可能かという観点で判定を行う。纏めた要求内容が受け入れられない場合もありうるが、その際には、後に積まれた要求から順に削って再度判定を行うという方法を用いることができる。また、検索処理で良く用いられる2分岐探索のように、要求数の半分の内容で一次判定を行い、判定結果が可ならば残る要求数の更に半分の内容を上積みして判定を行い、判定結果が不可ならば更に半分の要求数の内容で判定を行うといった判定を繰り返すことにより、許容される境界点を導き出すという方法を用いることができる。図4の#10と#11では、#10の要求までは受け入れられたが、#11の要求は受け入れられなかったケースを例示している。判定結果が不可となった要求に関しては結果を端末1に通知する。また、判定結果が可となった要求に関しても同様に、受付判定結果が出た時点の結果を通知するようにしても構わない。
上記のような判定を行う際の、制御対象における既存のリソース使用状況や限界値の情報は、リソース管理部19から取得する。
【0026】
以上のような手順を経て判定結果が出たら、次は制御発行部23の処理を行う。制御発行部23では制御対象への要求を生成し、制御実行部16を通じて制御を実施する。対象となるのは、受付判定の結果が「OK」となった制御要求だが、ここでも要求ごとに制御を行うのではなく、制御対象ごとに纏めた要求内容で制御を実施する。例えば、図4の#1と#2のような同一のノードに対する要求は、設定変更メッセージ(制御要求)を一つに纏めて制御を実行する。制御内容としては、例えば、VPN/ラベル/フロー単位でのシェイピング設定などを行う。制御要求のインタフェース仕様はノード装置が備えるインタフェースに依存するが、telnetなどで対象ノードにログインして制御コマンドを発行するという方法でも構わないし、IETF(the Internet Engineering Task Force)で策定されたNETCONF Configuration Protocol(RFC4741)を用いても構わない。この時に、同一ノード/同一インタフェースに対する複数の制御要求を、ノード装置に対して1制御コマンド/1制御メッセージで行えるか否かは、対象ノードが備えるインタフェース仕様に依存する。なお、上記「制御対象ごとに纏めた要求内容で制御を実施する」のは、リソース制御受付装置10の制御発行部23の処理である。
【0027】
最後に、対象となるノード装置への制御が完了したら、結果をリソース制御部19に反映すると共にユーザ端末に対しても通知を行う。
ここまでが、図3に示したリソース制御受付装置10の一連の処理の流れになる。図3では、制御要求分類部20、受付判定部22、制御発行部23が、全て一台の装置上に実装された形態を示したが、要求受付部11と制御要求分類部20を実装する装置、受付判定部22を実装する装置、制御発行部23と制御実行部16を実装する装置を分けて、それぞれの装置が、制御要求管理部21を実装した装置と通信を行いながら動作するシステムの形態を採っても構わない。
また、図4は帯域幅の設定変更に伴う制御要求管理に焦点を当てたテーブル構成例であるが、優先度の設定変更に伴う、優先度毎の帯域割当の変動を検査する必要がある場合は、対象ノードおよびインタフェースに加えて優先度を分類項目に加える。つまり、図4の項目40に優先度という条件を加えて分類整理する。同様に、図14に示したリソース管理テーブルも、優先度という条件を加えて分類整理する形となる(例えば、142と144の間に列を追加して分類する)。
【0028】
次に、図3で説明したリソース制御受付装置10の処理手順を、フローチャートを用いてさらに説明する。
図5は、ユーザ要求受信時のリソース制御受付装置の処理手順を示すフローチャートである。
全体的な流れとしては、既に図3で説明したように、ユーザ要求を要求受付部11で受け取る要求受付処理50を行い、次に、判定制御部15で行う判定制御処理52を行う。判定制御処理52については、後に図6を用いて詳細に説明する。判定制御処理52を行ったら、制御実行部16でノード装置に対する制御54を実行する。
図6は、判定制御部15の判定制御処理を示すフローチャートである。
要求分類処理61は制御要求分類部20の処理に相当し、受付判定処理63は受付判定部22の処理に相当する。また、制御発行処理65は制御発行部23の処理に相当する。基本的な流れは、図3で説明したように、要求分類処理61、受付判定処理63、制御発行処理65を順に行っていく形でだが、ここでは処理間の遷移のタイミングを中心に掘り下げて説明する。いずれの処理も、未処理の内容は全て処理した上で、次の処理に遷移させる。要求分類処理61であれば、未処理の要求が無くなるまで処理を行い、未処理の要求が無くなった時点で、次の受付判定処理に遷移する(ステップ60)。受付判定処理63では、未判定の処理が無ければ次の制御発行処理に遷移するが、未判定の処理があれば(ステップ62)、これら全ての受付判定処理を行う(ステップ63)。同様に、制御発行処理65では、未制御の処理が無ければ再び要求分類処理に遷移するが、未制御の処理があれば(ステップ64)、これら全ての制御発行処理を行う(ステップ65)。
未処理キューの実現方式としては、図7のような方式と、図8のような方式が考えられるが、次に図6の流れを、各処理キューの構成に従って説明する。
【0029】
先ずは、図7のような処理キューの構成を採る場合について説明する。
このモデルは処理に依存しない統一キューを設ける方式で、各処理は発生した時点で当該キューに積まれる。図7に示す例のような形で各処理が積まれている場合、72の処理A6が終わるまでは、ステップ60の未処理の要求確認で「有」と判定されるため、繰り返し要求分類処理61が行われる。要求の分類が終わると、各処理A4〜A6は新たな受付判定待ち処理B4〜B6となるが、これらは76の後ろに順次積む形となる。73の処理B2に順番がまわってくると、ステップ60の未処理の要求確認には該当せず「無」と判定され、ステップ62の未処理の判定確認で「有」と判定されるため、受付判定処理63が行われる。74の処理B3が終わるまでは、ステップ62の未処理の判定確認で「有」と判定されるため、繰り返し受付判定処理63が行われる。次の75の処理A7は、ステップ64の未処理の制御確認には該当しないため、再びステップ60に戻って、ステップ61の要求分類処理を行う。次の76の処理C1は、ステップ60にもステップ62にも該当しないため、ステップ64に遷移してステップ65の制御発行処理を行うという流れになる。なお、受付判定処理、制御発行処理は、例えば、B2、B3を繰り返し処理する以外にもまとめて処理することができる。
【0030】
以上のように、図7のモデルでは、統一キューに積まれた順に処理が行われ、同一処理が連続する間はその処理を続ける。このように処理することで、例えば71から72の処理などは、要求分類処理が終わった後は要求判定待ち状態となり、再び統一キューに同じように積まれるため、同時期に連続して発生した要求は、ほぼ同じ周期に処理が進められるようになる。ちなみに、キューに積まれる処理の単位は要求ID43だが、順番がまわってきたことを切っ掛けに処理される単位は、受付判定処理63と制御発行処理65では制御対象ノードおよび制御対象インタフェース単位であるため、制御対象が同一である処理は、キューの処理順番がまわってくる前に一編に処理される可能性もある。
次に、図8のような処理キューの構成を採る場合について説明する。
こちらのモデルは処理ごとにキューを用意する方式で、要求分類処理61、受付判定処理63、制御発行処理65を、例えば、複数のCPUにより並列に動作させる場合などに適する。厳密には、制御要求管理テーブル21を共有する都合上、排他制御により各処理は時分割されることになるが、処理間の割当時間(順序)79が巡ってきた際に、積まれている同種の処理を一気に裁く形態としては適している。例えば、予め定められたタイミング79毎に各キューに積まれた処理を実行する。また、キューに予め定められた量がたまったら、まとめて処理を実行するようにしてもよい。
要求分類処理61、受付判定処理63、制御発行処理65について、フローチャートを用いて補足する。
図10に要求分類処理61のフローチャートを示す。要求分類処理については、図4の説明の中で、制御要求分類部20が行う処理手順として、図10の符号を参照して述べているため省略する。
【0031】
図11に受付判定処理63のフローチャートを示す。
受付判定処理については、図3の後半の説明の中で受付判定部22の処理として触れているが、ここではフローチャートの手順に従って説明する。受付判定処理では、制御要求管理テーブルの状態欄44が「未」の要求(処理状態が「未」の要求)を対象に処理を行う(ステップ111)。処理状態が「未」の要求を抽出する際には、同一のノードおよびインタフェース単位に抽出する(ステップ112)。制御要求管理テーブルの要求は、対象ノードおよび対象インタフェース毎に分類(40)されているので、順に検索を行えば良い。同一のノードおよびインタフェースに対する未処理要求を一括り抽出したら、抽出した複数の要求を纏めた要求内容が許容されるか、リソース管理部19の対応ノードおよびインタフェースの情報を照合する(ステップ113)。纏めた要求内容の許容判定については、図3の後半の受付判定部22の説明で述べているので省略する。判定結果は状態欄44に反映し(ステップ114)、次のノードおよびインタフェースに対する要求の判定に移る(ステップ115)。ここで判定結果は、状態欄44への反映と共に、ユーザ端末に対して通知しても構わない。
【0032】
本実施の形態のネットワーク制御システムは、ユーザ要求の受付可否を判定する際に、ノード装置に設定反映された実リソース情報を参照すると共に、重複するユーザ要求を管理するキューに先に積まれた要求内容を考慮して受付判定を行うため、先にキューに積まれた要求を実際のノード装置に設定反映し終わるまで待たなくても受付判定を行うことができ、ユーザ要求に対する判定の待ち時間を短くできるという利点がある。
図12に制御発行処理65のフローチャートを示す。
制御発行処理についても、図3の後半の説明の中で制御発行部23の処理として触れているが、ここではフローチャートの手順に従って説明する。制御発行処理では、制御要求管理テーブルの状態欄44が「OK」の要求を対象に処理を行う(ステップ121)。受付判定処理と同様に、ここでも同一のノードおよびインタフェース単位に抽出を行う(ステップ122)。同一のノードおよびインタフェースに対する要求を抽出したら、要求内容を纏めて、対象ノードに対する制御要求を発行する(ステップ123)。制御実行部16に制御要求を渡した処理済の要求は、制御要求管理テーブルから削除する(ステップ124)。ここで再び処理状況をユーザ端末に通知しても構わない。制御要求管理テーブルの状態欄44が「OK」の全ノードおよびインタフェースに対する処理が完了したら(ステップ125)、状態欄44に記載された判定結果が「NG」の要求を纏めて削除する(ステップ126)。但し、判定結果が「NG」の要求を削除するタイミングに関しては、受付判定処理の最後に行っても構わないし、制御発行処理の最初に行っても構わない。
本実施の形態のネットワーク制御システムは、ノード装置に対する設定更新を行う際に、ユーザ要求の受付判定で認可された複数の要求内容を一括してオーダするため、複数のユーザが同時に同一のノード装置に関わる設定変更要求を発行した場合にも、ノード装置の設定変更要求にかかる負荷を削減することができる。
【0033】
ここまでは、複数のユーザが同時に設定変更を行う場合への対策方法として本実施の形態を説明してきたが、ここからは、複数の接続拠点を管理する単一ユーザが複数の設定を変更する場合にも、本実施の形態の構成が適用でき、有効であることについて説明する。
再び、図1の拠点30、31、32が、同一企業の拠点と仮定する。例えば、当初、拠点30と拠点32の間でのみVPN回線を開設したところに、新たに、拠点31と拠点32の間でも別のVPN回線を開設しようとしたとする。また、拠点30と拠点32の間のVPN回線の帯域も同時に増量しようとしたとする。
この時、発信側の拠点30と31に関しては、それぞれの変更要求が契約帯域内に収まっているかもしれないが、この要求を受け付けられるか否かは、拠点32側の状況を加味した上で判断を行う。拠点32は、拠点30と拠点31からの異なるVPNトラヒックが合流する形となる。合計トラヒック量が拠点32の契約帯域を遥かにオーバしていた場合、この設定変更で要求されている通信帯域を保証できなるため、ユーザには要求内容では受け付けられないことを伝える。
このように、設定変更の結果、複数のトラヒックが合流するポイントが発生する場合、リソース制御受付装置10は次のようにこれらの要求を扱う。要求受付部11で受信する要求は一要求が対象となるが、前述のとおり、一要求の中には複数の設定変更項目が含まれる可能性がある。設定要求分析部20では、設定変更項目ごとに制御対象となるノード装置やインタフェースを調べ、制御対象ごとに要求を分類して制御要求管理部21に一次記録する。ここで、設定変更項目とは、例えば、新たなVPN回線の開設、現在のVPN回線の帯域の増量についてである。
【0034】
具体的には、変更要求に含まれるフロー識別情報(例えば、VPN−IDや、送信元アドレスと送信先アドレスなど)を検索キーとして、経路情報管理部17を調べる。対象経路上のノード装置やインタフェースのうち、特にエッジノードに関する情報は常に対象となるため、送信先で合流するポイントに関わる設定変更項目も漏れなく抽出される。これらの情報は、制御要求管理部21には、例えば、図4の#1と#2のように分類整理される。
受付判定部22では、同一の対象ノード、同一の対象インタフェースに関する制御要求は纏めて判定を行うため、複数のトラヒックが合流するポイントに対して、複合する設定変更が受け付けが可能か否かも判定できる。以降の処理は同様である。
【産業上の利用可能性】
【0035】
本ネットワーク制御システムは、例えば、ユーザに対して、利用サービスに関わる設定変更を自由に行うことができるインタフェースを提供する通信事業者のネットワークシステムに有用であり、特に、複数のユーザがそれぞれ同時に網設備に関わる設定変更を行うことを許容するネットワークシステムに適している。
【図面の簡単な説明】
【0036】
【図1】本発明の実施の形態の一例を示すネットワーク構成図。
【図2】複数の要求をシーケンシャルに処理する場合の課題を説明するフローチャート。
【図3】リソース制御受付プログラムの機能ブロック図。
【図4】本実施の形態における制御要求管理テーブルの一構成例を示す図。
【図5】ユーザ要求受信時のリソース制御受付装置の処理手順を示すフローチャート。
【図6】判定制御部の処理手順を示すフローチャート。
【図7】判定制御部における処理キューの一構成例を示す図。
【図8】判定制御部における処理キューの別の構成例を示す図。
【図9】ユーザ要求の設定画面の一例を示す図。
【図10】要求分類処理の処理手順を示すフローチャート。
【図11】受付判定処理の処理手順を示すフローチャート。
【図12】制御発行処理の処理手順を示すフローチャート。
【図13】対象リスト管理テーブルの一構成例を示す図。
【図14】リソース管理テーブルの一構成例を示す図。
【図15】経路情報管理テーブルの一構成例を示す図。
【図16】契約情報管理テーブルの一構成例を示す図。
【図17】設定情報管理テーブルの一構成例を示す図。
【図18】本実施の形態のリソース制御受付装置の構成図。
【符号の説明】
【0037】
1 ユーザ端末
2 ユーザネットワーク
3 ユーザノード
4 アクセス網
5 エッジノード
6 コアノード
7 地域網
8 コア網
9 管理用ネットワーク
10 リソース制御受付装置
11 要求受付部
15 判定制御部
16 制御実行部
17 経路情報管理部
18 対象リスト管理部
19 リソース管理部
20 制御要求分類部
21 制御要求管理部
22 受付判定部
23 制御発行部
309 リソース制御受付プログラム
【特許請求の範囲】
【請求項1】
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する端末と、
前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システム。
【請求項2】
請求項1に記載の通信システムにおいて、
前記論理回線の識別情報に対応して、該論理回線の経路上にある前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を記憶した経路情報管理部
をさらに備え、
前記サーバ装置の前記分類部は、
前記設定情報に含まれる論理回線の識別情報を基に、前記経路情報管理部を参照して、通信経路上の前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を抽出する手段と、
抽出された前記ノード装置の識別子及び該ノード装置のインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶する手段と
を有することを特徴とする通信システム。
【請求項3】
請求項2に記載の通信システムにおいて、
制御対象の前記ノード装置の識別子を管理する対象リスト管理部
をさらに備え、
前記サーバ装置の前記分類部は、
抽出された前記ノード装置の識別子と、前記対象リスト管理部で管理された制御対象の前記ノード装置の識別子とを照合し、
照合した結果が合致した場合に、制御対象となる前記ノード装置の識別子及び該ノードのインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項4】
請求項1に記載の通信システムにおいて、
前記受付判定部は、
前記要求記憶部に記憶された同一のノード装置及び同一のインタフェースの複数の設定情報を纏めて受付可否判定して、判定結果を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項5】
請求項4に記載の通信システムにおいて、
前記受付判定部は、
受付可否判定の結果が否となった場合には、後から登録された設定情報から順に削って受付可否判定を繰り返し、受付可能な設定情報と受付不能な設定情報とを分類して、結果を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項6】
請求項4に記載の通信システムにおいて、
前記受付判定部は、
受付可否判定の結果が否となった場合には、2分岐探索法を用いて受付可能な設定情報と受付不能な設定情報とを分類し、結果を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項7】
請求項1に記載の通信システムにおいて、
前記制御発行部は、
前記受付判定部で受付可能と判定された設定情報を、前記要求記憶部に記憶された同一のノード装置及び同一のインタフェース単位で纏めて、該ノード装置への制御要求を生成することを特徴とする通信システム。
【請求項8】
請求項1に記載の通信システムにおいて、
前記サーバ装置は、
前記受信部が、複数の設定情報を受信し、
設定情報を受信すると、分類処理待ちをキューに積み、
分類処理を実行すると、受付判定処理待ちを前記キューに積み、
受付判定処理を実行すると、制御発行処理待ちを前記キューに積み、
前記受付判定部は、前記キューに連続して積まれた複数の設定情報についての受付判定処理待ちに対して纏めて受付可否を判定し、及び、前記制御発行部は前記キューに連続して積まれた複数の設定情報についての制御発行処理待ちに対して纏めて制御要求を生成する通信システム。
【請求項9】
請求項1に記載の通信システムにおいて、
前記サーバ装置は、
前記受信部が、複数の設定情報を受信し、
予め定められたタイミング毎に、前記受付判定部は複数の設定情報について纏めて受付可否を判定し、及び、前記制御発行部は複数の設定情報について纏めて制御要求を生成する通信システム。
【請求項10】
請求項1に記載の通信システムにおいて、
前記設定情報は、前記論理回線の帯域情報及び優先度のいずれかを含む通信システム。
【請求項11】
請求項1に記載の通信システムにおいて、
前記端末を複数備え、
前記サーバ装置の前記受信部は、複数の前記端末から複数の設定情報を受信する通信システム。
【請求項12】
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置。
【請求項13】
請求項12に記載のサーバ装置において、
前記分類部は、
前記論理回線の識別情報に対応して、該論理回線の経路上にある前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を記憶した経路情報管理部を参照して、
前記設定情報に含まれる論理回線の識別情報を基に、通信経路上の前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を抽出する手段と、
抽出された前記ノード装置の識別子及び該ノード装置のインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶する手段と
を有することを特徴とするサーバ装置。
【請求項14】
請求項13に記載のサーバ装置において、
前記分類部は、
抽出された前記ノード装置の識別子と、制御対象の前記ノード装置の識別子を管理する対象リスト管理部で管理された制御対象の前記ノード装置の識別子とを照合し、
照合した結果が合致した場合に、制御対象となる前記ノード装置の識別子及び該ノードのインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項15】
請求項12に記載のサーバ装置において、
前記受付判定部は、
前記要求記憶部に記憶された同一のノード装置及び同一のインタフェースの複数の設定情報を纏めて受付可否判定して、判定結果を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項16】
請求項15に記載のサーバ装置において、
前記受付判定部は、
受付可否判定の結果が否となった場合には、後から登録された設定情報から順に削って受付可否判定を繰り返し、受付可能な設定情報と受付不能な設定情報とを分類して、結果を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項17】
請求項15に記載のサーバ装置において、
前記受付判定部は、
受付可否判定の結果が否となった場合には、2分岐探索法を用いて受付可能な設定情報と受付不能な設定情報とを分類し、結果を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項18】
請求項12に記載のサーバ装置において、
前記制御発行部は、
前記受付判定部で受付可能と判定された設定情報を、前記要求記憶部に記憶された同一のノード装置及び同一のインタフェース単位で纏めて、該ノード装置への制御要求を生成することを特徴とするサーバ装置。
【請求項19】
請求項12に記載のサーバ装置において、
前記受信部が、複数の設定情報を受信し、
設定情報を受信すると、分類処理待ちをキューに積み、
分類処理を実行すると、受付判定処理待ちを前記キューに積み、
受付判定処理を実行すると、制御発行処理待ちを前記キューに積み、
前記受付判定部は前記キューに連続して積まれた複数の設定情報についての受付判定処理待ちに対して纏めて受付可否を判定し、及び、前記制御発行部は前記キューに連続して積まれた複数の設定情報についての制御発行処理待ちに対して纏めて制御要求を生成するサーバ装置。
【請求項20】
請求項12に記載のサーバ装置において、
前記受信部が、複数の設定情報を受信し、
予め定められたタイミング毎に、前記受付判定部は複数の設定情報について纏めて受付可否を判定し、及び、前記制御発行部は複数の設定情報について纏めて制御要求を生成するサーバ装置。
【請求項1】
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、
前記設定情報を送信する端末と、
前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置と
を備えた通信システムであって、
前記端末は、
前記ユーザネットワーク間の論理回線の設定情報を入力する入力部と、
前記設定情報を前記サーバ装置に送信する送信部と
を有し、
前記サーバ装置は、
前記端末から前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受付可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を有する通信システム。
【請求項2】
請求項1に記載の通信システムにおいて、
前記論理回線の識別情報に対応して、該論理回線の経路上にある前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を記憶した経路情報管理部
をさらに備え、
前記サーバ装置の前記分類部は、
前記設定情報に含まれる論理回線の識別情報を基に、前記経路情報管理部を参照して、通信経路上の前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を抽出する手段と、
抽出された前記ノード装置の識別子及び該ノード装置のインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶する手段と
を有することを特徴とする通信システム。
【請求項3】
請求項2に記載の通信システムにおいて、
制御対象の前記ノード装置の識別子を管理する対象リスト管理部
をさらに備え、
前記サーバ装置の前記分類部は、
抽出された前記ノード装置の識別子と、前記対象リスト管理部で管理された制御対象の前記ノード装置の識別子とを照合し、
照合した結果が合致した場合に、制御対象となる前記ノード装置の識別子及び該ノードのインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項4】
請求項1に記載の通信システムにおいて、
前記受付判定部は、
前記要求記憶部に記憶された同一のノード装置及び同一のインタフェースの複数の設定情報を纏めて受付可否判定して、判定結果を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項5】
請求項4に記載の通信システムにおいて、
前記受付判定部は、
受付可否判定の結果が否となった場合には、後から登録された設定情報から順に削って受付可否判定を繰り返し、受付可能な設定情報と受付不能な設定情報とを分類して、結果を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項6】
請求項4に記載の通信システムにおいて、
前記受付判定部は、
受付可否判定の結果が否となった場合には、2分岐探索法を用いて受付可能な設定情報と受付不能な設定情報とを分類し、結果を前記要求記憶部に記憶することを特徴とする通信システム。
【請求項7】
請求項1に記載の通信システムにおいて、
前記制御発行部は、
前記受付判定部で受付可能と判定された設定情報を、前記要求記憶部に記憶された同一のノード装置及び同一のインタフェース単位で纏めて、該ノード装置への制御要求を生成することを特徴とする通信システム。
【請求項8】
請求項1に記載の通信システムにおいて、
前記サーバ装置は、
前記受信部が、複数の設定情報を受信し、
設定情報を受信すると、分類処理待ちをキューに積み、
分類処理を実行すると、受付判定処理待ちを前記キューに積み、
受付判定処理を実行すると、制御発行処理待ちを前記キューに積み、
前記受付判定部は、前記キューに連続して積まれた複数の設定情報についての受付判定処理待ちに対して纏めて受付可否を判定し、及び、前記制御発行部は前記キューに連続して積まれた複数の設定情報についての制御発行処理待ちに対して纏めて制御要求を生成する通信システム。
【請求項9】
請求項1に記載の通信システムにおいて、
前記サーバ装置は、
前記受信部が、複数の設定情報を受信し、
予め定められたタイミング毎に、前記受付判定部は複数の設定情報について纏めて受付可否を判定し、及び、前記制御発行部は複数の設定情報について纏めて制御要求を生成する通信システム。
【請求項10】
請求項1に記載の通信システムにおいて、
前記設定情報は、前記論理回線の帯域情報及び優先度のいずれかを含む通信システム。
【請求項11】
請求項1に記載の通信システムにおいて、
前記端末を複数備え、
前記サーバ装置の前記受信部は、複数の前記端末から複数の設定情報を受信する通信システム。
【請求項12】
複数のユーザネットワーク間を接続するネットワークを構成し、制御要求に従い前記ユーザネットワーク間の論理回線の設定情報を変更する複数のノード装置と、前記設定情報を送信する端末と、前記端末から前記設定情報を受信して、前記ノード装置に制御要求を送信するサーバ装置とを備えた通信システムにおける前記サーバ装置であって、
前記端末から、前記ユーザネットワーク間の論理回線の前記設定情報を受信する受信部と、
前記受信部で受信した前記設定情報を、前記論理回線の経路上にある前記ノード装置及び該ノード装置のインタフェース毎に分類する分類部と、
前記分類部で分類された前記設定情報を、前記ノード装置及び該ノード装置のインタフェース毎に記憶する要求記憶部と、
前記ノード装置の各インタフェースに接続される物理回線の帯域情報を記憶するリソース記憶部と、
各ノード装置のインタフェースについて、前記物理回線の帯域情報と前記論理回線の設定情報とに基づいて、設定情報の受付可否を判定する受付判定部と、
前記受付判定部で受け付け可能と判定された前記論理回線の設定情報に基づき、前記ノード装置に対する制御要求を生成する制御発行部と
を備えた前記サーバ装置。
【請求項13】
請求項12に記載のサーバ装置において、
前記分類部は、
前記論理回線の識別情報に対応して、該論理回線の経路上にある前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を記憶した経路情報管理部を参照して、
前記設定情報に含まれる論理回線の識別情報を基に、通信経路上の前記ノード装置の識別子及び該ノード装置のインタフェースの識別子を抽出する手段と、
抽出された前記ノード装置の識別子及び該ノード装置のインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶する手段と
を有することを特徴とするサーバ装置。
【請求項14】
請求項13に記載のサーバ装置において、
前記分類部は、
抽出された前記ノード装置の識別子と、制御対象の前記ノード装置の識別子を管理する対象リスト管理部で管理された制御対象の前記ノード装置の識別子とを照合し、
照合した結果が合致した場合に、制御対象となる前記ノード装置の識別子及び該ノードのインタフェースの識別子毎に、前記設定情報を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項15】
請求項12に記載のサーバ装置において、
前記受付判定部は、
前記要求記憶部に記憶された同一のノード装置及び同一のインタフェースの複数の設定情報を纏めて受付可否判定して、判定結果を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項16】
請求項15に記載のサーバ装置において、
前記受付判定部は、
受付可否判定の結果が否となった場合には、後から登録された設定情報から順に削って受付可否判定を繰り返し、受付可能な設定情報と受付不能な設定情報とを分類して、結果を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項17】
請求項15に記載のサーバ装置において、
前記受付判定部は、
受付可否判定の結果が否となった場合には、2分岐探索法を用いて受付可能な設定情報と受付不能な設定情報とを分類し、結果を前記要求記憶部に記憶することを特徴とするサーバ装置。
【請求項18】
請求項12に記載のサーバ装置において、
前記制御発行部は、
前記受付判定部で受付可能と判定された設定情報を、前記要求記憶部に記憶された同一のノード装置及び同一のインタフェース単位で纏めて、該ノード装置への制御要求を生成することを特徴とするサーバ装置。
【請求項19】
請求項12に記載のサーバ装置において、
前記受信部が、複数の設定情報を受信し、
設定情報を受信すると、分類処理待ちをキューに積み、
分類処理を実行すると、受付判定処理待ちを前記キューに積み、
受付判定処理を実行すると、制御発行処理待ちを前記キューに積み、
前記受付判定部は前記キューに連続して積まれた複数の設定情報についての受付判定処理待ちに対して纏めて受付可否を判定し、及び、前記制御発行部は前記キューに連続して積まれた複数の設定情報についての制御発行処理待ちに対して纏めて制御要求を生成するサーバ装置。
【請求項20】
請求項12に記載のサーバ装置において、
前記受信部が、複数の設定情報を受信し、
予め定められたタイミング毎に、前記受付判定部は複数の設定情報について纏めて受付可否を判定し、及び、前記制御発行部は複数の設定情報について纏めて制御要求を生成するサーバ装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【公開番号】特開2010−4426(P2010−4426A)
【公開日】平成22年1月7日(2010.1.7)
【国際特許分類】
【出願番号】特願2008−162883(P2008−162883)
【出願日】平成20年6月23日(2008.6.23)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
【公開日】平成22年1月7日(2010.1.7)
【国際特許分類】
【出願日】平成20年6月23日(2008.6.23)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
[ Back to top ]