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