SREM: A Novel Multicast Routing Algorithm - Comprehensive Cost Analysis

Transcription

1 REM: A Novel Mulicas Rouing Algorihm - Comprehensive Cos Analysis Yewen Cao and Khalid Al-Begain chool of Compuing, Universiy of Glamorgan, CF37 DL, Wales, U.K {ycao,kbegain}@glam.ac.uk Absrac Ever-increasing aenion has been drawn o source specific mulicas in he Inerne sociey. In his paper, a novel mulicas scheme, called calable Recursive Explici Mulicas (REM) is proposed. To address he scalabiliy problem, REM uses a pair of branching node messages (BNMs) o consruc a mulicas ree, which is buil up gradually and dynamically as of mulicas group members join/leave. BNMs always raverse beween a pair of branching node rouers (BNRs) and he process of join/leave of member of a mulicas session is carried ou locally. Delivering mulicas packes is carried ou recursively beween BNRs by unicas. In REM, only BNs keep he mulicas sae abou heir nex BNRs. By he cos analysis and simulaion, i is shown REM has many posiive feaures such as fixed size conrol messages, being scalable and low join/leave laency. I. Inroducion Mulicas provides an efficien soluion o make full use of he scarce resource in he Inerne due o he explosive increasing of raffic. However, here are he scalabiliy issues when a nework needs o suppor a very large of disinc mulicas groups. Recenly, a number of mulicas mechanisms have been proposed o address he scalabiliy problem []-[6]. imple mulicas [] and EXPRE [2] were proposed o ackle he address allocaion and he sender access conrol problems. In hese schemes, here is a special node (sender or core) associaed wih each group and he group is idenified by a wo-uple <special node s unicas IP address, class D mulicas address>. While hese proposals address some imporan issues relaed o he service model of IP mulicas, he scalabiliy problem of IP mulicas rouing sill remains. In order o reduce forwarding sae a non-branching rouers, REUNITE [3] uses recursive unicas rees o implemen mulicas service. However, REUNITE inroduces dynamic behaviours such as ree resrucuring, race condiion of joins and duplicae packes during ree resrucuring. Explici mulicas (Xcas) proposal [4] and is enhanced version Xcas+[5], supporing small groups and medium size group respecively, eliminae he need for forwarding saes, bu sill being no scalable. imple explici mulicas (EM) [6] uses Xcas mechanism o build mulicas ree and uses a similar mechanism used in REUNITE [3] o deliver packes. However, EM has sill he scalabiliy problem, as all of desinaions addresses (of receivers for Xcas, or designaed rouers for Xcas+) have o be encoded in branching messages. In EM, anoher major problem is he join/leave laency. In his paper, we propose a new source specific mulicas proocol, called calable Recursive Explici Mulicas (REM). REM aims o address boh scalabiliy problem and high join / leave laency in exising mulicas schemes owards a soluion for applicaion in mobile IP neworks. II. REM Algorihm Overview REM uses recursive explici mulicas o implemen mulicas service. In REM, he key idea is using of a dynamic branching node-based mulicas ree (DBT) o deliver packes. Two ypes of signalling messages are used o build his DBT, i.e., join / leave signalling messages (J/JL) and branching node messages (BNMs). Each receiver who wans o join /leave a mulicas group (G) sends a join/leave message o is local mulicas rouer (LMR), and his LMR hen sends a regisraion message o he mulicas source () on behalf of his receiver. In he iniial sage of he mulicas ree seup, he mulicas source will be in charge of searching for he firs branching node rouer (BNR) by using of a pair of BNMs upon receiving hese regisraions. Following ha boh he mulicas source and BNRs will perform his funcion (searching for BNRs), as explained in more deails laer in his paper. As a resul, a dynamic branching node-based mulicas ree (DBT) will hen be creaed. In REM, using BNMs, each of BNRs in DBT is aware of he address of is previous BNR as well as a lis of is nex branching nodes addresses, which is kep in a mulicas forward ables (MFT) wih he mulicas ree ideniy (MTI) of (,G). However, he BNMs only raverse a pah beween a pair of BNRs, where a new mulicas

