deliverable d5.2 standardization survey

Seventh Framework STREP No. 317846 D5.2 – Standardization Survey Commercial in Confidence

Version 1.0 of 38 © Copyright 2013, the Members of the SmartenIT Consortium

Socially-aware Management of New Overlay Application Traffic with

Energy Efficiency in the Internet European Seventh Framework Project FP7-2012-ICT- 317846-STREP

Deliverable D5.2 Standardization Survey

The SmartenIT Consortium Universität Zürich, UZH, Switzerland Athens University of Economics and Business - Research Center, AUEB, Greece Julius-Maximilians Universität Würzburg, UniWue, Germany Technische Universität Darmstadt, TUD, Germany Akademia Gorniczo-Hutnicza im. Stanislawa Staszica w Krakowie, AGH, Poland Intracom SA Telecom Solutions, ICOM, Greece Alcatel Lucent Bell Labs, ALBLF, France Instytut Chemii Bioorganicznej PAN, PSNC, Poland Interoute S.P.A, IRT, Italy Telekom Deutschland GmbH, TDG, Germany © Copyright 2013, the Members of the SmartenIT Consortium For more information on this document or the SmartenIT project, please contact: Prof. Dr. Burkhard Stiller Universität Zürich, CSG@IFI Binzmühlestrasse 14 CH—8050 Zürich Switzerland Phone: +41 44 635 4331 Fax: +41 44 635 6809 E-mail: [email protected]

D5.2 Standardization Survey Seventh Framework STREP No. 317846 Commercial in Confidence

of 38 Version 1.0 © Copyright 2013, the Members of the SmartenIT Consortium

Document Control Title: Standardization Survey

Type: Public

Editor(s): Sabine Randriamasy

E-mail: [email protected]

Author(s): Gerhard Haßlinger, Roman Łapacz, Antonis Makris, Patrick Poullie, Sabine Randriamasy, Corinna Schmitt, Spiros Spirou, Piotr Wydrych

Doc ID: D5.2-v1.0.doc

AMENDMENT HISTORY

Version Date Author Description/Comments

V0.1 September 16th 2013

Sabine Randriamasy V0 for D5.2 – with initial partner input

V0.2 Sep 17, 2013 Corinna Schmitt Added IETF activity by UZH

V0.1.0.4 Sep 19 Sabine Updated ToC, introduction and, section 4 strategy

V0.1.0.5 Sep 20 Roman Łapacz The OGF info updated

V0.1.0.6 Sep 22 Antonis Makris Update mainly ICN section

V0.2 Oct 2 Sabine Randriamasy Integration of V0.1.0.* with comments to address

V0.2.0.7 Oct 7 Antonis Makris CDNI figures,IRTF definlitions update

V0.3 Oct9 Sabine Randriamasy Conclusion and last updates. Submitted for internal review

V0.3.0.4. Oct 28 Corinna Schmitt Comments in IETF CoRE addressed

V0.3.0.5 Oct 29 Antonis Makris Comments in cdni and icn addressed

V1.0 Oct 31 Sabine Randriamasy Reviewer comments addressed, document completion, final editing

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.



Table of Contents

1 Executive Summary 5

2 Introduction 6

3 Survey on SmartenIT Relevant Standardization Bodies 9 3.1 Internet Engineering Task Force (IETF) 9

3.1.1 Application Layer Traffic Optimization (ALTO) 9 3.1.2 CDN Interconnection (CDNI) 13 3.1.3 Multiple Interfaces (MIF) 16 3.1.4 Multipath TCP (MPTCP) 17 3.1.5 RTP Media Congestion Avoidance Techniques (RMCAT) 17 3.1.6 IETF working group Constraint RESTful Environmnets (CoRE) 18 3.1.7 Large-Scale Measurement of Broadband Performance (LMAP) 19

3.2 Internet Research Task Force (IRTF) 19 3.2.1 Software-Defined Networking RG (SDN RG) 20 3.2.2 Information-Centric Networking RG (ICN RG) 21

3.3 International Telecommunication Union (ITU-T) 22 3.3.1 SG13 23

3.4 Open Grid Forum (OGF) 24 3.4.1 Network Measurements (NM) 24 3.4.2 Network Measurement and Control (NMC) 25 3.4.3 Network Markup Language (NML) 25 3.4.4 Network Service Interface (NSI) 26

4 SmartenIT Standardization Background and Strategy 27 4.1 SmartenIT Partner Involvement in Standardization Bodies 27 4.2 Standardization Plans per Standardization Group 29

4.2.1 IETF – ALTO WG 29 4.2.2 IETF – CDNI WG 30 4.2.3 IRTF – SDN RG 30 4.2.4 IETF – CoRE WG 31 4.2.5 ITU-T – SG13 31

5 Conclusions 33

6 References 34

7 Abbreviations 37

8 Acknowledgements 38



(This page is left blank intentionally)



1 Executive Summary Modern applications, on top of the steady Internet traffic increase, amplify the unpredictability and burstiness of network traffic. In particular a growing part of traffic generated by cloud application is driven by social networks and runs on a growing number of energy demanding end user devices and network equipment.

The resulting network challenges are a waste of network resources caused by transport network topology agnostic overlay applications, increased network operator costs, degradation of user quality of experience and energy waste. To address them, the SmartenIT project targets an incentive-compatible cross-layer network management scheme for network and cloud operators, cloud service providers, and end-users to drive the traffic generated by cloud applications, with a joint awareness on network efficiency, energy efficiency and end user behavior.

To this end, SmartenIT enriches the legacy traffic management solutions with adequate schemes for inter cloud communication to support multi-party cloud traffic and for global service mobility to efficiently place services data resources. SmartenIT adds new design goals, namely social awareness and energy efficiency in their design.

The cloud application market has now taken off and its related products rely on a number of standard protocols. Likewise, the standardization bodies follow the Internet usage by designing evolution or addition of protocols to support modern applications.

This deliverable D5.2 is an output of Task 5.2 “Standardization” and provides a survey of standardizations bodies and affiliated working groups that are relevant to the potential standardization efforts of SmartenIT. Deliverable D5.1, see [36], provides a preliminary list of topics on which the follow-up and contribution efforts of Task 5.2 should focus: methods for socio-economically aware design of future Internet technology, energy efficiency mechanisms for traffic management, cloud traffic management mechanisms, extensions to standard protocols. This deliverable D5.2 describes a selection of relevant working group activities with their latest outcomes and outlines initial standardization plans identified in the SmartenIT consortium during the first project year. Standardization plans range from follow-up on crucial protocols for the SmartenIT mechanisms being specified in WP2 and architecture being defined in WP3 to contributions in relevant bodies and protocol extension proposals. At this stage of the project, T5.2 has identified an initial list of focus bodies that may slightly change as some may be closed and some other be created in the meantime. Nevertheless, a number of them produce protocols and specifications that are well suited to be integrated in the SmartenIT functions design.

The outcomes of the T5.2 plans will be reported in deliverable D5.3 to be issued at the end of the project. It is important to remind that the T5.2 standardization commitments limit the planned contribution in bodies to proposals. Indeed, getting proposals adopted as standards usually takes more time than the duration left for a project. Instead, SmartenIT provides use cases that highlight the benefits on new and ongoing standard contributions that may get adopted within the duration of the project.



2 Introduction The Cloud is progressively dominating the Internet traffic stresses challenges like user QoE, network stability and energy efficiency. Users massively run applications with a high demand in network and application resources, on a growing diversity of devices and often following social behavior patterns. This results in sub-optimal usage of energy and network resources and requires solutions to avoid overload of overlay and transport services. This also stresses the need to enrich the legacy overlay traffic management solutions with schemes enabling a better support for multi-party cloud traffic and for an efficient placement of overlay application resources.

To this end, the SmartenIT is designing inter cloud communication and global service mobility schemes that integrate crucial features such as QoE awareness and an incentive-compatible cross-layer framework to address challenges like energy efficiency, cost reduction for operators, QoE for end users, inter-domain traffic management. The SmartenIT mechanisms defined in D2.2, see [37] are being specified to be integrated as an evolution of solutions that mostly rely on standard protocols and functionalities. Likewise, the aforementioned challenges are being investigated in a number of standardization bodies and many of their major outcomes can be deployed within SmartenIT architecture that is being defined in WP3, see [38]. Therefore, non-disruptive parts of SmartenIT mechanisms and architecture need to be compliant with existing relevant standards, whereas disruptive ones may lead SmartenIT to propose extensions to standard mechanisms and protocols so as to tailor them to the SmartenIT needs.

