ネットワーク機能仮想化

ネットワーク機能仮想化（NFV）[ 1 ]は、IT仮想化技術を活用して、ネットワークノード機能のクラス全体を、接続または連鎖して通信サービスを作成および提供できるビルディングブロックに仮想化するネットワークアーキテクチャの概念です。

NFVは、エンタープライズITで使用されているような従来のサーバー仮想化技術に依存しています。仮想化ネットワーク機能（VNF ）は、市販の大容量サーバー、スイッチ、ストレージデバイス、あるいはクラウドコンピューティングインフラストラクチャ上に、異なるソフトウェアとプロセスを実行する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 を発表しています。

ホワイトペーパーの公開以来、ETSIグループは100以上の出版物[ 8 ]を発行しており、これらは業界で広く受け入れられ、OpenStack、ONAP、Open Source MANO（OSM）といった著名なオープンソースプロジェクトに実装されています。活発な相互連携活動により、ETSI NFV仕様は3GPP、IETF、ETSI MECなどの他の標準化団体でも参照されています。

フレームワーク

NFVフレームワークは3つの主要コンポーネントで構成されています。[ 9 ]

  1. 仮想化ネットワーク機能（VNF）は、ネットワーク機能仮想化インフラストラクチャ（NFVI）上に展開できるネットワーク機能のソフトウェア実装です。[ 10 ]
  2. ネットワーク機能仮想化インフラストラクチャ（NFVI）は、NFVが展開される環境を構築するすべてのハードウェアおよびソフトウェアコンポーネントの総体です。NFVインフラストラクチャは複数の拠点にまたがる場合があります。これらの拠点間の接続を提供するネットワークは、NFVインフラストラクチャの一部とみなされます。
  3. ネットワーク機能仮想化管理およびオーケストレーションアーキテクチャ フレームワーク (NFV-MANO アーキテクチャ フレームワーク) は、すべての機能ブロック、これらのブロックで使用されるデータ リポジトリ、およびこれらの機能ブロックが NFVI および VNF を管理およびオーケストレーションする目的で情報を交換するための参照ポイントとインターフェイスの集合です。

NFVIとNFV-MANOの両方の構成要素はNFVプラットフォームです。NFVIの役割では、仮想および物理処理およびストレージリソース、そして仮想化ソフトウェアで構成されます。NFV-MANOの役割では、VNFおよびNFVIマネージャー、そしてハードウェアコントローラー上で動作する仮想化ソフトウェアで構成されます。NFVプラットフォームは、プラットフォームコンポーネントの管理と監視、障害からの復旧、そして効果的なセキュリティの提供に使用されるキャリアグレードの機能を実装しています。これらはすべて、パブリックキャリアネットワークに必要な機能です。

実用的な側面

NFV設計に従うサービスプロバイダーは、1つ以上の仮想ネットワーク機能（VNF）を実装します。VNFだけでは、プロバイダーの顧客に利用可能な製品やサービスを自動的に提供することはできません。より複雑なサービスを構築するには、サービスチェイニングという概念が使用されます。サービスチェイニングでは、複数のVNFを順番に使用してサービスを提供します。

NFV実装のもう一つの側面は、オーケストレーションプロセスです。NFVでは、信頼性と拡張性に優れたサービスを構築するために、ネットワークがVNFインスタンスをインスタンス化し、監視、修復し、（サービスプロバイダービジネスにとって最も重要な）提供されたサービスに対して課金できることが求められます。キャリアグレード[ 11 ]機能と呼ばれるこれらの属性は、高可用性とセキュリティ、および低い運用保守コストを実現するために、オーケストレーション層に割り当てられます。重要なのは、オーケストレーション層がVNFの基盤となる技術に関係なくVNFを管理できなければならないということです。例えば、オーケストレーション層は、VMware vSphere上で稼働するベンダーXのSBC VNFだけでなく、 KVM上で稼働するベンダーYのIMS VNFも管理できなければなりません。

分散NFV

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 ]

NFVモジュール化の利点

