idnits 2.17.1 draft-toutain-lp-wan-compression-context-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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.) ** The abstract seems to contain references ([RFC4997]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 19, 2016) is 2900 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 388 -- Looks like a reference, but probably isn't: '8' on line 243 -- Looks like a reference, but probably isn't: '16' on line 320 -- Looks like a reference, but probably isn't: '15' on line 309 -- Looks like a reference, but probably isn't: '64' on line 315 -- Looks like a reference, but probably isn't: '17' on line 333 -- Looks like a reference, but probably isn't: '18' on line 319 -- Looks like a reference, but probably isn't: '19' on line 320 -- Looks like a reference, but probably isn't: '4' on line 333 -- Looks like a reference, but probably isn't: '11' on line 334 -- Looks like a reference, but probably isn't: '123' on line 334 -- Looks like a reference, but probably isn't: '12' on line 335 -- Looks like a reference, but probably isn't: '124' on line 335 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). 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: October 21, 2016 Institut MINES TELECOM ; TELECOM Bretagne 6 April 19, 2016 8 LP-WAN Compression Context 9 draft-toutain-lp-wan-compression-context-00 11 Abstract 13 This documents describes a way to adapt the formal notation to the 14 IoT context, especially for LP-WAN communication where packet size is 15 drastically limited. It is also necessary to simplify several 16 notation and avoid a specific notation. Concept described in 17 [RFC4997] may be written in CBOR or YANG. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 21, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 Robust Header Compression (RoHC) [RFC3095] has been originally 54 designed to compress the IP/UDP/RTP headers mainly to allow the use 55 of SIP on 3G networks. The protocol has been extended by a Formal 56 Notation (FN) [RFC4997] allowing to compress any protocol headers. 57 Original uncompressed packet header format is described using that 58 formal notation and several compressed packet header are derived. 59 RoHC state machine can chose which compress format to use regarding 60 the context evolution. RoHC state machine progressively reduce the 61 header size by sending only changing fields either integrally or 62 through delta. A context must be established on the sender and the 63 receiver to reconstruct the header. Several modes and several 64 degrees of compression are available. This document [1] gives an 65 overview of RoHC behavior. 67 This documents describes a way to adapt the formal notation to the 68 IoT context, especially for LP-WAN communication where packet size is 69 drastically limited [I-D.minaburo-lp-wan-gap-analysis] . It is also 70 necessary to simplify several notation and avoid a specific notation. 71 Concept described in [RFC4997] may be written in CBOR or YANG. 73 2. Formal Notation 75 [RFC4997] annex A gives a very good tutorial on the formal notation 76 language and how different kinds of compressed headers that may be 77 defined regarding the field behavior. The objective of the rest of 78 this chapter is to take elements that can be useful is the LP-WAN 79 context. 81 eg_header 82 { 83 UNCOMPRESSED { 84 field_1 [ 2 ]; 85 } 87 COMPRESSED initial_definition { 88 field_1 =:= fct(x); 89 } 90 } 92 Figure 1: Simplest header representation 94 Figure 1 represents a very simple header composed of a single field. 95 Two representations of the field are described: the uncompressed and 96 the compressed one. The link between the both is done through the 97 name: field_1 in the example. 99 The link between the compressed and decompressed value is done by a 100 function. This function is bi-directional, which means that "fct" in 101 the example can be used to go from the uncompressed value to the 102 compressed one or vice versa. The symbol "=:=" describes the call to 103 that fonction. Note that since the fonction is bi-directionnal, the 104 definition could have been done also in the uncompressed description. 105 Function can take some arguments ("x" in the example). 107 The size of the field as to be defined, at least in the uncompressed 108 description and given between square brackets. In the example, the 109 length is 2 bits. 111 eg_header 112 { 113 UNCOMPRESSED { 114 version_no [ 2 ]; 115 type [ 2 ]; 116 flow_id [ 4 ]; 117 sequence_no [ 4 ]; 118 flag_bits [ 4 ]; 119 } 120 COMPRESSED initial_definition { 121 version_no =:= irregular(2); 122 type =:= irregular(2); 123 flow_id =:= irregular(4); 124 sequence_no =:= irregular(4); 125 flag_bits =:= irregular(4); 126 } 127 } 129 Figure 2: Null compression 131 This example, taken from [RFC4997] annex A, represents a null 132 compression, since the compressed and uncompressed headers will be 133 exactly the same. The function "irregular" describes the field 134 behavior as non predictable, therefore the value has to be sent. The 135 argument is the size of the field. 137 The example continues with a effective compression. 139 eg_header 140 { 141 UNCOMPRESSED { 142 version_no [ 2 ]; 143 type [ 2 ]; 144 flow_id [ 4 ]; 145 sequence_no [ 4 ]; 146 abc_flag_bits [ 3 ]; 147 reserved_flag [ 1 ]; 148 } 149 COMPRESSED obvious { 150 version_no =:= uncompressed_value(2, 1); 151 type =:= irregular(2); 152 flow_id =:= static; 153 sequence_no =:= lsb(0, -3); 154 abc_flag_bits =:= irregular(3); 155 reserved_flag =:= uncompressed_value(1, 0); 156 } 157 } 159 Figure 3: Header compression 161 Several functions are called: 163 o uncompressed_value (2, 1) indicates that the value of the field is 164 always '01'. therefore it can be suppressed from the compressed 165 header or added to the uncompressed header. 167 o static indicates that the field does not change during the 168 transmission of a specific flow. Static fields are not sent in 169 the compressed format, but the initial value has to be known by 170 both sides by another mean. 172 o lsb allows to send in few bits a small modification in the field 173 value. 175 3. Compression of IPv6 and UDP 177 One possible way to compress header in LP-WAN is to use a shim. A 178 shim is a byte between layer 2 and 3 describing a compressed protocol 179 stack. In the example, Figure 4 CoAP is used both for configuration 180 and for user's applications. The first stack uses UDP ports 123 and 181 124 and the other UDP ports 8356. Respectively, shim 0 and 1 are 182 associated to these stacks. In this example, CoAP is not compressed. 183 We also suppose that the source and destination addresses are link- 184 local. 186 | 187 |auth|cool | 188 +----------+---------+ 189 | CoAP | CoAP | 190 +....||....+...||....+ 191 : UDP : UDP : 192 :..........:.........: 193 : 6LP : 6LP : 194 +-------------------------------------------------------+ 195 | SHIM | 196 +-------------------------------------------------------+ 197 | LP-WAN L2 technologies | 198 +-------------------------------------------------------+ 200 Figure 4: Simplified Protocol Stack for LP-WAN 202 Figure 5 describes the definition of the IPv6/UDP protocol stack 203 based on [RFC5225]. 205 IPv6_udp_compression { 206 UNCOMPRESSED { 207 version =:= uncompressed_value(4, 6) [ 4 ]; 208 tos_tc =:= uncompressed_value(8, 0) [ 8 ]; 209 flow_label =:= uncompressed_value(20, 0) [ 20 ]; 210 payload_length =:= inferred_ip_v6_length [ 16 ]; 211 next_header =:= uncompressed_value(8, 17) [ 8 ]; 212 ttl_hopl =:= uncompressed_value(8, 64) [ 8 ]; 213 src_addr_prf =:= uncompressed_value(64, FE80)[ 64]; 214 src_addr_iid =:= inferred_mac_src_iid(64, FE80)[ 64]; 215 dst_addr_prf =:= uncompressed_value(64, FE80) [ 64]; 216 dst_addr_iid =:= inferred_mac_dst_iid(64, FE80)[ 64]; 218 src_port [ 16 ]; 219 dst_port [ 16 ]; 220 udp_length =:= inferred_udp_length [ 16 ]; 221 checksum =:= inferred_udp_chk [ 16 ]; 222 } 224 Figure 5: IPv6/UDP header description 226 The main difference is the split in two fields of the source and 227 destination address to be closer to 6LoWPAN [RFC6282]. Two 228 compression methods will have to be defined to take the IID from the 229 MAC address. Some compression methods are also used to elude the 230 length and checksum during the transmission. 232 COMPRESSED shim_0{ 233 ENFORCE(next_header.UVALUE == 17) 234 ENFORCE(src_port.UVALUE == 123) 235 ENFORCE(dst_port.UVALUE == 124) 236 shim =:= uncompress_value (8, 0) [8] 237 } 239 COMPRESSED shim_1{ 240 ENFORCE(next_header.UVALUE == 17) 241 ENFORCE(src_port.UVALUE == 8356) 242 ENFORCE(dst_port.UVALUE == 8356) 243 shim =:= uncompress_value (8, 1) [8] 244 } 246 Figure 6: IPv6/UDP compression to a shim 248 The compression methods are defined Figure 3. They use the ENFORCE 249 statement from the RoHC-FN. UVALUE also is used to access to the 250 uncompressed value of a field. Therefore, to send shim 0, the 251 protocol must be UDP and the port correspond to 123 and 124. The 252 approach for shim 1 is the same. 254 NOTE: the description will differ for the sender and receiver since 255 source and destination ports need to be swapped. It could be 256 interested to find a more generic description. 258 4. 6WIDe representation 260 The use of the formal notation may be to complex for nodes. A more 261 compact representation should be used. CBOR is a good candidate. 262 This is a first attempt to transform the description seen in 263 Section 3. This also can derive from a Yang model. 265 A compression/decompression context is represented by an CBOR array 266 containing in the first element a array of the fields present in the 267 uncompressed header and reference to functions doing the conversion 268 (this can be also an array when function ask for arguments). This is 269 followed by one on several compressed headers. Compressed header are 270 composed of two arrays. The first one correspond to the predicate 271 allowing to access the compression (sort of ENFORCE). The second one 272 contains the field of the compressed header followed by a reference 273 to a function to do the conversion. If the reference is negative, it 274 creates a new field of this size. 276 [ // beginning of the compression/decompression context 277 [ // first element, uncompressed packet description 278 [size in bit, function] // field 1 279 [size in bit, function] // field 2 280 [size in bit, function] // field 3 281 .... 282 ] // end of first element 283 [ // first compressed format 284 [ // predicates 285 [ref to field, value] // field == value 286 .... 287 ] 288 [ // fields in compressed format 289 [ref to field, function] // compression of a field 290 [-length, function] // new field of length size 292 ] 293 ] // end of first compressed format 294 [ // second compressed format 295 .... 296 ] 297 .... 298 ] // end of the compression/decompression context 300 Figure 7: CBOR framework 302 The IPv6/UDP stack can be represented like this: 304 [ // begin of the compress context 305 [ // original packet description 306 [4, [0, 4, 6]], //version 0 307 [8, [0, 8, 0]], //tos_tc 1 308 [20,[0, 20, 0]], // flow_label 2 309 [16,15] // length 3 310 [8, [0, 8, 17]], // NH 4 311 [8, [0, 8, 64]], // HL 5 312 [64, [0, 64, FE80]], // SRC pref 6 313 [64, 16], // SRC IID 7 314 [64, [0, 64, FE80]], // DST pref 9 315 [64, 17] // DST IID 10 317 [16] // src port 11 318 [16] // dst port 12 319 [16, 18] // length 13 320 [16, 19] // chk 14 321 ] 323 Figure 8: CBOR framework 325 It is about 100 bytes long, note that the function 0 takes two 326 arguments as in RoHC-FN. The first one corresponding to the size can 327 be removed. We also suppose arbitrarily that value 15 correspond to 328 IPv6 length computation, 16 and 17 to IID computation. The 329 compressed format can be described with way. 331 [ // first compressed format 332 [ // predicates 333 [4, 17], // NH == 17 334 [11, 123] // src port == 123 335 [12, 124] // dst port == 124 336 ] 337 [ 338 [-8, [0, 8, 0]] // SHIM 0 339 ] 340 ] 341 ] 343 Figure 9: CBOR framework 345 -8 state for the creation of a new field of 8 bits in the compress 346 format. Function 0 set the value to 0. 348 5. CoAP compression 350 Work to be done to define a header with coap we need TLV. We can use 351 negative CBOR value: -1 is a CoAP TLV, -2 a token (refers to token 352 size in the header). 354 6. References 356 6.1. Normative References 358 [I-D.minaburo-lp-wan-gap-analysis] 359 Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP 360 Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in 361 progress), February 2016. 363 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 364 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 365 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 366 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 367 Compression (ROHC): Framework and four profiles: RTP, UDP, 368 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 369 July 2001, . 371 [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust 372 Header Compression (ROHC-FN)", RFC 4997, 373 DOI 10.17487/RFC4997, July 2007, 374 . 376 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 377 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 378 UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, 379 . 381 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 382 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 383 DOI 10.17487/RFC6282, September 2011, 384 . 386 6.2. URIs 388 [1] http://dl.acm.org/citation.cfm?id=2728090 390 Authors' Addresses 391 Ana Minaburo 392 Acklio 393 2bis rue de la Chataigneraie 394 35510 Cesson-Sevigne Cedex 395 France 397 Email: ana@ackl.io 399 Laurent Toutain 400 Institut MINES TELECOM ; TELECOM Bretagne 401 2 rue de la Chataigneraie 402 CS 17607 403 35576 Cesson-Sevigne Cedex 404 France 406 Email: Laurent.Toutain@telecom-bretagne.eu