Branch gateway and method and storage medium for network management

Abstract

Embodiments of the present disclosure relate to multicast WAN optimization in large-scale branch deployments using a central hub cloud-based service. Systems and methods are provided for reducing WAN bandwidth consumption used by multicast for large-scale software-defined branch deployments. In particular, a cloud-based multicast coordinator can be implemented as part of the SD-WAN service. The cloud-based multicast coordinator can coordinate the routing of multicast services between multicast sources and individual branches for large-scale software-defined branch deployments. The cloud-based multicast coordinator can coordinate the routing of multicast services, thereby reducing / optimizing WAN bandwidth consumption. In conjunction with the cloud-based multicast coordinator, an example can utilize a branch gateway hierarchy that designates one branch gateway as the "leader" for a given multicast flow to further reduce WAN bandwidth consumption used by multicast.

Description

Background Art

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

[0002] Associated with multicast is the concept of a multicast group. A multicast group typically has an IP address that identifies the multicast group (i.e., a multicast group IP address). Members of a multicast group can join or leave the multicast group without reference to other members. Traffic sent by members of a multicast group can be received by all other members (e.g., receivers) of the multicast group. Traditionally, multicast traffic is routed to multicast group members using an IP routing protocol such as Protocol Independent Multicast (PIM). BRIEF DESCRIPTION OF THE DRAWINGS

[0003] According to one or more different embodiments, the present disclosure is described in detail with reference to the following drawings. These drawings are provided for illustration purposes only and depict only typical or example embodiments.

[0004] Figure 1 Depicted are example large-scale software-defined branch deployments according to various examples of the presently disclosed technology;

[0005] Figure 2 is an example flow chart illustrating example operations that may be performed by a cloud-based multicast coordinator to coordinate multicast traffic within a large-scale software-defined branch deployment according to various examples;

[0006] Figure 3 It is a diagram showing various examples. Figure 2 An example system diagram of components of a cloud-based multicast coordinator;

[0007] Figure 4 is an example flow chart illustrating example operations that may be performed by a branch gateway leader to reduce WAN bandwidth consumption for multicast transmissions in a large-scale software-defined branch deployment according to various examples;

[0008] Figure 5 It is a diagram showing various examples. Figure 4 An example system diagram of components led by a branch gateway;

[0009] Figure 6 is an example flow chart illustrating example operations that may be performed by a secondary branch gateway to reduce WAN bandwidth consumption for multicast transmissions in a large-scale software-defined branch deployment according to various examples;

[0010] Figure 7 It is a diagram showing various examples. Figure 6 An example system diagram of components of a secondary branch gateway; and

[0011] Figure 8 are example computing components that can be used to implement various features of the embodiments described in this disclosure.

[0012] The drawings are not exhaustive and do not limit the disclosure to the precise forms disclosed. DETAILED DESCRIPTION

[0013] As described above, multicast may refer to group communication in which a data transmission (ie, a multicast service) is simultaneously addressed to a group of interested receivers (eg, destination hosts / computers).

[0014] One multicast environment is a large-scale software-defined branch deployment. In a large-scale software-defined branch deployment, software-defined wide area network (SD-WAN) technology can be used to centrally manage an organization's wide area network (WAN) across multiple physical branch locations. SD-WAN technology, which is often implemented as a cloud-based management solution (e.g., HPE's Aruba SD-WAN), relies on virtualization, overlay networks, and on-site SD-WAN devices and software platforms to better manage network traffic (among other things).

[0015] However, existing multicast implementations for large-scale software-defined branch deployments have not yet taken advantage of the centralized management capabilities of SD-WAN technology. In particular, these implementations rely on a variation of the same traditional decentralized approach—protocol-independent multicast (PIM)—which has been widely used for Internet-based multicast for many years. Although simple to implement, the PIM-based approach does not optimize bandwidth consumption on the WAN for large-scale software-defined branch deployments. In particular, multicast traffic will be transmitted from all branch gateways across branches from the multicast source to a given branch via the WAN (as used herein, a gateway may refer to a network device that transmits traffic between a branch's local area network (LAN) and an organization's larger WAN, and branch gateways are typically multiple at a given branch for load balancing and redundancy purposes). In addition, because there is no central entity for coordination / coordination of routing between the multicast source and each branch, a PIM-based solution may be difficult to monitor and troubleshoot. In addition, due to the lack of centralized management, a large amount of multicast-related routing information must be broadcast to a large number of network devices (e.g., source VPNC, routers, gateways, etc.) involved in multicast transmission. As a result, PIM's decentralized and somewhat brute-force approach, sometimes referred to as "flood and prune," consumes significant and unnecessary WAN bandwidth. This is especially true in large-scale software-defined branch deployments that include multiple (sometimes many) gateways at each branch.

[0016] In this context, examples of the currently disclosed technology leverage the centralized management capabilities of SD-WAN technology to provide a new multicast implementation method that reduces WAN bandwidth consumption for large-scale software-defined branch deployments. In particular, a cloud-based multicast coordinator can be implemented as part of the SD-WAN package. Such a cloud-based multicast coordinator can coordinate the routing of multicast services between a multicast source (typically a data center) and the various branches of a large-scale software-defined branch deployment. As described below, such a cloud-based multicast coordinator can coordinate / calculate the routing of multicast services, thereby reducing WAN bandwidth consumption.

