Get NFD Connected

UPDATE 2021-06-01: nfdc command syntax changed since NFD 0.6.0. This article has been updated to include the new syntax.

Named Data Networking (NDN) is a potential future Internet architecture designed as a distribution network. My last post described how to deploy NDN Forwarding Daemon (NFD) on a low end box. Now it's time to get it connected.

The procedures and experiences in this post are applicable to any NDN node. If you aren't using a low end box, you may follow the official guide to install binary packages or compile from source. This post assumes you have ndn-cxx, nfd, and ndnping installed. You need access to two machines with NFD running; they are referred to as "local" and "remote".

Connect to Another Machine

After installing NFD on your machine, you can connect to any other machine running NFD. Although NDN can run natively above Ethernet, there isn't a global scale native NDN network yet because NDN is still in its early stage. Instead, NDN can run as an overlay network above traditional IP network. You can specify the IP address and port number of the remote NFD, so that NDN packets are encapsulated into UDP or TCP packets and sent to the remote NFD.

Deploy NDN Forwarding Daemon in Low End Box

Named Data Networking (NDN) is a future Internet architecture designed as a distribution network. To access NDN network from a Linux or OSX machine, one can install NDN Platform, a collection of software packages including the protocol stack and critical applications. NDN Forwarding Daemon (NFD), a core component of the architecture, serves as a software router and runs both on network routers as well as on end hosts to communicate with routers.

NDN Platform has new version releases periodically, and binary packages are provided with each platform release. However, the development of NDN software, including NFD, happens much faster than platform releases. If one wants to run bleeding edge software, those packages must be built from source code available on GitHub.

As a geeky low end box user, I'm thinking: can I run NDN platform on a Linux box with a small amount of memory? The box I'm talking about is an OpenVZ container from LowEndSpirit UK location, with only 128MB memory and no swap space. To make the challenge more interesting, I want to avoid apt-get, and run bleeding edge version built from source code.

Building on the Box

I quickly installed compilers and dependencies (such as libboost-all-dev which takes several minutes to download) with apt-get, and cloned the git repositories for NFD and other essential NDN Platform packages. Given that the box has small memory and slow CPU, I can expect the compilation process to take a few hours, just like 8 years ago when I was compiling Apache on a library computer.

Faster Content Distribution with Content Addressable NDN Repository

The effectiveness of universal caching in Named Data Networking depends on data naming. NDN routers cannot identify duplicate contents published under different Names. This paper proposes an enhancement to NDN repository so that duplicate contents could be identified by their hash, in order to save bandwidth and shorten download completion time. The repository indexes Data packets not only by Name, but also by hash of payload. Client applications could retrieve chunks by hash from a nearby neighbor. Therefore, the same payload does not have to traverse the Internet twice. Our evaluation shows that total download time for two Linux Mint disc images is reduced by up to 38%.

Download full report as PDF
Browse code repository

How do I deploy my website on NDN?

As a website owner, I'm always thinking about making my website available on more channels, so I enabled IPv6 several years ago. NDN comes to my eye as a new "content distribute model" and "communicate protocol". It's natural for me to think about: how do I deploy my website on NDN?

Like most small websites, my website runs mainly on HTTP. Visitors issue GET requests to retrieve pages and resources, which is essentially static but may change at any time. They issue POST requests to interact with web applications, or play with JavaScript-based web applications. I used to provide file downloading through FTP or BitTorrent (but it's now on SkyDrive). I'm collecting statistics with Google Analysis, and an accurate report is important to me. To sum up, I have 5 scenarios:

  1. retrieve pages and resources;
  2. server-based web applications;
  3. JavaScript-based web application;
  4. file downloading;
  5. analysis.

File downloading is the easiest one on NDN. Once a file is published, I would not modify it without using a new name. So, publishing files under a NDN prefix is sufficient. By adding a segmentation component in data names, visitors can download a piece of a file, which is similar to BitTorrent.

Retrieving pages and resources is similar to file downloading, except that pages may change at any time. I don't know when a page will change, so I cannot specify an expiry time when the page was served. In HTTP, user agents can include a If-Modified-Since header, and server would respond with 304 status code if page is not modified without sending the content. In NDN, I can add a version component in data names, so user agents can INTEREST locally-cached version number with RightmostRightSibling annotation.