Network Slicing Architecture
draft-geng-netslices-architecture-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Liang Geng , Stewart Bryant , Jie Dong | ||
| Last updated | 2017-03-13 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-geng-netslices-architecture-00
Network Working Group L. Geng
Internet-Draft China Mobile
Intended status: Informational S. Bryant
Expires: September 14, 2017 J. Dong
Huawei Technologies
March 13, 2017
Network Slicing Architecture
draft-geng-netslices-architecture-00
Abstract
This document defines the overall architecture of network slicing.
Base on the general architecture, basic concepts of network slicing
and examples of network slicing instances are introduced for
clarification purposes. Some architectural considerations about the
data plane, control plane, management and orchestration of network
slicing are described to give a general view of network slicing
implementation principles. This also helps to identify the gaps in
existing IETF works relating to network slicing.
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 http://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 14, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Geng, et al. Expires September 14, 2017 [Page 1]
Internet-Draft Network Slicing Architecture March 2017
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
2. Demand for Network Slicing . . . . . . . . . . . . . . . . . 3
2.1. Guaranteed Service Performance . . . . . . . . . . . . . 4
2.2. End-to-end Customization . . . . . . . . . . . . . . . . 4
2.3. Network Slicing as a Service . . . . . . . . . . . . . . 4
3. Network Slicing Architecture . . . . . . . . . . . . . . . . 5
3.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Network Slicing Service Provider . . . . . . . . . . 5
3.1.2. Network Slice Instance . . . . . . . . . . . . . . . 5
3.1.3. Network Slice Type . . . . . . . . . . . . . . . . . 6
3.1.4. Network Slice Template . . . . . . . . . . . . . . . 6
3.1.5. Network Slice Tenant . . . . . . . . . . . . . . . . 6
3.2. General Architecture . . . . . . . . . . . . . . . . . . 6
4. Data Plane of Network Slicing . . . . . . . . . . . . . . . . 8
4.1. Propagation of Guarantees . . . . . . . . . . . . . . . . 8
4.2. The Underlying Physical Layer . . . . . . . . . . . . . . 8
4.3. Hard vs Soft Slicing in the Data-plane . . . . . . . . . 9
4.4. The Role of Deterministic Networking . . . . . . . . . . 9
4.5. The Role of VPNs . . . . . . . . . . . . . . . . . . . . 10
4.6. Dynamic Reprovisioning . . . . . . . . . . . . . . . . . 10
4.7. Non-IP Data Plane . . . . . . . . . . . . . . . . . . . . 10
5. Control Plane of Network Slicing . . . . . . . . . . . . . . 10
6. Management and Orchestration of Network Slicing . . . . . . . 11
7. Service Functions . . . . . . . . . . . . . . . . . . . . . . 11
8. OAM and Telemetry . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
12. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The Internet has always been designed to support a variety of
services. The emerging 5G market is expected to bring this diversity
of services to a new level. Typical examples of new bandwidth-hungry
services enabled by 5G include high definition (HD) video, virtual
reality (VR) and augmented reality (AR). The high bandwidth
requirement of these services is not particularly challenging thanks
to the continuing advancing technologies. However, the guarantee of
Geng, et al. Expires September 14, 2017 [Page 2]
Internet-Draft Network Slicing Architecture March 2017
high bandwidth performance of these services based-on a spontaneous
on-demand pattern is fairly challenging. Moreover, providing high
bandwidth with strict packet loss tolerances and high mobility is
also difficult for the current networks which are commonly designed
for best effort purposes.
Given that most Internet protocols are designed to comply with a best
effort, or enhanced best effort paradigm, it is inevitable that the
network will suffer from performance degradation in case of
congestion. Recent work on deterministic networking (DetNet) aim to
improve this situation by providing a ceiling on latency for a
particular traffic flow, which significant improves packet error rate
for specific DetNet services. This pioneering work gives a great
example that new approaches are investigated to make the Internet
aware of certain performance requirement other than the bandwidth.
Taking a look at the network infrastructure, service provider used to
build dedicated network and resources for services requiring
guaranteed performance. This is simply not cost-effective, neither
is it flexible. The emergence of virtualization and VPN technologies
make it possible to set up logically isolated computing and network
instances from shared infrastructures. This can be used dedicatedly
by specific services for improved performances. However, many
questions are still to be answered as different technologies in
various domains need to be combined to build network slices, which
may require the separation of different resources and various types
of performance guarantees.
2. Demand for Network Slicing
It is expected that a diversity of new services will emerge in 5G
network. These services including smart home, industrial control,
remote healthcare, Vehicle-to-Everything (V2X) and etc. will
eventually create an ecosystem of "Internet of Everything". With
hundreds of billions of devices from different business sectors
connected, the future network needs to meet the diversified Quality
of Experience (QoE) demands of different vertical industries.
Typical QoE requirements for the end users or the applications are
extremely low latency and high reliability, whilst the purchaser of
the slice is looking for short time-to-market and rapid deployment of
the service infrastructure needed to provide the technical
underpinning of their business. Service providers' networks need to
continuously evolve to adapt to this change. As a result, it is
believed that future networks should be able to provide services with
guaranteed performances together with the existing best-effort
services. In order to achieve this, it is preferred that dedicated
resources in the network could be used by different vertical industry
Geng, et al. Expires September 14, 2017 [Page 3]
Internet-Draft Network Slicing Architecture March 2017
customers. Network slicing is proposed as an end-to-end solution for
this purpose.
2.1. Guaranteed Service Performance
One of the most challenging requirements for future network is to
provide guaranteed performance for varieties of new services whilst
maintaining the economies of scale that accrue through resource
sharing. It has been foreseen that the requirements of different
services would be diversified and complex.
Taking augmented reality (AR) service as an example, it requires high
bandwidth to provide a local video feed to the augmenter, and high
quality augmented video back to the user. At the same time, it also
requires extremely low latency since the created reality and the
user's view must be synchronized to avoid reaction mismatch. Another
example is the vehicular communications where the delay in traffic
control system may directly jeopardize the road safety.
Network slicing can deal with these challenges by mapping the
performance requirements to physically or logically dedicated
resources.
2.2. End-to-end Customization
Customization is another significant feature of future services.
Many vertical industries are expected to offer customization
capabilities as a service to both internal manufacturing processes
and specific end users. Meanwhile, these customized services need to
be deployed with short time-to-market. The network needs to adapt to
this challenge since customers may frequently adjust and refine their
customization requirements.
There is ongoing work such as network orchestration, software defined
networks and network function virtualization that aims to address
this problem. In principle, these new technologies share a common
request for the network to provide the ability to provide agile
resource allocation.
2.3. Network Slicing as a Service
It is anticipated that the operation of 5G and future networks will
involve new business models. Given that the network is more
flexible, elastic, modularized and customized, the shared network
infrastructure can be sliced and offered as a service to the
customer. For instance, dedicated, isolated, end-to-end network
resources with a customized topology can be provided as a network
slice service to the tenant of this network slice.The tenants are
Geng, et al. Expires September 14, 2017 [Page 4]
Internet-Draft Network Slicing Architecture March 2017
allowed to have a certain level of provisioning of their network
slices.
3. Network Slicing Architecture
This section introduces the general system architecture of network
slicing.
3.1. Basic Concepts
Network slicing is a collection of technologies that are used to
establish logically dedicated resources including but not limited to
connectivity, computing, storage, provisioning and specific network
functions. The logical resources are a part of the larger common
network infrastructures that are shared among various network slice
instances. These dedicated resources can be customized to meet the
diversified requirements of different vertical industries.
The following sections describe some basic concepts of network
slicing.
3.1.1. Network Slicing Service Provider
A network slicing service provider, typically a telecommunication
service provider, is the owner of the network infrastructures from
which network slices are created. The network slicing service
provider takes the responsibilities of managing and orchestrating
corresponding resources that network slicing uses.
3.1.2. Network Slice Instance
A network slice instance (NSI) is the end-to-end realization of
network slicing, which consists of the combination of physically or
logically dedicated resources. An NSI typically associates with
components from different network domains including core network,
transport network and access network. It may also require cloud
resources from data centres. Furthermore, end-user terminals may
also allocate dedicated resource to a specific NSI.
Each NSI is defined and created for specific service-oriented
requirements. The logically dedicated resources allocated to NSIs
may be intrinsically isolated physical instances. They may also
share common physical infrastructures according to implementation
choices.
Geng, et al. Expires September 14, 2017 [Page 5]
Internet-Draft Network Slicing Architecture March 2017
3.1.3. Network Slice Type
Network slices are categorized into different types according to the
abstraction of characteristics of the services they facilitate. The
methodology used for defining network slice types may be different
for the owners of network slicing infrastructure. Some typical
examples of network slice types according to 5G implementation
include eMMB, mMTC and URLLC. Network slice type may be used to map
specific network resources, VPNs, QoS categories according to real
implementation. It is advised that mutual types should be defined
according to existing main-stream service implementation scenarios.
Extensions should be allowed for network slicing service provider to
make according to new requirements.
3.1.4. Network Slice Template
A network slice template is an abstraction of the resource
requirement for a set of similar network slice instances. Different
templates are defined for individual network slice types. These
templates are used to create certain network slice instances.
3.1.5. Network Slice Tenant
A network slice tenant is the user of specific NSIs, with which
specific services can be provided to end customers. Network slice
tenants can make requests of the creation of new network slice
instances. Certain level of management capability should be exposed
to network slice tenant from network slice service provider.
3.2. General Architecture
Figure 1 illustrates the general architecture of network slicing. It
can be seen that two network slice instances are created from the
shared network infrastructures. In principle, the network elements
(NEs) represent any general network infrastructures for demonstration
purposes. The two instances created do not know the existence of
each other. However, they may share the computing, connectivity and
storage resources of the NE, whether they are in physical or virtual
forms. Meanwhile, the owner of a particular network slice instance
is allowed to adjust the instance by requesting changes via the
network slicing management and orchestration system.
Geng, et al. Expires September 14, 2017 [Page 6]
Internet-Draft Network Slicing Architecture March 2017
+-----------------------------------------------------------+
| Network Slice Management and Orchestration |
| +------------+ +-------------+ +--------------------+ |
| | Template | | E2E Slice | | Life cycle Mngt. | |
| | Management | |Orchestration| | and monitoring | |
| +------------+ +-------------+ +--------------------+ |
| Created Network Slice Instances |
| +-------------------------------------------------------+ |
| | | |
| | +---+ +---+ +---+ | |
| | |NE1+----+ |NE3| |NE5| | |
| | +---+ | +-+-+ +-+-+ | |
| | +-+-+ | | | |
| | |NE2+-----+ | | |
| | +-+-+ | Network Slice | |
| | | | Instance 1 | |
| | +------------------------+ | |
| +-------------------------------------------------------+ |
| +-------------------------------------------------------+ |
| | | |
| | +---+ +---+ +---+ | |
| | |NE1+----+ +--+NE5+------+NE6| | |
| | +---+ | | +-+-+ +---+ | |
| | +-+-+ +---+ | | | |
| | |NE2| |NE4+-+ | | |
| | +-+-+ +-+-+ | Network Slice | |
| | | | | Instance 2 | |
| | +------------------------+ | |
| +-------------------------------------------------------+ |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Physical Network Infrastructures |
| +---+ +---+ +---+ +---+ |
| |NE1+----+ |NE3+------+ +--+NE5+------+NE6| |
| +---+ | +-+-+ | | +-+-+ +---+ |
| +-+-+ | +-+-+ | | |
| |NE2+----+ |NE4+-+ | |
| +-+-+ +-+-+ | |
| | | | |
| +------------------------+ |
+-----------------------------------------------------------+
Figure 1. Network Slicing Architecture
It is fundamental to network slicing that slices may be created, the
topology and/or its resources modified, and that the slices may be
decommissioned in a timely manner with minimum work by the network
slicing provider or the customer. This is not however unique to
Geng, et al. Expires September 14, 2017 [Page 7]
Internet-Draft Network Slicing Architecture March 2017
network slicing, it is a goal of modern classical networks to be able
to do this.
4. Data Plane of Network Slicing
In the network slicing architecture, the data plane in the edge and
core of the network will likely be one or more of the standard IETF
data planes: IPv4/IPv6, MPLS or Pseudowires (PW). This section
assumes that the IETF protocol stack exists as-is, and describes the
performance consideration in different layers of the data plane.
4.1. Propagation of Guarantees
Guarantees of delay start at the physical layer and propagate up the
stack layer by layer. Any layer can add delay, and can take various
steps to minimize the impact of delay on its layer, but no layer can
reduce the delay introduced by a lower layer.
Guarantees of loss and jitter can, by contrast be upheld or improved
at any layer of the protocol stack, but usually at a cost of
increased delay. Where delay is a constrain as it is in some 5G
applications the option of trading delay for better loss or jitter
characteristics is not an option. In these circumstances it is
critical that the quality characteristics start at the physical layer
and be maintained at each layer of the protocol stack.
4.2. The Underlying Physical Layer
A point to point dedicated physical channel provides the delay,
jitter and loss characteristics limited only by the media itself.
This does not fulfil the need for rapid reconfiguration of the
network to provision new services.
To address the need to provision a slice of the data-plane one
approach that can be deployed is to time-slice access to the physical
service. Ignoring many of the classic TDM offering as being too
slow, a number of technologies are available that might be applied
including OTN and FlexE. Whilst the provisioning of the channel
provided by underlays such as FlexE and the interconnection of FlexE
channels is within the scope of this architecture the operation of
the underlay is outside its scope.
The logical sub-division of a physical channel be that a single
channel with the full bandwidth available or a channel multiplexed at
the physical layer such as is provided by FlexE we will consider in
the following section.
Geng, et al. Expires September 14, 2017 [Page 8]
Internet-Draft Network Slicing Architecture March 2017
4.3. Hard vs Soft Slicing in the Data-plane
Hard slicing refers to the provision of resources in such a way that
they are dedicated to a specific NSI. Data-plane resources are
provided in the data-plane through the allocation of a lambda,
through the allocation of a time domain multiplexed resource such as
a FlexE channel or through a service such as an MPLS hard-pipe. Note
that although hard-pipes can be used to allocate dedicated, non-
shared resources to an NSI, the using of allocation is bandwidth,
which can result in more "lumpiness" in the physical channel that
would not be present with a true physical layer multiplexing scheme.
Soft slicing refers to the provision of resources in such a way that
whilst the slices are separated such that they cannot statically
interfere with each other (one cannot receive the others packets or
observe or interfere with the other's storage), they can interact
dynamically (one may find the other is sending a packet just when it
wants to, or the other may be using CPU cycles just when the other
needs to process some information), which means they may compete for
some particular resource at some specific time. Soft slicing is
achieved through logically multiplexing the data-plane over a
physical channel include various types of tunnel (IP or MPLS) or
various types of pseudowire (again IP or MPLS). Although the design
of deterministic networking techniques helps, it is not possible to
achieve the same degree of isolation with these techniques as it is
possible to achieve with pure physical layer multiplexing techniques.
However where such techniques provide sufficient isolation their use
leads to a network design that may be deployed on existing equipment
designs and which can make unused bandwidth available to best effort
traffic.
4.4. The Role of Deterministic Networking
Deterministic networking is a technology under development in the
IETF that aims to both minimize congestion loss and set an upper
bound on per hop latency. It allows a packet layer to emulate the
behaviour of a fully partitioned underlay such might be provided
through some physical layer multiplexing system such as FlexE.
Deterministic networking works by policing the ingress rate of a flow
to an agreed maximum and then scheduling the transmission time of
each flow to reduce the "lumpiness" and hence the possible buildup of
queues and hence congestion loss.
Whilst deterministic networking is not as perfect as physical layer
multiplexing in terms of latency minimization, because the scheduling
is hop by hop and not end to end meaning that at each hop a packet
has to wait for the transmission slot allocated to its flow, it has
Geng, et al. Expires September 14, 2017 [Page 9]
Internet-Draft Network Slicing Architecture March 2017
the advantage that it is able to allocate slots not needed by the
allocated traffic to best effort traffic. This reallocation of the
unused transmission slots to background traffic significantly
improves the efficiency of the network by amortizing the cost between
the scheduled high priority users and the best effort users.
4.5. The Role of VPNs
VPNs are considered candidate technologies for network slicing. The
existing VPN technologies mainly focus on the isolation of forwarding
tables between different tenants and provide a virtual topology for
the connectivity between different sites of a tenant. The VPN layer
and the underlying network resources are usually loosely coupled, and
statistical multiplexing is adopted to improve network utilization.
Although VPNs have been widely used to provide enterprise services in
service provide networks, it is unclear that whether VPNs along with
existing underlying tunnel technologies can meet the performance and
isolation requirements of critical services in the vertical
industries.
4.6. Dynamic Reprovisioning
A requirement of the network slicing system is that it can be
dynamically and non-disruptively reprovisioned. That is not an
unusual requirement of a modern network. However the frequency of
reprovisioning with network slicing will be relatively high, such
that it in many cases it is not possible to hide any disruption
during a "quiet" time.
Physical multiplexing methods such as FlexE have the ability to
seamlessly reprovision multiplex slots. At the network layer
techniques such as make-before-break, segment routing, and loop-free-
convergence can be used to provide uninterrupted operation during a
topology change.
4.7. Non-IP Data Plane
Non-IP data plane in support of Information Centric Networking (ICN),
some of the IoT services and other similar requirements will be added
in a future version.
5. Control Plane of Network Slicing
There are two control plane systems that need to be considered. The
first is the control plane of the slicing infrastructure itself, the
second is the control plane of an individual slice.
Geng, et al. Expires September 14, 2017 [Page 10]
Internet-Draft Network Slicing Architecture March 2017
The network slicing control plane receives instructions from the
orchestration layer and creates the required network slices and
manages them throughout their life cycle. The slices need to satisfy
a diverse set requirements and need to be dynamically managed as the
collective requirements of the set of network slices changes, and as
the resource and capabilities of the physical network change with
time. Changes occur as resources fail, and resources are added.
They also occur as the slices are added and deleted possibly needing
a garbage collection and defagmantation service.
The control plane of the network slicing system needs to comply with
the SDN architecture, while still using distributed control protocols
when it is necessary or proved to have advantages.
Within a slice the full range of existing control plane technologies
needs to be permissible. Some slices will run the existing IGP
protocols (such as IS-IS or OSPF) whilst others may use BGP. Some
slices may be controlled by their own SDN controllers. However the
architecture needs to be sufficiently general so as not to restrict
the control protocols that may be used within a slice.
6. Management and Orchestration of Network Slicing
The management and orchestration layer of network slicing system is
responsible for the slice template management, slice orchestration
and life cycle management and monitoring of network slices. Network
slice templates can be generated according to the functional and
performance requirements of the tenants. In different network
domains, different technologies may be used for network slicing, and
orchestration is needed to build E2E network slice. The
provisioning, runtime assurance and decommissioning of E2E network
slices is also the key function of this layer.
It is expected that the management and orchestration layer would use
state of the art management technologies to support short time-to-
market, and help the operators to build an open ecosystem for new
services in vertical industries.
7. Service Functions
To be provided in a future version.
8. OAM and Telemetry
To be provided in a future version.
Geng, et al. Expires September 14, 2017 [Page 11]
Internet-Draft Network Slicing Architecture March 2017
9. IANA Considerations
This document makes no request of IANA.
10. Security Considerations
Each layer of the system has its own security requirements.
11. Acknowledgements
12. Normative References
[Network-Slice-White-Paper]
China Mobile Communication Corporation, Huawei
Technologies Co. Deutsche Telekom AG,Volkswagen, "5G
Service-Guaranteed Network Slicing White Paper", 2017,
<http://labs.chinamobile.com/
pdf/5GService-GuaranteedNetworkSlicingWhitePaper.pdf>.
[TD126_DraftRec_Y_IMT2020-NetSoft]
Nakao, A., Shimizu, T., and T. Kinoshita, "High level
technical characteristics of network softwarization for
IMT-2020", 2017.
[TD127_DrafSup_NetSoft-and-OSS_v0214-19H]
Goto, Y. and N. Morita, "Draft supplement to Y.IMT2020
series "Standardization and open source activities related
to network softwarization of IMT-2020"", 2017.
Authors' Addresses
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Stewart Bryant
Huawei Technologies
Email: stewart.bryant@gmail.com
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Geng, et al. Expires September 14, 2017 [Page 12]