Project

General

Profile

Doc-overview » Random » T X's Junkyard »

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

Ressources:

Multicast Snooping Revised

Abstract

The idea of multicast snooping is to reduce multicast overhead in large broadcast domains: Intermediaries like switches are supposed to learn about potential recipients, i.e. multicast listeners and multicast routers, by sniffing and parsing IGMP/MLD and Multicast Router Discovery messages. And can then forward multicast data packets to the potential recipients they previously learned about only.

Multicast snooping on the link layer is tough though: IGMPv1/v2 and MLDv1 did not have something like multicast snooping on their radar. Especially their report suppression mechanism makes multicast snooping difficult.

Currently there is RFC4541 which at least specifies a way on how a switch can perform multicast snooping despite the short comings of IGMPv1/v2 and MLDv1 without breaking network protocols. Unfortunately, RFC4541 has a few drawbacks:

RFC4541 Drawbacks

Multicast Traffic to Selected Querier:

RFC4541 makes the assumption that the selected querier is a multicast router. Many snooping switches implement the querier protocol, too though (in general for valid motivations as without a querier multicast snooping is not possible). However if a snooping switch becomes the selected querier then it will receive all multicast traffic too even if it is neither interested in it as a multicast listener nor as a multicast router.

Unpredictable Traffic Flow through Querier Election:

IGMP and MLD specify that from a set of potential queriers the one with the lowest IP address shall become the selected querier. In a dynamic and decentral network, for instance layer 2 wireless mesh networks, the selected querier might be a "random" node behind an unreliable and/or low-throughput wireless link. Such a node might be overwhelmed if receiving all multicast traffic in the network as described above.

Link-Local Multicast Traffic Forwarded to Multicast Routers:

Furthermore RFC4541 does not distinguish between link-local and routable multicast traffic. While routable multicast traffic needs to be forwarded to both multicast routers and multicast listeners on the local link link-local multicast does not: Link-local multicast traffic needs to be forwarded to multicast listeners only as multicast routers are not allowed to route them to other broadcast domains anyways.

This document tries to describe an alternative approach to RFC4541. The main concept is to translate IGMPv1/v2 and MLDv1 messages to IGMPv3 and MLDv2 messages before forwarding them - instead of altering and limiting the forwarding path of reports. Furthermore it does not make any assumptions about the interest of multicast traffic of the selected querier and requires MRD instead.

With these two approaches the short comings mentioned above are addressed.

Requirements and Changes Compared to RFC4541

Handling of Multicast Queries

Incoming IGMPv1/v2 and MLDv1 queries from the selected querier need to be converted to IGMPv3 and MLDv2 queries.

Then flood any IGMPv3/MLDv2 query from the selected querier, both original or converted ones, to the adjacent switch ports.

If an IGMPv1/v2 or MLDv1 query was received from the selected querier then mark the according port as "legacy IGMP querier present" or "legacy MLD querier present".

Handling of Multicast Reports

If a port marked as "legacy IGMP querier present" or "legacy MLD querier present" exists then do the following for the according protocol(s):

Forward an incoming report towards the selected querier as IGMPv2 or MLDv1 respectively. For any port other then the querier or incoming port, forward it as an IGMPv3 or MLDv2 report respectively.

Otherwise forward an incoming report towards all ports other than the incoming one as an IGMPv3 or MLDv2 report respectively.

Instead of forwarding reports to all adjacent ports we MAY forward them to ports with a listener to ff02::16 for IPv6 or 224.0.0.22 for IPv4 and if present a "legacy querier present" port only.

Join ff02::16 and 224.0.0.22

Perform the IGMPv3/MLDv2 protocol for joining ff02::16 and 224.0.0.22 to signalize that we, the snooping switch, need to receive multicast reports.

Handling of Multicast Data

Always flood ff02::1 / 224.0.0.0/24. Forward any other link-local multicast traffic to multicast listeners on the local link only.

Forward multicast traffic of scope greater than link-local on ports with according multicast listeners and on ports with multicast routers discovered via MRD.

Require MRD as the way to discover multicast routers

RFC4541 says that the list of routers can be constructed in three ways. Scratch queries from the list, only discover them via MRD and explicitly configured ports. And make it a "MUST", not "can".

Adding Bridge Ports

When a bridge port gets added and up repeat the last received multicast query of the selected multicast querier.

(TODO: Or send a query with our own address on that specific port? RFC4541 says something about )

No Querier Present

Flood any multicast traffic if no querier is present.

VLANs

Either always flood VLAN tagged multicast traffic. Or keep separate databases and state for each discovered VLAN.

Compatibility Measures with RFC4541

If a querier behind one of our ports exists then we need to find out whether an RFC4541 snooping switch exists between that port and the querier (including the querier potentially being an RFC4541 snooping switch):

If a query is received from that port but no multicast report with the same source address was received then this means an RFC4541 snooping switch was suppressing IGMP/MLD reports. Otherwise we would have at least received a report for 224.0.0.20 and ff02::16.

If such a snooping switch is detected behind that port then we need to forward all multicast traffic (both link-local and routable multicast) received on any other port towards the port of the selected querier.

An administrative option MAY exist to disable this compatibility measure but SHOULD NOT be enabled in implementations by default.

Compatibility Measures with Multicast Routers Incapable of MRD

An administrative option MUST exist to manually mark a port as "multicast router present".

Notes on Devices Similar to Switches

Devices, which similar to switches might profit from snooping capabilities.

For instance: IEEE 802.11 wifi interfaces in access-point mode -> Treat STAs like a bridge port each.

Generic network interfaces: Even they may refrain from transmitting multicast traffic scheduled by the IP stack after having performed multicast snooping on the link.

Switch-internal Queriers

Must provide a way to manually disable the participation as a querier.

TODO - more details

No "::" Source Address for Query Messages

MLD requires multicast listeners to consider query messages with such a source address as broken - they will not respond. Explicitly forbid sending queries with a "::" source address as it seems to be a common misconception that a switch may use it. If a snooping switch is not able to obtain a link-local source address then multicast snooping must be turned off.

In other words, require a snooping switch to be capable of performing the IPv6 protocol for obtaining a link-local address.

(TODO: What about IPv4? Should 0.0.0.0 OK there? Or allow/suggest "fe80::"/00:00:00:00:00:00 as the query source address without the IPv6 procedure for link-local multicast? Or even suggest 0.0.0.0/fe80::/00:00:00:00:00:00 as with this document this will not imply becoming the root/sink for all multicast traffic anymore?)

Security Measures

Appendix

Security Considerations

Further TODOs

  • Specify what to do with invalid reports or queries. Or queries which we received from an address higher than the currently selected one.