Robust PIM-SM Multicasting using Anycast RP in Wireless Ad Hoc Networks

Transcription

1 Robust PIM-SM Multicasting using Anycast RP in Wireless A Hoc Networks Jaewon Kang, John Sucec, Vikram Kaul, Sunil Samtani an Mariusz A. Fecko Applie Research, Telcoria Technologies One Telcoria Drive, Piscataway, NJ 054, USA {jkang,jsucec,vkaul,ssamtani,mfecko}@research.telcoria.com Abstract Due to its banwith efficiency, multicast makes a group-centric communication more viable in wireless a hoc networks with limite raio resources. PIM-SM, a e facto stanar multicast protocol known for its high scalability, is a goo fit for a large-scale a hoc network. However, it oes not provie a robust multicast communication uner RP outage an high mobility. In this paper, we propose a robust way of configuring PIM-SM using Anycast RP in wireless a hoc networks. We analyze the impact of carinality an locations of anycast RPs on the network performance uner noe mobility. Base on these observations, we fin metrics for near-optimal carinality of anycast RPs an propose a novel RP selection scheme. The propose scheme is proven to make PIM-SM robust against noe mobility while satisfying QoS requirements an maintaining the scalability of PIM-SM. I. INTRODUCTION The banwith-efficient one-to-many communication paraigm of multicast is getting high attention as a way of group-centric communication in wireless a hoc networks eploye with scarce raio resources. Relatively unstable channel conition an ynamic topology changes from noe mobility, however, have been obstacles to its wie eployment. Many of the a hoc multicast protocols propose to overcome these problems still perform poorly in terms of message eliverability uner high mobility. This makes only variants of optimize flooing schemes feasible in that environment[]. On the other han, Protocol Inepenent Multicast-Sparse Moe (PIM-SM)[2] has been the e facto stanar in wie area networks ue to its scalability an QoS awareness[]. PIM-SM minimizes the multicast traffic by efficiently formulating the share tree using a central noe calle the Renezvous Point (RP) as the root of the tree. In PIM-SM, source noes in a multicast group sen their ata packets to the RP an then the RP natively multicasts them along the share multicast tree, which makes PIM-SM highly scalable with the growth of a multicast group membership. The high scalability of PIM-SM can significantly reuce the multicast traffic an control overhea of tree maintenance, This work has been prepare through collaborative participation in the Communications an Networks Consortium sponsore by the U.S. Army Research Laboratory uner the Collaborative Technology Alliance Program, Cooperative Agreement DAAD The U.S. Government is authorize to reprouce an istribute reprints for Government purposes notwithstaning any copyright notation thereon. Co-sponsore by the U.S. Army CERDEC uner the Proactive Integrate Link Selection for Network Robustness (PIL- SNER) program, contract W5P7T-04-CP022. Copyright c 200 Telcoria Technologies, Inc. All rights reserve. making it a promising solution in the wireless a hoc network with limite channel capacity. However, as inicate by [], existing wire multicast protocols incluing PIM-SM may fail to keep up with noe mobility an resulting route changes, thereby increasing protocol overheas. In aition, PIM-SM suffers from traffic concentration at the RP, consuming more energy in the vicinity noes of the RP an eventually making the RP unreachable from the rest of the network ue to energy epletion. The RP itself can fail, too. This RP outage problem cause by RP unreachability or failure makes the whole multicast communication break own, renering the RP a single point of failure. Robust multicast communication is a critical issue in the mobile a hoc network in which a wie range of military applications are often eploye. To enhance robustness of PIM-SM in the mobile a hoc network, we propose a PIM-SM configuration scheme that tackles two major aforementione issues, RP outage an noe mobility. To solve the RP outage problem, we eploy multiple active RPs in a multicast group using Anycast RP. Anycast RP has been alreay propose to cope with traffic concentration, slow convergence in case of RP failure, possible sub-optimal packet forwaring an istant RP epenencies, which are inuce by the single group-to-rp mapping property [4]. Anycast RP relaxes this single mapping constraint by configuring multiple RPs per group with an ientical anycast aress. While having more RPs per group brings benefits, it increases inter-rp traffic an control overhea among the RPs. Few stuies have been one to suggest an optimal number of anycast RPs. In this paper, we propose an incremental evaluation heuristic to fin a near-optimal number of anycast RPs that minimizes the multicast tree size while satisfying a certain level of robustness an QoS requirements. To solve the noe mobility problem of PIM-SM, the locations of anycast RPs are ecie base on the centroi concept. The topology change by noe mobility might results in the ineligibility of the current RP, thereby requiring RP relocation. RP relocation, however, incurs too much control overhea to inform the group members of the ientity of the new RP. Instea of frequent RP relocations, we show that if the level of noe mobility is not high, the noe mobility problem can be significantly mitigate by selecting anycast RPs base Anycast RP starting with a capital letter A inicates the PIM-SM mechanism using multiple RPs that are accesse base on the anycast routing protocol while anycast RP starting with a lowercase letter a implies an iniviual RP eploye in Anycast RP.

