each other and with the server by multicast. When an individual driving a tank or a fighter enters a grid square, it joins the multicast group to receive that square’s simulation traffic. As the individual moves from square to square, the individual’s multicast group membership changes.

IP multicasting uses Class D network addresses to route data to different groups and hosts. Most basic networking classes cover Classes A, B, and C, but usually don’t go into depth about Classes D and E. Maybe you were told that they are used for experimental purposes and not to worry about them. Well, as you will see in the next few sections, things have changed.

IP Multicasting Addresses

IP multicasting uses a variation of a Class D network address space assigned by the Internet Assigned Number Authority (IANA). A Class D address is denoted with a binary 1110 prefix in the first octet. The range spans from 224.0.0.0 to 239.255.255.255. Applications use one of the addresses in this range as the multicast group address on the Internet.

Note A permanent IP multicast address is rarely assigned to an application. Instead, the address is assigned to a specific network protocol or network application. Applications on the Internet must dynamically request a multicast address when needed and release the address when it is no longer being used.

Due to the nature of multicast addresses, they are frequently referred to as multicast groups. In addition, certain well−known groups have been identified by the IANA. These are detailed in RFC 2365 and are known as administrative scopes. We will discuss this topic later in this section.

The Multicast IP Structure

An IP multicast frame contains a single IP address. The host group is also identified by a single IP address. This process operates at Layer 3. However, switches do not understand IP addresses; they operate with Media Access Control (MAC) addresses. Let’s look at how the Layer 3 address is mapped to a Layer 2 address.

IP MAC addresses are 48 bits long. If the first 24 bits are set to 01−00−5e, with the next bit set to 0, that leaves 23 bits for the IP address to be mapped to the MAC address. The multicast IP address is 32 bits long with 28 unique bits. So, only the last 23 bits of the IP address are mapped to the MAC address.

Figure 7.4 shows the MAC address and IP address mapping.

Figure 7.4: The IP multicast address structure.

Let’s take a quick look at how this process works. Consider the multicast address 224.138.8.5:

1110 0000 1000 1010 0000 1000 0000 0101 XXXX XXXX X000 1010 0000 1000 0000 0101

140

The X bits are not used. The remaining bits

000 1010 0000 1000 0000 0101

give you 0a:08:05. Put that result together with 01:00:5e: and you get 01:00:5e:0a:08:05.

Here is another example, using the multicast address 224.127.15.10:

1110 0000 0111 1111 0000 1111 0000 1010 XXXX XXXX X111 1111 0000 1111 0000 1010

After removing the X portion, the section

111 1111 0000 1111 0000 1010

yields 7f:0f:0a. Again, you put this result together with 01:00:5e to get 01:00:5e:7f:0f:0a.

This process creates an ambiguity when a Layer 3 IP address is mapped to the Layer 2 MAC address. A 32−to−1 relationship (2^5) exists, meaning that for every multicast MAC address, there are 32 corresponding IP addresses. Figure 7.5 shows the MAC address ambiguities.

Figure 7.5: The 32−to−1 relationship of IP addresses to MAC address.

A host that is set up to receive multicast group 224.127.15.10 will have the network interface card interrupt the CPU when a frame with the destination MAC address 01:00:5e:7f:0f:0a arrives. This MAC address is also used by 31 other multicast groups. If any of these groups are active on the LAN, the CPU will have to examine the frames for both multicast groups to decide if the frame that interrupted the CPU belongs to the desired multicast group. This process could degrade the performance of the host PC if many multicast groups are on the network. You must consider this fact when assigning multicast groups to applications.

Special Multicast Addresses

The range from 224.0.0.0 to 224.0.0.255 is reserved for use on the network by network protocols. Cisco routers by default do not forward IP multicast frames that arrive for this range. Routers that forward these packets are known as broken routers. Routing protocols use this range to communicate with each other (see Table 7.1).

Table 7.1: Partial list of non−routed local multicast addresses.

141

The range from 224.0.1.0 to 224.1.255.255 is assigned by IANA to network protocols and network applications on a permanent basis. To obtain one of these addresses, you must have a really good technical justification.

