Project

General

Profile

Actions

Feature #3026

closed

RouterName configuration option

Added by Junxiao Shi over 9 years ago. Updated about 9 years ago.

Status:
Abandoned
Priority:
Normal
Assignee:
Category:
Management
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

In NFD configuration file general section, add configuration option(s) for RouterName.

The configuaration option(s) should be able to:

  • construct a RouterName that is used in mobility with Link processing
  • contain enough information to be used by NLSR to initialize itself

This issue contains:

  • determine whether to declare one configuration option, or multiple configuration options
  • decide the name and syntax of configuration option(s)
  • determine the behavior upon a configuration reload signal
  • add functions in nfd::general namespace to expose configured values

Documentation and NFD Developer Guide should be updated as part of this issue.


Related issues 2 (2 open0 closed)

Blocks NFD - Feature #3027: ForwarderStatus: RouterNameNew

Actions
Blocks NFD - Feature #3049: RouterName configuration optionNew

Actions
Actions #1

Updated by Junxiao Shi over 9 years ago

  • Related to Feature #3000: Design mobility with forwarding hint added
Actions #2

Updated by Junxiao Shi over 9 years ago

Actions #3

Updated by Junxiao Shi over 9 years ago

This issue is not blocked by #2107. Despite code location is within mgmt/, configuration file processing procedures is not expected to be touched by #2107.

Actions #4

Updated by Junxiao Shi over 9 years ago

  • Blocks Feature #3034: ContentStore miss pipeline: process Link for mobility added
Actions #5

Updated by Vince Lehman over 9 years ago

  • Assignee set to Vince Lehman
Actions #6

Updated by Vince Lehman over 9 years ago

  • Status changed from New to In Progress
  • determine whether to declare one configuration option, or multiple configuration options

To provide enough information for NLSR to be initialized, I recommend multiple configuration options that can be obtained from the ForwarderStatus dataset. Defining multiple configuration options makes determining the boundaries of the network and site names possible.

To set the LSA prefix, NLSR must know where the router name’s network components stop and the site components begin. With a single RouterName configuration option, there is no marker to tell when the network ends. With multiple configuration options, the beginning and end of both the network and site are made explicit.

  • decide the name and syntax of configuration option(s)
general
{
  ...

  router_name
  {
    network /ndn
    site    /edu/memphis
    router  /titan
  }
}

One choice that needs to be considered is whether or not to require the inclusion of the <%C1.Router> marker in the router option or to automatically add it when the router name is loaded.

For example, the above configuration would create the router name “/ndn/edu/memphis/%C1.Router/titan”. I personally like not including the marker as it does not require the user to be aware of the requirements of NLSR, and it allows for the automatic <%C1.Router> inclusion to be replaced by a marked component in the future.

The <%C1.Router> component is used to signal the beginning of the router’s name so the network name and site name can be extracted by the validator. The extracted network and site names are used to validate the Operator.
Without the <%C1.Router> component, the validator cannot determine where the site name ends and the router name begins.

  • determine the behavior upon a configuration reload signal

On a configuration reload signal, the previous router name and configuration options should be reset and replaced with the values obtained from the reloaded configuration file.

From my understanding of the code, it looks like NFD will receive a configuration reload signal when a SIGHUP is received by the NfdRunner class. In this case, will NLSR be disconnected from the forwarder? If not, NLSR will need to monitor the ForwarderStatus dataset to determine if the router name has changed.

Actions #7

Updated by Lan Wang over 9 years ago

  1. I also prefer not including %C1.Router in the configuration. However, it may be good to include a comment that the final router name will include this marker between site and router name segments to avoid any surprises to the operator.

  2. Monitoring the ForwarderStatus seems to be the straightforward solution to learn the changed name. Any other lighter weight solution?

Actions #8

Updated by Junxiao Shi over 9 years ago

Reply to note-6 and note-7:

/ndn /edu/memphis /titan should be represented as PartialNames, not absolute Name. Therefore, drop the '/' in front.

It's necessary to add comments to describe the semantics of network, site, and router.

I agree that "%C1.Router" shouldn't appear in the configuration.

During a configuration reload, NLSR will not be disconnected.
NLSR shouldn't poll the ForwarderStatus dataset, because it's unnecessary overload most of the time, and has a delay when the change happens.

Instead, we could require the caller to send a reload signal to NLSR as well, so NLSR can reload both its own configuration file and the ForwarderStatus dataset; if the caller does not signal NLSR, the change in RouterName does not take effect in routing.

Actions #9

Updated by Vince Lehman over 9 years ago

Junxiao Shi wrote:

Reply to note-6 and note-7:

/ndn /edu/memphis /titan should be represented as PartialNames, not absolute Name. Therefore, drop the '/' in front.
It's necessary to add comments to describe the semantics of network, site, and router.
I agree that "%C1.Router" shouldn't appear in the configuration.

Is the following change to the general section in "nfd.conf.sample.in" a correct starting point for implementation? The exact wording of the comments can be reviewed on Gerrit.

; The general section contains settings of nfd process.
general
{
  ; Specify a user and/or group for NFD to drop privileges to
  ; when not performing privileged tasks. NFD does not drop
  ; privileges by default.

  ; user ndn-user
  ; group ndn-user

  ; The router_name section specifies the name components used
  ; to build this router's name. The router name is constructed
  ; using the configuration options in the following manner:
  ;   /<network>/<site>/<%C1.Router>/<router>

  ; router_name
  ; {
  ;   network ndn ; the network to which this router belongs
  ;   site    edu/site ; the site to which this router belongs
  ;   router  router/name ; name used to uniquely identify this router under the site
  ; }
}

Junxiao Shi wrote:

During a configuration reload, NLSR will not be disconnected.
NLSR shouldn't poll the ForwarderStatus dataset, because it's unnecessary overload most of the time, and has a delay when the change happens.

Instead, we could require the caller to send a reload signal to NLSR as well, so NLSR can reload both its own configuration file and the ForwarderStatus dataset; if the caller does not signal NLSR, the change in RouterName does not take effect in routing.

The caller will need to explicitly trigger an NLSR reload, so this is not something that needs to be implemented in this task, right?

Actions #10

Updated by Junxiao Shi over 9 years ago

I agree to both points in note-9.

Actions #11

Updated by Vince Lehman over 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 80
Actions #12

Updated by Alex Afanasyev over 9 years ago

http://gerrit.named-data.net/#/c/2243/1 implements configuration options, but remembers them in a static variable. I would like to avoid introduction of static elements, as it would impede support in ndnSIM.

I think we need some kind of an instance of a general manager that should remember any necessary state. We didn't need it before, but may need it now.

Actions #13

Updated by Junxiao Shi over 9 years ago

Reply to note-12:

I agree with this idea but disagree with requiring it now.
It should be separate issue and arranged after #2107 and #3029, because it has some interaction with ForwarderStatus.

A simple RouterName is needed now for mobility with Link.

Actions #14

Updated by Alex Afanasyev over 9 years ago

I am not convienced that this has blocking on refactored management, but I agree to defer non-static general state recording to further commit. However, we should do it before next release (either minor or major).

Actions #15

Updated by Alex Afanasyev over 9 years ago

Actions #16

Updated by Junxiao Shi over 9 years ago

  • Status changed from Code review to In Progress

Next: update documentation (including ConfigFileFormat wiki page) and NFD Developer Guide ("General Configuration File Section Parser" section) to reflect this change.

Actions #17

Updated by Vince Lehman over 9 years ago

  • % Done changed from 80 to 100

I've finished updating the ConfigFileFormat wiki page as well as both the "General Configuration File Section Parser" and "User Info" sections in the NFD Developer's Guide.

Actions #18

Updated by Junxiao Shi over 9 years ago

  • Status changed from In Progress to Closed

I confirm devguide is correctly updated.

Actions #19

Updated by Junxiao Shi about 9 years ago

  • Status changed from Closed to Feedback

During the development of #3034, Alex and Davide point out that the design of RouterName class is causing unnecessary overhead in forwarding.

In particular, RouterName::getName method should return const Name& instead of const Name, so that forwarding would not have to make a copy of the return value.

Please rework this feature by uploading a new Change (not amending the old commit).

Actions #20

Updated by Vince Lehman about 9 years ago

This is an easy fix, just want to be clear which is preferred before I start implementation:

If I mimic the current behavior, each time RouterName::getName is called, the router's prefix will be constructed and assigned to a private member variable which will be returned. If the public member variables (network, site, router) are modified, the change will be reflected by RouterName::getName().

An alternative is to only construct the router's prefix after the configuration file is loaded and just return the reference in RouterName::getName(). This reduces the overhead of building the prefix, but if the public member variables are modified, RouterName::getName() will not reflect the changes.

Another alternative is to make RouterName's public member variables (network, site, router) private, and only build the router's prefix when the setters are used.

Actions #21

Updated by Junxiao Shi about 9 years ago

Answer to note-20:

  • RouterName type should expose three PartialNames and a complete Name; all of them should be declared as const Name so they cannot be changed out of constructor.
  • RouterName constructor should take three PartialNames, assign them to member fields, and build the complete Name.
Actions #22

Updated by Vince Lehman about 9 years ago

In that case, should the RouterName static variable be moved to global scope and be made a unique_ptr?

Actions #23

Updated by Junxiao Shi about 9 years ago

Reply to note-22:

This is an implementation detail. Implementer should make this decision.

Actions #24

Updated by Junxiao Shi about 9 years ago

According to #3000 note-20, mobility feature no longer uses RouterName.

Should we revert this feature, and keep RouterName in NLSR configuration file?

If reverting, #3027 #3028 #3029 #3030 #3025 will be reverted or abandoned as well.

Actions #25

Updated by Junxiao Shi about 9 years ago

  • Related to deleted (Feature #3000: Design mobility with forwarding hint)
Actions #26

Updated by Junxiao Shi about 9 years ago

  • Blocks deleted (Feature #3034: ContentStore miss pipeline: process Link for mobility)
Actions #27

Updated by Junxiao Shi about 9 years ago

  • Status changed from Feedback to Abandoned

20150817 conference call decides to abandon this feature, and undo the changes, because the current implementation is causing problems (#3049), and RouterName is no longer needed by mobility.

In the long term, RouterName may be needed for tunnel authentication. We can reimplement this feature properly in #3049 in the future.

I'll upload a Change to undo the changes.

Actions

Also available in: Atom PDF