Transport Aspects of Network Slicing: Existing Solutions and Gaps
Daniele Ceccarelli, Ericsson; and Young Lee, Huawei, USA
IEEE Softwarization, January 2018
A network slice is defined by 3GPP as an end to end logical network comprising a set of managed resources and network functions. Its definition and deployment start from the RAN (Radio Access Network) and packet core, but in order to guarantee end to end SLAs (Service Level Agreements) and KPIs (Key Performance Indicators) especially for applications that require strict latency and bandwidth guarantee, the transport network also plays an important role and needs to be sliced as part of services bound to the different slices. However, it is not easy for clients/applications to interface directly with transport networks.
ACTN (Abstraction and Control of Traffic Engineered Networks) has been driving SDN standardization in IETF in the TEAS (Traffic Engineering and Signaling) WG with the emphasis of providing customer interfaces that enable dynamic and automatic transport network slice instantiation and its life cycle operation. This article provides an overview of existing transport network slicing solutions based on ACTN and a gap analysis to meet the requirements.
Transport network slicing: key factors and requirements
In order to provide guaranteed end to end performances, service providers have the need to define logically isolated networks (aka virtual networks) that can be offered as a service to the different customers, each of which with possibly different requirements.
From a high level point of view, this translates into a number of main requirements against the transport network:
Requirement 1. Ability for the customer to define and convey their virtual networks without having to understand transport network details.
Requirement 2. Ability for the provider to map and translate customer’s virtual network models (e.g., L2/3 VPN) against TE constrained paths in transport network.
Requirement 3. Ability to provision and manage end to end paths meeting given virtual network constraints.
Requirement 4. Ability to monitor such virtual networks or connections at various levels: customer level, orchestration level and domain level.
Requirement 5. Ability to integrate other constraints such as Service Functions and/or Virtual Network Functions.
Requirement 6. Ability to extend for integrating non-TE device level performance data such as queuing delay.
The provisioning of end to end paths often spans multiple administrative and technological domains, possibly involving domains operated by different providers. All this complexity needs to be hidden to the customer of the network slice, which in most cases customer only cares about connectivity with given constraints between a set of end points.
These issues are addressed by an ongoing work in the IETF (Internet Engineering Task Force) known under the name of ACTN – Abstraction and Control of Traffic engineered Network.
ACTN defines a hierarchy of controllers based on a 3-tier model whose main functionalities are :
- Multi domain coordination: this function builds a single end to end network topology (with different levels of abstraction) to enable end to end path computation and provisioning.
- Virtualization/Abstraction: provides an abstracted view of the different network domains based on the customer requirements and negotiated with the service provider.
- Customer mapping/translation: This function maps customer level requests into network level constraints and command that can be sent down the control hierarchy till the devices.
- Virtual service coordination: Translation of service related information into requests and commands at network level. This includes many service orchestration functions such as multi-destination load balancing, guarantees of service quality, bandwidth, and throughput.
The 3-tier model defines types of controllers and the interfaces between them as shown in Figure 1 below.
Figure 1. ACTN architecture
A Customer Network Controller (CNC) is responsible for communicating a customer's Virtual Network Service (VNS) requirements to the network provider over the CNC-MDSC Interface (CMI). It has knowledge of the end-points associated with the VNS (expressed as Access Points (APs)), the service policy, and other QoS information related to the service.
A Multi-Domain Service Coordinator (MDSC) is a functional block that implements all of the ACTN functions listed in above. The MDSC sits at the center of the ACTN model between the CNC that issues connectivity requests and the Provisioning Network Controllers (PNCs) that manage the network resources. The key point of the MDSC is detaching the network and service control from underlying technology to help the customer express the network as desired by business needs. It is assumed that an MDSC is under one provider’s authority. In case that customer applications are spread over multiple providers, it is a responsibility of the CNC to have multiple interfaces to coordinate the multi-provider issues.
A Provisioning Network Controller (PNC) oversees configuring the network elements, monitoring the topology (physical or virtual) of the network, and collecting information about the topology (either raw or abstracted).
Solutions for Transport Network Slicing
This section provides the current progress and solutions against the aforementioned requirements of transport network slicing.
Virtual Network Slicing Service Model
It discusses customer initiated virtual network slicing data model in which customer can control their virtual network slice to fit their needs . This model fulfills the requirement #1. This is for CMI (i.e. CNC – MDSC Interface of ACTN) as shown in Figure 1. This model describes VN Yang model for customer access points, virtual network access points, Virtual Network (VN) identifiers, its VN-members, any constraints and policy customer cares for with respect to its VNs. See Figure 2 shows the process of VN creation in the context of ACTN architecture.
Figure 2. Virtual Network Slicing Service Creation
Figure 2 shows that VN Slicing Service model enables customer to create its VN without having to know the transport underlay details and to indicate its end-points with constraints (e.g., bandwidth, latency, load-balancing, protection, etc.) per VN or VN-member level. This model facilitates customer-driven dynamic life-cycle VN service operation.
TE-Service Mapping Model
It discusses the need for creating TE-Service Mapping model in which to create a binding relationship across Service Models such as L1/2/3 VPN [3-5] and ACTN VNS  and TE tunnel model . This model fulfils the requirement #2. Figure 3 shows the binding relationship across different models.
Figure 3. TE-service mapping model
This binding will facilitate a seamless service operation with underlay-TE network visibility. The TE-service model developed can also be extended to support other services including L1 Connectivity Service Model, L2 Service Model, and L3 Service Model, and future transport network service models. TE-service mapping model allows for customer to indicate their service policy in regards to how under-lay TE tunnels be created for their VPN service (e.g., sharing with existing tunnels, new TE-tunnel for VPN, a complete isolation by creating optical TE tunnel, etc.). As VN isolation requirement is one of the key enablers for certain applications for 5G and others, this model fulfills such requirement. With this model, customer is given the underlay TE tunnel reference so that it can monitor how its VNs are performing in the underlay via VN telemetry model .
Abstracted TE topology and TE tunnel Models
Abstracted TE topology model  allows operators to control and manage its transport networks based on an end-to-end abstracted topology. The corresponding TE tunnel model  allows operator to control and manage various tunnels across the abstracted topology independent of the underlying domain technology. These models fulfill the requirement #3.
Figure 4. Abstracted TE topology and TE tunnel models with technology specific augmentation
In some cases, topology abstraction may not provide sufficient details of the underlay transport networks. Using YANG Remote Procedure Call (RPC) operation, path compute request and reply can be supported so that the MDSC can collect more granular topology information beyond generic abstraction level such as Optical Transport Network (OTN), Wavelength Switched Optical Network (WSON) and Flexi-grid from the domain networks. This refers to augmentation which is shown in Figure 4 where both TE-topology and TE-tunnel models are augmented by technology specific YANG models of various types.
VN Telemetry Model
It discusses KPI Telemetry which allows customer to define key performance monitoring data relevant for its virtual network slicing via YANG subscription model . This model fulfills the requirement #4.
This model allows for mechanisms to define different aggregation/abstraction levels of telemetry data to support scalability. Figure 5 shows how VN telemetry model operates.
Figure 5. VN Telemetry Model Operation
The current traffic segregation solutions like L2VPN are not able to guarantee end to end constraints and SLA requirements, while new ACTN transport network slicing solutions presented in this article are focused on providing customer traffic with guaranteed end to end performances. The solutions allow creating virtual network slices for a set of end-to-end connectivity which connects customer’s end-points. Virtual networks requiring key performances such as bandwidth guarantee and strict latency can be created and monitored dynamically using various models presented in this article. In summary, the current standardization efforts have identified solutions already for requirements 1-4 while there is still room for discussions/solutions for requirements 5-6. Related to requirement 5, other slicing constraints beyond connectivity constraints are yet to be fulfilled in the current transport network slicing. Virtual Network Functions (VNFs) and Service Functions (SFs) can be added to Transport network slicing scope. An initial use-case  and its corresponding solution for SF-enabled TE topology are available .
Related to requirement 6, the port/queue level isolation requirements have not been considered in current transport network slicing scope. In hybrid non-TE and TE networks, the low level PM data such as port/queue level latency required for enhanced VPN  and Deterministic Networking  may contribute to end-to-end latency and as such the VN telemetry model can be extended to integrate these low level PM data.
 Daniele Ceccarelli and Young Lee (Editors), “ACTN Framework”, draft-teas-actn-framework-10, IETF draft, November 2017.
 Young Lee, et al, “A Yang Data Model for ACTN VN Operation”, draft-lee-teas-actn-vn-yang-08, IETF draft, October 2017.
 Giuseppe Fioccola, et al, “A Yang Data Model for L1 Connectivity Service Model (L1CSM)”, draft-fioccola-ccamp-l1csm-yang-00, IETF draft, October 2017.
 Giuseppe Fioccola (Editor), “A YANG Data Model for L2VPN Service Delivery”, draft-ietf-l2sm-l2vpn-service-model-04, IETF draft, October 2017.
 S. Litkowski, L. Tomotaki, and K, Ogaki, “YANG Data Model for L3VPN Service Delivery”, RFC 8049, IETF, February 2017.
 T. Saad (Editor), “TE tunnel model A YANG Data Model for Traffic Engineering Tunnels and Interfaces”, draft-ietf-teas-yang-te-09, IETF draft, October 2017.
 Young Lee (Editor), “YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics”, draft-lee-teas-actn-pm-telemetry-autonomics-05, IETF draft, October 2017.
 Xufeng Liu, et al, “YANG Data Model for Traffic Engineering (TE) Topologies”, draft-ietf-teas-yang-te-topo-13, IETF draft, October 2017.
 Igor Bryskin, et al. “Use Cases for SF Aware Topology Models”, draft-bryskin-teas-use-cases-sf-aware-topo-model-01, IETF draft, October 2017.
 Igor Bryskin and Xufeng Liu, “SF Aware TE Topology YANG Model”, draft-bryskin-teas-sf-aware-topo-model-00, IETF draft, October 2017.
 Stewart Bryant and Jie Dong, “Enhanced Virtual Private Networks (VPN+)”, draft-bryant-rtgwg-enhanced-vpn-01, IETF draft, October 2017.
 Norm Finn, et al. “Deterministic Networking Architecture”, draft-ietf-detnet-architecture-04, IETF draft, October 2017.
 Haomian Zheng, et al. “A YANG Data Model for Optical Transport Network Topology”, draft-ietf-ccamp-otn-topo-yang-02, IETF draft, October 30, 2017.
 Young Lee, et al. “A Yang Data Model for WSON Optical Networks”, draft-ietf-ccamp-wson-yang-09, IETF draft, November 12, 2017.
 J.E. Lopez de Vergara, et al. “YANG data model for Flexi-Grid Optical Networks”, draft-vergara-ccamp-flexigrid-yang-06, IETF draft, January 8, 2018.
 Haomian Zheng, et al. “OTN Tunnel YANG Model”, draft-ietf-ccamp-otn-tunnel-model-01, IETF draft, October 30, 2017.
 Young Lee, et al, “A Yang Data Model for WSON Tunnel”, draft-lee-ccamp-wson-tunnel-model-04, IETF draft, January 8, 2017.
 J.E. Lopez de Vergara, et al. “YANG data model for Flexi-Grid media-channels”, draft-vergara-ccamp-flexigrid-media-channel-yang-01, IETF draft, November 11, 2017.
