Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!ETN-WLV.EATON.COM!mcc
From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Does TCP/IP "comform" to ISO/OSI?
Message-ID: <8809130548.AA12371@ETN-WLV.EATON.COM>
Date: 13 Sep 88 05:48:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 69

Kent:

I must admit I don't really understand what you mean by the phrase "articulated
TCP/IP model" and what value it might have were I to understand it.  That does
not imply that I understand the ISO "Open System Interconnect (OSI) model" nor
the "Digital Communication Architecture (DCA) model" fully.  Although I may
have used concepts outlined in each of these models when developing network
software, my approach is governed by my education received from the "Department
of Intuitive Logic, School of Hard Knocks, University of Experience".  Formally,
I have a degree in the weird (social) science of Economics which is concerned
about the utilization of limited resources which definitely influences my view
of the hows and wherefors of networking.

The two (2) figures, below, might be regarded as my models of networking.  The
one on the left the theoretical model.  The one on the right the practical.

          +--------------------+---+       +------------------------+---+  
          |     Application    | M |       |         Application    | M |  
          +-------------+----+-+ a |       |   +-------------+----+-+ a |  
          | Generic Transport  | n |       |   | Generic Transport  | n | 
          +--------------------+ a |       |   +--------------------+ a | 
          |       Network      | g |       |   |       Network      | g | 
          +--------------------+ e |       |   +--------------------+ e | 
          | Specific Transport | m |       |   | Specific Transport | m | 
          +--------------------+ e |       +------------------------+ e | 
          |      Data Link     | n |       |        Data Link       | n | 
          +--------------------+ t |       +------------------------+ t | 
          |     Physical Link  |   |       |       Physical Link    |   | 
          +--------------------+---+       +------------------------+---+ 

What I understand to be the "session layer" is only an aspect of management
which has access to all "layers".  Without management being vertical, what
happens and what stops the no longer necessary activity when the application,
process, or pseudo-process unceremoniously aborts or "core dumps"?

The figure on the left is for the modular architecture and "black box" crowd
that assume memory is cheap and will be cheaper in the future *and* that
time is no consideration because you can always buy a faster engine.  The
figure on the right is for the practical chaps who realize that money does
have a cost and one *does* get stuck with less than optimal equipment for
both the near and far terms.

The "generic transport layer" may or may not exist; however, it is depicted
here to provide a mapping between the local machines representation and that
which is understood by the "network layer".  Also, the "specific transport
layer" may or may not exist; however, it is depicted here to provide a map-
ping between the "network layer" representation and the data representation
that is required to receive or transmit data over a specific communication
link.

In this model the "network layer" is assumed to have a choice of paths and
networks which can be used to communicate with the distant end; hence, the
need for a "specific transport layer".  It is also assumed that the "network
layer" can perform a store and foreward operation between networks without
involving an application process.

In the right hand figure, the vertical added to the "application layer" allows
one to define an "end node" which is technically compliant to the model with-
out having all of the layers.  It also requires well defined interfaces at
each layer because it implies that the "application layer" can enter the
"protocol stack" at any layer.

It doesn't seem to make much sense to allow the "application layer" to go
down to the "physical link layer"; however, I'm sure that someone can provide
a reason why it would be desirable.

If nothing else, the above figure along with the other models might provide
a way to get to a more robust and practical communications model.

Merton