Ann. Telecommun. (2008) 63:579–596DOI 10.1007/s12243-008-0058-x

Class-based multicast routing in interdomain scenarios

Maria João Nicolau · António Costa ·Joaquim Macedo · Alexandre Santos

Received: 17 February 2008 / Accepted: 1 July 2008 / Published online: 31 October 2008© Institut TELECOM and Springer-Verlag France 2008

Abstract DiffServ-like domains bring new challengesto quality of service (QoS) multicast routing simply byshifting the focus from individual flows into classes offlows. Packets are marked at edge routers and receivedifferentiated treatment according to the class and notthe flow that they belong to. DiffServ therefore becameadverse to multicast, as packet replication inside thedomain may require classification and remarking func-tions not present in core nodes. At the interdomainlevel, no doubt multicast QoS complexity is increasedby the interleaving of DiffServ and non-Diffserv do-mains, making it more difficult to address QoS mul-ticast in an end-to-end perspective. In today’s realinterconnection world, classes of service have no mean-ing in certain links of a full interdomain path. Whilethe problem is not new, as already pointed out, thereare no real efforts to bring multicast back to a class-of-service domain without compromising its model ofoperation. In this article, we present an innovativemulticast QoS routing strategy, clearly designed for the

M. J. Nicolau (B)Departamento de Sistemas de Informação,Universidade do Minho, Campus de Azurém,4800 Guimarães, Portugale-mail: joao@dsi.uminho.pt

A. Costa · J. Macedo · A. SantosDepartamento de Informática, Universidade do Minho,Campus de Gualtar, 4710 Braga, Portugal

A. Costae-mail: costa@di.uminho.pt

J. Macedoe-mail: macedo@di.uminho.pt

A. Santose-mail: alex@di.uminho.pt

new class-of-service paradigm. The solution is basedupon the construction of multiple trees, one per classof service available, while still allowing receivers toshift for source-specific trees in its own class of ser-vice. The strategy is presented in a full end-to-end per-spective. Intradomain trees use differentiated routingpaths thus helping traffic differentiation. Intradomainreceivers are allowed to shift from shared trees into anadequate class-of-service source tree. At interdomainlevel, each class-of-service interdomain tree branch isaccomplished by means of an improved path probingstrategy enabling for QoS path establishment. This pa-per presents this new strategy, and associated protocols,for constructing several multicast and directed distribu-tion trees, one per class of service, within each multicastgroup. This new strategy and associated protocols arethen simulated using NS-2 platform. Simulation resultsare analyzed and compared with other multicast rout-ing solutions, both at intra- and interdomain levels.

Keywords QoS routing · Multicast · Interdomain

1 Introduction

Many of the applications in the Internet, such as videoconference, distance learning, IP-TV, and video/audiobroadcast, would benefit from multicast support fromthe underlying network. These applications involvemultiple users (several receivers and, some of them,several sources too); thus, they need to use networkresources efficiently. Multicast communication is theability to send in an efficient way information to oneor more receivers at the same time without incurringinto network overloads. Hence, at each router, only a

580 Ann. Telecommun. (2008) 63:579–596

single copy of any incoming multicast packet is sent peractive link, rather than sending one copy of the packetper number of receivers accessed via that link.

Routing multicast traffic requires the construction ofa distribution tree (or a set of trees). Data packets aredelivered through that tree; thus, the major objectiveof the routing protocol is to build a tree with mini-mum cost in order to optimize the network resourcesinvolved.

In addition, most of the multicast applications arequality-of-service (QoS) sensitive in nature; thus, theywill need QoS support too, if available. The new chal-lenge lies on how to build a multicast tree (or a set ofmulticast trees) to deliver the data from sources to mul-tiple receivers so that QoS requirements are satisfiedand the cost of the multicast tree is still minimized.

There are two different models to provide QoS at thenetwork level: IntServ and DiffServ model. The mainstrength of the IntServ model is to provide an absoluteservice guarantee. However, it has several weaknessestoo. Each router is required to maintain state informa-tion for each flow; thus, scalability problems may arise.In addition, each router requires a significant amountof processing overhead, and the connection setup timeis sometimes greater than the time required for thetransmission of all packets belonging to a specific flow.The goal of DiffServ [4] is to provide the benefits ofdifferent levels of QoS while avoiding the limitations ofthe IntServ model. This is accomplished by aggregatingtraffic into classes. DiffServ does not maintain any per-flow information and also eliminates the connectionsetup costs.

Most proposals for differentiated services involvecontrol algorithms for aggregating service levels, packetmarking and policing, and preferential treatment ofmarked packets in the network. The issue of routingfor enhancing aggregate QoS has not yet received thenecessary attention.

In this paper, an innovative multicast QoS-awarerouting strategy is proposed addressing several of theproblems faced by interdomain and intradomain mul-ticast routing. This strategy is based upon the class-of-service (CoS) paradigm and is well suitable for DiffServarchitectures.

1.1 Multicast routing

The multicast routing problem is to find and establishthe most efficient path between a single or multiplesources and multiple receivers. As this problem is sim-ilar to the unicast routing problem, the solution is alsoexpected to be closely related.

To build a theoretical definition of the routing prob-lem, a computer network is represented as a graph G =(V, A), where each v ∈ V is a router and each a ∈ A isa communication link between two routers. Each graphedge has an associated cost c → R+.

For one-to-one (unicast) routing, the problem is theestablishment of the lowest-cost path between two ar-bitrary vertexes v, u ∈ V. For one-to-many or many-to-many (multicast) routing, a communication groupM ⊆ V is also defined, and the problem is to find alowest-cost subgraph R = (V ′, A′) connecting all groupmembers, that is M ⊆ V ′ ⊆ V. The R subgraph mustbe connected and acyclic, which are the properties ofa tree. To use R as a multicast route, m (m ∈ M)originated packets are replicated along all the edgesa ∈ A′. Some R vertexes may not be members of M andare only traversed by packets to reach group members.

The optimal solution results from the computation ofthe lowest-cost c = ∑

a∈A′ ca tree R′ = (M′, A′). Whenall the vertexes of graph G are members of the group,that is M = M′ = V (broadcast), the lowest-cost tree isnamed the minimal spanning tree (MST). There are sev-eral efficient algorithms to compute the MST. For theremaining trees, where there are vertexes not includedin the multicast group, M ⊂ V, the optimal solutionis the Steiner tree. The Steiner tree computation is aclassical problem of nondeterministic combinatory cal-culus, focused by research in the last 50 years. As a NPcomplete problem, suboptimal solutions are welcome,and there are several good Steiner tree approximations.Some of the existing heuristic algorithms [14] use, as afirst step, the reduction of a given Steiner problem intoa MST one.

1.2 Reverse path multicast

Steiner tree approximation algorithms are not used inreal multicast protocols because they are not scalableand most of them require a prior and complete knowl-edge of the multicast group membership. The relativedimension of network topology |V| and multicast group|M| are key issues on the choice of the multicast routingbest approach. If |M| ∼ |V|, the scenario is the densemode, and if |M| � |V|, the scenario is the sparse mode.In the former mode, there are several algorithms basedon flooding techniques. In the later one, a strategybased on explicit join requests is usually used, where themulticast tree is built finding the shortest path from thenew participant to the nearest node of the multicast treealready built. Flooding-based strategies have scalabilityproblems and they are often improved using reversepath forwarding (RPF) checking. RPF checking con-sists in the following: when a router receives a multicast

Ann. Telecommun. (2008) 63:579–596 581

packet, it checks if the packet’s incoming interface isthe one used by the router to reach the packet’s source.If it is, the packet is then forwarded through all theinterfaces of the router except the packet’s incominginterface. Otherwise, the router simply discards thepacket. This type of strategy leads to a multicast treethat is actually built in the opposite direction of theone used by traffic. A variant of this algorithm is usedby the dense mode variant of protocol-independentmulticast (PIM-DM [1]). In the sparse mode versionof PIM (PIM-SM [12]), multicast tree branches are es-tablished as PIM-join messages propagate towards therendezvous points (RPs) or the source. The multicasttree is built by explicit join request messages, but it isalso a reverse path tree. Assuming that link costs maybe asymmetric, the path taken by the join message maynot be the shortest path that actual traffic toward thereceiver should follow. Thus, the resulting shared orsource-based trees may not be optimal.

