IPv6 PIM-SM

IPv6 PIM-DM uses the flood-and-prune cycles to build SPTs for IPv6 multicast data forwarding. Although an SPT has the shortest paths from the IPv6 multicast source to the receivers, it is built with a low efficiency. Therefore, IPv6 PIM-DM is not suitable for large- and medium-sized networks.

IPv6 PIM-SM uses the pull mode for IPv6 multicast forwarding, and it is suitable for large-sized and medium-sized networks with sparsely and widely distributed IPv6 multicast group members.

IPv6 PIM-SM assumes that no hosts need IPv6 multicast data. A multicast receiver must express its interest in the IPv6 multicast data for an IPv6 multicast group before the data is forwarded to it. A rendezvous point (RP) is the core of an IPv6 PIM-SM domain. Relying on the RP, SPTs and rendezvous point trees (RPTs) are established and maintained to implement IPv6 multicast data forwarding. An SPT is rooted at the IPv6 multicast source and has the RPs as its leaves. An RPT is rooted at the RP and has the receiver hosts as its leaves.

IPv6 PIM-SM mechanisms include neighbor discovery, DR election, RP discovery, Anycast RP, RPT building, multicast source registration, switchover to SPT, and assert.

IPv6 PIM-SM uses the same neighbor discovery mechanism as IPv6 PIM-DM does. For more information, see "Neighbor discovery."

A designated router (DR) is required on both the source-side network and receiver-side network. A source-side DR acts on behalf of the IPv6 multicast source to send register messages to the RP. The receiver-side DR acts on behalf of the receiver hosts to send join messages to the RP.

	IMPORTANT: MLD must be enabled on the device that acts as the receiver-side DR. Otherwise, the receiver hosts attached to the DR cannot join any IPv6 multicast groups. For more information about MLD, see "Configuring MLD."

As shown in Figure 108, the DR election process is as follows:

1. The devices on the shared-media LAN send hello messages to one another. The hello messages contain the DR priority for DR election. The device with the highest DR priority is elected as the DR.

2. The device with the highest IPv6 link-local address wins the DR election under one of the following conditions:

   • All the devices have the same DR election priority.

   • A device does not support carrying the DR priority in hello messages.

If the DR fails, its IPv6 PIM neighbor lifetime expires, and the other devices initiate a new DR election.

An RP is the core of an IPv6 PIM-SM domain. An IPv6 multicast group can have only one RP for IPv6 multicast forwarding, and an RP can be designated to multiple IPv6 multicast groups. RPs can be statically configured or dynamically elected through bootstrap router (BSR) mechanism. The BSM mechanism lessens the RP burden and optimizes the topological structure of the RPT.

BSR mechanism includes the following roles:

• Candidate-RPs (C-RPs)—An RP is dynamically elected from C-RPs to provide services to an IPv6 multicast group.

• BSR—A BSR is the core of the administrative core of the IPv6 PIM-SM domain. It is responsible for collecting and advertising RP information in the whole domain. An IPv6 PIM-SM domain has only one BSR, and the BSR is elected from C-BSRs.

• Candidate-BSRs (C-BSRs)—Any devices in the IPv6 PIM-SM domain can act as C-BSRs and the BSR is elected from the C-BSRs. Once the BSR fails, a new BSR is elected from the C-BSRs to avoid multicast traffic interruption.

As shown in Figure 109, an RP is elected as follows:

1. Each C-BSR sends a bootstrap message (BSM) to other devices in the IPv6 PIM-SM domain.

2. When a C-BSR receives a BSM from another C-BSR, it compares its own priority with the priority carried in the message. The C-BSR with a higher priority wins the BSR election. If a tie exists in the priority, the C-BSR with a higher IPv6 address wins. The loser uses the winner's BSR address to replace its own BSR address and no longer regards itself as the BSR. The winner retains its own BSR address and continues to regard itself as the BSR.

3. Each C-RP periodically unicasts an advertisement message to the BSR. An advertisement message contains the address of the advertising C-RP and the IPv6 multicast group range to which it is designated.