The SmartenIT WP5 Task 5.2 «Standardization» has the following objectives:

- Identify the standardization bodies and working groups that are closely connected to the SmartenIT problem and solutions.

- Define standardization plans to:

o Ensure a maximum compliance of SmartenIT functions with existing protocols,

o Propose standard extensions to support SmartenIT innovations.

SmartenIT adds new traffic management mechanisms to the legacy ones and likewise, its involvement in standardization activities has several levels:

- Follow-up of relevant standardization bodies and WGs,

- Contributions with standardization extensions supporting the SmartenIT objectives.

Deliverable D5.1, see [36], sets a preliminary list of topics on which Task 5.2 should focus: methods for socio-economically aware design of future Internet technology, energy efficiency mechanisms for traffic management, cloud traffic management mechanisms, extensions to standard protocols. The mapping to the bodies and groups described in D5.2 is however hard to do at this stage and will be completed in a further deliverable D5.3 reporting the outcomes of task T5.2 standardization.

This deliverable is organized in two main parts: the first part provides a description of relevant standardization bodies, specific working group activities with their latest outcomes and their relation to SmartenIT. The second part pictures the current SmartenIT consortium involvement in standardization and outlines initial standardization plans identified in the SmartenIT consortium throughout the first project year.



The relation to standardization bodies is driven by the key requirements expressed in the project DoW (Description of Work), see [34] on network management mechanisms to be designed by SmartenIT: such mechanisms should be “cross-layer, operational, incentive-compatible and efficient for dealing with inter-domain ISPs functionality”.

Standardization bodies support the evolution of modern Internet traffic with the creation of a number of working and research groups. Task 5.2 partners have a solid background in IETF (Internet Engineering Task Force), ITU (International Telecommunication Union), OGF (Open Grid Forum) and IRTF (Internet Research Task Force). This document focuses on selected groups of these standard development organizations that address SmartenIT specific challenges.

IETF is designing the Internet related protocols and Task 5.2 focuses on groups looking at movements of large bulk content across transport or application network domains (CDNI1, ICN2), with a cross-layer decision scope (ALTO3) and requirements for richer transport paths (MP-TCP4) and connection schemes (MIF5). Since 2012 the RMCAT6 group was created to address streaming congestion, the sub-group of CoRE7 dealing with data security and LMAP8 group working on standard network performance assessment for end users.

ITU is a United Nations agency for information and communication technologies that publishes recommendations, which are highly relevant for industry and legislative bodies. In particular, an ITU-T division is focused amongst others on clouds ecosystem and on themes related to environment and socio-economic awareness.

IRTF is a research body that works in parallel to IETF and focuses on areas that are not mature enough for standardization in IETF or not a subject of standardization but may support future standardization efforts, see [11]. In particular, the SDN RG9 studies architectures for agile network management and ICN RG looks at integrating the naming schemes and name resolution with routing.

OGF is a community of users, developers, and vendors leading the global standardization effort for distributed computing, including clusters, grids and clouds. It works in cooperation with other leading standards organizations. T5.2 interests focus on network measurements and control (NM, NMC), network markup language (NML) to formalize topologies and network service interface (NSI) to provision bandwidth on demand.

The remainder of this deliverable is organized as follows: • Section 3 describes the different standardization bodies that relate to the objectives of

the SmartenIT project, identifies the relation to SmartenIT and recent relevant updates.

• Section 4 describes the SmartenIT standardization background and strategy. It gives the partner involvement in each of the bodies described in Section 3. Moreover, it

1 Content Delivery Networks Interconnection (CDNI) 2 Information Centric Networking (ICN) Research Group (RG) 3 Application Layer Traffic Optimization (ALTO) 4 MultiPath TCP (MP-TCP) 5 Multiple InterFaces (MIF) 6 RTP Media Congestion Avoidance Techniques (RMCAT) 7 (CoRE) Constraint RESTful Environments 8 Large-Scale Measurement of Broadband Performance (LMAP) 9 Software-defined network (SDN) Research Group (RG)



outlines an initial SmartenIT standardization strategy, by providing plans of individual partners, and of SmartenIT partner groups.

• Section 5 draws the major conclusions on the presented bodies and the next steps for T5.2.



3 Survey on SmartenIT Relevant Standardization Bodies

This section describes the different standardization bodies that relate to the objectives of the SmartenIT project and provides:

- A definition of the body,

- A presentation of selected working groups within this body,

- Its relevance to SmartenIT,

- Last updates when they impact the SmartenIT solution design.

3.1 Internet Engineering Task Force (IETF)

IETF stands for Internet Engineering Task Force. This body declares [1] its mission as being « "to make the Internet work better," but it is the Internet Engineering Task Force, so this means: make the Internet work better from an engineering point of view. We try to avoid policy and business questions, as much as possible ».The IETF designs protocols from Layer 3 to Layer 7 of TCP/IP stack to give support to traffic among end systems identified by an IP address, whether they are fixed or mobile. It also supports traffic continuity upon mobility of end systems.

The IETF is divided into eight functional areas each structured in Working Groups (WG). Among them, the Transport Area covers protocol standards related to streams of data transmission over the Internet, in particular: ALTO, CDNI, MIF, MPTCP, RMCAT, CoRE, and LAMP are presented in this section.

The protocol specifications meant to be standardized and related working documents such as problem definitions and requirements are validated by a body called Internet Engineering Steering Group (IESG), that is composed of the IETF chair and area directors, is responsible for day-to-day management of the IETF and provides the final technical review of Internet standards.

3.1.1 Application Layer Traffic Optimization (ALTO)

ALTO stands for Application Layer Traffic Optimization and is an IETF protocol. The ALTO Working Group [3] is introducing services to provide available localization information to distributed applications in order to optimize distances and transport paths in downloads and content delivery. 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. As stated in the base ALTO Protocol specification described in [4], 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 user Quality of Experience (QoE) on the application while reducing resource consumption in the underlying network infrastructure. To this end, ALTO Servers deployed by Network Operators (NOs), provide requesting ALTO Clients with information, such as



the NO-centric view on the network topology, the candidate endpoints with attributes such as their routing cost or connectivity type. ALTO started in 2008, motivated by use cases of random and unnecessary long transport paths in P2P networks, but extended the scope for distributed applications including CDNs, which face the same problem of selecting an appropriate CDN server/cache for each user request. Network providers are enabled to host ALTO servers based on a standardized protocol and network information basis and interface to applications.

InformationServer

Applications

Server

NetworkProviders

Request/Responsee.g. Peer selection

Informationon distances

CoordinateSystems

ApplicationLayer

ApproachPermanent

measurement ofdelay between peers

Estimation on positions

and clustering

Caching

NetworkProviderApproach

Local downloadsfrom backbone oraggregation nodes

supported by caches

Cache

InformationServer

Applications

Server

NetworkProviders



InformationServer

Applications

Server

NetworkProviders



CoordinateSystems

ApplicationLayer

ApproachPermanent

measurement ofdelay between peers

Estimation on positions

and clustering

Caching



supported by caches

Cache

Caching



supported by caches

Cache

Figure 1: Approaches for localized content delivery and traffic management support.

Earlier projects and studies already made such information available on web sites, such as Closest Node, see [39], based on the Meridian service [15] or Prefix WhoIs, see [35]. Prefix WhoIs queries are used in the study [17] to identify and give a preference when selecting peers in the same Autonomous System and district for improved locality in the BitTorrent and Coolstreaming P2P networks. In a coarse but already beneficial localization scheme, the corresponding Autonomous Systems (AS) can be assigned to the IP address of a potential source as well as the corresponding ISP or corporate network operator [17]. Some information on the number of transmission hops can be extracted from global BGP routing tables, but tunnelling mechanisms and other obstacles prevent from getting a clear picture of the hop count and transport complexity from an end-to-end view. For finer granularity, the network providers have best knowledge on access regions and neighbourhood relationships within their network domain, but are usually reluctant about publishing their network structure in detail. Therefore ALTO server decisions can be also driven by network providers who can recommend appropriate P2P network sources and CDN servers in the selection process without disclosing network topology information. In general, the basic information set for ALTO servers include:

• A network map that assigns end points to groups associated with different network locations and

• A cost map representing path costs on links and paths amongst network locations.



Moreover, special properties and costs can be assigned to the endpoints in order to reflect connectivity and access bandwidth.

An ISP, network, or CDN provider who operates an ALTO server can provide rating recommendations among a set of resources to perform an application for a requesting endpoint without giving further information on how the rating has been performed. Current working group drafts on the deployment of ALTO [30] consider scenarios for small and large ISPs with cost maps reflecting the transport costs between access regions, core networks, and peering to other network providers.

