<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.3">
</HEAD>
<BODY>
On Mon, 2009-09-14 at 17:02 -0700, Ben Pfaff wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Do you have an idea for a "harmless" packet to send though? I'm
concerned that we could send out a packet that either would
confuse the controller ("WTF is that? I don't know anything
about that MAC address!") or that it would just ignore and not
reply to.
</PRE>
</BLOCKQUOTE>
I've a couple of alternative suggestions. These may already have been considered and rejected for good reasons, but I wanted to make sure:
<UL>
<LI>Could we depend on the openflow protocol connection establishment protocol? It seems like the controller could reject the openflow connection at three points 1) before any openflow messages are sent (for example if the TLS handshake fails), 2) if the hello handshake does not contain compatible openflow versions, 3) if there is something in the response to the features request the controller doesn't like (for example a duplicate DPID). Unfortunately, as I read the spec at least, there is no positive acknowledgment of any of these stages. Instead, the controller sends errors and terminates the connection if it doesn't like how things are proceeding. However, we could do something like have a user-configurable timeout for which the switch will wait at each of these stages. If the switch gets past sending the features response (stage 3) and the timeout expires without the controller terminating the connection, the switch could conclude the connection is good and then start using it.
<LI>Could we use OpenFlow echo request/reply messages? We're using these now to determine the health of the connection when no messages have been sent for a period of time anyway. We could send one as early as immediately after the initial hello if that isn't a protocol violation and depend on the reply coming within a user configurable time as well.
</UL>
Regardless of these mechanisms, we still probably need a mechanism for timing out connections for which the controller never sends any data but holds the TCP connection open, etc. I'm sure these already exist and would be addressed by the changes already suggested, but include them for completeness.<BR>
<BR>
--- Keith
</BODY>
</HTML>