WP1 Requirements and Architecture for Green Information Delivery

Objectives

The objective of WP1 is the identification of use scenarios and requirements and the definition of the GreenICN architecture, which will be used by other WPs as the reference for working out the solutions for the emerging applications. The activity will start with the identification of target scenarios and requirements, and will be phased over the whole project lifetime, in order to incorporate the results, and any relevant technical feedback, coming from the other WPs.

To be more specific:

• Identification of requirements on the target GreenICN applications scenarios, considering both the user device’s and the network operator’s perspectives.
• Identification of requirements of GreenICN networks and end-systems, as well as energy consumption models (based on which energy reduction is estimated in GreenICN use scenarios).
• Design of the overall GreenICN architecture, including the building blocks for energy-efficient ICN networking, the relationships between involved elements, as well as API.
• Design of viable solutions for congestion priority control, naming, routing and mobility support from both user devices and network devices’ perspectives.

WP1 includes the identification of GreenICN use scenarios and requirements (T1.1), and the design of end-device architecture and APIs which exploits GreenICN services (T1.2); it also includes the design of key network elements enabling information delivery through GreenICN, including routing and forwarding strategies (T1.3), as well as traffic and resource control (T1.4).

Expected Results

• GreenICN scenarios and requirements
• Application level API specification
• Middleware specification
• Network level API specification
• Network level functionality specification
• Specification of routing and forwarding schemes
• Specification of traffic and resource control schemes

Task 1.1 Use scenarios and requirements [leader: UGO/UOS]

Summary of Y1

Use-scenarios:

A large and thoroughly detailed number of concrete scenarios are reported as part of this task. The associated deliverable (D1.1.1a) describes realistic, typical scenes of our daily digital life and digitally-mediated social relationships (exchanging messages and promoting activities among friends and people interested in similar things, entertaining together, commuting for work and traveling) and shifts the readers’ point of view by depicting negative impact on these scenarios caused by sudden or inevitable events which affect (a) the underlying communication network’s performance and (b) the energy/battery level of devices needed to communicate. The use scenarios we depict here try to span a wide coverage of these aspects, report them in a coherent way, list associated challenges and put them in technical perspective, in order to derive requirements and design strategies.

The effort we spent on the analysis the readers will find hereby enclosed is of the outmost importance for the project, and the level of detail of the descriptions reflects it, and has been (and continues to be) key enabler for a well-specified set of requirements and a coherent, innovative GreenICN  architecture.

Parts of this work is being used for the IETF draft named „Using ICN in Disaster Scenarios“ submitted to the IRTG ICNRG Working Group.

Requirements:

The deliverable that was the output of this work (D1.1.1b) lists the application specific requirements that were derived from the above disaster and video use-scenarios. The resulting middleware and network layer requirements are then presented and finally the requirements for energy efficiency are listed. The requirements deal with the need for a name-to-name API, access control, and notifications from the lower layers as well as the networks, how peers could interact with each other, how the information could be packaged, rights management, application layer pub/sub, energy efficient bit stream encoding, migration, pub/sub, security, routing, resilience, caching, prioritization, mobility, and network management.

Additionally, as part of this work, we present energy consumption models for an individual ICN router and an overall network that consists of ICN routers. These models are used to evaluate whether the GreenICN architecture satisfies the energy requirements.

This deliverable is a collection point for all the requirements and will therefore be further improved based on feedback received from implementations, demonstrations, the research and standardization communities as well as the reviewers.

Architecture (Internames):

