Optimal Distribution of Remotely-Subscribed Multicast Traffic within a Proxy Mobile IPv6 Domain by Using Explicit Multicast

Transcription

1 ptmal strbuton of Remotely-Subscrbed Multcast Traffc wthn a Proxy Moble v6 oman by Usng Explct Multcast us M. Contreras *, Carlos J. Bernardos * Core Networ Evoluton Telefónca I+ on Ramón de la Cruz, 82-84, 28006, Madrd, Span epartament of Telematcs Engneerng, Unversdad Carlos III de Madrd Avda. Unversdad, 30, 289, eganés, Span. lmcm@td.es, cjbc@t.uc3m.es Abstract strbuton of remotely subscrbed multcast content n a Proxy Moble v6 (PMv6) doman s performed by means of b-drectonal -n- tunnels establshed between the moblty anchor and the vsted access gateways where the moble termnals consumng such traffc are attached to. Each access gateway subscrbng to content on behalf of an attached moble termnal requres a separate copy of the remote multcast flow beng dstrbuted over the PMv6 doman. In many cases, these ndvdual copes traverse the same routers n the path from the moblty anchor towards the access gateways, ncurrng n an neffcent dstrbuton, whch s equvalent to the uncast delvery of the remote multcast content wthn the doman. Ths paper explores the potental gan obtaned by usng explct multcast nstead of the standard -n- tunnelng, showng relevant capacty savngs wth lower overhead respect to the standard dstrbuton case. Ths transport servce based on explct multcast emerges then as an attractve transport alternatve for PMv6 doman operators servng vstng moble multcast consumers. Keywords-component; PMv6; multcast; ; optmzaton. I. INTRUCTIN The new capabltes beng offered by the moble wreless technologes are brngng broadband capacty networs outsde the home, representng addtonal delvery optons for the dstrbuton of broadband servces on the move. The commercal success of moble multmedaenabled termnals, manly because of the success of S and Androd based devces, s rapdly ncreasng the demand of moble data access, especally audovsual contents. multcast bascally facltates the delvery of a sngle copy of a data stream to multple lsteners nterested n recevng the same content smultaneously. Ths capablty s commonly used nowadays n telecom networs, for nstance, to dstrbute TV content (nown as TV servce). The need for supportng the same nd of servces both n fxed and moble networs brngs the necessty of delverng multcast also to moble recevers. Proxy Moble v6 (PMv6) [] s a networ-based moblty management protocol whch enables the networ to provde moblty support to standard termnals resdng n the networ. These termnals enjoy ths moblty servce wthout beng requred to mplement any moblty-specfc operatons. Namely, PMv6 s one of the mechansms adopted by the 3GPP to support the moblty management n future Evolved Pacet System (EPS) networs [2]. PMv6 allows a Moble Access Gateway (MAG) to establsh a dstnct b-drectonal tunnel wth dfferent ocal Moblty Anchors (MAs), beng each tunnel shared by the attached Moble Nodes (MNs). Each moble node s assocated wth an MA, whch eeps trac of ts current locaton, that s, the MAG where the moble node s attached. -n- encapsulaton s used wthn the tunnel to forward traffc between the MA and the MAG (see Fgure ). The basc soluton [3] of multcast traffc dstrbuton wthn a PMv6 doman maes use of the b-drectonal MA-MAG tunnels. It follows the so-called remote subscrpton model, n whch the subscrbed multcast content s delvered from the Home Networ. By dong so, an ndvdual copy of every multcast flow s delvered through each tunnel connectng the moblty anchor to any of the access gateways n the doman. In many cases, these ndvdual copes traverse the same routers n the path towards the access gateways, ncurrng n an neffcent dstrbuton, equvalent to the uncast dstrbuton of the multcast content n the doman, as shown n Fgure 2. Ths fact leads to dstrbuton neffcences and hgher per-bt delvery costs, ncurred by a PMv6 doman operator offerng transport capabltes to a Home Networ operator for servng ther MNs when attached to the PMv6 doman. As long as the remotely subscrbed multcast servce s not affected, t seems worthy to explore more optmal ways of dstrbutng such content wthn the PIMPv6 doman.

