Internet DRAFT - draft-rokui-5g-transport-slice
draft-rokui-5g-transport-slice
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,
<https://www.rfc-editor.org/info/rfc7297>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049,
DOI 10.17487/RFC8049, February 2017,
<https://www.rfc-editor.org/info/rfc8049>.
[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,
<https://www.rfc-editor.org/info/rfc8453>.
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, <https://www.rfc-editor.org/info/rfc8466>.
[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,
<http://ftp.3gpp.org//Specs/
archive/28_series/28.530/28530-f10.zip>.
[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, <http://ftp.3gpp.org//Specs/
archive/28_series/28.531/28531-g20.zip>.
[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,
<https://www.3gpp.org/ftp/Specs/
archive/28_series/28.540/28540-g00.zip>.
[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,
<http://www.3gpp.org/ftp//Specs/
archive/28_series/28.541/28541-g10.zip>.
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]