In this project, we propose Internames, an architectural framework in which names are used to identify all entities involved in communication: content, users, devices, logical as well as physical points involved in the communication, and services. By not having a static binding between the name of a communication entity and its current location, we allow entities to be mobile, enable them to be reached by any of a number of basic communication primitives, enable communication to span networks with different technologies and allow for disconnected operation. Furthermore, with the ability to communicate between names, the communication path can be dynamically bound to any of a number of end-points, and the end-points (both source and destination) themselves could change as needed. A key benefit of our architecture is its ability to accommodate the gradual migration from the current IP infrastructure to a future that may be a ubiquitous Information Centric Network (ICN). Basic building blocks of Internames are: i) a name-based Application Programming Interface; ii) a separation of identifiers (names) and locators (addresses); iii) a powerful Name Resolution Service (NRS) that dynamically maps names to locators, as a function of time/location/context/service; iv) a built-in capacity of evolution, allowing a transparent migration from current networks, with the ability to coexist with current architectures. To achieve this vision, we exploit and expand on Information Centric Networking principles, extending ICN functionality beyond content retrieval, and make it easy to include send-to-name and push services, and allowing the use of names to route data in the return path. A key role in this architecture is played by the NRS, which allows for the co-existence of multiple network “realms”, including current IP and non-IP networks, glued together by an overarching name-to-name communication primitive.

Moreover, as part of this task, we highlight the benefits of ICN in terms of energy efficiency with the help of use cases.

We would like to note that the work on Internames titled “Internames: a name-to- name principle for 5G networks” is currently under submission for the Special issue on 5G Networks: End-to-end Architecture and Infrastructure, IEEE Communications Magazine. The Internames work is also currently under submission for the EUCNC Poster session. Moreover, the work on ICN’s energy efficiency will be published as a book chapter titled “Information Centric Networking: The Case For An Energy Efficient Future Internet Architecture”, Book on Green Communication, Wiley, to be published in late 2014.

 

Summary of Y2

Use-scenarios:  A large and thoroughly detailed number of concrete scenarios are reported as part of this task. The associated deliverable (D1.1.2a) describes realistic, typical scenes of our daily digital life and digitally-mediated social relationships (exchanging messages and promoting activities among friends and people interested in similar things, entertaining together, commuting for work and traveling) and shifts the readers’ point of view by depicting negative impact on these scenarios caused by sudden or inevitable events which affect (a) the underlying communication network’s performance and (b) the energy/battery level of devices needed to communicate. The use scenarios we depict here try to span a wide coverage of these aspects, report them in a coherent way, list associated challenges and put them in technical perspective, in order to derive requirements and design strategies. In Y2, we also identified a new use-scenario –service chaining in SDN – that allows us to make the design of ICN more generic. The effort we spent on the analysis the readers will find hereby enclosed is of the outmost importance for the project, and the level of detail of the descriptions reflects it, and has been (and continues to be) key enabler for a well-specified set of requirements and a coherent, innovative GreenICN  architecture.

Requirements: The deliverable that was the output of this work (D1.1.2b) lists the application specific requirements that were derived from the above disaster and video use-scenarios. The resulting middleware and network layer requirements are then presented and finally the requirements for energy efficiency are listed. The requirements deal with the need for access control, notifications from the lower layers as well as the networks, how peers could interact with each other, how the information could be packaged, rights management, application layer pub/sub, energy efficient bit stream encoding, migration, pub/sub, security, routing, resilience, caching, prioritization, mobility, and network management.   Additionally, this deliverable presents energy consumption models for an individual ICN router and an overall network that consists of ICN routers. These models are used to evaluate whether the GreenICN architecture satisfies the energy requirements.  This deliverable is a collection point for all the requirements and will therefore be further improved based on feedback received from implementations, demonstrations, the research and standardization communities as well as the reviewers.

Big-Picture and Energy: The deliverable that was the output of this work (D1.1.2c) describes the GreenICN “Big-Picture” and energy considerations. The Big-Picture presents the motivation of GreenICN and how the aim is to improve NDN/CCN in key areas such as energy efficiency, function in disaster scenarios (fragmented/disconnected operations, pub/sub: interest for something published in the future: useful to receive early warnings) and video scenarios (pub/sub for video, mobility and migration). We also present a new use-scenario –service chaining– and GreenICN’s node architecture. We also present “Server assisted” architectural enhancements that we proposed to support the ICN/NDN architecture such as Internames: a name-to-name communication Model and Orice: an Object Resolution Service. In the Energy part, we argue that energy optimization techniques applied on the current Internet infrastructure will not result in orders of magnitude increase in energy efficiency due to the limitations posed by the design. Furthermore, we argue for the need to consider the possibility of deploying future Internet architectures, namely Information Centric Networking. We then attempt to answer the question “Does caching really reduce the energy consumption of the entire network?”.

 

