12.

4 Multicasting

IP multicasting provides two services for an application.

1. Delivery to multiple destinations. There are many applications that deliver information to
multiple recipients: interactive conferencing and dissemination of mail or news to
multiple recipients, for example. Without multicasting these types of services tend to use
TCP today (delivering a separate copy to each destination). Even with multicasting, some
of these applications might continue to use TCP for its reliability.
2. Solicitation of servers by clients. A diskless workstation, for example, needs to locate a
bootstrap server. Today this is provided using a broadcast (as we'll see with BOOTP in
Chapter 16), but a multicast solution would impose less overhead on the hosts that don't
provide the service.

In this section we'll take a look at multicast addresses, and the next chapter looks at the protocol
used by multicasting hosts and routers (IGMP).

Multicast Group Addresses

Figure 12.2 shows the format of a class D IP address.

Figure 12.2. Format of a class D IP address.

Unlike the other three classes of IP addresses (A, B, and C), which we showed in Figure 1.5, the
28 bits allocated for the multicast group ID have no further structure.

A multicast group address is the combination of the high-order 4 bits of 1110 and the multicast
group ID. These are normally written as dotted-decimal numbers and are in the range 224.0.0.0
through 239.255.255.255.

The set of hosts listening to a particular IP multicast address is called a host group. A host group
can span multiple networks. Membership in a host group is dynamic— hosts may join and leave
host groups at will. There is no restriction on the number of hosts in a group, and a host does not
have to belong to a group to send a message to that group.

Some multicast group addresses are assigned as well-known addresses by the IANA (Internet
Assigned Numbers Authority). These are called permanent host groups. This is similar to the
well-known TCP and UDP port numbers. Similarly, these well-known multicast addresses are
listed in the latest Assigned Numbers RFC. Notice that it is the multicast address of the group
that is permanent, not the membership of the group.
For example, 224.0.0.1 means "all systems on this subnet," and 224.0.0.2 means "all routers on
this subnet." The multicast address 224.0.1.1 is for NTP, the Network Time Protocol, 224.0.0.9
is for RIP-2 (Section 10.5), and 224.0.1.2 is for SGI's (Silicon Graphics) dogfight application.

Converting Multicast Group Addresses to Ethernet Addresses

The IANA owns an Ethernet address block, which in hexadecimal is 00:00:5e. This is the high-
order 24 bits of the Ethernet address, meaning that this block includes addresses in the range
00:00:5e:00:00:00 through 00:00:5e:ff:ff:ff. The IANA allocates half of this block for
multicast addresses. Given that the first byte of any Ethernet address must be 01 to specify a
multicast address, this means the Ethernet addresses corresponding to IP multicasting are in the
range 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff.

Our notation here uses the Internet standard bit order, for a CSMA/CD or token bus network, as
the bits appear in memory. This is what most programmers and system administrators deal with.
The IEEE documentation uses the transmission order of the bits. The Assigned Numbers RFC
gives additional details on the differences between these representations.

This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group
ID. The mapping places the low-order 23 bits of the multicast group ID into these 23 bits of the
Ethernet address. This is shown in Figure 12.3.

Figure 12.3. Mapping of a class D IP address into Ethernet multicast address.

Since the upper 5 bits of the multicast group ID are ignored in this mapping, it is not unique.
Thirty-two different multicast group IDs map to each Ethernet address. For example, the
multicast addresses 224.128.64.32 (hex e0.80.40.20) and 224.0.64.32 (hex e0.00.40.20)
both map into the Ethernet address 01:00:5e:00:40:20.

Since the mapping is not unique, it implies that the device driver or the IP module in Figure 12.1
must perform filtering, since the interface card may receive multicast frames in which the host is
really not interested. Also, if the interface card doesn't provide adequate filtering of multicast
frames, the device driver may have to receive all multicast frames, and perform the filtering
itself.
LAN interface cards tend to come in two varieties. One type performs multicast filtering based
on the hash value of the multicast hardware address, which means some unwanted frames can
always get through. The other type has a small, fixed number of multicast addresses to listen for,
meaning that when the host needs to receive more multicast addresses than are supported, the
interface must be put into a "multicast promiscuous" mode. Hence, both types of interfaces still
require that the device driver perform checking that the received frame is really wanted.

Even if the interface performs perfect multicast filtering (based on the 48-bit hardware address),
since the mapping from a class D IP address to a 48-bit hardware address is not one-to-one,
filtering is still required.

Despite this imperfect address mapping and hardware filtering, multicasting is still better than
broadcasting.

Multicasting on a single physical network is simple. The sending process specifies a destination
IP address that is a multicast address, the device driver converts this to the corresponding
Ethernet address, and sends it. The receiving processes must notify their IP layers that they want
to receive datagrams destined for a given multicast address, and the device driver must somehow
enable reception of these multicast frames. This is called "joining a multicast group." (The
reason we use the plural "receiving processes" is because there are normally multiple receivers
for a given multicast message, either on the same host or on multiple hosts, which is why we're
using multicasting in the first place.) When a multicast datagram is received by a host, it must
deliver a copy to all the processes that belong to that multicast group. This is different from UDP
where a single process receives an incoming unicast UDP datagram. With multicasting it is
possible for multiple processes on a given host to belong to the same multicast group.

But complications arise when we extend multicasting beyond a single physical network and pass
multicast packets through routers. A protocol is needed for multicast routers to know if any hosts
on a given physical network belong to a given multicast group. This protocol is called the
Internet Group Management Protocol (IGMP) and is the topic of the next chapter.

Multicasting on FDDI and Token Ring Networks

FDDI networks use the same mapping between the class D IP address and the 48-bit FDDI
address [Katz 1990]. Token ring networks normally use a different mapping, because of
limitations in most token ring controllers [Pusateri 1993].