Multicast WAN optimization in large branch offices with a centralized cloud-based service

Abstract

A branch gateway leader (112a, 122a, 132a, 500) of a customer site (110, 120, 130), comprising: at least one processor (804) and a memory (806, 808; 810) storing instructions that, when executed by the at least one processor, cause the branch gateway leader to perform a method comprising: Receiving one or more messages from one or more secondary branch gateways (112b, 122b, 132b, 700) of the customer site that one or more hosts (114a, 114b, 124a, 124b, 134a, 134b) at the customer site are interested in joining a multicast stream (152), the branch gateway leader and each secondary branch gateway connecting the customer site to an external network; Sending a message that the one or more hosts at the customer site are interested in joining the multicast stream to a cloud-based multicast orchestrator (142, 300) that enables multicast routes to the customer site; Receiving traffic associated with the multicast stream from a Virtual Personal Network (VPNC) client (154a, 154b), the VPNC connecting the customer site to a source of the multicast stream (150); and Forwarding the traffic associated with the multicast stream to the one or more secondary branch gateways at the customer site; where: the customer site is one of multiple customer sites in a large-scale software-defined (SD) branch facility (100) connected via a wide area network (WAN) (160); the cloud-based multicast orchestrator enables multicast routes to the SD branch facility; the WAN comprises a physical network and a virtual overlay network that builds on the physical network, and the branch gateway leader receives the traffic associated with the multicast stream from the VPNC through an overlay tunnel of the overlay virtual network.

Description

background

[0001] In computer networks, multicast (or a multicast stream) can generally refer to group communication in which data transmission is directed to a group of interested recipients (e.g., target hosts / computers) simultaneously. Multicast can be used for various purposes, such as streaming media and other network applications, disseminating information, group communication, etc.

[0002] Related to multicast is the concept of a multicast group. A multicast group typically has an IP address (i.e., the IP address of the multicast group) that identifies the multicast group. Members of the multicast group can join or leave the multicast group without the other members being aware of it. Traffic sent by one member of a multicast group can be received by all other members of the multicast group (e.g., the recipients). Traditionally, multicast traffic is forwarded to the members of the multicast group using IP routing protocols such as Protocol Independent Multicast (PIM).

[0003] WO 2017 / 144945 A1 relates to the field of communication network interoperability and, in particular, to multi-area configurations supporting multicast for Source Packet in Routing (SPRING) networks.

[0004] EP 3 799 371 A1 relates generally to computer networks and, in particular, to multicasting for distributed applications.

[0005] US 2015 / 0146603 A1 relates to communication in an adaptive multicast network.

[0006] The present invention is defined by independent claims 1, 8 and 15. Embodiments are subject of the respective dependent claims. Brief description of the drawings

[0007] The present disclosure will be described in detail in accordance with one or more various embodiments with reference to the following figures. The figures are for illustrative purposes only and represent merely typical or exemplary embodiments. Fig. 1 shows an example of a large-scale software-defined branch deployment in accordance with various examples of the presently disclosed technology. Fig. 2 is an example flowchart illustrating example operations that may be performed by a cloud-based multicast orchestrator to orchestrate multicast traffic within a large-scale software-defined branch office deployment, in accordance with various examples. Fig. 3 is an example system diagram showing components of the cloud-based multicast orchestrator of Fig. 2 according to various examples. Fig. 4 is an example flowchart illustrating example operations that may be performed by a branch gateway leader to reduce WAN bandwidth consumption for multicast transmission in large-scale software-defined branch directions according to various examples. Fig. Figure 5 is a sample system diagram showing components of the Branch Gateway Leader of Fig. 4 in accordance with various examples. Fig. 6 is an example flowchart illustrating example operations that may be performed by a secondary branch gateway to reduce WAN bandwidth consumption for multicast transmission in large-scale software-defined branch office deployments according to various examples. Fig. Figure 7 is a sample system diagram showing components of the secondary branch gateway of Fig. 6 in accordance with various examples. Fig. 8 is an example of a computer component that may be used to implement various features of the embodiments described in the present disclosure.

[0008] The figures are not exhaustive and do not limit the present disclosure to the precise form disclosed. Detailed description

[0009] As described above, multicast can refer to group communication in which data transmission (i.e., multicast traffic) is directed to a group of interested recipients (e.g., destination hosts / computers) simultaneously.

[0010] One environment for multicast is large-scale software-defined branch office deployments. In large software-defined branch offices, software-defined WAN (SD-WAN) technology can be used to centralize the management of an organization's wide area network (WAN) across multiple physical branch offices. SD-WAN technologies (such as Aruba SD-WAN from HPE) are typically implemented as a cloud-based management solution and rely on virtualization, overlay networks, on-premises SD-WAN devices, and software platforms to better manage network traffic, among other things.

[0011] However, existing multicast implementations for large-scale software-defined branch deployments do not yet leverage the centralized management capabilities of SD-WAN technologies. Specifically, these implementations rely on variations of the same traditional, decentralized approach—Protocol-Independent Multicast (PIM)—that has been widely used for internet-based multicast for years. While PIM-based approaches are easy to implement, they do not optimize bandwidth consumption across the WAN of a large-scale software-defined branch deployment.Specifically, multicast traffic is transmitted—across the WAN—from the multicast source to a specific branch office via all of the branch office's branch gateways (gateways here can refer to network devices that carry traffic between a branch office's local area network (LAN) and the larger corporate WAN—branch gateways are typically present multiple times within a given branch office to enable load balancing and redundancy). Furthermore, because there is no central entity coordinating or orchestrating routes between the multicast source and the various branch offices, PIM-based solutions can be difficult to monitor and troubleshoot. Furthermore, the lack of centralized management requires large amounts of multicast-related routing information to be sent to a multitude of network devices involved in the multicast transmission (e.g.,Source VPNs, routers, gateways, etc.). Accordingly, PIM's decentralized and somewhat brute-force approach (sometimes referred to as "flood and prune") can consume large and unnecessary amounts of WAN bandwidth. This is especially true for large software-defined branch offices that include multiple (and sometimes many) gateways per branch.

[0012] With this in mind, examples of the technology presented here leverage the centralized management capabilities of SD-WAN technologies to provide a new approach to multicast implementation that reduces WAN bandwidth consumption for large-scale software-defined branch deployments. Specifically, a cloud-based multicast orchestrator can be implemented as part of an SD-WAN package. This cloud-based multicast orchestrator can orchestrate routes for multicast traffic between a multicast source (typically a data center) and the various branches of the large-scale software-defined branch deployment. As described below, this cloud-based multicast orchestrator can orchestrate / calculate routes for multicast traffic that reduce WAN bandwidth consumption.

