FlowN vs FlowVisor: Scalable Network Virtualization in SDN
Download as PPT, PDF3 likes1,179 views
This document proposes FlowN, a scalable software-defined network virtualization approach. FlowN uses container-based virtualization to isolate tenant control logic and encapsulation to isolate tenant traffic and address spaces. FlowN maps virtual networks to physical infrastructure using a database for flexibility and scalability. The database stores node and path mappings and lookups are done through SQL queries. An experiment shows FlowN has lower latency increases than FlowVisor as the number of virtual networks increases, demonstrating improved scalability.
FlowN vs FlowVisor: Scalable Network Virtualization in SDN
- 1. Scalable Network Virtualization in Software-Defined Networks Hao JIANG advisor: Prof. Ahmed Bouabdallah Autho rs:
- 2. 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. 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. 4 SDN simplified virtualization With centralized control plane decoupled from forwarding devices, SDN enables: • Virtualization by controller without need to support it on every switch; • Network abstractions where virtual topologies are decoupled from the physical infrastructure; • Each tenant to specify control logic and design its own topology for its own needs. Tenant 1Tenant 1 Tenant 2Tenant 2 Tenant 3Tenant 3 Network Infrastructure DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
- 5. 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. 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. 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. 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. 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. 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. 11 FlowN architecture DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion Source: Ranjbar, Alireza. "Domain Isolation in a Multi-Tenant Software-Defined Network." (2015).
- 12. 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. 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. 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. 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. 16 Experiment Evaluation • Slower latency increase • Higher latency for less VNs • Lower latency for more VNs • Overall increase in latency incurred by virtualization remains less than 0.2 ms with caching DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
- 17. 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. 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 FlowN virtual-physical Interaction OpenFlow message API call Control Plane Isolation Separate controllers Container-based virtualization Data Plane Isolation Slicing Encapsulation Address Space Restricted Full Mapping Lookup Custom software Database (SQL query) Virtualization Level Data plane (slicing) Control/ data plane(VLAN)
- 19. 19 Thank you ! DesignProblem Statement FlowN Overview EvaluationIntroduction Conclusion
- 20. 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. 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
Editor's Notes
- #2: http://mephisto.blogbus.com/logs/59843173.html