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