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]