| 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
draft-qiang-coms-use-cases-00
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.
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 August 6, 2018.
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.
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:
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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:
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.
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.
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.
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:
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
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
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.
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
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
This document makes no request of IANA.
There is no security consideration in this draft.
The authors would like to acknowledge Benoit Claise, Warren Kumari and Adrian Farrel for valuable discussions.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |