To Slice or Not to Slice, That is the Question

 In 2017, Blog, November

 – 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.

[1] http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7926919
[2] https://datatracker.ietf.org/doc/draft-geng-netslices-architecture
[3] https://datatracker.ietf.org/doc/draft-king-teas-applicability-actn-slicing

Recommended Posts
Showing 4 comments
  • Albert Rafel
    Reply

    Adrian,

    Thank you. It is a really good effort. However, from my point of view as the Technical Manager of the Metro-Haul, and taking a very pragmatic approach, what is really important is to find the answers to the questions in your last paragraph:

    – What 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?
    – Can the application layer (the end-to-end user) cause provisioning in the metro network? or rather
    – Is the metro network configured and provisioned with a variety of connections such that can be used (and scaled according to use) according to the features demanded by each use case?

    Albert Rafel (Metro-Haul TM)

    • Avatar photo
      Adrian Farrel
      Reply

      Yes, I agree that those are the questions that need to be addressed.

      Do you have any answers?

      Adrian

      • Albert Rafel
        Reply

        Adrian, I don’t, but the Metro-Haul project will contribute towards finding/defining an answer.

  • Albert Rafel on behalf of Phil Eardley
    Reply

    On behalf of Philip Eardley, a BT colleague in Networks Research.

    I fully agree with his comment (paragraphs 3 & 4) about the lessons from “bandwidth on demand” discussions – and the non-starter economically & technically to “turn up a high-capacity optical path to support a micro flow in the IP network”.
    In Adrian’s proposed definition I like the 3 bullets (which he calls the aspects of the service level agreement). It fits with my informal description that a slice is a dash of VPn, a splash of QoS and a drop of NFV.
    The first bullet about quality – the measures mentioned (bandwidth, latency, jitter) are about network connectivity. I think you could also mention ones for processing and storage and also for virtualised services (operations per second or similar). Resilience (availability and failover time) are a couple of other important ones.
    The second bullet about the “network service functions”. I think it would be better to express this as the network service. The service provider layer should be exposing the network service, rather than the individual component functions that are implemented by the Service Provider (more below).
    The third bullet about the location and nature of the connectivity. Perhaps you could mention other aspects like point to point vs multipoint, what layer (in the IP stack), support for mobility of the users etc.
    Although it’s (I think) implicit in Adrian’s definition, I think you could explicitly say that the idea is that a single network infrastructure is partitioned into slices with different characteristics regarding these bullets (quality, functionality and connectivity).
    I like the definition in terms of the interface between a User and Service Provider. I think this leaves open the question whether a slice is mainly about how the operator runs its infrastructure more efficiently, or whether it’s mainly about new types of service that it offers to its customers (inward vs upward looking; cost saving vs revenue generation). (The ACTN definition seems to focus a bit more on the former whilst the IEEE definition a bit more on the latter.)
    Since you’re aiming at a robust and generic definition, I think it would be worth saying a bit more about this interface. I think it should be a client-server style API with universal semantics (ie common information model).
    I fully agree that recursion is important and in fact I’d mention it explicitly somewhere within the definition, as it helps determine what the interface is like. I think a specific example helps people understand what recursion means and that multiple SPs may be involved. Perhaps you could also say automation-ready (with recursion a critical part of that).
    (Incidentally, people tend to think of multiple SPs in terms of different regions that are stitched together as a series of peer-to-peer interfaces, as is implied in the Geng end-to-end network slice definition. I think this is wrong – this should also be hierarchical, with an overall slice spanning the ends, with then the top-level SP organizing a (sub-)slice in each of the various domains.)
    In your first paragraph, you say “a Service Provider is a network operator that control a service network or a collection of server networks”. I think “control” is slightly wrong – I prefer “delivers a network service”. The point is that the interface is opaque, in that a Service Provider can make its own decision about how to deliver the network service and its service level agreement – including it can decide to devolve operation of some or all of the network service to another Service Provider; it can decide to use over-provisioning, less resources plus prioritization, or some complex QoS scheme and minimal resources. In terms of the functionality like authentication or parental control, it can decide how to implement this in terms of micro-services /functions (VNFs) (hence I don’t like that bullet-2 mentions functions). I like the very last paragraph about the metro-haul project – which is basically saying that the project, as a “Service Provider”, can decide how it wants to implement a slice and what type of service level agreement it wants to offer.
    Best wishes,
    Phil

Leave a Comment

Start typing and press Enter to search

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close