Resource Orchestration in Softwarized Networks

(1)

Resource Orchestration

in Softwarized Networks

(2)

D265ModTPhD/EN00 International Ph.D. Program in Emerging Digital Technologies Curriculum: Photonic Technologies

Accademic Year

2017/2018

Resource Orchestration in

Softwarized Networks

Author

Silvia Fichera

Supervisor

Prof. Piero Castoldi

Tutor

(3)

(4)

(5)

List of Figures

2.1 Business view of a 5G network. 7

2.2 Use case families of a 5G network. 9

2.3 The innovation introduced by SDN. 15

2.4 Software Defined Networking Architecture. 17

2.5 Network slicing example. 22

2.6 Vertical Industry Requirements Maslow Model. 24

3.1 ETSI NFV framework architecture. 35

3.2 ETSI MANO reference framework. 37

3.3 Network Service Deployment. 42

3.4 High level workflow. 46

3.5 5GT-SO Building blocks. 47

3.6 ECOC Demo Set-up. 51

3.7 Demo Workflow. 52

3.8 Representation of the network service. 53

3.9 OFC Demo Set-up. 54

4.1 Reference Architecture. 66

4.2 Network Scenario and Deployment Set-up. 67

4.3 No Network Information (NNI) Workflow. 74

4.4 Less Loaded Data Center (LLDC) Workflow. 78

4.5 Minimum Distance (MD) Workflow. 82

4.6 Minimum Latency (ML) Workflow. 83

(10)

viii LIST OF FIGURES

4.7 Percentage of Accepted Requests (%) vs. Traffic Load (Er). 85

4.8 Percentage of induced virtual links vs. Traffic Load (Er). 86

4.9 Accepted requests/virtual links ratio vs. Traffic Load (Er). 87

4.10 Obtained propagation and end-to-end delays vs. Traffic Load (Er). 88

4.11 Main rejection causes. 89

4.12 Bandwidth Blocking Ratio vs. Traffic Load (Er). 90

4.13 Setup Time (s) vs. Traffic Load (Er). 91

4.14 Average SBVT’s subtransponders Usage vs. Traffic Load (Er). 92

4.15 Average CPU Consumption [%] vs. Traffic Load (Er). 94

5.1 5G network and Service Scenario. 99

5.2 5G functioning layer. 100

5.3 Simplified OpenStack Architecture Schema. 107

5.4 ONOS layer architecture. 111

5.5 SDN Orchestartor: software buildign blocks. 113

5.6 Average number of transmitted bytes. 117

5.7 Average redirection time. 118

5.8 Controller overhead. 119

5.9 Experimental Setup building blocks. 120

5.10 ONOS snapshot of the IoT setup. 122

5.11 ONOS snapshot of Cloud and Edge network setup. 122

5.12 Paths created. 125

(11)

List of Tables

5.1 Parameters. 116

(12)

(13)

Chapter 1 Introduction

“I see a sea of networkers all doing and saying the same things. They look alike, act alike and sound alike when speaking to prospects. If you want to rise above the average, mediocre networker... then you have to think differently.”

- Mark Weiser, Xerox PARC

I

N the last ten years we have assisted to a deep evolution of the concept of the

network. This is especially due to the introduction of two new paradigms, Soft-ware Defined Networks (SoftSoft-ware Defined Network (SDN)) and Network Function Virtualization (NFV) that have started the so-called process of IT-zation of the network. SDN principles concern the decoupling of the Control Plane from the Data Plane, and thus the separation of the hardware from the software. NFV con-siders the development of network functions in software and the execution of these functions by a Virtual Machine running in general purpose hardware as virtualized functions that can be instantiated in various location in the network.

SDN and NFV are not the only elements that are impacting on the Telecom-munication network. Cloud Computing architectures, the huge number of devices connected and their future role in this scenario are all active part of the process called Softwarization. That’s why it makes sense talk about Software Defined In-frastructure (SDI). In particular SDI includes smart devices, machine, drones and robots transforming them in terminals of the future [1] and transform the city into a smart city. All those terminals need a network to talk each other through

(14)

2 1. INTRODUCTION

Internet. This is why we also talk about the Internet of Things. Thinking about mobile communication means that we are moving from the concept of every time, everywhere to every time, everywhere, everything .

The future 5G network is not only the evolution of the legacy mobile networks. The 5G network considers the integration between mobile and fixed networks. The goal is to achieve very dense coverage with all possible access technologies for all current and future services in a convergent network. This network needs very high bandwidth, very fast response time, extremely high reliability and flexibility. Those are the prerequisite to allow the communication between end devices and Machine-to-Machine (M2M) applications.

5G has the potential to make cities into smart cities, and it will be the basis to realize the Internet of Things. If we think about a concrete deployment of this infrastructure, SDN, NFV and the Cloud Computing will be the pillars of the 5G and it allows us to associate a SDI to 5G [2].

We can affirm that the slicing is one of the central aspects of a 5G network. A network slice is composed of a set of resources that, appropriately combined to-gether, meet the service requirements of the use case (e.g., mobile broadband [3], automotive [4], haptic internet [5], tele-rehabilitation [6]) that such a slice sup-ports. In a slicing environment, where different players are involved, an orches-tration process is needed to coordinate and manage the resources, manage and deliver services. This process is demanded to an orchestrator. This infrastructure element and its component are well defined by standard organization, e.g. ETSI.

The orchestrator is completely aware of i) the status of the resources in the underlying infrastructure, where the services have to be instantiated, and ii) the services life-cycles, from the deployment to the service termination. The respon-sible for the first part is the so-called resource orchestrator, the second part is supervised by the network service orchestrator.

The main actor in a 5G network is the so-called vertical. A vertical is a service provider (e.g., automotive industry, e-health) that uses the network to deliver the required services. It owns a dedicated portion of the network, the slice, on which the service is deployed by integrating the 5G infrastructure vertically [7]. The par-ticipation of these socio-economic subjects allows new remuneration opportunity for the network provider starting from the introduction of these new economic players to the maximization of the utilization of the infrastructure capacity by admitting network slice requests and exploiting multiplexing gains.

(15)

1. NOVEL CONTRIBUTIONS 3 In this thesis we focused our attention on the overall orchestration aspects with particular interest in the resource orchestration and its application in fully softwarized networks as the 5G network will be.

1.1 Novel contributions

This thesis provides contributions to the state of the art regarding the orches-tration in softwarized networks, from the conceptual and the experimental point of view. Since this work was part of an Industrial Ph.D. Program, funded by TIM, the thesis covers both research and implementation aspects, especially because almost everything was developed in an experimental setup, in order to develop a platform for 5G networks.

The main objective of the thesis is the development of orchestration compo-nents for a softwarized network. In such a network, where services are virtually deployed and stringent requirements have to be ensured, the network and the cloud controller are not enough to pledge them. This is because the need is to have a joined management and control of both domains to ensure the specification demanded. The orchestrator is necessary to complete what both controllers do. The developed orchestration components are fully compliant with the ETSI NFV MANO [8] framework definition and partially used in the EU project 5G-TRANS-FORMER [9].

Following the ETSI NFV MANO framework, several software orchestrators (some of them available as open source) have been designed and developed. Ac-cording to the application requirements, it is possible to add/modify components to the framework to meet the application’s requirements. In agreement with this vision, we have developed and experimentally evaluated some components that can be added to a custom orchestrator.

In particular, in this thesis, two different orchestration components are pre-sented. The first one is an allocation engine that applies placement algorithm to instantiate services in a multi-layer (packet over flexi-grid) infrastructure. The sec-ond component is a network orchestrator designated to maintain the QoS during the network service execution in SDN network infrastructures.

The obtained results show that, with the introduction of a resource orchestra-tor, it is possible to instantiate a larger number of network services and maintain the requested SLA parameter in both optical and SDN networks.

(16)

4 1. INTRODUCTION

To achieve these goals, the starting point has been the investigation of one of the main open source cloud platform, Openstack. It is needed to allocate virtualized network functions (VNFs) that compose a network service. The Cloud platform has been integrated with a network Controllor able to manage the core/transit network and the network related to Openstack. On top of this complex system a network orchestrator has been posed to monitor the traffic across the whole network infrastructure.

The next objective was strictly connected to the 5G-TRANSFORMER project and it is mainly realized thanks to the collaboration with CTTC in Catalunya. A resource orchestrator that interacts with a Transport-SDN Controller has been realized. The orchestrator is aware of the available network resources and able to select the resources that have to be allocated to instantiate a service with bandwidth and latency guaranteed.

Last but not least, this work also pursued a really challenging goal: we were able to demonstrate a 5G network slice deployment in the ARNO test-bed by using the 5G-TRANSFORMER architecture and offer a mobile/edge connectivity service with virtualized functions.

1.2 Structure of the thesis

This Ph.D. thesis focuses on the design, implementation and experimental validation of resource orchestration components.

Chapter 2 gives a broad overview of the subject. In particular it introduces the 5G networks and makes and presents the main technologies involved such as SDN, NFV and the clod computing. In this chapter is also clarified the role of the verticals, the definition of the slicing and a general introduction about the orchestration concept is provided.

Chapter 3 deals with the ETSI MANO framework with particular attention to the NFV orchestrator. In this chapter, it is specified the difference between network service orchestration and resource orchestration. Moreover, part of our contribution to the 5G-TRANSFORMER project is introduced.

Chapter 4 talks about our works conducted in the field of resource orchestra-tion in a multi-layer network. In this chapter is presented the work we made in collaboration with CTTC upon their multi-layer test-bed, ADRENALINE [10]. During this work we have developed several placement algorithm that selects the

(17)

1. STRUCTURE OF THE THESIS 5 resources needed for a network service deployment. In this chapter these algo-rithms are presented and experimentally evaluated.

In chapter 5, a network orchestrator that operates across SDN domains is presented. This orchestrator interacts with an SDN Controller to monitor the network resources. In the chapter we evaluate present and assess the orchestrator in multiple SDN domains.

Finally, chapter 6 closes with a summary discussion, which includes an overview of the achieved results and contributions, as well as the list of scientific production of the Ph.D. period.

(18)

(19)

Chapter 2 5G Softwarized Networks

T

HE 5G is claimed as the next generation of mobile communication that

en-ables higher throughput and lower latency than the actual 4.5G network in which telecommunication and IT will be integrated to build a common infras-tructure that will provide fast connectivity and seamless service delivery in all circumstances and for different kind of businesses. In fact, as shown in fig. 2.1, the 5G network will be the enabler for new applications and services, from the video streaming to the smart agriculture, from the e-health to the smart city.

Figure 2.1. Business view of a 5G network and all the services that it will enable for the evolution of the city in a smart city [11].

(20)

8 2. 5G SOFTWARIZED NETWORKS

This chapter presents an overview on softwarized networks and 5G enlightening the enabling components, actors, state of the art, and challenges.

The rest of the chapter is organized as follows: Section 2.1 introduces the 5G, section 2.2 presents the reason of the need of a softwarized network with the description of the key enabling technologies, section 2.3 talks about the network slicing concept and why it is important in a 5G network. Section 2.4 talks about the verticals’ perspective and section 2.5 introduce the orchestration as the unifying elements and the reason why orchestration is needed. Finally, section 2.6 gives an overview of the state of the art and section 2.7 presents the main challenges and what we propose to address them with this thesis.

2.1 5th Generation Networks

Presentations about the 5G networks are plenty of attractive buzzwords: we usually talk about smart cities and smart devices, big data, hyper-connected world, M2M communication. Additionally to these applications, from a technical point of view, we consider the radio evolution and the vision of a fully softwarized network infrastructure with spread computing capabilities. In this section we are going to explain how all these concepts are linked together to be part of the 5G vision.

To have a complete portrait of the 5G, we think that it is important to em-phasize that in the 5G, the evolution will involve the whole network infrastructure (access and core) and all the possible services offered to the users.

As the past evolution of mobile networks, the 5G network considers a stan-dardized new radio interface (called New Radio - NR), that enhance LTE radio standards (e.g., bandwidth and frequencies). Two early views of 5G are presented by the GSMA intelligence in [12]:

• The hyper-connected vision of 5G in which mobile operators would inte-grate existing wireless technologies covering 2G, 3G, 4G, Wi-fi and others to allow coverage and availability, and higher network density in both terms of cells and devices, with the key differentiation being greater con-nectivity as an enabler for Machine-to-Machine (M2M) services and the Internet of Things (IoT). This vision includes a new radio technology to enable low power, low throughput field devices with long duty cycles of ten years or more.

(21)

2. 5TH GENERATION NETWORKS 9

Figure 2.2. Use case families of a 5G network: enhanced Mobile Broad-band (eMBB), massive Internet of Things (mIoT), and Critical Commu-nication, i.e. Ultra-Low Latency (ULL)/Ultra-High Reliability (UHR).

• The next-generation radio access technology: this does not mean that the 5G is the 4G+1 in defining specific targets for data rates and latency. This in turn makes for a clear demarcation between a technology that meets the criteria for 5G, and another which does not.

The two visions push a different set of requirements associated with specific new services. Typically, these two visions and the requirements for the hyper-connected view and the next-generation radio access technology are grouped together.

The main features of the 5G mobile network [13] (fig. 2.2) are the support of Enhanced Mobile Broadband (eMBB) targeting a consistent user experience along with a secondary target of higher peak bit rates, Massive Machine Type Commu-nication (mMTC) able to support enormous number of low bit rate Internet of Things devices, and the provisioning of Ultra-reliable Low Latency Communica-tion (URLLC) services to provide extremely low delay transmission of specialized services. This can be translated in an higher bit rate (Gbps) from 10 to 1000 times

(22)

the rate of the actual 4G and 4.5G networks for each user, an higher spectrum efficiency, and the support for billion of interconnected devices. Moreover, the 5G network has to be cost efficient, reliable, flexibly deployable, elastic, agile, and above all programmable.