[0017] In addition to the cloud-based multicast coordinator, examples of the currently disclosed technology feature a gateway hierarchy designed to further reduce WAN bandwidth consumption. In particular, at a given branch, one gateway will be designated as the "leader" for a given multicast stream (here, the load can be balanced by assigning different "leaders" for different multicast streams / groups at a given branch). Other gateways at a given branch will be designated as "secondary gateways" for a given multicast stream. Therefore, only the gateway leader will (a) communicate with the cloud-based multicast coordinator; and (b) receive multicast services associated with a given multicast stream from the multicast source. With this architecture, WAN bandwidth consumption can be significantly reduced. For example, if a given branch has four gateways and at least one host / user is interested in a given multicast stream, the prior art will replicate the multicast stream to a given branch across four routes (where each route will terminate at one of the four gateways). In contrast, examples of the currently disclosed technology will utilize a cloud-based multicast coordinator to coordinate a single route from a multicast source to a gateway leader. Although the cloud-based multicast coordinator finds additional bandwidth savings / optimizations when calculating the routes, the mere fact of reducing the number of routes for multicast traffic from four to one saves a significant amount of WAN bandwidth.

[0018] As will be described in more detail below, the examples may also leverage existing SD-WAN services (e.g., container as a service offerings, routing compute engines, etc.) to enhance the multicast coordination described above. For example, a CaaS-type service that is typically included in an SD-WAN platform may be used to manage a cluster of gateways at each branch of a large-scale software-defined branch deployment. Similarly, CaaS may be used to manage a cluster of VPNCs at a multicast source. These VPNCs may act as nodes at a multicast source from which routing to gateway leaders may be coordinated. Thus, CaaS may communicate important multicast routing-related information to its neighbor in the SD-WAN platform, the multicast coordinator. CaaS may also make designations (e.g., gateway leader designations, assignment of VPNCs to multicast streams), which assists the architecture described herein.

[0019] Figure 1An example large-scale software-defined branch deployment according to various examples of the presently disclosed technology is depicted. Large-scale software-defined branch deployment 100 includes three branch / customer sites (branches 110, 120, and 130), SD-WAN 140, and multicast source 150. Services can be delivered between branches, SD-WAN 140, and multicast source 150 via wide area network (WAN) 160.

[0020] Multicast source 150 : Multicast source 150 may be any source of a multicast stream. In a common example, multicast source 150 would be a data center. As depicted in the example diagram, multicast stream 152 is behind two virtual private network clients (VPNCs): VPNC 154a and 154b.

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

[0022] exist Figure 1 In the example of FIG. 1 , only one multicast stream (i.e., multicast stream 152) is depicted in multicast source 150. However, in other examples, multicast source 150 can include any number of multicast streams. Similarly, in various examples, large-scale software-defined branch deployment 100 can include any number of multicast sources.

[0023] VPNC 154a and 154b : A given multicast stream can be associated with one VPNC. Generally speaking, a VPNC can refer to hardware used to connect to a software application of a virtual private network (VPN). As depicted, multicast source 150 includes two VPNCs: 154a and 154b. Together, these VPNCs can form a VPNC cluster. As will be described in more detail below, a container as a service (CaaS) application residing in SD-Wan 140 can manage this VPNC cluster. Management can include tasks such as configuring VPNCs, specifying which VPNC is associated with a given multicast stream, and the like.

[0024] As depicted, multicast stream 152 is associated with VPNC 154a. Thus, VPNC 154a may be used to transmit multicast traffic associated with multicast stream 152 to one or more of branches 110-130 (as coordinated by overlay multicast coordinator 142).

