Project

General

Profile

Actions

Feature #3142

open

Configurable top-level prefixes for NFD-RIB

Added by Junxiao Shi about 9 years ago. Updated almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
RIB
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
4.50 h

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 open0 closed)

Related to NFD - Feature #3141: Configurable top-level prefixes for NFD managementNew

Actions
Related to NFD - Feature #3143: Discover RIB management prefix of connected gateway routerNew

Actions
Blocks NFD - Feature #3145: Collect and publish routable-prefixesNew

Actions
Actions #1

Updated by Junxiao Shi about 9 years ago

  • Related to Feature #3141: Configurable top-level prefixes for NFD management added
Actions #2

Updated by Junxiao Shi about 9 years ago

  • Description updated (diff)
Actions #3

Updated by Junxiao Shi about 9 years ago

  • Related to Feature #3143: Discover RIB management prefix of connected gateway router added
Actions #4

Updated by Junxiao Shi about 9 years ago

  • Blocks Feature #3145: Collect and publish routable-prefixes added
Actions #5

Updated by Davide Pesavento almost 7 years ago

  • Target version deleted (v0.5)
Actions #6

Updated by Lan Wang almost 5 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.

Actions #7

Updated by Junxiao Shi almost 5 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.

Actions #8

Updated by Lan Wang almost 5 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.

Actions #9

Updated by Junxiao Shi almost 5 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.

Actions

Also available in: Atom PDF