Need for Multicast Offload
The Satellite nV System architecture currently requires the Cisco ASR 9000 Series Router host to process all replications for supported multicast traffic and topology profiles. This is in line with the envisioned port extender functionality of the satellite devices where all protocol processing and forwarding decisions happen on the host to fully utilize the IOS-XR functionalities. With the introduction of support for a wider variety of satellite topologies, the satellites are no longer restricted by a need for direct connection to the hosts. The satellites can be connected to a Dual Host system to form a Ring topology or through a hub and spoke topology. The satellites can also be reached over an Layer-2 fabric connection through transport provider EVCs.
![]() Note |
Refer the Configuring the Satellite Network Virtualization (nV) System chapter for more information on Simple Ring and Layer 2 fabric topologies. |
This use of satellite fabric connections over EVCs or sharing of the same fabric link by a chain of satellite devices has introduced new bandwidth conservation requirements. One such specific case is the forwarding of multicast traffic over satellite ports where the Host currently does all the replication even if all the copies are destined to the ports on the same satellite device. The satellite device is unaware of any multicast group or membership and if multiple receivers are present on the ports of the same satellite, multiple copies of the same packet is sent to the satellite for each of the receivers which can eventually oversubscribe the fabric bandwidth.
With the increasing scale of satellites over the new topologies, it is evident that the model of Host side replication is not very efficient or scalable. The nV Satellite multicast offload feature is introduced to solve this problem. This feature allows the Host to forward just the pre-replicated multicast streams per multicast route (S,G) to the satellites and offload the per satellite access port replication to the satellite device itself. The protocols still run on the Cisco IOS-XR Software modules of the Host but the final replication happens locally on the satellite device based on selective download of routes to the satellites.
![](/c/dam/en/us/td/i/300001-400000/360001-370000/364001-365000/364188.eps/_jcr_content/renditions/364188.jpg)
Without offload, Host 1 (assuming that it is the active for both Satellite 1 and Satellite 2) sends 4 copies to receivers 1,2,3 and 4 even if they join the same multicast group, (S1,G1). With offload, Host 1 sends 1 copy and Satellite 1 replicates it twice for receivers 1 and 2 and Satellite 2 replicates it twice for receivers 3 and 4.
The multicast offload feature provides a way for a multicast route which has one or more satellite extended interfaces as its route members known as outgoing interface element lists (OLEs) on the host data plane to be represented locally on the satellite, so that the satellite receives a master copy of a multicast packet from the host and also is capable of replicating that packet into the extended interfaces, that is, the route members (OLEs) of a multicast route.
Whenever a multicast route is offloaded to the satellite, the multicast data received by the satellite on the IC link is tagged with an identifier identifying the multicast route the data belongs to, the satellite hardware reads this tag and through a table lookup finds out the extended interfaces to which the data has to be replicated for a particular route and sends the multicast data on the route-members (OLEs) of that multicast route. The multicast feature channel allows for the host to specify to the satellite which extended interfaces are mapped to which multicast route (tag or multicast isid).