1.3 Asymmetric networks

The already defined multicast problem assumes a sym-metric network, represented by a undirected graph,where all group members, transmitters, and receivers,have an equivalent role. However, real communica-tion networks may be asymmetric due to the commu-nication links used and also, and in most cases dueto asymmetric network load conditions that are veryrelevant when there are QoS requirements, needed bythe traffic source nodes and even by the receivers. So,a more realistic model for a communication network isa directed graph. The above solutions based on Steinertrees or MSTs are not usable in such cases.

With asymmetric networks, the used approach is tobuild a tree assuming a group member (or even anarbitrary node at the center of the network topology)as the root, e.g., the source of the traffic. When themulticast tree is source-based, the complexity of theproblem grows (S times, where S is the number ofsources) as the multicast routing protocol needs to builda different tree for each potential source of the group.This characteristic is expensive when there are a largenumber of groups and sources. This is even worse forsparse groups on large network topologies. In suchcases, it would be better to build a single multicasttree for each group, shared by all sources, with a rooton a central and predefined node on the topology.Nevertheless, to find this central node in the presenceof dynamic groups is also a NP-complete problem. Thechoice of this central node is critical and influences thequality of the multicast tree built.

As the delay penalty for a shared tree in comparisonwith a source-based tree may reach an average of 1.4,some proposals give the receivers the possibility toswitch from an initial shared tree to a source-based tree.In this scenario, a new source starts its transmissionusing a shared tree, but it may also transmit using asource-based tree after some receiver issues a join to asource based-tree to request it. In the worst case, thereare (S + 1) trees for each group, one shared tree and Ssource-based trees.

One possible approach to build directed source-based trees is to use the shortest paths from the rootto each group member. The tree that results from thisstrategy is not the Steiner tree but it is a good approx-imation. The shortest-paths tree (SPT) is built using acentralized Dijkstra shortest-path algorithm. For thisreason, SPTs are frequently used in conjunction withintradomain link state algorithms, as open shortest pathfirst (OSPF) and IS–IS. The computation of multicastroutes is a simple extension of the unicast shortest pathalgorithm. However, this type of strategy does not scalewell because it maintains too much state informationin each node. For example, multicast OSPF (MOSPF)uses link state advertisements (LSAs) to ensure thatall nodes know about the current network topologyand link state information. Also, a group membershipLSA is used to ensure that all nodes know which arethe members of all groups. This amount of informa-tion brings complexity to nodes but also brings thepossibility to, at every instant, calculate the real SPTs(not reverse-path trees!) that connect any source to allmembers of a multicast group.

1.4 QoS routing

Routing in the Internet has so far been based on a best-effort service model, primarily concerned with connec-tivity. Packets are delivered using a route based ondestination addresses. Typically a single metric, a costassigned to each link, is taken into account to makeroute decisions. Thus, routing protocols build routingtables having the goal of minimizing the cost of eachpath. However, this model is not adequate to satisfythe growing demands of the applications, most of whichdemand QoS assurances. In order to support a widerange of QoS requirements, routing protocols needto have a more complex model where the network ischaracterized with multiple metrics, such as bandwidth,delay, and loss probability. The basic problem of QoSrouting is then to find a path able to satisfy multipleconstraints.

Most of these new metrics are network-load-dependent values, so even symmetric communication

582 Ann. Telecommun. (2008) 63:579–596

links become asymmetric ones due to the presenceof an asymmetric network load. It is assumed thatinstantaneous values of each metric result from directmonitoring of output links and can be kept updatedalong the time, as soft state information. Link metricscan be combined to find the corresponding value for thewhole path. This is done using composition rules thatdepend on the correspondent classification: additive(e.g., delay, jitter), multiplicative (e.g., losses), and con-cave (e.g., minimum bandwidth). Multiplicative metricscan be converted into additive ones using logarithmictransformation. Most of time, some of these path metriccompositions are applicable to multicast trees also.

QoS requirements are usually presented as a restric-tion set. Restrictions can be classified as link, path, ortree restrictions. When a group member is requestinga B bps connection to a group, this means that onlylinks with bandwidth equal to or greater than B maybe considered. The same is true for eligible paths andthe resultant tree. Path and tree are feasible if they cansatisfy requested QoS requirements.

Once requests have QoS requirements specified asa set of restrictions, a reformulated version of themulticast routing problem may be introduced. Givena network graph G = (V, A), a multicast group Mwith a set of tree restrictions CM and sequence ofjoin/leave requests E = (e0, e1, .., en), where each eventis described by (v, op, Cv), Cv is a set of restrictions forthe operation op of the new member v. The objectiveis the computation of a sequence of multicast treessatisfying CM and Cv restrictions.

A considerable number of QoS-aware algorithmsresult from extensions on existing multicast algorithms.Source-based trees usually need more network re-sources but have potential superior quality in both besteffort and QoS scenarios. On the other side, sharedbidirectional trees introduce some traffic concentrationand some degradation of end-to-end multicast sessions.Even with resource reservation mechanisms, the re-served resources must be shared by all group sources.Core router selection, not considering receiver QoSrequirements, also introduces difficulties on the setupof multicast routes. For flood-based algorithms, themulticast flow reaches the potential receivers beforeany explicit receiver request. In this way, receivers haveno chance to explicitly give their QoS requirements forpath selection.

The approximate Steiner tree with restriction-proposed solutions can be grouped into two mainclasses: distributed and centralized algorithms. The lastones assume that a single network node has a completeknowledge about group members. This assumption isnot suitable due to inherent dynamism of network load

dependent QoS parameters and group membership.In this way, partial information based strategies likepath probing are superior to others, at least in largetopologies, in which each node must have up-to-dateinformation of the global network state.

2 Interdomain multicast QoS routing

The global scenario for both intra- and interdomainmulticast routing is generally a two-tier problem, as itmay be depicted in Fig. 1, where different domains mayidentify different autonomous systems, eventually withvery different routing policies.

Most of the various proposals actually presented formulticast routing are, to a smaller or greater extent,somehow related with PIM, no doubt the most com-monly used multicast routing protocol. There are twomain PIM protocols, PIM-DM [1] and PIM-SM [12].PIM uses unicast routing information originating fromany routing protocol to perform multicast forwarding,instead of exchanging independent multicast routinginformation between routers. PIM-SM is used in mostcases, under the assumption that only a subset of net-works within any routing domain will be interested inreceiving any multicast group information.

PIM-SM [12] is then a widely deployed multicastrouting protocol, especially useful for groups wheremembers are sparsely distributed over the routing do-main. It is based upon the concept of RPs, predefinedpoints within the network known by all routers. Arouter with attached hosts interested in joining a mul-ticast group will start a multicast tree by sending a join

Domain E

PIM-DM

IGMP

PIM-SM

IGMP IGMP IGMP

DVMRP

PIM-DM IGMP

IGMP

IGMP

MOSPF

BGMP

BGMP

BGMP

BGMP

CBT

Domain A (Root Domain) Domain B

Domain C

Domain D

Domain F

BR

BR

BR

BR

BR

S2

BR

BR

R1

R2

R4

R3

S1

BR

BR

BR

Fig. 1 Hierarchical routing: intra- and interdomain multicastrouting protocols

Ann. Telecommun. (2008) 63:579–596 583

request message on the shortest path to the RP. Thisjoin request message is processed by all the routers inbetween the receiver and the RP so that a new branchfor the new member is setup within the multicast tree.

