a scalable multicast routing protocol for building shortest path trees

INTERNATIONAL JOURNAL OF COMMUNICATION SYSTEMSInt. J. Commun. Syst. 2007; 20:993–1009Published online 24 October 2006 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/dac.859

A scalable multicast routing protocol for buildingshortest path trees

Baoxian Zhang1, Jun Zheng2 and Hussein T. Mouftah2,*,y

1College of Computing and Communication Engineering, Graduate University of ChineseAcademy of Sciences, Beijing 100049, China

2School of Information Technology and Engineering, University of Ottawa, Ottawa, Ont., Canada K1N 6N5

SUMMARY

Scalability is a great concern in the design of multicast routing protocols for the global Internet. Buildingshortest path trees (SPT) is currently one of the most widely used approaches to supporting multicastrouting because of the simplicity and low per-destination cost of such trees. However, the construction ofan SPT typically involves high protocol overhead, which leads to the scalability problem as the number ofconcurrent multicast sessions increases.In this paper, we present a destination-initiated shortest path tree (DSPT) routing protocol. The design

objective is to effectively reduce the protocol overhead associated with SPT constructions for providingscalable multicast. To achieve this objective, we introduce destination-initiated joining operations inconstructing SPTs. With DSPT, each router receiving a request to join a specific multicast group makes alocal decision on selecting its parent node through which it connects to the existing tree. A source-rootedSPT is built as a result of such collaborative operations at nodes. DSPT requires only limited routinginformation at routers. Analytical results demonstrate that DSPT scales well with respect to computation,storage and communication overhead when the number of concurrent multicast requests is large.Simulation experiments are also conducted to verify the correctness of the theoretically deduced analyticalresults. Copyright # 2006 John Wiley & Sons, Ltd.

Received 17 November 2004; Revised 21 February 2005; Accepted 1 March 2005

KEY WORDS: multicast; shortest path tree; routing

1. INTRODUCTION

Multicast routing is a key issue in supporting group communications in the global Internet. Acommonly used approach for supporting multicast routing is to construct delivery trees using amulticast routing protocol. To support scalable multicast routing, a multicast routing protocolmust be able to scale well to the number of multicast requests and use as less routinginformation as possible.

*Correspondence to: Hussein T. Mouftah, School of Information Technology and Engineering, University of Ottawa,Ottawa, Ont., Canada K1N 6N5.yE-mail: [email protected]

Copyright # 2006 John Wiley & Sons, Ltd.

There are three basic paradigms for constructing efficient tree structures to support groupcommunications: Steiner trees [1], shortest path trees (SPT), and centre-based trees (CBT) [2]. ASteiner tree, or Steiner minimal tree (SMT), is a tree with the minimal overall cost, which coversthe source and each of the group members. Since the SMT problem is known to be NP-complete[1], heuristics have been extensively studied to obtain approximate solutions to the problem (see[3, 4] and the references cited therein). Due to their high computational complexity, however,these heuristics are not popular in practice for providing multicast services in communicationnetworks.

An SPT is constructed by combining the shortest paths from the source node of a multicastsession to each destination of the session. The main advantages of SPT include simplicity andlow per-destination cost. These properties make SPT structure suitable for providingmultimedia applications, which are typically delay sensitive and have high-bandwidthrequirements. Many existing multicast routing protocols are employed in the current Internet,for example, distance vector multicast routing protocol (DVMRP) [5] and multicast extension toopen shortest path first (MOSPF) [6] were designed to build SPTs for delivering multicast traffic.

The DVMRP protocol provides connectionless datagram delivery from a multicast source toa group of members. DVMRP is fully distributed and can dynamically construct a multicastdelivery tree using a technique called reverse path multicasting (RPM) [5] to forward multicasttraffic to the downstream interfaces at each router. More specifically, if a data packet is receivedat a router over the interface which is on the shortest path from the current router to the sourceof the packet, it will be forwarded to all other interfaces; otherwise it will be simply discarded.According to DVMRP, a router without any local members will send a prune message upstreamtowards the source of the group. The prune message prunes the branch not leading to any groupmembers, thus resulting in a source-specific reverse SPT. The main disadvantages of DVMRPinclude the heavy overhead because of its periodic flooding of multicast datagrams across theentire network and its reverse shortest path characteristic, which make it unfriendly tosupporting delay-sensitive applications.

The MOSPF protocol is currently the only protocol employed in the Internet, which works tobuild source-rooted SPTs. MOSPF is designed to work on top of the open shortest path first(OSPF) protocol [7] to support IP multicast. With MOSPF, a router floods a group-specificmembership-LSA (link state advertisement) across the entire network if it has local member(s)currently belonging to the group. This network-wide dissemination of group membership allowsall MOSPF routers in the domain to have the same view of the membership of a group. As aresult, each MOSPF router can independently construct an identical SPT for each (source node,group address) combination using Dijkstra’s SPT algorithm. To ease the computational demandat routers, these delivery trees are built ‘on demand,’ i.e. the first time when a datagram having aparticular combination of source network and multicast destination is received. Accordingly,MOSPF is data driven in nature. An MOSPF router can then determine its position on the SPTand create a forwarding table for the subsequent arriving multicast datagrams of the session.

The MOSPF protocol suffers from the scalability problems because of several reasons asfollows. First, to determine its position on the delivery tree built for each ‘passing-by’ group, anMOSPF router needs to locally perform Dijkstra’s SPT calculation when it receives a firstmulticast datagram belonging to a specific group. Such calculation can cause highcomputational overhead at routers when the number of concurrent multicast requests increases.Second, the network-wide dissemination of group-specific membership information canintroduce excessive communication overhead. Third, MOSPF requires each router to locally

B. ZHANG, J. ZHENG AND H. T. MOUFTAH994

Copyright # 2006 John Wiley & Sons, Ltd. Int. J. Commun. Syst. 2007; 20:993–1009