The range from 239.0.0.0 to 239.255.255.255 contains administratively scoped addresses for use in private networks, similar to the use of 10.x.x.x for IP addresses. The network administrator must ensure that this kind of multicast traffic does not leave the private network.

The range from 224.2.0.0 to 233.255.255.255 is dynamically assigned to applications that require a multicast address. This process is similar to the way Dynamic Host Configuration Protocol (DHCP) assigns IP addresses to hosts. The multicast address is allocated or leased when it’s needed and released to be used by others when it’s not needed. The Session Directory (SDR) program currently is the most widely used method of dynamically allocating IP multicast addresses. The Internet Engineering Task Force (IETF) is considering modifying SDR to enable it to scale well or to define and develop a new form of dynamic multicast address allocation.

Note IANA has started to assign blocks of multicast addresses from this range. To review a current list of multicast addresses, visit www.isi.edu/in−notes/iana/assignments/multicast−addresses.

Delivery of Multicast Datagrams

When the sender and recipients are members of the same subnet, delivery of multicast frames is a simple matter. The source station addresses the IP packet to the multicast group, the Network Interface Card (NIC) maps the IP address to the multicast MAC address, and the frame is sent. Recipients that want to capture the frame notify their IP layer that they want to receive datagrams addressed to the group.

When the sender is on one subnet and the recipients are on different subnets, the routers need to use a multicast routing protocol that permits the construction of multicast delivery trees and supports multicast data packet forwarding.

Multicast Distribution Tree

The multicast model uses one source and many destinations. The packet travels from one router to many routers on different paths. This route forms a multicast distribution tree, with the first router as the root. Multicast distribution tree is a dynamic visualization of how the multicast packet travels the network. The packet travels from one router to the next until it reaches the destination—it follows a line from end to end.

Note In unicast, there is no such tree.

There are two types of distribution trees: source trees and shared trees.

The source tree is the simplest type of tree. The source of the multicast traffic forms the root of the tree and the branches are the paths through the network to the destination. This form is commonly referred to as the

142

shortest path tree (SPT) because it uses the shortest path to reach the destination. This design functions very well in a one−to−many model, but it has drawbacks when used in a many−to−many model. For example, a live concert has only one source, so there will be only one distribution tree in the router for the multicast group. But in a video conference with 20 participants, you will have 20 different trees for the same multicast group.

In a shared tree design, the entire multicast group utilizes the same distribution path. The root is placed at a selected point in the network. Protocol Independent Multicast (PIM) refers to this router/point as the rendezvous point; Core−Based Tree (CBT) multicast routing protocol refers to this router as the core. All multicast traffic for that group is first sent to the root/rendezvous point. It then flows out the branches to the destination. Only one distribution tree exists for the multicast group, which in turn means each router only has to keep track of one path for that multicast group.

The only difference between the source tree and the shared tree in a one−to−many multicast is that the root moves from the first router to some other point in the network. In a many−to−many multicast, the differences and advantages become more significant. The shared tree is subdivided into unidirectional and bidirectional trees. In the unidirectional shared tree, the multicast traffic can first be unicast to the root for distribution to the rest of the multicast group; it can also be sent as a multicast using the source tree model with the source as the root and the shared tree root as the branch. A bidirectional shared tree takes advantage of the existing routing table to distribute multicast traffic to the multicast group. Multicast traffic can go back the same path by which it came to the rendezvous point and be distributed from the root. Before the traffic reaches the root, it follows the multicast routing table to the other destinations. This way, the multicast traffic flows only one time on any path on the network.

Multicast Forwarding

Let’s look at how the routers make the distribution tree. In unicast traffic, the router makes a forwarding decision based on the destination address. It looks up the address in the routing table and forwards the packet to the next hop via the associated interface. In multicast traffic, rather than a single IP address, a multicast address is associated with multiple hosts; this addressing makes the forwarding decision more complex.

The router utilizes Reverse Path Forwarding (RPF) to make the forwarding decision. Instead of using the destination address, the router uses the source address. It checks the source address and determines whether the packet comes from an interface that leads back to the source address. If the packet did not arrive on an interface that leads back to the source, the RPF check fails and the packet is discarded. If the packet comes from the interface that leads back to the source, the packet is forwarded out the other interfaces on the router.

