PIM-SM, part 2
So this is the 2nd part on how PIM-SM operates. Last time I showed how the initial RPT (shared tree) was constructed, and how data would flow from the source to the receiver.
This time, I want to show you how the optimization technique in SM actually works.
Lets start out with how our traffic flow looked like after the shared tree was constructured:
From this, the blue line represents the SPT build from the RP toward the source. Data is “pulled” by the RP, and then the RP sends it down the shared tree, as indicated by the red line.
Now, from this we can see that data is obviously not flowing in the most effecient manner. Instead of data flowing from R2 to R3 and downwards, data should be able to flow directly from R2 down to R4. This is where something known as SPT switchover comes into play.
SPT switchover is a method by which a last-hop router (last multicast router) can determine if a certain threshold has been exceeded, and if it has, it will switch over to using a (S,G) data path. On cisco routers, this threshold is when the first packet is received down the shared tree, the last hop router will switch to a SPT.
In our scenario, R4 is where all the action occurs. R4 has a (*,G) entry with a J flag attached to it, this flag tells the router that next time a packet is received on this (*,G) entry, it should switch over to doing SPT instead. Here’s what happens:
R3, upon receing the first multicast packet encapsulated inside a register message, unencapsulates this packet and sends it down the shared tree (red line). R4 receives this packet, and looks at its (*,G) entry for this group. It then sees that the (*,G) entry has a J flag on it, which tells the router to construct an (S,G) entry. It does so, and by the rules, it sends a (S,G) join towards R2, since a RPF lookup towards the source seen in the first multicast packet, indicates that R2 is the RPF neighbor. R4 then sends a special type of (*,G) prune towards the RP, called an RPT-bit prune. This prune is actually a (S,G) prune, but it is sent toward the RP instead of toward the source as we would normally do with all (S,G) entries. The reason for this, is that we want to inform the RP (or other upstream routers in the shared tree), that we no longer wish to receive traffic down the shared tree for this group from this source. When the RP receives this special prune, it will look up the incomming interface of this “prune” and prune it from the outgoing interface list of the (S,G) entry it already has (remember that this (S,G) entry was created as part of the SPT between the source and the RP). A shared tree still exists all the way from R4 to the RP, no matter what we do. We have just told it that we dont want to receive multicast traffic from this source to this group down this shared tree. Thats all.
The next step is another optimization technique employed by PIM-SM.
Since we dont have any more interfaces in the outgoing interface list of the RP, the RP sends a prune up its SPT (Source tree), because it doesnt need the data stream anymore. This (S,G) prune is received by R2, which sees that it needs to remove the interface pointing toward the RP, because no more data is needed by the RP. The only interface R2 has in its outgoing interface list now, is the interface toward R4.
In the end, our data flow will look like this:
This is clearly the best path for data to flow in this scenario.
So in the last post about PIM-SM, I will talk about the two dynamic ways of setting a Rendevouz Point. Namely Auto-RP and BSR. Stay tuned.