See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/305648004

DevOps for network function virtualisation: An architectural approach

Article  in  Transactions on Emerging Telecommunications Technologies · July 2016

DOI: 10.1002/ett.3084

CITATIONS READS

18 362

11 authors, including:

Alex Galis Aurora Ramos

University College London Atos S.A.
212 PUBLICATIONS   2,377 CITATIONS    21 PUBLICATIONS   63 CITATIONS   

SEE PROFILE SEE PROFILE

Muhammad Shuaib Siddiqui Wouter Tavernier

i2CAT Internet and Digital Innovation in Catalonia Ghent University
30 PUBLICATIONS   101 CITATIONS    75 PUBLICATIONS   367 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

T-NOVA View project

H2020 5GTANGO View project

All content following this page was uploaded by George Xilouris on 15 November 2017.

The user has requested enhancement of the downloaded file.

 TRANSACTIONS ON EMERGING TELECOMMUNICATIONS TECHNOLOGIES
Trans. Emerging Tel. Tech. (2016)
Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/ett.3084

SPECIAL ISSUE ARTICLE

DevOps for network function virtualisation: an

architectural approach
Holger 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, Germany
2 University College London, London, UK
3 NEC Laboratories Europe, Heidelberg, Germany
4 ATOS Spain, Madrid, Spain
5 Fundació i2CAT, Barcelona, Spain
6 Ghent University – iMinds, INTEC, Gehnt, Belgium
7 Institute of Informatics and Telecommunications, NCSR ‘Demokritos’, Greece

ABSTRACT
The Service Programming and Orchestration for Virtualised Software Networks (SONATA) project targets both the flexible
programmability of software networks and the optimisation of their deployments by means of integrating Development
and Operations in order to accelerate industry adoption of software networks and reduce time-to-market for networked
services. SONATA supports network function chaining and orchestration, making service platforms modular and easier to
customise to the needs of different service providers, and introduces a specialised Development and Operations model for
supporting developers. Copyright © 2016 John Wiley & Sons, Ltd.

*Correspondence
Aurora Ramos, ATOS Spain, Madrid, Spain.
E-mail: [email protected]
Received 6 April 2016; Revised 14 June 2016; Accepted 27 June 2016

1. INTRODUCTION support a decrease in development time and improved net-

work operations, including further overlapping functions.
In the ongoing research discussion about the structure Opportunity also arises as the role of providing network
and architecture of 5G networks, a basic trend is evi- functionality taken up by a broader range of actors, no
dent: the network will have to be much more flexible longer limited to the vendor of network equipment. This
and open to profound changes of its operation to match allows a much higher degree of customisation of network
evolving demands. These demands will not just evolve functions for the service developer, empowering them with
quantitatively but also qualitatively in that traffic with dif- a better deployment and greater control of their service.
ferent, yet unforeseeable, characteristics will have to be Conversely, the role of the operator of a network changes
supported. An ideal approach to increase flexibility of a as well: instead of just running a system with essentially
system is to scale software, more precisely, of reconfig- fixed functionality where only parameterisation is neces-
urable and replaceable software. This is the core notion sary, the dynamics provisioning and deploying new func-
of providing conventionally fixed network functions via tions become daunting. If, in particular, provisioning will
software, typically in a virtualised environment: network become a frequent action rather than a unique event, it must
function virtualisation (NFV) [1]. It is a transformation that be supported by automation that spans across the devel-
relies on software-based innovation on top of more generic opment and the operational cycle of network functions, as
telecommunications hardware. well as orchestration of needed resources—the technical
This disruptive architecture is challenging to put into role of an ‘orchestration platform’ becomes important and
practice. The value chain of the provisioning and opera- has received considerable attention.
tion of networks will change and needs to be supported Taking such a comprehensive view of development and
by a technical environment. This environment will need to operation of complex software is indeed a common trend of

Copyright © 2016 John Wiley & Sons, Ltd.

 H. Karl et al.

