From: Seth Cooper (scooper@cs.washington.edu)
Date: Wed Nov 10 2004 - 01:01:25 PST
This paper presents PIM, or Protocol Independent Multicast. It is thus
named because of its does not rely on a particular underlying unicast
protocol. PIM build upon previous multicast protocols; however, PIM is
designed with the idea of sparse multicast groups in mind. Previous
multicast algorithms worked well for dense multicast groups, but with
sparse groups they would be wasteful by sending either data or
membership information, and storing state in routers, where it wasn't
needed. PIM presents a method of preventing this waste, even when
multicasting to a sparse group across a large network.
One strength of PIM that the paper presents is that PIM allows groups
to choose whether they want to use a shortest-path or group-shared tree.
Thus a group can decide how to make the trade off between path length
and router state for itself, per group; it is not built into the
protocol one way or the other. This allows flexibility in the protocol.
Another strength is that downstream members must explicitly join a
group to receive messages. This contrasts dense multicast, where
membership is assumed, and routers without members mush periodically
prune themselves from the multicast tree. In a large network,
multicasting to all hosts would be expensive, as would be continually
sending prune messages.
A weakness of PIM presented by the paper is that PIM, as well as other
multicast protocols, may have issues with scaling. As the number of
groups across the Internet grows, the amount of state needed in routers
will also grow. Although PIM scales in some respects because it is
designed to work for sparse groups, if some aspect of PIM keeps it from
scaling, the whole protocol doesn't scale. The paper does present some
methods for scaling, but does not solve the problem entirely.
This paper is relevant because multicast is an excellent way to improve
the efficiency of the Internet. If it is possible for a server to send
out one stream to all of its clients, rather that sending out one stream
per client, it is a great savings to that server. However, if the
network is wasting resources to maintain the multicast group, then the
benefit to the network is reduced. In a large network like the
Internet, one can imagine that multicast groups would be sparse. This
paper presents an effective way to multicast to a group that may be
sparse across the Internet.
This archive was generated by hypermail 2.1.6 : Wed Nov 10 2004 - 01:01:27 PST