The real key to OSI is not the details of functions at each layer, but rather an understanding of why the layers have been separated as they have been; those layers represent sets of consistent concepts and functions related to data handling. The various layers treat data very differently (different interpretations). This is a bit broad, but generally, they are:

• Layer 7—Semantics of data (what does it mean)
• Layer 6—Syntax of data (exactly what does it say)
• Layer 5—Controls access to data ('sessions')
• Layer 4—Transport data to/from other systems
• Layer 3—Network (topology)
• Layer 2—Linking systems (including wrapping one protocol in another)
• Layer 1—Physical (interface to wires, or whatever)

As you read the following sections, it is important to differentiate between network-oriented functions, and those associated with a GUI or other user interface. For example, within this article, there will be discussion of things like web servers at Layer 7. Although Layer 7 is called the "application" layer, it does not necessarily mean that there will be an application program in the GUI sense of the word.

Indeed some programs, such as Internet key exchange (IKE) are best thought of as application-layer programs that affect lower levels in the stack (for example, changing the encryption policies using agreed-upon security associations between two secure networks). Here, I'm referring to network applications, and when you look at it that way, things like IKE, web servers, and other application programs rise naturally to the top of the stack.

For each layer, one or more "typical" programs will be listed, and in some cases, the nature of their operation will be described. Given the magnitude of the task and the great variability in both applications and implementations, this will be a brief overview. Nevertheless, it should be adequate to demonstrate the operation of stack components.

Layer 7: The Application Layer
Layer 7 in the OSI stack defines applications such as ping, telnet, ssh, ftp, http, https, tftp, snmp, and ike. Distinguishing features of a Layer 7 application are that they often have a direct interaction with the user, and encapsulate a high-level protocol. There are exceptions (such as IKE and SNMP), but in general the applications and protocols associated with this layer also have a user interface.

