2020 turned out to be an unexpected year, with the COVID19 pandemic adversely impacting the “normal” day-to-day lives of humans across the globe. However, even during this turn of events and unforeseen testing times, communication networks demonstrated their efficacy in keeping people and businesses connected. More concretely, Network Functions Virtualisation (NFV) proved its feasibility by enabling the operators to gracefully manage high demand for network connectivity.

NFV blog evolution new vision imageUndaunted by this situation, the technical experts at the ETSI ISG NFV continued to work tirelessly developing and delivering specifications that help get and keep “everyone/everything connected”. And the hard work paid off as ETSI ISG NFV delivered during the second half of 2020 new and updated "protocols and data model" (stage 3) specifications incorporating NFV Release 3 features.

The experts in the Solutions (SOL) working group completed stage 3 work on a subset of the NFV Release 3 features. One of the first features that was already finalised in 2019 was "Management of NFV-MANO" (FEAT11) with the release of ETSI GS NFV-SOL 009 V3.3.1. This document specifies a set of RESTful protocols and APIs that can be used to manage different aspects regarding configuration, performance, fault and logging of entities implementing specified NFV-MANO functional blocks. The defined APIs leveraged the same RESTful principles used for NFV-MANO APIs in Release 2, i.e., the ones used for managing VNF instances, NS instances and on-boarding VNF Packages, NSDs and other artefacts.

New outcomes on the development of NFV-MANO APIs continued in 2020 with the release of ETSI GS NFV-SOL 011 V3.3.1, which specifies NFV-MANO APIs related to management across "NFV-MANO administrative domains" (FEAT08). These APIs are produced by the NFVO and allow different administrative domains to communicate over the Or-Or reference point to help coordinate the management of NS instances deployed on their respective administrative domains. The Or-Or reference point is set in between NFVO instances placed on different administrative domains, as specified in ETSI GS NFV-IFA 030. For instance, the APIs of ETSI GS NFV-SOL 011 enable reusing an NS instance deployed on a domain A and nest it into another NS instance deployed on a domain B. Due to the functional similarities with existing capabilities offered by the NFVO to other systems such as OSS/BSS, most of the APIs are identical or based on those specified in ETSI GS NFV-SOL 005.

The release of new API specification documents was completed in 2020 by the ETSI GS NFV-SOL 012 V3.4.1 "NFV; Protocol and Data Models; RESTful protocols specification for the Policy Management Interface". As its title hints, the document specifies a new NFV-MANO API based on RESTful principles that can be used for setting up a "Policy management framework" (FEAT07). The API, produced by the NFV-MANO functional blocks, offers the much needed management capabilities by the network operators to be able to transfer, update, delete, activate, de-activate policies, and subscribe to and get notifications related to policy management. Note that the specification of the data models and formats of the policy content is not within the scope of this document. Information and data modelling work on policy content is under development as part of the Release 4.

The ETSI Industry Specification Group (ISG) NFV has published the initial release of ETSI GS NFV-IFA 040 titled "Requirements for service interfaces and object model for OS container management and orchestration specification". This document is the first normative specification delivered for the NFV Release 4 feature on “Cloud-native VNFs and Container Infrastructure management”. The specification propagates the recommendations from the study in ETSI GR NFV-IFA 029 and formally specifies the new functions required for the management and orchestration of OS containers, the Container Infrastructure Service Management (CISM) and the Container Image Registry (CIR). The CISM is responsible for maintaining the containerized workloads while the CIR is responsible for storing and maintaining information of OS container software images.NFV release 4 FEAT 17 blogpost

To enable a consistent and generic system for the management of containerized VNFs, ETSI GS NFV-IFA 040 specifies an abstract NFV object model for OS container management and orchestration, including their relationship to the core information models of NFV-MANO. The abstract NFV objects are also expected to be used in specifications profiling APIs of de-facto standard solutions, to map the abstract NFV objects to objects of the specific de-facto standard solution. One of the introduced abstract NFV objects is the Managed Container Infrastructure Object (MCIO), an object managed and exposed by the CISM, characterized by the desired and actual state of a containerized workload. Managed objects from Kubernetes® such as Deployment or Service are examples which map to an MCIO. Another new NFV object is the Managed Container Infrastructure Object Package (MCIOP), a hierarchical aggregate of information objects including declarative descriptors and configuration files for one or multiple MCIOs. Helm charts as specified by CNCF® are an example which maps to an MCIOP.

Furthermore, ETSI GS NFV-IFA 040 specifies requirements on the list of services to be offered by architectural elements providing the CISM and CIR functions and on the interfaces for exposing these services to NFV-MANO and other consuming entities. The CISM shall provide services for the management of OS container workloads as well as for the management of OS container compute, storage, network resources and their configuration. The CIR shall provide a service for the management of OS container images. This document intentionally does not specify interface operations or information models​ but only requirements on the management service interfaces. This approach leaves further details to the specification of protocols and data models in the form of profiling de-facto standard open source solutions.

For its 27th plenary meeting, the ETSI Industry Specific Group (ISG) on Network Functions Virtualisation (NFV) met at Orange Gardens, the recent Research and Innovation Campus of Orange, located in Châtillon, a small town in the outskirts of Paris, France. The meeting is to be remembered as the one where the contents of NFV Release 4 started to materialize with the approval of 8 work items.

The opening session started with an uplifting presentation from Diego Lopez, the chairman of the ISG, highlighting the challenges to be addressed by standardization bodies to cope with the transformation of the telco industry ecosystem and processes. I liked the comment he made to invite delegates to resist the temptation of creating new terms and acronyms (e.g. Cloud-Native Network Functions / CNF vs. Virtualised Network Functions / VNF) to catch-up with buzzwords. After all, whether the software of a VNF is designed according to cloud-native patterns or not, the VNF remains a VNF!

After the opening plenary, the bulk of the work was performed during three intense days where delegates divided in six working groups to process hundreds of contributions.

Group photo of participants at 27th NFV plenary meeting