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]