2 desinaion is joining, and no BNM for a BNR means no updae for is MFT. This resuls in he local join / leave operaions, which is one of REM s advanages. In REM, a BNR could be ofen in a dual funcionaliy simulaneously. The firs one is o help building a local par of mulicas ree, i.e., informing of is previous BNR and searching for is nex level BNRs. This will be done only when a new member is joining or an old member decides o leave a mulicas group. econdly, BNR is in place of delivery of mulicas packe o is nex level BNRs. To mulicas daa packes, a REM header will be added o each of packes. This is done by BNRs, which encode he address of one nex BNR in daa packes. Upon receiving his packe from is previous BNR, each of BNRs will check is MFTs and replicae he packe, modify he REM header wih desinaions of he nex BNRs, and hen send he modified copies of he packes on o he nex BNRs. For non-branching nodes, packes are forwarded jus like normal unicas. Finally, when arriving a he lashop mulicas rouer, mulicas packes will be delivered by he use of sandard mulicas. III. REM cheme Deailed 3. Dynamic Branching- node-based Tree (DBT) In REM, he se up of mulicas ree is processed gradually and dynamically by ineracion beween branching nodes as he joining of members of a mulicas group, no in advance. This mulicas ree is referred as a dynamic branching node-based ree (DBT). The DBT is se up by he use of a pair of BNMs, i.e., enquiring BNM (ebnm) and replying BNM (rbnm). BNMs carry he informaion such as he previous BNR, one nex BNR, and new LMR, as deailed in ecion 3.2. The key poin o build DBT is ha each of inermediae mulicas-enabled rouers (IMRs) is aware of wheher or no i is one of BNRs for he source or is nex BNR. For his, in REM, IMRs have hree separae funcions: i) idenify exisence of new BNR in he roue o desinaions; ii) know iself he sae of being a BNR or no; iii) inform one level upper (i.e. previous) BNR of is sae. These funcions are carried ou as follows. On receiving a new join signalling (J) message (say, from a receiver a), one BNR (can be he mulicas source a he iniial sage) in he DBT, say N, will check he roue (where x s J message is coming) agains all exising roues in is MFT. If i does no mach any one, hen N will be aware of his roue is a new branch of DBT and he address of x s LMR will hen be added o he N s MFT. Oherwise, he nex hop address for he new J message is equal o one of enries in N s MFT, and hen he BNR will sar a new branching node search by sending an enquiring BNM (ebnm) o he nex IMR wih an address couple of an exising BNR (say M ) and he x s LMR. When he IMR, say L, receives he ebnm from he upper level (previous) BNR (a he momen, N), i will check he nex-hop address for boh IP address in he message. If hese are he same, hen forward o he nex IMR. If no, his IMR is hen a new BNR and i sends a replying BNM (rbnm) o he upper level BNR, i.e., N. This procedure is similar o ha in Xcas [6]. However, in Xcas, his process is for delivery of packes, no for searching for branching nodes. M Fig. Process of building he DBT in REM. When N receives his rbnm, i will replace he enries for exising BNR (M) and he new LMR (x s LMR) wih he address of he new BNR (L). Based on his mechanism, a DBT will be buil gradually. 3.2 ignalling messages in REM L A. Branching Node Messages x In REM, enquiring branching messages (ebnm) should look like [src= IP_branching node group address = (,G ) des= IP_new LMR rouer, IP_nex branching node previous branching node], where a group or MTI is idenified by (, G). And, similarly bu simply, replying branching messages (rbnm) look like [src= IP_ new branching node group address =(, G) des = previous branching node]. Boh ebnm and rbnm are of a fixed size, differen from ha in EM [8]. In REM, sending BNMs could be iniiaed a he source or any one of BNRs o search for new BNRs. However, BNRs are usually responsible for searching for new BNRs by he joining of new members, unless a new member joins he mulicas session via an IMRs which is beween he source and is BNRs. This means ha he mulicas ree is buil gradually and locally and no N J ebnm rbnm

