[Ndn-interest] Local hub discovery procedure

Alex Afanasyev aa at CS.UCLA.EDU
Tue Feb 16 11:10:51 PST 2016


Hi Sabet,

Let me try to answer your questions.

1/ How ndn-autoconfig-server receives interests

ndn-autoconfig-server registers with the local NFD two prefixes: /localhop/ndn-autoconf/hub and /localhop/nfd/rib/routable-prefixes.  This means that whenever local NFD receives interests for data name with this prefix, this interests (unless satisfied by cache) will be demultiplexed to the ndn-autoconfig-server process.

Note that it does not matter at all how (on which face) such interests got into the local NFD.  It is job of remote NFDs to properly forward interests.  Or, saying in different way, /localhop/ndn-autoconf/hub should be registered to multicast faces only at the remote NFD.

While it is kind of pointless to run autoconfig-client and autoconfig-server on the same machine, it is a legitimate operations:

--
✔  10:42 ~ $ ndn-autoconfig-server -p /hello tcp://spurs.cs.ucla.edu
--
✔  10:42 ~ $ ndn-autoconfig
Trying multicast discovery...
About to connect to: tcp4://131.179.196.46:6363
Successfully created face: ControlParameters(FaceId: 267, Uri: tcp4://131.179.196.46:6363, )
Successful in name registration: ControlParameters(Name: /ndn, FaceId: 267, Origin: 66, Cost: 100, Flags: 1, ExpirationPeriod: 9223372036854775807 milliseconds, )
Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId: 267, Origin: 66, Cost: 100, Flags: 1, ExpirationPeriod: 9223372036854775807 milliseconds, )
--

What happens is that ndn-autoconfig sends an interest, which (in addition to be forwarded out) is immediately dispatched to the local ndn-autoconfig-server, which replies with information about hub URI.

2/ Poking /localhop/nfd/rib/routable-prefixes

If you (application) sends interest for /localhop/nfd/rib/routable-prefixes, it will receive a list of (configured) prefixes that are globally routable towards the hub (= announced in the routing system).  The list does not immediately imply that the application can directly publish under any of those prefixes.

3/ Choosing prefix from /localhop/nfd/rib/routable-prefixes data

There isn't a single answer to this question.  It depends on the use case.

