IP multicast replicates broadcast applications without dramatically increasing traffic on the network. The source sends out a single packet stream and switches and routers replicate it to reach multiple endpoints. The source doesn’t need to know who all the receivers are; they subscribe to the multicast using a group address, typically using Internet Group Management Protocol (IGMP), and the downstream provider edge routers (PEs) create the multicast distribution tree based on this group, typically using protocols such as Protocol Independent Multicast (PIM).
In an enterprise context, where the enterprise needs to interconnect its local area networks across the wide area network, multicast is typically used over virtual private networks (VPNs). There are more than a few options to perform multicast over VPNs, all sharing the same end goal to offer many streams of multicast traffic to multiple tenants within the larger enterprise network.
If we look in a bit more detail at the multicast implementation in VPNs, we immediately notice the wide range of different options available. It can be achieved based on a Layer 2 (L2) or a Layer 3 (L3) mode. Within each of the two technologies, there is the option to deliver multicasting based on flooding (typical for L2 networks but also possible in L3 networks based on inclusive provider multicast tunnels) or in a more efficient way (typical for L3 networks) where the upstream PE will only send the multicast group towards PEs where there are clients (CE) connected that have actually requested the multicast traffic (group).
In L3 networks, multicast VPN (MVPN) is the standard way to deliver multicast. Nonetheless, there are different ways of tunneling the traffic across the WAN (e.g., PIM, Multicast Label Distribution Protocol [mLDP], Bit Index Explicit Replication [BIER], etc.) as well as different signaling mechanisms towards the client CE (e.g., IGMP, PIM Multicast Listener Discovery) and PE to PE (PIM, Border Gateway Protocol [BGP]). This results in a lot of flexibility. However, that flexibility comes at the price of increased complexity.
For L2 VPNs (virtual private LAN service [VPLS] or Ethernet LAN [E-LAN]), the multicast distribution is based on ingress replication, where more efficient traffic replication can be achieved by snooping or proxy functionality. L2 VPNs enable daisy-chaining multicast traffic in cases where the PEs are connected via physical interfaces forming a ring structure. Again, all of this provides flexibility but may also be perceived as complex by operators.
Filling in the Missing Pieces
If we look at the current implementations of multicast in VPNs, there are some parts missing that might be needed in the future. Take for instance the fact that IP fabrics in data centers, or the cloud in general, do not support any multicast as this is a pure IP fabric without notion of protocols like mLDP and/or PIM. Next to that, there is no clear integration of L2 and L3 in current VPNs. To address both challenges, multicast in an Ethernet VPN (EVPN) will be an interesting technology for addressing the above deficiencies.
There is a current draft implementation of multicast in EVPN called Optimized Inter-Subnet Multicast (OISM), which is described in draft-ietf-bess-evpn-irb-mcast. The main goal of the draft is to provide a simplified multicast model in EVPN compared to the existing implementations in IP-VPN and L2-VPN. It enables efficient traffic distribution, even over IP-based fabrics, and maintains the ability to deliver multi-homing capabilities.
OISM increases the efficiency of the data path and the ability to send traffic from one broadcast domain on the PE into another broadcast domain on the same or neighboring PE. Without OISM, there needs to be a rendezvous point on a designated router to connect sources and receivers across broadcast domains because of limitations in PIM. This requirement can complicate the data path. Under OISM this is avoided by using BGP auto-discovery and the P-multicast service interfaces (PMSI) as an MVPN service overlay, setting up P-tunnel signaling. Thus, EVPN is the only control plane protocol among the PEs involved in the multicast and, without the overhead of PIM, this is much simpler and more efficient.
OISM also eliminates client routers at the receiving end by extending the EVPN domain. This keeps the traffic in L2 using IGMP/MLD with, again, no need for PIM or rendezvous points. It leverages the multi-homing capabilities of EVPN and gets rid of upstream multicast hop selection by creating a single EVPN route and single tree. In order for receivers to pull the multicast, OISM uses the type-6 Selective Multicast Ethernet Tag (SMET) route. This essentially translates the IGMP join into a BGP EVPN message.
To ensure redundancy on the receiver side, there is a need to synchronize the received IGMP (join/leaf) messages between the redundant PEs. Two new EVPN routes (route-type 7 and 8) will be used for this. This is mainly needed in case the receiving PE, being the PE that receives the IGMP join, is not acting as the designated router. As such the PE needs to inform the neighboring PE (acting as designated router) on the request made by the host wanting to join a certain multicast group. These RT-7 EVPN routes will trigger the sending of a SMET route towards the upstream PE, which will then result in receiving the related multicast group on the correct PE (being the designated router).
In regular IP domains, for instance an IP fabric in a data center where there is no multicast on the underlay or MPLS tunnels available, assistant replication may be used for the transport of multicast. This mechanism is based on sending multicast traffic or BUM (Broadcast unknown-unicast and multicast) traffic in a more general extend to a dedicated PE (being the assistant replicator). It then takes care of the replication towards the related receivers. This mechanism is an interesting approach for leaf-spine architectures, especially where leaf-nodes are not always powerful enough to support a scalable ingress replication, as the traffic flows are mapped onto the physical topology of the fabric.
A Look Ahead
MVPN will be around for a very long time, and perhaps will always have some role. In the near term, expect multicast over EVPN to be used in the data center and MVPN in the WAN. This would require an MVPN-EVPN gateway (MEG). It would be the designated router for the MVPN multicast and then translate client multicast (C-mcast) routes into receiving SMET routes. Upon receiving a C-mcast route the MEG creates an L3 state and generates a SMET route.
In summary, existing techniques for delivering multicast with VPNs are fairly complex and fall short on addressing efficient traffic distribution over IP-based fabrics and their ability to deliver multi-homing capabilities. EVPN multicast is an emerging alternative that is about simplification and efficient data paths, especially with the modifications proposed in the IETF OISM draft. EVPN’s multihoming features, which ensure redundancy on the provider edge for supporting enterprise branch CE in the case of link or PE device failure, are preserved under OISM. In the cloud age, EVPN multicast is much more suited to the data center and Virtual Extensible LAN (VXLAN) and, with OISM MEG, it can play an important role in integrating the WAN and data centers. While existing multicast VPN technologies will by no means go away, expect EVPN to play a growing role for IP multicast in the future.
Gilles Geerts is a consulting engineer for the Network Solutions/Consulting team at Nokia, EMEA region. In this role, he provides design guidelines based upon best practices and customer requirements with a special focus on IP/MPLS architectures and next-gen business services (including SD-WAN). For this, he interworks with Nokia technical sales as well as technical experts in leading EMEA service providers.