DOI: 10.1002/dac

store group-specific membership information for each multicast session. This can cause a highstorage overhead when the number of concurrent multicast sessions is very large.

To combat the scalability problem in providing multicast, Core-Based Tree (CBT) protocol[2] and protocol independent multicast-sparse mode (PIM-SM) [8, 9] were designed as alternateprotocols to overcome the deficiencies of DVMRP and MOSPF. With either CBT or PIM-SM,a node,z which wishes to join a group, sends a join message along the shortest path from thenode itself to the core node in the CBT protocol or the rendezvous point (RP) in the PIM-SMprotocol to initiate a join operation. A router receiving such a message creates a multicast entryfor the group and forwards the message further until it reaches the core (or the RP) node, or anode already on the forwarding tree created for the group to join. As a result, each multicastdestination is connected with the core or the RP via the reverse shortest path. Neither the reverseshortest path characteristic nor the core-based (or RP-based) delivering structure is friendly toprovide delay-sensitive applications. Another drawback of CBT is that the same tree is used forall members of a group. As a result, traffic concentration may occur on certain physical linksbecause multiple sources belonging to the same group can send traffic over the same delivery treesimultaneously.

In this paper, we design a multicast routing protocol named destination-initiated SPT routingprotocol (DSPT), which aims at providing scalable multicasting by building source-rooted SPTsin an overhead-efficient manner. To construct an SPT using MOSPF, each intermediate on-treenode locally determines its children link set through a tree-calculating process, using theknowledge of both group-specific membership and global state information that it locallymaintains. The intuitive idea behind DSPT comes from the observation that an SPT can besolely determined if each node is able to make a local decision on selecting its (proper) on-treeparent node. Such a change of viewpoint can bring a significant reduction in the overheadintroduced for constructing an SPT without affecting its per-destination shortest pathcharacteristic provided that appropriate destination-initiated joining operations are implemen-ted. To locally determine the children link set of an intermediate router on a ‘pass-by’ deliverytree, the router needs to locally maintain a copy of the group-specific membership, with which atree-calculating algorithm can be performed to determine its children link set. Moreover, thecorresponding calculated result can be used only for this particular multicast session. Incontrast, to determine the parent node of an intermediate router on a ‘pass-by’ tree, theinformation of the group source is sufficient to make such a decision. The problem to be solvedin this case is just a unicast routing problem because the routing decision is independent ofgroup-specific membership. In particular, this calculated result can also be used for subsequentrequests that the router receives (if any). In practice, an additional cost vector can be pre-computed to ease the destination-initiated joining operations. That is, instead of performing asource routing algorithm for tree calculations, a source-rooted SPT is built in a hop-by-hopmanner if each intermediate node can make a correct local decision on selecting its parent nodefor it to connect to the existing tree (or the source).

The rest of this paper is organized as follows. Section 2 gives a detailed description of theDSPT protocol design and illustrates how it works. Section 3 evaluates the performance ofDSPT through comprehensive analysis. Section 4 presents simulation results to verify theanalytical results that are deduced. Section 5 concludes this paper.

zMore exactly, the designated router (DR) of a host that requests to join a particular group.

SCALABLE MULTICAST ROUTING PROTOCOL 995


DOI: 10.1002/dac

2. DSPT PROTOCOL

In this section, we will first formulate the communication network under consideration, giveassumptions that make the DSPT protocol to operate successfully, describe the detailedoperational procedures of DSPT, and illustrate how DSPT works.

2.1. Network model and routing information

We consider a communication network that can be modelled as a directed graph GðV ;EÞ; whereV is the set of nodes and E is the set of links in the network. Each link in the network consists ofa pair of unidirectional links in opposite directions. Each link e (e 2 E) is associated with a cost,CðeÞ 2 Rþ; whose value is real and positive. The link cost CðeÞ can be a measure of the resourceutilization of the link, a monetary cost of using the link, or a delay value as experienced bypackets while traversing the link. In general, we consider asymmetrical links, which means thatthe cost of link e ¼ ði; jÞ does not have to be the same as that of link e0 ¼ ðj; iÞ: Each networknode maintains precise global network state information (including network topology and thedetailed state information associated with each link). Such state information can be provided byusing a link state routing protocol such as OSPF. In the rest of this paper, we will use the terms‘node’ and ‘router’ interchangeably unless otherwise stated.

With DSPT, each node is required to maintain an additional cost vector, which consists ofjV j � 1 entries, one for every other node in the network. The entry for node j ðj 2 V � figÞ atnode i contains the following information:

} The identifier of node j.} The cost value of the least cost path from j to i, denoted by Cji; optionally.} The predecessor(s) of node i on the least cost paths from j to i. There may exist multiple such

neighbouring nodes at i due to the possible availability of equal-cost multiple shortest pathsfrom j to i. This predecessor set, denoted by PREVj

i ; is given as fk 2 V jCjk þ Cðk; iÞ ¼ Cjig:jPREVj

i j represents the size of the set. For strongly connected networks, we have jPREVji j

51; 8j; i:

Here, node j is considered as a source node and node i is considered as the destination node.This vector information can be easily obtained by one run of Dijkstra’s algorithm in thebackward direction to generate a sink tree. This calculation can be carried out offline or uponthe arrival of a first communication request. In either case, the calculated result will be locallymaintained and will be used for subsequent arriving requests (if any) until the next change of thenetwork state is detected. The additional overhead for storing this vector information at eachnetwork node is obviously OðjV jÞ:

2.2. Routing problem and multicast-related assumptions

The multicast routing problem that we study can be described as follows. For a multicast sessionwith a source node s and a set of multicast destinations S, jSj52 and s =2 S; build a delivery treecovering s and each node in S such that the unique path on the resulting tree connecting thesource s and each multicast destination di (di 2 S) is the shortest path from s to di:

