Transcript Slides

Chapter 4
Network Layer:
The Data 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:
 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!)
 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
material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2016
J.F Kurose and K.W. Ross, All Rights Reserved
Computer
Networking: A Top
Down Approach
7th edition
Jim Kurose, Keith Ross
Pearson/Addison Wesley
April 2016
Network Layer: Data Plane 4-1
Chapter 4: outline
4.1 Overview of Network
layer
• data plane
• control plane
4.4 Generalized
Forwarding and SDN
• match
• action
• OpenFlow examples of
match-plus-action in
action
Network Layer: Data Plane 4-2
Network layer
 transport segment from
sending to receiving hosts
 on sending side
encapsulates segments
into datagrams
 on receiving side, delivers
segments to transport
layer
 network layer protocols
in every host & router
 router examines header
fields in all IP datagrams
passing through it
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Network Layer: Data Plane 4-3
Two key network-layer functions
analogy: taking a trip
network-layer functions:
forwarding: move packets  forwarding: process of
getting through single
from router’s input to
interchange
appropriate router output
routing: determine route
taken by packets from
 routing: process of
source to destination
planning trip from source
to destination
• routing algorithms
Network Layer: Data Plane 4-4
Network layer: data plane & control plane
Data plane
Control plane
local, per-router function
determines how datagram
arriving on router input port is
forwarded to router output
port
forwarding function
network-wide logic
determines how datagram is
routed among routers along endend path from source host to
destination host
two control-plane approaches:
• traditional routing algorithms:
implemented in routers
• software-defined networking
(SDN): implemented in
(remote) servers
values in arriving
packet header
1
0111
3
2
Network Layer: Data Plane 4-5
Per-router control plane
Individual routing algorithm components in each and every
router interact in the control plane
Routing
Algorithm
control
plane
data
plane
values in arriving
packet header
1
0111
3
2
Network Layer: Control Plane 5-6
“Logically centralized” control plane
A distinct (typically remote) controller interacts with local
control agents (CAs)
Remote Controller
control
plane
data
plane
CA
CA
values in arriving
packet header
CA
CA
CA
1
0111
3
2
Network Layer: Control Plane 5-7
Chapter 4: outline
4.1 Overview of Network
layer
• data plane
• control plane
4.4 Generalized Forwarding
and SDN
• match
• action
• OpenFlow examples of
match-plus-action in
action
Network Layer: Data Plane 4-8
Motivation
 Proliferation of middleboxes that perform many
layer-3 functions (except forwarding)
• NAT: rewrite packet header’s IP address and port #
• Firewall: block traffic based on header-field values
• Load-balancer: forward packets requesting a given service
to one of a set of servers
 Proliferation of layer-2 switches and layer-3
routers
 Each has its own specialized hardware, software, and
management interface
 A unified approach to provide many networklayer functions and certain link-layer functions in an
integrated manner
Network Layer: Data Plane 4-9
Generalized Forwarding and SDN
Each router contains a flow (match+action) 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
SDN switch or
packet switch
vs.
layer 3 router or
layer 2 switch
1
0100 1101
3 2
values in arriving
packet’s header
Network Layer: Data Plane 4-10
OpenFlow data plane abstraction
 flow: defined by {header fields from different layers}
 generalized forwarding: simple packet-handling rules
• Pattern: match values in packet header fields
• Actions (for matched packet): drop, forward, modify
matched packet or send unmatched 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-11
OpenFlow data plane abstraction
 flow: defined by {header fields from different layers}
 generalized forwarding: simple packet-handling rules
• Pattern: match values in packet header fields
• Actions (for matched packet): drop, forward, modify
matched packet or send unmatched 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
Match+Action
 Destination based vs. generalized forwarding
 Network-wide collection of per-packet switch
