Transcript OpenVirteX
Programmable Virtual Networks From Network Slicing To Network Virtualization Ali Al-Shabibi Open Networking Laboratory Outline • Define FlowVisor – It’s design goal – It’s success – It’s limitation • Describe and define Network Virtualization • Introduce the OpenVirteX (formerly known as NetVisor), which provides programmable virtual networks Why FlowVisor? Evaluating new network services is hard Experimenters want to control the behaviour of their network New services may require changes to switch software Also require access to real world traffic Good ideas rarely get deployed OK… Why is it hard? Current Virtualization à la FlowVisor • Network Slice = Collection of sliced switches, links, and traffic or header space • Each slice associated to a controller • Transparent slicing, i.e., every slice believes it has full and sole control of datapath FV enforces traffic and slice isolation Not a generalized virtualization Great! What about real traffic? • FlowVisor allows users to opt-in to services in real-time – Individual flows can be delegated to a slice by a user – Admins can add policy to slice dynamically VoIP Slice Video Slice Web Slice All the rest FlowVisor Sprinkle some resource limits • Slicing resources includes: – Specifying the link bandwidth – Maximum number of forwarding rules – Fraction of switch CPU FlowSpace: Which slice controls which packet? Mapping Packets to Slices FlowVisor Where does it live? • Sits between switches and controllers • Speaks OpenFlow up and down. • Acts like a proxy to switches and controllers • Datapaths and controllers run unmodified What kind of magic is this? It this action allowed? Who controls this packet? PacketIn from datapath Message Handling - PacketIn Yes Send to appropriate slice. Is LLDP? PacketIn Drop if controller is not connected. No Extract match structure and match FlowSpace match Are actions allowed? No Log exception. Yes Drop if controller is not connected. No match Has packet been send to a slice? Yes Done Send to slice. No Insert a drop rule. Message Handling - FlowMod FlowMod Slice Actions Slicing permitted? Yes Extract match struct and intersect FlowSpace Intersections Has slice permissions? No Intersections Zero rewrites? No Done Yes Log exception For each intersection, rewrite original flowmod with flowspace info. No Send Error. Log exception FlowVisor Highlights • Demonstrations: – Open Networking Summit ’12 and ’13 – GENI GEC 9 – Best demo at SIGCOMM ’09 • Deployments : – – – – GENI OFELIA Stanford Production Network In use at NEC and Ericsson labs, as well as other vendors • 3 releases in the past year – 1.0 release downloaded over 70 times in one day KSU U of Wisconsin U of Utah Clemson BBN NYSERNet CENIC AT&T Comcast Vendors Rutgers APNIC Commercial Network Ops Georgia Tech R&E Networks University Research FlowVisor Downloaders Release 1.0 Goldman Sachs EarthLink Cisco PSINet Aruba RCN NEC Ericsson FlowVisor Summary • FlowVisor introduces the concept of a network slice • Not a complete virtualization solution. • Originally designed to test new network services on production taffic • But, it’s really only a Network Slicer! FlowVisor provides network slicing but not a complete network virtualization. What should Network Virtualization be? At least what I think ;) • Conceptually introduces virtual network which is decoupled from physical network • Should not change the abstractions we know and love of physical networks • Should provide some new one: Instantiation, deletion, service deployment, migration, etc. What is Network Virtualization? VPN Overlays VLAN None of these give VRF you a virtual network MPLS TRILL They merely virtualize one aspect of a network Topology Virtualization • Virtual links • Virtual nodes • Decoupled from physical network Address Virtualization Policy Virtualization • Virtual Addressing • Maintain current abstractions • Add some new ones • Who controls what? • What guarantees are enforced? Network Virtualization vs. Network Slicing Slicing • Sorry, you can’t. • You need to discriminate traffic of two networks with something other than the existing header bits • Thus no address or complex topology virtualization Network virtualization • Virtual nets are completely independent • Virtual nets are distinguished by the tenant id • Complete address and topology virtualization Virtualization State of the Art • Functionality implemented at the edge • Use of tunneling techniques, such as STT, VXLAN, GRE • Network core is not available for innovation • Closed source controller controls the behaviour of the network • Provides address and topology virtualization, but limited policy virtualization. • Moreover, the topology looks like only one big switch Big Switch Abstraction E1 SWITCH 1 E3 E1 E2 E2 • A single switch greatly limits the flexibility of the E5 network controller • Cannot specify your own routing policy. • What if you want a tree topology? SWITCH 2 E4 E6 E3 E4 E5 E6 Current Virtualization vs OpenVirteX Current Virtualization Solutions • Networks are not programmable • Functionality implemented at the edge • Network core is not available for innovation • Must provision tunnels to provide virtual topology • Address virtualization provided by encapsulation OpenVirteX • Each virtual network is handed to a controller for programming. • Edge & core available for innovation • Entire physical topology may/can be exposed to the downstream controller. • Address virtualization provided by remapping/rewriting header fields • Both dataplanes and controllers can be used unmodified. OpenVirteX OpenVirtex All problems in computer science can be solved by another level of indirection. - David Wheeler Ultimate Goal Network)OS) Network)OS) Network)OS) VM) Virtual)Network) Maps) Topology,)Address)Space)and) Control)Func>on)Mapping) Physical)Network) Map) OpenVirteX NetVisor) physical)network) Address Space Virtualisation virtual)IP)space) Network)OS) Control traffic address translation virtual)IP) NetVisor) physical)IP) VM) edge) switch) NetVisor) Address)Space)Mapping)) physical)IP) physical)IP) virtual)IP) virtual)IP) physical)network) Data Datatraffic traffic address translation address mapping physical)IP)space) source'physical'IP' tenant'ID' MSB' transformed' virtual'source'IP' 32'bits' des1na1on'physical'IP' tenant'ID' LSB' transformed' virtual'des1na1on'IP' 32'bits' Topology Virtualization - Abstractions • Expose physical topology to tenants • Virtual link: collapse multi-hop path into one-hop link • Approach is also valid for proactive rules OpenVirtex Abstractions (contd.) ... – Allow OpenVirteX admin to control routing within virtual switch virtual switch ... • Virtual switch: collapse ports dispersed over network into a switch • Big switch is virtual switch with all edge ports • Use separate controller for each virtual switch virtual physical core ports edge ports VM OpenVirteX Interaction with the Real-World NetVisor OpenVirtex OpenVirteX API Mapping to Quantum OpenVirteX OpenStack Management System Nova Nova plugin VM1 Quantum plugin VM2 vSwitch Quantum Quantum plugin Other Components Quantum plugin virtual switch VM3 OpenFlo w Physical Network OpenVirteX API Mapping to Quantum OpenVirteX Create Network API Quantum ✔ Attach Port API ✔ Create vRouter API ✔ Configure Topology API Via the Router extension High Level Features • Support for more generalized network virtualization as opposed to slicing – Address virtualization: use extra bits or clever use of tenant id in header – Topology virtualization: on demand topology • Integrate with cloud using OpenStack – Via the Quantum plugin • Support any OF 1.x version, simultaneously • Support for scale, HA and security-features. – Incorporate right building blocks from other OSS Just finised implementing a prototype Current Status • Quick and dirty prototype implemented • Provides Address space virtualisation/isolation • Two topology abstractions: – Virtual Link – Virtual Switch • Current implementation not intended to scale or provide any significant performance – It’s a proof of concept Future Challenges • Traffic engineering, e.g., load balancing • Reliability, e.g., disjoint paths • The above needs special attention when offering topology abstractions – They may even be severely impacted. • Physical topology changes • Tenant may ask for reconfiguration of virtual network • Extremely challenging to get right Conclusion • FlowVisor 1.0 will remain to be supported • OpenVirteX is still in the design phase – But our clear goal is to deliver programmable virtual networks. • An initial proof of concept may be available in Q3 2013. • Contributions to FlowVisor and OpenVirteX are greatly appreciated and welcomed. Thanks! Questions?