In order for DSPT to operate correctly, we assume that the addresses of a multicast groupand its group source are known to potential members through some kinds of advertisements orquery mechanisms [10], which are somewhat orthogonal to the specification of the DSPT



DOI: 10.1002/dac

protocol and will not be discussed in detail. On the other hand, routers implementing the DSPTprotocol do not need to maintain any knowledge of either group-specific membership or on-treenodes for each multicast session.

Each router maintains an entry for each multicast group whose distribution tree passesthrough the router. Each such entry contains the following contents: the address of the sourcenode s of the specific group, the address of the group G, a set of outgoing interface(s), and anincoming interface. When a new member wishes to join a group, it sends an explicit join requesttowards the source node of the group. When a member leaves a group, it sends a prune messageupstream towards the source node of the group if it is a leaf node of the tree.

2.3. Protocol description

Before presenting the detailed design of DSPT, we first give the theoretical basis behind the tree-constructing operations in DSPT. DSPT utilizes the concept of the predecessor subgraph [11].Let pij denote a selected predecessor of j on a shortest path from i to j. A predecessor subgraphof the original graph G for a node i 2 VðGÞ is denoted by Gp;i ¼ ðVp;i;Ep;iÞ; whereVp;i ¼ fj 2 V j pij=NILg [ fig and Ep;i ¼ fðpij ; jÞ j j 2 Vp;i � figg: This predecessor subgraphwas proved to be a SPT rooted at i [11]. DSPT builds such a predecessor subgraph in a bottom-up manner such that each node (initially each of those group members) independently decides itson-tree parent node as the predecessor on the shortest path from the multicast source s to thenode itself or one of such predecessors if there are multiple such choices available. The resultingstructure by such iterative operations at intermediate nodes is therefore an SPT rooted at thesource. Note again that the structure resulted by DSPT is a source-rooted SPT. The on-tree pathconnecting the source and each group member is the shortest path from the source to thecorresponding member. This resulted structure is not a reverse SPT like DVMRP builds.

The tree-constructing process in DSPT operates as follows. For a new member to join acurrently on-going multicast session, it makes a local decision on selecting which neighbouringnode as its on-tree parent node for it to connect to the existing tree and then sends a join requestto the parent node that it selects. Routers receiving the join request repeat this operation untilthe request reaches an on-tree router (or the source). A source-rooted SPT can be built as aresult of such collaborative operations at intermediate routers.

The DSPT protocol consists of two major operations: member joining and member leaving.The joining operation specifies the procedures for a new member to join a currently on-goingmulticast session. The leaving operation is enforced when a member leaves a group.

2.3.1. Joining operation. The joining operation is initiated by a host wishing to join a currentlyon-going multicast session. To join a group, the host sends a join request identifying a particulargroup via an IGMP-report message [12] to the DR of the local subnet to which it is attached.

Figure 1 gives the procedures at the DR router and at an intermediate router, say x, when xreceives such a join request. If router x has already been added onto the existing tree built for theparticular group (for relaying multicast datagrams as an intermediate router for other groupmembers), router x simply adds the physical interface} for it to reach the joining host (or therouter that sent x the request) as an additional outgoing interface to forward multicastdatagrams of the group (see Steps 1–2 in Procedure RcvReq in Figure 1); otherwise router x is

}Such an interface can be either connected to a point-to-point link or a multiaccess link.



DOI: 10.1002/dac

not on the tree yet. For the latter case (see Steps 3–5), x first creates a new multicast forwardingentry (including group/source, incoming interface, and outgoing interface set) for the particulargroup. The only item in the outgoing interface set at this moment is the interface for reachingthe host (if x is the DR router) or the router (if x is an intermediate router) from which xreceived the join request. The incoming interface is the interface, from which x will receivedatagrams from the on-tree parent node to x, as well as to which this request will be forwarded.The parent node is decided by calling Procedure ParentSelection(), which operates as follows. Ifmultiple predecessors are available along the shortest paths from source s to x, random or roundrobin selection is applied to facilitate load balancing; otherwise, the only one is chosen. Router xthen forwards the request to the selected parent node to continue the joining process. In thisway, DSPT explicitly supports equal-cost multipath (ECMP) to facilitate load balancingwithout introducing additional control overhead. Since multicast datagrams of a group arealways forwarded along a single delivery tree, this ECMP support will not lead to the problemof out-of-order multicast datagram delivery. Each intermediate node receiving the requestrepeats the same operation given in Figure 1 until an on-tree router or the source is reached.

s:G:X:T:

Procedure RcvReq(s,G,x,y,T)1. if x ∈T2. then x adds the interface for x to reach y as an additional interface in its outgoing interface set in

the entry for group identified by G.3. else X←ParentSelection(x,s)4. Creates a new multicast forwarding entry with the following information.

Indentifier of source and group s/G;– incoming interface: The interface connecting X and x;– The only item in the outgoing link set: the interface leading to (x,y)

5. Sends the join request to the selected parent X to continue the join process 6. end RcvReq

/* return a predecessor of x along a shortest path from s to x */ /* Here we consider strongly connected networks only */ Procedure ParentSelection (x,s)

1. if 1>sxPREV //more than one predecessors available

2. then return one of sxPREV using either random or in round-robin selection

3. else return the only item in sxPREV

4. end ParentSelection

Indentifier of the multicast sourceIndentifier of the multicast group addressThe parent node that node x selects to send the join request. The multicast tree that has already been built for the group <s,G>.

–

Figure 1. Operations of DSPT for a router x 2 V to perform to continue a join process upon receiving ajoin request from a host or a router y:



DOI: 10.1002/dac

