Internet DRAFT - draft-williams-lwig-api

draft-williams-lwig-api





LWIG WG                                                      C. Williams
Internet-Draft                                                 MCSR Labs
Expires: September 7, 2012                                   G. Mulligan
                                                                  Proto6
                                                           March 6, 2012


         On Lightweight and Embedded IP Programming Interfaces
                     draft-williams-lwig-api-00.txt

Abstract

   This document takes a look at various aspects of Application
   Programming Interfaces (APIs) used in embedded sensors and controller
   applications such as IP Smart Objects and IP based Wireless Sensor
   Networks.  These devices may be interconnected via many different
   types of media, including 802.15.4 (lowpans), power line control
   (PLC), RS485, but the common characteristic is that the devices have
   extremely limited code space and memory space for both the stack and
   application.  Just as there is no one single API for IP networking
   stacks today (though the "Berkeley sockets" might be considered de-
   facto standard) there is not likely to be a single standard in the
   embedded space, but there can be some common understanding about
   facilities that can and should be provided to the application
   developer.

Status of this Memo

   This Internet-Draft is submitted 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 7, 2012.

Copyright Notice

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




Williams & Mulligan     Expires September 7, 2012               [Page 1]

Internet-Draft                  LWIG APIs                     March 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   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.  Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Applicability Statement . . . . . . . . . . . . . . . . . . . . 4
   5.  API requirements  . . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  Network Parameters  . . . . . . . . . . . . . . . . . . . . 4
     5.2.  Sending and Receiving packets . . . . . . . . . . . . . . . 4
     5.3.  Managing network errors . . . . . . . . . . . . . . . . . . 4
   6.  To RTOS or not  . . . . . . . . . . . . . . . . . . . . . . . . 4
     6.1.  Using an RTOS . . . . . . . . . . . . . . . . . . . . . . . 4
     6.2.  Providing libraries . . . . . . . . . . . . . . . . . . . . 5
   7.  Low level programming interfaces  . . . . . . . . . . . . . . . 5
     7.1.  Berkeley Sockets  . . . . . . . . . . . . . . . . . . . . . 5
       7.1.1.  Network management  . . . . . . . . . . . . . . . . . . 6
       7.1.2.  UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       7.1.3.  TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  High level programming interfaces . . . . . . . . . . . . . . . 6
     8.1.  Java  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.2.  Python  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.3.  Proprietary . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Modem type device interface . . . . . . . . . . . . . . . . . . 6
   10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     13.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     13.2. Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8










Williams & Mulligan     Expires September 7, 2012               [Page 2]

Internet-Draft                  LWIG APIs                     March 2012


1.  Introduction

   Just as there is no one single Application Programming Interface
   (API) for IP networking stacks today (though the "Berkeley sockets"
   might be considered a de-facto standard) there is not likely to be a
   single standard in the embedded space, but there can be some common
   understanding about facilities that can and should be provided to the
   application developer.  This document takes a look at various aspects
   of APIs used in embedded sensor and controller applications and
   Wireless Sensor Networks, such as IP Smart Objects and Machine to
   Machine (M2M) applications.

   Today in some embedded IP applications the IP stack is implemented in
   a separate external processor that provides a service like a Modem,
   while the application is run in its own processor.  This has provided
   workable but more costly solutions by requiring two processors.  This
   has the advantage that is separates the application from the network
   stack and offloads the network processing, but for small low-cost
   embedded systems the cost of the second processor can be prohibitive.
   In these cases combining the application and communications
   processors and providing an application environment in the single
   processor will provide a lower cost solution.


2.  Definition Of Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

   LowPan Network:
      It is a wireless (usually) or wired network generally
      characterized by having constrained nodes.  These constraints may
      be processing, memory or power or any combination


3.  Assumptions

   o  The 6LowPan host nodes either autoconfigure IPv6 address based on
      the prefix received in the Router Advertisement, or it uses DHCP
      for short address assignment.  It can receive multiple Router
      Advertisements and should configure at least one default router as
      its immediate nexthop.  It may configure multiple default routers,
      but this is implementation specific.  The 6LowPan host nodes
      always send their packets to the default router.  If one default
      router becomes unavailable, it chooses the next available default
      router or it may restart the ND process.




Williams & Mulligan     Expires September 7, 2012               [Page 3]

Internet-Draft                  LWIG APIs                     March 2012


4.  Applicability Statement

   This document aims to guide implementers in choosing appropriate
   programming interfaces for use in embedded IP devices, such as IP
   Smart Objects and other highly constrained devices with limited RAM
   or processing power


5.  API requirements

5.1.  Network Parameters

   Different types of networks will require different types of functions
   to set-up and manage the network interface.  In the case of wireless
   networks such a IEEE 802.15.4 it is necessary that functions be
   provided to select the channel and the PANID and possible set or read
   other IEEE 802.15.4 MAC parameters.

5.2.  Sending and Receiving packets

   All APIs must provide some mechanism to send and receive IP packets,
   otherwise what is the point of a networking stack.  Additionaly they
   may provide higher functions that will compose TCP streams and UDP
   packets.

5.3.  Managing network errors

   All stacks must provide some set of functions to pass network erros
   to the application.  These errors might include local networking
   errors, such as no IP address set for the interface, no next hop, no
   route to the destination.  These errors might also include remote
   network errors such as those received via ICMP.


