qos multicast routing using explore best path

www.elsevier.com/locate/comcom

Computer Communications 29 (2006) 2881–2894

QoS multicast routing using Explore Best Path

Jaipal Singh, Prakash Veeraraghavan *, Samar Singh

Applied Computing Research Institute, Department of Computer Science and Computer Engineering, La Trobe University, Victoria 3086, Australia

Available online 7 April 2006

Abstract

One of the most active research areas in networking is quality of service (QoS). The most fundamental requirement for QoS is theability to find a path that can provide the required network resources between two nodes. These nodes will use QoS routing to find afeasible QoS path between both of them. In this paper, we present a distributed multicast QoS routing architecture that uses probesto find a quick and scalable QoS path between a joining router and the multicast tree. Any router that receives this probe will only knowits neighbours and it will create a link to the previous router from where the probe comes from. The joining router will join the multicasttree by following these links on each router until it reaches the tree. Analysis of this method shows that the convergence rate and messageoverhead is lower than other similar schemes.� 2006 Elsevier B.V. All rights reserved.

Keywords: Quality of service; QoS routing; QoS multicasting; Multicast

1. Introduction

In the Internet, a sender will create a connection withone receiver and send a unicast data packet to that receiver.In the case of group communication where more than onereceiver accesses the same data, the sender will create aconnection for each receiver and send a copy of the samedata to each receiver. Network resources are wasted when-ever multiple copies of the same data travel along a com-mon link to reach these receivers.

Multicast was introduced as a more efficient way ofimplementing group communication in an IP network. Ina multicast network, a sender only has to send one datapacket which will be duplicated and forwarded at branch-ing points to multiple receivers in the network. This savesnetwork resources since only one packet is sent on a com-mon link. The networking community has done a lot ofresearch on multicast communications and the IETF havecome up with local membership management protocols likeIGMPv3 [1] for IPv4 and MLDv2 [2] for IPv6 networks,

0140-3664/$ - see front matter � 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2006.03.011

* Corresponding author.E-mail addresses: [email protected] (J. Singh), p.veera@

latrobe.edu.au (P. Veeraraghavan), [email protected] (S. Singh).

routing protocols [3–6], quality of service mechanisms[7,8] and security architectures [9].

Quality of service (QoS) is a widely researched topic asmore and more real-time multimedia content is sentthrough the network. QoS is the ability for a network toprovide the resources required for selected network trafficto reach their destination successfully without causingother best-effort network traffic to fail. QoS is generallystated as a number on each edge of a network graph.The aim of QoS multicast routing is to find a path froma sender to one or more receivers along these edges thatmeets the QoS requirement. The most commonly usedQoS performance parameters are latency, delay variation(jitter), throughput and packet loss rate [10].

There are currently two types of multicast trees – asource-based tree (SBT) and a shared tree (ShT) [11]. Agroup using SBT builds a shortest path tree from one send-er (source) to all the receivers in the multicast group. In aShT approach, both the senders and receivers share thesame tree which is rooted at a core node. All the receiversand senders on the tree will be connected along the shortestpath from themselves to the core. A SBT has been imple-mented for both dense mode and sparse mode networks,though SBT has a scalability problem if the number of

mailto:[email protected]




2882 J. Singh et al. / Computer Communications 29 (2006) 2881–2894

senders increase since a separate tree has to be built foreach sender. The ShT method was developed to overcomethe scalability issues faced by a SBT although ShT suffersfrom increased delay and traffic concentration at the core.

A lot of research has been done into finding an optimalQoS path from a joining node to the multicast tree. Mostof these QoS routing heuristics were for dense-mode andsparse-mode SBTs. QoS probes were used to find a QoSpath in a ShT multicast group. Refer to [12,13,15,14] fordetails on these heuristics and QoS probes.

In this paper, we are proposing a general distributedmulticast QoS routing architecture that uses probes to finda path from a joining router to a sparse mode multicast tree(SBT or ShT). Through theoretical and simulation work,we will show that our multicast QoS probe architecturecan find a successful path quicker than the previous QoSprobe schemes. This is especially important for applica-tions running on mobile devices [16–18].

The remainder of the paper is organized as follows: anintroduction of the QoS routing problem and previouswork by other researchers into multicast QoS probes areexplained in Section 2. In Section 3, we describe our multi-cast QoS probe architecture. Section 4 will provide theoret-ical and simulation results of our proposed QoS probearchitecture along with comparison with earlier works. Sec-tion 5 concludes this paper.

2. Problem statement

All of the QoS parameters like latency, jitter andthroughput can be quantified by using three types of met-rics, i.e., additive, multiplicative and concave. We denotethat for a path P(i1,in), the QoS metric for that path wouldbe m(i1, in).

An additive metric is the sum of the individual QoS met-ric along a network path. An example of QoS additive met-rics is end-to-end delay (latency), which is the sum of thetransmission delays across each link and the processingdelays of each router. Delay jitter and logarithm of proba-bility of successful transmission are other examples of QoSadditive metrics.

A multiplicative metric is the product of the individualQoS metrics along a path. An example of QoS multiplica-tive metrics would be the probability of successful trans-mission and reliability. Metrics of this type can bechanged into an additive metric by taking theirlogarithms1.

A concave metric would be either the maximum or min-imum QoS metric of all the individual QoS metric along apath. An example of QoS concave metrics would be theminimum available bandwidth.

1 The objective of a function measuring multiplicative metrics is tomaximise the value of the metric at every edge. Djikstra’s algorithm canstill be used – even if the logarithm of the probabilities returns a negativevalue – because it will find the path with the maximum probability ofsuccess, when we use the negative of the log.

These QoS metrics can be very precisely representedmathematically as shown below.

