ps@diab.UUCP (06/03/87)
We are looking for a software package that implements the OSI-model protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) in whole or parts. The software need not be a commercial product, or even completely functional. If suitable, it will be a base for further development. It is a requirement that the software could become the property of this company (no licensing), on a non-exclusive basis with no restrictions on it's future use or distribution. Any hints are appreciated. Thanks in advance. -- Per-Erik Sundberg, Diab Data AB SNAIL: Box 2029, S-183 02 Taby, Sweden ANALOG: +46 8-7680660 UUCP: seismo!mcvax!enea!diab!ps
mac@idacrd.UUCP (06/04/87)
in article <223@diab.UUCP>, ps@diab.UUCP (Per-Erik Sundberg) says: > Xref: idacrd comp.dcom.lans:459 comp.protocols.misc:22 comp.sources.wanted:1227 > > > > We are looking for a software package that implements the OSI-model > protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) > in whole or parts. The software need not be a commercial product, or > even completely functional. If suitable, it will be a base for further > development. It is a requirement that the software could become the property > of this company (no licensing), on a non-exclusive basis with no restrictions > on it's future use or distribution. > > Any hints are appreciated. Thanks in advance. > AHHHAAAA Ahhhaaa hahahahahaha ahhhhh hahahahahaha ahhh hahahaha Chuckle chuckle etc. Bob
dpz@aramis.rutgers.edu.UUCP (06/04/87)
>From: mac@idacrd.UUCP (Bob McGwier) >>We are looking for a software package that implements the OSI-model >>protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) > AHHHAAAA Ahhhaaa hahahahahaha ahhhhh hahahahahaha ahhh hahahaha > > Chuckle chuckle etc. Pretty friggin obnoxious. Go play with your toys, unless you have an intelligent answer for him. dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu
steckel@alliant.UUCP (06/05/87)
Anyone contemplating using OSI protocols should read Padlipsky's comments in the tcp-ip mailgroup (comp.dcom.tcp-ip I think). He exposes far better than I can the fundamental flaws in network protocols prescribed by PTTs (national postal/telegraph/telephone monopolies) or other monolithic entities. He has also published a book on the subject - suitable for making implementors cry and standards committee members break out in flames. (Sorry, I can't remember the title but I could find out if enough interest) OSI doesn't tell you how to make a network. It only tells you how to (supposedly) connect to a (supposedly perfect) network. All OSI protocols fall extremely short on error handling. Even X.25, the closest to usable of all the OSI protocols, has had several revisions because of this problem and it's a low level! Read Padlipsky and weep (or break into hysterical laughter!). geoff steckel (steckel@alliant.uucp, gwes@wjh12.uucp)
jmg@cernvax.UUCP (jmg) (06/05/87)
In article <233@idacrd.UUCP> mac@idacrd.UUCP (Bob McGwier) writes: >in article <223@diab.UUCP>, ps@diab.UUCP (Per-Erik Sundberg) says: >> We are looking for a software package that implements the OSI-model >> protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) etc. >> Any hints are appreciated. Thanks in advance. > >AHHHAAAA Ahhhaaa hahahahahaha ahhhhh hahahahahaha ahhh hahahaha > >Chuckle chuckle etc. > >Bob > May I say that this is the sort of inane reply which drives me wild. It has no information in it, other than an implied snide comment. Personally, I would prefer that Mr. McGwier thinks for a few microseconds before issuing such a reply. As it happens:- 1. I already sent off four names to the original sender, and there are certainly more. 2. We are currently running (and interworking with) three different ISO TP4 implementations (on Vax, 68000 and IBM PC). 3. The sender is not English mother tongue (although he speaks it probably rather better than most readers speak his language), and so is possibly upset by the answer.
nrh@chuck.bellcore.com.UUCP (06/06/87)
In article <526@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >Anyone contemplating using OSI protocols should read Padlipsky's comments >in the tcp-ip mailgroup (comp.dcom.tcp-ip I think). He exposes far better >than I can the fundamental flaws in network protocols prescribed by PTTs >(national postal/telegraph/telephone monopolies) or other monolithic entities. >He has also published a book on the subject - suitable for making implementors >cry and standards committee members break out in flames. (Sorry, I can't >remember the title but I could find out if enough interest) >... >Read Padlipsky and weep (or break into hysterical laughter!). > geoff steckel (steckel@alliant.uucp, gwes@wjh12.uucp) Padilipsky's book is called "The Elements of Networking Style", and is published by Prentice-Hall.
fair@ucbarpa.Berkeley.EDU.UUCP (06/07/87)
Followup-To: I wish to echo the recommendation of Michael Padlipsky's book, which is The Elements of Networking Style and other Essays & Animadversions on the Art of Intercomputer Networking Michael A. Padlipsky published by Prentice-Hall, 1985 ISBN 0-13-268111-0 01 It is most frustrating to only be able to sit idly by while most of the computer industry gives lip service to ISO vaporware, while a superior, second generation protocol suite goes mostly ignored (unless the customers have the sense to ask for it): DoD IP/TCP. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
mel1@houxa.UUCP (06/07/87)
In article <19265@ucbvax.BERKELEY.EDU>, fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: > It is most frustrating to only be able to sit idly by while most of the > computer industry gives lip service to ISO vaporware, while a superior, > second generation protocol suite goes mostly ignored (unless the > customers have the sense to ask for it): DoD IP/TCP. I am new to the field of networking and am getting very confused. I see lots of utility in the TCP/IP offerings and uses. I was a user of the ARPANET for many many years (without the slightest knowledge about what was providing such great services). I use an Ethernet in our lab that connects dozens of systems from different venders and opertaing systems. Both work very reliably, relatively fast, and duck simple to use. What does ISO offer that TCP/IP doesn't? Is it significantly faster? I can't think of any other measure that needs improving. Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? Mel Haas , odyssey!mel
dyer@spdcc.COM (Steve Dyer) (06/07/87)
It's unfortunate that Padlipsky, in naming his collection of essays
"The Elements of Networking Style", seems to have eschewed all the
recommendations of its namesake, "The Elements of Style" by Strunk
and White. Although there is some very good technical content in
the book, it is buried beneath a rambling, self-indulgent conversational
style which is very hard to read and follow. Padlipsky makes a lot of
his deliberate decision to avoid "seriousness" in a technical book,
but that doesn't mean that it has to represent the worst of an engineer's
first drafts.
I wonder, too, how accessible much of the material is to newcomers--many
of the essays dive immediately into the details of NCP, the protocol suite
used on the ARPAnet before the introduction of TCP/IP. When I was reading
it, I was glad that I had worked at BBN during the NCP/TCP transition where
I had to support both protocol suites--I had some context to work with.
This isn't to detract from its uniqueness -- it's practically the only
book of its kind, written from the point of view of one of the original
ARPA designers. But it helps if you read it as a kind of "oral history"
transcribed verbatim and manage to get past its idiosyncratic style.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,halleys}!spdcc!dyersas@pyramid.UUCP (06/07/87)
In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >What does ISO offer that TCP/IP doesn't? Is it significantly faster? >I can't think of any other measure that needs improving. The following is my opinion: The ISO stack, in its current state, offers significantly less functionality than TCP/IP. In particular, the virtual terminal protocol is not yet completed. What ISO does propose to offer (when completed) is: (1) More heterogeneity via a more "complete" series of options to the basic functions. (2) A solidification of the layering approach to communications protocols which would provide more intermingling of various services within a class of functionality without modification to the higher layers. E.g., the ability to run a lean transport on top of a connection-oriented service (X.25) versus a more substantial transport on top of connectionless services (802.3). (3) A suite of protocols not developed by the "bomb-crazed" American military. Not that I want to bring politics into the picture but, like it or not, we're talking *international* standards. The Europeans are very sensitive about the protocols which run over the PTT networks. Anyone whose gone through the ordeal of an X.25 certification can attest to this. An international standard not controlled by any one country (in fact one in which each country can select the options (see (2)) it prefers) would seem to be an ideal solution. > >Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? More opinion: I'm not sure I'd classify what appears to be taking place as a war. It seems to be more of a necessary sanity check on what's been produced by the standards bodies. I'm all for standards and computers that talk to each other. However, I'd like this to happen in a reasonably fast and (from the host-standpoint) efficient manner. Beyond the discussion over incompleteness of the standards, there is a question of performance of ISO implementations. One of the more visible groups raising these questions is the FDDI group. If you'll recall, FDDI is a 100 Mbit/sec token bus standard being developed by a subcomittee of ANSI. An important question is what happens when I suddenly improbe my bandwidth (in this case, an order of magnitude) but my software only allows me to use a small portion. In favor of ISO are the European PTTs and academic networks, the MAP/TOP group, NBS and Corporation for Open Systems (COS), and the US Government via the GOSIP spec. It also appears that the ARPAnet may migrate to ISO in an undetermined timeframe. > > Mel Haas , odyssey!mel sas ---- Scott Schoenthal Pyramid Technology Corp. pyramid!sas Mountain View, California
sas@pyramid.UUCP (06/08/87)
In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > [ ... ] If you'll recall, FDDI is a 100 Mbit/sec token bus ^^^ Ugh! My mind said "ring" but my fingers typed "bus". My apologies for any confusion. sas
ast@cs.vu.nl (Andy Tanenbaum) (06/09/87)
In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >What does ISO offer that TCP/IP doesn't? Is it significantly faster? >I can't think of any other measure that needs improving. > >Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? The ISO OSI model is an attempt to provide a framework for networking from the physical bit transport to the applications. The model itself does not contain protocols at all, although ISO has standardized some protocols and services for the various layers. TCP and IP are two specific protocols for layers 4 and 3, respectively, and as such can be used to fill two of the slots in the OSI reference model. Other protocols are needed for the other layers. 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. 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.) 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. Comments like: you can't go out and buy it off the shelf right now don't count. If the standards people waited until every company had already had a running network product, they would all be different and there would be no standard at all. The only way to achieve standardization in this area is to agree on the standards before every company invests a lot of money doing it some nonstandard way. Thus it is not surprising that the standards are here before all the implementations. Nevertheless, there are certainly plenty of valid criticisms of the model and the protocols (e.g., the session layer is pointless, the presentation layer is practically empty, they forgot about encryption altogether etc.). I would like to see a discussion of this subject, preferably by people who know what they are talking about. Andy Tanenbaum (ast@cs.vu.nl)
lamaster@pioneer.arpa (Hugh LaMaster) (06/09/87)
In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >> >>Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? > > >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. > >Andy Tanenbaum (ast@cs.vu.nl) 1) I would like to move this discussion to comp.protocols.iso 2) Unfortunately, the standards making bodies have appeared to those of us on the outside to be dominated by two groups; the first group are European telecomm monopolies who are indifferent to or actively hostile to internetworking (e.g. Arpanet, milnet, nsfnet, many regional networks) between LANs because it will reduce the tariffs they collect (they are right about that); and, second, Certain U.S. Vendors who individually and collectively have a financial interest in pretending to be interoperable while actually trying to make it difficult for their customers to integrate multiple vendors into a single network (they like captive customer bases of course, what monopoly wouldn't?). 3) It is not an issue that not everything is implemented yet by all vendors; it is an issue that absolutely essential protocols are not yet defined. Until there is a network virtual terminal specification, for example, the rest of ISO is of limited utility. You have to have the minimal set of specs first before you can reasonably judge the protocols. How can you be an "ISO booster" before you have a complete protocol set to boost? How can you expect an internet user to accept the ISO protocols before internetwork address resolution and routing are even defined? (Let alone published where the public can see them.) 4) The religious overtones from the ISO camp are also disturbing. I don't remember anyone ever laying religious stuff on me for the arpa protocols. TCP/IP etc. spread from arpanet to the general user community because they worked, and provided the facilities that people wanted. It was that simple, and that hard. The ISO camp is trying to replace TCP/IP not with an improvement in performance, reliability, features, or ease of integration. Instead, some its proponents have resorted to forced baptisms. Before the things we are supposed to believe in are even defined. It worries me. 5) Because the ISO camp didn't bother to stop and consider the needs of the LAN and internet communities, they have only recently begun to work on LAN and internet features. Real improvements over tcp/ip, such as new features like multiple gateway dynamic routing and path load balancing, and real (layer by layer) security, have not been worked on at all. Is it possible to retrofit real security into ISO at this point? If it is, will it be possible to change iso substantially, or will it be cast into concrete, warts and all? 6) Therefore, I am afraid there are two warring camps at this point. The TCP/IP camp is looking for better service, and the iso camp has its (somewhat hidden) agenda which is quite different. This is not to say that anyone working on defining or implementing iso is a bad person. Some of the nicest people are. The solution, from my perspective, is for the iso camp to mature sufficiently that technical considerations override the (current) political considerations. In the meantime, I hope that some mechanism by which user and small vendor input into iso can be developed. Why isn't there anything like the RFC mechanism for iso? Perhaps comp.protocols.iso should spin off rfc.protocols.iso (moderated, of course) and the results forwarded to the standards bodies. 7) Finally, this is not a flame on all the hardworking people who have tried to make the iso protocol suite more suitable for LANs and internets. I don't know who most of you are, but I know sitting on standards committees is tough work. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
kre@munnari.UUCP (06/10/87)
In article <1724@ames.UUCP>, lamaster@pioneer.arpa (Hugh LaMaster) writes: > 1) I would like to move this discussion to comp.protocols.iso Be careful here, comp.protocols.iso is an internet group (a cheap way of transporting the mailing list over the internet), it doesn't reach out into most of usenet. It probably should. Since usenet is all about networking, and iso is standardising exactly that, this is one topic that all usenet should be able to see. > Until there is a network virtual terminal specification, for example, > the rest of ISO is of limited utility. You're right, that one is lagging behind (and started late), probably largely because X.29 (as revolting as it is) was seen as serving adequately enough (which it doesn't outside the x.25 world). > The solution, from my perspective, is for the iso camp to mature > sufficiently that technical considerations override the (current) political > considerations. No, this is all backwards, strange as it may seem. 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. (Just consider Sun with NeWS and X). There's absolutely no hope of a technically perfect standard, especially not in any area where there's any dispute about what is perfect. This isn't to say that the standards bodies don't aim to formulate a standard as technically good as they can, but that *must* come second to getting the necessary agreements, from the whole world. > Why isn't there anything like the RFC mechanism for iso? There is: they're the working papers, draft standards, etc. What they're not is free. Nor are they even cheap. However you can easily obtain copies (contact ANSI in the US). The documentation isn't free, as this is how ISO largely finances its activities .. ie: selling those bits of paper largely pays for the secretarial work that goes into creating them (most of the cost of the technical work is contributed by the members of the working groups, or their employers, but I believe that some of this comes from ISO funds as well). Robert Elz
andre@nrc-ut.UUCP (Andre' Hut) (06/11/87)
In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >What does ISO offer that TCP/IP doesn't? Is it significantly faster? >I can't think of any other measure that needs improving. > >Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? There is a political issue here too. TCP/IP was developed by the U.S. Department of Defense, and well it is viewed by many Europeans as the American protocol. ISO is an attempt at an "International" protocol, universally acceptable... -- ----------------------------------------------------------------------------- sdcsvax-\ ihnp4-\ \ \ Andre' Hut sdcrdcf!psivax!nrcvax!nrc-ut!andre / / / hplabs--/ ucbvax!calma-/ / utah-gr!uplherc/ Network Research Corporation 923 Executive Park Dr. Suite C Salt Lake City, Utah 84117 -----------------------------------------------------------------------------
hedrick@topaz.rutgers.edu (Charles Hedrick) (06/11/87)
No, there isn't a war on. There's no real question about the facts: 1) if you want to build a large-scale network now, use TCP/IP; 2) in a few years, the ISO protocols will be widely implemented, so you may want to use them instead. Given that both the vendors and the U.S. government are committed to ISO, it is doomed to success. Cynical explanations have been considered. One of the more interesting is that you can keep your customers locked in for a few more years by saying that you are working on ISO and that is why you aren't giving them TCP/IP. And your ISO will be here Real Soon Now. However I think the real answer is that no group of people is ever happy with what another group of people did. The people doing ISO are from the European telephone monopolies, who know only X.25, and from U.S. vendors, who have spent years doing their own proprietary networks. In fact the U.S. representatives have done us a great favor, which is far too little appreciated in the TCP/IP community: they have gotten ISO to include a protocol family that is very similar in philosophy to TCP/IP. Personally I think we'd be a lot better off if they had actually used TCP/IP. But as I said, what group, when considering something another group has done, will ever just accept it? And the international politics are such that what we have may be the best we can hope for in any case. There are always things you can do better the second time, or think you can. So their equivalent of IP is sort of the same, but the bits are in different places, the documentation is written in the usual impenetrable ISOese (Reading this stuff makes me appreciate Postel's real achievements in writing readable specifications.), and there are a few more features here and there. Similarly with TP4. I'm not exactly jumping for joy. The bureacrats are convinced that ISO will save them all this money, because they can get the vendors to support it instead of having to pay all those university types to implement it the way they have done for TCP/IP. But of course that won't ever happen. The government is going to pay for ISO development too, one way of the other. No way this conversion is going to save them money. Despite the demo implementations that exist now, it will be a couple of years before it is widely available. And we'll have to deal with two kinds of networks in parallel for several years. I can think of no technical benefit that will come from the changeover. But it will happen, and we'll all live. Processor power and bandwidth is going up fast enough that any extra overhead involved in the new protocols won't sink us. In the meantime, if you don't like excitement, stick with TCP/IP for production use, but start experimenting with ISO, and make sure all the vendors you deal with for networking and communications are working on ISO.
mel1@houxa.UUCP (06/11/87)
Thanks to all who supplied comments to my questions on OSI vs TCP/IP. Unfortunately, none supplied answers. When I refered to OSI vs TCP/IP, I was just using those labels for the whole class of communications capability, not just the OSI reference model vs the TCP/IP layers of the DOD network. Several replys presented the theme that large corporations and government agencys "supported", "endorsed", or "were committed to" the OSI/ISO standards. I don't know what that means. In most cases the organizations mentioned market products or install systems that provide similar functions using quite different protocols. Am I off base in believing that those actions represent just the opposite of support, endorsement, and commitment? Several replys mentioned a variety of different protocols for some of the ISO layers. How does that fit the concept of a "standard"? Is this 1984 "double speak"? I am just a user of already deployed interconnected networks that use a truly fantastic variety of computer systems, hardware, and connection media all based on TCP/IP (with rcp, rsh, rlogin, ftp, telnet at the top for most UNIX users; and goodness knows what on the bottom to actually connect in). Isn't this whole stack already a standard (with an existance proof)? What is the replacement for all this? What does the replacement offer as an inducement to switch? The TCP/IP people have a very active newsgroup discussing technical details of the protocol. I don't understand any of it, but find it quite amazing that there is still growth, discussion, and willingness to learn and change so many years into the life of the product. Or, is this just an indication that the wonders I see are held together with bailing wire and string? Does ISO/OSI have such an activity? Mel Haas , odyssey!mel
sas@pyramid.UUCP (Scott Schoenthal) (06/11/87)
In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >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. > > [ ... ] > >Nevertheless, there are certainly plenty of valid criticisms of the model and >the protocols (e.g., the session layer is pointless, the presentation layer >is practically empty, they forgot about encryption altogether etc.). I would >like to see a discussion of this subject, preferably by people who know what >they are talking about. > >Andy Tanenbaum (ast@cs.vu.nl) I believe that Andy knows what he is talking about and I would certainly be interested if he would expand on the criticisms he mentions in his posting. While I did refer in an earlier posting to the political aspects of adoption of an international standard (the phrase '"bomb-crazed" American military' was an impetuous addition which I now regret), I believe that we should consider here (or hopefully in a comp.protocols.iso) mainly the technical issues of the ISO/OSI model and protocol definition and implementation. Hopefully, this could include MAP/TOP specific protocols (e.g., Directory Services, Network Management) and relevant CCITT protocols (e.g., X.400) as well. sas ---- Scott Schoenthal Pyramid Technology Corp. pyramid!sas Mountain View, California
richards@ditmela.UUCP (06/12/87)
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.
karn@faline.UUCP (06/13/87)
In article <1204@botter.cs.vu.nl>, ast@botter.UUCP 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. About the only thing virtually everybody agrees on is that hierarchical layering is usually a good idea in a computer communication network. The ISO Reference Model (not so fondly called "eyesore-emm" by Padlipsky) is only one of several possible hierarchical models, and a rather outdated one at that. Among the major flaws of the ISO Reference Model are: 1. A fixed number (7) of layers. In a real network there may well be more or less than 7 layers. The important thing is the relative position of a protocol in the hierarchy and the function it performs, not the fixed "level x" designator it might have. Jon Postel and Danny Cohen wrote a paper a few years ago in which they examined some real networking systems and showed that either a) N = N + 1 (for any value of N), OR b) the notion of "seven and only seven layers" is fundamentally flawed. 2. It completely ignores internetworking. This is related to point #1, since in a real internetwork you may very well have two or more network layers in a "stack", e.g., a subnet layer underneath an internet layer. (Some people do split ISO Layer 3 into Layer 3A, the Subnet layer, and Layer 3B, the Internet layer.) The fact that the model still doesn't formally recognize the very real existence of and need for internetworking says something about the motivations of those who influence the ISO. 3. Overly redundant layer functionality. My pet peeve is the use of the term "reliable" in the link layer description, implying that the primary burden for reliable delivery of information rests here instead of the transport layer where it belongs. No other concept has contributed so much to needless complexity, inflated costs and lousy performance than the stubborn notion that each and every layer must "guarantee" reliability, usually through the use of an overhead-laden connection- oriented protocol. A decade ago this mentality brought you X.25. Now it has resurfaced in an even more astonishingly byzantine creation, "IEEE 802.1 Connection- Oriented Logical Link Control" (basically X.25 over Ethernet, believe it or not). For more on the general subject of end-to-end vs low level reliability mechanisms, see "End-to-end Arguments in System Design" by Jerome Saltzer of MIT. 4. While important concepts are ignored, another layer exists whose function is questionable at best: the Session layer. I've yet to figure out just what it's supposed to do, and why a separate layer is needed to do it. 5. While not a fault of the ISO RM per se, some of its overly zealous followers (whom Padlipsky also not-so-fondly refers to as ISORMites, pronounced "eyesore mites") tout it as *the* way a network *must* be built. Even the originators of the ISORM never intended it as anything other than as a general guide to *naming* the pieces of *existing* networks. For example, I've had people tell me that I can't have a "network" without a separate Session layer, even though TCP and UDP have perfectly adequate port numbering and "well known socket" mechanisms. When I ask why, they say "ISO says so". In addition to the faults of the underlying reference model, the ISO/OSI "protocol suite" has a host of faults of its own. First and foremost among them is the fetish for connection-oriented protocols. Only recently did a connectionless transport protocol get added, despite the widespread use of UDP in the ARPA Internet for things like network databases and distributed file systems. On the other hand, there are a FIVE different and mutually incompatible protocols all providing a connection-oriented transport service (TP-0 thru TP-4). If the ISO was *really* serious about "open systems interconnection", they would pick ONE connection-oriented transport protocol (TP-4, the most general one). They claim you don't need all that reliability if you're running on a PTT network, but of course the real reason is that they're scared to death of internetworking. There's no way a PTT is going to allow it to happen unimpeded. Yes, eventually you may be able to pick a "subset" of the ISO stack that answers the needs of the internetworking world. But if you do, you end up with something that is similar to, but (deliberately) incompatible with TCP/IP. So why bother? In summary, if you think open systems interconnection is a good idea, I agree. That's why I and so many others use TCP/IP. I have nothing against migrating to an international standard if it is provably superior to what we have (e.g., the metric system vs the English system) but this is *not* the case with OSI in its present form. I also dislike the "bomb crazed military", but I also see no reason not to take their technology and beat it into plowshares. In fact, it gives me a real feeling of satisfaction to take military technology and pervert and subvert it to peaceful uses! Phil
martillo@bloom-beacon.UUCP (06/15/87)
Personally, I have always found this confusing because I have read the ISO documents and have never seen anything which implies there must be only one protocol at every layer. Further, I thought swap in and swap out of protocol layers should be possible. TCP and IP are tailored to each other but I have seen nothing which implies that TCP could not run over ISO IP or which implies TP4 could not run over IP. In fact there might be reason to tailor a transport protocol for certain classes of protocols. A remote virtual disk server for a PC can certainly get quite hosed when the PC is unexpectedly turned off, why should the host also have to deal with abnormal termination of the transport layer. Perhaps VCs at level 4 are not always a good idea. Unfortunately TP0-TP4 are all VC oriented (I'm not sure) maybe a UDP like level 4 should be defined, in fact maybe remote virtual disk applications are sufficiently unique that a special level 4 should be defined. In any case I don't quite understand why IP and ISO IP can't be coresident in the network. The communications subnet protocol will have some way of indentifying the level 3 protocol to the host level 3 layer software (like the type field in ethernet 2.0 or like ssap/dsap tuples in IEEE 802.2) IEEE 802.2 and ISO level 2 puzzle me as well. These are protocols for the communications subnet and I don't quite understand why IEEE and ISO are trying to define communications subnet protocols for all time. Shouldn't communications subnet protocols be medium-dependent?
martillo@bloom-beacon.UUCP (06/15/87)
Just a note on X and NeWS. NeWS is a postscript based graphics system for high resolution graphics devices which can be used to provide windows. X is a window system which has some graphics primitives. They are not comparable as alternate standards in view of the underlying mechanism or design or philosophy. The question is whether window systems should be implemented on top of graphics systems or whether graphics systems should be built on graphics systems. It maybe partially a religious issue (but I suspect not because virtualizing a raster device on top of a raster device makes sense to me while virtualizing a raster device on top of a graphics system on top of a raster device seems to introduce an extralevel of complexity) but Adobe has announced that it will implement postscript on top of X.
chuck@amdahl.UUCP (06/15/87)
In article <920@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: >IEEE 802.2 and ISO level 2 puzzle me as well. These are protocols for >the communications subnet and I don't quite understand why IEEE and >ISO are trying to define communications subnet protocols for all time. >Shouldn't communications subnet protocols be medium-dependent? Actually, if you look closely at 802.2, you'll notice that the IEEE defines an interface within the datalink layer. 802.2 defines the logical link control layer, and is, and should be, medium-independent. Underneath the logical link control layer there exists a medium access control layer which is, naturally, highly medium-dependent. The advantage to this approach, of course, is that the MAC layer is extremely simple, while the LLC layer is relatively complex. Making the LLC layer hardware independent makes it easier to port LLC layers from one machine to another. The MAC layer must be written anew for each machine and for each type of wire attached to the machine, but since it is relatively simple, this porting cost is not great. -- Chuck
martillo@athena.mit.edu (Yakim Martillo) (06/16/87)
In article <8613@amdahl.amdahl.com> chuck@amdahl.UUCP (Charles Simmons) writes: >In article <920@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: >>IEEE 802.2 and ISO level 2 puzzle me as well. These are protocols for >>the communications subnet and I don't quite understand why IEEE and >>ISO are trying to define communications subnet protocols for all time. >>Shouldn't communications subnet protocols be medium-dependent? >Actually, if you look closely at 802.2, you'll notice that the IEEE >defines an interface within the datalink layer. 802.2 defines >the logical link control layer, and is, and should be, medium-independent. >Underneath the logical link control layer there exists a medium >access control layer which is, naturally, highly medium-dependent. No, this is incorrect because the supposedly medium-independent part of the level 2 (logical link control) is basically a member of the X.25 level 2 like family of protocols. These protocols make or enforce some very specific assumptions about the medium and how you do networking. They assume you really want to establish a perfect virtual wire at level 2 on a relatively noisy telephone-line-like medium and that you either never do internetting or will do so at the cost of some very complicated flow control procedures. They also assume you will not have transmit windows at higher protocol layers. This family of protocols was developed for the PTTs which have a very specific type of medium and have some very specific constraints on the type of services they can provide and on the type of services which they want to provide. The PTTs consider remote terminal sessions and file transfer to constitute the full range of data communications for computers. While I do not always quite believe theoretical estimates, I have seen estimates that over FDDI, LLC could provide maximum of 1.7 megabit transfer rates. In any case I see no obvious reason to use similar level 2s on a point-to-point medium like a token ring and on a broadcast medium like an ethernet. >The advantage to this approach, of course, is that the MAC layer >is extremely simple, while the LLC layer is relatively complex. >Making the LLC layer hardware independent makes it easier to port >LLC layers from one machine to another. The MAC layer must be >written anew for each machine and for each type of wire attached >to the machine, but since it is relatively simple, this porting >cost is not great. This argument I have always found silly. I do not consider myself a particularly fast coder but last week I implemented LLC from scratch for an ethernet in about 3 evenings of work and then 4 evenings of debugging. The other level 2s I have implemented have been simpler and required even less work. Thus the value of a portable level 2 seems negligible to me especially since level 2s are by there nature confined to a single communications subnet. Now if you made the argument at the transport level I would give it more credence. By the way I am using LLC for remote terminal sessions with no higher layers and it really screams but I would think twice about using it in a situation where I was doing real networking like a network file system or where I needed security.
howard@COS.COM (Howard C. Berkowitz) (06/16/87)
In article <920@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) writes: > Personally, I have always found this confusing because I have > read the ISO documents and have never seen anything which implies > there must be only one protocol at every layer. Further, I thought > swap in and swap out of protocol layers should be possible. It is emphatically true that there need not be one protocol per layer; examples are given below. The ISO OSI Reference Model is a context for defining specific layer services and protocols; Implementors' Agreements and Functional Profiles details the options to be used if interoperability is the goal. The Corporation for Open Systems (COS) currently has a number "protocol stacks" defined for future conformance certification; these stacks have a fair variation of lower-layer protocols( i.e., various LAN and WAN technologies) supporting upper-layer messaging (MHS/X.400) and file transfer, access, and management (FTAM). More stacks are being defined. > > TCP and IP are tailored to each other but I have seen nothing > which implies that TCP could not run over ISO IP or which implies > TP4 could not run over IP. > > In fact there might be reason to tailor a transport protocol for > certain classes of protocols. To some extent, this is being done now. ISO defines five classes of the transport protocol, Class 0 having minimum functionality and Class 4 maximum (essentially that of TCP). COS uses Class 4 for most applications, but allows Class 0 for certain modes of operation over X.25 networks, which provide lower-layer error recovery not offered by LANs. > > In any case I don't quite understand why IP and ISO IP can't be > coresident in the network. This should be possible. Note, however, that their functionality is quite similar, and DoD has stated a policy of migration to ISO. >The communications subnet protocol will > have some way of indentifying the level 3 protocol to the host level 3 > layer software (like the type field in ethernet 2.0 or like ssap/dsap > tuples in IEEE 802.2) > > IEEE 802.2 and ISO level 2 puzzle me as well. These are protocols for > the communications subnet and I don't quite understand why IEEE and > ISO are trying to define communications subnet protocols for all time. Realize first that ISO has split Layer 2 into two sublayers: the Logical Link Control (LLC) sublayer, where 802.2 lives, and the Media Access Control (MAC) Layer, which defines the mechanism used to control access to the shared medium, as opposed to the medium-dependent Layer 1 mechanisms used to transmit over it. 802.2 is medium independent, and basically provides framing and limited error detection. It is practically necessary, in an implementation context, to shield upper layers from some of the details of interrupt handling, buffer management, etc. An 802.2 interface can be convenient at the communications chip level, to give a relatively constant interface to upper layers using quite different lower layers. IEEE and ISO definitely are not trying to define communications subnet protocols for all applications. Again, this comment seems to represent the common misconception that the OSI community prescribes one protocol per layer; it simply does not. At the MAC sublayer, there are three especially common protocols using different media access control approaches: 802.3 (using Carrier Sense Multiple Access/Collision Detection), 802.4 (using Token Passing Bus), and 802.5 (using Token Passing Ring). 802.3, essentially equivalent to Phase 2 ETHERNET, is a robust technology, rather easy to implement. It does not offer deterministic delay, which is needed for process control applications [note: there is much theological debate about whether it is; I leave that to the theologians.]. 802.4 is the preferred LAN protocol of the Manufacturing Automation Protocol (MAP) user group. 802.5 offers high reliability and compatibility with certain non-OSI protocols as seen in SNA architecture. MAC and LLC protocols can mix and match on top of specific media. For example, 802.3 protocols have well-defined physical subtypes appropriate for different environments, identified as 802.3 XYZ, where X is the data rate in megabits per second, Y is the medium, and Z is the maximum physical length in hundreds of meters: 10Base5 is thickwire "ETHERNET" cable -- 10 MBPS for 500 M 1Base5 is "STARLAN" type twisted pair 10Broad36 is a broadband implementation... Similar variants exist for 802.4 and 802.5. Other LAN protocols are emerging for specific communities of interest, such as FDDI very-high-speed optical fiber with kilometer range. The key point here is not that there is one protocol, but a whole family of protocols with standardized interfaces between layers. Internetworking is a Layer 3 problem, not Layer 2, so, for example, the goal is to have a common Layer 3 for a variety of quite necessary LANs. ---------------------------------- SEMI-DISCLAIMER I am a conformance testing system developer for the Corporation for Open Systems, and primary instructor for the COS seminar. Information in this posting are accurate to the best of my knowledge, as a worker in the field. Nevertheless, statements here are not necessarily the final word of the Corporation for Open Systems, ISO, ANSI, IEEE, CCITT, the Internal Revenue Service, etc. > Shouldn't communications subnet protocols be medium-dependent? MAC and PHY (Layer 1) protocols are, MAC somewhat so and PHY definitely.
ast@botter.UUCP (06/17/87)
In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: >I believe that Andy knows what he is talking about and I would certainly >be interested if he would expand on the criticisms he mentions in his posting. Ok. For one thing, I think the session layer is ridiculous. All it really does is keep track of whose turn it is to talk and do some checkpointing. I think most applications know whose turn it is to talk. If I am addressing an editor on a remote machine, we really don't need a whole layer to keep track of whether I am allowed to type or it is the editor's turn to say something. In the British proposal to ISO years ago, there was no session layer. I think they were right. The session layer was probably included because IBM had one, and people must have assumed that if IBM did it, it must be a good idea. I am not convinced that there are enough applications that use the session layer to make it worth having. The ARPANET model does not have any session layer and I have never heard of anyone saying he needed it. The presentation layer. It is practically empty now. All that seems to be left is ASN.1 and ASN.2, which are several hundred pages of mumbo jumbo for the purpose of telling which order the bytes are in (VAX, Intel = little endian) vs. (68000, IBM 370 = big endian). This seems overkill to me. Encryption. ISO seems to be totally unable to get its act together. Other than unambiguous statements that encryption does not belong in the session layer or physical layer, it seems that all others are possible, although lately I have been hearing noises that maybe presentation is "in" again. I think spreading it out all over the place is a disaster. Logically I think it belongs in presentation--it deals with "meaning" in some sense. In any event, the current situation is a disaster. Andy Tanenbaum (ast@cs.vu..nl)
lamaster@pioneer.arpa (Hugh LaMaster) (06/17/87)
In article <933@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: > >No, this is incorrect because the supposedly medium-independent part >of the level 2 (logical link control) is basically a member of the >X.25 level 2 like family of protocols. These protocols make or >enforce some very specific assumptions about the medium and how you do >networking. They assume you really want to establish a perfect >virtual wire at level 2 on a relatively noisy telephone-line-like >medium and that you either never do internetting or will do so at the >cost of some very complicated flow control procedures. They also >assume you will not have transmit windows at higher protocol layers. > There are several things I don't understand about this. First, as I look at ISO, X.25 is at level 3 with associated link procedures at level 2, and a spec to connect to physical media at level 1. What don't I understand about this, since you are referring to X.25 as a level 2 protocol? Do you mean the link level protocol associated with X.25 only? Also, as I understand (?!) the E-S to I-S (if I'm not mixing it up) ideas floating around, there will be a gateway protocol defined using X.25 packet addressing to handle WAN's. In a TP4/ISO IP LAN, there will be an X.25 gateway which will repackage the contents of an IP packet as the contents of an X.25 packet; somehow, there will be some way to tell the X.25 gateway on the other side what IP address you want there, and then the data goes over X.25 to the other gateway where it is repackaged again in IP. Now, I heard this from two independent sources, but I may be confused. If this is the way it will work, it is execrably stupid. The "correct" way to run over X.25 (I am NOT saying there is an existence proof which demonstrates that there IS a correct way to use X.25 :-) ) is to view it as an overkill layer 2 protocol which links 2 "IMPS" or "gateways" or "IP routers" depending on what you are doing. In fact, arpa now supports X.25 as a level 2 host to IMP protocol, "replacing" 1822. Some ISORMites may not like the redundancy in some layer three functions this way, but what is the alternative? At least this way you will be able to create an arpa type of internet/network/subnet uniform addressing, which you won't be able to do the other way. I would like to see more postings from some of the ISO gurus who are now appearing on the net regarding this subject; I appreciate the responses that have appeared so far, but I am not satisfied with the answers about "internetworking". > >While I do not always quite believe theoretical estimates, I have seen >estimates that over FDDI, LLC could provide maximum of 1.7 megabit >transfer rates. In any case I see no obvious reason to use similar >level 2s on a point-to-point medium like a token ring and on a >broadcast medium like an ethernet. > What is the estimate for LLC over Ethernet? Do you mean virtual circuit LLC or packet LLC? [I would hate to think that packet LLC can't run at Ethernet speeds...] I think that the "motivation" was that token bus, broadcast, and FDDI were all so "similar" that there was no point in making them different. I see the real question as: Why is there any connection oriented service at all in LLC? But then, I like packet networks, and CCITT and IBM don't, and IEEE wanted to make both CCITT and IBM happy, right? -- Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
martillo@athena.mit.edu (Yakim Martillo) (06/18/87)
I think X.25 level 2 and LAPB are fairly frequently used interchangeably. This is slightly erroneous because X.25 level 3 can run over other link access protocols. Also I meant the X.25 designers basically assumed that you would never have a transmit window in a protocol above level 3. LAPB has a window basically for error-handling and X.25 level 3 has a flow control window. Anyone who has tried to run kermit over a PSPDN knows how well all the transmission windows interact.
karn@faline.UUCP (06/18/87)
In article <1214@botter.cs.vu.nl>, ast@botter.UUCP writes: > Encryption. ISO seems to be totally unable to get its act together. Other > than unambiguous statements that encryption does not belong in the session > layer or physical layer, it seems that all others are possible, although > lately I have been hearing noises that maybe presentation is "in" again. > I think spreading it out all over the place is a disaster. Logically I > think it belongs in presentation--it deals with "meaning" in some sense. > In any event, the current situation is a disaster. I think there are some good reasons for encrypting at more than one layer. End-to-end encryption is the most effective way to keep a message's contents private, especially if you want to use any available network (e.g., a PDN), since nothing in the network need be trusted. There is probably something to be said for encrypting anything that the network doesn't absolutely have to have to do its job, so you might as well encrypt the transport header as well. In other words, encrypt on an end-to-end basis on the interface between L3 and L4. However, end-to-end encryption doesn't protect you against traffic volume analysis by someone outside the network monitoring its links, so encryption on a per-link layer is still necessary. The only remaining threat then becomes traffic analysis from within the network itself. This is virtually impossible to prevent since the network must have readable addresses in order to do its job; about the only thing you can do is generate lots of garbage traffic to random destinations to spoil their statistics -- IF you happen to have money to burn (i.e., work for NSA). You could go further and build a hierarchy of networks with encryption in each. For example, you could build a TCP/IP Internet where the gateways use X.25 public networks (possibly having internal encryption) to pass encrypted IP datagrams which themselves contain end-to-end encrypted TCP data segments. A dishonest subnet could then only analyze a fraction of the total Internet traffic, and those observations would be much less precise because of the (hidden) multiplexing and routing changes going on at the IP layer. It is entirely possible that one of the unstated reasons for DoD's insistence on datagrams is to allow "gratuitous rerouting" (i.e., route changing not necessitated by link failures or congestion). This would be yet another technique to foil traffic analysis attempts at the lower layers. So redundant encryption still makes sense, so that the lower the layer, the less trusted its components have to be. Phil
lamaster@pioneer.arpa (Hugh LaMaster) (06/18/87)
In article <1800@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes: > >Also, as I understand (?!) the E-S to I-S (if I'm not mixing it up) ideas >floating around, there will be a gateway protocol defined using X.25 packet >addressing to handle WAN's. In a TP4/ISO IP LAN, there will be an X.25 >gateway which will repackage the contents of an IP packet as the contents of >an X.25 packet; somehow, there will be some way to tell the X.25 gateway on It seems that I have mixed it up; I have received several replies to that effect. My apologies. X.25 (level 3?) will, it seems, be used as an alternate "level 2.5" protocol. Is 802.2 also considered "level 2.5"? Is there a draft standard on this yet? What ISO number is it? Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
aweinste@Diamond.BBN.COM (Anders Weinstein) (06/18/87)
I thought that the OSI Session layer was derived from the CCITT Teletex protocol (S or T.62). I believe most of the OSI Session-layer operations are just Teletex session functions couched in more abstract terms, ie. "activities" correspond to Teletex "documents", OSI synch points correspond to pages, etc. Not that this makes it a good idea or anything...
howard@cos.UUCP (06/19/87)
In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > >I believe that Andy knows what he is talking about and I would certainly > >be interested if he would expand on the criticisms he mentions in his posting. > Encryption. ISO seems to be totally unable to get its act together. Other > than unambiguous statements that encryption does not belong in the session > layer or physical layer, it seems that all others are possible, although > lately I have been hearing noises that maybe presentation is "in" again. > I think spreading it out all over the place is a disaster. Logically I > think it belongs in presentation--it deals with "meaning" in some sense. > In any event, the current situation is a disaster. > The reason encryption can be defined in multiple layers is that encryption is used for different purposes in different layers. The usual view of encryption is that it is intended for protecting information from viewing by unauthorized readers. This is not always true; disclosure of contents in, for example, many financial applications is no major threat, but real problems could be caused by replaying legitimate information. It can be appropriate to encrypt the message number part of a credit authorization message. Protection from duplication/replay, sender authentication, avoidance of repudiation of reception (e.g., registered letters), all are reasons to encrypt in the application layer. Transport-layer encryption protects message contents on an end-to-end basis. If encryption is done at the transport or presentation layers, however, message headers must be in clear (or a different cryptosystem) so that the network and data link layers can extract information needed to route messages. In some applications, such as tactical military systems, it can be important to protect against traffic analysis: gaining information by knowing how much traffic, at what times, are being sent from one endpoint to another. To protect against traffic analysis, the link level must be encrypted or physically protected. Again, this is only needed if traffic analysis is a concern, or, if for administrative reasons, it's easier to distribute encryption keys on a link-by-link rather than end-to-end basis.
kre@munnari.oz (Robert Elz) (06/19/87)
In article <943@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) writes: > ... X.25 level 3 has a flow control window. Anyone who > has tried to run kermit over a PSPDN knows how well all the > transmission windows interact. Huh? I always thought that the problem with kermit over x.25 nets is precisely because kermit doesn't have a windowing flow control scheme (or it has the terminal case, of a window size of 1). That is, kermit sends a packet, then waits for an ack. Packet turnaround in x.25 networks is typically fairly slow, but this is neither a problem with x.25, nor with the windowing scheme (which is effectively a no-op when protocols like traditional kermit are used above it). Rather, its a problem with the comparatively low capacity technology used to implement the networks. I doubt I'm alone in this belief, as I gather that the kermit people are defining a new protocol (extended protocol) with windowing in it, precisely so it will work *better* over x.25 type networks. kre
howard@COS.COM (Howard C. Berkowitz) (06/19/87)
In article <1818@ames.UUCP>, lamaster@pioneer.arpa (Hugh LaMaster) writes: > In article <1800@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes: > > It seems that I have mixed it up; I have received several replies to that > effect. My apologies. X.25 (level 3?) will, it seems, be used as an > alternate "level 2.5" protocol. A fine distinction here: OSI has "layers;" X.25 has "levels." X.25 Level 3 = OSI Layer "2.5" (more or less). The 1984 version of X.25 has several extensions for greater OSI compatibility, including the ability to extend addresses from the X.121 14-digit maximum to the 32-digit maximum of the OSI Network Service. > Is 802.2 also considered "level 2.5"? 802.2 has several classes of operation. The simplest, Class 1, is connectionless and offers no error correction. This class has been adopted by the NBS Workshop for OSI Implementors: "Only the connectionless type 1, class 1, IEEE 802 service will be used." COS and MAP/TOP also use class 1 only. 802.2 Class 1 has very minimal functionality, and basically serves the implementation role of insulating Layer 3 from the timing and buffer issues of the MAC sublayer of Layer 2. As a minimal protocol, it is much less than X.25, and thus is considered pure Layer 2 (Logical Link Control -- LLC -- sublayer). NBS, COS, and MAP/TOP all assume Internet on top of LLC1. > Is there a draft standard on this yet? What ISO number is it? So far, all standards out of the 802 Project have been given "derivative" international numbers: 802.X = ISO 8802/X. For example, 802.3 is ISO 8802/3.
nguyen@amd.UUCP (06/20/87)
In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > >I believe that Andy knows what he is talking about and I would certainly > >be interested if he would expand on the criticisms he mentions in his posting. > > Ok. For one thing, I think the session layer is ridiculous. All it really ... I don't think this comment is neccessarily constructive. It is too early to remove the session layer altogether from the ISO's OSI. The development for most upper layers protocols has not proved maturity for everyone to accept as standards and NO ONE really know what all layers have to be in the future. There are ton of different applications which can exist in all kinds of networks. Who knows?... I would rather have a null layer to by pass so I can reconfigure the adjacent interfaces when the 'null' is no longer necessarily empty later. Some one proved that the session layer is not null (such as IBM) must have a very good reason for it! As we all know that most network layer implementation are null!!!. This doesn't seem to hurt any body. Quinn Nguyen
blarson@castor.usc.edu (Bob Larson) (06/20/87)
In article <1707@munnari.oz> kre@munnari.oz (Robert Elz) writes: >In article <943@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) >writes: >> ... X.25 level 3 has a flow control window. Anyone who >> has tried to run kermit over a PSPDN knows how well all the >> transmission windows interact. > >Huh? I always thought that the problem with kermit over >x.25 nets is precisely because kermit doesn't have a windowing >flow control scheme (or it has the terminal case, of a window >size of 1). > >That is, kermit sends a packet, then waits for an ack. > >Packet turnaround in x.25 networks is typically fairly slow, >but this is neither a problem with x.25, nor with the windowing >scheme (which is effectively a no-op when protocols like >traditional kermit are used above it). Rather, its a problem >with the comparatively low capacity technology used to implement >the networks. Some implementations of x.25 do not realize that no further data will be sent, so have to time out before the packet is sent. (kermit packets are shorter than x.25 packets.) This is an implementation rather than pure standarization issue, but standards which allow rediculous behavior (waiting for output from a process that is waiting for input) somewhat deserve the critisism they get. >I doubt I'm alone in this belief, as I gather that the kermit >people are defining a new protocol (extended protocol) with >windowing in it, precisely so it will work *better* over x.25 >type networks. Full duplex windows has been an accepted option to the kermit protocol since the 6th edition of the protocol manual. (Published about a year ago.) I just wish they were part of c-kermit, the unix kermit implementation. (Prime kermit and Procom for the Ibm Pc are two examples of kermit implementations that do support full duplex windows.) Full duplex windows are a win in any situation where the communications speed is limiting the speed of the file transfer. They just win bigest when the communications delays are long. Bob Larson Arpa: Blarson@Ecla.Usc.Edu Uucp: {sdcrdcf,seismo!cit-vax}!oberon!castor!blarson "How well do we use our freedom to choose the illusions we create?" -- Timbuk3
kre@munnari.UUCP (06/20/87)
In article <1818@ames.UUCP>, lamaster@pioneer.arpa (Hugh LaMaster) writes: > X.25 (level 3?) will, it seems, be used as an > alternate "level 2.5" protocol. Is 802.2 also considered "level 2.5"? > Is there a draft standard on this yet? What ISO number is it? Here are a bunch of numbers .. IS 8348 Network service definition (this says what you can expect the network layer to do for you, and if you're implementing any network protocol, what services you must provide). IS 8348 AD 1 Network service definition addendum 1, Connectionless-mode transmission (ie: datagrams) DP 8880 Specification of protocols to provice and support the OSI network service part 1: General principles part 2: provision and support of the connection-mode service part 3: provision and support of the connectionless- mode service DIS 8878 Use of X.25 to provide the OSI connection-mode network service (this is what fills in the last .5 to turn the "2.5" layer X.25 into layer 3) DIS 8208 X.25 packet level protocol for data terminal equipment (this is 1984 X.25) DIS 8473 Protocol for providing the connectionless-mode network service (see also also DAD 1, and PDAD 2). DIS 8648 Internal organization of the Network Layer There are other level 3 related protocols (DP 9542, "End system to intermediate system routing exchange protocol for use in conjunction with ISO 8473", and DP 9068, "Provision of the connectionless network service using ISO 8208", are two that might be relevant) ISO 8802/2 (IEEE 802.2) is a link level protocol, as it provides only point to point service (from one host, across a LAN, to another). Contrary to what some others have implied, or even stated as fact, ISO layer 3 is an *internetwork* protocol, with exactly the same function in the overall scheme of things as IP has in the DARPA protocols. In this are you might want to look at DIS 8881-1 "Use of the X.25 packet level protocol in local area networks, Part 1: use with LLC Type 1 procedures" and DIS 8881-2 "... Part 2: use with LLC Type 2 pricedures". While I'm rambling, I should also point out, that most people making noises about IEEE 802.2 (8802/2) are considering only LLC Type 2, which is the thing that looks a little like X.25 (or hdlc). Remeber that LLC Type 1 exists too, which is a protocol about as complex as old form xerox/dec ethernet (and might go unnoticed because its just a couple of pages in the 802.2 book). Robert Elz kre@munnari.oz.au
kre@munnari.UUCP (06/20/87)
In article <638@faline.bellcore.com>, karn@faline.UUCP writes: > Among the major flaws of the ISO Reference Model are: > > 1. A fixed number (7) of layers. These are just conceptual layers, and they don't (and aren't mean to) include layers in application processes. You can recursively redefine any of those layers as much as you like for whatever purposes are appropriate (eg: level 2 on lans has llc and mac, but its all still level 2 .. point to point). > 2. It completely ignores internetworking. This is rubbish. > They claim you don't need all that reliability [TP4] if you're running on a > PTT network, but of course the real reason is that they're scared to > death of internetworking. There's no way a PTT is going to allow it to > happen unimpeded. I think your arguments about PTT fears need a little examination. Most of the world's PTT's don't need standards to control the world's networking (this is outside the US). In most countries the PTT's have a legal monopoly, they don't need this kind of extra second hand pseudo-protection. I have no love for PTT's and their regulations, however before discounting all their arguments, its worth placing yourself in their position for a while. Let's indulge in a little whimsy. Imagine yourself offered the job of director general (or whatever its called) of the arpanet (and nsfnet, span, csnet, etc for fun). You're naturally overjoyed, as quite apart from the 6 (or perhaps 7) figure salary, you're finally going to be able to stamp out all this OSI nonsense on the arpanet, and get things finally back on the straight and narrow of TCP/IP. So far, so good, everything's running smoothly, until one day there's a rash of "hacker" breakins at military institutions doing weapons research, and evidence is that this comes from the educational (research) side of the net .. the part you are in control of. Big stink in the press, congressmen up in arms, the lot. Of course, no-one suggests that OSI would have been any better (that's not my point). But, finally someone raises a question... the US goverment (the taxpayer) is paying for these hackers to wreak havoc on the US national security, Why? This must be stopped at once. In one of those amazing happenings in the US congress and Senate a bill is passed, and receives Presidential assent, all within a day. It denies any goverment funding to the networks. Not only direct funding, but indirect funding through research grants, contracts, etc, and denies tax deductions for gifts to any organizations that use any of the gift for networking purposes. Congress is really mad! Now, you have something of a problem. Here you are in charge of this network that has no money, and the bills are starting to come due. How are you going to solve this problem? You can try and get people to donate funds out of the goodness of their hearts, but somehow I doubt that is going to work. You're likely to have to reach the position where you have to actually charge real money to the people who use your networks. You're more or less in the position of the PTT's in the rest of the world, you're running a business, and you have to at least break even, if not make a profit, or your network collapses. It might be instructive to explain how, with the current internet setup, and using the standard IP based protocols (which of course you have the authority to change if you want) you are going to make all this work. Nb: I mean the whole internet here, including all those sites that have slip, and csnet x.25, links to the lucky few on net 10. > I have nothing > against migrating to an international standard if it is provably > superior to what we have (e.g., the metric system vs the English system) > but this is *not* the case with OSI in its present form. You're right, OSI is not ready for use yet, it needs some more work (though many of the individual protocols are perfectly ok). But asking for it to be provably superior is asking too much. It might never achieve that in the sense you mean. What it will be is demonstrably more widely available. That is, one day you will be able to connect to us (in Australia) using OSI. Chances are you never will be using TCP. Which is strange, as we run TCP now, so do you. Neither of us runs OSI... (But the US government won't allow us to connect to you using TCP, we would have to get some special dispensation to allow packets from outside the US onto the arpanet, and that's simply not worth bothering with). We could set up some direct TCP link (possibly over an X.25 carrier..., it would certainly be over some PTT carrier, as that's all that's available) but then you would have to take special precautions to make sure none of our packets escape. What great internetworking! Remember that continually bemoaning the lack of readiness of the ISO protocols does nothing to help them get completed. You'd be better assisting ISO, I know that you have lots of TCP knowledge, you must have plenty of experience that would be quite valuable, and perhaps you could be helping to prevent some of the mistakes that you see ISO making, instead of just complaining about them. kre ps: Phil .. mail to you on the backbone list is being addressed to bellcore!bellcore.com!karn (or something similar) and is making bellcore's mailer dump core (SIGSEGV), you might want to look into that.
kre@munnari.UUCP (06/20/87)
In article <2886@oberon.USC.EDU>, blarson@castor.usc.edu (Bob Larson) writes: > Some implementations of x.25 do not realize that no further data will be sent, > so have to time out before the packet is sent. Any X.25 implementation that does that is 100% bogus, and I actually doubt that there are any such implementations. However, X.28 does have this "feature". (This is what you get when you connect to X.25 via a PAD). However, it can be controlled in various ways, most of which, due to completely hopeless PAD implementations, work against one another to kill performance, when a little more intelligence (on the part of the implementor) could make it all work passably well. However, please don't judge X.25 (which is what would be used for any ISO networking) by the failings of X.3/X.28/X.29 which are total trash. Also, if you claim that any standard that allows this behaviour is no good, then you have just condemned TCP. TCP is not bound to deliver any data unless PUSH is set. I could easily implement a TAC (PAD) that never set PUSH (or only set PUSH after a timeout, just to see if any more data is coming...). kre
samlb@well.UUCP (Samuel B. Bassett) (06/21/87)
Harrumpf!
The process of achieving _reliable_ communication over a network is
difficult enough. _Secure_ communication is a whole order of magnitude
more work, and should be left to the spooks -- when they _really_ need it,
they will provide it on their own lines, and in their own formats.
As I understand it, the purpose of the various layers should be to
insure that a proper package is wrapped around the "data" that each layer
receives from the next 'higher' layer, so that the (otherwise unexamined)
contents of the data get where they are expected to go, and can be interpreted
correctly when they get there. The contents of the data at each stage can
be 'plaintext' or 'cryptext' -- the protocol handler should not care one way
or the other.
Let's not complexify the situation out beyond the state of the art!
--
Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale!
34 Oakland Ave., San Anselmo CA 94960; (415) 454-7282
UUCP: {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb;
Compuserve: 71735,1776; WU Easylink ESL 6284-3034; MCI SBassetthoward@COS.COM (Howard C. Berkowitz) (06/23/87)
In article <933@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) writes: > In article <8613@amdahl.amdahl.com> chuck@amdahl.UUCP (Charles Simmons) writes: > >In article <920@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: > >>IEEE 802.2 and ISO level 2 puzzle me as well. These are protocols for > >>the communications subnet and I don't quite understand why IEEE and > >>ISO are trying to define communications subnet protocols for all time. > >>Shouldn't communications subnet protocols be medium-dependent? > > >Actually, if you look closely at 802.2, you'll notice that the IEEE > >defines an interface within the datalink layer. 802.2 defines > >the logical link control layer, and is, and should be, medium-independent. > >Underneath the logical link control layer there exists a medium > >access control layer which is, naturally, highly medium-dependent. > > No, this is incorrect because the supposedly medium-independent part > of the level 2 (logical link control) is basically a member of the > X.25 level 2 like family of protocols. These protocols make or > enforce some very specific assumptions about the medium and how you do > networking. They assume you really want to establish a perfect > virtual wire at level 2 on a relatively noisy telephone-line-like > medium and that you either never do internetting or will do so at the > cost of some very complicated flow control procedures. They also > assume you will not have transmit windows at higher protocol layers. > NO to the No! There are several classes of Level 2 LLC (Logical Link Control; IEEE 8802/2). Type I is connectionless and does not ^^^^^^^^^^^^^^ ^^^ try to provide a "perfect virtual wire;" it is significantly different from the LAP-B HDLC-style link protocols used for the X.25 family, LLC Type I has been adopted as the media-independent part of LAN-environment Layer 2 by the NBS OSI Implementors' Workshop (for 802.3 CSMA/CD and 802.4 Token Bus Media Access Control), by the MAP/TOP User Group for 802.3 and 802.4, and by the Corporation for Open Systems (for 802.3, 802.4, and 802.5 Token Ring). By contrast, COS adopted ISO 7776 as the link control layer for X.25 WAN applications, another example of how practical OSI protocol stacks do not require only one protocol at each layer. > > This family of protocols was developed for the PTTs which have a very > specific type of medium and have some very specific constraints on the > type of services they can provide and on the type of services which > they want to provide. The PTTs consider remote terminal sessions and > file transfer to constitute the full range of data communications for > computers. In the worldwide environment, the view of PTT's cannot be ignored. The challenge is interfacing the LAN and WAN environment in the real world, which has political, regulatory, and economic constraints as well as technical ones. PTT's doing packet work are apt to be more amenable to data concerns than "old-line" telephone operating companies, who believe real men do it in 4 kilohertz analog channels implemented on twisted pair. There is hope, however. A few months ago, I presented COS' current activities to ANSI Committee T1, which is the main telecommunications standards body for the U.S. I reminded them that about three years previously, I had been on the T1 task force concerned with developing the workplan for performance/quality of service standards. At that meeting, an old time telephony standards man took me to task about not really understanding how it all worked; that I was up in the theoretical stratosphere of X.25. At the T1 meeting recently, I found that same old-timer in the bar, complaining how his customers "didn't understand what their software told them; that they simply didn't understand retransmission algorithms in X.25." I pointed out that in three years, our telephony pioneer had moved from below Layer 0 of the OSI Reference Model into Layer 2. I predicted that in 1993, he would be a UNIX hacker developing OSI applications, and we OSI people would have moved into another dimension. (Further discussion on last point to rec.sf-lovers, please. Comments that OSI people already are in another dimension will be routed, using IP if you like, to /dev/null.). -- -- howard(Howard C. Berkowitz) @cos.com {seismo!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [ofc] (703) 998-5017 [home] DISCLAIMER: I explicitly identify COS official positions.
jhh@ihlpl.UUCP (06/24/87)
In article <2886@oberon.USC.EDU>, blarson@castor.usc.edu (Bob Larson) writes: > >traditional kermit are used above it). Rather, its a problem > >with the comparatively low capacity technology used to implement > >the networks. It's not really the capacity that is the problem, rather it is the X.25 network delay that causes delay perceived by the user. Admittedly, delay is usually related to capacity just because higher capacity implementations have that much less time to process and delay a packet. The number of network nodes that a packet traverses, along with the trunk speed connecting the nodes has a much greater impact on delay. If an X.25 network requires the full packet to be received before it processes it and sends it to the next node, there is an insertion delay (number of bits in packet divided by the line speed). For example, 60 milliseconds are required to receive a 64 byte message at 9600 bps. With a protocol that has a window of 1, the transmiter must remain idle for at least the number of intermediate nodes times 60 milliseconds (assuming 9600 bps internal trunk speeds). At higher trunk speeds (56Kbps for example), the internal node processing time becomes a more significant factor. > Some implementations of x.25 do not realize that no further data will be sent, > so have to time out before the packet is sent. This has nothing to do with X.25, but rather the device that is converting the asynchronous data into X.25. This is typically a function on an X.3/X.28/X.29 PAD (Packet Assembler/Disassembler). In particular, two X.3 parameters that affect when an asynchronous stream should be forwarded are 3 (selection of data forwarding characters) and 4 (selection of idle timer delay). John Haller
ast@cs.vu.nl (Andy Tanenbaum) (06/24/87)
In article <4122@amd.UUCP> nguyen@amd.UUCP (Quinn Nguyen) writes: >In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >> I think the session layer is ridiculous. > > Quinn then goes on to say: >Some one [who] proved that the session layer is >not null (such as IBM) must have a very good reason for it! This is the kind of thinking that led to OSI in the first place. The committee observed. 1. IBM has a 7 layer network architecture. 2. IBM is big and powerful and successful Ergo, if we have a 7 layer network architecture we will become big and powerful and sucessful. Nonsense. It is not desirable to create a giant, ponderous beast that lusts after megabytes the way the cookie monster goes after cookies. St. Exupery said: Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away. Look at the success of RISC machines. Computer architects have learned that what one does NOT need is an unwieldy instruction set that no compiler can produce code for. Adding more instructions and modes and stuff on the off chance that someone will someday need it is foolish. The idea of having a session layer for those few applications that can't keep track of whose turn it is to talk is equally silly. Let them do it as part of the application. I think network architectures (and everything else in the world) should be made as simple as possible, consistent with their intended goal. I think OSI needs to go on a crash diet. Null session layers aren't the way to go. The structural complexity is still there, even if it is dormant for the moment. Andy Tanenbaum