This document provides an overview of the OpenVirteX (OVX) network virtualization platform. OVX allows multiple virtual networks to run over a single physical network in an isolated manner. It provides topology and address virtualization so each tenant can specify their own virtual network topology and IP addressing scheme. OVX acts as a network hypervisor, mapping virtual network elements to physical network elements and managing the interactions between virtual and physical networks.

1. 1/47
Dongho Son
Dept. of CSE, POSTECH
donghoson@postech.ac.kr
http://dpnm.postech.ac.kr
2016. 11. 07

2. 2/47
Outline
 Introduction
 Use cases
 Previous work
 Architecture
 Features
 Results
 Conclusion & Future work
 OVX Tutorial
 References

3. 3/47
Introduction
 Virtual Networks
 To provide virtualized network resource, the network is decoupled from
its physical manifestation
 Network virtualization has emerged as one of the key capabilities of
computing and networking infrastructure
• Why?  These virtual networks can offer strong isolation, migration, snapshot and
customize topology
• So..?  Infrastructure providers are focusing on network virtualization using SDN to
better utilize their network resources
 OpenVirteX(OVX)
 A network virtualization platform that can …
• Provide address virtualization to keep tenant traffic separate
• Provide topology virtualization to enable tenants to specify their topology
• Deliver each virtual network to the tenants’ NOS as Infrastructure
 OVX is a network hypervisor that manage network virtualization

4. 4/47
Use Cases
 NFV
 Nowadays network function, such as firewall, DPI, load-balancing and
authentication, are implemented in dedicated H/W appliances
 NFV offers such network functions in S/W and VMs to reduce
CAPEX/OPEX and allow more flexibility
 NFV will require dynamic virtual networks management

5. 5/47
Previous Work(1/2)
 FlowVisor
 A S/W platform for slicing an OpenFlow network into multiple resource
pools, or slices
 All slices share the same flow or address space, and thus a slice
doesn’t have a completely separate and independent address space
 FlowVisor also doesn’t allow a slice to have an arbitrary virtual network
topology. It only offer a subset of the physical topology

6. 6/47
Previous Work(2/2)
 VeRTIGO
 An extension to FlowVisor which provides topology virtualization
 Each tenant can specify virtual links in the network slice
 Since VeRTIGO is based on FlowVisor it is unable to provide each
tenant with a full isolated address space
 FlowN
 Add a database storage system to maintain a mapping between the
physical and virtual realms
 Since each tenant’s logic must be embedded in the FlowN controller, a
tenant is constrained to developing their application with the FlowN
framework

7. 7/47
Architecture(1/3)
 Network virtualization platform
 OVX is a network virtualization platform capable of spawning virtual
networks with OpenFlow semantics
 These virtual networks may have arbitrary topology and addressing
schemes, configured as per tenant request
 Requests are conveyed via API calls to OVX with a tool such as a
network embedder

8. 8/47
Architecture(2/3)
 Internal OVX architecture
 Internally, OVX relies on a loose decoupling of virtual elements from
physical counterparts
 OVX models all virtual and physical elements and maintains the
mapping between them
 All virtual network elements are mapped to at least one physical
element

9. 9/47
Architecture(3/3)
 Topology virtualization
 OVX allows the tenants to specify their own arbitrary topology
 These topologies don’t have to correspond to the actual physical
network, but exactly match what the tenants desire
 Address virtualization
 OVX grants tenants the ability to choose address assignments for their
end hosts, allowing multiple, potentially over-lapping IP address blocks
to exist in the same physical network
 To differentiate hosts, OVX generates unique tenant IDs for each tenant
 Control function virtualization
 Each virtual network can have its own NOS and applications that can
program the virtual network switches
 OVX is responsible for mapping various control functions for the virtual
network on to the corresponding physical network

10. 10/47
Features(1/2)
 Loose coupling of virtual and physical
components introduces significant amounts of
flexibility
 Topology customization
• A virtual link may encompass multiple contiguous hops, and virtual switches may
abstract away parts or all of a network
 Resiliency
• A resilient virtual link is characterized by multiple physical paths between the points
corresponding to the virtual link endpoints
 Dynamic vSDN reconfiguration
