Multicast Routing

The sending of multicast traffic and the reception of this traffic by end stations will require you to coordinate the actions of your RPs and switches. The previous section discussed how the RPs discovered the end stations and the multicast applications in which they're participating. This section discusses how information gets from the server to the end stations, along with the following multicast routing issues:

• RPs discovering multicast end stations and servers

• RPs sharing multicast information with each other and establishing a path from the server to the end stations

• RPs sharing their list of end stations with switches

• RPs forwarding multicast traffic to end-station segments

• Switches receiving multicast traffic from the RPs and intelligently forwarding it out only ports that have participating end stations

Overview of Routing Multicast Traffic

One of the problems of traditional routing protocols is that the RPs will not forward local broadcast and multicast traffic. Therefore, the multicast end stations never see the traffic that they want. With traditional routing protocols such as RIP, OSPF, and others, RPs make their routing decisions based on a specific destination IP address, using their routing tables to help them correctly forward their packets. Unfortunately, multicast traffic does not fit very well into this scheme because the actual destination can be many end stations. To overcome this, the RP could flood the multicast traffic. The downside of that approach is that the RP would forward traffic to every segment in the network even segments that have no participating end stations, which wastes bandwidth.

A more preferable solution is one in which the RPs interact with each other to share information about their knowledge of multicast end stations. RPs could then make intelligent forwarding decisions based on this information, thus minimizing the effect of the multicast traffic on the network.

Multicast Distribution Trees

To forward multicast traffic intelligently, the RPs must be able to build a distribution tree. A distribution tree is somewhat similar to the spanning tree used by switches to remove Layer 2 loops. Using a distribution tree, the RPs can ensure that a multicast frame traverses a segment only once in the network. This minimizes the bandwidth impact, which is accomplished by making sure that there's one and only one path from the source of the multicast traffic to each of the end stations that wants to see it.

These trees are loop-free, which means that multicast frames are replicated only when the tree branches, and then it's guaranteed that the multicast frame will not return to a branch that it has already traversed. Only segments that have either multicast clients or the paths required to reach those multicast clients will have multicast traffic traversing them. Because group members can join and leave at any time, the distribution tree that's built by the RPs must have the capability to be updated based on these changes. When a segment no longer has participating multicast end stations, the RP connected to it should prune that segment from the tree.

Shared Distribution Tree

With a shared tree, only one copy of each multicast frame is forwarded to those segments that have participating multicast end stations.

A shared distribution tree contains a router, sometimes referred to as a rendezvous point, that's the central point of the tree for all multicast traffic. All traffic from every multicast application in your network is first forwarded to the rendezvous point. From there, the multicast traffic uses a single-tree structure for the dissemination of the traffic, creating less overhead on the RP. The downside is that for certain multicast streams, suboptimal paths can exist.

This tree structure is very similar to common STP: For the entire switched network, there's only one tree structure, with the rendezvous point functioning as the root of the tree.

One advantage of this approach is that there's only the overhead of creating and maintaining a single-tree structure. The downside, however, is that in many instances, suboptimal paths exist between the source application server and the destination end stations, thus resulting in undesirable latency. This could be problematic for delay-sensitive multicast applications. The other disadvantage of this approach is that the rendezvous router could create a bottleneck if your multicast servers are generating a large amount of multicast traffic.

Source-Based Distribution Tree

Like shared distribution trees, source-based distribution trees guarantee that multicast traffic will traverse a given segment only once. However, unlike shared trees, where there's a single tree for the whole network, source-based implementations have a separate distribution tree for each multicast group.

A source-based distribution tree builds a single, optimal, shortest-path tree from the multicast source (the root of the tree) to each of the participating end stations (the leaves of the tree). There is a separate tree for each multicast group (address), allowing for optimal delivery of multicast streams, but this creates more overhead on the RP.

This process is more similar to Cisco's PVST there's one instance of STP per VLAN. In this case, there's one source-based tree per multicast group. Source-based trees use a technique called reverse path forwarding (RPF) when building their trees. This process has the RPs building the tree from the leaves (the end stations) back to the root (the multicast server). With unicast routing, the routing path is built from the source to the destination, but it's the reverse for source-based trees.

A large advantage of this approach is that the tree created for a multicast application will be optimal. The downside, however, is that there's a lot more overhead (many more trees that have to be managed) than using a shared distribution tree.

Multicast Routing Protocols

The type of distribution tree you should use is dependent on the multicast routing protocol you choose to run on your RPs. Some use a shared tree, whereas others use a source-based tree. The choice of your multicast routing protocol can have a very large effect on the performance of your network. Because normal unicast routing protocols cannot route traffic to multiple, dynamically changing destinations, a multicast routing protocol is needed. Several multicast routing protocols are available, including the Distance Vector Multicast Routing Protocol (DVMRP), Multicast Extensions to OSPF (MOSPF), Core-Based Trees (CBT), and Protocol Independent Multicast (PIM).

Each of these routing protocols uses distribution trees for building its multicast routing tables. These distribution trees fall into two basic categories: dense mode (DM) and sparse mode (SM). Your choice of a routing protocol will be determined by whether the multicast end stations are densely or sparsely distributed throughout your campus network as well as the available bandwidth that exists in your campus.