[0013] In addition to the cloud-based multicast orchestrator, examples of the technology presented here feature a gateway hierarchy designed to further reduce WAN bandwidth consumption. Specifically, a gateway at a given branch office is designated as the "leader" for a given multicast stream (load balancing can be achieved by assigning different "leaders" for different multicast streams / groups within the branch office). The other gateways at that branch office are referred to as "secondary gateways" for that multicast stream. Accordingly, only the leading gateway (a) communicates with the cloud-based multicast orchestrator and (b) receives the multicast traffic associated with that multicast stream from the multicast source. This architecture can significantly reduce WAN bandwidth consumption.For example, if the given branch office has four gateways and at least one host / user interested in the given multicast stream, existing technologies would replicate the multicast stream to the given branch office via four routes (with each route terminating at one of the four gateways). In contrast, examples of the technology presented here would leverage the cloud-based multicast orchestrator to orchestrate a single route from the multicast source to the single leading gateway. Regardless of any additional bandwidth savings / optimizations determined by the cloud-based multicast orchestrator in calculating this route, simply reducing the number of routes for multicast traffic from four to one saves a tremendous amount of WAN bandwidth.

[0014] As described in more detail below, examples can also leverage existing SD-WAN services (e.g., Container-as-a-Service offerings, route calculation engines, etc.) to enhance the multicast orchestration mentioned above. For example, CaaS-type services, which are often included in an SD-WAN platform, can be used to manage gateway clusters at each branch office of a large-scale software-defined branch deployment. Similarly, a CaaS can be deployed to manage VPNC clusters at the multicast source. These VPNCs can serve as nodes at the multicast source from which routes to the gateway leaders are orchestrated. Accordingly, the CaaS can communicate important information about multicast routes to its neighbor in the SD-WAN platform—the multicast orchestrator. The CaaS can also perform assignments (e.g.,Gateway leader assignments, assignment of VPNCs to multicast streams) that facilitate the architectures described here.

[0015] Fig. 1 shows an example of a large-scale software-defined branch deployment in accordance with various examples of the disclosed technology. The large-scale software-defined branch deployment 100 includes three branch offices / customer sites (branch offices 110, 120, and 130), an SD-WAN 140, and a multicast source 150. Traffic may be transmitted between the branch offices, the SD-WAN 140, and the multicast source 150 over a wide area network (WAN) 160.

[0016] Multicast Source 150: Multicast source 150 can be any source for a multicast stream. In common examples, multicast source 150 would be a data center. As shown in the example figure, multicast stream 152 is located behind two virtual private network (VPNC) clients: VPNCs 154a and 154b.

[0017] Multicast Stream 152: A multicast stream 152 can be any data transmission (e.g., streaming media, information dissemination, etc.) directed to a group of interested recipients (e.g., hosts) simultaneously. A multicast stream can be associated with a multicast group. A multicast group can include as members (a) the source of the multicast and (b) the recipients of the multicast stream. As shown, multicast stream 152 is associated with multicast group 224.0.0.010. Where "224.0.0.010" can be an IP address for multicast group 224.0.0.010. Multicast group 224.0.0.010 can include various members that receive the traffic associated with multicast stream 152. As described below, these group members / recipients can be hosts located at branches 110-130.

[0018] In the example of Fig. 1, only one multicast stream (i.e., multicast stream 152) is illustrated in multicast source 150. However, in other examples, multicast source 150 may include any number of multicast streams. Similarly, in various examples, a large-scale software-defined branch device 100 may include any number of multicast sources.

[0019] VPNCs 154a and 154b: A given multicast stream may be associated with a VPNC. In general, a VPNC may refer to a hardware or software application used to connect virtual private networks (VPNs). As illustrated, the multicast source 150 includes two VPNCs: 154a and 154b. Together, these VPNCs may form a VPNC cluster. As described in more detail below, a Containers-as-a-Service (CaaS) application residing in the SD-WAN 140 may manage this VPNC cluster. Management may include tasks such as configuring the VPNCs, determining which VPNC is associated with a particular multicast stream, etc.

[0020] As illustrated, multicast stream 152 is associated with VPNC 154a. Accordingly, VPNC 154a may be used to transmit multicast traffic associated with multicast stream 152 to one or more of branches 110-130 (as orchestrated by overlay multicast orchestrator 142).

[0021] SD-WAN 140: SD-WAN 140 may be a cloud-based SD-WAN technology platform (e.g., Aruba SD-WAN from HPE) that includes a centralized service capable of orchestrating multicast-related traffic within a given WAN (e.g., WAN 160). In certain examples, SD-WAN 140 may include additional centralized network management services.

[0022] Accordingly, various subservices can exist within SD-WAN 140. As shown in the figure, SD-WAN 140 includes the overlay multicast orchestrator 142 and Containers-as-a-Service (CaaS) 144.

[0023] Overlay Multicast Orchestrator 142: Overlay Multicast Orchestrator 142 is a central management unit that manages the routes for multicast traffic between multicast source 150 and branch sites 110-130. To perform this task, overlay multicast orchestrator 142 should be aware of aspects of the network topology / configuration as well as the needs of the hosts on the network. Among other things, overlay multicast orchestrator 142 may know (1) which branch sites are interested in a given multicast stream, (2) which branch gateways among the branch sites interested in the given multicast stream have been designated as branch gateway leaders for the given multicast stream, and (3) which VPNC and / or multicast source site is associated with the given multicast stream.Based on this information, the overlay multicast orchestrator 142 can then orchestrate routes between a suitable VPNC and the leading branch gateways to deliver the multicast traffic to interested hosts. As a central management entity within the SD-WAN 140, the overlay multicast orchestrator 142 can collect this information and make these decisions in a manner that reduces WAN bandwidth consumption. In other words, the centralized decision-making within the overlay multicast orchestrator 142 significantly reduces the number of communications / decisions required to transmit multicast traffic in a large-scale software-defined branch deployment. As described above, the decentralized approach of existing technologies would require much of the above-mentioned information to be shared between the various nodes (e.g.,routers, branch gateways, VPNCs) of a network tasked with transmitting multicast traffic.

[0024] So how can the overlay multicast orchestrator 142 obtain all this information? As described further below, the overlay multicast orchestrator 142 can obtain certain network configuration / topology information from CaaS 144 and information about the network's host requirements from the designated branch gateway leaders.

[0025] CaaS 144: CaaS 144, another centralized management service located in SD-WAN 140, can manage the various "containers / clusters" of a large-scale software-defined branch facility 200. Container-as-a-Service (CaaS) can refer to a cloud-based service that provides organizations with a way to manage their virtualized applications, clusters, and containers. A CaaS can include a container orchestration engine that operates and manages the infrastructure between an organization's clusters. As described above, CaaS 144 can manage the VPNC cluster containing VPNCs 154a and 154b. As part of its management responsibilities, CaaS 144 can determine (or at least know) which VPNC is associated with a particular multicast stream. Accordingly, CaaS 144 can pass this information to the overlay multicast orchestrator 142.

