Deliverable D3.1 Report On Initial System Architecture

Seventh Framework STREP No.
317846
Public
D3.1 - Report on Initial System Architecture
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.1 Report on Initial System Architecture
The SmartenIT Consortium

University of Zrich, UZH, Switzerland Athens University of Economics and Business - Research Center, AUEB-RC, Greece Julius-Maximilians Universitt Wrzburg, UniWue, Germany Technische Universitt Darmstadt, TUD, Germany Akademia Gorniczo-Hutnicza im. Stanislawa Staszica W Krakowie, AGH, Poland Intracom S.A. Telecom Solutions, ICOM, Greece Alcatel Lucent Bell Labs, ALBLF, France Instytut Chemii Bioorganiicznej Pan, PSNC, Poland Interoute S.P.A, IRT, Italy Telekom Deutschland GmbH, TDG, Germany
Copyright 2013, 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 3.0
Page 1 of 78

Public
Seventh Framework STREP No. 317846
Document Control
Title: Type: Editor(s): E-mail: Author(s): Report on Initial System Architecture Public David Hausheer, Julius Rckert [hausheer|rueckert]@ps.tu-darmstadt.de Matteo Biancani, Thomas Bocek, Daniel Dnni, Zbigniew Dulinski, Jakub Gutkowski, Gerhard Hasslinger, David Hausheer, Fabian Kaup, Roman Lapacz, Andri Lareida, Lukasz Lopatowski, Guilherme Sperb Machado, Antonis Makris, George Petropoulos, Patrick Poullie, Alessandro Predieri, Sabine Randriamasy, Julius Rckert, Sergios Soursos, Rafal Stankiewicz, Krzysztof Wajda, Matthias Wichtlhuber, Piotr Wydrych D3.1-v3.0.doc
Doc ID:
AMENDMENT HISTORY
Version
V3.0
Date
April 30, 2013
Author
David Hausheer
Description/Comments
Final version submitted to EC
Legal Notices The information in this document is subject to change without notice. The Members of the SmartenIT Consortium make no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the SmartenIT Consortium shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Page 2 of 78
Version 3.0

Public
Table of Contents
1 Executive Summary 2 Introduction
2.1 2.2 3.1 Purpose of the Document D3.1 Document Outline Problem Statement and Motivation 3.1.1 Single Cloud 3.1.2 Federated Cloud 3.1.3 Interconnected Clouds 3.1.4 End-user Considerations Related Approaches and Architectures 3.2.1 Software Defined Networks (SDN) 3.2.2 Application Layer Traffic Optimization (ALTO) 3.2.3 FI-WARE 3.2.4 Cloudlets 3.2.5 Nano Data Centers (NaDa) 3.2.6 SmoothIT Architecture 3.2.7 OpenNebula and OpenStack 3.2.8 Application-Based Network Operations (ABNO) 3.2.9 ETICS Base Functionality Conceptual Architecture 4.2.1 Domain View 4.2.2 Topological View Cloud Traffic Management Overlay Management: ALTO and CDNs 5.2.1 Inter-ALTO 5.2.3 Overlay Management for End User Deployed Software Network Traffic Management with SDN 5.3.1 Network Load Balancing supported by ALTO in an SDN-Controller Traffic Monitoring 5.4.1 Network Monitoring Functionality 5.4.2 Monitoring Systems and Key Performance Indicators 5.4.3 Interfaces between Network Monitoring Systems Mobile Traffic Management Quality Management: QoS and QoE 5.6.1 QoS/QoE Cloud Management 5.6.2 QoS/QoE Overlay Management Economic Considerations and Incentives 5.7.1 SmartenIT and External Charging Components 5.7.2 Charging Incentives for Traffic Management 5.7.3 Flexible Non-monetary Incentives for Traffic Management Energy Consumption Monitoring Social Awareness
6 7
7 7
3 Problem and Related Approaches
9
9 10 11 12 12 13 14 15 19 22 24 24 26 28 30
3.2
4 Base Functionality and Conceptual Architecture

4.1 4.2
32
32 34 34 37
5 Initial Functionality Specification

5.1 5.2
40
40 41 41 45 45 47 48 48 49 50 51 53 54 54 56 56 57 58 58 60
5.3 5.4
5.5 5.6
5.7
5.8 5.9
6 Derived Initial System Architecture 7 Summary and Conclusions

7.1 Next Steps
63 67
68
8 SMART Objectives Addressed 9 References

Version 3.0
69 71
Page 3 of 78

Public
10 Abbreviations 11 Acknowledgements
74 78
Page 4 of 78
Version 3.0

Public
(This page is left blank intentionally.)
Version 3.0
Page 5 of 78

Public
1 Executive Summary
The aim of this deliverable D3.1 is to specify the initial SmartenIT system architecture. As such, D3.1 outlines the problem and related approaches from which the base functionality and conceptual architecture are derived. Furthermore, a break-down of the envisioned functionality into entities and components is given and their basic interactions and interfaces are described. The deliverable D3.1 is the first outcome of Task 3.1 (Design of System Architecture) that is to design, specify, and evaluate a reference architecture for the SmartenIT system, taking into account the requirements from WP1 as well as the initial work conducted in WP2. The goal of the system architecture is to identify the respective architectural elements, their functionality and their interdependencies. As such, Task 3.1 builds upon the basic identification of deployable entities, and further elaborates on how the required functionality will be assigned to logical components. The resulting architecture is a modular one and follows existing standards and proposals so as to provide the guidelines to the implementation task T3.3. Moreover, the work of task T3.1 allows for a better formulation of realistic and specific problems of WP2, which benefits in its theoretical studies. Therefore, the main results of this deliverable include: An outline of the environment in which the technological solution of SmartenIT will be deployed (Section 3). This includes a presentation of the problem statement, roughly evaluating the cases where stakeholders could benefit from SmartenIT. As the work in WP1 and WP2 are still on-going and progress in parallel with the initial system architecture design, D3.1 makes an initial attempt to put placeholders for the aforementioned WPs to provide input and make the final decisions. To that end, certain existing architectures that tackle similar or related problems are mentioned, in order to provide a basis for the SmartenIT architecture. A description of the base functionality and the corresponding conceptual architecture for the SmartenIT approach (Section 4). The base functionality is derived from deliverable D1.1 as well as based on the problem description and discussion of related approaches. At the same time, the conceptual architecture provides the domain view and the topological view on the initial SmartenIT architecture. This serves as the basis for the functionality specification and the definition of the initial system architecture. An initial specification of the functionality and the interactions required by each functional block to fulfill its purpose (Section 5). This deliverable D3.1 doesnt provide any mechanisms as such, as this is the task of WP2 (specifically deliverable D2.1). Rather, it describes the internals of each block and analyzes each functional block (and interface) in order to extract more detailed requirements, to drive the design of the component architecture. Finally, a first attempt to design the initial SmartenIT system architecture (Section 6). The objective here is to consolidate the analyzed functionality and to provide an initial integrated view of the system architecture. The resulting architecture aims to cover the requirements imposed by all scenarios described in deliverable D1.1.
Page 6 of 78
Version 3.0

Public
2 Introduction
The high-level objective for task T3.1 (Design of System Architecture) of the SmartenIT project is to design, specify, and evaluate the overall reference architecture for the SmartenIT system. As such, Task 3.1 builds upon the basic identification of deployable entities, and further elaborates on how the required functionality will be assigned to logical components. The SmartenIT approach aims at an incentive-compatible cross-layer network management that involves a number of different entities and spans several domains of traditional network and traffic management. Therefore, the SmartenIT project aims to follow ALTO requirements and protocols and considers extending the inter-ALTO work, amongst others. Consequently, the main expected outcomes of task T3.1 are a full-fledged definition of the implementation architecture based on a selection of mandatory mechanisms from WP2. Thus, the resulting system architecture shall be a modular one that follows existing standards and proposals so as to provide the guidelines to the implementation task T3.3. Furthermore, in terms of achieving the architectural integration as part of Objective 3 of the overall SmartenIT project, the overall embedding of the architecture into the Future Internet needs to be determined. This requires a definition of respective interfaces to network management, Operations Support System (OSS), the Cloud, and social networks. Since the work in WP1 and WP2 are currently still on-going and progress in parallel with the system architecture design in task T3.1, this deliverable D3.1 provides an architecture design that is a preliminary one at this stage, thus mainly addressing problems and challenges, as well as related approaches, along with a conceptual rather than a detailed software architecture design. Nevertheless, in WP3 it is required to make an initial attempt to provide a view of the architectural environment and to put placeholders for the aforementioned WPs to provide input and make the final decisions.
2.1 Purpose of the Document D3.1

Therefore, the aim of deliverable D3.1 is to design and specify the initial SmartenIT system architecture, taking into account the requirements from WP1 as well as the initial work conducted in WP2. The goal of the system architecture is to identify the respective architectural elements, their functionality and their interdependencies. As such, D3.1 first outlines the problem and related approaches from which the base functionality and conceptual architecture are derived. Furthermore, a break-down of the envisioned functionality into entities and components is given and their basic interactions and interfaces are described.
2.2 Document Outline

The rest of this deliverable is organized as follows. Section 3 provides an outline of the environment in which the technological solution of SmartenIT will be deployed. To that end, it discusses several existing architectures that tackle similar or related problems, in order to provide a basis for the initial SmartenIT architecture. Furthermore, Section 4 provides a description of the base functionality and the corresponding conceptual architecture for the SmartenIT approach. While the base functionality outlines the key SmartenIT functions of concern, the conceptual architecture provides the domain view and the topological view on the initial SmartenIT architecture which serves as the basis for the
Version 3.0
Page 7 of 78

Public
functionality specification and the definition of the initial system architecture. Moreover, Section 5 provides the initial specification of the functionality and the interactions required by each functional block to fulfill its purpose. The internals of each block (and interface) are described and analyzed in order to extract more detailed requirements, to drive the design of the component architecture. Finally, Section 6 makes a first attempt to design the initial SmartenIT system architecture. The objective here is to consolidate the analyzed functionality and to provide an initial integrated view of the system architecture.
Page 8 of 78
Version 3.0

Public
3 Problem and Related Approaches

In this section, the environment in which the technological solution of SmartenIT will be deployed is outlined. First, a problem statement is presented, roughly evaluating the cases where stakeholders could benefit from SmartenIT. It is important to mention that the work in WP1 regarding the characterization of stakeholders, preliminary description of scenarios and identification of interesting applications characteristics, as well as the work in WP2 regarding the overview of mechanisms for overlay and cloud traffic management are still on-going and progress in parallel with the initial system architecture design in this document Deliverable D3.1. Thus, in WP3 it is required to make an initial attempt to provide a view of the architectural environment and to put placeholders for the aforementioned WPs to provide input and make the final decisions. Besides the problem statement and the motivation, certain existing architectures that tackle similar or related problems are mentioned in this section, in order to provide a basis for the SmartenIT architecture.
3.1 Problem Statement and Motivation

The SmartenIT project will deal with the management of traffic generated by applications running on the Cloud. In this sense, the project will offer Cloud and Overlay traffic management solutions for generated traffic that flows over the public Internet. More specifically, the SmartenIT project focuses on the following challenges: Management of inter-domain traffic, considering also economic factors Management of inter-cloud traffic, without the supervision of a central entity Improvement of Quality of Experience for end users Improvement of energy efficiency of network equipment and end user devices However, to do so, it is required first to identify the potential for intervention and the points of such intervention, which is a relevant dimension in the service classification and application selection in deliverable D1.1. In this section, a brief overview of the different instantiations of a Cloud is provided, commenting also on the solutions that SmartenIT could offer. Regarding the solutions to be offered, the envisioned SmartenIT scenarios should be kept in mind. In D1.1, the following scenarios have been identified and described: Inter-Data Center / Inter-Cloud communication Collaboration for Energy Efficiency Global Service Mobility Social-Awareness for Content Delivery
The analysis to follow is based mostly on the first scenario, since it is considered as the scenario that places the core requirements. However, the SmartenIT architecture, initially sketched in Section 4 and later described in detail in Section 6, expands and covers all the aforementioned scenarios and their requirements.
Version 3.0
Page 9 of 78

Public
3.1.1 Single Cloud To begin with, the case of a single Cloud is considered. By single it is implied that the Cloud is managed by a single administrative entity (also called private cloud, cf. Section 3.2 of D1.1), i.e., the infrastructure belongs to one owner, even though it might be located physically in dispersed locations.
Figure 1: High-level depiction of a single-owned cloud (colored circles denote different network domains) In Figure 1, the internal structure of a Cloud is depicted. A Cloud is composed of interconnected data centers (the grey boxes) offering infrastructure (IaaS Cloud), platform (PaaS Cloud) or software (SaaS Cloud) services. These data centers are dispersed in order to serve better the Clouds end users, thus residing in different network domains (network domains are the differently colored circles in which data centers are located). The Cloud operator interconnects its data centers through SLAs with the involved Network Operators (NOs) or Internet Service Providers (ISPs), using private lines and specifying the exact characteristics related to the required quality of telecommunication services provided. Moreover, the Cloud operator manages the Cloud infrastructure through the use of Cloud management platforms, which usually also provide load balancing and traffic redirection functionality so as to maintain the operation of the Cloud at an optimal level. Finally, in order to better serve their customers and bring the content/services closer to them, Cloud operators (especially big players like Google, Amazon etc.) place their datacenters on Tier 1 or Tier 2 domains [58]; sometimes they even place Points of Presence (PoPs) in Tier 3 domains. End users typically access the Internet through Tier 3 domains, hence the network path from an end user to the closest Cloud PoP is, most of the times, unique. This is straightforward since for most Tier 3 domains there is a single path to a Tier 2 or Tier 1 domain; exception to this is the cases multi-homed domains but again the routing policies of those domains typically result in one path per destination. In this context, it becomes obvious that there is no potential for intervention and further optimization by third-party solutions like SmartenIT, since the Cloud operator is controlling everything: placement of data centers, placement of PoPs, interconnection of data centers (in collaboration with Tier-1 ISPs) with specific characteristics, load balancing between
Page 10 of 78
Version 3.0

Public
data centers, traffic redirections from PoPs to data centers and unique path from a PoP to the end user. Hence, the single cloud case is not considered relevant for SmartenIT, from the perspective of managing traffic that travels across the public Internet. However, there may be issues regarding energy efficiency and user mobility that can still be addressed by the project. 3.1.2 Federated Cloud The next case that could be of interest to SmartenIT is that of the Federated Cloud. A federated Cloud is comprised of smaller data centers that belong to different administrative entities who want to collaborate for various reasons (extend their customer base, compete against bigger Cloud players, etc.) [59]. In Figure 2, the structure of a Federated Cloud is depicted. Data centers are now of different color that symbolizes the different ownership.
Figure 2: High-level depiction of a federated cloud (colored circles denote different network domains, colored datacenters show different ownership) By definition, a Federated Cloud is comprised of small data centers; hence, it can be expected that these data centers may reside in Tier 3 domains and their owners may not be in place to acquire high quality (and thus expensive) private links to interconnect with each other. Thus, due to the small market power, the data center owners could ask from the interconnecting ISPs to provide them cloud(-related) traffic management services (in the sense of outsourcing). ISPs could benefit from selling such services, by enriching their portfolio and increasing their profits. Traffic management (between datacenters) is necessary in this case, since there exist multiple paths (with different characteristics) between two datacenters due to the fact that they reside to Tier 3 domains. Additionally to traffic management, an ISP can also offer load balancing (and traffic redirection) services to the datacenter owners, unless one of the datacenters belonging to the federation could uptake this role. Hence, in the case of a Federated Cloud, there are opportunities for traffic management and potentials for optimization, and SmartenIT can offer solutions targeted to data center owners.
Version 3.0
Page 11 of 78

Public
3.1.3 Interconnected Clouds A third case is already identified as interesting to SmartenIT is that of the Interconnected Clouds, as already identified in the description of interesting scenarios in deliverable D1.1. For reasons that fall outside the scope of this deliverable, but can be summarized as extending Clouds customer base, providing/offering specialized services, and extending reachability, Clouds under different ownerships and of different sizes may decide to interconnect and perhaps merge their service portfolios. Such a case is depicted in Figure 3 below.
Figure 3: High-level depiction of interconnected clouds (colored circles denote different network domains) There are three issues that need to be taken into account in this case: i) the absence of a cross-Cloud load balancer may motivate ISPs to cover this role, ii) the interconnection of different sized Clouds (residing at different tiers) may require specific traffic management mechanisms and iii) specialized services may generate complex traffic patterns that should be further considered in the interconnection case. 3.1.4 End-user Considerations While the first cases introduced the more data center/cloud centric considerations, the projects also aims to consider the user perspective of the access to applications and services hosted in the cloud. Besides traditional home devices, such as desktop PCs and laptops, especially the use of mobile devices imposes a number of relevant questions and problems to be considered. Outside the range of WiFi-based home or corporate networks, mobile devices are increasingly used to access cloud applications and services using access technologies, such as 3G/UMTS or 4G/LTE. Due to these technologies aim to provide connectivity over longer distances than, e.g. WiFi, they play an important role for the energy consumption of mobile devices and thereby also the access to cloud-based services. In this case,
Page 12 of 78
Version 3.0

