ICN Research Group Y. Zhang
Internet-Draft D. Raychadhuri
Intended status: Informational WINLAB, Rutgers University
Expires: December 28, 2017 L. Grieco
Politecnico di Bari (DEI)
E. Baccelli
INRIA
J. Burke
UCLA REMAP
R. Ravindran
G. Wang
Huawei Technologies
A. Lindgren
B. Ahlgren
RISE SICS
O. Schelen
Lulea University of Technology
June 26, 2017

Design Considerations for Applying ICN to IoT
draft-zhang-icnrg-icniot-01

Abstract

The Internet of Things (IoT) promises to connect billions of objects to the Internet. After deploying many stand-alone IoT systems in different domains, the current trend is to develop a common, "thin waist" of protocols over a horizontal unified, defragmented IoT architecture. Such an architecture will make objects accessible to applications across organizations and domains. Towards this goal, quite a few proposals have been made to build an application-layer based unified IoT platform on top of today's host-centric Internet. However, there is a fundamental mismatch between the host-centric nature of todays Internet and mostly information-centric nature of the IoT system. To address this mismatch, an information-centric network (ICN) architecture can provide a common set of protocols and services, called 'ICN-IoT', which can be used to build IoT platforms. ICN-IoT leverages the salient features of ICN, and thus provides naming, security, mobility support,scalability, and efficient content and service delivery.

This draft summarizes general IoT demands, and covers the challenges and design considerations ICN faces to realize a ICN-IoT framework based on ICN architecture.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 28, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. IoT Motivation

During the past decade, many Internet of Things (IoT) systems have been developed and deployed in different domains. The recent trend, however, is to evolve towards a more unified IoT architecture, in which a large number of objects connect to the Internet, available for interactions among themselves, as well as interactions with many different applications across boundaries of administration and domains. General IoT applications involve sensing, processing, and secure content distribution occurring at various timescales and at multiple levels of hierarchy depending on the application requirements. This requires the system to adopt a unified architecture providing pull, push and publish/subscribe mechanisms using application abstractions, common naming, payload, encryption and signature schemes. This requires open APIs to be generic enough to support commonly used interactions between consumers, content producer, and IoT services, as opposed to proprietary APIs that are common in today's systems. Building a unified IoT architecture, however, poses great challenges on the underlying network and systems. To name a few, it needs to support 50-100 Billion networked objects [1], many of which are mobile. The objects will have extremely heterogeneous means of connecting to the Internet, often with severe resource constraints. Interactions between the applications and objects are often real-time and dynamic, requiring strong security and privacy protections. In addition, many IoT applications are inherently information centric (e.g., data consumers usually need data sensed from the environment without any reference to the sub-set of sensors that will provide the asked information).

Taking a general IoT perspective, we first motivate the discussion of ICN for IoT using well known scenarios. Then we discuss the IoT requirements generally applicable to many well known IoT scenarios. We then discuss how the current application-layer unified IoT architectures fail to meet these requirements. We follow this by key ICN features that makes it a better candidate to realize an unified IoT framework. We then discuss IoT design challenges from an ICN perspective and requirements posed towards its design.

2. Motivating ICN for IoT

ICN offers many features including name-based networking, content object security, caching, computing and storage, mobility, context-aware networking (see Section 3.6) and support for ad hoc networking features, all of which have to be realized in an application-specific means in the context of IP-IoT. These compelling features enable a distributed and intelligent data distribution platform to support heterogeneous IoT services with features like device bootstrapping with minimal configuration, simpler protocols to aid self-organizing among the IoT elements, natural support for compute and caching logic at strategic points in the network. We discuss these features through the following scenarios that are difficult to realize over IP today, and whose characteristics we argue match the features offered by ICN.

3. IoT Architectural Requirements

A unified IoT platform has to support interactions among a large number of mobile devices across the boundaries of organizations and domains. As a result, it naturally poses stringent requirements in every aspect of the system design. Below, we outline a few important requirements that a unified IoT platform has to address.

3.1. Naming

An important step towards realizing a unified IoT architecture is the ability to assign names that are unique to each device, data items generated by these devices, or a group of devices towards a common objective. Naming has the following requirements. Firstly, names need to be persistent against dynamic features that are common in IoT systems, such as lifetime, mobility or migration. Secondly, names that are derived from the keys need to be self-certifying, for both device-centric communication and content-centric communication. For device-centric communication, the binding between device names and the device must be secure. For content-centric communication, the binding between the names and the content has to be secure. Thirdly, names usually serve multiple purposes: routing, security (self-certifying) or human-readability. For IoT applications, the choice of flat versus human readable names needs to be made considering application and network requirements such as privacy and network level scalability, and the name space explosion that may occur because of complex relationship between name hierarchies [120] which might confound application logic. In order to ensure the trustworthiness of the names, a name certificate service (NCS) needs to be considered. Such a service acts as a certificate authority in assigning names, which are themselves public keys or appropriately bound to the name for verification at the consumer's end. In short, the NCS must provide services analogous to those provided by a Public Key Infrastructure (PKI). In ICN, users may either generate their own public keys and submit them to the NCS for registration, or may contact the NCS to acquire public keys. Consequently, the NCS publishes approved cryptographic suites, object categories and object description formats, as well as allows users to self-certify themselves.

3.2. Security and Privacy

A variety of security and privacy concerns exist in IoT. For example the unified IoT architecture makes physical objects accessible to applications across organizations and domains. Further, it often integrates with critical infrastructure and industrial systems with life safety implications, bringing with it significant security challenges and regulatory requirements [13], as will be discussed in Section 6.3. Security and privacy thus become a serious concern, as does the flexibility and usability of the design approaches. Beyond the overarching trust management challenge, security includes data integrity, authentication, and access control at different layers of the IoT architecture. Privacy includes several aspects: (1) privacy of data producer/consumer that is directly related to each individual vertical domain such as heath, electricity, etc., (2) privacy of data content, and (3) privacy of contextual information such as time and location of data transmission [65].

3.3. Scalability

Cisco predicts there will be around 50 Billion IoT devices such as sensors, RFID tags, and actuators, on the Internet by 2020 [1]. As mentioned above, a unified IoT platform needs to name every entity such as data, device, service etc. Scalability has to be addressed at multiple levels of the IoT architecture including naming, security, name resolution, routing and forwarding level. Mobility adds further challenge in terms of scalability. Particularly with respect to name resolution the system should be able to register/update/resolve a name within a short latency. In addition scalability is also affected because of IoT system specific features such as IoT resource object count, state and rate of information updates generated by the sensing devices.

3.4. Resource Constraints

IoT devices can be broadly classified as type 1, type 2, and type 3 devices, with type 1 the most resource-constrained and type 3 the most resource-rich [45]. In general, there are the following types of resources: power, computing, storage, bandwidth, and user interface.

Power constraints of IoT devices limit how much data these devices can communicate, as it has been shown that communications consume more power than other activities for embedded devices [46]. Flexible techniques to collect the relevant information are required, and uploading every single produced data to a central server is undesirable. Computing constraints limit the type and amount of processing these devices can perform. As a result, more complex processing needs to be conducted in cloud servers or at opportunistic points, example at the network edge, hence it is important to balance local computation versus communication cost.

