[Nfd-dev] The way of updating routers' FIB after handover

[Junxiao Shi]

Hi Bmohammadi

The short term plan for the NDN testbed is to *readvertise a mobile
producer's route into the global routing system*.

   1. The mobile producer application, e.g. ndnpingserver, registers its
   prefix onto the local NFD on the mobile node.
   2. NFD on the mobile node readvertises the producer's prefix to the
   connected router, so that the connected testbed router has a route toward
   the mobile node for this prefix. This step is formerly known as "automatic
   prefix propagation" and is implemented as such.
   3. NFD on the router readvertises the producer's prefix into the global
   routing system (NLSR), so that everyone in the world knows the mobile
   producer is reachable via this router. This feature is designed in
   https://redmine.named-data.net/issues/3784
   <https://redmine.named-data.net/issues/3784> and to be implemented in
   https://redmine.named-data.net/issues/3818
   <https://redmine.named-data.net/issues/3818> .

They will be routing scalability issue when there are many mobile nodes
advertising their prefixes, but we are not there yet.

Yours, Junxiao

On Mon, Jan 2, 2017 at 5:41 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>
> Dear Dr. Zhang,
>
> Thank you very much for your kind response. I have read the paper you
> mentioned but in that paper mobility in "pure NDN" has not been
> investigated.
>
> By "pure NDN", do you mean the use of a routing protocol to support mobile
> producers?
>
> Actually in addition to other solutions I want to compare my approach with
> "pure NDN", but I do not know the way of updating routers' FIB when a
> producer changes it's Point of Attachment.
>
> If one wants to use routing protocol to reflect a producer's connectivity
>  change from one NDN router R1 to another one R2, I think 2 actions are
> needed:
> 1/ de-register the producer's prefix from R1, and
>
This action is implicitly: when R1's face toward the mobile node fails,
NFD-RIB deletes the route, which in turn causes the readvertise module to
withdraw the route from the global routing system.


> 2/ register the prefix with R2.
>
This action is performed using the three steps above.


>
> We meant to make a TR to describe remote prefix registration but haven't
> got there.  There is a slide deck on the topic
> https://redmine.named-data.net/attachments/download/168/remo
> te%20prefix%20registeration-draft2.ppt
> but I dont know whether that still represents the latest implementation.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170103/1b66a119/attachment.html>