Internet DRAFT - draft-chen-lwip-implementataion
draft-chen-lwip-implementataion
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]
