Realization of Composite IETF Network Slices

Network slicing can be used to meet the connectivity and performance requirement of different applications or customers in a shared network. defines the terminologies and the characteristics of IETF network slices. It also discusses the general framework, the components and interfaces for requesting and operating IETF network slices. A Network Resource Partition (NRP) is a subset of network resources in the underlay network and the associated policies, which can be used to deliver the IETF network slice services with the required Service Level Objectives (SLOs) and Service Level Expectations (SLEs). describes the framework and the candidate technologies for providing enhanced VPN (VPN+) services. VPN+ leverages the VPN and Traffic Engineering (TE) technologies and adds characteristics that specific services require beyond those provided by conventional VPNs. VPN+ could be used to underpin network slicing, and could also be of use in general scenarios providing enhanced connectivity services between customer sites. For delivering VPN+ service, the concept of Virtual Transport Network (VTN) is introduced, which is a virtual underlay network consisting of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the underlay, so as to provide the network characteristics required by the customers. In the context of IETF network slicing, NRP can be seen as an instantiation of VTN. An IETF network slice may be used for 5G or other network scenarios. In the context of 5G, the 5G end-to-end network slices consist of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of 5G end-to-end network slice can be provided using IETF network slices. In some scenarios, IETF network slices may span multiple network domains, and IETF network slices may be composed hierarchically, which means a network slice may itself be further sliced. This document first describes the possible use cases of composite IETF network slices, then it provides considerations about the realization of composite IETF network slices. For the interaction between IETF network slices with 5G network slices, the identifiers of 5G network slice may be introduced into IETF networks. For the multi-domain IETF network slices, the Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) is defined. For the hierarchical IETF network slices, the structure of the NRP ID is discussed. These network slice related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite IETF network slices. This document also describes the management considerations of composite network slices.

One typical scenario of multi-domain IETF network slice is to support 5G network slicing as shown in Figure 1. 5G end-to-end network slices consists of the slice subnets in RAN, Mobile Core and Transport networks. In the RAN and Mobile Core networks, the 5G end-to-end network slice is identified by a Single Network Slice Selection Assistance Information (S-NSSAI). In the transport network, the 5G network slice is mapped to one or multiple IETF network slices. The IETF network slice itself may span multiple network domains. An IETF network slice may be realized as an inter-domain VPN+ service, which is similar to the inter-domain VPNs with additional resource and performance commitments. In the underlay network, the IETF network slices can be supported by the multi-domain NRPs, which is the concatenation of multiple intra-domain NRPs from different network domains.

A typical network slice deployment scenario is in the multi-industrial network case, in which a physical network is used to deliver services to multiple vertical industries. Separate IETF network slices are provided for different industries, such as health-care, education, manufacturing, governmental affairs, etc. Then within the network slice of a specific industry, it may be necessary to create separate network slices for some or all of the customers within each industry. For example, within the education network slice, some of the universities may require a separate network slice to connect with a set of branch campuses. Another example is within the health-care network slice, some of the hospitals may require a separate network slice for the connectivity and services between a set of the branch hospitals.

Another network slice deployment case is to provide dedicated IETF network slices for some important customers as the first-level network slices. While the customers may require to split further their network slices into different sub-network slices for a subset of applications. For example, a network slice for a hospital may be further divided to carry different types of medical applications, such as remote patient monitoring, remote ultrasound diagnosis, medical image transmission etc.

An IETF network slice can also be delivered as a wholesale service to other network operators. In this case, a network operator can be the customer of a network slice, and it may also need to deliver IETF network slice services to its customers. This is similar to the Carrier's Carrier VPN service, while some additional requirements on the SLOs and SLEs may be required by the second-level network slice customer.

The realization of composite network slices may require additional capability and functionality in the data plane, control plane and management plane technologies. These considerations are analyzed in the following subsections.

For the realization of multi-domain network slices, the following network slice related identifiers may be introduced in the management plane, control plane and the data plane. Intra-domain NRP ID: This is the NRP-ID as defined in . It is used by the network nodes in a network domain to determine the set of local network resources reserved for an NRP. Multi-domain NRP ID: This identifier uniquely identifies a multi-domain NRP. In each network domain, the domain border nodes can map the multi-domain NRP-ID to the intra-domain NRP IDs within the local network domain. A multi-domain network slice may be supported by a multi-domain NRP in the underlay, which consists of the concatenation of multiple intra-domain NRPs. Each intra-domain NRP can be identified using a domain-significant NRP ID. In order to facilitate the concatenation of multiple intra-domain NRPs into a multi-domain NRP, the multi-domain NRP may be needed. For the scenarios of 5G network slicing, in order to facilitate the mapping and management of 5G network slice services in the IETF network slices, the identifier of 5G network slice may be needed in the transport network. 5G network slice ID (S-NSSAI): This identifies the 5G network slice. When required, it may be used by the network entities of IETF network slices to provide traffic monitoring at the 5G network slice granularity. For the service scenarios which are not specific to 5G network slicing, other types of service identifiers may be used to identify the IETF network slice services. The existence of the multi-domain NRP-ID depends on how the intra-domain NRP IDs are managed. In some network scenarios, different network domains can have consistent NRP ID allocation, then the intra-domain NRP IDs can also be used to identify the multi-domain NRPs. The awareness to the S-NSSAI and other network slice service identifiers depend on whether the performance of 5G end-to-end network slices need to be monitored in the transport network. For the realization of hierarchical IETF network slices, since network resources may be partitioned hierarchically, the NRP IDs may be used to identify the first-level NRPs, the second-level NRPs, or the both.

The considerations about the network slice data plane can be classified into two aspects. The first is the mechanisms used for partitioning the data plane network resources, and the second is the mechanisms used to determine to which network slice a data packet belongs.

