• Home
• Multicast Routing Protocols - Cisco CCIE Prep

7.1 Multicast Routing Protocols

Just as unicast, multicast has several routing protocols, including distance vector and link state protocols that build multicast route tables to allow Layer 3 devices to forward multicast data to its intended recipients. These protocols enhance the efficiency by which multicast application data is distributed and optimize the use of existing network resources. Generally, multicast routing protocols use one of two techniques to forward multicast data: source trees and shared trees.

• When a Source Tree protocol is in use, a tree connects each source within a group to the members of its group. The source tree links create direct paths to join the multicast source to its downstream receiver. Once a source tree exists for a multicast source and it group members, all traffic to the members of the group passes along this tree and flows across the shortest path to the destination host. The Distance Vector Multicast Routing Protocol (DVMRP), the Multicast Open Shortest Path First (MOSPF) protocol and the Protocol Independent Multicast Dense Mode (PIM-DM) protocols use source trees. These protocols are also known as dense mode protocols.

• Shared Tree distribution is for sparsely populated multicast groups that may have slow network connections. Shared-tree multicast forwarding paths rely on a central router that becomes a rendezvous point (RP) between multicast sources and destinations. The RP forwards the multicast datagrams through a shared tree to the members of the group. Shared trees use only a single tree between all sources and receivers of a given multicast group. However, a shared tree can be unidirectional or bidirectional.

• In Unidirectional Shared Tree distribution, all destination hosts of a multicast group receive the data from a RP regardless of where they are located in the network.

• In Bidirectional Shared Tree distribution, destination hosts that are upstream of the RP it can receive data directly from the upstream source, without having to come from the RP.

The Core-based Tress (CBT) protocol and the Protocol Independent Multicast Sparse Mode (PIM-SM) protocols use shared trees. These protocols are also known as sparse mode protocols.

7.1.1 Distance Vector Multicast Routing Protocol (DVMRP)

The Distance Vector Multicast Routing Protocol (DVMRP), which is defined in RFC 1075, is a distance vector that is based on RIP. It operates within an AS but not between different ASs. DVMRP is the oldest of the multicast routing protocols and is currently the most widely used. It is also the primary multicast routing protocol in the Multicast Backbone (MBONE), which is used by the research community. DVMRP uses several of the features implemented in other distance vector protocols, including a 32 max hop-count, poison reverse, and 60-second route updates. It also allows for IP classless masking of addresses.

DVMRP enabled routers use a tunnel to establish adjacencies with their neighbor DMRP enabled routers, to share route information, and to forward multicast traffic between DVMRP enabled routers that may, or may not be separated by non-DVMRP enable routers. Once the adjacency is established, the DVMRP route table is created and is exchanged via Route Reports. The route table is similar to a unicast route table in that it contains the Layer 3 IP network of the multicast source and the next hop toward the destination. As a dense mode protocol, DVMRP sends a copy of a multicast packet out all ports on the DVMRP enabled router.

Routers that receive the multicast packets send prune messages back to their upstream neighbor router to stop a data stream if there are no downstream members of the multicast group.

Because of its table structure, DVMRP uses the Source Tree distribution technique, with the source tree based on the information in the DVMRP table. This information is also used to perform the Reverse Path Forwarding check to verify that the multicast data coming into the interface is coming in an interface that leads back to the source of the data.

Because DVMRP operates on the basis of establishing a DVMRP tunnel between DVMRP enable routers, it does not scale well and is only partially supported by Cisco. Usually DVMRP networks are implemented on UNIX machines that are running the mrouted process.

7.1.2 Multicast Open Shortest Path First (MOSPF)

Multicast Open Shortest Path First (MOSPF), which is described in RFC 1584 as a multicast extension of OSPF, eliminates the need for tunnels such as those used for DVMRP. MOSPF provides fast rerouting and supports VLSM and hierarchical routing within an AS.

As with OSPF, MOSPF can be used to route multicast traffic within a single OSPF area (inta-area), traffic to other areas (inter-area) or to other Autonomous Systems (inter-AS routing).

7.1.2.1 Intra-Area MOSPF

OSPF route information is shared via different LSA types. Link State Advertisements are flooded throughout an area so that all OSPF enable routers have the same topological map of the network. When changes are made to the topology, new LSAs are flooded to propagate the change. In addition to the unicast routing LSA types, in OSPFv2 there is a special multicast LSA (type 6) for flooding multicast group information throughout the area. This additional LSA type required some modification to the OSPF frame format.

