Feature #3784
closed
Design readvertise
100%
Description
Design a component that readvertises a subset of locally registered routes to another NFD-RIB or routing protocol.
Files
Updated by Junxiao Shi about 8 years ago
- File readvertise_20160907.pptx readvertise_20160907.pptx added
- Status changed from New to In Progress
The original feature request is:
When an end host registers a back-route through AutoPrefixPropagation, the router can advertise the end host's prefix into a routing protocol, so that the end host is still reachable when roaming.
Of course this approach has routing scalability concern, but it can work when the number of roaming end hosts are small.
I presented the attached slides in 20160908 call.
A separate readvertise program is proposed, which receives Notifications about registered routes, filters them by origin, and sends NLSR Management commands to advertise the routes; however, this design requires implementation of a route change notification stream, and there would be latency due to the use of notification stream.
We identify that this feature can be placed into NLSR itself, which simplifies the NLSR commands part, but it still has the same problems with notification stream.
Thus, the plan is to place this feature into NFD-RIB, so that the notification stream is no longer necessary; an implication is that NLSR needs to accept prefix registration commands encoded in NFD-RIB RibMgmt protocol, to avoid NFD codebase having dependency on NLSR libraries.
I recognize a strong similarity between AutoPrefixPropagation and this backroute-to-NLSR feature: both features readvertise a subset of the routes in local RIB into somewhere else.
The differences are:
| aspect | AutoPrefixPropagation | backroute-to-NLSR |
|---|---|---|
| RIB location | end host | gateway router |
| readvertise into | gateway router | local NLSR |
| number of targets | one (with feature request for multiple) | one |
| condition before readvertising | connected to a gateway router | none (assume NLSR is always running) |
| readvertised prefix | shortest identity name (with feature requests for other choices) | (undecided) |
| command signer | identity matching readvertised prefix | NFD-RIB default identity |
| periodical refresh | yes | yes (because NLSR crash does not restart NFD) |
| retry after failure | yes | yes |
Within a single readvertise feature, the above differences can be abstracted in two places:
- The destination is configured as a command prefix. AutoPrefixPropagation uses
/localhop/nfd/rib; backroute-to-NLSR uses/localhost/nlsr/rib. "condition before readvertising" is evaluated based on whether there's a route matching the configured command prefix. - A "policy" component receives signals about route changes into local RIB, and decides readvertised prefix, command signer, and intervals for periodical refreshes and retries.
After 20160915 call, there are still concerns on high level design choices. I won't start low-level design until a consensus is reached.
Updated by Junxiao Shi about 8 years ago
After Junxiao's explanation at 20160922 call, Lan agrees with the high level design choices.
Lan proposes to rename the command verbs between NFD-RIB and NLSR to advertise and withdraw, to better reflect their semantics.
Junxiao stresses that there would be much extra work, because ndn-cxx mgmt client is designed to treat every verb as a separate protocol.
Beichuan explains that one can understand current register and unregister verbs as operating on one hop: NFD-RIB gives NLSR (over one local hop) a RIB prefix, and whether to advertise or not is NLSR's decision.
Lan reluctantly agrees to keep register and unregister verbs, in order to simplify implementation.
Lan has not given clearance on starting implementation. I won't start low-level design until then.
Updated by Junxiao Shi about 8 years ago
- % Done changed from 0 to 10
Lan has approved high-level design. I'm now working on a header.
Updated by Junxiao Shi about 8 years ago
- Description updated (diff)
- Status changed from In Progress to Resolved
- % Done changed from 10 to 70
Updated by Junxiao Shi about 8 years ago
- Blocks Feature #3818: Readvertise end-host routes into NLSR added
Updated by Nicholas Gordon about 8 years ago
As I was asked to do, I have been looking over the design for a few days now, and I understand everything well enough to begin implementing.
Updated by Junxiao Shi about 8 years ago
- Status changed from Resolved to Closed
- % Done changed from 70 to 100
Thanks for the confirmation.
Updated by Junxiao Shi almost 8 years ago
I just want to clarify my understanding of how NLSR actually will hear Readvertise commands. My understanding:
- Readvertise will send a RibRegister/RibUnregister command on the normal prefixes (e.g. /localhost/nfd) but will set the route origin to client.
- NLSR will be listening for RibRegister/RibUnregister commands on those prefixes, but will only accept those with route origin set to client.
- NLSR will add whatever prefix and route are specified by that command.
My main point of confusion is that we aren't making Readvertise target NLSR specifically, rather we are using the RibMgmt protocol as a target and extending NLSR to listen for specialized commands from that protocol. Is that correct?
Then, all that needs to be done is write a module for NLSR to listen for these commands on those prefixes, and to incorporate the information from them?
No, this is completely wrong.
- Readvertise will send RibRegister/RibUnregister commands on
/localhost/nlsr/ribprefix. The commands are encoded in NFD-RIB format, but they are sent to a prefix controlled by NLSR (NfdRibReadvertiseDestinationconstructor takes the command prefix). ClientToNlsrReadvertisePolicyis responsible for filtering the RIB updates, and sends commands to NLSR only origin=client.- NLSR should accept RibRegister/RibUnregister commands on
/localhost/nlsr/ribprefix, and process all of them.