idnits 2.17.1 draft-irtf-icnrg-icnlowpan-04.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 22, 2019) is 1738 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group C. Gundogan 3 Internet-Draft TC. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: January 23, 2020 M. Waehlisch 6 link-lab & FU Berlin 7 C. Scherb 8 C. Marxer 9 C. Tschudin 10 University of Basel 11 July 22, 2019 13 ICN Adaptation to LowPAN Networks (ICN LoWPAN) 14 draft-irtf-icnrg-icnlowpan-04 16 Abstract 18 This document defines a convergence layer for CCNx and NDN over IEEE 19 802.15.4 LoWPAN networks. A new frame format is specified to adapt 20 CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For 21 that, syntactic and semantic changes to the TLV-based header formats 22 are described. To support compatibility with other LoWPAN 23 technologies that may coexist on a wireless medium, the dispatching 24 scheme provided by 6LoWPAN is extended to include new dispatch types 25 for CCNx and NDN. Additionally, the link fragmentation component of 26 the 6LoWPAN dispatching framework is applied to ICN chunks. In its 27 second part, the document defines stateless and stateful compression 28 schemes to improve efficiency on constrained links. Stateless 29 compression reduces TLV expressions to static header fields for 30 common use cases. Stateful compression schemes elide state local to 31 the LoWPAN and replace names in data packets by short local 32 identifiers. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 23, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 5 67 3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 5 68 3.2. Stateless Header Compression . . . . . . . . . . . . . . 6 69 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 7 70 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 7 71 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 7 72 4.2. Link Fragmentation . . . . . . . . . . . . . . . . . . . 9 73 5. Space-efficient Message Encoding for NDN . . . . . . . . . . 10 74 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 10 75 5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 11 76 5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 12 77 5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 15 78 6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 18 79 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 18 80 6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 18 81 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 18 82 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 25 83 7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 28 84 8. Stateful Header Compression . . . . . . . . . . . . . . . . . 29 85 8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 29 86 8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 29 87 8.3. Integrating Stateful Header Compression . . . . . . . . . 31 88 9. ICNLoWPAN Constants and Variables . . . . . . . . . . . . . . 32 89 10. Implementation Report and Guidance . . . . . . . . . . . . . 32 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 92 12.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . 33 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 95 13.2. Informative References . . . . . . . . . . . . . . . . . 33 97 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 36 98 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 36 100 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 37 101 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 39 102 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 39 103 A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 40 104 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 107 1. Introduction 109 The Internet of Things (IoT) has been identified as a promising 110 deployment area for Information Centric Networks (ICN), as 111 infrastructureless access to content, resilient forwarding, and in- 112 network data replication demonstrated notable advantages over the 113 traditional host-to-host approach on the Internet [NDN-EXP1], 114 [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate 115 mapping to link layer technologies has a large impact on the 116 practical performance of an ICN. This will be even more relevant in 117 the context of IoT communication where nodes often exchange messages 118 via low-power wireless links under lossy conditions. In this memo, 119 we address the base adaptation of data chunks to such link layers for 120 the ICN flavors NDN [NDN] and CCNx [RFC8569], [RFC8609]. 122 The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and 123 lossy networks (see "LLN" in [RFC7228]), in which devices are 124 typically battery-operated and constrained in resources. 125 Characteristics of LLNs include an unreliable environment, low 126 bandwidth transmissions, and increased latencies. IEEE 802.15.4 127 admits a maximum physical layer packet size of 127 octets. The 128 maximum frame header size is 25 octets, which leaves 102 octets for 129 the payload. IEEE 802.15.4 security features further reduce this 130 payload length by up to 21 octets, yielding a net of 81 octets for 131 CCNx or NDN packet headers, signatures and content. 133 6LoWPAN [RFC4944], [RFC6282] is a convergence layer that provides 134 frame formats, header compression and link fragmentation for IPv6 135 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces 136 a dispatching framework that prepends further information to 6LoWPAN 137 packets, including a protocol identifier for IEEE 802.15.4 payload 138 and meta information about link fragmentation. 140 Prevalent Type-Length-Value (TLV) based packet formats such as in 141 CCNx and NDN are designed to be generic and extensible. This leads 142 to header verbosity which is inappropriate in constrained 143 environments of IEEE 802.15.4 links. This document presents ICN 144 LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. 146 ICN LoWPAN compresses packet headers of CCNx as well as NDN and 147 allows for an increased effective payload size per packet. 148 Additionally, reusing the dispatching framework defined by 6LoWPAN 149 enables compatibility between coexisting wireless networks of 150 competing technologies. This also allows to reuse the link 151 fragmentation scheme specified by 6LoWPAN for ICN LoWPAN. 153 ICN LoWPAN defines a more space efficient representation of CCNx and 154 NDN packet formats. This syntactic change is described for CCNx and 155 NDN separately, as the header formats and TLV encodings differ 156 noteably. For further reductions, default header values suitable for 157 constrained IoT networks are selected in order to elide corresponding 158 TLVs. Experimental evaluations of the ICN LoWPAN header compression 159 schemes in [ICNLOWPAN] illustrate a reduced message overhead, a 160 shortened message airtime, and an overall decline in power 161 consumption for typical Class 2 devices compared to uncompressed ICN 162 messages. 164 In a typical IoT scenario (see Figure 1), embedded devices are 165 interconnected via a quasi-stationary infrastructure using a border 166 router (BR) that uplinks the constrained LoWPAN network by some 167 Gateway with the public Internet. In ICN based IoT networks, non- 168 local Interest and Data messages transparently travel through the BR 169 up and down between a Gateway and the embedded devices situated in 170 the constrained LoWPAN. 172 |Gateway Services| 173 ------------------------- 174 | 175 ,--------, 176 | | 177 | BR | 178 | | 179 '--------' 180 LoWPAN 181 O O 182 O 183 O O embedded 184 O O O devices 185 O O 187 Figure 1: IoT Stub Network 189 2. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 The use of the term, "silently ignore" is not defined in RFC 2119. 196 However, the term is used in this document and can be similarly 197 construed. 199 This document uses the terminology of [RFC7476], [RFC7927], and 200 [RFC7945] for ICN entities. 202 The following terms are used in the document and defined as follows: 204 ICN LoWPAN: Information-Centric Networking over Low-power Wireless 205 Personal Area Network 207 LLN Low-Power and Lossy Network 209 CCNx: Content-Centric Networking Architecture 211 NDN: Named Data Networking Architecture 213 time-value: a time value measured in seconds 215 time-code: an 8-bit encoded time-value 217 3. Overview of ICN LoWPAN 219 3.1. Link-Layer Convergence 221 ICN LoWPAN provides a convergence layer that maps ICN packets onto 222 constrained link-layer technologies. This includes features such as 223 link-layer fragmentation, protocol separation on the link-layer 224 level, and link-layer address mappings. The stack traversal is 225 visualized in Figure 2. 227 Device 1 Device 2 228 ,------------------, Router ,------------------, 229 | Application . | __________________ | ,-> Application | 230 |----------------|-| | NDN / CCNx | |-|----------------| 231 | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | 232 |----------------|-| |-|--------------|-| |-|----------------| 233 | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | 234 |----------------|-| |-|--------------|-| |-|----------------| 235 | Link-Layer | | | | Link-Layer | | | | Link-Layer | 236 '----------------|-' '-|--------------|-' '-|----------------' 237 '--------' '---------' 239 Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 241 Section 4 of this document defines the convergence layer for IEEE 242 802.15.4. 244 3.2. Stateless Header Compression 246 ICN LoWPAN also defines a stateless header compression scheme with 247 the main purpose of reducing header overhead of ICN packets. This is 248 of particular importance for link-layers with small MTUs. The 249 stateless compression does not require pre-configuration of global 250 state. 252 The CCNx and NDN header formats are composed of Type-Length-Value 253 (TLV) fields to encode header data. The advantage of TLVs is its 254 native support of variably structured data. The main disadvantage of 255 TLVs is the verbosity that results from storing the type and length 256 of the encoded data. 258 The stateless header compression scheme makes use of compact bit 259 fields to indicate the presence of mandatory and optional TLVs in the 260 uncompressed packet. The order of set bits in the bit fields 261 corresponds to the order of each TLV in the packet. Further 262 compression is achieved by specifying default values and reducing the 263 codomain of certain header fields. 265 Figure 3 demonstrates the stateless header compression idea. In this 266 example, the first type of the first TLV is removed and the 267 corresponding bit in the bit field is set. The second TLV represents 268 a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type and 269 the length fields are removed. The third TLV represents a boolean 270 TLV (e.g., the MustBeFresh selector in NDN) for which the type, 271 length and the value fields are elided. 273 Uncompressed: 275 Variable-length TLV Fixed-length TLV Boolean TLV 276 ,-----------------------,-----------------------,-------------, 277 +-------+-------+-------+-------+-------+-------+------+------+ 278 | TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN | 279 +-------+-------+-------+-------+-------+-------+------+------+ 281 Compressed: 283 +---+---+---+---+---+---+---+---+ 284 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field 285 +---+---+---+---+---+---+---+---+ 286 | | | 287 ,--' '----, '- Boolean Value 288 | | 289 +-------+-------+-------+ 290 | LEN | VAL | VAL | 291 +-------+-------+-------+ 292 '---------------'-------' 293 Var-len Value Fixed-len Value 295 Figure 3: Compression using a compact bit field - bits encode the 296 inclusion of TLVs. 298 Stateless TLV compression for NDN is defined in Section 5. Section 6 299 defines the stateless TLV compression for CCNx. 301 3.3. Stateful Header Compression 303 ICN LoWPAN further employs two orthogonal stateful compression 304 schemes for packet size reductions which are defined in Section 8. 305 These mechanisms rely on shared contexts that are either distributed 306 and maintained in the entire LoWPAN, or are generated on-demand hop- 307 wise on a particular Interest-data path. 309 The shared context identification is defined in Section 8.1. The 310 hop-wise name compression "en-route" is specified in Section 8.2. 312 4. IEEE 802.15.4 Adaptation 314 4.1. LoWPAN Encapsulation 316 The IEEE 802.15.4 frame header does not provide a protocol identifier 317 for its payload. This causes problems of misinterpreting frames when 318 several network layers coexist on the same link. To mitigate errors, 319 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 320 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation 321 headers can prepend the actual payload and each encapsulation header 322 is identified by a dispatch type. 324 [RFC8025] further specifies dispatch pages to switch between 325 different contexts. When a LoWPAN parser encounters a "Page switch" 326 LoWPAN encapsulation header, then all following encapsulation headers 327 are interpreted by using a dispatch table as specified by the "Page 328 switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This 329 document uses page 2 ("1111 0010 (0xF2)") for NDN and page 3 ("1111 330 0011 (0xF3)") for CCNx. 332 The base dispatch format (Figure 4) is used and extended by CCNx and 333 NDN in Section 5 and Section 6. 335 0 1 2 ... 336 +---+---+-------- 337 | C | M | 338 +---+---+-------- 340 Figure 4: Base dispatch format for ICN LoWPAN 342 C: Compression 344 0: The message is uncompressed. 346 1: The message is compressed. 348 M: Message Type 350 0: The payload contains an Interest message. 352 1: The payload contains a Data message. 354 ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the 355 extended dispatch format in Figure 5. 357 0 1 2 ... 358 +---+---+-------- 359 | 1 | M |CID| 360 +---+---+-------- 362 Figure 5: Extended dispatch format for compressed ICN LoWPAN 364 CID: Context Identifier 366 0: No context identifiers are present. 368 1: Context identifier(s) are present. 370 The encapsulation format for ICN LoWPAN is displayed in Figure 6. 372 +------...------+------...-----+--------+-------...-------+-----... 373 | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / 374 +------...------+------...-----+--------+-------...-------+-----... 376 Figure 6: LoWPAN Encapsulation with ICN-LoWPAN 378 IEEE 802.15.4: The IEEE 802.15.4 header. 380 RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 381 of [RFC4944] 383 Page: Page Switch. 2 for NDN and 3 for CCNx. 385 ICN LoWPAN: Dispatches as defined in Section 5 and Section 6. 387 Payload: The actual (un-)compressed CCNx or NDN message. 389 4.2. Link Fragmentation 391 Small payload sizes in the LoWPAN require fragmentation for various 392 network layers. Therefore, Section 5.3 of [RFC4944] defines a 393 protocol-independent fragmentation dispatch type, a fragmentation 394 header for the first fragment, and a separate fragmentation header 395 for subsequent fragments. ICN LoWPAN adopts this fragmentation 396 handling of [RFC4944]. 398 The Fragmentation LoWPAN header can encapsulate other dispatch 399 headers. The order of dispatch types is defined in Section 5 of 400 [RFC4944]. Figure 7 shows the fragmentation scheme. The reassembled 401 ICN LoWPAN frame does not contain any fragmentation headers and is 402 depicted in Figure 8. 404 +------...------+----...----+--------+------...-------+--------... 405 | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / 406 +------...------+----...----+--------+------...-------+--------... 408 +------...------+----...----+--------... 409 | IEEE 802.15.4 | Frag. 2nd | Payload / 410 +------...------+----...----+--------... 412 . 413 . 414 . 416 +------...------+----...----+--------... 417 | IEEE 802.15.4 | Frag. Nth | Payload / 418 +------...------+----...----+--------... 420 Figure 7: Fragmentation scheme 422 +------...------+--------+------...-------+--------... 423 | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / 424 +------...------+--------+------...-------+--------... 426 Figure 8: Reassembled ICN LoWPAN frame 428 5. Space-efficient Message Encoding for NDN 430 5.1. TLV Encoding 432 The NDN packet format consists of TLV fields using the TLV encoding 433 that is described in [NDN-PACKET-SPEC]. Type and length fields are 434 of variable size, where numbers greater than 252 are encoded using 435 multiple octets. 437 If the type or length number is less than "253", then that number is 438 encoded into the actual type or length field. If the number is 439 greater or equals "253" and fits into 2 octets, then the type or 440 lengh field is set to "253" and the number is encoded in the next 441 following 2 octets in network byte order, i.e., from the most 442 significant byte (MSB) to the least significant byte (LSB). If the 443 number is greater than 2 octets and fits into 4 octets, then the type 444 or length field is set to "254" and the number is encoded in the 445 subsequent 4 octets in network byte order. For larger numbers, the 446 type or length field is set to "255" and the number is encoded in the 447 subsequent 8 octets in network byte order. 449 In this specification, compressed NDN TLVs make use of a different 450 TLV encoding scheme that reduces size. Instead of using the first 451 octet as a marker for the number of following octets, the compressed 452 NDN TLV scheme uses a method to chain a variable number of octets 453 together. If an octet equals "255 (0xFF)", then the following octet 454 will also be interpreted. The actual value of a chain equals the sum 455 of all constituents. 457 If the type or length number is less than "255", then that number is 458 encoded into the actual type or length field (Figure 9 a). If the 459 type or length number (X) fits into 2 octets, then the first octet is 460 set to "255" and the subsequent octet equals "X mod 255" (Figure 9 461 b). Following this scheme, a variable-sized number (X) is encoded 462 using multiple octets of "255" with a trailing octet containing "X 463 mod 255" (Figure 9 c). 465 0 1 2 3 4 5 6 7 466 +-+-+-+-+-+-+-+-+ 467 a) | < 255 (X) | = X 468 +-+-+-+-+-+-+-+-+ 470 0 1 471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 b) | 255 | < 255 (X) | = 255 + X 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 0 477 0 1 2 3 4 5 6 7 478 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 479 c) | 255 | 255 | < 255 (X) | = (N * 255) + X 480 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ 481 (N) 483 Figure 9: Compressed NDN TLV encoding scheme 485 5.2. Name TLV Compression 487 This Name TLV compression encodes length fields of two consecutive 488 NameComponent TLVs into one octet, using 4 bits each. This process 489 limits the length of a NameComponent TLV to 15 octets. A length of 0 490 marks the end of the compressed Name TLV. An example for this 491 encoding is presented in Figure 10. 493 Name: /HAW/Room/481/Humid/99 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |0 0 1 1|0 1 0 0| H | A | W | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | R | o | o | m | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |0 0 1 1|0 1 0 1| 4 | 8 | 1 | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | H | u | m | i | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | d |0 0 1 0|0 0 0 0| 9 | 9 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 10: Name TLV compression for /HAW/Room/481/Humid/99 511 5.3. Interest Messages 513 5.3.1. Uncompressed Interest Messages 515 An uncompressed Interest message uses the base dispatch format (see 516 Figure 4) and sets the C as well as the M flag to "0" (Figure 11). 517 "resv" MUST be set to 0. The Interest message is handed to the NDN 518 network stack without modifications. 520 0 1 ... 7 521 +---+---+-----------------------+ 522 | 0 | 0 | resv | 523 +---+---+-----------------------+ 525 Figure 11: Dispatch format for uncompressed NDN Interest messages 527 5.3.2. Compressed Interest Messages 529 The compressed Interest message uses the extended dispatch format 530 (Figure 5) and sets the C flag to "1" and the M flag to "0". If an 531 Interest message contains TLVs that are not mentioned in the 532 following compression rules, then this message MUST be sent 533 uncompressed. 535 This specification assumes that a HopLimit TLV is part of the 536 original Interest message. If such HopLimit TLV is not present, it 537 will be set with a default value of DEFAULT_NDN_HOPLIMIT prior to the 538 compression. 540 In the default use case, the Interest message is compressed with the 541 following minimal rule set: 543 1. The "Type" field of the outermost MessageType TLV is removed. 545 2. The Name TLV is compressed according to Section 5.2. For this, 546 all NameComponents are expected to be of type 547 GenericNameComponent with a length greater than 0. An 548 ImplicitSha256DigestComponent or ParametersSha256DigestComponent 549 MAY appear at the end of the name. In any other case, the 550 message MUST be sent uncompressed. 552 3. InterestLifetime TLV is moved to the end of the compressed 553 Interest and is encoded as described in Section 7. If a lifetime 554 is not a valid time-value, then the lifetime is rounded up to the 555 nearest valid time-value as specified in Section 7. 557 4. The Type and Length fields of Nonce TLV, HopLimit TLV and 558 InterestLifetime TLV are elided. The Nonce value has a length of 559 4 octets and the HopLimit value has a length of 1 octet. The 560 compressed InterestLifetime (Section 7) has a length of 1 octet. 561 The presence of an InterestLifetime TLV is deduced from the 562 remaining length to parse. 564 The compressed NDN LoWPAN Interest message is visualized in 565 Figure 12. 567 T = Type, L = Length, V = Value, Vc = Compressed Value 569 +---------+---------+ +---------+ 570 | Msg T | Msg L | | Msg L | 571 +---------+---------+---------+ +---------+ 572 | Name T | Name L | Name V | | Name Vc | 573 +---------+---------+---------+ +---------+---------+ 574 | CBPfx T | CBPfx L | | FWDH L | FWDH Vc | 575 +---------+---------+ +---------+---------+ 576 | MBFr T | MBFr L | | NONC V | 577 +---------+---------+---------+ ==> +---------+ 578 | FWDH T | FWDH L | FWDH V | | HPL V | 579 +---------+---------+---------+ +---------+---------+ 580 | NONC T | NONC L | NONC V | | APM L | APM Vc | 581 +---------+---------+---------+ +---------+---------+ 582 | ILT T | ILT L | ILT V | | ILT Vc | 583 +---------+---------+---------+ +---------+ 584 | HPL T | HPL L | HPL V | 585 +---------+---------+---------+ 586 | APM T | APM L | APM V | 587 +---------+---------+---------+ 589 Figure 12: Compression of NDN LoWPAN Interest Message 591 Further TLV compression is indicated by the ICN LoWPAN dispatch in 592 Figure 13. 594 0 1 2 3 4 5 6 7 595 +---+---+---+---+---+---+---+---+ 596 | 1 | 0 |CID|DIG|PFX|FRE|FWD|APM| 597 +---+---+---+---+---+---+---+---+ 599 Figure 13: Dispatch format for compressed NDN Interest messages 601 CID: Context Identifier See Figure 5. 603 DIG: ImplicitSha256DigestComponent TLV 605 0: The name does not include an 606 ImplicitSha256DigestComponent as the last TLV. 608 1: The name does include an 609 ImplicitSha256DigestComponent as the last TLV. The 610 Type and Length fields are omitted. 612 PFX: CanBePrefix TLV 613 0: The uncompressed message does not include a 614 CanBePrefix TLV. 616 1: The uncompressed message does include a CanBePrefix 617 TLV and is removed from the compressed message. 619 FRE: MustBeFresh TLV 621 0: The uncompressed message does not include a 622 MustBeFresh TLV. 624 1: The uncompressed message does include a MustBeFresh 625 TLV and is removed from the compressed message. 627 FWD: ForwardingHint TLV 629 0: The uncompressed message does not include a 630 ForwardingHint TLV. 632 1: The uncompressed message does include a 633 ForwardingHint TLV. The Type field is removed from 634 the compressed message. Further, all link delegation 635 types and link preference types are removed. All 636 included names are compressed according to 637 Section 5.2. If any name is not compressible, the 638 message MUST be sent uncompressed. 640 APM: ApplicationParameters TLV 642 0: The uncompressed message does not include an 643 ApplicationParameters TLV. 645 1: The uncompressed message does include an 646 ApplicationParameters TLV. The Type field is removed 647 from the compressed message. 649 5.4. Data Messages 651 5.4.1. Uncompressed Data Messages 653 An uncompressed Data message uses the base dispatch format and sets 654 the C flag to "0" and the M flag to "1" (Figure 14). "resv" MUST be 655 set to 0. The Data message is handed to the NDN network stack 656 without modifications. 658 0 1 ... 7 659 +---+---+-----------------------+ 660 | 0 | 1 | resv | 661 +---+---+-----------------------+ 663 Figure 14: Dispatch format for uncompressed NDN Data messages 665 5.4.2. Compressed Data Messages 667 The compressed Data message uses the extended dispatch format 668 (Figure 5) and sets the C flag as well as the M flag to "1". If a 669 Data message contains TLVs that are not mentioned in the following 670 compression rules, then this message MUST be sent uncompressed. 672 By default, the Data message is compressed with the following base 673 rule set: 675 1. The "Type" field of the outermost MessageType TLV is removed. 677 2. The Name TLV is compressed according to Section 5.2. For this, 678 all NameComponents are expected to be of type 679 GenericNameComponent and to have a length greater than 0. In any 680 other case, the message MUST be sent uncompressed. 682 3. The MetaInfo TLV Type and Length fields are elided from the 683 compressed Data message. 685 4. The FreshnessPeriod TLV MUST be moved to the end of the 686 compressed Data message and the length is set to 1. Type and 687 Length fields are elided and the value is encoded as described in 688 Section 7. If the freshness period is not a valid time-value, 689 then the message MUST be sent uncompressed in order to preserve 690 the security envelope of the Data message. The presence of a 691 FreshnessPeriod TLV is deduced from the remaining length to 692 parse. 694 5. The Type fields of the SignatureInfo TLV, SignatureType TLV and 695 SignatureValue TLV are removed. 697 The compressed NDN LoWPAN Data message is visualized in Figure 15. 699 T = Type, L = Length, V = Value, Vc = Compressed Value 701 +---------+---------+ +---------+ 702 | Msg T | Msg L | | Msg L | 703 +---------+---------+---------+ +---------+ 704 | Name T | Name L | Name V | | Name Vc | 705 +---------+---------+---------+ +---------+---------+ 706 | Meta T | Meta L | | CTyp L | CType V | 707 +---------+---------+---------+ +---------+---------+ 708 | CTyp T | CTyp L | CTyp V | | FBID V | 709 +---------+---------+---------+ ==> +---------+---------+ 710 | FrPr T | FrPr L | FrPr V | | CONT L | CONT V | 711 +---------+---------+---------+ +---------+---------+ 712 | FBID T | FBID L | FBID V | | Sig L | 713 +---------+---------+---------+ +---------+---------+ 714 | CONT T | CONT L | CONT V | | SInf L | SInf Vc | 715 +---------+---------+---------+ +---------+---------+ 716 | Sig T | Sig L | | SVal L | SVal Vc | 717 +---------+---------+---------+ +---------+---------+ 718 | SInf T | SInf L | SInf V | | FrPr Vc | 719 +---------+---------+---------+ +---------+ 720 | SVal T | SVal L | SVal V | 721 +---------+---------+---------+ 723 Figure 15: Compression of NDN LoWPAN Data Message 725 Further TLV compression is indicated by the ICN LoWPAN dispatch in 726 Figure 16. 728 0 1 2 3 4 5 6 7 729 +---+---+---+---+---+---+---+---+ 730 | 1 | 1 |CID|FBI|CON|KLO| RSV | 731 +---+---+---+---+---+---+---+---+ 733 Figure 16: Dispatch format for compressed NDN Data messages 735 CID: Context Identifier See Figure 5. 737 FBI: FinalBlockId TLV 739 0: The uncompressed message does not include a 740 FinalBlockId TLV. 742 1: The uncompressed message does include a FinalBlockId 743 and it is encoded according to Section 5.2. If the 744 FinalBlockId TLV is not compressible, then the 745 message MUST be sent uncompressed. 747 CON: ContentType TLV 749 0: The uncompressed message does not include a 750 ContentType TLV. 752 1: The uncompressed message does include a ContentType 753 TLV. The Type field is removed from the compressed 754 message. 756 KLO: KeyLocator TLV 758 0: If the included SignatureType requires a KeyLocator 759 TLV, then the KeyLocator represents a name and is 760 compressed according to Section 5.2. If the the name 761 is not compressible, then the message MUST be sent 762 uncompressed. 764 1: If the included SignatureType requires a KeyLocator 765 TLV, then the KeyLocator represents a KeyDigest. The 766 Type field of this KeyDigest is removed. 768 RSV: Reserved Must be set to 0. 770 6. Space-efficient Message Encoding for CCNx 772 6.1. TLV Encoding 774 The generic CCNx TLV encoding is described in [RFC8609]. Type and 775 Length fields attain the common fixed length of 2 octets. 777 The TLV encoding for CCNx LoWPAN is changed to the more space 778 efficient encoding described in Section 5.1. Hence NDN and CCNx use 779 the same compressed format for writing TLVs. 781 6.2. Name TLV Compression 783 Name TLVs are compressed using the scheme already defined in 784 Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or 785 organizational TLVs, then the name remains uncompressed. 787 6.3. Interest Messages 789 6.3.1. Uncompressed Interest Messages 791 An uncompressed Interest message uses the base dispatch format (see 792 Figure 4) and sets the C as well as the M flag to "0" (Figure 17). 793 "resv" MUST be set to 0. The Interest message is handed to the CCNx 794 network stack without modifications. 796 0 1 ... 7 797 +---+---+-----------------------+ 798 | 0 | 0 | resv | 799 +---+---+-----------------------+ 801 Figure 17: Dispatch format for uncompressed CCNx Interest messages 803 6.3.2. Compressed Interest Messages 805 The compressed Interest message uses the extended dispatch format 806 (Figure 5) and sets the C flag to "1" and the M flag to "0". If an 807 Interest message contains TLVs that are not mentioned in the 808 following compression rules, then this message MUST be sent 809 uncompressed. 811 In the default use case, the Interest message is compressed with the 812 following minimal rule set: 814 1. The Type and Length fields of the CCNx Message TLV are elided and 815 are obtained from the Fixed Header on decompression. 817 The compressed CCNx LoWPAN Interest message is visualized in 818 Figure 18. 820 T = Type, L = Length, V = Value 822 +--------------------------+ +--------------------------+ 823 | Uncompr. Fixed Header | | Compr. Fixed Header | 824 +--------------------------+ +--------------------------+ 825 +--------+--------+--------+ +--------+ 826 | ILT T | ILT L | ILT V | | ILT V | 827 +--------+--------+--------+ +--------+ 828 | MSGH T | MSGH L | MSGH V | | MSGH V | 829 +--------+--------+--------+ +--------+ 830 +--------+--------+ +--------+ 831 | MSGT T | MSGT L | | Name V | 832 +--------+--------+--------+ +--------+ 833 | Name T | Name L | Name V | ==> | KIDR V | 834 +--------+--------+--------+ +--------+ 835 | KIDR T | KIDR L | KIDR V | | OBHR V | 836 +--------+--------+--------+ +--------+--------+ 837 | OBHR T | OBHR L | OBHR V | | PAYL L | PAYL V | 838 +--------+--------+--------+ +--------+--------+ 839 | PAYL T | PAYL L | PAYL V | | VALG L | VALG V | 840 +--------+--------+--------+ +--------+--------+ 841 | VALG T | VALG L | VALG V | | VPAY L | VPAY V | 842 +--------+--------+--------+ +--------+--------+ 843 | VPAY T | VPAY L | VPAY V | 844 +--------+--------+--------+ 846 Figure 18: Compression of CCNx LoWPAN Interest Message 848 Further TLV compression is indicated by the ICN LoWPAN dispatch in 849 Figure 19. 851 0 1 852 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 853 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 854 | 1 | 0 |CID|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|EXT|RSV| 855 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 857 Figure 19: Dispatch format for compressed CCNx Interest messages 859 CID: Context Identifier See Figure 5. 861 VER: CCNx protocol version in the fixed header 863 0: The Version field equals 1 and is removed from the fixed 864 header. 866 1: The Version field is carried in-line. 868 FLG: Flags field in the fixed header 870 0: The Flags field equals 0 and is removed from the Interest 871 message. 873 1: The Flags field is carried in-line. 875 PTY: PacketType field in the fixed header 877 0: The PacketType field is elided and assumed to be 878 "PT_INTEREST" 880 1: The PacketType field is elided and assumed to be 881 "PT_RETURN" 883 HPL: HopLimit field in the fixed header 885 0: The HopLimit field is carried in-line 887 1: The HopLimit field is elided and assumed to be "1" 889 FRS: Reserved field in the fixed header 891 0: The Reserved field is carried in-line 893 1: The Reserved field is elided and assumed to be "0" 895 PAY: Optional Payload TLV 897 0: The Payload TLV is absent. 899 1: The Payload TLV is present and the type field is elided. 901 ILT: Optional Hop-By-Hop InterestLifetime TLV 903 See Section 6.3.2.1 for further details on the ordering 904 of hop-by-hop TLVs. 906 0: No InterestLifetime TLV is present in the Interest 907 message. 909 1: An InterestLifetime TLV is present with a fixed length of 910 1 octet and is encoded as described in Section 7. The 911 type and length fields are elided. If a lifetime is not 912 a valid time-value, then the lifetime is rounded up to 913 the nearest valid time-value (see Section 7). 915 MGH: Optional Hop-By-Hop MessageHash TLV 916 See Section 6.3.2.1 for further details on the ordering 917 of hop-by-hop TLVs. 919 This TLV is expected to contain a T_SHA-256 TLV. If 920 another hash is contained, then the Interest MUST be sent 921 uncompressed. 923 0: The MessageHash TLV is absent. 925 1: A T_SHA-256 TLV is present and the type as well as the 926 length fields are removed. The length field is assumed 927 to represent 32 octets. The outer Message Hash TLV is 928 omitted. 930 KIR: Optional KeyIdRestriction TLV 932 This TLV is expected to contain a T_SHA-256 TLV. If 933 another hash is contained, then the Interest MUST be sent 934 uncompressed. 936 0: The KeyIDRestriction TLV is absent. 938 1: A T_SHA-256 TLV is present and the type as well as the 939 length fields are removed. The length field is assumed 940 to represent 32 octets. The outer KeyIdRestriction TLV 941 is omitted. 943 CHR: Optional ContentObjectHashRestriction TLV 945 This TLV is expected to contain a T_SHA-256 TLV. If 946 another hash is contained, then the Interest MUST be sent 947 uncompressed. 949 0: The ContentObjectHashRestriction TLV is absent. 951 1: A T_SHA-256 TLV is present and the type as well as the 952 length fields are removed. The length field is assumed 953 to represent 32 octets. The outer 954 ContentObjectHashRestriction TLV is omitted. 956 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 958 0: No validation related TLVs are present in the Interest 959 message. 961 1: Validation related TLVs are present in the Interest 962 message. An additional octet follows immediately that 963 handles validation related TLV compressions and is 964 described in Section 6.3.2.2. 966 EXT: Extension 968 0: No extension octet follows. 970 1: An extension octet follows immediately. Extension octets 971 are used to extend the compression scheme, but are out of 972 scope of this document. 974 RSV: Reserved Must be set to 0. 976 6.3.2.1. Hop-By-Hop Header TLVs Compression 978 Hop-By-Hop Header TLVs are unordered. For an Interest message, two 979 optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several 980 more can be defined in higher level specifications. For the 981 compression specified in the previous section, the Hop-By-Hop TLVs 982 are ordered as follows: 984 1. Interest Lifetime TLV 986 2. Message Hash TLV 988 Note: Other Hop-By-Hop Header TLVs than those two remain 989 uncompressed. 991 6.3.2.2. Validation 993 0 1 2 3 4 5 6 7 8 994 +-------+-------+-------+-------+-------+-------+-------+-------+ 995 | ValidationAlg | KeyID | Reserved | 996 +-------+-------+-------+-------+-------+-------+-------+-------+ 998 Figure 20: Dispatch for Interset Validations 1000 ValidationALg: Optional ValidationAlgorithm TLV 1002 0000: An uncompressed ValidationAlgorithm TLV is included. 1004 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1005 ValidationAlgorithm TLV is included. 1007 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 1008 ValidationAlgorithm TLV is included. Additionally, a 1009 Sigtime TLV is inlined without a type and a length field. 1011 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1012 no ValidationAlgorithm TLV is included. 1014 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 1015 no ValidationAlgorithm TLV is inclued. Additionally, a 1016 Sigtime TLV is inlined without a type and a length field. 1018 0101: Reserved. 1020 0110: Reserved. 1022 0111: Reserved. 1024 1000: Reserved. 1026 1001: Reserved. 1028 1010: Reserved. 1030 1011: Reserved. 1032 1100: Reserved. 1034 1101: Reserved. 1036 1110: Reserved. 1038 1111: Reserved. 1040 KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 1042 00: The KeyId TLV is absent. 1044 01: The KeyId TLV is present and uncompressed. 1046 10: A T_SHA-256 TLV is present and the type field as well as 1047 the length fields are removed. The length field is 1048 assumed to represent 32 octets. The outer KeyId TLV is 1049 omitted. 1051 11: A T_SHA-512 TLV is present and the type field as well as 1052 the length fields are removed. The length field is 1053 assumed to represent 64 octets. The outer KeyId TLV is 1054 omitted. 1056 The ValidationPayload TLV is present if the ValidationAlgorithm TLV 1057 is present. The type field is omitted. 1059 6.4. Content Objects 1061 6.4.1. Uncompressed Content Objects 1063 An uncompressed Content object uses the base dispatch format (see 1064 Figure 4) and sets the C flag to "0" and the M flag to "1" 1065 (Figure 21). "resv" MUST be set to 0. The Content object is handed 1066 to the CCNx network stack without modifications. 1068 0 1 ... 7 1069 +---+---+-----------------------+ 1070 | 0 | 1 | resv | 1071 +---+---+-----------------------+ 1073 Figure 21: Dispatch format for uncompressed CCNx Content objects 1075 6.4.2. Compressed Content Objects 1077 The compressed Content object uses the extended dispatch format 1078 (Figure 5) and sets the C flag as well as the M flag to "1". If a 1079 Content object contains TLVs that are not mentioned in the following 1080 compression rules, then this message MUST be sent uncompressed. 1082 By default, the Content object is compressed with the following base 1083 rule set: 1085 1. The PacketType field is elided from the Fixed Header. 1087 2. The Type and Length fields of the CCNx Message TLV are elided and 1088 are obtained from the Fixed Header on decompression. 1090 The compressed CCNx LoWPAN Data message is visualized in Figure 22. 1092 T = Type, L = Length, V = Value 1094 +--------------------------+ +--------------------------+ 1095 | Uncompr. Fixed Header | | Compr. Fixed Header | 1096 +--------------------------+ +--------------------------+ 1097 +--------+--------+--------+ +--------+ 1098 | RCT T | RCT L | RCT V | | RCT V | 1099 +--------+--------+--------+ +--------+--------+ 1100 | MSGH T | MSGH L | MSGH V | | MSGH L | MSGH V | 1101 +--------+--------+--------+ +--------+--------+ 1102 +--------+--------+ +--------+ 1103 | MSGT T | MSGT L | | Name V | 1104 +--------+--------+--------+ +--------+ 1105 | Name T | Name L | Name V | ==> | EXPT V | 1106 +--------+--------+--------+ +--------+--------+ 1107 | PTYP T | PTYP L | PTYP V | | PAYL L | PAYL V | 1108 +--------+--------+--------+ +--------+--------+ 1109 | EXPT T | EXPT L | EXPT V | | VALG L | VALG V | 1110 +--------+--------+--------+ +--------+--------+ 1111 | PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V | 1112 +--------+--------+--------+ +--------+--------+ 1113 | VALG T | VALG L | VALG V | 1114 +--------+--------+--------+ 1115 | VPAY T | VPAY L | VPAY V | 1116 +--------+--------+--------+ 1118 Figure 22: Compression of CCNx LoWPAN Data Message 1120 Further TLV compression is indicated by the ICN LoWPAN dispatch in 1121 Figure 23. 1123 0 1 1124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1125 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1126 | 1 | 1 |CID|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|EXT| RSV | 1127 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1129 Figure 23: Dispatch format for compressed CCNx Content objects 1131 CID: Context Identifier See Figure 5. 1133 VER: CCNx protocol version in the fixed header 1135 0: The Version field equals 1 and is removed from the fixed 1136 header. 1138 1: The Version field is carried in-line. 1140 FLG: Flags field in the fixed header See Section 6.3.2. 1142 FRS: Reserved field in the fixed header See Section 6.3.2. 1144 PAY: Optional Payload TLV See Section 6.3.2. 1146 RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 1148 0: The Recommended Cache Time TLV is absent. 1150 1: The Recommended Cache Time TLV is present and the type as 1151 well as the length fields are elided. 1153 MGH: Optional Hop-By-Hop MessageHash TLV 1155 See Section 6.4.2.1 for further details on the ordering 1156 of hop-by-hop TLVs. 1158 This TLV is expected to contain a T_SHA-256 TLV. If 1159 another hash is contained, then the Content Object MUST 1160 be sent uncompressed. 1162 0: The MessageHash TLV is absent. 1164 1: A T_SHA-256 TLV is present and the type as well as the 1165 length fields are removed. The length field is assumed 1166 to represent 32 octets. The outer Message Hash TLV is 1167 omitted. 1169 PLTYP: Optional PayloadType TLV 1171 00: The PayloadType TLV is absent. 1173 01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA 1174 is assumed. 1176 10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY 1177 is assumed. 1179 11: The PayloadType TLV is present and uncompressed. 1181 EXP: Optional ExpiryTime TLV 1183 0: The ExpiryTime TLV is absent. 1185 1: The ExpiryTime TLV is present and the type as well as the 1186 length fields are elided. 1188 RSV: Reserved Must be set to 0. 1190 VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec 1191 tion 6.3.2. 1193 EXT: Extension See Section 6.3.2. 1195 6.4.2.1. Hop-By-Hop Header TLVs Compression 1197 Hop-By-Hop Header TLVs are unordered. For a Content Object message, 1198 two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but 1199 several more can be defined in higher level specifications. For the 1200 compression specified in the previous section, the Hop-By-Hop TLVs 1201 are ordered as follows: 1203 1. Recommended Cache Time TLV 1205 2. Message Hash TLV 1207 Note: Other Hop-By-Hop Header TLVs than those two remain 1208 uncompressed. 1210 7. Compressed Time Encoding 1212 This document defines a compressed TLV encoding format for time- 1213 values that is inspired from [RFC5497]. 8-bit time-codes are used to 1214 represent time-values ranging from milliseconds to days. 1216 Time-codes are constructed using the formula: 1218 time-code := 8 * b + a 1220 where a is the mantissa and b the exponent of a time-value that 1221 follows the form: 1223 time-value := (1 + a/8) * 2^b * C 1225 The least significant 3 bits of a time-code represents the mantissa 1226 (a) and the most significant 5 bits represent the exponent (b). C is 1227 set to 1/1024 seconds in order to achieve a millisecond resolution. 1229 A time-code of all-bits zero MUST be decoded as a time-value of all- 1230 bits zero. The smallest representable time-value is thus 0 (a=0, 1231 b=0), the second smallest is ~1 ms (a=1, b=0), and the largest time- 1232 value is ~45 days (a=7, b=31). 1234 An invalid time-value (t, in seconds) MUST be rounded up to the 1235 nearest valid time-value using this algorithm: 1237 o set b := floor(log2(t/C)) 1239 o set a := 8 * (t / (C * 2^b) - 1) 1241 8. Stateful Header Compression 1243 Stateful header compression in ICN LoWPAN enables packet size 1244 reductions in two ways. First, common information that is shared 1245 throughout the local LoWPAN may be memorized in context state at all 1246 nodes and ommitted from communication. Second, redundancy in a 1247 single Interest-data exchange may be removed from ICN stateful 1248 forwarding on a hop-by-hop bases and memorized in en-route state 1249 tables. 1251 8.1. LoWPAN-local State 1253 A context identifier (CID) is an octet that refers to a particular 1254 conceptual context between network devices and MAY be used to replace 1255 frequently appearing information, such as name prefixes, suffixes, or 1256 meta information, such as Interest lifetime. 1258 0 1 2 3 4 5 6 7 1259 +---+---+---+---+---+---+---+---+ 1260 | X | ContextID | 1261 +---+---+---+---+---+---+---+---+ 1263 Figure 24: Context Identifier. 1265 The ContextID refers to a locally-scoped unique identifyer that 1266 represents contextual state shared between sender and receiver of the 1267 corresponding frame (see Figure 24). 1269 Such state shared between senders and receivers is removed from the 1270 compressed packet prior to sending, and reinserted after reception 1271 prior to passing to the upper stack. 1273 The initial distribution and maintenance of shared context is out of 1274 scope of this document. Frames containing unknown or invalid CIDs 1275 MUST be silently discarded. 1277 8.2. En-route State 1279 In CCNx and NDN, Name TLVs are included in Interest messages, and 1280 they return in data messages. Returning Name TLVs either equal the 1281 original Name TLV, or they contain the original Name TLV as a prefix. 1283 ICN LoWPAN reduces this redundancy in responses by replacing Name 1284 TLVs with single octets that represent link-local HopIDs. HopIDs are 1285 carried as Context Identifiers of link-local scope as shown in 1286 Figure 25. 1288 0 1 2 3 4 5 6 7 1289 +---+---+---+---+---+---+---+---+ 1290 | X | HopID | 1291 +---+---+---+---+---+---+---+---+ 1293 Figure 25: Context Identifier as HopID. 1295 A HopID is valid, if not all ID bits are set to zero and invalid 1296 otherwise. This yields 127 distinct HopIDs. If this range (1...128) 1297 is exhausted, the messages MUST be sent without en-route state 1298 compression until new HopIDs are available. An ICN LoWPAN node that 1299 forwards without replacing the name by a HopID (without en-route 1300 compression) MUST invalidate the HopID by setting all ID-bits to 1301 zero. 1303 While an Interest is traversing, a forwarder generates an ephemeral 1304 HopID that is tied to a PIT entry. Each HopID MUST be unique within 1305 the local PIT and only exists during the lifetime of a PIT entry. To 1306 maintain HopIDs, the local PIT is extended by two new columns: HIDi 1307 (inbound HopIDs) and HIDo (outbound HopIDs). 1309 HopIDs are included in Interests and stored on the next hop with the 1310 resulting PIT entry in the HIDi column. The HopID is replaced with a 1311 newly generated local HopID before the Interest is forwarded. This 1312 new HopID is stored in the HIDo column of the local PIT (see 1313 Figure 26). 1315 PIT of B PIT Extension PIT of C PIT Extension 1316 +--------+------++------+------+ +--------+------++------+------+ 1317 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1318 +========+======++======+======+ +========+======++======+======+ 1319 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1320 +--------+------++------+------+ +--------+------++------+------+ 1321 ^ | ^ 1322 store | '----------------------, ,---' store 1323 | send v | 1324 ,---, /p0, h_A ,---, /p0, h_B ,---, 1325 | A | ------------------------> | B | ------------------------> | C | 1326 '---' '---' '---' 1328 Figure 26: Setting compression state en-route (Interest). 1330 Responses include HopIDs that were obtained from Interests. If the 1331 returning Name TLV equals the original Name TLV, then the name is 1332 entirely elided. Otherwise, the distinct suffix is included along 1333 with the HopID. When a response is forwarded, the contained HopID is 1334 extracted and used to match against the correct PIT entry by 1335 performing a lookup on the HIDo column. The HopID is then replaced 1336 with the corresponding HopID from the HIDi column prior to forwarding 1337 the reponse (Figure 27). 1339 PIT of B PIT Extension PIT of C PIT Extension 1340 +--------+------++------+------+ +--------+------++------+------+ 1341 | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | 1342 +========+======++======+======+ +========+======++======+======+ 1343 | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | 1344 +--------+------++------+------+ +--------+------++------+------+ 1345 | ^ | 1346 send | '----------------------, ,---' send 1347 v match | v 1348 ,---, h_A ,---, h_B ,---, 1349 | A | <------------------------ | B | <------------------------ | C | 1350 '---' '---' '---' 1352 Figure 27: Eliding Name TLVs using en-route state (data). 1354 It should be noted that each forwarder of an Interest in an ICN 1355 LoWPAN network can individuall decide whether to paricipate in en- 1356 route compression or not. However, an ICN LoWPAN node SHOULD use en- 1357 route compression whenever the stateful compression mechanism is 1358 activated. 1360 Note also that the extensions of the PIT data structure are required 1361 only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside 1362 of an ICN LoWPAN domain do not need to implement these extensions. 1364 8.3. Integrating Stateful Header Compression 1366 A CID appears whenever the CID flag is set (see Figure 5). The CID 1367 is appended to the last ICN LoWPAN dispatch octet as shown in 1368 Figure 28. 1370 ...-------+--------+-------...-------+--...-+-------... 1371 / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / 1372 ...-------+--------+-------...-------+--...-+-------... 1374 Figure 28: LoWPAN Encapsulation with ICN LoWPAN and CIDs 1376 Multiple CIDs are chained together, with the most significant bit 1377 indicating the presence of a subsequent CID (Figure 29). 1379 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1380 |1| CID | --> |1| CID | --> |0| CID | 1381 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1383 Figure 29: Chaining of context identifiers. 1385 The HopID is always included as the very first CID. 1387 9. ICNLoWPAN Constants and Variables 1389 This is a summary of all ICNLoWPAN constants and variables. 1391 DEFAULT_NDN_HOPLIMIT: 255 1393 10. Implementation Report and Guidance 1395 The ICN LoWPAN scheme defined in this document has been implemented 1396 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT 1397 version on RIOT [RIOT]. An experimental evaluation with varying 1398 configurations has been performed in [ICNLOWPAN]. 1400 The header compression performance depends on certain aspects and 1401 configurations. It works best for the following cases: 1403 o Each name component is of GenericNameComponent type and is limited 1404 to a length of 15 bytes. 1406 o Time-values for content freshness TLVs represent valid time-values 1407 as per Section 7. Interest lifetimes will round up to the nearest 1408 valid encoded time-value. 1410 o Contextual state is distributed, such that long names are elided 1411 from Interest and data messages. 1413 11. Security Considerations 1415 Main memory is typically a scarce resource of constrained networked 1416 devices. Fragmentation as described in this memo preserves fragments 1417 and purges them only after a packet is reassembled, which requires a 1418 buffering of all fragments. This scheme is able to handle fragments 1419 for distinctive packets simultaneously, which can lead to overflowing 1420 packet buffers that cannot hold all necessary fragments for packet 1421 reassembly. Implementers are thus urged to make use of appropriate 1422 buffer replacement strategies for fragments. 1424 The stateful header compression generates ephemeral HopIDs for 1425 incoming and outgoing Interests and consumes them on returning Data 1426 packets. Forged Interests can deplete the number of available 1427 HopIDs, thus leading to a denial of compression service for 1428 subsequent content requests. 1430 To further alleviate the problems caused by forged fragments or 1431 Interest initiations, proper protective mechanisms for accessing the 1432 link-layer should be deployed. 1434 12. IANA Considerations 1436 12.1. Page Switch Dispatch Type 1438 This document makes use of "Page 2" from the existing paging 1439 dispatches in [RFC8025]. 1441 13. References 1443 13.1. Normative References 1445 [ieee802.15.4] 1446 "IEEE Std. 802.15.4-2015", April 2016, 1447 . 1450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1451 Requirement Levels", BCP 14, RFC 2119, 1452 DOI 10.17487/RFC2119, March 1997, 1453 . 1455 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1456 "Transmission of IPv6 Packets over IEEE 802.15.4 1457 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1458 . 1460 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1461 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1462 DOI 10.17487/RFC6282, September 2011, 1463 . 1465 13.2. Informative References 1467 [CCN-LITE] 1468 "CCN-lite: A lightweight CCNx and NDN implementation", 1469 . 1471 [ICNLOWPAN] 1472 Gundogan, C., Kietzmann, P., Schmidt, TC., and M. 1473 Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low 1474 Power IoT Networks", Proc. of 18th IFIP Networking 1475 Conference , May 2019. 1477 [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, 1478 "Networking Named Content", 5th Int. Conf. on emerging 1479 Networking Experiments and Technologies (ACM CoNEXT), 1480 2009, . 1482 [NDN-EXP1] 1483 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 1484 Waehlisch, "Information Centric Networking in the IoT: 1485 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 1486 on Information-Centric Networking (ICN-2014) ACM DL, pp. 1487 77-86, September 2014, 1488 . 1490 [NDN-EXP2] 1491 Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 1492 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 1493 Comparative Measurement Study in the IoT", Proc. of 5th 1494 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 1495 DL, pp. 159-171, September 2018, 1496 . 1498 [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and 1499 M. Waehlisch, "The Need for a Name to MAC Address Mapping 1500 in NDN: Towards Quantifying the Resource Gain", Proc. of 1501 4th ACM Conf. on Information-Centric Networking (ICN- 1502 2017) ACM DL, pp. 36-42, September 2017, 1503 . 1505 [NDN-PACKET-SPEC] 1506 "NDN Packet Format Specification", 1507 . 1509 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1510 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1511 DOI 10.17487/RFC5497, March 2009, 1512 . 1514 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1515 Constrained-Node Networks", RFC 7228, 1516 DOI 10.17487/RFC7228, May 2014, 1517 . 1519 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1520 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1521 "Information-Centric Networking: Baseline Scenarios", 1522 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1523 . 1525 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1526 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1527 "Information-Centric Networking (ICN) Research 1528 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1529 . 1531 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1532 and G. Boggia, "Information-Centric Networking: Evaluation 1533 and Security Considerations", RFC 7945, 1534 DOI 10.17487/RFC7945, September 2016, 1535 . 1537 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1538 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1539 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1540 . 1542 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1543 Networking (CCNx) Semantics", RFC 8569, 1544 DOI 10.17487/RFC8569, July 2019, 1545 . 1547 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1548 Networking (CCNx) Messages in TLV Format", RFC 8609, 1549 DOI 10.17487/RFC8609, July 2019, 1550 . 1552 [RIOT] Baccelli, E., Guenes, M., Hahm, O., Schmidt, TC., and M. 1553 Waehlisch, "RIOT OS: Towards an OS for the Internet of 1554 Things", Proc. of the 32nd IEEE INFOCOM IEEE Press, pp. 1555 79-80, April 2013, . 1557 [TLV-ENC-802.15.4] 1558 "CCN and NDN TLV encodings in 802.15.4 packets", 1559 . 1562 [WIRE-FORMAT-CONSID] 1563 "CCN/NDN Protocol Wire Format and Functionality 1564 Considerations", . 1568 Appendix A. Estimated Size Reduction 1570 In the following a theoretical evaluation is given to estimate the 1571 gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. 1573 We assume that "n" is the number of name components, "comps_n" 1574 denotes the sum of n name component lengths. We also assume that the 1575 length of each name component is lower than 16 bytes. The length of 1576 the content is given by "clen". The lengths of TLV components is 1577 specific to the CCNx or NDN encoding and outlined below. 1579 A.1. NDN 1581 The NDN TLV encoding has variable-sized TLV fields. For simplicity, 1582 the 1 octet form of each TLV component is assumed. A typical TLV 1583 component therefore is of size 2 (type field + length field) + the 1584 actual value. 1586 A.1.1. Interest 1588 Figure 30 depicts the size requirements for a basic, uncompressed NDN 1589 Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a 1590 InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. 1591 Numbers below represent the amount of octets. 1593 ------------------------------------, 1594 Interest TLV = 2 | 1595 ---------------------, | 1596 Name | 2 + | 1597 NameComponents = 2n + | 1598 | comps_n | 1599 ---------------------' = 21 + 2n + comps_n 1600 CanBePrefix = 2 | 1601 MustBeFresh = 2 | 1602 Nonce = 6 | 1603 InterestLifetime = 4 | 1604 HopLimit = 3 | 1605 ------------------------------------' 1607 Figure 30: Estimated size of an uncompressed NDN Interest 1609 Figure 31 depicts the size requirements after compression. 1611 ------------------------------------, 1612 Dispatch Page Switch = 1 | 1613 NDN Interset Dispatch = 1 | 1614 Interest TLV = 1 | 1615 -----------------------, | 1616 Name | = 9 + n/2 + comps_n 1617 NameComponents = n/2 + | 1618 | comps_n | 1619 -----------------------' | 1620 Nonce = 4 | 1621 HopLimit = 1 | 1622 InterestLifetime = 1 | 1623 ------------------------------------' 1625 Figure 31: Estimated size of a compressed NDN Interest 1627 The size difference is: 1628 12 + 1.5n octets. 1630 For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets, 1631 which is 46% of the uncompressed packet. 1633 A.1.2. Data 1635 Figure 32 depicts the size requirements for a basic, uncompressed NDN 1636 Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1637 1 minute is assumed and the value is encoded using 1 octet. An 1638 HMACWithSha256 is assumed as signature. The key locator is assumed 1639 to contain a Name TLV of length klen. 1641 ------------------------------------, 1642 Data TLV = 2 | 1643 ---------------------, | 1644 Name | 2 + | 1645 NameComponents = 2n + | 1646 | comps_n | 1647 ---------------------' | 1648 ---------------------, | 1649 MetaInfo | | 1650 FreshnessPeriod = 6 = 53 + 2n + comps_n + 1651 | | clen + klen 1652 ---------------------' | 1653 Content = 2 + clen | 1654 ---------------------, | 1655 SignatureInfo | | 1656 SignatureType | | 1657 KeyLocator = 41 + klen | 1658 SignatureValue | | 1659 DigestSha256 | | 1660 ---------------------' | 1661 ------------------------------------' 1663 Figure 32: Estimated size of an uncompressed NDN Data 1665 Figure 33 depicts the size requirements for the compressed version of 1666 the above Data packet. 1668 ------------------------------------, 1669 Dispatch Page Switch = 1 | 1670 NDN Data Dispatch = 1 | 1671 -----------------------, | 1672 Name | = 37 + n/2 + comps_n + 1673 NameComponents = n/2 + | clen + klen 1674 | comps_n | 1675 -----------------------' | 1676 Content = 1 + clen | 1677 KeyLocator = 1 + klen | 1678 DigestSha256 = 32 | 1679 FreshnessPeriod = 1 | 1680 ------------------------------------' 1682 Figure 33: Estimated size of a compressed NDN Data 1684 The size difference is: 1685 16 + 1.5n octets. 1687 For the name "/DE/HH/HAW/BT7", the total size gain is 22 octets. 1689 A.2. CCNx 1691 The CCNx TLV encoding defines a 2-octet encoding for type and length 1692 fields, summing up to 4 octets in total without a value. 1694 A.2.1. Interest 1696 Figure 34 depicts the size requirements for a basic, uncompressed 1697 CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version 1698 is assumed to be 1 and the reserved field is assumed to be 0. A 1699 KeyIdRestriction TLV with T_SHA-256 is included to limit the 1700 responses to Content Objects containing the specific key. 1702 ------------------------------------, 1703 Fixed Header = 8 | 1704 Message = 4 | 1705 ---------------------, | 1706 Name | 4 + = 56 + 4n + comps_n 1707 NameSegments = 4n + | 1708 | comps_n | 1709 ---------------------' | 1710 KeyIdRestriction = 40 | 1711 ------------------------------------' 1713 Figure 34: Estimated size of an uncompressed CCNx Interest 1715 Figure 35 depicts the size requirements after compression. 1717 ------------------------------------, 1718 Dispatch Page Switch = 1 | 1719 CCNx Interest Dispatch = 2 | 1720 Fixed Header = 3 | 1721 -----------------------, | 1722 Name | = 38 + n/2 + comps_n 1723 NameSegments = n/2 + | 1724 | comps_n | 1725 -----------------------' | 1726 T_SHA-256 = 32 | 1727 ------------------------------------' 1729 Figure 35: Estimated size of a compressed CCNx Interest 1731 The size difference is: 1732 18 + 3.5n octets. 1734 For the name "/DE/HH/HAW/BT7", the size is reduced by 53 octets, 1735 which is 53% of the uncompressed packet. 1737 A.2.2. Content Object 1739 Figure 36 depicts the size requirements for a basic, uncompressed 1740 CCNx Content Object containing an ExpiryTime Message TLV, an 1741 HMAC_SHA-256 signature, the signature time and a hash of the shared 1742 secret key. In the fixed header, the protocol version is assumed to 1743 be 1 and the reserved field is assumed to be 0 1745 ------------------------------------, 1746 Fixed Header = 8 | 1747 Message = 4 | 1748 ---------------------, | 1749 Name | 4 + | 1750 NameSegments = 4n + | 1751 | comps_n | 1752 ---------------------' | 1753 ExpiryTime = 12 = 124 + 4n + comps_n + clen 1754 Payload = 4 + clen | 1755 ---------------------, | 1756 ValidationAlgorithm | | 1757 T_HMAC-256 = 56 | 1758 KeyId | | 1759 SignatureTime | | 1760 ---------------------' | 1761 ValidationPayload = 36 | 1762 ------------------------------------' 1764 Figure 36: Estimated size of an uncompressed CCNx Content Object 1766 Figure 37 depicts the size requirements for a basic, compressed CCNx 1767 Data. 1769 ------------------------------------, 1770 Dispatch Page Switch = 1 | 1771 CCNx Content Dispatch = 3 | 1772 Fixed Header = 2 | 1773 -----------------------, | 1774 Name | | 1775 NameSegments = n/2 + | 1776 | comps_n = 89 + n/2 + comps_n + clen 1777 -----------------------' | 1778 ExpiryTime = 8 | 1779 Payload = 1 + clen | 1780 T_HMAC-SHA256 = 32 | 1781 SignatureTime = 8 | 1782 ValidationPayload = 34 | 1783 ------------------------------------' 1785 Figure 37: Estimated size of a compressed CCNx Data Object 1787 The size difference is: 1788 35 + 3.5n octets. 1790 For the name "/DE/HH/HAW/BT7", the size is reduced by 70 octets, 1791 which is 40% of the uncompressed packet containing a 4-octet payload. 1793 Acknowledgments 1795 This work was stimulated by fruitful discussions in the ICNRG 1796 research group and the communities of RIOT and CCNlite. We would 1797 like to thank all active members for constructive thoughts and 1798 feedback. In particular, the authors would like to thank (in 1799 alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, 1800 Junxiao Shi. The hop-wise stateful name compression was brought up in 1801 a discussion by Dave Oran, which is gratefully acknowledged. Larger 1802 parts of this work are inspired by [RFC4944] and [RFC6282]. Special 1803 mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi 1804 Ravindran as their previous work in [TLV-ENC-802.15.4] and 1805 [WIRE-FORMAT-CONSID] provided a good base for our discussions on 1806 stateless header compression mechanisms. This work was supported in 1807 part by the German Federal Ministry of Research and Education within 1808 the projects I3 and RAPstore. 1810 Authors' Addresses 1811 Cenk Gundogan 1812 HAW Hamburg 1813 Berliner Tor 7 1814 Hamburg D-20099 1815 Germany 1817 Phone: +4940428758067 1818 EMail: cenk.guendogan@haw-hamburg.de 1819 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 1821 Thomas C. Schmidt 1822 HAW Hamburg 1823 Berliner Tor 7 1824 Hamburg D-20099 1825 Germany 1827 EMail: t.schmidt@haw-hamburg.de 1828 URI: http://inet.haw-hamburg.de/members/schmidt 1830 Matthias Waehlisch 1831 link-lab & FU Berlin 1832 Hoenower Str. 35 1833 Berlin D-10318 1834 Germany 1836 EMail: mw@link-lab.net 1837 URI: http://www.inf.fu-berlin.de/~waehl 1839 Christopher Scherb 1840 University of Basel 1841 Spiegelgasse 1 1842 Basel CH-4051 1843 Switzerland 1845 EMail: christopher.scherb@unibas.ch 1847 Claudio Marxer 1848 University of Basel 1849 Spiegelgasse 1 1850 Basel CH-4051 1851 Switzerland 1853 EMail: claudio.marxer@unibas.ch 1854 Christian Tschudin 1855 University of Basel 1856 Spiegelgasse 1 1857 Basel CH-4051 1858 Switzerland 1860 EMail: christian.tschudin@unibas.ch