Network Working Group T. Miyasaka Internet-Draft KDDI Research Intended status: Informational K. Kumaki Expires: December 28, 2018 T. Niwa KDDI June 26, 2018 Analysis and Problem Statements for Interworking between 5G Network Slicing and Transport Network draft-mink-5g-ns-transport-ps-00 Abstract This document describes problem statements for realizing an end-to- end network slicing that is expected to provide service-oriented communications between users and applications. 3GPP introduced the network slicing concept in the 5G architecture (3GPP Release 15), however, it mainly focuses on mobile access and core domains. In order to reap the benefit of the concept, a network slicing needs to be designed across multiple domains of the network including non-3GPP parts. This document analyzes the current 3GPP 5G network slicing architecture and summarizes problem statements for the interworking between the 5G network slicing and the transport network. 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 December 28, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Miyasaka, et al. Expires December 28, 2018 [Page 1] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 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 1.1. Scope of this document . . . . . . . . . . . . . . . . . 3 2. 5G Network Slicing and Transport Network . . . . . . . . . . 5 2.1. 5G Network Slicing . . . . . . . . . . . . . . . . . . . 5 2.2. Transport Network for End-to-End 5G Communication . . . . 6 2.2.1. Transport Network inside 5G System . . . . . . . . . 6 2.2.2. Transport Network outside 5G System . . . . . . . . . 6 2.2.3. Management and Orchestration of 5G Network Slicing . 7 3. General Procedure for Interworking between 5G Network Slicing and Transport Network . . . . . . . . . . . . . . . . . . . . 7 4. Analysis on Interworking . . . . . . . . . . . . . . . . . . 10 4.1. Analysis Assumption . . . . . . . . . . . . . . . . . . . 10 4.2. Analysis inside 5G Core Network . . . . . . . . . . . . . 11 4.3. Analysis outside 5G Core Network . . . . . . . . . . . . 13 5. Problem Statement Summary . . . . . . . . . . . . . . . . . . 14 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Consideration . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 10. Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction An End-to-End(E2E) network slicing is expected to cater to much greater diversity of requirements for wide variety of services such as V2X services and factory automation. Here, the E2E means that a network slicing penetrates all network domains: mobile networks, transport networks and so forth. Network operators anticipate that it is possible to tailor the network to fit for service-oriented demands in a timely and cost-effective way, which in turn reduces OPEX and CAPEX. 3GPP is leading a network slicing concept in the 5G system (3GPP Release 15). The 3GPP network slicing is defined as a logical network that provides specific network capabilities and network Miyasaka, et al. Expires December 28, 2018 [Page 2] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 characteristics. However, it covers a limited domains and mainly focuses on an isolation for the 5G network functions. In order to achieve the goal, the network slicing needs to be designed from the E2E perspectives, not only 3GPP but also non-3GPP including transport networks. The way to map transport networks to the 5G system for a network slicing can be classified into two parts: inside and outside 5G system. Inside 5G system, network connections between UE, RAN, UPF and DN can be identified as network slice with one or more QoS Flow rules, and thus its underlying transport network should also be aware of the network slice. Outside 5G system, the E2E network slicing shall concatenate the network slicing whthin 5G systems with that of the following transport networks. To this end, a method to stitch user plane traffic to/from UPF and logical tunnels in transport networks (e.g. MPLS-TE) is required. Therefore, in terms of the E2E network slicing, the transport network shall accommodate to the 5G system. This document analyzes the current 5G network slicing architecture and summarizes problem statements for the interworking between the 5G network slicing and the transport network. 1.1. Scope of this document The scope of this document is to analyze an interworking between the 5G network slicing and the transport network and summarize problem statements for the interworking. Figure 1 shows an E2E communication between UE and CP(Content Provider Server) on 5G network slicing environment. We define each term used in the scope with Figure 1 as follows. Miyasaka, et al. Expires December 28, 2018 [Page 3] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 + - - - - - - - - - - - - - - - - - - + | Network Slice Instance(NS1) | +--+ +---+ +---+ +---+ |UE+--|-+RAN| |UPF|----------|DN | | +--+ +-|-+ +-|-+ +-|-+ + - + - - - - - - -+- - - - - - - + - + | | | + - - + - - - - - - -|- - + + - - + - - - - - - - - - + | | | | | | | | +----+ | | +----+ | | | R2 | | | | | | R6 | | | +----+ | | +----+ | | / \ | | | | / \ | +--|-+/ \+--|-+ +--|-+/ \+----+ +--+ | | R1 | | R4 | | | | R5 | | R8 |--+--|CP| +--|-+\ /+--|-+ +--|-+\ /+----+ +--+ | | \ / | | | | \ / | | +----+ | | +----+ | | | R3 | | | | | | R7 | | | +----+ | | +----+ | | Transport | | | | Transport | | Network | | Network | | Inside 5GC | | | | Outside 5GC | + - - + - - - - - - -|- - + + - - + - - - - - - - - - + | | | + - + - - - - - - -+- - - - - - - + - + +--+ +-|-+ +-|-+ +-|-+ |UE+--|-+RAN| |UPF|----------|DN | | +--+ +---+ +---+ +---+ | Network Slice Instance(NS2) | + - - - - - - - - - - - - - - - - - - + Figure 1: E2E communication between UE and CP o Network slice instance The network slice instance is defined as "A set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice" in [TS.23.501-3GPP]. o Transport network The definition of the transport network in this document is a network which provides a network connectivity to the 5G network functions such as UPF. The scope of the the transport network in this document is limited to layer-3 network, thus IPv4 and IPv6. This is because 3GPP adopted IPv4/IPv6 as a transport network of the 5G user plane. Miyasaka, et al. Expires December 28, 2018 [Page 4] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 There are two different transport networks in Figure 1: the transport network inside 5G core network consists of R1, R2, R3, and R4 and the transport network outside 5G core network consists of R5, R6, R7, and R8. Both inside and outside networks are within the scope of this document. o Traffic engineering The definition of traffic engineering in this document is to control the traffic path of IPv4/IPv6 packet in order to fulfill each network slice instance's requirements. (e.g. bandwidth and latency) For example, there are two network slice instance in Figure 1: NS1 and NS2. Suppose NS1 provides latency sensitive service such as V2X (in this case, UE is an automotive vehicle and CP is a control/ monitoring server operated by a car vendor), an operator needs to perform traffic engineering in transport network to select a path that total latency between UE and CP is minimum. If one-way latency is measured as follows, o R1->R2->R4 : 1msec o R1->R3->R4 : 2msec o R5->R6->R8 : 9msec o R5->R7->R8 : 6msec the traffic path of NS1 in the transport network inside 5G core network is R1->R2->R4 and the traffic path of NS1 in the transport network outside 5G core network is R5->R7->R8. Therefore, the E2E communication from UE to CP is "UE->RAN->R1->R2->R4->UPF->DN->R5->R7->R8->CP". o Interworking The definition of an interworking in this document is that the network slice instance and the transport network collaborate in order to perform the traffic engineering which fulfills requirements of the network slice instance. 2. 5G Network Slicing and Transport Network 2.1. 5G Network Slicing The 5G system architecture introduced the following key features: Miyasaka, et al. Expires December 28, 2018 [Page 5] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 o Separate the user plane (UP) functions from the control plane (CP) functions, allowing independent scalability and flexible deployments. o Modularize the network function to enable the flexible and efficient network slicing. Thanks to the features, the deployed network slicing is comprised of a network slice instance that indicates a set of network functions(e.g. UPF) and the required resources. S-NSSAI(Single Network Slice Selection Assistance Information) is used to identify a network slice and assists the selection of a particular network slice instance corresponding to the slice. A network slice instance can be associated with one or more S-NSSAIs, and an S-NSSAI can be associated with one or more network slice instances. NSI ID(Network Slice Instance Identifier) may identify a network slice instance corresponding to a certain S-NSSAI. 2.2. Transport Network for End-to-End 5G Communication An E2E network slicing needs a cross-domain technology that covers 3GPP, transport networks and others (e.g. optical networks, data center networks). For the 5G system, the transport networks are classifled two parts; inside and outside 5G systems. 2.2.1. Transport Network inside 5G System A PDU session belongs to one and only one specific network slice instance in the 5G system. The 5G QoS model is based on the QoS Flows that is the finest granularity of QoS differentiation in the PDU session. The QoS Flow is characterised by QoS profiles for RAN, QoS rules for UE and PDR(Packet Detection Rule) for UPF. DSCP can be optinally utilized to support the QoS Flow, however, the QoS Flow does not correspond to the network slice one by one. Therefore, a network slice can not be identified from the transport network perspective. Regarding the transport connectivity between different 3GPP nodes in the network slice instance, transport networks shall take 3GPP link requirements (e.g. NSI ID, topology, QoS parameters, etc.) from the network slice into account. 2.2.2. Transport Network outside 5G System The S-NSSAI instructs which a PDU session is associated with a DN and a network slice instance. In the current 3GPP specification, transport networks cannot recognize the S-NSSAI or the NSI ID from UP directly and thus cannot map the network slicing in the 3GPP system to that of transport networks. Miyasaka, et al. Expires December 28, 2018 [Page 6] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 2.2.3. Management and Orchestration of 5G Network Slicing The management and orchestration of the 5G network slicing is studied in 3GPP SA5. This study includes creation, modification, and elimination of the network slice instance from the 3GPP management system. In this 3GPP management system, the coordination with the management system of non-3GPP parts also has been taken into account and the transport network management is included in the scope of the management system. Figure 2 shows a concept of the 3GPP management system and a coordination with the transport network management system, which is described in section 4.7 of [TS.28.530-3GPP] However, the detailed analysis for the coordination with the transport network management system is not studied. +------------------------+ | 3GPP Management System | +------------------------+ /|\ | | \|/ +-------------------+ | Transport Network | | Management System | +-------------------+ /|\ /|\ /|\ | | | +----------+ | +------------+ | | | \|/ \|/ \|/ +---+ ---- +---+ ---- +---+ ---- +----------+ |RAN|----( TN )----|UPF|----( TN )----|DN |----( TN )----|App Server| +---+ ---- +---+ ---- +---+ ---- +----------+ * TN = Transport Network Figure 2: E2E communication between UE and CP 3. General Procedure for Interworking between 5G Network Slicing and Transport Network Figure 3 illustrates a general procedure for an interworking between 5G Network Slicing and Transport Network and we use following terminology in this figure Miyasaka, et al. Expires December 28, 2018 [Page 7] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 o 5G User Plane Function : A function which is related to 5G user plane. RAN, UPF, and DN are current 5G User Plane Fucntion defined by 3GPP. o NS Forwarding Policy DB : A database which maintains a forwarding policy which needs to be applied to each NS instance. o TE Indicator : An indicator which instructs an adequate forwarding policy to router for the NS instance and encoded in an incoming packet. MPLS label and SRv6 SRH are an example for TE indicator. o 5G IP Packet : An IPv4/IPv6 packet sents from 5G network function. The 5G network function performs the following procedures for an interworking. 1. Recognize the NSI ID of an outgoing packet at 5G User Plane Function 2. Decide an adequate forwarding policy which is performed on this network slice instance by inquiring to the NS Forwarding Policy DB. 3. Encapsulate an outgoing 5G IP Packet with an adequate TE indicator for the forwarding policy of a network slice instance 4. Send the encapsulated packet to the transport network Miyasaka, et al. Expires December 28, 2018 [Page 8] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 5G Network Function +-----------------+ |+---------------+| || NS Forwarding || || Policy DB || |+---------------+| | /|\ | | | | | | | | | | | | \|/ | | +-------------+ | | |5G User Plane| | | | Function | | +------------+ +------------+ | +-------------+ | |TE Indicator| |TE Indicator| | | | +------------+ Router +------------+ | \|/ | |5G IP Packet| +--------------+ |5G IP Packet| | +----------+ | +------------+ | +----------+ | +------------+ | |Data Plane|---+----------------+>|Data Plane|-|--------------> | +----------+ | | +----------+ | Next Router +-----------------+ +--------------+ Figure 3: Interworking Procedure Figure 4 shows an example of interworking procedure. In this example, the 5G network function uses MPLS-TE for traffic engineering in transport network and encapsulated with MPLS label which represents an adequate MPLS-TE tunnel which fulfills requirements of a network slice instance. The following list describes the detailed procedure in this example. 1. 5G Network Function recognizes that the NSI ID of the outgoing packet is 123 2. 5G Network Function resolves the required traffic engineering policy is the MPLS-TE tunnel 123 for the network slice instance 3. 5G Network Function encapsulated the outgoing 5G IP packet with MPLS label of 123 which is the outgoing label of the MPLS-TE tunnel 123 4. 5G Network Function sends the encapsulated packet to the transport network Miyasaka, et al. Expires December 28, 2018 [Page 9] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 5G Network Function +-------------------+ |+-----------------+| || NS Forwarding || || Policy DB || || || ||NSI ID:Policy || || 111:MPLS-TE || || tunnel 111|| || (HighBW) || || 123:MPLS-TE || || tunnel 123|| || (LowLatency)|| |+-----------------+| | /|\ | | | | | | | | | | | +-------------+ | +------------+ +------------+ | |5G User Plane| | | MPLS label | | MPLS label | | | Function | | | 123 | | 234 | | +-------------+ | |(tunnel 123)| |(tunnel 123)| | | | +------------+ Router +------------+ | \|/ | |5G IP Packet| +--------------+ |5G IP Packet| | +----------+ | +------------+ | +----------+ | +------------+ | |Data Plane|-----+----------------+>|Data Plane|-|--------------> | +----------+ | | +----------+ | Next Router +-------------------+ +--------------+ Figure 4: Example of Interworking Procedure 4. Analysis on Interworking This section describes an analysis on an interworking between the 5G network slicing and the transport network both outside and inside 5G core networks. 4.1. Analysis Assumption Figure 5 and the following list illustrates an assumption on the 5G network slicing for our analysis. Sharing of network function (UPF and DN) among different network slice instances is suggested in section 4.5 of [TS.28.530-3GPP]. o UE can connect to the multiple network slice instances. o RAN is a common network function to select adequate network slice instance's UPF. Miyasaka, et al. Expires December 28, 2018 [Page 10] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 o UPF may be shared between different network slice instances. The shared UPF has a common IP address/prefix for an endpoint. o DN may be shared between different network slice instances. The shared DN has a common IP address/prefix for an endpoint. + - - - - - - - - - - - - - - - - + | NS1 | +-----+ +-----+ +---+ +-----|---| UPF |-----| UPF |-----| |-| | +-----+ +-----+ | | | + - - - - - - - - - - - - - |DN | + | + - - - - - - - - - - - - - | | + | | NS2 | | | +--+ +-+-+ +-----+ | | |UE+----+RAN+---|---------------| |-----| |-| +--+ +-+-+ | | +---+ | + - - - - - - - | | - - - - - + | + - - - - - - - | UPF | - - - - - + | | NS3 | | | | +-----+ | | +---+ +-----|---| UPF |-----| |-----|DN |-| +-----+ +-----+ +---+ + - - - - - - - - - - - - - - - - + Figure 5: Analysis Assumption 4.2. Analysis inside 5G Core Network This section describes an analysis on an interworking between the 5G network slicing and the transport network inside 5G core network based on the procedure described in Section 3. The problem statement in this analysis is emphasized as [PS-Interwork-X]. [PS-Interwork-1]: 5G Network Function cannot recognize the NSI ID of an established PDU session. Therefore, statically configured Policy Based Routing(PBR) based traffic engineering is required. 5G Network Function cannot recognize the NSI ID of an established PDU session due to the following two reasons. 1. From the user plane perspective, the NSI ID is not encoded in any header including GTP-U extension header. New PDU Session Container GTP-U extension header is introduced for the 5G user plane in [TS.29.281-3GPP], but the extension header only includes QFI information. Miyasaka, et al. Expires December 28, 2018 [Page 11] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 2. From the control plane perspective, the NSI ID is not signaled to the user plane function such as UPF. PFCP is extended for the 5G control plane protocol in [TS.29.244-3GPP], however, the NSI ID is not signaled to the user plane function. For this problem statement, we have to statically configure a policy based routing(PBR) based traffic engineering in the 5G network function. In Figure 6, an example for statically configured PBR in UPFb and UPFd is described in Figure 7. + - - - - - - - - - - - - - - - - - - - + | NS1 (NSI ID=1) | +------+ +------+ +-----+ +-----|-----| UPFa |-----| UPFb |-----| DNa | | | +------+ +------+ +-----+ | + - - - - - - - - - - - - - - - - - - - + | + - - - - - - - - - - - - - - - - - - - + | | NS2 (NSI ID=2) | +--+ +-+-+ +------+ +------+ +-----+ |UE+----+RAN+---|-----| |-----| |-----| DNb | | +--+ +---+ | | | | +-----+ | + - - | |- - -| | - - - - - - + | + - - | UPFc |- - -| UPFd | - - - - - - + | | | | | | | | | | | | +-----+ +-----|-----| |-----| |-----| DNc | | +------+ +------+ +-----+ | NS3 (NSI ID=3) | + - - - - - - - - - - - - - - - - - - - + Figure 6: Example for PBR based traffic engineering In case of UPFd in Figure 6, statically configured PBR needs to include a source IP address classification because a destination IP address of next UPF (UPFc) is common as UPFc is shared between NS2 and NS3 as described in Section 4.1. Miyasaka, et al. Expires December 28, 2018 [Page 12] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 +------------------------------------------------------------+ | Routing Table for UPFb | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| | IF: Subsequent Node IP address is | | THEN: Nexthop is (for NS1) | | | | IF: Subsequent Node IP address is | | THEN: Nexthop is (for NS2) | +------------------------------------------------------------+ +------------------------------------------------------------+ |Routing Table for UPFd | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| | IF: Subsequent Node IP address is | | AND Previous Node IP address is | | THEN: Nexthop is (for NS2) | | | | IF: Subsequent Node IP address is | | THEN: Nexthop is (for NS2) | | | | IF: Subsequent Node IP address is | | AND Previous Node IP address is | | THEN: Nexthop is (for NS3) | | | | IF: Subsequent Node IP address is | | THEN: Nexthop is (for NS3) | +------------------------------------------------------------+ Figure 7: PBR based traffic engineering [PS-Interwork-2]: 5G network function cannot classify a network slice instance by using PBR If both previous node and subsequent node are shared between different network slice instances. For example, a routing table for UPFc in Figure 6 toward RAN node cannot classify NS2 and NS3, because previous node is UPFb which is shared NS2 and NS3 and the subsequent node is RAN which is a common network function among network slice instances as described in Section 4.1. Therefore, the source IP address and the destination IP address are common among NS2 and NS3, so we cannot create an adequate PBR rule for each network slice instance. 4.3. Analysis outside 5G Core Network TBD Miyasaka, et al. Expires December 28, 2018 [Page 13] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 5. Problem Statement Summary The following list summarizes problem statements for the interworking inside 5G core network. [PS-Interwork-1]: 5G Network Function cannot recognize the NSI ID of the established PDU session. Therefore, statically configured Policy Based Routing(PBR) based traffic engineering is required [PS-Interwork-2]: 5G network function cannot classify the network slice instance by using PBR If both previous node and subsequent node are shared between different network slice instances. The following list summarizes problem statements for the interworking outside 5G core network. [PS-Interwork-3]: TBD 6. Conclusion This document summarizes problem statements for an interworking between 5G network slicing and transport network. Our analysis shows the traffic engineering for a 5G network slicing is achieved by using a policy based routing. However, if the 5G network function (e.g., UPF) is shared among different network slice instances, there is a case that the traffic engineering is not achieved because the 5G network function cannot distinguish a network slice instance [PS- Interwork-2]. This issue is inevitable under the current 5G specification and we need to give the feedback to 3GPP to solve the issue. From the IETF perspective, "transport network management system" is required from 3GPP SA5 WG as described in Section 2.2.3. This transport network management system needs to serve a transport network related request sent from a 3GPP management system, which means the transport network management system needs to provide API to the 3GPP management system to control the transport network from the 3GPP side. Therefore, IETF needs to collaborate with 3GPP, specifically for 3GPP SA5 WG, and examine if the current standardized technology and framework in the IETF activity fulfills requirements from 3GPP. Miyasaka, et al. Expires December 28, 2018 [Page 14] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 7. Security Consideration TBD 8. IANA Considerations This document does not require any action from IANA. 9. Acknowledgement The author would like to thank Takeshi Usui, Satoru Matsushima, Shunsuke Homma for their useful comments. 10. Informative References [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 (V15.1.0): System Architecture for 5G System; Stage 2", March 2018, . [TS.28.530-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 (V1.0.0): Telecommunication management; Management and orchestration of networks and network slicing; Concepts, use cases and requirements", June 2018, . [TS.29.244-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 (V15.1.0): Interface between the Control Plane and the User Plane Nodes; Stage 3", March 2018, . [TS.29.281-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 (V15.2.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", March 2018, . Authors' Addresses Miyasaka, et al. Expires December 28, 2018 [Page 15] Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018 Takuya Miyasaka KDDI Research 2-1-15, Ohara, Fujimino-shi Saitama 356-8502 JP Email: ta-miyasaka@kddi-research.jp Kenji Kumaki KDDI 3-22-7, Yoyogi, Shibuya-ku Tokyo 151-0053 JP Email: ke-kumaki@kddi.com Tomonobu Niwa KDDI 3-22-7, Yoyogi, Shibuya-ku Tokyo 151-0053 JP Email: to-niwa@kddi.com Miyasaka, et al. Expires December 28, 2018 [Page 16]