Figure 2 shows the overall ALTO system architecture produced in the base ALTO protocol specification document [4] that explains: “In this architecture, an ALTO Server prepares ALTO Information; an ALTO Client uses ALTO Service Discovery to identify an appropriate ALTO Server; and the ALTO Client requests available ALTO Information from the ALTO Server using the ALTO Protocol”. Which component provides input to ALTO information and how is outside the ALTO protocol scope that however is not meant to replace near-real-time congestion control protocols.

Figure 2: Basic architecture depicted in the ALTO protocol specification.

In general, ALTO servers cannot be assumed to provide optimum traffic engineering decisions based on full topology awareness, since this is only partly available and the ALTO server operator may give biased recommendations from his perspective. Network providers can set up their own policies for dealing with localization servers which usually avoid transport via expensive and overloaded links. Achieving shorter paths is favourable for all involved parties, but there is a trade-off between non-disclosure of network topologies by the providers and trust of applications in ALTO server ratings without transparency on the underlying decision processes.



On the other hand, applications can collect additional information e.g. through measurement of inter-node transmission latencies [15], which can be combined with the server information on application layer or can be made available also for other applications as another input to the server. A clustering of nodes according to areas which are supplied via the same server of a global CDN may be considered to check locality relationships [14]. The overhead and delay introduced by localization servers has to be kept small. As another control option, applications should set a threshold on the requested data volume to avoid inadequate overhead and delay in requesting localization servers for small data transfers.

3.1.1.1 Relevance to SmartenIT

ALTO is a key player to meet one of the SmartenIT requirements for traffic management mechanisms to provide mutually incentives to players acting at adjacent network levels that are the Cloud Operator and the ISP layers, and usually not exchanging information, such as users or applications and networks of routers or data centers. Both applications and network players benefit from its usage: on one hand, ISP accept to provide an abstraction of their topology and related transport costs to incite applications to use the network in a resource efficient way; on the other hand, applications get a better QoE through the usage of shorter paths and possibly of additional QoE sensitive information such as endpoint or path bandwidth as exposed in ALTO protocol extensions currently proposed at the ALTO WG, see [5]. SmartenIT support to inter-cloud communication or inter-domain communication requires reaching and supporting a minimal degree of semantic understanding among ALTO servers. That is, a robust mechanisms to exchange aggregated information on network topology and conditions among ALTO Servers run by different stakeholders need to be proposed, especially as the ALTO Costs will probably be extended and SmartenIT involvement is necessary there. In particular, ALTO is a preferred candidate in the architecture under final definition in WP3, see [38], to provide abstracted network topology information to Cloud applications in order to help them choosing the best possible end points in terms of transport network costs and performances. Improved energy efficiency is a potential impact, as less power and network resources will be spent by avoiding needlessly long paths or processing. Additionally, cheaper user services, thanks to lower operator operational expenses, together with definitely better user QoE, might be attained. Likewise, traffic management mechanisms involving ALTO have been defined by WP2 in D2.2, see [37]: one for ALTO communication across domains and another one for enhanced application endpoint and service location selection.

3.1.1.2 Latest developments relevant to SmartenIT

The specification of the basic architecture for ALTO protocol is being finalized, the latest version has been issued, see [4] and will be submitted to the IESG. The next step is the re-chartering of the ALTO WG in order to propose extensions to support applications beyond the initial P2P use case. Indeed, ALTO 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 in the ALTO WG covers the Cloud Applications and relates to the SmartenIT problem in that ALTO can help optimizing the traffic of virtualized applications among Data Centers and physical machines or servers within each DC. Such a case motivates several ALTO extensions.



The ALTO WG held a side session during 87th IETF meeting and identified an initial list of extension items to be integrated in a next charter. The list includes extensions on the ALTO costs that introduce new metrics, encoding, time sensitive key elements and allowing for combination of all relevant aspects. Such extensions are foreseen to be deployed within the proposed SmartenIT architecture.

3.1.2 CDN Interconnection (CDNI)

The IETF standardization body is one of the various standards developing organizations who conduct activities for CDN technologies in order to support the increasing demand mainly for streaming services over IP networks. The IETF formed a WG on CDN related topics called CDN Interconnection Working Group (CDNI-WG, see [6]). This WG belongs to the Transport functional Area which covers protocol standards related to streams of data transmission over the Internet because CDN is an infrastructure of network elements that operates at layer 4 (transport layer) through layer 7 to efficiently distribute and deliver digital content. Along with the recent widespread of digital content such as streaming video delivered over IP networks, CDN service providers are extending the scope of their business. In addition, Internet service providers, telecommunications carriers, and even enterprises are building their own CDNs. If these individual CDNs were interconnected, the scope of their services could be expanded without the CDNs themselves being extended. The whole concept is clearly depicted in Figure 3.

The two CDN providers, CDN-A and CDN-B, establish a CDN interconnection. The Content Service CSP-1 reaches an agreement with CDN Provider A, so that when User

CSP-1 CSP-2

CDN Provider ‘A’ (CDN-A)

CDN Provider ‘B’ (CDN-B)

User Agent

Figure 3: Main players in a CDN Interconnection scenario



Agent requires content from CSP-1, the CDNs interconnection actually facilitates delivery through CDN Provider B.

The CDNI Working Group objective is to allow the interconnection of separately administered CDNs , via appropriate interfaces definitions, in support of the end-to-end delivery of content from CSPs (Content Service Providers) through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI interfaces will be normally realized using existing IETF protocols for transport and message exchange.

From a high level point of view, CDNI requires a pair of CDNs: an upstream CDN (uCDN) serving the content provider and a downstream CDN (dCDN) serving the end-user, to exchange two sets of information:

- (i) the uCDN tells the dCDN its policies for how its content is to be delivered (the IETF calls this the metadata interface) and

- (ii) the dCDN advertises its capabilities to the uCDN (the IETF calls this the request routing interface).

The IETF started the CDNI WG in June 2011. The interconnection of separately administered CDNs is considered for support of end-to-end delivery from content service providers (CSPs) through multiple CDNs to end users via their respective user agents.

Figure 4: CDNI interfaces

CSP

Downstream CDN

Surrogate

Distribution

Req-Routing

Logging

Control

Surrogate

Surrogate

Upstream CDN

Surrogate

Distribution

Req-Routing

Logging

Control

Surrogate

Surrogate

User Agent

CDNI

Control Interface

Logging Interface

RR Redirection Interface

CDNI Metadata Interface

Footprint & capabilities advtmt Interface

Request

Acquisition



The CDNI Expanded Reference Model including the interfaces between four fundamental functionalities is depicted in Figure 4: CDNI interfaces.

The main CDNI “Problem Statement” working document, see [41], points out lack of open standards or specifications to facilitate content delivery between the content provider and the requesting user. The use cases, covered in detail in the working document [42], include:

• Footprint extension: this way, a CDN interrelates with downstream CDNs in order to extend its coverage as an important criterion for large CDNs to offer global presence for content and service with full support in many geographical regions.

• Improved third party content handling by large network providers: large network providers who have established their own CDN and data center structures in their network can improve traffic management, resource efficiency, and QoS by standardized interworking and with global CDNs.

• Resource efficient dimensioning, load balancing and failure recovery between CDNs: while CDN support can essentially reduce the risk of bottlenecks at a single web site, since it has distributed network and server capacity available for many sites, the resources may still be overloaded in case of flash crowds or failures. Therefore especially small CDNs can profit from federations making a larger infrastructure available in such cases.

• Robustness against denial-of-service attacks, This includes protection against spoofed delivery requests sent by user agents directly to a Downstream CDN attempting to appear as if they had been redirected by a given Upstream CDN when they have not,

• Enhancement of limited CDN functions and capabilities to be outsourced to another CDN, e.g., for special support of security, QoS, or new technologies,

• Enforcement of policies demanded by the content service provider over several CDNs.

Among the main requirements, CDN interconnection has to work without changes to the user agents and the servers of content provisioning systems and shall reuse existing protocols. Inefficient and inappropriate operation modes have to be avoided, e.g. loops in control, routing, or delivery of small data units with high overhead.

The WG document on the CDN Interconnection framework, see [40], includes a reference model, an overview on operations, DNS and HTTP redirection modes, storing and removal of content. Moreover CDNI main interfaces, deployment framework, trust, and security aspects are considered. CDNI main interfaces as depicted in Figure 4: CDNI interfaces namely are the following:

• Control interface

• Request routing interface

• Metadata interface

• Logging interface

