RFC 3488

Cisco Systems Router-port Group Management Protocol (RGMP)

📅 published March 2003, from ietf

📡 RFC 3488: Router-port Group Management Protocol (RGMP) 🎀

Okay bestie, this one is from February 2003, written by I. Wu and T. Eckert at Cisco Systems 💅. It's marked Informational, which means it gives info to the Internet community and doesn't set an official Internet standard. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

okay so this doc explains the Router-port Group Management Protocol (RGMP) 🧚. Cisco made it, and it's how multicast routers and switches talk to each other so the switches only forward multicast packets to the routers that actually need them. Iconic restraint 👑.

RGMP is built for backbone switched networks where a bunch of high speed routers are linked together 🔥.

1. Conventions used in this document ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. Read those as the official vibe-check words 🫶.

2. Introduction 🌸

So IGMP Snooping is super popular, but nobody really documents it well 🙈. It lets a switch restrict multicast traffic to the ports whose hosts want it, and it dynamically sets up and tears down group specific forwarding on switches that support it.

The big limitation is that IGMP Snooping can only limit multicast traffic to switch ports with receiving hosts connected directly or through other switches. It can't limit multicast to ports where at least one multicast router is connected, so it has to flood traffic to those ports instead 💀. Snooping on IGMP messages alone is an intrinsic limitation, because a switch can only learn which multicast flows hosts are asking for. A switch can't learn through IGMP which flows router ports need in order to route, since routers don't report those flows via IGMP. Not it 😭.

When several multicast routers are hooked up to a switched backbone, IGMP Snooping won't reduce multicast traffic load. It also won't help increase internal bandwidth through the switches in the network 🥀.

In switched backbone networks or exchange points, where mostly routers are connected to each other, a lot of multicast traffic can cause unexpected congestion ⚡. It also eats up more router resources, because routers have to discard the unwanted multicast traffic 🙃.

The RGMP protocol in this document restricts multicast traffic to router ports 🦋. To work effectively, it has to be supported by both the switches and the routers in the network. Team effort 🫶.

The RGMP message format looks a lot like the IGMPv2 message format, so existing switches that can do IGMP Snooping can be upgraded with this feature without a huge glow-up 🎀. RGMP messages are encapsulated in IPv4 datagrams with protocol number 2, the same as IGMP. All RGMP messages are sent with TTL 1 to destination address 224.0.0.25. IANA assigned this address to carry messages from routers to switches [3] 💜.

RGMP is designed to work alongside multicast routing protocols where explicit join/prune to the distribution tree happens. PIM-SM [4] is an example of one of those 🌈.

The RGMP protocol only specifies operations for IP version 4 multicast routing. IP version 6 is not considered 🍓.

To keep RGMP simple, efficient and easy to implement, switches are designed to expect RGMP messages from only one source per port. So RGMP only supports a single RGMP enabled router directly connected to a port of an RGMP enabled switch. This setup should be customary when connecting routers to backbone switches, so it shouldn't be a limitation on deploying RGMP 🧚‍♀️.

All RGMP messages have the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Reserved field in the message MUST be transmitted as zeros and ignored on receipt. Keep that one locked in 🔒.

2.1 Type 🎀

There are four types of RGMP messages that matter for the router-switch interaction. The type codes are the highest values in an octet, so they don't clash with IGMP type codes that are already taken 🙈.

      0xFF = Hello
      0xFE = Bye
      0xFD = Join a group
      0xFC = Leave a group

Unrecognized message types should be silently ignored 🤫.

Note:

RGMP and the IANA assignment of address 224.0.0.25 for it came before RFC 3228 [9]. RGMP defines Type values that RFC 3228 assigns to protocol testing and experimentation. This isn't an operational issue for RGMP itself, because only RGMP packets use the IPv4 destination address 224.0.0.25. So the Type values defined above are ONLY valid together with the RGMP destination address. Context is everything 💅.

2.2. Checksum 🧮

The checksum covers the RGMP message, which is the entire IPv4 payload. The algorithm and checksum handling are the same as for IGMP messages, as described in RFC 3376 [5] ✨.

2.3. Group Address 🌷

In an RGMP Hello or Bye message, the group address field is set to zero 🫧.

In an RGMP Join or Leave message, the group address field holds the IPv4 multicast group address of the group being joined or left 💖.

2.4 IPv4 header 🌈

RGMP messages are sent by routers to switches. The source IPv4 address of an RGMP packet is the sending interface IPv4 address of the originating router. The destination IPv4 address of an RGMP packet is 224.0.0.25. Switches supporting RGMP need to listen to packets sent to this group 👂.

3. RGMP Protocol Description 💅

3.1 RGMP Router side Protocol Description 👑

Backbone switches use RGMP to learn which groups are wanted at each of their ports. Multicast routers use RGMP to pass that info along to the switches. Only routers send RGMP messages, and they ignore any RGMP messages they receive 🙅‍♀️.

A Router enabled for RGMP on an interface periodically [Hello Interval] sends an RGMP Hello message to the attached network to say that it's RGMP enabled. When RGMP is disabled on a router's interface, it sends out an RGMP Bye message on that interface, which says it wants to receive IPv4 multicast traffic promiscuously from that interface again 🦋.

When an interface is RGMP enabled, a router sends an RGMP Join message out through that interface for each group it wants traffic from on that interface. The router needs to periodically [Join Interval] re-send an RGMP Join for a group to show that it still wants that multicast traffic 🔁.

Routers supporting RGMP MUST NOT send RGMP Join or Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and 224.0.1.40. The latter two are known as cisco-rp-announce and cisco-rp-discovery [3]. Don't touch these, no cap 🚫.

When a router no longer needs traffic for a particular group, it sends an RGMP Leave message for that group. For robustness, the router MAY send more than one such message 🛡️.

If IPv4 multicast packets for an undesired group are received at a router from a switch, the router MAY send an RGMP Leave message for that group to the switch. These are called data-triggered RGMP Leave messages, and the router SHOULD rate-limit them 🚦. The router MAY suppress sending a data triggered RGMP Leave message if it has a desired group with the same MAC destination address as the undesired group. (See RFC 1112 [6] for MAC ambiguity.) Such suppression of data triggered RGMP Leave messages SHOULD be configurable if supported. Lowkey a lot of nuance, but it's all there 🎀.

3.2 RGMP Switch side Protocol Description ✨

Okay bestie, so a switch that's RGMP-enabled takes in the RGMP messages that show up on its network ports and processes them the way we're about to see 💅. If the switch has RGMP turned on, it must NOT forward or flood those received RGMP messages out to the other ports on the network 🙅‍♀️.

RGMP on a switch works per port 🦋. It builds per-group forwarding state on the ports that have RGMP enabled. A port becomes an RGMP enabled port as soon as it gets an RGMP Hello message, and that starts a timer set to [5 * Hello Interval] ⏰. Every new RGMP Hello that lands on the port restarts the timer. If the timer runs out, or if an RGMP Bye message shows up and removes it, the port goes back to whatever multicast traffic forwarding it was doing before 🔄.

The correct setup is one RGMP enabled router plugged straight into a port on an RGMP-capable switch 🎀. The port on the switch MAY want to keep track of the IPv4 originator address of the RGMP Hello and Bye messages it gets. If that port starts receiving RGMP messages from multiple IPv4 originating addresses, the switch MAY generate an alert to tell the admin something's up 🚨. The switch MAY also have a config option that lets the operator turn RGMP off and go back to flooding IPv4 multicast on that port. Heads up, though, this is a potentially dangerous option ⚠️.

By default, if you connect two or more RGMP enabled routers to one switch port, you'll get intermittent black holing of IPv4 multicast traffic heading to those routers 🕳️. Black holing happens when one router sends an RGMP Leave while the other router is still joined. It's literally the worst 😭.

This malfunction is super easy to spot, because the actual users behind the routers will notice right away 👀. It also follows the rule that a failure should cause less traffic, not more. Going back to flooding makes everything look like it's working perfectly 🌈. The catch is that you don't get the traffic-constraining perks of RGMP anymore. So the congestion shows up way later than the misconfiguration did, and nobody can easily connect the two anymore 🙈.

Routers that support RGMP don't have to send RGMP Join or Leave messages for the groups 224.0.0.x (where x=0...255), 224.0.1.39 and 224.0.1.40. That means RGMP enabled ports always need to receive traffic for those groups 💜. Traffic for any other groups isn't forwarded to an RGMP enabled port at first ✨.

