0% found this document useful (0 votes)
35 views

Openflow & Nox (& How The SDN Era Started) : Nick Mckeown & Natasha Gude Et Al

OpenFlow and NOX introduced a new approach to software-defined networking that separated the control plane from the data plane. This allowed the control logic of networks to be programmed centrally from a controller running NOX, which could install flow entries onto OpenFlow switches to define their packet forwarding behavior. This provided a more programmable and flexible way for researchers to test new network protocols and innovations without having to manually configure individual network devices.

Uploaded by

Kalan Kl
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
35 views

Openflow & Nox (& How The SDN Era Started) : Nick Mckeown & Natasha Gude Et Al

OpenFlow and NOX introduced a new approach to software-defined networking that separated the control plane from the data plane. This allowed the control logic of networks to be programmed centrally from a controller running NOX, which could install flow entries onto OpenFlow switches to define their packet forwarding behavior. This provided a more programmable and flexible way for researchers to test new network protocols and innovations without having to manually configure individual network devices.

Uploaded by

Kalan Kl
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

OpenFlow & NOX

(& how the SDN era started)


CCR 2008 Whitepapers

Nick McKeown & Natasha Gude et al.

Presented by: M. Asim Jamshed


Some slides have been derived from Nick McKeown’s talk in the Stanford Clean
Slate Program & Scott Shenker’s talk in the Open Networking Summit, 2011
Intro: Need for a Programmable Switch

• Alice wants to test a new network protocol


– Asks administrator to create network paths b/w set
of machines spanning the entire campus network

2
Intro: Need for a Programmable Switch
• Control plane elements difficult to configure
– E.g. Network paths are fixed in L2/L3 boxes
– Flow tables in switches/routers vendor-specific
– Each L2/L3 path needs to be updated manually on
each switch

3
Approach I: Updating switch internally

VENDOR’S sw Network
Network
Standard

hw Processing
Processing
User-
defined
Processing
Processing
Experimenter writes
experimental code
on switch/router

NIGHTMARE
*Figure taken from Nick McKoewn’s talk: “OpenFlow (Or: “Why can’t I innovate in my wiring closet?”)” (2008) 4
Approach II: Open-S/W Platforms

FANOUT
Experimenter
uses Click
(or its equivalent)

COMPACT
SOLUTION
5
OpenFlow Goals
Allow admins to program the control (forwarding)
plane without exposing the IP rights of the vendors’
switches/routers

An open protocol that dynamically programs the


flow tables in switches/routers

