All Rights Reserved © Alcatel-Lucent 2009 Enhancing Dynamic Cloud-based Services using Network Virtualization F. Hao, T.V. Lakshman, Sarit Mukherjee, H.

All Rights Reserved © Alcatel-Lucent 2009

Enhancing Dynamic Cloud-based

Services

using Network Virtualization

F. Hao, T.V. Lakshman, Sarit Mukherjee, H. Song

Bell Labs

All Rights Reserved © Alcatel-Lucent 2009 2

Dynamic Cloud-based Services: An Example

VM

VM

Data Center 1

Data Center 2

Data Center 3

Users will leverage cloud computing services to “outsource” their computing needs Thin client/Virtual desktop Proxy for handheld devices

Cloud Service Providers will Create a VM for the service Allocate VM closest to user

User attaches to cloud to get service

Cloud service provider creates VM to serve user


Dynamic Cloud-based Services: An Example

VM

As the user population for a service changes, the best location for the VM changes

Cloud Service Providers should Migrate the VM to the new location closest to the user VM migration over a LAN is supported by

most virtualization software Data Center 1

Data Center 2

Data Center 3

User attaches to cloud from a different location

VM should be moved to Data Center 2

Migrate VM across WAN in an efficient manner without losing service continuity

VM


Benefits of migration of VM across multiple networks/data centers

For Cloud Service Provider Service migration across data centers Load balancing within and across data centers Performance optimization Green computing

For Cloud Users Faster access Efficient data delivery


All traffic anchored at home agent

Triangular routing increase delay and burdens the network

Fine for end user device with low traffic volume, but not for servers

MIPv6 requires correspondent nodes to support MIP Transition from IPv4 to IPv6?? End users will be mixture of

IPv4 and IPv6 clients

Why Mobile IP is not a good solution

VM 1

HA

All traffic goes through the anchor point

User 1

VM 2

User 2


All traffic anchored at home agent

Triangular routing increase delay and burdens the network

Fine for end user device with low traffic volume, but not for servers

MIPv6 requires correspondent nodes to support MIP Transition from IPv4 to IPv6?? End users will be mixture of

IPv4 and IPv6 clients

Why Mobile IP is not a good solution

VM 2

VM 1

HA

All traffic goes through the anchor point

User 1

User 2


Our Approach: Virtually Clustered Open Router (VICTOR)

Traditional virtualization approach Slice and isolate resources in a physical router Each slice acts as a different router

Virtually Clustered Open Router (VICTOR) Logically combine multiple physical devices to form a virtual

router A physical device mimics a virtual line card with multiple virtual

ports Virtual line cards are interconnected to mimic a virtual backplane

Dedicated facilities (e.g.,for data centers of a cloud service provider) MPLS bandwidth-guaranteed paths Tunnels through the public Internet

Virtual router with distributed forwarding elements managed by logically centralized controller Similar in concept to [SoftRouter/Openflow/RCP/4D]


VICTOR Architecture

FE1

FE5

FE3

FE2

CC

VICTOR

VM

FE4

VM

VM2

VM

VM1

Client

FE is the first layer-3 access and aggregation point for mobile VM

Forwarding Element (FE) Handles all data plane functions Sets up a virtual backplane

between each other as necessary

Can be distributed across WAN A data forwarding device or a

VICTOR enabled router

Centralized Controller (CC) Controls routing and signaling

for mobile VM IP prefixes Computes and installs

forwarding table for each FE

Acts as a loosely coupled router with FEs as line cards, and CCs as control plane


Routing in VICTOR

External Routing Each FE advertises all the mobile VM addresses that VICTOR handles FE or CC calculates and maintains the best routes to the external IP

addresses FE does not announce FE-FE links to external routers

packets for non-mobile VMs are not routed by VICTOR

Internal Routing An active VM discovers an adjacent FE and registers itself with it The FE forwards the binding to the CC The CC authenticates the binding and configures all the other FEs with the

binding Only one active binding for each VM is allowed at a time Binding changes when the VM moves to another FE Each FE maintains a forwarding table

local bindings for locally registered VMs foreign bindings for remotely registered VMs


Packet Forwarding in VICTOR

VM 2

VM 1

External Packet Forwarding FE receives a packet destined to

an external IP address Packet is directly sent out by

looking up external forwarding table

Internal Packet Forwarding FE receives a packet destined to a

VM Tunnel header, if any, is stripped

off Packets for VM with local binding

are directly forwarded Packets for VM with foreign binding

are forwarded to the current FE Packet discarded if no binding is

found


VM Migration across Data Centers

1) VM sends an ARP

2) Local FE receives the ARP and sends the message to CC

3) CC installs new routing entry in local FE for the VM

4) CC installs new routing entry in the old FE

VM

VM

1

2

3

4Data Center 1

Data Center 2

Data Center 3

Old location

New location

Mobile VMs must have IP addresses that do not conflict with any other hosts in the cloud

VMs with destination NAT-ed addresses are moved by allocating non-conflicting private addresses to the mobile VMs

VM migration within a data center is similar in principle but simpler


Experimental Prototype of VICTOR

Prototype based on Linux (FC 9) All FEs are controlled by CC FE2 and FE3 have 4-port NetFPGA GbE card Developed new Openflow controller to support

Mobile node registration Layer 3 routing

VM Migration VM migrated from Server1 to Server2

Ping VM from Server3 at 0.01 sec interval Packet loss = 350 3.5 sec connectivity interruption Same downtime over LAN migration negligible

overhead

Physical Host Migration Mobile PC changed attachment from AP1 to AP2

Ping mobile PC from Server3 at 0.01 sec interval Packet loss = 1—2 0.01—0.02 sec connectivity

interruption

Forwarding Table at FE2

Flow Action

nw_dst=10.2.3.1 mod_dl_dst,out:2

nw_dst=10.10.0.11

mod_dl_dst,out:2

nw_dst=10.10.0.36

mod_dl_dst,out:3

nw_dst=10.4.5.1 out:0

nw_dst=10.6.7.1 out:1

0 2

1

0 0

1

2 2

Server1 Server2

10.2.3.1 10.4.5.1

3 3

FE1

FE3FE2

AP2AP1

Mobile PC

10.10.0.36

Controller

VM10.10.0.11

Server3

10.6.7.1

1

4-portNetFPGA


Conclusion

Enabling wide-area VM mobility in an efficient manner is of significant value to many cloud-based applications

Proposed solution based on distributed forwarding and centralized control More efficient data forwarding and more flexible control unlike mobile IP

solution Triangular routing is significantly reduced No modification to virtualization software or TCP/IP stack is needed No new requirement on correspondent node Connectivity is not affected during and after migration

Several open issues remain for future research Use of this architecture for enabling new applications Simplifying implementation of current features

All Rights Reserved © Alcatel-Lucent 2009 Enhancing Dynamic Cloud-based Services using Network Virtualization F. Hao, T.V. Lakshman, Sarit Mukherjee, H.

Documents

victor vm

vm closest

active vm

user vm migration

example vm data center

service continuity vm

user user

user slide