Summary of Y3

Use-scenarios:  There were no changes made to the use-scenarios finalized in Y2. We would like to note that part of the disaster use-scenarios were adopted as IRTF ICNRG working group document [1].

Requirements: There were no changes to the requirements finalized in Y2.

Big-Picture and Energy: The deliverable that was the output of this work (D1.1.3c) includes an image that shows how all the various solutions fit into the “Big Picture” along with the layer t which they belong. The section on object resolution is further enhanced with the camera ready version of the work accepted in the LANMAN workshop 2015.  We further separated the energy related work and created a new deliverable (D1.1.3d) for it.

New Section 1.1.3d:  We created a new deliverable D1.1.3d and moved all the energy related work to this deliverables. The sections related to energy from D1.1.2b and D1.1.2c is moved to this deliverable. This deliverable has been divided into two main parts: a summary of all the energy related work in GreenICN project and the work focused on caching for reducing energy consumption in ICN networks. A new section is added summarizing all the energy reduction solutions in the project. The energy consumption model of the ICN router is revised to handle energy optimization techniques. Section on efficient caching computation is added and section on analysis of energy reduction is revised.

Summary of work done

D1.1.3c

• We added an image in the section 2.5 to show how all the different solutions fit together in the Big Picture
• We improved the object resolution section with the published version
• Moved the energy related work to a separate deliverable D1.1.3d

D1.1.3d

• New sections added on energy reduction solutions
• Revised energy consumption model of ICN routers
• New section on efficient caching computation
• Revised section on analysis of energy reduction

Task 1.2 End Systems and APIs [leader: CED/PAN]

Summary of Y1

These are the activities carried out during the first year:

1. Defined the High-level (application) API based on the Managed advertising for real estate use case of D1.1v1.
2. Defined the GreenICN end-system architecture based on the MPEG-M architecture and the middleware. The functionalities of the middleware are already quite wide, but more will be added as needed in the following years.
3. Developed and submitted to MPEG first ideas for a GreenTech Engine as a proposal. The proposal has been accepted and GreenTech API are being developed with the group developing the Green Metadata standard (Samsung, Technicolor etc.).
4. Specified Low Level Energy saving API
5. Specified DASH (Dynamic Adaptive Streaming over HTTP) for use in the GreenICN End System (implemented in the Media Framework Engine used in the demo set up of D4.1.1)
6. Specified DRM (Digital Right Management) of MPEG DASH (implemented in the Security Engine used in the demo set up of D4.1.1)
7. Specified privacy-enhancing content-based publish/subscribe payload formats and implemented semantic search in the Metadata Engine used in the demo set up of D4.1.1
8. Submitted a proposal for a privacy-enhancing content-based Publish/Subscribe Application Format to standardisation. This has been accepted and a preliminary Working Draft produced and made publicly available. Several areas for further investigation have been identified

It is to be noted that several of the functionalities that relate to implementation of the above have been reported in D4.1.1.

Summary of Y2

The D1.2.2 deliverable is the intermediate specification of architecture and components of GreenICN End Systems (a.k.a. Peer), devices that enable access to GreenICN resources. It builds on the specification dated 2014/03/31 and titled “D1.2.1: Initial end-system technology and API / middleware specification” and is tightly connected to the D4.1.2 deliverable “Intermediate version of prototype devices and related description”, a partial implementation of D1.2.2.

The following specifications are included in this deliverable:

