Implicit Joins Versus Explicit Joins
As was previously observed, members may join or leave a group at any time during the lifetime of a multicast session, and as a result, the multicast tree can change dynamically It is the job of the multicast routing protocol to manage this changing tree, adding branches as members join and pruning branches as members leave
The multicast routing protocol may accomplish this task by using either an implicit or explicit join strategy Implicit joins are sender-initiated, whereas explicit joins are receiver-initiated
Multicast routing protocols that maintain their trees by implicit joins are commonly called broadcast-and-prune or flood-and-prune protocols When a sender first initiates a session, each router in the internetwork uses reverse path broadcasting to forward the packets out every interface except the upstream interface As a result, the multicast session initially reaches every router in the internetwork When a router receives the multicast traffic, it uses IGMP to determine whether there are any group members on its directly connected subnets If there are not, and there are no downstream routers to which the traffic must be forwarded, the router sends a poison-reverse message called a prune message to its upstream neighbor That upstream neighbor then stops forwarding the session traffic to the pruned router If the neighbor also has no group members on its subnets, and all downstream routers have pruned themselves from the tree, that router also sends a prune message upstream The result is that the multicast tree is eventually pruned of all branches that do not lead to routers with attached group members Figure 5-20 illustrates the broadcast-and-prune technique
Figure 5-20 Broadcast-and-Prune Protocols First Use RPB to Forward a Multicast Session to All Parts of the Internetwork (a) Routers with No Connection to Group Members Then Prune Themselves from the Tree (b) so That the Resulting Tree Only Reaches Routers with Group Members (c)
Figure 5-20 Broadcast-and-Prune Protocols First Use RPB to Forward a Multicast Session to All Parts of the Internetwork (a) Routers with No Connection to Group Members Then Prune Themselves from the Tree (b) so That the Resulting Tree Only Reaches Routers with Group Members (c)
For every (S, G) pair in its forwarding table, every router in the internetwork maintains state for each of its downstream interfaces The state is either forward or prune The prune state has a timer associated with it, and when the timer expires, the session traffic is again forwarded to neighbors on that interface Each neighbor once again checks for group members and floods the traffic to its own downstream neighbors If new group members are discovered, the traffic continues to be accepted Otherwise, a new prune message is sent upstream
The broadcast-and-prune technique is better suited to dense topologies than to sparse ones The initial flooding to all routers, the periodic reflooding as prune states expire, and the maintenance of prune states all contribute to a waste of network resources when many or most branches are pruned There is also a strong element of illogic in the maintenance of prune state, requiring routers that are not participating in the multicast tree to remember that they are not a part of the tree
A better technique for sparse topologies is the explicit join, in which the routers with directly attached group members initiate the join When a group member signals its router, via IGMP, that it wants to join a group, the router sends a message upstream toward the source, indicating the join In contrast to a prune message, this message can be thought of as a graft message, the router sending the message is grafting itself onto the tree If all of a router's group members leave, and the router has no downstream neighbors active on the group, the router prunes itself from the tree
Because traffic is never forwarded to any router that does not explicitly request the traffic, network resources are conserved And because prune state is not kept by nonparticipating routers, overall memory is conserved As a result, explicit joins scale better in sparse topologies The argument can be made, of course, that explicit joins always scale better, regardless of whether the topology is sparse or dense Table 5-4 shows which of the five multicast routing protocols use implicit joins and which use explicit joins
Table 5-4 Implicit Join and Explicit Join Protocols
|
Protocol |
Implicit Join |
Explicit Join |
|
DVMRP |
X |
|
|
MOSPF |
X |
|
|
PIM-DM |
X |
|
|
PIM-SM |
X |
|
|
CBT |
X |
Continue reading here: Operation of the Distance Vector Multicast Routing Protocol DVMRP
Was this article helpful?