PIM-SM has important advantages when comparedto other multicast routing protocols: it does not dependon any specific unicast routing protocol and sourcerooted trees may be used, instead of the shared tree,if the data rate of a source exceeds a certain threshold.However, PIM-SM assumes symmetric routing paths asit uses reverse-path routing, and thus, it is not suitablefor use in conjunction with any kind of constraint im-posed by QoS routing.

Indeed, most of the deployed multicast routing pro-tocols, like core-based trees (CBT) [3], and PIM-SMare based upon reverse-path routing. Only multicastextensions to OSPF, MOSFP [18, 19], handling thetopological database as a directed graph, deal withasymmetric networks topologies. MOSPF has seen im-plementations and has been deployed in intradomainnetworks but cannot cope, because it does not scale,with interdomain.

There are few proposals for interdomain constrainedmulticast routing. Among those are border gatewaymulticast protocol (BGMP) [15, 22], yet another mul-ticast routing protocol (YAM) [6], QoS-sensitive multi-cast Internet protocol (QoSMIC) [11], and QoS-awaremulticast routing protocol (QRMP) [8].

BGMP is an interdomain multicast routing protocolable to cope with several of the scaling problems thatother multicast protocols exhibit. BGMP has severalfeatures that, like its unicast counterpart, the bordergateway protocol (BGP) [21], make it suitable forISPs usage. BGMP has been designed in order tosupport both unidirectional source and shared trees,as well as bidirectional shared trees for multicast datadistribution. Each type of tree is specially useful for

certain types of applications (e.g., unidirectional treesfor single-source and also for backward compatibility;shared trees for many-to-many distribution). BGMPis able to build shared trees that are rooted at theautonomous system where the multicast group addressoriginates, using several different mechanisms in orderto discover which autonomous system “owns” the mul-ticast group address being distributed.

So, BGMP nicely supports “source-specific multi-cast” and, by means of shared trees, is also able tosupport “any-source multicast.” Nevertheless, as a ma-jor drawback, BGMP has not taken any QoS metricinto account, although some extensions have later beenproposed. YAM, proposed by Carlberg and Crowcrof,builds shared trees with the capability to provide multi-ple routes to connect a new node onto an existing tree.

YAM establishes on-demand shared trees, handlingdynamic membership, making use of the discovery fea-ture associated with the one-to-many join mechanisms,as depicted in Fig. 2. Nevertheless, YAM does notrequire any global network state at routers, althoughit implies excessive communication overhead becauseit relies on flooding to find a feasible tree branch toconnect a new member.

YAM itself does not take into account any specificQoS metric but it is able to operate over alternatepaths. Several extensions to YAM have been proposed[7, 11], able to cope with multicast QoS requirements.

QoSMIC, proposed by Michalis Faloutsos et al.,alleviates the flooding behavior but introduces a newcomplex element: the manager router. QoSMIC usestwo different procedures to find a feasible tree: a localsearch and a multicast tree search. Local search, asshown in Fig. 2, is initiated by the new member routerby flooding BID-REQ messages to its neighborhood,with scope controlled by time to live. Any in-treerouter that receives a BID-REQ message becomes a

Fig. 2 Search policies fornew member: YAM (left)vs QoSMIC (right)

a

b

d

e h

c

Local search...

NewMember

Root

Distribution Tree..

Reaching range TTL=3

Reaching range TTL=2

Established

Reaching range TTL=1

a

b

d

e h

c

TTL=1TTL=2

NewMember

Local or in-tree Search ...

TreeManager

Root

Reaching ranges

Distribution Tree..Established

584 Ann. Telecommun. (2008) 63:579–596

candidate router and replies with a BID message, whichis unicast to the new router. The BID message collectsinformation about the path on its way that can beused for selection purposes. The multicast tree searchoccurs at the same time, initiated by a manager afterreceiving a M-JOIN request from the new receiver. Themanager sends a BID-ORDER message to a set of in-tree routers, that become candidate routers and replywith BID messages exactly as described for the localsearch procedure.

In QRMP [8], proposed by Shigang Chen et al. in2000, two search modes are defined: single-path modeand multiple-path mode. The routing process startswith the single-path mode, attempting to search onlythe unicast routing path travelled by the join requestmessage through the multicast tree. The join requestmessage carries the QoS requirements. As it travels, itchecks the resource availability of every intermediatenode and proceeds only when the node has the requiredresources. If an intermediate node does not have therequired resources, it triggers the multiple path modeby sending a not acknowledge message to the previousnode. Upon receipt of the not acknowledge message,the previous node sends the join request message toall neighbor nodes except those from which the joinrequest messages and not acknowledge messages werepreviously received. Once a feasible branch is detected,an acknowledge message is sent back along the branchthat triggers the multiple path mode. If more then oneacknowledge message arrives at this node, the nodewill select the best branch and reject all the others. InQRMP, tree construction occurs from the new receiverin the direction toward the tree instead of from thefirst in-tree node found backwards toward the receiver;therefore, it does not seam adequate for asymmetrictopologies. In multiple-path mode, the join requestmessages are flooded. Besides, it does not support theestablishment of multicast routing policies.

3 CoS multicast routing: a new approach

There are two different approaches in order to pro-vide QoS to routing processes: per flow and per classrouting. Per flow routing strategies are based on theprinciple that QoS routes must be computed for eachrequest, being that requests explicitly express their re-source requirements, resorting to resource reservationin order to maintain those requirements after a feasiblepath has been found. This type of strategy can be easilyadapted to the multicast scenario. In a multicast sce-nario, the path searching process is usually initiated bythe new receiver, which explores different alternative

paths and evaluates them in terms of how well they fulfilrequirements. When a feasible path is found, a newmulticast tree branch is built joining the receiver to themulticast tree. This type of strategy is usually adoptedby interdomain multicast QoS routing strategies, likeYAM and QoSMIC, because it does not require thenodes to keep global state information. There is noneed to keep any type of link state information sinceQoS path metrics are evaluated by each node duringthe setup phase. Nevertheless, after a feasible path isfound, per-flow information is kept in those in-pathnodes. As the number of simultaneous per node flowsmay grow indefinitely, resource consumption becomesa critical issue.

The alternative approach is per-class routing. Insteadof trying to deal with each specific flow individually, theidea is to group them into a small amount of predefinedclasses. Packets on each flow are first marked into oneof the available classes and receive, thence, a class-specific treatment in all forwarding tasks. By changingthe focus from flows to classes of flows, this approachreally introduces a big paradigm shift. Flows are aggre-gated by affinity in terms of QoS requirements, thusmaking per-flow strong guaranties difficult to achieve.However, since the number of classes is both smalland well known, routes can be precomputed per classinstead of computed on demand. Since routes can differfrom class to class, there is an enormous potential fortraffic engineering and class differentiation by meansof routing differentiation. This approach has been pro-posed for unicast but not yet for multicast, or at leastnot with the same conviction. However, this strategycan easily be used in multicast, with the same benefitsand the same withdraws as in unicast.

In a DiffServ multicast scenario with heterogeneousgroup members, each one demanding a different CoStreatment, multiple multicast trees should be built (in-stead of a route per CoS like in unicast routing), atleast one tree per CoS, in order to comply with dif-ferent per-class QoS requirements. Thus, each routerwill have to deal with more state information than intraditional multicast routing; however, the total numberof different classes will be much smaller than the totalnumber of members in a multicast group. So, a realimprovement is expected.

Another problem that must be solved in order toimplement QoS multicast routing is the way multicastdistribution trees are built. Most of the deployed multi-cast routing protocols, such as DVRMP [23], CBT [3],and PIM-SM, are based on reverse path routing. OnlyMOSFP [18] handles asymmetric network topologiessince the topological database in MOSFP is stored asa directed graph. In PIM-SM, the packet deliver path

Ann. Telecommun. (2008) 63:579–596 585

