pim N. Karstens
Internet-Draft Garmin International
Updates: 4541 (if approved) Z. Zhang
Intended status: Standards Track L. Giuliano
Expires: 4 September 2025 N. Ashik
Juniper Networks
J. Huang
Garmin International
3 March 2025
Multicast Snooping Optimizations
draft-karstens-pim-multicast-snooping-optimization-00
Abstract
TODO: provide abstract
TODO: ensure all references are accounted for (e.g., IGMPvX, MLDvX,
pim)
TODO: ensure tone of document is for a standard, not informational
(i.e., don't use recommendations, use requirements)
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.
Karstens, et al. Expires 4 September 2025 [Page 1]
Internet-Draft Multicast Snooping Optimizations March 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Control Plane Operations . . . . . . . . . . . . . . . . . . 5
3. Data Plane Operations . . . . . . . . . . . . . . . . . . . . 6
3.1. Non-Routable Multicast Traffic . . . . . . . . . . . . . 6
3.2. Routable Multicast Traffic . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Karstens, et al. Expires 4 September 2025 [Page 2]
Internet-Draft Multicast Snooping Optimizations March 2025
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.
Karstens, et al. Expires 4 September 2025 [Page 3]
Internet-Draft Multicast Snooping Optimizations March 2025
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
1.1. Terminology
This document refers to IGMP snooping and MLD snooping collectively
as "multicast snooping".
The all-zeroes address refers to address 0.0.0.0 in IGMP contexts and
:: in MLD contexts.
TODO: do we want to define "multicast snooping switch"? Should we
have an abbreviation?
Karstens, et al. Expires 4 September 2025 [Page 4]
Internet-Draft Multicast Snooping Optimizations March 2025
TODO: if there are notable differences then mention something like
"except where there are notable differences".
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
Karstens, et al. Expires 4 September 2025 [Page 5]
Internet-Draft Multicast Snooping Optimizations March 2025
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.
3.1. Non-Routable Multicast Traffic
Multicast snooping switches shall only forward traffic to the
multicast router port if the traffic is known to be routable.
[RFC4541] section 3 discusses challenges associated with IPv6
addresses overlapping when they are mapped to DMAC addresses.
Multicast snooping switches should account for this possibility when
implementing this requirement. In the event of an address collision,
the recommendation is to forward the traffic and alert the network
administrator of the problem.
Karstens, et al. Expires 4 September 2025 [Page 6]
Internet-Draft Multicast Snooping Optimizations March 2025
TODO: How should this alert work, is there a YANG model we should
update?
3.2. Routable Multicast Traffic
TODO: add reference for 7761 (PIM)
Multicast snooping switches shall begin in a state where all
routable, any-source traffic shall be sent to the multicast router,
which will route it outside of the network. When the traffic reaches
the RP, the RP determines if it is interested in the traffic. If the
RP is not interested in the traffic, then it will send a PIM prune
message back to the multicast router.
When the multicast router receives the PIM prune message, it shall
send a report message excluding the multicast address back to the
multicast snooping switch. Multicast snooping switches shall
propagate the exclusion message back toward the source of the
multicast stream until it reaches a switch that contains a port that
is a member of that multicast group.
The fact that an exclusion message was received on the multicast
router port should be recorded so that the network can be properly
updated in the case of future changes to group-based port membership.
For example, if a multicast snooping switch stops propagating an
exclusion message because it contains at least one port that is a
member of the multicast group, then the switch should send an exclude
message back towards the source of the multicast stream when the last
port is removed from membership in the multicast group.
TODO: is this a problem? we woule be preventing future refinements
where an exclude message could be used to leave the have the port
leave group membership
Note that source-specific traffic is handled differently because PIM
will send a request to receive the traffic, so the recommendations in
this section only apply to any-source traffic.
4. Security Considerations
To be added.
5. IANA Considerations
This document does not have any IANA assignments/requests.
Karstens, et al. Expires 4 September 2025 [Page 7]
Internet-Draft Multicast Snooping Optimizations March 2025
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
Nate Karstens
Garmin International
Email: nate.karstens@garmin.com
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Lenny Giuliano
Juniper Networks
Email: lenny@juniper.net
Naveen Ashik
Juniper Networks
Email: nashik@juniper.net
Joseph Huang
Garmin International
Email: joseph.huang@garmin.com
Karstens, et al. Expires 4 September 2025 [Page 8]