This makes it easier to install the headers, or to use them directly from
another software package with -I$(openflow)/include, without invading
the top-level include file namespace.
Allow vendors to define their own actions. Actions were originally fixed-
length, which was a bit constraining. Actions now contain a length field,
which gives them more flexibility.
The original packet-out format allowed multiple actions to be specified for
buffered packets, but only a destination port for messages including data.
This change makes packet-out more consistent by allowing multiple actions
regardless of how the packet is stored.
This change also disallows sending packets through the incoming port without
explicitly using the OFPP_IN_PORT virtual port.
This updates the OpenFlow protocol version and changes the names of
structure members, so any software that uses OpenFlow will need to be
updated to match.
Before, if a hub connected a number of OpenFlow switches and the controller,
then in-band control traffic from one of the OpenFlow switches would be
seen by each of the other switches and forwarded up to the controller as
an ofp_packet_in message. That message would then be seen by all of the
other OpenFlow switches and also forwarded, and so on in an infinite loop.
This change prevents this situation by keeping secchan from forwarding
ofp_packet_in messages for a packet destined to the controller that
arrives on the port where the controller is located.
This code has at least two weaknesses. First, if the controller's port
changes, then the flows set up to drop packets will not be deleted. This
should not be a major problem: if this inadvertently kills a switch's
connection to the controller, then the switch will realize it after it
stops receiving data and re-connect. Its new connection will have new
flow data and therefore its packets will not be dropped.
Second, the notion of the "controller's port" does not take into account
the possibility of loops in the network topology. We need spanning tree
protocol for that.
It can happen that the secure channel thinks that it is connected
to the controller, but in fact the connection has dropped. For
example, a switch intermediate between the secure channel and the
controller could have a flow inserted, due to a malfunction, that
causes packets in one direction or the other to be dropped. When
this happens, the Linux kernel's TCP implementation will continue
retransmitting packets for somewhere between 13 and 30 minutes,
depending on the connection's retransmission timeout (according
to linux/Documentation/networking/ip-sysctl.txt) with the default
Linux settings.
We want to detect the lost connection and re-connect much faster
than that. We use OpenFlow echo request and reply messages: if
no message is received from the controller for N seconds, we
send out an echo request. If no reply (actually, any message at
all) is received for an additional N seconds, then we assume
that the connection has been lost, and reconnect.
This has two notable omissions. First, only at most 4k of flow statistics
are reported. Second, aggregate statistics are not yet supported. Both
of these are fairly easily fixable, just not fixed yet.
Until now, vconn_connect() has always completed the connection
synchronously, blocking as necessary. In the userspace
switch, we want to be able to continue forwarding packets even
if the connection to the controller drops. Thus, this change set
that makes that possible.
The approach taken is perhaps more ambitious than needed, as it
actually adds a new high-level mechanism for polling on arbitrary
file descriptors. This necessitates quite a bit of change to
each of the userspace programs that use vconns, but it also has
the effect of simplifying them. The new structure of these programs
is a lot less fragile than the old one (which tended to end up
livelocking or hanging when something wasn't quite right), so it
seems like the changes are worth it.
Ben Pfaff
Justin Pettit
Ben Pfaff
casado
Martin Casado