modern software engineering; it is commonly referred to as like OpenStack Heat [8], Terraform [9] and Application
‘DevOps’ (a contraction of Development and Operations, Deployment Toolkit (ADT) [10], are able to deploy entire
to highlight the close integration of these two processes). services but do not focus on network function-specific
It has not, however, taken root in the actual practice of the needs. Projects directly focusing on NFV service orches-
telecommunication industry with respect to the operation tration can be divided into three categories. The first
of networks in an open fashion. This is the core shortcom- consists of research projects, like Network Functions as
ing that the SONATA project [2] addresses, providing an
a Service over Virtualised Infrastructures (T-NOVA) [11]
integrated development and operational process for virtu-
and UNIFY [6]. The second category consists of open-
alised network functions, along with the necessary support-
source projects such as OpenMANO [12] or OpenStack
ing tools like a service-adaptable and resource-adaptable
orchestration platforms. Tacker [13] or open software-defined infrastructure [14].
Section 2 provides a perspective of previous results A third category is an initial generation of commer-
related to SONATA (including research work, stan- cial solutions put forth by telecommunications vendors
dardisation initiatives and common trends in an initial (expanding their platform, software and integration ser-
generation pre-production open-source and commercial vices to adapt to the disruptive change in the value chain)
architectures). Section 3.1 looks into how SONATA’s chal- and supporting technology partners (classically in IT,
lenges would have to be reflected in a broader 5G architec- cloud, etc. but recognising new market opportunities as
tural context. Specific requirements and challenges arising telecom infrastructure becomes virtualised and software-
from various use cases are presented in Section 4. Finally, based). Regardless of their origin, they offer similar func-
Section 5 describes the actual SONATA contribution to tionality and characteristics when confined to the ETSI
a ‘softwarised’ network architecture. Section 6 concludes NFVO specification, and significant differentiation is more
and previews future activities.
apparent when comparing their larger ecosystems that
extend beyond the scope of orchestration. This is consis-
2. RELATED WORK tent with the business strategy to provide all NFV-related
needs (through their own portfolio or partnerships).
Network function virtualisation [3] is currently on oper-
UNIFY’s architecture [6] aims at automated and
ators’ road maps for deployment, but at the time of
dynamic service creation and recursive resource orches-
writing mostly in a proof-of-concept stage of adoption.
tration. Its global orchestrator includes optimisation
However, the arrival of software networks, supported by
software-defined networking [4] and NFV technologies, algorithms for placement of service components; service-
is a universally agreed milestone in the evolution of specific actions related to placement and scaling are
telecommunications. Several open-source, standardisation deployed as a service component. T-NOVA is capable of
and commercial solutions are being developed for NFV managing services distributed across several data centres
management and orchestration [5] [‘MANO’, as European but only provides a simple, rule-based system to control
Telecommunications Standards Institute (ETSI) terms it] in the scaling and placement of deployed services. It also pro-
anticipation of its widespread operational use. vides a marketplace in which predefined services and vir-
tual network functions (VNFs) can be traded. OpenMANO
2.1. Software development processes and and OpenStack Tacker aim to be reference implementa-
tools for network function virtualisation tions of the MANO layer defined in the ETSI NFV Industry
Specification Group (ISG) architecture [15], but both are
There is surprisingly little material available of soft- at the beginning of their development. Other orchestration
ware development for network functions or resulting ser- solutions are Cloud4NFV [16] and vConductor [17].
vices, let alone concrete tools to this end. The Unifying All presented orchestration tools, to a great extent,
Cloud and Carrier Networks (UNIFY) project [6] deliv- follow the same principle and try to build a single orches-
ers some first insights on how to apply the DevOps
tration solution for different types of services. This creates
model to NFV. They provide a multicomponent debug-
multiple restrictions for service developers as they cannot
ging tool called Epoxide [7]. Compared with these tools,
SONATA’s approach is a step forward and combines a influence the orchestration process as such. Some of the
powerful software development kit (SDK) with a flex- existing platforms allow expressing a limited and pre-
ible service platform to provide end-to-end support for defined set of preferences regarding monitoring, scaling
service developers. and so on. within function descriptions. However, actively
influencing service-specific decisions, for example,
2.2. Orchestration platforms placement and scaling of services and their components,
is not fully supported by any of them. This is possible
Simple cloud managers like provide the basic functionality with SONATA’s service platform using function and
to deploy and manage single predefined virtual machines service-specific manager programmes defined by the
but cannot handle composed services. Other solutions, service developer.

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

3. SONATA SCOPE AND AN 3.2. 5G multi-service management

OVERALL 5G ARCHITECTURE
SONATA advocates a consistent view of 5G network
3.1. Scope of SONATA functionality and compute functions, encompassing a wide conceptual
range of such functionality. SONATA functionality cov-
SONATA aims at increasing the flexibility and programma- ers the multi-service control layer and partially integrated
bility of 5G networks with a novel Service Development management and operation layer and the application and
Kit and a novel modular Service Platform and Service business services layer. SONATA is also capable of incor-
Orchestrator; it will bridge the gap between telecom busi- porating widely heterogeneous physical resources: various
ness needs and operational management systems. access networks (esp., radio), aggregation and core net-
works, software networks, data centre networks and mobile
The scope of SONATA is depicted in Figure 1 where
edge computing clouds.
the outcome of the project is represented by the Ser-
A multi-service control layer is responsible for the
vice Development Kit, the Management System and
creation, operation and control of multiple dedicated com-
the Service Platform including a customisable Service
munication network services running on top of a common
Orchestrator, a Resource Orchestrator, a Service Infor-
infrastructure. SONATA’s functionality [18] for this layer
mation Base along with various enablers; we use here includes infrastructure abstraction, infrastructure capabil-
the ETSI reference model as a terminological frame- ity discovery, catalogues and repositories, large number
work. In fact, while ETSI’s division into Service and of service and resource orchestration functions as plug-
Resource Orchestrator can be mapped onto SONATA’s ins, information management functionality and enablers
service platform, SONATA is much more flexible in this for automatic reconfiguration of running services, that is,
regard and allows not only replacing these orchestra- part of the integrated management layer.
tion aspects individually, but even to change the division The business function layer maintains 5G application-
of work between these functions if so desired. This is related functions, organised in repositories, and DevOps
achieved by SONATA’s microservices-based architecture tools necessary for the creation and deployment of ser-
(Section 5.1.1); for example, the resource orchestrator cor- vices. SONATA’s functionality for this layer includes
responds by and large to SONATA’s default placement DevOps functionality: catalogues, monitoring data
plug-in. analysis tools, testing tools, packaging tools, editors

Figure 1. SONATA scope.

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

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

and basic functionality for application and service potential for future software networks. SONATA use cases
programmability. [19] encompass a wide range of Information and Com-
Figure 2 depicts the way in which SONATA manages munication Technologies (ICT) domains and their network
various underlying systems. The core idea is to endow services as follows:
SONATA with several infrastructure abstractions, each of
which is custom-tailored to the particular needs of the  Internet of Things: demonstrates SONATA’s ability
underlying infrastructure. This allows both simple and to monitor, classify and optimise Internet of Things
complex of Virtual Infrastructure Managers (VIMs) to be network traffic as an enabler of Smart City ecosystem.
used, as well as entire networks or single, for example,  Virtual Content Delivery Networks (CDN): manifests
OpenStack instances to be integrated. SONATA’s capabilities to enhance a virtual CDN
In summary, SONATA’s main contribution to 5G net- service with elasticity and programmability.
working is efficient integration of service programmability,  Industrial networks: providing guaranteed, resilient
domain orchestration functionality and DevOps function- and secure service delivery in vertical industrial net-
ality. This will maximise the predictability, efficiency, works, such as a wind park.
security and maintainability of development and opera-  Virtual Evolved Packet Core: exhibits and assesses
tional processes around virtualised network functions and the SONATA’s competence to enhance a virtual
chain services. Evolved Packet Core service in an long-term evolu-
tion mobile network.
 Personal security service: targets the system’s poten-
