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