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