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

Dirk Kutscher <> Thu, 21 July 2022 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90330C14CF18 for <>; Thu, 21 Jul 2022 01:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XNLI2YL0f9jG for <>; Thu, 21 Jul 2022 01:07:15 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 73865C14F735 for <>; Thu, 21 Jul 2022 01:07:14 -0700 (PDT)
Received: from [] ([]) by (mreue107 []) with ESMTPSA (Nemesis) id 1N5n3t-1nQMoy2yL5-017CIh; Thu, 21 Jul 2022 10:07:07 +0200
From: Dirk Kutscher <>
To: Teng Liang <>
Cc: ICNRG <>
Date: Thu, 21 Jul 2022 10:07:05 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_DFF070BE-DDC9-4444-A810-0A20694DF4DF_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:dTlYMk9WBTLKed9PWKitt/gQP2Uk30szIB0NvFY+jO1nT9RwcNb irDX8v1X/3o0x8nKcjHIzjabh/rE8eNGT/tgM/aoXSrdveezw5EigdjlzgZMZN8DxaRLzsL snEUwYlRrGdTIiAFC3DpB6AeehKm7NoZZSOlPmGAd+VVxIRWOgTOk4nja1RAgnA3tpnKVpy cVZrsMpNLIJq/DTQRiUEQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:JqZZNMxFflE=:66LzpuC8RgeCsGd5/ZdjCB EmpIzL4jXb7ZFFEj5BcqeP78UB0TqAz3SI94wNOfcWgFIi8WSYv13MkhTgz3Y439zUCmRNVDV 3A3nH3PTxwetCo94vv6vMjLn7KMLIPrUTHqo3z5VLqAVhmuxObEfY1UW2JlNY5qrNz7t9sJX1 O4X2HDPDqL2WWXz2HFAqIhPaL2vF/Hqamqi0dcSYpuIzRFNzDHZoTm29ovYLTgVTMgm896aMh zf20pBG1v0qCnvX4AMLDrOkVkOKEA4CIKIIexiJOG0qdQ91Yiwf2LHXU0leJTRDYJMuzHghQL f/Nd2EddUBlphQJ8s8f3b7vIlc9d0fsmVtHWAJfzlKmcljq9qxMulT+b6+dhyovRJgf4+MQO2 WGGUS8G03acR6UG1F9bXCGZo4/81QjScHGmAPkTjzcEwfyxi+6EEO7uXtrcyZ4gVXvaI3LOD4 /z4BsRDEi3COSOKnxZ2JwxhGkwW30SEk+NmLvvNWHk/Oimi5VT4A+i2O/FtkxdTB4OgufGQW4 EQ4YriAY3JBTd5LRTSVzRIC8PhDy230in8lyLfV2fvi5LNUuKGQjCBxtDTSqpmdLd8khi5wQU dIZ3HW8mPjqGBsppnGDIsrh8WKC4kQ7D/8tmbxS6A9H99yUxGxT6P84AQdTeZ23GEoYb9z5x8 y30uSE7wGSlRUfg8ByWj2lAvXgYNvmWYp7M7Nfu2X5k44XBmzkPreJX5fZz1hfyJ/NeGyVxNs jHNC6/MvKSAAPYEERZZTq+YNloveokMwD5UStA==
Archived-At: <>
Subject: Re: [icnrg] [EXT] ICN (NDN) auto-configuration and self-learning: best practices?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jul 2022 08:07:20 -0000

Hi Teng,

thanks a lot!

Best regards,

On 21 Jul 2022, at 5:59, Teng Liang wrote:

> Hi Dirk,
> Self-learning is implemented in NFD as a forwarding strategy. The current
> official version (v1) supports interest broadcast and on-demand route setup
> (i.e., add a route on data reception with prefix announcement attached).
> Self-learning v2 plans to add unicast face setup, and better interest/NACK
> handling. It is still under development, and an unofficial version can be
> found here (
> To use self-learning strategy, one can either use "nfdc strategy" command,
> or configure it in the nfd.config file, e.g., add an entry "/,
> /localhost/nfd/strategy/self-learning" in the strategy_choice (
> This tutorial in ICN'20 may be helpful:
> Best regards,
> Teng
> On Wed, Jul 20, 2022 at 10:19 PM Dirk Kutscher <> wrote:
>> Hello,
>> 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!
>> Thanks,
>> Dirk
>> References
>>    1. RONR <>
>>    2. On Broadcast-based Self-Learning in Named Data Networking
>>    <>
>>    3. What is a "Face" in Named Data Networking?
>>    <>
>>    4. NDNts API Design
>>    <>
>>    5. (NFD on OpenWrt Home Router)[
>>    6. (RFC 3259: A Message Bus for Local Coordination)[
>> External Email
>> _______________________________________________
>> icnrg mailing list