Virtualization TechniquesVirtualization Techniques
Network Virtualization
Software Defined Network
Rajeev TiwariRajeev Tiwari
Software ArchitectSoftware Architect
Software defined network
Introduction
Motivation
Concept
Open Flow
Virtual Switch
Million of lines
of source code
5400 RFCs Barrier to entry
500M gates
10Gbytes RAM
Bloated Power Hungry
Many complex functions baked into the infrastructure
OSPF, BGP, multicast, differentiated services,
Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …
An industry with a “mainframe-mentality”
We have lost our way
Specialized Packet
Forwarding Hardware
Operating
System
App App App
Routing, management, mobility management,
access control, VPNs, …
Operating SystemOperating System
Reality
App
App
App
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Operating
System
App App App
• Lack of competition means glacial innovation
• Closed architecture means blurry, closed interfaces
• Vertically integrated, complex, closed, proprietary
• Not suitable for experimental ideas
• Not good for network owners & users
• Not good for researchers
Glacial process of innovation
made worse by captive
standards process Deployment
Idea Standardize
Wait 10 years
• Driven by vendors
• Consumers largely locked out
• Lowest common denominator features
• Glacial innovation
Software defined network
Introduction
Motivation
Concept
Open Flow
Virtual Switch
Windows
(OS)
Windows
(OS)
Linux
Mac
OS
x86
(Computer)
Windows
(OS)
AppApp
LinuxLinux
Mac
OS
Mac
OS
Virtualization layer
App
Controller
1
AppApp
Controller
2
Virtualization or “Slicing”
App
OpenFlow
Controller
1
NOX
(Network OS)
Controller
2Network OS
Trend
Computer Industry Network Industry
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Ap
p
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
Ap
p
Ap
p
Ap
p
Network Operating System
App App App
The “Software-defined Network”
App
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
App App
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
1. Open interface to hardware
3. Well-defined open API
2. At least one good operating system
Extensible, possibly open-source
The “Software-defined Network”
Simple Packet
Forwarding Hardware
Network
Operating
System 1
Open interface to hardware
Virtualization or “Slicing” Layer
Network
Operating
System 2
Network
Operating
System 3
Network
Operating
System 4
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Many operating systems, or
Many versions
Open interface to hardware
Isolated “slices”
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Consequences
More innovation in network services
 Owners, operators, 3rd
party developers, researchers can
improve the network
 E.g. energy management, data center management, policy
routing, access control, denial of service, mobility
Lower barrier to entry for competition
 Healthier market place, new players
Software defined network
Introduction
Motivation
Concept
Open Flow
Virtual Switch
Traditional network node:
Router Router can be partitioned into control and data plane
 Management plane/ configuration
 Control plane / Decision: OSPF (Open Shortest Path First)
 Data plane / Forwarding
Adjacent Router Router
Management/Policy plane
Configuration / CLI / GUIConfiguration / CLI / GUI
Static routesStatic routes
Control plane
OSPFOSPF
Neighbor table Link state database IP routing table
Forwarding table
Data planeData plane
Control plane
OSPFOSPF
Adjacent Router
Data plane
Control plane
OSPFOSPF
Routing
Switching
Traditional network node:
Switch
 Typical Networking Software
 Management plane
 Control Plane – The brain/decision maker
 Data Plane – Packet forwarder
SDN Concept
 Separate Control plane and Data plane entities
 Network intelligence and state are logically centralized
 The underlying network infrastructure is abstracted from
the applications
 Execute or run Control plane software on general
purpose hardware
 Decouple from specific networking hardware
 Use commodity servers
 Have programmable data planes
 Maintain, control and program data plane state from a
central entity
 An architecture to control not just a networking
device but an entire network
Control Program
Control program operates on view of network
 Input: global network view (graph/database)
 Output: configuration of each network device
Control program is not a distributed system
 Abstraction hides details of distributed state
Software-Defined Network
with key Abstractions in the
Control Plane
Network Operating SystemNetwork Operating System
RoutingRouting Traffic
Engineering
Traffic
Engineering
Other
Applications
Other
Applications
Well-defined API
Network Map
Abstraction
Forwarding
Forwarding
Forwarding
Forwarding
Separation of Data
and Control Plane
Network
Virtualization
Forwarding Abstraction
Purpose: Abstract away forwarding hardware
Flexible
 Behavior specified by control plane
 Built from basic set of forwarding primitives
Minimal
 Streamlined for speed and low-power
 Control program not vendor-specific
OpenFlow is an example of such an abstraction
OpenFlow Protocol
Data Path (Hardware)
Control Path
OpenFlo
w
Network OS
Control Program
A
Control Program
B
OpenFlow Basics
Control Program
A
Control Program
B
Network OS
OpenFlow Basics
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Flow
Table(s)
Flow
Table(s)
“If header = p, send to port 4”
“If header = ?, send to me”
“If header = q, overwrite header with r,
add header s, and send to ports 5,6”
Plumbing Primitives
<Match, Action>
Match arbitrary bits in headers:
 Match on any header, or new header
 Allows any flow granularity
Action
 Forward to port(s), drop, send to controller
 Overwrite header with mask, push or pop
 Forward at specific bit-rate
