Path: utzoo!attcan!uunet!husc6!ukma!tut.cis.ohio-state.edu!ucbvax!HP-SDE.SDE.HP.COM!tozz%hpindlm From: tozz%hpindlm@HP-SDE.SDE.HP.COM Newsgroups: comp.protocols.iso Subject: Re: TCP/IP versus OSI Message-ID: <8905152046.AA01964@hpindlm.HP.COM> Date: 15 May 89 20:45:36 GMT References: <8905151612.AA15527@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 147 >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