Webspace Sponsored by:

Version 0.0.0 @ 03:55/08.07.2000

ISO OSI 7-layer Model forced with TCP/IP

Two competing systems were at work when the Internet was being created. Both were looking to define a structured, and modular design for networking. In one corner, we had a collection of governments and the ISO looking to create a standard that could be accepted by all members. In the other corner, we had groups of technical people that made a protocol, tested it, found errors, fixed them, and re-tested the protocol until it worked.

The ISO, can be thought of in this case as working on paper entirely from Theory, while the TCP/IP crowd sat down, got their hands dirty in the code, and learned from experience which parts worked and which parts did not.

There are plusses and minuses to both of these systems. For example, taking a long look at a problem, and carefully plotting out a plan of attack can offer long term future benefits. If some new addition to a protocol is desired in the future, it may be difficult to "patch" the protocol. Without forethought to the inclusion of future needs addressed at planning, patches resemble "hacks" more than they resemble an optimization with structured coding. If the protocol stack is in wide use, people are reluctant to upgrade their system and be incompatible with everyone else. Ensuring that you and others examine possible uses helps decrease the chances of need to modify the protocol stack later in the future.

Sometimes, a simple problem may have a simple solution. In cases like this, the time spent planning a system of attack is lost when the solution is entirely simple requiring little or not thought. Maybe problems you encounter in the "real world" do not show up while you work from the paper and theoretical world. Without experience in the problem with hands-on work, problems not expected could force a re-thinking of the concept on paper. This may cause the development to take longer.

A rather humorous and opinionated way to look at a comparison between the TCP/IP camp and the ISO people can be seen in this included quote from a fortune offered on one of my Linux boxes:

When you read the above section, you can get an idea on how differences between the two methods for creating networking protocols lead to vocal supporters on both sides. I am not looking to resolve this issue in this paper. Instead, I try to show how there are differences in how these two groups tried to solve their problems. This is meant to help you to understand why layers from the TCP/IP suite of protocols through to the Application Layer are not easily assigned to layers in the ISO OSI 7-layer Model.

Below, you can see a copy of the ISO OSI 7-layer Network Model discussed in the previous page in more detail:

ISO OSI 7 Layer Reference Model: End-to-end vs. Chained Communications
7 Application- < -------End--------to--------End------- > Application-
6 Presentation < -------End--------to--------End------- > Presentation
5 --Session--- < -------End--------to--------End------- > --Session---
4 -Transport-- < -------End--------to--------End------- > -Transport--
3 --Network--- < - > --Network-- < -- > --Network-- < - > --Network---
2 -Data Link-- < - > DL < - > DL < -- > DL < - > DL < - > -Data Link--
1 --Physical-- < = > PH < - > PH < == > PH < - > PH < = > --Physical--
L Stack Num 1  Link  Stack Num 2  Link  Stack Num 3 Link  Stack Num 4
Key:
< == > This is a physical wire or media connecting devices
< -- > This is a virtual path for peer level, layered protocol communications. Follow the GREEN colored layers, up and down any touching green stacks, and across physical links.
---- Where two or more "-" characters exist in a string, alone in a cell special meaning is implied. This is meant to show that data does not physically pass within the stack shown across this path, even though the data "virtually" passes through this point when viewing the peer layer stacks from an "End-to-end" vs. "chained" perspective.
DL Another way for referring to the Data Link layer.
PH Another way for referring to the PHysical Layer
GREEN or follow the ajacent cells with "links" This identifies the path that data actually flows, in a trip down the layers, across the physical layers, up to the RED colored layer where it is analyzed and sent on down to another physical layer, and over through the same layers, and is passed on down again, and across a third physical link to the destination, and up its layers.
R E D Shows the numbered layers where a chained communications for peer level protocols on original source to final destination take place. (By chained communication, you see that peer layer protocols must communicate through partial stacks for network devices before getting to final destination.)

From this and the sections on TCP/IP packets later in this document, you will see that TCP, and UDP appear to work for the most part at the Transport Layer. You will also see IP (and ICMP) work(s) for the most part at the Network Layer. We see these when we push the TCP/IP protocols into the ISO OSI 7-layer Networking Model's layers. (We will look into this in more detail further below.)

