Deliverable D3.4 - Prototype Implementation, Validation and Selected Application Final Version

D3.
4 Prototype Implementation,
Validation and Selected Application
Seventh Framework STREP No. 317846

Commercial in Confidence
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.4
Prototype Implementation, Validation and
Selected Application
The SmartenIT Consortium

Universitt Zrich, UZH, Switzerland
Athens University of Economics and Business - Research Center, AUEB, Greece
Julius-Maximilians Universitt Wrzburg, UniWue, Germany
Technische Universitt 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 2015, the Members of the SmartenIT Consortium

For more information on this document or the SmartenIT project, please contact:
Prof. Dr. Burkhard Stiller
Universitt Zrich, CSG@IFI
Binzmhlestrasse 14
CH8050 Zrich
Switzerland
Phone: +41 44 635 4331
Fax: +41 44 635 6809
E-mail: info@smartenit.eu
Version 1.0
Page 1 of 191
D3.4 Prototype Implementation, Validation

and Selected Application
Document Control
Title:
Prototype Implementation, Validation and Selected Application
Type:
Public
Editor:
George Petropoulos
E-mail:
geopet@intracom-telecom.com
Author(s):
George Petropoulos, Sergios Soursos, Jakub Gutkowski, ukasz

opatowski, Grzegorz Rzym, Piotr Wydrych, Andri Lareida, Daniel Dnni,
Thomas Bocek, Fabian Kaup, Matthias Wichtlhuber, Sabine Randriamasy,
Zbigniew Duliski, Rafa Stankiewicz, Krzysztof Wajda, Ioanna Papafili,
Paolo Cruschelli, Burkhard Stiller
Doc ID:
D3.4-v1.0.doc
Amendment History
Version
Date
Author
Description/Comments
v0.1
January 30, 2015
George
Table of contents
v0.2
March 31, 2015
George
Updated table of contents
v0.3
April 15, 2015
George, Fabian, Lukasz, Jakub,

Grzegorz, Sabine, Andri, Daniel
Integrated input to chapters 4, 5, 6 and 7.
v0.4
April 21, 2015
George, Sergios, Matthias, Lukasz,

Jakub, Grzegorz, Daniel, Piotr
Integrated input to all chapters.
v0.5
April 24, 2015
Ioanna, Paolo, Burkhard
Internal review
v1.0
April 30, 2015
George, Sergios, Lukasz, Grzegorz,

Matthias, Daniel, Sabine, Thomas
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 SmatenIT 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.
Page 2 of 191
Version 1.0
D3.4 Prototype Implementation,


Table of Contents
1 Executive Summary
2 Introduction
2.1
2.2
Purpose of Deliverable 3.4

Document Outline
6
7
3 Architecture Overview
3.1
3.2
3.3
Overview
Entities/Components/Interfaces
System Deployment
8
9
11
4 Implementation Framework
4.1
4.2
4.3
4.4
4.5
14
Tools
4.1.1 Specification Language
4.1.2 Programming Languages
4.1.3 Libraries
4.1.4 Tool chain
4.1.5 Testbed
4.1.6 Version Control
4.1.7 Issue Tracking
4.1.8 Continuous Integration Server
Procedures
4.2.1 System Release Process
4.2.2 Development Process
4.2.3 Roles
4.2.4 Meetings
System tree layout
Open-Source releases
Deployment Instructions
14
14
14
15
16
16
16
16
17
17
17
18
18
19
19
22
22
5 The Dynamic Traffic Management (DTM) mechanism

5.1
5.2
24
SBox
5.1.1 Quality of Service Analyzer
5.1.2 Network Traffic Manager
5.1.3 Economic Analyzer
5.1.4 Inter-SBox Communication Service
5.1.5 SBox-SDN Communication Service
5.1.6 Database
5.1.7 User Interface
SDN Controller
5.2.1 Interfaces
5.2.2 Floodlight
24
24
37
57
64
64
64
69
78
78
80
6 The Replicating Balanced Tracker - Home Router Sharing based on Trust (RBHORST) mechanism
90
6.1
6.2
uNaDa
6.1.1 Cloud Traffic Manager
6.1.2 Overlay Manager
6.1.3 Topology Proximity Monitor
6.1.4 Social Monitor
6.1.5 Social Analyzer
6.1.6 uNaDa-End-User Interface
6.1.7 Database
End-User
90
90
99
103
106
107
109
111
119
128
7 The Multi-Criteria Application End-Point Selection (MUCAPS) mechanism

Version 1.0
134
Page 3 of 191

7.1
7.2
Mapping to the SmartenIT Architecture

7.1.1 Required SmartenIT components and entities
7.1.2 Embedding MUCAPS on the SmartenIT architecture
Implementation and Deployment
7.2.1 Description of the MACAO related functional blocks
7.2.2 MUCAPS implementation and execution: entities and interfaces
7.2.3 In-network transparent deployment
8 The Virtual Incentives (vINCENT) mechanism

8.1
8.2

9 The Mobile Network Assistant (MoNA) mechanism

9.1
9.2

10 The SDN-based DC selection (SDNDC) mechanism

10.1 Mapping to the SmartenIT Architecture
10.2 Implementation and Deployment
10.2.1 Implementation Environment Description
10.2.2 Implementation
134
135
136
137
137
140
145
147
147
148
151
151
152
155
155
157
157
158
11 System Releases
162
11.1 Release v1.1

11.1.1 Features
11.1.2 Tests
11.1.3 Issues
11.2 Release v1.2
11.2.1 Features
11.2.2 Tests
11.2.3 Issues
11.3 Release v2.0
11.3.1 Features
11.3.2 Tests
11.3.3 Issues
11.4 Release v2.1
11.4.1 Features
11.4.2 Tests
11.4.3 Issues
11.5 Release v3.0
11.5.1 Features
11.5.2 Tests
11.5.3 Issues
11.6 Release v3.1
11.6.1 Features
11.6.2 Tests
11.6.3 Issues
163
163
163
163
163
163
164
165
166
166
167
172
172
172
173
174
174
175
175
176
177
177
177
179
12 Summary
180
13 SMART Objectives Addressed
182
14 References
184
15 Abbreviations
186
16 Acknowledgements
188
Page 4 of 191
Version 1.0


1 Executive Summary
The aim of Deliverable 3.4 Prototype Implementation, Validation and Selected
Application is to document the final release of the SmartenIT prototype, with respect to
the implementation framework, the design and the implementation of the SmartenIT
system. Moreover, D3.4 also documents any standalone implementations that were made
by SmartenIT partners but were not integrated to the core system.
D3.4 is the outcome of four WP3 tasks, namely T3.2 Technology Scouting and Definition
of Implementation Framework, T3.3 Development of Prototype Components, T3.4
Implementation of Selected Application and T3.5 Integration of Prototype and
Validation. Hence, this deliverable covers all SmartenIT prototype implementation
aspects. Additionally, D3.4 provides an overview of the standalone implementations
carried out throughout the duration of the project.
D3.4 is the last deliverable of WP3 Architecture Design and Engineering and with its
submission, the activities of WP3 are concluded. Thus, this deliverable provides the final
documentation of the SmartenIT prototype and can be used by third parties to extend the
software. For this reason, the SmartenIT consortium has already published the source
code of the prototype as Open Source, under the Apache License v2, available at [39].
The objectives and outcomes of D3.4 are summarized below:
A detailed description of the technologies and libraries used in the SmartenIT
prototype, along with the implementation framework (i.e., processes, tools, roles).
Detailed instructions on how to build the source code and deploy the artifacts on
the recommended hardware.
Detailed documentation of the two main mechanisms implemented by the
SmartenIT prototype, namely the Dynamic Traffic Management (DTM) and the
Replicating Balanced tracker & Home Router Sharing based on Trust (RBHORST) mechanisms. The documentation includes a per-component breakdown of
all the involved classes and interfaces, thus providing a full explanation of the
structure of the code, the functionality implemented, as well as the accompanying
tests for the validation of the components.
Documentation of the standalone implementation of certain SmartenIT
mechanisms which were not however integrated to the core prototype, due to either
their low maturity or the different direction decided to be taken by the SmartenIT
consortium. The documentation includes a description of the functionality
implemented, a mapping to the SmartenIT architecture and details of the
implementation and deployment. The mechanisms that fall under this category are
MUlti-Criteria Application endPoint Selection (MUCAPS), the Virtual Incentive
(vINCENT), the Mobile Network Assistant (MoNA) and the SDN-based DC
selection mechanisms.
A complete list of all the SmartenIT prototype releases, with the implemented
functionality in each of them, along with the respective integration tests.
To summarize, this deliverable stands as the engineering and implementation
documentation of the final release of the SmartenIT prototype and standalone
implementations and concludes the works of WP3.
Version 1.0
Page 5 of 191

2 Introduction
The focus of the SmartenIT project is to devise management mechanisms for traffic
generated by applications running on the Cloud and/or forming overlays. The main axes
around which such solutions evolve are: i) social awareness, ii) incentive compatibility, iii)
energy efficiency, and iv) QoE awareness. In this context, WP2 Theory and Modeling
has described a number of traffic management mechanisms that deal with certain
aspects. In the most recent deliverable of WP2, D2.4 Report on Final Specification of
Traffic Management Mechanisms and Evaluation Results [26], the final list of those
mechanisms is included, where each one of them is specified and evaluated. In
collaboration with WP3, WP2 has selected some of those mechanisms to be implemented
into a SmartenIT prototype according to the procedure described in [26]. The selected
mechanisms are specified in full details in [26] and comprise the core Dynamic Traffic
Management (DTM) mechanism, along with certain extensions so as to be combined with
the Inter-Cloud Communication (ICC) mechanism, as well as the Replicating Balanced
tracker & Home Router Sharing based on Trust (RB-HORST) mechanism. For more
details on these mechanisms, please consult [26].
WP3 on the other hand, has defined a modular architecture that can encompass any of
the functionality required for the SmartenIT prototype. In this sense, in the context of Task
3.1, Deliverable D3.3 Final Report on System Architecture [3] has documented all the
details of the SmartenIT architecture and has provided a mapping of all the identified
mechanisms to it. In the meantime, WP3 (through Tasks 3.3, 3.4 and 3.5) has started
implementing the first release of the SmartenIT prototype, which mainly involved the
implementation of the DTM mechanism. The details of this first release were documented
in D3.2 Technologies, Implementation Framework, and Initial Prototype [2].
With the next releases, WP3 started incorporating additional functionality and
mechanisms into the prototype system. In parallel, certain standalone implementations
were pursued by partners with focus on specific aspects of functionality that were not
addressed by the core system.
2.1
Purpose of Deliverable 3.4
The purpose of this deliverable is to fully document all the implementation work performed
by the consortium, by describing the final status of the SmartenIT prototype. More
specifically, D3.4 aims at:
describing in full detail the technologies and libraries used in the SmartenIT
prototype, along with the implementation framework (i.e., processes, tools, roles).
providing detailed instructions on how to build the source code and deploy the
artifacts on the recommended hardware.
documenting the mechanisms implemented by the SmartenIT prototype, including
a per-component breakdown of all the involved classes and interfaces, along with
the respective class and sequence diagrams, as well as the accompanying tests for
the validation of the components.
providing documentation of any standalone implementations of certain SmartenIT
mechanisms, not however integrated to the core prototype.
Page 6 of 191
Version 1.0


providing a complete list of all the SmartenIT prototype releases, with the
implemented functionality in each one of them, along with the respective integration
tests.
2.2
Document Outline
Chapter 3 briefly reminds to the reader the entire SmartenIT architecture, as documented
in D3.3 [3], including the entities, components and interfaces required to encompass the
envisioned functionality.
Chapter 4 is the outcome of Task 3.2, which includes all the technologies and tools used
to support the development and deployment of the selected traffic management
mechanisms. The generated system tree and build instructions are also included.
Chapter 5 presents the implementation details of the DTM mechanism and its extensions,
describe per entity and per component, and including description of the functionality, the
interfaces, the design and the related tests.
Chapter 6 provides the same details for the RB-HORST mechanism.
Chapter 7 documents the standalone implementation of the MUlti-Criteria Application
endPoint Selection (MUCAPS) mechanism, by describing the functionality implemented,
a mapping to the SmartenIT architecture and details of the implementation and
deployment.
Chapter 8 provides the same information for the Virtual Incentive (vINCENT)
mechanism.
Chapter 9 does the same for the Mobile Network Assistant (MoNA) mechanism, and so
does Chapter 10 for the SDN-based DC selection (SDNDC) mechanism.
Chapter 11 provides the list of the different system releases for the DTM and RB-HORST
mechanisms, by identifying the functionality implemented in each release (in the form of
features addressed), the respective integration tests and the remaining issues to be
addressed by next releases.
Chapter 12 provides a brief summary of the deliverables conclusions, including the final
implementation framework, the implemented components of the DTM and RB-HORST
mechanisms and the list of standalone implementations.
Finally, the SMART objectives, which are defined in the Description of Work [31], are
addressed in Chapter 13.
Version 1.0
Page 7 of 191

3 Architecture Overview
The SmartenIT architecture was finalized in D3.3 [3], hence this chapter presents a
synopsis of the most relevant aspects of the SmartenIT architecture that is necessary to
understand D3.4. Initially, a brief overview of the final SmartenIT architecture is given in
Section 3.1, presenting all components and interfaces, as well as their grouping to entities.
Sections 3.2 and 3.3 illustrate the mapping of the two integrated mechanisms to the
generic SmartenIT architecture and their deployment diagrams, respectively.
3.1
Overview
The component diagram in Figure 1 shows all the components of the SmartenIT
architecture together with an overview of main interfaces. The color-coding of the
components denotes whether a component already exists in external systems (white
components) or is already implemented by SmartenIT (blue components).
Datacenter/NaDa/Cloud Manager
Traffic
Redirector
Load
Balancer
Workflow
Manager
Hypervisor
Overlay
Manager
Inter DC/Cloud/NaDa
communication
E.g. ALTO
Billing/
Accounting
E.g. inter-ALTO
Economics
Analyzer
Traffic Manager
Cloud Traffic Manager
Social Monitor
E.g. Facebook
API
Inter-domain
communication
Fixed/Mobile
Network Traffic Manager
Social Analyzer
SDN Controller
E.g. REST
E.g. Vimeo API
Online
Social Networks
(e.g. Facebook)
Content
Portals (e.g.
Vimeo)
QoS/QoE
Analyzer
Network
Analyzer
Energy
Analyzer
E.g. SNMP,
BGP, Netflow
QoE Monitor
QoS Monitor
E.g. OpenFlow
Topology/
Proximity
Monitor
Energy Monitor
Switching/
Forwarding
Figure 1: The SmartenIT component diagram.

Moreover, the components may coexist on a number of entities. The mapping of
components to entities is presented in Figure 2. In this figure, the grey boxes denote
Page 8 of 191
Version 1.0


entities. In addition, the interfaces between entities components are presented.

Depending on the mechanism, each entity may run a subset of components and
interfaces.
Datacenter
ove1
Datacenter
Overlay
Manager
Traffic
Redirector
Load
Balancer
Workflow
Manager
Hypervisor
S-Box
iscs1
Inter-Sbox
Communication Service
ALTO
Energy
Monitor
eco1
Economics
Analyzer
Traffic Manager
UI
Social Analyzer
ntm1
Fixed/Mobile
DB
SDN Controller
soc2
Network
Analyzer
QoS/QoE Analyzer
uNaDa
ALTO
DB
UI
Energy
Analyzer
qos1
ove1
qoe1
top2
ene1
top1
ove2
Cloud Traffic
Manager
Overlay Manager
Topology/
Proximity Monitor
QoS/QoE
Analyzer
Network Entity
qoe1
soc3
End User Entity

qos1
soc2
soc2
ene1
soc1
Energy
Analyzer
Topology/
Proximity
Monitor
Switching/
Forwarding
Energy Monitor
ene1
Switching/
Forwarding
Traffic Manager
Vimeo
QoS Monitor
Topology/
Proximity
Monitor
Social Monitor
Energy Monitor
Energy Monitor
QoE Monitor
QoS Monitor
Social Analyzer
Social Monitor
ntm2
Facebook
ALTO
DB
UI
Figure 2: Components mapping to entities.

In the following subsections, the entities, components, interfaces and the deployment
diagrams of the two integrated prototypes, DTM and RB-HORST, are presented. The
mapping of the standalone implementations to the SmartenIT architecture are briefly
described in their respective chapters.
3.2
Entities/Components/Interfaces
Figure 3 and Table 3-1 present the instantiation of the SmartenIT architecture for the DTM
mechanism. 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.
Table 3-1: List of Entities for DTM implementation
Entity
Components
Reference
SBox
Inter-SBox Communication Service

(ISCS), Database (DB), User Interface
(UI), SBox-SDN, Economics Analyzer,
QoS/QoE Analyzer, Fixed/Mobile
Section 5.1
Version 1.0
Page 9 of 191


SDN Controller
SDN Controller, Interfaces
Section 5.2
ui
sdn1
S-Box
SDN Controller
Interfaces
ssdn
iscs1
ISCS
UI
Sbox-SDN
sdn2
iscs2
ntm3
SDN
Controller
ui
db
DB
Fixed/Mobile Network
Traffic Manager
openflow
netconf
ntm1
ntm2
Economics
Analyzer
Network Entity
Switching/
Forwarding
QoS Analyzer
eca1
snmp
QoS Monitor
Figure 3: The DTM mechanism entities/components/interfaces diagram.

On the other hand, the RB-HORST mechanism uses the entities and components,
presented in Figure 4 and also summarized in Table 3-2.
Table 3-2: List of Entities for RB-HORST implementation
Entity
Components
Reference
uNaDa
Cloud Traffic Manager (CTM), Overlay

Manager (OM), Social Monitor (SM),
Social Analyzer (SA), Topology
Proximity Monitor (TPM), Database
(DB), User Interface (UI), uNaDa-Enduser interface, Proxy
Section 6.1
End-User entity Traffic Manager, DB, UI
Section 6.2
Page 10 of 191
Version 1.0


uNaDa
End-User Entity
ctm2
ctm1
Mobile Network
Traffic Manager
Proxy
sa1
om1
db1
om2
Overlay
Manager
Social Analyzer
DB
Social Monitor
UI
UI
DB
om3
Topology
Proximity
Monitor
ui1
vimeo
facebook
Vimeo
Facebook
Figure 4: The RB-HORST entities/components/interfaces diagram
3.3
System Deployment
In this section, the deployment diagrams of the two integrated and released prototypes,
DTM and RB-HORST, are presented, including the required hardware, processes,
artifacts and protocols.
Diagram in Figure 5 presents the devices, processes and artifacts used, to deploy an
instantiation of the final version of the DTM mechanism.
More specifically, the SBox is deployed on an x64 server with Ubuntu 14.04 [32] installed,
and requires the installation of Java [6] and the Jetty Web server [13], in which the
sbox.war artifact is deployed. The sbox.war contains all the required components (UI and
DB) for the SBox Web application, exposing an HTTP/HTTPS Web interface, accessible
by any Web browser from the administrators PC. In addition, the sbox.jar is the main
executable of the SBox, including all components implementing DTM mechanisms
functionalities. It uses the JBoss Netty NIO framework [33] to expose the ISCS (Inter-SBox
Communication Service) interfaces using a custom SmartenIT-protocol over TCP, and
access the SDN Controllers REST API over HTTP. The Sqlite [14] is also used as the
SBoxs database.
The SDN Controller also requires an x64 server, with Ubuntu 14.04 [32] as its operating
system, requiring Java [6] to be installed. The sdn.jar executes all the Floodlight [23] SDN
Controllers processes, extended with DTM functionalities, and the Interfaces component,
which provides the SBox-SDN communication over HTTP.
Finally, the DTM mechanism requires also network devices, which, depending on the
localization in the network, must be Openflow-compatible [35], support SNMP [34] and
Version 1.0
Page 11 of 191

NETCONF [19]. QoS Analyzer of SBox retrieves SNMP measurements via SNMP.
NETCONF is used by the Network Traffic Manager to enforce configuration related with
delay tolerant traffic management. The network device also interacts with the exposed
Floodlight SDN Controllers interface using the OpenFlow protocol.
SBox (Server)
Jetty Container
SDN Controller (Server)
sqlite
HTTP
sbox.war
HTTP
(JSON)
sdn.jar
Floodlight
0.90
jdbc
sbox.jar
TCP
Inter-SBox
Communication
Service
OpenFlow
DB
NETCONF
Traffic Manager
Economic
Analyzer
QoS
Analyzer
Network Device
SNMP
Figure 5: DTM deployment diagram.

For the RB-HORST mechanism, the presented system architecture is mapped onto the
deployment diagram of Figure 6, which presents the hardware, processes and artifacts
used to deploy an instantiation of the RB-HORST entities, as well as the interfaces and
protocols between entities and external systems.
For the reference implementation of RB-HORST, the Raspberry Pi [30] was selected as
the home gateway hardware. It is a low cost credit-card-sized single-board computer that
can be used for various purposes in a home environment, and specifically in our
implementation with the addition of an external WiFi dongle, it plays the role of an accesspoint. Any hardware setup including a low-cost computer with minimum RAM of 256 MB, a
WiFi dongle that supports 2 SSIDs, and an SD-card with a light Linux flavor installed, can
host the uNaDa software. More details on the hardware setup can be found in D4.1 [4].
Raspbian OS is selected since it is optimized for the Raspberry Pi hardware and includes
thousands of packages and utilities, which ease development and optimize user
experience.
The uNaDa software is a Java 7 [6] Web application, which is packaged as a war file and
is deployed in the Jetty Web server [13], running the social and overlay prediction
algorithms, and managing system's cache. The mitmproxy software [17] acts as the
system's proxy, intercepting end-users' requests, caching watched videos and rewriting
end-user requests when the requested video exists in the local cache. An additional Web
server, lighttpd [16], is used to serve cached contents to connected end-user devices,
while h2 [15] is the system's database. Two additional services, hostapd and dhcpd, are
installed to provide the 2 SSIDs and DHCP capabilities, so that Raspberry Pi can act as
an access-point. On the contrary, the end-user entity is implemented as an Android [7]
application, packaged as an apk file and is installed in any Android smartphone or tablet.
Page 12 of 191
Version 1.0


Figure 6: RB-HORST deployment diagram.

Each uNaDa advertises and/or asks other overlay peers for content, location or other
metadata, using TomP2P [29] library, a distributed hash table which provides a
decentralized key-value infrastructure for distributed applications. The Facebook [27] and
Vimeo [28] APIs are periodically queried over HTTP by the Social Monitor, aiming to
retrieve and store social information. In addition, each uNaDa exposes a Web user
interface, accessible through any Web browser, where end-users can login with their
Facebook credentials, and manage their local cache and access-point. Finally, a REST
API is exposed and triggered by the RB-HORST Android application, used for end-users'
authentication in remote uNaDas, which returns private SSID credentials using JSON.
Version 1.0
Page 13 of 191

4 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. The initial
implementation framework was briefly described in D3.2 [2], mainly involving all the
required tools and technologies used in the DTM prototype development and release. This
chapter presents the final implementation framework for the two integrated and released
prototypes, DTM and RB-HORST, including the tools used, and the final system tree
layout and deployment instructions. Standalone mechanisms implementation framework
will be presented in their respective chapters.
4.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 systems components and the validation testbed created to validate each
releases features and functionalities.
4.1.1 Specification Language
The SmartenIT system is designed and modeled using UML specification language. As
also indicated in D3.2 [2], Microsoft Visio [5] is the key tool for the sequence, class,
architecture and deployment diagrams presented throughout this document.
4.1.2 Programming Languages
The selected programming languages for the SmartenIT entities are presented in Table
4-1.
Table 4-1: Entities programming languages.
Entity
Programming
Language(s)
Development Kit
SBox
Java
Oracle JDK 1.7.0_51 [6]
SDN Controller
Java
Oracle JDK 1.7.0_51 [6]
uNaDa
Java
Oracle JDK 1.7.0_51 [6]
End-User
Java
Android SDK API 14 [7]
Page 14 of 191
Version 1.0


4.1.3 Libraries
The external dependencies of each component are presented in Table 4-2.
Table 4-2: Components libraries.
Entity
Component
Libraries
sqlite-jdbc-3.7.2
Database
jdbi 2.53
jackson-annotations 2.3.3
Interfaces
(Inter-SBox and SBox-SDN)
User Interface
SBox
netty 4.0.21.Final
jackson-databind 2.2.3
wiremock 1.46
javax.servlet 3.0
jsf-api, jsf-impl 2.2.6
QoS Analyzer
snmp4j 2.2.5
Economic Analyzer
commons-math3 3.0
netconf-java 1.0.1
slf4j 1.7.7
Commons
logback 1.1.2
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
concurrentlinkedhashmap-lru 1.2
Floodlight
SDN
Controller
jython-standalone 2.5.2
libthrift 0.7.0
easymock 3.1
jsonassert 1.2.3
logback 1.0.0
slf4j 1.6.4
Interfaces
Database
uNaDa
User Interface
jsonassert 1.2.3
h2 1.4.184
jdbi 2.53
javax.servlet 3.0
jsf-api, jsf-impl 2.2.6
Version 1.0
Page 15 of 191

restfb 1.6.16
Social Monitor
httpclient 4.3.5
simplelatlng RELEASE
tomp2p-all 5.0-Alpha24
Overlay Manager
com.maxmind.geoip2 2.1.0
Topology Proximity Monitor
netty 4.0.21.Final
Cache Manager
vget 1.1.23
uNaDa-end-user inteface
jersey-media-json-jackson, jersey-test-frameworkprovider-jetty 2.12

slf4j 1.7.7
Commons
logback 1.1.2
commons-configuration 1.10
commons-logging 1.1.3
gson 2.3.1
End-User
App
android 4.1.1.4
facebook-sdk
support-v4 r7
4.1.4 Tool chain

Apache Maven [8] is used as the dependency management and build automation tool for
the SmartenIT prototype, as also defined in D3.2 [2]. The projects system tree,
dependencies and build/execution commands are presented in Section 4.3.
4.1.5 Testbed
For the validation of both integration prototypes, the basic testbed design and extensions
were used. The initial design was defined in D3.2 [2] and further details on the basic
testbeds design and configuration are provided in the D4.1 [4].
4.1.6 Version Control
Apache Subversion [9] is used as the version control system of SmartenIT. The
Subversion server is hosted and administrated by PSNC.
In addition to the internal SVN repository, the project consortium has setup a Github [10]
account and created a Github repository, to host and release the projects source code as
open-source. The SmartenIT Github repository will be later presented in Section 4.4 and is
available at [39].
4.1.7 Issue Tracking
Atlassian Jira [11] is a software implementation management and issue-tracking tool, used
to organize and plan the work of developers and the integrator. The Atlassian Jira server
is hosted and administrated by PSNC.
Page 16 of 191
Version 1.0


4.1.8 Continuous Integration Server

Jenkins [12] is a continuous integration tool, used to automatically and frequently build our
system. The Jenkins server is hosted and administrated by PSNC.
4.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 played
specific roles in these processes. Specific types of meetings where organized throughout
the development process.
4.2.1 System Release Process
The SmartenIT system release process followed the agile development model and was
divided into (approximately) 2 month release cycles. Each release cycle (Figure 7)
consisted of:
Feature planning, where the consortium identified and prioritized features and tasks
for next release;
Development of the required features by the responsible partners;
Integration of the developed components and basic sanity tests;
System validation, where the developed system was tested in the testbed for the
required release features;
System release and preparation of system release report.
Figure 7: System release cycle.
Version 1.0
Page 17 of 191

4.2.2 Development Process

The SmartenIT development process utilized the concept of continuous integration, in
which developers commit frequently (daily if possible) their code, aiming to prevent
integration problems and identify issues rapidly. This process was supported by
automated tools such as Jenkins (see Section 4.1.8).
The implementation process (Figure 8) comprised 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.
Figure 8: Development process.

4.2.3 Roles
A set of roles involved in the overall implementation process was decided that would
support processes that are described above. Each role was assigned a list of
responsibilities and responsible project partner. Those roles and related assignments are
presented in Table 4-3.
Table 4-3: Defined roles in the development process.
Role
Responsibilities
Responsible
Partner
Responsible
Person
Product Manager Sets the high-level

requirements and features of
each release.
ICOM
Spiros Spirou
Tools
Administrator
PSNC
(&ICOM)
Jakub Gutkowski
Manages and maintains

implementation framework
tools.
Page 18 of 191
ukasz opatowski
Version 1.0


Release Master
Provides access to tools.
George Petropoulos
Facilitates the system release ICOM

process.
(&PSNC)
George Petropoulos
ukasz opatowski
Contact point of the

implementation team.
Implementation
Team
Consists of all the people,

responsible for the design,
development, integration,
testing and deployment of the
SmartenIT prototype.
UZH, TUD,
AGH, ICOM,
ALBLF,
PSNC
As appointed by
each Partner.
4.2.4 Meetings
In each release cycle defined in Section 4.2.1, three types of the meetings took place:
feature planning meeting, weekly meeting and release review meeting. For more details
please see Section 5.2.4 in D3.2 [2].
4.3
System tree layout
D3.2 [2] presented the initial system tree layout of the SmartenIT source code, including
only the DTM entities and components. This section will define the final system tree
layout, including the RB-HORST entities and components.
The SmartenIT source code is organized as a Maven [8] 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 (mavenassembly-plugin). Each entitys component (e.g. main, interfaces) is a Maven module,
which may be divided into further maven modules or packages, based on component
owners preferences. In the defined system tree, certain components were divided into
sub-modules to isolate developers work, as well as avoid possible dependencies
conflicts.
The final SmartenIT system tree is presented below. Parentheses define the type of
packaging, indicating whether a module either consists of other sub-modules (pom
packaging), or is packaged as a (a) Java archive (jar), which aggregates all classes and
configuration files into one single executable, (b) a Web application archive (war) which
compresses all classes, Web pages, and resources into one executable which can be
deployed to any Web server, (c) an Android library (aar), (d) an Android archive (apk),
which compresses all classes, resources and files, which can be installed in an Android
device.
smartenit (pom)
o sbox (pom)
main (jar)
interfaces (pom)
inter-sbox (pom)
Version 1.0
Page 19 of 191

o client (jar)
o server (jar)
sbox-sdn (jar)
db (pom)
dao (jar)
dto (jar)
web (war)
ntm (jar)
qoa (jar)
eca (jar)
commons (jar)
o sdn (pom)
floodlight-0.90 (jar)
interfaces (pom)
sbox-sdn (jar)
o unada (pom)
interfaces (pom)
unada-enduser (jar)
db
dao (jar)
dto (jar)
ctm (pom)
cache (jar)
tpm (jar)
om (jar)
sa (jar)
web (war)
sm (jar)
commons (jar)
o enduser (pom)
app (pom)
facebook (aar)
SIT (apk)
Page 20 of 191
Version 1.0


SIT-TEST (apk)
o network (pom)
o dist (pom)
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
All the aforementioned commands also generate the SmartenIT software release artifact,
which is the smartenit-${project.version}.zip, created at the dist/target
directory.
The final release which implements the two integrated and released prototypes, DTM and
RB-HORST, the zip file contains the following executables and configuration files per
entity:
sbox
o main.jar: The main executable of the SBox application, which initializes all
modules, and executes the DTM mechanism.
o web.war: Its the war file, deployed to the Jetty Web server.
o sbox.properties: It includes all the required SBox configuration
parameters.
o logback.xml: It defines the logging level of the SBox application.
o realm.properties, jetty.xml: Configuration files that override default
Jetty configuration.
sdn
o floodlight-0.90.jar: The executable of the Floodlight SDN controller,
extended with SmartenIT functionality.
unada
o unada.war: The executable of the uNaDa software, which is deployed in
the Jetty Web server and executes the RB-HORST mechanism.
o unada.sh: A script that automatically starts the uNaDa processes.
o vimeo_proxy.py: A script used during initialization of mitmproxy software
for proxying and filtering end-user requests.
enduser:
o sit-app.apk: The HORST Android application, which will be deployed in
an Android smartphone or tablet.
Version 1.0
Page 21 of 191

4.4
Open-Source releases
The SmartenIT consortium has decided to release its major releases as open-source, in
order to be accessible by academic and research communities. For that purpose, a Github
[10] account and a repository were created (see Figure 9), available at [39]. The source
code is available under Apache v2 license [18].
Figure 9: SmartenIT Github repository.

Each time the integrated prototype was tested and internally released, the integration
team was also pushing the source code to the Github repository. Therefore, releases 1.1,
1.2, 2.1 and 3.0 were committed to the Github repository, while it is planned that final
version 3.1 will be also released to the general public.
4.5
Deployment Instructions
This section will provide the instructions to deploy the DTM and RB-HORST executables
to the targeted hardware.
The prerequisites to deploy and run the DTM executables are:
Oracle JDK 7 update 51 (Configure JAVA_HOME and PATH) [6],
Jetty 9.2.3.v20140905 (Configure JETTY_HOME and PATH) [13],
Sqlite 3 [14].
To deploy and run the SBox entity, check the following instructions:
Page 22 of 191
Version 1.0


1. Copy (and replace) the jetty.xml and realm.properties included in jetty-conf folder to
the $JETTY_HOME/etc directory: cp sbox/web/jetty-conf/jetty.xml
$JETTY_HOME/etc/jetty.xml;
cp
sbox/web/jettyconf/realm.properties $JETTY_HOME/etc/realm.properties
2. Copy the provided sbox.war file to the $JETTY_HOME/webapps directory: cp
sbox/web/sbox.war $JETTY_HOME/webapps/sbox.war
3. Initialize jetty ($JETTY_HOME/
module=https
directory):
java
-jar
start.jar
--
4. Open a Web browser and browse at https://<machine-ip-address>/sbox/admin or

http://<machine-ip-address>:8080/sbox/admin, where <machine-ip-address> is the
SBox's ip address (or localhost). Signin with admin/admin credentials.
5. Edit the sbox.properties file with the correct path to the smartenit.db file, and the
rest of required parameters.
6. To run the main SBox application: java -jar sbox.jar
To deploy and run the SDN Controller:
1. To run the extended SDN Controller: java -jar sdn.jar
The prerequisite software to deploy and run the RB-HORST mechanism entities are:
Oracle JDK 7 update 51 (Configure JAVA_HOME and PATH) [6],
Jetty 9.2.3.v20140905 (Configure JETTY_HOME and PATH) [13],
h2 [15],
lighttpd (Modify "server.document-root" of /etc/lighttpd/lighttpd.conf file to be equal
to $HOME directory, e.g. server.document-root = "/home/pi") [16],
mitmproxy (pip install mitmproxy) [17].
To deploy and run the uNaDa entity:
1. Copy
vimeo_proxy.py
~/vimeo_proxy.py
to
$HOME
directory:
cp
vimeo_proxy.py
2. Start the mitmproxy software ($HOME/ directory): mitmdump -T --host -s

vimeo_proxy.py
3. Copy the unada.war to $JETTY_HOME/webapps/:
$JETTY_HOME/webapps/unada.war
cp
unada.war
4. Add a relevant iptables rule to proxy all HTTPs requests to the mitmproxy: sudo
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j
REDIRECT --to-port 8080
5. Initialize Jetty ($JETTY_HOME/ directory):
etc/jetty.xml -Djetty.port=8181
java
-jar
start.jar
6. uNaDa Web interface is available at: http://192.168.40.1:8181/unada. If you are the

owner of the uNaDa you must login with your Facebook credentials.
To install the end-user entity:
1. Copy the sit-app.apk to the Android device, accept permissions and install it.
Version 1.0
Page 23 of 191

5 The Dynamic Traffic Management (DTM) mechanism

DTM is used to manage traffic exchanged between domains in which a Cloud or Data
Center (DC) is located. It is deployed by network operators on servers on both sides of an
inter-DC communication, since operators need to cooperate to achieve traffic transfer cost
reduction.
DTM functionalities, as defined in Deliverable D2.4 [26], map onto two architecture
entities, namely SBox and SDN Controller. Subsequent sections provide detailed
descriptions of the implemented software components being part of the respective entities.
Moreover the DTM specification defines two types of ISP network elements which are
involved in the network configuration which enables the DTM operations:
Data center Attachment point (DA): A point (router or switch) where DC inbound
and outbound traffic is passed to an ISP network;
Border Router (BG): An ISP border router on which inter-domain links are
terminated.
These devices are configured accordingly to the DTM specification however no SmartenIT
software is running on them.
5.1
SBox
SBox main functionalities comprise retrieving and aggregating SNMP measurements from
the network entities, calculating and distributing compensation and reference vectors,
delay-tolerant traffic management and finally, configuring the remote SDN Controller.
It includes certain components that are required to store and access DTM parameters
(Database and User Interface), retrieve and aggregate monitoring data from the network
devices (Quality of Service Analyzer), perform necessary calculations (Network Traffic
Manager, Economic Analyzer) and also interact with remote SBoxes and the SDN
Controller (Inter-SBox and SBox-SDN Communication Services).
Each components functionality, interfaces, design and finally unit tests are further
described in the following sections.
5.1.1 Quality of Service Analyzer
The Quality of Service (QoS) Analyzer component is responsible for periodical execution
of the following actions:
collection of incoming traffic counter values from all inter-domain links from a set of
configured BG routers;
collection of incoming traffic counter values from all tunnels from a set of configured
DA or BG routers (depending on which router given tunnel is terminated);
calculation of link traffic vector (X vector) and a list of tunnel traffic vectors (Z
vector) for each local AS;
distribution of information about new traffic vectors to Economic Analyzer and
Network Traffic Manager components;
Page 24 of 191
Version 1.0


archiving of traffic statistics in form of a text file.

The QoS Analyzer component supports two traffic charging rules defined in the system,
namely the total traffic volume based rule and the 95th percentile rule. Certain rule can be
enabled in the SBox user interface presented in Section 5.1.7 on the DTM settings page.
The above listed actions are executed at intervals specific to the used charging rule. In the
case of total traffic volume based rule, the calculation of vectors and the distribution of
information is performed at intervals defined by the length of the so called reporting
period. When the latter rule is enabled two different intervals are used, i.e. DTM reporting
period (X vector calculated and sent to NTM) and EA reporting period (X and Z vectors
sent to EA).
Counter values collection from network devices is performed by means of SNMP.
In order to improve performance and ensure that counters from all routers are read almost
exactly at the same moment, counters are read in multiple parallel threads (one thread per
router).
5.1.1.1 Interfaces
The QoS Analyzer does not provide any methods to be called by other SBox components.
5.1.1.2 Design
The QoS Analyzer consists of 23 classes organized into two packages:
eu.smartenit.sbox.qoa main package;
eu.smartenit.sbox.qoa.experiment extension to the QoS Analyzer
component added in order to support experimenters from WP4 with the ability to
store traffic statistics in form of a text file.
Following is the description of the most important classes from the main package of QoS
Analyzer component (see Figure 10). Please note that only public methods are listed.
DTMQosAnalyzer: Main class of the QoS Analyzer component. Communicates
with Economic Analyzer (EconomicAnalyzer class) and Network Traffic Manager
(DTMTrafficManager class).
o public DTMQosAnalyzer(DTMTrafficManager trafficManager,
EconomicAnalyzer
economicAnalyzer): The constructor with
arguments: instances of DTM external interface classes of Network Traffic
Manager and Economic Analyzer;
o public void initialize(): Initializes SNMPTrafficCollector class and
starts scheduled traffic counters values collection tasks according to
configured time schedule parameters;
o public void updateXVector(XVector xVector): Updates Network
Traffic Manager (DTMTrafficManager class) with link traffic vector calculated
after reporting period (or DTM reporting period);
o public
void
updateXZVectors(XVector
xVector,
List<ZVector> zVectors): Updates Economic Analyzer with link traffic
Version 1.0
Page 25 of 191

vector and a list of tunnel traffic vectors calculated after reporting period (or
EA reporting period).
SNMPTrafficCollector: Class used to schedule traffic counter collection tasks
and calculating traffic vectors once all counters are read after each reporting period
(or DTM reporting period). Calculated vectors are provided to DTMQosAnalyzer for
further distribution.
o public SNMPTrafficCollector(DTMQosAnalyzer analyzer): The
constructor with argument: instance of the DTMQosAnalyzer which should
be updated with calculated traffic vectors;
o public
void
configure(List<AS>
systems,
List<DC2DCCommunication> communications): Populates helper
data structures with links and tunnels that will be monitored. Triggers
collection of SNMP OID numbers for links and tunnels counters;
o public void scheduleMonitoringTasks(): Schedules counters
values collection tasks according to configured time schedule parameters;
o public
void
notifyNewCounterValues(int
asNumber,
CounterValues counterValues): Calls MonitoringDataProcessor to
calculate new link traffic vectors with data fetched from counters. Updates
DTMQosAnalyzer with the new link and tunnel traffic vectors;
o public MonitoredLinksInventory getMonitoredLinks(): Getter
method for monitored links inventory;
o public MonitoredTunnelsInventory getMonitoredTunnels():
Getter method for monitored tunnels inventory.
TrafficCollectorTask: Task class responsible for collecting counter values
from BG and DA routers. Implements Runnable interface.
o public
TrafficCollectorTask(SNMPTrafficCollector
trafficCollector, int asNumber): The constructor with arguments:
instance of the SNMPTrafficCollector from which information about
monitored links and tunnels will be read and which will be notified once all
counters are read; and number of the AS for which this task is launched
(relevant if SBox manages more than one AS);
o public void run(): Method launched when thread is started.
Responsible for fetching data from router counters and updating
SNMPTrafficCollector with collected data.
CounterCollectorThread: Thread class responsible for collecting counter
values from specific interfaces of a given router. Implements Callable interface.
o public
CounterCollectorThread(List<Link>
links,
List<Tunnel> tunnels,
BGRouter bgRouter): The constructor
with arguments to be used when monitoring a BG router;
o public
CounterCollectorThread(List<Tunnel>
tunnels,
DARouter daRouter): The constructor with arguments to be used when
monitoring a DA router;
Page 26 of 191
Version 1.0


o public CounterValues call() throws Exception: Thread's main

method responsible for fetching data from counters on given router and
updating TrafficCollectorTask.
SNMPWrapper: Wrapper class for the snmp4j library.
o public String snmpGet(OID oid, Target target): Triggers
snmpget command on given router specified by target argument and
given OID (object identifier). Returns the response received from the SNMP
agent;
o public List<String> snmpWalk(OID oid, Target target):
Triggers snmpwalk command on given router specified by target
argument and given OID. Returns the response received from the SNMP
agent;
o public void startClient() throws IOException: Starts SNMP
client;
o public void stopClient() throws IOException: Stops SNMP
client;
o public Target prepareTarget(String routerAddress, String
snmpCommunity): Prepares Target class instance with router address and
SNMP community to be used in snmpGet and snmpWalk method calls;
o public OID prepareOID(String oid): Prepares OID class instance
to be used in snmpGet and snmpWalk method calls.
SNMPOIDCollector: Helper class for preparing SNMP OID numbers for link and
tunnel counters.
o public SNMPOIDCollector(MonitoredLinksInventory links,
MonitoredTunnelsInventory tunnels): The constructor with two
arguments: links and tunnels to be monitored;
o public void collectOIDsForLinks() throws IOException:
Triggers OID information collection for all link counters from all BG routers;
o public void collectOIDsForTunnels() throws IOException:
Triggers OID information collection for all tunnel counters from all DA and
BG routers.
MonitoringDataProcessor: Used to handle monitoring data (i.e. counter
values) and calculating link traffic vector and tunnel traffic vectors by means of
XVectorCalculator class and ZVectorCalculator class, respectively.
o public
MonitoringDataProcessor(MonitoredLinksInventory
monitoredLinks,
MonitoredTunnelsInventory
monitoredTunnels): The constructor with two arguments: all monitored
links and tunnels;
o public
XVector
calculateXVector(int
asNumber,
CounterValues
lastValues,
CounterValues
newValues):
Calculates link traffic vector by means of XVectorCalculator class based on
provided counter values for inter-domain links of given AS;
Version 1.0
Page 27 of 191

o public
List<ZVector>
calculateZVectors(int
asNumber,
CounterValues
lastValues,
CounterValues
newValues):
Calculates a list of tunnel traffic vectors by means of ZVectorCalculator class
based on counter values for tunnels in given AS.
o public ZVector aggregateZVectors(List<ZVector> zVectors):
Aggregates vector values from given tunnel traffic vectors and returns a
single Z vector.
VectorCalculator: Base abstract class for traffic vector calculators comprising
data structure used to store counter values from previous reporting periods.
o protected
CounterValues
getOrCreateLatestVectorValues
(int asNumber): Returns stored instance of CounterValues for given AS if
exists. If not, creates and returns new instance.
XVectorCalculator: Implements link traffic vector calculation based on current
counter values collected from links in given AS and previous values of those
counters. Extends VectorCalculator class.
o public
XVector
calculateXVector(int
asNumber,
CounterValues lastValues, CounterValues newValues): Method
calculates new link traffic vector for given AS. It should be launched after
each reporting period.
ZVectorCalculator: Implements tunnel traffic vector calculation based on
current counter values collected from tunnels in given AS and previous values of
those counters. Extends VectorCalculator class.
o public
ZVectorCalculator(MonitoredTunnelsInventory
monitoredTunnels): The constructor with all monitored tunnels as an
argument;
o public
List<ZVector>
calculateZVectors(int
asNumber,
CounterValues lastValues, CounterValues newValues): Method
calculates new set of tunnel traffic vectors for given AS. Each ZVector class
object corresponds to a single DC2DCCommunication. It should be launched
after each reporting period.
CounterValues: Data container class used to store counter values (as 64bit
numbers) on per LinkID and per TunnelID basis.
o public
void
storeCounterValue(LinkID
linkID,
counterValue): Stores counter value for given link in the structure;
long
o public void storeCounterValue(TunnelID tunnelID, long

counterValue): Stores counter value for given tunnel in the structure;
o public
void
addLinksAndTunnels(CounterValues
counterValues): Populates the local structure with provided links and
tunnels counters data;
o public
void
addCounterValue(LinkID
linkID,
long
counterValue): Adds counter value to existing entry in the structure or
creates a new entry.
Page 28 of 191
Version 1.0


o public Map<LinkID, Long> getLinkCounterValues(): Retrieves

counter values for all links stored in the structure;
o public
Map<TunnelID,
Long>
getTunnelCounterValues():
Retrieves counter values for all tunnels stored in the structure;
o public Set<LinkID> getAllLinkIds(): Retrieves identifiers of all
links stored in the structure;
o public Set<TunnelID> getAllTunnelsIds(): Retrieves identifiers of
all tunnels stored in the structure;
o public Long getCounterValue(LinkID linkID): Retrieves 64-bit
counter value for given link from the structure;
o public Long getCounterValue(TunnelID tunnelID): Retrieves 64bit counter value for given tunnel from the structure.
o public
List<LocalVectorValue>
toLocalVectorValues():
Returns new list of LocalVectorValue based on stored counter values for
links.
MonitoredLinksInventory: Data container class used to store information
about routers and monitored links on per AS number basis. Provides specific query
methods to retrieve information.
o public void populate(List<AS> systems): Method to be called to
populate inventory with monitored link information that is obtained from list of
local Autonomous Systems;
o public List<Link> getLinks(int asNumber): Retrieves all interdomain links for given local AS;
o public List<Link> getLinks(BGRouter bgRouter): Retrieves all
links from given BG router;
o public List<BGRouter> getBGRouters(): Retrieves all BG routers
stored in the structure;
o public
List<BGRouter>
getBGRoutersByAsNumber(int
asNumber): Retrieves all BG routers from given local AS;
o public int getAsNumber(BGRouter bgRouter): Returns number of
the AS to which given BG router belongs;
o public Set<Integer> getAllAsNumbers(): Returns numbers of all
local ASs stored in the structure.
MonitoredTunnelsInventory: Data container class used to store information
about DA routers and monitored tunnels. Provides specific query methods to
retrieve information.
o public
void
populate(List<DC2DCCommunication>
communications): Method to be called to populate inventory with
monitored tunnels information that is obtained from list of
DC2DCCommunications terminated in local ASs.
Version 1.0
Page 29 of 191

o public List<Tunnel> getTunnels(int asNumber): Retrieves all

monitored tunnels from given local AS;
o public Tunnel getTunnel(TunnelID tunnelID, int asNumber):
Retrieves Tunnel instance for given TunnelID;
o public
List<Tunnel>
getTunnels(DARouter
Retrieves all monitored tunnels from given DA router;
daRouter):
o public
List<Tunnel>
getTunnels(BGRouter
Retrieves all monitored tunnels from given BG router;
bgRouter):
o public List<Tunnel> getTunnels(DC2DCCommunicationID id):

Retrieves all tunnels from inter-DC communication with given identifier;
o public List<DARouter> getDARouters(): Retrieves all DA routers
stored in the inventory;
o public
List<DARouter>
getDARoutersByAsNumber(int
asNumber): Retrieves all DA routers from given local AS;
o p. List<DC2DCCommunicationID> getAllDC2DCCommunicationIDs
(int asNumber): Retrieves identifiers of all inter-DC communications
terminating in given local AS;
o public Set<Integer> getAllAsNumbers(): Retrieves numbers of all
local ASs stored in the inventory.
Page 30 of 191
Version 1.0


Figure 10: Quality of Service Analyzer class diagram.

The classes contained in the eu.smartenit.sbox.qoa.experiment package of QoS
Analyzer are described below (see Figure 11):
ExtendedSNMPTrafficCollector: Extends SNMPTrafficCollector class to
enable writing traffic details to file.
Version 1.0
Page 31 of 191

o public
ExtendedSNMPTrafficCollector(DTMQosAnalyzer
analyzer): The constructor with arguments;
o public
boolean
configure(List<AS>
systems,
List<DC2DCCommunication> communications): Populates helper
data structures with links and tunnels that will be monitored. Triggers
collection of SNMP OID numbers for links and tunnels counters;
o public void scheduleMonitoringTasks(): Schedules counters
values collection task according to configured time schedule parameters;
o public
void
notifyNewCounterValues(int
asNumber,
CounterValues counterValues): Calls MonitoringDataProcessor class
to calculate new link traffic vectors with data fetched from counters. Updates
DTMQosAnalyzer class with the new link and tunnel traffic vectors. Extended
to enable writing traffic details to file.
ExtendedTrafficCollectorTask:
Extends
TrafficCollectorTask
class
to
o public void run(): Scheduled task responsible for fetching data from
router counters and updating SNMPTrafficCollector class with collected data.
ExtendedCounterCollectorThread: Extends CounterCollectorThread class to
o public ExtendedCounterCollectorThread(List<Link> links,
List<Tunnel> tunnels, BGRouter bgRouter): The constructor with
arguments to be used when monitoring BG router;
o public
ExtendedCounterCollectorThread(List<Tunnel>
tunnelsByDARouter, DARouter daRouter): The constructor with
arguments to be used when monitoring DA router.
ExtendedCounterValues: Extends CounterValues class to enable writing traffic
details to file.
o public
void
storeReceivedPackets(LinkID
linkID,
ReceivedPackets packetsInfo): Method used to store the number of
received packets on link;
o public
void
storeReceivedPackets(TunnelID
tunnelID,
ReceivedPackets packetsInfo): Method used to store the number of
received packets on tunnel;
o public
ExtendedCounterValues
calculateDifference
(ExtendedCounterValues
toBeSubtracted): Method used to
calculate difference between stored and provided values for all links and
tunnels;
o p Map<LinkID, ReceivedPackets> getLinkReceivedPackets():
Returns map with number of packets for all links;
o public
Map<TunnelID,
ReceivedPackets>
getTunnelReceivedPackets(): Returns map with number of packets for
all tunnels.
Page 32 of 191
Version 1.0


ReceivedPackets: Data container class used to store information about the

number of three types of packets.
o public ReceivedPackets(long unicast, long
long broadcast): The constructor with arguments;
multicast,
o public long aggregate(): Method used to calculate packets sum;

o public
ReceivedPackets
calculateDifference
(ReceivedPackets toBeSubtracted): Method used to calculate
difference between stored and provided values;
o public long getUnicast(): Returns amount of unicast packets;
o public long getMulticast(): Returns amount of multicast packets;
o public long getBroadcast(): Returns amount of broadcast packets.
ExtendedSNMPOIDCollector: Extends SNMPOIDCollector class to enable
writing traffic details to file.
o public
ExtendedSNMPOIDCollector(MonitoredLinksInventory
links, MonitoredTunnelsInventory tunnels): The constructor
with arguments.
FileManager: File manager class created to enable writing traffic details to file.
o public void updateFile(String path, String fileName,
String newRecord): Method used to update file with new record.
Figure 11: Class diagram for extension to Quality of Service Analyzer.

Version 1.0
Page 33 of 191

Sequence diagram in Figure 12 presents how the Quality of Service Analyzer interacts
with other SBox components, i.e. the Economic Analyzer and Network Traffic Manager.
After the TrafficCollectorTask finishes its execution, meaning that all counter values
are read from monitored routers, it passes new counter values to the
SNMPTrafficCollector which in turn instructs MonitoringDataProcessor to
calculate new X and Z vectors. Later on the QoSAnalyzer is used to pass information
about those new vectors to proper EconomicAnalyzer and DTMTrafficManager
instances.
Figure 12: Quality of Service Analyzer sequence diagram.

5.1.1.3 Tests
In order to test the functionality of the Quality of Service Analyzer a set of 22 test classes
was implemented comprising JUnit [19] tests for not only particular single methods or
group of methods but also simple workflows internal to QoS Analyzer component. Mockito
library [21] was used in several cases to mock components external to QoS Analyzer, e.g.
Database, Economic Analyzer and Network Traffic Manager.
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):
DTMQosAnalyzerTest contains test methods for DTMQosAnalyzer class
workflow launched after each reporting period including: new counter values
collection from routers, traffic vectors calculation and Economic Analyzer and
Network Traffic Manager updates:
o shouldUpdateXAndZVectors()
o shouldReturnFalseForInitialization()
SNMPTrafficCollectorTest
SNMPTrafficCollector class:
contains
following
test
methods
for
o shouldCalculatXVextor()
Page 34 of 191
Version 1.0


o shouldCalculaZXVextors()
o shouldUpdateXVector()
o shouldUpdateZVectors()
o shouldTriggerFiveScheduledTasks()
o shouldPrepareLogForScheduleMonitoringTasks()
o shouldPrepareErrorForAsNumbersValidation()
o shouldCalculateInitialDelay()
TrafficCollectorTaskTest
TrafficCollectorTask class:
contains
following
test
method
for
o shouldNotifyNewCounterValues()
TrafficCollectorTaskFailureScenarioTest contains following test method
for TrafficCollectorTask class:
o shouldMaxFetchingTimeExpire()
BGRouterCounterCollectorThreadTest contains following test methods for
collecting counter values from specific interfaces of BG routers:
o shouldParseCounter()
o shouldThrowExceptionForParseCounter()
o shouldThrowExceptionBecauseOfLackOfBGRouter()
o shouldThrowExceptionBecauseOfLackOfLinks()
o shouldCalculateCounterValues()
DARouterCounterCollectorThreadTest contains following test methods for
collecting counter values from specific interfaces of DA routers:
o shouldParseCounter()
o shouldThrowExceptionForParseCounter()
o shouldThrowExceptionBecauseOfLackOfDARouter()
o shouldThrowExceptionBecauseOfLackOfTunnels()
o shouldCalculateCounterValues()
SNMPWrapperTest contains following test methods for SNMP4J library wrapper
class named SNMPWrapper:
o shouldThrowExceptionForTimedOutForSnmpget()
o shouldThrowExceptionForNullResonseForSnmpget()
o shouldThrowExceptionBecauseOfErrorForSnmpget()
o shouldStarClient()
o shouldStopClient()
o shouldNotStopClient()
o shouldPrepareTargetForTheAddressWithPort()
o shouldThrowExceptionBecauseOfSnmpSendException()
Version 1.0
Page 35 of 191

o shouldThrowExceptionBecauseOfLackOfSnmpClient()
SNMPOIDCollectorTest contains following test methods for SNMPOIDCollector
class:
o shouldParseInterfaceNumber()
o shouldSetOutboundInterfaceCounterOID()
o shouldSetInboundInterfaceCounterOID()
o shouldCollectOIDsForLinks()
o shouldCollectOIDsForTunnels()
o shouldThrowExceptionBecauseOfLackOfSnmpWalkResponse()
o shouldThrowExceptionBecauseOfLackOfPhysicalInterfaceName
()
XVectorCalculationTest contains following test methods for link traffic vector
calculation logic implemented by XVectorCalculator class and triggered by
MonitoringDataProcessor class:
o shouldCalculateFirstXVector()
o shouldCalculateSecondXVector()
o shouldCalculateLaterXVector()
o shouldCalculateXVectorEvenIfCounterValueIsLessThanZero()
o shouldCalculateXVectorWithLastXVector()
ZVectorCalculationTest contains following test methods for tunnel traffic
vector calculation logic implemented by ZVectorCalculator class and triggered by
MonitoringDataProcessor class:
o shouldCalculateFirstZVectors()
o shouldCalculateSecondRoundOfZVectors()
o shouldCalculateZVectorsWithLastZVectors()
ZVectorsAggregationTest
aggregation:
contains following test method for Z vector
o shouldAggregateZVectors()
CounterValuesTest contains following test methods for store and get methods
of CounterValue class:
o shouldStoreOneLinkAndTunnelEntry()
o shouldStoreTwoEntries()
o shouldReplaceOneOfTwoEntries()
o shouldValidateTwoCounterValueInstancesAsEqual()
o shouldAddCounterValueToExistingEntry()
o shouldCreateNewEntryWhenAddingCounterValue()
o shouldConverToListOfLocalVectorValues()
Page 36 of 191
Version 1.0


MonitoredLinksInventoryTest contains following test method for population

and data retrieval methods of MonitoredLinksInventory data container class:
o shouldPopulateInventory()
MonitoredTunnelsInventoryTest contains following test methods for
population and data retrieval methods of MonitoredTunnelsInventory data container
class:
o shouldPopulateInventoryAndExecuteQueries()
o shouldPopulateInventoryWithSomeTunnelsAtBGRouters()
BGRouterTunnelTest contains following test method for tunnels terminated at
BG routers:
o
shouldFetchDataForTunnels()
QoaLogicTest contains following test method for analyzing Quality of Service

Analyzer component logic:
o shouldSendProperXAndZVectors()
SNMPTrafficCollectorSupportFor95thPercentileTest
following test method for 95th percentile charging rule:
contains
o shoulNotifyNewCounterValuesFor95thPercentile()
ExtendedCounterValuesTest
ExtendedCounterValues class:
contains
following
test
methods
for
o shouldStoreOneLinkAndTunnelEntry()
o shouldReplaceOneOfTwoEntries()
o shouldCalculateDifference()
FileManagerTest contains following test method for operations allowing file
updates:
o shouldCreateFile()
LogToFileTest contains following test method for traffic details log generation
and storage to file:
o shouldLogToFile()
LogToFileWithBGRouterTunnelsTest contains following test method for
traffic details log generation in case when tunnels are terminated at BG routers:
o shouldLogToFile()
TrafficDetailsWriteToFileTest contains following test method for traffic
details log generation:
o shouldWriteTrafficDetailsToFile()
5.1.2 Network Traffic Manager
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
Version 1.0
Page 37 of 191

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 using the algorithm specified in Section 5.1.2.2.1;
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;
(if delay tolerant traffic management is enabled) at the beginning of new accounting
period configures policers on the underlying BG routers with bandwidth limits for
each link;
when informed by the Economic Analyzer during an accounting period that on
some links the reference vector has been already achieved undertakes appropriate
actions: calculates next compensation vectors according to the algorithm specified
in Section 5.1.2.2.2 and (if delay tolerant traffic management is enabled)
deactivates filters on given links on BG routers till the end of current accounting
period.
When considering SBox located at the data traffic sender end of an inter-DC
communication, the NTM is responsible for:
initial configuration of the underlying SDN controllers (by means of SBox-SDN
Client) with information about tunnels established between local and remote DCs,
corresponding DA router ports and remote DC prefixes;
receive compensation and reference vectors from the Inter-SBox Communication
Service server and distributing them to the SDN controllers that will distribute the
outgoing traffic among all configured tunnels accordingly.
The NTM component supports two traffic charging rules defined in the system, namely the
total traffic volume based rule and the 95th percentile rule.
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.
5.1.2.1 Interfaces
The Network Traffic Manager provides in total 5 methods to be called by other SBox
components. Three of them are implemented by DTMTrafficManager class:
public
void
updateXVector(XVector
xVector)
throws
IllegalArgumentException: Method called by QoS Analyzer to update
information about link traffic vector calculated every reporting period.
o Input parameters:
xVector: New link traffic vector
Page 38 of 191
Version 1.0


