INTERNET-DRAFT D. Gothberg Category: Experimental Computer Club West 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.