SDN: Week 5: Programming SDNs: Module 6.4: Pyretic

Pryetic:
- SDN language: express high level policies
- runtime: "compiling" those policies to OpenFlow rules

Packets have location as an attribute.

Features of Pyretic:
- Write network policy as a function. Input a packet. Return packets at differing locations.
- Boolean predicates. AND, OR, NOT. Rather than OpenFlow exceptions.
- Virtual packet header fields. Such as locations, operator-applied tags.
- Parallel and sequential composition operators.

Network policies:
- OpenFlow (match, action) bit patterns are tough to reason about.
- Pyretic policies are functions which map packets to other packets.
identity returns original packet
none returns empty set
match(f=v) returns identity if field f matches value v, otherwise none
mod(f=v) returns packet with field f set to value v
fwd(a) returns mod(outport=a)
flood() returns one packet for each port on the network spanning tree

Boolean predicates
- OpenFlow packets either match or "fall through" to next rule. Simple OR, NOT are tough
- Pryetic match() outputs the packet or nothing depending on the predicate
eg: match(dstip=10.0.0.3) | match(dstip=10.0.0.4)

Virtual packet headers
- unified way of representing packet meta-data (ingress port, etc)
- packet is a dictionary which maps a field name to a value
- match(inport=a), match(switch=T), match(dstmac=b)
- use mod() to change or add meta-data

Policy composition
- sequential. eg: match(dstip=2.2.2.8) >> fwd(1)
- parallel. eg: (match(dstip=2.2.2.8) >> fwd(1)) + (match(dstip=2.2.2.8) >> fwd(2))

Traffic monitoring
- create a query to see packet streams
eg: return first packet seen on a switch of a previously-unseen MAC address

self.query = packets(1, ['srcmac', 'switch'])
self.query.register_callback(learn_new_MAC)

- callbacks invoked for each match to query

Dynamic policies
- polices who's forwarding behaviour changes
- represented as a timeseries of static policies
- current value is self.policy
- common idiom: set a default policy, register query callbacks to update policy
eg: learning switch

pyretic.py pyretic.examples.simple_learner

eg: firewall

pyretic.py pyretic.examples.simple_firewall

Summary
- Pyretic makes writing complex policies easy:
- network policy as function
- predicates on packets
- metadata as packet headers
- policy composition
- composition makes it easy for one module to build upon another

SDN: Week 5: Programming SDNs: Module 6.3: Concepts of composing SDN control

Networks perform many tasks
- could use a monolithic application (count, route, firewall, load balance, etc). Difficult to program, test, debug, reuse, port.
- solution: modularise control. monitor program, routing program, firewall program, etc.
- getting modules to play nice
- controller has to arbitrate between modules. These aren't "tenants" with parts of the network to themselves. Different modules affect the same traffic.
- solution: composition
- parallel composition. Multiple operations simultaneously. eg: counting and forwarding.
- sequential composition. One operation, then another. eg: firewall, then switch.

Example application of parallel composition: monitor arriving traffic, route traffic by dst prefix
- parallel composition: do both simultaneously

srcip == 5.6.7.8, dstip == 1.2.0.0/16 ---> fwd(1), count
srcip == 5.6.7.8, dstip == 3.4.5.0/25 ---> fwd(2), count
...

- note that the rules can be installed in any order

Example application of sequential composition: server load balancer
Sequence is:
- split traffic based on client's ip src addr
- rewrite server dst ip addr
- route traffic to replica

Can use a predicate to control which modules see which traffic
eg: if port 80 then load balance, then forward; else count and forward

A module should not specify everything:
- leave flexibility to allow other modules to exist
- avoid trying module to a specific setting
- eg: a load balancer spread the traffic across the replicas, but leaves determining network paths to the routing.

A module should have a abstract view of the topology
- "separations of concerns" by "information hiding", as per programming languages, for the same reasons
- so present a simple network rather than the complex reality
eg: a load balancer doesn't see any routing changes

Summary:
- SDN control programs perform many tasks on the same traffic
- this requires
1. compositional operators. How to compose the policies
2. logical switch abstraction. Hiding irrelevant details.

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

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

SDN: Week 5: Programming SDNs: Module 6.1: Motivation for northbound APIs

OpenFlow programming is not easy
- difficult to perform multiple independent tasks
- low level of abstraction
- controller only sees packets for events it does not know how to handle
- race conditions, avoid incorrect installation of rules

Solution: northbound API
- programming interface which allows applications and orchestration systems to program the network (not just an individual switch)
- uses: path computation, loop avoidance, routing, security
- users: sophisticated network operators, service providers offering value-added services, vendors, researchers. In short: people wanting to offer services over OpenFlow
- benefits: vendor independence, ability to quickly modify or customise control
- eg: present network as one large virtual switch, security, TE, security, middlebox integration
- goals: orchestration of high-level services

Summary:
- OpenFlow is a southbound API which controls a switch
- it makes it possible to program a network, but doesn't make it easy
- northbound API offers: sophisticated events, composition of policies, error handling