Public
depending on the kind of service to be accessed, there is the possibility to use a more distributed approach and switch to a more energy-efficient WiFi-based communication with other nearby devices [62]. Here, traffic is to be forwarded and distributed by the mobile devices themselves in an ad-hoc manner. For data intensive content this could allow for a relevant reduction in the energy consumption. Besides this energy consideration, the access to services hosted in the cloud can be negatively impacted by the length of the network path to the cloud that hosts the service, inducing undesired delays and a poor user experience. In this case, the use of ad-hoc but also infrastructure-based communication between clients could provide an alternative solution. For the latter, the appropriate traffic management mechanisms in the access and core network have to be aligned with the management of the cloud traffic and have to be considered. Finally, a complementary approach to both reduce energy consumptions as well as the network distance to the cloud is the use of nano data centers (cf. Section 3.2.5). Here, devices, such as the home router of users can become an active entity, providing or complementing cloud services in a distributed manner. Details on this concept are introduced in Section 3.2. Similar to the previous case, the network traffic management for such distributed approaches has to be aligned with the management of the cloud traffic. Depending on the observed traffic conditions and requests, services could dynamically be moved to nano data centers at the edge of the network to optimize the load situation, depending on the overall traffic management decisions.
3.2
Related Approaches and Architectures
This section provides an overview of approaches and architectures that can be considered as tackling a specific problem that is either similar or a subset of what SmartenIT addresses. We focus on the architecture designed by each approach. The purpose is to identify their possible points of inspiration, collaboration or interfacing that can drive the design of an architecture that follows the latest developments in the area of network, cloud and overlay management, so as to address SmartenIT key objectives. This section focuses on closest prior art on Cloud traffic management architecture. The closeness of related approaches is defined w.r.t. the four SmartenIT key design goals G1, G2, G3, G4 to integrate features supporting: (G1) energy efficiency, (G2) QoE awareness, (G3) incentive compatibility, (G4) social awareness. These four key goals are distributed in the following key challenges Ci that participate to the selected SmartenIT scenarios: C1 - Energy-efficiency of network infrastructure C2 - Energy-efficiency of end user devices C3 - Inter-domain traffic (costly for some ISPs) C4 - (Uncoordinated/unmanaged) inter-cloud traffic (e.g. for federated clouds, intercloud)
Version 3.0
Page 13 of 78

Public
C5 - Traffic management for ISPs but also cloud providers (covering bursty traffic situations and congestion cases) C6 - QoE of end user. The remainder of this section presents a selection of prior art that is considered best addressing the SmartenIT challenges. As a summary, Table 1 provides a mapping of the presented approaches to the key Smarten IT goals and applicable scenarios. SDN, ALTO, Cloudlets, NaDA, SmoothIT, ABNO and ETICS relate to some of the SmartenIT key goals Gi and Contexts Ci whereas FI-WARE, OpenNebula and Openstack are generic implementation frameworks for future Internet or cloud infrastructure functionalities. D3.1 aims at a preliminary architecture and goals (G1) and (G4) are not reflected in this section. Note, however, an architecture for social-aware applications is presented in [63] and is considered in D2.1 (traffic management solutions and social-awareness). APPROACH SDN ALTO FI-WARE Cloudlets NaDA SmoothIT OpenNebula & Openstack ABNO ETICS SmartenIT GOAL G1 G2, G3 SmartenIT CHALLENGE C1, C4, C5, C3 C3, C4, C5, C6
Generic platform to host core functionalities of the Future Internet G1, G2 G1, G3 G2, G3 G2 G2 C1, C2, C6 C1, C2, C5 C3, C5, C6 C3, C5, C6 C3, C6
Generic platform providing tools for overlay management
Table 1: relevance of state of art approaches to SmartenIT challenges 3.2.1 Software Defined Networks (SDN) A new idea of Software Defined Networks (SDN) [1] allows overcoming the limitations of existing static and complicated network architectures. This is an approach to network management that simplifies and separates data and control planes [2]. Network configurations and policies are logically centralized. Underlying network infrastructure is abstract and independent of certain network technologies. In general, the architecture of SDN consists of 3 layers (see Figure 4): the Infrastructure layer where the real network infrastructure with traffic forwarding functionality resides, the Control layer containing network intelligence in software-based controllers and the Application layer.
Page 14 of 78
Version 3.0

Public
Figure 4: The SDN architecture [1] The open API between the top two layers allows building the applications operating on an abstraction of the network. Such architecture and standardized access to the network infrastructure can be used for flexible connection configuration addressing various demands. An example is establishing circuits among data centers taking into account energy efficiency or selection of energy source. A real example of SDN concept is presented in the OpenFlow specification [3]. This is the first standard communications interface between the control and forwarding layers. OpenFlow is based on the concept of flows to identify the network traffic. A set of rules, defining how the flows are handled, is established in the Controller and applied in the OpenFlow enabled network devices. Examples of rules for the managements of flows can be found in [4]. SDN and its emerging implementations seem to be a very promising direction for SmartenIT as the concept is simple and modular. Proposed decompositions, focus on interfaces, abstract representation of topology, and standardized access to the network devices give an ability to add the extensions representing SmartenIT networking functionalities. There are also some drawbacks of SDN (e.g. scalability, focus on singledomain deployment or early stage of available implementations) but this will have to be investigated if they are acceptable by SmartenIT. 3.2.2 Application Layer Traffic Optimization (ALTO) ALTO stands for Application Layer Traffic Optimization and is a client server IETF protocol. Its design goal is to help applications to choose the best possible resource location, where the term resource may cover content as well as computing resource. This section discusses the base ALTO protocol as well as the combination of ALTO with SDN. 3.2.2.1 The base ALTO protocol and architecture As described in the base protocol IETF draft [20], the IETF ALTO working group originally provides guidance to content delivery applications such as P2P or Content Delivery Networks (CDN), which have to select one or several hosts or endpoints from a set of candidates that are able to provide a desired data resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve the Quality of
Version 3.0
Page 15 of 78

Public
Experience (QoE) of the application while reducing resource consumption in the underlying network infrastructure. To this end, ALTO Servers deployed by NOs, provide requesting ALTO Clients with information, currently such as the NO-centric view on the network topology, the candidate endpoints with attributes such as their routing cost or connectivity type. Quoting draft [20]: The ALTO Server internally maintains an ALTO Information Base that encodes the network providers preferences. The ALTO Information Base encodes the Network Locations defined by the ALTO Server (and their corresponding properties), as well as the provider-defined costs between pairs of Network Locations. The ALTO protocol provides application clients with the following ALTO Information Services. As specified in [20]: The Map Service: provides the full set of Network Location groupings defined by the ALTO Server and the Endpoints contained with each grouping. The Cost Map Service: indicates preferences amongst network locations in the form of Path Costs. Path Costs are generic costs and can be internally computed by a network provider according to its own needs. The Endpoint Cost Service: optional, it allows an ALTO Server to return either numerical costs or ordinal costs (rankings) directly amongst Endpoints. The Map Filtering Service and the Cost Map Filtering Service: allow ALTO Clients to query for parts of the ALTO Server Network Map and Cost Map based on additional filtering parameters. The Endpoint Property Service: allows ALTO Clients to look up properties for individual Endpoints. An example endpoint property is its Network Location (its grouping defined by the ALTO Server) or connectivity type (e.g., ADSL, Cable, or FTTH).
Figure 5 provides the basic ALTO architecture depicted in the IETF draft [20]. Note that ALTO is also further presented and discussed in Deliverable D2.1 Report on Overview of Overlay Traffic Management Solutions.
Page 16 of 78
Version 3.0

Public
Figure 5: Basic ALTO architecture It should be noted that currently the insight of ALTO information in the path between a User Equipment (UE) and a connection node (or say endpoint) does not provide details below IP hops, among others for scalability reasons. However, the major QoE challenges of wireless network users arise in the access network, that is, in the first hop between the UE and its one or more serving Packet Data Network (PDN) Gateway (PGW). The path of a UE to its serving PDN(s) impacts the path to the content and thus the related QoE. Therefore, it is necessary to detail access costs to the UE as well in order to take the appropriate decisions w.r.t. the utilized access path. The access technology in current ALTO protocol is accounted at the resource location (last hop) side by distinguishing whether the requested content is located in a fixed or a wireless access network, as described in [21] that states: For ISPs with mobile network and fixed network, the traffic optimizing problems they focus will be optimizing the mobile traffic, except problems on last hop section. First and last hop ALTO information is a key aspect when applications in the cloud are accessed from user devices via multi-access technologies and SmartenIT is looking at benefits to wireless devices and networks needing to push their work and storage load to the network. The ALTO WG is looking at other use cases besides the legacy P2P and most of them need protocol extensions. In particular the Data Center (DC) use case relates to the SmartenIT problem in that abstracted information on the DC infrastructure topology provided via the ALTO protocol can help optimizing the traffic of virtualized applications among Data Centers. Such a use case motivates several ALTO extensions. It is also highly relevant to the SmartenIT goal of optimizing ISP and Cloud provider traffic while preserving the user QoE. The base ALTO protocol is currently on the Internet Engineering Steering Group (IESG) track but not yet stabilized.
Version 3.0
Page 17 of 78

Public
3.2.2.2 Combination of ALTO and SDN SDN has been presented in Subsection 3.2.1 as a very promising traffic management solution for SmartenIT. An ALTO Server can assist an SDN Controller by hosting abstracted network information that can be provided to SDN aware applications via an ALTO Client. It can also assist other SDN Control operations using information in and outside the ALTO scope. In particular, [22] identifies the SDN Controller functions that ALTO is well suited to perform, the primitives of Abstraction, Get network topology, Get network resources and Event notification. Additionally, the interaction between ALTO and SDN has been investigated in [23] to provide applications with a path selection meeting Quality of Service (QoS) requirements on bandwidth and delay. Currently, the base ALTO protocol allows performing the following SDN services, see [22]: 1. Abstraction: through aggregation into Provider-defined Identifier (PIDs), ranking and a generic cost type. 2. Get network topology: through the Map and the Cost Map Services 3. Get device capabilities": through the Endpoint Property Service. Figure 6 shows how the ALTO protocol can be integrated in the conceptual SDN architecture to support SDN primitives.
Figure 6: Integration of ALTO protocol into the conceptual SDN architecture Virtualized applications in large Data Centers are supported by virtualized servers that actually gather resources distributed on several physical servers. The federation of these resources is often orchestrated by a centralized entity that needs to select the physical servers from or to which it will take resources. This entity is a particular case of application endpoint selection function (AESF) as depicted in Figure 6 and can be co-located with an ALTO Client that will request and get the ALTO information on the network formed by the physical servers. The physical servers can be assimilated to endpoints with which the orchestration entity trades application resources or content. These resources include
Page 18 of 78
Version 3.0

Public
computation resources, storage capacity and path bandwidth between the physical servers. The applications may have different and specific QoE requirements. The Endpoint selection typically needs to consider both the computational resources at the Endpoints and the resources, e.g., in bandwidth on the transmission paths to or among Endpoints. Thus the applications QoE requirements drive the Endpoint selection with more or less weight on QoE specific metrics such as hop count or delay, bandwidth and other resources that are typically combined with the routing cost and need to jointly integrate the Endpoint and transmission path perspective in the decision process, which is difficult to do with one single Cost Type. Besides, the application traffic volume is often time varying and should be distributed over time as well whenever it is possible. An ALTO Service supporting timeliness and QoE awareness can efficiently help an SDN Controller to guide the traffic of clouded applications and is one of the mechanisms investigated in SmartenIT. Architecture options to allow the co-existence of ALTO and SDN are proposed at the IETF in [23] that also proposes corresponding ALTO protocol extensions. In particular, when several SDN domains are involved in an application, the trade-off is whether to associate an ALTO Server to each SDN Domain controller to support fine grained information for local decisions with however less cohesion and flexibility or to have one ALTO Server for all SDN Domains, with more coherence and flexibility but coarse grain information. This issue should be investigated as work in T3.1 progresses. 3.2.3 FI-WARE The FI-WARE project [5] is being developed as part of the Future Internet Public Private Partnership (FI-PPP) program [6], launched by the European Commission in collaboration with the ICT Industry. It aims to build the Core Platform of the Future Internet introducing an infrastructure for creation and delivery of digital services, providing high QoS and security guarantees. The most important concepts of the FI-WARE platform are the following: FI-WARE Generic Enabler (GE): A functional building block of FI-WARE. Any implementation of a concrete GE supports a concrete set of Functions and provides a concrete set of APIs in compliance with GE open specifications published for that GE. FI-WARE Compliant Platform Product: A product which implements, totally or in part, a FI-WARE GE or composition of FI-WARE GEs (therefore, implements a number of FI-WARE Services). FI-WARE Instance: The result of the integration of a number of FI-WARE compliant Platform Products and, typically, a number of complementary products. As such, it comprises a number of FI-WARE GEs and supports a number of FI-WARE Services. FI-WARE Instance Provider: A company that operates a FI-WARE Instance. Future Internet Application: An application that is based on APIs defined as part of GE Open Specifications. A Future Internet Application should be portable across different FI-WARE Instances that implement the GEs that Future Internet
Version 3.0
Page 19 of 78

Public
Application relies on, no matter if they are linked to different FI-WARE Instance Providers. The Reference Architecture of the FI-WARE platform is structured along a number of technical chapters, each one of them considered as a FI-WARE Platform Compliant Product, implementing a composition of GEs. The list of these technical chapters includes i) Cloud Hosting, ii) Data/Context Management, iii) Internet of Things (IoT) Services Enablement, iv) Applications/Services Ecosystem and Delivery Framework, v) Security, and vi) Interface to Networks and Devices (I2ND). Cloud Hosting and Interface to Networks and Devices are in direct relation to SmartenITs goals and are further analyzed below. 3.2.3.1 FI-WARE Cloud Hosting Cloud hosting companies, considered as a particular type of FI-WARE Instance Providers, own and manage large IT infrastructures and offer their use as a service on a pay-as-yougo model to the so called cloud hosting users, i.e., organizations or individuals that own the compute processes or applications but do not own the physical infrastructure to run them. FI-WARE Cloud Hosting [7] aims at delivering a next-generation, open, scalable, resilient, standardized, and secure intermediate Cloud Stack that will enable Future Internet applications by providing service-driven IaaS and PaaS functionalities and extending the reach of the cloud infrastructure to the edge of the networks, much closer to end users. A high level view of the Cloud Hosting architecture is provided in Figure 7.
Figure 7: The FI-WARE cloud hosting architecture [7] A brief description of the major GEs that seem to be of interest to SmartenIT, in the sense that the SmartenIT system could interface with or even implement some of these enablers since they are expected provide functionality that is directly-related with SmartenITs envisioned operations, is provided below: PaaS Management: this GE provides hosting of application containers, such as Web container, database instance, etc. It leverages IaaS underneath, to automate the lifecycle of the underlying infrastructure and OS stack.
Page 20 of 78
Version 3.0

Public
IaaS Service Management: This GE provides hosting of compound VM-based services, including their definition and composition, deployment and life cycle management, as well as monitoring and elasticity. This GE is also able to communicate with other clouds, in scenarios of cloud federations. Monitoring: this GE will be responsible for collecting metrics and usage data of the various resources in the cloud. Metering & Accounting: this GE will be responsible for collecting and processing the data related to usage and monetization of cloud services (via an external Billing system, which is not part of this GE).
3.2.3.2 FI-WARE Interface to Networks and Devices (I2ND) A variety of user devices get connected to a variety of networks in modern Internet. Applications running on these devices are getting more and more complex as they have to carry the burden of handling both devices and networks varying and changing nature. FIWARE addresses the definition of GEs implementing a common and standard Interface to Devices and a common and standard Interface to the Networks in order to remove complexity from the applications. The GEs provided to implement a standardized Interface to Networks and Devices (I2ND) [8] can be used by other FI-WARE elements, such as Cloud Hosting, IoT, etc. They can also be directly used by the applications in multiple Usage Areas. A high level view of the Interface to Network and Devices Architecture is provided in Figure 8.
Figure 8: The FI-WARE interface to networks and devices architecture [8] A brief description each GE is provided below; it seems that SmartenIT can use some interfaces provided by these Enablers assuming that in the Future network devices will follow FI-WAREs proposals for providing generic interfaces (in case SmartenIT aims at becoming FI-WARE compliant and fit under the umbrella of Fi-WAREs and EUs vision): Connected Device Interfacing (CDI): This is the GE which interfaces the FI-WARE applications providing through unified APIs the possibility to exploit the device
Page 21 of 78
Version 3.0

Public
features and capabilities. It also interfaces services offered by other FI-WARE GEs, through the internal interface with the S3C Generic Enabler (see below). Cloud Edge (CE): This is the GE in charge of interfacing the Cloud Proxies with the FI-WARE and legacy cloud services. The interfaces provided by the CE GE cover a variety of cloud proxies functionalities: end-device communication, home system management, virtual machine management, protocol adaptation, etc. The CE interfaces are also used internally by the S3C Generic Enabler to control the cloud proxies. Network Information & Control (NetIC): this is the GE providing a homogeneous access to heterogeneous open networking devices. It exposes network status information, enables network virtualization and a certain level of programmability within the network, e.g., concerning flow processing, routing, addressing, and resource management at flow and circuit level. The NetIC interface focuses on transport mechanisms This GE also offers a set of I2ND internal interfaces to the S3C in order to control the open networks. Service, Capability, Connectivity and Control (S3C): this is the GE providing access to legacy network devices features, capabilities and services. In particular, the aim of this GE is to mitigate the challenges of packet core networks by offering extended interfaces for various service platforms. The S3C functional component therefore mainly considers interfaces at service level.
3.2.4 Cloudlets Mobile technology evolves rapidly towards lighter, smaller and less battery consuming devices. All these properties-goals, when achieved, impose a severe penalty in computational resources such as processor speed, memory size, and storage capacity. On the other hand more and more computationally intensive applications get developed for mobile devices. One way to offload the devices is to bring cloud technology into play. Unfortunately clouds involvement introduces unacceptable delays due to high, WANattributed, latencies. To cope with this latency the concept of cloudlet is introduced. Etymologically cloudlet means small cloud. Strictly speaking, a cloudlet is a trusted, resource-rich computer in the near vicinity of the mobile user (e.g., near or collocated with the wireless access point). The concept of the cloudlet is a version of the Cloud reduced to a single, on a box data center. The data center would be owned by a small business, like a cafeteria or a hotel, co-residing with its WiFi LAN (offering single-hop latency) and constituting a hot spot for dense computational power. The mobile device functions as a thin client, with respect to the service, with all significant computation occurring in the nearby cloudlet. If no cloudlet is available nearby, the mobile device can gracefully degrade to a fallback mode that involves a distant cloud or, in the worst case, solely its own resources. One implementation solution of a cloudlet introduced in [9] and presented here can be defined as transient customization of cloudlet infrastructure using hardware virtual machine (VM) technology. In the supporting architecture (see Figure 9), a mobile user exploits VM technology to rapidly instantiate customized service software on a nearby cloudlet and then uses that service over a wireless LAN. A VM cleanly encapsulates and separates the transient guest software environment (VM overlay) from the cloudlet infrastructures permanent host software environment (VM base).
Page 22 of 78
Version 3.0

