MR-IoT: an information centric MapReduce

© 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. DOI: https://doi.org/10.1109/CCNC.2018.8319184

MR-IoT: an information centric MapReduce framework for IoT Qian Wang, Brian Lee, Niall Murray, Yuansong Qiao Software Research Institute Athlone Institute of Technology Athlone, Co. Westmeath, Ireland {qwang|ysqiao|nmurray}@research.ait.ie, [email protected] Abstract—The number of devices connected by the Internet of Things (IoT) has exceeded billions today. As IoT grows, so do the volumes of data it produces. Distributed data process (such as: MapReduce) performs better than a single central server by considering the big data set. Moreover, many IoT network spans widely in geographical areas, such as smart cities and supply chain management. Thus, the collected data can be processed in distributed way before transmission. This paper studies how to develop a MapReduce framework to process massive IoT data. Because in many cases IoT consumers desire more to get the meaningful knowledge than to build connections with multiple devices. The proposed framework should also fits well with the information-centric nature of IoT applications. As a result, our design (MR-IoT) is built upon a novel Information Centric Networking (ICN) architecture - NDN. It defines two schemes to execute MapReduce tasks on IoT: computational tree construction and computational task dissemination. A testbed is built on ndnSIM to verify the design and the result shows the defined schemes work correctly and the network traffic is significantly decreased. Keywords—IoT; MapReduce; ICN; In-network Computing

I. INTRODUCTION The Internet of Things (IoT) has gained a dramatic growth recently and will continue its expansion in the following years [1]. It brings two challenges consequently: one is to seek an efficient approach of processing massive IoT data, which is produced and exchanged by billions of heterogeneous devices. The other is to meet the requirements of various IoT applications relying on multiple devices, sometimes sharing the same devices. For example, in the scenarios of smart environment and intelligent transport, they both have lots of sensors deployed to provide data periodically. These data can also be shared to realize smart city applications [8]. Earlier approach burned the processing logic on devices’ hardware [17]. It is inflexible and impracticable by considering the huge scale of IoT networks. To deal with big data in IoT, researchers move to the cloud-computing because of its rich resource and powerful capabilities compared with IoT devices [8]. In this way, all IoT data needs to be delivered out of the network for processing and/or storage. Then the analyzed data may be sent back to the actuators within the IoT network. However, this procedure potentially poses an effect on network congestions as a large amount of data needs to be send out and return to the IoT network. Moreover, the Cloud capacity is still limited if it has to deal with each single data produced by

billions of IoT devices constantly. It is waste of resource to send some non-valuable data to the Cloud, e.g. noise data should be filtered. Compared with cloud-centric processing for big data, more and more applications [15] move towards manipulating data distributed to avoid bottlenecks when transferring all data to a single server. It’s the fact that many IoT systems are deployed widely and densely in geographical areas, such as crowd monitoring, supply chain management and so on [8]. These data sets are collected in a distributed fashion and they could be processed partially without affecting others. Thus, in contrast with cloud-computing, this paper proposes in-network distributed processing for IoT data, based on the widely deployed MapReduce [2] framework. MapReduce offers second-orders function which take user-defined functions as an input. IoT users could gain from this feature to flexibly express the processing logic. The logic can vary according to specific usage without changing the configuration of underlying infrastructure. Additionally, as the output of MapReduce tasks are in similar format (key-value pair), it’s easier for various applications to share different data types. At least, this procedure provides a pre-processing on raw data for further usages. The nature of most IoT applications tend to be informationcentric because firstly, consumers desire more to get the meaningful knowledge rather than building connections with devices. (Security concern certainly requires identity verification, which is out the range of this paper.), and secondly, these IoT applications require data to be processed at intermediate nodes, e.g. IoT gateways. Current IP networks [4] are host-centric so that it has inborn constraints to fulfil the two demands. The novel Information Centric Networking (ICN) architectures [3] is proposed to as an improvement of IP, which offers the possibility to be a better network support for IoT applications. ICN offers each data a unique name and cares more about the data content rather than its location. The original design of ICN enables two operations for information: name-based forwarding and in-network caching. However, it lacks of data computing. Named Function Networking (NFN) [5] extends the NDN (Named Data Networking) functionalities to name functions as a special type of data. It leaves the network to decide where the data processing can be performed, which is one of the contribution in this paper. Service chaining is another type of ICN in-network processing, such as Nextserve