1. Revised GreenICN End System architecture: a 3-layer architecture that includes Application, Middleware and Computing Platform;
2. New GreenICN Applications, in particular the Publish/Subscribe application based on the PSAF standard;
3. Updated APIs exposed by Middleware to Application (High Level API) and by Computing Platform to Middleware (Low Level API);
4. Updated and New Engines (Middleware components) that expose Middleware API to Applications (Middleware Engine API are specified in D4.1.2), in particular GreenTech, Contract Expression and User Description;
5. New Engine-based Middleware compatible Monolithic Middleware (i.e. non Engine-based).

 

Summary of Y3

The D1.2.2 deliverable is the intermediate specification of architecture and components of GreenICN End Systems (a.k.a. Peer), devices that enable access to GreenICN resources. It builds on the specification dated 2014/03/31 and titled “D1.2.1: Initial end-system technology and API / middleware specification” and is tightly connected to the D4.1.2 deliverable “Intermediate version of prototype devices and related description”, a partial implementation of D1.2.2.

GreenICN Task 1.2 End Systems and APIs has completed the specification of the End System (Peer) Architecture with well defined

1. Components: Application, Middleware, Network and Computing Platform;
2. API: High Level API, Network API and Low Level API.

In particular it has completed the specification of

1. High Level API which expose a set of high level methods for Applications to call;
2. Monolithic Middleware (MMW) which is functionally equivalent to MXM, is less computing and memory demanding, more energy efficient, potentially portable to all platforms, exposes the same High Level API as MXM but has reduced flexibility compared to MXM
3. Low Level API which are called by the Middleware e.g., to call local computing resources, get energy information, request security functionalities and access Face;

The specification is the result of integration of existing standards, project research and experimentation results, which have produced a range of results submitted to standardisation:

 

GreenICN architecture	ISO/IEC 23006-1 – Multimedia Service Platform Technologies (MPEG-M) – Architecture (currently at Final Draft International Standard (FDIS) stage);
GreenICN High Level API	Additional normative components of 3rd edition of MPEG-M Architecture (currently at Draft International Standard (DIS) stage);
GreenICN Engine-based Middleware	ISO/IEC 23006-2 MPEG Extensible Middleware (MXM), currently at Final Draft International Standard (FDIS) stage, awaiting publication.
Green Metadata API	ISO/IEC 23001-11 Green Metadata, currently at International Standard (IS) stage;
GreenICN Engine-based Middleware	ISO/IEC 23006-3 Ref­erence Software and Conformance, currently at Final Draft International Standard (FDIS) stage, awaiting publication;
GreenICN PubSub	ISO/IEC 23000-16 Publish/Subscribe Application Format (PSAF), currently at Final Draft International Standard (FDIS) stage;
Support general business relation­ships in PSAF	ISO/IEC 21000-20 Contract Expression Language and ISO/IEC 21000-21 Media Contract Ontology, both at International Standard (IS) stage, 1st edition of ISO/IEC 21000-22 User Description, currently at Final Draft International Standard (FDIS) stage

 

Task 1.3 Routing and Forwarding Strategies [leader: NEE/KDD]

Task objective

This task is responsible for the design of the routing, forwarding, naming, mobility and the overall GreenICN node architecture for green information delivery networking. The architecture should support both general (video sharing for non-disaster) scenarios and disaster scenarios (e.g., rescue information and video delivery for disaster management).

Summary of Y1

The main part of the work done on routing and forwarding, naming and energy-efficiency within GreenICN Year 1 concerns the overall architecture, which is described in detail in Task 1.1. Initially, this task and deliverable was supposed to serve as the overall architecture document, but for ease of identification and to allow Task 1 to serve as the collection point, we have created an extra deliverable D1.1.1c titled “Initial GreenICN Architecture” in Task 1.1. Moreover, the energy consumption model is available as part of deliverable D1.1.1b titled “Initial GreenICN Requirements” in Task 1.1 and a general introduction into how ICN can provide energy efficiency is presented in D1.1.1c titled “Initial GreenICN Architecture”’ in Task 1.1.

