Full TCP/IP for 8-Bit Architectures - dunkels.com

1 Full TCP/IP for 8-Bit ArchitecturesAdam DunkelsSwedish institute of computer adam/AbstractWe describe two small and portable TCP/IP implemen-tations fulfilling the subset of RFC1122 requirementsneeded for full host-to-host interoperability. Our TCP/IPimplementations do not sacrifice any of TCP s mecha-nisms such as urgent data or congestion control. Theysupport IP fragment reassembly and the number of mul-tiple simultaneous connections is limited only by theavailable RAM. Despite being small and simple, our im-plementations do not require their peers to have com-plex, full-size stacks, but can communicate with peersrunning a similarly light-weight stack. The code size ison the order of 10 kilobytes and RAM usage can be con-figured to be as low as a few hundred IntroductionWith the success of the Internet, the TCP/IP protocolsuite has become a global standard for is the underlying protocol used for web pagetransfers, e-mail transmissions, file transfers, and peer-to-peer networking over the Internet.

2 For embedded sys-tems, being able to run native TCP/IP makes it possi-ble to connect the system directly to an intranet or eventhe global Internet. Embedded devices with full TCP/IPsupport will be first-class network citizens, thus beingable to fully communicate with other hosts in the TCP/IP implementations have required fartoo much resources both in terms of code size and mem-ory usage to be useful in small 8 or 16-bit systems. Codesize of a few hundred kilobytes and RAM requirementsof several hundreds of kilobytes have made it impossi-ble to fit the full TCP/IP stack into systems with a fewtens of kilobytes of RAM and room for less than 100kilobytes of [21] is both the most complex and the most widelyused of the transport protocols in the TCP/IP stack.

3 TCPprovides reliable full-duplex byte stream transmissionon top of the best-effort IP [20] layer. Because IP mayreorder or drop packets between the sender and the re-ceiver, TCP has to implement sequence numbering andretransmissions in order to achieve reliable, ordered have implemented two small generic and portableTCP/IP implementations,lwIP(lightweight IP) anduIP(micro IP), with slightly different design goals. The lwIPimplementation is a full-scale but simplified TCP/IP im-plementation that includes implementations of IP, ICMP,UDP and TCP and is modular enough to be easily ex-tended with additional protocols. lwIP has support formultiple local network interfaces and has flexible con-figuration options which makes it suitable for a wide va-riety of uIP implementation is designed to have only the ab-solute minimal set of features needed for a full TCP/IPstack.

4 It can only handle a single network interface anddoes not implement UDP, but focuses on the IP, ICMPand TCP implementations are fully written in the C pro-gramming language. We have made the source codeavailable for both lwIP [7] and uIP [8]. Our imple-mentations have been ported to numerous 8- and 16-bitplatforms such as the AVR, H8S/300, 8051, Z80, ARM,M16c, and the x86 CPUs. Devices running our imple-mentations have been used in numerous places through-out the have studied how the code size and RAM usage of aTCP/IP implementation affect the features of the TCP/IPimplementation and the performance of the communica-tion. We have limited our work to studying the imple-mentation of TCP and IP protocols and the interactionbetween the TCP/IP stack and the application such as address configuration, security, and en-ergy consumption are out of the scope of this main contribution of our work is that we have shownthat is it possible to implement a full TCP/IP stack thatis small enough in terms of code size and memory usageto be useful even in limited 8-Bit , other small implementations of the TCP/IPstack have made it possible to run TCP/IP in small 8-bitsystems.

5 Those implementations are often heavily spe-cialized for a particular application, usually an embed-ded web server, and are not suited for handling genericTCP/IP protocols. Future embedded networking appli-cations such as peer-to-peer networking require that theembedded devices are able to act as first-class networkcitizens and run a TCP/IP implementation that is not tai-lored for any specific , existing TCP/IP implementations for smallsystems assume that the embedded device always willcommunicate with a full-scale TCP/IP implementationrunning on a workstation-class machine. Under this as-sumption, it is possible to remove certain TCP/IP mech-anisms that are very rarely used in such situations. Manyof those mechanisms are essential, however, if the em-bedded device is to communicate with another equallylimited device, , when running distributed peer-to-peer services and paper is organized as follows.

6 After a short intro-duction to TCP/IP in Section 2, related work is presentedin Section 3. Section 4 discusses RFC standards compli-ance. How memory and buffer management is done inour implementations is presented in Section 5 and theapplication program interface is discussed in Section of the protocol implementations is given in Sec-tion 7 and Section 8 comments on the performance andmaximum throughput of our implementations, presentsthroughput measurements from experiments and reportson the code size of our implementations. Section 9 givesideas for future work. Finally, the paper is summarizedand concluded in Section TCP/IP overviewFrom a high level viewpoint, the TCP/IP stack can beseen as a black box that takes incoming packets, and de-multiplexes them between the currently active connec-tions.

7 Before the data is delivered to the application,TCP sorts the packets so that they appear in the orderthey were sent. The TCP/IP stack will also send ac-knowledgments for the received 1 shows how packets come from the network de-Web server applicationstackNetworkinterfaceIncoming packetsApplicationdataWeb server applicationWeb server applicationData logger applicationMail sender applicationTCP/IPFigure 1: TCP/IP input , pass through the TCP/IP stack, and are delivered tothe actual applications. In this example there are five ac-tive connections, three that are handled by a web serverapplication, one that is handled by the e-mail sender ap-plication, and one that is handled by a data logger server applicationWeb server applicationData logger applicationMail sender applicationWeb server applicationOutgoing NetworkFigure 2: TCP/IP output high level view of the output processing can be seenin Figure 2.

8 The TCP/IP stack collects the data sent bythe applications before it is actually sent onto the net-work. TCP has mechanisms for limiting the amount ofdata that is sent over the network, and each connectionhas a queue on which the data is held while waiting tobe transmitted. The data is not removed from the queueuntil the receiver has acknowledged the reception of thedata. If no acknowledgment is received within a specifictime, the data is arrives asynchronously from both the network andthe application, and the TCP/IP stack maintains queuesin which packets are kept waiting for service. Becausepackets might be dropped or reordered by the network,incoming packets may arrive out of order. Such pack-ets have to be queued by the TCP/IP stack until a packetthat fills the gap arrives.

9 Furthermore, because TCP lim-its the rate at which data that can be transmitted overeach TCP connection, application data might not be im-mediately sent out onto the full TCP/IP suite consists of numerous protocols,ranging from low level protocols such as ARP whichtranslates IP addresses to MAC addresses, to applicationlevel protocols such as SMTP that is used to transfer e-mail. We have concentrated our work on the TCP andIP protocols and will refer to upper layer protocols as the application . Lower layer protocols are often im-plemented in hardware or firmware and will be referredto as the network device that are controlled by the net-work device provides a reliable byte stream to the upper layerprotocols.

10 It breaks the byte stream into appropriatelysized segments and each segment is sent in its own IPpacket. The IP packets are sent out on the network bythe network device driver. If the destination is not onthe physically connected network, the IP packet is for-warded onto another network by a router that is situatedbetween the two networks. If the maximum packet sizeof the other network is smaller than the size of the IPpacket, the packet is fragmented into smaller packets bythe router. If possible, the size of the TCP segments arechosen so that fragmentation is minimized. The finalrecipient of the packet will have to reassemble any frag-mented IP packets before they can be passed to Related workThere are numerous small TCP/IP implementations forembedded systems.