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

[Dirk Kutscher <[e-mail]>]

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](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]