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

Versions: 00 01 02 03 04

NONE                                                             L. Geng
Internet-Draft                                              China Mobile
Intended status: Informational                              S. Kuklinski
Expires: September 6, 2018                                        Orange
                                                                L. Qiang
                                                     Huawei Technologies
                                                           S. Matsushima
                                                                Softbank
                                                                A. Galis
                                               University College London
                                                         Luis. Contreras
                                                              Telefonica
                                                           March 5, 2018


Problem Statement of Common Operation and Management of Network Slicing
                  draft-geng-coms-problem-statement-04

Abstract

   This document discusses the problem statement of Common Operation and
   Management of Network Slicing (COMS).  The purpose of this document
   is to identify the problem space of COMS and discuss the approach
   COMS is using to match the top-down network slice management concern
   with the underlay technologies.  Furthermore, the role of a common
   information model is introduced and corresponding design principles
   are also discussed.

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







Geng, et al.            Expires September 6, 2018               [Page 1]


Internet-Draft                                                March 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
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The Concept of COMS and Problem Space . . . . . . . . . . . .   4
   3.  How Top-down Matches with Bottom-up approach  . . . . . . . .   6
   4.  Resources under Supervision of COMS . . . . . . . . . . . . .   7
     4.1.  Connectivity Resources  . . . . . . . . . . . . . . . . .   7
     4.2.  Computing Resources . . . . . . . . . . . . . . . . . . .   8
     4.3.  Storage Resources . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Service Function  . . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The concept of network slicing is not new but energized greatly under
   the 5G work in 3GPP.  It is expected that further 5G network should
   be capable of providing dedicated private network for different
   verticals according to their specific requirements, which are created
   by diversity of new services such as high definition (HD) video,
   virtual reality (VR) and V2X applications.  Looking at the
   development of future network, no matter the service is connected via
   5G cellular RAN, FTTx optical access network or other dedicated
   connections, this resource dedication has become a fundamental
   enabler for services requiring extreme quality of user experience.
   The best effort transport is not good enough as both subscribers and



Geng, et al.            Expires September 6, 2018               [Page 2]


Internet-Draft                                                March 2018


   application providers are looking for and willing to pay for certain
   level of dedication.  Therefore it is inevitable for service
   providers (i.e.  Telecommunication infrastructure owners) to rethink
   the means of management and operation of their networks, which should
   support end-to-end slicing capabilities.

   The requirements from different verticals may be extremely
   diversified.  Typical examples includes high bandwidth, low latency,
   high level of isolation, specific security and encryption
   requirements and etc.  These requirements may also change dynamically
   along time since the services of certain industry vertical change
   very fast, and sometime spontaneously (i.e. burst bandwidth/latency
   requirement from on-line shopping provider during sale period).  It
   is expected that the configuration of certain network slice instances
   are very dynamic in a case-by-case manner.  Meanwhile, there are many
   technology options to fulfil particular requirements depending on
   considerations on many aspects including cost, TTM and etc.  The
   diversity of both requirements and technology options make the
   management of network slices significantly heterogeneous.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

1.2.  Terminology

   Network Slice - A set of infrastructure resources and service
   functions that has attributes specifically designed to meet the needs
   of an industry vertical or a service.

   Network Slicing - A management mechanism that Network Slice Provider
   can use to allocate dedicated infrastructure resources and service
   functions to Network Slice Tenant.

   Network Slice Provider - A network slice provider (NSP), typically a
   telecommunication service provider, is the owner or tenant of the
   infrastructures from which network slices can be created.  The
   network slice provider takes the responsibilities of managing,
   orchestrating and monitoring the corresponding resources to implement
   a network slice and provide the Network slice tenant certain level of
   management capability.

   Network Slice Tenant - A network slice tenant (NST) is the user of
   specific network slice, in which customized services are hosted.
   Network slice tenants can make requests of the creation of new
   network slice through a COMS service model.  This request will be



Geng, et al.            Expires September 6, 2018               [Page 3]


Internet-Draft                                                March 2018


   delivered to network slice orchestrator via service delivery model
   for service implementation purposes.