4. USE-CASE-DRIVEN CHALLENGES tial to offer on-demand network security services to
AND REQUIREMENTS multiple tenants/users with differentiated policies and
enable secure network access.
4.1. Use cases and resulting requirements  Separate client and hosting service providers:
demonstrates SONATA’s support for internetwork-
The use cases facilitate the identification of requirements ing between a client service provider and a hosting
of the SONATA framework while highlighting its full service provider to accomplish an end-to-end service.

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

Based on these use cases, we can distil high-level ment is highly service-specific (e.g. mandating a
DevOps requirements for both the overall process of devel- particular order in which virtual machines com-
oping network functions (SDK) as well as the runtime prising a service have to be booted and ini-
platform steering the management and life cycle of such tialised). This is impossible to achieve in a
functions in an actual infrastructure/network—commonly one-size-fits-all fashion.
called the orchestrator.
As a consequence, we need to support both aspects of
(1) Development model requirements a service’s code: the actual data-oriented code as well
For the development model, the following require- as the caretaking code. This materialises as support-
ments are elicited: ing tools for the developer, in specification for what
to ship as a service, and how to be rendered by the
 Support for arbitrary network functions: Sup- orchestration platform, which must be able to exe-
port for all types of network functions must be cute such service-specific code in a proper context
possible, irrespective of the technical domain. and with proper data.
For example, both core networks as well as (2) Orchestration platform requirements
wireless fronthaul networks must be supported. Similarly, for the orchestration platform, we can
To express the different requirements, suit- identify the following core requirements:
able annotation for network function and ser-
vices must exist. Scenarios that pertain to  No one solution fits all: The large variabil-
both network functions in the narrow sense ity of services to be orchestrated, along with
as well as generic (mobile) edge/distributed their own individual caretaking functions, man-
cloud computing are in the purview of the dates that the orchestration platform must be
able to execute service-specific code, but must
SONATA system.
ensure proper information hiding and isola-
 Network functions form data flow graphs: Indi-
tion between these code pieces from different
vidual functions will not suffice to address all
services.
needs; it is needed to group functions into
 Design to support for evolution and maintain-
general graphs of functions which then con-
ability: Assuming that an orchestration plat-
stitute the actual service (i.e network service).
form will ever have a stable, final form seems
This is in-line with current NFV specifications
overly optimistic. Rather, the platform itself
(Internet Engineering Task Force (IETF) service
must be able to be extended by additional func-
chains [20]; ETSI service graphs).
tionality or to replace existing one. This pre-
 Reuse by recursive definitions: Reusing such
cludes a monolithic design of the platform itself.
service graphs mandates a recursive notion— A microservices-based approach, with indi-
a new service can be formed not only by vidual modules executing particular aspects
using primitive network functions but also (together with the individual functions caretak-
by reusing other, simpler services. Hence, a ing code) of an orchestration cycle, seems more
recursive approach has to prevail in the soft- promising for adoption by network operators
ware development concepts and description and their bespoke configuration of the platform.
techniques.  Support real-world’s manifold systems: An
 Reuse by dynamic composition: Recursive defi- orchestration platform should be able to sup-
nitions are the first stepping stone. This concept port a wide range of actual infrastructures on
becomes really powerful if existing network which services will be deployed. This ranges
functions or service can be dynamically reused from bare-metal over simple hypervisors to full-
and combined into new services without requir- fledged OpenStack installations conceived of
ing new deployments (assuming the constituting a single logical node. A particular example
network functions is multi-user-capable). is sliced infrastructures, where the underlying
 Policy-driven support for developer’s service: infrastructure is divided into isolated ‘slices’,
