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

Liu Jian liujatp at gmail.com
Mon Jul 21 08:59:13 PDT 2008


>> 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)?
	netlink socket exchange information between userpace and kernel space, my NetlinkSocket has implemented this 
	mechanism. But, because the ns3 ipv4 was just simple simulation and contains very simple interface-address/link/route 
	information compared to linux kernel, the NetlinkSocket can only focus on the few information.
	For the Netlink route protocol we were mainly focusing on:
	1, supported:
	interface address: dump/add/delete, interface info:dump, route entry:dump/add/delete/get
	2, unsupported:
	interface info: set/add/delete
	for support quagga:
	the multicast issue due to the nozero group value was the next point.
	other netlink socket usages are all the same as the libnl.
	the multicast was used like this;	
	user creat an netlink socket and bind it to an nozero group, this socket was used to monitor
	kernel's inforamtion changes, eg, adding an address, delete an route entry. 
	when user send an request "add an adress", the kernel handle it and broadcast this information
	to its listerner(with an specified group value), the grouped socket can recv this message and do 
	some issues.
	quagga use this socket to maintained its rib with the newest state when kernel changes, now my 
	netlinksocket just send an unicast ack 	to user space and do not support this, i am planning to 
	use an static member to store these grouped sockets, add it when bind(), get it when broadcast to 
	some group.
>> 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.
	yes. libnl programs use netlink sockets, the functionality is limited by NetlinkSocket implementation
	and this simple ns3 ipv4 supporting i memtioned above.
>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 not sure what the libnl can do with ns3, this lib porting was just for NetlinkSocket
	testing. there have test code for netlink socket in NS3 space and process space alrealy. 
	but this experience maybe helpful to quagga porting, may be the steps was similar.

>Can you or Mathieu bring the repository current with ns-3-dev, or is 
>there a blocking issue?
>Given that we are aiming for mergeable code by the end of this project, 
>I think we should discuss what the merge steps might be.  It depends on 
>ns-3-simu branch, so should that repo be going in as a first step?
	here need to be discuss with mathieu.
>Broadly, should the plan be:
>1) brink ns-3-simu up to date and plan to merge it
>2) in parallel, solve the broadcast/multicast Netlink issue
>3) merge libnl and corresponding unit test program
>4) move on to quagga
	i will fix this broadcast issue as soon.
	and before move on to quagga, the simu_xxx support should be done first, other than the netlink broadcast.
>I don't know whether John Moy's ospfd (which uses linux netlink) would 
>be an easier initial routing daemon to try, compared to quagga.
>I do see some usefulness of trying to use some real netlink client 
>program to try to exercise the code.
>- Tom

        Liu Jian
        liujatp at gmail.com

More information about the Ns-developers mailing list