Feature #3026
closed
RouterName configuration option
Added by Junxiao Shi almost 9 years ago. Updated over 8 years ago.
100%
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::generalnamespace to expose configured values
Documentation and NFD Developer Guide should be updated as part of this issue.
Updated by Junxiao Shi almost 9 years ago
- Related to Feature #3000: Design mobility with forwarding hint added
Updated by Junxiao Shi almost 9 years ago
- Blocks Feature #3027: ForwarderStatus: RouterName added
Updated by Junxiao Shi almost 9 years ago
Updated by Junxiao Shi almost 9 years ago
- Blocks Feature #3034: ContentStore miss pipeline: process Link for mobility added
Updated by Vince Lehman almost 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.
Updated by Lan Wang almost 9 years ago
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.
Monitoring the ForwarderStatus seems to be the straightforward solution to learn the changed name. Any other lighter weight solution?
Updated by Junxiao Shi almost 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.
Updated by Vince Lehman almost 9 years ago
Junxiao Shi wrote:
Reply to note-6 and note-7:
/ndn/edu/memphis/titanshould be represented as PartialNames, not absolute Name. Therefore, drop the '/' in front.
It's necessary to add comments to describe the semantics ofnetwork,site, androuter.
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?
Updated by Vince Lehman almost 9 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 80
Updated by Alex Afanasyev almost 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.
Updated by Junxiao Shi almost 9 years ago
Updated by Alex Afanasyev almost 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).
Updated by Alex Afanasyev almost 9 years ago
- Blocks Feature #3049: RouterName configuration option added
Updated by Junxiao Shi almost 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.
Updated by Vince Lehman almost 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.
Updated by Junxiao Shi almost 9 years ago
- Status changed from In Progress to Closed
I confirm devguide is correctly updated.
Updated by Junxiao Shi over 8 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).
Updated by Vince Lehman over 8 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.
Updated by Junxiao Shi over 8 years ago
Answer to note-20:
RouterNametype should expose threePartialNames and a completeName; all of them should be declared asconst Nameso they cannot be changed out of constructor.RouterNameconstructor should take threePartialNames, assign them to member fields, and build the completeName.
Updated by Vince Lehman over 8 years ago
In that case, should the RouterName static variable be moved to global scope and be made a unique_ptr?
Updated by Junxiao Shi over 8 years ago
Reply to note-22:
This is an implementation detail. Implementer should make this decision.
Updated by Junxiao Shi over 8 years ago
Updated by Junxiao Shi over 8 years ago
- Related to deleted (Feature #3000: Design mobility with forwarding hint)
Updated by Junxiao Shi over 8 years ago
- Blocks deleted (Feature #3034: ContentStore miss pipeline: process Link for mobility)
Updated by Junxiao Shi over 8 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.
Updated by Junxiao Shi over 8 years ago
Revert Change: http://gerrit.named-data.net/2357