[0026] CaaS 144 may also manage clusters associated with branch gateways, which may be referred to as BG clusters. Within a given BG cluster, there is a leader. As described in more detail below, only the leader of a given BG cluster (a) sends requests to join or leave a multicast group to the overlay multicast orchestrator 142 and (b) receives multicast traffic from any of the VPNCs located in the multicast stream source 150. In certain examples, CaaS 144 may determine (or at least know) which branch gateway of a given BG cluster is the leader for a given multicast stream / group. In various examples, CaaS 144 may balance the loads by assigning different leaders for different multicast streams within the BG cluster—i.e., one leader for multicast stream 152, another leader for another multicast stream, etc.CaaS 144 can also manage the configuration of the branch gateways of a given BG cluster to ensure that each branch gateway knows which branch gateway is the leader for a given multicast stream. CaaS 144 can communicate all of this information to the overlay multicast orchestrator 142 as needed.

[0027] It's worth noting that CaaS-like services are often included within an SD-WAN service, such as SD-WAN 140. Why is this important? By leveraging existing cloud-based service infrastructure and capabilities, examples of the technology presented here can enhance a multicast orchestration service without consuming significant additional WAN bandwidth, cloud resources, etc.

[0028] Overlay Multicast Orchestrator 142 (Continued): As described above, the overlay multicast orchestrator 142 may obtain information from CaaS 144 about (a) which VPNC and / or multicast source location is associated with a particular multicast stream and (b) which branch gateways have been designated as leaders for the particular multicast stream. However, what is still missing is information about which branches are interested in the given multicast stream. As described above, the overlay multicast orchestrator 142 may obtain this information from the branch gateway leaders for the given multicast stream. In particular, the overlay multicast orchestrator 142 may receive "join request" messages from the branch gateway leaders.

[0029] As described above, each branch office has a designated branch gateway leader for a specific multicast stream. For multicast stream 152, branch gateways 112a, 122a, and 132a are the designated branch gateway leaders for branches 110, 120, and 130, respectively. Through mechanisms described in more detail below, these branch gateway leaders can receive join requests from hosts or other branch gateways in their branch. When a branch gateway leader receives at least one join request for multicast stream 152, the branch gateway leader sends a join request message to the overlay multicast orchestrator 142. The join request message can be sent to the overlay multicast orchestrator 142 via various protocols such as WebSocket, grpc, etc.

[0030] The overlay multicast orchestrator 142 can now know (1) which branch sites are interested in a particular multicast stream, (2) which branch gateways among the branch sites interested in the multicast stream have been designated as leaders for the given multicast stream, and (3) which VPNC and / or multicast source site is associated with the given multicast stream. Accordingly, the overlay multicast orchestrator 142 can orchestrate routes between the corresponding VPNCs and the branch gateways for the given multicast stream. As an illustrative example, if the hosts at branch offices 110, 120, and 130 are all interested in multicast stream 152, overlay multicast orchestrator 142 may orchestrate a route between VPNC 154a and branch gateway 112a, a route between VPNC 154a and branch gateway 122a, and a route between VPNC 154a and branch gateway 132a.

[0031] In some examples, a route calculation engine in the overlay multicast orchestrator 142 may calculate routes for multicast traffic based on the aforementioned source information (i.e., which VPNC is associated with a particular multicast stream) and receiver information (which branch gateways are designated as leaders for the given multicast stream). In some of these examples, the route calculation engine may learn to calculate optimal routes to reduce bandwidth consumption for the WAN 160. For example, the overlay multicast orchestrator 142 may employ artificial intelligence (AI) or machine learning to determine overlay tunnels for multicast traffic between VPNCs and branch gateways based on traffic requirements and historical data.

[0032] In other examples, the overlay multicast orchestrator 142 may take advantage of routes already calculated by the SD-WAN 140 (and / or its subservices). Existing SD-WAN services typically calculate routes for unicast traffic between VPNCs and branch gateways. Accordingly, the overlay multicast orchestrator 142 may orchestrate multicast traffic over these pre-calculated routes. By leveraging existing SD-WAN knowledge and services, the overlay multicast orchestrator 142 can enhance its multicast orchestration service without consuming significant additional WAN bandwidth, cloud resources, etc.

[0033] In certain examples, the overlay multicast orchestrator 142 may utilize the overlay network of a large software-defined branch office facility 200 to route multicast traffic between the multicast source 150 and the branch offices 110-130. In a particular network, the underlay (or underlay network) may refer to the physical connections of the network (e.g., Ethernet). In contrast, the overlay (or overlay network) may refer to a logical network that leverages virtualization to build connectivity on top of the physical infrastructure of the network by using tunnel encapsulation. In other words, "overlay tunnels" may refer to virtual circuits that connect nodes of a network. In this case, overlay tunnels may connect VPNCs and branch gateways.Various protocols, such as IPSec and GRE, can be used to transport network traffic through these overlay tunnels. SD-WAN architectures like the one shown here can generally rely on overlay tunnels to connect the various branch offices and other nodes of their network.

[0034] Branch Offices 110, 120, and 130: As used herein, a branch office may refer to a physical location where one or more hosts (e.g., a computer or other network device associated with a user) may connect to the WAN 160. For example, a branch office may be a remote office of an organization, a coffee shop, a home office, etc. While only three branch offices are shown in the example figure, the large-scale software-defined branch deployment 100 may include any number of branch offices. In certain examples, these may be branch offices of a particular organization. In other examples, not all branch offices are associated with a single organization.

[0035] Each branch office may have its own local area network (LAN), but this is not mapped. The various network devices (e.g., hosts, branch gateways, routers, etc.) within a particular branch office can communicate with each other via the branch office's LAN.

[0036] Hosts: A host can be a network device (e.g., a computer, tablet, smartphone, etc.) connected to a user at a branch office. A branch office can have any number of hosts, but as illustrated, each branch office in a large software-defined branch facility 100 has two hosts. As described above, a host can be a recipient of multicast traffic. In other words, a host can be a member of a multicast group. For example, hosts 114a and 124b can be members of multicast group 224.0.0.10. Accordingly, hosts 114a and 124b can receive multicast traffic associated with multicast stream 152 (the exact mechanisms by which multicast traffic is delivered to hosts 114a and 124b are described in more detail below).

[0037] If a host is interested in a multicast stream but is not yet a member of the multicast group associated with the multicast stream, the host can send a message to a branch gateway. A particular host can be connected to (i.e., behind) a branch gateway (here, any number of hosts can be behind the branch gateway). As described above, multiple branch gateways can be deployed in a branch office for load balancing and redundancy purposes. Accordingly, a particular host can connect to a specific branch gateway based on factors such as path latency. As shown, host 114a is behind branch gateway 112a; host 114b is behind branch gateway 112b; host 124a is behind branch gateway 122a; host 124b is behind branch gateway 122b; and so on.

[0038] If a host is not yet a member of a multicast group but is interested in joining, the host may send a message to the branch gateway behind which it is located. In certain examples, this may mean that the host sends a "join request" message to the branch gateway. For example, host 134b may not yet be a member of multicast group 224.0.0.10 but may be interested in joining. Accordingly, host 134b may send a join request message to branch gateway 132b. In certain examples, this join request message may be sent over an IGMP protocol (i.e., an IGMP join request message). In some examples, a host may send an IGMP join request to a branch gateway over a branch office LAN.

