I-D: add new PIM-DM Section

--=-4aXMEELQjYuVgnYdCoW2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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

--=-4aXMEELQjYuVgnYdCoW2
Content-Disposition: attachment; filename=udlr-experiments-pim-dm.txt
Content-Type: text/plain; name=udlr-experiments-pim-dm.txt; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

--=-4aXMEELQjYuVgnYdCoW2--