is set-up as PIM-join messages propagate towards theRP or the source. Therefore, the multicast distributiontree actually built by PIM-SM protocol is in fact amulticast reverse path tree, as it is built in the oppositedirection to the one used by multicast traffic. This is animportant problem to address when dealing with QoSrouting because these routing constraints expose linkasymmetry in terms of the QoS they offer. Due to theseasymmetries, the path taken by the join request messagemay not be the shortest path that data traffic shouldfollow. Thus, the resulting trees, shared or source-based, may not be optimal. In order to address themulticast routing problem, aware of DiffServ context,a new strategy is therefore proposed: a strategy basedon establishing directed multiple CoS multicast trees.

3.1 Directed shared tree construction

In order to give receivers the ability to join a groupwithout knowing a priori who and where the sourcesare, a shared tree is established to begin with.

To build a directed shared tree, explicit join requestmessages issued by new receivers must be sent towardsthe RPs router. When the RP router receives a join re-quest message, it must send back an acknowledgementpacket. This acknowledgement packet is sent back tothe receiver along the shortest path between the RProuter and the new receiver; this path may differ fromthe one followed by the join request message.

Routers along this path, when receiving such an ac-knowledgement packet, may then update their routingtables in order to build new multicast tree branches.Updating is basically accomplished by registering withthe multicast routing entry for that tree, both the in-coming and outgoing router interfaces traversed byacknowledgement packets.

When CoS multicast routing is considered, a sharedtree per CoS is needed (instead of a single shared mul-ticast tree) in order to enable sources to start sendingdata within any class. It is assumed that the total num-ber of “available” classes of service has a preestablishedupper limit and is small, when compared to the numberof group members. Figure 3a, b illustrates a receiverjoining directed shared trees.

Data packets issued by sources, previously markedaccording to source-defined QoS parameters, are senttowards the RP router. This RP router forwards datapackets, based on the CoS they are marked with, usingone of the shared trees.

When a new receiver decides to join, the designatedrouter sends an explicit join request towards the RProuter. Routers along the way between the new re-ceiver and the RP just forward the join request message

and no state information is kept. When the RP receivesa join request message from a new receiver, it must senda join acknowledge message per CoS. These messagesmust travel towards the new receiver through the bestavailable unicast path per CoS, building new branchesin each CoS multicast tree (see Fig. 3b). When joining agroup, receivers may initially connect to any of the RPshared trees.

3.2 Heterogeneous QoS receivers: switchingfrom shared to source-based trees

The multiple RP shared tree mechanism, presented sofar, does not really allow receivers to specify theirown QoS requirements. Traffic flows from sources toreceivers using one of the shared trees, according tothe QoS parameters defined by sources. After a startingperiod, a receiver may demand for a reclassificationof source multicast traffic. This issue cannot be ac-complished by a shared tree, but it may be met if thereceiver joins a source-based tree. When initiating thejoin to source procedure, the receiver should specifythe desired CoS and include it in the join requestmessage. It is up to the source to decide whether or notto accept the join, knowing that, when accepting a join,traffic in the requested CoS must be generated.

When accepting a join for a new CoS, a source mustgenerate an acknowledge message, addressed to thecorresponding receiver. This procedure is similar to theone described for the construction of the shared trees,being that now a single join acknowledge message perjoin request is generated. Two different situations maystill occur: the receiver decides to switch to a sourcelying in its own domain or it may want to switch to asource in a different administrative domain.

3.2.1 Join a source-based tree in the sameadministrative domain

Even in this specific situation, two different types ofsource-based tree join may occur: the receiver decidesto switch to a source-based tree in the same CoS or itmay decide both to switch to a source-based tree andrequest a different CoS.

The first case is similar to the switch, from sharedtree to source-based tree, issued by a receiver in PIM-SM, with some changes due to the directed nature ofmulticast trees. In PIM-SM, when a receiver decides toswitch from a shared to a source-based tree, it sends ajoin request message to the source. All routers in thepath between the receiver and the source are responsi-ble by building the new tree branch in the source-basedtree. Besides, when a router lying between the source

586 Ann. Telecommun. (2008) 63:579–596

Class (i) TreeClass (j) Tree

RP (all trees)

S1

S2

R2

R1

S3

New Member

Join(*)Ack(i)

Ack(j)

R1, R2, R3 - ReceiversS1, S2, S3 - Sources

(a) New member joins shared trees on all classes

Class (i) TreeClass (j) Tree

RP (all trees)

S1

S2

R3 R2

R1

S3

R1, R2, R3 - ReceiversS1, S2, S3 - Sources

(b) Resultant shared trees per class-of-service

Class (i) TreeClass (j) Tree

RP (all trees)

S1

S2

R3 R2

R1

S3

Join(S1,i)

Ack(i)

R1, R2, R3 - ReceiversS1, S2, S3 - Sources

(c) New member requests a specific class to a source

Class (i) TreeClass (j) Tree

RP (all trees)

S1

S2

R3 R2

R1

S3

R1, R2, R3 - ReceiversS1, S2, S3 - Sources

(d) Resultant set of shared and source-based trees

Fig. 3 Intradomain multiple tree construction (a–d)

and the receiver starts receiving data from that source,it must issue a prune of that source on the shared treebecause now packets must be received via the source-based tree and not from the shared one. When buildingdirected trees, the same idea is to be applied, with someminor changes. Here, the new source based tree branchis built by a join acknowledge message instead of thejoin request message.

In [20], the source-based tree join request messagesent by the receiver is just forwarded towards thesource by all the routers along the path. When thesource receives the join request message, it sends back a

join acknowledge message towards the receiver and thismessage will induce the construction of the new treebranch. Each router in the path between the source andthe receiver will process and forward the join acknowl-edge message, updating its routing tables. The interfaceto be added in the corresponding outgoing interface listis the one that has been used to forward the join ac-knowledge message. When one of the routers belongingto the new multicast tree branch begins receiving trafficfrom the source, it must issue a corresponding pruneon the shared tree of that class. This prune indicatesthat packets from this source, on CoS i, must not be

Ann. Telecommun. (2008) 63:579–596 587

forwarded using this branch of the shared tree becausethey are being received by means of the source-basedtree. This mechanism is implemented by sending aspecial prune to the upstream neighbor in the class ishared tree. When a router at the shared tree of theclass i receives this type of prune, it creates a specialtype of entry [an (i,S,G)RPT-bit entry], where theoutgoing interface list of the new (i,S,G)RPT-bitentry results from a copy of the (i,*,G) entry; theinterface to be deleted is the one being used to reachthe node that issued the prune (may not be the ar-riving interface of the prune packet). This is becausewe are dealing with directed trees, not reverse-pathones. These (i,S,G)RPT-bit entries must be up-dated whenever a join acknowledge message arrives inorder to enable any new receiver to join a shared tree(even if it had source-specific prune state established).

When a receiver decides to join a source, requestinga different CoS, the process develops as depicted inFig. 3c, d. When a new (i,S,G) entry is created, theoutgoing interface list should not be copied from the(i,*,G) entry because, in this case, the other receiversconnected through the corresponding shared tree stillneed to receive data packets in the source’s defaultCoS. For the same reason, these entries should not beupdated when a posterior join to shared tree acknowl-edge message is received. In addition, the “prune ofsource in the shared tree” mechanism must be triggeredby the receiver when it receives the join acknowledgemessage. The prune messages must be sent to theshared trees of all classes, except to the shared treeof the class for which the receiver recently commuted.This is because the receiver will start to receive thesource’s packets via the source tree in the desired class,so it should not keep on receiving them via the sharedtree established for the source’s default CoS. Figure 3summarizes the process of multiple tree construction inthe intradomain.

3.3 Connecting administrative domains

Despite the huge number of QoS multicast routing pro-posals that have emerged in the past few years, very fewwere actually designed for the dual-level hierarchicalmodel of the current Internet. This is also true for non-QoS-aware protocols.

One of the most common difficulties, absent in in-tradomain routing, is the need to address policy issues.Domains are delimited by administrative boundariesand domain border routers must be configured to en-force domain policies. This is usually carried out byfiltering routing information that enters or leaves adomain. BGP long life lasting derives mostly from its

