Hewlett Packard Enterprise Development LP

Chethan Chavadibagilu Radhakrishnabhat

Tathagata Nandy

Subramanian Muthukumar

Priyam De

Venkatavaradhan Devarajan

Balaji Sankaran

Thomas Samuel

Subramanian Muthumukar

A multicast tracing system for a network is provided. During operation, the system can identify, at a network device in the network, a join request and a data packet of a multicast group received at the network device. The system can determine respective timestamps indicating the arrival and departure of the join request and the data packet. The system can then determine, based on the timestamps, at least a local latency incurred by the data packet at the network device and a network latency incurred by the data packet in the network. Subsequently, the system can receive a multicast trace (mtrace) request for the multicast group. The system can incorporate the local latency and the network latency into the mtrace request. Upon identifying an upstream network device in a multicast path associated with the multicast group, the system can forward the mtrace request to the upstream network device.

Enhanced multicast tracing with latency detection

A programmed network device and corresponding method are provided for rebuilding a multicast state upon experiencing a failure in a network using a protocol independent multicast (PIM) protocol. The method includes receiving updates to an outgoing list (Olist) for a given multicast route (mroute) at the network component and updating a PIM cache Olist in the network component with the received updates. During a state of recovering from the failure, the method includes determining whether the PIM cache Olist matches a centralized database Olist located in a centralized database. When a match is found, the method includes publishing an mroute state from the PIM cache to the centralized database.

Nonstop forwarding for routed multicast traffic

A system for providing fast multicast convergence for Precision Time Protocol (PTP) at a switch is provided. During operation, the system can receive a multicast control message based on a multicast protocol used for PTP from a respective neighbor switch. The multicast control message can indicate neighbor information associated with the multicast protocol. The system can then determine a role associated with the PTP for a remote switch from the control message. Upon receiving a register message for a multicast group associated with the PTP, the system can determine whether a multicast path from the switch to a PTP source includes a device with a role of a boundary clock (BC) of PTP. If the multicast path includes a device with a role of a BC, the system can send a gratuitous register-stop message for the multicast group toward the PTP source in absence of a native path.

Fast multicast convergence for time synchronization in a network

A system for efficient multicast control packet forwarding is provided. During operation, the system can maintain a first tunnel between a first switch and a second switch in an overlay tunnel fabric. The encapsulation of a packet sent via the overlay tunnel fabric is initiated and terminated within the overlay tunnel fabric. The system can maintain a second tunnel between the first switch and a third switch, which can be in an external network that excludes the first and second switches. The switch can distinguish the first and second tunnels as intra-fabric and inter-fabric tunnels, respectively. Upon receiving a multicast control packet via the first tunnel, the system can identify the second tunnel as the inter-fabric tunnel and forward the multicast control packet via the second tunnel. Here, a respective multicast control packet received from the first tunnel can be precluded from being forwarded on intra-fabric tunnels.

Efficient multicast packet forwarding in a distributed tunnel fabric

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.

Multicast rendezvous point deployment in a virtual gateway of a distributed tunnel fabric

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.

Reducing multicast join latency for IPTV streams

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.

Multicast packet management for a virtual gateway of a distributed tunnel fabric

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.

Method and system for facilitating efficient multicast forwarding over tunnels

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.

Selecting a rendezvous point in an IP multicast-capable network

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.

Growing community of inventors

Bengaluru, India

Chethan Chavadibagilu Radhakrishnabhat