An Efficient Elastic Distributed SDN Controller for Follow-Me Cloud

An Effcent Elastc Dstrbuted SDN Controller for Follow-Me Cloud Abdelkader Assou PrSM/Unversty of Versalles Versalles, France E-mal: abdelkader.assou@ens.uvsq.fr Adlen Ksentn IRISA/Unversty of Rennes Rennes, France E-mal: adlen.ksentn@rsa.fr Abdelhak Guerou PrSM/Unversty of Versalles Versalles, France E-mal: mogue@prsm.uvsq.fr Abstract Follow Me Cloud (FMC) concept has emerged as a promsng technology that allows seamless mgraton of servces accordng to the correspondng users moblty. Meanwhle, Software Defned Networkng (SDN) s a new paradgm that permts to decouple the control and data planes of tradtonal network, and provdes programmablty and flexblty, allowng the network to dynamcally adapt to changng traffc patterns and user demands. Whle the SDN mplementatons are ganng momentum, the control plane, however, s stll sufferng from scalablty and performance concerns for a very large network. In ths paper, we address these scalablty and performance ssues by ntroducng a novel SDN/OpenFlow-based archtecture and control plane framework talored for moble cloud computng systems and more specfcally for FMC-based systems where moble nodes and network servces are subject to constrants of movements and mgratons. Contrary to centralzed approach wth sngle SDN controller, our approach permts to dstrbute the SDN/OpenFlow control plane on a two-level herarchcal archtecture: a frst level wth a global controller G-FMCC, and second level wth several local controllers L-FMCC(s). Thanks to our control plane framework and Network Functon Vrtualzaton concept (NFV), the L-FMCC(s) are deployed on-demand, where and when needed, dependng on the global system load. Results obtaned va analyss show that our soluton ensures more effcent management of control plane, performances mantanng and network resources preservaton. I. INTRODUCTION Today, servce provsonng fnds n the emergng Cloud Computng paradgm a flexble and economcally effcent soluton, n partcular for small and medum enterprses that do not want to nvest huge captals for creatng and managng ther own IT nfrastructures. The basc tenet of cloud computng s that end users do not need to care about where a servce s actually hosted, whle servce provders may dynamcally acqure the resources they need for servce provsonng n a pay-per-use model. Whle for most of elastc web applcatons the relatve poston of clent and server end systems does not affect the perceved Qualty of Experence, rch nteractve applcatons are sensble to other communcaton metrcs, such as delay and jtter. In the absence of explct QoS control mechansms n the network, the only way to mprove Qualty of Experence s to locate servers as close as possble to user termnals. Such an approach, largely exploted by Content Delvery Networks, can be further advanced n the era of Cloud Computng [1]. Assumng that several cloud-enabled Data Centers are made avalable at the edges of the Internet (.e. Federated Cloud), servce provders may take advantage of them for optmally locatng servce nstances as close as possble to ther users. In such a context, moblty of user termnals makes such locaton decsons even more dffcult. In ths context, the Follow Me Cloud (FMC) prncple was ntroduced n [2], wheren moble users are always connected va the optmal data anchor gateway to access ts data and/or servce from the optmal DC,.e. geographcally/topogcally nearest DC. To ensure an optmal end-to-end connecton to the cloud for moble users, users Vrtual Machne (VM) (.e. servce) are mgrated between DCs, when deemed approprate[3][4]. It s worth notng that VM mgraton s seamless and transparent to users. Thus, on-gong sessons between users and servces are not nterrupted, even f users and/or servers change locaton. Besdes mprovng users QoS/QoE, FMC allows preservng operators network resources by offloadng network traffc to data centers through the nearest ponts compared wth users locatons. However, FMC control plane scalng stll remans a serous concern n current FMC mplementatons. To the best of our knowledge, the only work that has nvestgated the FMC control plane scalablty s the one by Bfulco et al. [5]. They studed the scalablty of an FMC-based system from a statc perspectve, and proposed an archtecture permttng to dstrbute the control plane on a number of FMC controllers that are statcally located n the networks. Nevertheless, the statc number and locaton of FMC controllers may not be sutable constantly because of the dynamc aspect of network load and traffc patterns over tme. To overcome these lmtatons, we propose n ths paper a novel elastc approach based on a SDN/OpenFlow archtecture and a control plane framework talored for moble cloud computng systems and more specfcally for FMC-based systems where moble nodes and network servces are subject to constrants of movements and mgratons. In contrary to centralzed approach wth sngle SDN controller, our approach permts to dstrbute the SDN/OpenFlow control plane on a two-level herarchcal archtecture: () a frst level wth a global controller, () and second level wth several local controllers deployed on-demand, where and when needed, dependng on the network dynamcs and traffc patterns. The remander of ths paper s organzed as follows. Secton II dscusses some related work. In Secton III, we present 978-1-4673-7701-0/15/$31.00 2015 IEEE 884

