Movatterモバイル変換

September 26, 2014byCAIDA inUpdates |Comments Off on How to Deploy the NDN Forwarding Daemon on a Low-End Box

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

The NDN team provides periodic releases of the new platform, and binary packages are provided with each platform release. However, the development of NDN software, including NFD, happens much faster than platform releases, so users can download source code fromGitHub. If a user wants to run bleeding edge software, those packages must be built from source code.

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

Building the source code on the Low End Box

I quickly installed compilers and dependencies (such aslibboost-all-dev which takes several minutes to download) withapt-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.

The wait does not take too long: the build process ends after a few seconds, because it doesn’t work at all.ndn-cxx and NFD cannot build with only 128MB memory. You need2GB memory of memory to build them from source. I can guess one reason is the extensive usage of Boost.Asio which involves lots of C++ templates, and gcc cannot handle all those identifiers within 128MB memory.

Cross-Compiling

Cross-compiling is a technique often used to build software for an embedded device with limited resources. For example, Android applications are not compiled on Android phones; instead, they are typically built on more powerful computers, and then loaded into the phones.

I can use the same technique to build NFD for the low end box:find a machine with more memory, and copy the binaries into the box. Except that, it’s unnecessary tocross-compile, because the box is x86 architecture, and it’s easy to find another machine with x86 architecture.

So, I provisioned an x86 virtual machine with 2GB memory on a powerful server.This machine must have the same operating system as the target box, and dependencies should have the same version.apt-get can keep the dependencies up to date. This means, each time I run a system update, I’d run it on both machines.

Now it follows the regular build process. I turned off all debugging options, because I don’t expect any useful debugging in 128MB memory.

Installation

Copying the binaries into the box turns out to be easy: Waf build system has a--destdir option which allows me to specify where to install the binaries. The default is/ so that binaries are installed to the local machine.

All I need to do is tomount the root directory of the target box viasshfs, and specify
--destdir=/target. Alternatively, I can ask Waf to install into an empty directory, and then copy the contents onto the target box.

This process works. There’s still a problem: the binaries are huge, because they still contain some sort of debugging symbols. The solution is: runstrip on each binary, after they are built but before installation.

Configuration

Hopefully NFD is up and running on the low end box now.

The default configuration comes optimized for a host with 1GB of memory and it keeps 500MB worth of packets in the cache. I don’t have 500MB of memory, so I lowered thetables.cs_max_packets configuration option.

Next Steps

Finally we have the software router running on the low end box. The next step would be to connect it to other routers, such as theNDN Testbed. I’ll cover this topic in the future.