1. Administrivia Paper assignments for reviews 2 and 3 are out
MUD: send me your top 1—3 questions on this lecture
Gear up for course project: Sample ideas are out
Do make friends with & team up with the others in this room
Do brainstorm your own ideas with your friends and with me
Do check with me about the “significant programming” requirement
Do make the best use of office hours starting today

2. Software-Defined Networking: Principles
Lecture 9, Computer Networks (198:552)

3. Traditional IP routers
Management plane
Traditional IP routers
Management plane
Network-wide views
Configure routers
Control plane
Track topology
Compute routes
Install forwarding rules
Data plane
Forward, filter, buffer, drop, mark, rate-limit
Traffic statistics
Processor
Control plane
Data plane
BGP
OSPF
Switching
fabric
Net interface
Net interface
Net interface
Net interface

4. Problems with traditional routers
Management decisions tied to distributed protocols
Ex: Set OSPF link weights to force traffic through desired path
Ex: Non-deterministic network state after a link failure
Data and control plane controlled by vendors: proprietary interfaces ? X

5. Traditional IP network
Management plane
Control plane
Data plane
Data plane
Data plane
Data plane

6. SDN (1/2): Centralized control plane
SDN controller
Control planes lifted from switches
… into a logically centralized controller
… running in a compute cluster
Data plane
Data plane
Data plane
Data plane

7. SDN (2/2): Open interface to data plane
SDN controller
Data plane
Data plane
Data plane
Data plane

8. Some immediate consequences…

9. Small set of hardware instructions.
(1) Simpler switches
SDN controller
Data plane
Data plane
Data plane
Data plane
Small set of hardware instructions.

10. Data plane primitive: Match-action rules
Match arbitrary bits in the packet header
Match on any header, or new header
Allows any flow granularity
Actions
Forward to port(s), drop, send to controller, count,
Overwrite header with mask, push or pop, …
Forward at specific bit-rate
Prioritized list of rules
Data
Header
Match: 1000x01xx01001x
Action: fwd(port 2)
Priority: 65500

11. (2) Network programming abstractions
Application
Application
Application
Write modular apps and compose them
SDN controller
Data plane
Data plane
Data plane
Data plane

12. (3) Unified network operating system
Application
Application
Application
Network Operating System
Separate distributed system concerns from management policy
Data plane
Data plane
Data plane
Data plane
Persist app state
Graceful failover
Replication for perf

13. Composition of Policies

14. Combining many networking tasks
Monolithic application
Route + Monitor + FW + LB
SDN controller
Hard to program, test, debug, reuse, port, …

15. Modular controller applications
Each module partially specifies the handling of the traffic
Monitor
Route FW LB
SDN controller

16. Network policy as a function2
Located packet: headers + switch + port
Policy: function of a located packet
To a set of located packets: multicast, drop, forward
Function can modify packets
Headers and location 1 3
Match
Action
dstip == & srcport == 80  port = 3, dstip =

17. Parallel composition (+)
srcip ==  count
srcip ==  count
dstip == 1.2/16  fwd(1)
dstip == 3.4.5/24  fwd(2)
Monitor on source IP +
Route on
dst prefix
SDN controller
srcip == , dstip == 1.2/16  fwd(1), count
srcip == , dstip == 3.4.5/24  fwd(2), count
srcip == , dstip == 1.2/16  fwd(1), count
srcip == , dstip == 3.4.5/24  fwd(2), count

18. Example: Server load balancer
Spread client traffic over server replicas
Public IP address for the service
Split traffic based on client IP
Rewrite the server IP address
Then, route to the replica
clients
load balancer
server replicas

19. Sequential composition (>>)
srcip==0*, dstip==  dstip=
srcip==1*, dstip==  dstip=
dstip==  fwd(1)
dstip==  fwd(2)
Load Balancer
>>
Routing
SDN controller
Load balancer splits traffic sent to public IP address over multiple replicas, based on client IP address, and rewrites the IP address
srcip==0*, dstip==  dstip = , fwd(1)
srcip==1*, dstip==  dstip = , fwd(2)

20. Implications & Challenges

21. What does SDN make possible/easy?
Expressing forwarding intent directly
Example path: sw==S1fwd(4) + sw==S2fwd(1) + sw==S3fwd(7)
Reading state: Measurement through counters
Measure exactly the traffic you care about
Can modify forwarding to make measurements more accurate!
Deterministically and swiftly handle data plane failures
Google’s B4: Failover to pre-computed outcomes S1 S2 S3 4 3 1 2 7

22. What does SDN make possible/easy?
Network policy verification
Correctness: Reachability, loop-freedom, SLO violations, etc.
Performance
Better router data plane design
Decouple evolution of router instruction sets and network policy
Apply the SDN philosophy to system design as a whole
Stateful “network functions” that reside in the core of the network
Operating systems
End host NICs
<insert your idea here!>

23. Technical challenges of SDN
Scalability: controller responsible for many routers
Response time: Delays between controller and routers
Reliability: surviving failures of the controller & data plane
Consistency:
Ensuring multiple controllers behave consistently
Ensuring controller policy is faithfully implemented
Security:
Entire network may be owned if the controller is vulnerable
Interoperability: legacy routers and neighboring domains

