The Open System Interconnect (OSI) network model, referred to by many as simply a stack, is in fact a well-designed, layered architecture for efficient intersystem and intrasystem communications. In this two-part series, we provide a new view of the stack, showing how the layers are interconnected, and protocol services available at each level.
In Part 1 of this article, we provided an overview of the stack and delved into details on Layers 5 to 7, general concepts of abstraction, syntax, translation, programming interfaces, and functions associated with the model. Now, we'll further the discussion by looking at Layers 1 to 4 as well as at some non-layer layer items that are important for designers. Let's start our discussion by looking at Layer 4.
Layer 4: The Transport Layer
As mentioned in Part 1 of this article, Layer 4 is the transport layer in the OSI model. For many people, Layer 4 is the workhorse of the stack, and the part that most people think of first when they consider networking operations.
In Layer 4, the two most common transport mechanisms are the transmission control protocol (TCP) and user datagram protocol (UDP). They differ in the mechanisms used, and in particular, whether or not 'transport' of the particular data is guaranteed or not.
TCP includes control functions and fields that assist the stack to assure data delivery from one system to the next, including automatic retransmission of packets that get garbled or lost along the way. UDP, on the other hand, is a simple datagram protocol that does not, by itself, assure that any given piece of data will actually arrive at the destination. Only a 'best effort' is made. The advantage is greater speed. The disadvantage is that the application programmer is responsible for data integrity over the network.
Both TCP and UDP are so well known and so widely documented, this article won't go into much more detail. However, for those building embedded networking devices, you may want to refer to an upcoming White Paper from Arcturus, on packet travel through the Linux system as it pertains to embedded devices (i.e., taking into account things like DMA operations, cache considerations, etc.)
In addition, some sophisticated networking products use packet-processors, which can assist with efficient handling of data across layers, typically up to the TCP/UDP level (Layer 4). For example, a packet processor may know about TCP header formats and can provide efficient checksum procedures based on that knowledge. For devices such as routers this is important, because as the packet traverses the system (received from one machine, and sent to another), fields in the header (such as the time to live (TTL) variable), must be modified (here, decremented). Devices such as VPNs, which have encrypted or authenticated packet headers, can be even more demanding.
Do not confuse a packet processor (which is designed to have some 'knowledge' about the contents of headers and packets), with hardware designed to accelerate other common networking operations, such as encryption/decryption. However, some companies are designing or already building complex packet processors that include encryption support.
Layer 3: The Network Layer
At Layer 3, designers find a variety of protocols, many (or most) of which involve data transport over IP. The IP layer is one of the fuzzier areas in most implementations; sometimes, mainly in the interest of efficiency, the IP functions involve a fair amount of interaction with and support for other Layer 3 functions, and to lower stack layers.
For the purposes of this article, let's artificially separate the functions into two halves: the upper half includes ICMP (often associated with pinging), routing control (esp, bsp, ospf, rip-1 and rip-2), and automatic IP address assignment (dhcp). The lower-half functions include IP, IP secure (IPSec), filtering tools, and the all-important network address translation functions (NAT) commonly used by router/gateways.
Configuration is an issue for most layers within the OSI stack, but at Layer 3, we see some interesting configuration mixes. For example, in one configuration a device will hand out IP addresses to other systems while maintaining its own IP address. In the case of static IP addresses, the user often defines the network address when the system is setup for the first time, or reconfigured at a later time. The address can also be changed via mechanisms such as SNMP (a Layer 7 process), or the address, netmask, and other settings might be handed out by another system (in other words, if the system is a DHCP client). In the case of a DHCP client, the address might change frequently, if the 'lease time' is short. Each time the address changes, various portions of the rest of the IP subsystem must be informed of those changes.
If the system also acts a DHCP server, it can hand out addresses to other attached computers. While the approach is relatively straightforward, it can have implications for other components at Layer 3, especially some of the routing protocols such as the routing information protocol (RIP) or open shortest path first (OSPF) protocol. In those situations, being a DHCP client or server can have effects that ripple through the remainder of the stack.
Dealing with TCP/IP
One of the most common networking terms bandied about is TCP/IP, which is certainly considered the heart of most if not all modern network devices. From the perspective of the seven-layer OSI model, the functions associated with TCP and IP reside at two very different levels in the stack model. TCP, being concerned with data transmission (as is UDP) is a Layer 4 protocol. Layer 3, on the other hand, provides just the IP pieces of the combined subsystem.
But again, OSI provides great flexibility. Currently, most systems use IPv4 in the familiar dotted notation such as 192.168.0.1. On the other hand, IPv6 uses 8-part, 16 bits per part (128-bit total) addresses in colon format such as 1080:0:0:0:8:800:0:0. Yet IPv4 and IPv6, which are very different in formulation and implementation, can each still carry TCP data on top, with impunity. Nobody writes about TCP/IPv4 and TCP/IPv6, because it is not necessary to come up with two systems to solve one problem—that is, the encapsulation of very different forms of network addressing (and related concerns) vs. the data that they carry. This is possible exactly because of the separation inherent in the OSI model.
There is an interesting thing about IPv6 worth noting here. This article has talked about wrappering functions from one layer via functions in an adjacent layer. This is fairly common. Less common is to have layer-local wrappers, but IPv6 does exactly that, by providing a way to send IPv4 material over an IPv6 connection. Thus to take advantage of IPv6, designers do not need to rewrite the network, session, presentation, and application layers above. Layer abstraction makes this possible and relatively easy.
Layer 2: The Data Link Layer
At Layer 2, known as the data link layer, we again have functions that can be thought of as upper- and lower-half functions, along with stand-alone discovery protocols such as address resolution protocol (ARP) and reverse ARP (RARP).
Lower-half functions can be considered to include point-to-point protocol (PPP), which is commonly used with modems. Upper-half functions include wrapper protocols such as PPPoE. A wrapper protocol takes one protocol, here PPP, and encapsulates it within another protocol (here, Ethernet), thus sending PPP data over Ethernet (PPPoE). Obviously, the other system involved in the communication must perform the appropriate inverse functions as necessary.
There are also a number of control functions associated with data links in general. Fortunately, the link control protocol (LCP) has been developed to simplify access to those control functions. You can find details on a number of web sites.
Layer 1: The Physical Layer
The physical components at Layer 1 can also be considered as stratified into sub-layers that are responsible for functions associated with a particular hardware architecture (such as 802.3 networking hardware), and particular underlying hardware connection methods such as Ethernet, cable modem, wireless (WiFi), and DSL. The interface functions from Layer 2 to Layer 1 are easily thought of in the same terms as the layer-to-layer API of the other OSI levels. However, the hardware side of things changes extensively for each, and you're best off separately examining the standards documents for any particular interface.
Non-Model Connections
Despite the power inherent in the OSI model, it doesn't apply to all situations. Serial protocols are an interesting example, especially as they apply to modems (the various V.xx serial protocols, which define varying levels of hardware capability, and the signaling methods associated with those protocols. In addition, wrapper protocols that might interact with modems have already been described). Other common mechanisms include direct connections such as RS-232 (the common 'COM' port), RS-485 ('multi-drop'), and a wide variety of synchronous serial protocols (SDLC, HDLC, and many others). RS-232 and RS-485 are often used for console port connections, to or from modems, or sometimes via a direct ('wire line') connection.
Before the widespread adoption of the OSI model, it was not uncommon for people to use a variety of other packaging protocols, such as X-modem, Y-modem, and Z-modem, to transfer files or blocks of data. That's less common now.
X-modem is considered the original protocol of this type. This protocol defined a way to send large amounts of data by breaking it into 1-kbyte blocks. Mechanisms were also included to assure data delivery and retry any failed operations.
Y-modem and Z-modem represent improvements on X-modem, using larger blocks sizes (and thus relatively less overhead), as well as changed mechanisms for verifying the receipt (or not) of data from one machine to the other. These protocols, while still used in many situations, have basically been supplanted by IP protocol, due to the greater flexibility of IP, and the ability to send IP data over virtually any kind of underlying link (including serial ports, when necessary).
Another unique, but important special case for designers to consider, involves network-ready bootloaders. These programs often include just enough intelligence to configure a given hardware network interface (such as Ethernet), usually with some kind of address defaults, and then the package might implement a standard transfer protocol on top of that hardware; usually, this is done through brute implementation and not by a layered model approach. Common examples are bootp or tftp; both are used to pickup an operating image from a remote computer. This saves disk or flash memory space, provides an easy way to upgrade systems (only one image need be updated, and each attached system will use that new image at the next reboot), and yet it is still possible to allow remote clients to default to using an existing image if desired (or necessary, in case the network is down).
Wrap Up
That wraps up our two-part look at the OSI model. Remember that some systems pre-date OSI but use many of the same concepts; however, there may be slight differences in interpretation, placement or interaction as a result. To view Part 1 of this article, click here.
About the Author
John Drabik is the CTO for Arcturus Networks Inc. He is the former VP and CTO for Digital Media at Lineo as well as the former chief engineer and architect of Lineo's DTV and RG stacks. John is also the former technical chair of TV Linux Alliance. John can be reached at jdrabik@arcturusnetworks.com.