2 MA I Prefx MAG MN Pref::/64 MAG MN2 Pref2::/64 MAG Multcast Tree PMv6 doman MA MAG MN MN2 Fgure. PMv6 mode of operaton As later dscussed, local multcast dstrbuton to the PMv6 doman (also nown as drect routng) s not always feasble then we focused on the remote subscrpton case. Ths paper addresses ths ssue by analyzng the capabltes provded by Explct Multcast (Xcast) [4] to provde an optmal and effcent multcast traffc dstrbuton from the bandwdth consumpton pont of vew. Secton II descrbes the dfferent alternatves exstng today for multcast traffc dstrbuton wthn a PMv6 doman, remarng the potental neffcency observed n case of remotelysubscrbed multcast. Secton III ntroduces the applcablty of the explct multcast for the dstrbuton of the multcast flows n the doman, and extensons needed for usng explct multcast n PMv6 are dentfed. Furthermore, n Secton IV a performance evaluaton s conducted to assess the potental gans due to the use of explct multcast n the dstrbuton networ. Secton V addresses some conclusons and advances some further wor. Fnally, Appendx A provdes some nsghts on the PMv6 doman scalablty to determne the vablty of the proposed explct multcast approach. II. MUTICAST ISTRIBUTIN IN PMV6 As a general procedure for subscrbng to a multcast content, a moble node expresses ts nterest n jonng or leavng a multcast group by sendng Multcast stener scovery (M) control messages to the MAG, whch acts as the frst hop at the pont-to-pont ln establshed wth the MN. The MAG mantans the ndvdual multcast status of the nterface for that ln and handles the multcast traffc towards the MN accordngly to the M messages receved. There are two alternatves to dstrbute multcast traffc wthn a PMv6 doman: remote subscrpton and drect routng. The former s prmary focused on the multcast dstrbuton from networs outsde the PMv6 doman (e.g., the Home networ or thrd partes networs), whle the later results convenent for the multcast dstrbuton of content locally avalable at the PMv6 doman. Home Networ PMv6 doman MAG MAG2 MAG3 Fgure 2. Ineffcent dstrbuton of remote subscrbed multcast traffc n a PMv6 doman A. Remote subscrpton The baselne soluton [3] consders only the remote subscrpton case, where the MN obtans the desred multcast stream from ts home networ, through the local moblty anchor. The MA s n charge of nteractng wth the multcast nfrastructure out of the PMv6 doman. In the base soluton, the MAG nstantates a dstnct M proxy functonalty per every set of MNs assocated to a specfc MA. Each M proxy nstance s responsble of summarzng the subscrpton requests of the MNs connected to t on a per MA assocaton bass. The dfferent proxy nstances of the same MAG are solated one from the other. Wth the remote subscrpton model, the multcast traffc reaches the MNs after gong through the correspondng MA (note that there mght be multple MAs n the same doman). For every proxy nstance n the MAG, the tunnel nterface pontng to the MA becomes the proxy upstream nterface, whereas the lns towards the MNs are the correspondng downstream nterfaces of each nstance. Then, every MAG-MA tunnel s part of a separate M proxy doman, beng a branch of the multcast tree bult for multcast traffc dstrbuton nternally to the doman. A sngle copy of a data stream wll be sent per group of MNs (attached to a certan MAG) assocated to the same MA. The MA wll mantan the multcast state of every tunnel nterface, reflectng the summarzed vew offered by the MAG on behalf of the attached MNs bound to the MA. The base soluton suffers from the tunnel convergence problem, where several copes from the same multcast stream can reach the access gateway when smultaneous subscrptons from MNs assocated to dstnct MAs occur. To avod that, a central entty named Multcast Tree Moblty Anchor (MTMA) [5] can be deployed n the PMv6 doman to act as the topologcal anchor pont for remotely servng multcast traffc to the MNs n the doman, ndependently of the MA whch mantan the assocaton for recevng uncast traffc. The MTMA connects to the MAG as descrbed n [3]. The b-drectonal tunnels among the MTMA and the access

