Multicast Routing
See Also:
Introduction
Traditional network computing applications involve communication between two
computers. However, some important emerging applications such as LAN TV,
desktop conferencing, corporate broadcasts, and collaborative computing
require simultaneous communication between groups of computers. This process
is known generically as multipoint communications.
Design Considerations
There are three ways to design multipoint networking applications: unicast,
broadcast, and multicast.
- Unicast. With a unicast design, applications can send one copy of
each
packet to each member of the multicast group. This technique is
simple to implement, but it has significant scaling restrictions
if the group is large. In addition, it requires extra bandwidth,
because the same information has to be carried multiple times --
even on shared links.
- Broadcast. In a broadcast design, applications can send one copy of
each packet and address it to a broadcast address. This technique
is even simpler than unicast for the application to implement.
However, if this technique is used, the network must either stop
broadcasts at the LAN boundary (a technique that is frequently
used to prevent broadcast storms) or send the broadcast
everywhere. Sending the broadcast everywhere is a significant
usage of network resources if only a small group actually needed
to see the packets.
- Multicast. With a multicast design, applications can send one
copy of
each packet and address it to the group of computers that want to
receive it. This technique addresses packets to a group of
receivers rather than to a single receiver, and it depends on the
network to forward the packets to only the networks that need to
receive them.
Multicast can be implemented at both the data-link layer and the network
layer. Ethernet and FDDI, for example, support unicast, multicast, and
broadcast addresses. An individual computer can listen to a unicast address,
several multicast addresses, and the broadcast address. Token Ring also
supports the concept of multicast addressing but uses a different technique.
Token Rings have functional addresses that can be used to address groups of
receivers.
If the scope of an application is limited to a single LAN, using a data-link
layer multicast technique is sufficient. However, many multipoint
applications are valuable precisely because they are not limited to a
single LAN.
When a multipoint application is extended to an internet consisting of
different media types, such as Ethernet, Token Ring, FDDI, ATM, Frame Relay,
SMDS, and other networking technologies, it is best to implement multicast at
the network layer.
There are several parameters that the network layer must define in order to
support multicast communications:
- Addressing. There must be a network-layer address that is used to
communicate with a group of receivers rather than a single
receiver. In addition, there must be a mechanism for mapping this
address onto data-link layer multicast addresses where they exist.
- Dynamic registration. There must be a mechanism for the computer to
communicate to the network that it is a member of a particular
group. Without this ability, the network cannot know which
networks need to receive traffic for each group.
- Multicast routing. The network must be able to build packet
distribution trees that allow sources to send packets to all
receivers. A primary goal of these packet distribution trees is to
ensure that each packet exists only one time on any given network
(that is, if there are multiple receivers on a given branch, there
should only be one copy of the packets on that branch).
IP Multicast
The Internet Engineering Task Force has been developing standards that
address each of the issues described above.
- Addressing. The IP address space is divided into four pieces:
Class A,
Class B, Class C, and Class D. Classes A, B, and C are used for
unicast traffic. Class D is reserved for multicast traffic. Class
D addresses are allocated dynamically.
- Dynamic registration. RFC 1112 defines the Internet Group
Membership
Protocol (IGMP). IGMP specifies how the host should inform the
network that it is a member of a particular multicast group.
- Multicast routing. There are several standards available for
routing IP
Multicast traffic:
- RFC 1075 defines the Distance Vector Multicast Routing Protocol
(DVMRP).
- RFC 1584 defines the Multicast Open Shortest Path First (MOSPF)
protocol -- an extension to OSPF that allows it to support IP
Multicast.
- Two Internet standards-track drafts describe PIM -- a multicast
protocol that can be used in conjunction with all unicast IP routing
protocols. These documents are entitled Protocol-Independent
Multicast
(PIM): Motivation and Architecture and Protocol-Independent
Multicast
(PIM): Protocol Specification.
DVMRP (RFC 1075)
DVMRP uses a technique known as Reverse Path Forwarding. When a router
receives a packet, it floods the packet out of all paths except the one that
leads back to the packet's source. Doing so allows a data stream to reach all
LANs (possibly multiple times). If a router is attached to a set of LANs that
do not want to receive a particular multicast group, the router can send a
"prune" message back up the distribution tree to stop subsequent packets from
traveling where there are no members.
DVMRP will periodically reflood in order to reach any new hosts that want to
receive a particular group. There is a direct relationship between the time
it takes for a new receiver to get the data stream and the frequency of
flooding.
DVMRP implements its own unicast routing protocol in order to determine which
interface leads back to the source of the data stream. This unicast routing
protocol is very like RIP and is based purely on hop counts. As a result, the
path that the multicast traffic follows may not be the same as the path that
the unicast traffic follows.
DVMRP has significant scaling problems because of the necessity to flood
frequently. This limitation is exacerbated by the fact that early
implementations of DVMRP did not implement pruning.
DVMRP has been used to build the MBONE -- a multicast backbone across the
public Internet -- by building tunnels between DVMRP-capable machines. The
MBONE is used widely in the research community to transmit the proceedings of
various conferences and to permit desktop conferencing.
Multicast Extensions to OSPF (RFC 1584)
Multicast OSPF (MOSPF) was defined as an extension to the OSPF unicast
routing protocol. OSPF works by having each router in a network understand
all of the available links in the network. Each OSPF router calculates routes
from itself to all possible destinations.
MOSPF works by including multicast information in OSPF link state
advertisements. An MOSPF router learns which multicast groups are active on
which LANs.
MOSPF builds a distribution tree for each source/group pair and computes a
tree for active sources sending to the group. The tree state is cached, and
trees must be recomputed when a link state change occurs or when the cache
times out.
MOSPF works only in internetworks that are using OSPF.
MOSPF is best suited for environments that have relatively few source/group
pairs active at any given time. It will work less well in environments that
have many active sources or environments that have unstable links.
PIM (Internet Draft "Protocol-Independent Multicast [PIM]: Protocol
Specification")
Protocol-Independent Multicast (PIM) works with all existing unicast routing
protocols. PIM supports two different types of multipoint traffic
distribution patterns: dense and sparse.
Dense mode is most useful when:
- Senders and receivers are in close proximity to one another.
- There are few senders and many receivers.
- The volume of multicast traffic is high.
- The stream of multicast traffic is constant.
Dense-mode PIM uses Reverse Path Forwarding and looks a lot like DVMRP. The
most significant difference between DVMRP and dense-mode PIM is that PIM
works with whatever unicast protocol is being used; PIM does not require any
particular unicast protocol.
Sparse multicast is most useful when:
- There are few receivers in a group.
- Senders and receivers are separated by WAN links.
- The type of traffic is intermittent.
Sparse-mode PIM is optimized for environments where there are many multipoint
data streams. Each data stream goes to a relatively small number of the LANs
in the internetwork. For these types of groups, Reverse Path Forwarding
techniques waste bandwidth. Sparse-mode PIM works by defining a Rendezvous
Point. When a sender wants to send data, it first sends to the Rendezvous
Point. When a receiver wants to receive data, it registers with the
Rendezvous Point. Once the data stream begins to flow from sender to
Rendezvous Point to receiver, the routers in the path will optimize the path
automatically to remove any unnecessary hops. Sparse-mode PIM assumes that no
hosts want the multicast traffic unless they specifically ask for it.
PIM is able to simultaneously support dense mode for some multipoint groups
and sparse mode for others.
Conclusion
New computer networking applications continue to create the need for new
communication protocols. Multipoint applications such as collaborative
computing, desktop conferencing, and LAN TV have the potential to
significantly improve productivity. In order to support these applications it
will be necessary to build networks that can implement multicast efficiently.
Posted: Fri Mar 19 09:48:52 PST 1999