devops for network function virtualisation: an architectural approach

TRANSACTIONS ON EMERGING TELECOMMUNICATIONS TECHNOLOGIESTrans. Emerging Tel. Tech. 2016; 27:1206–1215

Published online 25 July 2016 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/ett.3084

SPECIAL ISSUE ARTICLE

DevOps for network function virtualisation: anarchitectural approachHolger Karl1, Sevil Dräxler1, Manuel Peuster1, Alex Galis2, Michael Bredel3,Aurora Ramos4*, Josep Martrat4, Muhammad Shuaib Siddiqui5,Steven van Rossem6, Wouter Tavernier6 and George Xilouris7

1 Paderborn University, Paderborn, Germany2 University College London, London, UK3 NEC Laboratories Europe, Heidelberg, Germany4 ATOS Spain, Madrid, Spain5 Fundació i2CAT, Barcelona, Spain6 Ghent University – iMinds, INTEC, Gehnt, Belgium7 Institute of Informatics and Telecommunications, NCSR ‘Demokritos’, Greece

ABSTRACT

The Service Programming and Orchestration for Virtualised Software Networks (SONATA) project targets both the flexibleprogrammability of software networks and the optimisation of their deployments by means of integrating Developmentand Operations in order to accelerate industry adoption of software networks and reduce time-to-market for networkedservices. SONATA supports network function chaining and orchestration, making service platforms modular and easier tocustomise to the needs of different service providers, and introduces a specialised Development and Operations model forsupporting developers. © 2016 The Authors. Transactions on Emerging Telecommunications Technologies published byJohn Wiley & Sons, Ltd.

*Correspondence

Aurora Ramos, ATOS Spain, Madrid, Spain.E-mail: [email protected] is an open access article under the terms of the Creative Commons Attribution-NonCommercial-NoDerivs License, which permitsuse and distribution in any medium, provided the original work is properly cited, the use is non-commercial and no modifications oradaptations are made.

Received 6 April 2016; Revised 14 June 2016; Accepted 27 June 2016

1. INTRODUCTION

In the ongoing research discussion about the structureand architecture of 5G networks, a basic trend is evi-dent: the network will have to be much more flexibleand open to profound changes of its operation to matchevolving demands. These demands will not just evolvequantitatively but also qualitatively in that traffic with dif-ferent, yet unforeseeable, characteristics will have to besupported. An ideal approach to increase flexibility of asystem is to scale software, more precisely, of reconfig-urable and replaceable software. This is the core notionof providing conventionally fixed network functions viasoftware, typically in a virtualised environment: networkfunction virtualisation (NFV) [1]. It is a transformation thatrelies on software-based innovation on top of more generictelecommunications hardware.

This disruptive architecture is challenging to put intopractice. The value chain of the provisioning and opera-tion of networks will change and needs to be supportedby a technical environment. This environment will need tosupport a decrease in development time and improved net-work operations, including further overlapping functions.Opportunity also arises as the role of providing networkfunctionality taken up by a broader range of actors, nolonger limited to the vendor of network equipment. Thisallows a much higher degree of customisation of networkfunctions for the service developer, empowering them witha better deployment and greater control of their service.Conversely, the role of the operator of a network changesas well: instead of just running a system with essentiallyfixed functionality where only parameterisation is neces-sary, the dynamics provisioning and deploying new func-tions become daunting. If, in particular, provisioning willbecome a frequent action rather than a unique event, it must

1206 © 2016 The Authors. Transactions on Emerging Telecommunications Technologies published by John Wiley & Sons, Ltd.

H. Karl et al.

be supported by automation that spans across the devel-opment and the operational cycle of network functions, aswell as orchestration of needed resources—the technicalrole of an ‘orchestration platform’ becomes important andhas received considerable attention.

Taking such a comprehensive view of development andoperation of complex software is indeed a common trend ofmodern software engineering; it is commonly referred to as‘DevOps’ (a contraction of Development and Operations,to highlight the close integration of these two processes).It has not, however, taken root in the actual practice of thetelecommunication industry with respect to the operationof networks in an open fashion. This is the core shortcom-ing that the SONATA project [2] addresses, providing anintegrated development and operational process for virtu-alised network functions, along with the necessary support-ing tools like a service-adaptable and resource-adaptableorchestration platforms.

