Electing an RP (in brief)

The PIMv2 RFC states:

“This specification does not mandate the use of a single mechanism to provide routers with the information to perform the group-to-RP mapping. Currently four mechanisms are possible, and all four have associated problems:

1. Static Configuration: A PIM router MUST support the static configuration of group-to-RP mappings. Such a mechanism is not robust to failures, but does at least provide a basic interoperability mechanism.
2. Embedded-RP: Embedded-RP defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address.
3. Cisco’s Auto-RP: Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-RP mappings from a central location.
4. BootStrap Router (BSR): RFC 2362 specifies a bootstrap mechanism based on the automatic election of a bootstrap router (BSR). Any router in the domain that is configured to be a possible RP reports its candidacy to the BSR, and then a domain-wide flooding mechanism distributes the BSR’s chosen set of RPs throughout the domain.

In this post we will look briefly at 1,3 and 4.

Static Configuration

Configuring a Static RP is fairly straight forward. The same RP is configured on each router in the multicast domain. There are some variations here where you can assign groups to different RPs to distributre the multicast load in the network.

Auto-RP

Auto-RP makes use of two multicast groups ie 224.0.1.39 and 224.0.1.40. The first address is 224.0.1.39 is used by the candidate RPs to announce their availability to be the RP for all or some multicast groups. The mapping agents listen for the candidate RP announcements and then send out group to RP mappings to the multicast group 224.0.1.40 address.

BSR

Within each multicast domain at least one of the routers must be configured as a candidate-BSR. The candidate BSR(s) each send Boot Strap Messages(BSM) out of all its interfaces to the ALL-PIM-ROUTERS (224.0.0.13) address. When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS’ it performs the following:

1. If the message was not sent by the RPF neighbor towards the BSR address included, the message is dropped. (ie if a PIM router receives a message from the BSR on an interface which is not the route back to the BSR, the BSM is dropped.)
2. If the BSM is received on an interface which is the outgoing interface back towards the BSR then forwarded out all PIM interfaces, excluding the one over which the message arrived, to `ALL-PIM-ROUTERS’ group, with a TTL of 1.

The original messages sent out by the BSR do not contain any RP information as the candidate-RP has yet to be configured. Once a candidate-RP has been configured it sends a unicast candidate-RP advertisement to the BSR which in turn sends out a BSM containing the RP information to all the routers in the multicast domain.

The BSR collects the information from all candidate RPs. It places the information for all candidate RPs into subsequent Bootstrap messages. The BSR performs the election of the active RP of each group range only for its own use. Each router in the domain is responsible for running the RP-selection hash algorithm on the candidate RP information contained in the Bootstrap messages.

Note:

BSR differs from Auto-RP in that BSR does not create or require that any state is maintained in the mroute table. When using Auto-RP a method must be implemented to dense-flood the RP information throughout the multicast domain. This can be done in one of two ways, either implement PIM-Sparse-Dense mode or use the Auto-RP listener feature.

Comments

Leave a comment

Name (required)

E-mail (required)

URI

Your Comment