Reading – Modular SDN Programming with Pyretic

Question 1

Why use the Pyretic programming API when the hardware itself exposes the OpenFlow
API?

Answer 1

The Pyretic API provides a high-level abstraction for SDN programmers. The OpenFlow API
exposed by devices supporting it is a low level API, on the level of assembly language. It is
inordinately difficult to develop sophisticated SDN applications with the OpenFlow API.
Additionally, the Pyretic runtime provides an efficient runtime that automatically installs
generated low level rules on hardware devices throughout the network.

Question 2

How does a network policy implemented in python and executed on a Pyretic con-troller
result in policies on OpenFlow switches?

Answer 2

First, using the Pyretic API, the programmer specifies a high level network policy. The Pyretic
runtime connects via sockets to OpenFlow clients on the network. The Pyretic runtime
interprets packets traversing these network clients against the policy, and using its socket
connection installs OpenFlow rules to implement policy behavior.
Additionally, these connections allow the Pyretic runtime to perform other actions, like
proactively installing rules to reduce network latency, reading counters, etc.

Question 3

Describe the function of the following pyretic network policy functions:
A. flood()

Answer 3

Returns one packet per local port on the network spanning tree.

Question 4

match(dstip=‘192.168.1.15’) & match(srcip=‘192.168.1.120’)

Answer 4

Two separate match predicates are composed, the result matches any packet that has
destination IP = 192.168.1.15 and source IP – 192.168.1.120

Question 5

match(dstip=‘10.0.0.8’)&raquo_space; fwd(12)

Answer 5

A single match predicate sequentially composed with another, the result of which matches
packets any packet bound for IP 10.0.08 and forwards it along port 12. This effectively “filters
out” all traffic not bound for IP 10.0.0.8.

Question 6

match(dstip= ‘10.0.0.1’) >> ( match(srcip=‘10.0.0.15’) >> drop() +
match(srcip= ‘10.0.0.25’) >> modify(dstip=‘10.0.0.30’) )

Answer 6

This policy implements a complex policy. First, all traffic not bound for IP 10.0.0.1 is filtered.
Any packets bound for 10.0.0.1 is then subject to parallel composition. If the packet is from IP
10.0.0.15, it is dropped. If the packet is from 10.0.0.25, it is returned, with the destination IP
rewritten to 10.0.0.30.