matching rules implements a wide range of
functions
•
•
•
•
•
•
layer 3 routing
layer 2 switching
NAT
firewalling
load-balancing
virtual networks
OpenFlow: Flow Table Entries
Rule
Action
Stats
packet + byte counters
1.
2.
3.
4.
5.
Switch VLAN
Port ID ID
Forward packet to port(s)
Encapsulate and forward to controller
Drop packet
Send to normal processing pipeline
Modify Fields
MAC
src
MAC
dst
Link layer
Eth
type
IP
Src
IP
Dst
IP
Prot
Network layer
TCP
sport
TCP
dport
Transport layer
http://archive.openflow.org/documents
/openflow-spec-v1.0.0.pdf
Network Layer
4-15
Examples
Destination-based forwarding:
Switch MAC
Port src
*
*
MAC Eth
dst
type
*
*
Switch MAC
Port src
*
IP
Dst
IP
Prot
TCP
TCP
Action
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
Firewall:
*
VLAN IP
ID
Src
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Forward
sport dport
*
*
*
*
*
22
drop
do not forward (block) all datagrams destined to TCP port 22
Switch MAC
Port src
*
*
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
*
128.119.1.1
IP
Dst
IP
Prot
TCP
TCP
Forward
sport dport
*
*
*
*
drop
do not forward (block) all datagrams sent by host 128.119.1.1
Examples
Destination-based layer 2 (switch) forwarding:
Switch MAC
Port src
*
22:A7:23:
11:E1:02
MAC Eth
dst
type
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
*
*
*
*
*
*
port3
layer 2 frames from MAC address 22:A7:23:11:E1:02
should be forwarded to output port 3
Network Layer: Data Plane 4-17
OpenFlow abstraction
 match+action: unifies different kinds of devices
 Router (layer 3)
• match: longest
destination IP prefix
• action: forward out
a link
 Switch (layer 2)
• match: destination
MAC address
• action: forward or
flood
 Firewall
• match: IP addresses
and/or TCP/UDP port
numbers
• action: permit or
deny
 NAT
• match: IP address
and port
• action: rewrite
address and port
Network Layer: Data Plane 4-18
OpenFlow example (1)
match
Example: datagrams from
hosts h5 or h6 destined to
h3 or h4 should be sent
via s1 to s2
action
IP Src = 10.3.*.*
forward(3)
IP Dst = 10.2.*.*
Host h6
10.3.0.6
1
s3
controller
2
3
4
Host h5
10.3.0.5
1
s1
s2
1
2
Host h1
10.1.0.1
4
2
3
ingress port = 1
IP Src = 10.3.*.*
IP Dst = 10.2.*.*
action
forward(4)
Host h4
10.2.0.4
3
Host h2
10.1.0.2
match
4
match
Host h3
10.2.0.3
action
ingress port = 2
forward(3)
IP Dst = 10.2.0.3
ingress port = 2
forward(4)
IP Dst = 10.2.0.4
Load balancing:
datagrams from h3
destined to 10.1.*.* are to
be forwarded over the link
between s2 and s1;
datagrams from h4
destined to 10.1.*.* are to
controller
be forwarded over the link
between s2 and s3 (and
the from s3 to s1)
OpenFlow example (2)
match
action
Ingress port = 4
forward(3)
IP Src = 10.2.*.*
IP Dst = 10.1.*.*
Host h6
10.3.0.6
1
s3
2
3
4
Host h5
10.3.0.5
1
s1
s2
1
2
Host h1
10.1.0.1
4
2
3
action
IP Dst = 10.1.0.1 forward(2)
IP Dst = 10.1.0.2 forward(3)
Host h4
10.2.0.4
3
Host h2
10.1.0.2
match
4
match
Host h3
10.2.0.3
ingress port = 3
IP Dst = 10.1.*.*
ingress port = 4
IP Dst = 10.1.*.*
action
forward(2)
forward(1)
OpenFlow example (3)
Host h6
10.3.0.6
1
s3
Firewall: s2 wants only to
receive (on any of its
interfaces) traffic sent
from hosts attached to s3
controller
2
3
4
Host h5
10.3.0.5
1
s1
s2
1
2
Host h1
10.1.0.1
4
4
2
3
Host h4
10.2.0.4
3
Host h2
10.1.0.2
match
Host h3
10.2.0.3
action
IP Src = 10.3.*.*
forward(3)
IP Dst = 10.2.0.3
IP Src = 10.3.*.*
forward(4)
IP Dst = 10.2.0.4
Data Plane: done!
4.1 Overview of Network
layer: data plane and
control plane
4.4 Generalized Forward and
SDN
• match plus action
• OpenFlow example
Question: how do forwarding tables
(destination-based forwarding) or
flow tables (generalized
forwarding) computed?
Answer: by the control plane
(next chapter)
Network Layer: Data Plane 4-22
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:
 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!)
 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