• Since the mappings themselves don’t store any network state, these can be changed
at runtime.

11. 11/47
Features(2/2)
 Persistence
 Each network and network element maintains a collection of
preservable attributes
• It allows OVX to record and store information in storage
• vSDNs can be torn down and re-created at a later time
• It gives OVX the ability to save and recover vSDN configuration, persistence which
can enable to snapshot tenant networks
 Troubleshooting
 Extensive rewriting of control messages complicates the already difficult
process of troubleshooting networks
 OVX enables it to integrate with network debuggers by providing
connection into vSDNs

12. 12/47
Results(1/2)
 Control channel overhead and virtual network
generation time
 A figure shows the latency introduced by OVX, FlowVisor, and FlowN
and the reference case where no virtualization software is used and the
packets are sent directly from the switch to the controller
 Compared with other platforms, OVX offers better performance than
similar virtualization platforms
 It just adds around 0.2 ms latency to the control channel

13. 13/47
Results(2/2)
 Control channel overhead and virtual network
generation time
 A Table shows the time needed to create and configure a virtual
network up to the point where the network OS has connected
 Virtual networks can be created through the API or loaded from
persistent storage(DB)
 OVX clearly can offer with provisioning times in the order of several
(tens of) seconds

14. 14/47
Conclusion & Future Work
 OVX provides programmable vSDNs
 These vSDNs are customizable in terms of topology and addressing
scheme used, and each tenant can control his virtual SDN with the
NOS of his choice
 Three additional functionalities
 Snapshotting and migration of vSDNs
• The ability to preserve the state and data of VM at a specific point in time has
become a key functionality
• This allows not only fast recovery in case of failure, but also eases the migration and
duplication of a working VM in other location
 Evolving beyond OF1.0
• Replace the standard java openflowj library, strictly tied to OF1.0, with LOXI
• Plan to implement OF1.3 in the southbound interface
 vSDN-based QoS
• OVX will use flow-based meters to enforce QoS for the virtual networks, thus offering
to the tenants a fully isolated environment with performance guarantees

15. 15/47
OVX Tutorial

16. 16/47
Introduction
 Pre-requisites
 Need a computer with at least 2GB of RAM & at least 5GB
of free hard disk space
 Windows, Mac OS X or Linux – all work fine with VirtualBox
 Download two files
 VirtualBox (https://www.virtualbox.org/)
 Tutorial VM (http://ovx.wpengine.com/wp-
content/uploads/ovx-vm-x86_64-2014-10-14.zip)
• Unzip it! Then you can see vmdk file.

17. 17/47
Setup Your Environment
 Create Virtual Machine(VM)
 Start up VirtualBox
 Select Machine>New, give it a name, and select Linux as
type and Ubuntu(64bit) as version.
 Configure the VM with 2GB of memory.
 Select ‘Use an existing virtual hard drive file’, and point it to
the vmdk file you download. Select create.
 Start VM
 Login with user ovx and password ovx

18. 18/47
Setup Your Environment
 Important Command Prompt Notes
 Terminal command prompt
 Mininet console
 OVX log message

19. 19/47
Setup Your Environment
 Scenario
 11 core switches
 Each core switch has 4 hosts attached
 Hosts connect to their core switch on ports 1 through 4
 Other port number are shown in the topology image.

20. 20/47
Setup Your Environment
 Scenario
 DPIDs are listed in the table
 Host MAC addresses are the last 6 bytes of the DPIDs,
with the last byte equal to host number
Example)
DPID of SFO
 00:00:00:00:00:00:02:00
MAC of the 3rd host on SFO
 00:00:00:00:02:03

21. 21/47
Setup Your Environment
 Start Mininet
 Start a terminal and run internet2.py
• $ sudo python internet2.py
• It will run Mininet and construct topology
 It will point all switches to connect to OVX
OVX

22. 22/47
Setup Your Environment
 Start OVX
 Start another terminal and run OVX
• $ cd OpenVirtex/scripts
• $ sh ovx.sh
 OVX connect to all switches and links in the network
OVX

