idnits 2.17.1 draft-gundogan-icnrg-ccnlowpan-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2017) is 2379 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'CCN-LITE' is defined on line 748, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-05 Summary: 1 error (**), 0 flaws (~~), 3 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: March 26, 2018 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 September 22, 2017 13 CCN Packet Adaptation to IEEE 802.15.4 Networks 14 draft-gundogan-icnrg-ccnlowpan-00 16 Abstract 18 Prevalent TLV-based CCN packet formats such as CCNx and NDN are 19 designed to be generic and extensible. This leads to header 20 verbosity which is not acceptable in constrained environments where 21 small-sized MTU link-layers like IEEE 802.15.4 are deployed. This 22 document presents an adaptation layer for IEEE 802.15.4 that reduces 23 CCNx and NDN packet header sizes for an increased payload size. 24 Further, a link fragmentation on this adaptation layer is described. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 26, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. CCN-LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. TLV Compression . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Name Compression . . . . . . . . . . . . . . . . . . . . 6 62 3.3. Dispatch Page & Type . . . . . . . . . . . . . . . . . . 7 63 3.4. CCN-LoWPAN Fragmentation . . . . . . . . . . . . . . . . 8 64 3.5. CCN-LoWPAN NDN Format Specific Header . . . . . . . . . . 8 65 3.5.1. Interest . . . . . . . . . . . . . . . . . . . . . . 8 66 3.5.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.6. CCN-LoWPAN CCNx Format Specific Header . . . . . . . . . 12 68 3.6.1. Interest . . . . . . . . . . . . . . . . . . . . . . 13 69 3.6.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.1. Normative References . . . . . . . . . . . . . . . . . . 16 73 5.2. Informative References . . . . . . . . . . . . . . . . . 17 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 This document decribes a method to reduce the header size of Content- 80 centric Networking (CCN) packet formats like CCNx and the NDN (Named 81 Data Networking) TLV [NDN][NDN-TLV]. This includes reducing the size 82 of the TLV format as well as omitting optional TLVs by assuming sane 83 default values. The compression method is inspired by the 6LoWPAN 84 concept [RFC4944][RFC6282], where an adaptation layer for IPv6 on 85 IEEE 802.15.4 is provided. 87 In the typical IoT scenario (Figure 1), embedded devices are 88 interconnected via quasi-stationary infrastructure, where a border 89 gateway router (BGR) sits at the junction of separate constrained 90 LoWPAN networks and the Internet. For CCN, Interest and Data 91 messages are supposed to travel up to the embedded devices in the 92 contrained LoWPANs. 94 NDN / CCNx 95 ------------------------- 96 | 97 | 98 ,-------, 99 | | 100 | BGR | 101 O | | 102 O '-------' 103 O LoWPAN 104 O O 105 O 106 O O O O O O 107 O 108 O O O embedded 109 O O O devices 110 O O O 112 Figure 1: IoT Network 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 The use of the term, "silently ignore" is not defined in RFC 2119. 120 However, the term is used in this document and can be similarly 121 construed. 123 This document uses the terminology of [RFC7476], [RFC7927], and 124 [RFC7945] for ICN entities. 126 The following terms are used in the document and defined as follows: 128 CCN-LoWPAN: Content-centric Networking over Low-power Wireless 129 Personal Area Network 131 TLV: Type Length Value 133 3. CCN-LoWPAN 135 The objective of this document is to define an adaptation layer that 137 1. registers CCNx and NDN packet format dispatch types for IEEE 138 802.15.4 frames, 140 2. handles packet header compression and 141 3. adopts the 6LoWPAN link fragmentation ([RFC4944]) to enable 142 transmissions over IEEE 802.15.4 for packets larger than the 143 Maximum Transmission Unit (MTU) of 127 bytes. 145 The adaptation is handled on a convergence layer between the actual 146 CCN layer (L3) and the IEEE 802.15.4 link-layer (L2). The adaptation 147 is transparent to any application inside the low-power network. 148 Therefore, after the packet was received on any IoT node, it is 149 transformed and parsed as a standard CCN message by the CCN layer. 150 As such, the message is passed to the common CCN forwarding pipeline 151 (Router) or an application (Figure 2). 153 Device 1 Device 2 154 ,------------------, Router ,------------------, 155 | Application . | __________________ | ,-> Application | 156 |----------------|-| | NDN / CCN | |-|----------------| 157 | NDN / CCN | | | ,--------------, | | | NDN / CCN | 158 |----------------|-| |-|--------------|-| |-|----------------| 159 | CCN-LoWPAN | | | | CCN-LoWPAN | | | | CCN-LoWPAN | 160 |----------------|-| |-|--------------|-| |-|----------------| 161 | 802.15.4 | | | | 802.15.4 | | | | 802.15.4 | 162 '----------------|-' '-|--------------|-' '-|----------------' 163 '--------' '---------' 165 Figure 2: Hop-By-Hop Adaptation 167 The parsing of position independent TLVs relies on the Type field to 168 identify a specific TLV. The CCNx and NDN packet formats however 169 mostly consist of TLVs with fixed position. The proposed packet 170 compression 1) reduces TLV sizes by removing the Type field of TLVs 171 and 2) reduces the header length by omitting TLVs and assuming sane 172 default values as specified in this document. 174 In a compressed packet, a CCN-LoWPAN header is prepended and 175 describes the compression scheme. CCN-LoWPAN defines packet format 176 specific headers for Interest and Data packets separately. 178 Figure 3 shows the header structure for the proposed CCN-LoWPAN 179 adaptation layer. 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 182 | ... Dispatch Types ... | CCN-LoWPAN | ... Payload ... 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 185 Figure 3: Dispatch Type + CCN-LoWPAN Header 187 Dispatch Types: Dispatch types for LoWPAN frames ([RFC4944]). 188 Dispatch types specifically for CCN-LoWPAN are 189 defined in Section 3.3 of this document. CCN-LoWPAN 190 makes use of the Dispatch Page "2" ([RFC8025]). 192 CCN-LoWPAN: A packet format specific CCN-LoWPAN header. 194 Payload: A compressed CCNx or NDN packet. 196 The bits in the CCN-LoWPAN header define which header field TLVs are 197 present. The order of the TLVs in the compressed header corresponds 198 to the order of the bits from MSB to LSB, as described in 199 Section 3.1. The compressed CCN packet follows immediately the CCN- 200 LoWPAN header. 202 3.1. TLV Compression 204 TLV (Type, Length, Value) is an extendible method to encode data. 205 The actual Value field of a TLV is thereby marked with a Type field 206 and a Length field. Providing the length of the value is beneficial 207 for parsing, since it allows variable-sized data and enables non- 208 linear skipping of TLVs using the Length field as offset. TLVs are 209 position independent, because of the Type field denoting the data to 210 parse. A typical series of TLVs is shown in Figure 4. 212 +-------+-------+-----------------+-------+-------+-----------+ 213 | TYP | LEN | VALUE | TYP | LEN | VALUE | 214 +-------+-------+-----------------+-------+-------+-----------+ 216 The Type and Length fields may also be of variable lengths depending 217 on the TLV encoding. 219 Figure 4: An uncompressed series of TLVs 221 In contrast to fixed-sized and ordered fields, TLVs have the 222 disadvantage of being much more verbose by providing the Type and the 223 Length in addition to the Value. For computer networks running IEEE 224 802.11 or Ethernet this may not pose a problem, but for networks 225 using small-sized MTU networks like IEEE 802.15.4 this overhead is 226 crucial. 228 This compression scheme reduces the overhead in a series of TLVs. 229 For a series of TLVs with each TLV having a fixed position in the 230 series, the Type field of each TLV is omitted, leaving only a series 231 of LVs. The order of TLVs thus MUST be known by the packet format 232 parser. In addition to this extended parser logic, a bitfield 233 representing the presence of a TLV is necessary to support optional 234 TLVs in the series. Figure 5 demonstrates how the overhead of a 235 series of TLVs is reduced by excluding the Type fields. Instead of 236 encoding the Type inside a TLV, the Type is defined by one 237 corresponding bit in the bitfield. If the bit is set, the Length and 238 the Value are assumed by the parser to be present in the order of the 239 set bits in the bitfield (see first set bit in the Figure). 240 Additionally, if the field has a fixed length (e.g. a 32-bit number), 241 the Length field MUST be omitted, too (see second set bit in the 242 Figure). If a TLV contains just a boolean value, then setting the 243 correct bit in the bitfield encodes the Type and the boolean value. 244 No further fields are enocded in the series (see third set bit in the 245 Figure). 247 +---+---+---+---+---+---+---+---+ 248 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bitfield 249 +---+---+---+---+---+---+---+---+ 250 | | | 251 ,--' '-----------, '- boolean 252 | | 253 +-------+--------------+-------------+ 254 | LEN | VALUE | VALUE | Compressed TLV series 255 +-------+--------------+-------------+ 257 Figure 5: A comressed series of TLVs 259 Note: This compresssion scheme extends the packet parser complexity 260 in order to reduce the TLV series. It reduces the overhead of the 261 TLV encoding and does not modify the contained data in the Value 262 field. 264 3.2. Name Compression 266 Name components in CCNx and NDN are structured as shown in Figure 6. 268 ,-----------------------------------------------------, 269 | | ,----------------, ,----------------, | 270 | Name TL | | Comp. TL | ... | ... | Comp. TL | ... | | 271 | | '----------------' '----------------' | 272 '-----------------------------------------------------' 274 Figure 6: Verbosity of Name TLVs in NDN 276 Each name component is marked by a TLV, which contains a series of 277 name component TLVs. In this compression scheme, the Type field of 278 name components is removed, leaving a series of LVs. Given the total 279 length in the Name TLV, the name component TLV series is further 280 reduced by removing the Length field and reserving a character for 281 separating name components ("CSEP"). In this document, "CSEP" is set 282 to ascii 0x00. All occurences of the "CSEP" character within a name 283 component MUST be escaped wit another "CSEP". "CSEP CSEP" therefore 284 transforms to "CSEP" within names. A compressed TLV for the name is 285 given in Figure 7. 287 ,-------------------------------------------, 288 | | | 289 | Name TL | Comp. CSEP Comp. CSEP ... Comp. | 290 | | | 291 '-------------------------------------------' 293 Figure 7: Compressed Name TLVs in NDN 295 Names can opionally further be compressed by limiting the alphabet to 296 a reduced set for a specific use case, or by using a LZ77-style 297 compression like in [RFC7400]. Both additions are out of scope of 298 this document. 300 3.3. Dispatch Page & Type 302 Similar to 6LoWPAaN (Section 5.1 of [RFC4944]), this document defines 303 dispatch types to identify the payload as (un-)compressed CCNx or NDN 304 headers (Table 1). [RFC8025] further specifies dispatch pages to 305 switch between different dispatch contexts. For an orthogonal code 306 space, this document specifies the use of page 2 ("1111 0010 307 (0xF2)"). Section 6.2 of [RFC8025] gives an overview of unassigned 308 dispatch pages and types. 310 +------------------+------+-------------------------------------+ 311 | Bit Pattern | Page | Header Type | 312 +------------------+------+-------------------------------------+ 313 | 0000 0000 (0x00) | 2 | Uncompressed CCNx Header (Interest) | 314 | 0000 0001 (0x01) | 2 | Uncompressed CCNx Header (Data) | 315 | 0000 0010 (0x02) | 2 | Uncompressed NDN Header (Interest) | 316 | 0000 0011 (0x03) | 2 | Uncompressed NDN Header (Data) | 317 | 0001 0000 (0xF0) | 2 | CCN-LoWPAN CCNx Header (Interest) | 318 | 0001 0001 (0xF1) | 2 | CCN-LoWPAN CCNx Header (Data) | 319 | 0001 0010 (0xF2) | 2 | CCN-LoWPAN NDN Header (Interest) | 320 | 0001 0011 (0xF3) | 2 | CCN-LoWPAN NDN Header (Data) | 321 +------------------+------+-------------------------------------+ 323 Table 1: Dispatch Types for (un-)compressed CCNx and NDN 325 For backwards compatibility, [RFC8025] does not require a Page Switch 326 dispatch type for page 0. For page 2, a Page Switch header MUST be 327 specified to indicate a context switch before parsing the dispatch 328 type. As an example, to select page 2 and mark the payload as an 329 uncompressed NDN header for Interests, the bit pattern is as follows: 330 "1111 0010 0000 0001". 332 3.4. CCN-LoWPAN Fragmentation 334 IEEE 802.15.4 provides a maximum physical layer packet size of 127 335 octets. The maximum frame size can be 25 octets, which leaves 102 336 octets for payload. IEEE 802.15.4 security features can even reduce 337 this payload length by a maximum of 21 octets, yielding a minimum 338 total net of 81 octets for CCNx or NDN packet headers, signatures and 339 content. To support packet sizes greater than this restriction, a 340 link fragmentation and reassembly scheme is necessary. 342 Section 5.3 of [RFC4944] defines a protocol independent fragmentation 343 dispatch type and a fragmentation header for the first fragment and a 344 separate fragmentation header for subsequent fragments. CCN-LoWPAN 345 adopts the fragmentation handling of [RFC4944]. 347 The Fragmentation dispatch type is prepended to other dispatch types 348 and the payload. The order of dispatch types is adopted from 349 [RFC4944]. To use the CCN-LoWPAN dispatch types (defined in 350 Table 1), a page switch to page 2 MUST occure. 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 353 | Fr. Type + Header | Disp. Page 2 | CCN-LoWPAN NDN Int. | Payload 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 356 Figure 8: Dispatch Types including Fragmentation 358 3.5. CCN-LoWPAN NDN Format Specific Header 360 In this section the compression scheme for NDN Interest and Data 361 object packets is defined. The packet format specification is 362 obtained from [NDN-TLV]. 364 3.5.1. Interest 366 The dispatch type bit pattern is "0001 0010 (0xF2)" (Table 1). An 367 uncompressed NDN Interest message is structured as shown in Figure 9. 368 where optional components are marked by a "?". 370 Interest ::= INTEREST-TYPE TLV-LENGTH 371 Name 372 Selectors? 373 Nonce 374 InterestLifetime? 375 ForwardingHint? 377 Selectors ::= SELECTORS-TYPE TLV-LENGTH 378 MinSuffixComponents? 379 MaxSuffixComponents? 380 PublisherPublicKeyLocator? 381 Exclude? 382 ChildSelector? 383 MustBeFresh? 385 Figure 9: NDN Interest BNF 387 The packet specific compression header for the NDN Interest message 388 is defined as shown in Figure 10. 390 0 1 2 3 4 5 6 7 8 391 +-------+-------+-------+-------+-------+-------+-------+-------+ 392 | minSx | maxSx | ppk | excld | ChSel | fresh | IntLT | resv | 393 +-------+-------+-------+-------+-------+-------+-------+-------+ 395 Figure 10: NDN Interest Compression Header 397 minSX: 1 bit flag. If set, then MinSuffixComponents are available 398 in the compressed NDN Interest packet. 400 maxSX: 1 bit flag. If set, then MaxSuffixComponents are available 401 in the compressed NDN Interest packet. 403 ppk: 1 bit flag. If set, then a PublisherPublicKeyLocator is 404 available in the compressed NDN Interest packet. 406 excld: 1 bit flag. If set, then an exclude selector is available in 407 the compressed NDN Interest packet. 409 ChSel: 1 bit flag. If set, then a ChildSelector is available in the 410 compressed NDN Interest packet. 412 fresh: 1 bit flag. If set, then the compressed NDN Interest is 413 handled as if the MustBeFresh selector is available. The 414 MustBeFresh selector is of boolean type and therefore is 415 omitted from the compressed NDN Interest entirely. 417 IntLT: 1 bit flag. If set, then the Interest Lifetime selector is 418 available in the compressed NDN Interest packet. 420 resv: 1 bit flag. This flag is reserved and MUST be set to 0. 422 If one of the bits in this CCN-LoWPAN header is set, the Length and 423 the Value of the corresponding field is written in the packet in the 424 same order as they appear in this header. For NDN, only the name and 425 nonce is mandatory. A compressed NDN Interest has the structure as 426 in Figure 11. 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 429 | Dispatch Types + Headers | Name | Nonce | [LV fields] ... 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 432 Figure 11: CCN-LoWPAN Interest for NDN 434 If only the exclude and the MustBeFresh bits are set, the Interest 435 message will be structured as shown in Table 2. D denotes all 436 dispatch types and headers, CCNL denotes the dispatch header for the 437 CCN-LoWPAN compression, N is the name, L is length. 439 +-----+----------+---+--------+-------+----+---------+ 440 | D | CCNL | L | N | Nonce | L | Exclude | 441 +-----+----------+---+--------+-------+----+---------+ 442 | ... | 00010100 | 6 | name/d | 34323 | 12 | | 443 +-----+----------+---+--------+-------+----+---------+ 445 Table 2: CCN-LoWPAN Interest with exclude and MustBeFresh 447 Since MusBeFresh is a boolean, it does not appear in the payload. 449 3.5.2. Data 451 The dispatch type bit pattern is "0001 0011 (0xF3)" (Table 1). An 452 uncompressed NDN Data packet is structured as shown in Figure 12. 454 Data ::= DATA-TLV TLV-LENGTH 455 Name 456 MetaInfo 457 Content 458 Signature 460 MetaInfo ::= META-INFO-TYPE TLV-LENGTH 461 ContentType? 462 FreshnessPeriod? 463 FinalBlockId? 465 Figure 12: NDN Data BNF 467 The CCN-LoWPAN dispatch header of the NDN Data packet marks if 468 Content Type, Freshness Period and Final Block ID are available as 469 shown in Figure 13. The surrounding MetaInfo TLV around these values 470 is omitted. 472 0 1 2 3 4 5 6 7 8 473 +-------+-------+-------+-------+-------+-------+-------+-------+ 474 | ContT | FrPer | FB_ID | reserved | 475 +-------+-------+-------+-------+-------+-------+-------+-------+ 477 Figure 13: NDN Data Compression Header 479 ContT: 1 bit flag. If set, then a ContentType is present in the 480 compressed NDN Data packet. If the ContT is cleared, 481 then a content type of BLOB (0) is assumed and no 482 ContenType is present in the compressed NDN Data packet. 484 FrPer: 1 bit flag. If set, then a FreshnessPeriod is present in 485 the compressed NDN Data Packet. If the FrPer is cleared, 486 then a default value of 0 is assumed and no 487 FreshnessPeriod is present in the compressed NDN Data 488 packet. 490 FB_ID: 1 bit flag. If set, then a FinalBlockId is present in 491 the compressed NDN Data packet. If the FB_ID is cleared, 492 then no FinalBlockId is present in the compressed NDN 493 Data packet. 495 reserved: 5 bits. These bits are reserved and MUST be set to 0. 497 The compressed NDN Data packet has the structure as shown in 498 Figure 14. 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Dispatch Types + Headers | Name | [LV fields] ... | Cont. | Sig | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 14: NDN LoWPAN Content 506 Assuming the FinalBlock ID is the only MetaInfo which is enabled, the 507 compressed NDN Data packet will look as demonstrated in Table 3. D 508 denotes all dispatch types, CCNL denotes the dispatch header for the 509 CCN-LoWPAN compression, N is the name, C is the content, L is length 510 and S is signature. 512 +-----+----------+---+--------+------+----+---+-----+---+ 513 | D | CCNL | L | N | FBID | L | C | L | S | 514 +-----+----------+---+--------+------+----+---+-----+---+ 515 | ... | 01000010 | 6 | name/d | 34 | 64 | c | 256 | s | 516 +-----+----------+---+--------+------+----+---+-----+---+ 518 Table 3: CCN-LoWPAN Data packet with FinalBlock ID 520 3.6. CCN-LoWPAN CCNx Format Specific Header 522 In this section the compression scheme for CCNx Interest and Data 523 object packets is defined. The packet format specification is 524 obtained from [I-D.irtf-icnrg-ccnxmessages]. The CCN-LoWPAN dispatch 525 header for the CCNx packet format consists of 2 octets. Thereby, the 526 first octet marks the presence of fields in the fixed header which is 527 defined for both CCNx Interest and Data object packets. The fixed 528 header consists of the Version, the PacketType, the PacketLength and 529 packet specific fields. Since the packet type is defined by the 530 dispatch type and the packet length is given by the L2 frame header 531 excluding the dispatch types and headers, both fields can be removed. 532 In this document, the Version is marked as optional and a default 533 version is assumed. In CCNx every packet can carry a payload and 534 validation info, but both are optional. The first octect for the 535 fixed header of CCNx packets is structured as shown in Figure 15. 537 0 1 2 3 4 5 6 7 8 538 +-------+-------+-------+-------+-------+-------+-------+-------+ 539 | ver | reserved | hash | payld | val | HbH | 540 +-------+-------+-------+-------+-------+-------+-------+-------+ 542 Figure 15: CCN-LoWPAN for the fixed header of CCNx 544 ver: 1 bit flag. If set, then a Version field is present in 545 the compressed fixed header of the CCNx packet. If ver 546 is cleared, then a default version of '1' (=CCNx v1.0) is 547 assumed. 549 reserved: 3 bits. These bits are reserved and MUST be set to 0. 551 hash: 1 bit flag. If set, a hash field is available. There is 552 no default value. 554 payld: 1 bit flag. If set, then a PacketPayloadTLV is present 555 in the compressed CCNx packet. If cleared, there is no 556 PacketPayloadTLV in the packet. 558 val: 1 bit flag. If set, then a ValidationTLV is present in 559 the compressed CCNx packet. If cleared, there is no 560 ValidationTLV in the packet 562 HbH: 1 bit flag. If set, then a HoyByHopTLV is present in the 563 compressed CCNx Packet. 565 3.6.1. Interest 567 The dispatch type bit pattern is "0001 0000 (0xF0)" (Table 1). An 568 uncompressed CCNx Interest message is structured as shown in 569 Figure 16. where optional components are marked by a "?". 571 Interest ::= Version 572 PacketType 573 PacketLength 574 HopLimit 575 Reserved / ReturnCode 576 Flags 577 HeaderLength 578 InterestLifetimeTLV? 579 MsgHashTLV? 580 PacketPayloadTLV 581 ValidationAlgorithmTLV? 582 ValidationPayloadTLV? 584 PacketPayloadTLV ::= T_INTEREST MsgLen 585 NameTLV 586 KeyIDRestrictionTLV? 587 ContentObjectHashRestrictionTLV? 588 PayloadTLV? 590 Figure 16: CCNx Interest BNF 592 The second octet for the CCNx Interest message is defined as in 593 Figure 17. 595 0 1 2 3 4 5 6 7 8 596 +-------+-------+-------+-------+-------+-------+-------+-------+ 597 | ilt | keyid | ohstr | hlim | hlim | flags | ret | resv | 598 +-------+-------+-------+-------+-------+-------+-------+-------+ 600 Figure 17: CCN-LoWPAN dispatch header for compressed Interest in CCNx 602 ilt: 1 bit flag. If set, then a InterestLiveTime field is 603 present in the compressed Interest header of the CCNx 604 packet. If ilt is cleared, the InterestLiveTime is 605 assumed to be zero, which indicates, the Interest does 606 not expect a response. 608 keyid: 1 bit flag. If set, a KeyIDRestrictionTLV field is 609 present in the compressed Interest header of the CCNx 610 packet. There is no default value, since the field is 611 optional in CCNx. 613 ohsr: 1 bit flag. If set, ContentObjectHashRestriction field 614 is present in the compressed Interest header of the CCNx 615 packet. There is no default value, since the field is 616 optional in CCNx. 618 hlim: 2 bit flag. If set to 0x00, the hop limit is carried in 619 the payload. If set to 0x01, the hop limit is omitted 620 from the payload and a hop limit of 1 is assumed. If set 621 to 0x02, the hop limit is omitted from the payload and a 622 hop limit of 64 is assumed. If set to 0x03, the hop 623 limit is omitted from the payload and a hop limit of 255 624 is assumed. 626 flags: 1 bit flag. If set, a flag field is present in the 627 compressed Interest header of the CCNx packet. Currently 628 there are no flags defined, thus the bit must be cleared. 630 ret: 1 bit flag. If set, a return field is present in the 631 compressed Interest header of the CCNx packet. This 632 field is optional in CCNx, so there is no default value. 634 resv: 1 bit flag. This flag is reserved and MUST be set to 0. 636 Similar to the NDN packet format, if a field is available, the 637 corresponding bit is enabeld. 639 For an Interest message, the PacketPayloadTLV contains a surrounding 640 MessageType of T_INTEREST and an overall MessageLength. This 641 information is already contained in the dispatch type. Thus, the 642 MessageType is removed. The MessageLength is also removed, as the 643 Length of each nested TLV is known. 645 3.6.2. Data 647 The dispatch type bit pattern is "0001 0001 (0xF1)" (Table 1). An 648 uncompressed CCNx Data message is designed as shown in Figure 18. 649 Optional fields are marked by '?'. 651 Data ::= Version 652 PacketType 653 PacketLength 654 Reserved 655 Flags 656 HeaderLength 657 CacheTimeTLV? 658 MsgHashTLV? 659 PacketPayloadTLV 660 ValidationAlgorithmTLV? 661 ValidationPayloadTLV? 663 PacketPayloadTLV ::= T_OBJECT MsgLen 664 NameTLV 665 PayloadTypeTLV? 666 PayloadTLV? 667 ExpiryTimeTLV? 669 Figure 18: CCNx Data BNF 671 The second octet of the CCN-LoWPAN dispatch header for a Data object 672 is structured as shown in Figure 19. 674 0 1 2 3 4 5 6 7 8 675 +-------+-------+-------+-------+-------+-------+-------+-------+ 676 | rct | ptype | exp | reserved | 677 +-------+-------+-------+-------+-------+-------+-------+-------+ 679 Figure 19: CCN-LoWPAN Data Object Header for CCNx 681 rct: 1 bit flag. If set, then a CacheTimeTLV is present in 682 the compressed Data header of the CCNx packet. Since the 683 CacheTimeTLV is of fixed length (8 octets), not only th 684 Type field, but also the Length field of this TLV is 685 omitted in the compressed CCNx packet. 687 ptype: 1 bit flag. If set, a PayloadTypeTLV is present in the 688 compressed Data header of the CCNx packet. If cleared, 689 then the "Data" PayloadTypeTLV is assumed. 691 exp: 1 bit flag. If set, then a ExpiryTimeTLV is present in 692 the compressed Data header of the CCNx packet. Since the 693 ExpiryTimeTLV is of fixed length (8 octets), not only th 694 Type field, but also the Length field of this TLV is 695 omitted in the compressed CCNx packet. 697 resv: 5 bits flag. This flag is reserved and MUST be set to 0. 699 For a Data message, the PacketPayloadTLV contains a surrounding 700 MessageType of T_OBJECT and an overall MessageLength. This 701 information is already contained in the dispatch type. Thus, the 702 MessageType is removed. The MessageLength is also removed, as the 703 Length of each nested TLV is known. 705 4. Security Considerations 707 TODO 709 5. References 711 5.1. Normative References 713 [I-D.irtf-icnrg-ccnxmessages] 714 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 715 Format", draft-irtf-icnrg-ccnxmessages-05 (work in 716 progress), September 2017. 718 [NDN-TLV] "NDN Packet Format Specification", 719 . 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, 724 . 726 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 727 "Transmission of IPv6 Packets over IEEE 802.15.4 728 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 729 . 731 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 732 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 733 DOI 10.17487/RFC6282, September 2011, 734 . 736 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 737 IPv6 over Low-Power Wireless Personal Area Networks 738 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 739 2014, . 741 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 742 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 743 RFC 8025, DOI 10.17487/RFC8025, November 2016, 744 . 746 5.2. Informative References 748 [CCN-LITE] 749 "CCN-lite: A lightweight CCNx and NDN implementation", 750 . 752 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 753 "Networking Named Content", 5th Int. Conf. on emerging 754 Networking Experiments and Technologies (ACM CoNEXT), 755 2009. 757 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 758 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 759 "Information-Centric Networking: Baseline Scenarios", 760 RFC 7476, DOI 10.17487/RFC7476, March 2015, 761 . 763 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 764 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 765 "Information-Centric Networking (ICN) Research 766 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 767 . 769 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 770 and G. Boggia, "Information-Centric Networking: Evaluation 771 and Security Considerations", RFC 7945, 772 DOI 10.17487/RFC7945, September 2016, 773 . 775 Acknowledgments 777 Authors' Addresses 779 Cenk Gundogan 780 HAW Hamburg 781 Berliner Tor 7 782 Hamburg D-20099 783 Germany 785 Phone: +4940428758067 786 EMail: cenk.guendogan@haw-hamburg.de 787 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 789 Thomas C. Schmidt 790 HAW Hamburg 791 Berliner Tor 7 792 Hamburg D-20099 793 Germany 795 EMail: t.schmidt@haw-hamburg.de 796 URI: http://inet.haw-hamburg.de/members/schmidt 798 Matthias Waehlisch 799 link-lab & FU Berlin 800 Hoenower Str. 35 801 Berlin D-10318 802 Germany 804 EMail: mw@link-lab.net 805 URI: http://www.inf.fu-berlin.de/~waehl 807 Christopher Scherb 808 University of Basel 809 Spiegelgasse 1 810 Basel CH-4051 811 Switzerland 813 EMail: christopher.scherb@unibas.ch 814 Claudio Marxer 815 University of Basel 816 Spiegelgasse 1 817 Basel CH-4051 818 Switzerland 820 EMail: claudio.marxer@unibas.ch 822 Christian Tschudin 823 University of Basel 824 Spiegelgasse 1 825 Basel CH-4051 826 Switzerland 828 EMail: christian.tschudin@unibas.ch