dpif-netdev: Properly track whether there is a vlan header.
[openvswitch] / vswitchd / vswitch.xml
index 6bcc0a2447a2adcc039d55d983de0792fc7bfdf2..465f27dd1b2a0df279f98a42f45298f687f82ad8 100644 (file)
              the same except one has an optional identifier and the other does
              not, the more specific one is matched first.  <code>in_key</code>
              is considered more specific than <code>local_ip</code> if a port
-             defines one and another port defines the other.  The arguments
-             are:
+             defines one and another port defines the other.  The following 
+             options may be specified in the <ref column="options"/> column:
             <dl>
               <dt><code>remote_ip</code></dt>
               <dd>Required.  The tunnel endpoint.</dd>
             </dl>
           </dd>
           <dt><code>patch</code></dt>
-          <dd>A pair of virtual devices that act as a patch cable.  A 
-            <code>peer</code> argument is required that indicates the name
-            of the other side of the patch.  Since a patch must work in
-            pairs, a second patch interface must be declared with the
-            <code>name</code> and <code>peer</code> arguments reversed.</dd>
+          <dd>
+            <p>
+              A pair of virtual devices that act as a patch cable.  The <ref
+              column="options"/> column must have the following key-value pair:
+            </p>
+            <dl>
+              <dt><code>peer</code></dt>
+              <dd>
+                The <ref column="name"/> of the <ref table="Interface"/> for
+                the other side of the patch.  The named <ref
+                table="Interface"/>'s own <code>peer</code> option must specify
+                this <ref table="Interface"/>'s name.  That is, the two patch
+                interfaces must have reversed <ref column="name"/> and
+                <code>peer</code> values.
+              </dd>
+            </dl>
+          </dd>
         </dl>
       </column>
 
   <table name="Controller" title="OpenFlow controller configuration.">
     <p>An OpenFlow controller.</p>
 
-    <p>Open vSwitch permits a bridge to have any number of OpenFlow
-       controllers.  When multiple controllers are configured, Open vSwitch
-       connects to all of them simultaneously.  OpenFlow 1.0 does not specify
-       how multiple controllers coordinate in interacting with a single switch,
-       so more than one controller should be specified only if the controllers
-       are themselves designed to coordinate with each other.</p>
+    <p>
+      Open vSwitch supports two kinds of OpenFlow controllers:
+    </p>
+    
+    <dl>
+      <dt>Primary controllers</dt>
+      <dd>
+        <p>
+          This is the kind of controller envisioned by the OpenFlow 1.0
+          specification.  Usually, a primary controller implements a network
+          policy by taking charge of the switch's flow table.
+        </p>
+
+        <p>
+          Open vSwitch initiates and maintains persistent connections to
+          primary controllers, retrying the connection each time it fails or
+          drops.  The <ref table="Bridge" column="fail_mode"/> column in the
+          <ref table="Bridge"/> table applies to primary controllers.
+        </p>
+
+        <p>
+          Open vSwitch permits a bridge to have any number of primary
+          controllers.  When multiple controllers are configured, Open
+          vSwitch connects to all of them simultaneously.  Because
+          OpenFlow 1.0 does not specify how multiple controllers
+          coordinate in interacting with a single switch, more than
+          one primary controller should be specified only if the
+          controllers are themselves designed to coordinate with each
+          other.  (The Nicira-defined <code>NXT_ROLE</code> OpenFlow
+          vendor extension may be useful for this.)
+        </p>
+      </dd>
+      <dt>Service controllers</dt>
+      <dd>
+        <p>
+          These kinds of OpenFlow controller connections are intended for
+          occasional support and maintenance use, e.g. with
+          <code>ovs-ofctl</code>.  Usually a service controller connects only
+          briefly to inspect or modify some of a switch's state.
+        </p>
+
+        <p>
+          Open vSwitch listens for incoming connections from service
+          controllers.  The service controllers initiate and, if necessary,
+          maintain the connections from their end.  The <ref table="Bridge"
+          column="fail_mode"/> column in the <ref table="Bridge"/> table does
+          not apply to service controllers.
+        </p>
+
+        <p>
+          Open vSwitch supports configuring any number of service controllers.
+        </p>
+      </dd>
+    </dl>
+
+    <p>
+      The <ref column="target"/> determines the type of controller.
+    </p>
 
     <group title="Core Features">
       <column name="target">
-        <p>Connection method for controller.
-          The following connection methods are currently
-          supported:</p>
+        <p>Connection method for controller.</p>
+        <p>
+          The following connection methods are currently supported for primary
+          controllers:
+        </p>
         <dl>
           <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
           <dd>
             <p>The specified SSL <var>port</var> (default: 6633) on the host at
-              the given <var>ip</var>, which must be expressed as an IP address
-              (not a DNS name).  The <ref table="Open_vSwitch" column="ssl"/>
-              column in the <ref table="Open_vSwitch"/> must point to a valid
-              SSL configuration when this form is used.</p>
+            the given <var>ip</var>, which must be expressed as an IP address
+            (not a DNS name).  The <ref table="Open_vSwitch" column="ssl"/>
+            column in the <ref table="Open_vSwitch"/> table must point to a
+            valid SSL configuration when this form is used.</p>
             <p>SSL support is an optional feature that is not always built as
               part of Open vSwitch.</p>
           </dd>
               used only for bootstrapping the OpenFlow PKI at initial switch
               setup; <code>ovs-vswitchd</code> does not use it at all.</p>
           </dd>
-          <dt><code>none</code></dt>
-          <dd>Disables the controller.</dd>
+        </dl>
+        <p>
+          The following connection methods are currently supported for service
+          controllers:
+        </p>
+        <dl>
+          <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
+          <dd>
+            <p>
+              Listens for SSL connections on the specified TCP <var>port</var>
+              (default: 6633).  If <var>ip</var>, which must be expressed as an
+              IP address (not a DNS name), is specified, then connections are
+              restricted to the specified local IP address.
+            </p>
+            <p>
+              The <ref table="Open_vSwitch" column="ssl"/> column in the <ref
+              table="Open_vSwitch"/> table must point to a valid SSL
+              configuration when this form is used.
+            </p>
+            <p>SSL support is an optional feature that is not always built as
+              part of Open vSwitch.</p>
+          </dd>
+          <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
+          <dd>
+            Listens for connections on the specified TCP <var>port</var>
+            (default: 6633).  If <var>ip</var>, which must be expressed as an
+            IP address (not a DNS name), is specified, then connections are
+            restricted to the specified local IP address.
+          </dd>
         </dl>
        <p>When multiple controllers are configured for a single bridge, the
          <ref column="target"/> values must be unique.  Duplicate