Thread View: mod.protocols.tcp-ip
2 messages
2 total messages
Started by bill
Thu, 02 Apr 1987 20:19
Re: Response to anti-bridge comments
Author: bill
Date: Thu, 02 Apr 1987 20:19
Date: Thu, 02 Apr 1987 20:19
59 lines
3605 bytes
3605 bytes
> Date: Tue, 31 Mar 87 15:33:29 EST > From: jas@monk.proteon.com (John A. Shriver) > Subject: Response to anti-bridge comments > The very nature of bridges prevents you from doing load > sharing (unless you manually program the filtering/forwarding > databases, giving up the advantages of adaptive bridges). I don't think it's anything intrinsic about a Bridge that would prevent you from doing load sharing. It's only a function of the current Bridge software that this isn't currently possible. One simple scheme that I just happened to think of off the top of my head would involve having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would handle those Ethernet addresses which modulo 2**N matched its own assigned Bridge number. A hot spare could detect the failure of any particular live Bridge, and take over for it. One Bridge could be designated to handle broadcast packets. Does anyone know if such a scheme or anything similar has been considered for doing load sharing across Bridges? It doesn't seem that it would be that difficult to implement. By the way, in practice, at least at our site, the level of traffic through our Ethernet Bridges is nowhere near significant enough to even start to worry about load sharing, and we have a fairly extensive Ethernet based network in active use here at NRL. > Gateways > with multipath internal routing algorithms can do load sharing, look > at BBN's PSN software using SPF on the ARPANET and MILNET. Sooner or > later, a network gets big enough and complicated enough that one > migrates from bridges to routers. Although Gateways/Routers COULD also do load sharing with appropriate routing algorithms, it is my understanding that all of the current Gateways, even those with SPF routing, DO NOT currently do any kind of load sharing, and only understand and compute a single path to any given destination. I specifically asked this question at the TCP/IP Interoperability Conference held just recently in Monterey, and that was the answer I was given by someone involved with the SPF routing Gateways. > What the advocates are arguing about is where the line between bridges > and routers is. I think there are appropriate circumstances to use both Bridges and Gateways/Routers. The primary benefits that I see for using Bridges, given the state of current technology, is ease of installation, monitoring, and management, and the fact that they are protocol transparent to the higher layer protocols. In the future, they will probably even be used to connect dissimilar technologies, such as Ethernet and FDDI Fiber Optic networks. But Gateways certainly have their appropriate niche also, such as providing a higher degree of isolation between the connected networks when this is desirable. -My first plunge -Bill Fink bill@NRL-LCP ------
Re: Response to anti-bridge comments
Author: kik
Date: Mon, 06 Apr 1987 07:26
Date: Mon, 06 Apr 1987 07:26
29 lines
2105 bytes
2105 bytes
I get the impression that, in the discussion on Bridge functionality,
people are not taking enough trouble to distinguish between the *service*
and the *communications*.
The service is to filter and forward, based on destination address.
There is no reason for the filtering not to be shared, in a disjoint way,
by any number of devices. In fact, we intend to do this. The load-sharing
and backup algorithms are designed and we plan to implement them on our own
equipment once we get the time.
The communications can be based on point-to-point links, satellites,
etc. In fact, the choice of communications is limited only by your
networking ability. For example, DEC and Vitalink have "invented" a
spanning-tree approach to provide redundant communcation. This is really
primitive. We, at CERN, use a genuine communications subnet with all of
the build-in advantages (originally designed for inter-computer traffic,
and all the better for that!). The ideal backbone for such purposes would
be a high-speed bus-type network (we're hoping for FDDI).
I am trying to rewrite the IEEE 802.1 document on MAC-level bridges to
reflect the clear separation between
a) address resolution and
b) routing
so that the current confusion can be avoided.
Cheers
Crispin PINEY
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads