idnits 2.17.1 draft-irtf-icnrg-icnlowpan-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-gundogan-icnrg-ccnx-timetlv-00 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group C. Gundogan 3 Internet-Draft TC. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: May 3, 2021 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 October 30, 2020 13 ICN Adaptation to LoWPAN Networks (ICN LoWPAN) 14 draft-irtf-icnrg-icnlowpan-09 16 Abstract 18 This document defines a convergence layer for CCNx and NDN over IEEE 19 802.15.4 LoWPAN networks. A new frame format is specified to adapt 20 CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For 21 that, syntactic and semantic changes to the TLV-based header formats 22 are described. To support compatibility with other LoWPAN 23 technologies that may coexist on a wireless medium, the dispatching 24 scheme provided by 6LoWPAN is extended to include new dispatch types 25 for CCNx and NDN. Additionally, the fragmentation component of the 26 6LoWPAN dispatching framework is applied to ICN chunks. In its 27 second part, the document defines stateless and stateful compression 28 schemes to improve efficiency on constrained links. Stateless 29 compression reduces TLV expressions to static header fields for 30 common use cases. Stateful compression schemes elide state local to 31 the LoWPAN and replace names in data packets by short local 32 identifiers. 34 This document is a product of the IRTF Information-Centric Networking 35 Research Group (ICNRG). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 3, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 6 71 3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 6 72 3.2. Stateless Header Compression . . . . . . . . . . . . . . 6 73 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 8 74 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 8 75 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 8 76 4.1.1. Dispatch Extensions . . . . . . . . . . . . . . . . . 10 77 4.2. Adaptation Layer Fragmentation . . . . . . . . . . . . . 10 78 5. Space-efficient Message Encoding for NDN . . . . . . . . . . 11 79 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 11 80 5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 12 81 5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 13 82 5.3.1. Uncompressed Interest Messages . . . . . . . . . . . 13 83 5.3.2. Compressed Interest Messages . . . . . . . . . . . . 13 84 5.3.3. Dispatch Extension . . . . . . . . . . . . . . . . . 17 85 5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 17 86 5.4.1. Uncompressed Data Messages . . . . . . . . . . . . . 17 87 5.4.2. Compressed Data Messages . . . . . . . . . . . . . . 18 88 5.4.3. Dispatch Extension . . . . . . . . . . . . . . . . . 20 89 6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 21 90 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 21 91 6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 21 92 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 21 93 6.3.1. Uncompressed Interest Messages . . . . . . . . . . . 21 94 6.3.2. Compressed Interest Messages . . . . . . . . . . . . 22 95 6.3.3. Dispatch Extension . . . . . . . . . . . . . . . . . 28 96 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 28 97 6.4.1. Uncompressed Content Objects . . . . . . . . . . . . 28 98 6.4.2. Compressed Content Objects . . . . . . . . . . . . . 29 99 6.4.3. Dispatch Extension . . . . . . . . . . . . . . . . . 32 100 7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 33 101 8. Stateful Header Compression . . . . . . . . . . . . . . . . . 34 102 8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 34 103 8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 35 104 8.3. Integrating Stateful Header Compression . . . . . . . . . 37 105 9. ICN LoWPAN Constants and Variables . . . . . . . . . . . . . 37 106 10. Implementation Report and Guidance . . . . . . . . . . . . . 37 107 10.1. Preferred Configuration . . . . . . . . . . . . . . . . 37 108 10.2. Further Experimental Deployments . . . . . . . . . . . . 38 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 110 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 111 12.1. Reserving Space in the 6LoWPAN Dispatch Type Field 112 Registry . . . . . . . . . . . . . . . . . . . . . . . . 40 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 115 13.2. Informative References . . . . . . . . . . . . . . . . . 41 116 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 45 117 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 118 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 45 119 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 46 120 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 48 121 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 48 122 A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 49 123 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 126 1. Introduction 128 The Internet of Things (IoT) has been identified as a promising 129 deployment area for Information Centric Networks (ICN), as 130 infrastructureless access to content, resilient forwarding, and in- 131 network data replication demonstrated notable advantages over the 132 traditional host-to-host approach on the Internet [NDN-EXP1], 133 [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate 134 mapping to link layer technologies has a large impact on the 135 practical performance of an ICN. This will be even more relevant in 136 the context of IoT communication where nodes often exchange messages 137 via low-power wireless links under lossy conditions. In this memo, 138 we address the base adaptation of data chunks to such link layers for 139 the ICN flavors NDN [NDN] and CCNx [RFC8569], [RFC8609]. 141 The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and 142 lossy networks (see "LLN" in [RFC7228]), in which devices are 143 typically battery-operated and constrained in resources. 144 Characteristics of LLNs include an unreliable environment, low 145 bandwidth transmissions, and increased latencies. IEEE 802.15.4 146 admits a maximum physical layer packet size of 127 bytes. The 147 maximum frame header size is 25 bytes, which leaves 102 bytes for the 148 payload. IEEE 802.15.4 security features further reduce this payload 149 length by up to 21 bytes, yielding a net of 81 bytes for CCNx or NDN 150 packet headers, signatures and content. 152 6LoWPAN [RFC4944], [RFC6282] is a convergence layer that provides 153 frame formats, header compression and adaptation layer fragmentation 154 for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation 155 introduces a dispatching framework that prepends further information 156 to 6LoWPAN packets, including a protocol identifier for payload and 157 meta information about fragmentation. 159 Prevalent Type-Length-Value (TLV) based packet formats such as in 160 CCNx and NDN are designed to be generic and extensible. This leads 161 to header verbosity which is inappropriate in constrained 162 environments of IEEE 802.15.4 links. This document presents ICN 163 LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. 164 ICN LoWPAN compresses packet headers of CCNx as well as NDN and 165 allows for an increased effective payload size per packet. 166 Additionally, reusing the dispatching framework defined by 6LoWPAN 167 enables compatibility between coexisting wireless deployments of 168 competing network technologies. This also allows to reuse the 169 adaptation layer fragmentation scheme specified by 6LoWPAN for ICN 170 LoWPAN. 172 ICN LoWPAN defines a more space efficient representation of CCNx and 173 NDN packet formats. This syntactic change is described for CCNx and 174 NDN separately, as the header formats and TLV encodings differ 175 notably. For further reductions, default header values suitable for 176 constrained IoT networks are selected in order to elide corresponding 177 TLVs. Experimental evaluations of the ICN LoWPAN header compression 178 schemes in [ICNLOWPAN] illustrate a reduced message overhead, a 179 shortened message airtime, and an overall decline in power 180 consumption for typical Class 2 [RFC7228] devices compared to 181 uncompressed ICN messages. 183 In a typical IoT scenario (see (Figure 1)), embedded devices are 184 interconnected via a quasi-stationary infrastructure using a border 185 router (BR) that connects the constrained LoWPAN network by some 186 Gateway with the public Internet. In ICN based IoT networks, non- 187 local Interest and Data messages transparently travel through the BR 188 up and down between a Gateway and the embedded devices situated in 189 the constrained LoWPAN. 191 |Gateway Services| 192 ------------------------- 193 | 194 ,--------, 195 | | 196 | BR | 197 | | 198 '--------' 199 LoWPAN 200 O O 201 O 202 O O embedded 203 O O O devices 204 O O 206 Figure 1: IoT Stub Network 208 The document has received fruitful reviews by members of the ICN 209 community and the research group (see Acknowledgments) for a period 210 of two years. It is the consensus of ICNRG that this document should 211 be published in the IRTF Stream of the RFC series. This document 212 does not constitute an IETF standard. 214 2. Terminology 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in RFC 2119 [RFC2119]. 219 The use of the term, "silently ignore" is not defined in RFC 2119. 220 However, the term is used in this document and can be similarly 221 construed. 223 This document uses the terminology of [RFC7476], [RFC7927], and 224 [RFC7945] for ICN entities. 226 The following terms are used in the document and defined as follows: 228 ICN LoWPAN: Information-Centric Networking over Low-power Wireless 229 Personal Area Network 231 LLN: Low-Power and Lossy Network 233 CCNx: Content-Centric Networking Architecture 235 NDN: Named Data Networking Architecture 237 byte: synonym for octet 238 nibble: synonym for 4 bits 240 time-value: a time offset measured in seconds 242 time-code: an 8-bit encoded time-value 244 3. Overview of ICN LoWPAN 246 3.1. Link-Layer Convergence 248 ICN LoWPAN provides a convergence layer that maps ICN packets onto 249 constrained link-layer technologies. This includes features such as 250 link-layer fragmentation, protocol separation on the link-layer 251 level, and link-layer address mappings. The stack traversal is 252 visualized in Figure 2. 254 Device 1 Device 2 255 ,------------------, Router ,------------------, 256 | Application . | __________________ | ,-> Application | 257 |----------------|-| | NDN / CCNx | |-|----------------| 258 | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | 259 |----------------|-| |-|--------------|-| |-|----------------| 260 | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | 261 |----------------|-| |-|--------------|-| |-|----------------| 262 | Link-Layer | | | | Link-Layer | | | | Link-Layer | 263 '----------------|-' '-|--------------|-' '-|----------------' 264 '--------' '---------' 266 Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 268 Section 4 of this document defines the convergence layer for IEEE 269 802.15.4. 271 3.2. Stateless Header Compression 273 ICN LoWPAN also defines a stateless header compression scheme with 274 the main purpose of reducing header overhead of ICN packets. This is 275 of particular importance for link-layers with small MTUs. The 276 stateless compression does not require pre-configuration of global 277 state. 279 The CCNx and NDN header formats are composed of Type-Length-Value 280 (TLV) fields to encode header data. The advantage of TLVs is its 281 native support of variably structured data. The main disadvantage of 282 TLVs is the verbosity that results from storing the type and length 283 of the encoded data. 285 The stateless header compression scheme makes use of compact bit 286 fields to indicate the presence of optional TLVs in the uncompressed 287 packet. The order of set bits in the bit fields corresponds to the 288 order of each TLV in the packet. Further compression is achieved by 289 specifying default values and reducing the range of certain header 290 fields. 292 Figure 3 demonstrates the stateless header compression idea. In this 293 example, the first type of the first TLV is removed and the 294 corresponding bit in the bit field is set. The second TLV represents 295 a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type and 296 the length fields are removed. The third TLV represents a boolean 297 TLV (e.g., the MustBeFresh selector in NDN) for which the type, 298 length and the value fields are elided. 300 Uncompressed: 302 Variable-length TLV Fixed-length TLV Boolean TLV 303 ,-----------------------,-----------------------,-------------, 304 +-------+-------+-------+-------+-------+-------+------+------+ 305 | TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN | 306 +-------+-------+-------+-------+-------+-------+------+------+ 308 Compressed: 310 +---+---+---+---+---+---+---+---+ 311 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field 312 +---+---+---+---+---+---+---+---+ 313 | | | 314 ,--' '----, '- Boolean Value 315 | | 316 +-------+-------+-------+ 317 | LEN | VAL | VAL | 318 +-------+-------+-------+ 319 '---------------'-------' 320 Var-len Value Fixed-len Value 322 Figure 3: Compression using a compact bit field - bits encode the 323 inclusion of TLVs. 325 Stateless TLV compression for NDN is defined in Section 5. Section 6 326 defines the stateless TLV compression for CCNx. 328 The extensibility of this compression is described in Section 4.1.1 329 and allows future documents to update the compression rules outlined 330 in this manuscript. 332 3.3. Stateful Header Compression 334 ICN LoWPAN further employs two orthogonal stateful compression 335 schemes for packet size reductions which are defined in Section 8. 336 These mechanisms rely on shared contexts that are either distributed 337 and maintained in the entire LoWPAN, or are generated on-demand hop- 338 wise on a particular Interest-data path. 340 The shared context identification is defined in Section 8.1. The 341 hop-wise name compression "en-route" is specified in Section 8.2. 343 4. IEEE 802.15.4 Adaptation 345 4.1. LoWPAN Encapsulation 347 The IEEE 802.15.4 frame header does not provide a protocol identifier 348 for its payload. This causes problems of misinterpreting frames when 349 several network layers coexist on the same link. To mitigate errors, 350 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 351 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation 352 headers can precede the actual payload and each encapsulation header 353 is identified by a dispatch type. 355 [RFC8025] further specifies dispatch pages to switch between 356 different contexts. When a LoWPAN parser encounters a "Page switch" 357 LoWPAN encapsulation header, then all following encapsulation headers 358 are interpreted by using a dispatch table as specified by the "Page 359 switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This 360 document uses page TBD1 ("1111 TBD1 (0xFTBD1)") for ICN LoWPAN. 362 The base dispatch format (Figure 4) is used and extended by CCNx and 363 NDN in Section 5 and Section 6. 365 0 1 2 ... 366 +---+---+----------- 367 | C | P | M | 368 +---+---+----------- 370 Figure 4: Base dispatch format for ICN LoWPAN 372 C: Compression 374 0: The message is compressed. 376 1: The message is uncompressed. 378 P: Protocol 379 0: The included protocol is NDN. 381 1: The included protocol is CCNx. 383 M: Message Type 385 0: The payload contains an Interest message. 387 1: The payload contains a Data message. 389 ICN LoWPAN frames with compressed CCNx and NDN messages (C=0) use the 390 extended dispatch format in Figure 5. 392 0 1 2 3 4 ... 393 +---+---+---+---+---+--- 394 | 0 | P | M |CID|EXT| 395 +---+---+---+---+---+--- 397 Figure 5: Extended dispatch format for compressed ICN LoWPAN 399 CID: Context Identifier 401 0: No context identifiers are present. 403 1: Context identifier(s) are present (see Section 8.1). 405 EXT: Extension 407 0: No extension bytes are present. 409 1: Extension byte(s) are present (see Section 4.1.1). 411 The encapsulation format for ICN LoWPAN is displayed in Figure 6. 413 +------...------+------...-----+--------+-------...-------+-----... 414 | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / 415 +------...------+------...-----+--------+-------...-------+-----... 417 Figure 6: LoWPAN Encapsulation with ICN-LoWPAN 419 IEEE 802.15.4: The IEEE 802.15.4 header. 421 RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 422 of [RFC4944] 424 Page: Page Switch. TBD1 for ICN LoWPAN. 426 ICN LoWPAN: Dispatches as defined in Section 5 and Section 6. 428 Payload: The actual (un-)compressed CCNx or NDN message. 430 4.1.1. Dispatch Extensions 432 Extension bytes allow for the extensibility of the initial 433 compression rule set. The base format for an extension byte is 434 depicted in Figure 7. 436 0 1 2 3 4 5 6 7 437 +---+---+---+---+---+---+---+---+ 438 | - | - | - | - | - | - | - |EXT| 439 +---+---+---+---+---+---+---+---+ 441 Figure 7: Base format for dispatch extensions. 443 EXT: Extension 445 0: No other extension byte follows. 447 1: A further extension byte follows. 449 Extension bytes are numbered according to their order. Future 450 documents MUST follow the naming scheme "EXT_0, EXT_1, ...", when 451 updating or referring to a specific dispatch extension byte. 452 Amendments that require an exchange of configurational parameters 453 between devices SHOULD use manifests to encode structured data in a 454 well-defined format, as, e.g., outlined in [I-D.irtf-icnrg-flic]. 456 4.2. Adaptation Layer Fragmentation 458 Small payload sizes in the LoWPAN require fragmentation for various 459 network layers. Therefore, Section 5.3 of [RFC4944] defines a 460 protocol-independent fragmentation dispatch type, a fragmentation 461 header for the first fragment, and a separate fragmentation header 462 for subsequent fragments. ICN LoWPAN adopts this fragmentation 463 handling of [RFC4944]. 465 The Fragmentation LoWPAN header can encapsulate other dispatch 466 headers. The order of dispatch types is defined in Section 5 of 467 [RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled 468 ICN LoWPAN frame does not contain any fragmentation headers and is 469 depicted in Figure 9. 471 +------...------+----...----+--------+------...-------+--------... 472 | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / 473 +------...------+----...----+--------+------...-------+--------... 475 +------...------+----...----+--------... 476 | IEEE 802.15.4 | Frag. 2nd | Payload / 477 +------...------+----...----+--------... 479 . 480 . 481 . 483 +------...------+----...----+--------... 484 | IEEE 802.15.4 | Frag. Nth | Payload / 485 +------...------+----...----+--------... 487 Figure 8: Fragmentation scheme 489 +------...------+--------+------...-------+--------... 490 | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / 491 +------...------+--------+------...-------+--------... 493 Figure 9: Reassembled ICN LoWPAN frame 495 The 6LoWPAN Fragment Forwarding (6FF) [I-D.ietf-6lo-minimal-fragment] 496 is an alternative approach that enables forwarding of fragments 497 without reassembling packets on every intermediate hop. By reusing 498 the 6LoWPAN dispatching framework, 6FF integrates into ICN LoWPAN as 499 seamless as the conventional hop-wise fragmentation. Experimental 500 evaluations [SFR-ICNLOWPAN], however, suggest that a more refined 501 integration can increase the cache utilization of forwarders on a 502 request path. 504 5. Space-efficient Message Encoding for NDN 506 5.1. TLV Encoding 508 The NDN packet format consists of TLV fields using the TLV encoding 509 that is described in [NDN-PACKET-SPEC]. Type and length fields are 510 of variable size, where numbers greater than 252 are encoded using 511 multiple bytes. 513 If the type or length number is less than "253", then that number is 514 encoded into the actual type or length field. If the number is 515 greater or equals "253" and fits into 2 bytes, then the type or 516 length field is set to "253" and the number is encoded in the next 517 following 2 bytes in network byte order, i.e., from the most 518 significant byte (MSB) to the least significant byte (LSB). If the 519 number is greater than 2 bytes and fits into 4 bytes, then the type 520 or length field is set to "254" and the number is encoded in the 521 subsequent 4 bytes in network byte order. For larger numbers, the 522 type or length field is set to "255" and the number is encoded in the 523 subsequent 8 bytes in network byte order. 525 In this specification, compressed NDN TLVs make use of a different 526 TLV encoding scheme that reduces size. Instead of using the first 527 byte as a marker for the number of following bytes, the compressed 528 NDN TLV scheme uses a method to chain a variable number of bytes 529 together. If a byte equals "255 (0xFF)", then the following byte 530 will also be interpreted. The actual value of a chain equals the sum 531 of all constituents. 533 If the type or length number is less than "255", then that number is 534 encoded into the actual type or length field (Figure 10 a). If the 535 type or length number (X) fits into 2 bytes, then the first byte is 536 set to "255" and the subsequent byte equals "X mod 255" (Figure 10 537 b). Following this scheme, a variable-sized number (X) is encoded 538 using multiple bytes of "255" with a trailing byte containing "X mod 539 255" (Figure 10 c). 541 0 1 2 3 4 5 6 7 542 +-+-+-+-+-+-+-+-+ 543 a) | < 255 (X) | = X 544 +-+-+-+-+-+-+-+-+ 546 0 1 547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 b) | 255 | < 255 (X) | = 255 + X 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 0 553 0 1 2 3 4 5 6 7 554 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 555 c) | 255 | 255 | < 255 (X) | = (N * 255) + X 556 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 557 (N) 559 Figure 10: Compressed NDN TLV encoding scheme 561 5.2. Name TLV Compression 563 This Name TLV compression encodes length fields of two consecutive 564 NameComponent TLVs into one byte, using a nibble for each. The most 565 significant nibble indicates the length of an immediately following 566 NameComponent TLV. The least significant nibble denotes the length 567 of a subsequent NameComponent TLV. A length of 0 marks the end of 568 the compressed Name TLV. The last length field of an encoded 569 NameComponent is either 0x00 for a name with an even number of 570 components, and 0xYF (Y > 0) if an odd number of components are 571 present. This process limits the length of a NameComponent TLV to 15 572 bytes, but allows for an unlimited number of components. An example 573 for this encoding is presented in Figure 11. 575 Name: /HAW/Room/481/Humid/99 577 0 1 2 3 578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |0 0 1 1|0 1 0 0| H | A | W | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | R | o | o | m | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | H | u | m | i | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | d |0 0 1 0|0 0 0 0| 9 | 9 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 11: Name TLV compression for /HAW/Room/481/Humid/99 593 5.3. Interest Messages 595 5.3.1. Uncompressed Interest Messages 597 An uncompressed Interest message uses the base dispatch format (see 598 Figure 4) and sets the C flag to "1" and the P as well as the M flag 599 to "0" (Figure 12). The Interest message is handed to the NDN 600 network stack without modifications. 602 0 1 2 3 4 5 6 7 603 +---+---+---+---+---+---+---+---+ 604 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 605 +---+---+---+---+---+---+---+---+ 607 Figure 12: Dispatch format for uncompressed NDN Interest messages 609 5.3.2. Compressed Interest Messages 611 The compressed Interest message uses the extended dispatch format 612 (Figure 5) and sets the P flag to "0", the C flag to "0" and the M 613 flag to "0". If an Interest message contains TLVs that are not 614 mentioned in the following compression rules, then this message MUST 615 be sent uncompressed. 617 This specification assumes that a HopLimit TLV is part of the 618 original Interest message. If such HopLimit TLV is not present, it 619 will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior 620 to the compression. 622 In the default use case, the Interest message is compressed with the 623 following minimal rule set: 625 1. The "Type" field of the outermost MessageType TLV is removed. 627 2. The Name TLV is compressed according to Section 5.2. For this, 628 all NameComponents are expected to be of type 629 GenericNameComponent with a length greater than 0. An 630 ImplicitSha256DigestComponent or ParametersSha256DigestComponent 631 MAY appear at the end of the name. In any other case, the 632 message MUST be sent uncompressed. 634 3. The Nonce TLV and InterestLifetime TLV are moved to the end of 635 the compressed Interest as illustrated in Figure 13. The 636 InterestLifetime is encoded as described in Section 7. If a 637 lifetime is not a valid time-value, then the lifetime is rounded 638 up to the nearest valid time-value as specified in Section 7. 640 4. The Type and Length fields of Nonce TLV, HopLimit TLV and 641 InterestLifetime TLV are elided. The Nonce value has a length of 642 4 bytes and the HopLimit value has a length of 1 byte. The 643 compressed InterestLifetime (Section 7) has a length of 1 byte. 644 The presence of a Nonce and InterestLifetime TLV is deduced from 645 the remaining length to parse. A remaining length of "1" 646 indicates the presence of an InerestLifetime, a length of "4" 647 indicates the presence of a nonce, and a length of "5" indicates 648 the presence of both TLVs. 650 The compressed NDN LoWPAN Interest message is visualized in 651 Figure 13. 653 T = Type, L = Length, V = Value 654 Lc = Compressed Length, Vc = Compressed Value 655 : = optional field, | = mandatory field 657 +---------+---------+ +---------+ 658 | Msg T | Msg L | | Msg Lc | 659 +---------+---------+---------+ +---------+ 660 | Name T | Name L | Name V | | Name Vc | 661 +---------+---------+---------+ +---------+---------+ 662 : CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc : 663 +---------+---------+ +---------+---------+ 664 : MBFr T : MBFr L : | HPL V | 665 +---------+---------+---------+ ==> +---------+---------+ 666 : FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc : 667 +---------+---------+---------+ +---------+---------+ 668 : NONCE T : NONCE L : NONCE V : : NONCE V : 669 +---------+---------+---------+ +---------+ 670 : ILT T : ILT L : ILT V : : ILT Vc : 671 +---------+---------+---------+ +---------+ 672 : HPL T : HPL L : HPL V : 673 +---------+---------+---------+ 674 : APM T : APM L : APM V : 675 +---------+---------+---------+ 677 Figure 13: Compression of NDN LoWPAN Interest Message 679 Further TLV compression is indicated by the ICN LoWPAN dispatch in 680 Figure 14. 682 0 1 683 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 684 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 685 | 0 | 0 | 0 |CID|EXT|PFX|FRE|FWD|APM|DIG| RSV | 686 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 688 Figure 14: Dispatch format for compressed NDN Interest messages 690 CID: Context Identifier See Figure 5. 692 EXT: Extension 694 0: No extension byte follows. 696 1: Extension byte "EXT_0" follows immediately. See 697 Section 5.3.3. 699 PFX: CanBePrefix TLV 700 0: The uncompressed message does not include a 701 CanBePrefix TLV. 703 1: The uncompressed message does include a CanBePrefix 704 TLV and is removed from the compressed message. 706 FRE: MustBeFresh TLV 708 0: The uncompressed message does not include a 709 MustBeFresh TLV. 711 1: The uncompressed message does include a MustBeFresh 712 TLV and is removed from the compressed message. 714 FWD: ForwardingHint TLV 716 0: The uncompressed message does not include a 717 ForwardingHint TLV. 719 1: The uncompressed message does include a 720 ForwardingHint TLV. The Type field is removed from 721 the compressed message. Further, all link delegation 722 types and link preference types are removed. All 723 included names are compressed according to 724 Section 5.2. If any name is not compressible, the 725 message MUST be sent uncompressed. 727 APM: ApplicationParameters TLV 729 0: The uncompressed message does not include an 730 ApplicationParameters TLV. 732 1: The uncompressed message does include an 733 ApplicationParameters TLV. The Type field is removed 734 from the compressed message. 736 DIG: ImplicitSha256DigestComponent TLV 738 0: The name does not include an 739 ImplicitSha256DigestComponent as the last TLV. 741 1: The name does include an 742 ImplicitSha256DigestComponent as the last TLV. The 743 Type and Length fields are omitted. 745 RSV: Reserved Must be set to 0. 747 5.3.3. Dispatch Extension 749 The "EXT_0" byte follows the description in Section 4.1.1 and is 750 illustrated in Figure 15. 752 0 1 2 3 4 5 6 7 753 +---+---+---+---+---+---+---+---+ 754 | NCS | RSV |EXT| 755 +---+---+---+---+---+---+---+---+ 757 Figure 15: EXT_0 format 759 NCS: Name Compression Strategy 761 00: Names are compressed with the default name 762 compression strategy (see Section 5.2). 764 01: Reserved. 766 10: Reserved. 768 11: Reserved. 770 RSV: Reserved Must be set to 0. 772 EXT: Extension 774 0: No extension byte follows. 776 1: A further extension byte follows immediately. 778 5.4. Data Messages 780 5.4.1. Uncompressed Data Messages 782 An uncompressed Data message uses the base dispatch format and sets 783 the C as well as the M flag to "1" and the P flag to "0" (Figure 16). 784 The Data message is handed to the NDN network stack without 785 modifications. 787 0 1 2 3 4 5 6 7 788 +---+---+---+---+---+---+---+---+ 789 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 790 +---+---+---+---+---+---+---+---+ 792 Figure 16: Dispatch format for uncompressed NDN Data messages 794 5.4.2. Compressed Data Messages 796 The compressed Data message uses the extended dispatch format 797 (Figure 5) and sets the C as well as the P flag to "0". The M flag 798 is set to "1". If a Data message contains TLVs that are not 799 mentioned in the following compression rules, then this message MUST 800 be sent uncompressed. 802 By default, the Data message is compressed with the following base 803 rule set: 805 1. The "Type" field of the outermost MessageType TLV is removed. 807 2. The Name TLV is compressed according to Section 5.2. For this, 808 all NameComponents are expected to be of type 809 GenericNameComponent and to have a length greater than 0. In any 810 other case, the message MUST be sent uncompressed. 812 3. The MetaInfo TLV Type and Length fields are elided from the 813 compressed Data message. 815 4. The FreshnessPeriod TLV MUST be moved to the end of the 816 compressed Data message. Type and Length fields are elided and 817 the value is encoded as described in Section 7 as a 1-byte time- 818 code. If the freshness period is not a valid time-value, then 819 the message MUST be sent uncompressed in order to preserve the 820 security envelope of the Data message. The presence of a 821 FreshnessPeriod TLV is deduced from the remaining one byte length 822 to parse. 824 5. The Type fields of the SignatureInfo TLV, SignatureType TLV and 825 SignatureValue TLV are removed. 827 The compressed NDN LoWPAN Data message is visualized in Figure 17. 829 T = Type, L = Length, V = Value 830 Lc = Compressed Length, Vc = Compressed Value 831 : = optional field, | = mandatory field 833 +---------+---------+ +---------+ 834 | Msg T | Msg L | | Msg Lc | 835 +---------+---------+---------+ +---------+ 836 | Name T | Name L | Name V | | Name Vc | 837 +---------+---------+---------+ +---------+---------+ 838 : Meta T : Meta L : : CTyp Lc : CType V : 839 +---------+---------+---------+ +---------+---------+ 840 : CTyp T : CTyp L : CTyp V : : FBID V : 841 +---------+---------+---------+ ==> +---------+---------+ 842 : FrPr T : FrPr L : FrPr V : : CONT Lc : CONT V : 843 +---------+---------+---------+ +---------+---------+ 844 : FBID T : FBID L : FBID V : | Sig Lc | 845 +---------+---------+---------+ +---------+---------+ 846 : CONT T : CONT L : CONT V : | SInf Lc | SInf Vc | 847 +---------+---------+---------+ +---------+---------+ 848 | Sig T | Sig L | | SVal Lc | SVal Vc | 849 +---------+---------+---------+ +---------+---------+ 850 | SInf T | SInf L | SInf V | : FrPr Vc : 851 +---------+---------+---------+ +---------+ 852 | SVal T | SVal L | SVal V | 853 +---------+---------+---------+ 855 Figure 17: Compression of NDN LoWPAN Data Message 857 Further TLV compression is indicated by the ICN LoWPAN dispatch in 858 Figure 18. 860 0 1 861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 862 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 863 | 0 | 0 | 1 |CID|EXT|FBI|CON|KLO| RSV | 864 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 866 Figure 18: Dispatch format for compressed NDN Data messages 868 CID: Context Identifier See Figure 5. 870 EXT: Extension 872 0: No extension byte follows. 874 1: Extension byte "EXT_0" follows immediately. See 875 Section 5.4.3. 877 FBI: FinalBlockId TLV 879 0: The uncompressed message does not include a 880 FinalBlockId TLV. 882 1: The uncompressed message does include a FinalBlockId 883 and it is encoded according to Section 5.2. If the 884 FinalBlockId TLV is not compressible, then the 885 message MUST be sent uncompressed. 887 CON: ContentType TLV 889 0: The uncompressed message does not include a 890 ContentType TLV. 892 1: The uncompressed message does include a ContentType 893 TLV. The Type field is removed from the compressed 894 message. 896 KLO: KeyLocator TLV 898 0: If the included SignatureType requires a KeyLocator 899 TLV, then the KeyLocator represents a name and is 900 compressed according to Section 5.2. If the name is 901 not compressible, then the message MUST be sent 902 uncompressed. 904 1: If the included SignatureType requires a KeyLocator 905 TLV, then the KeyLocator represents a KeyDigest. The 906 Type field of this KeyDigest is removed. 908 RSV: Reserved Must be set to 0. 910 5.4.3. Dispatch Extension 912 The "EXT_0" byte follows the description in Section 4.1.1 and is 913 illustrated in Figure 19. 915 0 1 2 3 4 5 6 7 916 +---+---+---+---+---+---+---+---+ 917 | NCS | RSV |EXT| 918 +---+---+---+---+---+---+---+---+ 920 Figure 19: EXT_0 format 922 NCS: Name Compression Strategy 923 00: Names are compressed with the default name 924 compression strategy (see Section 5.2). 926 01: Reserved. 928 10: Reserved. 930 11: Reserved. 932 RSV: Reserved Must be set to 0. 934 EXT: Extension 936 0: No extension byte follows. 938 1: A further extension byte follows immediately. 940 6. Space-efficient Message Encoding for CCNx 942 6.1. TLV Encoding 944 The generic CCNx TLV encoding is described in [RFC8609]. Type and 945 Length fields attain the common fixed length of 2 bytes. 947 The TLV encoding for CCNx LoWPAN is changed to the more space 948 efficient encoding described in Section 5.1. Hence NDN and CCNx use 949 the same compressed format for writing TLVs. 951 6.2. Name TLV Compression 953 Name TLVs are compressed using the scheme already defined in 954 Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or 955 organizational TLVs, then the name remains uncompressed. 957 6.3. Interest Messages 959 6.3.1. Uncompressed Interest Messages 961 An uncompressed Interest message uses the base dispatch format (see 962 Figure 4) and sets the C as well as the P flag to "1". The M flag is 963 set to "0" (Figure 20). The Interest message is handed to the CCNx 964 network stack without modifications. 966 0 1 2 3 4 5 6 7 967 +---+---+---+---+---+---+---+---+ 968 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 969 +---+---+---+---+---+---+---+---+ 971 Figure 20: Dispatch format for uncompressed CCNx Interest messages 973 6.3.2. Compressed Interest Messages 975 The compressed Interest message uses the extended dispatch format 976 (Figure 5) and sets the C and M flags to "0". The P flag is set to 977 "1". If an Interest message contains TLVs that are not mentioned in 978 the following compression rules, then this message MUST be sent 979 uncompressed. 981 In the default use case, the Interest message is compressed with the 982 following minimal rule set: 984 1. The Type and Length fields of the CCNx Message TLV are elided and 985 are obtained from the Fixed Header on decompression. 987 The compressed CCNx LoWPAN Interest message is visualized in 988 Figure 21. 990 T = Type, L = Length, V = Value 991 Lc = Compressed Length, Vc = Compressed Value 992 : = optional field, | = mandatory field 994 +-----------------------------+ +-------------------------+ 995 | Uncompr. Fixed Header | | Compr. Fixed Header | 996 +-----------------------------+ +-------------------------+ 997 +---------+---------+---------+ +---------+ 998 : ILT T : ILT L : ILT V : : ILT Vc : 999 +---------+---------+---------+ +---------+ 1000 : MSGH T : MSGH L : MSGH V : : MSGH Vc : 1001 +---------+---------+---------+ +---------+ 1002 +---------+---------+ +---------+ 1003 | MSGT T | MSGT L | | Name Vc | 1004 +---------+---------+---------+ +---------+ 1005 | Name T | Name L | Name V | ==> : KIDR Vc : 1006 +---------+---------+---------+ +---------+ 1007 : KIDR T : KIDR L : KIDR V : : OBHR Vc : 1008 +---------+---------+---------+ +---------+---------+ 1009 : OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V : 1010 +---------+---------+---------+ +---------+---------+ 1011 : PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc : 1012 +---------+---------+---------+ +---------+---------+ 1013 : VALG T : VALG L : VALG V : : VPAY Lc : VPAY V : 1014 +---------+---------+---------+ +---------+---------+ 1015 : VPAY T : VPAY L : VPAY V : 1016 +---------+---------+---------+ 1018 Figure 21: Compression of CCNx LoWPAN Interest Message 1020 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1021 Figure 22. 1023 0 1 1024 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1025 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1026 | 0 | 1 | 0 |CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL| 1027 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1029 Figure 22: Dispatch format for compressed CCNx Interest messages 1031 CID: Context Identifier See Figure 5. 1033 EXT: Extension 1035 0: No extension byte follows. 1037 1: Extension byte "EXT_0" follows immediately. See 1038 Section 6.3.3. 1040 VER: CCNx protocol version in the fixed header 1042 0: The Version field equals 1 and is removed from the fixed 1043 header. 1045 1: The Version field appears in the fixed header. 1047 FLG: Flags field in the fixed header 1049 0: The Flags field equals 0 and is removed from the Interest 1050 message. 1052 1: The Flags field appears in the fixed header. 1054 PTY: PacketType field in the fixed header 1056 0: The PacketType field is elided and assumed to be 1057 "PT_INTEREST". 1059 1: The PacketType field is elided and assumed to be 1060 "PT_RETURN". 1062 HPL: HopLimit field in the fixed header 1064 0: The HopLimit field appears in the fixed header. 1066 1: The HopLimit field is elided and assumed to be "1". 1068 FRS: Reserved field in the fixed header 1070 0: The Reserved field appears in the fixed header. 1072 1: The Reserved field is elided and assumed to be "0". 1074 PAY: Optional Payload TLV 1076 0: The Payload TLV is absent. 1078 1: The Payload TLV is present and the type field is elided. 1080 ILT: Optional Hop-By-Hop InterestLifetime TLV 1082 See Section 6.3.2.1 for further details on the ordering 1083 of hop-by-hop TLVs. 1085 0: No InterestLifetime TLV is present in the Interest 1086 message. 1088 1: An InterestLifetime TLV is present with a fixed length of 1089 1 byte and is encoded as described in Section 7. The 1090 type and length fields are elided. If a lifetime is not 1091 a valid time-value, then the lifetime is rounded up to 1092 the nearest valid time-value (see Section 7). 1094 MGH: Optional Hop-By-Hop MessageHash TLV 1096 See Section 6.3.2.1 for further details on the ordering 1097 of hop-by-hop TLVs. 1099 This TLV is expected to contain a T_SHA-256 TLV. If 1100 another hash is contained, then the Interest MUST be sent 1101 uncompressed. 1103 0: The MessageHash TLV is absent. 1105 1: A T_SHA-256 TLV is present and the type as well as the 1106 length fields are removed. The length field is assumed 1107 to represent 32 bytes. The outer Message Hash TLV is 1108 omitted. 1110 KIR: Optional KeyIdRestriction TLV 1112 This TLV is expected to contain a T_SHA-256 TLV. If 1113 another hash is contained, then the Interest MUST be sent 1114 uncompressed. 1116 0: The KeyIdRestriction TLV is absent. 1118 1: A T_SHA-256 TLV is present and the type as well as the 1119 length fields are removed. The length field is assumed 1120 to represent 32 bytes. The outer KeyIdRestriction TLV is 1121 omitted. 1123 CHR: Optional ContentObjectHashRestriction TLV 1125 This TLV is expected to contain a T_SHA-256 TLV. If 1126 another hash is contained, then the Interest MUST be sent 1127 uncompressed. 1129 0: The ContentObjectHashRestriction TLV is absent. 1131 1: A T_SHA-256 TLV is present and the type as well as the 1132 length fields are removed. The length field is assumed 1133 to represent 32 bytes. The outer 1134 ContentObjectHashRestriction TLV is omitted. 1136 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 1138 0: No validation related TLVs are present in the Interest 1139 message. 1141 1: Validation related TLVs are present in the Interest 1142 message. An additional byte follows immediately that 1143 handles validation related TLV compressions and is 1144 described in Section 6.3.2.2. 1146 6.3.2.1. Hop-By-Hop Header TLVs Compression 1148 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 1149 optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several 1150 more can be defined in higher level specifications. For the 1151 compression specified in the previous section, the Hop-By-Hop TLVs 1152 are ordered as follows: 1154 1. Interest Lifetime TLV 1156 2. Message Hash TLV 1158 Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed 1159 in the encoded message and they appear in the same order as in the 1160 original message, but after the Interest Lifetime TLV and Message 1161 Hash TLV. 1163 6.3.2.2. Validation 1165 0 1 2 3 4 5 6 7 8 1166 +-------+-------+-------+-------+-------+-------+-------+-------+ 1167 | ValidationAlg | KeyID | RSV | 1168 +-------+-------+-------+-------+-------+-------+-------+-------+ 1170 Figure 23: Dispatch for Interset Validations 1172 ValidationALg: Optional ValidationAlgorithm TLV 1174 0000: An uncompressed ValidationAlgorithm TLV is included. 1176 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1177 ValidationAlgorithm TLV is included. 1179 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1180 ValidationAlgorithm TLV is included. Additionally, a 1181 Sigtime TLV is inlined without a type and a length field. 1183 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1184 no ValidationAlgorithm TLV is included. 1186 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1187 no ValidationAlgorithm TLV is included. Additionally, a 1188 Sigtime TLV is inlined without a type and a length field. 1190 0101: Reserved. 1192 0110: Reserved. 1194 0111: Reserved. 1196 1000: Reserved. 1198 1001: Reserved. 1200 1010: Reserved. 1202 1011: Reserved. 1204 1100: Reserved. 1206 1101: Reserved. 1208 1110: Reserved. 1210 1111: Reserved. 1212 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1214 00: The KeyId TLV is absent. 1216 01: The KeyId TLV is present and uncompressed. 1218 10: A T_SHA-256 TLV is present and the type field as well as 1219 the length fields are removed. The length field is 1220 assumed to represent 32 bytes. The outer KeyId TLV is 1221 omitted. 1223 11: A T_SHA-512 TLV is present and the type field as well as 1224 the length fields are removed. The length field is 1225 assumed to represent 64 bytes. The outer KeyId TLV is 1226 omitted. 1228 RSV: Reserved Must be set to 0. 1230 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1231 is present. The type field is omitted. 1233 6.3.3. Dispatch Extension 1235 The "EXT_0" byte follows the description in Section 4.1.1 and is 1236 illustrated in Figure 24. 1238 0 1 2 3 4 5 6 7 1239 +---+---+---+---+---+---+---+---+ 1240 | NCS | RSV |EXT| 1241 +---+---+---+---+---+---+---+---+ 1243 Figure 24: EXT_0 format 1245 NCS: Name Compression Strategy 1247 00: Names are compressed with the default name 1248 compression strategy (see Section 5.2). 1250 01: Reserved. 1252 10: Reserved. 1254 11: Reserved. 1256 RSV: Reserved Must be set to 0. 1258 EXT: Extension 1260 0: No extension byte follows. 1262 1: A further extension byte follows immediately. 1264 6.4. Content Objects 1266 6.4.1. Uncompressed Content Objects 1268 An uncompressed Content object uses the base dispatch format (see 1269 Figure 4) and sets the C, P and M flags to "1" (Figure 25). The 1270 Content object is handed to the CCNx network stack without 1271 modifications. 1273 0 1 2 3 4 5 6 7 1274 +---+---+---+---+---+---+---+---+ 1275 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1276 +---+---+---+---+---+---+---+---+ 1278 Figure 25: Dispatch format for uncompressed CCNx Content objects 1280 6.4.2. Compressed Content Objects 1282 The compressed Content object uses the extended dispatch format 1283 (Figure 5) and sets the P as well as the M flag to "1". The C flag 1284 is set to "0". If a Content object contains TLVs that are not 1285 mentioned in the following compression rules, then this message MUST 1286 be sent uncompressed. 1288 By default, the Content object is compressed with the following base 1289 rule set: 1291 1. The PacketType field is elided from the Fixed Header. 1293 2. The Type and Length fields of the CCNx Message TLV are elided and 1294 are obtained from the Fixed Header on decompression. 1296 The compressed CCNx LoWPAN Data message is visualized in Figure 26. 1298 T = Type, L = Length, V = Value 1299 Lc = Compressed Length, Vc = Compressed Value 1300 : = optional field, | = mandatory field 1302 +-----------------------------+ +-------------------------+ 1303 | Uncompr. Fixed Header | | Compr. Fixed Header | 1304 +-----------------------------+ +-------------------------+ 1305 +---------+---------+---------+ +---------+ 1306 : RCT T : RCT L : RCT V : : RCT Vc : 1307 +---------+---------+------.--+ +---------+ 1308 : MSGH T : MSGH L : MSGH V : : MSGH Vc : 1309 +---------+---------+---------+ +---------+ 1310 +---------+---------+ +---------+ 1311 | MSGT T | MSGT L | | Name Vc | 1312 +---------+---------+---------+ +---------+ 1313 | Name T | Name L | Name V | ==> : EXPT Vc : 1314 +---------+---------+---------+ +---------+---------+ 1315 : PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V : 1316 +---------+---------+---------+ +---------+---------+ 1317 : EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc : 1318 +---------+---------+---------+ +---------+---------+ 1319 : PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V : 1320 +---------+---------+---------+ +---------+---------+ 1321 : VALG T : VALG L : VALG V : 1322 +---------+---------+---------+ 1323 : VPAY T : VPAY L : VPAY V : 1324 +---------+---------+---------+ 1326 Figure 26: Compression of CCNx LoWPAN Data Message 1328 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1329 Figure 27. 1331 0 1 1332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1333 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1334 | 0 | 1 | 1 |CID|EXT|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV| 1335 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1337 Figure 27: Dispatch format for compressed CCNx Content objects 1339 CID: Context Identifier See Figure 5. 1341 EXT: Extension 1343 0: No extension byte follows. 1345 1: Extension byte "EXT_0" follows immediately. See 1346 Section 6.4.3. 1348 VER: CCNx protocol version in the fixed header 1350 0: The Version field equals 1 and is removed from the fixed 1351 header. 1353 1: The Version field appears in the fixed header. 1355 FLG: Flags field in the fixed header See Section 6.3.2. 1357 FRS: Reserved field in the fixed header See Section 6.3.2. 1359 PAY: Optional Payload TLV See Section 6.3.2. 1361 RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 1363 0: The Recommended Cache Time TLV is absent. 1365 1: The Recommended Cache Time TLV is present and the type as 1366 well as the length fields are elided. 1368 MGH: Optional Hop-By-Hop MessageHash TLV 1370 See Section 6.4.2.1 for further details on the ordering 1371 of hop-by-hop TLVs. 1373 This TLV is expected to contain a T_SHA-256 TLV. If 1374 another hash is contained, then the Content Object MUST 1375 be sent uncompressed. 1377 0: The MessageHash TLV is absent. 1379 1: A T_SHA-256 TLV is present and the type as well as the 1380 length fields are removed. The length field is assumed 1381 to represent 32 bytes. The outer Message Hash TLV is 1382 omitted. 1384 PLTYP: Optional PayloadType TLV 1386 00: The PayloadType TLV is absent. 1388 01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA 1389 is assumed. 1391 10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY 1392 is assumed. 1394 11: The PayloadType TLV is present and uncompressed. 1396 EXP: Optional ExpiryTime TLV 1398 0: The ExpiryTime TLV is absent. 1400 1: The ExpiryTime TLV is present and the type as well as the 1401 length fields are elided. 1403 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1404 tion 6.3.2. 1406 RSV: Reserved Must be set to 0. 1408 6.4.2.1. Hop-By-Hop Header TLVs Compression 1410 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1411 two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but 1412 several more can be defined in higher level specifications. For the 1413 compression specified in the previous section, the Hop-By-Hop TLVs 1414 are ordered as follows: 1416 1. Recommended Cache Time TLV 1418 2. Message Hash TLV 1420 Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed 1421 in the encoded message and they appear in the same order as in the 1422 original message, but after the Recommended Cache Time TLV and 1423 Message Hash TLV. 1425 6.4.3. Dispatch Extension 1427 The "EXT_0" byte follows the description in Section 4.1.1 and is 1428 illustrated in Figure 28. 1430 0 1 2 3 4 5 6 7 1431 +---+---+---+---+---+---+---+---+ 1432 | NCS | RSV |EXT| 1433 +---+---+---+---+---+---+---+---+ 1435 Figure 28: EXT_0 format 1437 NCS: Name Compression Strategy 1438 00: Names are compressed with the default name 1439 compression strategy (see Section 5.2). 1441 01: Reserved. 1443 10: Reserved. 1445 11: Reserved. 1447 RSV: Reserved Must be set to 0. 1449 EXT: Extension 1451 0: No extension byte follows. 1453 1: A further extension byte follows immediately. 1455 7. Compressed Time Encoding 1457 This document adopts the compact time representation 1458 [I-D.gundogan-icnrg-ccnx-timetlv] for relative time values. Exponent 1459 and mantissa values are encoded in a 1-byte wide representation as 1460 depicted in Figure 29. The exponent occupies the most significant 1461 bits, while the mantissa uses the least significant bits. 1463 0 1 2 3 4 5 6 7 1464 +---+---+---+---+---+---+---+---+ 1465 | exponent | mantissa | 1466 +---+---+---+---+---+---+---+---+ 1468 Figure 29: A time-code with exponent and mantissa to encode a 1469 logarithmic range time representation. 1471 The mantissa size is set to 3 bits, the exponent size to 5 bits, and 1472 a bias of -5 is applied. This allows for a time representation that 1473 ranges from tens of milliseconds with high precision to days with low 1474 precision. The base unit for time values are seconds. A time-value 1475 is calculated using the following formula, where (e) represents the 1476 exponent, (m) the mantissa, (m_max = 8) the maximum mantissa value, 1477 and (b) the bias. 1479 Subnormal (e == 0): (0 + m/m_max) * 2^(1+b) 1481 Normalized (e > 0): (1 + m/m_max) * 2^(e+b) 1483 The subnormal form provides a gradual underflow from the smallest 1484 normalized number towards zero. 1486 This configuration allows for the following ranges: 1488 o Minimum subnormal number: 0 seconds 1490 o Maximum subnormal number: ~0.054688 seconds 1492 o Minimum normalized number: ~0.062500 seconds 1494 o Maximum normalized number: ~3.987284 years 1496 Valid time-values are positive numbers, including 0. An invalid 1497 time-value (t, in seconds) MUST be rounded down to the nearest valid 1498 time-value using this algorithm, where (e) represents the number of 1499 bits for the exponent, (m) the number of bits for the mantissa, and 1500 (m_max = 8) the maximum mantissa value. The bias (b) is set to -5 as 1501 before. 1503 o e := floor( log2( t/(2^-b) )) 1505 o m := floor( 8 * (t / 2^(e+b) - 1 )) 1507 8. Stateful Header Compression 1509 Stateful header compression in ICN LoWPAN enables packet size 1510 reductions in two ways. First, common information that is shared 1511 throughout the local LoWPAN may be memorized in context state at all 1512 nodes and omitted from communication. Second, redundancy in a single 1513 Interest-data exchange may be removed from ICN stateful forwarding on 1514 a hop-by-hop bases and memorized in en-route state tables. 1516 8.1. LoWPAN-local State 1518 A context identifier (CID) is a byte that refers to a particular 1519 conceptual context between network devices and MAY be used to replace 1520 frequently appearing information, such as name prefixes, suffixes, or 1521 meta information, such as Interest lifetime. 1523 0 1 2 3 4 5 6 7 1524 +---+---+---+---+---+---+---+---+ 1525 | X | ContextID | 1526 +---+---+---+---+---+---+---+---+ 1528 Figure 30: Context Identifier. 1530 The 7-bit ContextID is a locally-scoped unique identifier that 1531 represents contextual state shared between sender and receiver of the 1532 corresponding frame (see Figure 30). If set the most significant bit 1533 indicates the presence of another, subsequent ContextID byte (see 1534 Figure 35). 1536 Context state shared between senders and receivers is removed from 1537 the compressed packet prior to sending, and reinserted after 1538 reception prior to passing to the upper stack. 1540 The actual information in a context and how it is encoded are out of 1541 scope of this document. The initial distribution and maintenance of 1542 shared context is out of scope of this document. Frames containing 1543 unknown or invalid CIDs MUST be silently discarded. 1545 8.2. En-route State 1547 In CCNx and NDN, Name TLVs are included in Interest messages, and 1548 they return in data messages. Returning Name TLVs either equal the 1549 original Name TLV, or they contain the original Name TLV as a prefix. 1550 ICN LoWPAN reduces this redundancy in responses by replacing Name 1551 TLVs with single bytes that represent link-local HopIDs. HopIDs are 1552 carried as Context Identifiers (see Section 8.1) of link-local scope 1553 as shown in Figure 31. 1555 0 1 2 3 4 5 6 7 1556 +---+---+---+---+---+---+---+---+ 1557 | X | HopID | 1558 +---+---+---+---+---+---+---+---+ 1560 Figure 31: Context Identifier as HopID. 1562 A HopID is valid if not all ID bits are set to zero and invalid 1563 otherwise. This yields 127 distinct HopIDs. If this range (1...127) 1564 is exhausted, the messages MUST be sent without en-route state 1565 compression until new HopIDs are available. An ICN LoWPAN node that 1566 forwards without replacing the name by a HopID (without en-route 1567 compression) MUST invalidate the HopID by setting all ID-bits to 1568 zero. 1570 While an Interest is traversing, a forwarder generates an ephemeral 1571 HopID that is tied to a PIT entry. Each HopID MUST be unique within 1572 the local PIT and only exists during the lifetime of a PIT entry. To 1573 maintain HopIDs, the local PIT is extended by two new columns: HIDi 1574 (inbound HopIDs) and HIDo (outbound HopIDs). 1576 HopIDs are included in Interests and stored on the next hop with the 1577 resulting PIT entry in the HIDi column. The HopID is replaced with a 1578 newly generated local HopID before the Interest is forwarded. This 1579 new HopID is stored in the HIDo column of the local PIT (see 1580 Figure 32). 1582 PIT of B PIT Extension PIT of C PIT Extension 1583 +--------+------++------+------+ +--------+------++------+------+ 1584 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1585 +========+======++======+======+ +========+======++======+======+ 1586 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1587 +--------+------++------+------+ +--------+------++------+------+ 1588 ^ | ^ 1589 store | '----------------------, ,---' store 1590 | send v | 1591 ,---, /p0, h_A ,---, /p0, h_B ,---, 1592 | A | ------------------------> | B | ------------------------> | C | 1593 '---' '---' '---' 1595 Figure 32: Setting compression state en-route (Interest). 1597 Responses include HopIDs that were obtained from Interests. If the 1598 returning Name TLV equals the original Name TLV, then the name is 1599 entirely elided. Otherwise, only the matching name prefix is elided 1600 and the distinct name suffix is included along with the HopID. When 1601 a response is forwarded, the contained HopID is extracted and used to 1602 match against the correct PIT entry by performing a lookup on the 1603 HIDo column. The HopID is then replaced with the corresponding HopID 1604 from the HIDi column prior to forwarding the response (Figure 33). 1606 PIT of B PIT Extension PIT of C PIT Extension 1607 +--------+------++------+------+ +--------+------++------+------+ 1608 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1609 +========+======++======+======+ +========+======++======+======+ 1610 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1611 +--------+------++------+------+ +--------+------++------+------+ 1612 | ^ | 1613 send | '----------------------, ,---' send 1614 v match | v 1615 ,---, h_A ,---, h_B ,---, 1616 | A | <------------------------ | B | <------------------------ | C | 1617 '---' '---' '---' 1619 Figure 33: Eliding Name TLVs using en-route state (data). 1621 It should be noted that each forwarder of an Interest in an ICN 1622 LoWPAN network can individually decide whether to participate in en- 1623 route compression or not. However, an ICN LoWPAN node SHOULD use en- 1624 route compression whenever the stateful compression mechanism is 1625 activated. 1627 Note also that the extensions of the PIT data structure are required 1628 only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside 1629 of an ICN LoWPAN domain do not need to implement these extensions. 1631 8.3. Integrating Stateful Header Compression 1633 A CID appears whenever the CID flag is set (see Figure 5). The CID 1634 is appended to the last ICN LoWPAN dispatch byte as shown in 1635 Figure 34. 1637 ...-------+--------+-------...-------+--...-+-------... 1638 / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / 1639 ...-------+--------+-------...-------+--...-+-------... 1641 Figure 34: LoWPAN Encapsulation with ICN LoWPAN and CIDs 1643 Multiple CIDs are chained together, with the most significant bit 1644 indicating the presence of a subsequent CID (Figure 35). This allows 1645 to use multiple shared contexts in compressed messages. 1647 The HopID is always included as the very first CID. 1649 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1650 |1| CID / HopID | --> |1| CID | --> |0| CID | 1651 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1653 Figure 35: Chaining of context identifiers. 1655 9. ICN LoWPAN Constants and Variables 1657 This is a summary of all ICN LoWPAN constants and variables. 1659 DEFAULT_NDN_HOPLIMIT: 255 1661 10. Implementation Report and Guidance 1663 The ICN LoWPAN scheme defined in this document has been implemented 1664 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT 1665 version on RIOT [RIOT]. An experimental evaluation for NDN over ICN 1666 LOWPAN with varying configurations has been performed in [ICNLOWPAN]. 1667 Energy profilings and processing time measurements indicate 1668 significant energy savings, while amortized costs for processing show 1669 no penalties. 1671 10.1. Preferred Configuration 1673 The header compression performance depends on certain aspects and 1674 configurations. It works best for the following cases: 1676 o Relative time values use a compressible encoding as per Section 7. 1678 o Contextual state (e.g., prefixes) is distributed, such that long 1679 names can be elided from Interest and data messages. 1681 o Frequently used TLV type numbers for CCNx and NDN stay in the 1682 lower range (< 255). 1684 Name components are of GenericNameComponent type and are limited to a 1685 length of 15 bytes to enable compression for all messages. 1687 10.2. Further Experimental Deployments 1689 An investigation of ICN LoWPAN in large-scale deployments with 1690 varying traffic patterns using larger samples of the different board 1691 types available remains as future work. This document will be 1692 revised to progress it to the Standards Track, once sufficient 1693 operational experience has been acquired. Experience reports are 1694 encouraged, particularly in the following areas: 1696 o The name compression scheme (Section 5.2) is optimized for short 1697 name components of GenericNameComponent type. An empirical study 1698 on name lengths in different deployments of selected use cases, 1699 such as smart home, smart city, and industrial IoT can provide 1700 meaningful reports on necessary name component types and lengths. 1701 A conclusive outcome helps to understand whether and how extension 1702 mechanisms are needed (Section 5.3.3). As a preliminary analysis, 1703 [ICNLOWPAN] investigates the effectiveness of the proposed 1704 compression scheme with URLs obtained from the WWW. Studies on 1705 CoAP [RFC7252] deployments can offer additional insights on naming 1706 schemes in the IoT. 1708 o The fragmentation scheme (Section 4.2) inherited from 6LoWPAN 1709 allows for a transparent, hop-wise reassembly of CCNx or NDN 1710 packets. Fragment forwarding [I-D.ietf-6lo-minimal-fragment] with 1711 selective fragment recovery [I-D.ietf-6lo-fragment-recovery] can 1712 improve the end-to-end latency and reliability, while it reduces 1713 buffer requirements on forwarders. Initial evaluations 1714 ([SFR-ICNLOWPAN]) show that a naive integration of these upcoming 1715 fragmentation features into ICN LoWPAN renders the hop-wise 1716 content replication inoperative, since Interest and data messages 1717 are reassembled end-to-end. More deployment experiences are 1718 necessary to gauge the feasibility of different fragmentation 1719 schemes in ICN LoWPAN. 1721 o Context state (Section 8.1) holds information that is shared 1722 between a set of devices in a LoWPAN. Fixed name prefixes and 1723 suffixes are good candidates to be distributed to all nodes in 1724 order to elide them from request and response messages. More 1725 experience and a deeper inspection of currently available and 1726 upcoming protocol features is necessary to identify other protocol 1727 fields. 1729 o The distribution and synchronization of contextual state can 1730 potentially be adopted from Section 7.2 of [RFC6775], but requires 1731 further evaluations. While 6LoWPAN uses the Neighbor Discovery 1732 protocol to disseminate state, CCNx and NDN deployments are 1733 missing out on a standard mechanism to bootstrap and manage 1734 configurations. 1736 o The stateful en-route compression (Section 8.2) supports a limited 1737 number of 127 distinct HopIDs that can be simultaneously in use on 1738 a single node. Complex deployment scenarios that make use of 1739 multiple, concurrent requests can provide a better insight on the 1740 number of open requests stored in the Pending Interest Table of 1741 memory-constrained devices. This number can serve as an upper- 1742 bound and determines whether the HopID length needs to be resized 1743 to fit more HopIDs to the cost of additional header overhead. 1745 o Multiple implementations that generate and deploy the compression 1746 options of this memo in different ways will also add to the 1747 experience and understanding of the benefits and limitations of 1748 the proposed schemes. Different reports can help to illuminate on 1749 the complexity of implementing ICN LoWPAN for constrained devices, 1750 as well as on maintaining interoperability with other 1751 implementations. 1753 11. Security Considerations 1755 Main memory is typically a scarce resource of constrained networked 1756 devices. Fragmentation as described in this memo preserves fragments 1757 and purges them only after a packet is reassembled, which requires a 1758 buffering of all fragments. This scheme is able to handle fragments 1759 for distinctive packets simultaneously, which can lead to overflowing 1760 packet buffers that cannot hold all necessary fragments for packet 1761 reassembly. Implementers are thus urged to make use of appropriate 1762 buffer replacement strategies for fragments. The upcoming minimal 1763 fragment forwarding [I-D.ietf-6lo-minimal-fragment] can potentially 1764 prevent fragment buffer saturation in forwarders. 1766 The stateful header compression generates ephemeral HopIDs for 1767 incoming and outgoing Interests and consumes them on returning Data 1768 packets. Forged Interests can deplete the number of available 1769 HopIDs, thus leading to a denial of compression service for 1770 subsequent content requests. 1772 To further alleviate the problems caused by forged fragments or 1773 Interest initiations, proper protective mechanisms for accessing the 1774 link-layer should be deployed. IEEE 802.15.4, e.g., provides 1775 capabilities to protect frames and restrict them to a point-to-point 1776 link, or a group of devices. 1778 12. IANA Considerations 1780 12.1. Reserving Space in the 6LoWPAN Dispatch Type Field Registry 1782 IANA has assigned dispatch values of the "6LoWPAN Dispatch Type 1783 Field" registry [RFC4944][RFC8025] with Page TBD1 for ICN LoWPAN. 1784 Table 1 represents updates to the registry. 1786 +-------------+------+-------------------------------------------+ 1787 | Bit Pattern | Page | Header Type | 1788 +-------------+------+-------------------------------------------+ 1789 | 00 000000 | TBD1 | Uncompressed NDN Interest messages | 1790 | 00 100000 | TBD1 | Uncompressed NDN Data messages | 1791 | 01 000000 | TBD1 | Uncompressed CCNx Interest messages | 1792 | 01 100000 | TBD1 | Uncompressed CCNx Content Object messages | 1793 | 10 0xxxxx | TBD1 | Compressed NDN Interest messages | 1794 | 10 1xxxxx | TBD1 | Compressed NDN Data messages | 1795 | 11 0xxxxx | TBD1 | Compressed CCNx Interest messages | 1796 | 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages | 1797 +-------------+------+-------------------------------------------+ 1799 Table 1: Dispatch types for NDN and CCNx with page TBD1. 1801 13. References 1803 13.1. Normative References 1805 [ieee802.15.4] 1806 "IEEE Std. 802.15.4-2015", April 2016, 1807 . 1810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1811 Requirement Levels", BCP 14, RFC 2119, 1812 DOI 10.17487/RFC2119, March 1997, 1813 . 1815 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1816 "Transmission of IPv6 Packets over IEEE 802.15.4 1817 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1818 . 1820 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1821 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1822 DOI 10.17487/RFC6282, September 2011, 1823 . 1825 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1826 Bormann, "Neighbor Discovery Optimization for IPv6 over 1827 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1828 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1829 . 1831 13.2. Informative References 1833 [CCN-LITE] 1834 "CCN-lite: A lightweight CCNx and NDN implementation", 1835 . 1837 [I-D.gundogan-icnrg-ccnx-timetlv] 1838 Gundogan, C., Schmidt, TC., Oran, D., and M. Waehlisch, 1839 "An Alternative Delta Time encoding for CCNx using 1840 Interval Time from RFC5497", draft-gundogan-icnrg-ccnx- 1841 timetlv-00 (work in progress), November 2019. 1843 [I-D.ietf-6lo-fragment-recovery] 1844 Thubert, P., "6LoWPAN Selective Fragment Recovery", draft- 1845 ietf-6lo-fragment-recovery-21 (work in progress), March 1846 2020. 1848 [I-D.ietf-6lo-minimal-fragment] 1849 Watteyne, T., Thubert, P., and C. Bormann, "On Forwarding 1850 6LoWPAN Fragments over a Multihop IPv6 Network", draft- 1851 ietf-6lo-minimal-fragment-15 (work in progress), March 1852 2020. 1854 [I-D.irtf-icnrg-flic] 1855 Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like 1856 ICN Collections (FLIC)", draft-irtf-icnrg-flic-02 (work in 1857 progress), November 2019. 1859 [ICNLOWPAN] 1860 Gundogan, C., Kietzmann, P., Schmidt, TC., and M. 1861 Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low 1862 Power IoT Networks", Proc. of 18th IFIP Networking 1863 Conference, May 2019, 1864 . 1866 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1867 "Networking Named Content", 5th Int. Conf. on emerging 1868 Networking Experiments and Technologies (ACM CoNEXT), 1869 2009, . 1871 [NDN-EXP1] 1872 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1873 Waehlisch, "Information Centric Networking in the IoT: 1874 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1875 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1876 77-86, September 2014, 1877 . 1879 [NDN-EXP2] 1880 Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 1881 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 1882 Comparative Measurement Study in the IoT", Proc. of 5th 1883 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 1884 DL, pp. 159-171, September 2018, 1885 . 1887 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1888 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1889 in NDN: Towards Quantifying the Resource Gain", Proc. of 1890 4th ACM Conf. on Information-Centric Networking (ICN- 1891 2017) ACM DL, pp. 36-42, September 2017, 1892 . 1894 [NDN-PACKET-SPEC] 1895 "NDN Packet Format Specification", 1896 . 1898 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1899 Constrained-Node Networks", RFC 7228, 1900 DOI 10.17487/RFC7228, May 2014, 1901 . 1903 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1904 Application Protocol (CoAP)", RFC 7252, 1905 DOI 10.17487/RFC7252, June 2014, 1906 . 1908 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1909 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1910 "Information-Centric Networking: Baseline Scenarios", 1911 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1912 . 1914 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1915 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1916 "Information-Centric Networking (ICN) Research 1917 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1918 . 1920 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1921 and G. Boggia, "Information-Centric Networking: Evaluation 1922 and Security Considerations", RFC 7945, 1923 DOI 10.17487/RFC7945, September 2016, 1924 . 1926 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1927 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1928 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1929 . 1931 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1932 Networking (CCNx) Semantics", RFC 8569, 1933 DOI 10.17487/RFC8569, July 2019, 1934 . 1936 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1937 Networking (CCNx) Messages in TLV Format", RFC 8609, 1938 DOI 10.17487/RFC8609, July 2019, 1939 . 1941 [RIOT] Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., 1942 Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., 1943 and M. Waehlisch, "RIOT: an Open Source Operating System 1944 for Low-end Embedded Devices in the IoT", IEEE Internet of 1945 Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018, 1946 . 1948 [SFR-ICNLOWPAN] 1949 Lenders, M., Gundogan, C., Schmidt, TC., and M. Waehlisch, 1950 "Connecting the Dots: Selective Fragment Recovery in 1951 ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric 1952 Networking (ICN-2020) ACM DL, pp. 70-76, September 2020, 1953 . 1955 [TLV-ENC-802.15.4] 1956 "CCN and NDN TLV encodings in 802.15.4 packets", 1957 . 1960 [WIRE-FORMAT-CONSID] 1961 "CCN/NDN Protocol Wire Format and Functionality 1962 Considerations", . 1966 Appendix A. Estimated Size Reduction 1968 In the following a theoretical evaluation is given to estimate the 1969 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1971 We assume that "n" is the number of name components, "comps_n" 1972 denotes the sum of n name component lengths. We also assume that the 1973 length of each name component is lower than 16 bytes. The length of 1974 the content is given by "clen". The lengths of TLV components is 1975 specific to the CCNx or NDN encoding and outlined below. 1977 A.1. NDN 1979 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1980 the 1 byte form of each TLV component is assumed. A typical TLV 1981 component therefore is of size 2 (type field + length field) + the 1982 actual value. 1984 A.1.1. Interest 1986 Figure 36 depicts the size requirements for a basic, uncompressed NDN 1987 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1988 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1989 Numbers below represent the amount of bytes. 1991 ------------------------------------, 1992 Interest TLV = 2 | 1993 ---------------------, | 1994 Name | 2 + | 1995 NameComponents = 2n + | 1996 | comps_n | 1997 ---------------------' = 21 + 2n + comps_n 1998 CanBePrefix = 2 | 1999 MustBeFresh = 2 | 2000 Nonce = 6 | 2001 InterestLifetime = 4 | 2002 HopLimit = 3 | 2003 ------------------------------------' 2005 Figure 36: Estimated size of an uncompressed NDN Interest 2007 Figure 37 depicts the size requirements after compression. 2009 ------------------------------------, 2010 Dispatch Page Switch = 1 | 2011 NDN Interset Dispatch = 2 | 2012 Interest TLV = 1 | 2013 -----------------------, | 2014 Name | | 2015 NameComponents = n/2 + = 10 + n/2 + comps_n 2016 | comps_n | 2017 -----------------------' | 2018 Nonce = 4 | 2019 HopLimit = 1 | 2020 InterestLifetime = 1 | 2021 ------------------------------------' 2023 Figure 37: Estimated size of a compressed NDN Interest 2025 The size difference is: 2026 11 + 1.5n bytes. 2028 For the name "/DE/HH/HAW/BT7", the total size gain is 17 bytes, which 2029 is 43% of the uncompressed packet. 2031 A.1.2. Data 2033 Figure 38 depicts the size requirements for a basic, uncompressed NDN 2034 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 2035 1 minute is assumed and the value is encoded using 1 byte. An 2036 HMACWithSha256 is assumed as signature. The key locator is assumed 2037 to contain a Name TLV of length klen. 2039 ------------------------------------, 2040 Data TLV = 2 | 2041 ---------------------, | 2042 Name | 2 + | 2043 NameComponents = 2n + | 2044 | comps_n | 2045 ---------------------' | 2046 ---------------------, | 2047 MetaInfo | | 2048 FreshnessPeriod = 6 | 2049 | = 53 + 2n + comps_n + 2050 ---------------------' | clen + klen 2051 Content = 2 + clen | 2052 ---------------------, | 2053 SignatureInfo | | 2054 SignatureType | | 2055 KeyLocator = 41 + klen | 2056 SignatureValue | | 2057 DigestSha256 | | 2058 ---------------------' | 2059 ------------------------------------' 2061 Figure 38: Estimated size of an uncompressed NDN Data 2063 Figure 39 depicts the size requirements for the compressed version of 2064 the above Data packet. 2066 ------------------------------------, 2067 Dispatch Page Switch = 1 | 2068 NDN Data Dispatch = 2 | 2069 -----------------------, | 2070 Name | | 2071 NameComponents = n/2 + | 2072 | comps_n = 38 + n/2 + comps_n + 2073 -----------------------' | clen + klen 2074 Content = 1 + clen | 2075 KeyLocator = 1 + klen | 2076 DigestSha256 = 32 | 2077 FreshnessPeriod = 1 | 2078 ------------------------------------' 2080 Figure 39: Estimated size of a compressed NDN Data 2082 The size difference is: 2083 15 + 1.5n bytes. 2085 For the name "/DE/HH/HAW/BT7", the total size gain is 21 bytes. 2087 A.2. CCNx 2089 The CCNx TLV encoding defines a 2-byte encoding for type and length 2090 fields, summing up to 4 bytes in total without a value. 2092 A.2.1. Interest 2094 Figure 40 depicts the size requirements for a basic, uncompressed 2095 CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version 2096 is assumed to be 1 and the reserved field is assumed to be 0. A 2097 KeyIdRestriction TLV with T_SHA-256 is included to limit the 2098 responses to Content Objects containing the specific key. 2100 ------------------------------------, 2101 Fixed Header = 8 | 2102 Message = 4 | 2103 ---------------------, | 2104 Name | 4 + = 56 + 4n + comps_n 2105 NameSegments = 4n + | 2106 | comps_n | 2107 ---------------------' | 2108 KeyIdRestriction = 40 | 2109 ------------------------------------' 2111 Figure 40: Estimated size of an uncompressed CCNx Interest 2113 Figure 41 depicts the size requirements after compression. 2115 ------------------------------------, 2116 Dispatch Page Switch = 1 | 2117 CCNx Interest Dispatch = 2 | 2118 Fixed Header = 3 | 2119 -----------------------, | 2120 Name | = 38 + n/2 + comps_n 2121 NameSegments = n/2 + | 2122 | comps_n | 2123 -----------------------' | 2124 T_SHA-256 = 32 | 2125 ------------------------------------' 2127 Figure 41: Estimated size of a compressed CCNx Interest 2129 The size difference is: 2130 18 + 3.5n bytes. 2132 For the name "/DE/HH/HAW/BT7", the size is reduced by 53 bytes, which 2133 is 53% of the uncompressed packet. 2135 A.2.2. Content Object 2137 Figure 42 depicts the size requirements for a basic, uncompressed 2138 CCNx Content Object containing an ExpiryTime Message TLV, an 2139 HMAC_SHA-256 signature, the signature time and a hash of the shared 2140 secret key. In the fixed header, the protocol version is assumed to 2141 be 1 and the reserved field is assumed to be 0 2143 ------------------------------------, 2144 Fixed Header = 8 | 2145 Message = 4 | 2146 ---------------------, | 2147 Name | 4 + | 2148 NameSegments = 4n + | 2149 | comps_n | 2150 ---------------------' | 2151 ExpiryTime = 12 = 124 + 4n + comps_n + clen 2152 Payload = 4 + clen | 2153 ---------------------, | 2154 ValidationAlgorithm | | 2155 T_HMAC-256 = 56 | 2156 KeyId | | 2157 SignatureTime | | 2158 ---------------------' | 2159 ValidationPayload = 36 | 2160 ------------------------------------' 2162 Figure 42: Estimated size of an uncompressed CCNx Content Object 2164 Figure 43 depicts the size requirements for a basic, compressed CCNx 2165 Data. 2167 ------------------------------------, 2168 Dispatch Page Switch = 1 | 2169 CCNx Content Dispatch = 3 | 2170 Fixed Header = 2 | 2171 -----------------------, | 2172 Name | | 2173 NameSegments = n/2 + | 2174 | comps_n = 89 + n/2 + comps_n + clen 2175 -----------------------' | 2176 ExpiryTime = 8 | 2177 Payload = 1 + clen | 2178 T_HMAC-SHA256 = 32 | 2179 SignatureTime = 8 | 2180 ValidationPayload = 34 | 2181 ------------------------------------' 2183 Figure 43: Estimated size of a compressed CCNx Data Object 2185 The size difference is: 2186 35 + 3.5n bytes. 2188 For the name "/DE/HH/HAW/BT7", the size is reduced by 70 bytes, which 2189 is 40% of the uncompressed packet containing a 4-byte payload. 2191 Acknowledgments 2193 This work was stimulated by fruitful discussions in the ICNRG 2194 research group and the communities of RIOT and CCNlite. We would 2195 like to thank all active members for constructive thoughts and 2196 feedback. In particular, the authors would like to thank (in 2197 alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, 2198 Colin Perkins, Junxiao Shi. The hop-wise stateful name compression 2199 was brought up in a discussion by Dave Oran, which is gratefully 2200 acknowledged. Larger parts of this work are inspired by [RFC4944] 2201 and [RFC6282]. Special mentioning goes to Mark Mosko as well as G.Q. 2202 Wang and Ravi Ravindran as their previous work in [TLV-ENC-802.15.4] 2203 and [WIRE-FORMAT-CONSID] provided a good base for our discussions on 2204 stateless header compression mechanisms. Many thanks also to Carsten 2205 Bormann, who contributed in-depth comments during the IRSG review. 2206 This work was supported in part by the German Federal Ministry of 2207 Research and Education within the projects I3 and RAPstore. 2209 Authors' Addresses 2210 Cenk Gundogan 2211 HAW Hamburg 2212 Berliner Tor 7 2213 Hamburg D-20099 2214 Germany 2216 Phone: +4940428758067 2217 EMail: cenk.guendogan@haw-hamburg.de 2218 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 2220 Thomas C. Schmidt 2221 HAW Hamburg 2222 Berliner Tor 7 2223 Hamburg D-20099 2224 Germany 2226 EMail: t.schmidt@haw-hamburg.de 2227 URI: http://inet.haw-hamburg.de/members/schmidt 2229 Matthias Waehlisch 2230 link-lab & FU 2231 Berlin 2232 Hoenower Str. 35 2233 Berlin D-10318 2234 Germany 2236 EMail: mw@link-lab.net 2237 URI: http://www.inf.fu-berlin.de/~waehl 2239 Christopher Scherb 2240 University of 2241 Basel 2242 Spiegelgasse 1 2243 Basel CH-4051 2244 Switzerland 2246 EMail: christopher.scherb@unibas.ch 2247 Claudio Marxer 2248 University of 2249 Basel 2250 Spiegelgasse 1 2251 Basel CH-4051 2252 Switzerland 2254 EMail: claudio.marxer@unibas.ch 2256 Christian Tschudin 2257 University of 2258 Basel 2259 Spiegelgasse 1 2260 Basel CH-4051 2261 Switzerland 2263 EMail: christian.tschudin@unibas.ch