NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/protocol/tcpip/6144

Text File | 1993-01-28 | 6.6 KB | 120 lines

Newsgroups: comp.protocols.tcp-ip
Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!darwin.sura.net!newsserver.jvnc.net!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!ugle.unit.no!humpty.edb.tih.no!lumina.edb.tih.no!ketil
From: [e-mail] (Ketil Albertsen,TIH)
Subject: Re: Info wanted on TCP/IP vs OSI 7 layer
Message-ID: <[e-mail]>
Sender: [e-mail] (Ketil Albertsen,TIH)
Organization: T I H / T I S I P
References: <[e-mail]> <[e-mail]> <[e-mail]>
Posting-Front-End: Winix Conference v 92.05.15  1.20 (running under MS-Windows)
Date: Thu, 28 Jan 1993 10:16:55 GMT
Lines: 107

In article <[e-mail]>, [e-mail] writes:

>> Almost any computer networks textbook will spend a page or two stating
>> that TCP corresponds to OSI Transport, IP to OSI net, but IP is
>> connectionless while OSI is CO. That's about it - sometimes I wonder
>> how they can spend several pages saying nothing more.
>
>Where did you get the idea that the OSI reference model cares whether the
>network layer runs CONS or CLNP?

Evidence 1: The real world. The vast majority of networks following OSI
standards do run CONS. To put it squarely: They run X.25, which is CONS.
(ISDN will come in a few years, which is even more CONS.)

Evidence 2: While a CLNS was into earlier OSI documents, it has actually
been out for a few years! I haven't seen the '92 CCITT documents yet,
so it may have a decent treatment now. The preliminary copy I've got of
ISO 8473-1 (Connectionless-mode network service) states that the text is
also published as X.233, but there was no X.233 in the bluebooks (1988).

So, in the finer details, it is not strictly correct that "OSI is CO".
But as a first, general statement for people who want an introduction to
the difference between OSI and Internet protocols, it is a very good
starting point. Eg, is there *any* OSI *applications* that actually uses
connectionless mode? (Note that I was careful to state 'OSI is CO' in
a general sense, not associating it to the net layer in particular).
Actually, I have never seen the connectionless Transport service spec,
although I have heard of its existence. I don't know if there is any
CL Session service spec, or a CL Presentation service spec.

In essence, those fighting for CLTS want it for running their non-OSI
Internet applications.

Besides, I didn't intend, in my original statement, to make any blunt
statements about the OSI RM - I was referring to networking textbooks,
in general! (I could dig up a few examples to support it).

Besides 2: I consider IP an internet *Protocol*, not a net *Service*. If
we are to discuss the finer details of the OSI RM, IP is most certainly
not a CLNS, it is a CLNP. You may (but I am not seriously suggesting it!)
run CONS realized by a CLNP such as IP.

>While there are LOTS of ISO standards that fit in the OSI model, the OSI model
>is just that. It describes what each layer does as a general function, not
>specific. IP does fit into the OSI model at the network layer. It only lack
>blessings as an OSI standard. TCP fits into the transport layer the same way.
>(As do the ISO/CCITT approved TP0, TP1, TP2, TP3, and TP4.)

While I certainly agree with the main spirit of this statement, I think you
should pick up X.200 (or its ISO equivalent) and see which responsibilities
the OSI RM put on the NE and the TE. Too bad I've left my X.200 at home
today, or I would have quoted it. You will find that most (although not
all) of what TCP does is something primarily assigned to th NE.
A lot (although not all) of what IP does is something primarily assigned
to the Link Entity. On the general level, there is very little difference
between running OSI TP on a middle-of-the-road OSI NS (such as X.213 NS
using X.223 mapping to X.25), or on TCP; you get essentially the same service.

The one that does not fit into the OSI RM is TP4; it simply assumes that the
NE does *not* do what it is supposed to according to X.200. I have a
definite impression that TP4 was included with the sole purpose of "selling"
OSI to the IP camp. IMHO, TP4 should never have been included. It is OK
to run OSI over IP, but then a proper NS mapping (analogous to X.223, but
certainly very different) should  be defined rather than pushing
NE responsibilities over to the TE!

This "TCP = OSI TS, IP = OSI Net" is a very widespread misconception that
I have never seen backed up by a feature-by-feature analysis of the two.

>Somewhere the idea has been popularized that OSI means interoperability in some
>way. Not so. That requires systems to run matching OSI profiles, like US GOSIP
>or UK GOSIP (or both). Otherwise you will get a system running TP0 and TP2
>trying to talk to one running TP4 with no success.

As long as we keep the non-OSI-spirit TP4 out of it, it is much simpler.
Fallback to TP0 is defined as part of the connect procedure. For
interconnection of different net level protocols, an architecture is
defined ("Internal organization of the Network layer") that is supposed
to allow eg. a CLNP hop in a net providing a CONS, but hide it from the
end service interface. As soon as people start implementing these standards
rather than fighting them, things will become much easier... :-)

>To go a step further, there is nothing that prevents running the upper OSI
>level over TCP/IP. See RFC1006, and ISODE.

RFC1006 is a starting point. But it does not provide the full service, TP0
only. Which means eg. that there is no true support for expedited data.
(According to the letter of the standard: Good enough, according to the
spirit: Eeeeh, well...). I will consider 1006 a workable interim solution,
but not a permanent one. A better permanent solution would be to run TCP
as a net service provider, although the egos of the people in the Internet
camp would be seriously injuried if TCP was degraded to Net level...

>And, for that matter, TCP could run on an ISO network protocol such as CLNP.

In principle this is (of course) true. But most programming interfaces to
TCP makes a whole lot of IP itself visible. If all programmers knew that
they should NOT make their software rely on IP being present, fine. But
generally speaking, programmers tend to make maximum use of whatever
functionality provided. You certainly can "prove", in practice, that
TCP-based software CAN run across a non-IP net, but to paraphase
Dijkstra (?): "A demo can prove the presence of problems, not the absence".
Up until now, the syntax for invoking IP functionality has differed. But
adapting to various syntax is much easier than adapting to absence!

Ketil Albertsen.