NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/protocol/nfs/3205

Internet Message Format | 1993-01-24 | 3.6 KB

Xref: sparky comp.protocols.nfs:3205 comp.dcom.isdn:1220
Newsgroups: comp.protocols.nfs,comp.dcom.isdn
Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!carafe.enet.dec.com!goldstein
From: [e-mail] (Fred R. Goldstein)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Digital Equipment Corp., Littleton MA USA
Date: Sun, 24 Jan 1993 05:47:12 GMT
Lines: 60


Am I the only one in here who's an actual paying CUSTOMER of an
ISDN bridge provider?  Here it is getting past bedtime and I'm logged
in via my Gandalf 5510...

Okay, here's the skinny.  Bridges sound great, and they're okay, but
you have to have intelligence in them.  NOBODY has it right, and
I've given equisitely detailed descriptions of what I'd like to see
to the three ISDN Bridge vendors I'm aware of in the US:  Gandalf,
Combinet and Digiboard.

The real problem is that there's far too much multicast and/or
broadcast traffic on the real LAN to allow a normal bridge to
operate.  If you have 50 people and just TCP/IP, you're okay.  But
I've got The Lan From Hell to deal with, an FDDI+Ethernet backbone
with well over 2000 nodes.  I attached my Gandalf 5520 central-site
bridge to it and it crapped right out.  Why?  Because DECnet uses
multicast like crazy.  The Digiboard (better stats) clocks the
residual (midnight) multicast level at over 350 kbps.  Most of it
is "end system hello" messages, which DECnet uses because it doesn't
have ARP.  TCP/IP's broadcast traffic is manageably low.  It lasts
for more than 15 seconds (default DECnet timer).

But I don't want/need a router at home.  I use DECnet and TCP/IP
both, and real DECnet routers aren't that common (though not rare).
What I ended up doing was hiding the Gandalf 5520 dial-in machine
behind a little multiprotocol router (Ethernet-to-Ethernet); this
keeps the multicasts away and creats a tiny (ISDN only) LAN with
negligible multicast.

A home bridge with one node behind it doesn't need any filtering,
period.  A home bridge with multiple nodes needs filtering, but
the typical 15-address hardware filter should be enough.

The central site bridge needs the smarts.  It needs to pass
SELECTIVE multicasts -- intermediate system hellos, which are
sparse, but not the other crap -- onto the ISDN.  It does NOT need
to learn every node on the big LAN; it need only forward stuff
that's destined towards the dialed-in user.  That's an "include-only"
algorithm instead of the 802.1 "exclude-only" spanning tree.  The
spanning tree is needed to support redundant links, but that's a
different market.

Routing at home is overkill.  Dialing in to a router is not overkill,
but is not necessary IF the bridge is smarter than what we can get
today.

BTW, I'm becoming of the opinion that "real" ISDN bridge gear with
a built-in TA is not necessarily right.  At the dial-in site, it
may be easier to use PBX-derived Switched 56 (every PBX has it now)
or even ordinary T1 digital CO trunks that don't say "ISDN" on them.
These will pass 56 kbps over domestic "speech" calls.  Also, if
you can't get ISDN at home, you are likely to be able to get Switched
56, so a bridge with a DSU instead of a TA could be handy.  This would
be a moot point if our telcos were better about ISDN -- this is
America so only some states have much ISDN.
---
Fred R. Goldstein   [e-mail]
k1io             or [e-mail]   voice:[phone]
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.