LwIP Working Group H. Deng Internet-Draft China Mobile Intended status: Informational S. Sakane Expires: April 27, 2011 Cisco W. Haddad Ericsson N. Kong CNNIC October 24, 2010 Problem Statement of Lightweight IP Protocols Design draft-deng-lwip-ps-01 Abstract Since small devices such as sensors are often required to be physically small and inexpensive, an implementation of the Internet protocols will have to deal with having limited computing resources and memory. This report describes the design and implementation of a small TCP/IP stack called lwIP that is small enough to be used in minimal systems. 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 27, 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 Deng, et al. Expires April 27, 2011 [Page 1] Internet-Draft LwIP PS 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. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Constraint and Requirements . . . . . . . . . . . . . . . . . 6 3.1. Low Energy Consumption . . . . . . . . . . . . . . . . . . 6 3.2. Limited Memory Size . . . . . . . . . . . . . . . . . . . 6 3.3. Various Data Rates . . . . . . . . . . . . . . . . . . . . 6 3.4. Rapid Deployment . . . . . . . . . . . . . . . . . . . . . 6 4. Current Implementations . . . . . . . . . . . . . . . . . . . 7 4.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. LwIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. uC/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Blip on TinyOS . . . . . . . . . . . . . . . . . . . . . . 7 4.5. TinyTCP . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Lightweight IP Protocols Implementation Issues . . . . . . . . 9 5.1. P1: Modularity and Layering . . . . . . . . . . . . . . . 9 5.2. P2: Memory Usage Constraints . . . . . . . . . . . . . . . 9 5.3. P3: Inefficient Socket APIs . . . . . . . . . . . . . . . 10 5.4. P4: Protocol Interoperability . . . . . . . . . . . . . . 10 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Lightweight IP Mobility Protocol . . . . . . . . . . . . . 11 6.2. Lightweight Service Discovery . . . . . . . . . . . . . . 11 6.3. Lightweight Global Name Services . . . . . . . . . . . . . 11 6.4. Device configuration . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Deng, et al. Expires April 27, 2011 [Page 2] Internet-Draft LwIP PS October 2010 1. Introduction Technologies are evolving, but we keep inventing smaller things. 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. Secondly, the connectivity between the nodes and the outside network is constrained e.g, some networks go down to 20kbps and with limited delivery probability. Thirdly, these devices are energy constrained. They only have battery supply and the application users normally do not change their battery for long periods of time. On the other hand, the applications require more and more resources on the the devices. In home network applications, the small monitoring devices are required to send vedio streamings to the host's mobile phones, and also in factory monitoring scenarios, the requirments for high data rate transmission is emphasized. Given the above facts, IP protocols should be designed in as lightweight way as possible. This document summarizes those issues met by current practices. The document also introduces the current practices on implementing TCP/IP protocols in a lightweight way, and the problems met by implementers. 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]. Deng, et al. Expires April 27, 2011 [Page 3] Internet-Draft LwIP PS October 2010 2. Usage Scenario ,-''''--''''+ __...._ ,' \ ,' `-. / \ / Internet \ v | Wireless |----------| Access | | \ Network ,' \ ,' +---+ `. _, `-._ _,' |MN3| `-..____,,' `''' +---+ | | ******************** ******************** * * * * * In/out-door Net * * In/out-door Net * * +-------+ * * +--------+ * * |Fix-Mob| * * |Fix-Mob | * * | GW | * * | GW | * * +-------+ * * +--------+ * * | * * | * * /|\ * * /|\ * *zigbee__/ | \_z-wave* *zigbee_/ | \__z-wave* * +--+ | +--+ * * +--+ | +--+ * * |a1| | |b1| * * |a2| | |b2| * * +--+ | +--+ * * +--+ | +--+ * * | * * | * * +--+ * * +--+ * * |c1|Bluetooth* * |c2|Bluetooth* * +--+ * * +--+ * ****************** ****************** v v | | +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 1: The Scenario Currently many applications are built on this scenario. For example, a sensor for the intrusion detection sends messages to the host's mobile terminal (MN3) while they away from the house. The host can also send messages via the home gateway to home sensors in order to execute some commands, for instance, open the air conditioner before going home. For service discovery, the mobile node should be able to discover the service available nearby. For example, when a MN moves to a new environment (moving from its household to its work place), it should be able to discover the temperature and humidity information service nearby. Deng, et al. Expires April 27, 2011 [Page 4] Internet-Draft LwIP PS October 2010 The connection between the fix-mobile gateway and different types of sensors is based on various wireless technologies, for example, IEEE 802.15.4, Bluetooth, Z-Wave and RFID. IP protocol, as an adapting layer, should run over all these technologies without loosing features of communicating, qos, security and etc. So in order to accommodate those different sensing devices, it is highly desirable for all the components to talk with IP. However, both the sensing devices and the mobile gateway are built on top of the constrained platform. They are basically constrained in three aspects: o Energy Constrained. Most of the sensors do not have sustained power supply. Some of the gateway nodes also do not have power supply. Among the operations done by these nodes, communication is the most energy consuming. For scenarios like agriculture where the GW is most likely sitting somewhere outside in the field or floating on water without permanent power connectivity, the gateway are mostly out of sustained power supply. As a consequence, network stack implementations should be highly aware of these features. o Computation Constrained. The sensor nodes are built upon 8-bit MCUs with server kilos of RAM. The gateway nodes, even if they are more powerful than sensors, are not fully capable due to economic reasons. They should maintain the upward connection with the global internal as well as the downward connection between the sensor nodes. In many deploy scenarios, those gateway nodes are built upon the cellular phone platform (ARM7 or ARM9 with reduced computation functionality). In these scenarios, implementations should be aware of the computational capability on the nodes. And if secure computations are involved, implementations will met more challenges. o Network Constrained. The lower layer connection between the mobile gateway and the sensors is running at low data rate. For example, IEEE 802.15.4 provides over-the-air rates from 20kbps to 100kbps at 868/915 MHz. Implementations should be aware of the lower layer capability in order to be compliant. Deng, et al. Expires April 27, 2011 [Page 5] Internet-Draft LwIP PS October 2010 3. Constraint and Requirements 3.1. Low Energy Consumption This requirement is derived from several reasons. o it is necessary to use the devices at long time. the device is sometimes driven with a non-rechargeable and non-replaceable battery. o it is necessary to use the devices in the explosion atomosphere of the process automation. o in the human sensing, in particular, the inside of the human body sensing, the battery is very low power. o essentially, in the world wide movement, minimizing energy consumption must be considered. 3.2. Limited Memory Size The sensors are running at very constrained platforms with 8-bit micro-controllers and several kilos RAM. Even the fixed/mobile gateways are not fully capable devices; they are built on cheap chipsets for economic reasons. It is required for applications to be deployed and developed above these constrained platforms. 3.3. Various Data Rates It depends on the application requirement, video, audio streaming, or periodical sensing. The media type restricts the data rate. Actually, the technology develops the rate of the media. However, we have to consider about it for practical. 3.4. Rapid Deployment Meanwhile, there are numerous kinds of mobile terminals with heterogeneous platforms. It is difficult for developers to design universal expansion hardware to help mobile terminals access the sensor networks. Consequently, it is desirable to see some rapid deployment techniques to faciliate the fix-mobile gateway accessing the sensor network without affecting the mobile terminal platforms too much. uSD [usd] is such a practice. Deng, et al. Expires April 27, 2011 [Page 6] Internet-Draft LwIP PS October 2010 4. Current Implementations 4.1. uIP uIP is an implementation of the TCP/IP protocol stack intended for small 8-bit and 16-bit microcontrollers. It is completely RFC1122 compliant but has some limitations. For instance, a retransmit is managed by the stack, but the data that needs to be retransmitted is requested from the user application. uIP can be used together with Contiki, a very small OS which supports dynamic application download and a gui using VNC. The uIP stack uses less then 10kB ROM and 2kB RAM and Contiki can easily fit in 100kB ROM and 10kB RAM. You can use it any way you want as long as you leave a copy of the copyright notice in the source and/or documentation. uIP can be accessed via http://www.sics.se/~adam/uip/ 4.2. LwIP LwIP is a TCP/IP implementation designed for small code size and efficient memory usage. It is still widely used, and implemented. And is designed to use with or without an operating system. lwIP uses around 40kB of RAM and 30kB ROM and you can use it any way you want as long as you leave a copy of the copyright notice in the source and/or documentation. LwIP can be found via http://www.sics.se/~adam/lwip/ 4.3. uC/IP uC/IP is a TCP/IP stack developed for microcontrollers and embedded systems but is not often used. It based on the BSD TCP/IP implementations and is still a bit large compared to other implementations. uC/IP carries the BSD license so you can freely use it as long as you leave a copy of the copyright notice in the source and/or documentation. uC/IP can be found via http://ucip.sourceforge.net/ 4.4. Blip on TinyOS BLIP, the Berkeley Low-power IP stack, is an implementation in tinyos [tinyos] of a number of IP-based protocols. Using blip/tinyos, you will be able to form multi-hop IP networks consisting of different motes communicating over shared protocols. It has been tested on micaz, telosb, and epic platforms. It is not based on tinyos' active message layer, and the blip router is only supported on Linux, as of 2.1.1. BLIP can be found via Deng, et al. Expires April 27, 2011 [Page 7] Internet-Draft LwIP PS October 2010 http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip. 4.5. TinyTCP TinyTCP is a small implementation of the TCP and IP protocols, suitable for burning into ROM. A timer and an ethernet board are assumed. The implementation is based on busy-waiting, but the tcp_handler procedure could easily be integrated into an interrupt driven scheme. The TCP does not implement urgent pointers (easy to add), and discards segments that are received out of order. It ignores the received window and always offers a fixed window size on input (i.e., it is not flow controlled). TinyTCP can be found via http://www.unusualresearch.com/tinytcp/tinytcp.htm Deng, et al. Expires April 27, 2011 [Page 8] Internet-Draft LwIP PS October 2010 5. Lightweight IP Protocols Implementation Issues 5.1. P1: Modularity and Layering In many TCP/IP implementations, the layered protocol design has served as a guide. Each protocol shall be implemented separately from the other. However, implementing the protocols in a strictly layered way sometimes leads to a situiation where the communication overhead between the protocol layers degrades the overall performance [RFC0817]. To tackle this problem, care must be taken so that only the important information is shared among layers. The other fact is that the operation systems used in the constrained systems most often do not maintain a strict protection barrier between the kernel and application processes, such as TinyOS and Contiki. This offers an opportunity for more relaxed communication between application and the lower layer protocols via shared memory, so that the internet-working stack can use the memory more efficiently. So in order to improve performance in terms of processing speed and memory usage, implementors should in many situations violate the layering assumptions. For example, when verifying the checksum of an incoming TCP segment and when demultiplexing a segment, passing the source and destinations addresses to TCP via funtion calls will inevitably result into more memory consumption. In this case, making the TCP module aware of the structure of the IP header is more efficient althout it violates certain layering and modularity assumptions. 5.2. P2: Memory Usage Constraints Constrained devices with several kilos of memory cannot survice dynamic memeory allocation schemes. Most used MTU for the IP networks are 1500 bytes or bigger. One full size IPv4/IPv6 packet scales to more than a thousand bytes memory when using dynamic allocation. How to holding the incoming and outgoing packets to reduce the memory usage is a challenging question then. For example, uIP [uip] uses preallocated buffers, in which a fixed table is used to hold the connection state while a global buffer is used to hold all the incoming and outgoing packets. Moreover, uIP also implements zero-copy mechanisms over the packet buffer to further reduce memory usage and minimize the data transfers between the TCP/IP stack and the application program. As a result, the size of the global packet buffer is determined by a configuration option at compile time, which guarantees that the buffer is large enough to accommodate a packet of the maximum allowed size. Nevertheless, due Deng, et al. Expires April 27, 2011 [Page 9] Internet-Draft LwIP PS October 2010 to the implemented zero-copy mechanisms the application program must be carefully designed and pay special attention to all the packets arriving from the network to avoid packet loss, which occurs whenever the network device buffers become full. 5.3. P3: Inefficient Socket APIs The BSD socket API requires the support of a multitasking system which imposes a significant overhead due to the need for task management, context switching and allocation of stack space. This is overbearing on many constrained platforms. As a result, it is desirable to have a reduced event driven API with only the minimal and necessary functions is used to implement a TCP/IP stack optimized for small 8 and 16-bit systems. Using this approach the application program is only invoked in response to specific events, such as data arriving from a connection or an incoming connection request, which allows achieving minimum response times even in low-end systems 5.4. P4: Protocol Interoperability Many implementations on constrained devices have implemeted different sets of features of the IP protocols. For example, some do not handle IP fragmentation and reassembly, and some do not handle IP options. Due to the lack of implementation guidelines and protocol implementation profiles, the interoperability between different implementations potentially is problem. Deng, et al. Expires April 27, 2011 [Page 10] Internet-Draft LwIP PS October 2010 6. Other Issues 6.1. Lightweight IP Mobility Protocol Mobility patterns for the small devices is different from what's been investigated in typical Internet IP mobility. IP mobility solutions, such as MIPv4/v6, DSMIPv6 or PMIPv6, normally have incurred overhead through the use of heartbeat signalings, IP tunnels and security associations. On small and constrained devices, they may not surrive, heartbeat signalings waking the device up too much for energy consumption. for example, Mobile IPv6 is too heavy in terms of security requirements and signaling exchange to be implemented on mobile GWs. 6.2. Lightweight Service Discovery There are lots of constrained devices in the networks. To find a service of an application, a service discovery is required. There are several kind of the service discovery protocol like DNS-SD, SSDP, or XMPP. These protocols were not designed to assume running on the constrained devices. For example, XMPP is based on XML. It is indeed scalable to its contants. But, it is likely not "thing- friendly". Each of them are necessary to be considered whether it is suitable or not. Further investigation is needed. 6.3. Lightweight Global Name Services Global name services such as DNS (Domain Name System) [RFC1034] have already been one of the most important infrastructures of the Internet nowadays. For example, DNS is an indispensable system of the Internet used for translating the "human-friendly" host names of computers on a TCP/IP network into their corresponding "machine- friendly" IP addresses. In general, DNS also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a worldwide, distributed name service, DNS is an essential component of the functionality of the Internet. Similarly, global name services will also be one of essential and key elements in constrained networks, which can be used for translating the "thing-friendly" names of constrained devices or RFID tags on a lightweight TCP/IP network into their corresponding "machine- friendly" addresses or other related information of another constrained network. The applications or devices on a constrained network can easily communicate with other devices on the same or any other constrained network with the name of the constrained device by a global name service, without considering whether the address of the targeted constrained device on a constrained network has been changed Deng, et al. Expires April 27, 2011 [Page 11] Internet-Draft LwIP PS October 2010 or not. To fulfill the aforementioned objective, a lightweight global name service based on the LWIP protocol needs to be researched. The efficiency of this kind of service is supposed to be the most important issue to be studied in future. 6.4. Device configuration There are several type of devices for several purposes, and several applications running on the devices in the scenarios. There are some devices which has a monitor and a keyboard to monitor and to control the networks for administrating. But, most devices like a sensor, or a actuator do not have enough space to have such interface. It means there is no configuration interface of the device. The constrained device sometimes have to be configuared via an flash memory, or another interface like USB. However, it is difficult to set up handreds of devices in the networks. Furthermore, some types of devices like a temperature sesor do not have a space for it. In this scenario, it is recommended to configure the devices via the network. And, special messaging and special format are not scalable. We should have to consider the method to configure the device via a similar way. Deng, et al. Expires April 27, 2011 [Page 12] Internet-Draft LwIP PS October 2010 7. Security Considerations TBD. Deng, et al. Expires April 27, 2011 [Page 13] Internet-Draft LwIP PS October 2010 8. Acknowledgement TBD. Deng, et al. Expires April 27, 2011 [Page 14] Internet-Draft LwIP PS October 2010 9. IANA Considerations This document does not require any IANA actions. Deng, et al. Expires April 27, 2011 [Page 15] Internet-Draft LwIP PS October 2010 10. Normative References [I-D.moskowitz-hip-rg-dex] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-hip-rg-dex-02 (work in progress), July 2010. [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982. [RFC0817] Clark, D., "Modularity and efficiency in protocol implementation", RFC 817, July 1982. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [tinyos] "Tiny Operation System on Mica Series Sensors", . [uip] "Full TCP/IP for 8-bit Architectures", . [usd] Canfeng Chen, "uSD: an SD-based Mobile Gateway to Wireless Sensor Network". Deng, et al. Expires April 27, 2011 [Page 16] Internet-Draft LwIP PS October 2010 Authors' Addresses Hui Deng China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: denghui@chinamobile.com Shoichi Sakane Cisco 2-1-1 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-0409 Japan Email: ssakane@cisco.com Wassim Michel Haddad Ericsson 300 Holger Dr San Jose, CA 95134 US Phone: +1 646 256 2030 Email: Wassim.Haddad@ericsson.com Ning Kong CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3147 Email: nkong@cnnic.cn Deng, et al. Expires April 27, 2011 [Page 17]