[0039] In the same / similar way, a host wishing to leave a multicast group can send an "exit request" message to the branch gateway behind which it is located. For example, if host 114a wishes to leave multicast group 224.0.0.10, host 114a can send an "exit request" message to branch gateway 112a.

[0040] Branch Office Gateways: A branch office gateway can refer to a network device (hardware or software) that transmits traffic between a branch office and other networks. For example, the branch office gateways shown in the example figure can transmit traffic between the WAN 160 and the various network devices at their branch office (e.g., other branch office gateways, hosts, etc.).

[0041] Typically, there are multiple branch gateways per branch office (which may collectively be referred to as a BG cluster). However, for a given multicast stream, there is one branch gateway leader per BG cluster. As described above, CaaS 144 can determine which branch gateway of a given BG cluster is the leader for a given multicast stream / group. CaaS 144 can also manage the configuration of the branch gateways of a given BG cluster to ensure that each branch gateway knows which branch gateway of the BG cluster is the leader for a given multicast stream. As previously mentioned, significant savings in WAN bandwidth consumption can be achieved by simply directing multicast traffic to a single "branch gateway leader" per branch office. This compares favorably to existing technologies (e.g.,PIM) that replicate multicast traffic across all branch gateways of a given branch office for a large-scale software-defined branch deployment.

[0042] For multicast stream 152, branch gateways 112a, 122a, and 132a are the branch gateway leaders for their respective BG clusters. The other branch gateways (i.e., branch gateways 112b, 122b, and 132b) may be referred to as secondary branch gateways for multicast stream 152.

[0043] As described above, the branch gateway leader is the only branch gateway in the branch office that (a) sends join / leave request messages to the overlay multicast orchestrator 142 for the multicast stream 152 and (b) receives multicast traffic from VPNC 154a associated with the multicast stream 152.

[0044] However, both leading and secondary branch gateways may receive requests from hosts to join or leave multicast group 224.0.0.10 (as described above, a given host may be behind either a leading or secondary branch gateway). Likewise, both leading and secondary branch gateways may forward multicast traffic associated with multicast stream 152 to the hosts that have joined multicast group 224.0.0.10. Accordingly, internal forwarding of join / leave requests and multicast traffic between branch gateways may be required.

[0045] Forwarding Join / Leave Request Messages: When a secondary branch gateway receives a join / leave request message from a host, the secondary branch gateway can forward this message to the lead branch gateway. For example, if branch gateway 132b receives a message from host 134b requesting to join multicast group 224.0.0.10, branch gateway 132b can forward this message to branch gateway 132a (as described above, branch gateway 132a can then forward this message to overlay multicast orchestrator 142). In the same / similar manner, if the branch gateway 122b receives a message from the host 124b requesting to leave the multicast group 224.0.0.10, the branch gateway 122b may forward this message to the branch gateway 122a.In certain examples, message forwarding between branch gateways can occur across a branch office LAN.

[0046] When a branch gateway leader receives a join / leave request from a host, internal forwarding of the join / leave request may not be required. For example, if branch gateway 132a receives a message from host 134a requesting to join multicast group 224.0.0.10, branch gateway 132a does not need to forward this message to another branch gateway within branch 130. Instead, branch gateway 132a, as the branch gateway leader, can forward this message directly to overlay multicast orchestrator 142.

[0047] Forwarding Multicast Traffic: When a branch gateway leader receives multicast traffic from VPNC 154a, the branch gateway may forward the multicast traffic to (a) an interested host downstream of the leading branch gateway or (b) a secondary branch gateway upstream of an interested host. For example, branch gateway 112a may receive multicast traffic associated with multicast stream 152 from VPNC 154a (as orchestrated by overlay multicast orchestrator 142). Both hosts 114a and 114b may be interested in multicast stream 152 (i.e., they may both be members of multicast group 224.0.0.10). Accordingly, branch gateway 112a may forward the multicast traffic directly to host 114a because host 114a is downstream of branch gateway 112a.To forward the multicast traffic to host 114b, branch gateway 112a must forward the multicast traffic to branch gateway 112b because host 114b is located behind branch gateway 112b.

[0048] Fig. Figure 2 is an example flowchart illustrating example operations that may be performed by a cloud-based multicast orchestrator to orchestrate multicast traffic within a large-scale software-defined branch office deployment, in accordance with various examples. As a supplement to Fig. 2 is Fig. 3 an example system diagram showing the components of a cloud-based multicast orchestrator according to various examples.

[0049] In step 202, the cloud-based multicast orchestrator may receive a message from a branch gateway leader of a first customer site that one or more hosts at the first customer site are interested in a multicast stream. In various examples, this step may be performed by component 302 of multicast orchestrator 300 receiving a multicast join request.

[0050] The first customer site (i.e., the branch office) can be one of multiple customer sites that form a large-scale software-defined branch facility connected via a wide area network (WAN). In large software-defined branch offices, software-defined WAN (SD-WAN) technology can be used to manage a WAN across multiple customer sites. In many examples, SD-WAN technology is implemented as a cloud-based service.

[0051] The cloud-based multicast orchestrator can be a piece of hardware or software that orchestrates the routes for multicast traffic between a source of the multicast stream and the branch gateway leader. In certain examples, the cloud-based multicast orchestrator can be implemented as part of an SD-WAN service (e.g., Aruba SD-WAN from HPE) that manages a WAN that includes the first customer site.

[0052] A multicast stream can be any data transmission (e.g., streaming media, information dissemination, etc.) that is simultaneously directed to a group of interested recipients (e.g., hosts). In certain examples, a multicast stream can be associated with a multicast group. A multicast group can include as members (a) the source of the multicast stream and (b) the recipients of the multicast stream (e.g., hosts).

[0053] A host can refer to a network device (e.g., a computer, tablet, smartphone, etc.) connected to a user at a customer site. For example, a host can be a user's work computer or smartphone. As described above, a host can be a receiver of the multicast stream. In other words, a host can be a member of a multicast group associated with the multicast stream.

[0054] If a host is interested in the multicast stream but is not yet a member of the multicast stream / group, the host can send a message to a branch gateway at a customer site. A specific host can be connected to (i.e., behind) a specific branch gateway. As described above, multiple branch gateways can be deployed at the first customer site for load balancing and redundancy purposes. Accordingly, a specific host at the first customer site can be connected to a specific branch gateway at the first customer site based on factors such as path latency.

[0055] A branch gateway can refer to a network device (hardware or software) that carries traffic between a customer site and other networks. As described above, the first customer site can include multiple branch gateways. However, for the multicast stream, there is only one branch gateway leader at the first customer site. The branch gateway leader at the first customer site is the only branch gateway at the first customer site that (a) sends messages to the cloud-based multicast orchestrator that one or more hosts at the first customer site are interested in joining a multicast stream and (b) receives multicast traffic related to the multicast stream from a VPNC connected to the multicast stream / multicast stream source.

