INTERNET-DRAFT Zach Shelby Martti Huttunen Mikko Saarnivala University of Oulu Janne Riihij„rvi Ossi Raivio Petri M„h÷nen Aachen University February 2005 nanoIP 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, Riihij„rvi, Raivio, M„h÷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, Riihij„rvi, Raivio, M„h÷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, Riihij„rvi, Raivio, M„h÷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, 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 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, 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- 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, 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 "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, Riihij„rvi, Raivio, M„h÷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 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]