To achieve these challenges, the network has to be supported by advanced tech-nological tools. In fact, a new programmable (softwarized) infrastructure is needed. Cloud computing, Sofware Defined Networking (SDN) and Network Function Vir-tualization (NFV), are the three complementary elements that build a softwarized network. In particular, NFV is enabled by more powerful processors hosted in the DCs and the merging with SDN allows to reduce the cost of specialized hardware in terms of CapEx/OpEx.

The “cloudification” of the network allows to deploy virtual network functions and services in virtual machines. The Cloud paradigm is extended to the edge of the network, getting closer and closer to the final user to run vertical applications, SDN allows to manage network paths to guarantee stringent network requirements, and NFV support the deployment of virtualized network functions.

In the 5G network, the idea of communication and connection is extended to the terminals, identified as smart devices. Indeed, we will not have only mobile phones, laptops and tablets connected to the network and, the network itself, will be composed not only by switches and dedicated network function appliances. Each hardware components will be provided by an intelligence, computing capabilities and smart behaviors. They will be integrated into the network, included sensors, robots, drones, and self driving cars, to build a smart environment. These devices will be able to communicate each other and contribute to the creation of new services and new application scenarios, such as telepresence, networked virtual reality, smart mobility, health care services and so on. These services will trigger the need of ultra-broadband connection, fast processing and devices with advanced performance metrics to serve what is requested.

Every data collected and analyzed in 5G is “sensed” and collected by smart terminals, exchanged between them and elaborated by an intelligence to form the so-called big data. These information are useful to shape a service according to the final user needs and habits and data elaboration can be executed at different point of the network, from the edge to the cloud.

The network and the terminals connected to it will become undistinguish-able. Network services and functionalities will be executed partially in the proper

(23)

2. SOFTWARE-BASED NETWORK ARCHITECTURE 11 network and/or partially in the users’devices or in a premises with computing capabilities very close to the user, placed at the edge of the network. This con-cept extends the cloud computing by bringing its functionalities at the edge of the network and it is identified as Edge computing [14].

In this context reaction time is a key factor, especially in data elaboration. One of the main purposes of the 5G network is to reduce the latency to provide services likewise assisted driving, the remote control of a robot or a drone, etc. These operations are transparent for the end users and let them see the devices as autonomous machines.

From this vision of a flexible network and infrastructure, we can easily figure out that the starting point for the 5G network is a network based on software where the main actors are the new paradigms that, in the last years, have taken advantage from the open source community and the availability of general pur-pose devices. This, in practice, is translated by considering SDN and NFV as enabling technologies that will exploit clouds and micro-clouds in a flexible and programmable infrastructure to deploy network function and offer different services close to the users with demanded QoS.

2.2 Software-based Network Architecture

At the beginning of the information era, data processing and communication were two distinct facets of the whole Information and Communication Technol-ogy (ICT) world, each one evolving on its own, and developing specific and often closed/proprietary technologies. The last two decades have seen huge progresses in computing power at affordable prices and exponential growth of connectivity needs for any kind of users (business/residential, fixed/mobile, etc.). Moreover, the advent of highly-distributed information processing paradigms, such as Cloud Computing and Internet of Things, has urged the ICT industry to break the bound-aries between computing and communication, to the point that vendors that were traditionally active in building network equipment are now offering also advanced computing hardware platforms, and vice-versa.

Therefore, the current industry convergence trends between processing and networking ecosystems clearly show that software will play an unprecedented dom-inant role in future communication environments [15]. Computing, storage, and connectivity services, as well as any other present and future application instances,

(24)

will be deployed in the form of virtualized assets within a software-defined in-frastructures, i.e., softwarized networks, running on top of general-purpose pro-cessing and communication hardware (i.e., standard servers), thus managed and made available under the cloud *aaS paradigm. The so-called “Softwarization” of infrastructures is impacting profoundly the evolution of Telecommunications as demonstrated by the Software Defined Networks (SDN) paradigm [16] and the Network Function Virtualization (NFV) initiative [17]. SDN principles concern decoupling the software-based control plane (e.g., routing decision func-tions) from the hardware-based data plane (i.e., packet forwarding engine) while moving the network intelligence to a centralized software-based controller running on standard servers where network services, such as traffic engineering and path provisioning, are deployed. On the other hand, NFV envisions that network func-tions and capabilities, e.g., firewall, path computation engines, are deployed in software and executed as “virtualized functions” that can be instantiated in, and moved to, various locations in the network as required. SDN and NFV are not dependent on each other, but they are complementary and surely mutually benefi-cial. Indeed, SDN principles should not be seen as just impacting the evolution of L2-L3 “networking”, but also the whole spectrum of L4-L7 functions (i.e., network appliances or middle-boxes) are often considered as target functionalities. Com-plementary, the network function/middle-boxes deployment is not end in itself but strongly benefits of the SDN principles to connect them in the right order. The union of NFV and SDN provides an high level of flexibility and dynamicity in the network.

As result of this “Softwarization” trend, a scenario can be foreseen in the medium-term in which L2 to L7 network functions and services (i.e., from a soft-ware switch/router to a softsoft-ware middle-box) can be provisioned as services run-ning on VMs, i.e., virtual functions, deployed either in the Cloud or in distributed clusters of mini Data Centers (DCs) typically located at the edge of the net-works [18] or even in smart objects equipped with significant computing capa-bilities (e.g., robots). Correspondently, softwarized networks transversally span different domains of resources, from DCs, networks (i.e., edge and core) to termi-nals that are interconnected through different communication technologies (e.g., IP/MPLS, photonic, wireless, legacy networks, SDN) [19]. Definitely, softwarized networks create the conditions for effective and continuous updating and changing

(25)

2. SOFTWARE-BASED NETWORK ARCHITECTURE 13 the networking and computing functions addressing ever-changing user require-ments without redesigning architectural aspects and related components as new features are needed [20].

In this scenario, the availability of network, computing and storage virtualiza-tion techniques is paving the way for the concepvirtualiza-tion of architectural models and techniques for dynamic definition, orchestration and management of network func-tions and their proper chaining for adaptive network service provisioning while ad-dressing ever-changing user requirements. Indeed, virtualization techniques enable the open exposure of the underlying network infrastructure through proper levels of abstraction, thus easing the conception and development of network applica-tions and services, as well as the combined management, control and optimization (i.e., orchestration) of converged networking and computing services on end-to-end basis across heterogeneous resource domains [21, 22].

All these elements are the foundation of the incoming 5G network. The 5G net-work will offer fast speed and more reliability, combining the flexibility and the programmability of the network offered by NFV and SDN.

2.2.1 Software Defined Networking

In the last ten years, Software Defined Networking (SDN) has become the legacy concept when we refer to programmable or softwarized networks. Looking at the evolution of the networking based on the TCP/IP architecture, we can notice that it is a static architecture created for a Client-Server Networking concept and it is unsuitable with the dinamicity requested. A new network architecture was needed because of different drivers [23] including the changing traffic pattern. In fact, in classical client-server applications the bulk of the communication occurs between one client and one server. With todays applications, it is needed to access to different databases and servers, creating a lot of “east-west” machine-to-machine traffic before returning data to the end user device in the classic “north-south” traffic pattern. Moreover, users are changing network traffic patterns as they push for access to corporate content and applications from any type of device, connecting from anywhere, at any time.