Storage constraints of the IoT devices limit the amount of data that can be stored on the devices. This constraint means that unused sensor data may need to be discarded or stored in aggregated compact form time to time. Bandwidth constraints of the IoT devices limit the amount of communication. Such devices will have the same implication on the system architecture as with the power constraints; namely, we cannot afford to collect single sensor data generated by the device and/or use complex signaling protocols. It is also worth mentioning that idle chatter in the background is strongly discouraged to maintain connectivity or other volatile state.

User interface constraints refer to whether the device is itself capable of directly interacting with a user should the need arise (e.g., via a display and keypad or LED indicators) or requires the network connectivity, either global or local, to interact with humans.

The above discussed device constraints also affect application performance with respect to latency.

3.5. Traffic Characteristics

IoT traffic can be broadly classified into local area traffic and wide area traffic. Local area traffic is among nearby devices. For example, neighboring cars may work together to detect potential hazards on the highway, sensors deployed in the same room may collaborate to determine how to adjust the heating level in the room. These local area communications often involve data aggregation and filtering, have real time constraints, and require fast device/data/ service discovery and association. At the same time, the IoT platform has to also support wide area communications. For example, in Intelligent Transportation Systems, re-routing operations may require a broad knowledge of the status of the system, traffic load, availability of freights, whether forecasts and so on. Wide area communications require efficient data/service discovery and resolution services.

While traffic characteristics for different IoT systems are expected to be different, certain IoT systems have been analyzed and shown to have comparable uplink and downlink traffic volume in some applications such as [2], which means that we have to optimize the bandwidth/energy consumption in both directions. Further, IoT traffic demonstrates certain periodicity and burstiness [2]. As a result, when provisioning the system, the shape of the traffic volume has to be properly accounted for.

3.6. Contextual Communication

Many IoT applications rely on dynamic contexts in the IoT system to initiate, maintain and terminate communication among IoT devices. Here, we refer to a context as attributes applicable to a group of devices that share some common features, such as their owners may have a certain social relationship or belong to the same administrative group, or the devices may be present in the same location. There are two types of contexts: long-term quasi static contexts and short-term dynamic contexts. In this draft, we focus on the latter, which are more challenging to support, requiring fast formation, update, lookup and association For example, cars traveling on the highway may form a "cluster" based upon their temporal physical proximity as well as the detection of the same event. These temporary groups are referred to as contexts. IoT applications need to support interactions among the members of a context, as well as interactions across contexts.

Temporal context can be broadly categorized into two classes, long- term contexts such as those that are based upon social contacts as well as stationary physical locations (e.g., sensors in a car/ building), and short-term contexts such as those that are based upon temporary proximity (e.g., all taxicabs within half a mile of the Time Square at noon on Oct 1, 2013). Between these two classes, short-term contexts are more challenging to support, requiring fast formation, update, lookup and association.

3.7. Handling Mobility

There are several degrees of mobility in a unified IoT architecture, ranging from static as in fixed assets to highly dynamic in vehicle- to-vehicle environments.

Mobility in the IoT architecture can mean 1) the data producer mobility (i.e., location change), 2) the data consumer mobility, 3) IoT Network mobility (e.g., a body-area network in motion as a person is walking); and 4) disconnection between the data source and destination pair (e.g., due to unreliable wireless links). The requirement on mobility support is to be able to deliver IoT data below an application's acceptable delay constraint in all of the above cases, and if necessary to negotiate different connectivity or security constraints specific to each mobile context. More detailed discussions are presented in Section 6.7.

3.8. Storage and Caching

Storage and caching plays a very significant role depending on the type of IoT ecosystem, also a function subjected to privacy and security guidelines. Caching is usually done for increasing data availability in the network and reliability purposes, especially in wireless scenarios in the network access. Storage is more important for IoT, storing data for long term analysis. Data is stored in strategic locations in the network to reduce control and computation overhead. In a unified IoT architecture, depending on application requirements, content caching will be strictly driven by application level policies considering privacy requirements. If for certain kind of IoT data pervasive caching is allowed, intermediate nodes don't need to always forward a content request to its original creator; rather, receiving a cached copy is sufficient for IoT applications. This optimization may greatly reduce the content access latencies.

Furthermore considering hierarchical nature of IoT systems, ICN architectures enable flexible heterogeneous and potentially fault-tolerant approach to storage providing persistence at multiple levels.

Hence in the context of IoT while ICN allows resolution to replicated stored copies, it should also strive for the balance between content security/privacy and regulations considering application requirements.

3.9. Communication Reliability

IoT applications can be broadly categorized into mission critical and non-mission critical. For mission critical applications, reliable communication is one of the most important features as these applications have strong QoS requirements such as low latency and probability of error during information transfer. To summarize, reliable communication desires the following capabilities for the underlying system: (1) seamless mobility support under normal operating conditions, (2) efficient routing in the presence of intermittent disconnection, (3) QoS aware routing, (4) support for redundancy at all levels of a system (device, service, network, storage etc.), and (5) support for rich and diverse communication patterns, both within an IoT domain consisting of multiple IoT nodes and one or more gateway nodes to the Internet and across multiple such domains.

3.10. Self-Organization

The unified IoT architecture should be able to self-organize to meet various application requirements, especially the capability to quickly discover heterogeneous and relevant (local or global) devices/data/services based on the context. This discovery can be achieved through an efficient publish-subscribe service, or through private community grouping/clustering based upon trust and other security requirements. In the former case, the publish-subscribe service must be efficiently implemented, able to support seamless mobility, in- network caching, name-based routing, etc. In the latter case, the IoT architecture needs to discover the private community groups/clusters efficiently.

Another aspect of self-organization is decoupling the sensing Infrastructure from applications. In a unified IoT architecture, various applications run on top of a vast number of IoT devices. Upgrading the firmware of the IoT devices is a difficult work. It is also not practical to reprogram the IoT devices to accommodate every change of the applications. The infrastructure and the application specific logics need to be decoupled. A common interface is required to dynamically configure the interactions between the IoT devices and easily modify the application logics on top of the sensing/actuating infrastructure [30] [31].

3.11. Ad hoc and Infrastructure Mode

Depending upon whether there is communication infrastructure, an IoT system can operate either in ad-hoc or infrastructure mode.

For example, a vehicle may determine to report its location and status information to a server periodically through cellular connection, or, a group of vehicles may form an ad-hoc network that collectively detect road conditions around them. In the cases where infrastructure is unavailable, one of the participating nodes may choose to become the temporary gateway.

The unified IoT architecture needs to design a common protocol that serves both modes. Such a protocol should address the challenges that arise in these two modes: (1) scalability and low latency for the infrastructure mode and (2) efficient neighbor discovery and ad-hoc communication for the ad-hoc mode. Finally we note that hybrid modes are very common in realistic IoT systems.

3.12. IoT Platform Management

An IoT platforms' service, control and data plane will be governed by its own management infrastructure which includes distributed and centralized middleware, discovery, naming, self-configuring, analytic functions, and information dissemination to achieve specific IoT system objectives [25][26][27]. Towards this, new IoT management mechanisms and service metrics need to be developed to measure the success of an IoTdeployment. Considering an IoT systems' defining characteristics such as, its potential large number of IoT devices, objective to save power, mobility, and ad hoc communication, autonomic self-management mechanisms become very critical. Further considering its hierarchical information processing deployment model, the platform needs to orchestrate computational tasks according to the involved sensors and the available computation resources which may change over time. An efficient computation resource discovery and management protocol is required to facilitate this process. The trade-off between information transmission and processing is another challenge.