o Thrown exceptions:
IllegalArgumentException when given xVector argument is invalid
public
void
updateRVector(LocalRVector
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
IllegalArgumentException when given rVector argument is invalid
public
void
updateLinksWithRVectorAchieved(int
asNumber,
List<LinkID> links) throws IllegalArgumentException: Method
called by Economic Analyzer to update information about inter-domain links in
given AS for which the reference vector has been already achieved in the current
accounting period.
o Input parameters:
asNumber: Number of the AS to which provided links belong
links: List of inter-domain links
IllegalArgumentException when provided list is null or empty
The
remaining
two
interface
methods
are
implemented
by
DTMRemoteVectorsReceiver class and are called by Inter-SBox Communication
Service server component.
public
void
receive(CVector
cVector)
throws
IllegalArgumentException: Method called to update information about
compensation vector calculated every reporting period in remote SBox.
o Input parameters:
cVector: Compensation vector calculated in remote SBox
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 SBox.
o Input parameters:
cVector: Compensation vector calculated in remote SBox
rVector: Reference vector calculated in remote SBox
Version 1.0
Page 39 of 191

IllegalArgumentException when either of given vector arguments is

invalid
5.1.2.2 Design
The NTM component implementation consists of 25 classes. Its main functionalities fall
into two areas related with reacting on incoming traffic volumes by providing compensation
and reference vectors to remote SBoxes and adapting BG routers configuration for delay
tolerant traffic handling as well as 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 14 and Figure 19, respectively.
In Figure 13 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
Page 40 of 191
Version 1.0


and reference vectors calculated every reporting and accounting period,

respectively. Additionally Economic Analyzer may inform DTM that for some links
the reference vector is already achieved in current accounting period what triggers
appropriate operations.
o public void initialize(): Method that should be invoked during
component initialization to set initial values to control variables, populate
internal structures with data loaded from the Database as well as load a
default reference vector from file (if such exists).
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(LocalRVector rVector) throws
update information about reference vector calculated every accounting
period. Link traffic vector value for given AS is reset. Also, if delay tolerant
traffic management is enabled, policer limits are configured on BG routers
for the next accounting period. Triggers subsequent actions in a new thread.
o public void updateLinksWithRVectorAchieved(int asNumber,
List<LinkID> links) throws IllegalArgumentException: DTM
external interface method used to update the list of inter-domain links for
which the number of collected 95th percentile traffic samples with values
less than the reference vector value calculated for that link is greater than
95% of the number of all samples collected during a single accounting
period. For those links any configured bandwidth limits should be disabled till
the end of current accounting period since the reference vector is already
guaranteed to be achieved. Also compensation vector calculation algorithm
is adapted to current situation.
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
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
Version 1.0
Page 41 of 191

calculated every reporting and accounting period, respectively in remote

SBox.
Figure 13: NTM partial class diagram: top level.

In Figure 14, 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,
LocalRVector
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.
o public VectorProcessingThread(List<SBox> remoteSboxes):
The constructor with one argument. The compensation vector is calculated
outside of this thread and sent to given list of SBoxes.
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
CVectorProcessingThread(XVector
xVector,
LocalRVector
rVector,
List<SBox>
remoteSboxes): The
constructor with arguments.
o public CVectorProcessingThread(XRVectorPair vectorPair,
List<SBox> remoteSboxes): The constructor with arguments.
o public CVectorProcessingThread(CVector preparedCVector,
List<SBox> remoteSBoxes): The constructor with arguments.
Page 42 of 191
Version 1.0


o public void run(): Method launched when thread is started. Constructs

compensation vector with CVectorConstructor or uses already prepared
vector and sends it to remote SBoxes using an instance of
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
CRVectorProcessingThread(XVector
xVector,
LocalRVector
rVector,
List<SBox>
remoteSboxes): The
constructor with arguments.
o public CRVectorProcessingThread(XRVectorPair vectorPair,
List<SBox> remoteSboxes): The constructor with arguments.
o public void run(): Method launched when thread is started. Constructs
compensation vector with CVectorConstructor and sends both vectors to
remote SBoxes using instance of DTMVectorsSender.
CVectorConstructor: Constructs compensation vector from values calculated
by CVectorValuesCalculator.
o public CVector construct(XVector xVector, LocalRVector
rVector): Constructs new compensation vector based on provided
arguments:
link
traffic
vector
and
reference
vector.
Uses
CVectorValuesCalculator to calculate vector values.
CVectorValuesCalculator:
calculation logic.
Implements
compensation
vector
values
o public
CVectorValuesCalculator(XVector
xVector,
LocalRVector rVector): The constructor with arguments: link traffic
vector and reference vector to be used during calculation.
o public
List<LocalVectorValue>
compensation vector values.
calculate():
Calculates
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.
Version 1.0
Page 43 of 191

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.
CVectorHistory: Stores information about compensation vectors calculated over
time. Implements static methods for storing, retrieving and displaying entries
represented by CVectorHistoryEntry.
o public synchronized static void storeInHistory(CVector
vector): Stores information about new compensation vector encapsulated
in CVectorHistoryEntry object.
o public static List<CVectorHistoryEntry> entries(): Returns
all entries from the history.
CVectorHistoryEntry: Encapsulates CVector class object in order to be placed
in CVectorHistory.
o public CVectorHistoryEntry(CVector vector): The constructor
with arguments.
CVectorUpdateController: Implements compensation vector updates handling
logic. If the controller is activated, compensation vector updates are sent to remote
SBoxes only if required and not necessarily every time new vector is calculated.
Updates are sent periodically according to the value of the compensation period
defined in the TimeScheduleParameters class as well as if the current vector differs
significantly from the one previously sent. Moreover, if certain conditions are met,
i.e. the reference vector on specific links is already achieved in the current
accounting period, the controller itself calculates new compensation vectors
according to specific algorithm.
o public
static
CVectorUpdateController
getInstance():
Returns the single existing instance of the controller. If such instance does
not yet exists it is created.
o public static void activate(): Activates the controller.
o public static void deactivate(): Deactivates the controller.
o public
synchronized
boolean
updateRequired(CVector
cVector): Method checks whether it is required to send an update of given
compensation vector to remote SBoxes. It checks if the compensation period
elapsed, or if the values of current compensation vector in comparison with
the one previously sent meet some predefined conditions.
o public void increaseCount(): Method called after each reporting
period.
o public void sent(CVector cVector): Method called to inform about
new compensation vector that was just sent. This vector is stored as the
previous vector for given AS.
o public void reset(): Method called to reset stored values when new
accounting period begins.
Page 44 of 191
Version 1.0


o public
boolean
isCVectorPreparedByController(int
asNumber): Checks if there are already some links in given AS for which
the R vector is already achieved. This would mean that the compensation
vector for given AS should be calculated by the CVectorUpdateController.
o public CVector prepareCVector(int asNumber, LocalRVector
rVector): Calculates and returns proper compensation vector to be used
for given AS. This method should be called if at least one link in given AS
has the reference vector already achieved.
o public void updateLinksWithRVectorAchieved(int asNumber,
List<LinkID> links): Updates the list of links with R vector achieved in
given AS.
DelayTolerantTrafficManager: Uses NetConfWrapper class to execute
operations related with delay tolerant traffic management requested by the
DTMTrafficManager.
o public
void
updatePolicerLimitsOnLinks(LocalRVector
rVector): Sets bandwidth limits for hierarchical policer to be used during
next accounting period. Target router and interface details with new
bandwidth limit values are retrieved from the given reference vector.
o public void deactivateFiltersOnGivenLinks(List<LinkID>
links): Updates locally stored list of links for which filters should be
deactivated and triggers proper operations on routers using
NetConfWrapper.
o public void activateFiltersOnAllLinks(): Activates filters on all
links on which they have been previously deactivated.
NetConfWrapper: Implements router configuration operations by means of
NETCONF protocol.
o public static NetConfWrapper build(BGRouter bgRouter):
Returns an instance of NetConfWrapper configured based on the provided
BGRouter class instance.
o public boolean updatePolicerConfig(String interfaceName,
long bandwidthLimit): Redirects the operation execution to another
method providing default value of burst size limit.
o public boolean updatePolicerConfig(String interfaceName,
long
bandwidthLimit,
long
burstSizeLimit):
Updates
hierarchical policer configuration on an interface with given values of
bandwidth limit and burst size limit.
o public
boolean
activateHierarchicalFilter(String
interfaceName): Activates hierarchical filter on given router interface.
o public
boolean
deactivateHierarchicalFilter(String
interfaceName): Deactivates hierarchical filter on given router interface.
RemoteSBoxContainer: Data container class used to store SBox objects
representing SBoxes in remote ASs from which traffic is sent to the local AS. Those
SBoxes are grouped on per local AS number basis.
Version 1.0
Page 45 of 191

o public void populateFromDB(): Populates structure containing

SBoxes grouped on per local AS basis with data loaded from data base.
o public List<SBox> getRemoteSBoxes(int asNumber): Returns list
of remote SBoxes (with no duplicates) for given AS obtained based on
existing inter-DC communications.
VectorsContainer: Data container class used to store XVector and
LocalRVector objects representing link traffic vectors and reference vectors
organized in pairs (XRVectorPair class) by AS number.
o pu 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(LocalRVector
rVector): Stores new reference vector (LocalRVector) 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
LocalRVector) representing link traffic vector and reference vector, respectively.
o public
XRVectorPair(XVector
xVector,
LocalRVector
rVector): The constructor with arguments that sets both vectors. These
vectors can be later on retrieved with appropriate getter method.
o public boolean areBothVectorsSet(): Checks whether both vectors
comprising the pair are 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.
Page 46 of 191
Version 1.0


Figure 14: NTM partial class diagram: traffic receiver side.

Sequence diagrams in Figure 15 and Figure 16 present the NTM interactions with other
SBox components after reporting period in two cases depending on whether the reference
vector is already achieved on one or both links in given AS.
Presented actions are related to the NTM operations performed on the traffic receiving
side of inter-DC communication.
After reporting period elapses, in typical situation presented in Figure 15, the
DTMQoSAnalyzer updates DTMTrafficManager with a new X vector value. This
Version 1.0
Page 47 of 191

triggers the execution of CVectorProcessingThread which constructs a new C vector

using CVectorConstructor. When CVectorUpdateController confirms that
compensation vector update is required the DTMVectorSender is instructed to send the
new value to a remote SBox. InterSBoxClient is called to perform the actual C vector
transfer.
Figure 16 presents the specific situation mentioned above. After reception of the new X
vector DTMTrafficManager asks the CVectorUpdateController if it will prepare the
new compensation vector instead of the CVectorConstructor. In this case the answer
is positive so the C vector is retrieved from the CVectorUpdateController and passed
to CVectorProcessingThread and later on sent to a remote SBox.
Figure 15: NTM sequence diagram after reporting period: traffic receiver side.
Figure 16: NTM sequence diagram after reporting period: traffic receiver side (R vector
achieved on a link).
After
accounting
period
elapses
(as
presented
in
Figure
17)
the
EconomicAnalyzerInternal updates DTMTrafficManager with a new R vector
value. In turn DTMTrafficManager requests DelayTolerantTrafficManager to
update policer limits on BG router interfaces corresponding to the inter-domain links with
new values calculated from the reference vector that will be used during next accounting
period. Moreover hierarchical filters on all those interfaces should be activated since they
Page 48 of 191
Version 1.0


may have been deactivated during the last accounting period. The NetConfWrapper is
used to execute these requests on the routers using the NETCONF protocol [19]. This
also 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.
Figure 17: NTM sequence diagram after accounting period: traffic receiver side
During the accounting period the EconomicAnalyzerInternal may also update the
DTMTrafficManager with a list of inter-domain links on which the reference vector is
already achieved. This triggers appropriate actions presented in Figure 18.
DTMTrafficManager requests DelayTolerantTrafficManager to deactivate
hierarchical filter for specific links what is later on executed by the NetConfWrapper.
Information about the links is also sent to the CVectorUpdateController.
Figure 18: NTM sequence diagram: update of list of links with R vector achieved.
In Figure 19, a partial NTM class diagram is presented with the following classes
(DTMRemoteVectorsReceiver class was already described in the previous paragraph):
SDNControllerConfigBuilder: Prepares ConfigData class object specific for
given SDN controller based on DC2DCCommunication objects stored in the data
base.
Version 1.0
Page 49 of 191

o public
static
ConfigData
prepareConfig(SDNController
controller): Method prepares configuration data for given SDN
controller.
SDNConfigPusher: Implements methods that forward requests for SDN controller
vector information update or configuration to the SboxSdnClient component.
o public SDNConfigPusher(Set<SDNController> controllers):
The constructor with arguments: set of SDN controllers to which subsequent
requests called on this object will be directed.
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 pub 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.
DAOFactory: Static factory class used to obtain an instance of specific DAO class.
Contains a set of static methods that return locally stored instances of DAO
classes. Following DAO classes are supported: DC2DCCommunicationDAO,
Page 50 of 191
Version 1.0


SystemControlParametersDAO,
LinkDAO.
TimeScheduleParametersDAO,
ASDAO
and
Figure 19: NTM partial class diagram: traffic sender side.

The sequence diagram in Figure 20 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
prepared
by
the
SDNControllerConfigBuilder. 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.
Version 1.0
Page 51 of 191

Figure 20: NTM simplified sequence diagram: traffic sender side.

5.1.2.2.1
First compensation vector calculation algorithm
Following is the first, primary compenstation vector calculation algorithm presented in form
of a pseudocode. This algorithm uses as input information about current, aggregated link
traffic vector and reference vector. It is used in the case when on none of the links in a
given AS the reference vector is yet achieved.
factor=(xVector(1)+xVector(2))/(rVector(1)+rVector(2));
for(each link) {
cVector(k)=factor*rVector(k)xVector(k);
}
5.1.2.2.2
Second compensation vector calculation algorithm
The second algorithm presented below is used only in specific situation in which at some
time during the accounting period the reference vector is already achieved on one or both
links as indicated by the Economic Analyzer. This algorithm is used only in the case when
95th percentile based traffic charging rule is enabled. It uses information about either
reference vector or previous compensation vector to direct all the traffic to a single link on
which the reference vector is already achieved or to distribute the traffic equally if vector is
already achieved on both links.
// flagSamplesBelowR information received from Economic Analyzer; if equal to
1 for given link (link ids: 0 or 1) indicates that on this link the R vector is
achieved;
// flagSamplesBelowRActivated information stored locally; if equal to 1 for
given link (link ids: 0 or 1) indicates that information about the R vector
Page 52 of 191
Version 1.0


achieved on this links was already received and this link is already treated
accordingly;
if(flagSamplesBelowRActivated[1]==0 && flagSamplesBelowR[1]==1) {
cVector(1)=100*(rVector(1)+rVector(2));
cVector(2)=-100*(rVector(1)+rVector(2));
flagSamplesBelowRActivated[1]=1;
}
else if (flagSamplesBelowRActivated[2]==0 && flagSamplesBelowR[2]==1) {
cVector(1)=-100*(rVector(1)+rVector(2));
cVector(2)=100*(rVector(1)-rVector(2));
flagSamplesBelowRActivated[2]=1;
}
else if(flagSamplesBelowRActivated[1]==1 && flagSamplesBelowRActivated[2]==1) {
cVector[1]=-previousCVector[1];
cVector[2]=-previousCVector[2];
}
5.1.2.3 Tests
In order to test the DTM features provided by the NTM component a set of 18 test classes
was implemented comprising JUnit [19] tests for not only particular single methods or
group of methods but also simple workflows internal to NTM component. Mockito library
[21] 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).
Test classes are grouped in three packages.
There is one class in the eu.smartenit.sbox.ntm package.
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()
There are 13 test classes in eu.smartenit.sbox.ntm.dtm.receiver package.
These classes include tests of DTM features running in the NTM in the SBox deployed in
the traffic receiving domain.
Version 1.0
Page 53 of 191

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()
o shouldThrowExceptionOnInvalidVectorValuesListArgument()
o shouldSkipCalculationAfterXVectorUpdate()
o shouldCalculateCAndUpdateCVectorNoCVectorUpdateControlle
r()
o shouldCalculateCAndUpdateCVectorWithCVectorUpdateControl
ler()
XVectorUpdateChargingRuleTest contains following test methods for
workflow triggered by the DTMTrafficManager class after receiving updated link
traffic vector from QoS Analyzer for both charging rules:
o shouldDistributeCVectorChargingRule95thNoController()
o shouldDistributeCVectorChargingRule95thWithController()
o shouldDistributeCVectorChargingRuleVolume()
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()
o shouldDistributeCVectorBeforeAccountingPeriodEndSingleXV
ector()
o shouldDistributeCVectorBeforeAccountingPeriodEnd()
o shouldDistributeCVectorBeforeAccountingPeriodEndWithCVec
torController()
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()
o shouldCalculateCAndUpdateCRVectorsAfterRVectorUpdate()
CVectorValuesCalculatorTest
compensation
vector
values
CVectorValuesCalculator class:
contains following
calculation
logic
test methods
implemented
for
in
o shouldCalculateFromTwoDimentionVectors()
o shouldCalculateWithOneXVectorValueZero()
Page 54 of 191
Version 1.0


o shouldCalculateWithEqualRAndXVectorValuesRatio()
o shouldCalculateWithAllXVectorValuesZero()
o shouldCalculateWithXVectorEqualRVector()
o shouldCalculateFromFiveDimentionVectors()
CVectorConstructorTest contains following test methods for compensation
vector construction from values calculated by the CVectorValuesCalculator class:
o shouldConstructCVector()
o shouldThrowIAESinceXVectorNull()
o shouldThrowIAESinceRVectorNull()
o shouldThrowIAESinceBothVectorsNull()
o shouldThrowIAESinceInvalidVectorSize()
o shouldThrowIAESinceVectorSizeBelowTwo()
o shouldThrowIAESinceInvalidLinkIDs()
CVectorUpdateControllerTest
compensation
vector
updates
CVectorUpdateController class:
contains following test methods

management
logic
implemented
for
in
o shouldUpdateAfterCompensationPeriod()
o shouldUpdateFirstCVector()
o shouldUpdateOnThresholdExceeded()
o shouldNotUpdateThresholdNotExceeded()
o shouldUpdateControllerNotActivated()
DelayTolerantTrafficManagementTest contains following test methods for
functionalities related with delay tolerant traffic management:
o shouldTriggerPolicerConfUpdates()
o shouldNotTriggerPolicerConfUpdates()
o shouldThrowExceptionOnNullListOfLinks()
o shouldDeactivateAndActivateFiltersOnGivenLinks()
LinksWithRVectorAchievedHandlingTest contains following test methods
for functionalities related with handling links with reference vector achieved:
o shouldReturnProperStatusOfCVectorPreparation()
o shouldReturnPreparedCVector()
o shouldThrowExceptionOnInvalidASNumber()
o shouldThrowExceptionOnRVectorNull()
o shouldThrowExceptionOnInvalidRVector()
o shouldThrowExceptionOnInvalidASNotFound()
o shouldThrowExceptionOnInvalidASWithZeroLinks()
Version 1.0
Page 55 of 191

NetConfWrapperTest contains following test methods for all device configuration

operations that are supported by the NetConfWrapper class:
o shouldActivateFilter()
o shouldDeactivateFilter()
o shouldSetBandwidthLimit()
o shouldReturnFalseOnDeviceNull()
LoadingDefaultRVectorDuringInitTest contains following test methods for
loading default reference vector from file specified in SBox configuration file:
o shouldLoadCorrectRVectorAndUpdateRemoteSBox()
o shouldNotUpdateRemoteSBoxWhenRVectorFileNotExists()
VectorsContainerTest contains following test methods for store and load
methods of VectorsContainer class:
o shouldCreateNewPairOnEmptyContainerWithUpdatedXVector()
o shouldCreateNewPairWithUpdatedXVector()
o shouldCreateNewPairOnEmptyContainerWithUpdatedRVector()
o shouldCreateNewPairWithUpdatedRVector()
o shouldAccumulateAndUpdateExistingPairWithUpdatedXVector(
)
o shouldResetXVectorValuesInExistingPair()
o shouldUpdateExistingPairWithUpdatedRVector()
o shouldReturnNullIfAsNumberIsNotSet()
RemoteSBoxContainerTest contains following test method for populate and get
methods of RemoteSBoxContainer class:
o shouldPopulateContainerStructures()
There are 4 test classes in eu.smartenit.sbox.ntm.dtm.sender package. These
classes include tests of DTM features running in the NTM in the SBox deployed in the
traffic sending domain.
RemoteVectorsUpdateTest contains following test methods for workflow
triggered by DTMRemoteVectorsReceiver class after receiving new compensation
and reference vectors from remote SBoxes:
o shouldProcessAndUpdateAfterRemoteCVectorReceived()
o shouldProcessAndUpdateAfterRemoteCAndRVectorsReceived()
o shouldProcessAndUpdateAfterMultipleRemoteCAndRVectorsRec
eived()
o shouldProcessAndNotUpdateWhenNoSDNControllers()
o shouldThrowExceptionOnCVectorNull()
o shouldThrowExceptionOnRCVectorsNull()
o shouldThrowExceptionOnInvalidCVectorASNumberArgument()
Page 56 of 191
Version 1.0


o shouldThrowExceptionOnInvalidCRVectorASNumberArgument()
o shouldThrowExceptionOnInvalidCVectorValuesListArgument()
o shouldThrowExceptionOnInvalidCRVectorValuesListArgument(
)
SDNControllerContainerTest contains following test method for store and
load methods of SDNControllerContainer class:
o shouldPopulateContainerStructures()
SDNControllersConfigTest contains following test methods for the SDN
Controllers configuration process launched during DTMRemoteVectorsReceiver
class initialization:
o shouldInitControllers()
o shouldConstructProperConfigData()
ThetaCoefficientHandlerTest contains following test methods for the logic
implemented in ThetaCoefficientHandler class:
o shouldReturnTheSameCVectorIfThetaNull()
o shouldReturnTheSameCVectorIfThetaNotNull()
5.1.3 Economic Analyzer
The Economic Analyzer (EA) component works out the strategy for inbound traffic
distribution between inter-domain links for the next accounting period. This distribution is
represented in a compact form of the reference vector. EA creates a cost map for traffic at
the end of the accounting period and predicts the possible optimal traffic pattern (the
expected traffic amount on each inter-domain link which minimizes the total cost of
transfer via these links). This information forms the basis for the reference vector
calculation. Each reference vector component represents expected traffic amount on a
particular inter-domain link. Each time a new reference vector is calculated it is sent to the
NTM for calculation of compensation vectors and distribution to remote domains in which
sources of traffic are located.
The EA receives information about the amount of traffic transmitted through each interdomain link during the accounting period from the QoS Analyzer (which collects values of
appropriate traffic counters from BG and DA routers) in the form of link traffic and tunnel
traffic vectors.
The EA component supports two traffic charging rules defined in the system, namely the
total traffic volume based rule and the 95th percentile rule. Depending on the charging
rule, the traffic samples are received from QoS Analyzer at different intervals. Typically
when total traffic volume based rule is enabled traffic vectors are received every 30
seconds. On the other hand, in the case of 95 th percentile rule, traffic updates are
received every 5 minutes what corresponds to the 95 th traffic sample collection time. Also
according to the currently enabled charging rule traffic samples are processed,
accumulated and stored differently.
If the 95th percentile charging rule is enabled, during accounting period EA counts for
each link traffic samples with values less than the value of reference vector component for
Version 1.0
Page 57 of 191

that link. If the number of such samples reaches 95% of all samples collected during an
accounting period it is certain that the reference vector for given link will be achieved in
current period. This information is sent to the NTM so that compensation vectors are
calculated differently since the whole traffic can from now on be sent to the given link.
5.1.3.1 Interfaces
The Economic Analyzer provides one interface method to be called by other SBox
component. The following method is implemented by the EconomicAnalyzer class.
public void updateXZVectors(XVector xVector, List<ZVector>
zVectors): Method called by QoS Analyzer to update information about link traffic
vector and tunnel traffic vectors.
o Input parameters:
xVector: New link traffic vector
zVectors: New list of tunnel traffic vectors
5.1.3.2 Design
The Economic Analyzer consists of 10 top level classes. Figure 21 presents all the
involved classes with selected relationships between them.
Following is the description of those classes:
EconomicAnalyzer: Main class of the Economic Analyzer. Implements external
interface method used by the QoS Analyzer to update traffic information. Uses
EconomicAnalyzerInternal to handle traffic samples and trigger actions within a
single Autonomous System.
o EconomicAnalyzer(DTMTrafficManager
dtmTrafficManager):
The constructor with arguments. Takes in the DTM Traffic manager instance
as the input variable in order to proceed to the following methods eventually.
o void
X_in,
List
<ZVector>
Z_in_list): Economic Analyzer external interface method used to update
information about link traffic vector and tunnel traffic vectors.
EconomicAnalyzerInternal: Class that implements Economic Analyzer
operations within a single Autonomous System.
o EconomicAnalyzerInternal(DTMTrafficManager
dtmTrafficManager,
SimpleLinkID
link1,
SimpleLinkID
link2): The constructor with arguments: instance of DTMTrafficManager
(that should be updated once new reference vector is calculated or on some
link the reference vector is achieved) and identifiers of two considered interdomain links.
o void
xVector,
List<ZVector>
zVectors): Updates link and tunnel traffic data. If accounting period
elapsed, calculates new reference vector and sends is to configured NTM
instance. Updates NTM with a list of links on which the R vector has been
already achieved in the current accounting period.
Page 58 of 191
Version 1.0


TrafficSamplesContainer: Base class for traffic data containers used by

EconomicAnalyzerInternal to store data received from QoS Analyzer.
o public
TrafficSamplesContainer(SimpleLinkID
link1,
SimpleLinkID link2): The constructor with arguments: identifiers of two
inter-domain links.
o public abstract void storeTrafficValues(XVector xVector,
List<ZVector> zVectors): Stores traffic values from report/sample.
o public abstract void resetTrafficValues(): Resets aggregated
traffic information (after the accounting period has expired).
o public abstract long[] getTrafficValuesForLinks(): Returns
a vector of link traffic samples to be used in reference vector calculation.
o public
abstract
long[]
getTrafficValuesForTunnels():
Returns a vector of tunnel traffic samples to be used in reference vector
calculation.
TotalVolumeSamplesContainer: Container for accumulated traffic samples.
Extends TrafficSamplesContainer class.
o public TotalVolumeSamplesContainer(SimpleLinkID link1,
SimpleLinkID link2): The constructor with arguments: identifiers of two
inter-domain links.
List<ZVector> zVectors): Accumulates and stores link and tunnel
traffic values.
o public abstract void resetTrafficValues(): Resets aggregated
traffic information (after the accounting period has expired).
o public abstract long[] getTrafficValuesForLinks(): Returns
a vector of link traffic values to be used in reference vector calculation.
These values correspond to traffic accumulated over the whole accounting
period.
o public
abstract
long[]
Returns a vector of tunnel traffic samples to be used in reference vector
calculation. These values correspond to traffic accumulated over the whole
accounting period.
The95PercentileSamplesContainer: Container for 95th percentile traffic
samples. Extends TrafficSamplesContainer class.
o public
The95PercentileSamplesContainer(SimpleLinkID
link1, SimpleLinkID link2): The constructor with arguments:
identifiers of two inter-domain links.
o public
The95PercentileSamplesContainer(SimpleLinkID
link1,
SimpleLinkID
link2,
int
samplesInAccountingPeriod): The constructor with arguments:
identifiers of two inter-domain links and the number of samples collected
during entire accounting period.
Version 1.0
Page 59 of 191


List<ZVector> zVectors): Stores link and tunnel traffic values. Checks
if for some links the reference vector is already achieved.
o public abstract void resetTrafficValues(): Resets structures
holding traffic samples and other supporting fields (after the accounting
period has expired).
o public
abstract
long[]
getTrafficValuesForLinks():
Calculates and returns 95th percentile traffic samples for all links.
o public
abstract
long[]
Calculates and returns 95th percentile traffic samples for all tunnels.
o public
boolean
isChangeInLinksWithRVectorAchieved():
Checks whether after storing latest traffic samples the reference vector was
achieved on new link or links.
o public List<LinkID> getLinksWithRVectorAchieved(): Returns
current list of links on which the reference vector has been achieved.
o public void setCurrentRVector(LocalRVector rVector): Sets
reference vector to be used to determine the number of traffic samples with
values less than the reference vector component value.
o public
The95thPercentileSamplesHistory
getHistory():
Returns the whole history of traffic samples stored in previous accounting
periods.
ReferenceVectorCalculator: Implements the reference vector calculation
algorithm.
o public
ReferenceVectorCalculator(SimpleLinkID
link1,
SimpleLinkID link2, List<CostFunction> costFunctions,
TimeScheduleParameters
timeScheduleParameters):
The
constructor with arguments: identifiers of two links, cost functions used on
those links and additional control parameters.
o LocalRVector calculate(long[] X_V, long[] Z_V, int
sourceAsNumber): Calculates the reference vector for AS from given
aggregated traffic values.
DInterval: Represents an interval bounded by two alpha end points.
o DInterval(long lowerBound, long upperBound): The constructor
with arguments. Creates a DInterval class instance for a given set of lower
and upper bounds.
o boolean contains(long x): Returns true if the parameter value passed
as an argument is contained within the two bounds (including boundaries).
o long getLowerBound(): Returns the lower bound of the interval.
o long getUpperBound(): Returns the upper bound of the interval.
Area: Represents the intervals which make up an area.
Page 60 of 191
Version 1.0


o Area(DInterval d1, DInterval d2): The constructor with arguments

that is responsible for creating an Area object.
o DInterval getD1(): Returns the interval on the x1 axis.
o DInterval getD2(): Returns the interval on the x2 axis.
The95thPercentileSamplesHistory: Stores 95th percentile traffic samples
collected during past accounting periods.
o public void store(Map<SimpleLinkID, List<TrafficSample>>
linkTrafficSamples,
Map<SimpleLinkID,
List<TrafficSample>> tunnelTrafficSamples): Adds new entry to
the history.
o public List<Entry> getEntries(): Returns the whole history.
DAOFactory: Static factory class used to obtain an instance of a specific DAO
class. Contains a set of static methods that return locally stored instances of DAO
classes.
Following
DAO
classes
are
supported:
CostFunctionDAO,
SystemControlParametersDAO and TimeScheduleParametersDAO.
Figure 21: Economic Analyzer class diagram.
Version 1.0
Page 61 of 191

Sequence diagram in Figure 22 presents Economic Analyzer interactions with other SBox
components, namely QoS Analyzer and Network Traffic Manager.
Periodically the QoS Analyzer updates EA with new link and tunnel traffic vectors
calculated from traffic counters values collected over some period of time (e.g. 5 minutes).
For this purpose an interface method of EconomicAnalyzer class is used. New vectors
are passed to an instance of EconomicAnalyzerInternal corresponding to the AS for
which traffic vectors were prepared. EconomicAnalyzerInternal uses one of two
container classes to store traffic samples depending on the charging rule enabled in the
system. Sequence diagram depicts the workflows assuming that the 95th percentile based
rule is used. Please note that only a subset of presented messages is exchanged in the
case when total traffic volume charging rule is in use. During the accounting period,
EconomicAnalyzerInternal
stores
received
traffic
data
in
The95thPercentileSamplesContainer and checks whether there are some new
links on which the reference vector has been already achieved. If yes, new list of
identifiers of such links is sent to an instance of DTMTrafficManager. After the
accounting period, EconomicAnalyzerInternal retrieves the 95th percentile traffic
samples from the container and passes them to ReferenceVectorCalculator for
reference vector calculation. Finally new reference vector is sent to
DTMTrafficManager.
Figure 22: Economic Analyzer sequence diagram.
Page 62 of 191
Version 1.0


5.1.3.2.1
Reference vector calculation algorithm
The main responsibility of the Economic Analyzer component is the periodical calculation
of reference vector after each accounting period. The detailed description of the algorithm
is available in section 6.1.3.3.1 of Deliverable 3.2 [2].
5.1.3.3 Tests
In order to test the DTM features provided by the Economic Analyzer component a set of
6 test classes was implemented.
Those classes with their test methods are listed below (please note that all provided
names of test methods are preceded with public void in the source code):
ReferenceVectorCalculationTest contains following test methods for
reference vector calculation logic implemented by the ReferenceVectorCalculator
class.
o firstTestData()
o secondTestData()
o thirdTestData()
o fourthTestData()
o fifthTestData()
o sixthTestData()
o seventhTestData()
o eightTestData()
o ninthTestData()
o tenthTestData()
o eleventhTestData()
The95thPercentileWorkflowTest contains a test method for workflow
triggered by the EconomicAnalyzer after receiving updated link and tunnel traffic
vectors in the case the ChargingRule.the95thPercentile is enabled.
o shouldCalculateRefVectorAfterAccountingPeriod()
TotalVolumeWorkflowTest contains a test method for workflow triggered by the
EconomicAnalyzer after receiving updated link and tunnel traffic vectors in the case
the ChargingRule.volume is enabled.
o shouldCalculateRefVectorAfterAccountingPeriod()
TotalVolumeReportsAggregationTest contains test methods for handling
traffic updates when ChargingRule.volume is enabled. Traffic values are
aggregated during an accounting period and then reset.
o prepareTotalVolumeXVBeforeAccountingPeriod()
o prepareTotalVolumeZVBeforeAccountingPeriod()
o prepareTotalVolumeXVAfterAccountingPeriod()
o prepareTotalVolumeZVAfterAccountingPeriod()
Version 1.0
Page 63 of 191

o asNumberMatch()
o linkIDConsistence()
The95thPercentileSamplesContainerTest tests methods for handling 95th
percentile samples implemented by the The95PercentileSamplesContainer class.
o shouldStoreXAndZVectorTrafficSamples()
o shouldStoreManyXAndZVectorTrafficSamples()
o shouldThrowExceptionOnInvalidInput()
HandlingSamplesBelowRVectorTest contains following test methods for
handling of 95th percentile samples by the The95PercentileSamplesContainer with
the focus on samples with values less than corresponding reference vector
component value.
o shouldStoreSamplesAndHandleSamplesBelowRVector()
o shouldStoreAndHandleDifferentNumberOfSamples()
5.1.4 Inter-SBox Communication Service
The Inter-SBox Communication Service component functionality and design have been
documented in Section 6.1.5 of D3.2 [2] and have not changed since then.
5.1.5 SBox-SDN Communication Service
The SBox-SDN Communication Service component functionality and design have been
documented in Section 6.1.5 of D3.2 [2] and have not changed since then.
5.1.6 Database
The Database (DB) component is responsible both for relational tables creation and the
application connection to the actual database. It is partitioned into the following packages:
dto: Contains all the Data Transfer Objects (DTO) of the database, namely all the
Java classes that correspond to the relational tables of the DB, and some additional
helper entities, which are used by certain components, but are not stored into the
database.
dao: Contains all the Data Access Objects (DAO) one for each table. Each of them
contains the methods provided to external components for reading from or writing
to the corresponding table. The dao package also includes the five subpackages
that follow.
o binders: Contains the binder classes.
o mappers: Contains the mapper classes.
o gen: Contains for each table an abstract class, behaving as interface, with
the actual necessary SQL commands wrapped each from a Java method
which is the one called by the above mentioned DAO method.
o util: Contains auxiliary, utility classes. For the moment it has only the
Tables class which creates and deletes all tables.
Page 64 of 191
Version 1.0