Figures 2 and 3 give an example illustrating the joining operation in DSPT. Suppose that weneed to construct a tree covering a multicast source s and a set of multicast destinations fx; yg:Figure 2 depicts the procedures that DSPT takes to build an SPT for the multicast group.Without loss of generality, we suppose that y first requests to join the multicast session before x.Since y is not part of the delivery tree, it initiates a join procedure by sending a join request tonode v; which is the predecessor of y on the shortest path Pðs; yÞ from source s to y and also theon-tree predecessor that node y selects by locally running the ParentSelection procedure as givenin Figure 1 (see Figure 3(b)). Note that in Figure 3 the arrow of a link connecting a pair of nodesrepresents the direction of the link on the resulting tree. The join request travels in the reversedirection from the downstream end point y of link ðy; vÞ to the corresponding upstream endpoint v; because the joining operation in DSPT is destination initiated. Note that the next hop ofy to s along the shortest path Pðy; sÞ is u. Upon receiving the join request, v and w, sequentially,

s

x

w

u

v

y

51

21

21

5

5

10

1

5

10

10

5

Labels on links are link costs

Figure 2. An example graph.

s

x

w v

y

2

2

5

5

y

v

y

5 w v

y

5

5

s

w v

y

2

5

5

(a) (b)

(d)

(c)

(e)

Figure 3. Application of DSPT to the example graph shown in Figure 1. The multicast request has asource node s; and a set of destinations fy; xg: The tree shown in (e) is the constructed tree that spans

members of multicast request.



DOI: 10.1002/dac

repeats the same join procedure until source s receives the request (see Figures 3(c) and (d)).Then, x has a request to join the group. It will send a join request upstream to its predecessor onthe shortest path P(s, x) from the source s to x, i.e. w, which is already on the delivery tree.Figure 3(e) shows the delivery tree that DSPT builds as a result of sequential processing of thetwo join requests.

2.3.2. Leaving operation. The leaving operation is for a member to leave a group. When the lastlocal host of a DR router leaves an earlier subscribed group, the router will stop forwardingdatagrams belonging to the multicast session to its local subnet. Moreover, it will send a prunemessage to its on-tree parent node if it is a leaf router of the forwarding tree. Upon receivingthe prune message, the router to leave, the intermediate routers and links are removed from themulticast tree connection if they are used only for the member being removed. Obviously, theabove operation for a member to leave will not affect other (remaining) members’ receivingmulticast datagrams along their respective shortest paths from the multicast source.

Further, in the implementation of DSPT, link state dynamics do not cause reconstructions ofexisting trees built for on-going multicast sessions, as in most existing multicast routingprotocols. This is because such reconstruction can cause severe service disruption and maycreate the stability problem concerning traffic oscillation as observed in datagram networksusing adaptive routing based on shortest paths [13]. Upon the occurrence of topology change,each of those disconnected group members need to enforce a re-joining process to stay in thegroup.

3. ANALYTICAL RESULTS

In this section, we compare, through comprehensive analysis, the performance of the DSPTprotocol and the MOSPF protocol, which is currently the only protocol employed to constructsource-rooted SPTs in the Internet.

In terms of resource utilization, it is obvious that DSPT and MOSPF are the same becauseboth protocols build source-rooted SPTs. That is, the unique path from the source of a group toeach member of the group on a tree that either protocol builds is the shortest path from thesource to the corresponding member. This property also distinguishes DSPT from DVMRP,which builds reverse-SPTs by performing reverse path forwarding (RPF) at routers.

The main difference between MOSPF and DSPT is that MOSPF builds multicast trees in atop-down manner while DPST constructs trees in a bottom-up manner. This difference can leadto significant difference in terms of protocol overhead associated with tree constructionsbetween DSPT and MOSPF. Next, we present comprehensive analysis to compare the protocoloverhead in terms of computation, communication, and storage associated with treeconstructions using MOSPF and DSPT, respectively. Table I gives a summary of the symbolsto be used in the analysis.

3.1. Computational overhead

We first discuss the incremental SPT approach designed to reduce the computational overheadfor building and updating SPTs in the presence of network dynamics and then focus on itsrelationship with multicast tree constructions.



DOI: 10.1002/dac

3.1.1. Incremental SPT. Incremental SPT (e.g. [14–16]) has been designed as an effectivestrategy to achieve faster OSPF convergence as the network state evolves and to save CPUresources. Traditionally, each OSPF router uses Dijkstra’s algorithm to calculate the shortestpath from itself to other nodes. The calculated result is an SPT rooted at the calculating nodeand covering all other nodes in the network. Upon detecting a change of the network state, theroot node deletes the old tree and calculates a new SPT starting from the scratch usingDijkstra’s. The motivation behind incremental SPT is that in many cases a change of thenetwork state affects only a minor part of a SPT or even does not affect the tree at all. In thiscase, calculating a new SPT starting from the scratch by using a static algorithm (e.g. Dijkstra’s)is neither efficient nor necessary because such a calculation does not take advantage of theavailable information about the outdated SPT.

For this reason, incremental SPT is designed to start from the outdated tree to create a newtree upon a change of the network state. To accelerate routing convergence, it is reasonable torequire an OSPF router to maintain the entire structure of the outdated SPT rooted at therouter itself since this tree coincides with the forwarding table that the router maintains. Anextra piece of information required is the predecessor information for every other router to tracethe entire tree with a total extra storage overhead of jV j � 1 items. Incremental SPT has alreadybeen available as a practical option in implementing the OSPF protocol for improvedperformance.

Obviously, DSPT can utilize incremental SPT to further reduce the computational burden atrouters for computing the vector information specified in Section 2.1. The pre-condition for arouter to implement incremental SPT is that each node maintains the entire structure of the sinktree pointed to the router itself. For this purpose, one additional item is required to store thenext hop information from each possible source to the sink in the distance vector informationspecified in Section 2.1. With this information, the sink can locally trace the entire sink tree. Theextra storage overhead for this purpose is jV j � 1:

