Internet DRAFT - draft-hahm-lwig-painless-constrained-programming
draft-hahm-lwig-painless-constrained-programming
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]