In parallel to the CDNI work, the Hypertext Transfer Protocol Bis (HTTPbis) working group, see [7], is updating and refining the HTTP standards including an advanced working group draft on caching [10]. This document determines the applicability of caching based on diverse information options to be exchanged between the original content source and caching systems, where shared caches for many users and private caches for a single user are distinguished. The information to validate cached data according to [9] can include:



• Freshness, age and an expiry date, • Request methods and response status codes for cache-ability, • Explicit cache directives, such as “no store”, “private”, “public”, “no-transform” or “must-

revalidate”, • Header fields including warnings and extensions for authorization and cache control.

Such information is relevant to decide about new data to be stored or updated in the cache and whether data from the cache can be taken to serve user requests. The document lists up to a dozen preconditions to be checked for standards compliant handling of cached data and admits further cache control extension with fall-back to a default behaviour in case they are not understood. This shows that a standardized approach for ensuring proper use in a wide set of different scenarios can add quite a bit of complexity to caching. In fact, the decision to store content objects in the cache should depend on many factors including the size, request statistics of the past, expiry date until validation with content source and the expected cost for transfer of the object to the cache as well as the expected benefits for delivering the object from the cache. Most relevant is the information exchange between content providers and caching systems whether content is allowed and useful for caching where the expiry date for updating dynamics of content is decisive. On the other hand, more information exchange could be useful that is not addressed in [9] [10]. A content provider who evaluates statistics on the usage of his content for commercial or other purposes would like to get feedback about user requests handled and/or successfully served by caches or otherwise prefers to exclude caching in order to have direct control about user requests and dialogs.


CDNs constitute special cases of cloud networks and CDNs interconnection corresponds to the key SmartenIT scenario which is inter-cloud communication (D1.2 section 4.4). Therefore the CDNI use-case may be of interest for SmartenIT as an example protocol suite to be initially based on and probably enhance. In general, the concept of CDNs and clouds are very similar with regard to supported applications and the distributed server/cache architecture. The SmartenIT consortium is further evaluating the potential adjacencies among SmartenIT and CDNI use-cases.


The informational RFCs and drafts issued by the CDNI working group cover a wide scope of the problem space. The working group is expected to proceed towards the goals of its original charter although the required time frame may be extended beyond two years until the re-charter. The CDNI work already provides a large repository of background information and on the other hand is still open for input. Note that the CDNI WG has identified relations with the ALTO protocol, in particular “an Upstream CDN may take advantage of the ALTO service in its decision for selecting a Downstream CDN to which a user request should be delegated”, see [12], and this approach is investigated by some of the CDNI WG contributors to support footprint capabilities of a downstream CDN.

3.1.3 Multiple Interfaces (MIF)

The purpose of the multiple interfaces (MIF) working group, which started in 2009, is to describe the issues encountered by a node attached to multiple provisioning domains. The



group shall also analyse the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, Interactive Connection Establishment (ICE) and other mechanisms higher layers can use for address selection, Dynamic Host Control Protocol (DHCP) mechanisms, Router Advertisement mechanisms, and DNS recommendations.


The work is relevant for traffic management approaches to optimize the best path or transport via multiple paths to an end system. No direct impact on the SmartenIT designs is identified; however multipath connections for applications are likely to be generalized in the future and it is important to follow up this WG for the sake of completeness.


No recent developments significantly impacting SmartenIT have been identified.

3.1.4 Multipath TCP (MPTCP)

The Multipath TCP (MPTCP) working group, started in 2009, develops mechanisms that add the capability of simultaneously using multiple paths to transport a regular TCP session. Key aspects for MPTCP are:

• to be deployable and usable without significant changes to existing Internet infrastructure,

• to be usable by unmodified applications, • to be stable and congestion-safe over the wide range of existing Internet paths,

including NAT (Network Address Translation) interactions.

MPTCP assumes that both peers are modified and that one or both peers have multiple addresses, which often results in different network paths that are at least partially divergent (however, note there is no guarantee that the paths are divergent at all).


MPTCP is relevant for any traffic management and content delivery approaches in SmartenIT. Other options for traffic management including ALTO, CDNI and caching have to be aware of transport options on multiple paths in parallel.


Currently, MPTCP is continuing work on implementations and on moving RFC6824 on TCP extensions towards standards track.

3.1.5 RTP Media Congestion Avoidance Techniques (RMCAT)

The working group on Real Time Protocol (RTP) Media Congestion Avoidance Techniques started in 2012 to study congestion control for streaming applications using the Real Time Protocol (RTP) over UDP, which are expected to increase with the usage of the RTCWEB protocol suite on Real Time Communication in WEB-browsers.

The demands for streaming and other applications over RTP are basically different from congestion control for TCP since RTP streams have the following relevant characteristics:



• Are more tolerant to loss than file and other data transfers via TCP,

• Have delay requirements,

• Are less flexible in bandwidth demands, i.e. streaming often requires a minimum bandwidth in order to avoid degraded quality of experience, depending on the adaptively of codecs, where congestion signalling e.g. through Explicit Congestion Notification (ECN) is more relevant.


Real Time Communication/Collaboration on the World Wide Web (RTC-Web) applications and their performance under congestion are of central interest to SmartenIT.


No recent developments significantly impacting SmartenIT have been identified.

3.1.6 IETF working group Constraint RESTful Environmnets (CoRE)

The goal of the IETF working group Constraint RESTful Environments (CoRE) is to provide a framework for resource-oriented applications running on constrained IP networks [33]. Especially looking on applications in wireless sensor networks where the devices are limited in resources of memory, computational capacity, and power. The idea carried on by this working group is to use known standards from IP networks by shrinking them to the requirements of constraint devices.

Since summer 2013 a new subgroup within CoRE was established dealing with authentication and authorization tasks. This research came in focus due to the raise of the Internet of Things, the sensitivity of information added to every kind of data, and the raising security feeling of users.


Investigation in terms of Authentication & Authorization is also relevant for SmartenIT, because data access should be regulated and secured. This special topic rises due to the existing external liaison activity to the EU project FLAMINGO where UZH is involved in.


The authorization and authentication question is part of the external liaisons by UZH with the EU project Flamingo. Flamingo investigates among others legal regulation issues driven by stakeholders, countries and laws in order to regulate data access. As mentioned above, in order to protect data, the research in this area is important and UZH received many positive feedback in continuing the research when presenting the draft in IETF 87 [32]. This received feedback and inputs from discussions to use standard-based solutions for authorization and authentication, as mentioned in the draft, forces UZH to go on with standardization in this area and to find a solution that matches all kind of scenarios included in SmartenIT independent of the used entities and device resources. The activity in this area is mainly conveyed in the external liaison activities with the EU project FLAMINGO.



3.1.7 Large-Scale Measurement of Broadband Performance (LMAP)

Large-Scale Measurement of BroadBand Performance (LMAP) is a new IETF working group since January 2013 aiming at measuring and assuring the bandwidth offered to broadband access users. The goal is to have the measurements for a large number of points on the Internet, and to have the results collected and stored in the same form. The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication:

1. A Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector,

2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages.

LMAP can also build on defined measures and methods introduced by the IP Performance Metrics (IPPM) working group which has been active for more than a decade. Available access bandwidth is a basic QoS parameter that maybe has been neglected in the past in comparison to delay and loss. LMAP measurements are already being set up by regulation bodies, e.g. in Germany in the framework of an initiative for network quality by the Bundes-Netz-Agentur. Therefore tests are have been made available for subscribers via the web site entitled <www.initiative-netzqualitaet.de> on their available bandwidth as well as on net neutrality.


The work is relevant at first for ISPs, but also for cloud, overlay networks created by service providers, since it allows for enabling network wide performance tests involving many clients. In this way a new and broad monitoring mechanism can be established to check QoS parameters of network and service subscribers.


The LMAP working group started with drafts on the framework and use cases, which already have been accepted as working group documents and plans to proceed with drafts on the control and report protocol, data model and for the transport to a collector. WP2 could potentially use the LMAP protocols to run measurements and for modeling purposes provided they get standardized within the SmartenIT time frame, which is unlikely.

3.2 Internet Research Task Force (IRTF)

The Internet Research Task Force (IRTF) is a body controlled by the Internet Architecture Board (IAB) that “promotes research of importance to the evolution of the Internet by creating creates focused, long-term Research Groups (RGs) working on topics related to Internet protocols, applications, architecture, and technology” [2]. The key difference between IRTF research groups and IETF working groups is that IRTF research groups are not meant to produce Internet standards. Therefore, no consensus within research group is needed. At the time of writing, nine research groups are defined, with two of them being relevant to the SmartenIT project, i.e., Software-Defined Networking Research Group



