Project

General

Profile

Feature #3824

NetworkRegionTable dataset

Added by Muhammad Hosain Abdullahi Sabet over 3 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Category:
Management
Target version:
-
Start date:
10/22/2016
Due date:
% Done:

0%

Estimated time:

Description

Currently NetworkRegionTable API only provides means to determine forwarding behavior in processing incoming Interests with Link objects.
However, for a mobile producer to generate a Link object, it's also necessary for the application to learn the region names assigned to the local NFD, which can be used to derive delegation names.
This information shall be exposed as a StatusDataset.

History

#1

Updated by Muhammad Hosain Abdullahi Sabet over 3 years ago

I have slightly modified the table definition and added a function for returning table's elements(regionNames) for now.

#2

Updated by Junxiao Shi over 3 years ago

there should be a mechanism for clients to retrieve Region Name(s) of local router which the client is connected to

What's the use case of this mechanism?
Having a region name does not mean it's routable. Routable prefixes are offered in #3145 and they are more useful to applications.

I have slightly modified the table definition and added a function for returning table's elements(regionNames) for now.

This is totally unnecessary because NetworkRegionTable publicly inherits from std::set<Name>, so that a caller can enumerate region names using std::set APIs.

#3

Updated by Muhammad Hosain Abdullahi Sabet over 3 years ago

Junxiao Shi wrote:

What's the use case of this mechanism?
Having a region name does not mean it's routable. Routable prefixes are offered in #3145 and they are more useful to applications.

DelegationNames in Link objects are supposed to be routable in internetwork environments(including DFZ). If not, there is no use for Links. So, if a mobile node relocates into a new network, mobile node applications or mobile nfd should first be aware of the fact that the node has relocated into a new network. Secondly, they should somehow learn about which delegationNames they can use for their new Link object.
Actually at the end I'm proposing a protocol for mobility support, which I have done some experiments on it partially.

Junxiao Shi wrote:

This is totally unnecessary because NetworkRegionTable publicly inherits from std::set, so that a caller can enumerate region names using std::set APIs.

This may be true. But with this argument, then you would not need functions for NodeContainer (e.g. in globalRoutingHelper) when you have such for Ptr, because a caller can already go with multiple Ptr ones.

#4

Updated by Junxiao Shi over 3 years ago

  • Subject changed from NetworkRegionTable: Introduce mechanism for retrieving RegionName(s). to NetworkRegionTable dataset
  • Description updated (diff)

Original description:

Currently NetworkRegionTable API is implemented only for providing means to determine behavior of nfd in processing incommingInterest with Link objects attached. For supporting mobility, which is the mentioned goal of this table, it seems there should be a mechanism for clients to retrieve Region Name(s) of local router which the client is connected to. Something similar to local hub discovery. In simulation one can easily have an application to respond interest with data containing NRT entries. But maybe we should have a standard way of this exchange in nfd level. We could extend the API first to provide means for retrieving Region Name(s) in one Data pkt.

#5

Updated by Junxiao Shi over 3 years ago

if a mobile node relocates into a new network, mobile node applications or mobile nfd should first be aware of the fact that the node has relocated into a new network. Secondly, they should somehow learn about which delegationNames they can use for their new Link object.

I agree with this use case. However, I disagree with rushing the implementation until the high-level question below is resolved.

There's still a missing piece: The NetworkRegionTable could contain a longer prefix than the network domain in which a globally-unroutable name is announced; if an application creates a Link object with a name from local NetworkRegionTable, it can result in suboptimal network operations.
For example, /net/ndnsim prefix is announced within UCLA CS dept, and it's served by two producers. The NetworkRegionTable on one of the producers is configured as /edu/ucla/cs/ndnsim-server-1 and the other as /edu/ucla/cs/ndnsim-server-2. Ideally, the Link object should be created with /edu/ucla as delegation name, and the UCLA-CS router can load balance between the two servers; if the producer creates a Link object with the prefix /edu/ucla/cs/ndnsim-server-1 from the NetworkRegionTable, it would render the other producer useless.
One proposal would be to configure both producers' NetworkRegionTable with /edu/ucla/cs. However, if one of the machine also needs to serve some other content that cannot be announced into UCLA CS dept, the other Link object would need to point to one specific machine, which becomes impossible because there isn't a region for that.

#6

Updated by Muhammad Hosain Abdullahi Sabet about 3 years ago

Junxiao Shi wrote:

There's still a missing piece: The NetworkRegionTable could contain a longer prefix than the network domain in which a globally-unroutable name is announced; if an application creates a Link object with a name from local NetworkRegionTable, it can result in suboptimal network operations.
For example, /net/ndnsim prefix is announced within UCLA CS dept, and it's served by two producers. The NetworkRegionTable on one of the producers is configured as /edu/ucla/cs/ndnsim-server-1 and the other as /edu/ucla/cs/ndnsim-server-2. Ideally, the Link object should be created with /edu/ucla as delegation name, and the UCLA-CS router can load balance between the two servers; if the producer creates a Link object with the prefix /edu/ucla/cs/ndnsim-server-1 from the NetworkRegionTable, it would render the other producer useless.
One proposal would be to configure both producers' NetworkRegionTable with /edu/ucla/cs. However, if one of the machine also needs to serve some other content that cannot be announced into UCLA CS dept, the other Link object would need to point to one specific machine, which becomes impossible because there isn't a region for that.

Actually I'm not sure If I understood the problem quite clearly. When you talk about local NRT, I'm a bit confused. Each node can have NRT as part of its nfd. But what's the use of configuring NRT for an individual content producer node?

#7

Updated by Muhammad Hosain Abdullahi Sabet about 3 years ago

While I agree with ignoring the API extension and repeat the above, simultaneously:
So, are nodes supposed to publish NRT dataset - which I assume only includes a set of ndn::name - among other sets of data? Actually I don't think NRT status has things to do with FIB or Face managers. I think it will be something more like Discover local hub prefix:
http://named-data.net/doc/NFD/current/misc/local-prefix-discovery.html#local-prefix-discovery

#8

Updated by Junxiao Shi about 3 years ago

Reply to note-7:

I'm unsure about the usefulness of a NetworkRegionTable dataset due to the missing piece identified in note-5.
The relation between NetworkRegion configuration and routable prefixes dataset (#3145) needs to be discussed.

#9

Updated by Muhammad Hosain Abdullahi Sabet about 3 years ago

Reply to note-8:

I agree with the need for second one to be discussed.

Reply to note-5:

I believe lookup for delegationNames should be based on exact match so that we can have different scales in Link usage.
For the first piece of yours, I think you are looking for load balancing which is not the goal of Link objects. selectedDelegation is there to prefer/select one delegationName to another. If there needs to be load balancing, owners of NRTs are responsible for making it possible.
Sorry. I didn't understand the problem with "However..." part. Could you elaborate more?

#10

Updated by Junxiao Shi over 2 years ago

  • Category set to Management

Also available in: Atom PDF