PIM

Overview

PIM is a component of multicast routing that defines the one-to-many or many-to-many transmission of information. You can use the following variations for PIM configurations:

sparse mode
dense mode
source-specific multicast
bidirectional

Sparse mode is the most common PIM configuration. Sparse mode is used for data transmission to NEs in multiple Internet domains that contain a small ratio of NEs that subscribe to the multicast traffic. Dense mode is used when a large ratio of the potential NEs subscribe to the multicast traffic. In source-specific multicast, paths originate at a single, defined source. Bidirectional PIM is not source-specific.

Anycast RP

Anycast RP for PIM-SM enables fast convergence when a PIM RP router fails. The receivers and sources rendezvous at the closest RP after the router failure. Anycast RP allows an arbitrary number of RPs for each group in a single, shared-tree PIM-SM domain. Triple play configurations that distribute multicast traffic using PIM-SM realize the benefits of fast RP convergence, which helps to avoid the loss of multicast data streams or IPTV delivery to the end user.

Anycast RP for PIM-SM environments is supported in the base routing PIM-SM instance of the service router, and in VPRN instances that are configured with PIM on supporting NEs.

Anycast RP for PIM requires the completion of the following configuration information:

An IP address specified as the RP address. This address is statically configured, or distributed using a dynamic protocol, to all PIM routers in the domain.
A set of routers in the domain designated as RPs for the RP address. These routers form an anycast RP.
Each of these routers is configured with a loopback interface that uses the RP address. The RP address, or a prefix that includes the RP address, is injected into the unicast routing system inside the domain.
Each router in the anycast RP also needs a separate IP address, to be used for communication between the RPs.
Each router in the anycast RP is configured with the addresses of all other routers in the anycast RP. The addresses must be consistently configured in all RPs in the set.

The following figure shows a sample implementation of anycast RP for PIM-SM.

Figure 28-4: Sample implementation of anycast RP for PIM-SM

The following figure summarizes the sequence of events for the Anycast RP implementation shown in Figure 28-4, Sample implementation of anycast RP for PIM-SM.

Table 28-1: Sequence of events for Anycast RP fast convergence

Sequence	Event description
1	S1 sends a multicast packet.
2	The router connected to S1 forms a PIM registration message to send to the Anycast RP address. The Unicast routing system delivers the PIM registration message to the nearest RP, in this case RP1.
3	RP1 receives the PIM registration message, decapsulates the message, and sends the packet down the shared tree to the R1A and R1B receivers.
4	RP1 is configured with the IP address for RP2 and RP3. Since the registration message did not come from one of the RPs in the anycast RP set, RP1 assumes that the packet came from a designated router.
5	RP1 sends a copy of the registration message from the S1 designated router to RP2 and RP3. RP1 uses its IP address as the source address for the PIM registration message.
6	RP1 can join the source tree by sending a join message to S1. However, RP1 must create a source-specific state.
7	RP2 receives the registration message from RP1, decapsulates the message, and send the packet down the share tree to the R2 receiver.
8	RP2 sends a registration-stop message back to RP1. RP2 can wait to send the registration-stop message if it decides to join the source tree. RP2 should wait until it receives data from the source tree before it sends the registration-stop message. If RP2 does wait for the data, the registration-stop message is sent to RP1 when it receives the next registration message. If RP2 does not wait for the data, the registration-stop message is immediately sent to RP1.
9	RP2 can join the source tree by sending a join message to S1. However, RP2 must create a source-specific state.
10	RP3 receives the registration message from RP1 and decapsulates the message. No receivers joined for the group, so RP3 discards the packet.
11	RP3 sends a registration-stop message back to RP1.
12	RP3 creates a source-specific state, so when a receiver joins after S1 starts sending traffic, RP3 can quickly join the source tree for S1.
13	RP1 processes the registration-stop message from RP2 and RP3. RP1 can cache the receipt of registration-stop messages from the RPs in the anycast RP set. (The cache of messages is completed on a per-RP or per-source-specific basis.) The cache of messages increases the reliability of the delivery of registration messages to each RP. Subsequent registration messages received by RP1 are sent only to the RPs in the anycast RP set that have not previously sent registration-stop messages from the source-specific entry.
14	RP1 sends a registration-stop message to the DR under the following conditions: after receiving a registration message from the DR if all RPs in the anycast RP set have returned registration-stop messages for a specific source-specific route

SPT switchover thresholds

SPT switchover thresholds allow you to configure the switchover threshold, in Kbps, for the group prefixes. The threshold value determines when the router switches from the shared tree to the source-specific tree. The switchover is attempted only if the traffic rate on the shared tree for the group exceeds the configured threshold.

L3 Multicast Load Balancing for ECMP

The NFM-P distributes multicast traffic by balancing the load based on the total available multicast bandwidth on all ECMP paths. You can configure ECMP rebalancing on the VPRN and base PIM Routing Instance configuration forms.

NFM-P ECMP rebalancing has the following important characteristics:

Multicast load balancing over ECMP links is enabled, by default.
The rebalancing timer is set to 30 minutes, by default.
Distribution of the multicast groups over the available links is processed based on the bandwidth configured for the specified group address. If the bandwidth is not configured for the multicast stream, then the configured default value is used.
If a link failure occurs, the load on the failed channel is distributed to the remaining channels. The bandwidth required to accommodate the load from the failed link is evenly distributed over the remaining links.
If an additional link becomes available for a specific multicast channel, it is then treated in an equivalent manner to the other links of the interface.
A manual (operator-initiated) re-balance command is typically used to re-evaluate the current balance, with regard to bandwidth utilization. If necessary, multicast streams can subsequently be moved to different links to achieve a balance.
In an automatic timed re-balance, the system re-balances multicast streams over the available links, based on the configured bandwidth and interval. If no links have been added or removed, or it is determined that no multicast streams will benefit from a re-balance, then it is not be implemented.
When multicast load re-balancing is not enabled, any ECMP changes are not optimized. However, whenever a link is added, an attempt is made to balance the number of multicast streams on all the available ECMP links. This may however, not result in balanced bandwidth utilization of all the ECMP links.
Only a single re-balance command can be executed at any specific time. If a re-balance is in progress and a manual re-balance command is entered, it is rejected and a message is displayed informing the user who a re-balance is already in progress.

VRRP-aware PIM

VRRP aware PIM enables PIM to track the state of a VRRP instance and know if the associated VRRP interface is the master. This feature is supported on base router, IES and VPRN interfaces.

PIM monitors the state of the VRRP interface using an operational group. The operational group is up when the VRRP interface is the master, and down for all other VRRP states. A VRRP instance can only be associated with one operational group, and an operational group can only have one associated VRRP instance.

If the monitored interface is the VRRP master, PIM becomes the DR by setting its priority to the configured Operational DR Priority value. Priorities must be configured so that the Operational DR Priority is the highest priority on the IP interface.

If a PIM router is the DR and then receives an indication from VRRP that the interface is no longer the VRRP master, PIM will relinquish the DR role by setting its priority back to the default or configured priority value.

If the VRRP instance or operational group is not configured, PIM will operate as normal with the default or configured priority value.

Two operational groups are supported per PIM interface, one for IPv4 and one for IPv6. A change in operational group status is address family independent; IPv4 and IPv6 priorities are configured independently of each other.