Public
User interaction VM Overlay Transfer VM Synthesis
VNC server
VM Base
VM overlay Wireless link VNC client Control Manager Guest
Control Manager Host
Cloudlet
Mobile device
Figure 9: Cloudlet implementation using hardware VM technology The VNC (Virtual Network Computing) components, client side and server side, constitute the well-known graphical desktop sharing system that transfer the keyboard and mouse events and graphical screen updates between the aforementioned sides over a network. The approach selected for delivering VM state to infrastructure is the dynamic VM Synthesis. According to that a mobile device delivers a small VM overlay to the cloudlet infrastructure that already possesses the base VM from which this overlay was derived. The infrastructure applies the overlay to the base to derive the launch VM, which starts executing in the precise state in which it was suspended; see Figure 10 for the dynamic virtual machine synthesis timeline.
Figure 10: Dynamic VM synthesis timeline [9] It is anticipated that a relatively small number of base VMs (perhaps a dozen or so releases of Linux and Windows configurations) will be popular worldwide in cloudlets at any given time. Hence, the odds are high that a mobile device will find a compatible base for its overlays even far from home. Two advantages of this approach are that i) its
Version 3.0
Page 23 of 78

Public
performance is determined solely by local resources, i.e., bandwidth to cloudlet and the cloudlets compute power, and ii) WAN failures dont affect the VM synthesis. SmartenIT is not expected to provide solutions in the VM layer, but having in mind the Cloudlets approach might help to design an architecture that allows SmartenIT to offer solutions for the localization of Cloud resources and for bringing the content and services closer to the end users, especially in the case of mobile users. 3.2.5 Nano Data Centers (NaDa) One of the goals of NaDa is to reduce energy consumption, especially of modern Data Centers. In [28] a new, distributed computing platform called Nano Data Centers (NaDa) is proposed. NaDa uses ISP-controlled home gateways to provide computing and storage services and adopts a managed P2P model to form a distributed data center infrastructure. The underlying assumption is that home gateways are always powered on and the additional power consumption for additional tasks is lower than on servers in a data center. Figure 11 shows the high level architecture of the NaDa approach. NaDa follows a P2P philosophy, but contrary to typical P2P, NaDa is coordinated and managed by an ISP that installs and runs the gateways that act as nano servers, as well as the network that interconnects them. Due to its managed nature, NaDa avoids most of the shortcomings of classic unmanaged P2P. ISPs can implement NaDa by providing new customers with slightly over dimensioned gateways, whose extra storage and bandwidth resources would be used by NaDa to implement services like video hosting, all of which will be totally isolated from the end-user via virtualization technologies. Thus, with a rather small investment in higher capacity devices, ISPs can go beyond their traditional role as communication carriers, and enter the potentially highly profitable service and content hosting market [28]. Instead of having NaDas controlled by the ISP, the NaDas may be controlled by the end-users. This would allow a higher intervention potential for SmartenIT. However, extra incentives need to be provided to the end-user due to higher end-user bandwidth usage and energy costs.
Figure 11: High level NaDa architecture [28] 3.2.6 SmoothIT Architecture In the past few years, a main problem of ISPs was huge traffic generated by P2P networks. The Simple Economic Management Approaches of Overlay Traffic in Heterogeneous Internet Topologies (SmoothIT) project [65] dealt with mechanisms that
Page 24 of 78
Version 3.0

Public
enable the management and optimization of overlay application traffic in networks owned by ISPs and telecommunication operators. In the scope of the SmoothIT project, the Economic Traffic Management (ETM) mechanisms were proposed. These mechanisms aim was two-fold: to keep low costly inter-domain traffic, while improving users QoE. ETM is composed of three basic mechanisms that allow keeping overlay traffic in a local domain: BGPLoc This mechanism involves a server that provides advice to a requesting peer by rating his candidate neighbors. Peers initiating connection choose their partners in the specific order, the most preferred are peers located in the local Autonomous System (AS). Candidate peers for connection are ranked according to their localization in reference to the local AS peers located in local AS are preferred. A requesting peer which wants to join an overlay network, obtains a list of candidate peers for connection (for instance from the overlay tracker). Next it consults this list with SmoothIT Information Server (SIS) which ranks the peers on list. Peers with the highest rank (refers to the most preferred) are chosen first by the requesting peer. As a result, a peer may rely its decision of peer selection both on the overlay view (via the ranking performed by the overlay application using overlay-specific metrics), and on the underlay view (via the ranking provided by the ISP). ISP owned Peer (IoP) An ISP possesses a special server (cache), equipped with abundant resources (storage, bandwidth) which participates in the overlay network running the P2P protocol. IoP can be either transparent, or promoted by the overlay tracker, while it is preferred by other peers, due to its abundant resources and the exploitation of inherent incentive mechanism of the overlay. Depending on the popularity of content among the peers of the local domain, the IoP joins the respective swarms, downloads the content, and starts serving the local peers so as to reduce the unnecessary usage of inter-domain network resources. Highly Active Peer (HAP) This mechanism rewards highly active peers who possess and altruistically share a lot of content. This peer is not in the ISP possession but it is run by an end user. The incentive to users to actively share content with other local peers is an increased capacity of access link offered by ISP for free. The status of HAP is granted to peers that seed popular content for a long time and does not limit much the upload speed. Other peers requesting content try to download content from a HAP in the local AS since they are attractive to them. This mechanism is a conceptually similar to the IoP but achieves the same objectives in a distributed manner. Instead of having a central ISP-controlled peer that tries to improve the performance of local peers of a given swarm, the HAP mechanism distributes this responsibility to many regular local peers by assigning them temporarily extra network resources. The decision of which peers should be promoted to HAPs is taken by the ISP and is based by the overlay behaviour of the peers, the swarms they join, the compatibility of their actions with the ISPs goals.
Below in Figure 12 there is presented the SmoothIT system architecture, the central element is SIS. In the scope of SmoothIT project inter-SIS communication was also considered, where the prototype of inter-ALTO protocol was implemented. This protocol was used for retrieving information from a remote AS where candidate peers for connection were located.
Version 3.0
Page 25 of 78

Public
Overlay App 1 Overlay Mngt
Overlay App 2 Overlay Mngt
SIS Layer
Overlay Node
NW Transport
Overlay Node Overlay Node
ISP
SIS
SIS
SiS-To-ON IF SiS-To-SIS IF
ISP
Overlay Node
Core Internet
SIS Layer NW Transport

SIS
Overlay Node Overlay Node
ISP
Overlay Node
Figure 12: The SmoothIT system [64] Smoothit solutions, especially ETMs using SIS server for influencing overlay traffic are relevant to SmartenIT. The Smoothit project was focused on interaction between ISP and customers running overlay application with the aim of optimization overlay traffic. One of the developed extensions was inter-SIS communication protocol (proposed later as interALTO to the IETF community) that extended system capabilities with information exchange between different domains (ISPs). Similar to the ALTO concept, SIS is a promising solution that can be used as a basis for building SmartenIT traffic management system capable of influencing application layer traffic, and enabling collaboration between different stakeholders, including ISPs, Cloud providers, CDNs, and customers. Some architectural components of SIS and Smoothit system are conceptually close or would be identical to SmartenIT system architecture components. 3.2.7 OpenNebula and OpenStack OpenNebula and OpenStack are powerful and thus very popular platforms that provide a set of tools to build the cloud infrastructures of the IaaS model. Their openness and available APIs allow developing new services on top of highly distributed, virtualized and dynamically allocated resources. SmartenIT can use one of them as an implementation platform to develop, test and deploy traffic management solutions proposed by the project team. Moreover, the experience and software products collected and produced by other many ongoing research projects that utilize OpenNebula or OpenStack can be used by SmartenIT. 3.2.7.1 OpenStack OpenStack [10] is an open source initiative and a Cloud Management System (CMS) to build public and private clouds in the model of IaaS. OpenStack is composed of tools (each is represented by a separate project), which offer basic functionalities (see Figure 13):
Page 26 of 78
Version 3.0

Public
Compute Nova provides virtual servers upon demand and configure networking, Object Store Swift provides a storage with built-in redundancy and failover, Image Service Glance manages (discovery, catalogue functionalities) virtual disk images for Compute Nova, and repository
Dashboard Horizon provides a web-based interface to the OpenStack services, Identity Keystone provides the authentication and authorization functionalities, Networking Quantum provides advanced networking functionalities to build topologies, services and establish advanced network policies in the cloud.
Figure 13: OpenStack general architecture [44] OpenStack is a powerful platform because it gives a rich set of APIs and is ready for extensions implementing new functionalities. This allows creating innovative services made by engineers in various projects. SmartenIT may use OpenStack to build an environment to test traffic management solutions developed by the project. 3.2.7.2 OpenNebula OpenNebula [43] is an advanced open source platform to build and manage the virtualized environment of clouds in the model of IaaS. It contains a set of tools and interfaces to offer the components and functionalities (see Figure 14) such as: virtualization management (support of various hypervisors), networking, storage, resource monitoring, accounting for resource usage reporting, and security (authentication, authorization, role management based on the access control list).
Version 3.0
Page 27 of 78

Public
Figure 14: OpenNebula functionalities [43] Furthermore, OpenNebula can be used for all types of cloud deployment. This flexibility and maturity have been proven in the research projects like BonFire (Building service testbeds for Future Internet Research and Experimentation) [12]. The project builds a cloud containing large-scale virtualized compute, storage and networking resources with the necessary control and monitoring services for experimentation. PSNC, a member of the SmartenIT consortium, is responsible for maintaining one of the sites of the BonFires infrastructure and integration of BonFIREs services with services of external projects (like GEANT BoD - Bandwidth on Demand [13]). Like in case of OpenStack SmartenIT may use OpenNebula to build an environment to test traffic management solutions developed by the project. At the moment the OpenStacks networking component, Quantum, seems to offer more flexible API-based networking management. 3.2.8 Application-Based Network Operations (ABNO) Application-Based Network Operations (ABNO) [42] is a general framework where several already existing components get combined and enhanced with some new elements in order to gather information about the available network resources, consider topologies and their mapping to the underlying network resources, request path computation, provide or reserve network resources.
Among the new added elements the most prominent is the Path Computation Element (PCE), the main role of which is, as implied, to compute GMPLS and MPLS network paths and to provide policy enforcement capabilities for ABNO platforms and services. ABNOs functional components depicted in Figure 15 together with the corresponding connectionsinterfaces are: Network Management Systems (NMS) and Operations Support Systems (OSS) Application Service Coordinator ABNO Controller
Page 28 of 78
Version 3.0

Public
Policy agent Interface to the Routing System Client (I2RS) Operation, Administration, and Maintenance (OAM) Handler Path Computation Element (PCE) Databases ALTO server Virtual Network Topology Manager (VNTM) Provisioning Manager Client and Server Network Layers
OSS / NMS / Application Service Coordinator
Policy Agent
ABNO Controller
OAM Handler
ALTO Server
VNTM PCE I2RS Client
Databases TED LSP-DB Provisioning Manager
Client Network Layer
Server Network Layers
Figure 15: The ABNO architecture The use cases examined by ABNO include: i) inter-AS connectivity, ii) multi-layer networking, iii) bandwidth scheduling, iv) grooming and regrooming, v) global concurrent optimization and vi) adaptive network planning. Moreover, ABNO can provide the following types of service to applications by coordinating the components that operate and manage the network: Optimization of traffic flows between applications, described as Application Layer Traffic Optimization (ALTO) [39]. Remote control of network components allowing coordinated programming. Interconnection of Content Delivery Networks (CDNi) [40]. Network resource coordination to facilitate grooming and regrooming, bandwidth scheduling, and global concurrent optimization [41]. Virtual Private Network (VPN) planning in support of deployment of new VPN customers and to facilitate inter-data center connectivity.
Given that both the aforementioned use cases and the provided services are very close to SmartenITs objectives, ABNO renders as an approach that will be further investigated, especially in the area of provisioning network resources to manage Cloud-generated traffic. Consequently, SmartenIT may adopt concepts and ideas from ABNO. However,
Version 3.0
Page 29 of 78

Public
since ABNO is in its early stages, being very recently proposed to the IETF standardization body as a general architecture, perhaps some of the mentioned concepts may need to become more mature in order to be adopted by the SmartenIT approach. 3.2.9 ETICS The ETICS project [37] aimed at creating a new ecosystem of innovative QoS-enabled interconnection models between Internet service providers allowing for a fair distribution of revenue shares among all the actors of the service delivery value-chain (c.f. Figure 16). In particular, the ETICS project focused on studying and assessing the current Internet Interconnection (henceforth referred to as IC) ecosystem and market, identifies unmet needs and proposes new business models and IC goods; namely, the Assured Service Quality (ASQ) goods, which are expected to contribute to the health of the ecosystem and the increase of the IC market, to the benefit of all the actors involved. The ETICS ASQ products are a family of novel IC products that support paths with predefined assured performance in terms of business and technical attributes, described in an SLA. There can be several variants of ASQ goods, depending on those parameters e.g. whether the source or the destination is a point or set of points (multipoint path).
Consumer Customer
Information SP
Business Customer
ETICS Provider(s)
ETICS requirements and specification scope Out of ETICS solution scope Context for ETICS requirements
Figure 16: The ETICS actor role model and the definition of the ASQ product [37] The ASQ products are the only IC goods that guarantee network performance, as opposed to the peering and transit products, which allow best-effort connectivity without any guarantees. Also, the ASQ product definition allows a finer degree of traffic control over inter-domain network paths and regions, while peering and transit by definition either pertains to two entire networks (peering) or offer global connectivity to their buyer (transit). The main added value of the ETICS project is that a) it proposes a common technologically-agnostic language for QoS via the definition of a standard set of SLAs, b) it decouples routing from BGP, using an overlay layer, thus allowing multiple routes from any point A to any point B in the Internet, thus the appropriate one can be chosen according to monetary and QoS constraints,
Page 30 of 78
Version 3.0

Public
c) the ASQ interconnection products can incentivize actors such as Network Service Providers (NSPs) to provide the demanded effort for achieving end-to-end QoS via rewards (resp. penalties for non-conformance) and monitoring, d) it proposes coordination and information models that can support a variety of business models so that the interconnection market can conduct their business. Overall, this is a promising solution in the network layer and its impact and adoption by the market remains to be seen. This project can be seen as an evolution of previous EU projects, namely EuQoS and MESCAL, which also propose such architectures but were relying on BGP QoS extensions. (A) The latter has proven a bad choice, due to both scalability issues and lack of standardization in the IETF that rejects QoS extensions to BGP. (B) It still however remains questionable whether the finer granularity in the management of aggregate traffic flows that ETICS envisions will indeed be adopted by the market. So far, the inter-domain Traffic Engineering decisions are based on BGP configuration taking into account the two standard interconnection agreements between networks, namely peering and transit, and their extensions. In particular, each AS configures its BGP tables in such a way that it balances traffic and attempts to use the best possible route in order to communicate with other AS. The extent to which this is possible heavily depends on the size of the network and the number of interconnection agreements, hence the number of neighbors it has and interconnection points where it has presence. SmartenIT might benefit from the insights gained in ETICS when designing traffic management solutions for social network traffic which is delivered to consumers located in different ASes. EuQoS heavily relies on extending BGP for performing QoS routing while ETICS also deals with delivering hard QoS guarantees over "assured service quality" paths that are established and enforced over routes in general different than BGP (published via an overlay layer and a portal). Its implementation is based on overlay inter-PCE communication (over multiple AS).
Version 3.0
Page 31 of 78

Public
4 Base Functionality and Conceptual Architecture

The SmartenIT approach aims at an incentive-compatible cross-layer network management that involves a number of different entities and spans several domains of traditional network and traffic management. Based on the problem description and discussion of related approaches in Section 3 above, the base functionality and the corresponding conceptual architecture for the SmartenIT approach are provided and discussed in this section. While Section 4.1 introduces the base functionality as derived from deliverable D1.1 as well as Section 3 above, Section 4.2 outlines the conceptual architecture which provides a) the domain view and b) the topological view on the initial SmartenIT architecture. This serves as the basis for the functionality specification in Section 5, and the definition of the initial system architecture presented later on in Section 6.
4.1 Base Functionality

Figure 17 presents the base functionality of SmartenITs approach, each of which span one or multiple domains and addresses one or more of three main SmartenIT objectives (depicted as design axes), relevant in all three domains.
Applications Cloud Storage Video Streaming Online Social Networks Domain Functionality Design Axis
Data center / Cloud Social Awareness
End User
Core & Access Network Quality Management (QoS/QoE)
Overlay Management
Cloud Traffic Management
Fixed/Mobile Network Traffic Management
Traffic Monitoring
Energy Efficiency
Incentives & Economic Considerations
Figure 17: The base functionality and key properties of SmartenITs approach
Page 32 of 78
Version 3.0