4. State of the Art

Over the years, many stand-alone IoT systems have been deployed in various domains. These systems usually adopt a vertical silo architecture and support a small set of pre-designated applications. A recent trend, however, is to move away from this approach, towards a unified IoT architecture in which the existing silo IoT systems, as well as new systems that are rapidly deployed. By unified, we mean all the application and network components that use common APIs to interact with each other. This will make their data and services accessible to general Internet applications (as in ETSI- M2M and oneM2M standards). In such a unified architecture, resources can be accessed over Internet and shared across the physical boundaries of the enterprise. However, current approaches to achieve this objective are mostly based upon service overlays over the Internet, whose inherent inefficiencies due to IP protocol [56] hinders the architecture from satisfying the IoT requirements outlined earlier, particularly in terms of scalability, security, mobility, and self-organization, discussed more in Section 4.2.

4.1. Silo IoT Architecture 

  
                       [IoT Server]
                            |
                            |
                      ______|_______
 _______             {              }
{       }            {              }    
{IoT Dev}\           {   Internet   }---[IoT Application]
{_______}  [IoTGW]---{              }
                     {              }
                     {______________}
              
              
   Figure 1:Silo architecture of standalone IoT systems

A typical standalone IoT system is illustrated in Figure 1, which includes devices, a gateway, a server and applications. Many IoT devices have limited power and computing resources, unable to directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.) protocols. Therefore they use the IoT gateway to the server. Through the IoT server, applications can subscribe to data collected by devices, or interact with devices.

There have been quite a few popular protocols for standalone IoT systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc. However, these protocols are operating at the device-level abstraction, instead of information driven, which may sometimes lead to a fragmented protocol space that requires a higher-level solution for better interoperability.

4.2. Application-Layer Unified IoT Solutions

The current approach to a unified IoT architecture is to make IoT gateways and servers adopt standard APIs. IoT devices connect to the Internet through the standard APIs and IoT applications subscribe and receive data through standard control and data APIs. Building on top of today's Internet this application-layer unified IoT architecture is the most practical approach towards a unified IoT platform. Towards this, there are ongoing standardization efforts including ETSI[3], oneM2M[4]. Network operators can use frameworks to build common IOT gateways and servers for their customers. In addition, IETF's CORE working group [5] is developing a set of protocols like CoAP (Constrained Application Protocol) [78], that is a lightweight protocol modeled after HTTP [79] and adapted specifically for the Internet of Things (IoT). CoAP adopts the Representational State Transfer (REST) architecture with Client-Server interactions. It uses UDP as the underlying transport protocol with reliability and multicast support. Both CoAP and HTTP are considered as the suitable application level protocols for Machine-to-Machine communications, as well as IoT. For example, oneM2M (which is one of leading standards for unified M2M architecture) has both the protocol bindings to HTTP and CoAP for its primitives. Figure 2 shows the architecture adopted in this approach. 

  
              Publishing----[IoT Server]----Subscribing--
                  |        /    |       \                |
                  |       /     |        \               |
                  |      /______|_______  \              |
 ___________      |     /{              }  publishing    |
{           }     |    | {              }     |          |
{Smart Homes}\    |    | {   Internet   }---------[IoT Application]
{___________}  [IoTGW]---{              }\    |     ________________
                       | {              } \   |    {                }
                       | {______________}  [IoTGW]-{Smart Healthcare}
                       |        |                  {________________}  
              Publishing [IoTGW]
                       |    ____|_____         
                       |   {          }
                        ---{Smart Grid}
                           {__________}
                
              
Figure 2: Implementing an open IoT architecture through standardized APIs 
             on the IoT gateways and the server

4.2.1. Weaknesses of the Application-Layer Approach

The above application-layer approach can work with many different protocols, but the system is built upon today's IP network, which has inherent weaknesses towards supporting a unified IoT system. As a result, it cannot satisfy some of the requirements we outlined in Section 3:

4.2.2. Suitability of Delay Tolerant Networking(DTN)

In [21][22], delay-tolerant networking (DTN) has been considered to support future IoT architecture. DTN was created to support information delivery in the presence of network disruptions and disconnections, which has been extended to support heterogeneous networks and name-based routing. The DTN Bundle Protocol is able to achieve some of these same advantages and could be beneficially used in an IoT network to, for example, decouple sender and receiver. The DTN architecture is however centered around named endpoints (endpoint IDs), which usually correspond to a host or a service, and is mainly a way to transport data, while ICN provides a different paradigm centered around named data that addresses additional issues for IoT applications [23] through features such as information naming, information discovery, information request and dissemination. Also, the endpoint IDs could be used to also identify named content, enabling the use of the bundle protocol as a transport mechanism for an information-centric system. Such a use of the bundle protocol as transport would however still require other components from an ICN architecture such as naming conventions, so since the exact transport is not a major focus of the issues in this draft, most of of the discussions are applicable to a generic ICN architecture in general.

5. Advantages of using ICN for IoT

A key concept of ICN is the ability to name data independently from the current location at which it is stored, which simplifies caching and enables decoupling of sender and receiver. Using ICN to design an architecture for IoT data potentially provides many such advantages compared to using traditional host-centric networks and other new architectures. This section highlights general benefits that ICN could provide to IoT networks.

6. ICN Design Considerations for IoT

This section outlines some of the ICN specific design considerations and challenges that must be considered when adopting an ICN design for IoT applications and systems, and describes some of the trade offs that will be involved in order to support large scale IoT deployment with diverse application requirements.

Though ICN integrates content/service/host abstraction, name-based routing, compute, caching/storage as part of the network infrastructure, IoT requires special considerations given heterogeneity of devices and interfaces such as for constrained networking [61][119][121], data processing, and content distribution models to meet specific application requirements which we identify as challenges in this section.

6.1. Naming Devices, Data, and Services

The ICN approach of named data and services (i.e., device independent naming) is typically desirable when retrieving IoT data. However, data centric naming may also pose challenges.

6.2. Name Resolution

Inter-connecting numerous IoT entities, as well as establishing reachability to them, requires a scalable name resolution system considering several dynamic factors like mobility of end points, service replication, in-network caching, failure or migration [57] [69] [70] [91]. The objective is to achieve scalable name resolution handling static and dynamic ICN entities with low complexity and control overhead. In particular, the main requirements/challenges of a name space (and the corresponding Name Resolution System where necessary) are [50] [52]:

6.3. Security and Privacy

