Chapter 5
Network
Layer:
Control
Plane Computer
Networking: A Top-
Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Network layer: “control plane” roadmap
introduction
routing protocols
intra-ISP routing: OSPF
routing among ISPs: BGP
SDN control plane
Internet Control network management,
Message Protocol configuration
• SNMP
• NETCONF/YANG
Network Layer: 5-2
Software defined networking (SDN)
Internet network layer: historically implemented via distributed,
per-router control 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: 5-3
Per-router control plane
Individual routing algorithm components in each and every router
interact in the control plane to compute forwarding tables
Routing
Algorithm
control
plane
data
plane
values in arriving
packet header
0111 1
2
3
Network Layer: 4-4
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-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 (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: 5-6
SDN analogy: mainframe to PC revolution
A A A A A A A A A A
Specialized p
App p p p p p p p p p
Application p p p p p p p p p p
s 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
* Slide courtesy: N. McKeown Network Layer: 5-7
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-8
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-9
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-10
Software defined networking (SDN)
3.control plane
4. routing
access
… load
control balance
functions external
programmable to data-plane
control Remote Controller switches
applications
control
plane
data
plane
CA 2. control, data
CA CA CA CA
plane
separation
1: generalized “flow-
based” forwarding
(e.g., OpenFlow) Network Layer: 5-11
Software defined networking (SDN)
network-control
Data-plane switches: applications
fast, simple, commodity switches routing
…
implementing generalized data- access load
plane forwarding (Section 4.4) in control balance
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)
• defines what is controllable, what southbound API
is not
protocol for communicating with data
plane
controller (e.g., OpenFlow)
SDN-controlled switches
Network Layer: 5-12
Software defined networking (SDN)
network-control
SDN controller (network OS): applications
maintain network state information routing
…
interacts with network control access load
control balance
applications “above” via
northbound API control
northbound API plane
interacts with network switches
“below” via southbound API SDN Controller
implemented as distributed system (network operating system)
for performance, scalability, fault-
tolerance, robustness southbound API
data
plane
SDN-controlled switches
Network Layer: 5-13
Software defined networking (SDN)
network-control
network-control apps: applications
“brains” of control: implement routing
…
control functions using lower- access load
control balance
level services, API provided by
SDN controller control
northbound API plane
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: 5-14
Components of SDN controller
routing access load
control balance
interface layer to Interface, abstractions for network control apps
network control apps: network
graph
RESTful
API
… intent
abstractions API
network-wide state statistics … flow tables
SDN
management : state of
networks links, switches,
Network-wide distributed, robust state management
controlle
services: a distributed Link-state info host info … switch info
r
database
communication: OpenFlow … SNMP
communicate between Communication to/from controlled devices
SDN controller and
controlled switches
Network Layer: 5-15
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-16
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-17
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-18
SDN: control/data plane interaction
example
Dijkstra’s link-state
routing 1 S1, experiencing link failure uses
OpenFlow port status message to
4
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
s2 access network graph info, link
s1 state info in controller,
s4 computes new routes
s3
Network Layer: 5-19
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 tables
Link-state info host info … switch info needed
2
OpenFlow … SNMP
6 controller uses OpenFlow to
install new tables in switches
6 that need updating
1
s2
s1
s4
s3
Network Layer: 5-20
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
Network Layer: 5-21
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:
•
How will implementation
of network functionality
(SDN versus protocols)
evolve? Network Layer: 5-22
