<PARA><DROPCAP>J</DROPCAP>ust as blue, green, and red are the primary colors, unicast, multicast, and broadcast are the primary forms of communication on networks.</PARA>
<PARA>Today's Web and enterprise applications are directed to larger audiences on the network than ever before, causing increased bandwidth requirements. This increased demand on bandwidth can be accommodated with as little cost increase as possible by using multicast. For example, voice and video are being sourced for larger and larger audiences. One-on-one communications can overwhelm both servers and network resources. Unlike unicast and broadcast, however, multicast services can eliminate this problem.</PARA>
<PARA>This chapter will help you understand the differences in unicast, broadcast, and multicast communication methods and when each should be used. Unicast is an excellent method of point-to-point communication, whereas broadcast traffic is imperative for many systems and protocols to work on a network. Multicast comes in as a bridge between these two communication extremes by efficiently allowing point-to-multipoint data forwarding. It is imperative that you understand how multicast addressing spans both layer 3 and layer 2 of the OSI model. You will also learn about the protocols and tools used to implement and control multicast traffic on your network. As with any service that runs on your network, you must understand the resources needed and the implications of enabling multicast.</PARA>
<PARA><DROPCAP>J</DROPCAP>ust as blue, green, and red are different and each has its own place within the spectrum of visible light, unicast, broadcast, and multicast are different in that each is used to achieve a specific purpose or fulfill requirements of a specific part of the communication spectrum. It is important to know where each falls within the spectrum as well as the potential applications.</PARA>
<PARA>RFC 1112 discusses multicast and goes into great detail about host extensions and multicast groups. In addition to address assignment for multicast applications and hosts, protocol methods and procedures are discussed. For example, it covers the methods by which hosts join and leave multicast groups, and it also covers group advertisements and multicast forwarding.</PARA>
<PARA><KEYTERM>Unicast</KEYTERM> is used for direct host-to-host communication. When the layer 3 Protocol Data Unit (PDU, or packet) is formed, two layer 3 IP addresses are added to the IP header. These are the source and destination IP addresses. They specify a particular originating and receiving host. After the layer 3 PDU is formed, it is passed to layer 2 to create the layer 2 PDU, or frame. The frame consists of all of the previous layers' headers in addition to the layer 2 header. With an Ethernet frame, for example, the two 48-bit source and destination MAC addresses are specified in the layer 2 header. Other protocols such as IEEE 802.5 (Token Ring) and FDDI also have headers that contain specific host source and destination addresses.</PARA>
<PARA>Unicast communication is used when two hosts need only to exchange data with one another and are not concerned with sharing the data with everyone. A MAC address must <EMPHASIS FORMAT="italic">uniquely</EMPHASIS> identify a host. No two MAC addresses are the same. Therefore, unicast capitalizes on the unique MAC address for each host. With the specific address, any source host should be able to contact the destination host without confusion. </PARA>
<PARA>One of the caveats to unicast communication is that the source host must know or be able to learn what every destination MAC is for every station it wishes to communicate with. This may not be done on a host-by-host basis. The normal operation is that the host has a default gateway assigned for use when the logical destination address does not reside on the same subnet as the source host. Figure 9.1 depicts how unicast traffic works on the same subnet.</PARA>
<SLUG NUM="9.1">Figure 9.1: Unicast communication [f0901.eps]</SLUG>
<PARA>The unicast process, then, is a two-way communication. These two hosts are interested only in communicating with one another. So what happens when one host wants to talk to multiple hosts or all of the hosts on the same network segment? That is where broadcast communications come in.</PARA>
</SECTION>
<SECTION ID="9.1.2"><TITLE>Broadcast</TITLE>
<PARA>Now that you have a good understanding of unicast, we can discuss the principle of broadcast communication on networks. Whereas unicast messages target a single host on a network (unicast communication can be compared to sending an e-mail to a friend; the mail is addressed to the friend, and it is sent from you), <KEYTERM>broadcast</KEYTERM> messages are meant to reach all hosts on a broadcast domain. Figure 9.2 depicts a broadcast message sent from HostX to all machines within the same broadcast domain. </PARA>
<SLUG NUM="9.2">Figure 9.2: Broadcast message on a network [f0902.eps]</SLUG>
<PARA>A good example of a broadcast message is an Address Resolution Protocol (ARP) request. When a host has a packet destined for a logical address that is not located on the same network, the host must ARP for the default gateway's MAC address so it can create the layer 2 frame and in turn send the datagram to the router. The MAC address is obtained via an ARP request. The ARP request is a broadcast message sent to all devices in the broadcast domain. The router will be the device that responds to the broadcast message, whereas other stations will evaluate the frame but not respond.</PARA>
<PARA>This brings up another good point. Broadcasts can cause problems on networks. Because the broadcast frame is addressed to include every host, every host must process the frame. CPU interruption occurs so that the frame may be processed. This interruption affects other applications that are running on the host. When unicast frames are seen by a router, a quick check is made to identify whether the frame is intended for the host or not. If it isn't, the frame is discarded.</PARA>
</SECTION>
<SECTION ID="9.1.3"><TITLE>Multicast</TITLE>
<PARA>Multicast is a different beast entirely. At first glance, it appears to be a hybrid of unicast and broadcast communication, but that isn't quite accurate. Multicast does allow point-to-multipoint communication, which is similar to broadcasts, but it happens in a different manner. The crux of <KEYTERM>multicast</KEYTERM> is that it allows multiple recipients to receive messages without flooding the messages to all hosts on a broadcast domain.</PARA>
<PARA>Multicast works by sending messages or data to IP <KEYTERM>multicast group</KEYTERM> addresses. Routers then forward copies of the packet out every interface that has hosts <EMPHASIS FORMAT="italic">subscribed</EMPHASIS> to that group address. This is where multicast differs from broadcast messages. With unicast communication, copies of packets are sent only to subscribed hosts. </PARA>
<PARA>The difference between multicast and unicast is comparable to the difference between mailing lists and SPAM. You subscribe to a mailing list when you want to receive mail from a specific group regarding specific information-for example, a Cisco User Group mailing list. You expect to get only messages from other members of the group regarding topics related to the user group. In contrast, SPAM is unsolicited mail that arrives in your inbox. You aren't expecting it from the sender, nor are you likely to be interested in the content.</PARA>
<PARA>Multicast works in much the same way as a mailing list. You (as a user) or an application will <EMPHASIS FORMAT="italic">subscribe</EMPHASIS> to a specific IP multicast group to become a member. Once you're a member of the group, IP multicast packets containing the group address in the destination field in the header will arrive at your host and be processed. If the host isn't subscribed to the group, it will not process packets addressed to that group. Refer to Figure 9.3 for a visual reference on how multicast works.</PARA>
<SLUG NUM="9.3">Figure 9.3: Multicast communication [f0903.eps]</SLUG>
<PARA>The key to multicast is the addressing structure. This is key because all communication is based on addressing. In unicast communication, there is a unique address for every host on a network. With broadcast communication, a global address that all hosts will respond to is used. Multicast uses addressing that only some hosts will respond to. The next section will cover multicast addressing in detail.</PARA>
<PARA><DROPCAP>J</DROPCAP>ust as with mailing lists, there are several different groups that users or applications can subscribe to. The range of multicast addresses starts with 224.0.0.0 and goes through 239.255.255.255. As you can see, this range of addresses falls within IP Class D address space based on classful IP assignment. This is denoted by the fact that the first four bits in the first octet are 1110. Just as with regular IP addresses, there are some addresses that can be assigned and there are ranges of reserved addresses.</PARA>
<PARA>It is important to recognize that the reserved addresses are categorized. Table 9.1 depicts some of the reserved addresses and their corresponding categories. For a full listing of these assignments, you can go to <INLINEURL HREF="http://www.isi.edu/in-notes/iana/assignments/multicast-addresses" SHOW="new">www.isi.edu/in-notes/iana/assignments/multicast-addresses</INLINEURL>.</PARA>
<PARA>Each address range is managed by the Internet Address Number Authority (IANA). Due to the limited amount of multicast addresses, there are very strict requirements for new assignments within this address space. The 239.0.0.0-239.255.255.255 range is equivalent in purpose to the private networks defined by RFC 1918.</PARA>
<PARA>The difference between the IP multicast ranges of 224.0.0.0-224.0.0.255 and 224.0.1.0-224.0.1.255 is that addresses in the first range will not be forwarded by an IP router. Both ranges of addresses are used by applications and network protocols. The first group, classified as local-link, is meant to remain local to the subnet or broadcast domain on which the system resides. The second group is a global address that can be routed and forwarded across multiple IP routers.</PARA>
<SECTION ID="9.2.1" POS="1"><TITLE>Mapping IP Multicast to Ethernet</TITLE>
<PARA>Multicast addressing began on MAC addresses. Growth needs required that there be a way to use multicast across routers instead of limiting it to the physical segment where hosts were located. In regular unicast, MAC addresses are layer 2 addresses, and in order for the local host to reach remote hosts, layer 3 logical IP addresses are used to route data to the destination. Once the packet reaches the remote subnet, the Address Resolution Protocol (ARP) is used to find the MAC address of the host. By using an existing ARP table, or via an ARP request, the MAC address that is associated to the layer 3 IP address is found and the packet is forwarded to the destination host.</PARA>
<!-- <PARA>IP multicast generates a MAC address based on the layer 3 IP multicast address. The MAC frame has a standard prefix of 24 bits. This prefix, 01-00-5e, is used for all Ethernet multicast addresses. This leaves another 24 bits for use in creating the multicast MAC address. When the MAC address is generated, the 25th bit (or high order bit) is set to 0 and then the last 23 bits of the IP address are mapped in to the remaining 23 bits of the MAC address. Figure 9.4 depicts how this looks.</PARA> -->
<SLUG NUM="9.4">Figure 9.4: IP multicast mapped to MAC multicast [f0904.eps]</SLUG>
<!-- <PARA>Let's look at some examples for mapping layer 3 multicast addresses to layer 2 multicast addresses. A local IP multicast address is 224.0.0.1. Refer to Figure 9.5 to see how this is mapped. The conversion from binary to hex reveals the MAC multicast address. The prefix was 01-00-5e. The last 23 bits, including the high order bit, give you 00-00-01. Put them together and you get 01-00-5e-00-00-01 as the MAC address. </PARA> -->
<!-- <SLUG NUM="9.5">Figure 9.5: Example #1 for mapping IP multicast to MAC multicast addresses [f0905.eps]</SLUG> -->
<!-- <PARA>Now let's try one a little bit harder. Suppose, for example, you have the IP multicast address of 225.1.25.2 (follow along with Figure 9.6). Part of the 225 octet falls within the Class D mask. However, there is one bit that is not masked. By looking carefully at the location of the bit, you will see that it is part of five lost bits and is not mapped to the layer 2 MAC multicast address.</PARA> -->
<!-- <SLUG NUM="9.6">Figure 9.6: Example #2 for mapping IP multicast to MAC multicast addresses [f0906.eps]</SLUG> -->
<!-- <PARA>Do the conversion of the octets from decimal into binary so you can get a clear picture of what the last 23 bits are. Here you would see the following address (the last 23 bits are indicated with the bold font): 11100001.0<EMPHASIS FORMAT="bold">0000001.00011001.00000010</EMPHASIS>. Also, as you can see, Figure 9.6 depicts the last 23 bits that are mapped into the free spaces of the multicast MAC address. After the mapping has occurred in binary, convert the binary value to hex and you will have the new MAC multicast address.</PARA>
<PARA>After you do the math and map the last 23 bits, the MAC address becomes 01-00-5e-01-19-02. The easiest way to map layer 3 to layer 2 manually is to do the math and make the binary conversion so you can see what the last 23 bits of the layer 3 IP address are. Once you have that number, all you have to do is insert it into the MAC address and then calculate the remaining 3 hex octet values. The first three octets will always be the same, 01-00-5e.</PARA> -->
<PARA>It is important that you spend time studying this procedure and the steps needed to convert a layer 3 IP multicast address to a layer 2 MAC multicast address.</PARA>
<PARA>There is one last method of determining the last 23 bits, but this method will work only on some addresses. Keep in mind that the highest value you can get in the second octet is 127 and still have it be included in the 23 bits that will map to the MAC address. You know that the last 2 octets (3 and 4) will map no matter what. So you will have 7 bits from the second octet and a total of 16 bits from the last 2 octets for a total of 23 bits. Once your value goes above 127 in the second octet, you will have to break down the octet into binary so you can see the values of the first 7 fields.</PARA>
<SECTION ID="9.2.1.1"><TITLE>Layer 3 to Layer 2 Overlap</TITLE>
<PARA>After you have done a few of these conversions, you'll notice, or maybe you already have, that there is a problem with this conversion scheme. By not using all available bits for a Class D address, you cannot get an accurate map of layer 3 to layer 2 addresses. If you look at properties of a Class D address, you will see that the high order bit lies in the first octet and is in the 16's value position. This leaves 28 bits for host specification. However, by using only 23 bits of the layer 3 IP address, you leave 5 bits out of the mapping. This causes an overlap of 2<SUPERSCRIPT>5</SUPERSCRIPT>, or 32 layer 3 addresses for every 1 layer 2 address. With a ratio of 32:1, you can expect to see a significant amount of address ambiguity. It is safe to say that any IP addresses that have the same values in the last 23 bits will map to the same MAC multicast address.</PARA>
<PARA>For example, 224.0.1.1 and 225.128.1.1 map to the same MAC address. Figure 9.7 shows why this is true. You can see that the bits that differ between 224.0.1.1 and 225.128.1.1 are all within the lost 5 bits. The last 23 bits are equivalent.</PARA>
<PARA>The impact that this may have can be significant. This overlap creates a window for multiple multicast groups' data to be forwarded to and processed by machines that didn't intentionally subscribe to the multiple groups. To give another example, a machine that subscribes to a multicast group 224.2.127.254 would be given a MAC address of 01-00-5e-02-7f-fe. This host will also process packets that come from multicast group 225.2.127.254 because the layer 2 MAC address is identical.</PARA>
<PARA>The problem this creates is that the end host must now process packets from both multicast groups even though it is only interested in data from 224.2.127.254. This causes unwanted overhead and processor interrupts on the host machine.</PARA>
</SECTION>
</SECTION>
</SECTION>
<SECTION ID="9.3"><TITLE>Managing Multicast in an Internetwork</TITLE>
<PARA><DROPCAP>A</DROPCAP>s a user on the network, you can understand that SPAM is not something that is managed by a systems administrator, whereas valid mailing lists require maintenance to keep a current list of valid subscribers. The same can be said of multicast. Reverting a little to the differences between broadcast and multicast communication, one of the major differences that we discussed is that broadcast traffic goes to all hosts on a subnet, whereas multicast traffic only goes to the hosts that request it. The distinguishing factor that puts multicast traffic so far ahead of broadcast traffic in utility is the ability to specify which multiple hosts will receive the transmission.</PARA>
<PARA>This isn't done magically; it doesn't know who and where the recipients are just because it's multicast traffic. As with any application, protocols are needed to make things happen. Multicast works on the basis of host subscription to groups.</PARA>
<PARA>Several methods and protocols have been developed and implemented to facilitate multicast functionality within the internetwork:</PARA>
<PARACONTINUED>Each of these protocols and methods is used for specific tasks or to achieve specific results within the multicast environment.</PARACONTINUED>
<PARA>We will now look at these protocols and learn just where they fit in and what they are needed for. We will begin with the most important, subscription and group maintenance, and then move on to enhancements for multicast deployment and distribution.</PARA>
<SECTION ID="9.3.1" POS="1"><TITLE>Subscribing and Maintaining Groups</TITLE>
<PARA>For multicast traffic to reach a host, that host must be running an application that sends a request to a multicast-enabled router informing the router that it wishes to receive data belonging to the specified multicast group. If this request were to never take place, the router wouldn't be aware that the host was waiting for data for the specified group.</PARA>
<PARA>As an overview, a multicast-enabled router receives all group advertisements and routes. It listens on all interfaces, waiting for a request from a host to forward multicast group traffic. Once a host on an interface makes a request to become a member of a group, the interface activates the requested group on itself and only on itself. While the host is a member, multicast data will be forwarded to that interface and any host subscribed to the group will receive the data.</PARA>
<PARA>That was a simple overview; now let's look at how this is accomplished in more detail. We will start by discussing three major host subscription protocols:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>IGMPv1</PARA></LISTITEM>
<LISTITEM><PARA>IGMPv2</PARA></LISTITEM>
<LISTITEM><PARA>CGMP</PARA></LISTITEM>
</LIST>
<PARACONTINUED>The differences among them will become apparent as we get further into the discussion.</PARACONTINUED>
</SECTION>
<SECTION ID="9.3.2"><TITLE>Internet Group Management Protocol Version 1 (IGMPv1)</TITLE>
<PARA>As the name indicates, <KEYTERM>Internet Group Management Protocol version 1 (IGMPv1)</KEYTERM> was the first version of the protocol. It was a result of RFC 1112. The purpose of this protocol is to allow hosts to subscribe to or join specified multicast groups. By subscribing to groups, the hosts are thereby enabled to receive multicast data forwarded from the router.</PARA>
<PARA>IGMP has several processes that it executes to manage multicast group subscription and maintenance. We will discuss them in greater detail so you can get an understanding of what happens.</PARA>
<PARA>Three processes are employed by version 1 of IGMP:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Query</PARA></LISTITEM>
<LISTITEM><PARA>Joining</PARA></LISTITEM>
<LISTITEM><PARA>Leaving </PARA></LISTITEM>
</LIST>
<PARACONTINUED>These processes are the means by which multicast group membership is maintained. The first two processes are functional processes, whereas the Leaving process is more of a time-out than a formal request. Each process is defined in detail in the following sections.</PARACONTINUED>
<PARA>One important process is the <KEYTERM>IGMP Query process</KEYTERM>, which is kindred to a keepalive procedure. Because the router needs to keep tabs on which multicast groups need to remain active or be made active or inactive, it sends a Membership Query out each interface. The query is directed to the reserved address of 224.0.0.1, to which all multicast hosts will answer. </PARA>
<PARA>Once the request is received, the hosts report back with their group subscription information. Once a specific group has been reported to the router, subsequent reports for the same group coming from different hosts will be suppressed. This is done because only one host on a subnet/VLAN needs to request membership for the router to activate that group on the interface. Once active on the router interface, any host on that segment wanting to receive data for that specific group will receive it. <!-- Figure 9.8 depicts how this process works. --></PARA>
<!-- <PARA>You can follow the numbers indicated in the figure. First, the query to 224.0.0.1 is sent, and subsequently, the hosts begin to report back. The first host to respond (#2a) is HostB, requesting data for the multicast group 224.2.127.254. HostD responds next (#3a) with a request for the group 224.2.168.242. The next host to reply is HostA (#4a). However, because the report from HostD was already multicast to the 224.2.168.242 group, HostA heard the report and suppressed its own report to the group. </PARA>
<PARA>The protocol is smart enough to understand that once one host has reported, more hosts need to report as well. This helps prevent unwanted and unnecessary bandwidth and processor utilization.</PARA>
<PARA>HostC (#5a) responds with a different group number, 224.2.155.145. Once all of the hosts have responded to the query, Router1 can maintain activity for these groups on interface E0.</PARA>
<PARA>Notice that this description applies to interface E0 on Router1. Simultaneously, a multicast flood to 224.0.0.1 was sent out interface E1 as well. The first host to respond on this segment is HostE (#2b), and it is reporting membership to 224.2.168.242. Notice that this report was not suppressed, even though HostD had already multicast a report to this group. The router queries the local All hosts address 224.0.0.1, which is not forwarded by the router. That is why the same query is sent out all interfaces on the router. Now that HostE has multicast to the group for that segment, none of the other hosts on the E1 segment will report due to the fact that they are all members of the 224.2.168.242 group.</PARA> -->
<PARA>The other processes are joining and leaving multicast groups. Both of these processes are quite simple and straightforward. You understand how interfaces are maintained in an active state through Membership Queries. The query process only runs every 60 seconds. If a host wants to join a multicast group outside the Membership Query interval, it may simply send an unsolicited report to the multicast router stating that it wants to receive data for the specified multicast group. Figure 9.9 depicts how this occurs. This is known as the <KEYTERM>IGMP Join process</KEYTERM>.</PARA>
<PARA>Withdrawal from a group is not initiated by the host as one would imagine. The router hosts a timer that is reset every time a response is received from a host on the subnet. The timer runs for 3 minutes, which is equivalent to 3 Membership Query cycles (every 60 seconds). If the timer expires and no response is received from the hosts on the interface, the router disables multicast forwarding on that interface.</PARA>
</SECTION>
</SECTION>
</SECTION>
<SECTION ID="9.3.3"><TITLE>Internet Group Management Protocol Version 2 (IGMPv2)</TITLE>
<PARA>As with any software revision, things are made better. Defined by RFC 2236, <KEYTERM>Internet Group Management Protocol version 2 (IGMPv2)</KEYTERM> provides the same functionality as version 1 did, but with a few enhancements:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>The Leave process in version 2 was included to avoid long time-outs that are experienced in version 1. </PARA></LISTITEM>
<LISTITEM><PARA>There are two Query forms, General and Group.</PARA></LISTITEM>
<LISTITEM><PARA>Network traffic is less bursty due to new timing mechanisms.</PARA></LISTITEM>
</LIST>
<PARACONTINUED>In the following sections, these enhancements will be discussed.</PARACONTINUED>
<PARA>It is important to be aware of issues when both versions of IGMP are present on the network. Version 2 provides backward compatibility with version 1, but the functionality of version 2 is lost when it's operating with version 1 devices. A version 2 host has to use version 1 frame formats when talking with a version 1 router. The same applies when a version 2 router tries to communicate with a version 1 host; it must use the version 1 format.</PARA>
<SECTION ID="9.3.3.1.1"><TITLE>General and Group-Specific Query Processes</TITLE>
<PARA>One enhancement that was made to IGMPv2 processes was the creation of a new query type. The Membership Query, as it was called in IGMPv1, was renamed General Queries, and the new type is Group-Specific Query. The new query type is used to query a specific multicast group (kind of obvious from the name). The overall procedure is the same as it is in IGMPv1.</PARA>
<PARA>When multiple IGMPv1 routers existed on the same segment, a multicast routing protocol made the decision as to which of all the multicast routers would perform the Membership Queries. Now, the decision is made using a feature added to IGMPv2. This feature is known as the Querier Election Process. </PARA>
<PARA>The frame for the query was changed to enable a Maximum Response Time that allows the hosts on the segment more time to respond to the query. This reduces the bursty traffic on the network.</PARA>
<!-- <PARA>IGMPv2 implemented the capability for hosts to remove themselves from the multicast group immediately (in a matter of seconds) instead of having to wait up to three minutes. The process is known as the <KEYTERM>IGMP Leave process</KEYTERM>. The two new additions of the Leave and Group-Specific messages work together to allow a host to remove itself from the multicast group immediately without interrupting the state of the interface on the multicast router.</PARA>
<PARA>Figure 9.10 depicts how the IGMPv2 Leave process works. First, HostA sends a Leave message to the All multicast routers address (224.0.0.2) expressing the intent to withdraw from the multicast group. Because Router1 doesn't know how many hosts on the segment belong to group 224.2.155.145, it must send a Group-Specific Query to see if there are any hosts that remain members of the group. If no responses are received, the router disables multicast forwarding out of the interface for the 224.2.155.145 group. If any hosts respond to the query, the router leaves the interface status quo. In the figure, you can see that HostB responds because it is still participating in the group 224.2.155.145. Hence, the interface is left active for that group.</PARA> -->
<SLUG NUM="9.10">Figure 9.10: IGMPv2 Leave process [f0910.eps]</SLUG>
</SECTION>
</SECTION>
</SECTION>
<SECTION ID="9.3.4"><TITLE>Cisco Group Management Protocol (CGMP)</TITLE>
<PARA>We have discussed IGMPv1 and IGMPv2, which are open standard protocols for host membership of multicast groups. When running multicast at layer 2, things get a little complicated for the switch. It doesn't know which packets are membership report messages or which are actual multicast group data packets because all of them have the same MAC address. <KEYTERM>Cisco Group Management Protocol (CGMP)</KEYTERM> was implemented to fill this void. It runs on both routers and switches.</PARA>
<PARA>The key feature of CGMP is that it uses two MAC addresses: </PARA>
<RUNINPARA>The USA is the unicast MAC address of the host. It allows the host to send multicast membership reports to the multicast router-the multicast router can also be a Route Switch Module (RSM) or Multilayer Switch Feature Card (MSFC)-and still tell the switch which port needs to receive the multicast data using the USA.</RUNINPARA></RUNINBLOCK>
<PARA>In addition to being able to make port assignments on the switch, CGMP also handles the interface assignment on the router. If a switch doesn't have any ports that need to receive multicast data, CGMP will inform the router that it doesn't need to forward multicast group data out the router interface.</PARA>
<!-- <PARA>CGMP uses many of the same processes IGMP uses. The main difference is that CGMP is used between the router and switch. When switches are involved, the IGMP requests must be translated to CGMP and passed on to the switch. These processes include the following:</PARA>
<PARA>Hosts do not use CGMP; only the switches and routers that the host connects to use it. When a host sends an IGMP report (membership report) advertising membership of a multicast group, the message is forwarded to the router (i.e., an actual multicast router, RSM, or an MSFC) for processing. The router sees the request and processes it accordingly. The multicast group is set up, and the two MAC addresses are generated. The router then gives the switch the CGMP message. With the CGMP message, the switch can assign the multicast group to the port of the requesting host. You can see the entire process in Figure 9.11.</PARA> -->
<SLUG NUM="9.11">Figure 9.11: CGMP Join process [f0911.eps]</SLUG>
<PARA>Host management is performed by the router. The router continues to receive IGMP messages from the host. Then the router converts the message into a CGMP message and forwards it to the switch. The switch then performs the port maintenance as directed by the router. This process is followed for the multiple types of message that the host can generate. </PARA>
<PARA>The CGMP Leave process is done in the same manner. The router receives the request and then informs the switch that the multicast group address needs to be removed from the Content Addressable Memory (CAM) table for the host's port.</PARA>
<PARA><DROPCAP>U</DROPCAP>p to this point, we have been discussing the host side of multicast. You have learned how hosts interact with switches and routers to join multi- cast groups and receive the traffic. It is now time to move on to discuss how multicast traffic travels across the Internet (or intranet) from a source on a remote network to a local router and host.</PARA>
<PARA>Unicast data uses routing protocols to accomplish the task of getting data to and from remote destinations. Multicast does the same, but it goes about it in a somewhat different manner. Unicast relies on routing tables. Multicast uses a sort of spanning tree system to distribute its data. The following sections describe the tree structures that can be implemented to allow multicast routing. In addition to trees, several different protocol methods can be used to achieve the desired implementation of multicast.</PARA>
<PARA>Two types of trees exist in multicast:</PARA>
<RUNINBLOCK><RUNINHEAD>Source trees</RUNINHEAD>
<RUNINPARA><KEYTERM>Source trees</KEYTERM> use the architecture of the source of the multicast traffic as the root of the tree. </RUNINPARA></RUNINBLOCK>
<RUNINBLOCK><RUNINHEAD>Shared trees</RUNINHEAD>
<RUNINPARA><KEYTERM>Shared trees</KEYTERM> use an architecture in which multiple sources share a common rendezvous point.</RUNINPARA></RUNINBLOCK>
<PARA>Each of these methods is effective and allows sourced multicast data to reach an arbitrary number of recipients of the multicast group. Let's discuss each of them in detail.</PARA>
<SECTION ID="9.4.1.1"><TITLE>Source Tree</TITLE>
<PARA>Source trees use special notation. This notation is used in what becomes a multicast route table. Unicast route tables use the destination address and next hop information to establish a topology for forwarding information. Here is a sample from a unicast routing table:</PARA>
<CODESNIPPET><CODELINE>B 210.70.150.0/24 [20/0] via 208.124.237.10, 3d08h</CODELINE>
<CODELINE>B 192.5.192.0/24 [20/0] via 208.124.237.10, 2w1d</CODELINE>
<CODELINE>B 193.219.28.0/24 [20/0] via 208.124.237.10, 1d03h</CODELINE>
<CODELINE>B 136.142.0.0/16 [20/0] via 208.124.237.10, 3d07h</CODELINE>
<CODELINE>B 202.213.23.0/24 [20/0] via 208.124.237.10, 1w2d</CODELINE>
<CODELINE> 202.246.53.0/24 is variably subnetted, 2 subnets, 2 masks</CODELINE>
<CODELINE>B 202.246.53.0/24 [20/0] via 208.124.237.10, 1w2d</CODELINE>
<CODELINE>B 202.246.53.60/32 [20/0] via 208.124.237.10, 1w2d</CODELINE></CODESNIPPET>
<PARA>Multicast route tables are somewhat different. Here is a sample of a multicast table. Notice that the notation is different. Instead of having the destination address listed and then the next hop to get to the destination, source tree uses the notation of (S, G). This notation specifies the source host's IP address and the multicast group address for which it is sourcing information. Let's take the first one, for example. This is seen as (198.32.163.74, 224.2.243.55), which means that the source host is 198.32.163.74 and it is sourcing traffic for the multicast group 224.2.243.55:</PARA>
<PARA>Figure 9.12 gives you a good picture of how source trees work.</PARA>
<SLUG NUM="9.12">Figure 9.12: Source tree forwarding [f0912.eps]</SLUG>
<PARA>Also notice in the drawing that the shortest path to the receivers was chosen. This is known as choosing the shortest path tree (SPT). You can see from the preceding output that there are three sources for the same group of 224.2.127.254. This indicates that there are three SPT groups shown here: (195.134.100.102, 224.2.127.254), (207.98.103.221, 224.2.127.254), and (128.39.2.23, 224.2.127.254). Each of these sources has its own shortest path tree to the receivers.</PARA>
</SECTION>
<SECTION ID="9.4.1.2"><TITLE>Shared Tree</TITLE>
<PARA>There are two types of shared tree distribution:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Unidirectional</PARA></LISTITEM>
<LISTITEM><PARA>Bidirectional</PARA></LISTITEM>
</LIST>
<PARA>They both work a little differently than source tree distribution. Shared tree architecture lies in the characteristic that there may be multiple sources for one multicast group. Instead of each individual source creating its own SPT and distributing the data apart from the other sources, a shared root is designated. Multiple sources for a multicast group forward their data to a shared root or rendezvous point (RP). The rendezvous point then follows SPT to forward the data to the members of the group. Figure 9.13 depicts how the shared tree distribution works.</PARA>
<SLUG NUM="9.13">Figure 9.13: Shared tree forwarding [f0913.eps]</SLUG>
<SECTION ID="9.4.1.2.1"><TITLE>Unidirectional Shared Tree Distribution</TITLE>
<PARA><KEYTERM>Unidirectional shared tree</KEYTERM> distribution operates as shown in Figure 9.13. All recipients of a multicast group receive the data from a rendezvous point (RP) no matter where they are located in the network.</PARA>
</SECTION>
<SECTION ID="9.4.1.2.2"><TITLE>Bidirectional Shared Tree Distribution</TITLE>
<PARA><KEYTERM>Bidirectional shared tree</KEYTERM> distribution operates somewhat differently. If a receiver lives upstream from the RP, it can receive data directly from the upstream source. Figure 9.14 depicts how this works. As you can see, HostA is a source for group 224.2.127.254 and HostB is a receiver of that same group. In a bidirectional shared tree, data goes directly from HostA to HostB without having to come from the RP.</PARA>
<SLUG NUM="9.14">Figure 9.14: Bidirectional shared tree [f0914.eps]</SLUG>
<PARA>Even though the tree distributions explain how source information is managed, we must now discuss how the actual data delivery is managed. There are several methods of making sure that delivery is as efficient as possible. The ones that will be discussed here are Reverse Path Forwarding (RPF), Time-to-Live (TTL) attributes, and routing protocols.</PARA>
<PARA>RPF works in tandem with the routing protocols, but it will be described briefly here. As you have seen in the figures, specifically Figures 9.13 and 9.14, the traffic goes only to the multicast group receivers. We also broached the fact that bidirectional distribution eliminates the need to forward data upstream. You may ask, "How do you define <EMPHASIS FORMAT="italic">upstream</EMPHASIS>?" It is easy to clarify. By means of the routing protocols, routers are aware of which interface leads to the source(s) of the multicast group. That interface is considered <EMPHASIS FORMAT="italic">upstream</EMPHASIS>.</PARA>
<PARA>The Reverse Path Forwarding process is based on the upstream information. When it receives an incoming multicast packet, the router verifies that the packet came in on an interface that leads back to the source. The router forwards the packet if the verification is positive, otherwise the packet is discarded. This check stops potential loops. To avoid increased overhead on the router's processor, a multicast forwarding cache is implemented for the RPF lookups. </PARA>
</SECTION>
<SECTION ID="9.4.3"><TITLE>Time to Live (TTL)</TITLE>
<PARA>You can also control the delivery of IP multicast packets through the TTL counter and TTL thresholds. The Time-to-Live counter is decremented by one every time the packet hops a router. Once the TTL counter is set to zero, the packet is discarded.</PARA>
<PARA>Thresholds are used to achieve higher granularity and greater control within one's own network. Thresholds are applied to specified interfaces of multicast-enabled routers. The router compares the threshold value of the multicast packet with the value specified in the interface configuration. If the TTL value of the packet is greater than or equal to the TTL threshold configured for the interface, the packet will be forwarded through that interface.</PARA>
<PARA>TTL thresholds allow network administrators to bound their network and limit the distribution of multicast packets beyond the boundaries. This is accomplished by setting high values for outbound external interfaces. The maximum value for the TTL threshold is 255. Refer to Figure 9.15 to see how network boundaries can be set to limit distribution of multicast traffic.</PARA>
<PARA>The multicast source initially sets the TTL value for the multicast packet and then forwards it on throughout the network. In this scenario, the TTL threshold values have been set to 200 on both of the exiting POS interfaces. The initial TTL value has been set to 30 by the application. There are three to four router hops to get out of the campus network. Router3 will decrement by one, leaving a TTL value of 29; the Catalyst 6509's MSFC will decrement by one as well, leaving the value set to 28. Once the packet gets to Router2 or Router1, the value will be 27 or 26 respectively. Both of these values are less than the TTL threshold of 200, which means Router1 and Router2 will drop any outbound multicast packets.</PARA>
<PARA>We now need to turn our attention to the variety of multicast routing protocols. Unicast has several routing protocols that build route tables that enable layer 3 devices such as routers and some switches to forward unicast data to the next hop toward its final destination. We have also discussed some of the methods that multicast, in general, uses to distribute multicast data. Similar to unicast, multicast has a variety of routing protocols, including distance vector and link state protocols.</PARA>
<PARA>Protocols are used to enhance the efficiency by which multicast application data is distributed and to optimize the use of existing network resources. This section will cover Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), and Protocol Independent Multicast (PIM).</PARA>
<PARA><KEYTERM>Distance Vector Multicast Routing Protocol (DVMRP)</KEYTERM> has achieved widespread use in the multicast world. A few years ago, you may have often heard the term "DVMRP Tunnel" used when discussing the implementation of multicast feeds from an ISP or a feed from the MBONE. As the name indicates, this protocol uses a distance vector algorithm. It uses several of the features that other distance vector protocols (such as RIP) implement. Some of these features are a 32 max hop-count, poison reverse, and 60-second route updates. It also allows for IP classless masking of addresses.</PARA>
<PARA>Just as with other routing protocols, DVMRP-enabled routers must establish adjacencies in order to share route information. Once the adjacency is established, the DVMRP route table is created. Route information is exchanged via route reports. It is important to remember that the DVMRP route table is stored separately from the unicast routing table. The DVMRP route table is more like a unicast route table than the multicast route table that was shown earlier in this chapter. A DVMRP table contains the layer 3 IP network of the multicast source and the next hop toward the source. </PARA>
<PARA>Because the DVMRP table has this form, it works perfectly in conjunction with source tree distribution, as discussed earlier. Using the information in the DVMRP table, the tree for the source can be established. In addition, the router uses this information to perform the Reverse Path Forwarding check to verify that the multicast data coming into the interface is coming in an interface that leads back to the source of the data. DVMRP uses SPT for its multicast forwarding.</PARA>
<PARA>Figure 9.16 gives a description of how DVMRP works. You can see that not every router in the network is a DVMRP router. You should also notice that the adjacencies are established over tunnel interfaces. DVMRP information is tunneled through an IP network. On either end of the tunnel, information is learned and exchanged to build a multicast forwarding database or route table. </PARA>
<SECTION ID="9.4.4.2"><TITLE>Multicast Open Shortest Path First (MOSPF)</TITLE>
<PARA>Now we will concentrate on <KEYTERM>Multicast Open Shortest Path First (MOSPF)</KEYTERM>, which is a link state protocol. OSPFv2 includes some changes to allow multicast to be enabled on OSPF-enabled routers. This eliminates the need for tunnels like those used for DVMRP.</PARA>
<PARA>To completely understand the full functionality of MOSPF, you must have a good understanding of OSPF itself. However, here we will attempt to cover only the basic functionality of MOSPF, so you should be fine with just a basic understanding of OSPF.</PARA>
<NOTE>For more on the OSPF, see <EMPHASIS FORMAT="italic">CCNP: Advanced Cisco Router Configuration </EMPHASIS>by Todd Lammle, Kevin Hales, and Don Porter (Sybex, 1999).</NOTE>
<PARA>MOSPF's basic functionality lies within a single OSPF area. Things get more complicated as you route multicast traffic to other areas (inter-area routing) or to other autonomous systems (inter-AS routing). This additional complication requires more knowledge of OSPF routing. We will briefly discuss how this is accomplished in MOSPF, but most detail will be given regarding MOSPF intra-area routing.</PARA>
<PARA>OSPF route information is shared via different Link State Advertisement (LSA) types. LSAs are flooded throughout an area to give all OSPF-enabled routers a logical image of the network topology. When changes are made to the topology, new LSAs are flooded to propagate the change. </PARA>
<PARA>In addition to the unicast-routing LSA types, in OSPFv2 there is a special multicast LSA for flooding multicast group information throughout the area. This additional LSA type required some modification to the OSPF frame format.</PARA>
<PARA>Here is where you need to understand a little about OSPF. Multicast LSA flooding is done by the Designated Router (DR) when there are multiple routers connected to a multi-access media, such as Ethernet. On point-to-point connections, there are no DR and Backup Designated Router (BDR). Look at the following code from a Cisco router running OSPF over point-to-point circuits.</PARA>
<CODESNIPPET><CODELINE>Neighbor ID Pri State Dead Time Address Interface</CODELINE>
<PARA>On a multi-access network, the DR must be multicast enabled; that is, running MOSPF. If there are any non-MOSPF routers on the same network, their OSPF priority must be lowered so none of them become the DR. If a non-MOSPF router were to become the DR, it would not be able to forward the multicast LSA to the other routers on the segment.</PARA>
<PARA>Inside the OSPF area, updates are sent describing which links have active multicast members on them so that the multicast data can be forwarded to those interfaces. MOSPF also uses (S, G) notation and calculates the SPT using the Dijkstra algorithm. You must also understand that an SPT is created for each source in the network. </PARA>
</SECTION>
<SECTION ID="9.4.4.2.2"><TITLE>Inter-Area and Inter-AS MOSPF</TITLE>
<PARA>When discussing the difference between intra-area and inter-area MOSPF, you must remember that all areas connect through Area 0, the backbone. In large networks, having full multicast tables in addition to all the unicast tables flow across Area 0 would cause a great deal of overhead and possibly latency. </PARA>
<PARA>Unicast OSPF uses a Summary LSA to inform the routers in Area 0 about the networks and topology in an adjacent area. This task is performed by the area's ABR (Area Border Router). The ABR summarizes all the information about the area and then passes it on to the backbone (Area 0) routers in a summary LSA. The same is done for the multicast topology. The ABR summarizes which multicast groups are active and which groups have sources within the area. This information is then sent to the backbone routers.</PARA>
<PARA>In addition to summarizing multicast group information, the ABR is responsible for the actual forwarding of multicast group traffic into and out of the area. Each area has an ABR that performs these two functions within an OSPF network.</PARA>
<PARA>OSPF implements Autonomous System Border Routers to be the bridges between different Autonomous Systems. These routers perform much the same as an ABR but must be able to communicate with non-OSPF speaking devices. Multicast group information and data is forwarded and received by the Multicast Autonomous Border Router (MASBR). Because MOSPF runs natively within OSPF, there must be a method or protocol by which the multicast information can be taken from MOSPF and communicated to the external AS. Historically, DVRMP has provided this bridge. </PARA>
</SECTION>
</SECTION>
<SECTION ID="9.4.4.3"><TITLE>PIM DM</TITLE>
<!-- <PARA>We briefly mentioned <KEYTERM>Protocol Independent Multicast (PIM)</KEYTERM> previously. Now we will dedicate some time to learning how it is used in conjunction with the other multicast routing protocols. Although <KEYTERM>PIM dense mode (PIM DM)</KEYTERM> maintains several functions, the ones that will be discussed here are flooding, pruning, and grafting.</PARA>
<PARA>PIM is considered "protocol independent" because it actually uses the unicast route table for RPF and multicast forwarding. PIM DM understands classless subnet masking and uses it when the router is running an IP classless unicast protocol.</PARA>
<PARA>PIM DM routers establish neighbor relationships with other routers running PIM DM. It uses these neighbors to establish an SPT and forward multicast data throughout the network. The SPT created by PIM DM is based on source tree distribution.</PARA>
<SECTION ID="9.4.4.3.1"><TITLE>Flooding</TITLE>
<PARA>When a multicast source begins to transmit data, PIM runs the RPF using the unicast route table to verify that the interface leads toward the source. It then forwards the data to all PIM neighbors. Those PIM neighbors then forward the data to their PIM neighbors. This happens throughout the network whether there are group members on the router or not. This is why it is considered <KEYTERM>flooding</KEYTERM>.</PARA>
<PARA>When multiple, equal-cost links exist, the router with the highest IP address is elected to be the incoming interface (used for RPF). Every router runs the RPF when it receives the multicast data.</PARA>
<PARA>Figure 9.17 depicts the initial multicast flooding in a PIM DM network. You can see that the data is forwarded to every PIM neighbor throughout the network. Once a PIM neighbor does the RPF calculation, the router will then forward the data to interfaces that have active members of the group.</PARA> -->
<PARA>After the initial flooding through the PIM neighbors, pruning starts. <KEYTERM>Pruning</KEYTERM> is the act of trimming down the SPT. Because the data has been forwarded to every router, regardless of group membership, the routers must now prune back the distribution of the multicast data to routers that actually have active group members connected.</PARA>
<PARA>Figure 9.18 shows the pruning action that occurs for the PIM DM routers that don't have active group members. Router5 does not have any active group members, so it sends a prune message to Router3. Even though Router4 has a network that does not have members, it does have an interface that does, so it will not send a prune message.</PARA> -->
<!-- <PARA>There are four criteria that merit a prune message being sent by a router:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>The incoming interface fails the RPF check.</PARA></LISTITEM>
<LISTITEM><PARA>There are no directly connected active group members and no PIM neighbors (considered a leaf router because it has no downstream PIM neighbors).</PARA></LISTITEM>
<LISTITEM><PARA>A point-to-point non-leaf router receives a prune request from a neighbor.</PARA></LISTITEM>
<LISTITEM><PARA>A LAN non-leaf router receives a prune request from another router and no other router on the segment overrides the prune request.</PARA></LISTITEM>
</LIST>
<PARACONTINUED>If any of these criteria are met, a prune request is sent to the PIM neighbor and the SPT is pruned back.</PARACONTINUED>
</SECTION>
<SECTION ID="9.4.4.3.3"><TITLE>Grafting</TITLE>
<PARA>PIM DM is also ready to forward multicast data once a previously inactive interface becomes active. This is done through the process of <KEYTERM>grafting</KEYTERM>. When a host sends an IGMP group membership report to the router, the router then sends a Graft message to the nearest upstream PIM neighbor. Once this message is acknowledged, multicast data begins to be forwarded to the router and on to the host. Figure 9.19 depicts the grafting process.</PARA> -->
<PARA>Sparse mode protocols use shared tree distribution as their forwarding methods. This is done to create a more efficient method of multicast distribution. There are two sparse mode protocols that will be discussed in this section:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Core-based trees (CBT)</PARA></LISTITEM>
<PARA>When we discussed shared trees, you learned that there were two types, unidirectional and bidirectional. CBT utilizes the bidirectional method for its multicast data distribution. Because CBT uses a shared tree system, it designates a <EMPHASIS FORMAT="italic">core</EMPHASIS> router that is used as the root of the tree, allowing data to flow up or down the tree.</PARA>
<PARA>Data forwarding in a CBT multicast system is similar to the shared tree distribution covered earlier. If a source to a multicast group sends multicast data to the CBT-enabled router, the router then forwards the data out all interfaces that are included in the tree, not just the interface that leads to the <EMPHASIS FORMAT="italic">core</EMPHASIS> router. In this manner, data flows up and down the tree. Once the data gets to the <EMPHASIS FORMAT="italic">core</EMPHASIS> router, the <EMPHASIS FORMAT="italic">core</EMPHASIS> router then forwards the information to the other routers that are in the tree. Figure 9.20 depicts this process.</PARA>
<SLUG NUM="9.20">Figure 9.20: CBT data distribution [f0920.eps]</SLUG>
<PARA>It is important to see the difference between this sparse mode method and the dense mode method. In sparse mode operation, routers are members of the tree only if they have active members directly connected. Dense mode operates on the initial premise that all PIM neighbors have active members directly connected. The tree changes when the directly connected routers request to be pruned from the tree.</PARA>
<PARA>A CBT router may become part of the tree once a host sends an IGMP Membership Record to the directly connected router. The router then sends a join tree request to the <EMPHASIS FORMAT="italic">core</EMPHASIS> router. If the request reaches a CBT tree member first, that router will add the <EMPHASIS FORMAT="italic">leaf</EMPHASIS> router to the tree and begin forwarding multicast data.</PARA>
<PARA>Pruning the tree is done much the same way. Once there are no more active members on a router's interfaces, the router will send a prune request to the upstream router. The answering router will remove the interface from the forwarding cache if it is on a point-to-point circuit, or it will wait for a timer to expire it if is on a shared access network. The timer gives enough time for other CBT routers on the segment to override the prune request.</PARA>
</SECTION>
<SECTION ID="9.4.5.2"><TITLE>PIM SM</TITLE>
<PARA><KEYTERM>PIM sparse mode (PIM SM)</KEYTERM> also uses the architecture of shared tree distribution. There is an RP (rendezvous point) router that acts as the root of the shared tree. Unlike CBT, however, PIM SM uses the unidirectional shared tree distribution mechanism. Because PIM SM uses the unidirectional method, all multicast sources for any group must register with the RP of the shared tree. This enables the RP and other routers to establish the RPT, or RP tree (synonymous with SPT in source tree distribution).</PARA>
<PARA>Just as with CBT, PIM SM routers join the shared tree when they are notified via IGMP that a host requests membership of a multicast group. If the existing group entry (*, G) does not already exist in the router's table, it is created and the join tree request is sent to the next hop toward the RP. The next router receives the request. Based on whether or not it has an exiting entry for (*, G), two things can happen:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>If an entry for (*, G) exists, the router simply adds the interface to the shared tree and no further join requests are sent toward the RP.</PARA></LISTITEM>
<LISTITEM><PARA>If an entry for (*, G) does not exist, the router creates an entry for the (*, G) group and adds the link to the forwarding cache. In addition to doing this, the router sends its own join request toward the RP.</PARA></LISTITEM>
</LIST>
<PARA>This happens until the join request reaches a router that already has the (*, G) entry or a join request reaches the RP.</PARA>
<PARA>The next facet of PIM SM is the shared tree pruning. With PIM SM, pruning turns out to be just the opposite of the explicit Join mechanism used to construct the shared tree. </PARA>
<PARA>When a member leaves a group, it does so via IGMP. When it happens to be the last member on a segment, the router removes the interface from the forwarding cache entry and then sends a prune request toward the RP of the shared tree. If there is another router with active members connected to the router requesting the prune, it is removed from the outgoing interface list and no additional Prune messages are sent to the RP. See Figure 9.21 for a visual description. </PARA>
<SLUG NUM="9.21">Figure 9.21: PIM SM pruning [f0921.eps]</SLUG>
<PARA>Router5 receives an IGMP message requesting the removal of HostG from the group. Because HostG was the last active member of the group, the (*, G) entry is set to null 0 and a prune request is sent by Router5 to Router3. When Router3 receives the request, it removes the link for interface S0 from the forwarding table. Because HostF is a directly connected active member of the group, the entry for (*, G) is not null 0, so no prune request is sent to Router2 (the RP for this example).</PARA>
<PARA>If HostF were not active, the entry for (*, G) would have been set to null 0 also and a prune request would have been sent to the RP.</PARA>
</SECTION>
</SECTION>
</SECTION>
<SECTION ID="9.5"><TITLE>Summary</TITLE>
<PARA><DROPCAP>I</DROPCAP>n this chapter, we described the many different facets of IP multicast. We started out with an overview of multicast and compared it with unicast and broadcast communications. We then discussed how IP addresses were designated as multicast addresses. You learned how to convert them to layer 2 MAC addresses also.</PARA>
<PARA>The implementation of multicast can have significant impact on a network. This merited the topics regarding managing multicast distribution. Once you understood the basics of multicast and how hosts and sources participate, we were able to move on and cover topics regarding the different types of routing protocols that were made for multicast routing. Finally, we discussed PIM-DM, PIM-SM, and CBT. These are independent protocols that use tree distribution to manage multicast data delivery in a network.</PARA>
<PARA>Because this chapter focused on theory instead of configuration, there were no commands introduced. Therefore, this chapter doesn't include a table of commands, nor does it include a written lab and hands-on lab. You'll learn more about configuring multicast in <NOBR REF="10">Chapter 10</NOBR>.</PARA>
