]> Multicast Snooping Optimizations Garmin International
nate.karstens@garmin.com
Juniper Networks
zzhang@juniper.net
Juniper Networks
lenny@juniper.net
Juniper Networks
nashik@juniper.net
Garmin International
joseph.huang@garmin.com
Routing pim multicast snooping TODO: provide abstract
Introduction Considerations for the operation of IGMP and MLD snooping switches are described in . 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 . 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:
Example Network
S1 has designated its port connected to S2 as a multicast router port. Suppose the example network contains two multicast 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 :
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 :
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. 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, choosing 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. Multicast snooping switches implementing this design shall use , , or both. Multicast routers on the network must also use these protocol versions, , and satisfy the requirements listed in . Network hosts may use earlier versions of the protocols.
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document refers to IGMP snooping and MLD snooping collectively as "multicast snooping". TODO: if there are notable differences then mention something like "except where there are notable differences". IGMPv3 Membership Report messages and MLDv2 Multicast Listener Report messages are referred to collectively as Reports. The terms Any-Source Multicast and Source-Specific Multicast (see ) are respectively abbreviated ASM and SSM. TODO: do we want to define "multicast snooping switch"? Should we have an abbreviation?
Proxy Query Messages describes a special-case IGMP Query message with an IPv4 source address of 0.0.0.0. It would appear that the equivalent for MLD would be a Query message with the IPv6 source address set to the unspecified address (::), but several documents prohibit this:
  • requires all MLD messages to be sent with an IPv6 link-local source address
  • requires MLD Query messages to be sent with a valid IPv6 link-local source address
  • requires both that MLD Query messages be sent with a valid IPv6 link-local source address and that nodes discard Query messages without a valid IPv6 link-local source address
Instead of working against established precedent, this document assigns a new flag in the "IGMP/MLD Query Message Flags" registry: the P (Proxy Query) flag. If an IPv6 multicast router receives a Query with the P flag set, then it SHALL NOT use that message in the querier election process described in . To conserve flags and avoid duplicate functionality, this assignment is only made for MLD Query messages; the flag remains unassigned for IGMP Query messages. This document uses the term Proxy Query to refer to an IGMP Query with an IPv4 source address of 0.0.0.0 or an MLD Query with the P flag set.
Control Plane Operations Multicast snooping switches shall maintain a group-based port membership table that indicates which port(s) contain members for each tracked group. The requirements in this section are ultimately related to managing this table, using IGMP/MLD to communicate its contents to adjacent nodes, and making changes in response to IGMP/MLD messages received from adjacent nodes. Multicast snooping switches shall maintain a new Group/Port Membership Interval timer for each group and port combination in the group-based port membership table (see ). TODO: describe when the timer is set/reset and what happens when it expires Multicast snooping switches shall track a Multicast Router flag for each port. This flag indicates that a multicast router is connected through the associated port. Multicast snooping switches shall also track a Proxy Querier flag for each port. This flag indicates that the switch has received a Proxy Query message from this port, likely from another multicast snooping switch. If neither the Multicast Router or Proxy Querier flag is set for a port, then it can be inferred that the port is connected either to a host or to a switch that does not implement this design.
Transmitting Periodic Proxy Queries Each multicast snooping switch on the network shall periodically send General Proxy Query messages to all active ports. On startup, or after a port transitions from an inactive state to an active state, [Startup Switch Proxy Query Count] (see ) General Proxy Query messages shall be sent with [Startup Switch Proxy Query Interval] (see ) between each message. After this, General Proxy Query messages shall be sent with [Switch Proxy Query Interval] (see ) between each message. The QQIC field for each General Proxy Query message shall be set to [Startup Switch Proxy Query Interval] or [Switch Proxy Query Interval], as appropriate (see or ). 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.
Receiving Queries Multicast snooping switches shall do the following when a General non-Proxy Query is received:
  1. Set the Multicast Router flag for the port
  2. Reset the Multicast Router Timeout timer for the port (see )
  3. Forward the Query to all other active ports
Multicast snooping switches shall do the following when a General Proxy Query is received:
  1. Set the Proxy Querier flag for the port
  2. Reset the Proxy Querier Timeout timer for the port (see )
Note that Proxy Query messages are not forwarded. Forwarding non-Proxy Queries facilitates querier election and ensures that the network is aware that a multicast router is present. Accordingly, if only Proxy Query messages are received, then it can be inferred that there is no multicast router on the network. Multicast snooping switches shall respond to either type of Query by sending a Report to the port the Query was received on. This Report contains all groups in the group-based port membership table except the groups where the port the Query was received on is the only member port. TODO: we can add a table that gives an example group-based port membership table and the contents of the resulting report TODO: Does it make sense to require General Query messages be forwarded to multicast router ports, while also implying that if only Proxy Queries are received that there is no multicast router? TODO: use a term like "Querier Ports" to indicate a port that a Proxy Query is received on. Update: look for Proxy Querier flag TODO: need to handle unsolicited Rrports. 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
Receiving Reports TODO
Transmitting Reports TODO
Removing Groups from the Membership Table TODO
Data Plane Operations Multicast snooping switches shall follow the data forwarding rules outlined in . 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 multicast snooping switch vendors should 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.
Non-Routable Multicast Traffic Multicast snooping switches shall only forward traffic to the multicast router port if the traffic is known to be routable. 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. TODO: How should this alert work, is there a YANG model we should update?
Routable Multicast Traffic Multicast snooping switches shall begin in a state where all routable, ASM traffic is 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 SSM traffic is handled differently because PIM will send a request to receive the traffic, so the recommendations in this section only apply to ASM traffic.
List of Timers, Counters and Their Default Values TODO: Add a note indicating that these should be consistent with the analagous timers on a single link (like IGMPv3 section 8 or MLDv2 section 9 requires)
Group/Port Membership Interval This interval is analagous to the Group Membership Interval in and Multicast Address Listening Interval in , except it denotes how long a given group/port combination should remain in the group-based port membership table.
Switch Proxy Query Interval This interval is analogous to the Query Interval in and , except it denotes the interval between General Proxy Queries sent by the multicast snooping switch.
Startup Switch Proxy Query Interval This interval is analogous to the Startup Query Interval in and , except it denotes the interval between General Proxy Queries sent by the multicast snooping switch at startup.
Startup Switch Proxy Query Count This interval is analogous to the Startup Query Count in and , except it denotes the number of General Proxy Queries sent on startup, separated by the Startup Switch Proxy Query Interval.
Multicast Router Timeout This timeout is somewhat analogous to the Other Querier Present Timeout timer in and . If the timer expires, then the Multicast Router flag is cleared for the associated port.
Proxy Querier Timeout This timeout is somewhat analogous to the Other Querier Present Timeout timer in and . If the timer expires, then the Proxy Querier flag is cleared for the associated port.
Security Considerations To be added.
IANA Considerations TODO: Describe assigning flag in the "IGMP/MLD Query Message Flags" registry.
References Normative References An Overview of Source-Specific Multicast (SSM) The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community. Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community. Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. Internet Group Management Protocol, Version 3 The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. Multicast Listener Discovery Version 2 (MLDv2) for IPv6 This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document updates RFC 2710 and obsoletes RFC 3810. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Multicast Listener Discovery (MLD) for IPv6 This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK] Source Address Selection for the Multicast Listener Discovery (MLD) Protocol It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]
Contributors The authors would like to recognize the following individuals for their contributions to this research: Garmin International
david.vandewalle@garmin.com
Juniper Networks
princy@juniper.net