test: Includes the JUnit tests one for each DAO class.
The DB contains the SQL tables described in the Design Subsection 5.1.6.2.
5.1.6.1
Interfaces
The DB component provides its services by exposing for each table a number of methods.
These methods, which reside for each table-entity in the corresponding DAO class,
named <entity-name>DAO, constitute the DB interface to the other components. Each of
these methods wraps up one or more SQL commands, located in the corresponding
Abstract<entity-name>DAO. In the case of multiple SQL commands, these may reside in
more than one Abstract<entity-name>DAO.
There is a set of methods which are implemented by almost all DAOs, while few others
are more specific, more complicated therefore implemented usually by a single (or more
cooperating) DAO. The common methods are briefly described as follows.
public void createTable(): The method that creates the corresponding
table.
public void deleteTable(): The method that deletes the corresponding
table.
public void insert(<entity type> e): The method that inserts an entity
to the corresponding table.
o Input parameter: The entity to be inserted.
public List<entity type> findAll(): The method that finds all the
stored entities from the respective table.
o Returns: The list of stored entities.
public <entity type> findById(<primary-key-type> pk): The
method that finds a stored entity by the corresponding tables primary key.
o Input parameter: The primary key.
o Returns: the entity indexed by the primary key.
public <entity type> findLast(): The method that finds the last stored
entity.
o Returns: The most recent stored entity.
public void update(<entity type> e):The method that updates a stored
entity into its table.
o Input parameter: The entity to be updated.
public void deleteById(<primary-key-type> pk): The method that
deletes a stored entity by its table primary key.
public void deleteAll(): The method that deletes all the stored entities
from the respective table.
Version 1.0
Page 65 of 191

The DAO-specific methods were described in Section 6.1.4.2 of Deliverable 3.2 [2], and
have been enhanced with new fields, which will be presented in the following section.
5.1.6.2
Design
The DB schema contains the following SQL tables depicted in Figure 23:
ASSYSTEM: The table where each Autonomous System is stored. A unique

number that identifies each AS, its ASNUMBER, it is tables primary key.
BGROUTER: The table where the Border Gateway Is stored. The prefix of the router
management IP address is the tables primary key.
CLOUDDC: The table where all the different clouds are stored. The cloud name is
the primary key.
COSTFUNCTION: The table where all the different cost functions are stored. The
pair <local link id, ISP name> is the primary key.
DAROUTER: The table where all the different Datacenter Attached Routers are
stored. The router IP address is the primary key.
DC2DCCOMMUNICATION: The table where the various connections between any

pair of datacenter are stored. Each such pair is uniquely identified by a combination
of 6 parameters: the communication number, the respective symbol, the name of
the local cloud, the name of the remote cloud, the local AS number and the remote
AS number.
ISP: The table where all the different ISPs are stored. The ISP name is the primary
key.
LINK: The table where all the different links are stored. The pair <local link id, ISP
name> is the primary key.
PREFIX: The table where all the different address prefixes we use are stored. An
auto incremented numerical identifier is the primary key.
SDNCONTROLLER: The table where all the different SDN controllers are stored. The
controller address is the primary key.
SEGMENT: The table where all the different segments are stored. An auto
incremented numerical identifier is the primary key.
SYSTEMCONTROLPARAMETERS: The table where the single system control

parameters record is stored. An auto incremented numerical identifier is the primary
key.
TIMESCHEDULEPARAMETERS: The table where the single time schedule

parameters record is stored. An auto incremented numerical identifier is the primary
key.
TUNNEL: The table where all the different tunnels are stored. The pair <local link id,
ISP name> is the primary key.
Page 66 of 191
Version 1.0


Figure 23: SBox database schema.

Figure 24 presents the class diagram for the AS table-related classes. All other entities
conform to the same logic. For this simple case, 5 cooperating classes are involved to
provide read/write access to the respective table in a transparent fashion. Specifically, the
ASDAO class provides the necessary interface to all the other modules, and uses the
respective functions of the AbstractASDAO class, which execute all the SQL queries and
updates. Additional classes, BindAS and ASMapper provide the necessary mapping of
SQL result sets and columns to and from the respective DTO (AS class). The following
description of the aforementioned classes applies to all *, *DAO, Abstract*DAO, Bind*
and *Mapper classes.
AS
o All the ASDAO methods have arguments and/or return value an AS entity
object (the application language). It is the DTO class, therefore contains only
constructors, getters and setters.
ASDAO
Version 1.0
Page 67 of 191

o It is the only interface used by applications either to issue commands to or

receive responses from the database.
All its methods were described in Section 5.1.6.1.
AbstractASDAO
o Belongs to the gen package, contains all SQL queries, each one defines a
java method. These methods only get called from the ASDAO methods. The
ASDAO methods are the ones exposed to any application requesting to read
or write to the database.
BindAS
o Translator from application-entity to the database-table when commands
issued to the DB.
o It is an interface that includes a static class ASBinderFactory which
implements BinderFactory interface i.e a build() method that
instantiate a Binder object for the AS type using the bind() method
whose description follows
public void bind(SQLStatement q, BindAS bind, AS

arg): It maps the parameters of an sql statement in
AbstractASDAO into AS parameters.
ASMapper
o Translator from the database-table to application-entity dialect, when the DB
responds to an issued command, using the below described map method.
ASMapper:
AS
map(int
index,
ResultSet
r,
StatementContext ctx): The method that translates a received
resultset into an AS object.
Input parameter: index The index.
Input parameter: r The received result set.
Input parameter: ctx The statement context.
Returns: The AS object.
Page 68 of 191
Version 1.0


Figure 24: AS table-related class diagram.

5.1.6.3
Tests
The JUnit tests are identical as the ones defined in Section 6.1.4.4 of Deliverable 3.2 [2],
enhanced with assertions verifying new fields.
The User Interface (UI) of the SBox is the module responsible for configuring relevant
parameters for the execution of the DTM mechanism. It is operated by the administrator of
the Network Service Provider, which is also the SBox administrator, and exposes a Web
interface accessible by any Web browser, where the following parameters may be
inserted, modified or deleted:
Local and remote autonomous systems that are involved in DTM mechanism
execution,
Local BG and DA routers,
SDN controllers and their attached routers,
Inter-domain links,
Tunnels,
Local cloud information,
Version 1.0
Page 69 of 191

Remote clouds,
Inter-cloud communications, and,
System and general DTM settings.
5.1.7.1
Interfaces
The User Interface pages were presented in Section 6.1.7 of D3.2 [2] and only a few fields
in certain pages have changed since then.
In the BG and DA routers page (Figure 25), the intra-domain routers can be configured.
BG routers insertion requires the number of the AS they belong, and their username and
password to access them, while both types of routers require their SNMP community.
Besides, DA routers require the OpenFlow switch identifier, as well as their list of ports.
All inter-domain links are configured in the Links page (Figure 26). Link parameters
include: ID, ISP name, IP address, physical interface name, VLAN number, the BG router
it belongs, the tunnel end prefix and a list of Segments (left border, right border, a and b
constants) that comprise its cost function.
In the Tunnels page (Figure 27), the administrator may insert, modify and delete traversing
tunnels. More specifically, information about tunnels name, number, source and
destination end addresses, physical interface name, the local router address and the interdomain link they traverse are expected.
Finally, in the Settings page (Figure 28), required DTM execution parameters are set: the
start date of the DTM execution, and the duration of the accounting, reporting, sampling
and compensation periods. In addition, certain system control parameters can be
configured: the charging rule (95th percentile or volume-based), the operation mode of
SDN controller (proactive or reactive, with or without compensation vector), the
compensation threshold and a Boolean value defining whether the SBox operates with
delay-tolerant traffic management.
Page 70 of 191
Version 1.0


Figure 25: BG and DA routers page.
Version 1.0
Page 71 of 191

Figure 26: Links page.
Page 72 of 191
Version 1.0


Figure 27: Tunnels page.
Version 1.0
Page 73 of 191

Figure 28: DTM settings page.

5.1.7.2
Design
The SBox User Interface is a Web application designed and implemented based on the
Model-View-Controller (MVC) pattern, which defines 3 different but interconnected layers,
in order to separate data representation from business logic. In the generalized case, the
model layer includes all the application data, the view provides their output representation
and finally the controller is the coordinating component receiving user requests, calling
appropriate functions and returning results.
In the SBox User Interface, the model is represented by the Database component, which
consists of all the SBox database tables, their mapping to data transfer objects, as well as
Page 74 of 191
Version 1.0


the data access objects to query and update those tables. The database component was
described with details in Section 5.1.6.
The controller layer is implemented by several *Bean classes, one for each page, which
include all the required functions that:
a) receive users requests and input from the Web application pages,
b) interact with the database and,
c) return output and/or navigate to other pages.
The list of controlling bean classes and their mapping to their controlling page is presented
below:
DashboardBean: Its the session controlling bean, which is initialized on
successful login and terminated when the administrator logs off.
InterDatacenterBean: inter-datacenter communications page
IspBean: autonomous systems page.
LinksBean: links page (Figure 26).
LocalCloudsBean: local clouds page.
RemoteCloudsBean: remote clouds page.
RoutersBean: BG and DA routers page (Figure 25).
SdnControllersBean: SDN controllers page.
SettingsBean: system control DTM parameters page (Figure 28).
TunnelsBean: tunnel page (Figure 27).
Additional classes are also implemented, either providing support and converting functions
used in pages (WebUtils, IntegerListConverter), or managing certain required
functionalities (DB connection handling), when the Web application context is initialized or
terminated (SBoxWebAppListener).
Each *Bean class implements all the required functions to manage its respective page.
Specifically, the Web interface pages are used to insert, edit or remove specific entries
from the respective database tables, e.g. the IspBean manages the ISP and AS tables,
calling the respective DAO methods. Figure 29 presents such an example and is similar to
all *Bean classes.
Figure 30 presents a simple sequence diagram of an AS insertion through the User
Interface, which is triggered when the updateAS function is called. DashboardBean
calls the insert(AS) function of DB components ASDAO class, which subsequently
calls the related method from the AbstractASDAO, which executes the AS table update.
Afterwards, the findAll() is executed, to get all the AS entries and populate the table
presented in the page. The same action applies for all pages and methods defined above.
Version 1.0
Page 75 of 191

Figure 29: IspBean class diagram.
Figure 30: AS insertion sequence diagram

Finally, the view layer consists of all the pages, files and forms for the representation of
existing entries in the SBox database, and users request handling. The list of files is as
follows:
admin/: Its the directory where all Web application pages exist:
o index.xhtml: The home page summarizing the User Interface features.
o interdatacenter.xhtml: The inter-datacenter communications page.
When the user inserts an inter-datacenter communication, the
updateDC2DC of the DashboardBean is called, while the list of stored
DC2DCCommunication entries is rendered. The user can also delete an
inter-datacenter communication by pushing the Delete button, which calls
the deleteDC2DC function. The changeLocalAS and changeRemoteAS
functions are also used to dynamically adjust local and remote AS numbers,
based on users selection of local and remote cloud names respectively.
o isp.xhtml: The autonomous systems page. The user may update the
ISPs name (the updateIspName function is called), check stored
autonomous systems, add new ones (updateAS), update (editAS) or
delete (deleteAS) them.
Page 76 of 191
Version 1.0


o links.xhtml: The links page (Figure 26). The SBox administrator can
insert new links (updateLink), as well as update (editLink) or delete
(deleteLink) existing ones. The addSegment and deleteSegment
support functions are also used to add and delete, respectively, a Segment
for a selected Link.
o localclouds.xhtml: The local clouds page. The existing local clouds are
presented, and the user may insert (updateCloud) a local cloud, edit
(editCloud) or delete (deleteCloud) a stored one.
o remoteclouds.xhtml: The remote clouds page. The existing remote
clouds are presented, and the user may insert (updateRemoteCloud) a
remote cloud, edit (editRemoteCloud) or delete (deleteRemoteCloud) a
stored one.
o routers.xhtml: The BG and DA routers page (Figure 25). In this page,
the SBox administrator can insert (updateBGRouter, updateDARouter)
new BG and DA Routers, as well as delete (deleteBGRouter,
deleteDARouter) stored ones.
o sdncontrollers.xhtml: The SDN Controllers page. The SBox
administrator may check stored SDN Controllers, add new ones
(updateSDNController), update (editSDNController) or delete
(deleteSDNController) them.
o settings.xhtml: The DTM settings page (Figure 28). In this page, the
DTM execution and system parameters are configured and stored in the
database (updateTimeParams, updateSystemParams).
o tunnels.xhtml: The Tunnels page (Figure 27). The SBox administrator
can insert new tunnels (updateTunnel), as well as update (editTunnel)
or delete (deleteTunnel) existing ones.
css/: This directory includes all the css files used to format and style the Web
application pages. Besides, the 2 files (sbox-main.css and sbox-signin.css)
that describe the SBox UI style and format, the directory includes all the Twitter
Bootstrap css and theme files.
fonts/: It includes all Twitter Bootstrap fonts.
js/: This directory includes all the javascript files. These files are used to support
certain
Twitter
Bootstrap
components
(bootstrap.js,
bootstrapdropdown.js, bootstrap-modal.js, bootstrap-datetimepicker.js,
jquery.js, moment.js), and support the validation of the user input. In the
second case, the bootstrapValidator.js acts as the key element of forms validation,
highlighting correct/incorrect fields and enabling/disabling Submit button, while
additional javascript files (between.js, integer.js, ip.js, notEmpty.js)
provide individual fields validation, providing relevant error messages.
WEB-INF/: This directory includes the web.xml file, including Web applications
configuration. The Web application supports FORM authorization method, which
means that a new or session-expired request will be always redirected to a sign-in
Version 1.0
Page 77 of 191

