BEACON - static1.squarespace.com€¦ · cases that guide the BEACON project, and identifies the main user requirements derived from these use cases. ... 5.2. OpenStack 25 5.3. OVN

Horizon 2020

ICT‐07‐2014 Advanced Cloud Infrastructures and Services

BEACON

D22 BEACON Framework ‐ b

Project Full Title Enabling Federated Cloud Networking

Project Acronym BEACON

Grant Agreement No 644048

Project Type Research and Innovation Action

Nature R (R Report P Prototype O Other) Dissemination Level PU (CO Confidential PU Public) Version 10 Contractual Date of Delivery 31‐01‐2016 Actual Date of Delivery 01‐03‐2016 WP number and Title WP2 Federated Cloud Networking Framework Architecture Deliverable Leader UCM Author(s) Rafael Moreno Rubeacuten S Montero Eduardo Huedo Ignacio

M Llorente (UCM) Stefan Spahr Sandor Koi (LSY) Philippe Massonet (CETIC) Constantino Vaacutezquez Jaime Melis (ONS) Anna Levin (IBM) Massimo Villari Giovanni Merlino Antonio Celesti Giuseppe Tricomi (UME) Darren Whigham Madhuri Ramannavar (FLEX)

Status Submitted

Ref Ares(2016)1054527 - 01032016

ICT‐07‐2014

Document History

Version Issue Date Status 1

Content and changes

01 2‐11‐2015 Draft Based on D21

02 22‐01‐2016 Draft Input and changes for second DD cycle

09 11‐02‐2016 Peer‐Reviewed Input from reviewers

10 29‐02‐2016 Submitted

Peer Review History

Version Peer Review Date Reviewed By

02 4‐02‐2016 UME

02 5‐02‐2016 Philippe Massonet (CETIC)

1 A deliverable can be in one of these stages Draft Peer‐Reviewed Submitted and Approved

BEACON D22 BEACON Framework ‐ b Page 2 of 57

ICT‐07‐2014

Executive Summary

Document D22 is the second deliverable of WP2 which is an update of previous D21 for the second design and development cycle This document describes the use cases that guide the BEACON project and identifies the main user requirements derived from these use cases

The document also describes the main cloud components that will be considered to build the federated cloud network architecture and defines the main architectures for cloud federation and interconnection that will be considered in the BEACON framework to support the different use cases such as peer cloud federation hybrid cloud federation and brokered cloud federation

The document identifies the main software requirements derived from the user requirements and defines the roadmap for the next nine months of the project including the specification of the scenarios to be addressed in this period and the definition of the test suite for the verification of these scenarios

The roadmap defined in this document will be the starting point for the second iteration of WP3 andWP4 that will define in more detail the particular architectures and testing scenarios to be implemented in order to satisfy the list of requirements according to their priorities


ICT‐07‐2014

Table of contents 1 Introduction 10

2 General Description 11

21 Product Perspective 11

22 General Capabilities Functions and Purposes 11

PART I User Requirements Definition 12

3 Use Cases 12

31 Automated High Availability across Datacenters (UC1) 12

311 Use Case Description 12

312 Architectural Description 12

32 Datacenter Location Aware Elasticity (UC2) 13



33 Automated Service Function Chaining across Datacenters (UC3) 14



34 Multi‐cloud Security (UC4) 15



35 Multi‐cloud Deployment of an Airline Scheduling Application (UC5) 16



4 User Requirements 21

PART II Software Requirements Definition 23

5 Description of ComponentsSubsystems 23

51 OpenNebula 23

52 OpenStack 25

53 OVN 28

54 Flexiant Cloud Orchestrator 30

6 Architectures for Cloud Federation and Interconnection 32

61 Peer Cloud Federation and Interconnection 32

62 Hybrid Cloud Federation and Interconnection 33

63 Brokered Cloud Federation and Interconnection 34

64 Multi‐cloud Security 36


ICT‐07‐2014

7 Architecture for Cloud Network Federation 39

8 Architecture Realizations 41

81 OpenNebula‐based Peer Cloud Federation and Interconnection 41

82 OpenNebula‐based Hybrid Cloud Federation and Interconnection 42

83 OpenStack‐based Brokered Cloud Federation and Interconnection 44

84 FCO‐based Multi‐cloud Security 44

841 Vulnerability Scanner 44

842 Chef 46

843 Firewall Templates 47

9 Software Requirements 49

10 Development Roadmap 52

PART III Software Verification and Validation Plan 53

11 Software Verification 53

Conclusions 57


ICT‐07‐2014

List of Figures

Figure 1 Automated HA across datacenters use case 12

Figure 2 Datacenter location‐aware elasticity use case 14

Figure 3 Automated SFC use case 16

Figure 4 Deployment of firewall templates in multi‐cloud security use case 17

Figure 5 Airline scheduling application 19

Figure 6 Architecture of OpenNebula 25

Figure 7 OpenStack overview 26

Figure 8 HOT file in YAML format for the orchestration service in OpenStack 27

Figure 9 OVN architecture 30

Figure 10 FCO overview 30

Figure 11 Architecture for peer cloud federation and interconnection 33

Figure 12 Architecture for hybrid cloud federation and interconnection 34

Figure 13 Architecture for brokered cloud federation and interconnection 35

Figure 14 Architecture for cloud network federation 39

Figure 15 OpenNebula‐based peer cloud federation and interconnection 41

Figure 16 OpenNebula‐based hybrid cloud federation and interconnection 42

Figure 17 OpenStack‐based brokered cloud federation and interconnection 43

Figure 18 Result of elaboration of the manifest done by OSFFM 44

Figure 19 Sequence diagram of vulnerability scanner 45

Figure 20 Chef infrastructure 46

Figure 21 Sequence diagram of Chef infrastructure 47


ICT‐07‐2014

List of Tables

Table 1 ‐ User requirements for UC1 21





Table 6 ‐ Application and infrastructure level security considerations 36

Table 7 ‐ Software requirements for UC1 49





Table 12 ‐ Use cases architectures and realizations of the BEACON project 52

Table 13 ‐ Demo scenarios and verification methods for first cycle software requirements 53

Table 14 ‐ Demo scenarios and verification methods for second cycle software requirements 54


ICT‐07‐2014

Abbreviations and Acronyms

ACL Access Control List

AMQP Advanced Message Queuing Protocol

API Application Programming Interface

AWS Amazon Web Services

CLI Command Line Interface

CM Cloud Manager

CMP Cloud Management Platform

CSP Cloud Service Provider

CQRS Command Query Responsibility Segregation

DB Database

DDD Domain‐Driven Design

DDoS Distributed Denial of Service

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

FCO Flexiant Cloud Orchestrator

FDL Flexiant Development Language

FW Firewall

GUI Graphical User Interface

HA High Availability

HTTP Hypertext Transfer Protocol

HOT Heat Orchestration Template

IaaS Infrastructure as a Service

IP Internet Protocol

JVM Java Virtual Machine

L2 Layer 2

L3 Layer 3

LAN Local Area Network

NFV Network Function Virtualization

NM Network Manager

OCA OpenNebula Cloud API

OCCI Open Cloud Computing Interface


ICT‐07‐2014

OS Operating System

PaaS Platform as a Service

QoS Quality of Service

REST Representational State Transfer

RPC Remote Procedure Call

SaaS Software as a Service

SDN Software Defined Network

SFC Service Function Chain

SLA Service Level Agreement

SOAP Simple Object Access protocol

SQL Structured Query Language

TCP Transmission Control Protocol

UDP User Datagram Protocol

VDC Virtual Data Center

VLAN Virtual Local Area Network

VM Virtual Machine

VNF Virtualized Network Function

VPN Virtual Private Network

VXLAN Virtual Extensible LAN

XML Extensible Markup Language


ICT‐07‐2014

1 Introduction

The purpose of this deliverable is to define the BEACON framework for the second design and development cycle To this end it provides an incremental definition of use cases and requirements (task T21) framework and architecture (T22) and verification suite (T23) In fact this is a living document which is based on D21 and will be delivered again atM21 as D23 As a specification of the BEACON framework this deliverable will drive all the other work packages in each of the design and development cycles

This deliverable is composed of three parts Part I focuses on collecting user requirements from use cases which corresponds to task T21 Contents are organized in sections 3 and 4 Section 3 describes the different use cases of the BEACON project Section 4 identifies and defines the main user requirements for each of the BEACON use cases

Part II focuses on architectural design and software requirements definition which corresponds to task T22 Contents are organized in sections 5‐10 Section 5 describes the components of the BEACON architecture Section 6 describes the common architectures for cloud federation and interconnection Section 7 presents the proposed architecture for cloud network federation Section 8 describes different realizations of cloud federation and interconnection architectures made by integrating the cloud network federation architecture with Cloud Management Platforms (CMP) adopting different cloud federation architectures Section 9 presents the software requirements both functional and nonfunctional derived from user requirements And finally Section 10 defines the development roadmap for the second iteration of development