6
OpenFlow Switching Approach
OpenFlow Switch specification
L)
OpenFlow Switch col
(S S PC
t o
Pro
Flow
c kets
n /Pa
Ope and s Controller
sw Secure m
Com
Channel

hw Flow
Table

*Figure taken from Nick McKoewn’s talk: “OpenFlow (Or: “Why can’t I innovate in my wiring closet?”)” (2008) 7
Controller
• Fine-grained management of the control plane
– Flows processed according to admin’s policies
• Controller commands
– Forward packets to ports/controller
– Drop packets
– Rewrite headers
– Flexible header manipulation
• Arbitrary matching of first few bytes of payload
• Arbitrary rewriting of first few bytes of payload
• Support load balancing b/w multiple controllers
8
Secure Channel
• SSL Connection, site-specific key
• Controller discovery protocol
• Encapsulate packets for controller
• Send link/port state to controller

9
Flow Table
Flow Table Entry

Rule Action Stats

Packet + Byte counters

1. Forward packet to port(s)


2. Encapsulate and forward to controller
3. Drop packet
4. Send to normal processing pipeline

Switch MAC MAC Eth VLAN IP IP IP TCP TCP


Port src dst type ID Src Dst Prot sport dport
+ mask

*Figure taken from Nick McKoewn’s talk: “OpenFlow (Or: “Why can’t I innovate in my wiring closet?”)” (2008) 10
End Targets
• Amenable to
– High performance
– Low-cost implementations
• Isolation of experimental from normal traffic
• Vendor’s need for closed platforms retained

11
The Bigger Question
• Configuring each switch of the network for
– Path updates
– Access control
– VLAN tagging
– Traffic conditioning
– Traffic mirroring
• Extremely cumbersome
• Manage control plane via programmable switches
– from a centralized node

12
NOS Fundamentals
• Present apps a centralized programming model
• Manages the controller
• Programs written as if the entire network is on a single
machine
– High level abstractions
• IP and MAC address
• Hostnames and usernames
– Manage bindings between abstractions & low-level bindings

• NOS network view  Entire network abstraction


• An example of NOS  NOX (open source)
13
SDN Hierarchy – The Big Picture
3. Well-defined open API 2. At least one good operating system
Extensible, possibly open-source
App App App
(Routing) (CDN) (AC)

ABSTRACT NETWORK MODEL


Global
Network Operating System (NOX) Network
View (DB)
1. Open interface to hardware

Simple Packet
Forwarding (e.g.
OpenFlow) H/W
Simple Packet
Switch
Forwarding (e.g.
OpenFlow) H/W
Switch
Simple Packet
Forwarding (e.g.
OpenFlow) H/W
Simple Packet Switch
Forwarding (e.g.
Simple Packet
OpenFlow) H/W
Forwarding (e.g.
Switch
OpenFlow) H/W
*Figure taken from Nick McKoewn’s FCC talk: “Software-Defined Networks” (2009) 14
Switch
NOX Network Operations
• Incoming new packet at switch
– Does flow entry for the corresponding flow exist?
– If yes:
• Perform the action
– If no:
• Forward it to the NOX controller
• Process the packet in the controller based on the policy
written by the control program (app)
• Send NOX command to the switch to add new flow
entry (optional)
15
What more can NOX do?
• Finer Admission Control
– “Guests can comm. using HTTP only via a web proxy”
• VLANs
– “Create your own isolated network”
• A non-IP network
– “Evaluate your own L3 protocol”
• Simplistic scan detection
– How to detect scanning hosts
– Count # of unique L2 & L3 conn. initiation queries
• Concise (only 11 SLOC)

16
Experiment at Packet Level

Deep Packet
Inspection
using a
middlebox

17
*Figure taken from “OpenFlow: Enabling Innovation in Campus Networks” (2008)
Experiment: Power Management

18
Discussion Forum
• Making the network more manageable
• But also,
– Making the network more intelligent

Concept of “keeping the control


plane simple” lost??

19
Discussion Points
• Data plane -> Control plane -> Data plane
– Latency issues?
• Concept of security? (flow poisoning attacks)
• Downside of using centralized management
– DDoS attack on the SDN controller
• 100K DNS/DHCP requests per sec??
– Scalability
• Difference between Ethane/NOX

20
Appendix

21
OpenFlow Switch Vendors
• Alcatel-Lucent • Extreme Networks
• Big Switch Networks • IBM
• Brocade Communications • Juniper Networks
• Arista Networks • Hewlett-Packard
• Pica8 • NEC
• Cisco • MikroTik
• Dell Force10 • & many more…

22
OpenFlow Type Switches
• OpenFlow Switch Specification
– Current version 1.4 (2013)

23
NOX Port Detection Example Code
scans = defaultdict(dict)
def check_for_scans(dp, inport, packet):
dstid = nox.resolve_host_dest(packet)
if dstid == None:
scans[packet.l2.srcaddr][packet.l2.dstaddr] = 1
if packet.l3 != None:
scans[packet.l2.srcaddr][packet.l3.dstaddr] = 1
if len(scans[packet.l2.srcaddr].keys()) > THRESHOLD:
print nox.resolve_user_source_name(packet)
print nox.resolve_host_source_name(packet)
# To be called on all packet-in events
nox.register_for_packet_in(check_for_scans)

24

You might also like