Internet DRAFT - draft-qiang-coms-use-cases
draft-qiang-coms-use-cases
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
Abstract
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.
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 August 6, 2018.
Qiang, et al. Expires August 6, 2018 [Page 1]
Internet-Draft Abbreviated-Title February 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Heterogeneous Resource Management for Network Slicing . . . . 4
2.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 4
2.1.1. Combination of Networking and Computing . . . . . . . 4
2.1.2. Technology Diversity of Network Infrastructure . . . 5
2.1.3. Network and Service Functions Variety . . . . . . . . 6
2.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 6
3. Interoperation between Multiple Slice-aware Administrative
Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 6
3.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 7
4. End-to-end Orchestration of Network Slicing . . . . . . . . . 7
4.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 7
4.1.1. Resource Registration . . . . . . . . . . . . . . . . 7
4.1.2. Life-cycle Management . . . . . . . . . . . . . . . . 8
4.1.3. Network Slice Template and Repository . . . . . . . . 9
4.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 9
5. Customized OAM for Network Slice Tenant . . . . . . . . . . . 9
5.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 9
5.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 10
6. Interaction with 3GPP Network Slicing . . . . . . . . . . . . 10
6.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 10
6.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 10
7. Network Slice FCAPS . . . . . . . . . . . . . . . . . . . . . 10
7.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 11
7.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 11
8. Network Slice Stiching and Recursion . . . . . . . . . . . . 11
8.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 11
8.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Qiang, et al. Expires August 6, 2018 [Page 2]
Internet-Draft Abbreviated-Title February 2018
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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:
o Heterogeneous Resource Management for Network Slicing
o Interoperation between Multiple Slice-aware Administrative Domain
o End-to-end Orchestration of Network Slicing
o Customized OAM for Network Slice Tenant
o Interaction with 3GPP Network Slicing
o Network Slice FCAPS - to be specified in -01 version
o Network Slice Stiching and Recursion - to be specified in -01
version
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].
Qiang, et al. Expires August 6, 2018 [Page 3]
Internet-Draft Abbreviated-Title February 2018
2. Heterogeneous Resource Management for Network Slicing
2.1. Use Case Introduction
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.
2.1.1. Combination of Networking and Computing
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.
o Bare metal equipment with required specifications
o Hypervisor-based virtual machine
Qiang, et al. Expires August 6, 2018 [Page 4]
Internet-Draft Abbreviated-Title February 2018
o Container-based infrastructures
o Other customized type of presentation of computing resources
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.
2.1.2. Technology Diversity of Network Infrastructure
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.
o Various technology choices for access, aggregation and backbone
networks
o Legacy equipments due to deployment iteration
o Administrative concerns caused by geographical reasons
o Vendor-specific technology for customized deployment
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.
Qiang, et al. Expires August 6, 2018 [Page 5]
Internet-Draft Abbreviated-Title February 2018
2.1.3. Network and Service Functions Variety
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.
2.2. Use Case Analysis
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.
3. Interoperation between Multiple Slice-aware Administrative Domain
3.1. Use Case Introduction
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
Qiang, et al. Expires August 6, 2018 [Page 6]
Internet-Draft Abbreviated-Title February 2018
significant role as infrastructure resource, the requirement of
coordinating between networking and computing in management plane is
obvious.
3.2. Use Case Analysis
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.
4. End-to-end Orchestration of Network Slicing
4.1. Use Case Introduction
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:
1. Coordinating underlay network infrastructure and service function
resources
2. Life-cycle management, which includes the common operation of
network slice creation, activation/de-activation, modification,
deletion and status monitoring.
3. Pre-defining templates of common types of network slices and
provide repository for network slice instances created by
templates or full customization
4.1.1. Resource Registration
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:
Qiang, et al. Expires August 6, 2018 [Page 7]
Internet-Draft Abbreviated-Title February 2018
o The type of resources (whether it is a connectivity, computing,
storage or pre-defined network/sevice function)
o The physical/logical location of the resources
o Data plane and control plane technology capabilities
o Performance capabilities
o Availability information
o Domain topology information
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.
4.1.2. Life-cycle Management
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:
o 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.
o A network slice profile can be created by customized parameter
index and value.
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.
Qiang, et al. Expires August 6, 2018 [Page 8]
Internet-Draft Abbreviated-Title February 2018
4.1.3. Network Slice Template and Repository
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.
4.2. Use Case Analysis
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.
5. Customized OAM for Network Slice Tenant
5.1. Use Case Introduction
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:
1. Network slice life-cycle status monitoring
2. Performance dash board of individual/set of resource components
in a network slice
3. Slice-level parameter adjustments under network slice providers'
policies, strictly avoiding conflicts with other network slices.
4. Slice subset operation and management based on COMS at network
slice provider's permission
Qiang, et al. Expires August 6, 2018 [Page 9]
Internet-Draft Abbreviated-Title February 2018
5.2. Use Case Analysis
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
6. Interaction with 3GPP Network Slicing
6.1. Use Case Introduction
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
6.2. Use Case Analysis
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.
7. Network Slice FCAPS
Qiang, et al. Expires August 6, 2018 [Page 10]
Internet-Draft Abbreviated-Title February 2018
7.1. Use Case Introduction
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
7.2. Use Case Analysis
8. Network Slice Stiching and Recursion
8.1. Use Case Introduction
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
8.2. Use Case Analysis
9. IANA Considerations
This document makes no request of IANA.
10. Security Considerations
There is no security consideration in this draft.
11. Acknowledgements
The authors would like to acknowledge Benoit Claise, Warren Kumari
and Adrian Farrel for valuable discussions.
12. 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>.
Authors' Addresses
Li Qiang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: qiangli3@huawei.com
Qiang, et al. Expires August 6, 2018 [Page 11]
Internet-Draft Abbreviated-Title February 2018
Liang Geng
China Mobile
Beijing 100053
China
Email: gengliang@chinamobile.com
Kiran Makhijani
Huawei Technologies
2890 Central Expressway
Santa Clara CA 95050
USA
Email: kiran.makhijani@huawei.com
Xavier de Foy
InterDigital Inc.
1000 Sherbrooke West
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
Alex Galis
University College London
London
U.K.
Email: a.galis@ucl.ac.uk
Qiang, et al. Expires August 6, 2018 [Page 12]