RGMP Join and Leave messages get accepted only if they arrive on an RGMP enabled port. Otherwise they get thrown away 🗑️. When the switch accepts an RGMP Join message, it MUST start forwarding traffic for that group to the port. When it accepts an RGMP Leave message, the switch SHOULD stop forwarding traffic for that group to the port. Sometimes the switch can't stop forwarding for a group, for example because of destination MAC based forwarding in the switch 🤷‍♀️. So the switch always has to keep forwarding traffic for all MAC-ambiguous IPv4 multicast groups (see [6] for MAC-ambiguity) 🫶.

If RGMP Leave messages get lost, a switch MAY time out the RGMP forwarding state on a port for a group. That timeout is [5 * Join Interval] after the last RGMP Join for that group arrived on the port ⏳.

Without any layer 2 IPv4 multicast filtering running, a switch has to flood multicast traffic to all ports 🌊. If a switch runs one or more other mechanisms besides RGMP to filter IPv4 multicast traffic, like IGMP snooping [10], then by default it won't flood IPv4 multicast traffic to all ports anymore 🙌. Instead, it tries to figure out which ports still need all IPv4 multicast traffic by default, and which ports don't.

Compliance with this spec means a switch MUST be able to pick a port for flooding by spotting PIM Hello messages [4] arriving from that port, and also through a manual configuration option 💅. On top of that, the switch SHOULD recognize a port connected to a router through other suitable protocol packets, or through dedicated IPv4 multicast router discovery mechanisms like MRDISC [11] 👑. Manual configuration is required to support routers that don't do PIM or any other method the switch recognizes 🛠️.

Other mechanisms for restricting IPv4 multicast traffic may also be used on RGMP enabled ports 🎀. When that happens, forwarding for a group on the port must be established if either mechanism requires it, and it must only be removed if no mechanism requires it anymore 🔐.

4. Operational Notes ✨

4.1. Support for networks with multiple switches

To be simple to implement on switches and resilient in the face of potential layer 2 network topology changes, RGMP does not specify how to restrict multicast traffic on links connecting switches to each other 🧩. If only RGMP is being used, multicast traffic will get flooded on inter-switch links within a network as long as at least one router is connected to each of the switches 🌊.

This happens automatically, because the switch won't flood or forward received RGMP messages out to the inter-switch link. So the switch on the other end only recognizes that port as a router port through the PIM Hello messages the switches flood 💜. Manual configuration for inter-switch links may be required if non-PIM routers are in use, depending on what else the switch can do 🛠️.

If it makes sense, a switch can send RGMP messages out on its ports to look like an RGMP enabled router to a possible switch on the other end of the link 🦋. That would constrain IPv4 multicast traffic between switches. But this kind of "RGMP Spoofing" by the switch is outside the scope of this spec 🙅‍♀️.

4.2. Interoperability with RGMP-incapable routers

RGMP messages received at a switch only affect the state of their ingress ports, so the traffic restriction only gets applied there 🎯. RGMP-incapable routers will still receive multicast traffic for all multicast groups 🌈.

4.3. RGMP and multicast routing protocols

The simplicity of RGMP comes with some restrictions when it comes to supporting specific routing protocols 😅. Here are a few known restrictions, listed in the paragraphs below.

A router running RGMP on a switched network won't receive traffic for a multicast group unless it explicitly asks for it with RGMP Join messages (apart from the group ranges that Section 3.1 says get flooded) 🙈. Because of this, you can't run a protocol like PIM Dense-Mode or DVMRP across an RGMP enabled network with RGMP enabled routers 💀.

In Bidir-PIM, a router that gets elected as the DF must not be enabled for RGMP on the network 🚫. The reason is that it unconditionally needs to forward traffic received from the network towards the RP. If a router isn't the DF for any group on the network, it can be enabled for RGMP on that network 💖.

In PIM-SM, directly connected sources on the network can't be supported if the elected DR is running RGMP 😭. This DR needs to unconditionally receive traffic from directly connected sources so it can trigger the PIM-SM registering process on the DR. In PIM-SSM, though, directly connected sources can be supported with RGMP enabled routers 🥳.

In both PIM-SM and PIM-SSM, upstream routers that forward traffic into the switched network need to send RGMP Joins for the group to support the PIM assert process 🧚.

5. List of timers and default values ⏰

5.1. Hello Interval

The Hello Interval is the gap between RGMP Hello messages that an RGMP-enabled router sends to an RGMP-enabled switch 💌. Default: 60 seconds.

5.2. Join Interval

The Join Interval is the gap between the periodic RGMP Join messages that an RGMP-enabled router sends to an RGMP-enabled switch for a given group address 🔁. Default: 60 seconds.

6. Security Considerations 🔐

Okay, this section is serious bestie, so pay attention 🫣. The RGMP protocol assumes that physical port security can be guaranteed for the switch ports where RGMP messages are accepted. Physical port security for RGMP means that physical measures make sure those ports are dedicated to one system that acts as an RGMP capable router 🔒. This is also the recommended setup to get the most out of RGMP, for example by avoiding unwanted third-party IPv4 multicast traffic arriving on those ports 🛡️.

RGMP-specific DoS attacks come from forged RGMP messages 🚨. If more than one system is connected to a port on the RGMP switch, then one system can forge RGMP messages and mess with the operation of the other system(s) on that same port. That's a real security risk 😱.

When physical security makes sure that only one system is connected to an RGMP capable port on a switch, forged messages from that system itself can still take effect 🤔. Those forged messages can always be avoided with system-local measures 🙌.

Here's what happens with a forged message of each type 👇.

Hello Message:

A forged RGMP Hello message can restrict multicast data heading to a non-RGMP enabled router on the same port. That effectively creates a blackholing DoS attack 🕳️.

Leave Message:

A forged RGMP Leave message can restrict IPv4 multicast traffic for individual groups toward the port. The result is a possible blackholing DoS attack, similar to a forged RGMP Hello message. The difference is that it doesn't affect all IPv4 multicast traffic, only the traffic for the groups named in the forged messages. It also only affects a port if there's officially just one RGMP enabled router connected to it (that is, if the port is RGMP enabled) 🎯.

Bye Message:

A forged RGMP Bye message can turn the port into an RGMP-disabled port 😬. This could indirectly cause a DoS attack based on the port getting overloaded with IPv4 multicast traffic, if the network bandwidth of the port was provisioned expecting RGMP to suppress unwanted IPv4 multicast messages 📉.

This type of DoS attack just brings back the port behavior you'd have if RGMP wasn't configured at all, which kills the benefit of RGMP 💔. Still, it doesn't introduce a problem that wouldn't have existed without RGMP in the first place 🤷‍♀️.

Join Message:

A forged RGMP Join message could attract unwanted multicast packets to the port where it was received 🧲. The effect is similar to a forged RGMP Bye message, except that it only affects the traffic for the groups named in the forged messages, not all IPv4 multicast traffic. The message will only affect a port if there's officially just one RGMP enabled router connected to it (that is, if the port is RGMP enabled) 🎀.

7. Normative References 📚

