Xref: utzoo comp.dcom.lans:1629 comp.protocols.tcp-ip:4211 comp.protocols.iso:131
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
Message-ID: <1116@nusdhub.UUCP>
Date: 27 Jul 88 18:02:48 GMT
References: <61066@sun.uucp>
Organization: National University, San Diego
Lines: 155

I am begining to suspect that I am exchanging POV with more than one
other individual.

For clarity, the thread to date is based on one posters lament about how
dificult it was (for him) to write a TCP/IP interface which runs under
TLI.  Please re-read this sentince about a millino times--or at least until
it soaks in throughly--before proceeding.

Either that, or the postings are not being read, they are being "sampled."

Similarly, you should at _least_ include the *entire* sentince on which
you comment.  Other wise all you are doing is foistering you on distortions
of meaning on the readers.  A prepositional phrase, or dependant clause
all by itself does not an idea express...


in article <61066@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) says:
> Xref: nusdhub comp.dcom.lans:370 comp.protocols.tcp-ip:1132 comp.protocols.iso:52
> 
>> The fact that all you have ever seen of TCP/IP drivers written as
>> TLI conformant functions pass the four byte addresses as actual
>> bytes instead of a string like "109.90.42.6" is simply sad.
> Excuse me, but this is nonsense; the difference between "actual bytes" and
> "109.90.42.6" is trivial relative to the difference between "sun.com" and
> "10.7.0.2".  If TLI forced me to pass a string like "109.90.42.6" to it, that
> would be every bit as sad as if it forced me to pass that address down in
> binary form.