VNFを提供するソフトウェアを設計・開発する際に、ベンダーはソフトウェアをソフトウェアコンポーネント（ソフトウェアアーキテクチャの実装ビュー）に構造化し、それらのコンポーネントを1つ以上のイメージ（ソフトウェアアーキテクチャのデプロイメントビュー）にパッケージ化することがあります。これらのベンダー定義のソフトウェアコンポーネントは、VNFコンポーネント（VNFC）と呼ばれます。VNFは1つ以上のVNFCで実装され、一般性を損なうことなく、VNFCインスタンスはVMイメージに1対1でマッピングされると想定されています。

VNFCは一般的にスケールアップおよび／またはスケールアウトが可能である必要があります。各VNFCインスタンスに柔軟な（仮想）CPUを割り当てることができるため、ネットワーク管理層はVNFCをスケールアップ（垂直方向のスケールアップ）し、単一システムまたは単一プラットフォーム上で期待されるスループット／パフォーマンスとスケーラビリティを提供できます。同様に、ネットワーク管理層は複数のプラットフォーム上で複数のVNFCインスタンスをアクティブ化することでVNFCをスケールアウト（水平方向のスケールアウト）できるため、他のVNFC機能の安定性を損なうことなく、パフォーマンスとアーキテクチャの仕様を満たすことができます。

このようなアーキテクチャブループリントの早期導入者は、すでにNFVモジュール化の原則を実装しています。[ 17 ]

SDNとの関係

ネットワーク機能仮想化は SDN と非常に補完的です。[ 4 ]本質的に、SDN はデータ ネットワーク機器とソフトウェアを構築するためのアプローチであり、これらのシステムの要素を分離して抽象化します。これは、制御プレーンとデータ プレーンを互いに分離することで実現され、制御プレーンは中央に配置され、転送コンポーネントは分散されたままになります。制御プレーンは、ノースバウンドとサウスバウンドの両方と対話します。ノースバウンド方向では、制御プレーンは、高レベル API とインテント ベース ネットワーキングなどの新しい管理パラダイムを使用して、ネットワークの共通の抽象化されたビューを上位レベルのアプリケーションとプログラムに提供します。サウスバウンド方向では、制御プレーンは、ネットワーク全体に分散された物理ネットワーク機器のデバイス レベル API を使用して、データ プレーンの転送動作をプログラムします。

このように、NFVはSDNやSDNの概念に依存するものではなく、NFVとSDNが連携することでNFVインフラストラクチャの管理を強化し、より動的なネットワーク環境を構築することができます。既存のネットワークおよびオーケストレーションパラダイムを用いて、仮想化ネットワーク機能（VNF）をスタンドアロンエンティティとして実装することは完全に可能です。しかし、SDNの概念を活用してNFVインフラストラクチャを実装・管理することには、固有の利点があります。特に、物理ネットワーク機能（PNF）やVNFなどの異なるタイプのネットワーク機能（NF）で構成され、異なる地理的に配置されたNFVインフラストラクチャ間に配置されたネットワークサービス（NS）の管理とオーケストレーションを考えると、その利点は顕著です。そのため、SDNとNFVを協調エコシステムに組み込んだマルチベンダープラットフォームが定義されています。[ 18 ]

NFVシステムには、NSまたはVNFに関連するオペレータのリクエストを受け取り、NSまたはVNFを運用するために必要な適切な処理、ストレージ、およびネットワーク構成に変換する、中央オーケストレーションおよび管理システムが必要です。運用開始後は、VNFとそれが接続されているネットワークの容量と使用率を監視し、必要に応じて調整する必要があります。[ 19 ]

NFV インフラストラクチャのすべてのネットワーク制御機能は SDN の概念を使用して実現でき、NFV はサービス プロバイダー環境における主要な SDN ユース ケースの 1 つと見なすことができます。[ 20 ]たとえば、各 NFV インフラストラクチャ サイト内では、VIM は SDN コントローラーに依存して、NS を構成する VNF と PNF を相互接続するオーバーレイ ネットワーク (VXLAN など) をセットアップおよび構成できます。その後、SDN コントローラーは必要に応じて NFV インフラストラクチャ スイッチとルーター、およびネットワーク ゲートウェイを構成します。同様に、広域インフラストラクチャ マネージャー (WIM) は SDN コントローラーに依存して、地理的に異なる場所にある NFV インフラストラクチャに展開されている NS を相互接続するオーバーレイ ネットワークをセットアップできます。多くの SDN ユース ケースに NFV イニシアチブで導入された概念を組み込むことができることも明らかです。例としては、集中型コントローラーが分散転送機能を制御している場合が挙げられますが、これは実際には既存の処理機器やルーティング機器上で仮想化することもできます。