With MOSPF, however, the situation is quite different. This is primarily because an MOSPFrouter is not required to maintain the entire structures of those trees that pass through therouter. Instead, an on-tree router maintains only the incoming and outgoing link set on thedelivery tree. To utilize incremental SPT at an MOSPF router to reduce its computationaloverhead for tree management, the router must locally maintain the entire tree structures of allthose ‘pass-by’ multicast sessions. The corresponding extra storage overhead will jump tojMj � jT j2=jV j; or else a router keeps track of the shortest path spanning trees rooted at each ofthe other routers in the network in the presence of network dynamics. The latter option canintroduce extra storage overhead of jV j � ðjV j � 1Þ to store every other node’s forwarding table

Table I. Symbols.

jV j The number of nodes in the networkjEj The number of edges in the networkjMj The average number of simultaneously on-going multicast sessions in the networkr The average number of new requests injected into the network per unit time intervalx The average number of network dynamics per unit time intervald The average number of group dynamics during the life time of a multicast session, d50jT j The average number of nodes on a tree, 34jT j4jV jjSj The average number of destinations in a group, 24jSj4jV j � 1 and jSj5jT j



DOI: 10.1002/dac

and jV j times of computational overhead for the forwarding table updating. In general, neitherof the above tradeoffs is practical in reality, which will not be discussed further hereafter.

3.1.2. Qualitative comparison. In terms of computational overhead at routers implementingDSPT or MOSPF, we compare the average number of Dijkstra’s invocations for providingmulticast per unit time interval observed at routers.

To calculate the additional vector information as specified in Section 2.1, a DSPT router canrun Dijkstra’s algorithm or uses an incremental SPT algorithm in the backward direction. Weassume that Dijkstra’s algorithm is used in the calculation, which gives us a conservativeestimation of the computational overhead at a DSPT router. In contrast, with MOSPF, tolocally determine its position on an SPT passing through a router, a router needs to invoke onerun of Dijkstra’s SPT algorithm. Each execution of Dijkstra’s algorithm takes a computationaltime of OðjV j2Þ or OðjV jlogjV j þ EÞ if Fibonacci heaps are used. In a large time scale, however,the overall computational overhead associated with tree constructions at a DSPT router is afunction of the rate of (significant) changes in the network state. In contrast, the resultedcomputational overhead at an MOSPF router is a function of the rate of the connection requeststhat the router receives (including both requests originated from the router and those whosedelivery trees pass through the router). In most typical situations, where the rate of connectionrequests is significantly higher than that of (significant) changes of the network state,constructing delivery trees using DSPT can significantly reduce computational overheadcompared with that using MOSPF.

3.1.3. Quantitative comparison. With MOSPF, a multicast session with a delivery treeconsisting of a total number of jT j on-tree nodes introduces jT j runs of Dijkstra’s SPTcalculations, once at each of the on-tree nodes. Suppose that new multicast sessions arrive at arate of r connection requests per unit time interval. The total number of SPT calculations will berjT j; overtaken by the jV j nodes in the network. Consider a situation where group dynamicsoccur at an average rate of d times per session. Upon detecting a membership dynamics,MOSPF has to remove the old tree and then builds a new delivery tree starting from scratch. Asa result, these r requests introduce a total number of rjT jð1þ dÞ runs of SPT calculations, whered is typically a small non-negative integer. In the steady state, the overhead caused by groupdynamics of these r requests arriving in the current unit time interval in the subsequent intervalsis equivalent to the overall overhead caused by group dynamics of those requests arriving inearlier intervals in the current interval. Therefore, the number of SPT calculations enforced atan MOSPF router per unit time is, in average, equal to rð1þ dÞjT j=jV j:

In contrast, with DSPT, the computation for calculating the additional cost vector at a routercan be executed either upon a (significant) change of the network state or upon the arrival of thefirst join request. In either case, the router locally maintains the computed results for subsequentarriving join requests (if any) until it detects the next network state dynamics. With DSPT, thecomputational overhead for an intermediate node to select its parent node upon receiving a joinrequest is Oð1Þ and can thus be ignored. Therefore, the overall computational overhead at aDSPT router is x times of Dijkstra’s calculations per unit time interval irrespective of the arrivalrate of multicast requests, where x is the average rate of network state dynamics.

If r > xjV j=jT jð1þ dÞ; the computational overhead at an MOSPF router is higher than that ata DSPT router for providing multicast. In a practical environment where multicast requestsarrive at a high rate, r is much larger than x, the value of jT j is comparable to that of jV j; and d is



DOI: 10.1002/dac

a small non-negative integer. Therefore the computational overhead at an MOSPF router issignificantly higher than that at a DSPT router. Table II gives an overall comparison of theprotocol overhead associated with both protocols.

3.2. Communication overhead

In terms of communication overhead, we compare the average number of control messages usedfor building and maintaining an SPT created for a multicast session using either protocol,during the lifetime of the session.

The DSPT protocol avoids the network-wide dissemination of group-specific membershiprequired by MOSPF. In contrast, the identifiers of the group source and the group are enough toimplement the destination-initiated join operations. On the other hand, to construct a treeconsisting of jT j nodes, DSPT introduces a number of jT j � 1 join messages for all the potentialmembers to join a particular multicast session. In MOSPF, however, this type of controlmessage is not needed because of the data-driven nature of MOSPF.

