Chapter 1.

Introduction to IP Multicast

There are three data communication methods in IP networks: unicast,

broadcast, and multicast. To establish a baseline, it is important to under-
stand the fundamental elements of unicast and broadcast before we ex-
plore the details of multicast communication methods.

Unicast communication at Layer 3 (the Network layer) of the Open

Systems Interconnect (OSI) model is based on the IP address of the desti-
nation device. Routers learn about routes by static or dynamic methods
and forward traffic by looking at the destination IP address. Layer 2 (the
Data Link layer) uses another mechanism to establish communication be-
tween devices using media access control (MAC) addresses.

Take a look at Figure 1-1. The sender is sending a message to Receiver A,

and this requires a combination of both L2 and L3 services. The sender
learns the MAC address of the gateway using the Address Resolution
Protocol (ARP) and sends IP traffic destined to any network other than the
local subnet to the gateway/router. The router looks at the destination IP
address and forwards the packet to the next router based on the informa-
tion in the routing table (Layer 3). The destination router receives the
packet and forwards it to the receiver (Receiver A, in this example). As
you can see, the Sender never learns the MAC address of Receiver A be-
cause Receiver A is not on the same subnet.

Figure 1-1 Unicast Packet Forwarding Example

Most nontechnical people are familiar with broadcasting. A broadcast, in
this classic sense, is a signal that is propagated through electromagnetic
waves in the air. The signal saturates the broadcast area, and retrieving
the communication is a simple matter of tuning in to a specific frequency.
In the networking world, a broadcast is a message sent to all devices on a
subnet or a Layer 2 domain, and every device has an obligation to check
the message to validate whether they are an intended recipient.

NOTE

An Ethernet broadcast is very different from an IP broadcast.

Remember that IP packets (Layer 3) are encapsulated inside
an Ethernet frame (Layer 2). There are source addresses and
destination addresses at each layer, and each receives differ-
ent treatment by networking devices. The destination ad-
dress of a Layer 3 broadcast in IP is all ones in the host por-
tion of the address. Thus, all hosts would be 255.255.255.255.
At Layer 2, an all-hosts broadcast is ffff.ffff.ffff, and switches
must replicate these packets when forwarding in order to
reach all intended recipients, regardless of physical segment
(known as flooding). If a device was looking for a particular
IP host but did not know the destination MAC address, it
could send an IP unicast message encapsulated in an all-
hosts Ethernet broadcast. Every machine on the Ethernet
segment receives the packet, but only the intended IP host
processes the packet fully and responds. In fact, this is ex-
actly what an initial ARP request looks like.

We have traditionally used a router or Layer 3–capable switch to segment

broadcast domains and protect devices from unwanted traffic. This
means the router or Layer 3 switch must inspect Ethernet and IP headers
and search for broadcast messages. If a packet is a broadcast packet, the
router must make a forwarding decision on the destination address. If the
address is a local broadcast (intended for only local hosts) the router
should drop the packet because this is usually in the format of an all-hosts
broadcast (255.255.255.255). If the address is a directed broadcast (a
broadcast intended for a specific segment or subnet, such as, for example,
10.1.1.255) the router may forward the broadcast toward the targeted seg-
ment, or it may respond if the receiving interface is on the intended
segment.

A multicast message is a similar, more efficient version of a broadcast,

which is a replicated packet that is sent to a set of hosts. The primary ex-
ception is that with a multicast message, the intended recipients of the
flow could be on any segment instead of on one specific segment. This
process of receiving a single packet, replicating it, and sending copies to
additional network interfaces is the key to understanding how multicast
works, from the highest to the lowest level. Routers and switches must
replicate the packet from the source interface and forward toward re-
ceivers. Multicast incorporates the concept of selective learning of data
flow by multiple receivers in Layer 2 and 3 domains. Multicast data distri-
bution methods optimize bandwidth usage and create an efficient
method of data distribution.

What Problem Does Multicast Solve?

The purpose of multicast is to send information to a select group of de-

vices and to avoid duplication of traffic streams, consequently saving pre-
cious network resources such as bandwidth utilization.

Consider the other two mechanisms to propagate information throughout

a network—unicast and broadcast. Using the example of an Internet ra-
dio station transmitting information, unicast requires that each device on
the network interested in listening to the audio stream has a unique ses-
sion established. As shown in Figure 1-2, unicast has one sender and
three receivers. A sender is a device that generates information and ad-
vertises it to a group, and a receiver is a device that listens to the
information.
Figure 1-2 Unicast Using Multiple Streams

