| ICN Research Group | C. Gundogan |
| Internet-Draft | T. Schmidt |
| Intended status: Experimental | HAW Hamburg |
| Expires: January 4, 2018 | M. Waehlisch |
| link-lab & FU Berlin | |
| July 3, 2017 |
Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things
draft-gundogan-icnrg-pub-iot-01
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.
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 January 4, 2018.
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.
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]
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:
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 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
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:
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:
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 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.
| Prefix | Face | Lifetime |
|---|---|---|
| /P/ | 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.
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:
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:
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 [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.
Figure 3 (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 Figure 3 (b). Likewise in Figure 3 (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.
+-------------+ +------------------------+ +-------------------+
| | | | | Interest |
| (CP) | | ,->(CP) | | ,----(CP)<-, |
| / | | NAM | / | | | / / |
| / | | | / | | | / / |
| (A)<-, | | ,-(A)<-, | | `>(A)---' Data |
| \ | NAM | | | \ | Data | | \ |
| \ | | | | \ | | | \ |
| (P) | | Interest `--->(P) | | (P) |
| /HAW/temp_t | | /HAW/temp_t | | /HAW/temp_t |
+-------------+ +------------------------+ +-------------------+
(a) Adv. Name (b) Replicate Content (c) Finish publish
Figure 3: Publish
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:
TODO
The hop-wise replication described in Section 3.2 transparently supports publish operations in partitioned networks. When a publish operation fails to replicate content and no backup parent is in the vicinity (Figure 4 (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 (Figure 4 (c)).
+-------------+ +-------------+ +-------------+
| | | | | |
| (CP) | | (CP) | | (CP)<-, |
| | | | | / / |
| | | X | | / / |
| (A)<-, | | (A)---' | | (A)---' |
| \ | PUB | | \ PUB | | \ PUB |
| \ | | | \ | | \ |
| (P) | | (P) | | (P) |
| /HAW/temp_t | | /HAW/temp_t | | /HAW/temp_t |
+-------------+ +-------------+ +-------------+
(a) Publish content (b) Publish fails (c) Finish Publish
Figure 4: Publish in partitioned network
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.
TODO
TODO
TODO: add ABNF
TODO: add mappings of PAM and NAM to the NDN and CCNx dialects
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PAM |F| Reserved | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Prefix Advertisement Message (PAM)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NAM | Reserved | Options Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Name Advertisement Message (NAM)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x00 | Name Length | Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Name option format
TODO
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
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.