idnits 2.17.1 draft-irtf-icnrg-icnlowpan-10.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 (February 10, 2021) is 1171 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-02 Summary: 0 errors (**), 0 flaws (~~), 2 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: August 14, 2021 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 February 10, 2021 13 ICN Adaptation to LoWPAN Networks (ICN LoWPAN) 14 draft-irtf-icnrg-icnlowpan-10 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 August 14, 2021. 54 Copyright Notice 56 Copyright (c) 2021 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 uncompressed. 376 1: The message is compressed. 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=1) use the 390 extended dispatch format in Figure 5. 392 0 1 2 3 4 ... 393 +---+---+---+---+---+--- 394 | 1 | 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) [RFC8930] is an alternative 496 approach that enables forwarding of fragments without reassembling 497 packets on every intermediate hop. By reusing the 6LoWPAN 498 dispatching framework, 6FF integrates into ICN LoWPAN as seamless as 499 the conventional hop-wise fragmentation. Experimental evaluations 500 [SFR-ICNLOWPAN], however, suggest that a more refined integration can 501 increase the cache utilization of forwarders on a request path. 503 5. Space-efficient Message Encoding for NDN 505 5.1. TLV Encoding 507 The NDN packet format consists of TLV fields using the TLV encoding 508 that is described in [NDN-PACKET-SPEC]. Type and length fields are 509 of variable size, where numbers greater than 252 are encoded using 510 multiple bytes. 512 If the type or length number is less than "253", then that number is 513 encoded into the actual type or length field. If the number is 514 greater or equals "253" and fits into 2 bytes, then the type or 515 length field is set to "253" and the number is encoded in the next 516 following 2 bytes in network byte order, i.e., from the most 517 significant byte (MSB) to the least significant byte (LSB). If the 518 number is greater than 2 bytes and fits into 4 bytes, then the type 519 or length field is set to "254" and the number is encoded in the 520 subsequent 4 bytes in network byte order. For larger numbers, the 521 type or length field is set to "255" and the number is encoded in the 522 subsequent 8 bytes in network byte order. 524 In this specification, compressed NDN TLVs encode type and length 525 fields using self-delimiting numeric values (SDNVs) [RFC6256] 526 commonly known from DTN protocols. Instead of using the first byte 527 as a marker for the number of following bytes, SDNVs use a single bit 528 to indicate subsequent bytes. 530 +----------+-----------------------------+--------------------------+ 531 | Value | NDN TLV encoding | SDNV encoding | 532 +----------+-----------------------------+--------------------------+ 533 | 0 | 0x00 | 0x00 | 534 | 127 | 0x7F | 0x7F | 535 | 128 | 0x80 | 0x81 0x00 | 536 | 253 | 0xFD 0x00 0xFD | 0x81 0x7D | 537 | 2^14 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F | 538 | 2^14 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 | 539 | 2^16 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 | 540 | 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F | 541 | 2^21 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 | 542 | 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F | 543 | 2^28 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 | 544 | 2^32 | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 | 545 | | 0x00 0x00 0x00 0x00 | | 546 | 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F | 547 | | 0xFF 0xFF 0xFF 0xFF | | 548 | 2^35 | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 | 549 | | 0x00 0x00 0x00 0x00 | 0x00 | 550 +----------+-----------------------------+--------------------------+ 552 Table 1: NDN TLV encoding compared to SDNVs. 554 Table 1 compares the required bytes for encoding a few selected 555 values using the NDN TLV encoding and SDNVs. For values up to 127, 556 both methods require a single byte. Values in the range [128;252] 557 encode as one byte for the NDN TLV scheme, while SDNVs require two 558 bytes. Starting at value 253, SDNVs require a less or equal amount 559 of bytes compared to the NDN TLV encoding. 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 10. 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 10: 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 "0" and the P as well as the M flag 599 to "0" (Figure 11). The Interest message is handed to the NDN 600 network stack without modifications. 602 0 1 2 3 4 5 6 7 603 +---+---+---+---+---+---+---+---+ 604 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 605 +---+---+---+---+---+---+---+---+ 607 Figure 11: 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 C flag to "1", the P 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 12. The 636 InterestLifetime is encoded as described in Section 7. On 637 decompression, this encoding may yield an Interestlifetime that 638 is smaller than the original value. 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 12. 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 12: Compression of NDN LoWPAN Interest Message 679 Further TLV compression is indicated by the ICN LoWPAN dispatch in 680 Figure 13. 682 0 1 683 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 684 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 685 | 1 | 0 | 0 |CID|EXT|PFX|FRE|FWD|APM|DIG| RSV | 686 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 688 Figure 13: 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 14. 752 0 1 2 3 4 5 6 7 753 +---+---+---+---+---+---+---+---+ 754 | NCS | RSV |EXT| 755 +---+---+---+---+---+---+---+---+ 757 Figure 14: 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 flag to "0", the P flag to "0" and the M flag to "1" 784 (Figure 15). The Data message is handed to the NDN network stack 785 without modifications. 787 0 1 2 3 4 5 6 7 788 +---+---+---+---+---+---+---+---+ 789 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 790 +---+---+---+---+---+---+---+---+ 792 Figure 15: 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 M flags to "1". The P flag 798 is set to "0". 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 16. 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 16: Compression of NDN LoWPAN Data Message 857 Further TLV compression is indicated by the ICN LoWPAN dispatch in 858 Figure 17. 860 0 1 861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 862 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 863 | 1 | 0 | 1 |CID|EXT|FBI|CON|KLO| RSV | 864 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 866 Figure 17: 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 18. 915 0 1 2 3 4 5 6 7 916 +---+---+---+---+---+---+---+---+ 917 | NCS | RSV |EXT| 918 +---+---+---+---+---+---+---+---+ 920 Figure 18: 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 M flag to "0". The P flag is 963 set to "1" (Figure 19). The Interest message is handed to the CCNx 964 network stack without modifications. 966 0 1 2 3 4 5 6 7 967 +---+---+---+---+---+---+---+---+ 968 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 969 +---+---+---+---+---+---+---+---+ 971 Figure 19: 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 P flags to "1". The M flag is set to 977 "0". 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 20. 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 20: Compression of CCNx LoWPAN Interest Message 1020 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1021 Figure 21. 1023 0 1 1024 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1025 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1026 | 1 | 1 | 0 |CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL| 1027 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1029 Figure 21: 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. 1092 MGH: Optional Hop-By-Hop MessageHash TLV 1094 See Section 6.3.2.1 for further details on the ordering 1095 of hop-by-hop TLVs. 1097 This TLV is expected to contain a T_SHA-256 TLV. If 1098 another hash is contained, then the Interest MUST be sent 1099 uncompressed. 1101 0: The MessageHash TLV is absent. 1103 1: A T_SHA-256 TLV is present and the type as well as the 1104 length fields are removed. The length field is assumed 1105 to represent 32 bytes. The outer Message Hash TLV is 1106 omitted. 1108 KIR: Optional KeyIdRestriction TLV 1110 This TLV is expected to contain a T_SHA-256 TLV. If 1111 another hash is contained, then the Interest MUST be sent 1112 uncompressed. 1114 0: The KeyIdRestriction TLV is absent. 1116 1: A T_SHA-256 TLV is present and the type as well as the 1117 length fields are removed. The length field is assumed 1118 to represent 32 bytes. The outer KeyIdRestriction TLV is 1119 omitted. 1121 CHR: Optional ContentObjectHashRestriction TLV 1123 This TLV is expected to contain a T_SHA-256 TLV. If 1124 another hash is contained, then the Interest MUST be sent 1125 uncompressed. 1127 0: The ContentObjectHashRestriction TLV is absent. 1129 1: A T_SHA-256 TLV is present and the type as well as the 1130 length fields are removed. The length field is assumed 1131 to represent 32 bytes. The outer 1132 ContentObjectHashRestriction TLV is omitted. 1134 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 1136 0: No validation related TLVs are present in the Interest 1137 message. 1139 1: Validation related TLVs are present in the Interest 1140 message. An additional byte follows immediately that 1141 handles validation related TLV compressions and is 1142 described in Section 6.3.2.2. 1144 6.3.2.1. Hop-By-Hop Header TLVs Compression 1146 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 1147 optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several 1148 more can be defined in higher level specifications. For the 1149 compression specified in the previous section, the Hop-By-Hop TLVs 1150 are ordered as follows: 1152 1. Interest Lifetime TLV 1154 2. Message Hash TLV 1156 Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed 1157 in the encoded message and they appear in the same order as in the 1158 original message, but after the Interest Lifetime TLV and Message 1159 Hash TLV. 1161 6.3.2.2. Validation 1163 0 1 2 3 4 5 6 7 8 1164 +-------+-------+-------+-------+-------+-------+-------+-------+ 1165 | ValidationAlg | KeyID | RSV | 1166 +-------+-------+-------+-------+-------+-------+-------+-------+ 1168 Figure 22: Dispatch for Interset Validations 1170 ValidationALg: Optional ValidationAlgorithm TLV 1172 0000: An uncompressed ValidationAlgorithm TLV is included. 1174 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1175 ValidationAlgorithm TLV is included. 1177 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1178 ValidationAlgorithm TLV is included. Additionally, a 1179 Sigtime TLV is inlined without a type and a length field. 1181 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1182 no ValidationAlgorithm TLV is included. 1184 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1185 no ValidationAlgorithm TLV is included. Additionally, a 1186 Sigtime TLV is inlined without a type and a length field. 1188 0101: Reserved. 1190 0110: Reserved. 1192 0111: Reserved. 1194 1000: Reserved. 1196 1001: Reserved. 1198 1010: Reserved. 1200 1011: Reserved. 1202 1100: Reserved. 1204 1101: Reserved. 1206 1110: Reserved. 1208 1111: Reserved. 1210 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1212 00: The KeyId TLV is absent. 1214 01: The KeyId TLV is present and uncompressed. 1216 10: A T_SHA-256 TLV is present and the type field as well as 1217 the length fields are removed. The length field is 1218 assumed to represent 32 bytes. The outer KeyId TLV is 1219 omitted. 1221 11: A T_SHA-512 TLV is present and the type field as well as 1222 the length fields are removed. The length field is 1223 assumed to represent 64 bytes. The outer KeyId TLV is 1224 omitted. 1226 RSV: Reserved Must be set to 0. 1228 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1229 is present. The type field is omitted. 1231 6.3.3. Dispatch Extension 1233 The "EXT_0" byte follows the description in Section 4.1.1 and is 1234 illustrated in Figure 23. 1236 0 1 2 3 4 5 6 7 1237 +---+---+---+---+---+---+---+---+ 1238 | NCS | RSV |EXT| 1239 +---+---+---+---+---+---+---+---+ 1241 Figure 23: EXT_0 format 1243 NCS: Name Compression Strategy 1245 00: Names are compressed with the default name 1246 compression strategy (see Section 5.2). 1248 01: Reserved. 1250 10: Reserved. 1252 11: Reserved. 1254 RSV: Reserved Must be set to 0. 1256 EXT: Extension 1258 0: No extension byte follows. 1260 1: A further extension byte follows immediately. 1262 6.4. Content Objects 1264 6.4.1. Uncompressed Content Objects 1266 An uncompressed Content object uses the base dispatch format (see 1267 Figure 4) and sets the C flag to "0", the P and M flags to "1" 1268 (Figure 24). The Content object is handed to the CCNx network stack 1269 without modifications. 1271 0 1 2 3 4 5 6 7 1272 +---+---+---+---+---+---+---+---+ 1273 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1274 +---+---+---+---+---+---+---+---+ 1276 Figure 24: Dispatch format for uncompressed CCNx Content objects 1278 6.4.2. Compressed Content Objects 1280 The compressed Content object uses the extended dispatch format 1281 (Figure 5) and sets the C, P, as well as the M flag to "1". If a 1282 Content object contains TLVs that are not mentioned in the following 1283 compression rules, then this message MUST be sent uncompressed. 1285 By default, the Content object is compressed with the following base 1286 rule set: 1288 1. The PacketType field is elided from the Fixed Header. 1290 2. The Type and Length fields of the CCNx Message TLV are elided and 1291 are obtained from the Fixed Header on decompression. 1293 The compressed CCNx LoWPAN Data message is visualized in Figure 25. 1295 T = Type, L = Length, V = Value 1296 Lc = Compressed Length, Vc = Compressed Value 1297 : = optional field, | = mandatory field 1299 +-----------------------------+ +-------------------------+ 1300 | Uncompr. Fixed Header | | Compr. Fixed Header | 1301 +-----------------------------+ +-------------------------+ 1302 +---------+---------+---------+ +---------+ 1303 : RCT T : RCT L : RCT V : : RCT Vc : 1304 +---------+---------+------.--+ +---------+ 1305 : MSGH T : MSGH L : MSGH V : : MSGH Vc : 1306 +---------+---------+---------+ +---------+ 1307 +---------+---------+ +---------+ 1308 | MSGT T | MSGT L | | Name Vc | 1309 +---------+---------+---------+ +---------+ 1310 | Name T | Name L | Name V | ==> : EXPT Vc : 1311 +---------+---------+---------+ +---------+---------+ 1312 : PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V : 1313 +---------+---------+---------+ +---------+---------+ 1314 : EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc : 1315 +---------+---------+---------+ +---------+---------+ 1316 : PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V : 1317 +---------+---------+---------+ +---------+---------+ 1318 : VALG T : VALG L : VALG V : 1319 +---------+---------+---------+ 1320 : VPAY T : VPAY L : VPAY V : 1321 +---------+---------+---------+ 1323 Figure 25: Compression of CCNx LoWPAN Data Message 1325 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1326 Figure 26. 1328 0 1 1329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1330 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1331 | 1 | 1 | 1 |CID|EXT|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV| 1332 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1334 Figure 26: Dispatch format for compressed CCNx Content objects 1336 CID: Context Identifier See Figure 5. 1338 EXT: Extension 1340 0: No extension byte follows. 1342 1: Extension byte "EXT_0" follows immediately. See 1343 Section 6.4.3. 1345 VER: CCNx protocol version in the fixed header 1347 0: The Version field equals 1 and is removed from the fixed 1348 header. 1350 1: The Version field appears in the fixed header. 1352 FLG: Flags field in the fixed header See Section 6.3.2. 1354 FRS: Reserved field in the fixed header See Section 6.3.2. 1356 PAY: Optional Payload TLV See Section 6.3.2. 1358 RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 1360 0: The Recommended Cache Time TLV is absent. 1362 1: The Recommended Cache Time TLV is present and the type as 1363 well as the length fields are elided. 1365 MGH: Optional Hop-By-Hop MessageHash TLV 1367 See Section 6.4.2.1 for further details on the ordering 1368 of hop-by-hop TLVs. 1370 This TLV is expected to contain a T_SHA-256 TLV. If 1371 another hash is contained, then the Content Object MUST 1372 be sent uncompressed. 1374 0: The MessageHash TLV is absent. 1376 1: A T_SHA-256 TLV is present and the type as well as the 1377 length fields are removed. The length field is assumed 1378 to represent 32 bytes. The outer Message Hash TLV is 1379 omitted. 1381 PLTYP: Optional PayloadType TLV 1383 00: The PayloadType TLV is absent. 1385 01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA 1386 is assumed. 1388 10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY 1389 is assumed. 1391 11: The PayloadType TLV is present and uncompressed. 1393 EXP: Optional ExpiryTime TLV 1395 0: The ExpiryTime TLV is absent. 1397 1: The ExpiryTime TLV is present and the type as well as the 1398 length fields are elided. 1400 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1401 tion 6.3.2. 1403 RSV: Reserved Must be set to 0. 1405 6.4.2.1. Hop-By-Hop Header TLVs Compression 1407 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1408 two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but 1409 several more can be defined in higher level specifications. For the 1410 compression specified in the previous section, the Hop-By-Hop TLVs 1411 are ordered as follows: 1413 1. Recommended Cache Time TLV 1415 2. Message Hash TLV 1417 Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed 1418 in the encoded message and they appear in the same order as in the 1419 original message, but after the Recommended Cache Time TLV and 1420 Message Hash TLV. 1422 6.4.3. Dispatch Extension 1424 The "EXT_0" byte follows the description in Section 4.1.1 and is 1425 illustrated in Figure 27. 1427 0 1 2 3 4 5 6 7 1428 +---+---+---+---+---+---+---+---+ 1429 | NCS | RSV |EXT| 1430 +---+---+---+---+---+---+---+---+ 1432 Figure 27: EXT_0 format 1434 NCS: Name Compression Strategy 1435 00: Names are compressed with the default name 1436 compression strategy (see Section 5.2). 1438 01: Reserved. 1440 10: Reserved. 1442 11: Reserved. 1444 RSV: Reserved Must be set to 0. 1446 EXT: Extension 1448 0: No extension byte follows. 1450 1: A further extension byte follows immediately. 1452 7. Compressed Time Encoding 1454 This document adopts the 8-bit compact time representation for 1455 relative time values described in Section 5 of [RFC5497] with the 1456 constant factor "C" set to "C := 1/32". 1458 Valid time offsets in CCNx and NDN reach from a few milliseconds 1459 (e.g., lifetime of low-latency Interests) to several years (e.g., 1460 content freshness periods in caches). Therefore, this document adds 1461 two modifications to the compression algorithm. 1463 The first modification is the inclusion of a subnormal form 1464 [IEEE.754.2019] for time-codes with exponent 0 to provide an 1465 increased precision and a gradual underflow for the smallest numbers. 1466 The formula is changed as follows (a := mantissa; b := exponent): 1468 Subnormal (b == 0): (0 + a/8) * 2 * C 1470 Normalized (b > 0): (1 + a/8) * 2^b * C (see [RFC5497]) 1472 This configuration allows for the following ranges: 1474 o Minimum subnormal number: 0 seconds 1476 o 2nd minimum subnormal number: ~0.007812 seconds 1478 o Maximum subnormal number: ~0.054688 seconds 1480 o Minimum normalized number: ~0.062500 seconds 1482 o 2nd minimum normalized number: ~0.070312 seconds 1483 o Maximum normalized number: ~3.99 years 1485 The second modification only applies to uncompressible time offsets 1486 that are outside any security envelope. An invalid time-value MUST 1487 be set to the largest valid time-value that is smaller than the 1488 invalid input value before compression. 1490 8. Stateful Header Compression 1492 Stateful header compression in ICN LoWPAN enables packet size 1493 reductions in two ways. First, common information that is shared 1494 throughout the local LoWPAN may be memorized in context state at all 1495 nodes and omitted from communication. Second, redundancy in a single 1496 Interest-data exchange may be removed from ICN stateful forwarding on 1497 a hop-by-hop bases and memorized in en-route state tables. 1499 8.1. LoWPAN-local State 1501 A context identifier (CID) is a byte that refers to a particular 1502 conceptual context between network devices and MAY be used to replace 1503 frequently appearing information, such as name prefixes, suffixes, or 1504 meta information, such as Interest lifetime. 1506 0 1 2 3 4 5 6 7 1507 +---+---+---+---+---+---+---+---+ 1508 | X | ContextID | 1509 +---+---+---+---+---+---+---+---+ 1511 Figure 28: Context Identifier. 1513 The 7-bit ContextID is a locally-scoped unique identifier that 1514 represents contextual state shared between sender and receiver of the 1515 corresponding frame (see Figure 28). If set the most significant bit 1516 indicates the presence of another, subsequent ContextID byte (see 1517 Figure 33). 1519 Context state shared between senders and receivers is removed from 1520 the compressed packet prior to sending, and reinserted after 1521 reception prior to passing to the upper stack. 1523 The actual information in a context and how it is encoded are out of 1524 scope of this document. The initial distribution and maintenance of 1525 shared context is out of scope of this document. Frames containing 1526 unknown or invalid CIDs MUST be silently discarded. 1528 8.2. En-route State 1530 In CCNx and NDN, Name TLVs are included in Interest messages, and 1531 they return in data messages. Returning Name TLVs either equal the 1532 original Name TLV, or they contain the original Name TLV as a prefix. 1533 ICN LoWPAN reduces this redundancy in responses by replacing Name 1534 TLVs with single bytes that represent link-local HopIDs. HopIDs are 1535 carried as Context Identifiers (see Section 8.1) of link-local scope 1536 as shown in Figure 29. 1538 0 1 2 3 4 5 6 7 1539 +---+---+---+---+---+---+---+---+ 1540 | X | HopID | 1541 +---+---+---+---+---+---+---+---+ 1543 Figure 29: Context Identifier as HopID. 1545 A HopID is valid if not all ID bits are set to zero and invalid 1546 otherwise. This yields 127 distinct HopIDs. If this range (1...127) 1547 is exhausted, the messages MUST be sent without en-route state 1548 compression until new HopIDs are available. An ICN LoWPAN node that 1549 forwards without replacing the name by a HopID (without en-route 1550 compression) MUST invalidate the HopID by setting all ID-bits to 1551 zero. 1553 While an Interest is traversing, a forwarder generates an ephemeral 1554 HopID that is tied to a PIT entry. Each HopID MUST be unique within 1555 the local PIT and only exists during the lifetime of a PIT entry. To 1556 maintain HopIDs, the local PIT is extended by two new columns: HIDi 1557 (inbound HopIDs) and HIDo (outbound HopIDs). 1559 HopIDs are included in Interests and stored on the next hop with the 1560 resulting PIT entry in the HIDi column. The HopID is replaced with a 1561 newly generated local HopID before the Interest is forwarded. This 1562 new HopID is stored in the HIDo column of the local PIT (see 1563 Figure 30). 1565 PIT of B PIT Extension PIT of C PIT Extension 1566 +--------+------++------+------+ +--------+------++------+------+ 1567 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1568 +========+======++======+======+ +========+======++======+======+ 1569 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1570 +--------+------++------+------+ +--------+------++------+------+ 1571 ^ | ^ 1572 store | '----------------------, ,---' store 1573 | send v | 1574 ,---, /p0, h_A ,---, /p0, h_B ,---, 1575 | A | ------------------------> | B | ------------------------> | C | 1576 '---' '---' '---' 1578 Figure 30: Setting compression state en-route (Interest). 1580 Responses include HopIDs that were obtained from Interests. If the 1581 returning Name TLV equals the original Name TLV, then the name is 1582 entirely elided. Otherwise, only the matching name prefix is elided 1583 and the distinct name suffix is included along with the HopID. When 1584 a response is forwarded, the contained HopID is extracted and used to 1585 match against the correct PIT entry by performing a lookup on the 1586 HIDo column. The HopID is then replaced with the corresponding HopID 1587 from the HIDi column prior to forwarding the response (Figure 31). 1589 PIT of B PIT Extension PIT of C PIT Extension 1590 +--------+------++------+------+ +--------+------++------+------+ 1591 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1592 +========+======++======+======+ +========+======++======+======+ 1593 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1594 +--------+------++------+------+ +--------+------++------+------+ 1595 | ^ | 1596 send | '----------------------, ,---' send 1597 v match | v 1598 ,---, h_A ,---, h_B ,---, 1599 | A | <------------------------ | B | <------------------------ | C | 1600 '---' '---' '---' 1602 Figure 31: Eliding Name TLVs using en-route state (data). 1604 It should be noted that each forwarder of an Interest in an ICN 1605 LoWPAN network can individually decide whether to participate in en- 1606 route compression or not. However, an ICN LoWPAN node SHOULD use en- 1607 route compression whenever the stateful compression mechanism is 1608 activated. 1610 Note also that the extensions of the PIT data structure are required 1611 only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside 1612 of an ICN LoWPAN domain do not need to implement these extensions. 1614 8.3. Integrating Stateful Header Compression 1616 A CID appears whenever the CID flag is set (see Figure 5). The CID 1617 is appended to the last ICN LoWPAN dispatch byte as shown in 1618 Figure 32. 1620 ...-------+--------+-------...-------+--...-+-------... 1621 / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / 1622 ...-------+--------+-------...-------+--...-+-------... 1624 Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs 1626 Multiple CIDs are chained together, with the most significant bit 1627 indicating the presence of a subsequent CID (Figure 33). This allows 1628 to use multiple shared contexts in compressed messages. 1630 The HopID is always included as the very first CID. 1632 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1633 |1| CID / HopID | --> |1| CID | --> |0| CID | 1634 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1636 Figure 33: Chaining of context identifiers. 1638 9. ICN LoWPAN Constants and Variables 1640 This is a summary of all ICN LoWPAN constants and variables. 1642 DEFAULT_NDN_HOPLIMIT: 255 1644 10. Implementation Report and Guidance 1646 The ICN LoWPAN scheme defined in this document has been implemented 1647 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT 1648 version on RIOT [RIOT]. An experimental evaluation for NDN over ICN 1649 LOWPAN with varying configurations has been performed in [ICNLOWPAN]. 1650 Energy profilings and processing time measurements indicate 1651 significant energy savings, while amortized costs for processing show 1652 no penalties. 1654 10.1. Preferred Configuration 1656 The header compression performance depends on certain aspects and 1657 configurations. It works best for the following cases: 1659 o Signed time offsets compress as per Section 7 without the need for 1660 rounding. 1662 o Contextual state (e.g., prefixes) is distributed, such that long 1663 names can be elided from Interest and data messages. 1665 o Frequently used TLV type numbers for CCNx and NDN stay in the 1666 lower range (< 255). 1668 Name components are of GenericNameComponent type and are limited to a 1669 length of 15 bytes to enable compression for all messages. 1671 10.2. Further Experimental Deployments 1673 An investigation of ICN LoWPAN in large-scale deployments with 1674 varying traffic patterns using larger samples of the different board 1675 types available remains as future work. This document will be 1676 revised to progress it to the Standards Track, once sufficient 1677 operational experience has been acquired. Experience reports are 1678 encouraged, particularly in the following areas: 1680 o The name compression scheme (Section 5.2) is optimized for short 1681 name components of GenericNameComponent type. An empirical study 1682 on name lengths in different deployments of selected use cases, 1683 such as smart home, smart city, and industrial IoT can provide 1684 meaningful reports on necessary name component types and lengths. 1685 A conclusive outcome helps to understand whether and how extension 1686 mechanisms are needed (Section 5.3.3). As a preliminary analysis, 1687 [ICNLOWPAN] investigates the effectiveness of the proposed 1688 compression scheme with URLs obtained from the WWW. Studies on 1689 CoAP [RFC7252] deployments can offer additional insights on naming 1690 schemes in the IoT. 1692 o The fragmentation scheme (Section 4.2) inherited from 6LoWPAN 1693 allows for a transparent, hop-wise reassembly of CCNx or NDN 1694 packets. Fragment forwarding [RFC8930] with selective fragment 1695 recovery [RFC8931] can improve the end-to-end latency and 1696 reliability, while it reduces buffer requirements on forwarders. 1697 Initial evaluations ([SFR-ICNLOWPAN]) show that a naive 1698 integration of these upcoming fragmentation features into ICN 1699 LoWPAN renders the hop-wise content replication inoperative, since 1700 Interest and data messages are reassembled end-to-end. More 1701 deployment experiences are necessary to gauge the feasibility of 1702 different fragmentation schemes in ICN LoWPAN. 1704 o Context state (Section 8.1) holds information that is shared 1705 between a set of devices in a LoWPAN. Fixed name prefixes and 1706 suffixes are good candidates to be distributed to all nodes in 1707 order to elide them from request and response messages. More 1708 experience and a deeper inspection of currently available and 1709 upcoming protocol features is necessary to identify other protocol 1710 fields. 1712 o The distribution and synchronization of contextual state can 1713 potentially be adopted from Section 7.2 of [RFC6775], but requires 1714 further evaluations. While 6LoWPAN uses the Neighbor Discovery 1715 protocol to disseminate state, CCNx and NDN deployments are 1716 missing out on a standard mechanism to bootstrap and manage 1717 configurations. 1719 o The stateful en-route compression (Section 8.2) supports a limited 1720 number of 127 distinct HopIDs that can be simultaneously in use on 1721 a single node. Complex deployment scenarios that make use of 1722 multiple, concurrent requests can provide a better insight on the 1723 number of open requests stored in the Pending Interest Table of 1724 memory-constrained devices. This number can serve as an upper- 1725 bound and determines whether the HopID length needs to be resized 1726 to fit more HopIDs to the cost of additional header overhead. 1728 o Multiple implementations that generate and deploy the compression 1729 options of this memo in different ways will also add to the 1730 experience and understanding of the benefits and limitations of 1731 the proposed schemes. Different reports can help to illuminate on 1732 the complexity of implementing ICN LoWPAN for constrained devices, 1733 as well as on maintaining interoperability with other 1734 implementations. 1736 11. Security Considerations 1738 Main memory is typically a scarce resource of constrained networked 1739 devices. Fragmentation as described in this memo preserves fragments 1740 and purges them only after a packet is reassembled, which requires a 1741 buffering of all fragments. This scheme is able to handle fragments 1742 for distinctive packets simultaneously, which can lead to overflowing 1743 packet buffers that cannot hold all necessary fragments for packet 1744 reassembly. Implementers are thus urged to make use of appropriate 1745 buffer replacement strategies for fragments. Minimal fragment 1746 forwarding [RFC8930] can potentially prevent fragment buffer 1747 saturation in forwarders. 1749 The stateful header compression generates ephemeral HopIDs for 1750 incoming and outgoing Interests and consumes them on returning Data 1751 packets. Forged Interests can deplete the number of available 1752 HopIDs, thus leading to a denial of compression service for 1753 subsequent content requests. 1755 To further alleviate the problems caused by forged fragments or 1756 Interest initiations, proper protective mechanisms for accessing the 1757 link-layer should be deployed. IEEE 802.15.4, e.g., provides 1758 capabilities to protect frames and restrict them to a point-to-point 1759 link, or a group of devices. 1761 12. IANA Considerations 1763 12.1. Reserving Space in the 6LoWPAN Dispatch Type Field Registry 1765 IANA has assigned dispatch values of the "6LoWPAN Dispatch Type 1766 Field" registry [RFC4944][RFC8025] with Page TBD1 for ICN LoWPAN. 1767 Table 2 represents updates to the registry. 1769 +-------------+------+-------------------------------------------+ 1770 | Bit Pattern | Page | Header Type | 1771 +-------------+------+-------------------------------------------+ 1772 | 00 000000 | TBD1 | Uncompressed NDN Interest messages | 1773 | 00 100000 | TBD1 | Uncompressed NDN Data messages | 1774 | 01 000000 | TBD1 | Uncompressed CCNx Interest messages | 1775 | 01 100000 | TBD1 | Uncompressed CCNx Content Object messages | 1776 | 10 0xxxxx | TBD1 | Compressed NDN Interest messages | 1777 | 10 1xxxxx | TBD1 | Compressed NDN Data messages | 1778 | 11 0xxxxx | TBD1 | Compressed CCNx Interest messages | 1779 | 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages | 1780 +-------------+------+-------------------------------------------+ 1782 Table 2: Dispatch types for NDN and CCNx with page TBD1. 1784 13. References 1786 13.1. Normative References 1788 [IEEE.754.2019] 1789 Institute of Electrical and Electronics Engineers, C/MSC - 1790 Microprocessor Standards Committee, "Standard for 1791 Floating-Point Arithmetic", June 2019, 1792 . 1795 [ieee802.15.4] 1796 "IEEE Std. 802.15.4-2015", April 2016, 1797 . 1800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1801 Requirement Levels", BCP 14, RFC 2119, 1802 DOI 10.17487/RFC2119, March 1997, 1803 . 1805 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1806 "Transmission of IPv6 Packets over IEEE 802.15.4 1807 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1808 . 1810 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1811 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1812 DOI 10.17487/RFC5497, March 2009, 1813 . 1815 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 1816 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 1817 2011, . 1819 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1820 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1821 DOI 10.17487/RFC6282, September 2011, 1822 . 1824 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1825 Bormann, "Neighbor Discovery Optimization for IPv6 over 1826 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1827 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1828 . 1830 13.2. Informative References 1832 [CCN-LITE] 1833 "CCN-lite: A lightweight CCNx and NDN implementation", 1834 . 1836 [I-D.irtf-icnrg-flic] 1837 Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like 1838 ICN Collections (FLIC)", draft-irtf-icnrg-flic-02 (work in 1839 progress), November 2019. 1841 [ICNLOWPAN] 1842 Gundogan, C., Kietzmann, P., Schmidt, TC., and M. 1843 Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low 1844 Power IoT Networks", Proc. of 18th IFIP Networking 1845 Conference, May 2019, 1846 . 1848 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1849 "Networking Named Content", 5th Int. Conf. on emerging 1850 Networking Experiments and Technologies (ACM CoNEXT), 1851 2009, . 1853 [NDN-EXP1] 1854 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1855 Waehlisch, "Information Centric Networking in the IoT: 1856 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1857 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1858 77-86, September 2014, 1859 . 1861 [NDN-EXP2] 1862 Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 1863 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 1864 Comparative Measurement Study in the IoT", Proc. of 5th 1865 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 1866 DL, pp. 159-171, September 2018, 1867 . 1869 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1870 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1871 in NDN: Towards Quantifying the Resource Gain", Proc. of 1872 4th ACM Conf. on Information-Centric Networking (ICN- 1873 2017) ACM DL, pp. 36-42, September 2017, 1874 . 1876 [NDN-PACKET-SPEC] 1877 "NDN Packet Format Specification", 1878 . 1880 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1881 Constrained-Node Networks", RFC 7228, 1882 DOI 10.17487/RFC7228, May 2014, 1883 . 1885 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1886 Application Protocol (CoAP)", RFC 7252, 1887 DOI 10.17487/RFC7252, June 2014, 1888 . 1890 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1891 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1892 "Information-Centric Networking: Baseline Scenarios", 1893 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1894 . 1896 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1897 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1898 "Information-Centric Networking (ICN) Research 1899 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1900 . 1902 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1903 and G. Boggia, "Information-Centric Networking: Evaluation 1904 and Security Considerations", RFC 7945, 1905 DOI 10.17487/RFC7945, September 2016, 1906 . 1908 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1909 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1910 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1911 . 1913 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1914 Networking (CCNx) Semantics", RFC 8569, 1915 DOI 10.17487/RFC8569, July 2019, 1916 . 1918 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1919 Networking (CCNx) Messages in TLV Format", RFC 8609, 1920 DOI 10.17487/RFC8609, July 2019, 1921 . 1923 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 1924 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 1925 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 1926 . 1928 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 1929 Area Network (6LoWPAN) Selective Fragment Recovery", 1930 RFC 8931, DOI 10.17487/RFC8931, November 2020, 1931 . 1933 [RIOT] Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., 1934 Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., 1935 and M. Waehlisch, "RIOT: an Open Source Operating System 1936 for Low-end Embedded Devices in the IoT", IEEE Internet of 1937 Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018, 1938 . 1940 [SFR-ICNLOWPAN] 1941 Lenders, M., Gundogan, C., Schmidt, TC., and M. Waehlisch, 1942 "Connecting the Dots: Selective Fragment Recovery in 1943 ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric 1944 Networking (ICN-2020) ACM DL, pp. 70-76, September 2020, 1945 . 1947 [TLV-ENC-802.15.4] 1948 "CCN and NDN TLV encodings in 802.15.4 packets", 1949 . 1952 [WIRE-FORMAT-CONSID] 1953 "CCN/NDN Protocol Wire Format and Functionality 1954 Considerations", . 1958 Appendix A. Estimated Size Reduction 1960 In the following a theoretical evaluation is given to estimate the 1961 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1963 We assume that "n" is the number of name components, "comps_n" 1964 denotes the sum of n name component lengths. We also assume that the 1965 length of each name component is lower than 16 bytes. The length of 1966 the content is given by "clen". The lengths of TLV components is 1967 specific to the CCNx or NDN encoding and outlined below. 1969 A.1. NDN 1971 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1972 the 1 byte form of each TLV component is assumed. A typical TLV 1973 component therefore is of size 2 (type field + length field) + the 1974 actual value. 1976 A.1.1. Interest 1978 Figure 34 depicts the size requirements for a basic, uncompressed NDN 1979 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1980 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1981 Numbers below represent the amount of bytes. 1983 ------------------------------------, 1984 Interest TLV = 2 | 1985 ---------------------, | 1986 Name | 2 + | 1987 NameComponents = 2n + | 1988 | comps_n | 1989 ---------------------' = 21 + 2n + comps_n 1990 CanBePrefix = 2 | 1991 MustBeFresh = 2 | 1992 Nonce = 6 | 1993 InterestLifetime = 4 | 1994 HopLimit = 3 | 1995 ------------------------------------' 1997 Figure 34: Estimated size of an uncompressed NDN Interest 1999 Figure 35 depicts the size requirements after compression. 2001 ------------------------------------, 2002 Dispatch Page Switch = 1 | 2003 NDN Interset Dispatch = 2 | 2004 Interest TLV = 1 | 2005 -----------------------, | 2006 Name | | 2007 NameComponents = n/2 + = 10 + n/2 + comps_n 2008 | comps_n | 2009 -----------------------' | 2010 Nonce = 4 | 2011 HopLimit = 1 | 2012 InterestLifetime = 1 | 2013 ------------------------------------' 2015 Figure 35: Estimated size of a compressed NDN Interest 2017 The size difference is: 2018 11 + 1.5n bytes. 2020 For the name "/DE/HH/HAW/BT7", the total size gain is 17 bytes, which 2021 is 43% of the uncompressed packet. 2023 A.1.2. Data 2025 Figure 36 depicts the size requirements for a basic, uncompressed NDN 2026 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 2027 1 minute is assumed and the value is encoded using 1 byte. An 2028 HMACWithSha256 is assumed as signature. The key locator is assumed 2029 to contain a Name TLV of length klen. 2031 ------------------------------------, 2032 Data TLV = 2 | 2033 ---------------------, | 2034 Name | 2 + | 2035 NameComponents = 2n + | 2036 | comps_n | 2037 ---------------------' | 2038 ---------------------, | 2039 MetaInfo | | 2040 FreshnessPeriod = 6 | 2041 | = 53 + 2n + comps_n + 2042 ---------------------' | clen + klen 2043 Content = 2 + clen | 2044 ---------------------, | 2045 SignatureInfo | | 2046 SignatureType | | 2047 KeyLocator = 41 + klen | 2048 SignatureValue | | 2049 DigestSha256 | | 2050 ---------------------' | 2051 ------------------------------------' 2053 Figure 36: Estimated size of an uncompressed NDN Data 2055 Figure 37 depicts the size requirements for the compressed version of 2056 the above Data packet. 2058 ------------------------------------, 2059 Dispatch Page Switch = 1 | 2060 NDN Data Dispatch = 2 | 2061 -----------------------, | 2062 Name | | 2063 NameComponents = n/2 + | 2064 | comps_n = 38 + n/2 + comps_n + 2065 -----------------------' | clen + klen 2066 Content = 1 + clen | 2067 KeyLocator = 1 + klen | 2068 DigestSha256 = 32 | 2069 FreshnessPeriod = 1 | 2070 ------------------------------------' 2072 Figure 37: Estimated size of a compressed NDN Data 2074 The size difference is: 2075 15 + 1.5n bytes. 2077 For the name "/DE/HH/HAW/BT7", the total size gain is 21 bytes. 2079 A.2. CCNx 2081 The CCNx TLV encoding defines a 2-byte encoding for type and length 2082 fields, summing up to 4 bytes in total without a value. 2084 A.2.1. Interest 2086 Figure 38 depicts the size requirements for a basic, uncompressed 2087 CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version 2088 is assumed to be 1 and the reserved field is assumed to be 0. A 2089 KeyIdRestriction TLV with T_SHA-256 is included to limit the 2090 responses to Content Objects containing the specific key. 2092 ------------------------------------, 2093 Fixed Header = 8 | 2094 Message = 4 | 2095 ---------------------, | 2096 Name | 4 + = 56 + 4n + comps_n 2097 NameSegments = 4n + | 2098 | comps_n | 2099 ---------------------' | 2100 KeyIdRestriction = 40 | 2101 ------------------------------------' 2103 Figure 38: Estimated size of an uncompressed CCNx Interest 2105 Figure 39 depicts the size requirements after compression. 2107 ------------------------------------, 2108 Dispatch Page Switch = 1 | 2109 CCNx Interest Dispatch = 2 | 2110 Fixed Header = 3 | 2111 -----------------------, | 2112 Name | = 38 + n/2 + comps_n 2113 NameSegments = n/2 + | 2114 | comps_n | 2115 -----------------------' | 2116 T_SHA-256 = 32 | 2117 ------------------------------------' 2119 Figure 39: Estimated size of a compressed CCNx Interest 2121 The size difference is: 2122 18 + 3.5n bytes. 2124 For the name "/DE/HH/HAW/BT7", the size is reduced by 53 bytes, which 2125 is 53% of the uncompressed packet. 2127 A.2.2. Content Object 2129 Figure 40 depicts the size requirements for a basic, uncompressed 2130 CCNx Content Object containing an ExpiryTime Message TLV, an 2131 HMAC_SHA-256 signature, the signature time and a hash of the shared 2132 secret key. In the fixed header, the protocol version is assumed to 2133 be 1 and the reserved field is assumed to be 0 2135 ------------------------------------, 2136 Fixed Header = 8 | 2137 Message = 4 | 2138 ---------------------, | 2139 Name | 4 + | 2140 NameSegments = 4n + | 2141 | comps_n | 2142 ---------------------' | 2143 ExpiryTime = 12 = 124 + 4n + comps_n + clen 2144 Payload = 4 + clen | 2145 ---------------------, | 2146 ValidationAlgorithm | | 2147 T_HMAC-256 = 56 | 2148 KeyId | | 2149 SignatureTime | | 2150 ---------------------' | 2151 ValidationPayload = 36 | 2152 ------------------------------------' 2154 Figure 40: Estimated size of an uncompressed CCNx Content Object 2156 Figure 41 depicts the size requirements for a basic, compressed CCNx 2157 Data. 2159 ------------------------------------, 2160 Dispatch Page Switch = 1 | 2161 CCNx Content Dispatch = 3 | 2162 Fixed Header = 2 | 2163 -----------------------, | 2164 Name | | 2165 NameSegments = n/2 + | 2166 | comps_n = 89 + n/2 + comps_n + clen 2167 -----------------------' | 2168 ExpiryTime = 8 | 2169 Payload = 1 + clen | 2170 T_HMAC-SHA256 = 32 | 2171 SignatureTime = 8 | 2172 ValidationPayload = 34 | 2173 ------------------------------------' 2175 Figure 41: Estimated size of a compressed CCNx Data Object 2177 The size difference is: 2178 35 + 3.5n bytes. 2180 For the name "/DE/HH/HAW/BT7", the size is reduced by 70 bytes, which 2181 is 40% of the uncompressed packet containing a 4-byte payload. 2183 Acknowledgments 2185 This work was stimulated by fruitful discussions in the ICNRG 2186 research group and the communities of RIOT and CCNlite. We would 2187 like to thank all active members for constructive thoughts and 2188 feedback. In particular, the authors would like to thank (in 2189 alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, 2190 Colin Perkins, Junxiao Shi. The hop-wise stateful name compression 2191 was brought up in a discussion by Dave Oran, which is gratefully 2192 acknowledged. Larger parts of this work are inspired by [RFC4944] 2193 and [RFC6282]. Special mentioning goes to Mark Mosko as well as G.Q. 2194 Wang and Ravi Ravindran as their previous work in [TLV-ENC-802.15.4] 2195 and [WIRE-FORMAT-CONSID] provided a good base for our discussions on 2196 stateless header compression mechanisms. Many thanks also to Carsten 2197 Bormann and Lars Eggert, who contributed in-depth comments during the 2198 IRSG review. This work was supported in part by the German Federal 2199 Ministry of Research and Education within the projects I3 and 2200 RAPstore. 2202 Authors' Addresses 2203 Cenk Gundogan 2204 HAW Hamburg 2205 Berliner Tor 7 2206 Hamburg D-20099 2207 Germany 2209 Phone: +4940428758067 2210 EMail: cenk.guendogan@haw-hamburg.de 2211 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 2213 Thomas C. Schmidt 2214 HAW Hamburg 2215 Berliner Tor 7 2216 Hamburg D-20099 2217 Germany 2219 EMail: t.schmidt@haw-hamburg.de 2220 URI: http://inet.haw-hamburg.de/members/schmidt 2222 Matthias Waehlisch 2223 link-lab & FU 2224 Berlin 2225 Hoenower Str. 35 2226 Berlin D-10318 2227 Germany 2229 EMail: mw@link-lab.net 2230 URI: http://www.inf.fu-berlin.de/~waehl 2232 Christopher Scherb 2233 University of 2234 Basel 2235 Spiegelgasse 1 2236 Basel CH-4051 2237 Switzerland 2239 EMail: christopher.scherb@unibas.ch 2240 Claudio Marxer 2241 University of 2242 Basel 2243 Spiegelgasse 1 2244 Basel CH-4051 2245 Switzerland 2247 EMail: claudio.marxer@unibas.ch 2249 Christian Tschudin 2250 University of 2251 Basel 2252 Spiegelgasse 1 2253 Basel CH-4051 2254 Switzerland 2256 EMail: christian.tschudin@unibas.ch