page to provide its username and password. Currently, access is limited only to
administrators, with credentials encrypted in Web servers configuration files.
signin.jsp: The sign-in page of the Web application. In case of incorrect
credentials it redirects user to signinError.jsp page, otherwise to
index.xhtml.
signinError.jsp: The error page, when the user inserts incorrect credentials.
5.1.7.3
Tests
No automated tests were implemented for the User interface. The Web application was
tested during integration and system tests.
5.2
SDN Controller
The main purpose of SDN Controller is the selection of proper output interface of
OpenFlow-based switch in order to ensure traffic forwarding continuity in accordance with
current traffic statistics and the value of the Reference and Compensation vectors
received from SBox. Code of DTM module of SDN controller was updated since version
1.1 presented in D3.2 [2] in order to meet requirements of extended mechanism (DTM++).
Additionally, new working modes were introduced: reactiveWithReferenceVector,
reactiveWithoutReferenceVector,
proactiveWithReferenceVector
and
proactiveWithoutReferenceVector.
5.2.1 Interfaces
The SDN controller exposes the SBox-SDN Server Interface containing constants and
helper methods used commonly by the SBox and by the SDN controller.
5.2.1.1 Interfaces
The SBox-SDN Server exposes following constant URLs on which the SDN controller
listens:
public static final String BASE_PATH Base path URL.
public static final String DTM_R_C_VECTORS_PATH Path used by
server-side resource used for editing and retrieving RCVectors, i.e., RVector and
CVector.
public static final String DTM_CONFIG_DATA_PATH Path used by
server-side resource used for editing and retrieving ConfigData.
Moreover, the helper methods for serialization, deserialization, and conversion from tunnel
id to OpenFlow switch port id are exposed:
public static <T extends
object) Generic serializator.
Serializable>
String
serialize(T
public static <T extends Serializable> T deserialize(String

text, Class<T> clazz) Generic deserializator.
Page 78 of 191
Version 1.0


public static short toPort(TunnelID tunnelID) Converter of tunnel id to OpenFlow

switch port id.
5.2.1.2 Design
The SBox-SDN interfaces have been implemented in four classes, all within package
eu.smartenit.sdn.interfaces.sboxsdn. They are presented in Figure 31.
public class URLs (non-instantiable) holds information on common constant
URLs (BASE_PATH, DTM_R_C_VECTORS_PATH, and DTM_CONFIG_DATA_PATH)
public class Serialization (non-instantiable) defines serialization and
deserialization helpers (serialize and deserialize)
public class SimpleTunnelIDToPortConverter defines converter of
simple tunnel id object to OpenFlow switch port number. It contains one method:
o public static short toPort(TunnelID tunnelID) converts
tunnel id object to OpenFlow switch port number.
public final class RCVectors implements Serializable provides a
container for reference and compensation vectors. It contains two fields (with
getters and setters):
o private RVector referenceVector reference vector;
o private CVector compensationVector compensation vector.
Figure 31: SBox-SDN Server Interface classes.

5.2.1.3 Tests
One JUnit [19] class with seven test methods has been implemented:
public class SerializationTest:
o public void
RCVectors
testSerializeRCVectors() tests serialization of
Version 1.0
Page 79 of 191

o public void testSerializeConfigData() tests serialization of

ConfigData
o public void testDeserializeRCVectors() tests deserialization of
RCVectors
o public void testDeserializeConfigData() tests deserialization
of ConfigData
o public
void
testLinkBGRouterBiDirReferenceSerialization() tests if bidirectional reference between Link and BGRouter are correctly
(de-)serialized.
o public void testTunnelLinkBiDirReferenceSerialization()
tests if bi-directional reference between Tunnel and Link are correctly
(de-)serialized.
o public void testCloudDCASBiDirReferenceSerialization()
tests if bi-directional reference between CloudDC and AS are correctly
(de-)serialized.
5.2.2 Floodlight
The SDN Controller is a component responsible for flow distribution in the remote
autonomous system. Depending on the selected mode Floodlight uses both, Reference
and Compensation vectors received from NTM (reactiveWithReference and
proactiveWithReference
modes)
or
only
Compensation
vector
(reactiveWithoutReference and proactiveWithoutReference modes).
The SDN controller provides generally following functionalities:
receiving of ConfigurationData, Reference and Compensation vectors via
northbound interface (REST),
OpenFlow flow rules establishment,
initial configuration of OpenFlow-based switch via OpenFlows messages,
traffic statistics collection from tunnels (in modes with Reference vector).
5.2.2.1 Interfaces
The SDN controller runs a HTTP server on port 8080 and exposes two REST interfaces
under following URLs:
URLs.BASE_PATH + URLs.DTM_R_C_VECTORS_PATH used to send (using
POST request) and retrieve (using GET request) reference and compensation
vector in JSON-encoded RCVectors container; the reference vector may be set to
null in this case it is not updated.
URLs.BASE_PATH + URLs.DTM_CONFIG_DATA_PATH used to send (using
POST request) and retrieve (using GET request) configuration data in JSONencoded ConfigData object.
Page 80 of 191
Version 1.0


5.2.2.2 Design
The SDN controller is designed as an extension to the Floodlight 0.90 controller [23]. The
functionality
has
been
implemented
in
packages
eu.smartenit.sdn.floodlight090.dtm
and
eu.smartenit.sdn.floodlight090.dtm.restlet. The former consists of six
classes, and the latter of three classes. They are presented in the Figure 32.
public class DTM (singleton) main DTM class; holds information on current
compensation vector, reference vector, and traffic transmitted; it contains following
methods:
o public static DTM getInstance() returns DTM singleton; creates
one if necessary;
o public static void resetInstance() sets DTM instance to null.
When the instance will be requested next time it will be created. This method
is mainly meant to be using in tests;
o public
IFloodlightProviderService
getFloodlightProvider()/public
void
setFloodlightProvider(IFloodlightProviderService
floodlightProvider) returns/set FloodlightProvider;
o public
synchronized
void
setConfigData(ConfigData
configData)/public ConfigData getConfigData() update/return
configuration;
o public
synchronized
void
setReferenceVector(RVector
referenceVector)/public RVector getReferenceVector()
update/return reference vector;
o private
Set<Short>
getAllDARouterPorts(ConfigData
configData) returns all switch OF port numbers;
o public synchronized void setCompensationVector(CVector
compensationVector)/public
CVector
getCompensationVector() update/return compensation vector;
o public synchronized void setSwitch(IOFSwitch sw)/public
IOFSwitch getSwitch() update/return switch on which DTM operates;
currently, only one switch is supported;
o private synchronized void transmittedBytesMapUpdated()
modifies flow rule for proactiveWithReferenceVector controller mode;
o public long getTransmittedBytes() returns traffic counter on
selected switchs port;
o public Map<Short, Long> getTransmittedBytesOnAllPorts()
returns statistics of transmitted bytes on all switch ports
o private
synchronized
void
resetTransmittedBytesStart(short daRouterOfPortNumber)
resets traffic start counter on selected switch's port;
Version 1.0
Page 81 of 191

o public long getTransmittedBytesStart() returns traffic start

counter on selected switchs port;
o public void setOFPacketIn(OFPacketIn msg) updates OpenFlow
PacketIn message on whitch DTM operates;
o public OFPacketIn getOFPacketIn() returns OpenFlow PacetIn
message;
o public String intToStringIp(int i) parses integer IP address to
string;
o public void sendStaticFlowRule(Map<NetworkAddressIPv4,
Short> dcPrefixOutOfPortMap) sends static flow rule to switch
mapping output IP address to switch output port;
o public
synchronized
Map<NetworkAddressIPv4,
Short>
getProactiveOutOfPortNumber() returns map of destination IP
address with output port in proactive modes; see pseudocodes in sections
5.2.2.2.3 and 5.2.2.2.4;
o public
synchronized
short
getReactiveWithReferenceOutOfPortNumber() returns output port
of switch for a new flow for reactiveWithReference mode; see pseudocode in
section 5.2.2.2.1;
o public
synchronized
short
getReactiveWithoutReferenceOutOfPortNumber() returns output
port of switch for a new flow for reactiveWithoutReference mode; see
pseudocode in section 5.2.2.2.2;
o private void validateConfigData(ConfigData configData)
validates ConfigData;
o private
void
validateReferenceVector(RVector
referenceVector) validates Reference Vector;
o private
void
validateCompensationVector(CVector
compensationVector) validates Compensation Vector;
public class DTM.PortStatisticsPoller extends TimerTask timer
task
responsible
for
getting
swithchport
statistics
every
PORT_STATISTICS_POLLING_INTERVAL ms; it contains one method:
o public void run() - requests port statistics (tx bytes) from switch and
saves the state upon success;
public class DTMFloodlightModule implements IFloodlightModule
Floodlight module responsible for adding message listener, switch listener, and
RESTlet routable; it contains following methods:
o public Collection<Class<? extends IFloodlightService>>
getModuleServices()
and
public
Map<Class<?
extends
IFloodlightService>,
IFloodlightService>
getServiceImpls() do nothing and return null; this module does not
implement any services;
Page 82 of 191
Version 1.0


o public Collection<Class<? extends IFloodlightService>>

getModuleDependencies() returns a list of modules that this module
depends on, i.e., IFloodlightProviderService IRestApiService;
o public
void
init(FloodlightModuleContext
initializes DTM module;
o public void startUp(FloodlightModuleContext
starts DTM module;
context)
context)
public class DTMMessageListener implements IOFMessageListener

adds a new flow when a packet in message is received from a switch; it contains
following methods:
o public Command receive(IOFSwitch sw, OFMessage msg,
FloodlightContext cntx) processes new packet and add a flow for
it;
o public String getName() returns the listener name;
o public
boolean
isCallbackOrderingPrereq(OFType
type,
String
name)
and
public
boolean
isCallbackOrderingPostreq(OFType type, String name)
return false - this listener does not have pre/post-requisites.
public class DTMSwitchListener implements IOFSwitchListener
listens for new switches and configures main DTM class.
o public void addedSwitch(IOFSwitch sw) fired when a switch is
connected to the controller, and has sent a features reply; propagates the
information to DTM;
o public void removedSwitch(IOFSwitch sw) fired when a switch is
disconnected from the controller; propagates the information to DTM;
o public void switchPortChanged(Long switchId) fired when
ports on a switch change (any change to the collection of OFPhysicalPorts
and/or to a particular port); does nothing;
o public String getName() returns the listener name;
public class Flows (non-instantiable) manages flows; contains following
methods:
o public
static
void
init
(IOFSwitch
sw,
floodlightProvider,
FloodlightContext cntx, short dcPort, short inetPort)
initializes flow table in switch(adds return flows); adds flow for given switch,
outgoing port, and DC switch port; constructs OFMatch and instructs switch
to send all packets from the given interface to dcPort interface; the controller
sends the switch one OpenFlow message: ofp_flow_mod (with
OFPFC_ADD action);
o public
static
void
add(IOFSwitch
sw,
floodlightProvider,
FloodlightContext cntx, short outPort, OFPacketIn pi)
Version 1.0
Page 83 of 191

adds flow for given switch, outgoing port, and incoming packet; constructs
OFMatch from the incoming packet and instructs switch to send all packets
from the flow to be sent to given outgoing port; the received packet is sent
do switch for forwarding; the controller sends the switch two OpenFlow
messages:
ofp_flow_mod
(with
OFPFC_ADD
action)
and
ofp_packet_out;
o public
static
void
del(IOFSwitch
sw,
floodlightProvider,
FloodlightContext cntx, String dcIP, int dcMask) deletes
flow for given switch and destination DC IP; constructs OFMatch and
instructs switch to delete particular flow from its flow table; the controller
sends the switch a OpenFlow message: ofp_flow_mod (with
OFPFC_DELETE action);
o public
static
void
mod(IOFSwitch
sw,
floodlightProvider,
FloodlightContext cntx, String dcIP, int dcMask, short
outPort) modifies particular flow rule in switch; ; the controller sends the
switch
a
OpenFlow
message:
ofp_flow_mod
(with
OFPFC_MODIFY_STRICT action);
public class DTMRestletRoutable implements RestletRoutable
Configures RESTlet resources; contains two methods:
o public Restlet getRestlet(Context context) returns the restlet
that will map to the resources; two resources are mapped:
RCVectorsResource ConfigDataResource;
o public String basePath() returns the base path URL where the
router should be registered;
public class ConfigDataResource extends ServerResource Serverside resource used for editing and retrieving ConfigData; contains two mehods:
o public String
configuration data;
handleGet()
returns
JSON-serialized
DTM
o public String handlePost(String text) sets JSON-serialized

new DTM config data; returns JSON-serialized current DTM config data;
public class RCVectorsResource extends ServerResource Serverside resource used for editing and retrieving RCVectors, i.e., RVector and CVector;
contains two methods:
o public String handleGet() returns JSON-serialized current R and C
vectors;
o public String handlePost(String text) sets JSON-serialized
new R and C vectors; returns JSON-serialized current R and C vectors.
The Floodlight classes were all left unchanged. The only modifications to the controller
that have been done were the configuration files the DTM module has been enabled
and the Forwarding module has been disabled.
Page 84 of 191
Version 1.0


Figure 32: SDN Controller based on Floodlight 0.9 classes.
Version 1.0
Page 85 of 191

5.2.2.2.1
Pseudocode for reactiveWithReference mode
r_inv[1] = r[2];
r_inv[2] = r[1];
counter_start[1]=read_counter(1);
for(each new flow packet){
tunnel=1;
compensate=false;
If(C[1]>0){
tunnel=1;
compensate=true;
}
If(C[2]>0){
tunnel=2;
compensate=true;
}
if(compensate){
for(each timer=1sec) if(read_counter(tunnel)-counter_start[tunnel]>
C[tunnel]/r_inv[tunnel]){
for(k=1 to 2) counter_start[k]=read_counter(k);
tunnel=(tunnel mod 2) +1;
compensate=false;
}
send_SDN_rule(tunnel);
}
else {
for(each timer=1sec){
traffic_1=read_counter(1) - counter_start[1];
traffic_DA-B=traffic_1 + read_counter(2) - counter_start[2];
if(traffic_1/ traffic_DA-B < = r[1])
tunnel=1;
else
tunnel=2;
}
}
}
5.2.2.2.2
Pseudocode for reactiveWithoutReference mode
Page 86 of 191
Version 1.0


If(C[1]==0) tunnel=1;
If(C[1]>0) tunnel=1;
If(C[2]>0) tunnel=2;
}
5.2.2.2.3
Pseudocode for proactiveWithReference mode
r_inv[1] = r[2];
r_inv[2] = r[1];
for(each new C){
tunnel=1;
compensate=false;
if(C[1]>0){
tunnel=1;
send_mod_SDN_rule(tunnel, wildcard);
compensate=true;
}
if(C[2]>0){
tunnel=2;
send_mod_SDN_rule(tunnel, wildcard);
compensate=true;
}
}
if(compensate){
for(each timer=1sec)
if(read_counter(tunnel)-counter_start[tunnel]>
C[tunnel]/r_inv[tunnel]){
for(k=1 to 2) counter_start[k]=read_counter(k);
compensate=false;
tunnel=(tunnel mod 2) +1;
send_SDN_remove_rule(all);
break;
}
else {
for(each timer=1sec){
Version 1.0
Page 87 of 191

traffic_1=read_counter(1) - counter_start[1];
traffic_DA-B = traffic_1 + read_counter(2)
- counter_start[2];
if(traffic_1/ traffic_DA-B < = r[1])
tunnel=1;
else
tunnel=2;
}
}
5.2.2.2.4
Pseudocode for proactiveWithoutReference mode
for(each new C){

if(C[1]== 0) tunnel=1;
if(C[1]>0) tunnel=1;
if(C[2]>0) tunnel=2;
send_mod_SDN_rule(tunnel,wildcard);
}
5.2.2.3 Tests
Eight JUnit [19] classes were developed to test the implementation:
public class DTMConfigProcessingTest tests configuration processing
by DTM module; contains following tests:
o public void testGetInstance() tests if DTM.getInstance() returns
the same value in subsequent calls;
o public void testSetConfigData() tests the configuration data
setter;
o public void testSetSwitch() tests OpenFlow switch setter;
public class DTMFlowDistributorTest main DTM test class for single-tosingle DTM setup; contains following tests:
o public
testGetReactiveWithReferenceOutOfPortNumber()
algorithm for reactiveWithReference mode;
o public
testGetReactiveWithoutReferenceOutOfPortNumber()
algorithm for reactiveWithoutReference mode;
o public
testGetProactiveWithoutReferenceOutOfPortNumber()
algorithm for proactiveWithReference mode;
Page 88 of 191
void
tests
void
tests
void
tests
Version 1.0


public class DTMFlowDistributorTwoDCsTest main DTM test class for

multi-DC DTM setup; contains following tests:
o public
testGetReactiveWithReferenceOutOfPortNumber()
algorithm for reactiveWithReference mode;
void
tests
o public
testGetReactiveWithoutReferenceOutOfPortNumber()
algorithm for reactiveWithoutReference mode;
o public
testGetProactiveWithoutReferenceOutOfPortNumber()
algorithm for proactiveWithReference mode;
void
tests
void
tests
public class DTMTestCase contains test cases for the purpose of flow
distribution tests;
public class DTMVectorsProcessingTest tests vector processing by
SDN controller; contains following tests:
o public void testSetReferenceVector() tests setup of single
Reference Vector;
o public void testSetMultipleReferenceVectors() tests setup
of multiple Reference Vectors;
o public void testSetCompensationVector() tests setup of single
Compensation Vector;
o public void testSetMultipleCompensationVector() tests
setup of multiple Compensation Vector;
public final class FakeStatisticsProviderOFSwitch class providing
fake OpenFlow-enabled switch for reactive mode tests;
public class FlowDistributorSetUpHelper helper class with constant
values of Compensation Vector for DTMFlowDistributorTest
and
DTMFlowDistributorTwoDCsTest classes;
public class TestSetUpHelper helper class with constant values of
ConfigData and fake OpenFlow PacketIn message;
Version 1.0
Page 89 of 191

6 The Replicating Balanced Tracker - Home Router

Sharing based on Trust (RB-HORST) mechanism
RB-HORST mechanism focuses on end-users and is deployed on devices owned and
controlled by them. Therefore, the mechanisms functionalities map onto two architecture
entities: the user Nano-Datacenter (uNaDa), which implements the social monitoring,
social and overlay prediction, content prefetching and WiFi offloading functionalities and is
expected to be hosted on domestic WiFi access point devices or home gateways, and the
End-User application, which is deployed in end-user devices, e.g. smartphones, tablets.
The aforementioned entities and their respective components functionality, interfaces,
design and local tests will be presented in the sections that follow.
6.1
uNaDa
The uNaDa entity includes all the required components to execute the RB-HORST
mechanism. The following sections will provide a brief description for each component,
and document their exposed interfaces, design details, and local tests executed to
validate their correctness.
6.1.1 Cloud Traffic Manager
The Cloud Traffic Manager (CTM) component is the coordinating element of the uNaDa. It
is responsible for:
initializing the social monitoring function,
periodically querying the Overlay Manager and Social Analyzer components for the
ranked list of predicted contents,
managing the uNaDas cache, either by checking the ranked content list deriving by
the social and overlay prediction, or periodically cleaning the least accessed
contents,
implementing the content prefetching functions, either from the Vimeo servers or
other overlay peers.
6.1.1.1 Interfaces
The Cloud Traffic Manager exposes 4 interfaces:
CacheManager: The cache management interface. It includes methods to update
the cache based on the received sorted lists of content from the social and overlay
prediction and periodically delete the expired contents. This interface is called
internally upon uNaDa initialization.
o void
updateCache(List<Content>
socialContentList,
List<Content> overlayContentList): The method that updates the
cache based on the received sorted lists of content from the social and
overlay prediction. It receives the following input parameters:
Page 90 of 191
Version 1.0


socialContentList The sorted list of contents from the social

prediction.
overlayContentList The sorted list of contents from the overlay

prediction.
o void deleteExpired(): The method that deletes the expired contents

from the local cache and database.
ContentAccessLogger: It updates the content access log for a specific content
and user. This interface is called when a content access is received in the uNaDaend-user REST interface (Section 6.1.6.1) through the proxy component.
o boolean updateAccessLog():The method that updates the access log
for a specific content and user. If the recent accesses are very near to the
current time, then the access log is not updated.
It returns a Boolean, which is the outcome of the update.
ContentManager: It includes methods to delete contents from the database and

the local cache, prefetches content, either from Vimeo or other uNaDas and inserts
them to the local cache. This interface is called internally by the CacheManager
interface.
o void deleteContent(Content content): The method that deletes a
content from both the local cache and the database.
It receives as input the content to be deleted.
o void deleteContents(List<Content> contents): The method that

deletes a list of contents from both the local cache and the database.
It receives as input the list of contents to be deleted.
o void prefetchContent(Content content): The method that

prefetches a content, and inserts it to the local cache and the database.
It receives as input the content to be prefetched.
o void prefetchContents(List<Content> contents): The method

that prefetches a list of contents, and inserts it to the local cache and the
database.
It receives as input the list of contents to be prefetched.
o void
deleteContents(List<Content>
contents,
long
threshold): The method that deletes a list of contents from both the local
cache and the database, that were not accessed since the given time
threshold. It receives as input
The list of contents to be deleted,
The time threshold, after which contents which were not accessed
should be deleted.
VideoDownloader: The video downloading interface. It downloads the content,

either from the Vimeo servers, or other overlay peers. It is called, either from other
Version 1.0
Page 91 of 191

internal interfaces, or when a content download request is received in the uNaDaend-user REST interface (Section 6.1.6.1) through the proxy component.
o void downloadVideo(): The method that downloads a video and stores
it in local cache.
The implementation and internal functionality of each interface will be presented in the
following section.
6.1.1.2 Design
Figure 33 presents the class diagram of the CTM component. It includes all the interfaces,
classes and their associations and dependencies, as well as their parameters and
implemented methods. The key classes and methods are described below:
CacheManagerImpl implements CacheManager: It includes methods to
update the cache, based on the received sorted lists of content from the social and
overlay prediction.
o public void updateCache(List<Content> socialContentList,
List<Content> overlayContentList): The method that updates the
cache based on the received sorted lists of content from the social and
overlay prediction.
o public void deleteExpired():The method that deletes the expired
contents from the local cache and database.
o private int contentExistsInList(List<Content> list, long
contentID): The method that checks whether a content belongs a content
list.
o public
void
updateSocialContentListWithSizes(List<Content>
contentList): The method that updates the social content list with their
sizes, as retrieved from Vimeo.
ContentAccessLoggerImpl
Runnable:
implements
ContentAccessLogger,
o public boolean updateAccessLog(): It updates the content access

log for a specific content and user.
o public boolean updateAccessLog(): The method that updates the
access log for a specific content and user. If the recent accesses are very
near to the current time, then the access log is not updated.
o public void run(): The default thread start method.
ContentManagerImpl implements ContentManager: It includes methods to
delete contents from the database and the local cache, prefetches content, either
from Vimeo or other and inserts them to the local cache.
o void deleteContent(Content content): The method that deletes a
content from both the local cache and the database.
Page 92 of 191
Version 1.0


o void deleteContents(List<Content> contents): The method that

deletes a list of contents from both the local cache and the database.
o void prefetchContent(Content content): The method that
prefetches a content, and inserts it to the local cache and the database.
o void prefetchContents(List<Content> contents): The method
that prefetches a list of contents, and inserts it to the local cache and the
database.
o void
deleteContents(List<Content>
contents,
long
threshold): The method that deletes a list of contents from both the local
cache and the database, that were not accessed since the given time
threshold.
OverlayDownloader
implements
VideoDownloader,
Runnable: It
includes methods that retrieve content information from the overlay, and download
the content, if not present in the cache.
o public
void
run():
OverlayDownloader thread.
The
method
that
executes
the
o public void downloadVideo(): The method that downloads the video

from the overlay. It checks whether the content is cached, otherwise it
downloads it and stores it in the local cache.
VimeoDownloader implements VideoDownloader, Runnable: It includes
methods that retrieve content information from Vimeo, and download the content, if
not present in the cache.
o public void run(): The method that executes the VimeoDownloader
thread.
o public void downloadVideo(): The method that downloads the video
from Vimeo. It checks whether the content is cached, otherwise it downloads
it and stores it in the local cache.
o public Path getVideoStorage(VGet v): The method that extracts
the path where the video will be downloaded.
o public long getVideoID(String url): The method that retrieves the
content ID from the request url.
VimeoInfoRetriever: It includes a method which retrieves a Vimeo's video
information from the Vimeo.
o public VideoInfo retrieveVideoInfo(String url): The method
that retrieves the content information from Vimeo.
UnadaOrchestrator implements Runnable: It bootstraps the uNaDa Web
application functions.
o public void run(): The method running the bootstrap method. If its
outcome is successful, then thread is over, otherwise runs the bootstrap
again after 2 minutes.
Version 1.0
Page 93 of 191

o public boolean bootstrap(): The method bootstrapping all the

uNaDa functionalities: (a) starting or joining the overlay, (b) advertising
content to the overlay, (c) start social monitoring and, (d) start social and
overlay prediction.
PredictionTask implements Runnable: It initializes the social and overlay
prediction algorithms.
o private void predict(): The method that requests the ranked content
list from the social and overlay prediction algorithms and then provides them
to the cache manager to perform the required content downloads, deletions
and updates.
o public void run(): The method that starts the thread.
CacheCleanerTask implements
contents from the cache.
Runnable: It removes expired cached
o public void run(): The method that runs the thread.

Figure 34 presents which functions are initialized when the uNaDa Web application starts.
The coordinating class is the UnadaOrchestrator, which is triggered by the
bootstrap() method. It then queries the UnadaConfiguration and Owner tables
to check whether the required configuration parameters are set, as well as the user has
logged in with his Facebook credentials, hence has gained ownership of the uNaDa. In the
positive case, the uNaDa joins the overlay through the joinOverlay() function of the
OverlayManager, and starts the social monitoring function, by calling the
startMonitoring() method of SocialMonitor. Finally, the periodic prediction and
cache cleaning tasks are also initialized.
When the PredictionTask is called, it runs periodically and executes the social and
overlay prediction algorithms, and subsequently the cache management task. Specifically,
it retrieves from the OverlayManager and the SocialAnalyzer the sorted list of
predicted contents, through the predicting() and getPrediction() methods
respectively, and then provides them to the CacheManager to update the cache, through
the updateCache() method. Figure 35 presents the aforementioned function calls, as
well as a simple case, when some of the predicted contents are prefetched, by calling the
relevant ContentManager method, and each one is downloaded through the
VimeoDownloader downloadVideo() function. In addition, the low-ranked contents
are either ignored or deleted if are stored- from the cache, by triggering the
deleteContents() method.
Page 94 of 191
Version 1.0


Figure 33: CTM class diagram.
Version 1.0
Page 95 of 191

Figure 34: CTM orchestrator sequence diagram.
Figure 35: Cache management sequence diagram.

6.1.1.2.1
Cache management algorithm
The simplified pseudocode for the handling of the ranked content lists, provided by the
social and overlay prediction algorithms, and the basic cache management is presented
below. In principle, the contents predicted by the overlay prediction have a slight
advantage, since they can be downloaded by close peers and save unnecessary interdomain traffic. Close peers are considered the uNaDas that belong to ASes up to 1 hop
away. In this sense, if a content item belongs to both the overlay and social ranked lists,
then it will be downloaded from the overlay, unless the closest peer is more than 1 hop
away. Otherwise, it will be downloaded from Vimeo servers. Of course, the projected size
of the cache (sum of current cache size and content size) is always taken into account,
before adding the content to the ones that can be prefetched. The deleteIgnored()
function will either delete a content if it exists in the cache, or ignore it.
Page 96 of 191
Version 1.0


updateCache(socialContentList, overlayContentList):
foreach content in socialContentList:
if content does not exists in overlayContentList:
if socialScore > socialThreshold AND (currentCacheSize +
contentSize < cacheSize):
VimeoDownloader.download(content)
else:
ignoreList.add(content)
foreach content in overlayContentList:
if (overlayScore > overlayThreshold) AND (currentCacheSize +
contentSize < cacheSize):
if overlayHops <= 1:
OverlayDownloader.download(content)
else:
VimeoDownloader.download(content)
else:
ignoreList.add (content)
deleteIgnored(ignoreList)
6.1.1.3 Tests
The JUnit [19] tests that validate the correctness of the aforementioned functions and
algorithms are presented below:
CacheManagerTest
o public void testDeleteContents(): Tests the deleteContents()
function.
o public void testUpdateCacheFetchOneIgnoreOne(): Tests the
updateCache function, for one content above and one content below
threshold
o public void testUpdateCacheFetchAll(): Tests the updateCache
for multiple contents above threshold.
o public void testUpdateCacheIgnoreAll():Tests the updateCache
for multiple contents below threshold.
o public
void
testUpdateCacheFullCacheAboveThresholdIgnoreAll():Tests the
updateCache for multiple contents above threshold, but for full cache.
o public
void
testUpdateCacheFullCacheBelowThresholdIgnoreAll():Tests the
updateCache for multiple contents below threshold and full cache.
Version 1.0
Page 97 of 191

o public
void
testUpdateCacheNearFullCacheAboveThresholdIgnoreSecond():
Tests the updateCache for multiple contents above threshold, but with
cache near to full, hence the second is ignored.
o public void testUpdateCacheFetchAllSocialOverlay(): Tests
the updateCache for multiple contents above threshold.
o public void testUpdateCacheContentInBothListsLowScore():
Tests the updateCache for contents belonging in both social and overlay
list, but with low score.
o public void testUpdateCacheContentInBothListsGoodScore():
Tests the updateCache for contents belonging in both social and overlay
list, with good score.
ContentManagerTest
o public
void
testDeleteNullContent():
deleteContent() for a null one.
Tests
the
o public void testDeleteContent(): Tests the deleteContent().

o public
void
testDeleteNullContents():
deleteContents() for a null list.
o public
void
testDeleteEmptyListContents():
deleteContents() for an empty list.
Tests
Tests
the
the
o public void testDeleteContents(): Tests the deleteContents()

for existing ones.
o public
void
testPrefetchNullContent():
prefetchContent() for a null one.
Tests
the
o public
void
testPrefetchSocialContent():
prefetchContent() for one belonging to the social list.
Tests
the
o public
void
testPrefetchOverlayContent():
prefetchContent() for one belonging to the overlay list.
Tests
the
o public
void
testPrefetchContents():
Tests
the
prefetchContents() for multiple ones belonging to social and overlay
lists.
FileUtilsTest
o public void testDeleteFile(): Tests the deleteFile() function.
o public void testGetRootPath(): Tests a method which finds its root
directory.
OverlayDownloaderTest
o public
void
testDownloadVideoNotCached():
Tests
the
downloadVideo() for a non-cached video, hence the video is
downloaded.
Page 98 of 191
Version 1.0


o public
void
testDownloadVideoCached():
downloadVideo() for a cached video.
Tests
the
o public
void
testUpdateAccessLogNoMAC():
Tests
updateAccessLog() method when no MAC address is provided.
the
VimeoAccessLoggerTest
o public void testUpdateAccessLogNoTrustedUser(): Tests the

updateAccessLog() method when the user is not trusted.
o public void testUpdateAccessLogNoContentAccess(): Tests the
updateAccessLog() method for the first time.
o public
void
testUpdateAccessLogRecentContentAccess():
Tests the updateAccessLog() method when recent access logs for the
same user exist.
o public void testUpdateAccessLogNotRecentContentAccess():
Tests the updateAccessLog() method when no recent access logs for the
same user exist.
VimeoDownloaderTest
o public void testDownloadVideoMobileNotCached(): Tests the
downloadVideo() function for a non-cached mobile video.
o public
void
testDownloadVideoCached():
downloadVideo() function for a cached video.
o public
void
testGetVideoStorage():
getVideoStorage() method.
Tests
Tests
the
the
o public void testGetVideoID(): Tests the getVideoID() method.

VimeoInfoRetrieverTest
o public
void
testRetrieveVideoInfo():
retrieveVideoInfo() method.
Tests
the
o public
void
testRetrieveVideoInfo2():
retrieveVideoInfo() method.
Tests
the
o public
void
testRetrieveFalseVideoInfo():
retrieveVideoInfo() method for a false video URL.
Tests
the
VimeoPatternsTest
o public void testPatterns(): Tests the Vimeo patterns.
6.1.2 Overlay Manager
The Overlay Manager (OM) component is the communicating component of the uNaDa. It
is responsible for:
initializing and maintaining the overlay network,
calculating the overlay prediction,
Version 1.0
Page 99 of 191

sending messages between uNaDas,

downloading content from other uNaDas.
6.1.2.1 Interfaces
The IOverlayManager interface is the external interface of the Overlay Manager (OM) that
should be used by components relying on the OM. It offers all the methods called by the
Cloud Traffic Manager (CTM). The overview of methods is depicted in Figure 36.
Figure 36: The external interface of the Overlay Manager.

The methods offered allow a user to join, create, or update and overlay network. To join
an IP address and port number of an existing peer is required. To create a new overlay
nothing is required but interface name or IP address to be used for binding can be
specified. Update must be used if the IP address of the host changes.
Further methods are offered to advertise content to the other uNaDas, send messages to
other uNaDas, calculate an overlay prediction, to download a specific content from
another uNaDa, and to retrieve a list of close uNaDas that share a content. The
getuNaDaInfo() method returns the address and ID of the local uNaDa. The
shutDown() method is used to gracefully leave the overlay network and let others know
that this uNaDa is leaving the system.
Page 100 of 191
Version 1.0


Figure 37: Class diagram of the logical classes of the OM.

Version 1.0
Page 101 of 191


6.1.2.2 Design
Internally the OM is much more complex than the interface offered to other components.
Figure 37 depicts the classes of OM excluding messages which shall be explained later.
The OverlayManager is the main class of the component orchestrating the three
functional areas of overlay, downloading, and neighbor relations. These functional areas
are covered by three delegate classes shortly explained:
The Overlay class is responsible for all overlay related functionality like joining, leaving,
or creating a network as well as DHT lookups and sending messages.
The ContentDownloadHandler class manages the downloading process from other
uNaDas. It uses methods from OverlayManager to find providers for a given content.
Furthermore, it handles chunking an error checking of transferred data.
The NeighborDatabase mainly acts as a storage facility for known uNaDas. It keeps
them sorted according to as hops and acts as a cache for discovered AS paths. It makes
sure no traceroutes for discovered uNaDas are executed.
Figure 38 shows all messages used in the OM component. There is one abstract super
type called BaseMessage from which all messages inherit and which is used by OM to
send and execute messages.
The concept of the execute()method helps reduce boilerplate code like if instance of
XY then . since every message contains the logic it has to trigger in the receiving
uNaDa. This pattern also avoids casting deserialized messages. Typically, messages are
pairs of request and replies and therefore a request messages execute method will
somehow trigger the response message being sent back to the sender.
Figure 38: Messages used in the in Overlay Manager.
Page 102 of 191
Version 1.0


6.1.2.3 Tests
OverlayManagerMessagingTest
o public void basicMesagingTest() tests if a message can be sent
from one OM to another.
o public void requestProviderTest()tests the queryProviders()
method of OM
o public
void
requestContentInfoTest()tests
request and reply messages.
getContentInfo
OverlayManagerPredictionTest
o testPrediction()tests the getPrediction() method of OM with a
mocked network.
OverlayManagerTest
o public void testJoinOverlay() tests if a uNaDa can successfully
join the DHT and retrieve its own uNaDa information.
o public void testUpdateOverlay() tests if a uNaDa can update its
uNaDa information
6.1.3 Topology Proximity Monitor
6.1.3.1 Functionality
The Topology Proximity Monitor is an entity responsible for determining the distance
between the local uNaDa and a number of remote ones. The distance is measured as a
number of AS hops on the path from a remote uNaDa and the local one. The list of AS
hops is determined by perfoming a traceroute and converting IPd to ASNs.
6.1.3.2 Interfaces
TPM provides other components with a TopologyProximityMonitor interface
containing two methods:
public
List<ASVector>
sortClosest(Collection<UnadaInfo>)
throws InterruptedException returns a list of unique uNaDa identifiers
sorted from the nearest to the furthest as well as the list of AS hops on the path
from each uNaDa on the list and the local one.
public
List<Integer>
getASVector(UnadaInfo)
throws
UnknownHostException, IOException, InterruptedException returns
a list of AS hops from on the path from the local uNaDa to the remote one.
6.1.3.3 Design
The component consists of five classes:
Version 1.0
Page 103 of 191


public class ASVector implements Comparable<ASVector> is a helper

structure holding a remote uNaDa identifier and a list of AS numbers on the path
from the local uNaDa to the remote one.
public
class
TopologyProximityMonitorImpl
implements
TopologyProximityMonitor is an implementation of the interface provided by
the component. When a sortClosest method is called on a local uNaDa, it uses
the Overlay Manager to send remote traceroute request to each of the remote
uNaDas. When a remote uNaDa TPM receives the remote traceroute request, it
executes the getASVector method, performs a traceroute using the tools built
into Windows or Linux (depending on host OS), and parses the traceroute output.
Then the IP addresses are converted to the AS numbers by using the Team Cymru
IP to ASN Mapping service. The list of the AS numbers is sent back to the
requesting uNaDa through the overlay. When the local uNaDa receives all remote
traceroute replies (or a timeout occurs), it sorts the remote uNaDas ascending by
the AS hops count.
public class TeamCymruWhoisClient is a helper class a Team Cymru IP
to ASN Mapping service client.
public
class
TeamCymruWhoisClientHandler
extends
SimpleChannelInboundHandler<String> is a helper class an inbound
handler capable to handle and parse rensponse from Team Cymru IP to ASN
Mapping service
public
class
TeamCymruWhoisClientInitializer
extends
ChannelInitializer<SocketChannel> is a helper class a channel initializer
for TeamCymruWhoisClientHandler.
The classes and their relations are depicted in Figure 39.
Page 104 of 191
Version 1.0


Figure 39: TPM class diagram.

6.1.3.4 Tests
TopologyProximityMonitorImplTest
o testSortClosest()
tests
sortClosest(Collection<UnadaInfo>) method
if
the
processes remote traceroute requests and replies properly,
handles reply timeout,
sorts the uNaDas in the correct order.
Version 1.0
Page 105 of 191


o testGetASVector() tests if the getASVector(UnadaInfo) method

prepares the ASVector structure properly after parsing the traceroute output.
o testParseTraceroute() tests if the traceroute output is parsed properly
on current platform.
o testParseWindowsTraceroute() test if the Windows tracert output is
parsed properly.
o testParseLinuxTraceroute() test if the Linux traceroute output is
parsed properly.
TeamCymruWhoisClientTest
o testIsSpecialPurposeAddress() test if the TeamCymruWhoisClient
is able to determine if an IP addess is as special purpose one or a routable
one.
o testIpToASN() tests if the ipToASN(Collection<Inet4Address>)
method connects to the Team Cymru IP to ASN Mapping service and is able
to gather AS numbers from the service properly.
6.1.4 Social Monitor
The Social Monitor is the instance which is responsible for retrieving social data from
Facebook and Vimeo. The Social Monitor is designed such that it can run in the
background.
6.1.4.1 Interfaces
The Social Monitor does not provide any interfaces.
6.1.4.2 Design
The Social Monitor designed such that it can run in the background and therefore provides
methods to start and stop the monitoring process. The two methods provided are:
public ScheduledFuture<?> startMonitoring(Owner owner): Starts
retrieving data for a given owner.
public
void
stopMonitoring(ScheduledFuture<?>
retrieving data for a given ScheduledFuture instance.
sf):
Stops
An UML diagram of the Social Monitor is provided in Figure 40.
Figure 40: UML diagram of Social Monitor.

Page 106 of 191
Version 1.0


The Social Monitor class wraps the MonitorRunner class which contains the actual data
retrieval logic. The run method described below encapsulates the complete retrieval logic:
public void run(): Method that invokes the MonitorRunner
A UML diagram of the MonitorRunner is shown in Figure 41.
Figure 41: UML diagram of Monitor Runner.

6.1.4.3 Tests
The Social Monitor and the Social Monitor Runner are tested in the following classes:
SocialMonitorTest
o
public void runSocialMonitor(): Tests the operation of
SocialMonitor
o
public void getFriendsTest(): Tests friend list retrieval
MonitorRunnerTest
o public void test(): Invokes the test procedure.
6.1.5 Social Analyzer
The Social Analyzer is the component which is responsible for analyzing social data
obtained by the Social Monitor. Based on specific properties of content items, namely its
Version 1.0
Page 107 of 191


age, the geographic distance from its download location, the number of accesses in the
local database, the number of views, and the number of Facebook friends who reposted
the content item, a prediction score is calculated. This prediction score is calculated to
determine the probability whether some particular Facebook user will use the content item
in question.
6.1.5.1 Interfaces
The Social Analyzer does not expose any interfaces but it does provide public methods.
The Social Analyzer consists of a single class exposing a single public method, named
predicting(). The prediction algorithm is invoked by calling the predicting() method of the
Social Analyzer class.
public List<Content> predicting(): Invokes the prediction algorithm and
returns a List of Content items, sorted by their score (ascending)
6.1.5.2 Design
The UML diagram of the Social Analyzer class is shown in Figure 42. The class holds the
complete logic for the prediction algorithm. A complete description of the individual
methods is omitted at this point because its complexity is tremendous. The design of
these methods can be summarized though.
private List<FeedItem> getFeedItems(): Retrieves FeedItems from the
database
Figure 42: UML diagram of Social Analyzer.
Page 108 of 191
Version 1.0


Once the feed data required for the calculation is retrieved from the database, the
calculation phase starts. It consists of a well-defined sequence of get* methods which
retrieve necessary data from the database and calculate* methods which are responsible
for calculating separate parts of the prediction score. Finally, the feed items are sorted by
their prediction score and returned in a list.
6.1.5.3 Tests
SocialAnalyzerTest
o
public void predictionTest(): Tests the correctness of the
prediction algorithm.
6.1.6 uNaDa-End-User Interface
The uNaDa-End-User interface module exposes the uNaDas interfaces towards the enduser device, as well the proxy component deployed within the uNaDa. It specifically
implements the login interface, which is accessed by the End-User application to provide
the remote users credentials and connect to the uNaDas private SSID, as well as the
download and access interfaces, which are used by the proxy component to download a
specific content and log a content access respectively.
6.1.6.1 Interfaces
The uNaDa-End-user interface component exposes 3 REST interfaces, each one
implemented by the respective *Service class:
LoginService: The login REST API of the uNaDa towards the end-user device.
It listens for GET end-user application login requests to the following URL:
http://<unada-ip-address>:<unada-port>/unada/rest/login/<facebookID> for the
specific facebookID:
o public RemoteLoginReply login(@PathParam("facebookID")
String facebookID, @Context HttpServletRequest request):
The login method. It checks whether the user is a trusted one. If yes, then it
executes an ARP request and updates its entry with his MAC address and
finally returns the private SSID parameters (SSID name and password) in
JSON format. Otherwise, it returns a negative reply.
It receives as input the users Facebook identifier.
DownloadContentService: The download REST API of uNaDa. It listens for
GET requests at the following URL: http://<unada-ip-address>:<unadaport>/unada/rest/download/<contentID> to download a specific video with the
specified contentID:
o public boolean download(@PathParam("contentID") String
contentID): The download method. It downloads a Vimeo video with
contentID.
It receives as input the content identifier to be downloaded.
Version 1.0
Page 109 of 191


AccessContentService: The content access REST API of the uNaDa. It listens

for
POST
requests
to
URL:
http://<unada-ip-address>:<unadaport>/unada/rest/access to log an access of a specific video request to local cache
path.
o public
boolean
access(String
path,
@Context
HttpServletRequest request): The access POST method. It inserts
an access entry for the specified content, if it exists in local cache path.
It receives as input the path of the requested content.
6.1.6.2 Design
The component consists of the aforementioned 3 classes, which are also presented the
class diagram of Figure 43.
Figure 43: uNaDa-End-user class diagram.

Figure 44 presents the sequence diagram when the login service at URL: http://<unada-ipaddress>:<unada-port>/unada/rest/login/<facebookID>. It initially checks whether there is
a trusted user with the provided facebookID, and if in the positive case, it retrieves the
latest uNaDa configuration including the private SSID credentials, as well as executes an
ARP request to get the devices MAC address and updates its entry.
Figure 44: The login service sequence diagram.
Page 110 of 191
Version 1.0


6.1.6.3 Tests
One class implements the JUnit [19] tests for the login service:
LoginServiceTest: The LoginServiceTest class implementing tests for the login
REST API.
o public void testNonExistingTrustedUser(): The test case for a
non-existing trusted user.
o public void
trusted user.
testExistingTrustedUser(): The test case for a
6.1.7 Database
The Database (DB) component is responsible both for relational tables creation and the
application connection to the uNaDa database. It includes the following modules:
dto: Contains all the Data Transfer Objects (DTO) of the database, namely all the
Java classes that correspond to the relational tables of the DB, and some additional
helper entities, which are used by certain components, but are not stored into the
database.
dao: Contains all the Data Access Objects (DAO) one for each table. Each of them
contains the methods provided to external components for reading from or writing
to the corresponding table. The dao module also includes the 4 following
packages:
o binders: Contains the binder classes.
o mappers: Contains the mapper classes.
o impl: Contains the implementation of each abstract class defined in the
root directory.
o util: Contains helper classes.
The DB contains the SQL tables described in the Design Subsection 6.1.7.2.
6.1.7.1
Interfaces
The DB component provides its services by exposing for each table a number of methods.
These methods, which reside for each table-entity in the corresponding DAO class,
named <entity-name>DAO, constitute the DB interface to the other components. Each of
these methods wraps up one or more SQL commands, located in the corresponding
Abstract<entity-name>DAO. In the case of multiple SQL commands, these may reside in
more than one Abstract<entity-name>DAO.
There is a set of methods which are implemented by almost all DAOs, while few others
are more specific, more complicated therefore implemented usually by a single (or more
cooperating) DAO. The common methods are briefly described as follows.
public void createTable(): The method that creates the corresponding
table.
Version 1.0
Page 111 of 191


public void deleteTable(): The method that deletes the corresponding

table.
public void insert(<entity type> e): The method that inserts an entity
to the corresponding table.
o Input parameter: The entity to be inserted.
public List<entity type> findAll(): The method that finds all the
stored entities from the respective table.
o Returns: The list of stored entities.
public <entity type> findById(<primary-key-type> pk): The
method that finds a stored entity by the corresponding tables primary key.
o Returns: the entity indexed by the primary key.
public <entity type> findLast(): The method that finds the last stored
entity.
o Returns: The most recent stored entity.
public void update(<entity type> e):The method that updates a stored
entity into its table.
o Input parameter: The entity to be updated.
public void deleteById(<primary-key-type> pk): The method that
deletes a stored entity by its table primary key.
public void deleteAll(): The method that deletes all the stored entities
from the respective table.
6.1.7.2
Design
The DB schema contains the following SQL tables depicted in Figure 45:
UNADACONFIGURATION: It includes all the required unada configuration
parameters, including the bootstrap nodes IP address and port, the uNaDas MAC
address, and location, the open and private SSID name and password, and the
social, overlay and prediction intervals,
SOCIALPREDICTIONPARAMETERS: It includes the social prediction parameters
CACHE: It includes the cache configuration parameters, including the total size of
the uNaDa cache, its threshold, as well as the time-to-live for cached contents.
CONTENT: It is used to store entries for the cached contents. Its entries include
information about a contents size, url, storage path, quality and cache date and
score.
CONTENTACCESS table stores the content accesses of a specific content by a
specific facebook identifier
Page 112 of 191
Version 1.0


VIDEOINFO: The table that stores metadata for posted videos in the users
Facebook News Feed. Metadata include the publication date of the video, and its
views number.
TRUSTEDUSER: It includes the list of the uNaDas trusted users, providing the
Facebook identifier of the user, his MAC address and the last access timestamp.
FRIEND: It includes the list of uNaDa owners Facebook friends.
OWNER: It provides information about the uNaDas owner.
FEEDITEM: It stores the list of Facebook feed items, as these are published in
uNaDa owners Facebook News Feed. This table includes the content identifier, the
user Facebook identifier, the posts type and timestamp.
Figure 45: uNaDa database schema.

Figure 46 presents a class diagram including all data transfer objects and their
relationships. The class diagram maps to the aforementioned database schema.
Version 1.0
Page 113 of 191


Figure 46: Data Transfer Objects class diagram.

Figure 47 presents the class diagram for the CONTENT table DAO-related classes. The
logic is similar to the one presented in SBox DB component implementation (Section
5.1.6) and all other entities conform to this. Overall, five different classes are required to
provide read/write access to the respective table. Specifically, the ContentDAO class
provides the necessary interface to all the other components, and uses the respective
functions of the AbstractContentDAO class, which executes all the SQL insertions,
updates and queries. Additional classes, BindContent and ContentMapper provide the
necessary mapping of SQL result sets and columns to and from the respective DTO
(Content class). The following description of the aforementioned classes applies to all *,
*DAO, Abstract*DAO, Bind* and *Mapper classes.
Content
o The DTO class, which maps to the CONTENT database table.
ContentDAO
o It is the only interface used by applications either to issue commands to or
receive responses from the database. All its methods were described in
Section 5.1.6.1.
AbstractContentDAO
o The abstract class which belongs to the gen package, and implements all
SQL queries, insertions and updates. Its methods are called by respective
functions of the ContentDAO class
BindContent
o It is an interface that maps the parameters of the Content DTO class into
respective
SQL
arguments.
It
includes
a
static
class
ContentBinderFactory which implements BinderFactory interface of
the JDBI library, with the following method:
Page 114 of 191
Version 1.0


public void bind(SQLStatement q, BindContent bind,

Content arg): It maps the parameters of an sql statement in
AbstractContentDAO into Content parameters.
ContentMapper
o The class which translates the SQL arguments and results of a query into
the respective DTO class. It uses the following method:
public
Content
map(int
index,
ResultSet
r,
StatementContext ctx): The method that translates a received
resultset into an Content object.
Input parameter: index The index.
Input parameter: r The received result set.
Input parameter: ctx The statement context.
Returns: The Content object.
Version 1.0
Page 115 of 191


Figure 47: Content table DAO-related class diagram.

Besides the key functions which were described in the previous Section 6.1.7.1, and are
used to perform the basic insertions, updates and queries per primary key or for all stored
entries, a few additional and more complex queries were implemented. The complete list
of DAOs and their additional functions is presented below:
CacheDAO:
o No additional methods were implemented.
ContentAccessDAO:
Page 116 of 191
Version 1.0


o public
synchronized
List<ContentAccess>
findByContentID(long contentID): The method that finds all
accesses of the specified content id.
o public
synchronized
ContentAccess
findLatestByContentIDFacebookID(long contentID, String
facebookID): The method that finds the latest access of a specific content
id, by the user with the specified facebook id.
o public
synchronized
ContentAccess
findLatestByContentID(long contentID): The method that finds
the latest access of a specific content id.
o public
synchronized
void
deleteByContentID(long
contentID): The method that deletes all accesses of a specific content id.
ContentDAO
o public synchronized Content findByPath(String path): The
method that finds the content with the specified cache path.
o public synchronized List<Content> findByCacheType(String
cachetype): The method that finds and returns the list of contents for the
given cache type.
o public synchronized List<Content> findAllNotPrefetched():
The method that returns all contents which were not prefetched by social or
overlay prediction.
o public synchronized List<Content> findAllWithAccesses():
The method that returns all the contents that were accessed in the past.
o public synchronized long findTotalSize(): The method that
returns the total size of the cached contents, meaning the sum of the sizes.
o public synchronized List<Content> findAllOutDated(long
cacheThreshold): The method that returns the list of contents that were
cached before the given cache threshold.
o public synchronized List<Long> findAllIDs(): The method that
returns the list of stored content ids.
o public synchronized void deleteBatch(Iterator<Content>
contents): The method that deletes a list of contents.
o public
synchronized
boolean
deleteNotAccessedContent(Content
content,
long
threshold): The method that deletes a content if it was not accessed
before the provided threshold.
FeedItemDAO
o public List<FeedItem> findAllByContentID(long contentID):
The method that finds all FeedItem entries which have the content id.
FriendDAO:
Version 1.0
Page 117 of 191


OwnerDAO:
SocialPredictionParametersDAO:
TrustedUserDAO
o public TrustedUser findByMacAddress(String macAddress):
The method that finds a TrustedUser entry by its MAC address.
UNaDaConfigurationDAO
VideoInfoDAO
6.1.7.3
Tests
The list of JUnit [19] tests, which validate the correctness of the DAO functions, is
presented below:
CacheDAOTest
o public void testFunctions(): It tests all the basic functions of the
CacheDAO.
ContentAccessDAOTest
ContentAccessDAO.
o public void testThreads():It tests how the functions perform under
multiple threads.
ContentDAOTest
o public void testFunctions():It tests all the basic functions of the
ContentDAO.
o public void testBatchFunction(): It tests all the batch functions of
the ContentDAO.
o public void testThreads(): It tests how the functions perform under
multiple threads.
FeedItemDAOTest
FeedItemDAO.
FriendDAOTest
FriendDAO.
Page 118 of 191
Version 1.0


OwnerDAOTest
OwnerDAO.
SocialPredictionParametersDAOTest
SocialPredictionParametersDAO.
TrustedUserDAOTest
TrustedUserDAO.
VideoInfoDAOTest:
VideoInfoDAO.
UNaDaConfigurationDAOTest
UNaDaConfigurationDAO.
The User Interface of the uNaDa exposes the graphic interface towards the end-users to
configure the access point, monitor their cache and administrate their device. It specifically
provides the following pages and functions:
The login page, in which the user logins to the HORST Facebook application with
his Facebook credentials, and acquires administration of his device.
The settings page, where the private and public SSIDs information are configured,
The overlay page, including the overlay-related information,
The social page, where the social prediction parameters can be manually defined,
The cache page, where the cache parameters can be configured, and the list of
prefetched contents is presented, and,
The administration page, where the uNaDa administrator can monitor all the tables
and block access to external users.
6.1.8.1 Interfaces
The login page, presented in Figure 48, provides the initial page of the uNaDa towards the
end-user. The end-user logins with his Facebook credentials, and gains ownership of the
uNaDa, and initializes the social and overlay monitoring functionalities.
If the user has not registered with his Facebook credentials before, he is redirected to the
permissions page presented in Figure 49, where he must accept the HORST Facebook
application permissions.
Version 1.0
Page 119 of 191


Upon successful login, the user is redirected to the uNaDa configuration page (Figure 50),
where he may change the private and public SSIDs and passwords, as well as configure
the monitoring and predictions intervals.
Additional configuration pages include the overlay page (Figure 51), where the overlayrelated parameters (bootstrap node IP address, port, chunk size, uNaDa location) are set,
the social page (Figure 52) where the social prediction parameters can be manually
configured, and the cache page (Figure 53), where the administrator can manage the
uNaDas local cache parameters (cache size, threshold size, social and overlay prediction
score thresholds) and contents.
Finally, the administration page, presented in Figure 54, provides all the necessary tables
and functions, so that the uNaDa administrator can modify and delete trusted users, video
information and feed items.
Figure 48: The uNaDa login page.
Page 120 of 191
Version 1.0


Figure 49: The permissions page.
Figure 50: The uNaDa configuration page.
Version 1.0
Page 121 of 191


Figure 51: The uNaDa overlay configuration page.
Figure 52: The social prediction parameters configuration page.
Page 122 of 191
Version 1.0


Figure 53: The uNaDa cache management page.
Figure 54: The uNaDa administration page.
Version 1.0
Page 123 of 191


6.1.8.2 Design
The uNaDa User Interface is a Web application designed and implemented based on the
Model-View-Controller (MVC) pattern, which was already described in the description of
SBox User Interface (Section 5.1.7).
The controller layer of the uNaDa Web application is implemented by the list of controlling
bean classes presented below, also providing their mapping to the respective pages:
AdministrationBean: administration page (Figure 54).
CacheBean: cache management page (Figure 53)
DemoBean: demo page.
LoginBean: login page (Figure 48).
SocialBean: social parameters page (Figure 52).
UnadaConfigurationBean: uNaDa configuration pages (Figure 50, Figure 51).
UnadaSessionBean: The user that handles the session of the Web application
and also the response from the Facebook server, upon permissions page (Figure
49).
Each *Bean class implements all the required functions to manage its respective page.
Specifically, the Web interface pages are used to insert, edit or remove specific entries
from the respective database tables, e.g. the UnadaConfigurationBean manages the
UnadaConfiguration table, calling the respective DAO methods. Figure 55 presents
such an example and is similar to all *Bean classes.
Figure 55: UnadaConfigurationBean class diagram.

Figure 56 presents a simple sequence diagram of an UnadaConfiguration update
through the User Interface, which is triggered when the Submit button is called.
Page 124 of 191
Version 1.0


UnadaConfigurationBean calls the insert(UnadaConfiguration) function of DB

components
UnadaConfigurationDAO
class,
which
executes
the
UnadaConfiguration table update. Afterwards, the findLast() is executed, to get
all the UnadaConfiguration entries and populate the page fields. The same action
applies for all pages and methods defined above.
Figure 56: UnadaConfiguration insertion sequence diagram.

The view layer of the uNaDa Web application consists of all the pages, files and forms for
the representation of existing entries in the uNaDa database, and users request handling.
The list of files is as follows:
/: In the root directory all the Web application pages exist:
o login.xhtml: The login page (Figure 48) which provides a button for the
end-users to connect to the uNaDa Web application, with their Facebook
credentials. This button calls the login() function of the LoginBean,
redirects to Facebook servers, where user inserts his Facebook credentials,
then redirects to the permissions page (Figure 49), where user accepts the
HORST Facebook application permissions and finally redirects to the
UnadaSessionBean, initializing a new session.
o index.xhtml: The initial uNaDa configuration page (Figure 50), where
user configures the basic uNaDa parameters. This page uses
updateUnadaConfiguration()
method
provided
by
UnadaConfigurationBean to update the inserted parameters into
database.
the
the
the
the
o overlay.xhtml: The second uNaDa configuration page (Figure 51), where

the overlay-related parameters are set. This page calls the same method
from the UnadaConfigurationBean as the page above.
o social.xhtml: The social parameters page (Figure 52), where the social
prediction parameters are manually configured. This page triggers the
updateSocialParameters() function of the SocialBean to update the
parameters set into the respective database table.
o cache.xhtml: The cache management page (Figure 53), where the user
can configure the parameters of his uNaDas cache, as well as monitor and
Version 1.0
Page 125 of 191


manage the cached contents. The respective CacheBean provides a few

functions:
updateCache(): The method that updates the cache parameters

into the Cache database table.
delete(Content c): The method that deletes a specific content,

when the user pushes the respective button in the page.
o admin.xhtml: The administration page (Figure 54) where the user can
monitor all the uNaDa database tables entries and delete all or specific
ones. The AdministrationBean provides the following functions:
deleteTrustedUser(TrustedUser t): The method that deletes

a specific TrustedUser entry.
deleteVideoInfo(VideoInfo v): The method that deletes a

specific VideoInfo entry.
deleteVideoInfos(): The method that deletes all VideoInfo

entries.
deleteFeedItems(): The method that deletes all FeedItem

entries.
deleteFriends(): The method that deletes all Friend entries.
o demo.xhtml: The demonstration page, used for demonstration purposes.

css/: This directory includes all the css files used to format and style the Web
application pages. Besides, the 2 files (unada-main.css and unadalogin.css) that describe the uNaDa UI style and format, the directory includes all
the Twitter Bootstrap [22] css and theme files.
img/: It includes the image files used in the uNaDa Web application.
js/: This directory includes all the javascript files. These files are used to support
certain Twitter Bootstrap [22] components (bootstrap.js, bootstrapdropdown.js, bootstrap-modal.js, jquery.js), and support the validation
of the user input. In the second case, the bootstrapValidator.js acts as the
key element of forms validation, highlighting correct/incorrect fields and
enabling/disabling Submit button, while additional javascript files (between.js,
integer.js,
ip.js,
notEmpty.js,
mac.js,
numeric.js,
greaterThan.js) provide individual fields validation, providing relevant error
messages. In addition, there is a geolocation.js file, which is used to
automatically find the uNaDas geographical location and fill the respective fields in
the uNaDa configuration page.
WEB-INF/: This directory includes the web.xml file, including Web applications
configuration.
Besides the *Bean classes, which manage the UI pages, the current component also
implements some additional support classes. The UserSessionFilter implements the
Filter class of the javax.servlet package and handles the users session, and the
SizeConverter, MinutesConverter and HourConverter classes, implement the
Page 126 of 191
Version 1.0


Converter class of the javax.faces.convert package and transform certain pages

fields into relevant Java objects. The component also initializes all the required functions
of the Cloud Traffic Manager, namely the overlay joining, the social monitoring and the
cache management functionalities via the UIWebAppListener class. The class diagram
of the implemented classes which support these functionalities is presented in Figure 57.
The
key
class
is
the
UIWebAppListener,
which
implements
the
ServletContextListener class of the javax.servlet package, and specifically the
2 methods: contextInitialized() which is triggered before the Web application
context is initialized, and the contextDestroyed(), which is called before the Web
application is terminated. Upon contextInitialized() is called (Figure 58), all the
database tables are created and then, the bootstrap() function of
UnadaOrchestrator is called, which initializes all the Cloud Traffic Manager
functionalities and was described in Section 6.1.1.2.
Figure 57: Additional UI class diagram.
Version 1.0
Page 127 of 191


Figure 58: WebAppListener sequence diagram.

6.1.8.3 Tests
No automated tests were implemented for the User interface. The Web application was
tested during integration and system tests.
6.2
End-User
The RB-HORST End-User application allows the user to automatically connect to

encrypted WiFi networks of friends provided by the uNaDas. For this, the installation of the
Android application on the users phone is required, handling the automatic WiFi
configuration. The development of the application was focused on minimizing the
interactions required by the user, and thereby maximizing its utility. The sequence of
interactions is detailed in Figure 59.
The application is a single screen activity, and hence consists of one activity only. This
connects to the service controller, handling the individual tasks. The only call from the
Activity to the service is when the Facebook login is triggered. This loads the Facebook
login screen from the Facebook SDK, returning the user id on success, null otherwise.
The class diagram of both classes is given in Figure 60.
Page 128 of 191
Version 1.0


Figure 59: Sequence Diagram of the Facebook App.
Figure 60: Classes within the App package.

The service controller executes the tasks running in the background. These are grouped
into three different packages: the WifiService, Timers, and SDK packages. These
communicate only via the ServiceController.
Version 1.0
Page 129 of 191


The FacebookAccount package (cf. Figure 61) draws the Facebook login window on top
of the current activity when called. It also handles the communication with the uNaDa to
request the network configuration of the configured private network. Further, the network
configuration is stored in the CredentialManager.
Figure 61: Classes within the FacebookAccount package.

The WifiService package (cf. Figure 62) handles the WiFi scanning, switching and
configuration. The WifiScanner is activated if the device is not connected to a WiFi
network. It scans for networks with the SSID HORST_{*} or other known networks once
every 6 seconds. If a correct SSID is discovered, the WifiSwitcher is called with this
SSID and the corresponding key, if available. The WifiSwitcher then uses the Android
WifiManager to connect to the given SSID.
In case of the HORST_{*} SSID, and no configured private SSID the uNaDa is requested
for the corresponding network configuration. This is handles by the FacebookAccount
package.
Page 130 of 191
Version 1.0


Figure 62: Classes within the WifiService package.

The Timers package (cf. Figure 63) contains the timers required for periodic tasks and
related information. Currently, the package only contains the WifiScanTimer,
periodically triggering the WiFi scans and checking the discovered networks. If a
configured network is found, the WiFi Switcher is called to connect to the corresponding
SSID.
Version 1.0
Page 131 of 191


Figure 63: Classes within the Timers package.

The CTM package (cf. Figure 64) contains the configuration models of the discovered
uNaDas and the corresponding WiFi configurations. Further, a log handler is implemented
allowing to write important events to the system log.
Page 132 of 191
Version 1.0


Figure 64: Classes within the CTM package.

Figure 65 presents the user interface of the HORST Android application. These
screenshots include the screens where the user logins with his Facebook credentials,
accepts the RB-HORST services permissions and finally, the WiFi scanning procedure
starts.
Figure 65: Screenshots of the HORST Android Application.

The RB-HORST Android application has been made available to Google Play Store at
[40].
Version 1.0
Page 133 of 191


7 The Multi-Criteria Application End-Point Selection

(MUCAPS) mechanism
MUCAPS stands for "MUlti-Criteria Application endPoint Selection" and has been
specified in Section 4.11 of Deliverables D2.2 [25] and D2.4 [26]. MUCAPS addresses the
EFS scenario, in particular the use cases Locality in UNaDa and Service and content
placement for users. The MUCAPS added value to application traffic management and
SmartenIT is a contribution to the optimization of overlay application traffic. To this end,
MUCAPS revises the initial Endpoints selection done by the application overlay by
involving awareness on the underlying network topology and on transport costs with
information not available by traditional end to end on-line measurement mechanisms. The
selection criteria used in MUCAPS are an abstraction of end-to-end performances on
application paths. This abstraction relies itself on an ISP-centric abstraction of the Internet
topology, that is available to applications via the IETF ALTO protocol, documented in [24].
MUCAPS leverages proposed ALTO protocol extensions, extending the base protocol set
of ALTO metrics and allowing ALTO transactions with multiple metrics and constraints
combined with multiple logical operators allowing richer compromises. So MUCAPS can
help out any SmartenIT mechanism that supports applications having multiple candidate
resources locations and that have no awareness of the underlying network.
The ALTO protocol is integrated in the SmartenIT architecture: the ALTO Server stores
and provides abstracted transport network information to requesting ALTO Clients
associated to applications. However, the ALTO Client alone cannot automatically decide
what information to request and how to process it once received. MUCAPS builds the
decision making around the ALTO Client. It assists the choice of the location from which
to download content. Locations can be various entities including Video Server, Data
Center, uNaDa and Peers. Content covers video streams as well as computing resources
for virtualized or distributed applications. MUCAPS is suitable for applications having the
choice among several feasible Application Endpoints (AEPs) and supports multi layer and
multi party incentive decision making by involving the following aspects in the AEP
selection:
Topology distance: number of hops (inter or intra AS), impacting delay,
Routing cost: reflecting the ISP policy in terms of AS peering agreements,
ISP preferences in terms of resources availability (e.g., path bandwidth).
7.1
The initial selection of overlay Endpoints, referred to in MUCAPS as Application Endpoints

is usually produced by gathering functions such as DNS Servers and Clients, DHTs, Peer
Trackers and referred to in MUCAPS as Application EndPoint Gathering (AEPG)
functions. Figure 66 illustrates how MUCAPS is involved in a content downloading
scenario, as detailed in SmartenIT deliverables D2.2 [25] and D2.4 [26]. In this figure, the
term MACAO stands for Multi Access and Cost ALTO. Basically, the MACAO Client block
does (or performs) the following actions:
decides for which metrics an ALTO Client must request values,
decides which weight is applied to the metrics, and then
Page 134 of 191
Version 1.0


uses the obtained values to rank the AEPs.

Indeed an ALTO Client has no intelligence to perform these three MUCAPS operations as
ALTO is mainly a transport means for abstracted network information.
MUCAPS comprises three parts: a MACAO Service Client (MARC) that requires from the
MACAO Service interface (MARS) an additional ranking of the initial AEP selection. The
MARC is hooked to an AEPG that may call it for enhanced ranking and hands it from it the
initial list of AEPs, identified in the current implementation, by their IP addresses. The
MARS is just an interface to the MACAO block that does the actual selection and ranking.
The MACAO block with its MARS is entirely deployed in the provider network. Finally, the
MARC and the MARS communicate via a simple IP Socket carrying a light message. The
message typically includes: a list of AEP IP addresses, the MUCAPS service ID pointing
here to AEP Ranking and the number of AEPs to rank.
Figure 66: MACAO Request Service: function, interface and client.

7.1.1 Required SmartenIT components and entities
The MARC is hooked to AEPGs that in the SmartenIT architecture are typically part of an
End User Entity or the Overlay Manager where for instance the AEPG produces a sorted
list of socket addresses of providers of a resource, where the closest addresses are first in
the list. In this case, MUCAPS may revise the order of this initial list w.r.t. additional
provider network aware evaluation metrics.
Version 1.0
Page 135 of 191


Therefore MUCAPS has a footprint in the following entities where it involves the following
SmartenIT components, as illustrated in Figure 67.
The SBox: hosts the MACAO Client block and its MARS Interface to the MARC.
Note that MUCAPS is a super set including the ALTO Server and Client. Physically,
the ALTO Server and the MACAO Client block may be located on different
machines,
The Overlay Manager in the uNaDa and DC: includes an AEPG invoking the
MARC,
The AEPG in the End User Entity (EUE): in cases where an application gets a set of
candidate AEPs via an AEPG located in the end user entity. A MARC is hooked to the
AEPG that calls it to get the AEP ranking service from MUCAPS.
Thus the MARC is not in the SBox but linked to the Overlay Manager and EUEs
associated to the SBox. All decision burden is offloaded from these entities to the SBox in
the network.
7.1.2 Embedding MUCAPS on the SmartenIT architecture
The impact of MUCAPS on the architecture is shown in Figure 67 with following
modifications:
The ALTO component in the SBox is replaced by the set {MACAO block, MARS
interface and ALTO Server}. The ALTO Client is now in the MACAO block.
There is no more need to have an ALTO Client in end systems involved in overlay,
that is: Data Centers, uNaDas and End User Entities. Instead, the ALTO Client
there is replaced by the MARC that sends to the MARS in the SBox, MUCAPS
requests, that is requests to re-order the candidate AEP list w.r.t. ALTO based
network information.
The MARC is invoked by the Overlay Manager or the application of EUEs and
communicates with the MARS located in the SBox via a simple IP socket.
An alternative mapping of MUCAPS to the SmartenIT architecture is also described in
deliverable D3.3. It consists in replacing the ALTO (Client) component in the Overlay end
systems by the MARC, thus keeping the current interfaces established with
MUCAPS/ALTO replacing ALTO. This setting must however assume that the MARC can
be hooked with an AEPG function located in the Overlay Manager of the Data Center and
the uNaDa or in some appropriate place in the End User Entity.
The following SmartenIT architecture extensions are needed:
A placeholder is needed in the EUE for an AEPG that could call the MARC.
Interfaces should now be established between the MUCAPS/ALTO block and the
MARCs.
Page 136 of 191
Version 1.0


Figure 67: Entities and components involved in MUCAPS.
7.2
In the sections that follow, the implementation and deployment details of the MUCAPS
mechanism will be presented.
7.2.1 Description of the MACAO related functional blocks
Figure 68 shows details on the functions involved in MUCAPS, while the operations
sequencing will be explained in a further section.
Version 1.0
Page 137 of 191


Figure 68: Details on the functions involved in MUCAPS and operations sequencing.
The MACAO Request handling Server (MARS) InterFace (IF), bridges the MUCAPS block
with the MARC requesting evaluation and/or ranking of (S,D) pairs or application paths
and providing the initial selection of (S,D) pairs or application paths together with the ID of
the MACAO Service to request: typically Endpoint Ranking and/or Evaluation or Path
Ranking or Evaluation. The MARS IF returns the new evaluation and/or ranking of (S, D)
pairs or application paths done by MUCAPS. The MUCAPS block communicates with the
ALTO Server via its embedded ALTO Client.
The MARS receives and services requests issued, via an IP Socket, by a MARC that is
hooked to an AEPG function. For requests issued by un-trusted MARCs located in
public devices, the services include at least EP ranking and e2e Path ranking. These
services map respectively to the ALTO EP Cost Service and the ALTO Cost Map Service.
The evaluation services providing real-values are preferably restricted to trusted
MARCs since they provide numerical ISP scores or costs and are less transparent. It
returns to the MARC, via the MARS IF, the list of (S,D) EPs with requested evaluation
information: generically the rank of (S,D) pairs or e2e paths.
The MACAO Request handling Server (MARC) communicates with the MARS IF through
an IP socket, and exchanges a light data structure containing at least: the MACAO Service
ID, typically a Multi-Cost ranking or Evaluation Service, the list of application paths or
(S,D) endpoint pairs to evaluate, and fields for their values and/or rank. The MARC is
typically hooked to the function providing the initial selection of application endpoints or
paths, called AEPG for Application Endpoints Gathering Function, that can itself be
located in various places such as end user devices, the application network or its ISP
managed part. The MARC may customize its response to the calling AEPG function so as
to mimic the format of the values returned by the AEPG function so as to make the MARS
operations transparent to the applications.
The AMWS functionselects the ALTO metrics w.r.t. the application type and possibly time.
It also sets the weight associated to the metrics, w.r.t. application needs or context
Page 138 of 191
Version 1.0


information related to the UEP such as access type. The AMWM can optionally fine-tune
the metric weights w.r.t. the network access type and possibly time. The AMWM maps
metric ID and weight values to the application and other information contained in the
MARC currently by using a Look Up Table. The values of this LUT are periodically
updated from an ISP managed AMWM configuration setting function.
The AMWS Config Settings function is a Graphical User Interface (GUI) integrated in an
end system also able to access the AMWS Function. This function is to be managed by
the ISP. Via the GUI, the ALTO ON the ALTO auto metric and the ALTO auto weight
modes are activated. As an option, it updates the values associated to the configurations
mapped to groups of AEPs. For example: a group of AEP identified by their IP addresses
is identified as Video Servers. AEPs of this group must therefore be selected w.r.t. a set of
metrics including typically routing cost and bandwidth score. However, in some
circumstances as low peak hours, the ISP may consider that bandwidth score does not
need to be involved in the selection, or with a lower weight. Thus, the LUT always points
to the same file but the latter may have a varying content. A simplifying option is however
to set the values of the configuration files of the AMWS function as constant and avoid
thus implementing complex interactions.
The Multi-Criteria AEP evaluation function (MCEVAL) ranks the EPs w.r.t. the metric
values and their weights. It uses a vector-based multi-objective ranking method, based on
the proximity of a candidate solution to some ideal solution.
The ALTO Server The ALTO Server serves requests received by ALTO Clients according
to the capabilities exposed in its Information Resources Directory and specified by the
ALTO protocol (RFC7285)
The ALTO Client The ALTO Client then sends a request to the ALTO Server to get cost
values among the source and destination (S,D) endpoints (or among end to end paths for
the Path Ranking MARS Service). Its behavior complies with the specifications of
RFC7285.
The ALTO optimization information base (AOIB) This function stores, according to their
freshness, Multi-Cost ALTO responses as well as the evaluation and ranking results on
paths and endpoints pairs, so as to faster serve frequently repeated queries on the same
set of (S,D) pairs or paths.
The ALTO agent (AoA) The AoA is a central function that is hooked with all the other
functions for the sake of modularity and robustness: it knows the semantics of ALTO and
the functions using the ALTO information, passes information and requests among the
entities it is hooked with. The AoA:
Receives a Service request via the MARS Interface (IF) along with the MARS
Service ID, the list of candidate paths or source and destination endpoints (S,D)
EPs,
Checks its ALTO optimization information base to see if the needed ranking is
already available and therefore still valid,
If no stored response is available, the AoA prepares the arguments for the MultiCost ALTO request to be sent by the ALTO Client: (ALTO Service ID, list of (S, D)
EPs, cost metrics, cost mode by default numerical).
o To identify the cost metrics, the AoA calls the AMWS function,
Version 1.0
Page 139 of 191


o The ALTO Cost mode is by default numerical,

o The (S,D) pairs are included in the request sent by the MARC
o The ALTO Service ID is mapped from the MACAO Service ID (path
ranking/EP ranking)
Once the ALTO Client requests and gets the information from the ALTO Server it
hands it to the AoA that translates it into a form exploitable by the MCEVAL.
The AoA sends the ALTO-based EP information to the MCEVAL, together with the
applicable metric weights,
Once the MCEVAL has performed its multi-criteria evaluation it hands the result to the
AoA that translates it into a format exploitable by the MARS so as to be sent back to the
MARC.
7.2.2 MUCAPS implementation and execution: entities and interfaces
In the current MUCAPS deployment, the MARC is located in the ISP network. This is the
case for instance when the ISP wants to ensure that the DNS selection of the application
network is compliant to its policy in resources usage. In that case, the ISP captures the
response of its DNS Resolver, processes it with the MACAO module and sends the
MACAO selection to the DNS Resolver that sends it to the DNS Client. All this is done in a
transparent way for end users and applications.
As illustrated in Figure 69, the MACAO functional block has an external interface called
MARS for MACAO Request handling Server allowing it to comunicate with a MARS
Client (called MARC) hooked to the AEPG.
The network-side deployment enables a lightweight transaction between MUCAPS and
the ISP DNS resolver by: adding to the MUCAPS block a MARS service interface,
becoming thus a MACAO Request Server (MARS). This deployment includes the following
steps:
1. The application client queries the DNS server for the list of content servers to
download/upload from.
2. The DNS Server,
2.1. selects the MACAO Service Endpoint Ranking
2.2. hands to its embedded MARC its query result, that is the list of the candidate
Application Endpoint IP addresses, together with the IP address of the User
Endpoint, that is the DNS Client associated to the user device,
3. sends this light information to the MARS IF via an established IP Socket, as a query to
perform the multi-cost ranking of the AEPs,
4. The MUCAPS block performs the ranking and the MARS sends the reordered list of
AEPs to the MARC.
The MARC passes it to the AEPG/DNS Server that sends it to the requesting AEPG/DNS
Client.
Page 140 of 191
Version 1.0


Figure 69: MUCAPS entities and interfaces: MARC integrated in a network located
AEPG, here a DNS server.
Figure 70 shows the sequence diagram between the entities involved in the MACAO AEP
ranking. The acronym MSR stands for MUCAPS Service Request and represents a simple
object structure named alto_service, exchanged between the MARC and the MARS and
specified as follows:
struct _alto_service
{
int service_type;
char* source_endpoint;
char** application_endpoint;
int num_of_application_endpoint;
};
int service_type: is the identifier of the service requested to the MACAO
block. For the MUCAPS implementation, it corresponds to the ranking service that
re-orders the set of AEPs.
char source_endpoint[1][]: is the list of IP addresses of User Endpoints
receiving the application resources. By default, this list contains 1 element which is
the User EP
char application_endpoint[][]: is the list of IP addresses of the AEPs.
o When sent from the MARC to the MARS, this list is ordered following the
DNS transaction
o When sent from the MARS to the MARC, this list is re-ordered by the
MACAO block, in decreasing order of performance level, so that the best
AEP is listed first.
Version 1.0
Page 141 of 191


int num_of_application_endpoint: the number of AEPs.
Figure 70: Interaction between entities involved in the MACAO AEP ranking.
The ALTO Client and ALTO Server communicate according to RFC 7285 [24]. The
requested ALTO Service is the Endpoint Cost Service as specified in RFC 7285 [24].
The communication between the DNS Server AEPG, the MARC, the MARS and the
MACAO Block is depicted in Figure 71.
The MARS has received the MSR structure _alto_service described above. It then
initiates a structure called struct _altoa_endpoint_evaluate_service_t specified
below.
struct _altoa_endpoint_evaluate_service_t
{
struct _altoa_alto_config_t* config;
struct _altoa_endpoint_evaluate_request_t* request;
struct _altoa_endpoint_evaluate_reply_t* reply;
struct _altoa_endpoint_evaluate_result* result;
int (*request_set)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv,
int service_byte,
endpoint_address* eps_src,
int num_of_eps,
endpoint_address* eps,
int num_of_metrics,
int* metrics,
double* metric_weights,
int topN);
int (*perform)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv);
Page 142 of 191
Version 1.0