4. The BSR collects these advertisement messages and organizes the C-RP information into an RP-set, which is a database of mappings between IPv6 multicast groups and RPs. The BSR encapsulates the RP-set information in the bootstrap messages (BSMs) and floods the BSMs to the entire IPv6 PIM-SM domain.

5. All devices in the IPv6 PIM-SM domain select an RP for an IPv6 multicast group based on the following rules:

   1. The C-RP that is designated to the smallest IPv6 multicast group range wins.

   2. If the C-RPs are designated to the same group ranges, the C-RP with the highest priority wins.

   3. If the C-RPs have the same priority, the C-RP with the largest hash value wins. The hash value is calculated through the hash algorithm.

   4. If the C-RPs have the same hash value, the C-RP with the highest IP address wins.

The embedded RP mechanism enables a device to resolve the RP address from an IPv6 multicast group address to map the IPv6 multicast group to an RP. This RP can take the place of the configured static RP or the RP dynamically elected by the bootstrap mechanism. A DR does not need to learn the RP address beforehand. The process is as follows:

• At the receiver side:

  1. A receiver host initiates an MLD report to express its interest in an IPv6 multicast group.

  2. After receiving the MLD report, the receiver-side DR resolves the RP address embedded in the IPv6 multicast group address and sends a join message to the RP.

• At the IPv6 multicast source side:

  1. The IPv6 multicast source sends IPv6 multicast traffic to an IPv6 multicast group.

  2. The source-side DR resolves the RP address embedded in the IPv6 multicast address, and sends a register message to the RP.

IPv6 PIM-SM requires only one active RP to serve each IPv6 multicast group. If the active RP fails, the multicast traffic might be interrupted. The Anycast RP mechanism enables redundancy backup among RPs by configuring multiple RPs with the same IPv6 address for one multicast group. An IPv6 multicast source registers with the closest RP or a receiver-side DR joins the closest RP to implement source information synchronization.

Anycast RP has the following benefits:

• Optimal RP path—An IPv6 multicast source registers with the closest RP to build an optimal SPT. A receiver joins the closest RP to build an optimal RPT.

• Redundancy backup among RPs—When an RP fails, the RP-related sources will register with the closest available RPs and the receiver-side DRs will join the closest available RPs. This provides redundancy backup among RPs.

Anycast RP is implemented by using either of the following methods:

• Anycast RP through MSDP—In this method, you can configure multiple RPs with the same IP address for one multicast group and configure MSDP peering relationships between them. For more information about Anycast RP through MSDP, see "Configuring MSDP."

• Anycast RP through IPv6 PIM-SM—In this method, you can configure multiple RPs for one IPv6 multicast group and add them to an Anycast RP set. This method introduces the following concepts:

  • Anycast RP set—A set of RPs that are designated to the same IPv6 multicast group.

  • Anycast RP member—Each RP in the Anycast RP set.

  • Anycast RP member address—IPv6 address of each Anycast RP member for communication among the RP members.

  • Anycast RP address—IPv6 address of the Anycast RP set for communication within the IPv6 PIM-SM domain. It is also known as RPA.

  As shown in Figure 110, RP 1, RP 2, and RP 3 are members of an Anycast RP set.

  Figure 110: Anycast RP through IPv6 PIM-SM

  

  The following describes how Anycast RP through IPv6 PIM-SM is implemented:

  1. RP 1 receives a register message destined to RPA. Because the message is not from other Anycast RP members (RP 2 or RP 3), RP 1 considers that the register message is from the DR. RP 1 changes the source IPv6 address of the register message to its own IPv6 address and sends the message to the other members (RP 2 and RP 3).

     If a device acts as both a DR and an RP, it creates a register message, and then forwards the message to the other RP members.

  2. After receiving the register message, RP 2 and RP 3 find out that the source address of the register message is an Anycast RP member address. They stop forwarding the message to other devices.

  In Anycast RP implementation, an RP must forward the register message from the DR to other Anycast RP members to synchronize IPv6 multicast source information.

As shown in Figure 111, the process of building an RPT is as follows:

1. When a receiver wants to join the IPv6 multicast group G, it uses an MLD message to inform the receiver-side DR.

2. After getting the receiver information, the DR sends a join message, which travels hop by hop to the RP for the IPv6 multicast group.