Because each stream is being replicated, the sender must replicate the in-
formation for each client and the network connection takes three times
the bandwidth. This may not be a big problem for a low-bandwidth audio
session with only three users, but consider scaling to tens of thousands or
millions of sessions. Replicating information for every client creates a sig-
nificant impact on network resources.

By using broadcasts, the radio station can minimize the number of ses-
sions the sender has to be concerned with, which reduces bandwidth
from the sender to the network; however, in this case, the radio station
has a different challenge. Referring to Figure 1-3, the problem of replicat-
ing numerous streams has been eliminated, and the bandwidth challenge
has been mitigated, but now every device receives the radio station
whether they are interested in listening to it or not. As the number of ra-
dio stations increases, every device on the network becomes more and
more inundated with information it might not want. The receivers are
now obligated to process the radio streams and to decide whether that in-
formation is relevant. Welcome to networking in the 1980s and 1990s,
when broadcast storms were a common occurrence.
Figure 1-3 Broadcast

Multicast to the rescue! We have the best of both worlds with multicast,
minimizing the number of sessions required by the sender and reducing
the network load to a single traffic flow. We also obtain the benefits of
unicast by sending the radio station packets only to the devices interested
in receiving them. Referring to Figure 1-4, with multicast, only a single
stream is sent and replicated to the interested receivers.

Figure 1-4 Multicast

IP multicast messages are transmitted from one-to-many, from many-to-

many, and/or from many-to-one over an IP infrastructure that may span
Layer 3 boundaries. The destination nodes (receivers) send join and leave
messages that create an on-demand community of devices interested in
receiving the multicast stream. Multicast optimally uses network re-
sources by requiring the source to send a single packet stream, even
though large numbers of receivers might need to receive the messages.
The replication of messages takes place at the network node(s) or Layer 3
device(s) and diverges the stream to the receivers. The optimization of the
message flow of multicast is leveraged by many applications. These appli-
cations are one of the major driving forces for the adoption of multicast
in the network infrastructure. Some of the more common applications
that rely on multicast are as follows:

Stock exchanges

Computer imaging applications

Music-on-hold services

Sensor updates

Video distribution

Corporate webcasts

Having a good understanding of the nuances of multicast enables you to

effectively support those applications and services that rely on multicast
as a transport mechanism. This chapter covers some of the applications
and services that rely on multicast, examines the history of multicast, and
delves into some of the standards.

Multicast Applications and Services

The network infrastructure is in place to support applications and ser-

vices. These applications and services allow an entity—a government
agency, bank, retail organization, hospital, emergency services, or any
other business or institution—to fulfill its mission or business objective.
Establishing an infrastructure that enables the effective use of these mul-
ticast applications and services helps to ensure the success of that
organization.

One-to-Many Multicast Applications

The most common form of multicast applications is one-to-many, as

shown in Figure 1-5.
Figure 1-5 Multicast Using One-to-Many

As the name implies, there is one sender and multiple simultaneous re-
ceivers. Typical applications include video and audio broadcast, but there
are many other applications as well, including the following:

Television

Radio

Distance learning

Presentation sharing and whiteboard applications

Computer imaging software and application updates

Data distribution and caching

Informational updates:

Weather

News

Time—Network Time Protocol (NTP)

Sensors that collect environment information (water levels, tempera-

tures, seismic readings, and so on).
Many-to-Many Multicast Applications

With many-to-many multicast applications, the senders also act as re-

ceivers. This permits all the devices in the group to simultaneously com-
municate with one another, as shown in Figure 1-6.

Figure 1-6 Multicast Using Many-to-Many

Many-to-many applications include the following:

Audio and video communication

Document sharing and whiteboard applications

Data distribution, caching, and synchronization

Group chat applications

Financial applications

Polling applications

Multiplayer games.
Many-to-One Multicast Applications

Many-to-one applications have many senders but only one or few re-
ceivers, as shown in Figure 1-7. This is not a common multicast offering,
and it has a significant challenge in that the receiver might not be able to
process the information when many devices are sending multicast flows.
Scalability is a significant concern with this model. In some ways, this
model is not an improvement over using unicast streams but instead al-
lows configuration flexibility for the application. In fact, in many cases,
the receiver will respond to senders via a unicast flow. See RFC 3170 for
more details on many-to-one applications.