Part III focuses on the software verification and validation plan which corresponds to task T23 Contents are described in section 11 which defines software verification activities and describes how each requirement will be verified


ICT‐07‐2014

2 General Description

21 Product Perspective

BEACON will develop a cloud network federation framework integrated with OpenNebula and OpenStack technologies for cloud management This will allow cloud providers who use either OpenNebula or OpenStack to form federations and share resources By forming cloud network federations the users of these cloud providers will thus automatically benefit from an increased pool of virtualized resources for their applications

22 General Capabilities Functions and Purposes

The BEACON framework will provide the cloud user with extended service definition capabilities The cloud user will be able to request enhanced deployments that are currently not supported by the OpenNebula service template or OpenStack service manifest

In particular service definition will be extended in order to

Specify required automated high availability across datacenters New expressions will be defined to specify which components need to be replicated or how frequently replication must be done High availability is only possible in a tightly coupled federation and will only be supported between clouds running the same technology for cloud management and managed by the same organization

Specify datacenter location aware elasticity New service definition language expressions will be defined to specify constraints on the geographic location of application deployments These location constraints will be enforced on the initial deployment and the elasticity mechanism Geographic support will be partial and will aim to support the use cases within the project testbed

Specify requirements on network functions for the applicationrsquos virtual network New expressions will be defined to specify which network functions should be applied to the applicationrsquos network traffic and in which order they need to be applied Available network functions will be limited to the ones that are available in the project testbed

Specify firewall template definitions to the cloud middleware and run vulnerability analysis on the Virtual Machines (VMs) of a cloud deployment The service definition language will be extended to refer to firewall templates that need to be applied to an application that is deployed in the cloud federation The use of a firewall template ensures that the firewall configuration data and rules are independent of any specific firewall technology or cloud provider The same firewall template will thus be deployable on either an OpenNebula or OpenStack cloud


ICT‐07‐2014

PART I User Requirements Definition

3 Use Cases

This section describes in detail the use cases introduced in the proposal

31 Automated High Availability across Datacenters (UC1)

311 Use Case Description

High Availability (HA) of a system is achieved by incorporating specific features to reduce service downtime typically failover load balancing and replication These techniques can be easily incorporated into services deployed on multi‐data center clouds To some extent HA features are currently available on public cloud providers but seriously limited by networking constraints

This is a horizontal use case that accommodates any cluster or multi‐tier application For the sake of completeness we will consider a web application that combines all the techniques mentioned before This particular example is considered general enough to cover a wide spectrum of applications each one with its one architectural requirements

312 Architectural Description Figure 1 depicts a common implementation pattern for a web application that incorporates HA features in all tiers Considering the particular application further optimizations can be performed such as adding caching servers or relaxing synchronous cross‐datacenter communications

Figure 1 Automated HA across datacenters use case

Access to the service is performed typically through the Internet by means of a Domain Name System (DNS) via multiple A‐name records for the service to


ICT‐07‐2014

distribute the client calls across load balancers When a load balancer fails web clients will retry using the next address returned by the DNS servers

Load balancers redirect client requests to an application server to provide optimal performance reacting to high load and failure conditions on the application servers It is important to note that load balancers can make use of application servers from any datacenter Finally the application server process the request accessing the information stored in a database The database component is usually deployed in a HA setup implementing a replication mechanism

All the previous components communicate through a private network that traverse all the datacenters used to deploy the application The nature of the traffic is diverse and depends on the techniques and technologies used to implement each functional block For example a master‐slave replication at the database tier may require multicast UDP monitoring traffic to promote a slave in case of master failure while the application servers usually use plain TCP connections to other components Moreover a common scenario is a component acquiring the IP address of failed component

As mentioned before this use case highlights an implementation pattern of a typical clustered service however it is possible to further evolve this use case by adding more functional components like object caching servers (to speed‐up DB access) HTTP caching servers (to speed‐up application server access) or distributed file systems (to increase storage reliability)

Security is not considered in this use case

32 Datacenter Location Aware Elasticity (UC2)


The main characteristics of Cloud Computing are a pay‐as‐you‐go model provision of raw capacity and elasticity However the possibility to allocate resources in multiple clouds opens up avenues to a new type of elasticity based on where the new capacity is allocated that is the location‐aware elasticity

This is a generic use case that represents a class of applications that are able to allocate functional components close to the client requests to improve performance or because of security or jurisdictional constraints In general these components should be able to communicate through public networks and so being able to tolerate long latencies

As a paradigmatic example we will consider a content distribution system able to allocate access servers on specific geographic locations in order to address increasing amount of client requests in that area (eg country specific marketing campaigns or release of new media)

322 Architectural Description

Figure 2 shows a block diagram of the distribution system Initially the system is deployed in a private cloud where the original content is developed and stored At a


ICT‐07‐2014

given time the load of the application is expected to increase in a specific geographical area This process fires the allocation of a new component in a public cloud located closer to the clients so effectively reducing the latency of the application and improving the user experience

Figure 2 Datacenter location‐aware elasticity use case

The contents of the application are basically static and distributed through standard web mechanisms so newweb servers can be allocated in any location provided they have access to the content Typically to improve performance access to the content database a distributed memory object caching system should be considered Note that the redirection to the best server can be implemented through custom DNS A‐name records or with the GeoDNS extension

Web servers DB caches and DB servers need to communicate through a secure virtual LAN This LAN has to dynamically grow to multiple locations and additionally control and monitor traffic for the application components

33 Automated Service Function Chaining across Datacenters (UC3)

331 Use Case Description Federated clouds provide the ability to manage and share resources from multiple clouds and combine them into a common infrastructure A virtual network management system is necessary in the federated cloud environment for setting up a virtual infrastructure where network services can be deployed and managed across different network platforms and architectures

Network service functions such as firewalls load balancers deep packet inspection compression encryption and others are widely deployed in datacenters These functions can be deployed both in physical and virtual forms When deployed in virtual form they are usually addressed as Network Function Virtualization (NFV) Most of the datacenter traffic has to be treated by more than one service function An ordered set of the service functions is referred to as Service Function Chain (SFC) SFC is defined by the datacenter management and deployed in the datacenter infrastructure Then data flows are forwarded through those SFCs according to the network policies


ICT‐07‐2014

The use case of automated network service allows the applications deployed in a federated cloud to consume network services efficiently across datacenters In addition this use case allows the cloud infrastructure providers that own various types of costly service function equipment to consolidate their equipment and reduce costs

In order to enable automated service functions allocation and provisioning in federated cloud environments it is necessary to providemechanisms for sharing the service function information between federated cloud participants The interface between clouds is necessary for efficient service function creation and enforcement with regards to network policies and for forwarding application traffic through appropriate service chain

It is also required in this use case to extend the existing cloud APIs based on open interoperability and portability standards The API extension should support cloud federation enabling the instantiation and provision of Layer 2 (L2) and Layer 3 (L3) federated networks across different clouds The API should support the deployment and interconnection of resources and services across different clouds using federated networks as well as dynamic reconfiguration of these federated networks so they can meet service and user requirements Lastly the extended APIs should allow the migration of resources services and data across clouds


Figure 3 presents the architectural view of the use case There are various network functions deployed in the network From the perspective of the virtual network user there is a service in the virtual network and the user is not aware of the specific instances of the service appliances or Virtualized Network Functions (VNF) deployed in different clouds The user defines which network services should be traversed by its traffic For example in Figure 3 the traffic between DB and application servers should go through firewall (FW) The infrastructure management on its side is aware of the specific network service appliances or VNF instances eg FW1 and FW2 in Cloud 1 (C1) and Cloud 2 (C2) accordingly and automatically configures the physical network to forward the traffic through the corresponding service instances


ICT‐07‐2014

Figure 3 Automated SFC use case

The criteria for selecting appropriate service instances can be the location of the resources eg the traffic between VMs in the same Cloud 1must stay in the Cloud 1 and be serviced by FW1 Other considerations for choosing service instances can be their availability or current load

34 Multi‐cloud Security (UC4)

341 Use Case Description This use case is based on the security aspects of the BEACON environment and will show the current security limitations of application deployments in federated environments Our use case is linked to security challenges detailed under the proposal ambition ‐ security in inter‐site federated environments This use case will tack known issues for infrastructure providers and offers several advantages

We aim to automate security deployment protect VMs during runtime security changes and ensure that common security levels are found within federated environments This will be done using

Firewall templates and an open source vulnerability scanner Chef server

The main advantages around the use case and towards innovation are the following

Automate and configure application level security Automate and configure firewall templates Automated low overhead smart vulnerability scanning Store and utilize historical data externally with vulnerability scanner


ICT‐07‐2014