the system descrpton and functonng. Secton IV studes the control plane scalablty of the system. Whle the Secton V addresses the dstrbuted FMC controller operatons, the Secton VI provdes an analytcal evaluaton of the soluton wth results dscusson. The paper concludes n Secton VII. II. RELATED WORK A. The FMC concept The FMC concept was ntally proposed n [2]. It was dedcated to the case where all moblty management procedures are handled at the 3GPP doman. In [3], an analytcal model s presented to evaluate the performance of the FMC mechansm, whle n [4] a Markov-Decson Process (MDP) was ntroduced for the servce mgraton procedure. In [6], the authors proposed an mplementaton of FMC based on LISP (Local/Identfer Separaton Protocol), whereby the man goal s to render FMC ndependent from the underlyng rado access technology. Thanks to the features of LISP, both users moblty and VM mgraton are jontly managed at the same control plane. Besdes the LISP enttes, all FMC enttes were mplemented as vrtualzed network functons runnng on VMs. The results obtaned from a real-lfe testbed showed that the archtecture acheved ts man desgn goals, transferrng users servces n the order of mllseconds and wth very mnmal downtme. B. SDN Scalablty In the lterature, several research efforts have been made to tackle the SDN scalablty concerns, most of them can be classfed n three categores: data plane, control plane, and hybrd. In the frst category, DevoFlow [7] s characterzed by ts capablty to reduce the overhead by delegatng some work to the forwardng devces. Thus, t permts to reduce the control plane nvocaton for most flow setups, and reduces statstcs flows transfer. The Software-Defned Counters (SDC) [8] proposal ams to ntroduce general-purpose CPUs n forwardng devces (ASIC). The exstence of such purpose-cpus, and a fast connecton to ASIC s data plane allow to replace tradtonal counters wth a stream of rule-match records whch s transmtted to and processed n the CPU. Software-defned counters permts to reduce the control plane overhead by allowng software based mplementatons of functons for data aggregaton and compresson. The second category of efforts ams to mprove the performance of the control plane. Maestro [9] s a OpenFlow controller whch ncorporates an abstracton layer that permts to keep the smple sngle-threaded programmng model along wth explotng parallelsm, technques and desgns, permttng to mprove the performance of the OpenFlow control plane. HyperFlow [10] s another proposal amng to ncrease the OpenFlow control plane performance. HyperFlow explots the dstrbuton of control plane to provde a physcal local vew and a logcal global vew of the system. A dstrbuted fle system (WheelFS) s used to mantan and synchronze HyperFlow global vew state among dstrbuted controllers. Kandoo [11] s a dstrbuted control plane constructed of two-level herarchcal controllers. Local controllers wth no nterconnecton, whch take actons of local scope, and global controller that takes actons of global scope requrng global network vew. Among the hybrd category proposals, DIFANE [12] tres to splt the control plane between controllers and specalzed data plane swtches, called authorty swtches. The latter are responsble for nstallng rules on the remanng swtches, whle the controller focuses on generatng the needed rules by the applcatons. The utlsaton of ths approach ensures a better scale of the overall system. Addtonally, we can dstngush a specfc category of proposals that addresses the noton of elastcty n SDN controllers. Elastc approaches am to nclude dynamc adaptaton of the controllers number and ther locatons n the desgn of scalable SDN solutons. In [13] the authors propose ElastCon, an elastc dstrbuted controller archtecture whch permts dynamcally to expand or shrnk the controllers pool accordng to the network traffc load. A novel protocol of swtch mgraton s also presented permttng to shft traffc across controllers. Authors of [14] presented Pratyaastha, an elastc dstrbuted SDN control plane whch permt to effcently assgn state parttons and swtches to controller nstances, whle mnmzng both nter-controller communcaton and resources consumpton. The soluton reles on assgnment/reassgnment algorthm to adapt the system to dynamc changes, whch are modeled as an nteger lnear program (ILP) and solved va a heurstc approach. III. FMC SYSTEM DESCRIPTION AND FUNCTIONING In ths secton, we wll ntroduce our proposed soluton to cope wth the scalablty and reslency problems n centralzed control plane archtecture. The studed FMC system conssts of several PMIPv6 domans (we denote ths number by N), wheren each doman comprses two sdes: () the moble operator sde wth a set of OpenFlow-enabled devces (LMA(s)), () and the cloud provder sde wth a set of OpenFlow-enabled devces (DCG(s)). Our soluton, called Dstrbuted Follow Me Cloud Controller (DFMCC) s an elastc SDN/OpenFlow control plane archtecture based on two-level: () the frst level s represented by Global Follow-Me Cloud Controller (G-FMCC) whch s a permanent actve controller responsble of generatng, managng and nstallng OpenFlow Rules (OFRs) n order to ensure a seamless mgraton of servce on the cloud sde, whle followng nter-doman moblty of MN n the moble network sde. () the second level s represented by Local Follow-Me Cloud Controllers (L-FMCCs) whch are dynamcally provsoned and deployed when and where needed accordng to the network dynamcs n terms of MNs nter-domans mobltes, servces mgratons and traffc load. We envson deployng L- FMCC(s) on-demand usng the concept of Network Functon Vrtualzaton (NFV) whch ams at runnng network functons n vrtualzed envronments on VMs on top of vrtualzed platforms, rather than on dedcated hardware. 885

Our desgn of DFMCC s manly focused on evaluatng the scalablty n term of managed OFRs. For ths purpose, we ntroduce a new performance ndcator called the OpenFlow Rule Management Rate (OFRMRate), whch represents the number of new OFRs managed per second by the OpenFlow controller assocated to IPs addresses mgratons experenced by a doman D j. We ntroduced ths ndcator specfcally for FMC-based systems and more generally for moble cloud computng systems where moble nodes and network servces are subject to movements and mgratons. The OFRMRate s a per-doman calculated parameter (denoted by L-OFRMRate for doman D ) and t can be assocated to G-FMCC or L- FMCC (accordng to the assgnment of the doman D to G-FMCC or L-FMCC at tme t). If we defne a bnary vector Y = y 1,y 2,...,y N ndcatng whch domans are assgned to L-FMCCs (.e., y m =1)and whch domans are assgned to G-FMCC (.e., y m =0)at any tme. In ths condton, the sum over the N domans of dfferent L-OFRMRate values to gve the global ndcator (denoted by G-OFRMRate) of the overall system s as follow: G-OFRMRate = L-OFRMRate (1 y ) (1) The decson of deployng L-FMCC(s) s governed by a threshold-based system. We defne two global threshold levels: Hgh Global Threshold (H-GThr) and Low Global Threshold (L-GThr). The key objectve of our soluton s to mantan the G-OFRMRate value wthn the prespecfed threshold wndow (H-GThr, L-GThr), by deployng L-FMCC(s) when the G-OFRMRate goes over H-GThr (G-OFRMRate > H-GThr) and remove all deployed L-FMCC(s) to preserve system resources when the G-OFRMRate goes under L-GThr (G-OFRMRate < L-GThr). To acheve ths, every controller mantans a mgraton nformaton table, namely Global Mgraton Informaton Table (G-MITab) for G-FMCC and Local Mgraton Informaton Table (L-MITab) for L-FMCC. The G-MITab s a global vew, t contans nter-doman mgratons nformaton for all PMIPv6 domans whch conssts of doman d (Doman), controller d (Controller), number of OFRs (NbrOFR), lst of OFRs (LstOFR), OpenFlow rule management rate (OFRMRate), and old number of OFRs (OldNbrOFR). Whereas the L-MITab s a local vew, t contans nter-doman mgratons nformaton for local PMIPv6 doman only wth the same attrbutes as G-MITab. IV. CONTROL PLANE SCALABILITY In order to study the performances of our system, we are amng n ths secton at assessng the scalablty of our dstrbuted control plane archtecture. We wll manly focus on evaluatng the scalablty from the perspectve of managed OFRs. Lets c jk, represents the number of correspondents nodes n the cloud sde that are exchangng packets wth the -th IP address mgraton from the doman D j to the doman D k, and f j, f k represent the number of OpenFlow-enabled devces present n doman D j and D k respectvely (LMA for moble operator sde, DCG for cloud provder sde). The number of OFRs managed by the G-FMCC for the -th PMIPv6 doman1 c-prf2 DCG1 DCG2 c-prf2 DCG3 c-prf3 c-prf3 LMA1 MAG1 f2= 2 C23,1= 2 C23,2= 1 c-prf1 c-prf2 c-prf3 MN R(G) 23 =(f2+f3)(c23,1+c23,2)=12 f3= 2 C23,1= 2 G-FMCC C23,2= 1 OFR1 c-prf1 OFR1 C-prf1 c-prf3 c-prf2 PMIPv6 doman2 LMA2 m-prf1 MAG2 m-prf2 IDMD Mgraton 2 Mgraton 1 c-prf1 c-prf2 OFR1 c-prf1 OFR1 C-prf1 c-prf3 c-prf2 PMIPv6 doman3 LMA3 MAG3 m-prf1 m-prf2 MN LMA4 DCG4 PMIPv6 doman4 Fg. 1. Number of managed OFRs n MN nter-doman mgratons mgrated IP address from the doman D j to the doman D k s gven by the followng formula: R D j D k =(f j + f k )c jk, (2) The total number of OFRs managed by the G-FMCC for all IPs address mgratons from the doman D j to the doman D k s the sum over of the rules as expressed n (2): R D j D k = (f j + f k )c jk, (3) The total number of OFRs managed by the G-FMCC for all IPs address mgratons orgnated from the doman D j s: R D j D = MAG4 (f j )c jk, (4) The total number of OFRs managed by the G-FMCC for all IPs address mgratons toward the doman D j s: R D D j = (f j )c kj, (5) The total number of OFRs managed by G-FMCC for the doman D j s: R D j = R D j D + R D D j (6) ( R D j = (f j )c jk, + ) (f j )c kj, (7) The total number of OFRs managed by G-FMCC for all domans s the sum over j of the R Dj : ( R G = (f j )c jk, + ) (f j )c kj, (8) j=1 From equatons (2), (6) and (7) t s clear that the number of OFRs generated for a doman D j s drectly proportonal to: () the number of concurrent nter-doman mgratons between the doman D j and all the other domans (from doman D j to all other domans or nversely); () the number of OpenFlow-enabled devces of each doman on whch the OFRs are pushed (represented here by the f varables); () the number of correspondent nodes on the cloud sde that are exchangng packets wth each mgrated address (gven here by the c jk, varables) related to the -th IP address mgraton from 886