Each service will not only have its own code each of which has its own guaranteed resources
that deals with the actual data flows but also [21]. In the simplest case, SONATA obtains
have additional code that takes care of the new slices from an external slicing system (in
deployment and execution process in a man- the extreme case, one slice per service is con-
ner tailored to the specific requirements of the ceivable). Alternatively, it might be promising
service—we refer to such code here simply as to integrate slicing functionality directly into
‘service-specific code’ and make this notion an orchestrator.
more concrete in later sections. For example,  Division and recursion on platform layer: Akin
scaling or placing a complex service requires to the idea of recursion to describe services,
decision logic that is rather specific to the it is promising to conceive infrastructure and
particular service; similarly, life cycle manage- orchestration platform itself in a recursive

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

way, as well. Sub-orchestrators can then be requests. The service platform receives the service
in charge of different domains or different packages implemented and created with the help
operator networks, working together under the of SONATA’s SDK and is responsible for placing,
auspice of a higher-level orchestrator. The chal- deploying, provisioning, scaling and managing the
lenge is to have the orchestrator itself expose services on existing cloud infrastructures. For this
an infrastructure-like interface. This recursive purpose, it has modules for orchestrating and manag-
approach should also combine nicely with a ing the complete service chain, as well as managing
slicing system. on the VNF level. All artefacts needed to deploy the
service can be fetched from catalogues and reposito-
These high-level requirements and associated chal-
ries. The platform can also provide direct feedback
lenges are addressed by SONATA—the following sections
about the deployed services to the SDK, for example,
show how.
monitoring data about a service or its components.
SONATA’s service platform is designed with full
5. SOFTWARE-NETWORK customisation possibility, providing flexibility and
TECHNOLOGIES control to both operators and developers. The core
mechanism for this is a microservices-based plug-in
SONATA project’s main goal is to increase the flexi- architecture (Figure 3): all functionality that is to be
bility and programmability of 5G networks in order to provided by an orchestrator is assigned to specific
bridge the gap between telecom business needs and oper- plug-ins, all of which are connected to a message
ational management systems. In this chapter, an overview bus that ensures correct delivery semantics of all
of the SONATA architecture is provided, including a short control messages between these plug-ins. Some of
description of the main components. The service program- these plug-ins implement exactly one function per
ming and orchestration framework consist of the SDK, the orchestrator (e.g. the conflict resolver plug-in, which
service platform and different catalogues storing artefacts ensures that any possible resource conflicts between
that can be produced, used and managed by the SONATA services are resolved in a consistent, service-neutral
system. Services developed and deployed by this system fashion).
run on top of the underlying infrastructure accessible to Other plug-ins can be customised by the deployed
the SONATA system via a wide range VIMs; SONATA is service itself with caretaking code: these plug-ins
fairly agnostic to the particular VIMs. then act as an executive (akin to Microsoft Window’s
SONATA’s system design is based on the DevOps work- operating system concept) for this service-specific
flow, which is supported by the integration between the
code.
SDK and the service platform. This workflow implies
The service developer can ship the service package
continuous deployment and continuous integration during
to the service platform together with service-specific
service development. The main entity exchanged between
or function-specific caretaking code, expressing and
the SDK and the service platform is the service package
realising requirements and preferences. Such care-
to be deployed and runtime information like monitoring
taking code is referred to in SONATA as service-
data and performance measurements regarding the service
specific managers and function-specific managers,
package, which is provided to the service developer dur-
respectively. Service-specific managers and function-
ing the development phase, as well as the runtime. This
specific managers can influence the service and VNF
information can be used for optimising, modifying and
life cycle management operations, for example, by
debugging the operation and functionality of services.
specifying desired placement or scaling behaviour.
The main characteristics of the SONATA architecture
This grants the developer increased flexibility, con-
are explained in Section 5.1, followed by covering the four
trol and resilience of their service.
main actor roles in the SONATA platform (Section 5.2).
By virtue of a modular design in the Management
For a full description of the current state of the SONATA
and Orchestration Framework of the service plat-
architecture, please refer to the corresponding deliverable
form, the service platform operator can customise it,
[18] at the time of this writing, to be updated during the
for example, by replacing the conflict resolution or
course of the project.
information management modules. SONATA’s ser-
5.1. Some architectural aspects vice platform is described in more detail in project
deliverable D2.2 [18]. This could be an operator
(1) A microservices-based orchestration platform replacing modules of the configurable service plat-
The high-level service deployment procedure is form with alternatives to fit their software network
illustrated in the service platform. Each VIM/WAN management requirements and preferences.
Infrastructure Manager (WIM) provides the con- (2) Recursive orchestration
trolling service platform a view of the available A recursive structure can be defined as a design,
resources and capabilities of its underlying infras- rule or procedure that is (partially) explained using
tructure/network. A gatekeeper module in the service a simplified version of itself. In a network ser-
platform is responsible for processing the incoming vice context, this recursive structure can either be a

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

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