int (*destroy)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv);

int (*result_get)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv,
char** str_result);
};
The functions of this structure are performed by the MACAO block.

request-set(): calls the AMWS module to identify:
o the missing arguments of the ALTO request (besides the endpoint
addresses), which are metric types (int* metrics).
o The metric weights that will be used by the MCEVAL module.
o topN: is by default equal to num_of_application_endpoint,
maximum number of ordered AEPs to be used for the application.
the
Perform():
o Gets the performance values for the AEPs on the set of metrics int*
metrics from the ALTO Server via the ALTO Client.
o Calls the MCEVAL module to order the set of (eps_src, eps) w.r.t. their
metric value and weight.
Result-get(): shapes the resulting ranking for the MARS and MARC
communication semantics.
Version 1.0
Page 143 of 191



Figure 71: Interaction between the DNS Server AEPG, the MARC, the MARS and the MACAO Block.
Page 144 of 191
Version 1.0


7.2.3 In-network transparent deployment

MUCAPS has been deployed as an in-network overlay traffic management mechanism as
illustrated in Figure 72. The MUCAPS service, in this case is requested by a MARC
hooked to an AEPG located in the ISP network. In the evaluated deployment, the APEG is
the DNS resolver located in the ISP network and connected to the DNS client located at
the UEP side.
MUCAPS has been implemented and demonstrated as a prototype. Functional platform
tests have been conducted to verify whether MUCAPS behaves as expected in the
specifications. Besides, it has been evaluated w.r.t. the performance metrics mentioned
above. MUCAPS attempt to optimize performances that go beyond the sole user
perceived QoE, in particular OPEX in terms of ISP routing costs.
The prototype has been tested with a set-up illustrated in Figure 72 and composed of the
following entities:
A End-User (EU) device with a DNS client and a VLC client,
An AEPG which is a DNS Server with a MARC,
An ALTO Server,
A MARS hooked to the MACAO block and with an interface to the MARC,
3 video servers corresponding to AEP1, AEP2, AEP3.
Figure 72: MUCAPS demonstration and functional evaluation setup.

The MUCAPS deployment has led to the following implementations:
The MARC, MARS and MUCAPS block have been implemented in C,
Version 1.0
Page 145 of 191


The DNS Server code is the open source djbDNS suite implemented by D.J.
Bernstein, that allowed thus to integrate the MARC and its interaction with it,
The ALTO Server is a reference implementation in Java.
The functional behavior of MUCAPS is assessed by computing the numerical performance
of the selected EPs in different scenarios, mainly with or without MUCAPS. When
MUCAPS is activated, cases are further refined to evaluate performances when one or
more metrics are selected.
Page 146 of 191
Version 1.0


8 The Virtual Incentives (vINCENT) mechanism

The vINCENT mechanism addresses the end-user focused use case Mobile offloading
from cellular communication to WiFi. It was specified in Deliverable 2.2 [25] and
Deliverable 2.4 [26]. vINCENT provides an incentive for users to open their access point to
other users. The mechanism interacts with the RB-HORST mechanism in a well-defined
way and can be understood as an extension to the respective mechanism specification.
Conceptually, vINCENT replaces the offloading mechanism of RB-HORST.
vINCENT has a distributed nature. The main part runs on a user controlled Nano
Datacenter (uNaDa), which is established on the end users home router. The mechanism
assumes a flat rate pricing scheme for the access. Moreover, he has to install the
vINCENT firmware to his home router, and he needs a Facebook account. He has to
install a Facebook app which is part of the vINCENT mechanism and is responsible for
user authentication and manages the access to WiFi.
Just as RB-HORST, the vINCENT firmware establishes two separate WiFis (a private and
a shared WiFi) and enables mobile data offloading by broadcasting a special SSID (of the
shared WiFi) which can be recognized by a mobile device. Every vINCENT user can
request access to the shared WiFi of every uNaDa. An offloading, mobile users
connection quality is shaped by the mechanism according to the offloading services
provided by the users very own uNaDa.
8.1

