Blog

Network slicing remains a key concept in the development of new network technologies and the planning of new network services especially in support of 5G.

Figure 1 Network slicing by example – Source Nokia

As the foremost standards-making body for the Internet, it is natural that the Internet Engineering Task Force (IETF) should spend time considering network slicing and its implications for IP technologies.

At the 99th IETF meeting in Prague in July 2017, a “Birds of a Feather” (BoF) meeting [1] was held to bring together interested parties to discuss network slicing and determine what work, if any, the IETF needed to do to address the problem space. The meeting was addressed by the 3GPP’s liaison to the IETF, and several preliminary Internet-Drafts on use cases and the applicability of existing IETF technologies were presented. The conclusion was that there was a lot of enthusiasm to work on this topic, but a wide range of views about what issues needed to be solved and what the overall architecture should be. The proponents were sent away to attempt to focus their efforts.

A second BoF meeting (called “Common Operations and Management on network Slices (coms)” was held at the 101st IETF meeting in London in March 2018 [2]. This meeting was able to show significant progress in understanding the implications of network slicing for IP and related networks, and there was general agreement that many of the problems exist in the management and operations space, while protocol extensions to support network slicing would be relatively minor. However, there was no consensus on whether an overarching architecture was needed or if network slicing solutions should be built up based on existing techniques and technologies.

Figure 2 Network Slicing and Management Responsibilities – Source IEEE NETSOFT Tutorial: Network Slicing Landscape

At the time of writing this blog, the IETF has eleven active Internet-Drafts [3] examining issues surrounding network slicing. These documents range from descriptions of use cases and requirements, through proposed architectures, to discussions of how existing IETF technologies can be used or extended to deliver network slicing. Several of these documents also describe “enhanced VPNs” (or VPN+) that comprise an approach to achieve network slices.

This blog highlights four foundational documents for understanding the network slicing work that the IETF is doing:

• “Considerations on Network Virtualization and Slicing” [4] is a useful reference document that puts network slicing and network virtualisation in the context of the Internet architecture. The broad canvas allows the authors to compare and contrast different approaches (Protocols versus Representations of Virtual Networks, Selection versus Creation and Orchestration, Software versus Protocols) and to provide an overview of IETF virtualisation technologies. By referencing established architectural principles, the document is able to derive some areas for future work including the ability to manage heterogeneous technologies, the ability to specify “statistical” rather than hard performance parameters, the need to map from high abstraction level specifications to concrete network configurations, and the need for tools to manage cross-domain virtualized networks and resources;

• Another key background document looks at the applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to network slicing [5]. This is particularly important for the Metro-Haul project where ACTN plays a central role in the management architecture. The draft describes the relationship between logical or virtual networks and network slices and shows how the Software Defined Networking (SDN) approach at the core of ACTN can be used to request and manage those virtual networks so that each slice is separately operated;

Figure 3 Abstraction and Control of Traffic Engineered Networks (ACTN) to network slicing

• A third Internet-Draft is called ” Architecture for Data Model Driven Network Management: The Network Virtualization Case ” [6]. This presents how the IETF’s data models for service operation (such as the Layer 3 VPN Service Model [7] and the ACTN Virtual Network Operation Model [8]) can be coordinated with topology management models and with device and protocol management models. The whole architecture allows for top-to-bottom SDN configuration, management, and orchestration of network resources to deliver network slices that meet operational application requirements;

• Lastly, “A Framework for Enhanced Virtual Private Networks (VPN+)” [9] specifies a framework for using existing, modified, and new networking technologies as components to provide an enhanced VPN service. This document asserts that pure overlay networking cannot provide the level of function and control demanded by the user of a network slice because a tighter coordination between the overlay and undelay is needed. In the terminology of this draft “VPN+” refers to a virtual network (an enhanced VPN) which has dedicated network resources allocated from the underlay network. Unlike a traditional VPN, an enhanced VPN can achieve greater isolation and guaranteed performance.

Thus, most of the work in the IETF has resolved to architectural analysis and data modelling, with some enhancements to protocols for the collection of telemetry information and for providing additional control of network resources.