Composing Software Defined Networks

… realize these abstractions in Pyretic, an imperative, domain-specific language embedded in Python.

… build a single application out of multiple, independent, reusable network policies that affect the processing of the same traffic.

2015/10/10 01:59:46

previous: support multiple concurrent tasks (each controls its own slice) — a disjoint portion of traffic, over which the tenant or application module has (the illusion of) complete visibility and control.

SDN offers network-wide visibility and direct control over the underlying switches from a logically centralized controller. … today’s SDN platform … limited support fro creating modular applications …

composition operators

flexible constructs that build network applications out of simple independent components: however, programmer must specify policies in terms of the underlying physical topology …

abstract topology

network object has three key elements: a topology, a policy, and, for derived networks, a mapping … Pyretic constructs … programmer simply specifies the mapping between elements of the topologies, along with a function for calculating forwarding paths through the underlying topology, and Pyretic calculates correct implementation automatically.

abstract packet model

2015/10/15 09:31:47

Compared to conventional platforms [7, 12, 2, 3, 19], our Pyretic language raises the level of abstraction by introducing an abstract packet model, an algebra of high-level policies, and network objects.

2015/12/02 18:46:06

3.2 High-Level Policy Functions

A static policy: is a “snapshot” of a network’s global forwarding behavior, represented as an abstract function from a located packet to a multiset of located packets.

… Of course, one cannot build many useful network applications with just a single static, unchanging policy. To do so,

✓

one must use a series of static policies (i.e., a dynamic policy).

3.2.2 From Static Policies to Dynamic Applications

Doing so illustrates a common Pyretic programming paradigm:✓ One may develop dynamic applications by constructing parameterized static policies, listening for network events, and then repeatedly recomputing the static policy using different parameters as the network environment changes … building up a somewhat more complex policy by defining a collection of ordinary Python functions that compute simple, independent components of the policy, which are subsequently composed together.

5.2 putting it all together

the correct processing order of load balancer and firewall turns out to be direction-dependent

The firewall must be applied before load balancing for incoming traffic from clients — as the firewall must consider the original IP addresses, which are no longer be available after the load balancer rewrites the destination address that of a replica.
In the other direction, the load balancer must first restore the original IP address before the firewall is applied to packets returning to the client.