idnits 2.17.1 draft-gundogan-icnrg-ccnlowpan-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2018) is 2111 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'CCN-LITE' is defined on line 1264, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 1273, 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 (~~), 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: January 17, 2019 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 July 16, 2018 13 ICN Adaptation to LowPAN Networks (ICN LoWPAN) 14 draft-gundogan-icnrg-ccnlowpan-02 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 and stateful 28 compression 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 January 17, 2019. 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 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 6 67 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 8 68 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 8 69 4.2. Link Fragmentation . . . . . . . . . . . . . . . . . . . 9 70 4.3. Integrating Stateful Header Compression . . . . . . . . . 10 71 5. ICN LoWPAN for NDN . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 11 73 5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 13 74 5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 14 75 5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 16 76 6. ICN LoWPAN for CCNx . . . . . . . . . . . . . . . . . . . . . 18 77 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 18 78 6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 18 79 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 18 80 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 24 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 8.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . . 27 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 86 9.2. Informative References . . . . . . . . . . . . . . . . . 28 87 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 30 88 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 30 90 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 31 91 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 33 92 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 33 93 A.2.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 34 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 97 1. Introduction 99 The Internet of Things (IoT) has been identified as a promising 100 deployment area for Information Centric Networks (ICN), as 101 infrastructureless access to content, resilient forwarding, and in- 102 network data replication have shown noteable advantages over the 103 traditional host-to-host approach on the Internet [NDN-EXP]. Recent 104 studies [NDN-MAC] have shown that an appropriate mapping to link 105 layer technologies has a large impact on the practical performance of 106 an ICN. This will be even more relevant in the context of IoT 107 communication where nodes often exchange messages via low-power 108 wireless links under lossy conditions. In this memo, we address the 109 base adaptation of data chunks to such link layers for the ICN 110 flavors NDN [NDN] and CCNx. 112 The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and 113 lossy networks (see "LLN" in [RFC7228]), in which devices are 114 typically battery-operated and constrained in resources. 115 Characteristics of LLNs include an unreliable environment, low 116 bandwidth transmissions, and increased latencies. IEEE 802.15.4 117 admits a maximum physical layer packet size of 127 octets. The 118 maximum frame header size is 25 octets, which leaves 102 octets for 119 the payload. IEEE 802.15.4 security features further reduce this 120 payload length by up to 21 octets, yielding a net of 81 octets for 121 CCNx or NDN packet headers, signatures and content. 123 6LoWPAN [RFC4944][RFC6282] is a convergence layer that provides frame 124 formats, header compression and link fragmentation for IPv6 packets 125 in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a 126 dispatching framework that prepends further information to 6LoWPAN 127 packets, including a protocol identifier for IEEE 802.15.4 payload 128 and meta information about link fragmentation. 130 Prevalent Type-Length-Value (TLV) based packet formats such as in 131 CCNx and NDN are designed to be generic and extensible. This leads 132 to header verbosity which is inappropriate in constrained 133 environments of IEEE 802.15.4 links. This document presents ICN 134 LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN 135 that compresses packet headers of CCNx as well as NDN and allows for 136 an increased payload size per packet. Additionally by reusing the 137 dispatching framwork defined by 6LoWPAN, compatibility between 138 coexisting wireless networks of competing technologies is enabled. 139 This also allows to reuse the link fragmentation scheme specified by 140 6LoWPAN for ICN LoWPAN. 142 ICN LoWPAN utilizes a more space efficient representation of CCNx and 143 NDN packet formats. This syntactic change is described for CCNx and 144 NDN separately, as the header formats and TLV encodings differ 145 largely. For further reductions, default header values suitable for 146 constrained IoT networks are selected in order to elide corresponding 147 TLVs. 149 In a typical IoT scenario (see Figure 1), embedded devices are 150 interconnected via quasi-stationary infrastructure whith a border 151 router (BR) interconnecting the constrained LoWPAN networks via some 152 Gateway with the public Internet. In ICN based IoT networks, 153 Interest and Data messages transparently travel through the BR up and 154 down between a Gateway and the embedded devices within the 155 constrained LoWPANs. 157 |Gateway Services| 158 ------------------------- 159 | 160 ,--------, 161 | | 162 | BR | 163 | | 164 '--------' 165 LoWPAN 166 O O 167 O 168 O O embedded 169 O O O devices 170 O O 172 Figure 1: IoT Stub Network 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 The use of the term, "silently ignore" is not defined in RFC 2119. 180 However, the term is used in this document and can be similarly 181 construed. 183 This document uses the terminology of [RFC7476], [RFC7927], and 184 [RFC7945] for ICN entities. 186 The following terms are used in the document and defined as follows: 188 ICN LoWPAN: Information-Centric Networking over Low-power Wireless 189 Personal Area Network 191 LLN Low-Power and Lossy Network 193 CCNx: Content-Centric Networking Architecture 195 NDN: Named Data Networking 197 3. Overview of ICN LoWPAN 199 3.1. Link-Layer Convergence 201 ICN LoWPAN provides a convergence layer that maps ICN packets onto 202 constrained link-layer technologies. This includes features such as 203 link-layer fragmentation, protocol separation on the link-layer 204 level, and link-layer address mappings. The stack traversal is 205 visualized in Figure 2. 207 Device 1 Device 2 208 ,------------------, Router ,------------------, 209 | Application . | __________________ | ,-> Application | 210 |----------------|-| | NDN / CCNx | |-|----------------| 211 | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | 212 |----------------|-| |-|--------------|-| |-|----------------| 213 | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | 214 |----------------|-| |-|--------------|-| |-|----------------| 215 | Link-Layer | | | | Link-Layer | | | | Link-Layer | 216 '----------------|-' '-|--------------|-' '-|----------------' 217 '--------' '---------' 219 Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 221 Section 4 of this document defines the convergence layer for IEEE 222 802.15.4. 224 3.2. Stateless Header Compression 226 ICN LoWPAN also defines a stateless header compression scheme with 227 the main purpose of reducing header overhead of ICN packets. This is 228 of particular importance for link-layers with small MTUs. The 229 stateless compression does not require pre-configuration of global 230 state. 232 The CCNx and NDN header formats are composed of Type-Length-Value 233 (TLV) fields to encode header data. The advantage of TLVs is its 234 native support of variable-sized data. The main disadvantage of TLVs 235 is the verbosity that results from storing the type and length of the 236 encoded data. 238 The stateless header compression scheme makes use of compact bit 239 fields to indicate the presence of mandatory and optional TLVs in the 240 uncompressed packet. The order of set bits in the bit fields 241 corresponds to the order of each TLV in the packet. Further 242 compression is achieved by specifying default values and reducing the 243 codomain of certain header fields. 245 Figure 3 demonstrates the stateless header compression idea. In this 246 example, the first type of the first TLV is removed and the 247 corresponding bit in the bit field is set. The second TLV represents 248 a fixed-length TLV (e.g. the Nonce TLV in NDN), so that the type and 249 the length fields are removed. The third TLV represents a boolean 250 TLV (e.g. the MustBeFresh selector in NDN) and is missing the type, 251 length and the value field. 253 +---+---+---+---+---+---+---+---+ 254 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field 255 +---+---+---+---+---+---+---+---+ 256 | | | 257 ,--' '-----------, '- boolean 258 | | 259 +-------+--------------+-------------+ 260 | LEN | VALUE | VALUE | 261 +-------+--------------+-------------+ 263 Figure 3: Compression using a compact bit field to encode context 264 information. 266 3.3. Stateful Header Compression 268 ICN LoWPAN further employs 2 stateful compression schemes to enhance 269 size reductions. These mechanisms rely on shared contexts that are 270 either distributed and maintained in the whole LoWPAN, or are 271 generated on-demand for a particular Interest-data path. 273 3.3.1. LoWPAN-local State 275 A context identifier (CID) is a 1-octet wide number that refers to a 276 particular conceptual context between network devices and MAY be used 277 to replace frequently appearing information, like name prefixes, 278 suffixes, or meta information, such as Interest lifetime. 280 The initial distribution and maintenance of shared context is out of 281 scope. Frames containing unknown or invalid CIDs are silently 282 discarded. 284 3.3.2. En-route State 286 In CCNx and NDN, Name TLVs are included in Interest messages, and 287 they return in data messages. Returning Name TLVs either equal to 288 the original Name TLV, or they contain the original Name TLV as a 289 prefix. ICN LoWPAN reduces this duplication in responses by 290 replacing Name TLVs with 1-octet wide HopIDs. While an Interest is 291 forwarded, each hop generates an ephemeral HopID that is tied to a 292 PIT entry. Each HopID MUST be unique within the local PIT and only 293 exist during the lifetime of a PIT entry. To maintain HopIDs, the 294 local PIT is extended by two new columns: HIDi (inbound HopIDs) and 295 HIDo (outbound HopIDs). 297 HopIDs are included in Interests and stored on the next hop with the 298 resulting PIT entry in the HIDi column. The HopID is replaced with a 299 newly generated local HopID before the Interest is forwarded. This 300 new HopID is stored in the HIDo column of the local PIT (see 301 Figure 4). 303 PIT of B PIT Extension PIT of C PIT Extension 304 +--------+------++------+------+ +--------+------++------+------+ 305 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 306 +========+======++======+======+ +========+======++======+======+ 307 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 308 +--------+------++------+------+ +--------+------++------+------+ 309 ^ | ^ 310 store | '----------------------, ,---' store 311 | send v | 312 ,---, /p0, h_A ,---, /p0, h_B ,---, 313 | A | ------------------------> | B | ------------------------> | C | 314 '---' '---' '---' 316 Figure 4: Setting compression state en-route (Interest). 318 Responses include HopIDs that were obtained from Interests. If the 319 returning Name TLV equals the original Name TLV, then the name is 320 elided fully. Otherwise, the distinct suffix is included along with 321 the HopID. When a response is forwarded, the contained HopID is 322 extracted and used to match against the correct PIT entry by 323 performing a lookup on the HIDo column. The HopID is then replaced 324 with the corresponding HopID from the HIDi column before forwarding 325 the reponse (Figure 5). 327 PIT of B PIT Extension PIT of C PIT Extension 328 +--------+------++------+------+ +--------+------++------+------+ 329 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 330 +========+======++======+======+ +========+======++======+======+ 331 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 332 +--------+------++------+------+ +--------+------++------+------+ 333 | ^ | 334 send | '----------------------, ,---' send 335 v match | v 336 ,---, h_A ,---, h_B ,---, 337 | A | <------------------------ | B | <------------------------ | C | 338 '---' '---' '---' 340 Figure 5: Eliding Name TLVs using en-route state (data). 342 4. IEEE 802.15.4 Adaptation 344 4.1. LoWPAN Encapsulation 346 The IEEE 802.15.4 frame header does not provide a protocol identifier 347 for its payload. This causes problems of misinterpreting frames when 348 several networks coexist on the same link layer. To mitigate errors, 349 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 350 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation 351 headers can prepend the actual payload and each encapsulation header 352 is identified by a dispatch type. 354 [RFC8025] further specifies dispatch pages to switch between 355 different contexts. When a LoWPAN parser encounters a "Page switch" 356 LoWPAN encapsulation header, then all following encapsulation headers 357 are interpreted by using a dispatch table as specified by the "Page 358 switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This 359 document uses page 2 ("1111 0010 (0xF2)") for NDN and page 3 ("1111 360 0011 (0xF3)") for CCNx. 362 The base dispatch format (Figure 6) is used and extended by CCNx and 363 NDN in Section 5 and Section 6. 365 0 1 2 ... 7 366 +---+---+-----------------------+ 367 | C | M | | 368 +---+---+-----------------------+ 370 Figure 6: Base dispatch format for NDN 372 C: Compression 374 0: The message is uncompressed. 376 1: The message is compressed. 378 M: Message Type 380 0: The payload contains a Interest message. 382 1: The payload contains a Data message. 384 The encapsulation format for ICN LoWPAN identifying an NDN Interest 385 message is exemplarily displayed in Figure 7. 387 +---------------+------------+--------+----------------+-------+ 388 | IEEE 802.15.4 | Dispatches | Page 2 | NDN Dispatches | Payl. / 389 +---------------+------------+--------+----------------+-------+ 391 Figure 7: LoWPAN Encapsulation of NDN Interest with ICN LoWPAN 393 IEEE 802.15.4: The IEEE 802.15.4 header. 395 Dispatches: Optional additional dispatch types. 397 Page 2: Page Switch 2 (0xF2) for NDN. 399 NDN Dispatches: NDN dispatches as defined in Section 5. 401 Payload: The actual (un-)compressed NDN Interest. 403 4.2. Link Fragmentation 405 Section 5.3 of [RFC4944] defines a protocol independent fragmentation 406 dispatch type, a fragmentation header for the first fragment and a 407 separate fragmentation header for subsequent fragments. ICN LoWPAN 408 adopts the fragmentation handling of [RFC4944]. 410 The Fragmentation LoWPAN header can encapsulate other dispatch 411 headers. The order of dispatch types is adopted from [RFC4944]. 412 Figure 8 shows the fragmentation scheme. The reassembled ICN LoWPAN 413 frame does not contain any fragmentation headers and is depicted in 414 Figure 9. 416 +---------------+-----------+--------+----------------+-------------+ 417 | IEEE 802.15.4 | Frag. 1st | Page 2 | ICN LoWPAN | Payload ... / 418 +---------------+-----------+--------+----------------+-------------+ 420 +---------------+-----------+-------------+ 421 | IEEE 802.15.4 | Frag. 2nd | ... Payload / 422 +---------------+-----------+-------------+ 424 . 425 . 426 . 428 +---------------+-----------+-------------+ 429 | IEEE 802.15.4 | Frag. Nth | ... Payload / 430 +---------------+-----------+-------------+ 432 Figure 8: Fragmentation scheme 434 +---------------+--------+----------------+---------+ 435 | IEEE 802.15.4 | Page 2 | ICN LoWPAN | Payload / 436 +---------------+--------+----------------+---------+ 438 Figure 9: Reassembled ICN LoWPAN frame 440 4.3. Integrating Stateful Header Compression 442 4.3.1. LoWPAN-Local State 444 A CID is appended to the last ICN LoWPAN dispatch octet. Multiple 445 CIDs are chained together, whereas the most significant bit indicates 446 the presence of a subsequent CID (Figure 10). 448 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 449 |1| CID | --> |1| CID | --> |0| CID | 450 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 452 Figure 10: Multiple 1-octet wide context identifiers. 454 4.3.2. En-Route State 456 The HopID is included as the very first CID. To distinguish the 457 HopID from a typical LoWPAN-local CID, the 1st bit MUST be set 458 (Figure 11). This yields 64 distinct HopIDs. If this range (0..63) 459 is exhausted, the messages MUST be sent without en-route state 460 compression until new HopIDs are available. 462 0 1 2 3 4 5 6 7 463 +---+---+---+---+---+---+---+---+ 464 | X | 1 | HopID | 465 +---+---+---+---+---+---+---+---+ 467 Figure 11: Context Identifier as HopID. 469 5. ICN LoWPAN for NDN 471 5.1. TLV Encoding 473 The NDN packet format consists of TLV fields using the TLV encoding 474 that is described in [NDN-PACKET-SPEC]. Type and length fields are 475 of variable size, where numbers greater than 252 are encoded using 476 multiple octets. Figure 12 shows the NDN TLV encoding scheme. 478 If the type or length number is less than "253", then that number is 479 encoded into the actual type or length field (Figure 12 a). If the 480 number is greater or equals "253" and fits into 2 octets, then the 481 type or lengh field is set to "253" and the number is encoded in the 482 next following 2 octets in network byte order, i.e., from the most 483 significant byte (MSB) to the least significant byte (LSB) (Figure 12 484 b). If the number is greater than 2 octets and fits into 4 octets, 485 then the type or length field is set to "254" and the number is 486 encoded in the subsequent 4 octets in network byte order (Figure 12 487 c). For greater numbers, the type or length field is set to "255" 488 and the number is encoded in the subsequent 8 octets in network byte 489 order (Figure 12 d). 491 0 1 2 3 4 5 6 7 492 +-+-+-+-+-+-+-+-+ 493 a) | < 253 | 494 +-+-+-+-+-+-+-+-+ 496 0 1 2 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 b) | 253 | MSB LSB | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | 254 | MSB / 506 c) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | LSB | 508 +-+-+-+-+-+-+-+-+ 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | 255 | MSB / 514 +-+-+-+-+-+-+-+-+ + 515 d) | / 516 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | LSB | 518 +-+-+-+-+-+-+-+-+ 520 Figure 12: NDN TLV encoding scheme 522 In this document, compressed NDN TLVs make use of a different TLV 523 scheme that puts more emphasis on size reduction. Instead of using 524 the first octet as a marker for the number of following octets, the 525 compressed NDN TLV scheme uses a method to chain a variable number of 526 octets together. If an octet equals "255 (0xFF)", then the following 527 octet will also be interpreted. The actual value of a chain equals 528 the sum of all links. 530 If the type or length number is less than "255", then that number is 531 encoded into the actual type or length field (Figure 13 a). If the 532 type or length number (X) fits into 2 octets, then the first octet is 533 set to "255" and the subsequent octet equals "X mod 255" (Figure 13 534 b). Following this scheme, a variable-sized number (X) is encoded 535 using multiple octets of "255" with a trailing octet containing "X 536 mod 255" (Figure 13 c). 538 0 1 2 3 4 5 6 7 539 +-+-+-+-+-+-+-+-+ 540 a) | < 255 (X) | = X 541 +-+-+-+-+-+-+-+-+ 543 0 1 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 b) | 255 | < 255 (X) | = 255 + X 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 0 550 0 1 2 3 4 5 6 7 551 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 552 c) | 255 | 255 | < 255 (X) | = (N * 255) + X 553 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 554 (N - 1) 556 Figure 13: Compressed NDN TLV encoding scheme 558 5.2. Name TLV Compression 560 This Name TLV compression encodes length fields of two consecutive 561 NameComponent TLVs into one octet, using 4 bits each. This process 562 limits the length of a NameComponent TLV to 15 octets. A length of 0 563 marks the end of the compressed Name TLV. 565 Name: /HAW/Room/481/Humid/99 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |0 0 1 1|0 1 0 0| H | A | W | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | R | o | o | m | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | H | u | m | i | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | d |0 0 1 0|0 0 0 0| 9 | 9 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 14: Name TLV compression for /HAW/Room/481/Humid/99 583 5.3. Interest Messages 585 5.3.1. Uncompressed Interest Messages 587 An uncompressed Interest message uses the base dispatch format (see 588 Figure 6) and sets the C as well as the M flag to "0" (Figure 15). 589 "resv" MUST be set to 0. The Interest message is handed to the NDN 590 network stack without modifications. 592 0 1 2 ... 7 593 +---+---+-----------------------+ 594 | 0 | 0 | resv | 595 +---+---+-----------------------+ 597 Figure 15: Dispatch format for uncompressed NDN Interest messages 599 5.3.2. Compressed Interest Messages 601 The compressed Interest message uses the base dispatch format and 602 sets the C flag to "1" and the M flag to "0". By default, the 603 Interest message is compressed with the following base rule set: 605 1. The "Type" field of the outermost MessageType TLV is removed. 607 2. The Name TLV is compressed according to Section 5.2. For this, 608 all NameComponents are expected to be of type 609 GenericNameComponent. Otherwise, the message MUST be sent 610 uncompressed. 612 3. The InterestLifetime TLV length is set to 2. Messages with 613 lifetimes that require more than 2 octets MUST be sent 614 uncompressed. 616 4. The Nonce TLV, InterestLifetime TLV and HopLimit TLV MUST be 617 moved to the end of the compressed Interest, keeping the order 1) 618 Nonce TLV, 2) InterestLifetime TLV and 3) HopLimit TLV. 620 5. The Type and Length fields of Nonce TLV, InterestLifetime TLV and 621 HopLimit TLV are elided. The presence of each TLV is deduced 622 from the remaining length to parse. The Nonce TLV has a fixed 623 length of 4, the InterestLifetime TLV has a fixed length of 2 and 624 the HopLimit TLV has a fixed length of 1. Any combination yields 625 a distinct value that matches the remaining length to parse. 627 Further TLV compression is indicated by the ICN LoWPAN dispatch in 628 Figure 16. 630 0 1 2 3 4 5 6 7 631 +---+---+---+---+---+---+---+---+ 632 | 1 | 0 |DIG|PFX|FRE|FWD|PRM|CID| 633 +---+---+---+---+---+---+---+---+ 635 Figure 16: Dispatch format for compressed NDN Interest messages 637 DIG: ImplicitSha256DigestComponent TLV 639 0: The name does not include an 640 ImplicitSha256DigestComponent as the last TLV. 642 1: The name does include an 643 ImplicitSha256DigestComponent as the last TLV. The 644 Type and Length fields are omitted. 646 PFX: CanBePrefix TLV 648 0: The uncompressed message does not include a 649 CanBePrefix TLV. 651 1: The uncompressed message does include a CanBePrefix 652 TLV and is removed from the compressed message. 654 FRE: MustBeFresh TLV 656 0: The uncompressed message does not include a 657 MustBeFresh TLV. 659 1: The uncompressed message does include a MustBeFresh 660 TLV and is removed from the compressed message. 662 FWD: ForwardingHint TLV 664 0: The uncompressed message does not include a 665 ForwardingHint TLV. 667 1: The uncompressed message does include a 668 ForwardingHint TLV. The Type field is removed from 669 the compressed message. 671 PRM: Parameters TLV 673 0: The uncompressed message does not include a 674 Parameters TLV. 676 1: The uncompressed message does include a Parameters 677 TLV. The Type field is removed from the compressed 678 message. 680 CID: Context Identifiers 682 0: CID(s) are not appended to the dispatch octet. 684 1: CID(s) are appended to the dispatch octet. 686 5.4. Data Messages 688 5.4.1. Uncompressed Data Messages 690 An uncompressed Data message uses the base dispatch format and sets 691 the C flag to "0" and the M flag to "1" (Figure 17). "resv" MUST be 692 set to 0. The Data message is handed to the NDN network stack 693 without modifications. 695 0 1 2 ... 7 696 +---+---+-----------------------+ 697 | 0 | 1 | resv | 698 +---+---+-----------------------+ 700 Figure 17: Dispatch format for uncompressed NDN Data messages 702 5.4.2. Compressed Data Messages 704 The compressed Data message uses the base dispatch format and sets 705 the C flag as well as the M flag to "1". By default, the Data 706 message is compressed with the following base rule set: 708 1. The "Type" field of the outermost MessageType TLV is removed. 710 2. The Name TLV is compressed according to Section 5.2. For this, 711 all NameComponents are expected to be of type 712 GenericNameComponent. Otherwise, the message MUST be sent 713 uncompressed. 715 3. The MetaInfo Type and Length fields are elided from the 716 compressed Data message. 718 4. If present, the FinalBlockId TLV is encoded according to 719 Section 5.2. 721 5. The ContentType TLV length is set to 1. Messages with 722 ContentTypes that require more than 1 octet MUST be sent 723 uncompressed. 725 6. The FreshnessPeriod TLV length is set to 2. Messages with 726 FreshnessPeriods that require more than 2 octets MUST be sent 727 uncompressed. 729 7. The FreshnessPeriod TLV and ContntType TLV MUST be moved to the 730 end of the compressed Data, keeping the order 1) FreshnessPeriod 731 TLV and 2) ContentType TLV. 733 8. The Type and Length fields of ContentType TLV and FreshnessPeriod 734 TLV are elided. The presence of each TLV is deduced from the 735 remaining length to parse. The FreshnessPeriod TLV has a fixed 736 length of 2 and the ContentType TLV has a fixed length of 1. Any 737 combination yields a distinct value that matches the remaining 738 length to parse. 740 Further TLV compression is indicated by the ICN LoWPAN dispatch in 741 Figure 18. 743 0 1 2 3 4 5 6 7 744 +---+---+---+---+---+---+---+---+ 745 | 1 | 1 |DIG|FBI|CON| SIG |CID| 746 +---+---+---+---+---+---+---+---+ 748 Figure 18: Dispatch format for compressed NDN Data messages 750 DIG: ImplicitSha256DigestComponent TLV 752 0: The name does not include an 753 ImplicitSha256DigestComponent as the last TLV. 755 1: The name does include an 756 ImplicitSha256DigestComponent as the last TLV. The 757 Type and Length fields are omitted. 759 FBI: FinalBlockId TLV 761 0: The uncompressed message does not include a 762 FinalBlockId TLV. 764 1: The uncompressed message does include a FinalBlockId. 766 CON: Content TLV 768 0: The uncompressed message does not include a Content 769 TLV. 771 1: The uncompressed message does include a Content TLV. 772 The Type field is removed from the compressed 773 message. 775 SIG: Signature TLV 777 00: The Type fields of the SignatureInfo TLV, 778 SignatureType TLV and SignatureValue TLV are removed. 780 01: Reserved. 782 10: Reserved. 784 11: Reserved. 786 CID: Context Identifiers 788 0: CID(s) are not appended to the dispatch octet. 790 1: CID(s) are appended to the dispatch octet. 792 6. ICN LoWPAN for CCNx 794 6.1. TLV Encoding 796 The CCNx TLV encoding is described in [I-D.irtf-icnrg-ccnxmessages]. 797 Type and Length fields are of fixed length of 2 octets each. 799 In this document, the TLV encoding is changed to the more space 800 efficient encoding described in Section 5.1. Type and Length fields 801 MUST be encoded as in Figure 13. 803 6.2. Name TLV Compression 805 Name TLVs are compressed using the same approach outlined in 806 Section 5.2. 808 6.3. Interest Messages 810 6.3.1. Uncompressed Interest Messages 812 An uncompressed Interest message uses the base dispatch format (see 813 Figure 6) and sets the C as well as the M flag to "0" (Figure 19). 814 "resv" MUST be set to 0. The Interest message is handed to the CCNx 815 network stack without modifications. 817 0 1 2 ... 7 818 +---+---+-----------------------+ 819 | 0 | 0 | resv | 820 +---+---+-----------------------+ 822 Figure 19: Dispatch format for uncompressed CCNx Interest messages 824 6.3.2. Compressed Interest Messages 826 The compressed Interest message uses the base dispatch format and 827 sets the C flag to "1" and the M flag to "0". By default, the 828 Interest message is compressed with the following base rule set: 830 1. The Type and Length fields of the CCNx Message TLV are elided and 831 are obtained from the Fixed Header on decompression. 833 Further TLV compression is indicated by the ICN LoWPAN dispatch in 834 Figure 20. 836 0 1 837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 838 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 839 | 1 | 0 |FLG|HBH|PTY|HPL|FRS|MSG|PAY|VAL|EXT| RESVD |CID| 840 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 842 Figure 20: Dispatch format for compressed CCNx Interest messages 844 FLG: Flags field in the Fixed Header 846 0: The Flags field equals 0 and is removed from the Interest 847 message. 849 1: The Flags field is carried in-line. 851 HBH: Optional Hop-By-Hop Header TLVs 853 0: No Hop-By-Hop Header TLVs are present in the Interest 854 message. Also, the HeaderLength field in the fixed 855 header is elided from the Interest message and assumed to 856 be "8". 858 1: Hop-By-Hop Header TLVs are present in the Interest 859 message. An additional octet follows immediately that 860 handles Hop-By-Hop Header TLV compressions and is 861 described in Section 6.3.3. 863 PTY: PacketType field in the fixed header 864 0: The PacketType field is elided and assumed to be 865 "PT_INTEREST" 867 1: The PacketType field is elided and assumed to be 868 "PT_RETURN" 870 HPL: HopLimit field in the fixed header 872 0: The HopLimit field is carried in-line 874 1: The HopLimit field is elided and assumed to be "1" 876 FRS: Reserved field in the fixed header 878 0: The Reserved field is carried in-line 880 1: The Reserved field is elided and assumed to be "0" 882 MSG: Optional Interest Message TLVs 884 0: No Interest Message TLVs are present in the Interest 885 message. 887 1: Interest Message TLVs are present in the Interest 888 message. An additional octet follows immediately that 889 handles Interest Message TLV compressions and is 890 described in Section 6.3.4. 892 PAY: Optional Payload TLV 894 0: The Payload TLV is absent. 896 1: The Payload TLV is present and the type field is elided. 898 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 900 0: No validation related TLVs are present in the Interest 901 message. 903 1: Validation related TLVs are present in the Interest 904 message. An additional octet follows immediately that 905 handles validation related TLV compressions and is 906 described in Section 6.3.5. 908 EXT: Extension 910 0: No extension octet follows. 912 1: An extension octet follows immediately. Extension octets 913 are used to extend the compression scheme, but are out of 914 scope of this document. 916 CID: Context Identifiers 918 0: CID(s) are not appended to the last dispatch octet. 920 1: CID(s) are appended to the last dispatch octet. 922 6.3.3. Hop-By-Hop Header TLVs Compression 924 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 925 optional Hop-By-Hop Header TLVs are defined in 926 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 927 higher level specifications. For better compression, an ordering of 928 Hop-By-Hop TLVs is enforced as follows: 930 1. Interest Lifetime TLV 932 2. Message Hash TLV 934 With this ordering in place, Type fields are elided from the Interest 935 Lifetime TLV and the Message Hash TLV. 937 Note: If the original Interest message includes Hop-By-Hop Header 938 TLVs with a different ordering, then they remain uncompressed. 940 0 1 2 3 4 5 6 7 941 +-------+-------+-------+-------+-------+-------+-------+-------+ 942 | IntLifetime | MsgHash | Reserved | 943 +-------+-------+-------+-------+-------+-------+-------+-------+ 945 Figure 21: Dispatch for HBH Compression 947 IntLifetime: InterstLifetime Hop-By-Hop Header TLV 949 00: The Interest Lifetime TLV is absent. 951 01: The Interest Lifetime TLV is present and the type field 952 is removed. 954 10: The Interest Lifetime TLV is absent and a default value 955 of 0 seconds is assumed. 957 11: The Interest Lifetime TLV is absent and a default value 958 of 10 minutes is assumed. 960 MsgHash: Message Hash Hop-By-Hop Header TLV 962 00: The Message Hash TLV is absent. 964 01: The Message Hash TLV is present and uncompressed. 966 10: A T_SHA-256 TLV is present and the type field as well as 967 the length fields are removed. The length field is 968 assumed to represent 32 octets. The outer Message Hash 969 TLV is omitted. 971 11: A T_SHA-512 TLV is present and the type field as well as 972 the length fields are removed. The length field is 973 assumed to represent 64 octets. The outer Message Hash 974 TLV is omitted. 976 6.3.4. Interest Message TLVs Compression 978 0 1 2 3 4 5 6 7 979 +-------+-------+-------+-------+-------+-------+-------+-------+ 980 | KeyIDRestr | CObHRestr | Reserved | 981 +-------+-------+-------+-------+-------+-------+-------+-------+ 983 Figure 22: Dispatch for Interest Messages 985 KeyIDRestr: Optional KeyIdRestriction TLV within a CCNx Message TLV 987 00: The KeyIdRestriction TLV is absent. 989 01: The KeyIdRestriction TLV is present and uncompressed. 991 10: A T_SHA-256 TLV is present and the type field as well as 992 the length fields are removed. The length field is 993 assumed to represent 32 octets. The outer 994 KeyIdRestriction TLV is omitted. 996 11: A T_SHA-512 TLV is present and the type field as well as 997 the length fields are removed. The length field is 998 assumed to represent 64 octets. The outer 999 KeyIdRestriction TLV is omitted. 1001 CObHRestr: Optional ContentObjectHashRestriction TLV within a CCNx 1002 Message TLV 1004 00: The ContentObjectHashRestriction TLV is absent. 1006 01: The ContentObjectHashRestriction TLV is present and 1007 uncompressed. 1009 10: A T_SHA-256 TLV is present and the type field as well as 1010 the length fields are removed. The length field is 1011 assumed to represent 32 octets. The outer 1012 ContentObjectHashRestriction TLV is omitted. 1014 11: A T_SHA-512 TLV is present and the type field as well as 1015 the length fields are removed. The length field is 1016 assumed to represent 64 octets. The outer 1017 ContentObjectHashRestriction TLV is omitted. 1019 6.3.5. Validation 1021 0 1 2 3 4 5 6 7 8 1022 +-------+-------+-------+-------+-------+-------+-------+-------+ 1023 | ValidationAlg | KeyID | Reserved | 1024 +-------+-------+-------+-------+-------+-------+-------+-------+ 1026 Figure 23: Dispatch for Interset Validations 1028 ValidationALg: Optional ValidationAlgorithm TLV 1030 0000: An uncompressed ValidationAlgorithm TLV is included. 1032 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1033 ValidationAlgorithm TLV is included. 1035 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1036 ValidationAlgorithm TLV is included. Additionally, a 1037 Sigtime TLV is inlined without a type and a length field. 1039 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1040 no ValidationAlgorithm TLV is included. 1042 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1043 no ValidationAlgorithm TLV is inclued. Additionally, a 1044 Sigtime TLV is inlined without a type and a length field. 1046 0101: Reserved. 1048 0110: Reserved. 1050 0111: Reserved. 1052 1000: Reserved. 1054 1001: Reserved. 1056 1010: Reserved. 1058 1011: Reserved. 1060 1100: Reserved. 1062 1101: Reserved. 1064 1110: Reserved. 1066 1111: Reserved. 1068 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1070 00: The KeyId TLV is absent. 1072 01: The KeyId TLV is present and uncompressed. 1074 10: A T_SHA-256 TLV is present and the type field as well as 1075 the length fields are removed. The length field is 1076 assumed to represent 32 octets. The outer KeyId TLV is 1077 omitted. 1079 11: A T_SHA-512 TLV is present and the type field as well as 1080 the length fields are removed. The length field is 1081 assumed to represent 64 octets. The outer KeyId TLV is 1082 omitted. 1084 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1085 is present. The type field is omitted. 1087 6.4. Content Objects 1089 6.4.1. Uncompressed Content Objects 1091 An uncompressed Content object uses the base dispatch format (see 1092 Figure 6) and sets the C flag to "0" and the M flag to "1" 1093 (Figure 24). "resv" MUST be set to 0. The Content object is handed 1094 to the CCNx network stack without modifications. 1096 0 1 2 ... 7 1097 +---+---+-----------------------+ 1098 | 0 | 1 | resv | 1099 +---+---+-----------------------+ 1101 Figure 24: Dispatch format for uncompressed CCNx Content objects 1103 6.4.2. Compressed Content Objects 1105 The compressed Content object uses the base dispatch format and sets 1106 the C flag as well as the M flag to "1". By default, the Content 1107 object is compressed with the following base rule set: 1109 1. The PacketType field is elided from the Fixed Header. 1111 2. The Type and Length fields of the CCNx Message TLV are elided and 1112 are obtained from the Fixed Header on decompression. 1114 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1115 Figure 25. 1117 0 1 1118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1119 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1120 | 1 | 1 |FLG|HBH|FRS|MSG|PAY|VAL|EXT| RESVD |CID| 1121 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1123 Figure 25: Dispatch format for compressed CCNx Content objects 1125 FLG: Flags field in the fixed header See Section 6.3.2. 1127 HBH: Optional Hop-By-Hop Header TLVs 1129 0: No Hop-By-Hop Header TLVs are present in the Content 1130 Object message. Also, the HeaderLength field in the 1131 fixed header is elided from the Content Object message 1132 and assumed to be "8". 1134 1: Hop-By-Hop Header TLVs are present in the Content Object 1135 message. An additional octet follows immediately that 1136 handles Hop-By-Hop Header TLV compressions and is 1137 described in Section 6.4.3. 1139 FRS: Reserved field in the Fixed Header See Section 6.3.2. 1141 MSG: Optional Content Object Message TLVs 1143 0: No Content Object Message TLVs are present in the Content 1144 Object message. 1146 1: Content Object Message TLVs are present in the Content 1147 Object message. An additional octet follows immediately 1148 that handles Content Object Message TLV compressions and 1149 is described in Section 6.4.4. 1151 PAY: Optional Payload TLV See Section 6.3.2. 1153 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1154 tion 6.3.2. 1156 EXT: Extension See Section 6.3.2. 1158 CID: Context Identifiers 1160 0: CID(s) are not appended to the last dispatch octet. 1162 1: CID(s) are appended to the last dispatch octet. 1164 6.4.3. Hop-By-Hop Header TLVs Compression 1166 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1167 two optional Hop-By-Hop Header TLVs are defined in 1168 [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in 1169 higher level specifications. For better compression, an ordering of 1170 Hop-By-Hop TLVs is enforced as follows: 1172 1. Recommended Cache Time TLV 1174 2. Message Hash TLV 1176 With this ordering in place, Type fields are elided from the 1177 Recommended Cache Time TLV and Message Hash TLV. 1179 Note: If the original Content Object message includes Hop-By-Hop 1180 Header TLVs with a different ordering, then they remain uncompressed. 1182 0 1 2 3 4 5 6 7 1183 +-------+-------+-------+-------+-------+-------+-------+-------+ 1184 | RCT | MsgHash | Reserved | 1185 +-------+-------+-------+-------+-------+-------+-------+-------+ 1187 Figure 26: Dispatch for HBH Compression 1189 RCT: Recommended Cache Time Hop-By-Hop Header TLV 1191 0: The Recommended Cache Time TLV is absent. 1193 1: The Recommended Cache Time TLV is present and the type as 1194 well as the length fields are elided. 1196 MsgHash: Message Hash Hop-By-Hop Header TLV See Section 6.3.3. 1198 6.4.4. Content Object Message TLVs Compression 1200 0 1 2 3 4 5 6 7 1201 +-------+-------+-------+-------+-------+-------+-------+-------+ 1202 | PayloadType |ExpTime| Reserved | 1203 +-------+-------+-------+-------+-------+-------+-------+-------+ 1205 Figure 27: Dispatch for Message TLVs 1207 PayloadType: Optional PayloadType TLV within a CCNx Message TLV 1209 00: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA is 1210 assumed. 1212 01: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY is 1213 assumed. 1215 10: The PayloadType TLV is absent and T_PAYLOADTYPE_LINK is 1216 assumed. 1218 11: The PayloadType TLV is present and uncompressed. 1220 ExpTime: Optional ExpiryTime TLV within a CCNx Message TLV 1222 0: The ExpiryTime TLV is absent. 1224 1: The ExpiryTime TLV is present and the type as well as the 1225 length fields are elided. 1227 7. Security Considerations 1229 TODO 1231 8. IANA Considerations 1233 8.1. Page Switch Dispatch Type 1235 This document makes use of "Page 2" from the existing paging 1236 dispatches in [RFC8025]. 1238 9. References 1240 9.1. Normative References 1242 [ieee802.15.4] 1243 IEEE Computer Society, "IEEE Std. 802.15.4-2015", April 1244 2016, . 1247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1248 Requirement Levels", BCP 14, RFC 2119, 1249 DOI 10.17487/RFC2119, March 1997, 1250 . 1252 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1253 "Transmission of IPv6 Packets over IEEE 802.15.4 1254 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1255 . 1257 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1258 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1259 DOI 10.17487/RFC6282, September 2011, 1260 . 1262 9.2. Informative References 1264 [CCN-LITE] 1265 "CCN-lite: A lightweight CCNx and NDN implementation", 1266 . 1268 [I-D.irtf-icnrg-ccnxmessages] 1269 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1270 Format", draft-irtf-icnrg-ccnxmessages-08 (work in 1271 progress), July 2018. 1273 [I-D.irtf-icnrg-ccnxsemantics] 1274 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1275 draft-irtf-icnrg-ccnxsemantics-09 (work in progress), June 1276 2018. 1278 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1279 "Networking Named Content", 5th Int. Conf. on emerging 1280 Networking Experiments and Technologies (ACM CoNEXT), 1281 2009, . 1283 [NDN-EXP] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1284 Waehlisch, "Information Centric Networking in the IoT: 1285 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1286 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1287 77-86, September 2014, 1288 . 1290 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1291 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1292 in NDN: Towards Quantifying the Resource Gain", Proc. of 1293 4th ACM Conf. on Information-Centric Networking (ICN- 1294 2017) ACM DL, pp. 36-42, September 2017, 1295 . 1297 [NDN-PACKET-SPEC] 1298 "NDN Packet Format Specification", 1299 . 1301 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1302 Constrained-Node Networks", RFC 7228, 1303 DOI 10.17487/RFC7228, May 2014, 1304 . 1306 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1307 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1308 "Information-Centric Networking: Baseline Scenarios", 1309 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1310 . 1312 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1313 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1314 "Information-Centric Networking (ICN) Research 1315 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1316 . 1318 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1319 and G. Boggia, "Information-Centric Networking: Evaluation 1320 and Security Considerations", RFC 7945, 1321 DOI 10.17487/RFC7945, September 2016, 1322 . 1324 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1325 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1326 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1327 . 1329 Appendix A. Estimated Size Reduction 1331 In the following a theoretical evaluation is given to estimate the 1332 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1334 We assume that "n" is the number of name components, "comps_n" 1335 denotes the sum of n name component lengths. We also assume that the 1336 length of each name component is lower than 16 bytes. The length of 1337 the content is given by "clen". The lengths of TLV components is 1338 specific to the CCNx or NDN encoding and outlined below. 1340 A.1. NDN 1342 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1343 the 1 octet form of each TLV component is assumed. A typical TLV 1344 component therefore is of size 2 (type field + length field) + the 1345 actual value. 1347 A.1.1. Interest 1349 Figure 28 depicts the size requirements for a basic, uncompressed NDN 1350 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1351 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1352 Numbers below represent the amount of octets. 1354 ------------------------------------, 1355 Interest TLV = 2 | 1356 ---------------------, | 1357 Name | 2 + | 1358 NameComponents = 2n + | 1359 | comps_n | 1360 ---------------------' = 21 + 2n + comps_n 1361 CanBePrefix = 2 | 1362 MustBeFresh = 2 | 1363 Nonce = 6 | 1364 InterestLifetime = 4 | 1365 HopLimit = 3 | 1366 ------------------------------------' 1368 Figure 28: Estimated size of an uncompressed NDN Interest 1370 Figure 29 depicts the size requirements after compression. 1372 ------------------------------------, 1373 Dispatch Page Switch = 1 | 1374 NDN Interset Dispatch = 1 | 1375 Interest TLV = 1 | 1376 -----------------------, | 1377 Name | = 9 + n/2 + comps_n 1378 NameComponents = n/2 + | 1379 | comps_n | 1380 -----------------------' | 1381 Nonce = 4 | 1382 InterestLifetime = 2 | 1383 ------------------------------------' 1385 Figure 29: Estimated size of a compressed NDN Interest 1387 The size difference is: 1388 12 + 1.5n octets. 1390 For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets, 1391 which is 46% of the uncompressed packet. 1393 A.1.2. Data 1395 Figure 30 depicts the size requirements for a basic, uncompressed NDN 1396 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1397 1 minute is assumed. The value is thereby encoded using 2 octets. 1398 An HMACWithSha256 is assumed as signature. The key locator is 1399 assumed to contain a Name TLV of length klen. 1401 ------------------------------------, 1402 Data TLV = 2 | 1403 ---------------------, | 1404 Name | 2 + | 1405 NameComponents = 2n + | 1406 | comps_n | 1407 ---------------------' | 1408 ---------------------, | 1409 MetaInfo | | 1410 FreshnessPeriod = 6 = 53 + 2n + comps_n + 1411 | | clen + klen 1412 ---------------------' | 1413 Content = 2 + clen | 1414 ---------------------, | 1415 SignatureInfo | | 1416 SignatureType | | 1417 KeyLocator = 41 + klen | 1418 SignatureValue | | 1419 DigestSha256 | | 1420 ---------------------' | 1421 ------------------------------------' 1423 Figure 30: Estimated size of an uncompressed NDN Data 1425 Figure 31 depicts the size requirements for the compressed version of 1426 the above Data packet. 1428 ------------------------------------, 1429 Dispatch Page Switch = 1 | 1430 NDN Data Dispatch = 1 | 1431 -----------------------, | 1432 Name | = 38 + n/2 + comps_n + 1433 NameComponents = n/2 + | clen + klen 1434 | comps_n | 1435 -----------------------' | 1436 Content = 1 + clen | 1437 KeyLocator = 1 + klen | 1438 DigestSha256 = 32 | 1439 FreshnessPeriod = 2 | 1440 ------------------------------------' 1442 Figure 31: Estimated size of a compressed NDN Data 1444 The size difference is: 1445 15 + 1.5n octets. 1447 For the name "/DE/HH/HAW/BT7", the total size gain is 21 octets. 1449 A.2. CCNx 1451 The CCNx TLV encoding defines a 2-octet encoding for type and length 1452 fields, summing up to 4 octets in total without a value. 1454 A.2.1. Interest 1456 Figure 32 depicts the size requirements for a basic, uncompressed 1457 CCNx Interest. No Hop-By-Hop TLVs are included and the protocol 1458 version as well as the reserved field are assumed to be 0. A 1459 KeyIdRestriction TLV with T_SHA-256 is included to limit the 1460 responses to Content Objects containing the specific key. 1462 ------------------------------------, 1463 Fixed Header = 8 | 1464 Message = 4 | 1465 ---------------------, | 1466 Name | 4 + = 56 + 4n + comps_n 1467 NameSegments = 4n + | 1468 | comps_n | 1469 ---------------------' | 1470 KeyIdRestriction = 40 | 1471 ------------------------------------' 1473 Figure 32: Estimated size of an uncompressed CCNx Interest 1475 Figure 33 depicts the size requirements after compression. 1477 ------------------------------------, 1478 Dispatch Page Switch = 1 | 1479 CCNx Interest Dispatch = 3 | 1480 Fixed Header = 3 | 1481 -----------------------, | 1482 Name | = 39 + n/2 + comps_n 1483 NameSegments = n/2 + | 1484 | comps_n | 1485 -----------------------' | 1486 T_SHA-256 = 32 | 1487 ------------------------------------' 1489 Figure 33: Estimated size of a compressed CCNx Interest 1491 The size difference is: 1492 17 + 3.5n octets. 1494 For the name "/DE/HH/HAW/BT7", the total size gain is 31 octets, 1495 which is 38% of the uncompressed packet. 1497 A.2.2. Data 1499 Figure 34 depicts the size requirements for a basic, uncompressed 1500 CCNx Data containing an ExpiryTime Message TLV, an HMAC_SHA-256 1501 signature, the signature time and a hash of the shared secret key. 1503 ------------------------------------, 1504 Fixed Header = 8 | 1505 Message = 4 | 1506 ---------------------, | 1507 Name | 4 + | 1508 NameSegments = 4n + | 1509 | comps_n | 1510 ---------------------' | 1511 ExpiryTime = 12 = 124 + 4n + comps_n + clen 1512 Payload = 4 + clen | 1513 ---------------------, | 1514 ValidationAlgorithm | | 1515 T_HMAC-256 = 56 | 1516 KeyId | | 1517 SignatureTime | | 1518 ---------------------' | 1519 ValidationPayload = 36 | 1520 ------------------------------------' 1522 Figure 34: Estimated size of an uncompressed CCNx Data Object 1524 Figure 35 depicts the size requirements for a basic, compressed CCNx 1525 Data. 1527 ------------------------------------, 1528 Dispatch Page Switch = 1 | 1529 CCNx Content Dispatch = 4 | 1530 Fixed Header = 2 | 1531 -----------------------, | 1532 Name | | 1533 NameSegments = n/2 + | 1534 | comps_n = 91 + n/2 + comps_n + clen 1535 -----------------------' | 1536 ExpiryTime = 8 | 1537 Payload = 1 + clen | 1538 T_HMAC-SHA256 = 32 | 1539 SignatureTime = 8 | 1540 ValidationPayload = 34 | 1541 ------------------------------------' 1543 Figure 35: Estimated size of a compressed CCNx Data Object 1545 The size difference is: 1546 33 + 3.5n octets. 1548 For the name "/DE/HH/HAW/BT7", the total size gain is 47 octets. 1550 Acknowledgments 1552 Authors' Addresses 1554 Cenk Gundogan 1555 HAW Hamburg 1556 Berliner Tor 7 1557 Hamburg D-20099 1558 Germany 1560 Phone: +4940428758067 1561 EMail: cenk.guendogan@haw-hamburg.de 1562 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 1564 Thomas C. Schmidt 1565 HAW Hamburg 1566 Berliner Tor 7 1567 Hamburg D-20099 1568 Germany 1570 EMail: t.schmidt@haw-hamburg.de 1571 URI: http://inet.haw-hamburg.de/members/schmidt 1573 Matthias Waehlisch 1574 link-lab & FU Berlin 1575 Hoenower Str. 35 1576 Berlin D-10318 1577 Germany 1579 EMail: mw@link-lab.net 1580 URI: http://www.inf.fu-berlin.de/~waehl 1582 Christopher Scherb 1583 University of Basel 1584 Spiegelgasse 1 1585 Basel CH-4051 1586 Switzerland 1588 EMail: christopher.scherb@unibas.ch 1589 Claudio Marxer 1590 University of Basel 1591 Spiegelgasse 1 1592 Basel CH-4051 1593 Switzerland 1595 EMail: claudio.marxer@unibas.ch 1597 Christian Tschudin 1598 University of Basel 1599 Spiegelgasse 1 1600 Basel CH-4051 1601 Switzerland 1603 EMail: christian.tschudin@unibas.ch