Seifert c10.

tex V3 - 06/28/2008 5:35pm Page 417

Chapter 10 ■ Multicast Pruning 417

Ethernet has had multicast capability since its commercial inception, but
some protocol suites simply ignored the facility. (Most of the multicast-enabled
protocol suites, including DECnet and AppleTalk Phase 2, came from network
architects who did get it.) In particular, many of the support protocols in IP,
such as ARP and RIP, use the broadcast address rather than a protocol-specific
multicast. There is no excuse for this. ARP was designed specifically for
Ethernet; its use of broadcast is not a historical artifact. As a result, devices that
don’t even use IP have to receive and process all of the ARP and RIP traffic just
to figure out that they should discard it.
Token Ring adopters further contorted the concept of multicast by
implementing Functional Group Addressing (discussed in Chapter 3, ‘‘Bridging
Between Technologies’’), where individual bits in the address map to fixed
functions. Again, this is an example of network architects unable (or unwilling)
to grok the multicasting concept.
Multicast provides an elegant way for applications to communicate without
burdening any machine not currently running that particular application. Until
the application instantiates itself on a computer, the network interface can
ignore all traffic destined for the multicast address(es) particular to that
application. Coupled with a good implementation of multicast filtering in the
interface hardware, multicast provides incredible flexibility and efficiency.
In fact, with proper use of multicast techniques, there is never, ever a valid
reason to send frames to the broadcast address. Broadcast can be eliminated
from the architecture. We considered not defining a broadcast address in the
original Ethernet design, but left it in (for political and historical reasons) with a
disclaimer: ‘‘The use of broadcast is expressly discouraged’’ [DIX80, DIX82].
Broadcast places a burden on every station in the catenet, regardless of
whether it understands the message being sent. If you want to send a message
to every station on the catenet that can understand it, just define a multicast
for that purpose. There are 247 of them to choose from! Don’t waste your time
sending messages to stations that can’t understand them.
Some early Ethernet hardware didn’t do a very good job of multicast filtering,
so multicast didn’t provide much of a performance benefit over broadcasting.
However, this is no excuse for using the broadcast address instead of a
multicast; multicast is never worse than broadcasting. Using broadcast is just
dumb design.

10.1.2 Application Use of Multicast

To understand the nature of the multicast distribution problem better, let’s look
at the purpose(s) for which applications use multicasting and the implications
of the default switch behavior for multicast traffic.