3 remarkable joining and leaving laency is incurred. This is quie differen from he way in EM [8], where he mulicas ree is buil in advance based on all of addresses of desinaions involved in he mulicas group and needs o be rebuil whenever any new joining and leaving happens. B. Join / Leave ignalling (J/L) Messages In REM, IGMPv.3 is used o iniiae/end he procedure of mulicas. Any end user or receiver which inends o join / leave a mulicas group sends a join / leave message (JoinM/LeavM) o he LMR. On behalf of heir aached mulicas receivers, LMRs send regisraion reques messages (RqMs) o he mulicas source. Upon receiving RqMs, he source will send regisraion reply messages (RpMs). In REM, RqMs and RpMs use similar forma o IGMP messages. However, here are wo changes made. Firs, he Max Resp Time field in IGMP messages is replaced by a flag filed in REM regisraion messages, where a he momen, only one bi in he flag field, called bi, is defined. econdly, anoher address field is added o payload of he message. This field is filled wih he address of a receiver. C. Roles of ignalling Messages in REM In REM, he wo classes of mulicas session signalling messages, i.e., JoinM/LeavM and RqM/RpM, play heir independen roles and cooperae (in urn) o suppor mulicasing process. The role of hese messages in he mulicas process is explained below. Firs, le us consider he joining process. A new member of a mulicas group, say x, sends a JoinM o is LMR. Upon receiving his message, he LMR of x will hen send a RqM on behalf of x. Depending on wheher or no x is he firs member (of a mulicas group G) aached o is LMR, x s LMR will choose o send a RqM or RqM, where he superscrip and corresponds he saes of bi in RqM. The LMR will send a RqM if x is he firs member, oherwise i will send RqM. Le us ake he firs case for example, shown in Figure 3. Upon receiving RqM, each of IMRs jus passes and forwards i owards he source. As soon as a BNR (called he Firs BNR) receives RqM, i will fulfil wo asks (operaions). The firs is o creae an enry for x in is MFT. This means ha he mulicasing process for x will be sared a he Firs BNR. On oher hand, he Firs BNR will change he bi in RqM. The amended message is hen a New Receiver ( x ) Time LMR BNR n BNR ENDER n IMRs IMRs IMRs JoinM RqM RqM RqM (I) (II) New BNR RqM RpM RpM RqM RqM RqM RpM RpM RpM Figure. 3 Joining and delivering process in REM RqM. The role of RqM is o inform following IMRs and BNRs of no any processing needed. Therefore, boh following IMRs and BNRs jus pass and forward RqM owards he source wihou any processing. Due o his fac, i.e., ha boh following IMRs and BNRs don need o do any processing, i will ake a very shor ime (called Reg_ime_up) for RqM from he Firs BNR o reach he mulicas source. Upon receiving RqM, he mulicas source will send back RpM o confirm ha he joining of new member is acceped. Corresponding o RqM messages, here also is a pair of RpMs in REM, i.e., RpM and RpM. RpM is a reply message sen by he mulicas source while RpM is one sen by he Firs BNR. RpM is generaed by he Firs BNR only as a RpM is received. Excep for he Firs BNR, no any processing is needed for all of he IMRs and oher BNRs as receiving RpMs (RpM or RpM ). Clearly, i will also ake a very shor ime (called Reg_ime_down) for RpM from he source o he Firs BNR. Afer processing by he Firs BNR, a RpM will be hen generaed and i will finally reach he LMR of x, informing of LMR being auhorized o deliver mulicas packes for x. This means he regisraion processing is finished. As soon as he Firs BNR receives he RpM, he process of delivering mulicas packes for receiver x may sar. Noe ha his process sars from he Firs BNR. However, depending on wheher or no a new BNR is found by IMRs (exacly he IMRs beween he LMR of x and he Firs BNR), he mulicas packes will be forwarded via a New BNR (case (I)), or no (case (II)). Now, urn o he second case, i.e., here exis already oher members of a mulicas group aached o he x s LMR. In his case, he x s LMR will direcly send a RqM oher han RqM, informing he mulicas source of ha x is joining. Therefore, here is no processing needed for all of