This task contains routing and forwarding components as core concepts (i.e. network-realms, Routing Resolution Service (RRS)), and a high-level design of these components has been done (e.g. the high-level API for input/output of the RRS has been specified). A high-level overview of the routing and forwarding components as part of the GreenICN architecture have been provided, along with a high-level explanation of how in principle intra-realm as well as inter-realm routing and forwarding are envisioned to take place within/between different network-realms in the GreenICN Internames architecture.

The work on CNS demonstrates the benefit brought by a pub/sub system for an efficient notification service, including the convenience of hierarchical name based group management, network efficiency and timeliness in delivering the notification. The work also demonstrated a simple first-step authorization.

In addition, a concrete scheme for improving routing in a CCNx-based network-realm has been designed and evaluated. The proposed scheme for an efficient lookup scheme for CCN-based

network-realms in a large FIB can reduce the scale of FIB by exploiting the information on the longest matching prefix length in the previous hop. We have also discussed the benefits of our efficient FIB lookup scheme, in comparison to a conventional FIB lookup scheme, and have found that our proposed scheme significantly improves FIB lookup latency with a reasonable parameter settings observed in today’s Internet.

Further, highly decentralised schemes for mobility and routing in fragmented networks have been designed and evaluated; these schemes are described in detail in GreenICN deliverable D2.2.1 Furthermore, mobility support related studies are ongoing in WP3 as part of the video application.

We note that “CNS: A Content-centric Notification Service” has been demonstrated as the IEEE ICNP Conference in the demonstration session, October 2013. Moreover, “Efficient lookup scheme for Non-Aggregatable name prefixes and its evaluation” has been published in the IEICE Transactions on Communications, vol.E96-B, no.12, December 2013. The work on Internames in currently under submission for the EUCNC Poster session and a special edition of the IEEE Communications Magazine.

 

Summary of Y2

In Year-2, we proposed an enhancement to ICN, to improve flexibility for — service chaining — in an SDN environment. The proposed solution “Function-Centric Service Chaining”, exploits ICN to provide flexibility in managing networks that utilize virtualization to dynamically place functions in the network as required. This work deals with an efficient routing and forwarding mechanism for packets via a set of middleboxes/service-nodes.

Also in Year-2, we have proposed a first node architecture as extension to the CCNx core, with a focus on group communication in disasters. The design of the overall scheme is contained in D2.1.2. Further, highly decentralised schemes for mobility and routing in fragmented networks have been designed and evaluated; these schemes are described in detail in GreenICN deliverable D2.2.2.

Furthermore, mobility support related studies are ongoing in WP3 as part of the video application.

Summary of Y3

In Year-3, several new techniques are developed. A study on naming schemes and its effect on routing performance has also been performed. With the aim to reduce workload on routers in CCN 1.0, we propose a mechanism called List Interest. This mechanism conveys multiple interests containing mutually common information. We also built a hash-routing technique based on the nodal clustering techniques. In this technique we limit the number of nodes that a request has to travel to reach the corresponding cache in very large networks. We also performed a detailed qualitative and quantitative study of the two most important naming schemas (flat vs. hierarchical) and show the interdependence of the various metrics and the impact of the choice of the naming schema on the performance and scalability of the network in terms of forwarding efficiency, routing table size, name space size and security. Another contribution in is Application Adaptive Forwarding which modifies the forwarding plane of ICN. This strategy modulates the flow of interest and data. The proposed strategy prioritizes the flow of requests based on the applications.

 

Task 1.4 Traffic and resource control [leader: UGOE/NEJ]

Summary of Y1

Pub/sub congestion control for multicast based efficient large scale

Delivery: We proposed R-COPSS that enhances a content oriented pub/sub system with flow, congestion control and reliability. We showed that the combination of multicast based delivery and query/response based local repair enables R-COPSS

to support a rate that is faster than the slowest subscriber’s receive rate. In fact, the average throughput achieved across all the subscribers is greater than or equal to their bottleneck link rate, showing that the congestion control mechanism is effective. R-COPSS is also able to achieve fairness across publishers.

Energy efficient resource control scheme: We also developed a novel tree-based traffic control mechanism for ICN, called MTTE. In the ordinary case, MTTE is performed by the central controller like OpenFlow. MTTE designs topology to accommodate contents traffic without congestion under constraint to minimize

