SDN: Week 5: Programming SDNs: Module 6.2: Frenetic

[gdt]

Three steps of SDN programming
1. read and monitor network state
2. compute policy
3. write policy

Issues with reading state:
Conflicting rules
- traffic counters: a rule counts bytes and packets, controller polls counters
- multiple rules can exist, and these can conflict. Solution: predicates. eg: (srcip != 1.2.3.4) && (srcport == 80)
- run time system translates predicates into OpenFlow match patterns

Limited rules in switches
- limited number of rules which can be installed on switch: can't push all rules to the switch.
eg: counts of traffic by IP address. We can't preload the switch with all possible IP addresses. Solution: dynamic unfolding where program says GroupBy(srcip) and runtime system dynamically adds match patterns.

Unexpected packets to controller
- unexpected packet punted to controller, controller sends rule to switch for subsequent packets
- but say another packet gets punted before rule is installed
- suppress extra events, using a clause like Limit(1)

Frenetic
- SQL like query lanugage
- get what you asked for, nothing more, nothing less
- returns a stream of packets
- controller overhead minimised: filters using high-level patterns, limits num of values return, aggregates by number and size of packets.
- eg: Traffic Monitoring. Select(bytes) Where(in:2 & srcport:80) GroupBy([dstmac]) Every(60)
- eg: Learning Host Location/Port. Select(packets) GroupBy([srcmac]) SplitWhen([inport]) Limit(1)

Coming up next: Computing policy
- many modules can affect same traffic
- they might conflict: eg: routing says output to port, but firewall says to block

Summary:
- Looked at SDN programs to read network state
- Frentic: SQL-like query language to control the traffic seen at the controller
- Coming up: other challenges: composing policy, responding to events, compilation