[13] composes multiple services within one user request and the network execute the services in sequence. NDN-Q [6] achieves in-network query for vehicular networks based on the database model. The proposed design in this paper differs from the Nextserve and NDN-Q because we focus on using MapReduce method to develop a generic IoT processing framework. Although MR-CCN [13] applies the MapReduce concept in ICN, it is specially designed for datacenter scenario and routing path for data aggregation is based on the Camcube [14] model. To the authors’ best knowledge, this paper is the first one to develop an in-network MapReduce processing framework (MR-IoT) for IoT. Our design makes IoT devices to cooperate with each other for running user-defined functions. It is more user-friendly because consumers only express what they want, the whole network is responsible to deploy and execute the tasks, and then return the processed data. The main contributions of this paper include: •

Defined a naming scheme to express and disseminate the MapReduce functions.

•

Designed a protocol to form the computational tree based on the NDN routing schemes.

•

Implemented a MapReduce computation framework for IoT task execution over NDN.

•

Setup a testbed on ndnSIM to verify the proposed design.

This paper is organized as following: Section II introduces the related work of this paper. Section III shows the design of MR-IoT in detail. The experimental setup and evaluation results are presented in Section IV. Section V concludes the paper and discusses future work.

efforts are made to explore the potential capacity within IoT network. Named Data Networking (NDN) [4] is one of the most active ICN projects nowadays. MR-IoT is built upon NDN and verified by the NDN simulator [19]. Interest/Data are the two types of packets defined in NDN for information request and retrieval. Named Function Network (NFN) [5] proposes to name functions as a special type of data using Lambda expression. However, NFN doesn’t mention how the localityof-execution is discovered and decided by the network, which is one of the contributions of this paper. MapReduce is a traditional and powerful framework for distributed big data processing. Recently, many research areas are using MapReduce framework to achieve efficiency when processing large datasets, such as machine learning [15]. In [13], the authors implement a MapReduce framework on CCN and attempt to integrate computing with networking in datacenter environments. It uses the Camcube topology [14] as the foundation to guarantee forwarding for computation. The application scenario of MR-IoT concentrates on IoT. In addition, our design builds customized computational tree for each task by thinking that the routing requirement may be different for various IoT applications. The problem of routing by considering content has been discussed in [11]. The authors propose a routing protocol in IoT scenarios to route different content via different paths so that important content is not dropped while competing network resources with other traffic. The previous work of authors could be found in [9] and [10]. The initial attempt is to enable computing within the IoT network based on manually setup computing neighbours. The improvement in this paper allows the nodes to find computation neighbour according to the NDN routing protocol. Furthermore this paper focuses on the MapReduce framework whereas [9] and [10] focus on generic computation.

II. RELATED WORK The large amounts of IoT devices consist nearly everything around us. For example, temperature sensors in smart homes, vehicles in smart transportation and mobile phones in urban sensing. Current Internet works well when the connection between two static machines are stable. However, the overhead costs associated with mobility scenarios are very demanding for IoT devices with limited resources. ICN defines a new communication paradigm centered on data itself, which holds great support for IoT ecosystems. For example: ICN for automotive network [6] improves data delivery in poor-quality link; data retrieval is allowed from multiple-source nodes by sending one request [7]. Most existing ICN for IoT solutions cope with data caching and transmission. This paper aims to extend ICN to support in-network computation, with special focus on IoT scenarios. Without any doubt, Cloud is attractive due to its powerful capability and sufficient resource. Various IoT applications are able to obtain customized service in terms of data storage, management and processing in Cloud [8]. As we discussed before, this approach multiples the network traffic as IoT data will be sent in and out of network for different purpose. Current IoT data processing relies much on Cloud so that less

III. MR-IOT DESIGN MR-IoT aims to apply the powerful MapReduce framework on IoT network to achieve flexible and efficient data processing. We assume the selection of MapReduce nodes within IoT network has already done. MR-IoT mapper nodes process sensor data and return processed result to upstream reducers. MR-IoT reducers process data from downstream nodes, including direct connected mappers or child reducers. The main focus of this paper is how to coordinate these nodes to execute MapReduce tasks. The computation requirement of MR-IoT is that the same data can only be processed once. To this end, the overlap of network connection must be avoided. There are different types of network topology in real world: ring, star, tree and so on. When executing the MapReduce tasks, it should be a tree topology with current consumer as the root reducer and the mappers as the leaves so that the intermediate results can be aggregated effectively. To construct the computational tree for MR-IoT, reducers and mappers are designed to ask each other of the routing path to the current consumer (root reducer). In detail, every node will ask its neighbor “Am I your upstream to current consumer”. With the support of NDN routing, each node knows the routing information from itself to any other