2 2 sener RP 0 receiver Region 0. RP RP - Region Region - an RP 0 natively multicasts them to the joine receivers in Region 0 an at the same time, RP 0 encapsulates an forwars the packets to the rest of the anycast RPs base on the MSDP protocol. The other anycast RPs ecapsulate the packets an natively multicast them to the receivers in their regions. If RP 0 fails, multicast packets from the sener are route to another topologically closest anycast RP, which reuces the RP outage perio. Fig.. Multicast communication with anycast RPs in the network on the centroi concept so that the topological central-ness of an anycast RP is not significantly hurt by noe mobility. This paper is organize as follows. In Section II, we provie the backgroun on Anycast RP as well as the previous work. In Section III, we present a mobility-robust RP selection scheme an a near-optimal carinality of anycast RPs. We stuy their performance in Section IV. Finally, we conclue our work in Section V. II. BACKGROUND A. Anycast RP vs. Multiple Domains Using multiple RPs for reliability or loa balancing is not a new iea. Earlier stuies take two ifferent approaches, provisioning multiple backup RPs or configuring a network into multiple omains. In the first approach, backup RPs are pre-etermine so that one of them can quickly replace the faile RP without incurring the RP election latency. However, a bootstrap mechanism is still require to map the logical multicast aress to the new physical RP aress. In this mechanism, the new group-to-rp mapping information nees to be flooe in the network before the new RP starts to operate, which still allows a temporary RP outage[5]. In aition, the new RP still suffers from congestion since only one RP is active at a given time. In the secon approach, a network is configure into several omains. A RP is selecte in each omain an the RPs in the network are inter-connecte by Multicast Source Discovery Protocol (MSDP)[]. The interconnecte RPs have ifferent IP aresses. This approach makes local communications efficient while achieving loa balancing among the RPs. But, the RP outage in one omain can still affect the whole multicast communication if a source noe belongs to the omain. When its RP fails, the source cannot irectly communicate with an RP in another omain since it is not aware of the RP s IP aress. As shown in Fig., Anycast RP allows an operator to configure multiple active RPs per group in the network using an ientical anycast aress. Therefore, there is logically one RP per group in the network. Group members join towars the topologically closest RP ecie by the unerlying unicast routing protocol. 2 We efine a region as a sub-network consisting of an anycast RP an the noes that are topologically closer to the anycast RP than any other anycast RPs. In the figure, a sener in Region 0 sens multicast packets to RP 0 2 An arrow in Fig. represents a multi-hop wireless communication. B. Previous Work A lot of research have been one in the literature for the optimal configuration of PIM-SM in wie area networks. Most of the work focus on selecting the RP in a single omain base on their own metrics an on relocating the RP in a istribute manner uner topology changes[5], [7]. Due to lack of space, the etails of the work are omitte in this paper. On the other han, the stanar of Anycast RP oes not specify the optimal carinality of anycast RPs an their locations[]. In [9], p-meian was use to fin multiple proxies in the overlay multicast architecture, but not in the Anycast RP environment. As far as we know, no previous work has been one to eal with the Anycast RP configuration that solves the noe mobility an RP outage problems. III. ROBUST PIM-SM CONFIGURATION In this section, we introuce two schemes to make Anycast RP robust against the noe mobility an RP outage problems. The noe mobility problem is alleviate by the mobility-robust RP selection metho. The RP outage problem is hanle by fining a near-optimal carinality of anycast RPs. In fact, these two problems are tightly couple as will be clear in the following subsections. A. Mobility-robust RP Selection In PIM-SM, the best way to trae off the banwith efficiency of share trees an the path length minimization of source-base shortest path trees is to overlap all shortest path trees an place a RP at the noe where the traffic from a source is split. But, this is not feasible since sources are sometimes not known a priori an can be istribute wiely across the network. On the other han, receivers are require to explicitly join a multicast group while any noe can sen ata to the multicast group. Therefore, given the network topology, our RP selection is performe base on the multicast group members, i.e., receivers. The goal of our RP selection scheme is to fin anycast RPs whose locations are robust against noe mobility. ) Mobility-robustness: Most of the RP selection schemes in the literature try to reuce the size of the multicast istribution tree so that multicast traffic in the network is minimize by sharing a large number of links. To minimize the network traffic, a group-share tree woul use a minimal spanning tree. When some subset of noes in a graph are connecte, this graph is calle a minimal Steiner tree an fining this tree is known to be NP-complete[0]. The anycast RP selection problem is a special case of the minimal Steiner tree problem

3 since the multicast tree topology is completely etermine by the locations of anycast RPs an the link metric use by the unerlying unicast routing, resulting in the union of RP-tomembers shortest paths. Therefore, the locations of anycast RPs shoul be carefully etermine to have a small tree size. The p-meian problem introuce in [] fins p noes whose aggregate istance to a set of noes in a graph is the smallest. The p-meian problem, which is known to be NP-complete, however cannot be irectly applie to our anycast RP selection problem since it oes not consier the inter-meian traffic. To select a mobility-robust RP, we reuce the p-meian problem into a simple -meian problem by applying p = an prove the chosen meian is robust to mobility as an anycast RP. Then, the -meian problem is extene to make multiple anycast RP selections in Section III-B. First, to fin a meian, the istance-sum of a noe v is efine as follows when V is the set of all noes. H(v) = u V (w(u) (v, u)), () where (v, u) is the shortest-path cost from noe v to u an w(u) is the weight function as in []. w(u) is if u is a multicast group member an 0 otherwise. The meian of a topology has the smallest istance sum. In the topology in Fig. 2(a), where black noes are multicast members an link weights are, noe is the meian with the smallest istancesum. There might be more than one meian in the network. Fining a meian from all noes is not scalable especially in a large-scale network. This involves calculating the istancesums of all noes, requiring O(nm) time complexity in an arbitrary graph with n noes an m group members. On the other han, fining a meian from the multicast group members introuces less time complexity, but it has been shown that a tree roote at a group member gives a elay boun of three times that of source-specific trees while the boun becomes two times that of source-specific trees if the root is locate near the center of the group[2]. Therefore, we create a shortest-path tree roote at a group member as shown in Fig. 2(b) (noe as a root in this case) in orer to fin the caniate RP set near the center of the multicast group. This tree is boun to inclue at least one meian since noes are connecte to the root on the shortest-path tree. Shortestpath trees roote at other group members are also create an a union set of all on-tree noes of the shortest-path trees is foun. We call this set an on-tree noe set. Then, the meian is foun from the on-tree noe set. This approach reuces time complexity compare to having all noes as a caniate RP set an minimizes path length compare to having multicast group members as a caniate RP set. In [], it is shown that a meian is equivalent to a centroi if the graph is a tree. If T v,, T v,2,..., T v,k are the connecte subtrees of a noe v of egree k in a tree T, the member size of a subtree T v,i is efine as follows: s(t v,i ) = w(u), (2) u T v,i We assume that the network is not partitione meian H()=5; H(4)=7; H(7)=7 Fig centroi M()=; M(4)=5; M(7)=5 (a) (b) (c) 9 H()=; H(4)=; H(7)= M()=; M(4)=5; M(7)= centroi H()=5; H(4)=7; H(0)=7 () (e) (f) Impact of mobility on the location of a meian where w(u) is the previously efine weight function. The maximum member size of a noe v is efine as M(v) = MAX i k s(t v,i ). () A noe v is calle a centroi if the noe has the smallest value of M(v). As Eq. inicates, the location of a centroi epens not on the path length between the centroi an the noes, but only on the noe weights. Fig. 2(c) shows a shortest-path tree roote at noe, which can be easily constructe from the topology in Fig. 2(a). Noe becomes a centroi since it has the smallest maximum member size. This is true for other shortest-path trees roote at other noes. In Fig. 2(), noe s movement within the centroi s subtree roote at noe 7 oes not affect the location of the centroi since noe s maximum member size is still the smallest after noe s movement as shown in Fig. 2(e). In Fig. 2(f), noe s istance sum is still the smallest after noe 9 s movement outsie the subtree. If a centroi is selecte from the multicast group members, noe 7 will be selecte in Fig. 2() an lose its role as a centroi after noe 9 s movement since noe 0 becomes a new centroi in the new topology in Fig. 2(f). Therefore, selecting a meian from the on-tree noe set as an anycast RP minimizes the impact of mobility while making the scheme scalable to the growth of network size. 2) Discussion: Uner high mobility, another on-tree noe can have a smaller maximum member size than that of the current centroi after noe movements. We believe this is a rare case uner moest mobility. Due to the shortest path unicast routing an limite raio range, the centroi will have a limite number of neighbor noes. The subtree roote at each of this neighbor noe will expan outwar from the centroi, making the istance to other subtrees large. As a result, the noe movements across these subtrees are expecte to be infrequent uner moest mobility. In aition, the noe mobility within a subtree will not change the maximum