4 following IMRs and BNRs. Upon receiving RqM, he mulicas source will send back RpM o confirm ha he joining of new member is acceped. Noe ha in REM, he mulicas source is always in charge of he regisraion process of members of a mulicas group, bu he delivering of mulicas packes is fulfilled hrough BNRs, exacly a local BNR for a new member. Alhough he par of regisraion process (iniiaed from BNRs) is always owards and hrough he mulicas source, his process, which akes he ime of he sum of Reg_ime_up and Reg_ime_down, is fas and is expeced o be finished almos a he ime when BNRs are in place o deliver mulicas packes. This leads o more efficiency and less delay in delivering of mulicas packes. Therefore, REM is effecive and of less laency in delivering. The leaving process of a member (say x) of a mulicas group is similar o he joining process, excep for no RpMs being sen by boh BNRs and he mulicas source. If x is no he las member (of a mulicas group) aached o LMRs, no any change in he DBT will be occurred. In his case, he LMR for x will direcly send a RqM informing he mulicas source of ha x is leaving. Due o he RqM being in he form of RqM, here is no processing needed for all of IMRs and BNRs. Oherwise, if x is he las he las member aached a LMR, here will be some change in he DBT. The LMR of x will send a RqM oher han RqM. Upon receiving RqM, he Firs BNR for he x will do wo operaions. Firs, i will updae is MFT. As a resul, he forward pah for he x s LMR is deleed. econdly, i needs o make a decision: o send a RqM or a RqM. This is because he Firs BNR migh be no longer a BNR any more. If he Firs BNR is sill a BNR, i will send RqM. Consequenly, he following IMRs and BNRs don need o do any processing and jus forward his message owards he mulicas source and he source will finally be aware of x being leaving. Oherwise, he Firs BNR will send a RqM. The RqM will raverse hrough IMRs and reach an upper level BNR (owards he mulicas source). Upon receiving RqM, his upper level BNR will do wo operaions as well. Firs, i will sar a process of mulicas ree mainenance and updae is MFT. As a resul, he Firs BNR is no a BNR any more. econdly, he upper level BNR will send a RpM owards he mulicas source. The following IMRs and BNRs jus pass and forward his RpM. Finally, he mulicas source will receive his RpM and updae is regisraion lis. 3.3 Delivery of Packes To mulicas daa packes, a REM header will be added o each of packes. This is done by BNRs (including he mulicas source). Each of BNRs will encode he address of one following BNR in daa packes. This leads o disinc headers for packes owards he differen nex BNRs. A he sar of mulicasing, he source will send a copy of packes wih respecive REM headers o all of BNRs in is MFT. Upon receiving his packe, each of BNRs needs o properly process he REM header. The sandard processing for a BNR is as follows: (i) Check is MFTs and replicae he packe so ha here's one copy of he packe for each of is nex BNRs. (ii) Modify he REM header wih desinaion in each of he copies subsiued by he address of he nex BNR.(iii) end he modified copies of he packes on o he nex BNRs lised in is MFT. For nonbranching nodes, packes are forwarded jus like normal unicas. Finally, when arriving a he las-hop mulicas rouer, mulicas packes will delivered by he use of sandard mulicas. IV. Comparison and Cos Analysis Xcas encodes he lis of he addresses of all receivers in each packe, while Xcas+ encodes he lis of designaed rouers in each packe. However, boh REM and EM use his mechanism only in he branching message. In Xcas and Xcas+, he packe will follow he unicas pah beween he source and he desinaion, bu in EM and REM he packe will follow a unicas pah beween branching nodes. Furhermore, here are wo major differences beween EM and REM as follows. In EM, all of desinaions of a mulicas session are encoded in branching messages o build a mulicas ree in advance and he source or sender is always in charge of he se-up and mainenance of he whole mulicas ree, and he mulicas ree needs o be rebuil whenever he joining or leaving of one of desinaions is happened. This leads o wo disadvanages. Firs, EM has he scalabiliy problem, like he Xcas and Xcas+. This is due o he fac ha as he size of a mulicas group increases, boh he size of delivering packes in Xcas and Xcas+ and he size of BNMs in EM will increase correspondingly. econdly, EM has he problem of a big join/leave laency, which is occurred by he se-up of he whole mulicas ree in advance or rebuil he whole mulicas ree whenever a new member is joining or an old member is leaving. REM, however, aims a o overcome hese disadvanages in EM. In REM, he forma of BNMs are changed. Insead of all of desinaions of a mulicas session, only one BNR and one newly-joining desinaion are encoded in he BNMs. As a resul, he BNMs have a

