testsuite.at: Workaround for carriage returns on windows.
[sliver-openvswitch.git] / FAQ
diff --git a/FAQ b/FAQ
index a08d65c..6b4be43 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -149,6 +149,7 @@ A: The following table lists the Linux kernel versions against which the
        1.11.x     2.6.18 to 3.8
        2.0.x      2.6.32 to 3.10
        2.1.x      2.6.32 to 3.11
+       2.2.x      2.6.32 to 3.13
 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
@@ -774,6 +775,13 @@ A: With the Linux kernel, the Open vSwitch implementation of QoS has
    tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or
    mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
 
+Q: Does Open vSwitch support OpenFlow meters?
+
+A: Since version 2.0, Open vSwitch has OpenFlow protocol support for
+   OpenFlow meters.  There is no implementation of meters in the Open
+   vSwitch software switch (neither the kernel-based nor userspace
+   switches).
+
 
 VLANs
 -----
@@ -1083,20 +1091,25 @@ Using OpenFlow (Manually or Via Controller)
 
 Q: What versions of OpenFlow does Open vSwitch support?
 
-A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
-   extensions that bring in many of the features from later versions
-   of OpenFlow).
+A: The following table lists the versions of OpenFlow supported by
+   each version of Open vSwitch:
 
-   Open vSwitch 1.10 and later have experimental support for OpenFlow
-   1.2 and 1.3.  On these versions of Open vSwitch, the following
-   command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0:
+       Open vSwitch      OF1.0  OF1.1  OF1.2  OF1.3  OF1.4
+       ===============   =====  =====  =====  =====  =====
+       1.9 and earlier    yes    ---    ---    ---    ---
+       1.10               yes    ---    [*]    [*]    ---
+       1.11               yes    ---    [*]    [*]    ---
+       2.0                yes    [*]    [*]    [*]    ---
+       2.1                yes    [*]    [*]    [*]    ---
+       2.2                yes    [*]    [*]    [*]    [%]
 
-       ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
+       [*] Supported, with one or more missing features.
+       [%] Support is unsafe: ovs-vswitchd will abort when certain
+           unimplemented features are tested.
 
-   Open vSwitch version 2.0 and later will have experimental support
-   for OpenFlow 1.1, 1.2, and 1.3.  On these versions of Open vSwitch,
-   the following command enables OpenFlow 1.0, 1.1, 1.2, and 1.3 on
-   bridge br0:
+   Because of missing features, OpenFlow 1.1, 1.2, and 1.3 must be
+   enabled manually.  The following command enables OpenFlow 1.0, 1.1,
+   1.2, and 1.3 on bridge br0:
 
        ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
 
@@ -1105,11 +1118,17 @@ A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
 
        ovs-ofctl -O OpenFlow13 dump-flows br0
 
-   Support for OpenFlow 1.1, 1.2, and 1.3 is still incomplete.  Work
-   to be done is tracked in OPENFLOW-1.1+ in the Open vSwitch sources
-   (also via http://openvswitch.org/development/openflow-1-x-plan/).
-   When support for a given OpenFlow version is solidly implemented,
-   Open vSwitch will enable that version by default.
+   OpenFlow 1.4 is a special case, because it is not implemented
+   safely: ovs-vswitchd will abort when certain unimplemented features
+   are tested.  Thus, for now it is suitable only for experimental
+   use.  ovs-vswitchd will only allow OpenFlow 1.4 to be enabled
+   (which must be done in the same way described above) when it is
+   invoked with a special --enable-of14 command line option.
+
+   OPENFLOW-1.1+ in the Open vSwitch source tree tracks support for
+   OpenFlow 1.1 and later features.  When support for a given OpenFlow
+   version is solidly implemented, Open vSwitch will enable that
+   version by default.
 
 Q: Does Open vSwitch support MPLS?
 
@@ -1403,9 +1422,9 @@ A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
    even be convenient, e.g. it is often the desired behavior in a flow
    that forwards a packet to several ports ("floods" the packet).
 
-   Sometimes one really needs to send a packet out its ingress port.
-   In this case, output to OFPP_IN_PORT, which in ovs-ofctl syntax is
-   expressed as just "in_port", e.g.:
+   Sometimes one really needs to send a packet out its ingress port
+   ("hairpin"). In this case, output to OFPP_IN_PORT, which in
+   ovs-ofctl syntax is expressed as just "in_port", e.g.:
 
        ovs-ofctl add-flow br0 in_port=2,actions=in_port
 
@@ -1475,6 +1494,23 @@ A: These flows drop the ARP packets that IP hosts use to establish IP
       priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
       priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
 
+
+Development
+-----------
+
+Q: How do I implement a new OpenFlow message?
+
+A: Add your new message to "enum ofpraw" and "enum ofptype" in
+   lib/ofp-msgs.h, following the existing pattern.  Then recompile and
+   fix all of the new warnings, implementing new functionality for the
+   new message as needed.  (If you configure with --enable-Werror, as
+   described in INSTALL, then it is impossible to miss any warnings.)
+
+   If you need to add an OpenFlow vendor extension message for a
+   vendor that doesn't yet have any extension messages, then you will
+   also need to edit build-aux/extract-ofp-msgs.
+
+
 Contact 
 -------