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 routers input to data plane appropriate router output § routing: determine route taken by packets from source control plane to destination

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

4.1 • OVERVIEW OF NETWORK LAYER 309

Routing Algorithm Routing algorithm control Control plane plane Data plane Local forwarding data table plane header output 0100 3 0110 2 0111 2 1001 1

Values in arriving packet’s header 1 1101

2 3

CSci4211:Figure 4.2 ♦ Routing Network algorithms Control determine Plane values in forward tables 3 tables. In this example, a routing algorithm runs in each and every router and both forwarding and routing functions are contained within a router. As we’ll see in Sec- tions 5.3 and 5.4, the routing algorithm function in one router communicates with the routing algorithm function in other routers to compute the values for its forwarding table. How is this communication performed? By exchanging routing messages containing routing information according to a routing protocol! We’ll cover routing algorithms and protocols in Sections 5.2 through 5.4. The distinct and different purposes of the forwarding and routing functions can be further illustrated by considering the hypothetical (and unrealistic, but technically feasible) case of a network in which all forwarding tables are configured directly by human network operators physically present at the routers. In this case, no routing protocols would be required! Of course, the human operators would need to interact with each other to ensure that the forwarding tables were configured in such a way that packets reached their intended destinations. It’s also likely that human configuration would be more error-prone and much slower to respond to changes in the network topology than a routing protocol. We’re thus fortunate that all networks have both a forwarding and a routing function!

M04_KURO4140_07_SE_C04.indd 309 11/02/16 3:14 PM 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: Network Control Plane 4 Routing & Forwarding: Logical View of a (Classical) Router

B 3 C 2 5 A 2 3 1 F 1 2 D E 1

CSci4211: Network Control Plane 5 IP Forwarding & IP/ICMP Protocol

Transport layer: TCP, UDP

Routing protocols IP protocol •path selection •addressing conventions •RIP, OSPF, BGP •packet handling conventions 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

v 3 w 2 5 u 2 1 z 3 1 x y 2 graph: G = (N,E) 1

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 c(x,x) = cost of link (x,x) v 3 w e.g., c(w,z) = 5 2 5 cost could always be 1, or u 2 1 z 3 inversely related to bandwidth, 1 x y 2 or inversely related to 1 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 doesnt 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: IPs 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: • IPs loose/strict source route option (youll 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, neighbors 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

3 B C 2 5

A 2 1 F 3 1 2 D E 1

link state database

CSci4211: Network Control Plane 17 Constructing Routing Table: Dijkstras 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 N' p(v) p(w) p(x) p(y) p(z) 0 u 7,u 3,u 5,u ∞ ∞ 1 uw 6,w 5,u 11,w ∞ 2 uwx 6,w 11,w 14,x 3 uwxv 10,v 14,x 4 uwxvy 12,y 5 uwxvyz x 9

5 7 notes: 4 v construct shortest path tree by tracing predecessor nodes 8 3 v ties can exist (can be broken u w y z arbitrarily) 2 3 7 4 v

CSci4211: Network Control Plane 20 Dijkstras Algorithm: Another Example

Step start N D(B),p(B) D(C),p(C) D(D),p(D) D(E),p(E) D(F),p(F) 0 A 2,A 5,A 1,A infinity infinity 1 AD 2,A 4,D 2,D infinity 2 ADE 2,A 3,E 4,E 3 ADEB 3,E 4,E 4 ADEBC 4,E 5 ADEBCF 5

B 3 C 2 5 A 2 1 F 3 1 D E 2 1

CSci4211: Network Control Plane 21 Routing Table Computation

dest next 5 B B C D 3 D D B C 2 5 E D F D A 2 1 F 3 1 2 D E 1

CSci4211: Network Control Plane 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 1+e A A A 2+e 0 0 2+e 2+e 0 D B D B D B D B 0 0 1+e 1 0 0 1+e 1 0 e 0 0 C C 0 1 C 1+e C 0 1 1 e given these costs, given these costs, given these costs, initially find new routing…. find new routing…. find new routing…. resulting in new costs resulting in new costs resulting in new costs CSci4211: 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

DE () A B D 1 B C A 1 14 5 7 A 8 2 B 7 8 5 1 C 6 9 4 E D

2 destination D 4 11 2

CSci4211: Network Control Plane 25 From Distance Table to Routing Table

cost to destination via Outgoing link A B D D E () to use, cost A A ,1 A 1 14 5 B D, 5 B 7 8 5 C D, 4 C 6 9 4

destination destination D D, 2 D 4 11 2

Distance table Routing table (or a distance vector)

CSci4211: 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 clearly, dv(z) = 5, dx(z) = 3, dw(z) = 3 v 3 w 2 5 u 2 1 z B-F equation says: 3 1 d (z) = min { c(u,v) + d (z), x y 2 u v 1 c(u,x) + dx(z), c(u,w) + dw(z) } = min {2 + 5, 1 + 3, 5 + 3} = 4 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 v 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 node: each local iteration caused by: wait for (change in local link • local link cost change cost or msg from neighbor) • DV update message from neighbor distributed: recompute estimates • each node notifies neighbors only when its if DV to any dest has DV changes changed, notify neighbors – neighbors then notify their neighbors if necessary

CSci4211: Network Control Plane 31 Dx(z) = min{c(x,y) + Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)} = min{2+0 , 7+1} = 2 Dy(z), c(x,z) + Dz(z)} = min{2+1 , 7+0} = 3 node x cost to cost to table x y z x y z x 0 2 7 x 0 2 3 y y 2 0 1