(SDN RG) and Information-Centric Networking Research Group (ICN RG). It is managed by the IRTF chair in consultation with the Internet Research Steering Group (IRSG).

3.2.1 Software-Defined Networking RG (SDN RG)

SDN stands for Software-Defined Networking and is a network architecture framework that promotes the extraction of transport Network Control functions from the network elements to transfer them into programmable Network Control elements, called SDN Controllers, that centralize and coordinate the control decisions of several Network devices. The goal is to optimize modern flexibility demanding applications traffic by interfacing SDN controllers.

In general, the architecture of SDN consists of three layers (see Figure 5): (i) the Infrastructure layer where the real network devices with traffic forwarding functionality resides, (ii) the Control layer containing network intelligence in software-based controllers and (iii) the Application layer.

The Control layer hosts a key element often called “SDN Controller”, which is interfaced with the two other layers.

The open API between the top two layers, also called the “northbound interface”, allows building the applications operating on an abstraction of the network.

The open API between the two bottom layers, also called “southbound interface”, allows the SDN Controller to exchange on resources requests and network state with the infrastructure layer.

Figure 5: The SDN architecture.

Several vendor approaches to implement SDN exist currently and several standardization related bodies investigating it include ITU-T, ETSI and IRTF.

The IRTF Software-Defined Networking Research Group (SDN RG) has been chartered on January, 2013 to “provide a forum for researchers to investigate key and interesting problems in the Software-Defined Networking field”. The charter, see [8], expects that the SDN RG provides objective definitions, metrics and background research with the goal of providing this information as input to protocol, network, and service design to SDOs and other standards producing organizations such as the IETF, ETSI, ATIS, ITU-T, IEEE, ONF, MEF, and DMTF.



An SDN RG contribution exposes the service provider view of SDN in [18]. It is still not known whether SDN RG will liaise with Open Networking Foundation (ONF) or not.

The SDN scheme is one of the use cases of the ALTO WG, see [3] as the latter moves now to optimize virtualized application traffic.


The interest for SDN has been boosted by the growth of virtualized cloud traffic. A key use case for SDN is the automation and addition of flexibility in application networks The SDN advantages in a data center environment are related to the need to sue automation for service provisioning and de-provisioning in a rapid and flexible way. Moreover Data Centers leverage on SDN to create virtualized slices of physical networks. The SDN architecture and standardized access to the network infrastructure can be used for flexible connection configuration addressing various demands. For instance, paths established within and between data centers may be computed in a way that takes into account, among other things, the energy consumption. 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 single-domain deployment or early stage of available implementations), so the adoption of overall SDN approach is still under discussion among SmartenIT consortium.

3.2.1.2 Latest developments

The group is not highly active and it concentrates on the ideas exchange. The topics that have been discussed during IETF 87 and may be interesting to SmartenIT include: motivation for SDN-enabled Internet exchange points, convergence of SDNs in case of MPLS or source-routing environments, and potential cooperation between IRTF SDN RG and IETF Interface to the Routing System (I2RS) working group. The new version of the OpenFlow Switch Specification that was issued in October 14 2013 by the Open Networking Foundation has not been commented by SDN RG.

3.2.2 Information-Centric Networking RG (ICN RG)

Different technologies, typically implemented as an overlay, succeed the classical web based content distribution. Their main goal was to offer improved efficiency employing techniques like caching, replication, promoting a communication model of accessing data by name regardless of origin server. Nevertheless the different technologies use their proprietary information naming scheme.

The ICN RG aims at evolving the Internet infrastructure, moving the focus from nodes to information objects. Information-centric networking (ICN) is an approach to evolve the Internet infrastructure to directly support this use by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling in-network caching and replication.

The main objective of the ICN RG is to couple ongoing ICN research in the above mentioned areas with solutions that are relevant for evolving the Internet at large. ICN may



provide services either on the transport layer or even operate as a packet-level internetworking technology.

The second case would cause fundamental changes to Internet routing while in first case enables new transport strategies such as parallel interaction with multiple caches.

ICN relates in some extent to CDNI, though first is in its research state while second actually refers to real, already working systems. They both share a common goal, trying to optimize end user’s access and some similar use cases as well. One of the ICN RG’s ongoing documents, the “ICN Baseline scenarios” could provide use cases to a wider, CDN’s case included, range of technological areas.

The difference resides in the technical approach. CDN is viewed as a business model for an overlay application with several deployment instances where as the ICN approach aims at integrating overlay stages such as name resolution with underlay operations such as transport or routing. A discussion on relative positioning of CDN and ICN can be found in section 3 of Internet draft called CDNI Advanced Use Cases [29]. Unfortunately this work has been never carried forward since the aforementioned draft has expired.


The relation of ICN and SmartenIT is rather loose; SmartenIT interests have to do more with ICN’s performance optimizations strategies.


The ICN RG focuses on producing a number of relevant documents. Before the last IETF meeting, held in Berlin in July 2013, these documents were the three mentioned below :

• ICN Survey document

• ICN Research challenges

• ICN Baseline scenarios and evaluation methodology

A decision has been made to split the third one to two separate drafts namely the “ICN Baseline scenarios” and “ICN evaluation methodology”.

ICOM contributed to the second one, proposing metrics to be used in comparisons among various ICN proposed approaches and the current internet setup as well. A relative survey document has been produced in the background.

During the 6th ICN RG meeting at IETF87 Berlin that took place in July 2013, a new unofficial draft has been produced, out of individual contributions. It deals with the management of ICN networks. Specifically the way current management tools or frameworks can be adapted. Additionally the possibility to produce a new official 3rd draft, regarding the way existing Internet Protocol Performance Metrics (IPPM) can be used, has been discussed.

3.3 International Telecommunication Union (ITU-T)

The International Telecommunication Union (ITU) is a United Nations specialized agency for information and communication technologies. Within ITU, standards (called Recommendations) are fundamental to the operation of today’s ICT networks. The standardization sector is known under the abbreviation ITU-T, which is subdivided into



study groups, led by a chairman, with different research and standardization focuses. These focuses are further refined by dividing the study groups into Working Parties (WPs) and WPs into Questions, led by « rapporteurs ». Within Questions areas, contributors submit their contributions and periodically meet to discuss and develop these, to later become recommendations or other official documents. Subsequently, SG13’s Question 16 is introduced, as this branch of ITU-T has high relevance for SmartenIT.

3.3.1 SG13 Study Group 13 (SG13) is focused on “Future networks including cloud computing, mobile and next-generation networks (NGN)”. SG13’s Question 16 (Q16/13) focuses on "Environmental and socio-economic sustainability in Future Networks (FN) and early realization of FNs”. As pointed out by ITU-T the motivation of Q16/13 is the following, see [13]: “The previously published recommendation ITU-T Y.3001 has identified environmental and socio-economic awareness as two of the four objectives of FNs. The architectural design, resulting implementation, and operation of FNs should be tailored to minimize environmental impact, such as the consumption of materials and energy and the reduction of greenhouse gas emissions. In addition, it is recommended that FNs also be designed and implemented in such a way that they can be used to reduce the environmental impact of other sectors. FNs are also recommended to consider social and economic issues in order to reduce the barriers to entry for various actors involved in the network ecosystem. It is recommended that FNs consider the need to reduce their lifecycle costs in order for them to be deployable and sustainable. With these objectives in mind, the work to specify the procedure, the use-cases, requirements, properties, and mechanisms of environmental and socio-economic sustainability for FNs technology are the responsibility of this question.”


As SmartenIT aims to improve the communication between clouds, SG13’s focus on cloud computing may allow to channel results achieved within the project through SG13 to ITU-T recommendations at a later point. Also SG13’s focus on mobile networks may allow to channel SmartenIT results on user mobility to ITU-T recommendations.

Q16/13 is in particular relevant, as it focuses on environmental and socio-economic awareness of networks. As one of SmartenIT’s main goals is energy-efficiency this clearly falls within environmental awareness. Also, SmartenIT is aware that its designed technology not only needs to suffice technical demands but also socio-economic interactions of stakeholders, wherefore the socio-economic focus of Q16/13 makes it particularly relevant.

Furthermore, within Q16/13 a recommendation focused on “Economic Incentives of Future Networks” is developed, which will be refered to by its working title « Y.FNsocioeconomic » subsequently. The document introduces tussle analysis, as a mean to develop FN technology that is incentive compatible with different stakeholders. The need to consider “economic and social aspects, such as economic incentives in designing and implementing the requirements, architecture, and protocol of FNs, in order to provide the various participants with a sustainable, competitive environment” is highlighted in Y.FNsocioeconomic. As it was already noted in the SmartenIT DoW, see [34], that tussle analysis is the tool to design traffic management technology that fulfills incentive compatibility, which is inevitable to be successfully adopted in practice, in particular the development of Y.Fnsocioeconomic has high relevance to SmartenIT.




