Feature #3142
open
Configurable top-level prefixes for NFD-RIB
0%
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
ribcomponent. For example,ndn:/localhop/hobo/nfdcauses NFD-RIB to listen onndn:/localhop/hobo/nfd/ribtop-level prefix. The purpose is to be compatible with #3141. ndn:/localhost/nfd/ribis always enabled, and need not appear in the configuration.ndn:/localhop/nfd/ribis not implicitly enabled. If needed, it should be configured asndn:/localhop/nfd.
- The configured values should omit the final
- 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.
Updated by Junxiao Shi over 8 years ago
- Related to Feature #3141: Configurable top-level prefixes for NFD management added
Updated by Junxiao Shi over 8 years ago
- Related to Feature #3143: Discover RIB management prefix of connected gateway router added
Updated by Junxiao Shi over 8 years ago
- Blocks Feature #3145: Collect and publish routable-prefixes added
Updated by
Updated by Lan Wang over 4 years ago
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.
Updated by Junxiao Shi over 4 years ago
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.
Updated by Lan Wang over 4 years ago
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.
Updated by Junxiao Shi over 4 years ago
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.