🚀 go-pugleaf

Bob,

Well, today is Tuesday, so perhaps the clarity of our exchange will
improve.  Then again...

First of all, the diagram in your recent note certainly matches the
one that we produced while I was at Wollongong, describing the TSB.
The three that you had in your original note did not seem to map to
this one, so I thought that you had something else in mind.

Perhaps most of my confusion stems from the reference to IP/CLNP.  The
TSB does not know anything about IP or CLNP and does not see them.  You
are correct that ISODE implements TPO (sorry for my excessive simplification
of omitting the TP0/RFC1006 portions of the stack) and interfaces
to TCP and TP4 (and X.25, ...).  However, it does not know about the
lower layers; hence it does not seem correct to me to refer to it
as CLNP/IP translation.

The distinction might seem like nit-picking, but is not intended to be.
There often is confusion about how the layers interact and how to
do translations between incompatible layers.  My own experience suggests
that painfully careful detail must be maintained in such discussions.

With respect to the TSB, it performs two wonderful functions:  It allows
a TCP-Based host, running an OSI application, to talk with an OSI-based
host, running the SAME application.  Further, it will allow a TP0-based
OSI host to talk to a TP4-based OSI host.

Last item:  The TSB is not an off-the-shelf product.  At the time that
Marshall Rose and I left Wollongong, it had been demonstrated at various
conferences but had not yet received field-testing (alpha or beta), nor
was the documentation written, tho source material prepared for it.  I do
not know what the current release schedule is for it.

Over the year-and-a-half of working with Marshall to develop a coherent
view of TCP/OSI transition and co-existance, I came to believe that a
number of very different technologies would be required.  The TSB is only
one of them.  In a sufficiently constrained operational environment, it
might be the only tool required, along with ISODE-type software on
the end-user TCP hosts.  In most networks, I believe that several other
components will be required.

The CLNP-over-IP encapsulation is likely to be quite signficant to such
other options, since it allows hosts to run dual stack without requiring
the backbone (i.e., routers) to be dual-stack.  The EON (Experimental
OSI Network) effort plans to use this also to get basic field
testing in large networks.

To interwork such hosts with others running in pure OSI networks, you
will need something that Marshall likes to call a Network Tunnel and
I am tempted to call a CLNP-router.  It looks just like an IP Router on
one side and a CLNP router on the other.  Its peculiarity derives from
the fact that the CLNP-router functionality dominates and it views
IP as a link layer...

Dave