[Nfd-dev] [EXT] Re: NDN-Lite on Contiki NG

[Junxiao Shi]

Hi Alper

On Fri, Apr 4, 2025 at 3:40 PM Alper Kamil Demir <akdemir at atu.edu.tr> wrote:

>
>> The NDN-Lite codebase appears to have been abandoned, as it has not been
>> updated since 2021.
>>
>
> Yep. I know about this. Lixia told me that we can allocate some manpower
> for it. We have developed our codebase, but it is far away from NDN
> concepts totally. AFAIK, there is not any other codebase. That's why we
> prefer to use the NDN-Lite codebase. If there is a more recent codebase, I
> appreciate it if it is shared with us.(I got the answer below: NDND)
>

I also have these in C++ / Arduino platform:
https://github.com/yoursunny/NDNph
https://github.com/yoursunny/esp8266ndn
https://github.com/usnistgov/PION

They should still work and they are compatible with most other NDN
implementations, but I'm not planning on further development on them.

   - The codebase is constrained by needing to support C++11 for the
   nRF52832 port, which is now an outdated standard.
   - The arena memory manager at the core of NDNph codebase was improperly
   designed due to my lack of experience, which makes it difficult to add new
   features.
   - It's difficult to implement StateVectorSync with only statically
   allocated memory.
   - It's difficult to implement certificate retrieval with only statically
   allocated memory. There would be no LightVerSec if certificate retrieval
   cannot be implemented.


We chose Contiki NG OS because we have some know-how about it. We know it
> is easily ported to POSIX (i.e. RIOT) At least, we want to give it a shot.
> I am also curious if I can manage to integrate it for the NDNComm 2025
> Hackathon.
> We also plan to use it with RIOT.
>

If you are only using the software in POSIX on a computer, you may as well
use NDNd or other codebase designed for the computer.
There is "zero or negative" value in porting software to an "IoT platform"
that is only tested on the computer.

It only gets interesting when the software goes into an actual
microcontroller, where the RAM is highly constrained.
So, which microcontroller are you targeting?
What are the capabilities and constraints of this microcontroller?
Does the TinyGo compiler for this microcontroller?

For the NDNph + esp8266ndn + PION combination I mentioned above, they were
developed and tested on three microcontrollers: ESP8266, ESP32, nRF52832.
Note that Raspberry Pi and similar devices that run full Linux
distributions are not considered "IoT devices", but are full computers.

It is not interoperable with any other NDN codebase due to the usage of a
>> different fragmentation protocol (see
>> https://redmine.named-data.net/issues/4814
>> <https://redmine.named-data.net/issues/4814>
>> ).
>>
>
> Possibly, there will also be issues in the future versions. I question if
> we can design a perfect one at all. We want to start from somewhere, and
> NDN-Lite sounds like a good one and only candidate AFAIK. (I'll check NDND)
> We planned to integrate NDN-Lite to Contiki OS because both are in C. There
> might be ways to connect C and Go, but It will require more expertise I
> assume.
>

The Go programming language contains CGo, which connects C and Go.
It's supported by both Go compiler and TinyGo compiler.
Note that this is only for C code, but not C++, D, Zig, etc.

It also lacks a data synchronization protocol such as StateVectorSync,
>> which is believed to be an essential functionality needed by many NDN
>> applications.
>>
>
> I do not know about StateVectorSync. I'll check it. Thank you for
> addressing me. Do you think that it is a MUST for NDNoT?;
>

Data synchronization protocol and schematized trust are considered
essential for NDN IoT.
See "Trust schemas and ICN: key to secure home IoT" by Pollere Inc:
https://pollere.net/talks.html


>
>> Moreover, NDN-Lite has been moving away from its roots in small IoT
>> devices.
>> The ndn-iot-package-over-nordic-sdk
>> <https://github.com/named-data-iot/ndn-iot-package-over-nordic-sdk> repository,
>> last updated in 2019, is the only port of NDN-Lite that can run on a
>> microcontroller.
>> New additions in the main NDN-Lite repository have not been tested on a
>> microcontroller, and I have noticed that they may consume a
>> substantial amount of RAM.
>>
>
> We can consider these issues into our agenda. I need to find manpower for
> them.
>
>
>>
>> Therefore, I believe that trying to port NDN-Lite to another
>> platform would be wasted effort, unless the above issues are addressed
>> first.
>>
>
> AFAIK, your "Sovereign: Self-Contained Smart Home With Data-Centric
> Network and Security" uses NDN-Lite. As I see it, it was for a small-scale
> NDNoT environment.
>
>
>>
>> Nowadays most of the new developments are in ndnd
>> <https://github.com/named-data/ndnd>,
>> a codebase written in Go.
>>
>
> Thank you for sharing NDND with me. I did not know about it. I'll check
> it. Lixia is giving me a lot of homeworks that I am trying to catch up with
> (Just kidding.) It's good. I'm learning. I am doing my best to find
> manpower. However, everyone is going after AI/ML/DL nowadays. I am trying
> to make  AI+Network attractive as much as I can. People should understand
> that AI+Network is a much more unexplored area. Another tech is Quantum.
> Maybe we should put some Quantum Internet, Quantum NDN into our agenda. +
> always security.
>

Do you have expertise in quantum networking?


> It is interoperable with most other NDN systems and supports recent
>> protocols like StateVectorSync and LightVecSec.
>> Using the TinyGo compiler, a Go program may be compiled to run on dozens
>> of microcontrollers.
>> If you are interested in running NDN applications in IoT devices, I'd
>> suggest trying to compile portions of ndnd with the TinyGo compiler.
>>
>
> This information is invaluable to me.Definitely, I'll start learning about
> it ASAP. Just a naive question: what are the differences between NDND
> and NFD other than having different programming languages? Why NDND?
>

We are hoping this question would be answered in the NDNd presentation at
the upcoming NDN Community Meeting.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20250404/aa022578/attachment.htm>