Operating Environments and the Application Layer

The local operating system (or the network operating system) might have its own layered components that assist with providing users with access to the network. These components typically function above the TCP and UDP ports and are thus within the province of the Application layer.

All modern operating systems have built-in features that integrate the computer with resources on the network. One of the goals of these types of services is to hide the functioning of the network protocol stack by providing shortcuts from the local system to resources on the network. In some cases, the separation disappears completely, and the user browses the network as though it were part of the local computer. Behind the scenes, however, services at the Application layer are sending and receiving information through the network protocol stack. For instance, the Explorer feature of the Windows operating system is actually an application called explorer.exe that communicates with the network through an API (as shown in Figure 7.4). When you access a remote share or a mapped drive through Explorer, the operating system calls upon several of the services described in this chapter, including a redirector, a name resolution service, and a file service.

In Unix and Linux systems, services such as Network File System (NFS) provide files services, and other client/server components, such as the X Window graphics environment, operate at the Application layer to integrate the user with the network.

Sometimes the services residing at the Application layer do not represent a specific component or application, but are instead a separate protocol stack providing continuity with a dissimilar environment. For instance, a few years ago, Novell NetWare was the most popular LAN networking system in the world. Novell had already developed its own protocol suite (called IPX/SPX) before TCP/IP began its rise to prominence. IPX/SPX is a full-featured protocol system with its own error control and logical addressing. With the recent upsurge of interest in TCP/IP, developers and systems engineers started to wonder if it would be possible to integrate IPX/SPX networks with TCP/IP without disturbing the NetWare-related upper layers of the IPX/SPX stack.

An interesting solution emerged, known as IPX tunneling. IPX tunneling is defined in RFC 1234, "Tunneling IPX Traffic Through IP Networks."

In IPX tunneling, the IPX/SPX stack is grafted onto the UDP protocol of the TCP/IP stack (see Figure 7.5). The IPX protocol layer performs logical addressing functions similar to IP for the Novell network. Data passes down from IPX to UDP (see Hour 6), where it enters the TCP/IP stack and is encoded in an IP datagram, and delivered to the physical network.

Figure 7.5. An IP stack supporting IPX.

IPX tunneling and solutions similar to it produce a sort of hybrid protocol stack that is not easily described with the four-layer TCP/IP model. It is perhaps a matter of opinion whether the IPX superstructure riding above the Transport layer qualifies as an Application layer component, and most experts would describe this situation as upper-layer IPX/SPX protocols resting on the IPX/SPX Network layer, resting on TCP/IP's Transport layer. However, this IPX component supports applications at the top and links to the UDP ports beneath, so if it is included anywhere in this discussion of TCP/IP layering, the Application layer is an appropriate place to mention it. The fact that IPX tunneling is even possible is a tribute to TCP/IP's flexibility and versatility.

By the Way

Like the rest of the computer industry, Novell is well aware of the emergence of TCP/IP as the dominant routable protocol. Recent versions of NetWare have increased NetWare's support for TCP/IP, which is now the primary NetWare networking protocol (beginning with NetWare 5). Hybrid solutions such as IPX tunneling therefore are less important, but will continue to exist as long as IPX/SPX networks remain in the world.