The average number of control messages for building a tree using MOSPF is ðjSj þ 1ÞjEj for agroup with a source and a number of jSj multicast destinations, for network-wide disseminationof group-specific-LSAs. This overhead can be reduced to ðjSj þ 1ÞðjV j � 1Þ if minimum spanningtree (MST) or SPT structure is used for network-wide dissemination of such membership LSA-reports because either of the latter methods is more communication efficient than pure flooding.With DSPT, the communication overhead for each potential member to learn the addresses ofthe multicast group and the source can be either jEj if pure flooding is used or jV j � 1 if eitherMST- or SPT-structure is used for information dissemination. To make a fair comparison, weassume that such information is proactively disseminated to each potential member at the costof communication overhead. An alternative way is to query a known sever for such informationin an on-demand manner at the expense of initial join latency. For each group dynamics,MOSPF introduces jV j � 1 control messages to disseminate the group membership change,while DSPT incurs a number of DT join or prune messages for a new member to join or for anexisting member to leave. Typically, DT is a small integer since DT ¼ 0 for a non-leaf on-treenode to join or to leave. Therefore, the control messages generated for building and maintaininga delivery tree associated with MOSPF is ðjSj þ 1þ dÞðjV j � 1Þ and that associated with DSPT isðjV j � 1þ jT j � 1þ dnDTÞ ¼ ðjV j þ jT j � 2þ dnDTÞ: It is easy to see that ðjSj þ 1þ dÞðjV j �1ÞbðjV j þ jT j � 2þ dnDTÞ: Therefore, the communication overhead associated with DSPT ismuch lower than that associated with MOSPF.

Table II. Comparisons of average protocol overhead associated with MOSPFand DSPT protocols, respectively.

Protocol overhead MOSPF DSPT

Computational overhead at a routerrð1þ dÞjT jjV j

x

Number of control messages needed to build an SPT ðjSj þ 1þ dÞðjV j � 1Þ (jV j þ jT j � 2þ dnDT)

Storage overhead at a router jMjðjSj þ 1Þ jMj þ jV j � 1ECMP support No Yes



DOI: 10.1002/dac

3.3. Storage overhead

To maintain the additional cost vector information at a node, as specified in Section 2.1, DSPTgenerates an additional number of jV j � 1 labels in each router’s routing table at a time, which isused to keep track of predecessors on the shortest paths from each possible source node. On theother hand, with DSPT, a router does not need to maintain any group-specific membership.With MOSPF, the memory space needed for maintaining group-specific membership is as highas jMjðjSj þ 1Þ: With DSPT, however, the memory space required for maintaining the groupsource information is only jMj; one item per group. The storage space at a DSPT router istherefore jV j � 1þ jMj: Obviously, we can see that jV j � 1þ jMj5jMjðjSj þ 1Þ; or jV j5jMjjSj;when jMj is large.

In the above analysis, we did not count the storage overhead for maintaining multicastforwarding entries at routers. The overhead associated with both protocols for this purpose isthe same, i.e. one group-specific forwarding entry at a router whose delivery tree passes throughthe router, and the information kept in each of such entries is the same for both protocols, whichincludes the identifiers of the source and the group, an incoming interface, and a set of outgoinginterface(s). The storage overhead associated with either protocol to maintain multicastforwarding entries at a router is, in average, jMjjT j=jV j:

3.4. ECMP (equal-cost multipath) support

DSPT supports ECMP, which can facilitate load balancing. With MOSPF, however, toguarantee all routers to be able to return an identical SPT for a given multicast group in adecentralized manner, ECMP is explicitly prohibited. DSPT is flexible because each node makesa local routing decision on the selection of its on-tree parent node. The correct selection of aparent at each node forms a source-rooted SPT as a result.

The above comprehensive quantitative analysis indicates that DSPT outperforms MOSPF interms of computation, communication, and storage overhead, respectively. In addition, suchimprovement comes at no additional control overhead in building or maintaining SPTs.

4. SIMULATION RESULTS

In this section, we conduct simulations to further verify the analytical results obtained in thepreceding section. The simulations were implemented using a time-based simulation method inwhich at each discrete clock tick statistic data were collected. For each measured value in thesimulation results, each of the protocols under study was run repeatedly with new randommulticast requests until a 5% confidence interval with a 95% confidence level was achieved. Foreach multicast request, the multicast source and the set of multicast destinations were randomlyselected. As for group dynamics, we consider a situation where a request can be either a join or aleave. To determine whether the next request is a join or a leave, the following function is used,which is similar to that introduced in [17]

PaðkÞ ¼aðn� kÞ

aðn� kÞ þ ð1� aÞkð1Þ

where n is the number of nodes in the network, k is the number of group member nodes on thecurrent tree, and a is the fraction of group member nodes on the tree at equilibrium. We then



DOI: 10.1002/dac

generate a random number rnd ð05rnd51Þ: If PaðkÞ5rnd; the next request is a leave andrandomly one of the group members on the current tree is determined as the node to beremoved; if PaðkÞ5rnd; the next request is a join request and a non-group member is randomlyselected as the node to be added. In the simulations, a was set to 0.15 and we changed groupdynamics rate to observe the associated protocol overhead in different scenarios.

The connection arrival process is Poisson in all experiments. The holding time of each sessionis exponentially distributed. Table III summarizes the key parameters associated with each dataset generated in the experiments. The fourth row in Table III gives, in the steady state, the meannumber of simultaneously on-going multicast sessions in the network under each parametersetting. We believe that 508 and 1030 are reasonably large numbers for studying the scalabilityof a routing protocol with respect to the number of concurrent multicast sessions.

The simulation was run on the example network shown in Figure 4. Each link was assigned acost value randomly selected in the range [1, 10]. Table IV shows the simulation results, forwhich we make the following explanations. In terms of computational overhead, what is shownas the average number of Dijkstra’s invocations at a DSPT router per minute are not obtainedin our simulations. Instead, it is mainly based on the experimental results presented in [7, 18] andcan be explained as follows. First, according to the OSPF protocol, LSAs are refreshed at aminimum of every 30min [7]; and second, Dijkstra’s SPT calculations caused by network statedynamics are usually executed very infrequently in operational deployments. In the networksstudied in [18], Dijkstra’s algorithm is invoked on average at a rate of once per 13–50min, inwhich case we have the average rate of network state dynamics x4 1

13: Recall that if incremental

SPT is implemented at routers, this computational overhead can be further reduced.

Table III. Descriptions of the data sets used in the simulations.

Data set 1 Data set 2