In the ITU-T SG13 study group meeting in February 2013 it was decided to add a section to Y.FNsocioeconomic that explains to ITU members how to best integrate the socio-economic analysis (by the means of tussle analysis) proposed within Y.FNsocioeconomic in the standardization of Future Networks. A main output of the meeting in June 2013 was to generalize this section to explain how the proposed socio-economic analysis can be deployed by standardization bodies in general. A section on “service universalization” which was added in the February meeting to Y.FNsocioeconomic, in order to better comply with ITU recommendation Y.3001 was moved to a separate document during the current meeting, to clearly focus Y.FNsocioeconomic on economic incentives. The now-removed section on service universalization was added to Y.FNsocioeconomic in February, since Y.FNsocioeconomic was started to develop a methodology to better achieve the objective of “social and economic awareness”, which, as pointed out in February, implies, according to Y.3001, not only the design goal of "economic incentives" but also the design goal of “service universalization”. Besides this removal also informative content was removed or moved to the appendix.

3.4 Open Grid Forum (OGF)

The Open Grid Forum is, see [19], a community of users, developers, and vendors leading the global standardization effort for distributed computing (including clusters, grids and clouds). They work to accelerate adoption of grid and cloud computing worldwide because they believe grids will lead to new discoveries, new opportunities, and better business practices. The OGF goal is to translate business and science requirements into best practices and, where appropriate, relevant and timely industry standards that enable interoperability and integration within and across organizational boundaries. The work of OGF is carried out through community-initiated working groups, which develop standards and specifications in cooperation with other leading standards organizations, software vendors, and users. Thus, The OGF standards are specified with special care on compliance for IETF RFCs.

One recent standard issued by OGF that relates to SmartenIT is the Open Cloud Computing Interface, see [21], where it is introduced as follows: “the Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has evolved into an advanced API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to Infrastructure as a Service (IaaS), including Platform as a Service (PaaS) and Software as a Service (SaaS). “

The next sections highlight OGF WGs, see [20], followed by SmartenIT partners.

3.4.1 Network Measurements (NM)

The Network Measurements Working Group [22] provides an extensible encoding standard for network measurement and performance data. It is used for representing network measurements (metrics, measurement results and related meta data) in the XML format. NM has been included and extended by the multi-domain monitoring system



perfSONAR [23] that is developed by the European Union founded project, called „Multi-Gigabit European Research and Education Network and Associated Services” [24], and the US institutions (led by Internet2 [25] and ESnet [26]).


The XML schema for encoding the network metrics defined in NM and implemented by perfSONAR can be useful for SmartenIT and thus will be analysed. The way how the monitoring data are encoded in the XML structures could be followed by the SmartenIT team.

Within the SmartenIT framework it is planned to investigate the relevance of perfSONAR as a source of network monitoring data for the QoS/QoE Analyzer component identified in Deliverable D3.1, see [38].


No developments have been observed since the SmartenIT project started.

3.4.2 Network Measurement and Control (NMC)

The Network Measurement and Control Working Group [27] has created a standardized XML-based protocols to exchange network measurements in the multi-domain network monitoring environments. Together with NM this standard has been implemented in the perfSONAR monitoring system. Due to its flexible structures NMC already has been extended to include a set of experimental functionalities. Some of them has been done within the GN project in the perfSONAR implementation.


SmartenIT can analyze how the message exchange is performed in the perfSONAR system. This may be useful during the work on the communication protocol between the SmartenIT distributed components.

It is planned to investigate the relevance of perfSONAR as a source of network monitoring data for the QoS/QoE Analyzer component identified in Deliverable D3.1, see [38].


No developments have been observed since the SmartenIT project started.

3.4.3 Network Markup Language (NML)

NML stands for Network Markup Language and is an OGF Working group and is defined in [20] as follows: “The purpose of the Network Mark-up Language Working Group is to combine efforts of multiple projects to describe network topologies, so that the outcome is a standardized network description ontology and schema, facilitating interoperability between different projects”.


NML seems to be relevant to SmartenIT because the system architecture of the latter will be distributed and the exchange of topologies is needed to run actions spanning



separated network domains. Also the interfaces between providers of different levels (e.g., an interface between Cloud Provider and Internet Service Provider) will need a common abstracted representation.


The official release of the NML version 1 has been published on 15th September 2013, see [31].

3.4.4 Network Service Interface (NSI)

The Network Service Interface Working Group [28] provides a protocol for the bandwidth on demand (BoD) systems which can offer end-to-end dynamically established circuits in the multi-domain network environment. Independent implementations can communicate with each other to run a network service in a standardized manner. NSI defines in details the information exchange, the required messages and protocols, operational environment, and other relevant aspects. An example of a BoD system supporting NSI is AutoBAHN that is created in the GN project.


SmartenIT can analyze NSI and existing BoD systems, which support the standard, as a network traffic mechanism for establishing connections between cloud resources.


The NSI team works on the XML schema for the NSI message exchange that applies the NML topology description standard.



4 SmartenIT Standardization Background and Strategy This deliverable outlines the standardization plans that have been identified in the SmartenIT consortium throughout the first project year.

- The plans range from follow-up to contribution.

- The contributions involve single partners and groups of partners.

The first sub-section summarizes the involvement type, background and recent achievements of SmartenIT partners in standardization bodies. The second sub-section outlines the standardization WGs in which needs and plans are identified for contributions relating to SmartenIT.

4.1 SmartenIT Partner Involvement in Standardization Bodies

The SmartenIT consortium has a strong background in Standardization and is actively contributing to a number of bodies, in particular those that are boosted by the emergence of high QoE demanding new applications.

• AGH already contributed to the ALTO WG and follows up research groups such as SDNRG.

• ALBLF is contributing the IETF ALTO WG and proposes protocol extensions, while following up the SDNRG SDN and CDNI and their relation of ALTO.

• ICOM remains active both in IETF and IRTF communities, namely IETF’s ALTO and IRTF’s ICN and CDNI groups, mainly through its contribution to the preparation of relevant drafts.

• PSNC is following the described OGF groups and has contributed to the recently released NML version 1 has been published on 15th September 2013.

• TDG follows IETF groups such as ALTO, CDNI for content overlay optimization, MIF and MPTCP, RMCAT for related transport issues and LMAP for standardized network performance assessment.

• UZH contributes to the described ITU groups on socio-economical and to the IETF CoRE WG on authentication issues.

Table 1 lists, for the previously described bodies, the partner involvement type and contributions.

Table 1: Summary of SmartenIT partner involvement and contributions

Standardization

Body

Involved partner Type of involvement

ICOM

Already contributed to Internet Draft’s ALTO Feedback-Based Client Protocol.

ALTO

AGH Follow up & contribution

Already contributed draft-dulinski-alto-inter-alto-protocol-00 and draft-dulinski-alto-inter-



problem-statement-01

ALBLF Contribution

Base Protocol draft reviews

Individual drafts review

Last drafts presented to the WG:

- «Multi-Cost ALTO», S. Randriamasy (editor) and W. Roome and N. Schwan, IETF draft draft-randriamasy-alto-multi-cost-07, October 19th 2012,

- “ALTO Cost Schedule”, S. Randriamasy (editor) and N. Schwan, IETF draft draft-randriamasy-alto-cost-schedule-02, October 19th 2012,

ICOM Already contributed to Internet Draft’s “draft-fmn-cdni-advanced-use-cases-00” chapter 3 (Relationship between CDNI and Information Centric Networking).This draft, though kept separate complements the “draft_ietf_cdni_use_cases” Internet Draft with a catalogue of advanced, longer term cdn interconnection use cases

CDNI

AGH, ALBLF Follow up

IRTF-ICN ICOM Already contributed to ICN Baseline Scenarios Internet Draft, providing chapter 3.3 related to traffic and system metrics

IRTF-SDN AGH, ALBLF Follow up

MIF TDG Follow up

MPTCP TDG Follow up

RMCAT TDG Follow up

LMAP TDG Follow up

SG13 UZH The development of the Y.FNsocioeconomic document began within Q21/13 in 2011 and was adopted by ITU-T’s Q16/13 in February 2013 due to UZH efforts.

IETF CoRE UZH Published draft titled “DTLS-based Security with two-way Authentication for IoT” as version 00 (draft-schmitt-two-way-authentication-for-iot-00>)

