Network Slices

There has been a lot of chatter recently in the 5G wireless world about network slices. A draft was recently published in the IETF on network slices—draft-gdmb-netslices-intro-and-ps-02. But what, precisely, is a network slice?

Perhaps it is better to begin with a concept most network engineers already know (and love)—a virtual topology. A virtual topology is a set of links, with some subset of connected devices (either virtual or real), that act as a subset of the network. Isn’t such a subset of the network a “slice” if you look at it from a different angle? To ask the question in a different way: how are network slices different from virtual network overlays?

To begin, consider the control plane. In the world of virtual topologies, there is generally one control plane that provides reachability, as well as sorting reachability into each virtual topology. For instance, BGP carries a route target and a route distinguisher to indicate which virtual topology any particular destination belongs to. A network slice, by contrast, actually has multiple control planes—one for each slice. There will still be one “supervisor control plane,” of course, much like there is a hypervisor that manages the resources of each virtual machine on a virtualized compute node. This hyper control plane (hyperCP) will allocate resources and manage access, but it will not dictate what control plane is run within the slice, just like the hypervisor does not dictate the OS that must be run in the virtual machine. The control plane within the slice can determine which resources to use to solve what problems, just like the OS within a virtual machine. The slice itself can be limited to only use some portion of the overall network capabilities; the control plane within the slice determines how to allocate the resources within the slice.

So a network slice is something like a blending of a virtual network topology with the concepts of a virtual machine in a hypervisor based system. If any of this sounds familiar, it is—this was the basic idea behind virtual topologies in the first place. The main problem is that virtual topologies always live as something between what appears to be a completely separate network “purchased” by the customer, and the overall network owned by the provider. Network slices, first of all, aim to resolve this situation, by making slices conceptually closer to virtual machines, rather than our existing concept of virtual topologies.

Network slices, however, go beyond just the topology, to include the entire set of resources needed to build a network platform. This means network slices are also supposed to encompass compute and storage, or even perhaps a set of services available to be used by the customer. This means there could be a full set of network side services within the slice, including quality of service, service chaining, and others.

The most natural use case seems to be that of a provider selling access to a specific set of services to a customer, much like current public cloud providers, only in a standardized way, rather than using techniques developed by each individual public cloud operator. Other use cases are the deployment of two different kinds of technology on the same, such as running 4G and 5G at the same time, apparently completely independently of one another, and adjusting their available resources as needed while one is phased in, and the other is phased out.

Network slices are an interesting idea, but they are an idea fraught with complexity. Whether or not they will eventually “solve” the “purchase a slice of resources” problem in a way that can be widely deployed is a matter for conjecture and research—but this is definitely an area of research and study worth keeping an eye on.