Mean session holding time (minute) 22.0 33.1New request arrival rate (per minute) 23.2 31.1Mean number of concurrent sessions inthe network with the above settings

508 1030

0

1

2

3 4

5

67

8

9

1011

12

13

14

15

16

17

18

19

20

21

22 23

24

2526

27

2829

30

31

Figure 4. Example network.



DOI: 10.1002/dac

TableIV

.Sim

ulationresultsfordifferentexperim

ents.

Meannumber

ofSPT

calculationsatarouterper

minute

Meannumber

of

controlmessages

per

group

Meannumber

of

entrieskeptatarouter

Initialgroupsize

510

510

510

Group

dynamic

rate

d1

35

36

91

35

36

91

35

36

9

Data

set1DSPT

1/13

1/13

1/13

1/13

1/13

1/13

42.7

46.1

49.6

50.6

53.6

56.4

534

534

541

540

539

537

MOSPF

15.7

31.4

47.7

51.7

93.8

137.5

186

248

310.7

403

497

590

253625462635

5424

5702

5992

Data

set2DSPT

1/13

1/13

1/13

1/13

1/13

1/13

42.7

46.2

49.6

50.7

53.6

56.4

102610291033

1033

1022

1029

MOSPF

21.2

42.2

64.4

70.4

126

184.9

186.2

248.4

310.6

403

497

590

513351745300109101137812123



DOI: 10.1002/dac

With MOSPF, the computational overhead at a router increases with the new request arrivalrate and also with the group size because the tree size increases with the group size. In Table III,we can see that the mean value of the new request arrival rate for data sets 1 and 2, denoted by r1and r2; respectively, is 23.2 and 31.1 new arrivals per minute. Consequently, the computationaloverhead at a router resulted from data set 2 is r2=r1 ¼ 31:1=23:2 ¼ 1:34 times over that resultedfrom data set 1, as observed in Table IV. Here, we see that the mean session holding time doesnot affect computational overhead at the routers in our parameter settings. In Table IV, we canalso see that the computational overhead at an MOSPF router is proportional to ð1þ dÞ andincreases with the group size jSj: As a result, we observe a much heavier calculation burden at anMOSPF router than that at a DSPT router. Furthermore, even considering a more dynamicnetwork environment such that network dynamics occurs at a higher frequency, we still havethat DSPT outperforms MOSPF in terms of computational overhead as long as the rate of suchdynamics x516 in our simulations.

In terms of the average number of control messages introduced per group, in Table IV, wecan see that this overhead associated with MOSPF is proportional to jSj þ 1þ d: With DSPT,group dynamics leads to an insignificant increase in communication overhead since each joiningor leaving operation usually involves a small amount of control message exchange. Thus,MOSPF introduces a much higher communication overhead than DSPT does.

In terms of the storage overhead at a router, the number of entries stored at a DSPT router isthe mean number of concurrent multicast sessions plus jV j � 1:While for MOSPF, the necessityfor maintaining full group-specific information at each router makes the storage space large.This overhead increases slightly with the group dynamics rate as observed in Table IV. Thisis because the size of a group slightly deviates from the initial size setting (increases) underthe current membership dynamic model and parameters, and results in a slight increasedstorage space.

From the results shown in Table IV, we draw a conclusion that the number of controlmessages introduced per group or storage entries kept at a DSPT router is approximately1=ðjSj þ 1Þ of that at an MOSPF router.

In summary, we can see that the simulation results perfectly verified our analytical results inSection 3. Therefore, DSPT significantly reduces the protocol overhead with respect to thecomputation, communication, and storage space associated with SPT constructions. Theseproperties enable DSPT scale well to the number of concurrent multicast sessions.

5. CONCLUSIONS

Scalability is a great concern in designing multicast routing protocols for the global Internet. Toprovide scalable multicasting, SPT is currently the most widely used multicast tree type becauseof its simplicity, and low per-destination cost or delay property. In this paper, we presented adestination-initiated multicast routing protocol (DSPT). The objective of this protocol is toeffectively reduce the protocol overhead associated with SPT constructions in supportingscalable multicasting. To achieve this objective, destination-initiated join operations areemployed in DSPT. With DSPT, each intermediate node receiving a join request makes a localdecision on selecting its parent node in order for it to connect to the existing tree, with theassistance of an additional distance vector that it locally computes. An SPT can be built as aresult of such collective hop-by-hop operations at intermediate nodes. DSPT supports dynamic



DOI: 10.1002/dac

group membership well and also supports ECMP to facilitate load balancing withoutintroducing additional control overhead.

The analytical and simulation results have shown that DSPT outperforms the existingmulticast routing protocol MOSPF in terms of computation, communication, and storageoverhead, and ECMP support. The destination-initiated joining technique used in DSPT canalso be embedded into the PIM-SM protocol to facilitate the transformation of a multicastdelivery structure from a shared tree to a source-specific SPT. We also demonstrated that DSPTcan work with incremental SPT to further reduce the computational overhead at routers, aproperty that MOSPF does not have. Due to these facts, DSPT is a simple, practical, andscalable multicast routing protocol to be employed in the Internet.

REFERENCES

1. Garey MR, Johnson DS. Computer and Intractability: A Guide to Theory of NP-Completeness. CW. H. Free-manand Company: NY, 1979.

2. Ballardie A. Core based trees (CBT) multicast routing architecture. IETF RFC 2201, Experimental, September 1997.3. Winter P. Steiner problem in networks: a survey. Networks 1987; 17(2):129–167.4. Hwang FK, Richards DS. Steiner tree problems. Networks 1992; 22:55–89.5. Waitzman D, Partridge C, Deering S. Distance vector multicast routing protocol. IETF RFC 1075, November 1988.6. Moy J. Multicast extensions to OSPF. IETF RFC 1584, standard track, March 1994.7. Moy J. OSPF version 2. IETF RFC 2328, standard track, April 1998.8. Estrin D, Farinacci D, Helmy A, Thaler D, Deering S, Handley M, Jacobson V, Liu C, Sharma P, Wei L. Protocol

