Internet-Draft E2E IETF Network Slicing October 2021
Li, et al. Expires 28 April 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-teas-e2e-ietf-network-slicing-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Li
Huawei Technologies
J. Dong
Huawei Technologies
R. Pang
China Unicom
Y. Zhu
China Telecom

Framework for End-to-End IETF Network Slicing

Abstract

Network slicing can be used to meet the connectivity and performance requirement of different services or customers in a shared network. 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 major types of network segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). And in the transport network, the IETF network slice may span multiple network domains.

In order to facilitate the mapping between network slices in different network segments and network domains, it is beneficial to carry the identifiers of the 5G end-to-end network slice, the multi-domain IETF network slice together with the intra-domain network slice identifier in the data packet.

This document describes the framework of end-to-end IETF network slicing, and introduces the identifiers for 5G end-to-end network slice and the multi-domain IETF network slice in the data packet. The roles of the different identifiers in packet forwarding is also described. The network slice identifiers can be instantiated with different data planes.

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 28 April 2022.

Table of Contents

1. Introduction

[I-D.ietf-teas-ietf-network-slices] introduce the concept and the characteristics of IETF network slice, and describes a general framework for IETF network slice management and operation.

[I-D.ietf-teas-enhanced-vpn] describes the framework and the candidate component technologies for providing enhanced VPN (VPN+) services based on existing VPN and Traffic Engineering (TE) technologies with enhanced characteristics that specific services require above traditional VPNs. It also introduces the concept of Virtual Transport Network (VTN). A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical 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. Enhanced VPN (VPN+) and VTN can be used for the realization of IETF network slices.

[I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the scalability considerations in the control plane and data plane to enable VPN+ services, and proposed several suggestions to improve the scalability of VTN. In the control plane, It proposes the approach of decoupling the topology and resource attributes of VTN, so that multiple VTNs may share the same topology and the result of topology based path computation. In the data plane, it proposes to carry a VTN-ID of a network domain in the data packet to determine the set of resources reserved for the corresponding VTN.

An IETF network slice may span multiple network domains. Further in the context of 5G, there can be end-to-end network slices which consists of three major types of network segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). In order to facilitate the mapping between network slices in different network segments and network domains, it may be beneficial to also carry the identifiers of the 5G end-to-end network slice, the multi-domain IETF network slice together with the intra-domain network slice identifier in the data packet.

This document describes the scenarios of end-to-end network slicing, and the framework of network slice mapping between different network segments and network domains. Then multiple network slice related identifiers are defined to covers different network scopes. These network slice identifiers can be instantiated using different data planes, such as MPLS and IPv6.

2. Framework


    /----\        /----\         /----\          /----\         /----\
   /      \     //      \\     //      \\      //      \\      /      \
  |  RAN   |---|   TN-1   |---|   TN-2   |----|   TN-3   |----|  Core  |
   \      /     \\      //     \\      //      \\      //      \      /
    \----/        \----/         \----/          \----/         \----/

    S-NSSAI
  o--------------------------------------------------------------------o
             IETF Network Slice (VPN+)
           o--------------------------------------------------o
                Global VTN
              o===========================================o
                Local VTN-1   Local VTN-2      Local VTN-3
              o************o o************o   o***********o

Figure 1. 5G end-to-end network slicing scenario

One typical scenario of 5G end-to-end network slicing is shown in figure 1. The 5G end-to-end network slice is identified by the S-NSSAI (Single Network Slice Selection Assistance Information). In the transport network segment, the 5G network slice is mapped to an IETF network slice, which can be realized with a multi-domain VPN+ service. In the underlay network, the multi-domain VPN+ service is supported by a multi-domain VTN, which is comprised by multiple intra-domain VTNs in different domains. In each domain, a local VTN-ID is carried in the packet to identify the set of network resource reserved for the VTN in the corresponding domain.

In order to concatenate multiple local VTNs into a multi-domain VTN, the global VTN-ID can be carried in the packet, which is used by the network domain border routers to map to the local VTN-IDs in each domain. And in order to facilitate the network slice mapping between RAN, Core network and transport network, the S-NSSAI may be carried in the packet sent to the transport network, which can be used by the transport network to map the 5G end-to-end network slice to the corresponding IETF network slice.

According to the above end-to-end network slicing scenario, there can be three network slice related identifiers:

For the above network slice identifiers, the local VTN-ID is mandatory, the Global VTN-ID and the 5G S-NSSAI are optional. The existence of the Global VTN-ID depends on whether the VTN spans multiple network domains in the transport network. The existence of the 5G S-NSSAI depends on whether an IETF network slice is used as part of the 5G end-to-end network slice.

3. Requirements on E2E IETF Network Slicing

This section lists the requirements on E2E IETF network slicing.

3.1. Data Plane

To facilitate the mapping between 5G end-to-end network slice and IETF network slice, and the mapping between multi-domain IETF network slice and the intra-domain IETF network slice, different network slice related identifiers (e.g. S-NSSAI, Global VTN-ID, local VTN-ID) needs to be carried in the data packet.

3.2. Management Plane/Control Plane

For multi-domain IETF network slice, a centralized IETF network slice controller is responsible for the allocation of the Global VTN-ID and the Local VTN-ID, and the provisioning of the mapping relationship of the Global VTN-ID and the Local VTN-IDs to the network edge nodes in different network domains.

For 5G end-to-end network slice, the edge node of transport network can derive the S-NSSAI from the packet sent by the RAN or Core network, and encapsulate it an outer packet header or tunnel information when traversing the transport network. The controller needs to be responsible for creating the mapping relationship and provisioning it to the edge nodes of the transport network.

4. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

5. Security Considerations

TBD

6. Acknowledgements

TBD

7. References

7.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", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-08, , <https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-vpn-08.txt>.
[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", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-04, , <https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-04.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

7.2. Informative References

[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+)", Work in Progress, Internet-Draft, draft-dong-teas-enhanced-vpn-vtn-scalability-03, , <https://www.ietf.org/archive/id/draft-dong-teas-enhanced-vpn-vtn-scalability-03.txt>.

Authors' Addresses

Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Ran Pang
China Unicom
Yongqing Zhu
China Telecom