B. Functional Interest Naming To allow users to express what data they want and how the data should be processed, MR-IoT designs a naming scheme including data and functions within an Interest. More importantly, the naming scheme supports task dissemination and data acquisition.

Fig. 1 MR-IoT Architecture

specific node. However, each node is not aware of other nodes’ routing information, and consequently all nodes need to communicate with their neighbors to obtain the information. When the computational tree is ready, consumers can assign computational tasks by sending MapReduce Interests. As NDN manipulates data by using their unique name, it’s necessary for MR-IoT to define a naming scheme to express the desired data content and processing functions. Then the MR-IoT network is responsible for distributing the tasks along the computational tree. Mappers and reducers cooperate together to produce the final Data and return it to the consumer. The following explains the MR-IoT design in details: A. Concept Overview The architecture of MR-IoT is presented in Fig. 1. IoT infrastructure consists of heterogonous entities, spanning from Cloud servers, edge Cloud/gateways to routers and sensors. Amongst them, the computation-capable nodes are pre-defined as either a mapper or a reducer. • Mapper A mapper is a node connecting with multiple sensors. It could run user-defined map function to process sensor data. The output of mappers is a (key, value) pair which is returned to only one upstream reducer. • Reducer A reducer is a node on the routing path between an MR-IoT mapper to the consumer. It receives Interests from the consumer or its upstream reducer and then continues disseminating the computational task down to the downstream reducers and mappers. It can also run user-defined reduce function to process data replied by its neighbors on the MR-IoT computational tree. Finally, a reducer returns its processed data to the upstream reducer until reach the consumer. • Edge on Computational Tree The edge on MR-IoT computational tree represents logical relationship between MR-IoT nodes, drawn as solid lines in Fig. 1. The network connection uses dotted lines. The edge between two MR-IoT nodes may vary with different tasks. Every network connection is possible to be an edge when building the computational tree.

A functional Interest in MR-IoT consists of four parts, organized as (a): (i) /NeighborName: will match the name published by neighbors to guarantee the specific node receiving the Interest. (ii) /map/f1(x->(k,v)): “f1” is the user-defined map function which should be applied on each input data. “x” is the input data and it can be in any format according to specific use cases. Such as for a MapReduce wordCount task, the input data is a text file and every word in this file is regarded as the key. For a MapReduce statistics task, e.g. to count the periodical updates, the sensor readings are captured in (timestamp, number) format. The input data in this case is already in a (key, value) format. The output (or processed data) of a mapper is always a (k, v) pair. (iii) /reduce/f2((z1,z2)->(z3)): “f2” is the user-defined reduce function to process received data from mappers and/or child reducers. The reduce function works on a list of values with the same key. (iv) /contentFilter: desired content name or defined filter on content. /NeighborName-/map/f1(x->(k,v))-/reduce/f2((z1,z2)->(z3))-/contentFilter (a)

Each part in the functional Interest starts with slash and then constructs hierarchically. Short dash is used to separate two different parts. For instance, in smart city scenarios, an officer wants to know the number of noise sensors with the same monitoring level (L), the request in MR-IoT is expressed as below: /NeighborName-/map/(L)->(L,1)-/reduce/(L1, L2)->(L1+L2)- /allNoiseSensor (b)

C. Computational Tree Construction The construction of computational tree is launched if there is no information of computation neighbors existing on the reducer nodes. Currently, MR-IoT uses the NDN shortest path routing to build the tree. This choice simplifies our initial work to develop a specialized routing protocol to support MR-IoT. The authors are aware that more parameters should be considered to optimize the computational tree construction, which will be a part of future work. For clarity, we regard the consumer as the root reducer, which is the one receives a user’s Interest. When multiple users simultaneously assign tasks to MR-IoT, there will exist various trees with different root reducers for each specific user. The Interest used in this procedure is called BuildReduceTree Interest and written as (c): /NeighborName/BuildReduceTree/(rootReducer)

(c)

Initially, the root reducer sends the original BuildReduceTree (c) to its neighbors. All other reducers need to deal with two events in the BuildReduceTree procedure: receive BuildReduceTree Interest and send out BuildReduceTree Interest. When receiving a BuildReduceTree Interest for a neighbor (the root reducer or other reducers), a reducer will decompose it in order to obtain the name of the root reducer. Then, this