∞ ∞ ∞ from from z ∞ ∞ ∞ z 7 1 0

node y cost to table x y z y 2 1 x ∞ ∞ ∞ x z y 2 0 1 7 from z ∞ ∞ ∞

node z cost to table x y z x ∞ ∞ ∞ y

from ∞ ∞ ∞ z 7 1 0 time CSci4211: Network Control Plane 32 Dx(z) = min{c(x,y) + Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)} = min{2+0 , 7+1} = 2 Dy(z), c(x,z) + Dz(z)} = min{2+1 , 7+0} = 3 node x cost to cost to cost to table x y z x y z x y z x 0 2 7 x 0 2 3 x 0 2 3 y y 2 0 1

∞ ∞ ∞ from y

from 2 0 1 z z from ∞ ∞ ∞ 7 1 0 z 3 1 0

node y cost to cost to table x y z x y z cost to y x y z 2 1 x ∞ ∞ ∞ x 0 2 7 x 0 2 3 x z y 2 0 1 y 2 0 1 y 7

from 2 0 1 from z ∞ ∞ ∞ z 7 1 0 from z 3 1 0

node z cost to cost to cost to table x y z x y z x y z x ∞ ∞ ∞ x 0 2 7 x 0 2 3 y y 2 0 1

y from 2 0 1 from

from ∞ ∞ ∞ z z z 7 1 0 3 1 0 3 1 0 time CSci4211: Network Control Plane 33 Distance Vector: Link Cost Changes

link cost changes: 1 v node detects local link cost change y 4 1 v updates routing info, recalculates x z distance vector 50 v if DV changes, notify neighbors

good t : y detects link-cost change, updates its DV, informs its neighbors. news 0 travels t1 : z receives update from y, updates its table, computes new least fast cost to x , sends its neighbors its DV.

t2 : y receives zs update, updates its distance table. ys 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 v node detects local link cost change y 4 1 v bad news travels slow - count to x z infinity problem! 50 v 44 iterations before algorithm stabilizes: see text

“Count-to-Infinity” Problem: A Simple Example

1 1 X Y Z

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 Y • Z tells Y its (Zs) distance to X is 4 1 infinite (so Y wont route to X via Z) X Z 50

algorithm terminates

CSci4211: Network Control Plane 37 Fixes to Count-to-Infinity Problem

CSci4211: Network Control Plane 38 Count-to-Infinity Problem Revisited

X Y Z

CSci4211: Network Control Plane 39 Link State vs Distance Vector

