Network Working Group                                           L. Qiang
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                   L. Geng
Expires: August 6, 2018                                     China Mobile
                                                        K. Makhijani, ed
                                                     Huawei Technologies
                                                               X. de Foy
                                                       InterDigital Inc.
                                                                A. Galis
                                               University College London
                                                       February 02, 2018

  The Use Cases of Common Operation and Management of Network Slicing


   The Common Operation and Management of network Slicing (COMS) intends
   to provide a comprehensive approach for the overall operation and
   management of network slicing in the scope if IETF.  The system is
   designed in a hierarchical and inter-operative manner.  COMS is
   capable of recursive adaption in a hierarchical network management
   system.  It is also independent of data plane technologies used in
   different administrative domains.  Both network slice operator and
   network slice tenant may benefit for COMS for the purpose of slice
   management and maitenance.The purpose of this document is to discuss
   the use cases of COMS in different views.

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

   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 August 6, 2018.

Qiang, et al.            Expires August 6, 2018                 [Page 1]

Internet-Draft              Abbreviated-Title              February 2018

Copyright Notice

   Copyright (c) 2018 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
   ( 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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Heterogeneous Resource Management for Network Slicing . . . .   4
     2.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Combination of Networking and Computing . . . . . . .   4
       2.1.2.  Technology Diversity of Network Infrastructure  . . .   5
       2.1.3.  Network and Service Functions Variety . . . . . . . .   6
     2.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .   6
   3.  Interoperation between Multiple Slice-aware Administrative
       Domain  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .   6
     3.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .   7
   4.  End-to-end Orchestration of Network Slicing . . . . . . . . .   7
     4.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .   7
       4.1.1.  Resource Registration . . . . . . . . . . . . . . . .   7
       4.1.2.  Life-cycle Management . . . . . . . . . . . . . . . .   8
       4.1.3.  Network Slice Template and Repository . . . . . . . .   9
     4.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .   9
   5.  Customized OAM for Network Slice Tenant . . . . . . . . . . .   9
     5.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .   9
     5.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .  10
   6.  Interaction with 3GPP Network Slicing . . . . . . . . . . . .  10
     6.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .  10
     6.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .  10
   7.  Network Slice FCAPS . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .  11
     7.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .  11
   8.  Network Slice Stiching and Recursion  . . . . . . . . . . . .  11
     8.1.  Use Case Introduction . . . . . . . . . . . . . . . . . .  11
     8.2.  Use Case Analysis . . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11

Qiang, et al.            Expires August 6, 2018                 [Page 2]

Internet-Draft              Abbreviated-Title              February 2018

   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Network Slicing is a mechanism which a network slice provider can use
   to allocate dedicated infrastructures and services from shared
   systems to a network slice tenant.  COMS acts as a technology-
   independent and resource-centric approach according to which the
   operation and management of network slice can be performed.

   This document lists the use cases of COMS from various OAM aspects of
   network slicing.  It provides a general reference of how COMS may be
   used from both network slice provider and network slice tenant
   viewpoint.  The COMS community (the proposed WG) will consider these
   use cases and decide which related technology is going to be
   investigated under the problem scope of COMS.

   All of the use cases are introduced in this document followed by a
   brief analysis regarding the relationship with COMS.  As the document
   is being continuously worked on, the list of use cases is as follows:

   o  Heterogeneous Resource Management for Network Slicing

   o  Interoperation between Multiple Slice-aware Administrative Domain

   o  End-to-end Orchestration of Network Slicing

   o  Customized OAM for Network Slice Tenant

   o  Interaction with 3GPP Network Slicing

   o  Network Slice FCAPS - to be specified in -01 version

   o  Network Slice Stiching and Recursion - to be specified in -01

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Qiang, et al.            Expires August 6, 2018                 [Page 3]

Internet-Draft              Abbreviated-Title              February 2018

2.  Heterogeneous Resource Management for Network Slicing

2.1.  Use Case Introduction

   Network slice is a specific partition of resources.  The resources
   are deliberately associated together for the purpose of fulfilling
   both functional and performance requirements of various applications.
   Heterogeneity is the nature of those underlay resources based-on
   which network slices are created.  In order to provide end-to-end
   orchestration of network slices, it is required that all resources
   are manageable by a network slice provider.  COMS will be used as the
   fundamental technology for the purpose of heterogeneous resource

2.1.1.  Combination of Networking and Computing

   Networking used to be the absolute major asset and resources of a
   telecommunication service provider.  As the rapid development of
   cloud computing and NFV technology in recent years, computing
   infrastructures such as data center, distributed edge cloud, CDN and
   cache facilities start to play more and more important roles.
   Nowadays, not only is the amount of data centers dramatically growing
   in service providers' network, but also network/service functions are
   migrating to NFV deployment, which depends heavily on common
   computing and storage resources.  An obvious trend of more
   interactive relationship between networking and computing resources
   (computing resource referred in this section also includes storage
   resources) deployment is seen worldwide.

   The goal of network slicing is to provide a "turn-key" solution for
   vertical application provider, where certain performance and
   functional demands can be met according to specific SLAs.  This is
   achieved by providing infrastructure and functional dedication to
   vertical application providers.  It is expected that a vertical
   application provider, as a network slice tenant, will purchase a
   network slice which is equipped with both preferred connectivity
   topology and associated computing/storage resources.  Hence, the
   vertical application provider is able to deploy whatever applications
   according to its preference.

   Relying on the underlay network infrastructure, computing resource
   has become an inevitable part of the network slice.  In general, it
   may comes in various forms in a manner of IaaS as follows.

   o  Bare metal equipment with required specifications

   o  Hypervisor-based virtual machine

Qiang, et al.            Expires August 6, 2018                 [Page 4]

Internet-Draft              Abbreviated-Title              February 2018

   o  Container-based infrastructures

   o  Other customized type of presentation of computing resources

   Under the regime of network slicing, computing (including storage)
   resources provided in any form above need to be specified with
   geographical or logical location information.  These computing
   resources may distributed among the network slice topology as
   terminal or intermediate network nodes.  This location information is
   essential for the purpose of associating these resources with
   connectivity components within a network slice.

   It is not always easy to jointly manage both computing resources and
   the underlay networking.  Connectivity is normally supervised by
   using traditional EMS of the connected devices, or by using more
   advanced SDN approaches for more advanced systems.  In contrast,
   computing resources are typically managed by VIMs.  A manager who
   understands both EMS/SDN controller and VIMs is requirement for
   overall orchestration of an end-to-end network slice.

2.1.2.  Technology Diversity of Network Infrastructure

   Due to architectural and commercial reasons, the underlay technology
   choices for different administrative domains are unlikely to be the
   same.  For example, regional administrative domains may be favor of
   choosing single-vendor solutions for its backbone network.  This
   minimize the complexity of intra-domain OAM.  However, adjacent
   regional administrative domains may use equipments from different
   vendors.  This makes the overall backbone network infrastructure
   resources heterogeneous.  The technology diversity of the resource
   consisting a network slice mainly results from the following reasons.

   o  Various technology choices for access, aggregation and backbone

   o  Legacy equipments due to deployment iteration

   o  Administrative concerns caused by geographical reasons

   o  Vendor-specific technology for customized deployment

   It is common for an end-to-end network slice asking for resources
   from various administrative domains with distinctive technology
   options.  This include data plane, control plane and management plane
   technologies.  COMS, as an management tool, can be used for operation
   and management of such systems.

Qiang, et al.            Expires August 6, 2018                 [Page 5]

Internet-Draft              Abbreviated-Title              February 2018

2.1.3.  Network and Service Functions Variety

   A complete network slice may consist of many types of network ans
   service functions.  This functions are likely to be deployed either
   in NFV or physical forms.  In practice, virtualized network functions
   are managed by VNFM under MANO system, whilst physical network
   functions are managed by resource management system (RMS).
   Meanwhile, the management plane of service functions is even more
   diversified which may associated with extremely customized service
   management platforms.

   In order to make network and service function usable and manageable
   as a part of network slice, it is necessary to have an overall
   management system on which the orchestration of such functions can
   rely.  Existing technology such as SFC already provides a
   comprehensive solution for the purpose of service-level integration.
   It would be interesting to investigate how underlay network
   infrastructure can better serve and map with requirements of
   particular SFC or interconnection between SFCs under network slice
   regime.  Such system should be capable of associating service
   function resources to required network infrastructure, making the
   formation of an end-to-end network slice possible.

2.2.  Use Case Analysis

   It is always preferred to have more diversified resources on which
   network slices can be built.  Heterogeneity becomes an inevitable
   issue caused by this nature of variety.  At present, countless
   management systems are being used by service providers for different
   types of resource domains.  COMS may help to aggregate and coordinate
   the management plane of such systems and provide unified slice-level

3.  Interoperation between Multiple Slice-aware Administrative Domain

3.1.  Use Case Introduction

   As mentioned in section 2, the slice orchestrator need to supervise
   heterogeneous resources in various administrative domains in response
   to diversified demand from the network slice tenants.  For example,
   the network slice orchestrator needs to supervise some heterogeneous
   technology domains, which obviously have separated administrative
   systems.  Examples include optical transport network, IP routing
   network in terms of network infrastructure and SFCs in terms of
   service function.  Administrative domain may also isolated for
   technology-evolution reasons.  For instance, the slice orchestrator
   is necessary to be compatible with either controller-based networks
   or EMS-based networks.  Furthermore, as computing plays more and more

Qiang, et al.            Expires August 6, 2018                 [Page 6]

Internet-Draft              Abbreviated-Title              February 2018

   significant role as infrastructure resource, the requirement of
   coordinating between networking and computing in management plane is

3.2.  Use Case Analysis

   Either it is a green field implementation or not, given the
   heterogeneity property of resources, the administrative domains can
   only be more diversified.  Meshed interoperation between these
   administrative domains is infeasible.  Hence, a higher level
   management entity is one of the most cost effective and straight
   forward solution.

4.  End-to-end Orchestration of Network Slicing

4.1.  Use Case Introduction

   When a network slice tenant purchases a network slice service, it
   does not necessarily know the what underlay resources exactly are
   allocated for the purpose of the network slice creation.  It is the
   network slice orchestrator who takes care of this process.  As the
   network slice orchestrator receives network slice service delivery
   model from service provider's OSS/BSS, it executes slice-level
   operation and management accordingly.  End-to-end orchestration is an
   essential part of this process.

   The main functionality of end-to-end network slice orchestration may
   include the following aspects:

   1.  Coordinating underlay network infrastructure and service function

   2.  Life-cycle management, which includes the common operation of
       network slice creation, activation/de-activation, modification,
       deletion and status monitoring.

   3.  Pre-defining templates of common types of network slices and
       provide repository for network slice instances created by
       templates or full customization

4.1.1.  Resource Registration

   In the process of end-to-end orchestration of network slice, resource
   registration is one of the fundamental prerequisite.  The network
   slice orchestrator needs to know exactly what resources are available
   under the overall management.  The information for resource
   registration may include the the following aspects:

Qiang, et al.            Expires August 6, 2018                 [Page 7]

Internet-Draft              Abbreviated-Title              February 2018

   o  The type of resources (whether it is a connectivity, computing,
      storage or pre-defined network/sevice function)

   o  The physical/logical location of the resources

   o  Data plane and control plane technology capabilities

   o  Performance capabilities

   o  Availability information

   o  Domain topology information

   The network slice orchestrator can only use registered resources in
   the process of network slice creation.  Any change of resource
   information caused by equipment upgrading, new deployment or
   abolishing of legacy system need to be reported to the network slice

4.1.2.  Life-cycle Management

   It is important that the network slice orchestrator can continuously
   manage the creation, activation/de-activation, modification, deletion
   and status monitoring processes of the network slice for a complete
   life cycle.  In general, a network slice profile can be created in
   several ways:

   o  A network slice profile can be created according to the network
      slice templates.  In this way, the network slice profile is create
      by direct configuration of the parameters in a pre-defined network
      slice template according to exciting index.

   o  A network slice profile can be created by customized parameter
      index and value.

   In both cases, the value of parameters come from the service delivery
   interface of the network slice orchestrator.  Particularly for the
   latter case, a complete network slice profile is needed from the
   service delivery interface.

   Additionally, the operation of life cycle management also comes from
   the OSS/BSS service delivery model.  After receive such operation
   request, the orchestrator need to map certain them to different
   administrative domains respectively.

Qiang, et al.            Expires August 6, 2018                 [Page 8]

Internet-Draft              Abbreviated-Title              February 2018

4.1.3.  Network Slice Template and Repository

   As mentioned in section 3.1.2, network slice orchestrator can use
   templates to create network slice profiles.  Templates are extremely
   useful in cases where multiple network slice tenants require exact
   same type of network slices.  For example, URLLC is regarded as one
   of the most popular scenario in 5G application.  It would be useful
   to pre-define a URLLC network slice template, to which the network
   slice orchestrator can refer, upon request of network slice tenants.

   A network slice repository make it handy to manage the templates of
   different types.  It also helps to categorize different network slice
   profiles created under given templates.  A category of "Customized
   network slice" might also be useful for the cases where network slice
   is created from scratch.

4.2.  Use Case Analysis

   End-to-end orchestration is the most essential functionality of
   network slicing management.  COMS information model will act as a
   significant reference for resource registration, network slice
   template definition and and the creation of network slice profile.
   At the same time, life-cycle management will be enabled by the COMS
   service delivery model.

5.  Customized OAM for Network Slice Tenant

5.1.  Use Case Introduction

   As a network slice instance is activated, the network slice tenant is
   able to access the network slice and apply intra-slice configuration
   under network slice provider's policies.  This include operation and
   management functionalities, which are likely to be a subset of the
   overall network slice management.  Typical functionalities a network
   slice tenant may prefer to have include the following aspects:

   1.  Network slice life-cycle status monitoring

   2.  Performance dash board of individual/set of resource components
       in a network slice

   3.  Slice-level parameter adjustments under network slice providers'
       policies, strictly avoiding conflicts with other network slices.

   4.  Slice subset operation and management based on COMS at network
       slice provider's permission

Qiang, et al.            Expires August 6, 2018                 [Page 9]

Internet-Draft              Abbreviated-Title              February 2018

5.2.  Use Case Analysis

   The network slice orchestrator has two NBI interfaces respectively.
   One of them is designed for the purpose of customized OAM.  A network
   slice tenant may use this interface to perform the actions listed in
   section 5.1.  COMS is in the position of defining the NBI interface

6.  Interaction with 3GPP Network Slicing

6.1.  Use Case Introduction

   3GPP is the born-place of the concept of 5G network slicing.  However
   in 3GPP, only radio access network and core network are considered as
   the resource pool for network slices.  The transport network is
   modelled as a link between them.  Technically in 3GPP language,
   network slicing does not include transport network.

   In 5G, the requirements of network slicing focus on the guaranteed
   end-to-end quality in terms of Bandwidth (eMBBs), Latency (URLLC) and
   connections (eMTC).  For the purpose of end-to-end network slicing is
   to provide guaranteed service for vertical user.  Transport network
   will also play an important role in this scenario.  One of the most
   straight forward solution for service-guaranteed mapping to the
   sliced 3GPP network is to make the TN also slice-aware.

   As 3GPP SA5 delivers the performance requirements from 3GPP slice
   manager to IETF network slice orchestrator, the orchestrator will
   treat the requirements similarly to a general service delivery model
   received from OSS/BSS.  It is not 3GPP's concern weather IETF is
   using slice or not toe fulfill this requirements

6.2.  Use Case Analysis

   Network slicing is one of the key technology in 5G network.  It is
   important that transport network can provide certain quality
   guarantee, so that the end-to-end network slice run over can fulfill
   the overall requirements.  COMS provides NBI for the purpose of
   gathering transport network requirements.  These requirements will be
   further broken down into underlay systems requirements accordingly,
   where COMS can help the mapping by providing the general information

7.  Network Slice FCAPS

Qiang, et al.            Expires August 6, 2018                [Page 10]

Internet-Draft              Abbreviated-Title              February 2018

7.1.  Use Case Introduction

   This is a place holder for slice-level FCAPS use cases for COMS.  It
   is due to be updated in 01 version of this document

7.2.  Use Case Analysis

8.  Network Slice Stiching and Recursion

8.1.  Use Case Introduction

   This is a place holder for inter-slice operation use cases for COMS.
   It is due to be updated in 01 version of this document

8.2.  Use Case Analysis

9.  IANA Considerations

   This document makes no request of IANA.

10.  Security Considerations

   There is no security consideration in this draft.

11.  Acknowledgements

   The authors would like to acknowledge Benoit Claise, Warren Kumari
   and Adrian Farrel for valuable discussions.

12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

Authors' Addresses

   Li Qiang
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095


Qiang, et al.            Expires August 6, 2018                [Page 11]

Internet-Draft              Abbreviated-Title              February 2018

   Liang Geng
   China Mobile
   Beijing  100053


   Kiran Makhijani
   Huawei Technologies
   2890 Central Expressway
   Santa Clara  CA 95050


   Xavier de Foy
   InterDigital Inc.
   1000 Sherbrooke West


   Alex Galis
   University College London


Qiang, et al.            Expires August 6, 2018                [Page 12]