Datacenter
ove1
Datacenter
Traffic
Redirector
Load
Balancer
Workflow
Manager
Hypervisor
Overlay
Manager
S-Box
iscs1
Inter-Sbox
ALTO
Energy
Monitor
eco1
Economics
Analyzer
Traffic Manager
UI
Social Analyzer
ntm1
Fixed/Mobile
DB
SDN Controller
soc2
Network
Analyzer
QoS/QoE Analyzer
uNaDa
DB
UI
Energy
Analyzer
ALTO
qos1
ove1
qoe1
top2
top1
Overlay Manager
Topology/
Proximity Monitor
QoS/QoE
Analyzer
Network Entity
qoe1
End User Entity
qos1
soc2
soc2
ene1
soc1
Energy
Analyzer
Topology/
Proximity
Monitor
Switching/
Forwarding
Energy Monitor
ene1
Switching/
Forwarding
Traffic Manager
Vimeo
QoS Monitor
Topology/
Proximity
Monitor
Social Monitor
Energy Monitor
Energy Monitor
QoE Monitor
QoS Monitor
Social Analyzer
Social Monitor
ene1
ove2
Cloud Traffic
Manager
soc3
ntm2
Facebook
ALTO
DB
UI
Figure 73: VINCENT mapping to the SmartenIT architecture.

The RB-HORST-VINCENT mechanism implements the elements marked as dashed
boxes in the architecture diagram. It mainly affects the following components and entities:
Version 1.0
Page 147 of 191


Table 8-1: Component/Entity mapping

End-User Entity
SBox
uNaDa
Overlay Manager
Offloading History,
Regression Model
Calculation
WiFi Access
Provisioning
Social Analyzer
and Monitor
Friendship Relation
Analysis
Fixed/Mobile
Traffic Manager
WiFi Mgmt on
Laptop
The basic logic is defined by the SBox, which is an entity providing a complete view of the
offloading acitivies in the network and serves as secure endpoint for terminating offloaded
connection via VPN. This endpoint can be provided by a Telco provider to extend the base
of hotspots or a social data provider such. The Overlay Manager component, the
offloading history of all access points is recorded and the regression model calculation as
defined in D2.2 [25] /D2.4 [26] is performed to calculate offloading scores for all users of
the system based on their provided service. Moreover, the SBox can analyze the social
relations between users and can also grant unlimited access to users based on direct
relationships, which is essentially the offloading as initially defined by the pure RB-HORST
mechanism. On the uNaDa, the Overlay Manager manages the provisioning of the WiFi
networks, while the Fixed/Mobile Traffic Manager handles the accessing of WiFi networks
to be used for offloading.
8.2
The interfaces are illustrated in Figure 74 and are described as follows: The abstract class
IOffloadingStrategy provides basic features for saving histories and manages the uNaDato-owner relationships. It owns an object of the type IOffloadingDataType allowing to
define different data types that can be used to estimate an access points performance
using a regression model as described in D2.2 [25] / D2.4 [26]. In particular, an accounting
for provided Volume, Bandwidth, and Session count, i.e., the number of offloaded WiFi
sessions at a certain uNaDa is implemented.
IOffloadingStrategy is implemented by IWithGracePeriodStrategy. This subclass of
IOffloadingStrategy performs a preparation of history data. Th class IncentiveStrategy
implements the regression model calculation using the GNU Scientific Library and
provides means to determine the service that should be provided for a given uNaDa and
mobile user relation.
Page 148 of 191
Version 1.0


Figure 74: Interfaces developed in the scope of VINCENT.

The history structure that is maintained by IOffloadingStrategy is shown in Figure 75.
Every access point has a list of already connected clients. The clients have a tuple of
session-IDs (how often they have connected to the respective access points) and the
amount of offloaded data. Consequently, the data structure contains all data on which the
Volume, Bandwidth, and Session classes rely.
Figure 75: History Data Structure.

The VINCENT was implemented in C++ as a simulation model for OMNET++.
Nevertheless, OMNET offers possibilities to perform a deployment on a testbed.
Version 1.0
Page 149 of 191


Figure 76: Deployment Entities.

In the model as well as in the real-world deployment, the role of the SBox is taken by an
HTTP server (server) that is also acting as a proxy for all content requested. All devices
are connected via a single router. The access points (ap) run a DHCP server (dhcpServer)
to handle the configuration of IPs. Finally, the mobile client accessing the WiFis for mobile
offloading is represented by a laptop.
Page 150 of 191
Version 1.0


9 The Mobile Network Assistant (MoNA) mechanism

The Energy Aware Mobile Traffic Management intially focused on reducing the energy
consumption on mobile devices by intelligently scheduling network traffic generated on the
mobile device. Offloading traffic using WiFi networks can save between 75% and 90% of
the energy used for network transmissions compared to 3G connectivity [36]. At the same
time, the risk of network caused stalls may be reduced by increased data rates on WiFi,
improving the QoE of the end-user. The traffic management is based on QoS maps, user
mobility prediction, energy models, and QoE models. As core functionalities, the energy
models and a monitoring framework remain.
Consequently, as part of the project, means for measuring and predicting energy
efficiency of network access were implemented and a monitoring framework was provided.
In the following, the general purpose monitoring implementation for smart phones and
uNaDas is presented.
9.1

Datacenter
ove1
Datacenter
Traffic
Redirector
Load
Balancer
Workflow
Manager
Hypervisor
Overlay
Manager
S-Box
iscs1
Inter-Sbox
ALTO
Energy
Monitor
eco1
Economics
Analyzer
Traffic Manager
UI
Social Analyzer
ntm1
Fixed/Mobile
DB
SDN Controller
soc2
Network
Analyzer
QoS/QoE Analyzer
uNaDa
ALTO
DB
UI
Energy
Analyzer
qos1
ove1
qoe1
top2
top1
Overlay Manager
Topology/
Proximity Monitor
QoS/QoE
Analyzer
Network Entity
qoe1
End User Entity
qos1
soc2
soc2
QoS Monitor
Topology/
Proximity
Monitor
Switching/
Forwarding
Topology/
Proximity
Monitor
Social Monitor
ene1
Energy Monitor
Energy Monitor
QoE Monitor
QoS Monitor
Social Analyzer
Social Monitor
ene1
ove2
Cloud Traffic
Manager
soc3
ntm2
soc1
Energy
Analyzer
Energy Monitor
ene1
Switching/
Forwarding
Traffic Manager
Vimeo
Facebook
ALTO
DB
UI
Figure 77: MoNa mapping to the SmartenIT architecture.

The MoNa energy efficiency mechanism implements the elements marked as dashed
boxes in the architecture diagram. It mainly affects the following components:
Table 9-1: Component/Entity Mapping
Energy
End-User Entity
uNaDa
Measurement of
Measurement of
Version 1.0
Page 151 of 191


Monitor/Energy
Analyzer
smartphone energy
efficiency
uNaDa energy
efficiency
The basic logic is implemented in the Energy Monitor/Energy Analyzer component of the
respective entity. In particular, a number of classes were implemented to record and store
system utilization data. Moreover, a set of hardware-validated power models were
implemented to convert the system utilization data into energy measurements.
9.2
In the following, the measurement framework implementation for uNaDas, in particular,

the Raspberr PI used as a uNaDa platform is described, as it is representative for the
smart phone measurements as well.
The RaspberryPIMeasuerment Project provides classes to observe measurements for
RaspberryPi device. The implementation follows the observer pattern with a few
extensions to compute and store power measurements.
Figure 78: Basic pattern of monitroing implementation.

The main actors of the pattern are the PowerMonitor and MeasurementObserver Java
classes. In this case the observeable is the PowerMonitor and the observers are other
devices or applications that are interested in the measurements. The
MeasurementObserver class is an extension of the Observer class. It includes a circular
FIFO buffer and a Hash map of all registered observable devices. Every new observed
measurement is stored in the circular buffer.
Figure 79: Device Power Model Class.
Page 152 of 191
Version 1.0


The DevicePowerModel class serves as an abstraction of the devices power model, in

this case the RaspberryPi device. In order to augment varying power models for the
devices in experiments, it is possible to randomize the variance of the power by passing a
variance parameter in constructor. The main method of this class is the
getPowerConsumption() method. It returns the most current measurement depending on
the utilization and device information.
Figure 80: PowerMonitor Class.

The PowerMonitor class maintains the DevicePowerModel and device Information.
Furthermore it has a calculatePowerMeasurement() method, to compute the current
measurement of the given DevicePowerModel. At the end of the computation all
registered observers will be notified about the new measurement.
For testing purposes, there are regression tests in the Monitor package. In particular, the
UtilizationGeneratorExample class serves as a main test class. It provides a genUtil()
method to generate utilization, defaultDeviceInfo() to create device information based on
RaspberryPi device and a run() method to execute the test. After executing the
UtilizationGeneratorExample class, an output the observed power measurements and the
device name is dumped to the console. The computation happens using the given
sampling interval.
The power monitoring framework can run stand alone or can be integrated in the
Facebook App and RB-HORST software. The diagram below shows a sample deployment
as demonstrated for the SmartenIT Advisory Board Meeting. Therefore, the Energy
Monitoring instance was deployed on two smartphones and a uNaDa, which were invoked
from a remote energy analyser instance running on a measurement server and visualizing
the consumption of the devices in the network.
Version 1.0
Page 153 of 191


Figure 81: MONA Deployment as demonstrated during SmartenIT Advisory Board

Meeting.
Page 154 of 191
Version 1.0


10 The SDN-based DC selection (SDNDC) mechanism

The collaboration of Internet Service Providers (ISPs) and Cloud Service providers was
shown to be beneficial for both parties in a number of recent works. Influencing Cloud
Service data center (surrogate) selection allows the ISP to manage the rising amount of
traffic originated from cloud services in order to reduce the Operational Expenditures
(OPEX) of the infrastructure, e.g., by preventing peered traffic.
At the same time, including the ISPs hidden network knowledge in the surrogate selection
process influences the Quality of Service (QoS) a cloud service provider can deliver
positively. As a large amount of cloud traffic is Video on Demand (VoD) traffic [38], this
work investigates the topic of Cloud Service/ISP collaboration from a perspective of high
volume, long living flows. These types of flows are hardly manageable with state-of-the-art
Dynamic Name Service (DNS) based redirection, as a reassignment of flows during the
session is difficult to achieve. Consequently, varying load of surrogates caused by flash
crowds and congestion events in the ISPs network are hard to compensate.
SDN based DC selection (SDNDC) presents a novel approach promoting ISP and Data
Center collaboration based on a minimal deployment of Software Defined Networking
(SDN) switches in the ISPs network. The approach complements standard DNS based
redirection as used by many cloud service providers and CDNs by allowing for a migration
of high-volume flows between surrogates in the backend even if the communication has
state information, such as HTTP sessions. In the following, the proof of concept
implementation done in the course of the SmartenIT project is presented.
10.1 Mapping to the SmartenIT Architecture

Datacenter
ove1
Datacenter
Traffic
Redirector
Load
Balancer
Workflow
Manager
Hypervisor
Overlay
Manager
S-Box
iscs1
Inter-Sbox
ALTO
Energy
Monitor
eco1
Economics
Analyzer
Traffic Manager
UI
Social Analyzer
ntm1
Fixed/Mobile
DB
SDN Controller
soc2
Network
Analyzer
QoS/QoE Analyzer
uNaDa
DB
UI
Energy
Analyzer
ALTO
qos1
ove1
qoe1
top2
top1
Overlay Manager
Topology/
Proximity Monitor
QoS/QoE
Analyzer
Network Entity
qoe1
End User Entity
qos1
soc2
soc2
ene1
soc1
Energy
Analyzer
Topology/
Proximity
Monitor
Switching/
Forwarding
Energy Monitor
ene1
Switching/
Forwarding
Traffic Manager
Vimeo
QoS Monitor
Topology/
Proximity
Monitor
Social Monitor
Energy Monitor
Energy Monitor
QoE Monitor
QoS Monitor
Social Analyzer
Social Monitor
ene1
ove2
Cloud Traffic
Manager
soc3
ntm2
Facebook
ALTO
DB
UI
Figure 82: SDNDC mapping to the SmartenIT architecture.
Version 1.0
Page 155 of 191


The implementation of the SDNDC mechanism affects the Overlay Manager in the
Datacenter and the Cloud Traffic Manager and SDN Controller in the SBox, which is
owned and operated by the ISP. Moreover, the network entities of the ISP are affected for
redirecting flows (Switching/Forwarding), as well as the QoE Monitor running on the End
User Entity.
Data Center
SBox
Network Entity
End-User Entity
Decides on
redirection of traffic
(jointly with Cloud
Traffic Manager)
Cloud Traffic
Manager
Decides on
redirection of traffic
(jointly with Overlay
Traffic Manager)
SDN/Contoller,
Switching,
Forwarding
Dynamic redirection
of traffic by
rewriting flows
Dynamic redirection
of traffic by
rewriting flows
Monitor QoE and

signal Overlay
Manager if quality
drops due to
congestion
Overlay Manager
QoE Monitor
The basic meachnisms of the implementation work as depicted in the Figure shown
below.
Figure 83: SDNDC Selection mechanism overview.

Before going into the details of the implementation, a brief overview of the involved entities
is given following the illustration in Figure 83. The proposed architecture consists of a
single-tier approach based on a minimal deployment of SDN switches at the edge of the
ISPs network. As a main building block, the Overlay Manager (OM) inside the ISPs
network is introduced.
1) First, the client requests content from a cloud provider. The URL of the request is
resolved recursively by an authoritative DNS server. Contrary to the usual
Page 156 of 191
Version 1.0


redirection the DNS-record points to the next ISP owned OM. From this point on,
the request is handled within the ISPs network, only.
2) The OM terminates the TCP session of the user as if the OM would deliver the
actual content. In parallel the optimal Data Center (DC) surrogate capable of
delivering the content is calculated and selected by the OM.
3) Without requiring another HTTP redirect, the complete state of the TCP and HTTP
session representing the connection to the client is migrated from the OM to a
suitable DC surrogate. In order to ensure a seamless migration, the OM takes care
of signaling the edge Broadband Remote Server (BRAS) close to the client.
Extended with an OpenFlow switch the ows from and to the client are redirected to
ensure a working migration of the TCP ow.
4) Finally, the content is delivered to the client from the selected DC surrogate. The
process itself is transparent for the client only involving the resolving of a content
URL without any HTTP redirects. If necessary, the OM can reassign the flow to
another DC surrogate whenever necessary.
10.2 Implementation and Deployment

10.2.1 Implementation Environment Description
Figure 84 : Overview of Implementation and Deployment

As a testing environment for the implementation, a virtual machine based setup was
chosen. The implementation is running on four VMs. As a hypervisor, Kernel-based Virtual
Machine (KVM) running on an Intel i7 (4 cores, Hyper Threading) based machine is used.
All VMs are congured to use each one core and between 512 MB RAM and 1024 MB
RAM depending on the demands of the tasks they execute. The setup of the VMs was
carefully chosen such that the limitations of virtual RAM and CPU do not impose a
bottleneck.
Version 1.0
Page 157 of 191


The interaction and tasks of the VMs is depicted in Figure 84. The ISPs topology is
running on a dedicated VM (Mininet VM) using the Mininet tool. For experiments, this VM
can easily be substituted by a real network. Mininet allows for the emulation of OpenFlow
switch topologies. Core switches are emulated by means of the Open vSwitch software
switch (version 1.9) supporting OpenFlow 1.1.
In order to assess whether the approach is applicable in ISP networks, it is necessary to
evaluate it using realistic ISP topologies. A number of scripts running inside the Mininet
Test Environment VM sets up topologies parsed from well known ISP databases such as
TopologyZoo. An additional set of scripts (Topology/Route/Latency Setup) sets up the
topology, the routes based on shortest path calculation, and allows varying latency
between switches during the experiments. The setup relies on an OpenFlow controller
built on top of the Ryu controller software.
Moreover, the Mininet VM is dynamically congured to provide a number of virtual
interfaces, thus enabling access from the other VMs to an edge node of the topology. The
connection of edge nodes and virtual interfaces can be randomized between the
experiments to measure the variance caused by the topology. Furthermore, it is possible
to emulate congestion by dening ne grained parameters along a specic path.
A Python-based Ryu controller app communicates through a REST interface with the OM
application and pushes rules to the edge switches. The other VMs (OM, Surrogates and
End-User Entity VM) are connected to the virtual interfaces of the Mininet VM using a
software switch running on the hypervisor.
10.2.2 Implementation
Since the implementation is built aut of several distinct components Figure 85 provides an
overview. The complete system is a collaboration of distinct software parts which mainly
communicate via HTTP. Experiments are loaded via a shell script which then starts
automatically a predefined testing environment.
Figure 85: Overview of Prototype implementation.
Page 158 of 191
Version 1.0


The deployment consists of an ISP topology which is represented by a Mininet topology.

Switches inside the topology are represented by connected Open vSwitch bridges. The
bridges communicate via the Open Flow protocol with the Topology-App which runs inside
the RYU-Framework. DC surrogates and users are controlled via a Representational State
Transfer (REST) interface, just as the Topology-App.
The rest of the description is structured as follows. Mininet and the topology parser are
presented rst followed by the RYU framework and the Topology-App. Furthermore, the
server and client application and the stall detection are described.
10.2.2.1
ISP Topology Emulation
The following describes the topology parser and how to couple the topology to a real
network. Topology and Mininet run inside one dedicated VM as shown in Figure 87. The
topology information is loaded via a script as explained earlier. Furthermore, real
interfaces can be connected to the topology at every node as if they were a part of the
topology.
In order to evaluate different ISP topologies it is necessary to extend Mininet with the
capability of loading arbitrary topologies. Several topology formats are supported by the
implementation. Furthermore, it is possible to annotate the complete topology with Mininet
information like port numbers, link information and weights. All this information is retrieved
automatically by the Topology Parser and added to the topology before it is serialized.
This information is needed later on to set up the static routing information.
In order to decouple the emulation of the topology and the client and server application,
arbitrary network interfaces can be added to the Mininet topology. This enables the
topology to be used with multiple VMs or real network hardware without affecting exibility
of the Mininet approach. A node from the Mininet topology can be picked to be assigned
to a network interface, which can be any Linux interface like an Ethernet device or even
another virtual interface. The according Open vSwitch instance is congured to add the
newly assigned interface as a new port. In parallel to the switch instances, the Mininet
topology information is updated with the newly available egress and ingress port on the
chosen switch. The information is required later on to ensure that routing rules are
correctly installed. Furthermore, it is important to verify that the added interface accepts all
the trafc passing through and the correct conguration of the connected network. As an
alternative or extension to the Open vSwitch it is thus also possible to include real
switching hardware in the topology.
In order to provide reproducible randomness throughout the experiments, a random node
assignment of the DC VMs to the Mininet topology based on fixed seeds is provided.
10.2.2.2
Overlay Manager/Open Flow Controller Application
The controller represents the control plane of the network and is responsible to congure
the underlying (virtual) hardware correctly. Multiple frameworks exist supporting the
implementation of network applications which can be easily deployed.
Using the Ryu framework, the prototype implements a topology application which handles
routing and rerouting inside the Mininet topology. The newly implemented Topology App
building upon the existing wsgi and switch application provides a simple HTTP server for a
Version 1.0
Page 159 of 191


REST interface enabling the remote conguration of the controller. Switch lookup by name
in the topology is provided by the switches application.
OpenFlow events are distributed through events like explained in the previous paragraph.
The topology application is responsible to emulate the nearly static routing behaviour in
ISP topologies and for the proposed dynamic rerouting. Based on the Mininet topology
and knowledge of the location of IP subnets the controller pushes OpenFlow rules to the
switches. Topology and changes can be dynamically submitted to the controller by using
the REST interface. The REST interface is shown in Figure 86 and only uses HTTP GET
operations for the sake of simplicity. Requests are used by the experiment to enable
routing for a new topology or set the migration rule for a number of clients. If, for example,
a Type of Service rewrite is deployed, a new Open Flow rule is submitted to the edge
switches.
Figure 86: REST interface of OpenFlow controller

10.2.2.3
Video Streaming Application and Server
The video streaming application consists of a server app mimicking the DC surrogate and
a client application which receives the streamed video content. Both applications need to
be capable of dynamically setting the ToS eld in the IP header. Moreover, they are
capable to implement different buffer behaviours which are derived from real world
measurements. Additionally, in order to quantify changes in the QoE the client implements
a video stall detection mechanism.
The server application represents the DC surrogate streaming server. In order to provide a
preferably small memory footprint and maximum performance, the application is written in
C. After a client has connected, the server waits for requests for new content of the client
application.
As stated before, both applications implement a dynamic changing of the ToS field, which
is used to match the flow using OpenFlow. The flow is dynamically redirected to another
DC depending on the ToS field as depicted in Figure 87.
Page 160 of 191
Version 1.0


Figure 87: Dynamic ToS redirection - FlowTable

For more details on the SDNDC mechanism and the underlying implementation, please
refer to [37].
Version 1.0
Page 161 of 191


11 System Releases
As indicated in Section 4.2.1, the agile development model was adopted and the
development work for the two prototypes, DTM and RB-HORST was divided into small
release cycles. Each release cycle either introduced new features, or resolved issues from
previous releases.
The complete list of SmartenIT system releases, their changelog and release dates are
presented in Table 11-1.
Table 11-1: Summary of SmartenIT system releases
Version
Changelog
implementing
Release Date
Notes
1.0
Initial version,
mechanism.
DTM 15/07/2014
1.1
Fixed reference vector calculation in 26/08/2014

Economic Analyzer, added central
dependencies
and
plugins
management.
Open-source
1.2
New tunnel identifier and inter-domain 18/11/2014

link identification based on tunnel end
addresses, added support for multiple
traffic receiving DCs, and added
feature to QoS Analyzer to write
received traffic details to file.
Open-source
2.0
Second version, implementing RB- 20/11/2014

HORST mechanism.
2.1
Fixed social prediction algorithm 11/02/2015

candidates, introduced enhancements
in
content
advertisement
and
neighboring in the overlay network,
updated content prefetching to
consider AS hops towards the overlay
peers, and added demonstration
enhancements in uNaDa and enduser
user interface.
Open-source
3.0
Support for 95th percentile billing rule, 12/02/2015

added new system control variables
and time schedule parameters, added
SDN Controller operation modes
(proactive vs reactive), Compensation
vector handling in Network Traffic
Manager to reduce the number of
updates
sent
towards
remote
domains.
Open-source
3.1
Added BG router configuration using 30/04/2015
Will be released
Page 162 of 191
Version 1.0


NETCONF protocol, support for delaytolerant traffic management, and

introduced new compensation vector
calculation in the case when reference
vector is achieved on one or more
links.
as open-source.
The following sections will present the full list of features, issues and tests for each of the
aforementioned versions, excluding version 1.0, which was described in D3.2 [2].
11.1 Release v1.1

Version 1.1 was the first sub-release of v1.0, which was presented and documented in
D3.2 [2].
11.1.1 Features
Its purpose was a fix in the reference vector calculation algorithm in Economic Analyzer of
SBox, and some additional support code fixes and improvements (Figure 88).
Figure 88: v1.1 features.

11.1.2 Tests
The test cases were the same as v1.0 and were documented in Appendix A of D3.2 [2].
11.1.3 Issues
No issues were found during tests and v1.1 was successfully released.
11.2 Release v1.2

Version 1.2 of the SmartenIT software includes a set of improvements and additional DTM
features.
11.2.1 Features
Based on the updated version of DTM specification a set of JIRA issues was identified.
These are presented in Figure 89.
The major changes introduced in this version are the following:
new tunnel identifier and inter-domain link identification based on tunnel end
addresses;
Version 1.0
Page 163 of 191


added support for multiple traffic receiving DCs;

added feature to QoS Analyzer to write received traffic details to file.

11.2.2 Tests
After the implementation of all improvements and additional DTM features planned for
release v1.2 a set of integration tests were executed. First of all already implemented tests
for releases v1.0 and v1.1 presented in Appendix A of D3.2 [2] were updated and
executed to verify that recent changes in the code did not break the already implemented
and tested functionalities. In addition some new test cases were designed, implemented
and executed. These test cases are described in Table 11-2.
Table 11-2: v1.2 integration test cases.
Description
Components
Environment
Configuration/Execution
Expected Outcome
Complete
chain
with
total traffic
volume
based
charging
rule and one
receiving
DC.
QOA,
NTM,
SBox
JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client
NTM at sending domain is

initialized
with
mocked
SBox-SDN client which is
later on used to verify
interactions with the SDN
controller.
Inter-SBox
server is launched. At the
receiving domain NTM,
Economic Analyzer and
QoS Analyzer components
are
initialized.
Mocked
DAOs are used instead of
the real DB and return
preconfigured
structures
representing two domains
with two inter-connected
DCs.
Values of C and R vectors

passed to SBox-SDN client
are verified against known
values.
ECA,
inter-
QoS Analyzer reads preconfigured counter values

from
mocked
SNMPWrapper, calculates
X and Z vectors and
Page 164 of 191
Version 1.0


passes them to ECA and

NTM. ECA calculates R
vector after accounting
period. NTM calculates C
vector after each reporting
period and updates remote
NTM with new C and R
(after accounting period)
vectors. Received C and R
vectors are passed to a
mocked instance of SBoxSDN client.
Test
is
run
for
4
consecutive
accounting
periods.
Complete
chain
with
total traffic
volume
based
charging
rule and two
receiving
DCs.
QOA,
NTM,
SBox
Basic Sanity
testing
for
release v1.2
ALL
ECA,
inter-
JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client
Initialization of components
is performed as in previous
test but in this case there
are two receiving domains.

values.
C and R vectors are sent to

sending NTM from two
receiving NTMs.
Test
is
run
for
4
consecutive
accounting
periods.
WP4 testbed
at PSNC.
Configure the database of

each
SBox
with
the
required
domain
information.
No exceptions or logs that

indicate failures.
Run 1 SBox in receiving

domain. Run 1 SBox and 1
SDN controller in sending
domain.
Compare logs and verify

that
reference
and
compensation vectors are
sent to the sending domain,
and then to the SDN
Controller.
SDN
controller
should
initially
receive
the
configuration data.
Verify that test traffic

generated between DCs is
distributed through tunnels.
QOA in receiving domain

reads
counters
from
deployed software routers
and provides X and Z
vectors to NTM and ECA.
Periodically, the R and C
vectors are sent to the
SBox in the sending
domain and then the SDN
controller is also updated.
11.2.3 Issues
No major issues were identified during the integration testing. After issues were fixed v1.2
was released successfully.
Version 1.0
Page 165 of 191


11.3 Release v2.0

Version 2.0 is the first release implementing features of the RB-HORST mechanism.
11.3.1 Features

This release includes all the RB-HORST basic functionalities, including:
uNaDas overlay creation, and maintainance,
Overlay prediction algorithm,
Page 166 of 191
Version 1.0


Social monitoring from Facebook and Vimeo,

Social prediction algorithm,
WiFi offloading for trusted users,
Video caching and prefetching,
User requests proxying and serving from local Web server.
11.3.2 Tests
To test the integrated RB-HORST prototype, a simple testbed was designed and deployed
(Figure 91). It consists of 3 NSP domains, 2 access (AS1 and AS3) and 1 transit one
(AS2), and 3 users (Andri, Sergios and George), each one having Internet access through
their respective ISP. The transit NSP provides access to the rest of the Internet, e.g.
Facebook and Vimeo servers.
In each users premises there is a uNaDa, which is a Raspberry Pi hosting the RB-HORST
software, is assigned to him with his Facebook credentials and provides 2 SSIDs, one
open but with no Internet access, and one private with full Internet access. In addition,
each user owns an Android smartphone to access the Internet, with RB-HORST Android
application and at least a Web browser, installed. Of course, depending on the
experiment, we could have multiple users, with their respective Android smartphones,
accessing and connecting to the uNaDas.
Figure 91: FB-HORST integration testbed.
Version 1.0
Page 167 of 191


Version 2.0 integration tests included both tests performed in 2 uNaDas, specifically
Sergios uNaDa B and Georges uNaDa C, as well as JUnit tests, which integrate and test
certain components. Table 11-3 presents the description, involved components,
configuration and outcome of v2.0 integration tests.
Table 11-3: v2.0 integration tests.
Description
Components
Environment
Expected Outcome
uNaDa Web
interface
UI,
DB,
Facebook
Application
uNaDas
A
and B of RBHORST
testbed
Successful Facebook login

for both users.
Each user becomes owner
of the uNaDa, meaning that
no one else can access it.
Successful
uNaDa
parameters configuration.
uNaDa
REST API
DB, uNaDaEnduser
interface
uNaDas
A
and B of RBHORST
testbed
HORST
Android
Application
+
uNaDa
REST API
Enduser
application,
DB, uNaDaEnduser
interface
uNaDas
A
and B of RBHORST
testbed
Social
Monitoring
SM,
DB,
Facebook
application,
Vimeo
Junit tests
Initialized uNaDa software

in both RPis, accessed
uNaDas Web interface
from N5s.
George Petro logins to RPi
A and Sergios Soursos to
RPi B, both using their
facebook credentials. They
both configure their uNaDa
properties
and
logout.
George Petro tries to
access RPi B.
in RPi A.
George Petro calls the
REST API from the N5
browser, using his
facebook ID, and the REST
API should return the wifi
configuration of the private
SSID.
Sergios calls the REST API
using his facebook ID, and
the REST API should return
the wifi configuration of the
private SSID, because he is
Georges friend, thus a
trusted user.
Random user tried to call
the REST API, but receives
negative response.
in RPi A.
Sergios Soursos enables
WiFi in his N5 B, and opens
the Android application.
Logins to Facebook and
waits to connect to the
private SSID of George
Petros uNaDa (RPi A).
JUnit tests using George
Petros access token.
The tests check whether
social monitor fetches all
required information.
Social
Analyzer
SM, SA, DB,

Facebook
Junit tests
JUnit tests using George

Petros access token.
Page 168 of 191
Owner receives private

SSID credentials.
Trusted users receive
private SSID credentials.
Non trusted users always
receive a negative answer.
Connect to remote uNaDa

private SSID and gain
access to the Internet.
Social Monitor should fetch

Georges friends, his and
his friends feed items, and
also save them in the
database. It should also
fetch video information from
Vimeo and store them as
well.
Version 1.0


Prediction
application,
Vimeo
Cache
managemen
t
CTM,
Vimeo
DB,
Junit tests
Proxy
requests
CTM,
Vimeo
DB,
Junit tests
URI
rewriting
CTM, DB
uNaDa
SM,

social monitor fetches all
required information, and
then whether Analyzer
selects some contents that
could be prefetched.
For that reason, Sergios
Soursos posted 1 Vimeo
video in George Petros
facebook wall, and 1 Vimeo
video in his own wall.
CTM will prefetch contents
from Vimeo and update the
database. A list of Vimeo
contents is provided as the
outcome of the social
analyzer prediction, and
CTM should prefetch them
all.
Afterwards, the cleaning
task is also performed and
should delete all contents in
the database, because they
are outdated.
The Unit tests check
whether CTM proxies only
Vimeo requests.
Specifically, a non-Vimeo
request is initially
performed, then a Vimeo
request for a content that is
not cached, and finally a
request for a cached
content.
Junit tests
DB,
uNaDas
The Unit tests check

whether CTM rewrites URIs
for cached Vimeo contents.
Initially, a first request is not
Vimeo-related and should
be returned as it is.
Then, another Vimeo
streaming request is
passed, but for content
which does not exist in the
database. It should return
the same URI.
Finally, a Vimeo streaming
request is performed, for
cached content. It should
return the local http server
URI and also add a content
access to the database.
Version 1.0

