| 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
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.
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 (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.
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.
Please refer to [I-D.homma-slice-provision-models] as well.
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:
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.
<-------------- 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
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.
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.
|----------------------------------------------------|
| 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
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:
|-----| (---------------------)
| 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:
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 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
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.
<------------------ 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
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.
<-------------------- 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
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;
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.
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.
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:
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.
^
| (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.
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 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:
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:
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:
It contains information such as transport slice name, transport slice ID etc. The details will be provided in next version of this draft.
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.
As per Section 4, a transport slice will contain one or more transport-slice-networks.
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.
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.
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:
The summary of these policies will be provided here. The details will be provided in next version of this draft.
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.
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.
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.
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.
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.
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
This memo includes no request to IANA.
TBD