Introduction
This documents talks about Interaction between MPLS TE and multicast.
Description
Real world MPLS TE deployments are solely unicast MPLS TE deployments. That implies that multicast never really flows through these tunnels. Multicast always follows the native IP path even when there might be a better TE LSP available. However, this poses unique challenges for PIM joins and Multicast RPF checks to make multicast flows successful. For both Forwarding Agency (FA) and Autoroute (AR), this is the first obstacle. Traffic can only flow "out" on an MPLS TE tunnel, but it can never be "received" on it. This is the nature of MPLS TE LSP in general. Multicast packets always follow the native IGP path for their packet-forwarding process. They cannot leverage the MPLS TE tunnels (mLDP, P2MP are exceptions to this rule and out of scope for this document).
However, in multicast, we use Reverse Path Forwarding (RPF) to actually "forward" multicast packets and safeguard against multicast loops. In this process, a received multicast packet is checked against the source unicast address to ensure that it is incoming on the same interface that the unicast routing table would choose to send traffic out to that unicast address (if you are new to multicast, please ensure that you understand the last statement well). With MPLS TE enabled on a router, a multicast packet (or even a unicast packet) can never come IN on a tunnel interface (traffic only flows out on tunnel interface), but it would come in only via a physical interface. So when an RPF check is done for the source of the multicast packet, it would choose a tunnel interface, as per the unicast routing table, and RPF would fail! The multicast packet would be be dropped, and SP would not be able to roll out any multicast functionality on their network.
mpls traffic-eng multicast-intact command
MPLE TE enabled network. The solution came in the form of a command mpls traffic-eng multicast-intact under the router ospf or router IS-IS configuration mode. This command basically creates a separate table, referred to sometimes as the Multicast RIB table, that filters all the tunnel LSPs. This new table only contains actual physical interfaces as next-hops identified by the native SPF IGP. Now when a multicast packet comes in on the physical interface following the native IGP path, it consults this new multicast RIB only, and the RPF check succeeds! This is how multicasting can work today in an MPLS TE environment. However, due to the software implementation differences between FA and AR, we support the multicast-intact feature only for AR. Put in other words, TE deployments using FA, static routes, and PBR may not use this command for multicast support in the network. Here is the reason why:
AR implementation is straightforward in that we modify the RIB after IGP has run SPF and run the next-hop as the tunnel interface for all prefixes behind the tail-end tunnel address. In this sense, AR feature is purely local to the router. This makes it simple for us to implement multicast-intact feature by maintaining a parallel multicast RIB table that is basically the native IGP SPF output BEFORE we shortcut the next-hop with tunnel interfaces. We then use the RIB for normal unicast forwarding and use the multicast RIB for multicast RPF checks and forwarding PIM joins. In summary, the beauty of AR is that the function is local to the router, and hence, we can have another tweak made to the local router to enable multicasting.
FA not only does what AR does above but also generates new LSAs that represents the p2p tunnel LSPs. It's worthwhile to note that a head-end TE router will advertise this new LSA to downstream routers only when the tunnel passes two-way-connectivity-check (TWCC; i.e., there is a TE LSP from ‘a’ to ‘b’ and also from ‘b’ to ‘a’). The challenge is that the downstream router runs normal SPF like any other router but this SPF now also includes the TE LSAs. In that sense, the downstream router is now more ‘integrated’ and views the network with physical links and logical TE LSPs all combined together. Hence, a feature like multicast-intact cannot successfully identify the physical paths from the TE paths and does not work.
What’s required to fix this, in theory at least, is changing the IGP infrastructure (OSPF and IS-IS code) such that the LSAs themselves have some flag that identifies physical links with virtual TE links.
Related Information
