sven@osiris.sics.se (Sven Storg{rds) (05/18/89)
Is anybody addressing the problem of interworking between end-systems using the Transport Protocol [ISO 8073] on top of the Connection-Oriented Network Protocol [ISO 8208/8878 (X.25)] and end-systems using [ISO 8073] on top of the Connectionless Network Protocol [ISO 8473]? There has been some papers submitted to ISO/IEC JTC 1/SC6 on this, proposing Interworking Units. But has anybody done some actual experiments (prototype implementations)? Please reply to sven@nexus.se (although sven@sics.se will work too) Sven Storgards Nexus Communications Uppsala, Sweden
zpope@APOLLO.COM (05/19/89)
I would also be interested in this information.
Bill Pope
------------------
Is anybody addressing the problem of interworking between
end-systems using the Transport Protocol [ISO 8073] on
top of the Connection-Oriented Network Protocol [ISO
8208/8878 (X.25)] and end-systems using [ISO 8073] on top
of the Connectionless Network Protocol [ISO 8473]?
There has been some papers submitted to ISO/IEC JTC 1/SC6
on this, proposing Interworking Units. But has anybody
done some actual experiments (prototype implementations)?
Please reply to sven@nexus.se (although sven@sics.se will
work too)
++------------------------------------------------------------------------------++
Bill Z. Pope Phone: (508) 256-6600
ARPA: zpope@apollo.com Apollo Computer
UUCP: uunet!mit-eddie!apollo!zpope Somewhere in Massachusetts
-------mrose@cheetah.nyser.net (Marshall Rose) (05/19/89)
In February of last year the Wollongong Group built a transport service bridge which allows OSI applications to interwork between CO-mode and CL-mode networks. For example, you can have a FTAM running on a host with TP4 / CLNP talk to an FTAM running on another host with TP0 / X.25. This is also used for bridging into TCP/IP-based internets, i.e., RFC1006 / TCP. The key aspect of this approach is that it requires only a very modest change to the initiator to "know" about the bridge, and no changes to the responder. In terms of protocol changes, there are none. I know of at least three implementations of the TS bridge now (the others are in France and the UK), and it is generally viewed as a terrible idea (being level-4 relay) yet is quite successful since no other solution works, period. I'd like to take credit for inventing the TS bridge, but Steve Kille of University College London and Christian Huitema of INRIA proposed such a box back in November of 1987. I was the first to implement it though... /mtr
tozz@hpindda.HP.COM (Bob Tausworthe) (05/20/89)
/ hpindda:comp.protocols.iso / sven@osiris.sics.se (Sven Storg{rds) / 3:39 am May 18, 1989 /
>Is anybody addressing the problem of interworking between
>end-systems using the Transport Protocol [ISO 8073] on
>top of the Connection-Oriented Network Protocol [ISO
>8208/8878 (X.25)] and end-systems using [ISO 8073] on top
>of the Connectionless Network Protocol [ISO 8473]?
>
>There has been some papers submitted to ISO/IEC JTC 1/SC6
>on this, proposing Interworking Units. But has anybody
>done some actual experiments (prototype implementations)?
>
>Please reply to sven@nexus.se (although sven@sics.se will
>work too)
I've only heard of a couple. Marben in France claims to
have an MSDSG implementation. The Wollangong group in
USA also claims that their transport bridge, when incorporated
onto their OSI and TCP stack implemenations may be used as
an interworking unit (although see the previous discussion
between myself and Dave Crocker on IP-CLNP interworking in this
notesgroup). I have also heard that Retix (USA) also has
something, but this is unconfirmed.
Maybe you can post a list of the responses you receive once they
all come in.
>Sven Storgards
>Nexus Communications
>Uppsala, Sweden
----------
Bob Tausworthe
Hewlett Packard
tozz@hpda.hp.comkeef@.oasis.icl.stc.co.uk (Keith Weir) (05/24/89)
From article <8437.611538221@cheetah.nyser.net>, by mrose@cheetah.nyser.net (Marshall Rose): > In February of last year the Wollongong Group built a transport service > bridge which allows OSI applications to interwork between CO-mode and CL-mode > networks. [... deleted ...] At the beginning of 1985 International Computers Ltd. (UK) installed, and successfully benchmarked a TP4 to TP3 (CL-CO) transport relay for the DHSS here in the UK. This product has since been extended to cover TP4 to TP3,2,0, and TP4 to raw X.25 PLP. It is commercially available as OSG/MCU1. It is mainly used to provide high speed X.25 connection to multiple mainframes accross the LAN. > > I'd like to take credit for inventing the TS bridge, but Steve Kille of > University College London and Christian Huitema of INRIA proposed such a > box back in November of 1987. I was the first to implement it though... > Pre 1985?? :-) Regards Keith ------------------------------------------------------------------------ Keith Weir Mail: keef@vespa.oasis.icl.stc.co.uk International Computers Ltd. Fax: +44 344 487832 Lovelace Road, Bracknell Tel: +44 344 424842 xn 3048 BERKSHIRE RG12 4SN ENGLAND
mrose@cheetah.nyser.net (Marshall Rose) (05/28/89)
Keith - Perhaps we are not talking about the same thing? The transport service bridge I am referring to is generic: you can bridge any two of: tp4/clnp/(802 or x.25) tp0/x.25 rfc1006/tcp and presumably tp1-3/x.25 (which I haven't done since I don't have a tp1-3 implementation.) 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 Thus, if someone were to define a way of offering the OSI transport service over, say, SNA. Then you could drop a transport service bridge over this and have OSI applications running in an SNA-backbone interwork with OSI applications running in some other environment, such as the International X.25 network or the Internet. But, I did not mean to imply in my message that other transport connects had not been built prior to the transport service bridge. /mtr
mbanan@bcsaic.UUCP (Mohsen Banan) (05/31/89)
>>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?
mrose@cheetah.nyser.net (Marshall Rose) (06/05/89)
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
balavi@pbhyg.UUCP (06/12/89)
In article <7843.613029179@cheetah.nyser.net> you write: >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: > Thank you very much for posting this, and your direct mail to me in response to my request. --- __ Disclaimer & Copyright 1989 __ Behzad Alavi ...!pacbell!pbhyg!balavi / ) / / / ) /) 2600 Camino Ramon, 3N904 /--< _ /--, -, __) __/ /__/ // __) . San Ramon, Ca. 94583 /___/_(/_/ /___/__(_/__(_/ / /_(/_(_/___\/__/ (415) 823-3053 V3R1