Project

General

Profile

WARNING: Just some rough scribblings follow below. Some thoughts on how RFC4541 could be revised.

Multicast Snooping - IGMP/MLD Domain Segmentation

Abstract

While Multicast Snooping Revised improves the multicast snooping compared to RFC4541 by only forwarding the multicast data flow to segments of the broadcast domain which are actually interested, there is still room for improvements for the IGMP/MLD message flow.

One drawback is still the "random" election of the selected querier by the lowest IP address. This might have an impact on the reliability of the IGMP/MLD protocol in a larger, dynamic and potentially partially unreliable network, like layer 2 wireless mesh networks. The selected querier takes a central role in the network which might not be desirable in a decentral (mesh) network.

Secondly, the larger the network the more likely the transmission of redundant IGMP/MLD messages and avoidable overhead becomes: It is sufficient to forward only one report message for a specific multicast group onto another port instead of doing this for each source address. Furthermore IGMPv3/MLDv2 reports allow to bundle multiple records for different multicast groups in a single message.

Thirdly, in scenarios with multiple snooping switches the forwarding table of a switch is kept unnecessarily large: In the days of IPv6 all hosts are participating in MLD and forwarding their reports to all snooping switches will result in them learning and keeping track of all such hosts one by one through the forwarding table.

With this document the IGMP/MLD performance is both increased in reliability while reducing the overhead by isolating each port into its own query domain and proxying and aggregating reports in between.

Handling of Multicast Queries and Reports

Instead of keeping global state about "querier exists", "legacy querier exists" etc. they are kept on a port by port basis.

Queries and reports are never forwarded onto other ports. For each port with its state we join and leave multicast groups on adjacent ports accordingly. MLDv2 is required for that.

TODO: Implications on unicast forwarding table?

In an IPv6 only network if reports are proxied, having their source address replaced by the one of a snooping switch, might this have an impact on unicast traffic between hosts? -> IPv6 Neighbor Discovery should take care of bidirectional detection along paths through NS and NA.