Multicast Protocols Comaprison

7/27/2019 Multicast Protocols Comaprison

1/12

A comparison of the Internet multicast routing protocols

Jhyda Lina, Ruay-Shiung Changb,*

aDepartment of Information Management, National Taiwan University of Science and Technology, Taipei, TaiwanbDepartment 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 specific 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 efficiently 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 require-

ments 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 co-

operating applications. Unlike most of the successful appli-

cations in use today, they involve the interactions among

multiple members in a single session. For example, theimages 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 impor-

tant function called multicasting.

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 broad-

casting, 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 specific group address will be distributed

to all members of that group. To avoid consuming band-width by forwarding datagrams repeatedly on unicasting

basis or causing heavy traffic 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 tradi-

tional 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:

Computer Communications 22 (1999) 144155

0140-3664/99/$ - see front matter 1999 Elsevier Science B.V. All rights reserved.

PII: S0140-3664(98) 00236-9

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: [email protected]


2/12

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 specific member-

ships. The well-known Internet Group Management Proto-

col (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 multi-

cast data packets to the appropriate links.

However, IGMP only handles the membership manage-

ment on one directly-attached subnetwork. This capability

limits the forwarding of multicast traffic from a router to

group members on the specific local subnetwork. For multi-

casting to extend beyond the scope of the local subnetwork,

a multicast routing protocol must first construct multicastdelivery 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 data-

grams 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 specific

multicast protocols with others. Consequently, passing amulticast datagram to multicast ignorant routers will

cause that datagram to be ignored and discarded. Provid-

ing 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 multi-

cast control messages can then concentrate on specific

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 specific message should be sent to

inform multicast routers in the network. Later on, multi-

cast routers can know how to forward the multicast data-

grams 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 Member-

ship 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 main-

tained by each router to indicate that their attached

network has one or more hosts belonging to some multi-

cast 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 subnet-

works.

3. Multicast delivery tree maintenance: For multicasting, to

deliver multicast datagrams to specific members of the

target group is equivalent to construct a multicast deliv-

ery tree to span those members. There are many differenttechniques proposed to establish the multicast trees. Two

classic types of trees are widely used in todays multi-

casting protocols. They are source-based tree and

shared tree schemes. The shared tree schemes might

cause the traffic 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 source-

based 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 dynamicchanges of group memberships. In addition, fault toler-

ance must also be taken into account for different

designs.

These three characteristics are basics for multicast rout-

ing 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 usethese characteristics to examine each of them for highlight-

ing 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 defined a service model for multi-

casting and devised the related algorithms. After several

years of studying and practical experience with multicast-

ing, there are four mainstream multicasting protocols in the

Internet today: Distance Vector Multicast Routing Protocol

J. Lin, R.-S. Chang / Computer Communications 22 (1999) 144 155 145


3/12

(DVMRP) [7,18], Multicast extensions to OSPF (MOSPF)

[15,16], Core-Based Tree (CBT) [13], and Protocol-Inde-

pendent Multicast (PIM) [810]. Note that PIM actually

consists of two protocols: PIM Sparse Mode (PIM-SM)

and PIM Dense Mode (PIM-DM). This definition is becauseof the objective of the Inter-Domain Multicast Routin-

g(IDMR) working group for the PIM. They hope to develop

one or possibly more than one standard track multicast rout-

ing 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 defines 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 explicitlystated.

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 rout-

ing trees are built. In the following paragraphs, we will

discuss the tree building mechanisms first. A simplified

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 data-

grams. When a multicast datagram arrives at an interface ofa 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 Xacts

as a source in the multicast session and Xwants to send a

multicast datagram to the group members (Hosts Yand 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 routerA. The default action of the designated router

Ais 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 Cand router H, they would

send an explicit prune message upstream to avoid unneces-sary 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) 144 155146

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


4/12

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 multi-

cast 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 figure is abstracted from

the MOSPF specification [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 outboundrouter 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 exam-

ple, the first 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 theRouter-1andNetwork-3, (c) a 3-unit cost

link exists between Router-1and 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

groupA. 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 Router-

3 then forwards that datagram into Network-3 towardRouter-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. 2. A simple sample for MOSPF configuration.

Fig. 3. The operations of the MOSPF.


5/12

datagram to its connected LAN (Network-2) andRouter-4

delivers it to Network-6for 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 thou-

sands 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, finding 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 NP-Complete problem [14].

A simpler approach to constructing a group-shared tree

was proposed by Wall [19] using a center-specific 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 traffic

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-specific 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-specific trees lie

somewhere between the minimal Steiner tree and source-specific 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 configuration or some special protocol [8], and acts

as a junction for the groups multicast traffic. Datagrams

from the source will travel to the core first, and then willbe distributed along the other branches to the groups recei-

vers 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 Sby manual configura-

tion in this example and the four hosts do not join any group.

If host Xwants to send a datagram to group S, it can only


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

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


6/12

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 groupS. Therefore, the

default action is to forward that datagram to the core. As noone has joined group S yet, router E would discard the

received datagrams.

In Fig. 5, assume hostYand host Zwant to join group S.

Host Y would send an IGMP membership report to

announce that it wishes to receive traffic addressed to the

multicast group S. Upon receipt of this IGMP report, the

next-hop router Fwill issue a Join-Request message to the

groups core router E. This request message travels a speci-

fic path along the way towards the core. The next-hop router

Bfor hostZwould 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 groupmembers.

However, when some hosts join groupS, the groups core

router would keep the group membership information. If

hostXtries to send a multicast datagram to group Sagain,

the datagram would again be sent to core router E. As the

core router has information for the group Snow, it would

forward the datagram along the constructed multicast deliv-

ery tree to all group members of group S. Fig. 6 shows this

scenario. If host W also wants to send a datagram to the

groupS, it would also send the datagram to the core first.

3.3. Multicast protocols with mixed approaches

As mentioned, CBT proposes the use of one single multi-

cast tree per multicast session. All sources transmitting to

that multicast session distribute their traffic 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-specific 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-specific tree that spans all

members of that session. It merely has to find 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. Simi-

larly, when a new member joins an already existing multi-

cast session, it does not have to join the source-specific treesof all sources transmitting to that session. It simply has to

find a path to connect itself to the existing shared tree. There

is no need to keep an explicit list of the sources of a multi-

cast 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 video-

gaming applications, would have significantly less impactson network resources. However, for the shared tree architec-

ture, 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 first and then

distributed to group members in turn. The shared tree

approach might also result in the traffic 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 agroup-shared tree. In PIM, the default operations for the

group member joining and datagrams forwarding is identi-

cal to CBT. Each host sends IGMP_JOIN message to

announce its participation for the particular group. Its desig-

nated router records this membership and issues an addi-

tional Join-Request to the rendezvous point (RP)1 for

constructing a path between the RP and itself. A shared


Fig. 6. The operations of the CBT protocols: HostXsends a datagram to Group S.

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.


7/12

multicast delivery tree is then constructed to forward multi-

cast 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 specific 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 clas-

sified based on how the multicast routing trees and built.

Other types of classification 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 opera-

tions of these multicast protocols are discussed and exam-

ined individually. We decompose a multicast routing

protocol into several components as we have mentioned in

Section 2: Neighbor discovery, Group memberships main-tenance, and the Multicast delivery tree maintenance. The

decomposition with the specific 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 exchan-

gingProbemessages 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 nothave 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 finding 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 informa-

tion 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 todetermine 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, DVMRPprovides two mechanisms to trim the delivery trees. A

Prune message is used to reduce unwanted multicast traffic.

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

first router that recognizes the target group. The new recei-

ver will then be grafted to the nearest routers on the reverse

path.

In summary, by exchanging the routing information peri-

odically and making route decisions by each router,DVMRP routers refine the delivery multicast tree for multi-

cast groups dynamically. The routing in DVMRP is depen-

dent 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 data-

grams. 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 confirmation. When a groups memberships timeout

timer is expired, DVMRP routers would broadcast this



8/12

groups datagrams as it was starting to collect the group

membership information.

4.1.4. DVMRP: specific features

The Internet Multicast Backbone (MBONE) is an inter-

connected set of routers and subnets that provide IP multi-

cast delivery in the Internet. It is a collection ofautonomously administered multicast regions defined 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 inter-

mediate 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 interoperabil-

ity issues are described. Another characteristic of DVMRP

is tunneling. [17] Datagrams are encapsulated in a

unicasting packet and then sent through non-multicastrouters 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 subnet-

works. It then floods this information throughout the

network domain periodically. A minor difference is that

MOSPF routers would set an optional flag to indicate the

multicast capability of a specific router. In addition, because

the enhancements of MOSPF are added in a backward-

compatible fashion to OSPF, routers running MOSPF

would interoperate with non-multicast OSPF routers when

forwarding regular unicast IP data traffic. On the contrary,

non-multicast routers do not understand any multicast

messages innately. Multicast datagrams flooded 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 multi-

cast datagrams. To rectify this, some manual configurations

must be done to route datagrams away from those non-

multicast 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 adver-

tisement, 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 specific 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 deliv-

ery. When a multicast datagram arrives at a MOSPF router,

the router first calculates a pruned shortest path tree from its

link-state database. Then, forwarding paths for that packet is

defined. The link-state database describes the topology and

group memberships about the whole network. This informa-

tion 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 data-

gram 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: specific features

Other Internet multicast routing protocols treat the overall

network as a single flat 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 inher-

ited the characteristics of OSPF. It allows a whole network

to be configured into several logical areas. Any link-state

and group memberships messages are only flooded through-

out their originated area. Each area works independentlyand 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 configuration also makes the

MOSPF routers with incomplete knowledge about the

whole Autonomous System. This might lead to some ineffi-

ciency in routing when forwarding multicast datagrams

between areas. To rectify it, MOSPF configures a subset

of the area border router to be inter-area multicast forwar-

dersandwild-card multicast receivers. They are responsible

for summarizing and conveying link-state information and



9/12

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 defined in CBT. This is

because CBT employs unicasting to deliver all of its controlmessages. 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 significant effect on the

performance of the protocol in terms of the amount of

control traffic generated and the delay imposed on the data-

gram delivery. While how to elect cores remains an open

problem, there are two mechanisms available now: the

bootstrap mechanism and manual configuration. Thebootstrap [12] mechanism is specified 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 rendez-

vous-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 recei-

vers 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 acknowl-

edgement (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 flow 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-Notifica-

tionmessage would be sent to a routers parent router if it

finds its child interface list is empty. Similar to other proto-

cols, a CBT tree is pruned in the child-to-parent fashion.

But, it is not as easy to achieve the same degree of robust-

ness 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 Echo-

Requestmessage as a keep-alive message to its parents in

CBT. If no Echo-Reply message is received within someperiod, the router assumes that the parent failed. This

mechanism helps routers on the trees to maintain consistent

information.

4.3.4. CBT: specific features

CBT is currently in version 2. It differs significantly 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 rout-ing 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 significant band-

width and resources. It has a very good property on scal-

ability. However, the delay in such architecture might not be



10/12

minimal [1]. The phenomenon of traffic 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 specifications about neighbor discovery and group

memberships in PIM are the same as CBT. The major differ-

ence 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 specific sender to build a source-based multicast

tree to deliver datagrams to the group members directly

without passing the RP first. Here, the explicit join for

senders is a major and specific feature for PIM. Other proto-

cols 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 andshared-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 specific

unicasting routing protocol. Multicast datagrams are propa-

gated only among PIM routers. All PIM control messages

are delivered in the unicasting fashion. PIM is also a rendez-

vous-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


Table 1

The comparison of DVMRP, MOSPF, CBT and PIM.

DVMRP MOSPF CBT PIM

Neighbor discovery Exchange Probe messages

between each router

Based on OSPF link-state

advertisements

No additional mechanism about neighbor discovering

Interoperability with unicasting Routers would refer the unicast routing table to forwardmulticast datagrams. But they work as independent

systems from unicasting

Deliver datagrams and its control messages based onunicasting

Interaction with non-multicast

routers

Use the tunneling technique

to pass multicast datagram

through

Use manual configurations

to keep away from those

routers

Group Memberships Exchange Route messages

between each router

Add a new advertisement,

Group-membership LSA

The rendezvous-based property avoids the need for

distribution of group memberships

Tree Type Source-based tree Share-based tree Source-based and shared-

based trees

Tree construction point When a sender delivers a

multicast datagram

Before delivery of multicast When a receiver wants to

join a particular group

When a receiver joins the

group or a sender starts todeliver datagrams

Protocol is initiated by Sender Receiver

Actions of senders router Send datagrams directly Send datagrams after the

multicast tree has been

calculated

Send datagrams to the core

router

Send datagrams in PIM-

Register messages to the

rendezvous point

Actions of receivers router Based on the Group memberships schemes to announce

their existences

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

Tree Construction Dynamic Static Static Static

Disadvantage Consume too many resources Not minimal delay Complex

Suitability for environment Where group members are densely represented or

bandwidth is universally plentiful

Where group members are distributed sparsely around the

network and the bandwidth is not widely available


11/12

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 first.

When a source starts sending datagrams to the multicast

group, the last-hop PIM router would encapsulate the origi-

nal datagram in aPIM-Registermessage 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 configuration parameters of network administra-

tion policy, if a source-specific tree is desired, a new PIM-

Join 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 receivedon the new path, those members would send PIM-Prune

messages towards the groups RP to inform it of the transi-

tion from shared tree to source-specific 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: specific features

PIM is designed to provide architecture for efficiently

routing to multicast groups that span wide-area internet-works. It uses explicit source- and receiver-specific join/

prune processes to build shared trees for delivering multi-

cast 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 traffic 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 specific 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 efficient sparse group support for multicasting.

5. Conclusions

In this article, we have discussed four well-known multi-

cast routing protocols in the Internet. These discussions

include the concepts behind their developments and the

detailed operations of each protocol. The differences

between them were analyzed in detail by three characteris-

tics. 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

efficient mechanism for multicasting across a wide area. The

other protocol, MOSPF, proposed in 1985 seems pessimis-tic 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. Traffic concentration problems still exist between

the specific links used by different groups or sourcedesti-

nation pairs at the same time. In addition, these multicast

protocols are not implemented and used widely in todaysnew 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 over-

view, Internet draft, draft-ietf-idmr-cbt-arch-06, March 1997.

[2] A. Ballardie, Core based tree (CBT) multicast: protocol specification,

Internet draft,draft-ietf-idmr-cbt-spec-09, May 1997.

[3] A. Ballardie, Core based tree (CBT) multicast border router specifica-

tion for connecting a CBT stub region to a DVMRP backbone, Inter-

net 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.



12/12

[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. Jacob-

son, C. Liu, P. Sharma, D. Thaler, L. Wei, Protocol independent

multicast-spare mode (PIM-SM): motivation and architecture, Inter-net 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 multicast-

spare mode (PIM-SM): protocol specification, 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

specification, Internet draft, draft-ietf-idmr-pim-dm-05, May 1997.

[11] D. Estrin, L. Wei, The trade-offs of multicast tree and algorithms, In

proceedings of the 1994 international conference on computer

communication of networks, September 1994.

[12] D. Estrin, M. Handley, A. Helmy, P. Huang, D. Thaler, A dynamic

bootstrap mechanism for rendezvous-based multicast routing, Tech-

nical report, ftp://catarina.usc.edu/pim.

[13] W. Fenner, Internet group management protocol, version 2, Internet

draft,draft-ietf-idmr-igmp-v2-01.txt, September 1995.

[14] F.K. Hwang, D.S. Richards, Steiner tree problems, Networks 22 (1)

(1992) 5589.[15] J. Moy, Multicast extensions to OSPF, RFC 1584, March 1994.

[16] J. Moy, MOSPF, analysis and experience, RFC 1585, March

1994.

[17] C. Perkins, IP encapsulation with IP, RFC 2003, October 1996.

[18] T. Pusateri, Distance vector multicast routing protocol, Internet draft,

draft-ietf-idmr-dvmrp-v3-04, February 1997.

[19] W. Wall, Mechanisms for broadcast and selective broadcast, Ph.D.

dissertation, Standford University, June 1990.


Documents

Multicast Protocols Comaprison