Security and privacy is crucial to all the IoT applications applications including the use cases discussed in Section 2 and subjected to the information context. To exemplify this, in one recent demonstration,it was shown that passive tire pressure sensors in cars could be hacked adversely affecting the automotive system [74], while at the same time the information can be used by a public traffic management system to improve road safety. The ICN paradigm is information-centric as opposed to state-of-the-art host-centric Internet. Besides aspects like naming, content retrieval and caching this also has security implications. ICN advocates the model of trust in content rather than a direct trust in network host mode. This brings in the concept of Object Security which is contrary to session-based security mechanisms such as TLS/DTLS prevalent in the current host-centric Internet. Object Security is based on the idea of securing information objects unlike session-based security mechanisms which secure the communication channel between a pair of nodes for unicast, (or among a set of nodes for multicast/broadcast). This reinforces an inherent characteristic of ICN networks i.e. to decouple senders and receivers. Even session based trust association can be realized in ICN [83], that offers host-independence allowing authentication and authorization to be separated from session encryption, allowing multiple end points to meet specific service objectives. In the context of IoT, the Object Security model has several concrete advantages. Many IoT applications have data and services are the main goal and specific communication between two devices is secondary. Therefore, it makes more sense to secure IoT objects instead of securing the session between communicating endpoints. Though ICN includes data-centric security features the mechanisms have to be generic enough to satisfy multiplicity of policy requirements for different applications. Furthermore security and privacy concerns have to be dealt in a scenario-specific manner with respect to network function perspective spanning naming, name-resolution, routing, caching, and ICN-APIs. The work by the JOSE WG [80] provides solution approaches to address some of these concerns for object security for constrained devices and should be considered to see what can be applied to an ICN architecture. In general, we feel that security and privacy protection in IoT systems should mainly focus on the following aspects: confidentiality, integrity, authentication and non-repudiation, and availability. Even though, implementing security and privacy methods in IOT systems faces different challenges than in other systems, like IP. Specifically, below we discuss the challenges in the constrained and infrastructure part of the network.

6.4. Caching

In-network caching helps bring data closer to consumers, but its usage differs in constrained and infrastructure part of the IoT network.

Caching in ICN-IoT faces several challenges:

6.5. Storage

Storage is useful for IoT systems both at longer and small time scales.

Long terms storage can be distributed at vantage points including both the edge and the main IoT service aggregation points such as in the data centers, the difference being in the size of data, processing intelligence and heterogeneity of information that has to be dealt at the two points. The purpose of long terms storage at the edge is to analyze, filter, aggregate and re-publish data for consumption by either by the parent service components or directly by the consumers. The aggregation service points, republish data to be presented as part of the global pub/sub service to interested consuming parties. Long term storage for IoT data also serves the purpose of data backup and replication. Specifically, we face several issues here. Firstly, we need to decide how many replicas we should have for each stream of IoT data, and where we should store these replicas. Given that many IoT applications consume data locally, storage locations should be kept near to data sources as well. Since IoT data are mostly appended to the end of a stream, instead of being updated, managing multiple replicas becomes easier. Secondly, we need to adopt a mechanism that can efficiently route traffic to the nearest data replica. ICN provides several solutions to this problem. For example, global name resolution service (GNRS) can keep track of each replica's location [56].

Short-term in-network storage (here storage refers to temporary buffer when an outgoing link is not available) helps improve communication reliability, especially when network links are unreliable, such as wireless links. ICN-IoT could adopt a generalized storage-aware routing algorithm to support delay and disruption tolerance in the routing layer. Each router employs in-network storage that facilitates store vs. forward decisions in response to varying link quality and disconnections [111]. These decisions are based on both short-term and long-term path quality metrics. In addition, packets along paths that become disconnected are handled by a disruption tolerant networking (DTN) mode of the protocol with delayed delivery and replication features. In particular, each router maintains two types of topology information: (i) An intra-partition graph is formed by collecting flooded link state advertisements which carry fine-grained, time-sensitive information about the intra-network links; (ii) A DTN graph is maintained via epidemically disseminated link-state advertisements which carry connection probabilities between all nodes in the network. In-network storage faces the following challenges: (1) when to store and how long to store the data, and (2) the next step after the short-term storage. In [90] the authors also shows that it is beneficial to store data even for shorter periods of time (and even if only a single requester exist) if the network is lossy such that retransmissions and error recovery can be done locally instead of end-to-end.

6.6. Routing and Forwarding

ICN-IoT supports both device-to-device (D2D) communication and device-to-infrastructure (D2I) communication. Some D2D communications are within a single IoT domain, while others might cross IoT domains involving data forwarding within the source IoT domain, in the infrastructure network, and within the destination IoT domain. D2I communications involve data forwarding within the source IoT domain and in the infrastructure network. Data forwarding within an IoT domain can adopt sensor network popular routing protocols such as RPL [81], AODV[82], etc. The main challenge it faces is the resource constraint of the IoT nodes. In order to address this challenge, we could adopt a light-weight, much shorter ICN name for each communicating party within an IoT domain (see Section 6.12 for details). Before we leave the IoT domain, the gateway node will translate the party's short ICN name to its original ICN name. Data forwarding in the ICN infrastructure part can adopt either direct name-based routing or indirect routing using a name resolution service (NRS).

6.7. Mobility Management

Considering the diversity of IoT applications mobility ranges from tracking sensor data from mobile human beings to large fleets of diverse mobile elements such as drones, vehicles, trucks, trains associated with a transport infrastructure. These mobility could be over heterogeneous access infrastructure ranging from short range 802.15.4 to cellular radios. Further, handling information delivery in ad hoc setting involving vehicles, road side units (RSU) and the corresponding infrastructure based services offers more challenges. ICN architectures has generally been shown to handle consumer and producer mobility [59], and even suitability to V2V scenarios [60]. Networking tools to handle mobility varies with application requirements, which varies from being tolerant to packet losses and latency to those that are mission critical with stringent requirement on both these QoS metrics.

Related to this, the challenge is to quantify the cost associated with mobility management both in the control and forwarding plane, to handle both static binding versus dynamic binding (dynamic binding here refers to enabling seamless mobility) of named resources to its location when either or both consumer and producer is mobile.

During a network transaction, either the data producer or the consumer may move away and thus we need to handle the mobility to avoid information loss. ICN may differentiate mobility of a data consumer from that of a producer:

6.8. Contextual Communication

Contextualization through metadata in ICN control or application payload allows IoT applications to adapt to different environments. This enables intelligent networks which are self-configurable and enable intelligent networking among consumers and producers [55]. For example, let us look at the following smart transportation scenario: "James walks on NYC streets and wants to find an empty cab closest to his location." In this example, the context is the relative locations of James and taxi drivers. A context service, as an IoT middleware, processes the contextual information and bridges the gap between raw sensor information and application requirements. Alternatively, naming conventions could be used to allow applications to request content in namespaces related to their local context without requiring a specific service, such as /local/geo/mgrs/4QFJ/123/678 to retrieve objects published in the 100m grid area 4QFJ 123 678 of the military grid reference system (MGRS). In both cases, trust providers may emerge that can vouch for an application's local knowledge.

However, extracting contextual information on a real-time basis is very challenging:

6.9. In-network Computing

In-network computing enables ICN routers to host heterogeneous services catering to various network functions and applications needs. Contextual services for IoT networks require in-network computing, in which each sensor node or ICN router implements context reasoning [55]. Another major purpose of in-network computing is to filter and cleanse sensed data in IoT applications, that is critical as the data is noisy as is [73].

