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 |