Computer Communications 22 (1999) 144155

A comparison of the Internet multicast routing protocols

Jhyda Lin a, Ruay-Shiung Chang b,*
b

Department of Information Management, National Taiwan University of Science and Technology, Taipei, Taiwan Department of Computer Science and Information Engineering, National Dong Hwa University, Hualien 974, Taiwan Received 21 November 1997; received in revised form 5 August 1998; accepted 10 August 1998

Abstract The exploding Internet has brought many novel network applications. These include teleconferencing, interactive games, the voice/video phone, real-time multimedia playing, distributed computing, web casting, and so on. One of the specic characteristics of these applications is that all involve interactions among multiple members in a single session. Unlike the traditional one-to-one message transmission (unicasting), if the underlying networks provide no suitable protocol supports, these applications may be costly and infeasible to implement. Multicasting is one technique proposed to efciently distribute datagrams to a set of interested group members on the interconnected networks. In this article, we survey the multicast routing protocols on the Internet today. Four well-known multicast routing protocols, Distance Vector Multicast Routing Protocol (DVMRP), Multicast extensions to OSPF (MOSPF), Core Based Tree multicast routing protocol (CBT), and Protocol Independent Multicast routing protocol (PIM), are introduced. Different protocols have different design concepts and use different techniques to delivery datagrams and each has its special functions and properties. We provide a succinct explanation of their features. The advantages and weaknesses of these Internet protocols are also examined and compared in detail by several protocol characteristics. 1999 Elsevier Science B.V. All rights reserved. Keywords: Multicasting routing protocols; Delivery tree; Datagrams

1. Introduction From the Internet, corporate Intranet, to various on-line information services, we have seen and are witnessing a series of unprecedented innovative applications. These applications include video conferencing, distance learning, shared collaborative computing, and so on. The requirements of these applications highlight several strategic research and development directions for networks in the future. One of them is to provide a new interactive service architecture to facilitate the highly distributed sets of cooperating applications. Unlike most of the successful applications in use today, they involve the interactions among multiple members in a single session. For example, the images and voices of the lecturer in distance learning must be transmitted to multiple destinations at the same time on demand. These real-time member interactions need supports from the underlying networks. That is, the network protocol layers must be able to perform an important function called multicasting.
This research is supported in part by ROC NSC under contracts NSC87-2213-E011-013 and NSC87-2622-E007-002. * Corresponding author. Tel.: 886 3 8662500 Ext. 1 831; Fax: 886 3 8662781; e-mail: rschang@csie.ndhu.edu.tw

Multicasting [5,6] refers to transmit a single data packet to a set of receivers that are members of a multicast group. Different from one-to-one unicasting and one-to-all broadcasting, multicasting is considered as the more generalized concept: many-to-many. That is, the number of group members varies from zero to all. They may spread across a large network. At any time, each of them is allowed to join and leave the group dynamically. Individual network node can also be a member to different groups at the same time. Consequently, for such situations, multicasting manages the multiple members with a unique group address. Datagrams designated to the specic group address will be distributed to all members of that group. To avoid consuming bandwidth by forwarding datagrams repeatedly on unicasting basis or causing heavy trafc by broadcasting, it takes advantage of the spanning tree concept to force the network to replicate datagrams only when necessary at branches. Multicasting offers a better improvement of the network load and resource usage in comparison with traditional delivering. In this article, we discuss and compare four well-known multicast routing protocols on the Internet today. First, Section 2 explains what multicasting is about. Section 3 gives an overview of the current Internet protocols:

0140-3664/99/$ - see front matter 1999 Elsevier Science B.V. All rights reserved. PII: S0140-366 4(98)00236-9

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

145

DVMRP (Distance Vector Multicast Routing Protocol) [7,18], MOSPF (Multicast extensions to OSPF) [15,16], CBT (Core Based Tree multicast routing protocol) [13], and PIM (Protocol Independent Multicast routing protocol) [810]. Then, in Section 4, we examine these protocols in detail and evaluate them with respect to a number of criteria. Finally, Section 5 presents a summary of these protocols and a conclusion of our discussion. 2. Multicasting Multicasting on the local subnetworks is easily supported. For example, in Ethernet or most shared media, a host can simply deliver a multicast data packet to any directly connected hosts by mapping the group address to reserved portions of the IEEE-802 MAC-layer multicast address space. So, the remaining task is how to manage the mappings between group addresses and specic memberships. The well-known Internet Group Management Protocol (IGMP) [4,13] is one of such mechanisms. IGMP operates between hosts and multicast routers belonging to the same subnetwork. It allows a host to inform its multicast router what group it wishes to participate. By monitoring the group membership presence on its directly attached links, the multicast router knows how to send a copy of the multicast data packets to the appropriate links. However, IGMP only handles the membership management on one directly-attached subnetwork. This capability limits the forwarding of multicast trafc from a router to group members on the specic local subnetwork. For multicasting to extend beyond the scope of the local subnetwork, a multicast routing protocol must rst construct multicast delivery trees. It then has to keep track of the group memberships on the network, maintain the delivery trees for dynamic group changes, and forward multicast datagrams to the target destination across the internetworks. Therefore, we can examine a multicast routing protocol from the following perspectives. 1. Neighbor discovery: There are many different types of routers in the Internet. Not all routers have the same capability. Some of them support multicast routing, and others do not. In addition, a particular router with the capability of multicast might not support some specic multicast protocols with others. Consequently, passing a multicast datagram to multicast ignorant routers will cause that datagram to be ignored and discarded. Providing a mechanism for multicast routers to be able to discover neighbors with the same multicast capability is necessary on internetwork multicasting. Based on this information about neighbor distributions, the multicast control messages can then concentrate on specic routers to exchange the group membership information and to build the multicast tree. 2. Group membership maintenance: When a host wants to join or leave a group, a specic message should be sent to