21
HeaderHeader DataData
Match: 1000x01xx0101001x
General Forwarding
Abstraction
Small set of primitives
“Forwarding instruction set”
Small set of primitives
“Forwarding instruction set”
Protocol independent
Backward compatible
Protocol independent
Backward compatible
Switches, routers, WiFi
APs, basestations,
TDM/WDM
Switches, routers, WiFi
APs, basestations,
TDM/WDM
Software defined network
Introduction
Motivation
Concept
Open Flow
Virtual Switch
What is OpenFlow
 OpenFlow is similar to an x86 instruction set for the
network
 Provide open interface to “black box” networking node
 (ie. Routers, L2/L3 switch) to enable visibility and openness
in network
 Separation of control plane and data plane.
 The datapath of an OpenFlow Switch consists of a Flow
Table, and an action associated with each flow entry
 The control path consists of a controller which programs the
flow entry in the flow table
 OpenFlow is based on an Ethernet switch, with an
internal flow-table, and a standardized interface to add
and remove flow entries
OpenFlow Consortium
http://OpenFlowSwitch.org
 Goal
 Evangelize OpenFlow to vendors
 Free membership for all researchers
 Whitepaper, OpenFlow Switch Specification, Reference Designs
 Licensing: Free for research and commercial use
OpenFlow building blocks
ControllerNOXNOX
Slicing
SoftwareFlowVisorFlowVisor
FlowVisor
Console
26
ApplicationsLAVILAVIENVI (GUI)ENVI (GUI) ExpedientExpedientn-Castingn-Casting
NetFPGANetFPGASoftware
Ref. Switch
Software
Ref. Switch
Broadcom
Ref. Switch
Broadcom
Ref. Switch
OpenWRTOpenWRT PCEngine
WiFi AP
PCEngine
WiFi AP
Commercial Switches Stanford Provided
OpenFlow
Switches
ONIXONIX
Stanford Provided
Monitoring/
debugging toolsoflopsoflopsoftraceoftrace openseeropenseer
Open vSwitchOpen vSwitch
HP, NEC, Pronto,
Juniper.. and
many more
HP, NEC, Pronto,
Juniper.. and
many more
BeaconBeacon TremaTrema MaestroMaestro
Components of OpenFlow
Network Controller
 OpenFlow protocol messages
 Controlled channel
 Processing
 Pipeline Processing
 Packet Matching
 Instructions & Action Set
 OpenFlow switch
 Secure Channel (SC)
 Flow Table
 Flow entry
OpenFlow Controllers
28
Name Lang Platform(s) License Original
Author
Notes
OpenFlow
Reference
C Linux OpenFlow
License
Stanford/Nici
ra
not designed for extensibility
NOX Python,
C++
Linux GPL Nicira actively developed
Beacon Java Win, Mac,
Linux,
Android
GPL (core),
FOSS Licenses
for your code
David
Erickson
(Stanford)
runtime modular, web UI
framework, regression test
framework
Maestro Java Win, Mac,
Linux
LGPL Zheng Cai
(Rice)
Trema Ruby, C Linux GPL NEC includes emulator, regression test
framework
RouteFlow ? Linux Apache CPqD (Brazil) virtual IP routing as a service
Secure Channel (SC)
 SC is the interface that connects each OpenFlow switch to
controller
 A controller configures and manages the switch via this
interface.
 Receives events from the switch
 Send packets out the switch
 SC establishes and terminates the connection between
OpneFlow Switch and the controller using the procedures
 Connection Setup
 Connection Interrupt
 The SC connection is a TLS connection. Switch and
controller mutually authenticate by exchanging
certificates signed by a site-specific private key.
Flow Table
 Flow table in switches, routers, and chipsets
Rule
(exact & wildcard)
Action Statistics
Rule
(exact & wildcard)
Action Statistics
Rule
(exact & wildcard)
Action Statistics
Rule
(exact & wildcard)
Default Action Statistics
Flow 1.
Flow 2.
Flow 3.
Flow N.
Flow Entry A flow entry consists of
 Match fields
 Match against packets
 Action
 Modify the action set or pipeline processing
 Stats
 Update the matching packets
Match Fields StatsAction
In Port
Src
MAC
Dst
MAC
Eth
Type
Vlan Id IP Tos
IP
Proto
IP Src IP Dst
TCP
Src
Port
TCP Dst
Port
Layer 2 Layer 3 Layer 4
1. Forward packet to port(s)
2. Encapsulate and forward to controller
3. Drop packet
4. Send to normal processing pipeline
1. Packet
2. Byte counters
Examples
32
Switching
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* 00:1f:.. * * * * * * * port6
Flow Switching
port3
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6
Firewall
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * * * * * * * 22 drop
Examples
33
Routing
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * * * * 5.6.7.8 * * * port6
VLAN Switching
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * vlan1 * * * * *
port6,
port7,
port9
00:1f..
OpenFlowSwitch.org
Controller
OpenFlow
Switch
PC
OpenFlow Usage
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Protocol
Peter’s code
Rule Action Statistics
Rule Action Statistics Rule Action Statistics
Peter
Usage examples
 Peter’s code:
 Static “VLANs”
 His own new routing protocol: unicast, multicast, multipath,
