Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie Virt july-2013-meetup
Ähnlich wie Virt july-2013-meetup (20)
Mehr von nvirters
Mehr von nvirters (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Virt july-2013-meetup
- 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? Good ideas rarely get deployed Also require access to real world traffic New services may require changes to switch software Experimenters want to control the behaviour of their network Evaluating new network services is hard
- 4. OK… Why is it hard?
- 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 FlowVisor Web Slice VoIP Slice Video Slice All the rest
- 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. 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
- 10. What kind of magic is this? PacketIn from datapath Who controls this packet? It this action allowed?
- 11. Message Handling - PacketIn PacketIn Drop if controller is not connected. Is LLDP? Send to appropriate slice. Yes Extract match structure and match FlowSpace No Done Insert a drop rule. No Yes Drop if controller is not connected. Yes Send to slice. Are actions allowed? Log exception. Nomatch Has packet been send to a slice? No match
- 12. Message Handling - FlowMod FlowMod Slicing permitted? Slice Actions Send Error. Log exception No Extract match struct and intersect FlowSpace Yes For each intersection, rewrite original flowmod with flowspace info. Has slice permissions? Intersections No Intersections Zero rewrites? Log exception Done Yes No
- 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 Downloaders Release 1.0 UniversityResearch Georgia Tech Rutgers KSU U of Wisconsin U of Utah Clemson R&ENetworks APNIC BBN NYSERNet CENIC CommercialNetworkOps AT&T Comcast EarthLink PSINet RCN Vendors Goldman Sachs Cisco Aruba NEC Ericsson
- 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. 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. At least what I think ;)
- 17. MPLS VRF Overlays TRILL VLAN VPN What is Network Virtualization? None of these give you a virtual network 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 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
- 19. 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
- 20. Big Switch Abstraction E6 E2 E5 E1 E3 E4 SWITCH 1E1 E3 E2 E5 SWITCH 2 E4 E6 • A single switch greatly limits the flexibility of the network controller • Cannot specify your own routing policy. • What if you want a tree topology?
- 21. 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.
- 22. OpenVirteX All problems in computer science can be solved by another level of indirection. - David Wheeler OpenVirtex
- 23. Ultimate Goal physical)network) NetVisor) Virtual)Network) Maps) Physical)Network) Map) VM) Topology,)Address)Space)and) Control)Func>on)Mapping) Network)OS) Network)OS) Network)OS) OpenVirteX
- 24. Address Space Virtualisation source'physical'IP' des1na1on'physical'IP' tenant'ID' LSB' transformed' virtual'source'IP' transformed' virtual'des1na1on'IP' 32'bits' 32'bits' tenant'ID' MSB' NetVisor) physical)network) VM) edge) switch) virtual)IP) physical)IP) physical)IP) virtual)IP) physical)IP) virtual)IP) Network)OS) Control traffic address translation physical)IP)space) virtual)IP)space) NetVisor) Address)Space)Mapping)) Data traffic address mapping Data traffic address translation
- 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: 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 ... ... virtual switch edge ports core ports VM
- 27. OpenVirteX Interaction with the Real-World NetVisorOpenVirtex
- 28. OpenVirteX API Mapping to Quantum OpenStack Management System Nova Quantum Other Components virtual switch vSwitch VM1 VM2 VM3 Nova plugin Quantum plugin Quantum plugin OpenVirteX Quantum plugin OpenFlo w Physical Network
- 29. OpenVirteX API Mapping to Quantum Create Network API OpenVirteX Quantum ✔ Attach Port API ✔ Create vRouter API ✔ Configure Topology API Via the Router extension
- 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 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
- 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.
Hinweis der Redaktion
- Hi! Ia am Ali Al-Shabibi and I work at the ON.Lab. I am going to tell you about FlowVisor. Who here know FlowVisor? Who has used FlowVisor? Well you should be!!!
- Evaluating network sevices is diffcult and that for a variety of reasons. For one, users need control over the semantics of their network which could mean that they need to change the switches firmware. To top it off and to be credible you need access to real user traffic. So needless to say new ideas rarely get deployed.
- Alright, why is this hard? Well let’s contrast a real networks and test beds. Real Networks have the port density you want backed by relatively power networking devices. Then, they have the scale that you would can only hope to have. Finally, they have real users. Test beds on the other hand, usually have a low port density because they are usually composed of linux boxes. Then, their scale is limited by the amount of money you have and worse , they only have fake users, which really isn’t credible.
- So let’s look at the FlowVisor’s current virtualization. FlowVisor defines a slice as a collection of sliced switches, links and traffic. By traffic, we mean the header space that distinguishes this traffic, this is also know as flowspace. Then, each slice is associated to a controller. This controller now has control over the slice while thinking that it is the sole user of the datapath. FlowVisor is therefore responsible for enforcing isolation amongst the collection of slices that exist. Notice here that controllers and switches do not need to be modified to work with flowvisor.
- So now you know how flowvisor defines a slice, but what about adding real user traffic? The idea is to run network services as part of a slice and allow users to opt-in to the services. Users opt-in by delegating flows to slices which are themselves controlled by a specific controller. Moreover, an admin can add a service to the network by dynamically adding policy at the FlowVisor.
- Furthermore,FlowVisor allows you to define resource limits which are made available to every slice. You can specify dataplane link bandwidth as well as the number of available tcam entries available to a slice. You can also slice the CPU of the switch on a per slice basis, based on the amount of control traffic a particular slice controller can generate.OK but how are packet classified onto a slice, by this I mean which controller contols which packet. This is achieved by the notion of flowspace.
- FlowSpace is basically the set of all possible header values defined by the OpenFlow tuple. For example, Slice 3 is defined as the traffic that ranges all IP and MAC addresses that are on a particular TCP port minus the set of Ips and macs that are in slice 1. Slice 1 ranges all TCP ports. Slice 2, overlaps with Slice 3 which is a problem because in the overlapping regions we cannot distinguish that control traffic and therefore FlowVisor does not know which controller to forward the control packets to. FlowVisor avoids this problem by assigning a priority to each flowspace definition, and therefore this means that only one controller can ever control a particular flowspace.
- So now you know quite a bit about how flowvisor functions but sadly you do not know where it lives. Let’s fix that. FlowVisor lives between the switches and controllers and speaks openflow up to the controller and down to the switches. It basically acts like a glorified OpenFlow NAT for control traffic. Again, the controllers and datapaths can run unmodified.
- So how does this work….
- I’d like to define what network virtualization is… at least from my point of view. Network Virtualization should introduce the concept of a virtual network which is completely decoupled from the physical network.It should not change the abstraction that we know and love. But should provide some new ones, like instantiation, migration, snapshotting, etc.
- There are a bunch of virtualization techniques such as VRFs, VLANs, Overlays, etc. but unfortunately none of these deliver a decoupling of your virtual net from your physical infrastructure. They basically virtualize a certain aspect of your network. In my mind, there are three main flavors of network virtualization. Topology Virtualization, Address Virtualization, and policy virtualization. Topology Virtualization is the ability to have virtual nodes and/or links. These must be logically decoupled from your physical network.Address Virtualization – Essentially this is the ability to give the illusion to the user that he has the entire addressable space. But while we do this, we should take care of maintaining the current assumption, no one will like me if I destroy TCP/IP to give you a virtual net. Policy Virtualization – This is essentially what flowvisor currently does. We want to know who can control what and what guarantees do we give.
- Ok sowhats really the difference between slicing and virtualization. Say you want to have two networks with exactly the same properties? …
- So there already exist solution which will provide you with virtual networks. Most of these solutions use some sort of tunneling technique such as VXLAN or GRE tunnels. They basically treat the core network as a fabric of pipes that just shovel packet for one end of the network to the other. All the intelligence is implemented at the edge of the network which means that you cannot define the semantics of your network simply because that is not available to you but rather a closed source controller defines the nominal behaviour of your network. These solutions have been mostly catered to DCs and they do provide nice address and topology virtualization but unfortunately they provide limited policy virtualizaion. On top of this your topology looks like one big switch which I argue is rather limiting.
- The current state of the art in network virtualization revolves around mainly the big switch abstraction and and some tunneling technology (whether it’s VXLAN, STT, or something else is largely irrelevant). Currently we instantiate virtual networks by assigning endpoints to our virtual network and interconnecting them via this big switch abstraction. The issue is that this abstraction hides away an aspect of the network that we would like to control. Actually in current solution you have very limited choice type of network you would like to instantiate. We would like to change that.
- So just to summarize the differences between what exists and what we are building.
- By including a quantum plugin either directly in FlowVisor or possibly in FOAM we are able to spawn virtual networks which are then paired up with a controller. Each virtual network is given strict performance guarantees which therefore allow each tenant to operate his network unhindered by other tenants. Moreover, flowvisor will support any version of openflow and you will be able to use them simultaneously.As I told you earlier we achieve address and topology virtualization by rewriting control packets, basically all problems in computer science can be solved by another level of indiection.
- Ok so let’s see how this can work. For simplicity we are going to stick to a reactive modelFirst a end host sends a packet and in openflow style a control packet is shipped by the switch to the controller which happens to be FlowVisor in this case. FlowVisor `sees the packet and forwards it to the appropriate controller, the controller does something to the control packet and sends it back to the datapath which is also FlowVisorFlowVisor rewrites this packet and appends some actions to it to case it to tag the dataplane packet. At this point the dataplane packet continues to the next hop. Which triggers another control packet. This packet arrives at FV and is rewritten by FV to match what the controller would expect (ie. It removes the tag) and ships it off to the controller. The controller does its thing and sends it back, FV rewrites the packet to maintain the tag on the dataplane.The data packet continues on its way until it reaches its last hop, at this point yet another control plane packet is shot off to FV which again rewrites it to allow the controller to understand it, sends it to the controller and the controller sends it back. But this time FV appends actions to the control packet that cause the tag to be stripped from the data packet and forwarded to the destination.