inform multicast routers in the network. Later on, multicast routers can know how to forward the multicast datagrams by keeping track of these group memberships. IGMP supports the basic maintenance for group membership for the directly-attached networks. Each multicast router periodically sends IGMP Host Membership Queries on that subnetwork. Hosts then respond with IGMP Host Membership Reports for multicast groups to which they belong. A local group database is then maintained by each router to indicate that their attached network has one or more hosts belonging to some multicast group. However, in order to enable multicast across internetworks, this information should be distributed to inform other routers to help them decide which multicast datagrams need to be forwarded over which subnetworks. 3. Multicast delivery tree maintenance: For multicasting, to deliver multicast datagrams to specic members of the target group is equivalent to construct a multicast delivery tree to span those members. There are many different techniques proposed to establish the multicast trees. Two classic types of trees are widely used in todays multicasting protocols. They are source-based tree and shared tree schemes. The shared tree schemes might cause the trafc concentration. The source-based tree schemes could easily build a shortest path delivery tree to minimize the delay. However, the shared tree schemes make a better utilization of resources than the sourcebased ones. Further, the maintenance of multicast tree must also be considered together with the building of multicast tree. It involves how to prune and graft the branches from and to an existing tree for dynamic changes of group memberships. In addition, fault tolerance must also be taken into account for different designs. These three characteristics are basics for multicast routing protocols. But, there are many other topics that might be considered for a multicast routing protocol, for example, the interoperability problem. In order to communicate with other multicast routing protocols, the interoperability capability must be an integral part of a multicast routing protocol. Other issues such as management and security are also important. Based on these discussions, we will introduce current Internet multicasting protocols and use these characteristics to examine each of them for highlighting each protocols special features in the next two sections. 3. Multicasting in Internet: overview Deerings work [6] in the late 1980s is considered as a pioneer in this topic. He dened a service model for multicasting and devised the related algorithms. After several years of studying and practical experience with multicasting, there are four mainstream multicasting protocols in the Internet today: Distance Vector Multicast Routing Protocol

146

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

Fig. 1. The basic concept of the DVMRP operations.

(DVMRP) [7,18], Multicast extensions to OSPF (MOSPF) [15,16], Core-Based Tree (CBT) [13], and Protocol-Independent Multicast (PIM) [810]. Note that PIM actually consists of two protocols: PIM Sparse Mode (PIM-SM) and PIM Dense Mode (PIM-DM). This denition is because of the objective of the Inter-Domain Multicast Routing(IDMR) working group for the PIM. They hope to develop one or possibly more than one standard track multicast routing protocol that can provide scalable multicast routing across the Internet. So, in addiction to the PIM-SM driven by the need to provide scaleable spare-mode multicasting across internetworks, the IDMR also denes a Dense-Mode to operate in environments where members are densely packed and bandwidth is ample. As the PIM-DM is similar to the DVMRP with several minor differences, we discuss the PIM-SM in this section only. The word PIM used in this article is referred to PIM-SM excepting when explicitly stated. Different protocols use different techniques to construct the multicast delivery trees and each of them has its special functions and properties. However, based on the concepts behind them, we can classify the multicast routing protocols into three categories by considering the way multicast routing trees are built. In the following paragraphs, we will discuss the tree building mechanisms rst. A simplied example is also used to explain the operation of these mechanisms and highlight their basic concepts. The exact and detailed operations of each protocol can be found in their related RFCs.

3.1. Multicast protocols with source-based tree technology Source-based tree multicasting means multicast delivery trees are built from each active source (sender) to its current members (receivers). That is, for each node participating in multiple groups and acting as a sender for many groups, a separate multicast tree rooted at this node would be built to span every group member. If a group has many senders, there are many multicast trees existing to cover all the members of the group and each tree is rooted at each source

