Volume Number: 17 (2001)
Issue Number: 10
Column Tag: Network Management
by John C. Welch
Well, we've made it into the last three layers, and things should go a bit faster now. We are also going to group Layers 5 and 6 in this one article, as they are quite thin, and often rolled into other layers. The first OSI layer we will talk about is Layer 5, the Session Layer. This Layer is quite similar in function to Layer 4, and in many situations, it is rolled into the Transport Layer, and is not even a separate part of the networking model. In fact, there is only one protocol that really makes specific use of the Session Layer, and that is AppleTalk. (Other protocols, notably IPX/SPX have aspects that use the Session Layer, but AppleTalk makes more specific use of it than most any other protocol.). In fact, TCP/IP almost completely ignores the Session Layer. So if I seem to talk about AppleTalk more than other protocols here, there's a reason for it.
The basic function of the Session Layer is to manage communications flow during a session. Now, this is much of what Layer 4, the Transport Layer does, so why have a separate layer? Scope is the reason. The Session Layer is not concerned with things like error checking, reliability, etc. It is assuming that those things are being taken care of by the Transport Layer.
Instead, the Session Layer is concerned with managing the connections or sessions from a higher level point of view. It is concerned with the way traffic is flowing in the session, and making the session run smoother. It is dealing more with the application using the session, then the low - level mechanics of the session. So the Session Layer is said to control the dialog between two applications on a connection.
One of the aspects of this dialog control is the duplex level of the connection's data flow. That is, can the applications at both ends send and receive data simultaneously, (full duplex), or do they have to send and receive in separate actions, (half duplex). Deciding which to use, and handling it is a Session Layer function. An example of a protocol that deals with this type of functionality is the Apple Data Stream Protocol, or ADSP. ADSP's job is to handle connections between devices, and manage the bi-directional flow of data between them. It also allows the data to flow as a continuous stream from sender to receiver, and can handle things like out of order data problems. In that sense, ADSP is also performing some Transport Layer functions too.
Another function of the Session Layer is grouping. An example of this could be the AppleTalk Zone Information Protocol, or ZIP. This is the protocol that takes the information from the Name Binding Protocol, (NBP) and uses it to present the names of devices on an AppleTalk network in the correct logical groups, or zones. The Chooser is a classic use of ZIP and NBP.
Finally, the Session Layer deals with recovery, or what to do when the session fails for some reason. Now, there are two ways to handle this. The first is to just discard all the data on the receiving end, and retransmit all of it. For small pieces of data, this is not a big deal, but for say a five hundred page print job, that gets to be intolerable. So what the Session Layer does is allow for the insertion of checkpoints into the data. So now, if the connection dies for some reason, all that has to happen is for both ends to synchronize which checkpoint was last successfully transmitted, and proceed from there. An example of this functionality, although it occurs at a different layer is the ability to resume an interrupted FTP transfer. Another example of a protocol using this is the Printer Access Protocol, or PAP. When you have to stop and restart an AppleTalk print job, and it asks you "resume printing on page X", that's what we are talking about.
As you can see, there is not a lot to the Session Layer. The protocols that use the layer can be quite complex, but Layer 5 is, in and of itself, rather thin.
This layer is different from all the previous layers, as it is the first layer that is not at all concerned with moving data from point A to point B. Instead, the Presentation Layer cares about how the data is sent up to the Application Layer, and how it is sent down to the Session Layer. Remember, so far, regardless of how we have moved the data, it has all been nothing but a series of bits. However, applications, and the users of those applications don't want ones and zeros. We want letters, numbers, colors, etc.
That's what the Presentation Layer is for. It handles things like ASCII encoding, EBCDIC encoding, converting between the two formats, etc. It also handles other things like dealing with different floating point formats and the representation of those formats. If you are doing things like data compression, or encryption via a protocol, then this is where you would handle that sort of thing.
In other words, the way data is handed off, and how it is encoded, or how it looks to the other layers is a Presentation Layer function. One example of a use for the Presentation Layer is Postscript printing. Although the actual data transfer would be handled by the Session Layer and below, when you send Postscript data to a printer, it has to be encoded correctly, it has to ‘look' right. Otherwise, the print job could fail.
Well, this was certainly a short article. Again, these two Layers really are light weight. They don't' really interact with the user or the user applications, as does the Application Layer. They also don't directly deal with the mechanics of data transfer. As we pointed out, the Presentation Layer doesn't deal with this aspect at all. Still, since AppleTalk makes use of the Session Layer, and almost all protocols deal with the Presentation Layer in one fashion or another, it's good to know why they are even there. Next time, it's the series conclusion, the end of the journey...Layer 7, the Application layer.
As already mentioned, you may wish to include a bibliography at the end of your article, especially if you wish to cite work in the body of the article. Here is some typical bibliography format, to serve as a model:
John Welch jwelch@aer.com is a Mac/PC/Unix administrator and Mac writer living in the wilds of that part of Massachusetts that is not Boston. He has over fifteen years of experience at making computers work. His specialties are figuring out ways to make the Mac do what nobody thinks it can, and showing that the Mac is the superior administrative platform.
