You are on page 1of 139

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Framework, and Initial Prototype Commercial in Confidence Socially-aware Management of New Overlay Application Traffic

Socially-aware Management of New Overlay Application Traffic with Energy Efficiency in the Internet

European Seventh Framework Project FP7-2012-ICT- 317846-STREP

Deliverable D3.2 Technologies, Implementation Framework, and Initial Prototype

The SmartenIT Consortium

Universität Zürich, UZH, Switzerland Athens University of Economics and Business - Research Center, AUEB, Greece Julius-Maximilians Universität Würzburg, UniWue, Germany Technische Universität Darmstadt, TUD, Germany Akademia Gorniczo-Hutnicza im. Stanislawa Staszica w Krakowie, AGH, Poland Intracom SA Telecom Solutions, ICOM, Greece Alcatel Lucent Bell Labs, ALBLF, France Instytut Chemii Bioorganicznej PAN, PSNC, Poland Interoute S.P.A, IRT, Italy Telekom Deutschland GmbH, TDG, Germany

© Copyright 2014, the Members of the SmartenIT Consortium

For more information on this document or the SmartenIT project, please contact:

Prof. Dr. Burkhard Stiller Universität Zürich, CSG@IFI Binzmühlestrasse 14 CH—8050 Zürich Switzerland

Phone: +41 44 635 4331 Fax: +41 44 635 6809 E-mail: info@smartenit.eu

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

Document Control

Title: Technologies, Implementation Framework, and Initial Prototype

Type: Public

Editor: George Petropoulos

E-mail: geopet@intracom-telecom.com

Author(s): George Petropoulos, Antonis Makris, Sergios Soursos, Lukasz Lopatowski, Jakub Gutkowski, Thomas Bocek, Daniel Donni, Patrick Gwydion Poullie, Guilherme Sperb Machado, Piotr Wydrych, Zbigniew Dulinski, Grzegorz Rzym, David Hausheer, Fabian Kaup, Jeremias Blendin, Frederic Faucheux, Ioanna Papafili, Gerhard Hasslinger

Doc ID: D3.2-v0.8

Amendment History

Version

Date

Author

Description/Comments

v0.1

Sep 11, 2013

George

First version, Table of contents

v0.2

Nov 28, 2013

George

ToC update

v0.3

Feb 26, 2014

George, Antonis, Sergios, Lukasz, Jakub, Thomas

Contributions to chapter 4

v0.4

Jun 6, 2014

George, Antonis, Lukasz, Jakub, Thomas, Daniel, Piotr, Zbigniew, David, Fabian, Jeremias

Contributions to chapter 3, 4 and 5.

v0.5

June 11, 2014

Lukasz, Antonis, Thomas, Frederic

Contributions to chapter 5.

v0.6

July 2, 2014

George, Lukasz, Jakub, Patrick, Guilherme, Piotr, Frederic

Contributions to all chapters.

v0.7

July 9, 2014

Ioanna, Gerhard

Internal review.

v0.8

July 15, 2014

George, Lukasz, Patrick, Thomas, Piotr, Fabian, Jeremias, Frederic

Internal review comments addressed, final version.

Legal Notices The information in this document is subject to change without notice. The Members of the SmartenIT Consortium make no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the SmartenIT Consortium shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Table of Contents

1 Executive Summary

6

2 Introduction

7

2.1 Purpose of the Deliverable D3.2

7

2.2 Document Outline

8

3 Architecture Overview

9

3.1 Entities

10

3.2 Interfaces

10

3.3 System Deployment

12

4 Technology Scouting

14

4.1 Programming Languages

14

4.2 Frameworks

16

4.2.1 JBoss Netty approach

16

4.2.2 OSGi-based approach

17

4.3 External interfaces libraries and tools

18

4.3.1 Social Monitor

18

4.3.2 Cloud Manager

20

4.3.3 QoS monitor

22

4.3.4 QoE monitor

27

4.3.5 Fixed/Mobile Network Traffic Manager

28

4.4 Internal interfaces protocol formats

32

4.4.1 Google Protocol Buffers

32

4.4.2 Apache CXF Distributed OSGi

33

4.4.3 JSON

33

5 Implementation Framework

34

5.1 Tools

34

5.1.1

Specification Language

34

5.1.2

Programming Languages

34

5.1.3

Libraries

35

5.1.4

Tool chain

36

5.1.5

Testbed

36

5.1.6

Version Control

37

5.1.7

Issue Tracking

38

5.1.8

Continuous Integration Server

38

5.2 Procedures

39

5.2.1 System Release Process

39

5.2.2 Development Process

40

 

5.2.3 Roles

40

5.2.4 Meetings

41

5.3 System tree layout

41

6 Entities

46

6.1 S-Box

46

6.1.1

Network Traffic Manager

46

6.1.2

Quality of Service Analyzer

58

6.1.3

Economic Analyzer

67

6.1.4

Database

73

6.1.5

Inter-SBox Communication Service

84

6.1.6

SBox-SDN Communication Service

87

6.1.7

User Interface

90

6.2 SDN Controller

108

6.2.1 SBox-SDN Server Interfaces

108

6.2.2 SDN Controller based on Floodlight 0.90

110

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

7 Summary and Conclusions

117

8 SMART Objectives Addressed

119

9 References

121

10 Abbreviations

125

11 Acknowledgements

127

Appendix A.

History of system releases

128

A.1.

Version 1.0

Appendix B.

Internal Interfaces Protocol Format

128

136

B.1.

Reference and Compensation Vectors JSON Format

136

B.2.

Configuration Data JSON Format

136

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

(This page is left blank unintentionally.)

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

1 Executive Summary

The aim of Deliverable 3.2, entitled “Technologies, Implementation Framework, and Initial Prototype (Initial Version)”, is to describe the technology scouting, justify the technology selections made, define the implementation framework and finally, describe the design and development of the SmartenIT prototype for the first system release.

Deliverable 3.2 is the outcome of Task 3.2 “Technology Scouting and Definition of Implementation Framework”, and includes first results of Tasks 3.3 “Development of Prototype Components” and 3.4 “Implementation of Selected Application”, which will produce and document the final version of the SmartenIT prototype and application towards the end of the project.

It’s the first outcome of the engineering aspect of Work Package 3 “Architecture Design and Engineering”, providing technical details on the selected implementation framework and the documentation of the first release of the SmartenIT software.

Hence, the goals of this deliverable are the following:

The summary of the technology scouting, including all the proposed technologies, libraries and tools, which could be used to setup the implementation framework, support the development of the SmartenIT prototype components and provide and/or extend required existing functionalities.

The justification of choosing the final technologies and tools to be used throughout the SmartenIT implementation, through a selection process which provides the pros and cons of each approach, the prototype’s requirements as expressed by the mechanisms’ specification and, finally, the selection criteria.

The mapping of the latest SmartenIT architecture entities, components and interfaces to what was actually implemented in the first release of the SmartenIT software, as well as their deployment diagrams.

The definition of the implementation framework, including the methods, documents and tools to support the development and integration process, as well as the generated system tree, libraries and build commands to produce the release artifacts.

The design and implementation details of each component, including their interfaces to other components, sequence and class diagrams, and tests to ensure that they operate as expected.

To conclude, this deliverable can stand as the engineering and implementation documentation of the first release of the prototype, as well as the technology scouting report, part of which will be deployed in future releases and documented in the final deliverable, D3.4 “Prototype Implementation, Validation and Selected Application”.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

2 Introduction

The overall objective of the SmartenIT project is to deal with the management of traffic generated by applications running on the Cloud. In this sense, the project offers Cloud and Overlay traffic management solutions for generated traffic that flows over the public Internet. The proposed solutions consider the following objectives:

a) energy efficiency,

b) incentive compatibility for all stakeholders,

c) social awareness, and

d) QoE awareness.

They aim to improve the energy efficiency of network equipment and end-user devices, to

improve the QoE for users and efficiently manage the inter-domain and inter-cloud traffic

to benefit all the involved stakeholders.

A certain number of traffic management mechanisms were described and specified in

Deliverable 2.2 [1]. The Dynamic Traffic Management (DTM) mechanism was selected by the consortium in the respective Tasks 2.3 and 2.4, as the first traffic management mechanism to be implemented. DTM [1] is a generic concept addressing the problem of minimizing the ISP's costs related to the amount of traffic in the network. The DTM mechanism performs optimization to find a best solution over criteria and conditions defined by the ISP.

Simultaneously with the research work performed in the context of WP2, the WP3 team set up some methods and procedures to prepare and design the implementation of the selected specified mechanisms:

Initial architecture design, documented in D3.1 [2] was adapted to host DTM- required functionalities and components, and will be documented in the upcoming Deliverable 3.3.

Partners were also involved in the technology scouting, investigating all available existing technologies and tools, which could support the development, installation and testing of any specified traffic management mechanism, and finally, selected the most relevant ones, based on specific criteria.

A common implementation framework was initially agreed and deployed, and specific roles, documents, and release/development cycles were defined, to ease the development, integration and testing of the SmartenIT software.

The aforementioned methods and tools prepared the ground for the successful implementation of the DTM mechanism, which is the first release of the SmartenIT software.

2.1 Purpose of the Deliverable D3.2

This deliverable focuses on the technical documentation of the implemented SmartenIT components, which host the DTM mechanism functionalities. It provides specific details on their supported functionalities, interfaces exposed towards other components, their

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

implementation design, including class and sequence diagrams as well as algorithms and pseudocode, and finally, the local tests performed to confirm their functional behavior.

In addition, the deliverable provides information on important engineering aspects:

the DTM mechanism components to the latest SmartenIT

a) the

mapping

of

architecture,

b) the outcome of the technology scouting and the final selection of the technologies and tools to be used throughout the SmartenIT implementation, and,

c) the definition of the implementation framework, which includes the technologies, tools, as well as methods, roles, meetings and documents to support and ease the implementation effort.

2.2 Document Outline

Chapter 3 briefly describes the subset of the SmartenIT architecture entities, components and interfaces that are required to host the DTM mechanism functionalities, and presents its deployment diagram.

Chapter 4 is the outcome of Task 3.2, which presents all the investigated technologies and tools that could support the development and deployment of all proposed traffic management mechanisms, including the DTM. For all approaches, their advantages and disadvantages, as well as their relevance to SmartenIT are presented, including the justification of the final selection.

The agreed implementation framework is then described in Chapter 5. It includes the tools and methodologies to support the implementation effort in general, as well as the specific libraries required for the first release. The generated system tree and build instructions are also presented.

Chapter 6 provides the technical documentation of each entity and each component of the first release, including design, development and testing details.

Chapter 7 provides a brief summary of the deliverable’s conclusions, including decisions in the technology scouting, the implementation framework, and the implemented components of the DTM mechanism.

The SMART objectives, which are defined in the Description of Work [89], are addressed in Chapter 8.

Finally, the Appendix A includes the history of system releases, including the features, issues, and integration test cases for each release, while Appendix B presents the SmartenIT-internal protocol formats.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

3 Architecture Overview

The initial SmartenIT architecture design was documented in D3.1 [2], which was published during the early stages of the project. Since then, the architecture has evolved to host all specified mechanisms, with new components and interfaces. The current status of the system architecture, which will be documented in detail in deliverable D3.3, is depicted in Figure 1. This section provides a quick overview of the current architecture and shows how the DTM implementation maps to it.

The figure shows all the required components of the architecture as well as the necessary interfaces. The color-coding of the components denotes whether a component:

already exists in external systems (white components),

is required to be implemented by SmartenIT (blue components),

is required by the DTM mechanism (orange components).