selected upstream reducer. As an example in Fig. 1, R2 waits for the feedback from R3 and R4, and then it replies to R1. It is worth to mention although a reducer is reachable to the root reducer on the routing table, it won’t join in the job tree if it does not have downstream, such as R5 in Fig.1. Mappers only receive and reply to the BuildReduceTree Interests during computational tree construction. One mapper may receive multiple BuildReduceTree Interests from reducers. It will choose only one reducer as the SelectedUpstream and responds “nope” to others. The computational tree is done when all neighbors of the root reducer provide feedback. Then the root reducer will notify current user to assign computational tasks. Fig. 2 MR-IoT Workflow

node checks its own NDN routing table and get the neighbor (called SelectedUpstream) on the shortest path to the root reducer. If the received BuildReduceTree Interest is not from the SelectedUpstream, the node will reply “nope” immediately. It means this node will not use the path to return data for the current root reducer. Otherwise, the node will postpone the reply to its SelectedUpstream and continue discovering its neighbors. For example: if R1 is the root reducer in Fig.1, R2 will choose R1 as SelectedUpstream as well as replies “nope” to R3. If a reducer needs to continue exploring its computation neighbors, it will re-organize the original BuildReduceTree by inserting its own name. The newly-built Interest is shown as (d). To do this, it tells the downstream nodes who sent this Interest. For example, R5 in Fig. 1 receives two exactly the same Interests (c) from R3 and R4, R5 cannot know which Interest is sent by whom if R3 and R4 don’t add their information within the Interest. /NeighborName/BuildReduceTree/(rootReducer)/(upstreamReducerName) (d)

After a reducer sends out a BuildReduceTree Interest, it waits for answers from its network neighbors. If the reply content is “nope”, the reducer will ignore this neighbor and won’t assign any computational tasks (from current root reducer) to this neighbor. If a neighbor respond “yes”, the reducer will add this neighbor to its computation neighbor list for current root reducer for further use. When the node receives all feedback from its neighbors, it then replies “yes” to its

(a) Topology of 39 Nodes

D. Computational Task Execution Based on the functional design in section B and C, the MRIoT network is able to disseminate and execute computational tasks. The workflow of MR-IoT is shown as Fig. 2, which mainly involves three steps: task decomposition (D1), task deployment (D2) and task distribution (D3). For reducers, when they receive a functional Interest, they will decompose (D1) it to get the User-Define Reduce function (UF-R) and deploy (D2) it waiting for the returned data. At the same time, each reducer will continue distributing (D3) the functional Interests to its neighbors (downstream reducers and/or mappers) on the computational tree. The process happened on mappers is similar except mappers will decompose User-Defined Map function (UF-M). In addition, as mappers are connected with sensors, they will request all sensor data (Sensor Data Acquisition) rather than distributing functions to sensors. For task execution, a MR-IoT mapper firstly runs the UF-M on multiple sensor data. Each mapper produces a list of (key, value) pairs and then return them to the SelectedUpstream reducer. When MR-IoT reducer receives the processed data from all downstream neighbors, and it runs the UF-R on all the datasets. The final processed result is the combination of all sub-results produced by the reducers on the edge of the computational tree. Its format is defined as (e) and encapsulated into the Data packet for return. k1,v1-/k2,v2-/…-/k*,v*

(e)

The computational tasks in MR-IoT can be used to

(b) Topology of 66 Nodes

Fig. 3. Network Topology

(c) Topology of 93 Nodes

Fig. 4. Network Traffic

Fig. 5. Number of Interest at User Node

aggregate data into smaller size or filter noise data as soon as possible. It’s up to the specific functions provided by the users. As a result, users only describes what they want without worry about how and where the process is done.

IoT is expressed as (f). Both map and reduce functions are expressed as mathematical expression to examine whether the MR-IoT mappers and reducers can execute user-defined functions correctly. The normal Interest used for the comparison study is expressed as (g). The consumer sends out all Interests and then waits for Data. Because the comparison study involves no computation, the task is done when the consumer receives all feedback Data.