2.  The Concept of COMS and Problem Space

   COMS is a management mechanism where an NSP can use to allocate
   dedicated network infrastructures and service functions to an NST.
   This dedication may be presented in various forms depending on
   specific NSP's network availabilities.  Typical examples include
   physical and logical isolation of network connectivity, bare metal or
   virtualized computing resources, dedicated storage resources and
   specific pre-define service functions such as NAT server, SDN
   controller and etc.  COMS gives the NSP full flexibility to either
   logically or physically lease a partition of their resources to the
   NST with required functionalities and performances.  It is
   anticipated that new business models may be created with COMS.  More
   flexible, elastic and modularized resource allocation capability
   enables a network slice to be offered as a service to end users in a
   much finer granularity.  For instance, a network with certain
   bandwidth and latency guarantee and dedicated connections to required
   data center nodes can be provided as turn-key service to a HD video
   content provider who would like to implement it service on the NSP's
   network.  In this model, the NSP will use COMS to coordinate the
   underlay heterogeneous resources to deliver this network slice as a
   service (NSaaS).


























Geng, et al.            Expires September 6, 2018               [Page 4]


Internet-Draft                                                March 2018


                           Customer Service
             +-----------+ Interface (CSI)  +-----------+
             |    NST    +------------------+    NSP    |
             |(Customer) |                  |           |
             +-----------+                  +------+----+
                                                   |
                                                   | Service Delivery
                                                   | Interface (SDI)
                                                   |
       +-----------------------------------+-------------+
       |        Network Slice Orchestrator (NSO)         |
       +---------|------------+-------------------+------+
             SDI |            |                   |
          +------|-----+      |                   |
          |   NSO      |      |                   |
          +------------+      |                   |
                           Network Configuration Model
     ~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~
      Available NS-aware      |                   |
        Technologies          |                   |
      +-----------------------+-+    +------------+------------+
      |Controller/Orchestrator/ |    |Controller/Orchestrator/ |
      |Manager of Implementation|    |Manager of Implementation|
      |Technology A             |    |Technology B             |
      +---------------+---------+    +-------------+-----------+
                      |                            |
                      | Device Configuration Model |
      +---------------+----------------------------+-------------+
      |             Underlying Network Resources/Functions       |
      +----------------------------------------------------------+

                    Figure 1: Schematic Diagram of COMS

   Figure 1 illustrated the concept of how COMS is implemented within a
   heterogeneous network.  A customer (NST) request NSaaS via service
   model.  The service model describe the network slice in user's
   language.  This model is technology-agnostic.  A NSP translates the
   service profile to service delivery model which describe how a NSP
   engineering it's resource for the service.  The service delivery
   model is sent to the network slice orchestrator, where it is further
   decomposed to network configuration model in different technology
   domains.  Finally the device configuration models are used to setup
   the parameters of the underlay infrastructures and functions.

   COMS focuses on the cross-domain management of network infrastructure
   and service functions which are considered as elements of a given
   network slice.  COMS will only design service model and service
   delivery models for network slice services.  It will not try to



Geng, et al.            Expires September 6, 2018               [Page 5]


Internet-Draft                                                March 2018


   duplicate works in existing WGs regarding network configuration
   models and device configuration models.  The associated the slice-
   level operation, administration and maintenance will also be the
   concern of COMS.

3.  How Top-down Matches with Bottom-up approach

   COMS indeed takes a top-down approach to look at the management of
   network, where the requirement of network slice and its management
   are triggered by new vertical industry services and business model.
   However, this top-down approach does not directly ask for any
   specific new forwarding technology.  It asks for a slice-level
   management which coordinates various underlay technology domains to
   enable NSaaS.  Nowadays, existing IETF technologies either evolves
   (e.g.  DETNET) or naturally support (e.g.  VPN) certain resource
   dedication mechanism in a bottom-up view.  This is in line with the
   concept of network slicing.  However, A big problem is that IETF has
   little tools for cross-domain management
   [draft-arkko-arch-virtualization], without which the creation of an
   end-to-end network slicing would not be possible.  COMS makes the
   convergence between top-down and bottom-up view of network slicing.

                 +--------------------------------------+
                 |  Service & Service Delivery Model    |
                 |                                      |
                 +--------------------------------------+
                   Provide Design  /|\
                     Guidance       |
                     +-----------------------------+
                     |                             |
                     |    COMS Information Model   |
                     |                             |
                     +-----------------------------+
                        |           |           |
                        |          \|/          |
                        |   +--------------+   \|/
                        |   | Subset  +------------------+
                       \|/  |   1     |    |  Subset     |
                  +-----------+       |    |    3        |
                  | Subset  | |       |    |             |
                  |   2     | |       +------------------+
                  |         | |            |
                  |         +--------------+
                  |           |
                  +-----------+

             Figure 2: COMS Information Model Design Principle




Geng, et al.            Expires September 6, 2018               [Page 6]