load-balancing
 Network access control
 Home network manager
 Mobility manager
 Energy manager
 Packet processor (in controller)
 IPvPeter
 Network measurement and visualization
 …
Separate VLANs for
Production and Research
Traffic
Normal L2/L3 Processing
Flow Table
Production VLANs
Research VLANs
Controller
Dynamic Flow Aggregation on an
OpenFlow Network Scope
 Different Networks want different flow granularity (ISP, Backbone,…)
 Switch resources are limited (flow entries, memory)
 Network management is hard
 Current Solutions : MPLS, IP aggregation
Dynamic Flow Aggregation on an
OpenFlow Network How do OpenFlow Help?
 Dynamically define flow granularity by wildcarding arbitrary header fields
 Granularity is on the switch flow entries, no packet rewrite or encapsulation
 Create meaningful bundles and manage them using your own software (reroute,
monitor)
Virtualizing OpenFlow
 Network operators “Delegate” control of subsets of
network hardware and/or traffic to other network
operators or users
 Multiple controllers can talk to the same set of switches
 Imagine a hypervisor for network equipments
 Allow experiments to be run on the network in isolation
of each other and production traffic
Switch Based Virtualization
Exists for NEC, HP switches but not flexible enough
40
Normal L2/L3 Processing
Flow Table
Production VLANs
Research VLAN 1
Controller
Research VLAN 2
Flow Table
Controller
FlowVisor
 A network hypervisor developed by Stanford
 A software proxy between the forwarding and control
planes of network devices
FlowVisor-based Virtualization
OpenFlow
Switch
OpenFlow
Protocol
OpenFlow FlowVisor
& Policy Control
Craig’s
Controller
Heidi’s
ControllerAaron’s
Controller
OpenFlow
Protocol
OpenFlow
Switch
OpenFlow
Switch
42
Topology
discovery is
per slice
Topology
discovery is
per slice
OpenFlow
Protocol
OpenFlow
FlowVisor & Policy Control
Broadcast
Multicast
OpenFlow
Protocol
http
Load-balancer
FlowVisor-based Virtualization
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
43
Separation not only
by VLANs, but any
L1-L4 pattern
Separation not only
by VLANs, but any
L1-L4 pattern
dl_dst=FFFFFFFFFFFF tp_src=80, or
tp_dst=80
FlowVisor Slicing
 Slices are defined using a slice definition policy
 The policy language specifies the slice’s resource limits, flowspace, and
controller’s location in terms of IP and TCP port-pair
 FlowVisor enforces transparency and isolation between slices by inspecting,
rewriting, and policing OpenFlow messages as they pass
FlowVisor Resource Limits
 FV assigns hardware resources to “Slices”
 Topology
 Network Device or Openflow Instance (DPID)
 Physical Ports
 Bandwidth
 Each slice can be assigned a per port queue with a fraction of the total bandwidth
 CPU
 Employs Course Rate Limiting techniques to keep new flow events from one slice
from overrunning the CPU
 Forwarding Tables
 Each slice has a finite quota of forwarding rules per device
Slicing
FlowVisor FlowSpace
 FlowSpace is defined by a collection of packet headers and assigned to
“Slices”
 Source/Destination MAC address
 VLAN ID
 Ethertype
 IP protocol
 Source/Destination IP address
 ToS/DSCP
 Source/Destination port number
FlowSpace: Maps Packets to
Slices
FlowVisor Slicing Policy
 FV intercepts OF messages from devices
 FV only sends control plane messages to the Slice
controller if the source device is in the Slice topology.
 Rewrites OF feature negotiation messages so the slice
controller only sees the ports in it’s slice
 Port up/down messages are pruned and only forwarded to
affected slices
FlowVisor Slicing Policy
 FV intercepts OF messages from controllers
 Rewrites flow insertion, deletion & modification rules so they don’t violate the
slice definition
 Flow definition – ex. Limit Control to HTTP traffic only
 Actions – ex. Limit forwarding to only ports in the slice
 Expand Flow rules into multiple rules to fit policy
 Flow definition – ex. If there is a policy for John’s HTTP traffic and another for Uwe’s
HTTP traffic, FV would expand a single rule intended to control all HTTP traffic into 2
rules.
 Actions – ex. Rule action is send out all ports. FV will create one rule for each port in
the slice.
 Returns “action is invalid” error if trying to control a port outside of the slice
FlowVisor Message Handling
OpenFlow
Firmware
Data Path
Alice
Controller
Bob
Controller
Cathy
Controller
FlowVisor
OpenFlow
OpenFlow
Packet
Exception
Policy Check:
Is this rule
allowed?
Policy Check:
Who controls
this packet?
Full Line Rate
Forwarding
Rule
Packet
Software defined network
Introduction
Motivation
Concept
Open Flow
Virtual Switch
INTRODUCTION
 Due to the cloud computing service, the number of virtual switches begins
to expand dramatically
 Management complexity, security issues and even performance degradation
 Software/hardware based virtual switches as well as integration of open-
source hypervisor with virtual switch technology is exhibited
53
Software-Based Virtual
Switch  The hypervisors implement vSwitch
 Each VM has at least one virtual
network interface cards (vNICs) and
shared physical network interface
cards (pNICs) on the physical host
through vSwitch
 Administrators don’t have effective
