Network Working Group Y. Ma Internet-Draft R. Luo Intended status: Informational China Telecom Ningxia Expires: April 27, 2022 A. Chan B. Suen China Mobile Hong Kong J. Dong Huawei Technologies October 24, 2021 IETF Network Slice Deployment Status and Considerations draft-ma-teas-ietf-network-slice-deployment-00 Abstract Network Slicing is considered as an important approach to provide different services and customers with the required network connectivity, network resources and performance characteristics over a shared network. Operators have started the deployment of network slices in their networks for different purposes. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations collected from these IETF network slice deployments are also provided. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo 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 April 27, 2022. Ma, et al. Expires April 27, 2022 [Page 1] Internet-Draft IETF Network Slice Deployment October 2021 Copyright Notice Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IETF Network Slice Deployment Status . . . . . . . . . . . . 3 2.1. China Telecom Ningxia . . . . . . . . . . . . . . . . . . 3 2.2. China Mobile Hong Kong . . . . . . . . . . . . . . . . . 3 3. IETF Network Slice Deployment Cases . . . . . . . . . . . . . 3 3.1. Network Slicing for Multi-Industrial Network . . . . . . 4 3.2. Network Slicing for Fixed-Mobile Convergence . . . . . . 5 4. Network Slice Deployment Considerations . . . . . . . . . . . 7 4.1. Isolation . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Topology and Connection Types . . . . . . . . . . . . . . 7 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Data Plane Scalability . . . . . . . . . . . . . . . 8 4.4. Automation . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Network Slicing is considered as an important mechanism to provide different services and customers with the required network connectivity, resources and performance characteristics over a shared network. [I-D.ietf-teas-ietf-network-slices] describes network slicing in the context of networks built from IETF technologies, and discusses the general framework of IETF network slices. [I-D.ietf-teas-enhanced-vpn] describes the framework and candidate Ma, et al. Expires April 27, 2022 [Page 2] Internet-Draft IETF Network Slice Deployment October 2021 component technologies for providing enhanced VPN services, by utilizing an approach that is based on existing VPN and Traffic Engineering (TE) technologies and adds characteristics that specific services or customers require above traditional overlay VPNs. VPN+ is delivered using a VPN overlay and an underlying Virtual Transport Network (VTN) which has a set of dedicated or shared resources and is associated with a customized logical network topology in the underlay network. A centralized network controller can be used for the creation and operation of the VTNs, and the mapping of the enhanced VPN services to the appropriate VTNs. The enhanced VPN (VPN+) mechanism can be used for the realization of IETF network slices. Although the concept of network slicing is firstly introduced for the 5G, the use cases of IETF network slices are not limited to 5G. Operators have started the deployment of IETF network slices based on VPN+ in their networks for different service scenarios. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations about the IETF network slice deployments are also collected. 2. IETF Network Slice Deployment Status 2.1. China Telecom Ningxia Service scenario: Multiple industrial services Resource partitioning: Virtual sub-interface with dedicated bandwidth Data Plane: SRv6 Control plane: SR Policy with link affinity 2.2. China Mobile Hong Kong Service scenario: Fixed-Mobile convergence services Resource partitioning: Flexible Ethernet interface and virtual sub- interface with dedicated bandwidth Data plane: SR-MPLS Control Plane: SR Policy with link affinity 3. IETF Network Slice Deployment Cases Ma, et al. Expires April 27, 2022 [Page 3] Internet-Draft IETF Network Slice Deployment October 2021 3.1. Network Slicing for Multi-Industrial Network China Telecom NingXia has deployed a dedicated SRv6 based network to carry multiple industrial services. The three major types of service in the network are: Healthcare service, Education service and Broadband services, and the operator plans to migrate a set of industrial and governmental services from dedicated private networks or Multi-Service Transport Platform (MSTP) networks to this IP based multi-industrial network. With the help of network slicing, services of different industries can be isolated from each other, so that the performance of each service can be guaranteed, and the cost of maintaining and expanding the dedicated private networks for each industry can be reduced. In order to provide the required resource and security isolation between the health care, education and broadband services, three virtual transport networks (VTNs) are created in the network. All the VTNs share the same IGP instance, while each VTN is defined with a logical topology using different link administrative groups (i.e. color), and is allocated with a set of dedicated bandwidth resources on each involved physical link using the virtual sub-interface mechanism. In a VTN, each link is assigned with a SRv6 End.X SID to identify the sub-interface used for packet forwarding. With more industrial and governmental customers migrate to this network, more VTNs with dedicated network resources will be created. Multiple L3VPNs belonging to the same industry are provisioned in the corresponding VTN. For example, the VTN created for the health care services is used to support the VPNs for the connection between hospitals belonging to the medical consortium, and the VPNs for connecting the hospitals and the insurance systems in the healthcare cloud. The VPN traffic mapped to a VTN is steered into the set of virtual sub-interfaces of the VTN based on the corresponding SRv6 End.X SIDs. A centralized network controller is responsible for the management of the VTN and the VPNs. This includes the topology and resource planning of VTN, the VTN creation, the mapping of VPN services to the VTN, and the computation of SRv6 TE paths based on the service constraints and the topology and resource attributes of the VTN. The controller also collects the traffic statistics and performance information of the VTNs and the VPN services to enable the network slice services visualization and ensure the service SLAs are always met. Ma, et al. Expires April 27, 2022 [Page 4] Internet-Draft IETF Network Slice Deployment October 2021 +-------------------+ Centralized | Network Controller| Control & Management +-------------------+ /\ || \/ ________________________ VPN-1 o----/ o----o----o----o----o /----o VPN-2 o----/ / / / /----o VTN-1 VPN-3 o----/ o----o----o----o----o /----o Healthcare /_______________________/ ________________________ VPN-4 o----/ o----o----o----o----o /----o / / / / / VTN-2 VPN-5 o----/ o----o----o----o----o /----o Education /_______________________/ _________________________ VPN-6 o----/ o----o----o----o----o /----o VPN-7 o----/ / / / /----o VTN-3 VPN-8 o----/ o----o----o----o----o /----o Broadband /________________________/ .... _________________________ VPN-m o----/ ... /----o VTN-n /________________________/ Vertical Figure 1. IETF network slice deployment in China Telecom Ningxia 3.2. Network Slicing for Fixed-Mobile Convergence China Mobile Hong Kong (CMHK) has deployed network slices in their SR-MPLS based Fixed-Mobile Convergence (FMC) network, which is used to carry the mobile services, the enterprise private line services and the residential broadband services together. Each type of service has different traffic characteristics and performance requirements, thus independent network planning and operation for each service type is required. Currently three VTNs are created for mobile service, enterprise service and the residential service respectively. Depends on the new service requirement of 5G, More VTNs may be created for 5G critical services in the future. According to the operator's network planning, each VTN is allocated with a set of dedicated bandwidth resources using either virtual sub-interface or Flexible Ethernet (FlexE) interface mechanism. All the VTNs share the same IGP instance, while the links belonging to different VTNs are assigned with different link administrative groups (i.e. color). In a VTN, Ma, et al. Expires April 27, 2022 [Page 5] Internet-Draft IETF Network Slice Deployment October 2021 each link is assigned with an SR-MPLS Adj-SID to identify the sub- interface or FlexE interface used for packet forwarding. Multiple VPNs (EVPN, L3VPN and L2VPN) belonging to the one of the three major service types are mapped to the corresponding VTN. For example, the VTN created for the enterprise private line services is used to support the VPNs of a group of enterprise customers. The VPN traffic mapped to a VTN is steered into the set of virtual sub- interfaces or FlexE interfaces allocated to the VTN based on the corresponding SR-MPLS Adj-SIDs. A centralized network controller is responsible for the management of the VTN and the VPNs. This includes the topology and resource planning of VTN, the VTN creation, the mapping of VPN services to the VTN, and the computation of SRv6 TE paths based on the service constraints together with the topology and resource attributes of the VTN. The controller also collects the traffic statistics and performance information of the VTNs and the VPN services to enable the network slice services visualization and ensure the service SLAs are always met. +-------------------+ Centralized | Network Controller| Control & Management +-------------------+ /\ || \/ ________________________ VPN-1 o----/ o----o----o----o----o /----o VPN-2 o----/ / / / /----o VTN-1 VPN-3 o----/ o----o----o----o----o /----o Mobile /_______________________/ ________________________ VPN-4 o----/ o----o----o----o----o /----o VPN-5 o----/ / / / /----o VTN-2 VPN-6 o----/ o----o----o----o----o /----o Enterprise /_______________________/ __________________________ VPN-7 o----/ o----o----o----o----o /----o VPN-8 o----/ / / / /----o VTN-3 VPN-9 o----/ o----o----o----o----o /----o Residential /________________________/ Figure 2. IETF network slice deployment in CMHK Ma, et al. Expires April 27, 2022 [Page 6] Internet-Draft IETF Network Slice Deployment October 2021 4. Network Slice Deployment Considerations Based on the network slice deployment cases collected in section 2, this section describes some of the operators' considerations about network slice deployment. 4.1. Isolation Network slicing is introduced to operators' network to meet the connectivity and performance requirements of different services or customers. Since many services or customers are migrated from their own dedicated networks to network slices, it is expected that services or customers carried by a network slice will not be affected by any other traffic in the network, thus the resource, policy and security isolation from other services becomes a typical requirement. Operators have considered the usage of several forwarding plane mechanisms, such as FlexE interface or virtual sub-interfaces to allocate different set of network resources for the VTNs used for different services or customers. The services or customers which do not have specific requirement on resource or security isolation may be provisioned as separated VPNs, while these VPNs can be aggregated and mapped to a shared VTN with a set of aggregated network resources. 4.2. Topology and Connection Types According to the deployment scenarios of network slices, there can be different requirements on the topology and connection type of the network slices. When a network slice is provided for a particular service type or for a particular industry, the network slice usually covers a network scope similar to the scope of the physical network, and there are usually a large number of end points attached to the network slice, which requires meshed multipoint-to-multipoint connectivity between them. When a network slice is provided for a specific private line service customer, the network slice could have a customized topology covering a portion of the physical network, and usually has a small number of end points attached, in this case the network slice may be expressed as a set of point-to-point connections. The suitable mechanisms to define the topology of the VTN and build the connectivity needed by network slice service streams. For example, the administrative groups (i.e. color) can be used by a centralized controller to specify the topology of a VTN and compute the constraint paths for network slice services in the VTN. The Distributed control plane based mechanism for topology definition and Ma, et al. Expires April 27, 2022 [Page 7] Internet-Draft IETF Network Slice Deployment October 2021 the constraint path computation may be used for network slices which require meshed connectivity between a large number of end points. 4.3. Scalability As shown in several IETF network slice deployments, the number of VTNs at the initial stage can be small (e.g. less than 10). While there are also cases in which hundreds of network slices are needed for industrial and premium private line customers. It is expected that the number of VTNs required in the future could be at the hundreds or even thousands level. Thus the scalability considerations and optimization mechanisms as described in [I-D.dong-teas-enhanced-vpn-vtn-scalability] need to be considered to allow the deployment of a larger number of network slices in the network in future. 4.3.1. Data Plane Scalability The current deployment of network slices are mainly based on SR-MPLS or SRv6 data plane, with which each VTN is allocated with a separate group of SR SIDs, and the SIDs are associated with a group of dedicated network resources [I-D.ietf-spring-resource-aware-segments]. This provides a practical approach to deliver IETF network slices to meet the requirements in the early stage. While with the number of the required VTNs increases, the increasing amount of SR SIDs will bring challenges both to the forwarding tables and to the network management and operation. It is expected that the mechanisms with dedicated VTN-ID encapsulation as defined in [I-D.dong-6man-enhanced-vpn-vtn-id] could help to reduce the number of SR SIDs needed, and simplify the large scale network slice provisioning and management. 4.4. Automation The centralized network controller plays an important role in the life cycle management of network slices. With the number of network slices increases, it is necessary that the planning, creation, monitoring and the optimization of IETF network slices can be automated to reduce the burden in the network slice management and operation. For example, in a network where multiple IETF network slices are deployed, when the bandwidth utilization of one VTN reaches a specific threshold, there are two possible approaches for the VTN capacity expansion. The first approach is to expand the capacity of the physical network, which usually can take a long time. The second approach is to adjust the resource allocation of different VTNs based on the utilization ratio. The network controller can provide the Ma, et al. Expires April 27, 2022 [Page 8] Internet-Draft IETF Network Slice Deployment October 2021 monitoring and visualization of the resource utilization of the VTNs and VPNs, and gives recommendations about the optimal resource adjustment strategy to the network operator. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations TBD 7. Contributors Terence Ho Email: terenceho@hk.chinamobile.com Jimmy Tu Email: jimmytu@hk.chinamobile.com Jonathan Chung Email: jonathanchung@hk.chinamobile.com Kristy Li Email: kristyli@hk.chinamobile.com Tommy Zou: Email:tommyzou@hk.chinamobile.com Zhenbin Li Email: lizhenbin@huawei.com Zhibo Hu Email: huzhibo@huawei.com 8. Acknowledgements The authors would like to thank XXX for his valuable comments. 9. References Ma, et al. Expires April 27, 2022 [Page 9] Internet-Draft IETF Network Slice Deployment October 2021 9.1. Normative References [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) Services", draft-ietf-teas-enhanced-vpn-08 (work in progress), July 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [I-D.dong-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network Identifier in IPv6 Extension Header", draft-dong-6man-enhanced-vpn-vtn-id-05 (work in progress), September 2021. [I-D.dong-teas-enhanced-vpn-vtn-scalability] Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., Mishra, G., and F. Qin, "Scalability Considerations for Enhanced VPN (VPN+)", draft-dong-teas-enhanced-vpn-vtn- scalability-03 (work in progress), July 2021. [I-D.ietf-spring-resource-aware-segments] Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Z., and F. Clad, "Introducing Resource Awareness to SR Segments", draft-ietf-spring-resource-aware-segments-03 (work in progress), July 2021. [I-D.ietf-spring-sr-for-enhanced-vpn] Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Z., and F. Clad, "Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- enhanced-vpn-01 (work in progress), July 2021. [I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", draft-ietf-teas-ietf- network-slices-04 (work in progress), August 2021. Ma, et al. Expires April 27, 2022 [Page 10] Internet-Draft IETF Network Slice Deployment October 2021 Authors' Addresses Yusong Ma China Telecom Ningxia Email: mayusong.nx@chinatelecom.cn Rui Luo China Telecom Ningxia Email: luorui.nx@chinatelecom.cn Alex Chan China Mobile Hong Kong Email: alexckchan@hk.chinamobile.com Ben Suen China Mobile Hong Kong Email: bensuen@hk.chinamobile.com Jie Dong Huawei Technologies Email: jie.dong@huawei.com Ma, et al. Expires April 27, 2022 [Page 11]