1 / 16

Formal Modeling of an Openflow Switch using Alloy

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. SDN and Openflow. Software Defined Network (SDN)

calvin
Download Presentation

Formal Modeling of an Openflow Switch using Alloy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Formal Modeling of an Openflow Switch using Alloy NataliRuchansky and DavideProserpio

  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. Openflowscenario (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 table predadd[t,t':Table,e:Entry]{(t'.entries=t.entries+e)} preddelete[t,t':Table,e:Entry] {e instrictEntry =>t'.entries=t.entries-e   elset'.entries=t.entries-findOverlap[e,t]}

  11. Properties implemented (some) • NoForwardingLoop • This is ensured by checking that a packet entering a switch has not previously entered the switch. • NoBlackHoles • No packet mysteriously disappears from the system. • EchoAwareness • In our model, the Switch can be in two states – either it has received an echo reply, or it is awaiting one. • NoForgottenPackets • Any packet the Switch receives is eventually processed • 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 prednoForwardingLoop[s:Switch, p:Packet] {noport: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 predSwitch.echoTest[] {this.s2c_sendPacket[s2cPacket,s2cPacket,EchoT3] &&this.connectionStatus=waiting} //change status predSwitch.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 queueingaside and have Packets processed on a first-come first-serve basis. • InstantOFRespones • When a Switch receives an Openflowmessage 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!

More Related