Network function virtualization: Difference between revisions

Content deleted Content added
Bc-or-fr (talk | contribs)
Tag: references removed
Bc-or-fr (talk | contribs)
Line 65:
==Management and orchestration (MANO)==
[[ETSI]] has already indicated that an important part of controlling the NFV environment be done through automated orchestration. NFV Management and Orchestration (NFV-MANO) refers to a set of functions within an NFV system to manage and orchestrate the allocation of virtual infrastructure resources to virtualized network functions (VNFs) and network services (NSs). They are the brains of the NFV system and a key automation enabler.
 
The main functional blocks within the NFV-MANO architectural framework are:
* 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|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.
 
The full set of published specifications is summarized in the table below.