Abstract: A system for multicast traffic management in an overlay tunnel fabric is provided. The system can operate a first switch and a second switch of the fabric as part of a virtual switch. The virtual switch can operate as a gateway for the fabric. The system can efficiently deploy a rendezvous point (RP) for a multicast group at the first switch. During operation, the system can determine whether to synchronize a registration packet associated with the multicast group with the second switch based on a type of a first ingress connection associated with the registration packet. The system can then determine whether to receive subsequent registration packets for the multicast group based on the type of the first ingress connection and reception of a join request for the multicast group. The type of a respective connection indicates whether the connection includes an overlay tunnel.

Abstract: One aspect of the instant application facilitates reduction of multicast group join latency. During operation, the system can receive, at a network device, a first multicast group leave packet corresponding to a first multicast group. In response to receiving a first multicast group leave packet from an IPTV client, the system can simulate a second multicast group join on behalf of the IPTV client by updating, based on a predictive model, at least an entry in a table maintained in hardware with a next likely multicast group that the IPTV client is likely to join; and sending a simulated second multicast group join packet for initiating an IPTV stream associated with the next likely multicast group. In response to receiving an actual second multicast group join packet from the IPTV client, the system can facilitate the IPTV stream to the IPTV client, thereby reducing multicast group join latency.

Abstract: A system for multicast packet management in a first switch in an overlay tunnel fabric is provided. The system can operate the first switch as part of a virtual switch in conjunction with a second switch of the fabric. The virtual switch can operate as a gateway for the fabric. During operation, the system can receive a join request for a multicast group. The system can then determine whether to forward the join request to the second switch based on a type of a first ingress connection of the join request. Upon receiving a data packet for the multicast group, the system can determine how to forward the data packet based on respective types of a second ingress connection and an egress connection of the data packet. The type of a respective connection can indicate whether the connection includes an overlay tunnel.

Abstract: A system that can facilitate multicast forwarding via overlay multicast tunnels in a network is provided. The system can operate as a tunnel endpoint and form a first overlay tunnel with a peer tunnel endpoint. During operation, the system can receive a join request for a multicast group via the first overlay tunnel. The system can identify a local port of the system associated with the multicast group indicated by the join request. The system can then include the first overlay tunnel in a set of forwarding tunnels for multicast traffic of the multicast group based on the join request. Subsequently, the system can forward the multicast traffic of the multicast group received from a local port via the set of forwarding tunnels, thereby limiting forwarding of the multicast traffic to tunnel endpoints associated with the multicast group.

Abstract: One aspect of the instant application facilitates reduction of multicast group join latency. During operation, the system can receive, at a network device, a first multicast group leave packet corresponding to a first multicast group. In response to receiving a first multicast group leave packet from an IPTV client, the system can simulate a second multicast group join on behalf of the IPTV client by updating, based on a predictive model, at least an entry in a table maintained in hardware with a next likely multicast group that the IPTV client is likely to join; and sending a simulated second multicast group join packet for initiating an IPTV stream associated with the next likely multicast group. In response to receiving an actual second multicast group join packet from the IPTV client, the system can facilitate the IPTV stream to the IPTV client, thereby reducing multicast group join latency.

Abstract: A system for multicast traffic management in an overlay tunnel fabric is provided. The system can operate a first switch and a second switch of the fabric as part of a virtual switch. The virtual switch can operate as a gateway for the fabric. The system can efficiently deploy a rendezvous point (RP) for a multicast group at the first switch. During operation, the system can determine whether to synchronize a registration packet associated with the multicast group with the second switch based on a type of a first ingress connection associated with the registration packet. The system can then determine whether to receive subsequent registration packets for the multicast group based on the type of the first ingress connection and reception of a join request for the multicast group. The type of a respective connection indicates whether the connection includes an overlay tunnel.

Abstract: A system for multicast packet management in a first switch in an overlay tunnel fabric is provided. The system can operate the first switch as part of a virtual switch in conjunction with a second switch of the fabric. The virtual switch can operate as a gateway for the fabric. During operation, the system can receive a join request for a multicast group. The system can then determine whether to forward the join request to the second switch based on a type of a first ingress connection of the join request. Upon receiving a data packet for the multicast group, the system can determine how to forward the data packet based on respective types of a second ingress connection and an egress connection of the data packet. The type of a respective connection can indicate whether the connection includes an overlay tunnel.

Abstract: Some examples relate to selection of a rendezvous point in an IP multicast network managing multicast group traffic. An example includes transmitting, from a controller in a cloud computing system, messages to a source device and a host device in an IP multicast-capable network, which may include two peer network devices that are virtualized to function as one virtual device. Based on the response to the messages, the controller may determine that the source device is present in OSI layer 3 and the host device is present in OSI layer 2. The controller may determine that the peer network are located downstream in relation to the determined layer of the source device. The controller may select a non-peer network device as a rendezvous point in the IP multicast-capable network. Further to the selection, the controller may synchronize an active-active configuration between the peer network devices.

Abstract: Systems are methods are described for predicting and forecasting a resource utilization on network device, particularly for handling multicast flows, by monitoring past resource consumption patterns. A system can include a plurality of multicast clients coupled to a network; and a network device coupled to the network. The network device may be a switch or a router that directs multicast traffic to the plurality of multicast clients. The network device can include a flow prediction controller that determines one or more real-time predictions relating to a demand of the network based on an analysis of an artificial intelligence (AI) forecasting model, such as an Autoregressive Integrated Moving Average (ARIMA) model. Also, the network device can include a resource optimizer that performs a resource management action that optimizes the resources of the network device based on the one or more real-time predictions of the demand of the network and a policy.

Abstract: Some examples relate to selection of a rendezvous point in an IP multicast network managing multicast group traffic. An example includes transmitting, from a controller in a cloud computing system, messages to a source device and a host device in an IP multicast-capable network, which may include two peer network devices that are virtualized to function as one virtual device. Based on the response to the messages, the controller may determine that the source device is present in OSI layer 3 and the host device is present in OSI layer 2. The controller may determine that the peer network are located downstream in relation to the determined layer of the source device. The controller may select a non-peer network device as a rendezvous point in the IP multicast-capable network. Further to the selection, the controller may synchronize an active-active configuration between the peer network devices.

Abstract: A system that can facilitate multicast forwarding via overlay multicast tunnels in a network is provided. The system can operate as a tunnel endpoint and form a first overlay tunnel with a peer tunnel endpoint. During operation, the system can receive a join request for a multicast group via the first overlay tunnel. The system can identify a local port of the system associated with the multicast group indicated by the join request. The system can then include the first overlay tunnel in a set of forwarding tunnels for multicast traffic of the multicast group based on the join request. Subsequently, the system can forward the multicast traffic of the multicast group received from a local port via the set of forwarding tunnels, thereby limiting forwarding of the multicast traffic to tunnel endpoints associated with the multicast group.

Abstract: Examples herein are directed to centralized database based multicast converging. For instance, in various examples centralized database based multicast converging can include starting a restart timer having a value greater than a time to validate stored entries in a centralized database, sending data packets at least to hosts on the network corresponding to the stored entries in the centralized database to maintain service to the hosts while the restart timer is running, sending query packets to validate a host corresponding to an entry of the stored entries in the centralized database, and responsive to the restart timer expiring, sending data packets to a converged group of hosts including at least the validated host.

Abstract: Examples herein are directed to centralized database based multicast converging. For instance, in various examples centralized database based multicast converging can include starting a restart timer having a value greater than a time to validate stored entries in a centralized database, sending data packets at least to hosts on the network corresponding to the stored entries in the centralized database to maintain service to the hosts while the restart timer is running, sending query packets to validate a host corresponding to an entry of the stored entries in the centralized database, and responsive to the restart timer expiring, sending data packets to a converged group of hosts including at least the validated host.