[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Light-Weight Implementation Guidance                             O. Hahm
(LWIG)                                                       E. Baccelli
Internet-Draft                                                     INRIA
Intended status: Informational                              K. Schleiser
Expires: September 10, 2013                                   SpreeBytes
                                                           March 9, 2013


                  Painless Class 1 Devices Programming
          draft-hahm-lwig-painless-constrained-programming-00

Abstract

   In order to fit the constraints of Class 0 devices (offering much
   less than 10KiB of RAM and 100KiB of ROM) there are no alternatives
   to implementing IP protocols in special software environments, which
   impose programming paradigms that make implementation of protocol
   specifications significantly more complex.  However, our experience
   implementing RFC 4944 and RFC 6282, TCP and UDP on Class 1 devices
   (offering approximately 10KiB of RAM and 100KiB of ROM) shows that
   there are alternatives concerning software environments in which to
   implement IP protocols, which avoid such complexity by providing a
   more developer-friendly environment.  This draft shares this
   experience.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Hahm, et al.           Expires September 10, 2013               [Page 1]


Internet-Draft    Painless Class 1 devices Programming        March 2013


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Why implementations on Class 0 devices can be painful . . . . . 3
     2.1.  Learning curve  . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Implementing from scratch . . . . . . . . . . . . . . . . . 3
     2.3.  Increased complexity  . . . . . . . . . . . . . . . . . . . 4
   3.  Why implementations on Class 1 devices can be painless  . . . . 4
     3.1.  Average programmer background is OK . . . . . . . . . . . . 4
     3.2.  Leveraging more well-known tools  . . . . . . . . . . . . . 5
     3.3.  Safer and quicker coding  . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 5




























Hahm, et al.           Expires September 10, 2013               [Page 2]


Internet-Draft    Painless Class 1 devices Programming        March 2013


1.  Introduction

   In order to implement IP protocols with regard to the constraints of
   Class 0 devices [draft-ietf-lwig-terminology-01], tailored software
   environments must be used, such as [TinyOS] [Contiki-OS].  However,
   such software environments impose programming paradigms that can
   prove painful to use.  For instance,
   [draft-kovatsch-lwig-class1-coap-00] mentions some such issues,
   encountered while implementing COAP [draft-ietf-core-coap-13].
   However, our experience with implementing RFC 4944, RFC 6282, TCP and
   UDP shows that such issues can be avoided on Class 1 devices,
   depending on the choice of software environment in which
   specifications are implemented, as detailed in Section 3.

2.  Why implementations on Class 0 devices can be painful

   In order to deal with the very limited RAM and ROM available on Class
   0 devices, network protocol implementers generally code on specific
   operating systems based on an event loop with a shared stack for all
   processes (cooperative multi-threading).  The main advantage of a
   cooperative multi-threading is that it can optimize memory usage on
   very constrained devices.  However, the use of an event loop makes
   network protocol implementation a peculiar exercise, as it imposes an
   unusual programming paradigm.

2.1.  Learning curve

   The event loop programming paradigm is not straight-forward to master
   for programmers who are used to code on more conventional platforms,
   such as Linux or Unix for instance.  Hence, programmers do not only
   have to deal with the constrained resources (RAM, ROM) of the
   platform, but must also tussle with a fundamentally different way of
   designing the implementation of a protocol specification.  This means
   extra costs for code development and maintenance.

2.2.  Implementing from scratch

   The distinct programming paradigm stemming from an event loop
   typically imposes a non-standard programming language.  Some event
   loop operating systems introduce a new language (e.g.  [TinyOS]
   imposes nesC), while other operating systems "hijack" elements of a
   standard programming language to use it in a different way (e.g. the
   switch/case structure for Protothreads in [Contiki-OS], using a C
   dialect).  This results in:







Hahm, et al.           Expires September 10, 2013               [Page 3]


Internet-Draft    Painless Class 1 devices Programming        March 2013


      - the necessity for an entirely new code base,

      - the inability to easily port pre-existing, mature code for well-
      known functions, routines, or protocols,

      - the inability to use standard software engineering tools for
      debugging and analysing code.

   Conversely, it is not easy to port code developed for Class 0 devices
   running on an event loop operating system, to less constrained
   devices running conventional operating systems.

2.3.  Increased complexity

   A system based on an event loop in combination with a shared stack
   for all processes makes it necessary to use somewhat tricky
   programming techniques.  For instance, in order to not fully block
   the whole system during long-lasting processes, functions must be
   designed with split phase execution.  However, this technique breaks
   up logical contigous code into multiple pieces and thus increases
   code complexity.  Another example concerns handling multiple stateful
   connections at the same time: an event loop in combination with a
   shared stack typically forces programmers to implement complex state
   machinery to manage simultaneous connections (e.g., TCP connections).

3.  Why implementations on Class 1 devices can be painless

   When we were tasked with implementing RFC 4944, RFC 6282, TCP and UDP
   on Class 1 devices, we wanted to avoid the issues described in
   Section 2.  We have thus decided to look for alternatives to using an
   operating system based on an event loop.  Our implementation of the
   aforementioned protocol specifications was thus carried out in a
   different operating system, [RIOT-OS], which supports multi-threading
   similarly to operating systems running on "traditional" Internet
   hosts and routers (e.g., Linux or Unix).  Our experience with this
   choice is that network protocol implementations for Class 1 devices
   can be comparatively painless, as described in the following.

3.1.  Average programmer background is OK

   As the operating system we chose supports fully separated threads and
   the ability to react in real-time, there was no need to fundamentally
   change the programming paradigm, compared to programming on less
   constrained platforms.  Hence, we benefited from a drastically
   reduced learning curve for programmers with a usual background, i.e.
   that had never before programmed for constrained devices.  Practiced
   network programmers could simply adapt the implementation concepts
   and techniques known to be efficient on non-embedded systems.



Hahm, et al.           Expires September 10, 2013               [Page 4]


Internet-Draft    Painless Class 1 devices Programming        March 2013


3.2.  Leveraging more well-known tools

   As the operating system we chose allows to implement in ANSI C,
   existing code could be reused, taken from the IP protocol suite
   currently deployed on mature operating systems such as Linux or Unix.
   For instance, our 6LoWPAN and TCP implementations reuse constants and
   data structures for packet headers and protocol options.  The well-
   known BSD socket API was ported without significant modifications to
   functions like bind(), send() or recvfrom().  Useful helper modules
   like inet_pton and inet_ntop were integrated without any changes.  In
   a nutshell: the usage of standard programming languages in
   combination with a common programming paradigm reduces the amount of
   code that has to be developed and maintained.

3.3.  Safer and quicker coding

   Coding can be significantly safer and quicker on Class 1 devices,
   depending on the choice of operating system upon which to build.
   Network protocols from the IP suite were designed with traditional,
   multi-threading based operating systems in mind.  Thus, where
   possible, it makes sense to avoid unnecessary issues that stem from
   using fundamentally different software environments.  Our experience
   shows that for implementations on Class 1 devices, it is possible to
   benefit from a software environment that leverages substantially more
   well-known tools than what an operating system based on an event loop
   can achieve, thus facilitating both code development on Class 1
   devices, and porting of code to/from less constrained hardware.

4.  Security Considerations

   This document does not have any security considerations.

5.  IANA Considerations

   This document does not have any IANA actions.

6.  Informative References

   [RFC4944]                             Montenegro, G., Kushalnagar,
                                         N., Hui, J., and D. Culler,
                                         "Transmission of IPv6 Packets
                                         over IEEE 802.15.4 Networks",
                                         RFC 4944, September 2007.

   [RFC6282]                             Hui, J. and P. Thubert,
                                         "Compression Format for IPv6
                                         Datagrams over IEEE 802.15.4-
                                         Based Networks", RFC 6282,



Hahm, et al.           Expires September 10, 2013               [Page 5]


Internet-Draft    Painless Class 1 devices Programming        March 2013


                                         September 2011.

   [draft-ietf-lwig-terminology-01]      Bormann, C. and M. Ersue,
                                         "Terminology for Constrained
                                         Node Networks",
                                         draft-ietf-lwig-terminology ,
                                         Feb 2013.

   [draft-kovatsch-lwig-class1-coap-00]  Kovatsch, M., "Implementing
                                         CoAP for Class 1 devices", draf
                                         t-kovatsch-lwig-class1-coap ,
                                         Oct 2012.

   [draft-ietf-core-coap-13]             Shelby, Z., Hartke, K.,
                                         Bormann, C., and B. Frank,
                                         "Constrained Application
                                         Protocol (CoAP)",
                                         draft-ietf-core-coap ,
                                         Dec 2012.

   [TinyOS]                              "TinyOS
                                         http://www.tinyos.net", 2012.

   [Contiki-OS]                          "Contiki Operating System
                                         http://www.contiki-os.org",
                                         2012.

   [RIOT-OS]                             "RIOT Operating System
                                         http://www.riot-os.org", 2012.

Authors' Addresses

   Oliver Hahm
   INRIA

   EMail: Oliver.Hahm@inria.fr


   Emmanuel Baccelli
   INRIA

   EMail: Emmanuel.Baccelli@inria.fr
   URI:   http://www.emmanuelbaccelli.org/








Hahm, et al.           Expires September 10, 2013               [Page 6]


Internet-Draft    Painless Class 1 devices Programming        March 2013


   Kaspar Schleiser
   SpreeBytes

   EMail: kaspar@schleiser.de















































Hahm, et al.           Expires September 10, 2013               [Page 7]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/