Software Defined

Networking
Reference

Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Generalized forwarding: match plus action
Review: each router contains a forwarding table (aka: flow table)
 “match plus action” abstraction: match bits in arriving packet, take action
• destination-based
values in arriving
packet header
forwarding: forward based on dest. IP address
• generalized forwarding:
0111 1
2
3
• many header fields can determine action
• many action possible: drop/copy/modify/log packet

forwarding table
(aka: flow table)

Network Layer: 4-3

Flow table abstraction
• flow: defined by header field values (in link-, network-, transport-layer fields)
• generalized forwarding: simple packet-handling rules
• match: pattern values in packet header fields
• actions: for matched packet: drop, forward, modify, matched packet or send
matched packet to controller
• priority: disambiguate overlapping patterns
• counters: #bytes and #packets

Flow table Router’s flow table define

match action router’s match+action rules

Network Layer: 4-4

Flow table abstraction
• flow: defined by header fields
• generalized forwarding: simple packet-handling rules
• match: pattern values in packet header fields
• actions: for matched packet: drop, forward, modify, matched packet or send
matched packet to controller
• priority: disambiguate overlapping patterns
• counters: #bytes and #packets

Flow table src = *.*.*.*, dest=3.4.*.* forward(2)

match action src=1.2.*.*, dest=*.*.*.* drop
src=10.1.2.3, dest=*.*.*.* send to controller
* : wildcard
1 4
3
2 Network Layer: 4-5
OpenFlow: flow table entries
Match Action Stats

Packet + byte counters

1. Forward packet to port(s)
2. Drop packet
3. Modify fields in header(s)
4. Encapsulate and forward to controller

Header fields to match:

Ingress Src Dst Eth VLAN VLAN IP IP TCP/UDP TCP/UDP
IP Src IP Dst Src Port Dst Port
Port MAC MAC Type ID Pri Proto ToS

Link layer Network layer Transport layer

Network Layer: 4-6
 OpenFlow: examples
Destination-based forwarding:
Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP
Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action
* * * * * * * 51.6.0.8 * * * * port6
IP datagrams destined to IP address 51.6.0.8 should be forwarded to router output port 6

