| Internet-Draft | Data-centric CoAP | February 2021 |
| Gündoğan, et al. | Expires 26 August 2021 | [Page] |
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.¶
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 (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/.¶
Source for this draft and an issue tracker can be found at https://github.com/inetrg/draft-core-icncoap.¶
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 https://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 26 August 2021.¶
Copyright (c) 2021 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 (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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.¶
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.¶
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.¶
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].¶
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 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 '-------' '-------'
Proxy nodes aggregate requests and suppress the forwarding procedure, if they already maintain an on-going request with the same cache key.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