Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!husc6!think!ames!pioneer!lamaster From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.dcom.lans Subject: Re: OSI-model software Message-ID: <1800@ames.UUCP> Date: Wed, 17-Jun-87 15:06:11 EDT Article-I.D.: ames.1800 Posted: Wed Jun 17 15:06:11 1987 Date-Received: Sun, 21-Jun-87 10:19:49 EDT References: <1204@botter.cs.vu.nl> <1680@munnari.oz> Sender: usenet@ames.UUCP Reply-To: lamaster@pioneer.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 70 Keywords: osi, iso, internetworking 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")