idnits 2.17.1 draft-gundogan-icnrg-ccnlowpan-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 (March 5, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'CCN-LITE' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 1276, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-06 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-06 Summary: 0 errors (**), 0 flaws (~~), 5 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 T. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: September 6, 2018 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 March 5, 2018 13 ICN Adaptation to LowPAN Networks (ICN LoWPAN) 14 draft-gundogan-icnrg-ccnlowpan-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. Basic 27 improvements in efficiency are advised by stateless compression 28 schemes. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 5 64 3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 5 65 3.2. Stateless Header Compression . . . . . . . . . . . . . . 5 66 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 6 67 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 6 68 4.2. ICN LoWPAN Fragmentation . . . . . . . . . . . . . . . . 7 69 5. ICN LoWPAN Header Compression for NDN . . . . . . . . . . . . 8 70 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Interest . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.3. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6. ICN LoWPAN Header Compression for CCNx . . . . . . . . . . . 18 74 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 18 75 6.2. Interest . . . . . . . . . . . . . . . . . . . . . . . . 18 76 6.3. Content Object . . . . . . . . . . . . . . . . . . . . . 24 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 79 8.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . . 27 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 82 9.2. Informative References . . . . . . . . . . . . . . . . . 27 83 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 30 84 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 30 86 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 31 87 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 33 88 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 33 89 A.2.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 34 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 93 1. Introduction 95 The Internet of Things (IoT) has been identified as a promising 96 deployment area for Information Centric Networks (ICN), as 97 infrastructureless access to content, resilient forwarding, and in- 98 network data replication have shown noteable advantages over the 99 traditional host-to-host approach on the Internet [NDN-EXP]. Recent 100 studies [NDN-MAC] have shown that an appropriate mapping to link 101 layer technologies has a large impact on the practical performance of 102 an ICN. This will be even more relevant in the context of IoT 103 communication where nodes often exchange messages via low-power 104 wireless links under lossy conditions. In this memo, we address the 105 base adaptation of data chunks to such link layers for the ICN 106 flavors NDN [NDN] and CCNx. 108 The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and 109 lossy networks (see "LLN" in [RFC7228]), in which devices are 110 typically battery-operated and constrained in resources. 111 Characteristics of LLNs include an unreliable environment, low 112 bandwidth transmissions, and increased latencies. IEEE 802.15.4 113 admits a maximum physical layer packet size of 127 octets. The 114 maximum frame header size is 25 octets, which leaves 102 octets for 115 the payload. IEEE 802.15.4 security features further reduce this 116 payload length by up to 21 octets, yielding a net of 81 octets for 117 CCNx or NDN packet headers, signatures and content. 119 6LoWPAN [RFC4944][RFC6282] is a convergence layer that provides frame 120 formats, header compression and link fragmentation for IPv6 packets 121 in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a 122 dispatching framework that prepends further information to 6LoWPAN 123 packets, including a protocol identifier for IEEE 802.15.4 payload 124 and meta information about link fragmentation. 126 Prevalent Type-Length-Value (TLV) based packet formats such as in 127 CCNx and NDN are designed to be generic and extensible. This leads 128 to header verbosity which is inappropriate in constrained 129 environments of IEEE 802.15.4 links. This document presents ICN 130 LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN 131 that compresses packet headers of CCNx as well as NDN and allows for 132 an increased payload size per packet. Additionally by reusing the 133 dispatching framwork defined by 6LoWPAN, compatibility between 134 coexisting wireless networks of competing technologies is enabled. 135 This also allows to reuse the link fragmentation scheme specified by 136 6LoWPAN for ICN LoWPAN. 138 ICN LoWPAN utilizes a more space efficient representation of CCNx and 139 NDN packet formats. This syntactic change is described for CCNx and 140 NDN separately, as the header formats and TLV encodings differ 141 largely. For further reductions, default header values suitable for 142 constrained IoT networks are selected in order to elide corresponding 143 TLVs. 145 In a typical IoT scenario (see Figure 1), embedded devices are 146 interconnected via quasi-stationary infrastructure whith a border 147 router (BR) interconnecting the constrained LoWPAN networks via some 148 Gateway with the public Internet. In ICN based IoT networks, 149 Interest and Data messages transparently travel through the BR up and 150 down between a Gateway and the embedded devices within the 151 constrained LoWPANs. 153 |Gateway Services| 154 ------------------------- 155 | 156 ,--------, 157 | | 158 | BR | 159 | | 160 '--------' 161 LoWPAN 162 O O 163 O 164 O O embedded 165 O O O devices 166 O O 168 Figure 1: IoT Stub Network 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 The use of the term, "silently ignore" is not defined in RFC 2119. 176 However, the term is used in this document and can be similarly 177 construed. 179 This document uses the terminology of [RFC7476], [RFC7927], and 180 [RFC7945] for ICN entities. 182 The following terms are used in the document and defined as follows: 184 ICN LoWPAN: Information-Centric Networking over Low-power Wireless 185 Personal Area Network 187 LLN Low-Power and Lossy Network 188 CCNx: Content-Centric Networking Architecture 190 NDN: Named Data Networking 192 3. Overview of ICN LoWPAN 194 3.1. Link-Layer Convergence 196 ICN LoWPAN provides a convergence layer that maps ICN packets onto 197 constrained link-layer technologies. This includes features such as 198 link-layer fragmentation, protocol separation on the link-layer 199 level, and link-layer address mappings. The stack traversal is 200 visualized in Figure 2. 202 Device 1 Device 2 203 ,------------------, Router ,------------------, 204 | Application . | __________________ | ,-> Application | 205 |----------------|-| | NDN / CCNx | |-|----------------| 206 | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | 207 |----------------|-| |-|--------------|-| |-|----------------| 208 | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | 209 |----------------|-| |-|--------------|-| |-|----------------| 210 | Link-Layer | | | | Link-Layer | | | | Link-Layer | 211 '----------------|-' '-|--------------|-' '-|----------------' 212 '--------' '---------' 214 Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 216 Section 4 of this document defines the convergence layer for IEEE 217 802.15.4. 219 3.2. Stateless Header Compression 221 ICN LoWPAN also defines a stateless header compression scheme with 222 the main purpose of reducing header overhead of ICN packets. This is 223 of particular importance for link-layers with small MTUs. The 224 stateless compression does not require pre-configuration of global 225 state. 227 The CCNx and NDN header formats are composed of Type-Length-Value 228 (TLV) fields to encode header data. The advantage of TLVs is its 229 native support of variable-sized data. The main disadvantage of TLVs 230 is the verbosity that results from storing the type and length of the 231 encoded data. 233 The stateless header compression scheme makes use of compact bit 234 fields to indicate the presence of mandatory and optional TLVs in the 235 uncompressed packet. The order of set bits in the bit fields 236 corresponds to the order of each TLV in the packet. Further 237 compression is achieved by specifying default values and reducing the 238 codomain of certain header fields. 240 Figure 3 demonstrates the stateless header compression idea. In this 241 example, the first type of the first TLV is removed and the 242 corresponding bit in the bit field is set. The second TLV represents 243 a fixed-length TLV (e.g. the Nonce TLV in NDN), so that the type and 244 the length fields are removed. The third TLV represents a boolean 245 TLV (e.g. the MustBeFresh selector in NDN) and is missing the type, 246 length and the value field. 248 +---+---+---+---+---+---+---+---+ 249 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field 250 +---+---+---+---+---+---+---+---+ 251 | | | 252 ,--' '-----------, '- boolean 253 | | 254 +-------+--------------+-------------+ 255 | LEN | VALUE | VALUE | 256 +-------+--------------+-------------+ 258 Figure 3: Compression using a compact bit field to encode context 259 information. 261 4. IEEE 802.15.4 Adaptation 263 4.1. LoWPAN Encapsulation 265 The IEEE 802.15.4 frame header does not provide a protocol identifier 266 for its payload. This causes problems of misinterpreting frames when 267 several networks coexist on the same link layer. To mitigate errors, 268 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 269 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation 270 headers can prepend the actual payload and each encapsulation header 271 is identified by a dispatch type. 273 [RFC8025] further specifies dispatch pages to switch between 274 different contexts. When a LoWPAN parser encounters a "Page switch" 275 LoWPAN encapsulation header, then all following encapsulation headers 276 are interpreted by using a dispatch table as specified by the "Page 277 switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This 278 document defines dispatch types to identify the payload of CCNx or 279 NDN messages under different compression schemes in Table 1 using 280 page 2 ("1111 0010 (0xF2)") to assure isolated code spaces. 282 +-------------+------+---------------------+ 283 | Bit Pattern | Page | Header Type | 284 +-------------+------+---------------------+ 285 | 0000 0000 | 2 | LOWPAN_CCNX_INT | 286 | 001x xxxx | 2 | LOWPAN_CCNX_INT_HC | 287 | 0100 0000 | 2 | LOWPAN_CCNX_DATA | 288 | 011x xxxx | 2 | LOWPAN_CCNX_DATA_HC | 289 | ... | 2 | ... | 290 | 1000 0000 | 2 | LOWPAN_NDN_INT | 291 | 101x xxxx | 2 | LOWPAN_NDN_INT_HC | 292 | 1100 0000 | 2 | LOWPAN_NDN_DATA | 293 | 111x xxxx | 2 | LOWPAN_NDN_DATA_HC | 294 | ... | 2 | ... | 295 +-------------+------+---------------------+ 297 Table 1: ICN Dispatch Types for (un-)compressed CCNx and NDN 299 For backwards compatibility, [RFC8025] does not require a "Page 300 switch" dispatch type for page 0. For page 2, a "Page switch" header 301 is needed to indicate a context switch before parsing the dispatch 302 type. As an example, to select page 2 and mark the payload as an 303 uncompressed NDN Interest, the bit pattern reads: "1111 0010 1000 304 0000". 306 The encapsulation format for ICN LoWPAN identifying an NDN Interest 307 message is exemplarily displayed in Figure 4. 309 +---------------+-------------+--------+----------------+-------+ 310 | IEEE 802.15.4 | Dispatches | Page 2 | LOWPAN_NDN_INT | Payl. / 311 +---------------+-------------+--------+----------------+-------+ 313 Figure 4: LoWPAN Encapsulation of NDN Interest with ICN LoWPAN 315 IEEE 802.15.4: The IEEE 802.15.4 header. 317 Dispatches: Optional additional dispatch types. 319 Page Switch 2: This page identifier is set to 1111 0010. 321 LOWPAN_NDN_INT: This code point is set to 1000 0000. 323 Payload: The actual NDN Interest Message. 325 4.2. ICN LoWPAN Fragmentation 327 Section 5.3 of [RFC4944] defines a protocol independent fragmentation 328 dispatch type, a fragmentation header for the first fragment and a 329 separate fragmentation header for subsequent fragments. ICN LoWPAN 330 adopts the fragmentation handling of [RFC4944]. 332 The Fragmentation LoWPAN header can encapsulate other dispatch 333 headers. The order of dispatch types is adopted from [RFC4944]. To 334 use the ICN LoWPAN dispatch types (defined in Table 1), a page switch 335 to page 2 MUST occure. Figure 5 shows the fragmentation scheme. The 336 reassembled ICN LoWPAN frame does not contain any fragmentation 337 headers and is depicted in Figure 6. 339 +---------------+-----------+--------+----------------+-------------+ 340 | IEEE 802.15.4 | Frag. 1st | Page 2 | LOWPAN_NDN_INT | Payload ... / 341 +---------------+-----------+--------+----------------+-------------+ 343 +---------------+-----------+-------------+ 344 | IEEE 802.15.4 | Frag. 2nd | ... Payload / 345 +---------------+-----------+-------------+ 347 . 348 . 349 . 351 +---------------+-----------+-------------+ 352 | IEEE 802.15.4 | Frag. Nth | ... Payload / 353 +---------------+-----------+-------------+ 355 Figure 5: Fragmentation scheme 357 +---------------+---------+-----------------+---------+ 358 | IEEE 802.15.4 | Page 2 | LOWPAN_NDN_INT | Payload / 359 +---------------+---------+-----------------+---------+ 361 Figure 6: Reassembled ICN LoWPAN frame 363 5. ICN LoWPAN Header Compression for NDN 365 5.1. TLV Encoding 367 The NDN packet format consists of TLV fields using the TLV encoding 368 that is described in [NDN-TLV]. Type and length fields are of 369 variable size, where numbers greater than 252 are encoded using 370 multiple octets. Figure 7 shows the NDN TLV encoding scheme. 372 If the type or length number is less than "253", then that number is 373 encoded into the actual type or length field (Figure 7 a). If the 374 number is greater or equals "253" and fits into 2 octets, then the 375 type or lengh field is set to "253" and the number is encoded in the 376 next following 2 octets in network byte order, i.e., from the most 377 significant byte (MSB) to the least significant byte (LSB) (Figure 7 378 b). If the number is greater than 2 octets and fits into 4 octets, 379 then the type or length field is set to "254" and the number is 380 encoded in the subsequent 4 octets in network byte order (Figure 7 381 c). For greater numbers, the type or length field is set to "255" 382 and the number is encoded in the subsequent 8 octets in network byte 383 order (Figure 7 d). 385 0 1 2 3 4 5 6 7 386 +-+-+-+-+-+-+-+-+ 387 a) | < 253 | 388 +-+-+-+-+-+-+-+-+ 390 0 1 2 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 b) | 253 | MSB LSB | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | 254 | MSB / 400 c) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | LSB | 402 +-+-+-+-+-+-+-+-+ 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | 255 | MSB / 408 +-+-+-+-+-+-+-+-+ + 409 d) | / 410 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | LSB | 412 +-+-+-+-+-+-+-+-+ 414 Figure 7: NDN TLV encoding scheme 416 In this document, compressed NDN TLVs make use of a different TLV 417 scheme that puts more emphasis on size reduction. Instead of using 418 the first octet as a marker for the number of following octets, the 419 compressed NDN TLV scheme uses a method to chain a variable number of 420 octets together. If an octet equals "255 (0xFF)", then the following 421 octet will also be interpreted. The actual value of a chain equals 422 the sum of all links. 424 If the type or length number is less than "255", then that number is 425 encoded into the actual type or length field (Figure 8 a). If the 426 type or length number (X) fits into 2 octets, then the first octet is 427 set to "255" and the subsequent octet equals "X mod 255" (Figure 8 428 b). Following this scheme, a variable-sized number (X) is encoded 429 using multiple octets of "255" with a trailing octet containing "X 430 mod 255" (Figure 8 c). 432 0 1 2 3 4 5 6 7 433 +-+-+-+-+-+-+-+-+ 434 a) | < 255 (X) | = X 435 +-+-+-+-+-+-+-+-+ 437 0 1 438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 b) | 255 | < 255 (X) | = 255 + X 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 0 444 0 1 2 3 4 5 6 7 445 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 446 c) | 255 | 255 | < 255 (X) | = (N * 255) + X 447 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 448 (N - 1) 450 Figure 8: Compressed NDN TLV encoding scheme 452 5.2. Interest 454 5.2.1. Uncompressed Interest 456 An uncompressed Interest message uses the LoWPAN dispatch 457 "LOWPAN_NDN_INT". The Interest message is handed to the NDN network 458 stack without modifications. 460 5.2.2. Compression Base Header Format 462 The compression base header makes use of the dispatch type 463 "LOWPAN_NDN_INT_HC" (Table 1). 465 By default, the Interest message is compressed with the following 466 rule set: 468 1. The outermost Interest TLV is removed. 470 2. The "Type" field of the Name TLV is removed. 472 3. The "Type" and "Length" fields of the NonceTLV are removed. 474 Further compression rules are given in the "LOWPAN_NDN_INT_HC" 475 dispatch (Figure 9). 477 0 478 0 1 2 3 4 5 6 7 479 +---+---+---+---+---+---+---+---+ 480 | 1 | 0 | 1 |NCO|SNC|SEL|GUI|EXT| 481 +---+---+---+---+---+---+---+---+ 483 Figure 9: Compression base header format for Interest 485 NCO: NameComponent TLVs 487 0: The Name TLV is uncompressed and all NameComponent TLVs 488 contain a type field. 490 1: The first NameComponent TLV keeps the type field and all 491 type fields of subsequent NameComponent TLVs are elided. 492 When the Name TLV is decompressed, then the type field of 493 the first NameComponent TLV is replicated to all other 494 NameComponent TLVs. 496 SNC: Short NameComponent TLVs 498 0: The length fields of NameComponent TLVs are encoded as 499 described in Figure 8. 501 1: All NameComponent TLVs are limited in size to 15 octets 502 each and no 0 length NameComponent TLVs are present. The 503 compressed length encoding for short NameComponent TLVs 504 as described in Section 5.2.3 is used. Additionally, 505 using this encoding, the outermost length field of the 506 Name TLV is obsolete and removed. 508 SEL: Selector TLVs 510 0: No Selector TLVs are present in the Interest message. 512 1: Selector TLVs are present in the Interest message. An 513 additional octet follows immediately this dispatch octet 514 and handles Selector TLV compressions. See 515 Section 5.2.4. 517 GUI: Guider TLVs 519 0: No Guider TLVs are present in the Interest message. 521 1: Guider TLVs are present in the Interest message. An 522 additional octet follows immediately this dispatch octet 523 and handles Guider TLV compressions. See Section 5.2.5. 525 EXT: Extension 527 0: No extension octet follows. 529 1: An extension octet follows immediately. Extension octets 530 are used to extend the compression scheme, but are out of 531 scope of this document. 533 5.2.3. Short NameComponent TLV Encoding 535 The short NameComponent TLV encoding encodes the length fields of two 536 consecutive NameComponent TLVs into one octet, using 4 bits each. 537 This process limits the length of a NameComponent TLV to 15 octets 538 and is repeated until a length of 0 is encountered, which marks the 539 end of the Name TLV. This encoding forbids 0 length NameComponent 540 TLVs. 542 Name: /HAW/Room/481/Humid/12 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |0 0 1 1|0 1 0 0| H | A | W | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | R | o | o | m | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | H | u | m | i | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | d |0 0 1 0|0 0 0 0| 1 | 2 | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 10: Length field encoding for short NameComponent TLVs 560 5.2.4. Selectors Compression 562 0 1 2 3 4 5 6 7 563 +-------+-------+-------+-------+-------+-------+-------+-------+ 564 | minSx | maxSx | ppk | excld | ChildSel | fresh | resvd | 565 +-------+-------+-------+-------+-------+-------+-------+-------+ 567 Figure 11: LOWPAN_NDN_INT_HC_SEL 569 minSX: 1 bit flag. If set, then MinSuffixComponents are present in 570 the Interest message and the type field is removed. 572 maxSX: 1 bit flag. If set, then MaxSuffixComponents are present in 573 the Interest message and the type field is removed. 575 ppk: 1 bit flag. If set, then a PublisherPublicKeyLocator is 576 present in the Interest message and the type field is 577 removed. 579 excld: 1 bit flag. If set, then an exclude selector is present in 580 the Interest message and the type field is removed. 582 ChildSel: ChildSelector TLV 584 00: The ChildSelector is absent and a value of 0 is assumed. 586 01: The ChildSelector with value 0 was removed during the 587 compression. 589 10: The ChildSelector with value 1 was removed during the 590 compression. 592 fresh: 1 bit flag. If set, then a MustBeFresh selector is present 593 in the Interest message and the type and length fields are 594 removed. 596 resvd: 1 bit reserved and MUST be set to 0. 598 5.2.5. Guiders Compression 600 0 1 2 3 4 5 6 7 601 +-------+-------+-------+-------+-------+-------+-------+-------+ 602 | InterestLifetime |fwdhint| Reserved | 603 +-------+-------+-------+-------+-------+-------+-------+-------+ 605 Figure 12: LOWPAN_NDN_INT_HC_GUI 607 InterestLifetime TLV 609 000: The InterestLifetime TLV is absent in the original packet 610 and a default value of 4 seconds is assumed. 612 001: The InterestLifetime TLV is present and the type field is 613 removed. The length field is removed and assumed to be 614 "1". 616 010: The InterestLifetime TLV is present and the type field is 617 removed. The length field is removed and assumed to be 618 "2". 620 011: The InterestLifetime TLV is present and the type field is 621 removed. The length field is removed and assumed to be 622 "4". 624 100: The InterestLifetime TLV is present and the type field is 625 removed. The length field is removed and assumed to be 626 "8". 628 101: The InterestLifetime TLV with value 4 seconds is present 629 in the Interest message. It is removed on compression 630 and inserted on decompression. 632 110: Reserved. 634 111: Reserved. 636 fwdhint: 1 bit flag. If set, then a ForwardingHint TLV is present 637 in the Interest message and the type field is removed. 639 5.3. Data 641 5.3.1. Uncompressed Data 643 An uncompressed Data message uses the LoWPAN dispatch 644 "LOWPAN_NDN_DATA". The Data message is handed to the NDN network 645 stack without modifications. 647 5.3.2. Compression Base Header Format 649 The compression base header makes use of the dispatch type 650 "LOWPAN_NDN_DATA_HC" (Table 1). 652 By default, the Data message is compressed with the following rule 653 set: 655 1. The outermost Data TLV is removed. 657 2. The "Type" field of the Name TLV is removed. 659 3. The "Type" field of the MetaInfo TLV is removed. 661 4. The "Type" field of the Content TLV is removed. 663 5. The "Type" field of the SignatureInfo TLV is removed. 665 6. The "Type" field of the SignatureValue TLV is removed. 667 Further compression rules are given in the "LOWPAN_NDN_DATA_HC" 668 dispatch (Figure 13). 670 0 1 671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 672 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 673 | 1 | 0 | 1 |NCO|SNC|MET|EXT| Reserved | SIG | 674 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 676 Figure 13: Compression base header format for Data 678 NCO: NameComponent TLVs See Section 5.2.2. 680 SNC: Short NameComponent TLVs See Section 5.2.2. 682 MET: MetaInfo TLVs 684 0: No MetaInfo TLVs are present in the Data message. 686 1: MetaInfo TLVs are present in the Data message. An 687 additional octet follows immediately that handles 688 MetaInfo TLV compressions and is described in 689 Section 5.3.3. 691 EXT: Extension See Section 5.2.2. 693 SIG: Signature TLVs 695 0000: The type fields of the SignatureInfo TLV, SignatureType 696 TLV and SignatureValue TLV are removed. 698 0001: The Signature represents a DigestSha256. The 699 SignatureInfo and SignatureValue TLVs are absent. The 32 700 byte digest immediately follows the content. 702 0010: The Signature represents a SignatureSha256WithRsa. The 703 SignatureInfo TLV is absent and the SignatureValue TLV is 704 present without a type field. A KeyLocator TLV without a 705 type field follows immediately the content. The RSA 706 signature immediately follows the SignatureValue TLV. 708 0011: The Signature represents a SignatureSha256WithEcdsa. The 709 SignatureInfo TLV is absent and the SignatureValue TLV is 710 present without a type field. A KeyLocator TLV without a 711 type field follows immediately the content. The ECDSA 712 signature immediately follows the SignatureValue TLV. 714 0100: The Signature represents a SignatureHmacWithSha256. The 715 SignatureInfo and SignatureValue TLVs are absent. A 716 KeyLocator TLV without a type field follows immediately 717 the content. The 32 byte HMAC signature follows 718 immediately the Keylocator TLV 720 0101: Reserved. 722 0110: Reserved. 724 0111: Reserved. 726 1000: Reserved. 728 1001: Reserved. 730 1010: Reserved. 732 1011: Reserved. 734 1100: Reserved. 736 1101: Reserved. 738 1110: Reserved. 740 1111: Reserved. 742 5.3.3. MetaInfo Compression 744 0 1 2 3 4 5 6 7 745 +-------+-------+-------+-------+-------+-------+-------+-------+ 746 | ctype | freshperiod | finalblid | 747 +-------+-------+-------+-------+-------+-------+-------+-------+ 749 Figure 14: LOWPAN_NDN_DATA_HC_B 751 ctype: ContentType TLV 753 000: The ContentType TLV is absent in the original Data 754 message and the default value "0" is assumed. 756 001: The ContentType TLV is present and the type field is 757 removed. The length field is removed and assumed to be 758 "1". 760 010: The ContentType TLV is present and the type field is 761 removed. The length field is removed and assumed to be 762 "2". 764 011: The ContentType TLV is present and the type field is 765 removed. The length field is removed and assumed to be 766 "4". 768 100: The ContentType TLV is present and the type field is 769 removed. The length field is removed and assumed to be 770 "8". 772 101: The ContentType TLV with value 0 is present in the Data 773 message. It is removed on compression and inserted on 774 decompression. 776 110: Reserved. 778 111: Reserved. 780 freshperiod: FreshnessPeriod TLV 782 000: The FreshnessPeriod TLV is absent in the original Data 783 message. 785 001: The FreshnessPeriod TLV is present and the type field is 786 removed. The length field is removed and assumed to be 787 "1". 789 010: The FreshnessPeriod TLV is present and the type field is 790 removed. The length field is removed and assumed to be 791 "2". 793 011: The FreshnessPeriod TLV is present and the type field is 794 removed. The length field is removed and assumed to be 795 "4". 797 100: The FreshnessPeriod TLV is present and the type field is 798 removed. The length field is removed and assumed to be 799 "8". 801 101: Reserved. 803 110: Reserved. 805 111: Resedved. 807 finalblid: FinalBLockId TLV 808 00: The FinalBlockId TLV is absent. 810 01: The FinalBlockId TLV is absent, but a FinalBlockId TLV 811 equal to the last NameComponent TLV of the Data message 812 name is assumed. 814 10: The FinalBlockId TLV is present and the type field is 815 removed. 817 11: Reserved. 819 6. ICN LoWPAN Header Compression for CCNx 821 6.1. TLV Encoding 823 The CCNx TLV encoding is described in [I-D.irtf-icnrg-ccnxmessages]. 824 Type and length fields are of fixed length of 2 octets each. 826 In this document, the TLV encoding is changed to the more space 827 efficient encoding described in Section 5.1. Type and length fields 828 MUST be encoded as in Figure 8. 830 6.2. Interest 832 6.2.1. Uncompressed Interest 834 An uncompressed Interest message uses the LoWPAN dispatch 835 "LOWPAN_CCNX_INT". The Interest message is handed to the CCNx 836 network stack without modifications. 838 6.2.2. Compression Base Header Format 840 The compression base header makes use of the dispatch type 841 "LOWPAN_CCNX_INT_HC" (Table 1). 843 By default, the Interest message is compressed with the following 844 rule set: 846 1. The type and length fields of the CCNx Message TLV are elided and 847 are obtained from the Fixed Header on decompression. 849 Further compression rules are given in the "LOWPAN_CCNX_INT_HC" 850 dispatch (Figure 15). 852 0 1 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 854 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 855 | 0 | 0 | 1 |NSG|SNS|FLG|HBH|PTY|HPL|FRS|MSG|PAY|VAL|EXT| RESVD | 856 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 858 Figure 15: Compression base header format for Interest 860 NSG: NameSegment TLVs See Section 5.2.2. 862 SNS: Short NameSegment TLVs See Section 5.2.2. 864 FLG: Flags field in the Fixed Header 866 0: The Flags field equals 0 and is removed from the Interest 867 message. 869 1: The Flags field is carried in-line. 871 HBH: Optional Hop-By-Hop Header TLVs 873 0: No Hop-By-Hop Header TLVs are present in the Interest 874 message. Also, the HeaderLength field in the fixed 875 header is elided from the Interest message and assumed to 876 be "8". 878 1: Hop-By-Hop Header TLVs are present in the Interest 879 message. An additional octet follows immediately that 880 handles Hop-By-Hop Header TLV compressions and is 881 described in Section 6.2.3. 883 PTY: PacketType field in the fixed header 885 0: The PacketType field is elided and assumed to be 886 "PT_INTEREST" 888 1: The PacketType field is elided and assumed to be 889 "PT_RETURN" 891 HPL: HopLimit field in the fixed header 893 0: The HopLimit field is carried in-line 895 1: The HopLimit field is elided and assumed to be "1" 897 FRS: Reserved field in the fixed header 899 0: The Reserved field is carried in-line 900 1: The Reserved field is elided and assumed to be "0" 902 MSG: Optional Interest Message TLVs 904 0: No Interest Message TLVs are present in the Interest 905 message. 907 1: Interest Message TLVs are present in the Interest 908 message. An additional octet follows immediately that 909 handles Interest Message TLV compressions and is 910 described in Section 6.2.4. 912 PAY: Optional Payload TLV 914 0: The Payload TLV is absent. 916 1: The Payload TLV is present and the type field is elided. 918 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 920 0: No validation related TLVs are present in the Interest 921 message. 923 1: Validation related TLVs are present in the Interest 924 message. An additional octet follows immediately that 925 handles validation related TLV compressions and is 926 described in Section 6.2.5. 928 EXT: Extension 930 0: No extension octet follows. 932 1: An extension octet follows immediately. Extension octets 933 are used to extend the compression scheme, but are out of 934 scope of this document. 936 6.2.3. Hop-By-Hop Header TLVs Compression 938 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 939 optional Hop-By-Hop Header TLVs are defined in 940 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 941 higher level specifications. For better compression, an ordering of 942 Hop-By-Hop TLVs is enforced as follows: 944 1. Interest Lifetime TLV 946 2. Message Hash TLV 947 This ordering is encoded into "LOWPAN_CCNX_INT_HC_HBH" so that type 948 fields are elided from the Interest Lifetime TLV and the Message Hash 949 TLV. 951 Note: If the original Interest message includes Hop-By-Hop Header 952 TLVs with a different ordering, then they remain uncompressed. 954 0 1 2 3 4 5 6 7 955 +-------+-------+-------+-------+-------+-------+-------+-------+ 956 | IntLifetime | MsgHash | Reserved | 957 +-------+-------+-------+-------+-------+-------+-------+-------+ 959 Figure 16: LOWPAN_CCNX_INT_HC_HBH 961 IntLifetime: InterstLifetime Hop-By-Hop Header TLV 963 00: The Interest Lifetime TLV is absent. 965 01: The Interest Lifetime TLV is present and the type field 966 is removed. 968 10: The Interest Lifetime TLV is absent and a default value 969 of 0 seconds is assumed. 971 11: The Interest Lifetime TLV is absent and a default value 972 of 10 minutes is assumed. 974 MsgHash: Message Hash Hop-By-Hop Header TLV 976 00: The Message Hash TLV is absent. 978 01: The Message Hash TLV is present and uncompressed. 980 10: A T_SHA-256 TLV is present and the type field as well as 981 the length fields are removed. The length field is 982 assumed to represent 32 octets. The outer Message Hash 983 TLV is omitted. 985 11: A T_SHA-512 TLV is present and the type field as well as 986 the length fields are removed. The length field is 987 assumed to represent 64 octets. The outer Message Hash 988 TLV is omitted. 990 6.2.4. Interest Message TLVs Compression 991 0 1 2 3 4 5 6 7 992 +-------+-------+-------+-------+-------+-------+-------+-------+ 993 | KeyIDRestr | CObHRestr | Reserved | 994 +-------+-------+-------+-------+-------+-------+-------+-------+ 996 Figure 17: LOWPAN_CCNX_INT_HC_MSG 998 KeyIDRestr: Optional KeyIdRestriction TLV within a CCNx Message TLV 1000 00: The KeyIdRestriction TLV is absent. 1002 01: The KeyIdRestriction TLV is present and uncompressed. 1004 10: A T_SHA-256 TLV is present and the type field as well as 1005 the length fields are removed. The length field is 1006 assumed to represent 32 octets. The outer 1007 KeyIdRestriction TLV is omitted. 1009 11: A T_SHA-512 TLV is present and the type field as well as 1010 the length fields are removed. The length field is 1011 assumed to represent 64 octets. The outer 1012 KeyIdRestriction TLV is omitted. 1014 CObHRestr: Optional ContentObjectHashRestriction TLV within a CCNx 1015 Message TLV 1017 00: The ContentObjectHashRestriction TLV is absent. 1019 01: The ContentObjectHashRestriction TLV is present and 1020 uncompressed. 1022 10: A T_SHA-256 TLV is present and the type field as well as 1023 the length fields are removed. The length field is 1024 assumed to represent 32 octets. The outer 1025 ContentObjectHashRestriction TLV is omitted. 1027 11: A T_SHA-512 TLV is present and the type field as well as 1028 the length fields are removed. The length field is 1029 assumed to represent 64 octets. The outer 1030 ContentObjectHashRestriction TLV is omitted. 1032 6.2.5. Validation 1033 0 1 2 3 4 5 6 7 8 1034 +-------+-------+-------+-------+-------+-------+-------+-------+ 1035 | ValidationAlg | KeyID | Reserved | 1036 +-------+-------+-------+-------+-------+-------+-------+-------+ 1038 Figure 18: LOWPAN_CCNX_INT_HC_VAL 1040 ValidationALg: Optional ValidationAlgorithm TLV 1042 0000: An uncompressed ValidationAlgorithm TLV is included. 1044 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1045 ValidationAlgorithm TLV is included. 1047 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1048 ValidationAlgorithm TLV is included. Additionally, a 1049 Sigtime TLV is inlined without a type and a length field. 1051 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1052 no ValidationAlgorithm TLV is included. 1054 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1055 no ValidationAlgorithm TLV is inclued. Additionally, a 1056 Sigtime TLV is inlined without a type and a length field. 1058 0101: Reserved. 1060 0110: Reserved. 1062 0111: Reserved. 1064 1000: Reserved. 1066 1001: Reserved. 1068 1010: Reserved. 1070 1011: Reserved. 1072 1100: Reserved. 1074 1101: Reserved. 1076 1110: Reserved. 1078 1111: Reserved. 1080 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1081 00: The KeyId TLV is absent. 1083 01: The KeyId TLV is present and uncompressed. 1085 10: A T_SHA-256 TLV is present and the type field as well as 1086 the length fields are removed. The length field is 1087 assumed to represent 32 octets. The outer KeyId TLV is 1088 omitted. 1090 11: A T_SHA-512 TLV is present and the type field as well as 1091 the length fields are removed. The length field is 1092 assumed to represent 64 octets. The outer KeyId TLV is 1093 omitted. 1095 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1096 is present. The type field is omitted. 1098 6.3. Content Object 1100 6.3.1. Uncompressed Content Object 1102 An uncompressed Content Object message uses the LoWPAN dispatch 1103 "LOWPAN_CCNX_DATA". The Content Object message is handed to the CCNx 1104 network stack without modifications. 1106 6.3.2. Compression Base Header Format 1108 The compression base header makes use of the dispatch type 1109 "LOWPAN_CCNX_DATA_HC" (Table 1). 1111 By default, the Content Object message is compressed with the 1112 following rule set: 1114 1. The PacketType field is elided from the Fixed Header. 1116 2. The type and length fields of the CCNx Message TLV are elided and 1117 are obtained from the Fixed Header on decompression. 1119 Further compression rules are given in the "LOWPAN_CCNX_DATA_HC" 1120 dispatch (Figure 19). 1122 0 1 1123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1124 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1125 | 0 | 0 | 1 |NSG|SNS|FLG|HBH|FRS|MSG|PAY|VAL|EXT| RESVD | 1126 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1128 Figure 19: Compression base header format for Content Object 1130 NSG: NameSegment TLVs See Section 5.2.2. 1132 SNS: Short NameSegment TLVs See Section 5.2.2. 1134 FLG: Flags field in the fixed header See Section 6.2.2. 1136 HBH: Optional Hop-By-Hop Header TLVs 1138 0: No Hop-By-Hop Header TLVs are present in the Content 1139 Object message. Also, the HeaderLength field in the 1140 fixed header is elided from the Content Object message 1141 and assumed to be "8". 1143 1: Hop-By-Hop Header TLVs are present in the Content Object 1144 message. An additional octet follows immediately that 1145 handles Hop-By-Hop Header TLV compressions and is 1146 described in Section 6.3.3. 1148 FRS: Reserved field in the Fixed Header See Section 6.2.2. 1150 MSG: Optional Content Object Message TLVs 1152 0: No Content Object Message TLVs are present in the Content 1153 Object message. 1155 1: Content Object Message TLVs are present in the Content 1156 Object message. An additional octet follows immediately 1157 that handles Content Object Message TLV compressions and 1158 is described in Section 6.3.4. 1160 PAY: Optional Payload TLV See Section 6.2.2. 1162 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1163 tion 6.2.2. 1165 EXT: Extension See Section 6.2.2. 1167 6.3.3. 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 enforced as follows: 1175 1. Recommended Cache Time TLV 1177 2. Message Hash TLV 1178 This ordering is encoded into "LOWPAN_CCNX_DATA_HC_HBH" so that type 1179 fields are elided from the Recommended Cache Time TLV and the Message 1180 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 0 1 2 3 4 5 6 7 1186 +-------+-------+-------+-------+-------+-------+-------+-------+ 1187 | RCT | MsgHash | Reserved | 1188 +-------+-------+-------+-------+-------+-------+-------+-------+ 1190 Figure 20: LOWPAN_CCNX_DATA_HC_HBH 1192 RCT: Recommended Cache Time Hop-By-Hop Header TLV 1194 0: The Recommended Cache Time TLV is absent. 1196 1: The Recommended Cache Time TLV is present and the type as 1197 well as the length fields are elided. 1199 MsgHash: Message Hash Hop-By-Hop Header TLV See Section 6.2.3. 1201 6.3.4. Content Object Message TLVs Compression 1203 0 1 2 3 4 5 6 7 1204 +-------+-------+-------+-------+-------+-------+-------+-------+ 1205 | PayloadType |ExpTime| Reserved | 1206 +-------+-------+-------+-------+-------+-------+-------+-------+ 1208 Figure 21: LOWPAN_CCNX_DATA_HC_MSG 1210 PayloadType: Optional PayloadType TLV within a CCNx Message TLV 1212 00: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA is 1213 assumed. 1215 01: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY is 1216 assumed. 1218 10: The PayloadType TLV is absent and T_PAYLOADTYPE_LINK is 1219 assumed. 1221 11: The PayloadType TLV is present and uncompressed. 1223 ExpTime: Optional ExpiryTime TLV within a CCNx Message TLV 1225 0: The ExpiryTime TLV is absent. 1227 1: The ExpiryTime TLV is present and the type as well as the 1228 length fields are elided. 1230 7. Security Considerations 1232 TODO 1234 8. IANA Considerations 1236 8.1. Page Switch Dispatch Type 1238 This document makes use of "Page 2" from the existing paging 1239 dispatches in [RFC8025]. 1241 9. References 1243 9.1. Normative References 1245 [ieee802.15.4] 1246 IEEE Computer Society, "IEEE Std. 802.15.4-2015", April 1247 2016, . 1250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1251 Requirement Levels", BCP 14, RFC 2119, 1252 DOI 10.17487/RFC2119, March 1997, 1253 . 1255 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1256 "Transmission of IPv6 Packets over IEEE 802.15.4 1257 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1258 . 1260 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1261 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1262 DOI 10.17487/RFC6282, September 2011, 1263 . 1265 9.2. Informative References 1267 [CCN-LITE] 1268 "CCN-lite: A lightweight CCNx and NDN implementation", 1269 . 1271 [I-D.irtf-icnrg-ccnxmessages] 1272 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1273 Format", draft-irtf-icnrg-ccnxmessages-06 (work in 1274 progress), October 2017. 1276 [I-D.irtf-icnrg-ccnxsemantics] 1277 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1278 draft-irtf-icnrg-ccnxsemantics-06 (work in progress), 1279 October 2017. 1281 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1282 "Networking Named Content", 5th Int. Conf. on emerging 1283 Networking Experiments and Technologies (ACM CoNEXT), 1284 2009, . 1286 [NDN-EXP] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1287 Waehlisch, "Information Centric Networking in the IoT: 1288 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1289 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1290 77-86, September 2014, 1291 . 1293 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1294 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1295 in NDN: Towards Quantifying the Resource Gain", Proc. of 1296 4th ACM Conf. on Information-Centric Networking (ICN- 1297 2017) ACM DL, pp. 36-42, September 2017, 1298 . 1300 [NDN-TLV] "NDN Packet Format Specification", 1301 . 1303 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1304 Constrained-Node Networks", RFC 7228, 1305 DOI 10.17487/RFC7228, May 2014, 1306 . 1308 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1309 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1310 "Information-Centric Networking: Baseline Scenarios", 1311 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1312 . 1314 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1315 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1316 "Information-Centric Networking (ICN) Research 1317 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1318 . 1320 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1321 and G. Boggia, "Information-Centric Networking: Evaluation 1322 and Security Considerations", RFC 7945, 1323 DOI 10.17487/RFC7945, September 2016, 1324 . 1326 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1327 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1328 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1329 . 1331 Appendix A. Estimated Size Reduction 1333 In the following a theoretical evaluation is given to estimate the 1334 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1336 We assume that "n" is the number of name components, "comps_n" 1337 denotes the sum of n name component lengths. We also assume that the 1338 length of each name component is lower than 16 bytes. The length of 1339 the content is given by "clen". The lengths of TLV components is 1340 specific to the CCNx or NDN encoding and outlined below. 1342 A.1. NDN 1344 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1345 the 1 octet form of each TLV component is assumed. A typical TLV 1346 component therefore is of size 2 (type field + length field) + the 1347 actual value. 1349 A.1.1. Interest 1351 Figure 22 depicts the size requirements for a basic, uncompressed NDN 1352 Interest containing a MustBeFresh selector, a ChildSelector with 1353 value 1 (rightmost child) and an InterestLifetime guider set to 4 1354 seconds. Numbers below represent the amount of octets. 1356 ------------------------------------, 1357 Interest = 2 | 1358 ---------------------, | 1359 Name | 2 + | 1360 NameComponents = 2n + | 1361 | comps_n | 1362 ---------------------' | 1363 ---------------------, = 21 + 2n + comps_n 1364 Selectors | | 1365 MustBeFresh = 7 | 1366 ChildSelector | | 1367 ---------------------' | 1368 Nonce = 6 | 1369 InterestLifetime = 4 | 1370 ------------------------------------' 1372 Figure 22: Estimated size of an uncompressed NDN Interest 1374 Figure 23 depicts the size requirements after compression. 1376 ------------------------------------, 1377 Dispatch Page Switch = 1 | 1378 LOWPAN_NDN_INT_HC = 1 | 1379 LOWPAN_NDN_INT_HC_SEL = 1 | 1380 LOWPAN_NDN_INT_HC_GUI = 1 | 1381 -----------------------, = 9 + n/2 + comps_n 1382 Name | 1 + | 1383 NameComponents = n/2 + | 1384 | comps_n | 1385 -----------------------' | 1386 Nonce = 4 | 1387 ------------------------------------' 1389 Figure 23: Estimated size of a compressed NDN Interest 1391 The NDN Interest message is compressed with the "LOWPAN_NDN_INT_HC" 1392 strategy using the two additional octets "LOWPAN_NDN_INT_HC_SEL" and 1393 "LOWPAN_NDN_INT_HC_GUI". The MustBeFresh and Child selectors are 1394 omitted. The type and length fields of the Nonce TLV are elided. 1396 The size difference is: 1397 12 + 1.5n octets. 1399 For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets, 1400 which is 46% of the uncompressed packet. 1402 A.1.2. Data 1404 Figure 24 depicts the size requirements for a basic, uncompressed NDN 1405 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1406 10 minutes is assumed and the value is given as 600,000 milliseconds. 1407 The value is thereby encoded using 4 octets. An HMACWithSha256 is 1408 assumed as signature. The key locator is assumed to contain a Name 1409 TLV of length klen. 1411 ------------------------------------, 1412 Data = 2 | 1413 ---------------------, | 1414 Name | 2 + | 1415 NameComponents = 2n + | 1416 | comps_n | 1417 ---------------------' | 1418 ---------------------, | 1419 MetaInfo | | 1420 FreshnessPeriod = 8 = 55 + 2n + comps_n + 1421 | | clen + klen 1422 ---------------------' | 1423 Content = 2 + clen | 1424 ---------------------, | 1425 SignatureInfo | | 1426 SignatureType | | 1427 KeyLocator = 41 + klen | 1428 SignatureValue | | 1429 DigestSha256 | | 1430 ---------------------' | 1431 ------------------------------------' 1433 Figure 24: Estimated size of an uncompressed NDN Data 1435 Figure 25 depicts the size requirements for the compressed version of 1436 the above Data packet. 1438 ------------------------------------, 1439 Dispatch Page Switch = 1 | 1440 LOWPAN_NDN_DATA_HC = 2 | 1441 LOWPAN_NDN_DATA_HC_MET = 1 | 1442 -----------------------, | 1443 Name | 1 + = 43 + n/2 + comps_n + 1444 NameComponents = n/2 + | clen + klen 1445 | comps_n | 1446 -----------------------' | 1447 FreshnessPeriod = 4 | 1448 Content = 1 + clen | 1449 KeyLocator = 1 + klen | 1450 DigestSha256 = 32 | 1451 ------------------------------------' 1453 Figure 25: Estimated size of a compressed NDN Data 1455 The size difference is: 1456 12 + 1.5n octets. 1458 For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets. 1460 A.2. CCNx 1462 The CCNx TLV encoding defines a 2-octet encoding for type and length 1463 fields, summing up to 4 octets in total without a value. 1465 A.2.1. Interest 1467 Figure 26 depicts the size requirements for a basic, uncompressed 1468 CCNx Interest. No Hop-By-Hop TLVs are included and the protocol 1469 version as well as the reserved field are assumed to be 0. A 1470 KeyIdRestriction TLV with T_SHA-256 is included to limit the 1471 responses to Content Objects containing the specific key. 1473 ------------------------------------, 1474 Fixed Header = 8 | 1475 Message = 4 | 1476 ---------------------, | 1477 Name | 4 + = 56 + 4n + comps_n 1478 NameSegments = 4n + | 1479 | comps_n | 1480 ---------------------' | 1481 KeyIdRestriction = 40 | 1482 ------------------------------------' 1484 Figure 26: Estimated size of an uncompressed CCNx Interest 1486 Figure 27 depicts the size requirements after compression. 1488 ------------------------------------, 1489 Dispatch Page Switch = 1 | 1490 LOWPAN_CCNX_INT_HC = 2 | 1491 LOWPAN_CCNX_INT_HC_MSG = 1 | 1492 Fixed Header = 3 | 1493 -----------------------, = 40 + n/2 + comps_n 1494 Name | 1 + | 1495 NameSegments = n/2 + | 1496 | comps_n | 1497 -----------------------' | 1498 T_SHA-256 = 32 | 1499 ------------------------------------' 1501 Figure 27: Estimated size of a compressed CCNx Interest 1503 The size difference is: 1504 16 + 3.5n octets. 1506 For the name "/DE/HH/HAW/BT7", the total size gain is 30 octets, 1507 which is 36% of the uncompressed packet. 1509 A.2.2. Data 1511 Figure 28 depicts the size requirements for a basic, uncompressed 1512 CCNx Data containing an ExpiryTime Message TLV, an HMAC_SHA-256 1513 signature, the signature time and a hash of the shared secret key. 1515 ------------------------------------, 1516 Fixed Header = 8 | 1517 Message = 4 | 1518 ---------------------, | 1519 Name | 4 + | 1520 NameSegments = 4n + | 1521 | comps_n | 1522 ---------------------' | 1523 ExpiryTime = 12 = 124 + 4n + comps_n + clen 1524 Payload = 4 + clen | 1525 ---------------------, | 1526 ValidationAlgorithm | | 1527 T_HMAC-256 = 56 | 1528 KeyId | | 1529 SignatureTime | | 1530 ---------------------' | 1531 ValidationPayload = 36 | 1532 ------------------------------------' 1534 Figure 28: Estimated size of an uncompressed CCNx Data Object 1536 Figure 29 depicts the size requirements for a basic, compressed CCNx 1537 Data. 1539 ------------------------------------, 1540 Dispatch Page Switch = 1 | 1541 LOWPAN_CCNX_DATA_HC = 2 | 1542 LOWPAN_CCNX_DATA_HC_MSG = 1 | 1543 LOWPAN_CCNX_DATA_HC_VAL = 1 | 1544 Fixed Header = 2 | 1545 -----------------------, | 1546 Name | 1 + = 92 + n/2 + comps_n + clen 1547 NameSegments = n/2 + | 1548 | comps_n | 1549 -----------------------' | 1550 ExpiryTime = 8 | 1551 Payload = 1 + clen | 1552 T_HMAC-SHA256 = 32 | 1553 SignatureTime = 8 | 1554 ValidationPayload = 34 | 1555 ------------------------------------' 1557 Figure 29: Estimated size of a compressed CCNx Data Object 1559 The size difference is: 1560 32 + 3.5n octets. 1562 For the name "/DE/HH/HAW/BT7", the total size gain is 46 octets. 1564 Acknowledgments 1566 Authors' Addresses 1568 Cenk Gundogan 1569 HAW Hamburg 1570 Berliner Tor 7 1571 Hamburg D-20099 1572 Germany 1574 Phone: +4940428758067 1575 EMail: cenk.guendogan@haw-hamburg.de 1576 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 1578 Thomas C. Schmidt 1579 HAW Hamburg 1580 Berliner Tor 7 1581 Hamburg D-20099 1582 Germany 1584 EMail: t.schmidt@haw-hamburg.de 1585 URI: http://inet.haw-hamburg.de/members/schmidt 1586 Matthias Waehlisch 1587 link-lab & FU Berlin 1588 Hoenower Str. 35 1589 Berlin D-10318 1590 Germany 1592 EMail: mw@link-lab.net 1593 URI: http://www.inf.fu-berlin.de/~waehl 1595 Christopher Scherb 1596 University of Basel 1597 Spiegelgasse 1 1598 Basel CH-4051 1599 Switzerland 1601 EMail: christopher.scherb@unibas.ch 1603 Claudio Marxer 1604 University of Basel 1605 Spiegelgasse 1 1606 Basel CH-4051 1607 Switzerland 1609 EMail: claudio.marxer@unibas.ch 1611 Christian Tschudin 1612 University of Basel 1613 Spiegelgasse 1 1614 Basel CH-4051 1615 Switzerland 1617 EMail: christian.tschudin@unibas.ch