solution to separate packets from
different VM users
 For VMs reside in the same physical
machine, their traffic visibility is a big
issue
54
Issues of Traditional vSwitch
 The traditional vSwitches lack of advanced networking
features such as VLAN, port mirror, port channel, etc.
 Some hypervisor vSwitch vendors provide technologies
to fix the above problems
 OpenvSwitch may be superior in quality for the reasons
55
Open vSwitch
 A software-based solution
 Resolve the problems of network separation and traffic visibility, so the cloud
users can be assigned VMs with elastic and secure network configurations
 Flexible Controller in User-Space
 Fast Datapath in Kernel
Server
Open vSwitch Datapath
Open vSwitch Controller
Open vSwitch Concepts
 Multiple ports to physical switches
 A port may have one or more interfaces
 Bonding allows more than once interface per port
 Packets are forwarded by flow
 Visibility
 NetFlow
 sFlow
 Mirroring (SPAN/RSPAN/ERSPAN)
 IEEE 802.1Q Support
 Enable virtual LAN function
 By attaching VLAN ID to Linux virtual interfaces, each user will have its own
LAN environment separated from other users
Open vSwitch Concepts
 Fine-grained ACLs and QoS policies
 L2-­-L4 matching
 Actions to forward, drop, modify, and queue
 HTB and HFSC queuing disciplines
 Centralized control through OpenFlow
 Works on Linux-based hypervisors:
 Xen
 XenServer
 KVM
 VirtualBox
Open vSwitch
Contributors(Partial)
Packets are Managed as Flows
 A flow may be identied by any combination of
 Input port
 VLAN ID (802.1Q)
 Ethernet Source MAC address
 Ethernet Destination MAC address
 IP Source MAC address
 IP Destination MAC address
 TCP/UDP/... Source Port
 TCP/UDP/... Destination Port
Packets are Managed as Flows
 The 1st packet of a flow is sent to the controller
 The controller programs the datapath's actions for a flow
 Usually one, but may be a list
 Actions include:
 Forward to a port or ports
 mirror
 Encapsulate and forward to controller
 Drop
 And returns the packet to the datapath
 Subsequent packets are handled directly by the datapath
Migration
 KVM and Xen provide Live Migration
 With bridging, IP address migration must occur with in
the same L2 network
 Open vSwitch avoids this problem using GRE tunnels
Hardware-Based Virtual
Switch Why hardware-based?
 Software virtual switches consume CPU and memory usage
 Possible inconsistence of network and server configurations may cause errors
and is very hard to troubleshooting and maintenance
 Hardware-based virtual switch solution
emerges for better resource utilization and
configuration consistency
63
Virtual Ethernet Port Aggregator
 A standard led by HP, Extreme, IBM, Brocade, Juniper,
etc.
 An emerging technology as part of IEEE 802.1Qbg Edge
Virtual Bridge (EVB) standard
 The main goal of VEPA is to allow traffic of VMs to exit
and re-enter the same server physical port to enable
switching among VMs
64
Virtual Ethernet Port
Aggregator  VEPA software update is required
for host servers in order to force
packets to be transmitted to
external switches
 An external VEPA enabled switch
is required for communications
between VMs in the same server
 VEPA supports “hairpin” mode
which allows traffic to “hairpin”
back out the same port it just
received it from--- requires
firmware update to existing
switches
65
Pros. and Cons. for VEPA
 Pros
 Minor software/firmware update, network configuration
maintained by external switches
 Cons
 VEPA still consumes server resources in order to perform
forwarding table lookup
66
References "OpenFlow: Enabling Innovation in Campus Networks“ N. McKeown, T. Andershnan, G.
Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turneron, H. Balakris ACM Computer
Communication Review, Vol. 38, Issue 2, pp. 69-74 April 2008
 OpenFlow Switch Specication V 1.1.0.
 Richard Wang, Dana Butnariu, and Jennifer Rexford OpenFlow-based server load balancing
gone wild, Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise 66 IP
Infusion Proprietary and Confidential, released under Customer NDA , Roadmap items
subject to change without notice © 2011 IP Infusion Inc. gone wild, Workshop on Hot
Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE),
Boston, MA, March 2011.
 Saurav Das, Guru Parulkar, Preeti Singh, Daniel Getachew, Lyndon Ong, Nick McKeown,