Public
There are three domains for network and traffic management plus the application domain; all depicted as grey boxes in Figure 17. The latter includes the cloud-based applications as source of the traffic to be managed. Prominent examples for such applications are cloud storage and video streaming services as well as online social networks. All three impose high requirements for the management mechanisms to be applied in the other three domains: Data center / Cloud: This domain covers entities and concerns that target the overlay and cloud traffic management. Here, data centers for hosting cloud services but also other overlay-based services, including peer-to-peer systems, are relevant. Core & Access Network: As most important bridge between data centers or Clouds and the end user devices, the core and access network exhibits a special role for the management of traffic. It carries traffic from a large number of different services and applications and interconnects many autonomous systems. The optimization of content delivery, the management of traffic flows, as well as the monitoring of the traffic are relevant aspects covered by this domain. Focus in mobile data delivery and mobile backbone will be also placed here. End User: The end user devices are considered as well as the possibilities to manage traffic to obtain a certain service quality for the user.
Across these domains, the SmartenIT approach targets three design axes, depicted by orange boxes in Figure 17. They are considered for the design and implementation of the newly developed traffic management mechanisms: Energy Efficiency: This axis spans all three main domains of network and traffic management. In all of them there is a need to provide not only operational mechanisms, but also to cause as low energy consumption as possible. At the user side, especially focusing on mobile scenarios, this requires applications that carefully use the resources of the mobile devices, leaving small energy footprint and preserving a long battery lifetime. For the core network, energy considerations are important as a large number of different infrastructure elements are involved. In this context, e.g., mechanisms such as Software Defined Networking (SDN) promise new, especially energy efficient solutions [60]. Finally, energy efficiency for the application provisioning infrastructure, the cloud, and thereby within data centers and its operation are relevant. Altogether, the SmartenIT approach promises to combine the potentials for energy savings for an integrated network and traffic management. Incentives & Economic Considerations: The SmartenIT architecture will be built on the concept of Economic Traffic Management (ETM) [14] introduced by SmoothIT. This principle suggests that traffic management technologies and solutions need to fulfill incentive compatibility in order to be successfully adopted in practice, namely they need to provide incentives for all stakeholders to cooperate in a joint cross-layer optimization approach, e.g., expose information by providing advice for more efficient handling of resources [15], reward incentive-compatible behavior of players [16], invest in and deploy infrastructures that imply benefit for other stakeholders too [17], [61]. Social Awareness: SmartenIT will derive and exploit social information (e.g. social graphs or social relationships among users) and meta-information (e.g., behavior patterns), for example in order to predict the generation of traffic, the destination of
Version 3.0
Page 33 of 78

Public
traffic flows, and the time when new traffic is about to be generated, either between end users and the Cloud, or within the Cloud / data centers. To derive such social information, in general, monitoring of Overlay Social Networks (OSNs) constitutes an option, though this approach is inadequate as only limited information can be extracted. To overcome this obstacle, incentives could be provided to OSNs to expose such information; the latter is addressed by the Incentives & Economic Considerations design axis. Within the domains, respecting the three design axes, different functional blocks exist that constitute the core of the SmartenIT approach. They are depicted by blue boxes in Figure 17. They provide the basis to derive the component architecture at a later step. In the next subsection a description of each functional block is provided as well as two diagrams that show better the interactions between the blocks and their placement.
4.2 Conceptual Architecture

In this subsection, the conceptual architecture with its functional blocks, their interdependencies, and their placement are provided. Two different views are presented: a (refined) view on the domains and the corresponding functional blocks as well as a topological view to better understand the potential placement of the proposed functional blocks. With this conceptual architecture, all four scenarios of SmartenIT are addressed. As example, in some cases, we focus on the inter-cloud scenario. Nevertheless, the architecture is more general and intentionally not limiting to this special case. 4.2.1 Domain View Figure 18 provides a first attempt to identify the functional blocks and their relationships. We assume that each data center/Cloud owns and operates its own DC/Cloud Management platform that is responsible for managing the virtual machines (VMs) and the various Cloud instances, performing load balancing, and traffic redirection. We also assume (for ease of presentation) that we have a SmartenIT Box (S-Box), for which we do not know its internal (logical) structure and do not make assumptions on how it is going to be implemented and deployed in detail. Therefore, we do not refer to the functional blocks as components, yet. However, we have already identified that there will be one such (logical) box in each network domain, in the premises of an ISP, network carrier, or at the end-user side. The objective of this abstraction is to be able to cover the complete set of functionalities but, nevertheless, respect the separation of concern in the different domains. Thereby, the S-Box is meant to address the union of required functionalities at a small scale, including a limited set of providers and end users. This allows for a scalable approach, extended by Inter-S-Box communication for larger scenarios.
Page 34 of 78
Version 3.0

Public
Existing Platform
DC/Cloud Management
Data Center / Cloud S-Box

Includes also (in the mechanisms materiaized): Incentives & Economics Social Awareness Cloud Traffic Management Overlay Management
Fixed/Mobile Network Traffic Management
Inter - S-Box communication
QoS/QoE Management
Energy Analyzer
Core & Access Network
Network Monitor
Energy Monitor
Social Monitor
QoE Monitor
Overlay Management
Inter-User communication
End User
Includes e.g. Adhoc Overlays
Figure 18: Domain view of the SmartenIT system Starting for the top domain, the Data center/Cloud Domain, we expect a placement of Overlay Management functionality that interacts with the existing DC/Cloud Management platform. In the case that several data centers want to form a Federated Cloud or that several Clouds want to interconnect, there must be a mechanism that makes this collaboration possible. For this purpose, we see that Overlay Management mechanisms should be in such a place that exposes the status and actions of data centers or Clouds PoPs, as peers in an overlay. Such information may include when a peer joins/leaves the overlay, the peers status (up, down, overloaded, etc.), the remote peers a peer is connected to, the services a peer offers (e.g., storage and computation, in case of an IaaS Federated Cloud), as well as any other information that describes the interactions of these peers with each other. Moving down to the Core & Access Network Domain, we place the following functional blocks: Cloud Traffic Management: We consider this as a central functional block of the S-BOX. The goal of Cloud traffic management is to reduce costs and to achieve an optimized performance of Cloud services. Therefore it needs to consider many aspects ranging from the choice for specific cloud providers in an inter-cloud scenario to the reduction of redundant traffic in the network itself using techniques such as multicast. It takes input from all the following functional blocks and it takes decisions on how to bias the Cloud traffic that travels through the public Internet. For this reason it needs to interact with the Overlay Management block, residing in the premises of data center/Cloud, in order to collect information about the formed overlay and, once decisions are taken, suggest actions that may be taken by the data center/Cloud (and its DC/Cloud Management platform) to optimize its
Page 35 of 78
Version 3.0

Public
performance. At the same time, the Cloud Traffic Management interacts with the underlying network. To achieve this, a two-way interface with the Network Traffic Management block is required (see below for more information). Note that the Cloud Traffic Management block materializes mechanisms that are social-aware and driven by incentives and other economic considerations. QoS/QoE Management: This block receives the information from network and end user devices with respect to the Quality of Service (QoS), and Quality of Experience (QoE), aggregates and normalizes it and makes it available to the traffic management mechanisms so as to be considered during the optimization process. Thereby it considers the anticipated levels of user acceptance, and also improvements when introducing a novel approach. Using the later described Quality Monitor, the estimation of latency and throughput can be done from the viewpoint of the end-user, e.g., by sending messages and using locally available information, e.g., RTT (Round Trip Time). Energy Analyzer: While energy efficiency is a key requirement in all three domains, the Energy Analyzer concentrates the available information to provide a basis for the overall traffic management. This block collects, aggregates, and normalizes information about the energy status and consumption of end user and network devices and feeds them to the traffic management mechanisms so as to be considered during the optimization process. Fixed/Mobile Network Traffic Management: The management of traffic by this functional block is an important concern especially for the core and access networks and, thereby, within ISP networks. Decisions on optimal traffic engineering, the avoidance of redundant traffic, and resilient transportation of traffic are key aspects. In this context, the concept of SDN provides a potential approach to design flexible and cost-efficient network and traffic management mechanisms. This block collects, aggregates, and normalizes information about the network status and topology and feeds this information to the Cloud Traffic Management so as to be considered during the optimization process. Moreover, it receives the suggestions by the Cloud Traffic Management and translates them to traffic management actions realized by the underlying network equipment (if accepted). Furthermore, caching is an important topic in the context of traffic management as it aims at efficient delivery of content. Caching concepts, for example, are applied in the case of traditional CDNs. However, the nature of content originated from the cloud may differ from other traffic, being more dynamic and complex. It is composed of various pieces of data, possibly residing in different data centers around the globe. Therefore, in the context of the SmartenIT approach, it will be investigated how such mechanisms could be applied to this kind of traffic. Similar to the management of the core and fixed access network traffic, mobile access networks impose specific requirements for traffic management for mobile and access network data delivery. As later on detailed in Section 5.5, other infrastructure elements, requirements, and limitations are to be considered in this case. It is to be seen how approaches from the core and access network and traffic management can be extended and integrated with those within this field. While SmartenIT aims at a converged Fixed/Mobile Network Traffic Management, in todays networks fixed and mobile traffic management remain still as largely
Page 36 of 78
Version 3.0

Public
separate functionalities. Therefore, in Section 5 below network traffic management and mobile traffic management are discussed in two separate subsections. Network Monitor: To take network and traffic management decisions, the monitoring of traffic is an essential prerequisite. An accurate assessment of the network condition and its available resources is important to identify the need for and potential of new management approaches. Therefore, it is important to consider this concern in designing the management solution for the SmartenIT approach. This block monitors the network equipment and measures specific metrics that will be useful to the other blocks, namely the QoS/QoE Management and the Network Traffic Management.
At the borders of the Core & Access Network and the End User Domains lies the Energy Monitor. The main reason for this is that energy should be measured at both the network devices (e.g., switchers, routers, etc.) and the end user devices (e.g., smart phones, notebooks, etc.). The Energy Monitor will measure the energy consumption and the energy status of each device, as well as provide early signals for critical conditions. The Energy Monitor provides input to the Energy Efficiency block of the upper domain. On the End User Domain, we find the following functionality present: QoE Monitor: Monitors the quality of experience end users perceive during (or after) the use of an application and reports it to the QoS/QoE Management. Social Monitor: This block will provide all the necessary information regarding the social activities of the end-users that may be useful during the optimization process. Overlay Management: At the end user domain, the Overlay Management targets at the coordination of overlay nodes running at client devices. This covers overlay nodes to, e.g., coordinate Ad-hoc communication between mobile devices but also includes nano data centers, other communication between clients as well as communication between datacenters or Cloud PoPs belonging to different owners but interconnecting with each other (see Federated Cloud and Inter-connected Clouds cases in Section 3.1), thus acting as peers of an overlay network. A desirable outcome of this concern, for example, is to align the flexible overlay topology with the underlying network infrastructure and to allow for incentivecompatible and energy-efficient communication. In Section 6 we elaborate a bit more on this and distinguish the different aspects of functionality to be offered.
What is left to be explained is the interS-Box communication displayed. We assume that the S-Box, even though logically one unit, will eventually be deployed in many ASes. Hence, a communication is required so as to orchestrate this distributed management platform. 4.2.2 Topological View Having provided an early insight on how the SmartenIT system would look like, we now come to present a more detailed view on the placement of the different functional blocks across the different domains involved (see Figure 19).
Version 3.0
Page 37 of 78

Public
Figure 19: Topological view of the SmartenIT system We consider two data centers (DC1 and DC2) that operate their own private (and small) networks. Note that the same applies for two inter-connected Clouds, but we use the Federated Cloud case for simplicity. We assume that for the operation of the data center, special software is required, namely the DC Management platform, and it is hosted on a (logical) machine called gateway (GW), also connecting the data center to the Internet. The existing platform provides VM Management and Load Balancing in the Data center/Cloud Domain as well as Traffic Redirection (in the Network Domain). A first observation is that the existing platform needs to be enhanced with an Overlay Management functional block that will expose the formation of a Federated Cloud to the SmartenIT system and allow the latter to interact with it. In the Core Network (ISP A and ISP B), we have network entities, i.e. routers, that need to be enhanced with extra software (either integrated or collocated with the routing hardware/software) in order to apply cross-domain traffic management policies. Alternatively, concept of the area of Software-defined Networking (SDN) and its flavor OpenFlow could be used here to avoid requiring such special router devices. Additional functionality could be placed at the network controller side. In Figure 19 we present a functionality stack that should be supported by the network management platform. Note that the ordering of blocks in the functionality stack has no meaning at this point. Moreover, even though all entities have the same functionality stack, it may be that not
Page 38 of 78
Version 3.0

Public
every network entity performs all operations. This will depend on the mechanism to be implemented and the different roles that a network entity may take depending on its location (e.g., edge router, core router, etc). In the Access Network (ISP C and Mobile Operator), we have again routers with slightly augmented functionality, that of QoE Management and Social Awareness. This is due to the fact that these entities are closer to the end users and are the first points in the entire networked environment were the collection of this information can happen. Finally, in the End User Domain we have some light functionality that mainly deals with the measurement of certain metrics (QoE-, energy-, social-related) from the end users devices, as well as an overlay management block that deals with the traffic related to adhoc communications. The above placement of functionality is also valid for the case of inter-connected Clouds. The only difference with the case of data centers is that a Cloud has more than one GW (i.e., more PoPs) residing in different network domains and, hence, the Cloud Management happens in a distributed manner.
Version 3.0
Page 39 of 78

Public
5 Initial Functionality Specification

Having identified the base functionality and conceptual architecture, this section provides a better insight on the functionality offered and the interactions required by each block to fulfill its purpose. This section doesnt provide any mechanisms as such, which is the task of WP2 (specifically deliverable D2.1). Rather, having described the objective of each functional block with possible interfaces in Section 4, this section describes the internals of each block. Moreover, it analyzes each functional block (and interface) and extracts more detailed requirements, in order to drive the design of the component architecture in Section 6. The aim of this analysis is to be roughly at the same level for all functional blocks. Therefore, lengthy descriptions of applications, scenarios, use cases, and mechanisms are avoided, as these are already provided in D1.1 and D2.1. Also, discussions of technologies are not included here as they are destined for T3.2 and D3.2.
5.1 Cloud Traffic Management

Cloud traffic management is one of the main key elements of SmartenIT architecture. In the actual architecture description its described as a black-box with multiple interfaces (either mono-directional or bidirectional) with all main relevant SmartenIT components. Cloud traffic management main purpose is to take decisions on traffic related to services offered by Cloud operator to its end-users. The decisions on traffic are taken by internal algorithms to provide an optimization on key SmartenIT areas: QoE as perceived by enduser and energy efficiency (access/core network side and end-user-side). In the following, a high-level interface specification for cloud traffic manager block is provided: Overlay Cloud Interface: This is a two way interface. Cloud Traffic management receives from Overlay cloud management information related to the formed Overlay network (List of Cloud operators who have joined the federation, offered services, resources available, Service level agreements, economic interactions between the clouds). On the other hand, Cloud traffic management functional block sends information related to local ISP network topology and resources. The communication between the two entities will be performed as a cross-layer communication implemented via Alto protocol. Network Traffic Management: This is a two way interface. Cloud traffic management functional block receives information about ISP local network (actual topology, used resources, link congestion and available bandwidth). The main output to network traffic manager is a set of rules, identified after internal calculation for the optimization of key aspects of SmartenIT (energy efficiency and QoE), to dictate to the lower network layers the way to redirect the traffic to properly reach the selected resources (contents to be delivered to end-user). QoS/QoE Analyzer: This is a one way interface. Cloud traffic management will receive QoS/QoE information and will use them to perform an optimized selection of resources on the cloud side (Cloud operator/DC PoP selection, Cloud operator service selection) and network side (links on ISP network to be used). QoS/QoE
Page 40 of 78
Version 3.0

Public
information should be assessed against SLA information (as gathered via Overlay cloud management interface) offered by Cloud providers. Social Monitor (End-user Domain): This is a one way interface. Social Information gathered at end-user can be used to build social graph of people sharing the same interests and likely to access the same contents. Cloud traffic manager can use social information to optimize the placing of user requested contents within the DC resources (i.e. the content management/placement strategy based on caching optimization) and achieving improvement in QoE by lowering the distance between the locations of user and requested content. The specific distance indicator to minimize could be the appropriate composition of geographical distance and hop count (generally impacting round-trip-time and consequently service performances), coupled with performance monitoring data (useful to identify congestion conditions on specific routes/interfaces). Energy Efficiency Module: This is a one way interface. Energy efficiency achievement is one of the main drivers for SmartenIT traffic management solution. Energy efficiency information must take into account the energy consumption experienced at end-user (e.g. related to mobile terminals) and energy consumption in datacenter and within the ISP core/access network devices (being the datacenter part the more relevant factor due to the higher power budget of the IT hardware, e.g. servers, storage).
5.2 Overlay Management: ALTO and CDNs