342 Architectural Description FCO OpenNebula and OpenStack use the same vulnerability scanner to achieve security for their VMs The scanner is called whenever the VMs are created and after the completion of the scan reports are generated These reports are used to create firewall templates for the respective VMs The firewall templates are passed to the respective cloud which apply the new firewall to the VMs The figure below shows the architecture of the use case

Figure 4 Deployment of firewall templates in multi‐cloud security use case

As shown within the figure above this use case will focus on allowing a user to

Install an image from an ecosystem Migrate security constraints between clouds Setup same firewall template at different cloud locations Rescan VMs at different cloud locations

This will be used to provide a more secure method of multi‐cloud usage

35 Multi‐cloud Deployment of an Airline Scheduling Application (UC5)

351 Use Case Description From year to year the airline industry has the challenge of working more and more cost effectively Todays airlines need to permanently revise their schedule plans in


ICT‐07‐2014

response to competitor actions or to follow updated sales and marketing plans while constantly maintaining operational integrity This makes schedule management a very complex process

Strategic alliances of individual airlines (ie former competitors) happen in order to use the synergetic effects and to establish the necessary market power To support such cooperation the airline companies need amongst other things an IT infrastructure application software landscape and system operation with high flexibility and usability The applications must support different kind of collaboration models better than today

Cloud Computing provides such high flexibility by providing elasticity and scalability together with pay‐per‐use cost models The major obstacles which hinder airline companies to deploy and operate industrial applications into public‐ or hybrid‐cloud environments are related to security concerns Security issues must be addressed within the application development process (eg by security specification and SLA definition) as well as during deployment or operation (monitoring security control enforcement and authentication handling)

In the aforementioned scenarios of strategic alliances among former competitors data integrity selective confidentiality and selective data exchange are needed together with a high level of secure communication between different cloud environments (ie multi‐cloud environment) or between an ldquoAlliance Cloudrdquo (a federated cloud environment used by several airline alliancemembers) and different (on premise) application environments

These challenges call for a state‐of‐the‐art scheduling system which optimally supports the development management and implementation of alternative network strategies This use case is related to the commercial aircraft schedule planning software NetLineSched NetLineSched supports all aspects of schedule development and schedule management It offers powerful and easy to use schedule visualization and modification supports alternative network strategies and schedule scenarios and measures the profitability impacts of alternative scheduling scenarios

For the scope of the BEACON project LHS provides a prototype with reduced (business) functionality compared to the existing classic NetLineSched system This is because of several reasons

The NetLineSched software is closed source Current version of NetLineSched is not built as a cloud ready application

which could gain from a cloud ecosystem in the way we want to focus in BEACON

To focus on the usage of the new federated cloud functionality provided by BEACON to fulfill the distributed requirements of the application and not the specific application functionalities

The key aspects of the prototype are

Provide a minimal flight scheduling service only with some basic business functionalities using a simple domain


ICT‐07‐2014

Because of the nature of the business functional requirements the system services are split into write and read intensive modules which can be located in different geographical locations

For modules acting as read‐models the latency is critical so these are set to the closest datacenter to minimize the network latency

Write models require extremely high availability to ensure data integrity This can be achieved by using multiple datacenters in parallel to keep the factor of data loss in case of one datacenter outage as minimal as possible

Another possible scenario for such a distributed deployment can be the implementation of the aforementioned Alliance cloud

352 Architectural Description The NetlineSched airline flight scheduling application moves beyond standalone software functionality and is designed to support SaaS operations in cloud environments SaaS is provided by means of a delivery model where application services are cloud‐hosted and offered to customers on demand over the internet with specific pricing and licensing options

Figure 5 Airline scheduling application

Server‐side performance high availability and scalability are key nonfunctional requirements in architecting the NetlineSched software In a multi‐tenant environment users share the same code base and services are required to adequately react to high traffic loads Virtualized cloud environments are offering a scale on demand infrastructure Virtual nodes can incrementally be added to or removed from the cluster Elastic scalability is well suited to achieve high performance in scenarios when workload increases or to free up resources when demand decreases As a SaaS‐Architecture NetlineSched application provides central flight‐planning services Common infrastructure‐services like user‐ and


ICT‐07‐2014

configuration‐management security and an integration‐bus are centrally developed and provided in a PaaS‐Environment

In contrast to Cloud‐Operations customer Airlines may also choose to run NetlineSched as a traditional self‐contained application in an on‐premise infrastructure environment Cloud‐Operations as well as an application‐centric on‐premise runtime environment must be supported

The NetlineSched scheduling application is a multilayered distributed web‐application and provides a scalable platform of loosely coupled component oriented building blocks In contrast to a monolithic approach server‐side‐applications are decomposed in self‐contained collaborating and independently scalable business‐components each capable of running in its own process and interacting by use of lightweight REST‐style communication protocols

The overall Architecture of NetlineSched encompasses major styles of REST‐Architectures Domain‐Driven‐Design (DDD) with hexagonal layering design Command‐Query‐Segregation (CQRS) and Event‐Sourcing (ES) In combination these styles are complementary and covering non‐functional criteria on different architectural levels In turn a layered architecture enables to address various non‐functional and conceptual requirements with explicit design decisions on each level


ICT‐07‐2014

4 User Requirements

The following tables show the user requirements derived from the uses cases described in Section 3 The user requirements coming from use case UCx are identified with the code URxy In addition for each requirement a priority is assigned so that the high priority requirements will be addressed first

Table 1 ‐ User requirements for UC1

Id Description Priority Source Status

UR11 Service deployment across datacenters Medium UC1

UR12 Transparent connection across datacenters Medium UC1

UR13 Server failover across datacenters Medium UC1

UR14 DB replication across datacenters Low UC1

UR15 Load balancing across datacenters Low UC1



UR21 Service deployment across clouds High UC2 Done (SR21)

UR22 Transparent secure connection across clouds

High UC2 Partially done (SR22)

UR23 Automated geographic elasticity Medium UC2


Id Description Priority Source

Status

UR31 Overlay based VM connectivity across clouds High UC3 Done (SR31)

UR32 Automated service chaining support in a single cloud

Medium UC3

UR33 Automated service chaining support across clouds

Low UC3


ICT‐07‐2014



UR41 Automatic firewall creation Medium UC4

UR42 Automatic VM vulnerability scanning at creation


UR43 Automatic VM vulnerability monitoring during operation

Medium UC4

UR44 Provide vulnerability analysis as a VNF High UC4 Partially done

UR45 Firewall template creation based from vulnerability scanner

Medium UC4



UR51 Specify geographic constraints for the deployment of VMs


UR52 Specify geographic constraints in elasticity rules

Medium UC5

UR53 Create a hybrid cloud that support federated networking

Medium UC5

UR54 Deploy NoSQL databases in the federation and use HA (replication) techniques without performance degradation

Medium UC5

UR55 The service must be secured at all times Low UC5


ICT‐07‐2014

PART II Software Requirements Definition

5 Description of ComponentsSubsystems

This section provides a brief description of components or subsystems used in the BEACON solution

51 OpenNebula

OpenNebula is composed of the following subsystems 2

Users and Groups OpenNebula features advanced multi‐tenancy with powerful users and groups management fine‐grained Access Control Lists (ACLs) for resource allocation and resource quota management to track and limit computing storage and networking utilization

Virtualization Various hypervisors are supported in the virtualization manager with the ability to control the complete lifecycle of VMs and multiple hypervisors in the same cloud infrastructure

Hosts The host manager provides complete functionality for the management of the physical hosts in the cloud

Scheduling The scheduler is in charge of the assignment between pending VMs and known Hosts The OpenNebula scheduling framework is designed in a generic way and it is highly modifiable and can be easily replaced by third‐party developments OpenNebula comes with amatchmaking scheduler that selects and prioritizes those resources more suitable for the VM

Monitoring Virtual resources as well as hosts are periodically monitored for key performance indicators The information can then be used by a powerful and flexible scheduler for the definition of workload and resource‐aware allocation policies

Accounting A Configurable accounting system to visualize and report resource usage data to allow their integration with chargeback and billing platforms or to guarantee fair share of resources among users

Networking An easily adaptable and customizable network subsystem is present in OpenNebula in order to better integrate with the specific network requirements of existing data centers and to allow full isolation between VMs that composes a virtualized service

Storage The support for multiple datastores in the storage subsystem provides extreme flexibility in planning the storage backend and important performance benefits

2 httpopennebulaorg


ICT‐07‐2014

Security This feature is spread across several subsystems authentication and authorization mechanisms allowing for various possible mechanisms to identify and authorize users a powerful ACL mechanism allowing different role management with fine grain permission granting over any resource managed by OpenNebula support for isolation at different levels

High Availability Support for HA architectures and configurable behavior in the event of host or VM failure to provide easy to use and cost‐effective failover solutions

Clusters Clusters are pools of hosts that share datastores and virtual networks Clusters are used for load balancing high availability and high performance computing

