Get NFD Connected

January 6, 2015 by CAIDA in Updates | Comments Off on Get NFD Connected

The Named Data Networking (NDN) Project offers a potential future Internet architecture designed as a distribution network.

The last post described how to deploy the NDN Forwarding Daemon (NFD) on a low-end box. This post describes how to get it connected.

The procedures and experiences in this post apply 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 ndn-tlv-ping installed. You need access to two machines with NFD running; 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 on top of a traditional IP network. You can specify the IP address and port number of the remote NFD, so that NDN packets get encapsulated into UDP or TCP packets and sent to the remote NFD.

To establish a connection, enter the following command:

nfdc create udp4://192.0.2.1:6363

In this command:

  • nfdc is the tool used to control NFD
  • create means “create a face”, where the term “face” is a generalization of the “network interface” concept
  • udp4 means “IPv4 and UDP”
  • 192.0.2.1 specifies the IP address of the remote machine; the IP address of a host running another NFD instance
  • 6363 is the port number of NFD on the remote machine; 6363, the default port number, usually does not need to change

This command establishes a tunnel from the local NFD to the remote NFD. Logically, a tunnel is similar to a VPN connection, where the two machines directly connect at the NDN network layer. A tunnel could cross many IP and Ethernet layer links, but those are invisible to the NDN software router.

To verify a tunnel is established, run nfd-status -f to see a list of active faces. In the output you should see a line with the IP address and port number of the remote NFD.

For example:

Faces:
faceid=1 remote=internal:// local=internal:// counters={in={0i 12d 0B}
out={4i 0d 0B}} local persistent point-to-point
faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d
0B} out={0i 0d 0B}} local persistent point-to-point
faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d
0B}} local persistent point-to-point
faceid=256 remote=udp4://224.0.23.170:56363
local=udp4://132.249.65.100:56363 counters={in={0i 0d 0B} out={0i 0d 0B}}
non-local persistent point-to-point
faceid=257 remote=udp4://224.0.23.170:56363
local=udp4://192.172.226.92:56363 counters={in={0i 0d 0B} out={0i 0d 0B}}
non-local persistent point-to-point
faceid=259 remote=ether://[01:00:5e:00:17:aa] local=dev://en1
counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
faceid=260 remote=ether://[01:00:5e:00:17:aa] local=dev://en0
counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
faceid=261 remote=fd://26 local=unix:///private/var/run/nfd.sock
counters={in={4i 0d 955B} out={0i 4d 2006B}} local on-demand point-to-point
faceid=262 remote=fd://27 local=unix:///private/var/run/nfd.sock
counters={in={1i 0d 46B} out={0i 0d 0B}} local on-demand point-to-point

Send an Interest

In the NDN architecture, the receiver drives all communications. A consumer application sends an Interest packet, that indicates the content it wants to retrieve; the Interest packet contains a Name to specify the content wanted, but does not specify from where it comes. The network figures out from where to retreive the content; the Interest packet is forwarded to the producer application, which provides the content. The producer application replies with a Data packet that contains the content wanted by the consumer; the Data packet contains the same Name as the Interest (or more precisely, the Data Name could have a longer Name, but it must have the Interest Name as its prefix). The network then delivers the Data packet back to the consumer by matching the Name and using forwarding states.

To send an interest, issue the command:

ndnping -c 1 /A

In this command:

  • ndnping is the tool to test NDN reachability, to send Interests
  • -c 1 sends one Interest only
  • /A is the prefix of Interest(s)

This command would send an Interest with Name /A/ping/<random-number>. However, most likely the response would be “Timeout” because after the command sends the Interest, the local NFD cannot determine where to retreive the content with this Name. So, it would drop the packet.

For example:

$ ndnping -c 1 /A

=== Pinging /A ===

Timeout From /A – Ping Reference = 1867360662

=== Ping Statistics For /A ===
Sent=1, Received=0, Packet Loss=100%, Total Time=0 ms

To tell the local NFD where the content resides requires an entry in the routing table. To add an entry (aka a route) to the routing table, type this command:

nfdc register /A udp4://192.0.2.1:6363

In this command:

  • nfdc is the tool for NFD control
  • register means “register a route”
  • /A is the Name prefix that tells NFD about contents with this Name prefix available on the remote NFD
  • udp4://192.0.2.1:6363 describes the overlay protocol, IP address, and port number of the remote NFD; you must change this to reflect the IP address and port number where another NFD instance is running

For example:

$ nfdc register /A udp4://192.0.2.1:6363
Successful in name registration: ControlParameters(Name: /A, FaceId: 263,
Origin: 255, Cost: 0, Flags: 1, )