This section provides an insight of the overlay management functionalities identified in this preliminary SmartenIT architecture. Overlay networks and applications are by definition unaware of the topology and resources of their underlying network and are often its consumer. Consumer refers here to either user or costumer, as a network and one or more if its underlays may be owned by the same entity. Typically a content provider consumes resources and services from, e.g., a Cloud provider, Cloud providers consume resources from ISPs, and ISPs consume them from a physical network. The overlay addressed in section relates to the applications and the overlay network supporting them, that is a typical overlay network is a P2P network and a Cloud infrastructure. A crucial issue addressed by the SmartenIT architecture here is the need for overlays to include awareness of their underlying topology and related state. A number of functionalities described in Section 5.2 help providing applications with abstracted topology information. The following subsections identify SmartenIT functionalities inspired by such tools. 5.2.1 Inter-ALTO An ISP implementing the SmartenIT system can feed it with various types of data available in its domain (including traffic measurements, QoS/QoE monitoring, energy efficiency analyses, etc.) to perform traffic management algorithms. It can also communicate with SmartenIT system components implemented at nodes (servers, data centers, client equipment, etc.) owned by other cooperating stakeholders. However, locally available information may be insufficient for effective traffic management [19]. For that reason it is also assumed that SmartenIT systems administrated by different ISPs can cooperate. As the SmartenIT system itself may be based on the ALTO concept (and use ALTO protocol
Version 3.0
Page 41 of 78

Public
to communicate with client applications) the inter-ALTO protocol can be used for communication between remote trusted and collaborating SmartenIT system servers (see Figure 20). More information on motivation for using inter-ALTO concept and its relevance to SmartenIT are provided in Deliverable D2.1.
Figure 20: The inter ISP communication via inter-ALTO protocol For example, as presented on Figure 20, ISP-1 may cooperate with other stakeholders to efficiently manage the traffic as well as energy consumption, support QoS/QoE or use OSN information. Communication between SmartenIT system components and external systems components (i.e., SmartenIT component deployed in external system) can be performed using ALTO protocol. It is however limited to a local domain. Agreement between ISPs (e.g., ISP-1 and ISP-2) makes it possible to exchange additional information to enhance SmartenIT system efficiency (e.g., route asymmetry information, remote ISP preference, coordination of ISPs' policies, see [18] and [19]). Additionally, such a cooperation may be useful to indirectly influence overlay providers decisions. For example ISP-2 having an agreement with cloud provider 3 may take into account information provided by ISP-1, which collaborates with ISP-2 but does not have direct agreement with cloud provider 3. As a result, cloud provider 3 may change PoP offered to customers of ISP-1 so as they will download the content via ISP-1 ISP-2 inter-domain link instead of ISP-1 ISP-3 inter-domain link. Remote collaborating SmartenIT servers will communicate using inter-ALTO protocol. To make the communication possible each server must implement an interface supporting inter-ALTO protocol. SmartenIT server must have a software component responsible for inter-ALTO communication. This component needs an internal interface with the Traffic
Page 42 of 78
Version 3.0

Public
Manager component. The inter-ALTO protocol is currently not defined. SmartenIT is going to continue the work initiated in SmoothIT project and within IETF [18], [19]. In an ISP domain, metrics reflecting closeness and related to the network topology can be supported by an ALTO Server. ALTO may support abstracted network time delay in terms of estimation and possibly through the hop count metric but social metrics and real time measurements such as RTT are out of its scope. In this context, assistance to optimize the resources access can be provided via an ALTO Client embedded in an end user system and getting guidance from the ALTO Server in the SmartenIT box supervising the nano data centers. Resources covered by ALTO can be as diverse as depicted in Figure 21. At the home use case involving a SmartenIT box, the most relevant ALTO Service is the Endpoint Cost Service. Note that such a case stresses the need for ALTO insight below the IP hop level (as introduced in Section 3.2.2). Likewise cascaded ALTO Service would allow combining scalability and adapted information detailing.
Figure 21: ALTO guidance to improve access to resources of several types 5.2.2 Storage Management Overlay A Storage Management Overlay (SMO) is a network built on top of Cloud Storage Services (e.g., Google Picasa, Facebook, SoundCloud, ImageShack, Dropbox, Amazon EC2/S3, Apple iCloud, OwnCloud, or any Cloud Service that provides an API) in order to store, retrieve, and share files, either private (not sharing) or in a public fashion (sharing) and as such fits into the overlay management box illustrated in Figure 17. The SMO has the goal to add features and properties on top of the existing Storage Services and, therefore, provide an enhanced manner of storing data by managing how/where the content should be stored. It is also thinkable that a SMO can be used in a federated cloud scenario by providing flexible extension interfaces. Possible benefits of a SMO compared to a traditional cloud storage service include, for instance, an enhanced security scheme or policies to prioritize non-congested storage services data centers in a specific time frame. Moreover, a SMO can be used for traffic management by running network measurements and selecting the most suitable cloud storage provider for file up- or download based on the measurement results.
Version 3.0
Page 43 of 78

Public
Figure 22 shows three generic SMO Systems components: Cloud-access component, fragmentation component, and the traffic policy component. For the cloud-access component, SMO Systems users need to add Cloud Services credentials, e.g., Google Picasa, Facebook, SoundCloud, ImageShack, Dropbox, Amazon EC2/S3, Apple iCloud, OwnCloud, etc. Thus, the overlay holds the index information about files, e.g., in which Cloud Service the file was stored, if the data was encrypted, how the file was split into several small chunks, etc. Due to the fact that the fragmentation component may fragment files into several chunks (file parts), and store these file parts into different Cloud Services, it can influence the traffic being generated to and out of Clouds as well as transit domains using a traffic policy component. The traffic policy component may implement different scheduling strategies. These scheduling strategies can be based on, e.g., network information about Cloud Services, social behavior information, congested routes to Cloud Services data centers, etc. In order to enable optimized scheduling strategies within the traffic policy component, prioritizing certain factors (like less traffic, faster persistence, etc.), SMO Systems should take relevant input into consideration. These inputs can be acquired through the means of network monitoring (e.g., providing Round-Trip-Times), social network behavior (e.g., users that most share content to each other), data center locality (e.g., traceroute information), etc. Therefore, the SmartenIT component (Figure 22) provides the required information to SMO systems, thus influencing on how traffic is generated and distributed.
End Users Observe social behavior and interaction Users interacting with the overlay to store / share files
Storage Management Overlay System
SmartenIt
Well-defined interface to provide input to the overlay
Fragmentation Component
Cloud Access Component
Traffic Policy Component
Monitoring of Cloud Services and Datacenters Data traffic from the overlay to cloud services
Monitoring of Cloud Services and Datacenters
Data Centers
Cloud Service 1 ...
Data Centers
Cloud Service n
Figure 22: SmartenIT interfaces related to Traffic Management in Storage Management Overlay Systems
Page 44 of 78
Version 3.0

Public
5.2.3 Overlay Management for End User Deployed Software Software can be deployed on end user devices to enhance resources availability. This software can either be deployed by the end user, or by the ISP as in the nano data center approach [28]. Typically, the management of such devices is done in an overlay network, using distributed mechanisms. An overview is given here, where the architecture as a whole is treated in Section 6. A typical use case for resource availability enhancement is caching. Smart caches can exploit information on locality, closeness, and social behavior of network entities. Thus, the SmartenIT architecture needs to have interfaces to locality and social behavior information components. For SmartenIT, locality and closeness in a network are important and various approaches have been described. In SmartenIT, a service that provides a locality function for two IP addresses is used to determine how close two network entities are in terms of ASs. One example of such a service is the SmoothIT Information Service [58] which comes out of the SmoothIT project. Such a locality and closeness component should be extended in the SmartenIT architecture to allow for different kinds of architectural design. While the SmoothIT project proposed an ISP driven architecture, SmartenIT is more flexible and allows other kinds of closeness metrics, such as social metrics. In Figure 23, metrics of the locality and closeness component are provided either by the component itself or by the traffic monitoring or ALTO component. An important issue for enhancing resources availability is their identification. These resources can be identified by the social component. For other use-cases, a software deployment of other components is possible at a later stage. To exchange information about these metrics, an overlay will be formed where the network entities can coordinate. Either the overlay is formed by a central entity such as an ISP, Cloud, or third-party OTT provider, or it is formed in a decentralized manner.
Home Device SmartenIT Social Awareness Component
Content Identification
Closeness and Locality
Traffic Monitor
ALTO Other Service
Figure 23: Overview of interaction between end user systems and SmartenIT architecture
5.3 Network Traffic Management with SDN

As presented in Chapter 4, the network traffic management constitutes another key element of the SmartenIT approach. Just like cloud traffic management it was introduced
Version 3.0
Page 45 of 78

Public
as black box with several interfaces to other functional elements. Its high-level purpose is to coordinate the management of traffic in the core as well as the converged fixed/mobile access networks. By this, the element naturally resides in the area of responsibility of an ISP and has to interface with its network. On the one hand it uses an interface to the network monitor to retrieve network statistics; on the other hand it is able to provide a broader view on the network status by incorporating knowledge on the network topology and in place traffic engineering solutions. Besides, it is able to act as controlling entity that influences the forwarding and switching behavior of the network. For the latter, SDN-based approaches, along with traditional traffic engineering techniques can be applied. In the context of SDN, the application of the evolving standard of OpenFlow is promising and is going to be investigated for this element of the SmartenIT approach. It can be used to realize a virtual partition of physical resources [32] and, e.g., to perform selections of transmission paths, according to the cloud and overlay traffic management decisions, issued by the respective functional elements. Here, QoS or load-balancing aspects could become relevant from the network point of view that could be directly handled using OpenFlow [33], [34]. Furthermore, decisions on advanced content caching for cloud and overlay traffic could be taken within the network [36]. Here, the aim is to take consistent decisions for the core as well as the converged fixed/mobile access networks. Due to scalability considerations of an SDN-based traffic management solution, the offloading of data intensive traffic, as proposed in [35] has to be taken into account. Besides its implicit interface to the ISP network, the network traffic management element provides the following high-level interfaces to other elements of the SmartenIT approach: Network Monitor: This is a one-way interface to provide the traffic management mechanisms a better view on the network state. Therefore, the network Traffic Manager receives aggregated statistics of traffic flows from the Network Traffic Monitor. The statistics collected are primarily derived using state-of-the-art monitoring techniques based on SNMP data, BGP information, and Netflow statistics that are gathered from the networks lower layers. A potential extension could be the gathering of statistics directly using OpenFlow. Cloud Traffic Management: This is a two-way interface. The network traffic management takes inputs from the cloud traffic management element to execute cloud traffic optimization decisions, such as traffic redirects or altered routings, while respecting the ISPs authority for traffic engineering. In return, the network traffic management element provides the cloud traffic management with an aggregated view on the network status based on the data from the network monitoring element and its own view on the network status, such as the topology and possibilities to issue new optimizations. Overlay Management (at client-side): This is also a two-way interface that, firstly, allows the overlay management element to influence the network traffic management to optimize traffic to and from client-side overlay instances (e.g. from nano data centers) and traffic between clients. Secondly, it allows the network traffic management element to provide optimization suggestions to overlay instances, e.g. to switch to ad hoc communication with nearby client devices to improve the energy efficiency of the used service.
The SmartenIT project deals with various types of management issues: cloud traffic management, core network traffic management, overlay traffic management, mobile traffic management. The status of the network nodes, links and traffic statistics is required for
Page 46 of 78
Version 3.0

Public
different types of management. The SmartenIT mechanisms may require following information: traffic statistics from the inter-domain links (for: ALTO, inter-ALTO, management), global routing information offered by EBGP (for: ALTO, inter-ALTO, management), local routing and switching information OSPF, IS-IS, LDP, RSVP, MBGP, IBGP, MPLS(for management), traffic engineering information (for management) mobile devices localization (for: ALTO, inter-ALTO, mobile device traffic management), MPLS paths (for management) L3VPN, L2VPN, VPLS information (for management).
This data may be provided using monitoring techniques offered by standardized interfaces and protocols. It can happen that some specific SmartenIT management procedures may require working out original monitoring schemas and protocols. In order to obtain this information the SmartenIT software may need to access selected network nodes: routers and switches in a core network (route reflectors, PE- routers, traffic aggregating switches), routers and switches in data centers (located at the edge of data centers), routers located at the edge of operator networks (for inter domain traffic statistics collection), mobile backhaul nodes and nodes radio access network (MSC, GMSC, BSC, SGSN, GGSN, RNC, SGW, PGW, MME, eNodeB) charging nodes. (billing system nodes, PCRF)
The access to these nodes can be achieved by standard interfaces provided by network devices or some new interfaces offered by the SmartenIT software deployable on selected network devices or servers. 5.3.1 Network Load Balancing supported by ALTO in an SDN-Controller Load balancing can be improved by influencing the application traffic w.r.t. the network infrastructure conditions. Decision conflicts between the application and network layer are avoided by using a layer cooperative protocol such as ALTO. As the Network Traffic Manager (NTM) gathers information on link utilization patterns (LUP) and resources via the Network Monitoring interface, it can use it to achieve better load balancing by guiding the application traffic accordingly. One way to do it is to provide a set of time varying resources usage costs to applications able to schedule their traffic. For non real-time applications, data and resources transfer can be time shifted, resources availability may often be predicable and last, strong incentives for applications to time shift their traffic may be given by network operators appropriately setting routing cost values at different time values, according to their policy to cope with network occupation over time.
Version 3.0
Page 47 of 78

Public
To achieve this objective, the SDN Controller can include two dedicated components, as illustrated in Figure 24: 1. An LUP and network resources abstraction component in the NTM a. gets the network state history from the Network Monitoring through the SDN southbound API, b. derives an abstraction and an estimation of these value over given time frames, 2. an ALTO Server component a. stores this abstraction in the form for instance of an ALTO Cost Schedule, exposing values defined for different time periods b. provides these values to relevant SDN applications via the ALTO Endpoint Cost Service, either as history or prediction or both. This way, the SDN controller achieves load balancing as it may guide the application traffic so as to better distribute the traffic over time, and thus optimize its resources usage.
Figure 24: ALTO assistance to the SDN Controller to distribute traffic over time for load balancing An ALTO protocol extension to provide applications with time varying cost values has been proposed in [45]. A next step for SmartenIT is to specify the time varying LUP abstraction scheme for SmartenIT use cases.
5.4 Traffic Monitoring

This section details the traffic monitoring functionality and interfaces, starting from a high level description of the Network Monitoring functionality (Section 5.4.1); then, the different options and protocols for network monitoring are described (Section 5.4.2), and the specific interfaces detailed (Section 5.4.3). 5.4.1 Network Monitoring Functionality The Network Traffic Monitoring component is responsible for collecting the information about the status of network connections and a set of suitable parameters. This information is a crucial input to the Network Traffic Management. Accuracy and completeness of
Page 48 of 78
Version 3.0

Public
monitoring data contribute to the efficient traffic management conducted by the SmartenIT implementation. The component should be flexible and scalable. It means that deployment can be configured to run in various network environments (single-domain and multi-domain) with growing number of network devices and connections. In order to maintain the up-to-date view of network behavior, the monitoring data should be collected from network devices all the time (passive monitoring). Also an aggregation of long-term data specified by the SmartenIT administrator is important to give a useful tool for deep analysis. A set of collected network statistics cannot be fixed and limited by the implementation constraints. Selection of statistics depends on the traffic management needs and is to be configured by the SmartenIT administrator. Moreover, monitoring components are used at network boundaries in order to control service level agreements provided by network and service providers to other networks or customers. 5.4.2 Monitoring Systems and Key Performance Indicators The most common statistics are derived from Netflow and SNMP data. Netflow statistics are mainly based on network and transport layer information (IP addresses and TCP ports) while SNMP derived statistics are related to ingress and egress frames counted on physical ports. Traffic monitoring component should be provided with proper Netflow and SNMP interface to be able to interface with ISP monitoring points. The Network Traffic Monitoring component does not have to contain the complete implementation of monitoring functionalities. Instead, existing solutions like NSQM, perfSONAR [25] or storages of RRD files [26] can be used. Another monitoring option is to install clients of a monitoring system between two network elements in order to measure delay and loss via active probing. Based on that, the Perfas+ and Netprobe monitoring tools have been applied for support of performances measurement standardization at the IETF [57]. Monitoring systems are used to capture a set of key performance indicators (KPI) as a basis for traffic and QoS/QoE performance statistics, SLA and failure control, which include but are not limited to: One way, two way, round trip delay, Packet loss and errors, Data throughout, transmitted volume on links and paths, Connectivity, system availability, Thresholds evaluated from KPIs to trigger link upgrades, Metrics combined from several networked elements e.g. traffic matrices, Detailed statistics on IP packet and/or TCP/UDP flow level, QoE metrics on higher layer application level relevant for SLA or for detection of anomalies.
Monitoring is a precondition for failure discovery and handling as a basic network management task in operational networks. For support of trouble shooting, the component should offer active monitoring which is executing measurements with test traffic to simulate certain conditions and thus obtain detailed network information. This is usually done in case of observed network problems, strange behavior or random inspection. The Network
Version 3.0
Page 49 of 78

Public
Traffic Monitoring component should be enough flexible to formulate monitoring schedules relevant for the traffic management needs. 5.4.3 Interfaces between Network Monitoring Systems It is proposed to define an interface that allows the communication between the SmartenIT implementation and an external network monitoring system (cf. Figure 25). Such approach does not limit the component and it is possible to switch between external monitoring systems according to preferences, priorities, monitoring needs or other constraints. Another advantage is that Network Operation Centers (NOCs) maintain monitoring storages and a defined communication interface can be used to access their data.
Traffic Monitoring
Networks
External Traffic Monitoring System (e.g. NSQM)
Plugin Schedule Aggregation Analysis API Plugin
Monitoring data Storage (e.g. RRD files)
Figure 25: Communication interface between the Network Traffic Monitoring component and external monitoring systems The Traffic Monitoring component must interface with monitoring points/devices of ISP to derive information that can be passed to the following other SmartenIT components: Network Traffic management Quality of Service management Cloud Traffic management
The following three scenarios for SmartenIT monitoring component are proposed: Interface with Network Management System of ISP Monitoring distributed components that interface with all network devices of the ISP network, and Monitoring distributed components that interface with edge devices of the ISP network.
In the first scenario, the key assumption is that a close collaboration with ISP exists. The ISP provides an interface with his own Network Management system disclosing all information related to network load, network usage, peering and transit points (when applicable). That information is provided in the form of aggregate traffic statistics to the SmartenIT Traffic Monitoring component and are passed to the other relevant SmartenIT components.
Page 50 of 78
Version 3.0

Public
In the second scenario, the assumption is that collaboration with the ISP exists but the ISP does not provide any internal interface with his own Network Management system. In this scenario, SmartenIT Traffic Monitoring components are allowed to be installed in each network device of ISP core network and are in charge of realizing traffic monitoring statistics and patterns to be passed to other relevant SmartenIT components. The third and last scenario is the more restrictive as it pre-assumes no ISP collaboration. An ISP does not disclose any information of his core/internal network and allow SmartenIT components deployment only on the edge of the network (the gateways or CPE through which connectivity is provided to datacenters/users). This scenario seems the more realistic but led obviously to suboptimal measurements. For integration across layers and network boundaries, Figure 26 presents the communication of the Network Traffic Monitoring component with other SmartenIT components. The Network Traffic Management component provides all needed information to run the monitoring (e.g., network topology, description of nodes, list of requested metrics, needed aggregation, schedules, thresholds, etc.). Basing on the input from the Network Traffic Monitoring component the QoS/QoE Management component makes the relationship between QoS and QoE information.
Cloud/Overlay Traffic Management
QoS/QoE Management
Network Traffic Management
Network Traffic Monitoring
External Monitoring System
Figure 26: Communication of the Network Traffic Monitoring component
5.5 Mobile Traffic Management

The mobile traffic management is considered in scope of the SmartenIT project. We consider the following scenarios for mobile traffic management: 1. Cloud POP selection based on the relative localization of a mobile user and POPs. A mobile operator can access some given content via a few cloud POPs. The relative localization of an end user and a POP in the network may be important for mobile operator, as that may influence mobile core network load, QoS/QoE,
Version 3.0
Page 51 of 78

Public
operator and user costs. A mobile operator can deliver some localization information to the SmartenIT System which analyze some important factors for traffic management and can request cloud management software to deliver content from the suggested POP. In such a case, the Cloud may be obliged to migrate content and a virtual machine from one data center to another serving specific POP indicated by SmartenIT System. 2. Lightweight communication between user devices (equipped with wireless interfaces) for transfer increase to and from Internet. The diversity of devices possessed by a user is increasing since the advent of modern mobile communication hardware like smartphones. Multiple access to services from an increasing number of platforms is becoming an everyday scenario, i.e., a user is represented by the several devices he or she possesses. As a consequence, a users available resources (bandwidth, computing power, storage) are spread over a multitude of devices. In order to provide a unified view on a users available resources as well as to represent the user in a unified way towards third parties, a lightweight communication service overlay could be integrated in the SmartenIT architecture, which allows the several devices of a user to communicate with each other (see Figure 27). Such a service is relevant to both, mobile traffic management and overlay management, e.g., with respect to caching and the participation in P2P content distribution [27]. A users mobile device could fetch content cached on a users PC or a user could incorporate his resources in systems relying on the active contribution of resources. It is conceivable to have the smartphone downloading from a BitTorrent swarm, while the users router performs the upload to the network. The concept can be seen as an extension to the Nano Data Center approach presented in [28], where any device of a user can be part of the Nano Data Center. Moreover, such an approach complements the idea of utilizing social data, as it allows to easily match a users resources to a node in a social graph.
Figure 27: Home set system general view 3. Offloading between LTE, other cellular mobile networks and WiFi. When overload is observed in a cell of a mobile network, part of which is also cover by WiFi networks then WiFi offloading is an option for load balancing. In situations where the same network provider is operating overlapping 2G, 3G and 4G cellular as well as WiFi networks, all of those networks can be included as parts in a common load balancing regime, where restrictions of the UEs to one or another of those technologies have to be considered as boundary conditions.
Page 52 of 78
Version 3.0

Public
In a case of the first scenario we are going to use information provided by mobile network nodes. Basically, we focus on the localization of a mobile user versus a Cloud, server or peers in overlay network. The SmartenIT System (cf. Figure 35) gathers information from mobile core network nodes. These nodes are represented as a Network Entity component on the component diagram. The SmartenIT System accesses Network Entities via standard interfaces offered by nodes. After the SmartenIT software deployment, Network Entities can communicate with the SmartenIT System via internally defined interfaces. The central component for the Mobile Traffic Management is the Traffic Analyzer. This component interworks with the Traffic Monitor component, Traffic Manager and QoS/QoE Analyzer in order to work out management decision for traffic sourced by clouds, overlays and single users in a mobile network. In the third case, the basic issue is a design for a communication procedure between user devices composing the home set. The capabilities of a mobile phone have to be discovered. If a mobile phone possesses a WLAN interface, the management procedures may be carried out internally in the home user network. The communication protocol has to be defined. Also, a device discovery and registration procedure is needed. During device discovery procedures their capabilities will be established. Device capabilities will influence on the choice of management procedures. Also procedures which prevent foreign devices from participating in home set should be implemented.
5.6 Quality Management: QoS and QoE

Quality Management functionality is a key functionality in SmartenIT project. The QoS/QoE management may be based on the information gathered from network nodes closest to the end user or straight from user equipment. Also useful information for the service quality management can be delivered by other network nodes and entities being sources of data transferred to end users. In the SmartenIT project quality management is considered in context of the cloud, overlay and mobile application traffic management. The different approaches for the QoS and QoE measurement and management use different algorithms. The measurement of quality can be provided in the following way: MOS techniques, QoS to QoE mapping (user agnostic measurement), end to end service performance measurement (active measurement).
The quality management procedures can be designed to use a mix of the above described techniques. The QoS/QoE Analyzer component (cf. Figure 35) use one or a few algorithms which are chosen during the initiation of the connection between an end user application and a communicated party application. The party application may reside on servers in clouds, peers in the overlay or on stand-alone servers. The algorithm is chosen according to the Traffic Manager or the end user application requirements and availability of the SmartenIT software on the devices. The algorithms use information obtained from the Traffic Monitor component. The Traffic Monitor plays the role of proxy between different devices and the QoS/QoE Analyzer using the dedicated algorithm. It performs data adaptation procedures.
Version 3.0
Page 53 of 78

Public
Relying on the information from the Traffic Monitor, QoS/QoE algorithms produce data which is used by the Traffic Manager component. The QoS/QoE management strategy is decided by the Traffic Manager component prior to the algorithm selection, the chosen strategy have the influence on the algorithms selection. 5.6.1 QoS/QoE Cloud Management All mentioned measurement techniques can be used for the QoS/QoE Cloud Management. These techniques are represented by different algorithms. The QoS/QoE Analyzer component receives input from the Traffic Monitor component (statistics on traffic) and provides an input to Cloud Traffic Manager subcomponent which is in charge of dictate polices to the Network Traffic Manager subcomponent to adapt the network behavior to the desired QoE, Figure 28. The QoS/QoE Analyzer component basically uses two its subcomponents, prepares data for the Cloud Traffic Manager exploiting a few algorithms offered by the Algorithm Repository subcomponent. The functionality is composed by the QoS/QoE Calculator subcomponent. This can be thought as a short term calculation of Quality that will provide fast calculation to directly drive the SmartenIT Cloud Traffic Manager component (fast reaction to changes). MOS techniques and end to end measurements on the other hand can be seen as a long term calculation to provide continuous refinement and more realistic models for QoS to QoE mapping.
Server Client Network Entity
Traffic Monitor
QoS/QoE Analyzer
Traffic Manager
Algorithm Repository QoS/QoE Calculator
Cloud Traffic Manager Network Traffic Manager
Figure 28: Component and subcomponents involved in QoS/QoE Cloud management 5.6.2 QoS/QoE Overlay Management In scope of SmartenIT project, the Quality Overlay Management mechanism is based on the information obtained from the end user devices where the QoE device monitoring tool is deployed. In general many other techniques can be used for monitoring QoE, also
Page 54 of 78
Version 3.0

Public
passive monitoring approach may be considered. Our analysis is based on the VITALU software (ALBLF software) because the features of this tool are well known to the project partner who is interested in this subject and uses it as reference solution. The information from the QoE device monitoring tool is passed to the QoS/QoE Analyzer component where indications for management decisions are worked out by the QoS/QoE Calculator subcomponent, as depicted in Figure 29. Having obtained indications the Overlay Manager subcomponent sends management directives to peers participating in the overlay network. The SmartenIT architecture may be equipped with following components, subcomponents and specialized functions to provide the QoS/QoE overlay management: QoE Device Monitoring tool (for example the VITALU tool) o Home tool to assess the quality of experience for video based on QoS and video metrics. This tool is compatible with todays major video transmission protocols (HLS, HTTP Progressive Download, RTP, etc.). This component should be deployed on the user site. o Indicators provided by the QoE device monitoring tool include but are not limited to: Protocols used in the video or multimedia transmission, QoS metrics (end delay, jitter, lost packet rate, throughput), Video metrics (frozen frame rate, erroneous frame rate, buffer filling, VQM score), Audio metric (E-model score), and QoE metrics: display jitter, freezes, impaired frames, MOS-like score.
Subcomponents for the QoS/QoE Analyzer: o Algorithms to estimate QoS and QoE metrics o QoS/QoE calculator : gathering the QoE information from the QoE device monitoring tools deployed on user devices, analyzing traffic QoE, and reporting to Overlay management entity
The overall QoE of a multimedia playout through the network depends on three major factors: Encoding, Transmission and Playout. It is expected that a QoE monitoring tool (within the SmartenIT system?) deployed in the user device, will evaluate the impact of each of these processes on the quality: Encoding should be employed so as to adapt video bit-rate to the target resolution of the video, Transmission can induce delays and packet losses that may result in impairments, Playout involves at least a player buffer, which can create freezes if badly configured, and decoding using error concealment.
By capturing and analyzing packets at network-level, a QoE monitoring tool simulates the behavior of the player and provides metrics corresponding to each of these factors. A MOS-like overall estimator is then calculated from these metrics. Extra information such as GPS and radio power level (on mobile devices) can also be used to provide indicators of quality depending on the user location. This information is to
Version 3.0
Page 55 of 78

Public
be transferred by a QoE monitoring tool in a mobile device to the Traffic Monitor component located in the SmartenIT system. For Video traffic, other specific metrics can be provided, such as start delay, freeze statistics, impaired frames, and buffer filling level. As the QoE also depends on the target player device, this kind of information can either be retrieved automatically or entered as a parameter to the QoS/QoE calculator subcomponent. A video-decoding module can also be provided that will transfer frame samples and other related information (for example motion vector activity) to other components. This can be useful for an independent QoE model implementation.
Server QoE Monitor Client QoE Monitor
Traffic Monitor
QoS/QoE Analyzer Traffic Manager Algorithm Repository QoS/QoE Calculator
Overlay Traffic Manager
Figure 29: Components and subcomponents involved in QoS/QoE overlay management
5.7 Economic Considerations and Incentives

As mentioned in Section 4.1, SmartenIT is based on the ETM principle. As a consequence, economic considerations and stakeholder incentives are an integral part of the SmartenIT architecture. In the following sections the interaction of SmartenIT with external charging components as well as monetary and non-monetary incentives for traffic management are discussed. 5.7.1 SmartenIT and External Charging Components The SmartenIT architecture is not concerned with the design of billing systems for cloudrelated services itself. However, within the scope of the economic and incentive box illustrated in Figure 17, billing and charging are still relevant for the SmartenIT architecture because end-users may well use cloud services provided by one or more external cloud service providers indirectly through SmartenIT. Hence, the SmartenIT system must be capable of interacting in a generic way with the billing systems provided by cloud service providers.
Page 56 of 78
Version 3.0

Public
The interaction of SmartenIT with a cloud service provider as well as its service and billing component are depicted in Figure 30. The interaction is based on the OAuth authorization framework, specified in [29] and [30] and described subsequently. Before SmartenIT can access a service provided by a cloud service provider, it must submit an authorization request. If the authorization request is successful, the cloud service provider will reply with an access token. This access token allows SmartenIT to access the cloud service and the billing component. While the access token is sufficient to access the cloud service, a request to the billing component must be enriched with request properties describing the information the cloud service provider's billing component is supposed to reply with. For instance, SmartenIT might specify in the request that it wants to obtain information about the running costs of the cloud storage it is currently using and would therefore enrich the access token with service type = storage and billing period = March 2013. The cloud service provider's billing component would then reply with a billing reply message containing the amount of storage currently consumed along with the amount due as well as an indication detailing whether the amount has been paid or not.
Cloud Service Provider
Access Token Authorization Request SmartenIT Access Token Cloud Service
Authorization Server
Cloud Service
Access Token
Billing Reply
Billing Component
Figure 30: SmartenIT Interaction with Cloud Service Billing Component 5.7.2 Charging Incentives for Traffic Management The cost of the traffic transfer through inter-domain links is one of the driving incentives for traffic management performed by operators. Operators want to decrease expenses generated by inter-domain data transfer. This can be achieved in various ways, managing traffic on the application layer or on the network layer. The overlay management is related to the application layer management. In case of SmartenIT, the information about transferred traffic volume is crucial for transfer cost estimation. According to the present transfer volume and historical data from the previous payment periods, the prediction for the transfer costs can be estimated. The Traffic Monitor component has to access edge network nodes with links to the neighboring operators networks (i.e., ASes). Using standard technologies like NetFlow the desired information can be extracted from the network nodes. Communication with the remote AS (where the source of data is located) is required for precise identification of inter-domain links used for transferring selected downstream traffic. The wide range of data can be obtained from ALTO servers in remote ASes via inter-ALTO protocol or more limited information from Glass Looking Servers. The other information related to charging rules applied by an operator can be provisioned by a billing system. We assume that whole management infrastructure offered by the
Version 3.0
Page 57 of 78

Public
SmartenIT project is under complete operator control. The operator decides which and when specific charging information can be used for its own use in the scope of SmartenIT management procedures. 5.7.3 Flexible Non-monetary Incentives for Traffic Management Any network relying on its users nodes to help in providing the overall service needs an incentive for the user to contribute his or her resources to the network. Nodes can be seen as rational, i.e., selfish actors in such networks. As described in Figure 18, the incentives are materialized in the mechanisms implemented within the scope of this project. However, in the case of non-monetary incentives, e.g., incentives that can be created via an adaptation of the QoS/QoE experienced by the respective parties, the incentive scheme can be materialized as a component running on all of the devices involved. A number of applicable incentive schemes were presented in D2.1. The incentive component of the SmartenIT architecture can be imagined to serve as a flexible instance of such an incentive scheme on end-user and cloud hosts.Within the scope of SmartenIT, the component providing non-monetary incentives will support virtual nodes in order to better represent a users devices and to allow incentive-compatible support from cloud instances. For this purpose, the incentive component takes social information into account as a source of mutual trust, influencing the decisions of the cloud traffic management and fixed/mobile traffic management. The described incentive mechanisms are materialized in Figure 35 in the Economic Analyzer Box as well as in the various traffic Management components. Ideally, they span the cloud domain and the end-user domain. As an example, the distribution of bulky content via some P2P content distribution scheme can be imagined, where a user can organize his devices as one virtual node of a reciprocal incentive scheme. In this virtual node, cloud instances or friends can help with reciprocation in order to satisfy a users downlink or to support a users mobile devices (see Figure 31).
Figure 31: The home set protocol allows a user to unify his or her devices under one virtual node
5.8 Energy Consumption Monitoring

Nowadays, energy efficiency is an important topic for the IT community and many related robust solutions have been created. For example, Data Center Infrastructure Management
Page 58 of 78
Version 3.0

Public
(DCIM) tools offer energy monitoring and data center performance management capabilities [31]. They can reduce cost, support advanced analysis and improve overall efficiency. As the SmartenIT approach is modular, existing energy monitoring components can be included. For the optimization of the networks, all network entities should provide current energy statistics the Energy Efficiency Analyzer within the current network domain. This is important, as major routing or caching decisions may depend on the current power usage, or in the case of mobile device the remaining battery capacity, and such, the expected remaining life time of the mobile client. The client side of the necessary components is depicted in Figure 32, which implements the Energy Monitor. This component should be run on as many components of the network as possible to gain a complete overview of the network within the Energy Efficiency Analyzer.
Figure 32: Energy monitoring component on the network device There are several ways to measure the energy consumption of network entities. On the one hand, there are precise methods based on using dedicated measurement hardware, which have the disadvantage of making the measurements inflexible. On the other hand, many operating systems provide a very rough estimate of the current energy consumption, which might suffice in very rare cases only. Model-based approaches are situated somewhere between the two mentioned extreme cases. Therefore, a model taking certain parameters provided by the OS as an input is generated by correlating the input parameters and the actual energy consumption. The resulting mathematical model is implemented in software and can send an estimate of the current energy consumption to a measurement component within the SmartenIT architecture. This is detailed in Section 3.3 of Deliverable D2.1. The data provided by the network entities is then collected and aggregated on the Energy Consumption Monitoring component, which is responsible for collecting and managing the information about the energy consumption of network devices. Those devices are the members of network topology that is analyzed in the process of network traffic management. Collected data are used by the optimization mechanisms that will be proposed and investigated by the SmartenIT project. The component acts in a similar way to the Network Traffic Monitoring component. The energy statistics offered by network devices are fetched, stored, transformed (e.g., aggregated) in a single (single-domain use case) or multiple locations (multi-domain use case) as depicted in Figure 33. If a network domain does not want to share raw data some transformation should be allowed.
Version 3.0
Page 59 of 78

Public
Domain A
Domain B
Domain C
Energy Consumption Monitoring
Network Infrastructure
Figure 33: Energy consumption monitoring in the multi-domain use case Network domains, data centers, or cloud providers may have some specific energy-based policy constraints. This has to be included by the SmartenIT traffic management and thus the Energy Consumption Monitoring component could be aware of it. Such information is handled within the Cloud Traffic Management component, and hence, reflected in the network control messages. Knowing the current energy consumption and the remaining power on mobile devices, i.e., having full view of the network, the Cloud/Network Traffic Management component can decide on the best possible approach to route traffic through the network and trigger caching of content at the appropriate points.
5.9 Social Awareness

This section proposes three modules to realize social aware traffic management in OSNs. In particular, users cost for an OSN shall be contrasted to their worth in order to allocate resources on a per user basis in a fair manner in case of a resource shortage. Therefore, one of the proposed modules the Social Monitoring component - receives resource consumption figures of users and calculates the cost of every user. The second module the Social Analysis component calculates contribution metrics of a user for the OSN. Since the contribution of a user for an OSN may be described as the interest that other users have in the content that is provided by the user, i.e., photos, videos, etc., this component receives numbers about how often content of users is accessed by other users. Since both of these components classify users based on resource usage measurements but do not specify how this information shall be reallocated in case of a resource shortage, the third component the Resource Reallocation component - receives the output of the two other components and determines how resources shall be reallocated if necessary. The individual modules are subsequently discussed in detail and their interdependencies illustrated in Figure 34. In this figure, the blue boxes show the input parameters while the modules are represented by red boxes. The output is shown as a green box.
Page 60 of 78
Version 3.0

Public
Resources available
per resource
consumed
per user per resource
Content Access
shared own
Social Monitoring
Social Analysis
Resource Allocation
received
per user per resource
Figure 34: Architecture to implement social awareness in OSNs The Social Monitoring component monitors resources and determines social metrics such as the heaviness of users or friend connectivity. In particular, the problem is that OSNs offer many different resources to users, such as receiving content from different OSN servers (receiving content from a close server causes less cost than receiving content from a remote server, wherefore distinction is necessary) video chat services, online gaming, etc. As different resources are not directly comparable, this component produces a consumption profile of each user, i.e., how much each user consumes of each resource, and how much of every resource is available (consuming a scarce resource costs the OSN more, than consuming a resource that is abundant/not requested by many users). This consumption profile is forwarded to the resource reallocation component. The Social Analysis component analyzes the user behavior with respect to specific content and calculates user contribution metrics such as a users value which may be described as the interest that other users have in the content that is provided by that user. In order to accomplish its task, it needs to receive data about how often content is accessed. Furthermore, the module needs to receive input via which link content is accessed, wherefore underlay information needs to be accessed. For example, user A may upload content which is accessed himself, that is accessed, but can also share content of another user B, that is accessed. When the shared content is accessed, this increases Bs contribution. However, this content was accessed because A shared it, wherefore also As contribution must increase as well. To take this important factor of content distribution/sharing into account, that is central to OSNs, the module also must receive information of why, i.e., via which link, content was accessed. Just as the social monitoring component, the module produces a contribution profile and forwards it to the reallocation component. The information received by the social analysis component, may also be used to predict user behavior and pro-actively allocate resources.
Version 3.0
Page 61 of 78

Public
The Resource Reallocation component calculates how scarce resources have to be reallocated on a peer user basis. Therefore it needs to receive how much of the different resources users consume and how much is available of each, which is the same input as the first module receives. Since the prioritization shall happen in a social aware manner, the module must take the consumption and contribution profile of users into account and therefore additionally needs to receive the output of the other two modules as input. The module then outputs how the resources that users receive should be reallocated, such that (i) the overall consumption does not exceed the supply (only scare resources are reallocated), (ii) while users are as little affected a possible, ensuring (iii) that users whose consumption and contribution metrics are in a bad ratio are affected more than moderate users, i.e., a resource decrease is fair/social aware. This resource reallocation may happen in pro-active manner, e.g., in case of flash crowds due to newly available popular content, or in a periodic manner, to ensure an efficient overall allocation.
Page 62 of 78
Version 3.0

Public
6 Derived Initial System Architecture

Based on the analysis of the previous section, as well as the conceptual architecture provided in Section 4, a first attempt to design the initial SmartenIT system architecture is made here. The objective of this section is to consolidate the functionality analyzed in Section 5 and to provide an initial integrated view of the system architecture. The system described below, covers the requirements imposed by all scenarios described in deliverable D1.1. Note however that the derived system architecture is based mostly on assumptions made in Section 3.1 and intuition, since concrete requirements and mechanisms are to be provided by WP1 and WP2 in the next phases of the project. Once this is done, the architecture will be also updated and reach its final state.
Datacenter/Cloud Entity (PoP)
Datacenter/Cloud Manager Traffic Redirector Workflow Manager Load Balancer
Billing/ Accounting
Cloud Overlay Manager
Inter DC/Cloud communication
Hypervisor
E.g. ALTO
ISP
Billing/ Accounting Economics Analyzer
S-Box
Traffic Manager
Cloud Traffic Manager
Inter-S-Box communication E.g. inter-ALTO
Social Analyzer
Fixed/Mobile Network Traffic Manager
Social Monitor
Overlay Social Network
QoS/QoE Analyzer
Network Analyzer
Energy Analyzer
E.g. ALTO Includes e.g. Adhoc Overlays
Device Overlay Manager
QoE Monitor
QoS Monitor
Energy Monitor
End User Device

Energy Monitor Network Monitor
Network Entity
Network Monitor Switching/ Forwarding
E.g. SNMP, BGP, Netflow
E.g. OpenFlow
Figure 35: The initial SmartenIT system architecture
Version 3.0
Page 63 of 78

Public
In Figure 35 we provide a first integrated view of the system architecture, including all the components that could be in place, depending on the specific mechanisms to be implemented. The grey boxes denote the different entities, namely the Data center/Cloud entity, the S-Box, the End User Device, the Network Entity, the Overlay Social Network and the ISPs Billing System. In fact, the ISP has under its ownership both network entities and billing system. But for clarity reasons we distinguish them in the diagram above. Inside the entities we present the components and their interfaces. The colors in the figure relate to the colors used in Section 4. Additionally, a white-colored component denotes an existing (outside of our system) component; its presence will help at a later point to identify and define the exact interfaces to external systems to be used. Data center/Cloud Entity: The Data center/Cloud Entity is assumed to consist of two existing components, namely the Data center/Cloud Manager and the Billing/Accounting components. Here, we introduce an entity named Cloud Overlay Manager that encompasses some of the functionality of Overlay Management, already described in Section 4.2 and Section 5.2. This functionality relates to the overlays formed in the data center/cloud layer (as opposed to the overlays formed in the end user layer, to be mentioned later). The Cloud Overlay Manager uses any offered interfaces from the DC/Cloud Manager to extract information useful to the S-Box, or decisions taken by the SBox that should be suggested to the DC/Cloud Manager. The Cloud Overlay Manager also provides an interface to enable the inter-data center or inter-Cloud communication allowing the dissemination of SmartenIT-related information. S-Box: The S-Box can be considered as the core of the SmartenIT system. As already mentioned, the S-Box is only logically considered as one entity. At the center of the S-Box, there is the Traffic Manager, a newly introduced component that actually encompasses all the decision-taking functionality. Hence, the Traffic Manager is the umbrella for the Cloud Traffic Manager and Fixed/Mobile Network Traffic Manager components. Their functionality is briefly discussed in Section 4.2 and examples of more detailed functionality and interfaces are provided in Section 5.1, Section 5.3 and Section 5.5 respectively. The Traffic Manager provides a number of interfaces: i) an interface towards the Cloud Overlay Manager, which can follow or adopt the ALTO approach, ii) an interface towards remote S-Boxes, to enable the interoperability between different S-Boxes; for this interface, proposals such as the inter-ALTO approach or the SDN east-west interface can be adopted, iii) interfaces towards the Economics and Social Analyzers to capture the socioeconomic related aspects during the decision-taking process, iv) interfaces towards the QoS/QoE, Network and Energy Analyzers so as to consider all the parameters required in the decision-taking process and v) an interface towards the Device Overlay Manager, which can also follow or adopt the ALTO approach (see later for more details). Finally, the Traffic Manager will use the interface provided by the Network Entity so that the decisions taken will be materialized at the network layer. Through this interface, the decisions taken by the Traffic Manager will be translated to lower-level commands so as to be handled by the network layer. The level of interactions between the Traffic Manager and the Network Entity differ, based on type of the network entity (router, switch, mobile nodes such as GGSN (Gateway GPRS Support Node), SGSN (Serving GPRS Support
Page 64 of 78
Version 3.0

Public
Node), etc.). In the diagram we show only a typical type of interaction that follows the SDN approach (as discussed in Section 3.2.1 and Section 5.3), where the Traffic Manager (acting as the Controller, using the SDN terminology) instructs the switching/forwarding component of a router to follow a specific routing rule for certain type of network traffic. Note that the internals of the Traffic Manager are not further discussed, since they depend on the actual mechanisms to be implemented. For sure, there will be more than one interface between the Cloud Traffic Manager and the Network Traffic Manager, but the exact type of interactions is not yet identified. The Economics Analyzer interacts with the Billing/Accounting System of the ISP and the Cloud, in order to attain certain economic parameters that will be considered during the decision-taking process. Such examples are given in Section 5.7.1. The Social Analyzer will acquire social information from overlay social networks that might be useful in predicting the traffic or the impact of traffic management policies. An example of such an interaction is provided in Section 5.9. Both components interact with the Traffic Manager to provide the socio-economic aspects to be considered during the decision-taking process. The QoS/QoE Analyzer offers an interface to collect QoE-based measurements from end users and QoS metrics from network entities, so as to enhance the decision-taking process (through the interface with the Traffic Manager) with QoS/QoE optimization goals. To further enhance this, an interface with Network Analyzer is expected. A detailed description of possible interactions and functionality of the QoS/QoE Analyzer is provided in Section 5.6. The Network Analyzer primarily collects network-related information from network entities along the content/service delivery path. It may also collect such information from end user devices. More details are provided in Section 5.4. Network-related information does not refer only to network traffic and its characteristics. Depending on the context, it may also include information about location (from GPS-enabled devices) or estimated location (from mobile network entities), see Section 5.5. All this information is processed and passed to the Traffic Manager, while a subset is also provided to the QoS/QoE Analyzer. The Energy Analyzer offers an interface for devices (either end user devices or network entities) to provide information about their energy status so as to be able to consider energy efficiency in the decisions taken (through the interface with the Traffic Manager). More details are provided in Section 5.8. End User Device: Moving to the End User Device, there is the Device Overlay Manager that allows the creation and management of, e.g., ad hoc networks or any other forms of collaboration between devices. This component may possibly interact with the Traffic Manager to allow for further optimization of the overlay formation and operation. More details are provided in Section 5.2.1. The QoE Monitor can be considered as an application-level component since it allows capturing the quality of the users experience and providing such information to the S-Box (through the appropriate interface). In the same sense, the Energy Monitor is a lower-level component that monitors that energy consumption and provides the necessary information to the S-Box. Finally, the Network Monitor, as already mentioned, provides traffic-related (status of link, available bandwidth, etc.) and device-related (location, etc.) information. Network Entity: Last, but not least, at the Network Entity, we find almost the same components with the ones at the End User Device. The QoS Monitor provides information about the quality of service provided by the adjacent links, the Energy Monitor provides information about the energy status of the entity, as long as it can be biased, and the
Version 3.0
Page 65 of 78

Public
Network Monitor provides network-related information. If the context is fixed networks, this information can be provided through standard interfaces, such as SNMP, BGP, Netflow, etc. More information is provided in Section 5.4. Finally, there exists a Switching/Forwarding component which receives commands from the S-Box through the appropriate interface. OpenFlow can be such an interface. In cases of other entities than routers, such a component may not exist, but other will take its place. In case of typical mobile network nodes, the information about mobile user localization in the radio access network can be provided. Also information about traffic load in a cell can be gathered.
Page 66 of 78
Version 3.0

Public
7 Summary and Conclusions

The aim of this deliverable was to derive the initial SmartenIT system architecture, taking into account the requirements from WP1 as well as the initial work conducted in WP2. First, Section 3 outlined the problem, analyzed related approaches, and discussed their relevance to SmartenIT. To summarize the findings, Table 1 provided a mapping of the presented approaches to the key SmartenIT goals and applicable scenarios. SDN, ALTO, Cloudlets, NaDA, SmoothIT, ABNO and ETICS relate to some of the SmartenIT key goals and contexts whereas FI-WARE, OpenNebula and Openstack are generic implementation frameworks for future Internet or cloud infrastructure functionalities. Based on the problem description and discussion of related approaches in Section 3, Section 4 provided and discussed the base functionality and the corresponding conceptual architecture for the SmartenIT approach. All functionality spans one or multiple domains out of the data center / Cloud domain, the core and access network domain, and the end user domain. Moreover, it addresses one or more of the three main SmartenIT objectives, relevant in all three domains. Those objectives include social awareness, energy efficiency, and incentives and economic considerations. Section 4 also provided the conceptual architecture with its functional blocks, their interdependencies, and their placement. In summary, with this conceptual architecture, all four scenarios of SmartenIT are addressed. As example, in some cases, we focus on the inter-cloud scenario. Nevertheless, the architecture is more general and intentionally not limiting to this special case. Furthermore, Section 5 provided the initial specifications of the SmartenIT functionality and their interactions. The main purpose of Cloud Traffic Management is to take decisions on traffic related to services offered by Cloud operator to its end-users. Those decisions are taken by internal algorithms to provide an optimization on key SmartenIT areas: QoE as perceived by end-user and energy efficiency. Moreover, Overlay Management relates to the applications and the overlay network supporting them. Overlay networks and applications are by definition unaware of the topology and resources of their underlying network and are often its consumer. A crucial issue addressed by the SmartenIT architecture here is the need for overlays to include awareness of their underlying topology and related state. Therefore, one concept considered in more detail is the ALTO concept and the inter-ALTO protocol that can be used for communication between remote trusted and collaborating SmartenIT system servers. Furthermore, Network Traffic Management constitutes another key element of the SmartenIT approach. Its high-level purpose is to coordinate the management of traffic in the core as well as the converged fixed/mobile access networks. In the context of SDN-based approaches, the application of the evolving standard of OpenFlow is promising and is going to be investigated for this element of the SmartenIT approach. Additionally, Traffic Monitoring is responsible for collecting the information about the status of network connections and a set of suitable parameters. This information is a crucial input to the Network Traffic Management. Accuracy and completeness of monitoring data contribute to the efficient traffic management conducted by the SmartenIT implementation. Moreover, Mobile Traffic Management is considered in scope of the SmartenIT project. Several mobile traffic management scenarios have been considered, including cloud POP selection based on the relative localization of a mobile user and POPs, lightweight communication between user devices for transfer increase to and from Internet, and offloading between LTE, other cellular mobile networks, and WiFi. In addition, Quality Management is a key functionality in the SmartenIT project. Quality
Version 3.0
Page 67 of 78