3 gateways n the doman are part of the multcast tree for remote multcast traffc dstrbuton. Therefore, a copy of every multcast channel subscrbed by a MAG on behalf of an attached MN s transported on those tunnels to reach the correspondng access gateway. The MTMA can be then consdered as a form of upstream multcast router wth tunnel nterfaces allowng remote subscrpton for the MNs. B. rect routng A second opton to lmt the number of copes of the same content at the MAG s the usage of a natve multcast nfrastructure n the PMv6 doman [5] allowng drect multcast routng from locally avalable multcast sources. In ths case, the MAG can be drectly connected to an upstream multcast router n the PMv6 doman, whle the uncast traffc remans served as normally by the correspondng MAs. Followng ths approach, the usage of the b-drectonal tunnels s totally avoded, snce the multcast traffc s natvely dstrbuted wthn the PMv6 doman. Ths s the most effectve way of multcast dstrbuton wthn the doman, but unfortunately t s not always possble for nontechncal reasons, such as for example: The multcast source s not local to the PMv6 doman, beng located ether n the Home networ or hosted by a thrd party. The multcast content cannot be natvely dstrbuted wthn the local PMv6 doman due to admnstratve or regulatory reasons; as for nstance, multcast address allocaton ssues between the assgned addresses n the local PMv6 doman and n the multcast source home networ (.e., a certan multcast address dentfes dfferent multcast content channels n both the Home and the PMv6 domans), or some contents may be not allowed for dstrbuton n a certan networ, le regonal or ethncal channels out of the target regon. The multcast content s not natvely dstrbuted n the local PMv6 doman due to commercal and busness ntellgence reasons; for nstance, the Home networ operator mght not be nterested on provdng vsblty about what content ts MNs subscrbe to. These are some of the reasons why the remote subscrpton case s relevant and requres to be properly addressed. PMv6 doman operators can commercalze ths servce, offerng transport capabltes to the Home networ operators to reach ts MNs wth a multcast servce. Provdng ths transport servce n the most effcent manner s then economcally attractve from the PMv6 doman operator pont of vew. C. Effcency problems The transport of the remotely-subscrbed multcast traffc by means of -n- uncast tunnels n the PMv6 doman s neffcent as several copes of the same content traverse the same lns and are forwarded by the same routers. Two alternatves to mprove ths dstrbuton can be taen nto account: natve multcast transport (drect routng) on the PMv6 doman, or explct multcast (Xcast) transport of the multcast traffc. The former has been already descrbed, and some stuatons could prevent ts use. We now focus on the latter, by proposng the use of -n-xcast encapsulaton between the moblty anchor and the access gateways nstead of the standard -n- tunnelng. III. MUTICAST ISTRIBUTIN AMNG MBIITY ANCHR AN ACCESS GATEWAYS WITH EXPICIT MUTICAST A. Introducton to Xcast The Xcast protocol has been proposed as a way of optmzng the delvery of multcast traffc for small groups. Bascally, the Xcast mechansm elmnates the need of persesson sgnalng and per-sesson state nformaton of tradtonal multcast schemes by ncludng the lst of destnatons n the data pacet, nstead of usng a multcast address. To do that, the source node eeps trac of the fnal destnatons n the multcast channel that t wants to send pacets to. Wth Xcast, each router n the path between the source and the destnaton parses the header and creates a new datagram for every next hop ncludng only the destnatons reachable through that next hop accordng to the routng table, n such a way that the header of the subsequent Xcast pacets only contans the destnatons avalable n the path. The Xcast pacet always follows the ordnary uncast routng for a gven destnaton. When just one destnaton remans to be reached, the Xcast pacet s transformed nto a normal uncast pacet. Fgure 3 graphcally descrbes the Xcast procedures for the case n whch a node A smultaneously delvers data content to nodes B, C and wth Xcast encapsulaton. The processng that a router does for every Xcast pacet s the followng: () the router performs a route table looup to determne the next hop for each of the destnatons lsted n the pacet; () the router parttons the set of destnatons based on ther next hops; () t replcates the pacet so that there s one copy of the pacet for each of the next hops found n the prevous steps; (v) before delverng the new pacet, t modfes the lst of destnatons n each of the copes so that the lst n the copy for a gven next hop ncludes just the destnatons reachable through that next hop; (v) fnally, the router sends the modfed copes of the pacet on the next hops. B. Benefts and mpacts of usng Xcast Regardng tradtonal multcast, Xcast offers a number of advantages that have been reported on [4], such as not needng to mantan multcast state per group n every router on the tree, or not requrng multcast address allocaton. However, some drawbacs have also been dentfed, such as the ncurred overhead, or the header processng complexty. Furthermore, as descrbed later n the paper, the specfed Xcast header allows a maxmum of 27 destnatons. Ths means that n case of havng more destnatons on the path, separate Xcast trees should be formed.

4 st= All_Xcast Xcast B/ C / ata Payload st= B ata Payload R4 B st= C ata Payload A R R2 R3 R8 C (a) (b) Xcast C / st= All_Xcast ata Payload R5 R6 R7 st= ata Payload R9 Fgure 3. Explct multcast (Xcast) mode of operaton Ths mples that, when appled to the PMv6 case, a lmt of 27 access gateways per moblty anchor s downstream nterface has to be consdered n the dstrbuton tree. In the Appendx A the number of access gateways n a doman s dscussed n order to determne how ths lmt could mpose restrctons n a typcal PMv6 doman for the deployment of Xcast functonaltes. C. Modfcatons to standard PMv6 procedures for usng Xcast n a doman The MAG does not change ts behavor and subscrbes to the multcast content on behalf of the MNs (actng as a proxy) by usng a multcast group membershp protocol such as M. The multcast content requests wll reach the moblty anchor through the tunnel, followng the standard -n- encapsulaton []. The moblty anchor wll act as an Xcast source, and wll tae the decson of encapsulatng the multcast traffc n an -n-xcast mode n ts downstream nterfaces reachng the MAGs, nstead of usng the standard -n- tunnel. The router present n the bfurcaton pont n the end to end path provdng connectvty the last segment to reach a MAG (.e., no more MAGs reachable through that branch from that router), wll send the multcast pacet n uncast fashon as n the -n- case (see Fgure 2), so the MAG wll not perceved any change n the multcast dstrbuton regardng the standard case. Two ways of Xcast dstrbuton can be consdered. n one hand, t can be consdered that all the subscrptons between a set of MAGs and the moblty anchor are dstrbuted over the same -n-xcast tunnel, groupng all the multcast channels subscrbed for a certan group of MAGs. n the other hand, t can be consdered that a separate -n- Xcast tunnel s used per multcast channel. The tunnel management s very complex n the frst case, as the tunnel has to be dynamcally updated. Furthermore, dfferent subscrpton groupngs should be arranged accordng to the subscrptons exstng on the MAGs. The second case s smpler, and t s the one selected n ths paper. Fgure 4. Exampleof -tree structure wth =2 and =4 (a), and parameters defnng a a -tree structure (b).. Handover dynamcs usng Xcast In the event of a handover, the movement of an MN can produce the need of creatng a new branch for the dstrbuton of the multcast content to the MAG where the MN s beng attached (n case there s no other MN n that MAG subscrbed to the desred content). Smlarly, such movement can produce the removal of an exstng branch from the MAG where prevously t was attached (n case the MN was the last subscrber to a certan content). As the MA s aware of the channels subscrbed per MAG n the remote subscrpton case, the MA has to tae the decson of Xcast forwardng to the MAG. When a new branch has to be formed due to a handover event, t wll smply mean the need of addng a new destnaton to the Xcast header pontng to the requestng MAG. Furthermore, when an exstng branch has to be removed also for a handover event, the MA has just to remove the correspondng MAG from the desred destnatons from the Xcast header. IV. PERFRMANCE CMPARISN A. efnton of the scenaros under analyss In order to evaluate and compare the potental gans n the use of Xcast for transportng the multcast traffc between the moblty anchor and the access gateways wthn a PMv6 doman, we wll model the dstrbuton tree wth a -tree structure as consdered n [6]. Fgure 4 (a) shows an example of a -tree composed by a total number of 3 nodes (.e., =2, =4). A -tree structure can be characterzed by two parameters, as depcted n Fgure 4 (b):, the degree of the tree or number of leaves recursvely found from every prevous leaf on the tree, and, the depth of the tree, whch ndcates the number of levels n the dstrbuton tree. N, the total number of nodes n a certan -tree, s gven by: + N =, () whle the number of potental recevers (MAGs n ths analyss), m, s obtaned from: m = (2)

