Multicast PIMv2 Sparse - RP-Reachable, Register-Stop, Best Path Selection

[Andrew Xue Zheng Lay]

Question 1:

R4(config)#ip pim rp-address 10.0.0.4
R4(config)#interface Loopback0
R4(config-if)#ip address 10.0.0.4 255.255.255.255
R4(config-if)#ip pim sparse-mode

After configuring R4 as the Rendezvous Point, R4 started sending "RP-Reachable" from 10.0.0.4 to 224.0.0.2 (All routers in the same segment).

The "RP-Reachable" sent is a PIMv1 packet and is not further propagated.

What is the purpose of "RP-Reachable" and why is this packet PIMv1 format rather than PIMv2?

I did some show commands on its direct neighbours, but I don't see any relation of this being used for peering or keepalives.

Question 2:

When a Multicast Server first send traffic out, the Designated Router (First router that is connected to the Server) will encapsulate that Multicast Traffic within a "Register" packet.

The Rendezvous Point will then reply with a "Register-stop" packet.

Subsequently, the Designated Router will send the "Register" packet every 60 seconds, with a Null Payload.

What does "Register-stop" do and why does subsequently "Register" packet encapsulates Null Payload?

Question 3:

After traffic had been sent through the Rendezvous Point and to the Multicast Clients, if it is found that going through the Rendezvous Point is not the best path, the traffic will be diverted.

How and what did the PIM routers do, to divert the traffic away from the RP?

Are there some sort PIM signalling packets that inform the Upstream PIM Routers that it is not currently using the best path, and should swap path?

[Jon Marshall]

Andrew

I can answer most of your questions but not everything.

q1) this is the bit I am unsure of.

My understanding of the RP reachable message is that it is relayed down the shared tree to other PIM routers so they know the RP is still up.

If they don't receive that message then they assume they need to find a new RP (if they can).

I have no idea why PIMv1 and to be honest it is not something I have ever really looked into.

q2) the first packet as you say is sent encapsulated to the RP and if the RP has no need of the stream ie. no devices have requested it then it sends a register stop to the router connected to the source.

That begins a timer (60 seconds from memory) and when that timer expires the source router would again send the encapsulated payload of the packet to the RP.

As an optimisation though the source router simply sends a empty payload ie. why send a full payload if there is a chance it isn't going to be needed.

It's really just a way of saving having to send multicast traffic to the RP only to be told it isn't needed.

q3) if a router connected to the receiving device knows a better path to the source then it sends an SPT join message to the neighbor on that best path and it's neighbor then sends it to it's neighbor etc. until the join message gets to the router connected to the source of the multicast stream.

At the same time the router connected to the receiving device also sends a prune message towards the RP because otherwise it would be receiving duplicate packets.

Jon

[Andrew Xue Zheng Lay]

Hi Jon,

Thanks for answering.

But I couldn't agree with your answer for Question 2 with regards to the "Register-stop".

Cause my RP is sending "Register-stop" even when there are Downstream requests.

Please take a look at the attached Wireshark Capture.

[AMediaFilm]

"The RP triggers Register-Stop messages in response to Registers, if the RP has no downstream receivers for the group (or for that particular source), or if the RP has already joined the (S,G) tree and is receiving the data packets natively."

rfc-2362, rfc-4601. Cisco is still conservative enough to keep protocols implementations close to RFCs.