IP Library › Granted Patent US 12,732,450
Granted Patent B2
US 12,732,450 · App. 17/811,670 · Granted Sep 8, 2026

Designating a primary multicast flow and a backup multicast flow for multicast traffic

Inventors: Vinod Kumar Nagaraj (Cupertino, CA); Vikram Nagarajan (Bangalore, IN); Zhaohui Zhang (Westford, MA)
Assignee: Hewlett Packard Enterprise Development LP
H04L45/16H04L45/22H04L45/76
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,732,450
App. No.
17/811,670
Granted
Sep 8, 2026
Kind
B2
Abstract

A network device may receive a first redundant multicast flow indication from a first network device, and may receive a second redundant multicast flow indication from a second network device. The device may designate a primary multicast flow based on the first redundant multicast flow indication, and may designate a backup multicast flow based on the second redundant multicast flow indication. The device may accept the primary multicast flow and may discard the backup multicast flow.

Claims (59)

1 . A method, comprising:

receiving, by a network device, a first redundant multicast flow indication from a first network device and a second redundant multicast flow indication from a second network device,

wherein the first redundant multicast flow indication includes a first virtual extensible local area network (VXLAN) network identifier (VNI) or a first source VXLAN tunnel endpoint (VTEP) identifier and the second redundant multicast flow indication includes a second VNI or a second source VTEP identifier, and

wherein one or more of the first redundant multicast flow indication and the second redundant multicast flow indication is a Type 10 selective-provider multicast service interface route identifier;

designating, by the network device, a primary multicast flow based on the first redundant multicast flow indication;

designating, by the network device, a backup multicast flow based on the second redundant multicast flow indication;

accepting, by the network device, the primary multicast flow; and

monitoring, by the network device, a rate of the primary multicast flow.

2 . The method of claim 1 , further comprising: receiving a report from a host device; and

identifying the first redundant multicast flow indication and the second redundant multicast flow indication based on receiving the report.

3 . The method of claim 1 , further comprising: continuing to accept the primary multicast flow based on the rate of the primary multicast flow satisfying a rate threshold.

4 . The method of claim 3 , further comprising: accepting the backup multicast flow based on the rate of the primary multicast flow failing to satisfy the rate threshold.

5 . The method of claim 4 , wherein accepting the backup multicast flow comprises:

accepting multicast traffic with an outer source address that matches an address of the second network device forwarding the backup multicast flow.

6 . The method of claim 1 , wherein accepting the primary multicast flow comprises:

accepting multicast traffic with an outer source address that matches an address of the first network device forwarding the primary multicast flow.

7 . The method of claim 1 , wherein the network device is a service leaf network device or a data center interconnect gateway.

8 . A network device, comprising:

one or more memories; and

one or more processors to:

receive a first redundant multicast flow indication from a first network device and a second redundant multicast flow indication from a second network device,

wherein the first redundant multicast flow indication includes a first virtual extensible local area network (VXLAN) network identifier (VNI) or a first source VXLAN tunnel endpoint (VTEP) identifier and the second redundant multicast flow indication includes a second VNI or a second source VTEP identifier, and

wherein one or more of the first redundant multicast flow indication and the second redundant multicast flow indication is a Type 10 selective-provider multicast service interface (S-PMSI) route identifier;

designate a primary multicast flow based on the first redundant multicast flow indication;

designate a backup multicast flow based on the second redundant multicast flow indication;

accept the primary multicast flow; and

monitor a rate of the primary multicast flow.

9 . The network device of claim 8 , wherein the first network device is connected to a source of the primary multicast flow via a first protocol independent multicast (PIM) gateway and the second network device is connected to the source of the backup multicast flow via a second PIM gateway.

10 . The network device of claim 8 , wherein the first network device and the second network device communicate with the network device via an Ethernet virtual private network.

11 . The network device of claim 8 , wherein the one or more processors, to receive the first redundant multicast flow indication from the first network device and the second redundant multicast flow indication from the second network device, are to:

receive the first redundant multicast flow indication from a first advertisement generated by the first network device; and

receive the second redundant multicast flow indication from a second advertisement generated by the second network device.

12 . The network device of claim 8 , wherein the one or more processors, are further to:

broadcast a Type 6 selective multicast Ethernet tag (SMET) route based on receiving an Internet group management protocol (IGMP) report; and

wherein the one or more processors, to receive the first redundant multicast flow indication from the first network device and the second redundant multicast flow indication from a second network device, are to:

identify the first redundant multicast flow indication and the second redundant multicast flow indication based on receiving the IGMP report.

13 . The network device of claim 8 , wherein the one or more processors are further to:

