flown vs flowvisor: scalable network virtualization in sdn
TRANSCRIPT
Scalable Network Virtualization in Software-Defined Networks
Hao JIANG advisor: Prof. Ahmed Bouabdallah
Authors:
Design
2
Agenda
• Introduction to SDN Virtualization• Related Work• Problems to be Solved: Flexibility, Efficiency &
Scalability• Motivation• FlowN: a General Approach• Container-Based Virtualization• Database-Driven Mappings• A Experiment with FlowN Prototype• Evaluation• Conclusion
Problem Statement FlowN Overview EvaluationIntroduction Conclusion
- What?
- Why?- How?
3
What is network virtualization?
Ability to run multiple virtual networks (VNs) that:• Coexist together on top of a common shared infrastructure• Each has logically separate control and data planes• Can be managed by individual parties that potentially don’t trust each other
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Source: Cisco Network Virtualization, www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html
4
SDN simplified virtualization
With centralized control plane decoupled from forwarding devices, SDN enables:
• Virtualization by controller withoutneed to support it on every switch;
• Network abstractions where virtualtopologies are decoupled from thephysical infrastructure;
• Each tenant to specify control logicand design its own topology for its own needs.
Tenant 1 Tenant 2 Tenant 3
Network Infrastructure
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
5
Related work in network virtualization
Isolation between VNs:• Control isolation: a tenant should not be able to affect other’s but its own network;• Data isolation: the traffic of a tenant should completely be isolated from other’s;• Address space isolation: a tenant should have full address space without affecting
others;
Slice: a portion of traffic and a subset of physical network defined by any combination of switch ports (layer 1), MAC address (layer 2), IP address (layer 3), TCP/UDP port (layer 4) according to slicing policy for each tenant.
Mapping between the virtual and physical networks:• Node mapping: deciding which switch maps a virtual node;• Link mapping: deciding which path (one or more physical links) maps a virtual link;• Interface mapping
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
6
Current solution for SDN virtualization
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Source: Tran Song Dat Phuc – Uyanga, Presentation, Mapping Techniques for SDN, SeoulTech 2014
FlowVisor is a special purpose controller that:• acts as a transparent proxy between OpenFlow switches and multiple tenant
controllers• creates network slices and delegates the control of each slice to different controllers
Isolation in data plane:• Slicing data plane resources• One slice per controller
Mapping lookup software:• Custom code• In-memory data structure
Mapping OpenFlow messages
7
Application of virtualization
GENI (Global Environment for Network Innovation) Testbed
• shared network infrastructure• SDN/OpenFlow architecture• FlowVisor virtualization
– Multiple concurrent experiments– One slice for each experiment– Isolation between experiments– Experimenter can only use and
control it own slice
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Source: GENI Resource Map, http://groups.geni.net/geni
8
Performance issues with virtualization in the context of SDN
Flexibility* • Flowvisor’s virtual network is restricted to subsets of physical topology and
address space;
Efficiency• Interactions with separate controllers incurs additional overhead and latency;
Scalability• As VNs get bigger and the number VNs increases, running mapping software
with in-memory data structure and custom code becomes a limiting factor in scalability.
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
* Source: Sherwood, R., et al. "FlowVisor: A Network Virtualization Layer(OPENFLOW-TR-2009-1)." (2012).
9
Design goals
Flexibility:• Full virtualization: Virtual network is decoupled from physical topology-
hidden failover;• Full isolation: Control Logic, Data Traffic, Address Space, Performance;
Efficiency: Small latency increase and resource consumption incurred by virtualization layer;
Scalability: a scalable way to support large number of VNs and physical resources
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
10
Key design decisions
Flexibility & efficiency• Container-based virtualization: to lower resource consumption and isolate
control logic• Encapsulation(VLAN)-based isolation: data traffic and address space isolation
Scalability• Database-driven mappings: Modern Database Technology• Caching to improve performance
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
11
FlowN architecture
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Source: Ranjbar, Alireza. "Domain Isolation in a Multi-Tenant Software-Defined Network." (2015).
12
Database-driven mappings
Virtual network specification• Nodes• Interfaces• Links: A link connects one interface on one node to another interface on
another node
Embedding virtual networks to available physical resources• Arbitrary embedding algorithm decided by administrator;
Mapping • Virtual node physical node• Virtual link a path with one or a set of physical links
Caching can be utilized to optimize for mappings that frequently occur.
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Virtual
Physical
13
Database-driven mappings
Node assignment table• mapping each virtual node to one physical node
Path assignment table• mapping each virtual link to a set of physical links, each with a hop count
number that increases in the direction of the path
Mapping of a packet received event a simple matter of issuing an SQL query
• translate VLAN tag, switch id and port to corresponding virtual tenant, switch and port:
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
14
Container-based virtualization
Tenants run their controller applications in LXC containers and communicate the controller by mapping API calls back and forth (unlike FlowVisor by sending OpenFlow Messages).
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
15
Experiment
Prototype• Modified python NOX 1.0 controller• MySQL database using InnoDB engine• VLAN tags used for encapsulation• 4000ish lines of code in total• Chowdhury’s embedding algorithm*: high remaining capacity short path
Comparison below with FlowN (with/without caching)• FlowVisor: to evaluate scalability and efficiency• Unvirtualized NOX: to determine the overhead of the virtualization layer
Test• Modified cbench to generate packets with correct encapsulation tags and a
unique MAC;• Measure the latency by measuring the time between a packet-in event and a
response received by cbench.
*N. Chowdhury, M. Rahman, and R. Boutaba,“Virtual network embedding with coordinated node and link mapping,” in IEEE INFOCOM, pp. 783–791, April 2009.
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
16
Experiment
Evaluation
• Slower latency increase• Higher latency for less VNs• Lower latency for more VNs• Overall increase in latencyincurred by virtualizationremains less than 0.2 mswith caching
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
17
Conclusion
Flexibility & efficiency• Container-based virtualization: to lower resource consumption and isolate
control logic;• Encapsulation(VLAN)-based isolation: data traffic and address space isolation.
Scalability• Database-driven mappings: Modern Database Technology• Caching to improve performance
Future work• OpenFlow 1.3 to enable bandwidth guarantee;• Virtualization layer and mapping database replication for multiple controller
coordination;• Devise different embedding algorithms for tenants to specify based on some
constraints.
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
18
Some personal comments
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Scalability proof of concept•Number of VNs ✓✓ •Scale of a VN ✕✕•Scale of physical infrastructure (eg. a large-scale network / with multiple controllers) ✕✕•Latency ✓ ✓ (not efficient in small scale network compared with FlowVisor)•Error rate ✕✕•VLAN tag: scalability limit of 4096 number of tenants ??
Comparison FlowVisor FlowNvirtual-physical
InteractionOpenFlow message
API call
Control Plane Isolation Separate controllers
Container-based virtualization
Data Plane Isolation Slicing EncapsulationAddress Space Restricted Full
Mapping Lookup Custom software Database (SQL query)Virtualization Level Data plane
(slicing)Control/ data plane(VLAN)
19
Thank you !
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
20
Embedder performs a LP relaxation of a mixed integer problem, where the goal is to figure out the optimal assignments that minimizes an objective function which assigns weights to each node assignment or link assignment based on the capacities consumed compared to the remaining capacities on the links and nodes. Such an assignment will prefer links and nodes with high remaining capacity over low, and otherwise would attempt to place adjacent virtual nodes as close as possible, and have virtual links traverse short paths in the physical network.
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Chowdhury’s embedding algorithm
21
Multiple slave servers are then used to replicate the state across multiple servers:
In this case, we can set up a master database server that would get any of the updates, which are done in case of topology changes, admitting new virtual networks or network element failure, none of which are expected to occur frequently during normal operation. Multiple slave servers can be used to replicate the state. This would help more so if the size of the physical network demands multiple virtualization controllers for the OpenFlow network, as each could maintain it’s own database copy locally. Since mappings are done on a per-switch basis, each physical OpenFlow switch can thus talk to it’s own OpenFlow controller and the database will handle consistent network state across all such controllers.
DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
Replication of Database