Internet-Draft draft-rokui-5G-network-slice November 2020
Rokui, et al. Expires 6 May 2021 [Page]
Workgroup:
Individual
Internet-Draft:
draft-rokui-5g-ietf-network-slice-00
Published:
Intended Status:
Informational
Expires:
Authors:
R. Rokui
Nokia
S. Homma
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
Huawei Canada
H. Yu
Huawei Canada

IETF Network Slice for 5G and its characteristics

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.

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 6 May 2021.

▲

Table of Contents

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:

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 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)
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.


    <---------------- 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".

Referring to Figure 1, for each 5G E2E network slice, the following 5G IETF network Slices are needed:

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.


    |---------------------------------------------------------|
    |              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.
  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
  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     :
  :............:  :...............:  |  :...............:
  .... | ................ | ........ | .......... | ..... 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:

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:

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

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 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.

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):

  • "Connection group C" connects BBU1 and BBU2 to AMF1 with SLO-C
  • "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.

             <------- 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 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/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
       +--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
    +--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:


                        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:

10. Informative References

[I-D.boucadair-connectivity-provisioning-protocol]
Boucadair, M., Jacquenet, C., Zhang, D., and P. Georgatsos, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, Internet-Draft, draft-boucadair-connectivity-provisioning-protocol-15, , <http://www.ietf.org/internet-drafts/draft-boucadair-connectivity-provisioning-protocol-15.txt>.
[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", Work in Progress, Internet-Draft, draft-contreras-teas-slice-nbi-03, , <http://www.ietf.org/internet-drafts/draft-contreras-teas-slice-nbi-03.txt>.
[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", Work in Progress, Internet-Draft, draft-homma-slice-provision-models-00, , <http://www.ietf.org/internet-drafts/draft-homma-slice-provision-models-00.txt>.
[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", Work in Progress, Internet-Draft, draft-ietf-i2rs-yang-network-topo-20, , <http://www.ietf.org/internet-drafts/draft-ietf-i2rs-yang-network-topo-20.txt>.
[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", Work in Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-04, , <http://www.ietf.org/internet-drafts/draft-ietf-teas-actn-vn-yang-04.txt>.
[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", Work in Progress, Internet-Draft, draft-king-teas-applicability-actn-slicing-04, , <http://www.ietf.org/internet-drafts/draft-king-teas-applicability-actn-slicing-04.txt>.
[I-D.nsdt-teas-ietf-network-slice-definition]
Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "Definition of IETF Network Slices", Work in Progress, Internet-Draft, draft-nsdt-teas-ietf-network-slice-definition-00, , <http://www.ietf.org/internet-drafts/draft-nsdt-teas-ietf-network-slice-definition-00.txt>.
[I-D.nsdt-teas-ns-framework]
Gray, E. and J. Drake, "Framework for Transport Network Slices", Work in Progress, Internet-Draft, draft-nsdt-teas-ns-framework-04, , <http://www.ietf.org/internet-drafts/draft-nsdt-teas-ns-framework-04.txt>.
[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", Work in Progress, Internet-Draft, draft-qiang-coms-netslicing-information-model-02, , <http://www.ietf.org/internet-drafts/draft-qiang-coms-netslicing-information-model-02.txt>.
[I-D.wd-teas-transport-slice-yang]
Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data Model for Transport Slice NBI", Work in Progress, Internet-Draft, draft-wd-teas-transport-slice-yang-02, , <http://www.ietf.org/internet-drafts/draft-wd-teas-transport-slice-yang-02.txt>.
[RFC7297]
Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, , <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, , <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, , <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, , <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)", , <http://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g20.zip>.
[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)", , <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)", , <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)", , <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)", , <http://www.3gpp.org/ftp//Specs/archive/28_series/28.541/28541-g10.zip>.

Authors' Addresses

Reza Rokui
Nokia
Canada
Shunsuke Homma
NTT
3-9-11, Midori-cho, Tokyo
180-8585
Japan
Xavier de Foy
InterDigital Inc.
Canada
Luis M. Contreras
Telefonica
Spain
Philip Eardley
BT
United Kingdom
Kiran Makhijani
Futurewei Networks
United States of America
Hannu Flinck
Nokia
Finland
Rainer Schatzmayr
Deutsche Telekom
Germany
Ali Tizghadam
TELUS Communications Inc
Canada
Christopher Janz
Huawei Canada
Canada
Henry Yu
Huawei Canada
Canada