The All-New Switch Book: The Complete Guide to LAN Switching Technology, Second Edition

10.2. Trimming the (Spanning) Tree

Ideally, we would want multicast traffic to traverse only those links in the catenet that either:

• Have stations directly attached that want to receive the particular multicast

• Are needed to reach some station(s) that wants to receive that multicast traffic

Propagating multicast traffic on any other links is simply wasteful. Note that unicast traffic is propagated perfectly (according to these two principles) by the natural action of the learning and forwarding algorithms in switches. By learning the relative location (port mapping) of each unicast address, switches can forward traffic onto only those ports actually needed to reach a particular station. As depicted in Figure 10-2, unicast traffic flows on the minimum subset of the spanning tree needed to deliver the frame from source to destination. Wouldn't it be great if this happened automatically for multicast as well? Well, too bad, it can't. The problem is that there is no way for a switch to determine which stations need to receive which multicast groups by simply inspecting the traffic. Multicast addresses are never used as Source Addresses, so they cannot be learned like invention of a new unicasts. If we want to restrict the unnecessary propagation of multicast traffic, we will have to do something different.

One possibility is to manually configure the switches with the mapping of multicast ...