[Ns-developers] [GSOC:quagga-porting] status reports

Sun Jul 20 10:43:01 PDT 2008

Hi, thanks for this summary; some comments inline below

Liu Jian wrote:
> hi all,
> 
> As methieu suggested, i give an detailed intruction about my project.
> code location: http://code.nsnam.org/lj/quagga-porting/
> 
> 1, netlink socket.(files at: src/node/netlink-xxx.h/cc)
> 
> it is a subclass of Socket, and has the uniform send/recv socket APIs.
> 
> the point is how to serilize/desirilize an netlink message. the netlink message is not as simple as an 
> IP header, but it has an alterable payload message body due to different message type. So i take the 
> whole message(header and payloads) as an Header, all different payload has its own seri/deseri api 
> partly followed the Header class(netlink-message.h/cc and netlink-messge-route.h/cc).
> 
> another point is to simulate how the linux kernel handle the netlink messages. The kernel is very 
> complicated, i just simple implement it. 

do you have a summary somewhere of which pieces are implemented now, and 
which are not supported?

do you have an idea of what pieces of kernel support may be missing for 
supporting quagga (other than the broadcast issue you mention below)?

> 
> the line how the message passed is:
> user socket send an request to kenerl, the kernel netlink socket recv it and handle it, then send ack back 
> to user-space socket. where in my NetlinkSocket, there no kernel socket exist. when NetlinkSocket call 
> send() to transfer an message, Socket handle it directly as kernel, then send the ack/message back to 
> its own recv-queue.
> 
> this simplied implementation can support the message exchange between userspace and kernel process when 
> sockaddr_nl's group value is 0, which called the unicast message, and it was not supportable for 
> broadcast when this group value is nozoro.  when broadcasting message, kernel should send the 
> ack/response message to the sockets which were in the defined group, but now there no mechanism to 
> manage and classify the sockets. so the broadcast was NULL. but the NetlinkSocket unicast is OK for 
> simply use.

there seems to be a third service model to support: multicast

> 
> About the Netlink protocol, i were just focusing at NETLINK_ROUTE, and for quagga use, just aim at three 
> class of message(interface address, interface info, route enrty) with operations(add/delete/get).

this seems to be a reasonable scope

> After learing how the kernel code handle the message, i use the ipv4 APIs to implemented them. Because  
> the ns3 is an simulte tool, it has not so much inforamtion as the real kernel. an example: route entry. 
> ns3 IPv4route entry only has dest and interface members but netlink route has more than 10 attributes, 
> so NetlinkSocket was an simple simulation based on the NS3 ipv4 contents.
> (the example code at netlink-socket-test.cc) 
> 
> 2, libnl port
> libnl is an library using netlink socket, it provide user many brief programs to manage and operate 
> route inforamtion and others. mathieu suggest me to port it and make it run on top of ns-3-simu, being 
> aim at testing my NetlinkMessage seri/deseri , learing how the real-world netlink socket be used and 
> improving NetlinkSocket.
> 
> Because libnl is an real-world application, i use the src/process simu module to do with it, which has 
> the posix APIs and definetions.
> files at : src/porting
> the steps:
> 1, define some macros to replace the real world definitions with SIMU_XXXX(at src/porting/porting-
> types.h) 
> 2, replace the real world head files"#include<system-headfiles>" with simu head files 
> "#include<simu_headfiles>". 
> 3, replace the system call xxx() with simu_xxx() in libnl source files. 
> 
> For the three steps, i added some simu_xxx() and SIMU_XXX the libnl used in process module , because the 
> process module were also on working by mathieu and many were unsupportable.
> 
> libnl programs locate at src/porting/libnl/src/*.c, there were all real-world application. 
> ns-3-simu/process module provide mechanism to run programs on top of ns3, so, for porting, where i 
> create an program "libnl-test" (src/porting/libnl-test.cc) to run libnl at an better defined ns3 Node.
> 
> As for nl-addr-dump program, change the name int main(int, char*[]) to nl_addr_dump(int, char*[]), then 
> ns3 node can run it as an process.
> just like ns3 programs, it run as:
> ./waf --shell;
> cd build/debug/src/porting
> ./libnl nl-addr-dump xml
> then it dump the current node's interface address inforamtion through NS3 NetlinkSocket.
> 
> now i have tested 8 programs:nl_addr_dump, nl_link_dump, nl_route_dump, nl_addr_add, nl_addr_delete; 
> nl_route_add, nl_route_delete, nl_route_get. they all run normally.

yes, I tried several of those

> 
> so, i am not sure if this can be claimed to a milestone success, for the NetlinkSocket is still not 
> strong enough though is can be simply used. 

If I understand correctly, I think you are saying that, at this point, 
the functionality of libnl is limited by the NetlinkSocket 
functionality, but that libnl should be able to do now whatever is 
supported underneath.

I am not sure where next to go with libnl; maybe Mathieu has some plans. 
  It seems like what would be required next would be to either find some 
routing daemon or test suite that uses libnl and try to run it in the 
process environment, or to write a custom test program to more fully 
exercise the libnl functionality.  For the first case, it seems to me we 
might as well be focusing on the original task (quagga, or something 
like Moy's ospfd that uses raw netlink sockets).

As for test code, we overall need some kind of test framework for the 
netlink code.  Should this test code be based at the process level?  I 
am not sure who is going to write native ns-3 code using netlink 
sockets.  If so, should there be a small test suite in the process space 
that uses libnl?

> 
> i am planning to step foward to quagga porting, but one problem is the broadcast way the netlink used, 
> which is also used by quagga, currently, i have no clear thoughts about howto.

It seems to me that the semantics of these messages are roughly 
publish/subscribe, so I wonder whether we can somehow use the callback 
framework for this.