Download CH4-SDNbasics

Outline
• SDN Basics
– Concepts
– OpenFlow
– Controller
– OF-Config
– Mininet
9/10/13
Software Defined Networking (COMS 6998-8)
1
SDN
• For now: a new paradigm for network
management
• SDN widely accepted as “future of
networking”
– ~1000 engineers at latest Open Networking
Summit
– Commercialized, in production use (few places)
• E.g., controls Google’s WAN; NTT moving to deploy
– Much more acceptance in industry than in
academia
Building an Artifact, Not a Discipline
• Other fields in “systems”: OS, DB, etc.
– Teach basic principles
– Are easily managed
– Continue to evolve
• Networking:
–
–
–
–
Study of an artifact: the Internet
Teach (mostly) big bag of protocols
Notoriously difficult to manage
Evolves very slowly
• Networks are much more primitive and less
understood than other computer systems
What is Network Management?
• Recall the two “planes”
• Data plane: forwarding packets
– Based on local forwarding state
• Control plane: computing that forwarding
state
– Involves coordination with rest of system
• Broad definition of “network management”:
– Everything having to do with the control plane
Original goals for the control plane
• Basic connectivity: route packets to
destination
– Local state computed by routing protocols
– Globally distributed algorithms
• Interdomain policy: find policy-compliant
paths
– Done by fully distributed BGP
• For long time, these were the only relevant
goals!
– What other goals are there in running a network?
Also
•
•
•
•
Isolation
Access Control
Traffic Engineering
…
Isolation
• Want multiple LANs on single physical network
• Packets on LAN don’t pass through routers
– But routers used to impose various controls (later)
• Use VLANs (virtual LANs) tags in L2 headers
– Controls where broadcast packets go
– Gives support for logical L2 networks
– Routers connect these logical L2 networks
• No universal method for setting VLAN state
Access Control
• Operators want to limit access to various
hosts
– Don’t let laptops access backend database
machines
• This can be imposed by routers using ACLs
– ACL: Access control list
• Example entry in ACL: <header template;
drop>
Summarizing
• Network management has many goals
• Achieving these goals is job of the control
plane…
• …which currently involves many mechanisms
Control Plane Mechanisms
• Many different control plane mechanisms
• Designed from scratch for specific goal
• Variety of implementations
– Globally distributed: routing algorithms
– Manual/scripted configuration: ACLs, VLANs
– Centralized computation: Traffic engineering
How Have We Managed To Survive?
• Net. admins miraculously master this
complexity
– Understand all aspects of networks
– Must keep numerus details in mind
• This ability to master complexity is both a
blessing
– …and a curse!
Mastering Complexity versus
Extracting Simplicity
• The ability to master complexity is valuable
– But not the same as the ability to extract simplicity
• Each has its role:
– When first getting systems to work, master
complexity
– When making system easy to use, extract simplicity
• You will never succeed in extracting simplicity
– If you don’t recognize it is a different skill set than
mastering complexity
Mastering Complexity versus
Extracting Simplicity
• Networking has never made the distinction…
– And therefore has never made the transition from
mastering complexity to extracting simplicity
• Still focused on mastering complexity
– Networking “experts” are those that know all the
details
• Extracting simplicity lays intellectual foundations
– This is why networking has weak foundation
– We are still building the artifact, not the discipline
Why make the transition
• Complexity has increased to
“unmanageable” levels
• Consider datacenters:
– 100,000s machines, 10,000s switches
– 1000s of customers
• Each with their own logical networks: ACLs,
VLANs, etc
• Way beyond what we can handle
– Leads to brittle, ossify (harden) configurations
– Probably inefficient too
An Example Transition: Programming
• Machine languages: no abstractions
– Had to deal with low-level details
– Mastering complexity was crucial
• Higher-level languages: OS and other abstractions
– File system, virtual memory, abstract data types, ...
• Modern languages: even more abstractions
– Object orientation, garbage collection,...
Abstractions key to extracting simplicity
“The Power of Abstraction”
“Modularity based on abstraction
is the way things get done”
−
Barbara Liskov
Abstractions  Interfaces  Modularity
What About Networking Abstractions?
• Consider the data and control planes
separately
• Different tasks, so naturally different
abstractions
Abstractions for Data Plane: Layers
Applications
…built on…
Reliable (or unreliable) transport
…built on…
Best-effort global packet delivery
…built on…
Best-effort local packet delivery
…built on…
Physical transfer of bits
The Importance of Layering
• Decomposed delivery into basic components
• Independent, compatible innovation at each
layer
– Clean “separation of concerns”
– Leaving each layer to solve a tractable problem
• Responsible for the success of the Internet!
– Rich ecosystem of independent innovation
Finding Control Plane
Abstractions
How do you find abstractions?
• You first decompose the problem….
• …and define abstractions for each subproblem
• So what is the control plane problem?
21
Task: Compute forwarding state:
• Consistent with low-level
hardware/software
– Which might depend on particular vendor
• Based on entire network topology
– Because many control decisions depend on
topology
• For all routers/switches in network
– Every router/switch needs forwarding state
current approach
• Design one-off mechanisms that solve all three
– A sign of how much we love complexity
• No other field would deal with such a problem!
• They would define abstractions for each subtask
• …and so should we!
Separate Concerns with Abstractions
1. Be compatible with low-level
hardware/software
Need an abstraction for general forwarding model
2. Make decisions based on entire network
Need an abstraction for network state
1. Compute configuration of each physical device
Need an abstraction that simplifies configuration
Abs#1: Forwarding Abstraction
• Express intent independent of
implementation
– Don’t want to deal with proprietary HW and SW
• OpenFlow is current proposal for forwarding
– Standardized interface to switch
– Configuration in terms of flow entries: <header,
action>
• Design details concern exact nature of:
– Header matching
– Allowed actions
Two Important Facets to OpenFlow
• Switches accept external control messages
– Not closed, proprietary boxes
• Standardized flow entry format
– So switches are interchangeable
26
Abs#2: Network State Abstraction
• Abstraction: global network view
– Annotated network graph provided through an API
• Implementation: “Network Operating System”
– Runs on servers in network (“controllers”)
– Replicated for reliability
• Information flows both ways
– Information from routers/switches to form “view”
– Configurations to routers/switches to control
forwarding
Network Operating System
• Think of it as a centralized link-state
algorithm
• Switches send connectivity info to controller
• Controller computes forwarding state
– Some control program that uses the topology as
input
• Controller sends forwarding state to switches
• Controller is replicated for resilience
– System is only “logically centralized”
28
Network of Switches and/or Routers
Traditional Control Mechanisms
Distributed algorithm running between neighbors
Complicated task-specific distributed algorithm
Software Defined Network (SDN)
routing, access control, etc.
Control Program
Global Network View
Network OS
Major Change in Paradigm
• Control program:
– Configuration = Function(view)
• Control mechanism now program using
NOS API
• Not a distributed protocol, just a graph
algorithm
32
Abs#3: Specification Abstraction
• Control mechanism expresses desired behavior
– Whether it be isolation, access control, or QoS
• It should not be responsible for implementing
that behavior on physical network infrastructure
– Requires configuring the forwarding tables in each
switch
• Proposed abstraction: abstract view of network
– Abstract view models only enough detail to specify
goals
– Will depend on task semantics
Simple Example: Access Control
A
B
Abstract
Network
View
A
Global
Network
View
B
Routing
• Look at graph of network
• Compute routes
• Give to SDN platform, which passes on to
switches
35
Access Control
• Control program decides who can talk to who
• Pass this information to SDN platform
• Appropriate ACL flow entries are added to
network
– In the right places (based on the topology)
36
Software Defined Network
Abstract Network View
Virtualization
Layer
Control Program
Global Network View
Network OS
Clean Separation of Concerns
• Control program: express goals on abstract view
– Driven by Operator Requirements
• Virtualization Layer: abstract view  global
view
– Driven by Specification Abstraction for particular task
• NOS: global view  physical switches
– API: driven by Network State Abstraction
– Switch interface: driven by Forwarding Abstraction
38
SDN: Layers for the Control Plane
Control Program
Abstract Network View
Network Virtualization
Global Network View
Network OS
Abstractions for Control Plane
Expression of Intent
…built on…
Abstract Network View
…built on…
Global Network View
…built on…
Physical Topology
Abstractions Don’t Remove Complexity
• NOS, Virtualization are complicated pieces of code
• SDN merely localizes the complexity:
– Simplifies interface for control program (user-specific)
– Pushes complexity into reusable code (SDN platform)
• This is the big payoff of SDN: modularity!
– The core distribution mechanisms can be reused
– Control programs only deal with their specific function
• Note that SDN separates control and data planes
– SDN platform does control plane, switches do data plane
Separation of Control/Data Plane
• Today, routers implement both
– They forward packets
– And run the control plane software
• SDN networks
– Data plane implemented by switches
• Switches act on local forwarding state
– Control plane implemented by controllers
• All forwarding state computed by SDN platform
• This is a technical change, with broad
implications
42
Changes
• Less vendor lock-in
– Can buy HW/SF from different vendors
• Changes are easier
– Can test components separately
• HW has to forward
• Can simulate controller
• Can do verification on logical policy
– Can change topology and policy independently
– Can move from private net to cloud and back!
– Greater rate of innovation
Source: Nick Mckeown, Stanford
AppAppAppAppAppAppAppAppAppAppApp
Specialized
Applications
Specialized
Operating
System
Specialized
Hardware
Vertically integrated
Closed, proprietary
Slow innovation
9/10/13
Small industry
Open Interface
Windows
(OS)
or
Linux
or
Mac
OS
Open Interface
Microprocessor
Horizontal
Open interfaces
Rapid innovation
Software Defined Networking (COMS 6998-8)
Huge industry 44
Source: Nick Mckeown, Stanford
AppAppAppAppAppAppAppAppAppAppApp
Specialized
Features
Specialized
Control
Plane
Open Interface
Control
Plane
9/10/13
Control
Plane
or
Control
Plane
Open Interface
Merchant
Switching Chips
Specialized
Hardware
Vertically integrated
Closed, proprietary
Slow innovation
or
Horizontal
Open interfaces
Rapid innovation
Software Defined Networking (COMS 6998-8)
45
Source: Nick Mckeown, Stanford
Routing, management, mobility management,
access control, VPNs, …
Feature
Feature
Million of lines
of source code
6,000 RFCs
Billions of gates
Bloated
OS
Custom Hardware
Power Hungry
• Vertically integrated, complex, closed,
proprietary
• Networking industry with “mainframe” mind-set
9/10/13
Software Defined Networking (COMS 6998-8)
46
Source: Nick Mckeown, Stanford
The network is changing
Feature
Feature
Network OS
Feature
Feature
OS
Feature
Feature
Custom Hardware
OS
Feature
Feature
Custom Hardware
OS
Feature
Custom Hardware
Feature
OS
Feature
Feature
Custom Hardware
OS
9/10/13
Custom Hardware
Software Defined Networking (COMS 6998-8)
47
Source: Nick Mckeown, Stanford
Software Defined Network (SDN)
3. Consistent, up-to-date global network view
Feature
Feature
2. At least one Network OS
probably many.
Open- and closed-source
Network OS
1. Open interface to packet forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
9/10/13
Software Defined Networking (COMS 6998-8)
48
Network OS
Source: Nick Mckeown, Stanford
Network OS: distributed system that creates a
consistent, up-to-date network view
– Runs on servers (controllers) in the network
– Floodlight, POX, Pyretic, Nettle ONIX, Beacon, … +
more
Uses forwarding abstraction to:
– Get state information from forwarding elements
– Give control directives to forwarding elements
9/10/13
Software Defined Networking (COMS 6998-8)
49
Source: Nick Mckeown, Stanford
Software Defined Network (SDN)
Control Program A
Control Program B
Network OS
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
9/10/13
Software Defined Networking (COMS 6998-8)
50
Source: Nick Mckeown, Stanford
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
9/10/13
Software Defined Networking (COMS 6998-8)
51
Source: Nick Mckeown, Stanford
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
9/10/13
Software Defined Networking (COMS 6998-8)
52
Source: Nick Mckeown, Stanford
By comparison: Programming
Machine languages: no abstractions
– Had to deal with low-level details
Higher-level languages: OS and other
abstractions
– File system, virtual memory, abstract data types,
...
Modern languages: even more abstractions
– Object orientation, garbage collection,…
9/10/13
Software Defined Networking (COMS 6998-8)
53
Source: Nick Mckeown, Stanford
Programming Analogy
What if programmers had to:
– Specify where each bit was stored
– Explicitly deal with internal communication errors
– Within a programming language with limited
expressability
Programmers would redefine problem by:
– Defining higher level abstractions for memory
– Building on reliable communication primitives
– Using a more general language
9/10/13
Software Defined Networking (COMS 6998-8)
54
Source: Nick Mckeown, Stanford
Specification Abstraction
Network OS eases implementation
Next step is to ease specification
Provide abstract view of network map
Control program operates on abstract view
Develop means to simplify specification
9/10/13
Software Defined Networking (COMS 6998-8)
55
Source: Nick Mckeown, Stanford
Software Defined Network (SDN)
Abstract Network View
Virtualization
Control Program
A Control Program B
Global Network View
Network OS
Packet
Forwarding
Packet
Forwarding
9/10/13
Packet
Forwarding
Packet
Forwarding
Packet
Software Defined Networking (COMS 6998-8)
Forwarding
56
Outline
• Review of previous lecture
• SDN Basics
– Concepts
– OpenFlow
– Switches and Controllers
– OF-Config
– Mininet
9/10/13
Software Defined Networking (COMS 6998-8)
57
OpenFlow
• Why OpenFlow?
• How does OpenFlow work?
9/10/13
Software Defined Networking (COMS 6998-8)
58
Why OpenFlow?
9/10/13
Software Defined Networking (COMS 6998-8)
59
The Ossified Network
Routing, management, mobility management,
access control, VPNs, …
Feature
Feature
Operating
System
Specialized Packet
Forwarding Hardware
Million of lines
of source code
5400 RFCs
Barrier to entry
Billions of gates
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”, reluctant to change
9/10/13
Software Defined Networking (COMS 6998-8)
60
Research Stagnation
• Lots of deployed innovation in other areas
– OS: filesystems, schedulers, virtualization
– DS: CDNs, MapReduce
– Compilers: JITs, vectorization
• Networks are largely the same as years ago
– Ethernet, IP, WiFi
• Rate of change of the network seems slower in
comparison
– Need better tools and abstractions to demonstrate
and deploy
9/10/13
Software Defined Networking (COMS 6998-8)
61
Closed Systems (Vendor Hardware)
•
•
•
•
Stuck with interfaces (CLI, SNMP, etc)
Hard to meaningfully collaborate
Vendors starting to open up, but not usefully
Need a fully open system – a Linux equivalent
9/10/13
Software Defined Networking (COMS 6998-8)
62
OpenFlow: a pragmatic compromise
• + Speed, scale, fidelity of vendor hardware
• + Flexibility and control of software and
simulation
• Vendors don’t need to expose
implementation
• Leverages hardware inside most switches
today (ACL tables)
9/10/13
Software Defined Networking (COMS 6998-8)
63
How does OpenFlow work?
9/10/13
Software Defined Networking (COMS 6998-8)
64
Ethernet Switch
9/10/13
Software Defined Networking (COMS 6998-8)
65
Control Path (Software)
Data Path (Hardware)
9/10/13
Software Defined Networking (COMS 6998-8)
66
OpenFlow Controller
OpenFlow Protocol (SSL/TCP)
Control Path
OpenFlow
Data Path (Hardware)
9/10/13
Software Defined Networking (COMS 6998-8)
67
OpenFlow Example
Software
Layer
Controller
PC
OpenFlow Client
Flow Table
Hardware
Layer
MAC
src
MAC
dst
IP
Src
IP
Dst
TCP
TCP
Action
sport dport
*
*
*
5.6.7.8
*
port 1
5.6.7.8
9/10/13
port 2
*
port 3
port 1
port 4
1.2.3.4
Software Defined Networking (COMS 6998-8)
68
OpenFlow Basics
Flow Table Entries
Rule
Action
Stats
Packet + byte counters
1.
2.
3.
4.
5.
Switch VLAN
Port
ID
Forward packet to zero or more ports
Encapsulate and forward to controller
Send to normal processing pipeline
Modify Fields
Any extensions you add!
VLAN MAC
pcp src
MAC
dst
Eth
type
IP
Src
IP
Dst
IP
L4
IP
ToS Prot sport
L4
dport
+ mask what fields to match
9/10/13
Software Defined Networking (COMS 6998-8)
69
Examples
Switching
Switch MAC
Port src
*
MAC Eth
dst
type
00:1f:.. *
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
*
*
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
port6
Flow Switching
Switch MAC
Port src
MAC Eth
dst
type
port3 00:20.. 00:1f.. 0800
VLAN IP
ID
Src
vlan1 1.2.3.4 5.6.7.8
4
17264 80
port6
Firewall
Switch MAC
Port src
*
9/10/13
*
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
*
*
*
Software Defined Networking (COMS 6998-8)
22
drop
70
Examples
Routing
Switch MAC
Port src
*
*
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
IP
Dst
*
5.6.7.8 *
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
vlan1 *
*
*
TCP
TCP
Action
sport dport
port6,
port7,
*
*
port9
*
IP
Prot
TCP
TCP
Action
sport dport
*
port6
VLAN Switching
Switch MAC
Port src
*
9/10/13
*
MAC Eth
dst
type
00:1f.. *
Software Defined Networking (COMS 6998-8)
71
Centralized vs Distributed Control
Both models are possible with OpenFlow
Centralized Control
Controller
OpenFlow
Switch
Distributed Control
Controller
OpenFlow
Switch
Controller
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
9/10/13
Controller
OpenFlow
Switch
Software Defined Networking (COMS 6998-8)
72
Flow Routing vs. Aggregation
Both models are possible with OpenFlow
Aggregated
Flow-Based
•
•
•
•
Every flow is individually
set up by controller
Exact-match flow entries
Flow table contains one
entry per flow
Good for fine grain
control, e.g. campus
networks
9/10/13
•
•
•
•
One flow entry covers large
groups of flows
Wildcard flow entries
Flow table contains one
entry per category of flows
Good for large number of
flows, e.g. backbone
Software Defined Networking (COMS 6998-8)
73
Reactive vs. Proactive (pre-populated)
Both models are possible with OpenFlow
Reactive
Proactive
•
•
•
•
•
First packet of flow
triggers controller to insert
flow entries
Efficient use of flow table
Every flow incurs small
additional flow setup time
If control connection lost,
switch has limited utility
9/10/13
•
•
•
Controller pre-populates
flow table in switch
Zero additional flow setup
time
Loss of control connection
does not disrupt traffic
Essentially requires
aggregated (wildcard) rules
Software Defined Networking (COMS 6998-8)
74
Usage examples
• Alice’s code:
– Simple learning switch
– Per Flow switching
– Network access
control/firewall
– Static “VLANs”
– Her own new routing protocol:
unicast, multicast, multipath
– Home network manager
– Packet processor (in
controller)
– IPvAlice
–
–
–
–
–
VM migration
Server Load balancing
Mobility manager
Power management
Network monitoring
and visualization
– Network debugging
– Network slicing
… and much more you can create!
9/10/13
Software Defined Networking (COMS 6998-8)
75
Outline
• Review of previous lecture
• SDN Basics
– Concepts
– OpenFlow
– Switches and Controllers
– OF-Config
– Mininet
9/10/13
Software Defined Networking (COMS 6998-8)
76
Switches and Controllers
• OpenFlow switches and vendors
• Controllers
– Floodlight
– Beacon
– Nox/pox
– ….
9/10/13
Software Defined Networking (COMS 6998-8)
77
OpenFlow building blocks
oftrace
oflops
Monitoring/
debugging tools
openseer
Stanford Provided
ENVI (GUI)
NOX
LAVI
Beacon
FlowVisor
Console
n-Casting
Helios
9/10/13
Applications
SNAC
Controller
Maestro
Slicing
Software
FlowVisor
Stanford Provided
Commercial Switches
HP, NEC, Pronto,
Juniper.. and many
more
Expedient
Software
Ref. Switch
NetFPGA
Broadcom
Ref. Switch
OpenWRT
PCEngine
WiFi AP
OpenVSwitch
Software Defined Networking (COMS 6998-8)
OpenFlow
Switches
78
78
Current SDN hardware
Juniper MX-series
NEC IP8800
WiMax (NEC)
HP Procurve 5400
Netgear 7324
PC Engines
Pronto 3240/3290
Ciena Coredirector
More coming
soon...
9/10/13
Software Defined Networking (COMS 6998-8)
79
Commercial Switch Vendors
Model
Virtualize
Notes
HP Procurve 5400zl or
6600
1 OF
instance
per VLAN
-LACP, VLAN and STP processing
before OpenFlow
-Wildcard rules or non-IP pkts
processed in s/w
-Header rewriting in s/w
-CPU protects mgmt during loop
NEC IP8800
1 OF
instance
per VLAN
-OpenFlow takes precedence
-Most actions processed in
hardware
-MAC header rewriting in h/w
Pronto 3240 or 3290
with Pica8 or Indigo
firmware
1 OF
instance
per switch
9/10/13
-No legacy protocols (like VLAN
and STP)
-Most actions processed in
hardware
-MAC
header(COMS
rewriting
Software Defined
Networking
6998- in h/w
8)
80
Controller Vendors
Vendor
Notes
Vendor
Notes
Nicira’s
NOX
•Open-source GPL
•C++ and Python
•Researcher friendly
Stanford’s
Beacon
•Open-source
•Researcher friendly
•Java-based
Nicira’s
ONIX
•Closed-source
•Datacenter networks
BigSwitch
controller
•Ha open source version
•Based on Beacon
•Enterprise network
SNAC
•Open-source GPL
•Code based on NOX0.4
•Enterprise network
•C++, Python and Javascript
•Currently used by campuses
Maestro (from
Rice Univ)
•Open-source
•Based on Java
Frenetic or
Nettle
•Open-source
•Written in functional
programming languages
9/10/13
Software Defined Networking (COMS 6998-8)
81
Floodlight Architecture
Source: Big Switch Networks
Overview
FloodlightProvider
(IFloodlightProviderService)
TopologyManager
(ITopologyManagerService)
LinkDiscovery
(ILinkDiscoveryService)
– Floodlight is a collection of modules
– Some modules (not all) export
services
Forwarding
DeviceManager
(IDeviceService)
StorageSource
(IStorageSourceService)
– All modules in Java
– Rich, extensible REST API
RestServer
(IRestApiService)
StaticFlowPusher
(IStaticFlowPusherService)
VirtualNetworkFilter
(IVirtualNetworkFilterService)
82
Software Defined Networking (COMS 6998-8)
Floodlight Architecture
Source: Big Switch Networks
Module descriptions
FloodlightProvider
(IFloodlightProviderService)


