Chapter 5 v8.2
Chapter 5 v8.2
Network Layer:
Control Plane
Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
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”
routing: a “top-10” networking
application
transport
network
challenge! enterprise
network
link
physical
v 3 w
2 5
u 2 1 z
3
1 2
x 1
y
5 uwxvyz v
notes:
construct least-cost-path tree by tracing predecessor nodes
ties can exist (can be broken arbitrarily)
Network Layer: 5-28
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 compute
d 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-47
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-48
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
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 networks
3b 2a
2b
1c
AS3
other 1a 1b AS2
networks
1d
AS1
intra-AS
3c
routing3a inter-AS routing intra-AS
2c
3b 2a routing
2b
1c
intra-AS
AS3
1a routing 1b AS2
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-68
BGP path advertisement: multiple paths
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
… …
BGP: populating forwarding tables
AS 3 3b
AS 1 1b 3a 3c
1
1a 1c AS 2 3d X
2 2b
1d
2a 2c
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
Hot potato routing
AS 3 3b
AS 1 1b 3a 3c
1a 1c AS 2 3d X
2b 112
1d AS1,AS3,X AS3,X
2a 2c
201 263
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-73
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-74
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-86
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
plane
flow (forwarding) table computed, northbound API
(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-87
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-88
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-89
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-94
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-95
Google ORION SDN control plane
ORION: Google’s SDN control plane (NSDI’21): control plane for
Google’s datacenter (Jupiter) and wide area (B4) networks
routing (intradomain, iBGP), traffic Orion SDN architecture and core apps
REST/RESTCONF/NETCONF APIs
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-113
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
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-120
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-121