Daniele Ceccarelli received his master degree in 2005 in Telecommunications Engineering from the University of Pisa. After some years as researcher he joined Ericsson as system manager and network architect with focus on GMPLS and distributed control plane. In the last year his interests evolved into packet-optical integration and multi layer and multi domain transport SDN solutions. Daniele started working in IETF in various working groups of the routing Area in 2008 where in 2014 he became co-chair of the CCAMP working group. Daniele is co-author of 12 RFCs and more than 20 active internet draft mostly covering GMPLS, PCE, MPLS and ACTN.
Young Lee is a Technical Director of SDN network architecture at Huawei Technologies USA Research Center, Plano, Texas. He is responsible for developing new technology in the area of SDN/T-SDN/NFV and driving standards in IETF and ONF. He has also been leading optical transport control plane technology research and development. His research interest includes SDN, cloud computing architecture, cross stratum optimization, network virtualization, distributed path computation architecture, multi-layer traffic engineering methodology, and network optimization modeling and new concept development in optical control plane signaling and routing. Prior to joining to Huawei Technologies in 2006, he was a co-founder and a Chief Architect at Ceterus Networks (2001-2005) where he developed topology discovery protocol and control plane architecture for optical transport core product. Prior to joining to Ceterus Networks, he was Principal Technical Staff Member at AT&T/Bell Labs in Middletown/Holmdel, New Jersey (1987-2000).
He is active in standardization of transport SDN, GMPLS, PCE in IETF and ONF and has driven Transport SDN both in industry, standardization, and ONOS ACTN project. He currently serves a chair for Cross-Stratum Optimization (CSO) WG in ONF. He served a co-chair for IETF’s ACTN BOF and a co-chair for ONF’s NTDG.
He received B.A. degree in applied mathematics from the University of California at Berkeley in 1986, M.S. degree in operations research from Stanford University, Stanford, CA, in 1987, and Ph.D. degree in decision sciences and engineering systems from Rensselaer Polytechnic Institute, Troy, NY, in 1996.
Dr. Elio Salvadori is the Director of CREATE-NET Research Center within Fondazione Bruno Kessler (FBK); he is responsible for managing, organizing, executing and monitoring of the activities of the Center.
He joined CREATE-NET in 2005 and since then he has served different roles within the organization: from 2007 to 2012 he has been leading the Engineering and Fast Prototyping (ENGINE) area. From 2012 to 2014 he has been acting as SDN Senior Advisor while holding a position as CEO in Trentino NGN Srl. He then moved fully back to CREATE-NET acting as Research Director and then as Managing Director until the incorporation within FBK at the end of 2016.
Prior to CREATE-NET, Dr. Salvadori has developed a mixed industrial and academical background: he graduated in 1997 at Politecnico di Milano through an internship pursued at CoreCom, a research lab funded by Politecnico and Pirelli Optical Systems (now Cisco Photonics). Afterward he has worked as systems engineer at Nokia Networks in Milan and then at Lucent Technologies in Rome. In 2001 he won a research grant at the University of Trento to pursue his PhD on Information and Communication Technologies. He received his PhD degree in March 2005 with a thesis on traffic engineering for optical networks.
During his research career, he has been involved in several national and European projects on SDN and optical networking technologies as well as on Future Internet testbeds.
His current research interests include software-defined networking (network virtualization and distributed controller architectures), Network Functions Virtualization (NFV) and next generation transport networks. He has published in more than 100 International refereed journals and conferences. He is a member of IEEE and ACM.
Subscribe to IEEE Softwarization
Join our free SDN Technical Community and receive IEEE Softwarization.
Article Contributions Welcomed
Download IEEE Softwarization Editorial Guidelines for Authors (PDF, 122 KB)
If you wish to have an article considered for publication, please contact the Managing Editor at firstname.lastname@example.org.
IEEE Softwarization Editorial Board
Laurent Ciavaglia, Editor-in-Chief
Mohamed Faten Zhani, Managing Editor
TBD, Deputy Managing Editor
Syed Hassan Ahmed
Dr. J. Amudhavel
Atta ur Rehman Khan
Muhammad Maaz Rehan