[pox-dev] Offering contribution

[Murphy McCauley]

On Nov 13, 2013, at 10:44 AM, Felician Nemeth <nemethf at tmit.bme.hu> wrote:

>>> This is what we can offer:
>>> 
>>> * a (multicast) DNS responder similar to arp_responder.py
>> 
>> Cool!  I did some stuff with mDNS back in NOX, but off the top of my
>> head, I don't think any ever made it to POX.  I did have a POX-based
>> DNS server/interceptor, though.  I think between my DNS server, your
>> dns_responder, and maybe some refactoring of dns_spy (to make it more
>> useful... maybe something along the lines of arp_helper for DNS, which
>> might have actually been useful to you), we should get some improved
>> DNS functionality into the mainline.
> 
> Users can start arp_responder like this: 
> arp_responder --<IP>=<MAC> --<IP>=<MAC>
> 
> Similarly a mainline dns_responder could take --<hostname>=<IP>
> arguments.  However, I think it would be a good addition if users were
> able to feed information to a central "knowledgebase" module at start
> time and other modules were able to query this knowledgebase.  The
> topology module reflects the actual state of the network, whereas the
> knowledgebase should contain information on the intended configuration
> of datapaths, hosts, and hosts' interfaces.
> 
> This will result in a quite flexible architecture:
> 
>      PacketIn             DNSLookup                 KBQuery
> of_01 <-------> dns_helper <--------> dns_responder <------> knowledgebase
>      PacketOut
> 
> or 
> 
>      PacketIn             DNSLookup/DNSQuery
> of_01 --------> dns_helper -----------------> dns_spy
> 
> Although, you might say it is a little bit over-engineered, the
> visualization modules of our project query a similar knowledgebase for
> geo-location info, user-friendly names instead of dpids, etc.

I've actually come to be pretty much a nonbeliever in a generic topology module; I think I'm more inclined to believe in a generic knowledgebase in general.

Your code forked before the addition of arp_helper.  Where arp_responder takes an active role which involves keeping its own knowledgebase (keeping an ARP table, possibly responding to queries, etc.), arp_helper is much thinner but can still be really useful.  All it really does is translate ARP packets into events, and makes it really easy to send replies.  I think doing the same thing for DNS may also make sense.  I think that would be useful on its own, and a thin "adapter" could then interface between it and a centralized knowledgebase.

As a sidenote, a centralized knowledgebase might also provide a nice way to handle the "which functionality should get assigned to which switch" issue (e.g., if you want l2_learning on one switch and a firewall component on another).  Currently, you have to write your own code to manage this.  I've got a sort of low-level solution that's not quite ready for merging, but... this might provide the basis of a more high-level alternative.

> The current version of our dns_responder is here:
> https://github.com/nemethf/sigcomm2013/blob/master/our_controller/dns_responder.py
> 
>>> * POXDesk enhancements:
>>> 
>>> ** enhancements to tinytopo/TopoViewer (coloring links according to
>>>  bandwidth usage, displaying symbolic names instead of DPIDs,
>>>  listening to host_tracker events.)  This application relies on a
>>>  simple statistics module from the POX side.
>>> 
>>> ** a new MapView application that displays topology/link utilization on
>>>  OpenStreetMap
>>> 
>>> ** another POXDesk application that shows link utilizations as a
>>>  function of time.
>> 
>> This is all great.  Is there anything from this in specific that you
>> think is a candidate for POX itself, or do you think it's mostly
>> additions to POXDesk?
> 
> There's an overly simplified version of NOX's statistics module called
> linkutil:
> https://github.com/nemethf/sigcomm2013/blob/master/our_controller/linkutil.py

Will take a look.

> (I wrote another flowstat module, but that isn't generic enough.)
> 
>>> * a SIGINT hander in order to remotely shut down POX,
>> 
>> Curious about that one... shouldn't SIGINT already kill it?
> 
> Hm.  I cannot remember the reason for writing it.  However, pox won't
> terminate as long as the TopoView window is open in POXDesk.

That's believable.  Handling the web request is probably done on another non-daemon thread.  There have been some changes related to shutdown, and these may have happened after your fork.  So it's possible this has been fixed.  IIRC, the current behavior is to try to shut down nicely and if that fails, eventually it should shut down anyway.  We should double check whether this works now and if not figure out why not. :)

>>> (and a SIGUSR1 hander to fire a RereadConfiguration event)
>> 
>> I wonder if this should be included on the core object?  Different
>> mechanisms (e.g., possibly something from a GUI) could trigger the
>> same event allowing for a platform independent way of reload
>> notification -- even on systems that don't have full signals.  
> 
> Yes, I think a RereadConfiguration-like event could create a good
> abstraction layer.  This event might be trigged by different ways and
> modules relying on user-configuration should listen only this event.

Yeah.  Higher-level things might choose to listen to events from a knowledgebase object at some point in the future, but the knowledgebase might still listen to this event.

Do you (or anyone) have thoughts on whether this should be an event on core or somewhere else?

>> [...]
>> Please feel free to post a link to the demo site/etc.... 
> 
> Our controller automatically creates an overlay network from PlanetLab
> nodes, distributes virtual machines and sets up routes for MPTCP
> experiments.  Of course, it uses OpenFlow to communicate with OF
> switches, but the control framework consists of additional communication
> components as well (json-rpc, ssh, rsync).  There's some details here:
> http://http://sb.tmit.bme.hu/mediawiki/index.php/MptcpPlayground
> 
> Thanks,
> Felicián