respectively. Both DVMRP and MOSPF are examples of the source-based tree multicast routing protocols. DVMRP uses a broadcast and prune technique to construct the forwarding tree for delivering multicast datagrams. When a multicast datagram arrives at an interface of a DVMRP router, the reverse interfaces to the incoming one of that datagram are used as downstream interfaces to forward the datagrams initially. If the downstream router has no membership registered, it then sends back a prune message to avoid unnecessary packets forwarding. The trees are calculated and updated dynamically to track the memberships of individual group. Fig. 1 illustrates the basic concept about the DVMRP operations. In Fig. 1, the rectangles represent the host. The circles represent the DVMRP routers. Assuming that a host X acts as a source in the multicast session and X wants to send a multicast datagram to the group members (Hosts Y and Z). Initially, it would send the datagram with the multicast address of the target group to the connected LAN. Upon receiving the multicast datagram, designated router A would check the multicast routing table for the target group. There is unfortunately, no information for the target group in router A. The default action of the designated router A is to forward it to all connected links except the incoming one (similar to broadcasting). Owing to the absence of group information, other routers would also initially forward the datagram to its outgoing interfaces as router A does. However, for leaf routers that have no group members in its downstream such as router C and router H, they would send an explicit prune message upstream to avoid unnecessary datagrams forwarding. At the end, the forwarding paths that are not pruned form the multicast delivery tree from the source to all the group members. Another protocol, MOSPF, is designed to enhance the Open Shortest Path First (OSPF) [9] routing protocol for routing IP multicast datagrams. Similar to OSPF, MOSPF uses the OSPF link-state mechanism to advertise the local states to the whole network periodically. Each router collects this state information, and maintains a link-state database to memorize current group memberships and topology reachability of the network. Then, upon receiving

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

147

Fig. 2. A simple sample for MOSPF conguration.

a multicast datagram, the forwarding delivery tree could be calculated according to that database. MOSPF Routers located on the delivery tree would then forward the multicast datagrams based on the calculation. This procedure is repeated hop by hop until all group members are reached. Fig. 2 and Fig. 3 provide an example to illustrate the operations of the MOSPF. This gure is abstracted from the MOSPF specication [15]. H represents host and RT represents routers. The label, M.a, represents a host that has joined the group A. M.b has the same meanings but for a different group B. A cost is assigned to each outbound router interface. The lower-right table is an example of the information of network topology and member distributions hold by each MOSPF routers link-state database. For example, the rst line of the table denotes the following facts: (a) there are two links incident to Router-1, (b) a 1-unit cost link exists between the Router-1 and Network-3, (c) a 3-unit cost

link exists between Router-1 and Network-1, and (d) on the directly-connected LANs of Router-1, there is a host that has joined group B. In Fig. 3, assume H.3 sends a multicast datagram to group A. Before forwarding that datagram, the designated router Router-3 would execute a Dijkstra-like algorithm to compute a shortest spanning tree based on the link-state database. The built tree is rooted at the source router (Router-3) and covers all group members of the group A. According to its location on the delivery tree Router3 then forwards that datagram into Network-3 toward Router-2 and Router-4. Upon receiving the datagram, Router-2 and Router-3 would individually compute the multicast delivery tree that spans to all the group members. As these calculations are based on the same database, the resulting trees are identical. Thus, according to the location on the tree, Router-2 forwards the

Fig. 3. The operations of the MOSPF.

148

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

Fig. 4. The operations of the CBT protocols: there are no members in the CBT system.

datagram to its connected LAN (Network-2) and Router-4 delivers it to Network-6 for M.a. 3.2. Multicast protocols with shared tree technology For the source-based tree multicast routing protocols, a distinct delivery tree is built per active source. The complexity of source-based tree protocols is O(S*G), where S is the number of sources and G is the number of groups. It might not scale well in the case of wide-area multicasting, which potentially has to support many thousands of active groups, each of which may be sparsely distributed. Theoretically, using a single group-shared tree to span members is the optimal solution to minimize the band width usage. However, nding this optimal tree for a set of nodes in a graph is known as the minimal Steiner tree problem in graph theory. It has been proved to be an NPComplete problem [14]. A simpler approach to constructing a group-shared tree was proposed by Wall [19] using a center-specic tree scheme. In this approach, a single node is designated to be the center of a shared tree. It is responsible for expanding the tree when a new source/member joins the multicast session, and it is also responsible for collecting trafc from all sources and multicasting it to all receivers. That is, the group-shared tree is the shortest-path tree rooted at

that node. The advantages of a center-specic tree over a minimal Steiner tree thus include simpler implementation and bounded delay. Estrin and Wei [11] also show that in terms of the total bandwidth usage, center-specic trees lie somewhere between the minimal Steiner tree and sourcespecic tree. Core-Based Tree (CBT) multicast routing protocol is an example of the methods to reduce the bandwidth usage. Different from DVMRP and MOSPF, it constructs a single multicast tree (core-based tree) per group. In CBT, each local router invokes a tree joining process to the groups core router when receiving an IGMP join message. Then, a shared tree rooted at the groups core router is built for all of the groups receivers. The core router is selected by a manual conguration or some special protocol [8], and acts as a junction for the groups multicast trafc. Datagrams from the source will travel to the core rst, and then will be distributed along the other branches to the groups receivers indirectly from the core via the shared tree constructed. As an example of multicast datagram routing in CBT, consider the sample network system shown in Figs. 46. Fig. 4 illustrates the basic concept about the CBT when there are no group members in a system. Assume router E is selected to be the core for group S by manual conguration in this example and the four hosts do not join any group. If host X wants to send a datagram to group S, it can only

Fig. 5. The operations of the CBT protocols: some hosts join Group S.

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

149

Fig. 6. The operations of the CBT protocols: Host X sends a datagram to Group S.