Dense Mode Routing Protocols

DM routing protocols assume that there are many multicast end stations spread across most of your segments in your campus network and that your network infrastructure has a lot of available bandwidth. This means that most, if not all, of your RPs will need to be forwarding multicast traffic from the multicast servers to the multicast end stations.

DM protocols initially flood the network with multicast traffic and then, based on the discovery of participating end stations, prune back the distribution tree to include only those segments with participating end stations. The RPs use IGMP to discover these end stations.

DM protocols use source-based trees. The DM routing protocol learns about the participation of end stations by flooding multicast traffic across the entire network, as shown on the left side of Figure 8.3. This process guarantees that participating end stations get the multicast traffic quickly. Also, very little communication needs to take place between the different RPs, thus reducing your management overhead. However, the downside of this approach is that, initially, every segment is flooded with multicast traffic. In Figure 8.3, even PC-A (left side), which doesn't want to see the multicast stream, still receives it. Through a learning process, RPs learn via IGMP which devices want to see the multicast stream and prune off segments that don't want to see it, as shown on the right side of Figure 8.3.

Figure 8.3. Dense mode multicasting.

DM protocols are typically used in LAN, not WAN, environments. Examples of DM protocols include DVMRP, MOSPF, and PIM-DM.

Sparse Mode Routing Protocols

Because of the scalability problems of DM routing protocols, they are not the preferred method of transporting multicast traffic to end stations. As an example, assume that you have 100 VLANs in your campus, and three people in the campus start up a multicast video-conferencing application. In a DM environment, all 100 VLANs would initially be hit by this very large video stream, severely affecting the performance of your network just because of the actions of only three people. Because of the limited number of people in this example, a better solution would be the use of an SM routing protocol.

SM protocols use join messages to construct a distribution tree, ensuring that only those segments with participating end stations will have traffic forwarded to them by their connected RPs. Therefore, SM protocols scale much better and are more suited for large, geographically dispersed environments. Unlike DM protocols, SM protocols do not waste bandwidth by flooding multicasts everywhere. Traffic is not forwarded to a segment until an end station joins a multicast group.

SM assumes that only a handful of RPs will be forwarding multicast traffic. It also assumes that the participating end stations are widely dispersed across your campus network (possibly located across your WAN), and that the amount of bandwidth in your network is limited. In this approach, the distribution tree is empty and, as end stations are discovered, branches are added to the tree. As you can see in the left side of Figure 8.4, the multicast stream is initially not flooded through the network. As end stations, such as PC-B, send IGMP join messages, RPs builds a path back to the multicast source so that the multicast stream can be sent to only participating multicast clients. This is shown on the right side of Figure 8.4.

Figure 8.4. Sparse mode multicasting.

Most of the industry uses SM routing protocols to set up multicast distribution trees because SM works well in environments both with only a few clients and with many, many clients. SM routing protocols include PIM-SM and Core-Based Trees (CBTs).

Protocol Independent Multicast

Protocol Independent Multicast (PIM) is a multicast routing protocol that's currently being defined by a draft RFC. Its ongoing development is being discussed by the Internet Engineering Task Force (IETF). PIM is unique in that it supports both dense and sparse modes, making it much more flexible than other multicast routing protocols. PIM uses IGMP to transport its routing information.

PIM can coexist with any type of unicast routing protocol, including RIP, IGRP, Enhanced IGRP, and even OSPF. PIM can support both dense and sparse modes simultaneously to more adequately meet multicasting requirements in any network.

PIM-DM

Dense mode should be used when your campus network meets one of the following criteria:

• The multicast servers and end stations are located close to each other.

• The number of multicast servers is few, but the number of end stations is very many.

• Multicast traffic is constantly being generated and forwarded.

• The amount of multicast traffic is very large.

PIM-DM uses a source-based, shortest-path distribution tree. It uses reverse path forwarding to build its distribution tree. PIM-DM assumes that all segments are participating. The multicast routing protocol floods the campus network with multicast traffic from the multicast servers and then prunes off segments from the distribution tree when its IGMP-capable RPs do not receive any reports in response to their queries. This means that each multicast application you deploy will have its own separate tree structure. This works quite well in environments in which the multicast traffic needs to be forwarded to many, if not most, end stations in your campus.

PIM-SM

Sparse mode should be used when your campus network meets one of the following criteria:

• The multicast servers and clients are separated by a WAN.

• Each multicast group in your campus has very few clients.

• The multicast traffic that the servers generate is not constant.

PIM-SM is useful when you have a campus environment with many small bandwidth-generating multicast applications: The number of participants is small and the amount of traffic is small.

Unlike PIM-DM, PIM-SM does not use reverse path forwarding. Actually, in this type of setting, implementing reverse path forwarding does not make any sense. To flood your campus network with a stream of multicast traffic to deliver it to only a handful of end stations is very wasteful of your network's resources.

To be more efficient, PIM-SM uses a rendezvous point. The RP performing this responsibility serves as a registration point. It contains a list of all multicast applications and their respective servers that are generating the multicast traffic. Information is always forwarded to the rendezvous point RP and is then disseminated to all the segments that have participating multicast end stations. Intervening RPs ensure that the best path (usually the one with the lowest number of hops) is used to connect the rendezvous point to the end stations.