Internet-Draft Multicast Redundant Ingress Router Failo April 2022
Shepherd, et al. Expires 9 October 2022 [Page]
Workgroup:
MBONED WG
Internet-Draft:
draft-ietf-mboned-redundant-ingress-failover-00
Published:
Intended Status:
Informational
Expires:
Authors:
G. Shepherd
Cisco Systems, Inc.
Z. Zhang, Ed.
ZTE Corporation
Y. Liu
China Mobile
Y. Cheng
China Unicom

Multicast Redundant Ingress Router Failover

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 9 October 2022.

Table of Contents

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. The 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 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

                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.

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.

3.2. Failure detection

In order to achieve the successful IR switchover, some methods should be used for monitoring the IR node failure or the path failure between IR and ERs, and the IR can do the switching once the failure occurs. BFD or PING methods can be used for it.

BFD [RFC5880] can be used in all the deployments. Multipoint BFD [RFC8562] can also be used for the failure detection between IR and ERs. BFD for MPLS LSPs [RFC5884] can be used in P2MP TE tunnel or MLDP deployments. BIER BFD [I-D.ietf-bier-bfd] can be used in BIER deployment.

IPv4 PING [RFC0792] and IPv6 PING [RFC4443] can also be used in all the deployments. LSP-Ping [RFC8029] can be used for P2MP TE tunnel or MLDP deployments. BIER PING [I-D.ietf-bier-ping] can be used in BIER deployment.

BIR and ER can detect the SIR node and path failure easily by the BFD and PING methods. If the monitoring is between SIR and ER, how to trigger the switchover quickly is challenging when BIR needs to start forwarding the multicast flow. If the monitoring is between BIR and SIR, the path between BIR and SIR may fail, but the path is not the way from SIR to ERs, BIR may trigger the switchover by mistake, in this case unnecessary duplicate flow occurs. In this case, the ER must support the selective receiving and can be compatible with the IR switchover mistake. In order to minimize the mistaken switchover, the reliability of SIR/BIR detection needs to be enhanced, such as using redundant reliable paths for detection, etc.

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. [RFC9026] 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.

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.

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.

In some deployments, the SIR and BIR may in charge of different multicast flow. For a specific multicast flow, the SIR may be IR1, for another multicast flow, the SIR may be IR2. So the two IRs can share the multicast forwarding load. And another possible deployment is, the two IRs can in charge of different ERs for one multicast flow. For example, IR1 sends the multicast flow to some of the ERs, and IR2 send the multicast flow to the other ERs. In case IR1 detects there is something wrong between IR1 and the ERs, IR1 may notify IR2 to take over the responsibility of forwarding the multicast flow to these ERs that receive flow from IR1 before.

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.

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.

Table 1
role Cold Mode Warm Mode Hot Mode
IR Forwarding flow according to the request from ER. Takes the role of SIR or BIR, BIR must not forward flow to ER until SIR failovers. Need not to know the roles of SIR or BIR, just forwarding flow according to the request from ER.
ER Must select an IR as SIR to signal the request, signal to the BIR to request the flow when SIR failovers. Does not select the SIR or BIR, just signal to both of them. Signal to both of SIR and BIR. Discards the duplicate flow from BIR until SIR failover.
Intermediate Router Knows nothing about SIR or BIR. No duplicated flow is forwarded. Knows nothing about SIR or BIR. No duplicated flow is forwarded. Knows nothing about SIR or BIR. Duplicated flow is forwarded.

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.

5. IANA Considerations

This document does not have any requests for IANA allocation.

6. Security Considerations

This document adds no new security considerations.

7. References

7.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, , <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, , <https://www.rfc-editor.org/info/rfc6388>.
[RFC7450]
Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8279>.

7.2. Informative References

[I-D.ietf-bier-bfd]
Xiong, Q., Mirsky, G., Hu, F., and C. Liu, "BIER BFD", Work in Progress, Internet-Draft, draft-ietf-bier-bfd-01, , <https://www.ietf.org/archive/id/draft-ietf-bier-bfd-01.txt>.
[I-D.ietf-bier-ping]
Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, Internet-Draft, draft-ietf-bier-ping-07, , <https://www.ietf.org/archive/id/draft-ietf-bier-ping-07.txt>.
[I-D.ietf-pim-sr-p2mp-policy]
(editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Zhang, "Segment Routing Point-to-Multipoint Policy", Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-policy-04, , <https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-04.txt>.
[RFC0792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, , <https://www.rfc-editor.org/info/rfc792>.
[RFC4443]
Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, , <https://www.rfc-editor.org/info/rfc4443>.
[RFC5880]
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, , <https://www.rfc-editor.org/info/rfc5880>.
[RFC5884]
Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, , <https://www.rfc-editor.org/info/rfc5884>.
[RFC8029]
Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, , <https://www.rfc-editor.org/info/rfc8029>.
[RFC8562]
Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, , <https://www.rfc-editor.org/info/rfc8562>.
[RFC9026]
Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., "Multicast VPN Fast Upstream Failover", RFC 9026, DOI 10.17487/RFC9026, , <https://www.rfc-editor.org/info/rfc9026>.

Authors' Addresses

Greg Shepherd
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose,
United States of America
Zheng Zhang (editor)
ZTE Corporation
Nanjing
China
Yisong Liu
China Mobile
Beijing
Ying Cheng
China Unicom
Beijing
China

mirror server hosted at Truenetwork, Russian Federation.