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
Chapter 5: outline
5.5 The
5.1 introduction
SDN control plane
5.2 ICMP:
5.6 routing The
protocols
Internet Control Message Protocol
5.7link
Network
state management and SNMP
 distance vector
5.3 intra-AS routing in the Internet: OSPF
5.4 routing among the ISPs: BGP

Network Layer: Control Plane 5-2

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-3

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-4

 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-5

Software defined networking (SDN)
Why a logically centralized control plane?
 easier network management: avoid router
misconfigurations, greater flexibility of traffic
flows
 table-based forwarding (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-6
 Analogy: mainframe to PC evolution *

Ap Ap Ap Ap Ap Ap Ap Ap Ap Ap
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

Operating or Linux or 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-7
Traffic engineering: difficult 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, 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)!

Network Layer: Control Plane 5-8

 Software defined networking (SDN)
4. programmable 3. control plane
control routing
access
control … load
balance 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-9
 SDN perspective: data plane switches
Data plane switches network-control
applications
 fast, simple, commodity
routing
…
switches implementing
generalized data-plane access load
control balance
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-10
 SDN perspective: SDN controller
SDN controller (network network-control
OS): applications
…
routing
 maintain network state
access load
information control balance
 interacts with network control
control
applications “above” via northbound API plane
northbound API
 interacts with network SDN Controller
switches “below” via (network operating system)
southbound API
 implemented as distributed southbound API

system for performance,

scalability, fault-tolerance, data
robustness plane

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

southbound API

data
plane

SDN-controlled switches
Network Layer: Control Plane 5-12
 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
Network-wide distributed, robust state management
SDN
links, switches,
controller
services: a
distributed database
Link-state info host info … switch info

communication OpenFlow … SNMP

layer: Communication to/from controlled devices
communicate
between SDN
controller and
controlled switches
Network Layer: Control Plane 5-13
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-14

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-15
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.

Network Layer: Control Plane 5-16

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
6 access network graph info,
1
link state info in controller,
s2 computes new routes
s1
s4
s3
Network Layer: Control Plane 5-17
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

6
1

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

Network Layer: Control Plane 5-19

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

Network Layer: Control Plane 5-20

Chapter 4: outline
4.4 Generalized
4.1 Overview of Forward
Networkand SDN
layer
• match
• data
actionplane
• control
OpenFlow plane
examples of match-plus-action in action
4.2 What’s inside a router
4.3 IP: Internet Protocol
• datagram format
• fragmentation
• IPv4 addressing
• network address
translation
• IPv6

Network Layer: Data Plane 4-21

Generalized Forwarding and SDN
Each router contains a flow table that is computed and
distributed by a logically centralized routing controller

logically-centralized routing controller

control plane

data plane
local flow table
headers counters actions

1
0100 1101

3 2
values in arriving
packet’s header
Network Layer: Data Plane 4-22
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-23
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=10.1.2.3, 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: Forwarding
Functionality
Destination-based layer 3 (router) forwarding:
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
* * * * * * 51.6.0.8 * * * port6
IP datagrams destined to IP address 51.6.0.8
should be forwarded to router output port 6

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
22:A7:23:
* 11:E1:02 * * * * * * * * port3
layer 2 frames from MAC address
22:A7:23:11:E1:02 should be forwarded to switch
output port 3
Examples: Firewall Functionality

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
* * * * 128.119.1.1 drop
do not forward* (block)
* * * *
all datagrams sent by host
128.119.1.1
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-28

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.*.* 10.3.0.6
1 s3 controller
2

3 4
Host h5
10.3.0.5

1 s1 1 s2
2 Host h4
4 2 4
Host h1 10.2.0.4
3 3
10.1.0.1
Host h2
10.1.0.2 match action
match action Host h3
ingress port = 2
10.2.0.3 forward(3)
ingress port = 1 IP Dst = 10.2.0.3
IP Src = 10.3.*.* forward(4) ingress port = 2
forward(4)
IP Dst = 10.2.*.* IP Dst = 10.2.0.4
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-30