MBONED WG G. Shepherd
Internet-Draft Cisco Systems, Inc.
Intended status: Informational Z. Zhang, Ed.
Expires: April 28, 2021 ZTE Corporation
Y. Liu
China Mobile
Y. Cheng
China Unicom
October 25, 2020
Multicast Redundant Ingress Router Failover
draft-szcl-mboned-redundant-ingress-failover-00
Abstract
This document discusses the redundant ingress router failover in
multicast domain.
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 28, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Shepherd, et al. Expires April 28, 2021 [Page 1]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multicast Redundant Ingress Router Failover . . . . . . . . . 3
3.1. Swichover . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Stand-by Modes . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Cold . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Warm . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Hot . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The multicast redundant ingress router failover is an important issue
in multicast deployment. This document tries to do a research on it
in the multicast domain. The Multicast Domain is a domain which is
used to forward multicast flow according to specific multicast
technologies, such as PIM ([RFC7761]), BIER ([RFC8279]), P2MP TE
tunnel ([RFC4875]), MLDP ([RFC6388]), etc. This domain may or may
not connect the multicast source and receiver directly.
The ingress router is close to the multicast source. The ingress
router may connect the multicast source directly, or there may be
multiple hops between the ingress router and the multicast source.
In the multicast domain, the ingress router is the most adjacent
router to the multicast source. It's also called the first-hop
router in PIM, or BFIR in BIER, or Ingress LSR in P2MP TE tunnel or
MLDP.
The failover function between the multicast source and the ingress
router can be achieved by many ways, and it is not included in this
document.
The egress router is close to the multicast receiver. The egress
router may connect the multicast receiver directly, or there may be
multiple hops between the egress router and the multicast receiver.
In the multicast domain, the egress router is the most adjacent
router to the multicast receiver. It's also called the last-hop
Shepherd, et al. Expires April 28, 2021 [Page 2]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
router in PIM, or BFER in BIER, or Egress LSR in P2MP TE tunnel or
MLDP.
There may be some other function deployed in the multicast domain,
such as static configuration, or AMT ([RFC7450]), or SR P2MP Policy
([I-D.ietf-pim-sr-p2mp-policy]).
This document doesn't discuss the details of these technologies.
This document discusses the general redundant ingress router failover
ways in the multicast domain.
2. Terminology
The following abbreviations are used in this document:
IR: the ingress router which is the most close to the multicast
source in the multicast domain.
ER: the egress router which is the most close to the multicast
receiver in the multicast domain.
SIR: The IR that is in charge of sending the multicast flow, or the
flow from the IR is accepted by the ERs, the IR is called as the
Selected-IR, that is SIR in abbreviation.
BIR: The IR that is not in charge of sending the multicast flow, or
the flow from the IR is not accepted by the ERs, but the IR replaces
the role of SIR once SIR fails. The IR is called as the Backup-IR,
that is BIR in abbreviation.
3. Multicast Redundant Ingress Router Failover
Shepherd, et al. Expires April 28, 2021 [Page 3]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
source
...
+-----+ +-----+
+----------+ IR1 +------+ IR2 +---------+
|multicast +-----+ +-----+ |
|domain ... |
| |
| +-----+ +-----+ |
| | Rm | | Rn | |
| ++---++ +--+--+ |
| | | | |
| +-----+ +---+ +-----+ |
| | | | |
| +-v---+ +--v--+ +--v--+ |
+---+ ER1 +------+ ER2 +------+ ER3 +---+
+-----+ +-----+ +-----+
... ... ...
receiver receiver receiver
Figure 1
Usually, a multicast source connects directly, or across multiple
hops to two IRs to avoid single node failure. As shown in figure 1,
there are two IRs close to a multicast source. The two IRs are UMH
(Upstream Multicast Hop) candidates for the ERs.
The two IRs gets multicast flow from the mutlcast source, how to
forward the multicast flow to ERs is different according to the
technologies deployed in the multicast domain. For example, for PIM
which is used in this domain, two PIM Trees that rooted on the two
IRs may be built separately.
The IRs works with the other router, such as the ER, in the multicast
domain to minimize the multicast flow packet loss during the IR
swichover.
3.1. Swichover
There may be some failures occurs in the domain, such as link
failure, node failure, if the failed link or node is on the multicast
flow forwarding path, there may be multicast flow packet loss.
If there are multiple paths from the IR to the ERs, there is no need
to switch IR when some nodes or links fail.
o When PIM is used in the domain as multicast forwarding protocol,
the forwarding tree for (S, G) or (*, G) is built in advance.
When a node or link in the forwarding tree fails, the tree is
rebuilt partially.
Shepherd, et al. Expires April 28, 2021 [Page 4]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
o When BIER is used in the domain as multicast forwarding protocol,
there is no need to rebuilt forwarding tree in case of node or
link failure, the BIER forwarding recovers along with the IGP
routing convergence.
o When P2MP TE tunnel or MLDP is used in the domain as multicast
forwarding protocol, the forwarding LSP is built in advance. When
a node or link in the LSP fails, the LSP may be rebuilt partially.
o When static multicast tree or SR P2MP policy is used in the
domain, the controller needs to re-compute a new forwarding path
to bypass the failed node or link.
In some situations, there are some key nodes or links in the network.
The multicast path can not be recovered due to the key node or link
failure. The IR needs swichover.
source
...
+-----+ +-----+
+----------+ IR1 +------+ IR2 +---------+
| +--+--+ +--+--+ |
| | | |
| +--+--+ +--+--+ |
| | Rx | | Ry | |
| +-+-+-+ ++---++ |
| | | | | |
| | +-----------+ | |
| | | | | |
| | +---------+ | | |
| | | | | |
| +-v-v-+ +--v-v+ |
| | Rm | | Rn | |
| ++---++ +--+--+ |
| | | | |
| +-----+ +---+ +-----+ |
| | | | |
| +-v---+ +--v--+ +--v--+ |
+---+ ER1 +------+ ER2 +------+ ER3 +---+
+-----+ +-----+ +-----+
... ... ...
receiver receiver receiver
Figure 2
For example in figure 2, there is only one path in the network
partially. The IR1, Rx are key nodes in the domain, when IR1 or Rx
fails, there is no any other path between the IR1 and the ERs.
Shepherd, et al. Expires April 28, 2021 [Page 5]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
o When PIM is used in the domain, Rm and Rn may choose Ry as the
upstream node to send Join message to build a new tree which
rooted with IR2.
o When BIER is used in the domain, IR2 should in charge of the
forwarding role to forward the flow to the ERs.
o When P2MP TE tunnel or MLDP is used in the domain, the LSP may be
rebuilt partially, or another LSP can be built in advance, and
replace the used LSP when the used LSP does not work.
o When static multicast tree or SR P2MP policy is used in the
domain, the controller should let the IR2 to forward multicast
flow to the ERs.
4. Stand-by Modes
In case there are more than one IRs can be the UMH, and there is no
other path from an IR to ERs in case of the IR fails, the IR needs to
be switched.
Usually there are three types of stand-by modes in multicast IR
protection. [I-D.ietf-bess-mvpn-fast-failover] has some description
on it. This document discusses the detail of the three modes here.
The ER may send request to upstream router or IR when it finds the
node or path failure. The request from the ER may be the PIM tree
building, or BIER overlay protocol signaling, or LSP building, or
some other ways to let IR knows whether forwards the multicast flow.
4.1. Cold
In cold standby mode, the ER selects an SIR, for example IR1 in
figure 1, as the SIR and signals to it to get the multicast flow.
When the ER finds that the SIR is down, or the ER finds that it
cannot receive flow from IR1, the ER signals to IR2 to get the
multicast flow.
o For IR, the IRs, include SIR and BIR, just do the regular
operation of forwarding flow according to the request from the ER.
o For ER, the ER must select an IR as the SIR and signal to it.
When the SIR fails or the path between the SIR and ER fails, the
ER must signal to the BIR to get the flow.
Shepherd, et al. Expires April 28, 2021 [Page 6]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
o For the intermediate routers, they know nothing about the role of
IR, they just do the packet forwarding. There is no duplicate
packets in the domain.
In case of the IR switchover, the ER detects the failure of SIR, and
signals to the BIR. There is packet loss during the signaling until
the ER receives the flow from the BIR.
4.2. Warm
In Warm standby mode, the ER signals to both IR1 and IR2.
In case IR1 is the SIR, IR1 forwards the flow to the ER. The BIR,
for example the IR2, must not forward the flow to the ER until the
SIR is down.
o For IR, the IR should take the role of SIR or BIR. The BIR must
not forward flow to the ER. When the SIR fails or the path
between SIR and ER fails, the BIR must start forwarding the flow
to ER. But it's hard to know the failure for BIR itself, some
methods should be taken to let the BIR to get the failure
notification.
o For ER, the ER does not select the SIR or BIR. The ER just signal
to both of them.
o For the intermediate routers, they know nothing about the role of
IR, they just do the packet forwarding. There is no duplicate
packets in the domain.
In case of the IR switchover, the BIR detects the failure of the SIR
and switch to SIR. There is packet loss during the IR switchover.
4.3. Hot
In Hot standby mode, the ER signals to both IRs.
Both IRs are sending the flow to the ER. The ER must discard the
duplicate flow from one of the IRs.
In this situation, there are no SIR or BIR. Only ER knows which IR
is the SIR.
o For IR, the IR need not to know the roles of SIR or BIR, IR just
forwarding the flow according to the request received from ER.
o For ER, the ER signal to both of the IRs to get the flow. And the
ER must discard the duplicated flow from the backup BIR. When the
Shepherd, et al. Expires April 28, 2021 [Page 7]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
SIR fails or the path between SIR and ER fails, the ER must switch
the forwarding plane to forward the flow packet comes from the
BIR. To be noted, the ERs may choose different SIR or BIR.
o For the intermediate routers, they know nothing about the role of
IR, they just do the packet forwarding. There are duplicate
packets forwarded in the domain.
In case of the IR switchover, the ER detects the failure of the SIR.
Because there are duplicate flow packets arrive on the ER, the ER
just switch to forward the flow comes from the BIR. There may be
packet loss during the switching.
4.4. Summary
The table is a brief comparison among the three modes. The 'SIR
failover' means the SIR fails or the path between SIR and ER fails.
Shepherd, et al. Expires April 28, 2021 [Page 8]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
+--------------+------------------+--------------+------------------+
| role | Cold Mode | Warm Mode | Hot Mode |
+--------------+------------------+--------------+------------------+
| IR | Forwarding flow | Takes the | Need not to know |
| | according to the | role of SIR | the roles of SIR |
| | request from ER. | or BIR, BIR | or BIR, just |
| | | MUST NOT | forwarding flow |
| | | forward flow | according to the |
| | | to ER until | request from ER. |
| | | SIR | |
| | | failovers. | |
| | | | |
| ER | Must select an | Does not | Signal to both |
| | IR as SIR to | select the | of SIR and BIR. |
| | signal the | SIR or BIR, | Discards the |
| | request, signal | just signal | duplicate flow |
| | to the BIR to | to both of | from BIR until |
| | request the flow | them. | SIR failover. |
| | when SIR | | |
| | failovers. | | |
| | | | |
| Intermediate | Knows nothing | Knows | Knows nothing |
| Router | about SIR or | nothing | about SIR or |
| | BIR. No | about SIR or | BIR. Duplicated |
| | duplicated flow | BIR. No | flow is |
| | is forwarded. | duplicated | forwarded. |
| | | flow is | |
| | | forwarded. | |
+--------------+------------------+--------------+------------------+
Table 1
The Cold stand-by mode is the easiest way to implementated, but it
takes the longest converge time.
The Hot stand-by mode takes the most less packet loss, but there is
duplicated packet forwarding in the domain, more bandwidth is
occupied.
The Warm stand-by mode takes the middle packet loss and converge
time, but it's hard for BIR to know the failure between SIR and ERs.
So it's hard to say which mode is the best way for multicast
redundant ingress router failover, the network administrator should
select the most suitable mode according to the network deployment.
Shepherd, et al. Expires April 28, 2021 [Page 9]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
5. Security Considerations
This document adds no new security considerations.
6. References
6.1. Normative References
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
[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>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
6.2. Informative References
[I-D.ietf-bess-mvpn-fast-failover]
Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast
Upstream Failover", draft-ietf-bess-mvpn-fast-failover-11
(work in progress), October 2020.
Shepherd, et al. Expires April 28, 2021 [Page 10]
Internet-Draft Multicast Redundant Ingress Router Failover October 2020
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-ietf-pim-sr-p2mp-policy-00 (work in progress), July
2020.
Authors' Addresses
Greg Shepherd
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose
US
Email: gjshep@gmail.com
Zheng Zhang (editor)
ZTE Corporation
Nanjing
China
Email: zhang.zheng@zte.com.cn
Yisong Liu
China Mobile
Email: liuyisong@chinamobile.com
Ying Cheng
China Unicom
Beijing
China
Email: chengying10@chinaunicom.cn
Shepherd, et al. Expires April 28, 2021 [Page 11]