Section 2 provides a perspective of previous resultsrelated to SONATA (including research work, stan-dardisation initiatives and common trends in an initialgeneration pre-production open-source and commercialarchitectures). Section 3.1 looks into how SONATA’s chal-lenges would have to be reflected in a broader 5G architec-tural context. Specific requirements and challenges arisingfrom various use cases are presented in Section 4. Finally,Section 5 describes the actual SONATA contribution toa ‘softwarised’ network architecture. Section 6 concludesand previews future activities.

2. RELATED WORK

Network function virtualisation [3] is currently on oper-ators’ road maps for deployment, but at the time ofwriting mostly in a proof-of-concept stage of adoption.However, the arrival of software networks, supported bysoftware-defined networking [4] and NFV technologies,is a universally agreed milestone in the evolution oftelecommunications. Several open-source, standardisationand commercial solutions are being developed for NFVmanagement and orchestration [5] [‘MANO’, as EuropeanTelecommunications Standards Institute (ETSI) terms it] inanticipation of its widespread operational use.

2.1. Software development processes andtools for network function virtualisation

There is surprisingly little material available of soft-ware development for network functions or resulting ser-vices, let alone concrete tools to this end. The UnifyingCloud and Carrier Networks (UNIFY) project [6] deliv-ers some first insights on how to apply the DevOpsmodel to NFV. They provide a multicomponent debug-ging tool called Epoxide [7]. Compared with these tools,SONATA’s approach is a step forward and combines apowerful software development kit (SDK) with a flex-ible service platform to provide end-to-end support forservice developers.

2.2. Orchestration platforms

Simple cloud managers like provide the basic functionalityto deploy and manage single predefined virtual machinesbut cannot handle composed services. Other solutions,like OpenStack Heat [8], Terraform [9] and ApplicationDeployment Toolkit (ADT) [10], are able to deploy entireservices but do not focus on network function-specificneeds. Projects directly focusing on NFV service orches-tration can be divided into three categories. The firstconsists of research projects, like Network Functions asa Service over Virtualised Infrastructures (T-NOVA) [11]and UNIFY [6]. The second category consists of open-source projects such as OpenMANO [12] or OpenStackTacker [13] or open software-defined infrastructure [14].A third category is an initial generation of commer-cial solutions put forth by telecommunications vendors(expanding their platform, software and integration ser-vices to adapt to the disruptive change in the value chain)and supporting technology partners (classically in IT,cloud, etc. but recognising new market opportunities astelecom infrastructure becomes virtualised and software-based). Regardless of their origin, they offer similar func-tionality and characteristics when confined to the ETSINFVO specification, and significant differentiation is moreapparent when comparing their larger ecosystems thatextend beyond the scope of orchestration. This is consis-tent with the business strategy to provide all NFV-relatedneeds (through their own portfolio or partnerships).

UNIFY’s architecture [6] aims at automated anddynamic service creation and recursive resource orches-tration. Its global orchestrator includes optimisationalgorithms for placement of service components; service-specific actions related to placement and scaling aredeployed as a service component. T-NOVA is capable ofmanaging services distributed across several data centresbut only provides a simple, rule-based system to controlthe scaling and placement of deployed services. It also pro-vides a marketplace in which predefined services and vir-tual network functions (VNFs) can be traded. OpenMANOand OpenStack Tacker aim to be reference implementa-tions of the MANO layer defined in the ETSI NFV IndustrySpecification Group (ISG) architecture [15], but both areat the beginning of their development. Other orchestrationsolutions are Cloud4NFV [16] and vConductor [17].

All presented orchestration tools, to a great extent,follow the same principle and try to build a single orches-tration solution for different types of services. This createsmultiple restrictions for service developers as they cannotinfluence the orchestration process as such. Some of theexisting platforms allow expressing a limited and pre-defined set of preferences regarding monitoring, scalingand so on. within function descriptions. However, activelyinfluencing service-specific decisions, for example,placement and scaling of services and their components,is not fully supported by any of them. This is possiblewith SONATA’s service platform using function and

Trans. Emerging Tel. Tech. 27:1206–1215 (2016)© 2016 The Authors. Transactions on Emerging Telecommunications Technologies published by John Wiley & Sons, Ltd.

