INTERNET-DRAFT Router-port Group Management Protocol I. Wu Type: Informational T. Eckert Expires: December 2002 cisco Systems Tue, Jun 4 2002 Cisco Systems Router-port Group Management Protocol (RGMP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1] except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft documents RGMP, a protocol developed by Cisco Systems that is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. 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 RFC2119 [2]. 2. Introduction I. Wu, T. Eckert Informational - Expires December 2002 [Page 1] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 IGMP Snooping is a popular, but not well documented mechanism to restrict multicast traffic, in switched networks, to those ports that want to receive the multicast traffic. It dynamically establishes and terminates multicast group specific forwarding in switches that support this feature. The main limitation of IGMP Snooping is that it can only restrict multicast traffic onto switch ports were receiving hosts are connected directly or indirectly via other switches. IGMP Snooping can not restrict multicast traffic to ports where at least one multicast router is connected. It must instead flood multicast traffic to these ports. Snooping on IGMP messages alone is an intrinsic limitation. Through it, a switch can only learn which multicast flows are being requested by hosts. A switch can not learn through IGMP which traffic flows need to be received by router ports to be routed because routers do not report these flows via IGMP. In situations where multiple multicast routers are connected to a switched backbone, IGMP Snooping will not reduce multicast traffic load. Nor will it assist in increasing internal bandwidth through the use of switches in the network. In switched backbone networks or exchange points, where predominantly routers are connected with each other, a large amount of multicast traffic may lead to unexpected congestion. It also leads to more resource consumption in the routers because they must discards the unwanted multicast traffic. The RGMP protocol described in this document allows to restrict multicast traffic to router ports. To effectively restrict traffic, it must be supported both by the switches and the routers in the network. The message format of RGMP resembles that of IGMPv2 so existing switches that are capable of IGMP Snooping can easily be enhanced with this feature. Its messages are encapsulated in IP datagrams, with an IP protocol number of 2, the same as that of IGMP. All RGMP messages are sent with IP TTL 1, to destination address 224.0.0.25. This address has been assigned by IANA to carry messages from routers to switches [3]. RGMP is designed to work in conjunction with multicast routing protocols where explicit join/prune to the distribution tree is performed. PIM-SM [4] is an example of such a protocol. To keep RGMP simple, efficient and easy to implement, it is designed for switches to expect RGMP messages from only one source per I. Wu, T. Eckert Informational - Expires December 2002 [Page 2] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 port. For this reason, RGMP only supports a single RGMP enabled router to be connected directly to a port of an RGMP enabled switch. Such a topology should be customary when connecting routers to backbone switches and thus not pose a limitation on the deployment of 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. 2.1 Type There are four types of RGMP messages of concern to the router- switch interaction. The type codes are defined to be the highest values in an octet to avoid the re-use of already assigned IGMP type codes. 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 predates RFC3228 [9]. RGMP defines Type values which in RFC3228 are assigned to protocol testing and experimentation. This is not an operational issue for RGMP itself because only RGMP packets use the IP destination address 224.0.0.25. The Type values defined above are thus ONLY valid in conjunction with the RGMP destination address. 2.2. Checksum Checksum covers the RGMP message (the entire IP payload). The algorithm and handling of checksum are the same as those for IGMP messages as described in RFC2236 [5]. I. Wu, T. Eckert Informational - Expires December 2002 [Page 3] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 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 IP multicast group address of the group being joined or left. 2.4 IP header RGMP messages are sent by routers to switches. The source IP address of an RGMP packet is the sending interface IP address of the originating router. The destination IP address of an RGMP packet is 224.0.0.25. Switches supporting RGMP need to listen to packets to this group. 3. RGMP Protocol Description 3.1 RGMP Router side Protocol Description Backbone switches use RGMP to learn which groups are desired at each of their ports. Multicast routers use RGMP to pass such information to the switches. Only routers send RGMP messages. They ignore received RGMP messages. A Router enabled for RGMP on an interface periodically [Hello Interval] sends an RGMP Hello message to the attached network to indicate that it is RGMP enabled. When RGMP is disabled on a routers interface, it will send out an RGMP Bye message on that interface, indicating that it again wishes to receive IP multicast traffic promiscuously from that interface. When RGMP is enabled on an interface, a router sends an RGMP Join message out this interface for each group that it wants to receive traffic for from the interface. The router needs to periodically [Join Interval] re-send an RGMP Join for a group to indicate its continued desire to receive multicast traffic for it. 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]. When a router no longer needs to receive traffic for a particular group, it sends an RGMP Leave message for the group. For robustness, the router MAY send more than one such message. If IP multicast packets for an undesired group are received at a I. Wu, T. Eckert Informational - Expires December 2002 [Page 4] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 router from a switch, the router MAY send a RGMP Leave message for that group to the switch. These messages 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 that has the same MAC destination address as the undesired group (See RFC1112 [6] for MAC ambiguity). Such suppression of data triggered RGMP Leave messages SHOULD be configurable if supported. 3.2 RGMP Switch side Protocol Description A switch enabled for RGMP on a network consumes RGMP messages received from ports of the network and processes them as described below. If enabled for RGMP, the switch must NOT forward/flood received RGMP messages out to other ports of the network. RGMP on a switch operates on a per port basis, establishing per-group forwarding state on RGMP enabled ports. A port reverts into an RGMP enabled port upon receipt of an RGMP Hello message on the port, and a timer [5 * Hello Interval] is started. This timer is restarted by each RGMP Hello message arriving on the port. If this timer expires or if it is removed by the arrival of an RGMP Bye message, then the port reverts to its prior state of multicast traffic forwarding. Correct deployment of RGMP is one RGMP enabled router directly connected to a port on a switch that supports RGMP. The port on the switch MAY want to keep track of the IP originator address of the RGMP Hello and Bye messages it receives on that port. In the event of multiple RGMP IP originating addresses the switch MAY generate an alert to notify the administrator. The switch MAY also have a configuration option that will allow to disable RGMP in this situation and fall back to flooding IP multicast on that port, although this is a potentially dangerous option: By default, connecting two or more RGMP enabled routers to a switch port will cause intermittent black holing of IP multicast traffic towards these routers. Black holing occurs when a RGMP Leave is received from one router while the other router is still joined. This malfunction is not only easily recognized by the actual users connected through the routers, but it also adheres to the principle of a failure situation to rather cause less traffic than more. Reverting to flooding easily maintains the illusion that everything is working perfectly, only that the traffic constraining benefits of RGMP are not realized and probably congestion happens at a much later time than the misconfiguration and can then not easily be correlated with the cause anymore. I. Wu, T. Eckert Informational - Expires December 2002 [Page 5] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 Because routers supporting RGMP are not required to send RGMP Join or Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and 224.0.1.40, RGMP enabled ports always need to receive traffic for these groups. Traffic for other groups is initially not forwarded to an RGMP enabled port. RGMP Join and Leave messages are accepted if they arrive on an RGMP enabled port, otherwise they will be discarded. Upon acceptance of an RGMP Join message, the switch MUST start forwarding traffic for the group to the port. Upon acceptance of an RGMP Leave message, the switch SHOULD stop forwarding traffic for the group to that port. The switches ability to stop forwarding traffic for a group may be limited for example because of destination MAC based forwarding in the switch, which makes it necessary for the switch to always forward traffic for all MAC-ambiguous IP multicast groups (see [5] for MAC-ambiguity). To stop forwarding of traffic for a group in the event of lost RGMP Leave message(s), a switch MAY time out RGMP forwarding state on a port for a group [5 * Join Interval] after the last RGMP Join for that group has been received on the port. By default a switch needs to flood multicast traffic to all ports. If a switch supporting RGMP does concurrently also provide for other mechanisms to constrain multicast traffic forwarding, then the switch must be able to get IP multicast traffic also flooded to a port connected directly or indirectly to an IP multicast router. Compliance with this specification requires a switch to be able to elect a port for flooding through the presence of PIM Hello messages [4] arriving from a port and also through a configuration option to support routers not supporting PIM. In addition, the switch can of course also recognize a port connected to a router by other appropriate protocol packets or mechanisms. Further mechanisms for IP multicast traffic restriction may also be used on RGMP enabled ports. In this case, 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 face of potential layer 2 network topology changes, RGMP does not specify how to restrict multicast traffic on links connecting switches amongst I. Wu, T. Eckert Informational - Expires December 2002 [Page 6] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 each other. With just RGMP being used, multicast traffic will thus be flooded on inter-switch links within a network if at least one router is connected to each of the switches. This happens implicitly because the switch will not flood/forward received RGMP messages out to the inter-switch link and thus the switch on the other end will only recognize the port as a router port via the PIM Hello messages flooded by the switches. Manual configuration for inter-switch links may be required if non-PIM routers are being used, depending on the other capabilities of the switch. A switch can of course - if appropriate - send out RGMP messages on ports to make it look like an RGMP enabled router to a potential switch at the other end of the link. This would allow to constrain IP multicast traffic between switches, but this type of "RGMP Spoofing" by the switch is outside the scope of this specification. 4.2. Interoperability with RGMP-incapable routers Since RGMP messages received at a switch only affect the state of their ingress ports, the traffic restriction is applied there only. RGMP-incapable routers will receive multicast traffic for all multicast groups. 4.3. RGMP and multicast routing protocols One result of the simplicity of RGMP are its restrictions in supporting specific routing protocols. The following paragraphs list a few known restrictions. A router running RGMP on a switched network will not receive traffic for a multicast group unless it explicitly requests it via RGMP Join messages (besides those group ranges specified to be flooded in 3.1). For this reason, it is not possible to run a protocol like PIM Dense-Mode or DVMRP across an RGMP enabled network with RGMP enabled routers. In Bidir-PIM, a router elected to be the DF must not be enabled for RGMP on the network, because it unconditionally needs to forward traffic received from the network towards the RP. If a router is not 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 not be supported if the elected DR is running RGMP, because this DR needs to unconditionally receive traffic from directly connected sources to trigger the PIM-SM registering process on the DR. In PIM-SSM, I. Wu, T. Eckert Informational - Expires December 2002 [Page 7] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 directly connected sources can be supported with RGMP enabled routers. Both in PIM-SM and PIM-SSM, upstream routers forwarding traffic into the switched network need to send RGMP Joins for the group in support of the PIM assert process. 5. List of timers and default values 5.1. Hello Interval The Hello Interval is the interval between RGMP Hello messages sent by an RGMP-enabled router to an RGMP-enabled switch. Default: 60 seconds. 5.2. Join Interval The Join Interval is the interval between periodic RGMP Join messages sent by an RGMP-enabled router to an RGMP-enabled switch for a given group address. Default: 60 seconds. 6. Security Considerations We consider the ramifications of a forged message of each type. Hello Message: A forged RGMP Hello message from a machine could restrict multicast data toward itself. It has no adverse effect to other machines. Bye Message: A forged RGMP Bye message from a machine could turn a segment of a switched network to be RGMP-disabled. Even then, this segment will get no more multicast data than what it may get without this protocol. Join Message: A forged RGMP Join message from a machine could attract undesired multicast packets to the port where it is received. Even then, this port will get no more data than what it may get without this protocol. Leave Message: A forged RGMP Leave message from a machine could restrict I. Wu, T. Eckert Informational - Expires December 2002 [Page 8] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 multicast data toward itself. It has no adverse effect to other machines. These issues can best be avoided by never connecting multiple systems onto a single port in a switched network, or at least by never putting a router and hosts onto the same port. Misconfiguration as described in section 3.2 - putting more than one router on a port - may lead to black holing. In this respect, physical integrity of router ports is required to avoid such an effect. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. 3 Internet Multicast Addresses, ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses 4 Estrin, D., et al, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC2362, June 1998 5 Fenner, W., "Internet Group Management Protocol, Version 2", RFC2236, November 1997 6 Deering, S., "Host Extensions for IP Multicasting", RFC1112, August 1989. 7. ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) Bridges", 1998. 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)", RFC3228, February 2002 8. Acknowledgments The authors would like to thank Gorry Fairhurst, Bill Fenner, Giovanni Meo, Mike Norton, Pavlin Radoslavov and Alex Zinin for their review of the document and their suggestions. I. Wu, T. Eckert Informational - Expires December 2002 [Page 9] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 9. Author's 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 10. Revision History A record of changes which will be removed before publication. (1) Fixed typographic details as per Gorry Fairhurst. (2) Corrected protocol behavior description (legacy text that incorrectly made it into -01). a) Sending of data triggered RGMP Leave messages and their suppression due to MAC ambiguity is optional. b) Switches maintaining per group join timers is optional. c) Switches may want to recognize misconfiguration (connection of more than one router to a port). (3) The Intellectual Property Rights appendix (A.) was modified to indicate claims. (4) An appendix to compare RGMP against GARP/GMRP was added. (5) An appendix to discuss possible future extensions and a comparison against PIM Snooping was added. (6) An acknowledgment section was added. (7) A note about RFC3228 and RGMPs use of experimental Type fields was added. (8) Added security consideration about physical misconfiguration. Appendix A. Intellectual Property Rights I. Wu, T. Eckert Informational - Expires December 2002 [Page 10] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 Cisco has submitted a patent claim covering RGMP technology. Appendix B. Comparison with GARP/GMRP This appendix is not part of the RGMP specification but is provided for information only. GARP/GMRP (defined in IEEE 802.1D [7]) is the ANSI/ISO/IEC/IEEE protocol suite to constrain ethernet multicast traffic in bridged ethernet networks. As such it is also a possible alternative to RGMP for the purpose of constraining multicast traffic towards router ports. This appendix will explain the motivation not to rely on GARP/GMRP and how GARP/GMRP and RGMP differ. The key factor in rolling out GARP/GMRP would have been to completely replace IGMP Snooping. This was the design goal of GARP/GMRP. For efficient operations, IGMP Snooping requires hardware filtering support in the switch (to differentiate between hosts membership reports and actual IP multicast traffic). Especially in many older switches this support does not exist. Vendors tried to find a way around this issue to provide the benefit of constraining IP multicast traffic in a switched LAN without having to build more expensive switch hardware. GARP/GMRP is one protocol resulting from this. CGMP from Cisco is another one. While CGMP solves the problem without requiring changes to the host stack software, GARP/GMRP requires support for it by the host stack. This dependency is the main reason for GARP/GMRPs missing success in the market. Although GARP/GMRP was heavily promoted by individual vendors, it has so far not made significant inroads into deployed solutions. IGMP Snooping (and CGMP) are the norm for this environment. In result, GARP/GMRP can not necessarily be expected to be supported by layer 2 switches. In addition, GARP/GMRP does not address clearly the issues RGMP tries to solve. On one hand, GARP/GMRP provides much more functionality and as such complexity as immediately required. On the other hand, GARP/GMRP is limited by being a standard predominantly for the Ethernet scope. Beyond the process and applicability reasons, the main differences between GARP/GMRP and RGMP are as follows: o 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 protocol approach is meant to simplify implementation, operations and troubleshooting. o The same switch running RGMP in a backbone network will likely I. Wu, T. Eckert Informational - Expires December 2002 [Page 11] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 see more states then running on the edge only doing IGMP Snooping, making it preferable to keep the amount of per group processing and memory requirements in RGMP more in bounds than possible in IGMP Snooping and GARP/GMRP: In GARP/GMRP, a (multiple) timer based state-machines needs to be maintained on a per ethernet group address, in RGMP timer maintenance is completely optional and there are only two states per group (joined or not joined). o GARP/GMRP is an ethernet level protocol from the IEEE. It supports to constrain traffic for ethernet addresses (groups). RGMP does constrain traffic for IP multicast groups. Today this is even beyond the capabilities of typical switch platforms used as layer2 switches. Extensions to support further entities are likely easier to come by through extensions to RGMP than to GARP/GMRP. o RGMP shares the basic packet format with IGMP (version 2) and is as such easy to add to router and switch platforms that already support IGMP respectively IGMP Snooping. This is especially true for switches that in hardware can differentiate between IGMP protocol type packets and other IP multicast traffic sent to the same (or a MAC ambiguous) group. In addition, due to the state simplicity of RGMP it is easy to integrate IGMP Snooping and RGMP operations in a switches IP multicast control and forwarding plane. o 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 not a common scenario in today's switches layer 2 networks, it is also an undesired configuration when unwanted IP multicast traffic is to be kept away from routers. o GARP/GMRP defines how to constrain multicast traffic between switches, another reason for its complexity. RGMP does not explicitly support this as part of the protocol because of the following reasons: o It is not necessary to include this function as part of the RGMP protocol description because switch implementations can transparently decide to support this function (see 4.1 about this "RGMP Spoofing"). o Important deployments through which large amounts of IP multicast are moved today are typically single switch. MIX - Multicast Internet eXchange points. o Avoiding congestion on inter-switch links in general is more I. Wu, T. Eckert Informational - Expires December 2002 [Page 12] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 complex than simply constraining ip multicast traffic to paths where it is needed. With or without IP multicast, the aggregate bandwidth needed between switches can easily be the aggregate required bandwidth to routers on either sides. For this reason, inter-switch bandwidth is most often appropriately over provisioned. In addition, the likelihood for receiving routers to be only on the sources side of an inter-switch link is in general deployments rather low. The cases where traffic constrainment on inter-switch links is required and helpful is thus 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, 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. This appendix presents a discussion of possible extensions to RGMP. Included are points on why the extensions are not included and in addition a motivation for RGMP in comparison to (PIM) snooping. o Support for multiple switches As discussed in "RGMP Spoofing", chapter 4.1 and GARP/GMRP comparison in Appendix B. o Support for SSM While RGMP works with PIM-SSM, it does not have explicit messages for the router to selectively join to (S,G) channels individually. Instead the router must RGMP join to all (Si,G) channels by joining to G. Extending RGMP to include (S,G) Join/Leaves is feasible. However, currently the majority of switches do not support actual traffic constraining on a per channel basis. In addition, the likelihood for actual channel collision (two SSM channels using the same group) will only become an issue when SSM is fully deployed. o Support for IPv6 RGMP could easily be extended to support IPv6 by mapping the RGMP packet format into the MLD/IPv6 packet format. This was not done for this specification because most switches today do not even support MLD snooping. I. Wu, T. Eckert Informational - Expires December 2002 [Page 13] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 o Support for multiple routers per port As discussed in Appendix B. This is probably one extension that should be avoided. Multiple RGMP router per port are inappropriate for efficient multicast traffic constrainment. o Support for non-join based protocols / protocol elements For protocols like PIM dense-mode, DVMRP or Bidir-PIM DF routers, additional RGMP messages may be added to allow routers to indicate that certain group (ranges) traffic need to be flooded from (dense-mode) or to (Bidir-PIM) them. o Support for multi-policy switching In Multicast Exchange Points (MIXes) environments situations exist where different downstream routers for policy reasons need to receive the same traffic flow from different upstream routers. This problem could be solved by actually providing an upstream neighbor field in RGMP Join/Leave messages. The RGMP switch would then forward traffic from one upstream router only to those downstream routers who want to have the traffic from exactly this upstream router. This extension would best go in hand with 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. If all the above possible future extensions were to be 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 IP routing protocol run between routers in a switched LAN. From the perspective of protocol architecture it is certainly more appropriate to have a separate protocol like RGMP or GARP/GMRP for this purpose. Then again, the more complex the requirements are, the more duplication of effort is involved and snooping seems to become a more attractive option. Even though there exists one predominant routing Protocol, PIM, in IP multicast, routing with PIM in itself is extremely complex for a switch to snoop into. PIM has two main versions, different modes - sparse, dense, bidir, ssm, join / prune / graft messages (depending on the mode of the group), various PIM Hello options, different versions of asserts, two dynamic mode announcement protocols (BSR, AutoRP), and finally supports both IPv4 and IPv6. I. Wu, T. Eckert Informational - Expires December 2002 [Page 14] INTERNET-DRAFT Router-port Group Management Protocol Jun 4 2002 A switch snooping into PIM is very likely to implement just a subset of this feature set, making it very hard for the user to determine what level of actual traffic constrainment is achieved unless a clear specification exists for the implementation (or better the method per se.). In addition, there is always the danger that such a snooping implementation may break newer features of the routing protocol that it was not designed to handle (likely because they could not have been predicted). Exactly this, for example, happens with switches using IGMP (v2) snooping implementations are being subjected to IGMP version 3 messages - they break IGMPv3. In summary, with PIM still evolving, the approach taken by RGMP is the safest one for the immediate problems at hand, and extensions like those listed should be considered in time for actual demand. (PIM) snooping is a valid alternative once the total amount of features that need to be supported makes it an equally attractive solution (with respect to complexity) to a dedicated protocol and if its functions are well defined to allow predicting its effects - but always at the price of possible incompatibilities with upcoming PIM protocol extensions unless support for layer 2 switches is explicitly considered in moving PIM protocols forward. I. Wu, T. Eckert Informational - Expires December 2002 [Page 15]