mcast-snooping: Add Multicast Listener Discovery support
[cascardo/ovs.git] / vswitchd / vswitch.xml
index e04aefc..b1d30f6 100644 (file)
       <column name="other_config" key="n-dpdk-rxqs"
               type='{"type": "integer", "minInteger": 1}'>
         <p>
-          Specifies the number of rx queues to be created for each dpdk
+          Specifies the maximum number of rx queues to be created for each dpdk
           interface.  If not specified or specified to 0, one rx queue will
           be created for each dpdk interface by default.
         </p>
 
     <group title="Multicast Snooping Configuration">
       Multicast snooping (RFC 4541) monitors the Internet Group Management
-      Protocol (IGMP) traffic between hosts and multicast routers.  The
-      switch uses what IGMP snooping learns to forward multicast traffic
-      only to interfaces that are connected to interested receivers.
-      Currently it supports IGMPv1 and IGMPv2 protocols.
+      Protocol (IGMP) and Multicast Listener Discovery traffic between hosts
+      and multicast routers.  The switch uses what IGMP and MLD snooping
+      learns to forward multicast traffic only to interfaces that are connected
+      to interested receivers.  Currently it supports IGMPv1, IGMPv2, IGMPv3,
+      MLDv1 and MLDv2 protocols.
 
       <column name="mcast_snooping_enable">
         Enable multicast snooping on the bridge. For now, the default
 
       <column name="other_config" key="forward-bpdu"
               type='{"type": "boolean"}'>
-        Option to allow forwarding of BPDU frames when NORMAL action is
-        invoked.  Frames with reserved Ethernet addresses (e.g. STP
-        BPDU) will be forwarded when this option is enabled and the
-        switch is not providing that functionality.  If STP is enabled
-        on the port, STP BPDUs will never be forwarded.  If the Open
-        vSwitch bridge is used to connect different Ethernet networks,
-        and if Open vSwitch node does not run STP, then this option
-        should be enabled.  Default is disabled, set to
-        <code>true</code> to enable.
-
-        The following destination MAC addresss will not be forwarded when this
-        option is enabled.
+
+       <p>
+          Controls forwarding of BPDUs and other network control frames when
+          NORMAL action is invoked.  When this option is <code>false</code> or
+          unset, frames with reserved Ethernet addresses (see table below) will
+          not be forwarded.  When this option is <code>true</code>, such frames
+          will not be treated specially.
+       </p>
+
+       <p>
+         The above general rule has the following exceptions:
+       </p>
+
+       <ul>
+         <li>
+           If STP is enabled on the bridge (see the <ref column="stp_enable"
+           table="Bridge"/> column in the <ref table="Bridge"/> table), the
+           bridge processes all received STP packets and never passes them to
+           OpenFlow or forwards them.  This is true even if STP is disabled on
+           an individual port.
+         </li>
+
+         <li>
+           If LLDP is enabled on an interface (see the <ref column="lldp"
+           table="Interface"/> column in the <ref table="Interface"/> table),
+           the interface processes received LLDP packets and never passes them
+           to OpenFlow or forwards them.
+         </li>
+       </ul>
+
+       <p>
+         Set this option to <code>true</code> if the Open vSwitch bridge
+         connects different Ethernet networks and is not configured to
+         participate in STP.
+       </p>
+
+        <p>
+         This option affects packets with the following destination MAC
+         addresses:
+       </p>
+
         <dl>
           <dt><code>01:80:c2:00:00:00</code></dt>
           <dd>IEEE 802.1D Spanning Tree Protocol (STP).</dd>
 
           <dt><code>geneve</code></dt>
           <dd>
