Software Defined Networking (SDN) Overview
02/08/2018
Sumit Maheshwari
Includes material from Scott Shenker and Nick McKeown
1
Outline
• Overview
• What is SDN and why SDN
• SDN control plane abstractions
• Example applications
2
What is Software Defined Networking
A network in which the control plane is physically separate from the forwarding
plane
and
A single control plane controls several forwarding devices
3
A Short History of SDN
• ~2004: Research on new management paradigms
• RCP, 4D [Princeton, CMU,….]
• SANE, Ethane [Stanford/Berkeley]
• 2008: Software-Defined Networking (SDN)
• NOX Network Operating System [Nicira]
• OpenFlow switch interface [Stanford/Nicira]
• 2011: Open Networking Foundation (~69 members)
• Board: Google, Yahoo, Verizon, DT, Microsoft, Facebook, NTT
• Members: Cisco, Juniper, HP, Dell, Broadcom, IBM,…..
• 2013: Open Networking Summit
• 1600 attendees, Google: SDN used for their WAN
• Commercialized, in production use (few places)
• 2018: Yearly Summits and more Innovations
• SDN conferences
• Industry consortiums, ONF support, ONOS
Why SDN?
• Networks are hard to manage
- Computation and storage have been virtualized
- Creating a more flexible and manageable infrastructure
- Networks are still notoriously hard to manage
- Network administrators large share of sysadmin staff
• Networks are hard to evolve
- Ongoing innovation in systems software
- New languages, operating systems, etc.
- Networks are stuck in the past
- Routing algorithms change very slowly
- Network management extremely primitive
5
Why SDN?
• Networks design not based on formal principles
- OS courses teach fundamental principles
- Mutual exclusion and other synchronization primitives
- Files, file systems, threads, and other building blocks
- Networking courses teach a big bag of protocols
- No formal principles, just general design guidelines
6
Optimal Load Balancer (Traditional)
Optimal Load Balancer:
Ideally each HTTP
request would be sent
over a path which is
lightly loaded to a server
which is lightly loaded in
order to minimize the
request
7
Optimal Load Balancer (Traditional)
It can choose only the
lightly loaded server
The Network Control Problem
How does classical (IP-based) distributed network control plane operate today?
•Compute the configuration of each physical device
e.g., routing/forwarding tables, ACLs,…
•Operate without communication guarantees
e.g., best effort traffic
•Operate within given network-level protocol
e.g., different protocols for different use-cases
Only people who love complexity would find this a reasonable request
9
Idea: An OS for the Network
Feature Feature
Network OS
Feature Feature
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Custom Hardware
Idea: An OS for the Network
Control Programs
Network Operating System
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware 11
Idea: An OS for the Network
Software-Defined Networking (SDN)
Control Programs
Global Network View
Network Operating System
Control via
forwarding
interface Protocols Protocols
Simplifying Control
Logically-centralized control
Smart &
slow API to the data plane
(e.g., OpenFlow)
Dumb &
fast
Switches
13
Outcome of SDN
• No longer designing distributed control protocols
• Much easier to write, verify, maintain, …
• an interface for programming
• Network OS (NOS) serves as fundamental control block
• with a global view of network
14
Abstractions -> Problem Decomposition
Decompose problem into basic components (tasks)
Define an abstraction for each component
Implementation of abstraction can focus on one task
If tasks still too hard to implement, return to step 1
Problem: Find ‘x’
15
From Requirements to Abstractions
1. Operate without communication guarantees
Need an abstraction for distributed state
2. Compute the configuration of each physical device
Need an abstraction that simplifies configuration
3. Operate within given network-level protocol
Need an abstraction for general forwarding model
Once these abstractions are in place, control mechanism has a much
easier job! Hopefully!
Traditional Control Mechanisms
Distributed algorithm running between neighbors
Network of switches and/or routers
17
Restructured Network using SDN
2. At least one Network OS
3. Well-defined open API Feature Feature probably many.
Open- and closed-source
Network OS
1. Open interface to
packet forwarding
Packet
Forwarding Packet
Forwarding
Packet
Packet Forwarding
Forwarding
Packet
Forwarding
SDN Controller Design
How to design a Network Operating System?
• What features or “abstractions” should be provided by this “Network Operating System”?
• What should be the “global network view” & “programmatic interfaces” provided to control
apps?
• or what “low-level” details should be handled by Network OS?
• What is the granularity of control allowed to “apps”?
19
Requirements for these abstractions: Match-Action
Plumbing Primitives: Data
Header
<Match, Action>
Match: 1000x01xx0101001x
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
20
Requirements for these abstractions: Flow based Decisions
“If header = x, send to port 4”
“If header = y, overwrite header with z, send to ports 5,6”
“If header = ?, send to me” Traffic flow, packet flow or network
flow
Flow Sequence of packets from a source to
a destination
Table
(another host, a multicast group, or
a broadcast domain)
An artificial logical equivalent to a call
or connection
Example: IP Firewall (Reactive)
SRC_IP=10.2.X.X Forward to Port 2
10.2.1.19
SRC_MAC=D1.2E.X.X.X.X BLOCK
Flow Table
Match Action
1 2 NULL NULL
Example: IP Firewall (Reactive)
SRC_MAC=D1.2E.X.X.X.X BLOCK
Flow Table
10.2.1.19 Match Action
1
SRC_IP=10.2.X.X
2 NULL Forward to Port 2
NULL
Example: IP Firewall (Reactive)
10.2.1.19
SRC_MAC=D1.2E.X.X.X.X BLOCK
Flow Table
Match Action
1
SRC_IP=10.2.X.X
2 NULL Forward to Port 2
NULL
Example: Firewall/Switching (Proactive)
SRC_MAC=D1.2E.X.X.X.X BLOCK
Flow Table
Match Action
1
SRC_IP=10.2.X.X
2 NULL Forward to Port 2
NULL
D1.2E.00.12.00.00
Example: Firewall/Switching (Proactive)
Flow Table
Match Action
1
SRC_IP=10.2.X.X
2 NULL Forward to Port 2
NULL
SRC_MAC=D1.2E.X.X.X.X BLOCK
D1.2E.00.12.00.00
Examples Syntax from OpenFlow
Switching
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
* * 00:1f:.. * * * * * * * port6
Routing
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
* * * * * * 5.6.7.8 * * * port6
Firewall
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
* * * * * * * * * 22 drop
SDN Summary
• General forwarding model (data plane abstraction)
• Currently based on OpenFlow (flow-level) forwarding model
• prioritized rules [header: counters, actions]: match actions
• assume forwarding elements provide (standardized) APIs
• install and manipulate forwarding tables, perform match and actions, & collect stats, etc.
• Logically centralized control plane (a “network OS”)
• serve as a “network operating system”
• provide distributed state management, map control logic to data plane actions, etc.
• provide a “global network view” to (high-level) “control apps”
• enable “higher-level” abstractions to hide “lower-level” details
• Control apps operate on higher-level abstractions
• control apps focus on “control logic” using network OS APIs
• Hopefully, much easier to write, verify and maintain!
