Before we can talk about network slicing, we need to talk about what has made it such a networking buzzword these days — 5G.
5G is the fifth generation of cellular networks, bringing new capabilities. It enables a new kind of network that is designed to connect virtually everyone and everything together including machines, objects, and devices.
Some of the key 5G use cases include:
- Enhanced Mobile Broadband (eMBB)
- High data rates across a wide coverage area
- Ultra Reliable Low Latency Communications (URLLC)
- Target latency of 1 ms and requirements for end-to-end security and 99.999% reliability
- Massive Machine Type Communications (mMTC)
- Many devices that intermittently transmit small amounts of traffic
The idea here is not just more speed but to support brand new networking challenges, new use cases, industries, and experiences. The most interesting thing to note is that each of the key 5G use cases are asking for fundamentally different things from the network. This is where network slicing comes in.
The role of network slicing
Each network slice is a different virtualized and independent logical network on the same physical network infrastructure, created in order to meet the diverse service requirements. The network slice needs to be an isolated End-to-End (E2E) network tailored to a particular application under the end user Service Level Agreements (SLAs).
One may ask, why do we need this new term? Isn’t this similar to what we have been doing with, say, Virtual Local Area Networks (VLANs), Virtual Private Networks (VPNs), Traffic Engineering (TE), Quality of Service (QoS), Network Function Virtualization (NFV) and so on?
There is a need for a holistic E2E independent virtual network for each use case. VLANs by themselves can’t provide an end-to-end network; the QoS solution can provide a different treatment based on traffic type but not based on different tenets. Moreover, commercial needs are pushing for more dynamic requirements and lifecycle management than any of the existing techniques.
The IETF view of network slicing
The Traffic Engineering Architecture and Signaling (TEAS) Working Group at the IETF has been working towards defining the IETF network slice within the scope of the IETF networks. The E2E network slice would require stitching the IETF and the non-IETF (edge RAN and core DC networks).
There is a need for coordination at the higher systems with the E2E view to set up an E2E network slice spanning the edge, IETF network and the core.
The current working definition of the IETF network slice is as follows:
An IETF Network Slice is a logical network topology connecting a number of endpoints using a set of shared or dedicated network resources that are used to satisfy specific Service Level Objectives (SLOs).
The term ‘IETF’ is used to limit the scope. There was a long debate when the original proposed name was ‘transport network slice’ instead. The IETF network slice is not limited to 5G and considers many more interesting use cases, such as data centre interconnections and network wholesale services, to name a few. IETF network slicing is technology-agnostic and independent of underlying infrastructure connectivity and realization techniques.
The term SLO is a target value/range for the measurement of a Service Level Indicator (SLI), where the SLI is a quantifiable measure of network performance (using indicators like throughput and latency). Note that the more common term, SLA, refers to the contract between consumer and provider. The SLA can be expressed as a set of SLOs.
The proposed Northbound Interface (NBI) offers lifecycle management (including creation, modification, monitoring, and deletion) of the IETF network slice in a technology-agnostic form. It would be akin to modelling the intent. The proposed IETF network slice controller takes the request from the higher system and then realizes (or translates) it to the underlying infrastructure. The clear identification of the boundaries (the IETF network slice endpoints), the connectivity between them, and the SLOs that need to be fulfilled are required as part of the NBI.
The proposed IETF network slice controller needs to realize the slice. There is a lot of existing work going on at the IETF that could be used. For example, the Abstraction & Control of the TE networks (ACTN) framework that facilitates virtual network operation would be applicable. There are also different projects related to VPN services that would be relevant including TE techniques and Segment Routing (SR) protocols such as Border Gateway Protocol (BGP), Path Computation Element Protocol (PCEP) and Resource Reservation Protocol – Traffic Engineering (RSVP-TE). These are all building blocks needed to realize IETF network slices.
There are also new proposed solutions such as the Enhanced VPN project that call for tighter coordination and integration between underlay and overlay by defining a new term: Virtual Transport Network (VTN), which is an underlay customized network topology using techniques like SR, multi-topology (MT) and Flexible Algorithm in Interior Gateway Protocol. Similar to this, a new proposal has been put forth for a slice policy and slice aggregate to realize IETF network slices based on various control plane and data plane techniques.
The TEAS WG in the IETF is focusing on finalizing the definition and framework for the IETF network slice. The work on the technology agnostic NBI (based on a YANG model) and the various realization techniques are all likely to occur in parallel. It is an exciting time to participate in the TEAS WG discussion on the mailing list as well as the upcoming IETF 111 online, planned for July 2021. IETF network slices appear set to be a key technology enabling the most challenging 5G use cases.
Dhruv Dhody is Co-Chair of the Path Computation Element Working Group at IETF. The views expressed are his only and do not necessarily reflect the views of IETF, Huawei, or any other organization.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Thank you, this is a great report and well written