Presentation

External Data Representation (XDR) sits at the presentation level. It converts local representation of data to its canonical form and vice versa. The canonical uses a standard byte ordering and structure packing convention, independent of the host.

Layer 6 - Presentation Layer

The Network Redirector sends CPU operating system native code to the network operating system: the coding and format of the data is not recognizable by the network operating system. The data consists of file transfers and network calls by network aware programs.

For example, when a dumb terminal is used as a workstation (in a mainframe or minicomputer network), the network data is translated into (and from) the format that the terminal can use. The Presentation layer presents data to and from the terminal using special control characters to control the screen display (LF-line feed, CR-carriage return, cursor movement, etc..). The presentation of data on the screen would depend on the type of terminal that's used: VT100, VT52, VT420, etc.

Similarly, the Presentation layer strips the pertinent file from the workstation operating system's file envelope. The control characters, screen formatting, and workstation operating system envelope are all stripped or added to the file (if the workstation is receiving or transmitting data to the network). This could also include translating ASCII file characters from a PC world to EBCDIC in an IBM Mainframe world.

The Presentation Layer also controls security at the file level: this provides both file locking and user security. The DOS Share program is often used for file locking. When a file is in use, it is locked from other users to prevent 2 copies of the same file from being generated. If 2 users both modified the same file, and User A saved it, then User B saved it, then User A's changes would be erased!

At this point, the data is contiguous and complete (i.e. one large data file). See Fig. 4.

https://secure.linuxports.com/howto/intro_to_networking/c4412.htm

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.

http://www.commsdesign.com/design_corner/OEG20030415S0027