From: Rosalia Tungaraza (rltungar@u.washington.edu)
Date: Tue Nov 09 2004 - 22:03:30 PST
This paper is about Protocol Independent Multicast (PIM), which is a
multicast routing protocol such as the link-state, distance-vector and
reverse-path broadcast. The major difference between PIM and the other
ones is that PIM is capable of scaling well in a network were there are
sparse routers that are willing to send multicast packages to certain
groups. This protocol is also independent of any existing unicast routing
protocol. Moreover, it is robust, allows high-quality data distribution,
and is easily interoperable. The latter three points could arguably also
be applied to the other multicast protocols.
In general, I think PIM should work much better in regions were there are
sparse group members compared to other multicast protocols such as
link-state multicast, distance-vector multicast or reverse-path broadcast
in terms of optimizing resource utilization (avoid waste as well). Along
the same lines, the fact that PIM can operate in both "sparse-Mode" and
"dense-Mode" enables it perform equally well compared to the other
protocols when in a region where there are many group members for a given
multicast group. Basically, I wouldn't mind replacing any of the other
protocols with PIM and thus attribute this point as one of the successes
of this protocol and paper.
Thus said, I think there is a little point that the authors could improve
upon: at any given point in time there is one machine within a given
multicast group that acts as the rendezveou point (RP). This makes such a
network quite vulnerable to malfunctioning. If anything happens to the RP
such that it either is down for some time or just can't function well, all
machines (hosts) depending on that RP will miss multicasted packages for
some time. I think the authors should have explained in more detail how
such a situation is accounted for within the protocol (or routers).
As suggested in the paper, one possible path to take in future work is to
explore how efficiently alternative path routing at a time when
reservation requests are denied because there are not enough resources
along the route that was considered by the unicast routing protocol to be
the best.
This archive was generated by hypermail 2.1.6 : Tue Nov 09 2004 - 22:03:36 PST