Figure 1-7 Multicast Using Many-to-One

Some of the applications for many-to-one include the following:

Data collection

Service discovery

Polling

Multicast applications can consume a tremendous amount of bandwidth,

as with high-definition video, or it can consume very little network band-
width, as in time updates. All of these applications rely on the infrastruc-
ture for the successful operation of the previously mentioned applica-
tions and services.
Multicast Packet

As mentioned previously, multicast is a communication method for

reaching many participants with a single message flow. In an Ethernet
network running Internet Protocol (IP), the active components that make
up the infrastructure, primarily routers and switches, are responsible for
replicating the single packet flow into multiple packets or messages that
are efficiently distributed to other devices interested in receiving those
messages.

This warrants a brief review of the Open Systems Interconnect (OSI)

model and an explanation of where multicast is applied to the different
layers. The OSI model is comprised of the elements shown in Table 1-1.

Table 1-1 Multicast Applied to the OSI Reference Model

Multicast applications commonly use User Datagram Protocol (UDP) on IP.

Consequently, the Transport layer is used, and this would not be possible
without the Network layer running the IP protocol. The IP layer is also
where routers primarily function. The Data Link layer is where Ethernet
switches replicate multicast traffic on a subnet using multicast media ac-
cess control (MAC) addresses.

You need to have a solid understanding of the OSI model to comprehend

the dynamics of IP multicast technologies and how each layer interacts
with one another.
 NOTE

We refer to a frame as a Layer 2 message in that we are fo-

cusing on the source and/or destination MAC address. A
packet is a Layer 3 message that includes a source and a des-
tination IP address.

It is important to understand exactly how routers build a

multicast routing information base (MRIB) and how they use
the unicast routing information base (RIB) to ensure loop-
free forwarding paths. Mathematically, a tree is the best way
for a routing or switching device to guarantee loop free
topologies. Multicast routers and switches are master tree
builders, which will be covered in more detail throughout
this book.

What Is a Source?

When speaking about multicast, there are always two types of hosts, a
multicast source and a multicast receiver. A multicast source can be any
device with an IP address in the network. To become a source, a host only
needs to send a message to a multicast group IP address. (See Figure 1-8.)
The three senders in this diagram are all sending to the same multicast
destination address of 239.1.1.1.

Figure 1-8 Multicast Source

A source does not need to indicate any intention to send to a group before
sending a multicast message. Any IP enabled device, including a router or
switch, can send packets toward a multicast group. When an IP multicast
router processes a message destined to a multicast group, a new multicast
forwarding entry is created. This is the Source, Group entry and is called
source comma group, (S, G). The (S, G) entry for Sender A in Figure 1-8
would be (192.168.0.2, 239.1.1.1).

The (S, G) entry refers to the source IP address and the destination group
separated by a comma. The IP addresses of the senders in Figure 1-8 are
the source (S) addresses, whereas the destination IP address of the group
is G. Notice that the three devices are all sending to the same group ad-
dress. Could this be a problem? Keep that thought in the back of your
mind as you continue reading.

What Is a Receiver?

A receiver is any multicast-enabled device that has expressed interest in a

particular multicast group or a specific (S, G) pair. Unless the multicast is
link-local (not passed on through the network by any router, such as, for
example, the “all-routers” IPv4 group of 224.0.0.2), the IP devices must be
configured by the administrator or by an application to subscribe to a
specific multicast group. After it’s subscribed, a multicast receiver listens
for packets that arrive with the multicast group destination address, like
group 239.1.1.1 used in Figure 1-8.

Group subscription is managed by the Internet Group Messaging Protocol

(IGMP). When a receiver subscription for a specific group or set of groups
is received or initiated by a router, the router adds what is called a star
comma G, (*, G) entry to the MRIB. The (*, G) entry simply represents that
the router has an interest in the group.
 NOTE

Multicast forwarding information based (MFIB) and multicast

routing information base (MRIB) are terms used to under-
stand the multicast flow in Cisco routers.

The MRIB is responsible for routing information that is gen-

erated by multicast protocols. This information feeds into the
MFIB responsible for forwarding multicast packets and col-
lecting statistics on the multicast flow.

L3 Multicast Is Built on the TCP/IP Protocol Stack

