[icnrg] ICN (NDN) auto-configuration and self-learning: best practices?

Dirk Kutscher <ietf@dkutscher.net> Wed, 20 July 2022 14:18 UTC

Return-Path: <ietf@dkutscher.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E195CC182D6F for <icnrg@ietfa.amsl.com>; Wed, 20 Jul 2022 07:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WM3uZW0kKduK for <icnrg@ietfa.amsl.com>; Wed, 20 Jul 2022 07:18:43 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4CBC182D65 for <icnrg@irtf.org>; Wed, 20 Jul 2022 07:18:42 -0700 (PDT)
Received: from [] ([]) by mrelayeu.kundenserver.de (mreue108 []) with ESMTPSA (Nemesis) id 1N6KQZ-1nQ64M3A3l-016doT for <icnrg@irtf.org>; Wed, 20 Jul 2022 16:18:39 +0200
From: Dirk Kutscher <ietf@dkutscher.net>
To: ICNRG <icnrg@irtf.org>
Date: Wed, 20 Jul 2022 16:18:35 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <90EA4FFD-7CAB-4FFC-9EE0-855C06934F37@dkutscher.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_9684BAA4-B766-441C-85BC-1D993C6B1655_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:UkXS2Z6+RHHOly6FdEQ2/cFnH4leJFnxZPQ2va8JcqOI7aMMgBh 6rOFIZOjYpzfq2xPYKrW9pI5ZRFVwDY6ccG02OR0VUGiqhjemwpGSbx39uLxaML+prkAJH9 dUFInYjz26jUsqXC5hGycn65QqoTLmV1qj9S70kmkygSNOY1LNxpK/QbNsnDcq+V6UyIiQR +e7GXjBrR/gnCKiAq1z2Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:+1Cb1Ilzy7E=:1vxu4h4j2hmJYqox0i4WF9 z0+yd5uXF7PceP4M6VW8y2m5JqWARCSZ4tG2OPhK+E4U1Oev1xwYxNlftgEWlxcwEDSyQ8ttH U2vhtbAW6Xg2H1cgfWUfq9xfEf4TEzLAyu1/Q5Lc8T3kkJPKmxi4ix82RiHrgH/aLA6pdoqL5 ipO7Reuc6jOO4glXg7sKbsZteflYC/Y2zot2Tp2Hc8Vny8sBiaCd7VKm5ubYib3DpsvxJgjy3 G6TnKz9GYNm/I56oZaZSYFAD1YuWX7xkhCuge3wO7aWCIvb+B9T6xLsOGhzIfxqxfeo1M1AAZ BqA/uNqXy38ea7ceYzUQWRW3oEUTCrsmSUH4F22qwN07oweFOC5/hDpUnz/SEjdo1kfm7tlkI 6bIiBfhOyqYoC8rkc8ZSQDDDce8sH/AeZT4vy67M3QykVB/n/ysszxMzAk7q/iUCw7PQ2rk+/ onFGPVtMFJoP5igFoCY5CayRRywJsTOVtgHTD0Le4BqXqefAiieoHrNKoXYgDFmRqq3NkN6IM YduOxZobvqL3NL6HaNvi3DfGmofvkDMdsbAPRqBpDKTc4s4BYDvUy5weVkdmhQ6YqfUETu9A8 FqyXHx1/l95qFwn1ONC6YnDZOYNIc8nhe4/PlhgJkYJSOgAiX1q4hhB+mwE0HAW1UiTjCxiwi IwnImP+uegOTPS0gVr1vRaG97YwQddKaj8ArmqdtoJa2CAoIPFNZajDTNdPh5wLZSbxn5HGDY YFTiuN8PMl5cbhjb98Z8WajrhxxPtMtvl+kEOg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/htR4Rli-wp8YcG2fRngiDq76sIY>
Subject: [icnrg] ICN (NDN) auto-configuration and self-learning: best practices?
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2022 14:18:48 -0000


I wanted to check in on the current state of auto-configuration (self-learning) in local networks (single broadcast domains) such as Ethernet networks.

## Background

