Publish-Subscribe Deployment Option
for NDN in the Constrained Internet of ThingsHAW HamburgBerliner Tor 7HamburgD-20099Germany+4940428758067Cenk.Guendogan@haw-hamburg.deHAW HamburgBerliner Tor 7HamburgD-20099Germanyt.schmidt@haw-hamburg.dehttp://inet.haw-hamburg.de/members/schmidtlink-lab & FU
BerlinHoenower Str. 35BerlinD-10318Germanymw@link-lab.nethttp://www.inf.fu-berlin.de/~waehlICN Research GroupConstrained 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.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 .Characteristics of constrained nodes:Battery-powered with sleep cyclesFailing nodesLow power lossy networksChallenges of NDN deployment Complexity of name-based routingState management at nodesClear separation between control and data planeAdaptation to constrained wireless transmissionMobility managementMultiple scenarios have been discussed in and that evaluate
the applicability of ICN in IoT.We consider two characteristic constrained IoT scenarios with the
enumerated challenges: for
home, building, and factory automation, stationary monitoring,
...Reliability, resilience of operationRadio coordination, coverageEnergy constraints, device lifetimeInterference with rivaling appliancesfor
urban or rural mobility and sensing, industrial Internet in
widespread environments, disaster recovery and rescue ...Exploit connectivity when availableLarge off-duty cycles of nodesPartitioned networksLimited 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.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 , 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).TODO: The problem of PUSHThe 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 . 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 ,
, and for
ICN entities.The following terms are used in the document and defined as
follows:Many-to-One communication pattern, where
multiple devices send sensor readings to one gateway.Stable node for replicating content.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.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: Building the prefix-specific routing topology tailored to
constrained networksMapping Publish to NDN semanticsMapping Subscribe to NDN semanticsA (sensor) node that wants to publish a data item needs to rely on
path information towards the Content Proxy. Following the approach of
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 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 (alternatively, a DODAG w.r.t.
a gateway for redundant CPs).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 ) and uses
the tree 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.PrefixFaceLifetime/P/FxFt.........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.Each node in the tree calculates a rank based on the rank of its
parent and a routing metric. Hence, the rank is an indication for the
position within the tree and is strictly monotonically increasing in
the downwards direction from root to leaf. For simplicity, this
document uses the hop-count routing metric to calculate the rank.
Future work can focus on more elaborate routing metrics, e.g., to
reduce packet retransmissions or improve load balancing for publish
operations.
The Routing Information Base (RIB) contains the following
information:
Variable length prefix to configure a prefix-specific default
route
16-bit unsigned integer indicating a node's rank
8-bit unsigned integer to store SPT related flags
The appropriate face towards the parent node is stored.
Entries in the NAM Cache are
<name,downstream_face> tuples. The NC is consolidated
when propagating name advertisements.
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 performed on
the control plane with a link-local scope. The two phases consist of:
Announcing names of Named Data Objects (NDO) on the
control planeRequesting NDOs on the data plane
In the first phase, the name of the NDO to publish is advertised to the
prefix-specific upstream neighbor by encoding it with TLV format in a
unicast link-local Name Advertisement Message (NAM) adopted from PANINI
. Once an upstream neighbor receives an
unsolicited NAM, the name is extracted and along with the incoming face
stored in the NAM Cache (NC) as a
<name,downstream_face> tuple. This link-local content
signaling does not establish any data paths in the PIT, nor does it
modify the FIB or the Content Store (CS).
In the second phase and as a result of an unsolicited NAM, the content
is requested from the downstream neighbor accordingly to the standard
NDN scheme with an Interest message for the name recorded in the NC on
the recorded face. When a downstream neighbor replies with the content
(Data message), this neighbor removes the corresponding NC entry and
the NDO to publish is successfully replicated one hop closer towards
the content proxy. NC entries are thus short-lived for hop-wise
replication only.
Both phases are iteratively repeated hop-wise until the content proxy
is reached. Being the root of this prefix-specific spanning tree, the
content proxy has no further prefix-specific upstream neighbor and the
replication terminates. It is noteworthy, that both phases can be
interleaved, so that NAMs are signaled to the upstream neighbor, while
the content is requested from the downstream neighbor.
(a) depicts the
hop-wise replication of a published content on the gradient towards
the (CP). In this example, the name /HAW/temp_t is
advertised by the producer (P) to its parent node (A). (A) extracts
the name from the NAM and stores it along with the incoming face
in its NC. (A) then propagates the NAM further to its parent (CP)
and simultaneously requests the content from (P) as depicted in
(b). Likewise in
(c), (CP) reacts to
the incoming NAM by requesting the content from (A). NC states from
(A) and (P) are removed as soon as they respond to the request.
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 in various
ways:
Name Advertisements of the CP via dedicated prefix path
(TODO) or broadcast.By polling a dedicated data structure at the CP that records
publishings and updates. Such a data structure may contain
indicators about the periodicity of sensor readings to align
periodic polling schemes to sensor reading intervals.By encoding topics into a hierarchical naming scheme of the form
routing prefix / topic / unique_part. Inerest
timeouts for these names serve as subscription periods and must be
refreshed or retriggered for every publishing to adhere to the flow
control approach of NDN / CCNx.
TODO
The hop-wise replication described in
transparently supports publish
operations in partitioned networks. When a publish operation fails to
replicate content and no backup parent is in the vicinity ( (b)), the node marks its sub-DAG as
floating by propagating PAMs with the floating bit set
and the NC entry is preserved. Once a sub-DAG becomes connected to
another parent, the publishing is resumed ( (c)).
A node receiving a PAM from its parent with the floating bit set may
rejoin the tree using another parent in the neighborhood that is
connected to the content proxy. Rejoining the tree may result in a
worse rank.
TODOTODOTODO: add ABNFTODO: add mappings of PAM and NAM to the NDN and CCNx dialects
8-bit unsigned integer. Indicates a PAM.
1-bit floating flag. Indicates that a sub-tree is not connected
to the content proxy, when set.
7-bit unused field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
16-bit unsigned integer. Indicates a node's position
in the SPT.
16-bit unsigned integer. Indicates the length of the following
prefix in bytes.
Variable length prefix used to configure a default route within
the SPT.
8-bit unsigned integer. Indicates a NAM.
8-bit unused field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
16-bit unsigned integer. Indicates the accumulated length of
all options.
8-bit unsigned integer. Indicates the name option (0x00).
16-bit unsigned integer. Indicates the length of the name,
excluding the type and length field.
Variable length name.TODOInformation Centric Networking in the IoT: Experiments with
NDN in the WildINRIAFU BerlinINRIAHAW HamburgFU BerlinLet's Collect Names: How PANINI Limits FIB Tables in Name
Based RoutingHAW HamburgHAW HamburgHAW HamburgFU BerlinTowards an Information-Centric Internet with more
ThingsThis 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.