Datacenter/NaDa/Cloud Manager Overlay Manager Traffic Load Inter DC/Cloud/NaDa Redirector Balancer communication
Datacenter/NaDa/Cloud Manager
Overlay
Manager
Traffic
Load
Inter DC/Cloud/NaDa
Redirector
Balancer
communication
Workflow
Hypervisor
Manager
ALTO
Traffic Manager
ISCS
ISCS
Billing/
Economics
Inter-domain
Accounting
Analyzer
communication
Cloud Traffic Manager
E.g. inter-ALTO
Social Monitor
Social Analyzer
Fixed/Mobile Network
SDN Controller
Traffic Manager
E.g. FB API
OSNs
(Facebook etc.)
QoS/QoE
Network
Energy
Analyzer
Analyzer
Analyzer
E.g. SNMP,
BGP, Netflow
OpenFlow
Topology/
Switching/
QoE Monitor
QoS Monitor
Proximity
Energy Monitor
Forwarding
Monitor

Figure 1: The SmartenIT architecture.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

3.1 Entities

The architecture diagram is instantiated into the entities presented in Figure 2. This diagram includes both the architectural components, and the implementation-specific ones, used to provide support functionalities. In addition, the implemented interfaces are also defined. The white colored components were not implemented, but used, as well as the grey colored Network Entity interfaces.

ui S-Box ssdn ISCS UI Sbox-SDN iscs2 ntm3 db DB Fixed/Mobile Network Traffic Manager ntm1
ui
S-Box
ssdn
ISCS
UI
Sbox-SDN
iscs2
ntm3
db
DB
Fixed/Mobile Network
Traffic Manager
ntm1
ntm2
QoS Analyzer
Economics
Analyzer
eca1
Manager ntm1 ntm2 QoS Analyzer Economics Analyzer eca1 SDN Controller Interfaces sdn2 SDN Controller sdn1
Manager ntm1 ntm2 QoS Analyzer Economics Analyzer eca1 SDN Controller Interfaces sdn2 SDN Controller sdn1
Manager ntm1 ntm2 QoS Analyzer Economics Analyzer eca1 SDN Controller Interfaces sdn2 SDN Controller sdn1
SDN Controller Interfaces sdn2 SDN Controller
SDN Controller
Interfaces
sdn2
SDN
Controller

sdn1

eca1 SDN Controller Interfaces sdn2 SDN Controller sdn1 openflow Network Entity Switching/ Forwarding QoS Monitor

openflow

Network Entity Switching/ Forwarding QoS Monitor
Network Entity
Switching/
Forwarding
QoS Monitor

snmp

iscs1

Figure 2: The DTM mechanism entities/components/interfaces diagram.

Table 3-1 presents the list of the implemented entities and components that provide the DTM functionalities, and the respective Deliverable chapter or section in which their implementation details are further described.

Table 3-1: List of Entities for DTM implementation

Entity

Components

Reference

S-Box

Inter-SBox Communication Service (ISCS), Database (DB), User Interface (UI), SBox-SDN, Economics Analyzer, QoS/QoE Analyzer, Fixed/Mobile Network Traffic Manager

Section 6.1

SDN Controller

SDN Controller, Interfaces

Section 6.2

3.2 Interfaces

The implemented interfaces presented in Figure 2 are defined in Table 3-2, also referencing the section in which are further described.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Table 3-2: List of Interfaces for DTM implementation

Interface

Component

Component

Purpose

Reference

ID

providing the

using the

interface

interface

ntm1

Network Traffic

QoS Analyzer

X

Vector update

Section

Manager

 

6.1.1.2

ntm2

Network Traffic

Economic

Reference vector

Section

Manager

Analyzer

update

6.1.1.2

ntm3

Network Traffic

Inter-SBox

Reception of reference and compensation vectors from remote

Section

Manager

Communication

6.1.1.2

Service

SBox

eca1

Economic

QoS Analyzer

X

and Z Vector update

Section

Analyzer

 

6.1.3.2

db

Database

Network Traffic

Access to database

Section

Manager,

tables

6.1.4.2

Economic

Analyzer, QoS

Analyzer, User

Interface

ssdn

SBox-SDN

Network Traffic

Configuration data, compensation and reference vectors preparation to be sent to SDN Controller

Section

Communicatio

Manager

6.1.6.2

n

Service

ui

User Interface

-

Access to SBox User

Section

Interface

6.1.7.2

sdn1

SDN Controller

SBox-SDN

Configuration data, compensation and reference vectors update to SDN

Controller

Section

Interfaces

Communication

6.2.1.2

Service

sdn2

SDN Controller

SDN Controller

Configuration data, compensation and reference vectors

update

Section

Interfaces

6.2.2.2

iscs1

Inter-SBox

Inter-SBox

Reference and compensation vector update to remote SBox

Section

Communicatio

Communication

6.1.5.2

n

Service

Service

iscs2

Inter-SBox

Network Traffic

Reference and compensation vector preparation to be sent

Section

Communicatio

Manager

6.1.5.2

n

Service

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

to remote SBox
to remote SBox
to remote SBox

to remote SBox

to remote SBox

3.3 System Deployment

The deployment diagram of the first release of the SmartenIT software is presented in Figure 3. The diagram presents the devices, processes and artifacts used, to deploy an instantiation of the DTM mechanism.

More specifically, the SBox server is an x86 server with Ubuntu 14.04 [4] installed, and requires the installation of Java [3] and the Jetty web server [14], in which the sbox.war artifact is deployed. The sbox.war contains all the required components (UI and DB) for the SmartenIT web application, exposing an HTTP/HTTPS web interface, accessible by any web browser from the administrator’s PC. In addition, the main.jar is the main executable of the SBox, including all components implementing DTM mechanism’s functionalities. It uses the JBoss Netty NIO framework [9] to expose the ISCS (Inter-SBox Communication Service) interfaces using a custom SmartenIT-protocol over TCP, and access the SDN Controller’s REST API over HTTP. The Sqlite [45] is also used as the SBox’s database.

The SDN Controller also requires an x86 server, with Ubuntu 14.04 [4] as its operating system, requiring Java [3] to be installed. The floodlight.jar executes all the Floodlight [35] SDN Controller’s processes, extended with SmartenIT functionalities, and the Interfaces component, which provides the SBox-SDN communication over HTTP.

Finally, the DTM mechanism requires also a network device, which is Openflow- compatible [32], and also supports SNMP [38]. QoS Analyzer of SBox retrieves SNMP measurements from the latter interface, while the network device also interacts with the exposed Floodlight SDN Controller’s interface using the OpenFlow protocol.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Sbox server Jetty web Server User PC sqlite HTTP(S) Web Browser sbox.war JDBC main.jar EcA
Sbox server
Jetty web
Server
User PC
sqlite
HTTP(S)
Web Browser
sbox.war
JDBC
main.jar
EcA
NTM
DB
TCP
ISCS
QoA
SSDN
(Custom)
SDN Controller Server floodlight.jar HTTP Interfaces
SDN Controller Server
floodlight.jar
HTTP
Interfaces

UDP

(SNMP)

Network Device
Network Device

TCP

(OpenFlow)

Figure 3: DTM mechanism deployment diagram

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

4 Technology Scouting

In the process of SmartenIT implementation framework definition, a few alternatives were proposed by the consortium to be adapted and used in the development of the SmartenIT components. These suggestions concerned the programming languages to be used for entities development, the frameworks and/or containers to support and ease the integration of all components, the libraries and tools that could be imported and used to implement certain functionalities, and finally, the protocol serialization formats to define the internal interfaces between SmartenIT entities.

The advantages and disadvantages of each suggested technology are identified and briefly described in the sections below, as well as the justification for the final selection. The SmartenIT consortium selected certain technologies which will be adapted in all releases of the SmartenIT software, taking into account the following criteria:

Relevance to specified mechanisms,

Lack of restrictions,

Good performance,

Ease of prototyping and small learning curve,

Open-source nature,

Partners’ familiarity and expertise.

4.1 Programming Languages

Certain requirements for the selection of the programming language were identified at the beginning of the technology scouting procedure:

The SmartenIT software system tree should consist of less than 2-3 system trees, with a common implementation framework that spans as many as possible entities, in order to ensure efficient implementation work, minimum development and integration effort, and a homogeneous prototype.

The latest entities/component diagram implies that a lot of components share the same or similar functionality across multiple entities. Taking into account the aforementioned requirement, certain entities (e.g. SBox, uNaDa, and DataCenter) should use the same implementation framework, in order to avoid code re-writing in multiple programming languages.

Certain entities in the SmartenIT architecture impose hardware and software limitations. While the SBox or the Datacenter management platform do not have such restrictions, since they are installed on network providers’ (NSPs’) and/or Cloud Operators’ infrastructure, the uNaDa is installed at the end-user’s premises, and thus, requires being a low-spec machine, such as a WiFi-router. Moreover, besides the limited hardware characteristics such devices have (e.g. minimum memory, disk storage, low-spec processors, etc.), they also deploy limited Linux distributions, packaged with the minimum list of libraries. The same applies to the network device, which could be any switch or router. In the case of the end-user device, there are 2 options; (a) a mobile device, hence the application should be

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

implemented using the respective native API (e.g. Java for Android [6], Objective C for iOS [7], etc.), and (b) a standard PC, thus the application could be implemented using any programming language.

Taking into account the abovementioned requirements, a few programming languages and frameworks were suggested for the implementation of SBox, uNaDa, and DC entities:

C++ for its high performance both in low- and high-spec devices, Python and Java for their availability of frameworks and ease of development. Table 4-1 presents the proposed approaches for each programming language, including tools and libraries that could be used in implementation and integration.

Table 4-1: Programming Languages’ approaches

 

C++ approach

   

Python approach

 

Linux

Linux

C++

Python

Boost::asio [41] (async networking library)

 

Twisted [49] (async networking library + web server)

CppCms [42] (web application framework)

Apache [43] (Sbox, DC), nginx [44] (uNaDa)

Django [50] (web application framework)

Sqlite [45] (DB)

 

Apache [43] (Sbox, DC), nginx [44] (uNaDa)

Google protobuf [39] (data serialization)

 

Sqlite [45] (DB)

 

CMake [46] (CP/CL build tool)

Google protobuf [39] (data serialization)

Google

test [47]

+

gcov [48] (unit test +

code

unittest [51] + unittest-xml-reporting (unit tests) + coverage (code coverage)

coverage)

 
 

Java approaches

 
 

JBoss Netty approach

   

OSGi approach [8]

 

Linux

Linux

Java

Java

Netty [9] (async nio framework)

Jetty [14] (web server) + HTML + JS + Bootstrap (UI) [52]

OSGI container – Karaf [10] (one instance per entity)

CXF

DOSGi

[11]

(SOAP

communication

SQLite/ H2 [16] /Derby [17] (DB)

 

between entities)

 

Google protobuf [39] (data serialization)

 

Maven [19] (build tool)

Junit [20] (unit testing), Cobertura [23] / Sonar [22] (quality reporting/code coverage)

Tomcat [13] /Jetty [14] (web server) + JSF2 + PrimeFaces [15] (UI)

H2 [16] /Derby [17] (DB) + EclipseLink JPA [18] (persistence)

Maven [19] (build tool)

Junit [20] (unit testing), Cobertura [23] / Sonar [22] (quality reporting/code coverage), Pax Exam [21] (integration testing for OSGI)

After some internal discussions and tests indicating that Java could run in a low-spec device, such as the Raspberry Pi [5], without significant performance issues and taking into account partners’ expertise and familiarity, Java [3] was selected as the programming language for the SBox, uNaDa, and DC entities.

With regards to end-user device, either (a) a mobile application or/and (b) a PC-based client would be implemented. The consortium agreed to initially proceed with the mobile application development, and if mechanisms’ specifications require a PC-based client as

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

