JP2020022020A - サービスチェイン収容装置、および、サービスチェイン収容方法 - Google Patents
サービスチェイン収容装置、および、サービスチェイン収容方法 Download PDFInfo
- Publication number
- JP2020022020A JP2020022020A JP2018143105A JP2018143105A JP2020022020A JP 2020022020 A JP2020022020 A JP 2020022020A JP 2018143105 A JP2018143105 A JP 2018143105A JP 2018143105 A JP2018143105 A JP 2018143105A JP 2020022020 A JP2020022020 A JP 2020022020A
- Authority
- JP
- Japan
- Prior art keywords
- service chain
- network function
- service
- vnf
- unit
- 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
- 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/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- 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/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
- H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or 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
- 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/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
-
- 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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- 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
-
- 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/302—Route determination based on requested QoS
- H04L45/306—Route determination based on the nature of the carried application
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/83—Admission control; Resource allocation based on usage prediction
-
- 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/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
- H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】正常時にはサービスチェインが用いるリソースの利用効率を高めつつ、失敗時でもサービスチェインの品質低下を抑制すること。【解決手段】サービスチェイン収容装置１は、サービスチェインの後段に位置するＶＮＦであるほど、また、複数のサービスチェインに共有されるＶＮＦであるほど、サービスチェインの処理失敗時の影響が大きいものとする影響係数を計算する影響係数算出部７１と、サービスチェインが通過する各ＶＮＦについて、収容可能な残りのリソース量を影響係数で補正する残リソース算出部７２と、残りのリソース量をもとに新規のサービスチェインを割り当てる収容設計部７３と、を有する。【選択図】図１
Description
本発明は、サービスチェイン収容装置、および、サービスチェイン収容方法に関する。
通信事業者が提供するサービスの品質を保証するギャランティ型と、サービスの品質を保証しないベストエフォート型とでは、それぞれメリットとデメリットにちがいがある。ギャランティ型では、リソースを特定のユーザに占有させるため、個々のユーザへの利用料金は高くなるが、サービス品質への満足度も高い。一方のベストエフォート型では、リソースを複数のユーザで共有させるため、個々のユーザへの利用料金は安くなるが、混雑時にサービス品質が低下してしまうこともある。
非特許文献１には、リソースの処理能力を超過するオーバブッキングの運用を認めて、ベストエフォート型を実現するための規格として、Controlled-Load Serviceが記載されている。
非特許文献１には、リソースの処理能力を超過するオーバブッキングの運用を認めて、ベストエフォート型を実現するための規格として、Controlled-Load Serviceが記載されている。
ベストエフォート型に用いられる共有リソースは、ネットワーク全体で負荷分散することで、なるべく一部の共有リソースにアクセスが集中しないようにすることが望ましい。
そこで、特許文献１には、ギャランティ型で使用する加入者回線の収容先を設計するときに、ベストエフォート型で使用する共有帯域の偏りを少なくするような収容設計を実現する回線収容設計装置が記載されている。なお、帯域とは、通信サービスにおけるデータ流通量に対する単位時間当たりの通信速度であり、帯域が大きくなるほど流せるデータ量も多くなる。
そこで、特許文献１には、ギャランティ型で使用する加入者回線の収容先を設計するときに、ベストエフォート型で使用する共有帯域の偏りを少なくするような収容設計を実現する回線収容設計装置が記載されている。なお、帯域とは、通信サービスにおけるデータ流通量に対する単位時間当たりの通信速度であり、帯域が大きくなるほど流せるデータ量も多くなる。
山本幹、「品質制御技術」、［online］、2018年6月9日、電子情報通信学会、3群（コンピュータネットワーク）−5編（通信品質）−3章、［2018年7月23日検索］、インターネット〈URL：http://www.ieice-hbkb.org/files/03/03gun_05hen_03.pdf〉
既存のネットワークサービスにおいて、各種ネットワーク機能は物理装置（アプライアンス）で提供されていた。そのため、ネットワーク機能の提供元となる物理装置が固定されてしまい、柔軟性に欠けていた。そこで、物理装置を用いて仮想装置（ＶＭ：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）である。
ＮＦＶ技術により仮想化されたネットワーク機能は、ＶＮＦ（Virtualized Network Function）と呼ばれる。ＶＮＦは、例えば、vCPE（Virtualized Customer Premises Equipment）、vRouter、vMitigator、vFW（Virtualized Firewall）、vLB（Virtualized Load Balancer）、vDPI（Virtualized deep packet inspection）である。
ＶＮＦをユーザごとに柔軟に選択・利用可能とする技術を、サービスチェイニングという。サービスチェイニングによって提供される一連のサービスをサービスチェインという。
サービスチェインによって、専用アプライアンスで提供されていたネットワーク機能を仮想化基盤上のソフトウェア（仮想マシン）群で実現することができる。つまり、NFV技術によって、ネットワーク機器をソフトウェアとハードウェアとに分離し、汎用サーバで構成された仮想化基盤上で実現したネットワーク機能群を、サービスチェイニングによって数珠つなぎにすることで１つのサービスとして提供する。
サービスチェインによって、専用アプライアンスで提供されていたネットワーク機能を仮想化基盤上のソフトウェア（仮想マシン）群で実現することができる。つまり、NFV技術によって、ネットワーク機器をソフトウェアとハードウェアとに分離し、汎用サーバで構成された仮想化基盤上で実現したネットワーク機能群を、サービスチェイニングによって数珠つなぎにすることで１つのサービスとして提供する。
図７は、サービスチェインの説明図である。
まず、物理資源のアプライアンスとして、各物理ノード［N1,…,N11］が、各物理リンク［L1,…,L14］で接続される物理的なネットワークシステムが構築されている。例えば、物理ノードN4と物理ノードN8とは、物理リンクL8で接続される。
この物理ノード上に仮想ノード［VM1,…,VM6］が形成され、その仮想ノード上でVNF［F1,…,F4］が動作しているとする。例えば、仮想ノードVM1上にはVNFのF1が動作している。
さらに、１つ以上のVNFは、サービスチェイン[A,B,C]によってそれぞれ束ねられている。以下、各サービスチェインが利用するVNFの詳細について、図８を参照して説明する。
まず、物理資源のアプライアンスとして、各物理ノード［N1,…,N11］が、各物理リンク［L1,…,L14］で接続される物理的なネットワークシステムが構築されている。例えば、物理ノードN4と物理ノードN8とは、物理リンクL8で接続される。
この物理ノード上に仮想ノード［VM1,…,VM6］が形成され、その仮想ノード上でVNF［F1,…,F4］が動作しているとする。例えば、仮想ノードVM1上にはVNFのF1が動作している。
さらに、１つ以上のVNFは、サービスチェイン[A,B,C]によってそれぞれ束ねられている。以下、各サービスチェインが利用する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」はサービスチェインＣだけに使用される。
サービスチェインＡは、始点の物理ノード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」はサービスチェインＣだけに使用される。
以上、図７，図８を参照して説明したサービスチェインにおいても、共有可能なVNF上にオーバブッキングして、ベストエフォート型で運用する場合を考える。
ここで、サービスチェインは、複数のVNFの処理を連携させて１つのサービスとして提供することから、サービスチェインの途中のVNFで処理が失敗してしまった場合、サービスチェインの最初から再処理しなければならない。つまり、失敗箇所よりも前段で実施したVNFの処理はすべて無駄になってしまい、前段のリソースの無駄遣いと、サービスチェインの品質低下とを生じさせてしまう。
ここで、サービスチェインは、複数のVNFの処理を連携させて１つのサービスとして提供することから、サービスチェインの途中のVNFで処理が失敗してしまった場合、サービスチェインの最初から再処理しなければならない。つまり、失敗箇所よりも前段で実施したVNFの処理はすべて無駄になってしまい、前段のリソースの無駄遣いと、サービスチェインの品質低下とを生じさせてしまう。
特許文献１などの従来のベストエフォート型技術では、ネットワーク全体で偏りを無くす設計ポリシのため、サービスチェインの後段になるほどVNFの処理失敗に対するダメージが大きくなるというサービスチェインの特性は考慮されていない。よって、サービスチェイン前段の処理を手戻りして再実行するためのコストが大きくなってしまう。
そこで、本発明は、正常時にはサービスチェインが用いるリソースの利用効率を高めつつ、失敗時でもサービスチェインの品質低下を抑制することを、主な課題とする。
前記課題を解決するために、本発明のサービスチェイン収容装置は、以下の特徴を有する。
本発明は、１つ以上のネットワーク機能部を通過するサービスチェインについて、前記サービスチェインの後段に位置する前記ネットワーク機能部であるほど、また、複数の前記サービスチェインに共有される前記ネットワーク機能部であるほど、前記サービスチェインの処理失敗時の影響が大きいものとする影響係数を計算する影響係数算出部と、
前記サービスチェインが通過する前記各ネットワーク機能部について、収容可能な残りのリソース量を前記影響係数で補正する残リソース算出部と、
新規の前記サービスチェインを収容するときに、新規の前記サービスチェインが通過する前記各ネットワーク機能部の要求されたリソース量を収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在するときには、その既存の前記ネットワーク機能部に新規の前記サービスチェインを割り当てるとともに、収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在しないときには、新規の前記ネットワーク機能部に新規の前記サービスチェインを割り当てる収容設計部と、を有することを特徴とする。
本発明は、１つ以上のネットワーク機能部を通過するサービスチェインについて、前記サービスチェインの後段に位置する前記ネットワーク機能部であるほど、また、複数の前記サービスチェインに共有される前記ネットワーク機能部であるほど、前記サービスチェインの処理失敗時の影響が大きいものとする影響係数を計算する影響係数算出部と、
前記サービスチェインが通過する前記各ネットワーク機能部について、収容可能な残りのリソース量を前記影響係数で補正する残リソース算出部と、
新規の前記サービスチェインを収容するときに、新規の前記サービスチェインが通過する前記各ネットワーク機能部の要求されたリソース量を収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在するときには、その既存の前記ネットワーク機能部に新規の前記サービスチェインを割り当てるとともに、収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在しないときには、新規の前記ネットワーク機能部に新規の前記サービスチェインを割り当てる収容設計部と、を有することを特徴とする。
これにより、サービスチェイン後段のネットワーク機能部になるほど、収容率を下げるようにサービスチェインの配置が設計される。また、複数のサービスチェインに共有されるネットワーク機能部ほど、収容率を下げるようにサービスチェインの配置が設計される。よって、正常時には、収容率の高いサービスチェイン前段の設計を行うことで、サービス提供者にとって設備投資を節約できる。失敗時には、収容率の低いサービスチェイン後段の設計を行うことで、手戻り量を減らすことができる。また、複数のサービスチェインに共有されるネットワーク機能部に対して収容率の低い設計を行うことで、失敗時には、当該ネットワーク機能部を共有する全てのサービスチェインにおける影響を低減することができる。よって、加入者にとってサービス断に対する不満を抑えることができる。
本発明は、前記残リソース算出部が、前記サービスチェインで要求されたリソース量を用いて、前記各ネットワーク機能部の収容可能な残りのリソース量の下限を計算することを特徴とする。
これにより、サービスチェイン後段のネットワーク機能部、および、複数のサービスチェインに共有されるネットワーク機能部では、サービスチェインで要求された多めのリソース量が確保されやすくなり、サービスチェインの処理失敗時の影響を下げることができる。
本発明は、前記残リソース算出部が、前記サービスチェインで過去に使用した実績値のリソース量を用いて、前記各ネットワーク機能部の収容可能な残りのリソース量の上限を計算することを特徴とする。
これにより、サービスチェイン前段のネットワーク機能部では、サービスチェインで過去に使用した実績値のリソース量だけ確保することで、妥当な範囲内でリソースの収容率を上げることができる。
本発明によれば、正常時にはサービスチェインが用いるリソースの利用効率を高めつつ、失敗時でもサービスチェインの品質低下を抑制することができる。
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
図１は、サービスチェイン収容装置１の構成図である。
サービスチェイン収容装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
サービスチェイン収容装置１の記憶部には、サービスチェイン管理テーブル１０（詳細は図２）と、影響係数管理テーブル２０（詳細は図３）と、残リソース管理テーブル３０（詳細は図４）と、サービスチェイントポロジ管理部４０（具体的には、図２のサービスチェイントポロジ４１、および、図５のサービスチェイントポロジ４２）と、新規サービスチェイン管理テーブル５０（詳細は図６）とが記憶される。
サービスチェイン収容装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
サービスチェイン収容装置１の記憶部には、サービスチェイン管理テーブル１０（詳細は図２）と、影響係数管理テーブル２０（詳細は図３）と、残リソース管理テーブル３０（詳細は図４）と、サービスチェイントポロジ管理部４０（具体的には、図２のサービスチェイントポロジ４１、および、図５のサービスチェイントポロジ４２）と、新規サービスチェイン管理テーブル５０（詳細は図６）とが記憶される。
サービスチェイン収容装置１は、処理部として、影響係数算出部７１と、残リソース算出部７２と、収容設計部７３とを有する。なお、以下の各処理部の説明は概要であり、それぞれの詳細は図３以降の説明で明らかにする。
影響係数算出部７１は、オーバフロー時の影響係数２８をＶＮＦ（ネットワーク機能部）ごとに計算する（詳細は図３）。影響係数の「影響」とは、ＶＮＦで処理が失敗した場合に、その失敗したＶＮＦより前段のサービスチェイン上での処理をどれだけ無駄にしたかを示す、サービスチェインに及ぼす影響である。
影響係数算出部７１は、オーバフロー時の影響係数２８をＶＮＦ（ネットワーク機能部）ごとに計算する（詳細は図３）。影響係数の「影響」とは、ＶＮＦで処理が失敗した場合に、その失敗したＶＮＦより前段のサービスチェイン上での処理をどれだけ無駄にしたかを示す、サービスチェインに及ぼす影響である。
残リソース算出部７２は、残帯域（残リソース）の設計値３５をＶＮＦごとに計算する（詳細は図４）。残帯域とは、各ＶＮＦにおいて、現時点で新たなサービスチェインをどれだけ収容可能かを示すリソースの余力である。残リソース算出部７２は、オーバフロー時の影響係数２８を用いて、残帯域の設計値３５を補正する。これにより、サービスチェイン前段のＶＮＦほど新たなサービスチェインを配置しやすくし、サービスチェイン後段のＶＮＦほど、また複数のサービスチェインに共有されるＶＮＦほど、新たなサービスチェインを配置しにくくする。
収容設計部７３は、残帯域の設計値３５に収容できる範囲で、新たなサービスチェインを配置する（詳細は図５，図６）。一方、収容設計部７３は、新たなサービスチェインの収容先が無いときには、新規のリソースを増設させる。
収容設計部７３は、残帯域の設計値３５に収容できる範囲で、新たなサービスチェインを配置する（詳細は図５，図６）。一方、収容設計部７３は、新たなサービスチェインの収容先が無いときには、新規のリソースを増設させる。
図２は、サービスチェイントポロジ管理部４０およびサービスチェイン管理テーブル１０の構成図である。
サービスチェイントポロジ管理部４０には、サービスチェイントポロジ４１が格納される。サービスチェイントポロジ４１には、図８で示したサービスチェインＡ，Ｂの具体的な経路が、始点から終点までの矢印に沿って定義されている。２つのサービスチェインの経路の一部分（Ｎ６→Ｎ１０→ＶＭ５）は、共通のデバイスを通過している。
サービスチェイントポロジ管理部４０には、サービスチェイントポロジ４１が格納される。サービスチェイントポロジ４１には、図８で示したサービスチェインＡ，Ｂの具体的な経路が、始点から終点までの矢印に沿って定義されている。２つのサービスチェインの経路の一部分（Ｎ６→Ｎ１０→ＶＭ５）は、共通のデバイスを通過している。
サービスチェイン管理テーブル１０は、サービスチェインＩＤ１１と、収容ユーザ数１２と、契約速度１３と、要求帯域１４とを対応付けるテーブルである。このサービスチェイン管理テーブル１０は、各ユーザのサービス契約内容に応じて、事前にネットワーク事業者により用意されている。
サービスチェインＩＤ１１で特定されるサービスチェインには、収容ユーザ数１２のユーザ分のトラフィックが収容される。サービスチェインごとの要求帯域１４は、サービスチェインごとの収容ユーザ数１２と、その各ユーザの契約速度１３との積である。
サービスチェインＩＤ１１で特定されるサービスチェインには、収容ユーザ数１２のユーザ分のトラフィックが収容される。サービスチェインごとの要求帯域１４は、サービスチェインごとの収容ユーザ数１２と、その各ユーザの契約速度１３との積である。
図３は、影響係数管理テーブル２０の構成図である。
影響係数管理テーブル２０は、ＶＮＦＩＤ２１と、所属サービスチェインＩＤ２２と、サービスチェイン別要求帯域２３と、ＶＮＦ別要求帯域２４と、サービスチェイン別各ＶＮＦにおける平均使用帯域２５と、サービスチェイン別累積平均使用帯域２６と、ＶＮＦ別累積平均使用帯域２７と、オーバフロー時の影響係数２８とを対応付ける。以下、影響係数管理テーブル２０の各要素について、その計算手順（手順１１）〜（手順１６）に沿って順に説明する。
なお、サービスチェイン別各ＶＮＦにおける平均使用帯域２５などの「平均」とは、サービスチェインが稼働する期間を所定期間（例えば１ヶ月間）に区切ったときの使用帯域の平均値であり、サービスチェインで過去に使用した実績値から求める。過去の記録値では、21時以降や土日は使用率が高くなるなどの時間帯や曜日などによって帯域の使用率が大きく変動してしまう。そこで、１ヶ月間などの長期の平均値を用いることとした。
影響係数管理テーブル２０は、ＶＮＦＩＤ２１と、所属サービスチェインＩＤ２２と、サービスチェイン別要求帯域２３と、ＶＮＦ別要求帯域２４と、サービスチェイン別各ＶＮＦにおける平均使用帯域２５と、サービスチェイン別累積平均使用帯域２６と、ＶＮＦ別累積平均使用帯域２７と、オーバフロー時の影響係数２８とを対応付ける。以下、影響係数管理テーブル２０の各要素について、その計算手順（手順１１）〜（手順１６）に沿って順に説明する。
なお、サービスチェイン別各ＶＮＦにおける平均使用帯域２５などの「平均」とは、サービスチェインが稼働する期間を所定期間（例えば１ヶ月間）に区切ったときの使用帯域の平均値であり、サービスチェインで過去に使用した実績値から求める。過去の記録値では、21時以降や土日は使用率が高くなるなどの時間帯や曜日などによって帯域の使用率が大きく変動してしまう。そこで、１ヶ月間などの長期の平均値を用いることとした。
（手順１１）ネットワーク事業者は、サービスチェイントポロジ４１を参照して、ＶＮＦＩＤ２１ごとの所属サービスチェインＩＤ２２を事前に入力しておく。例えば、図２のＶＮＦ＝Ｆ２（ＶＭ３）を通過するサービスチェインは、サービスチェインＡだけなので、ＶＮＦＩＤ２１＝Ｆ２と、所属サービスチェインＩＤ２２＝Ａとの組み合わせ情報が、事前に入力される。
（手順１２）影響係数算出部７１は、サービスチェインＩＤ１１ごとの要求帯域１４を、サービスチェイン別要求帯域２３とする。そして、影響係数算出部７１は、サービスチェイン別要求帯域２３をＶＮＦＩＤ２１ごとに合計したＶＮＦ別要求帯域２４を求める。
（手順１３）ネットワーク事業者は、サービスチェイン別要求帯域２３のおよそ５割〜６割が実際に使用されるなどの過去の統計情報などを参照して、サービスチェイン別各ＶＮＦにおける平均使用帯域２５を事前に入力しておく。例えばＶＮＦＩＤ２１＝Ｆ２について、100の要求帯域に0.5を乗算した結果の50を、サービスチェイン別各ＶＮＦにおける平均使用帯域２５とする。
（手順１２）影響係数算出部７１は、サービスチェインＩＤ１１ごとの要求帯域１４を、サービスチェイン別要求帯域２３とする。そして、影響係数算出部７１は、サービスチェイン別要求帯域２３をＶＮＦＩＤ２１ごとに合計したＶＮＦ別要求帯域２４を求める。
（手順１３）ネットワーク事業者は、サービスチェイン別要求帯域２３のおよそ５割〜６割が実際に使用されるなどの過去の統計情報などを参照して、サービスチェイン別各ＶＮＦにおける平均使用帯域２５を事前に入力しておく。例えばＶＮＦＩＤ２１＝Ｆ２について、100の要求帯域に0.5を乗算した結果の50を、サービスチェイン別各ＶＮＦにおける平均使用帯域２５とする。
（手順１４）影響係数算出部７１は、サービスチェインの経路の始点から終点まで辿ることで、サービスチェインの経路上の各地点（ＶＮＦ）におけるサービスチェイン別累積平均使用帯域２６を求める。
例えば、ＶＭ５上のＦ３は、サービスチェインＡにとっては経路の終点であり、ＶＭ３上のＦ２の後段に位置する。よって、サービスチェインＡのＦ３におけるサービスチェイン別累積平均使用帯域２６は、前段（Ｆ２）のサービスチェイン別各ＶＮＦにおける平均使用帯域２５＝50と、自身（Ｆ３）の50との合計（累積和）の100である。
一方、同じＶＭ５上のＦ３であっても、サービスチェインＢにとっては経路の始点側（１つめ）に位置する。よって、サービスチェインＢのＦ３におけるサービスチェイン別累積平均使用帯域２６は、前段のＶＮＦが存在しないため、そのまま自身のサービスチェイン別各ＶＮＦにおける平均使用帯域２５＝300となる。
例えば、ＶＭ５上のＦ３は、サービスチェインＡにとっては経路の終点であり、ＶＭ３上のＦ２の後段に位置する。よって、サービスチェインＡのＦ３におけるサービスチェイン別累積平均使用帯域２６は、前段（Ｆ２）のサービスチェイン別各ＶＮＦにおける平均使用帯域２５＝50と、自身（Ｆ３）の50との合計（累積和）の100である。
一方、同じＶＭ５上のＦ３であっても、サービスチェインＢにとっては経路の始点側（１つめ）に位置する。よって、サービスチェインＢのＦ３におけるサービスチェイン別累積平均使用帯域２６は、前段のＶＮＦが存在しないため、そのまま自身のサービスチェイン別各ＶＮＦにおける平均使用帯域２５＝300となる。
（手順１５）影響係数算出部７１は、サービスチェイン別累積平均使用帯域２６をＶＮＦＩＤ２１ごとに合計したＶＮＦ別累積平均使用帯域２７を求める。
（手順１６）影響係数算出部７１は、サービスチェイン別累積平均使用帯域２６の最大値（＝600）で、ＶＮＦＩＤ２１ごとのサービスチェイン別累積平均使用帯域２６（テーブルの上から順に600、50、400）を割り算した結果を、オーバフロー時の影響係数２８（ｋ）として求める。このオーバフロー時の影響係数２８が大きいＶＮＦであるほど、オーバフローなどのサービスチェインの異常が発生したときに、ユーザに与える影響（ダメージ）が大きい。換言すると、オーバフロー時の影響係数２８が小さいＶＮＦには、多くのサービスチェインを収容させることで、ネットワーク事業者の収益性を向上させることができる。
（手順１６）影響係数算出部７１は、サービスチェイン別累積平均使用帯域２６の最大値（＝600）で、ＶＮＦＩＤ２１ごとのサービスチェイン別累積平均使用帯域２６（テーブルの上から順に600、50、400）を割り算した結果を、オーバフロー時の影響係数２８（ｋ）として求める。このオーバフロー時の影響係数２８が大きいＶＮＦであるほど、オーバフローなどのサービスチェインの異常が発生したときに、ユーザに与える影響（ダメージ）が大きい。換言すると、オーバフロー時の影響係数２８が小さいＶＮＦには、多くのサービスチェインを収容させることで、ネットワーク事業者の収益性を向上させることができる。
図４は、残リソース管理テーブル３０の構成図である。
残リソース管理テーブル３０は、収容可能帯域３１と、残帯域３２と、理論的残帯域３３と、残帯域のギャップ値３４と、残帯域の設計値３５とを対応付ける。以下、残リソース管理テーブル３０の各要素について、その計算手順（手順２１）〜（手順２３）に沿って順に説明する。
（手順２１）ネットワーク事業者は、ＶＮＦＩＤ２１ごとの収容可能帯域３１を事前に入力しておく。もちろん、高性能なＶＭであるほど、そのＶＭ上で動作するＶＮＦには多くの帯域を収容することができる。なお、ＶＮＦ自体にも制約（収容帯域の上限）がある。例えば、ＶＮＦはライセンス販売されているものが多く、ＶＮＦに収容可能な帯域（収容可能帯域３１）などの性能値により価格が変動する。よって、効率的な収容設計が求められる。
残リソース管理テーブル３０は、収容可能帯域３１と、残帯域３２と、理論的残帯域３３と、残帯域のギャップ値３４と、残帯域の設計値３５とを対応付ける。以下、残リソース管理テーブル３０の各要素について、その計算手順（手順２１）〜（手順２３）に沿って順に説明する。
（手順２１）ネットワーク事業者は、ＶＮＦＩＤ２１ごとの収容可能帯域３１を事前に入力しておく。もちろん、高性能なＶＭであるほど、そのＶＭ上で動作するＶＮＦには多くの帯域を収容することができる。なお、ＶＮＦ自体にも制約（収容帯域の上限）がある。例えば、ＶＮＦはライセンス販売されているものが多く、ＶＮＦに収容可能な帯域（収容可能帯域３１）などの性能値により価格が変動する。よって、効率的な収容設計が求められる。
（手順２２）残リソース算出部７２は、ＶＮＦＩＤ２１ごとに、収容可能帯域３１からＶＮＦ別要求帯域２４を減算した結果を残帯域３２とする。そして、残リソース算出部７２は、収容可能帯域３１からサービスチェイン別各ＶＮＦにおける平均使用帯域２５を減算した結果を理論的残帯域３３とする。さらに、残リソース算出部７２は、理論的残帯域３３から残帯域３２を減算した結果を残帯域のギャップ値３４とする。
（手順２３）残リソース算出部７２は、以下の式により、残帯域の設計値３５を求める。
（残帯域の設計値３５）＝（残帯域のギャップ値３４）×（１−ｋ）＋（残帯域３２）
ｋは、オーバフロー時の影響係数２８である。サービスチェインの後段に位置するＶＮＦほど、また、複数サービスチェインに共有されるＶＮＦほど、オーバフロー時の影響係数２８は大きくなる。よって、残帯域の設計値３５は、理論的残帯域３３の値よりも残帯域３２の値に近づくことで、オーバフローしにくくなる。
（手順２３）残リソース算出部７２は、以下の式により、残帯域の設計値３５を求める。
（残帯域の設計値３５）＝（残帯域のギャップ値３４）×（１−ｋ）＋（残帯域３２）
ｋは、オーバフロー時の影響係数２８である。サービスチェインの後段に位置するＶＮＦほど、また、複数サービスチェインに共有されるＶＮＦほど、オーバフロー時の影響係数２８は大きくなる。よって、残帯域の設計値３５は、理論的残帯域３３の値よりも残帯域３２の値に近づくことで、オーバフローしにくくなる。
（手順２２）の補足説明として、例えば、ＶＮＦ＝Ｆ１は、1000の帯域の処理能力があり、そのＦ１に収容されるユーザは500の帯域を要求しているから、1000-500=500だけ処理能力の余力（残帯域３２）がある。しかし、ユーザは500の帯域を要求していながら300の帯域しか使用しないことが見込まれるので、1000-300=700だけ処理能力の余力（理論的残帯域３３）があるとも言える。つまり、要求帯域と使用帯域との間には、200の残帯域のギャップ値３４が存在する。
この残帯域のギャップ値３４が大きいＶＮＦであるほど、そのＶＮＦに多くのサービスチェインを収容させることで、新規ＶＮＦの増設を減らすことができ、設備コストを抑えることができる。
この残帯域のギャップ値３４が大きいＶＮＦであるほど、そのＶＮＦに多くのサービスチェインを収容させることで、新規ＶＮＦの増設を減らすことができ、設備コストを抑えることができる。
図５は、新規サービスチェインを追加するときのサービスチェイントポロジ管理部４０およびサービスチェイン管理テーブル１０の構成図である。
まず、図５のサービスチェイントポロジ４２は、図２のサービスチェイントポロジ４１に対して、新たにサービスチェインＣ，Ｄが追加したときのものである。同様に、図５のサービスチェイン管理テーブル１０は、図２のサービスチェイン管理テーブル１０に対して、新たにサービスチェインＣ，Ｄが追加したときのものである。以下、収容設計部７３が、新たなサービスチェインＣ，Ｄをどのようにネットワークに配置するかを計算する処理について、具体的に説明する。
まず、図５のサービスチェイントポロジ４２は、図２のサービスチェイントポロジ４１に対して、新たにサービスチェインＣ，Ｄが追加したときのものである。同様に、図５のサービスチェイン管理テーブル１０は、図２のサービスチェイン管理テーブル１０に対して、新たにサービスチェインＣ，Ｄが追加したときのものである。以下、収容設計部７３が、新たなサービスチェインＣ，Ｄをどのようにネットワークに配置するかを計算する処理について、具体的に説明する。
図６は、図５の新規サービスチェインＣ，Ｄを追加するときの残リソース管理テーブル３０および新規サービスチェイン管理テーブル５０の構成図である。
残リソース算出部７２は、図４で説明したように、図５の新規サービスチェインＣ，Ｄについても、残リソース管理テーブル３０の各項目を計算する（図６では残帯域の設計値３５だけを例示）。
影響係数算出部７１は、図４で説明したように、図５の新規サービスチェインＣ，Ｄについても、新規サービスチェイン管理テーブル５０の各項目を計算する。
・影響係数算出部７１は、影響係数管理テーブル２０のサービスチェイン別要求帯域２３の計算方法を用いて、新規サービスチェイン管理テーブル５０の新規サービスチェイン別要求帯域５１を計算する。
・影響係数算出部７１は、影響係数管理テーブル２０のＶＮＦ別要求帯域２４の計算方法を用いて、新規サービスチェイン管理テーブル５０の新規ＶＮＦ別要求帯域５２を計算する。
残リソース算出部７２は、図４で説明したように、図５の新規サービスチェインＣ，Ｄについても、残リソース管理テーブル３０の各項目を計算する（図６では残帯域の設計値３５だけを例示）。
影響係数算出部７１は、図４で説明したように、図５の新規サービスチェインＣ，Ｄについても、新規サービスチェイン管理テーブル５０の各項目を計算する。
・影響係数算出部７１は、影響係数管理テーブル２０のサービスチェイン別要求帯域２３の計算方法を用いて、新規サービスチェイン管理テーブル５０の新規サービスチェイン別要求帯域５１を計算する。
・影響係数算出部７１は、影響係数管理テーブル２０のＶＮＦ別要求帯域２４の計算方法を用いて、新規サービスチェイン管理テーブル５０の新規ＶＮＦ別要求帯域５２を計算する。
収容設計部７３は、残帯域の設計値３５と新規サービスチェイン管理テーブル５０とを比較することで、以下の（収容１）〜（収容３）の計算順に、新規サービスチェインＣ，Ｄに含まれる各ＶＮＦの収容先を決定する。なお、同じ処理内容のＶＮＦが、複数のＶＭにそれぞれ分散されて配置されることもある。そのときには、それぞれ分散されたＶＮＦの集合を、「同種のＶＮＦ」と呼ぶ。
（収容１）（既設された同種ＶＮＦの残帯域の設計値３５）≧（新規ＶＮＦ別要求帯域５２）であるときは、左辺の同種ＶＮＦに対して新規サービスチェインを収容する。例えば、（ＶＮＦ＝Ｆ２の残帯域の設計値３５＝449）≧（新規ＶＮＦ別要求帯域５２＝400）なので、サービスチェインＣのＦ２は既設のＦ２上に配置する。
（収容１）（既設された同種ＶＮＦの残帯域の設計値３５）≧（新規ＶＮＦ別要求帯域５２）であるときは、左辺の同種ＶＮＦに対して新規サービスチェインを収容する。例えば、（ＶＮＦ＝Ｆ２の残帯域の設計値３５＝449）≧（新規ＶＮＦ別要求帯域５２＝400）なので、サービスチェインＣのＦ２は既設のＦ２上に配置する。
（収容２）前記の（収容１）を満たさないＶＮＦの場合、（既設された同種ＶＮＦの残帯域の設計値３５）≧（新規サービスチェイン別要求帯域５１）であるときは、この式を満たす一部の新規サービスチェインだけを左辺の同種ＶＮＦに収容する。例えば、以下は、２つのサービスチェインを同時には収容できないが、どちらか一方だけは収容できる例である。
・（ＶＮＦ＝Ｆ３の残帯域の設計値３５＝482.5）≧（サービスチェインＣの新規サービスチェイン別要求帯域５１＝400）
・（ＶＮＦ＝Ｆ３の残帯域の設計値３５＝482.5）≧（サービスチェインＤの新規サービスチェイン別要求帯域５１＝450）
この場合、収容設計部７３は、例えば、既存のＶＮＦ＝Ｆ３にはサービスチェインＣを収容し、残りのサービスチェインＤは新規に増設するＶＮＦに収容すればよい。
・（ＶＮＦ＝Ｆ３の残帯域の設計値３５＝482.5）≧（サービスチェインＣの新規サービスチェイン別要求帯域５１＝400）
・（ＶＮＦ＝Ｆ３の残帯域の設計値３５＝482.5）≧（サービスチェインＤの新規サービスチェイン別要求帯域５１＝450）
この場合、収容設計部７３は、例えば、既存のＶＮＦ＝Ｆ３にはサービスチェインＣを収容し、残りのサービスチェインＤは新規に増設するＶＮＦに収容すればよい。
（収容３）前記の（収容１）も（収容２）も満たさないＶＮＦの場合、そのＶＮＦを新規増設し、増設したＶＮＦへ新規サービスチェインをすべて収容する。例えば、ＶＮＦ＝Ｆ４は、そもそも既設されたＶＮＦが１つも存在しないため、新規サービスチェインを収容するためのＶＮＦを新たに増設する必要がある。
以上、収容設計部７３は、（収容１）、（収容２）、（収容３）の順に新規サービスチェインを収容することにより、既設された同種ＶＮＦをなるべく活用して、収容率を高めることができる。つまり、新規サービスチェインを収容するためのＶＮＦの増設をなるべく抑制することで、インフラ事業者の収益性を向上できる。
以上、収容設計部７３は、（収容１）、（収容２）、（収容３）の順に新規サービスチェインを収容することにより、既設された同種ＶＮＦをなるべく活用して、収容率を高めることができる。つまり、新規サービスチェインを収容するためのＶＮＦの増設をなるべく抑制することで、インフラ事業者の収益性を向上できる。
以上説明した本実施形態では、影響係数算出部７１は、サービスチェイントポロジ４２を考慮して、サービスチェイン別累積平均使用帯域２６を計算した。
つまり、サービスチェインの後段になり、複数サービスチェインに共有されるＶＮＦほど、ＶＮＦ別累積平均使用帯域２７は増加していくので、オーバフロー時の影響係数２８も高くなる。
そして、収容設計部７３は、オーバフロー時の影響係数２８に応じて、サービスチェイン後段のＶＮＦになるほど収容率を下げるように各サービスチェインの配置を設計する。
これにより、ベストエフォート型における収容率が大きいＶＮＦがサービスチェイン前段に集中する一方で、収容率が小さいＶＮＦはサービスチェイン後段に集中する。よって、処理失敗時の影響が大きいサービスチェイン後段のＶＮＦであっても、少ないサービスチェインの割当により余裕ができることで、処理失敗時でもサービスチェインの品質低下を抑制することができる。
つまり、サービスチェインの後段になり、複数サービスチェインに共有されるＶＮＦほど、ＶＮＦ別累積平均使用帯域２７は増加していくので、オーバフロー時の影響係数２８も高くなる。
そして、収容設計部７３は、オーバフロー時の影響係数２８に応じて、サービスチェイン後段のＶＮＦになるほど収容率を下げるように各サービスチェインの配置を設計する。
これにより、ベストエフォート型における収容率が大きいＶＮＦがサービスチェイン前段に集中する一方で、収容率が小さいＶＮＦはサービスチェイン後段に集中する。よって、処理失敗時の影響が大きいサービスチェイン後段のＶＮＦであっても、少ないサービスチェインの割当により余裕ができることで、処理失敗時でもサービスチェインの品質低下を抑制することができる。
なお、サービスチェインはＶＮＦを複数選択し、数珠つなぎすることで１つのサービスを構築する技術である。数珠つなぎという構造特性から、後段のＶＮＦで処理が失敗したときほど、無駄になる前段での処理量が増加してしまい、サービスチェインの品質劣化の度合いも大きくなる。
そこで、本実施形態のサービスチェイン収容装置１は、このようなサービスチェインの構造特性をふまえて、サービスチェイン前段を密にＶＮＦに配置する一方でサービスチェイン後段を疎にＶＮＦに配置するように、不均衡な配置を計算することとした。
これにより、正常時には、収容率の高いサービスチェイン前段の設計を行うことで、サービス提供者にとって設備投資を節約できる。失敗時には、収容率の低いサービスチェイン後段の手戻り量を減らすことで、加入者にとってサービス断に対する不満を抑えることができる。
そこで、本実施形態のサービスチェイン収容装置１は、このようなサービスチェインの構造特性をふまえて、サービスチェイン前段を密にＶＮＦに配置する一方でサービスチェイン後段を疎にＶＮＦに配置するように、不均衡な配置を計算することとした。
これにより、正常時には、収容率の高いサービスチェイン前段の設計を行うことで、サービス提供者にとって設備投資を節約できる。失敗時には、収容率の低いサービスチェイン後段の手戻り量を減らすことで、加入者にとってサービス断に対する不満を抑えることができる。
さらに、残リソース算出部７２は、収容設計部７３が認識する残帯域の設計値３５として、ユーザの要求帯域をそのまますべて確保した後の残帯域３２と、ユーザの使用帯域だけを予想して確保した後の理論的残帯域３３との中間値を、オーバフロー時の影響係数２８に応じて計算することとした。
これにより、残帯域３２を用いるギャランティ型と、理論的残帯域３３を用いる収容率が大きいベストエフォート型との中間のバランスのよい収容率を実現できる。
これにより、残帯域３２を用いるギャランティ型と、理論的残帯域３３を用いる収容率が大きいベストエフォート型との中間のバランスのよい収容率を実現できる。
一方、残帯域３２を用いるギャランティ型では、図４で示すように、ＶＮＦ＝Ｆ３の残帯域３２＝400である。よって、収容設計部７３は、（収容２）において、サービスチェインＤの新規サービスチェイン別要求帯域５１＝450を収容できないため、Ｆ３の新規増設により収容率が落ちてしまう。
または、理論的残帯域３３を用いるベストエフォート型では、図４で示すように、ＶＮＦ＝Ｆ１の理論的残帯域３３＝700である。よって、収容設計部７３は、（収容１）において、サービスチェインＣの新規ＶＮＦ別要求帯域５２＝400を収容した後も、まだ残り300の余裕がある。しかし、この300の余裕により別のサービスチェインを収容することで、収容率は大きくできるが、過密なＶＮＦ＝Ｆ１の処理失敗のリスクは高まってしまう。
または、理論的残帯域３３を用いるベストエフォート型では、図４で示すように、ＶＮＦ＝Ｆ１の理論的残帯域３３＝700である。よって、収容設計部７３は、（収容１）において、サービスチェインＣの新規ＶＮＦ別要求帯域５２＝400を収容した後も、まだ残り300の余裕がある。しかし、この300の余裕により別のサービスチェインを収容することで、収容率は大きくできるが、過密なＶＮＦ＝Ｆ１の処理失敗のリスクは高まってしまう。
なお、本実施形態においては、本発明に係るサービスチェイン収容装置１は、図５に示すように、４種類のサービスチェインＡ〜Ｄを扱うこととしたが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービスチェイン収容装置１の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
１ サービスチェイン収容装置
１０ サービスチェイン管理テーブル
１１ サービスチェインＩＤ
１２ 収容ユーザ数
１３ 契約速度
１４ 要求帯域
２０ 影響係数管理テーブル
２１ ＶＮＦＩＤ
２２ 所属サービスチェインＩＤ
２３ サービスチェイン別要求帯域
２４ ＶＮＦ別要求帯域
２５ サービスチェイン別各ＶＮＦにおける平均使用帯域
２６ サービスチェイン別累積平均使用帯域
２７ ＶＮＦ別累積平均使用帯域
２８ オーバフロー時の影響係数
３０ 残リソース管理テーブル
３１ 収容可能帯域
３２ 残帯域
３３ 理論的残帯域
３４ 残帯域のギャップ値
３５ 残帯域の設計値
４０ サービスチェイントポロジ管理部
４１ サービスチェイントポロジ
４２ サービスチェイントポロジ
５０ 新規サービスチェイン管理テーブル
５１ 新規サービスチェイン別要求帯域
５２ 新規ＶＮＦ別要求帯域
７１ 影響係数算出部
７２ 残リソース算出部
７３ 収容設計部
１０ サービスチェイン管理テーブル
１１ サービスチェインＩＤ
１２ 収容ユーザ数
１３ 契約速度
１４ 要求帯域
２０ 影響係数管理テーブル
２１ ＶＮＦＩＤ
２２ 所属サービスチェインＩＤ
２３ サービスチェイン別要求帯域
２４ ＶＮＦ別要求帯域
２５ サービスチェイン別各ＶＮＦにおける平均使用帯域
２６ サービスチェイン別累積平均使用帯域
２７ ＶＮＦ別累積平均使用帯域
２８ オーバフロー時の影響係数
３０ 残リソース管理テーブル
３１ 収容可能帯域
３２ 残帯域
３３ 理論的残帯域
３４ 残帯域のギャップ値
３５ 残帯域の設計値
４０ サービスチェイントポロジ管理部
４１ サービスチェイントポロジ
４２ サービスチェイントポロジ
５０ 新規サービスチェイン管理テーブル
５１ 新規サービスチェイン別要求帯域
５２ 新規ＶＮＦ別要求帯域
７１ 影響係数算出部
７２ 残リソース算出部
７３ 収容設計部
Claims (4)
- １つ以上のネットワーク機能部を通過するサービスチェインについて、前記サービスチェインの後段に位置する前記ネットワーク機能部であるほど、また、複数の前記サービスチェインに共有される前記ネットワーク機能部であるほど、前記サービスチェインの処理失敗時の影響が大きいものとする影響係数を計算する影響係数算出部と、
前記サービスチェインが通過する前記各ネットワーク機能部について、収容可能な残りのリソース量を前記影響係数で補正する残リソース算出部と、
新規の前記サービスチェインを収容するときに、新規の前記サービスチェインが通過する前記各ネットワーク機能部の要求されたリソース量を収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在するときには、その既存の前記ネットワーク機能部に新規の前記サービスチェインを割り当てるとともに、収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在しないときには、新規の前記ネットワーク機能部に新規の前記サービスチェインを割り当てる収容設計部と、を有することを特徴とする
サービスチェイン収容装置。 - 前記残リソース算出部は、前記サービスチェインで要求されたリソース量を用いて、前記各ネットワーク機能部の収容可能な残りのリソース量の下限を計算することを特徴とする
請求項１に記載のサービスチェイン収容装置。 - 前記残リソース算出部は、前記サービスチェインで過去に使用した実績値のリソース量を用いて、前記各ネットワーク機能部の収容可能な残りのリソース量の上限を計算することを特徴とする
請求項１に記載のサービスチェイン収容装置。 - 影響係数算出部と、残リソース算出部と、収容設計部と、を有するサービスチェイン収容装置により実行されるサービスチェイン収容方法であって、
前記影響係数算出部は、１つ以上のネットワーク機能部を通過するサービスチェインについて、前記サービスチェインの後段に位置する前記ネットワーク機能部であるほど、また、複数の前記サービスチェインに共有される前記ネットワーク機能部であるほど、前記サービスチェインの処理失敗時の影響が大きいものとする影響係数を計算し、
前記残リソース算出部は、前記サービスチェインが通過する前記各ネットワーク機能部について、収容可能な残りのリソース量を前記影響係数で補正し、
前記収容設計部は、新規の前記サービスチェインを収容するときに、新規の前記サービスチェインが通過する前記各ネットワーク機能部の要求されたリソース量を収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在するときには、その既存の前記ネットワーク機能部に新規の前記サービスチェインを割り当てるとともに、収容可能な残りのリソース量をもつ既存の前記ネットワーク機能部が存在しないときには、新規の前記ネットワーク機能部に新規の前記サービスチェインを割り当てることを特徴とする
サービスチェイン収容方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018143105A JP6947134B2 (ja) | 2018-07-31 | 2018-07-31 | サービスチェイン収容装置、および、サービスチェイン収容方法 |
| PCT/JP2019/028118 WO2020026814A1 (ja) | 2018-07-31 | 2019-07-17 | サービスチェイン収容装置、および、サービスチェイン収容方法 |
| US17/262,600 US11552853B2 (en) | 2018-07-31 | 2019-07-17 | Service chain accomodation apparatus and service chain accommodation method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018143105A JP6947134B2 (ja) | 2018-07-31 | 2018-07-31 | サービスチェイン収容装置、および、サービスチェイン収容方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2020022020A true JP2020022020A (ja) | 2020-02-06 |
| JP6947134B2 JP6947134B2 (ja) | 2021-10-13 |
Family
ID=69231699
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018143105A Active JP6947134B2 (ja) | 2018-07-31 | 2018-07-31 | サービスチェイン収容装置、および、サービスチェイン収容方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US11552853B2 (ja) |
| JP (1) | JP6947134B2 (ja) |
| WO (1) | WO2020026814A1 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6947134B2 (ja) * | 2018-07-31 | 2021-10-13 | 日本電信電話株式会社 | サービスチェイン収容装置、および、サービスチェイン収容方法 |
| CN116893885B (zh) * | 2023-09-11 | 2024-01-26 | 中移(苏州)软件技术有限公司 | Java虚拟机调节方法、装置、电子设备及可读存储介质 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5489174B2 (ja) | 2011-01-06 | 2014-05-14 | 日本電信電話株式会社 | 回線収容設計装置、そのプログラム及び記録媒体 |
| US10111163B2 (en) * | 2015-06-01 | 2018-10-23 | Huawei Technologies Co., Ltd. | System and method for virtualized functions in control and data planes |
| KR101746202B1 (ko) * | 2015-06-09 | 2017-06-12 | 주식회사 케이티 | 네트워크 기능 가상화 방법 및 이를 위한 장치 |
| JP6363976B2 (ja) * | 2015-08-04 | 2018-07-25 | 日本電信電話株式会社 | サービスチェイン管理装置およびサービスチェイン管理方法 |
| EP3477471A4 (en) * | 2016-06-27 | 2019-06-12 | Nec Corporation | CONTROL DEVICE, VNF DEPLOYMENT DESTINATION SELECTION METHOD, AND PROGRAM |
| EP3583743A1 (en) * | 2017-02-16 | 2019-12-25 | Telefonaktiebolaget LM Ericsson (PUBL) | Method and apparatus for virtual function self-organisation |
| CN107147517A (zh) * | 2017-03-24 | 2017-09-08 | 上海交通大学 | 一种针对虚拟网络功能的自适应计算资源分配方法 |
| JP6947134B2 (ja) * | 2018-07-31 | 2021-10-13 | 日本電信電話株式会社 | サービスチェイン収容装置、および、サービスチェイン収容方法 |
-
2018
- 2018-07-31 JP JP2018143105A patent/JP6947134B2/ja active Active
-
2019
- 2019-07-17 US US17/262,600 patent/US11552853B2/en active Active
- 2019-07-17 WO PCT/JP2019/028118 patent/WO2020026814A1/ja active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020026814A1 (ja) | 2020-02-06 |
| JP6947134B2 (ja) | 2021-10-13 |
| US20210266227A1 (en) | 2021-08-26 |
| US11552853B2 (en) | 2023-01-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3637733B1 (en) | Load balancing engine, client, distributed computing system, and load balancing method | |
| Allybokus et al. | Virtual function placement for service chaining with partial orders and anti‐affinity rules | |
| US20200177673A1 (en) | Minimizing overhead of applications deployed in multi-clouds | |
| US9417903B2 (en) | Storage management for a cluster of integrated computing systems comprising integrated resource infrastructure using storage resource agents and synchronized inter-system storage priority map | |
| Yang et al. | Delay-sensitive and availability-aware virtual network function scheduling for NFV | |
| CN105103506B (zh) | 用于为云计算网络中的非均匀带宽请求分配带宽的方法和系统 | |
| US10616139B1 (en) | Reducing quota access | |
| CN106209402B (zh) | 一种虚拟网络功能的伸缩方法和设备 | |
| US10705873B2 (en) | Predictive virtual server scheduling and optimization of dynamic consumable resources to achieve priority-based workload performance objectives | |
| Draxler et al. | Joint optimization of scaling and placement of virtual network services | |
| US10374914B2 (en) | Rerouting data of a streaming application | |
| CN110636394B (zh) | 一种虚拟光网络映射方法、装置、设备及介质 | |
| US10802884B2 (en) | Efficient provisioning of an infrastructure based on different factors | |
| WO2020026814A1 (ja) | サービスチェイン収容装置、および、サービスチェイン収容方法 | |
| CN109194578B (zh) | 一种专线业务的开通方法及装置 | |
| Rankothge et al. | On the scaling of virtualized network functions | |
| US8548881B1 (en) | Credit optimization to minimize latency | |
| JP6455936B2 (ja) | 配置決定システム、配置決定方法及びプログラム | |
| US11258551B2 (en) | Service chain designing device, service chain designing method, and service chain designing program | |
| CN112685167A (zh) | 资源使用方法、电子设备和计算机程序产品 | |
| JP2019149043A (ja) | 見積り装置および見積り方法 | |
| Chi et al. | A privacy and price-aware inter-cloud system | |
| WO2020022018A1 (ja) | リソース割当装置、リソース管理システム、および、リソース割当プログラム | |
| KR20180052927A (ko) | 가상 머신 기반의 서비스 펑션 체이닝에 있어서 가상 머신의 배치 방법 | |
| CN110808866B (zh) | 一种配置数据传输资源的系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20201105 |
|
| 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: 20210817 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20210830 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6947134 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |