Requirements for IP Multicast
| IP multicast is not a new concept; Steve Deering wrote the first RFC on multicast host requirements in 1986.[1] But it is only in the past few years that interest in multicasting has really taken off, as enterprises present increasing demands for one-to-many and many-to-many communications. Examples of one-to-many applications include video and audio feeds for distance learning or company news, software distribution, network-based entertainment programs, news and stock updates, and database or Web site replication. The classic many-to-many application is conferencing, including video, audio, and shared whiteboards . Multiplayer games are another many-to-many application, although most corporations would be loath to include them on a wish list. As the use of such group -based applications increases , the efficiency and performance advantages of multicast over broadcast and replicated unicast for packet delivery become more attractive. You must make a variety of protocol choices when implementing IP multicast. Because of this, multicast is presently found primarily in enterprise networks where a single administrative authority can make the design choices. As the popularity of multicasting grows, however, customers are increasing their pressure on ISPs to support multicast across the Internet. Interest in multicast within ISPs is also growing as more and more replicated unicast traffic is sent across the Internet, eating up more and more bandwidth. Although corporations have been interested in multicast for some time, the "killer app" that will finally bring IP multicast to maturity will be entertainment over the Internet. Multicast has been researched for some time on a subset of the Internet known as the Multicast Backbone, or MBone. ISPs are also beginning to offer multicast services to their customers, such as UUNET's UUcast. However, ubiquitous availability of multicast services across the entire Internet must await further research and development of inter-AS protocols such as Multiprotocol BGP (MBGP) and Border Gateway Multicast Protocol (BGMP). Presently, no IP multicast routing protocols exist that support routing policies comparable to those supported by BGP. Until adequate tools for enforcing policy are introduced, it is unlikely that multicasting will find wide Internet acceptance. The three basic requirements for supporting multicast across a routed internetwork are as follows :
This section examines the basics of each of these requirements; subsequent sections examine the details of the various protocols that are currently available to meet the requirements. Multicast IP AddressesThe IANA has set aside Class D IP addresses for use as multicast addresses. According to the first octet rule, as described in Chapter 2, "TCP/IP Review," of Volume I, the first four bits of a Class D address are always 1110, as shown in Figure 5-4. Finding the minimum and maximum 32-bit numbers within this constraint, the range of Class D addresses is 224.0.0.0 “239.255.255.255. Figure 5-4. Class D Addresses Are in the Range 224.0.0.0 “239.255.255.255 Unlike the Class A, B, and C address ranges, the Class D range is "flat" ”that is, subnetting is not used, as demonstrated by Figure 5-5. Therefore, with 28 variable bits, 2 28 (more than 268 million) multicast groups can be addressed out of the Class D space. Figure 5-5. Unlike Class A, B, and C IP Addresses, Class D Addresses Do Not Have a Network Portion and a Host Portion A multicast group is defined by its multicast IP address; groups may be permanent or transient. Permanent refers to the fact that the group has a permanently assigned address, not that members are permanently assigned to the group. In fact, hosts are free to join or leave any group. Transient groups are, as you might guess, groups that do not have a permanent existence ”like a videoconference group. An unreserved address is assigned to the group and is relinquished when the group ceases to exist. Table 5-1 shows some of the well-known addresses assigned to permanent groups by the IANA. You have encountered most of these addresses before, when you studied the routing protocols to which they are assigned. For example, you know that on a multiaccess network, OSPF DRothers send updates to the OSPF DR and BDR at 224.0.0.6; the DR sends packets to the DRothers at 224.0.0.5. Table 5-1. Some Well-Known Reserved Multicast Addresses
The IANA reserves all the addresses in the range 224.0.0.0 “224.255.255.255 for routing protocols and other network maintenance functions. Multicast routers do not forward packets with a destination address from this range. There are also addresses outside of this range that are reserved for open and commercial groups; for example, 224.0.1.1 is reserved for the Network Time Protocol (NTP), 224.0.1.8 is assigned to SUN NIS+, and 224.0.6.0 “224.0.6.127 are assigned to the Cornell ISIS Project. Yet another reserved range is 239.0.0.0 “239.255.255.255. The use of this last group of addresses is discussed in the section "Multicast Scoping" later in this chapter. For a complete list of reserved Class D addresses, see Appendix C, "Reserved Multicast Addresses," or RFC 1700. A group member's network interface card (NIC) also must be multicast-aware. When a host joins a group, the NIC determines a predictable MAC address. To accomplish this, all multicast-aware Ethernet, Token Ring, and FDDI NICs use the reserved IEEE 802 address 0100.5E00.0000 to determine a unique multicast MAC. It is significant that the eighth bit of this address is 1; that bit, in the 802 format, is the Individual/Group (I/G) bit. When set, it indicates that the address is a multicast address. Multicasting Over Ethernet and FDDIEthernet and FDDI interfaces map the lower 23 bits of the group IP address onto the lower 23 bits of the reserved MAC address to form a multicast MAC address, as shown in Figure 5-6. Here, the Class D IP address 235.147.18.23 is used to create the MAC address 0100.5E13.1217. Figure 5-6. Multicast MAC Addresses on Ethernet and FDDI Networks Are Created by Concatenating the Last 23 Bits of the IP Address with the First 25 Bits of the MAC Address 0100.5E00.0000 You already have encountered a couple of these addresses. Recall that in Chapter 9, "Open Shortest Path First," of Volume I, it was briefly explained that the All OSPF Routers address 224.0.0.5 uses a MAC address of 0100.5E00.0005, and the All OSPF Designated Routers address 224.0.0.6 uses the MAC address 0100.5E00.0006. Now you know why. Because only the last 23 bits of the IP address are mapped to the MAC address, the resulting multicast MAC address is not universally unique. For example, the IP address 225.19.18.23 will produce the very same MAC address, 0100.5E13.1217, as 235.147.18.23. In fact, calculating the ratio of the total number of Class D addresses (2 28 ) to the number of possible MAC addresses under the reserved prefix (2 23 ) reveals that 32 different Class D IP addresses can be mapped to every possible MAC address! The IETF's position is that the odds of two or more group addresses existing on the same LAN producing the same MAC address are acceptably remote. On the rare occasion that such a conflict does arise, the members of the two groups on the LAN will receive each other's traffic. In most of these cases, each group's packets will be destined for different port numbers or possibly have different application layer authentication schemes; each group's members will discard the other group's packets at the transport layer or above. The benefits of this predictable MAC approach are twofold:
Multicasting Over Token RingMulticast over Token Ring networks is treated differently. Token Ring specifies functional or function-dependent MAC addresses to reach stations running such common TR functions as Active Monitor, Ring Parameter Server, and Ring Error Monitor. The first bit of the first octet of the TR MAC address is the I/G address, which indicates whether the address is unicast (I/G=0) or broadcast/multicast (I/G=1). The second bit is the Universal/Local (U/L) bit, which indicates whether the address is a manufacturer burned-in address (U/L=0) or a locally administered address (U/L=1). Additionally, the first bit of the third octet is the Functional Address Indicator (FAI). The job of the FAI is to distinguish functional addresses (I/G=1, U/L=1, FAI=0) from locally administered group address (I/G=1, U/L=1, FAI=1). A specific functional address is created by setting one, and only one, of the 31 remaining bits after the FAI. So, for example, the functional address of the Active Monitor is C000.0000.0001 and a bridge is reached at C000.0000.0100. Because only one of the 31 bits can be set, there are 31 available functional addresses. This rule has consequences for IP multicast. Token Ring MAC addresses use the little-endian format, in which each octet is read from right to left; Ethernet uses the big-endian format, in which each octet is read from left to right. Therefore, the Ethernet multicast MAC address of 0100.5E13.1217 would be read by Token Ring as 8000.7AC8.48E6. The FAI in this TR address is 0, but more than one of the following 31 bits is set to 1. Therefore, Token Ring interprets the address as an illegal functional address. NOTE FDDI also uses the little-endian format, but it does not use functional addresses such as Token Ring and therefore supports the same mapping scheme as Ethernet. Because IP addresses cannot be mapped into Token Ring addresses as they are into Ethernet addresses, another method must be found to resolve this issue. Currently, there are two methods for addressing TR frames carrying IP multicast packets:[2]
Cisco routers default to the first method and support the second method with the command ip multicast use-functional configured on TR interfaces. Both of these methods have drawbacks. The first method is inefficient, delivering multicast packets to all stations on the ring and relying on upper-layer protocols to accept or reject the packets. The second method can be used only if the TR NICs on all stations on the ring recognize the functional address. Not all NICs do. Another problem with the second method is that TR NICs that recognize a functional address send an interrupt to the station's CPU. If there is even moderate IP multicast traffic on the ring, and especially if there is multicast traffic for several different groups all mapped to the one functional address, host performance will suffer. Because of these limitations, Token Ring is a poor choice for supporting IP multicast. Group Membership ConceptsBefore a host can join a group, it (or its user ) must know what groups are available to be joined, and how to join them. Various mechanisms are available for advertising multicast groups, such as online "TV Guides," or Web-based schedules such as the one shown in Figure 5-7. Figure 5-7. One Way of Locating Multicast Groups Is Through Web-Based Announcements, Such as This Schedule of MBone Sessions at www.cilea.it/MBone/browse.htm There are also tools that utilize such protocols as Session Description Protocol (SDP) and Session Advertisement Protocol (SAP) to describe multicast events and advertise those descriptions. Figure 5-8 shows an example of an application that uses these protocols. A user also may learn of a multicast session by invitation , such as via a simple e-mail. Figure 5-8. Applications Such as Multikit Listen for SDP and SAP and Display the Multicast Sessions Advertised by Those Protocols A detailed discussion of these mechanisms is beyond the scope of this book. This section presumes that hosts have somehow learned of a multicast group, and it examines the issues around joining and leaving the group. After examining these issues, you will see how they are handled by the Internet Group Management Protocol (IGMP), the de facto protocol for managing IP multicast groups on individual subnets. Joining and Leaving a GroupInterestingly, the source of a multicast session does not have to be a member of the multicast group to which it is sending traffic. In fact, the source typically does not even know what hosts, if any, are members of the group. Receivers are free to join and leave groups at any time. This again fits the earlier analogy of a radio or television signal; audience members can tune in or tune out at any time, and the originating station has no direct way of knowing who is listening. If the source and all group members share a common LAN, no other protocols are required. The source sends packets to a multicast IP (and MAC) address, and the group members "tune in" to this address. But sending multicast traffic over a routed internetwork becomes more complicated. Every router could merely forward all multicast packets onto every LAN, in case there are group members on the LAN, but this partially circumvents the goal of multicasting, which is to conserve network resources. If no group members are on the LAN, bandwidth and processing is wasted not only on that subnet, but also on all data links and routers leading to it. Therefore, a router must have some means to learn whether a connected network includes group members, and if so, members of what group. When a router becomes aware of a multicast session, it can query all of its attached subnets for hosts that want to join the receiving group. The query might be addressed to the "all systems on this subnet" address of 224.0.0.1, or it might be addressed to the specific address of the group for which it is querying. If one or more hosts respond, the router can then forward the session's packets onto the appropriate subnet, as illustrated in Figure 5-9. Figure 5-9. Multicast Group Member Discovery The router can periodically resend queries to the subnet. If there are still group members on the subnet, they will respond to all queries to let the router know they are still active in the group. If no hosts respond, the router assumes that all hosts on the subnet have left the group, and it ceases forwarding the group's packets onto the subnet. Join LatencyA problem with the scheme described so far is that if a host knows of a group it wants to join, it is not always practical for the host to wait for a router to query for the group. To reduce this wait time, a host could send a message to the router requesting a join, without waiting for a query. Upon receiving the join request, the router immediately forwards the multicast traffic onto the subnet. This procedure has benefits for more than just the local subnet. In the section "Multicast Routing Concepts" later in this chapter, you will see that having hosts initiate the join can help make multicast routing protocols more efficient. If a router has no group members on any of its attached subnets, and the subnets are not transit networks for multicast traffic to other routers, the router itself can request that upstream neighbors not forward multicast traffic to it. The result is that the traffic streams do not enter parts of the network in which there are no group members. If the router then receives a join request on one of its attached subnets, it can send a request upstream to begin receiving the relevant data stream. The trade-off of this scheme is that if a host sends a join request to its local router, and then has to wait for the router to request the appropriate traffic from its upstream neighbors, the join latency is increased. Join latency is the period between the time a host sends a join request and the time the host actually begins receiving group traffic. Of course, if there are already other group members on the subnet when the host decides to join, the join latency will be practically zero. The host has no reason to send a join request to the router; it can just begin listening to the packets that are already being forwarded onto its subnet for the other group members. Leave LatencyAllowing a host to explicitly notify its local router when it leaves a group can increase efficiency as well. Rather than having to wait for no hosts to respond to its queries before it implicitly concludes that there are no group members on a subnet, the router can actively determine whether there are remaining members. Upon receiving a leave notification from a host, the router immediately sends a query onto the subnet, asking whether there are any remaining members. If no one responds, the router concludes that there are no more members and can cease forwarding packets for the group onto that subnet. The result is a decreased leave latency, which is the period between the time the last group member on a subnet leaves the group and the time the router stops forwarding group traffic onto the subnet. Host-initiated group leaves also improve routing protocol efficiency. If a router knows that it no longer has any group members on any of its subnets, it can "prune" itself from the multicast tree. The sooner a router determines that there are no group members, the sooner it can prune itself. Decreased join and leave latencies also can improve the overall quality of a multicast network. There could be a large suite of multicast groups known to a host. Low join and leave latencies mean that the end user can easily "channel surf" through the available groups in the same way that users casually flip through radio and television channels. Group MaintenanceThe message that a host sends to a router to indicate that it wants to join a group is known as a report. A host can use several possible destination addresses when sending a report:
If all group members on a subnet respond to a query, bandwidth is unnecessarily wasted. After all, the router needs to know only that there is at least one member of the group on the subnet; it does not need to know exactly how many there are, or who they are. Another problem with all group members responding to a query is the possibility of collisions if all members respond at once. Backing off and retransmitting consumes more network and host resources. If many group members are on the subnet, there is an increased probability that multiple collisions will occur before everyone sends his report. Sending reports to the group address eliminates multiple reports on a subnet. When a query is received, each group member starts a timer based on a random value. The member does not send a report until the timer expires . Because the timers are random, it is much more likely that one member's timer will expire before the other timers. This member sends a report, and because the report is sent to the group address, all other members hear it. These other members, hearing the report, cancel their timers and do not send a report of their own. As a result, only one report is generally sent on the subnet. One report per subnet is all the router needs. Multiple Routers on a NetworkThe possibility was raised in the preceding section that multiple routers might be attached to a subnet, all of which need to know whether group members are present. Figure 5-10 shows an example. Two routers are attached to the subnet, both of which receive the same multicast stream from the same source over different routes. If one router or route fails, the group members can continue to receive their multicast session from the other router. Under normal circumstances, however, it is inefficient for both routers to forward the same data stream onto the subnet. Figure 5-10. Two Routers Receive the Same Multicast Session, but Only One Forwards It onto the Subnet The routers are aware of each other because of their routing protocols. So one way to ensure that only one router forwards the session onto the subnet is to add a designated router, or querier, function to the multicast routing protocol. The querier is responsible for forwarding the multicast stream. The other router or routers only listen, and they begin forwarding the stream only if the querier fails. The problem with allowing the routing protocol to elect a querier is that multiple IP multicast routing protocols are available. If the two routers in Figure 5-10 are running incompatible protocols, their respective querier election processes will not detect each other; each will decide that it is the querier, and both will forward the data stream. The local group management protocol, however, is independent of the routing protocols. The routers have to run this common protocol to query group members, so it makes sense to give the querier function to the group management protocol. This guarantees that the routers are speaking a common language on the subnet and can agree on which is responsible for forwarding the session. Internet Group Management Protocol (IGMP)Regardless of which of the several routing protocols is used in a multicast internetwork, IGMP is always the "language" spoken between hosts and routers. All hosts that want to join multicast groups, and all routers with interfaces on subnets containing multicast hosts, must implement IGMP. It is a control protocol like ICMP, sharing some functional similarities. Like ICMP, it is responsible for managing higher-level data exchanges. IGMP messages are encapsulated in IP headers like ICMP (with a protocol number of 2), but unlike ICMP, the messages are limited to the local data link. This is guaranteed both by the IGMP implementation rules, which require that a router never forward an IGMP message, and by always setting the TTL in the IP header to 1. There are two current versions of IGMP: IGMPv1 is described in RFC 1112,[3] and IGMPv2 is described in RFC 2236.[4] Cisco IOS Software Release 11.1 and all later versions support IGMPv2 by default; however, many host TCP/IP implementations still support only version 1 (Windows NT 4.0 with service packs previous to SP4, for example). For this reason, the default can be changed with the ip igmp version command. This next section discusses IGMPv2 and then presents its differences with IGMPv1. IGMPv3 has also been proposed,[5] although IOS does not currently support it. However, version 3 is briefly discussed in this section with the expectation that Cisco IOS Software may support it in the near future. IGMPv2 Host FunctionsHosts running IGMPv2 use three types of messages:
Membership Report messages are sent to indicate that a host wants to join a group. The messages are sent when a host first joins a group, and sometimes in response to a Membership Query from a local router. When a host first learns of a group and wants to join, it does not wait for the local router to send a query. As you will learn in the sections on the various multicast routing protocols, the router may not ”in fact, most likely does not ”have any knowledge of the particular group the host wants to join, and therefore does not query for members. If the host had to wait for a query, it might never get the opportunity to join. Instead, when the host first joins a group, it sends an unsolicited Membership Report for the group. Multicast sessions are identified in the routers by a (source, group) pair of addresses, where source is the address of the session's originator and group is the Class D group address. If the local multicast router does not already have knowledge of the multicast session the host wants to join, it sends a request upstream toward the source. The data stream is received, and the router begins forwarding the stream onto the subnet of the host that requested membership. The destination address of the Membership Report message's IP header is the group address, and the message itself also contains the group address. To ensure that the local router receives the unsolicited Membership Report, the host sends one or two duplicate reports separated by a short interval. RFC 2236 recommends an interval of 10 seconds. IGMPv2 hosts support IGMPv1 Membership Reports for backward compatibility. The mechanisms that IGMPv2 uses to detect and support IGMPv1 hosts and routers on its subnet are discussed in the section "IGMPv1 Versus IGMPv2." The local router periodically polls the subnet with queries. Each query contains a value called the Max Response Time, which is normally 10 seconds (specified in units of tenths of a second). When a host receives a query, it sets a delay timer to a random value between 0 and the Max Response Time. If the timer expires, the host responds to the query with one Membership Report for each group to which it belongs. NOTE All multicast-enabled devices are members of the "all systems on this subnet" group, represented by the group address 224.0.0.1. Because this is a default, hosts do not send Membership Reports for this group. Because the destination of the Membership Report is the group address, other group members that might be on the subnet hear the report in addition to the router. If the host receives a Membership Report for a group before its delay timer expires, it does not send a Membership Report for that group. In this way, the router is informed of the presence of at least one group member on the subnet, without all members flooding the subnet with reports. When a host leaves a group, it notifies the local router with a Leave Group message. The message contains the address of the group being left, but unlike Membership Report messages, the Leave Group message is addressed to the "all routers on this subnet" address of 224.0.0.2. This is because only the multicast routers on the subnet need to know that the host is leaving; other group members do not. RFC 2236 recommends that a Leave Group message be sent only if the leaving member was the last host to send a Membership Report in response to a query. As the next section explains, the local router always responds to a Leave Group message by querying for remaining group members. If group members other than the "last responder " leave quietly , the router continues forwarding the session and does not send a query. As a result, a little bandwidth is saved. However, this behavior is not required. If the designer of a multicast application does not want to include a state variable to remember whether this host was the last to respond to a query, the application can always send a Leave Group message when it leaves a group. IGMPv2 Router FunctionsThe only type of IGMP message sent by routers is a query. Within IGMPv2, there are two subtypes of queries:
The General Query is the message with which the router polls each of its subnets to discover whether group members are present and to detect when there are no members of a group left on a subnet. By default, the queries are sent every 60 seconds; the default can be changed to any value between 0 and 65,535 seconds with the command ip igmp query-interval. As described in the preceding section, the query also contains a value called the Max Response Time. This value specifies the maximum amount of time the host has to respond to a query with a Membership Report. By default, the Max Response Time is 10 seconds; you can use the command ip igmp query-max-response-time to change it. The value is carried in the message in an 8-bit field and is expressed in units of tenths of a second (although the value is specified with i p igmp query-max-response-time in units of seconds). For example, the default 10 seconds is expressed within the message as 100 tenths of a second. Therefore, the range that can be specified is 0 to 255 tenths, or 0 to 25.5 seconds. The General Query message is sent to the "all systems on this subnet" address of 224.0.0.1 and does not contain a reference to any specific group. As a result, the single message polls for reports from members of any and all groups that might be active on the subnet. The router tracks known groups and the interfaces attached to subnets with active members, as shown in the output in Example 5-1. Example 5-1 The show ip igmp groups Command Displays the IP Multicast Groups of Which the Router Is Aware Gold# show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Serial0/1.306 3d01h never 0.0.0.0 228.0.5.3 Ethernet0/0 00:09:07 00:02:55 172.16.1.254 239.1.2.3 Ethernet0/0 1d08h 00:02:53 172.16.1.23 Gold# If a Cisco multicast router does not hear a Membership Report on a particular subnet for a group within 3 times the query interval (3 minutes by default), the router declares that no active members of the group are on the subnet. This covers the eventuality of a lone group member being disconnected or otherwise not following the IGMPv2 rules for leaving a group. NOTE This differs from RFC 2236, which specifies twice the query interval plus one Max Response Time interval. The normal way that a host leaves a group is by sending a Leave Group message. When a router receives a Leave Group message, it must determine whether any remaining members of that group are on the subnet. To do this, the router issues a Group-Specific Query, which differs from a General Query in that it contains the group address, and it also uses the group address as its destination address. If the Group-Specific Query were to become lost or corrupted, a remaining group member on the subnet might not send a report. As a result, the router would incorrectly conclude that there are no group members on the subnet and stop forwarding the session packets. To protect against this eventuality, the router sends two Group-Specific Queries, separated by a 1-second interval. When a multicast-enabled router first becomes active on a subnet, it assumes that it is the querier ”the router responsible for sending all General and Group-Specific Queries to the subnet ”and immediately sends a General Query. NOTE RFC 2236 recommends sending multiple queries; however, Cisco's IGMPv2 sends only one. This action serves both to quickly discover the group members active on the subnet and to alert other multicast routers that may be on the subnet. When there are multiple routers, the rule for electing the querier is simple: The router with the lowest IP address is the querier. So when the existing router on the subnet hears the General Query from the new router, it checks the source address. If the address is lower than its own IP address, it relinquishes the role of querier to the new router. If its own IP address is lower, it continues sending queries. When the new router receives one of these queries, it sees that the old router has a lower IP address and becomes a nonquerier. If the nonquerier does not hear queries from the querier within a certain period of time, known as the Other Querier Present Interval, it concludes that the querier is no longer present and assumes that role. Cisco IOS Software has a default Other Querier Present Interval of twice the Query Interval, or 120 seconds; you can change this with the command ip igmp query-timeout. IGMPv1The important differences between IGMPv1 and IGMPv2 are as follows:
The section "IGMP Message Format" illustrates how these differences affect the fields in IGMPv1 and IGMPv2 messages. In some cases, IGMPv1 and IGMPv2 implementations might exist on the same subnet:
RFC 2236 describes several mechanisms that allow IGMPv2 to adapt in these situations. If there is a mixture of version 1 and version 2 members on the same subnet, the version 2 members treat both version 1 and version 2 Membership Reports the same when determining whether to suppress their own Membership Reports. That is, if a version 2 member hears a query from the router and subsequently hears a version 1 Membership Report for its group before its own delay timer expires, it does not send a Membership Report. Version 1 hosts, on the other hand, ignore version 2 messages. Therefore, if a version 2 Membership Report is sent for a group first, the version 1 member also sends a report when its delay timer expires. This does not cause problems for the version 2 host, and this is important for the version 2 router so that it is aware of the presence of version 1 group members. If a host is running version 2 and the local router is running version 1, the IGMPv1 router ignores the version 2 messages. So when a version 2 host receives a version 1 query, it responds with version 1 Membership Reports. The IGMPv1 query also does not specify a Max Response Time, so the IGMPv2 host uses the fixed version 1 period of 10 seconds. The host may or may not send Leave Group messages in the presence of version 1 routers; the IGMPv1 router does not recognize Leave Group messages, and ignores them. If a version 2 router receives a version 1 Membership Report, it treats all members of the group as if they are running version 1. The router ignores Leave Group messages and hence does not send Group-Specific Queries that the version 1 members would ignore. Instead, it sets a timer, known as the Old Host Present Timer (as shown in Example 5-2). The period of the timer is the same value as the Group Membership Interval. Whenever a new version 1 Membership Report is received, the timer is reset; if the timer expires, the router concludes that no more version 1 members of the group are on the subnet and reverts to version 2 messages and procedures. NOTE As described earlier, the Group Membership Interval is the period of time that the router waits to hear a Membership Report before declaring that no members are on a subnet. Cisco's default is three times the Query Interval. Example 5-2 This Multicast Router Is Receiving IGMPv2 Membership Reports for Group 239.1.2.3 and IGMPv1 Membership Reports for Group 228.0.5.3. The Version 1 Reports Cause the Router to Set an Old Host Present Timer for That Group Gold# debug ip igmp IGMP debugging is on Gold# IGMP: Send v2 Query on Ethernet0/0 to 224.0.0.1 IGMP: Received v2 Report from 172.16.1.23 (Ethernet0/0) for 239.1.2.3 IGMP: Received v1 Report from 172.16.1.254 (Ethernet0/0) for 228.0.5.3 IGMP: Starting old host present timer for 228.0.5.3 on Ethernet0/0 IGMP: Send v2 Query on Ethernet0/0 to 224.0.0.1 IGMP: Received v2 Report from 172.16.1.23 (Ethernet0/0) for 239.1.2.3 IGMP: Received v1 Report from 172.16.1.254 (Ethernet0/0) for 228.0.5.3 IGMP: Starting old host present timer for 228.0.5.3 on Ethernet0/0 Notice in Example 5-2 that the router continues to send version 2 General Queries. The only significant difference between these queries and version 1 queries is that the Max Response Time is nonzero. The field in which this value is carried is unused in version 1, and the version 1 host ignores it. As a result, the host interprets version 2 queries as version 1 queries. Another point of interest in Example 5-2 is that the Old Host Present timer is set only for group 228.0.5.3. The router treats only this group as an IGMPv1 group. Group 239.1.2.3, on the same interface, is treated as a version 2 group. If version 1 and version 2 routers exist on the same subnet, the version 1 router will not participate in the querier election process. Because of this, it is important that the version 2 router behaves as a version 1 router for consistency. There is no automatic conversion to version 1; the version 2 router must be manually configured with the ip igmp version 1 command. IGMPv3Because IGMPv3 is still under development and is not yet supported, this section does not examine it in the detail that the first two versions are examined. Instead, this section summarizes the major features that this version will add if and when it comes into general use. The primary addition to IGMPv3 is the inclusion of a Group-and-Source-Specific Query. This allows a group to be identified not only by group address, but also by source address. The Membership Report and Group Leave messages are modified so that they also can make this identification. When a group has many sources (a many-to-many group), the IGMPv3 router can perform source filtering based on the requests of group members. For example, a particular member may want to receive group traffic from only certain specified sources, or it may want to receive traffic from all sources except certain specified sources. The member can express these wants in a Membership Report with Include or Exclude filter requests. If no member on a particular subnet wants to receive traffic from a particular source, the router does not forward that source's traffic onto the subnet. IGMP Message FormatIGMPv2 uses a single message format, as shown in Figure 5-11. The IP header encapsulating the message indicates a protocol number of 2. Because the IGMP message must not leave the local subnet on which it was originated, the TTL is always set to 1. Additionally, IGMPv2 messages carry the IP Router Alert option that informs routers to "examine this packet more closely."[6] Figure 5-11. The IGMPv2 Message Format The fields for the IGMPv2 message are defined as follows:
Figure 5-12 shows the format of an IGMPv1 message. Figure 5-12. The IGMPv1 Message Format The only differences in the IGMPv1 format from IGMPv2 are as follows:
Another difference is that the Router Alert option is not set in the IP header of IGMPv1 messages. IGMPv1 defines just two message types:
The Version field is always set to 1. As a result, you can see that the combined Version and Type field is 0x11 for a Host Membership Query message, which is the same value as the 8-bit Type field of an IGMPv2 Membership Query. The combined Version and Type fields of the Host Membership Report is 0x12, whereas the Type field of the IGMPv2 Membership Report is 0x16. Cisco Group Membership Protocol (CGMP)A fundamental design principle of IP multicast is that traffic should be delivered only to destinations that want to receive the traffic. You have seen how Class D addressing and its associated MAC addressing help meet this goal at the data link layer, and how IGMP allows routers to determine whether they should deliver sessions to particular subnets. You will see in subsequent sections how IP multicast routing protocols extend this principle across internetworks, delivering multicast sessions only to those routers that have group members on their attached subnets. What about a switched network, however, such as the one shown in Figure 5-13? Large office buildings and campuses abound with such networks. The Ethernet switches, which are really just high- powered , high-port-density transparent bridges, limit unicast traffic by learning what MAC addresses are associated with what ports. They can then filter and forward frames based on this information. But broadcast traffic is forwarded to every port of every switch. A large network such as the one depicted in Figure 5-13 is normally broken into several virtual LANS (VLANs) to control the scope of the broadcast traffic. However, it is not unusual to find "flat" switched networks this large ”one big subnet, or broadcast domain. Figure 5-13. Unless This Switched Campus Network Is Divided into Multiple VLANs, It Comprises a Single Broadcast Domain. That Is, the Router Port Defines a Layer 3 Subnet, and Any Broadcast Frame Is Transmitted Out of All 384 Switch Ports Just as broadcast frames are forwarded to every port within a broadcast domain, so too are frames carrying IP multicast packets. After all, a broadcast domain is nothing more than a multicast group to which all hosts belong. Figure 5-14 illustrates the problem. Three group members are attached to a 24-port switch. An IGMP Membership Report is sent to the router, and the router begins forwarding the appropriate multicast session onto the subnet. Because IGMP is a Layer 3 protocol, the Ethernet switch has no easy way to determine what ports the group members are on. As a result, the multicast traffic is forwarded to all 23 ports (discounting the source port). Figure 5-14. One of the Three Group Members Sends an IGMP Membership Report, Joining Multicast Group A (a). When the Router Forwards the Multicast Session, the Switch Replicates the Frames to All Ports Except the Source Port (b) Obviously, the preferable behavior is for the switch to forward the multicast session only out of those ports to which the group members are attached. If this can be accomplished, switching is not only more efficient, but also is the preferable way to implement LANs that carry multicast sessions. For example, a videoconferencing multicast stream uses approximately 1 Mbps of bandwidth, and an MPEG II video stream can use approximately 4 Mbps. If these sessions can be limited to the group members' ports, network and host resources can be conserved. Cisco Group Membership Protocol (CGMP) is designed to do exactly that ”distribute multicast sessions only to those switch ports on which group members are located. Before examining the operation of CGMP, the next section takes a brief look at some other solutions for regulating switched multicast traffic. Alternative Multicast Control Methods on Switched NetworksThere are three methods besides CGMP for constraining multicast traffic in switched environments, all of which are supported by Cisco Catalyst software:
Because none of these three solutions has any direct bearing on routing, only an overview is provided in this section. Have a look at Cisco's Catalyst Switch Software Documentation on CCO for more details and complete configuration instructions. Manual configuration of switched multicast trees just means that you make static entries into the switch's bridging table. Cisco Catalyst switches call this table the content addressable memory (CAM) table. Suppose that the group members in Figure 5-13 are on switch ports 2/3, 2/4, and 2/19, the router is on port 1/1, and the group address is 239.0.5.10. This IP address gives the group a multicast MAC address of 0100.5E00.050A. The command for manually entering this information into the Catalyst CAM table is as follows: set cam permanent 01-00-5e-00-05-0a 2/3-4,2/19 set multicast router 1/1 The preceding adds the entry to the CAM table and writes it to the switch's NVRAM; the entry can be removed only with the clear cam or clear config command. Alternatively, the static keyword can be used rather than the permanent keyword. In that case, the entry is not written to NVRAM and is removed if the switch is reset. The second command is optional. It informs the switch of the port on which the multicast router is located, further limiting the scope of the multicast traffic within the switch. There are several limitations to using manual configuration. The two most obvious are that it is not dynamic, and it does not scale. If another group member joins on a different port, a group member leaves, or a different group is added to the switch, the information must be manually configured. For anything other than small, fixed groups, manual configuration is not practical. Another limitation is that manual configuration cannot be used across VLAN boundaries. If the group 239.0.5.10 is on VLAN 1, for example, and VLAN 2 also exists on the switch, none of the members of 239.0.5.10 can be in the second VLAN ”they must all reside in the same VLAN. Another technique is to use GARP Multicast Registration Protocol (GMRP), an open protocol defined in the IEEE 802.1p standard that enables MAC-layer multicast group addresses to be dynamically registered and deregistered in the switch. GMRP is enabled on the switch with the command set gmrp enable; no configuration is required on the router. As the IEEE 802.1p standard suggests, GMRP is strictly a Layer 2 protocol. The third technique is IGMP Snooping, enabled on the Catalyst switch with the command set igmp enable. With this option, the switch software examines IGMP messages and, as a result, knows the location of both multicast routers and group members. Unlike the proprietary CGMP, IGMP Snooping is supported by several switch manufacturers, making it a better choice for multivendor switched networks; however, detection of IGMP messages means that every IP packet must be examined. When this is implemented in software, the result can be a significant degradation of switch performance. You should use IGMP Snooping only if all the switches in the multicast network can implement the function in hardware, using specialized application-specific integrated circuits (ASICs) that can examine the IP packets at line rate. For example, this is supported on Cisco Catalyst switches with NetFlow Feature Card II (NFFC II). Operation of CGMPAlthough both Cisco routers and Cisco switches must be configured to run CGMP, only the routers produce CGMP packets. The CGMP process on switches only reads the packets. There are two types of CGMP packets:
These two packet types have an identical format, and the destination of the packets is always the reserved MAC address 0100.0cdd.dddd. CGMP-enabled switches listen for this address. The essential information in both packets is one or more pairs of MAC addresses:
When a CGMP router comes online, it makes itself known to the switch by sending a CGMP Join packet with the GDA set to zero (0000.0000.0000) and the USA set to its own MAC address. The CGMP-speaking switch now knows that a multicast router is attached to the port on which it received the packet. The router repeats the packet every 60 seconds as a keepalive. When a host wants to join a group, it sends an IGMP Membership Report message, as illustrated in Part A of Figure 5-15. The switch, following normal IEEE 802.1 procedures, enters the host's MAC address into its CAM table. Figure 5-15. When a Cisco Router Receives an IGMP Membership Report on a CGMP Interface (a), It Sends a CGMP Join Packet Telling the Switch to Map the Host MAC Address to the Group MAC Address (b) NOTE The Catalyst's CAM table is a bridging table that records the MAC addresses it has heard and the ports on which they were heard . When the router receives the IGMP Membership Report, it sends a CGMP Join packet with the GDA set to the group MAC address and the USA set to the host's MAC address, as illustrated in Part B of Figure 5-15. The switch is now aware of the multicast group, and because the switch knows the port on which the host is located, it can add that port to the group. When the router sends frames to the group MAC address, the switch forwards a copy of the frame out all ports (except the router port) associated with the group. As long as group members remain on the switched network, the router sends IGMP queries every 60 seconds, which the switch forwards to the members. The switch forwards the IGMP reports, sent in reply to the queries, to the router. When a host sends an IGMPv2 Leave message, the message is forwarded to the router, as illustrated in Part A of Figure 5-16. The router sends two IGMP Group-Specific Queries, which the switch forwards to all group ports. If another member responds to the Group-Specific Query, the router sends a CGMP Leave packet to the switch with the GDA set to the group MAC address and the USA set to the leaving member's MAC address, as illustrated in Part B of Figure 5-16. This packet tells the switch to delete just the leaving member's port from the group. If no members respond to the Group-Specific Query, the router concludes that no members are left on the segment. In this case, it sends a CGMP Leave packet to the switch with the GDA set to the group MAC address and the USA set to zero, as illustrated in Part C of Figure 5-16. This packet tells the switch to remove the group itself from the CAM table. Figure 5-16. When a Router Receives an IGMP Leave Message on a CGMP Interface (a), It Queries to Learn Whether There Are Other Members Left on the Subnet (b). If Other Members Respond, It Sends a CGMP Leave Packet to the Switch, Removing Just the Leaving Member. If No Members Respond, the Router Sends a CGMP Leave Message to the Switch, Removing the Entire Group (c) Table 5-2 summarizes the various possible values of the GDA and USA in CGMP packets, and the meaning of each. Only the last two Leave packets have not been discussed. A Leave with the GDA set to zero and the USA set to the router's MAC address signals the switch to remove all groups and ports associated with the router port from the CAM. This message is sent if the router's CGMP function has been disabled on that port. A Leave with both the GDA and the USA set to zero tells all switches receiving the message to delete all groups and associated ports from the CAM. This message is sent as the result of a clear ip cgmp command entered at the router. Table 5-2. CGMP Packets
CGMP Packet FormatThe source MAC address of frames carrying CGMP packets is the MAC address of the originating router, and the destination MAC address is the reserved multicast address 0100.0cdd.dddd. Only routers originate CGMP packets. Within the frame, the packet is encapsulated in a SNAP header. The OUI field of the SNAP header is 0x00000c, and the type field is 0x2001. Figure 5-17 shows the format of the CGMP packet. Figure 5-17. The CGMP Packet Format The fields of the CGMP packet are defined as follows:
|
![Routing TCP[s]IP (Vol. 22001)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 22001)"){kind=icon}