links in use for energy efficiency. Simulation results show that MTTE can shut off up to 50% of links without severe degradation of latency.

Prioritization: We also argued that communication resilience is necessary in case of disasters as a complement to network resilience. The wide adoption of powerful mobile devices enables ad hoc communication, which can be a very helpful framework when normal access networks collapse temporarily or permanently. We have discussed the benefits of a name-based replication scheme, in comparison to a traditional end-host-based communication paradigm, and have found that indeed it presents high potential for more efficient use of network and device resources. Our design, called NREP, incorporates message prioritisation and spatio temporal scoping. Although our design is rather simple, we believe that it is an important first step towards communication

resilience in disaster cases. Moreover, we also designed the mechanism to suppress retransmission for low priority Interests in fragmented ICN. In order to prioritize Interest and Data packet properly, we address two approaches to recognize priority of packets. First one is consumer driven to differentiate user and another is producer driven to differentiate route to each prefix.

The congestion control work titled “Reliable Publish/Subscribe in Content-Centric Networks” was published at the ACM Sigcomm ICN workshop, August 2013 and the prioritization work, namely the work on “Name-based replication priorities for Information-Centric Networks” has been accepted for publication in the IEEE INFOCOM Name-Oriented Mobility (NOM) Workshop, April 28 2014, Toronto, Canada. Moreover, a part of this work is currently under submission for the IEEE Communications Magazine special issue on Disaster Resilience. The work on MTTE titled “Multiple-Tree Based Online Traffic Engineering for Energy Efficient Content Centric Networking” is currently under submission in Globecom 2014 – Next Generation Networking Symposium.

Summary of Y2

End-to-End traffic/resource control: We proposed INRPP and a significantly improved SAID as the end-to-end traffic control schemes. The main change to R-COPSS from Y1 (now renamed to SAID) is that SAID can support both query-response and pub/sub communication model. In Y3, we intend to further improve SAID and INRPP and integrate these approaches. We plan to implement and evaluate the In-Network Resource Pooling Principle in order to design a complete transport protocol for Information-Centric Networking environments.

Network-side traffic/resource control: We proposed Retransmission control scheme for fragmented ICNs. We also propose dynamic routing protocol (DSDVN) and adaptive message forwarding for fragmented CCNs. Our proposals improve the content retrieval performance in terms of network load, energy consumption and content retrieval delay. In Y3, we intend to further improve retransmission control approach.

Traffic/resource control for prioritization: We proposed PMTTE as an extension of MTTE to realize priority-aware traffic engineering. Compared with naive priority queue-enabled MTTE, PMTTE can boost the quality of both the high priority and low priority traffic by up to 50%.

In Y3, we intend to further improve PMTTE.

 

Summary of Y3

End-to-End traffic/resource control: We proposed INRPP and a significantly improved SAID as the end-to-end traffic control schemes. The main change to R-COPSS from Y1 (now renamed to SAID) is that SAID can support both query-response and pub/sub communication model. In Y3, we have further improve SAID based on the feedback received from the scientific community and we have renamed it to “Scalable and Adaptive Data Dissemination”.

Network-side traffic/resource control: In Y3, we updated the evaluation results in Energy and Resource Efficient Retransmission control in fragmented ICNs w.r.to the accepted paper in Globecom. We also changed the Wi-Fi interface from 802.11b to 802.11g in the simulation and further evaluation results are incorporated for the content retrieval time as factor of change in the number of chunks. We also proposed DRENCH: Distributed Load Balancing for NFV based Service Function Chaining which describes how the load balancing among the NFV instances can benefit from name based forwarding.

[1] M. Arumaithurai, J. Seedorf, A. Tagami, K. Ramakrishnan, and N. Blefari Melazzi: “Using ICN in disaster scenarios”, Internet-Draft draft-irtf-icnrg-disaster-00, Internet Engineering Task Force, February 2016. Work in progress.