1207

DOI: 10.1002/ett

H. Karl et al.

service-specific manager programmes defined by theservice developer.

3. SONATA SCOPE AND ANOVERALL 5G ARCHITECTURE

3.1. Scope of SONATA functionality

SONATA aims at increasing the flexibility and programma-bility of 5G networks with a novel Service DevelopmentKit and a novel modular Service Platform and ServiceOrchestrator; it will bridge the gap between telecom busi-ness needs and operational management systems.

The scope of SONATA is depicted in Figure 1 wherethe outcome of the project is represented by the Ser-vice Development Kit, the Management System andthe Service Platform including a customisable ServiceOrchestrator, a Resource Orchestrator, a Service Infor-mation Base along with various enablers; we use herethe ETSI reference model as a terminological frame-work. In fact, while ETSI’s division into Service andResource Orchestrator can be mapped onto SONATA’sservice platform, SONATA is much more flexible in thisregard and allows not only replacing these orchestra-tion aspects individually, but even to change the divisionof work between these functions if so desired. This is

achieved by SONATA’s microservices-based architecture(Section 5.1.1); for example, the resource orchestrator cor-responds by and large to SONATA’s default placementplug-in.

3.2. 5G multi-service management

SONATA advocates a consistent view of 5G networkand compute functions, encompassing a wide conceptualrange of such functionality. SONATA functionality cov-ers the multi-service control layer and partially integratedmanagement and operation layer and the application andbusiness services layer. SONATA is also capable of incor-porating widely heterogeneous physical resources: variousaccess networks (esp., radio), aggregation and core net-works, software networks, data centre networks and mobileedge computing clouds.

A multi-service control layer is responsible for thecreation, operation and control of multiple dedicated com-munication network services running on top of a commoninfrastructure. SONATA’s functionality [18] for this layerincludes infrastructure abstraction, infrastructure capabil-ity discovery, catalogues and repositories, large numberof service and resource orchestration functions as plug-ins, information management functionality and enablersfor automatic reconfiguration of running services, that is,part of the integrated management layer.

Figure 1. SONATA scope.

1208 Trans. Emerging Tel. Tech. 27:1206–1215 (2016)© 2016 The Authors. Transactions on Emerging Telecommunications Technologies published by John Wiley & Sons, Ltd.

DOI: 10.1002/ett

H. Karl et al.

The business function layer maintains 5G application-related functions, organised in repositories, and DevOpstools necessary for the creation and deployment of ser-vices. SONATA’s functionality for this layer includesDevOps functionality: catalogues, monitoring dataanalysis tools, testing tools, packaging tools, editorsand basic functionality for application and serviceprogrammability.

Figure 2 depicts the way in which SONATA managesvarious underlying systems. The core idea is to endowSONATA with several infrastructure abstractions, each ofwhich is custom-tailored to the particular needs of theunderlying infrastructure. This allows both simple andcomplex of Virtual Infrastructure Managers (VIMs) to beused, as well as entire networks or single, for example,OpenStack instances to be integrated.

In summary, SONATA’s main contribution to 5G net-working is efficient integration of service programmability,domain orchestration functionality and DevOps function-ality. This will maximise the predictability, efficiency,security and maintainability of development and opera-tional processes around virtualised network functions andchain services.

4. USE-CASE-DRIVEN CHALLENGESAND REQUIREMENTS

4.1. Use cases and resulting requirements

The use cases facilitate the identification of requirementsof the SONATA framework while highlighting its fullpotential for future software networks. SONATA use cases[19] encompass a wide range of Information and Com-munication Technologies (ICT) domains and their networkservices as follows:

� Internet of Things: demonstrates SONATA’s abilityto monitor, classify and optimise Internet of Thingsnetwork traffic as an enabler of Smart City ecosystem.

� Virtual Content Delivery Networks (CDN): manifestsSONATA’s capabilities to enhance a virtual CDNservice with elasticity and programmability.

� Industrial networks: providing guaranteed, resilientand secure service delivery in vertical industrial net-works, such as a wind park.

� Virtual Evolved Packet Core: exhibits and assessesthe SONATA’s competence to enhance a virtualEvolved Packet Core service in an long-term evolu-tion mobile network.


1209