[0025] SD-WAN140 : SD-WAN 140 can be a cloud-based SD-WAN technology platform (e.g., HPE's Aruba SD-WAN) that includes centralized services capable of coordinating multicast-related services within a given WAN (e.g., WAN 160). In some examples, SD-WAN 140 can include additional centralized network management services.

[0026] Thus, resident within the SD-WAN 140 may be various sub-services. As depicted, the SD-WAN 140 includes an overlay multicast coordinator 142 and a container as a service (CaaS) 144.

[0027] Overlay Multicast Coordinator 142 : The overlay multicast coordinator 142 is a central management entity that coordinates the routing of multicast traffic between the multicast source 150 and the branches 110-130. To accomplish this task, the overlay multicast coordinator 142 should understand various aspects of the network topology / configuration, as well as the needs of the network hosts. Among other items, the overlay multicast coordinator 142 can also know (1) which branches are interested in a given multicast stream, (2) among the branches interested in a given multicast stream, which branch gateways have been designated as branch gateway leaders for the given multicast stream, and (3) which VPNC and / or multicast source location is associated with the given multicast stream. Following this information, the overlay multicast coordinator 142 can then coordinate routing between the appropriate VPNCs and branch gateway leaders in order to transmit multicast traffic to the interested hosts. As a central management entity incorporated in the SD-WAN 140, the overlay multicast coordinator 142 can collect this information and make these determinations in a manner that reduces WAN bandwidth consumption. In other words, the centralized decision making within the overlay multicast coordinator 142 greatly reduces the number of communications / decisions required to transmit multicast services in large-scale software-defined branch deployments. As described above, under the decentralized approach used by the prior art, most of the above information would be passed between the various nodes (e.g., routers, branch gateways, VPNCs) of the network responsible for transmitting multicast services.

[0028] So, how does the overlay multicast coordinator 142 obtain all of this information? As described below, the overlay multicast coordinator 142 may obtain certain network configuration / topology information from the CaaS 144 and information related to the needs of network hosts from designated branch gateway leaders.

[0029] CaaS144 : CaaS144 (i.e., another central management service located in SD-WAN 140) can manage various "containers / clusters" of the large-scale software-defined branch deployment 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. CaaS can include a container orchestration engine that runs and maintains the infrastructure between the organization's clusters. As described above, CaaS144 can manage a VPNC cluster that includes VPNCs154a and 154b. As part of its management responsibilities, CaaS144 can determine (or, at least know) which VPNC is associated with a given multicast stream. Therefore, CaaS144 can provide this information to the overlay multicast coordinator 142.

[0030] CaaS144 can also manage clusters associated with branch gateways, which can be referred to as BG clusters. In a given BG cluster, there will be one leader. As will be described in more detail below, only the leader of a given BG cluster will (a) send a request to join or leave a multicast group to the overlay multicast coordinator 142; and (b) receive multicast services from one of the VPNCs residing in the multicast stream source 150. In some examples, CaaS144 can determine (or at least know) which branch gateway of a given BG cluster is the leader of a given multicast stream / multicast group. In various examples, CaaS144 can balance the load by assigning different leaders to different multicast streams within the BG cluster - that is, one leader for multicast stream 152, another leader for different multicast streams, etc. CaaS144 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 of a given multicast stream. CaaS144 can pass all of this information to the overlay multicast coordinator 142 as needed.

[0031] Here, it may be noted that CaaS type services are typically included in SD-WAN services, such as SD-WAN 140. Why is this important? By leveraging existing cloud-based service infrastructure and features, examples of the presently disclosed technology may enhance multicast coordination services without consuming a large amount of additional WAN bandwidth, cloud resources, etc.

[0032] Overlay Multicast Coordinator 142 (Continued): As described above, from CaaS 144, overlay multicast coordinator 142 can obtain information associated with: (a) which VPNC and / or multicast source location is associated with a given multicast stream; and (b) which branch gateways have been designated as leaders for a given multicast stream. However, information related to which branches are interested in a given multicast stream is still missing. As described above, overlay multicast coordinator 142 can obtain this information from the branch gateway leader for a given multicast stream. In particular, overlay multicast coordinator 142 can receive a "join request" message from the branch gateway leader.

[0033] As described above, each branch will have a designated branch gateway leader for a given 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. Via mechanisms that will be described in more detail below, these branch gateway leaders can receive join requests from hosts or other branch gateways at their branches. If the branch gateway leader receives at least one join request for multicast stream 152, the branch gateway leader will send a join request message to the overlay multicast coordinator 142. The join request message can be sent to the overlay multicast coordinator 142 using various protocols such as Websocket, grpc, etc.

[0034] Overlay multicast coordinator 142 can now know (1) which branches are interested in a given multicast stream, (2) which branch gateways have been designated as leaders for the given multicast stream among the branches interested in the multicast stream, and (3) which VPNC and / or multicast source location is associated with the given multicast stream. Thus, overlay multicast coordinator 142 can coordinate routing between the appropriate VPNCs and branch gateway leaders for the given multicast stream. As an illustrative example, if hosts at branches 110, 120, and 130 are all interested in multicast stream 152, overlay multicast coordinator 142 can coordinate: one route between VPNC 154a and branch gateway 112a; one route between VPNC 154a and branch gateway 122a; and one route between VPNC 154a and branch gateway 132a.

[0035] In some examples, a routing calculation engine in overlay multicast coordinator 142 can calculate the routing of multicast traffic based on the above-mentioned source information (i.e., which VPNC is associated with a given multicast flow) and receiver information (which branch gateway is designated as the leader of a given multicast flow). In some of these examples, the routing calculation engine can learn to calculate the best route to reduce bandwidth consumption of WAN 160. For example, overlay multicast coordinator 142 can employ artificial intelligence (AI) or machine learning to determine the overlay tunnel of the multicast traffic between the VPNC and the branch gateway based on business needs and historical data.

[0036] In other examples, the overlay multicast coordinator 142 can leverage routes already calculated by the SD-WAN 140 (and / or its child services). Existing SD-WAN services typically calculate routes for unicast traffic between VPNCs and branch gateways. Thus, the overlay multicast coordinator 142 coordinator can coordinate multicast traffic over these pre-computed routes. By leveraging existing SD-WAN knowledge and services, the overlay multicast coordinator 142 can enhance its multicast coordination services without consuming significant additional WAN bandwidth, cloud resources, etc.

[0037] In some examples, the overlay multicast coordinator 142 can utilize the overlay network of the large-scale software-defined branch deployment 200 to route multicast traffic between the multicast source 150 and the branches 110-130. In a given network, the underlying layer (or, the underlying network) can refer to the physical connection of the network (e.g., Ethernet). In contrast, the overlay (or, the overlay network) can refer to a logical network that uses virtualization to establish a connection on top of the physical infrastructure of the network using tunnel encapsulation. In other words, an "overlay tunnel" can refer to a virtual link connecting network nodes. Here, the overlay tunnel can connect the VPNC with the branch gateway. Various protocols such as IPSec and GRE can be used to transmit network traffic through these overlay tunnels. In general, an SD-WAN architecture such as that depicted can rely on overlay tunnels to connect the various branches of its network with other nodes.

[0038] Branches 110, 120 and 130 : As used herein, a branch can refer to a physical location where one or more hosts (e.g., computers or other network devices associated with users) can connect to WAN 160. For example, a branch can be a remote office of an organization, a cafe / coffee shop, a home office, etc. Although only three branches are depicted in the example diagram, a large-scale software-defined branch deployment 100 can include any number of branches. In some examples, these can be branches of a specific organization. In other examples, branches may not all be associated with a single organization.

[0039] Although not depicted, each branch may have its own local area network (LAN). Various network devices (eg, hosts, branch gateways, routers, etc.) of a given branch may communicate with each other via the branch's LAN.

[0040] Host: A host can be a network device (e.g., a computer, tablet, smartphone, etc.) associated with a user located at a branch. A branch can have any number of hosts, but as depicted, each branch in the large-scale software-defined branch deployment 100 has two hosts. As described above, a host can be a receiver of a multicast service. 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. Thus, hosts 114a and 124b can receive multicast services associated with multicast stream 152 (the precise mechanism used to transmit multicast services to hosts 114a and 124b will be described in more detail below).

[0041] 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 given host can be connected to (i.e., "behind") one branch gateway (herein, any number of hosts can be behind a branch gateway). As described above, multiple branch gateways can be deployed at a branch for load balancing and redundancy purposes. Thus, a given host can connect to a given branch gateway based on factors such as path latency. As depicted, 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.

[0042] If the host is not yet a member of the multicast group, but is interested in joining, the host can send a message to the branch gateway behind it. In some examples, this can involve the host sending 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. Therefore, host 134b can send a join request message to branch gateway 132b. In some examples, the join request message can be sent using the IGMP protocol (i.e., an IGMP join request message). In some examples, the host can send an IGMP join request message to the branch gateway via the branch's LAN.

[0043] In the same / similar manner, if a host wants to leave a multicast group, the host can send a "leave request" message to the branch gateway behind it. For example, if host 114a wants to leave multicast group 224.0.0.10, host 114a can send a leave request message to branch gateway 112a.

[0044] Branch Gateway: A branch gateway may refer to a network device (hardware or software) that transmits traffic between a branch and other networks. For example, the branch gateway depicted in the example diagram may transmit traffic between WAN 160 and various network devices (e.g., other branch gateways, hosts, etc.) in its branches.

[0045] Each branch will typically have multiple branch gateways (which may be collectively referred to as BG clusters). However, for a given multicast stream, each BG cluster will have a branch gateway leader. As described above, CaaS144 can determine which branch gateway of a given BG cluster is the leader for a given multicast stream / multicast group. CaaS144 can also manage the configuration of the branch gateways for 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 a reminder of the above, the example significantly saves WAN bandwidth consumption by routing multicast traffic to a single "branch gateway leader" for each branch. This is in contrast to prior art (e.g., PIM), which replicates multicast traffic across all branch gateways for a given branch for large-scale software-defined branch deployments.

[0046] For multicast stream 152, branch gateways 112a, 122a, and 132a are branch gateway leaders of their respective BG clusters. Other branch gateways (ie, branch gateways 112b, 122b, and 132b) may be referred to as secondary branch gateways for multicast stream 152.

[0047] In the description above, the branch gateway leader will be the only branch gateway at the branch that (a) sends join / leave request messages to the overlay multicast coordinator 142 for the multicast stream 152 ; and (b) receives multicast traffic from the VPNC 154a associated with the multicast stream 152 .

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

[0049] Forwarding of Join / Leave Request Messages: When a secondary branch gateway receives a join / leave request message from a host, the secondary branch gateway may forward the message to the branch gateway leader. For example, if branch gateway 132b receives a message from host 134b requesting to join multicast group 224.0.0.10, branch gateway 132b may forward the message to branch gateway 132a (which may then pass the message to overlay multicast coordinator 142 as described above). In the same / similar manner, if branch gateway 122b receives a message from host 124b requesting to leave multicast group 224.0.0.10, branch gateway 122b may forward the message to branch gateway 122a. In some examples, message forwarding between branch gateways may be performed over the branch's LAN.

[0050] When a branch gateway leader receives a join / leave request message from a host, internal forwarding of the join / leave request message 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 will not need to forward the message to another branch gateway within branch 130. Instead, as the branch gateway leader, branch gateway 132a may pass the message directly to overlay multicast coordinator 142.

[0051] Forwarding of multicast services : When the branch gateway leader receives multicast traffic from VPNC 154a, the branch gateway may forward the multicast traffic to (a) an interested host behind the branch gateway leader, or (b) a secondary branch gateway in front of the interested host. For example, branch gateway 112a may receive multicast traffic associated with multicast stream 152 from VPNC 154a (as coordinated by overlay multicast coordinator 142). Both hosts 114a and 114b may be interested in multicast stream 152 (i.e., both of them may be members of multicast group 224.0.0.10). Therefore, branch gateway 112a may forward the multicast traffic directly to host 114a because host 114a is behind branch gateway 112a. Conversely, in order to forward the multicast traffic to host 114b, branch gateway 112a must forward the multicast traffic to branch gateway 112b because host 114b is behind branch gateway 112b.

[0052] Figure 2 is an example flow chart illustrating example operations that may be performed by a cloud-based multicast coordinator to coordinate multicast traffic within a large-scale software-defined branch deployment according to various examples. Figure 2 Accompanying, Figure 3 is an example system diagram illustrating components of a cloud-based multicast coordinator according to various examples.

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

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

[0055] The cloud-based multicast coordinator can be hardware or software that coordinates routing for multicast traffic between a source of a multicast stream and a branch gateway leader. In some examples, the cloud-based multicast coordinator can be implemented as part of an SD-WAN service (e.g., HPE's Aruba SD-WAN) that manages the WAN of which the first customer site is a part.

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

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

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

[0059] A branch gateway may refer to a network device (hardware or software) that transmits traffic between a customer site and other networks. In the description above, the first customer site may include multiple branch gateways. However, for a multicast stream, there will be one branch gateway leader at the first customer site. The branch gateway leader at the first customer site will be the only branch gateway at the first customer site that (a) sends a message to the cloud-based multicast coordinator that one or more hosts at the first customer site are interested in joining the multicast stream; and (b) receives multicast traffic associated with the multicast stream from the VPNC associated with the multicast stream / multicast stream source.

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

[0061] In the above description, the first customer site can be one of multiple customer sites connected via a WAN in a large-scale software-defined branch deployment, and the cloud-based multicast coordinator can be implemented as part of the SD-WAN platform that manages the WAN. Therefore, the cloud-based multicast coordinator can receive a message via the WAN that one or more hosts at the first customer site are interested in joining the multicast stream. The message itself can be sent using various protocols such as Websocket, grpc, etc.

[0062] At step 204, the cloud-based multicast coordinator can coordinate a route for transmitting the multicast flow between the VPNC associated with the multicast flow and the branch gateway leader at the first customer site. In various examples, this step can be performed by the multicast routing coordination component 304 of the multicast coordinator 300.

[0063] A VPNC may refer to hardware for connecting a software application of a virtual private network (VPN). Here, a VPNC associated with a multicast stream may be used to connect a source of the multicast stream (e.g., a data center) with a branch gateway leader at a first customer site. Thus, multicast traffic associated with the multicast stream may be transmitted over the connection. In some examples, the VPNC associated with the multicast stream may be located at the source of the multicast stream.

[0064] In some examples, the cloud-based multicast coordinator 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 coordinator can learn to calculate routes that reduce bandwidth consumption of the WAN network. In various examples, the cloud-based multicast coordinator can use artificial intelligence (AI) or machine learning to calculate routes that reduce WAN bandwidth consumption. Once calculated, the cloud-based multicast coordinator can coordinate multicast traffic through these routes.

[0065] In other examples, the cloud-based multicast coordinator can leverage routes that have already been calculated by the SD-WAN service of which the cloud-based multicast coordinator is a part. As described above, existing SD-WAN services typically calculate routes for unicast traffic between VPNCs and branch gateways. Therefore, the cloud-based multicast coordinator can determine to coordinate multicast traffic through these pre-calculated routes. By leveraging existing SD-WAN knowledge and services, the cloud-based multicast coordinator can enhance its multicast coordination services without consuming a large amount of additional WAN bandwidth, cloud resources, etc.

[0066] In some examples, a cloud-based multicast coordinator can leverage an overlay network of a WAN when coordinating the routing of multicast traffic. In a given network, the underlying layer (or, underlying network) can refer to the physical connection of the network (e.g., Ethernet). In contrast, an overlay (or, overlay network) can refer to a logical network that uses virtualization to establish a connection on top of the physical infrastructure of the network using tunnel encapsulation. In other words, an "overlay tunnel" can refer to a virtual link connecting network nodes. Here, an overlay tunnel can connect a VPNC to a branch gateway. Various protocols such as IPSec and GRE can be used to transmit network traffic through these overlay tunnels. In general, SD-WAN technology, in which a cloud-based multicast coordinator can be incorporated, typically uses overlay network tunnels to connect the various branches of its WAN to other nodes.

[0067] If you will Figure 4-Figure 7 As described in conjunction, once the multicast traffic has been transmitted to the branch gateway leader via routing coordinated by the cloud-based multicast coordinator, the multicast traffic can be forwarded to various hosts interested in the multicast.

[0068] As an additional note, in various examples, the cloud-based multicast coordinator can also receive join request messages from branch gateway leaders at other customer sites (e.g., a second customer site). Thus, in the same / similar manner as compared to that described above, the cloud-based multicast coordinator can coordinate the routing for transmitting multicast traffic to these branch gateway leaders at other customer sites.

[0069] Figure 4 is an example flow chart illustrating example operations that may be performed by a branch gateway leader at a customer site to reduce WAN bandwidth consumption for multicast transmissions in a large-scale software-defined branch deployment according to various examples. Figure 4 Accompanying, Figure 5 is an example system diagram illustrating components of a branch gateway leader according to various examples.

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

[0071] As Figure 2-Figure 3 In conjunction with the description, the customer site can be one of multiple customer sites connected via a WAN that constitute a large-scale software-defined branch deployment. In a large-scale software-defined branch deployment, SD-WAN technology can be used to manage the WAN across multiple customer sites. In many examples, SD-WAN technology is implemented as a cloud-based service.

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

[0073] A branch gateway may refer to a network device (hardware or software) that transmits traffic between a customer site and other networks. As described above, a customer site may include multiple branch gateways. However, for multicast flows, there will be one branch gateway leader at the customer site. The branch gateway leader will be the only branch gateway at the customer site that (a) sends a message to the cloud-based multicast coordinator that one or more hosts at the customer site are interested in joining the multicast flow; and (b) receives multicast traffic associated with the multicast flow from the VPNC associated with the multicast flow.

[0074] Some of the branch gateways at the customer site will be secondary branch gateways (i.e., branch gateways that are not leaders). Like the branch gateway leader, the secondary branch gateway can receive requests to join or leave the multicast group / stream from one or more hosts at the customer site (here, a given host can be connected to the secondary branch gateway for path latency / load balancing purposes). Similarly, both the branch gateway leader 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 leader (a) sends a message to the cloud-based multicast coordinator that one or more hosts at the customer site are interested in joining the multicast stream; and (b) receives multicast traffic associated with the multicast stream from the VPNC - internal forwarding of join / leave requests and multicast traffic between the branch gateways at the customer site may be required.

[0075] To this end, the 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 joining the multicast stream.

[0076] As described above, various network devices (eg, branch gateways, hosts, routers, etc.) at a customer site may be connected via a local area network (LAN). Therefore, communication between branch gateways at a customer site may be performed via the LAN at the customer site using various protocols.

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

[0078] As Figure 2-Figure 3 In conjunction with the description, a cloud-based multicast coordinator can be hardware or software that coordinates routing for multicast traffic between sources of multicast streams and branch gateway leaders. In some examples, the cloud-based multicast coordinator can be implemented as part of an SD-WAN service (e.g., HPE's Aruba SD-WAN) that manages the WAN of which the customer site is a part.

[0079] Thus, communication between the branch gateway leader and the cloud-based multicast coordinator can be carried out over the WAN / large-scale software-defined branch deployment of which the customer site is a part. Communication between the branch gateway leader and the cloud-based multicast coordinator can be sent using various protocols such as Websocket, grpc, etc.

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

[0081] As Figure 2-Figure 3 In conjunction with the description, VPNC may refer to hardware used to connect to a software application of a virtual private network (VPN). Here, a VPNC associated with a multicast stream may be used to connect the source of the multicast stream to a branch gateway leader. Thus, the multicast service associated with the multicast stream may be transmitted via the connection / route.

[0082] In some examples, routing between VPNC and branch gateway leaders can be implemented using an overlay network of a WAN / large-scale software-defined branch deployment. As described above, an overlay (or, overlay network) can refer to a logical network that uses virtualization to establish connections on top of the physical infrastructure of a network using tunnel encapsulation. In other words, an "overlay tunnel" can refer to a virtual link that connects network nodes. Here, an overlay tunnel can connect the VPNC to the branch gateway. Various protocols such as IPSec and GRE can be used to transmit network services through these overlay tunnels. In general, SD-WAN technology, which can incorporate a cloud-based multicast coordinator, typically uses overlay network tunnels to connect the various branches of its WAN with other nodes.

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

[0084] As described above, because some hosts interested in the multicast stream may be connected to (i.e., behind) a secondary branch gateway, internal forwarding of multicast traffic may be required between branch gateways at the customer site. For this reason, 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. Thus, once the secondary branch gateways receive the forwarded multicast traffic, they may forward the multicast traffic to the interested hosts to which they are connected.

[0085] As described above, communications between branch gateways may occur over the LAN at the customer site using a variety of protocols.

[0086] In various examples, the branch gateway leader can receive a request to join a multicast stream directly from a given host. In this case, no internal forwarding of the join request of the given host is required between branch gateways, because the branch gateway leader can pass the join request of the given host directly to the cloud-based multicast coordinator. Similarly, when the branch gateway leader receives traffic associated with the multicast stream from the VPNC, the branch gateway leader can forward the multicast traffic directly to the given host.

[0087] Figure 6 is an example flow chart illustrating example operations that may be performed by a secondary branch gateway at a customer site to reduce WAN bandwidth consumption for multicast transmissions in a large-scale software-defined branch deployment according to various examples. Figure 6 Accompanying, Figure 7 is an example system diagram illustrating components of a secondary branch gateway according to various examples.

[0088] At step 602, the secondary branch gateway can receive one or more requests to join a multicast stream from one or more hosts at a customer site. In various examples, step 602 can be performed by a multicast join request receiving component 702 of the secondary branch gateway 700.

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

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

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

[0092] If a host is interested in a multicast stream / group, but is not yet a member of the multicast stream / group, the host may send a message to a branch gateway located at a customer site. A given host may be connected to (i.e., behind) a particular branch gateway (here, any number of hosts may be behind a given branch gateway). As described above, multiple branch gateways may be deployed at a customer site for load balancing and redundancy purposes. Thus, a given host may be connected to a given branch gateway based on factors such as path delay.

[0093] In some examples, the Internet Group Management Protocol (IGMP) protocol (i.e., IGMP Join Request message) can be used to send the host's request to join the multicast stream to the branch gateway. In some examples, the host can send the IGMP Join Request message to the branch gateway through the branch's LAN.

[0094] A branch gateway may refer to a network device (hardware or software) that transmits traffic between a customer site and other networks. As described above, a customer site may include multiple branch gateways. However, for multicast flows, there will be one branch gateway leader at the customer site. The branch gateway leader will be the only branch gateway at the customer site that (a) sends messages to the cloud-based multicast coordinator; and (b) receives multicast traffic associated with the multicast flow from the VPNC.

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

[0096] To this end, at step 604, the secondary branch gateway can forward one or more requests to join the multicast stream to the branch gateway leader. As described above, communication between branch gateways can be performed over the LAN of the customer site using various protocols. In various examples, step 604 can be performed by the multicast join request forwarding component 704 of the secondary branch gateway 700.

[0097] At step 606, the secondary branch gateway can receive traffic associated with the multicast flow from the branch gateway leader. In various examples, step 604 can be performed by a multicast traffic receiving component 706 of the secondary branch gateway 700.

[0098] As described above, because some hosts interested in the multicast stream may be behind secondary branch gateways, internal forwarding of multicast traffic may be required between branch gateways at the customer site. For this reason, 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 may forward the multicast traffic to the hosts to which they are connected.

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

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

[0101] Figure 8 A block diagram of an example computer system 800 is depicted in which various embodiments described herein may be implemented. The computer system 800 includes a bus 802 or other communication mechanism for communicating information, one or more hardware processors 804 coupled to the bus 802 for processing information. The hardware processor(s) 804 may be, for example, one or more general purpose microprocessors.

[0102] The computer system 800 also includes a main memory 806, such as a random access memory (RAM), cache, and / or other dynamic storage device, coupled to the bus 802 for storing information and instructions to be executed by the processor 804. The memory 806 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 804. Such instructions, when stored in a storage medium accessible to the processor 804, present the computer system 800 as a special-purpose machine that is customized to perform the operations specified in the instructions.

[0103] The computer system 800 also includes a read only memory (ROM) 808 or other static storage device coupled to the bus 802 for storing static information and instructions for the processor 804. A storage device 810 such as a magnetic disk, optical disk, or USB thumb drive (flash drive) is provided and coupled to the bus 802 for storing information and instructions.

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

[0105] The computing system 800 may include a user interface module to implement a GUI, which may be stored in a mass storage device as executable software code executed by the computing device(s). As examples, this module and other modules may include components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuit systems, data, databases, data structures, tables, arrays, and variables.

[0106] In general, as used herein, the terms "component", "engine", "system", "database", "data store", etc. may refer to logic embodied in hardware or firmware, or to a set of software instructions, possibly with entry and exit points, written in a programming language, such as the following, for example, Java, C or C++. Software components may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as the following (e.g., BASIC, Perl or Python, etc.). It should be understood that software components may be called from other components or themselves, and / or may be called in response to detected events or interrupts. Software components configured for execution on a computing device may be provided on a computer-readable medium, such as a compact disc, digital video disc, flash drive, disk, or any other tangible medium, or as a digital download (and may be initially stored in a compressed or installable format that requires installation, decompression or decryption prior to execution). Such software code may be stored in part or in whole on a memory device of an executing computing device for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will also be understood that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0107] The computer system 800 may implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, enables or programs the computer system 800 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 800 in response to the processor(s) 804 executing one or more sequences of one or more instructions contained in the main memory 806. These instructions may be read into the main memory 806 from another storage medium, such as the storage device 810. Execution of the sequences of instructions contained in the main memory 806 causes the processor(s) 804 to perform the processing steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0108] As used herein, the term "non-transitory medium" and similar terms refer to any medium 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 include, for example, optical or magnetic disks, such as storage device 810. Volatile media include 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 tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with hole patterns, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cartridges, and networked versions thereof.

[0109] Non-transient media are distinct from transmission media but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between non-transient media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0110] Computer system 800 also includes a communication interface 818 coupled to bus 802. Network interface 818 provides a two-way data communication coupled to one or more network links connected to one or more local networks. For example, communication interface 818 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem for providing a data communication connection with a telephone line of a corresponding type. As another example, network interface 818 can be a local area network (LAN) card for providing a data communication connection to a compatible LAN (or, with a WAN component of a WAN communication). Wireless links can also be implemented. In any such implementation, network interface 818 sends and receives an electrical, electromagnetic or optical signal carrying a digital data stream representing various types of information.