23. 23/47
Learning to Fly
 Introduction
 Try to create a simple virtual network composed out of two
hosts, h_SEA_1 and h_LAX_2
 Final virtual network will look like figure
h_SEA_1
h_LAX_2

24. 24/47
Learning to Fly
 Virtual Network Configuration
 Create virtual network
• Start a new terminal
• $ python ovxctl.py –n createNetwork tcp:localhost:10000 10.0.0.0 16
• A virtual network will have a controller speaking tcp protocol and running on localhost
port 10000. Virtual network’s hosts will be using Ips in the 10.0.0.0/16 range.
• Above command returns a tenant ID (ex. ‘tenantId’:1 )
 Create virtual switches
• $ python ovxctl.py –n createSwitch 1 00:00:00:00:00:00:01:00  SEA
• $ python ovxctl.py –n createSwitch 1 00:00:00:00:00:00:02:00  SFO
• $ python ovxctl.py –n createSwitch 1 00:00:00:00:00:00:03:00  LAX
• Each time we create a virtual switch, we get a virtual switch DPID.
• Virtual DPID of SEA : 00:a4:23:05:00:00:00:01
• Virtual DPID of SFO : 00:a4:23:05:00:00:00:02
• Virtual DPID of LAX : 00:a4:23:05:00:00:00:03
tenantId Physical DPID

25. 25/47
Learning to Fly
 Virtual Network Configuration
OVX
1) Create virtual network
2) Create virtual switches
SEA
SFO
LAX
00:a4:23:05:00:00:00:01
00:a4:23:05:00:00:00:02
00:a4:23:05:00:00:00:03

26. 26/47
Learning to Fly
 Virtual Network Configuration
 Create virtual ports
• $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:01:00 1  return port 1
• $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:01:00 5  return port 2
• $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:02:00 5  return port 1
• $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:02:00 6  return port 2
• $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:03:00 5  return port 1
• $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:03:00 2  return port 2
tenantId Physical DPID Physical port
Get virtual port
SEA 
SFO 
LAX 

27. 27/47
Learning to Fly
 Virtual Network Configuration
 Create virtual links
• $ python ovxctl –n connectLink 1 00:a4:23:05:00:00:00:01 2 00:a4:23:05:00:00:00:02 1 spf 1
• $ python ovxctl –n connectLink 1 00:a4:23:05:00:00:00:01 2 00:a4:23:05:00:00:00:02 1 spf 1
• The call returns the virtual link ID. Note that OVX will automatically create the reverse link as well,
which has the same link ID.
 Connect hosts
• $ python ovxctl –n connectHost 1 00:a4:23:05:00:00:00:01 1 00:00:00:00:01:01
• $ python ovxctl –n connectHost 1 00:a4:23:05:00:00:00:03 2 00:00:00:00:03:02
• Connect h_SEA_1 to port 1 on the first virtual switch
• Connect h_LAX_2 to port 2 on the third virtual switch
tenantId src virtual DPID dst virtual DPID
src port dst port
tenantId virtual switch DPID
virtual switch port
Host MAC address

28. 28/47
Learning to Fly
 Virtual Network Configuration
OVX
3) Create virtual ports
4) Create virtual links
①
②
SEA
SFO
LAX
00:a4:23:05:00:00:00:01
00:a4:23:05:00:00:00:02
00:a4:23:05:00:00:00:03
②
②
①
①
h_SEA_1
00:00:00:00:01:01
h_LAX_2
00:00:00:00:03:02
5) Connect hosts

29. 29/47
Learning to Fly
 Starting a virtual network
 Our virtual network is ready to be booted
• $ python ovxctl.py –n startNetwork 1
• The virtual switches connect to the controller(Floodlight)
• From the controller’s point of view, OVX will look and behave exactly like a physical network.
• OVX looks like a controller from the physical switches’ perspective
tenantId
That is a physical
network!
That is a
controller!
OVX

30. 30/47
Learning to Fly
 Starting a virtual network
 Ping between two hosts
• Try to ping between h_SEA_1 and h_LAX_2  Everything works fine!
 Floodlight’s GUI
• http://localhost:10001/ui/index.html

