Blog

 – A personal view from Adrian Farrel

One of the questions exercising the partners in the Metro-Haul project is “What is a network slice?”

There are several base definitions that can be drawn upon, although many of these are specific to particular layers in the network, to the technologies in use, and to the services being delivered. This focus on environment-specific details tends to lead to definitions and interpretations that do not translate well to application in different environments. Furthermore, this approach can lead to attempts to consider complete end-to-end and top-to-bottom slicing solutions that would result in optical equipment being sliced dependent on (and to support) individual user-to-user 5G calls.

To me, much of this conversation is reminiscent of the “bandwidth on demand” discussions that we had as long as 15 years ago. At that time a lot of people talked past each other, but it was clear that no operator wanted to turn up a high-capacity optical path to support a micro flow in the IP network.

In fact, no one in the 5G world should be talking about this type of behaviour either. It doesn’t scale economically or technically.

To advance the discussion of network slicing more meaningfully, we need to settle on a simple, generic, and abstract definition. Once we have that in place we can debate the applicability of different aspects of network slicing to different layers of the network, to different applications, and to different technologies. And then we can look at the hierarchy of network slicing that spans multiple networks, multiple technologies, and multiple network administrations. It is likely that different interfaces (both technological and administrative) will be needed in this hierarchy, and that multiple software packages will need to be integrated to build a full-function system.

Writing in IEEE Communications Magazine in May 2017 [1], the Guest Editors (Samdanis, et al.) described network slicing as follows:

Network slicing in 5G systems defines logical, self-contained networks that consist of a mixture of shared and dedicated resource instances, such as radio spectrum or network equipment, and virtual network functions.

Virtualization allows the decoupling of network functions from proprietary hardware appliances in order to create distinct building blocks that can be flexibly chained to create value-added communication services.

The notion of resources in 5G network slicing includes network, compute, and storage capacity resources, virtualized network functions, and radio resources. Service designers can select the optimal control/user plane split, as well as compose and allocate virtualized network functions at particular locations inside the core or radio access network depending on the service requirements. 5G network slicing enables a particular communication service exploiting the principles of software defined networks (SDN) and network functions virtualization (NFV) to fulfill the business and regulatory requirements. The achieved networking and service flexibility enables a radical change, beyond network sharing, enabling tailored services to third parties and vertical market players.

Within the IETF several attempts have been made to define network slicing in the layer 3 and TE (transport) contexts. One architectural overview (Geng, et al.) [2] provides a set of definitions as follows:

Network Slice – A Network slice is a managed group of subsets of resources, network functions / network virtual functions at the data, control, management/orchestration planes and services at a given time. Network slice is programmable and has the ability to expose its capabilities. The behaviour of the network slice realised via network slice instance(s).

End-to-end Network Slice – A cross-domain network slice which may consist of access network (fixed or cellular), transport network, (mobile) core network and etc. End-to-end network slice can be customized according to the requirements of network slice tenants

Network Slice Instance – An activated network slice.  It is created based on network template. A set of managed run-time network functions, and resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by the service instance(s). It provides the network characteristics that are required by a service instance. A network slice instance may also be shared across multiple service instances provided by the network operator.

A different view within the IETF is provided in the context of Abstraction and Control of TE Networks (ACTN) by King, et al. [3]. Here we find:

A transport network slice construct provides an end-to-end logical  network, often with compute functions and utilising shared underlying  (physical or virtual) network resources.  This logical network is separated from other, often concurrent, logical networks each with independent control and management, and each of which can be created  or modified on demand.

At one end of the spectrum, a virtual private wire or a virtual private network (VPN) may be used to build a network slice. In these cases, the network slices do not require the service provider to isolate network resources for the provision of the service – the service is “virtual”.

At the other end of the spectrum there may be a detailed description of a complex service that will meet the needs of a set of applications with connectivity and service function requirements that may include compute resource, storage capability, and access to content. Such a service may be requested dynamically (that is, instantiated when an application needs it, and released when the application no longer needs it), and modified as the needs of the application change.

All of these discussions are reminiscent of feeling the elephant. Actually, for people wearing blindfolds, we are not doing so badly, but we are still reporting our opinions from our own very slanted perspectives. What Metro-Haul needs (and arguably what would be really helpful across the whole industry) is a robust and generic definition of “network slicing”. This definition can then be used to define the valuable function in different layers and particularly in the flexible optical network layer that can be deployed in the metro area. It is critically important that this definition not limit itself to any specific definition of application or technology.

Here is my proposed definition:

A “Network Slice” represents an agreement between a User and a Service Provider to deliver network resources according to a specific service level agreement. In this context a “User” is any application, client network, or customer of a Service Provider. And a “Service Provider” is a network operator that controls a server network or a collection of server networks.

“Network resources” are any features or functions that can be delivered by a server network. This includes connectivity, compute resources, storage, and content delivery. A “service level agreement” describes multiple aspects of the agreement between the user and the service provider:

• the quality with which the features and functions are to be delivered and includes measures of bandwidth, latency, and jitter
• the types of service (such as the network service functions or billing to be executed)
• the location, nature, and quantities of services (such as the amount and location of compute resources and the accelerators require).

A network slice does not necessarily represent dedicated resources in the server network, but does constitute a commitment by the service provider to provide a specific level of service. Thus, a network slice could be realised as a virtualisation of (consider virtual private wires and VPNs), or as a partitioning and dedication of server network resources.

A network slice can further be a detailed description of a complex service that will meet the needs of a set of applications. Such a service may be requested dynamically (that is, instantiated when an application needs it, and released when the application no longer needs it), and modified as the needs of the application change.

My opinion is that this definition is both recursive and sufficiently general to be safely applied within Metro-Haul and more widely.

Of course, work is still needed to determine how this definition is applicable to a wide range of end-to-end, application-level use cases. Furthermore, in the context of Metro-Haul, work is needed to understand the use cases that apply to the operation and management of metro networks in support of 5G applications.

Lastly, a lot of effort is needed to identify and develop the tools that are needed to support network slicing in the metro network. These will include planning, orchestration, and provisioning tools. And all of this will depend on the optical technologies available, the telemetry and demand-matrix measurement tools, and a clear techno-economic study. And that is the purpose of the Metro-Haul project.

An entirely separate issue that also has to be examined within the Metro-Haul project is the utility and practicality of network slicing within the metro network. Does slicing result in partitioning of the network, and if so, at what granularity and with what level of dynamicity? Or is slicing a form of aggregation? Does network slicing enable guarantees of quality of service delivery (such as end-to-end delay), and if so is this a function of virtual connectivity across the network, or is it a dynamic property? All of these are questions about the operation and management of the metro network, of how services are requested, and whether the application layer (the end-to-end user) can cause provisioning in the metro network or whether the metro network is configured and provisioned with a variety of connections that can be used (and scaled according to use) according to the features demanded by each use case.