Re: Routers vs. Bridges


Charles Hedrick (hedrick@athos.rutgers.edu)
Fri, 11 Dec 87 03:08:30 EST


>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.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:57 GMT