Name RTLinux UDP/IP Description Hard real-time IP/DUP stack implementation. Author/s Miguel Masmano Reviewer Ismael Ripoll Layer High level RTLinux. Version 0.1 Status Testing Dependencies None. Release Date M3

Currently, standard RTLinux/GPL has two different IP stacks: RTSOCK and LwIP (LwIP was ported to RTLinux by a college from the UPVLC, in a project sopported by the national reseach department, MCYT). Rtsock is not a device driver for network cards. Instead, packets flow through the Linux kernel using the standard Linux drivers, up/down the standard layer 2 and layer 3 protocols, and then packets are diverted into an RTLinux task. Currently only UDP sockets are supported. LwIP is a complete and full featured TCP/IP stack designed to be ported to embedded systems easily. The current version of RTLinux provides support of a small number of network card drivers. This component is an implementation of the UDP/IP stack from scratch (not derived from BSD code as many other TCP/UDP/IP implementations). The main design criteria is efficiency, while features and compatibility are secondary. The stack will be prepared (interfaced) to work with the network device drivers developed in the project EtherBoot, which has a large base of supported drivers; and also be connected with the Linux networking stack (via a virtual network driver), providing a high level communication mechanism between RTLinux and Linux on the same machine. Next figure outlines the internal structure of the proposed component: the core of the component is the UDP/IP stack, which provides the socket interface to RTLinux threads; the component will implement the required API to use all the EtherBoot project network device drivers; and finally, a standard Linux network driver will be provided so that Linux user application can communicate via UDP/IP with RTLinux threads.

This is a Low Level RTLinux component. It also interacts with the Linux Kernel by means of a virtual network Linux driver since it allows to send ARP/IP packets via the kernel TCP/IP stack.

Standard BSD socket API: send() and sendto() for sending messages; recv() and receivefrom() to receive messages; and connect() to establish the connection. The Stack will be compatible with all the EtherBoot network drivers.

RTLUDP do not have dependencies with any external components.

Alpha status

RTLUDP implements a light UDP stack with the following functionality: ARP protocol: Complete. The RTLUDP component implements the ARP protocol as is described in the RFC 826, titled "Ethernet Address Resolution Protocol". Besides the ARP protocol, RTLUDP implements a little software cache for storing Ethernet address and its IP address translation. All IP address are translated using this cache table. If an IP address is not located in the table, RTLUDP sends an ARP request only when the appropiate translation is not in the table. Since the ARP protocol is not an inherence real-time protocol, RTLUDP provides two non-standard functions: insert_arp_translation() and flush_arp_table(). The first one allows user to insert into the arp cache table translations during the initialisation time and the last one allows to empty the whole arp cache table. The use of the ARP protocol can be avoided if the physical medium used is a point-to-point medium. IP protocol: Complete. But packet split and recombine are not supported. Even using a deterministic physical medium, some IP protocol features, like the packet split, do not allow any kind of deterministic response time. Therefore in this implementation these non-deterministic features have been avoided. This IP protocol does not implement routing. UDP protocol: Complete. Avoiding the ARP protocol, since it can be statically initialised and supposing the previous described IP protocol, this UDP protocol can be considered a real-time protocol. RTLUDP only has made one simplification of this protocol: it does not calculate the UDP header checksum. However this is not an important simplification because it is covered by the RFC 768. The sockets abstraction has not any kind of simplification, allowing user to use any socket from 0 to 65535. RTLUDP does not reserve any port, from 0 to 1024, as conventionally done. ICMP protocol: Only some parts have been implemented like ECHO, DESTINATION UNREACHABLE, etc. Packages related with host or router information and management will not be implemented. This protocol has been implemented for debbuging porpouses so more error messages are not interesting. An extensive list of implemented error messages are: ICMP_ECHO_REQUEST: This is a very useful message because it can be used for checking the sending and also the reception of IP messages, since it guarantees the reception of other hosts ECHO_REPLY messages. ICMP_ECHO_REPLY: This message is used to response requests from other hosts. It has no sense to implement previous ECHO_REQUEST message without implementing this one. DESTINATION_UNREACHABLE: This message allows to indicate that a package can not arrive to the specified destination. TCP protocol: TCP protocol has not been implemeted since it is not a real-time protocol. The RTLUDP componen has been designed in two well-differenciated layer: the light UDP stack layer, previously described, and the hardware layer, which implements the drivers. RTLUDP supplies an interface layer, called hardware abstraction layer (HAL), for allowing the interaction between the UDP stack and drivers. HAL has been designed keeping in mind two important details: It has to be as simple as possible, because making drivers must be an easy work. It must be compatible with the existing EtherBoot HAL, to allow to port easily existing EtherBoot drivers. This HAL has been designed to be simple and also EtherBoot drivers compatible, thus with EtherBoot drivers can be used directly by the RTLUDP component. Any implemented driver must satisfay the next interface: poll(): This function has to return "1" when a new package has arrived and "0" otherwhise. reset(): This function will be used by the stack to reset the physical device. transmit(): This function will be always called whenever some protocol wants to send a package. disable(): This function will be used by the stack to disable the physical device. node_addr: This is an optional variable which is used on the case that the physical device had an MAC address like for example the Ethernet protocol. On the case there exist a MAC address, it has to be initialised by the driver itself. packet: When the poll() function returns "1" means that a new packet has arrived so packet will contain the new packet. packet_len: When the poll () function returns "1" means that a new packet has arrived so the packet variable will contain the new packet length. Another important feature of the RTLUDP component is that it accepts dynamic insertion and extraction of the drivers, showing available drivers in the /proc/rtl_udp file. Implementing drivers is a tedious task, so one solution is to use other project drivers, EtherBoot drivers have been choosen because it has drivers for almost all existing Ethernet cards. Due to the HAL interface is very similar to the EtherBoot drivers, in fact, it is the same. EtherBoot drivers can be used with only replacing its time functions with RTLinux time functions. This replacing is done because existing EtherBoot time functions use directly the hardware PIT, reprogramming it. Besides the EtherBoot network driver, a new virtual Linux network driver has been implemented. This new driver allows direct network communication between the RTLUDP stack and the Linux Kernel TCP/IP stack, and it also allows to send packages through the Linux Kernel stack. Although the first version of RTLUDP stack has been implemented using a one copy method, we will study the way to provide a real zero copy network on following versions (may be using the STREAMS interface).

