< draft-homma-slice-provision-models-00.txt   draft-homma-slice-provision-models-01.txt >
Individual S. Homma Individual S. Homma
Internet-Draft H. Nishihara Internet-Draft H. Nishihara
Intended status: Informational NTT Intended status: Informational NTT
Expires: August 5, 2019 T. Miyasaka Expires: January 9, 2020 T. Miyasaka
KDDI Research KDDI Research
A. Galis A. Galis
University College London University College London
V. Ram OV V. Ram OV
Independent Research Consultant India Independent Research Consultant India
D. Lopez D. Lopez
L. Contreras-Murillo L. Contreras-Murillo
J. Ordonez-Lucena J. Ordonez-Lucena
Telefonica I+D Telefonica I+D
P. Martinez-Julia P. Martinez-Julia
NICT NICT
L. Qiang L. Qiang
Huawei Technologies Huawei Technologies
R. Rokui R. Rokui
L. Ciavaglia L. Ciavaglia
Nokia Nokia
X. de Foy X. de Foy
InterDigital Inc. InterDigital Inc.
February 1, 2019 July 8, 2019
Network Slice Provision Models Network Slice Provision Models
draft-homma-slice-provision-models-00 draft-homma-slice-provision-models-01
Abstract Abstract
Network slicing is an approach to provide separate virtual network Network slicing is an approach to provide separate virtual network
based on service requirements. It's a fundamental concept of the 5G, based on service requirements. It's a fundamental concept of the 5G,
and the architecture and specification is under standardization in and the architecture and specification is under standardization in
several organizations. However, the definitions and scopes of several organizations. However, the definitions and scopes of
network slicing vary to some degree from one organization to another. network slicing vary to some degree from one organization to another.
This document provides classification of provisioning models of This document provides classification of provisioning models of
network slice for clarifying the differences on the definitions and network slice for clarifying the differences on the definitions and
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
1.1. Differentiated Roles in Network Slice Provisioning . . . 3 1.1. Differentiated Roles in Network Slice Provisioning . . . 3
1.2. High-level Problem Statement . . . . . . . . . . . . . . 4 1.2. High-level Problem Statement . . . . . . . . . . . . . . 4
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. General Requirements for Network Slicing . . . . . . . . . . 7 3. General Requirements for Network Slicing . . . . . . . . . . 7
4. Network Slice Structure . . . . . . . . . . . . . . . . . . . 7 3.1. Requirements/Attributes for Network Slice . . . . . . . . 7
4.1. Resources for Structuring Network Slices . . . . . . . . 7 4. Network Slice Structure . . . . . . . . . . . . . . . . . . . 8
4.2. Basic Network Slice Structure . . . . . . . . . . . . . . 11 4.1. Resources for Structuring Network Slices . . . . . . . . 8
4.2. Basic Network Slice Structure . . . . . . . . . . . . . . 12
4.3. Stakeholders in the Structuring Network Slices . . . . . 14 4.3. Stakeholders in the Structuring Network Slices . . . . . 14
5. Variations of Network Slice Creation . . . . . . . . . . . . 14 5. Variations of Network Slice Creation . . . . . . . . . . . . 15
5.1. Ready-made Network Slice . . . . . . . . . . . . . . . . 14 5.1. Ready-made Network Slice . . . . . . . . . . . . . . . . 15
5.2. Custom-made Network Slice . . . . . . . . . . . . . . . . 15 5.2. Custom-made Network Slice . . . . . . . . . . . . . . . . 15
5.3. semi-Custom-made Network Slice . . . . . . . . . . . . . 15 5.3. semi-Custom-made Network Slice . . . . . . . . . . . . . 15
6. Network Slice Provision Models . . . . . . . . . . . . . . . 15 6. Network Slice Provision Models . . . . . . . . . . . . . . . 15
6.1. Three Provision Models . . . . . . . . . . . . . . . . . 15 6.1. SaaS-like Model . . . . . . . . . . . . . . . . . . . . . 16
6.2. Configurable Parameters/Attributes on each Provision 6.1.1. Capability in SaaS-like Model . . . . . . . . . . . . 16
Models . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. PaaS-like Model . . . . . . . . . . . . . . . . . . . . . 16
6.3. Capability of NS Tenant on each Provision Model . . . . . 18 6.2.1. Capability in PaaS-like Model . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.3. IaaS-like Model . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.3.1. Capability in IaaS-like Model . . . . . . . . . . . . 17
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Mapping of NS Provision Models and Infrastructure
10. Informative References . . . . . . . . . . . . . . . . . . . 18 Layering . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. NS Structure in the 3GPP 5GS . . . . . . . . . . . . 20 Appendix A. NS Structure in the 3GPP 5GS . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction and Motivation 1. Introduction and Motivation
Network slicing is an approach to provide separate virtual networks Network slicing is an approach to provide separate virtual networks
depending on requirements of each service. Network slicing receives depending on requirements of each service. Network slicing receives
attention due to factors such as diversity of services and devices, attention due to factors such as diversity of services and devices,
and it is also a fundamental concept of the 5G for applying networks and it is also a fundamental concept of the 5G for applying networks
to such various types of requirements. to such various types of requirements.
In addition, network slicing is expected to enable a business model In addition, network slicing is expected to enable a business model
skipping to change at page 4, line 36 skipping to change at page 4, line 39
Finally, in order to establish a proper order and allow the Finally, in order to establish a proper order and allow the
coexistence and collaboration of different systems, a common ontology coexistence and collaboration of different systems, a common ontology
regarding network and system virtualization should be defined and regarding network and system virtualization should be defined and
agreed, so different and heterogeneous systems can understand each agreed, so different and heterogeneous systems can understand each
other without requiring to rely on specific adaptation mechanisms other without requiring to rely on specific adaptation mechanisms
that might break with any update on any side of the relation. that might break with any update on any side of the relation.
2. Definition of Terms 2. Definition of Terms
This section lists definitions and terms related to network slicing. This section lists definitions and terms related to network slicing.
Although this document refers terms and viewpoints on network slicing This document refers terms and view points on network slicing in some
in 3GPP documents ([TS.28.530-3GPP] and [TS.28.801-3GPP]) and SDOs, such as 3GPP([TS.23.501-3GPP], [TS.28.530-3GPP], and
[NGMN-5G-White-Paper], some of definitions in this document may be [TS.28.801-3GPP]), and NGMN ([NGMN-5G-White-Paper]). However the
different from ones of those documents. scope of this document is not network slicing which is mobile
specific but one for general networks, and thus some of definitions
in this document may be different from ones of those documents.
Network Slicing: Network slicing indicates a technology, an Network Slicing: Network slicing indicates a technology, an
approach, or a concept to create logical separate networks in approach, or a concept to create logical separate networks in
support of services, depending on several requirements, on the support of services, depending on several requirements, on the
same physical resources. This is possible by combinations of same physical resources. This is possible by combinations of
several network technologies. several network technologies.
Network Slice (NS): An NS is a general name of logical separate Network Slice (NS): An NS is a logical separate network that
networks instantiated on a network infrastructure. It includes provides specific network capabilities and characteristics. In
Network Slice Instance, Network Slice Subnet Instance, and End-to- 3GPP definitions, an NS potentially includes both data plane and
End Network Slice Instance. control plane resources/functions.
Network Slice Instance (NSI): An NSI is a logical network Network Slice Instance (NSI): An NSI is a logical network instance
instantiated with network(WAN) and computing(NFVI), and some composed with required infrastructure resources, including
include additional network service functions such as firewall or networking (WAN), computing (NFVI) resources, and some include
load-balancer. It is composed of one or more Network Slice Subnet additional network service functions such as firewall or load-
Instances. When it provides connectivity from end to end for end balancer. It is composed of one or more Network Slice Subnet
users, it is called End-to-End Network Slice Instance. An NSI is Instances.
basically an overlay network and is independent of the underlay
network's topology.
Network Slice Subnet Instance (NSSI): An NSSI is a partially virtual Network Slice Subnet: A Network Slice Subnet is a representation of
network instantiated within a single domain, and it basically a set of required resources. It is composed and managed as a
provides connectivity to other domains or end points. Ways to group of network elements.
construct an NSSI depends on the specifications of underlay
networks. Network Slice Subnet Instance (NSSI): An NSSI is a partial logical
network instance represented as a network slicce instance. It is
a minimul unit managed or provided as a network slice. One or
more NSSI structure an NSI or an E2E-NSI.
End-to-End Network Slice Instance (E2E-NSI): An E2E-NSI is a virtual End-to-End Network Slice Instance (E2E-NSI): An E2E-NSI is a virtual
network connecting among end points. It is composed of one or network connecting among end points. It is composed of one or
multiple NSSIs. This term is used in this document when it should multiple NSSIs. This term is original of this document and is
be emphasized that the NSI is structured from end to end. As an used when it should be emphasized that the target NSI provides
example, for providing an E2E-NSI on the 3GPP 5G network, connectivity from end to end. As an example, for providing an
combining three types of NSIs: RAN-, TRN-, and CN-NSIs would be E2E-NSI on the 3GPP 5G network, combining three types of NSIs:
required. RAN-, TRN-, and CN-NSIs would be required.
Transport(TRN)-NSSI: A set of connections between various network Transport(TRN)-NSSI: A set of connections between various network
functions (VNF or PNF) with deterministic SLAs. They can be functions (VNF or PNF) with deterministic SLAs. They can be
implemented (aka realized) with various technologies (e.g. IP, implemented (aka realized) with various technologies (e.g. IP,
Optics, FN, Microwave) and various transport (e.g. RSVP, Segment Optics, FN, Microwave) and various transport (e.g. RSVP, Segment
routing, ODU, OCH etc). The overview of NSI composed with TRN- routing, ODU, OCH etc). The overview of NSI composed with TRN-
NSSI is shown in Appendix A. NSSI is shown in Appendix A.
RAN-NSSI: Regardless of RAN deployment (e.g. distributed-RAN, RAN-NSSI: Regardless of RAN deployment (e.g. distributed-RAN,
Centralized-RAN or Cloud-RAN, a RAN-NSSI creates a dedicate and Centralized-RAN or Cloud-RAN, a RAN-NSSI creates a dedicate and
skipping to change at page 7, line 34 skipping to change at page 7, line 39
disturbance from other NSs, and it may have some levels of disturbance from other NSs, and it may have some levels of
enforcement, such as hard or soft isolations. In some cases, for enforcement, such as hard or soft isolations. In some cases, for
providing appropriate communication between client and server, it providing appropriate communication between client and server, it
would be allowed for NS tenants to put their applications as contents would be allowed for NS tenants to put their applications as contents
server on NSIs by using computing resources. server on NSIs by using computing resources.
The required agility of slice operation and granularity of end to end The required agility of slice operation and granularity of end to end
communication quality requested can vary depending on provision communication quality requested can vary depending on provision
model. model.
3.1. Requirements/Attributes for Network Slice
NS tenants will have specific requirements for network slices
depending on the usages or service characteristics. Such
requirements or the assosiated attributes are broken down into
concrete design including network topology and configurations of
infrastructure resources, and NS is established based on the design.
The requirements or attributes on NSs are listed below:
o Requirements/Attributes of Network Resource
* bandwidth
* latency
* jitter
* packet loss rate
* reliability (e.g., MTBF, MTTF)
o Requirements/Attributes of Functionalities Resources
* function type (e.g., security, parental control)
* throughput
* packet error rate
* availability
4. Network Slice Structure 4. Network Slice Structure
This section describes resources used for structuring NSs and the This section describes resources used for structuring NSs and the
basic structure of E2E-NS. basic structure of E2E-NS.
4.1. Resources for Structuring Network Slices 4.1. Resources for Structuring Network Slices
A network slice is structured as combinations of the resources it A network slice is structured as combinations of the resources it
uses. Such resources are mainly categorized into three classes: uses. Such resources are mainly categorized into three classes:
network/WAN, computing/NFVI, and functionality resources. Variations network/WAN, computing/NFVI, and functionality resources. Variations
skipping to change at page 15, line 32 skipping to change at page 15, line 45
sCM-NS is a derivation of a CM-NS. In sCM-NS, an NS provider designs sCM-NS is a derivation of a CM-NS. In sCM-NS, an NS provider designs
the outline of NSs in advance, and a tenant tunes an NS with deciding the outline of NSs in advance, and a tenant tunes an NS with deciding
some parameters or applications run on resources. For example, an some parameters or applications run on resources. For example, an
infrastructure operator designs a logical network presenting infrastructure operator designs a logical network presenting
connectivity, and tenants install their own applications on servers connectivity, and tenants install their own applications on servers
running on the logical network. running on the logical network.
6. Network Slice Provision Models 6. Network Slice Provision Models
This document classifis NS provision models into three categories This section classifis NS provision models into three categories
defined in the following section. The capabilities which NS tenants defined from aspect that granularity of information exposed to
can have on management of NSs would vary depending on the selected tenants. The provision models are categorized into three models:
provision model. SaaS (Software as a Service) -like Model, PaaS (Platform as a
Service) -like Model, and IaaS (Infrastructure as a Service) -like
Model. The capabilities which NS tenants can have on management of
NSs would vary depending on the selected provision model.
6.1. Three Provision Models 6.1. SaaS-like Model
The provision models are categorized into three models: SaaS In SaaS-like Model, underlay infrastructure is hidden from tenants,
(Software as a Service), PaaS (Platform as a Service), IaaS and tenants can receive desired communication environment without
(Infrastructure as a Service) like models as below. deep knowledge about network and servers. An NS tenant decides
attribute values of its NS, such as bandwidth or latency, based on
their requirements, and NS providers design and create NSIs which
fulfill the values.
SaaS-like Model: In this model, an NS provider designs NS templates NS tenants need not to grasp detailed configurations in underlay
in advance, and a tenant selects and uses one which fulfills most networks in this model. However, it may not be possible to provide
its requirement among the templates. The specifications of NSs strictly desired NS to tenants because of abstruction of configurable
are abstracted to KPIs as networks and servers and shown to parameters. Moreover, it may cause complexity on designing NS
tenants. In short, detailed parameters of infrastructure network catalog due to quantities of selected attributes.
are hidden from tenants.
PaaS-like Model: In this model, a tenant makes its request, 6.1.1. Capability in SaaS-like Model
including connected area, path routes, the KPIs, and included
service functions, and a NS provider designs an NS template and
instantiate an NS based on the request dynamically. The
configurable values would vary depending on the policy of each NS
provider.
IaaS-like Model: In this model, a tenant designs its own NS In SaaS-like Model, an NS is represented for a tenant with attributes
templates and instantiates NSs by indicating concrete resources to values listed in Section 3.1. In other words, an NS tenant never
infrastructure operators. In other words, infrastructure know the concrete configurations of components in underlay
operators provide just their resources, and NSs are coordinated by infrastructure.
the tenant.
An NS tenant chooses a value from the range presented by the NS
provider in each attribute. The NS provider creates or changes a NS
by configuraing components in underlay infrastructures based on the
decided attribute values.
In terms of telemetry for assurance of service qualities on a NS, a
tenant can obtain telemetry information with unit of NSI, and never
know ones of underlay components structuring the NS.
6.2. PaaS-like Model
In PaaS-like Model, an NS is represented with several components such
as nodes and connectivities among them. An NS tenant can design and
customize its desired NS with combining such components. NS
providers breakdown the NS designed by the NS tenant to concrete
configurations of their infrastructure, and create/change NSSIs by
inputting the configurations. An NS tenant is also able to
incorporate its own functions or applications into its NSI by using
computing resources provided from NS providers.
This model potentially has high customizability of NS rather than
SaaS-like model, but needs NS tenants to have some knowledge about
network management. In terms of designing NS, the tenants provide
outline of their NSs, and thus it would make creation of concrete
configurations be easier.
6.2.1. Capability in PaaS-like Model
In PaaS-like model, an NS is represented with NF nodes and their
connectivities. An NS tenant can indicate functionalities of NF
nodes and thier locations. Also, the tenant decides attribute values
of connectivities. An NS provider creates or changes an NSI by
configuring underlay nodes and links depending on the indication of
the tenant. An NS tenant is also able to deploy its own NF as
software with provided computing resources.
In terms of telemetry, an NS tenant can obtain telemetry information
of NF nodes and connectivities structuring an NS, in addition to
whole of NSI.
6.3. IaaS-like Model
In IaaS-like model, an NS is represented with concrete configurations
of underlay infrastructure. NS tenants are able to structure or
change their desired NS by controlling infrastructure resources
directly.
This model potentially has high customizability of NS rather than
other models, but needs NS tenants to have deep knowledge about
network and server operation. Also, NS providers need not to
recognize NSs on their infrastructure because NS tenants directly
manage their NS. Meanwhile, in terms of security and prevention of
disturbances among NSs, some limitations on expositions of resources
to tenants would be needed.
6.3.1. Capability in IaaS-like Model
In IaaS-like Model, an NS is represented with configurations of
(virtual) nodes and (virtual) links connecting the nodes. An NS
tenant is able to configure nodes and links in underlay
infrastructure. In short, an NS tenant directly design detailed NS
and manages it. In addition, an NS tenant inserts its own functions
or applications in the NS with using computing resources.
In terms of telemetry, an NS tenant can obtain telemetry information
of nodes and links in addition of whole of NSI.
6.4. Mapping of NS Provision Models and Infrastructure Layering
An example of mapping of each NS provision model is shown in An example of mapping of each NS provision model is shown in
Figure 3. Figure 3.
manage manage
[NS Tenant] ---------------------------+ [NS Tenant] ---------------------------+
| |
| |
. . . . . . . . . . . . . . . . . . . . . . . . | . . . . . . . . . . . . . . . . . . . . . . . . |
*Service Layer | *Service Layer |
skipping to change at page 18, line 12 skipping to change at page 19, line 12
Figure 3: Mapping of NS provision models Figure 3: Mapping of NS provision models
In some cases, NSIs provided based on IaaS- or PaaS-like models are In some cases, NSIs provided based on IaaS- or PaaS-like models are
coordinated to a form of SaaS-like model by an NS broker , and the NS coordinated to a form of SaaS-like model by an NS broker , and the NS
broker or by the tenant, becoming a NS provider in a recursive broker or by the tenant, becoming a NS provider in a recursive
manner. For example, a vertical customer sends its high-level manner. For example, a vertical customer sends its high-level
requirements to an NS broker create an appropriate NSI with resources requirements to an NS broker create an appropriate NSI with resources
provided by infrastructure operators. provided by infrastructure operators.
6.2. Configurable Parameters/Attributes on each Provision Models
TBD
6.3. Capability of NS Tenant on each Provision Model
TBD
7. Security Considerations 7. Security Considerations
In NSaaS, parts of controls of infrastructures are opened to In NSaaS, parts of controls of infrastructures are opened to
externals, and thus some mechanisms, such as authentication for APIs, externals, and thus some mechanisms, such as authentication for APIs,
to prevent illegal access would be required. to prevent illegal access would be required.
Other considerations are TBD Other considerations are TBD
8. IANA Considerations 8. IANA Considerations
skipping to change at page 19, line 21 skipping to change at page 20, line 12
NGMN, "NGMN 5G White Paper", February 2015, NGMN, "NGMN 5G White Paper", February 2015,
<https://www.ngmn.org/5g-white-paper/5g-white-paper.html>. <https://www.ngmn.org/5g-white-paper/5g-white-paper.html>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[TS.23.501-3GPP] [TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
(V15.3.0): System Architecture for 5G System; Stage 2", (V16.0.0): System Architecture for 5G System; Stage 2",
September 2018, <http://www.3gpp.org/ftp//Specs/ September 2018, <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.501/23501-f30.zip>. archive/23_series/23.501/23501-g00.zip>.
[TS.28.530-3GPP] [TS.28.530-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530
(V1.0.0): Management and orchestration of networks and (V1.0.0): Management and orchestration of networks and
network slicing; Concepts, use cases and requirements network slicing; Concepts, use cases and requirements
(work in progress)", June 2018, (work in progress)", June 2018,
<http://ftp.3gpp.org//Specs/ <http://ftp.3gpp.org//Specs/
archive/28_series/28.530/28530-100.zip>. archive/28_series/28.530/28530-100.zip>.
[TS.28.541-3GPP] [TS.28.541-3GPP]
 End of changes. 23 change blocks. 
79 lines changed or deleted 177 lines changed or added

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