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