Repo Protocol Specification » History » Version 19
Shuo Chen, 02/19/2014 02:56 PM
| 1 | 1 | Shuo Chen | Repo Protocol Specification |
|---|---|---|---|
| 2 | =========================== |
||
| 3 | |||
| 4 | 2 | Shuo Chen | Repo is persistent storage of data objects model in NDN. The NDN repo protocol is a specification of repo operations including reading, insertion and deletion of data objects in repo. |
| 5 | |||
| 6 | Repo semantics is based on [Command Interests](http://redmine.named-data.net/projects/nfd/wiki/Command_Interests) with signed commponents an the end of the name and basic common semantics of NDN. |
||
| 7 | |||
| 8 | 11 | Shuo Chen | When some operation of repo including insertion and deletion of data objects is requested, a command interest is sent. The command interest is the interest as command of insertion and deletion and signed as form of command interest for access control. The repo will response the command with the data object. |
| 9 | 4 | Shuo Chen | |
| 10 | The repo protocol can be categorized in three sections of reading, insertion and deletion of data objects. |
||
| 11 | |||
| 12 | ## Repo Reading Specification |
||
| 13 | |||
| 14 | 11 | Shuo Chen | The repo could be viewed as the data container of the data objects. It will register some specific prefixes of data objects it holds into NFD (NDN Forwarding Deamon) and the repo will respond the data with such prefixes. |
| 15 | 6 | Shuo Chen | |
| 16 | 11 | Shuo Chen | A standard interest is used to fetch content from the repo. The repo will respond when the name of the interest matches the prefix it registered in NFD. If the content in repo matches the interests, it will respond with the data object. When the interest is not matched, it will not respond. |
| 17 | 6 | Shuo Chen | |
| 18 | The protocol is listed as bellow |
||
| 19 | |||
| 20 | If there is a matching data object: |
||
| 21 | |||
| 22 | 7 | Shuo Chen | Requester Repo |
| 23 | | | |
||
| 24 | | | |
||
| 25 | | Interest | |
||
| 26 | t1 |-------------------------->| |
||
| 27 | | | |
||
| 28 | | Data Object | |
||
| 29 | t2 |<==========================| |
||
| 30 | 1 | Shuo Chen | | | |
| 31 | 7 | Shuo Chen | | | |
| 32 | 1 | Shuo Chen | | | |
| 33 | 7 | Shuo Chen | |
| 34 | If there is no matching data object: |
||
| 35 | 6 | Shuo Chen | |
| 36 | Requester Repo |
||
| 37 | | | |
||
| 38 | 1 | Shuo Chen | | | |
| 39 | 7 | Shuo Chen | | Interest | |
| 40 | t1 |-------------------------->| |
||
| 41 | | | |
||
| 42 | | | |
||
| 43 | | | |
||
| 44 | |||
| 45 | 8 | Shuo Chen | ## Repo Insertion Specification |
| 46 | |||
| 47 | 11 | Shuo Chen | Insertion specification is for some client and application to insert data objects into certain NDN repo. A command interest as insertion command will be sent to the repo. This command interest is a signed interest and will be validated with access control policy defined by the repo. When the interested is validated and name of the data is not existed in the repo. The repository will reponse with a data object containing OK status and start to send the interest to fetch the data to insert. |
| 48 | 8 | Shuo Chen | |
| 49 | 19 | Shuo Chen | Segmented data insertion is also supported in the insertion protocol. Segmantation info is defined as a TLV-encoded SegmantationInfo block. If the content is segmented, the final segment id will be encoded in this block. |
| 50 | 14 | Shuo Chen | |
| 51 | 8 | Shuo Chen | ### Insertion command interest semantics |
| 52 | 1 | Shuo Chen | |
| 53 | The name semantics is defined to have following components: |
||
| 54 | |||
| 55 | 17 | Shuo Chen | * ``<name of repo>`` refers to specific name of repo |
| 56 | 11 | Shuo Chen | * ``insert`` refers to insert data objects |
| 57 | 1 | Shuo Chen | * ``<data name>`` refers to specific name of data that will be inserted |
| 58 | |||
| 59 | 8 | Shuo Chen | The folloing components are components of singed interest for access control: |
| 60 | |||
| 61 | * ``<timestamp>`` |
||
| 62 | * ``<random-value>`` |
||
| 63 | * ``<SignatureInfo>`` |
||
| 64 | * ``<SignatureValue>`` |
||
| 65 | |||
| 66 | 17 | Shuo Chen | <name of repo> and <data name> can be divided by serveral continious ``/`` according to specific defination. |
| 67 | For example, for ``<name of repo>`` as ``/ucla/cs/repo`` and ``<data name>`` as ``/vedio/Forrest Gump``, the data object is defined as following: |
||
| 68 | 8 | Shuo Chen | |
| 69 | 11 | Shuo Chen | /ucla/cs/repo/insert/vedio/Forrest Gump/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
| 70 | 14 | Shuo Chen | |
| 71 | ### SegmantationInfo |
||
| 72 | |||
| 73 | SegmantationInfo ::= SEGMENTATIONINFO-TYPE TLV-LENGTH |
||
| 74 | StartBlockId? |
||
| 75 | FinalBlockId? |
||
| 76 | |||
| 77 | StartBlockId ::= STARTBLOCKID-TYPE TLV-LENGTH |
||
| 78 | nonNegativeInteger |
||
| 79 | 1 | Shuo Chen | |
| 80 | EndBlockId ::= FINALBLOCKID-TYPE TLV-LENGTH |
||
| 81 | nonNegativeInteger |
||
| 82 | |||
| 83 | 17 | Shuo Chen | ### Insertion status check |
| 84 | 1 | Shuo Chen | |
| 85 | 19 | Shuo Chen | During the insertion progress, the requester could send insertion status check command to check the status of the insertion progress. This status check command is also signed interest. The semantics of insertion status check command is shown as follows: |
| 86 | 17 | Shuo Chen | |
| 87 | The name semantics is defined to have following components: |
||
| 88 | |||
| 89 | * ``<name of repo>`` refers to specific name of repo |
||
| 90 | * ``insert check`` refers to insert data objects |
||
| 91 | * ``<data name>`` refers to specific name of data that will be inserted |
||
| 92 | |||
| 93 | The folloing components are components of singed interest for access control: |
||
| 94 | |||
| 95 | * ``<timestamp>`` |
||
| 96 | * ``<random-value>`` |
||
| 97 | * ``<SignatureInfo>`` |
||
| 98 | 1 | Shuo Chen | * ``<SignatureValue>`` |
| 99 | |||
| 100 | |||
| 101 | 19 | Shuo Chen | ### Insertatation status response |
| 102 | |||
| 103 | This insert status data object could be the response data object of both insert command and insert check command. The name of data packet is the same as that of command. The insertion status is enocoded as a TLV echoded block in content block in data packet. The TLV block format is as follows: |
||
| 104 | |||
| 105 | 17 | Shuo Chen | InsertStatus ::= INSERTSTATUS-TYPE TLV-LENGTH |
| 106 | StatusCode? |
||
| 107 | StartBlockId? |
||
| 108 | FinalBlockId? |
||
| 109 | InsertNum? |
||
| 110 | |||
| 111 | StatusCode ::= STATUSCODE-TYPE TLV-LENGTH |
||
| 112 | nonNegativeInteger |
||
| 113 | |||
| 114 | StartBlockId ::= STARTBLOCKID-TYPE TLV-LENGTH |
||
| 115 | nonNegativeInteger |
||
| 116 | |||
| 117 | EndBlockId ::= FINALBLOCKID-TYPE TLV-LENGTH |
||
| 118 | nonNegativeInteger |
||
| 119 | 1 | Shuo Chen | |
| 120 | 17 | Shuo Chen | InsertNum ::= INSERTNUM-TYPE TLV-LENGTH |
| 121 | nonNegativeInteger |
||
| 122 | |||
| 123 | 19 | Shuo Chen | StatusCode indicates the status of insertion. InsertNum represents how many data has been intersted into the repo. |
| 124 | 1 | Shuo Chen | |
| 125 | 17 | Shuo Chen | StatusCode Definition: |
| 126 | |||
| 127 | ``StatusCode`` | Description |
||
| 128 | 19 | Shuo Chen | -------------- | ---------------------------------------------- |
| 129 | ``100`` | The command is OK. can start to fetch the data |
||
| 130 | 17 | Shuo Chen | ``200`` | All the data has been inserted |
| 131 | ``300`` | This insertion is in progress |
||
| 132 | ``401`` | This insertion check is invalidated |
||
| 133 | ``404`` | No such this insertion is in progress |
||
| 134 | |||
| 135 | ### Protocol process |
||
| 136 | |||
| 137 | 1 | Shuo Chen | 1. start to authorize the command; if authorization does not fail immediately, go to step 3 |
| 138 | 14 | Shuo Chen | |
| 139 | 1 | Shuo Chen | 2. send a negative response indicating authorization failure, and abort these steps |
| 140 | 14 | Shuo Chen | |
| 141 | 1 | Shuo Chen | 3. if both StartBlockId and EndBlockId are missing, go to step 6 |
| 142 | 14 | Shuo Chen | |
| 143 | 1 | Shuo Chen | 4. if both StartBlockId and EndBlockId are present, and StartBlockId is less than or equal to EndBlockId, go to step 6 |
| 144 | 14 | Shuo Chen | |
| 145 | 5. send a negative response indicating malformed command, and abort these steps |
||
| 146 | |||
| 147 | 6. wait for authorization completion |
||
| 148 | |||
| 149 | 7. if authorization fails, go to step 2 |
||
| 150 | |||
| 151 | 8. send a positive response indicating insert is in progress |
||
| 152 | |||
| 153 | 9. if both StartBlockId and EndBlockId are present, go to step 15 |
||
| 154 | |||
| 155 | 10. start to retrieve Name |
||
| 156 | |||
| 157 | 11. wait for retrieval completion |
||
| 158 | |||
| 159 | 12. if retrieval fails, abort these steps |
||
| 160 | |||
| 161 | 13. store retrieved Data packet |
||
| 162 | |||
| 163 | 14. abort these steps |
||
| 164 | |||
| 165 | 15. append StartBlockId to Name |
||
| 166 | |||
| 167 | 16. start to retrieve Name |
||
| 168 | |||
| 169 | 17. wait for retrieval completion |
||
| 170 | |||
| 171 | 18. if retrieval fails, abort these steps |
||
| 172 | 15 | Shuo Chen | |
| 173 | 14 | Shuo Chen | 19. store retrieved Data packet |
| 174 | 15 | Shuo Chen | |
| 175 | 14 | Shuo Chen | 20. if retrieved Data packet contains FinalBlockId, and FinalBlockId is less than EndBlockId, let EndBlockId be FinalBlockId |
| 176 | 15 | Shuo Chen | |
| 177 | 14 | Shuo Chen | 21. if the last component of Name is greater than or equal to EndBlockId, abort these steps |
| 178 | 15 | Shuo Chen | |
| 179 | 14 | Shuo Chen | 22. increment the last component of Name |
| 180 | 15 | Shuo Chen | |
| 181 | 1 | Shuo Chen | 23. go to step 16 |
| 182 | |||
| 183 | 16 | Shuo Chen | Implementation MAY pipeline the Interests. |
| 184 | |||
| 185 | 18 | Shuo Chen | Implementation MAY publish a notification of status regarding insert progress. The process of status check is as follows: |
| 186 | |||
| 187 | 1. start to authorize the insert status command |
||
| 188 | 1 | Shuo Chen | |
| 189 | 18 | Shuo Chen | 2. send a negative response indicating authorization failure, and abort these steps |
| 190 | |||
| 191 | 3. start to check the progress of the insert with the data name in the command. If no such progress is found, go to 4. or go to 5. |
||
| 192 | |||
| 193 | 4. reponse status with status code of 404 |
||
| 194 | |||
| 195 | 5. ckeck te status of insertion. return the status data content |
||
| 196 | |||
| 197 | 17 | Shuo Chen | ### Protocol diagram: |
| 198 | 10 | Alex Afanasyev | |
| 199 | Requester Repo Data producer |
||
| 200 | | | | |
||
| 201 | | | | |
||
| 202 | +---+ Insert command +---+ | |
||
| 203 | | | --------------------> | | | |
||
| 204 | +---+ | | | |
||
| 205 | | | | | |
||
| 206 | +---+ Confirm start | | | |
||
| 207 | | | <==================== | | | |
||
| 208 | +---+ Reject command +---+ | |
||
| 209 | | (with status code) | | |
||
| 210 | | +---+ Interest for Data +---+ |
||
| 211 | | | | --------------------------> | | |
||
| 212 | | +---+ | | |
||
| 213 | | | | | |
||
| 214 | | +---+ Data segment | | |
||
| 215 | | | | <========================== | | |
||
| 216 | | +---+ +---+ |
||
| 217 | | | | |
||
| 218 | | ~ ~ |
||
| 219 | | ~ ~ |
||
| 220 | | | | |
||
| 221 | | +---+ Interest for Data +---+ |
||
| 222 | | | | --------------------------> | | |
||
| 223 | | +---+ | | |
||
| 224 | | | | | |
||
| 225 | | +---+ Data segment | | |
||
| 226 | | | | <========================== | | |
||
| 227 | | +---+ +---+ |
||
| 228 | | | | |
||
| 229 | | | | |
||
| 230 | | ~ ~ |
||
| 231 | | ~ ~ |
||
| 232 | | | | |
||
| 233 | | | | |
||
| 234 | | | | |
||
| 235 | +---+ Status interest +---+ | |
||
| 236 | | | --------------------> | | | |
||
| 237 | +---+ | | | |
||
| 238 | 1 | Shuo Chen | | | | | |
| 239 | +---+ Status response | | | |
||
| 240 | | | <==================== | | | |
||
| 241 | +---+ +---+ | |
||
| 242 | | | | |
||
| 243 | | | | |
||
| 244 | |||
| 245 | ## Repo Deletion Specification |
||
| 246 | |||
| 247 | Deletion of one content object or content objects under certain prefix are both supported in repo specification. Selectors are used to select multiple content objects. These selectors are different from conventional [selectors](http://named-data.net/doc/ndn-tlv/interest.html#selectors) of interest packet. The conventional selecors of interest would select one data packet of repo. Selecors of delete command will return any data packets which applies for these selectors. |
||
| 248 | |||
| 249 | 19 | Shuo Chen | ### Deletion command interest semantics |
| 250 | |||
| 251 | The name semantics is defined to have following components: |
||
| 252 | |||
| 253 | * ``<name of repo>`` refers to specific name of repo |
||
| 254 | * ``delete`` refers to insert data objects |
||
| 255 | * ``<data name>`` refers to specific name of data that will be inserted |
||
| 256 | |||
| 257 | The folloing components are components of singed interest for access control: |
||
| 258 | |||
| 259 | * ``<timestamp>`` |
||
| 260 | * ``<random-value>`` |
||
| 261 | * ``<SignatureInfo>`` |
||
| 262 | * ``<SignatureValue>`` |
||
| 263 | |||
| 264 | <name of repo> and <data name> can be divided by serveral continious ``/`` according to specific defination. |
||
| 265 | For example, for ``<name of repo>`` as ``/ucla/cs/repo`` and ``<data name>`` as ``/vedio/Forrest Gump``, the data object is defined as following: |
||
| 266 | |||
| 267 | /ucla/cs/repo/delete/vedio/Forrest Gump/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
||
| 268 | |||
| 269 | 17 | Shuo Chen | ### Deletion Command Selectors |
| 270 | |||
| 271 | Selectors ::= SELECTORS-TYPE TLV-LENGTH |
||
| 272 | MinSuffixComponents? |
||
| 273 | MaxSuffixComponents? |
||
| 274 | PublisherPublicKeyLocator? |
||
| 275 | Exclude? |
||
| 276 | |||
| 277 | MinSuffixComponents ::= MIN-SUFFIX-COMPONENTS-TYPE TLV-LENGTH |
||
| 278 | nonNegativeInteger |
||
| 279 | |||
| 280 | MaxSuffixComponents ::= MAX-SUFFIX-COMPONENTS-TYPE TLV-LENGTH |
||
| 281 | nonNegativeInteger |
||
| 282 | |||
| 283 | PublisherPublicKeyLocator ::= KeyLocator |
||
| 284 | |||
| 285 | 1 | Shuo Chen | Exclude ::= EXCLUDE-TYPE TLV-LENGTH Any? (NameComponent (Any)?)+ |
| 286 | Any ::= ANY-TYPE TLV-LENGTH(=0) |
||
| 287 | |||
| 288 | The definitions of delete command selectors is the same as the selectors of conventional [selectors](http://named-data.net/doc/ndn-tlv/interest.html#selectors). The difference is that this delete command selectors will return any data packets that comforms to the selectors. If selectors are not presented, the repo will just delete the data of exact name. So, for example, if somebody wants to delete all the data under certain prefix, at least, MinSuffixComponents should be set to 0. |
||
| 289 | |||
| 290 | 19 | Shuo Chen | ### Deletion status check |
| 291 | |||
| 292 | During the deletion progress, the requester could send deletion status check command to check the status of the deletion progress. This status check command is also signed interest. The semantics of deletion status check command is shown as follows: |
||
| 293 | |||
| 294 | The name semantics is defined to have following components: |
||
| 295 | |||
| 296 | * ``<name of repo>`` refers to specific name of repo |
||
| 297 | * ``delete check`` refers to insert data objects |
||
| 298 | * ``<data name>`` refers to specific name of data that will be inserted |
||
| 299 | |||
| 300 | The folloing components are components of singed interest for access control: |
||
| 301 | |||
| 302 | * ``<timestamp>`` |
||
| 303 | * ``<random-value>`` |
||
| 304 | * ``<SignatureInfo>`` |
||
| 305 | * ``<SignatureValue>`` |
||
| 306 | |||
| 307 | ### Deletion status response |
||
| 308 | |||
| 309 | This delete status data object could be the response data packet of both delete command and delete check command. The name of data packet is the same as that of command.The deletion status is enocoded as a TLV echoded block in content block in data packet. The TLV block format is as follows: |
||
| 310 | |||
| 311 | DeleteStatus ::= DELETESTATUS-TYPE TLV-LENGTH |
||
| 312 | StatusCode? |
||
| 313 | DeleteSum? |
||
| 314 | DeleteNum? |
||
| 315 | |||
| 316 | StatusCode ::= STATUSCODE-TYPE TLV-LENGTH |
||
| 317 | nonNegativeInteger |
||
| 318 | |||
| 319 | DeleteSum ::= INSERTNUM-TYPE TLV-LENGTH |
||
| 320 | nonNegativeInteger |
||
| 321 | |||
| 322 | DeleteNum ::= INSERTNUM-TYPE TLV-LENGTH |
||
| 323 | nonNegativeInteger |
||
| 324 | |||
| 325 | StatusCode indicates the status of deletion. DeleteSum is the sum of the deletion. DeleteNum represents how many data has been deleted. |
||
| 326 | |||
| 327 | StatusCode Definition: |
||
| 328 | |||
| 329 | ``StatusCode`` | Description |
||
| 330 | -------------- | -------------------------------------- |
||
| 331 | ``200`` | All the data has been deleted |
||
| 332 | ``300`` | This deletion is in progress |
||
| 333 | ``401`` | This deletion check is invalidated |
||
| 334 | ``404`` | No such this deletion is in progress |
||
| 335 | |||
| 336 | |||
| 337 | 17 | Shuo Chen | ### Protocol process |
| 338 | |||
| 339 | 1. start to authorize the command; if authorization does not fail immediately, go to step 3 |
||
| 340 | |||
| 341 | 2. send a negative response indicating authorization failure, and abort these steps |
||
| 342 | |||
| 343 | 3. check whether selectors are presented. If selectors are presented, go to step 4, or select the data packet of the exact name of command. If some data is selected, go to step 6. If no data selected, go to step 5 |
||
| 344 | |||
| 345 | 4. select all the data packets that comforms to data name of the command and the selectors. If some data packets are selected, go to step 6. Or no data selected, go to step 5. |
||
| 346 | |||
| 347 | 1 | Shuo Chen | 5. send a negative response and abort the delete transaction. |
| 348 | |||
| 349 | 6. wait for authorization completion |
||
| 350 | |||
| 351 | 7. if authorization fails, go to step 2 |
||
| 352 | |||
| 353 | 19 | Shuo Chen | 8. start to delete the selected data. If deletion success, return positive reponse, or return negative response and abort the deletion. |
| 354 | |||
| 355 | Implementation MAY publish a notification of status regarding delete progress. The process of status check is as follows: |
||
| 356 | |||
| 357 | 1. start to authorize the delete status command |
||
| 358 | |||
| 359 | 2. send a negative response indicating authorization failure, and abort these steps |
||
| 360 | |||
| 361 | 3. start to check the progress of the delete with the data name in the command. If no such progress is found, go to 4. or go to 5. |
||
| 362 | |||
| 363 | 4. reponse status with status code of 404 |
||
| 364 | |||
| 365 | 5. ckeck te status of delete. return the status data content |
||
| 366 | |||
| 367 | ### Protocol diagram: |
||
| 368 | |||
| 369 | Requester Repo |
||
| 370 | | | |
||
| 371 | | | |
||
| 372 | +---+ Delete command +---+ |
||
| 373 | | | --------------------> | | |
||
| 374 | +---+ +---+ |
||
| 375 | | | |
||
| 376 | | | |
||
| 377 | | | |
||
| 378 | +---+ Status interest +---+ |
||
| 379 | | | --------------------> | | |
||
| 380 | +---+ | | |
||
| 381 | | | | |
||
| 382 | +---+ Status response | | |
||
| 383 | | | <==================== | | |
||
| 384 | +---+ +---+ |
||
| 385 | | | |
||
| 386 | | | |
||
| 387 | | | |
||
| 388 | +---+ Confirm Deletion +---+ |
||
| 389 | | | <==================== | | |
||
| 390 | +---+ Reject command +---+ |
||
| 391 | | (with status code) | |
||
| 392 | | | |