業界への影響

NFVは初期段階から既に普及している標準規格です。その直接的な応用範囲は広く、モバイル基地局の仮想化、サービスとしてのプラットフォーム（PaaS）、コンテンツ配信ネットワーク（CDN）、固定アクセス、家庭環境など多岐にわたります。[ 21 ] NFVの潜在的なメリットは非常に大きいと予想されています。汎用の標準化されたハードウェア上に展開されたネットワーク機能を仮想化することで、設備投資と運用コストを削減し、サービスと製品の導入期間を短縮することが期待されています。[ 22 ] [ 23 ]多くの主要ネットワーク機器ベンダーがNFVのサポートを発表しています。[ 24 ]これは、機器サプライヤーがNFV製品を構築するために使用するNFVプラットフォームを提供する主要ソフトウェアサプライヤーからのNFV発表と一致しています。[ 25 ] [ 26 ]

しかし、仮想化の期待されるメリットを実現するために、ネットワーク機器ベンダーはIT仮想化技術を改良し、高可用性、拡張性、パフォーマンス、そして効果的なネットワーク管理機能を実現するために必要なキャリアグレードの属性を組み込んでいます。[ 27 ]総所有コスト（TCO）を最小限に抑えるには、キャリアグレードの機能を可能な限り効率的に実装する必要があります。そのためには、NFVソリューションが冗長リソースを効率的に活用し、ファイブナイン（99.999%）の可用性を実現し、[ 28 ]パフォーマンスの予測可能性を損なうことなくコンピューティングリソースを効率的に使用する必要があります。

NFVプラットフォームは、効率的なキャリアグレードのNFVソリューションを実現するための基盤です。[ 29 ]これは、標準的なマルチコアハードウェア上で動作し、キャリアグレードの機能を組み込んだオープンソースソフトウェアを使用して構築されたソフトウェアプラットフォームです。NFVプラットフォームソフトウェアは、障害やトラフィック負荷の変化に応じてVNFを動的に再割り当てする役割を担っており、高可用性を実現する上で重要な役割を果たします。ETSI NFV Proof of Concept、[ 30 ] ATIS [ 31 ] Open Platform for NFV Project、[ 32 ] Carrier Network Virtualization Awards [ 33 ]やさまざまなサプライヤーエコシステムなど、NFVのキャリアグレード機能の仕様策定、調整、推進を目的とした数多くの取り組みが進行中です。[ 34 ]

NFVプラットフォームの主要コンポーネントであるvSwitchは、VM間（VM間）およびVMと外部ネットワーク間の接続を提供する役割を担っています。vSwitchの性能は、VNFの帯域幅とNFVソリューションのコスト効率の両方を左右します。標準的なOpen vSwitch（OVS）の性能には欠点があり、NFVIソリューションのニーズを満たすためには解決が必要です。[ 35 ] NFVサプライヤーは、OVSとAccelerated Open vSwitch（AVS）の両方のバージョンにおいて、大幅な性能向上が報告されています。[ 36 ] [ 37 ]

仮想化は、NFVソリューションにおける可用性の仕様、測定、実現方法にも変化をもたらしています。VNFが従来の機能専用機器に取って代わるにつれ、機器ベースの可用性からサービスベースのエンドツーエンドの階層化アプローチへの移行が進んでいます。 [ 38 ] [ 39 ]ネットワーク機能の仮想化は特定の機器との明示的な結合を断ち切るため、可用性はVNFサービスの可用性によって定義されます。NFV技術は、それぞれ独自のサービス可用性の期待値を持つ幅広いネットワーク機能を仮想化できるため、NFVプラットフォームは幅広いフォールトトレランスオプションをサポートする必要があります。この柔軟性により、CSPはNFVソリューションを最適化し、あらゆるVNF可用性要件を満たすことができます。

管理とオーケストレーション（MANO）

