Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!cheetah.nyser.net!mrose
From: mrose@cheetah.nyser.net (Marshall Rose)
Newsgroups: comp.protocols.iso
Subject: Re: CONS / CLNS interworking
Message-ID: <7843.613029179@cheetah.nyser.net>
Date: 5 Jun 89 05:52:59 GMT
References: <11963@bcsaic.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: iso@sri-nic.ARPA
Organization: The Internet
Lines: 78

For the full details of transport-layer bridging, you might want to take
a look at "The Open Book" a book that I'm doing on OSI for Prentice-Hall.
It should be available by October of this year (it's already written,
copy-editing starts tomorrow!).  The ISBN is 0-13-643-016-3.  (Yes, its a
shameful plug, but I don't have the time to go into the full details.)

In a nutshell:  

1. An application asks the directory to map an application entity title
into a presentation address.  The paddr goes down the stack and the
taddr ultimately hits the transport layer.  At this point, you have tsel
(0..n octets) and one or more naddrs.

2. for each network address, the transport determines how it might form
a connection to that address.  This means that it selects transport
protocol and network service (TP0..4; CONS or CLNS).  this is a local matter.

3. it then orders these addresses in preference of use.  this is a local
matter.

4. it then tries each address to get a connection, invoking the
appropriate transport protocol and network service.  as soon as one
connection is established, it breaks out of the loop.

So, the question is: at step 2, if the transport provider determines
that it can not use any of the addresses, e.g., it has only a CLNS
available and all the network addresses it is given imply a CONS, what
happens?  In the traditional model, the transport layer gives up, saying
that interworking isn't possible.

In the bridge model, if no usable network address are found, then the
transport layer sees if it knows about a TS-bridge that can service one
of the network addresses.  If not, give up.  If so, a new transport
address is formed: the network address contains the network address of
the bridge, the transport selector encodes both the original transport
selector and the desired network address (the one the initiating
end-system could not deal with).

Because not all transport protocols allow exchange of user data during
connection establishment, the transport selector is used to encode the
actual transport address.  This mapping is pretty easy, Steve Kille
wrote a technical report at UCL describing a general way for encoding
OSI addresses as strings.  A copy of Steve's paper is in the ISODE
documentation set.

Performance will never be as good as a straight connection but can come
pretty close, depending on the latency and throughput characteristics of
the net.  On the down side, you have to regenerate checksums at the
bridge (either in the CONS or in the TP4).  On the plus side, in some
circumstances pipelining in the network will hide this cost.

As long as you have two fundamentally different models of the network
layer (CONS/CLNS), you will always run into interworking problems like
this.  Solutions which avoid level-4 relaying usually involve some very
hairy work at the network layer or mandate the use of a particular
transport protocol by both sides.  This is either technically complex or
politically unacceptable.  The advantage of a level-4 relaying approach
is that it is simple and places few restrictions on either end-system.
The only invasive change is the mapping step in transport.  It turns out
that if you are using a local directory (rather than the OSI directory),
you can fudge this in the directory and never touch your transport code.
Since editing tables is usually easier than editing code, there are
proponents of this.

There are, of course, disadvantages:

	- single point of failure
	- end-to-end integrity might be compromised in theory
	  (in practice, no way!)
	- thwarts end-to-end security
	- performance may oscilliate initially
	- you have to deal with addresses some how

Of course, in the Internet suite of protocols, the use of a single
network service avoids all this problems entirely.  I bet the TCP gurus
reading this list are having a huge laugh over this one...

/mtr