send that datagram to the core, router E. This is because there is no mechanisms designed to distribute group membership information in CBT. The next-hop router, A, has no group information about the group S. Therefore, the default action is to forward that datagram to the core. As no one has joined group S yet, router E would discard the received datagrams. In Fig. 5, assume host Y and host Z want to join group S. Host Y would send an IGMP membership report to announce that it wishes to receive trafc addressed to the multicast group S. Upon receipt of this IGMP report, the next-hop router F will issue a Join-Request message to the groups core router E. This request message travels a specic path along the way towards the core. The next-hop router B for host Z would try to build such a path towards the core, too. Then, a multicast delivery tree rooted at the core router can be constructed successfully to cover all the group members. However, when some hosts join group S, the groups core router would keep the group membership information. If host X tries to send a multicast datagram to group S again, the datagram would again be sent to core router E. As the core router has information for the group S now, it would forward the datagram along the constructed multicast delivery tree to all group members of group S. Fig. 6 shows this scenario. If host W also wants to send a datagram to the group S, it would also send the datagram to the core rst. 3.3. Multicast protocols with mixed approaches As mentioned, CBT proposes the use of one single multicast tree per multicast session. All sources transmitting to that multicast session distribute their trafc over that tree. The use of shared tree is motivated by the fact that less overhead is required to construct and administer one shared tree per multicast session than to construct and maintain a source-specic multicast tree for every source transmitting to that session. For example, when a new source joins an already existing multicast session, it does not have to construct an entire source-specic tree that spans all members of that session. It merely has to nd a path to

connect itself to the existing shared tree. As a result, a source node does not have to keep an explicit list of the members of the multicast session it is transmitting to. Similarly, when a new member joins an already existing multicast session, it does not have to join the source-specic trees of all sources transmitting to that session. It simply has to nd a path to connect itself to the existing shared tree. There is no need to keep an explicit list of the sources of a multicast session at each member node. Eliminating the need for explicit source lists or explicit member lists results in good scalability for the shared multicast tree. CBT, consequently, eliminates the source (S) factor in the complexity. As all sources of a group use the same shared tree to deliver datagrams, a shared tree scheme has complexity O(G). This implies that application with many active senders, such as interactive conferencing and distributed videogaming applications, would have signicantly less impacts on network resources. However, for the shared tree architecture, there are still some problems to be solved. One of them is that the delay of packet delivery might not be minimal. That is, all datagrams are delivered to the core router rst and then distributed to group members in turn. The shared tree approach might also result in the trafc concentration and bottlenecks on the shared links near the core router. It is evident that both tree types have their advantages and disadvantages. One type of tree may perform very well under on certain of conditions, while the other type may be better in other situations. Therefore, PIM is proposed to possess the advantages of both types of methods. It allows applications to choose between shortest-path trees and a group-shared tree. In PIM, the default operations for the group member joining and datagrams forwarding is identical to CBT. Each host sends IGMP_JOIN message to announce its participation for the particular group. Its designated router records this membership and issues an additional Join-Request to the rendezvous point (RP) 1 for constructing a path between the RP and itself. A shared
1 The term, rendezvous point, in PIM is equivalent to the core in CBT. Both refer to the router that acts as a hinge node or meeting point between a sender and group members.

150

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

multicast delivery tree is then constructed to forward multicast datagrams between group members and the sources. Consequently, the recommended policy in PIM is for each member to receive datagrams from the RP-shared tree. However, if the data rate does not meet the receivers requirement, the particular receiver can issue a new JOIN message to construct a source-based shortest path tree for the specic source and a PRUNE message to prune branches of the original RP tree. The decision can be made independently for each receivers designated router based on its requirements. By taking advantage of different types of tree for different sources at the same time, PIM reduces the resources and overheads of delivering packets and supports QoS distribution trees for heterogeneous applications. 4. Detailed analysis and comparison In the Section 3, we gave a synoptic description for each multicast routing protocol. These Internet protocols are classied based on how the multicast routing trees and built. Other types of classication are also possible. For example, CBT and PIM are also referred as rendezvous-based multicast routing protocols because both of them initiate a RP-or Core-rooted multicast tree per group for multicasting datagrams. DVMRP and MOSPF are termed sender initiated because the multicast tree is triggered by a group sender. In the following sections, the detailed operations of these multicast protocols are discussed and examined individually. We decompose a multicast routing protocol into several components as we have mentioned in Section 2: Neighbor discovery, Group memberships maintenance, and the Multicast delivery tree maintenance. The decomposition with the specic functions helps us clarify a protocols operations and its capabilities. 4.1. Distance vector multicast routing protocol 4.1.1. DVMRP: neighbor discovery Neighbors could be discovered dynamically by exchanging Probe messages between DVMRP routers. In DVMRP, each router periodically sends a message to all of its local multicast interfaces. This message is called Probe message, and it contains a router list about known neighbors to the originated router. Initially, DVMRP routers do not have any knowledge about their neighbors in the network. Each of them issues a Probe message, which contains only the sending router itself in the list, to all of its interfaces. Once a router receiving a Probe message from its directly connected LAN and nding it is not in the list of that received message, it will add itself into the list and then issue a new Probe message back to inform the neighbor of its existence. After some time, each router would have the up-to-date neighbor list about the whole network. Then, the processing of datagram multicasting and other control messages can focus on these DVMRP routers.