[0111] A network link typically provides data communication to other data devices through one or more networks. For example, a network link may provide a connection to a host or data device operated by an Internet Service Provider (ISP) through a local network. The ISP, in turn, provides data communication services through the global packet data communication network now commonly referred to as the "Internet." Both the local network and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link through the communication interface 818 (which carry digital data in and out of the computer system 800) are example forms of transmission media.

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

[0113] The received code may be executed by processor 804 as it is received, and / or stored in storage device 810 or other non-volatile storage for later execution.

[0114] Each of the processes, methods, and algorithms described in the previous sections may be embodied in a code component executed by one or more computer systems or computer processors including computer hardware, and fully or partially automated by it. One or more computer systems or computer processors may also operate to support the execution of related operations in a "cloud computing" environment or as "software as a service" (SaaS). The processes and algorithms may be implemented in part or in whole in a dedicated circuit system. The various features and processes described above may be used independently of each other, or may be used in combination in various ways. Different combinations and sub-combinations are intended to fall within the scope of the present disclosure, and certain methods 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 blocks or states associated therewith may be executed in other appropriate orders, or may be executed in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The execution of certain operations or processes may be distributed between computer systems or computer processors, not only residing in a single machine, but deployed on multiple machines.

[0115] As used herein, any form of hardware, software or combination thereof may be utilized to implement the circuit. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines or other mechanisms may be implemented to form the circuit. In implementation, the various circuits described herein may be implemented as discrete circuits, or the described functions and features may be partially or completely shared between one or more circuits. Even if the various features or elements of the functions may be described or claimed as separate circuits alone, these features and functions may also be shared between one or more common circuits, and this description should not require or imply that separate circuits are needed to implement these features or functions. In the case where the circuit is implemented in whole or in part using software, such software may be implemented to operate together with a computing or processing system (such as, computer system 800) that can perform the functions described therein.

