0

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).

1 Answer 1

0

I found this in the openflow 1.1 specs, I must have missed that:

When a flow entry is removed, the switch must check the flow entry’s OFPFF_SEND_FLOW_REM flag. If this flag is set, the switch must send a flow removed message to the controller. Each flow removed message contains a complete description of the flow entry, the reason for removal (expiry or delete), the flow entry duration at the time of removal, and the flow statistics at time of removal.

Therefore, what I want has been explicitly implemented in OpenFlow (at least, as of 1.1).

While I am using the OpenDaylight and am unsure whether ODL is designed to react to these messages, this answers my question perfectly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .