NLSR Management¶

NLSR Management provides:

• command to add(advertise) routes to name prefix list
• command to remove(withdraw) routes from name prefix list

1. Control Commands¶

1.1 Add a name prefix¶

command-verb: advertise¶

This command adds a name prefix to the name prefix list. This command can be accepted on ndn:/localhost/nlsr/prefix-update prefix.

Control Parameters¶

• Name (required)

1.2 Remove a name prefix¶

command-verb: withdraw¶

This command removes a name prefix from the name prefix list. This command can be accepted on ndn:/localhost/nlsr/prefix-update prefix.

Control Parameters¶

• Name (required)

2. Request format¶

NLSR control commands are command interests (https://redmine.named-data.net/projects/ndn-cxx/wiki/CommandInterest), whose name has the following form: /<prefix>/<management-module>/<command-verb>/<control-parameters>/<timestamp>/<random-value>/<signed-interests-components>

• <prefix> is /localhost/nlsr. Each individual command may specify additional prefixes under which that command could be accepted.
• <management-module>is the name of management module to which the command needs to be dispatched. For example, the name of the management module in this case would be prefix-update.
• <command-verb> is the command to be executed. For this case this would be either withdraw or advertise.
• <control-parameters> is a ControlParameters TLV block wrapped in a NameComponent.
• <timestamp> is interest's timestamp that is used to prevent replay attack.
• <random-value> aka Nonce that ensures the uniqueness of an interest.
• <signed-interest-components> are four additional components defined by [ndn-cxx:SignedInterest|Signed Interest] spec. So, putting everything together, the complete name of a command interest would be localhost/nlsr/prefix-update/advertise or localhost/nlsr/prefix-update/withdraw

3. Response Format¶

A response from the command interface is a Data that matches the request Interest. The payload of this Data is a ControlResponse block.

StatusCode¶

StatusCode loosely follows the HTTP semantics described in RFC2616 section 10 (RFC2616)