Problem Statement of Common Operation and Management of Network Slicing

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.

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.

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 manager via service delivery model for service implementation purposes.

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

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

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

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.

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 In general, the components that an NSP can use to create a network slice include connectivity, computing, storage infrastructures and service functions.

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.

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.

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.

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.

This document makes no request of IANA.

TBD

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