ControlCommand » History » Version 1
Junxiao Shi, 01/23/2014 08:00 PM
| 1 | 1 | Junxiao Shi | # NFD Control Command specification |
|---|---|---|---|
| 2 | |||
| 3 | NFD management module exposes a command interface as Interest-Data exchange. |
||
| 4 | Commands provided over this interface are useful for querying or changing the state of NFD forwarder. |
||
| 5 | |||
| 6 | |||
| 7 | ## Request format |
||
| 8 | |||
| 9 | A request to the command interface is an Interest under `ndn:/nfd` prefix. |
||
| 10 | |||
| 11 | A request Interest has at least four Name components. |
||
| 12 | The first four components are: |
||
| 13 | |||
| 14 | 1. "nfd" in UTF-8 |
||
| 15 | 2. *nfdid*, forwarder's public key digest |
||
| 16 | 3. *verb*, the command verb in UTF-8 |
||
| 17 | 4. *options*, the arguments to the command |
||
| 18 | |||
| 19 | ### Signed request and Unsigned request |
||
| 20 | |||
| 21 | Most commands require a signature to be included in the Name. |
||
| 22 | The signature format is defined in [[Signed Interests]] spec. |
||
| 23 | A signed request Interest has seven Name components. |
||
| 24 | |||
| 25 | Certain commands that do not change the forwarder state do not require a signature. |
||
| 26 | An unsigned request Interest has four Name components. |
||
| 27 | |||
| 28 | Each individual command specification defines whether a request Interest using that command verb should be signed or not. |
||
| 29 | |||
| 30 | ### Options |
||
| 31 | |||
| 32 | The *option* component contains arguments to the command as a TLV. |
||
| 33 | |||
| 34 | This component is required even if the command verb does not need any arguments. |
||
| 35 | In that case, this component would have zero length. |
||
| 36 | |||
| 37 | Each individual command specification defines the format of the options TLV. |
||
| 38 | The TLV-TYPE numbers used in this TLV should be allocated from application range, and are not required to be unique across different command verbs. |
||
| 39 | |||
| 40 | |||
| 41 | ## Response format |
||
| 42 | |||
| 43 | A response from the command interface is a Data that matches the request Interest. |
||
| 44 | |||
| 45 | Each individual command specification defines the format inside the Data payload. |
||
| 46 | |||
| 47 | ### Negative response |
||
| 48 | |||
| 49 | A negative response follows the following convention inside the Data payload. |
||
| 50 | |||
| 51 | StatusResponse ::= STATUS-RESPONSE-TYPE TLV-LENGTH |
||
| 52 | StatusCode |
||
| 53 | StatusText? |
||
| 54 | ... |
||
| 55 | |||
| 56 | StatusCode ::= STATUS-CODE-TYPE TLV-LENGTH |
||
| 57 | nonNegativeInteger |
||
| 58 | |||
| 59 | StatusText ::= STATUS-TEXT TLV-LENGTH |
||
| 60 | string in UTF-8 |
||
| 61 | |||
| 62 | **StatusCode** generally follows HTTP convention. Common codes include: |
||
| 63 | |||
| 64 | StatusCode | Description |
||
| 65 | -----------|------------------------ |
||
| 66 | 400 | Arguments are incorrect |
||
| 67 | 401 | Signed request is required for command, but unsigned request is passed |
||
| 68 | 403 | Signing key is not authorized for this command |
||
| 69 | 404 | Command verb is not supported |
||
| 70 | |||
| 71 | In **StatusResponse**, additional elements are allowed at the end. |
||
| 72 | Each individual command specification defines whether and what can present. |
||
| 73 | |||
| 74 | |||
| 75 | ## TLV-TYPE assignments |
||
| 76 | |||
| 77 | Type | Assigned value | Assigned value (hex) |
||
| 78 | ------------------------------------------- | ----------------- | -------------------- |
||
| 79 | StatusResponse | 130 | 0x82 |
||
| 80 | StatusCode | 139 | 0x8b |
||
| 81 | StatusText | 140 | 0x8c |