[0056] Certain branch gateways at the first customer site will be secondary branch gateways (i.e., branch gateways that are not the leader). Like the leading branch gateway, the secondary branch gateways may receive requests from one or more hosts at the first customer site to join or leave a multicast group / stream. Similarly, both the leading and secondary branch gateways may forward multicast traffic associated with the multicast stream to the hosts that have joined the multicast group / stream.

[0057] As described above, the first customer site can be one of several customer sites in a large-scale software-defined branch deployment connected over a WAN, and the cloud-based multicast orchestrator can be implemented as part of an SD-WAN platform that manages the WAN. Accordingly, the cloud-based multicast orchestrator can receive a message over the WAN that one or more hosts at the first customer site are interested in participating in a multicast stream. The message itself can be sent over various protocols such as WebSocket, grpc, etc.

[0058] In step 204, the cloud-based multicast orchestrator may orchestrate a route for transmitting the multicast stream between a VPNC associated with the multicast stream and the branch gateway leader at the first customer site. In various examples, this step may be performed by the multicast route orchestration component 304 of the multicast orchestrator 300.

[0059] A VPNC can refer to a hardware or software application used to connect virtual private networks (VPNs). In this case, the VPNC associated with the multicast stream can be used to connect a source of the multicast stream (e.g., a data center) to the branch gateway leader at the first customer site. Accordingly, the multicast traffic associated with the multicast stream can be transmitted over this connection. In certain examples, the VPNC associated with the multicast stream can be located at the source of the multicast stream.

[0060] In some examples, the cloud-based multicast orchestrator can calculate routes for multicast traffic based on source information (i.e., information related to the VPNC associated with the multicast stream) and receiver information (i.e., information related to the branch gateway leader). In certain examples, the cloud-based multicast orchestrator can learn to calculate routes that reduce the bandwidth consumption of a WAN network. In various examples, the cloud-based multicast orchestrator can use artificial intelligence (AI) or machine learning to calculate the routes that reduce WAN bandwidth consumption. After calculating the routes, the cloud-based multicast orchestrator can orchestrate the multicast traffic over those routes.

[0061] In other examples, the cloud-based multicast orchestrator can take advantage of routes already calculated by the SD-WAN service to which the cloud-based multicast orchestrator belongs. As described above, existing SD-WAN services typically calculate routes for unicast traffic between VPNCs and branch gateways. Accordingly, the cloud-based multicast orchestrator can choose to orchestrate multicast traffic over these pre-calculated routes. By leveraging existing SD-WAN knowledge and services, the cloud-based multicast orchestrator can enhance its multicast orchestration service without consuming significant additional WAN bandwidth, cloud resources, and so on.

[0062] In certain examples, the cloud-based multicast orchestrator can leverage a WAN's overlay network when orchestrating routes for multicast traffic. In a given network, the underlay (or underlay network) can refer to the network's physical connections (e.g., Ethernet). In contrast, the overlay (or overlay network) can refer to a logical network that leverages virtualization to build connectivity on top of the network's physical infrastructure by using tunnel encapsulation. In other words, "overlay tunnels" can refer to virtual circuits that connect nodes of a network. In this case, overlay tunnels can connect VPNCs and branch gateways. Various protocols, such as IPSec and GRE, can be used to transport network traffic through these overlay tunnels.In general, SD-WAN technologies—in which the cloud-based multicast orchestrator can be integrated—often use overlay network tunnels to connect the various branch offices and other nodes of their WAN.

[0063] As in connection with Fig. As described in Sections 4-7, once the multicast traffic has been transmitted to the branch gateway heads via the routes orchestrated by the cloud-based multicast orchestrator, it can be forwarded to the various hosts interested in the multicast.

[0064] In various examples, the cloud-based multicast orchestrator may also receive join request messages from branch gateway leaders at other customer sites (e.g., a second customer site). Accordingly, the cloud-based multicast orchestrator may orchestrate routes for transmitting multicast traffic to these branch gateway leaders at other customer sites in the same / similar manner as described above.

[0065] Fig. Figure 4 is an example flowchart illustrating example operations that may be performed by a customer site branch gateway leader to reduce WAN bandwidth consumption for multicast transmission in large software-defined branch deployments according to various examples. As a supplement to Fig. 4 is Fig. 5 is an example system diagram showing the components of a branch gateway leader according to various examples.

[0066] In step 402, the customer site branch gateway leader may receive one or more messages from one or more secondary branch gateways at the customer site that one or more hosts at the customer site are interested in a multicast stream. In various examples, step 402 may be performed by component 502 of branch gateway 500 receiving a multicast join request.

[0067] As in connection with the Fig. As described above, the customer site can be one of multiple customer sites that form a large-scale software-defined branch facility connected via a WAN. In large software-defined branches, SD-WAN technology can be used to manage a WAN across multiple customer sites. In many examples, SD-WAN technology is implemented as a cloud-based service.

[0068] A multicast stream can be any data transmission (e.g., streaming media, information dissemination, etc.) directed to a group of interested recipients (e.g., hosts) simultaneously. In certain examples, a multicast stream can be associated with a multicast group. A multicast group can include as members (a) the source of the multicast stream and (b) the recipients of the multicast stream (e.g., hosts).

[0069] A branch gateway can refer to a network device (hardware or software) that carries traffic between the customer site and other networks. As described above, the customer site can include multiple branch gateways. However, for the multicast stream, there is only one branch gateway leader at the customer site. The branch gateway leader is the only branch gateway at the customer site that a) sends messages to the cloud-based multicast orchestrator that one or more hosts at the customer site are interested in a multicast stream and b) receives multicast traffic associated with the multicast stream from a VPNC associated with the multicast stream.

[0070] Certain branch gateways at the customer site are secondary branch gateways (i.e., branch gateways that are not the leader). Like the leading branch gateway, secondary branch gateways can receive requests from one or more hosts at the customer site to join or leave a multicast group / stream (in this case, a specific host may be connected to a secondary branch gateway for path latency / load balancing purposes). Similarly, both the leading branch gateway and the secondary branch gateway can forward multicast traffic associated with the multicast stream to the hosts that have joined the multicast group / stream.However, because only the branch gateway manager (a) sends messages to the cloud-based multicast orchestrator that one or more hosts at the customer site are interested in a multicast stream and (b) receives the multicast traffic associated with the multicast stream from a VPNC, internal forwarding of join / leave requests and multicast traffic between the customer site branch gateways may be required.

[0071] For this reason, the leading branch gateway may receive one or more messages from one or more secondary branch gateways at the customer site indicating that one or more hosts at the customer site are interested in joining the multicast stream.

[0072] As described above, the various network devices at a customer site (e.g., branch gateways, hosts, routers, etc.) can be connected via a local area network (LAN). Accordingly, communication between branch gateways at the customer site can occur via the customer site's LAN using various protocols.

