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.

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

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

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

                      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

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

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

8.2. Informative References

Authors' Addresses