Figure 4. Service deployment using the SONATA framework.

specific part of a network service or a repeated part existing patterns could reduce complexity and even
of the deployment platform. Although different chal- add more flexible possibilities for extending the
lenges can be thought of, the general idea of reusing service [22]. In Figure 4, recursive orchestration is

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

shown as a SONATA service platform delegating an enterprise, or even a network service provider
(part of) the requested service to another instance of or content provider. In the SONATA ecosystem,
a SONATA platform using a dedicated infrastructure the end user requests the required network services
adaptor. from the network service developer—Figure 6 only
Reclusiveness also leads to an easier management shows the simpler case. That is, the end user and
of scalability. Monolithic software entities are prone the network service developer establish a customer–
to performance limitations from a certain workload provider relationship that is regulated by a service
onwards. Scaling by delegating parts of the service level agreement.
to multiple instances of the same software block is (2) Service developer
a natural way to handle more complex and larger It is the developer of a software artefact, for
workloads or service graphs. If this reclusiveness is example, a VNF or, more specifically, a network ser-
taken into account from the beginning of the devel- vice, which can be composed of one or more VNFs.
opment, the advantages of this approach will come at The SONATA SDK shall enable a DevOps envi-
a minimal cost. ronment for the development of network services.
(3) An software development kit for network function The network service developer can use the editor,
virtualisation debugging and packaging tools in the SONATA SDK
The SDK supports service developers by provid- along with VNF catalogues to compose a network
ing a service programming model and a develop- service that can then be moved to the SONATA ser-
ment tool-chain. Figure 5 shows an overview of the vice platform for deployment and execution. That
foreseen SDK components. SONATA’s SDK design is, the network service developer interacts with the
allows developers to define and test complex services end user for providing the network services and also
consisting of multiple network functions, with tools interacts with the SONATA service platform operator
that facilitate custom implementations of individual for the deployment and operation of those network
network functions. The implemented artefacts are services. However, in the value chain, the developer
stored in the developer’s private catalogues. More- and provider of such a service can of course be
over, service components can easily be obtained from separate entities.
external catalogues using the foreseen interfaces. The (3) Service platform operator
obtained artefacts can be directly used in a service The service platform operator runs the SONATA
or after being modified and tested using the SDK platform that manages the execution of network ser-
development tools. The service components and all vices. The SONATA service platform receives a net-
the information necessary for deployment and execu- work service in form of a package that is validated
tion of a service are bundled together into a package. through a series of quality assurance tests prior to
The service package can be handed over to the ser- their storage in the service platform catalogue. In
vice platform for actual deployment and for testing, addition to validation, the service platform opera-
debugging and profiling purposes. tor also manages the deployment and execution of
network services on virtual resources made avail-
5.2. The main actors in SONATA able by an infrastructure operator. As the SONATA
service platform supports reclusiveness, an opera-
(1) End users tor can manage multiple SONATA service platform
It is the entity that consumes the network ser- instances, as well. Hence, a responsibility of main-
vice. Thus, an end user can be a private person or taining smooth operations for a network service, with
respect to its corresponding service level agreement,
lies on the service platform operator. On one side, the
service platform operator interacts with the SONATA
SDK for network services reception and, on the other
side, interacts with the infrastructure operator for
their deployment and execution.
(4) Infrastructure operator
It is the entity that actually operates the phys-
ical infrastructure, including computational, com-
munication and storage resources. The SONATA
ecosystem does not distinguish between infrastruc-
ture owner and infrastructure operator and treat
them as the same. This is because the main focus
of SONATA is to reduce time-to-market for net-
work services by accelerating and facilitating service
development, management and orchestration with
Figure 5. Main components of SONATAs SDK. DevOps adoption, all while ensuring features such as

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

