Multicast routing protocols, such as the Protocol Independent Multicast-Sparse Mode (PIM-SM) protocol, are used to distribute multicast traffic efficiently. PIM-SM is designed to route multicast packets to widely distributed and sparsely populated multicast groups efficiently via transmission paths that include Ethernet-based segments such as local area networks (LANs), wide area networks (WANs), and RFC 2547 and/or other virtual private networks and similar services that provide LAN or LAN-like connectivity across provider or other networks. Routers that desire to receive multicast traffic associated with a multicast group subscribe to the group. In PIM-SM, a router that receives a request to subscribe to a multicast group sends to an upstream router nearer the source a “join” message, to let the upstream router know that the downstream router needs to receive multicast traffic associated with the group. The join message is sent as a link-local multicast packet but the message specifies an upstream neighbor to which the request is directed. Per the PIM-SM protocol specification, only the router specified in the join request processes the request. If other routers wishing to join the same multicast group also have chosen the same upstream neighbor for that group, then such routers suppress their own joins upon seeing a Join on the LAN. On the other hand, if a router wishing to join the same multicast group has chosen a different upstream neighbor for that group, then such a router will have to send a join request explicitly on the LAN.
To avoid the inefficiency of multiple routers forwarding the same multicast traffic on the same LAN or similar segment, PIM-SM and similar protocols provide for routers that detect when duplicate traffic is being sent and perform an “assert” election to determine which of them will forward the multicast traffic via the LAN. Existing mechanisms for detecting that an assert election should be performed require that the PIM-SM router detect that multicast traffic for a group is being received on an interface via which the router is forwarding multicast traffic for the group, i.e., the multicast traffic is received on what the router considers to be an outbound interface for the group. This typically requires either special logic and/or circuitry at the interface or more commonly that multicast traffic received at a LAN or similar interface (part of the data traffic “forwarding plane”) be sent to the control plane for a determination to be made, e.g., by a control processor, as to whether the traffic comprises multicast traffic that is being received on an outbound interface for the multicast group with which the traffic is associated. This interaction between the forwarding plane and control plane consumes control plane resources, can lead to delay, and results in at least some duplicate forwarding of multicast traffic until the condition can be detected and an assert election initiated and completed. Therefore, there is a need for a better way to process multicast traffic.