Transcript Diapositiva 1 - Roberto Bifulco

Scalability of a
Mobile Cloud Management System
Roberto Bifulco*
* Università di Napoli “Federico II”
Marcus Brunner**
Roberto Canonico*
Peer Hasselmeyer**
** NEC Laboratories Europe
Faisal Mir**
1
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
2
Scenario
▐ Several Cloud-enabled datacenters at the edges of the network
3
4
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
5
Follow-Me Cloud and OpenFlow
▐ 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)
6
OpenFlow architecture
7
How it works
IPa
A
B
8
How it works
IPa
IPb
A
IPa
B
9
How it works
Identifier
Locator
10
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;
Page 11
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;
Page 12
12
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.
Page 13
13
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!!
Page 14
14
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;
Page 15
15
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)
Page 16
16
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.
Page 17
17
Design principles
Page 18
18
Design principles
Page 19
19
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;
Page 20
20
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;
Page 21
▐ FC:
 generates a new locator address;
 set up FS with OpenFlow rules to
rewrite packet source/destination with
the appropriate identifier or locator
address
21
Distributed algorithm: CC update (1)
IPa
IPb
CC
ID/LOC
HC
IPb
A
IPa
IPa
B
22
Distributed algorithm: CC update (2)
Page 23
23
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.
Page 24
24
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
25
26