• Tells everyone about • Tells neighbors about neighbors everyone • Controlled flooding to • Exchanges distance exchange link state vectors with neighbors • Bellman-Ford • Dijkstra s algorithm algorithm • Each router computes • Each routers table is its own table used by others • May have oscillations • May have routing loops • Open Shortest Path • Routing Information First (OSPF) Protocol (RIP)

CSci4211: Network Control Plane 40 Comparison of LS and DV Algorithms message complexity robustness: what happens if • LS: with n nodes, E links, O(nE) router malfunctions? msgs sent LS: • DV: exchange between neighbors – node can advertise incorrect only link cost – convergence time varies – each node computes only its speed of convergence own table DV: • LS: O(n2) algorithm requires O(nE) msgs – DV node can advertise incorrect path cost – may have oscillations – each nodes table used by • DV: convergence time varies others – may be routing loops • error propagate thru – count-to-infinity problem network

CSci4211: 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 administrative autonomy destinations: • internet = network of • cant store all destinations in routing tables! networks • routing table exchange • each network admin may would swamp links! want to control routing in its own network

CSci4211: 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 ASs – Multihomed AS: large corporation (no transit): multiple connections to other ASs – Transit AS: provider, hooking many ASs 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 2c 3b 2a AS3 2b 1c AS2 1a 1b 1d AS1 • forwarding table configured by both intra- and inter-AS routing algorithm Intra-AS Inter-AS Routing Routing – intra-AS routing algorithm algorithm determine entries for Forwarding destinations within table AS – inter-AS & intra-AS determine entries for external destinations

CSci4211: Network Control Plane 43 Intra-AS vs. Inter-AS Routing

Inter-AS C.b routing between B.a A.a A and B Host b A.c c h2 a a C b a B Host d Intra-AS routing h1 c A b within AS B Intra-AS routing within AS A

CSci4211: Network Control Plane 45 Why Different Intra- and Inter- AS 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 Transprt (UDP) (UDP) network forwarding forwarding network (IP) table table (IP) link 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 Dijkstras 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, per- router 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

4.1 • OVERVIEW OF NETWORK LAYER 309

Routing Algorithm Routing algorithm control Control plane plane Data plane Local forwarding data table plane header output 0100 3 0110 2 0111 2 1001 1

Values in arriving packet’s header 1 1101

2 3

56 Figure 4.2 ♦ Routing algorithms determine values in forward tables CSci4211: Network Control Plane

tables. In this example, a routing algorithm runs in each and every router and both forwarding and routing functions are contained within a router. As we’ll see in Sec- tions 5.3 and 5.4, the routing algorithm function in one router communicates with the routing algorithm function in other routers to compute the values for its forwarding table. How is this communication performed? By exchanging routing messages containing routing information according to a routing protocol! We’ll cover routing algorithms and protocols in Sections 5.2 through 5.4. The distinct and different purposes of the forwarding and routing functions can be further illustrated by considering the hypothetical (and unrealistic, but technically feasible) case of a network in which all forwarding tables are configured directly by human network operators physically present at the routers. In this case, no routing protocols would be required! Of course, the human operators would need to interact with each other to ensure that the forwarding tables were configured in such a way that packets reached their intended destinations. It’s also likely that human configuration would be more error-prone and much slower to respond to changes in the network topology than a routing protocol. We’re thus fortunate that all networks have both a forwarding and a routing function!

M04_KURO4140_07_SE_C04.indd 309 11/02/16 3:14 PM 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

57 CSci4211: Network Control Plane 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

ApApApApApApApApApAp App Specialized p p p p p p p p p p Applications Open Interface

Specialized Windows Mac or Linux or Operating (OS) OS System Open Interface Specialized Hardware Microprocessor

Vertically integrated Horizontal Closed, proprietary Open interfaces Slow innovation Rapid innovation Small industry Huge industry

CSci4211: Network Control Plane 59 Traffic Engineering: Difficult Traditional Routing

5 3 2 v w 5 2 1 u 3 z 1 2 x 1 y

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 3 2 v w 5 2 1 u 3 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)

CSci4211: Network Control Plane 61 Networking 401 Traffic Engineering: Difficult

v 3 w 2 v w 5 2 1 z u 3 z 1 x y 2 x 1 y

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 3. control plane access load control applicationsrouting control … balance functions external to data-plane switches Remote Controller

