idnits 2.17.1 draft-irtf-icnrg-icnlowpan-03.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 (July 8, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 1446, but no explicit reference was found in the text 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: January 9, 2020 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 July 8, 2019 13 ICN Adaptation to LowPAN Networks (ICN LoWPAN) 14 draft-irtf-icnrg-icnlowpan-03 16 Abstract 18 In this document, a convergence layer for CCNx and NDN over IEEE 19 802.15.4 LoWPAN networks is defined. A new frame format is specified 20 to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. 21 For that, syntactic and semantic changes to the TLV-based header 22 formats 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 link fragmentation component of 26 the 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 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 5 67 3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 5 68 3.2. Stateless Header Compression . . . . . . . . . . . . . . 6 69 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 7 70 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 7 71 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 7 72 4.2. Link Fragmentation . . . . . . . . . . . . . . . . . . . 8 73 5. Space-efficient Message Encoding for NDN . . . . . . . . . . 9 74 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 10 76 5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 11 77 5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 14 78 6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 16 79 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 16 80 6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 16 81 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 17 82 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 23 83 7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 26 84 8. Stateful Header Compression . . . . . . . . . . . . . . . . . 27 85 8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 27 86 8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 28 87 8.3. Integrating Stateful Header Compression . . . . . . . . . 30 88 9. ICNLoWPAN Constants and Variables . . . . . . . . . . . . . . 30 89 10. Implementation Report and Guidance . . . . . . . . . . . . . 30 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 92 12.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . 31 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 95 13.2. Informative References . . . . . . . . . . . . . . . . . 32 97 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 35 98 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 99 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 35 100 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 36 101 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 38 102 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 38 103 A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 39 104 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 107 1. Introduction 109 The Internet of Things (IoT) has been identified as a promising 110 deployment area for Information Centric Networks (ICN), as 111 infrastructureless access to content, resilient forwarding, and in- 112 network data replication demonstrated notable advantages over the 113 traditional host-to-host approach on the Internet [NDN-EXP1], 114 [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate 115 mapping to link layer technologies has a large impact on the 116 practical performance of an ICN. This will be even more relevant in 117 the context of IoT communication where nodes often exchange messages 118 via low-power wireless links under lossy conditions. In this memo, 119 we address the base adaptation of data chunks to such link layers for 120 the ICN flavors NDN [NDN] and CCNx. 122 The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and 123 lossy networks (see "LLN" in [RFC7228]), in which devices are 124 typically battery-operated and constrained in resources. 125 Characteristics of LLNs include an unreliable environment, low 126 bandwidth transmissions, and increased latencies. IEEE 802.15.4 127 admits a maximum physical layer packet size of 127 octets. The 128 maximum frame header size is 25 octets, which leaves 102 octets for 129 the payload. IEEE 802.15.4 security features further reduce this 130 payload length by up to 21 octets, yielding a net of 81 octets for 131 CCNx or NDN packet headers, signatures and content. 133 6LoWPAN [RFC4944], [RFC6282] is a convergence layer that provides 134 frame formats, header compression and link fragmentation for IPv6 135 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces 136 a dispatching framework that prepends further information to 6LoWPAN 137 packets, including a protocol identifier for IEEE 802.15.4 payload 138 and meta information about link fragmentation. 140 Prevalent Type-Length-Value (TLV) based packet formats such as in 141 CCNx and NDN are designed to be generic and extensible. This leads 142 to header verbosity which is inappropriate in constrained 143 environments of IEEE 802.15.4 links. This document presents ICN 144 LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN 145 that compresses packet headers of CCNx as well as NDN and allows for 146 an increased payload size per packet. Additionally, reusing the 147 dispatching framework defined by 6LoWPAN enables compatibility 148 between coexisting wireless networks of competing technologies. This 149 also allows to reuse the link fragmentation scheme specified by 150 6LoWPAN for ICN LoWPAN. 152 ICN LoWPAN defines a more space efficient representation of CCNx and 153 NDN packet formats. This syntactic change is described for CCNx and 154 NDN separately, as the header formats and TLV encodings differ 155 largely. For further reductions, default header values suitable for 156 constrained IoT networks are selected in order to elide corresponding 157 TLVs. Experimental evaluations of the ICN LoWPAN header compression 158 schemes in [ICNLOWPAN] illustrate a reduced message overhead, a 159 shortened message airtime, and an overall decline in power 160 consumption for typical Class 2 devices compared to uncompressed ICN 161 messages. 163 In a typical IoT scenario (see Figure 1), embedded devices are 164 interconnected via a quasi-stationary infrastructure using a border 165 router (BR) that uplinks the constrained LoWPAN network by some 166 Gateway with the public Internet. In ICN based IoT networks, non- 167 local Interest and Data messages transparently travel through the BR 168 up and down between a Gateway and the embedded devices situated in 169 the constrained LoWPAN. 171 |Gateway Services| 172 ------------------------- 173 | 174 ,--------, 175 | | 176 | BR | 177 | | 178 '--------' 179 LoWPAN 180 O O 181 O 182 O O embedded 183 O O O devices 184 O O 186 Figure 1: IoT Stub Network 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 The use of the term, "silently ignore" is not defined in RFC 2119. 195 However, the term is used in this document and can be similarly 196 construed. 198 This document uses the terminology of [RFC7476], [RFC7927], and 199 [RFC7945] for ICN entities. 201 The following terms are used in the document and defined as follows: 203 ICN LoWPAN: Information-Centric Networking over Low-power Wireless 204 Personal Area Network 206 LLN Low-Power and Lossy Network 208 CCNx: Content-Centric Networking Architecture 210 NDN: Named Data Networking Architecture 212 time-value: a time value measured in seconds 214 time-code: an 8-bit encoded time-value 216 3. Overview of ICN LoWPAN 218 3.1. Link-Layer Convergence 220 ICN LoWPAN provides a convergence layer that maps ICN packets onto 221 constrained link-layer technologies. This includes features such as 222 link-layer fragmentation, protocol separation on the link-layer 223 level, and link-layer address mappings. The stack traversal is 224 visualized in Figure 2. 226 Device 1 Device 2 227 ,------------------, Router ,------------------, 228 | Application . | __________________ | ,-> Application | 229 |----------------|-| | NDN / CCNx | |-|----------------| 230 | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | 231 |----------------|-| |-|--------------|-| |-|----------------| 232 | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | 233 |----------------|-| |-|--------------|-| |-|----------------| 234 | Link-Layer | | | | Link-Layer | | | | Link-Layer | 235 '----------------|-' '-|--------------|-' '-|----------------' 236 '--------' '---------' 238 Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 240 Section 4 of this document defines the convergence layer for IEEE 241 802.15.4. 243 3.2. Stateless Header Compression 245 ICN LoWPAN also defines a stateless header compression scheme with 246 the main purpose of reducing header overhead of ICN packets. This is 247 of particular importance for link-layers with small MTUs. The 248 stateless compression does not require pre-configuration of global 249 state. 251 The CCNx and NDN header formats are composed of Type-Length-Value 252 (TLV) fields to encode header data. The advantage of TLVs is its 253 native support of variable-sized data. The main disadvantage of TLVs 254 is the verbosity that results from storing the type and length of the 255 encoded data. 257 The stateless header compression scheme makes use of compact bit 258 fields to indicate the presence of mandatory and optional TLVs in the 259 uncompressed packet. The order of set bits in the bit fields 260 corresponds to the order of each TLV in the packet. Further 261 compression is achieved by specifying default values and reducing the 262 codomain of certain header fields. 264 Figure 3 demonstrates the stateless header compression idea. In this 265 example, the first type of the first TLV is removed and the 266 corresponding bit in the bit field is set. The second TLV represents 267 a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type and 268 the length fields are removed. The third TLV represents a boolean 269 TLV (e.g., the MustBeFresh selector in NDN) and is missing the type, 270 length and the value field. 272 +---+---+---+---+---+---+---+---+ 273 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field 274 +---+---+---+---+---+---+---+---+ 275 | | | 276 ,--' '-----------, '- boolean 277 | | 278 +-------+--------------+-------------+ 279 | LEN | VALUE | VALUE | 280 +-------+--------------+-------------+ 282 Figure 3: Compression using a compact bit field to encode context 283 information. 285 Stateless TLV compression for NDN is defined in Section 5. Section 6 286 defines the stateless TLV compression for CCNx. 288 3.3. Stateful Header Compression 290 ICN LoWPAN further employs two orthogonal stateful compression 291 schemes for packet size reductions which are defined in Section 8. 292 These mechanisms rely on shared contexts that are either distributed 293 and maintained in the entire LoWPAN, or are generated on-demand hop- 294 wise on a particular Interest-data path. 296 The shared context identification is defined in Section 8.1. The 297 hop-wise name compression "en-route" is specified in Section 8.2. 299 4. IEEE 802.15.4 Adaptation 301 4.1. LoWPAN Encapsulation 303 The IEEE 802.15.4 frame header does not provide a protocol identifier 304 for its payload. This causes problems of misinterpreting frames when 305 several network layers coexist on the same link. To mitigate errors, 306 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 307 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation 308 headers can prepend the actual payload and each encapsulation header 309 is identified by a dispatch type. 311 [RFC8025] further specifies dispatch pages to switch between 312 different contexts. When a LoWPAN parser encounters a "Page switch" 313 LoWPAN encapsulation header, then all following encapsulation headers 314 are interpreted by using a dispatch table as specified by the "Page 315 switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This 316 document uses page 2 ("1111 0010 (0xF2)") for NDN and page 3 ("1111 317 0011 (0xF3)") for CCNx. 319 The base dispatch format (Figure 4) is used and extended by CCNx and 320 NDN in Section 5 and Section 6. 322 0 1 2 ... 323 +---+---+-------- 324 | C | M | 325 +---+---+-------- 327 Figure 4: Base dispatch format for ICN LoWPAN 329 C: Compression 331 0: The message is uncompressed. 333 1: The message is compressed. 335 M: Message Type 336 0: The payload contains an Interest message. 338 1: The payload contains a Data message. 340 ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the 341 extended dispatch format in Figure 5. 343 0 1 2 ... 344 +---+---+-------- 345 | 1 | M |CID| 346 +---+---+-------- 348 Figure 5: Extended dispatch format for compressed ICN LoWPAN 350 CID: Context Identifier 352 0: No context identifiers are present. 354 1: 1..n context identifiers are present. 356 The encapsulation format for ICN LoWPAN is displayed in Figure 6. 358 +------...------+------...-----+--------+-------...-------+-----... 359 | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / 360 +------...------+------...-----+--------+-------...-------+-----... 362 Figure 6: LoWPAN Encapsulation with ICN-LoWPAN 364 IEEE 802.15.4: The IEEE 802.15.4 header. 366 RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 367 of [RFC4944] 369 Page: Page Switch. 2 for NDN and 3 for CCNx. 371 ICN LoWPAN: Dispatches defined in Section 5 and Section 6. 373 Payload: The actual (un-)compressed CCNx or NDN message. 375 4.2. Link Fragmentation 377 Small payload sizes in the LoWPAN require fragmentation for various 378 network layers. Therefore, Section 5.3 of [RFC4944] defines a 379 protocol-independent fragmentation dispatch type, a fragmentation 380 header for the first fragment, and a separate fragmentation header 381 for subsequent fragments. ICN LoWPAN adopts this fragmentation 382 handling of [RFC4944]. 384 The Fragmentation LoWPAN header can encapsulate other dispatch 385 headers. The order of dispatch types is defined in Section 5 of 386 [RFC4944]. Figure 7 shows the fragmentation scheme. The reassembled 387 ICN LoWPAN frame does not contain any fragmentation headers and is 388 depicted in Figure 8. 390 +------...------+----...----+--------+------...-------+--------... 391 | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / 392 +------...------+----...----+--------+------...-------+--------... 394 +------...------+----...----+--------... 395 | IEEE 802.15.4 | Frag. 2nd | Payload / 396 +------...------+----...----+--------... 398 . 399 . 400 . 402 +------...------+----...----+--------... 403 | IEEE 802.15.4 | Frag. Nth | Payload / 404 +------...------+----...----+--------... 406 Figure 7: Fragmentation scheme 408 +------...------+--------+------...-------+--------... 409 | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / 410 +------...------+--------+------...-------+--------... 412 Figure 8: Reassembled ICN LoWPAN frame 414 5. Space-efficient Message Encoding for NDN 416 5.1. TLV Encoding 418 The NDN packet format consists of TLV fields using the TLV encoding 419 that is described in [NDN-PACKET-SPEC]. Type and length fields are 420 of variable size, where numbers greater than 252 are encoded using 421 multiple octets. 423 If the type or length number is less than "253", then that number is 424 encoded into the actual type or length field. If the number is 425 greater or equals "253" and fits into 2 octets, then the type or 426 lengh field is set to "253" and the number is encoded in the next 427 following 2 octets in network byte order, i.e., from the most 428 significant byte (MSB) to the least significant byte (LSB). If the 429 number is greater than 2 octets and fits into 4 octets, then the type 430 or length field is set to "254" and the number is encoded in the 431 subsequent 4 octets in network byte order. For larger numbers, the 432 type or length field is set to "255" and the number is encoded in the 433 subsequent 8 octets in network byte order. 435 In this specification, compressed NDN TLVs make use of a different 436 TLV encoding scheme that reduces size. Instead of using the first 437 octet as a marker for the number of following octets, the compressed 438 NDN TLV scheme uses a method to chain a variable number of octets 439 together. If an octet equals "255 (0xFF)", then the following octet 440 will also be interpreted. The actual value of a chain equals the sum 441 of all links. 443 If the type or length number is less than "255", then that number is 444 encoded into the actual type or length field (Figure 9 a). If the 445 type or length number (X) fits into 2 octets, then the first octet is 446 set to "255" and the subsequent octet equals "X mod 255" (Figure 9 447 b). Following this scheme, a variable-sized number (X) is encoded 448 using multiple octets of "255" with a trailing octet containing "X 449 mod 255" (Figure 9 c). 451 0 1 2 3 4 5 6 7 452 +-+-+-+-+-+-+-+-+ 453 a) | < 255 (X) | = X 454 +-+-+-+-+-+-+-+-+ 456 0 1 457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 b) | 255 | < 255 (X) | = 255 + X 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 0 463 0 1 2 3 4 5 6 7 464 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 465 c) | 255 | 255 | < 255 (X) | = (N * 255) + X 466 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 467 (N - 1) 469 Figure 9: Compressed NDN TLV encoding scheme 471 5.2. Name TLV Compression 473 This Name TLV compression encodes length fields of two consecutive 474 NameComponent TLVs into one octet, using 4 bits each. This process 475 limits the length of a NameComponent TLV to 15 octets. A length of 0 476 marks the end of the compressed Name TLV. 478 Name: /HAW/Room/481/Humid/99 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 |0 0 1 1|0 1 0 0| H | A | W | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | R | o | o | m | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | H | u | m | i | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | d |0 0 1 0|0 0 0 0| 9 | 9 | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 10: Name TLV compression for /HAW/Room/481/Humid/99 496 5.3. Interest Messages 498 5.3.1. Uncompressed Interest Messages 500 An uncompressed Interest message uses the base dispatch format (see 501 Figure 4) and sets the C as well as the M flag to "0" (Figure 11). 502 "resv" MUST be set to 0. The Interest message is handed to the NDN 503 network stack without modifications. 505 0 1 ... 7 506 +---+---+-----------------------+ 507 | 0 | 0 | resv | 508 +---+---+-----------------------+ 510 Figure 11: Dispatch format for uncompressed NDN Interest messages 512 5.3.2. Compressed Interest Messages 514 The compressed Interest message uses the extended dispatch format 515 (Figure 5) and sets the C flag to "1" and the M flag to "0". This 516 specification assumes the presence of a HopLimit TLV, which will be 517 set to a default value of DEFAULT_NDN_HOPLIMIT prior to the 518 compression if absent in the original message. In the default use 519 case, the Interest message is compressed with the following minimal 520 rule set: 522 1. The "Type" field of the outermost MessageType TLV is removed. 524 2. The Name TLV is compressed according to Section 5.2. For this, 525 all NameComponents are expected to be of type 526 GenericNameComponent. Otherwise, the message MUST be sent 527 uncompressed. 529 3. InterestLifetime TLV is encoded as described in Section 7. If a 530 lifetime is not a valid time-value, then the lifetime is rounded 531 up to the nearest valid time-value (see Section 7). 533 4. The Nonce TLV, HopLimit TLV and InterestLifetime TLV MUST be 534 moved to the end of the compressed Interest, keeping the order 1) 535 Nonce TLV, 2) HopLimit TLV and 3) InterestLifetime TLV. 537 5. The Type and Length fields of Nonce TLV, HopLimit TLV and 538 InterestLifetime TLV are elided. The Nonce value has a length of 539 4 octets and the HopLimit value has a length of 1 octet. The 540 compressed InterestLifetime (Section 7) has a length of 1 octet. 541 The presence of an InterestLifetime TLV is deduced from the 542 remaining length to parse. 544 The compressed NDN LoWPAN Interest message is visualized in 545 Figure 12. 547 T = Type, L = Length, V = Value 549 +--------+--------+ +--------+ 550 | Msg T | Msg L | | Msg L | 551 +--------+--------+--------+ +--------+ 552 | Name T | Name L | Name V | | Name V | 553 +--------+--------+--------+ +--------+--------+ 554 | CBPfx T| CBPfx L| | FWDH L | FWDH V | 555 +--------+--------+ +--------+--------+ 556 | MBFr T | MBFr L | | PRM L | PRM V | 557 +--------+--------+--------+ ==> +--------+--------+ 558 | FWDH T | FWDH L | FWDH V | | NONC V | 559 +--------+--------+--------+ +--------+ 560 | NONC T | NONC L | NONC V | | HPL V | 561 +--------+--------+--------+ +--------+ 562 | ILT T | ILT L | ILT V | | ILT V | 563 +--------+--------+--------+ +--------+ 564 | HPL T | HPL L | HPL V | 565 +--------+--------+--------+ 566 | PRM T | PRM L | PRM V | 567 +--------+--------+--------+ 569 Figure 12: Compression of NDN LoWPAN Interest Message 571 Further TLV compression is indicated by the ICN LoWPAN dispatch in 572 Figure 13. 574 0 1 2 3 4 5 6 7 575 +---+---+---+---+---+---+---+---+ 576 | 1 | 0 |CID|DIG|PFX|FRE|FWD|PRM| 577 +---+---+---+---+---+---+---+---+ 579 Figure 13: Dispatch format for compressed NDN Interest messages 581 CID: Context Identifier See Figure 5. 583 DIG: ImplicitSha256DigestComponent TLV 585 0: The name does not include an 586 ImplicitSha256DigestComponent as the last TLV. 588 1: The name does include an 589 ImplicitSha256DigestComponent as the last TLV. The 590 Type and Length fields are omitted. 592 PFX: CanBePrefix TLV 594 0: The uncompressed message does not include a 595 CanBePrefix TLV. 597 1: The uncompressed message does include a CanBePrefix 598 TLV and is removed from the compressed message. 600 FRE: MustBeFresh TLV 602 0: The uncompressed message does not include a 603 MustBeFresh TLV. 605 1: The uncompressed message does include a MustBeFresh 606 TLV and is removed from the compressed message. 608 FWD: ForwardingHint TLV 610 0: The uncompressed message does not include a 611 ForwardingHint TLV. 613 1: The uncompressed message does include a 614 ForwardingHint TLV. The Type field is removed from 615 the compressed message. 617 PRM: Parameters TLV 619 0: The uncompressed message does not include a 620 Parameters TLV. 622 1: The uncompressed message does include a Parameters 623 TLV. The Type field is removed from the compressed 624 message. 626 5.4. Data Messages 628 5.4.1. Uncompressed Data Messages 630 An uncompressed Data message uses the base dispatch format and sets 631 the C flag to "0" and the M flag to "1" (Figure 14). "resv" MUST be 632 set to 0. The Data message is handed to the NDN network stack 633 without modifications. 635 0 1 ... 7 636 +---+---+-----------------------+ 637 | 0 | 1 | resv | 638 +---+---+-----------------------+ 640 Figure 14: Dispatch format for uncompressed NDN Data messages 642 5.4.2. Compressed Data Messages 644 The compressed Data message uses the extended dispatch format 645 (Figure 5) and sets the C flag as well as the M flag to "1". By 646 default, the Data message is compressed with the following base rule 647 set: 649 1. The "Type" field of the outermost MessageType TLV is removed. 651 2. The Name TLV is compressed according to Section 5.2. For this, 652 all NameComponents are expected to be of type 653 GenericNameComponent. Otherwise, the message MUST be sent 654 uncompressed. 656 3. The MetaInfo TLV as well as Content TLV Type and Length fields 657 are elided from the compressed Data message. 659 4. If present, the FinalBlockId TLV is encoded according to 660 Section 5.2. 662 5. The FreshnessPeriod TLV MUST be moved to the end of the 663 compressed Data message and the length is set to 1. Type and 664 Length fields are elided and the value is encoded as described in 665 Section 7. If the freshness period is not a valid time-value, 666 then the message MUST be sent uncompressed in order to preserve 667 the security envelope of the Data message. The presence of a 668 FreshnessPeriod TLV is deduced from the remaining length to 669 parse. 671 The compressed NDN LoWPAN Data message is visualized in Figure 15. 673 T = Type, L = Length, V = Value 675 +--------+--------+ +--------+ 676 | Msg T | Msg L | | Msg L | 677 +--------+--------+--------+ +--------+ 678 | Name T | Name L | Name V | | Name V | 679 +--------+--------+--------+ +--------+ 680 | Meta T | Meta L | | CTyp V | 681 +--------+--------+--------+ +--------+ 682 | CTyp T | CTyp L | CTyp V | | FBID V | 683 +--------+--------+--------+ ==> +--------+--------+ 684 | FrPr T | FrPr L | FrPr V | | CONT L | CONT V | 685 +--------+--------+--------+ +--------+--------+ 686 | FBID T | FBID L | FBID V | | Sig L | 687 +--------+--------+--------+ +--------+--------+ 688 | CONT T | CONT L | CONT V | | SInf L | SInf V | 689 +--------+--------+--------+ +--------+--------+ 690 | Sig T | Sig L | | SVal L | SVal V | 691 +--------+--------+--------+ +--------+--------+ 692 | SInf T | SInf L | SInf V | | FrPr V | 693 +--------+--------+--------+ +--------+ 694 | SVal T | SVal L | SVal V | 695 +--------+--------+--------+ 697 Figure 15: Compression of NDN LoWPAN Data Message 699 Further TLV compression is indicated by the ICN LoWPAN dispatch in 700 Figure 16. 702 0 1 2 3 4 5 6 7 703 +---+---+---+---+---+---+---+---+ 704 | 1 | 1 |CID|DIG|FBI|CON| SIG | 705 +---+---+---+---+---+---+---+---+ 707 Figure 16: Dispatch format for compressed NDN Data messages 709 CID: Context Identifier See Figure 5. 711 DIG: ImplicitSha256DigestComponent TLV 713 0: The name does not include an 714 ImplicitSha256DigestComponent as the last TLV. 716 1: The name does include an 717 ImplicitSha256DigestComponent as the last TLV. The 718 Type and Length fields are omitted. 720 FBI: FinalBlockId TLV 722 0: The uncompressed message does not include a 723 FinalBlockId TLV. 725 1: The uncompressed message does include a FinalBlockId. 727 CON: ContentType TLV 729 0: The uncompressed message does not include a 730 ContentType TLV. 732 1: The uncompressed message does include a ContentType 733 TLV. The Type field is removed from the compressed 734 message. 736 SIG: Signature TLV 738 00: The Type fields of the SignatureInfo TLV, 739 SignatureType TLV and SignatureValue TLV are removed. 741 01: Reserved. 743 10: Reserved. 745 11: Reserved. 747 6. Space-efficient Message Encoding for CCNx 749 6.1. TLV Encoding 751 The generic CCNx TLV encoding is described in 752 [I-D.irtf-icnrg-ccnxmessages]. Type and Length fields attain the 753 common fixed length of 2 octets. 755 The TLV encoding for CCNx LoWPAN is changed to the more space 756 efficient encoding described in Section 5.1. Hence NDN and CCNx use 757 the same compressed format for writing TLVs. 759 6.2. Name TLV Compression 761 Name TLVs are compressed using the scheme already defined in 762 Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or 763 organizational TLVs, then the name remains uncompressed. 765 6.3. Interest Messages 767 6.3.1. Uncompressed Interest Messages 769 An uncompressed Interest message uses the base dispatch format (see 770 Figure 4) and sets the C as well as the M flag to "0" (Figure 17). 771 "resv" MUST be set to 0. The Interest message is handed to the CCNx 772 network stack without modifications. 774 0 1 ... 7 775 +---+---+-----------------------+ 776 | 0 | 0 | resv | 777 +---+---+-----------------------+ 779 Figure 17: Dispatch format for uncompressed CCNx Interest messages 781 6.3.2. Compressed Interest Messages 783 The compressed Interest message uses the extended dispatch format 784 (Figure 5) and sets the C flag to "1" and the M flag to "0". In the 785 default use case, the Interest message is compressed with the 786 following minimal rule set: 788 1. The Type and Length fields of the CCNx Message TLV are elided and 789 are obtained from the Fixed Header on decompression. 791 The compressed CCNx LoWPAN Interest message is visualized in 792 Figure 18. 794 T = Type, L = Length, V = Value 796 +--------------------------+ +--------------------------+ 797 | Uncompr. Fixed Header | | Compr. Fixed Header | 798 +--------------------------+ +--------------------------+ 799 +--------+--------+--------+ +--------+ 800 | ILT T | ILT L | ILT V | | ILT V | 801 +--------+--------+--------+ +--------+ 802 | MSGH T | MSGH L | MSGH V | | MSGH V | 803 +--------+--------+--------+ +--------+ 804 +--------+--------+ +--------+ 805 | MSGT T | MSGT L | | Name V | 806 +--------+--------+--------+ +--------+ 807 | Name T | Name L | Name V | ==> | KIDR V | 808 +--------+--------+--------+ +--------+ 809 | KIDR T | KIDR L | KIDR V | | OBHR V | 810 +--------+--------+--------+ +--------+--------+ 811 | OBHR T | OBHR L | OBHR V | | PAYL L | PAYL V | 812 +--------+--------+--------+ +--------+--------+ 813 | PAYL T | PAYL L | PAYL V | | VALG L | VALG V | 814 +--------+--------+--------+ +--------+--------+ 815 | VALG T | VALG L | VALG V | | VPAY L | VPAY V | 816 +--------+--------+--------+ +--------+--------+ 817 | VPAY T | VPAY L | VPAY V | 818 +--------+--------+--------+ 820 Figure 18: Compression of CCNx LoWPAN Interest Message 822 Further TLV compression is indicated by the ICN LoWPAN dispatch in 823 Figure 19. 825 0 1 826 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 827 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 828 | 1 | 0 |CID|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|EXT|RSV| 829 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 831 Figure 19: Dispatch format for compressed CCNx Interest messages 833 CID: Context Identifier See Figure 5. 835 VER: CCNx protocol version in the fixed header 837 0: The Version field equals 1 and is removed from the fixed 838 header. 840 1: The Version field is carried in-line. 842 FLG: Flags field in the fixed header 844 0: The Flags field equals 0 and is removed from the Interest 845 message. 847 1: The Flags field is carried in-line. 849 PTY: PacketType field in the fixed header 851 0: The PacketType field is elided and assumed to be 852 "PT_INTEREST" 854 1: The PacketType field is elided and assumed to be 855 "PT_RETURN" 857 HPL: HopLimit field in the fixed header 859 0: The HopLimit field is carried in-line 861 1: The HopLimit field is elided and assumed to be "1" 863 FRS: Reserved field in the fixed header 865 0: The Reserved field is carried in-line 867 1: The Reserved field is elided and assumed to be "0" 869 PAY: Optional Payload TLV 871 0: The Payload TLV is absent. 873 1: The Payload TLV is present and the type field is elided. 875 ILT: Optional Hop-By-Hop InterestLifetime TLV 877 See Section 6.3.2.1 for further details on the ordering 878 of hop-by-hop TLVs. 880 0: No InterestLifetime TLV is present in the Interest 881 message. 883 1: An InterestLifetime TLV is present with a fixed length of 884 1 octet and is encoded as described in Section 7. The 885 type and length fields are elided. If a lifetime is not 886 a valid time-value, then the lifetime is rounded up to 887 the nearest valid time-value (see Section 7). 889 MGH: Optional Hop-By-Hop MessageHash TLV 890 See Section 6.3.2.1 for further details on the ordering 891 of hop-by-hop TLVs. 893 This TLV is expected to contain a T_SHA-256 TLV. If 894 another hash is contained, then the Interest MUST be sent 895 uncompressed. 897 0: The MessageHash TLV is absent. 899 1: A T_SHA-256 TLV is present and the type as well as the 900 length fields are removed. The length field is assumed 901 to represent 32 octets. The outer Message Hash TLV is 902 omitted. 904 KIR: Optional KeyIdRestriction TLV 906 This TLV is expected to contain a T_SHA-256 TLV. If 907 another hash is contained, then the Interest MUST be sent 908 uncompressed. 910 0: The KeyIDRestriction TLV is absent. 912 1: A T_SHA-256 TLV is present and the type as well as the 913 length fields are removed. The length field is assumed 914 to represent 32 octets. The outer KeyIdRestriction TLV 915 is omitted. 917 CHR: Optional ContentObjectHashRestriction TLV 919 This TLV is expected to contain a T_SHA-256 TLV. If 920 another hash is contained, then the Interest MUST be sent 921 uncompressed. 923 0: The ContentObjectHashRestriction TLV is absent. 925 1: A T_SHA-256 TLV is present and the type as well as the 926 length fields are removed. The length field is assumed 927 to represent 32 octets. The outer 928 ContentObjectHashRestriction TLV is omitted. 930 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 932 0: No validation related TLVs are present in the Interest 933 message. 935 1: Validation related TLVs are present in the Interest 936 message. An additional octet follows immediately that 937 handles validation related TLV compressions and is 938 described in Section 6.3.2.2. 940 EXT: Extension 942 0: No extension octet follows. 944 1: An extension octet follows immediately. Extension octets 945 are used to extend the compression scheme, but are out of 946 scope of this document. 948 RSV: Reserved Must be set to 0. 950 6.3.2.1. Hop-By-Hop Header TLVs Compression 952 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 953 optional Hop-By-Hop Header TLVs are defined in 954 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 955 higher level specifications. For a compressed representation, this 956 document defines the following ordering of Hop-By-Hop TLVs: 958 1. Interest Lifetime TLV 960 2. Message Hash TLV 962 Note: If the original Interest message includes Hop-By-Hop Header 963 TLVs that follow a different ordering, then the message MUST be sent 964 uncompressed. 966 6.3.2.2. Validation 968 0 1 2 3 4 5 6 7 8 969 +-------+-------+-------+-------+-------+-------+-------+-------+ 970 | ValidationAlg | KeyID | Reserved | 971 +-------+-------+-------+-------+-------+-------+-------+-------+ 973 Figure 20: Dispatch for Interset Validations 975 ValidationALg: Optional ValidationAlgorithm TLV 977 0000: An uncompressed ValidationAlgorithm TLV is included. 979 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 980 ValidationAlgorithm TLV is included. 982 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 983 ValidationAlgorithm TLV is included. Additionally, a 984 Sigtime TLV is inlined without a type and a length field. 986 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 987 no ValidationAlgorithm TLV is included. 989 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 990 no ValidationAlgorithm TLV is inclued. Additionally, a 991 Sigtime TLV is inlined without a type and a length field. 993 0101: Reserved. 995 0110: Reserved. 997 0111: Reserved. 999 1000: Reserved. 1001 1001: Reserved. 1003 1010: Reserved. 1005 1011: Reserved. 1007 1100: Reserved. 1009 1101: Reserved. 1011 1110: Reserved. 1013 1111: Reserved. 1015 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1017 00: The KeyId TLV is absent. 1019 01: The KeyId TLV is present and uncompressed. 1021 10: A T_SHA-256 TLV is present and the type field as well as 1022 the length fields are removed. The length field is 1023 assumed to represent 32 octets. The outer KeyId TLV is 1024 omitted. 1026 11: A T_SHA-512 TLV is present and the type field as well as 1027 the length fields are removed. The length field is 1028 assumed to represent 64 octets. The outer KeyId TLV is 1029 omitted. 1031 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1032 is present. The type field is omitted. 1034 6.4. Content Objects 1036 6.4.1. Uncompressed Content Objects 1038 An uncompressed Content object uses the base dispatch format (see 1039 Figure 4) and sets the C flag to "0" and the M flag to "1" 1040 (Figure 21). "resv" MUST be set to 0. The Content object is handed 1041 to the CCNx network stack without modifications. 1043 0 1 ... 7 1044 +---+---+-----------------------+ 1045 | 0 | 1 | resv | 1046 +---+---+-----------------------+ 1048 Figure 21: Dispatch format for uncompressed CCNx Content objects 1050 6.4.2. Compressed Content Objects 1052 The compressed Content object uses the extended dispatch format 1053 (Figure 5) and sets the C flag as well as the M flag to "1". By 1054 default, the Content object is compressed with the following base 1055 rule set: 1057 1. The PacketType field is elided from the Fixed Header. 1059 2. The Type and Length fields of the CCNx Message TLV are elided and 1060 are obtained from the Fixed Header on decompression. 1062 The compressed CCNx LoWPAN Data message is visualized in Figure 22. 1064 T = Type, L = Length, V = Value 1066 +--------------------------+ +--------------------------+ 1067 | Uncompr. Fixed Header | | Compr. Fixed Header | 1068 +--------------------------+ +--------------------------+ 1069 +--------+--------+--------+ +--------+ 1070 | RCT T | RCT L | RCT V | | RCT V | 1071 +--------+--------+--------+ +--------+--------+ 1072 | MSGH T | MSGH L | MSGH V | | MSGH L | MSGH V | 1073 +--------+--------+--------+ +--------+--------+ 1074 +--------+--------+ +--------+ 1075 | MSGT T | MSGT L | | Name V | 1076 +--------+--------+--------+ +--------+ 1077 | Name T | Name L | Name V | ==> | EXPT V | 1078 +--------+--------+--------+ +--------+--------+ 1079 | PTYP T | PTYP L | PTYP V | | PAYL L | PAYL V | 1080 +--------+--------+--------+ +--------+--------+ 1081 | EXPT T | EXPT L | EXPT V | | VALG L | VALG V | 1082 +--------+--------+--------+ +--------+--------+ 1083 | PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V | 1084 +--------+--------+--------+ +--------+--------+ 1085 | VALG T | VALG L | VALG V | 1086 +--------+--------+--------+ 1087 | VPAY T | VPAY L | VPAY V | 1088 +--------+--------+--------+ 1090 Figure 22: Compression of CCNx LoWPAN Data Message 1092 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1093 Figure 23. 1095 0 1 1096 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1097 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1098 | 1 | 1 |CID|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|EXT| RSV | 1099 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1101 Figure 23: Dispatch format for compressed CCNx Content objects 1103 CID: Context Identifier See Figure 5. 1105 VER: CCNx protocol version in the fixed header 1107 0: The Version field equals 1 and is removed from the fixed 1108 header. 1110 1: The Version field is carried in-line. 1112 FLG: Flags field in the fixed header See Section 6.3.2. 1114 FRS: Reserved field in the fixed header See Section 6.3.2. 1116 PAY: Optional Payload TLV See Section 6.3.2. 1118 RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 1120 0: The Recommended Cache Time TLV is absent. 1122 1: The Recommended Cache Time TLV is present and the type as 1123 well as the length fields are elided. 1125 MGH: Optional Hop-By-Hop MessageHash TLV 1127 See Section 6.4.2.1 for further details on the ordering 1128 of hop-by-hop TLVs. 1130 This TLV is expected to contain a T_SHA-256 TLV. If 1131 another hash is contained, then the Content Object MUST 1132 be sent uncompressed. 1134 0: The MessageHash TLV is absent. 1136 1: A T_SHA-256 TLV is present and the type as well as the 1137 length fields are removed. The length field is assumed 1138 to represent 32 octets. The outer Message Hash TLV is 1139 omitted. 1141 PLTYP: Optional PayloadType TLV 1143 00: The PayloadType TLV is absent. 1145 01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA 1146 is assumed. 1148 10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY 1149 is assumed. 1151 11: The PayloadType TLV is present and uncompressed. 1153 EXP: Optional ExpiryTime TLV 1155 0: The ExpiryTime TLV is absent. 1157 1: The ExpiryTime TLV is present and the type as well as the 1158 length fields are elided. 1160 RSV: Reserved Must be set to 0. 1162 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1163 tion 6.3.2. 1165 EXT: Extension See Section 6.3.2. 1167 6.4.2.1. Hop-By-Hop Header TLVs Compression 1169 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1170 two optional Hop-By-Hop Header TLVs are defined in 1171 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 1172 higher level specifications. For better compression, an ordering of 1173 Hop-By-Hop TLVs is required as follows: 1175 1. Recommended Cache Time TLV 1177 2. Message Hash TLV 1179 With this ordering in place, Type fields are elided from the 1180 Recommended Cache Time TLV and Message Hash TLV. 1182 Note: If the original Content Object message includes Hop-By-Hop 1183 Header TLVs with a different ordering, then they remain uncompressed. 1185 7. Compressed Time Encoding 1187 This document defines a compressed TLV encoding format for time- 1188 values that is inspired from [RFC5497]. 8-bit time-codes are used to 1189 represent time-values ranging from milliseconds to days. 1191 Time-codes are constructed using the formula: 1193 time-code := 8 * b + a 1195 where a is the mantissa and b the exponent of a time-value that 1196 follows the form: 1198 time-value := (1 + a/8) * 2^b * C 1200 The least significant 3 bits of a time-code represents the mantissa 1201 (a) and the most significant 5 bits represent the exponent (b). C is 1202 set to 1/1024 seconds in order to achieve a millisecond resolution. 1204 A time-code of all-bits zero MUST be decoded as a time-value of all- 1205 bits zero. The smallest representable time-value is thus 0 (a=0, 1206 b=0), the second smallest is ~1 ms (a=1, b=0), and the largest time- 1207 value is ~45 days (a=7, b=31). 1209 An invalid time-value (t, in seconds) MUST be rounded up to the 1210 nearest valid time-value using this algorithm: 1212 o set b := floor(log2(t/C)) 1214 o set a := 8 * (t / (C * 2^b) - 1) 1216 8. Stateful Header Compression 1218 Stateful header compression in ICN LoWPAN enables packet size 1219 reductions in two ways. First, common information that is shared 1220 throughout the local LoWPAN may be memorized in context state at all 1221 nodes and ommitted from communication. Second, redundancy in a 1222 single Interest-data exchange may be removed from ICN stateful 1223 forwarding on a hop-by-hop bases and memorized in en-route state 1224 tables. 1226 8.1. LoWPAN-local State 1228 A context identifier (CID) is an octet that refers to a particular 1229 conceptual context between network devices and MAY be used to replace 1230 frequently appearing information, like name prefixes, suffixes, or 1231 meta information, such as Interest lifetime. 1233 0 1 2 3 4 5 6 7 1234 +---+---+---+---+---+---+---+---+ 1235 | X | ContextID | 1236 +---+---+---+---+---+---+---+---+ 1238 Figure 24: Context Identifier. 1240 The ContextID refers to a locally-scoped unique identifyer that 1241 represents contextual state shared between sender and receiver of the 1242 corresponding frame (see Figure 24). 1244 The initial distribution and maintenance of shared context is out of 1245 scope of this document. Frames containing unknown or invalid CIDs 1246 MUST be silently discarded. 1248 8.2. En-route State 1250 In CCNx and NDN, Name TLVs are included in Interest messages, and 1251 they return in data messages. Returning Name TLVs either equal the 1252 original Name TLV, or they contain the original Name TLV as a prefix. 1253 ICN LoWPAN reduces this redundancy in responses by replacing Name 1254 TLVs with single octets that represent link-local HopIDs. HopIDs are 1255 carried as Context Identifiers of link-local scope as shown in 1256 Figure 25. 1258 0 1 2 3 4 5 6 7 1259 +---+---+---+---+---+---+---+---+ 1260 | X | HopID | 1261 +---+---+---+---+---+---+---+---+ 1263 Figure 25: Context Identifier as HopID. 1265 A HopID is valid, if not all ID bits are set to zero and invalid 1266 otherwise. This yields 127 distinct HopIDs. If this range (1...128) 1267 is exhausted, the messages MUST be sent without en-route state 1268 compression until new HopIDs are available. An ICN LoWPAN node that 1269 forwards without replacing the name by a HopID (without en-route 1270 compression) MUST invalidate the HopID by setting all ID-bits to 1271 zero. 1273 While an Interest is traversing, a forwarder generates an ephemeral 1274 HopID that is tied to a PIT entry. Each HopID MUST be unique within 1275 the local PIT and only exists during the lifetime of a PIT entry. To 1276 maintain HopIDs, the local PIT is extended by two new columns: HIDi 1277 (inbound HopIDs) and HIDo (outbound HopIDs). 1279 HopIDs are included in Interests and stored on the next hop with the 1280 resulting PIT entry in the HIDi column. The HopID is replaced with a 1281 newly generated local HopID before the Interest is forwarded. This 1282 new HopID is stored in the HIDo column of the local PIT (see 1283 Figure 26). 1285 PIT of B PIT Extension PIT of C PIT Extension 1286 +--------+------++------+------+ +--------+------++------+------+ 1287 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1288 +========+======++======+======+ +========+======++======+======+ 1289 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1290 +--------+------++------+------+ +--------+------++------+------+ 1291 ^ | ^ 1292 store | '----------------------, ,---' store 1293 | send v | 1294 ,---, /p0, h_A ,---, /p0, h_B ,---, 1295 | A | ------------------------> | B | ------------------------> | C | 1296 '---' '---' '---' 1298 Figure 26: Setting compression state en-route (Interest). 1300 Responses include HopIDs that were obtained from Interests. If the 1301 returning Name TLV equals the original Name TLV, then the name is 1302 entirely elided. Otherwise, the distinct suffix is included along 1303 with the HopID. When a response is forwarded, the contained HopID is 1304 extracted and used to match against the correct PIT entry by 1305 performing a lookup on the HIDo column. The HopID is then replaced 1306 with the corresponding HopID from the HIDi column prior to forwarding 1307 the reponse (Figure 27). 1309 PIT of B PIT Extension PIT of C PIT Extension 1310 +--------+------++------+------+ +--------+------++------+------+ 1311 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1312 +========+======++======+======+ +========+======++======+======+ 1313 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1314 +--------+------++------+------+ +--------+------++------+------+ 1315 | ^ | 1316 send | '----------------------, ,---' send 1317 v match | v 1318 ,---, h_A ,---, h_B ,---, 1319 | A | <------------------------ | B | <------------------------ | C | 1320 '---' '---' '---' 1322 Figure 27: Eliding Name TLVs using en-route state (data). 1324 It should be noted that each forwarder of an Interest in an ICN 1325 LoWPAN network can individuall decide whether to paricipate in en- 1326 route compression or not. However, an ICN LoWPAN node SHOULD use en- 1327 route compression whenever the stateful compression mechanism is 1328 activated. 1330 Note also that the extensions of the PIT data structure are required 1331 only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside 1332 of an ICN LoWPAN domain do not need to implement these extensions. 1334 8.3. Integrating Stateful Header Compression 1336 A CID appears whenever the CID flag is set (see Figure 5). The CID 1337 is appended to the last ICN LoWPAN dispatch octet as shown in 1338 Figure 28. 1340 ...-------+--------+-------...-------+--...-+-------... 1341 / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / 1342 ...-------+--------+-------...-------+--...-+-------... 1344 Figure 28: LoWPAN Encapsulation with ICN LoWPAN and CIDs 1346 Multiple CIDs are chained together, with the most significant bit 1347 indicating the presence of a subsequent CID (Figure 29). 1349 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1350 |1| CID | --> |1| CID | --> |0| CID | 1351 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1353 Figure 29: Chaining of context identifiers. 1355 The HopID is always included as the very first CID. 1357 9. ICNLoWPAN Constants and Variables 1359 This is a summary of all ICNLoWPAN constants and variables. 1361 DEFAULT_NDN_HOPLIMIT: 255 1363 10. Implementation Report and Guidance 1365 The ICN LoWPAN scheme defined in this document has been implemented 1366 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT 1367 version on RIOT [RIOT]. An experimental evaluation with varying 1368 configurations is performed in [ICNLOWPAN]. 1370 The header compression performance depends on certain aspects and 1371 configurations. It works best for the following cases: 1373 o Each name component is of GenericNameComponent type and is limited 1374 to a length of 15 bytes. 1376 o Time-values for content freshness TLVs represent valid time-values 1377 as per Section 7. Interest lifetimes will round up to the nearest 1378 valid encoded time-value. 1380 o Contextual state is distributed, such that long names are elided 1381 from Interest and data messages. 1383 11. Security Considerations 1385 Main memory is typically a scarce resource of constrained networked 1386 devices. Fragmentation as described in this memo preserves fragments 1387 and purges them only after a packet is reassembled, which requires a 1388 buffering of all fragments. This scheme is able to handle fragments 1389 for distinctive packets simultaneously, which can lead to overflowing 1390 packet buffers which cannot hold all necessary fragments for packet 1391 reassembly. Implementers are thus urged to make use of appropriate 1392 buffer replacement strategies for fragments. 1394 The stateful header compression generates ephemeral HopIDs for 1395 incoming and outgoing Interests and consumes them on returning Data 1396 packets. Forged Interests can deplete the number of available 1397 HopIDs, thus leading to a denial of compression service for 1398 subsequent content requests. 1400 To further alleviate the problems caused by forged fragments or 1401 Interest initiations, proper protective mechanisms for accessing the 1402 link-layer should be deployed. 1404 12. IANA Considerations 1406 12.1. Page Switch Dispatch Type 1408 This document makes use of "Page 2" from the existing paging 1409 dispatches in [RFC8025]. 1411 13. References 1413 13.1. Normative References 1415 [ieee802.15.4] 1416 "IEEE Std. 802.15.4-2015", April 2016, 1417 . 1420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1421 Requirement Levels", BCP 14, RFC 2119, 1422 DOI 10.17487/RFC2119, March 1997, 1423 . 1425 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1426 "Transmission of IPv6 Packets over IEEE 802.15.4 1427 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1428 . 1430 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1431 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1432 DOI 10.17487/RFC6282, September 2011, 1433 . 1435 13.2. Informative References 1437 [CCN-LITE] 1438 "CCN-lite: A lightweight CCNx and NDN implementation", 1439 . 1441 [I-D.irtf-icnrg-ccnxmessages] 1442 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1443 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 1444 progress), January 2019. 1446 [I-D.irtf-icnrg-ccnxsemantics] 1447 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1448 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 1449 January 2019. 1451 [ICNLOWPAN] 1452 Gundogan, C., Kietzmann, P., Schmidt, TC., and M. 1453 Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low 1454 Power IoT Networks", Proc. of 18th IFIP Networking 1455 Conference , May 2019. 1457 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1458 "Networking Named Content", 5th Int. Conf. on emerging 1459 Networking Experiments and Technologies (ACM CoNEXT), 1460 2009, . 1462 [NDN-EXP1] 1463 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1464 Waehlisch, "Information Centric Networking in the IoT: 1465 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1466 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1467 77-86, September 2014, 1468 . 1470 [NDN-EXP2] 1471 Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 1472 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 1473 Comparative Measurement Study in the IoT", Proc. of 5th 1474 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 1475 DL, pp. 159-171, September 2018, 1476 . 1478 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1479 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1480 in NDN: Towards Quantifying the Resource Gain", Proc. of 1481 4th ACM Conf. on Information-Centric Networking (ICN- 1482 2017) ACM DL, pp. 36-42, September 2017, 1483 . 1485 [NDN-PACKET-SPEC] 1486 "NDN Packet Format Specification", 1487 . 1489 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1490 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1491 DOI 10.17487/RFC5497, March 2009, 1492 . 1494 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1495 Constrained-Node Networks", RFC 7228, 1496 DOI 10.17487/RFC7228, May 2014, 1497 . 1499 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1500 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1501 "Information-Centric Networking: Baseline Scenarios", 1502 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1503 . 1505 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1506 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1507 "Information-Centric Networking (ICN) Research 1508 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1509 . 1511 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1512 and G. Boggia, "Information-Centric Networking: Evaluation 1513 and Security Considerations", RFC 7945, 1514 DOI 10.17487/RFC7945, September 2016, 1515 . 1517 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1518 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1519 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1520 . 1522 [RIOT] Baccelli, E., Guenes, M., Hahm, O., Schmidt, TC., and M. 1523 Waehlisch, "RIOT OS: Towards an OS for the Internet of 1524 Things", Proc. of the 32nd IEEE INFOCOM IEEE Press, pp. 1525 79-80, April 2013, . 1527 [TLV-ENC-802.15.4] 1528 "CCN and NDN TLV encodings in 802.15.4 packets", 1529 . 1532 [WIRE-FORMAT-CONSID] 1533 "CCN/NDN Protocol Wire Format and Functionality 1534 Considerations", . 1538 Appendix A. Estimated Size Reduction 1540 In the following a theoretical evaluation is given to estimate the 1541 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1543 We assume that "n" is the number of name components, "comps_n" 1544 denotes the sum of n name component lengths. We also assume that the 1545 length of each name component is lower than 16 bytes. The length of 1546 the content is given by "clen". The lengths of TLV components is 1547 specific to the CCNx or NDN encoding and outlined below. 1549 A.1. NDN 1551 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1552 the 1 octet form of each TLV component is assumed. A typical TLV 1553 component therefore is of size 2 (type field + length field) + the 1554 actual value. 1556 A.1.1. Interest 1558 Figure 30 depicts the size requirements for a basic, uncompressed NDN 1559 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1560 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1561 Numbers below represent the amount of octets. 1563 ------------------------------------, 1564 Interest TLV = 2 | 1565 ---------------------, | 1566 Name | 2 + | 1567 NameComponents = 2n + | 1568 | comps_n | 1569 ---------------------' = 21 + 2n + comps_n 1570 CanBePrefix = 2 | 1571 MustBeFresh = 2 | 1572 Nonce = 6 | 1573 InterestLifetime = 4 | 1574 HopLimit = 3 | 1575 ------------------------------------' 1577 Figure 30: Estimated size of an uncompressed NDN Interest 1579 Figure 31 depicts the size requirements after compression. 1581 ------------------------------------, 1582 Dispatch Page Switch = 1 | 1583 NDN Interset Dispatch = 1 | 1584 Interest TLV = 1 | 1585 -----------------------, | 1586 Name | = 9 + n/2 + comps_n 1587 NameComponents = n/2 + | 1588 | comps_n | 1589 -----------------------' | 1590 Nonce = 4 | 1591 HopLimit = 1 | 1592 InterestLifetime = 1 | 1593 ------------------------------------' 1595 Figure 31: Estimated size of a compressed NDN Interest 1597 The size difference is: 1598 12 + 1.5n octets. 1600 For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets, 1601 which is 46% of the uncompressed packet. 1603 A.1.2. Data 1605 Figure 32 depicts the size requirements for a basic, uncompressed NDN 1606 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1607 1 minute is assumed and the value is encoded using 1 octet. An 1608 HMACWithSha256 is assumed as signature. The key locator is assumed 1609 to contain a Name TLV of length klen. 1611 ------------------------------------, 1612 Data TLV = 2 | 1613 ---------------------, | 1614 Name | 2 + | 1615 NameComponents = 2n + | 1616 | comps_n | 1617 ---------------------' | 1618 ---------------------, | 1619 MetaInfo | | 1620 FreshnessPeriod = 6 = 53 + 2n + comps_n + 1621 | | clen + klen 1622 ---------------------' | 1623 Content = 2 + clen | 1624 ---------------------, | 1625 SignatureInfo | | 1626 SignatureType | | 1627 KeyLocator = 41 + klen | 1628 SignatureValue | | 1629 DigestSha256 | | 1630 ---------------------' | 1631 ------------------------------------' 1633 Figure 32: Estimated size of an uncompressed NDN Data 1635 Figure 33 depicts the size requirements for the compressed version of 1636 the above Data packet. 1638 ------------------------------------, 1639 Dispatch Page Switch = 1 | 1640 NDN Data Dispatch = 1 | 1641 -----------------------, | 1642 Name | = 37 + n/2 + comps_n + 1643 NameComponents = n/2 + | clen + klen 1644 | comps_n | 1645 -----------------------' | 1646 Content = 1 + clen | 1647 KeyLocator = 1 + klen | 1648 DigestSha256 = 32 | 1649 FreshnessPeriod = 1 | 1650 ------------------------------------' 1652 Figure 33: Estimated size of a compressed NDN Data 1654 The size difference is: 1655 16 + 1.5n octets. 1657 For the name "/DE/HH/HAW/BT7", the total size gain is 22 octets. 1659 A.2. CCNx 1661 The CCNx TLV encoding defines a 2-octet encoding for type and length 1662 fields, summing up to 4 octets in total without a value. 1664 A.2.1. Interest 1666 Figure 34 depicts the size requirements for a basic, uncompressed 1667 CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version 1668 is assumed to be 1 and the reserved field is assumed to be 0. A 1669 KeyIdRestriction TLV with T_SHA-256 is included to limit the 1670 responses to Content Objects containing the specific key. 1672 ------------------------------------, 1673 Fixed Header = 8 | 1674 Message = 4 | 1675 ---------------------, | 1676 Name | 4 + = 56 + 4n + comps_n 1677 NameSegments = 4n + | 1678 | comps_n | 1679 ---------------------' | 1680 KeyIdRestriction = 40 | 1681 ------------------------------------' 1683 Figure 34: Estimated size of an uncompressed CCNx Interest 1685 Figure 35 depicts the size requirements after compression. 1687 ------------------------------------, 1688 Dispatch Page Switch = 1 | 1689 CCNx Interest Dispatch = 2 | 1690 Fixed Header = 3 | 1691 -----------------------, | 1692 Name | = 38 + n/2 + comps_n 1693 NameSegments = n/2 + | 1694 | comps_n | 1695 -----------------------' | 1696 T_SHA-256 = 32 | 1697 ------------------------------------' 1699 Figure 35: Estimated size of a compressed CCNx Interest 1701 The size difference is: 1702 18 + 3.5n octets. 1704 For the name "/DE/HH/HAW/BT7", the size is reduced by 53 octets, 1705 which is 53% of the uncompressed packet. 1707 A.2.2. Content Object 1709 Figure 36 depicts the size requirements for a basic, uncompressed 1710 CCNx Content Object containing an ExpiryTime Message TLV, an 1711 HMAC_SHA-256 signature, the signature time and a hash of the shared 1712 secret key. In the fixed header, the protocol version is assumed to 1713 be 1 and the reserved field is assumed to be 0 1715 ------------------------------------, 1716 Fixed Header = 8 | 1717 Message = 4 | 1718 ---------------------, | 1719 Name | 4 + | 1720 NameSegments = 4n + | 1721 | comps_n | 1722 ---------------------' | 1723 ExpiryTime = 12 = 124 + 4n + comps_n + clen 1724 Payload = 4 + clen | 1725 ---------------------, | 1726 ValidationAlgorithm | | 1727 T_HMAC-256 = 56 | 1728 KeyId | | 1729 SignatureTime | | 1730 ---------------------' | 1731 ValidationPayload = 36 | 1732 ------------------------------------' 1734 Figure 36: Estimated size of an uncompressed CCNx Content Object 1736 Figure 37 depicts the size requirements for a basic, compressed CCNx 1737 Data. 1739 ------------------------------------, 1740 Dispatch Page Switch = 1 | 1741 CCNx Content Dispatch = 3 | 1742 Fixed Header = 2 | 1743 -----------------------, | 1744 Name | | 1745 NameSegments = n/2 + | 1746 | comps_n = 89 + n/2 + comps_n + clen 1747 -----------------------' | 1748 ExpiryTime = 8 | 1749 Payload = 1 + clen | 1750 T_HMAC-SHA256 = 32 | 1751 SignatureTime = 8 | 1752 ValidationPayload = 34 | 1753 ------------------------------------' 1755 Figure 37: Estimated size of a compressed CCNx Data Object 1757 The size difference is: 1758 35 + 3.5n octets. 1760 For the name "/DE/HH/HAW/BT7", the size is reduced by 70 octets, 1761 which is 40% of the uncompressed packet containing a 4-octet payload. 1763 Acknowledgments 1765 This work was stimulated by fruitful discussions in the ICNRG 1766 research group and the communities of RIOT and CCNlite. We would 1767 like to thank all active members for constructive thoughts and 1768 feedback. In particular, the authors would like to thank (in 1769 alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders. 1770 The hop-wise stateful name compression was brought up in a discussion 1771 by Dave Oran, which is gratefully acknowledged. Larger parts of this 1772 work are inspired by [RFC4944] and [RFC6282]. Special mentioning 1773 goes to Mark Mosko as well as G.Q. Wang and Ravi Ravindran as their 1774 previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided 1775 a good base for our discussions on stateless header compression 1776 mechanisms. This work was supported in part by the German Federal 1777 Ministry of Research and Education within the projects I3 and 1778 RAPstore. 1780 Authors' Addresses 1781 Cenk Gundogan 1782 HAW Hamburg 1783 Berliner Tor 7 1784 Hamburg D-20099 1785 Germany 1787 Phone: +4940428758067 1788 EMail: cenk.guendogan@haw-hamburg.de 1789 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 1791 Thomas C. Schmidt 1792 HAW Hamburg 1793 Berliner Tor 7 1794 Hamburg D-20099 1795 Germany 1797 EMail: t.schmidt@haw-hamburg.de 1798 URI: http://inet.haw-hamburg.de/members/schmidt 1800 Matthias Waehlisch 1801 link-lab & FU Berlin 1802 Hoenower Str. 35 1803 Berlin D-10318 1804 Germany 1806 EMail: mw@link-lab.net 1807 URI: http://www.inf.fu-berlin.de/~waehl 1809 Christopher Scherb 1810 University of Basel 1811 Spiegelgasse 1 1812 Basel CH-4051 1813 Switzerland 1815 EMail: christopher.scherb@unibas.ch 1817 Claudio Marxer 1818 University of Basel 1819 Spiegelgasse 1 1820 Basel CH-4051 1821 Switzerland 1823 EMail: claudio.marxer@unibas.ch 1824 Christian Tschudin 1825 University of Basel 1826 Spiegelgasse 1 1827 Basel CH-4051 1828 Switzerland 1830 EMail: christian.tschudin@unibas.ch