Firewall:
Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP
Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action
* * * * * * * * * * * 22 drop
Block (do not forward) all datagrams destined to TCP port 22 (ssh port #)

Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP

Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action
* * * * * * 128.119.1.1 * * * * * drop
Block (do not forward) all datagrams sent by host 128.119.1.1
Network Layer: 4-7
OpenFlow: examples
Layer 2 destination-based forwarding:
Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP
Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action
22:A7:23:
* * 11:E1:02 * * * * * * * * * port3
layer 2 frames with destination MAC address 22:A7:23:11:E1:02 should be forwarded to
output port 3

Network Layer: 4-8

OpenFlow abstraction
• match+action: abstraction unifies different kinds of devices

Router Firewall
• match: longest • match: IP addresses and
destination IP prefix TCP/UDP port numbers
• action: forward out a link • action: permit or deny
Switch
• match: destination MAC NAT
address • match: IP address and port
• action: forward or flood • action: rewrite address and
port

Network Layer: 4-9

OpenFlow example
Host h6 Orchestrated tables can create
10.3.0.6
1 s3 controller
network-wide behavior, e.g.,:
2
4
 datagrams from hosts h5 and
Host h5
3
h6 should be sent to h3 or h4,
10.3.0.5 via s1 and from there to s2

1 s1 1 s2
Host h1 2 Host h4
10.1.0.1 4 2 4
10.2.0.4
3 3

Host h3
Host h2
10.2.0.3
10.1.0.2

Network Layer: 4-10

OpenFlow example
match action
IP Src = 10.3.*.*
forward(3)
Host h6 Orchestrated tables can create
10.3.0.6
IP Dst = 10.2.*.*
1 s3 controller
network-wide behavior, e.g.,:
2
4
 datagrams from hosts h5 and
Host h5
3
h6 should be sent to h3 or h4,
10.3.0.5 via s1 and from there to s2

1 s1 1 s2
Host h1 2 Host h4
10.1.0.1 4 2 4
10.2.0.4
3 3

match match action

action Host h3
Host h2 ingress port = 2
ingress port = 1 10.1.0.2
10.2.0.3 forward(3)
IP Src = 10.3.*.* forward(4) IP Dst = 10.2.0.3
IP Dst = 10.2.*.* ingress port = 2
forward(4)
IP Dst = 10.2.0.4
Network Layer: 4-11
Generalized forwarding: summary
 “match plus action” abstraction: match bits in arriving packet header(s) in
any layers, take action
• matching over many fields (link-, network-, transport-layer)
• local actions: drop, forward, modify, or send matched packet to
controller
• “program” network-wide behaviors
 simple form of “network programmability”
• programmable, per-packet “processing”
• historical roots: active networking
• today: more generalized programming:
P4 (see p4.org).

Network Layer: 4-12

Network layer: “data plane” roadmap

 Network layer: overview

 What’s inside a router
 IP: the Internet Protocol
 Generalized Forwarding
 Middleboxes
• middlebox functions
• evolution, architectural principles of
the Internet

Network Layer: 4-13

Middleboxes
Middlebox (RFC 3234)

“any intermediary box performing functions apart

from normal, standard functions of an IP router on
the data path between a source host and
destination host”
Middleboxes everywhere!
Firewalls, IDS: corporate,
institutional, service providers,
national or global ISP ISPs
NAT: home,
cellular,
institutional
Load balancers:
corporate, service
provider, data center,
mobile nets
Application-
specific: service datacenter
network

providers,
institutional, Caches: service
CDN enterprise
provider, mobile, CDNs
network
Middleboxes
 initially: proprietary (closed) hardware solutions
 move towards “whitebox” hardware implementing open API
 move away from proprietary hardware solutions
 programmable local actions via match+action
 move towards innovation/differentiation in software
 SDN: (logically) centralized control and configuration management
often in private/public cloud
 network functions virtualization (NFV): programmable services over
white box networking, computation, storage
Per-router control plane
Individual routing algorithm components in each and every router
interact in the control plane to computer forwarding tables

Routing
Algorithm
control
plane

data
plane

values in arriving
packet header
0111 1
2
3

Network Layer: 4-17

Software-Defined Networking (SDN) control plane
Remote controller computes, installs forwarding tables in routers

Remote Controller

control
plane

data
plane

CA
CA CA CA CA
values in arriving
packet header

0111 1
2
3

Network Layer: 4-18

Software defined networking (SDN)
Why a logically centralized control plane?
• easier network management: avoid router misconfigurations,
greater flexibility of traffic flows
• table-based forwarding (recall OpenFlow API) allows
“programming” routers
• centralized “programming” easier: compute tables centrally and distribute
• distributed “programming” more difficult: compute tables as result of
distributed algorithm (protocol) implemented in each-and-every router
• open (non-proprietary) implementation of control plane
• foster innovation: let 1000 flowers bloom

Network Layer: 5-19

 SDN analogy: mainframe to PC revolution
Ap Ap Ap Ap Ap Ap Ap Ap Ap Ap
App
Specialized p p p p p p p p p p
Applications Open Interface

Specialized
Operating or or
System
Windows Linux MAC OS
Specialized Open Interface
Hardware
Microprocessor

Vertically integrated Horizontal

Closed, proprietary Open interfaces
Slow innovation Rapid innovation
Small industry Huge industry
Network Layer: 5-20
* Slide courtesy: N. McKeown
Traffic engineering: difficult with traditional routing
5
3
2 v w 5

u 2
3
1 z
1
2
x 1 y

Q: what if network operator wants u-to-z traffic to flow along

uvwz, rather than uxyz?
A: need to re-define link weights so traffic routing algorithm
computes routes accordingly (or need a new routing algorithm)!
link weights are only control “knobs”: not much control!
Network Layer: 5-21
Traffic engineering: difficult with traditional routing
5
3
2 v w 5

u 2
3
1 z
1
2
x 1 y

Q: what if network operator wants to split u-to-z

traffic along uvwz and uxyz (load balancing)?
A: can’t do it (or need a new routing algorithm)

Network Layer: 5-22

Traffic engineering: difficult with traditional routing
5
3
2 v w 5

u 2
3
1 z
1
2
x 1 y

Q: what if w wants to route blue and red traffic differently from w to z?

A: can’t do it (with destination-based forwarding, and LS, DV routing)
We learned in Chapter 4 that generalized forwarding and SDN can
be used to achieve any routing desired
Network Layer: 5-23
 Software defined networking (SDN)
3. controlplane functions
4. programmable routing
access
… load
control balance
external to data-plane
control switches
applications Remote Controller

control
plane

data
plane

CA 2. control, data plane

CA CA CA CA
separation

1: generalized “flow-based”
forwarding (e.g., OpenFlow)
Network Layer: 5-24
Software defined networking (SDN)
network-control
Data-plane switches: applications
…
routing
 fast, simple, commodity switches
access load
implementing generalized data-plane control balance
forwarding (Section 4.4) in hardware control
plane
 flow (forwarding) table computed, northbound API

installed under controller supervision SDN Controller

 API for table-based switch control (network operating system)

(e.g., OpenFlow)
southbound API
• defines what is controllable, what is not
 protocol for communicating with data
controller (e.g., OpenFlow) plane

SDN-controlled switches Network Layer: 5-25

Software defined networking (SDN)
network-control
SDN controller (network OS): applications
…
routing
 maintain network state load
access
information control balance

 interacts with network control northbound API

control
plane
applications “above” via
northbound API SDN Controller
(network operating system)
 interacts with network switches
“below” via southbound API southbound API

 implemented as distributed system

data
for performance, scalability, fault- plane

tolerance, robustness
SDN-controlled switches Network Layer: 5-26
Software defined networking (SDN)
network-control
network-control apps: applications
…
routing
 “brains” of control: implement access load
control functions using lower- control balance

level services, API provided by northbound API

control
plane
SDN controller
SDN Controller
 unbundled: can be provided by (network operating system)
3rd party: distinct from routing
vendor, or SDN controller southbound API

data
plane

SDN-controlled switches Network Layer: 5-27

Components of SDN controller
routing access load
control balance

interface layer to network Interface, abstractions for network control apps

control apps: abstractions API network

graph
RESTful
API
… intent

network-wide state statistics … flow tables

SDN
management : state of
networks links, switches,
Network-wide distributed, robust state management
controller
services: a distributed database Link-state info host info … switch info

communication: communicate OpenFlow … SNMP

between SDN controller and Communication to/from controlled devices
controlled switches

Network Layer: 5-28

OpenFlow protocol
 operates between controller, switch OpenFlow Controller
 TCP used to exchange messages
• optional encryption
 three classes of OpenFlow messages:
• controller-to-switch
• asynchronous (switch to controller)
• symmetric (misc.)
 distinct from OpenFlow API
• API used to specify generalized
forwarding actions

Network Layer: 5-29

OpenFlow: controller-to-switch messages
Key controller-to-switch messages OpenFlow Controller
 features: controller queries switch
features, switch replies
 configure: controller queries/sets
switch configuration parameters
 modify-state: add, delete, modify flow
entries in the OpenFlow tables
 packet-out: controller can send this
packet out of specific switch port

Network Layer: 5-30

OpenFlow: switch-to-controller messages
Key switch-to-controller messages OpenFlow Controller
 packet-in: transfer packet (and its
control) to controller. See packet-out
message from controller
 flow-removed: flow table entry deleted
at switch
 port status: inform controller of a
change on a port.

Fortunately, network operators don’t “program” switches by creating/sending

OpenFlow messages directly. Instead use higher-level abstraction at controller
Network Layer: 5-31
SDN: control/data plane interaction example
Dijkstra’s link-state
routing 1 S1, experiencing link failure uses
4 OpenFlow port status message to
network
graph
RESTful
API
… intent notify controller

statistics
3 … flow tables
2 SDN controller receives OpenFlow
message, updates link status info
Link-state info host info … switch info
2 3 Dijkstra’s routing algorithm
OpenFlow … SNMP
application has previously registered
to be called when ever link status
changes. It is called.
1
4 Dijkstra’s routing algorithm access
s2 network graph info, link state info
s1
s4 in controller, computes new
s3 routes
Network Layer: 5-32
SDN: control/data plane interaction example
Dijkstra’s link-state
routing

4 5
network
graph
RESTful
API
… intent 5 link state routing app interacts
3 … with flow-table-computation
statistics flow tables component in SDN controller,
Link-state info host info … switch info
which computes new flow tables
2 needed
OpenFlow … SNMP
6 controller uses OpenFlow to
6
install new tables in switches
1 that need updating
s2
s1
s4
s3
Network Layer: 5-33
OpenDaylight (ODL) controller
Traffic
Engineering Firewalling Load Balancing … Network Orchestrations and Applications
Northbound API

REST/RESTCONF/NETCONF APIs
Enhanced Basic Network Functions
Services
Topology Switch Stats
AAA … processing mgr. mgr.
Forwarding Host
… rules mgr. Tracker
Service Abstraction Layer:
config. and
operational data messaging Service Abstraction  interconnects internal,
store Layer (SAL) external applications
and services
OpenFlow NETCONF SNMP OVSDB … Southbound API

Network Layer: 5-34

ONOS controller
Traffic
Engineering Firewalling Load Balancing … Network Applications
Northbound API
 control apps separate
northbound
REST API Intent abstractions, from controller
protocols
 intent framework: high-
hosts paths flow rules topology
level specification of
service: what rather
devices links statistics
ONOS
distributed
than how
core  considerable emphasis
on distributed core:
packet southbound
device link host flow
abstractions, service reliability,
OpenFlow Netconf OVSDB protocols replication performance
Southbound API scaling

Network Layer: 5-35

SDN: selected challenges
• hardening the control plane: dependable, reliable, performance-
scalable, secure distributed system
• robustness to failures: leverage strong theory of reliable distributed
system for control plane
• dependability, security: “baked in” from day one?
• networks, protocols meeting mission-specific requirements
• e.g., real-time, ultra-reliable, ultra-secure
• Internet-scaling: beyond a single AS
• SDN critical in 5G cellular networks

Network Layer: 5-36

SDN and the future of traditional network protocols

• SDN-computed versus router-computer forwarding tables:

• just one example of logically-centralized-computed versus protocol
computed
• one could imagine SDN-computed congestion control:
• controller sets sender rates based on router-reported (to
controller) congestion levels

How will implementation of

network functionality (SDN
versus protocols) evolve?
Network Layer: 5-37