Multicast LSA flooding is performed by the Designated Router (DR) when there are multiple routers connected to a multi-access media, such as Ethernet. However, the DR must be MOSF-enabled. Thus, if there are non-MOSPF routers on the same network, their OSPF priority must be lowered so they do not become the DR. If a non-MOSPF router were to become the DR, it would not be able to forward the Multicast LSA to the other routers on the segment.

Inside the OSPF area updates are sent describing which links have active multicast members on them so that the multicast data can be forwarded to those interfaces. MOSPF also uses (S, G) notation and calculates the SPT using the Dijkstra algorithm that is used for calculation of unicast routes. An SPT is created for each source in the network.

7.1.2.2 Inter-Area and Inter-AS MOSPF

All OSPF areas are connected through the backbone, which is known as Area 0. In large networks, having full multicast tables transmitted as updates across Area 0, as well as all the unicast table updates, would cause a large amount of overhead and possibly latency.

Unicast OSPF uses a Summary LSA to inform the routers in Area 0 about the networks and topology in an adjacent area. This task is performed by the area's ABR (Area Border Router), which summarizes all the information about the area and then passes it on to the backbone (Area 0) routers in a summary LSA. The same is done for the multicast topology. The ABR summarizes which multicast groups are active and which groups have sources within the area. This information is then sent to the backbone routers.

In addition to summarizing multicast group information, the ABR is responsible for the actual forwarding of multicast group traffic into and out of the area. Each area has an ABR that performs these two functions within an OSPF network.

OSPF implements Autonomous System Border Routers as the bridge between different ASs. These routers perform much the same as an ABR but must be able to communicate with non-OSPF devices. Multicast group information and data is forwarded and received by the Multicast Autonomous Border Router (MASBR). Since MOSPF runs natively within OSPF, there must be a method or protocol by which the multicast information can be taken from MOSPF and communicated to the external AS. Historically, DVRMP has provided this bridge.

7.1.3 Protocol Independent Multicast Sparse Mode (PIM-SM)

PIM Sparse Mode (PIM-SM), which is defined in RFC 2362, works in the assumption that no hosts want to receive multicast traffic unless they specifically request it. PIM-SM uses Shared Tree distribution, but only in unidirectional mode. Because of this, all multicast sources for any group must register with the router that is selected as the rendezvous point (RP) of the shared tree.

This allows the RP and other routers to establish a RP tree (RPT), which synonymous with SPT in source tree distribution. In addition, PIM-SM allows for the selection of three alternate RP routers as backups for the primary RP in case of failure.

7.1.3.1 PIM-SM Join Tree

PIM-SM designated routers (PIM DRs) on end segments join the shared tree when they receive IGMP query messages informing them that a host requests membership of a multicast group. If the existing group entry (*, G) does not already exist in the router's table, it is added to the table and the Join Tree request is sent to the next hop toward the RP with multicast address 224.0.0.13 requesting the multicast group. When the next hop router receives the Join Tree request it either adds the interface to the shared tree and discards Join Tree request if an entry for (*, G) exists in its table; or It adds an entry for the (*, G) group and adds the link to the forwarding cache, and sends its own Join Tree request toward the RP.

7.1.3.2 PIM-SM Prune

Multicast group members also use IGMP when they want to leave a group. When the last member on a segment leaves the group, the router removes the interface from the forwarding cache entry and then sends a

Prune request to the next hop toward the RP. The prune message includes the (*, G) group to be removed. If there is another router with active group members connected to the router requesting the Prune, it is removed from the outgoing interface list and the Prune message is discarded.

7.1.3.3 PIM-SM Configuration

You can view the PIM multicast routing (Mroute) table by using the show ip mroute command. This command lists the multicast groups (*, G) for PIM-SM, the RP, and the incoming and outgoing interfaces for the group.

Cisco recommends that you use ip pim command with the sparse-dense-mode keyword when configuring PIM. If the multicast group is running in sparse-mode, i.e. with a known RP, the interface will be treated as sparse-mode.

You can specify the RP by using the ip pim rp-address command, in which rp-address is the IP address of the RP. This command tell the router who the RP is.

Alternatively, you can use Auto-RP to have the RP announce its services to the PIM network. However, Auto-RP requires a RP mapping agent which must be configured by using the ip pim send-rp-discovery command. In smaller networks, the RP can be the mapping agent. In Auto-RP, the candidate RPs send their announcements to RP mapping agents using the multicast address 224.0.1.39. The RP mapping agent then selects the RP for a group, based on the highest IP address of all the candidate-RPs and sends RP-discovery messages to the rest of the PIM-SM routers in the internetwork, with the selected RP to group mappings. To use Auto-RP, you must configure a RP mapping agent using the ip pim send-rp-discovery command, and you must configure the candidate RPs with the ip pim send-rp-announce command.

