Multicast in IP-VPN applications

Applications for this feature include enterprise customer implementing a VPRN solution for their WAN networking needs, customer applications including stock-ticker information, financial institutions for stock and other types of trading data and video delivery systems.

The following figure depicts an example of multicast in an IP-VPN application. The provider domain encompasses the core routers (1 through 4) and the edge routers (5 through 10). The various IP-VPN customers each have their own multicast domain, VPN-1 (CE routers 12, 13 and 16) and VPN-2 (CE Routers 11, 14, 15, 17 and 18). In this VPRN example, the VPN-1 data generated by the customer behind router 16 is multicast only by PE router 9 to PE routers 6 and 7 for delivery to CE routers 12 and 13 respectively. Data for VPN-2 generated by the customer behind router 15 is forwarded by PE router 8 to PE routers 5, 7 and 10 for delivery to CE routers 18, 11, 14 and 17 respectively.

Figure: Multicast in IP-VPN applications

The demarcation of these domains is in the PE router (routers 5 through 10). The PE router participates in both the customer multicast domain and the provider multicast domain. The customer CE routers are limited to a multicast adjacency with the multicast instance on the PE created to support that specific customer IP-VPN. This way, customers are isolated from the provider core multicast domain and other customer multicast domains while the provider core routers only participate in the provider multicast domain and are isolated from all customer multicast domains.

The PE for a specific customer multicast domain becomes adjacent to the CE routers attached to that PE and to all other PE that participate in the IP-VPN (or customer) multicast domain. This is achieved by the PE, which encapsulates the customer multicast control data and multicast streams inside the provider multicast packets. These encapsulated packets are forwarded only to the PE nodes that are participating in the same MVPN domain and are part of the same customer VPRN. This prunes the distribution of the multicast control and data traffic to the PEs that do not participate in the customer multicast domain.

Note: To enable ingress FC classification for packets received on a P2MP LSP on a network port IP interface and that needs to be replicated to IP receivers, use the loopback-no-svc-port>p2mpbud>p2mpbud-port-id>p2mp-bud-classification command. This command is required only on the 7210 SAS-R6 and 7210 SAS-R12 for ingress FC classification; for other platforms, this is not required.This command allows users to prioritize multicast traffic to IP receivers in the service. In addition, this command marks the packet with IP DSCP values while sending the multicast stream out of the IP interface. Before using the command, users must ensure that sufficient resources are available in the network ingress CAM resource pool and MPLS EXP ingress profile map resource pool. Use the tools>dump>system-resources command to check resource availability.