The OSI Reference Model and Other Hierarchical Protocols

Daniel M. Dobkin

Introduction: Up the Stack

You are an important business executive in a Hollywood romantic comedy c. 1954; it's a period piece, with the action in 1907. How do you place a phone call?


CARRUTHERS [slightly rumpled dark suit, tie askew, Cary Grant if he is available]: [presses button] Miss Jones, get me Lewis Smothers and make it snappy!

MISS JONES [overly made up blonde, desperately in love with Carruthers but hardworking, responsible, good with telephones]: Yes, sir! Right away, sir! [cut to closeup of Miss Jones' telephone book; she flips pages until we see SMOTHERS BROKAW 9324 in neat handwriting]

[Cut to profile as she picks up her telephone handset:]

MISS JONES: Mabel, this is Annie! Get me Brokaw 9324 right away.

[Cut to phone operator in front of patch board; closeup of operator who we would describe as looking a lot like Lily Tomlin if it weren't anachronistic and dated at the same time, showing her neck-mounted mouthpiece as she speaks]

OPERATOR MABEL: [snort] Okay, Annie dear. [snort]

[Sequence of shots of one operator after another patching cords together; voiceover of their exchanges to make the appropriate set of connections]

MABEL: Oh, Alice, Honey, Brokaw 9324, coming on your line 12.

ALICE [brief & businesslike]: my 12, to Brokaw 9324 [pause] Joanne, on 182, your exchange, number 9324

JOANNE: your 182... 9324 is on ... MY board, I'll ring. [closeup of the last patch cord plugging in and--]

[Closeup of phone ringing; pull back to discover dark-haired, prissy, overdressed Miss Eloise Albinoni, assistant to Mr. Smothers.]

MISS ALBINONI: Smothers, Thomas, Richard, and Satyre; Mr. Smothers' office. May I help you?

[cut to closeup of Miss Jones]

MISS JONES: [disdainfully] Oh, hello, Eloise. Mr. Carruthers would like to speak to your boss right away.

MISS ALBINONI: Why, Annie Jones, I'll just see if Mr. Smothers has time for him. [presses button on phone] Mr. Smothers, Mr. Carruthers would like to speak to you.

[closeup of chubby hand pressing reply button]

SMOTHERS [a slightly accented Sidney-Greenstreet-esque baritone]: I'll take it on line 2.

MISS ALBINONI: OK, tell Aaaalbert he can go ahead.

[cut to closeup of Albinoni's hand pressing button 2 on her phone]

MISS JONES: [presses button; cheerfully:] Mr. Smothers on line 1, sir!

CARRUTHERS: Lewis you conniving dog, let's cut to the chase: I'll make it twenty-five thousand dollars in cash if I have all the negatives in my hands by tomorrow morning.

SMOTHERS: [seen from the back in silhouette] The wife of a Congressman only twenty-five thousand? I think fifty is more respectful to our democratic process.

[closeup of Miss Jones, listening silently at the phone, hand to her mouth with astonishment]

CARRUTHERS: This must be a bad connection, Lewis. I thought for a moment that I heard you say fifty, but that's beyond even your level of graft.

SMOTHERS: Why, Albert, that is certainly what I said. The error is not in the telephone but in your understanding of the delicacy of your position.

CARRUTHERS: Thirty thousand and that's my last offer, I'll bring the police in and damn the publicity.

SMOTHERS: Very good, Albert. Small bills, please, delivered in the customary fashion. Good day. [closeup of hand hanging up the phone]

[sequence of quick cuts as lights go dark on one patch board after another, operators' hands returning plugs to their resting place at the bottom of the board]



Ignoring the sexual innuendo and romantic complications no doubt to follow, what just happened?

• A connection was requested
• The destination address was converted to a form recognized by the network
• An "address resolution" took place, converting the address into a series of connections (links) across the network from one switching office to another until the destination was reached
• The connection was confirmed and data services offered to the requestor
• Data was exchanged using conventions for starting, stopping, and correcting errors of transmission
• The connection was released after the data exchange was completed.

The process looks something like figure 1, where we have also shown a somewhat more impersonal view of the situation as it might look if one set out to provide an analogous process for an automated data exchange:


Figure 1: A personal and impersonal view of a telephone conversation

The person who needs data transferred [the "host application"] uses an assistant [the "user-network interface"]. This assistant manages the details of dealing with the network: in this case, how to look up a telephone number identifying the desired destination host, and how to make a request to the network. The telephone operators [the "network"] know how to translate a given destination address into a connection on their patch boards. The assistant at the destination end [Ms. Albinoni acting again as a user-network interface for Mr. Smothers] can signal acceptance of the connection and pass the relevant data on to the corresponding host application.

Note that even though all the information actually travels as electrical signals along analog phone lines, from the point of view of anyone in the system they are in effect conversing directly with their peers: that is, the telephone operators speak with each other, the assistants deal with the network and then directly with each other, and the two bosses talk directly to each other, ignoring the network services that were required to provide the connection.

It's also interesting to note that there are in some sense two parallel processes going on. One is a "routing" process, typically invisible to the users (host applications) in which addressing information is transferred and some sort of connection is set up between the two users, and the second is the actual transfer of data along this connection. Furthermore, there are certain signals -- request connection, accept connection, terminate connection -- which are initiated by the users [hosts], and others -- find phone number [address resolution] and make patch connection [routing]-- which require signals that originate within the network. Thus there's a separate requirement for "signaling" to support the transfer of the user data.

What about data integrity? In this simple 1907 network, error checking is the responsibility of the users (" This must be a bad connection, Lewis. I thought for a moment that I heard you say fifty"); no checking is done at the network level. However, if the individual links were poor (and thus the whole phone line almost unintelligible) we might enlist the operators to perform data transfer and error checking:

"Mabel, he said 'fifty thousand dollars'."

"Fifty or fifteen, Alice?"

"Fifty, five-zero!"

"Thanks, Alice, I'll pass it on."

Finally, what if Mr. Carruthers spoke English and Monsieur Smothers French? We might add another function -- translation -- to our data network:


Figure 2: Communications with an additional translation function.

You can see that we're starting to build up a "stack" of functions at each "node", with the nodes connected by "links". Each level in the stack represents in an abstract sense a certain set of functions necessary to the communications process; the benefit of allocating them to certain layers is that then the other layers only need to understand the interface with their neighbors and not the whole system. The stack is a division of labor, not a physical object: what's really happening here is people talking on telephone lines. Each function is often known in the communications business as a protocol, so the whole thing is a protocol stack.

This approach to dividing up functions pops up all over the place in communications. Let's look in a bit more detail at a real example -- depending on how idealogical you are, perhaps the only example -- of a modern communications network protocol, the Internet protocol suite that you are using to read this article, TCP/IP.

TCP/IP: Terrific Champion Posterior on Implausible Palindrome

All right, it really stands for Transmission Control Protocol / Internet Protocol. Does that clarify everything?

I didn't think so. A closer look will help. The task is to move data: more specifically, to provide a "service" that can transfer chunks of data from an application (a program, like a web browser) on one computer to a similar program on another computer. Note that we view the transfer as occurring between programs rather than between computers, because a given physical computer might be running a whole bunch of different programs "at once", particularly if it is a network server. In order to provide a method for identifying a particular application program to the outside world, we'll assign each program to a virtual port: that is, from the point of view of the communications system, a given physical computer (a host) looks like:


Figure 3: A virtual view of a real host computer

These ports are just numbers that are used to identify which program you're trying to talk to. It's as if instead of addressing people by name at a party, you gave everyone number tags and used numbers instead. Note that some of the port numbers are "well-known" -- that is, they are always identified with particular applications or services by convention. The numbers shown in figure 3 are well-known ports for the cited functions running on a server (that is, a computer that e.g. stores e-mail and provides it to a user when requested), whereas if you were using your home computer to try to get your e-mail, the e-mail program on your computer would invent a temporary, arbitrary port number used for the duration of its connection with the server. This is an "ephemeral" port.

We can now define the task of the communications system looking "down from the top" (that is, from the point of view of the host application):

• connect me to a given port on a given remote host computer so that we can exchange messages
• the messages must arrive in order and be free of errors
• I don't know or care what network the destination computer port lives on or how the messages go back and forth

This is the job of the transmission control protocol, TCP.


Figure 4: What TCP does for the host computers

In our telephone analogy, the applications are like Mr. Carruthers and Mr. Smothers, and the TCP protocol plays the role that Miss Jones and Miss Albinoni did in establishing and removing a connection between their supervisors. However, TCP does more. It watches over the data to make sure that the data arrives at its destination in order and uncorrupted by transmission errors.

In order to understand how it does this, we need to recognize that TCP handles data as individual packets of information (actually, at the TCP stage they're known as "segments" and at the IP stage they become "packets", but packet is the generic term). The actual management of transmission of these packets from one TCP process to another is the job of the Internet Protocol, IP. TCP gives a packet to IP with the necessary address information; IP then makes a "best effort" attempt to send the packet to the destination address, taking care of issues such as translating the packet into different formats for differing networks, or splitting it into pieces (fragmentation)and reassembling it if a given network has a small maximum packet size. This situation is illustrated in figure 5.


Figure 5: User application communicates through a port, down the stack, and back to another port to the destination application.

Because IP treats each packet as an individual transmission (that is, it is a connectionless protocol), the packets could travel differing routes and arrive out of order. IP has no error checking; some packets could arrive with errors or could be dropped altogether. Thus, TCP is responsible for keeping track of the order in which packets were sent and reassembling arriving packets in the correct order. TCP supports error checking and correction by requesting retransmission of packets that were lost or corrupted ("This must be a bad connection, Lewis. I thought for a moment that I heard you say fifty, but that's beyond even your level of graft."). This approach is known as an Automatic Repeat Request or ARQ error correction scheme. TCP also imposes flow control by advertising how much room is available in the receiving system's buffer each time it acknowledges receipt of a packet. If no buffer room is available, the transmitting TCP process will stop putting packets into the connection until the congestion is relieved.

IP in turn relies on a network interface to format and address packets in an appropriate fashion for the actual physical network over which the data will travel. The network interface takes care of translating data and address information into the format appropriate for e.g. an Ethernet network. Figure 6 shows how things look once this additional function is taken into account.



Figure 6: Applications communicate using IP to talk to the network interface.

Finally, the network interfaces communicate using real, physical, touchable (and breakable) links: wires or fiber optic cables carrying 1's and 0's. The whole stack looks like figure 7, in which we also provide for comparison the functional view of a telephone call we discussed previously:




Figure 7: TCP/IP and the analogous picture of a telephone call

Just as before, we have constructed a division of labor amongst the various functions needed to communicate across networks, and have symbolically represented this division of labor as a stack of protocols. The resulting diagram looks a lot like that of our 1907 telephone system. Like the telephone diagram, a lot of complexity has been suppressed. For example, we haven't said a word about how the systems know where to send the data packets: that is, how the Router translates the packet's address into information about where to send it next. In the Internet, each router maintains a routing table which tells it where each address on the Internet can be found; this is the equivalent of each telephone operator having a phone book with every phone number in the system and a corresponding output line for their patch board. The routing tables are constructed and updated by the routers acting autonomously, using a set of signaling protocols which operate completely independently of user data, though they use the same IP protocol to send routing messages. Thus, the real TCP/IP stack looks something like figure 8.


Figure 8: The TCP/IP stack including provisions for exchange of routing information

OSPF (Open Shortest Path First) is one of several alternatives for routers to exchange information about the network topology. OSPF sends packets from one router to its neighbors, using the services of IP to get the packets from place to place. The routing information exchange happens entirely independently of any user data, although it uses the same IP, network, link, and physical resources that are employed to move data within the networks.

Other Hierarchical Communications Protocols

In thinking about two rather different networks -- an old-style telephone system and the modern Internet -- we've found that it makes a lot of sense to partition the various functions involved in the network, and arrange them in a sort of hierarchy where each group of functions -- each protocol -- uses functions below it to deliver services to protocols above it. This turns out to be a very useful way to think about communications systems. Let's look at some other examples.

The most common local area network for connecting computers to each other within a building or campus uses the Ethernet protocol. A basic Ethernet network uses a "shared medium": that is, all the computers on the network are connected to the same cable, like an old telephone "party line". Thus, in addition to the usual problems of figuring out where to send data to and getting it formatted and converted to and from 1's and 0's, we have the problem of how to allocate the shared medium to the various users: Media Access Control (MAC). The protocol stack for Ethernet thus has an extra layer to take care of the MAC function. A picture is shown in figure 9.


Figure 9: Ethernet protocol stack and functions

The Ethernet stack shown here is a possible answer to the question "What is inside the "LINK" box?" in figure 8. That is, it makes some sense to say that Ethernet is an implementation of the physical and link layers of the TCP/IP stack we have already discussed.

Mixed "wide area" voice-data networks, often operated by local phone companies or competitive telephone service providers, may use still another set of networking protocols, Asynchronous Transfer Mode (the ATM that is not where you get cash for lunch). ATM is similar to TCP/IP in that user information is sent in data packets. However, the routing and control approach is quite different: ATM networks are purely connection-oriented, so that the path a packet follows is completely determined by the virtual circuit it is in. Packets always follow the same path and arrive in order of transmission, so there is no need for a TCP-like function to re-order them. ATM networks also actively manage data traffic in order to provide "Quality of Service" guarantees to their users: that is, a user can ask for and receive delivery of a certain bit rate with a fixed maximum variation in the delay of delivery. To provide these services, ATM networks have a lot of signaling requirements, both to set up and tear down virtual connections and to manage traffic within and at the edges of the network to ensure that guaranteed performance is delivered. These functions occupy a "control plane", with a "user plane" for data, both employing the same physical connections to transfer messages. A simplified view of an ATM protocol network is shown in figure 10.


Figure 10: A simplified end-to-end view of an ATM network protocol.

The physical layer takes care of line coding, pulse shape, and extracting the packet boundaries. The ATM layer delivers fixed-length packets in order from one end of a virtual circuit to another, rather like TCP running over IP. However, unlike TCP, ATM can guarantee that the packets will be delivered in a certain amount of time and with bounds on packet error rate. Furthermore, addressing is entirely different in ATM: rather than each packet carrying a complete address, the process of establishing a virtual circuit connection must precede sending of data packets, and once established, the virtual circuit distributes routing information through the network and thus only requires a brief virtual circuit identifier on the packet. [There's also a virtual path identifier, but the principle is the same.] The ATM adaptation layers (AAL's) come in several flavors and provide various services, but generally take care of fragmenting user data packets into the appropriate size for the ATM network, packet error checking, and optional multiplexing of different user data together onto the same connection.

Note that while the diagram in figure 10 (ATM) looks a lot like the diagram in figure 8 (TCP/IP), the detailed services provided by each layer to the other layers are not identical. It isn't really possible to say that e.g. the TCP layer corresponds to an AAL and IP to ATM, etc. The ATM protocol is in some ways a fundamentally different partitioning of the same basic data networking functions provided in TCP/IP.

The OSI Reference Model: A Layer Too Far?

So it seems that it is often useful to organize communications functions into stacks of protocols. A simplified picture of one stack looks much like another, though these pictures often hide important differences in partitioning of tasks. Now imagine a group of bureaucrats consuming a large quantity of illegal narcotic drugs -- oops, we didn't mean that! Just imagine that you get a bit carried away with this similarity, and make the assertion that all communications systems can be described by the same protocol stack. What you might get is... the OSI Reference Model.

The OSI 7-layer reference model is an attempt to abstract features common to all approaches to data communications, and organize them into layers or modules such that each layer only worries about the layer directly above it and the one directly below it. The model is usually shown in something like the following deceptively simple diagram, generally with little or no explanation:


Figure 11: the Open Systems Interconnection (OSI) Protocol Stack

To figure out what all this means, it is helpful to remember that the whole point of the stack is to communicate with something. If we look at the OSI model in this context, we end up with a picture like figure 12, which hopefully is starting to look familiar to the reader:


Figure 12: The OSI reference model applied to a communications network

Once again, the OSI protocol stack represents a division of labor amongst the various functions required in a communications system. Conceptually, what's supposed to be happening is:

• Application layer: The application layer provides services to a calling computer program. An application layer might take care of all the downloads involved in transferring a web page (that is, the text, graphics, and other files) to a browser (the client program or application).

• Presentation layer: Takes care of any data format translations that might be needed to take the particular bits representing e.g. a number in the client computer and convert them to a "universal" number representation recognized by the communications system.

• Session layer: This layer is responsible for controlling exchange of information, for example by having the client and server take turns transmitting data.

• Transport layer: The transport layer is responsible for getting messages from one computer to another, somewhat analogous to the role that TCP played in the TCP/IP suite above.

• Network layer: The network layer is responsible for getting data across a communications network from one host computer to another.

• Data Link layer: The data link layer (often abbreviated to "link" layer) gets data from one network node (e.g. a computer or router) to another.

• Physical layer: The physical layer is the set of specifications that describe the actual medium of transmission. For example, a physical layer specification might include the type of connectors and wire to be used in a cable linking two machines, as well as the function of each wire and voltage levels that specify a "1" or "0", allowed rate of transmission, and so on.

If you find these descriptions a bit vague and confusing -- you're not alone. A model that covers all possible communications systems must necessarily be either rather vague or absurdly complex in its specifications. Rather than spending a lot of effort trying to figure out how the Session Layer differs from the Transport Layer, or deciding how to depict separate signaling and data activities, it is perhaps more profitable to reflect on the useful and important concepts embodied in the Reference Model:

Commonalty of function:

The OSI reference model recognizes the common features of any communications process: the need to format data, address it, get it to the right destination, and make sure that it arrived intact. The stack also helps to create a standardized ordering of these functions. For example, establishing a connection from one user to another happens "before" or "on top of" actual transmission of data, just as we dial a telephone on one end and pick up the ringing handset on the other to establish a connection prior to actually starting our conversation.

Hierarchical interfaces:

At the heart of the OSI stack is the idea that the various functions involved in communicating can be organized hierarchically: the program that is using the communications service needs to provide some data and perhaps an address to which the data should be sent, but shouldn't have to worry about just how the data actually gets moved. This is exactly analagous to mailing a letter: we provide a letter, an envelope with an address, and a stamp, but we aren't responsible for which trucks, airplanes, or [so it occasionally seems] human-powered ocean-going pedal boats the Postal Service uses to deliver the letter. Thus, in the idealized stack shown above, each layer provides data to the layer below it and doesn't worry about how that layer performs its function. This gives rise to the clever and rather useful idea that, from a "logical" point of view, each layer only talks to its peers in the same layer:


Figure 13: From the point of view of higher layers, each layer communicates directly with its peer layer; the network and underlying layers which actually provide the the data transfer are "invisible".

The great virtue of an hierarchical structure is that a given layer -- the Network layer, say -- can converse with its peer on another computer without caring how the data is actually transferred, whether by fiber optics, RS232 cables, or satellite links. You can (at least in theory) change the physical layer without needing to rewrite the network layer. Further, the network layer doesn't really care what application (browser, e-mail program, terminal emulator) is asking for its services. As long as the interfaces between layers are fixed, the layers themselves can be changed at will without affecting other layers.

Ah, but there's the rub: how independent can each layer really be of all the others? In the real world aspects of one layer often propagate upwards or downwards to affect the operation of other layers: we do care if a letter travels by airplane or pedal boat! For example, if you're using a wireless portable device as the first physical link, you have to expect a very high error rate (perhaps as high as 0.1% of bits will be misread), so you need to have error correction in the data link layer. In this case you might not want additional error correction in the network or transport layers to avoid excessive overhead. However, if the physical layer is a fiber optic cable with an error rate of less than 10^-12 and very high data rates, you can't afford error correction in the link layer, and thus need to have it in the network layer.

Different applications also require different types of data transmission (generally referred to as Quality of Service, QoS): an e-mail just needs to arrive at the destination intact, and doesn't care too much how long it takes to do so, whereas a voice-over-network telephone call assumes that the data describing the sound of your voice will arrive not just quickly, but in order and without much variation in delay from one packet of data to another, but can tolerate some errors or "dropped" packets: human listeners can correct for noise but are bothered by erratic stops and starts. This means that every real communications system makes specific assumptions about its communications medium and its users, and as a consequence has its own unique hierarchical structure.

So the best way to think about the OSI reference model is not as a standard onto which every possible communications system must be mapped, but as a sort of "typical" way to build a protocol, generally representative of real systems even though, like a "typical" 3.5-person household, no real example exactly fits the model.