Looking at the network evolution, the “problem” of the TCP/IP is that the core of the architecture is simple and well-established and it allowed a huge increase of technologies, protocols and application at the lower and higher levels that rely on them. Typically, a stack architecture, when it evolves, takes the shape of an hourglass [24] and that happened also to the TCP/IP . In fact, the Internet

(26)

architecture lays on three well-defined kernel protocol (IPv4, TCP, and UDP), the innovation on top and bottom them was very easy but the evolution of the core protocols was very hard. The ossification of the network made impossible to change or modify a core protocol, e.g., IPv4, because a new protocol must satisfy all the requirements of the upper and bottom layer protocols and, consequently, the substitution of all the IPv4 routers. This is one of the reason why it was so hard to introduce the IPv6 protocol in the old Internet: a new middle protocol meant to change all the routers in the world [25].

The main cause of this lack of evolution is due to the strong bond of Internet with the hardware. Internet, as we have known it till 10 years ago, was completely hardware dependent. This means that if someone wanted to create and test its own procotol, he can’t do it without build also its own hardware and it causes an evolution lack. All protocols were proprietary and preconfigured, so everything was vendors dependent [26].

One of the objective of a software defined paradigm, and in particular SDN, is to transform Internet from hardware oriented to software oriented. A system based on software is more flexible and adaptable; it can be executed in simple hardware devices and every time a network operator wants to test or change an application, it only has to modify its code. In this way the network becomes programmable and the role assigned to an hardware element depends on the installed software. The idea of a network application vendor/hardware-independent allows the to focus his attention on the functional and application aspects, neglecting the architectural. A new device has to use the API provided to use a specific module.

To do that, the main idea is the decoupling of the control plane from the data plane. In a softwarized network the control plane is represented by a central intelligence, that is mainly called Controller, a Network Operating System (NOS), and the data plane is made of physical level devices, like dummy switches. As represented in fig. 2.3(a), in the old concept of networking, every device is provided of a specialized packet forwarding hardware, an operating system and different features. With SDN, as shown in fig. 2.3(b), the NOS and the features are shared among all the devices. The NOS (or Network Layer) is independent from the architecture and acts as mediator between the features (or application) and the underlying devices. The NOS talks to them using a specif protocol, e.g., OpenFlow, to program the general purpose hardware.

(27)

2. SOFTWARE-BASED NETWORK ARCHITECTURE 15

(a) Traditional Network Paradigm.

(b) SDN Network Paradigm.

(28)

16 2. 5G SOFTWARIZED NETWORKS The SDN approach presents some advantages:

• All the applications that lay on the same Network Layer are portable (hardware independent);

• The interface between the application and the hardware is open, modular and, consequently, evolvable;

• Some hard coded functionalities are moved to an upper layer and the hardware can implements simple forwarding mechanism.

The SDN Architecture, represented in fig.2.4, is composed of three different layers: • the Application layer, is a set of application that communicate to the Controller their network requirements and desired network behavior via NBI. They can also have an abstracted view of the network. Each SDN application is made of an SDN Application Logic and one or more NBI drivers.

• the Control layer, which is the core of the architecture. Here the Con-troller(s) translate the requirements of the SDN Application layer to the Data plane and provide the abstract view to the upper layer (including statistics and events). If more than one Controller is present, they can be federated or hierarchically organized. A Controller is composed by one or more NBI drivers, the SDN Control Logic and a Control-to-Dataplane Interface (CDPI) Driver.

• The Data plane is composed of several Network Elements, that are logi-cal network devices. They are made of one or more SDN Datapaths that include a CDPI agent and a set of Traffic Forwarding Engine/Processing Function. These engines and functions can provide forwarding between the datapath’s external interfaces or internal traffic processing or termi-nation functions [28, 29].

The first protocol used to program the network according to SDN principles was OpenFlow [23]. OpenFlow is a Flow Based protocol: the ingress traffic is differentiated according some fields contained in the Ethernet frame, in the IPv4 packet and in the TCP/UDP segment. The Controller checks these fields to clas-sify the packet and install a rule (forward, drop, encapsulate and forward to the Controller) in the Flow Table (something like a forwarding table) of the OpenFlow switch. When the switch receives a packet, it checks if there is a matching with the installed rules. When the switch receives a new packet, if it is working in reactive mode, it can apply the rule if the packet matches the entry in the flow table or

(29)

2. SOFTWARE-BASED NETWORK ARCHITECTURE 17

Figure 2.4. Overview of Software Defined Networking Architecture [28].

send the header to the Controller who will decide if install one or more actions in the flow table. In proactive mode the Controller pre-populates the flow table in the switches and uses aggregated rules to be known in advance.

The main OpenFlow messages are:

• Hello: exchanged between the switch and the Controller upon connection startup;

• Features: the Controller may request the capabilities of a switch by sending features request. The switch must respond with a features reply that specifies the capabilities of a switch;

• Packet-In: it is an asynchronous message. A Packet-In transfers the control of a packet to the controller;

• Flow-mod:message sent by the Controller to modify a flow table. During the years, a large number of platforms have been developed. The first OpenFlow Controlle was NOX [30], it was written in C++ with some python

(30)

18 2. 5G SOFTWARIZED NETWORKS libraries.

The most recent and well known Controllers are OpenDaylight [31] and ONOS [32].

The Opendaylight (ODL) project is supported by the Linux foundation. The

software is written in java. It is a modular platform. The core of the ODL

platform is the Model-Driven Service Abstraction Layer (SAL). The MD-SAL presents allows the merging of both northbound and southbound APIs and data structures used in various services and components of an SDN Controller. To describe the structure of data provided by the Controller components, a domain-specific language, YANG, is proposed as the modeling language for service and data abstractions. Such a language allows: i ) modeling the structure of XML data and functionality provided by controller components; ii ) defining semantic elements and their relationships; iii ) modeling all the components as a single system.

The XML nature of YANG data model presents an opportunity for self-describing data, which Controller components and applications that use the Controllers north-bound APIs can consume in a raw format, along with the data’s schema. Utilizing a schema language simplifies development of Controller components and appli-cations. A developer of a module that provides some functionality (a service, data, functions/procedure) can define a schema and thus create simpler, statically typed APIs for the provided functionality, and thereby lower the risk of incorrect interpretation of data structures exposed through the SAL. In OpenDaylight, un-derlying network devices and network applications are all represented as objects, or models, whose interactions are processed within the SAL.

ONOS is an On.Lab. project started in 2014. It is a modular and scalable Controller written in java. The application platform relies on Apache Karaf OSGi container. OSGi is a component system for Java that allows modules to be installed and run dynamically in a single JVM. Since ONOS runs in the JVM, it can run on several underlying OS platforms. The system is designed to operate as a cluster of nodes that are identical in terms of their software stack and can withstand failure of individual nodes without causing disruptions in its ability to control the network operation. ONOS is partitioned into i) protocol-aware network-facing modules that interact with the network; ii) protocol-agnostic system core that tracks and serves information about network state; iii) applications that consume and act upon the information provided by the core.

(31)

