Disclaimer: The following text include the original design documents for CGMP and for CGMP fast-leave support with IGMPv2. This file is provided here to help customers in understanding of CGMP and its effects on IP Multicast traffic delivery within a switched LAN. This information is solely provided on an "as is" basis. The availability of this file must not be construed as an explicit or implied guarantee or warrante for Cisco IOS to be conformant with this specification, or for Cisco to provide any specific support for it. 2/2001 Notes: [CSCdj19501, 1997] The actual implementation of CGMP support for IGMPv2 leave message processing is slightly different than described below in the original specification. Instead of sending an IGMPv2 group specific query, the CGMP switch actually sends a IGMP general query on the port where the IGMPv2 leave was received from. The MAC destination address of the general query is set to the MAC address of the multicast group for which the IGMPv2 leave was received. Sending an IGMP general query is necessary because the switch needs to determine if there is at least one other host (on the port in question) interested in at least one of the 32 multicast groups that are MAC mapping into the MAC address of the group for which the IGMPv2 leave was received: The switch can not keep track of which multicast groups are actually joined to on a port, only the MAC groups that are joined. The MAC destination address of the general query is set to the MAC address in question to limit the responses from hosts to those hosts that actually are joined - if a host is not joined to a group mapping to that MAC address, then it will also ignore that general query. Such an IGMP general query packet is in compliance with the IGMPv2 protocoll specificaition. ------------------------------------------------------------------------------- Cisco Group Management Protocol (CGMP) -------------------------------------- Dino Farinacci and Alex Tweedly 08/14/96 Overview: This proposal is related to the Catalyst 5000 platform only. It is a short-term solution since the hardware cannot tell the difference between IP multicast data packets and IGMP Report messages which are both MAC level addressed to the same group address. Therefore, the Catalyst 1200 IGMP functionality cannot be implemented in the Catalyst 5000. Support is required in both the IOS based router and the Catalyst 5000 switch. This scheme may be applicable to other switch families, to be determined later. Goals: o Legacy IP multicast hosts (that run IGMP v1 or v2 only) can send and receive IP multicast packets through a switched network. o Reduce broadcast flooding over the switched network for IP multicast traffic. o Interoperates with the Catalyst 1200 switch. o Support multiple hosts on a single LAN connected to a switch. o Deals with host (that are attached to the switched network) moves. o Requires no host changes. Constraints: o Join latency will be increased slightly. The time to join a group is directly related to the time it takes for switches to propagate IGMP Reports through the switched network plus the time it takes a router to generate a CGMP message and for it to be propagated to the reporting host through the switched network. o Since leave processing cannot be implemented, because the switches can't intercept Report suppression, multicast packets for a group will be forwarded indefinitely throughout the switched network as long as there is at least 1 member. However, if the group disappears entirely, the router sends a CGMP Leave message to clear out the state for all switches in the switched network. o For switched networks that don't have a router attached, we are in broadcast mode, with a possible optimization of forwarding only to those ports which have been multicast capable/active. Basic Idea: Joining Groups: o Hosts send IGMP Reports for groups they wish to join. Switches will forward the Reports out the ports that are cached in the bridge forwarding table for the group address the Report is sent to. o When a router receives the IGMP Report, it will build a CGMP Join message and multicast it to 0100.0cdd.dddd. The CGMP Join message contains the MAC addresses of the group and the host that sent the IGMP Report. o Each switch that receives the CGMP Join message will add the port the host resides on to the bridge forwarding table entry for the group. Leaving Groups: o When a router detects there are no members left in the switched network, it will send an CGMP Leave message to 0100.0cdd.dddd including a MAC level host address of 0000.0000.0000 in the message. All switches process this by deleting the bridge forwarding table entry for the group specified in the message. Issues: o When the switch has a fully populated bridge forwarding table entry for a group address, and subsequent IGMP Reports are forwarded for that group, Report suppression may occur by host members anywhere across the switched network. This can be a problem with IGMP v1 hosts because the only way to tell if the last group member has left the group is by receiving no Reports. This case cannot be distinguished from the Report suppression case. The result of this is indefinite forwarding to this segment for the group that passively left by the last member. o With IP multicast active in a non-switched network, the number of IGMP packets is 1 query + N reports (where N is the number of active groups on the subnet). Total (N + 1). With this scheme, we have 1 query + N reports + N CGMP Joins. Total (2N + 1). However, Report suppression is obtained on the router segment (and throughout the switched network). Opposed to the Catalyst 1200 functionality which gives you 1 Report per group per member switch. CGMP Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Reserved | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GDA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GDA | USA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | USA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Ver (4 bits) - Version field is always set to 1. Any other version numbers are ignored at this time. Type (4 bits) - 0 = Join 1 = Leave Reserved (2 bytes) - must be set to 0 and ignored on receipt. Count (1 byte) - The number of GDA/USA pairs in the message. GDA (6 bytes) - Group Destination Address IEEE MAC level group address in canonical format. For IP, it is the RFC 1112 converted address from a class D IP multicast address. This could be a unicast address, but this is under further study. 0000.0000.0000 is the all-groups address and is used when routers send CGMP Join/Leave messages so switches can populate router ports. USA (6 bytes) - Unicast Source Address IEEE MAC level unicast address in canonical format. This must not be a group address. This is the address of the host which originated the IGMP Report which this CGMP message is being generated for. A switch will lookup this address from its bridge forwarding table. It obtains the port associated with the address. This is the port the host is either directly connected to or is reachable via another switch. For Join messages, this port is added to the the group address entry in the bridge forwarding table. For Leave, messages, this port is deleted from the entry, if and only if it is not a router port. If USA = 0000.0000.0000, then all ports are deleted for the specified group address. Encapsulation: CGMP messages will be encapsulated within SNAP formatted frames, using cisco's ORG ID of 0x00000c with ethertype value of 0x2001. The following header is prepended to the above CGMP message to construct the entire frame. MAC header 802.2 header: aa aa 03 SNAP header: 00 00 0c 20 01 CGMP header The source MAC address will be the router's MAC address for the interface the CGMP packet is sent on. The destination MAC address is a cisco specific link layer multicast address 0100.0cdd.dddd. Forwarding Rules: Since the switched network will be in a spanning tree loop-free topology, IGMP Reports will be forwarded along a specific path to reach a router. In turn, the CGMP packets will flow on the reverse path as the IGMP Reports. This happens since both messages are sent as multicasts (even though they are different MAC level multicast addresses) which are all forwarded along the same spanning tree. Therefore, no loop avoidance or routing of CGMP messages needs to be explicitly supported. Switch Cache Population Rules: o If a switch receives an IGMP Report which it has no bridge forwarding table for the MAC level destination group address, it will *not* forward the packet in hardware. The NMP will create an entry and populate the outgoing port list with the ports in the router port table (if any exists). Note this is not the case for IGMP Queries which are sent on all non-blocking ports (except the port the message was received on). o A switch needs to forward multicast data packets from "switched network sources" towards routers. The router ports are determined when a router sends a CGMP Join with GDA equal to 0000.0000.0000 and an USA equal to its own MAC address on the interface where the switched network resides. This avoids the need for the Catalyst 5000 to listen for IGMP or PIM Queries since it has limited resources for MAC level address recognition. o There is an issue when there are multicast sources only in the switched network (i.e. no group members). Since the Catalyst 5000 cannot populate the bridge forwarding table at packet forwarding time, the router will send CGMP Joins with GDA equal to the group address the source sent to with a USA of the router's MAC address. The IGMP querier router is the only one that does this as long as it detects there are no group members on the LAN (if there were group members CGMP Joins would be sent with a USA equal to the member's MAC address). o If a switch receives a multicast data packet or an IGMP Report which it has a bridge forwarding table entry for the MAC level destination group address, it simply forwards it (in hardware) according to the ports that exist in the outgoing port list. This design is based on the fact that the NMP cannot receive Reports after the bridge forwarding table is populated because the hardware is doing the forwarding and doesn't do special checks for IGMP Reports. o If the switch receives an CGMP Join message, it looks up the USA address in the bridge forwarding table and adds the port correpsonding to the host to the outgoing port list for the group address entry in the bridge forwarding table. If the USA address does not exist, do nothing. o If the GDA is 0000.0000.0000, add the port the USA address resides on to the switches router port table. In addition, the port must be added to all existing group-based entries. If the USA address does not exist, add the port the CGMP Join was received on to the router port table. This handles the case when a router has not send any packets so the switch has not learned where it is. o Routers will send CGMP Join messages periodically for their own MAC address to keep the router port table state alive in switches. o If a switch receives an CGMP Join message and there is no corresponding bridge forwarding table entry for the group address, it creates one and follows the rules in bullet 4. When it creates an entry, it must add all router ports to the entry in addition to the port that the USA address resides on. Switch Port Deletion: o If the switch receives an CGMP Leave message, it looks up the USA address in the bridge forwarding table and deletes (if it exists) the port correpsonding to the host from the outgoing port list for the group address entry in the bridge forwarding table. If the USA address does not exist, do nothing. If the GDA does not exist, do nothing. If the USA is 0000.0000.0000, delete the entry from the bridge forwarding table. o If the GDA is 0000.0000.0000, delete the port that USA address resides on from the router port table. Also delete the port from the bridge forwarding table for all groups if and only if there are no members on the port (that were populated by previous group-specific CGMP Joins). This implies the switch must keep track of at least one other USA that is not a router's address. o If both the GDA and USA are 0000.0000.0000, this is a cleanup message for the switch. The switch will delete its entire bridge forwarding table for all IP multicast addresses. The router port table is not affected. o When the last port of an outgoing port list is deleted from a bridge forwarding table entry, the entry is deleted to reduce state switches have to keep. o Switches can time out ports from the router port table. Since routers send CGMP Joins for their own MAC address periodically, the switches is able to know when the router port is still active. Interoperability with non-cisco switches: o Non-CGMP capable switches will merely forward IP multicast packets to CGMP capable switches. The protocol can run over non-cisco switches at the expense of indefinite flooding for all groups. o For the Catalyst 1200, a further optimization is performed since it *can* process IGMP Reports. However, the Catalyst 1200 must distinguish a CGMP message from a CDP message (since both are addressed to the CDP multicast address). CDP messages must be processed internally, not forwarded, and CGMP messages must be flooded like broadcast packets. Interoperability with non-cisco routers: o Since routers expect packets from sources on the switched network, they deliver them by discovering router ports. Since this is done with CGMP, non-cisco routers will not send CGMP packets and won't get discovered. Therefore, when a cisco router interoperates with a non-cisco router doing IGMP or any multicast routing protocol, it will send CGMP Joins/Leaves for the MAC adddress associated with non-cisco router. We call this function CGMP Proxy. o The ciscos will be configured on a per interface basis if they should perform CGMP Proxy. If more than one router is configured to do so, only one will send the Proxy Joins/Leaves. o The IGMP querier will be the CGMP Proxy sender. The network adminstrator must force a cisco to be the IGMP querier by assigning its IP address appropriately. o A CGMP Proxy Join/Leave contains a GDA of 0000.0000.0000 and a USA equal to the MAC address of the non-cisco/CGMP router. ------------------------------------------------------------------------ CGMP Leave Processing --------------------- Dino Farinacci Tony Speakman 01/14/97 1.0 Introduction This is an extension to the basic CGMP protocol specification to improve Leave latency for IGMPv2 connected hosts on switched-based networks. These extensions will require only modifications to switches only. This proposal adds no more messages to the CGMP protocol. However, it requires switches to do some IGMPv2 protocol processing (a very small subset of IGMPv2). 2.0 Sequence of Events 1) Host leaves group. 2) Switch queries for other members on segment. 3) If none found in a specific amount of time, segment is deleted from group entry. Otherwise, segment remains in group entry. 4) When a segment is deleted from a group entry, and it is the last segment in the group entry, the switch sends a Leave message on all router ports. 3.0 Details 1) When a host leaves a group, it sends an IGMP Leave message to 224.0.0.2. We can count on implementations sending this message unconditionally when they leave a group. 2) A switch will hear the IGMP Leave messages and will be able to process them. A switch processes an IGMP Leave message by sending an IGMP group specific Query (GS Query) on the segment the Leave message was received on. A switch does not forward IGMP Leave messages. The switch will include a Deletion-Timer value (in seconds) in the GS Query message and start an interface deletion timer based on this value for the specific group. The hosts that receive the GS Query will set a random delay timer between 1 and the (Deletion-Timer*10) (per IGMPv2 spec). 3) If there are other members for the group on the segment the Leave was sent on, they will respond to the GS Query within Deletion-Timer*10 seconds with an IGMP Report. Since the switch cannot hear the IGMP Report, it will be layer-2 forwarded to a multicast router. The router will in turn, send an CGMP Join for the group/reporter. When the switch receives the CGMP Join for a group for a segment that has the deletion timer running, it will cancel the timer and keep the segment in its outgoing interface list for the group. It the deletion timer expires and no CGMP Join message is received, then the segment is deleted from the outgoing interface list for the group entry. 4) When a switch deletes the last segment from its outgoing interface list for a group entry, it will send an IGMP Leave message to all router ports it has learned. This allows upstream switches to perform the same actions as if a host has left the group. If the last member has left the switched network, the router will delete the port from its IGMP cache and do the necessary multicast route pruning. 4.0 Race Conditions There may arise the case where a general Query interval is in effect and a switch needs to send an GS Query due to a leaving host. Rather than sending the GS Query right away and risk another host (on another segment) suppressing a colocated member host with the leaving host, it should delay sending the GS Query. The delay should be the time left in the general Query interval. This does mean that a switch must listen to general Querys and set a timer per group for the general Query interval. Likewise, the case may exist where a switch has sent a GS Query and then a general Query is sent. This case may also cause inadvertent suppression of a colocated member host with the leaving host. When a switch hears a general Query and a deletion timer is running for a group, it needs to send the GS Query again after the general Query interval has expired.