[0073] In step 404, the branch gateway leader at the customer site may send a message to a cloud-based multicast orchestrator that one or more hosts at the customer site are interested in joining the multicast stream. In various examples, step 404 may be performed by component 504 of the branch gateway leader 500 sending a multicast join request.

[0074] As in connection with the Fig. As described above, the cloud-based multicast orchestrator can be a piece of hardware or software that orchestrates routes for multicast traffic between a source of the multicast stream and the branch gateway leader. In certain examples, the cloud-based multicast orchestrator can be implemented as part of an SD-WAN service (e.g., Aruba SD-WAN from HPE) that manages the WAN to which the customer site belongs.

[0075] Accordingly, communication between the branch gateway leader and the cloud-based multicast orchestrator can occur over the WAN / large-scale software-defined branch facility to which the customer site belongs. Communication between the branch gateway leader and the cloud-based multicast orchestrator can be transmitted over various protocols such as WebSocket, gRPC, etc.

[0076] In step 406, the branch gateway leader at the customer site may receive traffic associated with the multicast stream from a VPNC associated with the multicast stream. In various examples, step 406 may be performed by the multicast traffic receiving component 506 of the branch gateway leader 500.

[0077] As in connection with the Fig. As described above, a VPNC can refer to a hardware or software application used to connect virtual private networks (VPNs). Here, the VPNC associated with the multicast stream can be used to connect a source of the multicast stream to the branch gateway leader. Accordingly, the multicast traffic associated with the multicast stream can be transmitted over this connection / route.

[0078] In certain examples, the route between the VPNC and the branch gateway leader may be implemented through an overlay network of the WAN / large software-defined branch facility. As described above, the overlay (or overlay network) can refer to a logical network that leverages virtualization to build connectivity on top of the network's physical infrastructure by using tunnel encapsulation. In other words, "overlay tunnels" can refer to virtual circuits that connect nodes of a network. In this case, overlay tunnels can connect VPNCs and branch gateways. Various protocols, such as IPSec and GRE, can be used to transport network traffic through these overlay tunnels.In general, SD-WAN technologies—in which the cloud-based multicast orchestrator can be integrated—often use overlay network tunnels to connect the various branch offices and other nodes of their WAN.

[0079] In step 408, the branch gateway leader at the customer site may forward the traffic associated with the multicast stream to one or more secondary branch gateways at the customer site. In various examples, step 408 may be performed by the multicast traffic forwarding component 508 of the branch gateway leader 500.

[0080] As described above, internal forwarding of multicast traffic may be required between the customer site's branch gateways because certain hosts interested in the multicast stream may be connected to (i.e., downstream of) secondary branch gateways. Therefore, the branch gateway leader at the customer site may be required to forward the multicast traffic it receives from the VPNC to one or more secondary branch gateways. Once the secondary branch gateways receive the forwarded multicast traffic, they can forward the multicast traffic to the interested hosts to which they are connected.

[0081] As described above, communication between branch gateways can occur over the customer site LAN using various protocols.

[0082] In various examples, the branch gateway manager may receive a request to join a multicast stream directly from a specific host. In this scenario, no internal forwarding of the given host's join request between the branch gateways would be required, as the branch gateway manager can forward the given host's join request directly to the cloud-based multicast orchestrator. Similarly, if the branch gateway manager receives the traffic associated with the multicast stream from the VPNC, it can forward the multicast traffic directly to the host in question.

[0083] Fig. Figure 6 is an example flowchart illustrating example operations that may be performed by a customer site secondary branch gateway to reduce WAN bandwidth consumption for multicast transmission in large software-defined branch deployments according to various examples. As a supplement to Fig. 6 is Fig. 7 is an example system diagram showing the components of a secondary branch gateway according to various examples.

[0084] In step 602, the secondary branch gateway may receive one or more requests to join a multicast stream from one or more hosts at the customer site. In various examples, step 602 may be performed by component 702 of the secondary branch gateway 700 that receives multicast join requests.

[0085] As described above, the customer site can be one of multiple customer sites that form a large software-defined branch facility connected via a WAN. In large software-defined branch facilities, SD-WAN technology can be used to manage a WAN across multiple customer sites. In many examples, SD-WAN technology is implemented as a cloud-based service.

[0086] A multicast stream can be any data transmission (e.g., streaming media, information dissemination, etc.) directed to a group of interested recipients (e.g., hosts) simultaneously. In certain examples, a multicast stream can be associated with a multicast group. A multicast group can include as members (a) the source of the multicast stream and (b) the recipients of the multicast stream (e.g., hosts).

[0087] A host can refer to a network device (e.g., a computer, tablet, smartphone, etc.) connected to a user at the customer's location. For example, a host can be a user's work computer or smartphone. As described above, a host can be a receiver of the multicast stream. In other words, a host can be a member of a multicast group.

[0088] If a host is interested in the multicast stream / group but is not yet a member of the multicast stream / group, the host can send a message to a branch gateway at the customer site. A given host can be connected to (i.e., behind) a given branch gateway (here, any number of hosts can be behind the given branch gateway). As described above, multiple branch gateways can be deployed at the customer site for load balancing and redundancy purposes. Accordingly, a given host can connect to a given branch gateway, with factors such as path latency playing a role.

[0089] In certain examples, a host's request to join the multicast stream may be sent to a branch gateway using an Internet Group Management Protocol (IGMP) protocol (i.e., an IGMP request message). In some examples, a host may send an IGMP join request to a branch gateway across a branch office LAN.

[0090] A branch gateway can refer to a network device (hardware or software) that carries traffic between the customer site and other networks. As described above, the customer site can include multiple branch gateways. However, for the multicast stream, there is only one branch gateway leader at the customer site. The branch gateway leader is the only branch gateway at the customer site that a) sends messages to a cloud-based multicast orchestrator and b) receives multicast traffic associated with the multicast stream from a VPNC.

[0091] The branch gateways that are not the branch gateway leader can be referred to as branch secondary gateways. Like the branch gateway leader, the secondary branch gateways can receive requests from one or more hosts at the customer site to join or leave a multicast group / stream. Similarly, both the leading and secondary branch gateways can forward multicast traffic associated with the multicast stream to the hosts that have joined the multicast group / stream. However, because only the branch gateway leader a) sends messages to the cloud-based multicast orchestrator and b) receives multicast traffic associated with the multicast stream from a VPNC, internal forwarding of multicast traffic between the customer site branch gateways may be required.

[0092] For this reason, the secondary branch gateway may forward the one or more requests to join the multicast stream to a branch gateway leader in step 604. As described above, communication between branch gateways over the customer site LAN may occur using various protocols. In various examples, step 604 may be performed by the multicast join request forwarding component 704 of the secondary branch gateway 700.

[0093] In step 606, the secondary branch gateway may receive the traffic associated with the multicast stream from the branch gateway leader. In various examples, step 604 may be performed by the multicast traffic receiving component 706 of the secondary branch gateway 700.