2. SOFTWARE-BASED NETWORK ARCHITECTURE 19 Each of the above is a tier in a layered architecture, where network-facing modules interact with the core via southbound (provider) API, and the core with the applications via the northbound (consumer) API. The southbound API defines protocol-neutral means to relay network state information to the core, and for the core to interact with the network via the network-facing modules. The northbound API provides applications with abstractions that describe network components and properties, so that they may define their desired actions in terms of policy instead of mechanism.

OpenFlow is not the only protocol available at southbound API that the Con-troller can use to install rules into the devices. Because of the variety of the devices and because of the need of configure and manage them, other protocols have been developed for the south-bound communication. Some of them are an alternative to OpenFlow to configure the device and the forwarding tables, e.g., ForCES [33] and P4 [34]. Others are also designated of the device management, e.g., NETCONF [35], OVSDB [36], BGP [37].

2.2.2 Network Function Virtualization

Typically, a network function is a network node or a physical appliance, e.g., NAT, Firewall, DNS, IDS, strongly coupled to proprietary hardware.

In a softwarized network, a complementary element of SDN is Network Func-tion VirtualizaFunc-tion (NFV) [17]. The use of powerful general purpose hardware, cloud computing and software virtualization techniques, brought to the concept of virtualizing classical network functions. NFV introduces significant novelties regarding the deployement of a network. In fact, it allows [38]:

• Decoupling software from hardware • Flexible network function deployment • Dynamic operation

These Virtualized Network functions (VNFs) run as a software application on virtual machines spawned in cloud servers. With NFV, a network operator can decide when and where to instantiate a specific function in generic hardware by software unbounded from proprietary restriction. Moreover, the operator can scale out the VNFs and deploy many instances in many places. This is a strong advantage for the operator in terms of reduction of CapEx and OpEx, accelera-tion of Time-to-Market, and network flexibility according to the demanded ser-vice [39]. The VNF deployment traversed two phases: during the first one, heavy

(32)

and complex VMs containing more than one network function where deployed to instantiate a network service. In the second one, the service is decomposed in elementary services each one represented by a VNF that are deployed in several cloud infrastructures and chained together to form a Service Function Chain.

The process of selection of VMs, allocation, deployment and connection has to be controlled and managed. To do that the NFV framework has been defined for standarization. This standard framework guarantee that the VNF deployed is not strictly related to specific hardware, it does not need to be tailored for any environment. The framework offers vendors a reference architecture can be follow for consistency and uniformity in the deployment methodologies of any VNF. Moreover, the framework needs to ensure that the management of these VNFs and the hardware they run upon is not vendor dependent. The defined framework must provide the architectural foundations that allow the VNFs, hardware, and the management systems to work seamlessly within the well defined boundaries.

The NFV framework is composed of three main domains [38]

• Virtualized Network Function: software implementation of NF that can be deployed in a NFVI.

• NFV Infrastructure - NFVI: all hardware and networking components on which deploy VNF.

• NFV Management and Orchestration - NFV MANO: it is in charge of the instances’lifecycle (from the deployment to the destruction of an instance).

The NFV framework is responsible for the creation of VNF, the connection and

the interaction between them. Two kind of interaction exists between VNFs:

the VNF-Forwarding Graph (VNF-FG), that is the order in which the VNFs are connected, and the VNF set where the connectivity is not specified.

2.2.3 Role of the Cloud

Cloud computing, aside the networking part, is another fundamental element in 5G networks. Since today, when people think about the Cloud, they mainly think about Dropbox and all the possible remote storage solution that we have. But the Cloud, in future perspective, is much more than storage.

Cloud technologies are based on virtualization paradigms, starting from hard-ware virtualization by mean of an hypervisor to Ethernet switch virtualization to

(33)

2. 5G SLICING 21 connect VMs mutually and to the external network. Cloud infrastructures pro-vides automated mechanism to instantiate VMs, manage resources, migration of VMs, etc. Cloud services are differentiated according to their functionalities. They can be classified in Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS). SaaS is mainly dedicated to the end customers and it contains all the software applications that are not installed in a PC but usable from the Internet (e.g., Google Docs, Office 365); PaaS regards a devel-opment platforms (e.g., Microsoft Azure, Google App Engine) that provides to the developer a powerful hardware platform, scalability, and backups automation. IaaS (e.g., AWS, Rackspace) is strongly related to the computing, storage and network infrastructure. The provider offers the virtualized hardware and a virtual management operating system to the sysadmins.

Accordingly to the 5G architecture, Clouds of different size will be distributed across the whole network to allow the services instantiation. In fact, it is possible to spawn different network functions in different points of the network and inter-connect them to offer a specific service. The Cloud won’t be anymore something far from the final user, but each site that can contain servers is considered as a small Cloud that can execute network functions that need to be closer to the end user for latency reasons.

Connected to the cloud paradigm, the ETSI has introduced the concept of Multi-access Edge Computing (MEC) [40]. Similarly to the cloud, it offers ap-plication developers, content providers cloud-computing capabilities, and an IT service environment at the edge of the network. This environment is character-ized by ultra-low latency and high bandwidth as well as real-time access to radio network information that can be leveraged by applications. It allows software ap-plications to access to local content and real-time information about local-access network conditions. By deploying various services and caching content at the net-work edge, core netnet-works are alleviated of further congestion and can efficiently serve local purposes.

2.3 5G Slicing

The network slicing is a central concept in 5G networks and it is enabled by SDN and NFV. It allows network operators to offer their physical network infrastructure for the deployment of multiple concurrent logical networks (seen

(34)

Figure 2.5. Network slicing example. Each slice is referred to a particular use-case, i.e. Mobile Broadband, Healthcare, and Inter-net of things [43].

as a partition of the network) defined by different requirements and owned by a tenant. A network service is as a set of network functions and resources properly selected and linked each other to build up a complete logical network [41].

A network slice is an independent end-to-end logical network that runs on a shared physical infrastructure, capable of providing a negotiated service quality and interconnecting different network funtions. It can be deployed across multiple operators and spanned across multiple parts of the network (e.g.,access, transport and core network) [42].

Slice types could be defined from a functional or behavioral point of view. Dif-ferent slices are set-up to address difDif-ferent requirements. Mobile network operators could deploy a single network slice type that satisfies the needs of multiple verti-cals, as well as multiple network slices of different types that are combined as a single product targeted towards business customers who have multiple and diverse requirements. For example, a vehicle may need simultaneously a high bandwidth slice for information and multimedia and an ultra reliable slice for telemetry, as-sisted driving. In fig. 2.5 is represented an example of network slicing according three different use-cases: mobile broadband, healthcare and Internet of Things.

A network slice instance is a set of network functions and resources to run these network functions, forming a complete instantiated logical network to meet

(35)

2. 5G SLICING 23 certain network characteristics required by the Service Instance(s). It can be fully or partly, logically and/or physically, isolated from another network slice instance. According to the vision of the next generation mobile network (NGMN), the network slicing involves three different layers [41]: i) service instance layer, ii) net-work slice instance layer, iii) resource layer. The three layers are strongly related each other and they provides mutual support. The service instance layer represents the services that have to be supported. Each service is characterized by a service instance provided by an operator or a third parties provider that are supported by the network slice instance layer. The network slice instance layer is fully supported by the resources layer that offers physical resources (e.g., network, RAM, CPU, storage, etc.).