the doman D j to the doman D k. Due to ths characterstc, and n order to quantfy the control plane performance, we make use of our OFRMRate parameter prevously ntroduced. V. DISTRIBUTED FMC CONTROLLER OPERATIONS A. Operatons Related to Inter-doman Mgratons We pont out here the exstence of external elements whch are the Inter-Doman Moblty Database (IDMD) ensurng the regstraton of moblty nformaton of all PMIPv6 domans, and the Decson Makng Applcaton Module (DMAM) responsble for takng the decson on the relevance of servce mgraton. The detals of control operatons nteractons between the D j -FMCC and the dfferent modules foregong the servce mgraton s out-of-scop for ths paper, the nterested readers are nvted to refer to our work on centralzed FMCC archtecture [15] for further detals. The IDMD mantans a local lst of doman-to-controller mappng nformaton ndcatng at all moment whch doman s managed by whch controller. Ths lst s kept updated by the G-FMCC accordng to L-FMCC(s) deployment state. Upon recepton of nter-doman mgraton message Msg DjD k, the IDMD extracts the source doman D j of the mgraton, performs a lookup of ts current deployed controller D j -FMCC thanks to the doman-to-controller mappng lst, and relays to t the mgraton message Msg DjD k. In ts turn, the D j - FMCC actvates the DMAM n order to take decson on the relevancy of servce mgraton. If t s deemed approprate, the D j -FMCC generates then the requste OFRs n order to ensure a seamless servce mgraton from doman D j to doman D k and updates ts local table entry wth nformaton on NbrOFR, and LstOFR. Ths s acheved by nstallng the generated OFRs on all SDN-capable components of D j and D k domans. B. Operatons Related to Local Controllers Deployment In ths part we wll develop the operatons related to L-FMCC(s) deployment, we wll present the parameters used to compute our OFRMRate, then we wll ntroduce the buldng blocks algorthms of our elastc control plane framework: (1) OFRMRate Updatng Algorthm (OUA), (2) L-FMCC(s) Deployment Vector Generatng Algorthm (LDVGA) and (3) L-FMCC(s) NFV Deployment Algorthm (LNDA). 1) OFRMRate Performance Indcator Computaton: Lets Ṽ = ṽ 1, ṽ 2,...,ṽ N and V = v 1,v 2,...,v N two vectors whch represent respectvely the prevous OpenFlow rule management rate (OldOFRMRate) and the current OpenFlow rule management rate (OFRMRate) extracted from the G- MITab table of the G-FMCC. Hence, ṽ m and v m are respectvely the prevous (OldOFRMRate m ) and the current (OFRMRate m ) number of OFRs managed per second regstered for the doman D m. We assume that the OFRMRate attrbute values are updated each T Rate tme nterval for all domans n the G-MITab of the G-FMCC. The updated OFRMRate attrbute value for the D doman s gven as follows: OF RMRate = NbrOFR OldNbrOFR T Rate (9) 2) OFRMRate Updatng Algorthm (OUA): Ths algorthm s nvoked by the G-FMCC every T Rate tme nterval; t computes the updated value of OFRMRate ndcator for each doman D on the G-MITab. Thereby preparng the next step for the executon of the L-FMCC(s) Deployment Vector Generatng Algorthm; t performs the followng operatons: OFRMRate Updatng Algorthm (OUA) Input: Current deployment vector of L-FMCCs, Y Current OpenFlow rule management rate vector, V Prevous OpenFlow rule management rate vector, Ṽ Output: Updated value of OFRMRate, V, Ṽ 1: for =1to N do 2: f y =0then 3: G-MITab[D ][OFRMRate] G-MITab[D ][NbrOFR] G-MITab[D ][OldNbrOF R] T Rate 4: v = G-MITab[D ][OFRMRate] 5: G-MITab[D ][OldNbrOFR] G-MITab[D ][NbrOFR] 6: ṽ = G-MITab[D ][OldNbrOFR] 7: end f 8: repeat 3) L-FMCC(s) Deployment Vector Generatng Algorthm (LDVGA): Ths algorthm s nvoked by the G-FMCC every T deployment tme nterval (note that T deployment > T Rate ), on the bass of the updated OFRMRate ndcator value for each doman D ; t generates a canddate deployment vector Ỹ = ỹ 1, ỹ 2,...,ỹ N of L-FMCC(s) destned to replace the current deployment vector Y = y 1,y 2,...,y N. Ths algorthm prepares the NFV deployment of L-FMCC(s) step accomplshed by L-FMCC(s) NFV Deployment Algorthm, and t performs the followng operatons: L-FMCC(s) Deployment Vector Generatng Algorthm (LDVGA) Input: Current OpenFlow rule management rate vector, V Current deployment vector of L-FMCCs, Y Output: Canddate deployment vector of L-FMCCs, Ỹ 1: V V, wth v m sorted n descendng order 2: Y Y, wth y m sorted n the same ndex order as v m 3: ψ v (1 y ), the G-OFRMRate =1 4: f ψ>h-gthr then 5: ψ ψ 6: for =1to N do 7: f y =0then 8: ψ ψ v 9: y 1 10: end f 11: f ψ H-GThr or = N then 12: break 13: end f 14: repeat 15: end f 16: f ψ<l-gthr then 17: ψ ψ 18: for =1to N do 19: f y N +1 =1then 20: ψ ψ + v N +1 21: y N +1 0 22: end f 23: f ψ L-GThr or = N then 24: break 25: end f 26: repeat 27: end f 28: Ỹ Y, wth y m sorted n the same ndex order as ym 4) L-FMCC(s) NFV Deployment Algorthm (LNDA): Ths algorthm s trggered by the L-FMCC(s) Deployment Vector Generatng Algorthm, markng the end of ts executon. It s 887