material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2016
J.F Kurose and K.W. Ross, All Rights Reserved
Computer
Networking: A Top
Down Approach
7th edition
Jim Kurose, Keith Ross
Pearson/Addison Wesley
April 2016
Network Layer: Control Plane 5-23
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-24
SDN 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-25
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 “programmable” routers
• centralized “programming” easier: compute tables
centrally and distribute flow tables
• 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-26
Analogy: mainframe to PC evolution
Specialized
Applications
Specialized
Operating
System
Specialized
Hardware
vertically integrated
closed, proprietary
➡slow innovation,
small industry
* Slide courtesy: N. McKeown
*
Ap Ap Ap Ap Ap Ap Ap Ap Ap Ap
p p p p p p p p p p
App
Open Interface
Windows
(OS)
or
Linux
or
Mac
OS
Open Interface
Microprocessor
horizontal
open interfaces
rapid innovation
huge industry
Network Layer: Control Plane 5-27
Traffic engineering: difficult with traditional routing
5
2
v
3
2
u
3
1
x
w
1
5
1
y
z
2
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 the only control “knobs”: wrong!
Network Layer: Control Plane 5-28
Traffic engineering: difficult
5
2
v
3
2
u
3
1
x
w
1
5
1
y
z
2
Q: what if network operator wants to split u-to-z
traffic along uvwz and uxyz (load balancing)?
A: cannot do it (or need a new routing algorithm)
Network Layer: Control Plane 5-29
Traffic engineering: difficult
Networking 401
5
2
3
v
2
u
1
w
w
v
xx
zz
1
3
1
5
yy
2
Q: what if w wants to route blue and red traffic
differently?
A: cannot do it (with destination based forwarding, and
LS, DV routing)
Network Layer: Control Plane 5-30
Software defined networking (SDN)
4. programmable
routing
control
applications
…
access
control
3. control plane
functions
external to dataplane switches
load
balance
Remote Controller
control
plane
data
plane
CA
CA
CA
CA
CA
2. control,
data plane
separation
1: generalized “flowbased” forwarding
(e.g., via OpenFlow)
Network Layer: Control Plane 5-31
SDN perspective: data plane switches
Data plane switches
 fast, simple, commodity
switches implementing
generalized data-plane
forwarding (Section 4.4) in
hardware
 switch flow table computed,
installed by controller
 API for table-based switch
control (e.g., OpenFlow)
• defines what is controllable and
what is not
network-control applications
…
routing
access
control
load
balance
northbound API
SDN Controller
(network operating system)
southbound API
 protocol for communicating
with controller (e.g., OpenFlow)
Network Layer: Control Plane 5-32
control
plane
data
plane
SDN-controlled switches
SDN perspective: SDN controller
SDN controller (network OS):
 maintain network state
information
 interacts with network
control applications “above”
via northbound API
 interacts with network
switches “below” via
southbound API
 implemented as distributed
system for performance,
scalability, fault-tolerance,
robustness
Network Layer: Control Plane 5-33
network-control applications
…
routing
access
control
load
balance
northbound API
control
plane
SDN Controller
(network operating system)
southbound API
data
plane
SDN-controlled switches
SDN perspective: control applications
network-control apps:
 “brains” of control:
implement control functions
using lower-level services, API
provided by SDN controller
 unbundled: can be provided by