IP multicast is built on the TCP/IP protocol stack. That means that the pro-
tocols necessary to transport multicast frames and packets are controlled
by the Internet Engineering Task Force (IETF). IETF members develop and
manage protocols through the RFC process, which means that IP multi-
cast protocols are open standards.

NOTE

Multicast protocol IETF development applies to both IPv4

and IPv6 multicast technologies; however, as with other IP-
based protocols, that does not mean that every manufacturer
treats multicast the same. It also does not mean that every
implementation of multicast protocols is perfectly standard-
compliant.

Using the TCP/IP stack also means that IP multicast is subject to the
Internet Assigned Numbers Authority (IANA). IANA controls and coordi-
nates the assignment and use of IP addresses in public spaces. This in-
cludes multicast address assignment.
It’s a Group Thing

A contrast and comparison between L3 unicasts, broadcasts, and multi-

casts will illustrate the uniqueness of multicast transmissions. The pri-
mary difference between a broadcast and a multicast is that multicast re-
ceivers can connect anywhere on any network segment or subnet,
whereas subnets define broadcast boundaries, called broadcast domains.
Routers and switches must therefore have a way of recognizing which
segments and subnets connect interested multicast hosts. Senders and re-
ceivers manage this process through group membership.

A broadcast uses a specific destination IP address in the packet to reach

each receiving host. Routers and switches immediately recognize broad-
casts without any additional protocol overhead because the subnet de-
fines the broadcast boundary. The following packet header breakdowns
show the difference between a unicast IPv4 packet, a broadcast IPv4
packet, and a multicast IPv4 packet. Figure 1-9 illustrates a basic unicast
IP packet.

Figure 1-9 IPv4 Unicast Packet

Forwarding a unicast message is a simple task—follow the route to the IP

destination. Broadcasts are equally simple to forward. Broadcast packets
also follow the route to the destination, but they are replicated on any
switch ports that belong to the appropriate logical Ethernet segment
(VLAN or subnet). There are two types of broadcasts, all-hosts broadcasts
and directed broadcasts. An all-hosts broadcast is intended for every IP
host on every subnet in which it is forwarded. A directed broadcast is in-
tended for every IP host only within a given subnet/supernet or VLAN.
 NOTE

Replication is the simple process of making a copy of a

packet to forward through the network. Replication is re-
quired anytime a single packet has more than one intended
recipient, as, for example, with broadcasts and multicasts.
Replication is a basic function of any active networking de-
vice such as a switch or router.

If the broadcast includes all-hosts, then the local switch simply replicates
the broadcast packet for each interface in the logical segment on which
the packet was received. Figure 1-10 depicts an all-hosts broadcast on a
local segment. Routers, by their nature, do not forward all-hosts broad-
casts received on an interface in a given subnet, consequently segmenting
the broadcast domain from the rest of the network.

Figure 1-10 All-Hosts Broadcast Packet (Indicated by 255.255.255.255 as

the Destination IPv4 Address and ffff.ffff.ffff as the Destination MAC
Address)

If a broadcast is directed, it is sent through the network toward the in-

tended subnet and replicated by any switch on that subnet, as shown in
Figure 1-11.
Figure 1-11 Directed Broadcast Packet (Indicated by the 10.2.2.255
Destination IPv4 Address, or All Hosts on the 10.2.2.0 Subnet)

The difference between a multicast and a broadcast with hosts on a single

subnet is subtle. What if only a few of the hosts on the subnet need to re-
ceive the packets? Using a group address to which hosts can subscribe
would ease the burden of sending packets to the select hosts on that seg-
ment, reduce replication overhead, and use the bandwidth only in the
LAN where the hosts are located. Figure 1-12 illustrates just such a
scenario.

Figure 1-12 Multicast Forwarding to Hosts on a Single Segment

The major difference between a broadcast and multicast is that sub-

scribed hosts of a multicast flow may exist on multiple segments. How
can routers and switches then forward to only those hosts without repli-
cating the packet for every segment in a network or on the Internet?
Multicast senders transmit IP packets using a specific destination IP ad-
dress known as a group address using a specific multicast MAC address.
You may have noticed the L2 destination address is not an address on the
local subnet. This will be discussed further in Chapter 2, “Network
Access and Layer 2 Multicast.”

IPv4 Layer 3 Multicast Addressing Defines Groups

The group address simply identifies a group of nodes interested in a flow.

The group address combined with the source IP address identifies the
multicast flow. Host receivers express interest in the flow by notifying up-
stream network devices of group membership. This expression of interest
is known as joining the group.

