JP2019213028A - サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム - Google Patents
サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム Download PDFInfo
- Publication number
- JP2019213028A JP2019213028A JP2018107042A JP2018107042A JP2019213028A JP 2019213028 A JP2019213028 A JP 2019213028A JP 2018107042 A JP2018107042 A JP 2018107042A JP 2018107042 A JP2018107042 A JP 2018107042A JP 2019213028 A JP2019213028 A JP 2019213028A
- Authority
- JP
- Japan
- Prior art keywords
- vnf
- service chain
- redundancy
- determination unit
- redundant
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- 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/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
-
- 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/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5045—Making service definitions prior to deployment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- 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/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby 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/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
- H04L41/0826—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for reduction of network costs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
- H04L45/128—Shortest path evaluation for finding disjoint paths
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Hardware Redundancy (AREA)
Abstract
【課題】サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計すること。【解決手段】サービスチェイン設計装置１は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ判定部１３が判定した冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する冗長化判定部３１とを有する。【選択図】図１
Description
本発明は、サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラムに関する。
システムに障害が発生するまえに予備の計算機をあらかじめ用意しておき、障害発生時には予備の計算機に処理を切り替える手法は、冗長化と呼ばれる。この冗長化により耐障害性に優れた信頼性の高いシステムを提供できる。サービスの信頼性を高める方法として、サービスの構成要素（経路、各種装置、アプリケーション等）を２重化するなどの冗長構成が採用される。
特許文献１には、ネットワーク全体を複数に分割したサブネットワーク内の冗長通信経路の設計をする際に、冗長化された複数の経路候補のうち、ファイバ重複、ノード重複、管路重複などのハードウェア資源を共用するような経路候補をなるべく用いない通信経路出力手段が記載されている。
特許文献１には、ネットワーク全体を複数に分割したサブネットワーク内の冗長通信経路の設計をする際に、冗長化された複数の経路候補のうち、ファイバ重複、ノード重複、管路重複などのハードウェア資源を共用するような経路候補をなるべく用いない通信経路出力手段が記載されている。
既存のネットワークサービスにおいて、各種ネットワーク機能は物理装置（アプライアンス）で提供されていた。そのため、ネットワーク機能の提供元となる物理装置が固定されてしまい、柔軟性に欠けていた。そこで、物理装置を用いて仮想装置（ＶＭ：Virtual Machine）を構築する仮想化技術を、ネットワーク資源にも適用する試みが普及しつつある。
ＮＦＶ（Network Function Virtualization）は、各種ネットワーク機能を仮想装置（ソフトウェア）で提供する仮想化技術である。仮想装置によりネットワーク機能の配置に柔軟性が生まれることで、ユーザごとの個別の要望に柔軟に対応することができる。
ＮＦＶ技術により仮想化されたネットワーク機能は、ＶＮＦ（Virtualized Network Function）と呼ばれる。ＶＮＦは、例えば、vCPE（Virtualized Customer Premises Equipment）、vRouter、vMitigator、vFW（Virtualized Firewall）、vLB（Virtualized Load Balancer）、vDPI（Virtualized deep packet inspection）である。
ＮＦＶ（Network Function Virtualization）は、各種ネットワーク機能を仮想装置（ソフトウェア）で提供する仮想化技術である。仮想装置によりネットワーク機能の配置に柔軟性が生まれることで、ユーザごとの個別の要望に柔軟に対応することができる。
ＮＦＶ技術により仮想化されたネットワーク機能は、ＶＮＦ（Virtualized Network Function）と呼ばれる。ＶＮＦは、例えば、vCPE（Virtualized Customer Premises Equipment）、vRouter、vMitigator、vFW（Virtualized Firewall）、vLB（Virtualized Load Balancer）、vDPI（Virtualized deep packet inspection）である。
ＶＮＦをユーザごとに柔軟に選択・利用可能とする技術を、サービスチェイニングという。サービスチェイニングによって提供される一連のサービスをサービスチェインという。
サービスチェインによって、専用アプライアンスで提供されていたネットワーク機能を仮想化基盤上のソフトウェア（仮想マシン）群で実現することができる。つまり、NFV技術によって、ネットワーク機器をソフトウェアとハードウェアとに分離し、汎用サーバで構成された仮想化基盤上で実現したネットワーク機能群を、サービスチェイニングによって数珠つなぎにすることで1つのサービスとして提供する。
サービスチェインによって、専用アプライアンスで提供されていたネットワーク機能を仮想化基盤上のソフトウェア（仮想マシン）群で実現することができる。つまり、NFV技術によって、ネットワーク機器をソフトウェアとハードウェアとに分離し、汎用サーバで構成された仮想化基盤上で実現したネットワーク機能群を、サービスチェイニングによって数珠つなぎにすることで1つのサービスとして提供する。
図７は、サービスチェインの説明図である。
まず、物理資源のアプライアンスとして、各物理ノード［N1,…,N11］が、各物理リンク［L1,…,L14］で接続される物理的なネットワークシステムが構築されている。例えば、物理ノードN4と物理ノードN8とは、物理リンクL8で接続される。
この物理ノード上に仮想ノード［VM1,…,VM6］が形成され、その仮想ノード上でVNF［F1,…,F4］が動作しているとする。例えば、仮想ノードVM1上にはVNFのF1が動作している。
さらに、１つ以上のVNFは、サービスチェイン[A,B,C]によってそれぞれ束ねられている。ここで、各サービスチェインが利用するVNFには、アクセスが混んでいて負荷の高いVNFと、アクセスが空いていて負荷の低いVNFとでばらつきが発生する。以下、各サービスチェインが利用するVNFの詳細について、図８を参照して説明する。
まず、物理資源のアプライアンスとして、各物理ノード［N1,…,N11］が、各物理リンク［L1,…,L14］で接続される物理的なネットワークシステムが構築されている。例えば、物理ノードN4と物理ノードN8とは、物理リンクL8で接続される。
この物理ノード上に仮想ノード［VM1,…,VM6］が形成され、その仮想ノード上でVNF［F1,…,F4］が動作しているとする。例えば、仮想ノードVM1上にはVNFのF1が動作している。
さらに、１つ以上のVNFは、サービスチェイン[A,B,C]によってそれぞれ束ねられている。ここで、各サービスチェインが利用するVNFには、アクセスが混んでいて負荷の高いVNFと、アクセスが空いていて負荷の低いVNFとでばらつきが発生する。以下、各サービスチェインが利用するVNFの詳細について、図８を参照して説明する。
図８は、図７の物理的なネットワークシステム上に構築されたサービスチェインの詳細な説明図である。
符号１０９は、図７の各サービスチェイン[A,B,C]が始点から終点までに通過する物理資源、仮想資源を順に辿った経路を示す。
サービスチェインＡは、始点の物理ノードN1から、VM3上のVNF「F2」と、終点のVM5上のVNF「F3」とを利用する。
サービスチェインＢは、始点の物理ノードN1から、VM5上のVNF「F3」と、終点のVM1上のVNF「F1」とを利用する。
サービスチェインＣは、始点の物理ノードN3から、VM6上のVNF「F4」と、VM5上のVNF「F3」と、終点のVM3上のVNF「F2」とを利用する。
つまり、VNF「F3」は３つのサービスチェインＡ〜Ｃに使用され、VNF「F2」は２つのサービスチェインＡ，Ｃに使用され、VNF「F1」はサービスチェインＢだけに使用され、VNF「F4」はサービスチェインＣだけに使用される。
符号１０９は、図７の各サービスチェイン[A,B,C]が始点から終点までに通過する物理資源、仮想資源を順に辿った経路を示す。
サービスチェインＡは、始点の物理ノードN1から、VM3上のVNF「F2」と、終点のVM5上のVNF「F3」とを利用する。
サービスチェインＢは、始点の物理ノードN1から、VM5上のVNF「F3」と、終点のVM1上のVNF「F1」とを利用する。
サービスチェインＣは、始点の物理ノードN3から、VM6上のVNF「F4」と、VM5上のVNF「F3」と、終点のVM3上のVNF「F2」とを利用する。
つまり、VNF「F3」は３つのサービスチェインＡ〜Ｃに使用され、VNF「F2」は２つのサービスチェインＡ，Ｃに使用され、VNF「F1」はサービスチェインＢだけに使用され、VNF「F4」はサービスチェインＣだけに使用される。
また、テーブル２０９ａは、サービスチェインごとの収容ユーザ数を示すものであり、サービスチェインＡが最大の100人のユーザを収容している。そして、テーブル２０９ｂは、VNFIDで示されるVNFごとに着目したサービスチェインの状況を示す。符号１０９の説明で前記したように、VNF「F3」は３つのサービスチェインＡ〜Ｃに使用され（つまり、サービス数＝３）、これらのサービスチェインのユーザ数の総和（＝１８０）が最大なので、故障時の影響度が他のVNFよりも大きいものとなっている（図示ではハッチングで強調）。
ここで、ネットワークの冗長設計の話題に戻る。特許文献１などで示唆されているように、信頼性の観点では、ネットワークを複数の経路で冗長化するときには、なるべく多くの物理資源を用意することで、共通に用いる物理資源を少なくすることが好ましい。なぜなら、共通に用いる物理資源が障害によりダウンしてしまうと、その物理資源を用いる冗長経路の全てが同時に利用不可能となってしまい、障害発生後の切替対象から外れてしまうからである。
一方で、ネットワーク運営者の観点からは、ネットワークの冗長設計において、予備として用意する冗長化用の物理資源は、そのまま平常時には遊休資源となってしまうため、リソースの無駄使いになってしまう。よって、コストの観点では、なるべく冗長化用の物理資源が少ない方が好ましい。
以上、信頼性の観点と、コストの観点とを統合的に考えると、ネットワークの冗長設計においては、故障時の影響度が高い重要な箇所は手厚く冗長化を行うことで信頼性を確保しつつ、故障時の影響度が少ない箇所は冗長化の度合いを下げることでコストを節約するような、メリハリの取れたバランスのよい設計が求められる。
例えば、図７，図８のようなサービスチェインの構成では、故障時に多くのユーザに影響を与える（つまり、サービスを中断させてしまい、多くのユーザに待ち時間の不便を強いてしまう）VNF「F3」を他のVNFよりも優先して冗長化を手厚くすることが望ましい。
例えば、図７，図８のようなサービスチェインの構成では、故障時に多くのユーザに影響を与える（つまり、サービスを中断させてしまい、多くのユーザに待ち時間の不便を強いてしまう）VNF「F3」を他のVNFよりも優先して冗長化を手厚くすることが望ましい。
そこで、本発明は、サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することを、主な課題とする。
前記課題を解決するために、本発明のサービスチェイン設計装置は、以下の特徴を有する。
本発明は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする。
本発明は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする。
これにより、ＶＮＦを利用するサービスチェインの数や、ＶＮＦが収容するユーザの数という、直接的にサービスやユーザに影響するパラメータを重要度として冗長化対象ＶＮＦを選択することで、信頼性の高いサービスチェインの設計が可能となる。さらに、重要なＶＮＦを冗長化対象ＶＮＦとして絞り込むことで、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することができる。
本発明は、前記第１判定部が、前記サービスチェインの数、および、前記収容するユーザの数に加えて、サービスチェイン内におけるＶＮＦの位置がルートの後方であるほど高い重要度とする重み、および、サービスチェイン内における前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みの少なくとも１つをＶＮＦごとの重要度とすることを特徴とする。
これにより、ルートの後方であるほど高い重要度とする重みが選択された場合には、サービスチェインのルート後方になるほど冗長化されやすくなるので、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
また、前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みが選択された場合でも、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
また、前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みが選択された場合でも、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
本発明は、前記第１判定部が、前記サービスチェインの数、および、前記収容するユーザの数に加えて、前記ＶＮＦが提供するサービス内容の重み、および、サービスチェインが収容するユーザの重みのうちの少なくとも１つの重みをもとに、ＶＮＦごとの重要度を計算することを特徴とする。
これにより、サービス内容の重みやユーザの重みが選択された場合には、重要なサービスや重要なユーザをかかえるＶＮＦが優先的に冗長化されるので、ユーザの満足度を高めることができる。
本発明は、前記第２判定部が、ＶＮＦの性能値の測定データをもとに、前記冗長化対象ＶＮＦの重要度が所定閾値を超過したか否かを判定することを特徴とする。
これにより、変動するＶＮＦの負荷が高くなったＶＮＦが優先的に冗長化されるので、より実用的な信頼性設計が可能となる。
本発明は、前記サービスチェイン設計装置が、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部が、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする。
前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部が、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする。
これにより、複数のＶＮＦ間や、複数の冗長ルート間で重複するハードウェア資源を減らすことにより、１つのハードウェア資源が故障しても、生存するＶＮＦや生存する冗長ルートを多く確保し、信頼性の高い設計が可能となる。
本発明は、前記サービスチェイン設計装置が、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部が、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする。
前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部が、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする。
これにより、設定変更の対象となる装置が少なくなるため、業務が容易となり、当該設定変更による他サービスへの影響リスクも低減することができる。
本発明によれば、サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することができる。
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
図１は、サービスチェイン設計装置１の構成図である。
サービスチェイン設計装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
サービスチェイン設計装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
サービスチェイン設計装置１が扱うサービスチェインに含まれるＶＮＦについて、以下のように定義する。
まず、サービスチェイン設計装置１は、物理的なネットワークシステム上で動作する全ＶＮＦのうち、故障時に多くのユーザに影響を与える重要なＶＮＦを「冗長化対象ＶＮＦ」として指定する。例えば、図８のVNF「F3」は、冗長化対象ＶＮＦの一例である。
次に、サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」に対して所定の基準を満たしたときに、その冗長化対象ＶＮＦを実際に冗長化するＶＮＦ（以下「冗長化実行ＶＮＦ」）として決定する。つまり、「全ＶＮＦ→冗長化対象ＶＮＦ→冗長化実行ＶＮＦ」という段階を経て実際に冗長化するＶＮＦが決定される。換言すると、冗長化対象ＶＮＦに選出されただけでは、まだ実際に冗長化するＶＮＦか否かは未確定の状態である。
まず、サービスチェイン設計装置１は、物理的なネットワークシステム上で動作する全ＶＮＦのうち、故障時に多くのユーザに影響を与える重要なＶＮＦを「冗長化対象ＶＮＦ」として指定する。例えば、図８のVNF「F3」は、冗長化対象ＶＮＦの一例である。
次に、サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」に対して所定の基準を満たしたときに、その冗長化対象ＶＮＦを実際に冗長化するＶＮＦ（以下「冗長化実行ＶＮＦ」）として決定する。つまり、「全ＶＮＦ→冗長化対象ＶＮＦ→冗長化実行ＶＮＦ」という段階を経て実際に冗長化するＶＮＦが決定される。換言すると、冗長化対象ＶＮＦに選出されただけでは、まだ実際に冗長化するＶＮＦか否かは未確定の状態である。
サービスチェイン設計装置１は、各種データを格納するデータベースとして、ポリシー／閾値管理ＤＢ２１と、サービスチェイン構成情報ＤＢ２２と、収容情報管理ＤＢ２３と、性能値収集ＤＢ２４と、冗長化対象ＶＮＦ管理ＤＢ２５とを有する。
サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」を選出するための処理部として、サービスチェイン生成要求受付部１１と、サービスチェイン生成要求分解部１２と、冗長化対象ＶＮＦ判定部（第１判定部）１３と、冗長化対象ＶＮＦ決定部１４とを有する。
サービスチェイン設計装置１は、選出された「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」として決定するための処理部として、冗長化判定部（第２判定部）３１と、冗長化決定部３２と、冗長度計算部３３と、冗長度決定部３４と、ＶＮＦ配置決定部３５と、冗長ルート計算部３６と、冗長ルート決定部３７とを有する。
さらに、冗長ルート決定部３７は、決定された「冗長化実行ＶＮＦ」を実際に冗長化するために、サービスチェイン設計装置１外部のサービスチェインコントローラ要求受付部３８と接続される。
以下、図２，図３の具体例を元に、これらのサービスチェイン設計装置１の各構成要素を明らかにする。
サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」を選出するための処理部として、サービスチェイン生成要求受付部１１と、サービスチェイン生成要求分解部１２と、冗長化対象ＶＮＦ判定部（第１判定部）１３と、冗長化対象ＶＮＦ決定部１４とを有する。
サービスチェイン設計装置１は、選出された「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」として決定するための処理部として、冗長化判定部（第２判定部）３１と、冗長化決定部３２と、冗長度計算部３３と、冗長度決定部３４と、ＶＮＦ配置決定部３５と、冗長ルート計算部３６と、冗長ルート決定部３７とを有する。
さらに、冗長ルート決定部３７は、決定された「冗長化実行ＶＮＦ」を実際に冗長化するために、サービスチェイン設計装置１外部のサービスチェインコントローラ要求受付部３８と接続される。
以下、図２，図３の具体例を元に、これらのサービスチェイン設計装置１の各構成要素を明らかにする。
図２は、サービスチェイン設計装置１が扱うサービスチェインに関するデータの構成図である。
符号１０１は、図８の符号１０９のサービスチェインＡ〜Ｃに対して、新たにサービスチェインＤを追加したものである。これらのサービスチェインＡ〜Ｄは、VNF「F1」〜「F5」という５つのＶＮＦを利用する。
テーブルＴ００は、図８のテーブル２０９ａと同様に、符号１０１の各サービスチェインＩＤＴ０１の収容ユーザ数Ｔ０２を示す。サービスチェイン単体でみると、最大のユーザ数200人を収容するサービスチェインＤが最も影響力の高いサービスチェインであるといえる。
符号１０１は、図８の符号１０９のサービスチェインＡ〜Ｃに対して、新たにサービスチェインＤを追加したものである。これらのサービスチェインＡ〜Ｄは、VNF「F1」〜「F5」という５つのＶＮＦを利用する。
テーブルＴ００は、図８のテーブル２０９ａと同様に、符号１０１の各サービスチェインＩＤＴ０１の収容ユーザ数Ｔ０２を示す。サービスチェイン単体でみると、最大のユーザ数200人を収容するサービスチェインＤが最も影響力の高いサービスチェインであるといえる。
テーブルＴ１０，Ｔ２０，Ｔ３０は、図８のテーブル２０９ｂと同様に、ＶＮＦＩＤＴ１１で示されるＶＮＦごとに着目したサービスチェインの状況を示す。図８のテーブル２０９ｂと同様に、収容サービスチェインＩＤＴ１２と、収容数Ｔ２０（サービス数Ｔ２１、ユーザ数Ｔ２２）とが、ＶＮＦＩＤＴ１１ごとに対応づけられている。さらに、図２では、ＶＮＦＩＤＴ１１ごとの性能値Ｔ３０（値１を100%とするＣＰＵ使用率）も、対応づけられている。
このような各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０は、サービスチェイン生成要求受付部１１が受け付けた各サービスチェインを、サービスチェイン生成要求分解部１２が分解して求めたものである。
そして、各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０の内容を冗長化対象ＶＮＦ判定部１３がサービス数Ｔ２１が最大であるＶＮＦを判定した結果、強調図示したVNF「F3」が冗長化対象ＶＮＦ決定部１４により「冗長化対象ＶＮＦ」として決定される。
このような各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０は、サービスチェイン生成要求受付部１１が受け付けた各サービスチェインを、サービスチェイン生成要求分解部１２が分解して求めたものである。
そして、各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０の内容を冗長化対象ＶＮＦ判定部１３がサービス数Ｔ２１が最大であるＶＮＦを判定した結果、強調図示したVNF「F3」が冗長化対象ＶＮＦ決定部１４により「冗長化対象ＶＮＦ」として決定される。
図３は、図２のサービスチェインＢ上のVNF「F3」が冗長化された後のデータの構成図である。
符号１０２は、図２の符号１０１と同様に、図７の物理的なネットワークシステム上に構築されたサービスチェインＢを示す。
符号１０１と符号１０２とを比較すると、符号１０２のサービスチェインＢは、始点ノードN1からの迂回路「N3→N7→N11→VM6→N11→N7→N3→N1→N2→N4→N8」上に、２つめのVNF「F3」が冗長化されている。
符号１０２は、図２の符号１０１と同様に、図７の物理的なネットワークシステム上に構築されたサービスチェインＢを示す。
符号１０１と符号１０２とを比較すると、符号１０２のサービスチェインＢは、始点ノードN1からの迂回路「N3→N7→N11→VM6→N11→N7→N3→N1→N2→N4→N8」上に、２つめのVNF「F3」が冗長化されている。
テーブルＴ１１，Ｔ４０（サービス数Ｔ４１、ユーザ数Ｔ４２、性能値Ｔ４３）は、冗長化判定部３１が「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」とするか否かを判定に使用される閾値をＶＮＦＩＤＴ１１ごとに対応づけたものである。例えば、サービス数Ｔ４１の「≧５（５以上）」とは、図２のサービス数Ｔ２１が５以上になったときに、「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」とする旨を示している。
つまり、図２の段階ではサービス数Ｔ２１＝３なので、サービス数Ｔ４１の「≧５」を満たさないので、冗長化判定部３１は、冗長化対象ＶＮＦ「F3」は、まだ冗長化実行ＶＮＦとはしない旨を判定する。一方、VNF「F3」を利用するサービスチェイン数がさらに２つ増加し、VNF「F3」のサービス数Ｔ４１の「≧５」を満たすようになったら、冗長化決定部３２は、冗長化対象ＶＮＦ「F3」を冗長化実行ＶＮＦとする旨を決定する。
つまり、図２の段階ではサービス数Ｔ２１＝３なので、サービス数Ｔ４１の「≧５」を満たさないので、冗長化判定部３１は、冗長化対象ＶＮＦ「F3」は、まだ冗長化実行ＶＮＦとはしない旨を判定する。一方、VNF「F3」を利用するサービスチェイン数がさらに２つ増加し、VNF「F3」のサービス数Ｔ４１の「≧５」を満たすようになったら、冗長化決定部３２は、冗長化対象ＶＮＦ「F3」を冗長化実行ＶＮＦとする旨を決定する。
テーブルＴ１１，Ｔ５０（サービス数Ｔ５１、ユーザ数Ｔ５２、性能値Ｔ５３）は、冗長度計算部３３が冗長化実行ＶＮＦ「F3」をどのように冗長化するかを具体的に計算するために参照される。例えば、強調図示したサービス数Ｔ５１の「２≦（２以下）」とは、冗長化実行ＶＮＦ「F3」を冗長化することにより、１つの箇所のVNF「F3」あたり、そのF3を利用するサービスチェイン数が２以下の状態になるようにする旨を示す。
よって、冗長度決定部３４は、冗長化前はサービスチェイン数「５」を収容していた１箇所のVNF「F3」を、新規に２つ生成して合計３箇所のVNF「F3」が存在するように、つまり、合計３箇所なので冗長度＝３を決定する。つまり、サービス数Ｔ５１の「２≦（２以下）」を満たすため、それぞれのVNF「F3」の収容サービス数がそれぞれ「１つ、２つ、２つ」になるように、５つのサービスチェインを分散させればよい。
つまり、冗長化決定閾値Ｔ４０よりも冗長化直後の閾値Ｔ５０を低い値とすることで、１回冗長化した後、すぐに２度目の冗長化決定の判定がおりないように余裕をもたせている。
よって、冗長度決定部３４は、冗長化前はサービスチェイン数「５」を収容していた１箇所のVNF「F3」を、新規に２つ生成して合計３箇所のVNF「F3」が存在するように、つまり、合計３箇所なので冗長度＝３を決定する。つまり、サービス数Ｔ５１の「２≦（２以下）」を満たすため、それぞれのVNF「F3」の収容サービス数がそれぞれ「１つ、２つ、２つ」になるように、５つのサービスチェインを分散させればよい。
つまり、冗長化決定閾値Ｔ４０よりも冗長化直後の閾値Ｔ５０を低い値とすることで、１回冗長化した後、すぐに２度目の冗長化決定の判定がおりないように余裕をもたせている。
ＶＮＦ配置決定部３５は、新規に２つ生成するVNF「F3」の配置を決定する。ここで、新旧含め、合計３つのVNF「F3」は、全て異なる物理サーバ上に配置することが望ましい。
冗長ルート計算部３６と、新規に２つ生成するVNF「F3」を通過するサービスチェインのルート（経路）も新規に生成する。例えば、符号１０２で示したように、サービスチェインＢにおいては、VNF「F3」の前に存在する始点ノードN3から分岐し、VNF「F3」が存在するノードN11上のVM6を通過し、サービスチェインＢの終点側のノードN8に合流するルートが、冗長ルート計算部３６によって新規に計算される。
ここで、冗長ルート計算部３６は、符号１０２の例では、始点側（N1）と終点側（N8）だけが分岐前後で重複しているように、各新規経路は可能な限り重複させないようにすることが望ましい。
冗長ルート決定部３７は、冗長ルート計算部３６の計算結果を受け、サービスチェインコントローラ要求受付部３８に対して新規経路を設定するように指示する。
冗長ルート計算部３６と、新規に２つ生成するVNF「F3」を通過するサービスチェインのルート（経路）も新規に生成する。例えば、符号１０２で示したように、サービスチェインＢにおいては、VNF「F3」の前に存在する始点ノードN3から分岐し、VNF「F3」が存在するノードN11上のVM6を通過し、サービスチェインＢの終点側のノードN8に合流するルートが、冗長ルート計算部３６によって新規に計算される。
ここで、冗長ルート計算部３６は、符号１０２の例では、始点側（N1）と終点側（N8）だけが分岐前後で重複しているように、各新規経路は可能な限り重複させないようにすることが望ましい。
冗長ルート決定部３７は、冗長ルート計算部３６の計算結果を受け、サービスチェインコントローラ要求受付部３８に対して新規経路を設定するように指示する。
以上、図２，図３を参照して、サービスチェイン設計装置１の各処理部の具体例を用いた説明を行った。
以下では、サービスチェイン設計装置１の各処理部および各データベースの内容について、一般化した説明を行う。まず、符号２１〜２５で示す各データベースが、格納するデータ内容について、図２，図３で説明したテーブルＴ００〜Ｔ５０を参照しつつ説明する。
以下では、サービスチェイン設計装置１の各処理部および各データベースの内容について、一般化した説明を行う。まず、符号２１〜２５で示す各データベースが、格納するデータ内容について、図２，図３で説明したテーブルＴ００〜Ｔ５０を参照しつつ説明する。
ポリシー／閾値管理ＤＢ２１は、ＶＮＦＩＤＴ１１ごとの冗長化決定閾値Ｔ４０と、ＶＮＦＩＤＴ１１ごとの冗長化直後の閾値Ｔ５０とを格納する。ここで「ポリシー」とは、ＤＢには直接格納されていないが、「サービス数Ｔ４１を冗長化判定部３１の判定に用いる」もしくは、「ユーザ数Ｔ４２および性能値Ｔ４３を組み合わせて冗長化判定部３１の判定に用いる」などの事前設定情報である。
サービスチェイン構成情報ＤＢ２２は、図２の符号１０１で示したような、サービスチェインＩＤＴ０１ごとの各サービスチェインの構成要素を格納する。例えば、サービスチェインＡの構成要素「N1→L1→N2→L4→N5→L10→N9→VL3→VM3→F2(T11)→VL3→N9→L11→N6→L12→N10→VL5→VM5→F3(T11)」が、サービスチェイン構成情報ＤＢ２２に格納される。
サービスチェイン構成情報ＤＢ２２は、図２の符号１０１で示したような、サービスチェインＩＤＴ０１ごとの各サービスチェインの構成要素を格納する。例えば、サービスチェインＡの構成要素「N1→L1→N2→L4→N5→L10→N9→VL3→VM3→F2(T11)→VL3→N9→L11→N6→L12→N10→VL5→VM5→F3(T11)」が、サービスチェイン構成情報ＤＢ２２に格納される。
収容情報管理ＤＢ２３は、サービスチェインＩＤＴ０１ごとの収容情報として、収容ユーザ数Ｔ０２、当該サービスチェインに収容されるＶＮＦＩＤＴ１１、および、収容数Ｔ２０を格納する。
性能値収集ＤＢ２４は、ＶＮＦＩＤＴ１１ごとに測定され、収集された性能値Ｔ３０として、図２に例示したＣＰＵ使用率や、図示省略した遅延時間、使用帯域、使用メモリ、使用プロセス数、トラヒック送受信量、処理速度などを１つまたは複数の組み合わせ値として格納する。
冗長化対象ＶＮＦ管理ＤＢ２５は、冗長化対象となったＶＮＦＩＤＴ１１（図２では、Ｆ３）と、その収容サービスチェインＩＤＴ１２とを格納する。
性能値収集ＤＢ２４は、ＶＮＦＩＤＴ１１ごとに測定され、収集された性能値Ｔ３０として、図２に例示したＣＰＵ使用率や、図示省略した遅延時間、使用帯域、使用メモリ、使用プロセス数、トラヒック送受信量、処理速度などを１つまたは複数の組み合わせ値として格納する。
冗長化対象ＶＮＦ管理ＤＢ２５は、冗長化対象となったＶＮＦＩＤＴ１１（図２では、Ｆ３）と、その収容サービスチェインＩＤＴ１２とを格納する。
次に、符号２１〜２５で示す各データベースを用いて、各処理部の動作を説明する。
サービスチェイン生成要求受付部１１は、新規サービスチェインの生成オーダを受け付ける。
サービスチェイン生成要求分解部１２は、サービスチェイン生成要求受付部１１が受け付けたオーダ内容の分解処理を行い、その結果をサービスチェイン構成情報ＤＢ２２、および、収容情報管理ＤＢ２３に書き出す。
サービスチェイン生成要求受付部１１は、新規サービスチェインの生成オーダを受け付ける。
サービスチェイン生成要求分解部１２は、サービスチェイン生成要求受付部１１が受け付けたオーダ内容の分解処理を行い、その結果をサービスチェイン構成情報ＤＢ２２、および、収容情報管理ＤＢ２３に書き出す。
冗長化対象ＶＮＦ判定部１３は、以下に示すように、各データベースを参照して、全ＶＮＦから冗長化対象ＶＮＦを選択するために必要なデータを取得する。
・サービスチェイン構成情報ＤＢ２２から、サービスチェインを構成するＶＮＦ情報を取得する。
・ポリシー／閾値管理ＤＢ２１から、冗長化対象ＶＮＦを決定するポリシー情報を取得する。
・収容情報管理ＤＢ２３から、各サービスチェインに収容されているユーザ数／サービス数などを取得する。
・性能値収集ＤＢ２４から、各サービスチェインに収容されているＶＮＦの性能値情報を取得する。
・サービスチェイン構成情報ＤＢ２２から、サービスチェインを構成するＶＮＦ情報を取得する。
・ポリシー／閾値管理ＤＢ２１から、冗長化対象ＶＮＦを決定するポリシー情報を取得する。
・収容情報管理ＤＢ２３から、各サービスチェインに収容されているユーザ数／サービス数などを取得する。
・性能値収集ＤＢ２４から、各サービスチェインに収容されているＶＮＦの性能値情報を取得する。
そして、冗長化対象ＶＮＦ判定部１３は、以下に列挙する手法のいずれかにより、冗長化対象ＶＮＦの候補を選択する。どの手法を用いるかは、取得したポリシー情報で指定される。
（手法１１）収容サービスチェイン数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１２）収容ユーザ数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１３）特に重要な機能をサービスとして提供しているＶＮＦ（例：緊急対応用サービスを提供するＶＮＦなど）を、冗長化対象ＶＮＦとすることを許可する。
（手法１４）重要ユーザを収容しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１５）サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図４で後記）。
（手法１６）前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図５で後記）。
冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）〜（手法１６）で算出した結果を１つ以上用いて、冗長化対象ＶＮＦを決定する（詳細は図６で後記）。
なお、収容サービスチェイン数、収容ユーザ数などのパラメータは、冗長化対象ＶＮＦを決定するための重要度のパラメータである。
（手法１１）収容サービスチェイン数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１２）収容ユーザ数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１３）特に重要な機能をサービスとして提供しているＶＮＦ（例：緊急対応用サービスを提供するＶＮＦなど）を、冗長化対象ＶＮＦとすることを許可する。
（手法１４）重要ユーザを収容しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
（手法１５）サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図４で後記）。
（手法１６）前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図５で後記）。
冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）〜（手法１６）で算出した結果を１つ以上用いて、冗長化対象ＶＮＦを決定する（詳細は図６で後記）。
なお、収容サービスチェイン数、収容ユーザ数などのパラメータは、冗長化対象ＶＮＦを決定するための重要度のパラメータである。
冗長化判定部３１は、冗長化対象ＶＮＦ決定部１４により決定された冗長化対象ＶＮＦを、冗長化実行ＶＮＦとするか否かを判定する。この判定処理は、ポリシー／閾値管理ＤＢ２１、収容情報管理ＤＢ２３、および、性能値収集ＤＢ２４を参照して、現在値（実測値）が閾値を超過しているかどうかを、判定基準の閾値ごとに比較する処理である。以下に、判定基準を列挙する。
（基準２１）収容サービスチェイン数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
（基準２２）収容ユーザ数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
（基準２３）性能値（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
冗長化決定部３２は、冗長化判定部３１の結果（１つ以上の閾値超過の可否）をもって、最終的に冗長化対象ＶＮＦを冗長化実行ＶＮＦとするか否かを決定する。冗長化決定部３２は、例えば、（基準２１）および（基準２２）それぞれの閾値が共に超過していたら冗長化を決定する。
（基準２１）収容サービスチェイン数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
（基準２２）収容ユーザ数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
（基準２３）性能値（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
冗長化決定部３２は、冗長化判定部３１の結果（１つ以上の閾値超過の可否）をもって、最終的に冗長化対象ＶＮＦを冗長化実行ＶＮＦとするか否かを決定する。冗長化決定部３２は、例えば、（基準２１）および（基準２２）それぞれの閾値が共に超過していたら冗長化を決定する。
冗長度計算部３３は、冗長化判断のパラメータ（収容サービスチェイン数、収容ユーザ数、性能値）が、任意の閾値以下になるように分割し、分割した分のＶＮＦを新規に生成する。そのため、冗長度計算部３３は、ポリシー／閾値管理ＤＢ２１、収容情報管理ＤＢ２３、および、性能値収集ＤＢ２４を参照する。
冗長度決定部３４は、冗長度計算部３３の結果（１つ以上の冗長度）を用いて、対象ＶＮＦの新規生成数を決定する。例えば、収容サービスチェイン数に着目した場合は対象ＶＮＦの新規生成数は２となり、性能値に着目した場合は新規生成数が３となるような場合を考える。冗長度決定部３４は、２と３との最大数を採用し、最終的にはＶＮＦの新規生成数を３と決定する。
冗長度決定部３４は、冗長度計算部３３の結果（１つ以上の冗長度）を用いて、対象ＶＮＦの新規生成数を決定する。例えば、収容サービスチェイン数に着目した場合は対象ＶＮＦの新規生成数は２となり、性能値に着目した場合は新規生成数が３となるような場合を考える。冗長度決定部３４は、２と３との最大数を採用し、最終的にはＶＮＦの新規生成数を３と決定する。
ＶＮＦ配置決定部３５は、サービスチェイン構成情報ＤＢ２２および性能値収集ＤＢ２４を参照して、冗長化実行ＶＮＦがそれぞれ可能な限り別々の物理サーバ上に配置されるように、新規生成したＶＮＦの配置を決定する。これにより、１つの物理サーバが故障した場合でも、他の物理サーバが生存していれば、いずれかの冗長化実行ＶＮＦが機能し続けることで、信頼性を高めることができる。
冗長ルート計算部３６は、サービスチェイン構成情報ＤＢ２２および性能値収集ＤＢ２４を参照して、ＶＮＦ配置決定部３５が決定した各新規生成ＶＮＦの配置をもとに、冗長ルートを計算する。以下に、冗長ルートの計算手法を列挙する。冗長ルート計算部３６は、（手法３１）〜（手法３３）のうちの少なくとも１つを用いて、冗長ルートを計算する。
（手法３１）サービスチェインごとに、冗長化対象となるＶＮＦの直前／直後のＶＮＦが存在するサーバ（もしくは、始点／終点ノード）と、新規ＶＮＦが存在するサーバとの間の新規経路を、ダイクストラ法などで算出する。
（手法３２）冗長化された複数の同種ＶＮＦにおいて、既に割り当てられている経路は計算の対象外とする。もしくは、より共有されていない経路を選択する。このように、経路重複を発生させないことで、現用系および予備系の経路双方が故障することによるサービス断の発生を予防することができる。
（手法３３）冗長化対象となるＶＮＦの直前にｖＬＢ（virtual Load Balancer）などのロードバランサを配置する。そのロードバランサを経由して複数の冗長化実行ＶＮＦ（既存ＶＮＦおよび新規ＶＮＦ）それぞれを通過する冗長ルートを生成してもよい。ただし、この場合、仮想経路は互いに分離されていても、物理経路が分離されているとは限らない。
（手法３１）サービスチェインごとに、冗長化対象となるＶＮＦの直前／直後のＶＮＦが存在するサーバ（もしくは、始点／終点ノード）と、新規ＶＮＦが存在するサーバとの間の新規経路を、ダイクストラ法などで算出する。
（手法３２）冗長化された複数の同種ＶＮＦにおいて、既に割り当てられている経路は計算の対象外とする。もしくは、より共有されていない経路を選択する。このように、経路重複を発生させないことで、現用系および予備系の経路双方が故障することによるサービス断の発生を予防することができる。
（手法３３）冗長化対象となるＶＮＦの直前にｖＬＢ（virtual Load Balancer）などのロードバランサを配置する。そのロードバランサを経由して複数の冗長化実行ＶＮＦ（既存ＶＮＦおよび新規ＶＮＦ）それぞれを通過する冗長ルートを生成してもよい。ただし、この場合、仮想経路は互いに分離されていても、物理経路が分離されているとは限らない。
冗長ルート決定部３７は、冗長ルート計算部３６の結果（１つ以上の冗長ルート）を用いて、新規生成したＶＮＦの冗長ルートを決定する。決定された冗長ルートは、サービスチェイン構成情報ＤＢ２２に追加される。
サービスチェインコントローラ要求受付部３８は、冗長ルート決定部３７から以下の設定情報を受け取り、その設定情報を物理ネットワークに反映させる。
・冗長化実行ＶＮＦのＶＮＦＩＤ
・冗長化実行ＶＮＦの生成数
・冗長化実行ＶＮＦの配置先の物理サーバＩＤ
・冗長化実行ＶＮＦを通過する新規の冗長ルートの情報
以上、図１〜図３を参照して、サービスチェイン設計装置１の各構成要素の詳細を説明した。以下、図４〜図６を参照して、冗長化対象ＶＮＦ判定部１３および冗長化対象ＶＮＦ決定部１４の一部の処理を補足説明する。
サービスチェインコントローラ要求受付部３８は、冗長ルート決定部３７から以下の設定情報を受け取り、その設定情報を物理ネットワークに反映させる。
・冗長化実行ＶＮＦのＶＮＦＩＤ
・冗長化実行ＶＮＦの生成数
・冗長化実行ＶＮＦの配置先の物理サーバＩＤ
・冗長化実行ＶＮＦを通過する新規の冗長ルートの情報
以上、図１〜図３を参照して、サービスチェイン設計装置１の各構成要素の詳細を説明した。以下、図４〜図６を参照して、冗長化対象ＶＮＦ判定部１３および冗長化対象ＶＮＦ決定部１４の一部の処理を補足説明する。
図４は、冗長化対象ＶＮＦ判定部１３の（手法１５）の処理例を示す説明図である。
冗長化対象ＶＮＦ判定部１３は、（手法１５）として、サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることとした。ここで、「重要なポジションに存在するＶＮＦ」とは、以下の２通りである。
（Ａ）サービスチェインの最後に位置するＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」と、サービスチェインＣの「Ｆ２」とが、それぞれ一番最後に位置する。
（Ｂ）サービスチェインにおけるＶＮＦの位置によって重み付けし（チェインの後方に位置するほど、重要度としての重みを大きくし）、一番重みの大きいＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」は、同じサービスチェインＡの「Ｆ２」よりも後方に位置しているので、重みが前方の「Ｆ２」の０．５よりも大きい１．０に設定されている。そして、テーブル２０３に示すように、サービスチェイン全体での重みの合計値をＶＮＦごとに求め、その最大値１．６６となる「Ｆ３」を、重要なポジションに存在するＶＮＦとする。
冗長化対象ＶＮＦ判定部１３は、（手法１５）として、サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることとした。ここで、「重要なポジションに存在するＶＮＦ」とは、以下の２通りである。
（Ａ）サービスチェインの最後に位置するＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」と、サービスチェインＣの「Ｆ２」とが、それぞれ一番最後に位置する。
（Ｂ）サービスチェインにおけるＶＮＦの位置によって重み付けし（チェインの後方に位置するほど、重要度としての重みを大きくし）、一番重みの大きいＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」は、同じサービスチェインＡの「Ｆ２」よりも後方に位置しているので、重みが前方の「Ｆ２」の０．５よりも大きい１．０に設定されている。そして、テーブル２０３に示すように、サービスチェイン全体での重みの合計値をＶＮＦごとに求め、その最大値１．６６となる「Ｆ３」を、重要なポジションに存在するＶＮＦとする。
なお、（Ａ）や（Ｂ）のように重みを設定した理由は、次の通りである。サービスチェインは、ルートの始点から順番に（シーケンシャルに）、ＶＮＦで処理される。例えば、チェインの最後のＶＮＦが故障した場合、一番最初から処理をやり直す必要がある。つまり、ルートの前段で実施した処理は無駄となり、全てやり直しとなってしまう。従って、チェインの後方のＶＮＦになればなるほど、重要（冗長化対象）となるようにした。
図５は、冗長化対象ＶＮＦ判定部１３の（手法１６）の処理例を示す説明図である。
冗長化対象ＶＮＦ判定部１３は、（手法１６）として、前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることとした。前段で多くのリソースを消費しているＶＮＦは、例えば、ＶＮＦごとに、前段処理で使用しているリソースの割合によって重み付けし、一番重みの大きいＶＮＦとして求めることができる。
図５の例では、テーブル２０４に示すように、重い処理か否かを判断する材料として、ＶＮＦごとの「リソース使用率」をみる。リソース使用率が大きい程、より重い処理を実行しているためである。
冗長化対象ＶＮＦ判定部１３は、（手法１６）として、前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることとした。前段で多くのリソースを消費しているＶＮＦは、例えば、ＶＮＦごとに、前段処理で使用しているリソースの割合によって重み付けし、一番重みの大きいＶＮＦとして求めることができる。
図５の例では、テーブル２０４に示すように、重い処理か否かを判断する材料として、ＶＮＦごとの「リソース使用率」をみる。リソース使用率が大きい程、より重い処理を実行しているためである。
そして、符号１０４の例では、サービスチェインＡの「Ｆ２」は、テーブル２０４を参照するとリソース使用率＝０．７である。そして、（自身のＶＮＦの重み）＝（サービスチェインにおける前段のリソース使用率）＋（自身のリソース使用率）という累積和の計算により、冗長化対象ＶＮＦ判定部１３は、各ＶＮＦの重みを求める。つまり、図４の（手法１５）と同様に、チェインの後方のＶＮＦになればなるほど、重要度としての重みを増加させた。
サービスチェインＡの「Ｆ２」の重み＝（自身のリソース使用率＝０．７）となり、
サービスチェインＡの「Ｆ３」の重み＝（前段のリソース使用率＝０．７）＋（自身のリソース使用率＝０．８）＝１．５となる。
同様に、冗長化対象ＶＮＦ判定部１３は、サービスチェインＢのＦ３，Ｆ１の重みも求める。
そして、冗長化対象ＶＮＦ判定部１３は、重みの最大値＝１．６となるＦ１を、冗長化対象ＶＮＦとする。
サービスチェインＡの「Ｆ２」の重み＝（自身のリソース使用率＝０．７）となり、
サービスチェインＡの「Ｆ３」の重み＝（前段のリソース使用率＝０．７）＋（自身のリソース使用率＝０．８）＝１．５となる。
同様に、冗長化対象ＶＮＦ判定部１３は、サービスチェインＢのＦ３，Ｆ１の重みも求める。
そして、冗長化対象ＶＮＦ判定部１３は、重みの最大値＝１．６となるＦ１を、冗長化対象ＶＮＦとする。
さらに、冗長化対象ＶＮＦ判定部１３は、図５の（手法１６）で求めた各リソース使用率の重みに対して、図４の（手法１５）で説明したように、サービスチェイン全体での重みの合計値が最大値となるＶＮＦを、冗長化対象ＶＮＦとしてもよい。例えば、図５の３つのＶＮＦについては、以下のように、重みの合計値が求まる。
・「Ｆ１」の重みの合計値＝１．６
・「Ｆ２」の重みの合計値＝０．７
・「Ｆ３」の重みの合計値＝２．３（＝１．５＋０．８）
よって、重みの合計値が最大の「Ｆ３」が、冗長化対象ＶＮＦとなる。
・「Ｆ１」の重みの合計値＝１．６
・「Ｆ２」の重みの合計値＝０．７
・「Ｆ３」の重みの合計値＝２．３（＝１．５＋０．８）
よって、重みの合計値が最大の「Ｆ３」が、冗長化対象ＶＮＦとなる。
図６は、冗長化対象ＶＮＦ決定部１４の処理例を示す説明図である。
冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）〜（手法１６）で算出した結果を２つ以上組み合わせて、冗長化対象ＶＮＦを決定してもよい。以下、その具体例を説明する。
テーブル２０５は、ＶＮＦごとに、収容ユーザ数が最大であるＶＮＦ（手法１２）を決定するためのユーザ数（つまり、図２で示した収容数Ｔ２０のうちのユーザ数Ｔ２２）と、前段で多くのリソースを消費しているＶＮＦ（手法１６）を決定するためのリソース使用率とを抜粋したものである。
まず、図５で説明したように、（手法１６）に従って、各ＶＮＦの重みを計算する。例えば、サービスチェインＡのＦ３の重み＝０．７＋０．８＝１．５である。
次に、ＶＮＦごとに、（手法１６）の重み×（手法１２）のユーザ数の積を求める。例えば、サービスチェインＡのＦ３の積＝（重み１．５）×（ユーザ数１８０）＝２７０となる。この積が他のどのＶＮＦの積よりも大きいので（つまり、重要度が最大値となるので）、冗長化対象ＶＮＦ決定部１４は、Ｆ３を冗長化対象ＶＮＦとして決定する。
冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）〜（手法１６）で算出した結果を２つ以上組み合わせて、冗長化対象ＶＮＦを決定してもよい。以下、その具体例を説明する。
テーブル２０５は、ＶＮＦごとに、収容ユーザ数が最大であるＶＮＦ（手法１２）を決定するためのユーザ数（つまり、図２で示した収容数Ｔ２０のうちのユーザ数Ｔ２２）と、前段で多くのリソースを消費しているＶＮＦ（手法１６）を決定するためのリソース使用率とを抜粋したものである。
まず、図５で説明したように、（手法１６）に従って、各ＶＮＦの重みを計算する。例えば、サービスチェインＡのＦ３の重み＝０．７＋０．８＝１．５である。
次に、ＶＮＦごとに、（手法１６）の重み×（手法１２）のユーザ数の積を求める。例えば、サービスチェインＡのＦ３の積＝（重み１．５）×（ユーザ数１８０）＝２７０となる。この積が他のどのＶＮＦの積よりも大きいので（つまり、重要度が最大値となるので）、冗長化対象ＶＮＦ決定部１４は、Ｆ３を冗長化対象ＶＮＦとして決定する。
以上説明した本実施形態では、サービスチェイン設計装置１が、サービスチェインに使用されるＶＮＦを冗長化することで、サービスチェインを動的かつ信頼性を高めた設計を行う方法を示した。
なお、比較例として、同じＶＮＦの集合を提供可能なサービスチェインを複数用意し、いずれか１つのサービスチェインに問題が発生した場合に、他のサービスチェインに切り替えるという運用方法が想定される。ただし、この比較例では、複数のサービスチェインに共有されるＶＮＦが故障した場合、故障したＶＮＦから他のＶＮＦに切り替える過程で多くのサービスまたはユーザに影響が及んでしまう。
例えば、あるＶＮＦが１００個のサービスチェインに共有されている場合、本ＶＮＦが故障すると、一度に１００個のチェインが予備系に切り替わる。結果、１００種のサービス影響と、本サービスチェインに収容されている多数のユーザに影響を及ぼしてしまう。
例えば、あるＶＮＦが１００個のサービスチェインに共有されている場合、本ＶＮＦが故障すると、一度に１００個のチェインが予備系に切り替わる。結果、１００種のサービス影響と、本サービスチェインに収容されている多数のユーザに影響を及ぼしてしまう。
一方、本実施形態では、サービスチェイン設計装置１が、多数のユーザに影響を及ぼしてしまうような、特に重要なＶＮＦを冗長化対象ＶＮＦとして個別に多重化することで、サービスチェイン全体の信頼性をより高めることができる。さらに、比較例のようなサービスチェイン単位での冗長化と、本実施形態の重要なＶＮＦ単位での冗長化とを併用することで、より高い信頼性を確保できる。
また、本実施形態では、冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ決定部１４と、冗長化判定部３１と、冗長化決定部３２とをそれぞれ個別の機能部として用意することで、最初に冗長化対象とするＶＮＦを決定し、次に対象ＶＮＦの各種閾値を観測し、冗長化を行う構成を示した。その代わりに、冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ決定部１４と、冗長化判定部３１と、冗長化決定部３２とを１つの機能部としてサービスチェイン設計装置１内に実装してもよい。その場合、運用中の全ＶＮＦの各種閾値を観測しながら、冗長化対象ＶＮＦを決定し、同時に冗長化を行うようにサービスチェイン設計装置１が動作する。
なお、本実施形態においては、本発明に係るサービスチェイン設計装置１は、図２に示すように、４種類のサービスチェインＡ〜Ｄを扱うこととしたが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービスチェイン設計装置１の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
１ サービスチェイン設計装置
１１ サービスチェイン生成要求受付部
１２ サービスチェイン生成要求分解部
１３ 冗長化対象ＶＮＦ判定部（第１判定部）
１４ 冗長化対象ＶＮＦ決定部
２１ ポリシー／閾値管理ＤＢ
２２ サービスチェイン構成情報ＤＢ
２３ 収容情報管理ＤＢ
２４ 性能値収集ＤＢ
２５ 冗長化対象ＶＮＦ管理ＤＢ
３１ 冗長化判定部（第２判定部）
３２ 冗長化決定部
３３ 冗長度計算部
３４ 冗長度決定部
３５ ＶＮＦ配置決定部（配置決定部）
３６ 冗長ルート計算部
３７ 冗長ルート決定部
３８ サービスチェインコントローラ要求受付部
１１ サービスチェイン生成要求受付部
１２ サービスチェイン生成要求分解部
１３ 冗長化対象ＶＮＦ判定部（第１判定部）
１４ 冗長化対象ＶＮＦ決定部
２１ ポリシー／閾値管理ＤＢ
２２ サービスチェイン構成情報ＤＢ
２３ 収容情報管理ＤＢ
２４ 性能値収集ＤＢ
２５ 冗長化対象ＶＮＦ管理ＤＢ
３１ 冗長化判定部（第２判定部）
３２ 冗長化決定部
３３ 冗長度計算部
３４ 冗長度決定部
３５ ＶＮＦ配置決定部（配置決定部）
３６ 冗長ルート計算部
３７ 冗長ルート決定部
３８ サービスチェインコントローラ要求受付部
Claims (8)
- ＶＮＦ（Virtualized Network Function）を利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする
サービスチェイン設計装置。 - 前記第１判定部は、前記サービスチェインの数、および、前記収容するユーザの数に加えて、サービスチェイン内におけるＶＮＦの位置がルートの後方であるほど高い重要度とする重み、および、サービスチェイン内における前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みの少なくとも１つをＶＮＦごとの重要度とすることを特徴とする
請求項１に記載のサービスチェイン設計装置。 - 前記第１判定部は、前記サービスチェインの数、および、前記収容するユーザの数に加えて、前記ＶＮＦが提供するサービス内容の重み、および、サービスチェインが収容するユーザの重みのうちの少なくとも１つの重みをもとに、ＶＮＦごとの重要度を計算することを特徴とする
請求項２に記載のサービスチェイン設計装置。 - 前記第２判定部は、ＶＮＦの性能値の測定データをもとに、前記冗長化対象ＶＮＦの重要度が所定閾値を超過したか否かを判定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載のサービスチェイン設計装置。 - 前記サービスチェイン設計装置は、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部は、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部は、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のサービスチェイン設計装置。 - 前記サービスチェイン設計装置は、さらに、配置決定部と、冗長ルート決定部とを有しており、
前記配置決定部は、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
前記冗長ルート決定部は、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のサービスチェイン設計装置。 - サービスチェイン設計装置は、第１判定部と、第２判定部と、冗長度計算部とを有しており、
前記第１判定部は、ＶＮＦ（Virtualized Network Function）を利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定し、
前記第２判定部は、前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定し、
前記冗長度計算部は、前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算することを特徴とする
サービスチェイン設計方法。 - 請求項７に記載のサービスチェイン設計方法を、コンピュータである前記サービスチェイン設計装置に実行させるためのサービスチェイン設計プログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018107042A JP6973300B2 (ja) | 2018-06-04 | 2018-06-04 | サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム |
| PCT/JP2019/021127 WO2019235304A1 (ja) | 2018-06-04 | 2019-05-28 | サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム |
| US15/734,292 US11258551B2 (en) | 2018-06-04 | 2019-05-28 | Service chain designing device, service chain designing method, and service chain designing program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018107042A JP6973300B2 (ja) | 2018-06-04 | 2018-06-04 | サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2019213028A true JP2019213028A (ja) | 2019-12-12 |
| JP6973300B2 JP6973300B2 (ja) | 2021-11-24 |
Family
ID=68769861
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018107042A Active JP6973300B2 (ja) | 2018-06-04 | 2018-06-04 | サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US11258551B2 (ja) |
| JP (1) | JP6973300B2 (ja) |
| WO (1) | WO2019235304A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112217874A (zh) * | 2020-09-21 | 2021-01-12 | 北京邮电大学 | 一种服务功能链生成方法及装置 |
| JP2023039385A (ja) * | 2021-09-08 | 2023-03-20 | 財團法人工業技術研究院 | 仮想機能性能分析システムおよびその分析方法 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2016152480A (ja) * | 2015-02-17 | 2016-08-22 | 日本電信電話株式会社 | 通信ネットワークの冗長経路検出システムおよびその検出方法 |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8010942B1 (en) * | 2007-03-05 | 2011-08-30 | Sprint Communications Company L.P. | Resilient application design and displaying design profile via graphical user interface |
| US20110103358A1 (en) * | 2009-10-30 | 2011-05-05 | Openwave Systems, Inc. | Back-channeled packeted data |
| JP5748363B2 (ja) | 2013-02-01 | 2015-07-15 | 日本電信電話株式会社 | 通信経路設計装置、通信経路設計方法及び通信経路設計プログラム |
| US9882828B1 (en) * | 2014-11-11 | 2018-01-30 | Amdocs Software Systems Limited | System, method, and computer program for planning distribution of network resources in a network function virtualization (NFV) based communication network |
| US9503391B2 (en) * | 2014-04-11 | 2016-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for network function placement |
| US9781631B2 (en) * | 2014-04-30 | 2017-10-03 | Affirmed Networks, Inc. | Optimizing capacity expansion in a mobile network |
| US9806975B2 (en) * | 2014-06-12 | 2017-10-31 | Futurewei Technologies, Inc. | Methods and systems for managing capacity in a virtualized network |
| CN105429776B (zh) * | 2014-09-22 | 2020-06-09 | 中兴通讯股份有限公司 | 一种虚拟化网络功能管理的方法和系统 |
| CN107005428B (zh) * | 2014-09-29 | 2020-08-14 | 皇家Kpn公司 | 虚拟网络功能实例的状态复制的系统和方法 |
| US9462084B2 (en) * | 2014-12-23 | 2016-10-04 | Intel Corporation | Parallel processing of service functions in service function chains |
| WO2016204804A1 (en) * | 2015-06-16 | 2016-12-22 | Hewlett-Packard Development Company, L.P. | Virtualized network function monitoring |
| JP6636142B2 (ja) * | 2015-09-30 | 2020-01-29 | 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． | スケールアウト関連付けの方法および装置、ならびにシステム |
| US10477449B2 (en) * | 2016-08-26 | 2019-11-12 | Veniam, Inc. | Systems and methods for route selection in a network of moving things, for example including autonomous vehicles |
| WO2018104541A1 (en) * | 2016-12-09 | 2018-06-14 | British Telecommunications Public Limited Company | Implementing service function chains |
| CN108632063B (zh) * | 2017-03-20 | 2021-01-05 | 华为技术有限公司 | 管理网络切片实例的方法、装置和系统 |
| EP3630294B1 (en) * | 2017-05-31 | 2023-11-15 | L'oreal | Composition for conditioning hair |
| US11070432B2 (en) * | 2017-07-20 | 2021-07-20 | Cisco Technology, Inc. | Dynamic and customizable virtual network functions |
| US11467881B2 (en) * | 2017-09-13 | 2022-10-11 | At&T Intellectual Property I, L.P. | Framework, method and apparatus for network function as a service for hosted network functions in a cloud environment |
| CN109560955B (zh) * | 2017-09-27 | 2021-10-01 | 华为技术有限公司 | 网络的部署信息确定方法及设备 |
| US10467040B2 (en) * | 2017-09-29 | 2019-11-05 | Nec Corporation | Intelligent self-configuring decision method for the cloud resources management and orchestration |
| US10491483B2 (en) * | 2017-10-19 | 2019-11-26 | Nicira, Inc. | Using application programming interface calls for communication between network functions |
| US10999155B2 (en) * | 2017-10-26 | 2021-05-04 | Cisco Technology, Inc. | System and method for hybrid and elastic services |
| US10826797B2 (en) * | 2017-12-15 | 2020-11-03 | Foundation Of Soongsil University Industry Cooperation | System and method for processing network packets based on NFV for ensuring high availability |
| GB2573283B (en) * | 2018-04-26 | 2020-04-29 | Metaswitch Networks Ltd | Improvements relating to network functions virtualization |
-
2018
- 2018-06-04 JP JP2018107042A patent/JP6973300B2/ja active Active
-
2019
- 2019-05-28 US US15/734,292 patent/US11258551B2/en active Active
- 2019-05-28 WO PCT/JP2019/021127 patent/WO2019235304A1/ja active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2016152480A (ja) * | 2015-02-17 | 2016-08-22 | 日本電信電話株式会社 | 通信ネットワークの冗長経路検出システムおよびその検出方法 |
Non-Patent Citations (1)
| Title |
|---|
| 中務 諭士 外４名: "可用性・運用性を向上するサービスルータ冗長構成の検討", 電子情報通信学会技術研究報告, vol. 第111巻 第344号, JPN6021038965, 8 December 2011 (2011-12-08), JP, pages 103 - 108, ISSN: 0004607490 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112217874A (zh) * | 2020-09-21 | 2021-01-12 | 北京邮电大学 | 一种服务功能链生成方法及装置 |
| CN112217874B (zh) * | 2020-09-21 | 2021-08-17 | 北京邮电大学 | 一种服务功能链生成方法及装置 |
| JP2023039385A (ja) * | 2021-09-08 | 2023-03-20 | 財團法人工業技術研究院 | 仮想機能性能分析システムおよびその分析方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019235304A1 (ja) | 2019-12-12 |
| US11258551B2 (en) | 2022-02-22 |
| JP6973300B2 (ja) | 2021-11-24 |
| US20210226743A1 (en) | 2021-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8862744B2 (en) | Optimizing traffic load in a communications network | |
| US20210012239A1 (en) | Automated generation of machine learning models for network evaluation | |
| US7610425B2 (en) | Approach for managing interrupt load distribution | |
| US20080263401A1 (en) | Computer application performance optimization system | |
| US7581052B1 (en) | Approach for distributing multiple interrupts among multiple processors | |
| US20070043347A1 (en) | Approach for distributing interrupts from high-interrupt load devices | |
| US11411808B2 (en) | Managing failover region availability for implementing a failover service | |
| US20210303423A1 (en) | Managing primary region availability for implementing a failover from another primary region | |
| EP4127936B1 (en) | Managing failover region availability for implementing a failover service | |
| US20210303422A1 (en) | Managing failover region availability for implementing a failover service | |
| WO2019235304A1 (ja) | サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム | |
| KR20200080458A (ko) | 클라우드 멀티-클러스터 장치 | |
| CN111641567B (zh) | 基于集中式控制器的动态网络带宽分配与管理 | |
| US11695631B1 (en) | Generating candidate links and candidate paths before selecting links for an optimized optical network plan | |
| US11212174B2 (en) | Network management device and network management method | |
| EP3588854B1 (en) | Determining and implementing egress peer engineering for destinations in a network | |
| US7835286B2 (en) | Dynamic multi-objective grid resources access | |
| US20190097917A1 (en) | Network system, network controller, method, and program | |
| US10210127B2 (en) | Storage system cabling analysis | |
| EP3716544B1 (en) | Utilizing segment routing data and network data to determine optimized network plans and to implement an optimized network plan | |
| EP3685567B1 (en) | Load shedding of traffic based on current load state of target capacity | |
| CN107491270B (zh) | 一种多控存储系统的资源访问方法及装置 | |
| Birke et al. | Power of redundancy: Designing partial replication for multi-tier applications | |
| CN112783673A (zh) | 一种调用链的确定方法、装置、计算机设备及存储介质 | |
| US11671486B1 (en) | Managing availability zone utilizing redundancy validation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20201012 |
|
| 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: 20211005 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20211018 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6973300 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |