Multicast Snooping Optimizations

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 September 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Considerations for the operation of IGMP and MLD snooping switches are described in [RFC4541]. In the intervening years since publication, industry has gained experience with deploying this technology and have identified areas of improvement on the original document, including how traffic distribution can be optimized for certain types of networks.¶

One area of improvement is that there appears to be a gap in the control path forwarding rules outlined in [RFC4541] section 2.1.1. Forwarding rules are defined for switch ports attached to multicast routers and switch ports attached to hosts, but switch ports attached to other switches are not mentioned, leaving the operation of these ports open to interpretation.¶

The authors may have purposefully limited consideration to networks with only a single switch, though this is not explicitly stated. In one sense, a network with a hierarchy of switches may be modeled as a single switch (in other words, the fact that multiple switches are being used would be transparent to any host or multicast router attached to the network). One side-effect of this approach is that it obscures how the network distributes traffic between multiple switches.¶

This router-centric view of multicast traffic distribution is likely rooted in the nature of the IGMP and MLD protocols, whose stated purpose is to communicate group membership (that is, the fact that a host would like to receive a given stream of multicast data) to a multicast router. Two types of networks would benefit from a closer examination of how traffic is distributed between multiple switches: 1) networks that do not contain a multicast router and 2) networks that contain a multicast router, but have a significant volume of multicast data that does not need to be routed outside of the local network.¶

The following diagram depicts an example network that can be used to illustrate the point:¶

                        /------\
                        |      |
               //=======|  S2  |=======\\
               ||       |      |       ||
               mr       \------/       ||
            /------\                /------\
            |      |                |      |
   //=======|  S1  |=======\\       |  H4  |
   ||       |      |       ||       |      |
   ||       \------/       ||       \------/
   ||          ||          ||
   ||          ||          ||
/------\    /------\    /------\
|      |    |      |    |      |
|  H1  |    |  H2  |    |  H3  |
|      |    |      |    |      |
\------/    \------/    \------/

S1 has designated its port connected to S2 as a multicast router port.¶

Suppose the example network contains two mulicast streams:¶

• Stream 1 generated by H1 and consumed by H3¶

• Stream 2 generated by H2 and consumed by H4¶

The problem is that Stream 1 is forwarded from S1 to S2 even though there are no consumers of this data. This is due to the following data forwarding rule in [RFC4541] section 2.1.2:¶

• Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables and must also be forwarded on router ports.¶

While it would be tempting to ignore this rule so that Stream 1 is no longer forwarded, this would also prevent Stream 2 from reaching H4. This is because of the following IGMP forwarding rule in [RFC4541] section 2.1.1:¶

• A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached.¶

This rule prevents S2 from forwarding the Membership Report from H4 to S1, so S1 does not mark the port connected to S2 as a member of the multicast group for Stream 2.¶

[RFC4541] indicates that this rule is meant to prevent a host running IGMPv1 or IGMPv2 (or MLDv1) from suppressing its Membership Report for that multicast group. While it would be tempting to require all hosts on the network to run IGMPv3 (or MLDv2), this is not possible on the networks targeted for deployment of this solution.¶

The next logical step in this direction would be to require multicast snooping switches to use some method to identify the nature of the device connected to each port (switch or host, IGMP/MLD version, etc.). This information would then be used to help control the distribution of Membership Reports.¶

However, this document uses a different approach, electing instead to use General Query messages to ensure membership information is distributed to all multicast snooping switches on the network. This solution is less complicated than methods that focus on Membership Reports, which reduces the likelihood for error. In addition, compatibility between different versions of IGMP and MLD are less of a concern because each protocol's Query messages are compatible with earlier versions of the protocol.¶

TODO: explicitly mention that IGMPv3 and MLDv2 are requirements for this protocol, but only on switches¶

2. Control Plane Operations

Each multicast snooping switch on the network shall periodically send General Query messages using an all-zeroes source address to all active ports. The interval between General Query messages is specified by a new timer, called Switch Query Interval. (TODO: describe the effect of adjusting the timer and specify a default value).¶

TODO: Important to send to multicast router ports because multicast router may have IRB (Integrated Routing and Bridging) connected, or be running a PIM-to-IGMP proxy.¶

Multicast snooping switches shall not forward General Query messages from the all-zeroes source address. Instead, the multicast snooping switch shall reply with an IGMPv3 Membership Report or MLDv2 Multicast Listener Report, as appropriate, that contains the aggregate of all valid report messages received by the multicast snooping switch. This report message shall only be sent to the port that the General Query message was received on; this ensures that a report message generated by the multicast snooping switch does not result in report suppression in IGMPv2 or MLDv1 hosts. (TODO: the report should not be sent back if the port is the only port that is a member)¶

Multicast snooping switches shall only forward General Query messages from non-zero source addresses. This ensures that the network is aware of any multicast router that is present on the network. Accordingly, the absense of a General Query message from a non-zero source address can be inferred to mean that the network does not have a multicast router.¶

TODO: several RFCs require query messages to use a valid IPv6 link-local source address (e.g., RFC 2710 section 3, RFC 3590 section 4, and RFC 3810 section 5.1.14) and RFC 4541 does not update these documents¶

TODO: Is there a disrepancy between requiring General Query messages to be forwarded to multicast router ports, while at the same time being able to use the absense of a Query from a non-zero source address to mean that there is no multicast router?¶

TODO: use a term like "Querier Ports" to indicate a port that an all-zeroes Query is received on¶

TODO: need to handle unsolicited reports. That needs to be sent to Querier Ports¶

TODO: need to handle leave and group-specific queries -- snooping switches will keep track of the ports that have group membership. When it receives a leave then it subtracts the port from membership, but only forwards the leave if there are no other ports with group membership¶

TODO: group membership timer expiration is the same as an explicit leave¶

TODO: if a switch receives a leave and there is only one port remaining and that port is a querier port, then send a leave to that querier port¶

3. Data Plane Operations

Multicast snooping switches should continue to follow the data forwarding rules outlined in [RFC4541] section 2.1.2. In order to optimize traffic distribution on the network, this section contains two refinements to the recommendation to forward traffic to the multicast router port, based on whether the multicast traffic is routable or non-routable.¶

To some extent, what constitutes a routable multicast address is subject to the overall design of the network, so it may be beneficial for multicast snooping switch vendors to allow configuration for how multicast addresses are classified.¶

Note that the decision to forward traffic based on group-based port membership tables is independent of the decision to forward traffic to the multicast router port. In other words, traffic may still be forwarded to the multicast router port because it is a group member.¶

4. Security Considerations

To be added.¶

5. IANA Considerations

This document does not have any IANA assignments/requests.¶

6. Acknowledgements

The authors would like to recognize the following individuals for their contributions to this research:¶

• David Vandewalle
  Garmin International¶

• Princy Elizabeth
  Juniper Networks¶

7. Normative References

[RFC4541]

Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.

Authors' Addresses