[Nfd-dev] The way of updating routers' FIB after handover
Junxiao Shi
shijunxiao at email.arizona.edu
Tue Jan 3 07:43:57 PST 2017
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>
More information about the Nfd-dev
mailing list