Feature #3142
open
Configurable top-level prefixes for NFD-RIB
Added by Junxiao Shi about 9 years ago.
Updated about 5 years ago.
Description
Make RibMgmt commands and datasets available under a configurable set of top-level prefixes, in addition to ndn:/localhost/nfd/rib.
Necessity
Currently, NFD-RIB on a gateway router is configured to accept prefix registration commands under ndn:/localhop/nfd/rib, and an end host may send a prefix registration command under this prefix to register a route on the connected gateway router.
However, this procedure would not work if an end host is connected to multiple gateway routers, because the ndn:/localhop/nfd/rib prefix cannot effectively distinguish which gateway router should the command be forwarded to.
This issue includes:
- Declare a configuration option to specify top-level prefixes for NFD-RIB.
- The configured values should omit the final
rib component. For example, ndn:/localhop/hobo/nfd causes NFD-RIB to listen on ndn:/localhop/hobo/nfd/rib top-level prefix. The purpose is to be compatible with #3141.
ndn:/localhost/nfd/rib is always enabled, and need not appear in the configuration.ndn:/localhop/nfd/rib is not implicitly enabled. If needed, it should be configured as ndn:/localhop/nfd.
- Modify NFD-RIB initialization procedure to add all configured top-level prefixes to the dispatcher.
With this Feature, every gateway router can be configured with a distinct top-level prefix, so that an end host connected to multiple gateway routers would be able to effectively address each gateway router using a different prefix.
Note that this Feature would not allow an end host to discover the top-level prefix of NFD-RIB on a connected gateway router, and that will be solved in #3143.
NFD Developer Guide should be updated to reflect the change.
Related issues
3 (3 open — 0 closed)
- Related to Feature #3141: Configurable top-level prefixes for NFD management added
- Description updated (diff)
- Related to Feature #3143: Discover RIB management prefix of connected gateway router added
- Blocks Feature #3145: Collect and publish routable-prefixes added
- Target version deleted (
v0.5)
Although the above is desirable, it is not absolutely necessary depending on the specific goal of the host - what the host wants to achieve by connecting to multiple gateways? If the host wants to be reachable through multiple gateways, then those gateways should advertise the host's prefix --> this can be achieved by setting the prefix registration command prefix to have those faces to the gateways (could be a subset of all the all the connected gateways) as next hops and use the multicast strategy. Note that the set can contain only one gateway.
setting the prefix registration command prefix to have those faces to the gateways as next hops and use the multicast strategy
The main problem with this hack is that, only one Data would come back to the procedure sending the prefix registration command. Therefore, the end host is unable to determine whether the command sent toward each specific gateway router was successful, and thus cannot correctly schedule retries.
Junxiao Shi wrote:
setting the prefix registration command prefix to have those faces to the gateways as next hops and use the multicast strategy
The main problem with this hack is that, only one Data would come back to the procedure sending the prefix registration command. Therefore, the end host is unable to determine whether the command sent toward each specific gateway router was successful, and thus cannot correctly schedule retries.
I understand. But I have always felt that there needs to be some relaxation of the one interest/one data rule for /localhop and one-hop multicast cases. In this case, the flow balance is preserved on the link to each gateway.
Without any long-term changes as the above, perhaps letting nfd explicitly specify the face when it sends the prefix registration command is an option. It just needs to do this multiple times.
I have always felt that there needs to be some relaxation of the one interest/one data rule for /localhop and one-hop multicast cases. In this case, the flow balance is preserved on the link to each gateway.
This discussion belongs to "NDN Specifications" project. Please create an issue there.
Without any long-term changes as the above
Do not add hacks on top of hacks. Solve it the proper way.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by