I-D: add new PIM-DM Section
Emmanuel Lety <Emmanuel.Lety <at> UDcast.com>
2003-08-25 14:19:18 GMT
Hi All,
I just wrote and committed Section 4.4.2 Dense Mode PIM-DM
You can now get the new version of draft-ietf-udlr-experiments
from the CVS repository.
Thanks,
Emmanuel.
--
UDcast: Full IP over Broadcast Media http://www.UDcast.com
Phone: (+33) (0)4 93 00 16 69, Fax : (+33) (0)4 93 00 16 61
2455, Route des Dolines, BP 355, F-06906 Sophia Antipolis, France
4.4.2 Dense Mode PIM (PIM-DM)
4.4.2.1 Topology
In order to study the advantages and limitations of a PIM-DM
deployment in a UDLR context, we focus here on a typical Multicast
Intranet topology. One feed and many receivers are connected via a
unidirectional link, all running the PIM-DM multicast routing
protocol. In this context, the feeds' and receivers' bi-directional
interfaces do not need to be multicast enabled. Typical applications
for such an infrastructure could be e-learning applications, video-
conferencing tools, large-scale virtual environments, or reliable
multicast files transfer, where both data and control multicast
traffic could be generated by any end-host on any attached subnet.
Unidirectional Link
----------------->----------------->------------------->---------
| | |
|fu |r1u |r2u
-------- ------- -------- ------- -------- -------
|Feed |--|subnet0| |Recv1 |--|subnet1| |Recv2 |--|subnet2|
|PIM-DM| -------- |PIM-DM| ------- |PIM-DM| -------
-------- -------- --------
|fb (multicast |r1b (multicast |r2b (multicast
| disabled) | disabled) | disabled)
-----------------------------------------------------------------
| Internet
-----------------------------------------------------------------
Figure 1 : Typical UDLR - Multicast Intranet Topology
As described in [DRAFT-PIM-DM-NEW], PIM-DM uses the Multicast Routing
Information Base (MRIB) derived from the unicast routing table, to
make decisions regarding Reverse Path Forwarding (RPF) interfaces and
neighbors. All the nodes (feed and receivers) in Figure 1 implement
the UDLR protocol, which implies that any PIM-DM node can reach any
other PIM-DM node as if they were all PIM-DM neighbors, connected to
the same ethernet LAN. Thus, for Recv1 the RPF neighbor toward
subnet2 is Recv2, and NOT the Feed, which is only the RPF neighbor
toward subnet0.
4.4.2.2 Advantages
PIM-DM has several advantages compared to other multicast routing
protocols :
1. It scales much better than DVMRP, as it does not need to carry the
complete neighbor list for each Hello/Probe messages and to run its
own specific topology discovery protocol.
2. Even if PIM-DM is part of the flood-and-prune multicast protocol
family, PIM-DM uses state-refresh messages which minimize periodic
flooding of data to maintain state for a given (S,G) entry.
3. PIM-DM has a simplified design compared to PIM-SM, without any
Rendez-Point selection, Shortest-Path Tree switching, Register-
encapsulation/Native Forwarding switching, MSDP interaction, etc.
This simplified design could be a significant advantage in order to
adapt the protocol to the specific constraints of a unidirectional
link.
4. Unlike IGMP-Proxy - which is not a multicast routing protocol -
PIM-DM prevents the permanent flooding on the unidirectional link of
downstream sources located on the attached subnets of UDLR receivers.
4.4.2.3 Limitations
The deployment of PIM-DM on unidirectional links raises several
issues, due to two main reasons :
- the number of PIM-DM receivers, i.e. PIM-DM neighbors, could be
very large.
- the round trip delay could be much more important than an ethernet
LAN, especially between two PIM-DM receivers (twice the delay between
a receiver and the feed).
Among these issues, we detail the following :
1. Prune and Join
2. Unicast Graft/Graft-ack
3. Reverse Path Forwarding
4. Assert Election
Prune and Join
For a given attached network, as soon as the last member of a
multicast group sends an IGMP-v2 Leave message, its connected PIM-DM
receiver has to prune explicitly each upstream PIM-DM router for
every existing (Si,G) entry. Indeed, [DRAFT-PIM-DM-NEW] specifies
that PIM-DM routers MUST set the Upstream Neighbor Address field to
the RPF next hop. Moreover, each Prune sent on the UDL can generate
one or several overriding PIM-DM Joins, if other PIM-DM receivers are
in forwarding mode for these (Si,G) entries. In the case of large
round trip times on the UDL, the number of overriding Joins can also
aggravate a potential Prune storm happening at the end of a multicast
session (where 90% of the session members un-subscribe in a short
time interval).
Note that a PIM-DM Prune message storm may not only waste bandwidth
on the unidirectional link, but also may create congestion at the
feed where all the UDLR GRE return channels converge. In addition,
congestion at the feed will increase the probability of losses in
PIM-DM Join, which again may lead to a PIM-DM Join message storm.
Unicast Graft/Graft-ack
For a given attached network, as soon as the first member of a
Multicast Group sends a IGMP-v2 Report message, its connected PIM-DM
receiver has to graft explicitly each upstream routers for every
(Si,G) entry, even if the traffic is already flooding on the UDL.
Unlike PIM-DM multicast Join messages that are cancelled by other
PIM-DM Join messages, a PIM-DM unicast Graft will not be canceled by
another Graft sent for the same (S,G) entry. Thus, simultaneous
Graft/Graft-Ack message increase again the probability of a PIM-DM
message storm.
Reverse Path Forwarding
Each receiver needs to have an up-to-date unicast routing table, that
allows it to reach in unicast any source on any attached network.
Indeed, in order to get the right RPF neighbor toward any source,
PIM-DM assumes that this information is already available. However,
in a UDLR context, UDLR receivers may have a simplified unicast table
where the default unicast gateway is the Feed Unidirectional
Interface (FUIP). In this case, a PIM-DM receiver will never be
pruned by another PIM-DM receiver, as the upstream neighbor field of
the PIM-DM Prune message will always be set to the FUIP. Moreover,
maintaining all the unicast routing tables up-to-date on every UDLR
receivers has a potentially significant cost (memory occupation,
messages exchanges, etc..) as the number of PIM-DM receivers starts
to be large.
Assert Election
Unlike PIM Hello messages where a PIM-DM router answers to a new
Hello message after a random delay, there is no timer before sending
a PIM-DM Assert in reply to an inferior Assert [DRAFT-PIM-DM-NEW],
i.e. an Assert with a higher value of metric_preference. Once again,
PIM-DM needs to be adapted in order to scale with the number of PIM-
DM neighbors on a UDL.
4.4.2.4 Security issues
Among the different attacks based on forged PIM-DM messages, an
attack based on forged Assert messages could result in dramatic
effects. Fortunately, forged Hello/Prune/Join messages will have a
less significant impact on a multi-access LAN with a large number of
PIM-neighbors, since any legitimate PIM neighbor will Prune/Join a
forged Join/Prune message.
We distinguish two kinds of attacks based on PIM-DM Assert :
1. Forged Inferior Assert (using very high value of metric_preference
and route_metric) could generate a PIM-DM Assert storm on the
unidirectional link (See Section 4.4.2.3).
2. Forged Preferred Assert (using very low value of metric_preference
and route_metric) could cause the legitimate forwarder to stop
forwarding traffic on the unidirectional link.
4.4.2.5 Conclusion
It appears that the deployment of PIM-DM on such an infrastructure
may suffer from both scalability and security issues. However, the
simplified design of this multicast protocol and the list of
advantages listed in Section 4.4.2.2 still make it an ideal candidate
for a specific adaptation to support unidirectional links. Over the
unidirectional link the protocol could be adapted to take into
account the remarks presented in this Section, whilst remaining fully
compliant with a PIM-DM classical implementation over terrestrial
links.
RSS Feed