ICN Research Group C. Gundogan
Internet-Draft T. Schmidt
Intended status: Experimental HAW Hamburg
Expires: September 14, 2017 M. Waehlisch
link-lab & FU Berlin
March 13, 2017

Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things


Constrained IoT devices often operate more efficiently in a loosely coupled environment without maintaining end-to-end connectivity between nodes. Information Centric Networking naturally supports this demand by replicated data distribution and hop wise forwarding. This document outlines a deployment option for NDN in low-power and lossy networks (LLNs) that follows a publish-subscribe pattern. The proposed protocol scheme simplifies name-based routing significantly and facilitates even large off-duty cycles for constrained nodes.

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 September 14, 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.

Table of Contents

1. Introduction

In the emerging Internet of Things (IoT), it is expected that large quantities of very constrained sensors and actuators collect, communicate, and process massive amounts of machine data. Early experiments with constrained nodes show promising results for different deployments of ICN communication [NDN-EXP].

Characteristics of constrained nodes:

Challenges of NDN deployment [RFC7927]

1.1. Baseline Scenarios

Multiple scenarios have been discussed in [RFC7476] and [IWMT] that evaluate the applicability of ICN in IoT.

We consider two characteristic constrained IoT scenarios with the enumerated challenges:

Stationary IoT nodes within reach of fixed uplinks
for home, building, and factory automation, stationary monitoring, ...
Mobile IoT nodes with sparse coverage or intermittent connectivity
for urban or rural mobility and sensing, industrial Internet in widespread environments, disaster recovery and rescue ...

IoT scenarios usually impose routing requirements to support mobile nodes, handle failing links and to be resilient against attacks. A secure and autonomous bootstrapping is essential, especially for large-scale IoT deployments.

1.2. Benefits of Loose Coupling in the IoT

