LwIP Working Group W. Chen Internet-Draft Bit-way Corporation Intended status: Informational November 8, 2010 Expires: May 12, 2011 Implementation Techniques of the Lightweight TCP/IP Stack draft-chen-lwip-implementataion-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 May 12, 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 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 Chen Expires May 12, 2011 [Page 1] Internet-Draft Implementation Techniques November 2010 described in the Simplified BSD License. Table of Contents 1. Non-layered protocols . . . . . . . . . . . . . . . . . . . . 3 2. Existing Protocols . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Network Layer . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Transport Layer . . . . . . . . . . . . . . . . . . . . . 4 2.3. Application Layer . . . . . . . . . . . . . . . . . . . . 4 3. Non-layered protocols . . . . . . . . . . . . . . . . . . . . 5 4. Memory Management . . . . . . . . . . . . . . . . . . . . . . 6 5. Application Programming Interfaces . . . . . . . . . . . . . . 7 6. TCP Communication . . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Implementations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Chen Expires May 12, 2011 [Page 2] Internet-Draft Implementation Techniques November 2010 1. Non-layered protocols With the era of the Internet of Things, the applications of smart objects are more and more widely used. Smart objects are usually low- power and have limited memory communication capabilities. In the past, they usually communicated through a protocol-translation gateway, which is typically of non-IP architecture. However, protocol gateways are inherently complex to design, manage, and deploy. It requests for scalability, interoperability and solid standardization based networking technology to support a large number of applications of smart objects. It is well known that IP is a stable, long-lived and highly scalable communication technology. So it can support a wide range of applications, devices, and underlying communication technologies. As smart objects will connect a larger number of devices than any other existing Internet, scalability is critical. The next generation Internet protocol, IPv6, expands the address space of IP to 2^128, which has been said to be enough to provide every grain of sand on the planet with an IP address. In addition, the advantage of Plug and Play, security, QoS, mobility of IPv6 make it better to meet the needs of smart objects connecting. However, IPv6 cannot be directly applied in the smart device. It requests for correspondingly simplifying the IPv6 protocol stacks and routing mechanisms to meet the requirements of network with low power consumption, low storage capacity and low transfer rate. This document introduces the design and implementation of the Lightweight TCP/IP Stack, and the problems met by implementers. Chen Expires May 12, 2011 [Page 3] Internet-Draft Implementation Techniques November 2010 2. Existing Protocols 2.1. Network Layer For constrained devices, 6LoWPAN (IPv6 over Low power WPAN) Working Group in IETF specifies some feasible implementation at network layer. 6LoWPAN intends to establish a low power Wireless Personal Area Network standard, and uses IPv6 as the low layer protocol in IEEE 802.15.4. Until now, 6LoWPAN WG has worked out some overviews and protocol drafts in RFC4944 and RFC4919, and brought up some important drafts about head compression and decompression, neighbor discovery, security and mobility management. ROLL Working Group specifies routing over Low-Power and Lossy Networks(LLN), which is also based on IPv6. The goal of this WG is to make the third layer routing to traverse any number of base link layer protocols and physical medium. Compared with 6LoWPAN of making the frame size to fit with IPv6, ROLL is to adapt or create a protocol, which can solve the package loss problem of low power devices that often cause by interference and mobility. Until now, there are some drafts and RFC approved. 2.2. Transport Layer In common cases, TCP and UDP are used in transport layer. However, for constrained devices, TCP and UDP are too heavy to implement all the functions. Some working groups are involved in this kind of work, but there is seemingly no specific approach to deal with simplifying TCP and UDP. 2.3. Application Layer CoRE Working Group specifies CoAP protocol to deal with constrained resource network. CoAP is a specialized RESTful transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. It can easily translate to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. Chen Expires May 12, 2011 [Page 4] Internet-Draft Implementation Techniques November 2010 3. Non-layered protocols In most common cases, TCP/IP protocols are implemented by modularity and layering. But for the constraint systems, layering will increase the cost so as to affect the overall performance. Moreover, there is no strict barrier between the kernel and application processes, such as TinyOS and Contiki. So there is no strict layer in Lightweight TCP/IP protocols, which are designed to be tight-coupled in order to shorten the codes and save the memory. Non-layered protocols can be implemented by queue method to cache the packages. As long as there is no layer concept, when sending packages, application calls directly to the end. When receiving, protocol stack uses callback functions to get the packages. And all the applications need to register the callback functions in advance. Furthermore, the retransmission should be done by applications. +-----------+ +-----------+ +-----------+ +----------- + | | | | | | | | |Application|---->|tcp_write()|---->| ip_send() |---->|netif_send()| | | | | | | | | +-----------+ +-----------+ +-----------+ +------------+ send packet +-----------+ +-----------+ +-----------+ +------------+ | | | | | | | | |netif_rcv()|---->| ip_rcv() |---->| tcp_rcv() |---->|Application | | | | | | | | | +-----------+ +-----------+ +-----------+ +------------+ receive packet Figure 1: Sending and Receiving Packets What's more, the TCP should care about the connection states, e.g. three-way handshaking. Chen Expires May 12, 2011 [Page 5] Internet-Draft Implementation Techniques November 2010 4. Memory Management Many TCP/IP protocols use dynamic memory allocation schemes. However, constraint devices with several kilo of memory can survive this kind of schemes. Lightweight TCP/IP Protocols use static memory allocation schemes to pre-allocation memory for each usage. Memory allocation is done when compiling, which is base on the pre-decision of the package size in the network. More attention should be paying to the cache to ensure it can hold the greatest size package. Chen Expires May 12, 2011 [Page 6] Internet-Draft Implementation Techniques November 2010 5. Application Programming Interfaces Multitasking system imposes a significant overhead for the need for task management, context switching and allocation of stack space. As a result, the constrained systems don't support multitask. Lightweight TCP/IP Protocols are designed to be simple, single-task, and have a reduced event driven API with only the needed functions. For example, there're no socket options which are needed in the integrity socket in order to save memory, as we merely develop quite simple applications in constrained systems. Furthermore, there's no need for receive function, for the protocol stack use callback functions to receive packages, as mentioned before. Chen Expires May 12, 2011 [Page 7] Internet-Draft Implementation Techniques November 2010 6. TCP Communication Many TCP/IP implementations, realize the sliding window algorithm, which allows the sender to deliver multiple segments continuously, without having to stop and wait for an acknowledgment for each segment. The congestion control algorithm is realized as well, in order to limit the number of simultaneous TCP segments in the network. Furthermore, overtime retransmission mechanism is sufficiently implemented by the stack. Lightweight TCP implementations, only handle a TCP connection at a time, while a TCP connection only allows a TCP segment to be unacknowledged. Due to a TCP connection dealt at a time, there is no need for the sliding window algorithm. Due to no more than one TCP segment per connection, the number of simultaneous TCP segments in the network is rather limited, and there is no need for he congestion control algorithm either. As for the overtime retransmission mechanism, it is up to the stack to decide when to retransmit, but the application to execute the retransmission actually. Moreover, checksum algorithm shall be implemented according to the architecture. Chen Expires May 12, 2011 [Page 8] Internet-Draft Implementation Techniques November 2010 7. Protocol Implementations Lightweight TCP/IP implementations, in resource-constrained devices, shall be fully compliant with the standard TCP/IP and other simplified and limited TCP/IP implementations. They should be able to support IP, NDP and TTL time-out estimation. For ICMPv6, only some common types should be enforced,such as echo request and echo request. IP options and fragment reassembly can be ignored, as fragment reassembly can be avoided by MTU configuration. Chen Expires May 12, 2011 [Page 9] Internet-Draft Implementation Techniques November 2010 8. Security Considerations TBD. Chen Expires May 12, 2011 [Page 10] Internet-Draft Implementation Techniques November 2010 9. IANA Considerations This document does not require any IANA actions. Chen Expires May 12, 2011 [Page 11] Internet-Draft Implementation Techniques November 2010 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Chen Expires May 12, 2011 [Page 12] Internet-Draft Implementation Techniques November 2010 Author's Address Wenlong Chen Bit-way Corporation Beijing China Email: wenlongchenn@gmail.com Chen Expires May 12, 2011 [Page 13]