Named Function Networking [113] describes an extension of the ICN concept to named functions processed in the network, which could be used to generate data flow processing applications well-suited to, for example, time series data processing in IoT sensing applications. Related to this, is the need to support efficient function naming. Functions, input parameters, and the output result could be encapsulated in the packet header, the packet body, or mixture of the two (e.g. [31]). If functions are encapsulated in packet headers, the naming scheme affects how a computation task is routed in the network, which IoT devices are involved in the computation task (e.g. [54]), and how a name is decomposed into smaller computation tasks and deployed in the network for a better performance.

Another is challenge is related to support computing-aware routing. Normal routing is for forwarding requests to the nearest source or cache and return the data to the requester, whereas the routing for in-network computation has a different purpose. If the computation task is for aggregating sensed data, the routing strategy is to route the data to achieve a better aggregation performance [51].

In-network computing also includes synchronization challenges. Some computation tasks may need synchronizations between sub-tasks or IoT devices, e.g. a device may not send data as soon as it is available because waiting for data from the neighbours may lead to a better aggregation result; some devices may choose to sleep to save energy while waiting for the results from the neighbours; while aggregating the computation results along the path, the intermediate IoT devices may need to choose the results generated within a certain time window.

6.10. Self-Orgnization

General IoT deployments involves heterogeneous IoT systems consisting of embedded systems, aggregators and service gateways in a IoT domain. To scale IoT deployments to large scale, scope-based self-organization is required. This relates to IoT system middleware functions [118] which include device bootstrapping and discovery, assigning local/global names to device and/or content, security and trust management functions towards device authentication and data privacy. ICN based on-boarding protocols have been studied [96] and has shown to offer significant savings compared to existing approaches. These challenges span both the constrained devices as well as interaction with the aggregators and the service gateways which may have to contact external services like authentication servers to on-board devices. A critical performance optimization metric of these functions while operating at scale is to have low control and data overhead in order to maximize energy efficiency. Further, in the infrastructure part scalable name-based resolution mechanisms, pub/sub services, storage and caching, and in-network computing techniques should be studied to meet the scope-based content dissemination needs of an ICN-IoT system.

6.11. Communications Reliability

ICN offers many ingredients for reliable communication such as multi-home interest anycast over heterogeneous interfaces, caching, and forwarding intelligence for multi-path routing leveraging state- based forwarding in protocols like CCN/NDN. However these features have not been analyzed from the QoS perspective when heterogeneous traffic patterns are mixed in a router, in general QoS for ICN is an open area of research [121]. In-network reliability comes at the cost of a complex network layer; hence the research challenges here is to build redundancy and reliability in the network layer to handle a wide range of disruption scenarios such as congestion, short or long term disconnection, or last mile wireless impairments. Also an ICN network should allow features such as opportunistic store and forward mechanism to be enabled only at certain points in the network, as these mechanisms also entail overheads in the control and forwarding plane overhead which will adversely affect application throughput, Please see the discussion on in-network storage (Section 6.5) for more details .

6.12. Resource Constraints and Heterogeneity

An IoT architecture should take into consideration resource constraints of (often) embedded IoT nodes. Having globally unique IDs is a key feature in ICN, which may consist of tens of bytes. Each device would have a persistent and unique ID no matter when and where it moves. It is also important for ICN-IoT to keep this feature. However, always carrying the long ID in the packet header may not be always feasible over a low-rate layer-2 protocol such as 802.15.4. To solve this issue, ICN can operate using lighter-weight packet header and a much shorter locally unique ID (LUID in short). In this way, we map a device's long global ID to its short LUID when we reach the local area IoT domain. To cope with collisions that may occur in this mapping process, we let each domain have its own global ID to LUID mapping which is managed by a gateway deployed at the edge of the domain. Different from NAT and other existing domain-based or gateway-based solutions, ICN-IoT does not change the identity the application uses. The applications, either on constrained IoT devices or on the infrastructure nodes, still use the long global IDs to identify each other, while the network performs translation which is transparent to these applications. An IoT node carries its global ID no matter where it moves, even when it is relocated to another local IoT domain and is assigned with a new LUID. This ensures the global reach-ability and mobility handling yet still considers resource constraints of embedded devices.

In addition, the optimizations for other components of the ICN-IoT system (described in earlier subsections) can lead to optimized energy efficiency as well.

7. Differences from T2TRG

T2TRG [9] is a IoT research group under IRTF focusing on research challenges of realizing IoT solutions considering IP as the narrow waist. IP-IoT has been a research topic over a decade and with active industry solutions, hence this group provides an venue to study advanced issues related to IP-IoT security, provisioning, configuration and inter-operability considering various heterogeneous application environments. ICN-IoT is a recent research effort, where the objective to exploit ICN feature of name based routing and security, caching, multicasting, mobility etc in an end-to-end manner to enable IoT services spanning both ad hoc, infrastructure and hybrid scenarios. More detailed comparison of IP-IoT versus ICN-IoT is given in Section 4.

8. Security Considerations

ICN puts security in the forefront of its design which ICN-IoT can leverage to build applications with varying security requirements, which has been discussed quite elaborately in this draft. This is an informational draft and doesn't create new considerations beyond what has been discussed.

9. Conclusions

This draft offers a comprehensive view of the benefits and design challenges of using ICN to deliver IoT services, not only because of its suitability for constraint networks but also towards ad hoc and infrastructure environments. The draft begins by motivating the need for ICN-IoT by considering popular IoT scenarios and then delves into understanding the IoT requirements from application and networking perspective. We then discuss why current approach of application layer unified IoT solutions based on IP falls short of meeting these requirements, and how ICN architecture is a more suitable towards this. We then elaborate on the design challenges in realizing an ICN-IoT architecture at scale and one that offers reliability, security, energy efficiency, mobility, self-organization among others to accommodate varying IoT service needs.

10. Acknowledgements

We thank all the contributors, reviewers and the valuable comments offered by the chairs to improve this draft.

11. Informative References