Multiple Zones The Data Center Federation functionality allows for the centralized management of multiple instances of OpenNebula (or zones) for scalability isolation and multiple‐site support

Virtual Data Centers (VDC) An OpenNebula instance can be further compartmentalized in VDCs which offer a fully‐isolated virtual infrastructure environment where a group of users under the control of the group administrator can create and manage compute storage and networking capacity

Cloud Bursting OpenNebula gives support to build a hybrid cloud an extension of a private cloud to combine local resources with resources from remote cloud providers A whole public cloud provider can be encapsulated as a local resource to be able to use extra computational capacity to satisfy peak demands

App Market OpenNebula allows the deployment of a private centralized catalog of cloud applications to share and distribute virtual appliances across OpenNebula instances

Graphical User Interface (Sunstone) OpenNebula Sunstone is the OpenNebula Cloud Operations Center a GUI intended for regular users and administrators that simplifies the typical management operations in private and hybrid cloud infrastructures It can be adapted to different user roles and its behaviour can be customized and extended via views

Service Manager (OneFlow) OneFlow allows users and administrators to define execute and manage multi‐tiered applications or services composed of interconnected VMs with deployment dependencies between them

Self‐awareness and Self‐configuration (OneGate) OneGate allows VM guests to pull and push VM or Service information from and to OpenNebula and trigger actions to reconfigure a VM or Service

OpenNebula shows a modular and extensible architecture (see Figure 6) The OpenNebula core attends the requests and manages the resource pools and all the components Customizable plugins for monitoring storage network virtualization authorization and image management allow the integration with any third‐party


ICT‐07‐2014

data center service An API for integration with higher level tools offers all the rich functionality of the OpenNebula core with bindings for ruby and java

OpenNebula implements two federation models zones and cloud bursting OpenNebula zones consists of multiple OpenNebula instances (peer clouds) each one deployed in a set of autonomous resources Each zone shares with the others the user and provisioning maps following a master‐slave communication pattern In a cloud bursting mode OpenNebula is able to offload some VM requests to other public clouds no information is shared across clouds and the model follows the client‐server paradigm

OpenNebula also implements clusters that together with the previous federation setups allows a great flexibility to deploy multi‐VM application onmultiple locations across clusters within the datacenter across zones within a peer federation or across providers within the global cloud market offering

OpenNebula also provides a limited support for the interconnection of related VMs when they are deployed in multiple locations For VMs in different clusters within the same datacenter OpenNebula leverages the VXLAN protocol or 8021Q for simpler network topologies When the VMs are allocated in different clouds (peers or bursting) OpenNebula relies on NFV to setup the interconnecting network However currently it does not implement any support to automate this process

Figure 6 Architecture of OpenNebula

52 OpenStack

OpenStack provides a Cloud IaaS using the cooperation of several services each one 3

dedicated to the provisioning of a specific service as shown in Figure 7 Most of the services are composed by agents who use different plugins to add new features or to

3 httpswwwopenstackorg


ICT‐07‐2014

be compliant with a specific technology Moreover every service has its own API to expose its functions

Figure 7 OpenStack overview

Basically the infrastructure provides three kind of resource compute network and storage and this goal is accomplished with these projectsservices (see Figure 7)

Nova (compute service) manages the VMs controlling and supervising the hypervisors distributed in dedicated computed node which gave the hardware computational resource

Neutron (networking service) provides an API for users to define networks and the attachments into them The agents provides also typical network service such as routing (between VMs and between VM and external network) DHCP firewall load‐balancing

Keystone (identity service) provides authentication and authorization service for the other OpenStack service Every external requests (the REST ones) must be validated using a token generated by Keystone in according to the


ICT‐07‐2014

role of the one (service or human) who is trying to communicate with the infrastructure

Glance (image service) stores and provides the images used as base for the VMs that are managed by Nova

Those four services represent the main core of OpenStack It means that a minimal OpenStack scenario can be risen up with just only Nova Neutron Keystone and Glance

A more complete and powerful infrastructure can be set up using these other services

Horizon (dashboard service) provides a web‐based GUI for the administration of tenants and users It use the REST API of each service as via for sending commands to them in more friendly way

Cinder (block storage service) provides and manages the persistent storage for the VMs using volumes that can be attached directly on the running VMs

Swift (object storage service) it is a pure storage of object that can be exported using REST API It provides mechanisms of redundancy on a scalable architecture

Ceilometer (telemetry service) provides the monitoring of the OpenStack resources of every services for billing scalability and statistical purpose

Heat (orchestration service) provides the orchestration of the resource using a Heat Orchestration Template (HOT) file as shown in Figure 8 With this service different virtual scenario and applications can be risen up configured and monitored automatically just writing down the file which describes the resources and their interaction

Trove (database service) provides a Database as a service using both relational and non‐relational database engines It is the newest service inserted into the last OpenStack releases

Figure 8 HOT file in YAML format for the orchestration service in OpenStack

The architecture is very flexible and all the services can be spread in different machines Basically this architecture has a dedicated controller node in which there are all the centralized component of the services several compute nodes that can manage the visualization a dedicated network node which provides to the VMs the


ICT‐07‐2014

routing for the external net and server storage node servers for storing images and volumes guaranteeing the redundancy

The controller node is the one in which resides also the SQL database for each service and the Message Broker (generally using AMQP) that manages all the messages the services exchange to communicate with each other

In relation to cloud federation OpenStack only supports identity federation whereas it supports several mechanisms for segregating cloud resources such as cells regions availability zones or host aggregates as well as cloud bursting through either vendor‐specific offerings or DIY approaches that can build on community resources such as Chef cookbooks and Puppet configurations Commercial vendor‐agnostic multi‐cloud management platforms are also available

With regards to the OpenStack networking subsystem (Neutron) it does not provide support for Cloud and Datacenter interconnection and more in general the current mechanism to federate multiple OpenStack sites is through a cascading multi‐site architecture yet limited to imposing a two‐level hierarchy on the federation where a parent site just exposes APIs and orchestration mechanisms and any child site provisions instances and networks

53 OVN

Open Virtual Network (OVN) is an SDN controller built natively to control Open Virtual Switch (OVS) instances to interconnect virtualized guests with (Geneve) 4

overlay tunnels OVN natively complements the existing capabilities of OVS to add native support for virtual network abstractions such as virtual L2 and L3 overlays and security groups Services such as DHCP are also included OVNrsquos design goals include production‐quality implementation that can operate at significant scale CMP integration exemplified by OpenStack and easy inclusion of advanced network services

An OVN deployment consists of several components

A CMP which is OVNrsquos ultimate client (via its users and administrators) OVN integration requires installing a CMP ‐ specific plugin and related software OVN initially targets OpenStack as CMP

An OVN Database physical or virtual node (or eventually cluster) installed in a central location

One or more (usually many) hypervisors Hypervisors must run Open vSwitch Any hypervisor platform supported by Open vSwitch is acceptable

Zero or more gateways A gateway extends a tunnel‐based logical network into a physical network by bi directionally forwarding packets between tunnels and a physical Ethernet port This allows non‐virtualizedmachines to participate in logical networks A gatewaymay be a physical host a VM or an ASIC‐based hardware switch that supports the vtep schema

4 httpopenvswitchorgsupportslidesOVN‐Vancouverpdf


ICT‐07‐2014

Figure 9 shows how the major components of OVN and related software interact Starting from the top it can be identified

The Cloud Management System as defined above The OVNCMP Plug‐in is the component of the CMP that interfaces to OVN

In OS this is a Neutron plugin The pluginrsquos main purpose is to translate the CMPrsquos notion of logical network configuration stored in the CMPrsquos configuration database in a CMP‐specific format into an intermediate representation understood by OVN This component is necessarily CMP‐specific so a new plug‐in needs to be developed for each CMP that is integrated with OVN All of the components in Figure 9 are CMP‐independent

The OVN Northbound Database receives the intermediate representation of logical network configuration passed down by the OVNCMP Plugin The database schema is meant to be impedance matched with the concepts used in a CMP so that it directly supports notions of logical switches routers ACLs and so on The OVN Northbound Database has only two clients the OVNCMP Plugin above it and ovn‐northd below it

ovn‐northd connects to the OVNNorthbound Database above it and the OVN Southbound Database below it It translates the logical network configuration in terms of conventional network concepts taken from the OVN North‐bound Database into logical data‐path flows in the OVN Southbound Database below it

The OVN Southbound Database is the centre of the system Its clients are ovn‐northd above it and ovn‐controller on every transport node below it The OVN Southbound Database contains three kinds of data Physical Network (PN) tables that specify how to reach hypervisor and other nodes Logical Network (LN) tables that describe the logical network in terms of logical data path flows and Binding tables that link logical network componentsrsquo locations to the physical network The hypervisors populate the PN and Port_Binding tables whereas ovn‐northd populates the LN tables OVN Southbound Database performance must scale with the number of transport nodes

The remaining components are replicated onto each hypervisor

ovn‐controller is the OVNrsquos agent on each hypervisor and software gateway Northbound it connects to the OVN Southbound Database to learn about OVN configuration and status and to populate the PN table and the Chassis column in Binding table with the hypervisorrsquos status Southbound it connects to ovs‐vswitchd as an OpenFlow controller for control over network traffic and to the local ovsdb‐server to allow it to monitor and control Open vSwitch configuration

ovs‐vswitchd and ovsdb‐server are conventional components of Open vSwitch


ICT‐07‐2014

Figure 9 OVN architecture

54 Flexiant Cloud Orchestrator

Flexiant Cloud Orchestrator (FCO) is a cloud orchestration software that allows 5

service providers the ability to launch highly differentiated public IaaS cloud services FCO provides compute network and storage orchestration which aremade directly available to end users via self‐service control panel and API A full breakdown of FCO is shown in Figure 10

Figure 10 FCO overview

5 httpwwwflexiantcomflexiant‐cloud‐orchestrator


ICT‐07‐2014

FCO offers access to multiple APIrsquos These APIs do as much of the business logic and functionality as possible and all other services communicate via the APIs not via database calls

FCO has three APIs which are available in both REST and SOAP

The User API for end users

The Admin API for administrative functions for Billing Entities or Licensees of the platform

The System API for licensees of the platform to manipulate use of physical resources

A unique offering of FCO is the Flexiant Development Language (FDL) which allows the ability to extend FCO by writing plug‐ins FDL provides access to a complete programmable suite of functions including access to FCO internal business logic as well as the ability to integrate with external applications These extensions are written as Triggers which are functions that allow an action in FCO to initiate a second action which can be external to FCO A trigger is written as a block of FDL code that run either before an event occurs (a pre trigger) or after an event occurs (a post trigger)


ICT‐07‐2014

6 Architectures for Cloud Federation and Interconnection

The different use cases described in Section 3 can bemapped to different federation architectures such as peer cloud federation hybrid cloud federation and 6 7

brokered cloud federation In this section we describe these three main federation architectures and introduce some security considerations both at application level and architecture level

61 Peer Cloud Federation and Interconnection

Peer cloud federation architecture (see Figure 11) corresponds to a tightly coupled federated cloud scenario consisting of several private cloud premises (or 8

datacenters) usually belonging to the same organization (or closely coordinated) and normally governed by the same technology for cloud (actually datacenter) management such as OpenNebula or OpenStack In this scenario each Cloud Manager (CM) instance can have full control over remote resources (eg placement control full monitoring or VM lifecycle management and migration control) In addition other advanced features can be allowed including the creation of cross‐site networks the support for cross‐site migration of VMs the implementation of high‐availability techniques among remote cloud instances the creation of virtual storage systems across site boundaries etc The interaction between CMs is usually implemented using private cloud interfaces (administration level APIrsquos) and data models (eg OpenNebula XML‐RPC or OpenStack component APIrsquos ) On top of the 9 10

CM there could be a SM to simplify service definition deployment and management

Within this architecture the Network Manager (NM) is responsible for managing virtual networks both inside and among datacenters The NM can be integrated with the CM (eg in OpenNebula) or can be a separated component (eg OpenStack Neutron) NMs in different datacenters interact and cooperate using (possibly private) inter‐cloud northbound APIs and protocols (eg the OpenNebula VirtualNetwork XML‐RPC API ) that enable the instantiation and management of 11

cross‐datacenter networks mainly based on SDN and NFV technologies

6 R Moreno‐Vozmediano RS Montero IM Llorente IaaS Cloud Architecture From Virtualized Data Centers to Federated Cloud Infrastructures Computer 45(12) 65‐72 December 2012 7 A Celesti F Tusa M Villari and A Puliafito How to Enhance Cloud Architectures to Enable Cross Federation IEEE 3rd International Conference on Cloud Computing (CLOUD) 337‐345 2010 8 B Rochwerger J Caceres RS Montero D Breitgand E Elmroth A Galis E Levy IM Llorente K Nagin Y Wolfsthal The RESERVOIR Model and Architecture forOpen Federated CloudComputing IBM Journal of Research and Development 53(4) 4‐11 July 2009 9 httpdocsopennebulaorg44integrationsystem_interfacesapihtml 10 httpdeveloperopenstackorgapi‐refhtml 11 httpdocsopennebulaorg414integrationsystem_interfacesapihtmlactions‐for‐virtual‐network ‐management


ICT‐07‐2014

Figure 11 Architecture for peer cloud federation and interconnection

These cross‐site networks are commonly implemented as L2 or L3 overlay virtual networks on top of the physical interconnection network which can be a public network (ie a L3 insecure network such as Internet) or a dedicated high‐performance link (usually a private L2 or L3 network) In this context themost challenging situation is deploying a cross‐site secure L2 virtual network over an insecure L3 public connection

This architecture enables the deployment of complex inter‐datacenter infrastructures to support advanced configurations such as HA between datacenters (as described in use case 1)

62 Hybrid Cloud Federation and Interconnection

The hybrid cloud federation architecture (see Figure 12) corresponds to a loosely coupled federated cloud scenario that combines multiple independent cloud (both public and private clouds) Also called cloud bursting model it combines the 12 13 14

existing local cloud infrastructure (eg a private cloud managed by a CM such as OpenNebula or OpenStack) with external resources from one or more remote clouds which can be either public clouds (eg Amazon EC2 FlexiScale Digital Ocean etc) or partner clouds (managed by the same or a different CM)

The main goal of this hybrid model is to provide extra capacity to the local cloud to satisfy peak demand periods and transforming the local data center in a highly

12 B Sotomayor RS Montero IM Llorente I Foster Virtual InfrastructureManagement in Private and Hybrid Clouds Internet Computing 13(5)14‐22 September 2010 13 RS Montero R Moreno‐Vozmediano IM Llorente An Elasticity Model for High Throughput Computing Clusters Journal of Parallel and Distributed Computing 71(6)750‐757 June 2011 14 A Celesti F Tusa M Villari and A Puliafito Integration of CLEVER clouds with third party software systems through a REST web service interface IEEE Symposium on Computers and Communications (ISCC rsquo12) 827‐832 2012


ICT‐07‐2014

scalable application hosting environment This architecture is loosely coupled since the local cloud has no advanced control over the virtual resources deployed in external clouds beyond the basic operations allowed by these providers The interaction between the local CM and the various remote clouds is usually implemented using public cloud interfaces (user level APIrsquos) and data models (eg Amazon AWS EC2 API or OCCI) As in the previous architecture on top of the CM there could be a SM

Figure 12 Architecture for hybrid cloud federation and interconnection

Due to the heterogeneity of NMs in different clouds each cloud can provide different capabilities to interconnect with external resources regarding the possibility of creating L2 or L3 overlay networks VPNs secure channels or even high level network functions like balancers In some clouds VMs are seen as independent resources (eg Amazon EC2‐Classic platform) that can be accessed using a public IP so the final user is responsible for configuring the appropriate communication channels (eg overlay tunnels or VPNs) Other clouds provide private networking to interconnect VMs inside the cloud (eg Amazon EC2‐VPC platform) and also some kind of VPN capabilities to implement a L3 overlay between local network and remote resources However methods to instantiate and configure these VPNs differ from one provider to another Regarding the creation of L2 overlay networks between independent clouds currently there are not any cloud technology offering this kind of capabilities so this is one of the most important challenges in cloud federation and interconnection

This architecture is the most appropriate to deploy hybrid solutions that support location aware elasticity (as described in use case 2)

63 Brokered Cloud Federation and Interconnection

The brokered cloud federation architecture (see Figure 13) usually consists of a central broker or orchestrator which has access to several public independent


ICT‐07‐2014

clouds This orchestrator can deploy virtual resources in the different clouds 15 16

according to criteria specified by the user such as location restrictions cost restrictions etc and should also provide networking capabilities to enable the interconnection of different resources deployed in geographically dispersed clouds There could be also decentralized brokering schemes with several brokers interacting to each other

We assume that as in the previous architectures the cloud broker or orchestrator is basically a multi‐cloud SM which is responsible for managing application and network services across clouds

Figure 13 Architecture for brokered cloud federation and interconnection

Similar to the hybrid cloud federation architecture this architecture is also loosely coupled since the orchestrator interacts with the different clouds using public cloud interfaces (user level APIrsquos such as Amazon AWS EC2 API or OCCI ) which usually 17 18

do not allow advanced control over the virtual resources deployed

Regarding networking issues the orchestrator must be able to deal with different NMs with different network capabilities hence it is responsible for creating the

