Internet DRAFT - draft-geng-coms-problem-statement
draft-geng-coms-problem-statement
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]