IV. TEST AND ANALYSIS A. Test Design MR-IoT is implemented on ndnSIM. In order to verify our design, a network generator BRITE [18] is used to generate the network topologies, shown as Fig. 3. There are three types of topology created and the total number of nodes are 39, 66 and 93 respectively. In details, for the three different topology sizes, they all have one consumer node and nine reducers. The consumer node also directly connects with two mapper nodes (sensors). The difference of the three topology is the number of mappers connected to each reducer. For the topology includes 39 nodes, each of the reducer connects with 3 mappers. The corresponding number of mappers are 6 per reducer for the 66topology and 9 per reducer for the 93-topology. There are three types of data transmission speed (bandwidth + delay): 100 Mbits per second + 25 milliseconds between the user network and MR-IoT network, 250kbits per second + 10 milliseconds between the MR-IoT mappers and MR-IoT reducers, and 54 Mbits per second + 1 millisecond between two MR-IoT reducers. All nodes are capable of MR-IoT functionalities. The comparison study (Request Directly) is performed for each network topology size, which means the consumer node directly sends NDN Interest to request mapper data. Both MRIoT and the comparison study run for 100s and the frequency that the consumer sends an Interest is 10 per second. To test the protocol of the computational tree construction, it should make sure that every reducer joins in the MapReduce tasks because they are all configured to connect with downstream mappers. Then it requires to check whether each reducer computes the right number of mapper data (1 reducer for 3/6/9 mappers in the three topology test cases respectively). Last but not least, the network topology generated by BRITE contain rings and therefore the proposed protocol should decompose the ring-connection into a tree while building the computational tree. To verify MR-IoT task execution procedure, a MapReduce task should be assigned. The functional Interest used in MR-

/NeighborName-/map/(k,v)->(k+1,v*2)-/reduce(n1,n2)->(n1+n2)-/allMapper (f)

/mapperName

(g)

B. Test Result and Analysis This section presents the test results and analysis. We checked the computational tree topology and recorded the network traffic. The number of Interests sent by the consumer is also illustrated. The original network connection looks nested in Fig.3. When running the tests using MR-IoT protocols, the whole network is full of BuildReduceTree Interest, it has a sharp increase on MR-IoT network traffic. However, when the tree is constructed, the network traffic is steady. As the reducer and mapper are connected with each other on the job tree, only the responsible nodes will forward user’s Interest to the corresponding mappers. For other nodes which are not on the job tree edge to the consumer, no traffic for the current task goes through their edges. Fig. 4 compares the traffic volume on the consumer node in the condition of different size of the IoT network. The traffic equals to the size of Interest packets sent by the consumer plus the size of Data packets received by the consumer. Indicated by the blue pattern filled columns in Fig. 4. It’s clear that the traffic at user node increases slightly even though the number of MR-IoT mappers becomes double or triple. The traffic generated by MR-IoT grows from 12.2 kilobytes when the test network has 39 nodes to 13 kilobytes when the node number adds to 93. The growth is related to the size of Data packets because of more mappers joining the network. The size of Interest packet is always the same as the neighbors of the consumer node on the computational tree never change. Only the reducers directly connect with the mapper nodes will send out more Interests. The red columns in Fig. 4 are the traffic produced in the comparison study. It shows a significant growth when the number of mappers raises. In order to get all sensor data, the

consumer has to send a separate Interest for each sensor data. Obviously, when there are 83 mappers in the biggest test topology, the consumer has to request 83 times. Moreover, one Interest packet is matched by one Data in NDN. The consumer then receives the same number of Data as the sent-out Interest quantity. It results in more data traffic for consumer node. The more mappers involved, the bigger difference between MR-IoT and the comparison study. When the network contains 93 nodes, MR-IoT generates 13 kilobytes whereas the comparison study produces 44.4 kilobytes. Our design could save more than triple of the traffic. According to the test results, we can infer that when the user sends more Interests to IoT network, the comparison study will create heavier the IoT data traffic. Fig. 5 shows the number of Interests sent by user in three test topology (the number of mappers are 29, 56 and 89 respectively). From this figure we can conclude the same result with the above discussion. As MR-IoT is responsible for the data retrieval and data computation, the consumer only asks its neighbor nodes on the job tree no matter how many mappers exist. For the comparison study, the number of Interest equals to the number of mapper. It’s not practical for a consumer to send a large volumes of messages if it wants to know the sensor data in a wide area. In this way, the consumer node will be overloaded with traffic for running one task. In summary, MR-IoT is able to perform in-network computation without causing heavy burden for consumers. Additionally, our design helps to save network traffic as well as offers flexibility for consumers to get customized services. V. CONCLUSION AND FUTURE WORK With the rapid increase of IoT network, there is a large amount of and will be more data to be produced and exchange by IoT devices. To achieve efficiency, distributed data processing is more promising for big datasets. With the consideration of information-centric nature of many IoT applications, this paper uses NDN as underlying support to develop a MapReduce framework for IoT (MR-IoT). To guarantee the computation accuracy in MR-IoT (the same data can only be processed once), a protocol for the computational tree construction is proposed to avoid the overlapped network connections. A naming scheme is designed to express required data and user-defined functions. The execution of computational tasks include task dissemination, function execution and returning the processed data. The experiments are performed on ndnSIM and the test results show MR-IoT can lower the network traffic significantly, especially when the number of sensor nodes are large. For the future work, more factors will be considered to optimize the computational tree, such as the minimum energy cost and the priority of tasks. In order to support complicated process logic, the naming scheme may require improvement. ACKNOWLEDGMENT

