Internet DRAFT - draft-gothberg-micro-ip
draft-gothberg-micro-ip
INTERNET-DRAFT D. Gothberg
Category: Experimental Computer Club West
<draft-gothberg-micro-ip-00.txt>
September 2000 Comments are welcome at:
Expires: March 2001 david@gothberg.com
Micro-IP for embedded systems
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This protocol is intended to provide easy communication between
small embedded nodes and between those nodes and the Internet.
Typically this means nodes in vehicles, home-appliances or nodes
on computerised machinery.
Gothberg Experimental [Page N]
INTERNET-DRAFT Micro-IP for embedded systems May 2000
Table of Contents
0. Some comments to this draft . . . . . . . . . . . . . . . . N
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . N
2. Conventions of this document . . . . . . . . . . . . . . . . N
3. Protocol layers . . . . . . . . . . . . . . . . . . . . . . N
4. Micro-IP datagram format . . . . . . . . . . . . . . . . . . N
5. Example network . . . . . . . . . . . . . . . . . . . . . NN
6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . NN
7. Protocols . . . . . . . . . . . . . . . . . . . . . . . . NN
8. Checksums . . . . . . . . . . . . . . . . . . . . . . . . NN
9. Connecting Micro-IP to the Internet . . . . . . . . . . . NN
10. UDP for Micro-IP . . . . . . . . . . . . . . . . . . . . . NN
11. TCP for Micro-IP . . . . . . . . . . . . . . . . . . . . . NN
12. ICMP for Micro-IP . . . . . . . . . . . . . . . . . . . . NN
13. ARP for Micro-IP . . . . . . . . . . . . . . . . . . . . . NN
14. RARP, BOOTP and DHCP for Micro-IP . . . . . . . . . . . . NN
15. DNS for Micro-IP . . . . . . . . . . . . . . . . . . . . . NN
16. Micro-IP over serial links . . . . . . . . . . . . . . . . NN
17. Fragmenting Micro-IP datagrams . . . . . . . . . . . . . . NN
18. Quality of Service for Micro-IP . . . . . . . . . . . . . NN
19. Security considerations . . . . . . . . . . . . . . . . . NN
20. Some comments . . . . . . . . . . . . . . . . . . . . . . NN
21. References . . . . . . . . . . . . . . . . . . . . . . . . NN
22. Authors' addresses . . . . . . . . . . . . . . . . . . . . NN
23. Full copyright statement . . . . . . . . . . . . . . . . . NN
0. Some comments to this draft
We have chosen to call this protocol Micro-IP. We would not recommend
the use of the terms "embedded IP" or "mini IP" because they already
have other meaning in the networking industry.
This document is specifying a whole new version of IP that might
become very widespread in the embedded world. We who build embedded
systems are in a need of this kind of minimalistic IP. Do not
condemn this protocol, instead help us get it right!
1. Introduction
This protocol is intended to provide internet-like communication
between small embedded nodes on the same or different buses. It is
also intended to provide those nodes with communication to and from
the Internet. Typically this means nodes in vehicles, home-appliances
or nodes on computerised machinery.
This protocol is not intended to replace the real-time protocols used
in embedded systems.
Micro-IP much resembles IPv4. But all "unnecessary" functions have
been removed and some things have been simplified. Micro-IP uses
one byte addressing thus limiting the number of nodes on a network
or group of networks to 252. (There are really 256 addresses but
some are reserved.) Micro-IP networks can be connected to the
Internet, both IPv4 and IPv6, using techniques such as proxying.
Micro-IP also includes a technique we call "address mapping" that
makes Micro-IP nodes visible on the Internet. Thus making it possible
for an embedded node on a Micro-IP network to act as a full
fledged server towards the Internet.
1.1 Why Micro-IP?
We are now adding connectivity to ever-smaller computers. Some
cars of today (year 2000) have as much as 26 computerised nodes
connected together over three data buses. Homes are being built
where your dish washer can send status reports to your cellular
phone. Engines in power plants and bigger ships have up to three
data buses with multiple nodes and terminals. Now we are
connecting all those small nodes to bigger networks and even to
the Internet so that we can get status reports, remote control
them and even update their software. Today it is costly to make
all these nodes interoperate since all of these small networks use
different communication protocols.
The IP suite of protocols have proven unbeatable when it comes to
connecting many different nodes over many different network types.
IP seams to be replacing all other internetworking protocols.
Because of that people have started to put IP into embedded nodes.
But IPv4 is to big for many embedded nodes. And now the Internet
is going towards IPv6 that takes up even more space. So we need a
lightweight IP protocol that fits into embedded systems but still
interoperates neatly with both IPv4 and IPv6. That's what Micro-IP
is all about.
1.2 Designing the protocol
When constructing a light weight IP-protocol there is a number of
things one should keep in mind. In IPv4 and IPv6 as much
intelligence as possible is put in the endpoints and as little as
possible in the routers. In embedded systems it is probably better
to move some of the intelligence to the routers since the nodes
are very small but the routers can be allowed to be big. Many
implementations of IPv4 for embedded systems are only partial
implementations. Actually, some parts of the functionality in IPv4
are not even used in bigger Internet hosts. So it should be ok to
leave out all the functionality that isn't normally used. What is
important is that the applications gets the services they need.
All this boils down to some basic demands:
* The applications needs to connect to the real Internet.
* Preferably the applications should not need to be
aware of that they are running on Micro-IP. That is,
they need something that looks like TCP and UDP.
* Micro-IP should take up very little code space and
memory space in the nodes. It may demand more of
the routers.
* If possible, Micro-IP should be easy to understand
and easy to implement.
2. Conventions of this document
In this document one byte is always eight bits.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
A note for the reader who is more familiar with embedded systems than
IP systems: Packet, frame, datagram, segment and message are almost
synonymous. In "Internet lingua" they use different words depending
on what type of protocol and what level the protocol works at. The
proper usage seems to be CAN frame, Ethernet frame, ICMP message, IP
datagram, UDP datagram and TCP segment.
The diagrams in this document put the first transmitted byte in the
upper left corner of the diagrams:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| First byte | Second byte |
+-----------------------+-----------------------+
| Third byte | Fourth byte |
+-----------------------+-----------------------+
The diagrams also put the most significant bit on the left:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| 1 0 0 0 0 0 0 0| = Decimal value 128.
+-----------------------+
The first transmitted byte is the most significant byte. That is, the
network byte order is "big endian".
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| = Decimal value
+-----------------------+-----------------------+ 32768.
First byte transmitted Second byte transmitted
3. Protocol layers
The protocol layers of a Mini-IP stack is the same as for most
other IP-protocols:
+------+ +------+-----+ +-----+-----+--------+
| Ping | | TFTP | Wap | | Web | FTP | Telnet | Application layer
| | +------+-----+ +-----+-----+--------+
+------+ | UDP | | TCP | Transport layer
| +--+------------+--+--------------------+
| ICMP | |
+------+ Micro-IP +-----+ Internet layer
| | ARP |
+---------------+-------+----------------+-----+
| PPP or SLIP | | Local network driver | Network Interface
| | | | layer
+---------------+ +----------------------+
| Serial device | | Local network device | Hardware layer
+---------------+ +----------------------+
Note that we have moved ARP up one layer compared to IPv4.
4. Micro-IP datagram format
Since this document is still very much "work in progress" the exact
format of the Micro-IP datagram is not yet decided. Instead there are
three slightly different suggestions.
Suggested IP datagram format A:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Version | Hops | Total length |
+-----------+-----------+-----------------------+
| Source address | Destination address |
+-----------------------+-----------------------+
| Checksum |
+-----------------------+-----------------------+
| Protocol | Flags / Padding |
+-----------------------+-----------------------+
| data |
...
| (N bytes) |
+-----------------------------------------------+
Suggested IP datagram format B:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Version | Hops | Total length |
+-----------+-----------+-----------------------+
| Source address | Destination address |
+-----------------------+-----------------------+
| Checksum |
+-----------------------+-----------------------+
| Protocol | Flow |
+-----------------------+-----------------------+
| data |
...
| (N bytes) |
+-----------------------------------------------+
Suggested IP datagram format C:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Version | Protocol | Total length |
+-----------+-----------+-----------------------+
| Source address | Destination address |
+-----------------------+-----------------------+
| Checksum |
+-----------------------------------------------+
| data |
...
| (N bytes) |
+-----------------------------------------------+
An entire Micro-IP datagram including the header MUST NOT have a size
bigger than 255 bytes. The datagram header has several fields:
Version = 4 bits. Until IANA has assigned a version
for Micro-IP this field SHOULD be set to 0.
When IANA have assigned a version the proper
value MUST be set.
Hops = 4 bits. Sender sets this field to 15. Each
router MUST decrease it by 1. If hops reaches 0
before the datagram has reached it's
destination the datagram MUST be discarded.
Total length = 1 byte. Length of the entire datagram including
both header and data.
Destination address = 1 byte address of destination node.
Source address = 1 byte address of node who created the
datagram.
Protocol = 1 byte or 4 bits. Specifies the transport layer
protocol. That is, what kind of data is carried
in the datagram. For-instance TCP=6 and UDP=17.
See section "Protocols" for more info.
Flags / Padding = 1 byte. To get the datagram header 16 bit
aligned this padding byte is needed. It MAY be
used by the transport layer protocol (for
instance TCP) for flags or other data.
Flow = 1 byte. If we decide to add Quality of Service
to Micro-IP a flow byte is needed. The use of
this byte and QoS is discussed later on in this
document.
Checksum = 2 bytes. The checksum is OPTIONAL. If there is
no checksum the field MUST be set to 0. The
checksum is calculated on the entire datagram.
See section "Checksums" for more info.
5. Example network
Since this document is still very much "work in progress" the
addressing style to use in Micro-IP is not yet decided. Instead there
are two different suggestions. Suggestion B uses traditional
subnetting just like IPv4 does. (With one small difference: Default
gateways always respond to address 1 to make things slightly
simpler.) Suggestion A instead only uses ARP proxying. That means
nodes do not have to be subnet aware.
Suggested addressing scheme A (routers use ARP proxying):
Link to the Internet <--------+
| 185.15.7.2
| (185.15.7.12)
+-----+ +-----+ +--+--+
| | | | | | Internet
| 7 +------+ 5 | | 2 | proxy
| | | | | |
+-----+ +--+--+ +--+--+
| (7) |
| Micro-IP bus A |
---+-------+--------+------------------------+-------------
| |
| | (11,12)
| +--+--+ +--+--+ +--+--+ This node
| | | | | | | may be reachable
| | 10 | Router | 11 | | 12 | as 185.15.7.12
| | | | | | | from the
| +--+--+ +--+--+ +--+--+ Internet.
| |(2-9,20-22) | |
| | | Micro-IP bus B |
| ---+-----------------+------------------+----------
|
|
| (21,22)
+--+--+ +--+--+ +--+--+
| | | | | |
| 20 | Router | 21 | | 22 |
| | | | | |
+--+--+ +--+--+ +--+--+
| (2-19) | |
| | Micro-IP bus C |
---+------------------+--------------------+---------
Suggested addressing scheme B (similar to the traditional approach):
Link to the Internet <--------+
| 185.15.7.2
| (185.15.7.12)
+-----+ +-----+ +--+--+
| | | | | | Internet
| 7 +------+ | | | proxy
| | | 5 | | 2 |
+-----+ +--+--+ +--+--+
| (7) |
| Micro-IP bus A |
---+-------+--------+------------------------+-------------
| |
| | (1)
| +--+--+ +--+--+ +--+--+ This node
| | 9 | | | | | may be reachable
| | | Router | | | | as 185.15.7.12
| | 10 | | 11 | | 12 | from the
| +--+--+ +--+--+ +--+--+ Internet.
| | (1) | |
| | | Micro-IP bus B |
| ---+-----------------+------------------+----------
|
|
| (21,22)
+--+--+ +--+--+ +--+--+
| 8 | | | | |
| | Router | | | |
| 20 | | 21 | | 22 |
+--+--+ +--+--+ +--+--+
| (1) | |
| | Micro-IP bus C |
---+------------------+--------------------+---------
Note that the traditional approach (suggestion B) is much more
complicated. It means nodes need to be subnet aware. It also means
that routers sometimes have to use ICMP redirect to tell nodes where
to send IP datagrams. An example: Node 2 want to send a datagram to
node 22. Since node 22 is on another subnet node 2 will send the
datagram to node 9 which is the default gateway for node 2. Node 9
will forward the datagram to node 8 (since node 9 is a router it has
more knowledge). Node 9 will also send an ICMP redirect message to
to node 2 telling it that further datagrams to node 22 should be sent
to node 8 instead.
Suggestion A makes things much simpler. In this case node 2 does not
know about subnetting, instead it does an ARP request asking for
node 22. Since node 20 is the router that handles the datagrams for
node 22 node 20 answers the ARP request. Thus node 2 will send the
datagrams directly to node 20. This makes ICMP redirects obsolete.
6. Addressing
If we decide to use addressing scheme A:
A Micro-IP node responds to the same address on all it's devices.
Routers also responds on each device to all the addresses for which
it can forward datagrams to another subnet.
If we decide to use addressing scheme B:
A Micro-IP node responds with different addresses on each device.
Each such address should fit into the range of the subnet to which
the device is connected. Routers should also respond to address 1 on
any device connected to a subnet on which the router is default
gateway.
To make things simple this protocol uses several default addresses:
0 = Internal loopback address. MUST never appear outside a node,
except when a node is requesting information before it has
received an address. See section about "RARP, BOOTP and DHCP"
for more info.
1 = Default gateway. A node that is gateway on a subnet SHOULD
respond to it's own addresses on the respective devices. The
node SHOULD also respond to address 1 on the device that are
connected to the subnet.
NOTE! Address 1 is only necessary if we decide to use
traditional addressing (subnetting) instead of ARP proxying.
2 = Internet proxy. The node that is gateway/proxy/bridge to
the "real" Internet MUST respond to address 2.
3 = Reserved for future use.
4-254 = Normal node addresses.
255 = Broadcast.
Note that the default addresses MUST NOT be used for any other
purpose than specified here. For instance, if there is no Internet
proxy the address 2 should not exist on the network.
Broadcasts should normally be retransmitted to all subnets. But if a
router can handle the request that the broadcast contains the router
may skip the retransmission to other subnets.
7. Protocols
The protocol numbers used in the datagram header SHOULD be the ones
specified by IANA. See RFC 1700 "Assigned Numbers" in section
"Assigned Internet Protocol Numbers". Note that RFC 1700 now is
obsolete, to get the most recent information check www.iana.org.
If we decide to use the Micro-IP datagram header with only a 4 bit
protocol field we of-course have to use other protocol numbers.
Note that most protocols needs to be modified to behave well over
Micro-IP and to be resource efficient in embedded systems. Most of
all, each protocol must have a way to negotiate connections to the
Internet through the Internet proxy.
8. Checksums
The checksum in the Micro-IP datagram header should be calculated on
the entire datagram with the Hops and Checksum fields considered to
be zero. The checksum field is the 16 bit one's complement of the
one's complement sum of all 16 bit words in the datagram. That's the
same type of checksum used in most other Internet protocols. It is
a somewhat primitive checksum but it is fast, takes up very little
code space and has proven sufficient in most cases.
Checksum rules:
* A sender MAY add a checksum.
* A router MAY add a checksum if there is none.
* A router MAY check the checksum if there is one and discard the
datagram if it is erroneous.
* The receiver SHOULD check the checksum and ignore (discard) the
datagram if it is erroneous.
These rules allows nodes on error free networks to save processor
time by not calculating the checksum. Routers that is going to send
the datagrams on to networks that are not error free can then add
checksums to protect the datagrams. Thus demanding more of the
routers and less of the nodes. That's the right approach for embedded
systems.
9. Connecting Micro-IP to the Internet
Addressing in Micro-IP datagrams isn't compatible with bigger
IP-networks. Therefor connection between such networks can not be
done at the internet layer. Instead the networks has to be connected
at the transport or application layer.
There are at-least two ways to connect FROM a Micro-IP network TO a
bigger IP-network:
A) Application layer proxying. That is, the node that has connection
to both the Internet and the Micro-IP network has proxy
applications/software. Applications on the Micro-IP network
addresses the proxy-applications and requests/leaves data and the
proxy application in turn connects to the Internet and
requests/leaves data.
B) Transport layer proxying. That is, translation of data is done on
the transport layer. Similar to "socks-proxies". For-instance the
TCP protocol in the Micro-IP node connects to the Internet-proxy
and requests to be forwarded to a "real" Internet address. The
proxy opens a "real" TCP connection to the requested address and
then connects the two streams.
There are at-least three ways to connect FROM a bigger IP-network TO
a Micro-IP network:
A) Application layer proxying. As described above.
B) Port mapping (transport layer). For instance the Internet-Proxy
is set up in such a way that if it receives a TCP connection from
the Internet on a specific port the proxy in turn opens a
connection to a specific port on a specific Micro-IP node and
then connects the two streams.
C) Address mapping (involves both transport and internet layer).
This means that the Micro-IP one-byte address is interpreted as
the last byte of the "real" IP-address. The Internet-proxy acts
as a router but also does protocol conversion since most
protocols will differ slightly between Micro-IP and the "real"
Internet. This means that the embedded node on the Micro-IP
network can act as a full fledged server towards the Internet.
For the Micro-IP node this looks exactly the same as alternative
B, port mapping. It's only the proxy/router that needs to know
the difference. NOTE! Although address mapping is the neatest and
most compatible way to connect a node to the Internet this is
also the least secure way.
10. UDP for Micro-IP
The User Datagram Protocol provides an unreliable connectionless
delivery service. UDP uses port numbers to distinguish among multiple
services/programs running on the same node. UDP datagrams are
transported as data in IP datagrams.
To support connection to the Internet Micro-IP UDP can handle
"extended addressing information". Nodes that do not need to
communicate with the Internet do not need to support extended
addressing.
Internet applications that are Micro-IP aware should avoid sending
UDP messages larger than 200 bytes of data. 200 byte + 10 byte IP and
UDP headers = 45 bytes left for extended addressing information.
Because UDP datagrams that comes from the Internet may carry much
more than 200 bytes of data, Micro-IP UDP has a method to fragment
such messages and send them as several Micro-IP UDP datagrams. This
fragmenting capability is OPTIONAL since the fragmenting capability
uses too much memory for most embedded nodes.
Suggested UDP datagram format A:
8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 |Type | Counter |
+--+--+--+--+--+--+--+--+-----+-----------------+
| Source port | Destination port |
+-----------------------+-----------------------+
| data |
...
| (N bytes) |
+-----------------------------------------------+
Suggested UDP datagram format B:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Source port | Destination port |
+-----+-----------------+-----------------------+
|Type | Counter | |
+-----+-----------------+ |
| data |
...
| (N bytes) |
+-----------------------------------------------+
The UDP datagram header has several fields:
Destination port = 1 byte address that identifies the service that
should receive the datagram.
Source port = 1 byte address that identifies the sending
socket/thread.
Type + counter = 1 byte. (If the IP datagram has a Flags/Padding
field: This is the Flags/Padding field from the IP
datagram header.) This field is used to handle UDP
addressing to and from the Internet and to handle
UDP datagrams that exceeds the size Micro-IP can
handle.
The type field (two bits) tells what kind of UDP datagram it is. The
counter has different meaning depending on the type value.
Type values:
0 = Normal UDP datagram. The counter value has no meaning (should
be 0).
1 = Extended UDP datagram. The datagram holds extended addressing
information and may be fragmented. The counter value tells how
many fragments to expect (including the first). If this is the
only fragment then counter = 1.
2 = Succeeding fragment. Counter value tells which fragment this
is. First succeeding fragment should have counter = 1 and last
fragment should have counter = (number of fragments - 1).
10.1 Extended addressing information
If a node wants to send a UDP datagram to the Internet it sends the
UDP datagram to the Internet proxy. Since the datagram is not
intended for the Internet proxy the destination port number should
be set to 0. The real Internet address is put as the first bytes
in the data section followed by ASCII 13. Examples of valid
extended addressing information:
www.ietf.org:80[ASCII 13]
123.45.67.89.01:80[ASCII 13]
Note that the extended addressing information may only be one line
of data and that IP numbers should be written in decimal using
ASCII. Also note that the extended addressing information is only
added to the first fragment (the fragment of type 1) if it is a
fragmented datagram.
Incoming datagrams from the Internet works the same way. The
Internet proxy puts the source address (for instance
www.ietf.org:80) as extended address information in the UDP
datagram. Since the source port in the UDP datagram head has no
meaning the proxy may set it to 0. The Micro-IP node do not need
to understand the address information. The node simply copies the
information into the outgoing datagram when responding.
10.2 Sending big UDP messages locally
The fragmenting facility also makes it possible to send big UDP
messages between Micro-IP nodes. In that case there is no need for
extended addressing information. To indicate the lack of
addressing information an ASCII 13 should be put as the first byte
in the data area of the extended UDP datagram. Thus the receiving
node do not need to understand the lack of addressing information.
NOTE! A receiving node MUST always use the senders source port as
destination port when responding. It's wrong to assume that the
port should be 0 just because there are extended addressing
information. For instance in the case where the extended address
is empty (local message) the source port definitely has a meaning.
10.3 Error handling
If a node does not support extended addressing or fragmented UDP
datagrams there are two ways it may respond to datagrams with type
values different from 0. The node can either simply ignore the
datagrams or it may send ICMP error messages indicating that it
does not support the features. If the sending node understands the
ICMP error message it may stop sending succeeding
datagrams/fragments.
10.4 UDP Example
Below is an example of a complete IP datagram and UDP datagram. It
is the first datagram of a fragmented message to node 12, port
119. It is a response to a call to the IETF web site. (Note that
web calls aren't really done with UDP.)
Example field
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 values:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Version | Hops | Total length | 0, 15, 255
+-----------+-----------+-----------------------+
| Source address | Destination address | 2, 12
+-----------------------+-----------------------+
| Checksum | 0
+-----------------------+--+--+--+--+--+--+--+--+
| Protocol |Type | Counter | 17, 1, 40
+-----------------------+-----+-----------------+
| Source port | Destination port | 0, 119
+-----------------------+-----------------------+
| |
Extended address followed by ASCII 13 www.ietf.org:80
| (N bytes) | 13
+-----------------------------------------------+
| data | Content type:
... text/html
| (N bytes) |
+-----------------------------------------------+
11. TCP for Micro-IP
The Transmission Control Protocol provides a reliable
connection-oriented delivery service. TCP uses port numbers to
distinguish among multiple services/programs running on the same node
and to distinguish among different connections to/from the same node.
TCP segments are transported as data in IP datagrams.
The Micro-IP TCP is similar to the TCP used in IPv4. (See RFC 793
"Transmission Control Protocol".) But the Micro-IP TCP differs in
some ways:
* It does not support out of band data (urgent pointer).
* It uses two way handshakes instead of three way handshakes.
* It may use extended addressing information to support connections
to and from the Internet.
It is strongly RECOMMENDED that implementations of Micro-IP TCP
includes techniques to handle such things as congestion and silly
window. Congestion can occur in any network that consists of more
than one physical network.
Suggested TCP segment format A:
8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 | Flags / Padding |
+--+--+--+--+--+--+--+--+-----------------------+
| Source port | Destination port |
+-----------------------+-----------------------+
| Sequence number |
+-----------------------------------------------+
| ACK number |
+-----------------------------------------------+
| Window size |
+-----------------------------------------------+
| data |
...
| (N bytes) |
+-----------------------------------------------+
Suggested TCP segment format B:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Source port | Destination port |
+-----------------------+-----------------------+
| Sequence number |
+-----------------------------------------------+
| ACK number |
+-----------------------------------------------+
| Window size |
+-----------------------------------------------+
| Flags | |
+-----------------------+ |
| data |
...
| (N bytes) |
+-----------------------------------------------+
Suggested TCP segment format C:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Source port | Destination port |
+-----------------------+-----------------------+
| Sequence number |
+-----------------------------------------------+
| ACK number |
+-----------------------------------+-----------+
| Window size | Flags |
+-----------------------------------+-----------+
| data |
...
| (N bytes) |
+-----------------------------------------------+
The TCP segment header has several fields:
Destination port = 1 byte address that identifies the service that
should receive the segment.
Source port = 1 byte address that identifies the sending
socket/thread.
**** Not written yet ****
12. ICMP for Micro-IP
**** Not written yet ****
(The protocol should preferable be designed in such a way that ICMP
messages will not be necessary.)
13. ARP for Micro-IP
The Address Resolution Protocol ...
**** Not written yet ****
Note that Micro-IP runs ARP on the Internet layer instead of the
Network Interface layer. Thus Micro-IP ARP uses IP broadcast.
The reason we have chosen to move ARP one layer up compared to other
IP protocols is to become more independent of the network type and
to not unnecessarily use up addressing space in the local network.
Having ARP running on the Internet layer even makes it work well over
serial connections!
14. RARP, BOOTP and DHCP for Micro-IP
**** Not written yet ****
(When requesting "boot data" the source address has no meaning so it
should be set to 0.)
15. DNS for Micro-IP
**** Not written yet ****
(Micro-IP nodes should not need to bother about Internet addresses.
The "extended addressing" in the Micro-IP UDP and TCP takes care of
that most of the time. So DNS is mostly needed for local address
resolving.)
16. Micro-IP over serial links
When transporting Micro-IP datagrams over serial links we recommend
using PPP. (Point-to-Point Protocol, RFC 1661.) If there isn't room
enough for PPP and the serial link is reasonably error free we
recommend using SLIP. (Serial Line Internet Protocol, RFC 1055.) Most
serial links can be made sufficiently error free by using shielded
cables.
17. Fragmenting Micro-IP datagrams
Micro-IP does not support datagram fragmenting. Micro-IP expects that
a full sized datagram (255 bytes) reaches it's destination in one
piece.
When transporting Micro-IP datagrams over buses that can not handle
datagrams as big as 255 bytes we recommend using the basic parts of
the ISO 15765-2 protocol for fragmenting and reassembly of the
datagrams. ISO 15765-2 is commonly used over CAN-buses in both
vehicles and industrial machines. It is also the protocol used in
OSEK/COM. (CAN = Controller Area Network = A real-time bus that only
has 8 bytes of data in each frame. OSEK is an initiative to
standardise embedded real-time operating systems.)
Note that fragmented Micro-IP datagrams MUST be reassembled at the
next router.
ISO 15765-2 basically works as follows:
**** Not written yet ****
18. Quality of Service for Micro-IP
The author of this document do not believe that Micro-IP should have
support for QoS. It would make nodes and routers far to complex for
embedded systems. But should "the general audience" demand QoS for
Micro-IP a flow byte needs to be added to the Micro-IP datagram
header. How the flow byte should be used will be specified if we
decide to add QoS.
19. Security considerations
**** Not written yet ****
20. Some comments
The use of "extended addressing" makes it possible to connect
Micro-IP networks to just about any network, be it IPv4, IPv6 or
something totally different. It is even possible to connect several
Micro-IP networks to the same proxy thus allowing much more than 251
nodes in Micro-IP networks.
21. References
[1] Malkin, G., Editor, "Internet Users' Glossary", FYI 18,
RFC 1983, August 1996
[2] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] Reynolds, J., "Assigned Numbers", STD 2, RFC 1700, October 1994
[4] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA,
September 1981
[5] Postel, J., Editor, "Transmission Control Protocol", STD 7,
RFC 793, September 1981
[6] Romkey, J.L., "Non-standard for transmission of IP datagrams
over serial lines: SLIP", STD 47, RFC 1055, June 1988
[7] Simpson W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994
[8] International Organization for Standardization, "Road vehicles
-- Diagnostics on Controller Area Networks (CAN) -- Part 2:
Network layer services", ISO/DIS 15765-2, (work in progress)
22. Authors' addresses
Micro-IP web site: www.micro-ip.org
To join the Micro-IP mailing list, send an email to:
micro-ip-subscribe@egroups.com
David Gothberg
Studiegangen 7-208
SE-416 81 Gothenburg
SWEDEN
Phone, home: +46-31-459856
Phone, work: +46-31-7033252
Email: david@gothberg.com
http://hem.passagen.se/davidgot/
23. Full copyright statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document expires March 2001.