[1] Cisco System Inc., CISCO., "Cisco visual networking index: Global mobile data traffic forecast update.", 2016-2021.
[2] Shafig, M., Ji, L., Liu, A., Pang, J. and J. Wang, "A first look at cellular machine-to-machine traffic: large scale measurement and characterization.", Proceedings of the ACM Sigmetrics , 2012.
[3] The European Telecommunications Standards Institute, ETSI., "http://www.etsi.org/.", 1988.
[4] Global Intiative for M2M Standardization, oneM2M., "http://www.onem2m.org/.", 2012.
[5] Constrained RESTful Environments, CoRE., "https://datatracker.ietf.org/wg/core/charter/.", 2013.
[6] Ghodsi, A., Shenker, S., Koponen, T., Singla, A., Raghavan, B. and J. Wilcox, "Information-Centric Networking: Seeing the Forest of the Trees.", Hot Topics in Networking , 2011.
[7] Dong, L., Zhang, Y. and D. Raychaudhuri, "Enhance Content Broadcast Efficiency in Routers with Integrated Caching.", Proceedings of the IEEE Symposium on Computers and Communications (ISCC) , 2011.
[8] NSF FIA project, MobilityFirst., "http://mobilityfirst.winlab.rutgers.edu/", 2010.
[9] Thing-to-Thing Research Group, T2TRG., "https://datatracker.ietf.org/rg/t2trg/about/", 2017.
[10] OPC Foundation, OPC., "https://opcfoundation.org/", 2017.
[11] Kim, B., Lee, S., Lee, Y., Hwang, I. and Y. Rhee, "Mobiiscape: Middleware Support for Scalable Mobility Pattern Monitoring of Moving Objects in a Large-Scale City.", Journal of Systems and Software, Elsevier, 2011.
[12] Dietrich, D., Bruckne, D., Zucker, G. and P. Palensky, "Communication and Computation in Buildings: A Short Introduction and Overview", IEEE Transactions on Industrial Electronics, 2010.
[13] Keith, K., Falco, F. and K. Scarfone, "Guide to Industrial Control Systems (ICS) Security", NIST, Technical Report 800-82 Revision 1, 2013.
[14] Darianian, M. and Martin. Michael, "Smart home mobile RFID-based Internet-of-Things systems and services.", IEEE, ICACTE, 2008.
[15] Zhu, Q., Wang, R., Chen, Q., Chen, Y. and W. Qin, "IOT Gateway: Bridging Wireless Sensor Networks into Internet of Things", IEEE/IFIP, EUC, 2010.
[16] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X. and G. Wang, "Contextualized information-centric home network", ACM, Sigcomm, 2013.
[17] Huang, R., Zhang, J., Hu, Y. and J. Yang, "Smart Campus: The Developing Trends of Digital Campus", 2012.
[18] Yan, Y., Qian, Y., Hu, Y. and J. Yang, "A Survey on Smart Grid Communication Infrastructures: Motivations, Requirements and Challenges", IEEE Communications Survey and Tutorials, 2013.
[19] Chai, W., Katsaros, K., Strobbe, M. and P. Romano, "Enabling Smart Grid Applications with ICN", ICN Sigcomm, 2015.
[20] Katsaros, K., Chai, W., Wang, N. and G. Pavlou, "Information-centric Networking for Machine-to-Machine Data Delivery: A Case Study in Smart Grid Applications", IEEE Network, 2014.
[21] Mael, A., Maheo, Y. and F. Raimbault, "CoAP over BP for a delay-tolerant internet of things", Future Internet of Things and Cloud (FiCloud), IEEE, 2015.
[22] Patrice, R. and H. Rivano, "Tests Scenario on DTN for IOT III Urbanet collaboration", Dissertation, INRIA, 2015.
[23] Kevin, F., "Comparing Information-Centric and Delay-Tolerant Networking", Local Computer Networks (LCN), 2012 IEEE 37th Conference on. IEEE, 2012..
[24] Miao, Y. and Y. Bu, "Research on the Architecture and Key Technology of Internet of Things (loT) Applied on Smart Grid", IEEE, ICAEE, 2010.
[25] Castro, M. and A. Jara, "An analysis of M2M platforms: challenges and opportunities for the Internet of Things", IMIS, 2012.
[26] Gubbi, J., Buyya, R. and S. Marusic, "Internet of Things (IoT): A vision, architectural elements, and future directions", Future Generation Computer Systems, 2013.
[27] Vandikas, K. and V. Tsiatsis, "Performance Evaluation of an IoT Platform. In Next Generation Mobile Apps, Services and Technologies(NGMAST)", Next Generation Mobile Apps, Services and Technologies (NGMAST), 2014.
[28] Zhang, Y., Yu, R., Nekovee, M., Liu, Y., Xie, S. and S. Gjessing, "Cognitive Machine-to-Machine Communications: Visions and Potentials for the Smart Grid", IEEE, Network, 2012.
[29] Zhou, H., Liu, B. and D. Wang, "Design and Research of Urban Intelligent Transportation System Based on the Internet of Things", Springer Link, 2012.
[30] Alessandrelli, D., Petracca, M. and P. Pagano, "T-Res: enabling reconfigurable in-network processing in IoT-based WSNs.", International Conference on Distributed Computing in Sensor Systems (DCOSS) , 2013.
[31] Kovatsch, M., Mayer, S. and B. Ostermaier, "Moving application logic from the firmware to the Cloud: towards the thin server architecture for the internet of things.", in Proc. 6th Int. Conf. on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS) , 2012.
[32] Zhang, M., Yu, T. and G. Zhai, "Smart Transport System Based on the Internet of Things", Applied Mechanics and Materials, 2012.
[33] Zhang, A., Yu, R., Nekovee, M. and S. Xie, "The Internet of Things for Ambient Assisted Living", IEEE, ITNG, 2010.
[34] Savola, R., Abie, H. and M. Sihvonen, "Towards metrics-driven adaptive security management in E-health IoT applications.", ACM, BodyNets, 2012.
[35] Jacobson, V., Smetters, D., Plass, M., Stewart, P., Thornton, J. and R. Braynard, "VoCCN: Voice-over Content-Centric Networks", ACM, ReArch, 2009.
[36] Piro, G., Cianci, I., Grieco, L., Boggia, G. and P. Camarda, "Information Centric Services in Smart Cities", ACM, Journal of Systems and Software, 2014.
[37] Gaur, A., Scotney, B., Parr, G. and S. McClean, "Smart City Architecture and its Applications Based on IoT - Smart City Architecture and its Applications Based on IoT", Procedia Computer Science, Volume 52, 2015, Pages 1089-1094.
[38] Herrera-Quintero, L., Banse, K., Vega-Alfonso, J. and A. Venegas-Sanchez, "Smart ITS sensor for the transportation planning using the IoT and Bigdata approaches to produce ITS cloud services", 8th Euro American Conference on Telematics and Information Systems (EATIS), Cartagena, 2016, pp. 1-7.
[39] Melis, A., Pardini, M., Sartori, L. and F. Callegati, "Public Transportation, IoT, Trust and Urban Habits", Internet Science: Third International Conference, INSCI 2016, Florence, Italy, September 12-14, 2016, Proceedings.
[40] Tonneau, A., Mitton, N. and J. Vandaele, "A Survey on (mobile) Wireless Sensor Network Experimentation Testbeds", 2014 IEEE International Conference on Distributed Computing in Sensor Systems, Marina Del Rey, CA, 2014, pp. 263-268.
[41] Zhilin, Y., "Mobile phone location determination and its impact on intelligent transportation systems", IEEE Transactions on Intelligent Transportation Systems, vol. 1, no. 1, pp. 55-64, Mar 2000.
[42] Papadimitratos, P., La Fortelle, A., Evenssen, K., Brignolo, R. and S. Cosenza, "Vehicular communication systems: Enabling technologies, applications, and future outlook on intelligent transportation", IEEE Communications Magazine, vol. 47, no. 11, pp. 84-95, November 2009.
[43] Zhang, Yu., Afanasyev, A., Burke, J. and L. Zhang, "A survey of mobility support in named data networking", Computer Communications Workshops (INFOCOM WKSHPS), 2016 IEEE Conference on. IEEE, 2016.
[44] Xylomenos, G., Ververidis, C., Siris, V. and N. Fotiou et al, "A survey of information-centric networking research", IEEE Communications Surveys and Tutorials, Volume: 16, Issue: 2, Second Quarter 2014 .
[45] Mavromoustakis, C., Mastorakis, G. and J. Batalla, "Internet of Things (IoT) in 5G Mobile Technologies", ISBN,3319309137,Springer.
[46] Firner, S., Medhekar, S. and Y. Zhang, "PIP Tags: Hardware Design and Power Optimization", in Proceedings of HotEmNets, 2008.
[47] Masek, P., Masek, J., Frantik, P. and R. Fujdiak, "A Harmonized Perspective on Transportation Management in Smart Cities: The Novel IoT-Driven Environment for Road Traffic Modeling", Sensors, Volume 16, Issue 11, 2016.
[48] Abreu, D., Velasquez, K., Curado, M. and E. Monteiro, "A resilient Internet of Things architecture for smart cities", Annals of Telecommunications, Volume 72, Issue 1, Pages 19-30, 2017.
[49] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A. and G. Wang, "Information-centric Networking based Homenet", IEEE/IFIP, 2013.
[50] Dannewitz, C., D' Ambrosio, M. and V. Vercellone, "Hierarchical DHT-based name resolution for information-centric networks", 2013.
[51] Fasoloy, E., Rossiy, M. and M. Zorziy, "In-network Aggregation Techniques for Wireless Sensor Networks: A Survey", IEEE Wireless Communications, 2007.
[52] Chai, W., He, D. and I. Psaras, "Cache "less for more" in information-centric networks", ACM, IFIP, 2012.
[53] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo. and N. Nishinaga, "Catt: potential based routing with content caching for icn", IEEE Communication Magazine, 2012.
[54] Drira, W. and F. Filali, "Catt: An NDN Query Mechanism for Efficient V2X Data Collection", Eleventh Annual IEEE International Conference on Sensing, Communication, and Networking Workshops (SECON Workshops), 2014.
[55] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R. and D. Raychaudhuri, "Enabling internet-of-things services in the mobilityfirst future internet architecture", IEEE, WoWMoM, 2012.
[56] Raychaudhuri, D., Nagaraj, K. and A. Venkatramani, "Mobilityfirst: a robust and trustworthy mobility-centric architecture for the future internet.", ACM SIGMOBILE Mobile Computing and Communications Review 16.3 (2012): 2-13.
[57] Sun, Y., Qiao, X., Cheng, B. and J. Chen, "A low-delay, lightweight publish/subscribe architecture for delay-sensitive IOT services", IEEE, ICWS, 2013.
[58] Azgin, A., Ravindran, R. and GQ. Wang, "Mobility study for Named Data Networking in wireless access networks", IEEE, ICC, 2014.
[59] Azgin, A., Ravindran, R., Chakraborti, A. and GQ. Wang, "Seamless Producer Mobility as a Service in Information Centric Networks", ACM ICN Sigcomm, IC5G Workshop, 2016.
[60] Wang, L., Wakikawa, R., Kuntz, R. and R. Vuyyuru, "Data Naming in Vehicle-to-Vehicle Communications", IEEE, Infocm, Nomen Workshop, 2012.
[61] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T. and M. Wahlisch, "Information Centric Networking in the IoT:Experiments with NDN in the Wild", ACM, ICN Siggcomm, 2014.
[62] Simona, C. and M. Mongiello, "Pushing the role of information in ICN", Telecommunications (ICT), 2016 23rd International Conference on. IEEE, 2016..
[63] Li, B., Huang, D., Wang, Z. and Y. Zhu, "Attribute-based Access Control for ICN Naming Scheme", IEEE Transactions on Dependable and Secure Computing, vol.PP, no.99, pp.1-1..
[64] Polyzos, G. and N. Fotiou, "Building a reliable Internet of Things using Information-Centric Networking", Journal of Reliable Intelligent Environments, vol.1, no.1, 2015..
[65] Pandurang, K., Xu, W., Trappe, W. and Y. Zhang, "Temporal privacy in wireless sensor networks: Theory and practice", ACM Transactions on Sensor Networks (TOSN) 5, no. 4 (2009): 28..
[66] Trossen, D., Sarela, M. and K. Sollins, "Arguments for an information-centric internetworking architecture.", ACM SIGCOMM Computer Communication Review 40.2 (2010): 26-33.
[67] Zhang, G., Li, Y. and T. Lin, "Caching in information centric networking: A survey.", Computer Networks 57.16 (2013): 3128-3141.
[68] Gronbaek, I., "Architecture for the Internet of Things (IoT): API and interconnect", IEEE, SENSORCOMM, 2008.
[69] Tian, Y., Liu, Y., Yan, Z., Wu, S. and H. Li, "RNS-A Public Resource Name Service Platform for the Internet of Things", IEEE, GreenCom, 2012.
[70] Roussos, G. and P. Chartier, "Scalable id/locator resolution for the iot", IEEE, iThings,CPSCom, 2011.
[71] Amadeo, M. and C. Campolo, "Potential of information-centric wireless sensor and actuator networking", IEEE, ComManTel, 2013.
[72] Nelson, S., Bhanage, G. and D. Raychaudhuri, "GSTAR: generalized storage-aware routing for mobilityfirst in the future mobile internet", ACM, MobiArch, 2011.
[73] Trappe, W., Zhang, Y. and B. Nath, "MIAMI: methods and infrastructure for the assurance of measurement information", ACM, DMSN, 2005.
[74] Rouf, I., Mustafa, H., Taylor, T., Oh, S., Xu, W., Gruteser, M., Trappe, W. and I. Seskar, "Security and privacy vulnerabilities of in-car wireless networks: A tire pressure monitoring system case study", USENIX, 2010.
[75] Liu, R. and W. Trappe, "Securing Wireless Communications at the Physical Layer", Springer, 2010.
[76] Xiao, L., Greenstein, L., Mandayam, N. and W. Trappe, "Using the physical layer for wireless authentication in time-variant channels", IEEE Transactions on Wireless Communications, 2008.
[77] Sun, S., Lannom, L. and B. Boesch, "Handle system overview", IETF, RFC3650, 2003.
[78] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[79] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014.
[80] Barnes, R., "Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)", RFC 7165, DOI 10.17487/RFC7165, April 2014.
[81] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012.
[82] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003.
[83] marc.mosko@parc.com, m., Uzun, E. and C. Wood, "CCNx Key Exchange Protocol Version 1.0", Internet-Draft draft-wood-icnrg-ccnxkeyexchange-01, October 2016.
[84] Sun, S., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 2014.
[85] Liu, X., Trappe, W. and Y. Zhang, "Secure Name Resolution for Identifier-to-Locator Mappings in the Global Internet", IEEE, ICCCN, 2013.
[86] Boguna, M., Fragkiskos, P. and K. Dmitri, "Sustaining the internet with hyperbolic mapping", Nature Communications, 2010.
[87] Shang, W., "Securing building management systems using named data networking", IEEE Network 2014.
[88] Fayazbakhsh, S. and et. et al, "Less pain, most of the gain: Incrementally deployable icn", ACM, Siggcomm, 2013.
[89] Burke, J. and et. et al, "Securing instrumented environments over Content-Centric Networking: the case of lighting control", INFOCOM, Computer Communications Workshop, 2013.
[90] Rao, A., Schelen, O. and A. Lindgren, "Performance Implications for IoT over Information Centric Networks", Performance Implications for IoT over Information Centric Networks, ACM CHANTS 2016.
[91] Li, S., Zhang, Y., Dipankar, R. and R. Ravindran, "A comparative study of MobilityFirst and NDN based ICN-IoT architectures", IEEE, QShine, 2014.
[92] Chen, J., Li, S., Yu, H., Zhang, Y. and R. Ravindran, "Exploiting icn for realizing service-oriented communication in iot", IEEE, Communication Magazine, 2016.
[93] Quevedo, J., Corujo, D. and R. Aguiar, "A Case for ICN usage in IoT environments", Global Communications Conference GLOBECOM, IEEE, Dec 2014, Pages 2770-2775.
[94] Lindgren, A., Ben Abdesslem, F., Ahlgren, B. and O. Schelen, "Design Choices for the IoT in Information-Centric Networks", IEEE Annual Consumer Communications and Networking Conference (CCNC) 2016.
[95] Grieco, L., Alaya, M. and K. Drira, "Architecting Information Centric ETSI-M2M systems", IEEE, Pervasive and Computer Communications Workshop (PERCOM), 2014.
[96] Compagno, A., Conti, M. and R. Dorms, "OnboardICNg: a Secure Protocol for On-boarding IoT Devices in ICN", ICN, Sigcomm, 2016.
[97] Grieco, L., Rizzo, A., Colucci, R., Sicari, S., Piro, G., Di Paola, D. and G. Boggia, "IoT-aided robotics applications: technological implications, target domains and open issues", Elsevier Computer Communications, Volume 54, 1 December, 2014.
[98] InterDigital, WhitePaper., "Standardized M2M Software Development Platform", 2011.
[99] Boswarthick, D., "M2M Communications: A Systems Approach", 2012.
[100] Swetina, J., Lu, G., Jacobs, P., Ennesser, F. and J. Song, "Toward a standardized common M2M service layer platform: Introduction to oneM2M", IEEE Wireless Communications, Volume 21, Number 3, June 2014.
[101] Wang, L., Wang, Z. and R. Yang, "Intelligent Multiagent Control System for Energy and Comfort Management in Smart and Sustainable Buildings", IEEE Transactions on Smart Grid, vol. 3, no. 2, pp. 605-617, June 2012..
[102] Lawrence, T., Boudreau, M. and L. Helsen, "Ten questions concerning integrating smart buildings into the smart grid, Building and Environment", Building and Environment, Volume 108, 1 November 2016, Pages 273-283..
[103] Hassan, A. and D. Kim, "Named data networking-based smart home", ICT Express 2.3 (2016): 130-134..
[104] Burke, J., Horn, A. and A. Marianantoni, "Authenticated lighting control using named data networking", UCLA, NDN Technical Report NDN-0011 (2012)..
[105] Afanasyev, A., "Packet fragmentation in ndn: Why ndn uses hop-by-hop fragmentation.", UCLA, NDN Technical Report NDN-0032 (2015)..
[106] Quan, Wei., Xu, C., Guan, J., Zhang, H. and L. Grieco, "Scalable Name Lookup with Adaptive Prefix Bloom Filter for Named Data Networking", IEEE Communications Letters, 2014.
[107] Wang, Yi., Pan, T., Mi, Z., Dai, H., Guo, X., Zhang, T., Liu, B. and Q. Dong, "NameFilter: Achieving fast name lookup with low memory cost via applying two-stage Bloom filters", INFOCOM, 2013.
[108] So, W., Narayanan, A., Oran, D. and Y. Wang, "Toward fast NDN software forwarding lookup engine based on Hash tables", ACM, ANCS, 2012.
[109] Amadeo, M., Campolo, C., Iera, A. and A. Molinaro, "Named data networking for IoT: An architectural perspective", IEEE, EuCNC, 2014.
[110] Amadeo, M., Campolo, C., Iera, A. and A. Molinaro, "Information centric networking in iot scenarios: The case of a smart home", IEEE ICC, June 2015.
[111] Somani, N., Chanda, A., Nelson, S. and D. Raychaudhuri, "Storage- Aware Routing for Robust and Efficient Services in the Future Mobile Internet", Proceedings of ICC FutureNet V, 2012.
[112] Blefari Melazzi, N., Detti, A., Arumaithurai, M. and K. Ramakrishnan, "Internames: A name-to-name principle for the future internet", QShine, August 2014.
[113] Sifalakis, M., Kohler, B., Christopher, C. and C. Tschudin, "An information centric network for computing the distribution of computations", ACM, ICN Sigcomm, 2014.
[114] Lu, R., Lin, X., Zhu, H. and X. Shen, "SPARK: a new VANET-based smart parking scheme for large parking lots", INFOCOM, 2009.
[115] Wang, H. and W. He, "A reservation-based smart parking system", The First International Workshop on Cyber-Physical Networking Systems, 2011.
[116] Qian, L., "Constructing Smart Campus Based on the Cloud Computing and the Internet of Things", Computer Science 2011.
[117] Project, BonVoyage., "European Unions - Horizon 2020, http://bonvoyage2020.eu/", 2016.
[118] Li, S., Zhang, Y., Raychaudhuri, D., Ravindran, R., Zheng, Q., Wang, GQ. and L. Dong, "IoT Middleware over Information-Centric Network", Global Communications Conference (GLOBECOM) ICN Workshop, 2015.
[119] Li, S., Chen, J., Yu, H., Zhang, Y., Raychaudhuri, D., Ravindran, R., Gao, H., Dong, L., Wang, GQ. and H. Liu, "MF-IoT: A MobilityFirst-Based Internet of Things Architecture with Global Reachability and Communication Diversity", IEEE International Conference on Internet-of-Things Design and Implementation (IoTDI), 2016.
[120] Adhatarao, S., Chen, J., Arumaithurai, M. and X. Fu, "Comparison of naming schema in ICN", IEEE LANMAN, June , 2016.
[121] Campolo, C., Corujo, D., Iera, A. and R. Aguiar, "Information-centric Networking for Internet-of-things: Challenges and Opportunities", IEEE Networks, Jan , 2015.

