PIM-WG Archana Patel INTERNET-DRAFT Cisco Systems draft-kulkarni-pim-gr-enhancement-00.txt Janardhan Kulkarni Citrix Systems 12 November 2007 Expires: May 2008 PIM GR Enhancement for BSR, BIDIR and SM Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Archana/Janardhan [Page 1] INTERNET-DRAFT Expires: August 2007 February 2007 Abstract This document suggests the GR enhancement for BSR, BIDIR and PIM-SM. -This draft suggests a mechanism to refresh E-BSR state and to learn RP-Set on Rebooted E-BSR Router quickly. -This draft suggests a mechanism for PIM-BIDIR Downstream Routers to refresh the (*, G) state only after 'Rebooted Upstream Router has learnt the RP Information and DF election is complete'. -This draft suggests a mechanism for PIM-SM Downstream Router to delay the (*, G) joins to allow RP Information to be learnt on Rebooted Upstream Router. It also suggests the mechanism to refresh the Assert-Winner or Assert-Loser state on Rebooting Router. Archana/Janardhan [Page 2] INTERNET-DRAFT Expires: May 2008 November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . 5 2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . 7 3. Enhancement for BSR GR Support . . . . . . . . . . . . . . 7 3.1. Rebooting Router is configured as BSR . . . . . . . . 7 3.1.1. Rebooting Router was Elected BSR . . . . . . . . 8 3.1.2. Rebooting Router was Candidate BSR . . . . . . . . 9 3.2. Rebooting Router is configured as CRP . . . . . . . . 10 3.4. Rebooting Router is not BSR or CRP . . . . . . . . . . 11 4. Enhancement for PIM-BIDIR GR Support . . . . . . . . . . . 12 4.1. Designated Forwarder State . . . . . . . . . . . . . 13 5. Enhancement for PIM-SM GR Support . . . . . . . . . . . . 13 5.1. Sending (*, G) and (S, G) joins to Rebooting Router. . 13 5.2. Refreshing Assert-Winner state on Rebooting Router . . 14 5.2.1. Assert Winner State for (S, G) Downstream Interface . . . . . . . . . . . . . . . . . . . 17 5.2.2. Assert Winner state for (*, G) Downstream Interface . . . . . . . . . . . . . . . . . . . 17 5.3. Refresh the Assert-Loser state on Rebooting Router . 17 5.4. State Summarization Macro . . . . . . . . . . . . . . 18 6. BSR/CRP Packet Formats . . . . . . . . . . . . . . . . . 20 6.1. BSM Message Format sent by Elected BSR . . . . . . . . 20 6.2. CRP Adv message Format sent by Rebooted CRP. . . . . . 21 7. PIM-SM Message Format . . . . . . . . . . . . . . . . . . 21 8. Timers and Timers Values . . . . . . . . . . . . . . . . . 22 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Copyright (C) The IETF Trust (2007). . . . . . . . . . . . 24 Archana/Janardhan [Page 3] INTERNET-DRAFT Expires: May 2008 November 2007 1. Introduction This document assumes familiarity with the concepts of -Protocol Independent Multicast - Sparse Mode (PIM-SM) -Protocol Independent Multicast-Bidirectional Protocol -Bootstrap Router mechanism for PIM This document suggests the enhancement in BSR, BIDIR and PIM-SM to extend their GR Support. In order to enhance the existing GR Support for BSR, The Rebooting Router must not only learn the RP-Set quickly but it should also be able to act as E-BSR as quickly as possible after the receipt of first BSM message with No Forward Bit set. C-RP Routers should also be able discover that E-BSR has rebooted, and should update the E-BSR with C-RP Adv message immediately. In the Existing mechanism, Group-to-RP mapping on all the Routers in PIM-Domain might be cleared on receiving BSM message from E-BSR which has recently Rebooted and was acting E-BSR earlier. Same is described in Section 3.1.1 in detail. In Case, If Rebooting Router is configured as C-RP, E-BSR should be able to notify in BSM message that C-RP has Restarted after receipt of first CRP Adv message. On Receiving this BSM message, First Hop router can generate Register Message for active source to CRP Router(if acting as RP) to restore the source information on RP as quickly as possible. This document suggests a mechanism for refreshing the BSR and CRP states of Rebooting Router quickly. As per RFC 5015, BIDIR-PIM, Section 3.4.2, When Router receives the hello message with new Gen-ID for Upstream neighbor, it discovers that Upstream neighbor has lost the state and initiates the triggered (*, G) joins almost immediately. But If upstream router does not have the RP Information or DF Election has not happened yet, Triggered Joins received from Downstream Routers will be ignored. In such case, State for (*, G) will be refreshed only on next periodic join. This document suggests mechanism to ensure that triggered joins by Downstream Routers will be sent only after DF election is done at upstream Router which is Rebooting Router here. Archana/Janardhan [Page 4] INTERNET-DRAFT Expires: May 2008 November 2007 As per RFC 4601, PIM-SM, When a Router receives the Hello message with new Gen-ID for upstream neighbor, it discovers that upstream neighbor has lost the state and It initiates the triggered joins almost immediately. But again, Upstream-routers might choose to ignore the (*, G) joins, if it is received before acquisition of RP-Information, resulting in delay of (*, G) state refresh until next periodic (*, G) joins This document suggests to introduce the delay in triggered join by Downstream router allowing Rebooting Router to learn RP Information. As per RFC 4601, PIM-SM, When a Assert-Loser receives the Hello message with new Gen-ID, It transition to No-Info State. This document also suggests the mechanism to restore the Assert-Winner and Assert-Loser State on Rebooting Router. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant PIM GR Enhancement. 2.1. Definitions This specification uses a number of terms to refer to the roles of routers participating in BSR, PIM-BIDIR and PIM-SM. The following terms have special significance for these Protocols: Rendezvous Point (RP): An RP is a router that has been configured to be used as the root of the non-source-specific distribution tree for a multicast group. Join messages from receivers for a group are sent towards the RP, and data from senders is sent to the RP so that receivers can discover who the senders are and start to receive traffic destined for the group. Designated Router (DR): A shared-media LAN like Ethernet may have multiple PIM-SM/BIDIR routers connected to it. A single one of these routers, the DR, will act on behalf of directly connected hosts with respect to the PIM-SM protocol. A single DR is elected per interface (LAN or otherwise) using a simple election process. Archana/Janardhan [Page 5] INTERNET-DRAFT Expires: May 2008 November 2007 Upstream Towards the root (RP or Source) of the tree. The direction used by packets traveling from sources to the RP or Source to the Receiver. Downstream Away from the root of the tree. The direction on which packets travel from the RP to receivers or Source to receivers. Designated Forwarder (DF) PIM-BIDIR is largely based on the concept of a Designated Forwarder (DF). A single DF exists for each RP on every link within a BIDIR-PIM domain (this includes both multi-access and point-to-point links). The DF is the router on the link with the best route to the RP (determined by comparing MRIB provided metrics). A DF for a given RP is in charge of forwarding downstream traffic onto its link, and forwarding upstream traffic from its link towards the RP. The DF on a link is also responsible for processing Join messages from downstream routers on the link as well as ensuring that packets are forwarded to local receivers. RPF Interface RPF stands for "Reverse Path Forwarding". The RPF Interface of a router with respect to an address is the interface that the MRIB indicates should be used to reach that address. RPF Neighbor The RPF Neighbor of a router with respect to an address is the neighbor that the MRIB indicates should be used to reach that address. Note that in BIDIR-PIM, the RPF neighbor for a group is not necessarily the router on the RPF interface that Join messages for that group would be directed to (Join messages are only directed to the DF on the RPF interface for the group). MRIB Multicast Routing Information Base. This is the multicast topology table, which is typically derived from the unicast routing table, or routing protocols such as Multiprotocol BGP (MBGP) that carry multicast-specific topology information. In PIM-SM, the MRIB is used to decide where to send Join/Prune messages. A secondary function of the MRIB is to provide routing metrics for destination addresses; these metrics are used when sending and processing Assert messages. Archana/Janardhan [Page 6] INTERNET-DRAFT Expires: May 2008 November 2007 2.2. Pseudocode Notation Following set notation is used in several places in this specification. A (+) B is the union of two sets A and B. A (-) B is the elements of set A that are not in set B. In addition we use C-like syntax: = denotes assignment of a variable. == denotes a comparison for equality. != denotes a comparison for inequality. Braces { and } are used for grouping. 3. Enhancement for BSR GR Support As per draft-ietf-pim-sm-bsr-12.txt, Section 3.5, "To allow Rebooting routers to learn the RP-Set quickly, when a Hello message is received with a new GenID from an existing neighbor, Router which is DR on LAN or if rebooting Router is DR, Router which would be DR if Rebooting Router is excluded on LAN, sends the BSM message with No Forward Bit set. And RPF check must not be performed on this BSM message." This section suggests enhancement in the processing of the BSM message for quick refresh of BSR and C-RP State. If Rebooting router has more than one link with pim-enable, It is recommended to process only first BSM message with No Forward Bit set and ignore the sub-sequent BSM message with No Forward Bit set. 3.1. Rebooting Router is configured as BSR As per suggested enhancement, It is recommended that Rebooting Router configured as BSR should delay the originating Bootstrap message for t_RefreshInterval, allowing itself to learn the BSR State from its Peer Routers through BSM message. On Rebooting Router, If No BSM message is received from Peer during t_RefreshInterval, Rebooting Router start the BSR election process as mentioned in draft-ietf-pim-sm-bsr-12.txt, Section 3.1. Archana/Janardhan [Page 7] INTERNET-DRAFT Expires: May 2008 November 2007 3.1.1 Rebooting Router was Elected BSR If Rebooting Router was Elected BSR, After Reboot, It starts acting as E-BSR(transition from P-BSR to E-BSR) after BS_Rand_Override. And then E-BSR waits for BS_Min_Interval to receive C-RP Adv messages. But CRP Router generates CRP-Adv message immediately only if new BSR is elected. Since CRP Router does not know that E-BSR has been rebooted, CRP Adv will be sent only after CRP Timer expires. In this case, During BS_Min_Interval, E-BSR will receive C-RP adv message only for those C-RP routers whose C-RP timers have expired. Suppose It receives CRP Adv from only one CRP, after BS_Min_Interval, BSM message sent only with one Group-to-RP mapping. On Receiving this BSM message, Routers in PIM-Domain will clear all the other Group-to-RP mappings from RP-Set as those are not present in BSM message. This Section suggests the Processing of BSM message and State-transition at E-BSR. Processing of Bootstrap message at Rebooting Router On Receiving the BSM message with BSR address same as Router's own BSR address, It should transition to the Elected BSR immediately and use the group-to-RP mapping of BSM message to store RP-Set. Originating new Bootstrap message at BSR E-BSR should now immediately originates the BSM message using the RP-Set and It should be sent out through all the interfaces on which pim-neighbor is present. This BSM message should have RestartedBSR bit set as described in Section 6.1. Next BSM message should be originated after BS_Min_Interval, allowing itself to receive C-RP Adv message. It is recommended that BSM message should not be generated during this interval for any RP-Set change at BSR. Processing of Bootstrap message at CRP Router CRP Router should originate CRP Adv message to E-BSR immediately on receiving BSM message with RestartedBSR bit set. Processing of CRP Adv message at BSR is same as mentioned in draft-ietf-pim-sm-bsr-12.txt. Archana/Janardhan [Page 8] INTERNET-DRAFT Expires: May 2008 November 2007 Figure 1: E-BSR state machine at Rebooting Router in tabular form +-------------------------------------------------------------------------+ | When Rebooting Router was Elected BSR state | +-----------+------------------+--------------------+---------------------+ | Event | Receive BSM with | t_RefreshInter | P-BSR state, | | | No Forward bit Set | val Timer | Receive BSM with | | | and with BSR address | Expires | No Forward Bit set, | | | same as Router's | | and with BSR address| | | own BSR address | | same as Router's | | | No BSM Msg Rcvd yet | No BSM Rcvd yet| own BSR address | +-----------+----------------------+----------------+---------------------+ | | -> E-BSR state | -> P-BSR state| -> E-BSR state | | | | Set Bootstrap | | | Action | Store RP-Set; | Timer to | Store RP-Set | | | Set Bootstrap | BS_Rand_ | Set Bootstrap | | | Timer to | Overide | Timer to BS_Timeout | | | BS_Timeout | | | | | | | Originate the BSM | | | Originate the BSM | | using RP-Set, with | | | using RP-Set, with | | RestartedBSR Bit set| | | RestartedBSR Bit set| | | +-----------+----------------------+----------------+---------------------+ 3.1.2 Rebooting Router was Candidate BSR On Rebooting Router, If BSM message is received with BSR address not same as Router's own BSR address and It is preferred BSR, It should transition to C-BSR immediately. It should use the Group-to-RP mapping of BSM message and Store the RP-Set. On Rebooting Router, If BSM message is received with BSR address not same as Router's own BSR address and It is non-preferred BSR, It becomes the P-BSR, use the Group-to-RP mapping of BSM message and store the RP-Set. And It originates the empty BSM message to initiate the BSR election as mentioned in draft-ietf-pim-sm-bsr-12.txt, Section 3. Archana/Janardhan [Page 9] INTERNET-DRAFT Expires: May 2008 November 2007 Figure 2: c-BSR state machine at Rebooting Router in tabular form +-------------------------------------------------------------------------+ | When Rebooting Router was Candidate BSR state | +-----------+------------------+--------------------+---------------------+ | Event | Receive BSM with | t_RefreshInter | P-BSR state | | | No Forward bit Set | val Timer | Received Proffered | | | and with BSR address | Expires | BSM with No Forward | | | not same as | | Bit set and BSR | | | Router's own BSR | | address not same as | | | address | | Router's own BSR | | | No BSM Msg Rcvd yet | No BSM Rcvd yet| Address | +-----------+----------------------+----------------+---------------------+ | | -> c-BSR state | -> P-BSR state| -> c-BSR state | | | | Set Bootstrap | | | Action | Store RP-Set; | Timer to | Store RP-Set; | | | Set Bootstrap | BS_Rand_ | Set Bootstrap Timer | | | Timer to | Overide | to BS_Timeout | | | BS_Timeout | | | | | | | | +-----------+----------------------+----------------+---------------------+ 3.2 Rebooting Router is configured as Candidate-RP On Rebooting Router, When BSM message is received with No Forward Bit, It transition to Accept Preferred set, Store RP-Set and Set Bootstrap Timer to BS_Timerout and Send C-RP Adv message to BSR with CRP Restarted Bit set as described in Section 6.2. But this CRP Adv message must delay for t_RouteRefreshInterval to learn unicast Routing information for BSR address. Processing of CRP Adv at BSR When C-RP Adv message received with CRP Restarted Bit set at BSR, It originates the BSM message with BSR CRP Restarted bit set as described in Section 6.1. Processing BSM message with BSR CRP Restarted Bit Set When First Hop Router receives group-to-RP mapping with BSR CRP Restarted Bit set in BSM message, It knows that RP has lost Active Source information and originates the register message to Rebooted Router which is CRP. Archana/Janardhan [Page 10] INTERNET-DRAFT Expires: May 2008 November 2007 Figure 3: C-RP state machine at Rebooting Router in tabular form +---------------------------------------------------------+ | When Rebooting Router was Candidate RP state | +-----------+------------------+--------------------------+ | Event | Receive BSM with | | | No Forward bit Set | | | | | | | | | No BSM Message Rcvd yet | +-----------+----------------------+----------------------+ | | ->AP State | | | Send C-RP Adv message | | | to BSR address with CRP Restarted Bit set | | Action | Store RP-Set; | | | Set Bootstrap | | | Timer to | | | BS_Timeout | | | | +-----------+----------------------+----------------+-----+ 3.3 Router is not candidate RP or BSR If Rebooting Router is not configured as BSR or C-RP, It process the first BSM received with No-Forward Bit set to store the RP set. Figure 4: Non-BSR and Non-CRP state machine at Rebooting Router in tabular form +---------------------------------------------------+ | When Rebooting Router was Non C-RP and Non-BSR | +-----------+---------------------------------------+ | Event | Receive BSM with | | | No Forward bit Set | | | | | | No BSM Message Rcvd yet | +-----------+---------------------------------------+ | | ->AP State | | | | | Action | Store RP-Set; | | | Set Bootstrap | | | Timer to | | | BS_Timeout | | | | +-----------+---------------------------------------+ Archana/Janardhan [Page 11] INTERNET-DRAFT Expires: May 2008 November 2007 4. Enhancement for PIM-BIDIR GR Support As per RFC 5015, PIM-BIDIR, Section 3.4.2, When a Router receives the Hello Message with new Gen-ID from upstream neighbor, It triggers the (*, G) joins almost immediately. But in case, RP Information has not been learnt or DF Election has not yet happened on Rebooting Router, the Triggered (*, G) Joins will be ignored. This draft suggests the mechanism to ensure that triggered joins are sent by Downstream Routers only after DF election is done on Rebooting Router. Once the Rebooting router has learnt the RP information, it starts sending the offer messages on the link. With the receipt of this offer messages, the router comes to know that the DF winner has lost the (*,G) state, and it sets the RefreshState flag for DF winner on Interface as described in section 4.2. After advertising metrics Election_Robustness times, Rebooting Router becomes the DF Winner and sends out the DF winner message. Receiving DF Winner message from the Current DF Winner which has StateRefresh flag set, Router discovers that DF Winner's state is restored, and it resets the StateRefresh Flag for DF Winner, and triggers the (*, G) join almost immediately. If Rebooted Router was DF loser, State-Transition is same as mentioned in RFC 5015, Section 3.5. Figure 5. State-Machine for DF Loser, when DF Winner has Rebooted +-------------------------------------------------------------------------+ | Router on Link is in Lose State | +-----------+------------------+--------------------+---------------------+ | Event | Receive the Offer | Receive winner message from DF winner| | | message from current | | | | DF Winner with Same | StateRefresh flag is set for DF | | | Metric | Winner | | | | | | | | | +-----------+----------------------+----------------+---------------------+ | | ->Lose state | ->Lose State | | | Set the DF Winner's | Reset StateRefresh flag for DF Winner| | Action | StateRefresh flag | | | | | Send Triggered (*, G) Joins | | | | to DF winner | +-----------+----------------------+----------------+---------------------+ Archana/Janardhan [Page 12] INTERNET-DRAFT Expires: May 2008 November 2007 4.1 Designated Forwarder State As per RFC 5015, PIM-BIDIR, Section 3.1.2, DF state is store for every RP on each Router interface. o RPA (actual address) Designated Forwarder (DF) State: For each router interface: Acting DF information: o DF IP Address o DF metric o DF StateRefresh Election information: o Election State o DF election-Timer o Message-Count Current best offer: o IP address of best offering router o Best offering router metric Designated Forwarder State on Interface has new Flag DF StateRefresh. This flag will be Set on receiving Offer message from Current DF winner with same Metric. And this flag will be cleared with receiving Winner message from the Current DF winner or DF Winner is changed. 5. Enhancement for PIM-SM GR Support 5.1 Sending (*, G) and (S, G) joins to Rebooting Router As Per RFC 4601, PIM-SM, section 4.5.6, When a Router receives the Hello Message with new Gen-ID for the upstream-neighbor, It triggers the (*, G) joins almost immediately to refresh the (*, G) state on upstream-neighbor. Archana/Janardhan [Page 13] INTERNET-DRAFT Expires: May 2008 November 2007 But when triggered join is received on Rebooted Router, RP Information RP(G) might not be present, and as mentioned in RFC 4601, Section 4.5.2, Rebooted Router may choose to ignore the (*, G) joins. In this case, (*, G) state will be restored only after next periodic join. This draft suggests the delay in (*, G) triggered joins by t_RefreshInterval which allows Router to learn the RP Information by BSM message. Same Applies to triggered join Sent to RPF'(*, G) which need to be delayed by t_RefreshInterval. As mentioned in RFC 4601 PIM-SM, Triggered joins for RPF(S, G) can be sent almost immediately and Triggered joins for RPF'(S, G) can be sent after t_override interval, Section 4.5.6. 5.2 Refreshing Assert-Winner State on Rebooting Router As per RFC 4601, PIM-SM Section 4.6.2, When Assert Loser receive the Hello message from Assert winner with new Gen-ID, it moves to No-Info state. This section suggests the mechanism to refresh the assert winner state on Rebooting Router. When Assert Loser Router receives the Hello message with new Gen-ID from Assert-Winner, Assert Loser must not transition to No-Info state. Figure 6. State Machine for Assert Loser +---------------------------------+ | In I Am Assert Loser (L) State | +---------------------------------+ |Current Winner's Assert GenID | |Changes | +---------------------------------+ | ->L State | +---------------------------------+ Refreshing Assert-Winner on Downstream Interface of (S, G) When a Assert Loser Router receives the Hello message with new Gen-ID from Assert-Winner on Interface I, It is RPF(s, G) and (S, G) is in Join State, It should trigger (S, G) joins with AssertWinner Bit set as described in Section 7. Subsequent Join message will have AssertWinner bit cleared. Archana/Janardhan [Page 14] INTERNET-DRAFT Expires: May 2008 November 2007 Receiving this (S, G) joins with AssertWinner bit set on Interface I, Rebooting Router should create the (S, G) state same as mentioned in RFC 4601, Section 4.5.3, with AssertWinner Flag set on Downstream Interface state for I. AssertWinner Flag is described in Section 5.2.1. And If RPF(S, G) is exist or Once the RPF(S, G) is learnt on Rebooted Router and Could_BeAssertWinner(S, G, I) is TRUE, It sets the SPT bit for (S, G) and originates the Assert Winner message on Interface I. AssertWinner Flag is cleared on Downstream Interface State for I after originating Assert Winner message on Interface I or Could_beAssertWinner(S, G, I) becomes FALSE. State Transition with Assert Message Processing is same as Mentioned in RFC 4601, PIM-SM, Section 4.6. Refreshing Assert-Winner on Downstream Interface of (*, G) And a Assert Loser Router receives the Hello message with new Gen-ID from Assert-Winner on Interface I, It is RPF(*, G) and (*, G) is in Join State, It should trigger (*, G) joins with AssertWinner Bit set as described in Section 7. Subsequent Join message will have AssertWinner bit cleared. Receiving this (*, G) joins with AssertWinner bit set on Interface I, Rebooting Router should create the (*, G) state same as mentioned in RFC 4601, Section 4.5.2, with AssertWinner Flag set on Downstream Interface state for I. AssertWinner Flag is described in 5.2.2. And If RPF(*, G) is exist or Once the RPF(*, G) is learnt and Could_BeAssertWinner(*, G, I) is TRUE, It originates the Assert Winner message on Interface I. AssertWinner Flag is cleared on Downstream Interface State for I after originating Assert Winner message on Interface I or Could_BeAssertWinner(*, G, I) becomes FALSE. State Transition with Assert Message Processing is same as Mentioned in RFC 4601, PIM-SM, . Archana/Janardhan [Page 15] INTERNET-DRAFT Expires: May 2008 November 2007 Figure 7. State-Machine for RPF/RPF' GenID Change +----------------------------------------------------------------------+ | In Joined (J) State | +----------------------------------+-----------------------------------+ | RPF'(S,G)/RPF(S, G) GenID | RPF'(*,G)/RPF(*, G) GenID change | | Change | | +----------------------------------+-----------------------------------+ | Decrease Join Timer to | Decrease Join Timer to | | t_override | t_RefreshInterval | | | | | For RPF'(S, G), Send Join for | For RPF'(*, G), Send Join for | | (S, G) with AssertBit Set | (*, G) with AssertBit Set | | | | +----------------------------------+-----------------------------------+ Could_BeAssertWinner(S,G) = (RPF_interface(S) != I) AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (-) lost_assert(*,G) (+) joins(S,G) (+) pim_include(S,G) ) ) AND AssertWinner Flag set on I Could_BeAssertWinner(S,G,I) is true for downstream interfaces that would be in the inherited_olist(S,G) if (S,G) assert information was not taken into account and AssertWinner Flag set on Downstream Interface State of I. Could_BeAssertWinner(*,G,I) = ( I in ( joins(*,*,RP(G)) (+) joins(*,G) (+) pim_include(*,G)) ) AND (RPF_interface(RP(G)) != I) AND AssertWinner Flag set on Downstream Interface State of I Could_BeAssertWinner(*,G,I) is true on downstream interfaces for which we have (*,G) join state, or local members that requested any traffic destined for G and AssertWinner Flag set on I. Archana/Janardhan [Page 16] INTERNET-DRAFT Expires: May 2008 November 2007 5.2.1 Assert-Winner State for (S, G) Downstream interface (S,G) state: For each interface: (S,G) Assert Winner State o State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)} o Assert Timer (AT) o Assert winner's IP Address (AssertWinner) o Assert winner's Assert Metric (AssertWinnerMetric) o Assertwinner Flag(applies to only Downstream Interface) 5.2.2. Assert-Winner State for (*, G) Downstream interface (*,G) State: For every group G, a router keeps the following state: (*,G) state: For each interface: (*,G) Assert Winner State o State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)} o Assert Timer (AT) o Assert winner's IP Address (AssertWinner) o Assert winner's Assert Metric (AssertWinnerMetric) o Assertwinner Flag(applies to only Downstream Interface) 5.3 Refreshing Assert-Loser State on Rebooting Router When a Router receives the Hello message with new Gen-ID on interface I and it is AssertWinner(S, G, I) or AssertWinner(*, G, I), it should decreases the AT Timer to t_RefreshAssertInterval to trigger the Assert Winner message on Interface I. Archana/Janardhan [Page 17] INTERNET-DRAFT Expires: May 2008 November 2007 Delaying Assert Message for t_RefreshAssertInterval to allow router to learn RP info, to refresh (*, G) and (S, G) state and to learn the unicast routing information. If Rebooting Router is Downstream-routers, This allows to restore the Assert-Winner state on Upstream Interface of Rebooting Routers quickly. Figure 8. State-Machine for GenID Change on I, I is AssertWinner(*, G, I)/(S, G, I) +----------------------------------------------------------------------+ | In AssertWinner State for (*, G, I)/(S,G, I) | +----------------------------------+-----------------------------------+ | GenID Change Received on I, | GenID change Received on I, | | I is AssertWinner(S, G, I) | I is AssertWinner(*, G, I) | +----------------------------------+-----------------------------------+ | Decrease AT Timer to | Decrease AT Timer to | | t_RefreshAssertInterval | t_RefreshAssertInterval | | | | +----------------------------------+-----------------------------------+ 5.4 State Summarization Macros As per RFC 4601 PIM-SM, Section 4.1.6, follwing are the State Macros used in this specification. pim_include(*,G) = { all interfaces I such that: ( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE ) OR AssertWinner(*,G,I) == me ) AND local_receiver_include(*,G,I) } pim_include(S,G) = { all interfaces I such that: ( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE ) OR AssertWinner(S,G,I) == me ) AND local_receiver_include(S,G,I) } pim_exclude(S,G) = { all interfaces I such that: ( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE ) OR AssertWinner(*,G,I) == me ) AND local_receiver_exclude(S,G,I) } Archana/Janardhan [Page 18] INTERNET-DRAFT Expires: May 2008 November 2007 The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD module or other local membership mechanism has determined that local members on interface I desire to receive traffic sent specifically by S to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD module or other local membership mechanism has determined that local members on interface I desire to receive all traffic sent to G (possibly excluding traffic from a specific set of sources). "local_receiver_exclude(S,G,I) is true if "local_receiver_include(*,G,I)" is true but none of the local members desire to receive traffic from S. The set "joins(*,G)" is the set of all interfaces on which the router has received (*,G) Joins: joins(*,G) = { all interfaces I such that DownstreamJPState(*,G,I) is either Join or Prune-Pending } The set "joins(S,G)" is the set of all interfaces on which the router has received (S,G) Joins: joins(S,G) = { all interfaces I such that DownstreamJPState(S,G,I) is either Join or Prune-Pending } Archana/Janardhan [Page 19] INTERNET-DRAFT Expires: May 2008 November 2007 6. BSR/CRP Packet Formats 6.1. BSM message Format sent by Elected BSR 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address n (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Count n | Frag RP Cnt n | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address 1 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1 Holdtime | RP1 Priority |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address 2 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2 Holdtime | RP2 Priority |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Archana/Janardhan [Page 20] INTERNET-DRAFT Expires: May 2008 November 2007 | RP Address m (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm Holdtime | RPm Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [R]estartedBSR Bit When set this Bit means that E-BSR Router has rebooted. BSR [C]RP Restarted Bit When set this Bit means that C-RP Router has rebooted. 6.2. CRP Adv message Format sent by Rebooted CRP 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [C]RP Restarted Bit When set this Bit means that CRP Router has rebooted(CRP notifies to E-BSR). 7. PIM-SM Packet Format Encoded Source address of Join message will have AssertWinner Bit. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Rsrvd |A|S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Archana/Janardhan [Page 21] INTERNET-DRAFT Expires: May 2008 November 2007 [A]ssertWinner Bit When set this Bit means that Receiver of Join is assert winner for (S, G) or (*, G) join 8. Timers and Timers Values +---------------------+------------------------+-----------------------+ | Value Name | Value | Explanation | +---------------------+------------------------+-----------------------+ | t_RefreshInterval | Default: 2 seconds | Interval after which| | | | Rebooted BSR Router | | | | will start | | | | originating | | | | BSM Message, if | | | | BSM Message is not | | | | received | +---------------------+------------------------+-----------------------+ | BS_Timeout | Default: 130 seconds | Interval after | | | | which a BSR is | | | | timed out if no | | | | BSM is received | | | | from that BSR | +---------------------+------------------------+-----------------------+ | BS_Min_Interval | Default: 10 seconds | Minimum interval | | | | with which BSMs | | | | may be originated | +---------------------+------------------------+-----------------------+ | t_RefreshAssert | Default: 15 seconds | Interval after which | | Interval | | AssertWinner triggers| | | | AssertWinner message | | | | after receiving Hello| | | | with new GenID | | | | election | +---------------------+------------------------+-----------------------+ | t_RouteRefresh | Default: 15 seconds | Interval after which | | Interval | | CRP sends the CRP | | | | Adv message to | | | | E-BSR after it | | | | reboot | | | | | +---------------------+------------------------+-----------------------+ | C_RP_Adv_Period | Default: 60 seconds | Periodic interval | | | | with which C-RP- | | | | Adv messages are | | | | sent to a BSR | +---------------------+------------------------+-----------------------+ Archana/Janardhan [Page 22] INTERNET-DRAFT Expires: May 2008 November 2007 9. Authors' Addresses Archana Patel Cisco Systems, Inc. Bangalore archanap@cisco.com Janardhan Kulkarni Citrix Systems Bangalore janardhan.kulkarni@citrix.com 10. References [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [2] Handley, I. Kouvelas, T. SpeakMan, L. Vicisano, "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", RFC5015. [3] Bhaskar, N., Gall, A., Lingard, J. and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", Work in progress , June 2007. Archana/Janardhan [Page 23] INTERNET-DRAFT Expires: May 2008 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Archana/Janardhan [Page 24]