Chapter 5

Network Layer:
The Control Plane

A note on the use of these Powerpoint slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Computer
 If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
Networking: A Top
 If you post any slides on a www site, that you note that they are adapted
from (or perhaps identical to) our slides, and note our copyright of this
Down Approach
material.
7th edition
Thanks and enjoy! JFK/KWR
Jim Kurose, Keith Ross
All material copyright 1996-2016 Pearson/Addison Wesley
J.F Kurose and K.W. Ross, All Rights Reserved April 2016
Network Layer: Control Plane 5-1
Network-layer functions
Recall: two network-layer functions:
 forwarding: move packets
from router’s input to data plane
appropriate router output
 routing: determine route
taken by packets from source control plane
to destination

Two approaches to structuring network control plane:

 per-router control (traditional)
 logically centralized control (software defined networking)

Network Layer: Control Plane 5-2

Per-router control plane
Individual routing algorithm components in each and every
router interact with each other in control plane to compute
forwarding tables

Routing
Algorithm
control
plane

data
plane

Network Layer: Control Plane 5-3

 Logically centralized control plane
A distinct (typically remote) controller interacts with local
control agents (CAs) in routers to compute forwarding tables

Remote Controller

control
plane

data
plane

CA
CA CA CA CA

Network Layer: Control Plane 5-4

Software defined networking (SDN)
 Internet network layer: historically has been
implemented via distributed, per-router approach
• monolithic router contains switching hardware, runs
proprietary implementation of Internet standard
protocols (IP, RIP, IS-IS, OSPF, BGP) in proprietary
router OS (e.g., Cisco IOS)
• different “middleboxes” for different network layer
functions: firewalls, load balancers, NAT boxes, ..

 ~2005: renewed interest in rethinking network

control plane

Network Layer: Control Plane 5-5

Recall: per-router control plane
Individual routing algorithm components in each and every
router interact with each other in control plane to compute
forwarding tables

Routing
Algorithm
control
plane

data
plane

Network Layer: Control Plane 5-6

 Recall: logically centralized control plane
A distinct (typically remote) controller interacts with local
control agents (CAs) in routers to compute forwarding tables

Remote Controller

control
plane

data
plane

CA
CA CA CA CA

Network Layer: Control Plane 5-7

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

Network Layer: Control Plane 5-8

 Analogy: mainframe to PC evolution *

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 Windows Mac

or Linux or
Operating (OS) OS
System
Open Interface
Specialized
Hardware
Microprocessor

Vertically integrated Horizontal

Closed, proprietary Open interfaces
Slow innovation Rapid innovation
Small industry Huge industry
* Slide courtesy: N. McKeown Network Layer: Control Plane 5-9
Traffic engineering: difficult traditional routing

5
3
2 v w 5

u 2 1
3 z
1
2
x 1 y

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

uvwz, x-to-z traffic to flow xwyz?
A: need to define link weights so traffic routing algorithm
computes routes accordingly (or need a new routing algorithm)!

Link weights are only control “knobs”: wrong!

Network Layer: Control Plane 5-10
Traffic engineering: difficult
5
3
2 v w 5

u 2 1
3 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: Control Plane 5-11

 Networking 401
Traffic engineering: difficult
5
3
v
v
w
w
2 5

zz
u 2 1
3
1
2
xx yy
1

Q: what if w wants to route blue and red traffic

differently?

A: can’t do it (with destination based forwarding, and LS,

DV routing)

Network Layer: Control Plane 5-12

 Software defined networking (SDN)
4. programmable
control routing
access
control
… load
balance
3. control plane
functions
applications external to data-
plane switches
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: Control Plane 5-13
 SDN perspective: data plane switches
Data plane switches network-control applications
 fast, simple, commodity
routing
…
switches implementing
generalized data-plane access load
balance
control
forwarding (Section 4.4) in
hardware control
plane
northbound API
 switch flow table computed,
installed by controller SDN Controller
 API for table-based switch (network operating system)
control (e.g., OpenFlow)
• defines what is controllable and southbound API
what is not
 protocol for communicating data
with controller (e.g., OpenFlow) plane

SDN-controlled switches
Network Layer: Control Plane 5-14
 SDN perspective: SDN controller
SDN controller (network OS): network-control applications
 maintain network state
routing
…
information
load
 interacts with network access
control balance
control applications “above”
via northbound API northbound API
control
plane
 interacts with network
switches “below” via SDN Controller
southbound API (network operating system)
 implemented as distributed
system for performance, southbound API
scalability, fault-tolerance,
robustness data
plane

SDN-controlled switches
Network Layer: Control Plane 5-15
 SDN perspective: control applications
network-control apps: network-control applications
 “brains” of control:
routing
…
implement control functions
using lower-level services, API access load
balance
control
provided by SND controller
 unbundled: can be provided by northbound API
control
plane
3rd party: distinct from routing
vendor, or SDN controller SDN Controller
(network operating system)

southbound API

data
plane

SDN-controlled switches
Network Layer: Control Plane 5-16
 Components of SDN controller

routing access load

control balance
Interface layer to
network control Interface, abstractions for network control apps
apps: abstractions
API
network
graph
RESTful
API
… intent

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

communication layer: OpenFlow … SNMP

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

Network Layer: Control Plane 5-17

OpenFlow protocol
 operates between