This publication has emanated from research supported by research grants from Institutes of Technology Ireland (IOTI) under Postgraduate Scholarship Initiative 2014, and Science Foundation Ireland (SFI) under Grant Number 13/SIRG/2178. REFERENCES [1] [2]

[3] [4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14] [15] [16]

[17]

[18] [19]

Cisco, Available: “Cisco visual networking index: Global mobile data traffic forecast update, 2014–2019,” Accessed: July-2017. J. Dean and S. Ghemawat, “MapReduce: Simpli_ed data processing on large clusters," Communications of the ACM, vol. 51, no. 1, pp. 107113, 2008. Y. Zhang, et al, "Requirements and challenges for IoT over ICN", IRTF ICN Research Group, Nov. 2015. L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, kc claffy, P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang, “Named Data Networking,” SIGCOMM Comput Commun Rev, vol. 44, no. 3, pp. 66–73, 2014. M. Sifalakis, B. Kohler, C. Christopher, and C. Tschudin, “An information centric network for computing the distribution of computations,” in Proceedings of the 1st international conference on Information-centric networking, pp. 137–146, 2014. W. Drira and F. Filali, “NDN-Q: An NDN Query Mechanism for Efficient V2X Data Collection,” 2014 Eleventh Annual IEEE International Conference on Sensing, Communication, and Networking Workshops (SECON Workshops), pp.13-18. M. Amadeo, C. Campolo and A. Molinaro, “Multi-source data retrieval in IoT via named data networking,” ICN’14 Proceedings of the 1st International Conference on Information-centric Networking, ACM New York, USA, pp. 67-76, 2014. J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A vision, architectural elements, and future directions,” Future Generation Computer Systerm., vol. 29, no. 7, pp. 1645–1660, September 2013. Q. Wang, B. Lee, , N. Murray and Y. Qiao, “CS-Man: Computation Service Management for IoT In-Network Processing,” the 27th Irish Signals and Systems Conference (ISSC), Derry, Northern Ireland, 2016. Q. Wang, B. Lee, , N. Murray and Y. Qiao, “IProIoT: an In-network Processing Framework for IoT using Information Centric Networking,” the 9th International Conference on Ubiqutious and Future Networks (ICUFN), Milan, Italy, 2017. Y. Jin, S. Gormus, P. Kulkarni, and M. Sooriyabandara, “Content centric routing in iot networks and its integration in RPL,” Computer Communications, 2016. Mansour, D., Braun, T., and Anastasiades, C. “Nextserve Framework: Supporting Services over Content-Centric Networking,” In Wired/Wireless Internet Communications. Springer, pp. 189–199, 2014. F. Pianese, “Information Centric Networks for Parallel Processing in the Datacenter,” the 33rd IEEE International Conference on Distributed Computing Systems Workshops, pp. 208-213, 2013. Abu-Libdeh, H., Costa, P., Rowstron, A., O’Shea, G., and Donnelly, “A. Symbiotic Routing in Future Data Centers”. In SIGCOMM (2010). Corentin, H., Erwan, M., and Bruno, S., “Distributed deep learning on edge-devices: feasibility via adptive compression”, arxiv 2017. M. Frankllin, S. Jeffery, S. Krishnamurthy, F. Reiss, S. Rizvi, E. Wu, O. Cooper, A. Edakkunni and W. Hong, “Design Considerations for High Fan-in Systems: The HiFi Approach”, Proceedings of the 2nd CIDR Conference, California, 2005. M. Kovatsch, S. Mayer, and B. Ostermaier, “Moving application logic from the firmware to the cloud: Towards the thin server architecture for the internet of things,” 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), Palermo, Italian, pp. 751–756, 2012. BRITE, Available: “https://www.cs.bu.edu/brite/”, Accessed: July-2017. ndnSIM, Available: “http://ndnsim.net/2.3/”, Accessed: July-2017.