Building in OpenFlow/SDN support

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130614/6d97673b/attachment-0001.asc>