idnits 2.17.1 draft-toutain-6lpwa-ipv6-static-context-hc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 53 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2016) is 2867 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain 5 Expires: December 23, 2016 Institut MINES TELECOM ; TELECOM Bretagne 6 June 21, 2016 8 6LPWA Static Context Header Compression (SCHC) for IPV6 and UDP 9 draft-toutain-6lpwa-ipv6-static-context-hc-01 11 Abstract 13 This document describes a header compression scheme for IPv6, IPv6/ 14 UDP based on static contexts. This technique is especially tailored 15 for LPWA networks and could be extended to other protocol stacks. 17 During the IETF history several compression mechanisms have been 18 proposed. First mechanisms, such as RoHC, are using a context to 19 store header field values and send smaller incremental differences on 20 the link. Values in the context evolve dynamically with information 21 contained in the compressed header. The challenge is to maintain 22 sender's and receiver's contexts synchronized even with packet 23 losses. Based on the fact that IPv6 contains only static fields, 24 6LoWPAN developed an efficient context-free compression mechanisms, 25 allowing better flexibility and performance. 27 The Static Context Header Compression (SCHC) combines the advantages 28 of RoHC context which offers a great level of flexibility in the 29 processing of fields, and 6LoWPAN behavior to elide fields that are 30 known from the other side. Static context means that values in the 31 context field do not change during the transmission, avoiding complex 32 resynchronization mechanisms, incompatible with LPWA characteristics. 33 In most of the cases, IPv6/UDP headers are reduced to a small 34 identifier. 36 This document focuses on IPv6/UDP headers compression, but the 37 mechanism can be applied to other protocols such as CoAP. It will be 38 described in a separate document. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 23, 2016. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 1. Introduction 74 Headers compression is mandatory to bring the internet protocols to 75 the node within a LPWA network [I-D.minaburo-lp-wan-gap-analysis]. 77 Nevertheless, LPWA networks offer good properties for an efficient 78 header compression: 80 o Topology is star oriented, therefore all the packets follows the 81 same path. For the needs of this draft, the architecture can be 82 summarized to End-Systems (ES) exchanging information with a 83 single LPWA Compressor (LC). In most of the cases, End Systems 84 and LC form a star topology. ESs and LC maintain a context for 85 compression. 87 o Traffic flows are mostly deterministic, since End-Systems embed 88 built-in applications. Contrary to computers or smartphones, new 89 applications cannot be easily installed. 91 First mechanisms such as RoHC use a context to store header field 92 values and send smaller incremental differences on the link. The 93 first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the 94 principle to any protocol and introduces a formal notation [RFC4997] 95 describing the header and associating compression functions to each 96 field. To be efficient the sender and the receiver must check that 97 the context remains synchronized (i.e. contains the same values). 99 Context synchronization imposes to periodically send a full header or 100 at least dynamic fields. If fully compressed, the header can be 101 compatible with LPWA constraints. However, the first exchanges or 102 context resynchronisations impose to send uncompressed headers, which 103 may be bigger than the original one. This will force the use of 104 inefficient fragmentation mechanisms. For some LPWA technologies, 105 duty cycle limits can also delay the resynchronization. Figure 1 106 illustrates this behavior. 108 sync 109 ^ +-+ sync sync ^ 110 | IPv6 | | +-+ +-+ | IPv6 111 v | | | | | | v 112 +------------+ | +-+-+ | | | | +------------+ 113 | +--+ | | | | | | | | | | +--+ | 114 | | c| | | | | +-+-+-+ +-+-+-+-+ | | | c| | 115 | | t| | | | | | | | | | | | | | | | | t| | 116 | | x| | +-+-+-+-+-+-+-+-+-+-+-+-+ | | x| | 117 | | t| | <----------------------------> | | t| | 118 | +--+ | | +--+ | 119 +------------+ +------------+ 121 Figure 1: RoHC Compressed Header size evolution. 123 On the other hand, 6LoWPAN [RFC4944] is context-free based on the 124 fact that IPv6, its extensions or UDP headers do not contain 125 incremental fields. The compression mechanism described in [RFC6282] 126 is based on sending a 2-byte bitmap, which describes how the header 127 should be decompressed, either using some standard values or sending 128 information after this bitmap. [RFC6282] also allows for UDP 129 compression. 131 In the best case, when Hop limit is a standard value, flow label, 132 DiffServ fields are set to 0 and Link Local addresses are used over a 133 single hop network, the 6LoWPAN compressed header is reduced to 4 134 bytes. This compression ratio is possible because the IID are 135 derived from the MAC addresses and the link local prefix is known 136 from both sides. In that case, the IPv6 compression is 4 bytes and 137 UDP compression is 2 bytes, which fills half of the payload of a 138 SIGFOX frame, or more than 10% of a LoRaWAN payload (with spreading 139 factor 12). 141 The Static Context Header Compression (SCHC) combines the advantages 142 of RoHC context, which offers a great level of flexibility in the 143 processing of fields, and 6LoWPAN behavior to elide fields that are 144 known from the other side. Static context means that values in the 145 context field do not change during the transmission, avoiding complex 146 resynchronization mechanisms, incompatible with LPWA characteristics. 147 In most of the cases, IPv6/UDP headers are reduced to a small context 148 identifier. 150 2. Static Context Header Compression 152 Static Context Header Compression (SCHC) avoids context 153 synchronization, which is the most bandwidth-consuming operation in 154 RoHC. Based on the fact that the nature of data flows is highly 155 predictable in LPWA networks, a static context may be stored on the 156 End-System (ES). The other end, the LPWA Compressor (LC) can learn 157 the context through a provisionning protocol during the 158 identification phase (for instance, as it learns the encryption key). 160 The context contains an ordered list of rules. Each rule is a vector 161 of entries. Each entry is composed of a field descriptor, a 162 prescribed matching value, a matching rule for the compression side, 163 a matching rule for the decompression side and a compression/ 164 decompression action. Contexts in the compressor and decompressor 165 are the same. A rule is identified by a rule identifier. If the 166 layer 2 allows it, the rule id can be carried in the layer 2 header. 167 Otherwise the rule id is located in the first byte of the L2 payload. 169 Being at the boundary between Layer 2 and Layer 3, the rule id will 170 also be called a shim id. Different ES will use the same shim id to 171 identify their own context. An LC may also use the ES device id to 172 identify the appropriate rule. 174 +---------------------------------------------------------------------+ 175 | Rule N | 176 +---------------------------------------------------------------------+ | 177 | Rule i | | 178 +---------------------------------------------------------------------+ | | 179 | Rule 1 | | | 180 | +---------+-------+------------+--------------+-----------------+ | | | 181 | | Field 1 | Value |match. comp.| match decomp | Action function | | | | 182 | +---------+-------+------------+--------------+-----------------+ | | | 183 | | Field 2 | Value |match. comp.| match decomp | Action function | | | | 184 | +---------+-------+------------+--------------+-----------------+ | | | 185 | | ... | ... |... | ... | ... | | | | 186 | +---------+-------+------------+--------------+-----------------+ | |----+ 187 | | Field N | Value |match. comp.| match decomp | Action function | | | 188 | +---------+-------+------------+--------------+-----------------+ |------+ 189 | | 190 +---------------------------------------------------------------------+ 192 Figure 2: Context in LC 194 The compression/decompression process follows several steps: 196 o compression rule selection: the goal is to identify which rule 197 will be used to compress the headers. To each field is associated 198 a matching rule for compression. Each header field's value is 199 compared to the corresponding value stored in the rule for that 200 field using the matching operator. If all the fields match, the 201 packet is processed using this rule action functions and the rule 202 list exploration is aborted. Otherwise the next rule is tested. 203 If no rule is found, then the packet is dropped. 205 o compression: the action function indicates is the field is send on 206 the link or not. A field can also be partially sent regarding the 207 matching operator. The resulting compressed header must be 208 aligned on byte boundaries. 210 o decompression rule selection, as for compression, a rule has to be 211 selected to uncompress incoming packets. A matching operator is 212 defined on the compress header and works as for compression. 214 o decompression: the same action function indicates how the field 215 value can be rebuilt, either from bits received on the link, a 216 value stored in the rule or by using a specific algorithm. 218 3. Matching operators 220 Matching a field with a value and header compression are related 221 operations; If a field matches a rule containing the value, it is not 222 necessary to send it on the link. Since context are synchronized, 223 reading the rule's value is enough to reconstruct the field's value 224 at the other end. 226 On some other cases, the value need to be sent on the link to inform 227 the other end. The field value may vary from one packet to another, 228 therefore the field cannot be used to select the rule id. 230 It may exist some intermediary cases, where part of the value may be 231 used to select a field and a variable part has to be sent on the 232 link. This is true for Least Significant Bits (LSB) where the most 233 significant bit can be used to select a rule id and the least 234 significant bits has to be sent on the link. 236 Several matching operators are defined: 238 o = : a field value in a packet matches with a field value in a rule 239 if they are equal. 241 o no : no check is done between a field value in a packet matches 242 with a field value in the rule 244 o lbs(L) : a field value of length T in a packet matches with a 245 field value in a rule if the most significant T-L bits are equal. 247 4. Action functions 249 The action functions describe the action taken by the compression and 250 inversely the action taken by the decompressor to restore the 251 original value. 253 /--------------------+-------------+--------------------------\ 254 | Function | Compression | Decompression | 255 | | | | 256 +--------------------+-------------+--------------------------+ 257 |elided |not sent |use value stored in ctxt | 258 |send-value |send |build field from value | 259 |compute-IPv6-length |elided |compute IPv6 length | 260 |compute-UDP-length |elided |compute UDP length | 261 |compute-UDP-checksum|elided |compute UDP checksum | 262 |ESiid-DID |elided |build IID from L2 ES addr | 263 |LCiid-DID |elided |build IID from L2 LA addr | 264 \--------------------+-------------+--------------------------/ 266 Figure 3: Simplified Protocol Stack for LP-WAN 268 Figure 3 lists all the functions defined to compress and decompress a 269 field. The first column gives the function's name. The second and 270 third columns outlines the compression/decompression process. 272 As with 6LoWPAN, the compression process may produce some data, where 273 fields that were not compressed (or were partially compressed) will 274 be sent in the order of the original packet. Information added by 275 the compression phase must be aligned on byte boundaries, but each 276 individual compression function may generate any size. 278 /-----------------+---------------------+----------------------------------------\ 279 | Field |Function | Behavior | 280 +-----------------+---------------------+----------------------------------------+ 281 |IPv6 version |elided |The value is not sent, but each end | 282 |IPv6 DiffServ | |agrees on a value, which can be | 283 |IPv6 Flow Label | |different from 0. | 284 |IPv6 Next Header |send-value |Depending on the matching operator, the | 285 | | |entire field value is sent or an | 286 | | |adjustment to the context value | 287 +-----------------+---------------------+----------------------------------------+ 288 |IPv6 Length |compute-IPv6-length |Dedicated function to reconstruct value | 289 +-----------------+---------------------+----------------------------------------+ 290 |IPv6 Hop Limit |elided+no matching |The receiver will put a value stored in | 291 | | |the context. It may be different from | 292 | | |one originally sent, but in a star | 293 | | |topology, there is not risk of loops | 294 | |elided+matching |Receiver and sender agree on the value. | 295 | | |If the value is not correct the packet | 296 | | |the rule is not selected | 297 | |send-value |Explicitly sent | 298 +-----------------+---------------------+----------------------------------------+ 299 |IPv6 ESPrefix |elided |The 64 bit prefix is stored on the ctxt | 300 |IPv6 LCPrefix |send-value |Explicitly send 64 bits on the link | 301 +-----------------+---------------------+----------------------------------------+ 302 |IPv6 ESiid |elided |IID is not sent, but stored in the ctxt | 303 |IPv6 LCiid |ESiid-DID | LCiid-DID|IID is built from the ES Device ID | 304 | |send-value |IID is explicitly sent on the link. The | 305 | | |size depends of the L2 technology | 306 +-----------------+---------------------+----------------------------------------+ 307 |UDP ESport |elided |In the context | 308 |UDP LCport |send-value |Send the 2 bytes of the port number | 309 | | |or less if lsb matching is specified in | 310 | | |the matching operator. | 311 +-----------------+---------------------+----------------------------------------+ 312 |UDP length |compute-UDP-length |Dedicated function to reconstruct value | 313 +-----------------+---------------------+----------------------------------------+ 314 |UDP Checksum |compute-UDP-checksum |Dedicated function to reconstruct value | 315 +-----------------+---------------------+----------------------------------------+ 317 Figure 4: SCHC functions' example assignment for IPv6 and UDP 319 Figure 4 gives an example of function assignment to IPv6/UDP fields. 321 4.1. Action functions 322 4.1.1. Elided 324 The compressor do not sent the field value on the link. The 325 decompressor restore the field value with the one stored in the 326 matched rule. 328 4.1.2. Send-value 330 The compressor send the field value on the link, if the matching 331 operator is "=". Otherwise the matching operator indicates the 332 information that will be sent on the link. For a LSB operator only 333 the Least Significant Bits are sent. 335 4.1.3. ESiid-DID, LCiid-DID 337 These functions are used to process respectively the End System and 338 the LC Device Identifier (DID). The IID value is computed from 339 device ID present in the Layer 2 header. The computation depends of 340 the technology and the device ID size. 342 5. Examples 344 This section gives some scenarios of the compression mechanism for 345 IPv6/UDP. The goal is to illustrate the SCHC behaviour. 347 5.1. IPv6/UDP compression in a star topology 349 The most common case will be a LPWA end-system embeds some 350 applications running over CoAP. In this example, the first flow is 351 for instance for the device management based on CoAP using Link Local 352 addresses and UDP ports 123 and 124. The second flow will be a CoAP 353 server for measurements done by the end-system (using ports 5683) and 354 Global Addresses alpha::IID/64 to beta::1/64. The last flow is for 355 legacy applications using different ports numbers, the destination is 356 gamma::1/64. 358 Figure 5 presents the protocol stack for this end-system. IPv6 and 359 UDP are represented with dotted lines since these protocols are 360 compressed on the radio link. The rule ID is represented by a shim 361 id (respectively 0, 1 and 2). 363 Managment Data 364 +----------+---------+---------+ 365 | CoAP | CoAP | legacy | 366 +----||----+---||----+---||----+ 367 . UDP . UDP | UDP | 368 ................................ 369 . IPv6 . IPv6 . IPv6 . 370 +--SHIM0------SHIM1-----SHIM2--+ 371 | 6LPWA L2 technologies | 372 +------------------------------+ 373 End System or LPWA GW 375 Figure 5: Simplified Protocol Stack for LP-WAN 377 Note that in some LPWA technologies, only End Systems have a device 378 ID . Therefore it is necessary to define statically an IID for the 379 Link Local address for the LPWA Compressor. 381 +----------------+---------+--------+--------+-------------++------+ 382 | Field | Value | Match | Match | Function || Sent | 383 +----------------+---------+-----------------+-------------++------+ 384 |LPWA SHIM |0 | No | = | send-value || 0 | 385 |ESDevice-ID |dev-id | No | = | elided || | 386 +================+=========+========+========+=============++======+ 387 |IPv6 version |6 | = | No | elided || | 388 |IPv6 DiffServ |0 | = | No | elided || | 389 |IPv6 Flow Label |0 | = | No | elided || | 390 |IPv6 Length |XXXXXXXXX| No | No | comp-IPv6-l || | 391 |IPv6 Next Header|17 | = | No | elided || | 392 |IPv6 Hop Limit |255 | No | No | elided || | 393 |IPv6 ESprefix |FE80::/64| = | No | elided || | 394 |IPv6 ESiid | | No | No | ESiid-DID || | 395 |IPv6 LCprefix |FE80::/64| = | No | elided || | 396 |IPv6 LCiid |::1 | = | No | elided || | 397 +================+=========+========+========+=============++======+ 398 |UDP ESport |123 | = | No | elided || | 399 |UDP LCport |124 | = | No | elided || | 400 |UDP Length |XXXXXXXXX| No | No | comp-UDP-l || | 401 |UDP checksum |XXXXXXXXX| No | No | comp-UDP-c || | 402 +================+=========+========+========+=============++======+ 404 +----------------+---------+--------+--------+-------------++------+ 405 | Field | Value | Match | Match | Function || Sent | 406 +----------------+---------+-----------------+-------------++------+ 407 |LPWA SHIM |1 | No | = | send-value || 1 | 408 |ESDevice-ID |dev-id | No | = | elided || | 409 +================+=========+========+========+=============++======+ 410 |IPv6 version |6 | = | No | elided || | 411 |IPv6 DiffServ |0 | = | No | elided || | 412 |IPv6 Flow Label |0 | = | No | elided || | 413 |IPv6 Length |XXXXXXXXX| No | No | comp-IPv6-l || | 414 |IPv6 Next Header|17 | = | No | elided || | 415 |IPv6 Hop Limit |255 | No | No | elided || | 416 |IPv6 ESprefix |alpha/64 | = | No | elided || | 417 |IPv6 ESiid | | No | No | ESiid-DID || | 418 |IPv6 LCprefix |beta/64 | = | No | elided || | 419 |IPv6 LCiid |::1000 | = | No | elided || | 420 +================+=========+========+========+=============++======+ 421 |UDP ESport |5683 | = | No | elided || | 422 |UDP LCport |5683 | = | No | elided || | 423 |UDP Length |XXXXXXXXX| No | No | comp-UDP-l || | 424 |UDP checksum |XXXXXXXXX| No | No | comp-UDP-c || | 425 +================+=========+========+========+=============++======+ 427 +----------------+---------+--------+--------+-------------++------+ 428 | Field | Value | Match | Match | Function || Sent | 429 +----------------+---------+-----------------+-------------++------+ 430 |LPWA SHIM |2 | No | = | send-value || 2 | 431 |ESDevice-ID |dev-id | No | = | elided || | 432 +================+=========+========+========+=============++======+ 433 |IPv6 version |6 | = | No | elided || | 434 |IPv6 DiffServ |0 | = | No | elided || | 435 |IPv6 Flow Label |0 | = | No | elided || | 436 |IPv6 Length |XXXXXXXXX| No | No | comp-IPv6-l || | 437 |IPv6 Next Header|17 | = | No | elided || | 438 |IPv6 Hop Limit |255 | No | No | elided || | 439 |IPv6 ESprefix |alpha/64 | = | No | elided || | 440 |IPv6 ESiid | | No | No | ESiid-DID || | 441 |IPv6 LCprefix |gamma/64 | = | No | elided || | 442 |IPv6 LCiid |::1000 | = | No | elided || | 443 +================+=========+========+========+=============++======+ 444 |UDP ESport |8720 | lsb(4) | No | elided || lsb | 445 |UDP LCport |8720 | lsb(4) | No | elided || lsb | 446 |UDP Length |XXXXXXXXX| No | No | comp-UDP-l || | 447 |UDP checksum |XXXXXXXXX| No | No | comp-UDP-c || | 448 +================+=========+========+========+=============++======+ 450 Figure 6: Simplified Protocol Stack for LP-WAN 452 All the fields described in the three rules Figure 6 are present in 453 the IPv6 and UDP headers. Two fields have been added at the begin, 454 they are used to identify the rule id for decompression when the 455 other end receives the compressed header. The shim id is read either 456 from the L2 header or from the first bit in the payload depending on 457 the technology. The ESDevice-ID value is found in the L2 header. 459 The second and third rules use global addresses. The way the ES 460 learn the prefix is not in the scope of the document. One possible 461 way is to use a management protocol to set up in both end rules the 462 prefix used on the LPWA network. 464 The third rule compresses port numbers on 4 bits. This value is 465 selected to maintain alignment on byte boundaries for the compressed 466 header. 468 6. Acknowledgements 470 Thanks to Dominique Barthel, Alexander Pelov, Juan Carlos Zuniga for 471 useful design consideration. 473 7. Normative References 475 [I-D.minaburo-lp-wan-gap-analysis] 476 Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP 477 Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in 478 progress), February 2016. 480 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 481 "Transmission of IPv6 Packets over IEEE 802.15.4 482 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 483 . 485 [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust 486 Header Compression (ROHC-FN)", RFC 4997, 487 DOI 10.17487/RFC4997, July 2007, 488 . 490 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 491 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 492 DOI 10.17487/RFC6282, September 2011, 493 . 495 Authors' Addresses 497 Ana Minaburo 498 Acklio 499 2bis rue de la Chataigneraie 500 35510 Cesson-Sevigne Cedex 501 France 503 Email: ana@ackl.io 504 Laurent Toutain 505 Institut MINES TELECOM ; TELECOM Bretagne 506 2 rue de la Chataigneraie 507 CS 17607 508 35576 Cesson-Sevigne Cedex 509 France 511 Email: Laurent.Toutain@telecom-bretagne.eu