5 fla size regardless of he size of a mulicas group. Therefore, REM is scalable. On he oher hand, in REM, he mulicas source is in charge of he regisraion process bu rarely akes par in he building of he mulicas ree. In fac, he source akes par in he se-up of mulicas ree only a he sar sage (exacly, he searching for firs level BNRs from he source), and BNRs will ake he responsibiliy of he updae and mainenance of remained par of he mulicas ree. This means he operaions of joining or leaving is always implemened locally, i.e., being done beween he desinaion riggering he join/ leave and is closes BNRs in exising mulicas ree. Therefore, no remarkable join /leave laency will be incurred in REM. Cos analysis of REM, Xcas, Xcas+ and EM schemes can be summarised as described in Table. Boh REM and EM have some conrol plane agains he Xcas and Xcas+, heir cos of packe header processing is minimised. REM has all of he advanages of EM. Furhermore, compared o EM, REM has less conrol overhead and lower join and leave laency. This will be confirmed by simulaion in he following secion. Table Cos analysis of REM, Xcas, Xcas+ and EM Xcas Xcas+ EM REM Mulicasaddress none medium medium medium allocaion Mulicas rouing none low low low sae managemen Conrol overhead none medium medium low Overhead by increase of receivers high low low low Exra header high medium low low processing overhead Deploymen low low low low Join and leave laency high high high low V. imulaion Resuls In our simulaion, he Waxman s probabiliy model [7] is used o produce a random nework opology. The average connecion degree a nodes is beween 3 an 4. The link coss are chosen randomly, uniformly disribued in [ ]. We assume here is one mulicas source, which is randomly chosen from he rouers, and some of nodes are randomly seleced as LMRs, where a rouer becomes a LMR as long as here is one mulicas receiver aached o i. The link coss beween receivers and LMRs are se a fixed value of., basing on he consideraion of ha he local link cos is usually lower han ha beween rouers. The source and rouers which are aking par in mulicasing are called as acive mulicas rouers (AMR). The oal number of AMR is changing wih he joining / leaving of he member of mulicas group. In our simulaion model, o deliver mulicas packes, he Dijksra algorihm [8] is used o find he shores pahs for all receivers. The ree informaion such as forming BNRs and down- and up-bnrs, nodes cos are kep a each nodes dynamically. A each of BNRs and LMRs, he possible processing includes: i) Perform a roue able look up, ii) Pariion he se of desinaions based on heir nex hops, iii) Replicae he packes for each of nex hops, and iv) Modify he lis of desinaions in each of copies. For Xcas and Xcas+, he processing will be made for mulicas packes. For EM and REM, he processing will be made for mulicas packes and conrol messages. The performance of hese proocols will highly depend on heir respecive processing. To evaluae he four algorihms considered in his paper, hree merics are considered. The firs one is processing cos (a nodes), including coss due o header encoding / decoding, exchanging of conrol messages. The processing cos is occurred a nodes when processing being made for mulicas packes / conrol messages. The second one is delivering cos (over links), including coss in delivery of mulicas packes and conrol messages. The delivering cos is he cos occurred a delivering mulicas packes / exchanging conrol messages. The hird merics is join / leave cos. The join/leave cos is an alernaive measure of laency o reflec he real delay in join / leave processing. They are given in more deails as follows. To calculae he oal processing / delivering cos in a mulicas ree, a basic packe (BP) wih a size of maximum ransfer uni (MTU) is used a benchmark. The BP is a packe which has an IP header, wih one source and one desinaion, and is payload. Mulicas packes (MPs) are always of a bigger size han a BP due o he fac ha here migh be a mulicas group address or a proocol header in he mulicas packes. However, he conrol messages (CMs) (in EM and REM) are usually of a size of less han MTU (for EM) or far less han MTU (for REM). For simpliciy, we rea hem as mulicas packes wih a size of MTU. We define he processing cos o be ( uni ) if a packe wih a size of BP is needed o be processed a a node and he delivering cos of his packe o be as well if i is delivered via a link wih a cos of. Then, he processing cos a a node k is given by =, () MP P cos ( N k ) M k, MP + M k, CM BP

