Chapter_5_v8.0
Chapter_5_v8.0
Chapter_5_v8.0
Network Layer:
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.
Computer Networking: A
For a revision history, see the slide note for this page.
Top-Down Approach
Thanks and enjoy! JFK/KWR 8th edition
All material copyright 1996-2020
Jim Kurose, Keith Ross
J.F Kurose and K.W. Ross, All Rights Reserved Pearson, 2020
Network layer control plane: our goals
understand principles instantiation, implementation
behind network control in the Internet:
plane: • OSPF, BGP
• traditional routing algorithms • OpenFlow, ODL and ONOS
• SDN controllers controllers
• network management, • Internet Control Message
configuration Protocol: ICMP
• SNMP, YANG/NETCONF
Routing
Algorithm
control
plane
data
plane
values in arriving
packet header
0111 1
2
3
Remote Controller
control
plane
data
plane
CA
CA CA CA CA
values in arriving
packet header
0111 1
2
3
congested”
application
routing: a “top-10” networking transport
network
challenge! enterprise
network
link
physical
5 uwxvyz v
notes:
construct least-cost-path tree by tracing predecessor nodes
ties can exist (can be broken arbitrarily)
Network Layer: 5-16
Dijkstra’s algorithm: discussion
algorithm complexity: n nodes
each of n iteration: need to check all nodes, w, not in N
n(n+1)/2 comparisons: O(n2) complexity
more efficient implementations possible: O(nlogn)
message complexity:
each router must broadcast its link state information to other n routers
efficient (and interesting!) broadcast algorithms: O(n) link crossings to disseminate a
broadcast message from one source
each router’s message crosses O(n) links: overall message complexity: O(n2)
a 2+e
a a 2+e a
1 1+e 0 0 2+e 0
d b d 1+e 1 b d 0 0
b d 1+e 1 b
0 0
e 1 0 1 1 1 0
1 0
c c 0 1 c 1+e 1 0 1
1 c
e e e
e
g h i
1 1
a b c
8 1
t=1 1 1
All nodes:
receive distance
vectors from
neighbors d e f
compute their new 1 1
local distance
vector
send their new 1 1 1
local distance
vector to neighbors
g h i
1 1
a
compute compute
b compute
c
8 1
t=1 1 1
All nodes:
receive distance
vectors from
neighbors d
compute compute
e compute
f
compute their new 1 1
local distance
vector
send their new 1 1 1
local distance
vector to neighbors
g
compute h
compute compute
i
1 1
a b c
8 1
t=1 1 1
All nodes:
receive distance
vectors from
neighbors d e f
compute their new 1 1
local distance
vector
send their new 1 1 1
local distance
vector to neighbors
g h i
1 1
a b c
8 1
t=2 1 1
All nodes:
receive distance
vectors from
neighbors d e f
compute their new 1 1
local distance
vector
send their new 1 1 1
local distance
vector to neighbors
g h i
1 1
compute
a compute
b compute
c
2 1
t=2 1 1
All nodes:
receive distance
vectors from
neighbors d
compute compute
e compute
f
compute their new 1 1
local distance
vector
send their new 1 1 1
local distance
vector to neighbors
g
compute compute
h compute
i
8 1
a b c
8 1
t=2 1 1
All nodes:
receive distance
vectors from
neighbors d e f
compute their new 1 1
local distance
vector
send their new 1 1 1
local distance
vector to neighbors
g h i
1 1
…. and so on
g h i
1 1
g h i
1 1
d b(a}} = 1 + 8 = 9
Dc(a) = min{cc,b+D e f
DV in c:
Dc(b) = min{cc,b+Db(b)} = 1 + 0 = 1
Dc(a) = 9
Dc(d) = min{cc,b+Db(d)} = 1+ ∞ = ∞ Dc(b) = 1
Dc(e) = min{cc,b+Db(e)} = 1 + 1 = 2 Dc(c) = 0
Dc(d) = 2
Dc(f) = min{cc,b+Db(f)} = 1+ ∞ = ∞
Dc(e) = ∞
Dc(g) = min{cc,b+Db(g)} = 1+ ∞ = ∞ * Check out the online interactive
Dc(f) = ∞ exercises for more examples:
Dc(h) = min{cbc,bg+Db(h)} = 1+ ∞ = ∞ h Dc(g) = ∞ i http://gaia.cs.umass.edu/kurose_ross/interactive/
Dc(i) = min{cc,b+Db(i)} = 1+ ∞ = ∞ Dc(h) = ∞
Dc(i) = ∞
Network Layer: 5-35
DV in b:
Distance vector example: computation Db(a) = 8 Db(f) = ∞
Db(c) = 1 Db(g) = ∞
Db(d) = ∞ Db(h) = ∞ DV in e:
DV in d: Db(e) = 1 Db(i) = ∞
De(a) = ∞
Dc(a) = 1 De(b) = 1
Dc(b) = ∞ a De(c) = ∞
b c
Dc(c) = ∞ 8 1 De(d) = 1
Dc(d) = 0 De(e) = 0
t=1 Dc(e) = 1
Dc(f) = ∞ 1
Q: what is new DV computed in e at
1t=1?
De(f) = 1
De(g) = ∞
e receives DVs Dc(g) = 1 De(h) = 1
from b, d, f, h Dc(h) = ∞ De(i) = ∞
Dc(i) = ∞
d compute
e f DV in f:
DV in h: 1 1
Dc(a) = ∞
Dc(a) = ∞ Dc(b) = ∞
Dc(b) = ∞ Dc(c) = ∞
Dc(c) = ∞ 1 1 1 Dc(d) = ∞
Dc(d) = ∞ Dc(e) = 1
Dc(e) = 1 Dc(f) = 0
Dc(f) = ∞ Dc(g) = ∞
Dc(g) = 1 g h i Dc(h) = ∞
1 1
Dc(h) = 0 Dc(i) = 1
Dc(i) = 1 Network Layer: 5-36
Distance vector: state information diffusion
Iterative communication, computation steps diffuses information through network:
t=0 c’s state at t=0 is at c only
a b c
8 1
c’s state at t=0 has propagated to b, and
t=1 may influence distance vector computations
up to 1 hop away, i.e., at b 1 1 t=1
t=2
c’s state at t=0 may now influence distance
t=2 vector computations up to 2 hops away, i.e.,
d e f
at b and now at a, e as well 1 1
c’s state at t=0 may influence distance vector
t=3 computations up to 3 hops away, i.e., at b,a,e
1 1 1 t=3
and now at c,f,h as well
c’s state at t=0 may influence distance vector
t=4 computations up to 4 hops away, i.e., at b,a,e, g h i
c, f, h and now at g,i as well 1 1 t=4
Distance vector: link cost changes
1
link cost changes: y
4 1
node detects local link cost change x z
50
updates routing info, recalculates local DV
if DV changes, notify neighbors
intra-AS
3c
routing3a inter-AS routing intra-AS
2c
3b 2a routing
2b
1c
intra-AS
AS3
1a routing 1b AS2
1d
AS1
3c
3a other
2c
3b 2a networks
2b
1c
AS3
other 1a 1b AS2
networks
1d
AS1
2a 2c
∂
1b 3b
2d
1a 1c 3a
∂ 3c
AS 2
1d 3d
AS 1 eBGP connectivity AS 3
logical iBGP connectivity
2d
AS2 router 2c receives path advertisement AS3,X (via eBGP) from AS3 router 3a
based on AS2 policy, AS2 router 2c accepts path AS3,X, propagates (via iBGP) to all
AS2 routers
based on AS2 policy, AS2 router 2a advertises (via eBGP) path AS2, AS3, X to
AS1 router 1c
Network Layer: 5-54
BGP path advertisement (more)
AS 3 3b
AS 1 1b AS3,X 3a 3c
AS3,X
AS3,X
1a 1c AS 2 3d X
2b
AS3,X
1d AS3, X
AS2,AS3,X 2a 2c
2d
2d
dest interface recall: 1a, 1b, 1d learn via iBGP from 1c: “path to X goes through 1c”
… …
1c 1 at 1d: OSPF intra-domain routing: to get to 1c, use interface 1
X 1 at 1d: to get to X, use interface 1
… …
2d
dest interface
… … recall: 1a, 1b, 1d learn via iBGP from 1c: “path to X goes through 1c”
1c 2
at 1d: OSPF intra-domain routing: to get to 1c, use interface 1
X 2
… … at 1d: to get to X, use interface 1
at 1a: OSPF intra-domain routing: to get to 1c, use interface 2
at 1a: to get to X, use interface 2
Network Layer: 5-58
Why different Intra-, Inter-AS routing ?
policy:
inter-AS: admin wants control over how its traffic routed, who
routes through its network
intra-AS: single admin, so policy less of an issue
scale:
hierarchical routing saves table size, reduced update traffic
performance:
intra-AS: can focus on performance
inter-AS: policy dominates over performance
2d
OSPF link weights
ISP only wants to route traffic to/from its customer networks (does not want
to carry transit traffic between other ISPs – a typical “real world” policy)
A advertises path Aw to B and to C
B chooses not to advertise BAw to C!
B gets no “revenue” for routing CBAw, since none of C, A, w are B’s customers
C does not learn about CBAw path
C will route CAw (not using B) to get to w
Network Layer: 5-61
BGP: achieving policy via advertisements (more)
B provider
x network
w A legend:
C y customer
network:
ISP only wants to route traffic to/from its customer networks (does not want
to carry transit traffic between other ISPs – a typical “real world” policy)
A,B,C are provider networks
x,w,y are customer (of provider networks)
x is dual-homed: attached to two networks
policy to enforce: x does not want to route from B to C via x
.. so x will not advertise to B a route to C
Network Layer: 5-62
BGP route selection
router may learn about more than one route to destination
AS, selects route based on:
1. local preference value attribute: policy decision
2. shortest AS-PATH
3. closest NEXT-HOP router: hot potato routing
4. additional criteria
Routing
Algorithm
control
plane
data
plane
values in arriving
packet header
0111 1
2
3
Remote Controller
control
plane
data
plane
CA
CA CA CA CA
values in arriving
packet header
0111 1
2
3
Specialized
Operating or or
System
Windows Linux MAC OS
Specialized Open Interface
Hardware
Microprocessor
u 2 1
3 z
1
2
x 1 y
u 2 1
3 z
1
2
x 1 y
u 2 1
3 z
1
2
x 1 y
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-73
Software defined networking (SDN)
network-control applications
Data-plane switches: …
routing
fast, simple, commodity switches load
access
implementing generalized data-plane control balance
forwarding (Section 4.4) in hardware control
northbound API plane
flow (forwarding) table computed,
installed under controller supervision SDN Controller
(network operating system)
API for table-based switch control
(e.g., OpenFlow)
southbound API
• defines what is controllable, what is not
protocol for communicating with data
plane
controller (e.g., OpenFlow)
SDN-controlled switches
Network Layer: 5-74
Software defined networking (SDN)
network-control applications
SDN controller (network OS): …
routing
maintain network state access load
information control balance
tolerance, robustness
SDN-controlled switches
Network Layer: 5-75
Software defined networking (SDN)
network-control applications
network-control apps: …
routing
“brains” of control: access load
implement control functions control balance
data
plane
SDN-controlled switches
Network Layer: 5-76
Components of SDN controller
routing access load
control balance
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
s4 state info in controller, computes
s3 new routes
Network Layer: 5-81
SDN: control/data plane interaction example
Dijkstra’s link-state
routing
4 5
network
graph
RESTful
API
… intent 5 link state routing app interacts
3 … with flow-table-computation
statistics flow tables component in SDN controller,
Link-state info host info … switch info
which computes new flow tables
2 needed
OpenFlow
… SNMP
6 controller uses OpenFlow to
install new tables in switches
1 that need updating
s2
s1
s4
s3
Network Layer: 5-82
OpenDaylight (ODL) controller
Traffic
Engineering Firewalling Load Balancing … Network Orchestrations and Applications
Northbound API
REST/RESTCONF/NETCONF APIs
Enhanced Basic Network Functions
Services
Topology Switch Stats
AAA … processing mgr. mgr.
Forwarding Host
… rules mgr. Tracker
Service Abstraction Layer:
config. and
operational data messaging Service Abstraction interconnects internal,
store Layer (SAL) external applications
… Southbound API and services
OpenFlow NETCONF SNMP OVSDB
northbound
Northbound API
control apps separate
REST API Intent abstractions, from controller
protocols
intent framework: high-
hosts paths flow rules topology
level specification of
service: what rather
devices links statistics
ONOS than how
distributed
core considerable emphasis
on distributed core:
device link host flow packet southbound
abstractions, service reliability,
OpenFlow Netconf OVSDB protocols replication performance
Southbound API scaling
3 probes
request
PDU Trap
message type 4 type Enterprise Agent Type
Specific Time
Name Value ….
Addr code stamp
4 (0-7)
SNMP PDU
…
<rpc>
<rpc-reply>
…
…
<rpc>
<rpc-reply>
…
…
<notification>
…
…
<rpc>
<rpc-reply>
…
…
Session close: <close-session>
Network Layer: 5-99
Selected NETCONF Operations
NETCONF Operation Description
<get-config> Retrieve all or part of a given configuration. A device may have multiple
configurations.
<get> Retrieve all or part of both configuration state and operational state data.
<edit-config> Change specified (possibly running) configuration at managed device.
Managed device <rpc-reply> contains <ok> or <rpcerror> with rollback.
<lock>, <unlock> Lock (unlock) configuration datastore at managed device (to lock out
NETCONF, SNMP, or CLIs commands from other sources).
<create-subscription>, Enable event notification subscription from managed device
<notification>
change a configuration
from
from
y ∞∞ ∞ y 2 0 1
Dx(z) = min{cx,y+ Dy(z), cx,z+ Dz(z)}
z ∞∞ ∞ z 7 1 0
= min{2+1 , 7+0} = 3
cost to y
Dy() x y z 2 1
Dx(y) = min{cx,y + Dy(y), cx,z+ Dz(y)}
x ∞ ∞ ∞ = min{2+0 , 7+1} = 2 x z
7
from
y 2 0 1
z ∞∞ ∞
cost to
Dz() x y z
x ∞∞ ∞
from
y ∞∞ ∞
z 7 1 0
time Network Layer: 5-106
Distance vector: another example
cost to cost to cost to
Dx() x y z x y z x y z
x 0 2 7 x 0 2 3 x 0 2 3
from
from
y ∞∞ ∞ y 2 0 1
from
y 2 0 1
z ∞∞ ∞ z 7 1 0 z 3 1 0
from
y 2 0 1 y 2 0 1
from
y 2 0 1
z ∞∞ ∞ z 7 1 0 z 3 1 0
x ∞∞ ∞ x 0 2 7 x 0 2 3
from
from
y 2 0 1 y 2 0 1
from
y ∞∞ ∞
z 7 1 0 z 3 1 0 z 3 1 0
time Network Layer: 5-107