15 J Tordsson RS Montero R Moreno‐Vozmediano IM Llorente Cloud brokering mechanisms for optimized placement of virtual machines across multiple providers Future Generation Computer Systems 28(2)358‐367 2012 16 Celesti F Tusa M Villari and A Puliafito How the Dataweb Can Support Cloud Federation Service Representation and Secure Data Exchange 2nd Symposium on Network Cloud Computing and Applications (NCCA) 73‐79 2012 17 httpdocsawsamazoncomAWSEC2latestAPIReferenceWelcomehtml 18 httpocci‐wgorgaboutspecification


ICT‐07‐2014

required interconnection topologies (eg L2L3 overlay networks) on top of these heterogeneous cloud network services These overlay networks will be based on VNFs and services such as bridges routers load balancers or firewalls deployed on the different clouds involved

This architecture is appropriate to build and deploy automated SFC (as described in use case 3) and highly scalable applications distributed over multiple public cloud providers (as described in use case 5)

64 Multi‐cloud Security

Table 6 classifies security considerations in four different categories for the BEACON architecture The table considers security issues at the level of the CM and the NM on the vertical axis and distinguishes between application level security and infrastructure level security requirements on the horizontal axis Application level 19 20

security deals with the security of the application when it is deployed in a federated cloud Infrastructure level security deals with securing the cloud infrastructure services ie the CM and the NM and protecting them from unauthorized access from applications and users We review the four categories of security issues identified and then conclude that the requirements from the BEACON use cases indicate that application level security needs to be studied at both the CM and NM levels

Table 6 ‐ Application and infrastructure level security considerations

Component Application level security Infrastructure level security

Cloud Manager

Applications should be able to request security services from the CM eg to perform vulnerability analysis on a given VM or to apply application level firewall rules to a given HTTP session

The CM services must be secured with respect to applications running in the cloud and system administrators

Network Manager

Applications should be able to request security services from the NM eg to apply firewall rules on one or several network layers vulnerability analysis at the network level or to apply network intrusion detection

The NM services must be secured from unauthorized access eg access to the network controller must be controlled the communication between the controller and the virtual switches must be encrypted

19 Celesti A M Fazio and M Villari SE CLEVER A Secure Message Oriented Middleware for Cloud Federation IEEE Symposium on Computers and Communications (ISCC) 1ndash6 2013 20 Villari M F Tusa A Celesti and A Puliafito How To Federate Vision Clouds Through SAMLShibboleth Authentication 1st European Conference Service‐Oriented and Cloud Computing (ESOCC 2012) 259ndash274 September 2012


ICT‐07‐2014

Application level security at the CM level involves the provision of security services by the CM to the applications The CM can provide security services for VMs such as an application level firewall service or a vulnerability analysis service for VMs The application can also choose to deploy these services itself and not require any of these services from the CM The above table provided a few examples from the use cases an application can request that vulnerability analysis be performed continuously on a given VM or could request that all HTTP traffic be analysed by application level firewall rules for a given HTTP session

Application security at the NM level involves the provision of security services by the NM to the applications The NM can provide network level security services and applications should select and provide requirements for the application of the network security services to the applicationrsquos network traffic The NM will deploy and provide the security services as NFV and SFC This will allow applications to select the exact combination of network security services to meet their security requirements The above table provided a few examples from the use cases the application may request to apply network firewall rules on one or several network layers or could request a vulnerability analysis at the network level or to apply network intrusion detection to the applicationrsquos network traffic

Infrastructure security at the CM level involves the provision of security services to secure the CM The threats to the CM are both external and internal in nature The CM needs to be protected from unauthorized users who could try to access the CM even though they are not authorized to Threats may also originate from internal sources Internal threats come from authorized users deploying applications in the cloud In this case the CMmust ensure a sufficient level of isolation of applications in the multi tenant environment of the federated cloud infrastructure This will require research on securing the complete VM deployment lifecycle by the federated cloud infrastructure management including issues related to key management Internal threats can also come from the CMs within the federation who might try to access services that are not authorized to

Infrastructure security at the NM level involves the provision of security services to secure the NM The main components of the virtual networks need to be secured For example the control plane of federated virtual network needs to be protected from the applications Another security challenge is how to ensure a sufficient level of isolation and encryption of network traffic by automating the provisioning and configuration of secure SDN on demand according to security level agreements

Federated cloud networking provides the opportunity to monitor the virtualized compute storage and network resources across a federation From the security perspective this allows to detect attacks at the federation level that could not be detected at the individual cloud level We can identify many security issues having a global picture of services deployed and executed in more federated Clouds The security issues we are considering range from the intrusion detections to vulnerability scanning even to the Distributed Denial of Service (DDoS) For example the DDoS attacks might be difficult to detect by monitoring activity within a single cloud However DDoS attack patterns could be detected earlier by monitoring data


ICT‐07‐2014

from the cloud federation Within the BEACON project we will identify opportunities for improving detection of threats thanks to the enhanced monitoring capabilities provided by federated cloud networking

The requirements from the different use cases essentially refer to application level security considerations at both the CM level and the NM level The application service definition should specify required security services to be performed by the CMs and the NMs to ensure that the federated cloud meets the security requirements of the application

The main requirements on the BEACON architecture for application level security requirements to be passed to both the CM and NM imply that security requirements must be defined in the service definition The service definition must then be analysed and the security requirements for the CM must be separated from the security requirements for the NM The respective requirements must then be passed to the CM and NM for enforcement This requires the service requirements to be translated into the appropriate security policies for the cloud and NMs This will require analysing the NMs of OpenNebula and OpenStackNeutron to see how they can be integrated and exchange security policies Other issues that will have to be analysed are related to the location of the network services eg to decide which firewall NFV must be used when several are available This question on which security function to use will also have to take into account live migration of VM within the cloud federation


ICT‐07‐2014

7 Architecture for Cloud Network Federation

Figure 14 depicts a high level view of the components necessary to carry out the network federation and their interactions The following subsections describe each component The detailed design of these components is described in D31 and D41

Figure 14 Architecture for cloud network federation

The proposed federation network model addresses the challenge of federating clouds based on different network technologies in their network backbone as well as in their Cloud Management Platforms (CMP) Moreover it can be used in different cloud federation architectures such as peer cloud federation hybrid cloud federation and brokered cloud federation as described in Section 6

The Federated SDN is the software component that allows to build a Federated Network by aggregating two or more Federated Network Segments It provides a uniform interface for users in order to set up a virtual federated network in a transparent way independently from the underlying clouds In order to do this it features an API to allow for Federated Network definitions and uses adaptors to talk to the Federation Agentsrsquo API in different cloud infrastructures and to the Cloud Management Platforms

A Federated Network Segment (FNS) is a virtual network within a cloud infrastructure sustained by a physical network backbone Two or more FNS belonging to two different clouds constitute a Federated Network FNS are pre‐created and as a requirement contain a Federation Datapath From the


ICT‐07‐2014

federation point of view FNS are treated as black boxes identified by the ID and the cloud infrastructure they belong to

The Federation Agent drives the control plane of a Federated Network It informs other Federation Agents about the known network segments of its domain and instructs the Federation Datapath The Federation Agent is pre‐created and present with a well known end point in the cloud infrastructure It exposes an API that is used by the Federated SDN and controls the Data Plane through the Federation Datapath API The Federation Agent has different implementations depending on the Cloud Management Platforms

The Federation Datapath defines the Data Plane as instructed by the Federation Agent It features an API to be consumed by the Federation Agent The Federation Datapath encapsulates traffic between the different Federated Network Segments and provides the needed mapping to interconnect FNS It is assumed to be pre‐created It can be an instance of different implementations depending on the type of Federated Network (L2 or L3) to be built the nature of the tunnel (GRE Geneve or any other tunnelling protocol) and any needed adaptation

The configuration for the Data Plane relies on a full mesh where all the Federation Data Paths communicate with each other when they belong to the same Federated Network

A Federated Network is composed of one or more network segments interconnected through Federation Agents and Federation Datapaths A Federated Network allows to establish a L2 or L3 networking domain across two or more cloud infrastructures allowing VMs to establish L3 subnets to communicate across clouds


ICT‐07‐2014

8 Architecture Realizations

81 OpenNebula‐based Peer Cloud Federation and Interconnection

Several datacenters each one managed with its own OpenNebula instance can be configured as a federation Datacenters are called zones and they are configured as one master and several slaves An OpenNebula federation is a tightly coupled integration where all the instances will share the same user accounts groups and permissions configuration The Sunstone GUI allows end users to change the active zone at any time and it will automatically redirect the requests to the right OpenNebula instance at the target zone

In a federation there is a master zone and several slave zones sharing the database tables for users groups VDCs ACL rules and zones The master OpenNebula is the only one that writes in the shared tables while the slaves keep a read‐only local copy and proxy any writing actions to themaster This guarantees data consistency without any impact on the speed of read‐only actions The synchronization is achieved configuring MySQL to replicate certain tables only

Although a single Sunstone server can connect to different zones all the other OpenNebula services such as the Scheduler Public Cloud Servers OneFlow and OneGate currently only work with the local zone resources In particular OneFlow will be extended to be able to deploy services on different zones

