Internet DRAFT - draft-geng-coms-architecture
draft-geng-coms-architecture
none L. Geng
Internet-Draft China Mobile
Intended status: Informational L. Qiang
Expires: September 6, 2018 Huawei
J. Ordonez
O. Adamuz-Hinojosa
P. Ameigeiras
University of Granada
D. Lopez
Telefonica I+D
L. Contreras
Telefonica
March 5, 2018
COMS Architecture
draft-geng-coms-architecture-02
Abstract
This document defines the overall architecture of a COMS based
network slicing system. COMS works on the top level network slice
orchestrator which directly communicates with the network slice
provider and enables the technology-independent network slice
management.
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.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Geng, et al. Expires September 6, 2018 [Page 1]
Internet-Draft Network slicing March 2018
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 3
4. Advanced Architecture . . . . . . . . . . . . . . . . . . . . 4
5. Integration with NFV . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Network slicing itself is a new concept triggered by vertical
industry, but that doesn't mean new forwarding technology is needed.
As an example given by [draft-arkko-arch-virtualization] shows, there
are multiple existing technologies could be used for network slicing
- VLAN tags are used in an ethernet segment, MPLS or VPNs across the
domain. If the storage and computing resources are considered, there
will be more available technologies (e.g., SFC).
Let's follow IETF's routine and image what will happen from the
bottom-up view. At first, existing technologies evolve toward
network slicing at forwarding plane in their own scopes. Then slice
management related functions will be patched at management/control
planes. When a network slice is going to be deployed inside a
domain, one of implementation technology will be selected, and the NS
provider directly operates on the management plane of this selected
technology. For example, If VPN is selected as the implementation
technology, then a network slice is a VPN for the NS provider in this
domain. While if SFC is selected in other domain, then a network
slice is a SFC for NS provider. What will happen if a network slice
across both VPN and SFC domains? There is no uniform management
manner in this case.
Geng, et al. Expires September 6, 2018 [Page 2]
Internet-Draft Network slicing March 2018
Then try to consider from the top-down view. There is no doubt that
slicing requirement is generated from NS tenant. When a NS tenant
request for NS service, normally he will not specify which
implementation technology should be used. Similarly, when the tenant
operates/manages his purchased slice, he doesn't want to care about
the technical details.
We can easily observe that bottom-up and top-down approaches will
eventually converge on a technology-independent common management
plane, that is exactly what COMS (Common Operation and Management on
network Slices) doing.
This document will explain how COMS works, and define the
architecture of COMS. Architecture discussed in this document is
assumed to be used only inside Transport Network region, and the end-
to-end network slice/slicing also just refers to the slice/slicing
across multiple TN domains in this document.
2. Terminology
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 [RFC2119].
Other network slicing related words used in this document are
interpreted as description in [COMS-PS].
Notations used in this document are interpreted as follows:
T(x->y): end-to-end delay from x to y;
B(x->y): bandwidth from x to y;
S(x): storage space of x.
3. Overall Architecture
This section provides the overall architecture for a COMS based
network slicing system as shown in Figure 1. If multiple such kind
of systems deployed in different domains, these systems may stitches
together through the method discussed in [Stitching-Management] and
[Stitching-Data]. COMS works on the top network orchestrator inside
Transport Network region, which directly receives the network slice
service profile, operation and management requests for network
slices. Based on received information, the network orchestrator will
select the most appropriate implementation technologies, and map the
technology independent requests into the technology specific
Geng, et al. Expires September 6, 2018 [Page 3]
Internet-Draft Network slicing March 2018
configuration information that will be sent to the corresponding
network slice controller/orchestrator downwards.
| Network Slice
| Service Profile
|
+--------------------------v----------------------------+
| |
| Top Level Network Orchestrator based on COMS |
| |
+--------------------------+----------------------------+
|
+--------+------------------+-------+-----------+----------------+
| | | | |
| +------v--------+ +------v--------+ +-------v-------+ +----v----+
| | | | | | | | |
| | NS Ctrlr/Orch | | NS Ctrlr/Orch | | NS Ctrlr/Orch | | ... |
| | | | | | | | |
| +-------+-------+ +-------+-------+ +-------+-------+ +----+----+
| | | | |
| | | | |
==v=========v==================v==================v================v=====
= =
= +------------+ +------------+ +------------+ +------------+ +-------+ =
= |Connectivity| | Computing | | Storage | |Generalized | | ... | =
= | | | | | | |Functions | | | =
= +------------+ +------------+ +------------+ +------------+ +-------+ =
= =
=========================================================================
Figure 1: Overall Architecture of COMS
4. Advanced Architecture
This section discusses the detailed architecture of a COMS based
network slicing system through an example shown in Figure 2. We do
not intend to design the inner framework of the top level network
slicing orchestrator but to explain how COMS works. Four components
insides the top level network orchestrator are logical components
that could be converged sometimes.
o Common Information Model: can be understood as the template,
according to which the received network slice service profile is
translated.
o Split Service Profile into Domains: the end-to-end service profile
is split into the service profiles inside different domains.
Geng, et al. Expires September 6, 2018 [Page 4]
Internet-Draft Network slicing March 2018
o Select Specific Implementation Technologies: there may be multiple
available implementation technologies inside a domain, select the
most appropriate one according to the service profile. As
Figure 2's example shows, since the end-to-end delay in Domain 1
is very small, the Flex-E will be selected. While in Domain 2 two
storage units are required, the NFV technology will be selected.
o Map to Selected Technologies: necessary mapping to the controller/
orchestrator of selected technologies.
|Network Slice Service Profile
|
**************************************************************************
*Top Level Network Orchestrator based on COMS *
* | *
* +-------------------------------v ---------------------------------+ *
* |Common Information Model | *
* | ................................................................ | *
* | . ~~~~~~~ T(A->B)<=10ms; B(A->B)>=10M ~~~~~~~ . | *
* | . ~ A ~---------------------------------------~ B ~ S(B)=1G. | *
* | . ~~~~~~~ ~~~~~~~ . | *
* | . | T(A->C)<=20ms; B(A->C)>=10M ~~~~~~~ . | *
* | . +-----------------------------------------~ C ~ S(C)=2G. | *
* | . ~~~~~~~ . | *
* | ................................................................ | *
* +--------------------------------+---------------------------------+ *
* | *
* +--------------------------------v---------------------------------+ *
* |Split Service Profile into Domains | *
* |................................. ................................| *
* |. Domain 1 . .Domain 2 .| *
* |. T(A->D)<=2ms . . T(D->B)<=8ms S(B)=1G .| *
* |. ~~~~~~~ B(A->D)>=10M ~~~~~~~ B(D->B)>=10M ~~~~~~~ .| *
* |. ~ A ~ --------------~ D ~-----------------~ B ~ .| *
* |. ~~~~~~~ ~~~~~~~ ~~~~~~~ .| *
* |. | T(A->E)<=2ms . . T(E->C)<=18ms S(C)=2G .| *
* |. | B(A->E)>=10M ~~~~~~~ B(E->C)>=10M ~~~~~~~ .| *
* |. +-----------------~ E ~-----------------~ C ~ .| *
* |. ~~~~~~~ ~~~~~~~ .| *
* |..................................................................| *
* +---------------------------------+--------------------------------+ *
* | *
* +---------------------------------v---------------------------------+ *
* |Select Specific Implementation Technologies | *
* | ............................. ............................ | *
* | .Domain 1 . .Domain 2 . | *
* | . Flex-E . . VPN+NFV . | *
* | ............................. ............................ | *
Geng, et al. Expires September 6, 2018 [Page 5]
Internet-Draft Network slicing March 2018
* +---------------+----------------------------------+----------------+ *
* | | *
* +---------------v----------------------------------v----------------+ *
* |Map to Selected Technologies | *
* +---------+------------------------+--------------------+-----------+ *
**************************************************************************
| | |
*********v*********** *********v******** **********v*********
* Flex-E Controller * * VPN Controller * * NFV Orchestrator *
*********+*********** *********+******** **********+*********
| | |
*********v*********** *********v********************v*********
* Physical/Logical * * Physical/Logical *
* Resources inside * * Resources inside *
* Domain 1 * * Domain 2 *
********************* ****************************************
Figure 2: Advanced Architecture of COMS
5. Integration with NFV
This section details the integration of the NFV framework [NFV-MANO]
in the COMS architecture.
Network slice providers aim to accommodate a myriad of use cases and
application scenarios from multiple tenants over a common network
infrastructure. To that end, network slice providers build up
multiple network slice instances (NSIs), each customized to serve the
specific service demands of a particular tenant. An NSI is a logical
self-contained network instance that network slice providers offer to
a tenant, and that a tenant can consume. Although NSIs may span
across multiple network segments (e.g., RAN, transport, and core
network), this document only considers the transport network domain.
NFV may play a key role in network slicing, enabling its realization
in a cost-efficient manner. Using the flexibility and virtualization
capabilities that the NFV framework brings, a network slice provider
can create and operate multiple NSIs over a common shared network
infrastructure with isolation guarantees in terms of performance,
management, security, and privacy [Ordonez-Network-Slicing]. To
provide the tenant with the required performance and functionality,
an NSI includes one or more network services, each consisting of a
chained set of compassable atomic units called virtualized network
functions (VNFs). These VNFs are software-based implementations of
network functions that rely on computing, storage, and connectivity
resources for their execution and communication. To simultaneously
serve the requirements of multiple NSIs, the network slice provider
makes use of the resources that are at its disposal, and efficiently
Geng, et al. Expires September 6, 2018 [Page 6]
Internet-Draft Network slicing March 2018
orchestrate them across NSIs. Although the network slice provider
can own these resources, we consider it rents them from one or more
infrastructure owners following the Infrastructure-as-a-Service
(IaaS) paradigm. In this case, the network slice provider takes the
role of a network infrastructure tenant. Note that each of the three
actors presented here (network infrastructure owner, network slice
provider, and network slice tenant) defines a different
administrative domain.
The NSIs shown in Figure 3 run parallel on a common shared transport
network infrastructure. The transport network infrastructure
consists of connectivity resources that may span across multiple
administrative domains (i.e., different network infrastructure
owners). These resources include WAN nodes and links providing
reachability across geographically remote data centers, where the
VNFs from different NSIs run. In particular, they connect together
the network connectivity endpoints (e.g., gateways) of those data
centers.
To simultaneously serve the connectivity needs of the NSIs using
resources within its administrative domain, each network
infrastructure owner has a WAN Infrastructure Manager (WIM). The WIM
is a NFV functional block that performs control-management actions
over the underlying connectivity resources to deploy and operate a
number of L2/L3 virtual topologies with different levels of
abstractions. To enforces the connectivity required by an NSI, the
WIM abstracts the resources under its management, and creates a
customized virtual topology that logically connects the data centers
hosting the NSI's VNFs. The resources of each data center are
managed with a Virtual Infrastructure Manager (VIM). This NFV
functional block play a similar role to the WIM, but extending their
management domain to computing and storage resources.
The transport network resources, managed by the underlying network
infrastructure owners using their WIMs/VIMs are delivered to the
network slice provider logically placed on top of them. The network
slice provider makes use of these resources to deploy and operate the
NSIs that are under its management. For this end, it may rely on the
NFV Orchestrator (NFVO) functionality. According to the NFV
framework, NFVO is a functional block with two well-defined
functionalities: resource orchestration and network service
orchestration. The former focuses on orchestrating network
infrastructure resources across multiple VIMs/WIMs, while the latter
performs lifecycle management operations (e.g., instantiation,
scaling, updating, termination, etc.) over the network service(s)
built using those resources. Due to the different scope of these two
set of functions, the NFVO may be logically split into two functional
blocks: Resource Orchestrator and Network Service Orchestrator.
Geng, et al. Expires September 6, 2018 [Page 7]
Internet-Draft Network slicing March 2018
^ +---------------------------------------------------------+
| | Cross-Segment Slice Manager |
| +-------------------------^-------------------------------+
| |
| +-------------------v------------------------+
| | Transport Network Slice Orchestrator <------+
| +----------------------------------^-----^---+ |
| | | |
| +------------------------------------ | ----+------+ |
| | NSI M | | |
| +--------------------------------------- | --------+ | |
| | NSI 1 | | | |
| +---------------------------+ +---v---+ | | |
Network | | Tenant SDN Controller <------> OSS | | | |
Slice | +--^-------^--------^----+--+ +---^---+ | | |
Provider | | | | | | | | |
Domain | +--v--+ +--v--+ | +--v--+ +------v-------+ | | |
| | VNF | | VNF | .. | | VNF | | Network | | | |
| | +--^--+ +--^--+ | +--^--+ | Service | | | |
| | | | | | | Orchestrator | | | |
| | | +-----+--------v--+ | +------^-------+ | | |
| | +-> vSwitch/vRouter <-+ | |-++ |
| | +-----------------+ | | | |
| +--------------------------------------- | --------+ | |
| | | |
| +------------------------------------------v-----------v--+ |
+ | Resource Orchestrator <-+
+--------^-------------------^-------------------^--------+
+-------+ | | |
+-----v-----+ +-----v-----+ +-----v-----+
+ | WIM | ... | VIM | ... | WIM |
| +-----+-----+ +-----+-----+ +-----+-----+
| | |
Network +-------+------+ +-----------------+ +------+-------+
Infrastructure | Connectivity | | +-------------+ | | Connectivity |
Owner | Resources | | | Computing/ | | | Resources |
Domain +--------------+ | | Storage/ | | +--------------+
| |Connectivity | |
| | | Resources | |
| | +-------------+ |
| | Data Center |
v +-----------------+
Figure 3: Integration of NFV framework in COMS architecture
To orchestrate the resources that are at its disposal (those provided
by the underlying network infrastructure owners), the network slice
provider has a single Resource Orchestrator. The main role of the
Geng, et al. Expires September 6, 2018 [Page 8]
Internet-Draft Network slicing March 2018
Resource Orchestrator is to dispatch this finite set of resources
across the operative NSIs in an optimal way, with the aim of
simultaneously satisfying their (potentially diverging) performance
requirements. To bring multiplexing gains and cost savings in this
task, the Resource Orchestrator may take advantage of resource
sharing. Resource sharing introduces flexibility and efficiency in
slice provisioning, as network slice provider's resources can be
dynamically allocated and released across NSIs according to the time-
varying resource requirements that their tenants impose. This
approach requires an adequate resource management framework for the
Resource Orchestrator that carefully finds an optimal solution,
enabling resource sharing among NSIs when necessary, while preserving
their performance isolation.
As shown in Figure 3, each of the operative NSIs serving a network
slice tenant comprises a tenant SDN controller, a Network Service
Orchestrator, and an Operation Support System (OSS). On the one
hand, the tenant SDN controller configures the VNFs at application
level, and chains them to dynamically build up the network service(s)
that are required in the NSI. For VNF configuration management, the
tenant SDN controller uses southbound configuration protocols such as
NETCONF. For VNF chaining management, it leverages the networking
capabilities provided by virtual switches/routers, sending them
appropriate forwarding instructions using southbound control
protocols such as OpenFlow. On the other hand, the Network Service
Orchestrator manages the lifecycle of the network service(s).
Finally, the OSS performs the intra-NSI management, bridging the gap
between the Network Service Orchestrator and the tenant SDN
controller, and coordinating their operations and management data.
The OSS is also the entry point of the NSI, providing management
capability exposure to external blocks. By way of example, the
network slice tenant can use the OSS to gain access to the NSI and
operate it at its convenience.
The description given above focuses on run-time phase, assuming the
NSIs are operative, and omitting the deployment steps referred in
Section 1. To trigger the deployment of a network slice, the network
slice provider needs other functional blocks. These functional
blocks include a Cross-Segment Slice Manager, and one or more Network
Slice Domain Orchestrators. The Cross-Segment Slice Manager receives
a network slice service profile from the tenant. This profile
contains the (end-to-end) slice requirements. The Cross-Segment
Slice Manager decompose these requirements into one or more network
slice domain slice requirements, and send them to the respective
Network Slice Domain Orchestrators (e.g., RAN Slice Orchestrator,
Transport Network Slice Orchestrator, Core Network Slice
Orchestrator). Since the architecture discussed in this document is
assumed to be inside the transport network domain, we only consider
Geng, et al. Expires September 6, 2018 [Page 9]
Internet-Draft Network slicing March 2018
the Network Slice Transport Orchestrator. The Network Slice
Transport Orchestrator uses the network slice transport requirements
to determine which VNFs and network service(s) are required, and what
are their resource requirements. Once checked the Resource
Orchestrator can provision them, the steps for deploying the slice
begin. First, the Resource Orchestrator creates the resource slice.
Then, the OSS takes over the resource slice and configures it,
resulting in a networking slice. Finally, the OSS (assisted by the
Network Service Orchestrator and the Tenant SDN controller),
instantiates one or more network services (and their constituent
VNFs) over this networking slice to realize a service slice, making
it usable for the network slice tenant.
6. Security Considerations
There is no security problems introduced by this document.
7. IANA Considerations
There is no IANA action required by this document.
8. Acknowledgements
TBD
9. Informative References
[COMS-PS] "Problem Statement of Supervised Heterogeneous Network
Slicing", <https://datatracker.ietf.org/doc/
draft-geng-coms-problem-statement/>.
[draft-arkko-arch-virtualization]
"Considerations on Network Virtualization and Slicing",
<https://tools.ietf.org/html/
draft-arkko-arch-virtualization-00>.
[I-D.boucadair-connectivity-provisioning-protocol]
Boucadair, M., Jacquenet, C., Zhang, D., and P.
Georgatsos, "Connectivity Provisioning Negotiation
Protocol (CPNP)", draft-boucadair-connectivity-
provisioning-protocol-15 (work in progress), December
2017.
[NFV-MANO]
ETSI GS NFV-MAN 001, "Network Functions Virtualisation
(NFV); Virtual Network Functions Architecture", V1.1.1,
December 2014.
Geng, et al. Expires September 6, 2018 [Page 10]
Internet-Draft Network slicing March 2018
[Ordonez-Network-Slicing]
Ordonez-Lucena, J., Ameigeiras, P., Lopez, D., Ramos-
Munoz, J., Lorca, J., and J. Folgueira, "Network Slicing
for 5G with SDN/NFV: Concepts, Architectures, and
Challenges", IEEE Communications Magazine, vol. 55, no. 5,
pp. 80-87, May 2017.
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[Stitching-Data]
"Gateway Function for Network Slicing",
<https://datatracker.ietf.org/doc/
draft-homma-coms-slice-gateway/>.
[Stitching-Management]
"Interconnecting (or Stitching) Network Slice Subnets",
<https://datatracker.ietf.org/doc/
draft-defoy-coms-subnet-interconnection/>.
Authors' Addresses
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Li Qiang
Huawei
Email: qiangli3@huawei.com
Jose Ordonez Lucena
University of Granada
Email: jordonez@ugr.es
Geng, et al. Expires September 6, 2018 [Page 11]
Internet-Draft Network slicing March 2018
Oscar Adamuz Hinojosa
University of Granada
Email: oadamuz@ugr.es
Pablo Ameigeiras
University of Granada
Email: pameigeiras@ugr.es
Diego Lopez
Telefonica I+D
Email: diego.r.lopez@telefonica.com
Luis Miguel Contreras Murillo
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Geng, et al. Expires September 6, 2018 [Page 12]