3. The devices along the path from the DR to the RP form an RPT branch. Each device on this branch adds to its forwarding table a (*, G) entry, where the asterisk (*) represents any IPv6 multicast source. The RPT is rooted at the RP and has the DR as its leaf.

When the IPv6 multicast data addressed to the IPv6 multicast group G reaches the RP, the RP forwards the data to the DR along the established RPT. Finally, the DR forwards the IPv6 multicast data to the receiver hosts.

When a receiver is no longer interested in the IPv6 multicast data addressed to the IPv6 multicast group G, the receiver-side DR sends a prune message. The prune message goes hop by hop along the RPT to the RP. After receiving the prune message, the upstream node deletes the interface that connects to this downstream node from the outgoing interface list. At the same time, the upstream device checks for the existence of receivers for that IPv6 multicast group. If no receivers for the IPv6 multicast group exist, the device continues to forward the prune message to its upstream device.

The IPv6 multicast source uses the registration process to inform an RP of its presence.

As shown in Figure 112, the IPv6 multicast source registers with the RP as follows:

1. The IPv6 multicast source S sends the first multicast packet to the IPv6 multicast group G. When receiving the multicast packet, the source-side DR that directly connects to the IPv6 multicast source encapsulates the packet into a register message and unicasts the message to the RP.

2. After the RP receives the register message, it decapsulates it and forwards it down to the RPT. Meanwhile, it sends an (S, G) source-specific join message toward the IPv6 multicast source. The devices along the path from the RP to the IPv6 multicast source constitute an SPT branch. Each device on this branch creates an (S, G) entry in its forwarding table.

3. The subsequent IPv6 multicast data from the IPv6 multicast source are forwarded to the RP along the SPT. When the IPv6 multicast data reaches the RP along the SPT, the RP forwards the data to the receivers along the RPT. Meanwhile, it unicasts a register-stop message to the source-side DR to prevent the DR from unnecessarily encapsulating the data.

In an IPv6 PIM-SM domain, only one RP and one RPT provide services for a specific IPv6 multicast group. Before the switchover to SPT occurs, the source-side DR encapsulates all IPv6 multicast data in register messages and sends them to the RP. After receiving these register messages, the RP decapsulates them and forwards them to the receiver-side DR along the RPT.

IPv6 multicast forwarding along the RPT has the following weaknesses:

• Encapsulation and decapsulation are complex on the source-side DR and the RP.

• The path for an IPv6 multicast packet might not be the shortest one.

• The RP might be overloaded by IPv6 multicast traffic bursts.

To eliminate these weaknesses, IPv6 PIM-SM allows an RP or the receiver-side DR to initiate the switchover to SPT when the RP or DR receives IPv6 multicast traffic:

• The RP initiates the switchover to SPT:

  If the RP receives IPv6 multicast traffic, it sends an (S, G) source-specific join message toward the IPv6 multicast source. The devices along the path from the RP to the IPv6 multicast source constitute an SPT branch. The subsequent IPv6 multicast data is forwarded to the RP along the SPT without being encapsulated into register messages.

  For more information about the switchover to SPT initiated by the RP, see "IPv6 multicast source registration."

• The receiver-side DR initiates the switchover to SPT:

  If the receiver-side DR receives IPv6 multicast traffic, it initiates the switchover to SPT as follows:

  1. The receiver-side DR sends an (S, G) source-specific join message toward the IPv6 multicast source. The devices along the path create an (S, G) entry in their forwarding table to constitute an SPT branch.

  2. When the multicast packets reach the device where the RPT and the SPT branches, the device drops the multicast packets that travel along the RPT. It then sends a prune message with the RP bit toward the RP.

  3. After receiving the prune message, the RP forwards it toward the IPv6 multicast source (supposed only one receiver exists). Thus, the switchover to SPT is completed. The subsequent IPv6 multicast packets for the IPv6 multicast group travel along the SPT from the IPv6 multicast source to the receiver hosts.

With the switchover to SPT, IPv6 PIM-SM builds SPTs more economically than IPv6 PIM-DM does.

IPv6 PIM-SM uses a similar assert mechanism as IPv6 PIM-DM does. For more information, see "Assert."