For example, the FTP protocol is usually encapsulated into a program of the same name; the same is true for telnet. For others, such as ping, the program generates one or more packet 'connections' (sockets) over a specified protocol (for ping, it's ICMP). Some services, such as http and https, are usually delivered to other systems (though they are certainly accessible from the local system too), and often involve complex programs (such as Apache) that in turn act as a front-end to a variety of services.

Layer 6: The Presentation Layer
Layer 6 is the presentation layer and its applications are typically fewer in number. One excellent example of a Layer 6 application, however, is the network file system (NFS). Another key application is ftpfs, which treats the files on a remote FTP site as if they are conventional files—you can read and write to them, copy them, etc.

Operations at Layer 6 are sometimes referred to as "connection-oriented". For NFS, this is a pure presentation function: a remote filesystem is attached or made visible (in Unix/Linux, one would say mounted) so that it can be used by the local system. As a result, remote file operations are virtually indistinguishable from those used when accessing a local filesystem.

All of the typical file functions—open, close, read, write—behave in the same way. Under the covers, the requests are translated to remote file accesses, with all the intermediate networking issues hidden from the programmer or user. Even though distinctive Layer 6 components are relatively rare, Layer 6 is involved in the transition from any Layer 7 application to the underlying layers, and provides abstraction for the layers below.

Despite the rather rare obvious contents at Layer 6, this layer is the first one that offers connector functions to both a layer above and a layer below. Let's use this feature to discuss some of the interactions between layers.

NFS will be used as a very broad example of a Layer 6 function. NFS introduces the concept that some functions which one might consider internal to the local machine, might actually involve complex interactions with a remote machine. Consider copying a file. First, the file-open (fopen()) must be converted to a form that is sent to the remote server, which then opens the file and returns the status. Next, the data must be sent in packets. Finally, the remote file must be closed. The user does nothing special—they simply copy the file between two "entities"" (mount points in Linux, "disk drives" in DOS, etc.) and NFS takes care of the rest. The application program (copy) wasn't modified to include a network-ready version. Compare this to some old operating systems that had one set of commands for local functions and another for remote (but similar) functions, and the value of OSI becomes clearer.

In some cases, it might be necessary to translate the name, depending on the local and/or remote system. As an example, most FTP servers are based on Linux or Unix, yet if the local machine is running DOS or Windows, the NFS client and server take care of syntactic and semantic differences in the file names (such as converting \ to /, getting rid of : marks (or adding them back), etc.. Another name often associated with such things is application and control service elements (ACSE). If you decide to look into that further (I won't here), you may want to examine the related XAP services protocol.

A function such as NFS requires a connection to something besides the surrounding stack layers. In this case, it's a remote NFS server. NFS links with the server by establishing a connection. It then runs through a series of negotiations to verify that both machines agree on a variety of points, which include the abstraction of system-specific issues. This abstract syntax, along with things like the protocols to use, and the encoding/decoding mechanisms to be used, are hidden to the user or even the programmer of a participating application.

Layer 6 assures that that is possible by hiding all of the messy details via appropriate translation routines. In other words, Layer 6 is only interested in the syntax of the data (not the semantics), and the methods needed to send and receive data using that syntax.

The results of the remote operations are handed up to Layer 7, where they are interpreted and used. At the same time, NFS doesn't just bypass the rest of the stack with it's own custom communication routines. Instead, it relies on connection-oriented functions of the Session Layer (Layer 5), via an agreed-upon protocol. Those functions are used to establish the link, perform the negotiation, interpret and execute commands, and receive status. Layer 5 (or a lower layer) may, in turn, perform a few tricks of its own -- the VPN example was given earlier -- and NFS does not have to be modified to take that into account.

Making Assumptions at Layer 6
Layer 6 has to make some assumptions in order to perform its task. The first is that a route exists to the other machine. The second is that all underlying functions needed to establish that connection are available in the lower layers. If they are not, Layer 6 does not attempt to fix things by itself; it simply fails, with varying degrees of warning (for example, if you are trying to mount a remote drive, you may or may not get a timeout warning. But unless you use some of the controls (switches) available when invoking the NFS mount to that remote machine, if you lose your network connection, it can hang your machine.)

Thus Layer 6 actually provides services to Layer 7 (applications). Those services include:

• Identifying the available transfer syntaxes
• Selecting an appropriate transfer syntax
• Associating the transfer syntax to an abstract syntax
• Translation services (to 'hide' the other machine differences)
• Access to the Session Layer services as appropriate

The methods used to establish the remote connection are beyond the scope of this article (entire books have been written on the subject), but Layer 6 does rely on several broad types of functions and items:

• An abstract syntax that describes the types of data that can be exchanged, and their structure. You can read more about these in books on ASN.1 and related issues.
• A concrete syntax that defines the data representations for the local system.
• Transfer syntax (how to exchange data between the system, via Layer 5 on each machine.
• Encoding rules to actually transfer the data.

Despite all of this complexity, applications above Layer 6 don't see much difference compared to a local filesystem. For example, they are not aware that the filesystem hiding under NFS might be radically different from the current machine, and located on a machine thousands of miles away. The application sees only the typical Layer 7 to Layer 6 interface functions. Within Layer 6, the fact that the other machine is remote is hidden by using network and session services available just below, at Layer 5.

Based on this description of NFS, designers can see that there is an API that defines the services available at a layer (such as APIs that describe the functions at Layer 6 which can be reached from Layer 7 above it). These APIs are formalized into standards; in the case of Layer 6 it's IEEE STD 1351-1994. You can find specific documentation for STD 1351-1994 at www.ieee.org. In general terms, the standards document will describe exactly the points we've already raised: datatypes, permitted operations, client-supplied primitives, and even things like error codes. Primitives for this layer include things like presentation primitives, data transfer operations, dialog controls, and attribute relationships. It can get complicated, but not excessively, and it's a lot better than constantly reinventing the same functions over and over.

Layer 5: The Session Layer
Layer 5 is the session layer and its functions include services such as domain name services (DNS) and remote procedure calls (rpc). Each such function involves a session, which may in turn support one or more presentation spaces above it, and one or more applications above that.

RPC is an interesting example of a Layer 5 protocol, since it provides mechanisms for harnessing applications (or processes) on a remote system (or, making procedures available to other remote systems from the current system). We've already seen a bit on the use of NFS (at Layer 6) to access files on remote systems. The control functions associated with using that remote file system are implemented at Layer 5, and such functions are among those referred to in the Layer 6 discussion about the use of Layer 5 functions to establish and use the NFS connection, translation, and transmission services.

Codecs are an even more interesting example of a Layer 5 application, given the rise in popularity of voice-over-IP (VoIP). Some codecs are called from Layer 5 packages such as SIP or H.323, and those codecs can themselves be thought of as Layer 5 packages.

SIP and H.323 are interesting in that they initiate sessions based on telephony and teleconferencing parameters, over virtual circuits (i.e., those that can appear and disappear from time to time). SIP is thus aptly named, since placing a voice call involves creating a voice session and initializing the parameters associated with that virtual circuit, both of which are session-layer issues.

Of course, once the session is established (or, for the more general case of a data session), the data must be transferred from one system to another. That's the role of the next layer down the stack, the Transport Layer (Layer 4), which I will look at in Part 2 of this series.

On to Part 2
That wraps our discussion on Layers 5 to 7 of the OSI stack. In Part 2, we'll continue the discussion by examining Layer 4 (transport), Layer 3 (network), Layer 2 (data link), and layer 1 (Physical). We'll also discuss some non-model but very important pieces, especially for embedded devices; those pieces include network-aware bootloaders and other functions.