[0094] Because, as described above, certain hosts interested in the multicast stream may be located behind secondary branch gateways, internal forwarding of multicast traffic between branch gateways at the customer site may be required. Therefore, the branch gateway leader at the customer site may need to forward the multicast traffic it receives from the VPNC to one or more secondary branch gateways. Once the secondary branch gateways receive the forwarded multicast traffic, they can forward the multicast traffic to the hosts they are connected to.

[0095] Accordingly, in step 608, the secondary branch gateway may forward the traffic associated with the multicast stream to the one or more hosts at the customer site. In various examples, step 608 may be performed by the multicast traffic forwarding component 708 of the secondary branch gateway 700.

[0096] As described above, the secondary branch gateway at the customer site can use various protocols, including IGMP, to transmit the traffic associated with the multicast stream to one or more hosts at the customer site.

[0097] Fig.Figure 8 shows a block diagram of an example computer system 800 in which various embodiments described herein may be implemented. Computer system 800 includes a bus 802 or other communication mechanism for conveying information, and one or more hardware processors 804 coupled to bus 802 for processing information. Hardware processor(s) 804 may be, for example, one or more general-purpose microprocessors.

[0098] Computer system 800 also includes main memory 806, such as random access memory (RAM), a cache, and / or other dynamic storage devices connected to bus 802, for storing information and instructions to be executed by processor 804. Main memory 806 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 804. Such instructions, stored in storage media accessible by processor 804, make computer system 800 a special-purpose machine adapted to perform the operations specified in the instructions.

[0099] Computer system 800 also includes a read-only memory (ROM) 808 or other static storage device connected to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk, an optical disk, or a USB flash drive, etc., is provided and connected to bus 802 for storing information and instructions.

[0100] Computer system 800 may be connected to a display 812, such as a liquid crystal display (LCD) (or a touch screen), via bus 802 to display information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to bus 802 to communicate information and command selections to processor 804. Another type of user input device is cursor control 816, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to processor 804 and controlling cursor movement on display 812. In some embodiments, the same direction information and command selections as with cursor control may be implemented via receiving touches on a touchscreen without a cursor.

[0101] Computer system 800 may include a user interface module for implementing a graphical user interface, which may be stored on a mass storage device as executable software code executed by the computing device(s). This and other modules may include, for example, components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0102] In general, the word "component," "engine," "system," "database," "data store," and the like, as used herein, may refer to logic embodied in hardware or firmware, or to a collection of software instructions that may have entry and exit points and may be written in a programming language such as Java, C, or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It is understood that software components may be callable by other components or by themselves, and / or may be invoked in response to detected events or interrupts. Software components configured to run on computing devices may be embodied on a computer-readable medium, such as a hard disk.a compact disc, digital video disc, flash drive, magnetic disk, or other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that must be installed, decompressed, or decrypted before execution). Such software code may be stored partially or entirely in a memory of the executing computing device for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. In addition, the hardware components may consist of interconnected logic units, such as gates and flip-flops, and / or programmable units, such as programmable gate arrays or processors.

[0103] Computer system 800 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, causes or programs computer system 800 to be a special-purpose machine. According to one embodiment, the techniques described herein are performed by computer system 800 in response to processor(s) 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another storage medium, such as storage device 810. Execution of the instruction sequences contained in main memory 806 causes processor(s) 804 to perform the process steps described herein.In alternative embodiments, hard-wired circuits may be used instead of or in combination with software instructions.

[0104] The term "non-transitory media" and similar terms as used herein refer to any media that stores data and / or instructions that cause a machine to operate in a particular manner. Such non-transitory media may include non-volatile media and / or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as main memory 806. Common forms of non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or other magnetic data storage media, CD-ROMs, other optical data storage media, physical media with hole patterns, RAM, PROM and EPROM, FLASH EPROM, NVRAM, other memory chips or cartridges, and networked versions thereof.

[0105] Non-transitory media are distinct from transmission media but can be used in conjunction with them. Transmission media are involved in the transfer of information between non-transitory media. Examples of transmission media include coaxial cables, copper cables, and fiber optic cables, including the wires that make up bus 802. Transmission media can also take the form of sound or light waves, such as those generated in radio and infrared data communications.

[0106] Computer system 800 also includes a communications interface 818 connected to bus 802. Network interface 818 establishes a two-way data communications connection to one or more network connections connected to one or more local area networks. For example, communications interface 818 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for establishing a data communications connection to a corresponding type of telephone line. As another example, network interface 818 may be a Local Area Network (LAN) card for establishing a data communications connection to a compatible LAN (or a WAN component for communicating with a WAN). Wireless connections may also be implemented.In each of these implementations, the network interface 818 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams containing various types of information.

[0107] A network connection typically enables data communication across one or more networks to other data devices. For example, a network connection may establish a connection across a local area network to a host computer or data devices operated by an Internet service provider (ISP). The ISP, in turn, provides data communication services across the worldwide packet data communications network, now commonly referred to as the "Internet." Both the local area network and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. The signals across the various networks and the signals on the network connection and across the communications interface 818 that carry the digital data to and from the computer system 800 are examples of transmission media.

[0108] Computer system 800 can send messages and receive data, including program code, over the network(s), the network connection, and the communications interface 818. In the Internet example, a server could transmit requested code for an application program over the Internet, the ISP, the local network, and the communications interface 818.

[0109] The received code may be executed by processor 804 upon receipt and / or stored in storage device 810 or other non-volatile memory for later execution.

[0110] Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors may also operate to support the performance of the corresponding operations in a cloud computing environment or as software as a service (SaaS). The processes and algorithms may be partially or fully implemented in application-specific circuitry. The various features and methods described above may be used independently or combined in various ways.Various combinations and subcombinations are intended to be within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the associated blocks or states may be executed in other suitable orders, in parallel, or otherwise. Blocks or states may be added to or removed from the disclosed examples. The execution of certain operations or processes may be distributed among computer systems or computer processors located not only on a single machine, but distributed across a number of machines.

[0111] As used herein, a circuit may be implemented in any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms may be implemented to form a circuit. In implementation, the various circuits described herein may be implemented as discrete circuits, or the described functions and features may be distributed, in part or in whole, among one or more circuits.Although various features or functional elements are individually described or claimed as separate circuits, these features and functions may be shared by one or more common circuits, and such description is not intended to assume or imply that separate circuits are required to implement these features or functions. If a circuit is implemented in whole or in part with software, that software may be implemented to operate with a computer or processing system capable of performing the functionality described with respect to it, such as computer system 800.

[0112] As used herein, the term "or" can be interpreted both inclusively and exclusively. Furthermore, descriptions of resources, acts, or structures in the singular should not be construed as excluding the plural. Conditional expressions such as "may," "could," "might," or "may," unless expressly stated otherwise or understood by context, are generally intended to convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not.

