PIM GR Enhancement ( draft-kulkarni-pim-gr-enhancement-00.txt ) & PIM-PING

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

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

3. 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

4. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | …………. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. 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)

6. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. Issue with Existing PIM-BIDIR GR & Proposed Solution Issue: • 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

8. Issues with Existing PIM-SM GR Issue: • 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)

9. 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

10. 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

11. 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.

12. 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

13. Q & A