idnits 2.17.1 draft-irtf-icnrg-flic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 24 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 391: '... HashGroups SHOULD carry the SizePer...' RFC 2119 keyword, line 395: '... Applications MAY extend FLIC via ne...' RFC 2119 keyword, line 397: '...tadata extension MUST be allocated a u...' RFC 2119 keyword, line 403: '... keying material, FLICs SHOULD carry a...' RFC 2119 keyword, line 405: '...rial. Receivers SHOULD fetch this con...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 26, 2017) is 2313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 678 -- Looks like a reference, but probably isn't: '32' on line 638 -- Looks like a reference, but probably isn't: '8' on line 636 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-06 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-06 == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-terminology-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG C. Tschudin 3 Internet-Draft University of Basel 4 Intended status: Informational C. Wood 5 Expires: June 29, 2018 University of California Irvine 6 December 26, 2017 8 File-Like ICN Collection (FLIC) 9 draft-irtf-icnrg-flic-01 11 Abstract 13 This document describes a bare bones "index table"-approach for 14 organizing a set of ICN data objects into a large, File-Like ICN 15 Collection (FLIC). 17 At the core of this collection is a so called manifest which acts as 18 the collection's root node. The manifest contains an index table 19 with pointers, each pointer being a hash value pointing to either a 20 final data block or another index table node. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 29, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. FLIC as a Distributed Data Structure . . . . . . . . . . 3 58 1.2. Design goals . . . . . . . . . . . . . . . . . . . . . . 3 59 2. File-Like ICN Collection (FLIC) Format . . . . . . . . . . . 4 60 2.1. Use of hash-valued pointers . . . . . . . . . . . . . . . 5 61 2.2. Creating a FLIC data structure . . . . . . . . . . . . . 6 62 2.3. Reconstructing the collection's data . . . . . . . . . . 7 63 2.4. Metadata and Extensibility . . . . . . . . . . . . . . . 8 64 2.5. FLIC Encryption . . . . . . . . . . . . . . . . . . . . . 9 65 2.6. Locating FLIC leaf and manifest nodes . . . . . . . . . . 10 66 3. Advanced uses of FLIC manifests . . . . . . . . . . . . . . . 10 67 3.1. Seeking . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.2. Block-level de-duplication . . . . . . . . . . . . . . . 12 69 3.3. Growing ICN collections . . . . . . . . . . . . . . . . . 12 70 3.4. Re-publishing a FLIC under a new name . . . . . . . . . . 12 71 3.5. Data Chunks of variable size . . . . . . . . . . . . . . 13 72 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.1. Example Encoding for CCNx1.0 . . . . . . . . . . . . . . 13 74 4.2. Example Encoding for NDN . . . . . . . . . . . . . . . . 14 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 ICN architectures such as Content-Centric Networking (CCN) 84 [I-D.irtf-icnrg-ccnxsemantics] and Named Data Networking 85 [NamedDataNetworking] are well suited for static content 86 distribution. Each piece of (possibly immutable) static content is 87 assigned a name by its producer. Consumers fetch this content using 88 said name. Optionally, consumers may specify the full name of 89 content, which includes its name and a unique (with overwhelming 90 probability) cryptographic digest of said content. (See 91 [I-D.irtf-icnrg-terminology] for a formal definition of "full name".) 93 To enable requests with full names, consumers need a priori knowledge 94 of content digests. Manifests, or catalogs, are data structures 95 commonly proposed to transport this information. Typically, 96 manifests are signed content objects (data) which carry a collection 97 of hash digests. However, as content objects, manifests themselves 98 may be fetched by full name. Thus, manifests may contain hash 99 digests of, or pointers to, other manifests or content objects. A 100 collection of manifests and content objects represents a large piece 101 of application data, e.g., one that cannot otherwise fit in a single 102 content object. 104 Structurally, this relationship between manifests and content objects 105 is reminiscent of the UNIX inode concept with index tables and memory 106 pointers. In this document, we specify a simple, yet extensible, 107 manifest data structure called FLIC - File-Like ICN Collection. FLIC 108 is suitable for ICNs such as CCN and NDN. We describe the FLIC 109 design, grammar, and various use cases, e.g., seeking, de- 110 duplication, extension, and variable-sized encoding. We also include 111 FLIC encoding examples for CCN and NDN. 113 1.1. FLIC as a Distributed Data Structure 115 FLIC is a distributed data structure best illustrated by the 116 following picture. 118 root manifest 119 .------------------------------------. 120 | optional name: | 121 | /icn/name/of/this/flic | 122 | | 123 | HashGroup (HG): | 124 | optional metadata: | 125 | overall digest, locator, etc. | .------. 126 | hash-valued (data) pointer ---------> | data | 127 | ... | `------' sub manifest 128 | hash-valued (manifest) pointer ----. .------------------. 129 | | `--> | -----> 130 | optional additional HashGroups .. | | -----> 131 | | `------------------' 132 | optional signature | 133 `------------------------------------' 135 Figure 1: A FLIC manifest and its directed acyclic graph 137 1.2. Design goals 139 o Copy the proven UNIX inode concept: 141 * index tables and memory pointers 143 o Adaption to ICN: 145 * hash values instead of block numbers, unique with high 146 probability 148 o Advantages (over non-manifest collections): 150 * single root manifest signature covers all elements of the full 151 collection, including intermediate sub manifests 153 * eliminate reference to chunk numbering schemata (hash values 154 only) 156 * supports block-level de-duplication (can lead to a directed 157 acyclic graph, or DAG, instead of a tree) 159 o Limitations 161 * All data leafs must be present at manifest creation time 162 (otherwise one cannot compute the pointers) 164 o Potential extensions (for study): 166 * Enhance the manifest such that it can serve as a "database 167 cursor" or as a cursor over a time series, e.g. having entries 168 for "previous" and "next" collections. 170 2. File-Like ICN Collection (FLIC) Format 172 The core of a FLIC node is the sequence of "hash groups". Each hash 173 group (HG) consists of a sequence of pointers. Pointers are 174 cryptographic HashValues encoded according 175 [I-D.irtf-icnrg-ccnxmessages]. Specifically, a HashValue specifies a 176 hash algorithm and digest value. A HashGroup can contain a metadata 177 section to help a reader to optimize content retrieval via, e.g., 178 block size of leaf nodes, total size, overall digest, etc. 180 Based on this description, FLIC encoding in EBN notation is as 181 follows: 183 Node := Name? Metadata? (Opqaue | HashGroup+) 184 HashGroup := MetaData? Ptr+ 186 Ptr := HashValue 188 HashValue := See {{I-D.irtf-icnrg-ccnxmessages}} 190 MetaData := Property* 191 Property := SizePerPtr | SecurityCtx | Locator | OverallByteCount | OverallDataDigest | ... 193 Note that all sizes are 64-bit unsigned integers. 195 A description of each field follows: 197 o Node: A structure with optional name, metadata, and collection of 198 hashgroups or an opaque, encrypted blob. Encrypted FLIC nodes are 199 discussed in Section Section 2.5. 201 o HashGroup: A collection of pointers (Ptr) and optional metadata. 203 o Ptr: A wrapper around a HashValue. 205 o HashValue: A structure specifying hash algorithm and cryptographic 206 hash digest. 208 o MetaData: A collection of Property values. 210 o Property: A well-defined FLIC extension. By default, SizePerPtr, 211 SecurityCtx, Locator, OverallByteCount, and OverallDataDigest 212 property extensions are supported. Each of these properties are 213 described in more detail in Section Section 2.4. 215 Lastly, no ICN objects used in FLIC are allowed to be chunked, 216 including the (sub-) manifests. The smallest possible complete 217 manifest contains one HashGroup with one pointer to an ICN object. 219 2.1. Use of hash-valued pointers 221 FLIC's tree data structure is a generalized index table as it is 222 known from file systems. The pointers, which in an OS typically are 223 hard disk block numbers, are replaced by hash values of other ICN 224 objects. These ICN objects contain either other manifest nodes, or 225 leaf nodes. Leafs contain the actual data of the collection. Each 226 pointer explicitly indicates the amount of application data bytes 227 contained by the referred object. For example, the size of a data 228 pointer (to a leaf) represents the size of the leaf's content object 229 payload. Conversely, the size of a manifest pointer represents the 230 total size of all pointers contained in that manifest. 232 FLIC makes use of "nameless ICN object" where the network is tasked 233 with fetching an object based on its digest only. The interest for 234 such an object consists of a routing hint (locator) plus the given 235 digest value. 237 2.2. Creating a FLIC data structure 239 Starting from the original content, the corresponding byte array is 240 sliced into chunks. Each chunk is encoded as a data object, 241 according the ICN suite. For each resulting data object, the hash 242 value is computed. Groups of consecutive objects are formed and the 243 corresponding hash values collected in manifests, which are also 244 encoded. The hash values of the manifest objects replace the hash 245 values of the covered leaf nodes, thus reducing the number of hash 246 values. This process of hash value collection and replacement is 247 repeated until only one (root) manifest is left. 249 data1 <-- h1 - - - - - - - - - - - - \ 250 data2 <-- h2 \ root mfst 251 ... mfst 1 <-- hN+1 \ / 252 dataJ <-- hJ / mfst2 <-- hN+2 253 ... / 254 dataN <-- hN - - - - - - / 256 Of special interest are "skewed trees" where a pointer to a manifest 257 may only appear as last pointer of (sub-) manifests. Such a tree 258 becomes a sequential list of manifests with a maximum of datapointers 259 per manifest packet. Beside the tree shape we also show this data 260 structure in form of packet content where D stands for a data pointer 261 and M is the hash of a manifest packet. 263 data1 <-- h1 - - - - - - - - root mfst 264 ... / 265 dataJ-1 <-- hJ-1 / 266 dataJ <-- hJ - - mfst1 <-- hN+1 / 267 ... / 268 dataN <-- hN - / 270 DDDDDDM--> DDDDDDM--> ....... DDDDDDM--> DDDDDDD 272 A pseudo code description for producing a skewed tree follows below. 274 Input: 275 Application data D of size |D| (bytes) 276 Block size B (in bytes) 277 Output: 278 FLIC root node R 279 Algo: 280 n = number of leaf nodes = ceil(|D| / B) 281 k = number of (encoded) hash values fitting in a block of size B 282 H[1..n] = array of hash values 283 initialized with the data hash values for data chunks 1..n 284 While n > k do 285 a) create manifest M with a HashGroup 286 b) append to the HashGroup in M all hash values H[n-k+1..n] 287 c) n = n - k + 1 288 d) H[n] = manifest hash value of M 289 Create root manifest R with a HashGroup 290 Add to the HashGroup of R all hash values H[1..n] 291 Optionally: add name to R, sign manifest R 292 Output R 294 Obtaining with each manifest a maximum of data pointers is beneficial 295 for keeping the download pipeline filled. On the other hand, this 296 tree doesn't support well random access to arbitrary byte positions: 297 All data pointers coming before that offset have to be fetched before 298 locating the block of interest. For random access, binary trees 299 (where both subtrees of a node cover half of the content bytes) are 300 better suited. This can be combined with the "skewed tree" approach: 301 Manifests of intermediate nodes are filled with data pointers except 302 for the last two slots. The second last slot points to a manifest 303 for the "first half" of the left content, the last slots then points 304 to a manifest for the rest. 306 root manifest= DDDDDMM 307 ____________/ \_____ 308 / \ 309 DDDDDMM DDDDDMM 310 _______/ \ _____/ \ 311 / \ / \ 312 DDDDDDD DDDDDDD DDDDDDD DDDDDDD 314 This can be generalized to k-ary trees by allocating k pointers per 315 manifest instead of 2. 317 2.3. Reconstructing the collection's data 319 To fetch the data associated with a given FLIC (sub-) manifest, the 320 receiver sequentially works through all entries found in the 321 HashGroups and issues corresponding hash-based interests. In case of 322 a data hash pointer, the received content object is appended. In 323 case of a manifest hash pointer, this procedure is called recursively 324 for the received manifest. In other words, the collection data is 325 represented as the concatenation of data leaves from this _pre-order_ 326 depth-first search (DFS) traversal strategy of the manifest tree. 327 (Currently, pre-order DFS is the only supported traversal strategy.) 328 This procedure works regardless of the tree's shape. 330 A pseudo code description for fetching is below. 332 Input: 333 Root manifest R 334 Output: 335 Application data D 336 Algo: 337 global D = [] 338 DFS(R) 339 Output D 341 where: 343 procedure DFS(M) 344 { 345 L: 346 H = sequence of hash valued pointers of M 347 foreach p in H do: 348 if p is a data pointer then 349 data = lookup(p) 350 Append data to D 351 else 352 M = lookup(p) 353 if p is last element in H then 354 goto L; // tail recursion 355 DFS(M) 356 } 358 The above DFS code works for FLIC manifest trees of arbitrary shape. 359 In case of a skewed tree, no recursion is needed and a single 360 instance of the DFS procedure suffices (i.e., one uses tail 361 recursion). 363 2.4. Metadata and Extensibility 365 In FLIC, metadata is linked to FLIC nodes or HashGroups informs FLIC 366 retrievers about data properties. Example metadata includes overall 367 data bytes and overall hash digest (this is akin to a Merkle hash). 368 The intent of such metadata is to enable an in-network retriever to 369 optimize its operation. 371 The list of available metadata is below. 373 * SizePerPtr - size of application data encoded in each HashGroup pointer. 375 * SecurityCtx - pointer to an application-specific security context blob. 376 For example, this point to a content object carrying an encrypted symmetric 377 key used to decrypt the parent FLIC node. 379 * Locator - provides a new routing hint (name prefix) where the 380 chunks of this hash group can be retrieved from. The default is to 381 use the locator of the root manifest. 383 * OverallByteCount - indicates the total number of *application 384 data bytes* contained in a single HashGroup. This does not include 385 bytes consumed by child manifests. This value is equal to the sum of 386 all pointer sizes contained in the HashGroup. 388 * OverallDataDigest - expresses the overall digest of all application 389 data contained in the HashGroup. 391 HashGroups SHOULD carry the SizePerPtr metadata property. This value 392 indicates the total number of application bytes contained within each 393 pointer in the hash group _except for the last pointer._ 395 Applications MAY extend FLIC via new metadata values. Example 396 extensions include: media type, timestamp, author, copyright, etc. 397 Each new metadata extension MUST be allocated a unique codepoint to 398 avoid parsing errors. 400 2.5. FLIC Encryption 402 FLIC nodes may be encrypted using an application-specific scheme. 403 When encrypted with external keying material, FLICs SHOULD carry a 404 SecurityCtx metadata value which points to application-specific 405 keying material. Receivers SHOULD fetch this context and use it to 406 obtain one or more keys needed to decrypt FLIC nodes. Upon decrypt, 407 FLIC nodes MUST be parsed as plaintext FLIC nodes. That is, it is an 408 error if FLIC node decryption yields a structure that is not a FLIC 409 node. Receivers must be able to decrypt content objects pointed to 410 from an encrypted FLIC node using keying material associated with 411 said FLIC node. (Recall that content objects do not carry any 412 metadata fields, thus, any security-related information such as 413 keying material must be delivered by parent FLIC nodes or some other 414 means.) 416 2.6. Locating FLIC leaf and manifest nodes 418 The optional name of a manifest is a mere decoration and has no 419 locator functionality at all: All objects pointed to by a manifest 420 are retrieved from the location where the manifest itself was 421 obtained from (which is not necessarily its name). Example: 423 Objects: 424 manifest(name=/a/b/c, ptr=h1, ptr=hN) - has hash h0 425 nameless(data1) - has hash h1 426 ... 427 nameless(dataN) - has hash hN 429 Query for the manifest: 430 interest(name=/the/locator/hint, implicitDigest=h0) 432 In this example, the name "/a/b/c" does NOT override "/the/locator/ 433 hint" i.e., after having obtained the manifest, the retriever will 434 issue requests for 436 interest(name=/the/locator/hint, implicitDigest=h1) 437 ... 438 interest(name=/the/locator/hint, implicitDigest=hN) 440 Using the locator metadata entry, this behavior can be changed: 442 Objects: 443 manifest(name=/a/b/c, 444 hashgroup(loc=/x/y/z, ptr=h1) 445 hashgroup(ptr=h2) - has hash h0 446 nameless(data1) - has hash h1 447 nameless(data2) - has hash h2 449 Queries: 450 interest(name=/the/locator/hint, implicitDigest=h0) 451 interest(name=/x/y/z, implicitDigest=h1) 452 interest(name=/the/locator/hint, implicitDigest=h2) 454 3. Advanced uses of FLIC manifests 456 The FLIC mechanics has uses cases beyond keeping together a set of 457 data objects, such as: seeking, block-level de-duplication, re- 458 publishing under a new name, growing ICN collections, and supporting 459 FLICs with different block sizes. 461 3.1. Seeking 463 Fast seeking (without having to sequentially fetch all content) works 464 by skipping over entries for which we know their size. The following 465 expression shows how to compute the byte offset of the data pointed 466 at by pointer P_i, offset_i. In this formula, let P_i represent the 467 Size value of the i-th pointer. 469 offset_i = \sum_{i = 1}^{i - 1} P_i.size 471 With this offset, seeking is done as follows: 473 Input: seek_pos P, a FLIC manifest with a hash group having N entries 474 Output: pointer index i and byte offset o, or out-of-range error 475 Algo: 476 offset = 0 477 for i in 1..N do 478 if (P < P_i.size) 479 return (i, P - offset) 480 offset += P_i.size 481 return out-of-range 483 Seeking in a BlockHashGroup is different since offsets can be quickly 484 computed. This is because the size of each pointer P_i except the 485 last is equal to the SizePerPtr value. For a BlockHashGroup with N 486 pointers, OverallByteCount D, and SizePerPointer L, the size of P_i 487 is equal to the following: 489 D - ((i - 1) * L) 491 In a BlockHashGroup with k pointers, the size of P_k is equal to: 493 D - L * (k - 1) 495 Using these, the seeking algorithm can be thus simplified to the 496 following: 498 Input: seek_pos P, a FLIC manifest with a hash group having 499 OverallByteCount S and SizePerPointer L. 500 Output: pointer index i and byte offset o, or out-of-range error 501 Algo: 502 if (P > S) 503 return out-of-range 504 i = floor(P / L) 505 if (i > N) 506 return out-of-range # bad FLIC encoding 507 o = P mod L 508 return (i, o) 510 Note: In both cases, if the pointer at position i is a manifest 511 pointer, this algorithm has to be called once more, seeking to 512 seek_pos o inside that manifest. 514 3.2. Block-level de-duplication 516 Consider a huge file, e.g. an ISO image of a DVD or program in binary 517 form, that had previously been FLIC-ed but now needs to be patched. 518 In this case, all existing encoded ICN chunks can remain in the 519 repository while only the chunks for the patch itself is added to a 520 new manifest data structure, as is shown in the picture below. For 521 example, the venti [1] archival file system of Plan9 uses this 522 technique. 524 old_mfst - - > h1 --> oldData1 <-- h1 < - - new_mfst 525 \ - > h2 --> oldData2 <-- h2 < - - / 526 \ replace3 <-- h5 < - -/ 527 \- > h3 --> oldData3 / 528 \ > h4 --> oldData4 <-- h4 < - / 530 3.3. Growing ICN collections 532 A log file, for example, grows over time. Instead of having to re- 533 FLIC the grown file it suffices to construct a new manifest with a 534 manifest pointer to the old root manifest plus the sequence of data 535 hash pointers for the new data (or additional sub-manifests if 536 necessary). Note that this tree will not be skewed (anymore). 538 old data < - - - mfst_old <-- h_old - - mfst_new 539 / 540 new data1 <-- h_1 - - - - - - - - -/ 541 new data2 / 542 ... / 543 new dataN <-- h_N - - - - - - - -/ 545 3.4. Re-publishing a FLIC under a new name 547 It can happen that a publisher's namespace is part of a service 548 provider's prefix. When switching provider, the publisher may want 549 to republish the old data under a new name. This can easily be 550 achieved with a single nameless root manifest for the large FLIC plus 551 arbitrarily many per-name manifests (which are signed by whomever 552 wants to publish this data): 554 data < - nameless_mfst() <-- h < - mfst(/com/parc/east/the/flic) 555 < - mfst(/com/parc/west/old/the/flic) 556 < - mfst(/internet/archive/flic234) 558 Note that the hash computation (of h) only requires reading the 559 nameless root manifest, not the entire FLIC. 561 This example points out the problem of HashGroups having locator 562 metadata elements: A retriever would be urged to follow these hints 563 which are "hardcoded" deep inside the FLIC but might have become 564 outdated. We therefore recommend to name FLIC manifests only at the 565 highest level (where these names have no locator function). Child 566 nodes in a FLIC manifest should not be named as these names serve no 567 purpose except retrieving a sub-tree's manifest by name, if would be 568 required. 570 3.5. Data Chunks of variable size 572 If chunks do not have regular (block) sizes, the HashGroup can be 573 used to still convey to a reader the length of the chunks at the 574 manifest level. (This can be computed based on the size of pointers, 575 but the metadata field makes this determination simpler.) Example 576 use cases would be chunks each carrying a single ASCII line as 577 entered by a user or a database with variable length records mapped 578 to chunks. 580 M = (manifest 581 (hashgroup((metadata(SizePerPtr=4096)) (dataptr=h1)) 582 (hashgroup((metadata(SizePerPtr=1500)) (dataptr=h2)) 583 ... 584 ) 586 4. Encoding 588 We express the packet encoding of manifests in a symbolic expression 589 style in order to show the TLV structure and the chosen type values. 590 In this notation, a TLV's type is a combination of "SymbolicName/ 591 Tvalue", Length is not shown and Values are sub-expressions. 592 Moreover, we populate the data structure with all possible entries 593 and omit repetition. 595 4.1. Example Encoding for CCNx1.0 597 [FIXED_HEADER OCTET[8]] 598 (ManifestMsg/T_MANIFEST 599 (Name/T_NAME ...) 600 (HashGroup/T_HASHGROUP 601 (MetaData/T_HASHGROUP_METADATA 602 (HGLocator/T_HASHGROUP_METADATA_LOCATOR (T_NAME ...)) 603 (HGOverallByteCount/T_HASHGROUP_METADATA_BYTECOUNT INT) 604 (HGOverallDataDigest/T_HASHGROUP_METADATA_DATADIGEST OCTET[32]) 605 ) 606 (SizeDataPtr/T_HASHGROUP_SIZEDATAPTR OCTET[8] (T_HASH ...)) 607 (SizeMfstPtr/T_HASHGROUP_SIZEMANIFESTPTR OCTET[8] (T_HASH ...)) 608 ) 609 (BlockHashGroup/T_BLOCKHASHGROUP 610 (MetaData/T_HASHGROUP_METADATA (...)) 611 (DataPtr/T_HASHGROUP_DATAPTR OCTET[32] (T_HASH ...)) 612 (MfstPtr/T_HASHGROUP_MANIFESTPTR OCTET[32] (T_HASH ...)) 613 ) 614 ) 616 Interest: name is locator, use objHashRestriction as selector. 618 4.2. Example Encoding for NDN 620 The assigned NDN content type value for FLIC manifests is 1024 621 (0x400). 623 (Data/0x6 624 (Name/0x7 ...) 625 (MetaInfo/0x14 626 (ContentType/0x18 0x0400) 627 ) 628 (Content/0x15 629 (HashGroup/0xC0 630 (MetaInfo/0x14 631 (LocatorNm/0xC3 (NameComp/0x8 ...)) 632 (OverallDataDigest/0xC4 OCTET[32]) 633 (OverallByteCount/0xC5 INT) 634 ) 635 (DataPtr/0xC1 OCTET[8] OCTET[32]) 636 (MfstPtr/0xC2 OCTET[8] OCTET[32]) 637 (SizeDataPtr/0xC3 OCTET[32]) 638 (SizeMfstPtr/0xC4 OCTET[32]) 639 ) 640 ) 641 (SignatureInfo/0x16 ...) 642 (SignatureValue/0x17 ...) 643 ) 644 Interest: name is locator, use implicitDigest name component as 645 selector. 647 5. Security Considerations 649 None. 651 6. References 653 6.1. Normative References 655 [I-D.irtf-icnrg-ccnxmessages] 656 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 657 Format", draft-irtf-icnrg-ccnxmessages-06 (work in 658 progress), October 2017. 660 [I-D.irtf-icnrg-ccnxsemantics] 661 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 662 draft-irtf-icnrg-ccnxsemantics-06 (work in progress), 663 October 2017. 665 [I-D.irtf-icnrg-terminology] 666 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 667 D., and C. Tschudin, "Information-Centric Networking 668 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 669 terminology-00 (work in progress), December 2017. 671 [NamedDataNetworking] 672 PARC, ., LinkedIn, ., and . PARC, "CCNx Messages in TLV 673 Format", n.d., . 676 6.2. URIs 678 [1] http://plan9.bell-labs.com/sys/doc/venti/venti.pdf 680 Authors' Addresses 682 Christian Tschudin 683 University of Basel 685 Email: christian.tschudin@unibas.ch 687 Christopher A. Wood 688 University of California Irvine 690 Email: woodc1@uci.edu