DOI: 10.1002/ett

Figure 2. SONATA’s relationship to heterogeneous underlying infrastructures.

H. Karl et al.

� Personal security service: targets the system’s poten-tial to offer on-demand network security services tomultiple tenants/users with differentiated policies andenable secure network access.

� Separate client and hosting service providers:demonstrates SONATA’s support for internetwork-ing between a client service provider and a hostingservice provider to accomplish an end-to-end service.

Based on these use cases, we can distil high-levelDevOps requirements for both the overall process of devel-oping network functions (SDK) as well as the runtimeplatform steering the management and life cycle of suchfunctions in an actual infrastructure/network—commonlycalled the orchestrator.

(1) Development model requirementsFor the development model, the following require-ments are elicited:

� Support for arbitrary network functions: Sup-port for all types of network functions must bepossible, irrespective of the technical domain.For example, both core networks as well aswireless fronthaul networks must be supported.To express the different requirements, suit-able annotation for network function and ser-vices must exist. Scenarios that pertain toboth network functions in the narrow senseas well as generic (mobile) edge/distributedcloud computing are in the purview of theSONATA system.

� Network functions form data flow graphs: Indi-vidual functions will not suffice to address allneeds; it is needed to group functions intogeneral graphs of functions which then con-stitute the actual service (i.e network service).This is in-line with current NFV specifications(Internet Engineering Task Force (IETF) servicechains [20]; ETSI service graphs).

� Reuse by recursive definitions: Reusing suchservice graphs mandates a recursive notion—a new service can be formed not only byusing primitive network functions but alsoby reusing other, simpler services. Hence, arecursive approach has to prevail in the soft-ware development concepts and descriptiontechniques.

� Reuse by dynamic composition: Recursive defi-nitions are the first stepping stone. This conceptbecomes really powerful if existing networkfunctions or service can be dynamically reusedand combined into new services without requir-ing new deployments (assuming the constitutingnetwork functions is multi-user-capable).

� Policy-driven support for developer’s service:Each service will not only have its own codethat deals with the actual data flows but also

have additional code that takes care of thedeployment and execution process in a man-ner tailored to the specific requirements of theservice—we refer to such code here simply as‘service-specific code’ and make this notionmore concrete in later sections. For example,scaling or placing a complex service requiresdecision logic that is rather specific to theparticular service; similarly, life cycle manage-ment is highly service-specific (e.g. mandating aparticular order in which virtual machines com-prising a service have to be booted and ini-tialised). This is impossible to achieve in aone-size-fits-all fashion.

As a consequence, we need to support both aspects ofa service’s code: the actual data-oriented code as wellas the caretaking code. This materialises as support-ing tools for the developer, in specification for whatto ship as a service, and how to be rendered by theorchestration platform, which must be able to exe-cute such service-specific code in a proper contextand with proper data.

(2) Orchestration platform requirementsSimilarly, for the orchestration platform, we canidentify the following core requirements:

� No one solution fits all: The large variabil-ity of services to be orchestrated, along withtheir own individual caretaking functions, man-dates that the orchestration platform must beable to execute service-specific code, but mustensure proper information hiding and isola-tion between these code pieces from differentservices.

� Design to support for evolution and maintain-ability: Assuming that an orchestration plat-form will ever have a stable, final form seemsoverly optimistic. Rather, the platform itselfmust be able to be extended by additional func-tionality or to replace existing one. This pre-cludes a monolithic design of the platform itself.A microservices-based approach, with indi-vidual modules executing particular aspects(together with the individual functions caretak-ing code) of an orchestration cycle, seems morepromising for adoption by network operatorsand their bespoke configuration of the platform.

� Support real-world’s manifold systems: Anorchestration platform should be able to sup-port a wide range of actual infrastructures onwhich services will be deployed. This rangesfrom bare-metal over simple hypervisors to full-fledged OpenStack installations conceived ofa single logical node. A particular exampleis sliced infrastructures, where the underlyinginfrastructure is divided into isolated ‘slices’,each of which has its own guaranteed resources[21]. In the simplest case, SONATA obtains


DOI: 10.1002/ett

H. Karl et al.

new slices from an external slicing system (inthe extreme case, one slice per service is con-ceivable). Alternatively, it might be promisingto integrate slicing functionality directly intoan orchestrator.

