| Internet-Draft | Composite IETF Network Slices | March 2024 |
| Li, et al. | Expires 5 September 2024 | [Page] |
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC XXXX describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC XXXX.¶
This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. 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 network slices. This document also describes the management considerations of composite network slices.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
RFC Editor Note: Please replace "RFC XXXX" in this document with the RFC number assigned to draft-ietf-teas-ietf-network-slices, and remove this note.¶
[I-D.ietf-teas-ietf-network-slices] defines network slicing in networks built using IETF technologies. These network slices may be referred to as RFC XXXX Network Slices, in this document we simply use the term "network slice" to refer to this concept when only the network slices as described in [I-D.ietf-teas-ietf-network-slices] is referred to.¶
A network slice aims to offer connectivity service to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. [I-D.ietf-teas-ietf-network-slices] defines the terminologies and the characteristics of network slices. It also discusses the general framework, the components and interfaces for requesting and operating network slices. The concept of a Network Resource Partition (NRP) is introduced by [I-D.ietf-teas-ietf-network-slices] as part of the realization of network slices. An NRP is a collection of network resources in the underlay network, which can be used to ensure the requested SLOs and SLEs of network slice services are met.¶
[I-D.ietf-teas-enhanced-vpn] describes a layered architecture and the candidate technologies in different layers and planes for providing NRP-based enhanced VPN services. Enhanced VPNs aim to meet the needs of customers or applications which require connectivity services with advanced characteristics, such as the assurance of SLOs and specific SLEs. Enhanced VPN services can be delivered by mapping one or a group of overlay VPNs to an NRP which is allocated with a set of network resources. The enhanced VPN architecture and technologies could be used for the realization of network slices. [I-D.ietf-teas-ns-ip-mpls] describes a solution to realize network slicing in IP/MPLS networks.¶
In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC XXXX.¶
This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. 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 network slices. This document also describes the management considerations of composite network slices.¶
One typical scenario of multi-domain 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 slices are identified by Single Network Slice Selection Assistance Information (S-NSSAI). In the transport network, the 5G network slices are mapped to one or multiple network slices as described in RFC XXXX.¶
The RFC XXXX network slice itself may span multiple network domains. It may be realized as an inter-domain enhanced VPN service, which is an inter-domain VPN with additional resource and performance commitments. In the underlay network, the IETF network slices can be mapped to an inter-domain NRP, which is the concatenation of multiple intra-domain NRPs from different network domains.¶
5G Network Slices (S-NSSAI)
o--------------------------------------------------------------------o
/----\ /----\ /----\ /----\ /----\
/ \ // \\ // \\ // \\ / \
| RAN |---| TN-1 |---| TN-2 |----| TN-3 |----| Core |
\ / \\ // \\ // \\ // \ /
\----/ \----/ \----/ \----/ \----/
Multi-domain IETF Network Slice
o--------------------------------------------------o
Multi-domain NRPs
o=========================================o
Intra-domain Intra-domain Intra-domain
NRPs NRPs NRPs
o**********o o***********o o***********o
o##########o o###########o o###########o
o@@@@@@@@@@o o@@@@@@@@@@@o o@@@@@@@@@@@o
Figure 1. Multi-domain IETF Network Slice in 5G Scenario¶
This section gives some example use cases of hierarchical NRP and network slices, in which two levels of NRPs/slices are described. More than two levels of NRPs is also possible, while it is out of the scope of this document.¶
A typical hierarchical network slice deployment scenario is in the multi-industrial network case, in which a shared physical network is used to deliver services to multiple vertical industries. Separate NRPs and network slices are provided for different industries, such as health-care, education, manufacturing, governmental affairs, etc. Then within the NRP of a specific industry, it may be necessary to create separate NRPs and network slices for specific customers.¶
For example, within the NRP created for the education industry, some of the universities may require a separate NRP and network slices to connect the branch campuses. Another example is within the NRP created for health-care industry, some of the hospitals may require a separate NRP and network slices for the connectivity and services between a set of the branch hospitals.¶
---------------------------------/
/ Industry-1 NRP/Slices /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Industry-2 NRP/Slices /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 2. Hierarchical Network Slices: Scenario 1
¶
Another network slice deployment case is to provide an NRP and network slices for some important customers as the first-level network slices. While the customers may require to further split the resources of their NRP into different sub-NRP and sub-slices for a subset of applications.¶
For example, an NRP 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.¶
---------------------------------/
/ Customer NRP/Slice 1 /
/ ----------------------- /
/ / APP NRP/Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / APP NRP/Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Customer NRP/Slice 2 /
/ ----------------------- /
/ / APP NRP/Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / APP NRP/Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 3. Hierarchical Network Slices: Scenario 2
¶
An NRP or 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 additional requirements on the SLOs and SLEs required by the second-level network slice customer is fulfilled by a wholesale NRP.¶
---------------------------------/
/ Wholesale NRP/Slice 1 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Wholesale NRP/Slice 2 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 4. Hierarchical Network Slices: Scenario 3¶
The realization of composite network slices may require additional capability and functionality in the data plane, control plane and management plane technologies. Considerations about the realization of composite network slices 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/or the data plane.¶
Intra-domain NRP ID: This is the NRP-ID as defined in [I-D.ietf-teas-nrp-scalability]. It is used by network nodes in a network domain to determine the set of local network resources allocated to 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 used 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 network-wide 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 in the management plane, control plane and/or data plane.¶
In the context of 5G end-to-end 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 introduced into the transport network.¶
5G network slice ID (S-NSSAI): This identifies a 5G network slice. When required, S-NSSAI may be used by network entities of RFC XXXX network slices for traffic mapping and monitoring at the 5G network slice granularity.¶
For network slice scenarios which are not specific to 5G network slicing, some types of service identifiers may be used by network entities of RFC XXXX network slices to classify and map the network slice services to the corresponding NRPs.¶
The requirement of multi-domain NRP-ID depends on how the intra-domain NRP IDs are managed. In some network scenarios, different network domains are under the same network administration, and can have consistent NRP ID assignment, then the same intra-domain NRP ID can be used in different network domains, and may be further used to identify a multi-domain NRP built across these domains. In other network scenarios, a multi-domain NRP ID would be needed for the identification of the concatenation of intra-domain NRPs in different domains. The awareness of the S-NSSAI and other network slice service identifiers depend on whether the performance of the 5G or other network slice services need to be monitored in the transport network.¶
For the realization of hierarchical network slices, since network resources may be partitioned hierarchically, different NRP IDs may be used to identify the first-level NRPs and the second-level NRPs respectively.¶
For multi-domain network slices, in order to fulfil the end-to-end network slice service commitment, it is important that the network resources in each of the involved network domain can be partitioned for different NRPs, so that intra-domain NRPs can be created in each network domain, which together constitute the multi-domain NRPs for the end-to-end network slice services.¶
For hierarchical network slices, the network resources in the underlay network 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 may need to be partitioned into two levels.¶
In different network domains or different network slice hierarchy, different technologies may be used for the data plane resource partitioning. For example, for resource partitioning of multi-domain network slices, it could be the case that in one network domain, the network resources are partitioned using Flexible Ethernet (FlexE), while in another network domain, the network resources may be partitioned using virtual sub-interfaces or 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 FlexE or virtual sub-interfaces with guaranteed link bandwidth, while the second-level NRPs may be further partitioned using virtual data channels under the FlexE or virtual sub-interfaces.¶
The considerations about the data plane encapsulation is mainly related to the mechanisms used to determine to which network slice a data packet belongs.¶
At the ingress of an IETF network slice, service flows of network slice can be classified and mapped to corresponding NRPs using flexible matching rules based on operators' local policy, so that the set of network resources of the corresponding NRPs can be used for processing and forwarding the service packet. Such matching can be done based on one or multiple fields in the data packet. While on the intermediate network nodes, a dedicated data plane NRP ID [I-D.ietf-teas-nrp-scalability] can facilitate the identification of the NRP a packet belongs to.¶
When network slice service packets traverse a multi-domain NRP, the multi-domain NRP ID may be carried in the packet, then the border nodes of each network domain can use it to determine the local domain NRP according to the mapping relationship between the multi-domain NRP ID and the local intra-domain NRP ID. The intra-domain NRP ID may also be carried in the packet for the NRP-specific packet processing on network nodes in the local domain. This requires that the involved network domains are considered as in the same trusted domain, in which the assignment of multi-domain NRP IDs is possible.¶
For hierarchical IETF network slices, each level of the hierarchical NRP needs to be identified using some fields in the data packet. One possible approach is to use NRP-specific resource-aware SIDs [I-D.ietf-spring-resource-aware-segments] to identify the set of resources allocated in the first-level NRPs, then use a dedicated NRP ID to identify the set of resources in the second-level NRPs. Alternatively, for better scalability [I-D.ietf-teas-nrp-scalability], dedicated NRP IDs may be used to identify both the first-level NRPs and the second-level NRPs. When dedicated NRP ID is used for both hierarchies, there are 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 NRP ID for both the first-level NRPs and the second-level NRPs. In this case, the first-level NRPs and the second-level NRPs are distinguished using different NRP ID 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 may be used to identify the first-level NRP, and the second part of the identifier may be used to identify the second-level NRP. Depends on the data plane technologies used, the hierarchical NRP may be encapsulated in one field, or may be positioned in separate fields in the packet.¶
In the context of 5G end-to-end network slicing, in order to facilitate the mapping and management of 5G network slice services to IETF network slices, the S-NSSAI of 5G network slice may be carried in the data packet sent to the transport network. For network slicing scenarios which are not specific to 5G, other types of service identifiers may be carried in the packet sent to the transport network.¶
The control plane of multi-domain IETF network slices would be similar to that of the Inter-AS VPN services [RFC4364], possibly with additional information of network slice related characteristics signaled in the control plane. The Inter-AS Option C mode is preferred due to the simplicity in network slice service endpoints provisioning, which requires to establish multi-domain NRPs in the underlay network. The Option A or Option B mode of inter-domain VPN may also be used for multi-domain IETF network slices, while they are not the focus of this document.¶
In each network domain, the provisioning and distribution of the intra-domain NRP information may be done via either the local domain network slice controllers or a distributed control plane, then the multi-domain NRP is realized as the concatenation of multiple intra-domain NRPs. The allocation of the multi-domain NRP-ID and the mapping relationship between the multi-domain NRP ID and intra-domain NRP ID in each domain can be done by a IETF network slice controller which is responsible for multiple network domains. Alternatively, distributed control plane may be used to advertise or signal the necessary information for stitching the NRP-specific paths of intra-domain NRPs into a multi-domain NRP-specific path. For 5G end-to-end network slices, when S-NSSAI is carried in the network slice service packets, the IETF network slice controller may be responsible for the provisioning of the mapping relationship between the S-NSSAIs and the multi-domain NRP IDs at the edge of the transport network.¶
For hierarchical network slices, the control plane is responsible for the distribution of the attributes and states of NRPs in different hierarchy both among network nodes in the NRP and to the network controller. According to the modeling of network resource partitioning in different hierarchy, the NRP information may be advertised as either layer-3 or layer-2 network information, and the control protocols may be extended correspondingly. The details of the control plane extensions are out of the scope of this document.¶
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 and the second-level NRPs and network slices. The first-level and second-level NRPs and network slices may be managed separately, while the relationship between the first-level and second-level NRPs and network slices also need to be maintained in the management system. Thus 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 [I-D.ietf-teas-ietf-network-slices] 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 security concerns, and highlight any missing requirements specific to this document.¶
Zhibo Hu Email: huzhibo@huawei.com¶
The authors would like to thank Daniel King for his review and comments.¶