launched by the NFV module of the G-FMCC, based on the current deployment vector Y and the canddate deployment vector Ỹ. It permts to deploy/remove L-FMCC(s) n order to adapt the overall system load. The algorthm performs the followng operatons: L-FMCC(s) NFV Deployment Algorthm (LNDA) Input: Output: Current deployment vector of L-FMCCs, Y Canddate deployment vector of L-FMCCs, Ỹ New deployment vector of L-FMCCs, Y 1: for =1to N do 2: f y =0and ỹ =1then 3: Deployment of L-FMCC n the doman D wth NFV 4: G-MITab[D ][Controller] L-FMCC 5: IDMD doman-to-controller lst[d ] L-FMCC 6: Transfer of context: L-MITab[D ] G-MITab[D ] 7: end f 8: f y =1and ỹ =0then 9: Removal of L-FMCC n the doman D wth NFV 10: L-MITab[D ][Controller] G-FMCC 11: IDMD doman-to-controller lst[d ] G-FMCC 12: Transfer of context: G-MITab[D ] L-MITab[D ] 13: end f 14: repeat 15: Y Ỹ, canddate vector becomes the current deployment vector VI. EVALUATION To evaluate the performance of our DFMCC, a theoretcal analyss s performed. Regardng the scalablty of the system and to evaluate the total number of managed rules we manly focus on the formulas gven n (7) and (8). A. Non-Homogeneous Posson Process Model for Interdoman Mgratons Arrvals In our evaluaton the nter-doman mgratons arrvals for a gven t from doman D j to doman D k (noted N DjD k (t)) are assumed to follow Non-Homogeneous Posson Process wth rate parameter functon λ jk (t);.e., {P (N D j D k (t) =R) =e Λ jk(t) (Λ jk(t)) R, t 0 R! Λ jk (t) = t 0 λ (10) jk(s)ds We wll consder three dfferent scenaros, each scenaro s run for 30 mnutes wth the L-FMCC(s) Deployment Vector Generatng Algorthm (LDVGA) runnng every 4 mnutes (T deployment =4mn). The choce of the latter depends on the current state of the DFMCC system, and can be further tuned through a more detaled analyss. Three scenaros were consdered: (1) The growng phase n whch the nter-doman mgratons arrvals are assumed to ncrease; (2) The constant phase wth nter-doman mgratons arrvals assumed to be constant; (3) The decayng phase n whch the nter-doman mgratons arrvals are assumed to decrease. In order to meet the condtons of ths three scenaros, the rate parameter functon λ jk (t) from doman D j to doman D k s assumed to be gven by: λ jk (t) = t 5(j+1), 360 (j+1), f 0 t 30mn f 30mn t 60mn 360 (j+1)(1+ 100 t, f 60mn t 90mn ) Where t s tme and j s the ndex of the source doman D j. The expected number of nter-doman mgraton arrvals M DjD k (t) from doman D j to doman D k s gven by: M D j D k (t) =E[N D j D k (t)] = Λ jk (t) (11) As a result, M D j D k (t) = t 2 10(j+1), 360t (j+1), 36000 (j+1) log(1 + f 0 t 30mn f 30mn t 60mn t ), f 60mn t 90mn 100 The reference nter-doman mgratons scheme s represented n Fgure 2, and throughout our evaluaton, we wll consder the followng constant parameter: (N =6), (, j, k, c jk, = c), ( j, f j = f). Regardng the precedng crtera and the 23(t) DCG2 LMA3 2 L-FMCC2 L-FMCC3 3 12(t) LMA2 DCG3 34(t) IDMD DCG1 LMA4 1 L-FMCC1 4 LMA1 DCG4 G-FMCC 61(t) Hypervsor5 DCG5 DCG6 Hypervsor6 45(t) L-FMCC6 L-FMCC5 LMA5 6 LMA6 Hypervsor1 Hypervsor2 Hypervsor3 Hypervsor4 L-FMCC4 Fg. 2. Network topology of DFMCC archtecture formulas gven n (7) and (8), we wll obtan the equatons summarzed n Table I: TABLE I THE EQUATIONS TO CALCULATE OFRMRATE, #MIGRATIONS, #RULES Parameter Doman D j All domans OFRMRate L-OFRMRate j(t)=2fc λ jk (t) G-OFRMRate(t)=2fc λ jk (t) #Mgratons M D j (t) = Λ jk (t) M G (t) = j=1 #Rules R D j (t) =2fc M D j (t) R G (t) =2fc M G (t) 5 56(t) j=1 Λ jk (t) B. scenaro 1: OFRMRate ncreasng phase Fgure 3(a) plots the G-OFRMRate(t) assocated to G-FMCC and the L-OFRMRate (t) assocated to L-FMCC of doman D when ths latter s actvated. The applcaton of our elastc control plane framework permts to offload the G-FMCC when the G-OFRMRate(t) goes over the G-HThr by the L-FMCC(s) NFV deployment for most loaded doman(s). The Fgure 4(a) plots a comparson of the global number of rules managed by G-FMCC under the applcaton of our elastc control plane framework, and the case wth a sngle centralzed FMCC. We can see that G-FMCC becomes less loaded then the centralzed FMCC when G-HThr s reached. C. scenaro 2: OFRMRate statonary phase In Fgure 3(b) we can see that the applcaton of our soluton ensures to have G-OFRMRate(t) under G-HThr, and as ths phase s statonary only the frst nvocaton of our LDVGA and LNDA algorthms (the frst T deployment ) s needed to deploy the suffcent number of L-FMCC(s) ensurng a G- OFRMRate(t) under G-HThr for the entre phase duraton. 888

As we can see also n the Fgure 4(b) there s only the frst executon of our algorthms (the frst T deployment ) that permts to reduce the number of OFRs managed by G-FMCC. We can clearly dstngush dfferences n term of number of managed rules and the advantage provded by our soluton. D. scenaro 3: OFRMRate decreasng phase Fgure 3(c) plots the G-OFRMRate(t) assocated to G-FMCC and L-OFRMRate (t) assocated to L-FMCC of doman D when the latter s actvated. We can see that the applcaton of our elastc approach permts ths tme to load G-FMCC when G-OFRMRate(t) goes under G-LThr, by the L-FMCC(s) NFV removng of less loaded doman(s) and ther assgnment to the G-FMCC. The Fgure 4(c) plots a comparson of global number of rules managed by the G-FMCC under the applcaton of our elastc control plane framework, and the case wth centralzed FMCC. We can observe clearly that our soluton permts to preserve resources when G-LThr s reached, by deactvatng L-FMCC(s) and approachng thus the case of centralzed FMCC archtecture. Fg. 3. OFRMRate parameter adaptaton between G-HThr and G-LThr Fg. 4. Number of rules managed by G-FMCC and centralzed FMCC E. Network delay In ths secton we wll analyse the delay of our approach n terms of the number of d r exchanged messages. The d r s a regonal long dstance message, whch s exchanged between two dfferent domans. Accordngly, ths knd of message experences hgh delay compared wth the d l message, as the latter s a local short dstance message. The Fgure 5 compares the number of d r exchanged messages n the case of G-FMCC under the applcaton of our elastc control plane framework, and the case wth centralzed FMCC. We can dstnctly observe that the our dstrbuted archtecture DFMCC represented here by the G-FMCC (the most loaded controller) performs better delay performance, and consequently, a faster handlng of rules nstallaton n comparson wth centralzed FMCC archtecture n the three phases. Fg. 5. Number of d r messages processed by the system VII. CONCLUSION In ths paper, we have proposed our desgn of an elastc dstrbuted SDN controller talored for moble cloud computng and FMC-based systems. We presented the buldng blocks of our control plane framework: the performance ndcator OFRMRate and the three algorthms (OUA, LDVGA and LNDA). The evaluaton results obtaned va analyss show that our soluton ensures better control plane management, performances mantanng and network resources preservaton. REFERENCES [1] X. Wang, M. Chen, T. Taleb, A. Ksentn, and V.C.M. Leung, Cache n the ar: explotng content cachng and delvery technques for 5G systems, n IEEE Com. Mag., Vol. 52, No. 2, Feb. 2014. pp.131-139 [2] T. Taleb, A. Ksentn, Follow me cloud: nterworkng federated clouds and dstrbuted moble networks, IEEE Network 27(5): 12-19 (2013) [3] T. Taleb and A. Ksentn, An analytcal Model for Follow Me Cloud, n Proc of Globecom 2013, Atlanta, USA, Dec. 2013. [4] A. Ksentn, T. Taleb, and M. Chen, A Markov Decson Process-based Servce Mgraton Procedure for Follow Me Cloud, n Proc. IEEE ICC 2014, Sydney, Australa, Jun. 2014. [5] R. Bfulco, M. Brunner, R. Canonco, P. Hasselmeyer, and F. Mr, Scalablty of a Moble Cloud Management System, n Proc. of SIGCOMM workshop on Moble Cloud Computng (MCC 2012), 2012. [6] A. Ksentn, T. Taleb, M. Farouk, A LISP-Based Implementaton of Follow Me Cloud, IEEE Access 2: 1340-1347 (2014) [7] A. R. Curts, J. C. Mogul, J. Tourrlhes, P. Yalagandula, P. Sharma, and S. Banerjee, DevoFlow: scalng flow management for hghperformance networks, Comput. Commun. Rev., vol.41, no.4, pp.254 265, Aug. 2011. [8] J. C. Mogul and P. Congdon, Hey, you darned counters!: Get off my asc! n Proceedngs of the Frst Workshop on Hot Topcs n Software Defned Networks, NY, USA: ACM, 2012, pp. 25 30. [9] Z. Ca, A. L. Cox, and T. S. E. Ng, Maestro: A System for Scalable OpenFlow Control, Rce Unversty, Tech. Rep., 2011. [10] A. Tootoonchan and Y. Ganjal, HyperFlow: a dstrbuted control plane for OpenFlow, n Proceedngs of the 2010 nternet network management conference on Research on enterprse networkng, Berkeley, CA, USA: USENIX Assocaton, 2010, pp. 3 3. [11] S. Hassas Yeganeh and Y. Ganjal, Kandoo: A framework for effcent and scalable offloadng of control applcatons, n Proceedngs of the Frst Workshop on Hot Topcs n Software Defned Networks, NY, USA: ACM, 2012, pp. 19 24. [12] M. Yu, J. Rexford, M. J. Freedman, and J. Wang, Scalable flow-based networkng wth dfane, SIGCOMM Comput.Commun.Rev., vol.41, no.4, Aug.2010. [13] A. Dxt, F. Hao, S. Mukherjee, T. Lakshman, and R. Kompella, Towards an elastc dstrbuted SDN controller, n Proceedngs of the second ACM SIGCOMM workshop on Hot topcs n software defned networkng, NY, USA: ACM, 2013, pp. 7 12. [14] A. Krshnamurthy, S. P. Chandrabose, and A. Gember-Jacobson, Pratyaastha: An effcent elastc dstrbuted SDN control plane, n Proceedngs of the Thrd Workshop on Hot Topcs n Software Defned Networkng, NY, USA: ACM, 2014, pp. 133 138. [15] A. Assou, A. Ksentn, A. Guerou PMIPv6-based Follow-Me Cloud (accepted for publcaton n Globecom 2015) 889