Xref: utzoo comp.dcom.lans:1584 comp.protocols.tcp-ip:4102 comp.protocols.iso:119
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!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: <1104@nusdhub.UUCP>
Date: 15 Jul 88 22:54:02 GMT
References: <666@cbnews.ATT.COM>
Organization: National University, San Diego
Lines: 127

in article <666@cbnews.ATT.COM>, mark@cbnews.ATT.COM (Mark Horton) says:
> Xref: nusdhub comp.dcom.lans:345 comp.protocols.tcp-ip:1043 comp.protocols.iso:42
> 
> I've used TLI too.  What are you describing above?

I begin to think That I don't know enough about TCP/IP to fully understand
what you are exactly trying to accomplish, or its spesific problems/
detils; but here goes...

TLI is (as I deal with it any way) a basic way of providing description
and contlrol of (aledgedly) any transport media.  It's purpose is to
make a through-the-media pipeline through which data may be passed
with total reliability (Session/Virtual circut) or of providing a
method of asserting data on a media with the implicit intent that the
device on the other end is listening for such data, and applications
will handle the details from there.

TCP/IP is a media protocol which involves addressing and connection
metenence.  It is inteneded that other protocols would be implemented
_above_ some or all of TCP/IP.

If my perceptions are correct then trying to write a TCP/IP driver
over a "TLI device" is a non-sequetor.  The order, top to bottom,
of the stream should be: TLI over TCP/IP over STREAMS Device; such
that you have a STREAMS conformant TCP/IP driver for your ethernet
board, and then you push a custom made TLI-to-TCP/IP STREAMS module
on the stream before you hand the connection to a TLI conformant
application.

For instance, with STARLAN on a 3B2 there is the program "pumped"
onto the board, two kernel drivers (NAU and SRM) the 'adm' program
which assembles the STREAM durring startup, hands a hook to the
'listener' and then goes deamon.

Were you to put TCP/IP _above_ the TLI you would already have been
issued the sub device numbers, and already possess the connection
(in remote startup) or be insulated form same (originating a call)

The WHOLE POINT of the TLI is to remove the details of the connection
from the application.  A TLI conformant program only needs know
two or three things; 1) an address in "plain english" (c.f.
something that a user could be prompted for at the keyboard);
2) A service code (If and only if the address can provide more than
one service); and 3) the file-system name of a provider.
The TLI device is "opened" (cloned as necessary); the plain english
address is passented to the driver for translation; the driver
translates this to an address which will be useful to the rest
of the process (whatever that might be!) and returns a pointer
to same if necessary; the user submits a "bind" request by passing
the dirver the above address and the service code (and optional
init data if necessary) and is returned "success" or "failure"
code dependant on wethaer the conection went through (etc.).
After successful compleetion of the connect, the user only
has to provide whatever data, it thinks it wants the other end
to receive, to the TLI and it is received as is at the other end.
Optionally, after successful bind, the user program may
i_push some modules on the stack before useint the connection.

To implement rlogin under TLI you would simply do the following:
write rlog-serve shuch that:
	Accepts first unit as "name"
	uses read()/write() to prompt/deal with password verification.
	{ read() from TLI and write() to shell standin &&
	  read() from standin and write() to TLI}
	close local files
	exit.
write rlogin such that:
	It takes destination machine name as option.
	knows the service code for rlog-serve
	opens provider
	passes TLI the address in a bind request
	on success i_push(es) the read()/write() interface on the
		STREAM (I forget the name, but you get it free)
	{ read() form stdin and write() to TLI  &&
	  read() from TLI and write() to standout}
	close all files when done
	exit.
Add rlog-serve to the listener database on every machine which
will accept rlogin requests (you need to know the serviec code
to do this.) while you are doing this you record in the database
that the listener should i_push the read()/write() module on
the stream before starting rlog-serve.

If you do the three steps above you have rlogin.  The remote shell
stuff works exactly the same way.  What more do you need?


If you want TCP/IP and TLI stuff on the same media, you would make
a TCP/IP STREAMS deiver for the media.  The program which oversees
the TCP/IP workings establishes a TCP/IP address for the TLI
functions (much like 'adm' on the STARLAN network.) and routes
the TLI functions up through a multiplexing STREAMS driver to
where the TLI stuff can get it's hands on it.  To whit:

Listener	Cloneable Module Hooks
|		|  |  |  |  |  |  |  |  |  |
-+------------------------------------------
 |
TLI to TCP/IP request format translator. {Multiplexing Kernel Module}
	|
	|	TCP/IP Overseer {Deamon} (establishes all this on startup)
	|	Other TCP/IP Entry Pionts
	|	| | | | | | | | | | | | | |
	-+---------------------------------
	 |
	TCP/IP Driver  {Multiplexing Kernel Module}
	Media Driver {Kernel Module}
	Interface {Hardware}

To do it the other way would be a total mess.  It is _expressly_
stated that TLI is a uniform service which 'insulates' the
application form the _media dependant_ details of establishing
and maintaining a connection.  I would assume that there
must therefore be a media dependant protocol on the other
(deeper) end of the module.  It would also seem that this
'other' protocol could be anything! (X.25; TCP/IP; STARLAN;
whatever).

(Or maby not, considering I don't really know the innards
of TCP/IP.  It may also end up that TCP is on the same
level as TLI and that IP may be below both of them equally.
Or TCP and TLI may be available over any media and things
like TCP/STARLAN and TLI/IP may be possible?????????????
I can't really know until I find out more about TCP/IP;
but This is my understanding of all the elements involved.)

Rob.