Dense mode assumes that group members are in dense pockets of the network. This is used for large distributions, such as Webcast concerts or corporate presentations, where many receivers on the same subnet or network are getting their broadcasts from the same location. Dense mode also assumes that bandwidth is high enough to handle the broadcasts. Routing protocols such as DVMRP (Distance Vector Multicast Routing Protocol), PIM-DM (Protocol Independent Multicast Dense Mode) and MOSPF (Multicast Open Shortest Path First) are used to distribute data in a dense-mode network.

DVMRP uses a flooding method of getting the multicast data to its destinations. Starting out, DVMRP routers assume that everyone on the connected subnets wants to receive the broadcasts. While this can use a large amount of bandwidth, it does accomplish its purpose. This type of spanning tree gets the information out to the "leaves" in the best and quickest fashion. Over time, as members join or leave the multicast, the routers will prune branches where no members exist, cutting down on the bandwidth being used.

DVMRP relies on the shortest path for propagation. DVMRP routers look at their regular routing tables to determine if they have the best route to the next multicast router. By comparing their routing tables, the DVMRP routers create an efficient path for all data. If a router determines via IGMP that it has no members downstream or it doesn't have the best path, it will ask to be deleted from the transmission.

DVMRP does use broadcast technology to update all the routers on the network. This can result in a lot of traffic if routers are spread apart or sending to sparsely connected members, and therefore DVMRP is good only for dense transmissions on high-bandwidth connections. DVMRP also must keep a large amount of state information about all the connections it maintains. Because a DVMRP tree is created for every group ID sent, this information can be overwhelming -- another reason DVMRP works only in dense distributions where the router can keep its connections as tightly packed as possible.

Unicast vs. Multicast Click here to enlarge

The PIM-DM routing protocol is similar to DVMRP in its overall operation, but it offers a distinct advantage over DVMRP in that it doesn't rely on any one unicast routing protocol. PIM-DM is the dense-mode version of PIM, which was created by an IETF working group to provide a standardized, scalable multicast routing protocol. It was developed to work well across the multiple backbones of the public Internet and be independent of a unicast routing protocol.

While independence from unicast sounds good, it can be problematic. PIM-DM was designed to be a simple protocol and therefore doesn't have the advantages of a more complex protocol, such as DVMRP. This is most obvious in PIM-DM's propagation of data packets. Upon a packet's arrival at a router, PIM-DM determines if it is using the shortest path back to the source. If so, then the packet is forwarded on all downstream interfaces until it reaches members, and unused branches are disconnected. This is simple in operation, but can cause increased overhead and packet duplication.

The third routing protocol used in dense-mode networks, MOSPF, extends OSPF to handle multicast traffic instead of only unicast. MOSPF routes data over the lowest-cost connection with available bandwidth, and the shortest hop count is used to determine the best path. Using this method, routes over heavily congested connections can be avoided by creating a higher cost for them.

Each MOSPF router maintains a complete view of the entire network, gathered from the link-state information that's flooded between routers. This can limit scalability, as the routers pass not only link-state information but also IGMP data on members, reducing the bandwidth available for transmission in networks with many group members. As the multicast tree is created, each MOSPF router performs calculations to determine the best path for a packet. However, this is done only once for each group ID, which keeps overhead down. As the packet traverses the network, each router performs the same calculations and creates the final tree for the members.

MOSPF is also limited by its reliance on OSPF domains to route traffic. MOSPF can't get away from the unicast portion of OSPF, which limits transmission to members on a network owned by one organization. Thus, MOSPF doesn't lend itself well to the multi-owner-backbone nature of the public Internet, but it could be easily deployed within an enterprise's network.

Sparse Mode

Sparse mode might sound as if it's designed for desert multicast sessions, but its purpose is to find efficient means of getting data to many people spread over wide areas. While dense mode assumes there are group members in every corner of the network, sparse mode realizes that for specialized transmissions, members are in small pockets, or clusters, of the network. It's unnecessary for data to be transmitted to every corner of the network when the data needs to reach only a few areas, or areas spread out over long distances. Sparse-mode protocols also are designed to work well over congested connections (for example, in trying to reach a few users scattered across the Internet) and lower-bandwidth connections (such as a low-bandwidth corporate WAN).

Dense Mode vs. Sparse Mode Click here to enlarge

Two sparse-mode protocols exist: CBT (Core-Based Trees) and PIM-SM (Protocol Independent Multicast Sparse Mode). Both build routing trees by requiring the routers to participate in creating the tree. Sparse-mode routers effectively ask to join a multicast session when a downstream member requests admission.

While dense-mode routers create different trees for each multicast group, CBT simplifies the approach by creating one tree that's used by all groups. CBT employs a tree structure based on a core router from which all data flows, regardless of the source. This is advantageous in that the link-state information is lessened because all groups use the same tree. Conversely, the core router becomes overloaded as more members join. Using multiple core routers is an option, but this solution has not yet been widely adopted.

To join a multicast over CBT, a group member sends an IGMP packet upstream to the first multicast router. That router will in turn begin sending the session to the member if it's already receiving the session. Otherwise, the router will send a request upstream toward the core router until it gets to the core or a router that's already receiving the session. The member's router is then added to the distribution, and the member can receive the data.

PIM-SM is similar to CBT in topology, but it's more flexible. Instead of a core router, PIM-SM uses an RP (rendezvous point), where downstream routers "gather." This lets PIM-SM create a shared tree, or one based on the shortest path. Thus, each group can have a different tree structure based on what works best. CBT keeps the amount of link-state information down but may not provide the best path to a member. If low latency is needed, PIM-SM can create better paths.

PIM-SM starts out in a shared-tree manner, but after routers have joined, they may opt to create a link via a shorter path. A message is sent to the RP to join. The new connection is created and the old path disconnected, thus yielding better latency by sacrificing a larger link-state table. Large group lists are accommodated by letting more than one RP handle traffic -- load-balancing the transmission from the source to the destination member.

Because PIM is a standardized protocol, interoperation between PIM-DM and PIM-SM makes sense. This would enable dense and sparse areas to be accommodated, and the same session transmitted to both. To do this, border routers would be used to let the PIM-DM network request a "join" from the PIM-SM network. In such a solution, a network using another dense-mode protocol--DVMRP, for example -- could connect to a PIM-SM network in the same way a PIM-DM would, resulting in interoperability.

Although it may loom in your imagination like a large floating head bellowing impossible orders, multicast technology is really very workable if you pull all the right levers.