(57)【要約】  サーバコンピュータは、クライアント・サーバアーキテクチャのオーケストレーションソリューションを用いてプロビジョニングされたネットワークに委任／委任解除する。プログラムコード命令は、サーバコンピュータにより管理されたデータへのアクセスを提供する、サーバコンピュータのリモート管理のためのＵＩと、サービス指向アーキテクチャ（ＳＯＡ）をサポートする、ウェブに基づくＡＰＩと、オーケストレーションソリューション及びウェブに基づくＡＰＩを用いて、ネットワークを動的に割り当て及び解放するネットワーク管理ロジックとを実装するように、サーバコンピュータに命令する。代替の実施例では、ネットワーク管理ロジックは、ソフトウェアで定義されたネットワークコントローラＳＤＮＣと協働して、ネットワークに委任／委任解除する。物理的実施形態は、ＳＯＡに基づくものと、ＳＤＮに基づくものとのいずれか又は両方を実装してもよい。
2019506095.tif 000002
【特許請求の範囲】
【請求項１】
サーバコンピュータは、アプリケーション及びデータを格納する少なくとも１つの処理装置を備える処理システムを備え、
上記サーバコンピュータは、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行い、
上記１つ又は複数のオーケストレーションソリューション及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムは、
上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、
サービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、
ネットワークの動的な割り当て及び解放を行い、上記１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うネットワーク管理ロジックと
を実装するように上記処理システムに命令するプログラムコード命令を備える、
サーバコンピュータ。
【請求項２】
上記ネットワーク管理ロジックは、複数のネットワークブロックと、各ネットワークブロック内の個々のネットワークプリフィックス、ネットワーク、サブネットワーク、及びマイクロセグメントとの動的なり当て及び解放を行う、
請求項１記載のサーバコンピュータ。
【請求項３】
上記ネットワーク管理ロジックは、ネットワークに対する要求を処理し、以下の条件、すなわち、
上記要求が、ネットワークユーザにタグ付けされたネットワークブロック又はプリフィックスを指定することと、
上記サーバコンピュータが、上記ネットワークユーザにタグ付けされたネットワークブロックにおいて利用可能であるデフォルトビットマスクを構成していることと、
上記要求がＩＰアドレス又はビットマスクを示し、上記要求されたネットワーク及び／又は上記ＩＰアドレス又はビットマスクに対応するサイズのパブリックなネットワークが利用可能であることと、
上記サーバコンピュータがデフォルトビットマスクで構成され、上記デフォルトビットマスクに対応するサイズを有するネットワークが少なくとも１つのパブリックなネットワークブロックにおいて利用可能であることと
のうちの少なくとも１つが真である場合、上記要求されたネットワークをネットワークブロックから割り当てる、
請求項１記載のサーバコンピュータ。
【請求項４】
上記オーケストレーションソリューション以外の技術によってどの部分のネットワークブロックが管理されるのかを管理するように構成された、
請求項３記載のサーバコンピュータ。
【請求項５】
上記サーバコンピュータは、以前に割り当てられたネットワークがもはや使用されていないことを検出することに応答して、以前に割り当てられたネットワークを解放する、
請求項１記載のサーバコンピュータ。
【請求項６】
上記サーバコンピュータは、上記以前に割り当てられたネットワークの実際の使用を追跡することにより上記検出を行う、
請求項５記載のサーバコンピュータ。
【請求項７】
上記処理システムは、
上記１つ又は複数のオーケストレーションソリューション及び上記ウェブに基づくアプリケーションプログラミングインターフェースを用いて、複数のホストに対するインターネットプロトコル「［ＩＰ」］リソースの動的な割り当て及び解放を行うことと、
互いに重複するアドレス空間を有する複数のネットワークの複数のノードである２つ以上のホストのそれぞれに対して、少なくとも１つの固有のＩＰリソースを作成することと、
上記少なくとも１つの固有のＩＰリソースが、上記２つ以上のホストのうちの各１つに係るプライベートネットワークの名前と、当該プライベートネットワーク内のＩＰアドレスとの組み合わせに基づくことと
を実施するように上記処理システムに命令するプログラムコード命令をさらに備える、
請求項１記載のサーバコンピュータ。
【請求項８】
サーバコンピュータは、アプリケーション及びデータを格納する少なくとも１つの処理装置を備える処理システムを備え、
上記サーバコンピュータは、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行い、
上記１つ又は複数のＳＤＮコントローラ及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムは、
上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラのリモート管理のためのユーザインターフェースと、
上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコネクタと、
１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックと
を実装するように上記処理システムに命令するプログラムコード命令を備える、
サーバコンピュータ。
【請求項９】
上記ネットワーク管理ロジックは、上記ネットワーク管理ロジックは、複数のネットワークブロックと、各ネットワークブロック内の個々のネットワークプリフィックス、ネットワーク、サブネットワーク、及びマイクロセグメントとの動的な割り当て及び解放を行う、
請求項８記載のサーバコンピュータ。
【請求項１０】
上記ネットワーク管理ロジックは、ネットワークに対する要求を処理し、以下の条件、すなわち、
上記要求が、ネットワークユーザにタグ付けされたネットワークブロック又はプリフィックスを指定することと、
上記サーバコンピュータが、上記ネットワークユーザにタグ付けされたネットワークブロックにおいて利用可能であるデフォルトビットマスクを構成していることと、
上記要求がＩＰアドレス又はビットマスクを示し、上記要求されたネットワーク及び／又は上記ＩＰアドレス又はビットマスクに対応するサイズのパブリックなネットワークが利用可能であることと、
上記サーバコンピュータがデフォルトビットマスクで構成され、上記デフォルトビットマスクに対応するサイズを有するネットワークが少なくとも１つのパブリックなネットワークブロックにおいて利用可能であることと
のうちの少なくとも１つが真である場合、上記要求されたネットワークをネットワークブロックから割り当てる、
請求項８記載のサーバコンピュータ。
【請求項１１】
上記ＳＤＮコントローラ以外の技術によってどの部分のネットワークブロックが管理されるのかを管理するように構成された、
請求項１０記載のサーバコンピュータ。
【請求項１２】
上記サーバコンピュータは、以前に割り当てられたネットワークがもはや使用されていないことを検出することに応答して、以前に割り当てられたネットワークを解放する、
請求項８記載のサーバコンピュータ。
【請求項１３】
上記サーバコンピュータは、上記以前に割り当てられたネットワークの実際の使用を追跡することにより上記検出を行う、
請求項１２記載のサーバコンピュータ。
【請求項１４】
上記処理システムは、
上記１つ又は複数のオーケストレーションソリューション及び上記ウェブに基づくアプリケーションプログラミングインターフェースを用いて、複数のホストに対するインターネットプロトコル「［ＩＰ」］リソースの動的な割り当て及び解放を行うことと、
互いに重複するアドレス空間を有する複数のネットワークの複数のノードである２つ以上のホストのそれぞれに対して、少なくとも１つの固有のＩＰリソースを作成することと
を実施するように上記処理システムに命令するプログラムコード命令をさらに備え、
上記少なくとも１つの固有のＩＰリソースは、上記２つ以上のホストのうちの各１つに係るプライベートネットワークの名前と、当該プライベートネットワーク内のＩＰアドレスとの組み合わせに基づく、
請求項８記載のサーバコンピュータ。
【請求項１５】
プログラムコード命令及びデータを格納する少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータを用いて、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うことを含み、
上記１つ又は複数のオーケストレーションソリューション及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムにおけるプログラムコード命令を実行することは、
上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、
サービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、
ネットワークの動的な割り当て及び解放を行い、上記１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
方法。
【請求項１６】
プログラムコード命令及びデータを格納する少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータを用いて、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行うことを含み、
上記１つ又は複数のＳＤＮコントローラ及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムにおけるプログラムコード命令を実行することは、
上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラのリモート管理のためのユーザインターフェースと、
上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコネクタと、
１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
方法。
【請求項１７】
少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータにより、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うためのプログラムコード命令を格納するコンピュータ可読メモリであって、
上記１つ又は複数のオーケストレーションソリューション及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記コンピュータ可読メモリに格納されたプログラムコード命令を実行することは、
上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、
サービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、
ネットワークの動的な割り当て及び解放を行い、上記１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
コンピュータ可読メモリ。
【請求項１８】
少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータにより、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行うためのプログラムコード命令を格納するコンピュータ可読メモリであって、
上記１つ又は複数のＳＤＮコントローラ及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムにおけるプログラムコード命令を実行することは、
上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラの管理のためのユーザインターフェースと、
上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコネクタと、
１つ又は複数のＳＤＮコントローラによって起動／終了されるように、ネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
コンピュータ可読メモリ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドコンピューティング環境におけるＩＰネットワーク及びＩＰリソースに対する委任（commissioning：権限譲渡）及び委任解除（decommissioning：権限解除）に関する。
【背景技術】
【０００２】
［先行する事件の履歴］
本願は、２０１２年６月２０日に出願されたフィンランド国特許出願第２０１２５６８０からの優先権を主張し、２０１３年６月１９日に出願され、米国特許出願公開第２０１３／０３４６６１８号として公開され、「Method and apparatus for IP commissioning and decommissioning in orchestrated computing environments」のタイトルを有し、同じ出願人によって所有された特許出願シリアル番号第１３／９２１３６１号の一部継続出願である。
【０００３】
長い間にわたって知られているように、インターネットプロトコルｖ．４（ＩＰｖ４）は、利用可能なアドレス空間に関してやや限定的である。この問題を扱うために、ＲＦＣ１９１８標準は、プライベートな使用のために意図された３つのネットワーク、すなわち、１０．０．０．０（クラスＡ）、１７２．１６．０．０（クラスＢ）、及び１９２．１６８．０．０（クラスＣ））を定義する。これらのプライベートネットワークのどれも、パブリックなインターネットにはルーティングされていない。大きな企業及びサービスプロバイダは、それらにより利用可能なアドレス空間を拡張するために、典型的にはクラスＡネットワーク（１０．０．０．０）アドレス空間を有し，一方、家庭及び小さなオフィスで一般的に用いられるＡＤＳＬ及びケーブルモデムは、プライベートな１９２．１６８ネットワークからのＩＰアドレスを分配する。外界への接続はネットワークアドレス変換（Network Address Translation：ＮＡＴ）技術を利用することにより提供され、ここで、パブリックネットワーク及びプライベートネットワークの間に位置したＮＡＴ装置は、ブリッジとして動作する。複数のプライベートネットワークが同じ１０．０．０．０アドレス空間を共用するので、それらは重複している。これらのプライベートネットワークがパブリックなインターネットにルーティングするのではなく内部で実行される限り、重複は些細な問題であった。
【０００４】
複数のプライベートネットワークの重複は、クラウドコンピューティング又はクラウドに基づくサービスに関する課題となる。例えば、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）のサービスプロバイダは、特に仮想プライベートクラウド及び／又は他の同様の技術のコンテキストにおいて同じ１０．０．０．０アドレス空間を使用する可能性がある複数の業務クライアントに同時にサービスを提供するために使用されるマルチテナント計算環境のデプロイメント（配備）を増やしている。このような使用例では、複数の異なるテナントによって用いられる複数のプライベートネットワークは典型的には重複する。
【０００５】
以下の説明において、複数のデータ処理及び通信システムの間の自動ワークフローについて議論する場合、「オーケストレーション」は、サービス指向アーキテクチャ（Service Oriented Architecture：「ＳＯＡ」）の領域内においてその確立した意味で使用される。企業及びサービスプロバイダは、業務上の要求をアプリケーション、データ、及びインフラストラクチャに合わせるためにオーケストレーションソリューションを使用する。上記ソリューションは、典型的には、自動化されたワークフロー、プロビジョニング、及び変更管理によりポリシー及びサービスレベルを定義するために用いられる。この技術によって、組織は、各アプリケーションのニーズに基づいてスケールアップ、スケールダウン、又は迂回することが可能な、アプリケーションに合わされたインフラストラクチャを作成することができる。オーケストレーションはまた、消費に対する請求書発行、測定、及び入金相殺を含む、リソースプールの集中的管理を提供する。
【０００６】
オーケストレーションされた環境においてアプリケーションを実行する様々なサーバへのＩＰアドレス、名前、及び他のネットワークパラメータの割り当ては、一般には作業負荷と呼ばれる。このような割り当ては、従来、上記サーバにおいてＩＰアドレスを構成して、サーバの名前及び対応するＩＰアドレスををドメイン名サーバ（domain name server：ＤＮＳ）に手動で追加することによって、又は、動的ホスト構成プロトコル（Dynamic Host Configuration Protocol：ＤＨＣＰ）及び動的ＤＮＳを用いてそのような割り当てを動的に実行させることによって、達成される。従来のオーケストレーションされた計算環境において実行される物理サーバのＩＰアドレス及び名前は比較的に静的であったので、それらのＳＯＡに基づく自動化されたワークフロー管理処理は、ＩＰ及び名前の委任機構と統合するように拡張されなかった。既存のオーケストレーションソリューションが、クラウドに基づく計算環境に拡張されるとき、上述したＩＰアドレス及び名前を管理するために用いられる従来の方法は、様々な課題を引き起こす。例えば、新たな仮想マシンのプロビジョニングがオンデマンドで行われることをクラウドに基づく計算パラダイムが必要とするとき、従来のオーケストレーションされた計算環境におけるＩＰリソース及び名前の割り当てに用いられる従来技術の方法に関連付けられた手動のＩＰ及び名前割り当て処理は、クラウドに基づく計算環境全体のスケーラビリティに関する限り、直ちにボトルネックになる。さらに、クラウドに基づくオンデマンドの計算パラダイムは、仮想サーバインスタンスの寿命が数分から数年までの任意の長さになりうることを必要とするが、ＤＨＣＰサーバは、自動的に割り当てられたＩＰアドレスに対して、予め定義されかつ固定されたリース期間を提供し、それによって、ＩＰリース期間を仮想計算環境の動的な性質に合わせることを不可能にする。さらに、従来技術は、ＤＨＣＰを用いる場合であっても、発行されたＩＰアドレスの予め定義されたリース期間に委任解除が結びつけられるので、仮想マシンが委任解除されるときにＩＰアドレスを自動的に取り戻すことを不可能にする。従って、従来技術の方法は、ＩＰアドレスのリース期間を、クラウド内で実行される各仮想マシンの固有の寿命に合わせることを不可能にする。
【０００７】
ＤＨＣＰの制限は、クラウドコンピューティングに関連して使用しようとすることですぐに明らかになる。ＤＨＣＰ及びクラウドコンピューティングの間の不十分な適合性の理由のうちの１つは、ＤＨＣＰが決してクラウドコンピューティング又はウェブに基づく統合モデルのために設計されなかったということにある。例えば、ＤＨＣＰはＯＳＩレイヤ２（Ｌ２）において動作する。実際には、クライアントはローカルエリアネットワーク（local-area network：ＬＡＮ）にブロードキャストメッセージを送る。そのＬＡＮにおけるＤＨＣＰサーバは、ブロードキャストメッセージを取り込み、ネットワークインターフェースアダプタの固有のアドレスであるクライアントの媒体アクセス制御（Medium Access Control：ＭＡＣ）アドレスを検査し、ＩＰアドレス及び他のネットワークパラメータをＭＡＣアドレスへ返信する。その後、クライアントは、それ自体のためのネットワークパラメータを構成し、より高いＯＳＩレイヤにおいて動作するＴＣＰ／ＩＰ接続を採用することができる。
【０００８】
実際には、上述の方法は、クライアント及びＤＨＣＰサーバがＬ２接続によって相互接続されなければならないことを必要とする。実際には、クライアント及びＤＨＣＰサーバは同じＬＡＮネットワークに接続されていなければならない。ＬＡＮは複数のＶＬＡＮネットワークで構成されてもよいが、これらはＬ２レイヤにおいて相互接続されていなければならない。複数のクライアントが重複する１０．０．０．０アドレス空間を有する場合、サービスプロバイダは、重複する複数のアドレス空間を別個のＬＡＮネットワークに構成することで、それらを互いに隔離しなければならない。その結果、すべてのプライベートネットワークは互いに隔離され、このことにより、一方では、ネットワーク内のＩＰトラフィックを可能にし、クライアントが他のクライアントのネットワークにアクセスすることを防ぐ。
【０００９】
第１にＤＨＣＰがＬ２において動作し、第２に重複する複数のアドレス空間が別個のＬＡＮへ隔離されなければならないという事実の結果、単一のＤＨＣＰが論理的に複数のＬＡＮに分かれて存在できなくなる。言いかえると、複数のプライベートネットワークの場合、それらの各々が専用のＤＨＣＰサーバを持たなければならない。
【００１０】
インターネットプロトコルバージョン６（ＩＰｖ６）は、動的なＩＰ割り当てのための２つの機構を提供する。これらの機構はステートフル自動構成及びステートレス自動構成と呼ばれる。どちらの自動構成機構も上記の課題を解決しない。その理由として、第１に、ステートフル自動構成（ＤＨＣＰｖ６）は、実際には、ＩＰｖ４環境で使用されるＤＨＣＰｖ４とまったく同じである。詳しくは、ＩＰリソースが仮想マシンに割り当てられるごとに、割り当てられたＩＰリソースは固定リース値を取得し、これは、割り当てられたＩＰリソースが仮想マシンによって実際に利用され続けるか否かにかかわらず、ＩＰリソースが予め定義された時間期間にわたって割り当てられ続けるということを基本的には意味する。クラウドに基づく環境内では、ＩＰアドレスは、新たな仮想マシンが実行中であるときは常に委任される（発行すみである）べきであり、その仮想マシンが仮想化された計算環境から除去されるときは常に（解放される）べきであるので、これは望ましくない。
【００１１】
一方、ステートレス自動構成は、クライアントがルータ広告に基づいてＩＰアドレスを自律的に取得することを意味する。ＳＯＡアーキテクチャ及びオーケストレーションに関する限り、この方式が動作しないかもしれない２つの理由がある。第１に、オーケストレーションが使用される環境において、典型的な要件として、仮想マシンが実行されることが意図される仮想ローカルエリアネットワーク（Virtual Local Area Network：ＶＬＡＮ）に一致するネットワークからＩＰアドレスが取得される。言いかえれば、ＩＰアドレスは、（ステートレス自動構成がもたらすように）たまたま利用可能になった任意のＩＰアドレスを仮想マシンに与えるのではなく、仮想マシンがデプロイされるＶＬＡＮに対応する特定のネットワークから割り当てられる必要がある。このような使用例でステートレス自動構成が動作しないかもしれない第２の理由は、環境が典型的にはマルチテナント環境であり、ここでは、管理者が、各ネットワークの割り当てレベルを能動的にモニタリングし、ネットワークにおいてどの機器及びクライアントが実行されているかを決定することができなければならない、ということにある。ＩＰアドレスがクライアントによって自律的に取得される場合、与えられた仮想マシンが取得することになるＩＰアドレスを制御する方法はなく、また、管理者によるこれらの関係の管理及び／又はＩＰ割り当ての割り当ての追跡を可能にする、この処理へのいかなる透明性も存在しない。
【００１２】
同じ出願人によって所有された特許文献１は、複数のオーケストレータ（オーケストレーションソリューションを実行するサーバ）が、ＩＰ委任／委任解除サーバ（IP commissioning/decommissioning server：「ＩＰＣＤＳ」）と呼ばれる、権限を有する単一のソースからネットワークパラメータを取得することを可能にする技術を開示することによって、上記の課題への解決方法を提案する。同じ出願人によって所有された出願に開示された方法は、ネットワークがＩＰＣＤＳシステムに記録されている限り、エラスティック（elastic）なネットワーク及び従来の交換ネットワークの両方からのネットワークパラメータのプロビジョニングを行うために使用可能である。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】米国特許出願公開第２０１３／０３４６６１８号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１４】
特許文献１によって提案された技術のデプロイメントの後で、関連する多数の課題が識別された。例えば、ＴＣＰ／ＩＰネットワークは、ソフトウェアで定義されたネットワーキング（Software-Defined Networking：ＳＤＮ）などの技術を用いて、エラスティックなアーキテクチャ及び処理の自動化に向かって進んでいる。そのような技術によって提供される利点は、自動化された管理及び構成処理によるサービスのアジャイル性の向上と、マイクロセグメント化のような方法による向上されたセキュリティと、仮想化された作業負荷及びサービス、集中したインフラストラクチャ、コンテナ、などのデプロイメントを担当するオーケストレータによって実行される、自動化されたサービスワークフロー及び処理と統合することによって導入されるサービスのアジャイル性とを含む。
【００１５】
しかしながら、多くの場合、ＳＤＮは純粋なグリーンフィールド環境にはデプロイされない。むしろ、ＳＤＮは、１９８０年代までさかのぼる従来のＴＣＰ／ＩＰネットワーキングモデルに基づく従来の交換ネットワークをさらに含むネットワークブロックの内部にネットワークを作成するためにしばしば使用される。従って、ＳＤＮを使用しようとする組織は、新たなエラスティックネットワーク及びマイクロセグメントが、同じパブリックＩＰｖ４ブロック、プライベートＩＰｖ４ブロック、及び／又はパブリックＩＰｖ６ブロック（まとめて「共用ネットワークブロック」という）の内部で既に起動されている従来のネットワークと重複しないということを確認しなければならない。
【００１６】
クラウドスタック及びＳＤＮコントローラは、典型的には、それらに対する空きのネットワークプリフィックスの手動構成を可能にするので、それらに対して構成されているプリフィックスからネットワークを自動的に割り当てることができる。しかしながら、共通の課題の源は、前述の技術が、上記ネットワークプリフィックスが属する共用ネットワークブロックの全体的な割り当て状態を認識していないということにある。このことは、ＳＤＮコントローラによって使用される１つ又は複数の空きのネットワークプリフィックスが、サービス自動化ワークフローの一部として自動的に位置決めされ、予約され、及び／又はＳＤＮコントローラへ割り当てられるべきである、ソフトウェアで定義された広域ネットワーキング（Software-Defined Wide Area Networking：ＳＤ−ＷＡＮ）又はネットワーク・アズ・ア・サービス（Network-as-a-Service：ＮａａＳ）のような使用例において、サービス自動化を問題のあるものにする。
【００１７】
さらに、仮想化された（ネットワーク）サービス及び作業負荷、集中したインフラストラクチャ、コンテナなどのデプロイメントを担当する１つ又は複数のオーケストレータにネットワークパラメータのプロビジョニングを行う場合、ネットワークへ接続する前述のリソースが、基礎をなすＴＣＰ／ＩＰネットワークのセットアップに使用された方法を認識しないので、エラスティックネットワーク及び従来のネットワークの両方に関するネットワークパラメータが、権限を有する単一のソース（ＩＰＣＤＳ）からプロビジョニングされていることが必要とされる。このことは、基礎をなすＴＣＰ／ＩＰネットワークをデプロイするために使用された技術とは独立の、オーケストレーションされた処理を可能にする。
【００１８】
課題を部分的に解決するために、同じ出願人によって所有された特許文献１は、複数のオーケストレータが権限を有する単一のソース（ＩＰＣＤＳ）からネットワークパラメータを取得することを可能にする方法を開示する。上記出願で開示された方法は、ネットワークがＩＰＣＤＳシステムに記録されている限り、エラスティックネットワーク及び従来の交換ネットワークの両方からネットワークパラメータのプロビジョニングを行うために使用可能である。このことは、典型的には、ＩＰＣＤＳによって管理されるＩＰリソースを提供するネットワークの手動デプロイメントを必要とする。
【００１９】
従って、ネットワークブロック及び／又はそれらの内容物の管理、割り当て、及び解放をサービス自動化ワークフローに組み込むことに、また、ネットワークブロック及びネットワークプリフィックスなどを管理し、また、１つ又は複数のＳＤＮコントローラに対して自動化された割り当て及び／又は解放を行うことには、なお改善の余地がある。
【課題を解決するための手段】
【００２０】
従って、本発明の目的は、上に識別された課題のうちの１つ又は複数を緩和するような方法、装置、及びコンピュータプログラム製品を提供することにある。特定の目的は、自動化された処理及び／又はワークフローの一部として前述のリソースの自動化された割り当て及び解放を可能にするために、パブリック及びプライベートなネットワークブロック、及びそれらに該当するネットワークを含むがこれらに限定されない、ネットワークブロック及びそれらの内容物の拡張管理を提供することである。ここでのコンテキストにおいて、ネットワークブロックの「内容物」は以下のように理解されてもよい。ネットワークブロックの部分は、プリフィックス、ネットワーク、及び関連付けられた管理上のデータである。ネットワークプリフィックスとネットワークとの間の差は、ネットワークが接続されているということにある。プリフィックスは単にブロックの部分集合のための用語である。ネットワークに一致するネットワークプリフィックスが常に存在するが、プリフィックスがより小さなプリフィックスへさらに分割されているかもしれないので、すべてのプリフィックスがネットワークに一致するわけではない。互いに重複する複数のプライベートネットワークブロックは、同じ出願人によって所有された前述の特許文献１に開示された技術を用いる同じ装置において共存可能である。ネットワークブロックをプリフィックス、ネットワーク、サブネットワーク、マイクロセグメントなどに分割する動作は、目的のために用いられた公知のアルゴリズムを実装するツールを用いて実行されてもよい。前述の技術の一部又はすべてを組み合わせるロジックは、動的ネットワークプロビジョニング処理（Dynamic Network Provisioning Process）又は「ＤＮＰＰ」と呼ばれる。
【００２１】
本発明の目的は、添付の独立請求項において定義されるような本発明の態様によって達成される。より具体的には、本発明は、上述した課題のうちの少なくとも１つを緩和するように、オーケストレーションされたワークフロー又はさもなければ自動化されたワークフローの一部として、ネットワークブロック、ネットワークプリフィックス、ネットワーク、サブネットワーク、マイクロセグメントなどの管理、割り当て、又は解放を行うために使用可能な方法、装置、及びコンピュータプログラム製品を提供する。従属請求項及び以下の詳細な説明及び図面は、追加の課題を解決し、及び／又は、追加の利点を提供する特定の実施形態に関する。
【００２２】
本開示の１つの実施形態は、アプリケーション及びデータを格納する少なくとも１つの処理装置を備える処理システムを備えるサーバコンピュータである。上記サーバコンピュータは、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対してそれらのプロビジョニングを行う。１つ又は複数のオーケストレーションソリューション及びサーバコンピュータは、クライアント・サーバアーキテクチャを構成する。処理システムは、上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、サービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、ネットワークの動的な割り当て及び解放を行い、１つ又は複数のオーケストレーションソリューション及びウェブに基づくアプリケーションプログラミングインターフェースに対してそれらのプロビジョニングを行うネットワーク管理ロジックとを実装するように処理システムに命令するプログラムコード命令を備える。
【００２３】
本開示のもう１つの実施形態は、アプリケーション及びデータを格納する少なくとも１つの処理装置を備える処理システムを備えるサーバコンピュータである。サーバコンピュータは、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行う。１つ又は複数のＳＤＮコントローラ及びサーバコンピュータは、クライアント・サーバアーキテクチャを構成する。上記処理システムは、上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラのリモート管理のためのユーザインターフェースと、上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコントローラと、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックとを実装するように上記処理システムに命令するプログラムコード命令を備える。
【００２４】
本開示の物理的実施形態は、ＳＯＡに基づく実装と、ＳＤＮに基づく実装とのいずれか又は両方を実施してもよい。
【００２５】
本開示のさらに別の実施形態は、プログラムコード命令を格納する方法及びコンピュータ可読メモリを備え、サーバコンピュータにおける方法又はプログラムコード命令の実行は、ＳＯＡに基づくサーバコンピュータと、ＳＤＮに基づくサーバコンピュータとのいずれか又は両方の特徴を実装する。
【００２６】
従って、本発明は、動的ネットワークプロビジョニング処理（ＤＮＰＰ）を改善する。同じ出願人によって所有された特許文献１で説明されたＩＰＣＤＳ技術が使用可能になる前には、ＩＰリソースに対して委任する、タグ付けされたネットワークは、何らかの方法で、例えば手動で委任されなければならない。本発明は、このネットワークに対する委任が改善及び自動化されるべきであるという観点に基づく。ＩＰＣＤＳが動作可能になる前に、ネットワークがどこかから起動される必要がある。ＤＮＰＰは、１）ネットワークブロックがどのように管理されているかを説明することで、この課題を解決することを目的とする。
【００２７】
典型的な実施例では、ＤＮＰＰクライアント機器は、
与えられたネットワークブロック又はその一部を特定の使用のために予約するように、テナント名、顧客名、又はＤＮＰＰで用いられる他の任意の識別子に基づいて、１つ又は複数のネットワークブロック、ネットワークプリフィックス、ネットワーク、マイクロセグメントなどに要求するタスクと、
上記リソースが終了（deactivate）されるとき、１つ又は複数の既に割り当てられていたネットワークブロック、ネットワークプリフィックス、ネットワーク、マイクロセグメントなどの解放をトリガするタスクと
を実行するように構成されたクライアントロジックを備える。
【００２８】
本発明の他の態様は、本発明に係るＤＮＰＰサーバ及びＤＮＰＰクライアントを動作させる方法と、コンピュータプログラム製品とを含み、適切な構成を備えたサーバ及びクライアントコンピュータにおいて当該コンピュータプログラム製品を実行することは、それらにＤＮＰＰサーバ及びＤＮＰＰクライアントの特徴を提供し、従って、ＤＮＰＰサーバ及びＤＮＰＰクライアントに本発明に係る方法を実行させる。代替として、同じ出願人によって所有された特許文献１で説明されたＩＰＣＤＳの方法をさらに実装するもう１つのサーバ及び／又はクライアントに、ＤＮＰＰロジックが組み込まれてもよい。
【００２９】
本発明によって概説された課題を解決しようとする以前の試みは、単一のクラウドスタックのみを仮定していたので、それらは、複数のオーケストレータ、ＳＤＮコントローラ、及び／又は既存のサービス、及び／又はインフラストラクチャからなる環境における相互運用性の課題を解決することができない。オーケストレーションされたワークフロー又はさもなければ自動化されたワークフローに関して、又はＳＤＮコントローラの内部で直接的に、又は様々なクラウドスタックの一部として、ネットワークブロック及びそれらの内容物の管理、割り当て、及び解放を行う以前の試みとは異なり、本発明は、製造環境において使用されるネットワークブロックが、典型的に、従来の交換されるネットワークとエラスティックネットワークとの間で典型的に共用されることを認識し、また、これら２つの間のシームレスな相互運用性が、与えられたネットワークブロックに該当するＴＣＰ／ＩＰネットワークを起動、構成、又はスイッチングするためにどの技術が使用されているかにかかわらず、すべてのネットワークブロック及び／又は管理下にあるそれらの内容物の管理、割り当て、及び解放を行う権限を有する一体化されたシステムにおいて、各ネットワークブロックのすべての内容物が管理されることを必要とすることを認識している。
【００３０】
好ましい、ただしオプションの特徴によれば、ＤＮＰＰロジックは、（ネットワーク）サービス、アプリケーション、作業負荷、コンテナなどをデプロイするオーケストレーションされたワークフローと、エラスティックネットワークの自動化された起動及び動作中の構成を担当するＳＤＮコントローラとの間の統合レイヤとして機能してもよい。このオプションの方法は、ＤＮＰＰクライアントによって要求されたときに、ネットワークブロック又はそれらの内容物の割り当て及び／又は解放を行い、また、関連付けられた変化を、ＤＮＰＰサーバロジックを実装する装置に直接的又は間接的に統合されたＳＤＮコントローラにもたらすために使用される。このオプションの方法の目的は、双方向（ノース・サウス（North-South））統合モデルを実装することにある。それによって、顧客とのインターフェースをとる様々なポータルの業務ロジックを担当するノースバウンドにおける１つ又は複数のオーケストレータは、利用可能なネットワークプリフィックス、ネットワーク、サブネットワーク、又はマイクロセグメントを、エンドユーザ（内部又は外部の顧客）に対して、潜在的にはサービスとして提供することができる。また、それによって、ノースバウンドにおける上記オーケストレータは、サウスバウンドにおいてＤＮＰＰと統合されている１つ又は複数のＳＤＮコントローラにおいて、エンドユーザによって選択されたネットワークプリフィックス、ネットワーク、サブネットワーク、及び／又はマイクロセグメントを自動的に起動するために、ＤＮＰＰに含まれたオプションのロジックを使用してもよい。
【００３１】
上記の構成要素は以下でさらに詳細に述べられ、ここで、「サウスバウンド」及び「ノースバウンド」インターフェースは以下のように定義される。ある構成要素のノースバウンドインターフェースは、当該構成要素によって、又は当該構成要素において使用された、より低レベルの詳細な構成要素（例えばデータ又は機能）を概念化する。ノースバウンドインターフェースは、より高レベルの１つ又は複数の構成要素のサウスバウンドインターフェースを用いるより高レベルのレイヤとインターフェースをとるために用いられる。サウスバウンドインターフェースは、主としてアーキテクチャの単一の構成要素に固有の概念を技術的な詳細事項に分解する。ノースバウンド及びサウスバウンドインターフェースは、アーキテクチャの全体図の上部及び下部にそれぞれ示される。ノースバウンドインターフェースは、通常、より高レベルの構成要素についてサウスバウンドインターフェースと通信し、また、その逆の通信を行う。本発明は、第１に、ネットワークブロックと、各ネットワークブロック内の個々のネットワークプリフィックス、ネットワーク、サブネットワーク、及びマイクロセグメントとの分布及び割り当て、関連する管理上の特性及び属性を管理して追跡するために使用され、また、サウスバウンドにおけるＳＤＮコントローラによって自律的に作られるネットワーク構成を読み出すために使用される、動的ネットワークプロビジョニング処理（ＤＮＰＰ）を含む。ネットワーク管理者及び他の情報技術者によってネットワーク、サブネットワーク、及びＩＰアドレスを手動で管理するように設計された従来のＩＰアドレス管理ソリューションとは異なり、本発明に係るＤＮＰＰは、環境において使用されるすべてのネットワークブロック及びそれらの既存の内容物を有して構成され、その後、それは、ネットワークブロック、ネットワークプリフィックス、ネットワーク、サブネットワーク、マイクロセグメントなどを、ノースバウンドにおけるサービスオーケストレータと、サウスバウンドにおけるＳＤＮコントローラとに対して自動的に割り当て及び／又は解放することができ、オプションで、ノースバウンド及びサウスバウンドのいずれかにおいて生じた変化を、逆の側における１つ又は複数のオーケストレータ及び／又は１つ又は複数のコントローラに対して調停する。
【００３２】
従って、ＤＮＰＰは、そのノースバウンドの側において作業負荷（ネットワークホスト）をセットアップし、そのサウスバウンドの側においてネットワークインフラストラクチャ（ＳＤＮコントローラを含む）をセットアップするオーケストレータを有する。技術的に、ここでの違いは、ノースバウンドの統合において、ＤＮＰＰがＡＰＩ及び業務ロジックを有する技術であり、また、クライアントがオーケストレータに位置しているということにある。サウスバウンドの統合（ＳＤＮなど）では、ＤＮＰＰは、クライアント及び業務ロジックを有し、また、ＡＰＩはＳＤＮコントローラ（又はＳＤ−ＷＡＮ）によって提供される。その考え方はスタックとして可視化することができ、ここで、下方へ接続する各レイヤは、「サウスバウンド」の側にあるＡＰＩに接続されたクライアントを有するものである。
【００３３】
ＩＰＣＤＳはＡＰＩ及び業務ロジックを含む。クライアントは常にオーケストレータにある。ＤＮＰＰは、ＡＰＩ、業務ロジック、及びクライアントを含む。このＡＰＩは、ＤＮＰＰがオーケストレータに（広義の）ネットワークを配るときに使用され、この場合、クライアントはオーケストレータにある。しかし、（再び広義の）ネットワークをＳＤＮコントローラ又はＳＤ−ＷＡＮにプッシュするためには、われわれは、われわれの装置にあるクライアントを実際には使用し、ＳＤＮ又はＳＤ−ＷＡＮ（又はクラウドスタック）によって提供されるＡＰＩを用いる。
【００３４】
本発明の特徴のうちの１つは、エラスティックネットワーク環境において実行されるネットワーク、サブネットワーク、又はマイクロセグメントが、その存在を停止するか、もう１つのエラスティックネットワーク環境に移動される状況に関する。このことは、ネットワークが、オンデマンドのリソースとして取り扱われ、必要に応じて自動的に起動及び再起動される次世代ネットワーク環境において可能である。従来技術では、どのネットワークリソースが使用中であるか、また、どれが単に割り当てられたものの非使用であるかについての正確な情報が欠如していることは、ネットワークリソースの割り当て及び解放のまわりで自動化されたサービスワークフローを作成することを不可能にする。本発明において、オーケストレーションシステムにおいて動作中のクライアントは、ネットワークが委任解除されようとするときにＤＮＰＰに通知してもよく、又は、場合に応じて、もう１つのエラスティックネットワーク環境又はＳＤＮコントローラに対してマイグレーションされる。代替として、解放されたネットワークリソースについての情報は、統合されたＳＤＮコントローラの構成からそれを読み出すことで取得されてもよい。この情報の結果、本発明に係るＤＮＰＰ処理は、もはや存在しないネットワークに以前に割り当てられていたリソース、例えばネットワークプリフィックスを自動的に解放する。本発明のＤＮＰＰは、上記システムがネットワークを非活性化しているか移もう１つの環境へマイグレーションしている場合、オーケストレーションシステム及び／又は統合されたＳＤＮコントローラと通信する。クライアント・サーバアーキテクチャの使用は、与えられたネットワークリソースが何かのために実際に使用中であるか否かに関するリアルタイム情報を本発明に係るＤＮＰＰ処理が取得しうるという利点を提供する。
【００３５】
本発明は、ＡＰＩに基づくアーキテクチャを利用するオーケストレーションされた計算環境であって、オーケストレーションシステム及び／又はＳＤＮコントローラによって管理された起動及び／又は終了処理の一部として実行されるべきである環境に関する。
【００３６】
ＤＮＰＰ処理は、ＤＮＰＰ処理において／によって管理されたデータにアクセスするために使用可能である、ウェブに基づくユーザインターフェースのようなリモートユーザインターフェースさらにを備える。リモートユーザインターフェースは、ほとんどリアルタイムで、ネットワークブロックの割り当て及び使用レベルを追跡する能力を提供する。他の望ましい特徴は、管理者がこれらのレベルをリアルタイムで透明にモニタリングする能力と、内部及び／又は外部エンドユーザによって使用されるネットワークブロックへの制限されたアクセス権／閲覧権を彼らに提供する可能性を含む、マルチテナント環境をサポートすることと、選択された属性又は特性をネットワークブロックにタグ付けすることでネットワークブロックを管理する能力とを含む。最後の部分が重要である理由は、正しいネットワークブロックからネットワークプリフィックス、ネットワーク、サブネットワーク、マイクロセグメントなどを割り当てるために、クライアントのコールに存在する１つ又は複数の固有の識別子でネットワークブロックにタグ付けしなければならないということにある。また、これらすべてを管理するために、多くの管理ユーザにとってはグラフィカルユーザインターフェース（ＧＵＩ）が好ましい。
【００３７】
ＤＮＰＰ処理はさらに、サービス指向アーキテクチャ（ＳＯＡ）を備え、また、ＡＰＩを介して受信されたコールに基づいて、ネットワークブロック、ネットワークプリフィックス、ネットワーク、サブネットワーク、又はマイクロセグメントのようなネットワークリソースを動的に割り当て及び解放することができる第１のロジックとをサポートするアプリケーションプログラミングインターフェース（ＡＰＩ）を備える。
【００３８】
ＤＮＰＰ処理は、与えられた顧客を個々のネットワークブロック及び／又はネットワークプリフィックスに関連付けるように構成された第２のロジックをさらに備え、また、ネットワークブロック及び／又は割り当てられたネットワークプリフィックスに空きがない場合、ＤＮＰＰ処理は、顧客を有する代替のネットワークブロックから、及び／又は、ネットワークリソースの予約プールから自動的にネットワークリソース（例えばネットワークプリフィックス）のプロビジョニングを行うように構成される。
【００３９】
またさらに、ＤＮＰＰ処理は、ＳＯＡに基づくＡＰＩを介してＤＮＰＰ処理と通信するオーケストレーションソリューションにおいて実行されるクライアントを含む、クライアント・サーバアーキテクチャを備える。代替の実施形態では、ＤＮＰＰは１つ又は複数のクライアントソフトウェア実装も含み、それによってＤＮＰＰ（クライアント）及びＳＤＮコントローラ（サーバ）の間でクライアント・サーバアーキテクチャが構成される。
【００４０】
クライアントについては、クライアントは、新たなネットワークがオーケストレーションソリューションによってデプロイされる場合、ネットワークブロック、ネットワークプリフィックス、ネットワーク、サブネットワーク、又はマイクロセグメントなどのネットワークリソースをＤＮＰＰ処理に要求するクライアントロジックを備える。ＤＮＰＰにおいてオプションの実施形態が実装された場合、ＤＮＰＰにおいて実装されたクライアントは、オーケストレータに割り当てられたネットワークリソースをピックアップし、同じネットワークリソースを、起動のために、統合されたＳＤＮコントローラに送る。代替として、ＤＮＰＰにおいて実装されたクライアントは、上記処理におけるいかなるオーケストレータを関与させることなく、ＤＮＰＰ処理からネットワークリソースをピックアップし、ネットワークリソースを、起動のために、統合されたＳＤＮコントローラに送ってもよい。
【００４１】
動的ネットワークプロビジョニング処理（「ＤＮＰＰ」）ロジックは、グラフィカルユーザインターフェース（ＧＵＩ）、コマンドラインインタフェース（ＣＬＩ）、及び／又はアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアクセス可能であり、ＡＰＩを介してサービスオーケストレータのようなサードパーティーシステムによって生成されたコールを介して適切なネットワークプリフィックスに自動的に割り当てるために使用されてもよい。
【００４２】
ＤＮＰＰは、サードパーティーのオーケストレータへのネットワーク定義のプロビジョニングを行うために使用される場合、スタンドアロン装置（サーバ）として実装されてもよい。ここで使用されるように、ネットワーク定義は、複数のネットワークのどれが意味されるか定義する情報（パラメータの集合）を意味する。ネットワーク定義の例示的なリストは、空きネットワークプリフィックス、サブネットワーク、ネットワークマスク（ネットマスク）などを含む。ＤＮＰＰがサーバとして実装される場合、それは動的ネットワークプロビジョニングサーバ又は「ＤＮＰＰサーバ」と呼ばれてもよい。ほとんどの場合において、ＤＮＰＰ及びＤＮＰＰサーバは交換可能である。
【００４３】
ＤＮＰＰは、そのような空きのネットワーク定義を、各管理されたネットワークブロックに関連付けられたテナント及び／又は顧客名を含むがこれらに限定されない固有の識別子に基づいて検索する。次いで、ＤＮＰＰは、システムに含まれる計算ツールを用いて、要求又は構成されたサイズのネットワークリソースを保存し、使用例に依存して、予約されたネットワークリソースをオーケストレータに単に返すか、又は、予約されたネットワークリソースをオーケストレータに返し、それを、サービス及び／又はネットワークの起動のために、統合されたＳＤＮコントローラ（ＳＤＮＣ）又はＳＤ−ＷＡＮコントローラ（ＳＤＷＡＮＣ）によって提供されるインターフェースを介してＳＤＮＣ及び／又はＳＤＷＡＮＣにプッシュする。
【００４４】
さらに、いったんネットワークリソースがＳＤＮＣ及び／又はＳＤＷＡＮＣにプッシュされると、ＤＮＰＰは、自動的に構成されたネットワークパラメータと、ＳＤＮＣ及び／又はＳＤＷＡＮＣによって提供されるインターフェースを介して利用可能な他の情報とについて、統合されたＳＤＮＣ及び／又はＳＤＷＡＮＣのポーリングを開始する。
ネットワークパラメータ及び他の情報が発見されたとき、ＤＮＰＰはこの情報を検索し、それを後の使用のために装置に格納する。
そのようなデータの使用は、自動的に構成されたデータの閲覧及び管理と、サードパーティーオーケストレータへの格納されたデータのプロビジョニングとを適宜に含むが、それらに限定されない。
【００４５】
さらに、検索されたデータがネットワークパラメータのプロビジョニングのために使用される場合、ロジックは特許文献１と組み合わせてもよく、この特許文献に開示されるように、サードパーティーオーケストレータへのプロビジョニングを行ってもよい。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施形態に係るクライアント・サーバアーキテクチャのブロックレベル図である。
【図２Ａ】オーケストレーションシステムからのネットワーク要求を処理する間における、動的ネットワークプロビジョニング処理（ＤＮＰＰ）サーバの動作を示すフローチャートである。
【図２Ｂ】オーケストレーションシステムからのネットワーク要求を処理する間における、動的ネットワークプロビジョニング処理（ＤＮＰＰ）サーバの動作を示すフローチャートである。
【図３】組み合わされた動的ネットワークプロビジョニング（ＤＮＰ）サーバ及びＩＰ委任／委任解除（ＩＰＣＤ）サーバのブロックレベル図である。
【図４Ａ】本発明の実施形態に係るＩＰＣＤサーバの動作を示すフローチャートである。
【図４Ｂ】本発明の実施形態に係るＩＰＣＤサーバの動作を示すフローチャートである。
【図５】動的ネットワークプロビジョニング処理（ＤＮＰＰ）の様々なオプションの特徴を示すフローチャートである。
【図６】様々なサーバ及び／又はクライアントコンピュータの例示的なブロック図を概略的に示す。
【発明を実施するための形態】
【００４７】
以下では、本発明は、添付の図面を参照して特定の実施形態によってより詳しく説明される。
【００４８】
図１は、本発明の実施形態に係るクライアント・サーバアーキテクチャのブロックレベル図である。参照符号ＤＮＰＳは動的ネットワークプロビジョニングサーバ（dynamic network provisioning server）を示し、それは上述の動的ネットワークプロビジョニング処理（ＤＮＰＰ）を実施する。参照符号ＵＩはユーザインターフェース（user interface）を示し、それは好ましくは、ウェブに基づくユーザインターフェースのようなリモートユーザインターフェースである。ユーザインターフェースは、ＤＮＰＳサーバがデータベースＤＢにおいて管理するデータにアクセスするために使用可能である。参照符号ＮＭＥはネットワーク管理エンジン（network management engine）を示し、それは、ネットワークの委任／委任解除と、オプションで、管理されたネットワークにおけるＩＰリソースの委任／委任解除とに関する様々な管理ロジックを実装する。
【００４９】
図１は、ネットワークの動的な委任／委任解除のための２つの並列機構を有する野心的な実施形態を示す。図１の左側において、ネットワーク管理エンジンＮＭＥの下方は、１つ又は複数のオーケストレータ（オーケストレーションソリューションを実行するサーバ）を利用する実装に関する。参照符号ＡＰＩは、オーケストレータＯＳにおけるクライアント（クライアントコネクタ）へのサービス指向アーキテクチャ（ＳＯＡ）をサポートするネットワーク管理エンジンＮＭＥにおけるアプリケーションプログラミングインターフェース（application programming interface）を示す。図１の右側において、ネットワーク管理エンジンＮＭＥの下方は、１つ又は複数のソフトウェアで定義されたネットワーキングコントローラ（Software-Defined Networking Controller）ＳＤＮＣを利用する実装に関する。ＳＤＮＣに基づく実装では、ネットワーク管理エンジンＮＭＥはクライアントコネクタ（client connector）ＣＬＣを有し、それは、ＳＤＮ−ＡＰＩにより示す、ＳＤＮコントローラにおけるアプリケーションプログラミングインターフェースに接続される。本開示に係るネットワーク管理エンジンＮＭＥの実施形態は、ＳＯＡに基づく実装及びＳＤＮに基づく実装のいずれか又は両方を実施することができる。
【００５０】
ネットワーク管理エンジンＮＭＥによって実装されたロジックは、アプリケーションプログラミングインターフェースＡＰＩ及び／又はクライアントコネクタＣＬＣを介して受信された要求に基づいて、ネットワークブロック、ネットワークプリフィックス、ネットワーク、サブネットワーク、又はマイクロセグメントのようなネットワークリソースの動的な割り当て及び解放を行う。ネットワーク管理エンジンＮＭＥは、与えられた顧客を個々のネットワークブロック及び／又はネットワークプリフィックスにさらに関連付け、また、ネットワークブロック及び／又は割り当てられたネットワークプリフィックスに空きがない場合、顧客を有する代替のネットワークブロックから、及び／又は、ネットワークリソースの予約プールから自動的にネットワークリソース（例えばネットワークプリフィックス）のプロビジョニングを行う。
【００５１】
ＳＯＡに基づく実装では、参照符号ＣＬは、クライアント・サーバアーキテクチャのクライアントコンピュータ（client computer）を示す。クライアントコンピュータＣＬは、ＳＯＡに基づくアプリケーションプログラミングインターフェースＡＰＩを介してＤＮＰＳサーバと通信するオーケストレーションソリューションＯＳにおいて、又は、そのようなオーケストレーションソリューションＯＳに関連して動作する。オーケストレーションソリューションＯＳは多数のサーバインスタンス（server instance）ＳＩをサポートする。典型的な実施例では、サーバインスタンスＳＩは、所定の作業負荷をそれぞれ有する仮想マシン（virtual machine）ＶＭである。ＤＮＰＰサーバは、オーケストレーションシステム（orchestration system）（オーケストレータ）ＯＳとは別個のサーバとして示されるが、一体化された実装もまた同様に可能である。ＳＤＮに基づく実装は、ＳＯＡに基づくものと同様に動作する。１つの物理的実施形態においていずれか又は両方の技術を実装可能である。
【００５２】
図２は、部分の図２Ａ及び図２Ｂからなり、オーケストレーションシステムＯＳからのネットワーク要求を処理する間における、ＤＮＰＰ処理の実施形態における詳細な処理ステップを示すフローチャートである。図２のために、ＤＮＰ処理（「ＤＮＰＰ」）及びＤＮＰサーバ（「ＤＮＰＳ」）は交換可能である。「サーバ」は専用サーバを意味するが、一方、「処理」は、分散型サーバ及び／又は他の目的で使用されるサーバのような他の実装により機能が提供されてもよいことを意味する。
【００５３】
ステップ２−２において、オーケストレーションシステムＯＳはネットワーク要求を送り、それはＤＮＰＰによって受信される。ステップ２−４において、ＤＮＰＰは、ネットワーク要求がテナント／顧客の名前を含むか否かをチェックする。ＹＥＳのとき、処理はステップ２−１０に進み、ここで、ＤＮＰＰは、テナント／顧客の名前がネットワークブロックにタグ付けされているか否かをチェックする。ＹＥＳのとき、処理はステップ２−１０に進み、ここで、ＤＮＰＰは、要求がＩＰアドレス又はビットマスクを含むか否かをチェックする。ＹＥＳのとき、ステップ２−２０において、ＤＮＰＰは、テナント／顧客の名前がタグ付けられたネットワークブロックにおいて要求されたネットワーク及び／又はビットマスクが利用可能であるか否かをチェックする。すべてのチェック２−４、２−１０、２−１６、及び２−２０の結果がＹＥＳである場合、ＤＮＰＰはステップ２−２４に進み、ここで、テナント／顧客にマークされたネットワークブロックから要求されたネットワークを予約し、それをオーケストレータに返す。
【００５４】
チェック２−１６が否定の結果を返す場合、ステップ２−１８において、ＤＮＰＰは、デフォルトビットマスクがＤＮＰＰに構成されているか否かをチェックする。ＹＥＳのとき、処理はステップ２−２２に進み、ここでテナント／顧客の名前がタグ付けられたネットワークブロックにおいてデフォルトビットマスクが利用可能であるか否かをチェックする。ＹＥＳのとき、処理は上述のステップ２−２４に進む。
【００５５】
ここで説明されているロジックは、ネットワークがまずは顧客（テナント）の名前に基づいて割り当てられ、顧客（テナント）の名前がネットワークブロックに、又はおそらくはその下の与えられたプリフィックスにタグ付けされるという観点に基づく。テナントの名前も顧客の名前も存在しない場合、第２の可能性は、オーケストレータが、ａ）与えられたネットワークブロックからの特定のプリフィックス（これはＩＰ／ビットマスク、例えば、１２３．１２３．１２３．１２３／２８とて書かれる）を要求するか、又は、ｂ）特定のビットマスク（例えば単に／２８）を要求することである。ａ）もｂ）も当てはまらない場合、デフォルトサイズを有するネットワークがパブリックなブロック／プリフィックスから到来する可能性があり、ここでは、割り当てが重複しないということのみが要件である。特定のビットマスクサイズが要求される（しかしその前のＩＰアドレスは存在しない）場合、割り当ては、おそらくは、パブリックなブロック／プリフィックスからの適切なサイズを有するネットワークになる。ここでの別の仮定は、要求がＩＰアドレス／プリフィックスを含む場合、それがプライベートなブロック又はパブリックなブロックのいずれかから到来する可能性があるということである。それが単にプリフィックス（ＩＰアドレスなし）である場合、論理的には、デフォルトでパブリックなブロックになる。
【００５６】
チェック２−４及び２−１０のいずれかが否定の結果を返す場合、処理はステップ２−６に進み、ここで、ＤＮＰＰは、要求がＩＰアドレス又はビットマスクを含むか否かをチェックする。ＹＥＳのとき、ステップ２−１２において、ＤＮＰＰは、要求されたビットマップサイズの要求されたネットワーク及び／又はパブリックなネットワークが利用可能であるか否かをチェックする。ＹＥＳのとき、ステップ２−２６において、ＤＮＰＰは、要求されたネットワークを予約し、それをオーケストレータに返す。チェック２−６が否定の結果を返す場合、ステップ２−８において、ＤＮＰＰは、デフォルトビットマスクがＤＮＰＰに構成されているか否かをチェックする。ＹＥＳのとき、処理はステップ２−１４に進み、デフォルトビットマスクサイズを有するネットワークが１つ又は複数のパブリックブロックにおいて利用可能であるか否かをチェックする。ＹＥＳのとき、ステップ２−２６において、ＤＮＰＰは、要求されたネットワークを予約し、それをオーケストレータに返す。
【００５７】
チェック２−８、２−１２、２−１４、２−１８、２−２０、及び２−２２のうちのどれかが否定の結果を返す場合、処理はステップ２−３０、２−３２、２−３４、及び２−３６のうちの１つに進み、エラー状態を返す。図２のフローチャートは、すべてのエラー表示について同一の説明を示すが、詳細なエラー状態及び表示は異なってもよい。
【００５８】
このように、図２は野心的な実施形態の動作を示し、ここで、ネットワーク管理エンジンＮＭＥは複数の方法（ステップ２−２０、２−２２、２−１２、及び２−１４に進む処理により示した）でネットワークを割り当てることができる。それほど野心的ではない実施形態は、これらの処理のうちの任意の部分集合を実装してもよい。
【００５９】
図３は、本発明の実施形態に係るクライアント・サーバアーキテクチャのブロックレベル図である。参照符号ＩＰＣＤＳは、ＩＰ委任／委任解除サーバ（IP Commissioning/Decommissioning server：ＩＰＣＤサーバ）を示す。参照符号ＵＩはユーザインターフェースを示し、それは好ましくは、ウェブに基づくユーザインターフェースのようなリモートユーザインターフェースである。ユーザインターフェースは、ＩＰＣＤＳサーバにおいて管理されたデータにアクセスするために使用可能である。参照符号ＡＰＩは、サービス指向アーキテクチャ（ＳＯＡ）をサポートするアプリケーションプログラミングインターフェースを示す。参照符号ＢＬは業務ロジック（business logic）を示し、それは、ＡＰＩを介して受信されたコールに基づいて、ＩＰアドレス、名前、及び他のネットワーク構成のようなＩＰリソースの動的な割り当て及び解放を行うことができる。本実施形態に係るＩＰＣＤＳサーバは２つの管理エンジンＭＥ１及びＭＥ２を備え、これらの管理エンジンは、第１のロジック及び第２のロジックにそれぞれ対応し、また、与えられたエンドユーザを個々のネットワークに関連付けるようにまとめて構成される。また、ネットワークの全体が割り当てられた場合、ＩＰＣＤＳサーバは、内部及び／又は外部のエンドユーザに関連付けられた代替のネットワークから、及び／又は、ＩＰリソースの予約プールから、ＩＰリソース（例えばＩＰアドレス）のプロビジョニングを自動的に行うように構成される。
【００６０】
参照符号ＣＬは、本発明に係るクライアント・サーバアーキテクチャのクライアントコンピュータを示す。クライアントコンピュータＣＬは、ＳＯＡに基づくアプリケーションプログラミングインターフェースＡＰＩを介してＩＰＣＤＳサーバと通信するオーケストレーションソリューションＯＳにおいて、又は、そのようなオーケストレーションソリューションＯＳに関連して動作する。オーケストレーションソリューションＯＳは多数のサーバインスタンスＳＩをサポートする。典型的な実施例では、サーバインスタンスＳＩは、所定の作業負荷をそれぞれ有する仮想マシンである。
【００６１】
図４は、部分の図４Ａ及び図４Ｂからなり、本発明の実施形態に係るＩＰＣＤＳサーバの動作を示すフローチャートである。ステップ４−２において、オーケストレーションシステムは、ホストがデプロイされるべき仮想ローカルエリアネットワーク（virtual local-area network）ＶＬＡＮを識別する要求を、ＩＰＣＤＳサーバに送信する。ステップ４−４において、ＩＰＣＤＳサーバは、ＶＬＡＮが、現在のＩＰＣＤシステムによって管理されたネットワークにタグ付けされているか否かを調べる。ＮＯのとき、フローはステップ４−４６（図面２Ｂを参照）に進み、ここで、ＩＰＣＤサーバは、エラーの原因を示すエラーメッセージを返す。ステップ４−４において結果が肯定である場合、フローはステップ４−６に進み、ここで、ＩＰＣＤサーバは、ＩＰアドレスの発行が要求の一部であったか否かを調べる。ＹＥＳのとき、フローはステップ４−１４に進み、ここで、ＩＰＣＤサーバは、ＶＬＡＮに関連付けられた第１のネットワークにおいて空きのＩＰアドレスが利用可能であるか否かを調べる。ＹＥＳのとき、フローはステップ４−２０に進み、ここで、ＩＰＣＤサーバは、名前の発行が要求の一部であったか否かを調べる。ＹＥＳであったとき、フローはステップ４−３０に進み、ここで、ＩＰＣＤサーバは、空きのＩＰアドレスを予約し、ＶＬＡＮに関連付けられたネットワークに構成されたデフォルトゾーンにそれを結びつける固有名を生成する。次いで、ＩＰＣＤサーバは、固有名及びＩＰアドレスをオーケストレーションシステムＯＳに返し、ＩＰアドレスを割り当て元のネットワークにおいて使用中のものとしてマークする。ステップ４−２０の結果が否定であったとき、フローはステップ４−３２に進み、ここで、ＩＰＣＤサーバは、空きのＩＰアドレスを予約し、それをオーケストレーションシステムＯＳに返し、ＩＰアドレスを割り当て元のネットワークにおいて使用中のものとしてマークする。
【００６２】
ステップ４−６の結果が否定である場合、フローはステップ４−８に進み、ここで、ＩＰＣＤサーバは、名前の発行が要求の一部であったか否かを調べる。ＹＥＳのとき、フローはステップ４−３８に進み、ここで、ＩＰＣＤサーバは、ＶＬＡＮに関連付けられたネットワークに構成されたデフォルトゾーンにそれを結びつける自動的に生成された名前を返し、固有名をオーケストレーションシステムＯＳに返す。ステップ４−８の結果が否定である場合、フローはステップ４−１０に進み、ここで、ＩＰＣＤサーバは、ＩＰアドレスの解放が要求の一部であったか否かを調べる。ＹＥＳのとき、フローはステップ４−１８に進み、ここで、ＩＰＣＤサーバは、使用中の名前の解放が要求の一部であったか否かを調べる。ＹＥＳのとき、フローはステップ４−４０に進み、ここで、ＩＰＣＤサーバは、関連付けられたＶＬＡＮに一致するネットワークから使用中の名前及びＩＰアドレスを解放し、確認をオーケストレーションシステムＯＳに返す。ステップ４−１８の結果が否定であったとき、フローはステップ４−４２に進み、ここで、ＩＰＣＤサーバは、関連付けられたＶＬＡＮに一致するネットワークから使用中のＩＰアドレスを解放し、確認をオーケストレーションシステムに返す。
【００６３】
現在の例示において、ステップ４−１０の結果が否定であったとき、フローはステップ４−１２に進み、ここで、ＩＰＣＤサーバは、要求がＩＰＣＤサーバの機能のいずれにも関連しないことを認識し、エラーメッセージを返す。より多くの機能を有するより野心的な実装では、ステップ４−１２から右方への分枝がさらなるテスト及び機能に進んでもよい。
【００６４】
ステップ４−１４の結果が否定であったとき、フローはステップ４−１６に進み、ここで、ＩＰＣＤサーバは、他のネットワークが同じＶＬＡＮにタグ付けされているか否かを調べる。ＹＥＳのとき、フローはステップ４−２２に進み、ここで、ＩＰＣＤサーバは、他のネットワークにおいて空きのＩＰアドレスが利用可能であるか否かを調べる。ＹＥＳのとき、ステップ４−２４において、ＩＰＣＤサーバは、名前の発行が要求の一部であったか否かを調べる。ＹＥＳのとき、フローは上述のステップ４−３０に進む。ＮＯのとき、フローはステップ４−３４に進み、ここで、ＩＰＣＤサーバは、空きのＩＰアドレスをオーケストレーションシステムＯＳに返し、ＩＰアドレスを割り当て元のネットワークにおいて使用中のものとしてマークする。
【００６５】
ステップ４−１６又は４−２２の結果が否定であるとき、フローはステップ４−３６に進み、ここで、ＩＰＣＤサーバは、ＶＬＡＮに関連付けられたネットワークに構成されたデフォルトゾーンにそれを結びつける自動的に生成された名前を返し、固有名をオーケストレーションシステムＯＳに返す。
【００６６】
図５は、動的ネットワークプロビジョニング処理（ＤＮＰＰ）の様々なオプションの特徴を示すフローチャートである。ステップ５−２において、ＤＮＰＰサーバは、既存のネットワークブロックの内部において新たなネットワークを作成する。ステップ５−１０において、ＤＮＰＰサーバは、新たなネットワークの追加がオーケストレータによって開始されたか否かをチェックする。ＹＥＳのとき、フローはステップ５−２０に進む。ＮＯのとき、フローはステップ５−２２に進む。ステップ５−２０において、ＤＮＰＰは、ネットワークがＳＤＮコントローラ又はＳＤ−ＷＡＮに追加されることをコールが要求したか否かをチェックする。ＹＥＳのとき、フローはステップ５−２２に進み、ここで、ＤＮＰＰは、ユーザがこのネットワークを担当するＳＤＮ／ＳＤ−ＷＡＮコントローラを手動で指定したか否かをチェックする。
【００６７】
チェック５−２０の結果が否定であるとき、フローはステップ５−３０に進み、ここで、ＤＮＰＰは、このネットワークについてモニタリングされるべき、担当するＳＤＮコントローラ又はＳＤ−ＷＡＮをコールが指定したか否かをチェックする。ＹＥＳのとき、フローはステップ５−４０に進み、ここで、ＤＮＰＰは、ネットワークをＤＮＰＰにおいて予約されたものとしてマークし、それをオーケストレータに返す。 それはまた、新たなネットワークのための指定されたＳＤＮコントローラ／ＳＤ−ＷＡＮのモニタリングをそのＡＰＩを用いて開始し、ＳＤＮコントローラ／ＳＤ−ＷＡＮによって作成及び/又は生成された構成を一定間隔でＤＮＰＰにおける一致するネットワークに戻して同期させる。
【００６８】
チェック５−３０の結果が否定であるとき、フローはステップ５−４２に進み、ここで、ＤＮＰＰは、ネットワークをＤＮＰＰにおいて予約されたものとしてマークし、それをオーケストレータに返す。このように、ステップ５−４０のＳＤＮに関連したモニタリング及び同期化の態様を省略する。
【００６９】
チェック５−２２の結果が肯定であり、ネットワークを担当するＳＤＮ／ＳＤ−ＷＡＮコントローラをユーザが手動で指定したとき、フローはステップ５−４４に進み、ここで、ＤＮＰＰは、新たなネットワークを指定されたＳＤＮコントローラ／ＳＤ−ＷＡＮにそのＡＰＩを用いて追加する。いったん構成されると、ＤＮＰＰは、ＳＤＮコントローラ／ＳＤ−ＷＡＮによって生成された構成を一定間隔で読み出し、それらをＤＮＰＰに戻して同期させる。
【００７０】
チェック５−２２の結果が否定であるとき、フローはステップ５−３２に進み、ここで、ＤＮＰＰは、ネットワークブロックに関連付けられたデフォルトＳＤＮコントローラが存在するか否かをチェックする。ＹＥＳのとき、フローはステップ５−４６に進み、ここで、ＤＮＰＰは、新たなネットワークをデフォルトＳＤＮコントローラ／ＳＤ−ＷＡＮにそのＡＰＩを用いて追加する。 いったん追加されると、ＤＮＰＰは、ＳＤＮコントローラ／ＳＤ−ＷＡＮによって作成又は実現された構成を一定間隔で読み出し、それらをＤＮＰＰにおける一致するネットワークに戻して同期させる。最後に、チェック５−３２の結果が否定であるとき、フローはステップ５−４８に進み、ここで、ＤＮＰＰは、新たなネットワークをＤＮＰＰにおいて予約されたものとしてマークする。
【００７１】
図６は、様々な情報処理構成要素の例示的なブロック図を概略的に示す。参照符号６−１００によって概して示す、図６に示すデータ処理アーキテクチャは、本発明のサーバ及びクライアントを実装するために使用可能である。サーバに適した構成を示すが、クライアントコンピュータの構成はより簡単であってもよい。データ処理アーキテクチャの２つの主要な機能ブロックは、処理システム６−１００及び記憶システム６−１９０である。処理システム６−１００は、参照符号６−１１０によって概して示す、１つ又は複数の中央処理装置ＣＰ１…ＣＰｎを備える。処理装置は、ネイティブの処理装置であってもよく、仮想処理装置であってもよい。複数の処理装置６−１１０を備える実施形態には、好ましくは、複数の処理装置６−１１０の間の処理負荷をバランスさせる負荷分散装置６−１１５が提供される。複数の処理装置６−１１０は、別個のプロセッサ構成要素として実装されてもよく、又は、単一の構成要素の場合に複数の物理プロセッサコアもしくは複数の仮想プロセッサとして実装されてもよい。処理システム６−１００は、参照符号ＤＮによって概して示される様々なデータネットワーク（data network）と通信するためのネットワークインターフェース６−１２０をさらに備える。データネットワークＤＮは、イーサネット（登録商標）ネットワークのようなローカルエリアネットワーク、及び／又は、インターネットのようなワイドエリアネットワークを含んでもよい。参照符号６−１２５は移動体ネットワークインターフェースを示し、これを介して、処理システム６−１００は、無線ネットワークノードとして動作する様々なアクセスネットワーク（access network）ＡＮと通信してもよい。複数の異なるネットワークをサポートする構成は、処理システム６−１００が、地上に基づく端末６−２００及び移動体端末６−２１０のような複数のタイプのクライアントをサポートすることを可能にする。
【００７２】
本実施形態の処理システム６−１００は、ローカルユーザインターフェース６−１４０を備えてもよい。実装に依存して、ユーザインターフェース６−１４０は、キーボード、マウス、及びディスプレイ（図示せず）のようなローカルユーザインターフェースのためのローカル入出力回路を備えてもよい。代替又は追加として、処理システム６−１００の管理は、ネットワークインターフェース６−１２０と、ユーザインターフェースを提供するインターネット接続機能を有する任意の端末とを利用することで、遠隔に実施されてもよい。ユーザインターフェースの性質は、処理システム６−１００を実装するためにどの種類のコンピュータが使用されるかに依存する。処理システム６−１００が専用コンピュータである場合、それはローカルユーザインターフェースを必要としなくてもよく、処理システム６−１００は、例えば、ウェブブラウザからインターネットを介して、遠隔に管理されてもよい。そのような遠隔の管理は、コンピュータがそれ自体とクライアント端末との間のトラフィックのために利用するものと同じネットワークインターフェース６−１２０を介して達成されてもよい。
【００７３】
処理システム６−１００はまた、プログラム命令、動作パラメータ、及び変数を格納するためのメモリ６−１５０を備える。参照符号６−１６０は、処理システム６−１００のためのプログラムスイートを示す。
【００７４】
処理システム６−１００はまた、様々なクロック、割り込みなどのための回路を備え、これらは概して参照符号６−１３０によって示される。処理システム６−１００はまた、記憶システム６−１９０への記憶インターフェース６−１４５を備える。処理システム６−１００がオフされるとき、記憶システム６−１９０は処理機能を実装するソフトウェアを格納してもよく、電源をオンするとき、ソフトウェアは半導体メモリー６−１５０へ読み出される。記憶システム６−１９０はまた、パワーオフ期間にわたって動作し続け、変数を保持する。大規模な実装、すなわち、単一の処理システム６−１００が各移動体端末（mobile terminal）ＭＴを介して多数のクライアントにサービスを提供する実装では、記憶システム６−１９０は、クライアント及び移動体端末ＭＴに関連付けられた動的な対話マトリクスを格納するために使用されてもよい。様々な構成要素６−１１０〜６−１５０は、当業者に周知のアドレス信号、データ信号、及び制御信号を伝送するバス６−１０５を介して、相互に通信する。」
【００７５】
技術の進歩に応じて本発明の概念を様々な方法で実装可能であることは、当業者には明らかである。本発明及びその実施形態は上述した例示に限定されず、特許請求の範囲内で変化してもよい。
【図１】
2019506095.tif 000003
【図２Ａ】
2019506095.tif 000004
【図２Ｂ】
2019506095.tif 000005
【図３】
2019506095.tif 000006
【図４Ａ】
2019506095.tif 000007
【図４Ｂ】
2019506095.tif 000008
【図５】
2019506095.tif 000009
【図６】
2019506095.tif 000010
【手続補正書】
【提出日】平成30年4月12日(2018.4.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サーバコンピュータは、アプリケーション及びデータを格納する少なくとも１つの処理装置を備える処理システムを備え、
上記サーバコンピュータは、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行い、
上記１つ又は複数のオーケストレーションソリューション及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムは、
上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、
１つ又は複数のオーケストレーションソリューションに対するサービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、
ネットワークの動的な割り当て及び解放を行い、上記ウェブに基づくアプリケーションプログラミングインターフェースを介して上記１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うネットワーク管理ロジックと
を実装するように上記処理システムに命令するプログラムコード命令を備える、
サーバコンピュータ。
【請求項２】
上記ネットワーク管理ロジックは、複数のネットワークブロックと、各ネットワークブロック内の個々のネットワークプリフィックス、ネットワーク、サブネットワーク、及びマイクロセグメントとの動的なり当て及び解放を行う、
請求項１記載のサーバコンピュータ。
【請求項３】
上記ネットワーク管理ロジックは、ネットワークに対する要求を処理し、以下の条件、すなわち、
上記要求が、ネットワークユーザにタグ付けされたネットワークブロック又はプリフィックスを指定することと、
上記サーバコンピュータが、上記ネットワークユーザにタグ付けされたネットワークブロックにおいて利用可能であるデフォルトビットマスクを構成していることと、
上記要求がＩＰアドレス又はビットマスクを示し、上記要求されたネットワーク及び／又は上記ＩＰアドレス又はビットマスクに対応するサイズのパブリックなネットワークが利用可能であることと、
上記サーバコンピュータがデフォルトビットマスクで構成され、上記デフォルトビットマスクに対応するサイズを有するネットワークが少なくとも１つのパブリックなネットワークブロックにおいて利用可能であることと
のうちの少なくとも１つが真である場合、上記要求されたネットワークをネットワークブロックから割り当てる、
請求項１記載のサーバコンピュータ。
【請求項４】
上記オーケストレーションソリューションによってネットワークブロックの一部が管理されるように、ネットワークブロックを管理するように構成された、
請求項３記載のサーバコンピュータ。
【請求項５】
上記サーバコンピュータは、以前に割り当てられたネットワークがもはや使用されていないことを検出することに応答して、以前に割り当てられたネットワークを解放する、
請求項１記載のサーバコンピュータ。
【請求項６】
上記サーバコンピュータは、上記以前に割り当てられたネットワークの実際の使用を追跡することにより上記検出を行う、
請求項５記載のサーバコンピュータ。
【請求項７】
上記処理システムは、
上記１つ又は複数のオーケストレーションソリューション及び上記ウェブに基づくアプリケーションプログラミングインターフェースを用いて、複数のホストに対するインターネットプロトコル「［ＩＰ」］リソースの動的な割り当て及び解放を行うことと、
互いに重複するアドレス空間を有する複数のネットワークの複数のノードである２つ以上のホストのそれぞれに対して、少なくとも１つの固有のＩＰリソースを作成することと、
上記少なくとも１つの固有のＩＰリソースが、上記２つ以上のホストのうちの各１つに係るプライベートネットワークの名前と、当該プライベートネットワーク内のＩＰアドレスとの組み合わせに基づくことと
を実施するように上記処理システムに命令するプログラムコード命令をさらに備える、
請求項１記載のサーバコンピュータ。
【請求項８】
サーバコンピュータは、アプリケーション及びデータを格納する少なくとも１つの処理装置を備える処理システムを備え、
上記サーバコンピュータは、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行い、
上記１つ又は複数のＳＤＮコントローラ及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムは、
上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラのリモート管理のためのユーザインターフェースと、
上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコネクタと、
１つ又は複数のＳＤＮコントローラによって上記ウェブに基づくクライアントコネクタを介して起動／終了されるようにネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックと
を実装するように上記処理システムに命令するプログラムコード命令を備える、
サーバコンピュータ。
【請求項９】
上記ネットワーク管理ロジックは、複数のネットワークブロックと、各ネットワークブロック内の個々のネットワークプリフィックス、ネットワーク、サブネットワーク、及びマイクロセグメントとの動的な割り当て及び解放を行う、
請求項８記載のサーバコンピュータ。
【請求項１０】
上記ネットワーク管理ロジックは、ネットワークに対する要求を処理し、以下の条件、すなわち、
上記要求が、ネットワークユーザにタグ付けされたネットワークブロック又はプリフィックスを指定することと、
上記サーバコンピュータが、上記ネットワークユーザにタグ付けされたネットワークブロックにおいて利用可能であるデフォルトビットマスクを構成していることと、
上記要求がＩＰアドレス又はビットマスクを示し、上記要求されたネットワーク及び／又は上記ＩＰアドレス又はビットマスクに対応するサイズのパブリックなネットワークが利用可能であることと、
上記サーバコンピュータがデフォルトビットマスクで構成され、上記デフォルトビットマスクに対応するサイズを有するネットワークが少なくとも１つのパブリックなネットワークブロックにおいて利用可能であることと
のうちの少なくとも１つが真である場合、上記要求されたネットワークをネットワークブロックから割り当てる、
請求項８記載のサーバコンピュータ。
【請求項１１】
上記ＳＤＮコントローラによってネットワークブロックの一部が管理されるように、ネットワークブロックを管理するように構成された、
請求項１０記載のサーバコンピュータ。
【請求項１２】
上記サーバコンピュータは、以前に割り当てられたネットワークがもはや使用されていないことを検出することに応答して、以前に割り当てられたネットワークを解放する、
請求項８記載のサーバコンピュータ。
【請求項１３】
上記サーバコンピュータは、上記以前に割り当てられたネットワークの実際の使用を追跡することにより上記検出を行う、
請求項１２記載のサーバコンピュータ。
【請求項１４】
上記処理システムは、
上記１つ又は複数のオーケストレーションソリューション及び上記ウェブに基づくアプリケーションプログラミングインターフェースを用いて、複数のホストに対するインターネットプロトコル「［ＩＰ」］リソースの動的な割り当て及び解放を行うことと、
互いに重複するアドレス空間を有する複数のネットワークの複数のノードである２つ以上のホストのそれぞれに対して、少なくとも１つの固有のＩＰリソースを作成することと
を実施するように上記処理システムに命令するプログラムコード命令をさらに備え、
上記少なくとも１つの固有のＩＰリソースは、上記２つ以上のホストのうちの各１つに係るプライベートネットワークの名前と、当該プライベートネットワーク内のＩＰアドレスとの組み合わせに基づく、
請求項８記載のサーバコンピュータ。
【請求項１５】
プログラムコード命令及びデータを格納する少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータを用いて、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うことを含み、
上記１つ又は複数のオーケストレーションソリューション及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムにおけるプログラムコード命令を実行することは、
上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、
１つ又は複数のオーケストレーションソリューションに対するサービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、
ネットワークの動的な割り当て及び解放を行い、上記ウェブに基づくアプリケーションプログラミングインターフェースを介して上記１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
方法。
【請求項１６】
プログラムコード命令及びデータを格納する少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータを用いて、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行うことを含み、
上記１つ又は複数のＳＤＮコントローラ及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムにおけるプログラムコード命令を実行することは、
上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラのリモート管理のためのユーザインターフェースと、
上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコネクタと、
１つ又は複数のＳＤＮコントローラによって上記ウェブに基づくクライアントコネクタを介して起動／終了されるようにネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
方法。
【請求項１７】
少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータにより、ネットワークに対して委任／委任解除を行い、１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うためのプログラムコード命令を格納するコンピュータ可読メモリであって、
上記１つ又は複数のオーケストレーションソリューション及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記コンピュータ可読メモリに格納されたプログラムコード命令を実行することは、
上記サーバコンピュータによって管理されたデータへのアクセスを提供する、上記サーバコンピュータの管理のためのユーザインターフェースと、
１つ又は複数のオーケストレーションソリューションに対するサービス指向アーキテクチャ「［ＳＯＡ］」をサポートする、ウェブに基づくアプリケーションプログラミングインターフェースと、
ネットワークの動的な割り当て及び解放を行い、上記ウェブに基づくアプリケーションプログラミングインターフェースを介して上記１つ又は複数のオーケストレーションソリューションに対して上記ネットワークのプロビジョニングを行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
コンピュータ可読メモリ。
【請求項１８】
少なくとも１つの処理装置を備える処理システムを有するサーバコンピュータにより、１つ又は複数のＳＤＮコントローラによって起動／終了されるようにネットワークに対して委任／委任解除を行うためのプログラムコード命令を格納するコンピュータ可読メモリであって、
上記１つ又は複数のＳＤＮコントローラ及び上記サーバコンピュータは、クライアント・サーバアーキテクチャを構成し、
上記処理システムにおけるプログラムコード命令を実行することは、
上記ＳＤＮコントローラによって管理されたデータへのアクセスを提供する、上記ＳＤＮコントローラの管理のためのユーザインターフェースと、
上記ＳＤＮコントローラのアプリケーションプログラミングインターフェースと通信する、ウェブに基づくクライアントコネクタと、
１つ又は複数のＳＤＮコントローラによって上記ウェブに基づくクライアントコネクタを介して起動／終了されるように、ネットワークの動的な割り当て及び解放を行うネットワーク管理ロジックと
を実装するように上記処理システムに命令する、
コンピュータ可読メモリ。
【国際調査報告】
2019506095.tif 000011
2019506095.tif 000012