policy friendliness. Because BGP routes are qualifiedwith a full AS-Path attribute, it is not hard to writecomplex filtering patterns without the risk of inducingloops. This issue really changes the focus of interdo-main routing: from efficiency to political connectivity.With such a focus, QoS usually turns out to be a sec-ondary issue.

Furthermore, in order to preserve domain indepen-dence, it is also desirable that independent domainsdo not have to rely on external resources managedby others. This simple nontechnical issue frustrates theconstruction of global shared trees rooted at singleexternal RP nodes.

Another specific interdomain problem is the accu-racy of the QoS information collected. Currently, aroute update can take several minutes to spread acrossmultiple domains. Absolute measures of QoS metricslike bandwidth, losses, or delays are useless in such atime interval. Efforts are therefore directed to providestatistical values, such as means and deviations, whichare more valuable in near future predictions [16]. Theengineer task turns out to be selecting the right amountof information to include in summary metrics withoutseverely degrading its accuracy.

All other issues are common to both intra- and inter-domain levels but are eventually more stressed by scaleand policies. One example is the asymmetric natureof routing. As pointed out in the intradomain section,routes are asymmetric when dynamic QoS metrics areconsidered. Resource consumption depends upon flowsadmitted; for most multicast applications, flows showintense packet rates from sources to destinations andalmost no traffic in the reverse direction. A good path inone direction may not be a feasible one for the reversedirection. Interdomain specific issues, like policies, en-force this asymmetric nature.

3.4 CoS and non-CoS domains coexistance

The analysis of interdomain specific requirements leadsto a fundamental question: can we simply expand theintradomain strategy presented so far or is it inadequateaccording to those requirements?

Preserving domain independence implies allowingeach domain to decide whether to use CoS or not. Itimplies also to allow domains to not depend on externalRPs, as already pointed out. This compromises thegoal of multiple shared trees at the interdomain level,but not its usage inside the domain. RPs within eachdomain can establish peer relations between them, asin MSDP [13] or [9], in order to exchange informationabout their active sources. Some announcements willcarry CoS, while others will not.

588 Ann. Telecommun. (2008) 63:579–596

Figure 4 illustrates this relationship with non-CoSdomains. A CoS domain internally builds multipleshared trees, a tree for each class, and announces allits sources to external peers with the associated CoS.Classes are supposed to be standard and well knownby all domains, without invalidating the freedom to usethem or not. It is also assumed that it is always possibleto map a set of QoS metrics obtained for a flow, a link,or a path into a specific CoS. A mapping function, aswell as its reverse function, are both needed in order toavoid class mismatches.

Domains having no members on a specific group willjust resend the announcement to all peers except theoriginator. Non-CoS domains having active receiversinside will probably proceed with a join to that source,as usual, ignoring any class mark Fig. 5a. CoS domainsshould consider all external unmarked announcementsas belonging to a default class.

Figure 4b illustrates the way two CoS domains couldinteract. Each domain announces its sources’ availabil-ity with the correspondent CoS. In order to providetraffic to its domain receivers, RPs join the interdomaintree for the CoS the source announces. An internalreceiver, within any domain, may shift to a source-

specific tree branch, on the same or on any other CoS,by sending a join request message on the desired CoS.This is also illustrated in Fig. 4b.

3.5 Interdomain via path probbing: effortvs. efficacy trade-off

The next question is how to build the interdomain QoS-aware multicast tree. In intradomain, precomputed uni-cast paths can be used if they exist on unicast routingtables. A CoS unicast routing protocol may be usedin order to find the best unicast path per CoS. How-ever, applying this type of strategy to the interdomaincontext introduces some scalability problems related tostate information accuracy and memory consumptionon routers.

The alternative is to build tree branches on demand,probing the QoS of the available paths. Special caremust be taken in order to build directed trees insteadof reversed path ones because asymmetries are highlystressed at the interdomain level.

Probing techniques pointed out so far differ basicallyin the spread of network regions covered by the probes

Class(j) Tree

RP (all trees)

R1

S1 S2

R2

RPRP

Join(S1)Join(S2)

Non-CoS Domain(Y)CoS Domain(X) Non-CoS Domain(Z)

Source Annouce (RP(x),S1,Class(j)) Source Annouce (RP(z),S2)

Class(i) Tree

(a) Source announcements exchanged with non-CoS domains

(b) Joining external sources requires QoS map functionsClass(j) Tree

RP (all trees)

R1

S1 S2

R2

RPRP

Non-CoS Domain(Y)CoS Domain(X) CoS Domain(Z)

Join(S2,Class(i))

Source Annouce (RP(z),S2,Class(i))Source Annouce (RP(x),S1,Class(j))

Join(S1,Class(j))

Join(S1,Class(i))

Class(i) Tree

Fig. 4 Interconnecting administrative domains (a, b)

Ann. Telecommun. (2008) 63:579–596 589

and in the direction they follow. Larger areas probedmeans greater efficacy but also a greater control over-head. There is a clear trade-off between the number ofprobes launched and the number of feasible paths thatcan be found. Techniques like YAM perform well whenthe new member is in the neighborhood of an existingtree. This is, of course, unlikely to occur in large net-works. This technique can be turned up by enlarging thesize of the expansion rings used, but the overhead growsexponentially. Other approaches, such as QoSMIC, tryfirst to locate the multicast tree and then select a subsetof in-tree nodes to launch probes. This technique canbe turned up on the in-tree node selection procedure.The best results are, however, achieved if all in-treenodes launch probe messages, but that introduces hugeoverheads. Perhaps the best approach, in this effort vsefficacy trade-off, is the one followed by QRMP: firstfollow the usual path towards the tree and measure it;launch probes in multiple directions only if the obvious

path is not feasible. This technique can also be tunedup by controlling the number of times a probe can beforked. It has, however, a major drawback: the direc-tion of the probing process. Paths are probed from newmembers to tree roots, and they should be issued in thereverse direction, due to asymmetries.

The path probing strategy proposed here is based onthese key ideas: find the tree as fast as possible, launchprobes in the downstream direction, and increase prob-ing efforts only when paths cannot be found. The strat-egy description that follows will show that these optionslead to the best fit to the interdomain level.

3.6 Interdomain tree branches construction

Figure 5 shows the way interdomain trees are con-structed. Multiple domains are connected by borderrouters that exchange MBGP routes. Policies are ap-plied first by filtering MBGP announcements, sent or

InterDomainTree Root: S

New Member: N1

2

3

3

4

56

4

4

1. N sends Join(S,Class)2. Join(S,Class) is forwarded until it reaches the tree in T3. T sends 3 probe messages Answer(N,Class) to N4. Two probes fail in first step, and Nack(T,Class) are sent back The other probe proceeds to N5. Last probe also fails and another Nack(T,Class) is sent6. Nack() is forwarded to T that detects fails on all possible available paths to N.

T

(a) First in-tree node found conducts probing process

InterDomainTree Root: S

New Member: N

7

8

910

1112

13

7. After detecting path probe failure, intree node T forwards Join(S,Class) towards S

8. Join reaches S that lauches only one probe to N. Avoids others because they will fail.

9., 10. The probe is successfully forwarded until it reaches N

11. N selects that path as the best one available, and sends Ack(S) to establish it.12, 13. Ack establish path to S

T

(b) Limited retries are issued further inside the tree

Fig. 5 Interdomain tree built by path probing strategy (a, b)

590 Ann. Telecommun. (2008) 63:579–596

received. So, only policy compliant routes remain to beused on multicast tree construction.

An interdomain tree is needed only when a receiver(or a RP-node on the receiver’s behalf) decides tojoin an external source. The request to join is gener-ated either within the original class, extracted from thesource announcement received, or in a different one, ifexplicitly expressed by receivers.

