UCL
  Personal Miscellaneous TCP/IP GRID Quality of Service Multi-Cast  
 

PIM-DM Example

Protocol Independent Multicast supports all underlying unicast routing protocols, including static, RIP, IGRP, EIGRP, IS-IS, BGP and OSPF. It uses Reverse Path Forwarding to flood the network with multicast data, then it prunes back paths based on uninterested receivers. It uses the Assert mechanism to prune off redundant flows. As such, it is appropiate for smaller implementations and pilot networks.

Flooding

PIM-DM is similar ot DVMRP in that it initially floods the network with multicast traffic to all parts of the network. However, unlike DVMRP, which pre-builds a 'Truncated Broadcast Tree' that is used for the intial flooding, PIM-DM initially floods traffic out ALL non RPF interfaces where is is either another PIM-DM neighbour our a directly connected member of the group.

The reason that PIM-DM does not use a TBT to pre-build a spanning tree for each source network is tha tthis would required running a separrate routing protocol as does DVMRP. At the very least, some sort of Poison-Reverse messages would have to be sent to build the TBT. Instead, PIM-DM uses other mechanisms to prune back the traffic flows abd build Source Trees.

In the above example, multicast traffic being send by the source is flooded throughout the entire network. As each router receives the multicast traffic via its RPF interface (the interface in the direction of the source), it forwards the multicast traffic to all its PIM-DM neighbours. This results in some traffic arriving via a non-RPF interface such as the case of the two routers in the center of hte diagram where packets arriving via the non-RPF interface are discarded. These non-RPF flows are normal for the intial flooding of data and will be corrected by the normal PIM-DM pruning mechanism.

Pruning

In the following example, pruning is denoted by the dashed arrows. PIM Prunes are send to stop the flow of unwanted traffic and are sent on the RPF interface when the router has no downstream members that need the multicast traffic.

Prunes are also sent on non-RPF interfaces to shutoff the flow of multicast traffic that is arriving via the wrong interface, that is the traffic arriving via an interface that is not in the shortest path to the source. An example of this can be seen on th esecond router from the receiver near the centre. Multicast traffic is arriving via a non-RPF interface from the router above which results in a Prune message.

The result of the pruning is shown below, multicast traffic has been pruned off all links except where it is necessary. This results in a Shortest Path Tree being built from teh Source to the Receiver.

Even though the flow of multicast traffic is no longer reaching most of the routers in the network, (S,G) state still remains in all routers in the network. This (S,G) state will remain until the source stops transmitting.

In PIM-DM, Prunes expire after 3 minutes. This causes the multicast traffic to be re-flooded to all routers just as was done in the initial flooding. This process is normal.

Assert Mechanism

The PIM Assert mechanism is used to shutoff duplicate flows onto the same multiaccess network. Routers detect this condiction when they receive an (S,G) packet via a multi-access interfcae that is in the (S,G) OIL. This causes the routers to send Assert Messages.

Assert messages contian the Administrative Distance (the high-order part of the assert value) and metric to the source combined into a single assert value. Routers compare these values to determine who has the best path (lowest value) to the source. Should both values be the same, the highest IP address is discarded.

The Losing routers (the ones with the higher value) Prunes its interface while the winning router continues to forward the multicast traffic onto the LAN segment.

Assert Problems

While the PIM Assert mechanism is effective in pruning off duplicate traffic, consider the example below where duplicate traffic is flowing into a LAN segment,

The normal PIM Assert mechanism takes place and the two routers exchange routing metrics to determine which one has the best route to the source.

In this case, the bottom router has the best metric and wins.

The normal PIM Assert mechanism takes place and the Assert Winner continues forwarding whilse the Assert Looser prunes its interface and starts it prune timer.

If we were to assume that the Assert Winner filas immediately after winning the Assert process,

Unfortunately, the Assert Looser has no way of knowing that the Assert Winner has failed and will wait 3 minutes before timing out its pruned interface. This results in the loss of traffic during this period.

Route Loops

The non-deterministic behaviour of PIM-DM along with its flood and prune mechanism can sometimes results in serious network outages including 'blackholes' an dmulticast route loops.

The example above is a simplified version of a frequently used network design whereby multiple routers are used to provide redundancy in the network. Under steady-state conditions, traffic flows from the source via the RPF interface as shown, in the diagram thr routers have performed the Assert process and one interface on the router is in the pruned state.

Assuming that the forwarding interface of the first hop router fails as shown above, and that the unicast routing of the router on the left convergest first and PIM computes the new RPF as shown. This means that the middle router has not yet concerged and is still forwarding multicast traffic using the old RPF interface.

At this point, a multicast route loop exists in the network due to the transient condition of thw two routers haveing opposite RPF interfaces. During the time this route loop exists, virtually all of the bandwidth on the network segments can be consumed. This situation will continue until the router in the middle finally converges and the new 'correct' RPF interface is calculated. Unfortunately, if the router needs some bandwidth to complete this convergence (as in the case when the EIGRP goes active) then this condition will never be resolved!

 

 

 

 

 

 

 

 

 

Wed, 23 July, 2003 13:07 Previous PageNext Page
 
 
    email me!
© 2001-2003, Yee-Ting Li, email: ytl@hep.ucl.ac.uk, Tel: +44 (0) 20 7679 1376, Fax: +44 (0) 20 7679 7145
Room D14, High Energy Particle Physics, Dept. of Physics & Astronomy, UCL, Gower St, London, WC1E 6BT