Individual R. Rokui Internet-Draft Nokia Intended status: Informational S. Homma Expires: May 6, 2021 NTT X. de Foy InterDigital Inc. LM. Contreras Telefonica P. Eardley BT K. Makhijani Futurewei Networks H. Flinck Nokia R. Schatzmayr Deutsche Telekom A. Tizghadam TELUS Communications Inc C. Janz H. Yu Huawei Canada November 2, 2020 IETF Network Slice for 5G and its characteristics draft-rokui-5g-ietf-network-slice-00 Abstract 5G Network slicing is an approach to provide separate independent end-to-end logical network from User Equipment (UE) to various mobile applications where each network slice has its own Service Level Agreement (SLA) and Objectives (SLO) requirements. Each end-to-end network slice consists of a multitude of contexts across RAN, Core and transport domains each with its own controller. To provide automation, assurance and optimization of the 5G the network slices, a 5G E2E network slice orchestrator is needed which interacts with controllers in RAN, Core and Transport network domains. The interfaces between the 5G E2E network slice orchestrator and RAN and Core controllers are defined in various 3GPP technical specifications. However, 3GPP has not defined a similar interface for transport network. The aim of this document is to describe E2E network slicing and its relation to "IETF network slice" for 5G use-case. It also provides an information model for control and mangement of IETF network slices for 5G. Rokui, et al. Expires May 6, 2021 [Page 1] Internet-Draft draft-rokui-5G-network-slice November 2020 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 May 6, 2021. Copyright Notice Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 2. Architecture of a 5G end-to-end network slice . . . . . . . . 5 3. Typical flow for fulfillment of a 5G E2E network slice . . . 8 4. Definition of 5G IETF Network Slice . . . . . . . . . . . . . 11 4.1. 5G IETF Network Slices in Distributed RAN deployment . . 12 4.2. 5G IETF Network Slices in Centralized RAN deployment . . 13 4.3. 5G IETF Network Slices in Cloud RAN (C-RAN) . . . . . . . 13 4.4. 5G IETF Network Slice as a set of Connection Groups . . . 14 5. IETF Network Slice Controller NBI for 5G . . . . . . . . . . 16 5.1. Relationship between 5G IETF Network Slice NBI and various IETF data models . . . . . . . . . . . . . . . . 17 6. 5G IETF Network Slice NBI Information Model . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 Rokui, et al. Expires May 6, 2021 [Page 2] Internet-Draft draft-rokui-5G-network-slice November 2020 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Informative References . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Network slicing offers network operators a mechanism to allocate dedicated infrastructure, resources and services from a shared operator's network to a customer for specific use-case. As discussed in draft [I-D.nsdt-teas-ietf-network-slice-definition], there are a number of use-cases benefiting from network slicing including: o 5G network slicing (See [TS.23.501-3GPP]) o Network wholesale services o Network sharing among operators o NFV connectivity and Data Center Interconnect It is important to note that the concept of network slicing is not only limited to 5G but other use-cases can also benefit from it as shown above. However, the 5G use case is one of the important use cases for network slicing. This memo will discuss the 5G use-case in more details. In specific, 5G network slicing is a mechanism which a mobile network operator can use to allocate dedicated infrastructures, resources and services from a shared mobile and transport network to a 5G customer for specific 5G use-case. A 5G network slice is inherently an E2E concept and is composed of multiple logical independent networks in a common operator's network from a user equipment to various 5G applications. In particular, 5G network slicing receives attention due to factors such as diversity of services and devices in 5G each with its own SLA requirements. Each 5G E2E network slice consists of multiple 5G RAN, 5G Core and transport network domains each with its own controller (See [TS.28.531-3GPP]. To enable automation, assurance and optimization of 5G network slices, an E2E network slice orchestrator is needed which interacts with 5G RAN, 5G Core and Transport network controllers. The interfaces between the E2E network slice orchestrator and RAN and Core slice controllers are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface towards the transport network. Draft [I-D.wd-teas-transport-slice-yang] addresses the object model of such interface for all network slice use-cases. However, for 5G network Rokui, et al. Expires May 6, 2021 [Page 3] Internet-Draft draft-rokui-5G-network-slice November 2020 slicing, the current model shall be augmented to address the specific characteristics of the 5G network slices. The aim of this document is to provide characteristics of 5G network slices and how it relares to "IETF network slice". It also provides the IETF network slice interface specifications and its information model to be used for automation, monitoring and optimization of IETF network slices for 5G. See [I-D.contreras-teas-slice-nbi]. 1.1. Definition of Terms Please refer to [I-D.nsdt-teas-ietf-network-slice-definition] and [I-D.homma-slice-provision-models] as well. Tenant: Also known as Customer. A network slice tenant is a person or group that rents and occupies an instance of the network slice from network provider. 5G End-to-end Network Slice: A logical end-to-end network provided by a 5G network slice provider that has the functionality and performance to support a specific 5G service. It spans multiple network domains (e.g. radio, transport and core) and in some cases more than one administrative domain. It may well support dynamic modification or it might be long-lasting i.e. only change on commercial timescales. 5G IETF Network Slice: We will use the term "5G IETF network slice" throughout this draft. It simply refers to IETF network slice define in [I-D.nsdt-teas-ietf-network-slice-definition] applicable to 5G. RAN Slice: Also known in 3GPP as RAN Sub-Slice or RAN Slice-Subnet. The context and personality created on RAN network functions to address the 5G radio portion of a 5G E2E network slice. Core Slice: Also known in 3GPP as Core Sub-Slice or Core Slice- Subnet. The context and personality created on Core network functions to address the 5G Core portion of a 5G E2E network slice. S-NSSAI: Single-Network Slice Selection Assistance Information, defined by 3GPP which is the identification of a 5G E2E Network Slice gNB: The radio portion of a 5G E2E network slice and in a distributed radio deployment (called Cloud-RAN), it incorporates two major modules; Central Unit (CU) and Distribute Unit (DU) Rokui, et al. Expires May 6, 2021 [Page 4] Internet-Draft draft-rokui-5G-network-slice November 2020 DU: Distributed Unit: This logical unit includes a subset of gNB real-time functions. Its operation is controlled by the CU. CU: Central Unit: It is a logical unit that includes the gNB non- realtime functions. UE: User Equipment such as vehicle infotainment unit, cell phone, IoT sensor and etc. RAN: Radio Access Network is the part of a mobile system that connects individual devices to other parts of a network through radio connections. It provides connection between user equipment (UE) and mobile core network. Transport Domain: Transport domain is a network domain implemented by the deployment of IETF network technologies. 2. Architecture of a 5G end-to-end network slice To demonstrate the concept of 5G E2E network slice and the role of various controllers, consider a typical 5G network shown in Figure 1 where a mobile network operator Y has two customers C1 and C2. The boundaries of administrative domain of the operator includes RAN, transport, Core and mobile application domains. Customer C1 and C2 request to have one or more logical independent E2E networks from UEs (e.g. vehicle infotainment, mobile phone, IoT meters etc.) to the 5G application servers, each with its own distinct SLO. Each of these independent networks is called a 5G E2E network slice. Each E2E network slice comprised of three componets RAN slice, IETF network slice, and Core slice, respectively representing RAN, transport and core domain portions of the slice. Rokui, et al. Expires May 6, 2021 [Page 5] Internet-Draft draft-rokui-5G-network-slice November 2020 <---------------- 5G End to End Network Slice -----------------> <-- RAN --> <-- IETF Network --> <- Core -> <-- IETF Network --> Slice Slice 1 Slice Slice 2 ......... ................... ............ ................. : : : : : : : : : : : : : : : : NS1 ---------------------------------------------------------------- NS2 ================================================================ NS3 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : : : : : : : : NS4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : : : : : : : : : : : : : : : : :.......: :.................: :..........: :...............: RAN Transport Core Transport App Network Network 1 Network Network 2 Servers Legend: ----- NS1: 5G E2E NS 1 for customer C1, service type Infotainment ===== NS2: 5G E2E NS 2 for customer C1, service type Autonomous Driving +++++ NS3: 5G E2E NS 3 for customer C1, service type HD Map - - - NS4: 5G E2E NS 4 for customer C2, service type CCTV Figure 1: High level architecture of a 5G end-to-end network slice In Figure 1 mobile network operator Y has created four 5G E2E network slices, NS1, NS2, NS3 and NS4, each with its own RAN, Core and IETF network slices. To create a RAN slice, the RAN network function s such as eNB and gNB should be programmed to have a context for each 5G E2E network slice. This context means that the RAN network functions should allocate certain resources for each 5G E2E network slice they belong to such as air interface, various schedulers, policies and profiles to guarantee the SLO requirement for that specific network slice. By the same token, the Core slices will be created which means that the mobile network operator will create the context for each 5G E2E network slice on Core network functions. For each 5G E2E network slice NS1, NS2, NS3 and NS4, after creation of RAN and Core slices, they should be connected to each other and be connected to mobile application servers to form the 5G E2E network slice. As defined in [I-D.nsdt-teas-ietf-network-slice-definition], the set of connections are referred to "IETF Network Slices" and specifically for 5G they are referred to "5G IETF Network Slices". Rokui, et al. Expires May 6, 2021 [Page 6] Internet-Draft draft-rokui-5G-network-slice November 2020 Referring to Figure 1, for each 5G E2E network slice, the following 5G IETF network Slices are needed: o 5G IETF Network Slice 1: To connect RAN slice to Core slice in Transport Network 1 o 5G IETF Network Slice 2: To connect Core slice to Mobile Application Servers in Transport Network 2. This might be needed if the mobile application servers are connected to core network functions through a transport network. For example, if the Core slice, which is realized on VNFs, and mobile application servers are in the same data center, the 5G IETF Network Slice 2 is not needed. In this case the transport network 2 does not exist. Note that as we will see later in Section 4.1, Section 4.2 and Section 4.3, the number of "5G IETF network slices" might be more than two which depends on some factors such as RAN deployment: After creation of RAN, Core and 5G IETF network slices, they will be associated together to form a working 5G E2E network slice identified by an ID referred as to S-NSSAI. Please refer to [TS.23.501-3GPP] for more info on S-NSSAI. To support fully automated enablement and assurance of 5G E2E network slices, multiple controllers are needed to perform the life cycle of 5G E2E network slices in RAN, Core and Transport domains. As shown in Figure 2 each RAN, Core and Transport domain needs its own controller called RAN Slice Controller, Core Slice Controller and IETF Network Slice Controller. In addition, an E2E network slice orchestrator is needed to provide coordination and control of network slices from an E2E perspective. In summary, a 5G E2E network slice will involve several domains, each with its own controller; 5G RAN, 5G Core and transport domains need to be coordinated in order to deliver an E2E mobile service. Note that in this context a service is not an IP/MPLS service but rather customer facing services such as CCTV service, eMBB service, Infotainment service and so on. Rokui, et al. Expires May 6, 2021 [Page 7] Internet-Draft draft-rokui-5G-network-slice November 2020 |---------------------------------------------------------| | E2E Network Slice Orchestrator | |---------------------------------------------------------| |----------------| |-------------------| |----------------| | RAN Slice | | IETF Network | | Core Slice | | Controller | | Slice Controller | | Controller | |----------------| |-------------------| |----------------| .......... ................... ........... ................ : : : : : : : : : : : : : : : : : RAN : : Transport : : Core : : Transport : Mobile : Network: : Network 1 : : Network : : Network 2 : App : : : : : : : : Servers : : : : : : : : :........: :.................: :.........: :..............: Figure 2: Various controllers for 5G end-to-end network slice 3. Typical flow for fulfillment of a 5G E2E network slice Figure 3 provides a typical flow across various controllers, orchestrator, NFVO and RAN/Transport/Core networks to achieve the automatic creation of a 5G E2E network slices such as NS1, NS2, NS3 or NS4 shown in Figure 1. Below are typical steps from the time a customer sends its request for a 5G E2E network slice creation to the operators network until the network slice is created and ready to be used by the customer. It is important to note that in practice some of these steps can be combined or re-ordered. 1. The customer C1 requests, from operator Y, the creation of a 5G E2E network slice NS1 for Infotainment service type and SLO of 10 [Mbps] 2. The 5G E2E network slice orchestrator receives this request and using its pre-defined network slice blueprints (a.k.a. network slice templates), creates a network slice profile (a.k.a. network slice instance) containing all the network functions in RAN and core which should be part of this E2E network slice. It then goes through decomposition of this profile and triggers various actions towards RAN, Core and transport domains. 3. A request for creation of 5G RAN slice will be sent to RAN Slice Controller. Rokui, et al. Expires May 6, 2021 [Page 8] Internet-Draft draft-rokui-5G-network-slice November 2020 4. If new instances of virtual RAN network functions are needed, the RAN Slice Controller triggers the creation of new VNFs in RAN (using for example ETSI interface Os-Ma-nfvo) 5. NFVO manages the life cycle of virtual RAN network functions 6. Since both physical and virtual RAN network functions which are part of 5G E2E network functions are known to the RAN slice controller, it triggers the creation of a RAN slice by programming 5G RAN network functions 7. Similary to previous step (3), a request for creation of a Core slice will be sent to the Core Slice Controller. 8. If new instances of virtual Core network functions are needed, the Core Slice controller triggers the creation of new 5G core VNFs (using for example ETSI interface Os-Ma-nfvo) and NFVO manages the life cycle of virtual Core network functions 9. Since both physical and virtual 5G Core network functions as components of 5G E2E network functions are known to the Core slice controller, it triggers the creation of Core slice by programming 5G Core network functions 10. In this step, the creation of various 5G IETF network slices will be triggered. Each 5G IETF network slice contains one or more connections between RAN network functions, Core network functions and 5G mobile applications. For example, connectivity between 5G RAN and 5G Core slices, connectivity between 5G RAN network functions (such as DU to CU) or connectivity between 5G core slice and mobile applications. Note that this step can be triggered by E2E network slice orchestrator, RAN slice controller, Core slice controller, or a combination of them. 11. [Optional] If the realization of a 5G IETF network slice involves creation of new VNFs (e.g. Firewall, security gateway etc.), 5G IETF network slice controller triggers the creation of those VNFs (using for example ETSI interface Os-Ma-nfvo) 12. Various 5G IETF network slices will be realized in transport network. Note that interface (10) is technology-agnostic whereas interface (12) is technology-specific 13. The E2E network slice orchestrator associates RAN slice, Core slice and 5G IETF network slices together to form a single 5G E2E network slice NS1 Rokui, et al. Expires May 6, 2021 [Page 9] Internet-Draft draft-rokui-5G-network-slice November 2020 14. At the end, when the E2E network slice is created, the E2E network slice orchestrator will allocate a unique network slice id (called S-NSSAI) and eventually, during the UE network attach, UEs will be informed about the existence of this newly created E2E network slice. UEs can request it using the 3GPP 5G signaling procedures. Note that the interfaces 3 and 7 between 5G E2E network slice orchestrator and RAN and Core slice controllers along with their information models are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface for transport network (i.e. interface 10). The aim of this document is to define specific attributes related to 5G network slices which will be used later to augment [I-D.wd-teas-transport-slice-yang]. |----------------------------------------------------| | Customer portal | |----------------------------------------------------| |(1) V |----------------------------------------------------| | Generate NS Profile (aka NSI) using NS Blueprints | 5G E2E | |(2) | Network Slice | V | Orchestrator | Decompose NS Profile and trigger various actions | |----------------------------------------------------| |(3) |(10) |(7) | |--------| | |------| | V | V V V | V --------------- | ----------------- | ---------------- | RAN | | | IETF | | | Core | Domain | Slice |-| | Network Slice | |-| Slice | Controllers | Controller | | Controller | | Controller | --------------- ----------------- ---------------- (6)| |(4) (12)| |(11) (8)| |(9) | | | |--------| | | | |-------------- | --------| | |------| | | | V V V | | | |----------| | | | | NFVO | | | | |----------| | | | | | .............. ................. | ................. : RAN : : IETF Network : | : Core : : Slice : : Slice : | : Slice : Rokui, et al. Expires May 6, 2021 [Page 10] Internet-Draft draft-rokui-5G-network-slice November 2020 :............: :...............: | :...............: .... | ................ | ........ | .......... | ..... 5G E2E : | | | | : Network Slice :... | ................ | ........ | .......... | ....: (13) | | | | (6)| (12)| (5)| |(9) V V V V |-----------------------------------------------------| | ,--------. ,-------------. ,--------. | Network of | / RAN \ / Transport \ / Core \ | Mobile | \ Network / \ Network / \ Network / | Operator "Y" | `--------' `-------------' `--------' | |-----------------------------------------------------| Legend: NS: 5G E2E Network Slice NSI: Network Slice Instance NFVO: NFV Orchestrator Figure 3: Typical flow for fulfillment of a 5G E2E network slice 4. Definition of 5G IETF Network Slice Referring to [I-D.nsdt-teas-ietf-network-slice-definition], the IETF network slice is define as follows: An IETF network slice is a logical network topology connecting a number of endpoints with a set of shared or dedicated network resources. These resources are used to satisfy specific Service Level Objectives (SLOs). The 5G IETF Network slice specification is technology-agnostic. Using the above-mentioned definition, the 5G IETF network slice is define as follows: 5G IETF network slices are sets of connections among the following network functions and mobile applications: o 5G RAN slice and 5G Core slice o 5G Core slice and mobile application server o Among 5G RAN network functions DU to CU o Among 5G RAN network functions RU to DU Rokui, et al. Expires May 6, 2021 [Page 11] Internet-Draft draft-rokui-5G-network-slice November 2020 In Section 4.1, Section 4.2 and Section 4.3, the details of various 5G IETF network slices for following RAN deployment will be provided: o Distributed RAN o Centralized RAN o Cloud RAN (C-RAN) 4.1. 5G IETF Network Slices in Distributed RAN deployment Distributed RAN is the most common deployment of 4G and 5G RAN networks whereas shown in Figure 4, the RAN network is connected to Core network using the transport network 1. Optionally the mobile applications can be also connected to the Core network using another transport network 2. In this case, a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but two 5G IETF network slices INS_1 and INS_2. INS_1 connects the RAN slice to Core slice and INS_2 connects Core slice to mobile application servers (if needed). <------------- 5G E2E Network Slice -------------> <--- RS --> <-- CS --> <--- INS_1 --> <--- INS_2 ---> .................. : RAN : : : ............. ............. : |----| |-----| : : : |------| : : |-----| : | RU | | BBU | : : Transport : | Core | : Transport : | App | : |----| |-----| : : Network 1 : |------| : Network 2 : |-----| : : :...........: :...........: :................: Legend INS: 5G IETF Network Slice RS: RAN Slice CS: Core Slice RU: Radio Unit BBU: BaseBand Unit App: Mobile Application Servers Figure 4: 5G IETF network slices in distributed RAN deployment Rokui, et al. Expires May 6, 2021 [Page 12] Internet-Draft draft-rokui-5G-network-slice November 2020 4.2. 5G IETF Network Slices in Centralized RAN deployment The RAN consists of two functional units: the baseband unit (BBU) and the radio unit (RU). The BBU processes the signal and is connected to the transport network. The RU transmits and receives the carrier signal that is transmitted over the air to the end user equipment (UE). In Centralized RAN as depicted in Figure 5, the RU and BBU are separated by a network called fronthaul network. In this deployment a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but three 5G IETF network slices INS_1, INS_2 and INS_3 where INS_1 and INS_2 are identical to their counterparts in distributed RAN deployment case (see Figure 4) and a new INS_3 connects the Radio Units (RU) to the BBUs. <-------------------- 5G E2E Network Slice --------------------> <-------- RS --------> <-- CS --> <--- INS_3 ---> <--- INS_1 ---> <---- INS_2 ----> ........................... : RAN : : ........ : ............. ............. : |----| : : |-----| : : : |------| : : |-----| : | RU | : FN : | BBU | : : Transport : | Core | : Transport : | App | : |----| : : |-----| : : Network 1 : |------| : Network 2 : |-----| : :......: : :...........: :...........: : : :.........................: Legend INS: 5G IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul network RU: Radio Unit BBU: BaseBand Unit App: Mobile Application Servers Figure 5: 5G IETF network slices in Centralized RAN deployment 4.3. 5G IETF Network Slices in Cloud RAN (C-RAN) In Cloud-RAN deployment, the baseband unit (BBU) is further disaggregated into real-time and non-real-time components. The former is deployed close to antenna to manages the real-time air interface resources while the non-real-time control functions are Rokui, et al. Expires May 6, 2021 [Page 13] Internet-Draft draft-rokui-5G-network-slice November 2020 hosted centrally in the cloud. In 5G, BBU is split into two parts called CU (Central Unit) and DU (Distributed Unit) as shown in Figure 6 where these entities are connected by a new network called Midhaul network. In this deployment a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but four 5G IETF network slices INS_1, INS_2, INS_3 and INS_4 where INS_1, INS_2 and INS_3 are identical to their counterparts in centralized RAN deployment case (see Figure 5) and a new 5G IETF network slice INS_4 connects the DUs to CUs. <--------------------- 5G E2E Network Slice ---------------------> <-------------- RS ---------------> <- CS -> <--- INS_3 ---> <-- INS_4 --> <-- INS_1 --> <--- INS_2 ---> ...................................... : RAN : : ...... ...... : ........ ...... :|----| : : |----| : : |----| : : : |------| : : |-----| :| RU | : FN : | DU | : MN : | CU | : : TN1 : | Core | :TN2 : | App | :|----| : : |----| : : |----| : : : |------| : : |-----| : :....: :....: : :......: :....: : : :....................................: Legend INS: 5G IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul network MN: Midhaul network TN: Transport network DU: Distributed Unit CU: Central Unit RU: Radio Unit App: Mobile Application Servers Figure 6: 5G IETF network slices in Cloud RAN deployment 4.4. 5G IETF Network Slice as a set of Connection Groups As discussed in [I-D.nsdt-teas-ietf-network-slice-definition], an IETF network slice contains one or more connections between various network functions, application and devices. These connections can be grouped into various Connection Groups where each group has its own SLA/SLO. Rokui, et al. Expires May 6, 2021 [Page 14] Internet-Draft draft-rokui-5G-network-slice November 2020 To further explore this concept in 5G E2E network slicing, consider Figure 7, where the details of 5G IETF network slice INS_1 introduced in Figure 4 is illustrated. The 5G IETF network slice INS_1 is between 5G RAN and Core slices and has multiple connections between 5G RAN network functions BBU1 and BBU2 and 5G Core network functions AMF1 and UPF1. In particular, it contains the following connection groups, each with its own SLO where SLO-C and SLO-U might be different (e.g. they might be control and user plans SLOs): o "Connection group C" connects BBU1 and BBU2 to AMF1 with SLO-C o "Connection group U" connects BBU1 and BBU2 to UPF1 with SLO-U The combination of two connection groups will form the 5G IETF network slice INS_1. Note that the definition of 5G IETF network slice INS_1 does not specify how these connections should be realized in transport network 1. Although it is optionally possible, it is not necessarily mandatory for the definition of a 5G IETF network slice to state which technology (e.g. IP, MPLS, Optics, PON etc.) or tunnel type (e.g. RSVP-TE, SR-TE etc.) should be employed for realization. As discussed in [[I-D.nsdt-teas-ietf-network-slice-definition], any of these technologies may be used by the IETF Network Slice Controller (NSC) to realize an IETF network slice. In summary, a 5G IETF network slice is a distinct set of technology- agnostic connection groups between various 5G network functions, 5G devices or 5G applications each with its own deterministic SLO which can be realized by any suitable technology, tunnel type and service type. Rokui, et al. Expires May 6, 2021 [Page 15] Internet-Draft draft-rokui-5G-network-slice November 2020 <------- IETF Network Slice INS_1 -------> ...................... ..................... ................... : : : : : : : --------- NSE1 : : : : NSE1 --------- : : | | <---------------------------------------> | | : : | BBU1 | <+++++ : : /------------> | AMF1 | : : | | NSE2 + : : / : : | | : : --------- +: : / : : --------- : : :+ : / : : : : : + : / : : : : --------- NSE1 : + / : : : : | | <-----------+--------/ : : NSE1 --------- : : | BBU2 | : +++++++++++++++++++++++++++> | | : : | | <+++++++++++++++++++++++++++++++++++++++> | UPF1 | : : --------- NSE2 : : : : | | : : : : : : --------- : :....................: ....................: :.................: RAN Transport Core Network Network 1 Network 5G IETF Network Slice INS_1: {"Connection group C" + "Connection group U"} Connection Group C {from BBU1.NSE1, BBU2.NSE1 to AMF1.NSE1 with SLO-C} Connection Group U {from BBU1.NSE2, BBU2.NSE2 to UPF1.NSE1 with SLO-U} Legend BBU: BaseBand Unit AMF: Access and Mobility Management Function UPF: User Plane Function NSE: 5G IETF Network Slice Endpoint ---- Connection group C ++++ Connection group U Figure 7: Details of 5G IETF Network Slice as a set of Connection Groups 5. IETF Network Slice Controller NBI for 5G As discussed in [I-D.nsdt-teas-ietf-network-slice-definition] and [I-D.nsdt-teas-ns-framework], to fulfill (i.e. create, modify, delete) any IETF network slice and perform monitoring on it, an entity called IETF Network Slice Controller (NSC) is required to take abstract requests for 5G IETF network slices and realize them using suitable underlying technologies. An IETF Network Slice Controller is the key building block for control and management of the transport Rokui, et al. Expires May 6, 2021 [Page 16] Internet-Draft draft-rokui-5G-network-slice November 2020 slice. It provides the creation/modification/deletion, monitoring and optimization of transport Slices in a multi-domain, a multi- technology and multi-vendor environment. Figure 8 shows the NSC and its NBI interface for 5G. Draft [I-D.wd-teas-transport-slice-yang] addresses the base data model of the NSC NBI interface for all network slicing use-cases. However, for 5G network slicing, the current model shall be augmented to include the specific characteristics of the 5G network slices for this interface. The details of NSC NBI interface for 5G provided in Section 6. +------------------------------------------+ | 5G Customer (Tenant) | +------------------------------------------+ A | V +------------------------------------------+ | 5G E2E Network Slice Orchestrator | +------------------------------------------+ A | NSC NBI V +------------------------------------------+ | IETF Network Slice Controller (I-NSC) | +------------------------------------------+ A | NSC SBI V +------------------------------------------+ | Network Controller(s) | +------------------------------------------+ Figure 8: IETF Network Slice Controller NBI for 5G 5.1. Relationship between 5G IETF Network Slice NBI and various IETF data models As discussed in [I-D.nsdt-teas-ns-framework], the main task of the IETF Network Slice Controller is to map abstract IETF network slice requirements from NBI to concrete technologies on SBI and establish the required connectivity, and ensure that required resources are allocated to IETF network slice. There are a number of different technologies that can be used on SBI including physical connections, MPLS, TSN, Flex-E, PON etc. If the undelay technology is IP/MPLS/ Rokui, et al. Expires May 6, 2021 [Page 17] Internet-Draft draft-rokui-5G-network-slice November 2020 Optics, any IETF models can be used during the realization of IETF network slice. There are no specific mapping requirements for 5G. The only difference is that in case of 5G, the NBI interface contains additional 5G specific attributes such as customer name, mobile service type, 5G E2E network slice ID (i.e. S-NSSAI) and so on (See Section 6). These 5G specific attributes can be employed by IETF Network Slice Controller during the realization of 5G IETF network slices on how to map NBI to SBI. They can also be used for assurance of 5G IETF network slices. Figure 9 shows the mapping between NBI to SBI for 5G IETF network slices. | (1) NBI: Request to create/modify/delete | 5G IETF Network Slice V +----------------------+ | IETF Network Slice | (2) Mapping between technology | Controller (NSC) | agnostics NBI to technology +----------------------+ specific SBI ^ ^ ^ | | | |---| | |---| (3) SBI: Realize 5G IETF Network Slice | | | by using various IETF models for V V V services, tunnels and paths +----------------------+ | Network |-+ | Controller(s) | |-+ +----------------------+ | | +----------------------+ | +----------------------+ Figure 9: Relationship between transport slice interface and IETF Service/Tunnels/Path data models 6. 5G IETF Network Slice NBI Information Model Based on the definition of 5G IETF Network slices (see Section 4), the high-level information model of northbound interface of IETF Network Slice Controller (NSC) for 5G IETF network slices should conform with Figure 10: module: 5g-ietf-network-slices +--rw 5g-ietf-network-slice +--rw 5g-ietf-network-slice-info Rokui, et al. Expires May 6, 2021 [Page 18] Internet-Draft draft-rokui-5G-network-slice November 2020 +--rw ins-id +--rw ins-name +--rw ins-plmn +--rw ins-hierarchical-tenant-id +--rw 5g-network-slice-info [s-nssai] +--rw s-nssai (i.e. 5G E2E network slice id) +--rw 5g-customer (i.e. 5G tenant) +--rw 5g-mobile-service-type (e.g. CCTV, infotainment etc) +--rw 5g-connection-group* [connection-group-id ] +--rw connection-group-id +--rw connection-group-name +--rw connection-group-type (e.g., P2P, MP2MP, etc.) +--rw connection-group-status +-- admin-status +-- operational-status +--rw connection-group-member* [member-id] +--rw member-id +--rw member-name +--rw member //Ref. to 5G-ietf-connection-group-member +--ro member-slo-monitoring +--ro latency? +--ro jitter? +--ro loss? +--rw connection-group-slo-policy +--rw policy-id +--rw slo attributes +--rw connection-group-realization-policy //Optional +--rw policy-id +--rw realization-attributes //Optional //Technology-specific attributes +--rw connection-group-monitoring-policy //Optional +--rw policy-id +--rw monitoring-attributes //Optional. Such as if monitoring //is needed, frequency of //monitoring and how often send //them to NBI etc. +--rw 5g-ietf-network-slice-endpoint* [ep-id] +--rw ep-id +--rw ep-name +--rw domain-id +--rw node-id +--rw transport-port-id +--rw transport-vlan-id +--rw transport-id (e.g. IP address of the transport) +--rw transport-label (For future use) +--rw transport-bsid (For future use) +--rw 5G-ietf-connection-group-member* [member-id] +--rw member-id Rokui, et al. Expires May 6, 2021 [Page 19] Internet-Draft draft-rokui-5G-network-slice November 2020 +--rw member-endpoint-a //Ref. to 5g-ietf-network-slice-endpoint +--rw member-endpoint-b //Ref. to 5g-ietf-network-slice-endpoint Figure 10: Information model of NSC NBI interface for 5G IETF Network Slices The proposed information model should include the following building blocks: o 5g-ietf-network-slice-info: All attributes related to 5G IETF Network Slice. It contains information such as 5G IETF network slice name, 5G IETF network slice ID, PLMN and hierarchical tenant ID etc. o 5g-network-slice-info: A list of all E2E network slices mapped to this 5G IETF network slice. As discussed in Section 3, a request for creation of a 5G IETF network slice is sent from 5G E2E network slice orchestrator to IETF Network Slice Controller (NSC) for a customer and certain service type (e.g. CCTV, Infotainment, URLLC, etc.). It is NSC's decision to either create a new transport slice or use one of the existing ones. As a result, the mapping between 5G E2E network slice and IETF network slice is many to one, i.e. one 5G IETF network slice can be used with multiple 5G E2E network slices. The attributes of each 5G E2E network slices are included here. The 5g-network-slice-info contains the list of E2E network slices which are mapped to a 5G IETF network slice with all relevant attributes such as S-NSSAI, customer name and service type. o 5g-connection-group: A 5G IETF network slice contains one or more connection groups each with its own SLA/SLO. Each connection group contains: * connection-group-attributes: A list of attributes for each 5g- connection-group such as connection-group-id, connection-group- name and connection-group-status * connection-group-member: A list of members. Each member is a connection between two endpoints. A connection group can contain one or more members. For example, the connections BBU1-UPF1 and BBU2-UPF1 are 2 members of "connection group U" in Figure 7. * connection-group-slo-policy: This is a mandatory policy. The connection-group-slo-policy represents in a generic and technology-agnostics fashion the SLO requirement needed to realize members of a connection group. It contains SLOs such Rokui, et al. Expires May 6, 2021 [Page 20] Internet-Draft draft-rokui-5G-network-slice November 2020 as bounded latency, bandwidth, reliability, security etc. Note that all members of a connection group must have the same SLO. * connection-group-realization-policy: This is an optional policy. In some scenarios, the 5G E2E network slice orchestrator might be able to influence the IETF Network Slice Controller on how to realize a 5G IETF network slice by providing some technology-specific information. * connection-group-monitoring-policy: This is an optional policy. The 5G E2E network slice orchestrator can influence the IETF Network Slice Controller on how to perform monitoring, analytics and optimization on 5G IETF Network Slices. It contains, the type of assurance needed, time interval, frequency of how often to inform the 5G E2E Network Slice Orchestrator etc. o 5g-ietf-network-slice-endpoint: It contains the list of all endpoints along with their attributes which belong to a 5G IETF network slice. See Figure 11 o 5G-ietf-connection-group-member: It contains the list of all members of connectin groups along with their attributes which belong to a 5G IETF network slice. Rokui, et al. Expires May 6, 2021 [Page 21] Internet-Draft draft-rokui-5G-network-slice November 2020 transport-port-id transport-vlan-id transport-id (e.g. IP address of the transport) transport-label (For future use) transport-bsid (For future use) | DAN | |----------------| | | | | |--------------| | o | V | Transport | | NSE |------------| Network | | | | | | | |--------------| |----------------| ^ | | ep-id (e.g. the IP address) ep-name domain-id node-id Legend: DAN: Device, application and/or network function NSE: IETF Network Slice Endpoint Figure 11: Details of the 5G IETF network slice endpoints 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations TBD 9. Acknowledgments The authors would like to thank the following people for their contribution to this draft: o Ryan Hoffman, Telus Rokui, et al. Expires May 6, 2021 [Page 22] Internet-Draft draft-rokui-5G-network-slice November 2020 10. Informative References [I-D.boucadair-connectivity-provisioning-protocol] Boucadair, M., Jacquenet, C., Zhang, D., and P. Georgatsos, "Connectivity Provisioning Negotiation Protocol (CPNP)", draft-boucadair-connectivity- provisioning-protocol-15 (work in progress), December 2017. [I-D.contreras-teas-slice-nbi] Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF Network Slice use cases and attributes for Northbound Interface of controller", draft-contreras-teas-slice- nbi-03 (work in progress), October 2020. [I-D.homma-slice-provision-models] Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. Foy, "Network Slice Provision Models", draft-homma-slice- provision-models-00 (work in progress), February 2019. [I-D.ietf-i2rs-yang-network-topo] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A Data Model for Network Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in progress), December 2017. [I-D.ietf-teas-actn-vn-yang] Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., Yoon, B., Wu, Q., and P. Park, "A Yang Data Model for VN Operation", draft-ietf-teas-actn-vn-yang-04 (work in progress), February 2019. [I-D.king-teas-applicability-actn-slicing] King, D. and Y. Lee, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing", draft-king-teas-applicability-actn-slicing-04 (work in progress), October 2018. [I-D.nsdt-teas-ietf-network-slice-definition] Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "Definition of IETF Network Slices", draft-nsdt- teas-ietf-network-slice-definition-00 (work in progress), October 2020. Rokui, et al. Expires May 6, 2021 [Page 23] Internet-Draft draft-rokui-5G-network-slice November 2020 [I-D.nsdt-teas-ns-framework] Gray, E. and J. Drake, "Framework for Transport Network Slices", draft-nsdt-teas-ns-framework-04 (work in progress), July 2020. [I-D.qiang-coms-netslicing-information-model] Qiang, L., Galis, A., Geng, L., kiran.makhijani@huawei.com, k., Martinez-Julia, P., Flinck, H., and X. Foy, "Technology Independent Information Model for Network Slicing", draft-qiang-coms- netslicing-information-model-02 (work in progress), January 2018. [I-D.wd-teas-transport-slice-yang] Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data Model for Transport Slice NBI", draft-wd-teas-transport- slice-yang-02 (work in progress), July 2020. [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 (V16.2.0): System Architecture for the 5G System (5GS); Stage 2 (Release 16)", September 2019, . Rokui, et al. Expires May 6, 2021 [Page 24] Internet-Draft draft-rokui-5G-network-slice November 2020 [TS.28.530-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 V15.1.0 Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements (Release 15)", December 2018, . [TS.28.531-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 V16.2.0 Technical Specification Group Services and System Aspects; Management and orchestration; Provisioning; (Release 16)", June 2019, . [TS.28.540-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 28.540 V16.0.0 Technical Specification Group Services and System Aspects; Management and orchestration; 5G Network Resource Model (NRM); Stage 1 (Release 16)", June 2019, . [TS.28.541-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 28.541 V16.1.0 Technical Specification Group Services and System Aspects; Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 (Release 16)", June 2019, . Authors' Addresses Reza Rokui Nokia Canada Email: reza.rokui@nokia.com Shunsuke Homma NTT 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585 Japan Email: shunsuke.homma.ietf@gmail.com Rokui, et al. Expires May 6, 2021 [Page 25] Internet-Draft draft-rokui-5G-network-slice November 2020 Xavier de Foy InterDigital Inc. Canada Email: Xavier.Defoy@InterDigital.com Luis M. Contreras Telefonica Spain Email: luismiguel.contrerasmurillo@telefonica.com Philip Eardley BT UK Email: philip.eardley@bt.com Kiran Makhijani Futurewei Networks US Email: kiranm@futurewei.com Hannu Flinck Nokia Finland Email: hannu.flinck@nokia-bell-labs.com Rainer Schatzmayr Deutsche Telekom Germany Email: rainer.schatzmayr@telekom.de Ali Tizghadam TELUS Communications Inc Canada Email: ali.tizghadam@telus.com Rokui, et al. Expires May 6, 2021 [Page 26] Internet-Draft draft-rokui-5G-network-slice November 2020 Christopher Janz Huawei Canada Canada Email: christopher.janz@huawei.com Henry Yu Huawei Canada Canada Email: henry.yu1@huawei.com Rokui, et al. Expires May 6, 2021 [Page 27]