[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                              Zach Shelby
                                                        Martti Huttunen
                                                       Mikko Saarnivala
                                                     University of Oulu
                                                       Janne Riihij„rvi
                                                            Ossi Raivio
                                                          Petri M„h÷nen
                                                      Aachen University
                                                          February 2005


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Shelby, Huttunen, Saarnivala, Riihij„rvi, Raivio, M„h÷nen        [Page 1]

INTERNET-DRAFT                   nanoIP                    February 2005


   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, Riihij„rvi, Raivio, M„h÷nen        [Page 2]

INTERNET-DRAFT                   nanoIP                    February 2005

1.2. New Architectural Entities


1.3. Terminology


   A term used to describe the collection of transport and application
   protocols for embedded networking.


   A connectionless transport that provides fragmentation in addition to
   port numbers.


   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


   Port numbers are utilized in nanoIP just as in TCP and UDP.
   Therefore, a nanoIP address plus destination port is represented by


   Broadcast is represented by


Shelby, Huttunen, Saarnivala, Riihij„rvi, Raivio, M„h÷nen        [Page 3]

INTERNET-DRAFT                   nanoIP                    February 2005

   An example URL for use with nanoIP would be


   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, Riihij„rvi, Raivio, M„h÷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

   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, Riihij„rvi, Raivio, M„h÷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-

   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

Shelby, Huttunen, Saarnivala, Riihij„rvi, Raivio, M„h÷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, Riihij„rvi, Raivio, M„h÷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

Shelby, Huttunen, Saarnivala, Riihij„rvi, Raivio, M„h÷nen        [Page 8]

INTERNET-DRAFT                   nanoIP                    February 2005


   [1] Jon Postel, "Transmission Control Protocol", RFC793, September

   [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 Riihij„rvi
   Ossi Raivio
   Petri M„h÷nen
   Aachen University (RWTH)
   Department of Wireless Networks
   Kackertstrasse 9, D-52072 Aachen, Germany
   email: jar@comnets.rwth-aachen.de

Shelby, Huttunen, Saarnivala, Riihij„rvi, Raivio, M„h÷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, Riihij„rvi, Raivio, M„h÷nen        [Page 10]

Html markup produced by rfcmarkup 1.129a, available from https://tools.ietf.org/tools/rfcmarkup/