idnits 2.17.1 draft-minaburo-lpwan-rohc-applicability-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 99 -- Looks like a reference, but probably isn't: '1' on line 120 ** Obsolete normative reference: RFC 4995 (Obsoleted by RFC 5795) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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: January 8, 2017 Institut MINES TELECOM ; TELECOM Bretagne 6 July 7, 2016 8 RoHC applicability in LPWAN 9 draft-minaburo-lpwan-rohc-applicability-00 11 Abstract 13 This document makes a survey of the way to adapt the RoHC mechanisms 14 to the LPWAN networks. It aims to show that RoHC header compression 15 is not adapted for the constrained LPWAN networks. RoHC was defined 16 to reduce the overhead over point-to-point connections for multimedia 17 flows, which does not correspond to the LPWAN traffic description. 18 RoHC is not able to reduce the use of battery and optimize the energy 19 lifetime. If RoHC is used it will need a big effort to be adapted, 20 there would be some problems to preserve a good transmission and 21 packet lost will cause a context desynchronisation which implies a 22 transmission of a complete header. LP-WAN's are different 23 technologies covering different applications based on long range, low 24 bandwidth and low power operation. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 8, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Introduction 60 LPWA (Low-Power Wide Area Network) technologies are a kind of 61 constrained and challenged networks [RFC7228] based on a star 62 topology where the device communicates directly with the gateway. 63 The use of the Internet Protocol to communicate, specially the IPv6/ 64 UDP protocol stack creates a big overhead since the packet size of 65 the LPWA technologies is no more than 200 bytes and in some 66 technologies no more than 60 bytes. So the use of a header 67 compression adapted to this very constrained networks is important. 68 But RoHC as defined in [RFC4995] and [RFC5225]are not adapted to the 69 constrained characteristics of the LPWAN networks. The adaptation 70 will modify RoHC in such manner that it will not be compatible with 71 the older versions, it will be so different that only the name will 72 be the same. This document wants to show that it is better to think 73 in a new solution than trying to adapt the older solution. 75 2. RoHC Compression 77 ROHC mechanism reduces the size of transmitted header by removing 78 redundancy. ROHC mechanisms starts by classifying header fields in 79 different classes according to their changing pattern [RFC3095]. 80 Those fields, which are classified as inferred, are not sent, those, 81 which are static, are sent initially and then they are not sent at 82 all and those, which are changing, are always sent. ROHC mechanism 83 is based on a context, which is maintained, by both ends, the 84 compressor and the decompressor. Context keeps the entire header and 85 ROHC's information. Each context has a context identifier (CID), 86 which identifies the flows. ROHC defines some profiles, which define 87 the protocol encapsulation that will be compressed. ROHC has three 88 operation modes: Unidirectional mode (U), Optimistic mode (O) and 89 Reliable mode (R). The U-mode is used when the link is 90 unidirectional or when feedback is not possible. For bi-directional 91 links, O-mode uses positive feedback packets (ACK) and R-mode use 92 positive and negative feedback packets (ACK and NACK). ROHC always 93 starts header compression using U-mode even if it is used in a bi- 94 directional link. ROHC does not make retransmission when an error 95 occurs the wrong packet is dropped. The ROHC feedback is used only 96 to indicate to the compressor side that there were an error and 97 probably the context is damaged. After receiving a negative feedback 98 compressor always reduces its compression level, which means increase 99 the header size. ROHC compressor has three compression levels [3]: 100 Initialization and Refresh (IR), First Order (FO) and Second Order 101 (SO). Each compression level uses different header format packets to 102 send the header information. In the IR compression level, it 103 establishes the context, which contains static and dynamic header 104 information, it is bigger than the entire header. The FO compression 105 level gives the change pattern of dynamic fields. And, in the last 106 compression level, SO, it sends encoded values of Sequence Number 107 (SN) and Timestamp (TS), forming the minimal size packets. With the 108 use of this header format packet all header fields can be generated 109 at the other end of the link using the previously established change 110 pattern. When some updates or errors are there, the compressor goes 111 back to upper compression levels. It only returns to the SO 112 compression level after retransmitting the updated information and 113 establishing again the change pattern in the decompressor. In 114 U-mode, the feedback channel is not used. To increase the 115 compression level an optimistic approach is used for compressor to be 116 sure that the context has been established at decompressor side. 117 This means that compressor uses the same header format packet for a 118 number of packets. As compressor does not know if context is lost it 119 also uses two timers, to come back to FO and IR compression levels. 120 The decompressor works at the receiving end of the link [1] and 121 decompresses the headers based on the header fields' information of 122 the context. Both the compressor and the decompressor use a context 123 to store all the information about the header fields. To ensure 124 correct decompression, the context should be always synchronized. 125 The decompressor has three states: the first, No Context (NC), is 126 used when there is no context synchronization, the second, Static 127 Context (SC), is reached if the dynamic information of the context 128 has been lost. The third, Full Context (FC), is reached when the 129 decompressor has all the information about header fields. In FC 130 state, the decompressor moves to the initial states as soon as it 131 detects context damage. Decompressor uses the 'k out of n' rule by 132 looking at the last n packets with CRC failures. If k CRC failures 133 have occurred then it assumes context damage and transits backward to 134 an initial state (SC or NC). The decompressor also sends feedback 135 according to the operation mode. 137 2.1. Unidirectional Mode 139 U-mode is not only the mode where RoHC compression is initialised, it 140 is also the only way to use RoHC in links where downlink is not 141 available. The U-mode of RoHC is not as efficiency as the others 142 mode of operation, because context synchronisation has to be done 143 frequently in order to be sure that the decompressor has all the 144 information to reestablish the header. The decompressor state 145 machine has three states No-Context, Static-Context and Full-Context. 146 In the beginning the state machine initialise in No-Context state 147 where it accepts only the IR packets, once the IR packet has arrive 148 he goes to the Full Context state where it decompresses all the 149 format packets. When there is an error or a packet lost and the 150 decompressor is not able to decompress the packet he goes back to 151 Static-context state where SO packets are dropped and only FO or IR 152 packets are decompressed. This is because when error or lost the 153 W-LSB for the Sequence number is lost and as in the SO header format 154 the W-LSB SN is the only information sent, so it is not capable to 155 find the good value. So the compressor has to refresh context as 156 soon as it believes is needed based on error rate and parameters 157 negotiated in the link before compression. 159 3. Applicability 161 3.1. Connection 163 RoHC uses a point-to-point communication with a negotiation to define 164 the characteristics of the channel (error rate,...) and some RoHC 165 parameters such as the size of the context identifiers, and the 166 profiles (the header stack) will be supported for the compression in 167 this channel. This implies to have a connection from one side to the 168 other. The LPWAN networks do not create a channel or connection, 169 there is not negotiation before sending any packet. Of course, RoHC 170 accepted to do an out-of-line negotiation but in all the cases this 171 represents a connection. 173 3.2. The IP address compression 175 In RoHC compression transmission is done in point-to-point connection 176 then the IP addresses could be elided in the header compression 177 processes and it is not sent in the different RoHC's packets, this 178 implies that the packet cannot be routed or forwarded between the 2 179 entities. 181 3.3. Framework 183 3.3.1. Contexts 185 RoHC framework uses contexts, they are synchronised by the 186 transmission information. So, sometimes the compression will send a 187 complete header packet which also contains RoHC information doing the 188 overhead larger than the one already generated by the IP stack. 190 3.3.2. Header format packets 192 The RoHC framework works with at least 15 different header formats 193 making the average header size around 2 bytes. But in reality you 194 will have larger packets. The RoHC framework add some compression 195 information needed to identify the flow is sent in the packet as 196 Padding (1 byte), Context ID (from 1 to 3 bytes), Profile (1 byte), 197 RoHC format packet type (5 bits to 1 byte), CRC (from 3 bits to 1 198 byte) Therefore, in order to get the littlest header format the 199 channel need to be stable and with a small error transmission, in 200 order to keep the compressor in the SO of compression and that 201 decompression does not send a negative acknowledgement in order to 202 detect lost packets and reduce compression. 204 3.3.3. Context Synchronisation 206 In case of error, the decompressor will send a negative acknowledge 207 when possible and he will drop packets until he receives a complete 208 header. This waste of energy and compression effort is very 209 expensive for the LPWAN node which will not be enable all the time 210 and that expects that its information arrives without confirmation. 212 3.3.4. Complexity 214 RoHC is a very complex header compression mechanism, it was defined 215 for wireless networks (2.5 and 3G) which use expensive radio spectrum 216 resource and have a long RTT. The main problem solved is the use of 217 bandwidth for multimedia applications as VoIP or VoD. in specific 218 channels (point-to-point), where a circuit is created. The RoHC 219 framework defines the possibility to reduce different protocols, but 220 to be reliable, it adds a lot of 'RoHC' signalling in order to keep 221 the context updated at both sizes (Compressor and Decompressor). To 222 be robust it refresh information of the context regularly or when 223 needed as the result of receiving a negative feedback. So the 224 problem it solves is clear different from IoT. In RoHC the power and 225 the memory are not a problem, the only important thing is to reduce 226 the use of bandwidth that is expensive even if the node needs a lot 227 of resources. 229 3.3.5. L variable or optimistic approach 231 RoHC uses in the Unidirectional and Optimistic mode of operation a 232 variable to bring robustness, this approach reuses the same packet 233 format L times in order to be sure that the Decompressor has received 234 the information. The value of this variable is not defined, it is 235 based on the RTT, and for 3G networks it is recommended to be 3, this 236 means that the compressor will use 3 times each format header of each 237 compression level before augmenting the compression rate. Then each 238 time the Decompressor lost the context or as periodically as timmers 239 are triggered the IR packets will be sent. Creating a big overhead 240 for the LPWAN networks. 242 3.3.6. Sequence Number (SN) 244 RoHC use the RTP sequence number to control the missing packets and 245 to reduce the header size. When there is no RTP header, RoHC 246 generates a 16 bit Sequence Number to guarantee robustness. The 247 sequence number is reduced by the W-LSB algorithm which manages the 248 number of packets lost before the context needs to be synchronised. 249 It also manages the number of SN bits to be sent, this corresponds to 250 the packet format so the W-LSB can reduce compression in order to 251 slight the window and continue working. 253 3.3.7. LSB Window (W-LSB) 255 It is a function of a reference value (vref) and 'k' (number of bits 256 in the format packet). The LSB interpretation interval function is 257 f(vref , k) = [vref - p, vref + (2k - 1) - p]; for any 'k', the 'k' 258 LSBs must uniquely identify a value in f(vref,k). 'p' is a shifting 259 parameters that may be tuned for efficiency. 261 3.4. Resources Usability 263 When RoHC was defined there were no requirements concerning the use 264 of battery and sporadic transmission (sleeping nodes). These two 265 LPWAN characteristics are not taking into account in the RoHC 266 solution. The concerning was to reduce the header overhead and to 267 adapt the robustness of the header information to the multimedia 268 applications where most of the time they prefer to receive erroneous 269 information than nothing at all, that's the reason why the CRC is 270 reduced and the UDP checksum eliminate. The concern was to keep the 271 context synchronised to loose as less as possible the application 272 information for reducing the use of bandwidth. RoHC is not concerned 273 for sleepy nodes or sporadic transmission, with a very little mtu's 274 and power optimimsation. 276 3.5. Flow 278 One based characteristics of the RoHC compression is the use of flow 279 (sequence of packets from a source to a destination), larger the flow 280 is, better the RoHC compression performs. The RoHC mechanisms have a 281 worse compression when there is a short flows, problems were 282 presented for the TCP profile with shortest flows were RoHC average 283 header size is larger than in a largest flow. The concept of flow is 284 very important in RoHC because it takes some flow parameters to 285 reduce the header, like the behaviour of the: sequence number and 286 timestamp. 288 3.6. Packet loss and reordering 290 RoHC does not support disordering in the compressed packets. The 291 packets need to be ordered before the compression. In reality the 292 RoHCv1 supports 'p' packets in disordered, 'p' is the parameter of 293 the W-LSB algorithm, in practice this represents 2 packets in 294 advanced before enlarging the window in SO of compression and any in 295 advance with a worst performance in the other levels of compression 296 but only 1 packet late in the SO level of compression and no 297 sequentially late packets at all in the other levels. RoHCv2 handles 298 disordering because the mechanisms have flexible format packets where 299 the needed information is sent. In the case of packet loss, RoHC 300 reacts very different depending on the Mode of Operation used. In 301 the Unidirectional mode any loss does not affect the compression but 302 the decompressor could drop all the packets until an IR packet 303 arrives when timmer is trigger. In the Optimistic and Reliable 304 Modes, the RoHC feedback is very helpful in order to keep robustness. 305 When needed the decompressor will ask through a feedback the 306 synchronisation of the context. 308 4. Acknowledgements 310 We would like also to thanks Alexander Pelov for the positive 311 discussions 313 5. Annex A -- Example 315 ToDo 317 6. Normative References 319 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 320 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 321 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 322 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 323 Compression (ROHC): Framework and four profiles: RTP, UDP, 324 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 325 July 2001, . 327 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 328 Header Compression (ROHC) Framework", RFC 4995, 329 DOI 10.17487/RFC4995, July 2007, 330 . 332 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 333 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 334 UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, 335 . 337 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 338 Constrained-Node Networks", RFC 7228, 339 DOI 10.17487/RFC7228, May 2014, 340 . 342 Authors' Addresses 344 Ana Minaburo 345 Acklio 346 2bis rue de la Chataigneraie 347 35510 Cesson-Sevigne Cedex 348 France 350 Email: ana@ackl.io 352 Laurent Toutain 353 Institut MINES TELECOM ; TELECOM Bretagne 354 2 rue de la Chataigneraie 355 CS 17607 356 35576 Cesson-Sevigne Cedex 357 France 359 Email: Laurent.Toutain@telecom-bretagne.eu