The join request message is forwarded between bor-der routers, without creating state information, until itreaches the first node already in the source tree for thatCoS. Note that the request is not forwarded up to thetree root, as it was inside the domain, in order to avoidoverloading it. Tree branches are constructed basedon the QoS values maintained on each tree node andloops are avoided by analyzing the AS-path value of thebranch. After having received the join request message,the newly found in-tree node sends a probe message onevery possible path, directed to the requesting domain.That is the right way to cope with asymmetries.

Each node that receives a probing message mustupdate its QoS path value by using the measured QoSon the next link in the path leading to the joining node.If the computed cumulate QoS value can no longerbe mapped into the requested CoS, or if the node isalready in the tree, the probe procedure fails. In thiscase, a negative ack is sent back to the in-tree node thatis controlling the probe process.

Eventually, one or more probes do reach the newmember and a path is selected. However, if all attemptsfail, as illustrated in Fig. 5a, a new retry must be initi-ated, further inside the tree, by resending the originaljoin request towards the tree root. The total number ofretries is limited to keep the strategy scalable. The nextnode that receives the request will then conduct its ownprobing, using exactly the same procedure. As soon asthe new member receives one valid probe message, itestablishes the new tree branch by sending an ack onthis specific path.

4 Experiments in multiclass multicast routing

4.1 Experimental setup

NS [10] has been used in order to simulate and evaluateour multicast routing proposal. First, directed treesconstruction inside a single domain has been imple-mented and results have been compared with a PIM-SM implementation. In these simulations, the CoS linkstate protocol (CoSLSP) has been used. CoSLSP is aCoS unicast routing protocol based on LS (a link-state

unicast routing protocol implementation included inNS-2 distribution).

CoSLSP aims to provide a class-based unicast rout-ing mechanism. The basic idea is to find one route perCoS, able to satisfy the QoS requirements of that class.It is a unicast link-state protocol that uses a modifiedDijkstra algorithm capable of finding the shortest pathroutes, if they exist at all, that can meet the QoSrequirements of different classes of service. In a fewwords, the path calculation algorithm starts by find-ing the shortest path, whose feasibility is then verifiedagainst the QoS requirements. If unfeasible, the nextshortest path is then iteratively verified until a feasiblepath is found or a configured threshold is reached. Inthis way, a different route is found for each CoS andit is installed in the unicast routing table. The packetforwarding process has been modified too in order tolookup for the appropriate route depending on the CoSof each packet. These CoS paths in unicast routingtables are used by join acknowledge messages, whichtravelled from RP and sources to receivers in orderto build CoS-directed multicast trees. This was just asimple way to achieve per-CoS routes in unicast routingtables.

4.2 Used metrics

To evaluate the proposal, different metrics have beenused. First of all, it is needed to measure the quality ofthe multicast trees built. The best way to achieve this,since there are multiple trees, is to count the numberof data packet replicas that are originated by nodeswhile forwarding those packets across the distributiontree. In order to realize how well the tree construc-tion mechanism deals with link asymmetries, instead ofusing only the number of data packet replicas, a metriccombining this number with the cost associated to eachlink traversed by each packet replica is used.

The second thing we intend to evaluate is the gainof using CoS multicast routing. In our simulation ex-periments, CoS requirements were defined in termsof packet losses. Therefore, to measure the gain ofour multiclass multicast routing strategy, we used theaverage packet drops that occurred in the flows of eachCoS (Fig. 6).

4.3 Results obtained

The topology used in the first simulation scenario (asingle DiffServ domain) is a typical large ISP network[2]. This topology (Fig. 6) includes 36 nodes; 18 of themare core nodes, and the other 18 are edge nodes. Eachof the core nodes is connected with one edge node

Ann. Telecommun. (2008) 63:579–596 591

33

26

34

29

30

16

17

15

10

14

2

13

20

12

18

11

19

25

9

23

27

7

28

8

31

6

32

5

35

4

21

3

221

24

0

Fig. 6 Typical large ISP topology

by a symmetric link with the cost 1. The core nodesare interconnected with each other by 30 asymmetriclinks. There are different alternative paths with differ-ent costs between any pair of core nodes. Link costs areintegers randomly chosen from the interval [1, 12].

Three different classes of service with different QoSrequirements in terms of losses were considered. Class1 does not support any losses; class 2 supports welllosses; and, finally, class 3 can deal with greater losses.Each link has three physical queues (one per class) andtwo virtual queues corresponding to two different dropprecedence. All queues are configured exactly in thesame way in order to prevent inside node differentia-tion. Therefore, the only class differentiation that canoccur is caused by the action of the routing protocol.

For each simulation run, only one group is consid-ered, and the RP is randomly chosen within the set

of all nodes. There are four fixed sources, and eachsource generates traffic in a CoS randomly chosen. Itis assumed that a single receiver is connected to eachedge node in the topology and that all edge nodes haveone potential receiver attached.

At the beginning of the simulation, there are noreceivers joining the group. After an initial period,nine receivers start to join the group building threeshared trees rooted at RP. After all the receivers havejoined, eight randomly chosen receivers join the fourdifferent sources requesting a CoS that is also randomlychosen. This scenario is then kept until the end of thesimulation. Before the simulation ends, all the receiversleave the group.

Simulation results are presented in Figs. 7 and 8,where shown values reflect the computed average after100 independent simulations.

Figure 7 shows the characteristics of the trees builtwith the two strategies (MCMRP and PIM-SM). Thecurves presented in Fig. 7a show the average tree costin function of number of receivers. The tree cost ismeasured in terms of number of replicas timeslink cost. The curves presented in Fig. 7b show thetotal number of links in the topology that are involvedin the multicast trees as a function of the number of joinor leave operations.

The results shown in Fig. 7a bring to evidence thatCoS trees have costs smaller than those created byPIM-SM. This is because they are directed trees insteadof reverse-path trees. Note that CoSLSP, the underly-ing unicast routing protocol, does not choose the bestunicast routing path; it chooses the best unicast paththat, furthermore, can also meet the QoS requirementsof each CoS. Even with this characteristic, it is able to

0

10

20

30

40

50

60

0 1 2 3 4 5 6 7 8 9

Ave

rage

Tre

e C

ost (

Rep

licas

* L

ink

Cos

t)

Number of Receivers

MCMRP with CoSLSPPIM-SM with LS

(a) Tree Cost(number of replicas times the link cost)

0

5

10

15

20

25

30

35

0 1 2 3 4 5 6 7 8 9

Ave

rage

Tre

e C

ost (

Num

ber

of L

inks

)

Number of Receivers

MCMRP with CoSLSPPIM-SM with LS

(b) Number of Links in the multicast trees

Fig. 7 Multicast trees quality (a, b)

592 Ann. Telecommun. (2008) 63:579–596

build better trees than PIM-SM. In addition, observingFig. 7b, we conclude that MCMRP is able to build bettertrees than PIM-SM without enlarging their size.

Figure 8 shows the average packet drops sufferedin function of number of receivers. Figure 8a, b, andc show the average packet drops that occurred inthe flows of each CoS when using the two protocols(MCMRP and PIM-SM). Figure 8d shows the resultsobtained for all the three classes, in terms of packetdrops per flow, when using MCMRP.

These results demonstrate that when MCMRP isused a considerably lower amount of drops is veri-fied. This is because MCMRP try to find routes lesscongested when links became bottlenecks. In addition,results show that MCMRP routing strategy promotesthe expected differentiation between classes. Observ-ing Fig. 8d, we conclude that the average number ofpacket drops suffered by class 3 is greater than the

average number of packet drops suffered by class 2and the average number of packet drops suffered byclass 2 is greater than the average number of packetdrops suffered by class 1. This is because class 1 hasthe highest QoS requirements, followed by class 2, andfinally, class 3 is the least demanding one.

5 Experiments in interdomain via path probing

5.1 Experimental setup

NS [10] was also used to simulate and evaluate ourproposal at the interdomain level. Interdomain treebranches are created only when a new member joins asource-based tree rooted at another administrative do-main. When that happens, a path probing procedure isinitiated. In this set of simulations, two other protocols

0

2

4

6

8

10

12

14