Figure 15 depicts how OpenNebula implements peer cloud federation and interconnection using the Federated SDN

Figure 15 OpenNebula‐based peer cloud federation and interconnection


ICT‐07‐2014

82 OpenNebula‐based Hybrid Cloud Federation and Interconnection

Using hybrid drivers an AWS EC2 region SoftLayer datacenter or Azure location is modeled as any other host (albeit of potentially a much bigger capacity) in OpenNebula so the scheduler can place VMs in the external cloud as it will do in any other local host Also the same VM template in OpenNebula can describe the VM if it is deployed locally and also if it gets deployed in a remote cloud Therefore users just have to instantiate the template and OpenNebula will transparently choose if the VM is executed locally or remotely depending on the requirement and rank expressions defined for the VM

The administrator must define the credentials the region and themaximum capacity to use on the remote cloud Also it is possible to lower the priority of hosts modeling remote clouds and start using them only when the local infrastructure is full Finally hybrid drivers report the host attribute ldquoPUBLIC_CLOUD = YESrdquo so it can be used in the VM requirements to select or filter out these resources

Figure 16 depicts how OpenNebula implements hybrid cloud federation and interconnection using the Federated SDN

Figure 16 OpenNebula‐based hybrid cloud federation and interconnection

83 OpenStack‐based Brokered Cloud Federation and Interconnection

Inside an OpenStack‐based cloud federation each single OpenStack cloud is an independent element that is monitored and coordinated from an external element


ICT‐07‐2014

In order to do this the brokering element acts as a federated user sending command to the cloud federated with credentials of that cloud These credentials are obtained previously by user and provided to broker before the interactions with federated cloud start

The element that perform the OpenStack coordination role in the BEACON architecture for the aspects that not involved federated network issues is OSFFM (defined in D41) that uses HTTP REST requests directed at OpenStack REST API exposed by OpenStack modules All the requests (coming both from the Federated SDN and from the OS2OSFM Dashboard) will be addressed to EastBound API if they involve SDN management action instead they will be addressed to NorthBound API if they involve to the other cloud management action

When a user have to deploy a service in the federation he interacts with the OS2OSFM Dashboard thus to deploy virtual resources in the selected federated clouds and after that he could create the SDN connection among virtual resources if necessary User requests are forwarded to the Federated SDN that is responsible for the network orchestration in the federation and then appropriate commands are sent to the Federation Agent acting on OpenStack through the OSFFM‐SDN Adapter This kind of setup is transparent for the user because he interacts only with an abstraction of the physical federated elements provided by the multi‐cloud orchestrator (see Figure 13)

Figure 17 OpenStack‐based brokered cloud federation and interconnection


ICT‐07‐2014

Regarding orchestration activities inside a federation of OpenStack clouds new user requirements are formalized in a Heat Advanced ServiceManifest (HOT file) in YAML format

Three fields of the basic HOT file (discussed in D41) need to be modified that are

Virtual Resource management Federated Network Security for federated resources

Federation userstenants describe their services inside a manifest where high‐level information are provided to the system in terms of deployment location resource requested network configuration and policies access management rules

Themanifest created for this purposes by the federation userstenants will be stored inside a No‐SQL database (MongoDB) connected to the OSFFM module When the manifest is used by OSFFM it is elaborated in order to obtain twomanifests one for the Heat instance operating in the federated cloud and one that is used by the OSFFM to orchestrate the deployment of the federated resource included in the manifest

Figure 18 Result of the elaboration of the manifest done by OSFFM

84 FCO‐based Multi‐cloud Security

841 Vulnerability Scanner As shown in Figure 4 themanagement of multi‐cloud security issues in UC4 requires a vulnerability scanner which scans VMs in the federated clouds and generates a


ICT‐07‐2014

report This report is parsed to obtain a firewall template which is passed to each cloud platform in order to be applied to the VMs This firewall is applied to the VMs using the cloud platform API The scanner sitting on FCO can be connected via socket to the other federated clouds to pass the new created VM configuration

Vulnerability scanner written in Java uses the open source port scanner called OpenVAS 21

Figure 19 shows the sequence diagram of the actions for the use case

Figure 19 Sequence diagram of vulnerability scanner

When a VM is created the vulnerability scanner is automatically called to scan the VM and generate a firewall template based on the results of the scan On FCO the

21 httpwwwopenvasorg


ICT‐07‐2014

triggers are built to call a Java executable which socket connects with the VM 22

running the vulnerability scanner The java executable passes the details of the VM from the FCO to the scanner such as IP server UUID and email address of the user The scanner receives this information from the socket connected and kick starts a scan using OpenVAS When the scan is completed a report is generated and 23

emailed to the user

The report is parsed to generate the firewall template which is then applied to the newly created VM via platform API

The main benefit of the scanner is that each VM is scanned individually and firewall template generated is crafted as per the security loopholes identified in the report Other benefits are that this process is automated and same level of security can be established on all the VMs in the network

842 Chef The other implementation of the use case is the chef server which centralizes the modelling of the IT infrastructure automatically configuresupdatesmanages all the client VMs and is reliable Chef provides the security baseline for the use case

Chef server is installed and functioning on the FCO Chef server interconnects with other clouds in a similar manner (see Figure 20)

Figure 20 Chef infrastructure

The chef‐server and the chef‐workstation sitting on the FCO can configure the VMs in the other cloud platforms The workstation currently will have to be manually

22 httpswwwflexiantcom20141113flexiant‐trigger‐plugin‐technology 23 httpwwwopenvasorg


ICT‐07‐2014

handled but we are planning to automate this part in the future The chef‐client is installed from the workstation on to the VMs and also authenticates the VM to the chef‐server when the chef‐client is run for the first time cookbooks are pulled from the chef‐server and run on the VM The cookbooks contain recipes that have security rules defined These recipes will be applied to the VM the VM can be located on any other federated cloud

The sequence diagram is shown in the figure below

Figure 21 Sequence diagram of Chef infrastructure

The security cookbooks are written on the workstation and uploaded onto the chef‐server A new VM is created and started on the FCO The knife tool is run on the workstation to bootstrap the newly created VM the details of the VM are provided manually Knife does two things a) Installs the chef‐client on the VM and b) authenticates the new VM to the chef‐server The chef‐server adds it to the list of clients The lsquoknife client listrsquo can be run to confirm the success of above step on the chef‐server

843 Firewall Templates After the VM has been scanned the scanner will call the corresponding cloud API and create a new firewall within the target cloud This firewall will be configured based of the generated report and any vulnerabilitiesopen ports found will be automatically dealt with This firewall will then be applied to the scanned VM The


ICT‐07‐2014

generated report will be stored within the OpenVAS Scanner and can be reused to generate a new firewall within a different target cloud if required Future work will include the reading of Cloud ldquotagsrdquo attached to the VM details specific applications and as such default firewall templates will be deployed to the VM before scanning allowing faster deployment while maintaining security


ICT‐07‐2014

9 Software Requirements

This section provides the results of the requirement engineering process which derives software requirements (functional and non‐functional) from user requirements

The following tables (Tables 7 to 11) summarize the resulting software requirements together with its priority (meaning implementation order) originating user requirement and status

Table 7 ‐ Software requirements for UC1


SR11 Service placement policies across datacenters Medium UR11 Scheduled for 2nd cycle

SR12 Transparent L2 network overlay across datacenters

Medium UR12 Scheduled for 2nd cycle

SR13 Dynamic reconfiguration of L2 network overlay across datacenters

Low UR12 Scheduled for 3rd cycle

SR14 Control basic network functions on L2 network overlays


SR15 Support IP re‐acquisition Low UR13 Scheduled for 3rd cycle

SR16 Support UDP multicast traffic Low UR14 Scheduled for 3rd cycle

SR17 Provide load balancing service as VNF Low UR15 Scheduled for 3rd cycle

SR18 Minimize overhead of cross‐datacenter L2 overlay




SR21 Service placement policies across clouds High UR21 Done

SR22 Transparent L2 network overlay across clouds High UR22 Done

SR23 Dynamic reconfiguration of L2 network overlay across clouds



ICT‐07‐2014

SR24 Geographic elasticity Medium UR23 Scheduled for 2nd cycle

SR25 Network and compute resource co‐location Medium UR23 Scheduled for 2nd cycle

SR26 Minimize overhead of cross‐cloud L2 overlay Medium UR22 Scheduled for 2nd cycle

SR27 Protect cross‐cloud L2 overlay from external and internal threats via secure protocols and access controls (security)




SR31 Extension of overlay networks across clouds High UR31 Done

SR32 Network services for overlay networks Medium UR32 Scheduled for 2nd cycle

SR33 Network services for overlay networks across clouds




SR41 Firewall template movement between clouds (security)


SR42 Open source vulnerability scanner (security) High UR42 UR43

