idnits 2.17.00 (12 Aug 2021) /tmp/idnits65024/draft-irtf-icnrg-icnlowpan-11.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 33 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 September 2021) is 229 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-irtf-icnrg-flic-02 Summary: 1 error (**), 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: 31 March 2022 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 27 September 2021 13 ICN Adaptation to LoWPAN Networks (ICN LoWPAN) 14 draft-irtf-icnrg-icnlowpan-11 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 31 March 2022. 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 (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 6 70 3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 6 71 3.2. Stateless Header Compression . . . . . . . . . . . . . . 6 72 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 8 73 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 8 74 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Dispatch Extensions . . . . . . . . . . . . . . . . . 9 76 4.2. Adaptation Layer Fragmentation . . . . . . . . . . . . . 10 77 5. Space-efficient Message Encoding for NDN . . . . . . . . . . 11 78 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 11 79 5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 13 80 5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 13 81 5.3.1. Uncompressed Interest Messages . . . . . . . . . . . 13 82 5.3.2. Compressed Interest Messages . . . . . . . . . . . . 14 83 5.3.3. Dispatch Extension . . . . . . . . . . . . . . . . . 16 84 5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 17 85 5.4.1. Uncompressed Data Messages . . . . . . . . . . . . . 17 86 5.4.2. Compressed Data Messages . . . . . . . . . . . . . . 17 87 5.4.3. Dispatch Extension . . . . . . . . . . . . . . . . . 19 88 6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 20 89 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 20 90 6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 20 91 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 20 92 6.3.1. Uncompressed Interest Messages . . . . . . . . . . . 20 93 6.3.2. Compressed Interest Messages . . . . . . . . . . . . 21 94 6.3.3. Dispatch Extension . . . . . . . . . . . . . . . . . 26 96 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 27 97 6.4.1. Uncompressed Content Objects . . . . . . . . . . . . 27 98 6.4.2. Compressed Content Objects . . . . . . . . . . . . . 27 99 6.4.3. Dispatch Extension . . . . . . . . . . . . . . . . . 30 100 7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 31 101 8. Stateful Header Compression . . . . . . . . . . . . . . . . . 32 102 8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 32 103 8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 32 104 8.3. Integrating Stateful Header Compression . . . . . . . . . 34 105 9. ICN LoWPAN Constants and Variables . . . . . . . . . . . . . 35 106 10. Implementation Report and Guidance . . . . . . . . . . . . . 35 107 10.1. Preferred Configuration . . . . . . . . . . . . . . . . 35 108 10.2. Further Experimental Deployments . . . . . . . . . . . . 36 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 110 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 111 12.1. Reserving Space in the 6LoWPAN Dispatch Type Field 112 Registry . . . . . . . . . . . . . . . . . . . . . . . . 38 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 115 13.2. Informative References . . . . . . . . . . . . . . . . . 39 116 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 42 117 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 118 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 42 119 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 43 120 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 45 121 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 45 122 A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 46 123 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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 typically 143 battery-operated and constrained in resources. Characteristics of 144 LLNs include an unreliable environment, low bandwidth transmissions, 145 and increased latencies. IEEE 802.15.4 admits a maximum physical 146 layer packet size of 127 bytes. The maximum frame header size is 25 147 bytes, which leaves 102 bytes for the payload. IEEE 802.15.4 148 security features further reduce this payload length by up to 21 149 bytes, yielding a net of 81 bytes for CCNx or NDN packet headers, 150 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 3 ... 366 +---+---+---+---+--- 367 | 0 | P | M | C | 368 +---+---+---+---+--- 370 Figure 4: Base dispatch format for ICN LoWPAN 372 P: Protocol 0: The included protocol is NDN. 374 1: The included protocol is CCNx. 376 M: Message Type 0: The payload contains an Interest message. 378 1: The payload contains a Data message. 380 C: Compression 0: The message is uncompressed. 382 1: The message is compressed. 384 ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the 385 extended dispatch format in Figure 5. 387 0 1 2 3 ... ... 388 +---+---+---+---+...+---+---+ 389 | 0 | P | M | 1 | |CID|EXT| 390 +---+---+---+---+...+---+---+ 392 Figure 5: Extended dispatch format for compressed ICN LoWPAN 394 CID: Context Identifier 0: No context identifiers are present. 396 1: Context identifier(s) are present (see 397 Section 8.1). 399 EXT: Extension 0: No extension bytes are present. 401 1: Extension byte(s) are present (see 402 Section 4.1.1). 404 The encapsulation format for ICN LoWPAN is displayed in Figure 6. 406 +------...------+------...-----+--------+-------...-------+-----... 407 | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / 408 +------...------+------...-----+--------+-------...-------+-----... 410 Figure 6: LoWPAN Encapsulation with ICN-LoWPAN 412 IEEE 802.15.4: The IEEE 802.15.4 header. 414 RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 415 of [RFC4944] 417 Page: Page Switch. TBD1 for ICN LoWPAN. 419 ICN LoWPAN: Dispatches as defined in Section 5 and Section 6. 421 Payload: The actual (un-)compressed CCNx or NDN message. 423 4.1.1. Dispatch Extensions 425 Extension bytes allow for the extensibility of the initial 426 compression rule set. The base format for an extension byte is 427 depicted in Figure 7. 429 0 1 2 3 4 5 6 7 430 +---+---+---+---+---+---+---+---+ 431 | - | - | - | - | - | - | - |EXT| 432 +---+---+---+---+---+---+---+---+ 434 Figure 7: Base format for dispatch extensions. 436 EXT: Extension 0: No other extension byte follows. 438 1: A further extension byte follows. 440 Extension bytes are numbered according to their order. Future 441 documents MUST follow the naming scheme EXT_0, EXT_1, ..., when 442 updating or referring to a specific dispatch extension byte. 443 Amendments that require an exchange of configurational parameters 444 between devices SHOULD use manifests to encode structured data in a 445 well-defined format, as, e.g., outlined in [I-D.irtf-icnrg-flic]. 447 4.2. Adaptation Layer Fragmentation 449 Small payload sizes in the LoWPAN require fragmentation for various 450 network layers. Therefore, Section 5.3 of [RFC4944] defines a 451 protocol-independent fragmentation dispatch type, a fragmentation 452 header for the first fragment, and a separate fragmentation header 453 for subsequent fragments. ICN LoWPAN adopts this fragmentation 454 handling of [RFC4944]. 456 The Fragmentation LoWPAN header can encapsulate other dispatch 457 headers. The order of dispatch types is defined in Section 5 of 458 [RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled 459 ICN LoWPAN frame does not contain any fragmentation headers and is 460 depicted in Figure 9. 462 +------...------+----...----+--------+------...-------+--------... 463 | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / 464 +------...------+----...----+--------+------...-------+--------... 466 +------...------+----...----+--------... 467 | IEEE 802.15.4 | Frag. 2nd | Payload / 468 +------...------+----...----+--------... 470 . 471 . 472 . 474 +------...------+----...----+--------... 475 | IEEE 802.15.4 | Frag. Nth | Payload / 476 +------...------+----...----+--------... 478 Figure 8: Fragmentation scheme 480 +------...------+--------+------...-------+--------... 481 | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / 482 +------...------+--------+------...-------+--------... 484 Figure 9: Reassembled ICN LoWPAN frame 486 The 6LoWPAN Fragment Forwarding (6FF) [RFC8930] is an alternative 487 approach that enables forwarding of fragments without reassembling 488 packets on every intermediate hop. By reusing the 6LoWPAN 489 dispatching framework, 6FF integrates into ICN LoWPAN as seamless as 490 the conventional hop-wise fragmentation. Experimental evaluations 491 [SFR-ICNLOWPAN], however, suggest that a more refined integration can 492 increase the cache utilization of forwarders on a request path. 494 5. Space-efficient Message Encoding for NDN 496 5.1. TLV Encoding 498 The NDN packet format consists of TLV fields using the TLV encoding 499 that is described in [NDN-PACKET-SPEC]. Type and length fields are 500 of variable size, where numbers greater than 252 are encoded using 501 multiple bytes. 503 If the type or length number is less than 253, then that number is 504 encoded into the actual type or length field. If the number is 505 greater or equals 253 and fits into 2 bytes, then the type or length 506 field is set to 253 and the number is encoded in the next following 2 507 bytes in network byte order, i.e., from the most significant byte 508 (MSB) to the least significant byte (LSB). If the number is greater 509 than 2 bytes and fits into 4 bytes, then the type or length field is 510 set to 254 and the number is encoded in the subsequent 4 bytes in 511 network byte order. For larger numbers, the type or length field is 512 set to 255 and the number is encoded in the subsequent 8 bytes in 513 network byte order. 515 In this specification, compressed NDN TLVs encode type and length 516 fields using self-delimiting numeric values (SDNVs) [RFC6256] 517 commonly known from DTN protocols. Instead of using the first byte 518 as a marker for the number of following bytes, SDNVs use a single bit 519 to indicate subsequent bytes. 521 +==========+==========================+==========================+ 522 | Value | NDN TLV encoding | SDNV encoding | 523 +==========+==========================+==========================+ 524 | 0 | 0x00 | 0x00 | 525 +----------+--------------------------+--------------------------+ 526 | 127 | 0x7F | 0x7F | 527 +----------+--------------------------+--------------------------+ 528 | 128 | 0x80 | 0x81 0x00 | 529 +----------+--------------------------+--------------------------+ 530 | 253 | 0xFD 0x00 0xFD | 0x81 0x7D | 531 +----------+--------------------------+--------------------------+ 532 | 2^14 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F | 533 +----------+--------------------------+--------------------------+ 534 | 2^14 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 | 535 +----------+--------------------------+--------------------------+ 536 | 2^16 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 | 537 +----------+--------------------------+--------------------------+ 538 | 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F | 539 +----------+--------------------------+--------------------------+ 540 | 2^21 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 | 541 +----------+--------------------------+--------------------------+ 542 | 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F | 543 +----------+--------------------------+--------------------------+ 544 | 2^28 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 | 545 +----------+--------------------------+--------------------------+ 546 | 2^32 | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 | 547 | | 0x00 0x00 0x00 0x00 | | 548 +----------+--------------------------+--------------------------+ 549 | 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F | 550 | | 0xFF 0xFF 0xFF 0xFF | | 551 +----------+--------------------------+--------------------------+ 552 | 2^35 | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 | 553 | | 0x00 0x00 0x00 0x00 | 0x00 | 554 +----------+--------------------------+--------------------------+ 556 Table 1: NDN TLV encoding compared to SDNVs. 558 Table 1 compares the required bytes for encoding a few selected 559 values using the NDN TLV encoding and SDNVs. For values up to 127, 560 both methods require a single byte. Values in the range [128;252] 561 encode as one byte for the NDN TLV scheme, while SDNVs require two 562 bytes. Starting at value 253, SDNVs require a less or equal amount 563 of bytes compared to the NDN TLV encoding. 565 5.2. Name TLV Compression 567 This Name TLV compression encodes length fields of two consecutive 568 NameComponent TLVs into one byte, using a nibble for each. The most 569 significant nibble indicates the length of an immediately following 570 NameComponent TLV. The least significant nibble denotes the length 571 of a subsequent NameComponent TLV. A length of 0 marks the end of 572 the compressed Name TLV. The last length field of an encoded 573 NameComponent is either 0x00 for a name with an even number of 574 components, and 0xYF (Y > 0) if an odd number of components are 575 present. This process limits the length of a NameComponent TLV to 15 576 bytes, but allows for an unlimited number of components. An example 577 for this encoding is presented in Figure 10. 579 Name: /HAW/Room/481/Humid/99 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |0 0 1 1|0 1 0 0| H | A | W | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | R | o | o | m | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | H | u | m | i | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | d |0 0 1 0|0 0 0 0| 9 | 9 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 10: Name TLV compression for /HAW/Room/481/Humid/99 597 5.3. Interest Messages 599 5.3.1. Uncompressed Interest Messages 601 An uncompressed Interest message uses the base dispatch format (see 602 Figure 4) and sets the C flag to 0 and the P as well as the M flag to 603 0 (Figure 11). The Interest message is handed to the NDN network 604 stack without modifications. 606 0 1 2 3 4 5 6 7 607 +---+---+---+---+---+---+---+---+ 608 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 609 +---+---+---+---+---+---+---+---+ 611 Figure 11: Dispatch format for uncompressed NDN Interest messages 613 5.3.2. Compressed Interest Messages 615 The compressed Interest message uses the extended dispatch format 616 (Figure 5) and sets the C flag to 1, the P flag to 0 and the M flag 617 to 0. If an Interest message contains TLVs that are not mentioned in 618 the following compression rules, then this message MUST be sent 619 uncompressed. 621 This specification assumes that a HopLimit TLV is part of the 622 original Interest message. If such HopLimit TLV is not present, it 623 will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior 624 to the compression. 626 In the default use case, the Interest message is compressed with the 627 following minimal rule set: 629 1. The Type field of the outermost MessageType TLV is removed. 631 2. The Name TLV is compressed according to Section 5.2. For this, 632 all NameComponents are expected to be of type 633 GenericNameComponent with a length greater than 0. An 634 ImplicitSha256DigestComponent or ParametersSha256DigestComponent 635 MAY appear at the end of the name. In any other case, the 636 message MUST be sent uncompressed. 638 3. The Nonce TLV and InterestLifetime TLV are moved to the end of 639 the compressed Interest as illustrated in Figure 12. The 640 InterestLifetime is encoded as described in Section 7. On 641 decompression, this encoding may yield an Interestlifetime that 642 is smaller than the original value. 644 4. The Type and Length fields of Nonce TLV, HopLimit TLV and 645 InterestLifetime TLV are elided. The Nonce value has a length of 646 4 bytes and the HopLimit value has a length of 1 byte. The 647 compressed InterestLifetime (Section 7) has a length of 1 byte. 648 The presence of a Nonce and InterestLifetime TLV is deduced from 649 the remaining length to parse. A remaining length of 1 indicates 650 the presence of an InerestLifetime, a length of 4 indicates the 651 presence of a nonce, and a length of 5 indicates the presence of 652 both TLVs. 654 The compressed NDN LoWPAN Interest message is visualized in 655 Figure 12. 657 T = Type, L = Length, V = Value 658 Lc = Compressed Length, Vc = Compressed Value 659 : = optional field, | = mandatory field 661 +---------+---------+ +---------+ 662 | Msg T | Msg L | | Msg Lc | 663 +---------+---------+---------+ +---------+ 664 | Name T | Name L | Name V | | Name Vc | 665 +---------+---------+---------+ +---------+---------+ 666 : CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc : 667 +---------+---------+ +---------+---------+ 668 : MBFr T : MBFr L : | HPL V | 669 +---------+---------+---------+ ==> +---------+---------+ 670 : FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc : 671 +---------+---------+---------+ +---------+---------+ 672 : NONCE T : NONCE L : NONCE V : : NONCE V : 673 +---------+---------+---------+ +---------+ 674 : ILT T : ILT L : ILT V : : ILT Vc : 675 +---------+---------+---------+ +---------+ 676 : HPL T : HPL L : HPL V : 677 +---------+---------+---------+ 678 : APM T : APM L : APM V : 679 +---------+---------+---------+ 681 Figure 12: Compression of NDN LoWPAN Interest Message 683 Further TLV compression is indicated by the ICN LoWPAN dispatch in 684 Figure 13. 686 0 1 687 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 688 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 689 | 0 | 0 | 0 | 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT| 690 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 692 Figure 13: Dispatch format for compressed NDN Interest messages 694 PFX: CanBePrefix TLV 0: The uncompressed message does not include a 695 CanBePrefix TLV. 697 1: The uncompressed message does include a 698 CanBePrefix TLV and is removed from the compressed 699 message. 701 FRE: MustBeFresh TLV 0: The uncompressed message does not include a 702 MustBeFresh TLV. 704 1: The uncompressed message does include a 706 MustBeFresh TLV and is removed from the compressed 707 message. 709 FWD: ForwardingHint TLV 0: The uncompressed message does not 710 include a ForwardingHint TLV. 712 1: The uncompressed message does include a 713 ForwardingHint TLV. The Type field is removed from 714 the compressed message. Further, all link delegation 715 types and link preference types are removed. All 716 included names are compressed according to 717 Section 5.2. If any name is not compressible, the 718 message MUST be sent uncompressed. 720 APM: ApplicationParameters TLV 0: The uncompressed message does not 721 include an ApplicationParameters TLV. 723 1: The uncompressed message does 724 include an ApplicationParameters TLV. The Type field 725 is removed from the compressed message. 727 DIG: ImplicitSha256DigestComponent TLV 0: The name does not include 728 an ImplicitSha256DigestComponent as the last TLV. 730 1: The name does include an 731 ImplicitSha256DigestComponent as the last TLV. The 732 Type and Length fields are omitted. 734 RSV: Reserved Must be set to 0. 736 CID: Context Identifier See Figure 5. 738 EXT: Extension 0: No extension byte follows. 740 1: Extension byte EXT_0 follows immediately. See 741 Section 5.3.3. 743 5.3.3. Dispatch Extension 745 The EXT_0 byte follows the description in Section 4.1.1 and is 746 illustrated in Figure 14. 748 0 1 2 3 4 5 6 7 749 +---+---+---+---+---+---+---+---+ 750 | NCS | RSV |EXT| 751 +---+---+---+---+---+---+---+---+ 753 Figure 14: EXT_0 format 755 NCS: Name Compression Strategy 00: Names are compressed with the 756 default name compression strategy (see Section 5.2). 758 01: Reserved. 760 10: Reserved. 762 11: Reserved. 764 RSV: Reserved Must be set to 0. 766 EXT: Extension 0: No extension byte follows. 768 1: A further extension byte follows immediately. 770 5.4. Data Messages 772 5.4.1. Uncompressed Data Messages 774 An uncompressed Data message uses the base dispatch format and sets 775 the C flag to 0, the P flag to 0 and the M flag to 1 (Figure 15). 776 The Data message is handed to the NDN network stack without 777 modifications. 779 0 1 2 3 4 5 6 7 780 +---+---+---+---+---+---+---+---+ 781 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 782 +---+---+---+---+---+---+---+---+ 784 Figure 15: Dispatch format for uncompressed NDN Data messages 786 5.4.2. Compressed Data Messages 788 The compressed Data message uses the extended dispatch format 789 (Figure 5) and sets the C as well as the M flags to 1. The P flag is 790 set to 0. If a Data message contains TLVs that are not mentioned in 791 the following compression rules, then this message MUST be sent 792 uncompressed. 794 By default, the Data message is compressed with the following base 795 rule set: 797 1. The Type field of the outermost MessageType TLV is removed. 799 2. The Name TLV is compressed according to Section 5.2. For this, 800 all NameComponents are expected to be of type 801 GenericNameComponent and to have a length greater than 0. In any 802 other case, the message MUST be sent uncompressed. 804 3. The MetaInfo TLV Type and Length fields are elided from the 805 compressed Data message. 807 4. The FreshnessPeriod TLV MUST be moved to the end of the 808 compressed Data message. Type and Length fields are elided and 809 the value is encoded as described in Section 7 as a 1-byte time- 810 code. If the freshness period is not a valid time-value, then 811 the message MUST be sent uncompressed in order to preserve the 812 security envelope of the Data message. The presence of a 813 FreshnessPeriod TLV is deduced from the remaining one byte length 814 to parse. 816 5. The Type fields of the SignatureInfo TLV, SignatureType TLV and 817 SignatureValue TLV are removed. 819 The compressed NDN LoWPAN Data message is visualized in Figure 16. 821 T = Type, L = Length, V = Value 822 Lc = Compressed Length, Vc = Compressed Value 823 : = optional field, | = mandatory field 825 +---------+---------+ +---------+ 826 | Msg T | Msg L | | Msg Lc | 827 +---------+---------+---------+ +---------+ 828 | Name T | Name L | Name V | | Name Vc | 829 +---------+---------+---------+ +---------+---------+ 830 : Meta T : Meta L : : CTyp Lc : CType V : 831 +---------+---------+---------+ +---------+---------+ 832 : CTyp T : CTyp L : CTyp V : : FBID V : 833 +---------+---------+---------+ ==> +---------+---------+ 834 : FrPr T : FrPr L : FrPr V : : CONT Lc : CONT V : 835 +---------+---------+---------+ +---------+---------+ 836 : FBID T : FBID L : FBID V : | Sig Lc | 837 +---------+---------+---------+ +---------+---------+ 838 : CONT T : CONT L : CONT V : | SInf Lc | SInf Vc | 839 +---------+---------+---------+ +---------+---------+ 840 | Sig T | Sig L | | SVal Lc | SVal Vc | 841 +---------+---------+---------+ +---------+---------+ 842 | SInf T | SInf L | SInf V | : FrPr Vc : 843 +---------+---------+---------+ +---------+ 844 | SVal T | SVal L | SVal V | 845 +---------+---------+---------+ 847 Figure 16: Compression of NDN LoWPAN Data Message 849 Further TLV compression is indicated by the ICN LoWPAN dispatch in 850 Figure 17. 852 0 1 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 854 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 855 | 0 | 0 | 1 | 1 |FBI|CON|KLO| RSV |CID|EXT| 856 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 858 Figure 17: Dispatch format for compressed NDN Data messages 860 FBI: FinalBlockId TLV 0: The uncompressed message does not include 861 a FinalBlockId TLV. 863 1: The uncompressed message does include a 864 FinalBlockId and it is encoded according to 865 Section 5.2. If the FinalBlockId TLV is not 866 compressible, then the message MUST be sent 867 uncompressed. 869 CON: ContentType TLV 0: The uncompressed message does not include a 870 ContentType TLV. 872 1: The uncompressed message does include a 873 ContentType TLV. The Type field is removed from the 874 compressed message. 876 KLO: KeyLocator TLV 0: If the included SignatureType requires a 877 KeyLocator TLV, then the KeyLocator represents a name 878 and is compressed according to Section 5.2. If the 879 name is not compressible, then the message MUST be 880 sent uncompressed. 882 1: If the included SignatureType requires a 883 KeyLocator TLV, then the KeyLocator represents a 884 KeyDigest. The Type field of this KeyDigest is 885 removed. 887 RSV: Reserved Must be set to 0. 889 CID: Context Identifier See Figure 5. 891 EXT: Extension 0: No extension byte follows. 893 1: Extension byte EXT_0 follows immediately. See 894 Section 5.4.3. 896 5.4.3. Dispatch Extension 898 The EXT_0 byte follows the description in Section 4.1.1 and is 899 illustrated in Figure 18. 901 0 1 2 3 4 5 6 7 902 +---+---+---+---+---+---+---+---+ 903 | NCS | RSV |EXT| 904 +---+---+---+---+---+---+---+---+ 906 Figure 18: EXT_0 format 908 NCS: Name Compression Strategy 00: Names are compressed with the 909 default name compression strategy (see Section 5.2). 911 01: Reserved. 913 10: Reserved. 915 11: Reserved. 917 RSV: Reserved Must be set to 0. 919 EXT: Extension 0: No extension byte follows. 921 1: A further extension byte follows immediately. 923 6. Space-efficient Message Encoding for CCNx 925 6.1. TLV Encoding 927 The generic CCNx TLV encoding is described in [RFC8609]. Type and 928 Length fields attain the common fixed length of 2 bytes. 930 The TLV encoding for CCNx LoWPAN is changed to the more space 931 efficient encoding described in Section 5.1. Hence NDN and CCNx use 932 the same compressed format for writing TLVs. 934 6.2. Name TLV Compression 936 Name TLVs are compressed using the scheme already defined in 937 Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or 938 organizational TLVs, then the name remains uncompressed. 940 6.3. Interest Messages 942 6.3.1. Uncompressed Interest Messages 944 An uncompressed Interest message uses the base dispatch format (see 945 Figure 4) and sets the C as well as the M flag to 0. The P flag is 946 set to 1 (Figure 19). The Interest message is handed to the CCNx 947 network stack without modifications. 949 0 1 2 3 4 5 6 7 950 +---+---+---+---+---+---+---+---+ 951 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 952 +---+---+---+---+---+---+---+---+ 954 Figure 19: Dispatch format for uncompressed CCNx Interest messages 956 6.3.2. Compressed Interest Messages 958 The compressed Interest message uses the extended dispatch format 959 (Figure 5) and sets the C and P flags to 1. The M flag is set to 0. 960 If an Interest message contains TLVs that are not mentioned in the 961 following compression rules, then this message MUST be sent 962 uncompressed. 964 In the default use case, the Interest message is compressed with the 965 following minimal rule set: 967 1. The version is elided from the Fixed Header and assumed to be 1. 969 2. The Type and Length fields of the CCNx Message TLV are elided and 970 are obtained from the Fixed Header on decompression. 972 The compressed CCNx LoWPAN Interest message is visualized in 973 Figure 20. 975 T = Type, L = Length, V = Value 976 Lc = Compressed Length, Vc = Compressed Value 977 : = optional field, | = mandatory field 979 +-----------------------------+ +-------------------------+ 980 | Uncompr. Fixed Header | | Compr. Fixed Header | 981 +-----------------------------+ +-------------------------+ 982 +---------+---------+---------+ +---------+ 983 : ILT T : ILT L : ILT V : : ILT Vc : 984 +---------+---------+---------+ +---------+ 985 : MSGH T : MSGH L : MSGH V : : MSGH Vc : 986 +---------+---------+---------+ +---------+ 987 +---------+---------+ +---------+ 988 | MSGT T | MSGT L | | Name Vc | 989 +---------+---------+---------+ +---------+ 990 | Name T | Name L | Name V | ==> : KIDR Vc : 991 +---------+---------+---------+ +---------+ 992 : KIDR T : KIDR L : KIDR V : : OBHR Vc : 993 +---------+---------+---------+ +---------+---------+ 994 : OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V : 995 +---------+---------+---------+ +---------+---------+ 996 : PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc : 997 +---------+---------+---------+ +---------+---------+ 998 : VALG T : VALG L : VALG V : : VPAY Lc : VPAY V : 999 +---------+---------+---------+ +---------+---------+ 1000 : VPAY T : VPAY L : VPAY V : 1001 +---------+---------+---------+ 1003 Figure 20: Compression of CCNx LoWPAN Interest Message 1005 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1006 Figure 21. 1008 0 1 1009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1010 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1011 | 0 | 1 | 0 | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT| 1012 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1014 Figure 21: Dispatch format for compressed CCNx Interest messages 1016 FLG: Flags field in the fixed header 0: The Flags field equals 0 1017 and is removed from the Interest message. 1019 1: The Flags field appears in 1020 the fixed header. 1022 PTY: PacketType field in the fixed header 0: The PacketType field 1023 is elided and assumed to be PT_INTEREST. 1025 1: The PacketType field 1026 is elided and assumed to be PT_RETURN. 1028 HPL: HopLimit field in the fixed header 0: The HopLimit field 1029 appears in the fixed header. 1031 1: The HopLimit field is 1032 elided and assumed to be 1. 1034 FRS: Reserved field in the fixed header 0: The Reserved field 1035 appears in the fixed header. 1037 1: The Reserved field is 1038 elided and assumed to be 0. 1040 PAY: Optional Payload TLV 0: The Payload TLV is absent. 1042 1: The Payload TLV is present and the 1043 type field is elided. 1045 ILT: Optional Hop-By-Hop InterestLifetime TLV See Section 6.3.2.1 for further details on the ordering 1046 of hop-by-hop TLVs. 1048 0: No 1049 InterestLifetime TLV is present in the Interest message. 1051 1: An 1052 InterestLifetime TLV is present with a fixed length of 1 1053 byte and is encoded as described in Section 7. The type 1054 and length fields are elided. 1056 MGH: Optional Hop-By-Hop MessageHash TLV See Section 6.3.2.1 for further details on the ordering 1057 of hop-by-hop TLVs. 1059 This TLV is expected to contain a T_SHA-256 TLV. If 1060 another hash is contained, then the Interest MUST be sent 1061 uncompressed. 1063 0: The MessageHash TLV is 1064 absent. 1066 1: A T_SHA-256 TLV is 1067 present and the type as well as the length fields are 1068 removed. The length field is assumed to represent 32 1069 bytes. The outer Message Hash TLV is omitted. 1071 KIR: Optional KeyIdRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If 1072 another hash is contained, then the Interest MUST be sent 1073 uncompressed. 1075 0: The KeyIdRestriction TLV is 1076 absent. 1078 1: A T_SHA-256 TLV is present 1079 and the type as well as the length fields are removed. 1080 The length field is assumed to represent 32 bytes. The 1081 outer KeyIdRestriction TLV is omitted. 1083 CHR: Optional ContentObjectHashRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If 1084 another hash is contained, then the Interest MUST be sent 1085 uncompressed. 1087 0: The ContentObject 1088 HashRestriction TLV is absent. 1090 1: A T_SHA-256 TLV 1091 is present and the type as well as the length fields are 1092 removed. The length field is assumed to represent 32 1093 bytes. The outer ContentObjectHashRestriction TLV is 1094 omitted. 1096 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 0: No 1097 validation related TLVs are present in the Interest 1098 message. 1100 1: Val 1101 idation related TLVs are present in the Interest message. 1102 An additional byte follows immediately that handles 1103 validation related TLV compressions and is described in 1104 Section 6.3.2.2. 1106 CID: Context Identifier See Figure 5. 1108 EXT: Extension 0: No extension byte follows. 1110 1: Extension byte EXT_0 follows immediately. See 1111 Section 6.3.3. 1113 6.3.2.1. Hop-By-Hop Header TLVs Compression 1115 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 1116 optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several 1117 more can be defined in higher level specifications. For the 1118 compression specified in the previous section, the Hop-By-Hop TLVs 1119 are ordered as follows: 1121 1. Interest Lifetime TLV 1123 2. Message Hash TLV 1125 Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed 1126 in the encoded message and they appear in the same order as in the 1127 original message, but after the Interest Lifetime TLV and Message 1128 Hash TLV. 1130 6.3.2.2. Validation 1132 0 1 2 3 4 5 6 7 8 1133 +-------+-------+-------+-------+-------+-------+-------+-------+ 1134 | ValidationAlg | KeyID | RSV | 1135 +-------+-------+-------+-------+-------+-------+-------+-------+ 1137 Figure 22: Dispatch for Interset Validations 1139 ValidationALg: Optional ValidationAlgorithm TLV 0000: An 1140 uncompressed ValidationAlgorithm TLV is included. 1142 0001: A T_CRC32C Va 1143 lidationAlgorithm TLV is assumed, but no 1144 ValidationAlgorithm TLV is included. 1146 0010: A T_CRC32C Va 1147 lidationAlgorithm TLV is assumed, but no 1148 ValidationAlgorithm TLV is included. Additionally, a 1149 Sigtime TLV is inlined without a type and a length field. 1151 0011: A T_HMAC- 1152 SHA256 ValidationAlgorithm TLV is assumed, but no 1153 ValidationAlgorithm TLV is included. 1155 0100: A T_HMAC- 1156 SHA256 ValidationAlgorithm TLV is assumed, but no 1157 ValidationAlgorithm TLV is included. Additionally, a 1158 Sigtime TLV is inlined without a type and a length field. 1160 0101: Reserved. 1162 0110: Reserved. 1164 0111: Reserved. 1166 1000: Reserved. 1168 1001: Reserved. 1170 1010: Reserved. 1172 1011: Reserved. 1174 1100: Reserved. 1176 1101: Reserved. 1178 1110: Reserved. 1180 1111: Reserved. 1182 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 00: Th 1183 e KeyId TLV is absent. 1185 01: Th 1186 e KeyId TLV is present and uncompressed. 1188 10: A 1189 T_SHA-256 TLV is present and the type field as well as 1190 the length fields are removed. The length field is 1191 assumed to represent 32 bytes. The outer KeyId TLV is 1192 omitted. 1194 11: A 1195 T_SHA-512 TLV is present and the type field as well as 1196 the length fields are removed. The length field is 1197 assumed to represent 64 bytes. The outer KeyId TLV is 1198 omitted. 1200 RSV: Reserved Must be set to 0. 1202 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1203 is present. The type field is omitted. 1205 6.3.3. Dispatch Extension 1207 The EXT_0 byte follows the description in Section 4.1.1 and is 1208 illustrated in Figure 23. 1210 0 1 2 3 4 5 6 7 1211 +---+---+---+---+---+---+---+---+ 1212 | NCS | RSV |EXT| 1213 +---+---+---+---+---+---+---+---+ 1215 Figure 23: EXT_0 format 1217 NCS: Name Compression Strategy 00: Names are compressed with the 1218 default name compression strategy (see Section 5.2). 1220 01: Reserved. 1222 10: Reserved. 1224 11: Reserved. 1226 RSV: Reserved Must be set to 0. 1228 EXT: Extension 0: No extension byte follows. 1230 1: A further extension byte follows immediately. 1232 6.4. Content Objects 1234 6.4.1. Uncompressed Content Objects 1236 An uncompressed Content object uses the base dispatch format (see 1237 Figure 4) and sets the C flag to 0, the P and M flags to 1 1238 (Figure 24). The Content object is handed to the CCNx network stack 1239 without modifications. 1241 0 1 2 3 4 5 6 7 1242 +---+---+---+---+---+---+---+---+ 1243 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1244 +---+---+---+---+---+---+---+---+ 1246 Figure 24: Dispatch format for uncompressed CCNx Content objects 1248 6.4.2. Compressed Content Objects 1250 The compressed Content object uses the extended dispatch format 1251 (Figure 5) and sets the C, P, as well as the M flag to 1. If a 1252 Content object contains TLVs that are not mentioned in the following 1253 compression rules, then this message MUST be sent uncompressed. 1255 By default, the Content object is compressed with the following base 1256 rule set: 1258 1. The version is elided from the Fixed Header and assumed to be 1. 1260 2. The PacketType field is elided from the Fixed Header. 1262 3. The Type and Length fields of the CCNx Message TLV are elided and 1263 are obtained from the Fixed Header on decompression. 1265 The compressed CCNx LoWPAN Data message is visualized in Figure 25. 1267 T = Type, L = Length, V = Value 1268 Lc = Compressed Length, Vc = Compressed Value 1269 : = optional field, | = mandatory field 1271 +-----------------------------+ +-------------------------+ 1272 | Uncompr. Fixed Header | | Compr. Fixed Header | 1273 +-----------------------------+ +-------------------------+ 1274 +---------+---------+---------+ +---------+ 1275 : RCT T : RCT L : RCT V : : RCT Vc : 1276 +---------+---------+------.--+ +---------+ 1277 : MSGH T : MSGH L : MSGH V : : MSGH Vc : 1278 +---------+---------+---------+ +---------+ 1279 +---------+---------+ +---------+ 1280 | MSGT T | MSGT L | | Name Vc | 1281 +---------+---------+---------+ +---------+ 1282 | Name T | Name L | Name V | ==> : EXPT Vc : 1283 +---------+---------+---------+ +---------+---------+ 1284 : PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V : 1285 +---------+---------+---------+ +---------+---------+ 1286 : EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc : 1287 +---------+---------+---------+ +---------+---------+ 1288 : PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V : 1289 +---------+---------+---------+ +---------+---------+ 1290 : VALG T : VALG L : VALG V : 1291 +---------+---------+---------+ 1292 : VPAY T : VPAY L : VPAY V : 1293 +---------+---------+---------+ 1295 Figure 25: Compression of CCNx LoWPAN Data Message 1297 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1298 Figure 26. 1300 0 1 1301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1302 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1303 | 0 | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT| 1304 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1305 Figure 26: Dispatch format for compressed CCNx Content objects 1307 FLG: Flags field in the fixed header See Section 6.3.2. 1309 FRS: Reserved field in the fixed header See Section 6.3.2. 1311 PAY: Optional Payload TLV See Section 6.3.2. 1313 RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 0: The 1314 Recommended Cache Time TLV is absent. 1316 1: The 1317 Recommended Cache Time TLV is present and the type as 1318 well as the length fields are elided. 1320 MGH: Optional Hop-By-Hop MessageHash TLV See Section 6.4.2.1 for further details on the ordering 1321 of hop-by-hop TLVs. 1323 This TLV is expected to contain a T_SHA-256 TLV. If 1324 another hash is contained, then the Content Object MUST 1325 be sent uncompressed. 1327 0: The MessageHash TLV is 1328 absent. 1330 1: A T_SHA-256 TLV is 1331 present and the type as well as the length fields are 1332 removed. The length field is assumed to represent 32 1333 bytes. The outer Message Hash TLV is omitted. 1335 PLTYP: Optional PayloadType TLV 00: The PayloadType TLV is 1336 absent. 1338 01: The PayloadType TLV is 1339 absent and T_PAYLOADTYPE_DATA is assumed. 1341 10: The PayloadType TLV is 1342 absent and T_PAYLOADTYPE_KEY is assumed. 1344 11: The PayloadType TLV is 1345 present and uncompressed. 1347 EXP: Optional ExpiryTime TLV 0: The ExpiryTime TLV is absent. 1349 1: The ExpiryTime TLV is present and 1350 the type as well as the length fields are elided. 1352 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1353 tion 6.3.2. 1355 RSV: Reserved Must be set to 0. 1357 CID: Context Identifier See Figure 5. 1359 EXT: Extension 0: No extension byte follows. 1361 1: Extension byte EXT_0 follows immediately. See 1362 Section 6.4.3. 1364 6.4.2.1. Hop-By-Hop Header TLVs Compression 1366 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1367 two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but 1368 several more can be defined in higher level specifications. For the 1369 compression specified in the previous section, the Hop-By-Hop TLVs 1370 are ordered as follows: 1372 1. Recommended Cache Time TLV 1374 2. Message Hash TLV 1376 Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed 1377 in the encoded message and they appear in the same order as in the 1378 original message, but after the Recommended Cache Time TLV and 1379 Message Hash TLV. 1381 6.4.3. Dispatch Extension 1383 The EXT_0 byte follows the description in Section 4.1.1 and is 1384 illustrated in Figure 27. 1386 0 1 2 3 4 5 6 7 1387 +---+---+---+---+---+---+---+---+ 1388 | NCS | RSV |EXT| 1389 +---+---+---+---+---+---+---+---+ 1391 Figure 27: EXT_0 format 1393 NCS: Name Compression Strategy 00: Names are compressed with the 1394 default name compression strategy (see Section 5.2). 1396 01: Reserved. 1398 10: Reserved. 1400 11: Reserved. 1402 RSV: Reserved Must be set to 0. 1404 EXT: Extension 0: No extension byte follows. 1406 1: A further extension byte follows immediately. 1408 7. Compressed Time Encoding 1410 This document adopts the 8-bit compact time representation for 1411 relative time values described in Section 5 of [RFC5497] with the 1412 constant factor C set to C := 1/32. 1414 Valid time offsets in CCNx and NDN reach from a few milliseconds 1415 (e.g., lifetime of low-latency Interests) to several years (e.g., 1416 content freshness periods in caches). Therefore, this document adds 1417 two modifications to the compression algorithm. 1419 The first modification is the inclusion of a subnormal form 1420 [IEEE.754.2019] for time-codes with exponent 0 to provide an 1421 increased precision and a gradual underflow for the smallest numbers. 1422 The formula is changed as follows (a := mantissa; b := exponent): 1424 Subnormal (b == 0): (0 + a/8) * 2 * C 1426 Normalized (b > 0): (1 + a/8) * 2^b * C (see [RFC5497]) 1428 This configuration allows for the following ranges: 1430 * Minimum subnormal number: 0 seconds 1432 * 2nd minimum subnormal number: ~0.007812 seconds 1434 * Maximum subnormal number: ~0.054688 seconds 1436 * Minimum normalized number: ~0.062500 seconds 1438 * 2nd minimum normalized number: ~0.070312 seconds 1440 * Maximum normalized number: ~3.99 years 1442 The second modification only applies to uncompressible time offsets 1443 that are outside any security envelope. An invalid time-value MUST 1444 be set to the largest valid time-value that is smaller than the 1445 invalid input value before compression. 1447 8. Stateful Header Compression 1449 Stateful header compression in ICN LoWPAN enables packet size 1450 reductions in two ways. First, common information that is shared 1451 throughout the local LoWPAN may be memorized in context state at all 1452 nodes and omitted from communication. Second, redundancy in a single 1453 Interest-data exchange may be removed from ICN stateful forwarding on 1454 a hop-by-hop bases and memorized in en-route state tables. 1456 8.1. LoWPAN-local State 1458 A context identifier (CID) is a byte that refers to a particular 1459 conceptual context between network devices and MAY be used to replace 1460 frequently appearing information, such as name prefixes, suffixes, or 1461 meta information, such as Interest lifetime. 1463 0 1 2 3 4 5 6 7 1464 +---+---+---+---+---+---+---+---+ 1465 | X | ContextID | 1466 +---+---+---+---+---+---+---+---+ 1468 Figure 28: Context Identifier. 1470 The 7-bit ContextID is a locally-scoped unique identifier that 1471 represents contextual state shared between sender and receiver of the 1472 corresponding frame (see Figure 28). If set the most significant bit 1473 indicates the presence of another, subsequent ContextID byte (see 1474 Figure 33). 1476 Context state shared between senders and receivers is removed from 1477 the compressed packet prior to sending, and reinserted after 1478 reception prior to passing to the upper stack. 1480 The actual information in a context and how it is encoded are out of 1481 scope of this document. The initial distribution and maintenance of 1482 shared context is out of scope of this document. Frames containing 1483 unknown or invalid CIDs MUST be silently discarded. 1485 8.2. En-route State 1487 In CCNx and NDN, Name TLVs are included in Interest messages, and 1488 they return in data messages. Returning Name TLVs either equal the 1489 original Name TLV, or they contain the original Name TLV as a prefix. 1490 ICN LoWPAN reduces this redundancy in responses by replacing Name 1491 TLVs with single bytes that represent link-local HopIDs. HopIDs are 1492 carried as Context Identifiers (see Section 8.1) of link-local scope 1493 as shown in Figure 29. 1495 0 1 2 3 4 5 6 7 1496 +---+---+---+---+---+---+---+---+ 1497 | X | HopID | 1498 +---+---+---+---+---+---+---+---+ 1500 Figure 29: Context Identifier as HopID. 1502 A HopID is valid if not all ID bits are set to zero and invalid 1503 otherwise. This yields 127 distinct HopIDs. If this range (1...127) 1504 is exhausted, the messages MUST be sent without en-route state 1505 compression until new HopIDs are available. An ICN LoWPAN node that 1506 forwards without replacing the name by a HopID (without en-route 1507 compression) MUST invalidate the HopID by setting all ID-bits to 1508 zero. 1510 While an Interest is traversing, a forwarder generates an ephemeral 1511 HopID that is tied to a PIT entry. Each HopID MUST be unique within 1512 the local PIT and only exists during the lifetime of a PIT entry. To 1513 maintain HopIDs, the local PIT is extended by two new columns: HIDi 1514 (inbound HopIDs) and HIDo (outbound HopIDs). 1516 HopIDs are included in Interests and stored on the next hop with the 1517 resulting PIT entry in the HIDi column. The HopID is replaced with a 1518 newly generated local HopID before the Interest is forwarded. This 1519 new HopID is stored in the HIDo column of the local PIT (see 1520 Figure 30). 1522 PIT of B PIT Extension PIT of C PIT Extension 1523 +--------+------++------+------+ +--------+------++------+------+ 1524 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1525 +========+======++======+======+ +========+======++======+======+ 1526 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1527 +--------+------++------+------+ +--------+------++------+------+ 1528 ^ | ^ 1529 store | '----------------------, ,---' store 1530 | send v | 1531 ,---, /p0, h_A ,---, /p0, h_B ,---, 1532 | A | ------------------------> | B | ------------------------> | C | 1533 '---' '---' '---' 1535 Figure 30: Setting compression state en-route (Interest). 1537 Responses include HopIDs that were obtained from Interests. If the 1538 returning Name TLV equals the original Name TLV, then the name is 1539 entirely elided. Otherwise, only the matching name prefix is elided 1540 and the distinct name suffix is included along with the HopID. When 1541 a response is forwarded, the contained HopID is extracted and used to 1542 match against the correct PIT entry by performing a lookup on the 1543 HIDo column. The HopID is then replaced with the corresponding HopID 1544 from the HIDi column prior to forwarding the response (Figure 31). 1546 PIT of B PIT Extension PIT of C PIT Extension 1547 +--------+------++------+------+ +--------+------++------+------+ 1548 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1549 +========+======++======+======+ +========+======++======+======+ 1550 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1551 +--------+------++------+------+ +--------+------++------+------+ 1552 | ^ | 1553 send | '----------------------, ,---' send 1554 v match | v 1555 ,---, h_A ,---, h_B ,---, 1556 | A | <------------------------ | B | <------------------------ | C | 1557 '---' '---' '---' 1559 Figure 31: Eliding Name TLVs using en-route state (data). 1561 It should be noted that each forwarder of an Interest in an ICN 1562 LoWPAN network can individually decide whether to participate in en- 1563 route compression or not. However, an ICN LoWPAN node SHOULD use en- 1564 route compression whenever the stateful compression mechanism is 1565 activated. 1567 Note also that the extensions of the PIT data structure are required 1568 only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside 1569 of an ICN LoWPAN domain do not need to implement these extensions. 1571 8.3. Integrating Stateful Header Compression 1573 A CID appears whenever the CID flag is set (see Figure 5). The CID 1574 is appended to the last ICN LoWPAN dispatch byte as shown in 1575 Figure 32. 1577 ...-------+--------+-------...-------+--...-+-------... 1578 / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / 1579 ...-------+--------+-------...-------+--...-+-------... 1581 Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs 1583 Multiple CIDs are chained together, with the most significant bit 1584 indicating the presence of a subsequent CID (Figure 33). This allows 1585 to use multiple shared contexts in compressed messages. 1587 The HopID is always included as the very first CID. 1589 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1590 |1| CID / HopID | --> |1| CID | --> |0| CID | 1591 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1593 Figure 33: Chaining of context identifiers. 1595 9. ICN LoWPAN Constants and Variables 1597 This is a summary of all ICN LoWPAN constants and variables. 1599 DEFAULT_NDN_HOPLIMIT: 255 1601 10. Implementation Report and Guidance 1603 The ICN LoWPAN scheme defined in this document has been implemented 1604 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT 1605 version on RIOT [RIOT]. An experimental evaluation for NDN over ICN 1606 LOWPAN with varying configurations has been performed in [ICNLOWPAN]. 1607 Energy profilings and processing time measurements indicate 1608 significant energy savings, while amortized costs for processing show 1609 no penalties. 1611 10.1. Preferred Configuration 1613 The header compression performance depends on certain aspects and 1614 configurations. It works best for the following cases: 1616 * Signed time offsets compress as per Section 7 without the need for 1617 rounding. 1619 * Contextual state (e.g., prefixes) is distributed, such that long 1620 names can be elided from Interest and data messages. 1622 * Frequently used TLV type numbers for CCNx and NDN stay in the 1623 lower range (< 255). 1625 Name components are of GenericNameComponent type and are limited to a 1626 length of 15 bytes to enable compression for all messages. 1628 10.2. Further Experimental Deployments 1630 An investigation of ICN LoWPAN in large-scale deployments with 1631 varying traffic patterns using larger samples of the different board 1632 types available remains as future work. This document will be 1633 revised to progress it to the Standards Track, once sufficient 1634 operational experience has been acquired. Experience reports are 1635 encouraged, particularly in the following areas: 1637 * The name compression scheme (Section 5.2) is optimized for short 1638 name components of GenericNameComponent type. An empirical study 1639 on name lengths in different deployments of selected use cases, 1640 such as smart home, smart city, and industrial IoT can provide 1641 meaningful reports on necessary name component types and lengths. 1642 A conclusive outcome helps to understand whether and how extension 1643 mechanisms are needed (Section 5.3.3). As a preliminary analysis, 1644 [ICNLOWPAN] investigates the effectiveness of the proposed 1645 compression scheme with URLs obtained from the WWW. Studies on 1646 CoAP [RFC7252] deployments can offer additional insights on naming 1647 schemes in the IoT. 1649 * The fragmentation scheme (Section 4.2) inherited from 6LoWPAN 1650 allows for a transparent, hop-wise reassembly of CCNx or NDN 1651 packets. Fragment forwarding [RFC8930] with selective fragment 1652 recovery [RFC8931] can improve the end-to-end latency and 1653 reliability, while it reduces buffer requirements on forwarders. 1654 Initial evaluations ([SFR-ICNLOWPAN]) show that a naive 1655 integration of these upcoming fragmentation features into ICN 1656 LoWPAN renders the hop-wise content replication inoperative, since 1657 Interest and data messages are reassembled end-to-end. More 1658 deployment experiences are necessary to gauge the feasibility of 1659 different fragmentation schemes in ICN LoWPAN. 1661 * Context state (Section 8.1) holds information that is shared 1662 between a set of devices in a LoWPAN. Fixed name prefixes and 1663 suffixes are good candidates to be distributed to all nodes in 1664 order to elide them from request and response messages. More 1665 experience and a deeper inspection of currently available and 1666 upcoming protocol features is necessary to identify other protocol 1667 fields. 1669 * The distribution and synchronization of contextual state can 1670 potentially be adopted from Section 7.2 of [RFC6775], but requires 1671 further evaluations. While 6LoWPAN uses the Neighbor Discovery 1672 protocol to disseminate state, CCNx and NDN deployments are 1673 missing out on a standard mechanism to bootstrap and manage 1674 configurations. 1676 * The stateful en-route compression (Section 8.2) supports a limited 1677 number of 127 distinct HopIDs that can be simultaneously in use on 1678 a single node. Complex deployment scenarios that make use of 1679 multiple, concurrent requests can provide a better insight on the 1680 number of open requests stored in the Pending Interest Table of 1681 memory-constrained devices. This number can serve as an upper- 1682 bound and determines whether the HopID length needs to be resized 1683 to fit more HopIDs to the cost of additional header overhead. 1685 * Multiple implementations that generate and deploy the compression 1686 options of this memo in different ways will also add to the 1687 experience and understanding of the benefits and limitations of 1688 the proposed schemes. Different reports can help to illuminate on 1689 the complexity of implementing ICN LoWPAN for constrained devices, 1690 as well as on maintaining interoperability with other 1691 implementations. 1693 11. Security Considerations 1695 Main memory is typically a scarce resource of constrained networked 1696 devices. Fragmentation as described in this memo preserves fragments 1697 and purges them only after a packet is reassembled, which requires a 1698 buffering of all fragments. This scheme is able to handle fragments 1699 for distinctive packets simultaneously, which can lead to overflowing 1700 packet buffers that cannot hold all necessary fragments for packet 1701 reassembly. Implementers are thus urged to make use of appropriate 1702 buffer replacement strategies for fragments. Minimal fragment 1703 forwarding [RFC8930] can potentially prevent fragment buffer 1704 saturation in forwarders. 1706 The stateful header compression generates ephemeral HopIDs for 1707 incoming and outgoing Interests and consumes them on returning Data 1708 packets. Forged Interests can deplete the number of available 1709 HopIDs, thus leading to a denial of compression service for 1710 subsequent content requests. 1712 To further alleviate the problems caused by forged fragments or 1713 Interest initiations, proper protective mechanisms for accessing the 1714 link-layer should be deployed. IEEE 802.15.4, e.g., provides 1715 capabilities to protect frames and restrict them to a point-to-point 1716 link, or a group of devices. 1718 12. IANA Considerations 1719 12.1. Reserving Space in the 6LoWPAN Dispatch Type Field Registry 1721 IANA has assigned dispatch values of the 6LoWPAN Dispatch Type Field 1722 registry [RFC4944][RFC8025] with Page TBD1 for ICN LoWPAN. Table 2 1723 represents updates to the registry. 1725 +=============+======+===========================================+ 1726 | Bit Pattern | Page | Header Type | 1727 +=============+======+===========================================+ 1728 | 00 000000 | TBD1 | Uncompressed NDN Interest messages | 1729 +-------------+------+-------------------------------------------+ 1730 | 00 01xxxx | TBD1 | Compressed NDN Interest messages | 1731 +-------------+------+-------------------------------------------+ 1732 | 00 100000 | TBD1 | Uncompressed NDN Data messages | 1733 +-------------+------+-------------------------------------------+ 1734 | 00 11xxxx | TBD1 | Compressed NDN Data messages | 1735 +-------------+------+-------------------------------------------+ 1736 | 01 000000 | TBD1 | Uncompressed CCNx Interest messages | 1737 +-------------+------+-------------------------------------------+ 1738 | 01 01xxxx | TBD1 | Compressed CCNx Interest messages | 1739 +-------------+------+-------------------------------------------+ 1740 | 01 100000 | TBD1 | Uncompressed CCNx Content Object messages | 1741 +-------------+------+-------------------------------------------+ 1742 | 01 11xxxx | TBD1 | Compressed CCNx Content Object messages | 1743 +-------------+------+-------------------------------------------+ 1745 Table 2: Dispatch types for NDN and CCNx with page TBD1. 1747 13. References 1749 13.1. Normative References 1751 [IEEE.754.2019] 1752 Institute of Electrical and Electronics Engineers, C/MSC - 1753 Microprocessor Standards Committee, "Standard for 1754 Floating-Point Arithmetic", June 2019, 1755 . 1758 [ieee802.15.4] 1759 "IEEE Std. 802.15.4-2015", April 2016, 1760 . 1763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1764 Requirement Levels", BCP 14, RFC 2119, 1765 DOI 10.17487/RFC2119, March 1997, 1766 . 1768 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1769 "Transmission of IPv6 Packets over IEEE 802.15.4 1770 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1771 . 1773 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1774 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1775 DOI 10.17487/RFC5497, March 2009, 1776 . 1778 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 1779 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 1780 2011, . 1782 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1783 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1784 DOI 10.17487/RFC6282, September 2011, 1785 . 1787 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1788 Bormann, "Neighbor Discovery Optimization for IPv6 over 1789 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1790 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1791 . 1793 13.2. Informative References 1795 [CCN-LITE] "CCN-lite: A lightweight CCNx and NDN implementation", 1796 . 1798 [I-D.irtf-icnrg-flic] 1799 Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like 1800 ICN Collections (FLIC)", Work in Progress, Internet-Draft, 1801 draft-irtf-icnrg-flic-02, 4 November 2019, 1802 . 1805 [ICNLOWPAN] 1806 Gundogan, C., Kietzmann, P., Schmidt, TC., and M. 1807 Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low 1808 Power IoT Networks", Proc. of 18th IFIP Networking 1809 Conference, May 2019, 1810 . 1812 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1813 "Networking Named Content", 5th Int. Conf. on emerging 1814 Networking Experiments and Technologies (ACM CoNEXT), 1815 2009, . 1817 [NDN-EXP1] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1818 Waehlisch, "Information Centric Networking in the IoT: 1819 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1820 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1821 77-86, September 2014, 1822 . 1824 [NDN-EXP2] Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 1825 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 1826 Comparative Measurement Study in the IoT", Proc. of 5th 1827 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 1828 DL, pp. 159-171, September 2018, 1829 . 1831 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1832 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1833 in NDN: Towards Quantifying the Resource Gain", Proc. of 1834 4th ACM Conf. on Information-Centric Networking (ICN- 1835 2017) ACM DL, pp. 36-42, September 2017, 1836 . 1838 [NDN-PACKET-SPEC] 1839 "NDN Packet Format Specification", 1840 . 1842 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1843 Constrained-Node Networks", RFC 7228, 1844 DOI 10.17487/RFC7228, May 2014, 1845 . 1847 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1848 Application Protocol (CoAP)", RFC 7252, 1849 DOI 10.17487/RFC7252, June 2014, 1850 . 1852 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1853 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1854 "Information-Centric Networking: Baseline Scenarios", 1855 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1856 . 1858 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1859 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1860 "Information-Centric Networking (ICN) Research 1861 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1862 . 1864 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1865 and G. Boggia, "Information-Centric Networking: Evaluation 1866 and Security Considerations", RFC 7945, 1867 DOI 10.17487/RFC7945, September 2016, 1868 . 1870 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1871 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1872 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1873 . 1875 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1876 Networking (CCNx) Semantics", RFC 8569, 1877 DOI 10.17487/RFC8569, July 2019, 1878 . 1880 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1881 Networking (CCNx) Messages in TLV Format", RFC 8609, 1882 DOI 10.17487/RFC8609, July 2019, 1883 . 1885 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 1886 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 1887 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 1888 . 1890 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 1891 Area Network (6LoWPAN) Selective Fragment Recovery", 1892 RFC 8931, DOI 10.17487/RFC8931, November 2020, 1893 . 1895 [RIOT] Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., 1896 Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., 1897 and M. Waehlisch, "RIOT: an Open Source Operating System 1898 for Low-end Embedded Devices in the IoT", IEEE Internet of 1899 Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018, 1900 . 1902 [SFR-ICNLOWPAN] 1903 Lenders, M., Gundogan, C., Schmidt, TC., and M. Waehlisch, 1904 "Connecting the Dots: Selective Fragment Recovery in 1905 ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric 1906 Networking (ICN-2020) ACM DL, pp. 70-76, September 2020, 1907 . 1909 [TLV-ENC-802.15.4] 1910 "CCN and NDN TLV encodings in 802.15.4 packets", 1911 . 1914 [WIRE-FORMAT-CONSID] 1915 "CCN/NDN Protocol Wire Format and Functionality 1916 Considerations", . 1920 Appendix A. Estimated Size Reduction 1922 In the following a theoretical evaluation is given to estimate the 1923 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1925 We assume that n is the number of name components, comps_n denotes 1926 the sum of n name component lengths. We also assume that the length 1927 of each name component is lower than 16 bytes. The length of the 1928 content is given by clen. The lengths of TLV components is specific 1929 to the CCNx or NDN encoding and outlined below. 1931 A.1. NDN 1933 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1934 the 1 byte form of each TLV component is assumed. A typical TLV 1935 component therefore is of size 2 (type field + length field) + the 1936 actual value. 1938 A.1.1. Interest 1940 Figure 34 depicts the size requirements for a basic, uncompressed NDN 1941 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1942 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1943 Numbers below represent the amount of bytes. 1945 ------------------------------------, 1946 Interest TLV = 2 | 1947 ---------------------, | 1948 Name | 2 + | 1949 NameComponents = 2n + | 1950 | comps_n | 1951 ---------------------' = 21 + 2n + comps_n 1952 CanBePrefix = 2 | 1953 MustBeFresh = 2 | 1954 Nonce = 6 | 1955 InterestLifetime = 4 | 1956 HopLimit = 3 | 1957 ------------------------------------' 1959 Figure 34: Estimated size of an uncompressed NDN Interest 1961 Figure 35 depicts the size requirements after compression. 1963 ------------------------------------, 1964 Dispatch Page Switch = 1 | 1965 NDN Interset Dispatch = 2 | 1966 Interest TLV = 1 | 1967 -----------------------, | 1968 Name | | 1969 NameComponents = n/2 + = 10 + n/2 + comps_n 1970 | comps_n | 1971 -----------------------' | 1972 Nonce = 4 | 1973 HopLimit = 1 | 1974 InterestLifetime = 1 | 1975 ------------------------------------' 1977 Figure 35: Estimated size of a compressed NDN Interest 1979 The size difference is: 11 + 1.5n bytes. 1981 For the name /DE/HH/HAW/BT7, the total size gain is 17 bytes, which 1982 is 43% of the uncompressed packet. 1984 A.1.2. Data 1986 Figure 36 depicts the size requirements for a basic, uncompressed NDN 1987 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1988 1 minute is assumed and the value is encoded using 1 byte. An 1989 HMACWithSha256 is assumed as signature. The key locator is assumed 1990 to contain a Name TLV of length klen. 1992 ------------------------------------, 1993 Data TLV = 2 | 1994 ---------------------, | 1995 Name | 2 + | 1996 NameComponents = 2n + | 1997 | comps_n | 1998 ---------------------' | 1999 ---------------------, | 2000 MetaInfo | | 2001 FreshnessPeriod = 6 | 2002 | = 53 + 2n + comps_n + 2003 ---------------------' | clen + klen 2004 Content = 2 + clen | 2005 ---------------------, | 2006 SignatureInfo | | 2007 SignatureType | | 2008 KeyLocator = 41 + klen | 2009 SignatureValue | | 2010 DigestSha256 | | 2011 ---------------------' | 2012 ------------------------------------' 2014 Figure 36: Estimated size of an uncompressed NDN Data 2016 Figure 37 depicts the size requirements for the compressed version of 2017 the above Data packet. 2019 ------------------------------------, 2020 Dispatch Page Switch = 1 | 2021 NDN Data Dispatch = 2 | 2022 -----------------------, | 2023 Name | | 2024 NameComponents = n/2 + | 2025 | comps_n = 38 + n/2 + comps_n + 2026 -----------------------' | clen + klen 2027 Content = 1 + clen | 2028 KeyLocator = 1 + klen | 2029 DigestSha256 = 32 | 2030 FreshnessPeriod = 1 | 2031 ------------------------------------' 2033 Figure 37: Estimated size of a compressed NDN Data 2035 The size difference is: 15 + 1.5n bytes. 2037 For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes. 2039 A.2. CCNx 2041 The CCNx TLV encoding defines a 2-byte encoding for type and length 2042 fields, summing up to 4 bytes in total without a value. 2044 A.2.1. Interest 2046 Figure 38 depicts the size requirements for a basic, uncompressed 2047 CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version 2048 is assumed to be 1 and the reserved field is assumed to be 0. A 2049 KeyIdRestriction TLV with T_SHA-256 is included to limit the 2050 responses to Content Objects containing the specific key. 2052 ------------------------------------, 2053 Fixed Header = 8 | 2054 Message = 4 | 2055 ---------------------, | 2056 Name | 4 + = 56 + 4n + comps_n 2057 NameSegments = 4n + | 2058 | comps_n | 2059 ---------------------' | 2060 KeyIdRestriction = 40 | 2061 ------------------------------------' 2063 Figure 38: Estimated size of an uncompressed CCNx Interest 2065 Figure 39 depicts the size requirements after compression. 2067 ------------------------------------, 2068 Dispatch Page Switch = 1 | 2069 CCNx Interest Dispatch = 2 | 2070 Fixed Header = 3 | 2071 -----------------------, | 2072 Name | = 38 + n/2 + comps_n 2073 NameSegments = n/2 + | 2074 | comps_n | 2075 -----------------------' | 2076 T_SHA-256 = 32 | 2077 ------------------------------------' 2079 Figure 39: Estimated size of a compressed CCNx Interest 2081 The size difference is: 18 + 3.5n bytes. 2083 For the name /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which 2084 is 53% of the uncompressed packet. 2086 A.2.2. Content Object 2088 Figure 40 depicts the size requirements for a basic, uncompressed 2089 CCNx Content Object containing an ExpiryTime Message TLV, an 2090 HMAC_SHA-256 signature, the signature time and a hash of the shared 2091 secret key. In the fixed header, the protocol version is assumed to 2092 be 1 and the reserved field is assumed to be 0 2094 ------------------------------------, 2095 Fixed Header = 8 | 2096 Message = 4 | 2097 ---------------------, | 2098 Name | 4 + | 2099 NameSegments = 4n + | 2100 | comps_n | 2101 ---------------------' | 2102 ExpiryTime = 12 = 124 + 4n + comps_n + clen 2103 Payload = 4 + clen | 2104 ---------------------, | 2105 ValidationAlgorithm | | 2106 T_HMAC-256 = 56 | 2107 KeyId | | 2108 SignatureTime | | 2109 ---------------------' | 2110 ValidationPayload = 36 | 2111 ------------------------------------' 2113 Figure 40: Estimated size of an uncompressed CCNx Content Object 2115 Figure 41 depicts the size requirements for a basic, compressed CCNx 2116 Data. 2118 ------------------------------------, 2119 Dispatch Page Switch = 1 | 2120 CCNx Content Dispatch = 3 | 2121 Fixed Header = 2 | 2122 -----------------------, | 2123 Name | | 2124 NameSegments = n/2 + | 2125 | comps_n = 89 + n/2 + comps_n + clen 2126 -----------------------' | 2127 ExpiryTime = 8 | 2128 Payload = 1 + clen | 2129 T_HMAC-SHA256 = 32 | 2130 SignatureTime = 8 | 2131 ValidationPayload = 34 | 2132 ------------------------------------' 2133 Figure 41: Estimated size of a compressed CCNx Data Object 2135 The size difference is: 35 + 3.5n bytes. 2137 For the name /DE/HH/HAW/BT7, the size is reduced by 70 bytes, which 2138 is 40% of the uncompressed packet containing a 4-byte payload. 2140 Acknowledgments 2142 This work was stimulated by fruitful discussions in the ICNRG 2143 research group and the communities of RIOT and CCNlite. We would 2144 like to thank all active members for constructive thoughts and 2145 feedback. In particular, the authors would like to thank (in 2146 alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, 2147 Colin Perkins, Junxiao Shi. The hop-wise stateful name compression 2148 was brought up in a discussion by Dave Oran, which is gratefully 2149 acknowledged. Larger parts of this work are inspired by [RFC4944] 2150 and [RFC6282]. Special mentioning goes to Mark Mosko as well as G.Q. 2151 Wang and Ravi Ravindran as their previous work in [TLV-ENC-802.15.4] 2152 and [WIRE-FORMAT-CONSID] provided a good base for our discussions on 2153 stateless header compression mechanisms. Many thanks also to Carsten 2154 Bormann and Lars Eggert, who contributed in-depth comments during the 2155 IRSG review. This work was supported in part by the German Federal 2156 Ministry of Research and Education within the projects I3 and 2157 RAPstore. 2159 Authors' Addresses 2161 Cenk Gundogan 2162 HAW Hamburg 2163 Berliner Tor 7 2164 D-20099 Hamburg 2165 Germany 2167 Phone: +4940428758067 2168 Email: cenk.guendogan@haw-hamburg.de 2169 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 2171 Thomas C. Schmidt 2172 HAW Hamburg 2173 Berliner Tor 7 2174 D-20099 Hamburg 2175 Germany 2177 Email: t.schmidt@haw-hamburg.de 2178 URI: http://inet.haw-hamburg.de/members/schmidt 2179 Matthias Waehlisch 2180 link-lab & FU Berlin 2181 Hoenower Str. 35 2182 D-10318 Berlin 2183 Germany 2185 Email: mw@link-lab.net 2186 URI: http://www.inf.fu-berlin.de/~waehl 2188 Christopher Scherb 2189 University of Basel 2190 Spiegelgasse 1 2191 CH-4051 Basel 2192 Switzerland 2194 Email: christopher.scherb@unibas.ch 2196 Claudio Marxer 2197 University of Basel 2198 Spiegelgasse 1 2199 CH-4051 Basel 2200 Switzerland 2202 Email: claudio.marxer@unibas.ch 2204 Christian Tschudin 2205 University of Basel 2206 Spiegelgasse 1 2207 CH-4051 Basel 2208 Switzerland 2210 Email: christian.tschudin@unibas.ch