Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7761

Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)

Pages: 137
Internet Standard: 83
Obsoletes:  4601
Updated by:  8736
Part 7 of 7 – Pages 122 to 137
First   Prev   None

Top   ToC   RFC7761 - Page 122   prevText

4.10. PIM Timers

PIM-SM maintains the following timers, as discussed in Section 4.11. All timers are countdown timers; they are set to a value and count down to zero, at which point they typically trigger an action. Of course, they can just as easily be implemented as count-up timers, where the absolute expiry time is stored and compared against a real-time clock, but the language in this specification assumes that they count downwards to zero.
Top   ToC   RFC7761 - Page 123
   Global Timers

   Per interface (I):

        Hello Timer: HT(I)

        Per neighbor (N):

             Neighbor Liveness Timer: NLT(N,I)

        Per Group (G):

             (*,G) Join Expiry Timer: ET(*,G,I)

             (*,G) Prune-Pending Timer: PPT(*,G,I)

             (*,G) Assert Timer: AT(*,G,I)

             Per Source (S):

                  (S,G) Join Expiry Timer: ET(S,G,I)

                  (S,G) Prune-Pending Timer: PPT(S,G,I)

                  (S,G) Assert Timer: AT(S,G,I)

                  (S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)

                  (S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)

   Per Group (G):

        (*,G) Upstream Join Timer: JT(*,G)

        Per Source (S):

             (S,G) Upstream Join Timer: JT(S,G)

             (S,G) Keepalive Timer: KAT(S,G)

             (S,G,rpt) Upstream Override Timer: OT(S,G,rpt)

   At the DRs or relevant Assert Winners only:

        Per Source,Group pair (S,G):

             Register-Stop Timer: RST(S,G)
Top   ToC   RFC7761 - Page 124

4.11. Timer Values

When timers are started or restarted, they are set to default values. This section summarizes those default values. Note that protocol events or configuration may change the default value of a timer on a specific interface. When timers are initialized in this document, the value specific to the interface in context must be used. Some of the timers listed below (Prune-Pending, Upstream Join, Upstream Override) can be set to values that depend on the settings of the Propagation_Delay and Override_Interval of the corresponding interface. The default values for these are given below. Variable Name: Propagation_Delay(I) +-------------------------------+--------------+----------------------+ | Value Name | Value | Explanation | +-------------------------------+--------------+----------------------+ | Propagation_delay_default | 0.5 secs | Expected | | | | propagation delay | | | | over the local | | | | link. | +-------------------------------+--------------+----------------------+ The default value of the Propagation_delay_default is chosen to be relatively large to provide compatibility with older PIM implementations. Variable Name: Override_Interval(I) +--------------------------+-----------------+-------------------------+ | Value Name | Value | Explanation | +--------------------------+-----------------+-------------------------+ | t_override_default | 2.5 secs | Default delay | | | | interval over | | | | which to randomize | | | | when scheduling a | | | | delayed Join | | | | message. | +--------------------------+-----------------+-------------------------+
Top   ToC   RFC7761 - Page 125
   Timer Name: Hello Timer (HT(I))

|Value Name           | Value  | Explanation                           |
|Hello_Period         | 30 secs| Periodic interval for Hello messages. |
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
|                     |        | message on bootup or triggered Hello  |
|                     |        | message to a rebooting neighbor.      |

   At system power-up, the timer is initialized to
   rand(0, Triggered_Hello_Delay) to prevent synchronization.  When a
   new or rebooting neighbor is detected, a responding Hello is sent
   within rand(0, Triggered_Hello_Delay).

   Timer Name: Neighbor Liveness Timer (NLT(N,I))

| Value Name               |  Value               |  Explanation       |
| Default_Hello_Holdtime   |  3.5 * Hello_Period  |  Default holdtime  |
|                          |                      |  to keep neighbor  |
|                          |                      |  state alive       |
| Hello_Holdtime           |  from message        |  Holdtime from     |
|                          |                      |  Hello message     |
|                          |                      |  Holdtime option.  |

   The Holdtime in a Hello message should be set to
   (3.5 * Hello_Period), giving a default value of 105 seconds.

   Timer Names: Expiry Timer (ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))

| Value Name     |  Value         |  Explanation                       |
| J/P_HoldTime   |  from message  |  Holdtime from Join/Prune message  |

   The value of J/P Holdtime that is included in Join/Prune messages is
   specified below, in the description of "Upstream Join Timer (JT(*,G),
