In this lesson we will look at Pyretic
which is an SDN language, and run time that
implements some of the composition operators that we
discussed in the last lesson. The language is a
way of expressing these high level policies, and
the run time provides the function of compiling these
policies. So, the OpenFlow rules that are eventually are
installed on the switches. One key abstraction in Pyretic
is the notion of located packets. The idea that we can apply a policy based on
a packet and it's location, in a network.
Such as the switch, at which that packet is
located or the port on which that packet
arrives. Pyretic offers several features. The first is, the
ability to take as input a packet, and
then return packets at different locations in the network.
This effectively allows the implementation of network
policy as a function, that simply takes packets
and returns other packets at different locations.
The second feature of Pyredic is the notion
of Boolean predicates. Unlike open flow rules,
which do not permit the expression of simple
conjunctions such as and, and or, or negations
like not. Pyredic allows the expressions of policies
in terms of these predicates. Pyredic also provides
the notion of virtual package header fields. Which
allows the programmer to refer to packet locations
and also to tag packets so that specific
functions can be applied at different portions of
the program. Pyretic also provides composition operators, such
as parallel and sequential composition, which we discussed
in the last lesson. The notion of network
policy as a function contrasts with the
Open Flow style of programming. In OpenFlow,
policies are simply bit patterns. In other
words, match statements for which matching packets are
subject to a particular action. These types
of policies can be particularly difficult to
reason about. In contrast, in Pyretic, policies
are functions that map packets to other packets.
Some example functions in Pyretic include the
identify function, which returns the original packet,
none or drop, which returns the empty
set, match which returns the identity if the
field f matches the value v and returns none or drop otherwise. Mod, which
returns the same packet with the field f set to v. Forward, which is simply
syntactic sugar on mod. To say that, the
output port field in the packet should be
modified to the parameter specified and flood which
returns one packet for each port on the
network spanning tree. In open flow, packets either
match on a rule, or they simply fall
through to the next rule. So, or, not,
Ect can be tough to reason about. In contrast,
peretics match function outputs either the
packet or nothing, depending on whether the
predicate is satisfied. For example, we could
apply a match statement that says match
destination IP equals ten zero zero three.
And this function would take packets as
input and only return packets that satisfy
this particular predicate. In addition to the
standard packet header fields, Pyretic offers the notion
of virtual packet header fields, which is a
unified way of representing packet metadata. In Pyretic,
the packet is nothing more than a dictionary that
maps a field name such as the destination
IP address to a value. Now, these field names
could correspond to fields in an actual packet
header. But they can also be virtual. For example,
we could provide a match statement based
on a switch, indicating that we only want
to return packets that are located at a particular switch or on the input port,
indicating that we only want c packets
whose attributes match a particular input port. The
match function matches on this packet meta-data
and the mod function can modify this meta-data.