joel@gould9.UUCP (Joel West) (03/28/86)
Could someone please help me out? I'm familiar with TCP/IP, and, to
some degree, X.25. I've even heard of MAP. But what does it mean when
someone says they will be using the "ISO" protocol?
I know that there is a 7-layer model proposed by ISO, and I'd always thought
this meant you could mix- and- match at any layer (a pure hierarchy, for
example). But recently I've seen plugs that suggest ISO is a specific
protocol, much like TCP/IP or XNS.
What does it mean, "DECNET will conform to ISO?" If, say, five years from
now I want to hook my PC to the DDN or across a LAN to a BSD 4.9 machine,
and they're all running "ISO", does that mean there will be an actual, known
protocol at all 7 layers? For programmer shops and office automation, will
that be TOPS + ISO? Would it also work, wholely or partly, with DECNET?
To get to the bottom line, is the standard well-defined enough that I can
write an "ISO driver" that will talk to an arbitrary box some point in the
future?
If an analogy would help, I know my terminal must talk ASCII, for
example, and the modem should conform to Bell 103, 212, or V.22 bis.
If I want to communicate between micros and mainframes, KERMIT works
well; between micros, XMODEM is popular.
Any information at all, references (articles and books) would be
appreciated. Mail or post at your discretion.
(I got an "A" in Buzzwords 101.)
--
Joel West (619) 457-9681
CACI, Inc. Federal, 3344 N. Torrey Pines Ct., La Jolla, CA 92037
{cbosgd,ihnp4,pyramid,sdcsvax,ucla-cs}!gould9!joel
gould9!joel@nosc.ARPAdjo@ptsfd.UUCP (Dan'l Oakes) (04/04/86)
Hey line eater, for all you do, this line's for you. In article <424@gould9.UUCP> joel@gould9.UUCP (Joel West) writes: >Could someone please help me out? I'm familiar with TCP/IP, and, to >some degree, X.25. I've even heard of MAP. But what does it mean when >someone says they will be using the "ISO" protocol? It means that they will be using some or all of the hundreds (literally) of protocols ISO and/or CCITT are suggesting now or have in the past six to ten years. It also means that they want you to buy their product. Find out what they mean. A good default is (layer 1) rs-232-c/v.35; (layer 2) LAP B; (layer 3) X.25. They may also support such things as X.75 but don't bet on it. Layers 4 and up will be their own protocols. >What does it mean, "DECNET will conform to ISO?" It means DEC wants you to buy DECNET. >To get to the bottom line, is the standard well-defined enough that I can >write an "ISO driver" that will talk to an arbitrary box some point in the >future? > No. The standards for layers 4 and up are WAY up in the middle of the air (see that wheel inside that other wheel?) Dan'l Danehy-Oakes "And as for all their tempting ideas, well, Hare didn't care. The lost spectacles were his own affair. And (after all) Hare did have a spare pair." Jethro Tull
karn@petrus.UUCP (Phil R. Karn) (04/05/86)
It is also worth mentioning that I don't think anyone has yet found a criterion by which "ISO" is somehow "better" than the ARPA protocol suite, other than its well-trumpeted status as a "future world standard". In fact, in many ways the ISO network and transport protocols are demonstrably worse than IP/TCP. Given that two hundred years ago a system of weights and measures was invented in Europe that (unlike ISO protocols) is simpler, easier to use and without question far superior to what was in common use in the US, and given that two hundred years later we're still not using it, I'm not holding my breath for an overnight conversion to ISO. Phil Karn
bzs@bu-cs.UUCP (04/06/86)
I would recommend M.A. Padlipsky's "The Elements of Networking Style" as one (certainly not the only!) book to look at when comparing and contrasting ISO and TCP/IP et al. He's completely and wonderfully biased and the book is just plain fun, I use it in one of my classes. -Barry Shein, Boston University
libes@nbs-amrf.UUCP (Don Libes) (04/06/86)
> I would recommend M.A. Padlipsky's "The Elements of Networking Style" > as one (certainly not the only!) book to look at when comparing and > contrasting ISO and TCP/IP et al. He's completely and wonderfully biased > and the book is just plain fun, I use it in one of my classes. You're kidding. I think that book is complete trash. It ought to be called "M.A. Padlipsky's Incredibly Biased Views about His Own Work". It's certainly not on par with other "Element of ..." books. All he talks about is ISO and Arpanet. There are pretty pictures on the cover about things like Tymnet, Mitrenet, SNA, etc. None of these are covered in the book. All he talks about is why ISO sucks and Arpa is the solution to all ISO's problems. Very little theory. This can be ok, because he seems to know what he is talking about but it doesn't come across in the book because of his incredibly obnoxious style. Incredibly caustic. He insults someone with every other sentence. He explains things by analogizing to the things that most people never heard of, and uses "in" jokes instead of explanations. Because of this, I didn't understand a lot of what he was saying. An example is when he says "they did such and such, because the air must be bad in Gaithersburg" when he is critizing work done at NBS (which happens to be in Gaithersburg, MD). It's not that I was offended by his critizing NBS; rather this was one of the few criticisms I understood (and therefore remember). I have never seen a book so bad before, and am amazed that anyone would publish this garbage. They absolutely gave the guy free reign to do what ever he felt like. If they cut out all the garbage in the book, it would be about 25 pages long. Besides the 6 or so introductions, prefaces and chapters that had absolutely nothing to do with networking, there must have been 30 pages or so of cute sayings, one to a page. Boy, did I feel ripped off. Don Libes {seismo,umcp-cs}!nbs-amrf!libes
dougm@ico.UUCP (Doug McCallum) (04/06/86)
> /* Written 7:04 pm Apr 3, 1986 by djo@ptsfd.UUCP in ico:net.dcom */ > It means that they will be using some or all of the hundreds (literally) of > protocols ISO and/or CCITT are suggesting now or have in the past six to ten > years. It also means that they want you to buy their product. Partially true, but misleading. There are indeed a number of protocols definede, but they are at a number of different levels of the reference model. > Find out what they mean. A good default is (layer 1) rs-232-c/v.35; (layer > 2) LAP B; (layer 3) X.25. They may also support such things as X.75 but don't > bet on it. Layers 4 and up will be their own protocols. Some good advice. Anyone buying or implementing ANY protocol should find out what they mean. You really need to know what the standards are for each layer. This is true for protocols such as TCP/IP as well (just because two vendors support TCP/IP doesn't mean that they support the same physical media). As far as layer 1 is concerned, ISO has already adopted the IEEE 802.{3,4} families. There are standards at Layers 1-5 and Draft International Standards at layers 6 and 7. To be a real ISO network, you must support the standards at all layers. Some vendors will have their own protocols at the higher layers for services specific to that vendor. There are also "national" guidelines for the implementation of the various protocols to ensure conformance between the various vendors. For example, the National Bureau of Standards will soon issue an X.400 product description which specifies which options are mandator/optional/etc. for a US implementation of X.400. Similar specifications exist for other protocols such as transport. In essence, it will be possible to build an ISO-OSI product that will work with other vendors implementations. The MAP and TOP specifications are just such a set of guidelines. TOP specifies such things as IEEE 802.3 as the physical layer, IEEE 802.2 as the link layer, ISO connectionless network protocol at the network layer, ISO transport class 4 (NBS spec) for the transport layer, ISO session (specific subsets) at the session layer, ISO ASN.1 at the presentation layer and ISO FTAM and CASE at the application layer. There is more to it than just those, but this list specifies a full ISO protocol suite at all layers. By implementing to the specifications, compatible implementations can be made. The vendors are also working together to pass conformance tests on their products. > >What does it mean, "DECNET will conform to ISO?" > It means DEC wants you to buy DECNET. It also means that DEC will provide ISO transport protocols on DECNET. They will probably provide some of the higher level protocols as well. They have announced availability of ISO transport class 4 already. > No. The standards for layers 4 and up are WAY up in the middle of the air (see > that wheel inside that other wheel?> ) Not true! Standard protocols exist for layers 4 and 5. Layers 6 and 7 have gone to DIS form (Draft International Standard) and are supposed to go for 6 month ballot in June. There should be International Standards at all 7 layers by the end of 1986. Standards DIS level are also stable enough for an initial implementation. Transport has been a standard for quite some time. Session a little less, but it has been about a year.
djo@ptsfd.UUCP (Dan'l Oakes) (04/08/86)
In article <102@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes: >Not true! Standard protocols exist for layers 4 and 5. Layers 6 and >7 have gone to DIS form (Draft International Standard) and are >supposed to go for 6 month ballot in June. There should be >International Standards at all 7 layers by the end of 1986. Standards >DIS level are also stable enough for an initial implementation. >Transport has been a standard for quite some time. Session a little >less, but it has been about a year. I beg to differ. It isn't officially adopted as a standard until the big books come out every four years (1988 books due out around 1989). Dan'l Danehy-Oakes "The opinions expressed above are no one's but my own, and especially do not represent the opinion of the person to whom I am responding."
dougm@ico.UUCP (Doug McCallum) (04/15/86)
> In article <102@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes: > >Not true! Standard protocols exist for layers 4 and 5. Layers 6 and > >7 have gone to DIS form (Draft International Standard) and are > >supposed to go for 6 month ballot in June. There should be > >International Standards at all 7 layers by the end of 1986. Standards > >DIS level are also stable enough for an initial implementation. > >Transport has been a standard for quite some time. Session a little > >less, but it has been about a year. > > I beg to differ. It isn't officially adopted as a standard until the > big books come out every four years (1988 books due out around 1989). > > Dan'l Danehy-Oakes Well, to correct the correction, I wasn't incorrect (at least not completely). The standards I was refering to are "ISO" standards, not CCITT. In the 1984 CCITT Red Books (note the 1984 and CCITT) CCITT is publishing the Layer 4 (X.224) and Layer 5 (X.225) standards. Also, they are publishing the X.400 family. X.409 is very similar to the ISO Abstract Syntax Notations which is part of the layer 6 standard and the rest of X.400 covers an application layer protocol, etc. That covers most of the bases. Now the real clarification. ISO and CCITT are not the same thing. I should have been more careful in specifying which standards body I was referring to. The adoption procedure within ISO is a little faster than within CCITT. ISO standards get approved at TC97 meetings which happen on the order of once per year. CCITT standards are approved at the end of 4 year study periods. Then there are the various national standards bodies that all have different rules. Doug McCallum Interactive Systems Corp. {ima, hao, cbosgd}!ico!dougm
sjl@amdahl.UUCP (Steve Langdon) (04/18/86)
In article <76@petrus.UUCP> karn@petrus.UUCP (Phil R. Karn) writes: > It is also worth mentioning that I don't think anyone has yet found a > criterion by which "ISO" is somehow "better" than the ARPA protocol suite, > other than its well-trumpeted status as a "future world standard". In fact, > in many ways the ISO network and transport protocols are demonstrably worse > than IP/TCP. > ... Please post some additional information supporting this statement. I would be the first to agree that the ISO standards are not perfect, but I am curious as to why you believe TCP/IP is better. -- Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ]
ch@gipsy.UUCP (Christian Huitema) (04/30/86)
We have been running ISO and TCP-Ip in parallel for some time now at INRIA. This will be reported in the next USENIX conference. Each has pro and contras, so lets state the advantages: For TCP-IP: Already established, comes with a lot of applications likes FTP, TELNET, RLOGIN, SMTP, RSH, etc. Available today on a large range of computer. This is not the case of ISO: the only standard application available today is X400, and in a certain sense the Teletex. For OSI: Getting agreed upon by a large number of manufacturer. Technically much better than TCP-IP, which hardly matches the services of the OSI transport, but does none of the functionalities of the session or presentation layers. We are running OSI on X25 and on Ethernet. We use X25 layer 3 on Ethernet, according to DIS8881, above IEEE802.2 LLC1. We establish X400 connections on an operational basis we other systems in UK and Germany; note that the OSI was independantly developped on these systems. It is extremely easy to set up a random connection using the OSI protocol and X25 networks, whilst to do the same with IP you have to formally interconnect networks. From an architectural point of view, ISO gives you the choice between connection oriented and connectionless networks. In the latter case of ISO-IP & TC-4, you have exactly the same repartition of function has with IP & TCP, with one advantage to IP due to short headers: the IP adresses are 32 bits, while the ISO NSAP addresses can be 20 bytes. On the other hand, there is a possibility with TC4 to negociate the usage of transport level checksum on a per-connection basis. We have measured almost the same throughputs for TCP and the OSI session, in file transfer applications. The OSI code is slightly smaller than the TCP code in the kernel (both are implemented as "sockets" protocols). Christian Huitema (<huitema@gipsy.uucp>)