When we try to include a matching for a protocol like SSH (Secure Shell, a replacement for Telnet) we have problems. We will see that it performs things that appear to match up with descriptions from the Application Layer, Presentation Layer, and Session Layer. What does this say? This tells us how applications in the TCP/IP suite of protocols are often viewed as taking all three of the top layers of the ISO OSI 7-layer Model for Networking.

Let us now create a new 5-layer model to describe a TCP/IP based network model. This new 5-layer model will reflect mapping the top 3 layers of the ISO OSI 7-layer Model for Networking into a single monolithic layer we will call the TCP/IP Application Layer. This is meant to allow the TCP/IP Application Layer to still remain as the name for the top layer in both models. (Pay attention to the left-hand side labeled, "Stack Num 1" for this next section.)

5 Layer TCP/IP Model vs. ISO OSI 7 Layer Reference Model
5
Application-
< -------End--------to--------End------- >
Application-
7
< -------End--------to--------End------- >
Presentation
6
< -------End--------to--------End------- >
--Session---
5
4
-Transport--
< -------End--------to--------End------- >
-Transport--
4
3
--Network---
< -- >
--Network---
< -- >
--Network---
< -- >
--Network---
3
2
-Data Link--
< -- >
-DLL-
--
-DLL-
< -- >
-DLL-
--
-DLL-
< -- >
-Data Link--
2
1
--Physical--
< == >
-PHY-
--
-PHY-
< == >
-PHY-
--
-PHY-
< == >
--Physical--
1
L
Stack Num 1
Link
Stack Num 2
Link
Stack Num 3
Link
Stack Num 4
L
Key:
< == >
Is a physical wire or media connecting devices
< -- >
This is a virtual path for peer level, layered protocol communications. Follow the GREEN colored layers, up and down any touching green stacks, and across physical links.
----
Where two or more "-" characters exist in a string, alone in a cell special meaning is implied. This is meant to show that data does not physically pass within the stack shown across this path, even though the data "virtually" passes through this point when viewing the peer layer stacks from an "End-to-end" vs. "chained" perspective.
-DLL-
Another way for referring to the Data Link Layer.
-PHY-
This is another way for referring to the PHYsical Layer.
GREEN
This identifies the path that data actually flows, in a trip down the layers, across the physical layers, up to the RED colored layer where it is analyzed and sent on down to another physical layer, and over through the same layers, and is passed on down again, and across a third physical link to the destination, and up its layers.
R E D
Shows the numbered layers where a chained communications for peer level protocols on original source to final destination take place. (By chained communication, you see that peer layer protocols must communicate through partial stacks for network devices before getting to final destination.)

The left-hand side of the above diagram shows what we are describing: the 5-layer model for TCP/IP suite of protocols. The right hand side shows what we described in the previous page: the ISO OSI 7-layer Model for Networking.

I should note that the mappings shown in the above diagram are not perfectly made. The diagram has the weakness of making it appear that the Application Layer for the TCP/IP 5-layer model maps perfectly to the Application Layer, Presentation Layer, and Session Layer of the ISO OSI 7-layer Reference Model for Networking. We are trying to make some square pegs fit into some round holes by forcing the TCP/IP 5-layer model to correlate its layers exactly with the ISO OSI 7-layer reference Model for Networking.

Here we begin examination of the TCP/IP 5-layer model's Application Layer by comparison to the ISO OSI 7-layer Reference Model for Networking Application Layer, Presentation Layer, and Session Layer.

