[ovs-dev] [PATCH 00/17] Run-Time Open Flow Version Configuration

Ben Pfaff blp at nicira.com
Thu Oct 4 17:39:23 UTC 2012


On Thu, Oct 04, 2012 at 11:41:15AM +0900, Simon Horman wrote:
> This seires adds a command line options to ovs-vswitchd and various
> utilities to allow the range of Open Flow versions to be set at run-time.
> 
> The options are --max-ofp-version and --min-ofp-version.
> The values accepted are: OpenFlow10, OpenFlow11 and OpenFlow12.
> The default for both options is OpenFlow10 which means
> that by default the behaviour is unchanged.
> 
> You mentioned to me in passing a month or so back that you
> envisaged some or all of this configuration residing in the database.
> I am happy to change the code accordingly if you give me some guidance
> on what and how configuration should be stored in the database.
> 
> One problem with the max/min scheme is that although I believe
> it is in keeping with the spec it does not take into account
> that Open vSwtich doesn not have a working implementation of OpenFlow11.
> 
> Or in other words, with these options in place if the negotiated
> version is OpenFlow10 or OpenFlow12 then things should work well,
> buts and a small number of outstanding OpenFlow12 features not
> withstanding, but if the negotiated version is OpenFlow11 then the
> session will be terminated.
> 
> It ought to be possible to resolve this in the case that Open vSwtich
> code is on both sides of the session - e.g. by teaching the Open vSwtich
> code how to skip OpenFlow11 or providing a list of acceptable versions
> rather than a range. However, I'm unsure of a mechanism to do this that
> is within the OpenFlow spec.

I have some feedback on the approach above.  (I haven't looked at the
patches yet.)

First, on the mode of configuration.  I would suggest that the
supported protocol(s) should be configured through the database.
There are multiple logical places to configure it, but I think that
the best place to start is the Bridge table.  One could add, for
example, a column named 'protocols' whose possible values are zero or
more from a list (such as OpenFlow10, OpenFlow11, OpenFlow12 as you
suggest above).  When the 'protocols' column is empty, then some
default would be used.  The default could be OpenFlow 1.0 only, for
maximum backward compatibility; we could broaden the default over time
as other protocol versions become well-supported.

Another possible place to configure the supported protocols would be
in the Controller table, if we want to have per-controller
configuration, but I think we could add that later if it proves useful
in practice.

I suggest a list of supported protocols, instead of a min/max, because
ONF recently standardized a way to negotiate a set of protocols rather
than a range.  Do you have access to the OpenFlow 1.3.1 standard?  (It
doesn't seem to be on the opennetworking.org website yet.)  It is in
there.



More information about the dev mailing list