Ishan Wu Internet Draft Toerless Eckert Document: <draft-wu-rgmp-00.txt> cisco Systems Category: Informational November 2000 Expires: June 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]. Informational - Expires June 2001 1 Router-ports Group Management Protocol November 2000 2. Introduction IGMP Snooping is a popular, but not well documented, mechanism to restrict multicast traffic in switched networks to those ports that may need to receive the multicast traffic. It dynamically establishes and terminates multicast group specific forwarding in switches that support this feature. It restricts traffic on those ports of switches to which only hosts are connected and does not restrict traffic to ports to which at least one multicast router is connected. With IGMP Snooping, any multicast traffic sourced by any router or host on a switched network will be forwarded to all routers. 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. 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 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 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. Informational - Expires June 2001 2 Router-ports Group Management Protocol November 2000 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. 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. Informational - Expires June 2001 3 Router-ports Group Management Protocol November 2000 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 switched 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 promiscously from that interface. When running RGMP on an interface, a router sends an RGMP Join message out the interface for each group that it wants to receive traffic from the interface. The router needs to periodically [Join Interval] resend an RGMP Join for a group to indicate its continued desire to receive multicast traffic for the given group. 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 RGMP on a switch operates on a per port basis, establishing per-group forwarding state on RGMP capable ports. A port reverts into an RGMP capable 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 capable ports always need to receive traffic for these groups. Traffic for other groups is initially not forwarded to an RGMP capable ports. Informational - Expires June 2001 4 Router-ports Group Management Protocol November 2000 RGMP Join and Leave messages are accepted if they arrive on an RGMP enabled port, otherwise it 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 will flood multicast traffic to all ports. If a switch supporting RGMP does concurrently also provide for other mechanisms to restrict 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 such a switch to be able to elect a port for flooding through the presence of PIM Hello messages [4] arriving from a port and through a configuration option. Further mechanisms for ip multicast traffic restriction may also be used on RGMP capable 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 and resilient in face of possible network topology changes, RGMP does not try to restrict multicast traffic on links connecting switches amongst each other. If another mechanism to restrict multicast traffic in the network is used in conjunction with RGMP, then the mechanism to detect routers and flood to their ports is used as part of RGMP to ensure flooding of multicast traffic between switches. For routers running PIM and thus sending PIM Hello messages, no manual configuration is required to set up a network with multiple switches. 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. Informational - Expires June 2001 5 Router-ports Group Management Protocol November 2000 A router running RGMP on a switched LAN 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 LAN with RGMP enabled routers. In Bidir-PIM, a router elected to be the DF must not be enabled for RGMP on the LAN, because it unconditionally needs to forward traffic received from the LAN towards the RP. If a router is not the DF for any group on the LAN, it can be enabled for RGMP on that LAN. In PIM-SM, directly connected sources on the LAN are not 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 LAN 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-incapable. Even then, this segment will get no more multicast data than what it may get without this protocol. Informational - Expires June 2001 6 Router-ports Group Management Protocol November 2000 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. 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 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 Informational - Expires June 2001 7