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

Internet Message Format | 1993-01-26 | 3.0 KB

Xref: sparky comp.protocols.nfs:3214 comp.dcom.isdn:1235
Path: sparky!uunet!gossip.pyramid.com!pyramid!infmx!johng
From: [e-mail] (John Galloway)
Newsgroups: comp.protocols.nfs,comp.dcom.isdn
Subject: Re: Low cost ether/isdn brouters
Message-ID: <[e-mail]>
Date: 26 Jan 93 01:17:30 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Usenet News)
Distribution: na
Organization: Galloway Research
Lines: 44

In article <[e-mail]> [e-mail] (Dave Carr) writes:
>In <[e-mail]> [e-mail] (John Galloway) writes:
>
>Do you want the B-channels up permanently?  You probably want dial on
>demand, with some intelligence at both ends to establish the link only
>when required.  Given the choice between a standard bridge or router,
>the router wins.  But is a full router necessary in this case?
Likely 1 B channel up all the time with the other being added on demand.
The only way ISDN is affordable is via centrex, and intra-centrex calls
are fee so why not leave it up?
>
>I would argue that very little router code needs to be added to the
>bridge to gain this functionality.  By adding static routing to our bridge
>I believe we have met your needs.
Agreed.  Just simple IP routing (as mentioned in a pervious post) would
be fine.  SNMP is nice, but cost is the dirving factor here so if not
having a full tcp/ip stack is easier/less-expensive, then it would be fine.
>
>Bonding makes one 128K channel by interleaving at the data stream bit level.
>It is necessary to account for the different delays between  the B channels.
>The alternative is to run LAPB multilink protocol.  But you are right.
>There is no standard yet on multilink.
>
>With bonding you only have one channel.  With some software running on top
>of multilink, you can split the packet in pieces and load balance.
>Fragmentation in this case is not done like a router, but similar to the
>more bit in X.25.

These two topcis are also realated.  If running completely seperate
B channels, then a user could leave one up all the time (and have a single
B chanles worth of resource on the host end dedicated to this user) but
only add the second on demand and thus have something like 1.25 B channels
for each user at the hub, and give 2 64K channels to most folks when
the need arises, but not have to have 2B channels dedicated to each user.
Digiboard claims they can do this with their IMAC with each B channel going
to a different user.  However this scheme would not allow the 2Bs to be bonded.
In part this comes down to the question: do apps like ftp want an
ack after every packet and hence not be able to make use of 2 64K channels
as opposed to one 128K channel?
    -jrg
--
internet    [e-mail]  John R. Galloway, Jr  795 Beaver Creek Way
internet    [e-mail]     CEO...receptionist    San Jose, CA   95133
applelink   D3413                  Galloway Research     [phone]