To verify a route is added, run nfd-status -r to see the routing table. You should see a line with the Name prefix /A.

For example:

$ nfd-status -r
RIB:
/A route={faceid=263 (origin=255 cost=0 ChildInherit)}

After adding the route, run ndnping -c 1 /A again, and the Interest will go to the remote NFD. The response is most likely still “Timeout”, but you can confirm an Interest indeed went out by observing traffic with Wireshark or tcpdump.

For example:

$ ndnping -c 1 /A

=== Pinging /A ===

Timeout From /A – Ping Reference = 1876520477

=== Ping Statistics For /A ===
Sent=1, Received=0, Packet Loss=100%, Total Time=0 ms

Complete the Communication

So, the Interest went out to the remote NFD, but why does ndnping -c 1 /A return “Timeout”? This happens because the remote NFD doesn’t know where to retreive the content.

To have a successful NDN communication requires two applications: a consumer that sends Interest packets, and a producer that replies with Data packets to satisfy those Interests. We already have ndnping as a consumer, but we are missing a producer to provide the contents.

To run a producer, log on to the remote machine, and type this command:

ndnpingserver /A

In this command:

  • ndnpingserver is the tool for testing NDN reachability that runs on the server side and acts as a producer that accepts Interests from
    ndnping and responds with Data packets
  • /A the Name prefix for the contents provided by this producer

This command will not return immediately. Instead, it runs as a daemon and waits for incoming Interests to which to respond. Don’t close the terminal in which you run this command.

For example:

$ ndnpingserver /A

=== Ping Server /A ===

Interest Received – Ping Reference = 1879209597

Go back to the local machine, and run ndnping -c 1 /A again. If configured correctly, the output should say “Content” with a round trip time measurement. Voila!

For example:

$ ndnping -c 1 /A

=== Pinging /A ===

Content From /A – Ping Reference = 1879209597 – Round Trip Time = 50.233
ms

=== Ping Statistics For /A ===
Sent=1, Received=1, Packet Loss=0%, Total Time=50.233 ms
Round Trip Time (Min/Max/Avg/MDev) = (50.233/50.233/50.233/0) ms

If it still returns “Timeout”, try executing ndnping -c 1 /A on another terminal of the remote machine; if it also returns “Timeout”, check whether ndnpingserver /A is still running. Also type nfd-status -r on the local machine to inspect the routing table, and execute nfdc register /A udp4://192.0.2.1:6363 if the route has disappeared.

Connect to the NDN Testbed

The NDN Testbed provides a backbone network with software routers in North America, Europe, and Asia. The NDN Testbed is a shared resource created for research purposes; joining the testbed requires an intention of productive research.

Connecting to a backbone router in the NDN Testbed is no different from connecting to any other machine. The following command connects you to a router:

nfdc register /ndn udp4://spurs.cs.ucla.edu

For example:

$ nfdc register /ndn udp4://spurs.cs.ucla.edu
Successful in name registration: ControlParameters(Name: /ndn, FaceId: 271,
Origin: 255, Cost: 0, Flags: 1, )

Now you can retrieve any content from the network, such as:

ndnping /ndn/edu/arizona

This command executes the NDN reachability test tool that measures the round trip time between you and the Arizona router.

For example:

$ ndnping /ndn/edu/arizona

=== Pinging /ndn/edu/arizona ===

Content From /ndn/edu/arizona – Ping Reference = 1882016366 – Round Trip
Time = 67.209 ms
Content From /ndn/edu/arizona – Ping Reference = 1882016367 – Round Trip
Time = 31.416 ms
Content From /ndn/edu/arizona – Ping Reference = 1882016368 – Round Trip
Time = 31.044 ms
Content From /ndn/edu/arizona – Ping Reference = 1882016369 – Round Trip
Time = 31.786 ms
Content From /ndn/edu/arizona – Ping Reference = 1882016370 – Round Trip
Time = 33.343 ms
^C

=== Ping Statistics For /ndn/edu/arizona ===
Sent=5, Received=5, Packet Loss=0%, Total Time=194.798 ms
Round Trip Time (Min/Max/Avg/MDev) = (31.044/67.209/38.9596/14.1464) ms

Next Steps

If you correctly installed, configured and executed the commands on this page, you connected your local NFD to another NFD instance running on a remote machine, and successfully retrieved content across this two-node network. You also connected your local NFD to the NDN Testbed, a backbone NDN network, and retrieved some content from the NDN Testbed.

The next step is to allow others on the backbone network to reach you. We will cover this topic in a future post.

Originally posted 2014-10-19 by Junxiao Shi. ©2015 yoursunny.com

Social tagging: > > > > > > > > > > > > > > > > > > > > > > >