16

18

0 1 2 3 4 5 6 7 8 9

Ave

rage

Per

Flo

w D

rops

/s

Number of Receivers

class1 MCMRP with CoSLSPclass1 PIM-SM with LS

(a) Flow Drops-Class 1

0

2

4

6

8

10

12

14

16

0 1 2 3 4 5 6 7 8 9

Ave

rage

Per

Flo

w D

rops

/s

Number of Receivers

class2 MCMRP with CoSLSPclass2 PIM-SM with LS

(b) Flow Drops - Class 2

0

2

4

6

8

10

12

14

16

0 1 2 3 4 5 6 7 8 9

Ave

rage

Per

Flo

w D

rops

/s

Number of Receivers

class3 MCMRP with CoSLSPclass3 PIM-SM with LS

(c) Flow Drops - Class 3

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9

Ave

rage

Per

Flo

w D

rops

/s

Number of Receivers

class1 MCMRP with CoSLSPclass2 MCMRP with CoSLSPclass3 MCMRP with CoSLSPclass4 MCMRP with CoSLSP

(d) Flow Drops per Class-of-Service

Fig. 8 Average packet drops (a–d)

Ann. Telecommun. (2008) 63:579–596 593

have been used: QoSMIC and PIM-SM. They are seenas top and bottom lines in results analysis. PIM-SMis the obvious bottom line because it connects eachmember on the shortest path towards the tree withoutdoing any probings at all. On the other hand, QoSMICis the reference for upper values because it can be con-figured in very aggressive local and tree-based searchprocedures.

GT-ITM [5] and BRITE [17] were used to generateinterdomain topologies. Those topology generators usedifferent methods to synthesize topologies that can berepresentative or have characteristics similar to theautonomous system structure of the Internet. Examplesof the topologies generated are presented in Fig. 9.

Simulations were run only at the interdomain level,ignoring inside domain routing approaches. Relationsbetween intra- and interdomain were not consideredat this phase. A domain is therefore abstracted as asingle node that initiates a join procedure. Instead ofbuilding complex traffic generation scenarios, the avail-able bandwidth at each link was also generated withuniform distribution in the interval 1.5–10 Mb. Heavytailed and exponentional distributions were also con-sidered. Traffic generation has been avoided because itis very expensive in computational terms and usuallyimpracticable. From extensive conducted experimentswith different scenarios, only the node degree functionseems to affect the results. Other parameters do notimpact protocol comparison.

Since all path probing actions occur only when nodesjoin the group and no tree reconstruction is done at

leave events, only join operations were considered ineach simulation scenario. For each simulation, a nodewas randomly chosen as source and tree root. Then,one by one, 60% of all nodes join the group. Eachnode is randomly chosen among all unconnected ones.Multicast receivers attached try to connect on pathswith higher available bandwidth. The multicast sendergenerates CBR traffic and 100 simulations were run foreach topology.

5.2 Used metrics

The goal of the path probing strategy is to find thebest available path that can be used to connect a newmember to the multicast tree, according to its QoSrequirements. So the first step to evaluate this proce-dure is to define the path quality, in terms of QoS, andmeasure it for all joining members. This QoS obtainedmetric can therefore be used to compare the efficacy ofthe probing strategy.

In this set of experiments, we have considered pathquality as a function of the available bandwidth. Avail-able bandwidth on a path is the minimum availablebandwidth of all its links. Values are collected for theentire tree branches, from the tree root towards thenew member. Each routing strategy, after path probing,provides a set of available connecting branches to thenew member. Within the set of results, the best possiblepath is the one with the higher available bandwidth.From the new member perspective, the most efficaciousstrategy provide paths with higher available bandwidth.

Fig. 9 Examples of BRITE AS (100) and GT-ITS (600) interdomain topologies

594 Ann. Telecommun. (2008) 63:579–596

Success measures can be stressed graphically with thepercentage of members vs the QoS obtained.

To measure the efficiency of the path probing strat-egy, the construction effort is estimated in terms of thenumber of control messages generated by each oper-ation and the time spent in the entire probing phase.Some multicast routing approaches achieve better ef-ficacy but at the expense of more construction effort,so to be more fair on result analysis, all metrics areneeded.

5.3 Results obtained

Figure 10 presents a set of results obtained when eval-uating the path probing strategy. The top two graphics(Fig. 10a and b) show efficacy measures for the synthe-sized topologies illustrated in Fig. 9. Figure 10a showsQoS obtained for the BRITE AS (100) topology for allprotocols. As expected, PIM-SM appears as the bot-tom line. This graph shows that the proposed strategyperforms good but not as well as QoSMIC when only

the first intree node launches probe messages. Thegraph shows that, with PIM-SM, only 50% of the mem-bers that joined the group achieve more than 3 Mbpsavailable bandwidth. That percentage grows to almost70% when using the proposed strategy and to near 80%with QoSMIC. However, the performance improveswhen the number of retries is increased. For two re-tries (two intree nodes initiate the probe procedure),the results are already similar to the normal QoSMICversion. This brings to evidence that inside tree searchis a good approach, and it can avoid the complexityof the tree manager element in QoSMIC architecture.This improvement remains true for the GT-ITM AS(600) topology.

The relative positions of the other protocols remainthe same in both graphics, showing no strong evidencethat the type of topology affects results. This readingcan be later transformed into a conclusion if confirmedby further experiments.

The two bottom graphics (Fig. 10c and d) show theefficiency metrics for the larger topology. The number

QoS (available bandwidth)

Join

Per

cen

tag

e

0Mb 1.5Mb 3.0Mb 4.5Mb 6.0Mb 7.5Mb 9.0Mb

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%PIM-SMQoSMICQoSMIC (mcast only)QoSMIC (full)PAQoSIDMRPAQoSIDMR (retry 2)PAQoSIDMR (retry 3)PAQoSIDMR (retry all)

(a) QoS obtained by Receivers on BRITE AS (100) topologies

QoS (available bandwidth)

Join

Per

cen

tag

e

0Mb 1.5Mb 3.0Mb 4.5Mb 6.0Mb 7.5Mb 9.0Mb

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%PIM-SMQoSMICQoSMIC (mcast only)PAQoSIDMRPAQoSIDMR (retry all)

(b) QoS obtained by Receivers on GT-ITM AS (600) topologies

Number of Join/Leave Operations

Nu

mb

er o

f C

on

tro

l Mes

sag

es S

ent

0 20 40 60 80 100 120

0

10000

20000

30000

40000

50000PIM-SMQoSMICQoSMIC (mcast only)PAQoSIDMRPAQoSIDMR (retry all)

confidence intervalat 95% confidence level

(c) Control messages over head on BRITE AS (100) topologies

Time (seconds)

Lat

ency

(se

con

ds)

0 100 200 300 400

0.0

0.1

0.2

0.3

0.4 PIM-SMQoSMICQoSMIC (mcast only)PAQoSIDMRPAQoSIDMR (retry all)

confidence intervalat 95% confidence level

(d) Join Latency on GT-ITMAS (600) topologies

Fig. 10 Simulation results: interdomain tree branch construction (a–d)

Ann. Telecommun. (2008) 63:579–596 595

of control messages needed to do the probing andconnect a new member is counted for every join eventoperation, and an average of all simulations is com-puted. Results are presented graphically using the ac-cumulated values in order to stress the differences. Thenumber of control messages is therefore always increas-ing as the number of join events increases. Results showthat PIM-SM has little overhead and that the proposedstrategy uses fewer control messages than QoSMIC.The join latency (time spent in the join procedure)is also presented in Fig. 10d. The normal QoSMICstarts with greater join latency because its local searchprocedure is unable to find any intree node in the newmember neighborhood when the group is small andsparse. It becomes more effective for larger groups(join events increase with time). When we use only thetree-based search procedure of QoSMIC (QoSMIC-mcast), the values become more stable in time becausethey only depend on the distance between the newmember and the tree manager that conducts the prob-ing procedure. The join latency value is smaller forthe proposed strategy because it only depends on thetime to reach the first intree node. The values do notincrease with the number of retries because, in thesesimulations, they are launched all at once.