IPv4 and IPv6 group addressing is controlled by a combination of IETF

RFCs. The most important and current IPv4 RFC is 5771, which finalizes
assignment of the multicast group address space and the individual group
types within that space. The multicast group block address space is de-
rived from IPv4 classful address space. Table 1-2 details classful routing
addressing assignment.

Table 1-2 IPv4 Classful Addressing

Class D addressing is reserved by RFC 5771 for multicast group assign-

ments. RFC 5771 replaced or updated several RFCs, including RFC 988,
which in 1986 originally proposed 1110 as the high-order bit reservation
for IPv4 multicast group identification. RFC 988 supersedes RFC 966, the
original IP multicast theory RFC. Both RFC 988 and 966 are important to
the history of multicast, and a thorough understanding of the theory in
each is a great starting point for anyone wishing to dive more deeply into
the roots of multicast technology and terminology.
IPv4 Multicast Group Address Assignments

RFC 5771 further expands the Class D address for suggested IANA multi-
cast group address assignment and deployment. Table 1-3 illustrates this
assignment.

Table 1-3 IPv4 Multicast Address Assignment

The following is a brief explanation of each block type, and the proper
usage:

Local Network Control block (224.0.0/24): The local control block is

used for specific protocol control traffic. Router interfaces listen to but do
not forward local control multicasts; for example, OSPF “all routers”
(224.0.0.5). Assignments in this block are publicly controlled by IANA. You
can find a complete list of Local Network Control address assignments at
the IANA website (www.iana.org).

NOTE

Routers listen for local control packets only if the control

group feature is enabled on the node. For example, a router
interface would only process RIPv2 control group packets
(group 224.0.0.9) if RIPv2 is enabled on that interface.

Internetwork Control block (224.0.1/24): The Internetwork Control

block is for protocol control traffic that router interfaces may forward
through the autonomous system number (ASN) or through the Internet.
Examples include 224.0.1.1 Network Time Protocol (NTP), defined in RFC
4330, and 224.0.1.68 mdhcpdiscover, defined in RFC 2730. Internetwork
Control group assignments are also publicly controlled by IANA.

AD-HOC blocks (I: 224.0.2.0–224.0.255.255, II: 224.3.0.0–224.4.255.255,

and III:233.252.0.0–233.255.255.255): Traditionally assigned to applica-
tions that do not fit in either the Local or Internetwork Control blocks.
Router interfaces may forward AD-HOC packets globally. Most applica-
tions using AD-HOC blocks require few group addresses (such as, for ex-
ample, less than a /24 space). IANA controls any public AD-HOC Block as-
signments and future assignments will come from AD-HOC block III, if
they are not more suited to Local Control or Internetwork Control. Public
use of unassigned AD-HOC space is also permitted.

SDP/SAP block (224.2.0.0/16): The Session Description Protocol/Session

Announcement Protocol (SDP/SAP) block is assigned to applications that
receive addresses through the SAP as described in RFC 2974.

Source-Specific Multicast block (232.0.0.0/8): SSM addressing is de-

fined by RFC 4607. SSM is a group model of IP Multicast in which multi-
cast traffic is forwarded to receivers from only those multicast sources
for which the receivers have explicitly expressed interest. SSM is mostly
used in one-to-many applications. No official assignment from IANA is re-
quired to use the SSM block because the application is local to the host;
however, according to IANA policy, the block is explicitly reserved for
SSM applications and must not be used for any other purpose. SSM will
be discussed further in subsequent sections of this and other chapters.

NOTE

The 232.0.0.0/8 block was originally assigned by IANA for use

by the Versatile Message Transaction Protocol (VMTP).

GLOP block (233.0.0.0/8): These addresses are statically assigned with a

global scope. Each GLOP static assignment corresponds to a domain with
a public 16-bit autonomous system number (ASN), which is issued by
IANA. The ASN is inserted in dotted-decimal into the middle two octets of
the multicast group address (X.Y). An example GLOP assignment for an
ASN of X.Y would be 233.X.Y.0/24. Domains using an assigned 32-bit ASN
should apply for group assignments from the AD-HOC III Block. Another
alternative is to use IPv6 multicast group addressing. Because the ASN is
public, IANA does not need to assign the actual GLOP groups. The GLOP
Block is intended for use by public content, network, and Internet service
providers. IANA considers GLOP addressing to be experimental, and
233.252–255.0.0 is reserved.

Administratively Scoped block (239.0.0.0/8): Administratively Scoped

addresses are intended for local use within a private domain as described
by RFC 2365. These group addresses serve a similar function as RFC 1918
private IP address block (such as, for example, 10.0.0.0/8 or 172.16-
31.0.0/16 blocks). Network architects can create an address schema using
this block that best suits the needs of the private domain and can further
split scoping into specific geographies, applications, or networks. Further
information on best practices for scoping this block can be found in
Chapter 5, “IP Multicast Design Considerations and Implementation.”

Important Multicast Groups and Group Considerations

There are many multicast groups, each subdivided from a larger block of
multicast group ranges. Each of the group block ranges has a specific ap-
plication or scope. The scope of each block ranges from single segments to
large enterprise multicast networks to the global Internet. It is important
to understand the RFC and standards for multicast groups when design-
ing multicast networks. Multicast group addresses play a very important
part in “scoping” the multicast domains. Chapter 5 explains this concept
in more detail.
 NOTE

IANA manages globally scoped address assignments as well

as any protocol assignments for applications. Without con-
trol over these addresses, there would be little possibility of
using them for protocol interchange or standards-driven
communication.

IPv4 Local Network Control

The Local Network Control block, also known as the Link-Local block, con-
sists of IANA assigned addresses between 224.0.0.0 and 224.0.0.255. These
multicast groups are intended for use within a single subnet or segment.
They are not to be forwarded by routers, and therefore have a time-to-
live (TTL) value of 1. Many well-known applications and communications
protocols have reserved address assignments.

Application developers and network administrators should not use group

addresses in this block for any purpose other than the IANA assigned ap-
plication. Table 1-4 lists some of the most relevant assignments from the
link-local multicast address, taken directly from the IANA database. The
table lists the reserved multicast addresses, the protocol function as-
signed, and relevant RFCs.
Table 1-4 IPv4 Link-Local Multicast Addresses

As the table illustrates, many important network functions rely on link-lo-

cal multicasting. Routing protocols, including EIGRP, RIPv2, and OSPF use
these protocols to send updates to neighbor routers. IGMP also uses a
link-local multicast address to notify gateway routers of group subscrip-
tion. The important point to remember is that the Layer 3 devices will not
replicate or forward these packets. Layer 2 devices will forward link-local
multicast frames only on ports within the same Layer 2 domain (VLAN or
subnet).
IPv4 Inter-Network Control

The Inter-Network Control block is similar to the Local Network Control

block, with the exception that multicast applications using this block may
require that multicast packets be forwarded beyond the local segment.
The block ranges from 224.0.1.0 to 224.0.1.255. Table 1-5 provides a par-
tial list of some of the more important Internetwork Control block assign-
ments as made by IANA.
Table 1-5 Inter-Network Multicast Address Addresses

Many infrastructure protocols use assigned Inter-Network Control block

group addresses for protocol communication. A good example of Inter-
Network Control multicast is the Cisco Auto-RP protocol. Cisco Auto-RP
uses multicast groups 224.0.1.39 and 224.0.1.40 to dynamically assign, ad-
vertise, and discover rendezvous points (RPs) in a PIM sparse mode net-
work domain; 224.0.1.39 is used for Cisco Announce; and 224.0.1.40 is
used for Cisco Discovery.

Using IP multicast for infrastructure communication simplifies the proto-

col design process. After a multicast address is assigned to a particular ap-
plication or protocol, developers need only send packets to the assigned
address to facilitate protocol intercommunication between many devices.
Several of the existing assignments from the Inter-Network Control block
may be for applications or protocols that will never be deployed on a
large scale. Approximately one-third of the block space remains for fu-
ture development.

The History of Multicast

Necessity is the mother of invention. Steve Deering was a student of

Stanford University in the early 1980s, working on a distributed process-
ing project. One of the underlying communication mechanisms allowed
one device to send a message to many other devices as a single update. As
the project grew, so did the requirement for compute resources. These re-
sources were distributed throughout the campus, which required a mech-
anism to communicate to those devices over a router (L3) infrastructure.
This could have been accomplished using multiple unicast messages, or
by broadcasting the messages across the entire network. Neither of these
methods were an acceptable solution in this case because they were too
inefficient. The resolution required a unique single group address, the
ability for the routers to participate in sending the messages, and the ca-
pability to have the hosts join or leave the group at will—hence, the birth
of multicast.
The MBone