True; I do understand that.  This relates bact, however, to the "lament"
that TLI (e.g. AT&T) did not spesify a "universal structure"  (read to mean
memory structure as in C or assem) which would interface to *every* kind
of underlying protocol. (and went on to name: X.25, SNA, URP, TCP/IP [sic]
and a couple of ones I didn't know)  Put simply, such a structure would
be preposterous and unworkable, therefore the "structure" stteled on was
the "string."  (e.g. a netbuf structure filled with an "arbitrary" string
of characters meaningful to the application and the TLI driver.)

To this end, what I wrote was *exactly* as menaingful as I intended.
We have laready been through the:  "But my address is 198.3.54.6 and
not nusdhub.serve, so whay should I pass the latter" argument.  I
therefore, used the "addressing scheme" of choice (to my audience).

>> In essence this breaks the aledged uniformity.  To implement the
>> TCP/IP and TLI over the same media,
> You don't "implement TLI over a medium".  TLI/TPI is, in effect, an *interface*
> that "transport providers" implement.  You implement a "TLI/TPI-conformant TCP"
> or a "TLI/TPI-conformant UDP" or a "TLI/TPI-conformant ISO TP4" or a "TLI-TPI
> conformant XNS SPP" or....

To this I must simply reply: "READ THE SPECS!"

TLI may be implemented OVER *ANYTHING*;  I even went so far as to explain
that I was using the -loose- *ENGLISH* version of the word 'MEDIA.'  To
whit you may (were you to desire to) implement the following:  TLI _over_
verification suit _over_ X.25 _over_ normal tty driver _over_ physical
port _contected to_ a modem _connected to_ Tymenet.  You may also make
A TLI module which you may push above a TCP/IP endpoint to make the
afore-mentioned TCP/IP driver-tree a "TLI CONFORMANT 'PROVIDER'": which
is ALL the specs require of you.

>> the primitive kernel driver should be TCP/IP, and then a streams module
>> which can convert TLI requests into TCP/IP should be written.
> No, you implement a driver that provides the TCP or UDP protocol and that
> conforms to the requirements of TPI and TLI.  That driver is what "converts
> TPI/TLI requests into TCP".

I KNOW the way is should be done when you have no other constraints.
What I described conforms to the constraints provided.  READ THE THREAD.

Several articles back I went over (with pictures) TCP/IP- and TLI-cloning
drivers over an overseer over a "media"; TLI-cloning driver over TCP/IP
driver over "media"; et al ad nausium...  Check your archive.

>> TCP/IP _is more_ complex, and therefore, to implement both TLI should be an
>> optional addition onto the TCP/IP.
> TCP and TLI are completely different types of things, so it's hard to say one
> is "more complex" than the other, except to say "TLI supports functions TCP
> doesn't provide" (which is true) or "TCP provides functions TLI doesn't
> support" (which is also true).

No kidding???!!!???  Of course they are, but the basis of all this was
someone who wanted to implement TCP/IP *over* TLI (patently dumb)
and the waters you just re-muddied were almost clear.

>> Then you place 109.90.42.6 in your Systems file;
> 
> I refuse to put something as gross as "109.90.42.6" into any configuration file
> for a network utility; if I can't put the *name* of the machine there, that's
> unacceptable.  There are, I believe, many *thousands* of hosts on the DARPA
> Internet; I know there are thousands of hosts on Sun's network.  Sometimes
> hosts may change their addresses but not their names.  Administering a network
> of that size by using addresses rather than names would simply be impractical.

Yes, I know about address names, verses real addresses.  I am trying to
keep the examples simple and well defined.

Once again, If you simply say:  "But I'll just throw away my spesifications
and the desire of my employer and do it this way" all sorts of things become
a lot easier.  Similarly, if you just say:  "This example is to basic, it
allows someone form another environment to _understand_ so I better
re-muck it up"  you can justify all sorts of "better" things to say.

The spesific issue *WAS* using the four byte address (c.f. to string
or to structure) and my use of uucp as an example was to keep things
both (1) on track to my audience, and (2) simple and aimed at my audience.

>> The simple task of converting the string to the 4-byte couplet
>> is not beyond the scope of a STREAMS module,
> No, but it's not very useful, either.  What you *really* want is a mechanism
> that can convert what you might call a "service specification" (i.e., "UUCP on
> host 'sun.com' over TCP") into an address in whatever form the protocol
> requires.  UUCP (which, I infer from your mention of a "Systems" file, is the
> service to which you're referring here) would then ask for that service, and
> hand *that* to TLI.

I don't know weather you have read the specs for UUCP as relates to
a TLI conformant provider.

>> All of this is much the purpose of the "adm" program which assembles
>> the STREAMS modules which eventually make /dev/starlan operate
>> the STARLAN product.  I would assume the correct "adm" program
>> for an ethernet and/or internet support would activate two STREAMS
>> multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.
> Are you actually familiar with TCP or IP, or is your only TLI/TPI experience
> with, e.g., STARLAN?  If you haven't worked with TCP, you should probably study
> up on it first, and preferably on TLI-conformant TCP implementations, so you
> can discuss implementations of things other than STARLAN meaningfully, and
> support for multiple protocols in general, meaningfully.  If all you know is
> STARLAN, you're unlikely to know what's involved in protocol independence....

No, I am not farmilliar with the internal details of TCP/IP;  my question
about TCP/IP is mostly how this thread got started.  As far as TLI is
concerned, I have been through the "porting rules" doccument--which
contains a description of *all* of the STREAMS requirements and
functional spesifications necessary to make any STREAM represent a
'TLI conformant provider'  (this includes state and precidence tables)--
and know exactly what is and is not required of a system for it to be
TLI conformant.

The essence of the discusion is:

(1) Q: What structure should be passed to TLI?  A: A "human readable"
	string.

(2) Q: How can I [sic] implement a TCP/IP interface over a TLI network?
	A:  You can't; you don't want to; the whole point of TLI is
		to allow/create a "simple and uniform" interface
		which will work with any provider.

(3) Q: How am I supposed to do address translation under TLI?
	A:  You don't; the driver writer has built the soft-to-
		hard address translation into the driver (if it
		is in fact conformant).


Rob.