ETSIは既に、NFV環境の制御における重要な部分を自動オーケストレーションによって実行することを示唆しています。NFV管理およびオーケストレーション（NFV-MANO）とは、仮想化ネットワーク機能（VNF）およびネットワークサービス（NS）への仮想インフラストラクチャリソースの割り当てを管理およびオーケストレーションするためのNFVシステム内の一連の機能を指します。これらはNFVシステムの頭脳であり、自動化を実現する重要な要素です。

NFV-MANO アーキテクチャ フレームワーク ( ETSI GS NFV-006 ) 内の主な機能ブロックは次のとおりです。

  • ネットワーク機能仮想化オーケストレーター (NFVO)
  • 仮想化ネットワーク機能マネージャー (VNFM)
  • 仮想化インフラストラクチャ マネージャー (VIM)。

NFV-MANO における外部の運用サポート システム (OSS) およびビジネス サポート システム (BSS) のエントリ ポイントは、NS インスタンスのライフサイクル管理を担当する NFVO です。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仕様[ 40 ]に加え、サービスプロバイダーにVNFを提供するためのパッケージングフォーマットや、VNFのライフサイクル管理を可能にするためにソフトウェアイメージにパッケージ化されるデプロイメントテンプレートの仕様も含まれます。デプロイメントテンプレートは、TOSCAまたはYANGをベースにすることができます。[ 41 ] [ 42 ]

API 仕様の OpenAPI (別名 Swagger) 表現は、デプロイメント テンプレートの作成時に使用される TOSCA および YANG 定義ファイルとともに、ETSI Forge サーバー上で使用可能かつ管理されています 。

公開されている仕様の全セットは、以下の表にまとめられています。

仕様 タイトル
ETSI GS NFV-SOL 001TOSCA仕様に基づくNFV記述子
ETSI GS NFV-SOL 002Ve-Vnfm 参照ポイントの RESTful プロトコル仕様
ETSI GS NFV-SOL 003Or-Vnfm 参照ポイントの RESTful プロトコル仕様
ETSI GS NFV-SOL 004VNF パッケージと PNFD アーカイブ仕様
ETSI GS NFV-SOL 005Os-Ma-nfvo 参照ポイントの RESTful プロトコル仕様
ETSI GS NFV-SOL 006YANG仕様に基づくNFV記述子
ETSI GS NFV-SOL 007ネットワークサービス記述子ファイル構造仕様
ETSI GS NFV-SOL 009NFV-MANO 管理のための RESTful プロトコル仕様
ETSI GS NFV-SOL 010VNFスナップショットパッケージ仕様
ETSI GS NFV-SOL 011Or-Or参照ポイントのRESTfulプロトコル仕様
ETSI GS NFV-SOL 012ポリシー管理インターフェースのRESTfulプロトコル仕様
ETSI GS NFV-SOL 013RESTful NFV MANO API の共通側面の仕様
ETSI GS NFV-SOL 014記述子ベースの仮想化リソース管理のための YAML データ モデル仕様
ETSI GS NFV-SOL 015RESTful NFV-MANO API のパターンと規約の仕様
ETSI GS NFV-SOL 016NFV-MANO手順仕様
ETSI GS NFV-SOL 018プロトコルとデータモデルソリューションのプロファイリング仕様

OSコンテナの管理とオーケストレーション

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のスケーラビリティに焦点が当てられています。[ 43 ] オープンソースのNFVプラットフォームが利用可能であり、その代表的なものの1つがopenNetVMです。[ 44 ] openNetVMは、DPDKとDockerコンテナに基づく高性能NFVプラットフォームです。openNetVMは、ネットワーク機能を展開し、それらを相互接続してサービスチェーンを構築するための柔軟なフレームワークを提供します。openNetVMは、NSDI 2014およびHotMiddlebox 2016の論文で説明されているNetVMプラットフォームのオープンソース版であり、BSDライセンスの下でリリースされています。ソースコードはGitHub:openNetVMにあります。[ 45 ]

クラウドネイティブネットワーク機能

