[Nfd-dev] remote prefix registration

[Junxiao Shi]

Dear folks

Please see below for a discussion about which process on the laptop should
send remote prefix registration commands.

I remember a previous NFD conference call concluded that ndn-autoconfig
tool should send such registrations.

Yours, Junxiao
Background

The NDN testbed consists of tens of dedicated router nodes that are always
online. Each router is responsible for a site prefix, such as
ndn:/ndn/edu/arizona. These routers run NLSR, a link state routing
protocol, to maintain a routing table so that every site prefix is
reachable from every router.

Currently, when a laptop (or other kind of end node) connects to a router,
the nfd-autoreg-server process on the router automatically installs a Route
of the site prefix toward the laptop. After that, it's up to the forwarding
strategy to figure out what contents could a laptop serve. For example,
every laptop connected to ARIZONA router will have a Route of prefix
ndn:/ndn/edu/arizona, and the forwarding strategy must figure out that
ndn:/ndn/edu/arizona/app1 is served by laptop1. While the forwarding
strategy SHOULD be able to find the path, it takes time and hurts
performance.

*Remote prefix registration* is a feature in NFD RIB Daemon (nrd process)
that allows a laptop to send a prefix registration command to the RIB
Daemon running on the router. This would allow laptop1 to install a Route
of prefix ndn:/ndn/edu/arizona/app1, so that the router knows to forward
Interests under this prefix to laptop1 instead of other laptops.

This feature is fully supported by NFD RIB Daemon, but it's not enabled on
NDN testbed routers.
Who should send the registration command?

A laptop can send a prefix registration command to the router, but which
process on the laptop should send the command? There are different opinions.

*ndn-autoconfig* is a tool to establish connection to a nearby testbed
router, or a user's home router (determined by the user identity). This
tool can be extended to install a Route toward the laptop on the router,
after a connection is established.
Benefit: Route is installed whenever laptop connects to testbed.
Drawback: Prefixes to be registered must be configured statically;
applications cannot dynamically request a prefix to be registered on the
router.

*nrd* is a process that handles local prefix registrations. It can be
extended to registration command to the router, if a local registration
suggests the necessity of a remote prefix registration.
Benefit: Prefixes to be registered can be controlled dynamically by
applications.
Drawback: Both nrd and applications still need to be aware of changes in
testbed connections. When a laptop moves to another router, the routable
prefix changes, and applications will have to switch to a new prefix.

*Applications* can directly send remote prefix registrations.
Drawback: This violates network layering.
Does the application need to be aware of testbed connections?

Yes.
(Until we have map-and-encap,) each testbed router has a distinct site
prefix. Application must monitor a change in the connection, and switch to
the new site prefix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141010/aad69a53/attachment.html>