4.1.2. DVMRP: group membership Similar to neighbor discovery, the information of group membership is propagated into the whole network by exchanging Route messages between DVMRP routers. The original IGMP messages would be translated to Route reports by DVMRP routers. The Route messages from a particular neighbor indicate a list of sources that are located in the direction of that neighbor. The list would be used to decide the direction of forward datagrams during multicast routing. Further, the Route messages also contain the route metrics about the distances between the router originating this report and the source network. This additional information can help DVMRP routers to build a better delivery tree. 4.1.3. DVMRP: multicast delivery tree maintenance DVMRP belongs to the source-based tree scheme. It generates the multicast delivery tree using a technique called broadcast and prune mechanism. When receiving a multicast datagram, a DVMRP router would use the unicast routing tables, the Probe and Route messages to determine the interfaces lead back to the source. If a packet did not arrive on that interface, the router would discard it. Otherwise, it duplicates and forwards the datagram onto all reverse interfaces. When the packet arrives on a router that has no group members in its downstream interfaces, a Prune message is sent back to the upstream router to clip the tree. As the Route messages with metrics are exchanged between DVMRP routers periodically, the delivery trees would change dynamically according to the status of the network. That is, some parts of the tree might be rerouted if a shorter path is found or if some router is faulty. For dynamic changes of the group members, DVMRP provides two mechanisms to trim the delivery trees. A Prune message is used to reduce unwanted multicast trafc. During multicast tree building or when a member leaves a group, any router that detects no group members present would send a Prune message to the appropriate upstream. In contrast to Prune messages, Graft messages are used for new receivers to join a multicast tree. Any Graft message is passed between adjacent DVMRP routers until it reaches the rst router that recognizes the target group. The new receiver will then be grafted to the nearest routers on the reverse path. In summary, by exchanging the routing information periodically and making route decisions by each router, DVMRP routers rene the delivery multicast tree for multicast groups dynamically. The routing in DVMRP is dependent on the control messages received from other neighbor routers. If one of these messages is lost, the related router might make wrong decisions in forwarding multicast datagrams. Some packets might be forwarded to an interface unnecessarily. Therefore, there are some timing parameters used in DVMRP. For example, Membership timeout period indicates how long a local group membership remains valid without conrmation. When a groups memberships timeout timer is expired, DVMRP routers would broadcast this

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

151

groups datagrams as it was starting to collect the group membership information. 4.1.4. DVMRP: specic features The Internet Multicast Backbone (MBONE) is an interconnected set of routers and subnets that provide IP multicast delivery in the Internet. It is a collection of autonomously administered multicast regions dened by one or more multicast-capable border routers. Each region independently chooses to run whichever multicast routing protocol best suits its needs, and the regions interconnect via the backbone region. For DVMRP, it is currently used in the backbone region of the MBONE and plays as an intermediate protocol among other multicast routing protocols. When talking about interoperability, any other protocol must support the parameters exchanged between DVMRP and itself. It is interesting that in DVMRP no interoperability issues are described. Another characteristic of DVMRP is tunneling. [17] Datagrams are encapsulated in a unicasting packet and then sent through non-multicast routers between two DVMRP routers. Tunneling enables DVMRP to interoperate with traditional routers. As DVMRP treats these tunnels as physical network interfaces, tunneling in DVMRP is transparent for routers. The routing algorithm and control messages described before need not change. 4.2. Multicast extensions to OSPF 4.2.1. MOSPF: neighbor discovery No special mechanisms about neighbor discovery are proposed in MOSPF. It follows the original mechanism in OSPF. That is, each MOSPF router is responsible for collecting reachability information from its attached subnetworks. It then oods this information throughout the network domain periodically. A minor difference is that MOSPF routers would set an optional ag to indicate the multicast capability of a specic router. In addition, because the enhancements of MOSPF are added in a backwardcompatible fashion to OSPF, routers running MOSPF would interoperate with non-multicast OSPF routers when forwarding regular unicast IP data trafc. On the contrary, non-multicast routers do not understand any multicast messages innately. Multicast datagrams ooded from MOSPF router to them would be ignored and discarded. Unlike DVMRP, no tunnel ability is available in MOSPF. Networks intermixed with MOSPF routers and non-multicast routers would be limited in delivery of multicast datagrams. To rectify this, some manual congurations must be done to route datagrams away from those nonmulticast routers. 4.2.2. MOSPF: group memberships In order to maintain the group membership in the network, MOSPF introduces a new type of link-state advertisement, The group-membership-LSAs. Its operations

