Formal Modeling of an Openflow Switch using Alloy

Natali Ruchansky and Davide Proserpio

2

Outline Background

Openflow Alloy

Our model Inside the switch Functionalities Properties (some of them)

Extensions and future work

3

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

4

Openflow scenario (Switch)

5

Alloy Language and tool for relational models

Mixture of first order logic and relational algebra

Applications Find security holes Verify specifications (e.g. switching networks) …

6

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

Simplest network: 2 hosts, a switch and a controller

Extend Nodes

7

What the (simplified) model looks like

8

Inside the Switch Tables

Pipeline line implementation Exists first/last table, no loops

Entries (flows) Match fields

Compare to packet headers Instructions

indicate what to do with packets Counters

Keep track of statistics

Ports Connect nodes Every port has an owner

9

Functionalities Packet handling

Checking for a match and act accordingly

Table modification Add and delete

Messaging Openflow

Controller-to-switch, asynchronous, symmetric Data

10

Example: Add and Delete Flow table modification messages

Add If overlap flag & overlap: drop No overlap flag: insert (replace if identical) entry

Delete Strict (delete identical entries) ..and not strict version (delete all overlapped entries)

//Add entry to a tablepred add[t,t':Table,e:Entry]{(t'.entries=t.entries+e)}

pred delete[t,t':Table,e:Entry] {e in strictEntry =>t'.entries=t.entries-e  

else t'.entries=t.entries-findOverlap[e,t]}

11

Properties implemented (some)

1. NoForwardingLoop This is ensured by checking that a packet entering a switch

has not previously entered the switch.

2. NoBlackHoles No packet mysteriously disappears from the system.

3. EchoAwareness In our model, the Switch can be in two states – either it has

received an echo reply, or it is awaiting one.

4. NoForgottenPackets Any packet the Switch receives is eventually processed

5. CorrectInstall Upon receipt of a new flow rule, the installation is correct.

12

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)}

13

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 statuspred Switch.Echo[type: Type,]{type=EchoT1 => this.s2c_sendPacket[s2cPacket,s2cPacket,HelloT]

&& type=EchoT2 =>this.connectionStatus=acked}

14

More properties FIFOprocessing

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.

InstantOFRespones When a Switch receives an Openflow message

from the Controller, it answers right away

NoForgottenPackets Any packet the Switch receives is eventually

processed

15

Extensions Notion of “time” (Done)

Implemented using module Ordering

Group tables and group types

Test specific applications/protocols

16

Thanks!