🚀 go-pugleaf

>Bob,

>I think that you may be importing too much functionality to the TSB and
>that you may want to use it in some ways that could be better done in other
>ways...

Dave,

I was never arguing what was the best way. A person on the net was interested 
in CLNP<-->IP translation. I was simply desiminating information. 
I was giving him the scoop on what is presently available in the REAL world.
Running IP over CLNP or vice-versa are being done EXPERIMENTALY ONLY. In
fact, RFC 1070 states that very clearly. I won't argue the fact this may
be the direction to take for OSI/ARPA connectivity, however, real-world 
(meaning comercial/government) people using TCP/IP and wanting a way to 
incorporate ISO functionality do not presently have 1070-type functionality 
available to them.

>You cite three situations.  The first has OSI, down to CLNP, running in
>an IP network.  You put in a TSB to allow CLNP to run over OSI Transport
>and then have it translated to run over TCP.  This sounds strange, to say
>the least.  Running CLNP encapsulated over IP, directly, where CLNP views
>IP as a link-level protocol, is far cleaner.

First off, what you have up there does sound strange, to say the least. CLNP over
TP? Don't you mean TP over CLNP? If I make this assumption about what you were
trying to say
    You put in a TSB to allow OSI Transport to run over CLNP [what normally 
    occurs] and then have TCP run over it [it==CLNP???].

Close, but no cigar. A TSB such as Wollangong has produced translates between
IP and CLNP by bridging at the transport layer. So your not putting TCP over
CLNP at all. Maybe the diagrams should have been more explicit. Try
this on for size:

           Node A                         Node B

       OSI Appl.
       Pres
       Sess                         Transport Bridge
       TP                         TP              TCP
       CLNP                       CLNP            IP
        | subnet (802.x, X.25)     |               |
        +--------------------------+               +---------- . . .

In short, the TSB gives you a method to interwork between CLNP and IP. 
If you look at my diagrams in the previous message, you will see that
two TSBs were used: one to convert to TCP/IP, and one to convert back
to TP/CLNP. Or, in the case of ISODE, only one is used (to translate from
TP/CLNP to TP/TCP/IP). In the first case, you aren't using the Transport
functionality, merely the layer 3 interworking functionality. Its in the
second case that you use the Transport functionality.

>The second situation reverses the relationships, to have IP running over
>a CLNP network.  Again, the solution is far cleaner to have IP view CLNP
>as a link protocol and CLNP think that IP is a Transport protocol. 

Yes, but is it available today to a customer? Does IP/CLNP buy you
anything? Only if there are people out there with CLNP networks (and we
know how many of those there are ;-) ) who want to run existing TCP/IP
applications over their CLNP networks. A valid need, but one which may
be solvable by something other than IP/CLNP. IP/CLNP is harder  (read 
"non-cleaner") than you may think, for instance, CLNP has 20-byte
network addresses. Which ARPA routing protocols can support addresses
of this size?

The interesting point is that what you propose is two Subnetwork Dependent
Convergence Protocols: one for CLNP/IP, one for IP/CLNP, both of which have
to be accepted by at least the Internet community (more likely ISO/ANSI X3S3.3..).
Something which would only increase the complexity of the Internet layer (not
to mention Routing), and the internet layer /routing is far too complex already.
The TSB gives both of these abilities in the same package using technology
which exists today.

>not see any benefits of placing TSB-like technology in between and, in fact,
>it does not sound as if it would work.

In fact, it does work and is an existing product marketed by Wollangong.

>Your last scenario uses a TSB to map OSI, down to CLNP, over to OSI, down
>to session, over RFC1006 and IP.  (ISODE only goes down to session.)
>This truly does not compute.

I agree, what you wrote above does not compute. Yes, ISODE sits on top of
transport, yet it incorporates transport as well: TP0 to be precise. The 
way RFC1006 gets ISO applications to run over TCP/IP is to have the stack:
Appl/Pres/Sess/TP0/TCP/IP. Wollangong's TSB cover's this problem so you
can talk "pure" OSI Application to a TCP/IP ISODE OSI Application.

>A rule for determining how/when/where to do conversions:  Create two
>protocol stacks. Look for the highest and lowest points of departure.
>You need to translate in between those points, at the highest level.

Thanks!! ;-) Let me write that one down!

Seriously, the part you left out is that rather than simply looking at
the two stacks, it is sometimes just as important to look at the 
connectivity/topology of the network in question.

>e.g.,

>OSI APPl       TCP APPL
>...            ...


>Means that nothing is in common and you translate above it; i.e., an
>applicatio gateway.

>OSI APPL       OSI APPL
>OSI PRES       OSI PRES
>OSI SESS       OSI SESS  
>OSI TPORT      TCP
>...            ...

whoops!! read the above, those are not ISODE stacks.

>Means that you need to translate at transport level.  This is the exact, and
>only, case that the documented Transport Service Bridge will solve.  To the
>extent that the other scenarios you describe can and should be done, they
>are independent of this particular kind of TSB.  I.e., they are different
>products.

The important point you are forgetting is that TSB's allow more than just
the ability to convert between protocol stacks. They also allow interworking
at the INTERNET layer. They solve much more than just the TCP<-->TP problem.



Sorry if the above discussion sounds somewhat caustic but I got your reply on early
monday morning. I guess the points I was trying to make are:

        1) I'm not supporting one method over the other. I am telling
           what's available to customers TODAY. I will agree to the
           hilt that CLNP/IP is a good way to do this, although its not
           a panacea and is not mature enough to be available to customers. 
           I will argue that IP/CLNP is not as good an idea
           and I hope that we can come up with a better alternative when
           that type of connectivity is required. 
        2) I am clarifying that a TSB gives you more than just conversion
           between layer 4 protocols: it gives you the ability to hook ISO
           nodes into a TCP/IP network TODAY.
        3) I am clarifying the semantic problems in our last discussion.


        
>Dave