[comp.protocols.tcp-ip] Brouters

ykluger@HAWK.ULOWELL.EDU (Yoav Kluger) (11/23/88)

Hi,
I have been hearing lately too much the term BROUTER.
Is there a formal or even an informal but well agreed upon definition
for this creature?
  - Is it a bridge and a router in one box?
  - Is it a back-bone bridge?
  - Is it a bridge that does some LLC-header replacement (depending
    on the interface the packet is coming from and going to)?
  - Is it none of the above?

There was a bird-of-a-feather session about brouters in the conference,
which wasn't much helpful at all, and I haven't been able to find
this term in any of the literature I know of.

Could you help in this?

Thanks,

Yoav.

craig@NNSC.NSF.NET (Craig Partridge) (11/24/88)

My understanding is that a brouter is a box which:

    (1) acts as a router for those protocol suites it understands

	and

    (2) bridges those protocol suites it doesn't understand

It figures out which protocol suites it understands by looking at the
link level protocol identifier.

The idea is to get around the problem of choosing between routers (which
are relatively good firewalls but only handle the protocol suites they
understand) and bridges (which are lousy firewalls but handle all protocol
suites).

Craig

jqj@HOGG.CC.UOREGON.EDU (11/24/88)

"Brouter" is not a well defined term.  To a first approximation, it
means some combination of MAC-level bridge and network-level router
*functionality* in the same box.  There are lots of possible schemes for
mixing these two beasts, and all the schemes have some claim to the
term "brouter".  The industry hasn't made up its mind.

Presumably, a "bridge" is a MAC layer product (more specifically an
802.3 product) that forwards packets, usually with filtering based on
destination address.  Most bridges these days support some spanning
tree algorithm that takes a complex bridged topology and turns off
enough forwarders to create a simple tree.  Some remote bridges support
parallel ptp links between two bridges, allowing limited load sharing
(e.g. 2 56Kb circuits connecting a single pair of bridges and giving
near-128Kb thruput).  Some remote bridges allow filtering based on
packet characteristics as well (e.g.  type field).

On of the first uses of the term "brouter" was in the product
literature for the RAD "Remote Ethernet Bridge".  RAD's bridge is a
remote bridge that operates totally at the MAC layer connecting 802.3
segments (Ethernet, Starlan, etc.) but that allows multiple
simultaneous paths between pieces with load balancing, loops, etc.
Note that this is much more complex than redundant ptp links between a
pair of bridges, but that it does not require a network-layer router.

The cisco Systems "HyBridge" has also been called a "brouter".  That
product, like a similar product from Wellfleet, combines bridging and
protocol-dependent routing in one box.  One can route some protocols
(as defined by the Ethernet type field) and not simply forward their
packets, while bridging all other packets.  Note that most protocol
stacks involve special handling of several type fields (e.g. TCP/IP
requires coordinated handling of IP and ARP packets, which I suspect
means that if you route IP you can't bridge Chaos).

Other vendors use "brouter" for mostly-MAC bridges that connect
disparate media, e.g. Ethernet to 802.3+802.2 or 802.3 to 802.4, or for
token ring "bridges" which should be quite a bit smarter than 802.3
bridges.  See the January 1988 IEEE Networks magazine for more
information.

Note also that "bridge" is used in the Novell and LocalTalk worlds for
what we TCP/IP types call a "gateway," i.e. a router.

ykluger@HAWK.ULOWELL.EDU (Yoav Kluger) (11/25/88)

This is just to acknowledge the receipt of your message and thank you
for it.
My understanding now is that different people call different animals
by the name "brouter", and there isn't a formal definition for it.
So I feared.
Just recently I have heard of a new creature invented (or at least
pursued) by DEC. I don't know much about it, but it seems this new
box attempts to replace one LLC+MAC header with another, thus working
at a level higher than level 2, yet not try to understand any portion
of the LLC data (e.g. a Network layer header), thus working at a level
lower than level 3. I wander if this strategy is well thought out, but
at a first glance it seems as a rather interesting way to get over the
clasic problem of connecting two different networks with a bridge, yet
maintain the most cited advantage of a bridge over a router - the
transparency attribute.

Thanks again,

Yoav.

P.S. Interestingly enough, my mailer daemon has omitted your name from
     the end of your message, and now I don't know who you are.

ykluger@HAWK.ULOWELL.EDU (Yoav Kluger) (11/25/88)

This is just to acknowledge the receipt of your message and thank you
for it.
My understanding now is that different people call different animals
by the name "brouter", and there isn't a formal definition for it.
So I feared.

Just recently I have heard of a new creature invented (or at least
pursued) by DEC. I don't know much about it, but it seems this new
box attempts to replace one LLC+MAC header with another, thus working
at a level higher than level 2, yet not try to understand any portion
of the LLC data (e.g. a Network layer header), thus working at a level
lower than level 3. I wander if this strategy is well thought out, but
at a first glance it seems as a rather interesting way to get over the
clasic problem of connecting two different networks with a bridge, yet
maintain the most cited advantage of a bridge over a router - the
transparency attribute.

Thanks again,

Yoav.

leong+@ANDREW.CMU.EDU (John Leong) (12/01/88)

> but it seems this new box attempts to replace one LLC+MAC
> header with another .....  at a first glance it seems as a rather
> interesting way to get over the clasic problem of connecting
> two different networks with a bridge

Such blind replacement seems unlikely to be workable for bridging between
Ethernet and Token Ring.  Token ring bridging requires source routing with
dynmaic route discovery involving the bridge.

John Leong   leong+@andrew.cmu.edu