< draft-geng-coms-problem-statement-02.txt   draft-geng-coms-problem-statement-03.txt >
Network Working Group L. Geng NONE L. Geng
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational S. Kuklinski Intended status: Informational S. Kuklinski
Expires: September 6, 2018 Orange Expires: September 6, 2018 Orange
L. Qiang L. Qiang
Huawei Technologies Huawei Technologies
S. Matsushima S. Matsushima
Softbank Softbank
A. Galis A. Galis
University College London University College London
Luis. Contreras Luis. Contreras
Telefonica
March 5, 2018 March 5, 2018
Full Title Problem Statement of Common Operation and Management of Network Slicing
draft-geng-coms-problem-statement-02 draft-geng-coms-problem-statement-03
Abstract Abstract
This document discusses the problem statement of Common Operation and This document discusses the problem statement of Common Operation and
Management of Network Slicing (COMS). The purpose of this document Management of Network Slicing (COMS). The purpose of this document
is to identify the problem space of COMS and discuss the approach is to identify the problem space of COMS and discuss the approach
COMS is using to match the top-down network slice management concern COMS is using to match the top-down network slice management concern
with the underlay technologies. Furthermore, the role of a common with the underlay technologies. Furthermore, the role of a common
information model introduced and corresponding design principles are information model is introduced and corresponding design principles
also discussed. are also discussed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Concept of COMS and Problem Space . . . . . . . . . . . . 4 2. The Concept of COMS and Problem Space . . . . . . . . . . . . 4
3. How Top-down Matches with Bottom-up approach . . . . . . . . 6 3. How Top-down Matches with Bottom-up approach . . . . . . . . 6
4. Resources under Supervisoin of COMS . . . . . . . . . . . . . 7 4. Resources under Supervisoin of COMS . . . . . . . . . . . . . 7
4.1. Connectivity Resources . . . . . . . . . . . . . . . . . 7 4.1. Connectivity Resources . . . . . . . . . . . . . . . . . 7
4.2. Computing Resources . . . . . . . . . . . . . . . . . . . 7 4.2. Computing Resources . . . . . . . . . . . . . . . . . . . 8
4.3. Storage Resources . . . . . . . . . . . . . . . . . . . . 8 4.3. Storage Resources . . . . . . . . . . . . . . . . . . . . 8
4.4. Service Function . . . . . . . . . . . . . . . . . . . . 8 4.4. Service Function . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The concept of network slicing is not new but energized greatly under The concept of network slicing is not new but energized greatly under
5G work in 3GPP. It is expected that further 5G network should be the 5G work in 3GPP. It is expected that further 5G network should
capable of providing dedicated private network for different be capable of providing dedicated private network for different
verticals according to their specific requirements, which are created verticals according to their specific requirements, which are created
by diversity of new services such as high definition (HD) video, by diversity of new services such as high definition (HD) video,
virtual reality (VR) and V2X applications. Looking at the virtual reality (VR) and V2X applications. Looking at the
development of future network, no matter the service is connected via development of future network, no matter the service is connected via
5G cellular RAN, FTTx optical access network or other dedicated 5G cellular RAN, FTTx optical access network or other dedicated
connections, this resource dedication has become a fundamental connections, this resource dedication has become a fundamental
technology for services requiring extreme quality of user experience. enabler for services requiring extreme quality of user experience.
The best effort transport is not good enough as both subscribers and The best effort transport is not good enough as both subscribers and
application providers are looking for and willing to pay for certain application providers are looking for and willing to pay for certain
level of quality dedication. Therefore it is inevitable for service level of dedication. Therefore it is inevitable for service
providers (telecommunication infrastructure owners) to rethink the providers (i.e. Telecommunication infrastructure owners) to rethink
means of management and operation of their networks, which should the means of management and operation of their networks, which should
support end-to-end slicing capabilities. support end-to-end slicing capabilities.
The requirements from different verticals may be extremely The requirements from different verticals may be extremely
diversified. Typical examples includes high bandwidth, low latency, diversified. Typical examples includes high bandwidth, low latency,
high level of isolation, specific security and encryption high level of isolation, specific security and encryption
requirements and etc. These requirements may also change dynamically requirements and etc. These requirements may also change dynamically
along time since the services of certain industry vertical changes along time since the services of certain industry vertical change
very fast, and sometime spontaneously (i.e. burst bandwidth/latency very fast, and sometime spontaneously (i.e. burst bandwidth/latency
requirement from on-line shopping provider on certain period). It is requirement from on-line shopping provider during sale period). It
expected that the configuration of certain network slice instances is expected that the configuration of certain network slice instances
are very dynamic in a case-by-case manner. Meanwhile, there are many are very dynamic in a case-by-case manner. Meanwhile, there are many
technology options to fulfil particular requirements depending on technology options to fulfil particular requirements depending on
considerations on many aspects including cost, TTM and etc. The considerations on many aspects including cost, TTM and etc. The
diversity of both requirements and technology options makes network diversity of both requirements and technology options make the
slices significantly heterogeneous. management of network slices significantly heterogeneous.
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 network resources and management entities.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
Network Slice - A set of infrastructure resources and service Network Slice - A set of infrastructure resources and service
skipping to change at page 5, line 37 skipping to change at page 5, line 37
| Device Configuration Model | | Device Configuration Model |
+---------------+----------------------------+-------------+ +---------------+----------------------------+-------------+
| Underlying Network Resources/Functions | | Underlying Network Resources/Functions |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 1: Schematic Diagram of COMS Figure 1: Schematic Diagram of COMS
Figure 1 illustrated the concept of how COMS is implemented within a Figure 1 illustrated the concept of how COMS is implemented within a
heterogeneous network. A customer (NST) request NSaaS via service heterogeneous network. A customer (NST) request NSaaS via service
model. The service model describe the network slice in user's model. The service model describe the network slice in user's
language. This model is technology-agnostic. A NSP translate the language. This model is technology-agnostic. A NSP translates the
service profle to service delivery model which describe how a NSP service profile to service delivery model which describe how a NSP
engineering it's resource for the service. The service delivery engineering it's resource for the service. The service delivery
model is sent to the network slice manager, where it is further model is sent to the network slice manager, where it is further
decomposed to network configuration model in different technology decomposed to network configuration model in different technology
domains. Finally the device configuration models are used to setup domains. Finally the device configuration models are used to setup
the parameters of the underlay infrastructures and functions. the parameters of the underlay infrastructures and functions.
COMS focuses on the cross-domain management of network infrastructure COMS focuses on the cross-domain management of network infrastructure
and service functions which are considered as elements of a given and service functions which are considered as elements of a given
network slice. COMS will only design service model and service network slice. COMS will only design service model and service
delivery models for network slice services. It will not try to delivery models for network slice services. It will not try to
skipping to change at page 6, line 11 skipping to change at page 6, line 11
models and device configuration models. The associated the slice- models and device configuration models. The associated the slice-
level operation, administration and maintenance will also be the level operation, administration and maintenance will also be the
concern of COMS. concern of COMS.
3. How Top-down Matches with Bottom-up approach 3. How Top-down Matches with Bottom-up approach
COMS indeed takes a top-down approach to look at the management of COMS indeed takes a top-down approach to look at the management of
network, where the requirement of network slice and its management network, where the requirement of network slice and its management
are triggered by new vertical industry services and business model. are triggered by new vertical industry services and business model.
However, this top-down approach does not directly ask for any However, this top-down approach does not directly ask for any
specific new forwarding technology. It ask for a slice-level specific new forwarding technology. It asks for a slice-level
management which coordinates various underlay technology domains to management which coordinates various underlay technology domains to
enablel NSaaS. Nowadays, existing IETF technologies either evolves enable NSaaS. Nowadays, existing IETF technologies either evolves
(e.g. DETNET) or naturally support (e.g. VPN) certain resource (e.g. DETNET) or naturally support (e.g. VPN) certain resource
dedication mechanism in a bottom-up view. This is in line with the 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 concept of network slicing. However, A big problem is that IETF has
little tools for cross-domain management (draft-arkko-arch- little tools for cross-domain management
virtualization-00), without which the creation of an end-to-end [draft-arkko-arch-virtualization], without which the creation of an
network slicing would not be possible. COMS makes the convergence end-to-end network slicing would not be possible. COMS makes the
between top-down and bottom-up view of network slicing. convergence between top-down and bottom-up view of network slicing.
+--------------------------------------+ +--------------------------------------+
| Service & Service Delivery Model | | Service & Service Delivery Model |
| | | |
+--------------------------------------+ +--------------------------------------+
Provide Design /|\ Provide Design /|\
Guidance | Guidance |
+-----------------------------+ +-----------------------------+
| | | |
| COMS Information Model | | COMS Information Model |
skipping to change at page 7, line 13 skipping to change at page 7, line 13
does not directly define network configuration model for each domain. does not directly define network configuration model for each domain.
The models defined elsewhere should refer to COMS information model The models defined elsewhere should refer to COMS information model
in order to be used as a part of a network slice. This information in order to be used as a part of a network slice. This information
model is than a comprehensive set of abstraction. Each single model is than a comprehensive set of abstraction. Each single
technology typically refer to a subset of this information model for technology typically refer to a subset of this information model for
slice-level abstraction process. slice-level abstraction process.
4. Resources under Supervisoin of COMS 4. Resources under Supervisoin of COMS
Fundamentally, network slices are created based on the shared In order to provide cost-effective and efficient network slice
infrastructures and funtions. There are many existing technologies configuration, service provider needs to understand specifically the
which focus on the management of those entities. For example, components it can make use to create a network slice instance and how
various type of domain SDN controllers supervise the connectivity these components map with the customer requirements. These
resources within each technology or geographical domains, and MANO components include both infrastructure resources and service
supervises the NFV infrastructures. COMS provides an end-to-end functions. There are many existing technologies which focus on the
management mechanism which integrate various underlay technology management of those entities. For example, various type of domain
domains to create a network slice. It oversees all these resources SDN controllers supervise the connectivity resources within each
and decides the placement of specific resources according to certain technology or geographical domains, and MANO supervises the NFV
path and topology constraints. 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 COMS does not have any particular constraints on what type of
resources it manages. This is defined by its information model and resources it manages. This is defined by its information model and
will have to adapt to what a NST really needs. Meanwhile, whether a 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 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, to NSP's policy. However, for the ease of management and operation,
it is worthy to have a guideline to categorize the common resources it is worthy to have a guideline to categorize the common resources
that NSP may offer to NST as a network slice service. The section that NSP may offer to NST as a network slice service. This section
endeavours to provide a prototype catalogue of the resource endeavours to provide a prototype catalogue of the resource
components for network slice creation. In general, the components components for network slice creation. More detailed description can
that an NSP can use to create a network slice include connectivity, be found in [draft-qiang-coms-netslicing-information-model-02] In
computing, storage infrastructures and service functions. 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 4.1. Connectivity Resources
Connectivity is one of the essential components for a network slice. 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 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 link using a dedicated wavelength. It may also have more complex
topology with other specific requirements including bandwidth, topology with other specific requirements including bandwidth,
latency and etc. latency and etc.
4.2. Computing Resources 4.2. Computing Resources
If an NST would like to host virtualized functions in a network If an NST would like to host virtualized functions in a network
slice, it may be interested in asking for specific computing resource slice, it may be interested in asking for specific computing resource
including both bare metal servers and virtual machines. . including both bare metal servers and virtual machines.
4.3. Storage Resources 4.3. Storage Resources
It is necessary for NSP to provide storage components in a network It is necessary for NSP to provide storage components in a network
slice since NSTs may want to host contents on dedicated resources. slice since NSTs may want to host contents on dedicated resources.
Meanwhile, NSP may also prefer to use dedicated storage for specific Meanwhile, NSP may also prefer to use dedicated storage for specific
service policies, authentication information and other management service policies, authentication information and other management
profiles. profiles.
4.4. Service Function 4.4. Service Function
skipping to change at page 8, line 33 skipping to change at page 8, line 39
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
TBD TBD
7. Acknowledgements 7. Acknowledgements
The author would like to thank Benoit Claise, Warren Kumari, Jari The author would like to thank Benoit Claise, Xavier de Foy,Warren
Arkko, Jeff Tantsura, Xavier de Foy for discussion on this work. Kumari, Jari Arkko and Jeff Tantsura for discussion on this work.
8. Normative References 8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
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 Authors' Addresses
Liang Geng Liang Geng
China Mobile China Mobile
Beijing 100053 Beijing 100053
China China
Email: gengliang@chinamobile.com Email: gengliang@chinamobile.com
Slawomir Kuklinski Slawomir Kuklinski
Orange Orange
Email: slawomir.kuklinski@orange.com Email: slawomir.kuklinski@orange.com
Li Qiang Li Qiang
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
skipping to change at page 9, line 21 skipping to change at page 10, line 4
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: qiangli3@huawei.com Email: qiangli3@huawei.com
Satoru Matsushima Satoru Matsushima
Softbank Softbank
Email: kiran.makhijani@huawei.com Email: kiran.makhijani@huawei.com
Alex Galis Alex Galis
University College London University College London
London London
U.K. U.K.
Email: a.galis@ucl.ac.uk Email: a.galis@ucl.ac.uk
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 26 change blocks. 
52 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/