ETSI NFV, the Pillar for Cloud Ready ICT Deployments
Cristina Badulescu1 and Joan Triay2
1 Vice-Chairman of ETSI NFV ISG, Ericsson, Canada
2 Technical Manager of ETSI NFV ISG, DOCOMO Euro-Labs, Germany
E-mail: cristina.badulescu@ericsson.com; triay@docomolab-euro.com
Received 04 March 2019; Accepted 20 May 2019
Since the first standardized Network Functions Virtualisation (NFV) Management and Orchestration (MANO) framework released in 2014, the ETSI NFV Industry Specification Group (ISG) has evolved the architecture, the interface specifications and the Information Model over two releases. With the Release 3 now unfolding, new NFV features are studied and delivered via normative specifications to enable faster, automated webscale deployment and orchestration of multi-access telecom systems as well as distributed edge systems via interoperable ETSI NFV standard based solutions.
While agnostic to the applications and technologies of the systems being deployed and orchestrated (e.g. 4G, 5G, enterprise solutions at customer premises), the ETSI NFV-MANO framework offers the architecture, interfaces and models that enable deployments of multi-vendor orchestration solutions. ETSI NFV management and orchestration supports deployment and provisioning of Virtual Network Functions (VNFs) independent of the type of runtime Virtual Machine (VM) or containers. In ETSI NFV ISG we keep our specifications relevant for the market and compatible with related industry standards and widely adopted open source de facto standards.
This is an Open Access publication. © 2019 the Author(s). All rights reserved.
Close collaboration is key with industry standards bodies such as 3GPP SA5, IETF, NGMN, ITU-T, MEF and open source initiatives with industry traction like the Linux Foundation’s and OpenStack.
Keywords: Virtualization, NFV, NFV Infrastructure, Cloud ready, Management, Orchestration, Automation, 5G, 4G, multi-access, access independent, Datacenter, Information Communication Technologies (ICT), Cloud enabler, interoperable standard, open source, edge computing, cloud native, containers, VNF, PNF, Network Service, VNF Forwarding Graph, Network Forwarding Path, Virtual Links, multi-site, multi-administrative domains, network slicing, VNF upgrades, NFVI Upgrades, VNF Snapshots, lifecycle management, virtual resources.
The merge of the traditional and digital economies resulted in new business models that heavily rely on digital services and data.
ETSI NFV Industry Specification Group (ISG) enables flexibility, opti-mization and is a step towards zero-touch automation of ICT networks. The ISG delivers an architectural framework that enables innovation and new services to be rapidly developed and deployed anywhere in the network making efficient use of the service provider resources.
At the same time, network transformation via NFV technologies is a key step in the network preparation for 5G deployments, where base requirements for low latency, multi-access, high bandwidth, high performance, zero-touch management and automation, as well as worldwide connectivity of multi-vendor systems must be fulfilled.
Network Functions Virtualisation (NFV) introduces a new set of management and orchestration functions in addition to existing Element Management (EM) and Operations Support Systems (OSS) functions. This new set of management and orchestration functions is referred as Network Functions Virtualisation Management and Orchestration (NFV-MANO), and is used to manage and orchestrate:
The ETSI NFV Architectural Framework with the main functional blocks and reference points is depicted below in Figure 1, with the NFV-MANO subset marked on the right-hand side of the figure.
The NFV-MANO, which was originally described in the ETSI GS NFV- MAN 001 [1], comprises the following functional blocks:
The NFVO has two main responsibilities:
The VNFM is mainly responsible for the lifecycle management of VNF instances.
The VIM is responsible for controlling and managing NFVI compute, storage and network resources. The VIM manages the association of the virtualised resources to the physical compute, storage and networking resources.
After the initial publication of the architecture framework for virtualization, management and orchestration in the ETSI GS NFV-MAN 001 [1], the ETSI NFV ISG further detailed the framework as part of the NFV Release 2 efforts. One of the main objectives in this Release was the specification of interfaces and descriptors seeking for interoperability in a multi-vendor environment according to the framework. The specification process culminated with the delivery of stage 3 level specifications with the interface protocols for the NFV-MANO reference points, and the data models for the VNF and NS descriptors.
The NFV Release 2 encompasses a wide specification scope, including: use cases and functional requirements, studies and normative specifications for stage 2 (architecture and interfaces), stage 3 (REST APIs, descriptors and packaging) and stage 4 (NFV testing framework covering interoperability guidelines, open source for NFV, and API conformance testing).
The normative specifications in the NFV Release 2 focus on essential NFV- MANO functional and non-functional capabilities enabling the management and orchestration of the NS, VNF and virtual resources. Additional informative documents cover aspects related to NFV Information Modelling, studies in the NFV security and reliability areas. For instance, ETSI GR NFV-IFA 015 [7], with its associated guidelines, provides an overview of the NFV Information Model, while the ETSI GR NFV-IFA 024 [10] reports about the NFV Information Model touchpoints with other external organization information models.
From a specification perspective, the content of the ETSI NFV Release 2 consists of:
The Network Service (NS) is a base construct in ETSI NFV used to expose to upper orchestration layers the lifecycle management of one or more Network Functions (NF) arranged as a set of functions, with unspecified connectivity between them or according to one or more forwarding graphs.
The NSD is specified in ETSI GS NFV-IFA 014 [28] as a deployment template which consists of information used by the NFVO to perform the life cycle management of an NS instance.
The VNFD is specified in ETSI GS NFV-IFA 011 [27] as a deployment template which describes a VNF in terms of deployment and operational behavior requirements. It also contains connectivity, interface and virtualized resource requirements. A VNFD enables a VNFM to automatically perform lifecycle management of a VNF instance, based on the collection of the data available in the VNFD together with other runtime information such as the chosen VNF deployment flavor and the underlying virtualized resources used to create the VNF instance.
Although not explicitly labelled as “service-based”, ETSI NFV took a “separation of concerns” approach in the specification of the NFV-MANO reference points by decomposing them in self-contained interfaces, each providing operations for its area of concern.
The interfaces exposed by the NFVO over the Os-Ma-nfvo reference point, specified in ETSI GS NFV-IFA 013 [19], are:
The interfaces exposed over the Or-Vnfm reference point, specified in ETSI GS NFV-IFA 007 [17], are:
The interfaces exposed over the Ve-Vnfm reference point, specified in ETSI GS NFV-IFA 008 [18], are:
The interfaces exposed by the VIM over the Or-Vi reference point, specified in ETSI GS NFV-IFA 005 [5], are:
The interfaces exposed by the VIM over the Vi-Vnfm reference point are the same type as the ones exposed over the Or-Vi reference point with the exception of the NFP Management interface and certain operations of the Software Image Management, Virtualised Resources Reservation Management and Virtualised Resources Quota Management. The set of interfaces exposed over the Vi-Vnfm are specified in the ETSI GS NFV-IFA 006 [6].
Encouraging interoperability within an open ecosystem was a key objective for the ETSI NFV. A key factor was to ensure that VNFs could be packaged, deployed and managed in an interoperable way, independently from the management systems. Interoperability was also expected between the different components of an NFV-MANO system, as well as in between the NFV-MANO and other Operations Support Systems (OSS) deployed by service providers, well in-line with the reference points identified in the ETSI NFV Architectural Framework.
With regard to the specification of protocols and data models for the interfaces, the ETSI NFV followed the industry trend by adopting RESTful technology and common principles for the stage 3 solution. Until now, four Release 2 stage 3 specifications have been produced in this area:
In addition to the formal API document specifications, OpenAPI representa-tions for each of these APIs are also available in the form of YAML and JSON files publicly available on the ETSI website [25]. The availability of OpenAPI representations is intended to facilitate the development and validation of implementations exposing or consuming these APIs.
In terms of NFV descriptors (i.e., VNFD and NSD), two solutions have been specified. The first leverages the “OASIS TOSCA Simple Profile in YAML” specification, which is published as ETSI GS NFV-SOL 001 [8], and the second provides a YANG-based representation of the same descriptors, which is expected to be published as ETSI GS NFV-SOL 006 [15].
Finally, in terms of other NFV artefacts, the VNF Packaging specification, in ETSI GS NFV-SOL 004 [9] leverages the OASIS Cloud Service Archive (CSAR) format specification. Similarly, for the solution specification of an NSD, which can also be structured as a set of files, the ETSI NFV adopted the same CSAR approach while delivering the NSD file structure specification in ETSI GS NFV-SOL 007 [14].
For the NFV Release 3, the ETSI NFV adopted a feature-based development approach whereby new specifications and evolved version of current Release 2 specifications are delivered together. The NFV Release 3 focuses on enriching the NFV Architectural Framework to make NFV “ready” for global deployment and operations taking as a baseline the operational and automation framework enabled by the NFV Release 2 specifications. The additional features that are considered for NFV Release 3 are categorized into three main areas, including:
An overview of the features and technical areas considered for NFV Release 3 is illustrated in Figure 2.
NFV Release 3 includes studies and normative stage 2 specifications for network slicing, in support for 5G systems. The support for a priority assigned to the network slice, or slice subnet, translated in the NFV-MANO framework into managing and handling priority for the NFV Network Services (NS). Reflected in the ETSI NFV Information model, network slicing support in NFV was harmonized with the network slicing defined in 3GPP SA5 Network Resource Model (NRM) [24]. This is depicted in the Figure 3.
One goal of the ETSI NFV architecture is to provide a management and orchestration framework that supports deployment and provisioning of VNFs independently of the type of runtime, hence support both of virtual machines (VM) and containers is considered. As part of the NFV Release 3
both normative and informative work addresses different aspects of the support for cloud native VNFs deployment and management.
On the one hand, the normative set of non-functional characteristics and parameters, which characterize and help classify the degree of cloud nativeness of a VNF, is captured in a new artefact named VNF Product Characteristics Descriptor (VNF PCD) and specified in ETSI GS NFV-EVE 011 [20]. The VNF PCD is ideally included in the VNF Package but can be provided by a VNF vendor to the service provider by means outside of the standards scope as well. Examples of such non-functional parameters and characteristics used for the classification criteria include: resiliency, monitoring and failure detection, healing, VNF design for deployment location independence, VNF state handling (stateless and stateful), use of containers and zero-touch management aspects of cloud native VNFs.
On the other hand, the study ETSI GR NFV-IFA029 [21] on enhancements of the NFV architecture for support of cloud native VNFs deployment and container-based Platform as a Service (PaaS) covers architecture impacts to support a Container Infrastructure Service (CIS). The study identifies the different types of services exposed by the PaaS and it defines the concept of common and dedicated services. The associated management of the CIS is defined as a new logical function called Container Infrastructure Service Management (CISM).
Driven by various business and operation requirements, the operators need to support distributed network deployments most often over multiple sites. While considering resiliency, low latency, control and user plane data separation and other 5G requirements, it is not conceivable that NFV-based network deployments will be confined in one single data centre site (also referred as NFVI Point of Presence (NFVI-PoP) in NFV terminology). To fulfil these multi-site deployments, connectivity needs to be established among diverse service components, such as VNF, VNF Components (VNFC), PNF, possibly across Wide Area Networks (WAN), either legacy, Software Defined Networks (SDN)-enabled or hybrid. In the multi-site connectivity services feature, which is part of the NFV Release 3, the NFV Architectural Framework is enhanced to consider the support of management of connectivity across multiple sites by integrating WAN Infrastructure Management (WIM) either deployed as part of the NFV-MANO framework or external to the NFV- MANO framework (e.g., under control of other OSS/BSS systems). As part of these enhancements, improvements to existing NFV-MANO interfaces on the Os-Ma-nfvo, Or-Vnfm and Vi-Vnfm reference points and definition of new multi-site connectivity services management interfaces exposed by the WIM functional block have been specified. Specifically, the stage 2 requirements and interface specification of the WIM are provided in the ETSI GS NFV-IFA 032 [23].
The operational aspects of NFV systems are of special importance, not only from the services consumer point of view, such as deploying new network services or a VNF instance, but also from the maintenance point of view of the NFV systems themselves. In a network evolution path towards 5G and other network technologies where increased level of automation, higher availability and easier integration of OSS/BSS systems are needed, the management aspects of the NFV-MANO framework itself and the automatic discovery of new instances of NFV-MANO components are of critical importance for service providers. As part of the NFV Release 3, the ETSI NFV specifies the framework and interfaces allowing a service provider to perform the necessary management tasks such as configuration, performance and fault monitoring, and state control of an NFV-MANO functional entity. The stage 2 requirements and interface specification are specified in the ETSI GS NFV-IFA 031 [22].
Covering the specification stages all the way from functional requirements to the testing, verification and conformance (a.k.a. stage 4 within the ISG), the ETSI ISG NFV and ETSI CTI initiated NFV Plugtest events starting in January 2017.
The first three NFV Plugtests targeted interoperability of implementations that follow ETSI NFV specifications taking as a source for the test plan the specification ETSI GR NFV-TST 007 [26]. As more stage 3 specifications got published, the scoping of the NFV Plugtests has evolved towards the inclusion of conformance testing with the ETSI NFV APIs (ETSI GS NFV-SOL 003 [11], ETSI GS NFV-SOL 005 [12] and ETSI GS NFV-SOL 002 [13]).
NFV Plugtests have synergies with similar open source events, such as OPNFV Plugfests so they are in many cases collocated.
Development is undergoing on several features from the original release tracking list (the scope of NFV Release 3 considers eighteen features). The specification of remaining features will be delivered either over the next drop of specification publications, or as part of the Release 4, for which the planning just began. Examples of features in progress include the NFVI Upgrades, VNF Licensing, NFV-MANO upgrades, normative work for cloud native, security aspects and others.
As a generic, interoperable ICT management and orchestration framework that is application agnostic, the ETSI NFV ISG considers it is essential to maintain the ETSI NFV architecture framework relevant to the industry. A tight technical collaboration is established with related standards organizations such as 3GPP SA5, ETSI ZSM, ETSI MEC, ITU-T, MEF, IETF as well as with several open source initiatives such as OpenStack, many projects of the Linux Foundation, including ONAP, OPNFV and CNCF, and ETSI OSM.
[1] ETSI GS NFV-MAN 001: “Network Functions Virtualisation (NFV); Management and Orchestration”.
[2] ETSI GS NFV-IFA 010: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Functional requirements specification”.
[3] ETSI GS NFV 002: “Network Functions Virtualisation (NFV); Architectural Framework”.
[4] ETSI GS NFV 003: “Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV”.
[5] ETSI GS NFV-IFA 005: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Or-Vnfm reference point – Interface and Information Model Specification”.
[6] ETSI GS NFV-IFA 006: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Vi-Vnfm reference point – Interface and Information Model Specification”.
[7] ETSI GS NFV-IFA 015: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Report on NFV Information Model”.
[8] ETSI GS NFV-SOL 001: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; NFV Descriptors based on TOSCA”.
[9] ETSI GS NFV-SOL 004: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; VNF Package specification”.
[10] ETSI GR NFV-IFA 024: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Report on External Touchpoints related to NFV Information Model”.
[11] ETSI GS NFV-SOL 003: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the Or-Vnfm Reference Point”.
[12] ETSI GS NFV-SOL 005: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point”.
[13] ETSI GS NFV-SOL 002: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the Ve-Vnfm Reference Point”.
[14] ETSI GS NFV-SOL 007: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; Network Service Descriptor file structure specification”.
[15] ETSI GS NFV-SOL 006: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; NFV Descriptors based on YANG Specification”.
[16] ETSI GS NFV-SOL 013: “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; Specification of common aspects for RESTful NFV MANO APIs”.
[17] ETSI GS NFV-IFA 007: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Or-Vnfm reference point – Interface and Information Model Specification”.
[18] ETSI GS NFV-IFA 008: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Ve-Vnfm reference point – Interface and Information Model Specification”.
[19] ETSI GS NFV-IFA 013: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Os-Ma-Nfvo reference point – Interface and Information Model Specification”.
[20] ETSI GS NFV-EVE 011: “Network Functions Virtualisation (NFV) Release 3; Virtualised Network Function; Specification of the Classification of Cloud Native VNF implementations”.
[21] ETSI GR NFV-IFA 029: “Network Functions Virtualisation (NFV) Release 3; Architecture; Report on the Enhancements of the NFV architecture towards “Cloud-native” and “PaaS” (in progress).
[22] ETSI GS NFV-IFA 031: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Requirements and interfaces specification for management of NFV-MANO”.
[23] ETSI GS NFV-IFA 032: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Interface and Information Model Specification for Multi-Site Connectivity Services”.
[24] 3GPP TS 28.541: “Management and orchestration of networks and network slicing; NR and NG-RAN Network Resource Model (NRM); Stage 2 and stage 3”.
[25] OpenAPI representation of ETSI NFV SOL REST APIs: https://nfvwiki.etsi.org/index.php?title=API_specifications#OpenAPIs
[26] ETSI GR NFV-TST 007: “Network Functions Virtualisation (NFV) Release 2; Testing; Guidelines on Interoperability Testing for MANO”.
[27] ETSI GS NFV-IFA 011: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; VNF Descriptor and Packaging specification”.
[28] ETSI GS NFV-IFA 014: “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Network Service Templates specification”.
Cristina Badulescu is a Vice-chair of ETSI NFV ISG and works in Ericsson Group Functions, Research Area Network Architecture and Protocols, NCM Standardization. She has received an engineering degree in Electronics and Telecommunications from the Polytechnic University, Bucharest, Romania, followed by a postgraduate degree in Computer Science from the Concordia University, Montreal Canada. She has worked for Telefonica Internacional for three years, after which she joined Ericsson Canada in 1998.
Cristina has been working as a standardization delegate representing Ericsson since 2007, working with several mobile technologies, core and applications enablers, service and network exposure, management and orchestration as well as cloud technologies. Cristina has held several leadership positions and rapporteurships in various standardization organizations since 2008.
Joan Triay is a principal network architect at DOCOMO Euro-Labs, in Munich, Germany, which he joined in 2012, and where he is currently involved in standardization and research activities spanning different areas such as network virtualization, mobile communication networks, and 5G network management. In the ETSI NFV, Joan is currently serving as the Technical Manager. He joined the ETSI NFV from the very beginning (2013) and has been participating actively in developing the NFV concepts and standards. Joan holds a Ph.D. in Telematics Engineering (Computer Networks) (2011) from Universitat Politècnica de Catalunya (UPC), Spain.
Journal of ICT, Vol. 7_2, 141–156. River Publishers
doi: 10.13052/jicts2245–800X.725