4 4 member size of the current centroi even uner high mobility. B. Carinality of Anycast RPs To fin a near-optimal carinality of anycast RPs, we first quantify the impact of the carinality of anycast PRs on the QoS. The affecte QoS is measure by the average en-to-en path length of a connection an the inter-rp traffic volume. We choose these metrics because multicast is originally eploye for its banwith efficiency an often requires limit on the en-to-en path length especially for real-time applications. ) Impact on QoS: To analyze the average path length, we assume an Anycast RP network with uniformly istribute n noes an RPs as shown in Fig.. We assume the weight of each link is, making the average path length calculate in hops. We also assume that there is one multicast group with s sources an r receivers an they are uniformly istribute in the network. The multicast traffic in an Anycast RP network can be classifie into the intra-region traffic an the inter- RP traffic. With s sources an r receivers in each region r on the average, there are s intra-region source-to-receiver connections in the network. Therefore, the upper boun on the total number of hops 4 traverse by the intra-region traffic can be represente as s r 2H R, (4) where H R is the average hops from a noe towars its anycast RP in the network with RPs. H R will be shown later. On the other han, the total number of the inter-region sourceto-receiver connections is s ( ) r an the total number of hops traverse by these connections can be calculate as s ( ) r (2H R + H T ), (5) where H T is the average hops among anycast RPs in the network with uniformly istribute n noes. Therefore, the average source-to-receiver path length (in hops) of a connection is 2srH R + sr( ) (2H R + H T ) sr = 2H R + ( )H T. () H R an H T are epenent on the network topology. Base on the network connectivity moels in [], H R can be calculate as n α, where α ecies the network topology. We use the mesh network moel as a network topology in this paper. The average path length of a mesh network with uniformly istribute n noes is 2 n. Therefore, HT, which is the average path length between anycast RPs when the number of hops between ajacent RPs is n, can be calculate as 2 n. The proof of above calculations can be foun in []. With the values of H R an H T of a mesh network, Eq. becomes 2 n( + α ( )). (7) 4 This is the sum of the en-to-en elay represente in hops that each source-to-receiver connection experiences, not the size of the istribution tree in hops. Fig.. path length (in hops) number of RPs alpha = alpha = 2 alpha = alpha = 4 alpha = 5 alpha = Average path length of a connection in hops Number of RPs RP 2 RPs 4 RPs Source-base per group shortest-path tree Average hops (increase against (2%) (%) (-%) -RP case) TABLE I AVERAGE PATH LENGTH OF A CONNECTION BY SIMULATION In Fig., we plot Eq. 7 with ifferent α values an ifferent number of anycast RPs. It shows that as the number of anycast RPs increases, the average path length eventually ecreases, generating ifferent results epening on α values, i.e. ifferent network topologies. We also conuct simulations. We create 0 multicast groups with 0 seners an 20 receivers in each group in a ranom network with 0 noes. Simulations also have similar results shown in Table I. In the source-base shortest-path tree case in the table, receivers join each source irectly an as a result, the traffic from a source is forware to receivers without passing through a RP. Therefore, the istribution tree create by source-base shortest-path trees is topologically equivalent to the share tree with an anycast RP at each source, resulting in 0 RPs per group in our simulations. The above results clearly inicate that a certain level of RP reunancy is require not only for robustness but also for QoS requirements. While a large number of anycast RPs reuces path length, it increases the inter-rp communication overhea. Since the inter-rp multicast traffic is encapsulate in unicast packets an therefore cannot be share on the same link, it becomes a ominant component of the whole multicast traffic as the number of anycast RPs increases. In a mesh network with n noes, anycast RPs an source, the inter-rp traffic volume can be calculate as 2 n( ) Ts β, () where T s is the traffic volume of the source an β (> ) is the encapsulation overhea. The inter-rp multicast traffic in the network increases linearly with the carinality of anycast RPs while no inter-rp traffic is generate with a sole anycast RP, i.e., when =. Eq. can be euce from []. In aition to larger packet size an processing overhea ue to the encapsulation, anycast RPs nee to exchange MSDP control messages to route the encapsulate unicast ata packets

