Content deleted Content added
m Task 18 (cosmetic): eval 22 templates: hyphenate params (13×); |
Citation bot (talk | contribs) Add: bibcode, work. Removed URL that duplicated identifier. Removed parameters. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 885/990 |
||
| (48 intermediate revisions by 27 users not shown) | |||
Line 1:
{{Short description|Type of computing virtualization}}
'''Network functions virtualization''' (
NFV relies upon
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
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
==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 |
The ETSI ISG NFV has announced the Release 5 of its specifications since May 2021 aiming to produce new specifications and extend 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==
The NFV framework consists of three main components:<ref>{{cite web |title=Network-Functions Virtualization (NFV) Proofs of Concept
# Virtualized network functions (VNFs) are software implementations of network functions that can be deployed on a network functions virtualization infrastructure (NFVI).<ref>{{cite web|url=http://blog.datapath.io/network-function-virtualization-nfv|title=What is Network Function Virtualization (NFV)|work=blog.datapath.io|access-date=2017-01-20|archive-url=https://web.archive.org/web/20170201235153/http://blog.datapath.io/network-function-virtualization-nfv|archive-date=2017-02-01|url-status=dead}}</ref>
# Network functions virtualization infrastructure (NFVI) is the totality of all hardware and software components that build the environment where NFVs are deployed. The NFV infrastructure can span several locations. The network providing connectivity between these locations is considered as part of the NFV infrastructure.
# 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 [[
==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">
==Distributed NFV==
Line 31 ⟶ 38:
For some cases there are clear advantages for a service provider to locate this virtualized functionality at the customer premises. These advantages range from economics to performance to the feasibility of the functions being virtualized.<ref>{{Cite news |title= RAD Rolls Out Distributed NFV Strategy |date= 3 October 2013 |author= Carol Wilson |work= Light Reading |url= http://www.lightreading.com/carrier-sdn/nfv-(network-functions-virtualization)/esdn-rad-rolls-out-distributed-nfv-strategy/d/d-id/705938 |access-date= 2 January 2014}}</ref>
The first ETSI NFV ISG-approved public multi-vendor [[Proof of concept#Engineering|proof of concept (PoC)]] of D-NFV was conducted by [[Cyan, Inc. (telecommunications company)|Cyan, Inc.]], [[RAD Data Communications|RAD]], [[Fortinet]] and Certes Networks in [[Chicago]] in June, 2014, and was sponsored by [[CenturyLink]]. It was based on RAD's dedicated customer-edge D-NFV equipment running Fortinet's Next Generation Firewall (NGFW) and Certes Networks’ virtual encryption/decryption engine as Virtual Network Functions (VNFs) with Cyan's Blue Planet system orchestrating the entire ecosystem.<ref name=poc>{{cite news|title=4 Vendors Bring Distributed NFV to BTE|url=http://www.lightreading.com/4-vendors-bring-distributed-nfv-to-bte/d/d-id/709403|publisher=Light Reading|date=June 11, 2014|access-date=March 3, 2015}}</ref> RAD's D-NFV solution, a [[Data link layer|Layer 2]]/[[Network layer|Layer 3]] [[Network interface device|network termination unit (NTU)]] equipped with a D-NFV [[X86]] server module that functions as a
==NFV modularity benefits==
Line 41 ⟶ 48:
==Relationship to SDN==
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>
▲In essence, software-defined networking (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 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 APIs. 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.
An NFV
▲Thus, NFV is not dependent on SDN or SDN concepts. 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 VNFs, and that's why multivendor platforms are being defined that incorporate SDN and NFV in concerted ecosystems.<ref>[http://www.cisco.com/go/esp Platform to Multivendor Virtual and Physical Infrastructure]</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 set 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 set 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.
▲An NFV infrastructure needs a central orchestration and management system that takes operator requests associated with a VNF, translates them into the appropriate processing, storage and network configuration needed to bring the VNF into operation. Once in operation, the VNF 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>
==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)
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>
The NFV platform is the foundation for achieving efficient carrier-grade NFV solutions.<ref>{{cite web|title=Why Service Providers Need an
▲Need an [https://networkbuilders.intel.com/docs/NP2013113597EN_NFV_Platform_StraWhitePaper.pdf NFV Platform'] {{Webarchive|url=https://web.archive.org/web/20150526045311/https://networkbuilders.intel.com/docs/NP2013113597EN_NFV_Platform_StraWhitePaper.pdf |date=2015-05-26 }}, 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>[http://www.etsi.org/technologies-clusters/technologies/nfv/nfv-poc NFV Proof of Concept]</ref> ATIS<ref>'New [http://www.lightreading.com/nfv/nfv-strategies/new-nfv-forum-focused-on-interoperability/d/d-id/710874 NFV Forum] Focused on Interoperability', Light Reading, Carol Wilson, September 16, 2015</ref> Open Platform for NFV Project,<ref>OPNFV, Linux Foundation Collaborative Projects Foundation webpage</ref> Carrier Network Virtualization Awards<ref>[http://carriernetworkvirtualization.com/carrier-network-virtualization-awards/ Carrier Network Virtualization Awards] {{webarchive|url=https://web.archive.org/web/20150607213250/http://carriernetworkvirtualization.com/carrier-network-virtualization-awards/ |date=2015-06-07 }} 2014, December 2015</ref> and various supplier ecosystems.<ref>'Wind River’s Ecosystemic Solution to NFV and Orchestration', CIMI Corporation Public Blog, Tom Nolle, 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>
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>
==Management and orchestration (MANO)==
[[ETSI]] has already indicated that an important part of controlling the NFV environment be done through
The main functional blocks within the NFV-MANO architectural framework ([https://www.etsi.org/deliver/etsi_gs/NFV/001_099/006/02.01.01_60/gs_nfv006v020101p.pdf ETSI GS NFV-006] ) are:
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|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>▼
* Network Functions Virtualisation Orchestrator (NFVO);
* Virtualised Network Function Manager (VNFM);
* Virtualised Infrastructure Manager (VIM).
The entry point in NFV-MANO for external operations support systems (OSS) and business support systems (BSS) is the NFVO, which is in charge of managing the lifecycle of NS instances. The management of the lifecycle of VNF instances constituting an NS instance is delegated by the NFVO to one more or VNFMs. Both the NFVO and the VNFMs uses the services exposed by one or more VIMs for allocating virtual infrastructure resources to the objects they manage. Additional functions are used for managing containerized VNFs: the Container Infrastructure Service Management (CISM) and the Container Image Registry (CIR) functions. The CISM is responsible for maintaining the containerized workloads while the CIR is responsible for storing and maintaining information of OS container software images
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 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.▼
▲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.
The full set of published specifications is summarized in the table below.
{| class="wikitable"
|-
|[https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/001/ ETSI GS NFV-SOL 001]
Line 99 ⟶ 109:
|[https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/009/ ETSI GS NFV-SOL 009]
|RESTful protocols specification for the management of NFV-MANO
|-
|ETSI GS NFV-SOL [https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/010/ 010]
|VNF Snapshot Package specification
|-
|[https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/011/ ETSI GS NFV-SOL 011]
|RESTful protocols specification for the Or-Or Reference Point
|-
|ETSI GS NFV-SOL [https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/012/ 012]
|RESTful protocols specification for the Policy Management interface
|-
|[https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/ ETSI GS NFV-SOL 013]
|Specification of common aspects for RESTful NFV MANO APIs
|-
|ETSI GS NFV-SOL [https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/014/ 014]
|YAML data model specification for descriptor-based virtualised resource management
|-
|ETSI GS NFV-SOL [https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/015/ 015]
|Specification of Patterns and Conventions for RESTful NFV-MANO APIs
|-
|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].
The OpenAPI files as well as the TOSCA YAML definition files and YANG modules applicable to NFV descriptors are available on the ETSI [https://forge.etsi.org/rep/nfv Forge].
Additional studies are ongoing within ETSI on possible enhancement to the NFV-MANO framework to improve its automation capabilities and introduce autonomous management mechanisms (see [https://www.etsi.org/deliver/etsi_gr/NFV-IFA/001_099/041/04.01.01_60/ ETSI GR NFV-IFA 041] )
==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>
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
==Cloud-native network functions==
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>
==See also==
Line 118 ⟶ 154:
* [[OASIS TOSCA]]
* [[Open Platform for NFV]]
==References==
Line 129 ⟶ 164:
* [https://www.ibm.com/services/network/what-is-nfv What are the benefits of NFV?]
[[Category:Network architecture]]
| |||