Programmable Virtual Networks

1. Programmable Virtual Networks From Network Slicing To Network Virtualization Ali Al-Shabibi Open Networking Laboratory

2. 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

3. Why FlowVisor?

4. OK… Why is it hard? Real Networks Test beds

5. 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

6. 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

7. 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?

8. Mapping Packets to Slices

9. FlowVisorWhere 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

10. PacketIn from datapath What kind of magic is this? Who controls this packet? It this action allowed?

11. Has packet been send to a slice? Are actions allowed? Is LLDP? Insert a drop rule. Send to appropriate slice. No match Yes Yes No Log exception. No match No Send to slice. Extract match structure and match FlowSpace Yes Done Drop if controller is not connected. Message Handling - PacketIn PacketIn Drop if controller is not connected.

12. Zero rewrites? For each intersection, rewrite original flowmod with flowspace info. Slicing permitted? Slice Actions Log exception Send Error. Log exception Has slice permissions? No Intersections No Yes Intersections Yes Extract match struct and intersect FlowSpace No Done Message Handling - FlowMod FlowMod

13. 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

14. FlowVisor DownloadersRelease 1.0

15. 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.

16. At least what I think ;) What should Network Virtualization be? • 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.

17. What is Network Virtualization? VPN Overlays VLAN None of these give you a virtual network VRF MPLS TRILL They merely virtualize one aspect of a network • Topology Virtualization • Virtual links • Virtual nodes • Decoupled from physical network • Address Virtualization • Virtual Addressing • Maintain current abstractions • Add some new ones • Policy Virtualization • Who controls what? • What guarantees are enforced?

18. Network Virtualizationvs.Network Slicing Say you want two networks with exactly the same properties. • Slicing • Sorry, you can’t. • You need to discriminate trafficof 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

19. VirtualizationState 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

20. Big Switch Abstraction E1 SWITCH 1 E3 E1 E2 E2 • A single switch greatly limits the flexibility of the network controller • Cannot specify your own routing policy. • What if you want a tree topology? E5 SWITCH 2 E4 E6 E5 E6 E3 E4

21. Current VirtualizationvsOpenVirteX • 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. • 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

22. OpenVirteX OpenVirtex All problems in computer science can be solved by another level of indirection. - David Wheeler

23. Ultimate Goal OpenVirteX

24. Address Space Virtualisation Control traffic address translation Data trafficaddress translation Data traffic address mapping

25. 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

26. Abstractions (contd.) 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 • Allow OpenVirteX admin to control routing within virtual switch . . . . . . virtual physical core ports edge ports VM

27. OpenVirteXInteraction with the Real-World NetVisor OpenVirtex

28. OpenVirteX APIMapping to Quantum OpenVirteX OpenStackManagement System Other Components Nova Quantum Quantum plugin Quantum plugin Nova plugin Quantum plugin virtual switch VM2 VM3 VM1 Physical Network OpenFlow vSwitch

29. OpenVirteX APIMapping to Quantum OpenVirteX Quantum Create Network API ✔ ✔ Attach Port API ✔ Create vRouter API Via the Router extension Configure Topology API

30. 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 cloudusing 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

31. 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

32. 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

33. 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.

34. Thanks! Questions?