Independent Multicast-Sparse Mode (PIM-SM): protocol specification. IETF RFC 2362, Experimental, June 1998.9. Fenner B, Handley M, Holbrook H, Kouvelas I. Protocol Independent Multicast-Sparse Mode (PIM-SM): protocol

specification (Revised). IETF Internet-draft 5draft-ietf-pim-sm-v2-new-11.txt>; October 2004, work in progress.10. Fenner B, Meyer D. Multicast source discovery protocol (MSDP). IETF RFC 3618, Experimental, October 2003.11. Cormen TH, Leiserson CE, Rivest RL. Introduction to Algorithms. MIT Press: Cambridge, MA, 2001.12. Cain B, Deering S, Kouvelas I, Fenner B, Thyagarajan A. Internet group management protocol, version 2. IETF

RFC 3376, standard track, October 2002.13. Bertsekas D, Gallager R. Data Networks. Prentice-Hall: Englewood Cliffs, NJ, 1992.14. Frigioni D, Marchetti-Spaccamela A, Nanni U. Incremental algorithms for single-source shortest path trees.

Proceedings of the Foundations of Software Technology and Theoretical Computer Science, Madras, India, December1994; 113–124.

15. Narvaez H-YTP, Siu K-Y. New dynamic algorithms for shortest path tree computation. IEEE/ACM Transactionson Networking 2000; 8(6):734–746.

16. Xiao B, ZhuGe Q, Sha EH-M. Minimum dynamic update for shortest path tree construction. Proceedings of IEEEGLOBECOM’01, San Antonio, TX, November 2001; 126–130.

17. Waxman BM. Routing of multipoint connections. IEEE Journal on Selected Areas in Communications 1988;6(9):1617–1622.

18. Moy J. OSPF protocol analysis. IETF RFC 1245, July 1991.

AUTHORS’ BIOGRAPHIES

Baoxian Zhang ([email protected]) received his BS, MS, and PhD degrees in

Electrical Engineering from Northern Jiaotong University, Beijing, China in 1994,

1997, and 2000, respectively. From January 2001 to August 2002, he was working

with Department of Electrical and Computer Engineering at Queen’s University in

Kingston as a postdoctoral fellow. He is currently a research scientist with the School

of Information Technology and Engineering (SITE) of University of Ottawa, Ottawa,

Ontario, Canada. He has published over 40 refereed technical papers in international

journals and conference proceedings. His research interests include routing algorithm

and protocol design, wireless ad hoc and sensor networks, optical networks,

multicast, and performance evaluation. He is a member of the IEEE.



DOI: 10.1002/dac

Jun Zheng ([email protected]) is a research scientist with the University of Ottawa,

Canada. He received his PhD in Electrical and Electronic Engineering from The

University of Hong Kong, China. He has conducted extensive research in the field of

telecommunications and computer networks, ranging from IP networks to ATM

networks, optical networks, and wireless networks. His research interests include

design and analysis of network architectures and protocols for efficient and reliable

communications. He is the first author of the book Optical WDMNetworks: Concepts

and Design Principles, and has published over 40 papers in international journals and

conference proceedings. He is Lead Guest Editor for a special issue on wireless sensor

networking of IEEE Network and Lead Guest Editor for a feature issue on optical

access networks of OSA Journal of Optical Networking (JON). He is serving as

Technical Program Committee (TPC) Chair for 2005 International Conference on Sensor Networks

(SENET’05) and has served on the technical program committees of many international conferences,

including IEEE ICC and GLOBECOM. Dr Zheng is a member of the IEEE.

Hussein T. Mouftah joined the School of Information Technology and Engineering

(SITE) of the University of Ottawa in September 2002 as a Canada Research Chair

(Tier 1) Professor in Optical Networks. He has been with the Department of Electrical

and Computer Engineering at Queen’s University (1979–2002), where he was prior to

his departure a Full Professor and the Department Associate Head. He has three years

of industrial experience mainly at Bell Northern Research of Ottawa, now Nortel

Networks (1977–1979).

He has spent three sabbatical years also at Nortel Networks (1986–1987, 1993–1994,

and 2000–2001), always conducting research in the area of broadband packet switching

networks, mobile wireless networks and quality of service over the optical Internet. He

served as Editor-in-Chief of the IEEE Communications Magazine (1995–1997) and

IEEE Communications Society Director of Magazines (1998–1999) and Chair of the Awards Committee

(2002–2003). He is a Distinguished Speaker of the IEEE Communications Society since 2000.

Dr Mouftah is the author or coauthor of five books, 22 book chapters and more than 700 technical papers

and eight patents in this area. He is the recipient of the 1989 Engineering Medal for Research and

Development of the Association of Professional Engineers of Ontario (PEO), and the Ontario Distinguished

Researcher Award of the Ontario Innovation Trust. He is the joint holder of the Best Paper Award for a

paper presented at SPECTS’2002, and the Outstanding Paper Award for papers presented at the IEEE

HPSR’2002 and the IEEE ISMVL’1985. Also he is the joint holder of a Honorable Mention for the

Frederick W. Ellersick Price Paper Award for Best Paper in the IEEE Communications Magazine in 1993.

He is the recipient of the IEEE Canada (Region 7) Outstanding Service Award (1995). Also he is the recipient

of the 2004 IEEE Communications Society Edwin Howard Armstrong Achievement Award, and the 2004

George S. Glinski Award for Excellence in Research of the Faculty of Engineering, University of Ottawa. Dr

Mouftah is a Fellow of the IEEE (1990), the Canadian Academy of Engineering (2003) and the Engineering

Institute of Canada (2005).



DOI: 10.1002/dac

a scalable multicast routing protocol for building shortest path trees

Documents