well, it would be developed in future releases. Android [6] was selected for end-user device due to its open-source nature, ease of development and partners’ expertise.

4.2

Frameworks

Two candidate frameworks/containers were proposed to be the basic implementation frameworks for SBox, and uNaDa entities, the Apache Karaf OSGi container ([8], [10]), and the NIO client-server framework JBoss Netty [9].

4.2.1 JBoss Netty approach

JBoss Netty [9] is a framework, written in Java and integrated as a Java API. It facilitates the development of network applications. It is asynchronous, in the sense that function calls do not block the caller until completion. It is also event-driven, meaning that thread orchestration, synchronization and scheduling are based on events’ ordering. Besides being a skeleton for network applications development, Netty supports a wide range of well established standard protocols (e.g. TCP, UDP, and HTTP).

A Netty application is written as a plain, simple Java application. Its components become

integrated as explicit Java packages. Development of a Netty server is similar to writing a

socket server, with some additional framework-specific characteristics.

Netty is used to implement in Java, client – server applications, either in a high (i.e.

application) or low (i.e. network) layer. Netty is proven to be suitable for low latency, high scalability applications. It can be deployed even in low-spec hardware machines as for its memory footprint is significantly low and its asynchronous nature permits better utilization

of resources.

asynchronous nature permits better utilization of resources. Figure 4: Network application development stack on top of

Figure 4: Network application development stack on top of core functionalities provided by Netty [9]

Netty has its own configurable model for events/messages/threads handling, separating the interfaces from the logic and easing development. Due to its asynchronous nature, it inherently supports multi-threading and concurrent connections handling.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

4.2.2 OSGi-based approach

The core part of the OSGi-based approach is the Apache Karaf [10], which is a small and lightweight OSGi based runtime. The OSGi [8] (Open Service Gateway Initiative) technology is a set of specifications that define a dynamic component system for Java. These specifications mainly aim to reduce software complexity by providing a highly modular architecture. OSGi provides an environment for the modularization of applications into smaller bundles (components). Each bundle is a dynamically loadable collection of classes, jars, and configuration files that explicitly declare their external dependencies (in Manifest file). Bundles have to be deployed and run on OSGi container like Apache Karaf. Additionally to the modularization, this approach allows developers to benefit from several interesting OSGi/Karaf features such as module versioning (multiple versions of the same bundle may coexist within the same Java VM), or lifecycle management (i.e. bundles can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot).

Apache Karaf is a broader “concept” that determines how an application is developed, tested and deployed. Using Karaf is not essential for the SmartenIT prototype but its features may simplify the development and integration processes.

Following features may be helpful for the SmartenIT development process:

Karaf as a container – all components and required libraries installed in one place,

Karaf as a dependency resolver – bundle state (uninstalled, installed, resolved, active, starting, stopping) determines whether all required dependencies are installed,

Karaf as a logging system – all logs in one place,

Karaf as an integration testing platform – Pax Exam [21] library enables “in- container testing for OSGi” meaning that for test purposes an instance of Karaf is run in memory (with desired bundles installed), and communication and interoperability between bundles can be tested, as if running in a real deployment environment,

Easy provisioning – Karaf provides a simple way to provision applications or features. The provisioning system uses xml "repositories" that define a set of features”. In simple words, Karaf enables using xml file for defining a set of components (with required libraries, configuration and configuration files) to be installed using a single command,

Karaf as a multi-platform system – each developer can install Karaf and use it in development process on its own operating system (e.g. Windows XP, Windows 7, Linux, Mac OS X),

Karaf as a lightweight container - clean binary distribution of Karaf 2.3.3 requires only up to 20 MB disk space and JDK 1.5.x or greater, moreover after starting it uses around 64 MB of RAM (checked on Ubuntu).

The use of Apache Karaf will require from developers some additional knowledge about OSGi and Karaf itself. However the required knowledge is proportional to the number and complexity of Karaf features to be used. OSGi bundles will be prepared by a Maven [19] plug-in configured in the POM file. In most cases, no manual edition of Manifest files will be required. Communication via services adds also some complexity (e.g. the necessity to

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

configure the blueprint file – additional configuration file). This framework also determines how integration tests are written and executed (using Pax Exam) which requires also some efforts.

It is assumed that the SBox and uNaDa entities will lie more on the network layer, interacting with network entities, e.g. routers, switches and external monitoring tools. The communication with such elements, as well as the SmartenIT entities is considered as performance-critical. Learning curve and ease of development were some additional criteria required by the consortium, with regards to framework selection. Taking into account the aforementioned factors, JBoss Netty [9] was selected by the consortium as the core framework for the SBox and uNaDa entities.

4.3 External interfaces libraries and tools

4.3.1 Social Monitor

In order to monitor social activity in existing Online Social Networks (OSN), libraries are required to be able to communicate to OSN APIs and to collect relevant information. Some libraries are able to communicate to multiple existing OSNs, while others are specific or specialized to one single OSN. For the scope of the SmartenIT Social Monitor implementation, the chosen library is required to meet the following characteristics:

Flexibility: It is possible to easily extend the library and also send custom queries to the OSN.

Open Source: The library is published under an open source license, maintained regularly and well documented.

API Completeness: The library supports the most important functionalities of the underlying OSN API.

Common OSN Data Model: The library is based on a general data model, independent of the underlying OSN.

OSN Authentication: The library supports/handles OSN authentication (e.g. oAuth 1.2 [53]).

OSN Support: The library supports at least Facebook as the underlying OSN.

4.3.1.1 Social Monitor Libraries; Pro / Cons

