Network Working Group YC. Ma Internet-Draft X. He Intended status: Informational Hitachi (China) Research and Expires: April 20, 2011 Development Corporation Z. Cao H. Deng China Mobile October 17, 2010 Stack Analysis for Lightweight IP Implementation draft-ma-lwip-stack-analysis-00 Abstract This document analyzes the main implementation of lightweight IP stack over constrained platform, including Contiki, TinyOS, and Atmel RUM approach. The consideration for lightweight IP stack implementation is summarized. The target of this document is to facilitate the ongoing/future developers on lightweight IP stack and provide guideline for lightweight IP stack implementation by documenting the related techniques. 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 April 20, 2011. Copyright Notice Copyright (c) 2010 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Ma, et al. Expires April 20, 2011 [Page 1] Internet-Draft LwIP Stack Analysis October 2010 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 1.1. Conventions used in this document . . . . . . . . . . . . 3 2. Analysis of existing implementations . . . . . . . . . . . . . 4 2.1. Contiki . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Atmel RUM . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Implementation consideration . . . . . . . . . . . . . . . . . 6 3.1. protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Metwork layer . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Transport layer . . . . . . . . . . . . . . . . . . . 6 3.1.3. Application layer . . . . . . . . . . . . . . . . . . 6 3.2. Task Scheduler and Platform Consideration . . . . . . . . 7 3.2.1. Task Scheduler . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Platform consideration . . . . . . . . . . . . . . . . 7 3.3. Implementation example . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Ma, et al. Expires April 20, 2011 [Page 2] Internet-Draft LwIP Stack Analysis October 2010 1. Introduction Internet of Things is becoming the focus of both industry and academia. For most devices that are commonly used in the Internet of Things applications, they are resource constrained. First, they are built on top of the constrained computing platform. e.g. with 8-bit microcontrollers and limited RAM and ROM. Second, the connectivity between the nodes and the outside network is constrained e.g, some networks go down to 20kbps and with limited delivery probability. IP stack is essential for networking the devices. To meet the requirement of resource constrained devices, the stack needs to be clipped while keeping the interoperability feature. There are already existing implementations of lightweight IP stack over resource constrained devices. But these techniques are not well documented formally. In order to facilitate the ongoing/future developers on these constrained platforms, there is a need to document these activities and common technologies. In this document the main implementations of lightweight IP stack over constrained platform, including Contiki, TinyOS, and Atmel RUM are analyzed. Then the protocol stack for lightweight IP implementation is analyzed. The related implementation issues including scheduler and hardware platform are summarized. It is expected to be the guidelines on lightweight IP stack/product implementaion based on existing techniques. 1.1. Conventions used in this document 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 [RFC2119]. Ma, et al. Expires April 20, 2011 [Page 3] Internet-Draft LwIP Stack Analysis October 2010 2. Analysis of existing implementations 2.1. Contiki Contiki is an open source, highly portable, multi-tasking operating system for memory-efficient networked embedded systems and WSN. The core of Contiki contains several components including uIP and Sicslopan communication stacks. uIP is a small RFC-compliant TCP/IP stack that makes it possible for Contiki to communicate over the Internet, while the Sicslopan stack realizes 6LoWPAN process according to [RFC4944] and ietf-draft-6lowpan-hc-01. Contiki is implemented in a layered structure. The hardware platform difference is also considered by implementing drivers for different platforms. 2.2. TinyOS The currently most extensive implementation of 6LoWPAN for TinyOS (prevalent WSN operating system) is called blip developed at the University of California, Berkeley. IPv6 neighbor discovery, default route selection and point-to-point routing are the most important features it supports. In addition to the IPv6 functionalities, it supports ICMP, UDP and includes a prototype TCP stack. Although it implements much functionality, it still contains several known issues. The fragmentation of IP packets used in blip provides several problems, in particular when using multi-hop. Buffering is a second known issue of blip. Blip is mainly based on several message buffers and windows, which consume a large amount of memory. This leads to several problems as messages are dropped if the buffer has no free space. The bilp does not include standard IEEE 802.15.4 interfaces. 2.3. Atmel RUM The Atmel Route Under Mac (RUM) is a small 802.15.4 protocol developed for supporting the 6LoWPAN component. This protocol routes packets at the MAC layer. The Atmel 6LoWPAN component can send a UDP packet to a node either on the wireless network (IP-local) or somewhere outside the wireless network (IP-global). The process of Atmel 6LoWPAN component is easy to understand, but the basic 802.15.4 protocol of Atmel is not a standard IEEE 802.15.4 protocol. Also the routing function is accomplished in a proprietary manner. 2.4. Analysis To make the stack as small as possible the stack should be clipped while keeping the interoperability feature. The application requirement should be analyzed to figure out the essential parts for a lightweight IP stack. Ma, et al. Expires April 20, 2011 [Page 4] Internet-Draft LwIP Stack Analysis October 2010 For example, according to the 3GPP discussion in TS22.368 , the traffic of Internet of Things has the following features, including small data, large number of devices, off-line transmission, on-line transmission, etc. The lightweight IP stack implementation should take the traffic features into consideration. Ma, et al. Expires April 20, 2011 [Page 5] Internet-Draft LwIP Stack Analysis October 2010 3. Implementation consideration 3.1. protocol stack 3.1.1. Metwork layer As for the network layer, 6lowpan is specified in IETF. The header compression and decompression is essential for data transmission in a low bit rate network such as 802.15.4. The ipv6 neighbour discovery is essential for address auto- configuration. This is important especially considering the large number of devices deployed in field. However due to the energy consumption requirement of the resource constrained devices, the value of ReachableTime should be carefully considerd to avoid frequent packet transmission. Also functions related to multicast management is not a must for resource constrained node. The end node of the network does not need to implement routing function. However for intermediate node the roll should be implemented for packet routing in resource constrained network. 3.1.2. Transport layer The UDP stack is essential for lightweight IP stack implementation. It is selected by core working group as the transport protocol. To guarantee the reliable transmission other approaches should be considered. For the TCP stack it is too heavy to be implemented in the resource constrained devices. It is not specified by core working group as the transport protocol. However for reliable transmission the TCP might be considered. Since the function of resource constrained devices is limited, only TCP client needs to be implemented. Also since most Internet of Things communication involves small data, the window control can be simplified. 3.1.3. Application layer Currently core working group is specifying CoAP protocol for resource constrained environment. However in CoAP each end node should be both client and server, which will increase the load of the resource constrained devices. Also the telecom operator needs the IoT service to be managable. This is hard to achieve in the end-to-end CoAP architecture. The application layer protocol with central controlled feature might be necessary to reduce the load of the resource constrained devices and enable service management for operators. Ma, et al. Expires April 20, 2011 [Page 6] Internet-Draft LwIP Stack Analysis October 2010 3.2. Task Scheduler and Platform Consideration 3.2.1. Task Scheduler Task scheduler is essential for lightweight IP stack implementation. Since data packets and ICMP packet needs parallel processing. Event driven schduler is widely used in prevalent WSN platforms such as Freescale. The scheduler can be based on existing event driven mechanism provided by the hardware. This mechanism is also used in other operation systems such as the Contiki. The scheduler can implement parallel processing via software suffer. 3.2.2. Platform consideration For most devices that are commonly used in the Internet of Things applications, they are resource constrained and usually battery powered. The typically embedded device consists of a tiny microprocessor, a RF modules, and a number of sensros. Different platform has different hardware property, interface, and needs different driver. The same platform will be customized to meet different technical requirements in different applications. Therefore the features of different platform needs to be considered for lightweight IP stack implementation. 3.3. Implementation example One example implementation is illustrated in Figure 1. Freescale BeeKit Wireless Connectivity Toolkit is chosen to be the implementation platform. The lightweight IP stack is implemented as application component defined by Freescale over the Freescale platform. The Application component includs network layer, transport layer and real application layer. Freescale provides standard IEEE802.15.4 MAC/PHY layers and interfaces with event-driven mechanism for low memory consumption. 6lowpan is implemented as the bottom layer module of Freescale Application. It communicates with MAC layer via standard IEEE 802.15.4 interfaces, including MAC Sublayer Management Entity (MLME) interface used for all 802.15.4 MAC commands, MAC Common Part Sublayer Service Access Point (MCPS-SAP) interface used for all 802.15.4 data related primitives, and Application Support Package (ASP) interface used for various application support features. Ma, et al. Expires April 20, 2011 [Page 7] Internet-Draft LwIP Stack Analysis October 2010 +------------------+ +------------------+ | Application 1 | | Application 2 | +-------/\------|\-+ +-/|--------/\-----+ +----------||-------\\------------//---------||---------+ | +-------\/---+ +\|----------|/+ +-----\/------+ | | | UDP | | ICMPv6 | | TCP | | | +------------+ +--------------+ +-------------+ | | +-------------------------------------------------+ | | | 6LoWPAN(ietf-6lowpan-draft-hc-06/FC4944) | | | +-------------------------------------------------+ | | Freescale Application Component (event-driven) | +---------/\----------------/\----------------/\--------+ +---------||----------------||----------------||--------+ | +-----\/----+ +-----\/----+ +-----\/----+ | | | MLME | | MCPS | | ASP | | | +-----------+ +-----------+ +-----------+ | | Freescale Platform (IEEE 802.15.4 MAC/PHY) | +-------------------------------------------------------+ Fig. 1 architechture of lightweight IP protocol stack The 6LoWPAN module is developed according to ietf-6lowpan-draft-hc-06 and RFC4944. The IP header compression and decompression is accomplished in this module. After header decompression, the ICMP messages are transferred into ICMPv6 module for further processing. Other data is transferred into transport layer for UDP or TCP process accordingly. The UDP and TCP modules can support different applications. In this implementation, the application is temperature sensing and data transmission. Ma, et al. Expires April 20, 2011 [Page 8] Internet-Draft LwIP Stack Analysis October 2010 4. Security Considerations TBD. Ma, et al. Expires April 20, 2011 [Page 9] Internet-Draft LwIP Stack Analysis October 2010 5. IANA Considerations This document does not require any IANA actions. Ma, et al. Expires April 20, 2011 [Page 10] Internet-Draft LwIP Stack Analysis October 2010 6. Normative References [3GPP.22.368] 3GPP, "Service requirements for Machine-Type Communications (MTC); Stage 1", 3GPP TS 22.368 10.2.0, October 2010. [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-06 (work in progress), October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. Ma, et al. Expires April 20, 2011 [Page 11] Internet-Draft LwIP Stack Analysis October 2010 Authors' Addresses Yuanchen Ma Hitachi (China) Research and Development Corporation 201, Tower C north, 2 Kexueyuan Nanlu, Haidian District Beijing 100190 China Email: ycma@hitachi.cn Xuan He Hitachi (China) Research and Development Corporation 201, Tower C north, 2 Kexueyuan Nanlu, Haidian District Beijing 100190 China Email: xhe@hitachi.cn Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: caozhen@chinamobile.com Hui Deng China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: denghui@chinamobile.com Ma, et al. Expires April 20, 2011 [Page 12]