Introducing the OSI Model

Introducing the OSI Model
The OSI model was designed to promote interoperability by creating a guideline for network data transmission between computers and components that have different hardware vendors,
software, operating systems, and protocols. For example, look at the simple process of transferring a file. From a user’s perspective, a single operation has been performed to transfer the file. In reality, however, many different procedures had to take place behind the scenes to accomplish this seemingly simple task. Network data transmission (like the file transfer) is performed through the use of a protocol suite, also known as a protocol stack, especially when
installed in a given device.
    
   A protocol is most easily defined as a set of rules used to determine how devices communicate with each other. It is similar to language. If one person speaks English and another speaks English, they can communicate. But if one person speaks only Spanish and the other speaks only English, they won’t be able to communicate. A protocol suite is a set of similar protocols that work together to make sure communications happen properly. 
   
    The OSI model is used to describe what tasks a protocol suite performs as you explore how data moves from the user interface of a transmitter down to its physical network access, across
a network, and then up the layers of the receiving device to its user interface. Keep in mind that not all protocols map directly to the guideline provided for us through the OSI model, but there
are enough similarities so that you can use the OSI model to examine how these protocols function. This is one of the OSI model’s greatest advantages. It is at once very specific in the separation of functionality within a device (specifying more layers than most other models) and very generic in how it explains what happens at each layer. With this duality, networking engineers
and administrators are able to make both broad comparisons and precise distinctions between the functionality and interoperability of different protocol stacks. There are a myriad of protocol suites in use today, including IPX/SPX, NetBIOS, and TCP/IP, with the first two being quite a bit less prolific in today’s market than the last one. Each performs a specific function. Many of these functions that are provided through the use of a protocol stack and its components are

Standard functions performed by other components in other protocol stacks, thus paving the way for devices and software that can enable the interoperation between differing stacks.
The most commonly referenced protocol model, the OSI model, was developed in 1977 by the International Organization for Standardization (commonly referred to as ISO) to provide
“common ground” when describing any network protocol.

Note:

ISO is not an acronym for the International Organization for Standardizationbut is instead derived from the Greek word isos, which means “equal,” andwas adopted by the organization. For more information, go to www.iso.ch

As you can see in Figure 2.1, the OSI model consists of seven layers. Each layer performs a specific function and then passes on the result to another layer. When a sending station has data
to send, it formats a network request and then passes that request to the network protocol at the top layer, the Application layer. The protocol that runs at the Application layer performs an operation on the request and then passes it to the next (lower) layer. Each protocol at each layer below the Application layer performs its own calculations and appends its own information to the data sent from the layer above it. At the receiving station, the process happens in reverse. Figure 2.2 illustrates this basic process.

     As you can see from the diagram, it is possible to have communication between two devices with vastly differing personalities (operating systems), as long as the protocols they are running for network access and communication are compatible (both TCP/IP, for example). Here we have a DOS-compatible PC and a Macintosh talking together over what could be a common
network medium, like Ethernet over copper. The term peer communication comes from the fact that, through the use of headers, equivalent protocols in each stack appear to talk directly with one another. Because the header that one protocol creates means something only to that protocol, and because this control information is encapsulated deeper with each successive lowerlayer
protocol, only the compatible protocol on the receiving device, or perhaps an intermediate device like a router, will be able to access the control information found in the header created by the corresponding process on the transmitting device.

FIGURE 2 . 1 The Open Systems Interconnect (OSI) model

FIGURE 2 . 2 How data travels through the layers 

of the OSI model

As an example, if TCP on the DOS device creates a TCP header, then this header will be passed transparently by all intermediate devices to the Macintosh device, which will be the only device capable of de-encapsulating the incoming frame far enough to access the TCP header, as well as the only device along the way running TCP because intermediate devices such as routers,

switches, and hubs are involved with only the bottom three layers for through traffic and TCP is a layer 4 protocol. Even if this were not true, it is the peer communication between the IP protocol

of the DOS device and the IP protocol of every device in between, including the Macintosh device, that tells each one that this IP packet traversing the network is destined for the Macintosh.

This alone would be enough to discourage any intermediate device from trying to process the encapsulated TCP header.

Peer communication can be seen in operation at every layer of any protocol or reference model from the way that two devices communicating on a shared segment have to use a common

cabling protocol with agreed-upon pin configurations and encoding methods at the Physical layer all the way up to the Application layer, where one device will be able to send a message—written, graphical, or otherwise—to another device and rightly expect that message to come across as intended. These two devices with Application layer peer communication could have considerably more degrees of separation from one another than two devices with

peer communication at the Physical layer, allowing any number of devices along the way to produce a path for this message to make it from one end to the other. This example also illustrates the importance of having different protocols in each protocol stack because each layer provides a different scope or diameter of communication; lower-layer protocols require that communicating

devices be neighbors, whereas higher-layer protocols don’t require any such adjacency. This difference in the scope of the layers allows highly advanced protocol suites to be developed and implemented as stacks.

Note:

You can use mnemonic devices to help you remember the order of the OSI
model layers: APSTNDP (from top to bottom). The most popular mnemonic for
this arrangement is All People Seem To Need Data Processing. A reverse mnemonic
(from Physical to Application, bottom to top) is Please Do Not Throw
Sausage Pizza Away. (Good advice, don’t you think?)

The OSI model is mainly a reference model as opposed to a mainstream protocol suite. Although the ISO has created protocols that operate at each of the higher layers of its model,
very few entities have standardizaed on the OSI protocol suite, due mainly to the overbearing popularity of the TCP/IP protocol suite. Let’s take a brief look at the layers of the OSI model and the basic protocol functions they describe:

