| 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
draft-zhang-icn-iot-architecture-00
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 distribution.
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 February 29, 2016.
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.
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, 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.
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]):
+----------------+ +-----------------+ +-----------------+ +------------------+ +-------------------+
|Embedded Systems| <-------> | Aggregator | <------> | Local Service | <-----> | IoT Server | <-----> | Services/Consumers|
+----------------+ +-----------------+ | Gateway | | | +-------------------+
| | +-----------------+ +------------------+
| | ^
+----------------+ +----------------+ |
| Embedded System| |Aggregator | <------------
+----------------+ +----------------+
Figure 2: ICN-IoT System Architecture
The ICN-IoT system architecture shown in Figure 2, has the following five main system components:
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 simplicity.
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.
+------------------------------------+
| (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
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].
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.
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 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).
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 [29].
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 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.
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/ 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.
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 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.
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 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 network.
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 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.
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 demands.