To create a Network Slice Instance, a network operator uses a Network Slice Blueprint. A Network slice blueprint is a description of the structure, configuration and the workflows that specifies how to instantiate and control the Network Slice Instance during its life cycle and it is referred to logical and physical resources. A Network Slice Instance, defined in a blueprint, provides the network characteristics (e.g., ultra-low-latency, ultra-reliability) which are required by a Service Instance. It is not dedicated to a single service but it can be shared across multiple Service Instances provided by the network operator. With network slicing it is easy to provide different services by different network slice instances.

The 5G network will be multi-tiered and slices have to be deployed and man-aged at each level. This poses anourmous challenges in terms of 5G network sliced infrastructure [44] i) to provide a seamless and flexible management of the re-sources (both physical and virtual); ii) an agile end-to-end service orchestration for the verticals (e.g., manufacturing, healthcare, smart cities, etc.) when they have deployed multiple services; iii) enable connectivity to each service instance. Network programmability and software virtualization are the key technologies to deal with these challenges.

A practical example of the deployment of a network architecture that enables network slicing is the Cloud-Radio Access Network (C-RAN). In the C-RAN dif-ferent sites are connected, using a front-haul network, to difdif-ferent DCs in which base staion processes are running. In a C-RAN the base station functions are rep-resented by the Distribution Unit (DU), located close to the antenna and close to the final user, and the Central Unit (CU) that can be located in a DC to exploit high processing power. Network virtualization of a CU in a DC is used to build

(36)

KƉĞƌĂƚŝŽŶĂů

ZĞƋƵŝƌĞŵĞŶƚƐ

&ƵŶĐƚŝŽŶĂů

ZĞƋƵŝƌĞŵĞŶƚƐ

WĞƌĨŽƌŵĂŶĐĞZĞƋƵŝƌĞŵĞŶƚƐ

Figure 2.6. Vertical Industry Requirements Maslow Model.

several logical network slices on top of one physical network. The logical slices serve different purposes as each of them complies with different network require-ments. Virtualizing C-RAN brings benefits in scalable management of processing resources and enables network programmability [45, 46].

2.4 Users perspective: verticals

As we said, a 5G network will not be only human oriented as the previous gen-eration of mobile communication, but it will serve the digital economy and all the sectors related to that. Through slicing, 5G will create an ecosystem for technical and business innovation involving vertical markets. We can identify as verticals sector: automotive (SDC, Connected cars, car sharing), media and entertainment (the customer can be also the producer of media contents, interactive form of enter-tainment), smart factory (automation and Internet of Things), e-Health (remote surgery, health care monitoring, tele-rehabilitation), smart cities (robot waste col-lector, road safety through drones), etc. Each one of this sector has application that requires high availability, ultra low latency, high bandwidth, and mobility, the key characteristics of 5G networks. So, for each vertical we have to guarantee a certain Service Level Agreement (SLA). Network slicing is one of the key ca-pabilities to ensure SLA in a shared physical infrastructure by creating multiple logical dedicated networks. With network slicing, new services and requests will be quickly addressed, according to the vertical’s requirements [47].

(37)

2. THE UNIFYING ELEMENT: THE ORCHESTRATION 25 Vertical’s requirements, represented in fig.2.6 according to the Maslow model (that underline the hierarchy of needs), can be categorized in:

• Operational Requirements: Self-Management of resources/policies, APIs, Service Assurance for core requirement of verticals business, charging, billing, and global operation;

• Functional Requirements: security and identity management, isolation; • Performance Requirements: latency, throughput, availability, reliability,

and coverage.

2.5 The unifying element: the Orchestration

We did a large list of components and concepts tight to the 5G networks, we said that we want to realize end-to-end connectivity between different domains and we need also flexibility. To realize that, it’s important to have a global overview of the whole infrastructure and to do that we have to put an higher element on top of all the components that manages the verticals’request and the interaction between the elements. What we need is an Orchestrator.

The Orchestration is the ability of manage the network, computing and stor-age, to guarantee flexibility and optimally exploit the resources. The orchestration process is in charge of the fulfilment of application demands (e.g., virtual network infrastructure for content delivery) by coordinately provisioning a composite set of service components (i.e., VFs) across different technological and/or administrative domains and exposing them as a single service instance. On the other hand, the orchestration is expected to guarantee the adequate service performance during the service lifecycle in spite of concurrent resource usage among users or service outages. To this purpose, the orchestration process also relies on monitoring func-tions to measure the status of the underlying (both physical and virtual) resources (e.g., load). Indeed, based on feedback from monitoring tools, the orchestration is expected to handle exceptions or deviations from normal workflows and to adapt provisioned resources to recover from service degradations or outages. Given the heterogeneity of the infrastructure resources (i.e., cloud, network, IoT) possibly deployed in different provider domains and given the different functional areas involved (i.e., application, service and infrastructure), a stacked although interde-pendent set of orchestration layers are foreseen to address context-aware end-to-end

(38)

service provisioning in 5G scenarios. More specifically we can distiguish different orchestration layers [48]:

• Service Orchestration Layer has to adapt a service to the infrastruc-ture. It decomposes the service in task and organizes a service graph,

modify the placement of functions, reroute traffic, etc. At this layer,

the dynamic composition of service components is addressed according to a specified service graph specification, i.e., an ordered list of the re-quired VFs types (e.g., firewall, deep packet inspection, data analytics), stating the invocation flow of service components as well as the Virtual Link requirements connecting VFs (e.g., maximum latency and/or min-imum bandwidth) while not specifying yet the instances that should ac-tually provide those VFs or the network data paths underpinning Virtual Links.This specification basically corresponds to the IETF Service Func-tion Chain [49] and to the ETSI Network Forwarding Path [50] concepts when also application service components are considered and when they dynamically adapt to address verticals’ requirements. This level of or-chestration also deals with the adaptation of the service chaining logic to accommodate changeable user requirements or service contexts (e.g., changes in user location or preferences) or to recover from service degra-dation events (e.g., SLA violations) [51].

• Resource Orchestration Layer manages the resources (i.e., connec-tivity, compute, and storage resources) across multiple network functions

in the same domain or across multiple domains. At this layer, for a

given chaining logic, the dynamic selection is carried out of i) VF in-stances underpinning the required service components (i.e., VMs running specified software modules) and ii) network domains and delivery path end points supporting connectivity between VFs (i.e., Virtual Links end points) to fulfill a specified request. Such (virtual) resources are selected among available candidates and their activation (i.e., service on-boarding) is triggered while leveraging lifecycle management systems or infrastruc-ture orchestrators. Different algorithms can be used to perform selections while optimizing a specified utility function (e.g., minimization of the latency experienced by traffic flows). Such algorithms can consider the available capabilities in the clouds (e.g., processing capabilities at VF in-stances) and/or link capacities in the network domains (e.g., throughput

(39)

2. STATE OF THE ART 27 at the Virtual Links) as well as their current load deduced from real-time monitoring data. Moreover, real-time monitoring data can be also used at runtime to adapt selections in case one or more VF instances are no more available (e.g., due to overload) or data delivery at Virtual Links degrades (e.g., throughput goes below a given threshold due to hotspots in the network domain). If such adaptation events are frequent, it means that the available resources (e.g., VF instances) are under-provisioned and scaling actions need to be carried out [52]. Resource Orchestration lev-ereges on NVF/SDN technologies and the reference fuctional architecture is the MANO - Management and Orchestration [50] framework proposed by ETSI NFV Industry Specification Group (presented in chapter 3). To this list we can also add the

