HANK@TAUNIVM.BITNET (Hank Nussbacher) (12/10/87)
I know this has been covered once before but I am preparing a paper on the benefits of routers over bridges and bridges over routers. Specifically, there are routers today that handle multiple protocols (cisco and proteon to name two) and there are bridges that are starting to handle alternate routing and allow the construction of a closed network loop. What I would like to receive (please reply directly to me and not to the list) are examples and explanations of what a router can do at level 3 that a bridge just cannot handle. And why is it so important to be able to do it. When I have finished creating my document I will post it to the this list. If you have any articles or papers you would like to send to me on the subject, please send them to: Henry Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel Thanks, Hank
radia@XX.LCS.MIT.EDU (Radia Perlman) (12/10/87)
The January, 1988 issue of IEEE Network magazine has multiple articles on bridges vs routers. I wrote one of them. The main problem with the "bridge vs router" issue is defining what a bridge vs a router is. You could define an entire network architecture and declare that to be your data link layer, and claim then that the box that forwards packets is a "bridge" because it operates at the "data link layer". My contention, though, is that a Data Link layer header only has in it information to deal with one hop -- one pair of addresses, (source and destination), no route, no hop count, etc. Since the Network Layer handles multiple hops, if a header is defined with two pairs of addresses (ultimate source, ultimate destination plus immediate source and immediate destination), hop counts, routes, etc, then I claim it's a Network Layer protocol. For instance, I claim the DEC bridge is clearly a bridge (although it allows store and forward) because as far as the end stations are concerned, they are dealing only with a Data Link protocols -- the header they see fits my description of a Data Link header. The "source routing bridge", on the other hand, I'd claim is clearly a router and not a bridge, because it requires end stations to discover and place a route in the header. You may want to wait until the January IEEE Network comes out for many different viewpoints on this issue. If you'd like to study the issue independently, I'd suggest starting with a rigorous definition of "routers" and "bridges" that clearly places a box in one category or another, before trying to argue the merits of each kind of box. Radia -------
braden@VENERA.ISI.EDU (12/11/87)
Here is one way you might decide if a given box is a bridge or an IP gateway (aka router): see if it forwards a local network broadcast packet. A bridge "must" forward broadcasts, while a gateway "must never" forward one. Another test: see if the IP network number changes when the packet is forwarded. A bridge must not change anything in the IP header, while a gateway "must" change the IP destination address. These two tests give some clues about the advantages of gateways over bridges. Bob Braden
braden@VENERA.ISI.EDU (12/11/87)
As Bill Westfield immediately pointed out to me (SIX MINUTES later!), my brain was disengaged when I sent a message earlier. Sorry. Here is what I meant to say: ___________________________________________________ Here is one way you might decide if a given box is a bridge or an IP gateway (aka router): see if it forwards a local network broadcast packet. A bridge "must" forward broadcasts, while a gateway "must never" forward one. Another test: see if the destination local network address changes when the packet is forwarded. These two tests give some clues about the advantages of gateways over bridges. Bob Braden ----- End Forwarded Message -----
hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) (12/11/87)
>Another test: see if the IP network number changes when the packet is >forwarded. A bridge must not change anything in the IP header, while a >gateway "must" change the IP destination address. One hopes the IP network number doesn't change when a gateway forwards a packet. The only thing that would normally change is TTL. The problem with trying to define these things is that there are hybrid beasts, e.g. bridges that allow the user to specify filtering using boolean operations on arbitrary bytes in the header. One could (and indeed probably should) set up such a bridge so it did not pass IP broadcasts. There seems to be a continuum possible. I have evidence that as time goes on, we're going to see a lot more points in that continuum. E.g. boxes that act as true gateways for IP packets and bridges for everything else, and bridges whose routing is as complex as an IP router, but applied to the MAC address instead of the IP address. I'd say that to qualify as an IP gateway by modern standards you need to process correctly most of the fields in the IP header, including decrementing the TTL, doing type of service routing, implementing source quench, source routing, record route, etc., and doing fragmentation. The claim that a bridge is all you need is equivalent to the following claims: - that everything in the IP header other than source and destination is unnecessary. - that it makes sense to build routing on top of an address with no internal structure. (That is, the MAC addresses have no pattern to them. IP gateways normally have to figure out a route to each network that they can reach. A bridge has to keep track of distinct MAC addresses. The thought of a gateway that knows every address in the Internet is absurd. So in effect the bridge's knowledge may be just a cache. But then you need a way to find a route initially. There are many such schemes, but they all run into trouble for very big networks.) - that ICMP functions, e.g. unreachable, and source quench, are unnecessary. (I don't mention redirects, because they obviously are unnecessary in a system using bridges.) In short, that the IP network layer is unnecessary. In my opinion, you can survive without a full network layer in a small, homogeneous system. So I have no problem with using LANbridges to connect a few Ethernets (though I wouldn't do it myself). But if the network layer is unnecessary, how come every protocol has one, and attempts to do routing at the MAC layer end up reinventing them (e.g. the IBM MAC-level source routing, and other ISO MAC-level network functions)? Again, I have no doubt that there are uses for LANbridges and similar gadgets. But at some point you have to draw the line, and start using the facilities that the protocol designers have supplied for you. The question is where that line is. One has a suspicion that when you start having a network of bridges running a full-scale routing protocol, there's a good chance you've crossed the line. On the other hand, there may be cases where for various practical reasons, such a product would actually be useful.
radia@XX.LCS.MIT.EDU (Radia Perlman) (12/11/87)
Just a clarification -- bridges don't HAVE to forward multicasts (broadcasts)
in order to be a bridge. The Vitalink and DEC bridges have the capability
to manually set certain multicast addresses as "don't forward". This
is very important for various reasons. The default is "forward", but
some finite number (large enough for all practical purposes, I claim)
of multicast addresses can be manually configured to be localized, i.e.
not forwarded by the bridge.
Once people agree on what a bridge vs a router is, I'd summarize the
tradeoffs as:
1) bridges don't require a standard layer 3 (win for bridges unless
suddenly layer 3 standards crystallized and universalized)
2) routers can do much fancier stuff because of the extra layer
of header and explicit cooperation from the stations, like
utilizing better routes, or utilizing hierarchical addresses
3) even if layer 3 standards crystallized, a mixture of bridges and
routers might be desirable because it gives an extra level
of hierarchy "for free". In other words, it might be efficient
to clump LANs into big LANs, and then the layer 3 protocol
doesn't have to trouble itself with the inner topology of
the bridged extended LANs.
Radia
-------srg@quick.COM (Spencer Garrett) (12/18/87)
Actually, it's pretty easy to tell whether a box is a gateway (router) or just a bridge. If it has a network address, it's a gateway. If it doesn't, it's a bridge.
roy@phri.UUCP (Roy Smith) (12/19/87)
In article <173@quick.COM> srg@quick.COM (Spencer Garrett) writes: > Actually, it's pretty easy to tell whether a box is a gateway (router) > or just a bridge. If it has a network address, it's a gateway. If it > doesn't, it's a bridge. I'm really out of my league here, so don't hesitate to correct me if I'm wrong, but isn't it possible to have a bridge which has no IP address of its own as far as moving packets around goes, but does have an IP address for communicating with the box for control purposes? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016