NM PSNC Active member. WG currently inactive



NMC PSNC Active member. WG currently inactive

NML PSNC Active member. Involved in NML specification version 1.

NSI PSNC Follow-up

4.2 Standardization Plans per Standardization Group

This section presents the standardization objectives of SmartenIT partners, as individuals or as a consortium group and related to the project. For each objective, it lists:

• The extension item, to be proposed in a standardization group, its definition and motivation;

• The challenge to its acceptance by the body, that is the degree of traction or reluctance, political constraints and issues in the body as well as potential timeline factors.

• The SmartenIT partners to be involved.

4.2.1 IETF – ALTO WG

Extension item: ALTO datacenter/cloud use cases

- Motivation: ALTO specifies the rules of communication between an ALTO server, deployed by a network operator and an ALTO client using the operator services, in order to exchange useful information/suggestions aiming to jointly optimize the performance of an overlay network. The only overlay networks considered are p2p and CDN. ALTO protocol extensions to support clouds and datacenters use cases as well, can be used to realize the interface between SmartenIT Cloud overlay manager-Cloud Traffic manager, as depicted in the initial SmartenIT System architecture, facilitating thus the information/directive flow between these two managing components.

- Challenges: The term Cloud is avoided in the ALTO WG due to its commercial flavor. So special care will be needed to avoid terms such as Cloud. Contributions should rather be positioned w.r.t. virtualization and the use cases of ALTO for Data Centers that have been published in the WG.

- Partners: AGH, ALBLF, ICOM

Extension item: Inter-ALTO standardization (including push & pull updates)

- Motivation: The ALTO protocol itself is used for communication between ALTO servers and ALTO software components at client side. However, locally available information may be insufficient for effective traffic management. Some information that can be used for the better traffic management, is not available in the local AS and must be obtained from outside, i.e., from a remote AS. It was a motivation for considering information exchange between remote ALTO servers operated by different ISPs. It is assumed that those ISPs collaborate and agreed to exchange some useful information. The components of solutions developed by SmartenIT may require more information about the network state than a single ISP can provide.

- Challenge: As stated in [4], “It may also be possible for an ALTO Server to exchange network information with other ALTO Servers (either within the same administrative



domain or another administrative domain with the consent of both parties) in order to adjust exported ALTO Information. Such a protocol is also outside of the scope of this [ALTO] specification”. However, an inter-ALTO communication protocol may require specific extensions. The challenge for SmartenIT will be to: provide acceptable protocol extensions and use cases to the ALTO WG and address previous WG objections suggesting instead solutions such as BGP-LS.

- Partners: AGH, ALBLF, ICOM

Extension item: extension of ALTO cost information

- Motivation: The necessity of incentive compatibility between users and networks, of supporting bulk traffic over challenged networks for CDN and Cloud applications with a customer attractive QoE, stress the need to extend selection metrics beyond the scope of the base ALTO protocol. Existing proposals to extend the ALTO cost information in terms of metrics, time and qualitative criteria can well support the SmartenIT ALTO-based application endpoint monitoring and selection mechanisms.

- Challenge: complete existing use cases for extension proposals

- Partners: ALBLF

4.2.2 IETF – CDNI WG

Extension item: requirements, framework, metadata interface etc. (especially in the context of inter-cloud communication).

- Motivation: The approaches employed by CDNI to interconnect CDNs and exchange data between them may be coherent to the SmartenIT’s view on the inter-cloud communications. In that case, SmartenIT should contribute to CDNI to make its requirements, interfaces, and protocols suitable for the project.

- Challenge: Long tail personalized content not amenable to caching, combined with heavilly asymmetric usage of the network between peak and quiet hours, create unique bandwidth challenges across CDNI.

- Partners: ICOM, AGH

4.2.3 IRTF – SDN RG

Extension item: SDN inter-domain use cases (IRTF SDN RG), Software Defined Networking Research Group) Network/service description languages, abstractions, and interfaces Inter-layer communication.

- Motivation: SDN is a protocol specifying how to run a controller that can install low-level packet-handling rules in the underlying switches and run various network-management applications, such as traffic engineering, server load balancing, energy-efficient networking, and so on. All these functionalities take place in a single domain scope. Such a controller would be the SmartenIT box (S-box) and such network-management applications should run in parallel and coordination in two or more peer, interconnected s-boxes realizing the Inter-S-Box communication (D3.1 Figure 33 initial SmartenIT System architecture, see [38]). The obvious extension needed would be for the SDN to operate in inter-domain use cases with the two aforementioned S-boxes belonging to separate administrative domains/ISPs.



- Challenge: Inter-domain SDN is still in an exploration phase and faces almost all challenges of general inter-domain routing. The challenge is to define a inter S-Box communication protocol supporting coordinated decisions of their hosted SDN Controllers.

- Partners: PSNC,ALBLF,ICOM,AGH

4.2.4 IETF – CoRE WG

Extension Item: Standard based solution for many application scenarios and device diversity.

- Motivation: Since April 2013 UZH started the investigations of the possibility to bring Datagram Transport Layer Security (DTLS) to constraint devices and to support a two-way authenticated handshake in order to solve security problem occurring when data is transmitted through the Internet. This case investigates security question concerning authentication and authorization whenever data is published or an entity subscribes to data. The investigations are done in cooperation with the external liaisons FLAMINGO looking on cached data and access regulations due to legal implications.

UZH is in the process to specify hardware and message workflow requirements, which brings the relevant level of trust into the network for upcoming communications between any two stakeholders. Therefore, UZH deals with the following research and standardization aspects:

• DTLS-based two-way authentication handshake using User Datagram Protocol (UDP)

• Authentication of each stakeholder

• Certificate Authority for creating certificates

• Trusted Platform Module (TPM) inclusion for building chain of trust

The currently active IETF groups have not focused on Authentication and Authorization issues so far, especially not including stakeholders and TPM technology.

UZH is currently working on a second version of the draft presented at IETF 87 in Berlin, specifying application scenario and more requirements. In order to publish it for IETF 88 in November 2013. The published draft was grouped in working group CoRE building a new subgroup called Authentication & Authorization (AA), where other groups dealing with the same questions from University of Bremen, University of Oulu (Finland), and Ericsson are participating.

- Challenges: Development of a standard based solution, which is applicable to different kind of devices and applications.

- Partners: UZH

4.2.5 ITU-T – SG13

Extension item: Y.FNsocioeconomic

Motivation: By the exchange with other SG13 participants, which are experts from the industrial, academic, and regulative field, SmartenIT’s efforts regarding the development of Y.FNsocioeconic will deepen the understanding of FN technology and tussle analysis,



which is an important tool for the technology development within SmartenIT. Therefore, this efforts within ITU-T will aid the development of SmartenIT technology with respect to socio-economic sustainability. Furthermore, these interactions may constitute a starting point to channel technical SmartenIT research to ITU-T recommendations.

Challenge: The next editorial iteration for Y.FNsocioecomic will happen during SG13 Rapporteur meeting in November 4-15, 2013, where UZH will again contribute to the development of Y.Fnsocioeconomic.

Partners: UZH



5 Conclusions

This deliverable describes the relationship between SmartenIT project and standardization bodies. SmartenIT highlights modern use cases that stress the need to impact bodies related to overlay traffic management and optimization, security and robustness in transmission paths, reliable performance measurements and socioeconomic aspects.

The set of bodies exposed in this document appears to match with a number of emerging standardization groups that are boosted by the same reasons than the ones motivating SmartenIT. This is the case for working and research groups such as ALTO, CDNI, ICNRG, SDNRG, SG13, and NMC, closely connected to the SmartenIT objectives.

Legacy related standardization groups such as MPTCP, MIF, RMCAT, NSI and NML remain crucial precisely because the gear of network used towards resources greedy and highly unpredictable traffic bursts poses challenges to the transport network topology and stress the need to augment its control protocols.

Concerns on user security and experience and network performances addressed in bodies such as LMAP, CoRE, NM and NMC are considered as well in SmartenIT that tend to augment the role of users in the application set ups.

On top of that most of the applications considered in SmartenIT involve end systems located in wireless networks living on scarce resources. This deliverable does not report on standardization bodies such as 3GPP as the latter is not involved in overlay traffic management and limits its decision scope to the access layer and network. IETF bodies on the other hand do consider wireless use cases and extend their scope beyond the access network and layer.

Future work will focus on the following groups with involvement ranging from follow up to contributions. The outcomes will be reported in deliverable 5.3. Follow up is crucial as the SmartenIT traffic management mechanisms and architecture must either be compliant to relevant standards or lead to standard extension proposals. It is important to remind that the T5.2 standardization commitments limit the planned contribution in bodies to proposals. Indeed, getting proposals adopted as standards usually takes more time than the duration left for a project. Instead, SmartenIT provides use cases that highlight the benefits on new and ongoing standard contributions that may get adopted within the duration of the project.



6 References Note that all the referenced Web Pages were visited latest in September 2013

[1] Internet Engineering Task Force (IETF) home page, http://www.ietf.org/

[2] Internet Research Task Force (IRTF) home page, http://irtf.org/

[3] IETF working group on Application Layer Traffic Optimization (ALTO), <tools.ietf.org/wg/alto/charters> and Status Pages http://tools.ietf.org/wg/alto/

[4] R. Alimi, R. Penno, Y. Yang: ALTO Protocol, draft-ietf-alto-protocol-20.txt (work in progress), October 2013, see http://tools.ietf.org/wg/alto/draft-ietf-alto-protocol/

[5] «Multi-Cost ALTO», S. Randriamasy (editor) and W. Roome and N. Schwan, draft draft-randriamasy-alto-multi-cost-07, October 19th 2012, http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07

[6] IETF working group on CDN interconnection (CDNI) <tools.ietf.org/wg/cdni/charters>

[7] IETF working group on HTTPbis <tools.ietf.org/wg/httpbis/charters>

[8] “Software Defined Networking Research Group” http://irtf.org/sdnrg

[9] R. Fielding et al., Hypertext transfer protocol - HTTP/1.1, Request for Comments 2616 <www.rfc-editor.org/rfc/rfc2616.txt> (2000)

[10] R. Fielding et al., Hypertext transfer protocol HTTP/1.1: Caching, Internet-Draft, work in progr. <tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22> (2013)

[11] S. Floyd et al., “IAB Thoughts on the Role of the Internet Research Task Force (IRTF).” RFC 4440, March 2006.

[12] B. Niven-Jenkins et al., “Content Distribution Network Interconnection (CDNI) Problem Statement”, IETF Request for Comments 6707, September 2012

[13] ITU Homepage, http://www.itu.int

[14] A.-J. Su, D.R. Choffnes, A. Kuzmanovic and F.E. Bustamante, Drafting behind Akamai, IEEE/ACM Trans. on Networking 17 (2009) 1752–1765

[15] B. Wong, A. Slivkins and E.G. Sirer, Meridian: A lightweight network location service without virtual coordinates, Proc. ACM Sigcomm, Philadelphia, USA (2005)

[16] H. Xie et al., P4P: Provider Portal for Applications, Proc. ACM Sigcomm, Seattle, USA (2008)

[17] H. Yu, G. Shi, J. Chen, X. Weng and W. Zheng, Towards a better understanding of locality-awareness in P2P systems, Grid and distributed computing, Communications in computer and information sciences 63 (2009) 41-48.

[18] M. Boucadair, C. Jacquenet, “Software-Defined Networking: A Service Provider's Perspective”, IRTF Contribution draft-sin-sdnrg-sdn-approach-03, June 5 2013

[19] “Open Grid Forum Overview” http://www.ogf.org/About/abt_overview.php

[20] “OGF areas and groups” http://www.ogf.org/gf/group_info/view.php?group=nml-wg

[21] “Open Cloud Computing Interface - RESTful HTTP Rendering”, GFD-P-R.185, OCCI WG, June 21, 2011, http://www.ogf.org/documents/GFD.185.pdf.



[22] “Network Measurements Working Group (NM-WG)”, http://www.ogf.org/gf/group_info/view.php?group=nm-wg

[23] “perfSONAR”, http://www.perfsonar.net/

[24] “GEANT”, http://geant3.archive.geant.net

[25] “Internet2”, http://www.internet2.edu/

[26] “ESnet – Energy Science network”, http://www.es.net/

[27] “Network Measurement and Control WG (NMC-WG)” http://www.ogf.org/gf/group_info/view.php?group=nmc-wg

[28] “Network Service Interface WG (NSI-WG)”, http://www.ogf.org/gf/group_info/view.php?group=nsi-wg

[29] “Catalog of Advanced Use Cases for Content Delivery Network Interconnection”, http://tools.ietf.org/id/draft-fmn-cdni-advanced-use-cases-00.txt

[30] M. Stiemerling, S. Kiesel, S. Previdi, M. Scharf, “ALTO Deployment Considerations”, draft-ietf-alto-deployments-07, July 15th 2013, http://tools.ietf.org/wg/alto/draft-ietf-alto-deployments/

[31] GFD-R-P.206 "Network Markup Language Base Schema version 1" J. vd. Ham, F. Dijkstra, R. Łapacz, J. Zurawski, via NML-WG, http://www.ogf.org/documents/GFD.206.pdf

[32] Corinna Schmitt, Burkhard Stiller, Thomas Kothmayr, W. Hu: DTLS-based Security with two-way Authentication for IoT; IETF, online, Berlin, Germany, July 2013, URL: http://www.ietf.org/id/draft-schmitt-two-way-authentication-for-iot-00.txt

[33] IETF working group on Constrained RESTful Environments (CoRE), https://datatracker.ietf.org/wg/core/charter/

[34] The SmartenIT project: Grant Agreement for STREP: Annex I'Description of Work (DoW)'; 2012

[35] Web page of “WhoIs”, see www.pwhois.org, no concrete report or documentation available

[36] The SmartenIT project: Deliverable D5.1 - Dissemination, External Liaisons Plan, and Initial Exploitation Plan; January 2013.

[37] The SmartenIT project: Deliverable D2.2 - Report on Definitions of Traffic Management Mechanisms and Initial Evaluation Results; October 2013.

[38] The SmartenIT project: Deliverable D3.1 - Report on initial system architecture; March 2013.

[39] Web page of “Closest Node”, see www.closestnode.com, no concrete report or documentation available

[40] L. Peterson, B. Davie, “Framework for CDN Interconnection”, draft-ietf-cdni-framework-05, September 09, 2013, http://tools.ietf.org/html/draft-ietf-cdni-framework-05

[41] B. Niven-Jenkins, F. Le Faucheur, N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", IETF RFC6707, September 2012, http://tools.ietf.org/html/rfc6707



[42] G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson, "Use Cases for Content Delivery Network Interconnection", IETF RFC6770, November 2012, http://tools.ietf.org/html/rfc6770



7 Abbreviations 3GPP 3rd Generation Partnership Project

AA Authentication, Authorization

AAA Authentication, Authorization, Accounting

ALTO Application Layer Traffic Optimization

AS Autonomous System

BoD Bandwidth on Demand

CDN Content Delivery Network(ing)

CDNI Content Delivery Networks Interconnection

CoRE Constraint RESTful Environments

DNS Domain Name Server

DHCP Dynamic Host Configuration Protocol

DTLS Datagram Transport Layer Security

FN Future Network

ICN RG Information Centric Networking RG

IaaS Infrastructure as a Service

IETF Internet Engineering Task Force

IESG Internet Engineering Steering Group

IPPM IP Performance Metrics

IRTF Internet Research Task Force

IRSG Internet Research Steering Group

ISP Internet Service Provider

ITU International Telecommunication Union

LMAP Large Scale Measurement of Broadband Performance

MIF Multiple InterFaces

NAT Network Address Translation

NGN Next Generation Network

NM Network Measurement

NMC Network Measurement And Control

NML Network Markup Language

MPTCP MultiPath TCP

NO Network Operator

NSI Network Service Interface

OGF Open Grid Forum



ONF Open Networking Foundation

PaaS Platform as a Service

RFC Request For Comments

RG Research Group

RMCAT RTP Media Congestion Avoidance Techniques

RTC-Web Real Time Communication/Collaboration on the World Wide Web

RTP Real Time Protocol

SDN RG Software Defined Networking RG

SaaS Software as a Service

SmoothIT Simple Economic Management Approaches of Overlay Traffic in Heterogeneous Internet Topologies

STREP Specific Targeted Research Project

SUN Smart Ubiquitous Networks

UDP User Datagram Protocol

WG Working Group

8 Acknowledgements This deliverable was made possible due to the large and open help of the WP5 team of the SmartenIT team within this STREP. Many thanks to all of them. Special thanks go to the reviewers Paolo Cruschelli and Tobias Hoßfeld for detailed revisions and valuable comments.

deliverable d5.2 standardization survey

Documents

sabine randriamasy v0

uzh v0

strategy v0

icn section v0

sabine randriamasy email

smartenit project

internal review v0

irtf definlitions update