OpenFlow Controller controller, switch
 TCP used to exchange
messages
• optional encryption
 three classes of
OpenFlow messages:
• controller-to-switch
• asynchronous (switch
to controller)
• symmetric (misc)

Network Layer: Control Plane 5-18

OpenFlow: controller-to-switch messages

Key controller-to-switch messages

 features: controller queries OpenFlow Controller
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: Control Plane 5-19
OpenFlow: switch-to-controller messages
Key switch-to-controller messages
 packet-in: transfer packet (and its OpenFlow Controller
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: Control Plane 5-20
OpenFlow data plane abstraction
 flow: defined by header fields
 generalized forwarding: simple packet-handling rules
• Pattern: match 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 in a router (computed and distributed by

controller) define router’s match+action rules
Network Layer: Data Plane 4-
OpenFlow data plane abstraction
 flow: defined by header fields
 generalized forwarding: simple packet-handling rules
• Pattern: match 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

* : wildcard
1. src=1.2.*.*, dest=3.4.5.*  drop
2. src = *.*.*.*, dest=3.4.*.*  forward(2)
3. src=[Link], dest=*.*.*.*  send to controller
OpenFlow: Flow Table Entries

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
5. Modify Fields

Switch VLAN MAC MAC Eth IP IP IP TCP TCP

Port ID src dst type Src Dst Prot sport dport

Link layer Network layer Transport layer

Examples
Destination-based forwarding:
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
* * * * * * [Link] * * * port6
IP datagrams destined to IP address [Link] should
be forwarded to router output port 6
Firewall:
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Forward
Port src dst type ID Src Dst Prot sport dport
* * * * * * * * * 22 drop
do not forward (block) all datagrams destined to TCP port 22

Switch MAC MAC Eth VLAN IP IP IP TCP TCP

Forward
Port src dst type ID Src Dst Prot sport dport
* * * * * [Link]
* * * * drop
do not forward (block) all datagrams sent by host [Link]
Examples
Destination-based layer 2 (switch) forwarding:
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
[Link]
* [Link] * * * * * * * * port3
layer 2 frames from MAC address [Link]
should be forwarded to output port 6

Network Layer: Data Plane 4-

OpenFlow abstraction
 match+action: unifies different kinds of devices
 Router  Firewall
• match: longest • match: IP addresses
destination IP prefix and TCP/UDP port
• action: forward out numbers
a link • action: permit or
 Switch deny
• match: destination  NAT
MAC address • match: IP address
• action: forward or and port
flood • action: rewrite
address and port

Network Layer: Data Plane 4-

OpenFlow example Example: datagrams from
hosts h5 and h6 should
be sent to h3 or h4, via s1
match action and from there to s2
IP Src = 10.3.*.* Host h6
forward(3)
IP Dst = 10.2.*.* [Link]
1 s3 controller
2

3 4
Host h5
[Link]

1 s1 1 s2
2 Host h4
4 2 4
Host h1 [Link]
3 3
[Link]
Host h2
[Link] match action
match action Host h3
ingress port = 2
[Link] forward(3)
ingress port = 1 IP Dst = [Link]
IP Src = 10.3.*.* forward(4) ingress port = 2
forward(4)
IP Dst = 10.2.*.* IP Dst = [Link]
SDN: control/data plane interaction example
Dijkstra’s link-state 1 S1, experiencing link failure
Routing using OpenFlow port status
message to notify controller
4 5
network
graph
RESTful
API
… intent 2 SDN controller receives
OpenFlow message, updates
statistics
3
… flow tables
link status info
3 Dijkstra’s routing algorithm
Link-state info host info … switch info application has previously
2 registered to be called when
OpenFlow
… SNMP
ever link status changes. It is
called.
4 Dijkstra’s routing algorithm
1 access network graph info, link
state info in controller,
s2 computes new routes
s1
s4
s3
Network Layer: Control Plane 5-28
SDN: control/data plane interaction example
Dijkstra’s link-state
Routing

4 5
network
graph
RESTful
API
… intent 5 link state routing app interacts
with flow-table-computation
statistics
3
… flow tables
component in SDN controller,
which computes new flow
Link-state info host info … switch info
tables needed

2 6 Controller uses OpenFlow to

OpenFlow
… SNMP
install new tables in switches
that need updating

s2
s1
s4
s3
Network Layer: Control Plane 5-29
OpenDaylight (ODL) controller
Traffic …
Engineering  ODL Lithium
controller
REST
API  network apps may
Network Basic Network Service Functions
be contained within,
service apps or be external to
Access
topology
manager
switch
manager
stats
manager
SDN controller
Control
host
 Service Abstraction
forwarding
manager manager Layer: interconnects
internal, external
Service Abstraction Layer (SAL) applications and
services
OpenFlow 1.0
… SNMP OVSDB

Network Layer: Control Plane 5-30

ONOS controller
Network …
control apps
 control apps
northbound separate from
REST API Intent abstractions,
protocols
controller
 intent framework:
hosts paths flow rules topology high-level
specification of
ONOS
devices links statistics distributed service: what rather
core than how
 considerable
device link host flow packet southbound emphasis on
OpenFlow Netconf OVSDB
abstractions,
protocols distributed core:
service reliability,
replication
performance scaling
Network Layer: Control Plane 5-31
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

Network Layer: Control Plane 5-32