Within SSH you have the following properties: (Not all aspects of SSH are covered in this partial review. Only enough of the attributes of the SSH protocol are covered in order to give the user and understanding that SSH as a complete protocol is not easily matched to any one of the 7-layer model's layers.)

In addition to the above mess of the SSH protocol refusing to have its parts fit withing the "standard" know as the ISO OSI 7-Layer Reference Model for Networking, realize that it is also possible to tunnel a PPP connection over an SSH connection, causing 1 layer of nesting. There is no theoretical limit as to how many times a tunneled connection could further tunnel oter connections, but there are rational limits. Each tunneling decreases performance by increasing latency, and decreasing throughput (since headers for each tunneleing are cumulative, and each stream must be decoded n+1 times (where n = an integer value for the number of tunnel layers that exist for connections and data transmissions.))

For an SSH client, you can see that expectations for certain layers seem to be jumbled. Synchronization is happening with file transfers at the TCP/IP Application Layer when it would normally happen at the OSI Session Layer

Session Flow Control is actually taking place in the O.S. at its TCP/IP Transport Layer when it would take place at the OSI Session Layer if it were a true ISO OSI 7-layer Reference Model for Networking.

Even when we discount the bleeding over of expectations within the Forced 7-layer models on the TCP/IP side, we still see the top 3 layers having their parts rolled together in a single monolithic Application Layer on the TCP/IP side of the diagram.

The bleeding over of certain items between OSI Layers forced onto the TCP/IP layers compounded with the existence of many OSI Layers in a single TCP/IP Application Layer protocol leads us to shrug our shoulders in unhappiness. We cannot easily force TCP/IP with its many TCP/IP Application Layer protocols to match up with the ISO OSI 7-layer Networking Reference Model for Networking. What we decide to do, is make breaks in the TCP/IP stack side where we can, which generally correspond to the layers on the OSI side.

(If you want a more complete list of the parts of SSH then you can review the out of date (expired) drafts for the various parts of the SSH protocol.)

From this, we decide to group the OSI Application Layer, OSI Presentation Layer, and OSI Session Layer into one monolithic TCP/IP Application Layer.

Look again at the diagram with the TCP/IP stack on the far left, and the OSI stack on the far right: (included down below here again to avoid scrolling)

5 Layer TCP/IP Model vs. ISO OSI 7 Layer Reference Model
5
Application-
< -------End--------to--------End------- >
Application-
7
< -------End--------to--------End------- >
Presentation
6
< -------End--------to--------End------- >
--Session---
5
4
-Transport--
< -------End--------to--------End------- >
-Transport--
4
3
--Network---
< -- >
--Network---
< -- >
--Network---
< -- >
--Network---
3
2
-Data Link--
< -- >
-DLL-
--
-DLL-
< -- >
-DLL-
--
-DLL-
< -- >
-Data Link--
2
1
--Physical--
< == >
-PHY-
--
-PHY-
< == >
-PHY-
--
-PHY-
< == >
--Physical--
1
L
Stack Num 1
Link
Stack Num 2
Link
Stack Num 3
Link
Stack Num 4
L
Key:
< == >
Is a physical wire or media connecting devices
< -- >
This is a virtual path for peer level, layered protocol communications. Follow the GREEN colored layers, up and down any touching green stacks, and across physical links.
----
Where two or more "-" characters exist in a string, alone in a cell special meaning is implied. This is meant to show that data does not physically pass within the stack shown across this path, even though the data "virtually" passes through this point when viewing the peer layer stacks from an "End-to-end" vs. "chained" perspective.
-DLL-
Another way for referring to the Data Link Layer.
-PHY-
This is another way for referring to the PHYsical Layer.
GREEN
This identifies the path that data actually flows, in a trip down the layers, across the physical layers, up to the RED colored layer where it is analyzed and sent on down to another physical layer, and over through the same layers, and is passed on down again, and across a third physical link to the destination, and up its layers.
R E D
Shows the numbered layers where a chained communications for peer level protocols on original source to final destination take place. (By chained communication, you see that peer layer protocols must communicate through partial stacks for network devices before getting to final destination.)

You can see that our stack on the left attempts to show that the top three layers on the OSI model from the far right stack are mapped to the single monolithic TCP/IP Application Layer.

Now let us examine the Transport Layers of both sides:

On the TCP/IP side, UDP and TCP are considered to be part of the Transport Layer. (An examination of what information is included in TCP and UDP packets can be found later in the main document. To avoid double-statement of information, only generalizations of these protocols including the review of the Network Layer's IP and ICMP will be used.)

All of the above correspond to many of the requirements of the OSI Transport Layer so we can say that it is a pretty good mapping, and our diagram above shows that. There is a bit of bleed over for requirements in the session layer since sequence numbers, and port values can help to allow the O.S. to keep track of sessions, but most of the TCP and UDP functions and specifications map to the OSI Transport Layer.

Comments and/or suggestions for this?: Email me at: dugan@passwall.com
Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.
Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.
Copyright (C) 1999, 2000, 2001, 2002 by Michael Egan: All rights reserved.
A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.
In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.