� Division and recursion on platform layer: Akinto the idea of recursion to describe services,it is promising to conceive infrastructure andorchestration platform itself in a recursiveway, as well. Sub-orchestrators can then bein charge of different domains or differentoperator networks, working together under theauspice of a higher-level orchestrator. The chal-lenge is to have the orchestrator itself exposean infrastructure-like interface. This recursiveapproach should also combine nicely with aslicing system.

These high-level requirements and associated chal-lenges are addressed by SONATA—the following sectionsshow how.

5. SOFTWARE-NETWORKTECHNOLOGIES

SONATA project’s main goal is to increase the flexi-bility and programmability of 5G networks in order tobridge the gap between telecom business needs and oper-ational management systems. In this chapter, an overviewof the SONATA architecture is provided, including a shortdescription of the main components. The service program-ming and orchestration framework consist of the SDK, theservice platform and different catalogues storing artefactsthat can be produced, used and managed by the SONATAsystem. Services developed and deployed by this systemrun on top of the underlying infrastructure accessible tothe SONATA system via a wide range VIMs; SONATA isfairly agnostic to the particular VIMs.

SONATA’s system design is based on the DevOps work-flow, which is supported by the integration between theSDK and the service platform. This workflow impliescontinuous deployment and continuous integration duringservice development. The main entity exchanged betweenthe SDK and the service platform is the service packageto be deployed and runtime information like monitoringdata and performance measurements regarding the servicepackage, which is provided to the service developer dur-ing the development phase, as well as the runtime. Thisinformation can be used for optimising, modifying anddebugging the operation and functionality of services.

The main characteristics of the SONATA architectureare explained in Section 5.1, followed by covering the fourmain actor roles in the SONATA platform (Section 5.2).For a full description of the current state of the SONATAarchitecture, please refer to the corresponding deliverable[18] at the time of this writing, to be updated during thecourse of the project.

5.1. Some architectural aspects

(1) A microservices-based orchestration platformThe high-level service deployment procedure is

illustrated in the service platform. Each VIM/WANInfrastructure Manager (WIM) provides the con-trolling service platform a view of the availableresources and capabilities of its underlying infras-tructure/network. A gatekeeper module in the serviceplatform is responsible for processing the incomingrequests. The service platform receives the servicepackages implemented and created with the helpof SONATA’s SDK and is responsible for placing,deploying, provisioning, scaling and managing theservices on existing cloud infrastructures. For thispurpose, it has modules for orchestrating and manag-ing the complete service chain, as well as managingon the VNF level. All artefacts needed to deploy theservice can be fetched from catalogues and reposito-ries. The platform can also provide direct feedbackabout the deployed services to the SDK, for example,monitoring data about a service or its components.SONATA’s service platform is designed with fullcustomisation possibility, providing flexibility andcontrol to both operators and developers. The coremechanism for this is a microservices-based plug-inarchitecture (Figure 3): all functionality that is to beprovided by an orchestrator is assigned to specificplug-ins, all of which are connected to a messagebus that ensures correct delivery semantics of allcontrol messages between these plug-ins. Some ofthese plug-ins implement exactly one function perorchestrator (e.g. the conflict resolver plug-in, whichensures that any possible resource conflicts betweenservices are resolved in a consistent, service-neutralfashion).

Other plug-ins can be customised by the deployedservice itself with caretaking code: these plug-insthen act as an executive (akin to Microsoft Window’soperating system concept) for this service-specificcode.

The service developer can ship the service packageto the service platform together with service-specificor function-specific caretaking code, expressing andrealising requirements and preferences. Such care-taking code is referred to in SONATA as service-specific managers and function-specific managers,respectively. Service-specific managers and function-specific managers can influence the service and VNFlife cycle management operations, for example, byspecifying desired placement or scaling behaviour.This grants the developer increased flexibility, con-trol and resilience of their service.

By virtue of a modular design in the Managementand Orchestration Framework of the service plat-form, the service platform operator can customise it,


1211

DOI: 10.1002/ett

H. Karl et al.

Figure 3. Main plug-ins into SONATA’s orchestrator.

