< draft-geng-coms-architecture-01.txt   draft-geng-coms-architecture-02.txt >
none L. Geng none L. Geng
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational L. Qiang Intended status: Informational L. Qiang
Expires: August 3, 2018 Huawei Expires: September 6, 2018 Huawei
J. Ordonez-Lucena J. Ordonez
O. Adamuz-Hinojosa O. Adamuz-Hinojosa
P. Ameigeiras P. Ameigeiras
University of Granada University of Granada
D. Lopez D. Lopez
Telefonica I+D
L. Contreras L. Contreras
Telefonica Telefonica
January 30, 2018 March 5, 2018
COMS Architecture COMS Architecture
draft-geng-coms-architecture-01 draft-geng-coms-architecture-02
Abstract Abstract
This document defines the overall architecture of a COMS based This document defines the overall architecture of a COMS based
network slicing system. COMS works on the top level network slice network slicing system. COMS works on the top level network slice
orchestrator which directly communicates with the network slice orchestrator which directly communicates with the network slice
provider and enables the technology-independent network slice provider and enables the technology-independent network slice
management. management.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 43
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 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 3 3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 3
4. Advanced Architecture . . . . . . . . . . . . . . . . . . . . 4 4. Advanced Architecture . . . . . . . . . . . . . . . . . . . . 4
5. Integration with NFV . . . . . . . . . . . . . . . . . . . . 6 5. Integration with NFV . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Deploying network slices on a common infrastructure logically Network slicing itself is a new concept triggered by vertical
requires at least three steps as shown in Figure 1: industry, but that doesn't mean new forwarding technology is needed.
As an example given by [draft-arkko-arch-virtualization] shows, there
Step 1: Slice physical/logical resources including connectivity, are multiple existing technologies could be used for network slicing
storage, computing resources from the infrastructure. The sliced - VLAN tags are used in an ethernet segment, MPLS or VPNs across the
resources couldn't be used directly, just as people is unable to use domain. If the storage and computing resources are considered, there
a computer with only hardware resources. will be more available technologies (e.g., SFC).
Step 2: Install protocols and make some necessary configurations to
make the sliced resources usable. Following up the former example,
this step is to install an operating system on the computer. Just as
there are kinds of operating systems (e.g., Linux, Windows, MacOS,
etc.) could be selected, there are a variety of technologies (e.g.,
VPN, SFC, Flex-E, etc.) could be used to support the network slicing.
Step 3: Implement services on slice, just like installing Let's follow IETF's routine and image what will happen from the
applications on the operating system. This is really a slice in the bottom-up view. At first, existing technologies evolve toward
eyes of customer until this step. 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.
+------------------+ 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
/ Service Slice / ===> Implement services 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.
/ /
/ Network Slice / ===> Install protocol/configuration
/ / to make resource usable
+------------------+
+------------------+
/ /
/ Resource Slice / ===> Slice physical/logical resources
/ / from infrastructure
+------------------+
Figure 1: Three Levels Network Slicing 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 (Common Operation and Management This document will explain how COMS works, and define the
on network Slices) works during these three steps, and define the
architecture of COMS. Architecture discussed in this document is architecture of COMS. Architecture discussed in this document is
assumed to be used only inside Transport Network region, and the end- assumed to be used only inside Transport Network region, and the end-
to-end network slice/slicing also just refers to the slice/slicing to-end network slice/slicing also just refers to the slice/slicing
across multiple TN domains in this document. across multiple TN domains in this document.
2. Terminology 2. Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 50 skipping to change at page 3, line 43
T(x->y): end-to-end delay from x to y; T(x->y): end-to-end delay from x to y;
B(x->y): bandwidth from x to y; B(x->y): bandwidth from x to y;
S(x): storage space of x. S(x): storage space of x.
3. Overall Architecture 3. Overall Architecture
This section provides the overall architecture for a COMS based This section provides the overall architecture for a COMS based
network slicing system as shown in Figure 2. If multiple such kind network slicing system as shown in Figure 1. If multiple such kind
of systems deployed in different domains, these systems may stitches of systems deployed in different domains, these systems may stitches
together through the method discussed in [Stitching-Management] and together through the method discussed in [Stitching-Management] and
[Stitching-Data]. COMS works on the top network orchestrator inside [Stitching-Data]. COMS works on the top network orchestrator inside
Transport Network region, which directly receives the network slice Transport Network region, which directly receives the network slice
service profile, operation and management requests for network service profile, operation and management requests for network
slices. Based on received information, the network orchestrator will slices. Based on received information, the network orchestrator will
select the most appropriate implementation technologies, and map the select the most appropriate implementation technologies, and map the
technology independent requests into the technology specific technology independent requests into the technology specific
configuration information that will be sent to the corresponding configuration information that will be sent to the corresponding
network slice controller/orchestrator downwards. network slice controller/orchestrator downwards.
skipping to change at page 4, line 41 skipping to change at page 4, line 34
| | | | | | | | | |
==v=========v==================v==================v================v===== ==v=========v==================v==================v================v=====
= = = =
= +------------+ +------------+ +------------+ +------------+ +-------+ = = +------------+ +------------+ +------------+ +------------+ +-------+ =
= |Connectivity| | Computing | | Storage | |Generalized | | ... | = = |Connectivity| | Computing | | Storage | |Generalized | | ... | =
= | | | | | | |Functions | | | = = | | | | | | |Functions | | | =
= +------------+ +------------+ +------------+ +------------+ +-------+ = = +------------+ +------------+ +------------+ +------------+ +-------+ =
= = = =
========================================================================= =========================================================================
Figure 2: Overall Architecture of COMS Figure 1: Overall Architecture of COMS
4. Advanced Architecture 4. Advanced Architecture
This section discusses the detailed architecture of a COMS based This section discusses the detailed architecture of a COMS based
network slicing system through an example shown in Figure 3. We do network slicing system through an example shown in Figure 2. We do
not intend to design the inner framework of the top level network not intend to design the inner framework of the top level network
slicing orchestrator but to explain how COMS works. Four components slicing orchestrator but to explain how COMS works. Four components
insides the top level network orchestrator are logical components insides the top level network orchestrator are logical components
that could be converged sometimes. that could be converged sometimes.
o Common Information Model: can be understood as the template, o Common Information Model: can be understood as the template,
according to which the received network slice service profile is according to which the received network slice service profile is
translated. translated.
o Split Service Profile into Domains: the end-to-end service profile o Split Service Profile into Domains: the end-to-end service profile
is split into the service profiles inside different domains. is split into the service profiles inside different domains.
o Select Specific Implementation Technologies: there may be multiple o Select Specific Implementation Technologies: there may be multiple
available implementation technologies inside a domain, select the available implementation technologies inside a domain, select the
most appropriate one according to the service profile. As most appropriate one according to the service profile. As
Figure 3's example shows, since the end-to-end delay in Domain 1 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 is very small, the Flex-E will be selected. While in Domain 2 two
storage units are required, the NFV technology will be selected. storage units are required, the NFV technology will be selected.
o Map to Selected Technologies: necessary mapping to the controller/ o Map to Selected Technologies: necessary mapping to the controller/
orchestrator of selected technologies. orchestrator of selected technologies.
|Network Slice Service Profile |Network Slice Service Profile
| |
************************************************************************** **************************************************************************
*Top Level Network Orchestrator based on COMS * *Top Level Network Orchestrator based on COMS *
skipping to change at page 6, line 28 skipping to change at page 6, line 21
*********v*********** *********v******** **********v********* *********v*********** *********v******** **********v*********
* Flex-E Controller * * VPN Controller * * NFV Orchestrator * * Flex-E Controller * * VPN Controller * * NFV Orchestrator *
*********+*********** *********+******** **********+********* *********+*********** *********+******** **********+*********
| | | | | |
*********v*********** *********v********************v********* *********v*********** *********v********************v*********
* Physical/Logical * * Physical/Logical * * Physical/Logical * * Physical/Logical *
* Resources inside * * Resources inside * * Resources inside * * Resources inside *
* Domain 1 * * Domain 2 * * Domain 1 * * Domain 2 *
********************* **************************************** ********************* ****************************************
Figure 3: Advanced Architecture of COMS Figure 2: Advanced Architecture of COMS
5. Integration with NFV 5. Integration with NFV
This section details the integration of the NFV framework [NFV-MANO] This section details the integration of the NFV framework [NFV-MANO]
in the COMS architecture. in the COMS architecture.
Network slice providers aim to accommodate a myriad of use cases and Network slice providers aim to accommodate a myriad of use cases and
application scenarios from multiple tenants over a common network application scenarios from multiple tenants over a common network
infrastructure. To that end, network slice providers build up infrastructure. To that end, network slice providers build up
multiple network slice instances (NSIs), each customized to serve the multiple network slice instances (NSIs), each customized to serve the
skipping to change at page 7, line 20 skipping to change at page 7, line 13
makes use of the resources that are at its disposal, and efficiently makes use of the resources that are at its disposal, and efficiently
orchestrate them across NSIs. Although the network slice provider orchestrate them across NSIs. Although the network slice provider
can own these resources, we consider it rents them from one or more can own these resources, we consider it rents them from one or more
infrastructure owners following the Infrastructure-as-a-Service infrastructure owners following the Infrastructure-as-a-Service
(IaaS) paradigm. In this case, the network slice provider takes the (IaaS) paradigm. In this case, the network slice provider takes the
role of a network infrastructure tenant. Note that each of the three role of a network infrastructure tenant. Note that each of the three
actors presented here (network infrastructure owner, network slice actors presented here (network infrastructure owner, network slice
provider, and network slice tenant) defines a different provider, and network slice tenant) defines a different
administrative domain. administrative domain.
The NSIs shown in Figure 4 run parallel on a common shared transport The NSIs shown in Figure 3 run parallel on a common shared transport
network infrastructure. The transport network infrastructure network infrastructure. The transport network infrastructure
consists of connectivity resources that may span across multiple consists of connectivity resources that may span across multiple
administrative domains (i.e., different network infrastructure administrative domains (i.e., different network infrastructure
owners). These resources include WAN nodes and links providing owners). These resources include WAN nodes and links providing
reachability across geographically remote data centers, where the reachability across geographically remote data centers, where the
VNFs from different NSIs run. In particular, they connect together VNFs from different NSIs run. In particular, they connect together
the network connectivity endpoints (e.g., gateways) of those data the network connectivity endpoints (e.g., gateways) of those data
centers. centers.
To simultaneously serve the connectivity needs of the NSIs using To simultaneously serve the connectivity needs of the NSIs using
skipping to change at page 9, line 48 skipping to change at page 8, line 48
Network +-------+------+ +-----------------+ +------+-------+ Network +-------+------+ +-----------------+ +------+-------+
Infrastructure | Connectivity | | +-------------+ | | Connectivity | Infrastructure | Connectivity | | +-------------+ | | Connectivity |
Owner | Resources | | | Computing/ | | | Resources | Owner | Resources | | | Computing/ | | | Resources |
Domain +--------------+ | | Storage/ | | +--------------+ Domain +--------------+ | | Storage/ | | +--------------+
| |Connectivity | | | |Connectivity | |
| | | Resources | | | | | Resources | |
| | +-------------+ | | | +-------------+ |
| | Data Center | | | Data Center |
v +-----------------+ v +-----------------+
Figure 4: Integration of NFV framework in COMS architecture Figure 3: Integration of NFV framework in COMS architecture
To orchestrate the resources that are at its disposal (those provided To orchestrate the resources that are at its disposal (those provided
by the underlying network infrastructure owners), the network slice by the underlying network infrastructure owners), the network slice
provider has a single Resource Orchestrator. The main role of the provider has a single Resource Orchestrator. The main role of the
Resource Orchestrator is to dispatch this finite set of resources Resource Orchestrator is to dispatch this finite set of resources
across the operative NSIs in an optimal way, with the aim of across the operative NSIs in an optimal way, with the aim of
simultaneously satisfying their (potentially diverging) performance simultaneously satisfying their (potentially diverging) performance
requirements. To bring multiplexing gains and cost savings in this requirements. To bring multiplexing gains and cost savings in this
task, the Resource Orchestrator may take advantage of resource task, the Resource Orchestrator may take advantage of resource
sharing. Resource sharing introduces flexibility and efficiency in sharing. Resource sharing introduces flexibility and efficiency in
slice provisioning, as network slice provider's resources can be slice provisioning, as network slice provider's resources can be
dynamically allocated and released across NSIs according to the time- dynamically allocated and released across NSIs according to the time-
varying resource requirements that their tenants impose. This varying resource requirements that their tenants impose. This
approach requires an adequate resource management framework for the approach requires an adequate resource management framework for the
Resource Orchestrator that carefully finds an optimal solution, Resource Orchestrator that carefully finds an optimal solution,
enabling resource sharing among NSIs when necessary, while preserving enabling resource sharing among NSIs when necessary, while preserving
their performance isolation. their performance isolation.
As shown in Figure 4, each of the operative NSIs serving a network As shown in Figure 3, each of the operative NSIs serving a network
slice tenant comprises a tenant SDN controller, a Network Service slice tenant comprises a tenant SDN controller, a Network Service
Orchestrator, and an Operation Support System (OSS). On the one Orchestrator, and an Operation Support System (OSS). On the one
hand, the tenant SDN controller configures the VNFs at application hand, the tenant SDN controller configures the VNFs at application
level, and chains them to dynamically build up the network service(s) level, and chains them to dynamically build up the network service(s)
that are required in the NSI. For VNF configuration management, the that are required in the NSI. For VNF configuration management, the
tenant SDN controller uses southbound configuration protocols such as tenant SDN controller uses southbound configuration protocols such as
NETCONF. For VNF chaining management, it leverages the networking NETCONF. For VNF chaining management, it leverages the networking
capabilities provided by virtual switches/routers, sending them capabilities provided by virtual switches/routers, sending them
appropriate forwarding instructions using southbound control appropriate forwarding instructions using southbound control
protocols such as OpenFlow. On the other hand, the Network Service protocols such as OpenFlow. On the other hand, the Network Service
skipping to change at page 11, line 35 skipping to change at page 10, line 35
8. Acknowledgements 8. Acknowledgements
TBD TBD
9. Informative References 9. Informative References
[COMS-PS] "Problem Statement of Supervised Heterogeneous Network [COMS-PS] "Problem Statement of Supervised Heterogeneous Network
Slicing", <https://datatracker.ietf.org/doc/ Slicing", <https://datatracker.ietf.org/doc/
draft-geng-coms-problem-statement/>. 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] [I-D.boucadair-connectivity-provisioning-protocol]
Boucadair, M., Jacquenet, C., Zhang, D., and P. Boucadair, M., Jacquenet, C., Zhang, D., and P.
Georgatsos, "Connectivity Provisioning Negotiation Georgatsos, "Connectivity Provisioning Negotiation
Protocol (CPNP)", draft-boucadair-connectivity- Protocol (CPNP)", draft-boucadair-connectivity-
provisioning-protocol-15 (work in progress), December provisioning-protocol-15 (work in progress), December
2017. 2017.
[NFV-MANO] [NFV-MANO]
ETSI GS NFV-MAN 001, "Network Functions Virtualisation ETSI GS NFV-MAN 001, "Network Functions Virtualisation
(NFV); Virtual Network Functions Architecture", V1.1.1, (NFV); Virtual Network Functions Architecture", V1.1.1,
skipping to change at page 13, line 15 skipping to change at page 12, line 15
University of Granada University of Granada
Email: oadamuz@ugr.es Email: oadamuz@ugr.es
Pablo Ameigeiras Pablo Ameigeiras
University of Granada University of Granada
Email: pameigeiras@ugr.es Email: pameigeiras@ugr.es
Diego Lopez Diego Lopez
Telefonica Telefonica I+D
Email: diego.r.lopez@telefonica.com Email: diego.r.lopez@telefonica.com
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Telefonica Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 21 change blocks. 
54 lines changed or deleted 56 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/