6.  To RTOS or not

   One fundamental question for all embedded stack developers is whether
   they should provide their stack with an RTOS or just a set of library
   functions.  There are pros and cons to each.

6.1.  Using an RTOS

   Certainly providing and RTOS does offer a more complete solution, but
   it tends to contrain the application developer and may add
   unnecessary overhead (processing, code, memory and power).

   TinyOS and Contiki are two open source RTOS.  Each provides
   networking functionality and both now offer support for 6lowpan and



Williams & Mulligan     Expires September 7, 2012               [Page 4]

Internet-Draft                  LWIG APIs                     March 2012


   IPv6.  They both have the supporters and detractors.  Some developers
   shy away from TinyOS because they don't want to delve into the world
   of nesC.  Some developers have chosen to not use Contiki because of
   the design using "protothreads".

   The advantage that any RTOS provides is that the developer usually
   does not need to deal with many of the basic timings and can
   ostensibly write their application as just that, an application, and
   leave the details to the OS.  The disadvantage is that if the
   application requires either some very specifc timing or possibly some
   detailed device or network control (sleeping, interrupts, ...) if
   these are not provided by the RTOS then the application may become
   more complex than otherwise required.

   Additionally, as already mentioned, the RTOS may provide unnecessary
   functionality which could impact code size or memory requirements.
   The RTOS might also require a change in the design of existing
   embedded applications in order to be integrated into this
   environment.

6.2.  Providing libraries

   Providing libraries is not a panacea either.  While a set of
   libraries offers the most flexibility (other than writing the
   complete stack and application), it does put the burden on the
   programmer to deal with all of the nuances normally taken care of by
   the OS.  As such the programmer must have a better understanding of
   the specific of the particular microprocessor.


7.  Low level programming interfaces

7.1.  Berkeley Sockets

   A number of companies have implemented embedded networking stacks and
   provide an interface to the stack (either an RTOS or set of
   libraries) via a Berkely Socket like set of functions.  The major
   advantage is that Berkely Sockets is widely known, understood and
   taught.  This can greatly speed up the development of networked
   embedded systems.  If the set of library functions it properly
   written the basic network calls should be able to be used just as if
   they were a being written on a Unix or Linux system.  In the embedded
   environment it is probably not possible to provide a complete POSIX
   compliant network interface, but a sufficient subset of functions can
   be implemented.






Williams & Mulligan     Expires September 7, 2012               [Page 5]

Internet-Draft                  LWIG APIs                     March 2012


7.1.1.  Network management

   TBD

7.1.2.  UDP

   Sending and receiving UDP packets

7.1.3.  TCP

   TBD


8.  High level programming interfaces

8.1.  Java

   The Sun SPOT team built an embedded stack based on the JAVA VM.  The
   stack provided a mechanism to write embedded networking code,
   including "mobile code", in Java.  All of the implementation of the
   protocols was provided as part of the JVM.  The implementation of the
   JVM required a processor with 8MB of flash and 1MB of RAM.  This is
   larger than would typically be considered an embedded system.

8.2.  Python

   At least one company has developed a python engine for small embedded
   devices.  They provide a reduced set of phyton library functions, but
   they do include the ability to send a receive IP packets.

   More information TBC (to be completed)

8.3.  Proprietary

   TBC


9.  Modem type device interface

   Some providers of embedded communications devices have chosen to
   provide a "closed" external processor that is used to send a receive
   packets, much like a modem of yesteryears.  Some companies have gone
   as far as to overload the old AT command set to manage the network
   interface.  For example to set the destination address the
   application processor send the string "ATDT ipaddress/port" as though
   it was asking the communications process to dial a phone number.
   Prior to that the application would send other AT commands to define
   various other parameters such as whether to treat the data as



Williams & Mulligan     Expires September 7, 2012               [Page 6]

Internet-Draft                  LWIG APIs                     March 2012


   datagrams (UDP) or a stream (TCP).  In one case this was overloaded
   using ATDT (Dial Tone) for TCP and ATDP (Dial Pulse) for UDP and then
   the application just sends bytes and the outboard processor deals
   with all the details of managing the connection and sending and
   receiving data.

   As already mentioned, while this provides an extremely simple
   interface and insulates the application developer from any details of
   the network, it adds cost to the overall system and may not provide
   an abstraction that allows the system to meet power or timing
   constraints.


10.  Security Considerations

   No known security considerations.


11.  IANA Considerations

   There are no IANA considerations for this document.


12.  Acknowledgements

   The ideas behind this came from discussion with a number of people
   including Eric Gnoske, Colin O'Flynn, Kris Pister, David Ewing and
   folks working in the 6LowPAN WG.


13.  References

13.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

13.2.  Informative References

   [2]  Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets
        over IEEE 802.15.4 networks", RFC 4944, September 2007.

   [3]  Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
        Assumptions, Problem Statement and Goals", RFC 4919,
        August 2007.

   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6),
        Specification", RFC 2460, December 1998.



Williams & Mulligan     Expires September 7, 2012               [Page 7]

Internet-Draft                  LWIG APIs                     March 2012


   [5]  IEEE Computer Society, "IEEE Std. 802.15.4-2003",  ,
        October 2003.


Authors' Addresses

   Carl Williams
   MCSR Labs
   USA

   Email: carlw@mcsr-labs.org


   Geoff Mulligan
   Proto6
   USA

   Email: geoff@proto6.com

































Williams & Mulligan     Expires September 7, 2012               [Page 8]