database. It should also
fetch video information from
Vimeo and store them as
well.
Social Analyzer should
return at least one content
as candidate for
prefetching.
Vimeo contents should be
fetched and saved in the
expected cache path, and
also their respective
database entries should be
inserted in the database.
In the second iteration,
contents should be deleted
both from the cache, and
also the respective
database tables.
Only Vimeo requests must

be proxied.
Vimeo requests for non
cached videos should be
proxied and also initiate
content prefetching from
Vimeo. Content should be
saved in cache and also
respective rows in the
database.
Vimeo requests for cached
videos should be proxied,
but do not initiate content
prefetching, because
content exists.
Only Vimeo streaming
requests must be taken into
account.
Vimeo streaming requests
for non cached contents
should be ignored.
Vimeo streaming requests
for cached contents should
be rewritten to the local
HTTP server URIs and also
content access entries
should be added to the
database.
Page 169 of 191


social
monitoring
Facebook
application,
Vimeo
and B of RBHORST
testbed
in both RPis.
Social Monitors in both of
them should retrieve and
fetch all required
information from Facebook
and Vimeo.
uNaDa
social
prediction
SM, SA, DB,

Facebook
application,
Vimeo
uNaDas
A
and B of RBHORST
testbed
Vimeo
proxying and
rewriting
CTM,
SM,
SA,
DB,
Facebook
application,
Vimeo
uNaDas
A
and B of RBHORST
testbed
Overlay
creation,
join,
advertiseme
nt,
prediction
OM,
CTM
uNaDas
A
and B of RBHORST
testbed

in RPi A.
Sergios Soursos posted 1
Vimeo video in George
Petros facebook wall, and
1 Vimeo video in his own
wall.
Social Monitor fetches all
required social information,
and social analyzer
prefetches one of Sergios
Vimeo videos.
in RPi A.
wall.
social analyzer prefetches
one of Sergios Vimeo
videos, George tries to
watch this video and video
is served from local HTTP
server.
George tries to browse to
other Websites and no
proxying is done.
George accesses other
Vimeo contents, videos are
downloaded from Vimeo
and are available to be
served in future requests.
George accesses some of
these contents again, and
videos are served from
local http server.
in both RPis. RPi A is set
as bootstrap node, RPi B is
configured to join the
overlay and connect to the
A.
The 2 uNaDas must create
and maintain an overlay
Both uNaDas have some
contents watched and
cached. These contents are
DB,
Page 170 of 191

uNaDas database. It
should also fetch video
information from Vimeo and
store them as well.
Similar procedure should
happen in Sergios uNaDa.
Social prediction should
return and prefetch at least
one content to Georges
uNaDa
No proxying for non Vimeo

requests.
Proxying for Vimeo
requests, and content
download to be available in
the cache.
No URL rewriting for non
cached contents.
URL rewriting for cached
contents, and streaming
from local http server.
Overlay creation, join,

advertisement and
prediction should work.
Contents should be fetched
from the other overlay
nodes and stored in the
local cache.
Version 1.0


Full
prototype
working
ALL
uNaDas
A
and B of RBHORST
testbed
advertised to the overlay.

They have 2 common
contents, hence overlay
prediction should return
their non cached contents
as available for prefetching.
Non common contents
should be prefetched from
overlay and cached to
uNaDas databases.
in both RPis. RPi A is set
as bootstrap node, RPi B is
configured to join the
overlay and connect to the
A.
The 2 uNaDas must create
and maintain an overlay.
wall.
social analyzer prefetches
one of Sergios Vimeo
videos, George tries to
watch this video and video
is served from local HTTP
server.
Social analyzer prefetches
one content in Georges
uNaDa. George can watch
the video, served from local
http server.
George and Sergios
browse several Vimeo
videos, which are cached in
their uNaDas and also
advertised to the overlay.
They have some common
contents, hence overlay
prediction should return
their non cached contents
as available for prefetching.
Non common contents
should be prefetched from
overlay and cached to
uNaDas databases.
They can both connect to
each others uNaDa using
the Android application, and
also can watch locally
prefetched and cached
contents.
Version 1.0
Full working prototype
Page 171 of 191


11.3.3 Issues
Integration tests identified certain issues, which are presented in Figure 92.
Figure 92: v2.0 issues.

The issues were finally resolved and re-tested, and v2.0 was released.
11.4 Release v2.1

Version 2.1 was the first sub-release of v2.0, implementing bug fixes and enhancements
to the RB-HORST mechanism.
11.4.1 Features
Main improvements, which are presented in the form of JIRA tickets (Figure 93), included:
Updated social prediction algorithm, which considers friends posts in the News
Feed,
Updated cache management algorithm,
Overlay Manager improvements and AS hops inclusion in sorted content list,
uNaDa UI improvements,
Android application UI improvements.
Page 172 of 191
Version 1.0



11.4.2 Tests
The integration testbed and the test cases included the ones performed in v2.0 (Section
11.3.2) and certain new and more complex ones (Table 11-4).
Table 11-4: v2.1 integration tests
Description
Components
Environment
Expected Outcome
Social
Prediction
ALL
Full
HORST
testbed
RB-
Video should be prefetched

(or not), depending on the
social
prediction
parameters set and the
configured social prediction
threshold.
The result can be checked
in the Georges uNaDa
logs, the demo screen page
or the cache screen page of
the Web interface.
Overlay
prediction
(content
does
not
exist in the
overlay
nodes)
ALL
Full
HORST
testbed
RB-
Andri posts a Vimeo video

to his Facebook wall.
Content is not cached in
Georges
or
Sergios
uNaDas.
Start Georges uNaDa.
Login to the Georges
uNaDa Web interface and
try
different
social
prediction
parameters
configuration, each time.
Also modify the social
prediction threshold each
time.
Start Andris and Georges
uNaDas.
Andri connects to his
private SSID and watches a
Vimeo video.
Georges
or
Sergios
Version 1.0
Video should be prefetched

(or not), depending on the
the
configured
overlay
prediction threshold.
In addition, video will be
prefetched by the Vimeo
CDN servers, since the 2
Page 173 of 191

uNaDas.
Modify
the
overlay
prediction threshold each
time.
uNaDas are 2 ASes away.

the Web interface.
Video will be prefetched by
Sergios
uNaDa,
since
Georges
and
Sergios
uNaDas belong to the same
domain.
in
the
Georges
and
Sergios uNaDas logs, the
demo screen page or the
cache screen page of the
Web interface.
Video is predicted by both
prediction algorithms, but
will be prefetched by the
Vimeo CDN servers, since
the 2 uNaDas are 2 ASes
away.
the Web interface.
Video is predicted by both
prediction algorithms, and
will be prefetched by
Sergios
uNaDa,
since
Georges
and
Sergios
uNaDas belong to the same
domain.
Monitor the social and
overlay prediction scores of
the predicted content from
the logs.
in
the
Georges
and
Sergios uNaDas logs, the
demo screen page or the
cache screen page of the
Web interface.
Overlay
prediction
(content
exists in the
overlay
nodes)
ALL
Full
HORST
testbed
RB-

uNaDas.
Vimeo video.
Content is cached in
Sergios uNaDa, hence will
be
considered
as
a
candidate node to be
prefetched from.
Social and
overlay
prediction
(content
does
not
exist in the
overlay
nodes)
ALL
Full
HORST
testbed
RB-

uNaDas.
Vimeo video. He also posts
it to his Facebook wall.
Georges
or
Sergios
uNaDas.
Social and
overlay
prediction
(content
exists in the
overlay
nodes)
ALL
Full
HORST
testbed
RB-

uNaDas.
Vimeo video. He also posts
it to his Facebook wall.
Content is cached in
Sergios uNaDa, hence will
be
considered
as
a
candidate node to be
prefetched from.
11.4.3 Issues
No issues were found during v2.1 integration tests and v2.1 was released successfully.
11.5 Release v3.0

Version 3.0 of the SmartenIT software implements additional DTM features.
Page 174 of 191
Version 1.0


11.5.1 Features
support for 95th percentile billing rule;
added new system control variables and time schedule parameters;
added SDN Controller operation modes (proactive vs reactive);
compensation vector handling in Network Traffic Manager to reduce the number of
updates sent towards remote domains.

11.5.2 Tests
The integration testing procedure that preceded the release of SmartenIT software v3.0
comprised the execution of all the test cases defined for release v1.2 presented in section
11.2.2 and additional tests described in Table 11-5.
Description
Components
Environment
Expected Outcome
Complete
chain
with
95th
percentile
based
charging
rule and one
receiving
DC.
QOA,
NTM,
SBox
JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client

initialized
with
mocked
controller.
Inter-SBox
are
initialized.
Mocked
preconfigured
structures
DCs. The 95th percentile
billing rule is used in the
SBox.

values.
ECA,
inter-
Version 1.0
Page 175 of 191



from
mocked
X and Z vectors and
vector from 95th percentile
traffic
samples
after
accounting period. NTM
calculates C vector after
each reporting period and
updates remote NTM with
new C and R (after
accounting period) vectors.
Received C and R vectors
are passed to a mocked
instance of
SBox-SDN
client.
Test
is
run
for
2
consecutive
accounting
periods.
Basic Sanity
testing
for
release v3.0
ALL
WP4 testbed
at PSNC.

each
SBox
with
the
required
domain
information. Configuration
should include the 95th
percentile charging rule and
one of the SDN controller
operation modes.
Run 1 SBox in receiving
SDN controller in sending
domain.
SDN
controller
should
initially
receive
the
configuration data.

indicate failures.
that
reference
and
sent to the sending domain,
and then to the SDN
Controller.
distributed by the SDN
Controller running in all four
operation modes.

reads
counters
from
vectors are sent to the
SBox in the sending
domain and then the SDN
controller is also updated.
11.5.3 Issues
Page 176 of 191
Version 1.0


11.6 Release v3.1

Version 3.1 of the SmartenIT software implements additional DTM features.
11.6.1 Features
added BG router configuration using NETCONF protocol;
support for delay-tolerant traffic management;
introduced new compensation vector calculation in the case when reference vector
is achieved on one or more links.

11.6.2 Tests
The integration testing procedure that preceded the release of SmartenIT software v3.1
comprised the execution of all the test cases defined for releases v1.2 and v3.0 presented
in sections 11.2.2 and 11.5.2 and additional tests described in Table 11-6.
Description
Components
Environment
Expected Outcome
Complete
chain
with
95th
percentile
based
charging
rule,
advanced
operations
when
R
vector
QOA,
NTM,
SBox
JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client

initialized with mocked
controller.
Inter-SBox
are
initialized.
Mocked

values.
ECA,
inter-
Version 1.0
Page 177 of 191


achieved on
link and one
receiving
DC.

preconfigured
structures
DCs. The 95th percentile
billing rule is used in the
SBox.
from
mocked
X and Z vectors and
vector from 95th percentile
traffic
samples
after
accounting period. NTM
calculates C vector after
each reporting period and
updates remote NTM with
new C and R (after
accounting period) vectors.
Received C and R vectors
are passed to a mocked
instance of SBox-SDN
client.
C vector updates are sent
only if specific conditions
are met. Before the end of
accounting period, ECA
sends to NTM a list of links
for which the calculated R
vector value has already
been
achieved.
This
triggers different C vector
calculation algorithm.
Test
is
run
for
2
consecutive
accounting
periods.
Basic Sanity
testing
for
release v3.1
ALL
WP4 testbed
at PSNC.
There are 4 domains

configured in the testbed (2
receiving and 2 sending).
each of 4 SBoxes with the
required
domain
information. Configuration
should include the 95th
percentile charging rule and
one of the SDN controller
operation modes.
Run 1 SBox per receiving
SDN controller per sending
domain.
Page 178 of 191

indicate failures.
that
reference
and
sent
to
the
sending
domains, and then to the
SDN Controllers.
distributed by the SDN
Controllers to DCs via
proper tunnels.
Version 1.0


SDN controllers should

initially
receive
the
configuration data.
reads
counters
from
vectors are sent to the both
SBoxes in the sending
domains
and
then
respective SDN controllers
are also updated.
11.6.3 Issues
Version 1.0
Page 179 of 191


12 Summary
In this deliverable, we reported the final outcomes of WP3: the final system architecture,
the final implementation framework, the two integrated and released prototypes, DTM and
RB-HORST and the complete list of their system releases, as well as the standalone
implementations, MUCAPS, vINCENT, MoNA, and SDNDC.
The final SmartenIT architecture was finalized and documented in D3.3 [3]. The two
released prototypes, as well as the presented standalone implementations deploy a
subset of the defined architectural entities, components and interfaces, in order to fulfil
their goals and functionalities.
A common implementation framework has been agreed and set up since the beginning of
WP3 and has been documented in D3.2 [2]. The agile development and continuous
integration concepts were adopted, aiming at 2-month release cycles and rapid code
development, and issue resolution. In addition, certain tools were deployed to support
these concepts: a Subversion source code repository, a JIRA issue management
platform and a Jenkins continuous integration server were deployed in PSNCs premises.
The first integrated SmartenIT prototype is the DTM, which maps to two architecture
entities: the SBox and the SDN Controller. SBox includes the following components: The
QoS Analyzer retrieves the required SNMP measurements from the network entities, the
Economic Analyzer calculates the reference vector based on links costs and the Network
Traffic Manager calculates the compensation vector and also coordinates the interaction
with the other entities (remote SBox, local SDN Controller). The inter-SBox
Communication Service is responsible for sending and receiving the calculated reference
and compensation vector to/from other SBoxes. The SBox-SDN executes the same
functionality towards the local SDN controller, and finally, UI and DB provide the
necessary interfaces to save and access required configuration. The SDN Controller is
built on top of Floodlight controller source code to implement DTM functionality, which
translates received compensation and reference vectors into flow rules. It also exposes
interfaces towards the SBox to receive these vectors and additional configuration
parameters.
The second integrated prototype is the RB-HORST, which implements two architecture
entities: uNaDa and End-user application. The uNaDa is a Java Web application which
consists of the following components: The Social Manager monitors the OSNs for useful
social information, while the Social Analyzer aggregates this information to perform the
social prediction algorithm and return the ranked list of contents, likely to be watched.
uNaDas AS hops are calculated by the Topology Proximity Monitor and are given as input
to the Overlay Manager, which sets up the peers overlay network, advertises and
prefetches content from other uNaDas and executes the overlay prediction algorithm. The
Cloud Traffic Manager is the coordinating component of the uNaDa, which receives the
results of social and overlay prediction algorithms, prefetches the most-likely to be
watched, and also manages the uNaDas cache. DB and UI are components which
support the other components basic functionalities, while the uNaDa-End-User interface
exposes an interface towards end-user applications, to authenticate and receive SSID
credentials. The End-user application is an Android application which is used by the endusers to connect to a remote uNaDas private SSID, using their Facebook credentials. The
RB-HORST Android application has been released in the Google Play Store [40].
Page 180 of 191
Version 1.0


All the aforementioned tools and procedures aimed at and ensured a commercially
developed and integrated prototype, following industry standards. Three major (1.0, 2.0
and 3.0) and four minor (1.1, 1.2, 2.1 and 3.1) versions of the SmartenIT software were
released by the WP3 integration team, implementing new features and fixing bugs of the
DTM and RB-HORST mechanisms. For every released version, certain test cases were
designed and finally performed in the integration testbeds, validating the prototypes
functionalities and operation. Version 3.1 concluded the implementation work of WP3,
including the final DTM and RB-HORST prototypes.
The consortium aimed at making the source code of the project available to the general
public. Therefore, key releases of the SmartenIT project (1.1, 1.2, 2.1, 3.0 and 3.1) were
released as open-source to Github [39], under Apache v2 license.
Additional prototypes have been developed to address further goals of the SmartenIT
project, but were not integrated to the DTM or RB-HORST prototypes. MUCAPS optimizes
the overlay application traffic by involving awareness on the underlying network topology
and on transport costs, proposing ALTO protocol extensions. VINCENT proposes and
implements an incentive scheme for users to open their access points to other users,
while MoNA focuses on reducing the energy consumption of end-users mobile devices.
Finally, the SDNDC mechanism complements standard DNS based redirection used by
many cloud service providers and CDNs by allowing the migration of high-volume flows
between surrogates in the backend.
Version 1.0
Page 181 of 191


13 SMART Objectives Addressed

This deliverable addresses certain SmartenIT SMART objectives defined in Section
B1.1.2.4 of the SmartenIT Description of Work (DoW) [31]. Specifically, the deliverable
addresses the WP3 SMART Objective (Table 13-1), two overall SMART objectives (Table
13-2) and one prototyping SMART objective (Table 13-3).
The WP3 Objective is defined in the DoW as follows:
Table 13-1: Work Package 3 SMART objective addressed.
Objective 3 SmartenIT will investigate economically, QoE, and energy-wise such models
in theory by simulations to guide the respective prototyping work in terms of
a successful, viable, and efficient architectural integration, framework and
mechanisms engineering, and its subsequent performance evaluation.
This deliverable is the final outcome of the engineering work performed in WP3, providing
the technical documentation of the two implemented, integrated and released traffic
management mechanisms, DTM and RB-HORST. These prototypes and the additional
standalone implementations, MUCAPS, VINCENT, MoNA and SDN-based DC selection,
address Objective 3, in the sense that a successful, viable, and efficient architectural
integration, framework and mechanisms engineering evolved and were finalized.
In addition, the overall SmartenIT SMART objectives presented in Table 13-2 have been
addressed in the current document. The SmartenIT architecture was finalized and
documented in D3.3 [3], covering all aspects and functionalities of the designed WP2
mechanisms, which were later implemented into specific software modules under the
scope of WP3, resulting in functional integrated prototypes. Overall, six mechanisms were
developed and tested, covering all aspects of the SmartenIT DoW.
Table 13-2: Overall SmartenIT SMART objectives addressed.
Measurable
Objective
No.
O3
Specific
Deliverable
Number
Timely
Achievable
Relevant
Mile Stone Number
Framework and
mechanism engineering
D3.2
Implementation
Advanced
MS3.4, MS3.5
Architectural integration
D3.2
Implementation
Complex
MS3.4, MS3.5
Page 182 of 191
Version 1.0


Finally, this document addresses the prototyping SMART objective O3.4, with the
implementation of the MoNA mechanism, which monitors and reduces energy
consumption in end-users mobile devices.
Table 13-3: Prototyping SmartenIT SMART objectives addressed.
Objective
ID
O3.4
Measurable
Specific
Timely
Achievable
Relevant
Prototyping
Highly relevant
output of
relevance for
users
Metric
How to monitor energy

and take appropriate
coordinated actions?
Number of options
identified to monitor
energy consumption on
networking elements and
end users mobile devices,
investigation on which
options perform best
(yes/no)
Version 1.0
Project
Month
M36
Page 183 of 191


14 References
[1]
The SmartenIT project: Deliverable D3.1 - Report on Initial System Architecture; April
2013
[2]
The SmartenIT project: Deliverable D3.2 - Technologies, Implementation Framework,

and Initial Prototype; July 2014
[3]
The SmartenIT project: Deliverable D3.3 - Final Report on System Architecture;

October 2014
[4]
The SmartenIT project: Deliverable D4.1 - Test-bed Set-up and Configuration;

October 2014
[5]
Microsoft Visio, online. Available at: http://office.microsoft.com/en-001/visio/
[6]
Java Development Kit, a development environment for building applications, applets,

and components using the Java programming language, online. Available at:
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads1880260.html
[7]
Android - a mobile operating system based on the Linux kernel that is currently
developed by Google, online. Available at: http://www.android.com/
[8]
Apache Maven, online. Available at: http://maven.apache.org/
[9]
Apache Subversion software, online. Available at: http://subversion.apache.org/
[10] GitHub, a web-based Git repository hosting service. Available at: https://github.com/
[11] Atlassian JIRA, online. Available at: https://www.atlassian.com/software/jira
[12] Jenkins open source continuous integration server, online. Available at: http://jenkinsci.org/
[13] Eclipse Jetty, online. Available at: http://www.eclipse.org/jetty/
[14] SQLite - SQL database engine, online. Available at: http://www.sqlite.org/
[15] The
H2
Database
Engine,
http://www.h2database.com/html/main.html
online.
Available
at:
[16] Lighttpd, an open-source Web server optimized for speed-critical environments.

Available at: http://www.lighttpd.net/
[17] Mitmproxy, an interactive console program that allows traffic flows to be intercepted,
inspected, modified and replayed. Available at: https://mitmproxy.org
[18] Apache v2 license, a free software license written by the Apache Software
Foundation (ASF). Available at: https://www.apache.org/licenses/LICENSE-2.0
[19] R. Enns, Ed., "NETCONF Configuration Protocol", RFC 6241, June 2011
[20] JUnit a programmer-oriented testing framework for Java, online. Available at:
http://junit.org/
[21] Mockito
open
source
testing
https://code.google.com/p/mockito/
framework,
online.
Available
at:
[22] Bootstrap front-end framework, online. Available at: http://getbootstrap.com/

[23] Project Floodlight, online. Available at: http://www.projectfloodlight.org/floodlight/
Page 184 of 191
Version 1.0


[24] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and
R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285,
September 2014.
[25] The SmartenIT project: Deliverable D2.2 - Report on Definitions of Traffic
Management Mechanisms and Initial Evaluation Results; October 2013
[26] The SmartenIT project: Deliverable D2.4 - Report on Final Specifications of Traffic
Management Mechanisms and Evaluation Results; October 2014
[27] Facebook, online. Available at: https://www.facebook.com/
[28] Vimeo, online. Available at: https://vimeo.com/
[29] TomP2P, a distributed hash table which provides a decentralized key-value
infrastructure for distributed applications. Available at: http://tomp2p.net
[30] Raspberry Pi - a low cost, credit-card sized computer, online. Available at:
http://www.raspberrypi.org/
[31] The SmartenIT Consortium: Grant Agreement for STREP: Annex I Description of
Work (DoW). 2012.
[32] Ubuntu - a Debian-based
http://www.ubuntu.com/
Linux
operating
system,
online.
Available
at:
[33] The Netty project, online. Available at: http://netty.io/

[34] J. Case, M. Fedor, M. Schoffstall, J. Davin, "A Simple Network Management Protocol
(SNMP)", RFC 1157, May 1990
[35] OpenFlow:
Open
Switch
specification,
online.
Available
https://www.opennetworking.org/sdn-resources/onf-specifications/openflow
at:
[36] N. Gautam, H. Petander, and J. Noel, A comparison of the cost and energy
efficiency of prefetching and streaming of mobile video, in Proc. MoVid, 2013.
[37] M. Wichtlhuber, R. Reinecke, and D. Hausheer, An SDN based CDN/ISP
Collaboration Architecture for Managing High-Volume Flows, IEEE TNSM Special
Issue on Efficient Managementof SDN and NFV-based Systems, vol. 12, no. 1, pp.
406409, 2015.
[38] Global Internet Phenomena Report, Sandvine Inc., Tech. Rep., 2013.
[39] The SmartenIT project, The source code of the SmartenIT software. Available at:
https://github.com/smartenit-eu/smartenit
[40]
The SmartenIT project, RB-HORST Android application. Available

https://play.google.com/store/apps/details?id=eu.smartenit.enduser.app
Version 1.0
at:
Page 185 of 191


15 Abbreviations
ALTO
Application Layer Traffic Optimization, Working group of the Internet

Engineering Task Force
API
Application Interface
AS
Autonomous System
BG
Border Gateway
BGP
Border Gateway Protocol
CTM
DA
Datacenter Attachment
DAO
Data Access Object
DB
Database
DC
Datacenter
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
DTM
Dynamic Traffic Management
DTO
Data Transfer Object
ECA
Economic Analyzer
HTTP
Hypertext Transport Protocol
ICC
Inter-Cloud Communication
ISCS
Inter-SBox Communication Service
ISP
Internet Service Provider
JDK
Java Development Kit
JSF
Java Server Faces
JSON
Javascript Object Notation
MIB
Management Information Base
MoNA
Mobile Network Assistant
MPLS
Multiprotocol Label Switching
MUCAPS
Multi-Criteria Application End-Point Selection
NaDa
NanoDatacenter
NSP
Network Service Provider
NTM
OM
Overlay Manager
OSN
Online Social Network
PC
Personal Computer
Page 186 of 191
Version 1.0


PoP
Point of Presence
QOA
QoS/QoE Analyzer
QoE
Quality of Experience
QoS
Quality of Service
RAM
Random Access Memory
RB-HORST Replicating Balanced Tracker - Home Router Sharing based on Trust

REST
Representational State Transfer
RFC
Request for Comments
SA
Social Analyzer
SBox
SmartenIT Box
SDN
Software Defined Networking
SDNDC
SDN-based DC selection
SM
Social Monitor
SmartenIT
Socially-aware Management of New Overlay Application Traffic with Energy

Efficiency in the Internet, EU STREP project
SNMP
Simple Network Management Protocol
SSID
Service Set Identifier
STREP
Specific Targeted Research Project
TCP
Transmission Control Protocol
TPM
Topology Proximity Monitor
UDP
User Datagram Protocol
UI
User Interface
UML
Unified Modeling Language
uNaDa
user NanoDatacenter
URL
Uniform Resource Locator
VINCENT
Virtual Incentives
VM
Virtual Machine
WP
Work Package
Version 1.0
Page 187 of 191


16 Acknowledgements
This deliverable was made possible due to the large and open help of the WP3 team of
the SmartenIT team within this STREP, which includes the deliverable authors presented
in the document control, and the internal reviewers Ioanna Papafili, Paolo Cruschelli and
Burkhard Stiller for their valuable feedback. Many thanks to all of them.
Page 188 of 191
Version 1.0


Appendix A. Internal Interfaces Protocol Format

In this section JSON format of the internal interfaces protocol is presented including some
sample values as retrieved from the integration testing logs. A significant modification of
the exchanged data has been introduced since prototype release v1.0 presented in
Deliverable D3.2 [2].
A.1. Reference and Compensation Vectors JSON Format

{"referenceVector":{
"vectorValues":[{"value":1000,"tunnelEndPrefix":{"prefix":"10.1.1.0","pre
fixLength":24}},{"value":1500,"tunnelEndPrefix":{"prefix":"10.1.2.0","pre
fixLength":24}}],"sourceAsNumber":100,"thetaCollection":null},
"compensationVector":{
"vectorValues":[{"value":500,"tunnelEndPrefix":{"prefix":"10.1.1.0","pref
ixLength":24}},{"value":-500,"tunnelEndPrefix":{"prefix":"10.1.2.0","pref
ixLength":24}}],"sourceAsNumber":100}}
A.2. Configuration Data JSON Format

{"entries":[{
"remoteDcPrefix":{"prefix":"10.10.3.0","prefixLength":24},
"daRouterOfDPID":"00:00:00:00:00:00:00:01",
"tunnels":
[{"tunnelID":{"tunnelName":"TUN1","localTunnelEndAddress":{"prefix":"172.
16.16.2","prefixLength":32},"remoteTunnelEndAddress":{"prefix":"172.16.16
.1","prefixLength":32}},"daRouterOfPortNumber":1},
{"tunnelID":{"tunnelName":"TUN2","localTunnelEndAddress":{"prefix":"172.1
6.16.6","prefixLength":32},"remoteTunnelEndAddress":{"prefix":"172.16.16.
5","prefixLength":32}},"daRouterOfPortNumber":2}]}],
"operationModeSDN":"proactiveWithoutReferenceVector",
"localDCPortsConfig":[{"daRouterOfDPID":"00:00:00:00:00:00:00:01","localD
COfSwitchPortNumbers":[5]}]}
Version 1.0
Page 189 of 191


Appendix B. NetConf XML Messages Format

In order to implement delay tolerant traffic management decisions on BG routers the
NETCONF protocol [19] is being used. Please note that the current prototype
implementation supports only Juniper MX devices1 as BG routers.
Following are XML messages used to perform specific actions on the BG router filled with
some example values (e.g. interface names) used during tests. Please note that the
implementation assumes that a specific configuration was set up on the router manually
beforehand. The names of policers are currently not configurable so need to be strictly
followed. Two names are used, i.e. POLICER_EF_<cap-iface-name> and
POLICER_TOLERANT_TRAFFIC_<cap-iface-name>, where <cap-iface-name> should be
replaced with capitalized name of a specific interface on which given policer is used, e.g.
GE-2/0/4.
B.1. Filter activation and deactivation

<rpc>
<load-configuration action="set" format="text">
<configuration-set>
activate interfaces ge-2/0/4 unit 0 family inet filter input
</configuration-set>
</load-configuration>
</rpc>
]]>]]>
<rpc>
<configuration-set>
deactivate interfaces ge-2/0/4 unit 0 family inet filter input
</rpc>
]]>]]>
B.2. Policer bandwidth limits update

<rpc>
<configuration-set>
set firewall policer POLICER_EF_GE-2/0/4 if-exceeding bandwidthlimit 100000 burst-size-limit 625000
</rpc>
]]>]]>
<rpc>
<configuration-set>
http://www.juniper.net/us/en/products-services/routing/mx-series/
Page 190 of 191
Version 1.0


set firewall hierarchical-policer POLICER_TOLERANT_TRAFFIC_GE2/0/4 aggregate if-exceeding bandwidth-limit 100000 burst-size-limit

625000
</rpc>
]]>]]>
<rpc>
<configuration-set>
set firewall hierarchical-policer POLICER_TOLERANT_TRAFFIC_GE2/0/4 premium if-exceeding bandwidth-limit 100000 burst-size-limit 625000
</rpc>
]]>]]>
Version 1.0
Page 191 of 191


Deliverable D3.4 - Prototype Implementation, Validation and Selected Application Final Version

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Deliverable D3.4 - Prototype Implementation, Validation and Selected Application Final Version

Enviado por

Direitos autorais:

Formatos disponíveis

D3.

Seventh Framework STREP No. 317846

The SmartenIT Consortium

Copyright 2015, the Members of the SmartenIT Consortium

D3.4 Prototype Implementation, Validation

Seventh Framework STREP No. 317846

Prototype Implementation, Validation and Selected Application

George Petropoulos, Sergios Soursos, Jakub Gutkowski, ukasz

January 30, 2015

March 31, 2015

Updated table of contents

April 15, 2015

George, Fabian, Lukasz, Jakub,

Integrated input to chapters 4, 5, 6 and 7.

April 21, 2015

George, Sergios, Matthias, Lukasz,

Integrated input to all chapters.

April 24, 2015

Ioanna, Paolo, Burkhard

April 30, 2015

George, Sergios, Lukasz, Grzegorz,

D3.4 Prototype Implementation,

Seventh Framework STREP No. 317846

Purpose of Deliverable 3.4

5 The Dynamic Traffic Management (DTM) mechanism

7 The Multi-Criteria Application End-Point Selection (MUCAPS) mechanism

D3.4 Prototype Implementation, Validation

Seventh Framework STREP No. 317846

Mapping to the SmartenIT Architecture

8 The Virtual Incentives (vINCENT) mechanism

Mapping to the SmartenIT Architecture

9 The Mobile Network Assistant (MoNA) mechanism

Mapping to the SmartenIT Architecture

10 The SDN-based DC selection (SDNDC) mechanism

11.1 Release v1.1

13 SMART Objectives Addressed

D3.4 Prototype Implementation,

Seventh Framework STREP No. 317846

D3.4 Prototype Implementation, Validation

Seventh Framework STREP No. 317846

Purpose of Deliverable 3.4

D3.4 Prototype Implementation,

Seventh Framework STREP No. 317846

D3.4 Prototype Implementation, Validation

Seventh Framework STREP No. 317846

Figure 1: The SmartenIT component diagram.

D3.4 Prototype Implementation,

Seventh Framework STREP No. 317846

entities. In addition, the interfaces between entities components are presented.

End User Entity

Figure 2: Components mapping to entities.

Inter-SBox Communication Service

D3.4 Prototype Implementation, Validation

Seventh Framework STREP No. 317846

Network Traffic Manager

SDN Controller, Interfaces

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

Cloud Traffic Manager (CTM), Overlay

End-User entity Traffic Manager, DB, UI

D3.4 Prototype Implementation,

Seventh Framework STREP No. 317846

Cloud Traffic Manager

Figure 4: The RB-HORST entities/components/interfaces diagram

D3.4 Prototype Implementation, Validation