[0116] As used herein, the term "or" may be interpreted as inclusive or exclusive. In addition, descriptions of resources, operations, or structures in the singular should not be interpreted as excluding the plural. Unless otherwise expressly stated, or otherwise understood in the context of use, conditional language such as "may," "could," "might," or "might" is generally intended to convey that certain embodiments include and other embodiments do not include certain features, elements, and / or steps.

[0117] Unless expressly stated otherwise, the terms and phrases used in this document and variations thereof should be interpreted as open ended and not limiting. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to a given time period or to items available as of a given time, but should be understood to include conventional, traditional, normal, or standard technology that may be available or known at any time now or in the future. In some cases, the presence of phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be understood to indicate that a narrower use is intended or required where such broadening words may not be present.

[0118] It should be noted that the terms "optimize," "optimal," and the like as used herein may be used to refer to making or achieving as efficient or perfect a performance as possible. However, as one of ordinary skill in the art reading this document will recognize, perfection is not always achieved. Thus, these terms may also include making or achieving the best or most efficient or practical performance possible under given circumstances, or making or achieving better performance than could be achieved using other settings or parameters.

Claims

1. A branch gateway leader at a customer site, comprising: at least one processor; as well as A memory storing instructions, wherein when the instructions are executed by the at least one processor, the branch gateway leader executes a method, the method comprising: receiving 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 joining the multicast stream, wherein the leader branch gateway and each secondary branch gateway connect the customer site to an external network; sending a message to a cloud-based multicast coordinator that facilitates multicast routing to the customer site that the one or more hosts at the customer site are interested in joining the multicast stream; receiving traffic associated with the multicast stream from a virtual private network client VPNC associated with the multicast stream, wherein the VPNC couples the customer site to a source of the multicast stream; and forwarding the traffic associated with the multicast stream to the one or more secondary branch gateways at the customer site; in: The customer site is one of a plurality of customer sites connected via a wide area network (WAN) in a large-scale software-defined SD-branch deployment; The cloud-based multicast coordinator facilitates multicast routing to the SD branch deployment; The WAN includes a physical network and a virtual overlay network built on the physical network; and The branch gateway leader receives the traffic associated with the multicast flow from the VPNC via an overlay tunnel of the virtual overlay network.