Spring Social, RestFB and Twitter4J are the most used libraries for Facebook [59] and Twitter [60], and are also officially listed by these OSNs. Facebook4J is rather new, but developed by the same developer as Twitter4J, which is well structured and considered a stable library. All four alternatives use a data model, which is specific for the underlying OSN and would need adapters to be compliable with other OSNs. Except of RestFB, all other presented libraries have OSN authentication support, which is a required feature, but also could be easily integrated by third-party services (e.g. https://oauth.io/). A comparison of these libraries is presented in Table 4-2.

Table 4-2: OSN monitoring libraries comparison

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

   

Facebook4J

 

Twitter4J

Spring Social [53]

[55]

RestFB [56]

[57]

   

Yes, only

Yes, custom

 

Flexibility

Yes

custom FQL

FQL, custom

Yes

supported

open graph

Open Source

Yes

Yes

Yes

Yes

API

 

Yes (no open graph)

   

Completeness

Yes

Yes

Yes

Common OSN

       

Data Model

No

No

No

No

OSN

       

Authentication

Yes

Yes

No

Yes

OSN Support

Facebook, Twitter, LinkedIn, (Incubation: TripIt, GitHub), (many community implementa- tions of other OSN providers)

Facebook

Facebook

Twitter

However, there are general issues with social monitoring as discussed in the next paragraph. Those issues include resources limitations and development issues. While the development issues can be solved with careful planning, the rate limitation cannot be circumvented. Thus, the social monitor and analyzer components need to be developed with those rate limitations in mind.

4.3.1.2 Social Monitoring Issues

Rate Limitations: OSNs limit the rate on which a user can access their API endpoints. For example, Facebook limits the API to 600 calls per 10 minutes per access token. This becomes critical when fetching a lot of data (e.g. retrieve all friends (600+) of a Facebook user, search tweets based on a hashtag). Developers should consider these limitations and work with timers and counters to avoid the temporal or even final bans of an access token.

Testing: It is not an easy task to test the implemented functionality since most OSNs do not allow the creation of test users. Therefore, developers have to work with real user profiles. It is important to mention that the code should be reviewed precisely before testing, since different user profiles may present slightly different characteristics due to the OSN continuous development (e.g., new features just available to a portion of users).

API Reliability: OSN API’s are not perfect, many bugs exist (such as [57]) and also response times are not guaranteed. One has to deal with this uncertainty and take into account whilst developing.

OSN Authentication: The most difficult part is the handling of the OSN authentication. Some of the OSNs implement oAuth 1.0 (e.g. Twitter) others oAuth 2.0 (e.g. Facebook), and also proprietary solutions are used. It is preferred to use a third-party service such as oauth.io, which already solved this problem and is easy to integrate with minimum effort.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

If the library should support as many OSNs as possible, then Spring Social should be chosen. If the focus lies only on Facebook and Twitter, then it is recommended to work with RestFB and Twitter4J, which have proven – by the open-source community – to be well maintained and stable. Moreover, RestFB and Twitter4J are easy to use and they support almost the complete underlying OSN API.

4.3.2 Cloud Manager

CloudStack [61] and OpenStack [62] provide an open source implementation of a fully featured cloud software stack. Although both come with deployment features, as discussed in Section 4.3.2.3, CloudStack is more stable and easier to deploy, but OpenStack is more scalable. Since OpenStack was initiated by Rackspace and NASA and is actively supported, deployed and developed by many other big stakeholders in the field, such as SUSE Linux, Dell, Canonical, Citrix Systems, Hewlett-Packard, AMD, Intel, Red Hat, and IBM, OpenStack's deployment and code quality rapidly increases.

Furthermore, as Section 4.3.2.4 discuses, CloudStack offers mechanisms that may ease the deployment of the Cloud Manager in the case of cloud federation, which is a major focal point of SmartenIT. Since SmartenIT aims to provide cloud mechanisms for fair resource allocation, it is also highly important, that the chosen cloud software stack comes with appropriate resource monitoring functions. Here OpenStack clearly outpaces CloudStack, as discussed in Section 4.3.2.1. While CloudStack may outpace OpenStack with respect to the ability of resource reallocation, these capabilities are constraint to certain hypervisors, as discussed in Section 4.3.2.2. Further, if reallocations are implemented on the hypervisor level, also OpenStack is highly capable.

4.3.2.1 Specific APIs for Resource Monitoring

To decide on resource allocation, an allocation mechanism needs information about the current (and possibly past) resource utilization of VMs. OpenStack provides this information via the Ceilometer component which is addressable through an API and highly customizable.

CloudStack provides basic usage information through its dashboard. Further, the optional component "cloudstack-usage" provides different access methods including an API, to infer utilization data. However, this data is accessible only at user account level, which means that, contrary to OpenStack, it is not possible to get necessary usage information at VM level.

4.3.2.2 Reallocation

CloudStack provides advanced capabilities to reassign resources to VMs by an API, which allows reallocations even for running VMs. Although CloudStack has an edge over OpenStack, the functionality is only accessible in combination with the VMware or XenServer hypervisor.

While OpenStack does not provide such fine grained resource reallocation features natively, they can be implemented for many open source hypervisors. This means, although CloudStack outruns OpenStack in terms of out-of-the-box resource reallocation features, it is possible to implement the same functionality for OpenStack. Although OpenStack’s reallocation capabilities have therefore be implemented for hypervisors

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

specifically, CloudStack also only supports the functionality for two hypervisors out of the box.

A way to implement resource reallocations in OpenStack, independent of the hypervisor, would be by VM resizing. In particular, OpenStack provides VMs with predefined resource sets, which are called flavors. Resources could therefore be reallocated by creating customized flavors and resizing VMs to these as needed. The creation of flavors and subsequent migration of a VM to the new flavor is handled by the component Nova and is also addressable through an API. However, it requires restarting VMs and is therefore not very flexible. Thus, although the resizing approach would virtually support every hypervisor, it is planned to implement the reallocation functionality on hypervisor level.

4.3.2.3 DevStack; Pro / Cons

As mentioned, CloudStack outpaces OpenStack in terms of deployment ease. To address this issue, the community created the DevStack [63] distribution of OpenStack. It is a quick and (as described by the creators themselves) dirty way of deploying OpenStack. The only goal is to setup OpenStack as quick as possible, hence all components are initialized with default values and security is of no concern. Therefore, it is highly discouraged to use OpenStack installed by DevStack as production environment. However, DevStack will serve for initial deployment/test purposes well and mitigate the deployment efforts compared to CloudStack.

4.3.2.4 Deployment

There are four available mechanisms to logically group an OpenStack deployment:

Regions, Cells, Availability Zones and Host Aggregates.

The first two mechanisms are used to control multiple cloud sites i.e. datacenters. Cells rely on a hierarchical tree-like structure with only one master node to organize datacenters. If datacenters are organized as Regions, each datacenter has its own master node and its own API which allows better separation. The mechanisms may in particular become relevant, when cloud federations are considered: as organizing datacenters by regions allows for more heterogeneous cloud federations.

The other two mechanisms serve to organize a single master node and its corresponding set of cloud services. Availability Zones allocate compute and storage nodes to logical groups and allow for some form of physical isolation and redundancy when scheduling VMs. Host Aggregates introduce the possibility of attaching additional meta-data (e.g. "SSD_disks" or "Intel_AVX") to nodes such that they can be grouped to further ease scheduling decisions.

The most favourable architecture for a multi-datacenter deployment would be based on Regions to manage the different sites and Availability Zones to group nodes within Regions as shown in Figure 5.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

in Confidence Seventh Framework STREP No. 317846 Figure 5: Multi-datacenter deployment architecture [62]

Figure 5: Multi-datacenter deployment architecture [62]

4.3.2.5 Cloud Manager Decision

As community support is a good indicator for future-proofness of software and OpenStack obviously boasts this characteristic, OpenStack will be deployed by SmartenIT as it clearly rules out CloudStack in terms of active contributors and enterprise support. Since KVM is OpenStack's standard hypervisor and offers a lot of monitoring functionalities, and is widely deployed, it will be deployed as the hypervisor. Table 4-3 lists the feature highlights of the two alternatives sorted by relevance.

Table 4-3: Feature highlights of the two overlay manager alternatives

OpenStack

CloudStack

Support by many big companies

Stability

Rapidly growing deployment

Ease of deployment

Ceilometer

 

4.3.3 QoS monitor

Depending on the network size and topology, network equipment and other aspects like implemented Traffic Management Solution (TMS) specific requirements, network monitoring information may be collected in different ways and from several types of sources. Those may be roughly categorized in three sets: network devices, basic network performance monitoring tools and more sophisticated and/or complex monitoring systems.

Typically network devices can be directly queried by means of SNMP [38] in order to obtain information stored in MIBs. However in order to obtain any other specific monitoring data form a device any of the implemented management protocols can be used to connect to the device. Those would include among others: SSH [83], TL1 [84] and NETCONF [37].

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Selected measurement tools and monitoring systems that could be potentially used in the SmartenIT prototype development are presented in the following sections. In the last paragraph of Section 4.3.3.4 we present the final selection of tools and the reasoning behind it.

4.3.3.1 Basic system monitoring tools

The utilization of entities in the SmartenIT architecture is required for the optimization of service and content placement decisions. Therefore, a number of utilities and libraries exist, simplifying the task of gathering the utilization of the different devices and device types in a unified and platform independent way. These metrics are required for the model based power estimation of participating devices, reducing the overall power consumption

to a minimum. The tools considered for deployment are listed in the following table.

Table 4-4: System utilization measurement tools

Tool name

Available Metrics

Language

Platform

Deployment

SIGAR [64]

System utilization (CPU, RAM, HDD, network, …)

Java

Multi-platform

uNaDa or hosts

psutil [65]

System utilization (CPU, RAM, HDD, network, …)

Python

Multi-platform

uNaDa or hosts

As the selected language is Java, the preferred system monitoring library is SIGAR.

4.3.3.2 Basic network measurement tools

A set of basic network monitoring tools covers most or even all network metrics that are

foreseen to be potentially collected and utilized by the implemented TMS. These include packet delays, loss, data throughput, device/interface availability and others. The list of selected example tools and their basic characteristics is provided in the following table. The SmartenIT software would need to be able to interface with these tools to trigger measurements and collect results. The way this would be done depends on the selected tool(s) to be used and where given tool is deployed.

Table 4-5: Network measurement tools

Tool name

Available metrics

Deployment

Ping

connectivity, packet loss, round-trip time

On network devices or hosts

Traceroute

path, round-trip time

On network devices or hosts

Iperf [26]

throughput, packet loss (UDP), and jitter

Client-server application on hosts

OWAMP

one way delay

Client-server application on hosts

[27]

4.3.3.3 Measurement tools for network and traffic analysis

Permanent measurements give information about network and application activity and allow searching for trends in traffic volumes sent and level of applications’ usage. Monitoring data is important for network administrators, since it can be used for anomaly

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

detection and user misbehavior. Moreover raw data is necessary for validation of theoretical models and when searching for new modeling methods. Section 5 of Deliverable 1.2 [31] provides some insight into traffic measurement and analysis mechanisms and tools. Short descriptions of those tools are provided in the following table complemented with additional information on sFlow network monitoring technology.

List of measurement tools suitable for data extraction in the context of traffic analysis is provided in Table 4-6.

Table 4-6: Network and traffic analysis measurement tools

Tool name

Available network performance metrics

Purpose / usage

D-ITG Tool

throughput,

delay,

jitter,

packet

traffic generator that uses stochastic models (for packet size and inter departure time) to imitate real application behavior with built-in measurement tool that can produce accurate IPv4 and IPv6 applications’ workloads

[66]

loss

Tstat Tool [67]

 

-

automatically correlates incoming and outgoing packets combining them into flows using both standard traffic measurement indices and more sophisticated methods at L2-L7 layers level to provide traffic evaluation

CoralReef Tool

 

-

open source network analyzer

[68]

 

BLINC [85]

 

-

novel traffic classification approach operating at three levels of the host behavior – social, functional and application

PERFAS

delay,

latency

variation,

packet

performs active measurements on IP level, installed on Deutsche Telekom’s IP backbone

loss

MIB/SNMP

highly aggregated – counter of packets and bytes transmitted and lost at interfaces

provide coarse grained statistics from network equipment

Standards [38]

NetFlow [81]

 

-

protocol dedicated to IP traffic information collection and analysis which enables network traffic accounting, usage-based network billing, network planning, security, Denial of Service monitoring capabilities, and network monitoring

sFlow [28]

 

-

multi-vendor sampling technology embedded within switches and routers; provides the ability to continuously monitor application level traffic flows at wire speed on all interfaces simultaneously; the sFlow Agent runs as part of the network management software within a device, it combines interface counters and flow samples into sFlow datagrams that are sent across the network to an sFlow Collector

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

4.3.3.4 External monitoring data sources and monitoring systems

Apart from directly interfacing with the monitoring tools it is also possible to interact with monitoring systems or collect data from other sources, e.g. monitoring information databases. Those databases, e.g. maintained by NOCs, can be for instance organized as Round Robin Database (RRD) files for which special tools are used to store and retrieve data [29].

Interacting with a deployed monitoring system would be particularly suitable when running complex measurements in large and heterogeneous networks. It is possible to interface with network management systems or monitoring middleware software that orchestrates a number of underlying monitoring tools to run complex monitoring tasks. An example of such a middleware is perfSONAR [30].

PERFormance Service-Oriented Network monitoring ARchitecture (perfSONAR) [30] is an infrastructure for network performance monitoring. It consists of a set of services delivering performance measurements in a federated environment. These services act as an intermediate layer, between the performance measurement tools and the diagnostic or visualization applications. perfSONAR is a joint collaboration between several partners including GÉANT European project participants [88].

perfSONAR is a service-oriented architecture in which all services communicate with each other using well-defined protocols. Figure 6 presents this architecture logically divided into three layers. The lowest layer of the architecture contains measurement points – individual tools that take passive and active measurements of the network. The service layer is made up of services that bind communication and management activities between the measurement points and the user-focused tools.

between the measurement points and the user-focused tools. Figure 6: perfSONAR Architecture [30] Many perfSONAR

Figure 6: perfSONAR Architecture [30]

Many perfSONAR services and monitoring applications have already been implemented as standalone measurement tools [86], e.g. BWCTL [87] Measurement Point and OWAMP Measurement Point.

Monitoring tool selection Before the implementation of the DTM mechanism two basic measurement tools were considered as main approaches for implementation in DTM monitoring modules: SNMP

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

[38] and NetFlow [81]. Below a short description of both protocols with explanation of motivation for such choice is presented.

NetFlow offers per flow counters and reports without possibility to receive those reports on-demand. NetFlow exporter sends flow statistics only when one of two counters will trigger it: flow-active-timeout or flow-inactive-timeout. As presented in Figure 7 flow-active- timeout is set as an example to 15s and flow-inactive-timeout to 20s. Time when collector will receive flows’ statistics depends only on arrival of the first and last packet of particular flow. If the flow is longer than flow-active-timeout the exporter sends statistics after 15s, otherwise (i.e. if the flow is shorter than flow-active-timeout or period of time from last export) flow-inactive-timeout triggers sending procedure.

Flow X

15 s

triggers sending procedure. Flow X 15 s 20 s 15 s 15 s 20 s Flow
triggers sending procedure. Flow X 15 s 20 s 15 s 15 s 20 s Flow
20 s
20 s
15 s 15 s 20 s Flow Y 20 s Flow Z Reports received Reports
15 s
15 s
20 s
Flow Y
20 s
Flow Z
Reports received
Reports needed in DTM
t
ττττ
τ+10τ+10τ+10τ+10
τ+20τ+20τ+20τ+20
τ+30τ+30τ+30τ+30
τ+40τ+40τ+40τ+40
τ+50τ+50τ+50τ+50

Figure 7: NetFlow exporting process.

SNMP-based traffic measurements provide only information about interface/queue statistics, i.e., number of transmitted/received packets or bytes. Reports can be synchronized (send as a response for polling). Figure 8 presents example process of receiving SNMP-based statistics from network equipment as a replay for polling by SNMP agent. In addition, SNMP implementation is less complex and supported by almost any network device.

30 s 30 s Flow X Flow Y Flow Z Reports needed in DTM t
30 s
30 s
Flow X
Flow Y
Flow Z
Reports needed in DTM
t
ττττ
τ+10τ+10τ+10τ+10
τ+20τ+20τ+20τ+20
τ+30τ+30τ+30τ+30
τ+40τ+40τ+40τ+40
τ+50τ+50τ+50τ+50

Figure 8: SNMP-based measurement.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

The SmartenIT consortium aimed to select a measurement tool for network traffic that addresses DTM specification requirements and is also lightweight. Taking into account previously mentioned features of measurement tools, SNMP was selected.

4.3.4 QoE monitor

The QoE monitor can be anywhere in the network but more accurate results can be obtained if it is located close to the video player in order to experience network performance similar to those of the player. At best, QoE monitor should be on the video player host itself.

Some open source libraries (e.g. IQA [71], VQMT [72]) are available but are only able to provide results of full-reference quality assessment (i.e. similar to a “diff” between source and received video), while it is important to support the “no-reference quality assessment” case: the receiver evaluates the quality of what it receives without knowledge of the original video file, as in many cases (i.e. use of Youtube), the original video file is not known.

VitALU [73], a proprietary tool developed by ALBLF, is able to provide an estimation of the Mean Opinion Score (MOS) value (a score estimated subjectively by human viewers) without need for the reference video.

Table 4-7 presents the metrics that should be supported by the QoE monitor.

Table 4-7: Metrics for QoE monitoring tool

Category

Metric Name

 

Transport Protocol (HTTP Live, RTSP, RTP Multicast, Flash HTTP)

Number of Packets, Packets Retransmitted (%)

IP traffic metrics

Lost/Disordered Packets (for UDP flows)

Network jitter

Average Bitrate

 

Video frame resolution (pixel)

Frame rate (Average and Std) (frame per second)

Video access time (s)

Video duration (s)

Video bit rate (bps)

Video metrics

Time distribution for each frame resolution / video bitrate (adaptive streaming)

Number of freezes (video interruption)

Freeze duration (Average and Max) (s)

Number of erroneous frames

Late and erroneous frame ratio (%)

Compression Video Quality Score (Avg and Std) from 1 (very bad

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

 

quality) to 5 (very good quality)

Networked Video Quality Score (Avg and Std) from 1 (very bad quality) to 5 (very good quality)

 

Audio bitrate (bps)

Audio metrics

Audio duration (s)

MOS (E-model)

The VITALU software supports all these metrics. It is implemented in C# and is targeted

for fixed clients (e.g. PC, server). A Windows executable (binary to be used with license by Alcatel-Lucent 1 ) can be provided along with open source DLLs (FFMPEG [74], Wireshark

[75], etc

supported.

As it was developed by the consortium partner ALBLF, VitALU is selected to be used as the QoE analyzing library in any traffic management mechanism, as it should be fairly easy to make simple adaptations in order to be interfaced with SmartenIT entities or to add new specific metrics. While the software itself cannot be released as open-source, it relies on several other open source libraries. This software is intended to be simple of use:

all that is needed is the type of flow to analyze and understanding the resulting metrics. Of course as being the originator of this software, ALBLF has a strong expertise on this product.

In order to integrate VitALU into the java framework, the executable could be launched by a Java application, or a wrapper could be provided. In case a mobile client is targeted, it is possible to mimic VitALU measurements on a mobile by running it on a portable PC connected with a 3G key. Another option is to perform an offline analysis by capturing the packets, together with radio-related (e.g. base id, signal strength) and location (GPS) information, on the mobile during the video rendering and later, send the file containing the captured network data (in the standard PCAP format) corresponding to the monitored flow to the VitALU server, e.g. via Wi-Fi.

).

A version for the Linux operating systems exists but not all functionalities are

4.3.5 Fixed/Mobile Network Traffic Manager

In general, the Fixed/Mobile Network Traffic Manager takes decisions related to traffic management, e.g. connectivity set up between two network endpoints that should be materialized at the network layer by the Switching/Forwarding component. So far two so called Network Configuration Frameworks were considered in the project namely OpenFlow-based Software Defined Networking (OpenFlow-based SDN) and Multi-protocol Label Switching with Traffic Engineering capabilities (MPLS-TE). Those frameworks have been already described in Sections 5.2 and 5.3 of Deliverable D2.2 [1], respectively. Those descriptions contain basic technical information about related technologies and mechanisms, brief explanation of their potential application to TMSs developed within the project and a summary of conducted initial functional validation tests. Each of those frameworks provides different capabilities which may be particularly suitable for different TMSs.

1 ALBLF is a subsidiary company of Alcatel-Lucent

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

In the following sections the above mentioned frameworks are described focusing on their technological aspects and their possible impact on the architecture and software prototype. Please note that the network configuration framework has major impact on the Network Traffic Manager and Switching/Forwarding components as well as the interface to be used between them. We assume that the Switching/Forwarding component resides in the network device thus the devices (either physical or virtual) must support the technologies implied by the selected network configuration framework. This has a direct impact on the testbed design done in the scope of Work Package 4.

4.3.5.1 OpenFlow-based SDN

OpenFlow Switch specification [32] covers the components and basic functions of the switch as well as the OpenFlow protocol to manage the switch from a remote controller. Multiple OpenFlow Switch specification versions exist: from version 1.0.0 up to the latest version 1.4.0 released in October 2013. Each new version of the specification introduces new features and capabilities. Nevertheless not all versions of OpenFlow are widely implemented and supported by both virtual and physical network devices as well as available software SDN controllers. What might be relevant from the project perspective is that OpenFlow since version 1.1 supports basic operations related to MPLS.

OpenFlow is supported by a variety of physical network equipment vendors but also by virtual switch implementations like Open vSwitch [33] which has been used during the tests documented in D2.2 [1]. Mininet framework [34] was used for the creation of the entire virtual network and may be found useful in the future work especially during prototype validation.

Multiple SDN controllers supporting different OpenFlow versions exist. Both the Controller and the underlying network devices will need to support the agreed version of OpenFlow. Next, two of the available open SDN controllers are briefly described.

Floodlight

Floodlight [35] is an enterprise-class, Apache-licensed, Java-based OpenFlow Controller. It is supported by a community of developers including a number of engineers from Big Switch Networks. Floodlight is not just a plain OpenFlow controller. It realizes a set of common functionalities to control and inquire an OpenFlow network, while applications on top of it realize different features to solve different user needs over the network. Figure 9 shows the relationship among the Floodlight Controller, the applications built as Java modules compiled with Floodlight, and the applications built over the Floodlight REST API.

The REST API is the recommended interface to develop applications utilizing Floodlight supported features but it is also possible to add functionalities/applications inside the controller software itself.

Floodlight controller supports OpenFlow version 1.0 only. The latest version of the software has been released in October 2012.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

in Confidence Seventh Framework STREP No. 317846 Figure 9: Floodlight controller components diagram [35] The

Figure 9: Floodlight controller components diagram [35]

The advantages of using a Floodlight controller are: maturity and wide adoption of the software, complete and easily accessed documentation of the REST API and clearly documented guidelines for implementing controller extensions. On the other hand, it only supports OpenFlow version 1.0, what may not be sufficient from the implemented TMS point of view.

OpenDaylight

OpenDaylight [36] is an open source project with a modular, pluggable, and flexible SDN controller platform at its core. OpenDaylight project is supported by many big companies including leading network equipment vendors like Brocade, Cisco and Juniper. The controller exposes open northbound APIs which are used by applications. Those APIs support communication over the OSGi framework and bidirectional REST. The business logic and algorithms reside in the applications. These applications use the controller to gather network intelligence, run algorithms to perform analytics, and then use the controller to orchestrate the new rules, if any, throughout the network.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Framework, and Initial Prototype Commercial in Confidence Figure 10: OpenDaylight (Hydrogen) components diagram [36]

Figure 10: OpenDaylight (Hydrogen) components diagram [36]

The controller platform itself contains a collection of dynamically pluggable modules to perform needed network tasks. In addition, platform oriented services and other extensions can also be inserted into the controller platform for enhanced SDN functionality.

The southbound interface is capable of supporting multiple protocols (as separate plug- ins), e.g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS [82], etc. These modules are dynamically linked into a Service Abstraction Layer (SAL). The SAL exposes device services to which the modules north of it are written. The SAL determines how to fulfill the requested service irrespective of the underlying protocol used between the controller and the network devices.

The version 1.0 of the OpenDaylight controller software, named Hydrogen, was released in February 2014. Three editions of the software were released, namely Base, Virtualization and Service Provider. Hydrogen Base Edition is mainly meant for exploring SDN and OpenFlow for proof-of-concepts or academic initiatives in physical or virtual environments.

The main advantages of OpenDaylight controller are: support for OpenFlow 1.3, novel and easily extensible modular architecture, its constantly rising popularity and wide support provided by all major players from the network equipment vendors and network services community. Its major downsides are on the other hand related to the very recent release of the software which may still contain unidentified bugs and issues as well as the lack of well-organized and complete documentation.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

4.3.5.2 MPLS-TE Multi-Protocol Label Switching [25] is a well-known standard and commonly used technology in ISP networks. At its core, MPLS enables creation of virtual end-to-end tunnels called Label Switch Paths (LSP). Over the years, MPLS has been enhanced with additional features including the Traffic Engineering extensions that enable efficient and reliable network operations while simultaneously optimizing network resources utilization. Moreover, multiple connectivity applications have been defined that leverage MPLS as the underlying technology, e.g., VPLS, BGP/MPLS VPN, that enable setting up different type of connectivity services on top of the existing LSPs tailored for particular communication requirements.

MPLS-TE [76] is suitable for any TMS that uses traffic differentiation, sets up dedicated paths in the network, monitors the load on paths or makes QoS guarantees. LSPs might be set up on-demand on per data transfer basis in the case when the delivery paths need to be established for a considerably long time period. It is also possible to establish a mesh of LSPs and provide periodical LSPs re-configuration what may be employed by TMSs focused on load balancing and overall cost minimization.

In order to perform MPLS related configuration, software needs to communicate with network devices using any of the available management protocols, e.g. NETCONF [37], SNMP [38] or other.

Eventually, based on selected TMS requirements, network configuration by means of OpenFlow-based SDN is being implemented. Taking into consideration the description of both SDN controllers provided in section 4.3.5.1, the fact that OpenFlow 1.0 version is sufficient, the importance of having clear and complete documentation and previous experience of the development team, the Floodlight controller was selected by the consortium as the SDN controller to be used as part of the SmartenIT prototype.

4.4 Internal interfaces protocol formats

The following sections describe the advantages and disadvantages of the 3 alternatives for the protocol serialization and formatting that could be used in the internal SmartenIT interfaces: the interfaces between the SmartenIT entities. In the end of the section, the final selection is presented.

4.4.1 Google Protocol Buffers

Google Protocol Buffers [39] is a cross-language, cross-platform mechanism for serializing structured data, ideal for communication protocol and data storage design and development. Developers define the structure format in a text .proto file in a human- readable fashion, which can then be compiled to most well-known and popular programming languages, such as Java, C++, Python, and Ruby, generating the source code to be integrated into the software project. The advantages of using the Google Protocol buffers are (a) the simple and human-readable format definition, (b) the binary format of the encoded messages, thus the small footprint when exchanged in a communication channel, (c) the short time required for parsing and (d) the ease of using the generated classes. On the other hand, the non-human readable format of the exchanged messages could be considered as a disadvantage by certain developers.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

4.4.2 Apache CXF Distributed OSGi

Apache CXF Distributed OSGi (DOSGi) [11] implements the OSGi Remote Service [8] functionality using Web Services (since DOSGi release version 1.1 both SOAP and RESTful services are supported). The core OSGi specification allows OSGi services to be visible and accessible inside the OSGi container. The OSGi Remote Service specification and consequently DOSGi extends this functionality and allows defining services inside one container and using them in another one even if they are deployed on different physical machines.

In the case of SmartenIT, DOSGi can be used for communication between entities in two ways. If both entities are OSGi containers, the communication can be done as described above, so for example one S-Box instance (Section 3) can get and use remote service from another S-Box instance deployed on a different server. The other case would be to use DOSGi only for creating and exposing Web Services (in cases where one of the communicating entities is not an OSGi container).

The usage of DOSGi would be a natural choice, if OSGi-based framework would be selected. It seamlessly integrates with OSGi/Karaf mechanisms and makes use of its advanced features. If OSGi-based framework isn’t selected, other more lightweight and underlying framework independent approaches should be considered instead.

4.4.3 JSON

JSON [80], derived from JavaScript, is an open, text-based, cross-language, cross- platform, human-readable data serialization format, ideal for network and web applications. The existence of multiple libraries and tools for generating and parsing JSON data in all programming languages, as well as its small footprint and human-readable nature, have made JSON one of the most widely used data serialization formats.

The SmartenIT consortium aimed to select a data serialization format that would be lightweight and used in all internal interfaces between SmartenIT entities to ensure the homogeneity of the prototype. Taking into account that ALTO protocol also uses JSON for its data exchange format, JSON was selected.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

5 Implementation Framework

The implementation framework of the SmartenIT project includes all required tools to design, develop, test and deploy the created software, and the necessary methods and support platforms to organize and support the implementation process. These tools are used by the SmartenIT implementation team to implement their respective components, as well as by prototype integrators to produce a coherent, integrated system. This ensures to some extent that developers and integrators use a common development, building, and testing environment. Note that although testing is a core part of the implementation process, the functional testing of the prototype falls under the WP4 tasks. Hence, in this chapter we will briefly describe the testbed as part of the implementation framework. More details on the design and set-up of the software validation testbed will be provided in the upcoming Deliverable D4.1 (due to M24).

5.1

Tools

The implementation framework tools consist of a specification language for designing the SmartenIT system, programming languages used to develop components, the libraries used to support the software development, the tool chain for compiling and building the source code, the version control platform for archiving source code, the issue tracking system for organizing and planning the implementation work, as well as tracking and resolving found bugs and issues, the continuous integration server for automatically building system’s components and the validation testbed created to validate each release’s features and functionalities.

5.1.1 Specification Language

The SmartenIT system is designed and modeled using UML specification language. The consortium also agreed to use the Microsoft Visio [40] software, in order to achieve homogeneity in created diagrams and figures. UML has been applied to component, entity, class, sequence and deployment diagrams presented in previous, and the current deliverable.

5.1.2 Programming Languages

The selected programming languages for the SmartenIT entities are presented in Table 5-1, and reflect the decision of Section 4.1.

Table 5-1: Entities’ programming languages

Entity

Programming

Development Kit

Language(s)

SBox

Java

Oracle JDK 1.7.0_51 [3]

SDN Controller

Java

Oracle JDK 1.7.0_51 [3]

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

5.1.3 Libraries

Each component’s external dependencies are presented in Table 5-2. Most of these libraries reflect the decisions of sections 4.1, 4.2 (JBoss Netty libraries), 4.3.3 (SNMP library), 4.3.5 (Floodlight SDN Controller dependencies), and 4.4 (Jackson libraries for JSON support). The rest of libraries are used to support certain features of the first SmartenIT release.

Table 5-2: Components’ libraries

Entity

Component/Module

Libraries

   

sqlite-jdbc-3.7.2

Database

jdbi 2.53

jackson-annotations 2.3.3

Interfaces

netty 4.0.18.Final

(Inter-SBox and SBox- SDN)

jackson-databind 2.2.3

wiremock 1.46

 

javax.servlet 3.0

SBox

User Interface

jsf-api, jsf-impl 2.2.6

QoS Analyzer

snmp4j 2.2.5

Economic Analyzer

commons-math3 3.0

 

slf4j 1.7.7

logback 1.1.2

Commons

commons-configuration 1.10

commons-logging 1.1.3

   

org.restlet, org.restlet.ext.jackson, org.restlet.ext.simple, org.restlet.ext.slf4j 2.1-RC1

org.simpleframework 4.1.21

netty 3.2.6.Final

args4j 2.0.16

Floodlight

concurrentlinkedhashmap-lru 1.2

SDN

jython-standalone 2.5.2

Controller

 

libthrift 0.7.0

easymock 3.1

jsonassert 1.2.3

logback 1.0.0

slf4j 1.6.4

 

jackson-databind 2.2.3

Interfaces

jsonassert 1.2.3

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

5.1.4 Tool chain

Apache Maven [19] is used as the dependency management and build automation tool for the SmartenIT prototype. Maven is actually a software project management tool, which provides an expandable set of tools so that developers may define the build lifecycle, phases and goals, the project’s dependencies, build plug-ins that insert additional goals in build phases and build profiles which may build the project in different ways.

Specifically, version 3.1.1 of Apache Maven is used for the building of the SmartenIT project, including the following list of plug-ins to execute additional required functions:

maven-surefire-report-plugin (version 2.17), used to aggregate all JUnit test results and present them in HTML format,

maven-javadoc-plugin (version 2.9), used to generate the Java API documentation,

cobertura-maven-plugin (version 2.6), used to generate and aggregate the Cobertura coverage results,

maven-project-info-reports-plugin (version 2.1.2), used to include general project information,

maven-site-plugin (version 3.3), which aggregates all the aforementioned reports into a single project Maven website,

keytool-maven-plugin

(version 1.3), used to generate a SmartenIT security

certificate,

jetty-maven-plugin (version 9.1.1.v20140108), used to run and deploy the web applications of the SmartenIT prototype into a Jetty web server,

maven-compiler-plugin, used to compile the source of the project,

maven-assembly-plugin (version 2.4), used to create a single executable for each entity and finally package and generate the SmartenIT software release artifact,

android-maven-plugin (version 3.8.0), used to run and test the Android application of the end-user entity.

The project’s system tree, dependencies and build/execution commands are presented in Section 5.3.

5.1.5 Testbed

The testbed provides an environment for verification and experimentation, its basic topology is depicted in Figure 11. The main technology used in the testbed is Linux; in particular, the Ubuntu 14.04 distribution [4] is used. For managing virtual OS instances, libvirt is used for KVM and the LXC tools for LXC.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

PC 1 Network Connections Datacenter 1 Switch 1 PC 2 PC 3 Datacenter 2 Datacenter
PC 1
Network Connections
Datacenter 1
Switch 1
PC 2
PC 3
Datacenter 2
Datacenter 3
uNaDa 3
uNaDa 2
Switch 2
Switch 3
C
Access Point 2
Access Point 3
Home Clients
Mobile Clients

Figure 11 : The basic testbed topology

Other operating systems different than Linux could be used, however, the prevalence of Linux in research and industry makes it well suited for the task. Furthermore, the wide range of virtualization options and its high performance are unparalleled. A number of *NIX operating systems are free and open source as well. However, they lack performance, software support and virtualization options.

L2 and OpenFlow switching is provided by Open vSwitch; L3 routing by Linux features. Furthermore, standard network technologies are used, such as DNS, DHCP as well as routing protocols such as BGP. Open vSwitch supports both L2 switch and OpenFlow based forwarding. It is free and open source, while no other available software offers the same level of features and this performance.

More details on the basic testbed’s design and configuration will be provided in the upcoming Deliverable D4.1 (due to M24).

5.1.6 Version Control

Apache Subversion [77] is used as the version control system of SmartenIT. It will be used to store and maintain current and previous versions of the source code. Developers can copy and modify files or folders in the code repository and still maintain full revision history. Each change is identified by a revision identifier.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

Developers will get access to the SmartenIT repository by the SVN administrator and can extract, update and commit their code to the SmartenIT code repository using a client based on their operating system, e.g. TortoiseSVN for Windows, XCode for Mac OS and RapidSVN for Linux users.

The Subversion server is hosted and administrated by PSNC and can be accessed at https://svn.man.poznan.pl/svnroot/SmartenIT/.

5.1.7 Issue Tracking

Atlassian Jira [78] is a software implementation management and issue-tracking tool, used to organize and plan the work of developers and the integrator. Its main features that are used during SmartenIT development and integration are:

Software implementation management and planning: Roadmap of milestones and future versions of the software

Integration with the Subversion: Code changes and revision logs tracking

Ticketing: Bug and features tracking and management

Developers are provided access to JIRA by the JIRA administrator and can view their tickets, milestones and other information from their web browser.

The Atlassian Jira server is hosted and administrated by PSNC and can be accessed at https://jira.man.poznan.pl/en/.

5.1.8 Continuous Integration Server

Jenkins [79] is a continuous integration tool, used to automatically and frequently build our system. Its main features are:

Integration with the Subversion: All artifacts essential to build our system should be placed under code repository and system should be buildable upon every new code checkout.

Build automation: Source code compiling, binary code packaging, deployment and documentation generation can be automatically performed by calling single commands in existing build scripts.

Automated Unit tests whenever developers commit code to the repository.

E-mail Notification and feedback to responsible developers whenever last build fails or there are incompatible changes in code.

Continuous integration and testing statistics.

Developers will get access to Jenkins by the Jenkins administrator and can view the project’s build status, and other information from their web browser.

The Jenkins server is hosted and administrated by PSNC and can be accessed at https://maven.man.poznan.pl/jenkins/job/SmartenIT/.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

5.2

Procedures

A set of common software prototype development procedures was defined and agreed on by the involved partners in order to assure a smooth and efficient prototype development process and successful delivery of software in incremental releases.

This section includes information about the system release and development processes (both represented in form of cycles) implemented in the project. Project partners play specific roles in these processes. Specific types of meetings will be organized throughout the implementation process.

5.2.1 System Release Process

The SmartenIT system release process will follow the agile development model, divided into (approximately) 2 month release cycles. Each release cycle (Figure 12) would consist of:

Feature planning, where the consortium would identify and prioritize features and tasks for next release, and specify components’ mechanisms and interfaces in the specification document (this phase takes place in feature planning meeting);

Development of the required features by the responsible partners (assignment of components to partners and agreement on the implementation framework was done prior to initialization of implementation);

Integration of the developed components and basic sanity tests;

System validation, where the developed system is tested in the testbed for the required release features;

System release and preparation of system release report (current document D3.2 and upcoming Deliverable D3.4 update). In addition, a system release review meeting takes place to identify and discuss problems encountered during this release cycle.

and discuss problems encountered during this release cycle. Figure 12: System release cycle Version 0.8 Page
and discuss problems encountered during this release cycle. Figure 12: System release cycle Version 0.8 Page

Figure 12: System release cycle

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

5.2.2 Development Process

The concept of continuous integration will be adopted for the development process within SmartenIT, in which developers commit frequently (daily if possible) their code, aiming to prevent integration problems and identify issues rapidly. This process will be supported by automated tools, e.g. Jenkins continuous integration server, while developers are required to write unit tests, covering most parts of their code.

The implementation process (Figure 13) consists of 4 phases:

Developers write code and tests,

Perform unit tests locally,

If tests pass, then commit their code to the repository, and

In case the build fails they are notified to fix the issue, otherwise continue their development work.

they are notified to fix the issue, otherwise continue their development work. Figure 13: Development cycle
they are notified to fix the issue, otherwise continue their development work. Figure 13: Development cycle
they are notified to fix the issue, otherwise continue their development work. Figure 13: Development cycle
they are notified to fix the issue, otherwise continue their development work. Figure 13: Development cycle

Figure 13: Development cycle

5.2.3

Roles

A set of roles involved in the overall implementation process was decided that would support processes described above. Each role was assigned a list of responsibilities and responsible project partner. Those roles and related assignments are presented in Table

5-3.

Table 5-3: Defined roles in the implementation process

Role

Responsibilities

Responsible

Responsible

Partner

Person

Product

Sets the high-level requirements and features of each release.

ICOM

Spiros Spirou

Manager

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Tools

Manages and maintains implementation framework tools.

PSNC

Jakub Gutkowski

Administrator

(&ICOM)

Łukasz Łopatowski

Provides access to tools.

George Petropoulos

Release

Facilitates the system release process.

ICOM

George Petropoulos

Master

Contact point of the implementation team.

Implementatio

Consists of all the people, responsible for the design, development, integration, testing and deployment of the SmartenIT prototype.

UZH, TUD,

As appointed by each Partner.

n Team

AGH, ICOM,

ALBLF,

 

PSNC

5.2.4 Meetings

In each release cycle defined in Section 5.2.1, 3 types of meetings will take place:

Feature planning meeting

o Long meeting before each release cycle, where product manager, release master and implementation team decide release’s features, break them into smaller tasks, assign responsibilities and define the time plan.

Weekly meeting

o 15-minute meeting every week during each release cycle, organized by release master where developers report their progress and problems since last weekly meeting and state their plans for next week.

Release review meeting

o

Short meeting after each release cycle, where product manager, release master and implementation team review the release cycle, identify and resolve issues.

o

If possible, a prototype demonstration to product manager and the consortium could take place.

o

This meeting could be merged and co-located with feature planning meeting.

5.3 System tree layout

The SmartenIT source code is organized as a Maven [19] multi-module project. Each entity (sbox, sdn, unada, enduser, network, dist) is also a Maven multi-module project, which can be packaged as a single jar with the use of a certain maven plug-in (maven- assembly-plugin).

Each entity’s component (e.g. main, interfaces) is a Maven module, which may be divided into further maven modules or packages, based on component owner’s preferences. In the defined system tree, certain components were divided into sub-modules to isolate developers’ work, as well as avoid possible dependencies’ conflicts.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

Packages have the following structure: eu.smartenit.<parent module(s)>. <current module>.package1, e.g. eu.smartenit.sbox.db.dao

The complete SmartenIT system tree, which also includes currently unimplemented entities and components, is presented below. Parentheses define the type of packaging, indicating whether a module consists of other sub-modules (pom packaging), is packaged as a Java archive (jar), which aggregates all classes and configuration files into one single executable or a Web application archive (war) which compresses all classes, web pages, and resources into one executable which can be deployed to any web server.

smartenit (pom)

o

sbox (pom)

 
 

main (jar)

 

interfaces (pom)

 

inter-sbox (pom)

 

o

client (jar)

o

server (jar)

 

sbox-sdn (jar)

 

db (pom)

 

dao (jar)

dto (jar)

 

web (war)

 

alto (jar)

ctm (jar)

ntm (jar)

na (jar)

qoa (jar)

 

eca (jar)

commons (jar)

o

sdn (pom)

 
 

floodlight-0.90 (jar)

interfaces (pom)

 

sbox-sdn (jar)

o

unada (pom)

 

o

enduser (pom)

o

network (pom)

o

dist (pom)

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

The system can be built with the use of the following command at the smartenit base directory:

mvn clean install

The aforementioned command, cleans all previously generated artifacts, compiles, packages and installs all modules, as well as runs all test cases. To avoid executing all test cases, the user may execute the following command:

mvn clean install -DskipTests

Besides, the user may generate the maven site for the smartenit project with the following command:

mvn clean install site site:stage

Besides compiling and packaging all source code, the aforementioned command aggregates and presents in html format the project-related information, e.g. implementation team information (Figure 14), the Java API documentation (JavaDoc) (Figure 15), the complete test results, and the Cobertura [23] coverage reports (Figure

16).

and the Cobertura [23] coverage reports (Figure 16). Figure 14: SmartenIT implementation team Version 0.8 Page

Figure 14: SmartenIT implementation team

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

in Confidence Seventh Framework STREP No. 317846 Figure 15: SmartenIT JavaDoc API example Figure 16:

Figure 15: SmartenIT JavaDoc API example

STREP No. 317846 Figure 15: SmartenIT JavaDoc API example Figure 16: SmartenIT Cobertura coverage results for

Figure 16: SmartenIT Cobertura coverage results for SBox entity

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

All the aforementioned commands also generate the SmartenIT software release artifact, which is the smartenit-${project.version}.zip, created at the dist/target directory.

For the first release, which implements the DTM mechanism, the zip file includes the following executables and configuration files:

main.jar: The main executable of the SBox application, which initializes all modules, and executes the DTM mechanism.

sbox.properties: It includes all the required SBox configuration parameters.

logback.xml: It defines the logging level of the SBox application.

web.war: It’s the war file, deployed to the Jetty web server.

realm.properties, jetty.xml: Configuration files that override default Jetty configuration.

floodlight-0.90.jar: The executable of the Floodlight SDN controller, extended with SmartenIT functionality.

Assuming that all prerequisite software (JDK 1.7.0_51 and Jetty 9.1.1) is installed, the release artifact may be installed to execute the DTM functionalities.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

6 Entities

6.1

S-Box

The SBox entity is the coordinating entity of the DTM mechanism. SBox is responsible for retrieving and aggregating the SNMP measurements from the network entities, calculating the compensation and reference vectors, and finally, configuring the remote SDN Controller. It includes certain components that are required to store and access mechanism- and NSP-specific parameters (Database and User Interface), retrieve and aggregate the monitoring data from the network entities (QoS Analyzer), perform necessary calculations (Network Traffic Manager, Economic Analyzer) and also interact with remote SBoxes and the SDN Controller (Inter-SBox and SBox-SDN Controller Communication Services). Each component’s functionality, interfaces, design and finally unit tests are further described in the following sections.

6.1.1

Network Traffic Manager

6.1.1.1

Functionality

The main functionalities provided by the Network Traffic Manager (NTM) can be grouped into two sets. When NTM is running on SBox deployed in AS that receives data traffic generated by one or multiple inter-DC communications, NTM provides the following functionalities:

periodically receives information about link traffic vectors from QoS Analyzer calculated after each reporting period and about reference vectors calculated by Economic Analyzer after each accounting period;

calculates a new compensation vector after each link traffic or reference vector update;

sends the compensation vector (with the reference vector after accounting period) to remote SBox instances that are deployed in ASs from which the received data traffic originated.

When considering SBox located at the data traffic sender end of an inter-DC communication, the NTM is responsible for receiving compensation and reference vectors from the Inter-SBox Communication Service server and distributing them to the underlying SDN controllers (by means of SBox-SDN Client) that will distribute the outgoing traffic among all configured tunnels accordingly.

In a general case, the SBox and therefore the NTM supports both ends of inter-DC communication since DCs in a local AS will most likely both receive and send traffic from/to remote ASs at the same time.

6.1.1.2 Interfaces

Network Traffic Manager provides in total 4 methods to be called by other S-Box components. Two of them are implemented by DTMTrafficManager class:

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

public

throws

IllegalArgumentException: Method called by the QoS Analyzer to update information about link traffic vector calculated every reporting period.

void

updateXVector(XVector

xVector)

o

Input parameters:

xVector New link traffic vector

o

Thrown exceptions:

IllegalArgumentException when given xVector argument is invalid

public void updateRVector(RVector rVector) throws IllegalArgumentException: Method called by Economic Analyzer to update information about reference vector calculated every accounting period.

o

Input parameters:

rVector New reference vector

o

Thrown exceptions:

IllegalArgumentException when given rVector argument is invalid

The remaining two interface

DTMRemoteVectorsReceiver class and are called by Inter-SBox Communication

Service server component.

implemented by

methods

are

public

cVector) throws