6 where M k, and MP M k, are he number of desinaions in CM mulicas packes and ha in conrol messages a node k, and MP are he size of a mulicas packe and he size BP of a BP (i.e. MTU), respecively. In our simulaion, he values of MTU fixed a 576 oces, i.e., he minimum size of packes required for rouers. When he size of mulicas packes is over MTU, a fragmen processing for packes is needed, which migh happens for Xcas mulicas packes, bu no being considered in our simulaion. Correspondingly, he delivering cos for one mulicas packe over a link i is given by MP D cos ( Li ) = Li ( + J i, CM ), (2) BP where J i, and CM L i are he number of desinaions in conrol messages and he cos over a link i, respecively. Based on hese consideraions, he average processing cos ( P cos ) a a node and average delivering cos ( D cos ) over a link are given by, P cos = P ( N ), cos N T (3) D cos = Dcos ( L ), L (4) T where N and L are he oal number of rouers and he oal number of links in he nework, and N and L are he number of acive rouers and he number of acive links in he mulicas ree, respecively. P cos and D cos denoe processing cos a a node and delivering cos over a link, respecively. As for feasible measures of laency, join / leave delay cos should be able o reflec he real nework as closely as possible. In mulicas, here are many facors o conribue he join/leave laency, such as how he regisraion (owards he source) is carried ou, he quaniy of mulicas raffic needed o be processed a nodes and over links, he ime o build he mulicas ree, he size of queue ec. However, heir conribuions in occurred laency are varied for differen mulicas proocols. For Xcas and Xcas+, no processing of building he mulicas ree is needed bu more processing cos a nodes and delivering cos over links, while for EM he whole mulicas ree is needed o be se up in advance, compared o ha for REM where he mulicas ree is buil gradually and could be updaed locally, and less processing and delivering cos are required for boh EM and REM. In our consideraion of join/leave laency, we assume ha he delay cos occurred in he regisraion processes are idenical for all four proocols. This assumpion is reasonable because for all mulicas proocol considered he source is always in charge of racking he membership of mulicas group. Furhermore, for simpliciy, he average processing cos a nodes and average delivering cos over links are furher used o reflec he delay cos, bu heir conribuions o delay cos are added ogeher hough weighing. Based on hese consideraions, we define he join/leave delay cos for a given receiver i as follows: T cos ( i) = K i, nodes P cos + γk i, links D cos, (5) where K i, and nodes K i, are he number of nodes (rouers) links and he number of links involved in he receiver i s join/ leave processing, P cos and D cos are given by equaion () and (2), respecively. γ is a weighing facor. Ifγ >>, i means he processing cos a nodes plays he dominan role o he join/leave delay cos; if γ <<, means ha he delivering cos over links dominae he join/leave delay cos; oherwise, he processing a nodes and delivering over links conribue o he join/leave delay cos in he same level. Therefore, he average join / leave delay cos for all receivers is given by where T N R cos = Lcos ( i) N R i= N is he number of receivers. R, (6) For each simulaion resul, we run simulaion imes for each proocol, and hen he resuls are shown by average. In Figures 4 and 5,, he average processing / delivering cos for REM, EM, Xcas and Xcas+ as a funcion of he number of receivers per LMRs, are depiced, where he number of LMRs is fixed a 2. I is shown ha boh processing and delivering coss in REM, EM and Xcas increases approximaely linear, bu increases dramaically in Xcas. This means ha Xcas is no scalable and jus a soluion for small mulicas groups and oher hree proocols are more scalable han Xcas. Figures 6 and 7 show he average processing cos a nodes and average delivering cos over links for four proocols as a funcion of he number of LMRs, respecively. Boh processing cos and delivering cos of four proocols normally increases wih he increase of he group size. The proposed REM always ouperforms he

