<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-qiang-coms-use-cases-00" ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">The Use Cases of Common Operation and
    Management of Network Slicing</title>

    <author fullname="Li Qiang" initials="L." surname="Qiang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>

          <region/>
        </postal>

        <phone/>

        <email>qiangli3@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>

          <region/>
        </postal>

        <phone/>

        <email>gengliang@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Kiran Makhijani" initials="K." surname="Makhijani, ed">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>2890 Central Expressway</street>

          <city>Santa Clara</city>

          <code>CA 95050</code>

          <country>USA</country>

          <region/>
        </postal>

        <phone/>

        <email>kiran.makhijani@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Xavier de Foy" initials="X." surname="de Foy">
      <organization>InterDigital Inc.</organization>

      <address>
        <postal>
          <street>1000 Sherbrooke West</street>

          <city>Montreal</city>

          <code/>

          <country>Canada</country>

          <region/>
        </postal>

        <phone/>

        <email>Xavier.Defoy@InterDigital.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Alex Galis" initials="A." surname="Galis">
      <organization>University College London</organization>

      <address>
        <postal>
          <street/>

          <city>London</city>

          <code/>

          <country>U.K.</country>

          <region/>
        </postal>

        <phone/>

        <email>a.galis@ucl.ac.uk</email>

        <uri/>
      </address>
    </author>

    <date day="02" month="February" year="2018"/>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>

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

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

      <t><list style="symbols">
          <t>Heterogeneous Resource Management for Network Slicing</t>

          <t>Interoperation between Multiple Slice-aware Administrative
          Domain</t>

          <t>End-to-end Orchestration of Network Slicing</t>

          <t>Customized OAM for Network Slice Tenant</t>

          <t>Interaction with 3GPP Network Slicing</t>

          <t>Network Slice FCAPS - to be specified in -01 version</t>

          <t>Network Slice Stiching and Recursion - to be specified in -01
          version</t>
        </list></t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

    <section title="Heterogeneous Resource Management for Network Slicing">
      <section title="Use Case Introduction">
        <t>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
        management.</t>

        <section title="Combination of Networking and Computing">
          <t>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.</t>

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

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

          <t><list style="symbols">
              <t>Bare metal equipment with required specifications</t>

              <t>Hypervisor-based virtual machine</t>

              <t>Container-based infrastructures</t>

              <t>Other customized type of presentation of computing
              resources</t>
            </list>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.</t>

          <t>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.</t>
        </section>

        <section title="Technology Diversity of Network Infrastructure">
          <t>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.</t>

          <t><list style="symbols">
              <t>Various technology choices for access, aggregation and
              backbone networks</t>

              <t>Legacy equipments due to deployment iteration</t>

              <t>Administrative concerns caused by geographical reasons</t>

              <t>Vendor-specific technology for customized deployment</t>
            </list>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.</t>
        </section>

        <section title="Network and Service Functions Variety">
          <t>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.</t>

          <t>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.</t>
        </section>
      </section>

      <section title="Use Case Analysis">
        <t>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
        OAM.</t>
      </section>
    </section>

    <section title="Interoperation between Multiple Slice-aware Administrative Domain">
      <section title="Use Case Introduction">
        <t>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
        significant role as infrastructure resource, the requirement of
        coordinating between networking and computing in management plane is
        obvious.</t>
      </section>

      <section title="Use Case Analysis">
        <t>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.</t>
      </section>
    </section>

    <section title="End-to-end Orchestration of Network Slicing">
      <t/>

      <section title="Use Case Introduction">
        <t>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.</t>

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

        <t><list style="numbers">
            <t>Coordinating underlay network infrastructure and service
            function resources</t>

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

            <t>Pre-defining templates of common types of network slices and
            provide repository for network slice instances created by
            templates or full customization</t>
          </list></t>

        <section title="Resource Registration">
          <t>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:</t>

          <t><list style="symbols">
              <t>The type of resources (whether it is a connectivity,
              computing, storage or pre-defined network/sevice function)</t>

              <t>The physical/logical location of the resources</t>

              <t>Data plane and control plane technology capabilities</t>

              <t>Performance capabilities</t>

              <t>Availability information</t>

              <t>Domain topology information</t>
            </list>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 orchestrator.</t>
        </section>

        <section title="Life-cycle Management">
          <t>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:</t>

          <t><list style="symbols">
              <t>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.</t>

              <t>A network slice profile can be created by customized
              parameter index and value.</t>
            </list>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.</t>

          <t>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.</t>
        </section>

        <section title="Network Slice Template and Repository">
          <t>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.</t>

          <t>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.</t>
        </section>
      </section>

      <section title="Use Case Analysis">
        <t>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.</t>
      </section>
    </section>

    <section title="Customized OAM for Network Slice Tenant">
      <section title="Use Case Introduction">
        <t>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:</t>

        <t><list style="numbers">
            <t>Network slice life-cycle status monitoring</t>

            <t>Performance dash board of individual/set of resource components
            in a network slice</t>

            <t>Slice-level parameter adjustments under network slice
            providers' policies, strictly avoiding conflicts with other
            network slices.</t>

            <t>Slice subset operation and management based on COMS at network
            slice provider's permission</t>
          </list></t>
      </section>

      <section title="Use Case Analysis">
        <t>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</t>
      </section>
    </section>

    <section title="Interaction with 3GPP Network Slicing">
      <section title="Use Case Introduction">
        <t>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.</t>

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

        <t>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</t>
      </section>

      <section title="Use Case Analysis">
        <t>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
        model.</t>
      </section>
    </section>

    <section title="Network Slice FCAPS">
      <t/>

      <section title="Use Case Introduction">
        <t>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</t>
      </section>

      <section title="Use Case Analysis">
        <t/>
      </section>
    </section>

    <section title="Network Slice Stiching and Recursion">
      <t/>

      <section title="Use Case Introduction">
        <t>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</t>
      </section>

      <section title="Use Case Analysis">
        <t/>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There is no security consideration in this draft.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge Benoit Claise, Warren Kumari
      and Adrian Farrel for valuable discussions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>
  </back>
</rfc>