3rd party: distinct from routing
vendor, or SDN controller
network-control applications
…
routing
access
control
load
balance
northbound API
control
plane
SDN Controller
(network operating system)
southbound API
data
plane
Network Layer: Control Plane 5-34
SDN-controlled switches
Components of SDN controller
access
control
routing
Interface layer to
network control
apps: abstractions,
API
Network-wide state
management layer:
state of networks’
hosts, links, switches,
services: a distributed
database/servers
communication layer:
communicate between
SDN controller and
controlled switches
load
balance
Interface, abstractions for network control apps
network
graph
RESTful
API
statistics
…
…
intent
flow tables
Network-wide distributed, robust state management
Link-state info
host info
OpenFlow
…
…
SDN
controller
switch info
SNMP
Communication to/from controlled devices
Network Layer: Control Plane 5-35
OpenFlow protocol
OpenFlow Controller
 operates between
controller and switch
 TCP used (port #
6653) to exchange
messages
• optional encryption
 three classes of
OpenFlow messages:
• controller-to-switch
• asynchronous (switch
to controller)
• symmetric (misc)
Network Layer: Control Plane 5-36
OpenFlow: controller-to-switch messages
Key controller-to-switch messages
 read-state: controller collects
statistics and counter values from
flow tables and ports
 configuration: controller queries/sets
switch configuration parameters
 modify-state: add, delete, modify
flow table entries in switch; set
switch port properties
 send-packet (packet-out): controller
can send contents of this packet
out of specific switch port
OpenFlow Controller
Network Layer: Control Plane 5-37
OpenFlow: switch-to-controller messages
Key switch-to-controller messages
 packet-in: transfer (unmatched)
packet (and its control) to
controller. Vs. packet-out message
from controller
 flow-removed: flow table entry
deleted at switch
 port-status: inform controller of a
status change on a port.
OpenFlow Controller
Fortunately, network operators do not “program” switches by
creating/sending OpenFlow messages directly. Instead, use
higher-level abstraction at controller
Network Layer: Control Plane 5-38
SDN: control/data plane interaction example
1 S1, experiencing link failure
using OpenFlow port-status
message to notify controller
Dijkstra’s link-state
Routing
4
RESTful
API
network
graph
…
3
statistics
Link-state info
host info
2
OpenFlow
…
5
…
flow tables
…
switch info
SNMP
2 SDN controller receives
OpenFlow message, updates
link status info
3 Dijkstra’s routing algorithm
application has previously
registered to be called when
ever link status changes. It is
called.
4 Dijkstra’s routing algorithm
access network graph info, link
state info in controller,
computes new routes
1
s2
s1
intent
s4
s3
Network Layer: Control Plane 5-39
SDN: control/data plane interaction example
Dijkstra’s link-state
Routing
4
RESTful
API
network
graph
…
3
statistics
Link-state info
host info
2
OpenFlow
…
5
…
intent
flow tables
…
5 link state routing app interacts
with flow-table-computation
component in SDN controller,
which computes new flow
tables needed
switch info
SNMP
6 Controller uses OpenFlow to
install new tables in switches
that need updating
1
s2
s1
s4
s3
Network Layer: Control Plane 5-40
OpenDaylight (ODL) controller
…
Traffic
Engineering
REST API
Network
service apps
Access
Control
Basic Network Service Functions
topology
manager
switch
manager
forwarding
manager
stats
manager
host
manager
Service Abstraction Layer (SAL)
OpenFlow 1.0
…
SNMP
 ODL Lithium
controller
 network apps may
be contained within,
or be external to
SDN controller
 Service Abstraction
Layer: interconnects
internal, external
applications and
services
OVSDB
Network Layer: Control Plane 5-41
ONOS controller
…
Network
control apps
REST API
Intent
northbound
abstractions,
protocols
hosts
paths
flow rules
topology
devices
links
statistics
ONOS
distributed
core
host
flow packet
device
link
OpenFlow
Netconf
OVSDB
southbound
abstractions,
protocols
 control apps
separate from
controller
 intent framework:
high-level
specification of
service: what rather
than how
 considerable
emphasis on
distributed core:
service reliability,
replication
performance scaling
Network Layer: Control Plane 5-42
SDN: 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-43