[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/