31. 31/47
Learning to Fly
 Starting a virtual network
 Inspecting the flow tables on the physical switches
• cookie=0x100000002, … , dl_src=00:00:00:00:01:01, dl_dst=00:00:00:00:03:02
actions=mod_nw_dst:1.0.0.4, mod_nw_src:1.0.0.3, mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:10:00:04
• cookie=0x100000003, … ,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:10:00:02
actions=mod_nw_dst:10.0.0.2,mod_nw_src:10.0.0.1,mod_dl_src:00:00:00:00:03:02,mod_dl_dst:00:00:00:00:01:01
• cookie=0x100000002, … , dl_src=a4:23:05:01:00:00, dl_dst=a4:23:05:10:00:04
actions=mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:10:00:04
• cookie=0x100000003, … ,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:20:00:02
actions=mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:10:00:02
• cookie=0x100000002, … , dl_src=00:00:00:00:03:02, dl_dst=00:00:00:00:01:01
actions=mod_nw_dst:1.0.0.3, mod_nw_src:1.0.0.4, mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:20:00:02
• cookie=0x100000003, … ,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:20:00:04
actions=mod_nw_dst:10.0.0.1,mod_nw_src:10.0.0.2,mod_dl_src:00:00:00:00:01:01,mod_dl_dst:00:00:00:00:03:02
 OVX rewrites packets at the edge of the network
• IP address of h_SEA_1 and h_LAX_2 get rewritten from 10.0.0.x to 1.0.0.x and back
• MAC address of packets are also rewritten
• The controller is unaware of all this rewriting. It only deals with packets that have their original IP (in the 10.0/16
range) and MAC address
SEA 
SFO 
LAX 

32. 32/47
Learning to Fly
SEA
LAX
SFO
MAC=00:00:00:00:01:01
IP : 10.0.0.1
Host2
Host1
MAC=00:00:00:00:03:02
IP : 10.0.0.2
dl_src=a4:23:05:01:00:00
dl_dst=a4:23:05:20:00:04
mod_dl_src=00:00:00:0:01:01
mod_dl_dst=00:00:00:0:03:02
mod_nw_src=10.0.0.1
mod_nw_dst=10.0.0.2
dl_src=00:00:00:00:01:01
dl_dst=00:00:00:00:03:02
mod_dl_src=a4:23:05:01:00:00
mod_dl_dst=a4:23:05:10:00:04
mod_nw_src=1.0.0.3
mod_nw_dst=1.0.0.4
MACs are changed!
IPs are changed!
dl_src=a4:23:05:01:00:00
dl_dst=a4:23:05:10:00:04
mod_dl_src=a4:23:05:01:00:00
mod_dl_dst=a4:23:05:10:00:04

33. 33/47
Learning to Fly
SEA
LAX
SFO
MAC=00:00:00:00:01:01
IP : 10.0.0.1
Host2
Host1
MAC=00:00:00:00:03:02
IP : 10.0.0.2
dl_src=a4:23:05:01:00:00
dl_dst=a4:23:05:10:00:02
mod_dl_src=00:00:00:00:03:02
mod_dl_dst=00:00:00:00:01:01
mod_nw_src=10.0.0.2
mod_nw_dst=10.0.0.1
dl_src=00:00:00:0:03:02
dl_dst=00:00:00:0:01:01
mod_dl_src=a4:23:05:01:00:00
mod_dl_dst=a4:23:05:20:00:02
mod_nw_src=1.0.0.4
mod_nw_dst=1.0.0.3
MACs are changed!
IPs are changed!
dl_src=a4:23:05:01:00:00
dl_dst=a4:23:05:20:00:02
mod_dl_src=a4:23:05:01:00:00
mod_dl_dst=a4:23:05:10:00:02

34. 34/47
Air Traffic Control
 Add another virtual network
 This network uses the same IP addresses space as the first
 Traffic is completely isolated among tenants
 mininet> h_SEA_3 ping –c3 h_LAX_4  works fine.
• h_SEA_3 and h_LAX_4 are in the second virtual network
 mininet> h_SEA_1 ping –c3 h_LAX_4  No ping.
