IETF Network Slice Deployment Status and Considerations

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. describes network slicing in the context of networks built from IETF technologies, and discusses the general framework of IETF network slices. describes the framework and candidate 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.

Service scenario: Multiple industrial services Resource partitioning: Virtual sub-interface with dedicated bandwidth Data Plane: SRv6 Control plane: SR Policy with link affinity

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

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.

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, 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.

Based on the network slice deployment cases collected in section 2, this section describes some of the operators' considerations about network slice deployment.

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.

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 the constraint path computation may be used for network slices which require meshed connectivity between a large number of end points.

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 need to be considered to allow the deployment of a larger number of network slices in the network in future.

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 . 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 could help to reduce the number of SR SIDs needed, and simplify the large scale network slice provisioning and management.

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 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.

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

TBD

The authors would like to thank XXX for his valuable comments.