INTERNET-DRAFT Router-port Group Management Protocol I. Wu Type: Informational T. Eckert Expires: January 2002 cisco Systems Fri, Jul 13 2001 Router-port Group Management Protocol 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 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]. I.Wu, T. Eckert Informational - Expires January 2002 [Page 1] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 2. Introduction 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. It's limitation is that it can only restrict traffic on those ports of switches to which only hosts are connected. It can not restrict traffic to ports to which at least one multicast router is connected, but instead it must flood traffic to those ports. This is an intrinsic limitation because by snooping on just IGMP messages, a switch can only learn which multicast traffic is requested by hosts, but not which traffic needs to get forwarded to routers for the purpose of being routed by it - routers are not required to report these memberships via IGMP. In situations where multiple multicast routers are connected to a switched backbone, IGMP Snooping will thus not have the desired effect of reducing multicast traffic and increasing the internal bandwidth through the use of switches in the network. In switched backbone networks or exchange points, where predominantly routers are connected with each others, large amount of multicast traffic may thus lead to unexpected congestion on the router ports and to a waste of CPU-cycles in the routers needed to discard the unwanted multicast traffic. RGMP is described in this document 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 could be easily 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 to for switches to expect RGMP messages from only one source per port. For this reason, RGMP only supports a single RGMP enabled router or RGMP enabled switch to be connected directly to a port of an RGMP enabled switch or indirectly to such a port via one or more I.Wu, T. Eckert Informational - Expires January 2002 [Page 2] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 non-RGMP enabled switches. 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. 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]. 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. I.Wu, T. Eckert Informational - Expires January 2002 [Page 3] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 2.4 IP header RGMP messages are sent by routers to switches. The source ip address of an RGMP packet is the emitting 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. 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 router's 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 the 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 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. 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. If undesired multicast packets are received at a router from a switch, the router may send an RGMP Leave message to the switch. This message should be rate-limited. Before the RGMP Leave message is sent in this situation, a router should check that the data is not needed for the group and any other groups that share the same MAC layer multicast destination address. This MAC/IP multicast address ambiguity is described in RFC1112 [6]. 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 I.Wu, T. Eckert Informational - Expires January 2002 [Page 4] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 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. 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, a timer [5 * Join Interval] is started, which is coupled with the forwarding state for this group on this port. This timer is restarted by further RGMP Join messages for the group arriving on the port. If the timer expires or if it is removed by the arrival of an RGMP Leave message for the group on this port, then the forwarding state for this group is removed from this port as far as RGMP is concerned. 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 support 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. I.Wu, T. Eckert Informational - Expires January 2002 [Page 5] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 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 to restrict multicast traffic on links connecting switches amongst 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 achieve inter-switch traffic constrainment, 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. I.Wu, T. Eckert Informational - Expires January 2002 [Page 6] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 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, 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. I.Wu, T. Eckert Informational - Expires January 2002 [Page 7] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 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 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. 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. 8. Acknowledgments I.Wu, T. Eckert Informational - Expires January 2002 [Page 8] INTERNET-DRAFT Router-port Group Management Protocol Jul 13 2001 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 I.Wu, T. Eckert Informational - Expires January 2002 [Page 9]