Internet-Draft                                                March 2018


   The information model of COMS serves as the key element for this
   convergence.  It provides guidance for the design of service deliver
   model.  And it also provides slice-level abstraction reference for
   existing IETF forwarding technologies.  This mean the although COMS
   does not directly define network configuration model for each domain.
   The models defined elsewhere should refer to COMS information model
   in order to be used as a part of a network slice.  This information
   model is than a comprehensive set of abstraction.  Each single
   technology typically refer to a subset of this information model for
   slice-level abstraction process.

4.  Resources under Supervision of COMS

   In order to provide cost-effective and efficient network slice
   configuration, service provider needs to understand specifically the
   components it can make use to create a network slice instance and how
   these components map with the customer requirements.  These
   components include both infrastructure resources and service
   functions.  There are many existing technologies which focus on the
   management of those entities.  For example, various type of domain
   SDN controllers supervise the connectivity resources within each
   technology or geographical domains, and MANO supervises the NFV
   infrastructures.  In contrast, COMS provides an end-to-end management
   mechanism which integrate various underlay technology domains to
   create a network slice.  It oversees all these resources and decides
   the placement of specific resources according to certain path and
   topology constraints.

   COMS does not have any particular constraints on what type of
   resources it manages.  This is defined by its information model and
   will have to adapt to what a NST really needs.  Meanwhile, whether a
   certain type of resource is available to be used in COMS is subjected
   to NSP's policy.  However, for the ease of management and operation,
   it is worthy to have a guideline to categorize the common resources
   that NSP may offer to NST as a network slice service.  This section
   endeavours to provide a prototype catalogue of the resource
   components for network slice creation.  More detailed description can
   be found in [draft-qiang-coms-netslicing-information-model-02] In
   general, the components that an NSP can use to create a network slice
   include connectivity, computing, storage infrastructures and service
   functions.

4.1.  Connectivity Resources

   Connectivity is one of the essential components for a network slice.
   It can be as simple as a best effort point-to-point VPN or a physical
   link using a dedicated wavelength.  It may also have more complex




Geng, et al.            Expires September 6, 2018               [Page 7]


Internet-Draft                                                March 2018


   topology with other specific requirements including bandwidth,
   latency and etc.

4.2.  Computing Resources

   If an NST would like to host virtualized functions in a network
   slice, it may be interested in asking for specific computing resource
   including both bare metal servers and virtual machines.

4.3.  Storage Resources

   It is necessary for NSP to provide storage components in a network
   slice since NSTs may want to host contents on dedicated resources.
   Meanwhile, NSP may also prefer to use dedicated storage for specific
   service policies, authentication information and other management
   profiles.

4.4.  Service Function

   Many dedicated service/network functions, either physical or virtual,
   may requested by a NST.  Typical example include common network
   functions as DHCP server, DNS, NAT, Firewall, SDN controller.
   Application- level functions may also exist in a network slice, such
   as session management, mobility management and etc.  NSP should be
   able to provide such service function blocks according to NST's
   request.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   TBD

7.  Acknowledgements

   The author would like to thank Benoit Claise, Xavier de Foy,Warren
   Kumari, Jari Arkko and Jeff Tantsura for discussion on this work.

8.  References

8.1.  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,
              <https://www.rfc-editor.org/info/rfc2119>.



Geng, et al.            Expires September 6, 2018               [Page 8]


Internet-Draft                                                March 2018


8.2.  Informative References

   [draft-arkko-arch-virtualization]
              "Considerations on Network Virtualization and Slicing",
              <https://tools.ietf.org/html/
              draft-arkko-arch-virtualization-00>.

   [draft-qiang-coms-netslicing-information-model-02]
              "Considerations on Network Virtualization and Slicing",
              <https://datatracker.ietf.org/doc/
              draft-qiang-coms-netslicing-information-model/>.

Authors' Addresses

   Liang Geng
   China Mobile
   Beijing  100053
   China

   Email: gengliang@chinamobile.com


   Slawomir Kuklinski
   Orange

   Email: slawomir.kuklinski@orange.com


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

   Email: qiangli3@huawei.com


   Satoru Matsushima
   Softbank

   Email: kiran.makhijani@huawei.com










Geng, et al.            Expires September 6, 2018               [Page 9]


Internet-Draft                                                March 2018


   Alex Galis
   University College London
   London
   U.K.

   Email: a.galis@ucl.ac.uk


   Luis Miguel Contreras Murillo
   Telefonica

   Email: luismiguel.contrerasmurillo@telefonica.com







































Geng, et al.            Expires September 6, 2018              [Page 10]


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