are the same as other link-state advertisements in OSPF. All of them are advertised throughout the whole network periodically. The contents of the group-membership-LSAs pinpoint the locations of all multicast group members in the network. 4.2.3. MOSPF: multicast delivery tree maintenance Both DVMRP and MOSPF use the source-base tree algorithm. They construct a specic tree from each source to all its members. But they use different schemes to build the multicast delivery trees. DVMRP adopts the broadcast and prune technique. The tree is built dynamically along the delivery of datagrams. In contrast to DVMRP, MOSPF multicast trees could be determined before datagrams delivery. When a multicast datagram arrives at a MOSPF router, the router rst calculates a pruned shortest path tree from its link-state database. Then, forwarding paths for that packet is dened. The link-state database describes the topology and group memberships about the whole network. This information is collected by exchanging link-state messages. For datagram receiving, receivers use IGMP messages for participating a target group. Their last-hop MOSPF routers would translate these messages and advertise them into the network such that all routers know this information for calculating multicast trees. When members leave or join a group, the internal topology of the MOSPF changes. As these changes may invalidate the previously calculated datagram shortest-path trees, some trees may be removed and new ones built. In contrast, DVMRP only needs to rearrange some branches to adjust to changes of the network instead of rebuilding a whole new tree. 4.2.4. MOSPF: specic features Other Internet multicast routing protocols treat the overall network as a single at routing domain. That is, the whole network is seen as a single Autonomous System [10,15]. The multicasting routers maintain a separate entry in its routing table for every member in the network and exchange periodic routing messages with each of their neighbors. They incur additional processing costs whenever there is a change anywhere in the network. MOSPF inherited the characteristics of OSPF. It allows a whole network to be congured into several logical areas. Any link-state and group memberships messages are only ooded throughout their originated area. Each area works independently and communicates by their border routers. This mechanism limits the size of the link-state database and reduces the operation complexity of each router. However, the logical-area conguration also makes the MOSPF routers with incomplete knowledge about the whole Autonomous System. This might lead to some inefciency in routing when forwarding multicast datagrams between areas. To rectify it, MOSPF congures a subset of the area border router to be inter-area multicast forwarders and wild-card multicast receivers. They are responsible for summarizing and conveying link-state information and

152

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

act as hinge routers to merge multiple paths into a single forwarding path between areas. Further, the MOSPF tree is also a least cost tree. It is calculated based on the link-state advertisements and the Dijkstra-like algorithm. Even in cases of inter-area and inter-AS routing, the optimal arrangement of the sources and destinations is still approximated by the summarized information for constructing a shortest-path tree. All branches not containing multicast members are pruned from the delivery tree, and the replications that are performed by the algorithm in common branches are as few as possible. Therefore, MOSPF multicast tree always tries to use a pruned shortest-path multicast delivery tree. 4.3. Core-based tree 4.3.1. CBT: neighbor/core discovery Unlike DVMRP and MOSPF, no additional mechanisms about neighbor discovery are dened in CBT. This is because CBT employs unicasting to deliver all of its control messages. The multicast datagrams are also encapsulated before sending by IP-in-IP tunneling [17]. Therefore, it does not worry that non-multicast router would discard any CBT message. It is protocol-independent and works well with any routers. The core election in the network and the distribution of information about the core location is very important in CBT. The core placement has a signicant effect on the performance of the protocol in terms of the amount of control trafc generated and the delay imposed on the datagram delivery. While how to elect cores remains an open problem, there are two mechanisms available now: the bootstrap mechanism and manual conguration. The bootstrap [12] mechanism is specied in PIM. CBT version 2 implements it in all routers. The main idea of it is using a hash function to map a multicast group address to the IP address of the groups core. 4.3.2. CBT: group memberships For group memberships, CBT does not provide any mechanism for distributing this information either. The main reason is that the CBT algorithm belongs to rendezvous-based. What is rendezvous-based and how it is used? The following two sections provide an introduction. 4.3.3. CBT: multicast delivery tree maintenance The CBT protocol is designed to build and maintain a shared multicast distribution tree for all sources and receivers in the same group. A local CBT router would invoke the tree joining process when receiving an IGMP report from a host expressing its interest in joining a particular group. First, the router decides the core router for the target group. Then, it generates a Join-Request message towards the groups core router. This message is sent hop by hop based on unicast routing. On the way it goes through, the Join-Request messages would set up transient states in the

traversed routers. These states consist of information about the group that the message is intended, the interface it came from and the interfaces it is sent out. Once the message arrives at the core or any on-tree router, an explicit acknowledgement (Join-Ack) would be sent back. Along the way of Join-Ack message, those transient states in routers help to branch and graft the tree to the host. A multicast distribution tree is then built to cover all receivers of the target group. To send datagrams, there are two cases to consider. If the senders local router is already on-tree for the target group, the multicast datagram would be forwarded along the tree edges. If the senders router is not attached to the group tree, it would encapsulate the datagram and unicast it to the groups core router by tunneling. The core router would encapsulate and then re-send them to all members based on the shared tree indirectly. Note that data can ow either way along a tree branch in CBT because the states created in routers are bi-directional. There are no distinctions between upstream and downstream interfaces in CBT. It refers these interfaces as parent or child interface in different cases. When a member leaves the target group, a Quit-Notication message would be sent to a routers parent router if it nds its child interface list is empty. Similar to other protocols, a CBT tree is pruned in the child-to-parent fashion. But, it is not as easy to achieve the same degree of robustness as in the source-based tree schemes. A shared trees core maintains connectivity between all group members. Thus it is a crucial point. Once the core fails, CBT must detect it quickly and rebuild all trees to root at a new core. To accomplish this, each router periodically sends an EchoRequest message as a keep-alive message to its parents in CBT. If no Echo-Reply message is received within some period, the router assumes that the parent failed. This mechanism helps routers on the trees to maintain consistent information. 4.3.4. CBT: specic features CBT is currently in version 2. It differs signicantly from version 1, and is not intended to be backwards compatible with version 1. This is because IETF expects that version 1 is not widely deployed and there will be no extensive compatibility problems. IETF only guarantees that the future versions of CBT will be backward compatible with version 2. CBT is also one of the rendezvous-based multicast routing protocols. A receiver of the same group explicitly joins to a designated core. A multicast distribution tree rooted at the core is then built to cover those receivers. Based on the RP-based feature, all receivers could hear from all group sources and the sources could send datagrams to all group members by that groups RP. As the group memberships are kept by all RPs, the distribution of such information is not required. Finally, shared tree architecture saves signicant bandwidth and resources. It has a very good property on scalability. However, the delay in such architecture might not be

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155 Table 1 The comparison of DVMRP, MOSPF, CBT and PIM. DVMRP Neighbor discovery Exchange Probe messages between each router MOSPF Based on OSPF link-state advertisements CBT PIM

