On Fri, Jun 14, 2013 at 04:14:19PM +1200, Sam Russell wrote:
Thanks for the reply. I think the kernel/iface stuff is a little bit more complicated than you've explained - there are lots of places around the code where calls are made directly rather than referring to the functions in the proto structure.
Well, we should discuss separately kernel protocol and device protocol. Kernel protocol is essentially just another protocol (there is one small hack when kernel protocol abuses attached kernel table by temporarily storing dummy routes in it but this is irrelevant here), You could easily run BIRD without kernel protocol and therefore you could just have another protocol syncing with SDN forwarding core, which is not really different than any other protocol (say BGP) from the BIRD core point of view. Device protocol is a bit more complicated. It is the only protocol that do not generate routes but ifaces and there are a few hacks (mostly in nest/proto.c): 1) Already mentioned kif_choose_primary() (which is not really important and will go away) 2) initial_device_proto in proto_init(), protos_commit() which forces which forces device proto to be initialized first. 3) Call to if_flush_ifaces() in proto_flush_loop(), this flushes all ifaces regardless of protocol that generates it. and perhaps some more bits. But there is one much bigger problem related to replacing device protocol - interface names and IDs from struct iface are often directly used when interacting with OS (like sending packets on specific iface or enabling receiving multicast on that iface). There are three posibilities: 1) Create some iface flag marking iface 'virtual', such iface cannot be used for these purposes, but this makes them more or less useless (you could have routes with gw on that iface, but you cannot run OSPF on that iface) 2) Virtualize whole BIRD socket interace, but this esssentially means reimplementing TCP/IP stack in BIRD. 3) For each SDN/OpenFlow iface create one TUN/TAP iface (on OS level) which will be used for tasks like sending OSPF packets to that iface. I think that the third option is the only realistic one. In that case BIRD SDN/OpenFlow protocol (or even some other daemon) would create TUN/TAP devices in OS and work as backend for them. You don't even need replacement for device protocol - standard device protocol would work with TUN/TAP devices. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."