OpenFlow 1.1 was released about 9 months ago. Open vSwitch doesn't
yet have support for this protocol version. Furthermore, OpenFlow 1.2
will likely be released by the end of 2011.
We would love to work with the OpenFlow community to make sure OVS
supports current and future versions of OpenFlow. We can't do it
alone, and as an open-source project OVS is ideally suited to working
on this together. We are therefore inviting code contributions from
those interested in an open, production quality OpenFlow 1.1 and 1.2
implementation.
We recognize the importance of these new protocol versions to the
OpenFlow community, but we cannot dedicate enough development time to
implement them in a timely manner.
I've done a significant amount of "starter" work on an OpenFlow 1.1
implementation, posted on ovs-dev here (search for "of1.1 draft"):
http://openvswitch.org/pipermail/dev/2011-December/thread.html
Some of this is already clean and high-quality enough to be reviewed
for inclusion in Open vSwitch. Other patches need some cleanup before
they are ready for final review.
What follows is some thoughts on how OF1.1 and OF1.2 support should
work. It is mainly meant as an introduction for anyone who is
thinking about contributing code. (Otherwise, you can stop reading
this long email.)
We do not want OF1.1 and OF1.2 support to be a build-time option. A
single build of Open vSwitch should be able to support OF1.0, OF1.1,
and OF1.2. Ideally, even at runtime it should be able to support all
protocol versions at the same time on different OpenFlow bridges (and
perhaps even on the same bridge).
At the same time, it would be a shame to litter the core of the OVS
code with lots of ugly code concerned with the details of various
OpenFlow protocol versions.
The primary approach to compatibility, then, should be one that
abstracts most of the details of the differences from the core code,
by adding a protocol layer that translates between OF1.0/1.1/1.2 and a
slightly higher-level abstract representation. The current OVS
codebase has a start at this approach as the many "struct ofputil_*"
structures in lib/ofp-util.h, although the existing translators and
representations only cover OF1.0. The patches that I have already
posted take a start at this approach, by abstracting OpenFlow 1.0
actions and some OpenFlow 1.0 and 1.1 messages into
protocol-independent data structures.
One consequence of this approach is that OVS will no longer be able to
use OpenFlow protocol definitions that closely resemble those in the
OpenFlow specification, because "openflow.h" in different versions of
the OpenFlow specification defines the same identifier with different
values. Instead, the patches introduce an "openflow-common.h" with
any definitions that are common to all the specifications and separate
"openflow-1.0.h", etc. headers that contain protocol-specific
definitions renamed so as not to conflict, e.g. "OFPAT10_ENQUEUE" and
"OFPAT11_ENQUEUE" for the OpenFlow 1.0 and 1.1 values for
OFPAT_ENQUEUE. Generally, in cases of conflict, the protocol layer
will define a more abstract "OFPUTIL_*" or "struct ofputil_*".
Here are some tentative approaches in a few tricky areas:
- Port numbering. OpenFlow 1.0 has 16-bit port numbers, OpenFlow
1.1/1.2 have 32-bit port numbers. Initially, anyway, OVS
support of OF1.1 will require all port numbers to fall into the
16-bit range (the reserved OFPP_* ports will need translation).
- Actions. OpenFlow 1.0 and 1.1 have very different ideas of
actions. It should be possible to reconcile them by
implementing OF1.1 actions as vendor extensions in OF1.0, and
vice versa.
The current list of items I see for OF1.1 support is the following.
It is based on reading OF1.1 a few months ago and is probably
incomplete:
- Minimal support:
- OF1.1 ofp_match decoding and encoding, which also requires:
* Implement arbitrary Ethernet source and destination address
masks.
* Implement arbitrary IPv6 source and destination address masks.
- OF1.1 actions:
* Decoding and encoding to the "ofpact" internal representation
introduced in my patch set.
* Add "ofpact" internal representations for actions not in
OF1.0.
* Implement actions not in OF1.0.
* Decoding and encoding of actions not in OF1.0 as OF1.0 vendor
extensions.
- Encoding and decoding other protocol messages to an abstract
form. Most of these should be straightforward, but there are
many of them.
- Add support for OF1.1 "metadata" field. Implementation should
be straightforward but there is some uncertainty about what
implementation is correct. OVS already has multiple 32-bit
"register" fields. Should the 64-bit "metadata" field be
separate or should it map to a pair of these? We've also
internally at Nicira talked about implementing 64-bit "wide
registers"; should metadata map to one of those?
- Implement "cookie_mask" in flow_mod messages.
- Make behavior of flow table misses configurable.
- Updates by flow_mod "MODIFY" is now much better specified.
Check that we implement the new behavior, fix it if not.
- Flow_mod "DELETE" now ignores buffer_id.
- OFPP_CONTROLLER must now be supported as in_port for packet_ins.
- Document how OVS does packet buffering.
- Full support:
- Implement groups. I haven't thought about how to do this.
- MPLS. This requires kernel work for reasonable performance.
- SCTP. This requires kernel work for reasonable performance.
- Match and set double-tagged VLANs (QinQ). This requires kernel
work for reasonable performance.
- VLANs tagged with 88a8 Ethertype. This requires kernel work for
reasonable performance.
- OF1.1 "set ECN" action. The OVS kernel module already supports
this.
- OF1.1 TTL actions. The OVS kernel module already supports
these.
How to contribute
-----------------
If you plan to contribute code for a feature, please let everyone know
on dev@openvswitch.org before you start work. This will help avoid
duplicating work.
Please think about the following:
- Testing. Please test your code (it's understandable, though, if
the code is not testable at the time it is added, because the
protocol implementation is incomplete).
- Unit tests. Please consider writing some.
- Coding style (see the CodingStyle file at the top of the source
tree).
- The patch submission guidelines (see SubmittingPatches). I
recommend using "git send-email", which automatically follows a
lot of those guidelines.
Thanks,
Ben.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
