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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[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, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc8775>.
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]