Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!munnari!mulga!ditmela!richards From: richards@ditmela.UUCP Newsgroups: comp.protocols.iso,comp.dcom.lans Subject: Re: OSI-model software Message-ID: <192@ditmela.OZ> Date: Fri, 12-Jun-87 01:04:35 EDT Article-I.D.: ditmela.192 Posted: Fri Jun 12 01:04:35 1987 Date-Received: Mon, 15-Jun-87 05:35:52 EDT References: <1204@botter.cs.vu.nl> <1680@munnari.oz> Reply-To: richards@ditmela.OZ (Ian Richards) Organization: C.S.I.R.O. Division of Information Technology, Melbourne. Lines: 116 Keywords: osi, iso, internetworking Xref: utgpu junk:5263 comp.dcom.lans:483 In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Virtually everyone now agrees that the OSI model is a good way to look at >networking. The war is about which protocols which be used in which layer. To the entent that everyone agrees that networking should be performed by layered "entities" communicating with layer protocols and each layer using the services of *a* layer below it and providing services to *a* layer above it, then probably everyone (even Mike Padlipsky!) is in agreement. Of course the OSI Reference Model goes much further than that, eg. it precludes "layer skipping", ie. a layer using the services of a layer not directly below it. Furthermore, IS 7498 SAYS there are SEVEN layers and says roughly what their purposes are. You will have a lot of difficulty getting some people to agree with that. >TCP is clearly one candidate for the transport protocol, but most >companies in the U.S., and virtually all companies outside the U.S. are >committed to supporting the ISO OSI transport protocol and the ISO protocols >in layers 5 through 7 too. (1-3 are much fuzzier, what with IEEE 802 etc.) First, it goes without saying that the OSI reference model achieves very little towards interoperability (how many times have you seen Sales brochures using disgustingly misleading phrases like "our networking complies with the OSI Model"?) Standards are about interoperability. ISO standards exist for protocols up to layer 5, Presentation is about to go to IS status as are a number of Application Layer standards including FTAM. Down at layers 1-3, the IEEE 802 standards are becoming IS8803 and the connectionless network protcocol (equivalent in most senses to IP) is already an international standard. So make no mistake, the standards ARE here and the weight of support for their adoption is enormous. Frankly, the possibility of TCP/IP becoming part of the OSI "suite" is long since past, and before people criticize that, make sure you have examined ISO TP-4 in comparison with TCP. In any case, irrespective of the technical merits of any of the OSI protocols, acceptance of what is standard rather than what is best is unfortunately necessary. This was the view expressed in message <1680@munnari.oz> where kre@munnari.oz (Robert Elz) writes: >The whole purpose >of standardisation is for political considerations to override the >technical ones. And no, I'm not being cynical. The absolute essential >for a standard is for everyone to agree with it, and getting everyone >to agree means lots of compromises. >There's absolutely no hope of a technically perfect standard, especially >not in any area where there's any dispute about what is perfect. Unfortunate, but so, so true. In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) continues: >There has been a lot of generalized disgust with OSI expressed here and >elsewhere. I would be very interested in hearing specific comments about > 1. What is wrong with the OSI model itself. > 2. What is wrong with the specific protocols ISO has adopted. and also >I would like to see a discussion of this subject, preferably by people >who know what they are talking about. First, I thoroughly agree with the the last statement. We need more discussion and we need it from people who know what they are talking about. Given the FACT that OSI standards will happen, the closer we can go to getting them right the better! Unfortunately there are many contributions on the net and elsewhere (Padlipsky's book is an example) from people who in my view have seen some early OSI stuff, have said "It'll never work" or "What's wrong with Arpanet?" and they haven't even attempted to keep up to date with the latest development in OSI. So let's have input from people who know what the latest standards say. One could write a whole book on the two questions raised above, and indeed day by day, experts all around the world are contributing comments to Standards Committees for consideration in the further development of standards. For the time being, let me summarise what I see as the biggest single problem with the OSI Model: THE ROLE OF THE PRESENTATION LAYER. One problem arises with Message Handling systems (a la X.400 which is currently being standardized by ISO also, and there is a commitment for complete alignment of X.400 and the corresponding ISO standards). X.400 provides for a kind of "sub-layering" in the Application Layer with the higher layer handling particular message types, eg. Inter Personal Messaging (Mail) and the lower layer handling Message Transfer. The reference model says that the encoding ought to be done by the Presentation Layer so the message passed to the Message Transfer Sub-Layer must (at least conceptually) be unencoded. X.400 provides for relaying so that the message may be received by a Message Transfer Agent (MTA) on an intermediate machine (or several) which will forward it on to another MTA, eventually reaching the right machine which where the MTA will pass the message "up" to a User Agent, ie. it will deliver the mail. Now the Presentation Service (quite properly) provides for different parts of the data to be encoded in different ways so that for instance, the Message could be encrypted. But how does the Presentation Layer on the intermediate machine (which we assume for security reasons doesn't have the capability to decrypt the message) unencode the message so it can pass it up to the MTA? Well of course it can't, and indeed the situation couldn't have arisen because the two communicating Presentation Entities would have failed in their attempts to negotiate a common transfer encoding. What is the solution? Well, in my view, the Presentation Layer doesn't belong as a true Layer in the OSI model but should instead be provided as a so-called Application Service Entity (ASE) that can be used by other parts of the application layer as and when they see fit. There is nothing wrong with having another ASE - there are already quite a few of them (Remote Operations, Reliable Transfer, Commitement Concurrency and Recovery just to name three). A Presentation ASE could still negotiate with its peer, but another part of the Application layer, eg. the MTA described above, could choose if and when it wants to use it. This contribution has gone on long enough, but it should also be stated that there are other problems with the positioning of the Presentation Layer that have to do with applications that want to do checkpointing, but because they are dealing with unencoded data, they don't have any concept of data size and thus where checkpoints should be placed. Perhaps we can pursue that problem in another article. Ian Richards.