control plane

data plane

CA 2. control, data plane CA CA CA CA separation

1: generalized“ flow- based” forwarding (e.g., OpenFlow)

CSci4211: Network Control Plane 63 SDN Perspective: Data Plane Switches

Data plane switches network-control applications • fast, simple, commodity routing … switches implementing access load generalized data-plane balance forwarding (Section 4.4) in control hardware control plane • switch flow table computed, northbound API installed by controller SDN Controller • API for table-based switch (network operating system) control (e.g., OpenFlow)

– defines what is controllable and southbound API what is not • protocol for communicating data with controller (e.g., plane OpenFlow)

SDN-controlled switches CSci4211: Network Control Plane 64 SDN perspective: SDN Controller

SDN controller (network OS): network-control applications § maintain network state … information routing access load § interacts with network control control balance applications “above” via northbound API control northbound API plane § interacts with network switches “below” via SDN Controller southbound API (network operating system) § implemented as distributed system for performance, southbound API scalability, fault-tolerance, robustness data plane

SDN-controlled switches CSci4211: Network Control Plane 65 SDN Perspective: Control Applications

network-control apps: network-control applications § “brains” of control: … implement control functions routing access load using lower-level services, API balance provided by SND controller control § unbundled: can be provided control northbound API plane by 3rd party: distinct from routing vendor, or SDN SDN Controller controller (network operating system)

southbound API

data plane

CSci4211: Network Control Plane SDN-controlled switches 66 Components of SDN Controller

routing access load control balance Interface layer to network control Interface, abstractions for network control apps apps: abstractions network RESTful API graph API … intent Network-wide state management layer: statistics … flow tables state of networks SDN links, switches, Network-wide distributed, robust state management services: a controller Link-state info host info … switch info distributed database communication OpenFlow … SNMP layer: Communication to/from controlled devices communicate between SDN controller and controlled switches

CSci4211: Network Control Plane 67 OpenFlow Protocol

• operates between OpenFlow Controller 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 OpenFlow Controller 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 69 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

CSci4211: Network Control Plane 70 SDN: Control/Data Plane Interaction Example Dijkstra’s link-state 1 S1, experiencing link failure Routing using OpenFlow port status message to notify controller 4 5 network RESTful … graph API intent 2 SDN controller receives 3 OpenFlow message, updates … link status info statistics flow tables 3 Dijkstra’s routing algorithm Link-state info host info … switch info application has previously 2 registered to be called when ever link status changes. It is OpenFlow … SNMP called. 4 Dijkstra’s routing algorithm 6 1 access network graph info, link state info in controller, s2 computes new routes s1 s4 s3 CSci4211: Network Control Plane 71 SDN: Control/Data plane Interaction Example Dijkstra’s link-state Routing 4 5 network RESTful … graph API intent 5 link state routing app interacts 3 with flow-table-computation … component in SDN controller, statistics flow tables which computes new flow tables needed Link-state info host info … switch info 2 6 Controller uses OpenFlow to install new tables in switches OpenFlow … SNMP that need updating 6 1

s2 s1 s4 s3 CSci4211: Network Control Plane 72 OpenDaylight (ODL) Controller

Traffic … Engineering § ODL Lithium controller REST API § network apps may be contained within, Network Basic Network Service Functions service apps or be external to topology switch stats Access SDN controller manager manager manager Control § Service Abstraction forwarding host manager manager Layer: interconnects internal, external Service Abstraction Layer (SAL) applications and services … OpenFlow 1.0 SNMP OVSDB

CSci4211: Network Control Plane 73 ONOS Controller

Network … control apps § control apps northbound separate from REST API Intent abstractions, protocols controller § intent framework: hosts paths flow rules topology high-level specification of ONOS devices links statistics distributed service: what rather core than how § considerable device link host flow packet southbound emphasis on abstractions, OpenFlow Netconf OVSDB protocols 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 mission- specific requirements – e.g., real-time, ultra-reliable, ultra-secure • Internet-scaling

CSci4211: Network Control Plane 75