Multicast

VOS Edge Nodes Configured to use a Static Rendezvous Point

In this use case, a customer deploys Versa Operating System™ (VOS™) SD-WAN nodes in multiple retail locations to provide application-aware connectivity over multiple access links. The network includes multiple hubs, with each hub serving a subset of spoke sites. The spoke sites that are served by a hub are in a full-mesh topology, as illustrated below.

The customer has an application that is used to distribute videos to their employees, and uses multicast to efficiently transmit the videos across the network to hundreds of sites. 

The SD-WAN network is shared by unicast applications and multicast applications. The unicast and multicast applications have very different requirements from the network. A mesh topology between the sites is very important for unicast applications that are sensitive to delays. For multicast applications, a hub-and-spoke model makes efficient use of the unequal number of resources that are available at VOS hub nodes and VOS spoke nodes.

The customer chose to deploy a partial-mesh topology for unicast applications and a hub-and-spoke topology for multicast deployments. The Versa Networks multicast solution allows the customer to configure the same CPE with different topologies for multicast and unicast application traffic using MP-BGP to propogate unicast routes (IPv4, IPv6, VPNv4, VPNv6), as well as routes to multicast source-subnets (multicast IPv4, multicast IPv6, and multicast VPNv4).  This way, the unicast topology can be both full-mesh or partial-mesh, and the multicast topology can be hub-and-spoke.

The customer has deployed a multicast network using PIM sparse mode (PIM-SM). The rendezvous point (RP) is configured behind one of the hub devices, and a set of sites (up to 128) are associated with each hub. The hubs themselves are connected in full-mesh topology for multicast traffic. 

The client on the branch site initiates a group membership request towards an SD-WAN edge device. The SD-WAN devices are configured with a static RP for the group. The PIM-SM protocol ensures that the routing topology is formed from the RP towards the spoke in order to route the multicast data successfully towards the client. In the topology shown above, the receiver host triggers an IGMP request towards Spoke1. The PIM join (*,G) traverses the following path: Spoke1 > Hub2 > Hub1 > RP. The data flows from the RP toward the receiver host behind Spoke1 using the path RP > Hub1 > Hub2 > Spoke1 receiver.

Multicast Using SD-WAN as Overlay and Underlay

In a deployment at a large oil and gas producer, the customer has a working solution for multicast over an MPLS network, and has deployed SD-WAN to connect unicast applications over public access. The customer wants to take advantage of the access-independent nature of SD-WAN and allow the multicast traffic to be routed over public access to serve the sites without MPLS connectivity.

The Versa Networks multicast solution works in conjunction with legacy PE routers to provide routing capability for multicast applications using the MPLS core. Simultaneously, for branches without MPLS connectivity (or during the service degradation of MPLS), the branches can receive the multicast traffic over the SD-WAN overlay. This is achieved by prioritizing underlay-transport routes more than SD-WAN-overlay routes to multicast source subnets when a multicast-capable underlay is available.

For the branches with MPLS connectivity, the routes with that can reach the multicast addresses using the MPLS underlay are given higher priority than the routes using the overlay tunnels, which results in the branches sending PIM join messages using the multicast-capable MPLS core. The data traffic follows the same route (in the opposite direction) as the PIM messages. Since the specific routes for multicast source-subnets are prioritized differently than the routes for unicast traffic, the unicast traffic follows the overlay tunnel.

For the branches without MPLS connectivity, the routes over the SD-WAN overlay are given priority, which results in PIM join messages traversing the overlay network. This way, data traffic also utilizes the overlay route (using public access) for multicast traffic.

In the topology shown above, the receiver host behind a branch with a broadband only-WAN link triggers an IGMP request towards Spoke1. The PIM join (*,G) traverses the following path: Spoke1 >Hub (over SD-WAN overlay) > RP. The data from the RP towards the receiver host behind Spoke1 traverses the following path: RP > Hub > Spoke1 (over SD-WAN overlay) > receiver.

For the receiver host behind the branch with an MPLS connection, the PIM join (*,G) follows the path: Spoke3 > MPLS PE (underlay) > Remote PE >Hub >RP. The data from RP towards the receiver host follows the path: RP > Hub > MPLS PE (underlay) > MPLS PE (closest to the branch over MPLS core) > Spoke3 > receiver. Unicast traffic between various SD-WAN nodes traverses tunnels based on SD-WAN policy, or the traffic can be sent through the underlay-transport, in the case of MPLS.

Push-to-Talk over SD-WAN Overlay

The figure below illustrates a proof of concept at a leading brokerage firm with a global presence. The firm uses a form of Push-to-Talk as a communication channel between its traders. The physical device, such as Spoke1, can be used to listen to a number of channels. Additionally, the device can be used to talk to peers. For channels that are used to communicate, a trader behind Spoke1 pushes a button to talk while all the peers listen. In multicast terms, the Spoke1 becomes a source host for the group, while all other devices are receiver hosts. When some other device triggers the talk, the Spoke1 becomes a receiver host. 

In this use case, a VOS hub was defined as an RP. When a device takes over the role of a source host, it unicasts the data to the RP over the SD-WAN overlay network. The RP then replicates the data and multicasts it to the interested branches, which then forward it to the receiver hosts. At any given point of time, there are multiple sources for different groups (while only having a single source host per group). There can be multiple RPs as well.

The network can also be extended to include hierarchical hubs (such as in the VOS Edge Nodes Configured to use a Static Rendezvous Point use case shown above).

Multicast Using PIM-SSM

In enterprise-wide deployments in which the source of the data is pre-determined, PIM-SSM provides significant benefits, including lower delay, efficient routing, and better security. This is an ideal use case for stock-ticker applications that distribute pricing and other stock market-related information in which the network delay is the highest concern.

The network architecture in this deployment leverages the multi-hub and spoke architecture for multicast as described in the first use case, VOS Edge Nodes Configured to use a Static Rendezvous Point. PIM-SSM creates a hierarchical topology depending on the receiver host. 

In the topology shown above, the receiver host in Zone 64 triggers an IGMP request towards a spoke. The PIM join (S, G) traverses the following path: Spoke > Hub 64 > Hub1 > S1. The data from Source 1 towards the receiver host in Zone 64 traverses the following path: S1 > Hub 1 > Hub64 > spoke > receiver.

For the receiver host in Zone 1, the PIM join (S, G) follows the path: Rcvr64 > Spoke64 > S1. The data from Source 1 towards the receiver host follows the path S1 > S64  > Rcvr64.