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 AbstractionE1
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
NetVisor

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?