[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.

[5] Cain, B., Deering, S., Kouvelas, I., Fenner, W. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.

[6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

[7] ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) Bridges", 1998.

8. Informative References ✨

  • [3] Internet Multicast Addresses, http://www.iana.org/assignments/multicast-addresses 🌸
  • [8] Farinacci D., Tweedly D., Speakman T., "Cisco Group Management Protocol (CGMP)", 1996/1997 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt 💅
  • [9] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", RFC 3228, February 2002. 📚
  • [10] Christensen, M. and F. Solensky, "IGMP and MLD snooping switches", Work In Progress. 🛠️
  • [11] Biswas, S., Cain, B. and B. Haberman, "IGMP Multicast Router Discovery", Work In Progress. 🔍

9. Acknowledgments 🫶

Huge shoutout to Gorry Fairhurst, Bill Fenner, Giovanni Meo, Mike Norton, Pavlin Radoslavov and Alex Zinin for reviewing the document and dropping their suggestions. The authors literally couldn't have done it without you, bestie 💖

Appendix A. Intellectual Property Rights 📜

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification in this document. For the full details, go check the online list of claimed rights 🔗

Appendix B. Comparison with GARP/GMRP 🦋

This appendix is not part of the RGMP specification but is provided for information only. So it's a bonus read, not the rulebook ✨

GARP/GMRP (defined in IEEE 802.1D [7]) is the ANSI/ISO/IEC/IEEE protocol suite for constraining ethernet multicast traffic in bridged ethernet networks. That makes it a possible alternative to RGMP for constraining multicast traffic towards router ports 👀 This appendix explains why we're not relying on GARP/GMRP and how the two actually differ.

The big goal behind GARP/GMRP was to completely replace IGMP Snooping, and honestly that was the whole vibe. For efficient operation, IGMP Snooping needs hardware filtering support in the switch so it can tell host membership reports apart from actual IPv4 multicast traffic. Many older switches just don't have that, and vendors wanted a way around it so they could constrain IPv4 multicast in a switched LAN without building pricier switch hardware. GARP/GMRP is one result of that hustle, and CGMP from Cisco is another. CGMP solves the problem without changing the host stack software, but GARP/GMRP needs host stack support 💅

Here's the tea: GARP/GMRP hasn't really made big moves in deployed solutions yet. IGMP Snooping (and CGMP) are the norm in this environment 🙃 So GARP/GMRP can not necessarily be expected to be supported by layer 2 switches. It also doesn't clearly address the problems RGMP is trying to solve. On one hand, it brings way more functionality, and with that more complexity, than is immediately needed. On the other hand, it's limited because it's a standard that's mostly focused on the Ethernet scope 🌈

Beyond the process and applicability reasons, the main differences between GARP/GMRP and RGMP are these:

  • GARP/GMRP switches/systems need to send and listen/react to GARP/GMRP messages. In RGMP, routers only need to send RGMP messages and switches only need to listen to them. This approach is meant to simplify implementation, operations and troubleshooting 🧚
  • The same switch running RGMP in a backbone network will likely see more states than one that only does IGMP Snooping at the edge. That makes it preferable to keep the per-group processing and memory requirements of RGMP more in bounds than what's possible with IGMP Snooping and GARP/GMRP. In GARP/GMRP, one or more timer-based state machines need to be maintained per ethernet group address. In RGMP, timer maintenance is completely optional, and there are only two states per group: joined or not joined ⏱️
  • GARP/GMRP is an ethernet level protocol from the IEEE. It supports constraining traffic for ethernet addresses (groups). RGMP constrains traffic for IPv4 multicast groups. Today that's even beyond the capabilities of typical switch platforms used as layer 2 switches. Extending support to further entities is likely easier through extensions to RGMP than through GARP/GMRP 🎀
  • RGMP shares the basic packet format with IGMP (version 2), so it's easy to add to router and switch platforms that already support IGMP and IGMP Snooping respectively. This is especially true for switches that can differentiate, in hardware, between IGMP protocol type packets and other IPv4 multicast traffic sent to the same (or a MAC ambiguous) group. Plus, because RGMP has such simple state, it's easy to integrate IGMP Snooping and RGMP operations in the IPv4 multicast control and forwarding plane of a switch 💜
  • GARP/GMRP supports more than one system (host/router) on a switch port, which is one reason for its complexity. In RGMP, this configuration is explicitly not supported. More than one router per switched port is not only uncommon in today's switched layer 2 networks, it's also an undesired configuration when unwanted IPv4 multicast traffic is supposed to be kept away from routers 🚫
  • GARP/GMRP defines how to constrain multicast traffic between switches, which is another reason for its complexity. RGMP does not explicitly support this as part of the protocol, for the following reasons:
    • It is not necessary to include this function in the RGMP protocol description, because switch implementations can transparently decide to support it (see 4.1 about this "RGMP Spoofing") 🕵️
    • Important deployments that move large amounts of IPv4 multicast today are typically single switch MIX - Multicast Internet eXchange points 🌐
    • Avoiding congestion on inter-switch links is more complex than simply constraining IPv4 multicast traffic to the paths where it's needed. With or without IPv4 multicast, the aggregate bandwidth needed between switches can easily equal the aggregate required bandwidth to routers on either side. For this reason, inter-switch bandwidth is most often appropriately over provisioned. Also, the likelihood of receiving routers being only on the source side of an inter-switch link is rather low in general deployments. Cases where traffic constrainment on inter-switch links is required and helpful are therefore limited, and can in most cases be avoided or worked around. Moving the network to a layer 3 routed network is often the best solution, and supporting RGMP-Spoofing (see section 4.1) is another one 🥳

Appendix C. Possible future extensions / comparison to PIM Snooping ✨

This appendix is not part of the RGMP specification but is provided for information only. 🎀

okay so this appendix is basically RGMP's "what if" file 🔮 It talks about future extensions that could be added to RGMP, explains why they didn't make the cut, and gives the case for RGMP over (PIM) snooping 💅 Lowkey the best part.

  • Support for multiple switches 🌸 This is covered in "RGMP Spoofing", chapter 4.1, and in the GARP/GMRP comparison in Appendix B. Go check those, bestie.
  • Support for SSM 🦋 RGMP works with PIM-SSM, but it has no explicit messages for the router to selectively join individual (S,G) channels. Instead, the router has to RGMP join to all (Si,G) channels by joining to G. Extending RGMP to include (S,G) Join/Leaves is feasible ✅ BUT most switches don't actually do traffic constraining per channel yet, so it's not a priority rn. Also, the chance of two SSM channels using the same group (actual channel collision) only becomes a real problem once SSM is fully deployed. Not yet, babe 💀
  • Support for IPv6 🧚 RGMP could easily be extended to IPv6 by mapping the RGMP packet format into the MLD/IPv6 packet format. This wasn't done in this spec because most switches today don't even support MLD snooping. Like, the hardware isn't there yet 😭
  • Support for multiple routers per port 🙈 As discussed in Appendix B. This is probably the one extension that should be avoided, because multiple RGMP routers per port are inappropriate for efficient multicast traffic constrainment. Hard pass from me 🚫
  • Support for non-join based protocols / protocol elements 🍓 For protocols like PIM dense-mode, DVMRP, or Bidir-PIM DF routers, extra RGMP messages may be added so routers can say that certain group (ranges) traffic needs to be flooded from them (dense-mode) or to them (Bidir-PIM). Ooooh, a whole new vibe 💜
  • Support for multi-policy switching 👑 In Multicast Exchange Points (MIXes) environments, there are situations where different downstream routers need to receive the same traffic flow from different upstream routers, for policy reasons. Iconic drama, honestly 🎭 This could be solved by adding an upstream neighbor field to RGMP Join/Leave messages. The RGMP switch would then forward traffic from one upstream router only to the downstream routers that want traffic from exactly that upstream router. This extension would work best alongside changes to the layer 3 routing protocol run between the routers ✨

As previously mentioned, RGMP was designed to be easy to implement and to support simple layer2 switches. Implementations could also be applied to switches beyond layer 2. But ngl, if every one of those possible future extensions were supported by an evolution of RGMP, it would be questionable whether such a protocol could be any less complex than actually snooping into the layer3 IPv4 routing protocol run between routers in a switched LAN. Wild, right? 🤯

From a protocol architecture perspective, it is definitely more appropriate to have a separate protocol like RGMP or GARP/GMRP for this purpose. Then again, the more complex the requirements get, the more duplication of effort is involved, and snooping starts to look like the more attractive option 👀

Even though PIM is the predominant routing protocol in IPv4 multicast, routing with PIM is extremely complex for a switch to snoop into. PIM has two main versions and different modes: sparse, dense, bidir, and ssm. It uses join / prune / graft messages (depending on the mode of the group), has various PIM Hello options and different versions of asserts, and has two dynamic mode announcement protocols (BSR and AutoRP). On top of all that, it supports both IPv4 and IPv6. Literally a whole universe 🌌

A switch that snoops into PIM is very likely to implement only a subset of that feature set. That makes it really hard for the user to figure out what level of actual traffic constrainment they're getting, unless there's a clear specification for the implementation (or, even better, for the method itself) 📜 There's also always the danger that a snooping implementation breaks newer features of the routing protocol it wasn't designed to handle, which probably couldn't have been predicted in the first place. For example, switches using IGMP (v2) snooping implementations that get hit with IGMP version 3 messages end up breaking IGMPv3. Rip 🥀

In summary, PIM is still evolving, so the approach RGMP takes is the safest one for the immediate problems at hand. Extensions like the ones listed should be considered in time, once there's actual demand 🌈 (PIM) snooping is a valid alternative once the total number of features that need support makes it just as attractive (complexity-wise) as a dedicated protocol, and as long as its functions are well defined so its effects can be predicted. But it always comes at the price of possible incompatibilities with upcoming PIM protocol extensions, unless support for layer 2 switches is explicitly considered as PIM protocols move forward. Main character energy for RGMP, fr 💖

Authors' Addresses

Ishan Wu 🧑‍💻 cisco Systems 170 West Tasman Drive San Jose, CA 95134

Phone: (408) 526-5673 EMail: iwu@cisco.com

Toerless Eckert 🧑‍💻 cisco Systems 170 West Tasman Drive San Jose, CA 95134

Phone: (408) 853-5856 Email: eckert@cisco.com

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💜

📦 where this page comes from