Introduction
This post will describe PIM Bidir, why it is needed and the design considerations for using PIM BiDir. This post is focused on technology overview and design and will not contain any actual configurations.
Multicast Applications
Multicast is a technology that is mainly used for one-to-many and many-to-many applications. The following are examples of applications that use or can benefit from using multicast.
One-to-many
One-to-many applications have a single sender and multiple receivers. These are examples of applications in the one-to-many model.
Scheduled audio/video: IP-TV, radio, lectures
Push media: News headlines, weather updates, sports scores
File distributing and caching: Web site content or any file-based updates sent to distributed end-user or replicating/caching sites
Announcements: Network time, multicast session schedules
Monitoring: Stock prices, security system or other real-time monitoring applications
Many-to-many
Many-to-many applications have many senders and many receivers. One-to-many applications are unidirectional and many-to-many applications are bidirectional.
Multimedia conferencing: Audio/video and whiteboard is the classic conference application
Synchronized resources: Shared distributed databases of any type
Distance learning: One-to-many lecture but with “upstream” capability where receivers can question the lecturer
Multi-player games: Many multi-player games are distributed simulations and also have chat group capabilities.
Overview of PIM
PIM has different implimentations to be able to handle the above applications. There are mainly three implementatios of PIM, PIM Any Source Multicast (ASM), PIM Source Specific Multicast (SSM) and PIM BiDirectional (BiDir).
PIM ASM
PIM ASM was the first implementation and is well suited for one-to-many applications. ASM means that traffic from any source to a group will be delivered to the receiver(s). PIM ASM uses the concept of a Rendezvous Point Tree (RPT) and Shortest Path Tree (SPT). The RPT is a tree built from the receiver to a Rendezvous Point (RP). The tree from a multicast source to a receiver is called the SPT. Before the receiver can learn the source and build the SPT, the RP will have sent a PIM Join towards the source to build the SPT between the source and the RP. When looking in the mroute table, RPT state will be shown as (*,G) and SPT state will be shown as (S,G)
The responsibilities of the RP are:
- Receive PIM Register messages from the First Hop Router (FHR) and send Register Stop
- Join the SPT and the RPT so the receivers get traffic and find out the source of the multicast
Initially traffic flows through the RP, there is a more efficient path though. When the Last Hop Router (LHR) starts receiving the multicast it will switch over to the SPT.The SPT will be a more optimal path and (likely) introduce lower delay between the source and the receiver.
PIM ASM can support both one-to-many and many-to-many applications since it can use both SPT and RPT. To prevent LHR to switch to SPT, ip pim spt-threshold command can be used. It can either be set to switch over at a certain rate of traffic (kbps) or be set to infinity to always stay on the RPT. This can be combined with ACL to have certain groups always stay on the RPT and for others to switch over. PIM ASM can therefore use SPT for some groups and RPT for other groups. There are still drawbacks to PIM ASM, a few are mentioned here:
- Complex protocol state with Register messages
- Redundancy requires the use of MSDP
- Any source can send which opens attack vector for DoS and sending traffic from spoofed source
PIM SSM
PIM SSM was created to work better with one-to-many flows compared to PIM ASM. In PIM SSM, there is no complex handling of state and there is only SPT, no RPT. That also means that there is no need for a RP. PIM SSM is much easier to setup and use, it does require clients to support IGMPv3 so that the IGMP Report can contain which source the receiver wants to receive the traffic from. This also means that since there is no RP, there has to be some way for the receiver to know which sources send to which groups. This has to be hanled by some form of Out Of Band(OOB) mechanism. The most common use for SSM is IP-TV where the Set Top Box (STB) receives a list of sources and groups by contacting a server.
The drawback of PIM SSM is that (S,G) state is created requiring more memory. Depending on the number of sources, this may be a factor or not.
PIM BiDir
Bidirectional PIM was created to work better with many-to-many applications. PIM BiDir uses only RPT and no SPT. This means that there has to be a RP. With bidirectional PIM, the RP does not perform any of the functions of PIM ASM though, such as sending Register Stop messages or joining the SPT. Remember, in PIM BiDir, there is no SPT.The RP in PIM BiDir does not have to be a physical device since the RP is not performing any control plane functions. It is simply a way of forwarding traffic the right way, think of it as a vector. The RP can be a physical device and in that case it is a normal RP, just without the responsibilities of an RP as we know it in PIM ASM. When configuring PIM BiDir to have redundant RPs the RP is sometimes called Phantom RP, because it does not have to reside on a physical device.
PIM BiDir is often used in “hoot n holler” and financial applications. PIM BiDir and PIM SSM are at different ends of the spectrum where PIM ASM can serve both type of applications.
PIM uses the concept of Reverse Path Forwarding (RPF) to ensure loop free forwarding. RPF ensures that traffic comes in on the interface that would be used to send traffic out towards the source. PIM BiDir can send traffic both up and down the RPT. This is not normally supported by using RPF, to support this PIM BiDir uses a Designated Forwarder (DF) on each segment, even point-to-point segments. The main responsibility of the DF is to forward traffic upstream towards the RP. The DF is elected based on the metric towards the RP, essentially building a tree along the best path without having to install any (S,G) state. RPF is still used to find the appropiate path towards the Rendezvous Point Link (RPL) but it is the DF mechanism that ensures loop free forwarding.
RP Considerations
In PIM BiDir there isno MSDP, it does not use (S,G) so this is expected. To provide redundant RP in PIM BiDir, Phantom RP is used. The Phantom RP is a virtual RP which is not assigned to a physical device, it is often implemented by having two routers use a loopback with different subnet mask length.
Routers are assigned the RP adress of 192.0.2.1 which is then the Phantom RP, the actual routers where the traffic will flow through have been assigned 192.0.2.2 and 192.0.2.3 but with different net mask lengths. Normal best path rules will then forward traffic towards the longest path match which will be RP1 when it is available and RP2 when RP1 is not available. It is important to not configure the RP address as a physical interface address since this would break the redundancy. If a router was configured with the real address, it would not forward the traffic since the traffic would be destined for one of its own addresses.
Since the RP is so critical, redundancy must be provided. All traffic will pass through the RP which means that certain links in the network may have to carry a lot of the traffic. For this reason it can be necessary to have several RPs, that are acting as RPs for different multicast groups. The placement of the RP also becomes very important since traffic must flow through the RP.
PIM BiDir Considerations
PIM BiDir uses the DF mechanism and for the election to succeed, all the PIM routers on the segment must support PIM BiDir, otherwise the DF election will fail and PIM BiDir will not be supported on the segment. It is possible to have non PIM BiDir routers on a segment if a PIM neighbor filter is implemented to not form PIM adjacencies with certain routers. That way PIM BiDir can be gradually implemented into the network.
Closing Thoughts
PIM ASM supports all multicast models but at the cost of complexity. One could say that it’s a jack of all trades but does not excel at anything. PIM SSM is less complex and the best choice for one-to-many applications if the receivers have support for IGMPv3. PIM BiDir is best suited for many-to-many applications and keeps the least state of all the PIM implementations. Every PIM implementation has its use case and as an architect/designer its your job to know all the models and pick the best one based on business requirements.
Hi Daniel,
Very nice blog as usual!
Please allow me to comment on a few things. First, I believe that the terminology and explanation of RPT and SPT isn’t quite right. Following the terminology in RFC 4601, RPT is a Rendezvous Point Tree, and is indeed built from receivers toward an RP so that multicast data can flow from RP down to the receivers. SPT stands for Shortest Path Tree that is, in general, built from receivers toward multicast sources, not just from an RP toward a source. It is true that in ASM, the RP builds an SPT toward the source as a receiver, and then “knits together” the SPT with the RPT, but in this case, RP is posing as an end receiver. In general, SPT is built from receivers toward sources, and in SSM, this is in fact the only tree that exists and is always created directly from receivers (SSM does not need an RP).
Second, I believe that it is appropriate to talk about Phantom RP only in cases when the RP address is not really assigned to any interface but merely lies inside an advertised network prefix. Not every RP address in a BiDir PIM is a Phantom RP – if referecing a true router’s interface then that’s not a Phantom RP.
Third, I do not fully agree with the statement: “The RP is even more critical in PIM BiDir because all traffic flows through the RP.” To me, it is exactly the opposite. In ASM, the RP actualy did something – it collected (*,*,RP) and (*,G) Joins, received PIM Register messages, created SPT toward their source on their behalf, sent PIM Register-Stop messsages, received PIM Null-Register messages and responded accordingly – there was a bunch of activities exclusive to an RP in ASM. In BiDir, the only thing RP does is to be a reference point – a vector, just as you said. But if it is just a reference point with no active involvement in the traffic path or processing, its criticality is arguably smaller, and especially considering Phantom RP in which the address does not really belong to any router, there is no traffic flowing through the RP – because none really exists, right? If an address from a physical link was used than, true, multicast traffic would flow through this RP Link (RPL). The RPL does not even physically exist when loopback addresses are used as RP addresses.
Fourth, the RPF in BiDir PIM is still used to determine the proper interface toward the RPL. Its importance is somewhat downplayed in comparison to ASM/SSM but it is still crucial.
Nonetheless, a great blog and overview!
Best regards,
Peter
Thanks a lot for the comments, Peter!
I tried to correct the part of the SPT. Seems I and many others have been wrong in how the RPF works in PIM BiDir, this seems to be a common misconception. I should have checked the RFC for clarity…
I also changed the statement about the criticality, I guess it can be argued both ways. It’s true as you say, that it has a very limited role. On the other hand without a RP, all traffic would not flow. Or am I missing some concept here?
Regarding the traffic flowing through the RP, even if we use a loopback, there must still be physical interfaces on the RP? What am I missing here?
Daniel,
I am honored!
Regarding the criticality of the RP, in both ASM and BiDir, it is imperative that every router in a multicast-enabled network knows who the RP is and how to get to it. BiDir ends here, provided that at least the IP subnet in which the RP is located exists. In ASM, the RP has to actually exist as a network entity and perform all those functions commented earlier.
With the traffic flowing through an RP in BiDir PIM, you have designed your network with point-to-point links between routers, so if the RP happens to be placed in the path the multicast has to flow through then by all means, traffic will flow through it. However, think of multi-access networks as well. In the figures you have posted, the RP has its “left” and “right” neighbor (you didn’t label the routers so I cannot refer to them by their names) connected in a point-to-point fashion. Assume that the “left” and “right” router were connected by a switch, and that the RP was a third router on this common network connecting “left”, RP, and “right”. Would then the multicast flow through the RP? Surely not – it would flow up to the RP but RP would not forward it back, and because there would be no further routers behind RP, it would be silently dropping the multicast without forwarding it anywhere.
Just to be exact, even if you created the multi-access segment between “left” and “right” and had the RP connected to it as a third member, this segment would not be considered the RPL unless the RP was identified by the IP address of its physical interface in this common segment. If the RP was identified by the loopback address, the RPL would also be virtual – the imaginary network constituted by the loopback interface.
Best regards,
Peter
Pingback:CCDE Success: References Used – localpref.net