Auto-configuration in the data plane (self-learning through forwarding) without requiring additional control plane interactions (e.g., routing, configuration) has always been one of the advertized ICN features.

For example, in an Ethernet (switched or not), ideally one would be using NDN with Ethernet (L2) faces. When you run NDN applications, what would be the best (reliable, efficient) way to learn about faces and routes to available data in the network? Ethernet broadcast/multicast (every node could have exactly one face) is an option that would surely work, but could incur overheads.

###  Reactive Optimistic Name-based Routing

Early work such as Reactive Optimistic Name-based Routing (RONR) for the IoT demonstrated the effectiveness of learning about forwarding options through flooding for discovery and then creating FIB entries based on the observed Data messages.

### On Broadcast-based Self-Learning

The 2017 IFIP Networking paper On Broadcast-based Self-Learning in Named Data Networking [2] discusses several aspects such as prefix granularity, trust of announcements and data, self-learning on switched Ethernet and presented an approach that leverages flood-and-learn" and prefix announcements but includes some additional mechanisms for reducing overhead etc.

### What is a "Face" in Named Data Networking?

Junxiao is discussing the related topics of "what is a face?" (interface vs. node adjacency) and multicast/broadcast in his blog posting [3], motivated by his thoughts on NDNts API Design that he also presented at a past ICNRG meeting [4].

He is also discussing ways to deal with L2 remote addresses and alludes to filtering NICs and name-based switching.

## Forwarder Implementations

In the "Wireless Multicast" section in [3], Junxiao describes a model that could be used by consumer forwarders, without requiring name-based switching in the network nor special producer support.

> In 2020, another implementation attempt was made using two faces: the physical Ethernet adapter for broadcast, and an adjacency face between C and P for unicast. Forwarding logic should extract the unicast address of P in the first Data packet, dynamically create an adjacency face and setup a route, and then send subsequent Interests on that adjacency face. This would not fully insulate the forwarding plane from understanding EndpointId, but it would be limited to the logic that perform this face creation, and hopefully does not need to change everything else.

> This direction met challenges since the design stage. Generally, face creation and route updates are assumed to infrequent, but dynamic adjacency creation violates this assumption. NFD's architecture could allow the forwarding plane to create adjacency faces. However, the only way to perform a route update is sending a packet to the control plane running on a separate thread, and it isn't possible to send a new packet while processing another packet. Thus, this attempt never got past the design stage.

Incidentally, I had used a similar design many years ago for implementing RFC 3259 (on L3 with UDP/IP multicast and unicast).

I wondered whether this has been explored further or whether new designs have been tried. The approach outlined above is IMO relatively straight-forward, would rely on Ethernet Spanning Tree and on unicast addressing at the cost of having to creating many faces potentially.

I understand that NFD constraints made this difficult to implement. Is this still the current situation?

Are there other forwarders that implement this or other approaches?

## NDN Switch design

The paper [2] and Junxiao's blog posting [3] also mention ideas and early work on switch designs that are based on name-based forwarding. In fact, Junxiao has an earlier implementation on OpenWrt [5]. I could imagine that a "production-grade" NDN switch could be quite useful in many scenarios, including the current effort on Big Data processing and distributed computing in NDN.

Have there been new attempts, potentially leveraging NDN-DPDK or other modern forwarders?

Any pointers, new ideas, feedback on any of these topics would be very welcome!


## References

1. [RONR](https://inet.haw-hamburg.de/papers/bmhsw-icnie-14.pdf)
2. [On Broadcast-based Self-Learning in Named Data Networking](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8264832&tag=1)
3. [What is a "Face" in Named Data Networking?](https://yoursunny.com/t/2021/NDN-face/)
4. [NDNts API Design](https://datatracker.ietf.org/meeting/interim-2021-icnrg-01/materials/slides-interim-2021-icnrg-01-sessa-ndnts-api-junxiao-shi-00)
5. (NFD on OpenWrt Home Router)[https://www.slideshare.net/yoursunny/nfd-luci]
6. (RFC 3259: A Message Bus for Local Coordination)[https://www.rfc-editor.org/rfc/rfc3259.html]