The router determines which interface is on the reverse path back to the source using either the unicast routing table or a separate multicast routing table. This routing decision is based on the multicast routing protocol.

IGMP Protocols

In order to build multicast routes for each multicast group, routers communicate with each other via one of the following protocols:

∙DVMRP—Distance Vector Multicast Routing Protocol

∙PIM—Protocol Independent Multicast

∙MOSPF—Multicast Open Shortest Path First

143

Distance Vector Multicast Routing Protocol

DVMRP is based on RIP and is widely used. Just like RIP, it uses a distance vector (hops) and sends out periodic route updates. It’s different from RIP in that it is classless and has a hop limit of 32 rather than 16. When DVMRP is first implemented on a router, it sends a probe packet with its IP address out all the interfaces. Another DVMRP router receives the probe and adds the IP address to its list of DVMRP neighbors on that interface. It then sends back a probe with its IP address and the first router’s IP address. When the first router receives a probe with its own IP address, it knows that it has a two−way adjacency between itself and the other router. The two routers will then begin to exchange routing information.

As stated earlier, the router uses RPF to ensure that a packet arrives on the correct interface. If the packet fails the RPF check, it is discarded. When it passes the RPF check, the packet is forward out all other interfaces. As the multicast traffic is sent out, it reaches every point in the network. That’s great if every host on the network wants the multicast—but if part of the network does not need the multicast, the traffic is just taking up bandwidth. To overcome this problem, the multicast routers use a process called pruning. If the router is not connected to a recipient (multicast destination), it sends a prune message to the upstream router to stop the flow of unnecessary multicast traffic. The upstream router responds by pruning the connection to the router. If the interface on the upstream router is connected to another router, it also must send a prune message before the upstream router will prune traffic from that interface. As the prune message traffic flows from one router to another, the multicast traffic is only sent to the portion of the network that wants it. If the router wants to receive multicast traffic after being pruned, it must send a graft message to the upstream router. When the upstream router receives the graft message, it sends out a graft−ack message. If that router is not receiving the multicast traffic, it will also send a graft message to its upstream router. The graft message will be sent until it reaches a router that is receiving the multicast traffic.

DVMRP sends out periodic updates. It cannot be used in a network with a diameter greater than 31 hops, and it does not consider the bandwidth of the link. It was the first multicast routing protocol, so, despite its limitations, it is deployed in the Internet Multicast Backbone (MBONE). The MBONE is used primarily to transmit desktop video conferencing and—due to the use of DVMRP as its protocol—it has been responsible

for several Internet meltdowns when the volume of traffic has become overwhelming.

Protocol Independent Multicast

Protocol Independent Multicast (PIM) is an IP multicast routing protocol that is independent of the unicast routing protocol on the router. It does not maintain a multicast routing table, but instead uses the unicast routing table. The routing table can be populated in many ways: OSPF, static routes, Enhanced IGRP (EIGRP), Border Gateway Protocol (BGP), and so on. By using the existing routing table to perform reverse path forwarding checks, PIM sends out no updates and the overhead on the router is significantly reduced.

PIM operates in two modes:

∙Dense mode (DM)—Utilizes the source tree distribution model. It is designed to operate in an environment where bandwidth is plentiful and the multicast traffic is destined for all LANs. DM is suitable for environments with a small number of senders and many recipients. DM is also a good choice in high−traffic networks with a constant stream of multicast traffic. PIM−DM enabled routers that have no local members of a multicast group will prune themselves from that group with prune messages sent to neighboring IP multicast routers. The neighbors that receive the prune messages stop sending multicast messages and start a timer. When this timer expires, they begin sending multicast messages to the pruned group again. This process is known as the broadcast and prune cycle.

∙Sparse mode (SM)—Uses the unidirectional shared tree design. It is designed to operate in environments where group members are distributed across many regions of the Internet and bandwidth may not be widely available. SM does not imply that the group has few members, just that they are widely dispersed across the Internet. The objective of SM is to prevent situations in which a relatively small number of devices want to participate in a multicast environment and cause the multicast traffic to overwhelm the network. SM is designed to limit multicast traffic so that only those routers interested in receiving traffic for a particular group participate in it. Each router that wishes to

144