Translates OF messages to Floodlight events
Managing connections to switches via Netty
TopologyManager
(ITopologyManagerService)
•
•
Computes shortest path using Dijsktra
Keeps switch to cluster mappings
LinkDiscovery
(ILinkDiscoveryService)


Maintains state of links in network
Forwarding


Installs flow mods for end-to-end routing
DeviceManager
(IDeviceService)


Tracks hosts on the network
StorageSource
(IStorageSourceService)


DB style storage (queries, etc)
RestServer
(IRestApiService)


Implements via Restlets (restlet.org)
StaticFlowPusher
(IStaticFlowPusherService)


Supports the insertion and removal of static flows
VirtualNetworkFilter
(IVirtualNetworkFilterService)


Create layer 2 domain defined by MAC address
Sends out LLDPs
Handles island routing
MAC -> switch,port, MAC->IP, IP->MAC
Modules can access all data and subscribe to changes
Modules export RestletRoutable
REST-based API
Used for OpenStack / Quantum
8383
Software Defined Networking (COMS 6998-8)
Floodlight Programming Model
Northbound APIs
IFloodlightModule


Java module that runs as part of Floodlight
External
Application
Consumes services and events exported by
other modules




OpenFlow (ie. Packet-in)
Switch add / remove
Device add /remove / move
REST
IFloodlightModule
Link discovery
Floodlight Controller
External Application

Switch
Communicates with Floodlight via REST
 Quantum / Virtual networks
 Normalized network state
 Static flows
Software Defined Networking (COMS 6998-8)
Switch
vSwitch
Switch
84
REST API Reference
Source: Big Switch Networks
A moving target…but…
Network State
Static Flows
Virtual Network
User Extensions
List Hosts
Add Flow
Create Network
…
List Links
Delete Flow
Delete Network
List Switches
List Flows
Add Host
GetStats (DPID)
RemoveAll Flows
Remove Host
GetCounters
(OFType…)
Floodlight Controller
Switch
Switch
Switch
vSwitch
Software Defined Networking (COMS 6998-8)
85
Programming Floodlight
Using the REST API
• Fine-grained ability to
push flows over REST
• Access to normalized
topology and device state
• Extensible access to add
new APIs
Software Defined Networking (COMS 6998-8)
86
Programming Floodlight
Source: Big Switch Networks
Creating a module
• Handle OpenFlow
messages directly (ie.
PacketIn)
• Expose services to other
modules
• Add new REST APIs
Software Defined Networking (COMS 6998-8)
87
Outline
• Review of previous lecture
• SDN Basics
– Concepts
– OpenFlow
– Switches and Controllers
– OF-Config
– Mininet
9/10/13
Software Defined Networking (COMS 6998-8)
88
OpenFlow configuration and Management
Protocol
• Bootstrap OpenFlow network
• Switch connects to controller
• Controller(s) to connect to must be
configured at switches
controller
controller
• Allocate resources within switches
• Ports
• Queues
• ...
switch
switch
switch
switch
89
9/10/13
Software Defined Networking (COMS 6998-8)
OpenFlow configuration and Management Protocol:
Reference Model
• Configuration Point
• Source of switch configuration
• OpenFlow Capable Switch
• Hosts one or more logical switches
Configuration
Configuration
Point
Point
OF-CONFIG
Configuration
OpenFlow
Point
Controller
using IETF Netconf &
XML data models
OpenFlow
Capable Switch
• OpenFlow Controller
• OpenFlow Logical Switch
• instance of an OpenFlow
Switch
OpenFlow
OF Logical
Switch
resources
(ports, queues)
90
9/10/13
Software Defined Networking (COMS 6998-8)
Configuration
OpenFlow
Point
Controller
OpenFlow
OF Logical
Switch
OF-CONFIG Scope and Releases
• OF-CONFIG 1.0 (Jan 2012) based on OpenFlow 1.2
• assigning controllers to logical switches
• retrieving assignment of resources to logical switches
• configuring some properties of ports and queues
WG established
in Sep 2011
• OF-CONFIG 1.1 (Apr 2012) based on OpenFlow 1.3
• added controller certificates and resource type "table"
• retrieving logical switch capabilities signaled to controller
• configuring of tunnel endpoints
• OF-CONFIG 1.1.1 (Aug 2012) based on OpenFlow 1.3.1
• consolidation of version 1.1, fixing small inconsistencies
• OF-CONFIG 1.2 (early 2013) based on OpenFlow 1.3.1
• features still under discussion, candidates include
• retrieving capable switch capabilities, configuring logical switch capab.
• assigning resources to logical switches
• simple topology detection
• event notification
91
9/10/13
Software Defined Networking (COMS 6998-8)
Use of Netconf and Yang
• Netconf was chosen as management protocol
• not necessarily accepted as ideal solution
• still discussing alternatives
• XML schema was chosen as modeling language
• So far, the focus has been on configuration
• bootstrap of an OpenFlow network is the obvious first thing to
do
92
9/10/13
Software Defined Networking (COMS 6998-8)
Mininet
• Machine-local virtual network
– great dev/testing tool
• Uses linux virtual network features
– Cheaper than VMs
• Arbitrary topologies, nodes
Mininet (Cont’d)
• Rapidly prototype, develop and test
– Interestingly-sized networks (16-100 nodes) start
up in seconds
– No lengthy lab reconfiguration or rebooting
required
– Always-accessible network resources, in any
topology, at essentially no cost
– Designs that work on Mininet transfer seamlessly
to hardware for full speed operation
9/10/13
Software Defined Networking (COMS 6998-8)
94
Mininet (Cont’d)
• Repeatably test, analyze, and predict network
behavior
– Easy replication of experimental and test results
– Examine effects of code or network changes
before testing/deploying on hardware
– Allows automated system-level tests and
experiments
– Recreate real-world network and test cases for a
variety of topologies and configurations
9/10/13
Software Defined Networking (COMS 6998-8)
95
Mininet (Cont’d)
• Quickly get up and running
– Free and permissively licensed (BSD)
– Minimal hardware requirements
– Accessible to novices thanks to simple CLI
– Smooth learning curve thanks to walkthrough,
tutorial, examples and API documentation
– Strong users and support community
9/10/13
Software Defined Networking (COMS 6998-8)
96
Questions?
9/10/13
Software Defined Networking (COMS 6998-8)
97