Additive Metric:
m(i1,in) = m(i1,i2) + m(i2,i3) + � � � + m(in�1,in)Multiplicative Metric:m(i1,in) = m(i1,i2) Æ m(i2,i3) Æ � � � Æ m(in�1,in)Concave Metric:m(i1,in) = min[m(i1,i2),m(i2,i3),. . .,m(in�1,in)
Since current routing protocols only find the shortest-path between two nodes, they will have to be extendedto support these other metrics. Based on these metricsand the network state information, a QoS routing proto-col can be used to find one or more feasible QoS paths.The QoS path is a path bounded by one or more con-straints. However, finding a path that satisfies multipleQoS constraints might not be solvable in polynomialtime. [19] lists the combinations of multiple QoS con-straints that can and cannot be solved in polynomialtime.

Besides finding feasible paths, a QoS routing mechanismalso needs to establish a QoS path based on the paths iden-tified and to maintain the path for the duration of the QoSsession [20].

In this paper, we will only look at QoS probing methodsfor finding a feasible QoS path. We will not look at mech-anisms to establish and maintain the QoS path. These mul-ticast QoS probes are used for finding a feasible path to thetree based on single, dual or multiple metrics. For simplic-ity, this paper will look at the delay (additive) and mini-mum bandwidth (concave) metric although our approachcan also find QoS paths for other types of additive, multi-plicative and concave metrics.

Latency or delay is the time a packet takes to travelfrom the source node to the destination node. Real-timeinteractive applications like video conferencing and voiceover IP (VoIP) cannot tolerate long delays because the con-versation between the sender and receiver becomesimpractical.

Delay in a multicast tree is a tree-constrained routingproblem. The delay from a source to the receiver(s) in a treemust not exceed a specified value. The current assumptionis that the network delay of a link is proportional to thedistance of the link. We also assume that the input and out-put queue delay will be calculated as part of the totalincoming or outgoing delay. With these assumptions, theshortest path between two nodes will have the least delaybetween the said nodes. Routing algorithms like MOSPF,Jia’s algorithm, Kumar et al. algorithm [15] are dense modemulticast routing algorithms while probing methods aresparse mode multicast routing algorithms that can be usedto find a path that meets the delay constraint on a multicasttree.

Constructing a multicast tree with a minimum band-width requirement on all tree links is a link constrainedrouting problem. The links along the on-tree routersbetween the sender and all receivers must provide the

J. Singh et al. / Computer Communications 29 (2006) 2881–2894 2883

required bandwidth for the duration of the session. Sha-cham [12] uses a Djikstra like algorithm to compute themaximum single-path bandwidth to all receivers from thesource. However, this algorithm can only be used forsource based routing in a link state network. Generic probebased multicast routing algorithms can be used to find apath that meets the minimum bandwidth requirement ofa SBT or ShT multicast tree.

Unlike other routing algorithms, probing algorithms donot assume that the shortest path in the number of hopshas the least delay or provide the best bandwidth. They willprobe the network link to find a feasible path to a multicasttree by using a single path algorithm or a multiple pathalgorithm. Single path algorithms will search for only onepath that meets the QoS requirements. If the path fails tomeet the QoS requirement, the routing algorithm will starta new search for another path. Multiple path algorithmswill try to find several paths that meet the QoS require-ments concurrently. The multicast member will select the‘best’ path from a list of available paths.

2.1. Related work

We describe the multicast probing methods proposed byother researchers in more detail before we explain how ourprobing method works. The WAVE [21] probing algorithmis used for source-based multicast trees while the spanningjoin (YAM) [22], QoSMIC [23,24] and QMRP [25] probingalgorithms are used for finding a feasible path in both asource-based or shared multicast trees.

The WAVE routing algorithm will find a QoS path fromthe source-based multicast tree to the joining node. Thejoining node first sends a join request to the source nodewhich will propagate the join message along the tree. Aseach member of the tree receives the join request, they willsend a response to the joining node. The joining node willselect the best QoS path from all the responses it receives tojoin the tree.

This method of probing has a single point of failure.Every join request needs to reach the source node beforethe probe method can begin. If the source node fails, orcannot handle the request, the joining node will not be ableto find the QoS path to the multicast tree. The joining nodehas to wait for all responses before it chooses a path to jointhe tree. This can lead to a long waiting time if the tree isfar away.

The spanning joins (YAM) mechanism overcomes thesingle point of failure problem of WAVE by finding oneor more candidate paths from a joining router to the mul-ticast tree. The joining router uses broadcast with reversepath forwarding (RPF) to send out join messages on alllinks towards the multicast tree. Once an on-tree routerreceives the broadcast packet, it will probe for the QoSon the reverse path taken by the broadcast. The joiningnode will evaluate which path contains the best QoS fromthe probes it receives and joins the tree using the best pathit finds.

The first join message that reaches an on-tree routershould be the path with the least delay to the joining node.However, in an asymmetrical link, this might not be truefor the reverse path. The biggest problem with YAM is thatmost or even all the paths from the joining node to the mul-ticast tree might not provide the required QoS. Dependingon the size of the network, the high message complexityduring path exploration can produce very high networkoverheads with no guarantee of finding a path with therequired QoS.

Faloutsos et al. introduced QoSMIC which expands onthe YAM protocol described above. QoSMIC finds a QoSpath by performing a local search using a limited scopespanning join mechanism to find an on-tree router whichis close to the joining node. If there are no on-tree routersclose by, the joining node will send a join request to a man-ager on the multicast tree. This manager will choose candi-date on-tree routers to start probing towards the joiningrouter. Whether the path is joining node initiated or multi-cast tree initiated, the QoS probe is sent from the candidateon-tree routers to the joining node. The joining node willselect the best QoS path from the received probes to jointhe multicast tree.

QoSMIC improves on YAM by limiting the broadcastsearch area to limit resource overheads. If the multicasttree is beyond the search area, the manager node can beused to choose candidate routers to initiate the probe.The only drawback is that the manager node’s addressneeds to be known by the joining node for it to becontactable.

In a large network, both YAM and QoSMIC might takea long time to converge if probes are sent out at differenttimes. The joining router has no way of knowing how longit will take for every probe to reach itself. The time a probeis sent depends on the location of the tree reached by thespanning join. The RPF used by both these protocolsassume that the links are symmetrical. If the network hasasymmetrical links, the convergence time might be muchlonger than if the network was symmetrical. The WAVEprotocol also suffers from this convergence problem sincenodes nearer the source node will send a probe before thefarther nodes in the tree.

Chen and Nahrstedt’s QoS-aware multicast routing(QMRP) protocol uses both single path and multiple pathrouting to find one or more feasible paths from a joiningrouter to a shared multicast tree with the required QoS.The QMRP protocol starts probing for a QoS path fromthe joining node to the on-tree router rather than the otherway as used in WAVE, YAM and QoSMIC. A joiningrouter starts out by using single path routing to probethe shortest path to the multicast tree. The QMRP protocolswitches to multiple path routing when the probed pathcannot provide the required QoS. Once a node fails theQoS check, the probe will go back one node and sendout multiple path probes on every link except for the linkleading to the failed node and the origin of the probe. Oncethe probe successfully reaches an on-tree router, it will send

V’1 V’2 V’3

B

C

A

D

2 3

13 72

3

3

5 6

1

23

CBT Join-RequestV1 EBPM Message

V2 EBPM MessageV3 EBPM Message

E

CoreRouter

u

Fig. 1. The joining router u wants to join the CBT multicast tree.


an ACK on the reverse path of the probe back to the orig-inating node. The originating node will select the best pathfrom all the returned ACK messages.

QMRP does not flood the network with as many pack-ets as YAM or QoSMIC to find a path to the multicasttree. Unfortunately, QMRP might find itself backtrackingall the way to the source to perform a multi-path searchif it cannot find a QoS path at later routers. Unlike theother protocols, QMRP is only interested in finding a suc-cessful QoS path rather than the optimal QoS path fromthe joining node to the multicast tree.

All of these protocols are used for finding QoS paths ona wired multicast network. They assume that the joiningnode is in a fixed position. These protocols will not workwell in mobile networks although they can be used in aninfrastructure-based wireless network. However, these pro-tocols are not optimised for speed which is an importantconsideration in a mobile environment.

3. Proposed quality of service architecture

In the previous section, we discussed QoS routing andthe schemes used for finding a QoS path from a joiningnode to a multicast tree along with their shortcomings. Inthis section, we will describe our multicast QoS routingarchitecture that can be used to find QoS feasible pathsin both wired and wireless networks.

3.1. QoS routing: tree initiated path exploration

In the following, we denote a network topologyG = (V,E) with a multicast shared tree, T = (V 0,E 0) whereV 0 ˝ V and E 0 ˝ E with each edge e = uv P 0. Ifu 2 (V � V 0) is a joining router, our problem is to find apath from u to an on-tree node v 0 2 T that satisfies therequired QoS using a distributed routing scheme.

Our scheme minimises the use of multiple path QoSrouting which leads to high broadcast overheads in largenetworks. We start by using a single path probe on theshortest path between the joining router and the multicasttree and only use multiple path probing if the single pathfails to provide the required QoS. Although the shortestpath might not provide the optimal QoS path, the joiningrouter can quickly join the multicast tree without incurringhigh network overheads when multiple path probing isused.

We will use a bi-directional multicast shared tree likecore-based tree (CBT) [26,6] as an example even thoughthis architecture can be used to find a QoS path for anytype of sparse mode multicast tree (SBT or ShT). TheCBT routing protocols uses the underlying unicast routingprotocol to perform multicast routing.

If we look at Fig. 1, router u wants to join the mul-ticast tree and sends a QoS probe with the CBT Join-Re-quest message to the core router (V 01) of the multicasttree, T which consists of on-tree routers V 01, V 02 andV 03. The join message will use the underlying unicast-

routing table to reach the core router on the shortestpath from u to V 01.

As the join message traverses the network, the QoS infor-mation from each router along the path will be stored in thepacket. If an additive metric like delay is measured, the QoSvalue from each router is accumulated and stored in thepacket. In the event of measuring a concave metric like min-imum bandwidth, the QoS value of the link bandwidthstored in the router will be compared with the QoS valuein the packet. If the QoS value of the router link has lowerbandwidth compared to the QoS value in the packet, therouter will replace the value in the packet with the lowerQoS value. The proposed architecture can also be used tofind a multiplicative metric QoS path by converting the met-ric to an additive metric so that it can be easily measured.

There is not much overhead compared to the regularCBT Join-Request message since the router does not makeany QoS decisions during this initial stage. The main pur-pose of this initial Join-Request is to inform an on-treerouter that a member is interested in joining the multicasttree rather than to find a QoS satisfying path to the tree.

This Join-Request message will reach an on-tree routerv0n on the shortest path using the underlying unicast routingtable. The example in Fig. 1 shows that the shortest pathbetween the joining router to the multicast tree isu fi A fi V 01. The on-tree router V 01 will perform a QoSeligibility test. If the Join-Request passes the eligibility test,the on-tree router will send a Join-Ack message back to thejoining router on the reverse path used by the Join-Requestmessage.

Our multipath QoS routing scheme is only used in theevent that the Join-Request fails the QoS eligibility test.If we assume that the QoS needed to join the tree is


15 ms, the diagram shows that the shortest route pathused by the Join-Request does not satisfy the requiredQoS. The on-tree router V 01 will multicast an ExploreBest Path Message (EBPM) initiation message to allother on-tree routers. Every on-tree router that receivesthis initiation message will broadcast an EBPM to everyqualified outgoing neighbour which are not on-treerouters.

A non-tree node v2 is a qualified neighbour for somenode v1 if the link v1v2 has the required bandwidth or thelatency up to v2 is less than the required latency or both.For ease of explanation, the example in this paper onlyconsiders latency (additive metric) for the QoS path. TheEBPM packet can be extended to include other QoS met-rics including multiple metrics.

Each EBPM message is uniquely identified by each ofthe on-tree router v0n (source) that initialises the message,the joining router u (destination), the multicast groupaddress and a sequence number. The sequence number isincremented whenever a source issues a new EBPM tothe same destination for the same group after the expiryof the previous EBPM.

Unlike the Join-Request message which only collectsQoS information to be processed by an on-tree router,the QoS value in an EBPM message will be evaluated byeach router that receives it. The router will create a routingstate for the received EBPM message and then compare thecollected QoS value with the required QoS value. If theQoS value is within the QoS bound, the router will thenupdate the EBPM QoS value, replicate the packet and for-ward it on every qualified outgoing link not directlyattached to an on-tree router or on the reverse path ofthe EBPM.

Every qualified neighbour router vn that receives anEBPM will process the packet according to these six condi-tions as detailed below:

3.1.1. Condition 1If vn has no qualified neighbours, then the EBPM will be

dropped by vn. This can only happen if vn has only oneneighbour from which it received the EBPM or if all theother outgoing neighbours do not offer the required band-width or their latency does not meet the required QoS.

Router A in Fig. 1 will drop the EBPM from on-treerouter V 01 since it cannot find a path with the requiredQoS.

3.1.2. Condition 2

If the EBPM time-to-live (TTL) expires, the EBPM willbe dropped.

3.1.3. Condition 3

If a previously received EBPM has a better path QoSthan the current EBPM, the current EBPM will bedropped. In the example in Fig. 1, router B will drop theEBPM message from router E since it already knows a bet-ter QoS path to the on-tree router (V 02).

3.1.4. Condition 4

If the current EBPM has the same QoS update value asthe QoS value in the routing table, the router will use thisnew path as a backup path. The router will create a backupreverse link to the previous router that sent this EBPM anddrop the EBPM.

The EBPM received by router C from router D

(V 02 fi B fi E fi D) has the same QoS as the EBPM fromrouter B (V 02 fi B). Router C will use router D as a backuplink in case the link to router B fails.

3.1.5. Condition 5

If router vn receives this EBPM for the first time and it iswithin the required QoS value, router vn will create areverse link to the last router that sent this EBPM andrebroadcast the EBPM to all the qualified neighbours.

3.1.6. Condition 6

If this is not the first EBPM received by a router and theQoS value is better than the QoS in the reverse link table,the router will change the old reverse link to the new routerwhich sent the better EBPM packet. The router will thenforward the EBPM packet on all qualified outgoing links.To keep the router’s routing table small, the router willonly keep a routing state to the last router that sent the bestEBPM packet.

There are two exceptions to condition 6. The first is ifcondition 4 is true where a backup link is created for analternate path. The other exception only applies to aconcave metric like minimum bandwidth. The incomingEBPM QoS value is limited by the best QoS providedon the outgoing link of the router. The router will notupdate the reverse link table if the incoming EBPM isbetter than the value in the reverse link table and alsobetter than any of the outgoing link bandwidth of therouter.

The way a path QoS is calculated depends on whetherthe QoS measurement is for the outgoing link, incominglink or both links. The outgoing link follows the directionfrom the on-tree router to the joining router and vice-versafor incoming link. Normally multicast receivers require theQoS on the outgoing link while multicast senders requireQoS on the incoming link.

Since all routers know their outgoing link QoS, therouter will replicate the EBPM and update the EBPMQoS of the link it goes out on if only the outgoing linkQoS is measured. In the case of the incoming link QoS,a router will send the EBPM to the next hop routerwhich will fill in the QoS value of the link it came on(previous router’s incoming link). If QoS is requiredfor both incoming and outgoing links, then the routerswill perform both operations, ie. update QoS for down-stream link and send the EBPM to a qualified routerwhich will update the QoS for the upstream link. Thisprocess will continue until the EBPM process terminateseither by finding a successful path or until the packet isdropped.

V’1 V’2 V’3

B

u C

A

D

2 3

13 72

3

3

5 6

1

23

Selected QoS PathCBT Join-Request MessageCBT Join-Ack Message

E

CoreRouter

Fig. 2. The joining router u joins the CBT multicast tree on the best QoSpath.


To summarize, the QoS value will be updated as follows:

1. For a concave metric like minimum bandwidth, router vn

will broadcast the EBPM with QoS update = mini-mum(QoS value of the incoming EBPM, bandwidth ofonly the qualified link to which it is advertising).

2. For an additive metric like latency, router vn will broad-cast the EBPM with QoS update = QoS update + addi-tive weight on the qualified link.

3. For both additive and concave metrics, router vn willbroadcast the EBPM, with each QoS update for a con-cave or additive metric as shown above, through allqualified links which satisfy the multiple QoSrequirements.

An EBPM that reaches the joining router u has found aQoS satisfying path from the multicast tree to u. Router u

will send a new Join-Request on the reverse link taken bythe EBPM. If we refer to the network architecture inFig. 1, Table 1 displays the reverse link and QoS valueaccumulated by the EBPM from each router along its pathto the joining router. Although the joining router u receivestwo successful EBPMs from router A and router C with theQoS of 10 and 11 ms, respectively, it will only pick the opti-mal QoS path. The joining router will send a CBT Join-Re-quest on the reverse link to router A since that link gives abetter QoS. Router A will follow its reverse link table entryto router B and from there to router V 02 as shown in Fig. 2.

Unlike other QoS probe methods that find static QoSpaths, from which the optimal path is selected, our methodhas the ability to dynamically change the reverse link of anintermediate router as it receives a better EBPM. Everytime a router changes its reverse link to a router that pro-vides better QoS latency, that router will broadcast a newEBPM with the latest QoS values. As shown in Fig. 2, rout-er A will dynamically change its reverse link from V 01 to B

since the EBPM from router B has the better QoS. Thisalways ensures that the selected QoS path will at least pro-vide the QoS collected in the EBPM or even better if therouter dynamically changes its reverse link.

As the Join-Request travels to the on-tree router, eachintermediate router will establish the forward path asdetailed in the CBT protocol. Once an intermediate routercreates the forwarding path, the router cannot change itsreverse link any more even if it receives a better EBPMat a later time. If the joining router wants to accept a betterpath, it needs to leave the group first and re-join the group

Table 1Reverse link table for each router

V 01 V 02 V 03 A B C D E

A – – – – 5 – – –B – 2 – – – – – –C – – – – 8 – 8 (R) –D – – – – – – – 6E – – – – 3 – – –u – – – 10 – – – –

on the new path. This is to avoid loops and to reduce theload on the non-tree routers.

However, if the joining router does not receive anEBPM within the round-trip time of the required QoS laten-

cy + end-to-end tree delay, it can conclude that there is noQoS satisfying path available from itself to the multicasttree. In case, the joining router does not know the end-to-

end tree delay, it will wait for twice the round-trip time ofthe required QoS latency. This is not an optimum upperbound and can be modified accordingly if the networktopology is known.

3.2. Finding an end to end QoS path

Our proposed QoS architecture as detailed in section 3 isused to find feasible paths from the multicast tree to thejoining router. A feasible path can only be found if theend-to-end QoS between all members of the group isknown. The method used for path exploration is alsodependent on whether the joining router is a receiver or asender in the multicast group. End-to-end QoS can be clas-sified as the QoS between a sender and all of the receiverson the multicast tree.

Every on-tree router will keep a QoS value between itselfand a sender node. We propose rather than have a separateQoS entry for each sender (if a ShT is used), the on-treerouters will only keep the lowest bound (worst) QoS valuein its routing table. This way, the routing table will notgrow as the number of senders grow. We believe this isacceptable since all receivers in the group must be able tocater for the QoS of every sender. The EBPM messages willnot be uniform since the QoS requirement for an EBPMprobe will depend on the QoS between the on-tree routerand the sender.


The direction for a node to probe a QoS path greatlydepends on whether it is a sender, a receiver or both a send-er and a receiver. If the new member is a receiver, it needsto find a path on its incoming (outgoing for the on-treerouter) link that meets the end-to-end QoS between itselfand the sender(s). The path between itself and the multicasttree has to be equal to or less than the difference betweenthe required QoS and the QoS between the sender andon-tree router. In Eq. (1), the end-to-end delay for a source(s) and a receiver (r) through on-tree routers (ot) is D(p)where p is a path in the multicast tree T and the QoSdelay-constraint for the multicast group has to be less thanor equal to D.X

p2P T ðs;rÞDðpÞ ¼

X

p2P T ðs;otÞDðpÞ þ

X

p2P T ðot;rÞDðpÞ 6 D. ð1Þ

In Fig. 3, on-tree router V 02 is directly connected withthe only sender on the tree. If we assume there is no delaybetween the sender and V 02, the latency for V 02 is 0. On-tree routers V 01 and V 03 will have a latency of 2 and3 ms, respectively, between themselves and the multicastsender. If the end-to-end QoS delay-constraint is 15 ms,router u has to find a path with a QoS path with latencyof 13 ms or less if it joins at V 01, a path with QoS latencyequal to or less than 15 ms to on-tree router V 02 or a QoSpath with latency of 12 ms or less to on-tree router V 03.Only router V 02 can provide a QoS path to router u andthe optimum path leading to V 02 is followingu fi A fi B fi V 02.

Finding a path for a sender becomes more complicatedsince the QoS requirement is set by the sender. This newsender might require the same or less QoS than the currenttree provides or it might require more QoS. If the senderneeds the same or less QoS than the current tree, it usesthe same mechanism as a joining receiver but the QoS iscalculated on its outgoing (incoming for the on-tree router)link.

V’1 V’2 V’3

B

u C

A

D

2 3

13 72

3

3

5 6

1

23

Optimum QoS Path

E

Fig. 3. Optimum QoS latency path from receiver u to multicast senderV 02.

At this moment, our path selection algorithm does notcater for senders with higher QoS requirements than whatis specified by the existing group. If the new sender asksfor more QoS than D, the on-tree router will not allow thesender to join the group until it lowers its QoS requirements.

4. Comparison and performance analysis

We will show through theoretical analysis and simula-tions the performance of EBPM against other multicastprobing methods like YAM and QoSMIC.

4.1. Theoretical analysis

The following theorems are valid for the EBPM methoddescribed in this paper.

Theorem 1. The above exploration algorithm does not form

a loop in any instance.

Proof 1. Like YAM and QoSMIC, EBPM does not forma loop in any circumstance. In a worst case scenario, thenetwork routers v = v1,v2, . . ., vr are connected in the orderthey appear and vr is connected to v1 to form a loop. If v1 isthe first router to receive an EBPM, the EBPM it receivesfrom the on-tree router will be the lowest starting latency.It will update the QoS latency in the EBPM and broadcastit to the next routers connected to it, i.e., v2 and vr. TheseEBPM QoS latency values will increment as it traversesthe network routers. Once a router receives more thanone EBPM at the same time, it will select the best EBPMand discard the other message. In the event, that all thelinks have a latency of 0, the router will select one EBPMand use the other as a backup route. This also holds truefor a concave metric like minimum bandwidth, where theQoS on all routers will be restricted to the worst QoS valuethat is within the bounded bandwidth constraint. If a rout-er receives another EBPM with a better QoS, it will notchange the reverse link since the outgoing link bandwidthwill be the bottleneck for the QoS path. This limiting ofQoS values only applies to a concave metric. Thus, no rou-ters will form a loop using EBPM if we are exploring for anadditive or concave QoS path. h

When the initial Join-Request from the joining router u

fails to establish a QoS satisfying path to the multicast tree,every on-tree node will start exploring for a QoS satisfyingpath to u. However, they will start exploring the paths atdifferent times as the EBPM initiation message travels fromone on-tree router to the next. Depending on the topologyand the link latencies, an intermediate router may receiveone or more EBPM for a particular router u and a groupaddress, G. These EBPMs might reach an intermediaterouter at different times with a better EBPM arriving later.When this happens, the intermediate router will continu-ously update its reverse link until no better EBPM arrives.An intermediate router will stop changing its reverse linksunder the following situation:


1. All the EBPM packets broadcasted by the on-tree rou-ters have passed the intermediate router.

2. Any EBPM received by the intermediate router has aworse QoS than the previous EBPM it received.

At this stage, we say that the algorithm has converged forthat particular router u. If the joining router is close to themulticast tree, then the EBPM will converge faster comparedto a farther joining router. By choosing a right time-to-live(TTL) value, we can make sure that the EBPM packets doesnot go wide in the network. The following theorems showthat the EBPM message will converge in polynomial time.

Theorem 2. When constructing a delay-constrained path

from the joining router to the multicast tree, our algorithm

converges in O(1) time if all EBPMs are sent out at the same

time from the on-tree routers.

For additive functions like latency, the convergence rateis quite slow and theoretically it can be exponential. This isdue to the fact every intermediate router receiving a newEBPM needs to add its additive link capacity at every qual-ified outgoing link and rebroadcast through the outgoinglink, making the number of different possible advertise-ments exponential.

Although the basic algorithm can theoretically takeexponential time to converge when finding an additiveQoS path, we present an algorithm that converges inO(1) time when probing for a delay-constrained path. HereO(1) means that the algorithm will converge in constanttime. The constant will depend on the topology, whichincludes the edge lengths. This constant is bounded bythe length of the longest path in that graph.

Observe that if all the on-tree nodes start their probe atthe same time, the first EBPM received by non-tree routerswill be the most optimum EBPM with respect to end-to-end latency. This is true for the destination too. The firstEBPM received by the destination would use the minimumdelay path to reach it.

Since the first EBPM received by every non-tree routeruses the optimum path, any intermediate node will set itsreverse link only once. It may set one or more backup linksif it received multiple EBPMs at the same time. Thus, itconverges in O(1) time.

Now, we must ensure that all the tree nodes start theirbroadcast at the same time. Since each on-tree nodereceives the EBPM initiation request at different times,we need to have a mechanism by which they wait for a cer-tain time before starting the exploration. We present this asan algorithm.

Algorithm. The destination router u wants to join a sharedtree T with the required latency. If u can connect to on-treerouter v and the path between v and u does not provide therequired QoS, v will request the core to issue the EBPM ini-tiation message to all on-tree routers. This is because thecore has the knowledge of latency from itself to every otheron-tree nodes.

The core will send an EBPM initiation message with themaximum tree latency used to set a timer. Every on-treerouter will start their exploration as soon as this timerexpires. On-tree routers that are closer to the core needto wait for a longer time compared to routers which arefurther from the core. Every on-tree router waits for (tim-er � a) time, where a is the time taken for the initiationmessage to travel from the core to the on-tree router andtimer is the maximum tree latency. Each of these EBPMmessages will also have the on-tree router’s delay fromitself to a sender in the group so that the path found willtake into account any QoS difference between the on-treerouter and a sender node.

Since all EBPMs are sent out at the same time, the rou-ters should receive the best path EBPM first. The routerscan drop any subsequent EBPM received since most ofthem will have a worst QoS than the previous EBPM.Thus, the EBPM messages will converge in O(1) time.

In practice, it is hard to achieve perfect synchronisa-tion among every on-tree router. However, even if therouters are loosely time synchronised, the algorithm willconverge and output a QoS path. If the maximum timedifference among the on-tree routers are less than the dif-ference between the end-to-end latency of the first bestQoS path and the second best QoS path, the proposedalgorithm will output the optimum QoS path. If the timedifference is more, then the algorithm will still output aQoS path although it may not be the optimum QoSpath.

Theorem 3. If only a concave metric is measured, our

algorithm converges in O(m2) time, where m is the number

of edges in the network.

Proof 2. In the network under consideration, the worstcase scenario has 2m edge weights, one in each direction.Thus through any single edge uiuj, the router ui mayadvertise 2m different QoS updates. Router uj may receivea maximum of d(uj) · 2m advertisements, where d(uj) isthe degree of the router uj. The total time complexity isOðP

j2m� dðujÞÞ ¼ Oð2m� mÞ ¼ Oðm2Þ. Though theoreti-cally the worst case complexity is O(m2), the average timecomplexity would be much less than this. This is becauseof the following facts: If any intermediate node vi receivesa new EBPM with better QoS, i.e., better available band-width, vi does not have to advertise the new EBPMthrough its outgoing links if the router’s outgoing linkis the QoS bottleneck. That is if vi has received a higherbandwidth EBPM than a previous EBPM QoS, vi neednot have to replicate and send this EBPM over the outgo-ing link since the whole QoS path is constrained by thelowest bandwidth. This will reduce the average time com-plexity. h

In order to explain the next theorem, we give the defini-tion of a two-connected component. Two vertices u and vare in the same two-connected component if and only ifthere exist at least two vertex-disjoint paths joining u


and v. For the sake of clarity, Fig. 4 illustrates an exampleof a two-connected component in a network graph. Thetwo-connected components of G are {1,2,3,4} and {4,5,6}.

Theorem 4. If the network topology is known, only an on-

tree router that can find a path between itself and the joining

router without going through another on-tree router will

initiate EBPM broadcasts.

Basic EBPM states that every on-tree router will broad-cast EBPM messages on every outgoing link that meets theQoS requirement and is not connected to another on-treerouter. This method may be acceptable in smaller networksbut it will cause high message overheads in larger networks,especially if these routers have no route to the joining rout-er in the first place. Although limiting the EBPM TTL val-ue may stop the EBPM messages from spreadingexponentially within the network, it still does not stopon-tree routers with no independent routes to the joiningrouter to broadcast EBPM messages.

If the network topology is known and u is a joining nodefor a multicast tree T, only the on-tree routers that are inthe same two-connected component of u will initiateEBPM broadcasts. Those nodes also restrict their broad-cast only to the two-connected component they belongto. If none of the vertices of T are in the same two-connect-ed component of u, every on-tree router will initiate theEBPM broadcast. The EBPM probes will be restricted tonodes in the two-connected component along the pathdetermined by the block-cutvertex tree.

If the network is represented as graph G = (V,E), theblock-cutvertex tree (BCT) is defined as follows.

(a) For each block Bi, we associate a vertex bi in theBCT.

(b) For each cutvertex ai in G, we associate another ver-tex ai in the BCT.

(c) If ai is a cutvertex in Bj, aibj 2 E(BCT).

1

3

2 4

Network Graph G

5

6

Fig. 4. Two-connected components of G.

Remark. The algorithm presented in this paper can be opti-mised if the network topology is known (link-state).Although the computational complexity remains the same,the message complexity of the algorithm can be reduced ifthe probes are sent to nodes in the two-connected compo-nent of the joining router.

4.2. Simulation analysis

In this section, we present our simulation results. Wecompared the message complexity (number of messagesexchanged until the algorithm terminates) and the conver-gence time of our algorithm with YAM [22] and QoSMIC[23,24].

We used the BRITE topology generator [27] to con-struct an autonomous system network topology. We gener-ated several random Euclidean graphs for 27 nodes usingthe Waxman method to represent an autonomous system.The nodes are connected by symmetrical links and theprobability of a node linked to its neighbour nodes isdefined as follows:

P ðu; vÞ ¼ ae�d=ðbLÞ ð2Þwhere 0 < a; b < 1, d is the Euclidean distance from node u

to node v, and L is the maximum distance between any twonodes. In our topology, we set a = 0.15 and b = 0.2.

The nodes of the topology are distributed in a planedivided by 1000 · 1000 squares where each of the squaresare further subdivided into 100 · 100 low-level squares.We set m = 2 where m is the number of neighbour nodesa new node connects to when it joins the network.

The graphs represent a hierarchical architecture of ametropolitan area network, offering high redundancy atevery layer in the hierarchy. Thus the number of edges inthese graphs are more than O(n).

In order to generate a topology which meets the Internetpower laws of the form y = xa [28], our generated topologyuses a Heavy-Tailed distribution of nodes instead of apurely random distribution. The Internet node connectivityis represented by a combination of preferential connectivityand Waxman’s probability function. In our topology, for anewly considered node v, we compute for each candidateneighbour node i a Waxman’s probability Wi (cf. Eq. 2)which gives connectivity preference to close-by nodes.Then, the final probability of connecting to node i is com-puted as follows :

widiPj2C

wjdj

This process is repeated to connect v to m nodes.Once the network topology is generated, we selected

three random connected nodes to be the multicast treeon-tree routers. The joining router was randomly selectedfrom this topology. The joining router will form a delayconstrained QoS path or a bandwidth constrained QoSpath between itself and the multicast tree.


Since the graph is random and represents a real-life net-work, the successful path with the prescribed QoS may ormay not exist between the joining node and multicast tree.In a similar way, if the joining router is in a different com-ponent of the network from the tree, no path exists con-necting the on-tree routers and the joining router, andhence no QoS path can exist.

In our simulations, we simulated the base YAM proto-col, QoSMIC with multiple spanning join radius limits andEBPM QoS multicast routing protocols. For QoSMIC, weconcurrently used both the spanning join and managerassisted probing methods. We simulated QoSMIC usingthe spanning join mechanism with a radius of three, fourand five hops from the joining router. When we simulatethe EBPM protocol, all on-tree routers will send out theEBPM message at the same time as described in theorem2. We simulated these protocols on the network with andwithout background traffic. The results are summarizedin a tabular form below.

4.2.1. Network without background traffic

The simulation was done to find a delay constrainedQoS path between the joining router and the multicast treewhen there was no background traffic present in the net-work. The same network condition was also used to simu-late the search for a bandwidth constrained QoS pathbetween the joining router and the multicast tree.

Table 2 summarizes the message complexity (number ofmessages exchanged till the convergence) when there is asuccessful path from the source to the destination withthe required QoS for a delay constrained QoS metric.

As we can see from Table 2, the message complexity ofYAM is remarkably high. This is because YAM uses multi-ple path exploration to find paths from the joining node toan on-tree router and send probes on the reverse paths ofthe paths found. Thus, a message will take every possiblepath from the joining node to an on-tree router. If thetopology is sparse, this will generate only linear order ofmessages. But since our topology is dense, YAM resultedin exponential messages with respect to the number ofedges.

QoSMIC has a much lower message complexity thanYAM since it limits its broadcast to three, four and fivehops from the joining router. The message complexity forQoSMIC reduces as the joining router is further away fromthe multicast tree. This reduction in message complexity is

Table 2Message complexity of QoS multicast routing protocols searching fordelay constrained path

Protocol Hop 1 Hop 2 Hop 3 Hop 4

YAM 1662085 2311636 2666274 3559666QoSMIC-3 58 54 55 23QoSMIC-4 229 206 173 66QoSMIC-5 787 771 627 245EBPM 5 12 20 31

an artefact of the simulated topology. The simulated envi-ronment is not topologically closed like the Internet ie. asphere. As the joining router gets further away from themulticast tree, the joining router will be at a corner ofthe network where the node connectivity is sparse. This sce-nario does not exist in the actual Internet since a router isconnected to many other routers and the message complex-ity for QoSMIC will be higher than what is presented inTable 2.

When the same QoS multicast routing protocols areused to find a bandwidth constrained QoS path, the mes-sage complexity for YAM and QoSMIC are the same asthe message complexity when searching for a delay con-strained path as shown is Table 2. This is because the samenumber of paths are explored and probed as in the delayconstrained QoS metric paths. The average message com-plexity for the EBPM routing protocol is 37 messages fornodes one hop away from the multicast tree. The EBPMmessage complexity for nodes two hops away is 44 messag-es, 56 messages for nodes three hops away and 63 messagesfor nodes that are four hops away from the multicast tree.

There is an increase in EBPM messages since a largenumber of routers have high bandwidth links that meetthe QoS requirement. This caused more paths to beexplored compared to the delay constrained path explora-tion. However, the EBPM message complexity is still smalland manageable compared to YAM and to the QoSMICradius limit of 4 and 5 hops.

Table 3 summarizes the percentage of successful pathsto the number of paths found. The percentage of successfulpaths found using YAM is very small since only a smallnumber of paths can provide the required QoS from allthe available paths found between the joining router andmulticast tree. QoSMIC provides a higher number of suc-cessful paths but this number decreases as the spanningjoin radius increases. This is because more paths areexplored as the radius increases but most of the newlyexplored paths fail to provide the required QoS. However,QoSMIC with a spanning join radius of three hops cannotfind a path for a joining router that is four hops away fromthe multicast tree. The joining router will have to requestthe QoSMIC tree manager to find a QoS path to the join-ing router. The tree manager will elect candidate on-treerouters to probe on the shortest path for a successfulQoS path.

In the case of EBPM, many paths are explored but onlyone successful path is found from the multicast tree to thejoining router. This one successful path will provide theoptimal QoS value since the routers will drop any EBPMprobe that provides a worse QoS path before it even reach-es the joining router. A joining router can only receivemore than one EBPM exploration packets if the paths tak-en by the successful EBPM packets are fully disjoined.Even it two or more EBPM packets reach the joining rout-er, all the paths taken by these messages would provide therequired QoS. That is why if a path can be found by anEBPM message, the success rate is always 100%.

Table 4Percentage of successful paths found using QoS multicast routing protocols for exploring bandwidth constrained paths

Protocol Hop 1 (%) Hop 2 (%) Hop 3 (%) Hop 4 (%)

YAM 1.635629435 2.201601296 1.70849949 0QoSMIC-3 32.53968254 31.6468254 36.34920635 0QoSMIC-4 27.11038961 24.35217051 29.83200707 0QoSMIC-5 24.93194192 22.92377892 23.64718615 0EBPM 100 100 100 0

Table 3Percentage of successful paths found using QoS multicast routing protocols for exploring delay constrained paths


YAM 0.002002774 0.00176883 0.002278909 0.005252143QoSMIC-3 25.3968254 32.34126984 36.34920635 75a

QoSMIC-4 8.116883117 11.46969129 15.3197760 46.42857143QoSMIC-5 3.039927405 3.639703734 6.385281385 18.14449918EBPM 100 100 100 100

a QoSMIC 3 hops spanning join limit could not find a successful path to an on-tree router. The QoSMIC tree manager selects candidate on-tree routersto find a QoS path to the joining router.


Table 4 shows the percentage of successful paths eachQoS routing protocol has in finding one or more band-width constrained QoS paths from the joining router tothe on-tree routers on a network topology without back-ground traffic. The links on the node four hops away fromthe multicast tree do not meet the bandwidth requirementsand will always return a failed path. The rate of successfulQoS paths found is higher for bandwidth constrained pathsbecause a higher number of links in the network have highbandwidth.

4.2.2. Network with background traffic

We introduced background traffic (5% to 25%) into thenetwork to see how background traffic affects the messagecomplexity and the success rate of the QoS routing proto-cols in finding a QoS path. The background traffic modelsthe average busy time in a metropolitan area networkwhich affects the QoS parameters at different routers andthus modifies the delay and bandwidth parameters. Insome cases, there may not be any QoS paths between thejoining router and an on-tree router. In other cases, theremight be alternative QoS paths with more hops than theones found when the network had no background traffic.

Since the same network topology was used, there was nochange to the YAM and QoSMIC message complexities

Table 5Percentage of successful delay constrained paths found when network has bac

Protocol Hop 1 (%) Hop 2 (%

YAM 0.001031523 0.001002QoSMIC-3 14.28571429 16.17063QoSMIC-4 4.545454545 5.734845QoSMIC-5 1.724137931 1.819851EBPM 100 100

a QoSMIC 3 hops spanning join limit could not find a successful path to an oto find a QoS path to the joining router.

for delay constrained and bandwidth constrained pathsearches. When EBPM was used to search for a delay con-strained QoS path, there was a marginal increase in themessage complexity for EBPM. This increase is still mana-gable because the QoS values in the EBPM explorationpackets are incremented at every link and the routers willfinally discard the EBPM explore packet once it has noqualifying outgoing links. In the case of searching for abandwidth constrained QoS path, the EBPM packet willbe discarded by a router that has received a better QoSpath before or if its outgoing links fail to meet the QoSrequirements.

The message complexity for EBPM delay constrainedexploration is 9 messages for nodes one hop away fromthe multicast tree, 13 messages for nodes two hops away,20 messages for nodes three hops away and 32 messagesfor nodes four hops away. In the case of bandwidth, theEBPM message complexity is 37 messages for nodes onehop away from the multicast tree, and 44, 56 and 63 mes-sages for nodes two, three and four hops away from themulticast tree, respectively.

Table 5 summarizes the percentage of successful pathsto the number of paths found for one or more delay con-strained QoS paths when the network topology has vari-able background traffic. The QoSMIC protocol with a

kground traffic

) Hop 3 (%) Hop 4 (%)

477 0.001185206 0.002020055492 14.6031746 50a

645 5.935750074 3.064778268867 2.543290043 0.831410343

100 100

n-tree router. The QoSMIC tree manager selects candidate on-tree routers

Table 6Percentage of successful bandwidth constrained paths found when network has background traffic


YAM 1.232000679 1.58242263 1.156621157 0QoSMIC-3 32.53968254 25.29761905 29.68253968 0QoSMIC-4 25.32467532 22.3537379 23.896257 0QoSMIC-5 21.68784029 19.20033443 15.25974026 0EBPM 100 100 100 0

V’1

A

U

B

51 20

5

10

2

15

7

2

3

1

1

Fig. 5. The joining router u wants to joins the CBT multicast tree in anasymmetrical network.


radius restriction of three hops cannot find a path to themulticast tree if the joining router is four hops away. Thejoining router must request the QoSMIC tree manager toselect on-tree routers to probe for a QoS path to the joiningrouter. The results show that QoSMIC has a 50 percentchance of successfully finding a QoS path by just relyingon the tree manager. It also shows that the effectivenessof YAM and QoSMIC in finding one or more QoS pathsis reduced by at least half when the background traffic isincreased by 5% to 25%.

Table 6 shows the percentage of successful nodes com-pared to total number of explored paths for one or morebandwidth constrained paths when there is backgroundtraffic in the network. There are no QoS paths for nodesthat are four hops away from the multicast tree. All theQoS routing protocols will fail in such a situation. TheQoS routing protocols perform better when searching fora bandwidth constrained QoS path since the increase inbackground traffic does not drastically reduce the overallavailable link bandwidth. This shows that background traf-fic effects link delays more than link bandwidth. TheEBPM protocol can find link and bandwidth constrainedQoS paths with very low message complexity comparedto the other QoS routing protocols.

From our simulation results, we can derive the followingconclusions:

1. In QoSMIC, if a joining node is r hops away from themulticast tree, the spanning join radius limit should beat least r hops for it to find a path an on-tree router.If the radius is less than r hops, QoSMIC cannot finda path to the tree without relying on the tree manager.Since the tree manager only probes on the shortest path,there is no guarantee that the shortest path can providethe required QoS.

2. If the topology is dense, YAM will find a lot of paths tothe on-tree routers although most of these paths do notprovide the required QoS. In the case of QoSMIC, as thespanning join radius increases, the number of pathsfound will similarly increase. However, like YAM, themajority of these paths will not provide the requiredQoS and lower the percentage of successful paths found.EBPM will always provide 0% or 100% since there arealways only two conditions – an EBPM will reach thejoining router or not.

3. The EBPM message complexity is lower than the otherQoS routing protocols because whenever a routerreceives an EBPM exploration packet that is worse than

any previous EBPM packet or when a router has noqualified neighbours, the router will discard the EBPMexploration packet.

4. If the topology is sparse and has O(n) edges, where n isthe number of vertices, all the above algorithms performequally.

4.3. Discussion

The YAM and QoSMIC QoS routing algorithmsassume that the routers are joined by symmetrical links.The delay for a joining router to reach an on-tree routerwill be the delay from the multicast tree to the joining rout-er. However, if the links are asymmetrical, which is mostoften the case in real-life networks, the time taken forreaching an on-tree router might be very different fromthe delay on the reverse path.

A simple network example is shown in Fig. 5 where thefastest upstream link U fi V 01 has the longest delay on thedownstream link V 01 fi U whereas the slowest upstreamlink path U fi A fi V 01 has the fastest downstream link.Table 7 shows the round trip time taken for a probe toreach an on-tree router.

Let us assume that the joining router is a multicastreceiver with a QoS requirement of 15 ms. The time takenfor all the probes to reach the joining router using YAM isupstream link path delay + downstream link path delay. Asuccessful path can be found in 27 ms although the opti-mum path will be found in 26 ms.

QoSMIC will have the same results as YAM if it usesthe spanning join probing mechanism. If QoSMIC uses

Table 7Probe round trip time for the sample network

Protocol Upstream (ms) Downstream (ms) Total Time (ms)

YAMa 1 20 2115 7 2218 9 2721 5 2622 5 27

QoSMIC 1b 5 6(Tree Search)

EBPM 1 5 6

a QoSMIC spanning join is the same as YAM.b V 01 is the QoSMIC manager and sends the probe from itself.


tree search, the time taken for a probe to reach the joiningrouter is shortest upstream link path delay to manag-

er + manager to tree delay + downstream link path delay.All QoSMIC probes will reach the joining router fasterthan YAM if uplink path delay > upstream link path delay

to manager + manager to tree delay. As shown in Table 7,the optimal path is found in 6 ms where the manager nodeis also the on-tree router that initiates the reverse linkprobe. The delay between the manager node and on-treerouters may differ depending on the location of the manag-er node in the tree.

The time taken for an EBPM probe to reach the joiningrouter in an asymmetrical network is shortest upstream link

path delay + shortest downstream link path delay. Forexample in Fig. 5, the joining router will send a Join-Re-quest on U fi V 01 and V 01 will broadcast an EBPM to rou-ters A and B. The first probe to reach the joining router willbe from V 01 fi A fi U in 6 ms same as V 01 fi A fi B fi U

which is elected as the backup link.

5. Conclusion

This paper describes the EBPM protocol which sendsout probes from the multicast tree to the joining router.The EBPM routing protocol along with the other QoSrouting protocols are used when a router only has localknowledge of the network. Since the routers in the Internetonly have local route knowledge, a good multicast QoSrouting protocol that can quickly find one or more QoSpaths is important.

Based on the simulations done and the presented theo-retical analysis, we find that similar protocols like YAMand QoSMIC can take a long time to converge. If the join-ing router waits to receive all probes before selecting a QoSpath, it will take a long time before the router joins themulticast tree. Not only does EBPM converge faster thanYAM and QoSMIC, it also sends out less messages to findall successful QoS paths to the joining node. The EBPMprotocol can be optimised to find the most optimised delayconstrained QoS path quickly and with lower packet over-heads than the other protocols. Its performance in finding abandwidth constrained QoS path is also better than the

other QoS protocols. Once multicast becomes more com-mon in mobile networks, this improvement in finding aQoS path quickly will be important for mobile devices tofind a QoS path during hand-offs.

References

[1] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, InternetGroup Management Protocol Version 3, RFC 3376, IETF, (October2002).

[2] R. Vida, L.H.M.K. Costa, S. Fdida, S. Deering, B. Fenner, I.Kouvelas, B. Haberman, Multicast Listener Discovery Version 2(MLDv2) for IPv6, RFC 3810, IETF, (June 2004).

[3] J. Moy. MOSPF: analysis and experience, RFC 1585, IETF, (March1994).

[4] D. Waitzman, C. Partridge, S. Deering, Distance Vector MulticastRouting Protocol, RFC 1075, IETF, (November 1998).

[5] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.Handley, V. Jacobson, C.-G. Liu, P. Sharma, L. Wei, Protocolindependent multicast-sparse mode (PIM-SM): protocol specification,RFC 2362, IETF, June 1998.

[6] A. Ballardie, Core based trees (CBT) multicast routing: protocolspecification, RFC 2189, IETF, (September 1997).

[7] E. Robert Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,Resource reservation protocol (RSVP) – version 1 functional spec-ification, RFC 2205, IETF, (September 1997).

[8] R. Bless, K. Wehrle, IP multicast in differentiated services (DS)networks, RFC 3754, IETF, (April 2004).

[9] T. Hardjono, B. Weis, The multicast group security architecture.RFC 3740, IETF, (March 2004).

[10] J. Shin, D.C. Lee, C.-C.J. Kuo, Quality of Service for InternetMultimedia, Prentice Hall PTR, 2003.

[11] L. Wei, D. Estrin, The trade-offs of multicast trees and algorithms, in:Proceedings of Fourth International Conference on ComputerCommunications and Networks, 1995, pp 150–157.

[12] B. Wang, J.C. Hou, Multicast routing and its QoS extension:problems, algorithms and protocols, IEEE Network 14 (1) (2000)22–36.

[13] D. Schreckling. Quality of service routing, Julius-Maximilians-Uni-versitt Wrzburg <http://www.stud.uni-wuerzburg.de/s139296/qos/index.html/>.

[14] P. Paul, S.V. Raghavan, Survey of multicast routing algorithms andprotocols, in: Proceedings of 15th International Conference onComputer Communication, Mumbai, India, 2002.

[15] P. Paul, S.V. Raghavan, Survey of QoS routing, in: Proceedings of15th International Conference on Computer Communication, Mum-bai, India, 2002.

[16] J. Singh, P. Veeraraghavan, S. Singh, Core based tree multicast(M-CBT) approach in supporting mobility, in: Proceedings of theIASTED International Conference Parallel and Distributed Comput-ing and Networks (PDCN 2004), Innsbruck, Austria, 2004, pp.147–152.

[17] A. Helmy, A multicast-based protocol for IP mobility support. in:Proceedings of the Networked Group Communication (NGC), 2000,pp. 49–58.

[18] C. Castelluccia, A hierarchical mobility management scheme for IPv6,in: Proceedings of the 3rd IEEE Symposium on Computers andCommunications (ISCC), Greece, 1998, pp. 305–309.

[19] S. Chen, K. Nahrstedt, An overview of quality of service routing fornext-generation high-speed networks: problems and solutions, IEEENetw. 12 (6) (1998) 64–79.

[20] G. Apostolopoulos, S. Kamat, D. Williams, R. Guerin, A. Orda, T.Przygienda, QoS Routing Mechanisms and OSPF extensions, RFC2676, IETF, (August 1999).

[21] E. Biersack, J. Nonnenmacher, WAVE: a new multicast routingalgorithm for static and dynamic multicast groups, 5th Workshop on

http://www.stud.uni-wuerzburg.de/s139296/qos/index.html

http://www.stud.uni-wuerzburg.de/s139296/qos/index.html


Network and Operating System Support for Digital Audio and Video(NOSSDAV) (1995), pp. 228–239.

[22] K. Carlberg, J. Crowcroft, Building shared trees using a one-to-manyjoining mechanism, ACM SIGCOMM Comput. Commun. Rev. 27(1) (1997) 5–11.

[23] M. Faloutsos, A. Banerjea, R. Pankaj. QoSMIC: quality of servicesensitive multicast internet protocol, in: Proceedings of the ACMSIGCOMM 1998 Conference on Applications, Technologies,Architectures, and Protocols for Computer Communication, 1998,pp. 144–153.

[24] S. Yan, M. Faloutsos, A. Banerjea, QoS-aware multicast routing forthe internet: the design and evaluation of QoSMIC, IEEE/ACMTrans. Netw. (TON) 10 (1) (2002) 54–66.

[25] S. Chen, K. Nahrstedt, Y. Shavitt, A QoS-aware multicast routingprotocol, in: Proceedings of INFOCOM 2000, 19th Annual JointConference of the IEEE Computer and Communications Societies,vol. 3, 2000, pp. 1594–1603.

[26] A. Ballardie. Core based trees (CBT) multicast routing architecture,RFC 2201, IETF (September 1997).

[27] A. Medina, A. Lakhina, I. Matta, J. Byers, Boston UniversityRepresentative Internet Topology Generator (BRITE), (Web site).URL <http://www.cs.bu.edu/brite/index.html/>.

[28] A. Medina, I. Matta, J. Byers, On the origin of power laws in internettopologies, ACM SIGCOMM Comput. Commun. Rev. 30 (2) (2000)18–28.

Mr. Jaipal Singh received his bachelors degree inComputer Science (Hons.) from University ofTechnology Malaysia. He is currently undertak-ing his Ph.D. candidature at the Department ofComputer Science and Computer Engineering inLa Trobe University. His research interestsinclude quality of service routing, group com-munication using multicast routing and wirelessmobility routing. His Ph.D. thesis is concernedwith designing a mobile routing protocol thatsupports transparent handover for mobile net-

work devices engaged in one-to-one and group communication through afixed wired infrastructure.

Prakash Veeraraghavan obtained his B.Sc. andM.Sc. in Special Mathematics from MaduraiKamaraj University and Ph.D. from IIT, Madras,India. His research interest includes Algorithms,optimization and security. He is currently workingas a senior lecturer in the Department of Computerscience and Computer Engineering, La TrobeUniversity.

Samar Singh obtained his B.Sc.(Hons) in physics,
and M.Sc. in operational research from theUniversity of Delhi, and his Ph.D. from the IIT,Delhi, India. From 1975 to 1977 he was aHumboldt Research Fellow at the University ofErlangen-Nuremberg. From 1977 to 1986, heworked in Government and Industry in India,and from 1986 to 1992 he was on the faculty ofthe Department of Computer Science and Com-puter Engineering at the IIT, Delhi, India. Since1992 he has been at the Department of Computer
Science and Computer Engineering at La Trobe University, Melbourne,Australia, where he is currently an Associate Professor and Head of
Department. He has authored and co-authored over 60 papers in refereedinternational journals and conference proceedings. His current researchinterests lie in the area of computer networking and performance issues.
http://www.cs.bu.edu/brite/index.html

qos multicast routing using explore best path

Documents