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:

On the other hand, the TCP camp also has a phrase for OSI people. There are lots of phrases. My favorite is `nitwit' -- and the rationale is the Internet philosophy has always been you have extremely bright, non-partisan researchers look at a topic, do world-class research, do several competing implementations, have a bake-off, determine what works best, write it down and make that the standard.

The OSI view is entirely opposite. You take written contributions from a much larger community, you put the contributions in a room of committee people with, quite honestly, vast political differences and all with their own political axes to grind, and four years later you get something out, usually without it ever having been implemented once.

So the Internet perspective is implement it, make it work well, then write it down, whereas the OSI perspective is to agree on it, write it down, circulate it a lot and now we'll see if anyone can implement it after it's an international standard and every vendor in the world is committed to it. One of those processes is backwards, and I don't think it takes a Lucasian professor of physics at Oxford to figure out which.

-- Marshall Rose, "The Pied Piper of OSI"

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:

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.)

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.

SSH Related documents: Expired Draft Proposals: (For those that may want to have a deeper understanding of how SSH can be used)
• draft-ietf-secsh-EXPIRED.txt
• draft-ietf-secsh-architecture-04.txt
• draft-ietf-secsh-auth-kbdinteract-00.txt
• draft-ietf-secsh-connect-06.txt
• draft-ietf-secsh-transport-06.txt
• draft-ietf-secsh-userauth-06.txt

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.)

• File Transfers (OSI Application Layer)
  • Z-modem uploads and downloads may take place over a pre-existing SSH Session
  • "SCP" may be used to create a new session for transferring files
• Terminal Display and control like vt100: (OSI Application Layer)
  • Terminal Display Settings are not specified in the document to ensure proper terminal character display. However, most SSH client for Windows machines will offer vt100, and vt220 support as part of the Application. For UNIX Systems, support for terminal types like vt100 and vt200 is also done, but not in exactly the same way.
  • An example of an obvious Application Layer item within the SSH protocol may be seen in the SSH_CMSG_WINDOW_SIZE. From this the variable "row, col, xpixel, ypixel" may be passed to describe the window size. Obviously, terminal display such as the size of a window would be an Application Layer issue. There are many examples that can be found withing the specs for the (out of date draft) specifications for SSH.
• Encryption (translation) of data (OSI Presentation Layer)
  • Many SSH Clients offer many types of encryption algorithms like: no encryption, IDEA is CFB mode, DES is CBC mode, 3DES in CBC mode , RC4 , and room to expand to include Blowfish and other new encryption algorithms.
  • Encryption is supposed to be part of the Presentation Layer, since it is a form of character translation.
  • Compression is also something that is possible for SSH as an optional feature. SSH is supposed to be an application layer protocol, but compression is reserved by the 7-layer model for use at the Presentation Layer.
• Session creation and tear-down (OSI Session Layer)
  • SSH is prompted to create and tear down session as requested through the application that is running. As the use chooses to connect to a site, a session must be created. When the user is not interested in remaining connected, then the session must be destroyed as the user logs out.
  • For a lack of location, I have placed X11, and the "port forwarding" capabilities in the Session Layer for SSH in this paper. When you think of it, port forwarding must have access to the port numbers being forwarded. Technically, port numbers for the TCP/IP suite take place at the same level as TCP and UDP. TCP and UDP occupy the Transport Layer. X11 based forwarding requires knowledge of environmental variables read from the user environment at the Application Layer. Choice for the location of the "port forwarding" and X11 is difficult when we try to look at the 7-layer model. The Session Layer makes the most sense to me, but if you have other thoughts, send me an e-mail. New sessions may be created and destroyed as needed when forwarding is taking place. Since session creation and destruction is at the heart of the forwarding, and it requires Application Layer as well as Transport Layer resources, is makes the most sense to remain here IMHO.
• Checksums (OSI Session Layer)
  • Checksums are also included to ensure the data that is transmitted is the same as the data received. This is also a Session Layer issue. (I need to verify that checksuming is performed in SSH. I will look at this later.)
• Synchronization (OSI Session Layer)
  • As a file is being transferred with a Z-Modem transfer in the OSI Application Layer, synchronization is occurring at the OSI Application Layer when it should be taking place here!
  • Z-Modem transfers have the ability with use of checksums (also being done at the OSI Application Layer) to ensure that the data coming through for a transferred file is what was transmitted. Also, if a transfer is interrupted, Z-Modem transfers have the ability to resume where they left off.
• Tokenizing/Speaking staff control (OSI Session Layer)
  • The operating system controls this action. The Operating System ensures that the streams of data get temporarily paused if something else needs to be transmitted that must use the same resource, and that resource use is not sharable. It is the Operating System that make sure the session started with MY SSH client gets the data for its session. (Need to come up with examples and verify)
  • The applications on a pre-emptive multitasking system usually do not get to have control over when they are allowed to speak, and receive. A O.S.(kernel and supporting daemons) often, controls their access to data streams. In this way, an application may keep track of a session it is trying to keep going, but it does not actually control the flow of data into and out of the session. For TCP/IP suite this control is given to the OS, and happens at a lower layer like maybe the TCP/IP Suite Transport Layer, but not in the TCP/IP Session Layer.

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)

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.)

UDP and TCP (TCP/IP Transport Layer)
• Flow control exists in the TCP protocol
  • TCP uses a "Maximum Window Size" with its sliding window protocol for transmission of data. A sender may only transmit up to the size of the Maximum Windows Size before it must wait for the ACKnowledgments from the receiver.
  • TCP also uses
• Data from the TCP/IP Application Layer needing to be transmitted may be larger than the largest allowed packet size by TCP. TCP and UDP can both resize incoming data from higher layers. They do this by chopping the incoming data from above to fit within valid packets. The peer level layer on the remote TCP/IP stack extracts the data and connects the data to make a single stream of data. This stream can appear to the receiver as a larger single chunk of data: a chunk of data larger than could be carried in a valid TCP or UUDP packet as payload.
• TCP keeps track of connections in progress that are taking place and has within it the ability to let the Operating System direct the TCP packets to the Applications that need them.
• TCP is the TCP/IP suite TCP/IP Transport Layer protocol that is responsible for creating reliable connections. UDP is for unreliable connections. (Use for unreliable connections is explained in the examination of UDP packet headers.)
• Sequence control takes place in both TCP and UDP to ensure payloads are assembled for being relayed to the TCP/IP Application Layer in the same order they were originally transmitted. (This is done with sequence numbers that will be explained later in the analysis of TCP and UDP headers.)

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.

IP and ICMP (TCP/IP Network Layer)
• (Mmmmmmm Must sleep now.)
• (Must take a break from this... I will be back later to do more work.)

Ethernet (One example of a Data Link Layer protocl that may carry a TCP/IP suite of protocols.)

Wires (or wireless radio are examples of a Physcial Layer system)

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.