The multicast backbone (MBone) project was started ten years after Dr.
Deering’s invention of multicast. The routers that comprised the Internet
at that time did not have the capability to support native multicast; conse-
quently, the MBone was a handful of Unix hosts connected over tunnels
using Distance Vector Multicast Routing Protocol (DVMRP), running a dae-
mon called mrouted. The MBone at that time was driven by higher-educa-
tion institutions and was used to deliver content such as the Internet
Engineering Task Force (IETF) meetings, concerts, and so on, all with a
very limited scope of viewing.

Native Internet Multicast

Native Internet multicast would allow anyone with an Internet connec-

tion to view content. Could you imagine being able to watch any TV chan-
nel, listen to any radio station, participate in distance learning sessions,
all via multicast? Unfortunately, the experiment of the MBone driven by
academia in the 1990s has still not moved to a mainstream service of-
fered by Internet Service Providers (ISPs), because many service
providers do not support the transport of multicast traffic across their
network. The adoption of multicast by ISPs has been slowed by security
concerns, the complexity of implementation, and the capability to easily
share multicast routing information.

This has not diminished the need for multicast within private networks.
As we reviewed earlier, there are many applications that benefit from an
infrastructure that transports multicast traffic. We can still take advan-
tage of the transport services of the Internet by tunneling multicast traffic
over it, even if it is not supported natively.

IPv6 Multicast

The rapid growth of the Internet is causing the depletion of IPv4 address
space. Consequently, IPv6 is taking hold to provide for the expansion of
the Internet and to permit our ability to access any device on the planet.

IPv4 addresses use 32 bits for a numerical value to distinguish individual

devices, whereas IPv6 uses 128 bits. This increase offers tremendous scal-
ability. The implementation of IPv6 has another interesting characteristic
in that it no longer supports network broadcasts. The two methods of
communication with IPv6 are either unicast or multicast. Because multi-
cast was considered during the creation of the protocol, there are inher-
ent capabilities that improve the operation. Besides the greater amount of
address space, there are other features in IPv6 that make the multicast
designs simpler. You will learn much more about the functionality of IPv6
and multicast in Chapter 6, “IPv6 Multicast Networks.”

Multicast Development and Standardization

Just as with many other networking technologies, the effort being made
to improve multicast has continued. There have been many enhance-
ments to address the shortfalls and feature enhancements that were not
foreseen during the creation of the protocol.

Could you imagine if every developer decided to write code based on how
they thought it should work? Fortunately, standardization groups collabo-
rate on how to solve technical challenges and create documentation on
how those solutions are to be addressed to achieve compatibility and in-
teroperability. There are two major standards bodies that help to drive
common implementation methodologies, the Internet Engineering Task
Force (IETF) and the Institute of Electrical and Electronic Engineers
(IEEE).
 NOTE

The charter of the Internet Engineering Task Force (IETF) is

to make the Internet work better by producing high-quality
and relevant technical documents that influence the way
people design, use, and manage the Internet. The IETF gener-
ates documents such as requests for comment (RFC) and best
current practices (BCP).

The Institute of Electrical and Electronics Engineers (IEEE) is

the largest technical professional society and is an associa-
tion dedicated to advancing innovation and technological ex-
cellence for the benefit of humanity. Besides developing stan-
dards for Ethernet, the IETF develops standards for many
other areas.

Summary

The three data communication methods in IP networks are unicast,

broadcast, and multicast. Each of these methods has advantages and dis-
advantages depending on the application. Multicast offers an efficient
communication mechanism for sending messages to multiple recipients
in separate locations. It is also capable of supporting many-to-many and
many-to-one communication.

Multicast applications commonly use User Datagram Protocol (UDP) on IP.

Messages are sent by a source (called the sender) and will send messages
(termed as a stream) even if there is not another device on the network
interested in receiving that information. Receivers, on the other hand,
must subscribe to a particular multicast stream in order to inform the
network to forward those messages.

IP addressing for multicast is also unique. There are many public and pri-
vate addresses that have been allocated for different applications and ser-
vices. It is imperative to understand what addresses you plan to use prior
to building out a multicast network.

Multicast was developed in the early 1980s from a research project at

Stanford University. Improvements continue as new applications and ser-
vices are developed and to address security concerns.