• Infrastructure Orchestration Layer . At this layer the delivery of VF services and Virtual Links is carried out through allocation of VMs into DC servers, service on-boarding into VMs (i.e., configurations and instantiation of VFs for them to promptly serve the end-users) and/or set-up of data delivery paths across a number of switches to connect VF instances. Moreover, the monitoring of VMs, servers and switches is per-formed in a way that if some hotspot occurs, different or augmented set of capabilities are activated (e.g., delivery path redirection throughout a different set of switches, VF scaling out). To this purpose, this layer leverages infrastructure managers related to IoT devices, cloud platforms, and SDN networks.

2.6 State of the Art

The integration of the Internet with software infrastructures and traditional communication technologies has been always a challenge for network and service operators, as far as service deployment and management are concerned [53,54,55, 56]. The main challenge for future networks and services is to move from being merely “Defined by Software” to be “Programmable by Software” to be capable of fully supporting a multitude of providers of services that exploit an environment in which services are dynamically deployed and quickly adapted over heterogeneous resource domains (i.e., physical wired and wireless networks, virtualized cloud

(40)

and smart objects infrastructures), according to varying and sometimes conflicting customer requirements [19].

The progressive “softwarization of the communication infrastructure started around 20 years ago with the first attempts to develop flexible and reconfigurable (i.e., programmable) transmission and networking functions, e.g., Software Defined Radio [57] and Active Networks [58], respectively. However, only recently the software “revolution” of networking has reached significant levels of interest from both academia and industry, owing to the development of key technologies such as Software-Defined Networking (SDN) [16], emerging solutions such as Network Function Virtualization (NFV) [17], and perspective paradigm shifts such as the ones envisioned in 5G scenarios [59].

The usage of orchestration is often discussed in the context of service-oriented architecture, virtualization, service computing, converged (i.e., horizontally-inte-grated) infrastructure and cloud computing topics [60, 61]. In these domains, the orchestration is already operated across different applications and enterprises, i.e., cloud/DC domains. However, in software-defined infrastructures the orchestra-tion is much more challenging because it involves interconnecting services running across heterogeneous systems in geographically distributed DCs and user loca-tions [62]. In this regard, network-awareness capabilities is required to properly address data delivery services between virtualized cloud resources (i.e., virtual machines, virtual disks) [63]. Recently, in the networking domain [64, 65], or-chestration solutions based on bandwidth requirements and resource availability in the network are provided for allocation decisions. However, they ignore both CPU requirements and CPU availability in the clouds/DCs. Instead, a coordi-nated decisions between DC and network is proven to be more effective [66] and architectural guidelines are desirable that address cross-functional orchestration across networks and cloud resources [51], possibly considering optical networking technologies (e.g., flexigrid) between DCs [21, 67].

Regarding the coordination between network and cloud resource provisioning, several projects and research initiatives focused on frameworks to provide a more efficient and reliable approach to share network resources to applications both in the context of Cloud DC and inter-DC environments.

Within Cloud DCs, noteworthy initiatives includes research efforts focused on effective VM deployments across DC servers while addressing bandwidth de-mands [68, 69]. However, the traffic load across links is not considered in making

(41)

2. STATE OF THE ART 29 allocation decisions. In line with guidelines dictated by recent research directions and emerging industry trends for Cloud DC management [70], in OFELIA EU project [71], a horizontally-integrated solution has been designed that integrate control and management functions at both network level (via SDN) and cloud level (via Xen cloud platform). According to defined architectural guidelines, an orchestrator has been also developed that selects proper servers based on periodi-cally collected link load status to preserve adequate network performance despite oversubscription of DC networks [72]. However, more integration of network con-trol functions with the cloud environment should be desirable. In [73, 74] the OpenStack cloud virtualization platform has been enhanced with network-aware capabilities. However, neither a full awareness of the physical network intercon-nection is obtained, nor a comprehensive orchestration functions is provided. In no case, optimizations on end-to-end level, i.e., across DCs, networks and terminals, is demonstrated.

Between DCs, other solutions for joint resource control including both DC and network resources has been devised in [75] considering optical network-integrated computing environment. Specifically, different algorithms are conceived for rout-ing of data packets across the network nodes possibly considerrout-ing also the DC resources status, e.g., enabling the offload of DC resources (e.g., CPU). However, such solution aims at adding cloud resource awareness into the routing of data packets thereby affecting the internal network operation. Instead, the approach of exposing data transfer capabilities as a service would be preferable, according to the NaaS concept [76], in order to effectively synchronize resource provisioning processes and service delivery workflows at both cloud and network level. In order to support the continuous growth of traffic demands, the use of flexible-grid optical networks which support connections on super-channels (i.e. several optical carri-ers combined to create a channel of desired capacity) is being investigated [77]. Such networks tailor the bandwidth capacity and the spectrum occupancy in a fine way guaranteeing an extremely efficient use of network resources [77]. How-ever, the large number of parameters needed to configure connections based on super-channels and the frequent reconfigurations make the distributed Control Planes (CP) (such as GMPLS) not completely adequate for flexi-grid networks in an inter-DC scenario. For these reasons, resource virtualization and, generically, service-oriented capabilities are required at the network control level to enable a

(42)

novel class of interconnection services among DCs triggered by cloud service deliv-ery workflows at different levels of granularity and QoS in a flexible and scalable way [76].

Thanks to inherent network virtualization capabilities given by flow-based ab-straction and to high-programmability of forwarding rules, the SDN approach emerged as promising methodology to support agile traffic steering capabilities and software-centric approaches to QoS-aware virtual network provisioning [78]. For this reason, the centralized SDN control is now being considered also for the dynamic establishment of delivery path across VNF in NFV-capable resource en-vironments. However, a service dimension should be given to SDN Controllers for addressing connectivity service provisioning according to service data deliv-ery requirements and dynamics (e.g., on-demand video services) while performing proper network setting across network nodes and hiding network technology de-tails [76]. This would effectively enable DC interconnections that automatically adapt to VM allocations and movements across DCs. The use of SDN network control in both intra and inter-DC domains calls for a coordination of the relevant SDN controllers, which is currently almost unavailable. A relevant work in this direction is [66] where a cross-functional orchestration platform is presented able to coordinate the provision of cloud-based services with multi-granular data deliv-ery services across flexible optical network. Research efforts addressing the entire resource orchestration also including smart objects and terminals capabilities are currently lacking.

The analysis of the state of the art reveals the need of a coordinated orchestra-tion between the different component of a softwarized network to coordinate the fair usage of IT and network resources.

