idnits 2.17.1 draft-hahm-lwig-painless-constrained-programming-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 : ---------------------------------------------------------------------------- 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 (March 9, 2013) is 4065 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 211, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Light-Weight Implementation Guidance O. Hahm 3 (LWIG) E. Baccelli 4 Internet-Draft INRIA 5 Intended status: Informational K. Schleiser 6 Expires: September 10, 2013 SpreeBytes 7 March 9, 2013 9 Painless Class 1 Devices Programming 10 draft-hahm-lwig-painless-constrained-programming-00 12 Abstract 14 In order to fit the constraints of Class 0 devices (offering much 15 less than 10KiB of RAM and 100KiB of ROM) there are no alternatives 16 to implementing IP protocols in special software environments, which 17 impose programming paradigms that make implementation of protocol 18 specifications significantly more complex. However, our experience 19 implementing RFC 4944 and RFC 6282, TCP and UDP on Class 1 devices 20 (offering approximately 10KiB of RAM and 100KiB of ROM) shows that 21 there are alternatives concerning software environments in which to 22 implement IP protocols, which avoid such complexity by providing a 23 more developer-friendly environment. This draft shares this 24 experience. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF 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 September 10, 2013. 43 Copyright Notice 45 Copyright (c) 2013 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 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Why implementations on Class 0 devices can be painful . . . . . 3 62 2.1. Learning curve . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Implementing from scratch . . . . . . . . . . . . . . . . . 3 64 2.3. Increased complexity . . . . . . . . . . . . . . . . . . . 4 65 3. Why implementations on Class 1 devices can be painless . . . . 4 66 3.1. Average programmer background is OK . . . . . . . . . . . . 4 67 3.2. Leveraging more well-known tools . . . . . . . . . . . . . 5 68 3.3. Safer and quicker coding . . . . . . . . . . . . . . . . . 5 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 In order to implement IP protocols with regard to the constraints of 76 Class 0 devices [draft-ietf-lwig-terminology-01], tailored software 77 environments must be used, such as [TinyOS] [Contiki-OS]. However, 78 such software environments impose programming paradigms that can 79 prove painful to use. For instance, 80 [draft-kovatsch-lwig-class1-coap-00] mentions some such issues, 81 encountered while implementing COAP [draft-ietf-core-coap-13]. 82 However, our experience with implementing RFC 4944, RFC 6282, TCP and 83 UDP shows that such issues can be avoided on Class 1 devices, 84 depending on the choice of software environment in which 85 specifications are implemented, as detailed in Section 3. 87 2. Why implementations on Class 0 devices can be painful 89 In order to deal with the very limited RAM and ROM available on Class 90 0 devices, network protocol implementers generally code on specific 91 operating systems based on an event loop with a shared stack for all 92 processes (cooperative multi-threading). The main advantage of a 93 cooperative multi-threading is that it can optimize memory usage on 94 very constrained devices. However, the use of an event loop makes 95 network protocol implementation a peculiar exercise, as it imposes an 96 unusual programming paradigm. 98 2.1. Learning curve 100 The event loop programming paradigm is not straight-forward to master 101 for programmers who are used to code on more conventional platforms, 102 such as Linux or Unix for instance. Hence, programmers do not only 103 have to deal with the constrained resources (RAM, ROM) of the 104 platform, but must also tussle with a fundamentally different way of 105 designing the implementation of a protocol specification. This means 106 extra costs for code development and maintenance. 108 2.2. Implementing from scratch 110 The distinct programming paradigm stemming from an event loop 111 typically imposes a non-standard programming language. Some event 112 loop operating systems introduce a new language (e.g. [TinyOS] 113 imposes nesC), while other operating systems "hijack" elements of a 114 standard programming language to use it in a different way (e.g. the 115 switch/case structure for Protothreads in [Contiki-OS], using a C 116 dialect). This results in: 118 - the necessity for an entirely new code base, 120 - the inability to easily port pre-existing, mature code for well- 121 known functions, routines, or protocols, 123 - the inability to use standard software engineering tools for 124 debugging and analysing code. 126 Conversely, it is not easy to port code developed for Class 0 devices 127 running on an event loop operating system, to less constrained 128 devices running conventional operating systems. 130 2.3. Increased complexity 132 A system based on an event loop in combination with a shared stack 133 for all processes makes it necessary to use somewhat tricky 134 programming techniques. For instance, in order to not fully block 135 the whole system during long-lasting processes, functions must be 136 designed with split phase execution. However, this technique breaks 137 up logical contigous code into multiple pieces and thus increases 138 code complexity. Another example concerns handling multiple stateful 139 connections at the same time: an event loop in combination with a 140 shared stack typically forces programmers to implement complex state 141 machinery to manage simultaneous connections (e.g., TCP connections). 143 3. Why implementations on Class 1 devices can be painless 145 When we were tasked with implementing RFC 4944, RFC 6282, TCP and UDP 146 on Class 1 devices, we wanted to avoid the issues described in 147 Section 2. We have thus decided to look for alternatives to using an 148 operating system based on an event loop. Our implementation of the 149 aforementioned protocol specifications was thus carried out in a 150 different operating system, [RIOT-OS], which supports multi-threading 151 similarly to operating systems running on "traditional" Internet 152 hosts and routers (e.g., Linux or Unix). Our experience with this 153 choice is that network protocol implementations for Class 1 devices 154 can be comparatively painless, as described in the following. 156 3.1. Average programmer background is OK 158 As the operating system we chose supports fully separated threads and 159 the ability to react in real-time, there was no need to fundamentally 160 change the programming paradigm, compared to programming on less 161 constrained platforms. Hence, we benefited from a drastically 162 reduced learning curve for programmers with a usual background, i.e. 163 that had never before programmed for constrained devices. Practiced 164 network programmers could simply adapt the implementation concepts 165 and techniques known to be efficient on non-embedded systems. 167 3.2. Leveraging more well-known tools 169 As the operating system we chose allows to implement in ANSI C, 170 existing code could be reused, taken from the IP protocol suite 171 currently deployed on mature operating systems such as Linux or Unix. 172 For instance, our 6LoWPAN and TCP implementations reuse constants and 173 data structures for packet headers and protocol options. The well- 174 known BSD socket API was ported without significant modifications to 175 functions like bind(), send() or recvfrom(). Useful helper modules 176 like inet_pton and inet_ntop were integrated without any changes. In 177 a nutshell: the usage of standard programming languages in 178 combination with a common programming paradigm reduces the amount of 179 code that has to be developed and maintained. 181 3.3. Safer and quicker coding 183 Coding can be significantly safer and quicker on Class 1 devices, 184 depending on the choice of operating system upon which to build. 185 Network protocols from the IP suite were designed with traditional, 186 multi-threading based operating systems in mind. Thus, where 187 possible, it makes sense to avoid unnecessary issues that stem from 188 using fundamentally different software environments. Our experience 189 shows that for implementations on Class 1 devices, it is possible to 190 benefit from a software environment that leverages substantially more 191 well-known tools than what an operating system based on an event loop 192 can achieve, thus facilitating both code development on Class 1 193 devices, and porting of code to/from less constrained hardware. 195 4. Security Considerations 197 This document does not have any security considerations. 199 5. IANA Considerations 201 This document does not have any IANA actions. 203 6. Informative References 205 [RFC4944] Montenegro, G., Kushalnagar, 206 N., Hui, J., and D. Culler, 207 "Transmission of IPv6 Packets 208 over IEEE 802.15.4 Networks", 209 RFC 4944, September 2007. 211 [RFC6282] Hui, J. and P. Thubert, 212 "Compression Format for IPv6 213 Datagrams over IEEE 802.15.4- 214 Based Networks", RFC 6282, 215 September 2011. 217 [draft-ietf-lwig-terminology-01] Bormann, C. and M. Ersue, 218 "Terminology for Constrained 219 Node Networks", 220 draft-ietf-lwig-terminology , 221 Feb 2013. 223 [draft-kovatsch-lwig-class1-coap-00] Kovatsch, M., "Implementing 224 CoAP for Class 1 devices", draf 225 t-kovatsch-lwig-class1-coap , 226 Oct 2012. 228 [draft-ietf-core-coap-13] Shelby, Z., Hartke, K., 229 Bormann, C., and B. Frank, 230 "Constrained Application 231 Protocol (CoAP)", 232 draft-ietf-core-coap , 233 Dec 2012. 235 [TinyOS] "TinyOS 236 http://www.tinyos.net", 2012. 238 [Contiki-OS] "Contiki Operating System 239 http://www.contiki-os.org", 240 2012. 242 [RIOT-OS] "RIOT Operating System 243 http://www.riot-os.org", 2012. 245 Authors' Addresses 247 Oliver Hahm 248 INRIA 250 EMail: Oliver.Hahm@inria.fr 252 Emmanuel Baccelli 253 INRIA 255 EMail: Emmanuel.Baccelli@inria.fr 256 URI: http://www.emmanuelbaccelli.org/ 257 Kaspar Schleiser 258 SpreeBytes 260 EMail: kaspar@schleiser.de