2. The branch gateway leader according to claim 1, wherein the method further comprises: receiving a message from a given host at the client site other than the one or more hosts that the given host is interested in joining the multicast stream; as well as The traffic associated with the multicast flow is forwarded to the given host.

3. The branch gateway leader of claim 2, wherein the given host is coupled to the branch gateway leader rather than to one of the one or more secondary branch gateways.

4. The branch gateway leader according to claim 1, wherein: The branch gateway leader and the one or more secondary branch gateways of the customer site are in a local area network LAN; and The branch gateway leader receives the one or more messages via the LAN.

5. The branch gateway leader according to claim 4, wherein: The branch gateway leads and a given host other than the one or more hosts is connected via the LAN; and The branch gateway leader receives a message from the given host via 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 Internet Group Management Protocol (IGMP) protocol.

7. The branch gateway leader according to claim 1, wherein the method further comprises: A route for transmitting the multicast flow between the VPNC and the branch gateway leader is received by the branch gateway leader, wherein the route is coordinated at the cloud-based multicast coordinator.

8. A method for network management, comprising: receiving, by a branch gateway leader, one or more messages from one or more secondary branch gateways at a customer site that one or more hosts at the customer site are interested in joining a multicast stream, wherein the branch gateway leader and each secondary branch gateway connect the customer site to an external network; sending a message to a cloud-based multicast coordinator that facilitates multicast routing to the customer site that the one or more hosts at the customer site are interested in joining the multicast stream; receiving traffic associated with the multicast stream from a virtual private network client VPNC associated with the multicast stream, wherein the VPNC couples the client site to a source of the multicast stream; as well as 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 coupled to the branch gateway leader and not to one of the one or more secondary branch gateways; as well as The traffic associated with the multicast flow is forwarded to the given host.