7 oher hree proocols. Furhermore, Figures 8 and 9 show he maximum processing cos a nodes / delivering cos over links for four proocols as he increasing of he number of LMRs. I is easy o see ha only REM has an approximaely fla maximum cos in processing / delivering as he number of LMRs changes. However, he cos in he oher hree proocols is increasing remarkably as he number of LMRs increases. This means REM is more scalable han oher ree proocols, because he maximum processing cos a nodes / delivering cos over links is an indicaion of possible delivering/processing maximum burden a nodes /over links. In Fig he average join/leave delay cos is demonsraed as a funcion of he number of LMRs, where he number of receivers per LMRs is fixed a and γ is se o as well. I is shown ha he proposed REM proocol has much lower cos in delay compared wih all of oher hree proocols. For example, he delay cos in our proposed REM is only abou one fourh of ha in Xcas and Xcas+ and one eighh of ha in EM, as he number of LMRs is 3. This is a very aracive advanage of our proposed proocol. [3] I. oica, T. Ng, and H. Zhang. REUNITE: A recursive unicas approach o mulicas. In Proceedings of IEEE INFOCOM, Tel Aviv, Israel, Mar. 2. [4] R. Boivie e al., Explici mulicas (Xcas) basic specificaion,<draf-ooms-xcas-basic-spec-.x>, 2. [5] M. hin e al., Explici Mulicas (Xcas+) upporing Iniiaed Join, <draf-shin-xcas-reciever-join-.x>, 2. [6] A.Boudani and B.Cousin, imple explici mulicas <draf-boudani-simple-xcas-.x>, Jan. 22. [7] B. M. Waxman, Rouing of mulipoin connecions, IEEE Jounal of eleced Areas in Communicaions, vol.6, no.9, pp ,988. [8] Ravindra. K. Ahuja, Thomas L. Maganai and James B. Orlin. Nework Flows: Theroy, algorihms and applicaions. New Jersy: Prenice-Hall,993. V. Conclusion In paper, a new mulicas scheme is proposed, named scalable recursive explici mulicas (REM). In REM, mulicas ree is buil gradually as he joining / leaving of members of mulicas groups and he delivery of mulicas is done recursively via branching node rouers. This is implemened by he use of a pair of branching node messages (BNMs), which have a fla size. REM have wo advanages, i.e., being scalable and lower joining / leaving laency, which is esified by he simulaion resuls. The resuls show ha REM provides much high scalabiliy and less laency for he joining and leaving of he new members. The laer advanage makes i he bes candidae for mulicasing over mobile neworks. References [] R. Perlman, e al, imple Mulicas: A design for simple, low-overhead mulicas, Inerne Draf, <drafperlman-simple-mulicas-3.x>. [2] H.W. Holbrook and D.R. Cherion, IP mulicas channels: EXPRE suppor for large-scale singlesource applicaions, in IGCOMM 99, Cambridge, Massachuses, Aug. 999.

8 Figure 4 Average processing cos versus he number of receivers per LMR Fig 6. Average processing cos versus he number of LMRs. Fig 5. Average delivering cos versus he number of receivers per LMR Fig 7. Average delivering cos versus he number of LMR

9 Fig 8 Maximum processing cos Fig Average join/leave delay cos for REM, EM, Xcas and Xcas+. (b) Fig 9. Maximum delivering cos