ICN decouples content consumers from data producers (decoupling in space). A more sophisticated decoupling can be provided with the publish-subscribe messaging pattern that further adds a decoupling in time and synchronization. Constrained devices in LLNs can leverage this loose coupling to increase sleep cycles and delegate the authority over as much information as possible to more powerful devices that act as content proxies. In Figure 1, once content is published to the content proxy (CP) by a producer (P), consumers (C) can retrieve this content from (CP) without interacting with the producer. This indirection when retrieving information allows (P) to align sleep cycles accordingly to the period of generating new sensor readings, instead of handling content requests from any consumers (C).

    / | \
   /  |  `-----.
  /   |   |  |  \
(P)  (C) ...... (C)

Figure 1: Content Proxy (CP) - Producer (P) - Consumer (C)

TODO: The problem of PUSH

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.

This document uses the terminology of [RFC7476], [RFC7927], and [RFC7945] for ICN entities.

The following terms are used in the document and defined as follows:

Content Proxy
Stable node for replicating content.
Cloud Gateway
A Gateway that enables content transfer to and from a remote cloud storage, possibly by performing some kind of protocol translation.
Prefix Advertisement Message.
Name Advertisement Message.

3. Publish-Subscribe in IoT Edge Networks

The publish-subscribe system is centered around prefix-specific content proxies (CPs) that are deployed in IoT edge networks. Such proxy function can be hosted on the Cloud- or Internet Gateway, or may reside on a stable, less constrained node within the IoT infrastructure. It is assumed that a CP is present for each prefix covering publishable content.

Implementing a pub-sub NDN involves several steps that are bound to the tight requirements of resource-constrained devices. These steps include:

  1. Building the prefix-specific routing topology tailored to constrained networks
  2. Mapping Publish to NDN semantics
  3. Mapping Subscribe to NDN semantics

3.1. Topology Maintenance and Routing

A (sensor) node that wants to publish a data item needs to rely on path information towards the Content Proxy. Following the approach of PANINI [PANINI], default routes will be established as follows.

Each CP in the local IoT sub-network advertises the prefix(es) it represents to the routing system. It does so by broadcasting Prefix Advertisement Messages (PAMs) on the link layer (see Section 4 for the corresponding protocol details). Nodes that newly receive PAM advertisements will add or refresh a prefix-specific default route in their FIB. Intermediate nodes in a multi-hop environment also re-broadcast PAMs, so that the entire sub-network is flooded and default route entries build a shortest path tree (SPT) towards the CP as shown in Table 1 (alternatively, a DODAG w.r.t. a gateway for redundant CPs).

PAM /  \
   /    \ PAM
 (A)    (B)
 /|\    /|\
: : :  : : : PAM

Figure 2: SPT building by Prefix Advertisement Messages (PAMs)

Information flowing from constrained sensor nodes towards a gateway is the prevalent communication pattern in the IoT (converge cast). The publish-subscribe system hence establishes a default routing (see sample FIB in Table 1) and uses the tree (DODAG) topology with default routes towards the CP as a first step of content aggregation. Content replication towards other CPs, an Internet gateway, or into a cloud can follow subsequently.

FIB with a default route
Prefix Face Lifetime
/ Fx Ft
... ... ...

It is noteworthy that the role of the new PAM message remains orthogonal to the existing Interest or Data semantics. A PAM never carries data nor requests, but persists on the control plane of name-based routing. User applications stay unaffected, and continue to rely on the NDN-specific request-response paradigm.

3.2. Mapping Publish to NDN

In classical publish-subscribe systems, a Publish is typically implemented as a push mechanism on the data plane. However, this contradicts the request-response paradigm employed by NDN. To adapt the Publish operation to NDN semantics, it is split into two phases and the required push mechanism is moved into the control plane. The two phases consist of:

  1. Announcing names of Named Data Objects (NDO) on the control plane
  2. Requesting NDOs on the data plane

The first phase is the actual announcement of names in the upwards direction towards the CP. Because of NDN's name-based routing approach, the announcement of names is subject of the routing protocol and therefore belongs to the control plane. For this purpose, the control message type Name Advertisement Message (NAM) is adapted from PANINI [PANINI]. Similarly to the PAM, a NAM message utilizes a push mechanism in the control plane without interfering with the request-response mechanism on the data plane. NAMs are directed towards the (prefix-specific) parent of a node and traverse hop-by-hop along the gradient towards the CP. Each intermediate hop on the gradient installs forwarding states in the downward direction by using the announced names in the NAM and the incoming face. Typically, states are short-lived for content replication, only. NAMs contain one or multiple names encoded as TLV elements in the payload.

Figure 3 (a) depicts the propagation of the NAM towards the (CP). In this example, the name /HAW/temp123 is announced by (C) via (A) to (CP).

|                                                                 |
|   +----------------------+  +-------------------------------+   |
|   |                      |  |                               |   |
|   |     Mt: /HAW/temp123 |  |   Mt: /HAW/temp123 = 23C      |   |
|   |     ,->(CP)          |  |          ,---(CP)<--,         |   |
|   | NAM |  /             |  |          |    /     |         |   |
|   |     | /              |  |          |   /    ,-'         |   |
|   |     (A)<-,           |  | Interest | (A)    | Data(23C) |   |
|   |       \  | NAM       |  |          |   \    `-,         |   |
|   |        \ |           |  |          |    \     |         |   |
|   |        (C)           |  |          `--->(C)---'         |   |
|   |     /HAW/temp123     |  |       /HAW/temp123 = 23C      |   |
|   |                      |  |                               |   |
|   +----------------------+  +-------------------------------+   |
|          (a) Phase 1                  (b) Phase 2               |

Figure 3: Publish

In addition to a FIB, the (CP) maintains another data structure Mt (Meta-Table) to store all announced names annotated with additional context information and a lifetime. Upon receipt of a NAM, the Mt is updated accordingly. Context information consists of generic properties attached to a name (e.g. topic names and content freshness indicators) and are out of scope of this document. The Mt has its own name and can be requested by other devices.

In the second phase, the (CP) requests the content of newly learned names from the first phase. For content requests, the regular NDN Interest-Data exchange on the data plane is used and is depicted in Figure 3 (b). Upon receipt, the content is cached on the (CP).

3.3. Mapping Subscribe to NDN

In the proposed publish-subscribe system, the Subscribe operation is equivalent to an Interest-based request of previously learned content names. A device can learn about new content by (a) Name Advertisements of the CP via dedicated prefix path (TODO) or broadcast. It may as well poll the Mt in order to learn about general updates at the CP. Context information in the Mt may give indications about periodic sensor readings, so that a periodic polling of the Mt can be aligned with the sensor reading period.

|                                                        |
|   +----------------------+  +----------------------+   |
|   |                      |  |                      |   |
|   |    Data (Mt)         |  |    Data (Nx)         |   |
|   |       ,-------->(S)  |  |       ,-------->(S)  |   |
|   |     (CP)<--------'   |  |     (CP)<--------'   |   |
|   |     /  \  Int. (Mt)  |  |     /  \  Int. (Nx)  |   |
|   |    /    \            |  |    /    \            |   |
|   |  (A)    (B)          |  |  (A)    (B)          |   |
|   |  /|\    /|\          |  |  /|\    /|\          |   |
|   | : : :  : : :         |  | : : :  : : :         |   |
|   |                      |  |                      |   |
|   +----------------------+  +----------------------+   |
|       (a) Request Mt          (b) Request Content      |

Figure 4: Subscribe

In Figure 4 (a), a subscriber (S) requests the Mt to learn about new names. A new name (Nx) is then requested via the regular Interest/Data request-response paradigm in Figure 4 (b).

The majority of constrained devices at the IoT edge are mostly content producers, but not consumers. Subscribers do not necessarily need to be part of the distribution tree, but may reach the gateway (CP) by other means.

3.4. Content Replication between Proxy Instances


4. Control Plane Messaging


5. Security Considerations


6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

6.2. Informative References

[IWMT] Kutscher, D. and S. Farrell, "Towards an Information-Centric Internet with more Things", Position Paper, Interconnecting Smart Objects with the Internet Workshop IAB, 2011.
[NDN-EXP] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC. and M. Waehlisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", Proc. of 1st ACM Conf. on Information-Centric Networking (ICN-2014) ACM DL, pp. 77-86, September 2014.
[PANINI] Schmidt, TC., Woelke, S., Berg, N. and M. Waehlisch, "Let's Collect Names: How PANINI Limits FIB Tables in Name Based Routing", Proc. of 15th IFIP Networking Conference IEEE Press, pp. 458-466, Mai 2016.
[RFC7476] Pentikousis, K., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A. and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015.
[RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T. and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016.
[RFC7945] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S. and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016.


This work was stimulated by fruitful discussions ... We would like to thank all active members for constructive thoughts and feedback. In particular, the authors would like to thank (in alphabetical order) Emmanuel Baccelli, Michael Frey, Oliver Hahm, Peter Kietzmann, Dirk Kutscher, Martine Lenders, Joerg Ott, Hauke Petersen, and Felix Shzu-Juraschek. This work was partly funded by the German Federal Ministry of Education and Research, project I3.

Authors' Addresses

Cenk Gundogan HAW Hamburg Berliner Tor 7 Hamburg, D-20099 Germany Phone: +4940428758067 EMail: Cenk.Guendogan@haw-hamburg.de
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg, D-20099 Germany EMail: t.schmidt@haw-hamburg.de URI: http://inet.haw-hamburg.de/members/schmidt
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin, D-10318 Germany EMail: mw@link-lab.net URI: http://www.inf.fu-berlin.de/~waehl