Source Based Trees Versus Shared Trees

Some multicast routing protocols construct separate multicast trees for every multicast source These trees are source-based trees, because they are rooted at the source The multicast trees that have been presented in previous sections have been source-based trees

You have learned that multicast trees can change during the lifetime of a multicast session as members join and leave the group, and that it is the responsibility of the multicast routing protocol to dynamically adapt the tree to these changes However, some parts of the tree might not change Figure 5-21 shows two multicast trees superimposed onto the same internetwork Notice that although the trees have different sources and different members, their paths pass through at least one common router

Shared trees take advantage of the fact that many multicast trees can share a single router within the network Rather than root each tree at its source, the tree is rooted at a shared router called (depending on the protocol) the rendezvous point (RP) or core The RP is predetermined and strategically located in the internetwork When a source begins a multicast session, it registers with the RP It may be up to the source's directly connected router to determine the shortest path to the RP, or it may be up to the RP to find the shortest path to each source Explicit joins are used to build trees from routers with attached group members to the RP Rather than the (S, G) pair recorded for source-based trees, the shared trees use a (*, G) state This state reflects that fact that the RP is the root of the tree to the group and that there may be many sources upstream of the RP More importantly, a separate (S, G) pair must be recorded for each distinct source on a source-based tree Shared trees, on the other hand, record only a single (*, G) for each group

Figure 5-21 These Two Multicast Trees Have Different Shapes, but They Both Pass Through the Single Router RP

Figure 5-21 These Two Multicast Trees Have Different Shapes, but They Both Pass Through the Single Router RP

The impact of the (S, G) entries can be demonstrated with a few simple calculations Suppose in some source-tree, flood-and-prune multicast domain, there are 200 multicast groups and an average of 30 sources per group Each router must record 30 (S, G) entries for each group, or 30 * 200 = 6000 entries If there are 150 sources in each of the 200 groups, the entries increase to 150 * 200 = 30,000

NOTE Keep in mind that with interactive multicast applications, many group members (receivers)

are also sources (senders)

In contrast, shared tree routers record a single (*, G) entry for each group So if there are 200 groups in a shared-tree multicast domain, the RP records 200 (*, G) entries Most significantly, this number does not vary with the number of sources Another way of stating these facts is that source-based trees scale on an order of (SG * GN), and shared trees scale on an order of (GN), where GN is the number of groups in the multicast domain and SG is the number of sources per group Impact is greatly reduced on non-RP routers also, because they do not keep state for groups for which they do not forward packets These routers record a single (*, G) entry for each active downstream group

This scalability means that shared trees are generally preferable in sparse topologies As usual, however, there are trade-offs First, the path from the source through the RP may not be the optimum path to every group member for every group Reexamining Figure 5-21, notice that a member of group 2 is attached to router R5 The optimal path from the source S2 to this group member is R2-R1-R5 But the source traffic must reach the RP first, so the path taken is R2-R3-RP-R4-R5 RPs must be chosen carefully to minimize suboptimal paths Another drawback is that the RP can become a bottleneck when there are multiple high-bandwidth multicast sessions Because of both suboptimal paths and RP congestion, latency can become a problem in poorly designed shared tree internetworks The RP also represents a single point of failure Finally, shared trees can be difficult to debug

Table 5-5 shows which multicast routing protocols use source-based trees and which use shared trees Comparing this table with Table 5-4, you can see that although MOSPF uses explicit joins, it also uses source-based trees The converse situation is never true—a protocol using shared trees must always use explicit joins, because it has no other way to maintain loop-free trees

Table 5-5 Source-Based Tree and Shared Tree Protocols


Source-Based Trees

Shared Trees











100 SEO Tips

100 SEO Tips

100 SEO Tips EVERY SEO Enthusiast Should Know. This Report 100 SEO Tips will help you to Utilize These Tips to Dominate The Search Engine Today.

Get My Free Ebook

Post a comment