idnits 2.17.1 draft-zhang-icnrg-icniot-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scopes are used to mark where the content is available[65]. For' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2017) is 2497 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'IoTGW' on line 762 == Unused Reference: '6' is defined on line 1711, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1721, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1729, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1734, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1743, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1747, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1751, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1755, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1783, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1800, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 1820, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1827, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 1839, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: '41' is defined on line 1863, but no explicit reference was found in the text == Unused Reference: '49' is defined on line 1903, but no explicit reference was found in the text == Unused Reference: '67' is defined on line 1981, but no explicit reference was found in the text == Unused Reference: '68' is defined on line 1985, but no explicit reference was found in the text == Unused Reference: '76' is defined on line 2015, but no explicit reference was found in the text == Unused Reference: '77' is defined on line 2020, but no explicit reference was found in the text == Unused Reference: '84' is defined on line 2054, but no explicit reference was found in the text == Unused Reference: '87' is defined on line 2065, but no explicit reference was found in the text == Unused Reference: '92' is defined on line 2085, but no explicit reference was found in the text == Unused Reference: '93' is defined on line 2089, but no explicit reference was found in the text == Unused Reference: '94' is defined on line 2093, but no explicit reference was found in the text == Unused Reference: '98' is defined on line 2112, but no explicit reference was found in the text == Unused Reference: '99' is defined on line 2115, but no explicit reference was found in the text == Unused Reference: '100' is defined on line 2118, but no explicit reference was found in the text == Unused Reference: '102' is defined on line 2128, but no explicit reference was found in the text == Unused Reference: '110' is defined on line 2162, but no explicit reference was found in the text == Unused Reference: '112' is defined on line 2171, but no explicit reference was found in the text == Unused Reference: '114' is defined on line 2179, but no explicit reference was found in the text == Unused Reference: '115' is defined on line 2183, but no explicit reference was found in the text == Unused Reference: '116' is defined on line 2187, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. '79') (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-02) exists of draft-wood-icnrg-ccnxkeyexchange-01 Summary: 3 errors (**), 0 flaws (~~), 38 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Y. Zhang 3 Internet-Draft D. Raychadhuri 4 Intended status: Informational WINLAB, Rutgers University 5 Expires: December 28, 2017 L. Grieco 6 Politecnico di Bari (DEI) 7 E. Baccelli 8 INRIA 9 J. Burke 10 UCLA REMAP 11 R. Ravindran 12 G. Wang 13 Huawei Technologies 14 A. Lindgren 15 B. Ahlgren 16 RISE SICS 17 O. Schelen 18 Lulea University of Technology 19 June 26, 2017 21 Design Considerations for Applying ICN to IoT 22 draft-zhang-icnrg-icniot-01 24 Abstract 26 The Internet of Things (IoT) promises to connect billions of objects 27 to the Internet. After deploying many stand-alone IoT systems in 28 different domains, the current trend is to develop a common, "thin 29 waist" of protocols over a horizontal unified, defragmented IoT 30 architecture. Such an architecture will make objects accessible to 31 applications across organizations and domains. Towards this goal, 32 quite a few proposals have been made to build an application-layer 33 based unified IoT platform on top of today's host-centric Internet. 34 However, there is a fundamental mismatch between the host-centric 35 nature of todays Internet and mostly information-centric nature of 36 the IoT system. To address this mismatch, an information-centric 37 network (ICN) architecture can provide a common set of protocols and 38 services, called 'ICN-IoT', which can be used to build IoT platforms. 39 ICN-IoT leverages the salient features of ICN, and thus provides 40 naming, security, mobility support,scalability, and efficient content 41 and service delivery. 43 This draft summarizes general IoT demands, and covers the challenges 44 and design considerations ICN faces to realize a ICN-IoT framework 45 based on ICN architecture. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on December 28, 2017. 64 Copyright Notice 66 Copyright (c) 2017 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. IoT Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Motivating ICN for IoT . . . . . . . . . . . . . . . . . . . 4 83 3. IoT Architectural Requirements . . . . . . . . . . . . . . . 9 84 3.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 3.2. Security and Privacy . . . . . . . . . . . . . . . . . . 10 86 3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.4. Resource Constraints . . . . . . . . . . . . . . . . . . 10 88 3.5. Traffic Characteristics . . . . . . . . . . . . . . . . . 11 89 3.6. Contextual Communication . . . . . . . . . . . . . . . . 12 90 3.7. Handling Mobility . . . . . . . . . . . . . . . . . . . . 12 91 3.8. Storage and Caching . . . . . . . . . . . . . . . . . . . 13 92 3.9. Communication Reliability . . . . . . . . . . . . . . . . 13 93 3.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 14 94 3.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 14 95 3.12. IoT Platform Management . . . . . . . . . . . . . . . . . 15 96 4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 15 97 4.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 15 98 4.2. Application-Layer Unified IoT Solutions . . . . . . . . . 16 99 4.2.1. Weaknesses of the Application-Layer Approach . . . . 17 100 4.2.2. Suitability of Delay Tolerant Networking(DTN) . . . . 19 101 5. Advantages of using ICN for IoT . . . . . . . . . . . . . . . 19 102 6. ICN Design Considerations for IoT . . . . . . . . . . . . . . 21 103 6.1. Naming Devices, Data, and Services . . . . . . . . . . . 21 104 6.2. Name Resolution . . . . . . . . . . . . . . . . . . . . . 25 105 6.3. Security and Privacy . . . . . . . . . . . . . . . . . . 26 106 6.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 6.5. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 6.6. Routing and Forwarding . . . . . . . . . . . . . . . . . 31 109 6.7. Mobility Management . . . . . . . . . . . . . . . . . . . 32 110 6.8. Contextual Communication . . . . . . . . . . . . . . . . 33 111 6.9. In-network Computing . . . . . . . . . . . . . . . . . . 33 112 6.10. Self-Orgnization . . . . . . . . . . . . . . . . . . . . 34 113 6.11. Communications Reliability . . . . . . . . . . . . . . . 35 114 6.12. Resource Constraints and Heterogeneity . . . . . . . . . 35 115 7. Differences from T2TRG . . . . . . . . . . . . . . . . . . . 36 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 117 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 119 11. Informative References . . . . . . . . . . . . . . . . . . . 37 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 122 1. IoT Motivation 124 During the past decade, many Internet of Things (IoT) systems have 125 been developed and deployed in different domains. The recent trend, 126 however, is to evolve towards a more unified IoT architecture, in 127 which a large number of objects connect to the Internet, available 128 for interactions among themselves, as well as interactions with many 129 different applications across boundaries of administration and 130 domains. General IoT applications involve sensing, processing, and 131 secure content distribution occurring at various timescales and at 132 multiple levels of hierarchy depending on the application 133 requirements. This requires the system to adopt a unified 134 architecture providing pull, push and publish/subscribe mechanisms 135 using application abstractions, common naming, payload, encryption 136 and signature schemes. This requires open APIs to be generic enough 137 to support commonly used interactions between consumers, content 138 producer, and IoT services, as opposed to proprietary APIs that are 139 common in today's systems. Building a unified IoT architecture, 140 however, poses great challenges on the underlying network and 141 systems. To name a few, it needs to support 50-100 Billion networked 142 objects [1], many of which are mobile. The objects will have 143 extremely heterogeneous means of connecting to the Internet, often 144 with severe resource constraints. Interactions between the 145 applications and objects are often real-time and dynamic, requiring 146 strong security and privacy protections. In addition, many IoT 147 applications are inherently information centric (e.g., data consumers 148 usually need data sensed from the environment without any reference 149 to the sub-set of sensors that will provide the asked information). 151 Taking a general IoT perspective, we first motivate the discussion of 152 ICN for IoT using well known scenarios. Then we discuss the IoT 153 requirements generally applicable to many well known IoT scenarios. 154 We then discuss how the current application-layer unified IoT 155 architectures fail to meet these requirements. We follow this by key 156 ICN features that makes it a better candidate to realize an unified 157 IoT framework. We then discuss IoT design challenges from an ICN 158 perspective and requirements posed towards its design. 160 2. Motivating ICN for IoT 162 ICN offers many features including name-based networking, content 163 object security, caching, computing and storage, mobility, context- 164 aware networking (see Section 3.6) and support for ad hoc networking 165 features, all of which have to be realized in an application-specific 166 means in the context of IP-IoT. These compelling features enable a 167 distributed and intelligent data distribution platform to support 168 heterogeneous IoT services with features like device bootstrapping 169 with minimal configuration, simpler protocols to aid self-organizing 170 among the IoT elements, natural support for compute and caching logic 171 at strategic points in the network. We discuss these features 172 through the following scenarios that are difficult to realize over IP 173 today, and whose characteristics we argue match the features offered 174 by ICN. 176 o Smart Mobility: Smarter end-user devices and Machine-to-Machine 177 (M2M) connection are undergoing a significant growth. By 2021, 178 there will be more than 10 billion mobile devices and connection, 179 including smartphones, tablets, wearables, vehicles [1]. Involved 180 fields range from medical and healthcare, fitness, clothing, to 181 environmental monitoring [40]. In particular, one of the most 182 affected domain is transportation and the so-called Intelligent 183 Transport Systems (ITS) [42]. It aims at providing multi-modal 184 transportation, embracing public and private municipal, regional, 185 national, trans-national vehicles and fleets. This extremely 186 heterogeneous eco-system of means of transportation is made 187 available to users and citizens through advanced services. These 188 services are able to fulfill usability requirements while pursuing 189 system level objectives, thus including: (i) the reduction of the 190 CO2 footprint, (ii) the real-time delivery of specific goods, 191 (iii) the reduction of traffic within urban areas, (iv) the 192 provisioning of pleasant journeys to tourists, and (v) the general 193 commitment of satisfactory travel time and experience [117]. In 194 this context, IoT technologies can play a pivotal, in particular, 195 Traffic Management Systems (TMS) aided by IoT technologies are 196 creating novel approaches to traffic modeling [47]. Moreover, 197 such features enable advanced design paradigms (e.g., Mobility as 198 a Service (MaaS) [39]) with huge implications in systems 199 architectures [48]. As a consequence, smart mobility support can 200 be a significant use case of ICN-IoT. The important ICN features 201 that corroborate mobility support are: 203 * The location independence of content allows one to manage 204 consumer mobility in a simpler way than IP. Different from 205 Mobile IP, that needs 'triangular routing' to locate moving 206 hosts, ICN envisions that the consumers just needs to re-issue 207 content requests after changing the attachment point [43]; 209 * Since content is not bound to a specific location, it can be 210 cached anywhere in the network. This caching mechanism adds 211 redundancy to the system. Therefore, if the producer loses 212 connectivity while it is moving, a content request can be 213 resolved to an intermediate node en-route or routed towards a 214 caching node [43]; 216 * The content request-response communication paradigm decouples 217 publications and subscriptions in time and space. Therefore, 218 entities involved are not aware of each other and do not need 219 to be connected at the same time [44]; 221 * The use of in-network Name Resolution Service design allows to 222 identify content name's current location in the network, thanks 223 to its network function of updating named entity location 224 information [56]. 226 From a technological perspective, open challenges are: (i) 227 interoperability across different IoT technologies; (ii) namespace 228 design able to harmonize ITS standards; (iii) scalable data- 229 sharing model across real-time (and non real-time) traffic 230 sources; (iv) definition of travel-centric services based on ICN- 231 IoT; (v) seamless support to mobility; (vi) content authentication 232 and cryptography. 234 o Smart Building: Buildings are gaining smart capabilities that 235 allow to enhance comfort, provide safety and security, manage 236 efficiently energy [101]. In particular, smart buildings are no 237 longer simple energy consumer, but can also be prosumers with on- 238 site energy generation systems. These systems can improve 239 building's usability towards: (i) Smart heating, ventilation, and 240 air conditioning (HVAC), (ii) Smart lightings, (iii) Plug loads, 241 (iv) Smart windows. The main requirements of those sub-systems 242 are [101]: (i) context awareness; (ii) resource-constrained 243 devices; (iii) interoperability across heterogeneous technologies; 244 (iv) security and privacy protection. The ICN paradigm could ease 245 the fulfillment of those requirements because, usually, smart 246 building services are information centric by design: this means 247 that every time an autonomic management loop is established within 248 the smart building to control some physical variables of interest, 249 the information exchanged between users, sensors, actuators, and 250 controllers do not immediately translate to specific nodes within 251 the building but could be provided by multiple sensors / gateways. 252 The relevance of ICN in Smart Building is recognized in literature 253 with reference to the several frameworks deployed in various 254 environments. For instance, in [61], nodes are distributed in 255 different rooms, floors, and buildings of a campus university and 256 their energy consumption and individual behavior are monitored. 257 Smart home application is investigated in [103], by evaluating 258 data retrieval delay and data packet loss. Moreover, [104] 259 designed and tested lighting control over NDN in a theater. In 260 this context, specific ICN challenges are: (i) design of a 261 scalable namespace for uniquely identifying the information of 262 interest, (ii) data-sharing model across heterogeneous systems, 263 (iii) self-organizing functionalities for improving network 264 connections between end-nodes, utilities and the control center, 265 (iv) authentication procedures to grant data confidentiality and 266 integrity. 268 o Smart Grid: Smart Grids are increasingly transforming into cyber- 269 physical systems [18] with the goal of maximum automation towards 270 efficiency and minimal human intervention. The system is very 271 complex comprising of power distribution grids, end user 272 applications (e.g. EV charging systems, appliances etc), smart 273 monitoring systems (spanning end user and the power grids), 274 heterogeneous energy producing sources (including prosumers), and 275 load distribution and balancing systems. Current smart grid 276 systems are managed using Supservisory Control and Data 277 Acquisition (SCADA) frameworks that are centralized and highly 278 restrictive unidirectional communication support [19]. Hence the 279 requirement is towards : 1) greater flexibility to distribute the 280 energy from the feeder through real-time reconfiguration of 281 multiple monitoring devices (e.g. phasor measurement units 282 (PMUs)), and management operations which require efficient data 283 delivery infrastructure; 2) large scale data delivery 284 infrastructure, which also include latency sensitive applications, 285 inter-connecting heterogeneous smart grid producing, monitoring 286 and consuming end user devices; 3) Resiliency,which is critical to 287 the operation and protection of the grid; 4)Security, to protect 288 mission critical grid applications from network intrusions ; 5) 289 understanding machine-to-machine traffic patterns for optimal 290 placement of storage and computing for maximum efficiency. Smart 291 grids can benefit from ICN in the following ways [20] : 293 * Smart grid will benefit from naming content than hosts, as it 294 is more likely that data generated by one subsystem will be 295 useful for multiple entities. Further, naming content allows 296 to enable many-to-many model of communication, which is very 297 in-efficient in host-centric architectures. 299 * ICN features of in-network computing, storage and caching will 300 enable better use of network resources and benefit diverse 301 application needs varying from applications that has low 302 bitrate and is latency tolerant (e.g. smart grid and energy 303 pricing) to higher data rate ones with stringent delay/ 304 disruption requirements (e.g. synchrophasor measurements). 305 Also it is typical in smart grid systems to have applications 306 consuming the same data at different rates in which case in- 307 network caching and computing could help. 309 * Host-centric networking exposes a mission critical 310 infrastructure like smart grid infrastructure to intrusion and 311 DOS attacks, this is directly related to exposing the IP 312 addresses of critical applications and subsystems. Naming 313 content, service or device de-couples it from the location, 314 reducing the exposure to target a specific smart grid subsystem 315 based on a geographical context. 317 * ICN's name based networking offers the potential for self- 318 configuration both during bootstrapping and during the regular 319 operation of the grid allowing scalable operation and self- 320 recovery during faults or maintenance tasks in the system. 322 o Smart Industrial Automation : In a smart and connected industry 323 environment, there is a multitude of equipment with sensors that 324 generate large volumes of data during normal operation. This 325 range from highly time-critical data for real-time control of 326 production processes, to less time-critical data that is collected 327 to central cloud environment for control room monitoring, to pure 328 log data without latency requirements that is mainly kept for a 329 posteriori analysis. Industrial wireless networks are harsh 330 environments with lots of potential interference at the same time 331 as hard reliability and real-time requirements are placed by many 332 applications. This means that available network capacity is not 333 always high, so congestion is likely to be experienced by traffic 334 with less stringent timing requirements. One such example is when 335 errors occur in the production process, a mobile workforce will 336 need to investigate the problem on-site and will need high 337 resolution data from the faulty machine as well as other process 338 data from other parts of the plant. The mobile workforce will 339 locally perform diagnostics or maintenance and they rely on the 340 information from the production system both for safety and to 341 solve any issues in the plant. They rely on both historical data 342 in order to pinpoint the root cause of the problems, as well as 343 the current data flows in order to assess the present state of the 344 equipment under control. High resolution measurements are 345 generated close to the mobile workforce while the historic data 346 has to be retrieved from the historian servers. Multiple workers 347 involved in the process will access the same data, possibly with a 348 slight time-shift. The network thus need to support a mobile 349 users to get access to data flows in a way suitable for their 350 physical location and task requirements. Introducing ICN 351 functionality into the system can introduce several benefits that 352 will enhance the working experience and productivity for the 353 mobile workforce. 355 * When using ICN, naming of data can be done in a way that 356 corresponds well to the current names often used in industrial 357 scenarios as the hierarchical names defined by OPC Foundation 358 [10] maps well to the CCN/NDN name space. 360 * ICN provides the possibility to get newest data without knowing 361 the location of the caches or whether a particular piece of 362 data is available locally or in a central repository. Also 363 gives the possibility to get either local high-resolution data 364 or remote low-resolution data (no need to store all data 365 centrally, which is maybe not even possible due to large data 366 volumes). May require known naming conventions or routing 367 policies that can route interests to the right location. 369 * Reduces network usage as unnecessary data is not transmitted, 370 and data accessed by multiple workers is only sent once. 372 * Workforce mobility between different access points in the 373 factory is inherently supported without the need to maintain 374 connection state. 376 * Removing tedious configurations in clients since that is 377 provided by the infrastructure. 379 * Allow sharing of large data volumes between users that are in 380 physical proximity without introducing additional traffic on 381 the backbone. 383 * Caching of data means avoiding database accesses to a 384 distributed redundant database in the central infrastructure 385 with consistency requirements. 387 3. IoT Architectural Requirements 389 A unified IoT platform has to support interactions among a large 390 number of mobile devices across the boundaries of organizations and 391 domains. As a result, it naturally poses stringent requirements in 392 every aspect of the system design. Below, we outline a few important 393 requirements that a unified IoT platform has to address. 395 3.1. Naming 397 An important step towards realizing a unified IoT architecture is the 398 ability to assign names that are unique to each device, data items 399 generated by these devices, or a group of devices towards a common 400 objective. Naming has the following requirements. Firstly, names 401 need to be persistent against dynamic features that are common in IoT 402 systems, such as lifetime, mobility or migration. Secondly, names 403 that are derived from the keys need to be self-certifying, for both 404 device-centric communication and content-centric communication. For 405 device-centric communication, the binding between device names and 406 the device must be secure. For content-centric communication, the 407 binding between the names and the content has to be secure. Thirdly, 408 names usually serve multiple purposes: routing, security (self- 409 certifying) or human-readability. For IoT applications, the choice 410 of flat versus human readable names needs to be made considering 411 application and network requirements such as privacy and network 412 level scalability, and the name space explosion that may occur 413 because of complex relationship between name hierarchies [120] which 414 might confound application logic. In order to ensure the 415 trustworthiness of the names, a name certificate service (NCS) needs 416 to be considered. Such a service acts as a certificate authority in 417 assigning names, which are themselves public keys or appropriately 418 bound to the name for verification at the consumer's end. In short, 419 the NCS must provide services analogous to those provided by a Public 420 Key Infrastructure (PKI). In ICN, users may either generate their 421 own public keys and submit them to the NCS for registration, or may 422 contact the NCS to acquire public keys. Consequently, the NCS 423 publishes approved cryptographic suites, object categories and object 424 description formats, as well as allows users to self-certify 425 themselves. 427 3.2. Security and Privacy 429 A variety of security and privacy concerns exist in IoT. For example 430 the unified IoT architecture makes physical objects accessible to 431 applications across organizations and domains. Further, it often 432 integrates with critical infrastructure and industrial systems with 433 life safety implications, bringing with it significant security 434 challenges and regulatory requirements [13], as will be discussed in 435 Section 6.3. Security and privacy thus become a serious concern, as 436 does the flexibility and usability of the design approaches. Beyond 437 the overarching trust management challenge, security includes data 438 integrity, authentication, and access control at different layers of 439 the IoT architecture. Privacy includes several aspects: (1) privacy 440 of data producer/consumer that is directly related to each individual 441 vertical domain such as heath, electricity, etc., (2) privacy of data 442 content, and (3) privacy of contextual information such as time and 443 location of data transmission [65]. 445 3.3. Scalability 447 Cisco predicts there will be around 50 Billion IoT devices such as 448 sensors, RFID tags, and actuators, on the Internet by 2020 [1]. As 449 mentioned above, a unified IoT platform needs to name every entity 450 such as data, device, service etc. Scalability has to be addressed 451 at multiple levels of the IoT architecture including naming, 452 security, name resolution, routing and forwarding level. Mobility 453 adds further challenge in terms of scalability. Particularly with 454 respect to name resolution the system should be able to 455 register/update/resolve a name within a short latency. In addition 456 scalability is also affected because of IoT system specific features 457 such as IoT resource object count, state and rate of information 458 updates generated by the sensing devices. 460 3.4. Resource Constraints 462 IoT devices can be broadly classified as type 1, type 2, and type 3 463 devices, with type 1 the most resource-constrained and type 3 the 464 most resource-rich [45]. In general, there are the following types 465 of resources: power, computing, storage, bandwidth, and user 466 interface. 468 Power constraints of IoT devices limit how much data these devices 469 can communicate, as it has been shown that communications consume 470 more power than other activities for embedded devices [46]. Flexible 471 techniques to collect the relevant information are required, and 472 uploading every single produced data to a central server is 473 undesirable. Computing constraints limit the type and amount of 474 processing these devices can perform. As a result, more complex 475 processing needs to be conducted in cloud servers or at opportunistic 476 points, example at the network edge, hence it is important to balance 477 local computation versus communication cost. 479 Storage constraints of the IoT devices limit the amount of data that 480 can be stored on the devices. This constraint means that unused 481 sensor data may need to be discarded or stored in aggregated compact 482 form time to time. Bandwidth constraints of the IoT devices limit 483 the amount of communication. Such devices will have the same 484 implication on the system architecture as with the power constraints; 485 namely, we cannot afford to collect single sensor data generated by 486 the device and/or use complex signaling protocols. It is also worth 487 mentioning that idle chatter in the background is strongly 488 discouraged to maintain connectivity or other volatile state. 490 User interface constraints refer to whether the device is itself 491 capable of directly interacting with a user should the need arise 492 (e.g., via a display and keypad or LED indicators) or requires the 493 network connectivity, either global or local, to interact with 494 humans. 496 The above discussed device constraints also affect application 497 performance with respect to latency. 499 3.5. Traffic Characteristics 501 IoT traffic can be broadly classified into local area traffic and 502 wide area traffic. Local area traffic is among nearby devices. For 503 example, neighboring cars may work together to detect potential 504 hazards on the highway, sensors deployed in the same room may 505 collaborate to determine how to adjust the heating level in the room. 506 These local area communications often involve data aggregation and 507 filtering, have real time constraints, and require fast device/data/ 508 service discovery and association. At the same time, the IoT 509 platform has to also support wide area communications. For example, 510 in Intelligent Transportation Systems, re-routing operations may 511 require a broad knowledge of the status of the system, traffic load, 512 availability of freights, whether forecasts and so on. Wide area 513 communications require efficient data/service discovery and 514 resolution services. 516 While traffic characteristics for different IoT systems are expected 517 to be different, certain IoT systems have been analyzed and shown to 518 have comparable uplink and downlink traffic volume in some 519 applications such as [2], which means that we have to optimize the 520 bandwidth/energy consumption in both directions. Further, IoT 521 traffic demonstrates certain periodicity and burstiness [2]. As a 522 result, when provisioning the system, the shape of the traffic volume 523 has to be properly accounted for. 525 3.6. Contextual Communication 527 Many IoT applications rely on dynamic contexts in the IoT system to 528 initiate, maintain and terminate communication among IoT devices. 529 Here, we refer to a context as attributes applicable to a group of 530 devices that share some common features, such as their owners may 531 have a certain social relationship or belong to the same 532 administrative group, or the devices may be present in the same 533 location. There are two types of contexts: long-term quasi static 534 contexts and short-term dynamic contexts. In this draft, we focus on 535 the latter, which are more challenging to support, requiring fast 536 formation, update, lookup and association For example, cars traveling 537 on the highway may form a "cluster" based upon their temporal 538 physical proximity as well as the detection of the same event. These 539 temporary groups are referred to as contexts. IoT applications need 540 to support interactions among the members of a context, as well as 541 interactions across contexts. 543 Temporal context can be broadly categorized into two classes, long- 544 term contexts such as those that are based upon social contacts as 545 well as stationary physical locations (e.g., sensors in a car/ 546 building), and short-term contexts such as those that are based upon 547 temporary proximity (e.g., all taxicabs within half a mile of the 548 Time Square at noon on Oct 1, 2013). Between these two classes, 549 short-term contexts are more challenging to support, requiring fast 550 formation, update, lookup and association. 552 3.7. Handling Mobility 554 There are several degrees of mobility in a unified IoT architecture, 555 ranging from static as in fixed assets to highly dynamic in vehicle- 556 to-vehicle environments. 558 Mobility in the IoT architecture can mean 1) the data producer 559 mobility (i.e., location change), 2) the data consumer mobility, 3) 560 IoT Network mobility (e.g., a body-area network in motion as a person 561 is walking); and 4) disconnection between the data source and 562 destination pair (e.g., due to unreliable wireless links). The 563 requirement on mobility support is to be able to deliver IoT data 564 below an application's acceptable delay constraint in all of the 565 above cases, and if necessary to negotiate different connectivity or 566 security constraints specific to each mobile context. More detailed 567 discussions are presented in Section 6.7. 569 3.8. Storage and Caching 571 Storage and caching plays a very significant role depending on the 572 type of IoT ecosystem, also a function subjected to privacy and 573 security guidelines. Caching is usually done for increasing data 574 availability in the network and reliability purposes, especially in 575 wireless scenarios in the network access. Storage is more important 576 for IoT, storing data for long term analysis. Data is stored in 577 strategic locations in the network to reduce control and computation 578 overhead. In a unified IoT architecture, depending on application 579 requirements, content caching will be strictly driven by application 580 level policies considering privacy requirements. If for certain kind 581 of IoT data pervasive caching is allowed, intermediate nodes don't 582 need to always forward a content request to its original creator; 583 rather, receiving a cached copy is sufficient for IoT applications. 584 This optimization may greatly reduce the content access latencies. 586 Furthermore considering hierarchical nature of IoT systems, ICN 587 architectures enable flexible heterogeneous and potentially fault- 588 tolerant approach to storage providing persistence at multiple 589 levels. 591 Hence in the context of IoT while ICN allows resolution to replicated 592 stored copies, it should also strive for the balance between content 593 security/privacy and regulations considering application 594 requirements. 596 3.9. Communication Reliability 598 IoT applications can be broadly categorized into mission critical and 599 non-mission critical. For mission critical applications, reliable 600 communication is one of the most important features as these 601 applications have strong QoS requirements such as low latency and 602 probability of error during information transfer. To summarize, 603 reliable communication desires the following capabilities for the 604 underlying system: (1) seamless mobility support under normal 605 operating conditions, (2) efficient routing in the presence of 606 intermittent disconnection, (3) QoS aware routing, (4) support for 607 redundancy at all levels of a system (device, service, network, 608 storage etc.), and (5) support for rich and diverse communication 609 patterns, both within an IoT domain consisting of multiple IoT nodes 610 and one or more gateway nodes to the Internet and across multiple 611 such domains. 613 3.10. Self-Organization 615 The unified IoT architecture should be able to self-organize to meet 616 various application requirements, especially the capability to 617 quickly discover heterogeneous and relevant (local or global) 618 devices/data/services based on the context. This discovery can be 619 achieved through an efficient publish-subscribe service, or through 620 private community grouping/clustering based upon trust and other 621 security requirements. In the former case, the publish-subscribe 622 service must be efficiently implemented, able to support seamless 623 mobility, in- network caching, name-based routing, etc. In the 624 latter case, the IoT architecture needs to discover the private 625 community groups/clusters efficiently. 627 Another aspect of self-organization is decoupling the sensing 628 Infrastructure from applications. In a unified IoT architecture, 629 various applications run on top of a vast number of IoT devices. 630 Upgrading the firmware of the IoT devices is a difficult work. It is 631 also not practical to reprogram the IoT devices to accommodate every 632 change of the applications. The infrastructure and the application 633 specific logics need to be decoupled. A common interface is required 634 to dynamically configure the interactions between the IoT devices and 635 easily modify the application logics on top of the sensing/actuating 636 infrastructure [30] [31]. 638 3.11. Ad hoc and Infrastructure Mode 640 Depending upon whether there is communication infrastructure, an IoT 641 system can operate either in ad-hoc or infrastructure mode. 643 For example, a vehicle may determine to report its location and 644 status information to a server periodically through cellular 645 connection, or, a group of vehicles may form an ad-hoc network that 646 collectively detect road conditions around them. In the cases where 647 infrastructure is unavailable, one of the participating nodes may 648 choose to become the temporary gateway. 650 The unified IoT architecture needs to design a common protocol that 651 serves both modes. Such a protocol should address the challenges 652 that arise in these two modes: (1) scalability and low latency for 653 the infrastructure mode and (2) efficient neighbor discovery and ad- 654 hoc communication for the ad-hoc mode. Finally we note that hybrid 655 modes are very common in realistic IoT systems. 657 3.12. IoT Platform Management 659 An IoT platforms' service, control and data plane will be governed by 660 its own management infrastructure which includes distributed and 661 centralized middleware, discovery, naming, self-configuring, analytic 662 functions, and information dissemination to achieve specific IoT 663 system objectives [25][26][27]. Towards this, new IoT management 664 mechanisms and service metrics need to be developed to measure the 665 success of an IoTdeployment. Considering an IoT systems' defining 666 characteristics such as, its potential large number of IoT devices, 667 objective to save power, mobility, and ad hoc communication, 668 autonomic self-management mechanisms become very critical. Further 669 considering its hierarchical information processing deployment model, 670 the platform needs to orchestrate computational tasks according to 671 the involved sensors and the available computation resources which 672 may change over time. An efficient computation resource discovery 673 and management protocol is required to facilitate this process. The 674 trade-off between information transmission and processing is another 675 challenge. 677 4. State of the Art 679 Over the years, many stand-alone IoT systems have been deployed in 680 various domains. These systems usually adopt a vertical silo 681 architecture and support a small set of pre-designated applications. 682 A recent trend, however, is to move away from this approach, towards 683 a unified IoT architecture in which the existing silo IoT systems, as 684 well as new systems that are rapidly deployed. By unified, we mean 685 all the application and network components that use common APIs to 686 interact with each other. This will make their data and services 687 accessible to general Internet applications (as in ETSI- M2M and 688 oneM2M standards). In such a unified architecture, resources can be 689 accessed over Internet and shared across the physical boundaries of 690 the enterprise. However, current approaches to achieve this 691 objective are mostly based upon service overlays over the Internet, 692 whose inherent inefficiencies due to IP protocol [56] hinders the 693 architecture from satisfying the IoT requirements outlined earlier, 694 particularly in terms of scalability, security, mobility, and self- 695 organization, discussed more in Section 4.2. 697 4.1. Silo IoT Architecture 699 [IoT Server] 700 | 701 | 702 ______|_______ 703 _______ { } 704 { } { } 705 {IoT Dev}\ { Internet }---[IoT Application] 706 {_______} [IoTGW]---{ } 707 { } 708 {______________} 710 Figure 1:Silo architecture of standalone IoT systems 712 A typical standalone IoT system is illustrated in Figure 1, which 713 includes devices, a gateway, a server and applications. Many IoT 714 devices have limited power and computing resources, unable to 715 directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.) 716 protocols. Therefore they use the IoT gateway to the server. 717 Through the IoT server, applications can subscribe to data collected 718 by devices, or interact with devices. 720 There have been quite a few popular protocols for standalone IoT 721 systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc. 722 However, these protocols are operating at the device-level 723 abstraction, instead of information driven, which may sometimes lead 724 to a fragmented protocol space that requires a higher-level solution 725 for better interoperability. 727 4.2. Application-Layer Unified IoT Solutions 729 The current approach to a unified IoT architecture is to make IoT 730 gateways and servers adopt standard APIs. IoT devices connect to the 731 Internet through the standard APIs and IoT applications subscribe and 732 receive data through standard control and data APIs. Building on top 733 of today's Internet this application-layer unified IoT architecture 734 is the most practical approach towards a unified IoT platform. 735 Towards this, there are ongoing standardization efforts including 736 ETSI[3], oneM2M[4]. Network operators can use frameworks to build 737 common IOT gateways and servers for their customers. In addition, 738 IETF's CORE working group [5] is developing a set of protocols like 739 CoAP (Constrained Application Protocol) [78], that is a lightweight 740 protocol modeled after HTTP [79] and adapted specifically for the 741 Internet of Things (IoT). CoAP adopts the Representational State 742 Transfer (REST) architecture with Client-Server interactions. It 743 uses UDP as the underlying transport protocol with reliability and 744 multicast support. Both CoAP and HTTP are considered as the suitable 745 application level protocols for Machine-to-Machine communications, as 746 well as IoT. For example, oneM2M (which is one of leading standards 747 for unified M2M architecture) has both the protocol bindings to HTTP 748 and CoAP for its primitives. Figure 2 shows the architecture adopted 749 in this approach. 751 Publishing----[IoT Server]----Subscribing-- 752 | / | \ | 753 | / | \ | 754 | /______|_______ \ | 755 ___________ | /{ } publishing | 756 { } | | { } | | 757 {Smart Homes}\ | | { Internet }---------[IoT Application] 758 {___________} [IoTGW]---{ }\ | ________________ 759 | { } \ | { } 760 | {______________} [IoTGW]-{Smart Healthcare} 761 | | {________________} 762 Publishing [IoTGW] 763 | ____|_____ 764 | { } 765 ---{Smart Grid} 766 {__________} 768 Figure 2: Implementing an open IoT architecture through standardized APIs 769 on the IoT gateways and the server 771 4.2.1. Weaknesses of the Application-Layer Approach 773 The above application-layer approach can work with many different 774 protocols, but the system is built upon today's IP network, which has 775 inherent weaknesses towards supporting a unified IoT system. As a 776 result, it cannot satisfy some of the requirements we outlined in 777 Section 3: 779 o Naming. In current application-layer IoT systems the naming 780 scheme is host centric, i.e., the name of a given resource/service 781 is linked to the device that can provide it. In turn, device 782 names are coupled to IP addresses, which are not persistent in 783 mobile scenarios. On the other side, in IoT systems the same 784 service/ resource could be offered by different devices. 786 o Security and Trust. In IP, the security and trust model is based 787 on session established between two hosts. Session-based protocols 788 rely on the exchange of several messages before a secure session 789 is established. Use of such protocols in constrained IoT devices 790 can have serious consequences in terms of energy efficiency 791 because transmission and reception of messages is often more 792 costly than the cryptographic operations. The problem may be 793 amplified with the number of nodes the constrained device has to 794 interact with because of both the computation cost and per session 795 key state required to be managed by the constrained device. Also 796 the trust management schemes are still relatively weak, focusing 797 on securing communication channels rather than managing the data 798 that needs to be secured directly. Though key management in ICN 799 is no less complex than in host based interactions, the benefits 800 is associated with the security credentials in the content instead 801 of the host. Trust is via keys that are bound to names through 802 certificates whose private keys are held by the principals of the 803 system, with IP focusing on the channel model of security while 804 ICN focusing on the object model. 806 o Mobility. The application-layer approach uses IP addresses as 807 names at the network layer, which hinders the support for device/ 808 service mobility or flexible name resolution. Further the Layer 809 2/3 management, and application-layer addressing and forwarding 810 required to deploy current IoT solutions limit the scalability and 811 management of these systems. 813 o Resource constraints. The application-layer approach requires 814 every device to send data to an aggregator, gateway or to the IoT 815 server. Resource constraints of the IoT devices, especially in 816 power and bandwidth, could seriously limit the performance of this 817 approach. On the other hand, ICN supports in-network 818 computing/caching/storage, which can alleviate this problem. 820 o Traffic Characteristics. In this approach, applications are 821 written in a host-centric manner suitable for point-to-point 822 communication. IoT requires multicast support that is challenging 823 the application-layer based IoT systems today, which has only 824 limited deployment in current Internet. 826 o Contextual Communications. This application-layer based IoT 827 approach may not react to dynamic contextual changes in a timely 828 fashion. The main reason is that context lists are usually kept 829 at the IoT server in this approach, and they cannot help 830 efficiently route requests information at the network layer. 832 o Storage and Caching. The application-layer approach supports 833 application-centric storage and caching but not what ICN envisions 834 at the network layer, or flexible storage enabled via name-based 835 routing or name-based lookup. 837 o Self-Organization. The application-layer approach is topology- 838 based as it is bound to IP semantics, and thus does not 839 sufficiently satisfy the self-organization requirement. In 840 addition to topological self-organization, IoT also requires data- 841 and service-level self-organization [97], which is not supported 842 by this approach. 844 o Ad-hoc and infrastructure mode. As mentioned above, the overlay- 845 based approach lacks self-organization, and thus does not provide 846 efficient support for the ad-hoc mode of communication. 848 4.2.2. Suitability of Delay Tolerant Networking(DTN) 850 In [21][22], delay-tolerant networking (DTN) has been considered to 851 support future IoT architecture. DTN was created to support 852 information delivery in the presence of network disruptions and 853 disconnections, which has been extended to support heterogeneous 854 networks and name-based routing. The DTN Bundle Protocol is able to 855 achieve some of these same advantages and could be beneficially used 856 in an IoT network to, for example, decouple sender and receiver. The 857 DTN architecture is however centered around named endpoints (endpoint 858 IDs), which usually correspond to a host or a service, and is mainly 859 a way to transport data, while ICN provides a different paradigm 860 centered around named data that addresses additional issues for IoT 861 applications [23] through features such as information naming, 862 information discovery, information request and dissemination. Also, 863 the endpoint IDs could be used to also identify named content, 864 enabling the use of the bundle protocol as a transport mechanism for 865 an information-centric system. Such a use of the bundle protocol as 866 transport would however still require other components from an ICN 867 architecture such as naming conventions, so since the exact transport 868 is not a major focus of the issues in this draft, most of of the 869 discussions are applicable to a generic ICN architecture in general. 871 5. Advantages of using ICN for IoT 873 A key concept of ICN is the ability to name data independently from 874 the current location at which it is stored, which simplifies caching 875 and enables decoupling of sender and receiver. Using ICN to design 876 an architecture for IoT data potentially provides many such 877 advantages compared to using traditional host-centric networks and 878 other new architectures. This section highlights general benefits 879 that ICN could provide to IoT networks. 881 o Naming of Devices, Data and Services. The heterogeneity of both 882 network equipment deployed and services offered by IoT networks 883 leads to a large variety of data, services and devices. While 884 using a traditional host-centric architecture, only devices or 885 their network interfaces are named at the network level, leaving 886 to the application layer the task to name data and services. This 887 causes different applications to use different naming schemes, and 888 no consistent mapping from application layer names to network 889 names exist. In many common applications of IoT networks, data 890 and services are the main goal, and ICN provides an intuitive way 891 to name those in a way that can be utilized on the network layer 892 as well. Communication with a specific device is often secondary, 893 but when needed, the same ICN naming mechanisms can be used. The 894 network distributes content and provides a service, instead of 895 only sending data between two named devices. In this context, 896 data content and services can be provided by several devices, or 897 group of devices, hence naming data and services is often more 898 important than naming the devices. This naming mechanism also 899 enables self-configuration of the IoT system. 901 o Security and privacy. ICN advocates the model of object security 902 to secure data in the network. This concept is based on the idea 903 of securing information objects unlike session-based security 904 mechanisms which secure the communication channel between a pair 905 of nodes. ICN provides data integrity through Name-Data 906 Integrity, i.e., the guarantee that the given data corresponds to 907 the name with which it was addressed. Signature-based schemes can 908 additionally provide data authenticity, meaning establishing the 909 origin, or provenance, of the data, for example, by 910 cryptographically linking a data object to the identity of a 911 publisher. Confidentiality can be handled on a per object basis 912 based on keys established at the application level. All of this 913 means that the actual transmission of data does not have to be 914 secured as the same security mechanisms protect the data after 915 generation until consumed by a client, regardless of whether it is 916 in transit over a communication channel or stored in an 917 intermediate cache. In an ICN network, each individual object 918 within a stream of immutable objects could potentially be 919 retrieved from a cache in a different location. Having a trust 920 relationship with each of these different caches is not realistic. 921 Through Name-Data Integrity, ICN automatically guarantees data 922 integrity to the requester regardless of the location from where 923 it is delivered. The Object Security model also ensures that the 924 content is readily available in a secure state in the device 925 constraints are severe enough that it is not able to perform the 926 required cryptographic operations for Object Security, it may be 927 possible to offload this operation to a trusted gateway to which 928 only a single secure channel needs to be established. ICN can 929 also derive a name from a public key; cryptographic hash of a 930 public key also enables them to be self-certifying, i.e., 931 authenticating the resource object does not require an external 932 authority [25][26]. 934 o Distributed Caching and Processing. While caching mechanisms are 935 already used by other types of overlay networks, IoT networks can 936 potentially benefit even more from caching and in-network 937 processing systems, because of their resource constraints. 938 Wireless bandwidth and power supply can be limited for multiple 939 devices sharing a communication channel, and for small mobile 940 devices powered by batteries. In this case, avoiding unnecessary 941 transmissions with IoT devices to retrieve and distribute IoT data 942 to multiple places is important, hence processing and storing such 943 content in the network can save wireless bandwidth and battery 944 power. Moreover, as for other types of networks, applications for 945 IoT networks requiring shorter delays can benefit from local 946 caches and services to reduce delays between content request and 947 delivery. 949 o Decoupling between Sender and Receiver. IoT devices may be mobile 950 and face intermittent network connectivity. When specific data is 951 requested, such data can often be delivered by ICN without any 952 consistent direct connectivity between devices. Apart from using 953 structured caching systems as described previously, information 954 can also be spread by forwarding data opportunistically. 956 6. ICN Design Considerations for IoT 958 This section outlines some of the ICN specific design considerations 959 and challenges that must be considered when adopting an ICN design 960 for IoT applications and systems, and describes some of the trade 961 offs that will be involved in order to support large scale IoT 962 deployment with diverse application requirements. 964 Though ICN integrates content/service/host abstraction, name-based 965 routing, compute, caching/storage as part of the network 966 infrastructure, IoT requires special considerations given 967 heterogeneity of devices and interfaces such as for constrained 968 networking [61][119][121], data processing, and content distribution 969 models to meet specific application requirements which we identify as 970 challenges in this section. 972 6.1. Naming Devices, Data, and Services 974 The ICN approach of named data and services (i.e., device independent 975 naming) is typically desirable when retrieving IoT data. However, 976 data centric naming may also pose challenges. 978 o Naming of devices: Naming devices can be useful in an IoT system. 979 For example, actuators require clients to act on a specific node 980 of the deployed network, e.g. to switch it on or off; or it could 981 be necessary to access to a particular device for administrator 982 purposes. This can be achieved through the specific name that 983 uniquely identify the network entity of interest. Moreover, a 984 persistent name allows a device to change attachment point without 985 loosing its identity. A friendly way to address devices is using 986 contextual hierarchical names, where the same types of names as 987 for data objects can be used. To ensure that the device is always 988 reached, it is important that it is possible to disable caching 989 and request aggregation, if used, for such names. 991 o Size of data/service name: Content name can have variable length. 992 Since each name has to uniquely identify the content and can also 993 include self-certifying properties (e.g., the hash of the content 994 is bound to the name), its length can reach high values. In 995 particular, according to the specific application, content name 996 size can exceed Data size. This can be the case of IoT sensed 997 values that usually consist in few bytes: data could be as small 998 as a short integer in case of temperature values, or one-byte in 999 case of control messages of an actuator state (on/off). Moreover, 1000 a too long name would probably incur in fragmentation at the link 1001 layer, and related problems such as, several transmissions, delay 1002 and security issues. Viable solutions to handle ICN packets 1003 fragmentation and reassembly have been investigated in literature. 1004 For instance, the work in [105] proposes to perform the operations 1005 hop-by-hop: each hop fragments the packet that has to be forwarded 1006 and reassembles the packet received for further processing. This 1007 mechanism allows to efficiently handle the recovery of lost or 1008 corrupted fragments locally, thus reducing packet delivery 1009 failures that require application-level retransmissions. 1011 o Hash-based content name: Hash algorithms are commonly used to name 1012 content in order to verify that the content is the one requested. 1013 This is only possible in contexts where the requested object is 1014 already existing, and where there is a directory service to look 1015 up names or learned through a manifest service. This approach is 1016 suitable for systems with large data objects where it is important 1017 to verify the content. 1019 o Hierarchical names: The use of hierarchical names, such as in the 1020 CCN and NDN architectures make it easier to create names a priori 1021 and also provides a convenient way to use the same naming scheme 1022 for node names. Since the names are not self-certifying, this 1023 will require other mechanisms for verification of object 1024 integrity. If routing is also done on the hierarchical names, the 1025 system will loose some of its location independence and caching 1026 will mostly only be done on the path to the publisher. 1028 o Semantic and Metadata based content name: A semantic-based naming 1029 approach can allow a successful name retrieving through keywords 1030 (for example, 'noise level at position X'), even if a perfect 1031 matching of name is not available [62]. Moreover, enriching 1032 contents with metadata allows to better describe them and to 1033 establish association between similar ones. However this 1034 mechanism require more advanced functionality for matching of such 1035 metadata in data objects to the semantics of the name (such as 1036 comparing the position information of an object with the position 1037 information of the requested name). The need for such potentially 1038 computationally heavy tasks in intermediate nodes in the network 1039 may be considered understanding the trade-offs in terms of 1040 application and network performance. 1042 o Naming of services: Similar to naming of devices or data, services 1043 can be referred to with a unique identifier, provided by a 1044 specific device or by someone assigned by a central authority as 1045 the service provider. It can however also be a service provided 1046 by anyone meeting some certain metadata conditions. Example of 1047 services include content retrieval, that takes a content name/ 1048 description as input and returns the value of that content, and 1049 actuation, that takes an actuation command as input and possibly 1050 returns a status code afterwards. 1052 o Trust: Names can be used to verify the authenticity and integrity 1053 of the data. To provide security functionalities through names, 1054 it is possible to use different approaches. On one hand, 1055 hierarchical, schematized, Web-of-Trust models allow the public 1056 key verification. On the other hand, self-certifying names allow 1057 in-network integrity check of the name-key or name-content binding 1058 without the need of a Public Key Infrastructure (PKI) or other 1059 third party to establish whether the key is trustworthy or not. 1060 This can be realized (i) directly: the hash of the content is 1061 bound to the name; or (ii) indirectly: first, the hash of the 1062 content is signed with the secret key of the publisher, then the 1063 public key of the publisher and the signed hash are bound to the 1064 name [44]. The hash algorithm can be applied to already existing 1065 contents and where there is a directory service or manifests to 1066 look up names. In case of contents not yet published, but 1067 generated on demand, the hash cannot be known a priori. Thus, 1068 different trust mechanisms should be investigated. Moreover, 1069 self-certified names approach can hide content semantics, thus 1070 making names less human friendly. Since trends show that users 1071 prefer to find contents through search engine using keywords, non- 1072 human-friendly names could be a barrier unless the content is 1073 enriched with keywords. But, this problem does not concern M2M 1074 applications. In fact, human-readable names may not be useful in 1075 a context of just communicating machines. 1077 o Flexibility: Further challenges arise for hierarchical naming 1078 schema: referring to requirements on "constructible names" and 1079 "on-demand publishing" [35][36]. TThe former entails that each 1080 user is able to construct the name of a desired data item through 1081 specific algorithms and that it is possible to retrieve 1082 information also using partially specified names. The latter 1083 refers the possibility to request a content that has not yet been 1084 published in the past, thus triggering its creation. 1086 o Scoping : From an application's point of view, scopes are used to 1087 gather related data. From the network's perspective, instead, 1088 scopes are used to mark where the content is available[65]. For 1089 instance, nodes involved in caching coordination can vary 1090 according to scope[66]. As a consequence, scoping allows to limit 1091 packet request propagation, improving bandwidth and energy 1092 resources usage, and control content dissemination thanks to 1093 access control rules, different for each scope[64]. However, 1094 relying on scoping for security/privacy has been shown to not work 1095 all that well for IP, and is unlikely to work well for ICN either. 1096 However, scoping may be useful to limit interest propagation, 1097 provide a simple means to attain context-sensitive communication, 1098 etc. Finally, perimeter- and channel-based access control is 1099 often violated in current networks to enable over-the-wire updates 1100 and cloud-based services, so scoping is unlikely to replace a need 1101 for data-centric security in ICN. 1103 o Confidentiality: As names can reveal information about the nature 1104 of the communication or more importantly violate privacy, 1105 mechanisms for name confidentiality should be available in the 1106 ICN-IoT architecture. To grant confidentiality protection, some 1107 approaches have been proposed in order to handle access control in 1108 ICN naming scheme such as Attribute-Based Encryption [63] and 1109 access control delegation scheme [64]. In the first solution, a 1110 Trusted Third Party assigns a set of attributes to each network 1111 entity. Then, a publisher (i) encrypts the data with a random 1112 key; (II) generates the metadata for the decryption phase; (iii) 1113 creates an access policy used to encrypt the random key; (iv) 1114 appended the encrypted key to the content name. When the consumer 1115 receives the packet, if its attributes satisfy the hidden policy 1116 in the name, it can get the random key protected in the name and 1117 decrypt the data. The second solution introduces a new trusted 1118 network entity (i.e., Access Control Provide). In this case, when 1119 a publisher generates a content, it also creates an access control 1120 policy and send it to an Access Control Provider. This network 1121 entity stores the access control policy, to which it associates a 1122 Uniform Resource Identifier (URI). This URI is sent to the 1123 publisher and included in the advertisements of the content. 1124 Then, when a subscriber tries to access a protected content, it 1125 can authenticate himself and request authorization for the 1126 particular policy to the Access Control Provider through the URI. 1128 6.2. Name Resolution 1130 Inter-connecting numerous IoT entities, as well as establishing 1131 reachability to them, requires a scalable name resolution system 1132 considering several dynamic factors like mobility of end points, 1133 service replication, in-network caching, failure or migration [57] 1134 [69] [70] [91]. The objective is to achieve scalable name resolution 1135 handling static and dynamic ICN entities with low complexity and 1136 control overhead. In particular, the main requirements/challenges of 1137 a name space (and the corresponding Name Resolution System where 1138 necessary) are [50] [52]: 1140 o Scalability: The first challenge faced by ICN-IoT name resolution 1141 system is its scalability. Firstly, the approach has to support 1142 billions of objects and devices that are connected to the 1143 Internet, many of which are crossing administrative domain 1144 boundaries. Second of all, in addition to objects/devices, the 1145 name resolution system is also responsible for mapping IoT 1146 services to their network addresses. Many of these services are 1147 based upon contexts, hence dynamically changing, as pointed out in 1148 [57]. As a result, the name resolution should be able to scale 1149 gracefully to cover a large number of names/services with wide 1150 variations (e.g., hierarchical names, flat names, names with 1151 limited scope, etc.). Notice that, if hierarchical names are 1152 used, scalability can be also supported by leveraging the inherent 1153 aggregation capabilities of the hierarchy. Advanced techniques 1154 such as hyperbolic routing [86] may offer further scalability and 1155 efficiency. 1157 o Deployability and inter-operability: Graceful deployability and 1158 interoperability with existing platforms is a must to ensure a 1159 naming schema to gain success on the market [7]. As a matter of 1160 fact, besides the need to ensure coexistence between IP-centric 1161 and ICN-IoT systems, it is required to make different ICN-IoT 1162 realms, each one based on a different ICN architecture, to inter- 1163 operate. 1165 o Latency: For real-time or delay sensitive M2M application, the 1166 name resolution should not affect the overall QoS. With reference 1167 to this issue it becomes important to circumvent too centralized 1168 resolution schema (whatever the naming style, i.e, hierarchical or 1169 flat) by enforcing in-network cooperation among the different 1170 entities of the ICN-IoT system, when possible [95]. In addition, 1171 fast name lookup are necessary to ensure soft/hard real time 1172 services [106][107][108]. This challenge is especially important 1173 for applications with stringent latency requirements, such as 1174 health monitoring, emergency handling and smart transportation 1175 [109]. 1177 o Locality and network efficiency: During name resolution the named 1178 entities closer to the consumer should be easily accessible 1179 (subject to the application requirements). This requirement is 1180 true in general because, whatever the network, if the edges are 1181 able to satisfy the requests of their consumers, the load of the 1182 core and content seek time decrease, and the overall system 1183 scalability is improved. This facet gains further relevance in 1184 those domains where an actuation on the environment has to be 1185 executed, based on the feedbacks of the ICN-IoT system, such as in 1186 robotics applications, smart grids, and industrial plants [97]. 1188 o Agility: Some data items could disappear while some other ones are 1189 created so that the name resolution system should be able to 1190 effectively take care of these dynamic conditions. In particular, 1191 this challenge applies to very dynamic scenarios (e.g., VANETs) in 1192 which data items can be tightly coupled to nodes that can appear 1193 and disappear very frequently. 1195 6.3. Security and Privacy 1197 Security and privacy is crucial to all the IoT applications 1198 applications including the use cases discussed in Section 2 and 1199 subjected to the information context. To exemplify this, in one 1200 recent demonstration,it was shown that passive tire pressure sensors 1201 in cars could be hacked adversely affecting the automotive system 1202 [74], while at the same time the information can be used by a public 1203 traffic management system to improve road safety. The ICN paradigm 1204 is information-centric as opposed to state-of-the-art host-centric 1205 Internet. Besides aspects like naming, content retrieval and caching 1206 this also has security implications. ICN advocates the model of 1207 trust in content rather than a direct trust in network host mode. 1208 This brings in the concept of Object Security which is contrary to 1209 session-based security mechanisms such as TLS/DTLS prevalent in the 1210 current host-centric Internet. Object Security is based on the idea 1211 of securing information objects unlike session-based security 1212 mechanisms which secure the communication channel between a pair of 1213 nodes for unicast, (or among a set of nodes for multicast/broadcast). 1214 This reinforces an inherent characteristic of ICN networks i.e. to 1215 decouple senders and receivers. Even session based trust association 1216 can be realized in ICN [83], that offers host-independence allowing 1217 authentication and authorization to be separated from session 1218 encryption, allowing multiple end points to meet specific service 1219 objectives. In the context of IoT, the Object Security model has 1220 several concrete advantages. Many IoT applications have data and 1221 services are the main goal and specific communication between two 1222 devices is secondary. Therefore, it makes more sense to secure IoT 1223 objects instead of securing the session between communicating 1224 endpoints. Though ICN includes data-centric security features the 1225 mechanisms have to be generic enough to satisfy multiplicity of 1226 policy requirements for different applications. Furthermore security 1227 and privacy concerns have to be dealt in a scenario-specific manner 1228 with respect to network function perspective spanning naming, name- 1229 resolution, routing, caching, and ICN-APIs. The work by the JOSE WG 1230 [80] provides solution approaches to address some of these concerns 1231 for object security for constrained devices and should be considered 1232 to see what can be applied to an ICN architecture. In general, we 1233 feel that security and privacy protection in IoT systems should 1234 mainly focus on the following aspects: confidentiality, integrity, 1235 authentication and non-repudiation, and availability. Even though, 1236 implementing security and privacy methods in IOT systems faces 1237 different challenges than in other systems, like IP. Specifically, 1238 below we discuss the challenges in the constrained and infrastructure 1239 part of the network. 1241 o In the resource-constrained nodes, energy limitation is the 1242 biggest challenge. Moreover, it has to deliver its data over a 1243 wireless link for a reasonable period of time on a coin cell 1244 battery. As a result, traditional security/privacy measures are 1245 impractical to be implemented in the constrained part. In this 1246 case, one possible solution might be utilizing the physical 1247 wireless signals as security measures [75] [55]. 1249 o In the infrastructure part, we have several new threats introduced 1250 by ICN-IoT [85] particularly in architectures employing name 1251 resolution service [119]. Below we list several possible attacks 1252 to a name resolution service that is critical to ICN-IoT : 1254 1. Each IoT device is given an ICN name. The name spoofing 1255 attack is a masquerading threat, where a malicious user A 1256 claims another user B's name and attempts to associate it with 1257 A's own network address NA-A, by announcing the mapping (ID-B, 1258 NA-A). The consequence of this attack is a denial of service 1259 as it can cause traffic directed for B to be directed to A's 1260 network address. 1262 2. The stale mapping attack is a message manipulation attack 1263 involving a malicious name resolution server. In this attack, 1264 if a device moves and issues an update, the malicious name 1265 resolution server can purposely ignore the update and claim it 1266 still has the most recent mapping. Perhaps worse, a name 1267 resolution server can selectively choose which (possibly 1268 stale) mapping to give out during queries. The result is a 1269 denial of service. 1271 3. The third potential attack, false announcement attack, is an 1272 information modification attack that results in illegitimate 1273 resource consumption. User A, which is in network NA1, claims 1274 its ID-A binds to a different network address, (ID-A, NA2). 1275 Thus A can direct its traffic to network NA2, which causes 1276 NA2's network resources to be consumed. 1278 4. The collusion attack is an example of an information 1279 modification attack in which a malicious user, its network and 1280 the location where the mapping is stored collude with each 1281 other. The objective behind the malicious collusion is to 1282 allow for a fake mapping involving a false network address to 1283 pass the verification and become stored in the storage place. 1285 5. An intruder may insert fake/false sensor data into the 1286 network. The consequence might be an increase in delay and 1287 performance degradation for network services and applications. 1289 o As far as the IoT application server is concerned, data privacy is 1290 one of the biggest concerns. IoT data is collected and stored on 1291 such servers, which usually run learning algorithms to extract 1292 patterns from such data. In this case, it is important to adopt a 1293 framework that enables privacy-preserving learning techniques. 1294 The framework defines how data is collected, modified (to satisfy 1295 the privacy requirement), and transmitted to application 1296 developers. 1298 6.4. Caching 1300 In-network caching helps bring data closer to consumers, but its 1301 usage differs in constrained and infrastructure part of the IoT 1302 network. 1304 Caching in ICN-IoT faces several challenges: 1306 o An important challenge is to determine which nodes on the routing 1307 path should cache the data. According to [52], caching the data 1308 on a subset of nodes can achieve a better gain than caching on 1309 every en-route routers. In particular, the authors propose a 1310 "selective caching" scheme to locate those routers with better hit 1311 probabilities to cache data. According to [53], selecting a 1312 random router to cache data is as good as caching the content 1313 everywhere. In [88], the authors suggest that edge caching 1314 provides most of the benefits of in-network caching typically 1315 discussed in NDN, with simpler deployment. However, it and other 1316 papers consider workloads that are analogous to today's CDNs, not 1317 the IoT applications considered here. Further work is likely 1318 required to understand the appropriate caching approach for IoT 1319 applications. 1321 o Another challenge in ICN-IoT caching is what to cache for IoT 1322 applications. In many IoT applications, customers often access a 1323 stream of sensor data, and as a result, caching a particular 1324 sensor data item for longer time may not be beneficial. In [90], 1325 proposed a caching scheme that ensures that older instances of the 1326 same sensor stream were first to be evicted from the cache when 1327 needed. In [55], the authors suggest to cache IoT services on 1328 intermediate routers, and in [57], the authors suggest to cache 1329 control information such as pub/sub lists on intermediate nodes. 1330 In addition, it is yet unclear what caching means in the context 1331 of actuation in an IoT system. For example, it could mean caching 1332 the result of a previous actuation request (using other ICN 1333 mechanisms to suppress repeated actuation requests within a given 1334 time period), or have little meaning at all if actuation uses 1335 authenticated requests as in [89]. 1337 o Another challenge is that the efficiency of distributed caching 1338 may be application dependent. When content popularity is 1339 heterogeneous, some content is often requested repeatedly. In 1340 that case, the network can benefit from caching. Another case 1341 where caching would be beneficial is when devices with low duty 1342 cycle are present in the network and when access to the cloud 1343 infrastructure is limited. In [90], it is also shown that there 1344 are benefits to caching in the network when edge links are lossy, 1345 in particular if losses occur close to the content producer, as is 1346 common in wireless IoT networks. However, using distributed 1347 caching mechanisms in the network is not useful when each object 1348 is only requested at most once, as a cache hit can only occur for 1349 the second request and later. It may also be less beneficial to 1350 have caches distributed throughout ICN nodes in cases when there 1351 are overlays of distributed repositories, e.g., a cloud or a 1352 Content Distribution Network (CDN), from which all clients can 1353 retrieve the data. Using ICN to retrieve data from such services 1354 may add some efficiency, but in case of dense occurrence of 1355 overlay CDN servers the additional benefit of caching in ICN nodes 1356 would be lower. Another example is when the name refers to an 1357 object with variable content/state. For example, when the last 1358 value for a sensor reading is requested or desired, the returned 1359 data should change every time the sensor reading is updated. In 1360 that case, ICN caching may increase the risk that cache 1361 inconsistencies result in old data being returned. 1363 6.5. Storage 1365 Storage is useful for IoT systems both at longer and small time 1366 scales. 1368 Long terms storage can be distributed at vantage points including 1369 both the edge and the main IoT service aggregation points such as in 1370 the data centers, the difference being in the size of data, 1371 processing intelligence and heterogeneity of information that has to 1372 be dealt at the two points. The purpose of long terms storage at the 1373 edge is to analyze, filter, aggregate and re-publish data for 1374 consumption by either by the parent service components or directly by 1375 the consumers. The aggregation service points, republish data to be 1376 presented as part of the global pub/sub service to interested 1377 consuming parties. Long term storage for IoT data also serves the 1378 purpose of data backup and replication. Specifically, we face 1379 several issues here. Firstly, we need to decide how many replicas we 1380 should have for each stream of IoT data, and where we should store 1381 these replicas. Given that many IoT applications consume data 1382 locally, storage locations should be kept near to data sources as 1383 well. Since IoT data are mostly appended to the end of a stream, 1384 instead of being updated, managing multiple replicas becomes easier. 1385 Secondly, we need to adopt a mechanism that can efficiently route 1386 traffic to the nearest data replica. ICN provides several solutions 1387 to this problem. For example, global name resolution service (GNRS) 1388 can keep track of each replica's location [56]. 1390 Short-term in-network storage (here storage refers to temporary 1391 buffer when an outgoing link is not available) helps improve 1392 communication reliability, especially when network links are 1393 unreliable, such as wireless links. ICN-IoT could adopt a 1394 generalized storage-aware routing algorithm to support delay and 1395 disruption tolerance in the routing layer. Each router employs in- 1396 network storage that facilitates store vs. forward decisions in 1397 response to varying link quality and disconnections [111]. These 1398 decisions are based on both short-term and long-term path quality 1399 metrics. In addition, packets along paths that become disconnected 1400 are handled by a disruption tolerant networking (DTN) mode of the 1401 protocol with delayed delivery and replication features. In 1402 particular, each router maintains two types of topology information: 1403 (i) An intra-partition graph is formed by collecting flooded link 1404 state advertisements which carry fine-grained, time-sensitive 1405 information about the intra-network links; (ii) A DTN graph is 1406 maintained via epidemically disseminated link-state advertisements 1407 which carry connection probabilities between all nodes in the 1408 network. In-network storage faces the following challenges: (1) when 1409 to store and how long to store the data, and (2) the next step after 1410 the short-term storage. In [90] the authors also shows that it is 1411 beneficial to store data even for shorter periods of time (and even 1412 if only a single requester exist) if the network is lossy such that 1413 retransmissions and error recovery can be done locally instead of 1414 end-to-end. 1416 6.6. Routing and Forwarding 1418 ICN-IoT supports both device-to-device (D2D) communication and 1419 device-to-infrastructure (D2I) communication. Some D2D 1420 communications are within a single IoT domain, while others might 1421 cross IoT domains involving data forwarding within the source IoT 1422 domain, in the infrastructure network, and within the destination IoT 1423 domain. D2I communications involve data forwarding within the source 1424 IoT domain and in the infrastructure network. Data forwarding within 1425 an IoT domain can adopt sensor network popular routing protocols such 1426 as RPL [81], AODV[82], etc. The main challenge it faces is the 1427 resource constraint of the IoT nodes. In order to address this 1428 challenge, we could adopt a light-weight, much shorter ICN name for 1429 each communicating party within an IoT domain (see Section 6.12 for 1430 details). Before we leave the IoT domain, the gateway node will 1431 translate the party's short ICN name to its original ICN name. Data 1432 forwarding in the ICN infrastructure part can adopt either direct 1433 name-based routing or indirect routing using a name resolution 1434 service (NRS). 1436 o In direct name-based routing, packets are forwarded by the name of 1437 the data [91][61][71] or the name of the destination node [72]. 1438 Here, the main challenge is to keep the ICN router state required 1439 to route/forward data low. This challenge becomes more serious 1440 when a flat naming scheme is used due to the lack of aggregation 1441 capabilities. 1443 o In indirect routing, packets are forwarded based upon the locater 1444 of the destination node, and the locater is obtained through the 1445 name resolution service. In particular, the name-locater binding 1446 can be done either before routing (i.e., static binding) or during 1447 routing (i.e., dynamic binding). For static binding, the router 1448 state is the same as that in traditional routers, and the main 1449 challenge is the need to have fast name resolution, especially 1450 when the IoT nodes are mobile. For dynamic binding, ICN routers 1451 need to main a name-based routing table, hence the challenge of 1452 keeping the state information low. At the same time, the need of 1453 fast name resolution is also critical. 1455 6.7. Mobility Management 1457 Considering the diversity of IoT applications mobility ranges from 1458 tracking sensor data from mobile human beings to large fleets of 1459 diverse mobile elements such as drones, vehicles, trucks, trains 1460 associated with a transport infrastructure. These mobility could be 1461 over heterogeneous access infrastructure ranging from short range 1462 802.15.4 to cellular radios. Further, handling information delivery 1463 in ad hoc setting involving vehicles, road side units (RSU) and the 1464 corresponding infrastructure based services offers more challenges. 1465 ICN architectures has generally been shown to handle consumer and 1466 producer mobility [59], and even suitability to V2V scenarios [60]. 1467 Networking tools to handle mobility varies with application 1468 requirements, which varies from being tolerant to packet losses and 1469 latency to those that are mission critical with stringent requirement 1470 on both these QoS metrics. 1472 Related to this, the challenge is to quantify the cost associated 1473 with mobility management both in the control and forwarding plane, to 1474 handle both static binding versus dynamic binding (dynamic binding 1475 here refers to enabling seamless mobility) of named resources to its 1476 location when either or both consumer and producer is mobile. 1478 During a network transaction, either the data producer or the 1479 consumer may move away and thus we need to handle the mobility to 1480 avoid information loss. ICN may differentiate mobility of a data 1481 consumer from that of a producer: 1483 o When a consumer moves to a new location after sending out the 1484 request for Data, the Data may traverse to the previous point of 1485 attachment (PoA) but leaving copies of it through its previous 1486 path, which can be retrieved by the consumer by retransmitting its 1487 request, a technique used by direct routing approach. Indirect 1488 routing approach doesn't differentiate between consumer and 1489 producer mobility [91], as it only requires an update to the name 1490 resolution system, which can update the routers to rebind the 1491 named resource to its new location, while using late-binding to 1492 route the packet from the previous PoA to the new one. 1494 o If the data producer itself has moved, the challenge is to control 1495 the control overhead while searching for a new data producer (or 1496 for the same data producer in its new position) [58]. To this 1497 end, flooding techniques could be used rediscover the producer, or 1498 the direct routing techniques can be enhanced with late-binding 1499 feature to enable seamless mobility [59]. 1501 6.8. Contextual Communication 1503 Contextualization through metadata in ICN control or application 1504 payload allows IoT applications to adapt to different environments. 1505 This enables intelligent networks which are self-configurable and 1506 enable intelligent networking among consumers and producers [55]. 1507 For example, let us look at the following smart transportation 1508 scenario: "James walks on NYC streets and wants to find an empty cab 1509 closest to his location." In this example, the context is the 1510 relative locations of James and taxi drivers. A context service, as 1511 an IoT middleware, processes the contextual information and bridges 1512 the gap between raw sensor information and application requirements. 1513 Alternatively, naming conventions could be used to allow applications 1514 to request content in namespaces related to their local context 1515 without requiring a specific service, such as /local/geo/ 1516 mgrs/4QFJ/123/678 to retrieve objects published in the 100m grid area 1517 4QFJ 123 678 of the military grid reference system (MGRS). In both 1518 cases, trust providers may emerge that can vouch for an application's 1519 local knowledge. 1521 However, extracting contextual information on a real-time basis is 1522 very challenging: 1524 o We need to have a fast context resolution service through which 1525 the involved IoT devices can continuously update its contextual 1526 information to the application (e.g., each taxi's location and 1527 Jame's information in the above example). Or, in the namespace 1528 driven approach, mechanisms for continuous nearest neighbor 1529 queries in the namespace need to be developed. 1531 o The difficulty of this challenge grows rapidly when the number of 1532 devices involved in a context as well as the number of contexts 1533 increases. 1535 6.9. In-network Computing 1537 In-network computing enables ICN routers to host heterogeneous 1538 services catering to various network functions and applications 1539 needs. Contextual services for IoT networks require in-network 1540 computing, in which each sensor node or ICN router implements context 1541 reasoning [55]. Another major purpose of in-network computing is to 1542 filter and cleanse sensed data in IoT applications, that is critical 1543 as the data is noisy as is [73]. 1545 Named Function Networking [113] describes an extension of the ICN 1546 concept to named functions processed in the network, which could be 1547 used to generate data flow processing applications well-suited to, 1548 for example, time series data processing in IoT sensing applications. 1550 Related to this, is the need to support efficient function naming. 1551 Functions, input parameters, and the output result could be 1552 encapsulated in the packet header, the packet body, or mixture of the 1553 two (e.g. [31]). If functions are encapsulated in packet headers, 1554 the naming scheme affects how a computation task is routed in the 1555 network, which IoT devices are involved in the computation task (e.g. 1556 [54]), and how a name is decomposed into smaller computation tasks 1557 and deployed in the network for a better performance. 1559 Another is challenge is related to support computing-aware routing. 1560 Normal routing is for forwarding requests to the nearest source or 1561 cache and return the data to the requester, whereas the routing for 1562 in-network computation has a different purpose. If the computation 1563 task is for aggregating sensed data, the routing strategy is to route 1564 the data to achieve a better aggregation performance [51]. 1566 In-network computing also includes synchronization challenges. Some 1567 computation tasks may need synchronizations between sub-tasks or IoT 1568 devices, e.g. a device may not send data as soon as it is available 1569 because waiting for data from the neighbours may lead to a better 1570 aggregation result; some devices may choose to sleep to save energy 1571 while waiting for the results from the neighbours; while aggregating 1572 the computation results along the path, the intermediate IoT devices 1573 may need to choose the results generated within a certain time 1574 window. 1576 6.10. Self-Orgnization 1578 General IoT deployments involves heterogeneous IoT systems consisting 1579 of embedded systems, aggregators and service gateways in a IoT 1580 domain. To scale IoT deployments to large scale, scope-based self- 1581 organization is required. This relates to IoT system middleware 1582 functions [118] which include device bootstrapping and discovery, 1583 assigning local/global names to device and/or content, security and 1584 trust management functions towards device authentication and data 1585 privacy. ICN based on-boarding protocols have been studied [96] and 1586 has shown to offer significant savings compared to existing 1587 approaches. These challenges span both the constrained devices as 1588 well as interaction with the aggregators and the service gateways 1589 which may have to contact external services like authentication 1590 servers to on-board devices. A critical performance optimization 1591 metric of these functions while operating at scale is to have low 1592 control and data overhead in order to maximize energy efficiency. 1593 Further, in the infrastructure part scalable name-based resolution 1594 mechanisms, pub/sub services, storage and caching, and in-network 1595 computing techniques should be studied to meet the scope-based 1596 content dissemination needs of an ICN-IoT system. 1598 6.11. Communications Reliability 1600 ICN offers many ingredients for reliable communication such as multi- 1601 home interest anycast over heterogeneous interfaces, caching, and 1602 forwarding intelligence for multi-path routing leveraging state- 1603 based forwarding in protocols like CCN/NDN. However these features 1604 have not been analyzed from the QoS perspective when heterogeneous 1605 traffic patterns are mixed in a router, in general QoS for ICN is an 1606 open area of research [121]. In-network reliability comes at the 1607 cost of a complex network layer; hence the research challenges here 1608 is to build redundancy and reliability in the network layer to handle 1609 a wide range of disruption scenarios such as congestion, short or 1610 long term disconnection, or last mile wireless impairments. Also an 1611 ICN network should allow features such as opportunistic store and 1612 forward mechanism to be enabled only at certain points in the 1613 network, as these mechanisms also entail overheads in the control and 1614 forwarding plane overhead which will adversely affect application 1615 throughput, Please see the discussion on in-network storage 1616 (Section 6.5) for more details . 1618 6.12. Resource Constraints and Heterogeneity 1620 An IoT architecture should take into consideration resource 1621 constraints of (often) embedded IoT nodes. Having globally unique 1622 IDs is a key feature in ICN, which may consist of tens of bytes. 1623 Each device would have a persistent and unique ID no matter when and 1624 where it moves. It is also important for ICN-IoT to keep this 1625 feature. However, always carrying the long ID in the packet header 1626 may not be always feasible over a low-rate layer-2 protocol such as 1627 802.15.4. To solve this issue, ICN can operate using lighter-weight 1628 packet header and a much shorter locally unique ID (LUID in short). 1629 In this way, we map a device's long global ID to its short LUID when 1630 we reach the local area IoT domain. To cope with collisions that may 1631 occur in this mapping process, we let each domain have its own global 1632 ID to LUID mapping which is managed by a gateway deployed at the edge 1633 of the domain. Different from NAT and other existing domain-based or 1634 gateway-based solutions, ICN-IoT does not change the identity the 1635 application uses. The applications, either on constrained IoT 1636 devices or on the infrastructure nodes, still use the long global IDs 1637 to identify each other, while the network performs translation which 1638 is transparent to these applications. An IoT node carries its global 1639 ID no matter where it moves, even when it is relocated to another 1640 local IoT domain and is assigned with a new LUID. This ensures the 1641 global reach-ability and mobility handling yet still considers 1642 resource constraints of embedded devices. 1644 In addition, the optimizations for other components of the ICN-IoT 1645 system (described in earlier subsections) can lead to optimized 1646 energy efficiency as well. 1648 7. Differences from T2TRG 1650 T2TRG [9] is a IoT research group under IRTF focusing on research 1651 challenges of realizing IoT solutions considering IP as the narrow 1652 waist. IP-IoT has been a research topic over a decade and with 1653 active industry solutions, hence this group provides an venue to 1654 study advanced issues related to IP-IoT security, provisioning, 1655 configuration and inter-operability considering various heterogeneous 1656 application environments. ICN-IoT is a recent research effort, where 1657 the objective to exploit ICN feature of name based routing and 1658 security, caching, multicasting, mobility etc in an end-to-end manner 1659 to enable IoT services spanning both ad hoc, infrastructure and 1660 hybrid scenarios. More detailed comparison of IP-IoT versus ICN-IoT 1661 is given in Section 4. 1663 8. Security Considerations 1665 ICN puts security in the forefront of its design which ICN-IoT can 1666 leverage to build applications with varying security requirements, 1667 which has been discussed quite elaborately in this draft. This is an 1668 informational draft and doesn't create new considerations beyond what 1669 has been discussed. 1671 9. Conclusions 1673 This draft offers a comprehensive view of the benefits and design 1674 challenges of using ICN to deliver IoT services, not only because of 1675 its suitability for constraint networks but also towards ad hoc and 1676 infrastructure environments. The draft begins by motivating the need 1677 for ICN-IoT by considering popular IoT scenarios and then delves into 1678 understanding the IoT requirements from application and networking 1679 perspective. We then discuss why current approach of application 1680 layer unified IoT solutions based on IP falls short of meeting these 1681 requirements, and how ICN architecture is a more suitable towards 1682 this. We then elaborate on the design challenges in realizing an 1683 ICN-IoT architecture at scale and one that offers reliability, 1684 security, energy efficiency, mobility, self-organization among others 1685 to accommodate varying IoT service needs. 1687 10. Acknowledgements 1689 We thank all the contributors, reviewers and the valuable comments 1690 offered by the chairs to improve this draft. 1692 11. Informative References 1694 [1] Cisco System Inc., CISCO., "Cisco visual networking index: 1695 Global mobile data traffic forecast update.", 2016-2021. 1697 [2] Shafig, M., Ji, L., Liu, A., Pang, J., and J. Wang, "A 1698 first look at cellular machine-to-machine traffic: large 1699 scale measurement and characterization.", Proceedings of 1700 the ACM Sigmetrics , 2012. 1702 [3] The European Telecommunications Standards Institute, 1703 ETSI., "http://www.etsi.org/.", 1988. 1705 [4] Global Intiative for M2M Standardization, oneM2M., 1706 "http://www.onem2m.org/.", 2012. 1708 [5] Constrained RESTful Environments, CoRE., 1709 "https://datatracker.ietf.org/wg/core/charter/.", 2013. 1711 [6] Ghodsi, A., Shenker, S., Koponen, T., Singla, A., 1712 Raghavan, B., and J. Wilcox, "Information-Centric 1713 Networking: Seeing the Forest of the Trees.", Hot Topics 1714 in Networking , 2011. 1716 [7] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content 1717 Broadcast Efficiency in Routers with Integrated Caching.", 1718 Proceedings of the IEEE Symposium on Computers and 1719 Communications (ISCC) , 2011. 1721 [8] NSF FIA project, MobilityFirst., 1722 "http://mobilityfirst.winlab.rutgers.edu/", 2010. 1724 [9] Thing-to-Thing Research Group, T2TRG., 1725 "https://datatracker.ietf.org/rg/t2trg/about/", 2017. 1727 [10] OPC Foundation, OPC., "https://opcfoundation.org/", 2017. 1729 [11] Kim, B., Lee, S., Lee, Y., Hwang, I., and Y. Rhee, 1730 "Mobiiscape: Middleware Support for Scalable Mobility 1731 Pattern Monitoring of Moving Objects in a Large-Scale 1732 City.", Journal of Systems and Software, Elsevier, 2011. 1734 [12] Dietrich, D., Bruckne, D., Zucker, G., and P. Palensky, 1735 "Communication and Computation in Buildings: A Short 1736 Introduction and Overview", IEEE Transactions on 1737 Industrial Electronics, 2010. 1739 [13] Keith, K., Falco, F., and K. Scarfone, "Guide to 1740 Industrial Control Systems (ICS) Security", NIST, 1741 Technical Report 800-82 Revision 1, 2013. 1743 [14] Darianian, M. and Martin. Michael, "Smart home mobile 1744 RFID-based Internet-of-Things systems and services.", 1745 IEEE, ICACTE, 2008. 1747 [15] Zhu, Q., Wang, R., Chen, Q., Chen, Y., and W. Qin, "IOT 1748 Gateway: Bridging Wireless Sensor Networks into Internet 1749 of Things", IEEE/IFIP, EUC, 2010. 1751 [16] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X., and 1752 G. Wang, "Contextualized information-centric home 1753 network", ACM, Sigcomm, 2013. 1755 [17] Huang, R., Zhang, J., Hu, Y., and J. Yang, "Smart Campus: 1756 The Developing Trends of Digital Campus", 2012. 1758 [18] Yan, Y., Qian, Y., Hu, Y., and J. Yang, "A Survey on Smart 1759 Grid Communication Infrastructures: Motivations, 1760 Requirements and Challenges", IEEE Communications Survey 1761 and Tutorials, 2013. 1763 [19] Chai, W., Katsaros, K., Strobbe, M., and P. Romano, 1764 "Enabling Smart Grid Applications with ICN", ICN Sigcomm, 1765 2015. 1767 [20] Katsaros, K., Chai, W., Wang, N., and G. Pavlou, 1768 "Information-centric Networking for Machine-to-Machine 1769 Data Delivery: A Case Study in Smart Grid Applications", 1770 IEEE Network, 2014. 1772 [21] Mael, A., Maheo, Y., and F. Raimbault, "CoAP over BP for a 1773 delay-tolerant internet of things", Future Internet of 1774 Things and Cloud (FiCloud), IEEE, 2015. 1776 [22] Patrice, R. and H. Rivano, "Tests Scenario on DTN for IOT 1777 III Urbanet collaboration", Dissertation, INRIA, 2015. 1779 [23] Kevin, F., "Comparing Information-Centric and Delay- 1780 Tolerant Networking", Local Computer Networks (LCN), 2012 1781 IEEE 37th Conference on. IEEE, 2012.. 1783 [24] Miao, Y. and Y. Bu, "Research on the Architecture and Key 1784 Technology of Internet of Things (loT) Applied on Smart 1785 Grid", IEEE, ICAEE, 2010. 1787 [25] Castro, M. and A. Jara, "An analysis of M2M platforms: 1788 challenges and opportunities for the Internet of Things", 1789 IMIS, 2012. 1791 [26] Gubbi, J., Buyya, R., and S. Marusic, "Internet of Things 1792 (IoT): A vision, architectural elements, and future 1793 directions", Future Generation Computer Systems, 2013. 1795 [27] Vandikas, K. and V. Tsiatsis, "Performance Evaluation of 1796 an IoT Platform. In Next Generation Mobile Apps, Services 1797 and Technologies(NGMAST)", Next Generation Mobile Apps, 1798 Services and Technologies (NGMAST), 2014. 1800 [28] Zhang, Y., Yu, R., Nekovee, M., Liu, Y., Xie, S., and S. 1801 Gjessing, "Cognitive Machine-to-Machine Communications: 1802 Visions and Potentials for the Smart Grid", IEEE, Network, 1803 2012. 1805 [29] Zhou, H., Liu, B., and D. Wang, "Design and Research of 1806 Urban Intelligent Transportation System Based on the 1807 Internet of Things", Springer Link, 2012. 1809 [30] Alessandrelli, D., Petracca, M., and P. Pagano, "T-Res: 1810 enabling reconfigurable in-network processing in IoT-based 1811 WSNs.", International Conference on Distributed Computing 1812 in Sensor Systems (DCOSS) , 2013. 1814 [31] Kovatsch, M., Mayer, S., and B. Ostermaier, "Moving 1815 application logic from the firmware to the Cloud: towards 1816 the thin server architecture for the internet of things.", 1817 in Proc. 6th Int. Conf. on Innovative Mobile and Internet 1818 Services in Ubiquitous Computing (IMIS) , 2012. 1820 [32] Zhang, M., Yu, T., and G. Zhai, "Smart Transport System 1821 Based on the Internet of Things", Applied Mechanics and 1822 Materials, 2012. 1824 [33] Zhang, A., Yu, R., Nekovee, M., and S. Xie, "The Internet 1825 of Things for Ambient Assisted Living", IEEE, ITNG, 2010. 1827 [34] Savola, R., Abie, H., and M. Sihvonen, "Towards metrics- 1828 driven adaptive security management in E-health IoT 1829 applications.", ACM, BodyNets, 2012. 1831 [35] Jacobson, V., Smetters, D., Plass, M., Stewart, P., 1832 Thornton, J., and R. Braynard, "VoCCN: Voice-over Content- 1833 Centric Networks", ACM, ReArch, 2009. 1835 [36] Piro, G., Cianci, I., Grieco, L., Boggia, G., and P. 1836 Camarda, "Information Centric Services in Smart Cities", 1837 ACM, Journal of Systems and Software, 2014. 1839 [37] Gaur, A., Scotney, B., Parr, G., and S. McClean, "Smart 1840 City Architecture and its Applications Based on IoT - 1841 Smart City Architecture and its Applications Based on 1842 IoT", Procedia Computer Science, Volume 52, 2015, Pages 1843 1089-1094. 1845 [38] Herrera-Quintero, L., Banse, K., Vega-Alfonso, J., and A. 1846 Venegas-Sanchez, "Smart ITS sensor for the transportation 1847 planning using the IoT and Bigdata approaches to produce 1848 ITS cloud services", 8th Euro American Conference on 1849 Telematics and Information Systems (EATIS), Cartagena, 1850 2016, pp. 1-7. 1852 [39] Melis, A., Pardini, M., Sartori, L., and F. Callegati, 1853 "Public Transportation, IoT, Trust and Urban Habits", 1854 Internet Science: Third International Conference, INSCI 1855 2016, Florence, Italy, September 12-14, 2016, Proceedings. 1857 [40] Tonneau, A., Mitton, N., and J. Vandaele, "A Survey on 1858 (mobile) Wireless Sensor Network Experimentation 1859 Testbeds", 2014 IEEE International Conference on 1860 Distributed Computing in Sensor Systems, Marina Del Rey, 1861 CA, 2014, pp. 263-268. 1863 [41] Zhilin, Y., "Mobile phone location determination and its 1864 impact on intelligent transportation systems", IEEE 1865 Transactions on Intelligent Transportation Systems, vol. 1866 1, no. 1, pp. 55-64, Mar 2000. 1868 [42] Papadimitratos, P., La Fortelle, A., Evenssen, K., 1869 Brignolo, R., and S. Cosenza, "Vehicular communication 1870 systems: Enabling technologies, applications, and future 1871 outlook on intelligent transportation", IEEE 1872 Communications Magazine, vol. 47, no. 11, pp. 84-95, 1873 November 2009. 1875 [43] Zhang, Yu., Afanasyev, A., Burke, J., and L. Zhang, "A 1876 survey of mobility support in named data networking", 1877 Computer Communications Workshops (INFOCOM WKSHPS), 2016 1878 IEEE Conference on. IEEE, 2016. 1880 [44] Xylomenos, G., Ververidis, C., Siris, V., and N. Fotiou et 1881 al, "A survey of information-centric networking research", 1882 IEEE Communications Surveys and Tutorials, Volume: 16, 1883 Issue: 2, Second Quarter 2014 . 1885 [45] Mavromoustakis, C., Mastorakis, G., and J. Batalla, 1886 "Internet of Things (IoT) in 5G Mobile Technologies", 1887 ISBN,3319309137,Springer. 1889 [46] Firner, S., Medhekar, S., and Y. Zhang, "PIP Tags: 1890 Hardware Design and Power Optimization", in Proceedings of 1891 HotEmNets, 2008. 1893 [47] Masek, P., Masek, J., Frantik, P., and R. Fujdiak, "A 1894 Harmonized Perspective on Transportation Management in 1895 Smart Cities: The Novel IoT-Driven Environment for Road 1896 Traffic Modeling", Sensors, Volume 16, Issue 11, 2016. 1898 [48] Abreu, D., Velasquez, K., Curado, M., and E. Monteiro, "A 1899 resilient Internet of Things architecture for smart 1900 cities", Annals of Telecommunications, Volume 72, Issue 1, 1901 Pages 19-30, 2017. 1903 [49] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and 1904 G. Wang, "Information-centric Networking based Homenet", 1905 IEEE/IFIP, 2013. 1907 [50] Dannewitz, C., D' Ambrosio, M., and V. Vercellone, 1908 "Hierarchical DHT-based name resolution for information- 1909 centric networks", 2013. 1911 [51] Fasoloy, E., Rossiy, M., and M. Zorziy, "In-network 1912 Aggregation Techniques for Wireless Sensor Networks: A 1913 Survey", IEEE Wireless Communications, 2007. 1915 [52] Chai, W., He, D., and I. Psaras, "Cache "less for more" in 1916 information-centric networks", ACM, IFIP, 2012. 1918 [53] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo., and N. 1919 Nishinaga, "Catt: potential based routing with content 1920 caching for icn", IEEE Communication Magazine, 2012. 1922 [54] Drira, W. and F. Filali, "Catt: An NDN Query Mechanism for 1923 Efficient V2X Data Collection", Eleventh Annual IEEE 1924 International Conference on Sensing, Communication, and 1925 Networking Workshops (SECON Workshops), 2014. 1927 [55] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R., 1928 and D. Raychaudhuri, "Enabling internet-of-things services 1929 in the mobilityfirst future internet architecture", IEEE, 1930 WoWMoM, 2012. 1932 [56] Raychaudhuri, D., Nagaraj, K., and A. Venkatramani, 1933 "Mobilityfirst: a robust and trustworthy mobility-centric 1934 architecture for the future internet.", ACM SIGMOBILE 1935 Mobile Computing and Communications Review 16.3 (2012): 1936 2-13. 1938 [57] Sun, Y., Qiao, X., Cheng, B., and J. Chen, "A low-delay, 1939 lightweight publish/subscribe architecture for delay- 1940 sensitive IOT services", IEEE, ICWS, 2013. 1942 [58] Azgin, A., Ravindran, R., and GQ. Wang, "Mobility study 1943 for Named Data Networking in wireless access networks", 1944 IEEE, ICC, 2014. 1946 [59] Azgin, A., Ravindran, R., Chakraborti, A., and GQ. Wang, 1947 "Seamless Producer Mobility as a Service in Information 1948 Centric Networks", ACM ICN Sigcomm, IC5G Workshop, 2016. 1950 [60] Wang, L., Wakikawa, R., Kuntz, R., and R. Vuyyuru, "Data 1951 Naming in Vehicle-to-Vehicle Communications", IEEE, 1952 Infocm, Nomen Workshop, 2012. 1954 [61] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1955 Wahlisch, "Information Centric Networking in the 1956 IoT:Experiments with NDN in the Wild", ACM, ICN Siggcomm, 1957 2014. 1959 [62] Simona, C. and M. Mongiello, "Pushing the role of 1960 information in ICN", Telecommunications (ICT), 2016 23rd 1961 International Conference on. IEEE, 2016.. 1963 [63] Li, B., Huang, D., Wang, Z., and Y. Zhu, "Attribute-based 1964 Access Control for ICN Naming Scheme", IEEE Transactions 1965 on Dependable and Secure Computing, vol.PP, no.99, 1966 pp.1-1.. 1968 [64] Polyzos, G. and N. Fotiou, "Building a reliable Internet 1969 of Things using Information-Centric Networking", Journal 1970 of Reliable Intelligent Environments, vol.1, no.1, 2015.. 1972 [65] Pandurang, K., Xu, W., Trappe, W., and Y. Zhang, "Temporal 1973 privacy in wireless sensor networks: Theory and practice", 1974 ACM Transactions on Sensor Networks (TOSN) 5, no. 4 1975 (2009): 28.. 1977 [66] Trossen, D., Sarela, M., and K. Sollins, "Arguments for an 1978 information-centric internetworking architecture.", ACM 1979 SIGCOMM Computer Communication Review 40.2 (2010): 26-33. 1981 [67] Zhang, G., Li, Y., and T. Lin, "Caching in information 1982 centric networking: A survey.", Computer Networks 57.16 1983 (2013): 3128-3141. 1985 [68] Gronbaek, I., "Architecture for the Internet of Things 1986 (IoT): API and interconnect", IEEE, SENSORCOMM, 2008. 1988 [69] Tian, Y., Liu, Y., Yan, Z., Wu, S., and H. Li, "RNS-A 1989 Public Resource Name Service Platform for the Internet of 1990 Things", IEEE, GreenCom, 2012. 1992 [70] Roussos, G. and P. Chartier, "Scalable id/locator 1993 resolution for the iot", IEEE, iThings,CPSCom, 2011. 1995 [71] Amadeo, M. and C. Campolo, "Potential of information- 1996 centric wireless sensor and actuator networking", IEEE, 1997 ComManTel, 2013. 1999 [72] Nelson, S., Bhanage, G., and D. Raychaudhuri, "GSTAR: 2000 generalized storage-aware routing for mobilityfirst in the 2001 future mobile internet", ACM, MobiArch, 2011. 2003 [73] Trappe, W., Zhang, Y., and B. Nath, "MIAMI: methods and 2004 infrastructure for the assurance of measurement 2005 information", ACM, DMSN, 2005. 2007 [74] Rouf, I., Mustafa, H., Taylor, T., Oh, S., Xu, W., 2008 Gruteser, M., Trappe, W., and I. Seskar, "Security and 2009 privacy vulnerabilities of in-car wireless networks: A 2010 tire pressure monitoring system case study", USENIX, 2010. 2012 [75] Liu, R. and W. Trappe, "Securing Wireless Communications 2013 at the Physical Layer", Springer, 2010. 2015 [76] Xiao, L., Greenstein, L., Mandayam, N., and W. Trappe, 2016 "Using the physical layer for wireless authentication in 2017 time-variant channels", IEEE Transactions on Wireless 2018 Communications, 2008. 2020 [77] Sun, S., Lannom, L., and B. Boesch, "Handle system 2021 overview", IETF, RFC3650, 2003. 2023 [78] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2024 Application Protocol (CoAP)", RFC 7252, 2025 DOI 10.17487/RFC7252, June 2014, 2026 . 2028 [79] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2029 Protocol (HTTP/1.1): Message Syntax and Routing", 2030 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2031 . 2033 [80] Barnes, R., "Use Cases and Requirements for JSON Object 2034 Signing and Encryption (JOSE)", RFC 7165, 2035 DOI 10.17487/RFC7165, April 2014, 2036 . 2038 [81] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2039 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2040 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2041 Low-Power and Lossy Networks", RFC 6550, 2042 DOI 10.17487/RFC6550, March 2012, 2043 . 2045 [82] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 2046 Demand Distance Vector (AODV) Routing", RFC 3561, 2047 DOI 10.17487/RFC3561, July 2003, 2048 . 2050 [83] marc.mosko@parc.com, m., Uzun, E., and C. Wood, "CCNx Key 2051 Exchange Protocol Version 1.0", draft-wood-icnrg- 2052 ccnxkeyexchange-01 (work in progress), October 2016. 2054 [84] Sun, S., "Hypertext Transfer Protocol (HTTP/1.1): Message 2055 Syntax and Routing", 2014. 2057 [85] Liu, X., Trappe, W., and Y. Zhang, "Secure Name Resolution 2058 for Identifier-to-Locator Mappings in the Global 2059 Internet", IEEE, ICCCN, 2013. 2061 [86] Boguna, M., Fragkiskos, P., and K. Dmitri, "Sustaining the 2062 internet with hyperbolic mapping", Nature Communications, 2063 2010. 2065 [87] Shang, W., "Securing building management systems using 2066 named data networking", IEEE Network 2014. 2068 [88] Fayazbakhsh, S. and et. et al, "Less pain, most of the 2069 gain: Incrementally deployable icn", ACM, Siggcomm, 2013. 2071 [89] Burke, J. and et. et al, "Securing instrumented 2072 environments over Content-Centric Networking: the case of 2073 lighting control", INFOCOM, Computer Communications 2074 Workshop, 2013. 2076 [90] Rao, A., Schelen, O., and A. Lindgren, "Performance 2077 Implications for IoT over Information Centric Networks", 2078 Performance Implications for IoT over Information Centric 2079 Networks, ACM CHANTS 2016. 2081 [91] Li, S., Zhang, Y., Dipankar, R., and R. Ravindran, "A 2082 comparative study of MobilityFirst and NDN based ICN-IoT 2083 architectures", IEEE, QShine, 2014. 2085 [92] Chen, J., Li, S., Yu, H., Zhang, Y., and R. Ravindran, 2086 "Exploiting icn for realizing service-oriented 2087 communication in iot", IEEE, Communication Magazine, 2016. 2089 [93] Quevedo, J., Corujo, D., and R. Aguiar, "A Case for ICN 2090 usage in IoT environments", Global Communications 2091 Conference GLOBECOM, IEEE, Dec 2014, Pages 2770-2775. 2093 [94] Lindgren, A., Ben Abdesslem, F., Ahlgren, B., and O. 2094 Schelen, "Design Choices for the IoT in Information- 2095 Centric Networks", IEEE Annual Consumer Communications and 2096 Networking Conference (CCNC) 2016. 2098 [95] Grieco, L., Alaya, M., and K. Drira, "Architecting 2099 Information Centric ETSI-M2M systems", IEEE, Pervasive and 2100 Computer Communications Workshop (PERCOM), 2014. 2102 [96] Compagno, A., Conti, M., and R. Dorms, "OnboardICNg: a 2103 Secure Protocol for On-boarding IoT Devices in ICN", ICN, 2104 Sigcomm, 2016. 2106 [97] Grieco, L., Rizzo, A., Colucci, R., Sicari, S., Piro, G., 2107 Di Paola, D., and G. Boggia, "IoT-aided robotics 2108 applications: technological implications, target domains 2109 and open issues", Elsevier Computer Communications, Volume 2110 54, 1 December, 2014. 2112 [98] InterDigital, WhitePaper., "Standardized M2M Software 2113 Development Platform", 2011. 2115 [99] Boswarthick, D., "M2M Communications: A Systems Approach", 2116 2012. 2118 [100] Swetina, J., Lu, G., Jacobs, P., Ennesser, F., and J. 2119 Song, "Toward a standardized common M2M service layer 2120 platform: Introduction to oneM2M", IEEE Wireless 2121 Communications, Volume 21, Number 3, June 2014. 2123 [101] Wang, L., Wang, Z., and R. Yang, "Intelligent Multiagent 2124 Control System for Energy and Comfort Management in Smart 2125 and Sustainable Buildings", IEEE Transactions on Smart 2126 Grid, vol. 3, no. 2, pp. 605-617, June 2012.. 2128 [102] Lawrence, T., Boudreau, M., and L. Helsen, "Ten questions 2129 concerning integrating smart buildings into the smart 2130 grid, Building and Environment", Building and Environment, 2131 Volume 108, 1 November 2016, Pages 273-283.. 2133 [103] Hassan, A. and D. Kim, "Named data networking-based smart 2134 home", ICT Express 2.3 (2016): 130-134.. 2136 [104] Burke, J., Horn, A., and A. Marianantoni, "Authenticated 2137 lighting control using named data networking", UCLA, NDN 2138 Technical Report NDN-0011 (2012).. 2140 [105] Afanasyev, A., "Packet fragmentation in ndn: Why ndn uses 2141 hop-by-hop fragmentation.", UCLA, NDN Technical Report 2142 NDN-0032 (2015).. 2144 [106] Quan, Wei., Xu, C., Guan, J., Zhang, H., and L. Grieco, 2145 "Scalable Name Lookup with Adaptive Prefix Bloom Filter 2146 for Named Data Networking", IEEE Communications Letters, 2147 2014. 2149 [107] Wang, Yi., Pan, T., Mi, Z., Dai, H., Guo, X., Zhang, T., 2150 Liu, B., and Q. Dong, "NameFilter: Achieving fast name 2151 lookup with low memory cost via applying two-stage Bloom 2152 filters", INFOCOM, 2013. 2154 [108] So, W., Narayanan, A., Oran, D., and Y. Wang, "Toward fast 2155 NDN software forwarding lookup engine based on Hash 2156 tables", ACM, ANCS, 2012. 2158 [109] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 2159 data networking for IoT: An architectural perspective", 2160 IEEE, EuCNC, 2014. 2162 [110] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, 2163 "Information centric networking in iot scenarios: The case 2164 of a smart home", IEEE ICC, June 2015. 2166 [111] Somani, N., Chanda, A., Nelson, S., and D. Raychaudhuri, 2167 "Storage- Aware Routing for Robust and Efficient Services 2168 in the Future Mobile Internet", Proceedings of ICC 2169 FutureNet V, 2012. 2171 [112] Blefari Melazzi, N., Detti, A., Arumaithurai, M., and K. 2172 Ramakrishnan, "Internames: A name-to-name principle for 2173 the future internet", QShine, August 2014. 2175 [113] Sifalakis, M., Kohler, B., Christopher, C., and C. 2176 Tschudin, "An information centric network for computing 2177 the distribution of computations", ACM, ICN Sigcomm, 2014. 2179 [114] Lu, R., Lin, X., Zhu, H., and X. Shen, "SPARK: a new 2180 VANET-based smart parking scheme for large parking lots", 2181 INFOCOM, 2009. 2183 [115] Wang, H. and W. He, "A reservation-based smart parking 2184 system", The First International Workshop on Cyber- 2185 Physical Networking Systems, 2011. 2187 [116] Qian, L., "Constructing Smart Campus Based on the Cloud 2188 Computing and the Internet of Things", Computer Science 2189 2011. 2191 [117] Project, BonVoyage., "European Unions - Horizon 2020, 2192 http://bonvoyage2020.eu/", 2016. 2194 [118] Li, S., Zhang, Y., Raychaudhuri, D., Ravindran, R., Zheng, 2195 Q., Wang, GQ., and L. Dong, "IoT Middleware over 2196 Information-Centric Network", Global Communications 2197 Conference (GLOBECOM) ICN Workshop, 2015. 2199 [119] Li, S., Chen, J., Yu, H., Zhang, Y., Raychaudhuri, D., 2200 Ravindran, R., Gao, H., Dong, L., Wang, GQ., and H. Liu, 2201 "MF-IoT: A MobilityFirst-Based Internet of Things 2202 Architecture with Global Reachability and Communication 2203 Diversity", IEEE International Conference on Internet-of- 2204 Things Design and Implementation (IoTDI), 2016. 2206 [120] Adhatarao, S., Chen, J., Arumaithurai, M., and X. Fu, 2207 "Comparison of naming schema in ICN", IEEE LANMAN, June , 2208 2016. 2210 [121] Campolo, C., Corujo, D., Iera, A., and R. Aguiar, 2211 "Information-centric Networking for Internet-of-things: 2212 Challenges and Opportunities", IEEE Networks, Jan , 2015. 2214 Authors' Addresses 2216 Prof.Yanyong Zhang 2217 WINLAB, Rutgers University 2218 671, U.S 1 2219 North Brunswick, NJ 08902 2220 USA 2222 Email: yyzhang@winlab.rutgers.edu 2224 Prof. Dipankar Raychadhuri 2225 WINLAB, Rutgers University 2226 671, U.S 1 2227 North Brunswick, NJ 08902 2228 USA 2230 Email: ray@winlab.rutgers.edu 2232 Prof. Luigi Alfredo Grieco 2233 Politecnico di Bari (DEI) 2234 Via Orabona 4 2235 Bari 70125 2236 Italy 2238 Email: alfredo.grieco@poliba.it 2240 Prof. Emmanuel Baccelli 2241 INRIA 2242 Room 148, Takustrasse 9 2243 Berlin 14195 2244 France 2246 Email: Emmanuel.Baccelli@inria.fr 2247 Jeff Burke 2248 UCLA REMAP 2249 102 East Melnitz Hall 2250 Los Angeles, CA 90095 2251 USA 2253 Email: jburke@ucla.edu 2255 Ravishankar Ravindran 2256 Huawei Technologies 2257 2330 Central Expressway 2258 Santa Clara, CA 95050 2259 USA 2261 Email: ravi.ravindran@huawei.com 2263 Guoqiang Wang 2264 Huawei Technologies 2265 2330 Central Expressway 2266 Santa Clara, CA 95050 2267 USA 2269 Email: gq.wang@huawei.com 2271 Anders Lindgren 2272 RISE SICS 2273 Box 1263 2274 Kista SE-164 29 2275 SE 2277 Email: anders.lindgren@ri.se 2279 Bengt Ahlgren 2280 RISE SICS 2281 Box 1263 2282 Kista, CA SE-164 29 2283 SE 2285 Email: bengt.ahlgren@ri.se 2286 Olov Schelen 2287 Lulea University of Technology 2288 Lulea SE-971 87 2289 SE 2291 Email: lov.schelen@ltu.se