There are various manifestations of Protocol Independent Multicast (PIM).

PIM Dense Mode (PIM-DM) is the easiest to configure but doesn’t make the most efficient use of your network. Basically PIM-DM works by flooding multicast traffic to every routed subnet. Routers that don’t have interested receivers will prune back that traffic. At regular intervals, the flooding/pruning will be repeated. Now, if you have receivers on every subnet in your environment, this will work fine - if you don’t, as is more likely, then you’re wasting resources significantly.

Hence the development of PIM Sparse Mode (PIM-SM). PIM-SM works on a pull rather than push model, which just means that the default is not to send traffic to routers unless they ask for it (which they will do as soon as they find out about receivers on their LANs that want to join the multicast group).

PIM-SM uses the concept of shared trees, meaning that you don’t require a separate distribution tree created (and hence using memory) on the routers for every multicast source. This necessitates the creation of Rendezvous Points (RPs) in the network to act as the focal point (root) for the trees. Sources register with these RPs and data is passed through the network towards each receiver.

Routers with active receivers will send a join message back to the source to indicate that they wish to receive the multicast traffic. Intermediate routers will determine the best path back to the source (using standard unicast routing tables) which may well not be via the RP. In many cases, although the RP is vital in setting up the multicast distribution tree, it isn’t actually in the forwarding path of the multicast traffic. Be aware here that the routers keep track of source group (SG) pairings, so will have to keep a record for every different source within the same multicast group.

The location of these RPs does have to be chosen, however, as every multicast router needs to know where it is. You can statically configure every multicast-aware router in your network with the RP address, but in a sizeable network this isn’t particularly efficient.

A more scaleable and resilient option is to configure auto-RP. This allows routers to offer themselves up as RP candidates while other routers, known as mapping agents, decide which of the candidates to choose and notify all other routers in the network which RP to use. This allows for the provision of backup RPs. While you would be advised to configure all of the other routers to only accept information from known mapping agents, and perhaps to filter for specified multicast groups only, you don’t have to manually configure RPs.

Auto-RP does require dense mode activation as the notifications have to be sent to all routers: in reality what you configure is a hybrid known as sparse-dense that uses dense mode for RP information and sparse mode for actual data traffic. There are potential issues with this, which will be covered in the next section.

A better option than Sparse Mode is a relatively new form of PIM, known as Bi-Dir (Bi-Directional PIM). Where PIM-SM is best suited to one-to-many flows, since traffic flows from a source along a tree to the receivers, Bi-Dir builds a tree where data flows in both directions. This is best suited in many-to-many applications, where a site may be a source for some traffic and a receiver for others. By allowing data to flow either way along the tree, the amount of state (memory) used in the routers doesn’t rise in line with the number of sources in use.

However, support from the manufacturers for Bi-Dir isn’t comprehensive yet, so while it’s something to aim for, it may be some time before you can implement it for real.

Another way of setting up RPs is using something called Anycast RP. This uses the rather scary concept of having multiple RPs in your network that all have the same IP address allocated to a loopback interface and it’s this address that is advertised to all other routers as their RP. The routers will use normal IP routing to talk to their closest RP. This makes for flexibility and redundancy once you come to terms with duplicate IP addresses on your network—and yes, it really does work.

Because you might well have sources and receivers of the same multicast group now associated to multiple independent RPs, there has to be some way for the RPs to exchange information. This is done via Multicast Source Discovery Protocol (MSDP), which in fact was designed to allow ISPs to pass multicast traffic across the Internet without having to rely on each other’s RPs.

And then there’s SSM—Source Specific Multicast. This allows receivers to learn about multicast sources (probably from a directory service) and for the multicast routers to signal to the source directly that they need to join that group, bypassing the need for RPs altogether. This also means that receivers can choose to listen to just one source in a group, as there may be several sources allocated to a group, not all of whom who may be sending relevant content. This in turn can give you both performance and security improvements, since in effect a receiver can join a source, rather than a group.

Like Bi-Dir, this isn’t yet fully supported on all equipment, and it relies heavily on IGMPv3 on the receiving hosts, so while it’s probably where you want to be going, you won’t be able to get there, just yet.