INTERNET-DRAFT Zach Shelby
Martti Huttunen
Mikko Saarnivala
University of Oulu
Janne Riihijrvi
Ossi Raivio
Petri Mh÷nen
Aachen University
February 2005
nanoIP
<draft-shelby-nanoip-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 1]
INTERNET-DRAFT nanoIP February 2005
Abstract
This Internet-Draft proposes protocols specifically for use with
embedded devices for networking. These protocols offer similar
services at the socket layer as UDP or TCP, but do so with much less
overhead and lower implementation complexity. These protocols
together are part of the nanoIP protocol suite.
1. Introduction
NanoIP is a protocol suite for the most minimal of devices [2]. It
consists a reliable transport called nanoTCP, and a connectionless
transport called nanoUDP. Note that the "TCP" and "UDP" in nanoTCP
and nanoUDP do not strictly refer to the TCP and UDP protocols, but
instead refer to functional similarity. NanoIP contains no network-
layer protocol, no network-layer address space, and no ICMP. It is
meant to provide a UDP/TCP functionally equivalent socket interface
for embedded applications.
NanoUDP and nanoTCP are lightweight IP/UDP- and IP/TCP-like protocols
designed for use in a single subnet by small embedded devices. There
are no network-layer addresses, MAC addresses are re-used instead.
Port numbers are supplied to serve a similar purpose as in standard
UDP and TCP. These protocols can be used for peer-peer communication
as no gateway or coordinating device is necessary.
1.1. Applicability
For minimal and embedded devices where full TCP/IP takes too much
bandwidth, power, or RAM/ROM size. These protocols also considerably
reduce protocol stack complexity. It can be implemented in VHDL and
included in the smallest of sensors. It can also be used over any
wireless or wired network technology that use MAC addresses or over
P-to-P links. Broadcast capability is useful, but not required. The
protocols are also useful over links with extremely small frame
sizes, such as narrowband ISM transceivers.
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 2]
INTERNET-DRAFT nanoIP February 2005
1.2. New Architectural Entities
None.
1.3. Terminology
nanoIP
A term used to describe the collection of transport and application
protocols for embedded networking.
nanoUDP
A connectionless transport that provides fragmentation in addition to
port numbers.
nanoTCP
A reliable transport without congestion control using a fixed window
size. Has good wireless properties.
2. Addressing and subnets
NanoIP requires the use of unique link layer medium access control (MAC)
addresses instead of IP addresses. In this document IEEE 48-bit MAC
addresses are assumed, but any address format is useable. In the case
of a broadcast only data link layer applications must then distinguish
between hosts. 48-bit addresses are represented by the (human readable)
ASCII form
XX:XX:XX:XX:XX:XX
Port numbers are utilized in nanoIP just as in TCP and UDP.
Therefore, a nanoIP address plus destination port is represented by
XX:XX:XX:XX:XX:XX.port
Broadcast is represented by
FF:FF:FF:FF:FF:FF
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 3]
INTERNET-DRAFT nanoIP February 2005
An example URL for use with nanoIP would be
http://0E:01:6A:34:20:3D.80/index.wml
As nanoIP does not include routing functionality, networking with
it is limited to subnetworks where all nodes are accessible by MAC
address. Subnetworks can be expanded using bridging technology,
thus expanding the size of network that nanoIP can use. NanoIP is
also meant to be a zero configuration technology as there are no
parameters to be discovered to configure the protocol properly. It
is also meant to be infrastructureless, not needing any supporting
nodes. It is assumed that all nodes agree upon the effective maximum
transmission unit (MTU) on a link, and all nodes are capable of
receiving datagrams of MTU length.
3. NanoUDP
NanoUDP is a minimal connectionless transport protocol. It provides
basic encapsulation with payload length, and source/destination
ports. Fragmentation can be optionally implemented for nodes which
can handle buffers larger than the link MTU size.
3.1. Header Format (5 octets)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Protocol / Flags | Length /
+-----------+-----------------------------------+
/ Length cont. | Src Port |
+-----------------------------+-----------------+
| Dst Port | |
+-----------+-----------+ |
| Data |
/ ...
| N octets |
+-----------------------------------------------+
Protocol 4-bit protocol number = 0
Flags 4-bit. FIRST, LAST, reserved, reserved.
Length 16-bit unsigned integer = number of octets N of the
packet payload.
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 4]
INTERNET-DRAFT nanoIP February 2005
Src Port 8-bit unsigned integer
Dst Port 8-bit unsigned integer
Only the first two of the flag bits are used in nanoUDP fragmenta-
tion, the remaining two are set to zero by the sender, and are to be
ignored by the receiver. Both FIRST and LAST are set to 1 for normal
packets.
Source and destination port spaces are limited to 256 ports each. The
length field represents the payload size in octets, except for in
fragments, where the length is used for other purposes. The maximum
fragment size is 64KB.
3.2. Fragmentation
Fragmentation is optional for nanoUDP. If not supported, attempting
to send a packet larger than the MTU should give an error message to
the application, and any received fragments are to be discarded.
If the size of the packet to be sent exceeds the link MTU and the
sending node supports fragmentation it will be fragmented as follows.
All fragments, except possibly the last one, have a payload of size
MTU - 5. The header fields of the various fragments are set according
to these rules:
1. In the first fragment FIRST = 1, and the LAST = 0.
2. In the last fragment FIRST = 0, and the LAST = 1.
3. In the other "middle" fragments, FIRST = LAST = 0.
4. All fragments carry the same port numbers.
5. In the first fragment, length is set to the total length of the
application payload, and in the last fragment length is set to the
actual length of the payload. In middle fragments length acts as the
"fragment offset" of IPv4, that is, it is set to the number (starting
from zero) of the first octet in the payload.
The defragmentation process is done by taking away the headers, con-
catenating the payloads in the order given by the length field into a
buffer, and when the last fragment arrives, passing the buffer to the
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 5]
INTERNET-DRAFT nanoIP February 2005
application. Reassembly of the fragments by a node supporting frag-
mentation is governed by the following rules:
1. When defragmenting a payload, all nanoUDP packets that are not
fragments are given immediately to the application.
2. The implementation is free to use a time-out of any kind, after
which the buffer is cleared in the event of incomplete defragmenta-
tion.
3. The defragmentation process should be immediately started anew, if
a first segment arrives from the same node that the receiver is
already defragmenting a payload from.
4. The implementation is free to choose how many nodes it simultane-
ously accepts fragmented payloads from and how large these payloads
can be.
The following is an example if assuming an MTU size of 85 and an
application payload of 210. Notice that the effective payload per
packet is then 80 octets.
+----------------------------------------+
| Application payload: 210 octets |
+----------------------------------------+
+---+------------ Length = 210 (total length)
|HDR|Octets 0-79| FIRST = 1
+---+-----------+ LAST = 0
+---+-------------+ Length = 80 (fragment length)
|HDR|Octets 80-159| FIRST = 0
+---+-------------+ LAST = 0
+---+--------------+ Length = 50 (fragment payload)
|HDR|Octets 160-209| FIRST = 0
+---+--------------+ LAST = 1
4. NanoTCP
NanoTCP is equivalent in functionality to TCP [1], except that it
does not implement adaptive flow control, and some of the lesser used
functionality. A detailed header and differences from TCP are given
below.
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 6]
INTERNET-DRAFT nanoIP February 2005
4.1. Header Format (9 octets)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Protocol / Flags | Length /
+-----------------------+------------------------
/ Length cont. | Src Port |
------------------------+-----------------------+
| Dst Port | Sequence /
+-----------------------+------------------------
/ Sequence (cont.) | Acknowledgement /
------------------------+------------------------
/ Ack (cont.) | |
------------------------+ |
| Data |
/ ... /
| N octets |
+-----------------------------------------------+
Notice that for ease of parsing the first five octets of the
nanoTCP header are identical to those of the nanoUDP header.
Protocol 4-bit protocol number = 1
Flags Four bits, from left to right, ACK, RST, SYN, FIN.
Length 16-bit unsigned integer = number of octets N of the
packet payload.
Src Port 8-bit unsigned integer
Dst Port 8-bit unsigned integer
SEQ Number 16-bit unsigned integer
ACK Number 16-bit unsigned integer
4.2. NanoTCP Operation
The NanoTCP protocol operates exactly as in regular TCP (as per [1]
with corrections, but not additions, from other RFCs), except for the
following differences.
1. The port number and seq/ack number spaces are smaller.
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 7]
INTERNET-DRAFT nanoIP February 2005
2. There is no PUSH or urgent data functionality.
3. There is no slow-start or window management. The Window Size is
set to a fixed size for the lifetime of a connection using the pay-
loads of the first two handshake segments. When referring to [1] this
is to be understood as if all the segments had their Window fields
set to this value.
4. There is no checksum.
5. The RTO is computed in an implementation-specific manner. Example
values should be given for different link technologies.
6. Nodes SHOULD use timeouts and delayed or piggybacked acknowledge-
ments. If this is impossible then just ACK every segments.
This transport is meant to function well over wireless links, with
bridging, and on very limited nodes. The window size negotiation dur-
ing handshaking is important as it respects implementation with lim-
ited buffer sizes. Without congestion control nanoTCP simply imple-
ments ARQ and is does not suffer from wireless losses as TCP does.
This protocol however assumes that the link layer is responsible for
detecting and discarding errored frames, as no checksum is included.
6. Intellectual Property Right Notice
No intellectual property is known by the authors to exist regarding
these protocols or methods.
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 8]
INTERNET-DRAFT nanoIP February 2005
References
[1] Jon Postel, "Transmission Control Protocol", RFC793, September
1981.
[2] Z. Shelby et al., "NanoIP: The Zen of Embedded Networking", Proceedings of
the ICC, May 2003.
Authors' Addresses
Zach Shelby
Martti Huttunen
Mikko Saarnivala
University of Oulu
Center for Wireless Communications
PO Box 4500
90014 Oulu, Finland
phone: +358 40 779 6297
email: zach.shelby@ee.oulu.fi
Janne Riihijrvi
Ossi Raivio
Petri Mh÷nen
Aachen University (RWTH)
Department of Wireless Networks
Kackertstrasse 9, D-52072 Aachen, Germany
email: jar@comnets.rwth-aachen.de
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 9]
INTERNET-DRAFT nanoIP February 2005
Table of Contents
1. Introduction ................................................... 2
1.1. Applicability ................................................ 2
1.2. New Architectural Entities ................................... 3
1.3. Terminology .................................................. 3
2. Addressing and subnets ......................................... 3
3. NanoUDP
3.1. Header Format (5 octets)
................................................................ 4
3.2. Fragmentation ............................................. 5
4. NanoTCP ........................................................ 6
4.1. Header Format (9 octets) .................................. 7
4.2. NanoTCP Operation ......................................... 7
6. Intellectual Property Right Notice ............................. 8
References ........................................................ 9
Authors' Addresses ................................................ 9
Shelby, Huttunen, Saarnivala, Riihijrvi, Raivio, Mh÷nen [Page 10]