[pox-dev] Offering contribution

[Felician Nemeth]

>> 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.

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

(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.

>> (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.

> [...]
> 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