for example, by replacing the conflict resolution orinformation management modules. SONATA’s ser-vice platform is described in more detail in projectdeliverable D2.2 [18]. This could be an operatorreplacing modules of the configurable service plat-form with alternatives to fit their software networkmanagement requirements and preferences.

(2) Recursive orchestrationA recursive structure can be defined as a design,

rule or procedure that is (partially) explained usinga simplified version of itself. In a network ser-vice context, this recursive structure can either be aspecific part of a network service or a repeated partof the deployment platform. Although different chal-lenges can be thought of, the general idea of reusingexisting patterns could reduce complexity and evenadd more flexible possibilities for extending theservice [22]. In Figure 4, recursive orchestration isshown as a SONATA service platform delegating(part of) the requested service to another instance ofa SONATA platform using a dedicated infrastructureadaptor.

Reclusiveness also leads to an easier managementof scalability. Monolithic software entities are proneto performance limitations from a certain workloadonwards. Scaling by delegating parts of the service

to multiple instances of the same software block isa natural way to handle more complex and largerworkloads or service graphs. If this reclusiveness istaken into account from the beginning of the devel-opment, the advantages of this approach will come ata minimal cost.

(3) An software development kit for network functionvirtualisation

The SDK supports service developers by provid-ing a service programming model and a develop-ment tool-chain. Figure 5 shows an overview of theforeseen SDK components. SONATA’s SDK designallows developers to define and test complex servicesconsisting of multiple network functions, with toolsthat facilitate custom implementations of individualnetwork functions. The implemented artefacts arestored in the developer’s private catalogues. More-over, service components can easily be obtained fromexternal catalogues using the foreseen interfaces. Theobtained artefacts can be directly used in a serviceor after being modified and tested using the SDKdevelopment tools. The service components and allthe information necessary for deployment and execu-tion of a service are bundled together into a package.The service package can be handed over to the ser-vice platform for actual deployment and for testing,debugging and profiling purposes.


DOI: 10.1002/ett

H. Karl et al.

Figure 4. Service deployment using the SONATA framework.

5.2. The main actors in SONATA

(1) End usersIt is the entity that consumes the network ser-

vice. Thus, an end user can be a private person oran enterprise, or even a network service provideror content provider. In the SONATA ecosystem,the end user requests the required network servicesfrom the network service developer—Figure 6 onlyshows the simpler case. That is, the end user andthe network service developer establish a customer–provider relationship that is regulated by a servicelevel agreement.

(2) Service developerIt is the developer of a software artefact, for

example, a VNF or, more specifically, a network ser-

vice, which can be composed of one or more VNFs.The SONATA SDK shall enable a DevOps envi-ronment for the development of network services.The network service developer can use the editor,debugging and packaging tools in the SONATA SDKalong with VNF catalogues to compose a networkservice that can then be moved to the SONATA ser-vice platform for deployment and execution. Thatis, the network service developer interacts with theend user for providing the network services and alsointeracts with the SONATA service platform operatorfor the deployment and operation of those networkservices. However, in the value chain, the developerand provider of such a service can of course beseparate entities.

(3) Service platform operatorThe service platform operator runs the SONATA

platform that manages the execution of network ser-vices. The SONATA service platform receives a net-work service in form of a package that is validatedthrough a series of quality assurance tests prior totheir storage in the service platform catalogue. Inaddition to validation, the service platform opera-tor also manages the deployment and execution ofnetwork services on virtual resources made avail-able by an infrastructure operator. As the SONATAservice platform supports reclusiveness, an opera-tor can manage multiple SONATA service platforminstances, as well. Hence, a responsibility of main-taining smooth operations for a network service, withrespect to its corresponding service level agreement,lies on the service platform operator. On one side, theservice platform operator interacts with the SONATA


1213

DOI: 10.1002/ett

Figure 5. Main components of SONATAs SDK.

H. Karl et al.

Figure 6. Main components and roles.

SDK for network services reception and, on the otherside, interacts with the infrastructure operator fortheir deployment and execution.

(4) Infrastructure operatorIt is the entity that actually operates the phys-

