Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!bloom-beacon!martillo
From: martillo@athena.mit.edu (Yakim Martillo)
Newsgroups: comp.dcom.lans
Subject: Re: OSI-model software
Message-ID: <933@bloom-beacon.MIT.EDU>
Date: Mon, 15-Jun-87 21:05:38 EDT
Article-I.D.: bloom-be.933
Posted: Mon Jun 15 21:05:38 1987
Date-Received: Sun, 21-Jun-87 04:09:20 EDT
References: <1204@botter.cs.vu.nl> <1680@munnari.oz> <192@ditmela.OZ> <920@bloom-beacon.MIT.EDU> <8613@amdahl.amdahl.com>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: martillo@athena.mit.edu (Yakim Martillo)
Organization: MIT Project Athena
Lines: 57
Keywords: osi, iso, internetworking

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.