accept the backup multicast flow based on the rate of the primary multicast flow failing to satisfy a rate threshold.

14 . A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising:

one or more instructions that, when executed by one or more processors of a network device, cause the network device to:

receive a first redundant multicast flow indication from a first network device and a second redundant multicast flow indication from a second network device,

wherein the first redundant multicast flow indication includes a first virtual extensible local area network (VXLAN) network identifier (VNI) or a first source VXLAN tunnel endpoint (VTEP) identifier and the second redundant multicast flow indication includes a second VNI or a second source VTEP identifier, and

wherein one or more of the first redundant multicast flow indication and the second redundant multicast flow indication is a Type 10 selective-provider multicast service interface route identifier;

designate a primary multicast flow based on the first redundant multicast flow indication;

designate a backup multicast flow based on the second redundant multicast flow indication;

accept the primary multicast flow; and

monitor a rate of the primary multicast flow.

15 . The non-transitory computer-readable medium of claim 14 , wherein the one or more instructions further cause the network device to:

receive a report from a host device; and

identify the first redundant multicast flow indication and the second redundant multicast flow indication based on receiving the report.

16 . The non-transitory computer-readable medium of claim 14 , wherein the one or more instructions further cause the network device to:

continue to accept the primary multicast flow based on the rate of the primary multicast flow satisfying a rate threshold.

17 . The non-transitory computer-readable medium of claim 16 , wherein the one or more instructions further cause the network device to:

accept the backup multicast flow based on the rate of the primary multicast flow failing to satisfy the rate threshold.

18 . The non-transitory computer-readable medium of claim 14 , wherein the network device is a service leaf network device or a data center interconnect gateway.

19 . The non-transitory computer-readable medium of claim 14 , wherein the one or more instructions, to accept the backup multicast flow, causes the network device to:

accept multicast traffic with an outer source address that matches an address of the second network device forwarding the backup multicast flow.

20 . The non-transitory computer-readable medium of claim 14 , wherein the one or more instructions, to accept the backup multicast flow, causes the network device to:

accept multicast traffic with an outer source address that matches an address of the first network device forwarding the primary multicast flow.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 11, 2022
From: NAGARAJ, VINOD KUMAR; NAGARAJAN, VIKRAM; ZHANG, ZHAOHUI
To: JUNIPER NETWORKS, INC.
Reel/Frame 060474/0735 →
Continuity (1)
Related Publication 20240015095A1 · Jan 11, 2024
References Cited (19)
US 9806895B1 · Kommula · 2017 [cited by examiner]
US 10103902B1 · Sampath · 2018 [cited by examiner]
US 10855520B1 · Kommula · 2020 [cited by examiner]
US 11824797B1 · Mishra · 2023 [cited by examiner]
US 20070268899A1 · Cankaya · 2007 [cited by examiner]
US 20130322291A1 · Venkataraman · 2013 [cited by examiner]
US 20160119156A1 · Drake · 2016 [cited by examiner]
US 20180069908A1 · Buchanan · 2018 [cited by examiner]
US 20190036717A1 · Kebler · 2019 [cited by examiner]
US 20200259680A1 · Thubert · 2020 [cited by examiner]
US 20200280455A1 · Mishra · 2020 [cited by examiner]
US 20210227608A1 · Zhu · 2021 [cited by examiner]
Internet Draft : Multicast Source Redundancy in EVPN Networks (Year: 2018) https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/00/. [cited by examiner]
J. Rabadan, Ed. et al. Multicast Source Redundancy in EVPN Networks draft-skr-bess-evpn-redundant-mcast-source-00.txt BESS Workgroup Internet Draft Oct. 22, 2018 (Year: 2018). [cited by examiner]
Rabadan et al., “Multicast Source Redundancy in EVPN Networks draft- ietf- bess- evpn- redundant- mcast- source- 03,” BESS Workgroup, Internet-Draft, Feb. 6, 2022, Website: https://www.ietf.org/archive/id/draft-ietf-bes… [cited by applicant]
Boutros et al., “VXLAN DCI Using EVPN,” Work in Progress, Internet-Draft, Website: https://www.ietf.org/archive/id/draft-boutros-bess-vxlan-evpn-02.txt, Oct. 21, 2016, 17 Pages. [cited by applicant]
Aggarwal et al., “BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs,” Internet Engineering Task Force (IETF), Feb. 2012, 59 Pages. [cited by applicant]
Rabadan et al., “RFC 9014: Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks,” Internet Engineering Task Force (IETF), May 2021, 24 Pages. [cited by applicant]
Extended European Search Report for Application No. EP221924376, mailed on Sep. 14, 2023, 13 pages. [cited by applicant]