5 B. Performance evaluaton The performance evaluaton of Xcast versus the standard dstrbuton s carred out by comparng the number of traversed lns between the moblty anchor and the access gateways when each of these solutons s used to dstrbute a multcast channel. ) General calculaton The prevous calculaton has consdered that all MAGs subscrbe to the same content. Whle ths can be true for hghly demanded content, t cannot be generalzed. In ths secton we try to formulate the generc calculaton of the lns traversed n a PMv6 as a functon of the demand. A certan channel wll be subscrbed by the MAG f there s at least one attached MN demandng such channel. et us consder p as the probablty of a MAG demandng a certan channel, then t can be establshed that p= f there s at least an MN requestng the channel, and p=0 otherwse. Then, n the standard case, the lns traversed for servng the MAGs demandng the channel wll be: std MAG = p. (3) through two dfferent -tree structures, wth 8 degrees and 2 depth levels n one case, and 4 degrees and 3 depth levels n the second. The number of ntermedate nodes changes, obtanng n the frst case a flatter archtecture. The second fgure, consderng 729 MAGs (whch can be connected ether by -trees of parameters =9 and =3, or =3 and =6), s presented to evaluate the senstvty of Xcast to the growth n the number of connected MAGs, only for llustratve purposes, as such hgh number of MAGs cannot be ncluded n a unque Xcast tree due to the lmtaton on the number of destnatons per Xcast header. As observed from Fgures 5 and 6, more herarchcal - tree structures provde more savngs that ther flattened counterparts for connectng the same number of MAGs. Ths trend s more sgnfcant as the number of MAGs n the tree ncreases. The gan ncreases rapdly wth the probablty of subscrpton per MAG p, and t s asymptotcally bounded, whch means that the maxmum networ resource savngs are closely reached even for moderately popular channels. Fnally, t can be concluded that hgher savngs are obtaned as the number of MAGs grows n the doman. The total number of lns traversed n the PMv6 doman can be establshed on: std = m p = p (4) For the Xcast case, t s a bt more complex to calculate the ln usage, as the usage at a level of the tree depends on the usage of the followng level, as can be derved from Fgure 4. A ln of a certan level wll not be traversed f none of the recevers (MAGs) below t subscrbes to such content. Ths can be formulated n the followng way: m m 2 = ( ( p ) ) = = ( ( p )) = ( ( p )) (5) ( ( p ) ), (6) and, n general: m ( d ) ( d ) ( d ) ( d ) = ( ( p ) ) = ( ( p ) ). (7) d Then, the total number of lns traversed n the Xcast case wll be the sum of the lns used for all the levels, gven by: Xcast = (8) Fgures 5 and 6 show the comparson of the gan obtaned for dfferent -trees dstrbuton archtectures connectng the same number of moble access gateways, as a functon of the probablty of subscrpton p for a certan multcast channel per MAG (note that the probablty of subscrpton of any MAG s ndependent of the probablty of subscrpton of the other MAGs n the doman, then t can be stated that p = p,, assumng a smlar average number of MNs per MAG). In the frst fgure, 64 MAGs are connected Fgure 5. Gan due to multcast for two dfferent -tree structures connectng 64 MAGs Fgure 6. Gan due to multcast for two dfferent -tree structures connectng 729 MAGs (for llustratve purposes)