ical infrastructure, including computational, com-munication and storage resources. The SONATAecosystem does not distinguish between infrastruc-ture owner and infrastructure operator and treatthem as the same. This is because the main focusof SONATA is to reduce time-to-market for net-work services by accelerating and facilitating servicedevelopment, management and orchestration withDevOps adoption, all while ensuring features such asmulti-tenancy, reclusiveness and virtual networkslices are supported. The infrastructure operatorinteracts heavily with the service platform operatoras the network services are actually executed in thephysical infrastructure. This interaction is enabled bythe infrastructure abstraction layer in the SONATAservice platform. It is worth mentioning that in mostscenarios, the infrastructure operator will be the sameas the service platform operator. However, SONATAalso supports a use case where the system is engagedby separate entities for these roles, supporting morecomplex telecom provider business models.

6. CONCLUSIONS ANDFUTURE WORK

The SONATA architecture and resulting system push inno-vation in the evolving state of the art of NFV MANO andnetwork service development. From the approach outlinedearlier, we can draw four main conclusions.

Modular and customisable MANO plug-in architec-ture: the architecture structure provides hitherto unseen

levels of flexibility. Third-party developers are empoweredwith control over specific orchestration and managementfunctionalities pertaining to their own service withoutbeing able to influence other services. Similarly, a networkoperator has a wide range of control over how the serviceplatform should behave. For example, the service platformeffortlessly encompasses ETSI’s separation into resourceand service orchestration, but other orchestration modelsare supported as well. This boils down into a new notionof Orchestration-as-a-Service (OaaS): the orchestrationprocess itself can be customised on demand by the providerof a service but stays under the operator’s control.

Interoperable, agnostic framework: the resultingframework (incorporating both service platform anddeveloper support) is agnostic along multiple axes: it sup-ports multiple VIMs, multiple vendors, deployment atmultiple sites. It is also agnostic to whether these functionsare used in different kind of networks (mobile, optical, etc.)or in the fronthaul or backhaul part. It is agnostic withrespect to whether these services are stateless or stateful.

Efficient network service development and DevOps:SONATA provides service developers with an SDK forefficient creation, deployment and management of networkservices composed of VNFs along with the required chain-ing on the platform. The integration of SDK and serviceplatform links an existing gap between service developersand operators.

5G integration: SONATA easily embraces current 5Garchitecture developments and plays as a good citizenin the entire ecosystem. For example, slicing is wellsupported in various fashions, interacting with externalslicing systems as is bespoke network configuration forindustry verticals. Recursion support allows stacked ten-ant and wholesale deployments in new software networksbusiness models.


DOI: 10.1002/ett

H. Karl et al.

DevOps prototype: SONATA is an ongoing researchproject with its first code release scheduled early July2016. The consortium plans to demonstrate a first pro-totype showcasing the complete life cycle of a networkservice in the NFV environment with continuous monitor-ing by end of year 2016 as well as by exercising severalpilot applications that will be chosen among the use casesdescribed in Section 4. The final prototype with full featureset is scheduled for end of year 2017. Using this proto-type with its continuously increasing capabilities, we willelaborate on the reduction of development time. Using theSONATA systems, we expect the time to deploy a newnetwork service to be much faster compare with com-mon approaches today. Moreover, we expect a significantreduction of code to write in order to operate networkfunctions and services compared with existing technolo-gies. The proposed DevOps approach raises more technicalchallenges, for example, related to the update process ofrunning network functions and service. To this end, wewill investigate different approaches—again looking at thecomplete life cycle—and evaluate them in terms of perfor-mance, service continuity, resiliency and fault tolerance.Finally, we will compare the SONATA system with exist-ing solutions with respect to resource efficiency and overallservice performance.

REFERENCES

1. Chiosi M, Clarke D, Willis P, Reid A, et al. Networkfunctions virtualisation. Technical Report, White paperat the SDN and OpenFlow World Congress, ETSI, 2012.

2. SONATA project, 2015. Available from: http://sonata-nfv.eu/ [accessed on April 2016].

3. Mijumbi R, Serrat J, Gorricho J, Bouten N, De TurckF, Boutaba R. Network function virtualization: state-of-the-art research challenges. IEEE CommunicationsSurveys & Tutorials 2016; 18(1): 236–262.

4. McKeown N, Anderson T, Balakrishnan H, Parulkar G,Peterson L, Rexford J, et al. Openflow: enabling inno-vation in campus networks. ACM SIGCOMM ComputerCommunication Review 2008; 38(2): 69–74.

