ネットワーク機能仮想化(NFV)[ 1 ]は、IT仮想化技術を活用してネットワークノード機能のクラス全体を、通信サービスを作成および提供するために接続または連鎖できるビルディングブロックに仮想化するネットワークアーキテクチャの概念です。
NFVは、企業ITで使用されているような従来のサーバー仮想化技術に依存しています。仮想化ネットワーク機能(VNF )は、各ネットワーク機能ごとに専用のハードウェア機器を用意するのではなく、市販の既製品(COTS)の大容量サーバー、スイッチ、ストレージデバイス、あるいはクラウドコンピューティングインフラストラクチャ上で、異なるソフトウェアやプロセスを実行する1つ以上の仮想マシンまたはコンテナ内に実装されるため、ベンダーロックインを回避できます。
例えば、仮想セッション境界コントローラを導入すれば、物理的なネットワーク保護ユニットの入手や設置に伴う一般的なコストや複雑さを伴わずにネットワークを保護できます。NFVの他の例としては、仮想化されたロードバランサ、ファイアウォール、侵入検知装置、WANアクセラレータなどが挙げられます。[ 2 ]
ネットワーク機能ソフトウェアをカスタマイズされたハードウェアプラットフォームから分離することで、柔軟なネットワークアーキテクチャが構築され、俊敏なネットワーク管理、迅速な新サービス展開、そして設備投資(CAPEX)と運用コスト(OPEX)の大幅な削減が可能になります。
通信業界における製品開発は、従来、安定性、プロトコル準拠、品質に関する厳格な基準に従っており、この高い信頼性と性能を示す機器を指すためにキャリアグレードという用語が使われてきました。 [ 3 ] このモデルは過去にはうまく機能していましたが、必然的に製品サイクルが長くなり、開発ペースが遅くなり、専用または特定のハードウェア(例えば、特注のアプリケーション固有集積回路(ASIC))に依存することになりました。この開発モデルは、新しいサービスの展開時に大幅な遅延を引き起こし、複雑な相互運用性の課題をもたらし、ネットワーク負荷とパフォーマンス要求の増加に対応するためにネットワークシステムとインフラストラクチャを拡張し、ネットワークサービス機能を強化する際に、CAPEX/OPEXが大幅に増加しました。さらに、公共インターネット上で大規模に活動する機敏な組織( Google Talk、Skype、Netflixなど)による通信サービス提供における激しい競争の台頭により、サービスプロバイダーは現状を打破し、収益源を増やす革新的な方法を模索するようになりました。
2012 年 10 月、通信事業者グループがドイツのダルムシュタットで開催された会議で、ソフトウェア定義ネットワーク(SDN) とOpenFlowに関するホワイト ペーパー[ 4 ]を発表しました。ホワイト ペーパーの最後に示された行動要請により、欧州電気通信標準化機構(ETSI)内にネットワーク機能仮想化 (NFV) 業界仕様グループ (ISG) [ 5 ]が設立されました。ISG は、ヨーロッパ内外の電気通信業界の代表者で構成されていました。[ 6 ] [ 7 ] ETSI ISG NFV は、機能アーキテクチャ、情報モデル、データ モデル、プロトコル、API、テスト、信頼性、セキュリティ、将来の進化など、多くの側面を扱っています。
ETSI ISG NFVは、2021年5月以降、新たな仕様を作成し、新機能や機能強化に基づいて既に公開されている仕様を拡張することを目的として、仕様のリリース5を発表しました。
ホワイトペーパーの公開以来、このグループは100以上の出版物を制作しており[ 8 ] 、これらは業界で広く受け入れられ、OpenStack 、ONAP、Open Source MANO(OSM)などの著名なオープンソースプロジェクトで実装されています。活発なクロスリエゾン活動により、ETSI NFV仕様は3GPP、IETF、ETSI MECなどの他のSDOでも参照されています。
NFVフレームワークは3つの主要なコンポーネントで構成されています。[ 9 ]
NFVIとNFV-MANOの両方の構成要素はNFVプラットフォームです。NFVIの役割においては、仮想および物理的な処理・ストレージリソースと仮想化ソフトウェアで構成されます。NFV-MANOの役割においては、ハードウェアコントローラ上で動作するVNFおよびNFVIマネージャと仮想化ソフトウェアで構成されます。NFVプラットフォームは、プラットフォームコンポーネントの管理と監視、障害からの復旧、効果的なセキュリティの提供など、公衆通信事業者ネットワークに必要なキャリアグレードの機能を実装しています 。
NFV設計を採用するサービスプロバイダは、1つ以上の仮想化ネットワーク機能(VNF)を実装します。VNF単体では、プロバイダの顧客に利用可能な製品やサービスを自動的に提供するわけではありません。より複雑なサービスを構築するには、サービスチェーンという概念が用いられます。これは、複数のVNFを順番に使用してサービスを提供するものです。
NFV を実装するもう 1 つの側面は、オーケストレーションプロセスです。信頼性が高くスケーラブルなサービスを構築するには、NFV ではネットワークが VNF インスタンスをインスタンス化し、監視し、修復し、そして (サービス プロバイダー ビジネスにとって最も重要なこと) 提供されたサービスに対して課金できることが必要です。キャリア グレード[ 11 ]機能と呼ばれるこれらの属性は、高い可用性とセキュリティ、および低い運用保守コストを提供するために、オーケストレーション レイヤーに割り当てられます。重要なのは、オーケストレーション レイヤーは、VNF 内の基盤となるテクノロジーに関係なく、VNF を管理できる必要があるということです。たとえば、オーケストレーション レイヤーは、VMware vSphere上で動作するベンダー X のSBC VNF を、KVM 上で動作するベンダー Y のIMS VNFと同様に管理できる必要があります。
NFVの当初の認識は、仮想化機能はデータセンターに実装されるべきだというものでした。このアプローチは多くの場合有効ですが、すべての場合に有効とは限りません。NFVは、仮想化機能の物理的な配置場所に関して、可能な限り幅広い柔軟性を前提とし、それを重視しています。
したがって、理想的には、仮想化機能は最も効果的でコストが最も低い場所に配置されるべきです。つまり、サービスプロバイダは、データセンターからネットワークノード、顧客構内まで、あらゆる可能な場所にNFVを自由に配置できるべきです。分散NFVとして知られるこのアプローチは、NFVの開発と標準化の当初から強調されており、最近公開されたNFV ISG文書でも顕著に示されています。[ 12 ]
場合によっては、サービスプロバイダーがこの仮想化された機能を顧客の施設に配置することに明確な利点があります。これらの利点は、経済性からパフォーマンス、仮想化される機能の実現可能性まで多岐にわたります。[ 13 ]
ETSI NFV ISG が承認した最初の公開マルチベンダーD-NFV概念実証 (PoC)は、2014 年 6 月にシカゴでCyan, Inc.、RAD、Fortinet、Certes Networksによって実施され、CenturyLinkがスポンサーを務めました。これは、RAD の顧客エッジ専用 D-NFV 機器をベースとし、Fortinet の次世代ファイアウォール (NGFW) と Certes Networks の仮想暗号化/復号エンジンを仮想ネットワーク機能 (VNF) として実行し、Cyan の Blue Planet システムがエコシステム全体をオーケストレーションするというものでした。[ 14 ] RAD の D-NFV ソリューションは、顧客エッジで仮想化エンジンとして機能するD-NFV X86サーバー モジュールを搭載したレイヤ 2 /レイヤ 3ネットワーク終端装置 (NTU)であり、同月末までに商用利用可能になりました。[ 15 ] 2014年には、RADは新しいNFVアプリケーションを専門とするベンダーと国際的なシステムインテグレーターのエコシステムであるD-NFVアライアンスも組織した。[ 16 ]
VNFを提供するソフトウェアを設計・開発する際、ベンダーはソフトウェアをソフトウェアコンポーネント(ソフトウェアアーキテクチャの実装ビュー)に構造化し、それらのコンポーネントを1つ以上のイメージ(ソフトウェアアーキテクチャの展開ビュー)にパッケージ化することがあります。これらのベンダー定義のソフトウェアコンポーネントは、VNFコンポーネント(VNFC)と呼ばれます。VNFは1つ以上のVNFCで実装され、一般性を損なうことなく、VNFCインスタンスはVMイメージと1対1で対応付けられると想定されます。
VNFCは一般的にスケールアップおよび/またはスケールアウトが可能であるべきです。ネットワーク管理レイヤーは、各VNFCインスタンスに柔軟な(仮想)CPUを割り当てることで、VNFCをスケールアップ(垂直方向のスケール)し、単一システムまたは単一プラットフォーム上で期待されるスループット/パフォーマンスとスケーラビリティを実現できます。同様に、ネットワーク管理レイヤーは、複数のプラットフォーム上でVNFCの複数のインスタンスをアクティブ化することで、VNFCをスケールアウト(水平方向のスケール)し、他のVNFC機能の安定性を損なうことなく、パフォーマンスとアーキテクチャの仕様を満たすことができます。
ネットワーク機能仮想化は、SDN と非常に相補的です。[ 4 ]本質的に、SDN は、データ ネットワーク機器とソフトウェアを構築するためのアプローチであり、これらのシステムの要素を分離および抽象化します。これは、制御プレーンとデータ プレーンを互いに分離することによって行われ、制御プレーンは中央に配置され、転送コンポーネントは分散されたままになります。制御プレーンは、北向きと南向きの両方と相互作用します。北向きの方向では、制御プレーンは、高レベルの API とインテント ベース ネットワークなどの新しい管理パラダイムを使用して、上位レベルのアプリケーションとプログラムにネットワークの共通の抽象化されたビューを提供します。南向きの方向では、制御プレーンは、ネットワーク全体に分散している物理ネットワーク機器のデバイス レベルの API を使用して、データ プレーンの転送動作をプログラムします。
したがって、NFVはSDNやSDNの概念に依存していませんが、NFVとSDNは連携してNFVインフラストラクチャの管理を強化し、より動的なネットワーク環境を構築することができます。既存のネットワークおよびオーケストレーションパラダイムを使用して、仮想化ネットワーク機能(VNF)をスタンドアロンエンティティとして実装することは十分に可能です。しかし、特に物理ネットワーク機能(PNF)やVNFなど、さまざまな種類のネットワーク機能(NF)で構成され、地理的に異なるNFVインフラストラクチャ間に配置されたネットワークサービス(NS)の管理とオーケストレーションを考慮すると、NFVインフラストラクチャの実装と管理にSDNの概念を活用することには固有の利点があり、そのため、SDNとNFVを協調的なエコシステムに組み込んだマルチベンダープラットフォームが定義されています。[ 17 ]
NFVシステムには、NSまたはVNFに関連付けられたオペレータ要求を受け取り、NSまたはVNFを動作させるために必要な適切な処理、ストレージ、およびネットワーク構成に変換する中央オーケストレーションおよび管理システムが必要です。動作開始後は、VNFおよびそれが接続されているネットワークの容量と利用状況を監視し、必要に応じて適応させる必要があります。[ 18 ]
NFV インフラストラクチャのすべてのネットワーク制御機能は SDN の概念を使用して実現でき、NFV はサービス プロバイダ環境における主要な SDN ユース ケースの 1 つとみなすことができます。[ 19 ]例えば、各 NFV インフラストラクチャ サイト内で、VIM は SDN コントローラに依存して、NS を構成する VNF と PNF を相互接続するオーバーレイ ネットワーク (VXLAN など) をセットアップおよび構成することができます。SDN コントローラは、必要に応じて NFV インフラストラクチャ スイッチとルータ、およびネットワーク ゲートウェイを構成します。同様に、広域インフラストラクチャ マネージャ (WIM) は、SDN コントローラに依存して、地理的に異なる NFV インフラストラクチャに展開されている NS を相互接続するオーバーレイ ネットワークをセットアップすることができます。また、多くの SDN ユース ケースが NFV イニシアチブで導入された概念を取り入れることができることも明らかです。例としては、集中コントローラが分散転送機能を制御している場合があり、これは実際には既存の処理機器またはルーティング機器上で仮想化することもできます。
NFVは黎明期から人気のある標準規格であることが証明されています。モバイル基地局の仮想化、 PaaS( Platform as a Service)、コンテンツ配信ネットワーク(CDN)、固定アクセス、ホーム環境など、その即時のアプリケーションは多数あります。[ 20 ] NFVの潜在的なメリットは大きいと予想されています。汎用標準化ハードウェアに展開されたネットワーク機能の仮想化により、設備投資と運用コスト、サービスと製品の導入時間が削減されると予想されます。[ 21 ] [ 22 ]多くの主要なネットワーク機器ベンダーがNFVのサポートを発表しています。[ 23 ]これは、機器サプライヤーがNFV製品を構築するために使用するNFVプラットフォームを提供する主要なソフトウェアサプライヤーからのNFVの発表と一致しています。[ 24 ] [ 25 ]
しかし、仮想化の期待されるメリットを実現するために、ネットワーク機器ベンダーは、高可用性、拡張性、パフォーマンス、および効果的なネットワーク管理機能を実現するために必要なキャリアグレードの特性を組み込むように、IT仮想化技術を改善しています。[ 26 ]総所有コスト(TCO)を最小限に抑えるには、キャリアグレードの機能を可能な限り効率的に実装する必要があります。そのためには、NFVソリューションが冗長リソースを効率的に使用してファイブナイン(99.999%)の可用性[ 27 ]と、パフォーマンスの予測可能性を損なうことなくコンピューティングリソースを使用することが求められます。
NFVプラットフォームは、効率的なキャリアグレードNFVソリューションを実現するための基盤です。[ 28 ]これは、標準的なマルチコアハードウェア上で動作し、キャリアグレード機能を組み込んだオープンソースソフトウェアを使用して構築されたソフトウェアプラットフォームです。NFVプラットフォームソフトウェアは、障害やトラフィック負荷の変化に応じてVNFを動的に再割り当てする役割を担っており、高可用性を実現する上で重要な役割を果たしています。ETSI NFV Proof of Concept [ 29 ] 、 ATIS [ 30 ]、Open Platform for NFVプロジェクト[ 31 ] 、 Carrier Network Virtualization Awards [ 32 ] 、さまざまなサプライヤーエコシステム[ 33 ]など、NFVキャリアグレード機能の仕様策定、整合、推進に向けた数多くの取り組みが進行中です。
NFVプラットフォームの主要コンポーネントであるvSwitchは、VM間(VM間)とVMと外部ネットワーク間の接続を提供する役割を担っています。そのパフォーマンスは、VNFの帯域幅とNFVソリューションのコスト効率の両方を決定します。標準のOpen vSwitch(OVS)のパフォーマンスには、NFVIソリューションのニーズを満たすために解決しなければならない欠点があります。[ 34 ] NFVサプライヤーは、OVSとAccelerated Open vSwitch(AVS)バージョンの両方で大幅なパフォーマンス改善を報告しています。[ 35 ] [ 36 ]
仮想化は、NFV ソリューションにおける可用性の指定、測定、および達成方法も変えています。VNF が従来の機能専用機器に取って代わるにつれて、機器ベースの可用性からサービスベースのエンドツーエンドの階層型アプローチへと移行しています。 [ 37 ] [ 38 ]ネットワーク機能を仮想化すると、特定の機器との明示的な結合が解消されるため、可用性は VNF サービスの可用性によって定義されます。NFV テクノロジーは、それぞれ独自のサービス可用性の期待値を持つ幅広いネットワーク機能タイプを仮想化できるため、NFV プラットフォームは幅広いフォールトトレランス オプションをサポートする必要があります。この柔軟性により、CSP は、あらゆる VNF 可用性要件を満たすように NFV ソリューションを最適化できます。
ETSIは既に、NFV環境の制御において、自動化されたオーケストレーションが重要な役割を果たすことを示唆しています。NFV管理・オーケストレーション(NFV-MANO)とは、NFVシステム内で仮想インフラストラクチャリソースを仮想化ネットワーク機能(VNF)およびネットワークサービス(NS)に割り当てる管理とオーケストレーションを行う一連の機能を指します。これらはNFVシステムの頭脳であり、自動化を実現する上で重要な役割を担います。
NFV-MANOアーキテクチャフレームワーク(ETSI GS NFV-006)における主要な機能ブロックは以下のとおりです。
NFV-MANO における外部運用サポートシステム (OSS) およびビジネスサポートシステム (BSS) のエントリポイントは NFVO であり、これは NS インスタンスのライフサイクル管理を担当します。NS インスタンスを構成する VNF インスタンスのライフサイクル管理は、NFVO から 1 つ以上の VNFM に委任されます。NFVO と VNFM はどちらも、管理対象オブジェクトに仮想インフラストラクチャ リソースを割り当てるために、1 つ以上の VIM によって公開されるサービスを使用します。コンテナ化された VNF を管理するために、コンテナ インフラストラクチャ サービス管理 (CISM) 機能とコンテナ イメージ レジストリ (CIR) 機能という追加機能が使用されます。CISM はコンテナ化されたワークロードの維持を担当し、CIR は OS コンテナ ソフトウェア イメージの情報の保存と維持を担当します。NFVO と VNFM の動作は、ネットワーク サービス ディスクリプタ (NSD) や VNF ディスクリプタ (VNFD) などのデプロイメント テンプレート (別名 NFV ディスクリプタ) の内容によって決まります。
ETSI は、仮想化ネットワーク機能 (VNF) が独立して開発された管理およびオーケストレーション システムと相互運用可能であり、管理およびオーケストレーション システムのコンポーネント自体も相互運用可能なオープン エコシステムを実現する一連の標準を提供します。これには、一連のRESTful API仕様[ 39 ]と、サービス プロバイダに VNF を配信するためのパッケージ フォーマットの仕様、および VNF のライフサイクル管理を可能にするためにソフトウェア イメージとともにパッケージ化されるデプロイメント テンプレートの仕様が含まれます。デプロイメント テンプレートは、TOSCAまたはYANGに基づくことができます。[ 40 ] [ 41 ]
API仕様のOpenAPI(別名Swagger)表現は、ETSI forgeサーバー上で利用可能であり、維持管理されています。また、デプロイメントテンプレートを作成する際に使用するTOSCAおよびYANG定義ファイルも同サーバー上で提供されています。
公開されている仕様書の全容は、以下の表にまとめられています。
NFV-MANO APIのOpenAPI表現のさまざまなバージョンの概要は、ETSI NFV wikiで入手できます。
OpenAPIファイル、TOSCA YAML定義ファイル、およびNFV記述子に適用可能なYANGモジュールは、ETSI Forgeで入手できます。
ETSIでは、NFV-MANOフレームワークの自動化機能を向上させ、自律的な管理メカニズムを導入するための追加研究が進行中です(ETSI GR NFV-IFA 041を参照)。
NFV に関する最近のパフォーマンス調査では、仮想化ネットワーク機能 (VNF) のスループット、レイテンシ、ジッタ、および単一の物理サーバーがサポートできる VNF の数という観点からの NFV のスケーラビリティに焦点が当てられています。[ 42 ] オープンソースの NFV プラットフォームが利用可能であり、その代表例が openNetVM です。[ 43 ] openNetVM は、DPDK と Docker コンテナに基づく高性能 NFV プラットフォームです。openNetVM は、ネットワーク機能をデプロイして相互接続し、サービス チェーンを構築するための柔軟なフレームワークを提供します。openNetVM は、NSDI 2014 および HotMiddlebox 2016 の論文で説明されている NetVM プラットフォームのオープンソース バージョンであり、BSD ライセンスでリリースされています。ソース コードは GitHub:openNetVM で入手できます。[ 44 ]
2018 年以降、多くの VNF プロバイダーが、多くの VNF をコンテナベースのアーキテクチャに移行し始めました。クラウドネイティブネットワーク機能(CNF) としても知られるこれらの VNF は、インターネットインフラストラクチャで一般的に展開されている多くのイノベーションを活用しています。これには、自動スケーリング、継続的デリバリー / DevOps デプロイメントモデルのサポート、プラットフォーム間で共通サービスを共有することによる効率の向上などが含まれます。サービスディスカバリとオーケストレーションにより、CNF に基づくネットワークはインフラストラクチャリソースの障害に対してより回復力があります。コンテナを使用することで、ゲスト OSを排除することによって従来の仮想化に内在するオーバーヘッドを排除し、インフラストラクチャリソースの効率を大幅に向上させることができます。[ 45 ]