153

No additional mechanism about neighbor discovering

Interoperability with unicasting

Routers would refer the unicast routing table to forward multicast datagrams. But they work as independent systems from unicasting Use the tunneling technique to pass multicast datagram through Exchange Route messages between each router Source-based tree Use manual congurations to keep away from those routers Add a new advertisement, Group-membership LSA

Deliver datagrams and its control messages based on unicasting

Interaction with non-multicast routers

Group Memberships

The rendezvous-based property avoids the need for distribution of group memberships Share-based tree Source-based and sharedbased trees When a receiver joins the group or a sender starts to deliver datagrams

Tree Type

Tree construction point

When a sender delivers a multicast datagram

Before delivery of multicast

When a receiver wants to join a particular group

Protocol is initiated by Actions of senders router

Sender Send datagrams directly Send datagrams after the multicast tree has been calculated

Receiver Send datagrams to the core router Send datagrams in PIMRegister messages to the rendezvous point

Actions of receivers router

Based on the Group memberships schemes to announce their existences Dynamic Consume too many resources Where group members are densely represented or bandwidth is universally plentiful Static

Use explicit join/prune messages to join or leave the group

Tree Construction Disadvantage Suitability for environment

Static Not minimal delay

Static Complex

Where group members are distributed sparsely around the network and the bandwidth is not widely available

minimal [1]. The phenomenon of trafc concentration on the shared links might make the CBT unsuitable for some time-critical applications. Further, new receivers join to the nearest routers on the delivery tree. As it does not consider the possibility of using common tree edges, the resulting shared tree might not be optimal. 4.4. Protocol-independent multicast 4.4.1. PIM: neighbor/RP discovery and group memberships The specications about neighbor discovery and group memberships in PIM are the same as CBT. The major difference is that the senders can deliver multicast datagrams directly to receivers in PIM, not necessary by cores as in CBT. That is, the senders and receivers would involve a join procedure while sending or receiving datagrams to construct a particular path from the RP to itself. By these constructed delivery paths, RP acts as a central forwarder to transmit datagrams from sources to group members. Dependent on different requirements of the applications, however, PIM

allows the specic sender to build a source-based multicast tree to deliver datagrams to the group members directly without passing the RP rst. Here, the explicit join for senders is a major and specic feature for PIM. Other protocols do not have the same mechanism for senders. 4.4.2. PIM: multicast delivery tree maintenance The major improvement in PIM is that it proposes a good architecture with both properties of shortest-path tree and shared-based tree schemes. It allows applications to choose the kind of delivery trees to meet their requirements. Like CBT, PIM can be deployed without requiring a specic unicasting routing protocol. Multicast datagrams are propagated only among PIM routers. All PIM control messages are delivered in the unicasting fashion. PIM is also a rendezvous-based protocol. The following explains its detailed operations. When receiving an IGMP join message from a host, the last-hop PIM router would start to send periodic PIM-Join messages towards the RP for that group. Each intermediate

154

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155

router along the path would set up the multicast tree branch from the RP to the originated host. This constructs an initial PIM tree for the group. On the contrary, unlike CBT, datagrams from sources must be sent to the RP rst. When a source starts sending datagrams to the multicast group, the last-hop PIM router would encapsulate the original datagram in a PIM-Register message and then send it to the RP for that group. This PIM-Register message acts as the PIM-Join message. It would construct a delivery path from the source to the groups RP. Then, the groups PIM tree is really built for communicating between sources and receivers. The following datagrams would be sent along that path to the RP, and then distributed to all receivers. Based on sources data rate for different applications or some other conguration parameters of network administration policy, if a source-specic tree is desired, a new PIMJoin message would be triggered by the last-hop router of each member to the source. Processing of these messages by intermediate routers constructs a shortest-path tree rooted at the source to those members. After data packets are received on the new path, those members would send PIM-Prune messages towards the groups RP to inform it of the transition from shared tree to source-specic tree. Then, the RP will not forward any datagram sent by that source to those members. However, if there are other senders for that group, the tree branches between RP and those members would not be pruned. They will be used to forward other sources datagrams. 4.4.3. PIM: specic features PIM is designed to provide architecture for efciently routing to multicast groups that span wide-area internetworks. It uses explicit source- and receiver-specic join/ prune processes to build shared trees for delivering multicast datagrams by default. This reduces the bandwidth and resources used for multicasting. And, for special application requirements, it allows the shared tree to be switched to the shortest-path tree. PIM also provides several mechanisms for trafc control. For example, PIM allows users to set some threshold in its routers. If the sources data rate is lower than that threshold, shortest path Join messages would not be triggered and receivers still receive datagrams via the shared trees instead and no source specic tree would be constructed. On the contrary, PIM also adopts the scalable timer approach to make the total overhead of its control messages be some small percentage of the link bandwidth. To summarize, PIM has the properties of high-quality data distribution and efcient sparse group support for multicasting.