-            An Ethernet over Geneve (<code>http://tools.ietf.org/html/draft-gross-geneve-00</code>)
+            An Ethernet over Geneve (<code>http://tools.ietf.org/html/draft-ietf-nvo3-geneve-00</code>)
             IPv4 tunnel.
 
-            Geneve supports options as a means to transport additional metadata,
-            however, currently only the 24-bit VNI is supported. This is planned
-            to be extended in the future.
+            A description of how to match and set Geneve options can be found
+            in the <code>ovs-ofctl</code> manual page.
           </dd>
 
           <dt><code>gre</code></dt>
             </p>
           </dd>
 
+          <dt><code>stt</code></dt>
+          <dd>
+             The Stateless TCP Tunnel (STT) is particularly useful when tunnel
+             endpoints are in end-systems, as it utilizes the capabilities of
+             standard network interface cards to improve performance.  STT utilizes
+             a TCP-like header inside the IP header. It is stateless, i.e., there is
+             no TCP connection state of any kind associated with the tunnel.  The
+             TCP-like header is used to leverage the capabilities of existing
+             network interface cards, but should not be interpreted as implying
+             any sort of connection state between endpoints.
+             Since the STT protocol does not engage in the usual TCP 3-way handshake,
+             so it will have difficulty traversing stateful firewalls.
+             The protocol is documented at
+             http://www.ietf.org/archive/id/draft-davie-stt-06.txt
+
+             All traffic uses a default destination port of 7471. STT is only
+             available in kernel datapath on kernel 3.5 or newer.
+          </dd>
+
           <dt><code>patch</code></dt>
           <dd>
             A pair of virtual devices that act as a patch cable.
         These options apply to interfaces with <ref column="type"/> of
         <code>geneve</code>, <code>gre</code>, <code>ipsec_gre</code>,
         <code>gre64</code>, <code>ipsec_gre64</code>, <code>vxlan</code>,
-        and <code>lisp</code>.
+        <code>lisp</code> and <code>stt</code>.
       </p>
 
       <p>
           </li>
           <li>
             A positive 24-bit (for Geneve, VXLAN, and LISP), 32-bit (for GRE)
-            or 64-bit (for GRE64) number.  The tunnel receives only packets
-            with the specified key.
+            or 64-bit (for GRE64 and STT) number.  The tunnel receives only
+            packets with the specified key.
           </li>
           <li>
             The word <code>flow</code>.  The tunnel accepts packets with any
           </li>
           <li>
             A positive 24-bit (for Geneve, VXLAN and LISP), 32-bit (for GRE) or
-            64-bit (for GRE64) number.  Packets sent through the tunnel will
-            have the specified key.
+            64-bit (for GRE64 and STT) number.  Packets sent through the tunnel
+            will have the specified key.
           </li>
           <li>
             The word <code>flow</code>.  Packets sent through the tunnel will
 
          </group>
 
-      <group title="Tunnel Options: gre and ipsec_gre only">
+      <group title="Tunnel Options: gre, ipsec_gre, geneve, and vxlan">
         <p>
-          Only <code>gre</code> and <code>ipsec_gre</code> interfaces support
-          these options.
+          <code>gre</code>, <code>ipsec_gre</code>, <code>geneve</code>, and
+          <code>vxlan</code> interfaces support these options.
         </p>
 
         <column name="options" key="csum" type='{"type": "boolean"}'>
           <p>
-            Optional.  Compute GRE checksums on outgoing packets.  Default is
-            disabled, set to <code>true</code> to enable.  Checksums present on
-            incoming packets will be validated regardless of this setting.
+            Optional.  Compute encapsulation header (either GRE or UDP) 
+            checksums on outgoing packets.  Default is disabled, set to
+            <code>true</code> to enable.  Checksums present on incoming
+            packets will be validated regardless of this setting.
          </p>
 
-         <p>
-           GRE checksums impose a significant performance penalty because they
-           cover the entire packet.  The encapsulated L3, L4, and L7 packet
-           contents typically have their own checksums, so this additional
-           checksum only adds value for the GRE and encapsulated L2 headers.
+          <p>
+            When using the upstream Linux kernel module, computation of
+            checksums for <code>geneve</code> and <code>vxlan</code> requires
+            Linux kernel version 4.0 or higher. <code>gre</code> supports
+            checksums for all versions of Open vSwitch that support GRE.
+            The out of tree kernel module distributed as part of OVS
+            can compute all tunnel checksums on any kernel version that it
+            is compatible with.
           </p>
 
           <p>