0% found this document useful (0 votes)
7 views

Chapter_5_part3c

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Chapter_5_part3c

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy