Transcript
Network Layer: Control Plane Goal: understand principles behind network control plane • traditional (intra-domain) routing algorithms • SDN controllers and their instantiation, implementation in the Internet: • OSPF, RIP, OpenFlow, ODL and ONOS controllers
The following will be discussed in separate lecture notes • inter-domain routing & BGP • Internet Control Message Protocol: ICMP • network management and SNMP Readings: Textbook: Chapter 5, Sections 5.1-5.3 & 5.5 CSci4211:
Network Control Plane
1
Network Layer Functions Recall: two network-layer functions: • forwarding: move packets from router’s input to appropriate router output
data plane
routing: determine route taken by packets from source to destination
control plane
Two approaches to structuring network control plane: per-router control (traditional) logically centralized control (software defined networking)
CSci4211:
Network Control Plane
2
Per-router Distributed 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
CSci4211:
Network Control Plane
3
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
CSci4211:
Network Control Plane
CA
CA
CA
4
Routing & Forwarding:
Logical View of a (Classical) Router 5
A
2 1
B 2 D
3
3 1
C
5
1 E
F 2
CSci4211:
Network Control Plane
5
IP Forwarding & IP/ICMP Protocol Transport layer: TCP, UDP IP protocol •addressing conventions •packet handling conventions
Routing protocols •path selection •RIP, OSPF, BGP
Network layer
routing table
ICMP protocol •error reporting •router “signaling”
Data Link layer (Ethernet, WiFi, PPP, …) Physical Layer (SONET, …)
CSci4211:
Network Control Plane
6
Routing: Issues • How are routing tables determined? • Who determines table entries? • What info used in determining table entries? • When do routing table entries change? • Where is routing info stored? • How to control routing table size? Answer these questions, we are done!
CSci4211:
Network Control Plane
7
Routing Protocols Routing protocol goal: determine “good”
paths (equivalently, routes), from sending hosts to receiving host, through network of routers • path: sequence of routers packets will traverse in going from given initial source host to given final destination host • “good”: least “cost”, “fastest”, “least congested” • routing: a “top-10” networking challenge!
CSci4211:
Network Control Plane
8
Graph Abstraction of the Network 5 2
u
v 2
1 graph: G = (N,E)
x
3
w 3
1
5
z
1
y
2
N = set of routers = { u, v, w, x, y, z } E = set of links ={ (u,v), (u,x), (v,x), (v,w), (x,w), (x,y), (w,y), (w,z), (y,z) }
aside: graph abstraction is useful in other network contexts, e.g., P2P, where N is set of peers and E is set of TCP connections
CSci4211:
Network Control Plane
9
Graph Abstraction: Costs 5
2
u
v 2
1
x
3
c(x,x’) = cost of link (x,x’) e.g., c(w,z) = 5
w 3
1
5
z
1
y
2
cost could always be 1, or inversely related to bandwidth, or inversely related to congestion
cost of path (x1, x2, x3,…, xp) = c(x1,x2) + c(x2,x3) + … + c(xp-1,xp)
key question: what is the least-cost path between u and z ? routing algorithm: algorithm that finds that least cost path CSci4211:
Network Control Plane
Routing Algorithms/Protocols Issues Need to Be Addressed:
• Route selection may depend on different criteria – Performance: choose route with smallest delay – Policy: choose a route that doesn’t cross .gov network
• Adapt to changes in network topology or condition
– Self-healing: little or no human intervention
• Scalability
– Must be able to support large number of hosts, routers
CSci4211:
Network Control Plane
11
Classical Distributed Routing Paradigms • Hop-by-hop Routing – Each packet contains destination address – Each router chooses next-hop to destination
• routing decision made at each (intermediate) hop! • packets to same destination may take different paths!
– Example: IP’s default datagram routing
• Source Routing
– Sender selects the path to destination precisely – Routers forward packet to next-hop as specified
• Problem: if specified path no longer valid due to link failure!
– Example:
• IP’s loose/strict source route option (you’ll see later) • virtual circuit setup phase (or MPLS) CSci4211:
Network Control Plane
12
Centralized vs. Distributed Routing Algorithms Centralized: • A centralized route server collects routing information and network topology, makes route selection decisions, then distributes them to routers
Distributed: • Routers cooperate using a distributed protocol – to create mutually consistent routing tables • Two standard distributed routing algorithms – Link State (LS) routing – Distance Vector (DV) routing CSci4211:
Network Control Plane
13
Link State vs. Distance Vector • Both assume that
– The address of each neighbor is known – The cost of reaching each neighbor is known
• Both find global information
– By exchanging routing info among neighbors
• Differ in info exchanged and route computation
– LS: tells every other node its distance to neighbors – DV: tells neighbors its distance to every other node CSci4211:
Network Control Plane
14
Link State Algorithm • Basic idea: Distribute to all routers – Topology of the network • Cost of each link in the network
• Each router independently computes optimal paths – From itself to every destination – Routes are guaranteed to be loop free if • Each router sees the same cost for each link • Uses the same algorithm to compute the best path
CSci4211:
Network Control Plane
15
Topology Dissemination • Each router creates a set of link state packets (LSPs) – Describing its links to neighbors – LSP contains
• Router id, neighbor’s id, and cost to its neighbor
• Copies of LSPs are distributed to all routers – Using controlled flooding
• Each router maintains a topology database – Database containing all LSPs
CSci4211:
Network Control Plane
16
Topology Database: Example 5
2
A
B
3
2 1
D
C 3
1
5
F
1
E
2
link state database
CSci4211:
Network Control Plane
17
Constructing Routing Table: Dijkstra’s Algorithm • Given the network topology – How to compute shortest path to each destination?
• Some notation – X: source node – N: set of nodes to which shortest paths are known so far • N is initially empty – D(V): cost of known shortest path from source X – C(U,V): cost of link U to V • C(U,V) =
¥ if not neighbors CSci4211:
Network Control Plane
18
Dijsktra’s Algorithm (at Node X) • Initialization – N = {X} – For all nodes V • If V adjacent to X, D(V) = C(X,V) • else D(V) = • Loop – Find U not in N such that D(U) is smallest – Add U into set N – Update D(V) for all V not in N • D(V) = min{D(V), D(U) + C(U,V)} – Until all nodes in N
¥
CSci4211:
Network Control Plane
19
Dijkstra’s Algorithm: Example D(v) D(w) D(x) D(y) D(z) Step 0 1 2 3 4 5
N'
p(v)
p(w)
p(x)
u uw uwx uwxv uwxvy uwxvyz
7,u 6,w 6,w
3,u
∞ ∞ 5,u ∞ 5,u 11,w 11,w 14,x 10,v 14,x 12,y
p(y)
p(z)
notes:
x 5
construct shortest path tree by tracing predecessor nodes ties can exist (can be broken arbitrarily)
9 7
4 8 3
u
w
y
2
z
3 4
7
v CSci4211:
Network Control Plane
20
Dijkstra’s Algorithm: Another Example Step 0 1 2 3 4 5
start N A AD ADE ADEB ADEBC ADEBCF
D(B),p(B) D(C),p(C) D(D),p(D) D(E),p(E) D(F),p(F) 2,A 1,A 5,A infinity infinity 2,A 4,D 2,D infinity 2,A 3,E 4,E 3,E 4,E 4,E 5 2
A
B 2
1
D
CSci4211:
3
C 3
1
5
F
1
E
2
Network Control Plane
21
Routing Table Computation
dest next
B C D E F
B D D D D
5
2
A
3
B 2
1
D
CSci4211:
C
F
1
3 1
5
E
Network Control Plane
2
22
Dijkstra’s Algorithm: Discussion
algorithm complexity: n nodes
• each iteration: need to check all nodes, w, not in N • n(n+1)/2 comparisons: O(n2) • more efficient implementations possible: O(nlogn)
oscillations possible:
• e.g., support link cost equals amount of carried traffic: A
1
D 1
B
0
0 0
1+e
C
e
initially
D
A
0
C
0
D
B
1+e 1 0
1 e
2+e
0
CSci4211:
0 1
given these costs, find new routing…. resulting in new costs
A C
2+e
B
0 1+e
2+e
D
A
0
B
1+e 1 0
C
0
given these costs, given these costs, find new routing…. find new routing…. resulting in new costs resulting in new costs
Network Control Plane
23
Distance Vector Routing • A router tells neighbors its distance to every router – Communication between neighbors only
• Based on Bellman-Ford algorithm – Computes “shortest paths”
• Each router maintains a distance table – A row for each possible destination – A column for each neighbor • DX(Y,Z) : distance from X to Y via Z • DX(Y): = min Z {Dx(Y,Z)}: shortest path from X to Y
• Exchanges distance vector with neighbors
– Distance vector: current least cost from X to each destination CSci4211:
Network Control Plane
24
Distance Table: Example cost to destination via
7
A
B
1
C 2
8 1
E
2
D
CSci4211:
DE ()
A
B
D
A
1
14
5
B
7
8
5
C
6
9
4
D
4
11
2
Network Control Plane
25
From Distance Table to Routing Table cost to destination via
Outgoing link to use, cost
D E ()
A
B
D
A
1
14
5
A
A ,1
B
7
8
5
B
D, 5
C
6
9
4
C
D, 4
D
4
11
2
D
D, 2
Distance table
CSci4211:
Routing table (or a distance vector)
Network Control Plane
26
Distance Vector Algorithm Bellman-Ford equation (dynamic programming)
let dx(y) := cost of least-cost path from x to y then dx(y) = min {c(x,v) + dv(y) } v
cost from neighbor v to destination y cost to neighbor v min taken over all neighbors v of x CSci4211:
Network Control Plane
27
Bellman-Ford Example 5 2
u
v 2
1
x
3
w 3
1
clearly, dv(z) = 5, dx(z) = 3, dw(z) = 3 5
z
1
y
B-F equation says: du(z) = min { c(u,v) + dv(z), c(u,x) + dx(z), c(u,w) + dw(z) } = min {2 + 5, 1 + 3, 5 + 3} = 4
2
node achieving minimum is next hop in shortest path, used in forwarding table CSci4211:
Network Control Plane
28
Distance Vector Algorithm • Dx(y) = estimate of least cost from x to y – x maintains distance vector Dx = [Dx(y): y є N ]
• node x: – knows cost to each neighbor v: c(x,v) – maintains its neighbors’ distance vectors. For each neighbor v, x maintains Dv = [Dv(y): y є N ]
CSci4211:
Network Control Plane
29
Distance Vector Algorithm key idea: • from time-to-time, each node sends its own distance vector estimate to neighbors • when x receives new DV estimate from neighbor, it updates its own DV using B-F equation: Dx(y) ← minv{c(x,v) + Dv(y)} for each node y ∊ N
under minor, natural conditions, the estimate Dx(y) converge to the actual least cost dx(y)
CSci4211:
Network Control Plane
30
Distance Vector Algorithm iterative, asynchronous:
each local iteration caused by: • local link cost change • DV update message from neighbor
distributed:
each node: wait for (change in local link cost or msg from neighbor)
recompute estimates
• each node notifies neighbors only when its DV changes – neighbors then notify their neighbors if necessary
CSci4211:
if DV to any dest has changed, notify neighbors
Network Control Plane
31
Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)} = min{2+0 , 7+1} = 2
x y z
x 0 2 7 y ∞∞ ∞ z ∞∞ ∞
x 0 2 3 y 2 0 1 z 7 1 0
cost to
from
from
node x cost to table x y z
Dx(z) = min{c(x,y) + Dy(z), c(x,z) + Dz(z)} = min{2+1 , 7+0} = 3
from
node y cost to table x y z
2
x ∞ ∞ ∞ y 2 0 1 z ∞∞ ∞
x
y 7
1
z
from
node z cost to table x y z x ∞∞ ∞ y ∞∞ ∞ z 7 1 0
time CSci4211:
Network Control Plane
32
Dx(z) = min{c(x,y) + Dy(z), c(x,z) + Dz(z)} = min{2+1 , 7+0} = 3
Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)} = min{2+0 , 7+1} = 2
x y z
x y z
x 0 2 7 y ∞∞ ∞ z ∞∞ ∞
x 0 2 3 y 2 0 1 z 7 1 0
x 0 2 3 y 2 0 1 z 3 1 0
cost to
cost to
from
from
from
node x cost to table x y z
x y z
x y z
x ∞ ∞ ∞ y 2 0 1 z ∞∞ ∞
x 0 2 7 y 2 0 1 z 7 1 0
x 0 2 3 y 2 0 1 z 3 1 0
cost to
cost to
x ∞∞ ∞ y ∞∞ ∞ z 7 1 0
x 0 2 7 y 2 0 1 z 3 1 0 CSci4211:
2
x
y 7
1
z
cost to
x y z from
x y z from
node z cost to table x y z from
cost to
from
from
from
node y cost to table x y z
x 0 2 3 y 2 0 1 z 3 1 0 time
Network Control Plane
33
Distance Vector: Link Cost Changes link cost changes:
node detects local link cost change updates routing info, recalculates distance vector if DV changes, notify neighbors
“good news travels fast”
1
x
4
y 50
1
z
t0 : y detects link-cost change, updates its DV, informs its neighbors. t1 : z receives update from y, updates its table, computes new least cost to x , sends its neighbors its DV. t2 : y receives z’s update, updates its distance table. y’s least costs do not change, so y does not send a message to z.
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
CSci4211:
Network Control Plane
34
Distance Vector: Link Cost Changes link cost changes:
60
node detects local link cost change bad news travels slow - “count to infinity” problem! 44 iterations before algorithm stabilizes: see text
x
4
y
1
50
z
“Count-to-Infinity” Problem: A Simple Example 1
X
1
Y
Z
2 CSci4211:
Network Control Plane
35
“Fixes” to Count-to-Infinity Problem • Split horizon – A router never advertises the cost of a destination to a neighbor • If this neighbor is the next hop to that destination
• Split horizon with poisonous reverse – If X routes traffic to Z via Y, then • X tells Y that its distance to Z is infinity – Instead of not telling anything at all
– Accelerates convergence
CSci4211:
Network Control Plane
36
Split Horizon with Poisoned Reverse If Z routes through Y to get to X :
60
• Z tells Y its (Z’s) distance to X is infinite (so Y won’t route to X via Z)
X
4
Y 50
1
Z
algorithm terminates
CSci4211:
Network Control Plane
37
“Fixes” to Count-to-Infinity Problem • Split horizon – A router never advertises the cost of a destination to a neighbor • If this neighbor is the next hop to that destination
• Split horizon with poisonous reverse – If X routes traffic to Z via Y, then • X tells Y that its distance to Z is infinity – Instead of not telling anything at all
– Accelerates convergence
• Will this completely solve count to infinity problem? CSci4211:
Network Control Plane
38
Count-to-Infinity Problem Revisited
X
Y
Z
W
CSci4211:
Network Control Plane
39
Link State vs Distance Vector • Tells everyone about neighbors • Controlled flooding to exchange link state • Dijkstra’s algorithm • Each router computes its own table • May have oscillations • Open Shortest Path First (OSPF)
CSci4211:
• Tells neighbors about everyone • Exchanges distance vectors with neighbors • Bellman-Ford algorithm • Each router’s table is used by others • May have routing loops • Routing Information Protocol (RIP)
Network Control Plane
40
Comparison of LS and DV Algorithms message complexity • LS: with n nodes, E links, O(nE) msgs sent • DV: exchange between neighbors only – convergence time varies
speed of convergence • LS: O(n2) algorithm requires O(nE) msgs – may have oscillations • DV: convergence time varies – may be routing loops – count-to-infinity problem
CSci4211:
robustness: what happens if router malfunctions? LS: – node can advertise incorrect link cost – each node computes only its own table
DV: – DV node can advertise incorrect path cost – each node’s table used by others • error propagate thru network
Network Control Plane
0
Routing in the Real World Our routing study thus far - idealization • all routers identical • network “flat”
How to do routing in the Internet • scalability and
policy issues
scale: with 200 million destinations:
• can’t store all destinations in routing tables! • routing table exchange would swamp links!
CSci4211:
administrative autonomy • internet = network of networks • each network admin may want to control routing in its own network
Network Control Plane
42
Routing in the Internet • The Global Internet consists of Autonomous Systems (AS) interconnected with each other:
– Stub AS: small corporation: one connection to other AS’s – Multihomed AS: large corporation (no transit): multiple connections to other AS’s – Transit AS: provider, hooking many AS’s together
• Two-level routing:
– Intra-AS: administrator responsible for choice of routing algorithm within network – Inter-AS: unique standard for inter-AS routing: BGP CSci4211:
Network Control Plane
43
Interconnected ASes 3c
3a 3b AS3
2a 1c 1a 1d
2c
2b AS2
1b AS1
Intra-AS Routing algorithm
Inter-AS Routing algorithm
Forwarding table
CSci4211:
• forwarding table configured by both intra- and inter-AS routing algorithm
– intra-AS routing determine entries for destinations within AS – inter-AS & intra-AS determine entries for external destinations
Network Control Plane
43
Intra-AS vs. Inter-AS Routing C.b
a Host h1
C
b
A.a
Inter-AS routing between A and B A.c
a
d c b A Intra-AS routing within AS A
CSci4211:
B.a a
c
B
Host h2 b
Intra-AS routing within AS B
Network Control Plane
45
Why Different Intra- and InterAS Routing? Policy: • Inter-AS: admin wants control over how its traffic routed, who routes through its net. • Intra-AS: single admin, so no policy decisions needed
Scale: • hierarchical routing saves table size, update traffic Performance: • Intra-AS: can focus on performance • Inter-AS: policy may dominate over performance Will Talk about Inter-AS routing (& BGP) later! CSci4211:
Network Control Plane
46
Intra-AS Routing • Also known as Interior Gateway Protocols (IGP) • Most common Intra-AS routing protocols: – RIP: Routing Information Protocol – OSPF: Open Shortest Path First – IS-IS: Intermediate System to Intermediate System (OSI Standard) – EIGRP: Extended Interior Gateway Routing Protocol (Cisco proprietary)
CSci4211:
Network Control Plane
47
RIP ( Routing Information Protocol) • Distance vector algorithm • Included in BSD-UNIX Distribution in 1982 • Distance metric: # of hops (max = 15 hops) – Can you guess why?
• Distance vectors: exchanged among neighbors every 30 sec via Response Message (also called advertisement) • Each advertisement: list of up to 25 destination nets within AS
CSci4211:
Network Control Plane
48
RIP: Link Failure and Recovery If no advertisement heard after 180 sec --> neighbor/link declared dead – routes via neighbor invalidated – new advertisements sent to neighbors – neighbors in turn send out new advertisements (if tables changed) – link failure info quickly propagates to entire net – poison reverse used to prevent ping-pong loops (infinite distance = 16 hops)
CSci4211:
Network Control Plane
49
RIP Table Processing • RIP routing tables managed by application-level process called route-d (daemon) • advertisements sent in UDP packets, periodically repeated routed
routed
Transprt (UDP) network (IP)
Transprt (UDP) forwarding table
forwarding table
link
network (IP) link
physical
physical
CSci4211:
Network Control Plane
50
OSPF (Open Shortest Path First) • “open”: publicly available • uses link-state algorithm – link state packet dissemination – topology map at each node – route computation using Dijkstra’s algorithm
• router floods OSPF link-state advertisements to all other routers in entire AS – carried in OSPF messages directly over IP (rather than TCP or UDP – link state: for each attached link
• IS-IS routing protocol: nearly identical to OSPF CSci4211:
Network Control Plane
51
OSPF “Advanced” Features (not in RIP) • Security: all OSPF messages authenticated (to prevent malicious intrusion) • Multiple same-cost paths allowed (only one path in RIP) • For each link, multiple cost metrics for different TOS (“Type-of-Services”) – e.g., satellite link cost set “low” for best effort; high for real time)
• Hierarchical OSPF in large domains.
CSci4211:
Network Control Plane
52
Hierarchical OSPF boundary router backbone router
backbone area border routers
area 3
internal routers
area 1
area 2 CSci4211:
Network Control Plane
53
Hierarchical OSPF • Two-level hierarchy: local area, backbone.
– Link-state advertisements only in area – each nodes has detailed area topology; only know direction (shortest path) to nets in other areas.
• Area border routers: “summarize” distances to nets in own area, advertise to other Area Border routers. • Backbone routers: run OSPF routing limited to backbone. • Boundary routers: connect to other ASes.
CSci4211:
Network Control Plane
54
Software Defined Networking (SDN) • Internet network layer: historically has been implemented via distributed, perrouter 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 CSci4211:
Network Control Plane
55
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
CSci4211:
Network Control Plane
56
Recall: 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
CSci4211:
CA
Network Control Plane
57
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
CSci4211:
Network Control Plane
58
Analogy: mainframe to PC Evolution Ap Ap Ap Ap Ap Ap Ap Ap Ap Ap p p p p p p p p p p
App
Specialized Applications
Open Interface
Specialized Operating System
Windows (OS)
or
Linux
or
Mac OS
Open Interface
Specialized Hardware
Microprocessor
Vertically integrated Closed, proprietary Slow innovation Small industry
Horizontal Open interfaces Rapid innovation Huge industry CSci4211:
Network Control Plane
59
Traffic Engineering: Difficult Traditional Routing 5
2
v
u
3
2
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 only control “knobs”: wrong! CSci4211:
Network Control Plane
60
Traffic Engineering: Difficult 5
2
v
u
3
2
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: can’t do it (or need a new routing algorithm)
CSci4211:
Network Control Plane
61
Networking 401
Traffic Engineering: Difficult 5
2
3
v v 2
u 1
xx
w w
zz
1
3 1
5
yy
2
Q: what if w wants to route blue and red traffic differently? A: can’t do it (with destination based forwarding, and LS, DV routing)
CSci4211:
Network Control Plane
62
Software Defined Networking (SDN) 4. programmable control applications routing
…
access control
3. control plane functions external to data-plane 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., OpenFlow) CSci4211:
Network Control Plane
63
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) CSci4211:
Network Control Plane
control plane
data plane
SDN-controlled switches 64
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
CSci4211:
Network Control Plane
network-control applications
…
routing access control
load balance
northbound API
control plane
SDN Controller (network operating system) southbound API
data plane
SDN-controlled switches 65
SDN Perspective: Control Applications network-control apps: “brains” of control: implement control functions using lower-level services, API provided by SND 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
CSci4211:
Network Control Plane
SDN-controlled switches 66
Components of SDN Controller access control
routing Interface layer to network control apps: abstractions API Network-wide state management layer: state of networks links, switches, services: a distributed database communication layer: communicate between SDN controller and controlled switches CSci4211:
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 Control Plane
67
OpenFlow Protocol OpenFlow Controller
• operates between controller, switch • TCP used to exchange messages – optional encryption
• three classes of OpenFlow messages: – controller-to-switch – asynchronous (switch to controller) – symmetric (misc) CSci4211:
Network Control Plane
68
OpenFlow: Controller-to-Switch Messages
Key controller-to-switch messages • 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
CSci4211:
Network Control Plane
OpenFlow Controller
69
OpenFlow: Switch-to-Controller Messages
Key switch-to-controller messages: • packet-in: transfer packet (and its control) to controller. See packetout message from controller • flow-removed: flow table entry deleted at switch • port status: inform controller of a change on a port.
OpenFlow Controller
Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction at controller CSci4211:
Network Control Plane
70
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
…
2 SDN controller receives OpenFlow message, updates link status info
intent
flow tables
…
switch info
SNMP
4 Dijkstra’s routing algorithm access network graph info, link state info in controller, computes new routes
1
s2 s1
3 Dijkstra’s routing algorithm application has previously registered to be called when ever link status changes. It is called.
s4 s3 CSci4211:
Network Control Plane
71
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 CSci4211:
Network Control Plane
72
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
CSci4211:
Network Control Plane
73
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
CSci4211:
Network Control Plane
74
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 missionspecific requirements
– e.g., real-time, ultra-reliable, ultra-secure
• Internet-scaling
CSci4211:
Network Control Plane
75