Packet and Circuit Network Convergence with OpenFlow, Optical Fiber Conference
(OFC/NFOEC'10), San Diego, March 2010
 Nikhil Handigol, Srini Seetharaman, Mario Flajslik, Nick McKeown, Ramesh Johari, Plug-n-
Serve: Load-Balancing Web Traffic using OpenFlow, ACM SIGCOMM Demo, Aug 2009.
 NOX: Towards an Operating System for Networks
 https://sites.google.com/site/routeflow/home
 http://www.openflow.org/
 http://www.opennetsummit.org/
 https://www.opennetworking.org/
 http://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p195.pdf
 http://searchnetworking.techtarget.com/
References
 Network Virtualization with Cloud Virtual Switch
 S. Horman, “An Introduction to Open vSwitch,” LinuxCon Japan, Yokohama,
Jun. 2, 2011.
 J. Pettit, J. Gross “Open vSwitch Overview,” Linux Collaboration Summit,
San Francisco, Apr. 7, 2011.
 J. Pettit, “Open vSwitch: A Whirlwind Tour,” Mar. 3, 2011.
 Access Layer Network Virtualization: VN-Tag and VEPA
 OpenFlow Tutorial

Software defined network and Virtualization

  • 1.
    Virtualization TechniquesVirtualization Techniques NetworkVirtualization Software Defined Network Rajeev TiwariRajeev Tiwari Software ArchitectSoftware Architect
  • 2.
  • 3.
    Million of lines ofsource code 5400 RFCs Barrier to entry 500M gates 10Gbytes RAM Bloated Power Hungry Many complex functions baked into the infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … An industry with a “mainframe-mentality” We have lost our way Specialized Packet Forwarding Hardware Operating System App App App Routing, management, mobility management, access control, VPNs, …
  • 4.
    Operating SystemOperating System Reality App App App SpecializedPacket Forwarding Hardware Specialized Packet Forwarding Hardware Specialized Packet Forwarding Hardware Operating System App App App • Lack of competition means glacial innovation • Closed architecture means blurry, closed interfaces • Vertically integrated, complex, closed, proprietary • Not suitable for experimental ideas • Not good for network owners & users • Not good for researchers
  • 5.
    Glacial process ofinnovation made worse by captive standards process Deployment Idea Standardize Wait 10 years • Driven by vendors • Consumers largely locked out • Lowest common denominator features • Glacial innovation
  • 6.
  • 7.
    Windows (OS) Windows (OS) Linux Mac OS x86 (Computer) Windows (OS) AppApp LinuxLinux Mac OS Mac OS Virtualization layer App Controller 1 AppApp Controller 2 Virtualization or“Slicing” App OpenFlow Controller 1 NOX (Network OS) Controller 2Network OS Trend Computer Industry Network Industry
  • 8.
    Specialized Packet Forwarding Hardware Ap p Ap p Ap p SpecializedPacket Forwarding Hardware Ap p Ap p Ap p Specialized Packet Forwarding Hardware Ap p Ap p Ap p Specialized Packet Forwarding Hardware Ap p Ap p Ap p Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System Ap p Ap p Ap p Network Operating System App App App The “Software-defined Network”
  • 9.
    App Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware SimplePacket Forwarding Hardware App App Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Network Operating System 1. Open interface to hardware 3. Well-defined open API 2. At least one good operating system Extensible, possibly open-source The “Software-defined Network”
  • 10.
    Simple Packet Forwarding Hardware Network Operating System1 Open interface to hardware Virtualization or “Slicing” Layer Network Operating System 2 Network Operating System 3 Network Operating System 4 Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Many operating systems, or Many versions Open interface to hardware Isolated “slices” Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware
  • 11.
    Consequences More innovation innetwork services  Owners, operators, 3rd party developers, researchers can improve the network  E.g. energy management, data center management, policy routing, access control, denial of service, mobility Lower barrier to entry for competition  Healthier market place, new players
  • 12.
  • 13.
    Traditional network node: RouterRouter can be partitioned into control and data plane  Management plane/ configuration  Control plane / Decision: OSPF (Open Shortest Path First)  Data plane / Forwarding Adjacent Router Router Management/Policy plane Configuration / CLI / GUIConfiguration / CLI / GUI Static routesStatic routes Control plane OSPFOSPF Neighbor table Link state database IP routing table Forwarding table Data planeData plane Control plane OSPFOSPF Adjacent Router Data plane Control plane OSPFOSPF Routing Switching
  • 14.
    Traditional network node: Switch Typical Networking Software  Management plane  Control Plane – The brain/decision maker  Data Plane – Packet forwarder
  • 15.
    SDN Concept  SeparateControl plane and Data plane entities  Network intelligence and state are logically centralized  The underlying network infrastructure is abstracted from the applications  Execute or run Control plane software on general purpose hardware  Decouple from specific networking hardware  Use commodity servers  Have programmable data planes  Maintain, control and program data plane state from a central entity  An architecture to control not just a networking device but an entire network
  • 16.
    Control Program Control programoperates on view of network  Input: global network view (graph/database)  Output: configuration of each network device Control program is not a distributed system  Abstraction hides details of distributed state
  • 17.
    Software-Defined Network with keyAbstractions in the Control Plane Network Operating SystemNetwork Operating System RoutingRouting Traffic Engineering Traffic Engineering Other Applications Other Applications Well-defined API Network Map Abstraction Forwarding Forwarding Forwarding Forwarding Separation of Data and Control Plane Network Virtualization
  • 18.
    Forwarding Abstraction Purpose: Abstractaway forwarding hardware Flexible  Behavior specified by control plane  Built from basic set of forwarding primitives Minimal  Streamlined for speed and low-power  Control program not vendor-specific OpenFlow is an example of such an abstraction
  • 19.
    OpenFlow Protocol Data Path(Hardware) Control Path OpenFlo w Network OS Control Program A Control Program B OpenFlow Basics
  • 20.
    Control Program A Control Program B NetworkOS OpenFlow Basics Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Flow Table(s) Flow Table(s) “If header = p, send to port 4” “If header = ?, send to me” “If header = q, overwrite header with r, add header s, and send to ports 5,6”
  • 21.
    Plumbing Primitives <Match, Action> Matcharbitrary bits in headers:  Match on any header, or new header  Allows any flow granularity Action  Forward to port(s), drop, send to controller  Overwrite header with mask, push or pop  Forward at specific bit-rate 21 HeaderHeader DataData Match: 1000x01xx0101001x
  • 22.
    General Forwarding Abstraction Small setof primitives “Forwarding instruction set” Small set of primitives “Forwarding instruction set” Protocol independent Backward compatible Protocol independent Backward compatible Switches, routers, WiFi APs, basestations, TDM/WDM Switches, routers, WiFi APs, basestations, TDM/WDM
  • 23.
  • 24.
    What is OpenFlow OpenFlow is similar to an x86 instruction set for the network  Provide open interface to “black box” networking node  (ie. Routers, L2/L3 switch) to enable visibility and openness in network  Separation of control plane and data plane.  The datapath of an OpenFlow Switch consists of a Flow Table, and an action associated with each flow entry  The control path consists of a controller which programs the flow entry in the flow table  OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries
  • 25.
    OpenFlow Consortium http://OpenFlowSwitch.org  Goal Evangelize OpenFlow to vendors  Free membership for all researchers  Whitepaper, OpenFlow Switch Specification, Reference Designs  Licensing: Free for research and commercial use
  • 26.
    OpenFlow building blocks ControllerNOXNOX Slicing SoftwareFlowVisorFlowVisor FlowVisor Console 26 ApplicationsLAVILAVIENVI(GUI)ENVI (GUI) ExpedientExpedientn-Castingn-Casting NetFPGANetFPGASoftware Ref. Switch Software Ref. Switch Broadcom Ref. Switch Broadcom Ref. Switch OpenWRTOpenWRT PCEngine WiFi AP PCEngine WiFi AP Commercial Switches Stanford Provided OpenFlow Switches ONIXONIX Stanford Provided Monitoring/ debugging toolsoflopsoflopsoftraceoftrace openseeropenseer Open vSwitchOpen vSwitch HP, NEC, Pronto, Juniper.. and many more HP, NEC, Pronto, Juniper.. and many more BeaconBeacon TremaTrema MaestroMaestro
  • 27.
    Components of OpenFlow NetworkController  OpenFlow protocol messages  Controlled channel  Processing  Pipeline Processing  Packet Matching  Instructions & Action Set  OpenFlow switch  Secure Channel (SC)  Flow Table  Flow entry
  • 28.
    OpenFlow Controllers 28 Name LangPlatform(s) License Original Author Notes OpenFlow Reference C Linux OpenFlow License Stanford/Nici ra not designed for extensibility NOX Python, C++ Linux GPL Nicira actively developed Beacon Java Win, Mac, Linux, Android GPL (core), FOSS Licenses for your code David Erickson (Stanford) runtime modular, web UI framework, regression test framework Maestro Java Win, Mac, Linux LGPL Zheng Cai (Rice) Trema Ruby, C Linux GPL NEC includes emulator, regression test framework RouteFlow ? Linux Apache CPqD (Brazil) virtual IP routing as a service
  • 29.
    Secure Channel (SC) SC is the interface that connects each OpenFlow switch to controller  A controller configures and manages the switch via this interface.  Receives events from the switch  Send packets out the switch  SC establishes and terminates the connection between OpneFlow Switch and the controller using the procedures  Connection Setup  Connection Interrupt  The SC connection is a TLS connection. Switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key.
  • 30.
    Flow Table  Flowtable in switches, routers, and chipsets Rule (exact & wildcard) Action Statistics Rule (exact & wildcard) Action Statistics Rule (exact & wildcard) Action Statistics Rule (exact & wildcard) Default Action Statistics Flow 1. Flow 2. Flow 3. Flow N.
  • 31.
    Flow Entry Aflow entry consists of  Match fields  Match against packets  Action  Modify the action set or pipeline processing  Stats  Update the matching packets Match Fields StatsAction In Port Src MAC Dst MAC Eth Type Vlan Id IP Tos IP Proto IP Src IP Dst TCP Src Port TCP Dst Port Layer 2 Layer 3 Layer 4 1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet 4. Send to normal processing pipeline 1. Packet 2. Byte counters
  • 32.
    Examples 32 Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * 00:1f:.. ** * * * * * port6 Flow Switching port3 Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action 00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * * * * * * * 22 drop
  • 33.
    Examples 33 Routing * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * ** * 5.6.7.8 * * * port6 VLAN Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * vlan1 * * * * * port6, port7, port9 00:1f..
  • 34.
  • 35.
    Usage examples  Peter’scode:  Static “VLANs”  His own new routing protocol: unicast, multicast, multipath, load-balancing  Network access control  Home network manager  Mobility manager  Energy manager  Packet processor (in controller)  IPvPeter  Network measurement and visualization  …
  • 36.
    Separate VLANs for Productionand Research Traffic Normal L2/L3 Processing Flow Table Production VLANs Research VLANs Controller
  • 37.
    Dynamic Flow Aggregationon an OpenFlow Network Scope  Different Networks want different flow granularity (ISP, Backbone,…)  Switch resources are limited (flow entries, memory)  Network management is hard  Current Solutions : MPLS, IP aggregation
  • 38.
    Dynamic Flow Aggregationon an OpenFlow Network How do OpenFlow Help?  Dynamically define flow granularity by wildcarding arbitrary header fields  Granularity is on the switch flow entries, no packet rewrite or encapsulation  Create meaningful bundles and manage them using your own software (reroute, monitor)
  • 39.
    Virtualizing OpenFlow  Networkoperators “Delegate” control of subsets of network hardware and/or traffic to other network operators or users  Multiple controllers can talk to the same set of switches  Imagine a hypervisor for network equipments  Allow experiments to be run on the network in isolation of each other and production traffic
  • 40.
    Switch Based Virtualization Existsfor NEC, HP switches but not flexible enough 40 Normal L2/L3 Processing Flow Table Production VLANs Research VLAN 1 Controller Research VLAN 2 Flow Table Controller
  • 41.
    FlowVisor  A networkhypervisor developed by Stanford  A software proxy between the forwarding and control planes of network devices
  • 42.
    FlowVisor-based Virtualization OpenFlow Switch OpenFlow Protocol OpenFlow FlowVisor &Policy Control Craig’s Controller Heidi’s ControllerAaron’s Controller OpenFlow Protocol OpenFlow Switch OpenFlow Switch 42 Topology discovery is per slice Topology discovery is per slice
  • 43.
    OpenFlow Protocol OpenFlow FlowVisor & PolicyControl Broadcast Multicast OpenFlow Protocol http Load-balancer FlowVisor-based Virtualization OpenFlow Switch OpenFlow Switch OpenFlow Switch 43 Separation not only by VLANs, but any L1-L4 pattern Separation not only by VLANs, but any L1-L4 pattern dl_dst=FFFFFFFFFFFF tp_src=80, or tp_dst=80
  • 44.
    FlowVisor Slicing  Slicesare defined using a slice definition policy  The policy language specifies the slice’s resource limits, flowspace, and controller’s location in terms of IP and TCP port-pair  FlowVisor enforces transparency and isolation between slices by inspecting, rewriting, and policing OpenFlow messages as they pass
  • 45.
    FlowVisor Resource Limits FV assigns hardware resources to “Slices”  Topology  Network Device or Openflow Instance (DPID)  Physical Ports  Bandwidth  Each slice can be assigned a per port queue with a fraction of the total bandwidth  CPU  Employs Course Rate Limiting techniques to keep new flow events from one slice from overrunning the CPU  Forwarding Tables  Each slice has a finite quota of forwarding rules per device
  • 46.
  • 47.
    FlowVisor FlowSpace  FlowSpaceis defined by a collection of packet headers and assigned to “Slices”  Source/Destination MAC address  VLAN ID  Ethertype  IP protocol  Source/Destination IP address  ToS/DSCP  Source/Destination port number
  • 48.
  • 49.
    FlowVisor Slicing Policy FV intercepts OF messages from devices  FV only sends control plane messages to the Slice controller if the source device is in the Slice topology.  Rewrites OF feature negotiation messages so the slice controller only sees the ports in it’s slice  Port up/down messages are pruned and only forwarded to affected slices
  • 50.
    FlowVisor Slicing Policy FV intercepts OF messages from controllers  Rewrites flow insertion, deletion & modification rules so they don’t violate the slice definition  Flow definition – ex. Limit Control to HTTP traffic only  Actions – ex. Limit forwarding to only ports in the slice  Expand Flow rules into multiple rules to fit policy  Flow definition – ex. If there is a policy for John’s HTTP traffic and another for Uwe’s HTTP traffic, FV would expand a single rule intended to control all HTTP traffic into 2 rules.  Actions – ex. Rule action is send out all ports. FV will create one rule for each port in the slice.  Returns “action is invalid” error if trying to control a port outside of the slice
  • 51.
    FlowVisor Message Handling OpenFlow Firmware DataPath Alice Controller Bob Controller Cathy Controller FlowVisor OpenFlow OpenFlow Packet Exception Policy Check: Is this rule allowed? Policy Check: Who controls this packet? Full Line Rate Forwarding Rule Packet
  • 52.
  • 53.
    INTRODUCTION  Due tothe cloud computing service, the number of virtual switches begins to expand dramatically  Management complexity, security issues and even performance degradation  Software/hardware based virtual switches as well as integration of open- source hypervisor with virtual switch technology is exhibited 53
  • 54.
    Software-Based Virtual Switch The hypervisors implement vSwitch  Each VM has at least one virtual network interface cards (vNICs) and shared physical network interface cards (pNICs) on the physical host through vSwitch  Administrators don’t have effective solution to separate packets from different VM users  For VMs reside in the same physical machine, their traffic visibility is a big issue 54
  • 55.
    Issues of TraditionalvSwitch  The traditional vSwitches lack of advanced networking features such as VLAN, port mirror, port channel, etc.  Some hypervisor vSwitch vendors provide technologies to fix the above problems  OpenvSwitch may be superior in quality for the reasons 55
  • 56.
    Open vSwitch  Asoftware-based solution  Resolve the problems of network separation and traffic visibility, so the cloud users can be assigned VMs with elastic and secure network configurations  Flexible Controller in User-Space  Fast Datapath in Kernel Server Open vSwitch Datapath Open vSwitch Controller
  • 57.
    Open vSwitch Concepts Multiple ports to physical switches  A port may have one or more interfaces  Bonding allows more than once interface per port  Packets are forwarded by flow  Visibility  NetFlow  sFlow  Mirroring (SPAN/RSPAN/ERSPAN)  IEEE 802.1Q Support  Enable virtual LAN function  By attaching VLAN ID to Linux virtual interfaces, each user will have its own LAN environment separated from other users
  • 58.
    Open vSwitch Concepts Fine-grained ACLs and QoS policies  L2-­-L4 matching  Actions to forward, drop, modify, and queue  HTB and HFSC queuing disciplines  Centralized control through OpenFlow  Works on Linux-based hypervisors:  Xen  XenServer  KVM  VirtualBox
  • 59.
  • 60.
    Packets are Managedas Flows  A flow may be identied by any combination of  Input port  VLAN ID (802.1Q)  Ethernet Source MAC address  Ethernet Destination MAC address  IP Source MAC address  IP Destination MAC address  TCP/UDP/... Source Port  TCP/UDP/... Destination Port
  • 61.
    Packets are Managedas Flows  The 1st packet of a flow is sent to the controller  The controller programs the datapath's actions for a flow  Usually one, but may be a list  Actions include:  Forward to a port or ports  mirror  Encapsulate and forward to controller  Drop  And returns the packet to the datapath  Subsequent packets are handled directly by the datapath
  • 62.
    Migration  KVM andXen provide Live Migration  With bridging, IP address migration must occur with in the same L2 network  Open vSwitch avoids this problem using GRE tunnels
  • 63.
    Hardware-Based Virtual Switch Whyhardware-based?  Software virtual switches consume CPU and memory usage  Possible inconsistence of network and server configurations may cause errors and is very hard to troubleshooting and maintenance  Hardware-based virtual switch solution emerges for better resource utilization and configuration consistency 63
  • 64.
    Virtual Ethernet PortAggregator  A standard led by HP, Extreme, IBM, Brocade, Juniper, etc.  An emerging technology as part of IEEE 802.1Qbg Edge Virtual Bridge (EVB) standard  The main goal of VEPA is to allow traffic of VMs to exit and re-enter the same server physical port to enable switching among VMs 64
  • 65.
    Virtual Ethernet Port Aggregator VEPA software update is required for host servers in order to force packets to be transmitted to external switches  An external VEPA enabled switch is required for communications between VMs in the same server  VEPA supports “hairpin” mode which allows traffic to “hairpin” back out the same port it just received it from--- requires firmware update to existing switches 65
  • 66.
    Pros. and Cons.for VEPA  Pros  Minor software/firmware update, network configuration maintained by external switches  Cons  VEPA still consumes server resources in order to perform forwarding table lookup 66
  • 67.
    References "OpenFlow: EnablingInnovation in Campus Networks“ N. McKeown, T. Andershnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turneron, H. Balakris ACM Computer Communication Review, Vol. 38, Issue 2, pp. 69-74 April 2008  OpenFlow Switch Specication V 1.1.0.  Richard Wang, Dana Butnariu, and Jennifer Rexford OpenFlow-based server load balancing gone wild, Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise 66 IP Infusion Proprietary and Confidential, released under Customer NDA , Roadmap items subject to change without notice © 2011 IP Infusion Inc. gone wild, Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE), Boston, MA, March 2011.  Saurav Das, Guru Parulkar, Preeti Singh, Daniel Getachew, Lyndon Ong, Nick McKeown, Packet and Circuit Network Convergence with OpenFlow, Optical Fiber Conference (OFC/NFOEC'10), San Diego, March 2010  Nikhil Handigol, Srini Seetharaman, Mario Flajslik, Nick McKeown, Ramesh Johari, Plug-n- Serve: Load-Balancing Web Traffic using OpenFlow, ACM SIGCOMM Demo, Aug 2009.  NOX: Towards an Operating System for Networks  https://sites.google.com/site/routeflow/home  http://www.openflow.org/  http://www.opennetsummit.org/  https://www.opennetworking.org/  http://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p195.pdf  http://searchnetworking.techtarget.com/
  • 68.
    References  Network Virtualizationwith Cloud Virtual Switch  S. Horman, “An Introduction to Open vSwitch,” LinuxCon Japan, Yokohama, Jun. 2, 2011.  J. Pettit, J. Gross “Open vSwitch Overview,” Linux Collaboration Summit, San Francisco, Apr. 7, 2011.  J. Pettit, “Open vSwitch: A Whirlwind Tour,” Mar. 3, 2011.  Access Layer Network Virtualization: VN-Tag and VEPA  OpenFlow Tutorial

Editor's Notes

  • #27 There are components at different levels that work together in making it work The commercial switch details will follow in next slide There are a plethora of applications possible. I only list those available at Stanford
  • #29 Language open-source Performance cross-platform runtime modular
  • #41 Experiments running on PRODUCTION infrastructure Key to get scale, key to get traffic on the network (e.g. can’t just do a reset...)
  • #47 Carves Network into “Slices” and Assigns hardware resources to each slice. Switch DPID, Port.