Presentation is loading. Please wait.

Presentation is loading. Please wait.

Programmable Virtual Networks

Similar presentations

Presentation on theme: "Programmable Virtual Networks"— Presentation transcript:

1 Programmable Virtual Networks
From Network Slicing To Network Virtualization Ali Al-Shabibi Open Networking Laboratory 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!!!

2 Outline Define FlowVisor Describe and define Network Virtualization
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 Good ideas rarely get deployed
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 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.

4 OK… Why is it hard? Real Networks Test beds
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. 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 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.

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

7 Sprinkle some resource limits
Slicing resources includes: Specifying the link bandwidth Maximum number of forwarding rules Fraction of switch CPU 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: Which slice controls which packet?

8 Mapping Packets to Slices
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.

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

10 What kind of magic is this?
Who controls this packet? It this action allowed? PacketIn from datapath So how does this work….

11 Message Handling - PacketIn
Drop if controller is not connected. PacketIn Is LLDP? Send to appropriate slice. Yes Extract match structure and match FlowSpace No Yes Send to slice. Are actions allowed? Log exception. No match Drop if controller is not connected. Has packet been send to a slice? No match Done Insert a drop rule. No Yes When a packet in is received, we first check whether the packet is an LLDP packet. If it is we send it to the appropriate slice if the controller for this slice is connected. If this packet is not LLDP, the we extract the match structure from the packet in. We use this match structure to intersect the flowspace, if we find a match we we analyze the actions, ie. the flowspace actions. Depending whether this actions are allowed we either log an exception of we send it to a slice if the slice controller is connected. Finally, the last past is a safety feature of FV. If we did not send the packet to a slice then we protect the control path by installing a drop rule.

12 Message Handling - 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 When a controller send a flowmod, FlowVisor catches it. FlowVisor starts by slicing the actions, and verifying that such slicing is permitted. For example, if a flowmod rewrites a vlan id to another vlan id, then both vlans must by in the slice’s flowspace otherwise an error is send back to to controller. Then we extract the match and intersect it with the flowspace, every intersection is then used to rewrite the original flowmod with the flowspace definitions Finally if there are no rewrites, Flowvisor sends an error to the controller.

13 FlowVisor Highlights Demonstrations: Deployments :
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
University Research Georgia Tech Rutgers KSU U of Wisconsin U of Utah Clemson R&E Networks APNIC BBN NYSERNet CENIC Commercial Network Ops 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?
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. 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.

17 What is Network Virtualization?
VPN Overlays None of these give you a virtual network VLAN VRF MPLS TRILL They merely virtualize one aspect of a network 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. 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
Say you want two networks with exactly the same properties. 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 Ok so whats really the difference between slicing and virtualization. Say you want to have two networks with exactly the same properties? …

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

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 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. E4 E6 E3 E4 E5 E6

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. So just to summarize the differences between what exists and what we are building.

22 OpenVirteX OpenVirtex
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. 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 traffic address 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: 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 switch . . . . . . virtual physical core ports edge ports VM

27 OpenVirteX Interaction with the Real-World

28 OpenVirteX API Mapping to Quantum
OpenStack Management System Nova Quantum Other Components Quantum plugin Nova plugin Quantum plugin Quantum plugin VM1 VM2 VM3 Physical Network virtual switch OpenFlow vSwitch

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

30 How does it work? Finally FlowVisor removes the tag, so that the packet can be send to the destination. FlowVisor rewrites the control plane packet to match what the controller expects. FlowVisor modifies the control packet to append a tag. Switch generates a control packet, which is sent up to the controller. Packet is tagged on the dataplane Ok so let’s see how this can work. For simplicity we are going to stick to a reactive model First 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 FlowVisor FlowVisor 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. Host sends a packet

31 Just finised implementing a prototype
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

32 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

33 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

34 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 Q Contributions to FlowVisor and OpenVirteX are greatly appreciated and welcomed.

35 Thanks! Questions?

Download ppt "Programmable Virtual Networks"

Similar presentations

Ads by Google