The validation criteria are: A Real Time behaviour, when the real-time protocol is used, must be achieved, being this point the main goal of the RTLUDP. RTLUDP stack must be completely compatible with existing UDP/IP protocol.

As is described in the Validation criteria, there are two important features to check in this component: the deterministic behaviour and the compatibility with existing protocols. There is no problem in testing the second feature, however, currently the real-time behaviour can not be tested because we have not any real-time physical device to use. Following four tests check ARP and ICMP compatibility: Test 1: The first test is a simple test with the ping utility. Using the virtual Linux kernel network driver, the ping utility sends several ICMP ECHO_REQUEST packets, and the RTLUDP component answers with the appropiate ICMP ECHO_REPLY package. Test 2: This test is similar to the previous one but this time the ICMP ECHO_REQUEST package is sent by the RTLUDP component. Test 3: This test checks as well as the ARP and ICMP protocol, it checks EtherBoot drivers. Using a different computer connected through ETHERNET without computer, it consists of sending several ICMP ECHO_REQUEST using the ping utility and waiting a correct answer. Test 4: This test is the same that the test 3 but this time the ICMP ECHO_REQUEST package is sent by the RTLUDP component. EtherBoot Drivers has the same well-behavior as the Virtual Linux Kernel network driver so for following will be executed using first EtherBoot drivers and later the Virtual one. The following tests check the ARP and IP/UDP compatibility, (Only UDP compatibility can be tested since in the current version raw IP packages have not been implemented): Test 5: UDP sending and receiving compatibility. This test has been designed to prove UDP sending compatibilities with a standard TCP/IP stack. The test sends several packages, from several ports, to one open Linux port, and waits confirmation. Test 6: Previous tests have check if the implemented UDP sends and receives correctly packages with open ports, tests 6 checks the same but with close ports. This test checks what it happens when nobody waits a package. A Linux application sends several packages to RTLUDP closed ports and waits a response. Test 7: Stress test. In this test, several external applications send packages through different physical mediums to the RTLUDP, trying to get a stack overload, measuring the number of lost packages, times, and so on.