Network function virtualization: Difference between revisions

Revision as of 12:51, 7 December 2021

Latest revision as of 00:22, 27 August 2025

(23 intermediate revisions by 20 users not shown)

Line 1:

{{Short description|Type of computing virtualization}}

'''Network functions virtualization''' (also '''network function virtualization''' or '''NFV''')<ref>{{Cite web | url=http://www.etsi.org/technologies-clusters/technologies/nfv |title = ETSI - Standards for NFV - Network Functions Virtualisation &#124; NFV Solutions}}</ref> is a [[network architecture]] concept that leverages the IT [[virtualization]] technologies to virtualize entire classes of [[network node]] functions into building blocks that may connect, or chain together, to create and deliver communication services.

NFV relies upon traditional server-[[virtualization]] techniques such as those used in enterprise IT. A '''virtualized network function''', or '''VNF''', is implemented within one or more [[virtual machines]] or [[OS-level virtualization|containers]] running different software and processes, on top of commercial off the shelf (COTS) high-volume servers, switches and storage devices, or even [[cloud computing]] infrastructure, instead of having custom hardware appliances for each network function thereby avoiding vendor lock-in.

For example, a virtual [[session border controller]] could be deployed to protect a network without the typical cost and complexity of obtaining and installing physical network protection units. Other examples of NFV include virtualized [[Network Loadload Balancingbalancing|load balancers]], [[Firewall (computing)|firewalls]], [[Intrusion detection system|intrusion detection devices]] and [[WAN optimization|WAN accelerators]] to name a few.<ref>{{cite web|title=Network Functions Virtualisation (NFV); Use NFV is present and SDN is future|url=http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf|access-date=6 June 2014}}</ref>

The decoupling of the network function software from the customized hardware platform realizes a flexible network architecture that enables agile network management, fast new service roll outs with significant reduction in CAPEX and OPEX.

==Background==

Product development within the telecommunication industry has traditionally followed rigorous standards for stability, protocol adherence and quality, reflected by the use of the term [[carrier grade]] to designate equipment demonstrating this high reliability and performance factor.<ref>{{cite journalmagazine|url=https://www.wired.com/insights/2013/03/how-low-cost-telecom-killed-five-9s-in-cloud-computing/ |title=How Low-Cost Telecom Killed Five 9s in Cloud Computing |journalmagazine=Wired |date= 2013-03-13|access-date=2016-06-27|last1=Stephenson |first1=Rick}}</ref> While this model worked well in the past, it inevitably led to long product cycles, a slow pace of development and reliance on proprietary or specific hardware, e.g., bespoke [[application-specific integrated circuit]]s (ASICs). This development model resulted in significant delays when rolling out new services, posed complex interoperability challenges and significant increase in CAPEX/OPEX when scaling network systems & infrastructure and enhancing network service capabilities to meet increasing network load and performance demands. Moreover, the rise of significant competition in communication service offerings from agile organizations operating at large scale on the public Internet (such as [[Google Talk]], [[Skype]], [[Netflix]]) has spurred service providers to look for innovative ways to disrupt the status quo and increase revenue streams.

==History==

In October 2012, a group of telecom operators published a [[white paper]]<ref name="white">{{cite web |title=Network Functions Virtualization— Introductory White Paper |publisher= ETSI |date= 22 October 2012 |url= https://docbox.etsi.org/isg/nfv/open/Publications_pdf/White%20Papers/NFV_White_Paper1_2012.pdf |access-date= 20 June 2013 }}</ref> at a conference in [[Darmstadt, Germany]], on [[software-defined networking]] (SDN) and [[OpenFlow]]. The Call for Action concluding the White Paper led to the creation of the Network Functions Virtualization (NFV) Industry Specification Group (ISG) <ref>{{cite web |title = Network Functions Virtualisation |work= ETSI Standards for NFV |url= https://www.etsi.org/technologies/nfv |access-date= 30 June 2020 }}</ref> within the [[European Telecommunications Standards Institute]] (ETSI). The ISG was made up of representatives from the telecommunication industry from Europe and beyond.<ref>{{Cite news |title= Tier 1 Carriers Tackle Telco SDN |date= 22 October 2012 |first1=Ray|last1=Le Maistre |work=Light Reading |url= http://www.lightreading.com/software-defined-networking/tier-1-carriers-tackle-telco-sdn/240135217 |access-date=20 June 2013 }}</ref><ref>{{cite web |title= Latest Agenda at SDN & OpenFlow World Congress |publisher= Layer123.com |url-status=dead |url= http://www.layer123.com/sdn-agenda/ |archive-date= October 14, 2012 |archive-url= https://web.archive.org/web/20121014053339/http://www.layer123.com/sdn-agenda/ |access-date= 20 June 2013}}</ref> ETSI ISG NFV addresses many aspects, including functional architecture, information model, data model, protocols, APIs, testing, reliability, security, future evolutions, etc.

The ETSI ISG NFV has announced the Release 5 of its specifications since May 2021 aiming to produce new specifications and extendingextend the already published specifications based on new features and enhancements.

Since the publication of the white paper, the group has produced over 100 publications,<ref>{{cite web |title=Standards for NFV: Network Functions Virtualisation |publisher= NFV Solutions |url=https://www.etsi.org/technologies/nfv |website=ETSI |language=en-gb}}</ref> which have gained wider acceptance in the industry and are being implemented in prominent open source projects like OpenStack, ONAP, Open Source MANO (OSM) to name a few. Due to active cross-liaison activities, the ETSI NFV specifications are also being referenced in other SDOs like 3GPP, IETF, ETSI MEC etc.

==Framework==

Line 23 ⟶ 24:

# Network functions virtualization management and [[Orchestration (computing)|orchestration]] architectural framework (NFV-MANO Architectural Framework) is the collection of all functional blocks, data repositories used by these blocks, and reference points and interfaces through which these functional blocks exchange information for the purpose of managing and orchestrating NFVI and VNFs.

The building block for both the NFVI and the NFV-MANO is the NFV platform. In the NFVI role, it consists of both virtual and physical processing and storage resources, and virtualization software. In its NFV-MANO role it consists of VNF and NFVI managers and virtualization software operating on a [[ControllerNetwork (computing)interface controller|hardware controller]]. The NFV platform implements carrier-grade features used to manage and monitor the platform components, recover from failures and provide effective security&nbsp;– all required for the public carrier network.

==Practical aspects==

A service provider that follows the NFV design implements one or more virtualized network functions, or ''VNFs''. A VNF by itself does not automatically provide a usable product or service to the provider's customers. To build more complex services, the notion of ''service chaining'' is used, where multiple VNFs are used in sequence to deliver a service.

Another aspect of implementing NFV is the ''orchestration'' process. To build highly reliable and scalable services, NFV requires that the network be able to instantiate VNF instances, monitor them, repair them, and (most important for a service provider business) bill for the services rendered. These attributes, referred to as carrier-grade<ref name="CG">{{cite web|title=Don't Confuse "High Availability" with "Carrier Grade" | url=http://embedded.communities.intel.com/community/en/blog/2014/04/04/don-t-confuse-high-availability-with-carrier-grade|archive-url=https://web.archive.org/web/20170703015358/https://embedded.communities.intel.com/community/en/blog/2014/04/04/don-t-confuse-high-availability-with-carrier-grade|archive-date=2017-07-03|publisher=Embedded Community|first1=Charlie|last1=Ashton|date=April 2014}}</ref> features, are allocated to an orchestration layer in order to provide high availability and security, and low operation and maintenance costs. Importantly, the orchestration layer must be able to manage VNFs irrespective of the underlying technology within the VNF. For example, an orchestration layer must be able to manage an [[Session border controller|SBC]] VNF from vendor X running on [[VMware]] [[vSphere]] just as well as an [[IP Multimedia Subsystem|IMS]] VNF from vendor Y running on KVM.

==Distributed NFV==

Line 47 ⟶ 48:

==Relationship to SDN==

Network Functions Virtualisation is highly complementary to [[Software-Defined Networking]] (SDN).<ref name="white">{{cite web |title=Network Functions Virtualization— Introductory White Paper |publisher= ETSI |date= 22 October 2012 |url= https://docbox.etsi.org/isg/nfv/open/Publications_pdf/White%20Papers/NFV_White_Paper1_2012.pdf |access-date= 20 June 2013 }}</ref>. In essence, SDN is an approach to building data networking equipment and software that separates and abstracts elements of these systems. It does this by decoupling the control plane and data plane from each other, such that the control plane resides centrally and the forwarding components remain distributed. The control plane interacts with both [[Northbound interface|northbound]] and [[Southbound interface|southbound]]. In the northbound direction the control plane provides a common abstracted view of the network to higher-level applications and programs using high-level APIs and novel management paradigms, such as Intent-based networking. In the southbound direction the control plane programs the forwarding behavior of the data plane, using device level APIs of the physical network equipment distributed around the network.

Thus, NFV is not dependent on SDN or SDN concepts, but NFV and SDN can cooperate to enhance the management of a NFV infrastructure and to create a more dynamic network environment. It is entirely possible to implement a virtualized network function (VNF) as a standalone entity using existing networking and orchestration paradigms. However, there are inherent benefits in leveraging SDN concepts to implement and manage an NFV infrastructure, particularly when looking at the management and orchestration of Network Services (NS), composed of different type of Network Functions (NF), such as Physical Network Functions (PNF) and VNFs, and placed between different geo-located NFV infrastructures, and that's why multivendor platforms are being defined that incorporate SDN and NFV in concerted ecosystems.<ref>{{cite web|url=http://www.cisco.com/go/esp|title=Platform to Multivendor Virtual and Physical Infrastructure}}</ref>

Line 53 ⟶ 54:

An NFV system needs a central orchestration and management system that takes operator requests associated with an NS or a VNF, translates them into the appropriate processing, storage and network configuration needed to bring the NS or VNF into operation. Once in operation, the VNF and the networks it is connected to potentially must be monitored for capacity and utilization, and adapted if necessary.<ref>{{Cite book|url=http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118900286.html|title=Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture.|last=Liyanage|first=Madhusanka|publisher=John Wiley|year=2015|isbn=978-1-118-90028-4|___location=UK|pages=1–438}}</ref>

All network control functions in an NFV infrastructure can be accomplished using SDN concepts and NFV could be considered one of the primary SDN use cases in service provider environments .<ref name="eve005">{{cite web |title=Report on SDN Usage in NFV Architectural Framework |publisher= ETSI |date= December 2015 |url= https://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/005/01.01.01_60/gs_nfv-eve005v010101p.pdf |access-date= 7 December 2021 }}</ref>. For example, within each NFV infrastructure site, a VIM could rely upon an SDN controller to setupset up and configure the overlay networks interconnecting (e.g. VXLAN) the VNFs and PNFs composing an NS. The SDN controller would then configure the NFV infrastructure switches and routers, as well as the network gateways, as needed. Similarly, a Wide Area Infrastructure Manager (WIM) could rely upon an SDN controller to setupset up overlay networks to interconnect NSs that are deployed to different geo-located NFV infrastructures. It is also apparent that many SDN use-cases could incorporate concepts introduced in the NFV initiative. Examples include where the centralized controller is controlling a distributed forwarding function that could in fact be also virtualized on existing processing or routing equipment.

==Industry impact==

NFV has proven a popular standard even in its infancy. Its immediate applications are numerous, such as virtualization of [[mobile base station]]s, [[platform as a service]] (PaaS), [[content delivery network]]s (CDN), fixed access and home environments.<ref>{{cite web|title=Network Functions Virtualization (NFV) Use Cases|url=http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf}}</ref> The potential benefits of NFV is anticipated to be significant. Virtualization of network functions deployed on general purpose standardized hardware is expected to reduce capital and operational expenditures, and service and product introduction times.<ref name="benefits">{{cite web|title=What's NFV – Network Functions Virtualization?|work=SDNCentral |url=http://www.sdncentral.com/whats-network-functions-virtualization-nfv/|publisher=SDN Central}}</ref><ref>{{cite web|title=Carrier Network Virtualization|url=http://carriernetworkvirtualization.com/company/network-functions-virtualisation-isg-nfv-etsi/|publisher=ETSI news}}</ref> Many major network equipment vendors have announced support for NFV.<ref>{{Cite news |title= Openwave Exec Discusses the Benefits, Challenges of NFV & SDN |work= Article |url= http://www.sdnzone.com/topics/software-defined-network/articles/359936-openwave-exec-discusses-benefits-challenges-nfv-sdn.htm |date= 12 November 2013 |access-date= 22 November 2013 |archive-url= https://web.archive.org/web/20160303214633/http://www.sdnzone.com/topics/software-defined-network/articles/359936-openwave-exec-discusses-benefits-challenges-nfv-sdn.htm |archive-date= 3 March 2016 |url-status= deadusurped }}</ref> This has coincided with NFV announcements from major software suppliers who provide the NFV platforms used by equipment suppliers to build their NFV products.<ref>{{cite web|url=http://www.serviceprovideritreport.com/author.asp?section_id=3098|title=Middleware for the NFV Generation|publisher=Service Provider IT Report|first=Lee|last=Doyle}}</ref><ref>{{cite web|url=http://www.policychargingcontrol.com/1643-wind-river-s-launches-nfv-ecosystem-program-with-initial-five-industry-leaders| title=Wind River Launches NFV Ecosystem Program with Five Industry Leaders|publisher=PCC Mobile Broadband|first1=Ray|last1=Sharma}}</ref>

However, to realize the anticipated benefits of virtualization, network equipment vendors are improving IT virtualization technology to incorporate carrier-grade attributes required to achieve [[high availability]], scalability, performance, and effective network management capabilities.<ref>{{cite web|title=Carrier-Grade Reliability—A "Must-Have" for NFV Success|url=http://electronicdesign.com/communications/carrier-grade-reliability-must-have-nfv-success|publisher=Electronic Design|first1=Charlie|last1=Ashton|date=January 2015}}</ref> To minimize the total cost of ownership (TCO), carrier-grade features must be implemented as efficiently as possible. This requires that NFV solutions make efficient use of redundant resources to achieve five-nines availability (99.999%),<ref>{{cite web|title=5 must-have attributes of an NFV platform|url=http://www2.alcatel-lucent.com/techzine/5-must-attributes-nfv-platform/ |archive-url=https://web.archive.org/web/20150526044023/http://www2.alcatel-lucent.com/techzine/5-must-attributes-nfv-platform/ |archive-date=2015-05-26|publisher=Techzine, Alcatel-Lucent|first1=Andreas|last1=Lemke|work=TechZine - Alcatel-Lucent |date=November 2014}}</ref> and of computing resource without compromising performance predictability.

The NFV platform is the foundation for achieving efficient carrier-grade NFV solutions.<ref>{{cite web|title=Why Service Providers Need an NFV Platform | url=https://networkbuilders.intel.com/docs/NP2013113597EN_NFV_Platform_StraWhitePaper.pdf | archive-url=https://web.archive.org/web/20150526045311/https://networkbuilders.intel.com/docs/NP2013113597EN_NFV_Platform_StraWhitePaper.pdf | archive-date=2015-05-26|publisher=Intel Strategic paper}}</ref> It is a software platform running on standard multi-core hardware and built using open source software that incorporates carrier-grade features. The NFV platform software is responsible for dynamically reassigning VNFs due to failures and changes in traffic load, and therefore plays an important role in achieving high availability. There are numerous initiatives underway to specify, align and promote NFV carrier-grade capabilities such as ETSI NFV Proof of Concept,<ref>{{cite web|url=http://www.etsi.org/technologies-clusters/technologies/nfv/nfv-poc|title=NFV Proof of Concept|publisher=ETSI}}</ref> ATIS<ref>{{cite web|title=New NFV Forum Focused on Interoperability|url=http://www.lightreading.com/nfv/nfv-strategies/new-nfv-forum-focused-on-interoperability/d/d-id/710874|publisher=Light Reading|first1=Carol|last1=Wilson|date=16 September 2015}}</ref> Open Platform for NFV Project,<ref>{{cite web|url=https://www.opnfv.org/|title=OPNFV|publisher=Linux Foundation Collaborative Projects Foundation}}</ref> Carrier Network Virtualization Awards<ref>{{cite web|url=http://carriernetworkvirtualization.com/carrier-network-virtualization-awards/|title=Carrier Network Virtualization Awards|archive-url=https://web.archive.org/web/20150607213250/http://carriernetworkvirtualization.com/carrier-network-virtualization-awards/|archive-date=2015-06-07|date=December 2015}}</ref> and various supplier ecosystems.<ref>{{cite web|title=Wind River's Ecosystemic Solution to NFV and Orchestration|url=https://blog.cimicorp.com/?p=1788|publisher=CIMI Corporation Public Blog|first1=Tom|last1=Nolle|date=June 2014}}</ref>

The vSwitch, a key component of NFV platforms, is responsible for providing connectivity both VM-to-VM (between VMs) and between VMs and the outside network. Its performance determines both the bandwidth of the VNFs and the cost-efficiency of NFV solutions. The standard [[Open vSwitch]]'s (OVS) performance has shortcomings that must be resolved to meet the needs of NFVI solutions.<ref>{{cite web|url=http://networkheresy.com/2014/11/13/accelerating-open-vswitch-to-ludicrous-speed/|title=Accelerating Open vSwitch to "Ludicruos Speed"|work=Network Heresy: Tales of the network reformation|first1=Justin|last1=Pettit|date=11 November 2014}}</ref> Significant performance improvements are being reported by NFV suppliers for both OVS and Accelerated Open vSwitch (AVS) versions.<ref>{{cite web|title=Wind River Delivers Breakthrough Performance for Accelerated vSwitch Optimized for NFV|url=http://www.windriver.com/news/press/pr.html?ID=12801|publisher=Wind River News Room|date=May 2014}}</ref><ref>{{cite web|title=6WIND Announces Open vSwitch Acceleration for Red Hat Enterprise Linux OpenStack Platform|url=httphttps://www.prweb.com/releases/2014/046wind_announces_open_vswitch_acceleration_for_red_hat_enterprise_linux_openstack_platform/prweb11768622.htm|publisher=PRweb|date=April 2014}}</ref>

Virtualization is also changing the way [[availability]] is specified, measured and achieved in NFV solutions. As VNFs replace traditional function-dedicated equipment, there is a shift from equipment-based availability to a service-based, end-to-end, layered approach.<ref>{{cite web|title=Network Functions Virtualization Challenges and Solutions|url=http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2013/9377-network-functions-virtualization-challenges-solutions.pdf|publisher=Alcatel-Lucent|year=2013}}</ref><ref>{{cite web|title=NFV: The Myth of Application-Level High Availability|url=http://www.windriver.com/whitepapers/nfv-myth-app/|archive-url=https://web.archive.org/web/20151005122643/http://www.windriver.com/whitepapers/nfv-myth-app/|archive-date=2015-10-05|publisher=Wind River|date=May 2015}}</ref> Virtualizing network functions breaks the explicit coupling with specific equipment, therefore availability is defined by the availability of VNF services. Because NFV technology can virtualize a wide range of network function types, each with their own service availability expectations, NFV platforms should support a wide range of fault tolerance options. This flexibility enables CSPs to optimize their NFV solutions to meet any VNF availability requirement.

Line 76 ⟶ 77:

The behavior of the NFVO and VNFM is driven by the contents of deployment templates (a.k.a. NFV descriptors) such as a Network Service Descriptor (NSD) and a VNF Descriptor (VNFD).

ETSI delivers a full set of standards '''enabling an open ecosystem''' where Virtualized Network Functions (VNFs) can be interoperable with independently developed management and orchestration systems, and where the components of a management and orchestration system are themselves interoperable. This includes a set of [[Representational state transfer|Restful API]] specifications<ref>{{Cite journal|last=Chatras|first=B.|date=December 2018|title=On the Standardization of NFV Management and Orchestration APIs|journal= IEEE Communications Standards Magazine|volume=2|issue=4|pages=66–71|doi=10.1109/MCOMSTD.2018.1800032|bibcode=2018ICStM...2d..66C |s2cid=59620488|issn=2471-2825}}</ref> as well as the specifications of a packaging format for delivering VNFs to service providers and of the deployment templates to be packaged with the software images to enable managing the lifecycle of VNFs. Deployment templates can be based on [[OASIS TOSCA|TOSCA]] or [[YANG]].<ref>{{Cite web|url=https://www.etsi.org/newsroom/press-releases/1540-2019-01-etsi-releases-a-standard-for-nfv-deployment-templates|title=ETSI - ETSI releases a standard for NFV Deployment Templates|last=ETSI COMS TEAM|website=ETSI|access-date=2019-07-09}}</ref><ref>{{Cite web|url=https://www.etsi.org/newsroom/blogs/entry/sol006-nfv-descriptors-based-on-yang-specification|title=Technology blogs, NFV, MEC, NGP, ZSM, ENI - SOL006 – NFV descriptors based on YANG Specification|website=www.etsi.org|access-date=2019-07-09}}</ref>

An [[OpenAPI Specification|OpenAPI]] (a.k.a. Swagger) representation of the API specifications is available and maintained on the ETSI forge [https://forge.etsi.org/gitlab/nfv server], along with TOSCA and YANG definition files to be used when creating deployment templates.

Line 82 ⟶ 83:

The full set of published specifications is summarized in the table below.

{| class="wikitable"

|!Specification

|!Title

|-

|[https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/001/ ETSI GS NFV-SOL 001]

Line 129 ⟶ 130:

|ETSI GS NFV-SOL [https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/016/ 016]

|NFV-MANO procedures specification

|-

|ETSI GS NFV-SOL [https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/018/ 018]

|Profiling specification of protocol and data model solutions for

OS Container management and orchestration

|}

An overview of the different versions of the OpenAPI representations of NFV-MANO APIs is available on the ETSI NFV [https://nfvwiki.etsi.org/index.php?title=SOL_OpenAPI_Representations wiki].

Line 137 ⟶ 142:

==Performance study==

Recent performance study on NFV focused on the throughput, latency and jitter of virtualized network functions (VNFs), as well as NFV scalability in terms of the number of VNFs a single physical server can support.<ref>{{cite journal|url=https://ieeexplore.ieee.org/document/7781548|title=Toward High-Performance and Scalable Network Functions Virtualization|year=2016|doi=10.1109/MIC.2016.111|last1=Wang|first1=Chengwei|last2=Spatscheck|first2=Oliver|last3=Gopalakrishnan|first3=Vijay|last4=Xu|first4=Yang|last5=Applegate|first5=David|journal=IEEE Internet Computing|volume=20|issue=6|pages=10–20|bibcode=2016IIC....20f..10W |s2cid=15518060}}</ref>

Open source NFV platforms are available, one representative is openNetVM.<ref name="OpenNetVM">{{cite journal|title=OpenNetVM: A Platform for High Performance Network Service Chains|url=http://faculty.cs.gwu.edu/timwood/papers/16-HotMiddlebox-onvm.pdf|doi=10.1145/2940147.2940155|doi-access=free|s2cid=13706879}}</ref> openNetVM is a high performance NFV platform based on DPDK and Docker containers. openNetVM provides a flexible framework for deploying network functions and interconnecting them to build service chains. openNetVM is an open source version of the NetVM platform described in NSDI 2014 and HotMiddlebox 2016 papers, released under the BSD license. The source code can be found at githubGitHub:openNetVM<ref>{{cite web|url=https://github.com/sdnfv/openNetVM|title=GitHub- OpenNetVM|website=[[GitHub]]}}</ref>

==Cloud-native Networknetwork Functionsfunctions==

From 2018, many VNF providers began to migrate many of their VNFs to a container-based architecture. Such VNFs also known as [[Cloud-Native Network Function]]s (CNF) utilize many innovations deployed commonly on internet infrastructure. These include auto-scaling, supporting a continuous delivery / DevOps deployment model, and efficiency gains by sharing common services across platforms. Through service discovery and orchestration, a network based on CNFs will be more resilient to infrastructure resource failures. Utilizing containers, and thus dispensing with the overhead inherent in traditional virtualization through the elimination of the [[Hardware virtualization|guest OS]] can greatly increase infrastructure resource efficiency.<ref>{{Cite web|title=Cloud-Native Network Functions|url=https://www.cisco.com/c/en/us/solutions/service-provider/industry/cable/cloud-native-network-functions.html|access-date=1 April 2021|website=Cisco}}</ref>

Line 149 ⟶ 154:

* [[OASIS TOSCA]]

* [[Open Platform for NFV]]

* [[Software-defined networking]]

==References==

Line 160 ⟶ 164:

* [https://www.ibm.com/services/network/what-is-nfv What are the benefits of NFV?]

[[Category:Emerging technologies]]

[[Category:Network architecture]]