At one end of the IP communication spectrum is IP unicast communication,
where a source IP host sends packets to a specific destination IP host. In
this case, the destination address in the IP packet is the address of a single,
unique host in the IP network. These IP packets are forwarded across the network
from the source host to the destination host by routers. The routers at each
point along the path between the source and destination use their unicast Routing Information Base
(RIB) to make unicast forwarding decisions based on the IP destination address
in the packet.
At the other end of the IP communication spectrum is an IP broadcast,
where a source host sends packets to all IP hosts on a network segment. The
destination address of an IP broadcast packet has the host portion of the
destination IP address set to all ones and the network portion set to the
address of the subnet (see Figure1-1).
(In some cases the host portion is set to all zeros, but this form of IP broadcast
address is generally no longer used.)
IP hosts (including routers) understand that packets, which contain an IP
broadcast address as the destination address, are addressed to all IP hosts
on the subnet. Unless specifically configured otherwise, routers do not forward
IP broadcast packets and, therefore, IP broadcast communication is normally
limited to the local subnet. Figure1-2
clearly illustrates this point.
In this example, Host A sends
out a broadcast to the local subnet 184.108.40.206/24. Because Hosts B and C are
on the same subnet as Host A, they receive the broadcast. Host D, however,
is on a different subnet (220.127.116.11/24) and does not receive the broadcast
because the router does not forward broadcasts. If routers forwarded these
broadcasts, route loops are likely to cause a catastrophic broadcast storm.
If your goal is to permit a host to send IP packets to other hosts not
on the local subnet, then IP broadcasting is not sufficient to accomplish
IP multicasting falls between IP unicast and IP broadcast communication
and enables a host to send IP packets to a group of hosts anywhere within
the IP network. To do so, the destination address in an IP multicast packet
is a special form of IP address called an IP multicast
group address. (The format of IP multicast group addresses and
exactly how hosts become members of a multicast group are explained in Chapter 2, “Multicast Basics.”) IP multicast routers must forward incoming IP multicast packets out all interfaces
that lead to members of the IP multicast group. The IP multicast group address
is specified in the IP destination address field of the packet.
Exactly how the routers learn which interface to forward the packet
to is part of the magic of IP multicast routing. The explanation of how this
magic works is one of the goals of this book. By the time you finish reading
this book, you should have a good understanding not only of how IP multicasting
works in general but also of how to design efficient IP multicast networks
using Cisco routers.
This chapter offers a brief history of IP multicasting, a discussion
on the pros and cons of multicast, a description of various multicast applications,
and an introduction to the multicast backbone.
At Stanford University in the early 1980s, a doctoral graduate
student, Steve Deering, was working on a distributed
operating system project for his advisor, David Cheriton. This distributed operating system was called Vsystem
and was composed of several computers tied together into a loosely coupled
multiprocessing system via a single Ethernet segment. The computers on this Ethernet
segment worked together and communicated at the operating system level via
special messages sent on the common Ethernet segment. One of the operating
system primitives permitted one computer to send a message to a group of the
other computers on the local Ethernet segment using a MAC layer multicast.
As the project progressed, the need arose to add more computers to the
multiprocessing system. Unfortunately, the only available computers were on
the other side of the campus with production routers between the two networks.
Consequently, the graduate students had to extend the operating system's inter-processor
communications to work at Layer 3 of the OSI reference model so that the computers
on the other side of the campus could function as part of the loosely coupled
multiprocessor system. In addition, the MAC layer multicast messaging would
also have to be extended to work at Layer 3. The task of finding a way to
extend the MAC layer multicast capability across the Layer 3 routed network
primarily fell to Steve Deering.
After studying the Open Shortest Path First (OSPF) Protocol and the
Routing Information Protocol (RIP) IP routing protocols, Steve concluded that
the link-state mechanisms of OSPF could certainly be extended to support multicasting.
He also concluded that the basic mechanisms of RIP could be used as the basis
for a new distance vector-based multicast routing protocol. This idea led
to more research into the area of IP multicasting and ultimately resulted
in Steve Deering's doctoral thesis, “Multicast
Routing in a Datagram Network,” published in December 1991.
Dr. Deering's thesis also described a Host Membership Protocol, which
became the basis for today's Internet Group Membership
Protocol (IGMP) that IP multicast hosts use to signal
to the router on the network that they desire to join a multicast group. In
addition, Dr. Deering's thesis described a distance vector-based IP multicast
routing protocol that was the basis for the Distance Vector Multicast Routing Protocol (DVMRP), also
developed by Dr. Deering a few years later. These two protocols provided the
first successful extensions to the IP packet network model to allow multicasting
to be extended to Layer 3 of the OSI model. Since that time, advances in IP
multicasting technology have continued and additional protocols such as Protocol
Independent Multicasting (PIM) and multiprotocol extensions to the Border
Gateway Protocol (BGP) have been developed. These protocols permit IP multicasting
to scale beyond the initial limited implementations to large, enterprise-wide
multicast networks and eventually on to a native, completely multicast-enabled