Figure 6. Main components and roles.

multi-tenancy, reclusiveness and virtual network developer support) is agnostic along multiple axes: it sup-
slices are supported. The infrastructure operator ports multiple VIMs, multiple vendors, deployment at
interacts heavily with the service platform operator multiple sites. It is also agnostic to whether these functions
as the network services are actually executed in the are used in different kind of networks (mobile, optical, etc.)
physical infrastructure. This interaction is enabled by or in the fronthaul or backhaul part. It is agnostic with
the infrastructure abstraction layer in the SONATA respect to whether these services are stateless or stateful.
service platform. It is worth mentioning that in most Efficient network service development and DevOps:
scenarios, the infrastructure operator will be the same SONATA provides service developers with an SDK for
as the service platform operator. However, SONATA efficient creation, deployment and management of network
also supports a use case where the system is engaged services composed of VNFs along with the required chain-
by separate entities for these roles, supporting more ing on the platform. The integration of SDK and service
complex telecom provider business models. platform links an existing gap between service developers
and operators.
6. CONCLUSIONS AND 5G integration: SONATA easily embraces current 5G
FUTURE WORK architecture developments and plays as a good citizen
in the entire ecosystem. For example, slicing is well
The SONATA architecture and resulting system push inno- supported in various fashions, interacting with external
vation in the evolving state of the art of NFV MANO and slicing systems as is bespoke network configuration for
network service development. From the approach outlined industry verticals. Recursion support allows stacked ten-
earlier, we can draw four main conclusions. ant and wholesale deployments in new software networks
Modular and customisable MANO plug-in architec- business models.
ture: the architecture structure provides hitherto unseen DevOps prototype: SONATA is an ongoing research
levels of flexibility. Third-party developers are empowered project with its first code release scheduled early July
with control over specific orchestration and management 2016. The consortium plans to demonstrate a first pro-
functionalities pertaining to their own service without totype showcasing the complete life cycle of a network
being able to influence other services. Similarly, a network service in the NFV environment with continuous monitor-
operator has a wide range of control over how the service ing by end of year 2016 as well as by exercising several
platform should behave. For example, the service platform pilot applications that will be chosen among the use cases
effortlessly encompasses ETSI’s separation into resource described in Section 4. The final prototype with full feature
and service orchestration, but other orchestration models set is scheduled for end of year 2017. Using this proto-
are supported as well. This boils down into a new notion type with its continuously increasing capabilities, we will
of Orchestration-as-a-Service (OaaS): the orchestration elaborate on the reduction of development time. Using the
process itself can be customised on demand by the provider SONATA systems, we expect the time to deploy a new
of a service but stays under the operator’s control. network service to be much faster compare with com-
Interoperable, agnostic framework: the resulting mon approaches today. Moreover, we expect a significant
framework (incorporating both service platform and reduction of code to write in order to operate network

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett
 H. Karl et al.

functions and services compared with existing technolo- 11. Xilouris G, Trouva E, Lobillo F, Soares JM, Carapinha J,
gies. The proposed DevOps approach raises more technical McGrath M, et al. TNOVA: a marketplace for virtualized
challenges, for example, related to the update process of network functions. In European Conference on Networks
running network functions and service. To this end, we and Communications (EuCNC), Bologna, Italy, 2014.
will investigate different approaches—again looking at the 12. OpenMANO, 2015. Available from: https://github.com/
complete life cycle—and evaluate them in terms of perfor-
nfvlabs/openmano [accessed on April 2016].
mance, service continuity, resiliency and fault tolerance.
13. OpenStack tacker, 2015. Available from: https://wiki.
Finally, we will compare the SONATA system with exist-
ing solutions with respect to resource efficiency and overall openstack.org/wiki/Tacker [accessed on April 2016].
service performance. 14. Mamatas L, Clayman S, Galis A. A service-aware virtu-
alized software-defined infrastructure. IEEE Communi-
cations Magazine 2015; 53(4): 166–174.
REFERENCES 15. ETSI NFV ISG. GS NFV-MAN 001 V1.1.1 network
function virtualisation (NFV); management and orches-
1. Chiosi M, Clarke D, Willis P, Reid A, et al. Network tration, Dec. 2014.
functions virtualisation. Technical Report, White paper 16. Soares J, Dias M, Carapinha J, Parreira B, Sargento
at the SDN and OpenFlow World Congress, ETSI, 2012. S. Cloud4NFV: a platform for virtual network func-
2. SONATA project, 2015. Available from: http:// tions. In IEEE 3rd International Conference on Cloud
sonata-nfv.eu/ [accessed on April 2016]. Networking (CloudNet), Luxemburg, 2014.
3. Mijumbi R, Serrat J, Gorricho J, Bouten N, De Turck 17. Shen W, Yoshida M, Minato K, Imajuku W. Conduc-
F, Boutaba R. Network function virtualization: state- tor: an enabler for achieving virtual network integration
of-the-art research challenges. IEEE Communications as a service. Communications Magazine 2015; 53 (2):
Surveys & Tutorials 2016; 18(1): 236–262. 116–124.
4. McKeown N, Anderson T, Balakrishnan H, Parulkar G, 18. Architecture design: deliverable D2.2—SONATA pro-
Peterson L, Rexford J, et al. Openflow: enabling inno- ject. Available from: http://sonata-nfv.eu/sites/default/
vation in campus networks. ACM SIGCOMM Computer files/sonata/public/content-files/pages/SONATAD2.
Communication Review 2008; 38(2): 69–74. 2ArchitectureandDesign.pdf [accessed on April 2016].
5. ETSI. NFV MANO. Available from: http://portal.etsi. 19. Use cases and requirements—deliverable 2.1—SOTATA
org/portal/server.pt/community/NFV/367?tbId$=$79 project. Available from: http://sonata-nfv.eu/use-cases
[accessed on April 2016]. [accessed on April 2016].
6. Unify project, 2015. Available from: https://www. 20. IETF service chaining. Available from: https://
fp7-unify.eu/ [accessed on April 2016]. datatracker.ietf.org/wg/sfc/documents/ [accessed on
7. Lévai T, Pelle I, Németh F, Gulyás A. EPOXIDE: a mod- April 2016].
ular prototype for SDN troubleshooting. In ACM Confer- 21. Argyropoulos C, Mastorakis S, Giotis K, Androulidakis
ence on Special Interest Group on Data Communication, G, Kalogeras D, Maglaris V. Control-plane slicing meth-
London, 2015. ods in multi-tenant software defined networks. In 2015
8. OpenStack heat, 2015. Available from: https://wiki. IFIP/IEEE International Symposium on Integrated Net-
openstack.org/wiki/Heat [accessed on April 2016]. work Management (IM), Ottawa, 2015; 3–4.
9. Terraform, 2015. Available from: https://www.terraform. 22. Szabo R, Kind M, Westphal FJ, Woesner H, Jocha D,
io [accessed on April 2016]. Csaszar A. Elastic network functions: opportunities and
10. Keller M, Peuster M, Robbert C, Karl H. A topology- challenges. IEEE Network 2015; 29(3): 15–21.
aware adaptive deployment framework for elastic appli-
cations. In 17th International Conference on Intelligence
in Next Generation Networks (ICIN), Venice, Italy, 2013.

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.
DOI: 10.1002/ett

View publication stats