Individual R. Rokui Internet-Draft Nokia Intended status: Informational S. Homma Expires: January 3, 2020 NTT D. Lopez Telefonica I+D X. de Foy InterDigital Inc. L. Contreras-Murillo J. Ordonez-Lucena Telefonica I+D P. Martinez-Julia NICT M. Boucadair Orange P. Eardley BT K. Makhijani Futurewei Networks H. Flinck Nokia July 2, 2019 5G Transport Slice Connectivity Interface draft-rokui-5g-transport-slice-00 Abstract The 5G Network slicing is an approach to provide separate independent E2E logical network from user equipment (UE) to applications where each network slice has different SLA requirements. Each E2E network slice consists of multitude of RAN-slice, Core-slice and Transport- slices, each with its own controller. To provide automation, assurance and optimization of the network slices, an E2E network slice controller is needed which interacts with controller in RAN, Core and Transport slices. The interfaces between the E2E network slice controller and RAN and Core controllers are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface for transport slices. The aim of this document is to provide the clarification of this interface and to provide the information model of this interface for automation, monitoring and optimization of the transport slices. Rokui, et al. Expires January 3, 2020 [Page 1] Internet-Draft draft-rokui-5G-transport-slice July 2019 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 January 3, 2020. Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 3 2. High level architecture of 5G end-to-end network slicing . . 5 3. Logical flow cross layers for automation of an end-to-end network slices . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definition of Transport Slice . . . . . . . . . . . . . . . . 11 4.1. Transport Slices in Distributed RAN . . . . . . . . . . . 11 4.2. Transport Slices in Centralized RAN (C-RAN) . . . . . . . 12 4.3. Transport Slices in cloud RAN . . . . . . . . . . . . . . 13 4.4. Transport Slice as a set of networks . . . . . . . . . . 14 5. Transport Slice Connectivity Interface (TSCi) . . . . . . . . 16 5.1. Relationship between TSCi and various IETF data models . 17 5.2. Realization (aka Implementation) of transport slices . . 18 6. Transport slice connectivity interface (TSCi) information Rokui, et al. Expires January 3, 2020 [Page 2] Internet-Draft draft-rokui-5G-transport-slice July 2019 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. transport-slice-info . . . . . . . . . . . . . . . . . . 22 6.2. network-slice-info . . . . . . . . . . . . . . . . . . . 22 6.3. transport-slice-networks . . . . . . . . . . . . . . . . 22 6.4. node . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.5. connection-link . . . . . . . . . . . . . . . . . . . . . 23 6.6. transport-slice-policy . . . . . . . . . . . . . . . . . 23 6.6.1. transport-slice-sla-policy . . . . . . . . . . . . . 23 6.6.2. transport-slice-selection-policy . . . . . . . . . . 23 6.6.3. transport-slice-assurance-policy . . . . . . . . . . 23 6.7. IETF models . . . . . . . . . . . . . . . . . . . . . . . 24 6.7.1. ACTN model . . . . . . . . . . . . . . . . . . . . . 24 6.7.2. i2rs model . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Informative References . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Network Slicing is a mechanism which a network operator can use to allocate dedicated infrastructures and services to a customer (aka tenant) from shared operator's network. In particular a 5G network slice is inherently an E2E concept and is composed of multiple logical independent networks are created in a common operator's network from an user equipement to applications. In specific, the network slicing receives attention due to factors such as diversity of services and devices in 5G each with its own SLA requirements. Each E2E network slice consists of multitude of RAN-slice, Core-slice and Transport-slices each with its own controller. To provide automation, assurance and optimization of the network slices, an E2E network slice orchestrator is needed which interacts with controller of RAN, Core and Transport slices. The interfaces between the E2E network slice controller and RAN and Core controllers are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface for transport slices. The aim of this document is to provide the clarification of this interface and to provide the information model of this interface for automation, monitoring and optimization of the transport slices. 1.1. Definition of Terms Please refer to [I-D.homma-slice-provision-models] as well. Customer: Also known as Tenant. Any application, client network, or customer of a network provider, i.e. an NS tenant is a person or group that rents and occupies NSIs from network provider. Rokui, et al. Expires January 3, 2020 [Page 3] Internet-Draft draft-rokui-5G-transport-slice July 2019 E2E Network Slice: A E2E network slice is a virtual network provided by a Slice Provider that has the functionality and performance to support a specific industry sector and/or service. This capability will be the subject of a commercial agreement between the Slice Provider and Slice Buyer, and although it may well support dynamic scale-in/out, the Slice capability will normally be long-lasting i.e. only change on commercial timescales, although this may become more dynamic over time. In specific, E2E 5G network slices are separate independent logical network E2E from user equipment (UE) to applications in a common infrastructure where each logical network has dedicated SLA. It is an E2E concept which spans multiple network domains (e.g. radio, transport and core), and in some cases more than one administrative domain. Network Slice Instance (NSI): Also known as Network slice profile (NS profile), NSI is an E2E instance of a network slice blueprint which is instantiated in service provider's network for specific customer and specific service type. Note that customer and service type can be wildcard. Transport Slice: It is also called Transport Sub-Slice. A set of connections between various network functions (VNF or PNF) with deterministic SLAs. They can be implemented (aka realized) with various technologies (e.g. IP, Optics, FN, Microwave) and various transport (e.g. RSVP, Segment routing, ODU, OCH etc). RAN Slice: It is also called RAN Sub-Slice. The context and personality created on RAN network functions for each E2E network slice. Core Slice: It is also called Core Sub-Slice. The context and personality created on Core network (CN) functions for each e2e network slice. S-NSSAI: Single Network Slice Selection Assistance Information, defined by 3GPP and is the identification of a Network Slice Sub-Slice: The RAN, Transport or Core Slices are also called Sub- Slice or Subnet; i.e. RAN, Transport and Core Sub-slices or Subnets Service Level Agreement (SLA): An agreement between a customer (aka tenant) and network provider that describes the quality with which features and functions are to be delivered. It may include information on target KPIs (such as min guaranteed throughput, max tolerable latency, max tolerable packet loss rate); the types of Rokui, et al. Expires January 3, 2020 [Page 4] Internet-Draft draft-rokui-5G-transport-slice July 2019 service (such as the network service functions or billing) to be executed; the location, nature, and quantities of services (such as the amount and location of compute resources and the accelerators require) gNB: gNB incorporates two major modules; Centralized Unit (CU) and Distribute Unit (DU) UE: UE: User Equipment such as vehicle Infotainment, Cell phone, IoT sensor etc 2. High level architecture of 5G end-to-end network slicing To demonstrate the concept of 5G E2E network slicing and the role of various controllers consider a typical 5G network shown in Figure 1 where a mobile network operator Y has two customers (tenants) C1 and Public Safety. The boundaries of administrative domain of the operator includes RAN, Transport, Core and Application domains. Each customer requests to have several logical independent E2E networks from UEs (e.g. vehicle infotainment, mobile phone, IoT meters etc.) to the application, each with distinct SLAs. In 5G, each of these independent networks called an E2E network slice, which consists of RAN, Transport and Core slices (or RAN, Transport and Core Sub- slices). In Figure 1 there are four E2E network slices, NS1 to NS4, each with its own RAN, Core and Transport slices. To create RAN slice, the RAN network functions such as eNB and gNB should be programmed to have a context for each E2E network slice. This context means that the RAN network functions should allocate certain resources for each E2E network slice such as air interface, various schedulers, policies and profiles to guarantee the SLA requirement for that specific network slice. By the same token, the Core slice means to create the context for each E2E network slice on Core network functions. This means that the RAN and Core network functions are aware of multiple E2E network slices. When both RAN and Core slices are created, they should be connected together using a set of connections to have an E2E network slice. These set of connections are called Transport Slices, i.e. the transport slices are a group of connections with specific SLAs. The following factors dictate the number of transport slices. The details on transport slices will be discussed in see Section 4: o The RAN deployment (i.e. distributed RAN, Centralized RAN or Cloud RAN). For example, in Cloud RAN, the RAN network function (i.e. gNB) is decomposed into two network functions (called CU and DU) where one or both will be VNFs and there is a Midhaul network Rokui, et al. Expires January 3, 2020 [Page 5] Internet-Draft draft-rokui-5G-transport-slice July 2019 between them. In this case, there will be a transport slice in RAN to connect DUs to CU o The location of the mobile applications. If there is a network between the mobile applications and the 5G Core, another transport slice is needed to connect the 5G Core to Applications. o Mobile network policy on how to allow creation of the E2E network slices and if the sharing of transport slices between multiple E2E network slices are desirable and allowed. At the end when RAN, Core and Transport slices are created, they should be bind or associated together to form a working E2E network slice. Since the nature of an E2E network slice is dynamic and the life cycle of each network slice might be a few hours or few months, various controllers are needed to perform the life cycle of various E2E network slices in their respective domains. As shown in Figure 1, each RAN, Core and Transport slice needs a controller. Also an E2E network slice controller is needed to provide the coordination and control of network slices from an E2E perspective. In summary, an E2E network slice will involve several domains, each with its own controller: 5G RAN domain, transport domain, and 5G core domain. These need to be coordinated in order to deliver an E2E service. Note that in this context a service is not necessarily an IP/MPLS service but rather customer (aka tenant) facing services such as CCTV service, eMBB service and Infotainment service etc. Rokui, et al. Expires January 3, 2020 [Page 6] Internet-Draft draft-rokui-5G-transport-slice July 2019 <-------------- End to End Network Slices ----------------> <----- RAN -----> <----- Transport ----> <----- Core -----> Slice Slice Slice |---------------------------------------------------------| | E2E Network Slice Controller | |---------------------------------------------------------| |----------------| |-------------------| |----------------| | RAN | | Transport | | Core | | Controller | | Controller | | Controller | |----------------| |-------------------| |----------------| ................ .................... ......... ....... : : : : : : : : : : : : : : : : ------------------------------------------------------------- NS1 ============================================================= NS2 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NS3 : : : : : : : : : : : : : : : : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - NS4 : : : : : : : : : : : : : : : : :..............: :..................: :.......: :.....: RAN Transport Core Mobile Network Network Network Application Customers (aka Tenants): Public Safety and C1 MNO (Mobile Network Operator): Operator Y Legend: ----- NS1: E2E network slice 1 for customer C1, service type Infotainment ===== NS2: E2E network slice 2 for customer C1, service type Autonomous Driving +++++ NS3: E2E network slice 3 for customer C1, service type HD Map (NS3) - - - NS4: E2E network slice 4 for customer Public Safety, service type Video Surveillance Figure 1: High level architecture of 5G end-to-end network slicing Rokui, et al. Expires January 3, 2020 [Page 7] Internet-Draft draft-rokui-5G-transport-slice July 2019 3. Logical flow cross layers for automation of an end-to-end network slices Figure 2 provides the logical flow cross layers to achieve the automatic creation of each E2E network slices such as NS1 mentioned in Figure 1. Below are the logical flow among various controllers to achieve this. It is important to note that these steps are logical and in practice some of them can be combined. For example, step 3 can be combined with steps 4 or 5. 1. The customer C1 will request the Operator Y for creation of an E2E network slice for Infotainment service type and SLA of 10 [Mbps] 2. The E2E network slice controller receives this request and using its pre-defined network slice blueprints (aka network slice templates) creates a network slice profile (aka network slice instance) which contains 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. Steps 3 to 7 shows these actions. 3. A request for creation of the RAN slice will be triggered to RAN Controller. 4. If RAN network functions are virtual, the RAN Slice controller triggers the creation of 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 the E2E network functions are known to RAN controller, it then triggers the creation of RAN slice by programming RAN network functions 7. Similar to previous steps, a request for creation of the Core slice will be triggered to Core Controller. 8. If Core network functions are virtual, the Core Slice controller triggers the creation of 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 Core network functions which are part of the E2E network functions are known to Core controller, it then triggers the creation of Core slice by programming Core network functions Rokui, et al. Expires January 3, 2020 [Page 8] Internet-Draft draft-rokui-5G-transport-slice July 2019 10. In this step, various transport slices (i.e. various connections) need to be created between various network functions, e.g. transport slices between RAN and Core slices, transport slices between RAN network functions or transport slices between core and applications 11. The transport slices will be implemented (aka realized) in the network 12. [Optional] If the creation of transport slice involves creation of VNFs (e.g. Firewall, security gateway etc.), triggers the creation of these VNFs (using for example ETSI interface Os-Ma- nfvo) 13. The E2E network slice controller binds (or associates) all these slices together to form a single E2E network slice for specific customer and specific service type. 14. At the end, when the E2E network slice is created, the E2E network slice controller will allocate a unique network slice id (called S-NSSAI) and eventually during the UE network attach, all the UEs will be informed about the existence of this newly created E2E network slice and then they can request it using the 3GPP 5G signaling procedures. Note that the interfaces 3 and 7 between the E2E network slice Controller and RAN and Core controllers and their information models are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface for transport slices, i.e. interface 10. The aim of this document is to define this interface. More details will be provided in Section 5. Rokui, et al. Expires January 3, 2020 [Page 9] Internet-Draft draft-rokui-5G-transport-slice July 2019 |----------------------------------------------------| | Customer (aka Tenant) portal | |----------------------------------------------------| |(1) V |----------------------------------------------------| | Generate NS Profile (aka NSI) using NS Blueprints | | |(2) | E2E NS | V | Controller | Decompose NS Profile and trigger various actions | |----------------------------------------------------| |(3) |(10) |(7) | |--------| | |------| | V | V V V | V --------------- | ----------------- | ---------------- | RAN | | | Transport | | | Core | Domain | Slice |-| | Slice | |-| Slice | Controllers | Controller | | Controller | | Controller | --------------- ----------------- ---------------- (6)| |(4) (11)| |(12) (8)| |(9) | | | |--------| | | | |-------------- | --------| | |------| | | | V V V | | | |----------| | | | | NFVO | | | | |----------| | V V |(5) V .............. ................. | ................. : RAN Slice : :Transport slice: | : Core Slice : :............: :...............: | :...............: .................................. | .................. : E2E Network Slice | : (13) :................................. | .................: | V |-----------------------------------------------------| | ,--------. ,-------------. ,--------. | | / RAN \ / Transport \ / Core \ | Operator "Y" | \ Domain / \ Domain / \ Domain / | | `--------' `-------------' `--------' | |-----------------------------------------------------| Figure 2: Logical flow cross layers for automation of an end-to-end network slices Rokui, et al. Expires January 3, 2020 [Page 10] Internet-Draft draft-rokui-5G-transport-slice July 2019 4. Definition of Transport Slice Since the transport slice is an important concept throughout this document, this section describes this concept in more detail. To this end, consider Figure 3 where a group of physical or virtual network functions (PNF, VNF or both) are connected together. In particular, a single transport slice is defined as: o A distinct set of connections between multiple VNFs and PNFs each with its own deterministic SLA which is implemented (aka realized) in the network using any technology (e.g IP, Optics, Microwave and PON), any tunnel types (e.g. IP, MPLS, SR, ODU/OCH) and any L0/L1/L2/L3 service types |-----| (---------------------) | NF11| ( ) |-----| ( Transport Slice ) |-----| ( ) | NF21| |-----| ( ) |-----| | NF12| ( A set of distinct ) . |-----| ( connetions connecting ) . . ( physical or virtul ) |-----| . ( network functions (PNF/VNF)) | NF2m| . ( NF11, NF12, ..., NF1n to ) |-----| |-----| ( NF21, ..., NF2m ) | NF1n| ( ) |-----| ( ) (---------------------) Figure 3: Definition of transport slice For clarity, in next three sections, a few examples of the transport slices will be provided for following RAN deployments: o Distributed RAN o Centralized RAN (C-RAN) o Cloud RAN 4.1. Transport Slices in Distributed RAN Distributed RAN is the most common deployment of 4G and 5G RAN networks where as shown in Figure 4, the RAN network is connected to Core network using the transport network. Optionally the mobile applications can be also connected to the Core network using another Rokui, et al. Expires January 3, 2020 [Page 11] Internet-Draft draft-rokui-5G-transport-slice July 2019 overlay network (e.g. Internet where the mobile applications are virtualized in another data center). In this case, for a single E2E network slice, in addition to RAN and Core slices, there are two sets of transport slices; TS_1 and TS_2. TS_1 is connecting the RAN to Core and TS_2 is connecting Core to Applications. <----------- End to End Network Slice ----------> <--- RS --> <-- CS --> <--- TS_1 ---> <--- TS_2 ---> .................. : RAN : : : ............. ........... : |----| |-----| : : : |------| : : |-----| : | RU | | BBU | : : Transport : | Core | : Other : | App | : |----| |-----| : : Network : |------| : Network : |-----| : : :...........: :.........: :................: Legend TS: Transport Slice RS: RAN Slice CS: Core Slice Figure 4: Transport slices in distributed RAN 4.2. Transport Slices in Centralized RAN (C-RAN) 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 (aka C-RAN) as depicted in Figure 5, the RU and BBU are separated by a network called fronthaul network. In this case a single E2E network slice contains three set of transport slices TS_1, TS_2 and TS_3 where TS_1 and TS_2 are identical to distributed RAN case (see Figure 4) and the new TS_3 connects the Radio Units (RU) to the BBUs. Rokui, et al. Expires January 3, 2020 [Page 12] Internet-Draft draft-rokui-5G-transport-slice July 2019 <------------------ End to End Network Slices ---------------> <-------- RS --------> <-- CS --> <--- TS_3 ---> <--- TS_1 ---> <---- TS_2 ----> ........................... : RAN : : ........ : ............. ............. : |----| : : |-----| : : : |------| : : |-----| : | RU | : FN : | BBU | : : Transport : | Core | : Other : | App | : |----| : : |-----| : : Network : |------| : Network : |-----| : :......: : :...........: :...........: : : :.........................: Legend TS: Transport Slice RS: RAN Slice CS: Core Slice FN: Fronthaul network MN: Midhaul network Figure 5: Transport slices in centralized RAN 4.3. Transport Slices in cloud RAN In new cloud-RAN architecture, the baseband unit functionality is further divided into real-time and non-real-time. The former is deployed close to antenna to manages the real-time air interface resources while the non-real-time control functions are 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 new network called Midhaul. In this deployment for a single E2E network slice, there are four sets of transport slices TS_1, TS_2, TS_3 and TS_4 where TS_1 and TS_2 and TS_3 are identical to distributed and centralized RAN (see Figure 4 and Figure 5). The new transport slice TS_4 will connect DUs to CUs. Rokui, et al. Expires January 3, 2020 [Page 13] Internet-Draft draft-rokui-5G-transport-slice July 2019 <-------------------- End to End Network Slices ------------------> <-------------- RS ---------------> <- CS -> <--- TS_3 ---> <-- TS_4 --> <-- TS_1 --> <--- TS_2 ---> ...................................... : RAN : : ...... ...... : ........ ...... :|----| : : |----| : : |----| : : : |------| : : |-----| :| RU | : FN : | DU | : MN : | CU | : : TN : | Core | : ON : | App | :|----| : : |----| : : |----| : : : |------| : : |-----| : :....: :....: : :......: :....: : : :....................................: Legend TS: Transport Slice RS: RAN Slice CS: Core Slice FN: Fronthaul network MN: Midhaul network TN: Transport network ON: Other network Figure 6: Transport slices in cloud RAN 4.4. Transport Slice as a set of networks To further explore the content of a transport slice, lets focus on transport slice TS_1 between RAN and Core. Note that the following discussion is also applicable to any other transport slices TS_2, TS_3 or TS_4. As shown in Figure 7 for an individual E2E network slice belongs to a specific customer for a specific service type, the RAN domain is connected to Core domain through the transport network. In this example, the E2E network slice is identified by n-nssai=10 for customer C1 and service type Infotainment. Two RAN network elements BBU1 and BBU2 and two Core network elements AMF1 and UPF1 are all part of the E2E network slice. There are two sets of distinct connections between RAN and Core domains; o Network-C which connects BBU1 and BBU2 to AMF1 with SLA-C o Network-U which connects BBU1 and BBU2 to UPF1 with SLA-U Rokui, et al. Expires January 3, 2020 [Page 14] Internet-Draft draft-rokui-5G-transport-slice July 2019 Customer: C1 Service type: Infotainment S-NSSAI: 10 Network-C {from BBU-1.tp1, BBU-2.tp1 to AMF1.tp1 with SLA-C} Network-U {from BBU-1.tp2, BBU-2.tp2 to UPF1.tp2 with SLA-U} Transport slice TS_1: { Network-C and Network-U } .................... .................... .................. : : : : : : : --------- tp1 : : : : tp1 --------- : : | | <------------------------------------> | | : : | BBU1 | <+++ : : /-----------> | AMF1 | : : | | tp2 + : : / : : | | : : --------- +: : / : : --------- : : :+ : / : : : : : + : / : : : : --------- tp1 : + / : : : : | | <---------+--------/ : : tp2 --------- : : | BBU2 | : ++++++++++++++++++++++++++> | | : : | | <++++++++++++++++++++++++++++++++++++> | UPF1 | : : --------- tp2 : : : : | | : : : : : : --------- : :..................: ...................: :................: RAN Transport Core Network Network Network Legend tp termination point ----- Network-C +++++ Network-U Figure 7: Transport Slice as a set of networks Note that the SLA-C and SLA-U can be different. The combination of these two networks is called a single transport slice TS_1. Note that the definition of the transport slice does not specifies how these connections should be realized (or implemented). It also does not specify which technology (e.g. IP, MPLS, Optics etc.) or tunnel type (e.g. MPLS, Segment Routing etc.) should be used during the realization. Those are part of realization of the transport slice done by transport slice controller. With this approach the definition is logically separated from implementation of transport slices. This gives a tremendous programmability and flexibility during the realization of transport slices using any type of technologies and tunnel types. Rokui, et al. Expires January 3, 2020 [Page 15] Internet-Draft draft-rokui-5G-transport-slice July 2019 In summary, a transport slice is a distinct set of technology- agnostics connections each with its own deterministic SLA which can be implemented (aka realized) using any technology, tunnel type and service type. 5. Transport Slice Connectivity Interface (TSCi) As shown in Figure 2, the interfaces 3 and 7 between the E2E network slice Controller and RAN and Core controllers, respectively and their information models are defined in various 3GPP technical specifications [TS.28.530-3GPP], [TS.28.531-3GPP], [TS.28.540-3GPP] and [TS.28.541-3GPP]. However, 3GPP has not defined the same interface for transport slices, i.e. interface 10. The aim of this document is to provide the clarification of this interface and to provide the information model of this interface. The interface is called the Transport Slice Connectivity interface (TSCi) which provides some means for automation, monitoring and optimization of the transport slices. This new interface is needed in order to simplify the creation of the Transport slices and hides all the complexity of implementation (aka realization) from higher E2E network slice controller similar to their RAN and Core counterparts defined by 3GPP. The aim of this document is to define a new interface and its information model between the E2E network slice controller and the transport slice controller. The characteristics on this new interface are: a. The interface allows a request and response about resources. It should not allow negotiation, as this would be complex and not have a clear benefit b. This interface is needed by the same layer that configures 3GPP RAN and Core slices to support the E2E path management in 5G networks. The provider of this interface is the higher layer controller which needs to create a connectivity between two network functions. The provider of this interface is the lower layer controller which provide the implementation (aka realization) of this connectivity (i.e. transport slice). c. This interface is needed in industry to achieve true standard based automation of 5G E2E network slices. It provides a technology-agnostic intent-based interface to the E2E network slice controller similar to interfaces defined by 3GPP for RAN and Core slices Rokui, et al. Expires January 3, 2020 [Page 16] Internet-Draft draft-rokui-5G-transport-slice July 2019 d. This interface is independent of type of network functions which needs to be connected, i.e. it is independent of any specific repository, software usage, protocol, or platform which realizes the physical or virtual network functions. e. The interface standardizes a way to learn about what resources are available in the network which impact the creation of the transport slices f. This technology independent interface simplifies the creation of the transports slices by describing it in a standard way along with all the network functions (such as eNB, gNB, CU, DU, Core, Mobile application server, etc.) that compose a transport slice, their properties, attributes and their SLA requirements, i.e. the connectivity resources requested from an E2E network slice controller to transport slice controller with their corresponding SLA requirements g. This interface provides capabilities for transport slice monitoring and analytics. It means that the TSCi interface allows enabling/disabling the collection of the transport slices telemetry, assurance and Threshold Crossing Alert (TCA) data and providing them to the E2E network slice controller h. This interface provides capabilities for optimization of the transport slices. Since the nature of an E2E network slice is dynamic, it is important to make sure the transport slice SLA are valid and in case any SLA violation happens, the transport slice controller performs the closed-loop action and informe the upper layer E2E network slice controller for the violation and closed- loop action. This interface allows this fucntionality. i. This interface allows binding and association between RAN to Transport slices and between Core to Transport slices j. This interface complements various IETF service, tunnel, path models by providing an abstract layer on top of these models 5.1. Relationship between TSCi and various IETF data models The transport slice connectivity interface and its relationship to various IETF data models are not addressed in any IETF WGs as it has very unique characteristics of the 5G E2E network slicing. The new interface complements various IETF service, tunnel, path data models by providing an abstract layer on top of these models. Rokui, et al. Expires January 3, 2020 [Page 17] Internet-Draft draft-rokui-5G-transport-slice July 2019 ^ | (1) Transport Slice Connectivity | Interface (TSCi) v ------------------------ | Transport slice | (2) Find the resource (e.g. | Controller | boarder routers, ip addresses, ------------------------ VLAN etc) ^ ^ ^ | | | |-------| | |-------| (3) Trigger various IETF service, | | | path and tunnel APIs v v v (---------------------------) ( ) ( Transport Network ) ( ) (---------------------------) Figure 8: Relationship between transport slice interface and IETF Service/Tunnels/Path data models Figure 8 shows more details on how the new transport slice connectivity interface (TSCi) relates to various IETF service/tunnels/path models. The transport slice controller receives a request for creation of a transport slice. This request is an abstract intent-based request which contains the required connections between various network functions in RAN and Core. The transport slice controller will then realize or implement those connections using various IETF models. In a sense, the new transport slice connectivity interface provides an abstract layer on top of IETF models. The IETF service, path and tunnel data models can be any existing IETF service models such as L3SM or L2SM ([RFC8049] and [RFC8466]). It also can be any future data models. 5.2. Realization (aka Implementation) of transport slices Since the transport slice connectivity interface describes the connections not the services, it is essential to make a distinction between connections and implemented services. Referring to Figure 9, assume using the new transport slice interface, the E2E network slice controller requests the creation of a transport slice which has multiple connections between RAN and Core. One of these connections is shown below between RAN1 and UPF1. The E2E network slice controller can request a connection between RAN1 to UPF1 for a Rokui, et al. Expires January 3, 2020 [Page 18] Internet-Draft draft-rokui-5G-transport-slice July 2019 specific tenant, specific service type and specific SLA (e.g. customer Public Safety for service CCTV with latency of 5 [ms] or better). (-----------------------) ( Transport Network ) ( ) -------- UNI1 -------- -------- UNI2 -------- | RAN1 |-------| BR1 | | BR2 |--------| UPF1 | -------- -------- -------- -------- ( ) ( ) (-----------------------) <=========================> IP/MPLS service, path and tunnel between BR1 & BR2 <-------------------------------------------------> Connectivity between RAN1 and UPF1 (which is part of a Transport Slice) Legend: <---> Connection part of the transport slice <===> Implementation (aka realization) of the transport slice Figure 9: Distinction between Connections and Services To realize (aka implement) this connection, the transport slice controller, will find the endpoint for the L0/L1/L2/L3 services, find the best path and create a service between these endpoints. In this example, in order to implement the connection between RAN1 and UPF1, the transport slice controller will first find the best boarder routers BR1 and BR2, find the best path between them and finally creates a Service/path from BR1 to BR2. It is important to note that: o The endpoints of the Connection are different from the endpoints of the Services, paths and tunnels. This is the unique characteristic of transport slices where the endpoints of the connections are different from endpoints of the Services (i.e. endpoint of the transport slices are RAN1 and UPF1 whereas the endpoint of services are BR1 and BR2 Rokui, et al. Expires January 3, 2020 [Page 19] Internet-Draft draft-rokui-5G-transport-slice July 2019 o The Service/path API can be any existing IETF service models such as L3SM or L2SM ([RFC8049] and [RFC8466]). It also can be any future service model o In order to have the connectivity between RAN1 and UPF1, the RAN and Core slices should be associated to Transport slice. This is also a by-product of the Transport slice connectivity interface when all allocated resources for access points (such as allocated VLAN IDs, IP addresses etc) are conveyed to RAN and Core Slices. This will be done by cordiantion between transport slice controller and E2E network slice controller. 6. Transport slice connectivity interface (TSCi) information model Based on the definition of a transport slice (see Section 4), the high-level information model of a transport slice connectivity interface should conform with Figure 10: Rokui, et al. Expires January 3, 2020 [Page 20] Internet-Draft draft-rokui-5G-transport-slice July 2019 module: transport-slice-connectivity +--rw transport-slice +--rw transport-slice-info +--rw ts-id +--rw ts-name +--... +--rw network-slice-info [ns-id] +--rw list of s-nnsai (i.e. E2E network slice id) +--rw customer (aka tenant) +--rw service type (e.g. CCTV, infotainment etc) +--rw NS IDs (i.e. list of S-NSSAI) +--... +--rw transport-slice-networks* [network-id] +--rw network-id +--... +--rw node* [node-id] +--rw node-id +--... +--rw connection-link* [link-id] +--rw link-id +--rw endpoint-A +--rw endpoint-B +--... +--rw transport-slice-policy* [policy-id] +--rw policy-id +--rw policy-type (e.g. sla-policy, selection-policy, assurance-policy) +--... Figure 10: High-level information model of transport slice connectivity interface The proposed transport slice information model should include the following building blocks: o transport-slice-info: Information related to transport slice o network-slice-info: A list of all E2E network slices mapped to transport slice o transport-slice-networks: Each transport slice is a set of networks. Each network contains: * list of nodes (i.e. list of RAN and Core network functions) * list of connection-links (i.e. list of connections between nodes) Rokui, et al. Expires January 3, 2020 [Page 21] Internet-Draft draft-rokui-5G-transport-slice July 2019 * list of transport-slice-policies (i.e. various SLA, Selection and Monitoring policies) 6.1. transport-slice-info It contains information such as transport slice name, transport slice ID etc. The details will be provided in next version of this draft. 6.2. network-slice-info As discussed in Section 3, a request for creation of a transport slice starts with the fact that a customer (aka tenant) will request an E2E network slice from an operator for a certain service type (e.g. CCTV, Infotainment, URLLC, etc.). So, there is a mapping between transport slice and the E2E network slice. Depending on the deployment, it is possible to map multiple E2E network slice to a transport slice, i.e. the mapping between transport slice to E2E network slice is one to many. The network-slice-info contains the list of E2E network slices which are mapped to the transport slice with all relevant information such as S-NSSAI, name of customer, service type etc. The details will be provided in next version of this draft. 6.3. transport-slice-networks As per Section 4, a transport slice will contain one or more transport-slice-networks. 6.4. node As discussed in Section 4, the transport slice comprises one or more connectivity networks between RAN and Core network elements. It is also possible to have the connectivity networks between RAN and RAN network elements for some RAN deployments (example for midhaul network). As discussed in section 2.2, when the transport slice is realized (implemented), the network elements which are the endpoints of realization of the transport slice might be different. As a result, the nodes in this model represent RAN or Core network elements. However, the model is flexible where nodes might represent the routers or switches which are the endpoints of the transport slice realization. The attributes of the node are IP address, node name, domain ID and termination points. The details will be provided in next version of this draft. Rokui, et al. Expires January 3, 2020 [Page 22] Internet-Draft draft-rokui-5G-transport-slice July 2019 6.5. connection-link Each transport-slice-networks contain one or more connections between various nodes described in Section 6.4. The connection-link is a list of links which are represented by endpoint-A, endpoint-B etc. The details will be provided in next version of this draft. 6.6. transport-slice-policy To establish a transport slice, one or more transport-slice-networks will be created each with certain SLA requirement which is represented by transport-slice-policy. This draft proposes three types of transport slice policies to be supported: o transport-slice-sla-policy o transport-slice-selection-policy o transport-slice-assurance-policy The summary of these policies will be provided here. The details will be provided in next version of this draft. 6.6.1. transport-slice-sla-policy This is a mandatory policy. The transport-slice-policy represents in a generic and technology-agnostics way the SLA requirement needed to realize a group of connections which are part of a transport slice. It is defined per transport-slice-network. It contains the bounded latency, bandwidth, reliability, security etc. 6.6.2. transport-slice-selection-policy This is an optional policy. In some deployment, the E2E network slice controller might want to assist the transport slice controller on how to realize a transport slice by providing some information regarding the type of technologies and tunnels. This information will be provided in transport-slice-selection-policy. 6.6.3. transport-slice-assurance-policy This is a mandatory policy. The E2E network slice controller shall influence the transport slice controller for transport slice assurance on how to perform monitoring, analytics and optimization. To this end, the transport-slice-assurance-policy will be used. It contains, the type of assurance needed, time interval, how often inform the E2E network slice controller etc. Rokui, et al. Expires January 3, 2020 [Page 23] Internet-Draft draft-rokui-5G-transport-slice July 2019 6.7. IETF models Currently none of the IETF data models address the modeling of transport slice connectivity as shown in Figure 6. However, the various IETF data models might be augmented to address the information model of the transport slice connectivity interface. Following is the list of candidates IETF YANG models. This is not an extensive list and the next version of the draft will provide a more comprehensive list. 6.7.1. ACTN model As defined in [RFC8453], [I-D.king-teas-applicability-actn-slicing] and [I-D.ietf-teas-actn-vn-yang] a VN (Virtual Network) is the abstract customer view of the TE network. The VN can be seen as a set of edge-to-edge abstract links (a Type 1 VN). Each abstract link is referred to as a VN member and is formed as an E2E tunnel across the underlying networks. This definition is very similar to definition of the transport slice which means that the VN YANG model can be augmented to address the modeling of the transport slice shown in Figure 6. This is work in progress for next version of this document. 6.7.2. i2rs model Similar to [I-D.qiang-coms-netslicing-information-model], the data model for network topologies developed in [[I-D.ietf-i2rs-yang-network-topo] can be augmented to address the modeling of the transport slice. This is work in progress for next version of this document 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations TBD 9. 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. Rokui, et al. Expires January 3, 2020 [Page 24] Internet-Draft draft-rokui-5G-transport-slice July 2019 [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.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. [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, . Rokui, et al. Expires January 3, 2020 [Page 25] Internet-Draft draft-rokui-5G-transport-slice July 2019 [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.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 Rokui, et al. Expires January 3, 2020 [Page 26] Internet-Draft draft-rokui-5G-transport-slice July 2019 Shunsuke Homma NTT 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585 Japan Email: homma.shunsuke@lab.ntt.co.jp Diego R. Lopez Telefonica I+D Spain Email: diego.r.lopez@telefonica.com Xavier de Foy InterDigital Inc. Canada Email: Xavier.Defoy@InterDigital.com Luis M. Contreras-Murillo Telefonica I+D Spain Email: luismiguel.contrerasmurillo@telefonica.com Jose J. Ordonez-Lucena Telefonica I+D Spain Email: joseantonio.ordonezlucena@telefonica.com Pedro Martinez-Julia NICT Japan Email: pedro@nict.go.jp Rokui, et al. Expires January 3, 2020 [Page 27] Internet-Draft draft-rokui-5G-transport-slice July 2019 Mohamed Boucadair Orange France Email: mohamed.boucadair@orange.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 Rokui, et al. Expires January 3, 2020 [Page 28]