For multi-domain network slices, in order to fulfil the end-to-end network slice service commitment, it is important that the forwarding plane network resources in each of the involved network domains can be partitioned, so that the intra-domain NRPs can be created, which together constitute the multi-domain NRPs for the end-to-end network slice services. For hierarchical network slices, the forwarding plane network resources may need to be partitioned hierarchically. Taking a two-level hierarchical network slice as an example, the bandwidth and associated resources of a physical interface needs to be partitioned into two levels. Different technologies may be used for the data plane resource partitioning in different network domains or different network hierarchy. For example, for resource partitioning of multi-domain network slices, it could be the case that in one network domain, the forwarding resources may partitioned using Flexible Ethernet (FlexE), while in another network domain, the resources may be partitioned using dedicated queues under the same interface. Similarly, for hierarchical network resource partitioning, the network resources of the first-level NRPs may be partitioned using separate layer-3 sub-interfaces with dedicated link bandwidth, while the second-level NRPs may be further partitioned using virtual data channels under the layer-3 sub-interfaces.

The traffic of IETF network slices can be steered into the corresponding NRPs based on one or multiple fields in the data packet, so that the set of network resources of the corresponding NRPs are used for processing and forwarding the packet. On the edge nodes of an IETF network slice, traffic flows can be classified and mapped to IETF network slices using flexible matching rules based on operators' local policy. While on the intermediate network nodes, a dedicated data plane NRP Identifier can facilitate the identification of the NRP a packet belongs to. When IETF network slice service packets traverse a multi-domain NRP, the identifier of the multi-domain NRP may be carried in the packet, so that the border nodes of each network domain can determine the local domain NRP according to the mapping relationship between the multi-domain NRP ID and the local domain NRP ID. The intra-domain NRP ID may be carried in the packet for the NRP-specific packet processing on network nodes in the local domain. This usually requires that the involved network domains of a multi-domain NRP are in the same trusted domain. For the 5G end-to-end network slices, in order to facilitate the mapping and management of 5G network slice services in the IETF network slices, the S-NSSAI of 5G network slice may be carried in the packet sent to the transport network. For the service scenarios which are not specific to 5G network slicing, other types of service identifiers may be carried in the packet sent to the transport network. For hierarchical IETF network slices, the data plane NRP ID may be used to identify the first-level NRPs, the second-level NRPs, or the both. There may be different options in the design of the data plane NRP ID for hierarchical network slices. The first option is to use a unified data plane identifier for both the first-level NRP and the second-level NRP. In this case, the first-level NRPs and the second-level NRPs are identified using distinct identifier values. The second option is to use hierarchical identifiers for the first-level NRP and the second-level NRP respectively. In this case, the first part of the identifier is used to identify the first-level NRP, and the second part of the identifier is used to identify the second-level NRP. Depends on the data plane technologies used, the hierarchical NRP may be encapsulated in a continuous field in the packet, or may be positioned in separate fields.

For multi-domain network slices, the control plane would be similar to the Inter-AS VPN services . In the overlay, the Option C mode of inter-AS VPN is preferred due to the simplicity in the service endpoints provisioning. Using the Option A or Option B mode of inter-domain VPN for multi-domain network slices is also possible, although they are not the focus of this document. In the underlay, the provisioning and distribution of the intra-domain NRP IDs in different network domains may be done via network controllers or distributed control plane. The allocation of the Multi-domain NRP-ID and the mapping relationship between the multi-domain NRP ID and the intra-domain NRP IDs are usually performed by the IETF network slice controller. For 5G end-to-end network slices, the IETF network slice controller may also be responsible for the provisioning of the mapping relationship between the S-NSSAI and the multi-domain NRP ID at the domain edge nodes. For hierarchical network slices, the control plane is used for the distribution of the attributes and states of NRPs in different hierarchy among network nodes in the NRP and also to the network controller. With different modeling of the partitioned network resources, the information may be advertised as either layer-3 or layer-2 network information.

For multi-domain network slices, some coordination in management plane among different network domains would be needed. That includes but not limited to the planning of intra-domain NRPs to meet the same or similar set of SLO and SLEs, the allocation and mapping of intra-domain NRP IDs with the multi-domain NRP IDs. For the hierarchical network slices, the management system of network operator needs to provide life-cycle management to both the first-level network slices and the second-level network slices. It should allow the management of the first-level and second-level network slices separately, while the relationship between the first-level and second-level network slices also need to be maintained in the management system. The management system may need to support additional functions and procedures for the management of hierarchical network slices. Further analysis of management plane requirements is for future study.

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

Several broad security considerations exist, and Section 6 of highlights several important security aspects for network slice deployment and operation. These security considerations will apply to the architecture and techniques outlined in this document and multi-domain NRPs for end-to-end network slices. Ensuring that only authorised customers have access to end-to-end network slices is important. In addition, malicious intent to access, delete or modify the end-to-end service should also be mitigated or negated. The control plane may distribute attributes of different levels of hierarchical NRPs among network nodes, including communicating this information to the controller. Therefore, secure methods will be required to disseminate, control, and store NRP related information. Multiple data plane methods are applicable for instantiating the end-to-end network slice services. However, these techniques have security advantages and disadvantages and must be considered when deploying multi-domain and hierarchical network slices. In addition, some encapsulation methods will have stronger security or encryption capabilities that may be required for certain customer slice applications where confidentiality or securing data being transmitted across the end-to-end slice is needed. Future versions of this document will expand the security discussion and propose techniques to address the security concerns, and highlight any missing requirements specific to this document.

The authors would like to thank Daniel King for his review and comments.