idnits 2.17.1 draft-irtf-icnrg-icnlowpan-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (November 27, 2018) is 1976 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 1389, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-08 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-09 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group C. Gundogan 3 Internet-Draft TC. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: May 31, 2019 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 November 27, 2018 13 ICN Adaptation to LowPAN Networks (ICN LoWPAN) 14 draft-irtf-icnrg-icnlowpan-01 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 May 31, 2019. 50 Copyright Notice 52 Copyright (c) 2018 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 . . . . . . . . . . . . . . 5 69 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 17 81 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 17 82 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 23 83 7. Stateful Header Compression . . . . . . . . . . . . . . . . . 26 84 7.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 26 85 7.2. En-route State . . . . . . . . . . . . . . . . . . . . . 27 86 7.3. Integrating Stateful Header Compression . . . . . . . . . 29 87 8. Implementations . . . . . . . . . . . . . . . . . . . . . . . 29 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 90 10.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . 30 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 93 11.2. Informative References . . . . . . . . . . . . . . . . . 30 94 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 33 95 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 33 97 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 34 98 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 36 100 A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 37 101 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 104 1. Introduction 106 The Internet of Things (IoT) has been identified as a promising 107 deployment area for Information Centric Networks (ICN), as 108 infrastructureless access to content, resilient forwarding, and in- 109 network data replication demonstrated noteable advantages over the 110 traditional host-to-host approach on the Internet [NDN-EXP1], 111 [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate 112 mapping to link layer technologies has a large impact on the 113 practical performance of an ICN. This will be even more relevant in 114 the context of IoT communication where nodes often exchange messages 115 via low-power wireless links under lossy conditions. In this memo, 116 we address the base adaptation of data chunks to such link layers for 117 the ICN flavors NDN [NDN] and CCNx. 119 The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and 120 lossy networks (see "LLN" in [RFC7228]), in which devices are 121 typically battery-operated and constrained in resources. 122 Characteristics of LLNs include an unreliable environment, low 123 bandwidth transmissions, and increased latencies. IEEE 802.15.4 124 admits a maximum physical layer packet size of 127 octets. The 125 maximum frame header size is 25 octets, which leaves 102 octets for 126 the payload. IEEE 802.15.4 security features further reduce this 127 payload length by up to 21 octets, yielding a net of 81 octets for 128 CCNx or NDN packet headers, signatures and content. 130 6LoWPAN [RFC4944], [RFC6282] is a convergence layer that provides 131 frame formats, header compression and link fragmentation for IPv6 132 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces 133 a dispatching framework that prepends further information to 6LoWPAN 134 packets, including a protocol identifier for IEEE 802.15.4 payload 135 and meta information about link fragmentation. 137 Prevalent Type-Length-Value (TLV) based packet formats such as in 138 CCNx and NDN are designed to be generic and extensible. This leads 139 to header verbosity which is inappropriate in constrained 140 environments of IEEE 802.15.4 links. This document presents ICN 141 LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN 142 that compresses packet headers of CCNx as well as NDN and allows for 143 an increased payload size per packet. Additionally, reusing the 144 dispatching framework defined by 6LoWPAN enables compatibility 145 between coexisting wireless networks of competing technologies. This 146 also allows to reuse the link fragmentation scheme specified by 147 6LoWPAN for ICN LoWPAN. 149 ICN LoWPAN defines a more space efficient representation of CCNx and 150 NDN packet formats. This syntactic change is described for CCNx and 151 NDN separately, as the header formats and TLV encodings differ 152 largely. For further reductions, default header values suitable for 153 constrained IoT networks are selected in order to elide corresponding 154 TLVs. 156 In a typical IoT scenario (see Figure 1), embedded devices are 157 interconnected via a quasi-stationary infrastructure using a border 158 router (BR) that uplinks the constrained LoWPAN network by some 159 Gateway with the public Internet. In ICN based IoT networks, non- 160 local Interest and Data messages transparently travel through the BR 161 up and down between a Gateway and the embedded devices situated in 162 the constrained LoWPAN. 164 |Gateway Services| 165 ------------------------- 166 | 167 ,--------, 168 | | 169 | BR | 170 | | 171 '--------' 172 LoWPAN 173 O O 174 O 175 O O embedded 176 O O O devices 177 O O 179 Figure 1: IoT Stub Network 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 The use of the term, "silently ignore" is not defined in RFC 2119. 187 However, the term is used in this document and can be similarly 188 construed. 190 This document uses the terminology of [RFC7476], [RFC7927], and 191 [RFC7945] for ICN entities. 193 The following terms are used in the document and defined as follows: 195 ICN LoWPAN: Information-Centric Networking over Low-power Wireless 196 Personal Area Network 198 LLN Low-Power and Lossy Network 200 CCNx: Content-Centric Networking Architecture 202 NDN: Named Data Networking Architecture 204 3. Overview of ICN LoWPAN 206 3.1. Link-Layer Convergence 208 ICN LoWPAN provides a convergence layer that maps ICN packets onto 209 constrained link-layer technologies. This includes features such as 210 link-layer fragmentation, protocol separation on the link-layer 211 level, and link-layer address mappings. The stack traversal is 212 visualized in Figure 2. 214 Device 1 Device 2 215 ,------------------, Router ,------------------, 216 | Application . | __________________ | ,-> Application | 217 |----------------|-| | NDN / CCNx | |-|----------------| 218 | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | 219 |----------------|-| |-|--------------|-| |-|----------------| 220 | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | 221 |----------------|-| |-|--------------|-| |-|----------------| 222 | Link-Layer | | | | Link-Layer | | | | Link-Layer | 223 '----------------|-' '-|--------------|-' '-|----------------' 224 '--------' '---------' 226 Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 228 Section 4 of this document defines the convergence layer for IEEE 229 802.15.4. 231 3.2. Stateless Header Compression 233 ICN LoWPAN also defines a stateless header compression scheme with 234 the main purpose of reducing header overhead of ICN packets. This is 235 of particular importance for link-layers with small MTUs. The 236 stateless compression does not require pre-configuration of global 237 state. 239 The CCNx and NDN header formats are composed of Type-Length-Value 240 (TLV) fields to encode header data. The advantage of TLVs is its 241 native support of variable-sized data. The main disadvantage of TLVs 242 is the verbosity that results from storing the type and length of the 243 encoded data. 245 The stateless header compression scheme makes use of compact bit 246 fields to indicate the presence of mandatory and optional TLVs in the 247 uncompressed packet. The order of set bits in the bit fields 248 corresponds to the order of each TLV in the packet. Further 249 compression is achieved by specifying default values and reducing the 250 codomain of certain header fields. 252 Figure 3 demonstrates the stateless header compression idea. In this 253 example, the first type of the first TLV is removed and the 254 corresponding bit in the bit field is set. The second TLV represents 255 a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type and 256 the length fields are removed. The third TLV represents a boolean 257 TLV (e.g., the MustBeFresh selector in NDN) and is missing the type, 258 length and the value field. 260 +---+---+---+---+---+---+---+---+ 261 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field 262 +---+---+---+---+---+---+---+---+ 263 | | | 264 ,--' '-----------, '- boolean 265 | | 266 +-------+--------------+-------------+ 267 | LEN | VALUE | VALUE | 268 +-------+--------------+-------------+ 270 Figure 3: Compression using a compact bit field to encode context 271 information. 273 Stateless TLV compression for NDN is defined in Section 5. Section 6 274 defines the stateless TLV compression for CCNx. 276 3.3. Stateful Header Compression 278 ICN LoWPAN further employs two orthogonal stateful compression 279 schemes for packet size reductions which are defined in Section 7. 280 These mechanisms rely on shared contexts that are either distributed 281 and maintained in the entire LoWPAN, or are generated on-demand hop- 282 wise on a particular Interest-data path. 284 The shared context identification is defined in Section 7.1. The 285 hop-wise name compression "en-route" is specified in Section 7.2. 287 4. IEEE 802.15.4 Adaptation 289 4.1. LoWPAN Encapsulation 291 The IEEE 802.15.4 frame header does not provide a protocol identifier 292 for its payload. This causes problems of misinterpreting frames when 293 several network layers coexist on the same link. To mitigate errors, 294 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 295 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation 296 headers can prepend the actual payload and each encapsulation header 297 is identified by a dispatch type. 299 [RFC8025] further specifies dispatch pages to switch between 300 different contexts. When a LoWPAN parser encounters a "Page switch" 301 LoWPAN encapsulation header, then all following encapsulation headers 302 are interpreted by using a dispatch table as specified by the "Page 303 switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This 304 document uses page 2 ("1111 0010 (0xF2)") for NDN and page 3 ("1111 305 0011 (0xF3)") for CCNx. 307 The base dispatch format (Figure 4) is used and extended by CCNx and 308 NDN in Section 5 and Section 6. 310 0 1 2 ... 311 +---+---+-------- 312 | C | M | 313 +---+---+-------- 315 Figure 4: Base dispatch format for ICN LoWPAN 317 C: Compression 319 0: The message is uncompressed. 321 1: The message is compressed. 323 M: Message Type 325 0: The payload contains an Interest message. 327 1: The payload contains a Data message. 329 ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the 330 extended dispatch format in Figure 5. 332 0 1 2 ... 333 +---+---+-------- 334 | 1 | M |CID| 335 +---+---+-------- 337 Figure 5: Extended dispatch format for compressed ICN LoWPAN 339 CID: Context Identifier 341 0: No context identifiers are present. 343 1: 1..n context identifiers are present. 345 The encapsulation format for ICN LoWPAN is displayed in Figure 6. 347 +------...------+------...-----+--------+-------...-------+-----... 348 | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / 349 +------...------+------...-----+--------+-------...-------+-----... 351 Figure 6: LoWPAN Encapsulation with ICN-LoWPAN 353 IEEE 802.15.4: The IEEE 802.15.4 header. 355 RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 356 of [RFC4944] 358 Page: Page Switch. 2 for NDN and 3 for CCNx. 360 ICN LoWPAN: Dispatches defined in Section 5 and Section 6. 362 Payload: The actual (un-)compressed CCNx or NDN message. 364 4.2. Link Fragmentation 366 Small payload sizes in the LoWPAN require fragmentation for various 367 network layers. Therefore, Section 5.3 of [RFC4944] defines a 368 protocol-independent fragmentation dispatch type, a fragmentation 369 header for the first fragment, and a separate fragmentation header 370 for subsequent fragments. ICN LoWPAN adopts this fragmentation 371 handling of [RFC4944]. 373 The Fragmentation LoWPAN header can encapsulate other dispatch 374 headers. The order of dispatch types is defined in Section 5 of 375 [RFC4944]. Figure 7 shows the fragmentation scheme. The reassembled 376 ICN LoWPAN frame does not contain any fragmentation headers and is 377 depicted in Figure 8. 379 +------...------+----...----+--------+------...-------+--------... 380 | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / 381 +------...------+----...----+--------+------...-------+--------... 383 +------...------+----...----+--------... 384 | IEEE 802.15.4 | Frag. 2nd | Payload / 385 +------...------+----...----+--------... 387 . 388 . 389 . 391 +------...------+----...----+--------... 392 | IEEE 802.15.4 | Frag. Nth | Payload / 393 +------...------+----...----+--------... 395 Figure 7: Fragmentation scheme 397 +------...------+--------+------...-------+--------... 398 | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / 399 +------...------+--------+------...-------+--------... 401 Figure 8: Reassembled ICN LoWPAN frame 403 5. Space-efficient Message Encoding for NDN 405 5.1. TLV Encoding 407 The NDN packet format consists of TLV fields using the TLV encoding 408 that is described in [NDN-PACKET-SPEC]. Type and length fields are 409 of variable size, where numbers greater than 252 are encoded using 410 multiple octets. 412 If the type or length number is less than "253", then that number is 413 encoded into the actual type or length field. If the number is 414 greater or equals "253" and fits into 2 octets, then the type or 415 lengh field is set to "253" and the number is encoded in the next 416 following 2 octets in network byte order, i.e., from the most 417 significant byte (MSB) to the least significant byte (LSB). If the 418 number is greater than 2 octets and fits into 4 octets, then the type 419 or length field is set to "254" and the number is encoded in the 420 subsequent 4 octets in network byte order. For larger numbers, the 421 type or length field is set to "255" and the number is encoded in the 422 subsequent 8 octets in network byte order. 424 In this specification, compressed NDN TLVs make use of a different 425 TLV encoding scheme that reduces size. Instead of using the first 426 octet as a marker for the number of following octets, the compressed 427 NDN TLV scheme uses a method to chain a variable number of octets 428 together. If an octet equals "255 (0xFF)", then the following octet 429 will also be interpreted. The actual value of a chain equals the sum 430 of all links. 432 If the type or length number is less than "255", then that number is 433 encoded into the actual type or length field (Figure 9 a). If the 434 type or length number (X) fits into 2 octets, then the first octet is 435 set to "255" and the subsequent octet equals "X mod 255" (Figure 9 436 b). Following this scheme, a variable-sized number (X) is encoded 437 using multiple octets of "255" with a trailing octet containing "X 438 mod 255" (Figure 9 c). 440 0 1 2 3 4 5 6 7 441 +-+-+-+-+-+-+-+-+ 442 a) | < 255 (X) | = X 443 +-+-+-+-+-+-+-+-+ 445 0 1 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 b) | 255 | < 255 (X) | = 255 + X 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 0 452 0 1 2 3 4 5 6 7 453 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 454 c) | 255 | 255 | < 255 (X) | = (N * 255) + X 455 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 456 (N - 1) 458 Figure 9: Compressed NDN TLV encoding scheme 460 5.2. Name TLV Compression 462 This Name TLV compression encodes length fields of two consecutive 463 NameComponent TLVs into one octet, using 4 bits each. This process 464 limits the length of a NameComponent TLV to 15 octets. A length of 0 465 marks the end of the compressed Name TLV. 467 Name: /HAW/Room/481/Humid/99 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |0 0 1 1|0 1 0 0| H | A | W | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | R | o | o | m | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | H | u | m | i | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | d |0 0 1 0|0 0 0 0| 9 | 9 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 10: Name TLV compression for /HAW/Room/481/Humid/99 485 5.3. Interest Messages 487 5.3.1. Uncompressed Interest Messages 489 An uncompressed Interest message uses the base dispatch format (see 490 Figure 4) and sets the C as well as the M flag to "0" (Figure 11). 491 "resv" MUST be set to 0. The Interest message is handed to the NDN 492 network stack without modifications. 494 0 1 ... 7 495 +---+---+-----------------------+ 496 | 0 | 0 | resv | 497 +---+---+-----------------------+ 499 Figure 11: Dispatch format for uncompressed NDN Interest messages 501 5.3.2. Compressed Interest Messages 503 The compressed Interest message uses the extended dispatch format 504 (Figure 5) and sets the C flag to "1" and the M flag to "0". In the 505 default use case, the Interest message is compressed with the 506 following minimal rule set: 508 1. The "Type" field of the outermost MessageType TLV is removed. 510 2. The Name TLV is compressed according to Section 5.2. For this, 511 all NameComponents are expected to be of type 512 GenericNameComponent. Otherwise, the message MUST be sent 513 uncompressed. 515 3. The InterestLifetime TLV length is set to 2. Messages with 516 lifetimes that require more than 2 octets MUST be sent 517 uncompressed. 519 4. The Nonce TLV, InterestLifetime TLV and HopLimit TLV MUST be 520 moved to the end of the compressed Interest, keeping the order 1) 521 Nonce TLV, 2) InterestLifetime TLV and 3) HopLimit TLV. 523 5. The Type and Length fields of Nonce TLV, InterestLifetime TLV and 524 HopLimit TLV are elided. The presence of each TLV is deduced 525 from the remaining length to parse. The Nonce TLV has a fixed 526 length of 4, the InterestLifetime TLV has a fixed length of 2 and 527 the HopLimit TLV has a fixed length of 1. Any combination yields 528 a distinct value that matches the remaining length to parse. 530 The compressed NDN LoWPAN Interest message is visualized in 531 Figure 12. 533 T = Type, L = Length, V = Value 535 +--------+--------+ +--------+ 536 | Msg T | Msg L | | Msg L | 537 +--------+--------+--------+ +--------+ 538 | Name T | Name L | Name V | | Name V | 539 +--------+--------+--------+ +--------+--------+ 540 | CBPfx T| CBPfx L| | FWDH L | FWDH V | 541 +--------+--------+ +--------+--------+ 542 | MBFr T | MBFr L | | PRM L | PRM V | 543 +--------+--------+--------+ ==> +--------+--------+ 544 | FWDH T | FWDH L | FWDH V | | NONC V | 545 +--------+--------+--------+ +--------+ 546 | NONC T | NONC L | NONC V | | ILT V | 547 +--------+--------+--------+ +--------+ 548 | ILT T | ILT L | ILT V | | HPL V | 549 +--------+--------+--------+ +--------+ 550 | HPL T | HPL L | HPL V | 551 +--------+--------+--------+ 552 | PRM T | PRM L | PRM V | 553 +--------+--------+--------+ 555 Figure 12: Compressed NDN LoWPAN Interest Message 557 Further TLV compression is indicated by the ICN LoWPAN dispatch in 558 Figure 13. 560 0 1 2 3 4 5 6 7 561 +---+---+---+---+---+---+---+---+ 562 | 1 | 0 |CID|DIG|PFX|FRE|FWD|PRM| 563 +---+---+---+---+---+---+---+---+ 565 Figure 13: Dispatch format for compressed NDN Interest messages 567 CID: Context Identifier See Figure 5. 569 DIG: ImplicitSha256DigestComponent TLV 571 0: The name does not include an 572 ImplicitSha256DigestComponent as the last TLV. 574 1: The name does include an 575 ImplicitSha256DigestComponent as the last TLV. The 576 Type and Length fields are omitted. 578 PFX: CanBePrefix TLV 580 0: The uncompressed message does not include a 581 CanBePrefix TLV. 583 1: The uncompressed message does include a CanBePrefix 584 TLV and is removed from the compressed message. 586 FRE: MustBeFresh TLV 588 0: The uncompressed message does not include a 589 MustBeFresh TLV. 591 1: The uncompressed message does include a MustBeFresh 592 TLV and is removed from the compressed message. 594 FWD: ForwardingHint TLV 596 0: The uncompressed message does not include a 597 ForwardingHint TLV. 599 1: The uncompressed message does include a 600 ForwardingHint TLV. The Type field is removed from 601 the compressed message. 603 PRM: Parameters TLV 605 0: The uncompressed message does not include a 606 Parameters TLV. 608 1: The uncompressed message does include a Parameters 609 TLV. The Type field is removed from the compressed 610 message. 612 5.4. Data Messages 614 5.4.1. Uncompressed Data Messages 616 An uncompressed Data message uses the base dispatch format and sets 617 the C flag to "0" and the M flag to "1" (Figure 14). "resv" MUST be 618 set to 0. The Data message is handed to the NDN network stack 619 without modifications. 621 0 1 ... 7 622 +---+---+-----------------------+ 623 | 0 | 1 | resv | 624 +---+---+-----------------------+ 626 Figure 14: Dispatch format for uncompressed NDN Data messages 628 5.4.2. Compressed Data Messages 630 The compressed Data message uses the extended dispatch format 631 (Figure 5) and sets the C flag as well as the M flag to "1". By 632 default, the Data message is compressed with the following base rule 633 set: 635 1. The "Type" field of the outermost MessageType TLV is removed. 637 2. The Name TLV is compressed according to Section 5.2. For this, 638 all NameComponents are expected to be of type 639 GenericNameComponent. Otherwise, the message MUST be sent 640 uncompressed. 642 3. The MetaInfo Type and Length fields are elided from the 643 compressed Data message. 645 4. If present, the FinalBlockId TLV is encoded according to 646 Section 5.2. 648 5. The ContentType TLV length is set to 1. Messages with 649 ContentTypes that require more than 1 octet MUST be sent 650 uncompressed. 652 6. The FreshnessPeriod TLV length is set to 2. Messages with 653 FreshnessPeriods that require more than 2 octets MUST be sent 654 uncompressed. 656 7. The FreshnessPeriod TLV and ContntType TLV MUST be moved to the 657 end of the compressed Data, keeping the order 1) FreshnessPeriod 658 TLV and 2) ContentType TLV. 660 8. The Type and Length fields of ContentType TLV and FreshnessPeriod 661 TLV are elided. The presence of each TLV is deduced from the 662 remaining length to parse. The FreshnessPeriod TLV has a fixed 663 length of 2 and the ContentType TLV has a fixed length of 1. Any 664 combination yields a distinct value that matches the remaining 665 length to parse. 667 The compressed NDN LoWPAN Data message is visualized in Figure 15. 669 T = Type, L = Length, V = Value 671 +--------+--------+ +--------+ 672 | Msg T | Msg L | | Msg L | 673 +--------+--------+--------+ +--------+ 674 | Name T | Name L | Name V | | Name V | 675 +--------+--------+--------+ +--------+--------+ 676 | Meta T | Meta L | | FWDH L | FWDH V | 677 +--------+--------+--------+ +--------+--------+ 678 | CTyp T | CTyp L | CTyp V | | FBID V | 679 +--------+--------+--------+ ==> +--------+ 680 | FrPr T | FrPr L | FrPr V | | Sig L | 681 +--------+--------+--------+ +--------+--------+ 682 | FBID T | FBID L | FBID V | | SInf L | SInf V | 683 +--------+--------+--------+ +--------+--------+ 684 | Sig T | Sig L | | SVal L | SVal V | 685 +--------+--------+--------+ +--------+--------+ 686 | SInf T | SInf L | SInf V | | FrPr V | 687 +--------+--------+--------+ +--------+ 688 | SVal T | SVal L | SVal V | | CTyp V | 689 +--------+--------+--------+ +--------+ 691 Figure 15: Compressed NDN LoWPAN Data Message 693 Further TLV compression is indicated by the ICN LoWPAN dispatch in 694 Figure 16. 696 0 1 2 3 4 5 6 7 697 +---+---+---+---+---+---+---+---+ 698 | 1 | 1 |CID|DIG|FBI|CON| SIG | 699 +---+---+---+---+---+---+---+---+ 701 Figure 16: Dispatch format for compressed NDN Data messages 703 CID: Context Identifier See Figure 5. 705 DIG: ImplicitSha256DigestComponent TLV 707 0: The name does not include an 708 ImplicitSha256DigestComponent as the last TLV. 710 1: The name does include an 711 ImplicitSha256DigestComponent as the last TLV. The 712 Type and Length fields are omitted. 714 FBI: FinalBlockId TLV 716 0: The uncompressed message does not include a 717 FinalBlockId TLV. 719 1: The uncompressed message does include a FinalBlockId. 721 CON: Content TLV 723 0: The uncompressed message does not include a Content 724 TLV. 726 1: The uncompressed message does include a Content TLV. 727 The Type field is removed from the compressed 728 message. 730 SIG: Signature TLV 732 00: The Type fields of the SignatureInfo TLV, 733 SignatureType TLV and SignatureValue TLV are removed. 735 01: Reserved. 737 10: Reserved. 739 11: Reserved. 741 6. Space-efficient Message Encoding for CCNx 743 6.1. TLV Encoding 745 The generic CCNx TLV encoding is described in 746 [I-D.irtf-icnrg-ccnxmessages]. Type and Length fields attain the 747 common fixed length of 2 octets. 749 The TLV encoding for CCNx LoWPAN is changed to the more space 750 efficient encoding described in Section 5.1. Hence NDN and CCNx use 751 the same compressed format for writing TLVs. 753 6.2. Name TLV Compression 755 Name TLVs are compressed using the scheme already defined in 756 Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or 757 organizational TLVs, then the name remains uncompressed. 759 6.3. Interest Messages 761 6.3.1. Uncompressed Interest Messages 763 An uncompressed Interest message uses the base dispatch format (see 764 Figure 4) and sets the C as well as the M flag to "0" (Figure 17). 765 "resv" MUST be set to 0. The Interest message is handed to the CCNx 766 network stack without modifications. 768 0 1 ... 7 769 +---+---+-----------------------+ 770 | 0 | 0 | resv | 771 +---+---+-----------------------+ 773 Figure 17: Dispatch format for uncompressed CCNx Interest messages 775 6.3.2. Compressed Interest Messages 777 The compressed Interest message uses the extended dispatch format 778 (Figure 5) and sets the C flag to "1" and the M flag to "0". In the 779 default use case, the Interest message is compressed with the 780 following minimal rule set: 782 1. The Type and Length fields of the CCNx Message TLV are elided and 783 are obtained from the Fixed Header on decompression. 785 The compressed CCNx LoWPAN Interest message is visualized in 786 Figure 18. 788 T = Type, L = Length, V = Value 790 +--------------------------+ +--------------------------+ 791 | Uncompr. Fixed Header | | Compr. Fixed Header | 792 +--------------------------+ +--------------------------+ 793 +--------+--------+--------+ +--------+ 794 | ILT T | ILT L | ILT V | | ILT V | 795 +--------+--------+--------+ +--------+ 796 | MSGH T | MSGH L | MSGH V | | MSGH V | 797 +--------+--------+--------+ +--------+ 798 +--------+--------+ +--------+ 799 | MSGT T | MSGT L | | Name V | 800 +--------+--------+--------+ +--------+ 801 | Name T | Name L | Name V | ==> | KIDR V | 802 +--------+--------+--------+ +--------+ 803 | KIDR T | KIDR L | KIDR V | | OBHR V | 804 +--------+--------+--------+ +--------+--------+ 805 | OBHR T | OBHR L | OBHR V | | PAYL L | PAYL V | 806 +--------+--------+--------+ +--------+--------+ 807 | PAYL T | PAYL L | PAYL V | | VALG L | VALG V | 808 +--------+--------+--------+ +--------+--------+ 809 | VALG T | VALG L | VALG V | | VPAY L | VPAY V | 810 +--------+--------+--------+ +--------+--------+ 811 | VPAY T | VPAY L | VPAY V | 812 +--------+--------+--------+ 814 Figure 18: Compressed CCNx LoWPAN Interest Message 816 Further TLV compression is indicated by the ICN LoWPAN dispatch in 817 Figure 19. 819 0 1 820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 821 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 822 | 1 | 0 |CID|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|EXT|RSV| 823 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 825 Figure 19: Dispatch format for compressed CCNx Interest messages 827 CID: Context Identifier See Figure 5. 829 VER: CCNx protocol version in the fixed header 831 0: The Version field equals 1 and is removed from the fixed 832 header. 834 1: The Version field is carried in-line. 836 FLG: Flags field in the fixed header 838 0: The Flags field equals 0 and is removed from the Interest 839 message. 841 1: The Flags field is carried in-line. 843 PTY: PacketType field in the fixed header 845 0: The PacketType field is elided and assumed to be 846 "PT_INTEREST" 848 1: The PacketType field is elided and assumed to be 849 "PT_RETURN" 851 HPL: HopLimit field in the fixed header 853 0: The HopLimit field is carried in-line 855 1: The HopLimit field is elided and assumed to be "1" 857 FRS: Reserved field in the fixed header 859 0: The Reserved field is carried in-line 861 1: The Reserved field is elided and assumed to be "0" 863 PAY: Optional Payload TLV 865 0: The Payload TLV is absent. 867 1: The Payload TLV is present and the type field is elided. 869 ILT: Optional Hop-By-Hop InterestLifetime TLV 871 See Section 6.3.2.1 for further details on the ordering 872 of hop-by-hop TLVs. 874 0: No InterestLifetime TLV is present in the Interest 875 message. 877 1: An InterestLifetime TLV is present with a fixed length of 878 2 octets. The type and length fields are elided. 880 MGH: Optional Hop-By-Hop MessageHash TLV 882 See Section 6.3.2.1 for further details on the ordering 883 of hop-by-hop TLVs. 885 This TLV is expected to contain a T_SHA-256 TLV. If 886 another hash is contained, then the Interest MUST be sent 887 uncompressed. 889 0: The MessageHash TLV is absent. 891 1: A T_SHA-256 TLV is present and the type as well as the 892 length fields are removed. The length field is assumed 893 to represent 32 octets. The outer Message Hash TLV is 894 omitted. 896 KIR: Optional KeyIdRestriction TLV 898 This TLV is expected to contain a T_SHA-256 TLV. If 899 another hash is contained, then the Interest MUST be sent 900 uncompressed. 902 0: The KeyIDRestriction TLV is absent. 904 1: A T_SHA-256 TLV is present and the type as well as the 905 length fields are removed. The length field is assumed 906 to represent 32 octets. The outer KeyIdRestriction TLV 907 is omitted. 909 CHR: Optional ContentObjectHashRestriction TLV 911 This TLV is expected to contain a T_SHA-256 TLV. If 912 another hash is contained, then the Interest MUST be sent 913 uncompressed. 915 0: The ContentObjectHashRestriction TLV is absent. 917 1: A T_SHA-256 TLV is present and the type as well as the 918 length fields are removed. The length field is assumed 919 to represent 32 octets. The outer 920 ContentObjectHashRestriction TLV is omitted. 922 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 924 0: No validation related TLVs are present in the Interest 925 message. 927 1: Validation related TLVs are present in the Interest 928 message. An additional octet follows immediately that 929 handles validation related TLV compressions and is 930 described in Section 6.3.2.2. 932 EXT: Extension 933 0: No extension octet follows. 935 1: An extension octet follows immediately. Extension octets 936 are used to extend the compression scheme, but are out of 937 scope of this document. 939 RSV: Reserved Must be set to 0. 941 6.3.2.1. Hop-By-Hop Header TLVs Compression 943 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 944 optional Hop-By-Hop Header TLVs are defined in 945 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 946 higher level specifications. For a compressed representation, this 947 document defines the following ordering of Hop-By-Hop TLVs: 949 1. Interest Lifetime TLV 951 2. Message Hash TLV 953 Note: If the original Interest message includes Hop-By-Hop Header 954 TLVs that follow a different ordering, then the message MUST be sent 955 uncompressed. 957 6.3.2.2. Validation 959 0 1 2 3 4 5 6 7 8 960 +-------+-------+-------+-------+-------+-------+-------+-------+ 961 | ValidationAlg | KeyID | Reserved | 962 +-------+-------+-------+-------+-------+-------+-------+-------+ 964 Figure 20: Dispatch for Interset Validations 966 ValidationALg: Optional ValidationAlgorithm TLV 968 0000: An uncompressed ValidationAlgorithm TLV is included. 970 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 971 ValidationAlgorithm TLV is included. 973 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 974 ValidationAlgorithm TLV is included. Additionally, a 975 Sigtime TLV is inlined without a type and a length field. 977 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 978 no ValidationAlgorithm TLV is included. 980 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 981 no ValidationAlgorithm TLV is inclued. Additionally, a 982 Sigtime TLV is inlined without a type and a length field. 984 0101: Reserved. 986 0110: Reserved. 988 0111: Reserved. 990 1000: Reserved. 992 1001: Reserved. 994 1010: Reserved. 996 1011: Reserved. 998 1100: Reserved. 1000 1101: Reserved. 1002 1110: Reserved. 1004 1111: Reserved. 1006 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1008 00: The KeyId TLV is absent. 1010 01: The KeyId TLV is present and uncompressed. 1012 10: A T_SHA-256 TLV is present and the type field as well as 1013 the length fields are removed. The length field is 1014 assumed to represent 32 octets. The outer KeyId TLV is 1015 omitted. 1017 11: A T_SHA-512 TLV is present and the type field as well as 1018 the length fields are removed. The length field is 1019 assumed to represent 64 octets. The outer KeyId TLV is 1020 omitted. 1022 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1023 is present. The type field is omitted. 1025 6.4. Content Objects 1027 6.4.1. Uncompressed Content Objects 1029 An uncompressed Content object uses the base dispatch format (see 1030 Figure 4) and sets the C flag to "0" and the M flag to "1" 1031 (Figure 21). "resv" MUST be set to 0. The Content object is handed 1032 to the CCNx network stack without modifications. 1034 0 1 ... 7 1035 +---+---+-----------------------+ 1036 | 0 | 1 | resv | 1037 +---+---+-----------------------+ 1039 Figure 21: Dispatch format for uncompressed CCNx Content objects 1041 6.4.2. Compressed Content Objects 1043 The compressed Content object uses the extended dispatch format 1044 (Figure 5) and sets the C flag as well as the M flag to "1". By 1045 default, the Content object is compressed with the following base 1046 rule set: 1048 1. The PacketType field is elided from the Fixed Header. 1050 2. The Type and Length fields of the CCNx Message TLV are elided and 1051 are obtained from the Fixed Header on decompression. 1053 The compressed CCNx LoWPAN Data message is visualized in Figure 22. 1055 T = Type, L = Length, V = Value 1057 +--------------------------+ +--------------------------+ 1058 | Uncompr. Fixed Header | | Compr. Fixed Header | 1059 +--------------------------+ +--------------------------+ 1060 +--------+--------+--------+ +--------+ 1061 | RCT T | RCT L | RCT V | | RCT V | 1062 +--------+--------+--------+ +--------+--------+ 1063 | MSGH T | MSGH L | MSGH V | | MSGH L | MSGH V | 1064 +--------+--------+--------+ +--------+--------+ 1065 +--------+--------+ +--------+ 1066 | MSGT T | MSGT L | | Name V | 1067 +--------+--------+--------+ +--------+ 1068 | Name T | Name L | Name V | ==> | EXPT V | 1069 +--------+--------+--------+ +--------+--------+ 1070 | PTYP T | PTYP L | PTYP V | | PAYL L | PAYL V | 1071 +--------+--------+--------+ +--------+--------+ 1072 | EXPT T | EXPT L | EXPT V | | VALG L | VALG V | 1073 +--------+--------+--------+ +--------+--------+ 1074 | PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V | 1075 +--------+--------+--------+ +--------+--------+ 1076 | VALG T | VALG L | VALG V | 1077 +--------+--------+--------+ 1078 | VPAY T | VPAY L | VPAY V | 1079 +--------+--------+--------+ 1081 Figure 22: Compressed CCNx LoWPAN Data Message 1083 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1084 Figure 23. 1086 0 1 1087 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1088 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1089 | 1 | 1 |CID|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|EXT| RSV | 1090 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1092 Figure 23: Dispatch format for compressed CCNx Content objects 1094 CID: Context Identifier See Figure 5. 1096 VER: CCNx protocol version in the fixed header 1098 0: The Version field equals 1 and is removed from the fixed 1099 header. 1101 1: The Version field is carried in-line. 1103 FLG: Flags field in the fixed header See Section 6.3.2. 1105 FRS: Reserved field in the fixed header See Section 6.3.2. 1107 PAY: Optional Payload TLV See Section 6.3.2. 1109 RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 1111 0: The Recommended Cache Time TLV is absent. 1113 1: The Recommended Cache Time TLV is present and the type as 1114 well as the length fields are elided. 1116 MGH: Optional Hop-By-Hop MessageHash TLV 1118 See Section 6.4.2.1 for further details on the ordering 1119 of hop-by-hop TLVs. 1121 This TLV is expected to contain a T_SHA-256 TLV. If 1122 another hash is contained, then the Content Object MUST 1123 be sent uncompressed. 1125 0: The MessageHash TLV is absent. 1127 1: A T_SHA-256 TLV is present and the type as well as the 1128 length fields are removed. The length field is assumed 1129 to represent 32 octets. The outer Message Hash TLV is 1130 omitted. 1132 PLTYP: Optional PayloadType TLV 1134 00: The PayloadType TLV is absent. 1136 01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA 1137 is assumed. 1139 10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY 1140 is assumed. 1142 11: The PayloadType TLV is present and uncompressed. 1144 EXP: Optional ExpiryTime TLV 1146 0: The ExpiryTime TLV is absent. 1148 1: The ExpiryTime TLV is present and the type as well as the 1149 length fields are elided. 1151 RSV: Reserved Must be set to 0. 1153 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1154 tion 6.3.2. 1156 EXT: Extension See Section 6.3.2. 1158 6.4.2.1. Hop-By-Hop Header TLVs Compression 1160 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1161 two optional Hop-By-Hop Header TLVs are defined in 1162 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 1163 higher level specifications. For better compression, an ordering of 1164 Hop-By-Hop TLVs is required as follows: 1166 1. Recommended Cache Time TLV 1168 2. Message Hash TLV 1170 With this ordering in place, Type fields are elided from the 1171 Recommended Cache Time TLV and Message Hash TLV. 1173 Note: If the original Content Object message includes Hop-By-Hop 1174 Header TLVs with a different ordering, then they remain uncompressed. 1176 7. Stateful Header Compression 1178 Stateful header compression in ICN LoWPAN enables packet size 1179 reductions in two ways. First, common information that is shared 1180 throughout the local LoWPAN may be memorized in context state at all 1181 nodes and ommitted from communication. Second, redundancy in a 1182 single Interest-data exchange may be removed from ICN stateful 1183 forwarding on a hop-by-hop bases and memorized in en-route state 1184 tables. 1186 7.1. LoWPAN-local State 1188 A context identifier (CID) is an octet that refers to a particular 1189 conceptual context between network devices and MAY be used to replace 1190 frequently appearing information, like name prefixes, suffixes, or 1191 meta information, such as Interest lifetime. 1193 0 1 2 3 4 5 6 7 1194 +---+---+---+---+---+---+---+---+ 1195 | X | ContextID | 1196 +---+---+---+---+---+---+---+---+ 1198 Figure 24: Context Identifier. 1200 The ContextID refers to a locally-scoped unique identifyer that 1201 represents contextual state shared between sender and receiver of the 1202 corresponding frame (see Figure 24). 1204 TODO: Examles? Correspondance to 6Lo? 1206 The initial distribution and maintenance of shared context is out of 1207 scope of this document. Frames containing unknown or invalid CIDs 1208 MUST be silently discarded. 1210 7.2. En-route State 1212 In CCNx and NDN, Name TLVs are included in Interest messages, and 1213 they return in data messages. Returning Name TLVs either equal the 1214 original Name TLV, or they contain the original Name TLV as a prefix. 1215 ICN LoWPAN reduces this redundancy in responses by replacing Name 1216 TLVs with single octets that represent link-local HopIDs. HopIDs are 1217 carried as Context Identifiers of link-local scope as shown in 1218 Figure 25. 1220 0 1 2 3 4 5 6 7 1221 +---+---+---+---+---+---+---+---+ 1222 | X | HopID | 1223 +---+---+---+---+---+---+---+---+ 1225 Figure 25: Context Identifier as HopID. 1227 A HopID is valid, if not all ID bits are set to zero and invalid 1228 otherwise. This yields 127 distinct HopIDs. If this range (1...128) 1229 is exhausted, the messages MUST be sent without en-route state 1230 compression until new HopIDs are available. An ICN LoWPAN node that 1231 forwards without replacing the name by a HopID (without en-route 1232 compression) MUST invalidate the HopID by setting all ID-bits to 1233 zero. 1235 While an Interest is traversing, a forwarder generates an ephemeral 1236 HopID that is tied to a PIT entry. Each HopID MUST be unique within 1237 the local PIT and only exists during the lifetime of a PIT entry. To 1238 maintain HopIDs, the local PIT is extended by two new columns: HIDi 1239 (inbound HopIDs) and HIDo (outbound HopIDs). 1241 HopIDs are included in Interests and stored on the next hop with the 1242 resulting PIT entry in the HIDi column. The HopID is replaced with a 1243 newly generated local HopID before the Interest is forwarded. This 1244 new HopID is stored in the HIDo column of the local PIT (see 1245 Figure 26). 1247 PIT of B PIT Extension PIT of C PIT Extension 1248 +--------+------++------+------+ +--------+------++------+------+ 1249 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1250 +========+======++======+======+ +========+======++======+======+ 1251 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1252 +--------+------++------+------+ +--------+------++------+------+ 1253 ^ | ^ 1254 store | '----------------------, ,---' store 1255 | send v | 1256 ,---, /p0, h_A ,---, /p0, h_B ,---, 1257 | A | ------------------------> | B | ------------------------> | C | 1258 '---' '---' '---' 1260 Figure 26: Setting compression state en-route (Interest). 1262 Responses include HopIDs that were obtained from Interests. If the 1263 returning Name TLV equals the original Name TLV, then the name is 1264 entirely elided. Otherwise, the distinct suffix is included along 1265 with the HopID. When a response is forwarded, the contained HopID is 1266 extracted and used to match against the correct PIT entry by 1267 performing a lookup on the HIDo column. The HopID is then replaced 1268 with the corresponding HopID from the HIDi column prior to forwarding 1269 the reponse (Figure 27). 1271 PIT of B PIT Extension PIT of C PIT Extension 1272 +--------+------++------+------+ +--------+------++------+------+ 1273 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1274 +========+======++======+======+ +========+======++======+======+ 1275 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1276 +--------+------++------+------+ +--------+------++------+------+ 1277 | ^ | 1278 send | '----------------------, ,---' send 1279 v match | v 1280 ,---, h_A ,---, h_B ,---, 1281 | A | <------------------------ | B | <------------------------ | C | 1282 '---' '---' '---' 1284 Figure 27: Eliding Name TLVs using en-route state (data). 1286 It should be noted that each forwarder of an Interest in an ICN 1287 LoWPAN network can individuall decide whether to paricipate in en- 1288 route compression or not. However, an ICN LoWPAN node SHOULD use en- 1289 route compression whenever the stateful compression mechanism is 1290 activated. 1292 Note also that the extensions of the PIT data structure are required 1293 only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside 1294 of an ICN LoWPAN domain do not need to implement these extensions. 1296 7.3. Integrating Stateful Header Compression 1298 A CID appears whenever the CID flag is set (see Figure 5). The CID 1299 is appended to the last ICN LoWPAN dispatch octet as shown in 1300 Figure 28. 1302 ...-------+--------+-------...-------+--...-+-------... 1303 / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / 1304 ...-------+--------+-------...-------+--...-+-------... 1306 Figure 28: LoWPAN Encapsulation with ICN LoWPAN and CIDs 1308 Multiple CIDs are chained together, with the most significant bit 1309 indicating the presence of a subsequent CID (Figure 29). 1311 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1312 |1| CID | --> |1| CID | --> |0| CID | 1313 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1315 Figure 29: Chaining of context identifiers. 1317 The HopID is always included as the very first CID. 1319 8. Implementations 1321 The ICN LoWPAN scheme defined in this document has been implemented 1322 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT 1323 version on RIOT [RIOT]. Experimental verifications have been 1324 performed. 1326 9. Security Considerations 1328 Main memory is typically a scarce resource of constrained networked 1329 devices. Fragmentation as described in this memo preserves fragments 1330 and purges them only after a packet is reassembled, which requires a 1331 buffering of all fragments. This scheme is able to handle fragments 1332 for distinctive packets simultaneously, which can lead to overflowing 1333 packet buffers which cannot hold all necessary fragments for packet 1334 reassembly. Implementers are thus urged to make use of appropriate 1335 buffer replacement strategies for fragments. 1337 The stateful header compression generates ephemeral HopIDs for 1338 incoming and outgoing Interests and consumes them on returning Data 1339 packets. Forged Interests can deplete the number of available 1340 HopIDs, thus leading to a denial of compression service for 1341 subsequent content requests. 1343 To further alleviate the problems caused by forged fragments or 1344 Interest initiations, proper protective mechanisms for accessing the 1345 link-layer should be deployed. 1347 10. IANA Considerations 1349 10.1. Page Switch Dispatch Type 1351 This document makes use of "Page 2" from the existing paging 1352 dispatches in [RFC8025]. 1354 11. References 1356 11.1. Normative References 1358 [ieee802.15.4] 1359 IEEE Computer Society, "IEEE Std. 802.15.4-2015", April 1360 2016, . 1363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1364 Requirement Levels", BCP 14, RFC 2119, 1365 DOI 10.17487/RFC2119, March 1997, 1366 . 1368 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1369 "Transmission of IPv6 Packets over IEEE 802.15.4 1370 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1371 . 1373 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1374 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1375 DOI 10.17487/RFC6282, September 2011, 1376 . 1378 11.2. Informative References 1380 [CCN-LITE] 1381 "CCN-lite: A lightweight CCNx and NDN implementation", 1382 . 1384 [I-D.irtf-icnrg-ccnxmessages] 1385 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1386 Format", draft-irtf-icnrg-ccnxmessages-08 (work in 1387 progress), July 2018. 1389 [I-D.irtf-icnrg-ccnxsemantics] 1390 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1391 draft-irtf-icnrg-ccnxsemantics-09 (work in progress), June 1392 2018. 1394 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1395 "Networking Named Content", 5th Int. Conf. on emerging 1396 Networking Experiments and Technologies (ACM CoNEXT), 1397 2009, . 1399 [NDN-EXP1] 1400 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1401 Waehlisch, "Information Centric Networking in the IoT: 1402 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1403 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1404 77-86, September 2014, 1405 . 1407 [NDN-EXP2] 1408 Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 1409 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 1410 Comparative Measurement Study in the IoT", Proc. of 5th 1411 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 1412 DL, pp. , September 2018, . 1414 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1415 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1416 in NDN: Towards Quantifying the Resource Gain", Proc. of 1417 4th ACM Conf. on Information-Centric Networking (ICN- 1418 2017) ACM DL, pp. 36-42, September 2017, 1419 . 1421 [NDN-PACKET-SPEC] 1422 "NDN Packet Format Specification", 1423 . 1425 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1426 Constrained-Node Networks", RFC 7228, 1427 DOI 10.17487/RFC7228, May 2014, 1428 . 1430 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1431 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1432 "Information-Centric Networking: Baseline Scenarios", 1433 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1434 . 1436 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1437 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1438 "Information-Centric Networking (ICN) Research 1439 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1440 . 1442 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1443 and G. Boggia, "Information-Centric Networking: Evaluation 1444 and Security Considerations", RFC 7945, 1445 DOI 10.17487/RFC7945, September 2016, 1446 . 1448 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1449 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1450 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1451 . 1453 [RIOT] Baccelli, E., Guenes, M., Hahm, O., Schmidt, TC., and M. 1454 Waehlisch, "RIOT OS: Towards an OS for the Internet of 1455 Things", Proc. of the 32nd IEEE INFOCOM IEEE Press, pp. 1456 79-80, April 2013, . 1458 [TLV-ENC-802.15.4] 1459 "CCN and NDN TLV encodings in 802.15.4 packets", 1460 . 1463 [WIRE-FORMAT-CONSID] 1464 "CCN/NDN Protocol Wire Format and Functionality 1465 Considerations", . 1469 Appendix A. Estimated Size Reduction 1471 In the following a theoretical evaluation is given to estimate the 1472 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1474 We assume that "n" is the number of name components, "comps_n" 1475 denotes the sum of n name component lengths. We also assume that the 1476 length of each name component is lower than 16 bytes. The length of 1477 the content is given by "clen". The lengths of TLV components is 1478 specific to the CCNx or NDN encoding and outlined below. 1480 A.1. NDN 1482 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1483 the 1 octet form of each TLV component is assumed. A typical TLV 1484 component therefore is of size 2 (type field + length field) + the 1485 actual value. 1487 A.1.1. Interest 1489 Figure 30 depicts the size requirements for a basic, uncompressed NDN 1490 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1491 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1492 Numbers below represent the amount of octets. 1494 ------------------------------------, 1495 Interest TLV = 2 | 1496 ---------------------, | 1497 Name | 2 + | 1498 NameComponents = 2n + | 1499 | comps_n | 1500 ---------------------' = 21 + 2n + comps_n 1501 CanBePrefix = 2 | 1502 MustBeFresh = 2 | 1503 Nonce = 6 | 1504 InterestLifetime = 4 | 1505 HopLimit = 3 | 1506 ------------------------------------' 1508 Figure 30: Estimated size of an uncompressed NDN Interest 1510 Figure 31 depicts the size requirements after compression. 1512 ------------------------------------, 1513 Dispatch Page Switch = 1 | 1514 NDN Interset Dispatch = 1 | 1515 Interest TLV = 1 | 1516 -----------------------, | 1517 Name | = 9 + n/2 + comps_n 1518 NameComponents = n/2 + | 1519 | comps_n | 1520 -----------------------' | 1521 Nonce = 4 | 1522 InterestLifetime = 2 | 1523 ------------------------------------' 1525 Figure 31: Estimated size of a compressed NDN Interest 1527 The size difference is: 1528 12 + 1.5n octets. 1530 For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets, 1531 which is 46% of the uncompressed packet. 1533 A.1.2. Data 1535 Figure 32 depicts the size requirements for a basic, uncompressed NDN 1536 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1537 1 minute is assumed. The value is thereby encoded using 2 octets. 1538 An HMACWithSha256 is assumed as signature. The key locator is 1539 assumed to contain a Name TLV of length klen. 1541 ------------------------------------, 1542 Data TLV = 2 | 1543 ---------------------, | 1544 Name | 2 + | 1545 NameComponents = 2n + | 1546 | comps_n | 1547 ---------------------' | 1548 ---------------------, | 1549 MetaInfo | | 1550 FreshnessPeriod = 6 = 53 + 2n + comps_n + 1551 | | clen + klen 1552 ---------------------' | 1553 Content = 2 + clen | 1554 ---------------------, | 1555 SignatureInfo | | 1556 SignatureType | | 1557 KeyLocator = 41 + klen | 1558 SignatureValue | | 1559 DigestSha256 | | 1560 ---------------------' | 1561 ------------------------------------' 1563 Figure 32: Estimated size of an uncompressed NDN Data 1565 Figure 33 depicts the size requirements for the compressed version of 1566 the above Data packet. 1568 ------------------------------------, 1569 Dispatch Page Switch = 1 | 1570 NDN Data Dispatch = 1 | 1571 -----------------------, | 1572 Name | = 38 + n/2 + comps_n + 1573 NameComponents = n/2 + | clen + klen 1574 | comps_n | 1575 -----------------------' | 1576 Content = 1 + clen | 1577 KeyLocator = 1 + klen | 1578 DigestSha256 = 32 | 1579 FreshnessPeriod = 2 | 1580 ------------------------------------' 1582 Figure 33: Estimated size of a compressed NDN Data 1584 The size difference is: 1585 15 + 1.5n octets. 1587 For the name "/DE/HH/HAW/BT7", the total size gain is 21 octets. 1589 A.2. CCNx 1591 The CCNx TLV encoding defines a 2-octet encoding for type and length 1592 fields, summing up to 4 octets in total without a value. 1594 A.2.1. Interest 1596 Figure 34 depicts the size requirements for a basic, uncompressed 1597 CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version 1598 is assumed to be 1 and the reserved field is assumed to be 0. A 1599 KeyIdRestriction TLV with T_SHA-256 is included to limit the 1600 responses to Content Objects containing the specific key. 1602 ------------------------------------, 1603 Fixed Header = 8 | 1604 Message = 4 | 1605 ---------------------, | 1606 Name | 4 + = 56 + 4n + comps_n 1607 NameSegments = 4n + | 1608 | comps_n | 1609 ---------------------' | 1610 KeyIdRestriction = 40 | 1611 ------------------------------------' 1613 Figure 34: Estimated size of an uncompressed CCNx Interest 1615 Figure 35 depicts the size requirements after compression. 1617 ------------------------------------, 1618 Dispatch Page Switch = 1 | 1619 CCNx Interest Dispatch = 2 | 1620 Fixed Header = 3 | 1621 -----------------------, | 1622 Name | = 38 + n/2 + comps_n 1623 NameSegments = n/2 + | 1624 | comps_n | 1625 -----------------------' | 1626 T_SHA-256 = 32 | 1627 ------------------------------------' 1629 Figure 35: Estimated size of a compressed CCNx Interest 1631 The size difference is: 1632 18 + 3.5n octets. 1634 For the name "/DE/HH/HAW/BT7", the size is reduced by 53 octets, 1635 which is 53% of the uncompressed packet. 1637 A.2.2. Content Object 1639 Figure 36 depicts the size requirements for a basic, uncompressed 1640 CCNx Content Object containing an ExpiryTime Message TLV, an 1641 HMAC_SHA-256 signature, the signature time and a hash of the shared 1642 secret key. In the fixed header, the protocol version is assumed to 1643 be 1 and the reserved field is assumed to be 0 1645 ------------------------------------, 1646 Fixed Header = 8 | 1647 Message = 4 | 1648 ---------------------, | 1649 Name | 4 + | 1650 NameSegments = 4n + | 1651 | comps_n | 1652 ---------------------' | 1653 ExpiryTime = 12 = 124 + 4n + comps_n + clen 1654 Payload = 4 + clen | 1655 ---------------------, | 1656 ValidationAlgorithm | | 1657 T_HMAC-256 = 56 | 1658 KeyId | | 1659 SignatureTime | | 1660 ---------------------' | 1661 ValidationPayload = 36 | 1662 ------------------------------------' 1664 Figure 36: Estimated size of an uncompressed CCNx Content Object 1666 Figure 37 depicts the size requirements for a basic, compressed CCNx 1667 Data. 1669 ------------------------------------, 1670 Dispatch Page Switch = 1 | 1671 CCNx Content Dispatch = 3 | 1672 Fixed Header = 2 | 1673 -----------------------, | 1674 Name | | 1675 NameSegments = n/2 + | 1676 | comps_n = 89 + n/2 + comps_n + clen 1677 -----------------------' | 1678 ExpiryTime = 8 | 1679 Payload = 1 + clen | 1680 T_HMAC-SHA256 = 32 | 1681 SignatureTime = 8 | 1682 ValidationPayload = 34 | 1683 ------------------------------------' 1685 Figure 37: Estimated size of a compressed CCNx Data Object 1687 The size difference is: 1688 35 + 3.5n octets. 1690 For the name "/DE/HH/HAW/BT7", the size is reduced by 70 octets, 1691 which is 40% of the uncompressed packet containing a 4-octet payload. 1693 Acknowledgments 1695 This work was stimulated by fruitful discussions in the ICNRG 1696 research group and the communities of RIOT and CCNlite. We would 1697 like to thank all active members for constructive thoughts and 1698 feedback. In particular, the authors would like to thank (in 1699 alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, 1700 +++. The hop-wise stateful name compression was brought up in a 1701 discussion by Dave Oran, which is gratefully acknowledged. Larger 1702 parts of this work are inspired by [RFC4944] and [RFC6282]. Special 1703 mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi 1704 Ravindran as their previous work in [TLV-ENC-802.15.4] and 1705 [WIRE-FORMAT-CONSID] provided a good base for our discussions on 1706 stateless header compression mechanisms. This work was supported in 1707 part by the German Federal Ministry of Research and Education within 1708 the projects I3 and RAPstore. 1710 Authors' Addresses 1711 Cenk Gundogan 1712 HAW Hamburg 1713 Berliner Tor 7 1714 Hamburg D-20099 1715 Germany 1717 Phone: +4940428758067 1718 EMail: cenk.guendogan@haw-hamburg.de 1719 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 1721 Thomas C. Schmidt 1722 HAW Hamburg 1723 Berliner Tor 7 1724 Hamburg D-20099 1725 Germany 1727 EMail: t.schmidt@haw-hamburg.de 1728 URI: http://inet.haw-hamburg.de/members/schmidt 1730 Matthias Waehlisch 1731 link-lab & FU Berlin 1732 Hoenower Str. 35 1733 Berlin D-10318 1734 Germany 1736 EMail: mw@link-lab.net 1737 URI: http://www.inf.fu-berlin.de/~waehl 1739 Christopher Scherb 1740 University of Basel 1741 Spiegelgasse 1 1742 Basel CH-4051 1743 Switzerland 1745 EMail: christopher.scherb@unibas.ch 1747 Claudio Marxer 1748 University of Basel 1749 Spiegelgasse 1 1750 Basel CH-4051 1751 Switzerland 1753 EMail: claudio.marxer@unibas.ch 1754 Christian Tschudin 1755 University of Basel 1756 Spiegelgasse 1 1757 Basel CH-4051 1758 Switzerland 1760 EMail: christian.tschudin@unibas.ch