1 / 24

Parental Control on OpenFlow Status report 2012-06-13

Parental Control on OpenFlow Status report 2012-06-13. Fulvio Risso, Politecnico di Torino http://fulvio.frisso.net. Intro. Bla bla bla. General Architecture of the System. Structure of the database. General architecture of the edge node.

jafari
Download Presentation

Parental Control on OpenFlow Status report 2012-06-13

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. Parental Control on OpenFlowStatus report 2012-06-13 Fulvio Risso, Politecnico di Torino http://fulvio.frisso.net

  2. Intro • Blablabla

  3. General Architecture of the System

  4. Structure of the database

  5. General architecture of the edge node • There is a Openflow Controller “core”(based on Beacon) in which we implemented the backward learning algorithm. • On top on this simple controller there is a dispatcher that send the traffic to various application. • Zero or more App. (e.g Parental Control, Firewall, Loggging… ) Edge Node Core Dispatcher Forwarding Parental Control Logging User Apps

  6. Dispatcheriterface – How can I writeanapp? • It’s verysimilarto Beacon. • The Dispatcherprovidesan entry pointto the appsforgettingpackets data. • Eachappmustspecify 2 methodscalledby the system when the appisstarted and destroyed in whichit can save or load some data (e.g the status). • Then the system providestoeachapp a referenceto the dispathcerclass. So eachapp can asksto the dispatchertoregister a listenerforpacket in messages. • The listenermustimplement the IPacketListener interface defined in the Dispatchercomponent.

  7. IPacketListener Interface • StringgetName() • return the appnameto the dispatcher. • STATUS receive(OFPacketInmsg,IOFSwitchsw) • return: STATUS – ifCONTINUE the dispatchersend the packetto the nextappifSTOPitdrop the packet. • msg: The OpenflowPacketInobjectreference. • sw: The Openflow Switch reference. • voidsetBitMask(Bitmaskbitmask) • The Dispatcher set a bitmaskto the app.

  8. Bitmask - AppsPermissions • A userapptipicallycannotchange the forwarding algorithm or ifitonly create statisticsitcannotchange the packetpayload. • Toreachthis goal the dispather can sendlessthingsto the appscomparedto the previous interface. • E.g. if I don’t want an application to change the forwarding I must not pass the pointer to the OpenFlow switch. • The application can be awared of what are the fields passed because the dispatcher sets the Bitmask.

  9. ParentalControl • It’s anuserAppof the EdgeNode • It’s a verysimpleappthatinterceptall the DNS requestmadeby the user, itextract the domain from the query and decidesif DROP the request or forwardit. • Itcannotmodify the forwarding algorithm. It can only decide ifdrop or not the query. • Ithas 2 policies: Blacklist or WhiteList

  10. Software architecture of the edge node • Java vs JavaScript vs C++ • Beacon and Floodlight are based on JAVA. • Floodlight is a branch of Beacon. It make easier to write an app but it removes support to dynamic loading of app. (It not use OSGi). • Beacon is very powerful because of its intrinsic modularity and dynamicity. • NodeFlow is based on Javascript • It is still premature, but is very lightweight in terms of memory ( 20 MB each controller ) • NOX is based on C++ (core) we can write app in Python or C++ • It is based on modular components like beacon. But it is not dynamic

  11. Software architecture of the edge node • Some numbers • Throughput • Our user controllers are derived from Beacon • The controller bring a interface really similar to the beacon one ( we added permissions for the apps). • Some numbers • Throughput • Our user controllers are derived from Beacon

  12. Memoryusage • NOX • core 16 MB • Beacon • edgenode ~ 30 MB (onlyservlet) • corewithwebserver default ( ~ 100 MB) • FloodLight • onlytrywithbuilt-inwebserver ~ 70MB • NodeFlow • Flowvisor • 40 – 70 MB

  13. TP-link performance • In this case I wastransfering a file. The troughputwasabout~ 1 MB/s

  14. Flowvisor • FlowVisor is a special purpose OpenFlow controller that acts as a transparent proxy between OpenFlow switches and multiple OpenFlow controllers • FlowVisor creates ''slices'' of network resources and delegates control of each slice to a different controller • Slices can be defined by any combination of switch ports (layer 1), src/dstethernet address or type (layer 2), src/dst IP address or type (layer 3), and src/dst TCP/UDP port or ICMP code/type (layer 4). Edge Node Ip_src = X.X.X.1 FlowVisor Edge Node Ip_src = X.X.X.2

  15. In-band vs Out-of-band control • Out-of-band controller is simpler and faster.Its biggest drawback is that the machine in which the controller runs can not perform other services. (the service to be usable must be embedded in the controller). • E.g. We want a webserver to control the stats of the user apps and we want the user to reach it. With a out-of-band controller we must place it on another machine or embed a webserver into the controller and so implement the tcp protocol etc.. • In-band controller is slower but the same machine can do more services. The defect is that the controller machine becomes an active Openflow machine. (he need a controller or some rules to speak with the other machines)

  16. ProtocolsInterfaces Edge Node FlowVisor Edge Node Openflow Openflow Openflow Data traffic HTTP HTTP TomcatWebServer CaptivePortal – Node Manager HTTP Controltraffic

  17. Data Messages Ippacket Ippacket OFPkt_in OFPkt_out FlowVisor OFPkt_in OFPkt_out Edge Node Edge Node

  18. Control Messages – Out of Band Ippacket Ippacket OFPkt_in Ippacket OFPkt_out FlowVisor Tomcat - WebServer OFPkt_in OFPkt_out Edge Node Edge Node

  19. Control Messages – In Band Ippacket Ippacket OFPkt_in OFPkt_out FlowVisor Tomcat - WebServer OFPkt_in OFPkt_out Edge Node Edge Node

  20. Current Status

  21. Next steps

  22. The next hardware architecture

  23. Questions?

More Related