The RP plays a fundamental role in ASM distribution models. The RP is the shared root for multicast shared distribution trees (*,G), and by design, acts as a meeting point between sources and receivers. When designing a new multicast service based on the ASM model it’s very important to take into account the RP role, design options, configuration and redundancy.
Depending on the nature of the service the RP can have more or less functionality. As we’ll describe later, it can be only a reference as a root of the shared tree located in the data plane as it happens in the BiDir models, or it can have additional functionality in the control plane registering new sources and letting it know to the receivers.
It may exist multiple RP in the network, each one covering multiple multicast addresses or multicast address ranges. Within a PIM domain, all the routers must be able to map a multicast group to the same RP.
RP may be configured in several ways:
- Statically (automated or not).
- Using an automated distribution method (Bootstrap Router - BSR).
- Embedding the RP information in the multicast group distribution address (Embedded RP).
Easy in small networks
Hard in big networks
In order to take the correct design decision on which configuration method to use it’s important to be able to understand the key differences between the options.
Static RP configuration mode it’s possibly the easiest of the tree options and if the network is small and stable enough, you may not even need to think about another configuration method.
With Static RP, the RP address must be statically configured on every device of the multicast domain.
In this case the configuration is simple and repetitive, and may be convenient to think about automation in this scenario. Automation ensures a quick, easy and coherent configuration on all the network devices. It helps too in a change management scenario, where all network devices need to change the RP configuration at once to ensure a high degree of service availability.
As we said earlier, it’s a good solution for small and static networks where once the solution is deployed, it’s not prone to changes. If the network is large in size, with many devices or is not automated at all, an alternative way to configure the RP should be considered.
By itself, Static RP configuration doesn’t support load sharing or redundancy mechanisms, but may be combined with PIM Anycast RP for that.
Bootstrap Router (BSR) is an auto-configuration RP mechanism. When using BSR, there is no need to configure manually the RP in any device on the network, as the configuration will be learned automatically. The only elements that need configuration with this method are the candidate BSR (c-BSR) and the candidate RP (c-RP).
With BSR is easy to make and distribute changes on the RP to all the devices on the network, because those changes spread automatically to all the devices on the multicast domain.
This mechanism allows automatic distribution of multiple RPs to the network for different groups. BSR allows for redundancy and load-balancing scenarios by design.
Deploying a RP distribution system based on BSR is more complex than manually configuring the RP or automating the static configuration process and for that, it requires more specialized O&M stuff, increasing the overall OPEX of this solution.
The elements of this configuration method are:
- C-BSR: candidate to become BSR
- BSR: elected BSR among the c-BSR set (higher priority)
- C-RP: candidate to become RP
- RP: elected RP among the c-RP set (lower priority)
RP final election is made at each router and must be coherent within the domain, but there are some previous steps that may be convenient to be aware of:
Elects one BSR
c-RP address Group Range
Set of group ranges serviced by c-RP
Group to RP mapping from all c-RPs
Multicast routers perform coherent RP election for each Group
- C-BSR announcements and election: all c-BSR flood bootstrap messages (BSM) to all routers on the domain. c-BSR with the highest BSR Priority is elected as BSR.
- C-RP announcements: c-RPs send unicast c-RP-advertisement messages to the BSR. C-RP-advertisement includes triplets (C-RP-Address, Group-Range, RP-Priority).
- BSR announcements: BSR floods RP to Group associations to all devices on the network. BSM messages include information about all the RP to group associations.
- RP election by routers: each router in the domain uses a common algorithm to make possible to select the same RP address for a given multicast group G (coherent election based on priority and hash values)
This configuration mode replaces Static RP configuration by embedding the RP information in the group multicast address.
With Embedded RP, there is no need to preconfigure any router of the multicast domain with RP address information and as a consequence the deployment is much easier. Routers extract RP information from the Embedded RP multicast group address.
Embedded RP is a highly scalable and flexible solution. Multicast applications can set or change at any time the RP address following business needs and can set multiple RP to serve multiple multicast groups. The number of RPs can grow on demand based on the design requirements, making this solution suited for small and big network environments.
This solution doesn’t support RP redundancy. Routers extract only one RP address per each multicast group address. It doesn’t support BiDir designs either.
For designs that require inter-domain multicast Embedded RP is a good solution because the RP address embedded in the multicast group address can be out of the intra-domain boundary.
The applications interaction with the network by setting the RP for the multicast groups directly can lead to severe security concerns. Some kind of security check should be set to avoid hacking or application misconfiguration as this would have a direct impact to the multicast service.
I hope you find it useful.