24. Routing Control Platform (RCP)
Usenix NSDI ’05
Caesar et al.

25. Separating interdomain routing from routers
Compute interdomain routes for the routers
Input: BGP-learned routes from neighboring ASes
Output: forwarding-table entries for each router
Backwards compatibility with legacy routers
RCP speaks to routers using iBGP protocol
Installing <destination prefix, next-hop address>
Routers still run intradomain routing protocol
So the routers can reach the RCP
To reduce overhead on the RCP
RCP
Autonomous
System

26. Example: DoS blackholing
Filtering attack traffic
Measurement system detects an attack
Identify entry point and victim of attack
Drop offending traffic at the entry point
RCP
null
route
DoS attack

27. Example: Maintenance dry-out
Planned maintenance on an edge router
Drain traffic off of an edge router
Before bringing it down for maintenance
RCP
use egress 2
egress 1 d
egress 2

28. Example: Egress selection
Customer-controlled egress selection
Multiple ways to reach the same destination
Giving customers control over the decision
RCP
use egress 1
egress 1
data center 1
hot-potato routing
data center 2
customer
sites
egress 2

29. Example: Better BGP security
Enhanced interdomain routing security
Anomaly detection to detect bogus routes
Prefer “familiar” routes over unfamiliar
RCP
use egress 2
egress 1
d???? d
egress 2

30. Example: Saving router memory
Reduce memory requirements on routers
Strip BGP route attributes (except prefix and next-hop)
Combine related prefixes into a single route
BGP with other ASes
RCP
/16  nh 1
/16  nh 1
/15  nh 1

31. Discussion of RCP
Centralizing control logic allows formalizing correctness properties
… even if the existing solutions don’t actually uphold them!
e.g., loop freedom, same egress router throughout path within AS
Reliability, consistency, and performance from the start
Network partitions & RCP—network partitions
RCP replica failures
Processing high rates of route computations (e.g., IGP changes)
Performance metrics & testing methodology
Message processing: delay, throughput, memory
Real-time convergence delays: may be less than iBGP-mesh
Other metrics?

32. OpenFlow: Enabling Innovation in Campus Networks
ACM CCR ‘08
McKeown et al.

33. Program networks using simple rules
Goals: high-performance low-cost programmable switch
Be able to isolate experimental traffic on campus networks
Be consistent with vendors need for closed platforms
Restricted flexibility to keep the cost low
Controller programs switch “flow tables” built with TCAMs
First packet of a flow allows controller to determine fwding rules
Rules can match packets against flexible field boundaries
Standardized set of actions: forward, drop, de/encapsulate
Also be able to send packet through “normal” switch processing

34. Discussion of OpenFlow/SDN
Is match-action sufficiently expressive?
Can switches sustain many flow processing rules and setups?
TCAM space for matches
Control overheads to install or remove flows
Memory to install packet counters for each flow
Why fix the set of wire protocols allowed in matches?

36. Backup Slides

37. RCP incremental deployability
Simplify management and enable new services
RCP incremental deployability
Other ASes can deploy an RCP independently
Backwards compatibility
Work with existing routers and protocols
Incentive compatibility
Offer significant benefits, even to the first adopters
ASes can upgrade to new routing protocol
RCP tells routers how to forward traffic
Use BGP to communicate with the legacy routers
… while using BGP to control the legacy routers
ASes with RCPs can cooperate for new features
Inter-AS Protocol
RCP
RCP
RCP
BGP
AS 1
AS 2
AS 3

38. RCP: Scalable implementation
Eliminate redundancy
Store a single copy of each BGP-learned route
Accelerate lookups
Maintain indices to identify affected routers
Avoid recomputation
Compute routes once for group of related routers
Handle only BGP routing
Leave intradomain routing to the routers
An extensible, scalable, “smart” route reflector

39. Runs on a single high-end PC
Home-grown implementation on top of Linux
Experiments on 3.2 Ghz P4 with 4GB memory
Computing routes for all AT&T routers
Grouping routers in the same point-of-presence
Replaying all routing-protocol messages
BGP and OSPF logs, for 203,000 IP prefixes
Experimental results
Memory footprint: 2.5 GB
Processing time: msec

40. Reliability Simple replication Run replicas independently
Single PC can serve as an RCP
So, just run multiple such PCs
Run replicas independently
Separate BGP update feeds and router sessions
Same inputs, and the same algorithm
No need for replica consistency protocol
RCP
RCP

41. Potential consistency problem
RCP 1
RCP 2
“Use egress D (hence use B as your next-hop)”
“Use egress C (hence use A as your next-hop)” A B C D
Need to ensure routes are consistently assigned
Even in presence of failures/partitions
Fortunately…
Flooding-based IGP means each RCP knows what partition(s) it connects to

42. Single RCP under partition
Solution: Only use state from router’s partition in assigning its routes
Ensures next hop is reachable

43. Multiple RCPs under partition
Solution: RCPs receive same IGP/BGP state from each partition they can reach
IGP provides complete visibility and connectivity
RCS only acts on partition if it has complete state for it
No consistency protocol needed to guarantee consistency in steady state