2018年以降、多くのVNFプロバイダーが、自社のVNFの多くをコンテナベースのアーキテクチャに移行し始めました。クラウドネイティブネットワーク機能（CNF）とも呼ばれるこのようなVNFは、インターネットインフラで一般的に導入されている多くのイノベーションを活用しています。これには、自動スケーリング、継続的デリバリー/DevOps展開モデルのサポート、プラットフォーム間での共通サービス共有による効率性の向上などが含まれます。サービス検出とオーケストレーションにより、CNFベースのネットワークは、インフラリソースの障害に対する耐性が向上します。コンテナを活用し、ゲストOSを排除することで従来の仮想化に内在するオーバーヘッドを排除することで、インフラリソースの効率を大幅に向上させることができます。[ 46 ]

参照

参考文献

  1. ^ 「ETSI - NFV の標準 - ネットワーク機能仮想化 | NFV ソリューション」。
  2. ^ 「ネットワーク機能仮想化（NFV）；NFVは現在利用されており、SDNは将来利用される」（PDF） 。 2014年6月6日閲覧。
  3. ^ Stephenson, Rick (2013年3月13日). 「低コスト通信会社がクラウドコンピューティングにおけるファイブナインをどのように破壊したか」 . Wired . 2016年6月27日閲覧。
  4. ^ a b「ネットワーク機能仮想化 - 入門ホワイトペーパー」（PDF） ETSI、2012年10月22日。 2013年6月20日閲覧。
  5. ^ 「ネットワーク機能仮想化」。NFVのETSI標準。2020年6月30日閲覧。
  6. ^ Le Maistre, Ray (2012年10月22日). 「Tier 1キャリアが電気通信SDNに取り組む」Light Reading . 2013年6月20日閲覧。
  7. ^ 「SDN & OpenFlow World Congress 最新アジェンダ」 Layer123.com。2012年10月14日時点のオリジナルよりアーカイブ。 2013年6月20日閲覧。
  8. ^ 「NFVの標準：ネットワーク機能仮想化」 ETSI NFVソリューション。
  9. ^ 「ネットワーク機能仮想化 (NFV) の概念実証」。
  10. ^ 「ネットワーク機能仮想化（NFV）とは」blog.datapath.io . 2017年2月1日時点のオリジナルよりアーカイブ。 2017年1月20日閲覧。
  11. ^アシュトン、チャーリー（2014年4月）「「高可用性」と「キャリアグレード」を混同しないでください」「 . 埋め込みコミュニティ。 2017年7月3日にオリジナルからアーカイブ。
  12. ^ Tom Nolle (2013年9月18日). 「『分散NFV』は私たちに何かを教えてくれるのか？」 CIMI Corporationの公開ブログ. 2014年1月2日閲覧。
  13. ^ Carol Wilson (2013年10月3日). 「RADが分散NFV戦略を展開」 Light Reading . 2014年1月2日閲覧。
  14. ^ 「4つのベンダーがBTEに分散NFVを導入」 Light Reading、2014年6月11日。 2015年3月3日閲覧。
  15. ^ 「RAD、ETX NTUプラットフォームをベースとしたカスタマーエッジ分散NFVソリューションを発表」 Optical Keyhole、2014年6月16日。 2015年3月3日閲覧。
  16. ^ 「RADがD-NFVアライアンスに新たなパートナーを追加」 Telecompaper 、 2014年12月9日。 2015年3月3日閲覧。
  17. ^ TMCnet News (2014年6月26日). 「Qosmosが2014年インターネットテレフォニーNFVパイオニア賞を受賞」 TMC . 2014年6月26日閲覧。
  18. ^ 「マルチベンダーの仮想および物理インフラストラクチャへのプラットフォーム」。
  19. ^ Liyanage, Madhusanka (2015).ソフトウェア定義モバイルネットワーク (SDMN): LTE ネットワークアーキテクチャを超えて. 英国: John Wiley. pp.  1– 438. ISBN 978-1-118-90028-4。
  20. ^ 「NFVアーキテクチャフレームワークにおけるSDNの使用に関する報告書」（PDF） ETSI、2015年12月。 2021年12月7日閲覧。
  21. ^ 「ネットワーク機能仮想化 (NFV) のユースケース」(PDF)。
  22. ^ 「NFV（ネットワーク機能仮想化）とは？」 SDNCentral.SDN Central . 2014年7月26日時点のオリジナルよりアーカイブ。 2014年9月19日閲覧。
  23. ^ 「キャリアネットワーク仮想化」 ETSIニュース。2013年10月31日時点のオリジナルよりアーカイブ。 2014年9月19日閲覧。
  24. ^ 「Openwave幹部がNFVとSDNの利点と課題について語る」。記事。2013年11月12日。2016年3月3日時点のオリジナルよりアーカイブ。2013年11月22日閲覧。
  25. ^ Doyle, Lee. 「NFV世代のミドルウェア」サービスプロバイダーITレポート。
  26. ^ Sharma, Ray. 「ウインドリバー、業界リーダー5社とNFVエコシステムプログラムを開始」 PCCモバイルブロードバンド。
  27. ^アシュトン、チャーリー（2015年1月）「キャリアグレードの信頼性：NFVの成功に必須」 Electronic Design誌。
  28. ^ Lemke, Andreas (2014年11月). 「NFVプラットフォームに必須の5つの属性」 . TechZine - Alcatel-Lucent . Techzine, Alcatel-Lucent. 2015年5月26日時点のオリジナルよりアーカイブ。
  29. ^ 「サービスプロバイダーがNFVプラットフォームを必要とする理由」（PDF）。Intel戦略ペーパー。 2015年5月26日時点のオリジナル（PDF）からアーカイブ。
  30. ^ 「NFV概念実証」。ETSI。
  31. ^ウィルソン、キャロル（2015年9月16日）「相互運用性に焦点を当てた新しいNFVフォーラム」 Light Reading。
  32. ^ 「OPNFV」。Linux Foundation Collaborative Projects Foundation。
  33. ^ 「Carrier Network Virtualization Awards」 2015年12月。2015年6月7日時点のオリジナルよりアーカイブ。
  34. ^ Nolle, Tom (2014年6月). 「Wind RiverのNFVおよびオーケストレーション向けエコシステムソリューション」 . CIMI Corporation 公開ブログ.
  35. ^ペティット、ジャスティン（2014年11月11日）「Open vSwitchを「驚異的なスピード」に加速させる」「 。ネットワーク異端：ネットワーク改革の物語。」
  36. ^ 「ウインドリバー、NFV向けに最適化された高速vSwitchで画期的なパフォーマンスを実現」ウインドリバーニュースルーム、2014年5月。
  37. ^ 「6WIND、Red Hat Enterprise Linux OpenStack Platform向けOpen vSwitchアクセラレーションを発表」 PRweb、2014年4月。
  38. ^ 「ネットワーク機能仮想化の課題と解決策」（PDF）アルカテル・ルーセント、2013年。
  39. ^ 「NFV：アプリケーションレベルの高可用性の神話」 Wind River、2015年5月。 2015年10月5日時点のオリジナルよりアーカイブ。
  40. ^ Chatras, B. (2018年12月). 「NFV管理およびオーケストレーションAPIの標準化について」. IEEE Communications Standards Magazine . 2 (4): 66– 71. Bibcode : 2018ICStM...2d..66C . doi : 10.1109/MCOMSTD.2018.1800032 . ISSN 2471-2825 . S2CID 59620488 .  
  41. ^ ETSI COMS TEAM. 「ETSI - ETSIがNFVデプロイメントテンプレートの標準をリリース」 . ETSI . 2019年7月9日閲覧。
  42. ^ 「テクノロジーブログ、NFV、MEC、NGP、ZSM、ENI - SOL006 – YANG仕様に基づくNFV記述子」 www.etsi.org . 2019年7月9日閲覧。
  43. ^ Wang, Chengwei; Spatscheck, Oliver; Gopalakrishnan, Vijay; Xu, Yang; Applegate, David (2016). 「高性能かつスケーラブルなネットワーク機能仮想化に向けて」. IEEE Internet Computing . 20 (6): 10– 20. Bibcode : 2016IIC....20f..10W . doi : 10.1109/MIC.2016.111 . S2CID 15518060 . 
  44. ^ 「OpenNetVM：高性能ネットワークサービスチェーンのためのプラットフォーム」（PDF） . doi : 10.1145/2940147.2940155 . S2CID 13706879 . {{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  45. ^ 「GitHub-OpenNetVM」 . GitHub .
  46. ^ 「クラウドネイティブネットワーク機能」 . Cisco . 2021年4月1日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Network_function_virtualization&oldid=1318235139」より取得