6 Fxed Part Varable Part Fgure 7. Xcast header format C. verhead calculaton Another relevant aspect s the comparson between multcast and Xcast n terms of the total overhead on the dstrbuton structure under analyss. The standard dstrbuton of the remotely subscrbed multcast context uses -n- encapsulaton, and therefore the overhead s due to the encapsulaton n the b-drectonal tunnel. In our proposal, the remotely subscrbed multcast content s dstrbuted n an -n-xcast fashon; then the overhead wll be orgnated by the Xcast mechansm. ) Standard multcast case Consderng h as the overhead bts needed for the encapsulaton of the remote multcast channel (.e. the 40 bytes of an v6 header n an -n- tunnel), the total overhead due for transportng a multcast channel all the path from the moblty anchor to an access gateway can be stated as: std ch MAG = h. (9) Extendng ths formula to the set of MAGs n the doman, the total overhead for a multcast channel beng dstrbuted to all the MAGs across the PMv6 doman can be wrtten as: std ch doman = h. (0) 2) Xcast case In Xcast defnton, the encapsulaton defned s composed of an v6 header and an Xcast header, carred as a routng extenson, whch s structured n a fxed part and a varable one. The v6 header wll have as source address the address of the Xcast sender (the moblty anchor n our case), beng the destnaton address the all_xcast_routers address. As consequence of the v6 header, every Xcast pacet wll account h bytes. The Xcast header presents a fxed 24-byte part ncludng several protocol felds. Among them, the NBR_F_EST feld determnes the maxmum number of destnatons that can be ncluded n the Xcast header. Ths feld s 7 bt long, so a maxmum of 27 destnatons could be ncluded n an Xcast dstrbuton. The ssue on the number of the maxmum number of the destnatons (.e., MAGs) s dscussed on Appendx A, at the end of the paper. The varable part of the Xcast header wll carry the lst of the destnaton addresses for pacet forwardng. Each Xcast router n the path wll evaluate the lst of destnatons to replcate the pacet accordngly for each of the correspondng next hops, ncludng on the next pacet just the destnatons to be routed through the next hop, onwards. Ths varable part ncludes also a BITMAP feld, of whch sze depends on the number of destnatons, beng a multple of 64 bts. Then, the sze of an Xcast header for a certan dstrbuton level n the -tree can be can be formulated as: N d d h ( bytes) = 24 + N 6 + 8, () d 64 beng N d the number of destnatons reachable from level d n a certan branch, that can be defned n the followng manner: ( ) N = d d. (2) Each Xcast pacet s converted nto a normal uncast pacet for reachng the last destnaton. In that case, correspondng to the frst level n the tree,, the applcable overhead wll be just h, wth h = 0. When extendng these formulas to the whole set of MAGs n the doman, we obtan: ch 2 ch 3 = + = ch = ( h + h ) = h (3) ( h + h ) = h ( h + h ) = h , 64 and, n general: ch d + = ( d ) ( d ) d ( d ) ( h + h ) = h d d (4) (5) (6) Then, consderng the total dstrbuton n the PMv6 doman, the general formulaton of the overhead requred for dstrbutng a multcast channel to all the MAGs s gven by:

7 = = ch doman ch d d = ( d ) ( d ) d = h + h, d = d = 2 that can be rewrtten as: (7) ( ) d h. (8) ( d ) ch doman = h + d = 2 Fgures 8 and 9 present a comparson of the overhead for dstrbutng a channel to all the MAGs n a doman, consderng dfferent -tree confguratons. The Xcast opton ntroduces less overhead than the standard case as the degree n the tree,, grows for a gven tree depth,. At the same tme, as the depth of the tree ncreases, the advantage on usng Xcast becomes more sgnfcant for hgher -tree degrees. V. CNCUSINS AN FURTHER WRK As shown n the prevous analyss, the Xcast encapsulaton can provde a lower cost per transported bt for a PMv6 doman operator offerng remote multcast dstrbuton capabltes to a Home Networ operator, allowng for better beneft margns. It can also be concluded that the most effcent dstrbuton structures for servng a certan number of MAGs n the PMv6 doman are those more herarchcal (.e., wth greater number of levels, ), nstead of the flatten ones, because a hgher gan s acheved respect to the standard multcast case. Ths matches exstng operators networ topologes. Furthermore, hgher degrees n the tree result n less overhead for the Xcast case. As next steps, we are worng on the characterzaton of the total overhead as a functon of the channel subscrpton probablty at the MAG. We are also studyng how to dynamcally decde when to use standard multcast versus Xcast transport dependng on the locatons of the MAGs subscrbng the content n the -tree, and n general, dependng on the number of MAGs subscrbng the content, for allevatng ntermedate routers of the burden of Xcast processng n scenaros of low gan. ACKNWEGMENTS The research of Carlos J. Bernardos leadng to these results has receved fundng from the European s Communty s Seventh Framewor Programme (FP7-ICT ) under the grant agreement n (MEIEVA project), beng also partally supported by the Mnstry of Scence and Innovaton (MICINN) of Span under the QUARTET project (TIN C02-0). verhead (Bytes) verhead (n bytes) for = , degree of the tree standard Fgure 8. overhead comparson for dfferent degrees values n a - tree wth depth =2 verhead (Bytes) verhead (n bytes) for = , degree of the tree standard Fgure 9. overhead comparson for dfferent degrees values n a - tree wth depth =3 REFERENCES [] S. Gundavell, K. eung, V. evarapall, K. Chowdhury, B. Patl, Proxy Moble v6, RFC 523, August, [2] 3GPP, Archtecture enhancements for non-3gpp accesses, 3GPP TS , September 20. [3] T.C. Schmdt, M. Waehlsch, and S. Krshnan, A Mnmal eployment pton for Multcast steners n PMv6 omans, RFC 6224, Aprl, 20. [4] R. Bove, N. Feldman, Y. Ima, W. vens,. oms, Explct multcast (Xcast) concepts and optons, RFC 5058, November, [5] J.C. Zunga,.M. Contreras, C.J. Bernardos, S. Jeon, Y. Km, Multcast moblty routng optmzatons for Proxy Moble v6, RFC 7028, September, 203. [6] P. Van Meghem, G. Hooghemstra, R. van der Hofstad, n the effcency of multcast, IEEE/ACM Transactons on Networng, Vol. 9, No. 6, pp , ecember, 200. [7] H. uo, H. Zhang, Y. Qn, V.C.M. eung, An approach for buldng scalable Proxy Moble v6 domans, IEEE Transactons on Networ and Servce Management, Vol. 8, No.3, pp , September, 20. [8] C. Perns,. Johnson, J. Aro, Moblty support n v6, RFC 6275, July 20. [9] Csco 8500 Seres Wreless Controller eployment Gude, ocument I 3695, ctober 202 (downloadable at: accessed n November 202.

8 APPENIX A N THE NUMBER F MAGS IN A PMV6 MAIN Ths Appendx ams at dscussng the typcal number of MAGs n a PMv6 doman as a way of determnng the potental lmtatons on the use of Xcast n a PMv6 doman. The length of the feld NBR_F_EST (7 bt) of the Xcast header lmts the maxmum of destnatons to 27. Note that ths lmt apples to each branch of the -tree, n such a way that the total number of MAGs per -tree (.e., per moblty anchor) can be rased to 27. In order to evaluate how ths number could be n lne wth the number of MAGs n a PMv6 deployment, we wll analyze the potental scalablty of a PMv6 doman n terms of users and number of access gateways. We next partally follow the analyss consdered n [7]. There, authors looed at the bandwdth requrements of the moblty anchor as one of the lmtng factors for ths entty. Beng R S the rate of oversubscrpton n the MA (that s, the rate of the total number of MNs regstered n excess regardng the number of actually actve MNs), and T p the pea data throughput per actve MN, the bandwdth delvered by the moblty anchor equals to: Tp BW = M, (9) anchor ( R +) where M represents the total number of MNs regstered at the moblty anchor n the PMv6 doman. Commercal off-the-self core routers today are capable of delverng traffc n the order of Tbps. Table II summarzes the achevable number of MNs n the PMv6 doman assumng a moblty anchor forwardng capacty of Tbps, consderng dfferent values of the observable pea data throughput and oversubscrpton ratos. S TABE I. NUMBER F REGISTERE MNS PER MBIITY ANCHR WITH A FRWARING CAPACITY F TBPS Pea data throughput, T p versubscr., R S 00bps Mbps 0Mbps For every attached MN, the moblty anchor has to eep an entry n the bndng cache. Such an entry contans a number of felds [] [8], le the MN dentfer (28 bts), the MN s ln layer dentfer (64 bts), the MAG s ln layer dentfer (28 bts), the lst of the Home Networ Prefxes (HNPs) for the MN s nterface (each prefx beng 28 bts), the tunnel dentfer (at most 28 bts), the Proxy Care-of- Address (28 bts), etc. These felds requre a storage capacty above 000 bts per MN. Taen ths nto account, the upper lmt n the number of MNs observed n Table II mposes the need of handlng a global bndng cache memory n the order of 0 Tbts. Ths huge storage capacty, the correspondng number of assocated routng entres, and the looup capacty requred to handle both of them, mae that upper lmt unachevable. Therefore, we can argue that a more realstc upper lmt of MNs managed by a moblty anchor would be n the order of few hundreds of thousand termnals. Current state-of-the-art MAG specfcatons [9] support a maxmum number of 40,000 attached MNs. Ths mples that only a branch of the -tree (that s, a downstream nterface of the moblty anchor), wth 27 of those MAGs, could potentally provde connectvty to more than 5 mllon MNs, much more than the total number of MNs per moblty anchor. To sum up, t can be stated that the number of MAGs per branch wll be lower than the lmt mposed by the feld NBR_F_EST n the Xcast header. We have slghtly modfed the formula used for obtanng Fg. 9 n [7] because t s not totally correct from our pont of vew. In the orgnal formula the denomnator only consders the rate of oversubscrpton, R S, not provdng a consstent result for the case when no oversubscrpton occurs.