How I Put a Temperature Sensor on the NDN Testbed

The frontpage of my recently renovated website shows a room temperature reading of my apartment. This is not your average IoT project, but a showcase of how an IoT device can communicate directly over Named Data Networking (NDN). This article explains where does this temperature reading come from, how is it turned into NDN Data packets, how the sensor appears on the NDN testbed, and how the temperature reading shows up on the website.

room temperature display on yoursunny.com frontpage

Sensor Hardware

If you have been reading my posts, you may have guessed that the temperature reading comes from an ESP8266. Of course! It is actually my very first ESP8266, which I received from Losant IoT Inc. It comes with a TMP36 analog temperature sensor, and has been reporting my room temperature to Losant platform since May 2016.

Losant Builder Kit with all the additions

How HomeCam Registers NDN Prefixes?

HomeCam, a browser-based home surveillance camera, is one of my major side projects during the past few years. My last post gave an overview on the overall architecture and various components of HomeCam. I mentioned that HomeCam delivers pictures via Named Data Networking (NDN), which provides better scalability because the camera only needs to serve each picture once even if there are multiple viewers, and the network takes care of the distribution.

Both HomeCam viewers and cameras connect to the global NDN testbed network via WebSockets. A viewer sends Interests to the network to request a picture from a specific camera identified by part of the Interest name. The network forwards the Interests to the named camera, and the camera responds with Data packets that contain the picture. But how does the network know where the camera is?

The camera must register its prefix onto the NDN testbed network.

For a regular end host running the NDN Forwarding Daemon (NFD), you may let the world reach your NFD via auto prefix propagation. This procedure involves sending a prefix registration command to the network, which causes the router to add a route toward the end host. A requirement is that the prefix registration command must be signed by a key trusted by the network.

HomeCam camera is a browser-based application that directly connects to a testbed router, and there is no NFD running local to do auto prefix propagation for us. However, HomeCam can still have a route added toward the camera by sending a prefix registration command.

How HomeCam Works?

HomeCam, a browser-based home surveillance camera, is one of my major side projects during the past few years. HomeCam allows you to capture pictures via the webcam on a laptop or smartphone, and view real-time images from a different device. No specialized hardware or software installation is needed: HomeCam works directly in a web browser. This article gives an overview of the web technologies that enable HomeCam.

If you have not used HomeCam, try it today!

Functionality Review and General Workflow

The HomeCam web app can operate in either viewer or camera mode. To enter either mode, the user is required to specify a "camera name", which serves as an identifier. Each camera should have a distinct camera name. Any number of viewers can be active at the same time, and they will retrieve real-time pictures from the camera with the same camera name.

Under the hoods, this works in three steps:

ndnping Jewelry on ESP8266

I was wearing a unique piece of jewelry at NDN community meeting, Mar 2017: a pair of ESP8266 units that communicate with each other over the NDN testbed. They are ugly, but it is a nice way to demonstrate my creation in a Named Data Networking community meeting.

Two Witty Cloud boards are tied to my wrists, and powered by a USB powerbank in my pocket. One of them runs a ndnping client, and the other runs a ndnping server. The client sends Interests to a router in Arizona, the Interests (under a multicast prefix) are flooded through the testbed, and reach the server which is connected to a router in Memphis.

Arduino Code

Library: esp8266ndn

Issue Your Own NDN Certificates

To publish contents into a Named Data Networking (NDN) backbone network, you need to connect your NFD end host to the NDN Testbed, run a local producer application, and let the world reach your NFD through Automatic Prefix Propagation. However, a limitation with NDN Forwarding Daemon (NFD)'s Automatic Prefix Propagation is that, the prefix registered toward your end host is always the identity name of your certificate. While this works fine when you only have one or two machines, two problems arise when you want to deploy multiple end hosts:

  • Every certificate request needs an email verification and manual approval process, which is inconvenient. Or, you can copy your certificate and private key onto every machine, but in case any of these machines is compromised, your one and only private key will be exposed.
  • Certificates requested with the same email address have the same "identity name" and hence Automatic Prefix Propagation would register the same prefix. Unless all your machines serve the same contents, registering the same prefix toward all machines hurts network performance because the router has to rely on flooding and probing to figure out which of your machines serves a certain piece of content.

The solution is to issue your own NDN certificates, and let the world trust them.

The Hierarchical Trust Model

In cryptography, two trust models are widely used:

Let the World Reach Your NFD

Named Data Networking (NDN) is a potential future Internet architecture designed as a distribution network. My last post described how to connect an end host running NDN Forwarding Daemon (NFD) to the NDN Testbed, a backbone NDN network for research purposes, and retrieve contents from that network. An equally important topic is: how can you publish contents into the backbone network?

As mentioned in the last post, NDN communication is receiver driven. Interests expressed by the consumer application are forwarded toward the producer following the routing table, and Data packets carrying contents flow back on the reverse path of Interests. Every end host and router along the path between consumer and producer needs to have a route in its routing table, so that NFD can forward the Interest, hop by hop, toward the producer. On your own machine, nfdc register command adds a route to the routing table; however, if you want to publish contents into the backbone network and make them available for others to retrieve, you won't be able to directly execute nfdc register command on a terminal of the routers. How can you add a route without console access?

Prefix Registration Protocol

Before I talk about how to add a route onto a router, let's have a look at how nfdc register works under the hood. nfdc register implements NFD Management Protocol. When you execute nfdc register /A udp4://192.0.2.1:6363, the program connects to the local NFD instance via a Unix socket, and sends a command to instruct NFD to add a route for /A prefix toward the specified UDP tunnel. The command is encoded as an NDN Interest. All the parameters you entered on the command line are encoded into the name of this Interest. The name also contains a timestamp to prevent a command being processed twice, and a signature which identifies who is sending the command. When NFD receives this Interest, it dispatches the Interest to the management module, which would check the signature and the timestamp, and then decode and execute the command. If everything goes well, the management module generates a successful response as a Data packet, which goes back to nfdc register program and gets displayed on your terminal.

Since the prefix registration command is actually an Interest, you could manually construct the Interest and send it to NFD via a Unix socket, and NFD would execute it indiscriminately, as long as you get the syntax right.

Get NFD Connected

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.

Before going further, ensure NFD is started on both local and remote machines:

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.

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.