5 5 Inter-RP Communication Overhea 2... Average En-to-En Path length Fig. 4. Seconary metrics for carinality of anycast RPs Number of Anycast RPs en-to-en elay (ms) all noes on-tree noe set multicast group members among them. In the following section, we introuce the metrics for eciing the carinality of anycast RPs. 2) Metrics: We have two types of metrics to be use for eciing the carinality of anycast RPs: primary metric an seconary metrics. As mentione earlier, the primary goal of multicast is to reuce the size of the istribution tree to minimize the multicast traffic in the network. Therefore, our primary metric is the multicast traffic volume generate by the given Anycast RP configuration. In aition, we have a set of other application-specific metrics such as path length an inter-rp traffic. We call them seconary metrics. An Anycast RP configuration with a certain number of anycast RPs an their locations is evaluate an ranke by the primary metric only after it satisfies all of the seconary metrics. Fig. 4 shows two seconary metrics: inter-rp communication overhea an average en-to-en path length. As the carinality of anycast RPs increases, the inter-rp communication overhea increases while the average en-to-en path length ecreases as shown earlier. The application-specific seconary metrics are use for the pass-or-fail check. We assume that the boun for each seconary metric is specifie by the multicast group initiator. An Anycast RP configuration that satisfies all of the seconary metrics will further be evaluate base on the primary metric for the final selection. The caniate carinality of anycast RPs starts from two since a eployment with a sole RP oes not provie RP reunance an is ientical to the legacy PIM-SM. ) Heuristic: To fin a robust Anycast RP configuration with a near-optimal carinality of anycast RPs an their mobility-robust locations, we take an incremental evaluation approach that increases the number of anycast RPs in each step until that inclusion of an anycast RP satisfies all seconary metrics. The heuristic consists of the following steps. Step : Fin the on-tree noe set from the given topology an multicast group members. 5 Step 2: Calculate a istance-sum of each noe in the set an sort them in an ascening orer. Set the starting caniate carinality of anycast RPs to 2 (i.e., k = 2). Step : Pick k noes with the smallest istance-sum as anycast RPs. If there are more than one set of k noes ue to the same istance-sums, fin all possible sets of k noes. Step 4: Formulate a multicast istribution tree using k anycast RPs selecte in Step. Step 5: Evaluate the istribution tree base on the seconary metrics. 5 The network topology is available from the unerlying unicast routing protocol. In Section IV, OSPF is use. Fig En-to-en elay number of RPs Step : If not all of the seconary metrics are satisfie, go to Step with k = k +. Step 7: If all of the seconary metrics are satisfie, evaluate the istribution tree base on the primary metric. If there were more than one set of k noes in Step, compare their primary metric values an pick the best one. The k noes selecte in Step will provie mobilityrobustness as well as reunancy in case of RP failure. In the worst case when only one anycast RP survives, the RP is still robust to mobility ue to its small istance sum while forming a small-size istribution tree ue to its close proximity to the meian. The above heuristic fins the smallest carinality of anycast RPs that satisfies all seconary metrics impose by the eploye application. IV. EVALUATION Simulations to evaluate the effectiveness of the propose scheme are performe by using an embee evaluation functionality of our multicast planning tool calle PUMA (Planning Utility of Multicast Application). The network is compose of three OSPF areas an one backbone area. The area borer routers (ABR) in ifferent OSPF areas are connecte through the backbone area. A shortest path is ecie by the OSPF unicast routing protocol using the propagation elay as a link weight. There are 240 noes in the network. One multicast group is forme by ranomly selecting 0 members from each OSPF area (except the backbone area) with one source noe. There exist two types of wireless channels with the propagation elays of 20ms an 50ms, respectively. A noe s average number of neighbor noes is.9. In the first evaluation, we stuy the effectiveness of using the on-tree noe set an prove its near-optimality base on the weighte tree size an ento-en elay with no mobility. In the secon evaluation, we stuy the robustness of our RP selection heuristic against noe mobility. A. Carinality Fig. 5 an Fig. show the en-to-en elay an weighte tree size of the propose scheme with three RP caniate sets (i.e., from all noes, the on-tree noe set, or the multicast group members). As mentione in Section III-B2, the primary metric is the multicast traffic volume measure here base

