Internet-Draft Data-centric CoAP February 2021
Gündoğan, et al. Expires 26 August 2021 [Page]
TODO Working Group
Intended Status:
C. Gündoğan
HAW Hamburg
C. Amsüss
TC. Schmidt
HAW Hamburg
M. Waehlisch
link-lab & FU Berlin

A Data-centric Deployment Option for CoAP


The information-centric networking (ICN) paradigm offers replication of autonomously verifiable content throughout a network, in which content is bound to names instead of hosts. This has proven beneficial in particular for the constrained IoT. Several approaches, the most prominent of which being Content-Centric Networking (CCNx) and Named-Data Networking (NDN), propose access to named content directly on the network layer. Independently, the CoRe WG developed mechanisms that support autonomous content processing, on-path caching, and content object security using CoAP proxies and OSCORE.

This document describes a data-centric deployment option using standard CoAP features to replicate information-centric properties and benefits to the host-centric IoT world.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (, which is archived at

Source for this draft and an issue tracker can be found at

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

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 26 August 2021.

1. Introduction

Information-Centric Networking (ICN) introduced the idea to turn named content objects into first class citizens of the Internet ecosystem. This paradigm gave rise to (i) a decoupling of content from hosts and the ability of ubiquitous content caching without content delivery networks (CDNs), and (ii) serverless routing on names without the DNS infrastructure; (iii) Named Data Networking (NDN) additionally abandoned network endpoint addresses in favor of a stateful forwarding fabric. These properties enable an asynchronous, hop-wise content fetching, which prevents forwarding of unsolicited data. The latter significantly reduces the attack surface of (Distributed) Denial-of-Service (DDoS).

All three constituents make ICN appealing to the (constrained) Internet of Things (IoT) as infrastructural burdens and common DDoS threats stand in the way of a lean and efficient inter-networking for embedded devices. Early experimental work [NDN-IOT] shows that NDN can successfully operate on very constrained nodes with noticeable resource savings compared to IP. In addition, short-term in-network caching proved valuable for increasing reliability in low-power lossy networks with nodes frequently at sleep as common at the IoT edge.

The deployment option described in this document replicates these information-centric properties using standard CoAP features. Recent experimental evaluations [OBJECTSEC][ICN-COAP] in a testbed with real IoT hardware demonstrate promising results.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Data-centric Deployment Option for CoAP

3.1. Stateful Forwarding

In the data-centric deployment, all IoT devices act as CoAP proxies with enabled caching functionality. A forwarding information base (FIB) on the application-layer describes a mapping of resource names to next-hop CoAP proxies. This mapping list is compiled statically, or is dynamically discovered in the network; future document iterations will further elaborate on this topic.

Within the IoT stub network, requests traverse multiple proxies, install forwarding state, and build return paths for corresponding responses. The use of IPv6 link-local addresses between each proxy hop is encouraged for a better 6LoWPAN compressibility. Responses return on symmetrical request paths, which consequently consumes existing forwarding state.

3.2. Content Caching

A deployment of proxy nodes on each hop enables a hop-wise caching just as performed by CCNx [RFC8569] and NDN. Responses replicate on a request path following a cache decision and cache replacement strategy. A simple and lightweight approach is to cache everywhere and replace least recently used (LRU) content.

OSCORE enables content object security for CoAP and allows for transmitting autonomously verifiable content similar to CCNx and NDN. Further details on cachable OSCORE messages is recorded in [I-D.draft-amsuess-core-cachable-oscore-00].

3.3. Corrective Actions

In contrast to end-to-end retransmissions for standard CoAP deployments, the data-centric setup performs hop-wise retransmissions in the event of message timeouts. Confirmable messages arm message timers on each proxy node.

Figure 1 illustrates the default retransmission behavior: each subsequent packet traverses the full request path to recover a lost message.

Initial request:

,-------,  Request   ,-------,  Request   ,-------,
|client |------------|router |----------->|server |
|       |  x---------|       |------------|       |
'-------'  Response  '-------'  Response  '-------'

Request retransmission:

,-------,  Request   ,-------,  Request   ,-------,
|client |------------|router |----------->|server |
|       |<-----------|       |------------|       |
'-------'  Response  '-------'  Response  '-------'
Figure 1: End-to-end recovery of lost packets.

Figure 2 demonstrates the shortening of request paths for subsequent request retransmissions due to the on-path caching functionality.

Initial request:

,-------,  Request   ,-------,  Request   ,-------,
| Proxy |----------->| Proxy |----------->| Proxy |
|(cache)|  x---------|(cache)|<-----------|(cache)|
'-------'  Response  '-------'  Response  '-------'

Request retransmission:

,-------,  Request   ,-------,            ,-------,
| Proxy |----------->| Proxy |            | Proxy |
|(cache)|<-----------|(cache)|            |(cache)|
'-------'  Response  '-------'            '-------'
Figure 2: Hop-wise recovery of lost packets with on-path caching.

Proxy nodes aggregate requests and suppress the forwarding procedure, if they already maintain an on-going request with the same cache key.

5. IANA Considerations

This document has no IANA actions.

6. References

6.1. Normative References

Amsuess, C. and M. Tiloca, "Cachable OSCORE", Work in Progress, Internet-Draft, draft-amsuess-core-cachable-oscore-00, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

6.2. Informative References

Gündoğan, C., Amsüss, C., Schmidt, TC., and M. Waehlisch, "Toward a RESTful Information-Centric Web of Things: A Deeper Look at Data Orientation in CoAP", Proceedings of 7th ACM ICN, DOI 10.1145/3405656.3418718, , <>.
Gündoğan, C., Kietzmann, P., Lenders, M., Petersen, H., Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: a comparative measurement study in the IoT", Proceedings of 5th ACM ICN, DOI 10.1145/3267955.3267967, , <>.
Gündoğan, C., Amsüss, C., Schmidt, TC., and M. Waehlisch, "IoT Content Object Security with OSCORE and NDN: A First Experimental Comparison", Proceedings of 19th IFIP Networking, , <>.
Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, , <>.


TODO acknowledge.

Authors' Addresses

Cenk Gündoğan
HAW Hamburg
Christian Amsüss
Thomas C. Schmidt
HAW Hamburg
Matthias Waehlisch
link-lab & FU Berlin