6 Discussion and future work

Multicast has somehow been put aside from the dif-ferentiated service QoS model simply because it mayinvolve tasks that are too complicated for domain corenodes. While packet replication is not complex at all,and may be allowed inside the domain, that is no longertrue for packet classification and marking, usually doneat edge routers. One of the problems to face is thedifficulty to reflect receivers’ QoS requirements, due tothe unidirectional nature of DiffServ: packets are to bemarked in the downstream path to the receivers.

At the interdomain level, difficulties arise from theneed to interconnect different administrative domains,either DiffServ or non-DiffServ. Notice that traditionalany-source multicast model allows multiple sources andreceivers to join and leave any group at any time,whatever their administrative domain would be.

In this article, an innovative intra- and interdomainQoS multicast routing strategy has been proposed andevaluated by means of NS-2 simulations. The strategywas specially designed for class-based domains andallows every member, source, or receiver to join aQoS-aware multicast group according to its own QoSrequirements. There is no need to remark packetsinside a domain because multiple trees can be built,

one tree per CoS. With this approach, multicast fits inDiffServ architectures, as well as unicast.

Simulation results show important decreases inpacket drops when the new strategy is used and alsoevidence the ability to dynamically find, and commutetraffic to, multicast distribution paths that avoid bot-tlenecks and congested links. Furthermore, this newrouting strategy promotes CoS traffic differentiation,being able to keep traffic from priority classes withinmore stringent limits.

At the interdomain level, the same multiclass/multitree approach has been analyzed. Interdomaintree branches are now constructed using an efficientpath probing mechanism that border domain routersissue in order to build directed QoS-aware trees, in-stead of establishing simple reverse (non-QoS-aware)path trees. The path probing strategy used in inter-domain scenarios has been shown to be efficient bothon flat and hierarchical topologies, without incurringsignificant overheads even when compared against non-QoS-aware interdomain solutions. Interdomain scenar-ios with 600 border domain routers have been usedin NS-2 simulations. In such a large simulation sce-nario, building trees from roots towards leaf membersinduces greater join latencies. However, results haveshown that this problem may be addressed by buildingmultiple directed unidirectional multicast distributiontrees. Furthermore, to avoid tree root routers overload,join requests are handled in a distributed manner by thefirst in-tree border domain router that receives them,thus relieving the tree root domain from this task.

Simulation results have also shown that QoS ob-tained with this new strategy, as perceived by receivers,is adequate, and join latency is kept small because newmembers try to find any in-tree BDR node, as fast aspossible, by sending control packets towards the rootdomain.

Finally, results presented also show that, using thisstrategy, there are significant gains in the costs of dis-tribution trees, even when compared with non-QoS-aware interdomain multicast routing solutions. Futurework includes a careful evaluation of the usage ofper-class precomputed routes, even without dynamicprobing, also at the interdomain (BGP) level.

References

1. Adams A, Nicholas J, Siadak W (2005) Protocol indepen-dent multicast-dense mode (PIM-DM): protocol specification(revised). RFC 3973 (Experimental). http://www.ietf.org/rfc/rfc3973.txt

596 Ann. Telecommun. (2008) 63:579–596

2. Apostolopoulos G, Guerin R, Kamat S, Tripathi SK(1998) Quality of service based routing: a performanceperspective. In: SIGCOMM, pp 17–28. citeseer.nj.nec.com/apostolopoulos98quality.html

3. Ballardie A (1997) Core based trees (CBT version 2) multi-cast routing—protocol specification. RFC 2189 (Experimen-tal). http://www.ietf.org/rfc/rfc2189.txt

4. Blake S, Black D, Carlson M, Davies E, Wang Z,Weiss W (1998) An architecture for differentiated ser-vice. RFC 2475 (Informational). Updated by RFC 3260.http://www.ietf.org/rfc/rfc2475.txt

5. Calvert K, Zegura E (1996) Gt-itm: Georgia tech internet-work topology models (software). http://www.cc.gatech.edu/fac/Ellen.Zegura/gt-itm/gt-itm.tar.gz

6. Carlberg K, Crowcroft J (1997) Building shared trees usinga one-to-many joining mechanism. Comput Commun Rev27:5–11

7. Carlberg K, Crowcroft J (1998) Quality of multicast service(qoms) by yet another multicast (yam) routing protocol. In:Proceedings of HIPARCH’98, June 1998

8. Chen S, Nahrstedt K, Shavitt Y (2000) A qos-aware mul-ticast routing protocol. In: INFOCOM (3), pp 1594–1603.citeseer.nj.nec.com/article/chen00qosaware.html

9. Costa A, Nicolau MJ, Santos A, Freitas V (2005) A newpath probing strategy for inter-domain multicast routing.In: First conference on next generation internet networkstraffic engineering (NGI’2005). IEEE Comm Society, Cata-log Number 05EX998C, ISBN 0-7803-8901-8, Libr of Congr2004116428

10. Fall K, Varadhan K (2001) The NS manual. http://www.isi.edu/nsnam/ns/ns-documentation.html

11. Faloutsos M, Banerjea A, Pankaj R (1998) Qosmic: qual-ity of service sensitive multicast internet protocol. In:Proceedings of the ACM SIGCOMM ’98 conference onapplications, technologies, architectures, and protocols forcomputer communication, pp 144–153. ACM, New York.doi:10.1145/285237.285276

12. Fenner B, Handley M, Holbrook H, Kouvelas I (2006) Proto-col independent multicast-sparse mode (PIM-SM): protocol

specification (Revised). RFC 4601 (Proposed Standard).http://www.ietf.org/rfc/rfc4601.txt

13. Fenner B, Meyer D (2003) Multicast source discoveryprotocol (MSDP). RFC 3618 (Experimental). http://www.ietf.org/rfc/rfc3618.txt

14. Kou L, Markowsky G, Berman L (1981) A fast algorithm forSteiner trees. Acta Inform 15:141–145

15. Kumar S, Radoslavov P, Thaler D, Alaettinoglu C,Estrin D, Handley M (1998) The masc/bgmp architecturefor inter-domain multicast routing. In: Proceedings of theACM SIGCOMM ’98 conference on applications, tech-nologies, architectures, and protocols for computer commu-nication, pp 93–104, Vancouver, 31 August–4 September1998

16. Lui KS, Nahrstedt K, Chen S (2004) Routing with topol-ogy aggregation in delay-bandwidth sensitive networks.IEEE/ACM Trans Netw 12(1):17–29

17. Medina A, Lakhinam A, Matta I, Byers J (2001) Brite: anapproach to universal topology generation. In: Proceedingsof the international workshop on modeling, analysis andsimulation of computer and telecommunications systems-MASCOTS ’01, Cincinnati, August 2001

18. Moy J (1994) MOSPF: analysis and experience. RFC 1585(Informational). http://www.ietf.org/rfc/rfc1585.txt

19. Moy J (1994) Multicast extensions to OSPF. RFC 1584 (Pro-posed Standard). http://www.ietf.org/rfc/rfc1584.txt

20. Nicolau MJ, Costa A, Santos A (2007) Design and evaluationof a multi-class based multicast routing protocol. In: Proc ofthe 21st edition of the international conference on informa-tion networking (ICOIN 2007), Estoril

21. Rekhter Y, Li T, Hares S (2006) A border gateway pro-tocol 4 (BGP-4). RFC 4271 (Draft Standard). http://www.ietf.org/rfc/rfc4271.txt

22. Thaler D (2004) Border gateway multicast protocol(BGMP): protocol specification. RFC 3913 (Informational).http://www.ietf.org/rfc/rfc3913.txt

23. Waitzman D, Partridge C, Deering S (1988) Distance vec-tor multicast routing protocol. RFC 1075 (Experimental).http://www.ietf.org/rfc/rfc1075.txt