You can also configure a PIMv2 Bootstrap Router (BSR), which is described in RFC 2362, to automatically select an RP for the network. In BSR, you configure BSR candidates (C-BSRs) with priorities from 0 to 255 and a BSR address. C-BSRs exchange bootstrap messages to multicast IP 224.0.0.13, i.e., to all PIM routers. If a C-BSR receives a bootstrap message, it compares it with its own. The largest priority C-BSR is selected as the BSR. You can use the ip pim bsr-candidate interface hash-mask-len pref to configure candidate BSRs. Once the BSR is selected for the network, it collects a list of candidate RPs. The BSR selects RP to group mappings, which is called the RP-set, and distributes the selected RPs using bootstrap messages sent to 224.0.0.13.

7.1.4 Protocol Independent Multicast Dense Mode (PIM-DM)

Protocol Independent Multicast Dense Mode (PIM-DM), which is defined in RFC 3973, supports classless subnet masking and uses it when the router is running a classless IP unicast protocol. PIM-DM uses Source Tree distribution, which does not require the selection of a RP. PIM-DM routers establish neighbor relations with other PIM-DM routers. It uses these neighbors to establish a SPT that is used to forward multicast data through the network. Like PIM-SM, PIM-DM uses RPF to verify that the interface leads toward the source.

7.1.4.1 PIM-DM Flooding

When a multicast source transmits data, PIM runs the RPF using the unicast route table to verify that the interface leads toward the source. It then forwards the data out all other interfaces to all its PIM neighbors.

The PIM neighbors then forward the data out all other interfaces to its PIM neighbors. This happens throughout the network whether there are group members on the router or not and allows the data to reach all segments. Every router runs the RPF when it receives the multicast data.

7.1.4.2 PIM-DM Pruning

After the initial flooding through the PIM neighbors, PIM-DM performs pruning to optimize the SPT. Since the data has been forwarded to every router, regardless of group membership, the routers must now prune back the distribution of the multicast data to routers that actually have active group members connected.

There are four criteria that merit a prune message being sent by a router.

• The incoming interface fails the RPF check

• No directly connected active group members and no PIM neighbors (Considered a Leaf router)

• Point-to-point non-Leaf router receives a prune request from neighbor

• LAN non-Leaf router receives a prune request from another router and no other router on the segment overrides the prune request.

If any of these criteria are met, a prune request is sent to the PIM neighbor and the SPT is pruned back.

7.1.4.3 PIM-DM Grafting

PIM-DM is also capable of forwarding multicast data once a previously inactive interface becomes active. This is accomplished through a process called grafting. When a host sends and IGMP group membership report to the router, the router then sends a Graft message to the nearest upstream PIM-DM neighbor. Once this message is acknowledged, multicast data begins to be forwarded to the router and on to the host.

7.1.4.4 Configuring PIM-DM

You can configure PIM-DM with the ip pim dense-mode command; however, Cisco recommends that you configure PIM with the sparse-dense-mode keyword rather than the dense-mode keyword unless the interface must run strictly in dense mode.

7.1.5 Core-Based Trees (CBT)

Core-Based Tree (CBT), which is described in RFC 2189, and CBTv2, which is described in RFC 2201, are sparse mode multicast protocols that use Shared Tree distribution, but only in bidirectional mode. Since CBT uses a Shared Tree system it designates a core router that is used as the root of the tree, allowing data to flow up or down the tree. CBT constructs a single shared tree for all sources and members of the group instead of a single tree for each source-group pair. It sends multicast traffic for the entire group over the same tree, regardless of the source. Senders do not need to be members of the group and group membership is dynamic.

If a source to a multicast group sends multicast data to the CBT enabled router, the router then forwards the data out all interfaces that are included in the tree, not just the interface that leads to the core router. In this way, data flows upstream and downstream from the source. Once the data gets to the core router, the core router then forwards the information to the other routers that are in the tree.

A CBT router joins the tree once a host sends an IGMP Membership Record to the directly connected router. The router then sends a Join Tree request to core router. If the request reaches a CBT tree member first, that router will add the leaf router to the tree and begin forwarding multicast data.

Pruning the tree is done much the same way. Once there are no more active members on a router's interfaces, the router will send a Prune request to the upstream router. The answering router will remove the interface from the forwarding cache if it is a point-to-point circuit, or it will wait for a timer to expire it if is on a shared access network. The timer gives enough time for other CBT routers on the segment to override the prune request.