6 Fig.. weighte tree size all noes on-tree noe set multicast group members Weighte tree size number of RPs During the low mobility perio, the propose scheme shows robustness to mobility by having comparable weighte tree sizes to those of the RP relocation case. This is because the maximum member sizes of the anycast RPs haven t change much uner moest mobility. As the mobility level increases, the chosen anycast RPs generate a larger multicast traffic volume. However, their increase traffic volume is still within 7% margin compare to the RP relocation scheme that might be provoke many times with large overhea uner high mobility. As the mobility level goes up, the weighte tree size is saturate in all cases because more number of noes begin to share the newly create istribution branches. Fig. 7. weighte tree size Propose scheme (5 RPs) RP relocation (5 RPs) Propose scheme (2 RPs) RP relocation (2 RPs) mobility Weighte tree size with respect to mobility V. CONCLUSION In this paper, we propose a robust Anycast RP configuration scheme that fins a near-optimal carinality of anycast RPs an their locations to hanle the RP outage an noe mobility problems. By eploying a near-optimal number of anycast RPs, we effectively reuce the RP outage perio while minimizing the inter-rp communication overhea. In aition to robustness, the selecte Anycast RP configuration enhances relevant metrics such as elay. We also etermine the locations of anycast RPs using the centroi concept to make them robust to the moest noe mobility, resulting in avoiance of frequent RP relocations that incur a lot of overhea. on the weighte tree size, in which the traffic volume is weighte by the link s weight. The en-to-en elay represents a seconary metric. The results of the anycast RP selection from the on-tree noe set are on a par with those of selecting from all noes while incurring low computation overhea. This is because the meians with the smallest istance sums are locate mostly in the on-tree noe set. On the other han, the meians selecte from the group members show low performance. When the upper boun on the en-to-en elay is set to 420ms, our scheme selects three anycast RPs that have almost the same weighte tree size as that of selecting anycast RPs from all noes with small computational overhea. B. Mobility The noe mobility can be implemente in two ways, by changing the velocity of a noe or by changing the percentage of mobile noes. In this paper, we change the fraction of mobile noes in the network. These noes move slowly enough not to make link breakages frequent. When a noe is connecte to a ifferent subnet after movement, a new istribution branch is quickly constructe by sening a JOIN message to the closest anycast RP. An anycast RP is always available to this noe by the anycast routing protocol. To evaluate the robustness of our RP selection scheme, we compare our scheme with the RP relocation scheme. The RP relocation scheme exhaustively searches the best set of anycast RPs base on the primary metric (i.e., the weighte tree size) after noe mobility. The RP relocation incurs the overheas mentione in Section II-A, which, however, is not inclue here. Due to lack of space, results of 2 an 5 RP cases are shown in Fig. 7. REFERENCES [] C. Coreiro, H. Gossain, an D. Agrawal, Multicast over Wireless Mobile A Hoc Networks: Present an Future Directions, IEEE Network, vol. 7, no., pp , Jan 200. [2] B. Fenner, M. Hanley, H. Holbrook, an I. Kouvelas, Protocol Inepenent Multicast - Sparse Moe (PIM-SM), RFC 40, Aug 200. [] C. Metz an M. Tatipamula, A Look at Native IPv Multicast, IEEE Internet Computing, vol., no. 4, pp. 4 5, Jul [4] D. Kim, D. Meyer, H. Kilmer, an D. Farinacci, Anycast Renevous Point (RP) mechanism using Protocol Inepenent Multicast (PIM) an Multicast Source Discovery Protocol (MSDP), RFC 44, Jan 200. [5] D. Estrin, M. Hanley, A. Helmy, an P. Huang, A Dynamic Boostrap Mechanism for Renezvous-base Multicast Routing, IEEE INFOCOM, Mar 999. [] B. Fenner an D. Meyer, Multicast Source Discovery Protocol (MSDP), RFC, Oct 200. [7] S.K.S. Gupta an P.K. Srimani, Aaptive Core Selection an Migration Metho for Multicast Routing in Mobile A Hoc Networks, IEEE Transactions on Parallel an Distribute Systems, vol. 4, no., pp. 27, Jan 200. [] D. Farinacci an Y. Cai, Anycast-RP Using Protocol Inepenent Multicast (PIM), RFC 40, Aug 200. [9] L. Lao, J.H. Cui, M. Gerla, an S. Chen, A Scalable Overlay Multicast Architecture for Large-Scale Applications, IEEE Transactions on Parallel an Distribute Systems, vol., no. 4, pp , Apr [0] M.R. Garey an D.S. Johnson, Computers an Intractability: A Guie to the Theory of NP-Completeness, New York: Freeman, Jun 9. [] O. Kariv an S.L. Hakim, An Algorithmic Approach to Network Location Problems. II: The p-meians, SIAM Journal of Applie Mathematics, vol. 7, no., pp , Dec 979. [2] D.W. Wall, Mechanisms for broacast an selective broacast, Ph.D. Thesis, Jun 90. [] National Institute of Stanars an Technology, Catalog of Network Connectivity Moel, netmoels.html, Apr 200. The views an conclusions containe in this ocument are those of the authors an shoul not be interprete as representing the official policies, either expresse or implie, of the Army Research Lab or the U.S. Government.