[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

ICN Research Group                                              Y. Zhang
Internet-Draft                                            D. Raychadhuri
Intended status: Informational                WINLAB, Rutgers University
Expires: February 29, 2016                                     L. Grieco
                                               Politecnico di Bari (DEI)
                                                            R. Ravindran
                                                                 G. Wang
                                                     Huawei Technologies
                                                         August 28, 2015

                     ICN based Architecture for IoT


   Internet of Things (IoT) promises to connect billions of objects to
   Internet.  After deploying many stand-alone IoT systems in different
   domains, the current trend is to develop a unified de-fragmented IoT
   platform so that objects can be made accessible to applications
   across organizations and domains.  Towards this goal, quite a few
   proposals have been made to build a unified IoT platform as an
   overlay on top of today's Internet.  Such overlay solutions, however,
   are inadequate to address the important challenges posed by a unified
   IoT system, especially in terms of mobility, scalability, and
   communication reliability, due to the inherent inefficiencies of the
   current Internet.  To address this problem, we propose to build a
   unified IoT platform based on the Information Centric Network (ICN)
   architecture, which we call ICN-IoT [20].  ICN-IoT leverages the
   salient features of ICN, and thus provides seamless device-to-device
   (D2D) communication, mobility support, scalability, and efficient
   content and service delivery leveraging in-network computing, caching
   and storage.

   This draft begins by motivating the need for an unified ICN-IoT
   platform to connect heterogenous IoT systems.  We then propose an
   ICN-IoT system architecture and middleware components which includes
   device/network-service discovery, naming service, IoT service
   discovery, contextual processing, pub/sub management to support
   efficient naming, data discovery, data processing and data

Status of This Memo

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

Zhang, et al.           Expires February 29, 2016               [Page 1]

Internet-Draft       ICN based Architecture for IoT          August 2015

   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 February 29, 2016.

Copyright Notice

   Copyright (c) 2015 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.  ICN-Centric Unified IoT Platform  . . . . . . . . . . . . . .   2
     1.1.  Strengths of ICN-IoT  . . . . . . . . . . . . . . . . . .   4
   2.  ICN-IoT System Architecture . . . . . . . . . . . . . . . . .   5
   3.  ICN-IoT Middleware Architecture . . . . . . . . . . . . . . .   6
   4.  ICN-IoT Middleware Functions  . . . . . . . . . . . . . . . .   7
     4.1.  Device and Network Service Discovery  . . . . . . . . . .   8
     4.2.  Service Discovery . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Naming Service  . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Context Processing and Storage  . . . . . . . . . . . . .  11
     4.5.  Publish-Subscribe Management  . . . . . . . . . . . . . .  12
     4.6.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  ICN-Centric Unified IoT Platform

   In recent years, the current Internet has become inefficient in
   supporting rapidly emerging Internet use cases, e.g., mobility,
   content retrieval, IoT, contextual communication, etc.  As a result,

Zhang, et al.           Expires February 29, 2016               [Page 2]

Internet-Draft       ICN based Architecture for IoT          August 2015

   Information Centric Networking has been proposed as a future Internet
   design to address these inefficiencies.  ICN has the following main
   features: (1) it identifies a network object (including a mobile
   device, a content, a service, or a context) by its name instead of
   its IP address, (2) a hybrid name/address routing, and (3) a delay-
   tolerant transport.  These features make it easy to realize many in-
   network functions, such as mobility support, multicasting, content
   caching, cloud/edge computing and security.

   Considering these salient features of ICN, we propose to build a
   unified IoT platform using ICN, in which the overlay IoT services are
   only needed for administrative purposes, while the publishing,
   discovery, and delivery of the IoT data/services is directly
   implemented within the ICN network.  Figure 1 shows the proposed ICN-
   centric IoT approach, which is centered around the ICN network
   instead of today's Internet.

               ______________   __________   __________
              |IoT Smart Home| |IoT Smart | |IoT Smart |
              |Management    | |Transport | |Healthcare|
              |______________| |Management| |Management|
                   \           |__________| |__________|
                    \               |             /
                     \ _____________|___________ /
                      {                         }
                      {                         }
                      {           ICN           }
                      {                         }
                        /           |         \
                       /            |          \
             _________/     ________|______   __\_____________
            {          }   {               } {                }
            {Smart home}   {Smart Transport} {Smart Healthcare}
            {__________}   {_______________} {________________}
              |      |          |      |         |          |
           ___|__  __|___     __|__  __|__   ____|____  ____|____
          |Home-1||Home-2|   |Car-1||Car-2| |Medical  ||Medcical |
          |______||______|   |_____||_____| |Devices-1||Devices-2|

             Figure 1: The proposed ICN-centric IoT unified platform.

Zhang, et al.           Expires February 29, 2016               [Page 3]

Internet-Draft       ICN based Architecture for IoT          August 2015

1.1.  Strengths of ICN-IoT

   Our proposed ICN-IoT delivers IoT services over the ICN network,
   which aims to satisfy the requirements of the open IoT platform
   (discussed in "draft-zhang-icn-iot-challenges-01.txt"[20]):

   o  Naming.  In ICN-IoT, we assign a unique name to an IoT object, an
      IoT service, or even a context.  These names are persistent
      throughout their scopes.

   o  Scalability.  In ICN-IoT, the name resolution is performed at the
      network layer, distributed within the entire network.  Thus, it
      can achieve high degree of scalability exploiting features like
      content locality, local computing, and multicasting.

   o  Resource efficiency.  In ICN-IoT, in both the constrained and non-
      constrained parts of the network, only those data that are
      subscribed by applications in the specified context will be
      delivered.  Thus, it offers a resource-efficient solution.

   o  Local traffic Pattern.  In ICN-IoT, we can easily cache data or
      services in the network, hence making more communications within
      local distances and reducing the overall traffic volume.

   o  Context-aware communications.  ICN-IoT supports contexts at
      different layers, including device layer, networking layer and
      application layer.  Contexts at the device layer include
      information such as battery level or location; contexts at the
      network layer include information such as network address and link
      quality; contexts at the application layer are usually defined by
      individual applications.  In ICN-IoT, device and network layer
      contexts are stored within the network, while network elements
      (i.e., routers) are able to resolve application-layer contexts to
      lower-layer contexts.  As a result of adopting contexts and
      context-aware communications, communications only occur under
      certain contexts that are specified by applications, which can
      significantly reduce the entire network traffic volume.

   o  Seamless mobility handling.  In ICN-IoT, ICN's name resolution
      layer allows multiple levels of mobility relying on receiver-
      oriented nature for self-recovery for consumers, to multicasting
      and late-binding techniques to realize seamless mobility support
      of producing nodes.

   o  Data storage.  In ICN-IoT, data are stored locally, either by the
      mobile device or by the gateway nodes or at service points.  Also
      in-network storage/caching [22] also speeds up data delivery.

Zhang, et al.           Expires February 29, 2016               [Page 4]

Internet-Draft       ICN based Architecture for IoT          August 2015

   o  Security and privacy.  In ICN-IoT, secure binding between
      application-centric names and content instead of IP addresses to
      identify devices/data/services, is inherently more secure than the
      traditional IP paradigm [30].

   o  Communication reliability.  ICN-IoT supports delay tolerant
      communications [35], which in turn provides reliable
      communications over unreliable links.

   o  Ad hoc and infrastructure mode.  ICN-IoT supports both
      applications operating in ad-hoc and infrastructure modes.

   o  In-network processing.  ICN offers in-network processing that
      supports various network services, such as context resolution,
      multicast and mobility support.

2.  ICN-IoT System Architecture

   The ICN-IoT system architecture shown in Figure 2, has the following
   five main system components:

    +----------------+            +-----------------+           +-----------------+          +------------------+         +-------------------+
     |Embedded Systems| <-------> | Aggregator      | <------>  | Local Service   | <----->  |    IoT Server    | <-----> | Services/Consumers|
     +----------------+           +-----------------+           |     Gateway     |          |                  |         +-------------------+
            |                            |                      +-----------------+          +------------------+
            |                            |                         ^
     +----------------+            +----------------+              |
     | Embedded System|            |Aggregator      | <------------
     +----------------+            +----------------+

                                                          Figure 2: ICN-IoT System Architecture

   o  Embedded Systems: The embedded sensor has sensing and actuating
      functions and may also be able to relay data for other sensors to
      the Aggregator, through wireless or wired links.

   o  Aggregator: It interconnects various entities in a local IoT
      network.  Aggregators serve the following functionalities: device
      discovery, service discovery, and name assignment.

   o  Local Service Gateway (LSG): A LSG serves the following
      functionalities: (1) connecting the local IoT system to the rest
      of the global IoT system, (2) assigning ICN names to local
      sensors, (3) enforcing data access policies for local IoT devices,

Zhang, et al.           Expires February 29, 2016               [Page 5]

Internet-Draft       ICN based Architecture for IoT          August 2015

      and (4) running context processing services to generate
      information specified by application-specific contexts (instead of
      raw data) to the IoT server.

   o  IoT Server: The IoT server is a centralized server that maintains
      subscription memberships and provides the lookup service for
      subscribers.  Unlike legacy IoT servers that are involved in the
      data path from publishers to subscribers -- raising the concern of
      its interfaces being a bottleneck -- the IoT server in our
      architecture is only involved in the control path where publishers
      and subscribers exchange their names and certificates.

   o  Services/Consumer: These are application instances interacting
      with the IoT server to fetch or be notified of anything of
      interest within the scope of the IoT service.

   Specifically, the logical topology of the IoT system can be mesh-
   like, with every sensor attached to one or more aggregators, while
   every aggregator is attached to a LSG and all the LSGs connected to
   the IoT server.  Thus, each sensor has its aggregators, each of which
   in turn has its LSG.  All sensors share the same IoT server.  All the
   aggregators that are attached to the same LSG are neighbors to each
   other.  Though our middleware supports mesh topology, in the rest of
   the draft, we will focus on the tree topology for the sake of

3.  ICN-IoT Middleware Architecture

   The proposed ICN-IoT middleware aims to bridge the gap between
   underlying ICN functions and IoT applications.

   The middleware functions are shown in Fig. 3 and it includes six core
   functions: device and network service discovery, naming service,
   Context Processing and Storage, IoT service discovery, Pub/Sub
   management, and security.

   In contrast to centralized or overlay-based implementation in the
   legacy IP-based IoT platform, ICN-IoT architecture pushes a large
   portion of the functionalities to the network layer, such as naming
   resolution, mobility management, in-network processing/caching,
   context processing, which greatly simplifies the middleware design.

Zhang, et al.           Expires February 29, 2016               [Page 6]

Internet-Draft       ICN based Architecture for IoT          August 2015

                                |         (IoT Middleware)           |
                                |                                    |
                                |   +----------------------+  +--+   |
                                |   |  Pub/Sub Management  |  |  |   |       +---------------------+
                                |   +----------------------+  |  |   |       |      Consumer       |
           +-------------+      |   |IoT Service Discovery |  |S |   |       |  +-------------+    |
           | Sensor      |      |   +----------------------+  |E |   |       |  |    App      |    |
           + ----------- +      |   |Context Processing &  |  |C |   |       |  +-------------+    |
           |Gateway      |<-->  |   | and Storage          |  |U |   | <-->  |  |  Service    |    |
           +-------------+      |   +----------------------+  |R |   |       |  +-------------+    |
           |Actuator     |      |   |    Naming Service    |  |I |   |       |                     |
           +-------------+      |   +----------------------+  |T |   |       +---------------------+
           |Smart thing  |      |   | Device/ Network      |  |Y |   |
           +-------------+      |   | Service Discovery    |  |  |   |
                                |   +----------------------+  +--+   |
                                          ^          ^
                                          |          |
                                          V          V
                            |                  ICN Network                |
                            |   +-------------------------------------+   |
                            |   |   Optional: In-network Computing    |   |
                            |   |    (Data Aggregation/Fusion)        |   |
                            |   +-------------------------------------+   |
                            |   |         Network Service             |   |
                            |   +-------------------------------------+   |
                            |   |          Name Based Routing         |   |
                            |   +-------------------------------------+   |
                            |   |         Mobility and Security       |   |
                            |   +-------------------------------------+   |

                    Figure 3: The ICN-IoT Middleware Functions

4.  ICN-IoT Middleware Functions

   The ICN-IoT middleware mainly consists of the following functions:
   device and network service discovery, service discovery, naming
   service, publish/subscribe management, context processing, and
   security.  For each of these functions we highlight what the function
   achieves, advantages an ICN architecture enables in realizing this
   function, and provide discussion of how the function can be realized
   considering NDN [24] and MobilityFirst (MF) [23].

Zhang, et al.           Expires February 29, 2016               [Page 7]

Internet-Draft       ICN based Architecture for IoT          August 2015

   Please note that most of these functions are implemented on
   aggregators, LSGs and the IoT servers, and only very limited
   functions (mainly for device discovery) are implemented on resource-
   constrained sensors.

4.1.  Device and Network Service Discovery

   Device discovery is a key component of any IoT system.  The objective
   of device discovery is to expose new devices to the rest of the IoT
   system -- every entity should be exposed to its direct upstream
   device and possibly other devices.  Specifically, it includes the
   following three aspects: (1) a newly-added sensor should be exposed
   to its aggregator, and possibly to its LSG and the IoT server; (2) a
   newly-added aggregator is exposed to its LSG, and possibly to its
   neighbor aggregators; and (3) a newly-added LSG should be exposed to
   the IoT server.  We note that device discovery could be used in other
   contexts, such as neighboring sensors discovering each other to form
   routing paths, but in this draft, we use the term to specifically
   mean discovering new devices for IoT middleware purpose.

   During device discovery for newly-added sensors, the sensor passes
   its device-level information (such as manufacture ID and model
   number) and application-level information (such as service type and
   data type) to the upstream devices.  If the sensor is to have an ICN
   name, the name is assigned by the naming service (described in
   Section 4.3), and recorded by both the LSG and the aggregator (and
   possibly the IoT server).

   ICN enables flexible and context-centric device discovery which is
   important in IoT ecosystem where heterogeneous IoT systems belonging
   to different IoT services may co-exist.  Contextualization is a
   result of name-based networking where different IoT services can
   agree on unique multicast names that can be pre-provisioned in end
   devices and the network infrastructure using the routing control
   plane.  This also has an advantage of localizing device discovery to
   regions of network relevant to an ICN service, also enabling certain
   level of IoT asset security.  In contrast IP offers no such natural
   IoT service mapping; any forced mapping of this manner will entail
   high configuration cost both in terms of device configuration, and
   network control and forwarding overhead.

   In the device discovery phase, sensors expose their information, such
   as its manufacture secure ID and model name, to the upstream
   aggregators pulling information from sensors.  There are two ways of
   achieving this aim: (1) sensors pushing the information towards the
   aggregators, and (2) aggregators pulling the information from
   sensors.  In both NDN and MF, the pulling method is used.  In NDN,
   this process is initiated by the configuration service running on

Zhang, et al.           Expires February 29, 2016               [Page 8]

Internet-Draft       ICN based Architecture for IoT          August 2015

   LSG, which periodically broadcasts discovery Interests (using the
   name /iot/model).The new sensor replies to the discovery interest
   with its information, and the configuration service then registers
   the sensor and generates a local ICN name for the sensor.  In MF, we
   can set group-GUID as the destination address, and the configuration
   service issues a request via multicasting.  When receiving such
   request, the new device replies with the manufacture secure ID, and
   the configuration service registers the device and generates a local
   ICN name for it.

   The network service discovery for IoT infrastructure service like
   naming, gateway, or context-processing service is hosted on LSGs or
   Aggregators.  These devices periodically broadcast their services,
   which will be responded to by sensors that need these services.
   Please note that only those sensors that need naming service or
   context processing service will respond.  The detailed process is
   very similar to that involved in the device discovery (which is
   described above).

4.2.  Service Discovery

   Service discovery intends to learn IoT services that are hosted by
   one aggregator by its neighbor aggregators.  The requirements include
   low protocol overhead (including low latency and low control message
   count), and discovery accuracy.

   In today's IoT platforms, sensors, aggregators and LSGs are connected
   via IP multicast, which involves complicated group management and
   multicast name to IP translation service.  Multicast, however, is
   greatly simplified in ICN as most ICN architectures have natural
   support for multicast.

   Below, we explain how service discovery is implemented.  The key to
   service discovery is to expose aggregator's services to its neighbor
   aggregators.  How this is implemented differs in NDN and MF.  In NDN,
   the source aggregator broadcasts an interest using the well-known
   name /area/servicename/certificate, which will eventually reach the
   destination aggregator.  NDN's Interest/Data mechanisms allows only
   one response for each Interest send while discovery requires to learn
   multiple entities, hence efficient discovery is realized using
   exclusion via Selectors in the protocol or as an overlay protocol

   After establishing the multicast group, the source aggregator sends a
   request containing the service name and certificate to the multicast
   group.  The destination aggregator that hosts the service checks the
   certificate and registers the source Aggregator if there is a matched

Zhang, et al.           Expires February 29, 2016               [Page 9]

Internet-Draft       ICN based Architecture for IoT          August 2015

   service.  It replies with an acknowledgment containing certificate to
   the source aggregator.

   For secure service discovery, a secured name needs to assigned to the
   service host.  Especially in MF IoT, secured group GUID is utilized
   to realize service request multicast, which may be owned by multiple
   hosts, hence conventional public/private key scheme may not be
   suitable for this case.  As an alternative, group key management
   protocol (GKMP) [31] can be adopted to resolved the issue above -- A
   naming service residing at LSG or IoT server (depending on
   application scope) generates a group public key that used as group
   GUID for a service, then this group public/private keys pair is
   assigned to each Aggregator that host this service.  The service host
   Aggregator in the group then listen on this group GUID, and use the
   group private key to decrypt the incoming discovery message.
   Finally, we note that this form of secure service discovery is
   difficult for NDN.

   As an example of NDN smart home, a thermostat expresses a request to
   discover a AC service using well-known name /home/ac/certificate via
   broadcast channel.  In MF case, a multicast group GUID 1234 can be
   assigned to all home appliance IoT service.  The thermostat sends
   request containing the service name and certificate to 1234.  In both
   cases, the AC hosting this services replies with acknowledgment if
   all conditions match.

4.3.  Naming Service

   The objective of the naming service is to assure that either device
   or service itself is authenticated, attempting to prevent sybil (or
   spoofing) attack [31] and that the assigned name closely binds to the
   device (or service).  Naming service is specific to MobilityFirst,
   and it is hard to achieve in the context of NDN.  Naming service
   assigns and authenticates sensor and device names.  An effective
   naming service should be secure, persistent, and able to support a
   large number of application agnostic names.

   Traditional IoT systems use IP addresses as names, which are insecure
   and non-persistant.  IP addresses also have relatively poor
   scalability, due to its fixed structure.  Instead, ICN separates
   names from locators, and assigns unique and persistent names to each
   sensor/device, which satisfies the above requirements.

   In what follows, we discuss an approach for secure naming service in
   ICN-IoT.  We first consider the case where the embedded system is
   programmable so that before deployment, the owner can preload
   identity information (such as secure ID, a pair of public/private key
   and a certificate) , or has some manufacture ID and a pair of public/

Zhang, et al.           Expires February 29, 2016              [Page 10]

Internet-Draft       ICN based Architecture for IoT          August 2015

   private key (which is certified by the manufacturer).  That is, the
   device is associated with information including device identity,
   public/private keys (PK_{device}, SK_{device}) and a certificate
   either from the owner or the manufacturer which certifies the device
   identity and public/private keys.  When such a device is discovered,
   the aggregator will first verify the device identity (e.g., the
   device can generate a signature with the private key SK_{device} and
   present the signature and the certificate to the aggregator so that
   the aggregator can verify it), and then assign a name to the device
   as follows: the aggregator will issue a request to LSG together with
   its device identity and $PK_{device}$, so that LSG can assign an NDN
   name and generate a certificate (certifying the binding of NDN name,
   PK_{device}).  To this end, the ICN name and the certificate will be
   sent back to the aggregator and will be stored locally if the device
   is resource-restricted.  Otherwise, the ICN name and the certificate
   will be passed to the device.

   For the MF-IoT, assigning a GUID for a device is rather
   straightforward: after verifying the device identity, the Aggregator
   inserts the public key PK_{device} and device information to the
   upper layer component to verify if there is a conflict in the
   corresponding scope.  Specifically, LSG is in charge of local scope
   and IoT server guarantees the global uniqueness.  Finally, the unique
   public key is used a GUID for the new device.  Analogously, service
   discovery can be secured in a similar way.

   In the case where devices are only associated with the secure
   manufacture ID while without being pre-loaded public/private keys and
   the certificate, it is critical to assure that devices are
   authenticated by using other trust model.  For example the system can
   take advantage of the web-of-trust model or the contextually semantic
   information so that the devices manufactured by the same vendor can
   authenticate each other.  Moreover, in order to comply with the
   capability of resource-restricted devices, light-weight cryptographic
   primitive (such as symmetric cryptography) may be used instead of
   public key cryptography.

   Finally, we note that the same naming mechanism can be used to name
   higher-level IoT devices such as aggregators and LSGs.

4.4.  Context Processing and Storage

   In order to facilitate context-aware communication and data
   retrieval, we need to support context processing in the IoT system.
   The objective of context processing is to expose the sensor's low-
   level context information to upstream aggregators and LSGs, as well
   as to resolve the application's high-level context requirements using

Zhang, et al.           Expires February 29, 2016              [Page 11]

Internet-Draft       ICN based Architecture for IoT          August 2015

   lower-level sensor contexts.  The context processing service usually
   runs on both aggregators and LSGs.

   Context processing requires the underlying network to be able to
   support in-network computing at both application and network levels.
   ICN inherently supports in-networking computing and caching, which
   thus offers unique advantages compared to traditional IP network
   where the support for in-network computing and caching is poor.

   Application level contexts differ from application to application,
   and therefore, we need to provide a set of basic mechanisms to
   support efficient context processing.  Firstly, the network needs to
   define a basic set of contextual attributes for devices (including
   sensors, aggregators, and LSGs), including device-level attributes
   (such as location, data type, battery level, etc), network-level
   attributes (such as ICN names), and service-level attributes (such as
   max, min, average, etc).

   Secondly, we need to have means to expose sensor/aggregator/LSG
   contextual attributes to the rest of the system, through centralized
   services such as naming resolution service.

   Thirdly, the IoT server needs to allow applications (either producers
   or consumers) to specify their contextual requirements.  Fourthly,
   the unconstrained part of ICN-IoT needs to be able to map the higher-
   level application-specific contextual requirements to lower-level
   device-level and network-level contextual information.

4.5.  Publish-Subscribe Management

   Data Publish/Subscribe (Pub/Sub) is an important function for ICN-
   IoT, and is responsible for IoT information resource sharing and
   management.  The objective of pub/sub system is to provide
   centralized membership management service.  Efficient pub/sub
   management poses two main requirements to the underlying system: high
   data availability and low network bandwidth consumption.

   In conventional IP network, most of the IoT platforms provide a
   centralized server to aggregate all IoT service and data.  While this
   centralized architecture ensures high availability, it scales poorly
   and has high bandwidth consumption due to high volume of control/data
   exchange, and poor support of multicast.

   Next we consider two decentralized pub/sub models.  The first one is
   the Rendezvous mode that is commonly used for today's pub/sub
   servers, and the second one involves Data-Control separation that is
   unique to ICN networks where the control messages are handled by the
   centralized IoT server and the data messages are handled by the

Zhang, et al.           Expires February 29, 2016              [Page 12]

Internet-Draft       ICN based Architecture for IoT          August 2015

   underlying ICN network.  Compared to the popular Rendezvous mode
   where both control and data messages both meet at the centralized
   server, separating data and control messages can greatly improve the
   scalability of the entire system, which is enabled by the ICN

   In today's IP network, Rendezvous mode is the classic pub/sub scheme
   in which data and requests meet at an intermediate node.  In this
   case the role of the IoT server is only required to authenticate the
   consumers and providing it Rendezvous service ID.

   While NDN is a Pull-based architecture without supporting the Pub/Sub
   mode naturally, COPSS [33] proposes a solution to fix this problem.
   It integrates a push based multicast feature with the pull based NDN
   architecture at the network layer by introducing Rendezvous Node(RN).
   RN is an logical entity that resides in a subset of NDN nodes.  The
   publisher first forwards a Content Descriptor (CD) as a snapshot to
   the RN.  RN maintains a subscription table, and receives the
   Subscription message from subscriber.  The data publisher just sends
   the content using Publish packet by looking up FIB instead of PIT.
   If the same content prefix is requested by multiple subscribers, RN
   will deliver one copy of content downstream, which reduces the
   bandwidth consumption substantially.

   Compared with the Rendezvous mode in which data plane and control
   plane both reside on the same ICN network layer, we consider an
   architecture where the control message is handled by the centralized
   server while data is handled by ICN network layer.  Following the
   naming process mentioned above, the LSG has the ICN name for the
   local resource which is available for publishing on IoT server.  IoT
   server maintains the subscription membership, and receives
   subscription requests from subscribers.  Since the subscribers has no
   knowledge about the number of resource providers and their identities
   in a dynamic scenario, IoT server has to take responsibility of
   grouping and assigning group name for the resource.

   MF takes advantage of Group-GUID to identify a service provided by
   multiple resources.  This Group-GUID will be distributed to the
   subscriber as well as the publisher.  In an example of NDN, it uses
   the common prefix/home/monitoring/ to identify a group of resource
   that provides multiple monitoring services such as /home/monitoring/
   temperature and /home/monitoring/light.  The subscriber retrieves the
   prefix from the IoT server, and sends Interest toward the resource.
   In a MF example, GUID-x identifies the "home monitoring" service that
   combines with "light status" and "temperature".  The resource
   producers, i.e. the host of "temperature" and the host of "light
   status" are notified that their services belong to GUID-x, then
   listen on GUID-x.  The subscriber sends the request containing GUID-x

Zhang, et al.           Expires February 29, 2016              [Page 13]

Internet-Draft       ICN based Architecture for IoT          August 2015

   through multicasting which ultimately reach the producers at the last
   common node.  Once receiving the request, the resource producer
   unicasts the data to the subscriber.  In addition, if multiple
   resource consumers subscribe to the same resource, the idea of Group-
   GUID can be reused to group the consumers to further save bandwidth
   using multicast.

4.6.  Security

   This spans across all the middleware functions.  Generally speaking,
   the security objective is to assure that the device that connects to
   the network should be authenticated, the provided services are
   authenticated and the data generated (through sensing or actuating)
   by both devices and services can be authenticated and kept privacy
   (if needed).  To be specific, we consider the approach to secure
   device discovery, naming service and service discovery, because other
   services, such as pub/sub management and context processing and
   storage, can be properly secured according to application-specific

5.  Informative References

   [1]        Cisco System Inc., CISCO., "Cisco visual networking index:
              Global mobile data traffic forecast update.", 2009-2014.

   [2]        Mohsen, D. and M. Michael, "Smart home mobile RFID-based
              Internet-of-Things systems and services.", International
              Conference on Internet-of-Things systems and services. ,

   [3]        Zhu, Q., Wang, R., Chen, Q., Liu, Y., and W. Qin, "Iot
              gateway: Bridgingwireless sensor networks into internet of
              things.", Embedded and Ubiquitous Computing (EUC), 2010
              IEEE/IFIP 8th International Conference on. IEEE, 2010 ,

   [4]        Huang, R., "Smart Campus: The Developing Trends of Digital
              Campus.", Open Education Research 4 (2012): 004 , 2012.

   [5]        Zhu, Q., Wang, R., Chen, Q., Liu, Y., Qin, W., and W. Qin,
              "ICN based Architecture for IoT - Requirements and
              Challenges.", draft-zhang-icn-iot-challenges-00.txt ,

   [6]        Piro, R., Cianci, I., Grieco, L., Boggia, G., and P.
              Camarda, "Information Centric Services in Smart Cities.",
              Elsevier Journal of Systems and Software , 2014.

Zhang, et al.           Expires February 29, 2016              [Page 14]

Internet-Draft       ICN based Architecture for IoT          August 2015

   [7]        Grieco, L., Alaya, M., Monteil, T., and K. Drira,
              "Architecting Information Centric ETSI-M2M systems.",
              Proc. of IEEE PerCom (to appear as work in progress paper)
              , 2014.

   [8]        Dietrich, D., Bruckner, D., Zucker, G., and P. Palensky,
              "Communication and computation in buildings: A short
              introduction and overview.", IEEE Transaction of
              Industrial Electronics , 2010.

   [9]        Zhang, Y. and R. Yu, "Research on the architecture and key
              technology of Internet of Things (IoT) applied on smart
              grid.", Advances in Energy Engineering (ICAEE), 2010
              International Conference on. IEEE , 2010.

   [10]       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.

   [11]       Hong, Z., Liu, B., and D. Wang, "Design and Research of
              Urban Intelligent Transportation System Based on the
              Internet of Things.", Internet of Things. Springer Berlin
              Heidelberg , 2012.

   [12]       Min, Z., Yu, T., and G. Zhai, "Smart Transport System
              Based on the Internet of Things.", Applied mechanics and
              materials , 2011.

   [13]       Min, Z., Yu, T., Zhai, G., Zhai, G., and G. Zhai, "The
              internet of things for ambient assisted living.",
              Information Technology: New Generations (ITNG), 2010
              Seventh International Conference on , 2010.

   [14]       Reijo, S., Abie, H., and M. Sihvonen, "Towards metrics-
              driven adaptive security management in E-health IoT
              applications.", Proceedings of the 7th International
              Conference on Body Area Networks. ICST (Institute for
              Computer Sciences, Social-Informatics and
              Telecommunications Engineering) , 2012.

   [15]       Yan, Y., Qian, Y., Sharif, H., and D. Tipper, "A Survey on
              Smart Grid Communication Infrastructures: Motivations,
              Requirements and Challenges.", IEEE Communications Surveys
              and Tutorials , 2013.

Zhang, et al.           Expires February 29, 2016              [Page 15]

Internet-Draft       ICN based Architecture for IoT          August 2015

   [16]       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.

   [17]       The European Telecommunications Standards InstituteS,
              ETSI., "http://www.etsi.org/.", 1988.

   [18]       Global Intiative for M2M Standardization, oneM2M.,
              "http://www.onem2m.org/.", 2012.

   [19]       Constrained RESTful Environments, CoRE.,
              "https://datatracker.ietf.org/wg/core/charter/.", IETF,

   [20]       ICN based Architecture for IoT - Requirements and
              Challenges, ICN-IoT., "https://tools.ietf.org/html/draft-
              zhang-iot-icn-challenges-01.", IETF/ICNRG 2015.

   [21]       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.

   [22]       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.

   [23]       NSF FIA project, MobilityFirst.,
              "http://www.nets-fia.net/", 2010.

   [24]       NSF FIA project, NDN., "http://named-data.net/", 2010.

   [25]       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.

   [26]       Hui, JW. and DE. Culler, "IP is dead, long live IP for
              wireless sensor networks.", ACM, SenSys, 2008.

   [27]       AllSeen Alliance, AllJoyn.,
              "https://allseenalliance.org/developers/learn", 2015.

   [28]       "https://www.iotivity.org/about", 2015.

Zhang, et al.           Expires February 29, 2016              [Page 16]

Internet-Draft       ICN based Architecture for IoT          August 2015

   [29]       Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and
              G. Wang, "Information-centric Networking based Homenet",
              ACM, Sigcomm, 2013.

   [30]       Nikander, P., Gurtov, A., and T. Henderson, "Host identity
              protocol (HIP): Connectivity, mobility, multi-homing,
              security, and privacy over IPv4 and IPv6 networks", IEEE
              Communications Surveys and Tutorials, pp: 186-204, 2010.

   [31]       Newsome, J., Shi, E., Song, DX., and A. Perrig, "The sybil
              attack in sensor networks: analysis and defenses", IEEE,
              IPSN, 2004.

   [32]       Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Architecture", RFC Editor 1997.

   [33]       Jiachen, C., Mayutan, A., Lei, J., Xiaoming, Fu., and KK.
              Ramakrishnan, "COPSS: An efficient content oriented
              publish/subscribe system", ACM/IEEE ANCS, 2011.

   [34]       Marica, A., Campolo, C., and A. Molinaro, "Multi-source
              data retrieval in IoT via named data networking", ACM ICN
              Siggcomm, 2014.

   [35]       Nelson, S., Bhanage, G., and D. Raychaudhuri, ""GSTAR:
              generalized storage-aware routing for mobilityfirst in the
              future mobile internet", Proceedings of the sixth
              international workshop on MobiArch, pp. 19--24, 2011.

Authors' Addresses

   Prof.Yanyong Zhang
   WINLAB, Rutgers University
   671, U.S 1
   North Brunswick, NJ  08902

   Email: yyzhang@winlab.rutgers.edu

   Prof. Dipankar Raychadhuri
   WINLAB, Rutgers University
   671, U.S 1
   North Brunswick, NJ  08902

   Email: ray@winlab.rutgers.edu

Zhang, et al.           Expires February 29, 2016              [Page 17]

Internet-Draft       ICN based Architecture for IoT          August 2015

   Prof. Luigi Alfredo Grieco
   Politecnico di Bari (DEI)
   671, U.S 1
   Via Orabona 4, Bari  70125

   Email: alfredo.grieco@poliba.it

   Ravi Ravindran
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: ravi.ravindran@huawei.com

   Guoqiang Wang
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: gq.wang@huawei.com

Zhang, et al.           Expires February 29, 2016              [Page 18]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/