Done

SR43 Provide network level security services (eg firewall or vulnerability scanner) as VNF and SFC (security)


SR44 Applications can request security services from the NM (security)

Low UR42 UR44

Scheduled for 3rd cycle

SR45 Create firewall templates from vulnerability scanner (security)



ICT‐07‐2014



SR51 Location‐aware placement policies High UR51 Partially done

SR52 Geographic placement policies Medium UR52 Scheduled for 2nd cycle

SR53 Replicate the database Medium UR54 Scheduled for 2nd cycle

SR54 Minimize response time for the end user by staying close to customers


SR55 Deploy into different clouds to create hybrid cloud setups (privatepublic) with federated networking


SR56 Protect VMs from external and internal threats (security)


SR57 Monitor the federation for early security threat detection (security)



ICT‐07‐2014

10 Development Roadmap

Table 12 relates use cases and architectures It also describes how the proposed architectures will be realized as described in Section 8 and enumerates the involved partners (responsible partner in bold letters)

Table 12 ‐ Use cases architectures and realizations of the BEACON project

Use case Architecture Realization Involved partners

UC1 Peer cloud federation and interconnection

OpenNebula‐based ONS UCM

UC2 Hybrid cloud federation and interconnection

OpenNebula‐based ONS UCM UME CETIC

UC3 Brokered cloud federation and interconnection

OpenStack‐based IBM UME CETIC

UC4 Multi‐cloud security FCO‐based FLEX CETIC UME


OpenStack‐based LSY UME IBM CETIC

The priority given to each requirement in Section 9 determines the implementation order Therefore in the second development cycle the project will focus onmedium priority requirements and any high priority requirement not yet done


ICT‐07‐2014

PART III Software Verification and Validation Plan

11 Software Verification

This section presents a list of methods for verifying the software requirements defined in Section 9 At the first review we plan to demonstrate high priority software requirements These requirements are intended to be implemented in the different design and development cycles and will be verified and demonstrated upon their completion as part of WP5

Table 13 summarizes the requirements addressed in the first design and development cycle and their corresponding verificationmethods and demonstration scenarios Detailed information about verification of these requirements is provided in D54

Table 13 ‐ Demo scenarios and verification methods for first cycle software requirements

Id Description Verification method Demonstration scenario

SR21 Service placement policies across clouds

Check if placement agrees with policies

Deploy a service with cloud location restrictions

SR22 Transparent L2 network overlay across clouds

Connectivity test (ping) between VMs

Deploy VMs in different clouds connected to the same overlay L2 network using private IPv4 andor IPv6 addresses belonging to the same logical network

SR31 Extension of overlay networks across clouds

Connectivity test (ping) between VMs in distant clouds

Deploy two VMs with private IP addresses in different clouds connected to the same logical tenant network and demonstrate their reachability over overlay network

SR42 Open source vulnerability scanner

Show scanner scanning VM within Flexiant platform

Set up open source scanner that can access public IPrsquos

SR51 Location‐aware placement policies

Use application provided metrics for response time measurement

Configure constraints to enforce the deployment of the application into different clouds with different network conditions between client and application service


ICT‐07‐2014

Table 14 summarizes the requirements to be addressed in the second design and development cycle and their corresponding verificationmethods and demonstration scenarios Detailed information about verification of these requirements will be provided in D55

Table 14 ‐ Demo scenarios and verification methods for second cycle software requirements


SR11 Service placement policies across datacenters


Deploy a service with datacenter location restrictions



Deploy VMs in different datacenters connected to the same overlay L2 network using private IPv4 andor IPv6 addresses belonging to the same logical network


Check if L2 network overlay reconfigures and performance improves

Deploy VMs in different clouds connected to the same overlay L2 network and generate bad performance metrics

SR24 Geographic elasticity

Check if service grows in the appropriate geographic location

Deploy a service with cloud location restrictions and generate load increase from different geographic locations

SR25 Network and compute resource co‐location

Check location of resources

Deploy a service composed of network and compute resources with cloud location restrictions

SR26 Minimize overhead of cross‐cloud L2 overlay

Measure overhead Deploy VMs in different clouds connected to the same overlay L2 network


Check if security mechanisms are in place

Deploy VMs in different clouds connected to the same secured overlay L2 network

SR32 Network services for overlay networks

Choose network service eg load balancer DHCP

Deploy VMs in the federated cloud that require network service support for example


ICT‐07‐2014

firewall or DPI and demonstrate its ability to work with overlay network supported by SDN controller andor OVS

load balancer Check network service APIs with cloud network management and SDN control plane Validate traffic forwarding through network service in SDN‐managed overlay networks

SR41 Firewall template movement between clouds

Template re‐created in second target cloud

Trigger movement into second target cloud and show new template created in new cloud platform


Template created in the vulnerability scanner VM

The newly created VM is scanned to generate the report Show the creation of the new firewall template based on the report

SR52 Geographic placement policies

Increase application

load to trigger a

scale‐out action on

the application

component with the

associated elasticity

rules

Add geographic constraints

into the elasticity rules

SR53 Replicate the database

Check if the database

is running inside the

cluster over the

federated network

without any

performance

degradation

(and in case

replication check if

data exists in all

replicated database)

Define a cluster for the used

NoSQL database using the

federated network

infrastructure and enable the

high availability option (ie

replication)


Check that the latency is reduced for a user located near to the Cloud providing the access point for the application

Deploy the application over multiple clouds using a federated network


ICT‐07‐2014


Check that the application running in CB can access data (or an application service providing the data) in CA

Deploy one instance of the application in Cloud CA and another instance in Cloud CB Federate a virtual network for tenant T in CA with a virtual network in CB


ICT‐07‐2014

Conclusions

This document describes the use cases that will guide the development of the project and the main user requirements derived from these use cases From these requirements we have extracted a prioritized list of software requirements to be implemented and we have defined the roadmap and the verification methods to address these software requirements for the second design and development cycle of the project Also several alternatives for the architecture of the BEACON Framework have been also defined


ICT‐07‐2014

Document History

Version Issue Date Status 1

Content and changes

01 2‐11‐2015 Draft Based on D21

02 22‐01‐2016 Draft Input and changes for second DD cycle

09 11‐02‐2016 Peer‐Reviewed Input from reviewers

10 29‐02‐2016 Submitted

Peer Review History

Version Peer Review Date Reviewed By

02 4‐02‐2016 UME

02 5‐02‐2016 Philippe Massonet (CETIC)

1 A deliverable can be in one of these stages Draft Peer‐Reviewed Submitted and Approved


ICT‐07‐2014

Executive Summary






ICT‐07‐2014






3 Use Cases 12



















51 OpenNebula 23

52 OpenStack 25

53 OVN 28








ICT‐07‐2014








842 Chef 46






Conclusions 57


ICT‐07‐2014

List of Figures























ICT‐07‐2014

List of Tables
















ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

Executive Summary






ICT‐07‐2014






3 Use Cases 12



















51 OpenNebula 23

52 OpenStack 25

53 OVN 28








ICT‐07‐2014








842 Chef 46






Conclusions 57


ICT‐07‐2014

List of Figures























ICT‐07‐2014

List of Tables
















ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014






3 Use Cases 12



















51 OpenNebula 23

52 OpenStack 25

53 OVN 28








ICT‐07‐2014








842 Chef 46






Conclusions 57


ICT‐07‐2014

List of Figures























ICT‐07‐2014

List of Tables
















ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








842 Chef 46






Conclusions 57


ICT‐07‐2014

List of Figures























ICT‐07‐2014

List of Tables
















ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

List of Figures























ICT‐07‐2014

List of Tables
















ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

List of Tables
















ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014







CM Cloud Manager




DB Database







FW Firewall








L2 Layer 2

L3 Layer 3



NM Network Manager




ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

OS Operating System















VM Virtual Machine






ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

1 Introduction






ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014












ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014


3 Use Cases










ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014














ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014









ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014







ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014










ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014









ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014













ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014






ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

4 User Requirements

















Status



Medium UC3


Low UC3


ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014







Medium UC4



Medium UC4






Medium UC5


Medium UC5


Medium UC5



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014




51 OpenNebula










2 httpopennebulaorg


ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014













ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014






52 OpenStack





ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014














ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014





53 OVN










ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014











ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014












ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014










ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








Cloud Manager



Network Manager





ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014







ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014





ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014







ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014









ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014









ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014






ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014










ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014








ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014



emailed to the user









ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014







ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

























ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

















Done




Low UR42 UR44





ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014















ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014
















ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014























ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014




























ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014











load to trigger a


the application

component with the


rules






cluster over the

federated network

without any

performance

degradation

(and in case


data exists in all




federated network



replication)





ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014





ICT‐07‐2014

Conclusions



ICT‐07‐2014

Conclusions



Documents

BEACON - static1.squarespace.com€¦ · cases that guide the BEACON project, and identifies the main user requirements derived from these use cases. ... 5.2. OpenStack 25 5.3. OVN