This question might come off as slightly hypothetical, but I couldn't figure how else to ask it.
The OpenFlow protocol has a feature which lets its rules get deleted when no traffic matches them. This feature is called the "idle timeout".
In a paper, it's stated that typical OpenFlow link discovery is not scalable, because the Controller has to interact with many packets. So I started thinking about a way to continuously poll links without having the controller continuously looking at what was happening. I came up with the following idea:
Detect all new ports (like, every 5 minutes or something), then install rules which idletimeout in 2 seconds, and send exactly one packet on each link. The idle-timeouting rules will make the packet loop on the link.
Apart for the potential for abuse, and the potential to suck up a megabyte per second of traffic with a single packet, the desired behavior should be clear:
If the link is taken down, or there is saturation on the link, then the packet will be lost and the rules will idle-timeout after two seconds. This can be detected with the Controller, and seems more elegant than to continuously send packets to make sure "everything is alright".
My issue is that this would still require the Controller to poll the installed rules on the relevant table, which still feels like an annoying amount of work.
Wouldn't it be simpler if OpenFlow could be ordered to advertise when a specific rule is uninstalled?
Would that be a realistic add-on, given the current implementation of OpenFlow (or is this already implemented)?
By design, it seems OpenFlow is close to be able to do such messaging, and it seems that by the way OpenFlow is implemented, timeouts can be critically important (although not all of them).
