From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 29 Jul 92 03:07:47 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Jul28.175418.23747@acc.com>, art@acc.com (Art Berggreen) writes:
> In article <nrksjfc@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Well, I think bridges in general are nasty, because I'm of the routing
> >faith.  More precisely, bridges and routers/gateways are the same kind
> >of boxes, except that bridges are particularly stupid (well, limited)
> >routers.
> 
> I think philosophically, we're in general agreement.  For Routeable protocols
> I much prefer routing.  But I do understand customer desires for simple
> plug-'n-play devices.  But I think the success of homogeneous local
> bridges has set unrealistic expectations for multimedia bridges.

Agreed on all points.

> >IP fragmentation is a trivial bit of work, and far less that all of IP
> >routing.
> 
> You do save the dynamic routing algorithms, but I'm not convinced that
> the forwarding is that much simpler (to be done right).
> 
> To do IP fragmentation correctly, it should be able to generate ICMP
> errors (if DF is set).  It needs to at least know IP option syntax to
> properly copy options to fragments.  To insure that it does those
> correctly, it needs to at least partially parse the IP header and
> verify the header checksum.  It also obviously needs to know about
> IP addresses and be careful about IP and/or media broadcasts.  If it
> does generate ICMP, what source address does it use?  Of course it needs
> to be able to generate the proper headers with new checksums on the
> fragments.  Then there is the question of what is should do about IP
> Path Discovery. A translating bridge already has to rewrite MAC headers,
> which similar to the effort for an IP router just to add a new MAC header.

Good points, except that bridge-spanning tree fixes the usual media vs.
IP broadcast hassles.  Also, since most systems seem to be using SNMP
for control ("network management" for anyone who inists on the high
toned, technological term), having an IP address for ICMP's doesn't seem
hard.  The MAC address rewriting for FDDI-ether bridging is trivial
and is supported by hardware, making the MAC header rewriting more trivial
for a bridge than for an IP router.  If I were building such a box, I
might not verify the IP checksums.  I might simply adjust the existing
checksum for the new IP headers, preserving errors and letting the
destination worry them.

I suspect the main advantage is that small packets do not need to be
examined by a CPU.  You have all day to fiddle with packets >= 1500
bytes, but it is more difficult to IP-route 29 byte UDP/IP packets with
one data byte.  If you can just point your hardware at a giant CAM
such as DEC uses, such tinygrams should be easy to bridge at FDDI media
speeds, as DEC claims to do.


> >DEC is among the vendors of such more-than-bridges-less-than-routers.
> >I think they call their boxes "transparent bridges," like others in
> >the industry.
> 
> That still doesn't make it good technology.

I've observed that the word "technology" has become a synnonym for
"male bovine manure".  Every time you hear a form of "technology",
substituted the appropriate form of the slang, and notice that the
sense is not only preserved but made more clear.


Vernon Schryver,   vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi