rzi@sposp1.UUCP (Roman Zielinski) (02/25/90)
???: HOW TO CONNECT TP4 AND TCP/IP NETS :??? ---------------------------------- I need make our Unix-V.2-like 680x0-system network using OSI/TP4 (but not TCP/IP) to support such nice things as: NFS, RFS, TELNET, Rlogin, Remote Proc Call so they can cooperate with another 680x0-systems run under V.3(V.4) supporting TCP/IP (but not TP4). There is another system-family (a 386-based) that fortunately supports both TP4 and TCP. An idea I have, is to add a gateway system converting TP4 <-> TCP, and then write a "black box" leyer between NFS, Telnet, ..., and TP4: +-----+ +--------+ +--------------+ ! NFS !...! Rlogin ! ! NFS...Rlogin ! +-----+---+--------+ +-------------------+ ! ! ! black box appl ! ! Gateway + ! ! ! ! conv TP4/TCP ! ! conv TCP/TP4 ! ! ! +------------------+ +----------+--------+ +--------------+ ! ISO 8073 Cl4 ! ! 8073 Cl4 ! TCP ! ! TCP ! +------------------+ +----------+--------+ +--------------+ ! 'Ethernet' !-------! Eth. ! Eth. !-------! Eth. ! +------------------+ +----------+--------+ +--------------+ system in system in OSI-network Gateway (386) TCP/IP-network Questions: 1. Is it possible to translate TCP/IP <--> ISO8073 Cl4? 2. Is it easy to write a "black-box" and Gateway session layer programs? Or maybe it exists somewhere???? 3. Will NFS, Rlogin,... be satisfied by such an arrangement? Greetings from Sweden having green-house climat! +---------------------------------+-------------------------------------------+ ! Roman M. Zielinski ! <here should be something wise...> ! ! Philips Tele & Data System AB ! <but there is not> ! ! S-115 84 Stockholm, Sweden ! ! ! tel +46 8 782 1373 ! ! ! uunet!mcsun!sunic!sposp1!rzi ! ! +---------------------------------+-------------------------------------------+ Things are always at their best in the beginning. /Pascal
collin@hpindda.HP.COM (Collin Park) (02/28/90)
> 1. Is it possible to translate TCP/IP <--> ISO8073 Cl4? In principle, no: tcp/ip has graceful release whereas 8073 has not. also, 8073 retains record boundaries which tcp does not. However, if your tcp/ip applications don't need graceful release (ftp is a notable exception) then it's probably possible to use the 8073 class 4 to do the data transfer. Even if the application does need graceful release, there may be some klugey way to get around it... For example, if the 8073 class 4 (i'll call it 'tp4' from now on) sends data and then waits for ALL data to be acknowledged before sending the DR TPDU, then the close is 'graceful' from the sender's side. (But how does the receiver know that the sender did this vs just being disconnected? A problem.) To me, it seems the more difficult problem is that of address translation. how do you get the destination t-address translated to tcp port # and ip address? And vice versa? You may be better off using the ISODE model of encapsulating tp0 packets inside tcp/ip. But... this doesn't address your heterogeneous network. > 2. Is it easy to write a "black-box" and Gateway session layer programs? > Or maybe it exists somewhere???? I don't know how easy these would be to write... again, the hard problem in my mind is address translation. > 3. Will NFS, Rlogin,... be satisfied by such an arrangement? Not ftp unless you do something klugey as per my comment above. I don't know about nfs, rlogin and others. Hope this helps -collin ------------------------------------------------------------------------------ This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind. collin park Hewlett-Packard Company collin%hpda@hplabs.hp.com 19420 Homestead Road -- MS 43LT Cupertino, CA 95014 USA
sklower@ernie.Berkeley.EDU (Keith Sklower) (03/01/90)
In article <5560054@hpindda.HP.COM> collin@hpindda.HP.COM (Collin Park) writes: }> 1. Is it possible to translate TCP/IP <--> ISO8073 Cl4? } }In principle, no: tcp/ip has graceful release whereas 8073 has not. and goes on to say }... there may be some }klugey way to get around it... For example, if the 8073 class 4 (i'll }call it 'tp4' from now on) sends data and then waits for ALL data to }be acknowledged before sending the DR TPDU, then the close is }'graceful' from the sender's side. This in fact is not true; ISO 8072 (the transport service specification) >>REQUIRES<< that if the transport provider on the remote end has data queued up for its consumer (session), (which has not yet been delivered), and the remote transport provider receives a disconnect request, then the remote transport provider MUST THROW AWAY all queued up data. Let's repeat that -- You know the remote guy has the received the data he know's he's got the data, but he can't tell you if his client has eaten it yet, and if it's still on the table when you the caterer leave the building, he's required to throw it in the garbage. What a brain dead protocol!!!!!!! It has been speciously suggested that they deliberately castrated TP4 to make it just as limp as X.25, just so they could make sure session had something to do to justify its existence.
preece@ncrcce.StPaul.NCR.COM (Bently Preece) (03/02/90)
In article <245@sposp1.UUCP> rzi@sposp1.UUCP (Roman Zielinski) writes: >???: HOW TO CONNECT TP4 AND TCP/IP NETS :??? > ---------------------------------- ... >1. Is it possible to translate TCP/IP <--> ISO8073 Cl4? > >2. Is it easy to write a "black-box" and Gateway session layer programs? > Or maybe it exists somewhere???? > >3. Will NFS, Rlogin,... be satisfied by such an arrangement? This is an interesting topic. Please post a summary of the responses you receive. -- ------------ ------------ Bently H. Preece NCR Comten, Inc. b.preece@StPaul.NCR.COM St. Paul, MN 55113
collin@hpindda.HP.COM (Collin Park) (03/17/90)
In article <34587@ucbvax.BERKELEY.EDU> sklower@ernie.Berkeley.EDU (Keith Sklower) writes: > In article <5560054@hpindda.HP.COM> collin@hpindda.HP.COM (Collin Park) writes: > }> 1. Is it possible to translate TCP/IP <--> ISO8073 Cl4? > } > }In principle, no: tcp/ip has graceful release whereas 8073 has not. > > and goes on to say > > }... there may be some > }klugey way to get around it... For example, if the 8073 class 4 (i'll > }call it 'tp4' from now on) sends data and then waits for ALL data to > }be acknowledged before sending the DR TPDU, then the close is > }'graceful' from the sender's side. > > This in fact is not true; ISO 8072 (the transport service specification) > >>REQUIRES<< that if the transport provider on the remote end has ^^^^^^^^^^^^ This is in practicality not true; ISO 8072, being a service definition (not "specification") has no conformance clause, and never will have one. There is NO conformance to any service definition in OSI, because the architects of ISO/IEC JTC1/SC21 have declared (in their former lives as ISO TC97/SC21 and /SC16) that the service is abstract. > data queued up for its consumer (session), (which has not yet been ^^^^^^^^^^^^^^^^^^^^^ The consumer isn't necessarily session, especially since we're talking about use of tp4 as a sort of tcp replacement. Actually, it might even be possible to "conform" to 8072 by making a statement like this: There is in my operating system a TS-user thingie which interfaces to tp4 (on its lower end) and to applications accustomed to operating over TCP/IP (on its higher end). This "thingie" always receives all data from the transport-entity instantly; thus, my tp4 entity never has data queued awaiting receipt by the "thingie". The "thingie" also has a peep-hole into network management and in particular knows how much data have not been acknowledged by the peer tp4 entity. When the TCP-accustomed application tells it to disconnect gracefully, the "thingie" peeps at the "number of TPDUs not yet acknowledged by remote" and waits for this number to go to zero. When all these data have been acked, the "thingie" issues a T-disconnect.request to the local tp4 entity. This also circumvents the problem of "if data haven't been acked by the remote and the local tp4 entity receives a disconnect.request from the TS-user, it shall toss those un-acked data and send the DR TPDU" -- since we simply delay giving the disconnect request until we KNOW that the remote has eaten all our data. Actually, by inserting this TS-user thingie I'm creating a site OUTSIDE of the tp4 entity where this "wait for all data to be acked" behavior is done, so it's not really being done inside the tp4 entity. (Actually, it's a transport-entity, not a "tp4 entity"...) So Keith is correct in saying that this behavior isn't legally part of ISO transport. But can you bridge tcp to tp4? I think that this lack-of-graceful-release need not be the factor that stops you. The REAL problem is with directories and mapping one style of addresses to the other.... > delivered), and the remote transport provider receives a disconnect > request, then the remote transport provider MUST THROW AWAY all queued > up data. > Let's repeat that -- You know the remote guy has the received the data > he know's he's got the data, but he can't tell you if his client has > eaten it yet, and if it's still on the table when you the caterer leave > the building, he's required to throw it in the garbage. As I hope I have made clear above, 1) the layer service definitions do not have conformance clauses and thus are not subject to conformance tests; 2) because of this, it is legitimate to bury the _interfaces_ and insert entities that allow OSI protocols to be used by non-OSI-based applications (ftp, telnet, rlogin...) 3) there are still plenty of hurdles to making a practical tp4/tcp bridge, but the graceful release issue, while being a theoretical impediment, can (most probably) be creatively and legally circumvented. Hope this clarifies things.... ------------------------------------------------------------------------------ This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind. collin park Hewlett-Packard Company collin%hpda@hplabs.hp.com 19420 Homestead Road -- MS 43LT Cupertino, CA 95014 USA