Top   ToC   RFC7761 - Page 126
   Timer Names: Prune-Pending Timer (PPT(*,G,I), PPT(S,G,I),

|Value Name                | Value               | Explanation         |
|J/P_Override_Interval(I)  | Default:            | Short period after  |
|                          | Effective_          | a join or prune to  |
|                          | Propagation_        | allow other         |
|                          | Delay(I) +          | routers on the LAN  |
|                          | Effective_Override_ | to override the     |
|                          | Interval(I)         | join or prune       |

   Note that both Effective_Propagation_Delay(I) and
   Effective_Override_Interval(I) are interface-specific values that may
   change when Hello messages are received (see Section 4.3.3).

   Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))

| Value Name                | Value               | Explanation        |
| Assert_Override_Interval  | Default: 3 secs     | Short interval     |
|                           |                     | before an assert   |
|                           |                     | times out where    |
|                           |                     | the assert winner  |
|                           |                     | resends an Assert  |
|                           |                     | message            |
| Assert_Time               | Default: 180 secs   | Period after last  |
|                           |                     | assert before      |
|                           |                     | assert state is    |
|                           |                     | timed out          |

   Note that for historical reasons, the Assert message lacks a Holdtime
   field.  Thus, changing the Assert Time from the default value is not
Top   ToC   RFC7761 - Page 127
   Timer Names: Upstream Join Timer (JT(*,G), JT(S,G))

|Value Name   | Value              | Explanation                       |
|t_periodic   | Default: 60 secs   | Period between Join/Prune messages|
|t_suppressed | rand(1.1 *         | Suppression period when someone   |
|             | t_periodic, 1.4 *  | else sends a J/P message so we    |
|             | t_periodic) when   | don't need to do so.              |
|             | Suppression_       |                                   |
|             | Enabled(I) is      |                                   |
|             | true, 0 otherwise  |                                   |
|t_override   | rand(0, Effective_ | Randomized delay to prevent       |
|             | Override_          | response implosion when sending a |
|             | Interval(I))       | Join message to override someone  |
|             |                    | else's Prune message.             |

   t_periodic may be set to take into account such things as the
   configured bandwidth and expected average number of multicast route
   entries for the attached network or link (e.g., the period would be
   longer for lower-speed links, or for routers in the center of the
   network that expect to have a larger number of entries).  If the
   Join/Prune-Period is modified during operation, these changes should
   be made relatively infrequently, and the router should continue to
   refresh at its previous Join/Prune-Period for at least
   Join/Prune-Holdtime, in order to allow the upstream router to adapt.

   The Holdtime specified in a Join/Prune message should be set to
   (3.5 * t_periodic).

   t_override depends on the Effective Override Interval of the upstream
   interface, which may change when Hello messages are received.

   t_suppressed depends on the Suppression State of the upstream
   interface (Section 4.3.3) and becomes zero when suppression is
Top   ToC   RFC7761 - Page 128
   Timer Name: Upstream Override Timer (OT(S,G,rpt))

| Value Name    | Value                    |  Explanation              |
| t_override    | see Upstream Join Timer  |  see Upstream Join Timer  |

   The Upstream Override Timer is only ever set to the t_override value;
   this value is defined earlier in this section, under "Timer Names:
   Upstream Join Timer (JT(*,G), JT(S,G))".

   Timer Name: Keepalive Timer (KAT(S,G))

| Value Name            |  Value                |  Explanation         |
| Keepalive_Period      |  Default: 210 secs    |  Period after last   |
|                       |                       |  (S,G) data packet   |
|                       |                       |  during which (S,G)  |
|                       |                       |  Join state will be  |
|                       |                       |  maintained even in  |
|                       |                       |  the absence of      |
|                       |                       |  (S,G) Join          |
|                       |                       |  messages.           |
| RP_Keepalive_Period   |  ( 3 * Register_      |  As                  |
|                       |  Suppression_Time )   |  Keepalive_Period,   |
|                       |  + Register_          |  but at the RP when  |
|                       |  Probe_Time           |  a Register-Stop is  |
|                       |                       |  sent.               |

   The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
   However, at the RP, the keepalive period must be at least the
   Register_Suppression_Time, or the RP may time out the (S,G) state
   before the next Null-Register arrives.  Thus, the KAT(S,G) is set to
   max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop
   is sent.
Top   ToC   RFC7761 - Page 129
   Timer Name: Register-Stop Timer (RST(S,G))

|Value Name                 | Value              | Explanation         |
|Register_Suppression_Time  | Default: 60 secs   | Period during       |
|                           |                    | which a DR stops    |
|                           |                    | sending Register-   |
|                           |                    | encapsulated data   |
|                           |                    | to the RP after     |
|                           |                    | receiving a         |
|                           |                    | Register-Stop       |
|                           |                    | message.            |
|Register_Probe_Time        | Default: 5 secs    | Time before RST     |
|                           |                    | expires when a DR   |
|                           |                    | may send a Null-    |
|                           |                    | Register to the RP  |
|                           |                    | to cause it to      |
|                           |                    | resend a Register-  |
|                           |                    | Stop message.       |

   If the Register_Suppression_Time or the Register_Probe_Time is
   configured to values other than the defaults, it MUST be ensured that
   the value of the Register_Probe_Time is less than half the value of
   the Register_Suppression_Time to prevent a possible negative value in
   the setting of the Register-Stop Timer.
Top   ToC   RFC7761 - Page 130

5. IANA Considerations

5.1. PIM Address Family

The PIM Address Family field was chosen to be 8 bits as a tradeoff between packet format and use of the IANA-assigned numbers. Because when the PIM packet format was designed only 15 values were assigned for Address Families, and large numbers of new Address Family values were not envisioned, 8 bits seemed large enough. However, the IANA assigns Address Families in a 16-bit field. Therefore, the PIM Address Family is allocated as follows: Values 0 through 127 are designated to have the same meaning as IANA-assigned Address Family Numbers [7]. Values 128 through 250 are designated to be assigned for PIM by the IANA based upon IESG Approval, as defined in [9]. Values 251 through 255 are designated for Private Use, as defined in [9].

5.2. PIM Hello Options

Values 17 through 65000 are to be assigned by the IANA. Since the space is large, they may be assigned as First Come First Served, as defined in [9]. Such assignments are valid for one year and may be renewed. Permanent assignments require a specification (see "Specification Required" in [9]).
Top   ToC   RFC7761 - Page 131

6. Security Considerations

This section describes various possible security concerns related to the PIM-SM protocol. The reader is referred to [8], [14], and [15] for further discussion of PIM-SM and multicast security. Note that PIM relies upon an MRIB populated outside of PIM; therefore, securing the sources of change to the MRIB is RECOMMENDED.

6.1. Attacks Based on Forged Messages

The extent of possible damage depends on the type of counterfeit messages accepted. We next consider the impact of possible forgeries, including forged link-local (Join/Prune, Hello, and Assert) and forged unicast (Register and Register-Stop) messages.

6.1.1. Forged Link-Local Messages

Join/Prune, Hello, and Assert messages are all sent to the link-local ALL-PIM-ROUTERS multicast address and thus are not forwarded by a compliant router. A forged message of this type can only reach a LAN if it was sent by a local host or if it was allowed onto the LAN by a compromised or non-compliant router. 1. A forged Join/Prune message can cause multicast traffic to be delivered to links where there are no legitimate requesters, potentially wasting bandwidth on that link. A forged leave message on a multi-access LAN is generally not a significant attack in PIM, because any legitimately joined router on the LAN would override the leave with a join before the upstream router stops forwarding data to the LAN. 2. By forging a Hello message, an unauthorized router can cause itself to be elected as the Designated Router on a LAN. The Designated Router on a LAN is (in the absence of asserts) responsible for forwarding traffic to that LAN on behalf of any local members. The Designated Router is also responsible for register-encapsulating to the RP any packets that are originated by hosts on the LAN. Thus, the ability of local hosts to send and receive multicast traffic may be compromised by a forged Hello message. 3. By forging an Assert message on a multi-access LAN, an attacker could cause the legitimate designated forwarder to stop forwarding traffic to the LAN. Such a forgery would prevent any hosts downstream of that LAN from receiving traffic.
Top   ToC   RFC7761 - Page 132

6.1.2. Forged Unicast Messages

