Scalability of a Mobile Cloud Management System

1. Scalabilityof a Mobile Cloud Management System * Università di Napoli “Federico II” ** NEC LaboratoriesEurope Roberto Bifulco* Marcus Brunner** Roberto Canonico* Peer Hasselmeyer** Faisal Mir**

2. Mobile devices and Cloud Computing • 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

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

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. Follow-Me Cloud and OpenFlow • FMC uses OpenFlowswitches 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)

7. OpenFlow architecture

8. How it works IPa A B

9. How it works IPa IPb A IPa B

10. How it works Identifier Locator

11. Scalability in an OpenFlow network OpenFlowswitches 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. Scalability in an OpenFlow network • OpenFlowswitches 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. Data plane: scale out solution Support data plane by adding more switches; e.g., reducing the dimension of accessnetworks (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. Control Plane issues Total number of managedrules; Controller responsetime; Depends from many factors, e.g., controller load but also network latency; Network latency between controller and OF-switches does matter!!

15. Network latency Flow setup is influenced by networklatency between controller and switch; At least 2RTTs 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 telconetwork) Each flow installation is delayed of at least 80ms;

16. Problems Application to largenetworks raises scalability issues: Highnumber of end-points/migrations Higher delays between switches and controller “Long distance” signalling (openflow) traffic Increased networkstate (id/loc mappings)

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. Design principles

19. Design principles

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 networkstaterelatedto the MN; Orchestrating controllers involved in IP address migrations for the MN;

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 OpenFlowrules to rewrite packet source/destination with the appropriate identifier or locator address; • FC: • generates a new locator address; • set up FS with OpenFlowrules to rewrite packet source/destination with the appropriate identifier or locator address

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

23. Distributed algorithm: CC update (2)

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 Future work • 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 • 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