5G Slicing: Concepts, Architectures, and Challenges
Part 4: SDN and NFV Integration, Challenges and Possible Solutions
After the first 3 blogs in this series, in this blog I will illustrate how network slicing using the SDN and NFV architectures together. Case in point we will take an example of an SDN-enabled NFV deployment, with several slices running on a common NFVI.
This deployment includes two tenants, each managing a particular set of slices. Please note that in this example, I only consider a single level of recursion and thus the tenants directly serve the end users. Each slice consists of VNFs that are appropriately composed and chained to support and build up the network service or services the slice (or the tenant) delivers to its users.
The deployment includes two phases:
- First, a slice creation phase, in which an end user requests a slice from a network slice portal catalog (could be exposed to the end user or only the service provider), that instantiates the slice.
- Second, the run-time phase, where the different functional blocks within each slice have already been created and are now operative.
In this scenario tenants access NFVI resources from PoPs that provide computer and networking resources, both deployed on NFVI. For example, a PoP can provide SDN-based WAN transport networks, used to communicate such NFVI-PoPs. The VMs (and their underlying hardware), are instantiated in the NFVI-PoPs and are in charge of running VNFs (and their components). These are directly managed by the VIMs.
The networking resources supporting VNF connectivity are programmatically managed by the ICs using the VIM and the WAN infrastructure manager (WIM) premises. Both VIMs and WIMs act as SDN applications, delegating the tasks related to the management of networking resources to their underlying ICs. Although in this example the ICs are deployed on the NFVI, it is possible to integrate them into VIMs.
On top of the InPs, the tenants independently manage a set of network slices. Each slice interacts with the OSS, a TC, and the orchestrator. The OSS, which could be an SDN application from the TC’s perspective, instructs the controller to manage the slice’s constituent VNFs and logically bring them together to efficiently realize the service(s) the slice offers.
The lifecycle of such network service(s) is managed by the orchestrator, which interacts with the TC via the OSS. The TC, deployed as a VNF, relies on the capabilities provided by virtual switches/routers (VNFs as well) to enable the VNF composition, forwarding pertinent instructions to such virtual switches/routers via its southbound interfaces. Through its northbound interfaces, the TC provides a way to securely expose selected network service capabilities to end users. Such interfaces allow end users to retrieve context information (e.g. real-time performance and fault information, user policies, etc.), operate, manage and make use of the slice’s network service(s), always within the limits set by the tenant.
The fact that each slice is provided with its own TC instances enables the required management isolation.
Each tenant must efficiently orchestrate its assigned resources to simultaneously satisfy the diverging requirements of the slices that are under its management. The orchestrator which holds the planning slice as define by the tenet has the capability to reserve/remove/ add/scale the required service to the specific slice. Therefor metadata on the PoP and InP is always synced with the orchestrator which is synced with tenant requirements.
All the NFVI resources available for use by a tenant are supplied by the different InPs. Each InP gets a part of the virtual resources. To access, reserve and request such resources, the tenant’s interacts with the VIM(s) /WIM(s). The assumption is that VIMs and WIMs support multi-tenancy.
Performance issues in a shared infrastructure
When network slices are deployed over a common underlying infrastructure, performance isolation requirement is not an easy task. If a tenant only assigns dedicated resources to network slices, performance levels are usually met at the cost of preventing resource sharing. This often leads to over-provisioning, an undesired situation bearing in mind that the tenant has a finite set of assigned resources.
One way to resolve this issue is to permit resource sharing, but this means slices are not completely decoupled in terms of performance. Thus, it is required to design adequate resource management mechanisms that enable resource sharing among slices when necessary without violating their required performance and SLA levels. To accomplish this, the orchestrator could use policies and strategies similar to those used in VIMs (such as the OpenStack Congress module, or Enhanced Platform Awareness attributes).
Management and Orchestration issues
Given the dynamism and scalability that slicing brings, management and orchestration in multi-tenant scenarios are not straightforward. To flexibly assign resources on-the-fly to slices, the optimization policy that governs the RO must deal with situations where resource demands vary considerably in relatively short timescales. To accomplish this the following elements are required:
- An appropriate cooperation between slice-specific management functional blocks
- Policies need to be captured in a way that they can be automatically validated. This automation enables slice-specific functional blocks to be authorized to perform the corresponding management and configuration actions in a timely manner.
- Designing computationally efficient resource allocation algorithms and conflict resolution mechanisms at each abstraction layer
Security and Privacy
The open interfaces that support the programmability of the network facilitate potential attacks to software-based networks. This calls for a consistent multi-level security framework composed of policies and mechanisms for software integrity, remote verification, dynamic threat detection and mitigation, user authentication and accounting management. The security and privacy concerns arising from 5G slicing are today a major barrier to adopt multi-tenancy approaches.
I hope you enjoyed this last blog in the series, see you soon…
Click here to learn more about ECI's ElastiNET 5G Mobile Backhaul Solutions.