IllegalArgumentException: Method called to update information about compensation vector calculated every reporting period in remote S-Box.

void

receive(CVector

o

Input parameters:

cVector Compensation vector calculated in remote SBox

o

Thrown exceptions:

IllegalArgumentException when given cVector argument is invalid

public void receive(CVector cVector, RVector rVector) throws IllegalArgumentException: Method called to update information about compensation and reference vectors calculated every reporting and accounting period, respectively in remote S-Box.

o

Input parameters:

 

cVector Compensation vector calculated in remote SBox

rVector Reference vector calculated in remote SBox

o

Thrown exceptions:

IllegalArgumentException when either of given vector arguments is invalid

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

6.1.1.3 Design The NTM component implementation consists of 20 classes. The main functionalities provided by the NTM as described in Section 6.1.1.1 fall into two areas related with reacting on incoming traffic volumes by providing compensation and reference vectors to remote SBoxes and outgoing traffic distribution by means of SDN based on received compensation and reference vectors. These functionalities are implemented by disjoint sets of classes depicted in Figure 18 and Figure 21, respectively.

In Figure 17 a top level view on the NTM design is presented with classes that are used by other components of the SBox:

NetworkTrafficManager: Main class of the Network Traffic Manager component. Represents an entry point for the NTM component common for all the implemented traffic management mechanisms. Manages the lifecycle of the major NTM internal objects that implement traffic management mechanisms interfaces and logic.

o

public void initialize(): Method that should be called in order to initialize the NTM component (e.g. read required data from data base) in default DTM mode.

o

public void initialize(NetworkTrafficManagerDTMMode mode): Method that should be called in order to initialize the component in provided NetworkTrafficManagerDTMMode mode.

o

public DTMTrafficManager getDtmTrafficManager(): Returns an instance of DTMTrafficManager class that should be used by QoS Analyzer and Economic Analyzer to provide updated vectors to DTM logic implemented as part of the Network Traffic Manager.

o

public DTMRemoteVectorsReceiver getDtmVectorsReceiver():

Returns an instance of DTMRemoteVectorsReceiver class that should be used by Inter-SBox Communication Service server to provide received remote vectors to DTM logic implemented as part of the Network Traffic Manager.

NetworkTrafficManagerDTMMode: Enumeration class that represents three DTM running modes:

o

TRAFFIC_SENDER: DTM instance is run on SBox that manages AS(s) that only sends traffic to remote ASs. In this case some of the modules do not need to be initialized.

o

TRAFFIC_RECEIVER: DTM instance is run on SBox that manages AS(s) that only receives traffic from remote ASs. In this case some of the modules do not need to be initialized.

o

TRAFFIC_SENDER_AND_RECEIVER: General case enabled by default.

DTMTrafficManager: Implements DTM external interface methods that are used by QoS Analyzer and Economic Analyzer to update information about link traffic and reference vectors calculated every reporting and accounting period, respectively.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

o

public void initialize(): Method that should be invoked during component initialization to load required data from the database and populate internal structures.

o

public void updateXVector(XVector xVector) throws IllegalArgumentException: DTM external interface method used to update information about link traffic vector calculated every reporting period. Traffic vector values are accumulated from the beginning of accounting period (reception of updated R vector). Triggers subsequent actions in a new thread.

o

public void updateRVector(RVector rVector) throws IllegalArgumentException: DTM external interface method used to update information about reference vector calculated every accounting period. Link traffic vector value for given AS is reset. Triggers subsequent actions in a new thread.

DTMRemoteVectorsReceiver: Implements DTM external interface methods that are used by Inter-SBox Communication Service server side component to update information about reference and compensation vectors calculated in remote SBoxes.

o

public void initialize(): Method that should be invoked during component initialization to load required data from the database, populate internal structures and initialize all SDN controllers.

o

public void receive(CVector cVector) throws IllegalArgumentException: DTM external interface method used to update information about compensation vector calculated every reporting period in remote SBox.

o

public void receive(CVector cVector, RVector rVector) throws IllegalArgumentException: DTM external interface method used to update information about compensation and reference vectors calculated every reporting and accounting period, respectively in remote SBox.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

in Confidence Seventh Framework STREP No. 317846 Figure 17: NTM partial class diagram: top level In

Figure 17: NTM partial class diagram: top level

In Figure 18, a partial NTM class diagram is presented with the following classes (DTMTrafficManager class was already described in the previous paragraph):

VectorProcessingThread: Base abstract class that implements the Runnable interface. Each vector processing procedure implemented by the subclasses of this base class is executed in separate thread of execution.

o public VectorProcessingThread(XVector xVector, RVector rVector, List<SBox> remoteSboxes): The constructor with three arguments: link traffic and reference vectors to be used during compensation vector calculation and a list of SBoxes which should be updated once the calculation is complete.

CVectorProcessingThread: Extends VectorProcessingThread class. Implements new compensation vector calculation after new link traffic vector is received followed by sending compensation vector to remote SBoxes. Those actions are performed in separate thread.

o public void run(): Method launched when thread is started. Calculates compensation vector with CVectorCalculator and sends it to remote SBoxes using instance DTMVectorsSender.

CRVectorProcessingThread: Extends VectorProcessingThread class. Implements new compensation vector calculation after new reference vector is received followed by sending both compensation and reference vectors to remote SBoxes.

o public void run(): Method launched when thread is started. Calculates compensation vector with CVectorCalculator and sends both vectors to remote SBoxes using instance of DTMVectorsSender.

CVectorCalculator: Implements compensation vector calculation logic.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

o public CVector calculateCompensationVector(XVector xVector, RVector rVector): Calculates compensation vector based on provided arguments: link traffic vector and reference vector.

DTMVectorsSender: Implements methods that forward requests for inter-SBox vector information update to the InterSBoxClient component.

o

public void send(SBox sbox, CVector cVector): Method calls proper method of the InterSBoxClient class instance in order to send information about updated compensation vector to given remote SBox.

o

public void send(SBox sbox, CVector cVector, RVector rVector): Method calls proper method of the InterSBoxClient class instance in order to send information about updated compensation and reference vectors to given remote SBox.

InterSBoxClientFactory: Static factory class used by DTMVectorsSender to obtain instances of InterSBoxClient class to be used for communication with remote SBoxes.

o public static InterSBoxClient getInstance(): Method returns an instance of the InterSBoxClient class according to the currently enabled client creation mode. By default the so called unique client creation mode is disabled.

VectorsContainer: Data container class used to store XVector and RVector objects representing link traffic vectors and reference vectors organized in pairs (XRVectorPair class) by AS number.

o

public

XRVectorPair

accumulateAndStoreUpdatedXVectorValues(XVector xVector):

Stores data from new link traffic vector in the container. If XRVectorPair for given AS already exists it is updated, meaning that the current counter values are increased by the values from the new link traffic vector. If not, new XRVectorPair is created.

o

public void resetXVectorValues(int asNumber): Resets the counter values of link traffic vector stored for given AS.

o

public XRVectorPair storeUpdatedRVector(RVector rVector): Stores new reference vector (RVector) in the container. If XRVectorPair for given AS already exists it is updated. If not, new XRVectorPair is created.

o

public XRVectorPair loadCurrentVectorPair(int asNumber):

Retrieves XRVectorPair for given AS from the container.

o

public Set<Integer> getListOfAsNumbers(): Retrieves a list of all ASs for which vector pairs are currently stored in the container.

XRVectorPair: Used to store two related vector objects (XVector and RVector) representing link traffic vector and reference vector, respectively.

o public XRVectorPair(XVector xVector, RVector rVector):

The constructor with arguments that sets both vectors. Those vector can be later on retrieved with appropriate getter method.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

o public boolean areBothVectorsSet(): Checks whether both vectors comprising the pair were already set.

o public int getAsNumber(): Returns the number of the AS for which both of the vectors were calculated. Note: Both vectors should have the same value of source AS number field.

should have the same value of source AS number field. Figure 18: NTM partial class diagram:

Figure 18: NTM partial class diagram: traffic receiver side

Sequence diagrams in Figure 19 and Figure 20 present the NTM interactions with other SBox components after reporting and accounting periods, respectively. Presented actions are related to the NTM operations performed on the traffic receiving side of inter-DC communication.

After reporting period elapses, the DTMQoSAnalyzer updates DTMTrafficManager with a new X vector value. This triggers the execution of CVectorProcessingThread which calculates a new C vector using CVectorCalculator and instructs the

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

DTMVectorSender to send the new value to a remote SBox. InterSBoxClient is called to perform the actual C vector transfer.

After accounting period elapses, the EconomicAnalyzerInternal updates DTMTrafficManager with a new R vector value. This triggers the execution of CRVectorProcessingThread which calculates a new C vector and sends both newly calculated C vector and received R vector to a remote SBox.

calculated C vector and received R vector to a remote SBox. Figure 19: NTM sequence diagram

Figure 19: NTM sequence diagram after reporting period: traffic receiver end

diagram after reporting period: traffic receiver end Figure 20: NTM sequence diagram after accouting period:

Figure 20: NTM sequence diagram after accouting period: traffic receiver end

In Figure 21, a partial NTM class diagram is presented with the following classes (DTMRemoteVectorsReceiver class was already described in the previous paragraph):

SDN

SDNConfigPusher: Implements

methods

that

forward

requests

for

Controller

vector

information

update

or

configuration

to

the

SboxSdnClient

component.

o public SDNConfigPusher(List<SDNController> controllers):

The constructor with arguments: list of SDN controllers to which subsequent requests called on this object will be directed.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

o

public void updateVectorInfo(CVector cVector): Method uses SboxSdnClient to update compensation vector information in selected SDN controllers.

o

public void updateVectorInfo(CVector cVector, RVector rVector): Method uses SboxSdnClient to update compensation and reference vectors information in selected SDN controllers.

o

public void initializeSDNController(ConfigData data):

Method uses SboxSdnClient to initialize selected SDN controllers with configuration data.

SDNClientFactory: Static factory class used by the SDNConfigPusher to obtain instances of SboxSdnClient to be used for communication with remote SDN controllers.

o public static SboxSdnClient getInstance(): Method returns an instance of the SboxSdnClient according to currently enabled client creation mode. By default the so called unique client creation mode is disabled.

ThetaCoefficientHandler: Implements logic for manipulating compensation vector values based on theta coefficients.

o public CVector normalizeCVector(CVector cVector, RVector rVector): Method normalizes compensation vector values based on theta coefficients provided as part of reference vector for given AS.

SDNControllerContainer: Data container class used to store information about SDN controllers that manage DA routers on which tunnels were configured towards AS with given AS number.

o

public void populateControllersFromDB(): Used to initialize internal structures based on data stored in data base.

o

public

List<SDNController>

getControllersByRemoteASNumber(int asNumber): Returns a list of SDN controllers that manage DA routers with tunnels towards given remote AS.

o

public List<SDNController> getAllControllers(): Returns a list of all SDN controllers in local ASs.

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Framework, and Initial Prototype Commercial in Confidence Figure 21: NTM partial class diagram: traffic sender side

Figure 21: NTM partial class diagram: traffic sender side

The sequence diagram in Figure 22 presents the Network Traffic Manager interactions that take place on the traffic sending side of inter-DC communication. During NTM component initialization, DTMRemoteVectorsReceiver is requested to initialize all SDN controllers with initial configuration data loaded from the database. This request is passed to SDNConfigPusher which in turn communicates with SboxSdnClient to transfer required ConfigData to the SDN controller over HTTP. Later on during SBox operation, DTMRemoteVectorsReceiver periodically receives from InterSBoxServer new C and R vectors updated by remote SBoxes. SDNConfigPusher is used to pass those vectors to appropriate SDN controllers. The actual transfer is done by SboxSdnClient.

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

in Confidence Seventh Framework STREP No. 317846 Figure 22: NTM simplified sequence diagram: traffic sender

Figure 22: NTM simplified sequence diagram: traffic sender side

6.1.1.4 Tests In order to test the functionality of NTM a set of 10 test classes was implemented comprising JUnit [20] tests for not only particular single methods or group of methods but also simple workflows internal to NTM component. Mockito library [69] was used in several cases to mock components external to NTM, e.g. Database, SBox-SDN Communication Service and Inter-SBox Communication Service.

The implemented test classes with test methods are listed below (please note that all provided names of test methods are preceded with public void in the source code):

NetworkTrafficManagerDTMTest contains following test methods for NetworkTrafficManager class initialization of DTM modules in three modes as specified in NetworkTrafficManagerDTMMode enum class:

o

shouldCreateAndInitializeNTMInSenderOnlyMode()

o

shouldCreateAndInitializeNTMInReceiverOnlyMode()

o

shouldCreateAndInitializeNTMInGeneralMode()

o

shouldCreateAndInitializeNTMInDefaultMode()

XVectorUpdateTest contains following test methods for workflow triggered by DTMTrafficManager class after receiving updated link traffic vector from QoS Analyzer component:

o

shouldThrowExceptionOnVectorNull()

o

shouldThrowExceptionOnInvalidVectorASNumberArgument()

Seventh Framework STREP No. 317846

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

o

shouldThrowExceptionOnInvalidVectorValuesListArgument()

o

shouldSkipCalculationAfterXVectorUpdate()

throws

InterruptedException

o

shouldCalculateCAndUpdateCVectorAfterXVectorUpdate() throws InterruptedException

RVectorUpdateTest

contains following test methods for workflow triggered by

DTMTrafficManager class after receiving updated reference vector from Economic Analyzer component:

o

shouldThrowExceptionOnVectorNull()

o

shouldThrowExceptionOnInvalidVectorASNumberArgument()

o

shouldThrowExceptionOnInvalidVectorValuesListArgument()

o

shouldSkipCalculationAfterRVectorUpdate()

throws

InterruptedException

o

shouldCalculateCAndUpdateCRVectorsAfterRVectorUpdate() throws InterruptedException

XRVectorsUpdateDetailedTest: contains following more detailed test methods for workflow triggered by DTMTrafficManager class after receiving updated traffic vectors from QoS Analyzer and Economic Analyzer component:

o

shouldDistributeCRVectorsAfterAccountingPeriodEnd() throws Exception

o

shouldDistributeCVectorBeforeAccountingPeriodEndSingleXV ector() throws Exception

o

shouldDistributeCVectorBeforeAccountingPeriodEnd() throws Exception

RemoteVectorsUpdateTest contains following test methods for workflow triggered by DTMRemoteVectorsReceiver class after receiving new compensation and reference vectors from remote SBoxes:

o

shouldThrowExceptionOnCVectorNull()

o

shouldThrowExceptionOnRCVectorsNull()

o

shouldThrowExceptionOnInvalidCVectorASNumberArgument()

o

shouldThrowExceptionOnInvalidCRVectorASNumberArgument()

o

shouldThrowExceptionOnInvalidCVectorValuesListArgument()

o

shouldThrowExceptionOnInvalidCRVectorValuesListArgument(

)

o

shouldInitControllers()

o

shouldProcessAndNotUpdateWhenNoSDNControllers()

o

shouldProcessAndUpdateAfterRemoteCVectorReceived()

o

shouldProcessAndUpdateAfterRemoteCAndRVectorsReceived()

CVectorCalculatorTest contains following test methods for compensation vector calculation logic implemented in CVectorCalculator class:

D3.2 – Technologies, Implementation Framework, and Initial Prototype

Commercial in Confidence

Seventh Framework STREP No. 317846

o

shouldCalculateFromTwoDimentionVectors()

o

shouldCalculateWithOneXVectorValueZero()

o

shouldCalculateWithEqualRAndXVectorValuesRatio()

o

shouldCalculateWithAllXVectorValuesZero()

o

shouldCalculateWithXVectorEqualRVactor()

o

shouldCalculateFromFiveDimentionVectors()

o

shouldReturnNullSinceVectorNull()

o

shouldReturnNullSinceInvalidVectorSize()

o

shouldReturnNullSinceVectorSizeBelowTwo()

o

shouldReturnNullSinceInvalidLinkIDs()

ThetaCoefficientHandlerTest contains following test methods for the logic implemented in ThetaCoefficientHandler class (this class and its tests will be enhanced in future releases):

 

o

shouldReturnTheSameCVectorIfThetaNull()

o

shouldReturnTheSameCVectorIfThetaNotNull()

VectorsContainerTest contains following test methods for store and load methods of VectorsContainer class:

 

o

shouldCreateNewPairOnEmptyContainerWithUpdatedXVector()

o

shouldCreateNewPairWithUpdatedXVector()

o

shouldCreateNewPairOnEmptyContainerWithUpdatedRVector()

o

shouldCreateNewPairWithUpdatedRVector()

o

shouldUpdateExistingPairWithUpdatedXVector()