Authors' Addresses

Prof.Yanyong Zhang WINLAB, Rutgers University 671, U.S 1 North Brunswick, NJ 08902 USA EMail: yyzhang@winlab.rutgers.edu
Prof. Dipankar Raychadhuri WINLAB, Rutgers University 671, U.S 1 North Brunswick, NJ 08902 USA EMail: ray@winlab.rutgers.edu
Prof. Luigi Alfredo Grieco Politecnico di Bari (DEI) Via Orabona 4 Bari, 70125 Italy EMail: alfredo.grieco@poliba.it
Prof. Emmanuel Baccelli INRIA Room 148, Takustrasse 9 Berlin, 14195 France EMail: Emmanuel.Baccelli@inria.fr
Jeff Burke UCLA REMAP 102 East Melnitz Hall Los Angeles, CA 90095 USA EMail: jburke@ucla.edu
Ravishankar Ravindran Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA EMail: ravi.ravindran@huawei.com
Guoqiang Wang Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA EMail: gq.wang@huawei.com
Anders Lindgren RISE SICS Box 1263 Kista, SE-164 29 SE EMail: anders.lindgren@ri.se
Bengt Ahlgren RISE SICS Box 1263 Kista, CA SE-164 29 SE EMail: bengt.ahlgren@ri.se
Olov Schelen Lulea University of Technology Lulea SE-971 87 SE EMail: lov.schelen@ltu.se