To publish under a name prefix, application should hold a valid key for that namespace.  While the generalization of obtaining keys is an ongoing research and engineering effort, we have developed a few cases of (semi-)automated process.  One of them is ndncert system (http://ndncert.named-data.net/).  There is also an mHealth application specific certification system that has more automation built in.

Therefore, one way to choose prefix is to check whether there is a corresponding certificate and private key for the presented namespace.  Another way would be to pick any of the prefixes and invoke (currently undefined) procedure of obtaining certification for a sub-namespace of the selected prefix.

There is also a third answer to this question: don't pick, but take all of them.  This is the use case of forwarding using LINK objects (http://named-data.net/publications/snamp-ndn-scalability/):  an application registers its own prefix, while notifying others explicitly or via a mapping system that to retrieve data one needs to use a specific LINK object containing one or more delegations (aka globally reachable prefixes).   Note that the presumption that the application needs to have certificate and key still stays.  The difference is in namespaces: application-specific namespace vs. namespace(s) provided by the point-of-attachment NDN hub.

4/ Mechanism between app and router

Just to clear up the picture.  There are two routers in it: one local NFD and zero or many remote NFDs.

Between application and local NFD, we have RIB management protocol: http://redmine.named-data.net/projects/nfd/wiki/FibMgmt.  This enables local NFD to demultiplex incoming interests to the application.

Between local NFD and remote NFD(s).  Currently, we have designed and implemented two mechanisms: routing protocol (NLSR) and automatic prefix propagation (there is an unpublished draft with detailed description that we will make available soon).

With the routing protocol, local NFD makes announcements to the routing system.  The current limitation is that the announced prefixes need to be manually configured.  They may be injected to the routing based on local registrations, though there are several research and engineering questions how exactly it should be done.

Automatic prefix propagation is a simplistic routing-like protocol that applicable in home network-like scenarios (NFD on NDN hub <---> local NFD <---> application).  When properly configured with certificates, the RIB registration from application to local NFD will be automatically "propagated" towards NDN hub.

---
Alex

> On Feb 16, 2016, at 6:06 AM, Muhammad Hosain Abdollahi Sabet <M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
> 
> Update!
> 
> In 2nd email, answer to 3rd question is yes. Although I still wonder how autoconfig-server supposed to be found natively, having manually created a face to autoconfig-server and registered /localhop/ on it I could run autoconfig. And I got answer(a data packet consisting of an available prefix).
> 
> Questions in 3rd email remains unanswered.
> 
> Thanks,
> Sabet
> 
> -----Original Message-----
> From: Ndn-interest on behalf of Muhammad Hosain Abdollahi Sabet
> Sent: Sun 2/14/2016 12:15 PM
> To: Alex Afanasyev
> Cc: ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Local hub discovery procedure
> 
> Hi again,
> 
> Additional to questions below, I have some others:
> How an application is going to choose one prefix? I mean, is there any specefic message the application should send through NFD to autoconfig server, so that the server knows which prefix(es) is(are) allocated and not available anymore? Is there a mechanism for applications to release the prefix(es) they were using for publishing data?
> How a router is supposed to know the location of optained prefixes in a LAN? Is there any mechanism available between a autoconfig server and a router or an application and a router to announce obtained prefixes to the router?
> 
> Thanks,
> Sabet
> 
> ________________________________
> 
> From: Ndn-interest on behalf of Muhammad Hosain Abdollahi Sabet
> Sent: Sat 2/13/2016 1:30 AM
> To: Alex Afanasyev
> Cc: ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Local hub discovery procedure
> 
> 
> 
> Alex,
> 
> Firstly, thank you so much.
> Secondly, how is auto-configure-server supposed to work then? This server should somehow receive interests for /localhop/ndn-autoconf/hub. While it's face uri is not on multiaccess faces list, I don't see how it is supposed to work. Actually I tested this. I mean I tried autoconfig-client side on a node which was configured for being autoconfig-server, and needless to say that I got error code 408. Am I to run some multicast capability in my home network to be able to use autoconfig client-server system?
> Third, assuming the above issues have passed, if I poke for /localhop/nfd/rib/routable-prefixes, I(an application) should receive available prefix(es) for publishing data, right?
> 
> Thanks,
> Sabet
> 
> -----Original Message-----
> From: Alex Afanasyev [mailto:aa at cs.ucla.edu]
> Sent: Sat 2/13/2016 1:05 AM
> To: Muhammad Hosain Abdollahi Sabet
> Cc: ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Local hub discovery procedure
> 
> 
> > On Feb 12, 2016, at 9:35 AM, Muhammad Hosain Abdollahi Sabet <M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
> >
> > Hello everyone,
> >
> > As far as I understood, according to:
> > http://named-data.net/doc/NFD/current/misc/local-prefix-discovery.html <http://named-data.net/doc/NFD/current/misc/local-prefix-discovery.html>
> > http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig.htm <http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig.htm>
> >
> > When I run ndn-autoconfig, NFD will send an interest to /localhop/ndn-autoconf/hub over a multicast face. After that assuming there is some autoconfig server behind one of the node's multiaccess faces, the node receives a data packet including the face uri of a localhub.
> >
> Dear Sabet,
> 
> The above correctly describes the basic NDN-native procedure.  Just to extend it, as you saw in the documentation, there are two additional stages to help with configuring IP-overlay NDN connectivity.  While not yet formally defined, we are also planning to extend the stages to include discovery using mDNS/DNS-SD protocols (http://redmine.named-data.net/issues/3465 <http://redmine.named-data.net/issues/3465>).  Anecdotally, mDNS queries have higher chances to work than other protocols, even though they utilize the same IP multicast.
> > Then after registering /localhop/ prefix on the very face that it has got from the localhub, the node will again send an interest this time for /localhop/nfd/rib/routable-prefixes and awaits for a data packet including some prefixes which it(interest sender application) can register for publishing data.
> >
> Correct, but just to clarify.  As of right now, "node" in this sentence is any NDN application that wants to obtain information about routable prefixes.  There is an extension of this mechanism (http://redmine.named-data.net/issues/3145 <http://redmine.named-data.net/issues/3145>) in which local NFD will be expressing such interests.
> > If I'm wrong some where, please correct me.
> >
> > Right now I have these two multiaccess faces:
> > -udp4://224.0.23.170:56363
> > -ether://[01:00:5e:00:17:aa]
> > I know the former is IANA assigned, but I don't know the latter. My question are:
> > 1- The reason my machine's NFD is not receiving anything form 224.0.23.170 is that this IP is not globally routable, and I don't have any autoconfig server in my local network having this IP and being up and running. Right?
> >
> 224.0.23.170 is a multicast IP address and how far interests sent over such face will propagate depends on your networking environment (e.g., whether or not your WiFI access point allows multicast, whether you're running multicast routing protocol on your routers, etc.).
> 
> The shorter answer to your question is most likely yes.  Not getting any reply most likely mean that you don't have NFD and associated autoconfig server running in your local network.
> > 2- What is the second one? I've checked my host machine's virtual NICs(NFD is on a VM). It's not any of their MACs.
> >
> This is a multicast Ethernet address.  It is not yet assigned, but it is effectively a mapping of 224.0.23.170 to ethernet address range (https://technet.microsoft.com/en-us/library/cc957928.aspx <https://technet.microsoft.com/en-us/library/cc957928.aspx>).
> 
> Sincerely,
> Alex
> 
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160216/dc9f511b/attachment.bin>


More information about the Ndn-interest mailing list