Formal Modeling of an Openflow
Switch using Alloy
Natali Ruchansky and Davide Proserpio
Outline
Background



Openflow
Alloy
Our model




Inside the switch
Functionalities
Properties (some of them)
Extensions and future work

2
SDN and Openflow
Software Defined Network (SDN)


decoupling between data and control plane access
Openflow


a standard interface for controlling computer network switches

Simplify networks administration

Very useful for research
3
Openflow scenario (Switch)
4
Alloy

Language and tool for relational models

Mixture of first order logic and relational algebra

Applications



5
Find security holes
Verify specifications (e.g. switching networks)
…
Our switch model
We model a Snapshot



Not a working system!
Possible events at any specific instance
We provide a context network






Network
Controller
End Hosts
Switches
Packets
Extend Nodes
Simplest network: 2 hosts, a switch and a controller

6
What the (simplified) model looks like
7
Inside the Switch
Tables


Pipeline line implementation

Exists first/last table, no loops
Entries (flows)


Match fields


Instructions


Compare to packet headers
indicate what to do with packets
Counters

Keep track of statistics
Ports



8
Connect nodes
Every port has an owner
Functionalities
Packet handling


Checking for a match and act accordingly
Table modification


Add and delete
Messaging


Openflow


9
Controller-to-switch, asynchronous, symmetric
Data
Example: Add and Delete

Flow table modification messages

Add


If overlap flag & overlap: drop
No overlap flag: insert (replace if identical) entry
//Add entry to a table
pred add[t,t':Table,e:Entry]{(t'.entries=t.entries+e)}

Delete


Strict (delete identical entries)
..and not strict version (delete all overlapped entries)
pred delete[t,t':Table,e:Entry]
{e in strictEntry =>t'.entries=t.entries-e
else t'.entries=t.entries-findOverlap[e,t]}
10
Properties implemented (some)
NoForwardingLoop
1.

This is ensured by checking that a packet entering a switch has not
previously entered the switch.
NoBlackHoles
2.

No packet mysteriously disappears from the system.
EchoAwareness
3.

In our model, the Switch can be in two states – either it has received
an echo reply, or it is awaiting one.
NoForgottenPackets
4.

Any packet the Switch receives is eventually processed
CorrectInstall
5.

11
Upon receipt of a new flow rule, the installation is correct.
NoForwardingLoop

We check for every packet if it has already been
received/sent by any port of the switch
pred noForwardingLoop[s:Switch, p:Packet]
{no port:s.ports | port in (p.seen)}
12
EchoAwareness

the Switch can be in two states – either it has received an
echo reply, or it is awaiting one.
//send echo
pred Switch.echoTest[]
{this.s2c_sendPacket[s2cPacket,s2cPacket,EchoT3] &&
this.connectionStatus=waiting}
//change status
pred Switch.Echo[type: Type,]{type=EchoT1 =>
this.s2c_sendPacket[s2cPacket,s2cPacket,HelloT]
&& type=EchoT2 =>this.connectionStatus=acked}
13
More properties

FIFOprocessing


InstantOFRespones


the model does not have a queue – we chose to set any
queueing aside and have Packets processed on a first-come
first-serve basis.
When a Switch receives an Openflow message from the
Controller, it answers right away
NoForgottenPackets

14
Any packet the Switch receives is eventually processed
Extensions

Notion of “time” (Done)

Implemented using module Ordering

Group tables and group types

Test specific applications/protocols
15
Thanks!
16