Transcript view
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