• h_SEA_1 is in the first virtual network but h_LAX_4 is in the second virtual network
①
②
SEA
SFO
LAX
00:a4:23:05:00:00:00:01
00:a4:23:05:00:00:00:02
00:a4:23:05:00:00:00:03
②
②
①
①
h_SEA_3
00:00:00:00:01:03
h_LAX_4
00:00:00:00:03:04

35. 35/47
Build Your Own Topology
 Big switches
 Create a single virtual switch that is composed out of
multiple physical switches
• $ pyhon ovxctl.py –n createSwitch 3
00:00:00:00:00:00:05:00,00:00:00:00:00:00:06:00,00:00:00:00:00:00:0A:00
• It returns switch_id 00:a4:23:05:00:00:00:01
CLE
IAD
EWR
h_CLE_3
h_EWR_2
h_IAD_1
CLE
IAD
EWR
00:a4:23:05:00:00:00:01

36. 36/47
Build Your Own Topology
 Big switches
 It’s interesting to see that, from the controller’s perspective,
traffic is forwarded between ports on a single switch
 It makes controller’s job so easier, as all it has to do is
forward traffic between ports on a switch
 Multiple physical switches can be aggregated into a virtual
switch. But it cannot partition a single physical switch into
multiple virtual switches.

37. 37/47
Build Your Own Topology
 Virtual links
 A virtual link is simply a link between two virtual switches
 OVX calculate the routing automatically for the virtual link
• User can specify a manual route by configuring the routing algorithm
I don’t care here.
I just want to
connect MCI to
Big switch
h_CLE_3
h_EWR_2
h_IAD_1
CLE
IAD
EWR
00:a4:23:05:00:00:00:01
MCI
h_MCI_4
00:a4:23:05:00:00:00:02
③
④
①
②
②
①

38. 38/47
Automagic Networks
 Big switch
 All we want is to connect hosts over a single big switch
automatically
h_SFO_1
h_IAD_2
h_EWR_3
h_ORD_4

39. 39/47
Automagic Network
 Big switch
 Using json file, it can automatically create virtual switch
h_SFO_1
h_IAD_2
h_EWR_3
h_ORD_4
ORD
EWR
IAD
SFO
②
④
③
①

40. 40/47
Automagic Networks
 Physical clone
 We want a clone of the physical network
 Using json file, it can automatically copy physical network
h_SEA_1
h_MCI_3
h_IAH_4
h_ATL_2

41. 41/47
Networking. Uninterrupted.
 OVX ensures user’s network is there and
operating as expected
 If a physical link fails, OVX can automatically switch over to
the backup path without the controller noticing a thing
 OVX calculated both a primary and backup path

42. 42/47
Networking. Uninterrupted.
 Fast reroute
 As soon as OVX detects that a link has gone down, it finds
out which flows are currently using that link, and shifts
traffic away onto the backup path
Time for ping sequence number 9
is much higher than the rest.
Since OVX pre-calculated the path,
it could push down the new rules
over the full path very quickly
Original path
Backup path

43. 43/47
Networking. Uninterrupted.
 More backups
 OVX calculates a single backup path by default
 If user want to have more then user can ask OVX to
calculate more backups
 After a link failure, OVX automatically switches to a backup
path. After the link comes back up, OVX will revert to the
original situation
 Taking control of routing
 OVX calculates shortest path routes by default
 But user also can configure the routes

44. 44/47
What goes up must come down
 Start and stop
 How to stop and start the switch
• A ping between h_ATL_2 & h_MCI_3
• $ python ovxctl.py –n stopSwitch 2 00:00:00:00:00:00:04:00
• $ python ovxctl.py –n startSwitch 2 00:00:00:00:00:00:04:00

45. 45/47
What goes up must come down
 Clean up
 How to remove the host
• Want to remove host h_IAH_4
• $ python ovxctl.py –n disconnectHost 2 4
h_SEA_1
h_MCI_3
h_IAH_4
h_ATL_2

46. 46/47
References
 http://ovx.onlab.us/getting-started/tutorial/
 http://dl.acm.org/citation.cfm?id=2620741

47. 47/47
Q&A
 Any Question?