Why we need a length field in Ethernet while we don't need..

Archived from groups: comp.dcom.lans.ethernet (More info?)

Why we need a length field in Ethernet while we don't need it in FDDI??

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <2f3b012a.0501180104.3a1dc7cd@posting.google.com>,
levin_ae101hk@yahoo.com.hk (levin) wrote:

> Why we need a length field in Ethernet while we don't need it in FDDI??

Clearly, school has started for the Winter Quarter/Spring Semester.
(Seeing that the poster is from Hong Kong, it may be his Summer
Quarter/Fall Semester.)

That said, we *don't* need a length field in Ethernet. The fact that the
vast majority of Ethernet frames ever sent (e.g., those carrying TCP/IP
payloads) do not contain an Ethernet length field speaks volumes.

What I find more amazing is that, in this day and age, networking
instructors are still teaching FDDI and Token Ring technology as if was
something *necessary* for the emerging professional to understand (other
than for historical, "how did we get here" reasons.) I agree that:
(1) it is useful to understand the various ways in which a shared-access
medium can be arbitrated, and (2) new media may indeed necessitate the
use of such access methods (or new ones based on the same principles).

However, what I generally see is instruction that is more in tune with
the 1980s, when shared-media LANs were dominant, and there was market
competition among systems using different access methods. This is no
longer the case. Part of the problem may be that most existing texts
dedicate a lot of pages to this subject; the teacher is either loath to
dispense with it, or doesn't have anything else prepared to take its
place.

When I teach LAN technology, I discuss shared-media access and the
tradeoffs among access methods in a more "abstract" manner, i.e., what
system characteristics would lead you to use contention access vs.
polling/token-passing; the "details" of 802.3 vs. 802.4 vs. 802.5 vs.
FDDI are used merely as *examples* of those tradeoffs, not as "important
distinctions" among competing technologies.

Also (for what it's worth), you can watch a streaming-video sample of a
LAN class I taught a few years back, at:

http://tippytoe.multicasttech.com/ [...] g/index.ht
ml


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Archived from groups: comp.dcom.lans.ethernet (More info?)

Jens Link wrote:

> Rich Seifert <usenet@richseifert.com.invalid> writes:
>
>> What I find more amazing is that, in this day and age, networking
>> instructors are still teaching FDDI and Token Ring technology as if was
>> something *necessary* for the emerging professional to understand
>
> Well they teach classfull IP Networking (and only classfull) too. And
> even today you can find TokenRing Networks, we just pulled out the last
> components in December.

A friend says he still has one arcnet network at a client! As for token
ring, FDDI & classfull IP, they should only be taught for historical
background. Any instructor who presents them as current technolgy needs to
have his course updated. Even IBM's given up on token ring.

This sort of reminds me of my high school electronics class (many years
ago). Virtually the entire course was about vacuum tubes, with only a
brief look at transistors. A year later, I was working with integrated
circuits, which hadn't even been mentioned in that electronics class.
The kids who are preparing for tomorrow seem to get stuck being taught about
yesterday's technology.

Archived from groups: comp.dcom.lans.ethernet (More info?)

You don't


--

hsb


"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <csk1jk$c8q$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
>In article <86llaqzal4.fsf@quux.de>, Jens Link <usenet02@quux.de> wrote:
>>Rich Seifert <usenet@richseifert.com.invalid> writes:
>
>:> What I find more amazing is that, in this day and age, networking
>:> instructors are still teaching FDDI and Token Ring technology as if was
>:> something *necessary* for the emerging professional to understand
>
>:Well they teach classfull IP Networking (and only classfull) too.
>
>It also turns out that in some circumstances, the Cisco PIX software will
>default netmasks according to the IP class.. even in cases where the
>IP is in the subnet assigned to an interface and so the netmask would
>be easily deducable.
>
>There is also a circumstance under which the Cisco VPN software
>will get told a classfull subnet mask by any of Cisco's devices
>that support IPSec, such as the PIX, VPN Concentrator, or IOS with
>IPSec Feature Set.
>--
>Can a statement be self-referential without knowing it?

We are still running some systems that identify themselvs as
'SYSTEM V/68 Release R3V6 Version 990318 M68030'
and the Copyright is
Copyright (c) 1984 AT&T
Copyright (c) 1985 Motorola, Inc.
They still work in terms of the old Classes!
--
Tom Schulz
schulz@adi.com