[0113] Unless expressly stated otherwise, the terms and expressions used in this document, as well as their variations, are not to be interpreted as limiting but as open-ended. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar import are not to be construed as limiting the subject matter described to a particular period of time or to a subject matter available at a particular time, but should be understood to include conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future.The presence of broader words and phrases such as “one or more,” “at least,” “but not limited to,” or similar phrases in some cases should not be construed as meaning that the narrower case is intended or required in the absence of such broader phrases.

[0114] It should be noted that the terms "optimize," "optimal," and the like, as used herein, may be used to make or achieve performance as effective or perfect as possible. However, as one skilled in the art reading this document will recognize, perfection cannot always be achieved. Accordingly, these terms may also mean making or achieving performance as good or effective as possible or practical under the circumstances, or making or achieving performance better than that achievable with other settings or parameters.

Claims

[1] A branch gateway leader (112a, 122a, 132a, 500) of a customer site (110, 120, 130), comprising: at least one processor (804) and a memory (806, 808; 810) storing instructions that, when executed by the at least one processor, cause the branch gateway leader to perform a method comprising: Receiving one or more messages from one or more secondary branch gateways (112b, 122b, 132b, 700) of the customer site that one or more hosts (114a, 114b, 124a, 124b, 134a, 134b) at the customer site are interested in joining a multicast stream (152), the branch gateway leader and each secondary branch gateway connecting the customer site to an external network; Sending a message that the one or more hosts at the customer site are interested in joining the multicast stream to a cloud-based multicast orchestrator (142, 300) that enables multicast routes to the customer site; Receiving traffic associated with the multicast stream from a Virtual Personal Network (VPNC) client (154a, 154b), the VPNC connecting the customer site to a source of the multicast stream (150); and Forwarding the traffic associated with the multicast stream to the one or more secondary branch gateways at the customer site; where: the customer site is one of multiple customer sites in a large-scale software-defined (SD) branch facility (100) connected via a wide area network (WAN) (160); the cloud-based multicast orchestrator enables multicast routes to the SD branch facility; the WAN comprises a physical network and a virtual overlay network that builds on the physical network, and the branch gateway leader receives the traffic associated with the multicast stream from the VPNC through an overlay tunnel of the overlay virtual network. [2] The branch gateway leader of claim 1, wherein the method further comprises: Receiving a message from a given host, different from the one or more hosts at the customer site, that the given host is interested in joining the multicast stream; and Forward the traffic associated with the multicast stream to the given host. [3] The branch gateway leader of claim 2, wherein the given host is connected to the branch gateway leader and not to one of the one or more secondary branch gateways. [4] The branch gateway leader of claim 1, wherein: the branch gateway leader and the one or more secondary branch gateways of the customer site are located on a local area network (LAN), and the branch gateway leader receives the one or more messages over the LAN. [5] The branch gateway leader of claim 4, wherein: the branch gateway leader and a given host other than the one or more hosts are connected via the LAN; and the branch gateway leader receives a message from the given host over the LAN that the given host is interested in joining the multicast stream. [6] The branch gateway leader of claim 5, wherein the message that the given host is interested in joining the multicast stream is sent using an Internet Group Management Protocol (IGMP). [7] The branch gateway leader of claim 1, wherein the method further comprises receiving, by the branch gateway leader, a route to transmit the multicast stream between the VPNC and the branch gateway leader, wherein the route is orchestrated at the cloud-based multicast orchestrator. [8] A procedure comprising: by a branch gateway leader (112a, 122a, 132a, 500), receiving one or more messages from one or more secondary branch gateways (112b, 122b, 132b, 700) at a customer site (110, 120, 130) that one or more hosts (114a, 114b, 124a, 124b, 134a, 134b) at the customer site are interested in joining a multicast stream (152), the branch gateway leader and each secondary branch gateway connecting the customer site to an external network; Sending a message that the one or more hosts at the customer site are interested in joining the multicast stream to a cloud-based multicast orchestrator (142, 300) that enables multicast routes to the customer site; receiving traffic associated with the multicast stream from a Virtual Personal Network (VPNC) client (154a, 154b) associated with the multicast stream, the VPNC connecting the customer site to a source of the multicast stream (150); and Forwarding the traffic associated with the multicast stream to the one or more secondary branch gateways at the customer site; Receiving a message from a given host, different from the one or more hosts at the customer site, that the given host is interested in joining the multicast stream, wherein the given host is associated with the branch gateway leader and not with one of the one or more secondary branch gateways; and Forward the traffic associated with the multicast stream to the given host. [9] The method of claim 8, wherein the customer site is one of a plurality of customer sites in a large-scale software-defined (SD) branch facility (100) connected via a wide area network (WAN) (160), and wherein the cloud-based multicast orchestrator enables multicast routes to the SD branch facility. [10] The method of claim 9, wherein the WAN comprises a physical network and a virtual overlay network that builds on the physical network, and the branch gateway leader receives the traffic associated with the multicast stream from the VPNC through an overlay tunnel of the overlay virtual network. [11] The method of claim 8, wherein the branch gateway leader and the one or more secondary branch gateways of the customer site are located on a local area network (LAN), and the branch gateway leader receives the one or more messages over the LAN. [12] The method of claim 11, wherein the two-site gateway leader and a given host other than the one or more hosts are connected via the LAN and the branch gateway leader receives a message from the given host over the LAN that the given host is interested in joining the multicast stream. [13] The method of claim 12, wherein the message that the given host is interested in joining the multicast stream is sent using an Internet Group Management Protocol (IGMP). [14] The method of claim 8, further comprising receiving, by the branch gateway leader, a route to transmit the multicast stream between the VPNC and the branch gateway leader, wherein the route is orchestrated at the cloud-based multicast orchestrator. [15] A non-transitory computer-readable storage medium (806, 808, 810) containing instructions that, when executed by at least one processor (804), cause a branch gateway leader (112a, 122a, 132a, 500) of a customer site (110, 120, 130) to perform a method comprising: Receiving one or more messages from one or more secondary branch gateways (112b, 122b, 132b, 700) of the customer site that one or more hosts (114a, 114b, 124a, 124b, 134a, 134b) at the customer site are interested in joining a multicast stream (152), the branch gateway leader and each secondary branch gateway connecting the customer site to an external network; Sending a message that the one or more hosts at the customer site are interested in joining the multicast stream to a cloud-based multicast orchestrator (142, 300) that enables multicast routes to the customer site; Receiving traffic associated with the multicast stream from a Virtual Personal Network (VPNC) client (154a, 154b) associated with the multicast stream, the VPNC connecting the customer site to a source of the multicast stream (150); Forwarding the traffic associated with the multicast stream to the one or more secondary branch gateways at the customer site; Receiving a message from a given host, different from the one or more hosts at the customer site, that the given host is interested in joining the multicast stream, wherein the given host is associated with the branch gateway leader and not with one of the one or more secondary branch gateways; and Forward the traffic associated with the multicast stream to the given host.

Images