Skip to main content

Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things
draft-gundogan-icnrg-pub-iot-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Cenk Gündoğan , Thomas C. Schmidt , Matthias Wählisch
Last updated 2017-03-13
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-gundogan-icnrg-pub-iot-00
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
                    draft-gundogan-icnrg-pub-iot-00

Abstract

   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

Gundogan, et al.       Expires September 14, 2017               [Page 1]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Baseline Scenarios  . . . . . . . . . . . . . . . . . . .   3
     1.2.  Benefits of Loose Coupling in the IoT . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Publish-Subscribe in IoT Edge Networks  . . . . . . . . . . .   4
     3.1.  Topology Maintenance and Routing  . . . . . . . . . . . .   5
     3.2.  Mapping Publish to NDN  . . . . . . . . . . . . . . . . .   6
     3.3.  Mapping Subscribe to NDN  . . . . . . . . . . . . . . . .   7
     3.4.  Content Replication between Proxy Instances . . . . . . .   8
   4.  Control Plane Messaging . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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:

   o  Battery-powered with sleep cycles

   o  Failing nodes

   o  Low power lossy networks

   Challenges of NDN deployment [RFC7927]

   o  Complexity of name-based routing

   o  State management at nodes

   o  Clear separation between control and data plane

   o  Adaptation to constrained wireless transmission

Gundogan, et al.       Expires September 14, 2017               [Page 2]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

   o  Mobility management

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

      *  Reliability, resilience of operation

      *  Radio coordination, coverage

      *  Energy constraints, device lifetime

      *  Interference with rivaling appliances

   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 ...

      *  Exploit connectivity when available

      *  Large off-duty cycles of nodes

      *  Partitioned networks

      *  Limited dependability

      *  Environmental impact and disturbance

   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

Gundogan, et al.       Expires September 14, 2017               [Page 3]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

   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).

                                 (CP)
                                / | \
                               /  |  `-----.
                              /   |   |  |  \
                            (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.

   PAM  Prefix Advertisement Message.

   NAM  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

Gundogan, et al.       Expires September 14, 2017               [Page 4]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

   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).

                                 (CP)
                             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.

Gundogan, et al.       Expires September 14, 2017               [Page 5]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

                       +--------+------+----------+
                       | Prefix | Face | Lifetime |
                       +--------+------+----------+
                       | /      |  Fx  |    Ft    |
                       | ...    | ...  |   ...    |
                       +--------+------+----------+

                     Table 1: FIB with a default route

   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).

Gundogan, et al.       Expires September 14, 2017               [Page 6]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

    +-----------------------------------------------------------------+
    |                                                                 |
    |   +----------------------+  +-------------------------------+   |
    |   |                      |  |                               |   |
    |   |     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.

Gundogan, et al.       Expires September 14, 2017               [Page 7]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

        +--------------------------------------------------------+
        |                                                        |
        |   +----------------------+  +----------------------+   |
        |   |                      |  |                      |   |
        |   |    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

   TODO

4.  Control Plane Messaging

   TODO

5.  Security Considerations

   TODO

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,
              <http://www.rfc-editor.org/info/rfc2119>.

Gundogan, et al.       Expires September 14, 2017               [Page 8]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

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., Ed., 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,
              <http://www.rfc-editor.org/info/rfc7476>.

   [RFC7927]  Kutscher, D., Ed., 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,
              <http://www.rfc-editor.org/info/rfc7927>.

   [RFC7945]  Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
              and G. Boggia, "Information-Centric Networking: Evaluation
              and Security Considerations", RFC 7945,
              DOI 10.17487/RFC7945, September 2016,
              <http://www.rfc-editor.org/info/rfc7945>.

Gundogan, et al.       Expires September 14, 2017               [Page 9]
Internet-Draft           NDN Pub-Sub in the IoT               March 2017

Acknowledgments

   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

Gundogan, et al.       Expires September 14, 2017              [Page 10]