Deploying Hybrid Network Services: Mixing VNFs and CNFs in Multi-site Infrastructures

—Next generation mobile networks base on the automated, ﬂexible, and dynamic orchestration of virtualised network services (NSs). These NSs are made up of Virtual Network Functions, which have hitherto mostly been implemented by means of virtual machines. The current trend is to include the use of containers, the so-called Cloud-native Network Functions, which may ﬁt better the need of NS deployments embracing edge infrastructures having constrained resources. This ends up in the deﬁnition of NSs mixing both kinds of network functions (NFs) satisfying the needs of network operators and vertical industries and the characteristics of available infrastructures. We refer to the use of both kinds of NFs in a single NS as Hybrid NS. This demonstration presents the extensions done in the 5Growth management and orchestration platform to perform the deployment of such kind of NSs in a multi-site infrastructure, including the dynamic interconnection of the deployed NFs according to their nature.


I. INTRODUCTION
Next generation mobile networks rely on the automated, flexible and dynamic orchestration of network services (NSs) to satisfy the requirements of the multiple involved stakeholders (e.g., network operators and vertical industries). Software Defined Networking (SDN), Network Function Virtualization (NFV) and Network Slicing are key pillars to realise this vision. These NSs are made up of a set of interconnected Virtual Network Functions (VNFs) distributed among the available Points-of-Presence (PoPs) of the NFV infrastructure (NFVI). These VNFs, based on virtual machines (VMs), implement software applications with the aim of replacing its predecessors, the hardware-based physical network functions.
The current trend in the evolution of NS design and development is the inclusion of network functions (NFs) based on containers, the so-called Cloud-native Network functions (CNFs). CNFs allow implementing micro-services based applications having smaller footprint, hence fitting resource-constrained infrastructures, like those PoPs located at the edge of the network. However, not all VNFs can be moved into CNFs for several reasons, like the big amount of development time of the VM format spent by vendors, dependencies with old third-party versions of software not available as containers or the intended VNF not being based on Linux operating system. Additionally, passing from a full VNF-based NS to a full CNF-based NS requires a big effort in terms of application architecture re-design. These considerations open a phase where both kinds of NFs can be combined. Depending on the application components and the underlying infrastructure (i.e., edge, cloud), leveraging either VNFs or CNFs or combining both of them in an NS definition are possible alternatives. This gives NS designers a higher degree of flexibility when defining vertical services. We refer to these NSs combining both types of NFs within a single NS definition as Hybrid NSs. Hence, enhanced management and orchestration (MANO) procedures will be required to handle such kind of NSs to deal with the different characteristics of their NFs, their interconnection, and the underlying infrastructure supporting them.
Previous work ( [1], [2]) and open source MANO projects, like Open Source MANO (OSM) and ONAP, consider the deployment of CNFs in NSs made up exclusively of CNFs. This demonstration goes beyond previous work and shows, to the best of our knowledge, the first operational demonstration allowing the deployment of a Hybrid NS dynamically interconnecting multiple NFVI-PoPs by means of an SDNcontrolled transport network, where VNF-and CNF-based NFs belonging to the same NS definition have been instantiated. This is achieved through the enhancements included in the 5Growth MANO platform [3]. These enhancements cover multiple operations of the NS lifecycle management, namely onboarding, instantiation and termination.
II. SYSTEM ARCHITECTURE Fig. 1 presents the experimental setup under demonstration deployed at the CTTC 5G Lab. The 5Gr platform [3] performs MANO operations at the underlying infrastructure based on and extending ETSI NFV architecture and specifications. This infrastructure counts with three NFVI-PoPs, which are interconnected by the depicted packet-switched transport network emulated with GNS3 [4]. This transport network is managed by an ONOS SDN controller acting as the Wide Area Infrastructure Manager (WIM). The NFVI-PoPs are controlled by a dedicated instance of a Kubernetes-based Container Infrastructure Manager (CIM) handling the instantiation of CNFs in the form of containers or an OpenStack-based Virtual Infrastructure Manager (VIM) handling the instantiation of VNFs in the form of VMs.
In this demonstration, the Service Orchestrator (5Gr-SO) module has been extended to handle the lifecycle management of Hybrid NSs using OSM Release 9 as Core MANO platform. During the onboarding phase, the considered ETSI-NFV IFA011 VNF descriptor has been extended to include a new information element (IE) modeling the container deployment unit as a Helm-Chart element. A Helm-Chart is a template describing the deployment of complex Kubernetes applications in a declarative manner. It is worth mentioning that these Helm-chart templates must define a LoadBalancer service type to be able to expose CNF endpoints to the external world. In the case of the NS descriptor, following ETSI-NFV IFA014 specification, changes are not required. Both types of descriptors are then translated to the ETSI-NFV SOL006 format required by OSM. During the instantiation phase [5], the logic of the resource orchestration engine (ROE) and Core MANO wrapper (interacting with OSM) sub-modules of the 5Gr-SO has been enhanced to handle the relation between the different types of NFs. These modules coordinate with the Resource Layer (RL) the allocation of needed computing and network connectivity resources at the different infrastructure managers (i.e., VIMs, CIM and WIM). In order to do so, the resource abstraction provided by the 5Gr-RL to the 5Gr-SO required of an extension to specify the capabilities of the available NFVI-PoPs to host the different kinds of NFs (i.e., container or VMs).
III. DEMONSTRATION This demonstration shows the capabilities of the 5Gr platform to perform the deployment of Hybrid NSs. For this, we consider the sample Hybrid NS depicted at the bottom of Figure 1. It consists of three network functions (NFs): one CNF and two VNFs, which are interconnected by means of two virtual links. After onboarding the corresponding NF and NS descriptors in the 5Gr platform (and the associated Core MANO platform), the main steps of the demonstration are: 1) An NS request arrives to the 5Gr-SO asking for the deployment of the Hybrid NS.
2) The 5Gr-SO ROE parses the associated descriptors and queries the infrastructure resource status to the 5Gr-RL to compose a request to the placement algorithm including the type of NF and the capabilities of each NFVI-PoP (i.e. VM, container). In this demonstration, the different NFs are distributed in the available NFVI-PoPs as depicted in Fig. 1.
3) According to the decided placement, the 5Gr-SO Core MANO wrapper first creates, through the 5Gr-RL, the appropriate virtual networks in the corresponding NFVI-PoPs controlled by a VIM instance. Then, it contacts the MANO platform to boot the VMs associated with the VNFs and the containers associated to the CNF at the selected VIMs/CIM, respectively. Day-0 actions (i.e., during booting time) are performed in the VNF connected to the CNF to create appropriate routing rules between created virtual networks for VNFs and the external network of a CIM announced by the 5Gr-RL. IP addresses in the range of this CIM external network are assigned to CNF endpoints. 4) After NFs are instantiated, the ROE determines the pairs of (VNF-VNF) and (VNF-CNF) connections based on the NS descriptor and composes a query to the 5Gr-RL. Then, the RL interacts with the WIM, which establishes the specified physical connections through the depicted SDN-controlled transport network (red and green lines represented in Fig. 1). 5) Once the CNF and VNFs are running and the requested network connectivity among them is established, we check that CNF and VNFs can communicate with each other. During the demonstration, all steps are shown through the GUIs of the different building blocks of the 5Gr platform (e.g., NS structure, NS deployment information status, selected network paths) and the available VIM/CIMs (Openstack, Kubernetes), as depicted in Fig. 1.