5. ETSI. NFV MANO. Available from: http://portal.etsi.org/portal/server.pt/community/NFV/367?tbId$=$79[accessed on April 2016].

6. Unify project, 2015. Available from: https://www.fp7-unify.eu/ [accessed on April 2016].

7. Lévai T, Pelle I, Németh F, Gulyás A. EPOXIDE: a mod-ular prototype for SDN troubleshooting. In ACM Confer-ence on Special Interest Group on Data Communication,London, 2015.

8. OpenStack heat, 2015. Available from: https://wiki.openstack.org/wiki/Heat [accessed on April 2016].

9. Terraform, 2015. Available from: https://www.terraform.io [accessed on April 2016].

10. Keller M, Peuster M, Robbert C, Karl H. A topology-aware adaptive deployment framework for elastic appli-cations. In 17th International Conference on Intelligencein Next Generation Networks (ICIN), Venice, Italy, 2013.

11. Xilouris G, Trouva E, Lobillo F, Soares JM, Carapinha J,McGrath M, et al. TNOVA: a marketplace for virtualizednetwork functions. In European Conference on Networksand Communications (EuCNC), Bologna, Italy, 2014.

12. OpenMANO, 2015. Available from: https://github.com/nfvlabs/openmano [accessed on April 2016].

13. OpenStack tacker, 2015. Available from: https://wiki.openstack.org/wiki/Tacker [accessed on April 2016].

14. Mamatas L, Clayman S, Galis A. A service-aware virtu-alized software-defined infrastructure. IEEE Communi-cations Magazine 2015; 53(4): 166–174.

15. ETSI NFV ISG. GS NFV-MAN 001 V1.1.1 networkfunction virtualisation (NFV); management and orches-tration, Dec. 2014.

16. Soares J, Dias M, Carapinha J, Parreira B, SargentoS. Cloud4NFV: a platform for virtual network func-tions. In IEEE 3rd International Conference on CloudNetworking (CloudNet), Luxemburg, 2014.

17. Shen W, Yoshida M, Minato K, Imajuku W. Conduc-tor: an enabler for achieving virtual network integrationas a service. Communications Magazine 2015; 53 (2):116–124.

18. Architecture design: deliverable D2.2—SONATA pro-ject. Available from: http://sonata-nfv.eu/sites/default/files/sonata/public/content-files/pages/SONATAD2.2ArchitectureandDesign.pdf [accessed on April 2016].

19. Use cases and requirements—deliverable 2.1—SOTATAproject. Available from: http://sonata-nfv.eu/use-cases[accessed on April 2016].

20. IETF service chaining. Available from: https://datatracker.ietf.org/wg/sfc/documents/ [accessed onApril 2016].

21. Argyropoulos C, Mastorakis S, Giotis K, AndroulidakisG, Kalogeras D, Maglaris V. Control-plane slicing meth-ods in multi-tenant software defined networks. In 2015IFIP/IEEE International Symposium on Integrated Net-work Management (IM), Ottawa, 2015; 3–4.

22. Szabo R, Kind M, Westphal FJ, Woesner H, Jocha D,Csaszar A. Elastic network functions: opportunities andchallenges. IEEE Network 2015; 29(3): 15–21.


1215

DOI: 10.1002/ett

http://sonata-nfv.eu/

http://sonata-nfv.eu/

http://portal.etsi.org/portal/server.pt/ community/NFV/367?tbId$=$79

http://portal.etsi.org/portal/server.pt/ community/NFV/367?tbId$=$79

https://www.fp7-unify.eu/

https://www.fp7-unify.eu/

https://wiki.openstack.org/wiki/Heat

https://wiki.openstack.org/wiki/Heat

https://www.terraform.io

https://www.terraform.io

https://github.com/nfvlabs/openmano

https://github.com/nfvlabs/openmano

https://wiki.openstack.org/wiki/Tacker

https://wiki.openstack.org/wiki/Tacker

http://sonata-nfv.eu/sites/default/files/sonata/public/content-files/pages/SONATAD2.2ArchitectureandDesign.pdf



http://sonata-nfv.eu/use-cases

https://datatracker.ietf.org/wg/sfc/documents/

devops for network function virtualisation: an architectural approach

Documents