(draft-archana-pimwg-pim-ping-00.txt) PIM GR Enhancement (draft-kulkarni-pim-gr-enhancement-00.txt) & PIM-PING (draft-archana-pimwg-pim-ping-00.txt) Archana Patel Janardhan Kulkarni

Attempts to address the GR Issue for BSR PIM-BIDIR PIM-SM

Issues with Existing BSR GR, and Proposed Solution If Rebooting Router was E-BSR, Issue : E-BSR reelection takes 5-23 seconds (BS_Override_Interval) C-RP Router does not come to know that E-BSR has rebooted, CRP-Adv message will be sent only at C-RP Adv timer expiry Group-to-RP mapping might be deleted with received non-Empty BSM on non-BSR Routers, As BSM doesn’t have all the C-RP Routers’ gorup-to-rp mappings Approach to solve the Issue : Transition to E-BSR state as soon as BSM with No-Forward-bit received and BSR address in BSM is same as Router’s own address(2-3 seconds) After E-BSR reelection, First BSM is sent with Restart-bit set C-RP Routers trigger C-RP Adv message as soon as BSM with Restart-bit is received Second BSM message is originated after BS_Min_Interval(10 seconds), This allows E-BSR to receive C-RP Adv message from all C-RP Routers

New BSM Message Formats 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |N|R| Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Tag | Hash Mask Len | BSR Priority | | BSR Address (Encoded-Unicast format) | | Group Address 1 (Encoded-Group format) | | RP Count 1 | Frag RP Cnt 1 | Reserved | | RP Address 1 (Encoded-Unicast format) | | RP1 Holdtime | RP1 Priority |C| Reserved | | ……….. | | RP Address m (Encoded-Unicast format) | | RPm Holdtime | RPm Priority |C| Reserved | | Group Address 2 (Encoded-Group format) | | …………. |

Issues with Existing BSR GR & Proposed Solution If C-RP Router is rebooted, Issue: Active source information is restored on C-RP Routers, after Register-suppression-timer expiry at Firsthop routers Approach to solve the Problem: After CRP Router restarts, Trigger C-RP Adv with C-RP-Restart bit set as soon as BSR-Address and unicast route for BSR address are learnt When C-RP Adv message with C-RP Restart bit set is received, BSR originates BSM with RP-Restart bit set When BSM received with RP-Restart bit set, Firsthop router originates null-register immediately for the RP (if acting as active RP)

New CRP Adv Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |C| Reserved | Checksum | | Prefix Count | Priority | Holdtime | | RP Address (Encoded-Unicast format) | | Group Address 1 (Encoded-Group format) | | ………….. | | Group Address n (Encoded-Group format) |

Issue with Existing PIM-BIDIR GR & Proposed Solution If Hello with new-GenID is received from upstream-router (DF-Winner) Downstream Routers trigger joins almost immediately RP Information might not be present or DF election has not happened yet (As unicast routes info are not learnt yet) Joins will be ignored by rebooted router Approach to solve the Problem: Do not trigger joins for Hello message with new Gen-ID Approach 1: When offer message received from current DF-Winner with same metric, Set DF Winner Restart Flag (Indicates DF Winner has rebooted) When Restart Flag is set for DF Winner and DF Winner message is received, Trigger Joins immediately (DF Winner’s state has refreshed) Approach 2: Have the Gen-ID field in DF winner message (same as hello message) When Gen-ID field is changed for DF winner, Trigger joins

Issues with Existing PIM-SM GR If Hello message with new-GenID is received from upstream-Router (RPF’(*, G)/(S, G) or RPF(*, G)/(S, G)), Trigger joins for RPF’ or RPF If Hello message with new-GenID is received from AssertWinner, AssertLoser transitions to NI(NoInfo) state “Joins are sent to RPF’ “ and “the transitions of AssertLoser to NI State” are contradicting Though joins are sent to RPF’, Upstream Router doesn’t know that it is assert-winner. So AssertWinner state will eventually expire on Downstream Router Rebooted Router may choose to ignore the (*, G) join in the absence of RP-Info (If (*, G) joins are received before BSM message)

Proposed Solution for PIM-SM GR Approach to solve the Problem: Assert Loser shouldn’t transition to NI on receiving hello with new-GenID from AssertWinner Joins sent to RPF’ should have AssertWinner bit set in the Join Message, Once all the necessary requirements to be AssertWinner are met, AssertWinner message is triggered by Upstream-router If Assert-Winner receives hello with new Gen-ID, It should reduce the AssertTimer to t_override to restore Assert-Winner state on Downstream-router (to restore RPF’ state) Join messages should be sent after t_RefreshInterval(2-3 Seconds), allowing upstream to learn RP Info Or Send BSM with No-Forward-Bit set before sending Join message

PIM-PING This Feature is extension to existing PIM Protocol To check the convexity in PIM-Domain. To Verify the RP Consistency in PIM-Domain Also, this feature can be extended to, -To find number of receivers for source -To find minimum PMTU for receiver

It has two message types Request and Response and it uses PIM Type 14. Request message is similar to join message and it will be propagated towards destination hop by hop. Each hop adds it response to end of the request packet First hop router to destination or destination router will change this request packet to response packet and unicast this response message to originator. In Case of failure, response message with appropriate error-message will be generated and send to originator by Intermediate router or destination router Response message can have messages like source is active, source is not active but reachable, unicast route for destination is not present, pim-neighbor is not present, pim-configuration is not present, RP is not consistent or RP is consistent etc.

There is no IPv6 mtrace support Instead of using ICMPv6/MLD for mtrace, Extend PIM Protocol itself for this feature. To have common protocol for all the troubleshooting and statistics information for Multicast

Q & A