From this point of view, the telco service providers could benefit from the introduction of software and orchestration in the legacy network because it can cause a significant reduction in terms of CapEx and OpEx. Multiple sites can be used to deploy different function spread across the whole network, that means the possibility to guarantee multiple services in multiple places.

(43)

2. PROBLEM STATEMENT AND CHALLENGES 31

2.7 Problem statement and challenges

In this chapter, we gave a large overview of the future softwarized networks and focus our attention on the specific case of the 5G networks and all the relate key enabling technologies.

We said that the 5G network does not represent a simple advancement for the mobile network, as it was for the previous mobile network generation. The 5G network will make indistinguishable the mobile from the fixed network and it will be pervasively present.

We saw that a 5G networks will leverages three main technologies: SDN, NFV and the Cloud. The merging of these technological trends allow to build a fully softwarized network that will ensure connectivity requirements for each service requested. In particular, all the identified use cases need high data rate and low latency. We also stated that 5G network will be vertical oriented, so network slices will be dedicated to a specific service requested by a specific vertical. That means that the network has to guarantee flexibility and dynamicity. To do that, it is necessary to introduce an element in charge of orchestrate and manage the whole infrastructure: an orchestrator. The orchestrator has to deal with the managing of the resources, the VNFs placement, the online guarantee of the requested SLA, etc.

In this thesis we tackled some of the main challenges raised during the last three years of definition of a 5G network. We have faced the main tasks of a NFV orchestrator when it has to deal with the dynamicity request by the vertical orientation of a 5G network and the resources that it has to take into account to instantiate and keep alive a service. We took on the different requirements needed to orchestrate a service or resources. In fact, orchestrating a service means to decompose the service in elementary tasks and create a graph, design the service as an ordered graph of VNFs that will compose it. To orchestrate the resources means to deal with the two components that compose a 5G network: the network infrastructure and the cloud one. In fact, to allocate a service, it is needed to optimally select where to place the VNFs (in the cloud) by considering the IT resources (CPU, RAM and Storage) and optimally connect them to guarantee network requirements such as minimum bandwidth and maximum latency.

(44)

(45)

Chapter 3 Flexible Network Service

Orchestration for Verticals

I

N traditional network infrastructure, network functions (NFs) are deployed as

physical proprietary devices (software and hardware). In fact, to deploy a NF, a specialized physical appliance was needed with pre-installed closed software. With the evolution of the network, due to the introduction of SDN and the concept of NFV, it is possible to deploy NFs as virtualized elements for a flexible and efficient utilization of the infrastructure. NFV is responsible of the separation of the NFs from the hardware and the deployment of it in general purpose hardware, as detailed in the previous chapter.

This vision has brought ETSI in defining the specification of a framework in support of NFV management and orchestration. The framework objective is to support VFN operation across hypervisors and computing resources, that means the spawning of virtual function in one or more shared DCs. Moreover, it specifies how to orchestrate and manage the life-cycle of physical and virtual resources. According to [38], the framework does not propose any specific implementation and it is described at a functional level. In this chapter we presents the main objectives in 3.1, in section 3.2 we present the ETSI NFV MANO framework and its components, in particular, in section 3.2.2 we talk about the NFV Orchestrator and its structure. In section 3.3 we present part of our contribution in the EU Project H2020 5G-TRANSFROMER, and, in section 3.5 we conclude this chapter.

(46)

34 3. FLEXIBLE NETWORK SERVICE ORCHESTRATION FOR VERTICALS

3.1 Objectives

One of the main challenges in the field of networking is to meet the user re-quirements. With the 5G technology, we consider as users the verticals. A ver-tical is a socio-economic subject that offers services: from the e-health to the e-entertainment, from the automotive to the pure telecommunication. Each ser-vice offered has stringent requirements in term of network reliability, latency and transmission bandwidth. To accommodate such services it is needed to deploy a dedicated portion of network (slice) and instantiate the components of the services in distributed clouds.

This operation are performed by an architectural element that has the role of manage and orchestrate the network services. The reference architecture for this element has been proposed by the ETSI with the MANO framework. The framework can be extended according to specialized functional requirements.

Its main objective is to build up adaptive customized services. In fact, each service responds to specific characteristics and, since the resource utilization (both network and cloud) is variable, it is necessary to constantly adapt them.

3.2 Related Work

The ETSI NFV MANO framework definition started in 2012. The framework as we know it today, represented in fig. 3.1, is structured in three blocks:

• NFV Infrastructure - NFVI: this is composed of all the hardware and software components where the VNFs are deployed. It includes the compute, storage and infrastructure network resources, along with the virtualization layer (i.e. hypervisor) o top of which virtualized resources (i.e. virtual machines) are setup to host VNFs.

• Operation/Business Support System - OSS/BSS, responsible for operation and business application (e.g., monitoring, controlling, billing) managed by the service providers to provision their network services. • NFV Management and Orchestration - NFV-MANO that

per-forms all the tasks related to the virtualization management, coordina-tion and automacoordina-tion in the NFV architecture. It covers the orchestracoordina-tion and the life-cycle management of the resources and VNFs. NFV-MANO

(47)

3. RELATED WORK 35

Figure 3.1. ETSI NFV framework architecture.

focuses on all virtualization-specific management tasks necessary in the NFV framework. We will talk about it in section 3.2.1.

Between the NFVI and the OSS/BSS blocks, there are the Element Manage-ment (EM), responsible for the network manageManage-ment functions, and the VNFs as function blocks that represents the VNF deployed on a server. EMs and VNFs are also connected to the NFV-MANO block.

In this chapter we emphasize the role and the characteristics of the NFV MANO framework.

3.2.1 ETSI NFV MANO

The NFV MANO framework has been defined by the ETSI in [50]. This doc-ument specifies how to provision, manage, and orchestrate VNFs. VNF

manage-ment functions are responsible for the life-cycle1of a VNF, that means: instantiate

1_{The life-cycle is composed of four operation: create, start, stop and delete. Each state of}

Resource Orchestration in Softwarized Networks

Resource Orchestration

in Softwarized Networks

Accademic Year

2017/2018

Resource Orchestration in

Softwarized Networks

Author

Silvia Fichera

Supervisor

Prof. Piero Castoldi

Tutor

Contents

List of Figures

List of Tables

Chapter 1

Introduction

I

1.1

Novel contributions

1.2

Structure of the thesis

Chapter 2

5G Softwarized Networks

T

2.1

5th Generation Networks

2.2

Software-based Network Architecture

2.3

5G Slicing

KƉĞƌĂƚŝŽŶĂů

ZĞƋƵŝƌĞŵĞŶƚƐ

&ƵŶĐƚŝŽŶĂů

ZĞƋƵŝƌĞŵĞŶƚƐ

WĞƌĨŽƌŵĂŶĐĞZĞƋƵŝƌĞŵĞŶƚƐ

2.4

Users perspective: verticals

2.5

The unifying element: the Orchestration

2.6

State of the Art

2.7

Problem statement and challenges

Chapter 3

Flexible Network Service

Orchestration for Verticals

I

3.1

Objectives

3.2

Related Work