Register messages and Register-Stop messages are forwarded by intermediate routers to their destination using normal IP forwarding. Without data origin authentication, an attacker who is located anywhere in the network may be able to forge a Register or Register-Stop message. We next consider the effect of a forgery of each of these messages. 1. By forging a Register message, an attacker can cause the RP to inject forged traffic onto the shared multicast tree. 2. By forging a Register-Stop message, an attacker can prevent a legitimate DR from registering packets to the RP. This can prevent local hosts on that LAN from sending multicast packets. The above two PIM messages are not changed by intermediate routers and need only be examined by the intended receiver. Thus, these messages can be authenticated end-to-end. Attacks on Register and Register-Stop messages do not apply to a PIM-SSM-only implementation, as these messages are not required for PIM-SSM.

6.2. Non-cryptographic Authentication Mechanisms

A PIM router SHOULD provide an option to limit the set of neighbors from which it will accept Join/Prune, Assert, and Hello messages. Either static configuration of IP addresses or an IPsec security association MAY be used. Furthermore, a PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message. A Designated Router MUST NOT register-encapsulate a packet and send it to the RP unless the source address of the packet is a legal address for the subnet on which the packet was received. Similarly, a Designated Router SHOULD NOT accept a Register-Stop packet whose IP source address is not a valid RP address for the local domain. An implementation SHOULD provide a mechanism to allow an RP to restrict the range of source addresses from which it accepts Register-encapsulated packets. All options that restrict the range of addresses from which packets are accepted MUST default to allowing all packets.
Top   ToC   RFC7761 - Page 133

6.3. Authentication

This document refers to RFC 5796 [8], which specifies mechanisms to authenticate PIM-SM link-local messages using the IPsec Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It also points out that non-link-local PIM-SM messages (i.e., Register and Register-Stop messages) can be secured by a normal unicast IPsec Security Association (SA) between two communicants.

6.4. Denial-of-Service Attacks

There are a number of possible denial-of-service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating false traffic. Authenticating PIM protocol traffic prevents some, but not all, of these attacks. Two of the possible attacks include the following: o Sending packets to many different group addresses quickly can be a denial-of-service attack in and of itself. This will cause many register-encapsulated packets, loading the DR, the RP, and the routers between the DR and the RP. o Forging Join messages can cause a multicast tree to get set up. A large number of forged joins can consume router resources and result in denial of service.

7. References

7.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <>. [3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <>. [4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <>.
Top   ToC   RFC7761 - Page 134
   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,

   [6]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
        RFC 4607, DOI 10.17487/RFC4607, August 2006,

   [7]  IANA, "Address Family Numbers",

   [8]  Atwood, W., Islam, S., and M. Siami, "Authentication and
        Confidentiality in Protocol Independent Multicast Sparse Mode
        (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796,
        March 2010, <>.

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 5226,
        DOI 10.17487/RFC5226, May 2008,

7.2. Informative References

[10] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <>. [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <>. [12] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <>. [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <>. [14] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609, October 2006, <>.
Top   ToC   RFC7761 - Page 135
   [15] Savola, P. and J. Lingard, "Host Threats to Protocol Independent
        Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008,

   [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
        Address in an IPv6 Multicast Address", RFC 3956,
        DOI 10.17487/RFC3956, November 2004,

   [17] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on Protocol
        Independent Multicast - Sparse Mode (PIM-SM) Implementations and
        Deployments", RFC 7063, DOI 10.17487/RFC7063, December 2013,
Top   ToC   RFC7761 - Page 136

Appendix A. Functionality Removed from RFC 4601

Based on a survey of PIM implementations and deployments [17] conducted by the IETF PIM working group, the following functionality of RFC 4601 has been removed due to lack of sufficient implementation and deployment experience: o (*,*,RP) State o PIM Multicast Border Router (PMBR) o Authentication using IPsec


PIM-SM was designed over many years by a large group of people, including ideas, comments, and corrections from Deborah Estrin, Dino Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike Davison, James Huang, Christopher Thomas Brown, and James Lingard. Thanks are due to the American Licorice Company, for its obscure but possibly essential role in the creation of this document.

Authors' Addresses

Bill Fenner Arista Networks Email: Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom Email:
Top   ToC   RFC7761 - Page 137
   Hugh Holbrook
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA  95054


   Isidor Kouvelas
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA  95054


   Rishabh Parekh
   Cisco Systems, Inc.
   170 W. Tasman Drive
   San Jose, CA  95134


   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886


   Lianshu Zheng
   Huawei Technologies Co., Ltd
   Huawei Campus, 156 Beiqing Road, Hai-dian District
   Beijing  100089