This is an electronic reprint of the original article. This reprint may differ from the original in pagination and typographic detail. Powered by TCPDF (www.tcpdf.org) This material is protected by copyright and other intellectual property rights, and duplication or sale of all or part of any of the repository collections is not permitted, except that material may be duplicated by you for your research use or educational purposes in electronic or print form. You must obtain permission for any other use. Electronic or print copies may not be offered, whether for sale or otherwise to anyone who is not an authorised user. Taleb, Tarik; Afolabi, Ibrahim; Samdanis, Konstantinos; Yousaf, Faqir Zarrar On multi-domain network slicing orchestration architecture and federated resource control Published in: IEEE NETWORK DOI: 10.1109/MNET.2018.1800267 Published: 01/09/2019 Document Version Peer reviewed version Please cite the original version: Taleb, T., Afolabi, I., Samdanis, K., & Yousaf, F. Z. (2019). On multi-domain network slicing orchestration architecture and federated resource control. IEEE NETWORK, 33(5), 242-252. [8758980]. https://doi.org/10.1109/MNET.2018.1800267
Transcript
This is an electronic reprint of the original article.This reprint may differ from the original in pagination and typographic detail.
Powered by TCPDF (www.tcpdf.org)
This material is protected by copyright and other intellectual property rights, and duplication or sale of all or part of any of the repository collections is not permitted, except that material may be duplicated by you for your research use or educational purposes in electronic or print form. You must obtain permission for any other use. Electronic or print copies may not be offered, whether for sale or otherwise to anyone who is not an authorised user.
Taleb, Tarik; Afolabi, Ibrahim; Samdanis, Konstantinos; Yousaf, Faqir ZarrarOn multi-domain network slicing orchestration architecture and federated resource control
Published in:IEEE NETWORK
DOI:10.1109/MNET.2018.1800267
Published: 01/09/2019
Document VersionPeer reviewed version
Please cite the original version:Taleb, T., Afolabi, I., Samdanis, K., & Yousaf, F. Z. (2019). On multi-domain network slicing orchestrationarchitecture and federated resource control. IEEE NETWORK, 33(5), 242-252. [8758980].https://doi.org/10.1109/MNET.2018.1800267
On Multi-domain Network Slicing OrchestrationArchitecture & Federated Resource Control
Tarik Taleb†, Ibrahim Afolabi†, Konstantinos Samdanis‡, and Faqir Zarrar Yousaf±† Aalto University, Espoo, Finland‡ Nokia-Bell Labs, Munich, Germany
± NEC Laboratories Europe GmbH, Heidelberg, Germany
Abstract—A sophisticated and efficient network slicingarchitecture is needed to support the orchestration ofnetwork slices across multiple administrative domains.Such multi-domain architecture shall be agnostic of theunderlying virtualization and network infrastructure tech-nologies. Its objective is to extend the traditional orches-tration, management and control capabilities by means ofmodels and constructs in order to form a well-stitchedcomposition of network slices. To facilitate such com-position of networking and compute/storage resources,this paper introduces a management and orchestrationarchitecture that incorporates Software Defined Network-ing (SDN) and Network Function Virtualization (NFV)components to the basic 3GPP network slice manage-ment. The proposed architecture is broadly divided intofour major strata, namely Multi-domain Service Conduc-tor Stratum, Domain-specific Fully-Fledged OrchestrationStratum, Sub-Domain Management and Orchestration(MANO) and Connectivity Stratum, and Logical Multi-domain Slice Instance stratum. Each of these strata isdescribed in detail providing also the fundamental opera-tional specifics for instantiating and managing the resultingfederated network slices.
Index Terms—5G, network slicing, multi-domain, or-chestration, and network softwarization.
I. INTRODUCTION
The 5th Generation of Mobile Networks (5G) isenvisioned to revolutionize the communication serviceexperience, enabling also new applications. It is expectedto offer content-rich multimedia in a crowd and onthe move, support critical communications and allowmassive connectivity of sensors and actuators [1]. Such aplethora of services would accelerate emerging businessopportunities. It facilitates commercialization for verticalsegments without a network infrastructure by utilizingcustomized networks and cloud resources. Indeed, 5G
Tarik Taleb is also with the Faculty of Information Technology andElectrical Engineering, Oulu University, and with the Department ofComputer and Information Security, Sejong University, Seoul 05006,South Korea.
introduces the concept of network slicing, which is basedon virtualization and softwarization. Network slicingenables programmability and modularity in the provi-sioning of network resources with respect to specificvertical segment service requirements, thereby advancingthe apriori 4G monolithic architecture [2]. Typically, dif-ferent verticals offer applications with distinct and oftenconflicting service requirements in terms of bandwidth,latency, etc. Allowing a variety of verticals to use acommon infrastructure, requires an appropriate level ofisolation and QoS provisioning. This can only be ad-dressed via an efficient means of resource orchestrationand programmable management [3].
Network slices, allocated to verticals, can stretchacross greater geographical areas, i.e. between differ-ent countries, or encompass areas where coverage canonly be assured by combining resources from differentmobile operators. Likewise, vertical services may needcomputing and storage resources that can only be offeredby particular cloud providers to complement networkingcapabilities. Such slice deployment requires an efficientcombination of federated resources. Resources not onlyto provide the desired bandwidth, but to also cope withadditive constraints (e.g., latency or jitter) and multi-plicative constraints (e.g., end-to-end error rate proba-bility) across multiple administrative domains.
Fulfilling such requirements across a federated envi-ronment is challenging, not only from the perspectives ofdecomposing a slice request into respective domain(s),but also assuring its performance maintenance. This pa-per proposes a multi-domain network slicing orchestra-tion architecture introducing the notion of Multi-domainService Conductor stratum, which provides service man-agement across federated domains. The Multi-domainService Conductor stratum analyzes and maps the servicerequirements of incoming multi-domain slice requestsonto the respective administrative domains. It also main-tains the desired service performance throughout theentire service life-cycle. To handle the dynamics re-lated to federated resource allocation efficiently, a cross-
2
Virtual Network Slate
Virtual Compute/Storage Slate
Virtual Network Slate
Virtual Compute/Storage Slate
Virtual Network Slate
Virtual Compute/Storage Slate
Infrastructure Resources
Virtualization Layer
Fully-fledged Network Slice Instance (NSI)
Virtual Resource Slates for NSSI-1 Virtual Resource Slates for NSSI-2 Virtual Resource Slates for NSSI-3
Figure 1: Composition of a Fully-fledged Network Slice Instance
domain coordinator is introduced. Such cross-domaincoordinator aligns cloud and networking resources acrossfederated domains and carries out the life-cycle man-agement (LCM) operations of a multi-domain slice. Italso establishes and controls inter-domain transport layerconnectivity assuring the desired performance.
The remaining of this paper is organized as follows.Section II presents the fundamentals of network slicing,highlighting the challenges for slice management in amulti-domain federated environment. In view of thesechallenges and gaps, the details of our proposed multi-domain slice management framework are presented inSection III. Section IV describes the main procedures,while a discussion on open challenges is presented inSection V. Finally Section VI concludes the paper.
II. NETWORK SLICING CONCEPTS, KEY ENABLERS
AND OPEN ISSUES
A. Network Slicing in Single Administrative Domains
A network slice (NS) is a fundamental but complexattribute of a 5G network. According to NGMN [4], anNS is defined as a set of network functions, and resourcesto run these network functions, forming a completeinstantiated logical network to meet certain networkcharacteristics required by the Service Instance(s). In
other words, an NS is a basic substrate offered bymobile network operators from which multiple businessservices are deployed and run in an efficient and cost-effective manner. Virtualization is the key technologyenabler for realizing a fully or partially isolated NSInstance (NSI). It abstracts the physical and/or virtualinfrastructure resources, such as computation, network,memory, and storage, offering logical resources withcustomized policy and configuration parameters. Suchlogical resources are then assigned to different tenants,e.g., verticals, which form virtualized functions andoverlay connectivity fulfilling the desired service needs.
A Virtualized Network Function (VNF) can accommo-date simple network functions, e.g., virtual firewall, ormore complex ones, e.g., virtual mobile core network1.Each VNF is assigned a specific type and amountof virtualized-resources. VNFs are interconnected in aoverlay network topology order over well-defined virtualor logical links to create a Fully-Fledged NSI. A NSItypically consists of multiple Network Slice SubnetInstances (NSSIs) that represent a group of networkfunction instances and/or logical connectivity. An NSSIforms a part or complete constituents of an NSI [5].
1like the virtual Evolved Packet Core (vEPC)
3
Figure 1 illustrates the concept and composition of aFully-Fledged NSI, which consists of three NSSIs, eachbelonging to a different technology domain, e.g., RadioAccess Network (RAN), transport and core. The RANand core NSSIs are composed of VNF(s) interconnectedover logical transport links. A NSSI can, on its own, bea Fully-Fledged NSI, but then multiple NSSIs stitchedtogether can extend the service scope and thus createa new enhanced Fully-Fledged NSI. Each NSSI is es-tablished over an infrastructure that provides virtualizedresources, which are accompanied by the appropriateorchestration and management means forming the so-called slate, as shown in Figure 1. Each resource slateabstracts a particular type of resource and provides themeans of LCM and control towards the NSSI.
For example, a virtual compute or storage slate ischaracterized by virtual compute resources such as vir-tual Central Processing Unit (vCPU), virtual memory,and virtual storage capacity. Resource slates at the net-work edge can reduce latency by offering users com-bine caching and computation offloading capabilities [6].Equivalently, a virtual connectivity slate is characterizedby virtualized network resources, such as virtual networkinterface controller, logical links, virtual switches etc.Each NSSI is assigned a set of resource slates, the typeand amount of which depends on the requirements ofthe VNFs that are part of the NSSI. Resource slatesshall include an interface and data model, e.g., basedon YANG, that offer the means for providing LCM toNSSI directly or through the corresponding orchestratorand/or controller. Currently, proprietary interfaces maybe used for this purpose until standardized solution aredeveloped.
A comprehensive and well-coordinated managementsystem is required to facilitate an effective LCM of aFully-Fledge NSI. At minimum, the following manage-ment, orchestration and control entities are essential:• Network Slice Manager responsible for the config-
uration and operation of a mobile network serviceto a Fully-Fledge NSI.
• NFV MANO2 that instantiates and orchestrates therequested VNFs considering the supported avail-ability.
• SDN Controller that connects together VNFs form-ing service function chains and controls the trans-port layer connectivity.
3GPP has introduced an orchestration and manage-ment architecture in [5] consisting of: (i) a service man-agement function that analyzes incoming slice requests,
converting service requirements into networking onesand (ii) a network slice management function, whichperforms the mapping onto network resources and takescare of the LCM. Although the resource mapping pro-cess is carried out across different technology domains,including the RAN, transport and core, the current 3GPPefforts concentrate only on NSIs deployed and managedby a single administrative entity.
B. Multi-domain Slice Management
An end-to-end NS is deployed across multiple net-works, stretching across the RAN, transport and corenetwork segments; belonging to the same or differentadministrative domains. The process of establishing amulti-domain NSI leverages the benefits of recursivevirtualization as described in [7]. Recursive virtualizationallows a hierarchical network abstraction, wherein slatesoffer a logical resource view to NSSIs, and NSSIs inturn to the NSI. Each successively highest level enablesa greater abstraction within a broader scope hiding thelayer internals, while allowing a generic resource usage.Such a paradigm can easy the composition of NS acrossdifferent administrative borders, combining efficientlyand in a flexible manner different types of resources.
The main challenge is laid on the deployment and run-time management since the involved domains may notonly be geographically apart data centers interconnectedover a Wide Area Network (WAN) infrastructure, butmay belong to different administrative domains. Figure 2depicts a fully functional end-to-end NS across threeadministrative domains A, B and C, illustrating therespective physical infrastructure. A multi-domain NSIshall combine two or more Fully-Fledged NSIs thatbelong to different administrative domains facilitatingan end-to-end multi-domain (a.k.a federated) NSI. Theconstituent Fully-Fledged NSIs instantiated from thedifferent administrative domains are also referred to asNSSI of the multi-domain NSI.
To understand the inherent complexity, we list belowsome of the main processes involved when a slice requestis received from a 3rd party:
1) Mapping of the service requirements onto capabil-ity requirements.
2) Translating the capability requirements into:a) NSI resource requirements in terms of com-
pute, storage and networking resources.b) NSI topology and connectivity type, policy,
isolation and security requirements.3) Identifying the infrastructure-domains with the re-
quired resources, which can assure the end-to-endNSI functional and operational requirements.
Figure 2: Federated Network Slice Across Multiple Administrative Domains
4) Instantiating NSSIs in each infrastructure domainand then “stitching” them to create the federatedNSI.
5) Providing run-time coordination management op-erations across different domains for maintainingthe end-to-end NSI service integrity.
Such processes have several architectural implicationsrequiring effective controllers at different stratum levels.As shown in Figure 2, there is a need to have at leastthree levels of controllers. That is, two sub-domaincontrollers for the orchestration of Network FunctionVirtualization Infrastructure (NFVI) resources and net-working control. A domain-specific slice controller forthe orchestration and management of NSSIs within eachrespective domain, and an overarching end-to-end slicecoordinator for unifying the management of individualmulti-domain NSI.
A preliminary study towards a framework for vir-tualization across multiple administrative domains isintroduced in [8] elaborating the main concepts of iso-lation, programmability and performance maintenance,also including the fundamental functional components.
Logical resources from different administrative domainsare collected by a virtualization resource manager, whichacts as a broker allowing third parties to establish a vir-tual network optimized for supporting particular services.A federated slicing solution is presented in [9] intro-ducing the notion of multi-domain orchestrator, whichhandles slice requests for resources beyond its domain.The proposed multi-domain orchestrator analyzes therelated service requirements and directly contacts theappropriate neighboring domains performing resourcenegotiation. Once a slice is established, a peer-to-peermanagement plane is responsible for handling the LCMconsidering relevant service-oriented key performanceindicators, while coordinating closely with individualdomain-specific orchestrators.
A hierarchical multi-domain orchestration architectureis introduced in [10], based on the concept of recursiveabstraction and resource aggregation that “stitches” NSIheterogeneous resources initially on per domain leveland then across federated domains. A similar conceptis presented in [11] where an overarching Inter-slice Re-source Broker functional element is proposed to manage
5
Unified Connectivity Resource Manager
Unified Cloud Mediator
d
Logical Multi-Domain Network Slices
Tenants (Verticals, MVNO, APP Providers)
Multiple Administrative Domains
End-users
Fully-Fledged Network Slice Orchestration Plane
Domain-Specific VNF Catalogue
VNFM(s)
Virtual Resources
VNFs Domain
Slice A
Slice C Multi-Domain Service Conductor Plane
Service Conductor
Service Broker Service Repository
OSS/BSS
Service Management
Slice Life-Cycle Management
Sub-domain NFV MANO
NFVO Sub-domain Connectivity
Control
SDN Controller
Slice B
Virtualization Layer
Virtual Computing
Virtual Storage
Virtual Network
Network Resources
Storage Resources
Compute Resources
Physical Resources VIM/ VIM/WIM
VIM/WIM
Cross-Domain Slice Coordinator
Cross-Domain Slice Coordinator
Cross-Domain Slice Coordinator
VNF VNF
VNF
PNF
PNF Data Plane
VNF VNF
VNF VNF
Control Plane
Multi-Domain Network Slice Functions
Figure 3: Multi-domain Slicing Architecture.
and orchestrate resources for end-to-end slices acrossmultiple technology domains. Each domain facilitates alocal instance of the standard ETSI NFV-MANO inter-acting with the broker. Although different technologydomains may belong to a distinct administration, thesolution assumes a unified orchestration and manage-ment provided by a single administrative domain. Suchunified orchestration and management acts as aggregatorwithout supporting service federation to form an end-to-end multi-domain NSI.
With regard to multi-domain support, ETSI NFV todate has published two informative reports. The firstreport [12] deals with managing the connectivity of anNS deployed over multiple NFVI sites, referred to asNFVI-PoPs. A single MANO system then manages inter-connectivity issues over WAN links linking these NFVI-PoPs. The second report [13] highlights the differentarchitectural options and recommendations to supportMANO operations in multiple administrative domains.To manage multi-site/multi-domain NSIs, a direct ref-erence point between the NFV Orchestrator (NFVO)functional elements is recommended in each NFVI-PoP.Such a peer-to-peer approach does not only bring more
complexity, but is not optimal in view of the delaysensitive nature of MANO operations. In view of thechallenges and gaps discussed above, we present a novelmulti-domain architecture for the LCM of NSIs deployedacross heterogeneous federated infrastructure domains.
III. MULTI-DOMAIN ORCHESTRATION
ARCHITECTURE
The envisioned architecture for NS across multipleadministrative and technological domains is illustratedin Figure 3. The architecture takes into account scala-bility, with its fundamental components and functionsdescribed below.
A. Service Broker Stratum
The envisioned architecture introduces a functionalplane known as Service Broker [14] to handle incomingslice requests from verticals, Mobile Virtual NetworkOperators (MVNO), and application providers, with themain operations listed below:• NS admission control and negotiation considering
service aspects.
6
• Management of slice user/owner relationship en-abling a direct tenant interface with the federatedMulti-domain Service Conductor plane.
• NSI revenue management, which involves billingand charging of slice owners.
• NSI scheduling, i.e. start and termination time re-lated with slice composition and decommission.
Typically, a Service Broker collects abstracted servicecapability information regarding different administrativedomains, creating a global service support repository. Italso interacts with the Operating/Business Support Sys-tem (OSS/BSS) in order to collect business, policy andadministrative information when handling slice requests.
B. Multi-domain Service Conductor Stratum
The Multi-domain Service Conductor Stratum is re-sponsible for service orchestration and managementacross federated resources related with successfully ad-mitted slice requests. It consists of the following twomain building blocks:• Service Conductor that decomposes a slice request
towards different administrative domains and de-cides on the combination of domains, includingalso the cross-domain connectivity, i.e. “stitching”.It instantiates the Cross-domain Slice Coordinatorwith respect to a particular federated NSI to per-form LCM processes and assigns ownership rights,e.g., offered to a vertical or MVNO. A ServiceConductor also carries out potential service specificre-adjustments across the federated domains, i.e.,instantiating, modifying and decommissioning do-mains, upon request in case of performance degra-dation or service policy update.
• Cross-domain Slice Coordinator monitors, managesand controls the corresponding resources relatedwith a federated NSI, while ensuring secure andtrusted connectivity across administrative domains.It also serves as a mediator among federated re-sources, carrying out domain specific resource allo-cation and re-adjustments to compensate potentialperformance degradation. A Cross-domain SliceCoordinator performs federated compute, storageand network resource allocation with the help of:
1) Unified Cloud Mediator that interprets andtranslates the performance capability descrip-tion of heterogeneous cloud resources.
When a federated NSI is formed, the Multi-domainService Conductor Stratum achieves scalability by as-
signing a Cross-domain Slice Coordinator that can in-dependently point out domain and cross-domain servicemisbehaviors accurately for each NSI.
C. Fully-Fledged Network Slice Orchestration Stratum
The Fully-Fledged Network Slice Orchestration Stra-tum interacts with the Cross-domain Slice Coordinator,allocating internal domain resources for establishing afederated NSI. It also provides the corresponding LCMvia the following functional blocks:• Service Management Function analyzes the slice
request received from the Cross-domain Slice Co-ordinator and identifies the RAN and core networkfunctions, including value added services. It also de-termines logical links characterized by bandwidth,delay, jitter, packet loss, etc. In return, it feeds theCross-domain Slice Coordinator with service andperformance capability information related with theunderlying resources.
• Slice Life-Cycle Management Function identifiesthe appropriate network slice template from an asso-ciated catalogue and forms a logical network graph.Such graph is mapped to the underlying compute,storage and network resources corresponding to atechnology specific slate. For deploying particularslates, further information (e.g., the desired topol-ogy type such as multi-cast tree, policy and controlplane functions) can be provided. The Slice Life-Cycle Management Function is also responsible forthe instantiation, run-time and orchestration of aNSSI considering the resource slates within thesame administrative domain, performing monitoringand modification related operations.
• Sub-domain NFV MANO takes care of the VNF,computation or storage slates. It communicates withthe Slice Life-Cycle Management Function provid-ing an abstracted view of the underlying infras-tructure and performs the instantiation and run-timeoperations of the corresponding VNF, computationor storage slates with the assistance of the followingfunctional blocks:
1) NFVO is aware of the LCM related with theshare of virtual resources apportioned to eachslate under its control. It is the decision mak-ing entity for the allocation of available virtualresources, which is periodically reported bythe corresponding VIM/WIM and VNF Man-agers (VNFMs).
2) VNFM is in charge of the LCM (i.e., instanti-ating, monitoring, modifying, and terminating)VNFs. In collaboration with the NFVO, it is
7
responsible for allocating the optimal amountof resources to particular VNFs and for han-dling dynamic VNF re-configurations basedon received updates.
3) VIM/WIM is carrying out resource manage-ment functionalities, interacting also with theVNFs and virtualized network infrastructure.To simplify its deployment and enhance itsmodularity, VIM/WIM consists of:a) Virtual Network Resources Manager that
directly controls the networking resourceswithin the virtualized environment.
b) Virtual Compute Resources Managerworks closely with the NFVI storage andcomputing controller scaling up or downof virtual machine’s CPU resources.
c) Virtual Storage Resources Manager is re-sponsible for allocating the appropriateamount of virtual storage resources, ab-stracted directly from the NFVI.
• Sub-domain SDN Controller provides the networkconnectivity and service chaining among the allo-cated VNFs connecting remote cloud environmentsoptionally via Physical Network Functions (PNFs),e.g., routers or switches. It feeds the Slice Life-Cycle Management Function with an abstracted net-work resource view and monitoring reports for as-suring the desired Service Level Agreement (SLA)in case of a failure or performance degradation.The Sub-domain SDN Controller can leverage thebenefits of deep data plane programmability and in-formation centric networking for the transport layer.For integrating the Sub-domain SDN Controllerwith the NFV MANO architecture, two optionswere considered as documented in [15]. The SDNController being: (i) a part of VNFI interactingwith the VIM/WIM or (ii) an independent PNFentity linked with the NFVO, (typically via thecorresponding sub-domain OSS/BSS). The formersuits better a virtualized environment, while thelater a mixed, including PNFs.
D. Sub-domain Infrastructure Stratum
The Sub-domain Infrastructure Stratum consists of thephysical and virtual infrastructure containing:
• VNFs that are related with the hardware infras-tructure from where they can be deployed. Thesenetwork functions are typical 5G control plane anddata plane functions, or value added services suchas a firewall or Content Delivery Network (CDN).
• Virtual resources are the abstracted physical re-sources that VNFs are running directly on, i.e., thevirtual compute, storage and networking resources.
• Virtualization layer often referred to as the hypervi-sor that sits directly above the physical infrastruc-ture is responsible for partitioning the physical re-sources among the operating VNFs. It also abstractsthe underlying hardware resources and decouplesVNFs from hardware.
• Physical Infrastructure consists of the hardwareresources that provide processing, storage andnetwork connectivity functionalities to the VNFsthrough the virtualization layer. The computing andstorage physical resources are usually CommercialOff The Shelf (COTS) commodity servers withgeneral purpose CPUs and local or network attachedhard disk storage. Network resources are typicallyphysical switches and routers, but virtualized coun-terparts are also considered.
E. Multi-domain Orchestration: A Quantitative Analysis
To highlight and distinct the features and operationsof our architecture a quantitative analysis and compar-ison is provided. Other approaches considered includestandard efforts based on 3GPP, ONF-SDN, ITU-T andETSI NFV-MANO and representative research projectsfocusing on 5G-EX, 5G!Pagoda and 5G-NORMA. Tomake the analysis concise, the following set of featuresare selected:• Multi-domain support: Multiple administrative do-
mains and technology types including RAN• Multi-domain service and resource management:
Service broker, service management and federatedLCM
• Multi-domain tenant control: 3rd party NS con-trol/orchestration, programmability and recursivevirtualization
• Multi-domain resource “’stiching”: Unified multi-domain connectivity and cloud mediation
Table I summarizes the details of the quantitativeanalysis, showing the functional and operational featureswhere our proposed multi-domain architecture advancesthe state of the art.
IV. MULTI-DOMAIN NETWORK SLICE
ORCHESTRATION & MANAGEMENT PROCEDURES
To further expatiate on the orchestration of multi-domain network slicing, a series of operational proce-dures are elaborated considering slice configuration andmodification.
8
Table I: Network Slicing Orchestration Architectures and their Offered Support.
OrchestrationArchitectures
MultiAdmin.Domains
Multi Tech.Domains
RANOrch.
Broker:AC/Neg.
ServiceChain &SDN
ServiceMang.
FederatedLCM
3rd PartyCntl./Orch.
Program-ability
RecursiveVirtualiz.
Unif.Connct.Mgmt.
Unif.CloudMed.
3GPP 28.530 [5] 7 3 3 7 7 3 3 7 7 7 7 7
SDN TR-526 [7] 3 7 7 7 3 3 3 3 3 3 7 7
ITU-TY.3011 [8]
3 3 7 3 7 3 3 3 3 3 3 7
5G-EX [9] 3 3 7 7 7 3 3 7 3 7 7 3
5G!Pagoda [10] 3 3 3 7 3 7 3 7 3 7 3 3
5G-Norma [11] 7 3 3 3 3 7 7 3 3 7 7 7
NFV-MANOMD [13]
3 3 7 7 7 7 3 7 3 7 7 3
Proposed MDO 3 3 3 3 3 3 3 3 3 3 3 3
A. Multi-domain Network Slice Configuration
A multi-domain NSI slice is instantiated followingthe procedure illustrated in Figure 4. A slice requestfirst arrives at the Service Broker, which performs theadmission control and negotiation with the requestingtenant considering the OSS/BSS policy and rules. Suc-cessful requests are forwarded to the Service Conductor,which analyzes the service requirements selecting theappropriate domains before instantiating a Cross-domainSlice Coordinator for the newly allocated multi-domainNSI. The Service Conductor or optionally the requestingtenant once authorized, programs the Cross-domain SliceCoordinator providing essential information related tothe desired service type (e.g., SLA and policy).
B. Multi-domain Network Slice Modification
Once the Cross-domain Slice Coordinator is config-ured, the Service Conductor provides the correspond-ing service decomposition details of the slice request.The Cross-domain Slice Coordinator relies on the Uni-fied Cloud Mediator for guidance on interpreting theslice requirements related with VNFs and value addedservices across heterogeneous platforms. Cross-domainconnectivity is established through the Unified Connec-tivity Resource Manager. Thereafter, the Cross-domainSlice Coordinator establishes a secure communicationwith each Service Management Function in the rel-ative administrative domain. It then provides servicetype specifics (e.g., SLA and policy) related to thecorresponding slice request. Each Service ManagementFunction in turn performs a mapping analysis to identifythe network resources, i.e. network functions, valueadded service and connectivity, that correspond to certain
technology sub-domains and then informs the Slice Life-Cycle Management Function.
The Slice Life-Cycle Management Function selectsthe appropriate slice template and creates the desired“slice resource graph”. It then carries out the resourceconfiguration towards the corresponding sub-domain byissuing a request towards the respective Sub-domainNFV MANO and/or Sub-domain-specific SDN Con-troller, which in turn needs to create the desired NFV,computing and connectivity slate. There are two majoroptions when configuring an NFV or computing slate:(i) the Sub-domain NFVO forwards the request directlyto the corresponding VIM or (ii) it communicates therequest to the relevant VNFM. When the request directlyreaches the VIM, it represents a situation of resourcescaling related with a shared VNF resource. However,requests for instantiating VNFs are handled by the Sub-domain VNFM. For the connectivity slate, the Sub-domain SDN Controller performs the necessary networkconfigurations to establish the transport layer and relatedservice chain. A multi-domain NSI becomes operationalwhen all domain-specific NSSIs and cross-domain con-nectivity are configured successfully. Once the resourcesare granted, an acknowledgement shall be returned to thetenant, updating also the Service Broker.
1) Scenario I: Multi-domain Resource Modification:A resource modification request typically concerns aparticular slate and is handled within the correspondingSub-domain NFVO or SDN controller via conventionalmechanisms that scale up or down VNF resources orperform routing alternations. When a modification re-quest relies on resource re-configuration beyond the ca-pabilities of a sub-domain, e.g. a certain VNF cannot be
9
Tenant (Slice Provider)
Service Broker Service Conductor
Cross-Domain Slice Coordinator
Unified Connectivity Resource Manager
Unified Cloud Mediator
Service Management
Slice Life-Cycle Management
Slice Request
i. Admission control ii. Negotiation
Slice Request
i. Service Analysis ii. Select Domains
Instantiate
Coordinator
Optionally: Tenant Programs
the Coordinator
Multi-domain Service Conductor Stratum
Fully-Fledged Network Slice Orchestration Plane
Cross-domain
Connectivity Cloud Resource Translation
Domain Specific Slice Request
Maps Slice Req. to Network Resources
Network Resource Req.
Abdelhamid Taha
NFVO
i. Gets Slice Template ii. Creates Slice Graph
Connectivity Req.
VNF Instantiation Req.
Instantiates Service Chain
Connectivity ACK Instantiate
VNFs
VNF Instantiation ACK
Sub-domain SDN
Sub-domain MANO
SDN Controller
Slice Established Domain Specific Slice ACK
Slice Request
Slice Request ACK Slice Request ACK
Slice Request ACK
Figure 4: Sequence diagram for creating a multi-domain slice.
scaled up further from the same sub-domain but insteadcan be configured into a different one; the connectivityand VNF reconfiguration would be handled by the SliceLife-Cycle Management Function. Figure 5a providesan overview of such resource modification procedure.A new resource allocation can then be determined withthe Slice Life-Cycle Management Function instructingthe corresponding sub-domain SDN controller and/orNFVO about the related modifications that need to takeplace. The NFVO instantiates/terminates or modifies theindicated VNF(s). It instructs the VNFM and VIM tocarry out the corresponding re-configurations or resourcescaling up/down including the reclamation of unusedresources. The SDN controller then updates the servicechain, providing an acknowledgement all the way back.
2) Scenario II: Multi-domain Service Modification:In case of an unsuccessful resolution, the Slice Life-Cycle Management Function invokes the Service Man-agement to check other potential resource mapping forre-assigning VNFs and connectivity on different sub-domains. Such a process can lead the Slice Life-CycleManagement Function to re-assign a “slice resourcegraph” that may result in a different resource allocationacross sub-domains. If the Service Management function
fails to identify a valid resource re-mapping, then asingle domain alone cannot handle the slice modificationrequest and hence the Cross-domain Slice Coordinatorneeds to re-assign the allocated resources differentlyacross the federated domains.
The Cross-domain Slice Coordinator is a federatedNSI manager, which assigns logical resources, whileperforming resource monitoring and control consideringthe desired performance targets. Once a modificationrequest cannot be handled by rearranging the allocatedresources among the involved sub-domains, the Cross-domain Slice Coordinator instructs the Multi-domainService Conductor to modify the service realization in-volving optionally other domains not previously utilizedwith the guidance of the Service Broker. Figure 5billustrates the main processes for modifying the allocatedservices as a response to a modification request.
The Multi-domain Service Conductor analyzes onceagain the service requirements with the objective todecompose a slice request across a different set offederated domains. Once this is accomplished, it informsthe Cross-domain Slice Coordinator about the modifiedservice mapping. The Cross-domain Slice Coordina-tor identifies the type of modification with respect to
10
Cross-Domain Slice Coordinator
Service Management
Slice Life-Cycle Management
Multi-domain Service Conductor Stratum
Fully-Fledged Network Slice Orchestration Plane
Abdelhamid Taha
NFVO
Sub-domain SDN
Sub-domain MANO
SDN Controller
Resource Modification that cannot be Handled Locally
Calculate new Slice Graph (new domains)
VNF Modification Reply VNF Instantiation Req.
Connectivity Req.
Instantiates Service Chain
Instantiate VNFs
Connectivity ACK
VNF Instantiation ACK
VNF Modification Req.
Connectivity Modification Req.
Connectivity and/or NVF Modification
If Life-Cycle Management cannot resolve modification req.
Modified Network Resource Req.
Modify Slice Mapping Req.
Maps Slice Req. to Network Resources
Modify Slice Cross-domain Connectivity
AND/OR domain-specific VNF allocation
If Service Management cannot resolve modification req.
(a) Scenario I: Sequence diagram for updating the federated resources of a multi-domain slice.
Service Conductor
Cross-Domain Slice Coordinator
Unified Connectivity Resource Manager
Unified Cloud Mediator
Service Management
Multi-domain Service Conductor Stratum
Fully-Fledged Network Slice
Orchestration Plane
Cannot resolve Domain Specific Modification req.
Modify Slice Cross-domain Connectivity
AND/OR domain-specific VNF allocation
i. Avail. Cross-domain connectivity ii. VNF support in other domains
Modify Cross-domain
Connectivity
Cloud Resource Translation
Modify Domain Specific Slice
Service Management
Fully-Fledged Network Slice
Orchestration Plane
i. Service Analysis of Modification Req. ii. Select Different Federated Domains
If Coordinator cannot Resolve Modification Req. on existing Resources
Service Broker
Modify Service Mapping
Service Availability Update
Service Mapping Update
Modify Domain Specific Slice ACK
i. Maps Slice Modification Req. to Network Resources ii. Trigger Life-Cycle Manager to carry out Modification Req.
(b) Scenario II: Sequence diagram for updating the service across multiple domains.
particular domains, i.e. allocate new, scale up/down,or terminate resources, relying on the Unified CloudMediator and Unified Connectivity Resource Manager.The Cross-domain Slice Coordinator then provides adomain specific slice modification request to the Ser-vice Management function. Each Service Managementfunction in turn performs a mapping analysis to identifythe desired modifications or allocation of network re-sources that correspond to certain sub-domains. It thentriggers the Life Cycle Manager to carry out the relatedmodification requests by involving the respective Sub-domain NFV MANO and/or SDN Controller. Once thedesired modifications take place, an acknowledgement isreturned to each Service Management function and thento the Cross-domain Slice Coordinator.
V. DISCUSSION & OPEN CHALLENGES
Multi-domain NS orchestration and management hasnot been fully explored with various deployment specificissues being still open. Herein, we explore three funda-mental emerging aspects relevant to service managementinterfaces, resource isolation and sharing, and servicebased management plane.
A. Service Management Interfaces & Service Profiling
The wide-adoption of slicing relies on standardizedinterfaces and relevant information models, which canabstract service capabilities and resource requirementshiding the network specifics. Currently, RESTfull modelscan be used by 3rd parties, e.g., verticals, for programma-bility purposes, facilitating also information exchangeand control among different technology and/or adminis-trative domains. A number of information models existsand are currently under development to convey trans-port and cloud capabilities towards the mobile networkmanagement plane including L3SM3/L2SM4 and NFV-IFA Os-Ma-Nfvo5. Although such data models aim toenrich the NS management plane, they are not takinginto account: (i) multi-domain connectivity and controlconsiderations, neither (ii) resiliency and performancemeasurements on federated resources.
Besides the development of data models, when acquir-ing cloud and/or networking resources, it is essential toanalyze and map the service requirements of the corre-sponding slice into relevant resources. A NSI may/may
3Q. Wu, S. Litkowski, L. Tomotaki, K. Ogaki, YANG Data Modelfor L3VPN Service Delivery, IETF RFC 8299, Jan. 2018.
4B. Wen, G. Fioccola, C. Xie, L. Jalil, A YANG Data Model forLayer 2 Virtual Private Network (L2VPN) Service Delivery, IETFRFC 8466, Oct. 2018
5ETSI GS NFV-IFA, Os-Ma-Nfvo reference point, Interface andInformation Model Specification, Oct. 2016
Figure 6: A service based management architecture formulti-domain slicing.
not serve one type of traffic, while the connectivity andresource demand may not be equally distributed amongall indicated end-points. Service profiling algorithmsare hence needed to optimize the mapping of allocatedresources especially for federated environments.
B. Resource Sharing & Isolation
The notion of resource sharing and isolation has afurther significance when considering federated domains.Selecting which functions and connectivity resourcesshall be shared or kept dedicated impacts the end-to-end performance and the economic cost. Realizing acommon control plane and linking it to a dedicated oneper slice considering cross-domain resources taking intoaccount, e.g. latency and resource utilization, is yet to beexplored. Security is another isolation-relevant issue forconfiguring and operating network slices with federatedresources. Two security aspects should be consideredincluding authorization and encryption. Cross-domain
12
security can be carried out by extending border securityprotocols among different administrative domains incoordination with the multi-domain service management.
C. A Service Based Network Management Architecture
A service based architecture [16] relies on a com-munication bus that offers function inter-connectivityinstead of point-to-point interfaces. A mediator, referredto as function repository, assists registered functionsto cooperate based on service needs by allocating alight-weighted interface via the communication bus. Inthis way management services can be modified in-dependently, i.e. being modular, with minimal impactamong each other and management capabilities can becustomized considering the needs of a particular NSI.
A preliminary service based architecture vision formulti-domain slicing is illustrated in Figure 6 followingthe Zero touch network and Service Management(ZSM) paradigm6. An intra-domain bus is envisionedto connect orchestration and control functions per slate.Different technology slates including the related serviceand resource management can then interact via aninter-domain integration fabric forming a Fully-FledgedNS orchestration plane. In each multi-domain NSI, across-domain slice orchestrator manages a NS servicecombining diverse Fully-Fledged orchestration planesrelated with the RAN, transport and core network via aninter-domain fabric. In addition, it interacts via an intra-domain bus internally within the multi-domain serviceconductor plane for carrying out service managementand configuration procedures. Certain capabilities andoperational details of such architecture are still open,including the function repository, the organization ofdata management states and the notion of statelessmanagement, where the processing and storage isseparated. The interaction with the control plane andthe integration of data analytics are yet further issues tobe explored.
VI. CONCLUSIONS
This paper elaborates a multi-domain orchestrationand management architecture and framework to addressthe service challenges of network slicing when utilizingfederated resources. In particular, a multi-domain ServiceConductor plane is introduced considering: (i) its mainfunctional components including the Cross-domain SliceCoordinator and its assisting Unified Connectivity Re-source Manager and Unified Cloud Mediator elements,
and (ii) inter-working issues with the conventional singleadministrator Fully-Fledged network domain, whereinNSSIs are established by combining computing, storageand network slates with RAN, transport and core networkcapabilities. The main operations are elaborated consid-ering a multi-domain NSI instantiation and management,bringing also an insight into the further architectural andoperational challenges.
ACKNOWLEDGMENT
This work was partially supported by the EuropeanUnion’s Horizon 2020 Research and Innovation Pro-gram through the 5G!Pagoda project and the MATILDAProject with Grant No. 723172 and No. 761898 respec-tively. It was also supported in part by the 6Genesisproject under Grant No. 318927.
REFERENCES
[1] GSMA Alliance, Network Slicing: Use Case Requirements,Apr. 2018.
[2] 3GPP TS 23.501, System Architecture for the 5G System.Rel.15, March 2018
[3] I. Afolabi, T. Taleb, K. Samdanis, A. Ksentini, H. Flinck,“Network Slicing & Softwarization: A Survey on Principles,Enabling Technologies & Solutions”, IEEE CommunicationsSurveys & Tutorials, Mar. 2018
[4] NGMN Alliance, Description of Network Slicing Concept,NGMN 5G P1 Requirements & Architecture, Work StreamEnd-to-End Architecture, Version 1.0, Jan. 2016.
[5] 3GPP TS 28.530, Management of 5G networks and networkslicing; Concepts, use cases and requirements, Rel.15, Apr.2018.
[6] M. Chen, Y. Hao, L. Hu, M. S. Hossain and A. Ghoneim,“Edge-CoCaCo: Toward Joint Optimization of Computation,Caching, and Communication on Edge Cloud,” in IEEE Wire-less Communications, vol. 25, no. 3, pp. 21-27, JUNE 2018.
[7] ONF TR-526, Applying SDN Architecture to 5G Slicing, Issue1, Apr. 2016.
[8] ITU-T Y.3011, Framework of Network Virtualization for FutureNetworks, Jan. 2012.
[9] R. Guerzoni, et al., “Analysis of end-to-end Multi-domainManagement and Orchestration Frameworks for Software De-fined Infrastructures: An Architectural Survey”, Transactions onEmerging Telecommunications Technologies, Vol. 28, No. 4,Apr. 2017.
[10] I. Afolabi. A. Ksentini, M. Bagaa, T. Taleb, M. Corici, A.Nakao, “Towards 5G Network Slicing over Multiple-Domains”,IEICE Transactions on Communications, Vol.100B, No.11,Nov. 2017.
[11] 5G NORMA, “D3.3: 5G NORMA network architecture - Fi-nal report”, September 2017, available at https://5gnorma.5g-ppp.eu/dissemination/public-deliverables.
[12] ETSI NFV ISG, “Network Function Virtualisation (NFV);Management and Orchestration;Report on Management andConnectivity for Multi-Site Services,” ETSI GR NFV-IFA 022V3.1.1, 2018.
[13] ETSI NFV ISG, “Network Function Virtualisation (NFV);Management and Orchestration;Report on architecture optionsto support multiple administrative domains,” ETSI GR NFV-IFA 028 V3.1.1, 2018.
13
[14] K.Samdanis, X. Costa-Perez, and V. Sciancalepore, “From net-work sharing to multi-tenancy: The 5G network slice broker”,IEEE Communications Magazine, Vol.54, No.7, Jul. 2016.
[15] F.Z. Yousaf, M. Bredel, S. Schaller, and F. Schneider, “NFVand SDN—Key Technology Enablers for 5G Networks”, IEEEJournal on Selected Area, Vol.35, No.11, Nov. 2017.
[16] NGMN, Service-Based Architecture in 5G, V1.0, Jan 2018
