🚀 go-pugleaf

>>From: mrose@cheetah.nyser.net (Marshall Rose)
>Newsgroups: comp.protocols.iso
>Subject: Re: CONS / CLNS interworking
>Message-ID: <25317.612334550@cheetah.nyser.net>

>Keith - 

>...
>The idea here is that you can take any two transport stacks each offering
>the OSI transport service and bridge them together.  Further, the complexity
>of doing so:

>	1. Involves no new protocols
>	2. Involves only modest (if any) changes at the initiating end
>	3. Is no more complex than adding a new transport stack to an
>	   implementation--i.e., the bridging quite literally comes for
>	   free, all the cost is simply in building the transport stack
>...
>/mtr

The concept of a transport bridge is relatively new to me and
I am not sure if I really understand it.
Addressing in particular, (Marshall's second point) is what I like 
to better understand.
Marshall will you please expand on that second point. 
What is the impact of TS-Bridge as viewed by the initiator?

Would some of the people who do understand TS-Bridgess please
walk through the next few lines with me and tell me if I more or less
have got it or am far off. 

To remain pure and faithful to the subject we are discussing, 
let's take the case of a Transport Class 4 User (TU4)
who wants to communicate with a Transport Class 0 User (TU0).

The following picture demonstrate a simple scenario for usage of TS-BRIDGE.

   ----------			-----------------------		-----------
   |        |                   |                     |         |         |
   | T U 0  |                   |  T S - B R I D G E  |         |  T U 4  |
   |        |                   |                     |         |         |
   ----------			-----------------------		-----------
        |                           |            |                   |
        X (1)                       X (2)        X (3)               X (4)	
        |                           |            |                   |
    ---------                   ---------     ---------         -----------
    |	    |			|	|     |	      |		|	  |
    | T P 0 |                   | T P 0 |     | T P 4 |         | T P 4   |
    |	    |			|	|     |	      |		|	  |
    ---------                   ---------     ---------         -----------
        |                           |            |                   |
        X (5)                       X (6)        X (7)               X (8)	
        |                           |            |                   |
    ---------                   ---------     ---------         -----------
    |	    |			|	|     |	      |		|	  |
    | CONP  |                   | CONP  |     | CLNP  |         | CLNP    |
    |	    |			|	|     |	      |		|	  |
    ---------                   ---------     ---------         -----------
	|                           |             |                  |
	|      CO-SubNet	    |             |    CL-SunNet     |
	-----------------------------		  --------------------

 (1) = TU0-TSAP-SEL, (5)	/* TU0 , TSAP-Address */
 (2) = TBU0-TSAP-SEL, (6)	/* TS-Bridge-TP0. TSAP-Address */
 (3) = TBU4-TSAP-SEL, (7)	/* TS-Bridge-TP4. TSAP-Address */
 (4) = TU4-TSAP-SEL, (8)	/* TU4 , TSAP-Address */

 (5) = T0-X25-NSAP-ADDRESS
 (6) = TB0-X25-NSAP-ADDRESS
 (7) = TB4-CLNP-NSAP-ADDRESS
 (8) = T4-CLNP-NSAP-ADDRESS

TU4, looks up the TSAP-Address of TU0 ((1)) in some directory, it discovers
that it is only accessible through TS-BRIDGE ((3)). TU4 issues a conReq
with called tsapAddress of (3). TS-BRIDGE gets conInd,
figures out (May be through the same directory that TU4 used to get (3))
that TBU4-TSAP-SEL maps to (1).
TS-BRIDGE issues a conReq on (2) with tsapAddress of (1).
TU0 gets the indication , responds which then gets forwarded to TU4
and they connect.

Data transfer phase is probably very implementation specific.
The obvious seems to be taking advantage of optimal TPDU sizes
while maintaining TSDU boundaries. The bridge computes checksums twice.

The above, assumed transfer of no user data in any of the connect primitives.
Address mapping was through the use of 	TSAP-Selectors of the TS-Bridge onto
called TSAP-Addresses. If one was to make the existance of the TS-Bridge
totally transparent, this seems to be the only choice.

On the other hand if through some type of an agreement, TU4 could 
transfer the destination TSAP-Address to the TS-Bridge, less layer 4
routing knowledge would be expected of TU4. (still ugly but may be less).

I have a number of questions and comments.
	-Have I got it. Is this model more or less appropriate?
	-It seems to me that if there were some generally agreed upon
	 conventions for transfer of user data during the connection 
	 establishment phase, usage of TS-bridges can be made more practical.
	 Any ideas on that?
	-What sort of performance penalties should one expect?
	 Is there any real performance data available on any TS-Bridges?
        -TS-Bridge is obviously a practical present solution for certain
	 situations. Ideally speaking, relaying is not the responsibility
	 of transport layer. To allow for access to both CO Networks and
	 CL Networks what other alternatives are there?
	 At one time I was considering viewing CLNS as CONS by simply 
	 faking the connection primitives (reverse of typical SNDCFs)
	 by a thin layer above CLNS. Then if one was to implement full
	 transport (all classes) on top of both network services,
	 then one can talk to any open system. 
	 Is this a reasonable perspective?