The Application Layer   The Application layer, the top layer of the OSI model, does not refer to applications such as word processors, but rather to a set of tools that an application can use to
accomplish a task such as a word processor application requesting a file transfer. This layer is responsible for defining how interactions occur between network services (applications) and the
network. Services that function at the Application layer include, but are not limited to, file, print, and messaging services. The Application layer may also support error recovery.

As an example, a web browsing application may appear, at first glance, to exist at the Application layer because it is indeed an application and it is involved, most often, with network communication. While the browser software is an application, it is not a protocol because the web services it connects to do not have to operate exactly the same way that the browser operates.
The fact that one application is a server application and the other is a client application speaks to their differences and need for underlying compatible protocols. The Application layer protocol
in common between the two applications is most likely HTTP, which allows the server to deliver an HTML file to the client for display in its browser window. The same browser could
speak FTP to an FTP server. HTTP and FTP are the Application layer protocols here, not the browser software. These protocols give support to the applications that call upon them and offer an entryway into the networking process.

To prove that these functions can be separated from the application itself, open your favorite web browser and surf to your favorite website. On the File menu, save the web page to your Desktop or other favorite local resource. Next, unplug your network connection or shut down your wireless access. You could even pull out your NIC card, for that matter. Open a new instance of your web browser and open the file you saved. Notice that the HTML file displays, even without the support of HTTP and an active network connection. If the application does not need to enter the network process to get its job done, then no Application layer protocol’s services will be required. Said another way, if an Application layer protocol is used at one end, then a corresponding Application layer protocol must be used at the other end, and because your web browser can be used independently of a network connection, it is not an Application layer process, as is HTTP, for example.

The Presentation Layer   The Presentation layer is responsible for the formatting and code conversion of data being passed up to the Application layer. In this layer, character sets are converted
(e.g., from ASCII to Unicode or EBCDIC) and data is encrypted. Data may also be compressed in this layer. Of course, anything that is done to the data on the transmitting device must be undone on the receiving device.

Note:

that character-set conversion is not a result of the transmitting device’s having done anything to the data and is only performed on the receiving device, in response to the Presentation layer’s
recognizing that incoming data is not based on the same character set that its own upper-layer processes require. On the other hand, compression and encryption services must be supported by both end devices in the conversation, one to add these features, the other to remove them.

It is the Presentation layer that is responsible for recognizing file types in an incoming data stream and performing any massaging to the data to make a file presentable to the Application
protocol. Think of this function as providing a common syntax for data and using this syntax to convert to and from the application data. The Multipurpose Internet Mail Extensions
(MIME) system denotes the file type of incoming data, helping the Presentation layer know what to do with the incoming stream. File types like MIDI, MPEG, JPEG, and GIF are considered to be Presentation layer entities.

The Session Layer   The Session layer defines how two computers establish, synchronize, maintain, and end a session. Practical functions such as security authentication, connection ID establishment, data transfer, acknowledgments, and connection release take place here. This list is not all-inclusive. Any communications that require milestones—or, put another way, require an answer to “Have you got that data I sent?”—are performed here. Typically these milestones are called
checkpoints. Once a checkpoint has been crossed, any data not received needs retransmission only from the last good checkpoint. Adjusting checkpoints to account for very reliable or unreliable connections can greatly improve the actual throughput of data transmission.

The Transport Layer   The Transport layer is responsible for checking that the data was delivered error-free. It is also used to divide a message that is too long into smaller segments and, in
the reverse, take a series of short messages and combine them into one longer segment. These smaller or combined segments must later be correctly reassembled. This is accomplished through segment sequencing (usually by appending a number to each of the segments).
     This layer also handles logical address/name resolution. Additionally, this layer can send an acknowledgment that it got the data packet. Frequently you will see this referred to as an ACK,
which is short for acknowledgment.  This layer is responsible for the majority of error and flow control in network communications. 
     
The major difference in the sessions that the Session layer deals with and the connections that a connection-oriented Transport layer protocol (such as TCP) will create lies with the size or scope of the communication. The Session layer is responsible for the ordered bidirectional communication of entire messages, in the form of a dialog, while a connection-oriented Transport layer protocol is only responsible for the ordered transmission of segments of these messages. Session layer functionality will have to be called upon to salvage a session that is broken before  a normal end can occur, while Transport layer functionality is fine to reestablish lost segments or broken virtual circuits while the session itself is still established.

The Network Layer   The Network layer is responsible for logical addressing and translating logical addresses into physical addresses. A little-known function of the Network layer is prioritizing
data. Not all data is of equal importance. Nobody is hurt if an e-mail message is delayed a fraction of a second. Delaying audio or video data a fraction of a second could be disastrous to the message. This prioritization is known as quality of service (QoS).

In addition, the Network layer controls congestion, routes data from source to destination, and builds and tears down packets. Most routing protocols perform their function on packets native to this layer.

The Data Link Layer    The Data Link layer takes raw data from the Physical layer and gives it a logical structure, known as a frame. In the opposite direction of flow, the Data Link layer hands frames down to the Physical layer for bit-level encoding onto the networking medium. Frames include information about where the data is meant to go, which device on the local link sent the data, and the overall validity of the bytes sent. In legacy technologies used over lessdependable links, such as X.25 and LLC2 used in an SNA environment, after a data frame is sent, the Data Link layer waits for a positive ACK. If one is not received or if the frame is damaged, another frame is sent. These days, such acknowledgment and retransmission is left to higher layers to perform.

The Data Link layer also controls functions of logical network topologies and physical addressing as well as data transmission synchronization and connection.

The Physical Layer   The Physical layer is responsible for controlling the functional interface, such as transmission technique, encoding scheme, cable specifications, pin layout, and connector type.