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 signed interests, whose name has the following form: /<prefix>/<management-module>/<command-verb>/<control-parameters>/<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.
• <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. see https://www.ietf.org/rfc/rfc2616.txt.

(See RFC2616 section 10)