PIM WG Z. Zhang Internet-Draft ZTE Corporation Intended status: Standards Track F. Hu Expires: April 3, 2021 Individual B. Xu ZTE Corporation M. Mishra Cisco Systems September 30, 2020 Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement draft-ietf-pim-dr-improvement-10 Abstract Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely deployed multicast protocol. As deployment for the PIM protocol is growing day by day, a user expects lower packet loss and faster convergence regardless of the cause of the network failure. This document defines an extension to the existing protocol, which improves the PIM protocol's stability with respect to packet loss and convergence time when the PIM Designated Router (DR) role changes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 3, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires April 3, 2021 [Page 1] Internet-Draft PIM DR Improvement September 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 3.1. Election Algorithm . . . . . . . . . . . . . . . . . . . 5 3.2. Sending Hello Messages . . . . . . . . . . . . . . . . . 5 3.3. Receiving Hello Messages . . . . . . . . . . . . . . . . 6 3.4. Working with the DRLB function . . . . . . . . . . . . . 6 4. PIM Hello message format . . . . . . . . . . . . . . . . . . 7 4.1. DR Address Option format . . . . . . . . . . . . . . . . 7 4.2. BDR Address Option format . . . . . . . . . . . . . . . . 7 4.3. Error handling . . . . . . . . . . . . . . . . . . . . . 7 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Multicast technology, with PIM-SM ([RFC7761]), is used widely in modern services like IPTV and Net-Meeting. Some events, such as changes in unicast routes, or a change in the PIM-SM DR, may cause the loss of multicast packets. The PIM DR has two responsibilities in the PIM-SM protocol. For any active sources on a LAN, the PIM DR is responsible for registering with the Rendezvous Point (RP) if the group is operating in PIM-SM. Also, the PIM DR is responsible for tracking local multicast listeners and forwarding data to these listeners if the group is operating in PIM-SM. Zhang, et al. Expires April 3, 2021 [Page 2] Internet-Draft PIM DR Improvement September 2020 + + | | +-----+----+ +-----+----+ | RouterA | | RouterB | +-----+----+ +-----+----+ | | +----+----+--------+---------+---+----+ | | | + + + Receiver1 Receiver2 Receiver3 Figure 1: An example of multicast network The simple network in Figure 1 presents two routers (A and B) connected to a shared-media LAN segment. Two different scenarios are described to illustrate potential issues. (a) Both routers are on the network, and RouterB is elected as the DR. If RouterB then fails, multicast packets are discarded until RouterA is elected as DR and it assumes the multicast flows on the LAN. As detailed in [RFC7761], a DR's election is triggered after the current DR's Hello_Holdtime expires. When the DR (RouterB) is deemed unavailable, as the result of DR failure detection, RouterA is elected as the DR. Then RouterA joins the multicast trees, starts receiving the flows and proceeds with the multicast forwarding. All the procedures usually take several seconds. That is too long for modern multicast services. (b) Only RouterA is initially on the network, making it the DR. If RouterB joins the network with a higher DR Priority. Then it will then be elected as DR. RouterA will stop forwarding multicast packets, and the multicast flows will not recover until RouterB assumes the multicast flows on the LAN. In either of the situations listed, many multicast packets are lost, and the quality of multicast services noticeably affected. To increase the stability of the network, this document introduces the Designated DR (DR) and Backup Designated Router (BDR) options and specifies how its identity is explicitly advertised. 1.1. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Zhang, et al. Expires April 3, 2021 [Page 3] Internet-Draft PIM DR Improvement September 2020 2. Terminology Backup Designated Router (BDR): Immediately takes over all DR functions ([RFC7761]) on an interface once the DR is no longer present. A single BDR SHOULD be elected per interface. Designated Router Other (DROther): A router which is neither a DR nor a BDR. 0x0: 0.0.0.0 if IPv4 addresses are in use or 0:0:0:0:0:0:0:0/128 if IPv6 addresses are in use. To simplify, 0x0 is used in abbreviation in this draft. 3. Protocol Specification The router follows the following procedures: (a). A router first starts sending Hello messages with the values of DR and BDR Address options are all set to 0x0, after its interface is enabled in PIM on a shared-media LAN. The router treats itself as DROther role, and starts a timer which value is set to Hello_Holdtime. (b). When the router receives Hello messages from other routers on the same shared-media LAN, the router checks the value of DR/BDR Address option. If the value is filled with a non-zero IP address, the router stores the IP addresses. (c). When a Hello message with a non-zero DR Address option is received or after the timer expires, the router first executes the algorithm defined in section 3.1. After that, the router first one of the roles in the LAN: DR, BDR, or DROther. If the role of the router first starts changes to BDR, the following steps are: o The BDR takes on all the functions of a DR as specified in [RFC7761], except that it SHOULD NOT actively forward multicast flows or send a register message to avoid duplication. o If the DR becomes unreachable on the LAN, the BDR MUST take over all the DR functions, including multicast flow forwarding or send the register message. Mechanisms outside the scope of this specification, such as [I-D.ietf-pim-bfd-p2mp-use-case] or BFD Asynchronous mode [RFC5880] can be used for faster failure detection. Zhang, et al. Expires April 3, 2021 [Page 4] Internet-Draft PIM DR Improvement September 2020 For example, there are three routers: A, B, and C. If all three were in the LAN, then their DR preference would be A, B, and C, in that order. Initially, only C is on the LAN, so C is DR. Later, A joins; C is still the DR, and A is the BDR. Later B joins, and if B is better than A, then B becomes the BDR, and A is simply DROther. 3.1. Election Algorithm The DR and BDR election is according to the DR election algorithm defined in section 9.4 in [RFC2328], except: o The DR is elected among the DR candidates directly. If there is no DR candidates, i.e., no router advertise the DR Address options with a non-zero IP address, the elected BDR will be the DR. And then the BDR is elected again from the other routers in the LAN. o The BDR election is not sticky. Whatever there is a router that advertise the BDR Address option, the router which has the highest priority, expect the elected DR, is elected as the BDR. That is the BDR may be the router which has the highest priority in the LAN. o The advertisement is through PIM Hello message. o Step 6 and 7 in section 9.4 in [RFC2328] are not applicable here. Compare to the DR election function defined in section 4.3.2 in [RFC7761] the differences include: o The router, that can be elected as DR, has the highest priority among the DR candidates. The elected DR may not be the one that has the highest priority in the LAN. o The router that supports the election algorithm defined in section 3.1 MUST advertise the DR Address option defined in section 4.1 in PIM Hello message, and SHOULD advertise the BDR Address option defined in section 4.2 in PIM Hello message. In case a DR is elected and no BDR is elected, only the DR Address option is advertised in the LAN. 3.2. Sending Hello Messages When PIM is enabled on an interface or a router first starts, Hello messages MUST be sent with the values of the DR Address option filled with 0x0. The BDR Address option SHOULD be sent, if the option is carried, the value MUST be filled with 0x0. Then the interface starts a timer which value is set to Hello_Holdtime. When the timer Zhang, et al. Expires April 3, 2021 [Page 5] Internet-Draft PIM DR Improvement September 2020 expires, the DR and BDR will be elected on the interface according to the DR election algorithm (Section 3.1). DR newcomer \ / ----- ----- ----- | A | | B | | C | ----- ----- ----- | | | | | | ------------------------------------------- LAN Figure 2 For example, there is a stable LAN that includes RouterA and RouterB. RouterA is the DR that has the highest priority. RouterC is a newcomer. RouterC sends a Hello message with the DR and BDR Address options are all set to zero. When a router first starts (RouterC) elects itself as the BDR after it running the election algorithm, the router sends Hello messages with the value of DR is set to the IP address of current DR (RouterA) and the value of BDR is set to the IP address of the router first starts itself (RouterC). A current BDR (RouterB) may find that it can not be the BDR after it running the election algorithm, it MUST set itself DROther and stop sending the BDR Address options with its IP address. It MUST send Hello messages with the value of DR is set to current DR and the value of BDR is set to the newly elected BDR. 3.3. Receiving Hello Messages When a Hello message is received, if the DR/BDR Address option carried in the message is different from the previous message. The election algorithm MUST be rerun. As a result, the associate actions should be taken according to the role changing. 3.4. Working with the DRLB function The DRLB function defined in [RFC8775] can work with the mechanism defined in this document. The routers advertise the DR/BDR Address options and the DRLB-Cap Hello Option defined in [RFC8775]. After running the election algorithm defined in section 3.1, the elected DR advertises the DRLB-List Hello Option to carry the GDR candidates. When the current DR is unavailable, the BDR MUST send the DRLB-List Hello Option to carry the GDR candidates. The BDR starts forwarding Zhang, et al. Expires April 3, 2021 [Page 6] Internet-Draft PIM DR Improvement September 2020 the multicast flows, but there may be duplicated flows because the DR may not be the same as the GDR. 4. PIM Hello message format Two new PIM Hello Options are defined, which conform to the format defined in [RFC7761]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Hello Option Format 4.1. DR Address Option format o OptionType : The value is 37. o OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6. o OptionValue: IP address of the DR. If the IP version of the PIM message is IPv4, the value MUST be the IPv4 address of the DR. If the IP version of the PIM message is IPv6, the value MUST be the link-local address of the DR. 4.2. BDR Address Option format o OptionType : The value is 38. o OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6. o OptionValue: IP address of the BDR. If the IP version of the PIM message is IPv4, the value MUST be the IPv4 address of the BDR. If the IP version of the PIM message is IPv6, the value MUST be the link-local address of the BDR. 4.3. Error handling The DR and BDR addresses MUST be the same with the addresses which are used to send PIM Hello message. Unknown options MUST be ignored, which conforms to the format defined in section 4.9.2 in [RFC7761], and the options MUST be ignored that include unexpected values. For example, when a DR Address option Zhang, et al. Expires April 3, 2021 [Page 7] Internet-Draft PIM DR Improvement September 2020 with IPv4 address is received while the interface supports IPv6 only, the option MUST be ignored. 5. Compatibility If at least one router on a LAN doesn't send a Hello message, including the DR Address Options, then the specification in this document MUST NOT be used. Any router using the DR and BDR Address Options MUST set the corresponding OptionValues to 0x0. This action results in all routers using the DR election function defined in [RFC7761] or [I-D.mankamana-pim-bdr]. This draft allows the DR election to be sticky by not unnecessarily changing the DR when routers go down or come up. That is done by introducing new PIM Hello options. Both this draft and the draft [I-D.mankamana-pim-bdr], introduce a backup DR. The latter draft does this without introducing new options but does not consider the sticky behavior. A router that does not support this specification ignores unknown options According to section 4.9.2 defined in [RFC7761]. So the new extension defined in this draft will not influence the stability of neighbors. The DR election mechanism selection would depend on deployment scenario. 6. Security Considerations [RFC7761] describes the security concerns related to PIM-SM, the potential BFD session attack can be used as the security function in section 9 [RFC5880] mentioned. If an attacker wants to hijack the DR role, it may send PIM Hello message with the altered DR/BDR Address options. The attacker sends the Hello message with the DR Address option set to itself as DR except for the highest priority or IP address. Or the attacker sends the Hello message without the DR/BDR Address option except for the highest priority or IP address. If an attacker wants to take the BDR role, it simply sends PIM Hello message with BDR Address options except for the higher priority or IP address than the current BDR. Some security measures, such as IP address filtering for the election, may be taken to avoid these situations. For example, the Hello message received from an unknown neighbor is ignored by the election process. Zhang, et al. Expires April 3, 2021 [Page 8] Internet-Draft PIM DR Improvement September 2020 7. IANA Considerations IANA is requested to allocate two new code points from the "PIM-Hello Options" registry. +------+--------------------+---------------+ | Type | Description | Reference | +------+--------------------+---------------+ | 37 | DR Address Option | This Document | | 38 | BDR Address Option | This Document | +------+--------------------+---------------+ Table 1 8. Acknowledgements The authors would like to thank Alvaro Retana, Greg Mirsky, Jake Holland, Stig Venaas for their valuable comments and suggestions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Zhang, et al. Expires April 3, 2021 [Page 9] Internet-Draft PIM DR Improvement September 2020 [RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., and A. Green, "PIM Designated Router Load Balancing", RFC 8775, DOI 10.17487/RFC8775, April 2020, . 9.2. Informative References [I-D.ietf-pim-bfd-p2mp-use-case] Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Protocol Independent Multicast - Sparse Mode (PIM-SM) Use Case", draft-ietf-pim-bfd-p2mp-use-case-04 (work in progress), July 2020. [I-D.mankamana-pim-bdr] mishra, m., Goh, J., and G. Mishra, "PIM Backup Designated Router Procedure", draft-mankamana-pim-bdr-04 (work in progress), April 2020. Authors' Addresses Zheng(Sandy) Zhang ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: zhang.zheng@zte.com.cn Fangwei Hu Individual Shanghai China Email: hufwei@gmail.com Benchong Xu ZTE Corporation No. 68 Zijinghua Road, Yuhuatai Distinct Nanjing China Email: xu.benchong@zte.com.cn Zhang, et al. Expires April 3, 2021 [Page 10] Internet-Draft PIM DR Improvement September 2020 Mankamana Mishra Cisco Systems 821 Alder Drive, MILPITAS, CALIFORNIA 95035 UNITED STATES Email: mankamis@cisco.com Zhang, et al. Expires April 3, 2021 [Page 11]