9. The method of claim 8, wherein the customer site is one of a plurality of customer sites connected via a wide area network (WAN) in a large-scale software-defined (SD)-branch deployment, and wherein the cloud-based multicast coordinator facilitates multicast routing to the SD-branch deployment.

10. The method according to claim 9, wherein: The WAN includes a physical network and a virtual overlay network built on the physical network; and The branch gateway leader receives the traffic associated with the multicast flow from the VPNC via an overlay tunnel of the virtual overlay network.

11. The method according to claim 8, wherein: The branch gateway leader and the one or more secondary branch gateways of the customer site are in a local area network LAN; and The branch gateway leader receives the one or more messages via the LAN.

12. The method according to claim 11, wherein: The branch gateway leads and the given host different from the one or more hosts is connected via the LAN; and The branch gateway leader receives a message from the given host via 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 the Internet Group Management Protocol (IGMP) protocol.

14. The method according to claim 8, further comprising: A route for transmitting the multicast flow between the VPNC and the branch gateway leader is received by the branch gateway leader, wherein the route is coordinated at the cloud-based multicast coordinator.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by at least one processor, cause a branch gateway leader at a customer site to perform a method comprising: receiving 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 joining a multicast stream, wherein the branch gateway leader and each secondary branch gateway connect the customer site to an external network; sending a message to a cloud-based multicast coordinator that facilitates multicast routing to the customer site that the one or more hosts at the customer site are interested in joining the multicast stream; receiving traffic associated with the multicast stream from a virtual private network client VPNC associated with the multicast stream, wherein the VPNC couples the client site to a source of the multicast stream; 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 coupled to the branch gateway leader and not to one of the one or more secondary branch gateways; as well as The traffic associated with the multicast flow is forwarded to the given host.

Images