If your embedded system is on a network, the key question is: what subset of TCP/IP will you include in your product?
TCP/IP is the name given to a large collection of related networking protocols. It would be unusual in an embedded application to use all of these protocols at once. So the real question is: what subset of TCP/IP will you include in your product, if any?
It's now been more than five years since I developed my very first internet appliance. Of course, it wasn't really an appliance in the consumer understanding of that word. But it was the first time that anyone at my company had attempted to use the TCP/IP suite of protocols to connect proprietary equipment.
The product in question was a piece of telecommunications equipment designed to connect remote land-based telephone networks via satellite. One or more of these satellite gateways would be attached to each land-based network, thereby allowing telephone calls from one network to the other to be routed through a satellite channel.
None of the TCP/IP protocols was required to communicate with the satellite, nor were any of them required to communicate with the land-based telephone network. Therefore, we really could've used just about any protocol we wanted for communication between the internal subsystems of our product. We chose a subset of TCP/IP.
Why TCP/IP?
With literally hundreds of internally and externally developed communications protocols to choose from, we had no compelling reason to choose TCP/IP. This was 1995 after all, and the Internet was just beginning to take hold outside of universities and the Department of Defense; the World Wide Web was still in its infancy; and a war between Ethernet and Token Ring was raging fiercely. If I'd been a stock market investor back then, I probably would've bet all my savings on a networking company called Novell. (Thankfully, I didn't have any money to invest at the time.)
What we needed on that project was a way to connect one or more of these satellite gateways to a local PC-based monitoring and control station. (Take a look at Figure 1 to get a feel for the overall context.) Most PCs were not on networks then and Windows 3.1, the dominant PC operating system, had only limited TCP/IP support-in the form of the Winsock add-on. But this was still far better than the PC support for proprietary network protocols. So we decided to use TCP/IP for the communication between the subsystems of our own product (specifically, the satellite gateway and the PC).
Figure 1. Satellite gateways in context
The point was not to put our product onto the Internet (with a capital 'I') or even the customer's corporate intranet. In fact, the Ethernet cabling connecting our satellite gateways and PC-based monitoring station was going to be restricted to that purpose. The customer wouldn't necessarily even know what protocols were involved. So it really didn't matter what protocols we chose, so long as they did the job and did it well.
Embedding TCP/IP
Back then, independent embedded TCP/IP stack vendors didn't exist like they do today. We were familiar with a couple of RTOSes that included TCP/IP stacks (yes, VxWorks, LynxOS, and others included TCP/IP that far back), but the RTOS we'd selected did not. Our RTOS was just a small kernel that didn't include any kind of networking support at all.
Our options were, therefore, quite limited. We could either port the BSD TCP/IP stack ("free" source code from the University of California at Berkeley that formed the basis of most TCP/IP implementations at the time) or write our own. A preliminary estimate of the work involved in porting BSD revealed that the source code (and resulting executable) was huge and would not be easily reduced to just the subset we needed or ported to our kernel.
We really only needed a narrow subset of the full TCP/IP suite, so we decided to develop our own more limited protocol stack from scratch. In fact, what we needed wasn't a TCP/IP stack at all. What we really needed for this particular application was a UDP/IP stack.
Figure 2 shows the interrelationships between the member protocols and applications in a typical TCP/IP stack. As you can see from the figure, UDP and TCP are "peer" protocols (ICMP and IGMP are also their peers), in the sense that they are at the same protocol level. The vast majority of application programs and higher-layer protocols depend on either UDP or TCP, but not both.
Figure 2. The interrelationship of the TCP/IP protocols and applications
You see, communications between our satellite gateway and PC-based monitoring and control station was pretty simple. The list of communication requirements was limited to the following:
- Each satellite gateway needed to be individually addressable by the PC
- At boot-time, each satellite gateway needed to determine the address of the local PC and receive a set of boot parameters
- At boot-time, each satellite gateway needed to be able to download new firmware, if any, from the PC and store it into local flash memory
- During normal operation, each satellite gateway needed to send its operating statistics and various event reports to the PC
This list of required communications functions maps nicely to UDP/IP, ARP, BOOTP, and TFTP. In other words, all of these demands could be met by a UDP/IP-only protocol stack augmented with ARP support and BOOTP and TFTP application software. So that's what I set out to develop.
Road Map
Figure 3 shows the relationship between the various protocols we chose to implement. The "network interface" at the bottom was Ethernet, but it's possible to use SLIP or PPP in its place. TFTP and BOOTP, at the top of the stack, are the application layer programs. Both are client applications that communicate with server counterparts hosted on a remote system.
Figure 3. A smaller UDP/IP-only protocol stack
Between the network interface and the client applications are the protocol layers, IP and UDP. UDP is a much simpler protocol to understand and use than its transport layer peer TCP. UDP provides only for the "connectionless" exchange of information between two devices on the network. Since there is no "connection" to track and maintain and there is no guarantee of successful communication, the UDP protocol is stateless.
The implementation of the IP protocol layer, on the other hand, can get complicated very quickly. The more features you add the more you need to research and understand the best implementation techniques invented. But it's possible to exclude several IP features found in a general-purpose IP implementation.
Even SNMP, a far more complicated client-server application than either BOOTP or TFTP, requires only a UDP/IP stack. Unlike HTTP, it is not built upon the "connection-oriented" communications embodied by TCP.
This article began as a column in the April 2000 issue of Embedded Systems Programming. If you wish to cite the article in your own work, you may find the following MLA-style information helpful:
Barr, Michael. "TCP/IP or Not TCP/IP?," Embedded Systems Programming, April 2000 , pp. 49-52.
Related Barr Group Courses:
Embedded Linux Customization and Driver Development
For a full list of Barr Group courses, go to our Course Catalog.