Public
management is considered in context of the cloud, overlay and mobile application traffic management. Different approaches for QoS and QoE measurement and management using different algorithms have been addressed. Furthermore, as mentioned in Section 4.1, SmartenIT is based on the ETM principle. As a consequence, Economic Considerations and Incentives are an integral part of the SmartenIT architecture. In this context, the interaction of SmartenIT with external charging components as well as monetary and non-monetary incentives for traffic management have been discussed. Additionally, energy efficiency is a key aspect tackled within SmartenIT as it is an important topic for the IT community and many related robust solutions have been created. Thus, Energy Consumption Monitoring can reduce cost, support advanced analysis and improve overall efficiency. As the SmartenIT approach is modular, existing energy monitoring components can be included. Finally, Social Awareness realizes social aware traffic management in OSNs. In particular, it contrasts users cost for an OSN to their worth in order to allocate resources on a per user basis in a fair manner in case of a resource shortage. Finally, Section 6 made a first attempt to design the SmartenIT system architecture. The objective here was to consolidate the analyzed functionality and to provide an initial integrated view of the system architecture. The resulting architecture covers the requirements imposed by all scenarios described in deliverable D1.1.
7.1 Next Steps

The resulting initial system architecture is a modular one and follows existing standards and proposals so as to provide the guidelines to the implementation task T3.3. Components of the presented initial architecture will be designed based on WP knowledge, according to the mechanisms for traffic management specified in WP2. Particular focus in task T3.1 will be on refining the component interfaces to fit all mechanisms developed in tasks T3.3 and T3.4 and to ease the integration work in task T3.5. Finally, deliverable D3.3 will present in detail the final architectural structure of the SmartenIT system, providing all available interfaces, exchanged information, and the sequence of messages required to compose the complete the SmartenIT solution. This deliverable will cover, after interacting with WP2 and WP4, expected changes (minor or important ones) that may occur in the specification of mechanisms, the system implementation, and the system validation progress.
Page 68 of 78
Version 3.0

Public
8 SMART Objectives Addressed

Through this document, three SmartenIT SMART objectives defined in Section B1.1.2.4 of the SmartenIT Description of Work (DoW, [66]) have been partially addressed. Namely, one overall (O3, see Table 2) and one practical (O3.2, see Table 3) SMART objectives were addressed. The overall Objective 3 is defined in the DoW as follows: 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 provides a first step towards a successful, viable, and efficient architectural integration by outlining the problem and related architectural approaches (Section 3) and describing the base functionality and the corresponding conceptual architecture for the SmartenIT approach (Section 4). Moreover, it provides the initial specification of the functionality and the interactions required by each functional block to fulfill its purpose (Section 5). Finally, it makes a first attempt to design the initial SmartenIT system architecture (Section 6). These results provide the guidelines to the task T3.3 in which the prototype components will be developed. As such, deliverable D3.1 is a first step towards the achievement of the architectural integration as part of Objective 3, which will be extended in deliverables D3.2 (Technologies, Implementation Framework, and Initial Prototype, end of project month 18) and D3.3 (Final System Architecture, end of project month 24) as well as finalized in D3.4 (Prototype Implementation, Validation and Selected Application, end of project month 30). Table 2: Overall SmartenIT SMART objective addressed. (Source: [66])
Objective No.
O3
Specific
Architectural integration
Measurable
Deliverable Number
Achievable
Design
Relevant
Complex
Timely
Mile Stone Number
D3.1
MS3.1
Table 3: Practical SmartenIT SMART objectives addressed. (Source: [66])

Objective ID Measurable Specific
Metric
Timely Achievable Relevant

Highly relevant output of relevance for providers
Project Month
O3.2
At which level to integrate the proposed solution with the existing network management platforms?
Number of considered management platforms, number of comparison studies to existing solutions
Design T3.1
M24
This deliverable contributes to answering one specific practical question: 1. Objective O3.2: At which level to integrate the proposed solution with the existing network management platforms? The outline of the environment in which the technological solution of SmartenIT will be deployed derives the problem statement which roughly evaluates the cases
Version 3.0
Page 69 of 78

Public
where stakeholders could benefit from SmartenIT. Moreover, a number of existing architectures that tackle similar or related problems have been analyzed to provide the basis for the SmartenIT architecture (see Section 3, in particular Table 1). Based on the problem description and discussion of related approaches, the conceptual architecture outlines the domain view and the topological view, illustrating in which way the proposed solutions may be integrated (see Section 4). This is further detailed in Section 5, which describes the internals of each functional block and analyzes each block (and interface) in order to extract more detailed requirements, which finally drive the consolidation of the analyzed functionality into an initial integrated view of the system architecture (see Section 6). Objective O3.2 will be addressed further in T3.2, which will perform the technology scouting and define the implementation framework, as well as T3.3, which will develop the prototype components. According to the SMART objectives set within SmartenIT DoW, those ones of relevance for D3.1 and the respective task within WP3, i.e., T3.1, the targeted for objectives have been met.
Page 70 of 78
Version 3.0

