1 Scalability of a Mobile Cloud Management System Roberto Bifulco* Marcus Brunner** Roberto Canonico* Peer Hasselmeyer** Faisal Mir** * Università di Napoli “Federico II” ** NEC Laboratories Europe

2 ▐ Mobile devices: Laptops, tablets, smartphones, etc. ▐ Advanced services: E.g., rich media applications, devices extended in the cloud with storage/computational resources ▐Cloud Computing for service provisioning Mobile devices and Cloud Computing

3 Scenario ▐ Several Cloud-enabled datacenters at the edges of the network

4

5 Follow-Me Cloud (FMC) ▐ FMC provides transparent network addresses mobility End-points are unaware of FMC Ongoing connections are maintained upon addresses migrations ▐ If the migration involves a UE, FMC provides a mean to eventually perform live migrations of services (VMs) related to the migrated user

6 ▐FMC uses OpenFlow switches in the network but.. ▐...OpenFlow switches are assumed to be only at the edge of the network (i.e., the network core is unaware of FMC) Follow-Me Cloud and OpenFlow

7 OpenFlow architecture

8 How it works A A B B IPa

9 How it works A A B B IPa IPb IPa

10 How it works Identifier Locator

11 Page 11 Scalability in an OpenFlow network OpenFlow switches are programmed by means of rules: each rule generation requires some processing time and network state ▐Data plane: The number of rules that can be installed on a device is limited; Limited flexibility; Hard constraint to network solutions development; ▐Control plane: The number of rules managed by a single controller can be huge! Limited performance (In terms of processed rules per second); Limited reactivity to network events;

12 Page 12 Scalability in an OpenFlow network OpenFlow switches are programmed by means of rules: each rule generation requires some processing time and network state ▐Data plane: The number of rules that can be installed on a device is limited; Limited flexibility; Hard constraint to network solutions development; ▐Control plane: The number of rules managed by a single controller can be huge! Limited performance (In terms of processed rules per second); Limited reactivity to network events;

13 Page 13 Data plane: scale out solution ▐Support data plane by adding more switches; e.g., reducing the dimension of access networks (hence, increasing their number) ▐Switch composition Hierarchical; P2P-like; … ▐But: more workload on the control-plane because of the increased number of switches to be managed.

14 Page 14 Control Plane issues ▐Total number of managed rules; ▐Controller response time; Depends from many factors, e.g., controller load but also network latency; Network latency between controller and OF-switches does matter!!

15 Page 15 Network latency ▐Flow setup is influenced by network latency between controller and switch; At least 2 RTTs are needed (first packet forwarded to the controller (i), rule set up (ii)); ▐Assume 40ms RTT between a switch and a far controller (e.g., a centralized controller managing a geographical telco network) ▐Each flow installation is delayed of at least 80ms;

16 Page 16 Problems ▐Application to large networks raises scalability issues: High number of end-points/migrations Higher delays between switches and controller “Long distance” signalling (openflow) traffic Increased network state (id/loc mappings)

17 Page 17 Solution ▐Distributed Follow-Me Cloud controller, to handle large amounts of mobility events. Enables scale-up to large networks with many migrating entities; Optimized controller-switches communications due to localized decisions; ▐Design principles: Distribute only the needed knowledge, where it is actually needed; Keep decisions local, if possible.

18 Page 18 Design principles

19 Page 19 Design principles

20 Page 20 Architecture overview ▐A controller plays one or more roles: Home Controller, Foreign Controller, Correspondent Controller ▐Controller's role is defined in respect to the MN perspective; The controller of the first network on which the MN appears assumes the role of Home Controller for that MN; ▐Home Controller is in charge of: Managing all the network state related to the MN; Orchestrating controllers involved in IP address migrations for the MN;

21 Page 21 Distributed algorithm: HC-FC interaction ▐HC: informs FC providing MN information (e.g., the identifier address) and obtaining the locator address; set up HS with OpenFlow rules to rewrite packet source/destination with the appropriate identifier or locator address; ▐FC: generates a new locator address; set up FS with OpenFlow rules to rewrite packet source/destination with the appropriate identifier or locator address

22 A A B B IPa HC C ID/LOC IPb IPa Distributed algorithm: CC update (1) IPa IPb IPa

23 Page 23 Distributed algorithm: CC update (2)

24 Page 24 Advantages ▐Number of managed OF rules per controller; ▐Number of “long distance” signalling messages. One migration case, when the number of nodes from HN, FN and the number of CNets, exchanging packets with MN, increase linearly.

25 Conclusion ▐FMC provides transparent mobility to users and services splitting the network identifier and locator concepts ▐The system is able to scale up to large networks by adding more controllers node Future work ▐ Optimization of local mobility and handover delay ▐ Extend services migration logic: Design of services migration triggers and allocation algorithms Evaluation of tiny-VM based services migration ▐ Network-wide load balancing functions ▐ Mobile data offloading (seamless multi-homing) ▐ Extension to NATted end-points

26