detailed operations of each protocol. The differences between them were analyzed in detail by three characteristics. We summarize their characteristics in Table 1. DVMRP uses the broadcast the prune technique to build the delivery tree dynamically. MOSPF maintains a database about the network topology and group memberships. Then, it uses a Dijkstra-like algorithm to build the tree before forwarding datagrams. Both CBT and PIM members use a tree joining process to construct an RP-rooted delivery tree. Sources send datagrams via the RP to distribute to all members for that group. Regarding the present state and the trends of multicasting, DVMRP was developed in November 1988 with RFC 1075. The newest version of it is the draft version 3.4 and it is currently used in the backbone of the MBONE. CBT and PIM-DM were proposed in 1995 and 1996 respectively. They only have draft documents now. PIM-SM was released as a formal document, RFC 2117, in June 1997 to provide an efcient mechanism for multicasting across a wide area. The other protocol, MOSPF, proposed in 1985 seems pessimistic in the future. The requirement of resources for maintaining a large database of the whole network is the main disadvantage. DVMRP and CBT use extreme strategies to meet their different design objectives. PIM breaks this tie. It allows members to switch between the shortest path tree and the shared tree according to their requirements. However, this scheme might not be optimal for the whole groups and networks. Trafc concentration problems still exist between the specic links used by different groups or sourcedestination pairs at the same time. In addition, these multicast protocols are not implemented and used widely in todays new applications. The performances of them are still doubted. Consequently, more quantitative analysis about the performance of these protocols need to be done. These may include the messages overhead and their behaviors for different applications or different network topologies.

Acknowledgements The authors would like to express their thanks to the anonymous referees for their valuable comments that greatly improved the quality of this article.

References
[1] A. Ballardie, Core based tree (CBT) multicast: architectural overview, Internet draft, draft-ietf-idmr-cbt-arch-06, March 1997. [2] A. Ballardie, Core based tree (CBT) multicast: protocol specication, Internet draft, draft-ietf-idmr-cbt-spec-09, May 1997. [3] A. Ballardie, Core based tree (CBT) multicast border router specication for connecting a CBT stub region to a DVMRP backbone, Internet draft, draft-ietf-idmr-cbt-dvmrp-00, March 1997. [4] B. Cain, S. Deering, A. Thyagarajan, Internet group management protocol version 3, Internet drafts, draft-cain-igmp-00.txt, August 1995.

5. Conclusions In this article, we have discussed four well-known multicast routing protocols in the Internet. These discussions include the concepts behind their developments and the

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144155 [5] S. Deering, Host extensions for IP multicasting, RFC 1112, August 1989. [6] S. Deering, Multicast routing in datagram internetworks and extended LANs, ACM transactions on computer systems 8 (2) (1990) 85110. [7] S. Deering, C. Partridge, D. Waitzman, Distance vector multicast routing protocol, RFC 1075, November 1988. [8] S. Deering, D. Estrin, D. Fariancci, M. Handley, A. Helmy, V. Jacobson, C. Liu, P. Sharma, D. Thaler, L. Wei, Protocol independent multicast-spare mode (PIM-SM): motivation and architecture, Internet draft, draft-ietf-idmr-pim-arch-04, October 1996. [9] S. Deering, D. Estrin, D. Fariancci, M. Handley, A. Helmy, V. Jacobson, C. Liu, P. Sharma, D. Thaler, L. Wei, Protocol independent multicastspare mode (PIM-SM): protocol specication, RFC 2117, June 1997. [10] S. Deering, D. Estrin, D. Farincci, V. Jacobson, A. Helmy, L. Wei, Protocol independent multicast-dense mode (PIM-DM): protocol specication, Internet draft, draft-ietf-idmr-pim-dm-05, May 1997. [11] D. Estrin, L. Wei, The trade-offs of multicast tree and algorithms, In

155

[12]

[13] [14] [15] [16] [17] [18] [19]

proceedings of the 1994 international conference on computer communication of networks, September 1994. D. Estrin, M. Handley, A. Helmy, P. Huang, D. Thaler, A dynamic bootstrap mechanism for rendezvous-based multicast routing, Technical report, ftp://catarina.usc.edu/pim. W. Fenner, Internet group management protocol, version 2, Internet draft, draft-ietf-idmr-igmp-v2-01.txt, September 1995. F.K. Hwang, D.S. Richards, Steiner tree problems, Networks 22 (1) (1992) 5589. J. Moy, Multicast extensions to OSPF, RFC 1584, March 1994. J. Moy, MOSPF, analysis and experience, RFC 1585, March 1994. C. Perkins, IP encapsulation with IP, RFC 2003, October 1996. T. Pusateri, Distance vector multicast routing protocol, Internet draft, draft-ietf-idmr-dvmrp-v3-04, February 1997. W. Wall, Mechanisms for broadcast and selective broadcast, Ph.D. dissertation, Standford University, June 1990.