Public
9 References
[1] Open Networking Foundation: Software-Defined Networking: The New Norm for Networks, April 2012. Available from: https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdnnewnorm.pdf Open Networking Foundation, https://www.opennetworking.org/ OpenFlow Specification, Last http://www.openflow.org/wp/documents/ Last access: April April 2013. 2013. Nov Available Available 2011. from: from: Available:
[2] [3] [4] [5] [6] [7] [8] [9]
access:
S. Seetharaman: OpenFlow / Software-defined http://www.slideshare.net/openflow/openflow-tutorial
Networking,
FI-WARE: Future Internet Core Platform, Last access: April 2013. Available from: http://www.fi-ware.eu/ Future Internet Public-Private Partnership, Last access: April 2013. Available from: http://www.fi-ppp.eu/ FI-WARE Cloud Hosting, Last access: April 2013, Available ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Cloud_Hosting from: http://forge.fi-
FI-WARE Interface to Network and Devices, Last access: April 2013, Available from: http://forge.fiware.eu/plugins/mediawiki/wiki/fiware/index.php/Interface_to_Networks_and_Devices_%28I2ND%29 M. Satyanarayanan, P. Bahl, R. Caceres, N. Davies: The Case for VM-Based Cloudlets in Mobile Computing, IEEE Pervasive Computing, Vol. 8, No.4, pp.14-23, 2009.
[10] The OpenStack project, Last access: April 2013. Available from: http://www.openstack.org/ [11] P2P Live Streaming for the Masses Deployment and Results, IRTF-75 Presentation, P2P Research Group, Stockholm, 2009. Available from: http://www.ietf.org/proceedings/75 [12] The BonFIRE FP7 project, Last access: April 2013. Available from: http://www.bonfire-project.eu/ [13] The GEANT BoD http://bod.geant.net/ (Bandwidth on Demand), Last access: April 2013. Available from:
[14] S. Soursos, M. Callejo Rodriguez, K. Pussep, P. Racz, S. Spirou, G. Stamoulis, B. Stiller: ETMS: A System for Economic Management of Overlay Traffic, Future Internet Conference (FIA 2009), Amsterdam, The Netherlands, April 2008. [15] P. Racz, S. Oechsner, F. Lehrieder: BGP-based Locality Promotion for P2P Applications. 19th IEEE International Conference on Computer Communications and Networks (ICCCN 2010), Zrich, Switzerland, August 2010. [16] K. Pussep, S. Kuleshov, C. Gross, S. Soursos: An Incentive-based Approach to Traffic Management for Peer-to-Peer Overlays. 3rd Workshop on Economic Traffic Management (ETM 2010), Amsterdam, The Netherlands, September 2010. [17] I. Papafili, S. Soursos, G. Stamoulis: Improvement of BitTorrent Performance and Inter-domain Traffic by Inserting ISP-owned Peers. ICQT09, Aachen, Germany, May 2009. [18] Z. Dulinski, R. Stankiewicz, P. Choda, P. Wydrych, B. Stiller: Inter-ALTO communication protocol, IETF Internet draft, draft-dulinski-alto-inter-alto-protocol-00, June 2010. [19] Z. Duliski, P. Wydrych, R. Stankiewicz, P. Choda, M. Kantor: Inter-ALTO Communication Problem Statement, IETF Internet draft, draft-dulinski-alto-inter-problem-statement-00, March 2011. [20] R. Alimi, R. Penno, Y. Yang: ALTO Protocol, draft-ietf-alto-protocol-14.txt (work in progress), February 2013. Available from: http://tools.ietf.org/html/draft-ietf-alto-protocol-14 [21] M. Stiemerling, S. Kiesel, S. Previdi: ALTO Deployment Considerations, draft-ietf-alto-deployments06.txt (work in progress), February 2013. Available from: http://tools.ietf.org/html/draft-ietf-altodeployments-06 [22] V. Gurbani, M. Scharf, T. Lakshman, V. Hilt: Abstracting network state in Software Defined Networks (SDN) for rendezvous services, IEEE International Conference on Communications (ICC) Workshop on Software Defined Networks (SDN), June 2012.
Version 3.0
Page 71 of 78

Public
[23] H. Xie, T. Tsou, D. Lopez, H. Yin: Use Cases for ALTO with Software Defined Networks, draft-xie-altosdn-extension-use-cases-01, January 2013. Available from: http://tools.ietf.org/pdf/draft-xie-alto-sdnextension-use-cases-01.pdf [24] N. Kamiyama, et al.: ISP-operated CDN, 14th NETWORKS Telecom, Network Strategy & Planning Symposium, Warszawa, Poland, 2010. [25] perfSONAR, Last access: April 2013. Available from: http://www.perfsonar.net/ [26] RRD Tool, Last access: April 2013. Available from: http://oss.oetiker.ch/rrdtool/ [27] M. Wichtlhuber, D. Hausheer: vINCENT: An Incentive-Scheme for Peer-to Peer Content Distribution Supporting Virtual Nodes, Conference on Networked Systems (NetSys), PhD Forum, Stuttgart, Germany, March 2013. [28] V. Valancius, N. Laoutaris, L. Massouli, C. Diot, P. Rodriguez: Greening the Internet with Nano Data Centers. International Conference on Emerging Networking Experiments and Technologies (ACM CoNEXT), 2009. [29] D. Hardt: The OAuth 2.0 Authorization Framework, RFC 6749, October 2012. [30] M. Jones, D. Hardt: The OAuth 2.0 Authorization Framework: Bearer Token Usage, RFC 6750, October 2012. [31] Ten Steps to Increasing Data Center Efficiency and Availability through Infrastructure Monitoring, A White Paper from the Experts in Business-Critical Continuity, Emerson Network Power, Last access: April 2013. Available from: http://www.cisco.com/web/partners/downloads/765/other/10_Steps_to_IM.pdf [32] R. Sherwood, G. Gibb, K. K. Yap, G. Appenzeller, et al.: Flowvisor: A network virtualization layer. Technical Report Openflow-tr-2009-1, Stanford University, 2009. Available from http://www.openflow.org/downloads/technicalreports/openflow-tr-2009-1-flowvisor.pdf [33] R. Wang, D. Butnariu, J. Rexford: Openflow-based server load balancing gone wild; USENIX HotICE, 2011. [34] H. Egilmez, S. Dane, et al.: OpenQoS: An OpenFlow controller design for multimedia delivery with endto-end Quality of Service over Software-Defined Networks, Signal & Information Processing Association Summit and Conference (APSIPA ASC), 2012. [35] N. Sarrar, S. Uhlig, A. Feldmann, R. Sherwood: Leveraging Zipf's Law for Traffic Offloading; ACM SIGCOMM Computer Communication Review (CCR), Vol. 42, No. 1, January 2012. [36] T. Li, N. Van Vorst, R. Rong, J. Liu: Simulation Studies of OpenFlow-based In-network Caching Strategies, ACM Communications and Networking Simulation Symposium (CNS), 2012. [37] Economics and Technolgies for Inter-Carrier Services (ETICS), Last access: April 2013. Available from: https://www.ict-etics.eu/ [38] Open ContEnt Aware Networks (OCEAN), Last access: April 2013. Available from: http://www.ictocean.eu/ [39] J. Seedorf, E. Burger: Application-Layer Traffic Optimization (ALTO) Problem Statement, RFC 5693, October 2009. Available from: http://tools.ietf.org/html/rfc5693 [40] B. Niven-Jenkins, F. Le Faucheur, N. Bitar: Content Distribution Network Interconnection (CDNi) Problem Statement, RFC 6707, September 2012. Available from: http://tools.ietf.org/html/rfc6707 [41] Y. Lee, et al.: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization, RFC 5557, July 2009. Available from: http://tools.ietf.org/html/rfc5557 [42] D. King, A. Farrel: A PCE-based Architecture for Application-based Network Operations, Internet Draft, February 2013. Available from: https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/ [43] OpenNebula - Open Source Data Center Virtualization, Last access April 2013. Available from: http://opennebula.org [44] OpenStack - Open vSwitch: An Open Virtual Switch, Last access April 2013. Available from: http://openvswitch.org/openstack/
Page 72 of 78
Version 3.0

Public
[45] S. Randriamasy, N. Schwan: ALTO Cost Schedule, IETF draft, draft-randriamasy-alto-cost-schedule02, 85th IETF, Atlanta GA, October 2012. Available from: http://tools.ietf.org/html/draft-randriamasyalto-cost-schedule-02 [46] J. Charzinski: Traffic Properties, Client side Cachability and CDN Usage of Popular Web sites, 15th MMB Conference, Essen, Germany, Springer LNCS 5987, pp. 182-194, 2010. [47] Digital Video Broadcasting Project (DVB), Internet TV Content Delivery study mission report, DVB Document A 145, 2009. [48] Digital Video Broadcasting (DVB): Internet TV Content Delivery Study Mission Report, December 2009. Available from: http://www.dvb.org/technology/standards/A145_Internet_TV_Content_Delivery_Study.pdf [49] M. Eubanks: The Video Tsunami: Internet Television, IPTV and the Coming Wave of Video on the Internet, Plenary talk, 71th IETF meeting, 2008. Available from: http://www.ietf.org/proceedings/08mar/slides/plenaryt-3.pdf [50] R. Fielding et al.: Hypertext transfer protocol HTTP/1.1: Caching, Internet-Draft, Work in progress, 2013. Available from: http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22 [51] G. Hasslinger: ISP Platforms under a Heavy Peer-to-Peer Workload, Peer-to-Peer Systems and Applications, Eds.: R. Steinmetz and K. Wehrle, Springer LNCS 3485, pp. 369-382, 2005. [52] G. Hasslinger, F. Hartleb: Content Delivery and Caching from a Network Providers Perspective, Special Issue on Internet based Content Delivery, Computer Networks, Vol. 55, pp. 3991-4006, 2011. [53] G. Hasslinger, G. Nunzi, C. Meirosu, C. Fan, F.-U. Andersen: Traffic Engineering Supported by Inherent Network Management: Analysis of Resource Efficiency and Cost Saving Potential, International Journal on Network Management (IJNM), Vol. 21, pp. 45-64, 2011. [54] G. Hasslinger, S. Schnitter, M. Franzke: The Efficiency of Traffic Engineering with regard to Failure Resilience, Telecommunication Systems Vol. 29, No. 2, Springer, pp. 109-130, 2005. [55] C. Huang, A. Wang, J. Li, K. Ross: Understanding Hybrid CDN-P2P, NOSSDAV, Braunschweig, Germany, pp. 75-80, 2008. [56] A.-J. Su, D.R. Choffnes, A. Kuzmanovic, F.E. Bustamante: Drafting behind Akamai, IEEE/ACM Trans. on Networking, Vol. 17, pp. 17521765, 2009. [57] L. Ciavattone, R. Geib, A. Morton, M. Wieser: RFC 2680 (1-way Loss) Test Plan and Results. March 2013. Available from: http://www.ietf.org/proceedings/86/slides/slides-86-ippm-0.pdf [58] J.F. Kurose, K.W. Ross: Computer Networking, A Top-Down Approach , Sixth Edition, Pearson, 2012. [59] B. Rochwerger, J. Caceres, R.S. Montero, et al.: The RESERVOIR Model and Architecture for Open Federated Cloud Computing, IBM Journal of Research and Development, Vol. 53, No. 4, pp. 1-11, July 2009. [60] D. Staessens, et al.: Software defined networking: Meeting carrier grade requirements. IEEE Workshop on Local & Metropolitan Area Networks (LANMAN), 2011. [61] Future Internet Architecture (FIArch) Group: Future Internet Design Principles, January 2012. Available from: http://www.future-internet.eu/uploads/media/FIArch_Design_Principles_V1.0.pdf [62] K. Lee, J. Lee, Y. Yi, I. Rhee, S. Chong: Mobile data offloading: how much can WiFi deliver? ACM Conference on Emerging Networking Experiments and Technologies (CoNEXT), 2010. [63] A. Iamnitchi, J. Blackburn, N. Kourtellis: The Social Hourglass - An Infrastructure for Socially Aware Applications and Services, IEEE Internet Computing, 2012. [64] Zoran Despotovic (Edt.): Economic Traffic Management Systems Architecture Design (Final), Deliverable D3.4 of the SmoothIT project, August 2010. [65] SmoothIT: Simple Economic Management Approaches of Overlay Traffic in Heterogeneous Internet Topologies, Last access: April 2013. Available from: http://www.smoothit.org/ [66] The SmartenIT Consortium: Grant Agreement for STREP: Annex I Description of Work (DoW). 2012.
Version 3.0
Page 73 of 78

Public
10 Abbreviations
3G/UMTS 3GPP 4G/LTE ABNO AESF AGH ALBLF ALTO API APN AS ASQ AUEB-RC BGP BoD BSC CDI CDN CDNi CE CGI CMS CPE DC DCIM DNS DPI EBGP EC2 eNodeB ETICS ETM EuQoS Third Generation / Universal Mobile Telecommunications System Third Generation Partnership Project Fourth Generation / Long Term Evolution Application-Based Network Operations Application Endpoint Selection Function Akademia Gorniczo-Hutnicza im. Stanislawa Staszica W Krakowie Alcatel Lucent Bell Labs Application Layer Traffic Optimization Application Programming Interface Access Point Name Autonomous System Assured Service Quality Athens University of Economics and Business - Research Center Border Gateway Protocol Bandwidth on Demand Base Station Controller Connected Device Interfacing Content Delivery Network Interconnection of Content Delivery Networks Cloud Edge Cell Global Identity Cloud Management System Customer Premises Equipment Data Center Data Center Infrastructure Management Domain Name System Deep Packet Inspection External Border Gateway Protocol Elastic Compute Cloud Evolved Node B Economics and Technologies for Inter-Carrier Services Economic Traffic Management End-to-end Quality of Service support over heterogeneous networks
Page 74 of 78
Version 3.0

Public
FI FP7 GE GEANT GGSN GMPLS GMSC GSM GW HAP HLS HTTP I2ND I2RS IaaS IBGP IC ICOM ICT IESG IETF IP IRT IS-IS ISP KPI L2VPN L3VPN LAI LAN LDP LUP MBGP MESCAL MME
Version 3.0
Future Internet Seventh Framework Programme Generic Enabler Gigabit European Academic Network Gateway GPRS Support Node Generalized Multi-Protocol Label Switching Gateway Mobile Switching Center Global System for Mobile Communications Gateway Highly Active Peer HTTP Live Streaming Hypertext Transfer Protocol Interface to Networks and Devices Interface to the Routing System Client Infrastructure as a Service Interior Border Gateway Protocol Internet Interconnection Intracom S.A. Telecom Solutions Information and Communications Technology Internet Engineering Steering Group Internet Engineering Task Force Internet Protocol Interoute S.P.A. Intermediate System to Intermediate System Internet Service Provider Key Performance Indicators Layer 2 VPN Layer 3 VPN Location Area Identity Local Area Network Label Distribution Protocol Link Utilization Patterns Multiprotocol Border Gateway Protocol Management of End-to-end Quality of Service Across the Internet at Large Mobility Management Entity
Page 75 of 78

Public
MOS MPLS MSC NaDa NetIC NMS NO NOC NSP NSQM NTM OAM OCEAN OS OSN OSPF OSS OTT P2P PaaS PC PCE PCRF PDN PDP PGW PID PLMN PoP PSNC QoE QoS RAT RG RNC
Page 76 of 78
Mean Opinion Score Multi-Protocol Label Switching Mobile Switching Center Nano Data Centers Network Information & Control (NetIC) Network Management Systems Network Operators Network Operation Center Network Service Provider Network and Service Quality Measurements Network Traffic Manager Operation, Administration, and Maintenance Open ContEnt Aware Networks Operating System Overlay Social Network Open Shortest Path First Operations Support Systems Over-the-Top Peer-to-Peer Platform as a Service Personal Computer Path Computation Element Policy and Charging Rules Function Packet Data Network Packet Data Protocol Packet Data Network Gateway Provider-defined Identifier Public Land Mobile Network Point of Presence Poznan Supercomputing and Networking Center Quality of Experience Quality of Service Radio Access Technology Research Group Radio Network Controller
Version 3.0

Public
RRD RSVP RTP RTT S3 S3C SaaS S-Box SDN SGSN SGW SIS SLA SmartenIT SMO SmoothIT SNMP STREP TCP TDG TNL TUD UDP UE UniWue UZH VM VNTM VPLS VPN VNC VQM WAN
Round-Robin Database Resource Reservation Protocol Real-time Transport Protocol Round Trip Time Simple Storage Service Service, Capability, Connectivity and Control Software as a Service SmartenIT Box Software Defined Networks Serving GPRS Support Node Serving Gateway SmoothIT Information Server Service Level Agreement Socially-aware Management of New Overlay Application Traffic with Energy Efficiency in the Internet Storage Management Overlay Simple Economic Management Approaches of Overlay Traffic in Heterogeneous Internet Topologies Simple Network Management Protocol Specific Targeted Research Projects Transport Control Protocol Telekom Deutschland GmbH Transport Network Layer Technische Universitt Darmstadt User Datagram Protocol User Equipment Julius-Maximilians Universitt Wrzburg University of Zrich, UZH Virtual Machine Virtual Network Topology Manager Virtual Private LAN Service Virtual Private Network Virtual Network Computing Video Quality Model Wide Area Network
Version 3.0
Page 77 of 78

Public
WG WLAN WP
Working Group Wireless LAN Work Package
11 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 besides the deliverable authors as indicated in the document control, a number of additional persons as well. Many thanks to all of them. Additionally, we thank the SmartenIT internal reviewers Ioanna Papafili (AUEBRC), Tobias Hossfeld (UniWue), Spiros Spirou (ICOM), and Burkhard Stiller (UZH) for providing valuable feedback and input.
Page 78 of 78
Version 3.0

Deliverable D3.1 Report On Initial System Architecture

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deliverable D3.1 Report On Initial System Architecture

Uploaded by

Copyright:

Available Formats

Seventh Framework STREP No.

D3.1 - Report on Initial System Architecture