ovn-sb.xml

<?xml version="1.0" encoding="utf-8"?>
<database name="ovn-sb" title="OVN Southbound Database">
  <p>
    This database holds logical and physical configuration and state for the
    Open Virtual Network (OVN) system to support virtual network abstraction.
    For an introduction to OVN, please see <code>ovn-architecture</code>(7).
  </p>

  <p>
    The OVN Southbound database sits at the center of the OVN
    architecture.  It is the one component that speaks both southbound
    directly to all the hypervisors and gateways, via
    <code>ovn-controller</code>/<code>ovn-controller-vtep</code>, and
    northbound to the Cloud Management System, via <code>ovn-northd</code>:
  </p>

  <h2>Database Structure</h2>

  <p>
    The OVN Southbound database contains classes of data with
    different properties, as described in the sections below.
  </p>

  <h3>Physical network</h3>

  <p>
    Physical network tables contain information about the chassis nodes in the
    system.  This contains all the information necessary to wire the overlay,
    such as IP addresses, supported tunnel types, and security keys.
  </p>

  <p>
    The amount of physical network data is small (O(n) in the number of
    chassis) and it changes infrequently, so it can be replicated to every
    chassis.
  </p>

  <p>
    The <ref table="Chassis"/> and <ref table="Encap"/> tables are the physical
    network tables.
  </p>

  <h3>Logical Network</h3>

  <p>
    Logical network tables contain the topology of logical switches and
    routers, ACLs, firewall rules, and everything needed to describe how
    packets traverse a logical network, represented as logical datapath flows
    (see Logical Datapath Flows, below).
  </p>

  <p>
    Logical network data may be large (O(n) in the number of logical ports, ACL
    rules, etc.).  Thus, to improve scaling, each chassis should receive only
    data related to logical networks in which that chassis participates.
  </p>

  <p>
    The logical network data is ultimately controlled by the cloud management
    system (CMS) running northbound of OVN.  That CMS determines the entire OVN
    logical configuration and therefore the logical network data at any given
    time is a deterministic function of the CMS's configuration, although that
    happens indirectly via the <ref db="OVN_Northbound"/> database and
    <code>ovn-northd</code>.
  </p>

  <p>
    Logical network data is likely to change more quickly than physical network
    data.  This is especially true in a container environment where containers
    are created and destroyed (and therefore added to and deleted from logical
    switches) quickly.
  </p>

  <p>
    The <ref table="Logical_Flow"/>, <ref table="Multicast_Group"/>, <ref
    table="Address_Group"/>, <ref table="DHCP_Options"/>, <ref
    table="DHCPv6_Options"/>, and <ref table="DNS"/> tables contain logical
    network data.
  </p>

  <h3>Logical-physical bindings</h3>

  <p>
    These tables link logical and physical components.  They show the current
    placement of logical components (such as VMs and VIFs) onto chassis, and
    map logical entities to the values that represent them in tunnel
    encapsulations.
  </p>

  <p>
    These tables change frequently, at least every time a VM powers up or down
    or migrates, and especially quickly in a container environment.  The
    amount of data per VM (or VIF) is small.
  </p>

  <p>
    Each chassis is authoritative about the VMs and VIFs that it hosts at any
    given time and can efficiently flood that state to a central location, so
    the consistency needs are minimal.
  </p>

  <p>
    The <ref table="Port_Binding"/> and <ref table="Datapath_Binding"/> tables
    contain binding data.
  </p>

  <h3>MAC bindings</h3>

  <p>
    The <ref table="MAC_Binding"/> table tracks the bindings from IP addresses
    to Ethernet addresses that are dynamically discovered using ARP (for IPv4)
    and neighbor discovery (for IPv6).  Usually, IP-to-MAC bindings for virtual
    machines are statically populated into the <ref table="Port_Binding"/>
    table, so <ref table="MAC_Binding"/> is primarily used to discover bindings
    on physical networks.
  </p>

  <h2>Common Columns</h2>

  <p>
    Some tables contain a special column named <code>external_ids</code>.  This
    column has the same form and purpose each place that it appears, so we
    describe it here to save space later.
  </p>

  <dl>
    <dt><code>external_ids</code>: map of string-string pairs</dt>
    <dd>
      Key-value pairs for use by the software that manages the OVN Southbound
      database rather than by
      <code>ovn-controller</code>/<code>ovn-controller-vtep</code>.  In
      particular, <code>ovn-northd</code> can use key-value pairs in this
      column to relate entities in the southbound database to higher-level
      entities (such as entities in the OVN Northbound database).  Individual
      key-value pairs in this column may be documented in some cases to aid
      in understanding and troubleshooting, but the reader should not mistake
      such documentation as comprehensive.
    </dd>
  </dl>

  <table name="SB_Global" title="Southbound configuration">
    <p>
      Southbound configuration for an OVN system.  This table must have exactly
      one row.
    </p>

    <group title="Status">
      This column allow a client to track the overall configuration state of
      the system.

      <column name="nb_cfg">
        Sequence number for the configuration.  When a CMS or
        <code>ovn-nbctl</code> updates the northbound database, it increments
        the <code>nb_cfg</code> column in the <code>NB_Global</code> table in
        the northbound database.  In turn, when <code>ovn-northd</code> updates
        the southbound database to bring it up to date with these changes, it
        updates this column to the same value.
      </column>
    </group>

    <group title="Common Columns">
      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>

      <column name="options">
      </column>
    </group>

    <group title="Common options">
      <column name="options">
        This column provides general key/value settings. The supported
        options are described individually below.
      </column>

      <group title="Options for configuring BFD">
        <p>
          These options apply when <code>ovn-controller</code> configures
          BFD on tunnels interfaces.
        </p>

        <column name="options" key="bfd-min-rx">
          BFD option <code>min-rx</code> value to use when configuring BFD on
          tunnel interfaces.
        </column>

        <column name="options" key="bfd-decay-min-rx">
          BFD option <code>decay-min-rx</code> value to use when configuring
          BFD on tunnel interfaces.
        </column>

        <column name="options" key="bfd-min-tx">
          BFD option <code>min-tx</code> value to use when configuring BFD on
          tunnel interfaces.
        </column>

        <column name="options" key="bfd-mult">
          BFD option <code>mult</code> value to use when configuring BFD on
          tunnel interfaces.
        </column>

        <column name="options" key="debug_drop_domain_id">
          <p>
            If set to a 8-bit number and if
            <code>debug_drop_collector_set</code> is also configured,
            <code>ovn-controller</code> will add a <code>sample</code> action
            to every flow that does not come from a logical flow that contains
            a 'drop' action.
            The 8 most significant bits of the observation_domain_id field will
            be those specified in the
            <code> debug_drop_domain_id</code>.
            The 24 least significant bits of the observation_domain_id field
            will be zero.
          </p>
          <p>
            The observation_point_id will be set to the OpenFlow table number.
          </p>
        </column>

        <column name="options" key="debug_drop_collector_set">
          <p>
            If set to a 32-bit number <code>ovn-controller</code> will add a
            <code>sample</code> action to every flow that does not come from
            a logical flow that contains a 'drop' action.
            The sample action will have the specified collector_set_id.
            The value must match that of the local OVS configuration as
            described in <code>ovs-actions</code>(7).
          </p>
        </column>
      </group>

      <group title="Options for configuring Load Balancers">
        <p>
          These options apply when <code>ovn-controller</code> configures
          load balancer related flows.
        </p>

        <column name="options" key="lb_hairpin_use_ct_mark">
          By default this option is turned on (even if not present in the
          database) unless its value is explicitly set to <code>false</code>.

          This value is automatically set to <code>false</code> by
          <code>ovn-northd</code> when action <code>ct_lb_mark</code> cannot be
          used for new load balancer sessions and action <code>ct_lb</code>
          will be used instead.  <code>ovn-controller</code> then
          knows that it should check <code>ct_label.natted</code> to detect
          load balanced traffic.
        </column>
      </group>

      <group title="Options for configuring ovn-sbctl">
        <p>
          These options apply when <code>ovn-sbctl</code> connects to
          OVN Southbound database.
        </p>

        <column name="options" key="sbctl_probe_interval">
          <p>
            The inactivity probe interval of the connection to the OVN
            Southbound database from <code>ovn-sbctl</code> utility, in
            milliseconds.  If the value is zero, it disables the connection
            keepalive feature.
          </p>

          <p>
            If the value is nonzero, then it will be forced to a value of
            at least 1000 ms.
          </p>

          <p>
            If the value is less than zero, then the default inactivity probe
            interval for <code>ovn-sbctl</code> would be left intact (120000 ms).
          </p>
        </column>
      </group>
    </group>

    <group title="Connection Options">
      <column name="connections">
        Database clients to which the Open vSwitch database server should
        connect or on which it should listen, along with options for how these
        connections should be configured.  See the <ref table="Connection"/>
        table for more information.
      </column>
      <column name="ssl">
        Global SSL configuration.
      </column>
    </group>
    <group title="Security Configurations">
      <column name="ipsec">
        Tunnel encryption configuration. If this column is set to be true, all
        OVN tunnels will be encrypted with IPsec.
      </column>
    </group>
  </table>

  <table name="Chassis" title="Physical Network Hypervisor and Gateway Information">
    <p>
      Each row in this table represents a hypervisor or gateway (a chassis) in
      the physical network.  Each chassis, via
      <code>ovn-controller</code>/<code>ovn-controller-vtep</code>, adds
      and updates its own row, and keeps a copy of the remaining rows to
      determine how to reach other hypervisors.
    </p>

    <p>
      When a chassis shuts down gracefully, it should remove its own row.
      (This is not critical because resources hosted on the chassis are equally
      unreachable regardless of whether the row is present.)  If a chassis
      shuts down permanently without removing its row, some kind of manual or
      automatic cleanup is eventually needed; we can devise a process for that
      as necessary.
    </p>

    <column name="name">
      OVN does not prescribe a particular format for chassis names.
      ovn-controller populates this column using <ref key="system-id"
      table="Open_vSwitch" column="external_ids" db="Open_vSwitch"/>
      in the Open_vSwitch database's <ref table="Open_vSwitch"
      db="Open_vSwitch"/> table.  ovn-controller-vtep populates this
      column with <ref table="Physical_Switch" column="name"
      db="hardware_vtep"/> in the hardware_vtep database's
      <ref table="Physical_Switch" db="hardware_vtep"/> table.
    </column>

    <column name="hostname">
      The hostname of the chassis, if applicable.  ovn-controller will populate
      this column with the hostname of the host it is running on.
      ovn-controller-vtep will leave this column empty.
    </column>

    <column name="nb_cfg">
      Deprecated. This column is replaced by the <ref table="Chassis_Private"
      column="nb_cfg"/> column of the <ref table="Chassis_Private"/> table.
    </column>

    <column name="other_config" key="ovn-bridge-mappings">
      <code>ovn-controller</code> populates this key with the set of bridge
      mappings it has been configured to use.  Other applications should treat
      this key as read-only.  See <code>ovn-controller</code>(8) for more
      information.
    </column>

    <column name="other_config" key="datapath-type">
      <code>ovn-controller</code> populates this key with the datapath type
      configured in the <ref table="Bridge" column="datapath_type"/> column of
      the Open_vSwitch database's <ref table="Bridge" db="Open_vSwitch"/>
      table.  Other applications should treat this key as read-only. See
      <code>ovn-controller</code>(8) for more information.
    </column>

    <column name="other_config" key="iface-types">
      <code>ovn-controller</code> populates this key with the interface types
      configured in the <ref table="Open_vSwitch" column="iface_types"/> column
      of the Open_vSwitch database's <ref table="Open_vSwitch"
      db="Open_vSwitch"/> table.  Other applications should treat this key as
      read-only. See <code>ovn-controller</code>(8) for more information.
    </column>

    <column name="other_config" key="ovn-cms-options">
      <code>ovn-controller</code> populates this key with the set of options
      configured in the <ref table="Open_vSwitch"
      column="external_ids:ovn-cms-options"/> column of the Open_vSwitch
      database's <ref table="Open_vSwitch" db="Open_vSwitch"/> table.
      See <code>ovn-controller</code>(8) for more information.
    </column>

    <column name="other_config" key="is-interconn">
      <code>ovn-controller</code> populates this key with the setting
      configured in the <ref table="Open_vSwitch"
      column="external_ids:ovn-is-interconn"/> column of the Open_vSwitch
      database's <ref table="Open_vSwitch" db="Open_vSwitch"/> table.
      If set to true, the chassis is used as an interconnection gateway.
      See <code>ovn-controller</code>(8) for more information.
    </column>

    <column name="other_config" key="is-remote">
      <code>ovn-ic</code> set this key to true for remote interconnection
      gateway chassises learned from the interconnection southbound database.
      See <code>ovn-ic</code>(8) for more information.
    </column>

    <column name="transport_zones">
      <code>ovn-controller</code> populates this key with the transport
      zones configured in the <ref table="Open_vSwitch"
      column="external_ids:ovn-transport-zones"/> column of the Open_vSwitch
      database's <ref table="Open_vSwitch" db="Open_vSwitch"/> table.
      See <code>ovn-controller</code>(8) for more information.
    </column>

    <column name="other_config" key="ovn-chassis-mac-mappings">
      <code>ovn-controller</code> populates this key with the set of options
      configured in the <ref table="Open_vSwitch"
      column="external_ids:ovn-chassis-mac-mappings"/> column of the
      Open_vSwitch database's <ref table="Open_vSwitch" db="Open_vSwitch"/>
      table. See <code>ovn-controller</code>(8) for more information.
    </column>

    <column name="other_config" key="port-up-notif">
      <code>ovn-controller</code> populates this key with <code>true</code>
      when it supports <code>Port_Binding.up</code>.
    </column>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
    </group>

    <group title="Encapsulation Configuration">
      <p>
        OVN uses encapsulation to transmit logical dataplane packets
        between chassis.
      </p>

      <column name="encaps">
        Points to supported encapsulation configurations to transmit
        logical dataplane packets to this chassis.  Each entry is a <ref
        table="Encap"/> record that describes the configuration.
      </column>
    </group>

    <group title="Gateway Configuration">
      <p>
        A <dfn>gateway</dfn> is a chassis that forwards traffic between the
        OVN-managed part of a logical network and a physical VLAN, extending a
        tunnel-based logical network into a physical network.  Gateways are
        typically dedicated nodes that do not host VMs and will be controlled
        by <code>ovn-controller-vtep</code>.
      </p>

      <column name="vtep_logical_switches">
        Stores all VTEP logical switch names connected by this gateway
        chassis.  The <ref table="Port_Binding"/> table entry with
        <ref column="options" table="Port_Binding"/>:<code>vtep-physical-switch</code>
        equal <ref table="Chassis"/> <ref column="name" table="Chassis"/>, and
        <ref column="options" table="Port_Binding"/>:<code>vtep-logical-switch</code>
        value in <ref table="Chassis"/>
        <ref column="vtep_logical_switches" table="Chassis"/>, will be
        associated with this <ref table="Chassis"/>.
      </column>
    </group>
  </table>

  <table name="Chassis_Private" title="Chassis Private">
    <p>
      Each row in this table maintains per chassis private data that are
      accessed only by the owning chassis (write only) and ovn-northd, not by
      any other chassis.  These data are stored in this separate table instead
      of the <ref table="Chassis"/> table for performance considerations:
      the rows in this table can be conditionally monitored by chassises so
      that each chassis only get update notifications for its own row, to avoid
      unnecessary chassis private data update flooding in a large scale
      deployment.
    </p>

    <column name="name">
      The name of the chassis that owns these chassis-private data.
    </column>

    <column name="chassis">
      The reference to <ref table="Chassis"/> table for the chassis that owns
      these chassis-private data.
    </column>

    <column name="nb_cfg">
      Sequence number for the configuration.  When <code>ovn-controller</code>
      updates the configuration of a chassis from the contents of the
      southbound database, it copies <ref table="SB_Global" column="nb_cfg"/>
      from the <ref table="SB_Global"/> table into this column.
    </column>

    <column name="nb_cfg_timestamp">
      The timestamp when <code>ovn-controller</code> finishes processing the
      change corresponding to <ref column="nb_cfg"/>.
    </column>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
    </group>
  </table>

  <table name="Encap" title="Encapsulation Types">
    <p>
      The <ref column="encaps" table="Chassis"/> column in the <ref
      table="Chassis"/> table refers to rows in this table to identify
      how OVN may transmit logical dataplane packets to this chassis.
      Each chassis, via <code>ovn-controller</code>(8) or
      <code>ovn-controller-vtep</code>(8), adds and updates its own rows
      and keeps a copy of the remaining rows to determine how to reach
      other chassis.
    </p>

    <column name="type">
      The encapsulation to use to transmit packets to this chassis.
      Hypervisors and gateways must use one of: <code>geneve</code>,
      <code>vxlan</code>, or <code>stt</code>.
    </column>

    <column name="options">
      Options for configuring the encapsulation, which may be <ref column="type"/> specific.
    </column>

    <column name="options" key="csum" type='{"type": "boolean"}'>
      <p>
        <code>csum</code> indicates whether this chassis can transmit and
        receive packets that include checksums with reasonable performance.  It
        hints
        to senders transmitting data to this chassis that they should use
        checksums to protect OVN metadata. <code>ovn-controller</code>
        populates this key with the value defined in
        <ref table="Open_vSwitch" column="external_ids:ovn-encap-csum"/> column
        of the Open_vSwitch database's <ref table="Open_vSwitch"
        db="Open_vSwitch"/> table.  Other applications should treat this key as
        read-only. See <code>ovn-controller</code>(8) for more information.
      </p>

      <p>
        In terms of performance, checksumming actually significantly increases
        throughput in most common cases when running on Linux based hosts
        without NICs supporting encapsulation hardware offload (around 60% for
        bulk traffic). The reason is that generally all NICs are capable of
        offloading transmitted and received TCP/UDP checksums (viewed as
        ordinary data packets and not as tunnels). The benefit comes on the
        receive side where the validated outer checksum can be used to
        additionally validate an inner checksum (such as TCP), which in turn
        allows aggregation of packets to be more efficiently handled by the
        rest of the stack.
      </p>

      <p>
        Not all devices see such a benefit. The most notable exception is
        hardware VTEPs. These devices are designed to not buffer entire
        packets in their switching engines and are therefore unable to
        efficiently compute or validate full packet checksums. In addition
        certain versions of the Linux kernel are not able to fully take
        advantage of encapsulation NIC offloads in the presence of checksums.
        (This is actually a pretty narrow corner case though: earlier
        versions of Linux don't support encapsulation offloads at all and
        later versions support both offloads and checksums well.)
      </p>

      <p>
        <code>csum</code> defaults to <code>false</code> for hardware VTEPs and
        <code>true</code> for all other cases.
      </p>

      <p>
        This option applies to <code>geneve</code> and <code>vxlan</code>
        encapsulations.
      </p>
    </column>

    <column name="options" key="dst_port" type='{"type": "integer"}'>
      <p>
        If set, overrides the UDP (for <code>geneve</code> and
        <code>vxlan</code>) or TCP (for <code>stt</code>) destination port.
      </p>
    </column>

    <column name="ip">
      The IPv4 address of the encapsulation tunnel endpoint.
    </column>
    <column name="chassis_name">
      The name of the chassis that created this encap.
    </column>
  </table>

  <table name="Address_Set" title="Address Sets">
    <p>
      This table contains address sets synced from the <ref table="Address_Set"
      db="OVN_Northbound"/> table in the <ref db="OVN_Northbound"/> database
      and address sets generated from the <ref table="Port_Group"
      db="OVN_Northbound"/> table in the <ref db="OVN_Northbound"/> database.
    </p>

    <p>
      See the documentation for the <ref table="Address_Set"
      db="OVN_Northbound"/> table and <ref table="Port_Group"
      db="OVN_Northbound"/> table in the <ref db="OVN_Northbound"/>
      database for details.
    </p>

    <column name="name"/>
    <column name="addresses"/>
  </table>

  <table name="Port_Group" title="Port Groups">
    <p>
      This table contains names for the logical switch ports in the
      <ref db="OVN_Northbound"/> database that belongs to the same group
      that is defined in <ref table="Port_Group" db="OVN_Northbound"/>
      in the <ref db="OVN_Northbound"/> database.
    </p>

    <column name="name"/>
    <column name="ports"/>
  </table>

  <table name="Logical_Flow" title="Logical Network Flows">
    <p>
      Each row in this table represents one logical flow.
      <code>ovn-northd</code> populates this table with logical flows
      that implement the L2 and L3 topologies specified in the
      <ref db="OVN_Northbound"/> database.  Each hypervisor, via
      <code>ovn-controller</code>, translates the logical flows into
      OpenFlow flows specific to its hypervisor and installs them into
      Open vSwitch.
    </p>

    <p>
      Logical flows are expressed in an OVN-specific format, described here.  A
      logical datapath flow is much like an OpenFlow flow, except that the
      flows are written in terms of logical ports and logical datapaths instead
      of physical ports and physical datapaths.  Translation between logical
      and physical flows helps to ensure isolation between logical datapaths.
      (The logical flow abstraction also allows the OVN centralized
      components to do less work, since they do not have to separately
      compute and push out physical flows to each chassis.)
    </p>

    <p>
      The default action when no flow matches is to drop packets.
    </p>

    <p><em>Architectural Logical Life Cycle of a Packet</em></p>

    <p>
      This following description focuses on the life cycle of a packet through
      a logical datapath, ignoring physical details of the implementation.
      Please refer to <em>Architectural Physical Life Cycle of a Packet</em> in
      <code>ovn-architecture</code>(7) for the physical information.
    </p>

    <p>
      The description here is written as if OVN itself executes these steps,
      but in fact OVN (that is, <code>ovn-controller</code>) programs Open
      vSwitch, via OpenFlow and OVSDB, to execute them on its behalf.
    </p>

    <p>
      At a high level, OVN passes each packet through the logical datapath's
      logical ingress pipeline, which may output the packet to one or more
      logical port or logical multicast groups.  For each such logical output
      port, OVN passes the packet through the datapath's logical egress
      pipeline, which may either drop the packet or deliver it to the
      destination.  Between the two pipelines, outputs to logical multicast
      groups are expanded into logical ports, so that the egress pipeline only
      processes a single logical output port at a time.  Between the two
      pipelines is also where, when necessary, OVN encapsulates a packet in a
      tunnel (or tunnels) to transmit to remote hypervisors.
    </p>

    <p>
      In more detail, to start, OVN searches the <ref table="Logical_Flow"/>
      table for a row with correct <ref column="logical_datapath"/> or a
      <ref column="logical_dp_group"/>, a <ref column="pipeline"/> of
      <code>ingress</code>, a <ref column="table_id"/> of 0, and a <ref
      column="match"/> that is true for the packet.  If none is found, OVN
      drops the packet.  If OVN finds more than one, it chooses the match with
      the highest <ref column="priority"/>.  Then OVN executes
      each of the actions specified in the row's <ref table="actions"/> column,
      in the order specified.  Some actions, such as those to modify packet
      headers, require no further details.  The <code>next</code> and
      <code>output</code> actions are special.
    </p>

    <p>
      The <code>next</code> action causes the above process to be repeated
      recursively, except that OVN searches for <ref column="table_id"/> of 1
      instead of 0.  Similarly, any <code>next</code> action in a row found in
      that table would cause a further search for a <ref column="table_id"/> of
      2, and so on.  When recursive processing completes, flow control returns
      to the action following <code>next</code>.
    </p>

    <p>
      The <code>output</code> action also introduces recursion.  Its effect
      depends on the current value of the <code>outport</code> field.  Suppose
      <code>outport</code> designates a logical port.  First, OVN compares
      <code>inport</code> to <code>outport</code>; if they are equal, it treats
      the <code>output</code> as a no-op by default.  In the common
      case, where they are different, the packet enters the egress
      pipeline.  This transition to the egress pipeline discards
      register data, e.g. <code>reg0</code> ...  <code>reg9</code> and
      connection tracking state, to achieve uniform behavior regardless
      of whether the egress pipeline is on a different hypervisor
      (because registers aren't preserve across tunnel encapsulation).
    </p>

    <p>
      To execute the egress pipeline, OVN again searches the <ref
      table="Logical_Flow"/> table for a row with correct <ref
      column="logical_datapath"/> or a <ref column="logical_dp_group"/>,
      a <ref column="table_id"/> of 0, a <ref column="match"/> that is true for
      the packet, but now looking for a <ref column="pipeline"/> of
      <code>egress</code>.  If no matching row is found, the output becomes a
      no-op.  Otherwise, OVN executes the actions for the matching flow (which
      is chosen from multiple, if necessary, as already described).
    </p>

    <p>
      In the <code>egress</code> pipeline, the <code>next</code> action acts as
      already described, except that it, of course, searches for
      <code>egress</code> flows.  The <code>output</code> action, however, now
      directly outputs the packet to the output port (which is now fixed,
      because <code>outport</code> is read-only within the egress pipeline).
    </p>

    <p>
      The description earlier assumed that <code>outport</code> referred to a
      logical port.  If it instead designates a logical multicast group, then
      the description above still applies, with the addition of fan-out from
      the logical multicast group to each logical port in the group.  For each
      member of the group, OVN executes the logical pipeline as described, with
      the logical output port replaced by the group member.
    </p>

    <p><em>Pipeline Stages</em></p>

    <p>
      <code>ovn-northd</code> populates the <ref table="Logical_Flow"/> table
      with the logical flows described in detail in <code>ovn-northd</code>(8).
    </p>

    <column name="logical_datapath">
      The logical datapath to which the logical flow belongs.
    </column>

    <column name="logical_dp_group">
      The group of logical datapaths to which the logical flow belongs.  This
      means that the same logical flow belongs to all datapaths in a group.
    </column>

    <column name="pipeline">
      <p>
        The primary flows used for deciding on a packet's destination are the
        <code>ingress</code> flows.  The <code>egress</code> flows implement
        ACLs.  See <em>Logical Life Cycle of a Packet</em>, above, for details.
      </p>
    </column>

    <column name="table_id">
      The stage in the logical pipeline, analogous to an OpenFlow table number.
    </column>

    <column name="priority">
      The flow's priority.  Flows with numerically higher priority take
      precedence over those with lower.  If two logical datapath flows with the
      same priority both match, then the one actually applied to the packet is
      undefined.
    </column>

    <column name="match">
      <p>
        A matching expression.  OVN provides a superset of OpenFlow matching
        capabilities, using a syntax similar to Boolean expressions in a
        programming language.
      </p>

      <p>
        The most important components of match expression are
        <dfn>comparisons</dfn> between <dfn>symbols</dfn> and
        <dfn>constants</dfn>, e.g. <code>ip4.dst == 192.168.0.1</code>,
        <code>ip.proto == 6</code>, <code>arp.op == 1</code>, <code>eth.type ==
        0x800</code>.  The logical AND operator <code>&amp;&amp;</code> and
        logical OR operator <code>||</code> can combine comparisons into a
        larger expression.
      </p>

      <p>
        Matching expressions also support parentheses for grouping, the logical
        NOT prefix operator <code>!</code>, and literals <code>0</code> and
        <code>1</code> to express ``false'' or ``true,'' respectively.  The
        latter is useful by itself as a catch-all expression that matches every
        packet.
      </p>

      <p>
        Match expressions also support a kind of function syntax.  The
        following functions are supported:
      </p>

      <dl>
        <dt><code>is_chassis_resident(<var>lport</var>)</code></dt>
        <dd>
          Evaluates to true on a chassis on which logical port <var>lport</var>
          (a quoted string) resides, and to false elsewhere.  This function was
          introduced in OVN 2.7.
        </dd>
      </dl>

      <p><em>Symbols</em></p>

      <p>
        <em>Type</em>.  Symbols have <dfn>integer</dfn> or <dfn>string</dfn>
        type.  Integer symbols have a <dfn>width</dfn> in bits.
      </p>

      <p>
        <em>Kinds</em>.  There are three kinds of symbols:
      </p>

      <ul>
        <li>
          <p>
            <dfn>Fields</dfn>.  A field symbol represents a packet header or
            metadata field.  For example, a field
            named <code>vlan.tci</code> might represent the VLAN TCI field in a
            packet.
          </p>

          <p>
            A field symbol can have integer or string type.  Integer fields can
            be nominal or ordinal (see <em>Level of Measurement</em>,
            below).
          </p>
        </li>

        <li>
          <p>
            <dfn>Subfields</dfn>.  A subfield represents a subset of bits from
            a larger field.  For example, a field <code>vlan.vid</code> might
            be defined as an alias for <code>vlan.tci[0..11]</code>.  Subfields
            are provided for syntactic convenience, because it is always
            possible to instead refer to a subset of bits from a field
            directly.
          </p>

          <p>
            Only ordinal fields (see <em>Level of Measurement</em>,
            below) may have subfields.  Subfields are always ordinal.
          </p>
        </li>

        <li>
          <p>
            <dfn>Predicates</dfn>.  A predicate is shorthand for a Boolean
            expression.  Predicates may be used much like 1-bit fields.  For
            example, <code>ip4</code> might expand to <code>eth.type ==
            0x800</code>.  Predicates are provided for syntactic convenience,
            because it is always possible to instead specify the underlying
            expression directly.
          </p>

          <p>
            A predicate whose expansion refers to any nominal field or
            predicate (see <em>Level of Measurement</em>, below) is nominal;
            other predicates have Boolean level of measurement.
          </p>
        </li>
      </ul>

      <p>
        <em>Level of Measurement</em>.  See
        http://en.wikipedia.org/wiki/Level_of_measurement for the statistical
        concept on which this classification is based.  There are three
        levels:
      </p>

      <ul>
        <li>
          <p>
            <dfn>Ordinal</dfn>.  In statistics, ordinal values can be ordered
            on a scale.  OVN considers a field (or subfield) to be ordinal if
            its bits can be examined individually.  This is true for the
            OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable.''
          </p>

          <p>
            Any use of a ordinal field may specify a single bit or a range of
            bits, e.g. <code>vlan.tci[13..15]</code> refers to the PCP field
            within the VLAN TCI, and <code>eth.dst[40]</code> refers to the
            multicast bit in the Ethernet destination address.
          </p>

          <p>
            OVN supports all the usual arithmetic relations (<code>==</code>,
            <code>!=</code>, <code>&lt;</code>, <code>&lt;=</code>,
            <code>&gt;</code>, and <code>&gt;=</code>) on ordinal fields and
            their subfields, because OVN can implement these in OpenFlow and
            Open vSwitch as collections of bitwise tests.
          </p>
        </li>

        <li>
          <p>
            <dfn>Nominal</dfn>.  In statistics, nominal values cannot be
            usefully compared except for equality.  This is true of OpenFlow
            port numbers, Ethernet types, and IP protocols are examples: all of
            these are just identifiers assigned arbitrarily with no deeper
            meaning.  In OpenFlow and Open vSwitch, bits in these fields
            generally aren't individually addressable.
          </p>

          <p>
            OVN only supports arithmetic tests for equality on nominal fields,
            because OpenFlow and Open vSwitch provide no way for a flow to
            efficiently implement other comparisons on them.  (A test for
            inequality can be sort of built out of two flows with different
            priorities, but OVN matching expressions always generate flows with
            a single priority.)
          </p>

          <p>
            String fields are always nominal.
          </p>
        </li>

        <li>
          <p>
            <dfn>Boolean</dfn>.  A nominal field that has only two values, 0
            and 1, is somewhat exceptional, since it is easy to support both
            equality and inequality tests on such a field: either one can be
            implemented as a test for 0 or 1.
          </p>

          <p>
            Only predicates (see above) have a Boolean level of measurement.
          </p>

          <p>
            This isn't a standard level of measurement.
          </p>
        </li>
      </ul>

      <p>
        <em>Prerequisites</em>.  Any symbol can have prerequisites, which are
        additional condition implied by the use of the symbol.  For example,
        For example, <code>icmp4.type</code> symbol might have prerequisite
        <code>icmp4</code>, which would cause an expression <code>icmp4.type ==
        0</code> to be interpreted as <code>icmp4.type == 0 &amp;&amp;
        icmp4</code>, which would in turn expand to <code>icmp4.type == 0
        &amp;&amp; eth.type == 0x800 &amp;&amp; ip4.proto == 1</code> (assuming
        <code>icmp4</code> is a predicate defined as suggested under
        <em>Types</em> above).
      </p>

      <p><em>Relational operators</em></p>

      <p>
        All of the standard relational operators <code>==</code>,
        <code>!=</code>, <code>&lt;</code>, <code>&lt;=</code>,
        <code>&gt;</code>, and <code>&gt;=</code> are supported.  Nominal
        fields support only <code>==</code> and <code>!=</code>, and only in a
        positive sense when outer <code>!</code> are taken into account,
        e.g. given string field <code>inport</code>, <code>inport ==
        "eth0"</code> and <code>!(inport != "eth0")</code> are acceptable, but
        not <code>inport != "eth0"</code>.
      </p>

      <p>
        The implementation of <code>==</code> (or <code>!=</code> when it is
        negated), is more efficient than that of the other relational
        operators.
      </p>

      <p><em>Constants</em></p>

      <p>
        Integer constants may be expressed in decimal, hexadecimal prefixed by
        <code>0x</code>, or as dotted-quad IPv4 addresses, IPv6 addresses in
        their standard forms, or Ethernet addresses as colon-separated hex
        digits.  A constant in any of these forms may be followed by a slash
        and a second constant (the mask) in the same form, to form a masked
        constant.  IPv4 and IPv6 masks may be given as integers, to express
        CIDR prefixes.
      </p>

      <p>
        String constants have the same syntax as quoted strings in JSON (thus,
        they are Unicode strings).
      </p>

      <p>
        Some operators support sets of constants written inside curly braces
        <code>{</code> ... <code>}</code>.  Commas between elements of a set,
        and after the last elements, are optional.  With <code>==</code>,
        ``<code><var>field</var> == { <var>constant1</var>,
        <var>constant2</var>,</code> ... <code>}</code>'' is syntactic sugar
        for ``<code><var>field</var> == <var>constant1</var> ||
        <var>field</var> == <var>constant2</var> || </code>...<code></code>.
        Similarly, ``<code><var>field</var> != { <var>constant1</var>,
        <var>constant2</var>, </code>...<code> }</code>'' is equivalent to
        ``<code><var>field</var> != <var>constant1</var> &amp;&amp;
        <var>field</var> != <var>constant2</var> &amp;&amp;
        </code>...<code></code>''.
      </p>

      <p>
        You may refer to a set of IPv4, IPv6, or MAC addresses stored in the
        <ref table="Address_Set"/> table by its <ref column="name"
        table="Address_Set"/>.  An <ref table="Address_Set"/> with a name
        of <code>set1</code> can be referred to as
        <code>$set1</code>.
      </p>

      <p>
        You may refer to a group of logical switch ports stored in the
        <ref table="Port_Group"/> table by its <ref column="name"
        table="Port_Group"/>.  An <ref table="Port_Group"/> with a name
        of <code>port_group1</code> can be referred to as
        <code>@port_group1</code>.
      </p>

      <p>
        Additionally, you may refer to the set of addresses belonging to a
        group of logical switch ports stored in the <ref table="Port_Group"/>
        table by its <ref column="name" table="Port_Group"/> followed by
        a suffix '_ip4'/'_ip6'.  The IPv4 address set of a
        <ref table="Port_Group"/> with a name of <code>port_group1</code>
        can be referred to as <code>$port_group1_ip4</code>, and the IPv6
        address set of the same <ref table="Port_Group"/> can be referred to
        as <code>$port_group1_ip6</code>
      </p>

      <p><em>Miscellaneous</em></p>

      <p>
        Comparisons may name the symbol or the constant first,
        e.g. <code>tcp.src == 80</code> and <code>80 == tcp.src</code> are both
        acceptable.
      </p>

      <p>
        Tests for a range may be expressed using a syntax like <code>1024 &lt;=
        tcp.src &lt;= 49151</code>, which is equivalent to <code>1024 &lt;=
        tcp.src &amp;&amp; tcp.src &lt;= 49151</code>.
      </p>

      <p>
        For a one-bit field or predicate, a mention of its name is equivalent
        to <code><var>symobl</var> == 1</code>, e.g. <code>vlan.present</code>
        is equivalent to <code>vlan.present == 1</code>.  The same is true for
        one-bit subfields, e.g. <code>vlan.tci[12]</code>.  There is no
        technical limitation to implementing the same for ordinal fields of all
        widths, but the implementation is expensive enough that the syntax
        parser requires writing an explicit comparison against zero to make
        mistakes less likely, e.g. in <code>tcp.src != 0</code> the comparison
        against 0 is required.
      </p>

      <p>
        <em>Operator precedence</em> is as shown below, from highest to lowest.
        There are two exceptions where parentheses are required even though the
        table would suggest that they are not: <code>&amp;&amp;</code> and
        <code>||</code> require parentheses when used together, and
        <code>!</code> requires parentheses when applied to a relational
        expression.  Thus, in <code>(eth.type == 0x800 || eth.type == 0x86dd)
        &amp;&amp; ip.proto == 6</code> or <code>!(arp.op == 1)</code>, the
        parentheses are mandatory.
      </p>

      <ul>
        <li><code>()</code></li>
        <li><code>==   !=   &lt;   &lt;=   &gt;   &gt;=</code></li>
        <li><code>!</code></li>
        <li><code>&amp;&amp;   ||</code></li>
      </ul>

      <p>
        <em>Comments</em> may be introduced by <code>//</code>, which extends
        to the next new-line.  Comments within a line may be bracketed by
        <code>/*</code> and <code>*/</code>.  Multiline comments are not
        supported.
      </p>

      <p><em>Symbols</em></p>

      <p>
        Most of the symbols below have integer type.  Only <code>inport</code>
        and <code>outport</code> have string type.  <code>inport</code> names a
        logical port.  Thus, its value is a <ref column="logical_port"/> name
        from the <ref table="Port_Binding"/> table.  <code>outport</code> may
        name a logical port, as <code>inport</code>, or a logical multicast
        group defined in the <ref table="Multicast_Group"/> table.  For both
        symbols, only names within the flow's logical datapath may be used.
      </p>

      <p>
        The <code>reg</code><var>X</var> symbols are 32-bit integers.
        The <code>xxreg</code><var>X</var> symbols are 128-bit integers,
        which overlay four of the 32-bit registers: <code>xxreg0</code>
        overlays <code>reg0</code> through <code>reg3</code>, with
        <code>reg0</code> supplying the most-significant bits of
        <code>xxreg0</code> and <code>reg3</code> the least-significant.
        <code>xxreg1</code> similarly overlays <code>reg4</code> through
        <code>reg7</code>.
      </p>

      <ul>
        <li><code>reg0</code>...<code>reg9</code></li>
        <li><code>xxreg0</code> <code>xxreg1</code></li>
        <li><code>inport</code> <code>outport</code></li>
        <li><code>flags.loopback</code></li>
        <li><code>pkt.mark</code></li>
        <li><code>eth.src</code> <code>eth.dst</code> <code>eth.type</code></li>
        <li><code>vlan.tci</code> <code>vlan.vid</code> <code>vlan.pcp</code> <code>vlan.present</code></li>
        <li><code>ip.proto</code> <code>ip.dscp</code> <code>ip.ecn</code> <code>ip.ttl</code> <code>ip.frag</code></li>
        <li><code>ip4.src</code> <code>ip4.dst</code></li>
        <li><code>ip6.src</code> <code>ip6.dst</code> <code>ip6.label</code></li>
        <li><code>arp.op</code> <code>arp.spa</code> <code>arp.tpa</code> <code>arp.sha</code> <code>arp.tha</code></li>
        <li><code>rarp.op</code> <code>rarp.spa</code> <code>rarp.tpa</code> <code>rarp.sha</code> <code>rarp.tha</code></li>
        <li><code>tcp.src</code> <code>tcp.dst</code> <code>tcp.flags</code></li>
        <li><code>udp.src</code> <code>udp.dst</code></li>
        <li><code>sctp.src</code> <code>sctp.dst</code></li>
        <li><code>icmp4.type</code> <code>icmp4.code</code></li>
        <li><code>icmp6.type</code> <code>icmp6.code</code></li>
        <li><code>nd.target</code> <code>nd.sll</code> <code>nd.tll</code></li>
        <li><code>ct_mark</code> <code>ct_label</code></li>
        <li>
          <p>
            <code>ct_state</code>, which has several Boolean subfields.  The
            <code>ct_next</code> action initializes the following subfields:
          </p>
          <ul>
            <li>
              <code>ct.trk</code>: Always set to true by <code>ct_next</code>
              to indicate that connection tracking has taken place.  All other
              <code>ct</code> subfields have <code>ct.trk</code> as a
              prerequisite.
            </li>
            <li><code>ct.new</code>: True for a new flow</li>
            <li><code>ct.est</code>: True for an established flow</li>
            <li><code>ct.rel</code>: True for a related flow</li>
            <li><code>ct.rpl</code>: True for a reply flow</li>
            <li><code>ct.inv</code>: True for a connection entry in a bad state</li>
          </ul>
          <p>
            The <code>ct_dnat</code>, <code>ct_snat</code>, and
            <code>ct_lb</code> actions initialize the following subfields:
          </p>
          <ul>
            <li>
              <code>ct.dnat</code>: True for a packet whose destination IP
              address has been changed.
            </li>
            <li>
              <code>ct.snat</code>: True for a packet whose source IP
              address has been changed.
            </li>
          </ul>
        </li>
      </ul>

      <p>
        The following predicates are supported:
      </p>

      <ul>
        <li><code>eth.bcast</code> expands to <code>eth.dst == ff:ff:ff:ff:ff:ff</code></li>
        <li><code>eth.mcast</code> expands to <code>eth.dst[40]</code></li>
        <li><code>vlan.present</code> expands to <code>vlan.tci[12]</code></li>
        <li><code>ip4</code> expands to <code>eth.type == 0x800</code></li>
        <li><code>ip4.src_mcast</code> expands to
        <code>ip4.src[28..31] == 0xe</code></li>
        <li><code>ip4.mcast</code> expands to <code>ip4.dst[28..31] == 0xe</code></li>
        <li><code>ip6</code> expands to <code>eth.type == 0x86dd</code></li>
        <li><code>ip</code> expands to <code>ip4 || ip6</code></li>
        <li><code>icmp4</code> expands to <code>ip4 &amp;&amp; ip.proto == 1</code></li>
        <li><code>icmp6</code> expands to <code>ip6 &amp;&amp; ip.proto == 58</code></li>
        <li><code>icmp</code> expands to <code>icmp4 || icmp6</code></li>
        <li><code>ip.is_frag</code> expands to <code>ip.frag[0]</code></li>
        <li><code>ip.later_frag</code> expands to <code>ip.frag[1]</code></li>
        <li><code>ip.first_frag</code> expands to <code>ip.is_frag &amp;&amp; !ip.later_frag</code></li>
        <li><code>arp</code> expands to <code>eth.type == 0x806</code></li>
        <li><code>rarp</code> expands to <code>eth.type == 0x8035</code></li>
        <li><code>nd</code> expands to <code>icmp6.type == {135, 136} &amp;&amp; icmp6.code == 0 &amp;&amp; ip.ttl == 255</code></li>
        <li><code>nd_ns</code> expands to <code>icmp6.type == 135 &amp;&amp; icmp6.code == 0 &amp;&amp; ip.ttl == 255</code></li>
        <li><code>nd_na</code> expands to <code>icmp6.type == 136 &amp;&amp; icmp6.code == 0 &amp;&amp; ip.ttl == 255</code></li>
        <li><code>nd_rs</code> expands to <code>icmp6.type == 133 &amp;&amp;
        icmp6.code == 0 &amp;&amp; ip.ttl == 255</code></li>
        <li><code>nd_ra</code> expands to <code>icmp6.type == 134 &amp;&amp;
        icmp6.code == 0 &amp;&amp; ip.ttl == 255</code></li>
        <li><code>tcp</code> expands to <code>ip.proto == 6</code></li>
        <li><code>udp</code> expands to <code>ip.proto == 17</code></li>
        <li><code>sctp</code> expands to <code>ip.proto == 132</code></li>
      </ul>
    </column>

    <column name="actions">
      <p>
        Logical datapath actions, to be executed when the logical flow
        represented by this row is the highest-priority match.
      </p>

      <p>
        Actions share lexical syntax with the <ref column="match"/> column.  An
        empty set of actions (or one that contains just white space or
        comments), or a set of actions that consists of just
        <code>drop;</code>, causes the matched packets to be dropped.
        Otherwise, the column should contain a sequence of actions, each
        terminated by a semicolon.
      </p>

      <p>
        The following actions are defined:
      </p>

      <dl>
        <dt><code>output;</code></dt>
        <dd>
          <p>
            In the ingress pipeline, this action executes the
            <code>egress</code> pipeline as a subroutine.  If
            <code>outport</code> names a logical port, the egress pipeline
            executes once; if it is a multicast group, the egress pipeline runs
            once for each logical port in the group.
          </p>

          <p>
            In the egress pipeline, this action performs the actual
            output to the <code>outport</code> logical port.  (In the egress
            pipeline, <code>outport</code> never names a multicast group.)
          </p>

          <p>
            By default, output to the input port is implicitly dropped,
            that is, <code>output</code> becomes a no-op if
            <code>outport</code> == <code>inport</code>.  Occasionally
            it may be useful to override this behavior, e.g. to send an
            ARP reply to an ARP request; to do so, use
            <code>flags.loopback = 1</code> to allow the packet to
            "hair-pin" back to the input port.
          </p>
        </dd>

        <dt><code>next;</code></dt>
        <dt><code>next(<var>table</var>);</code></dt>
        <dt><code>next(pipeline=<var>pipeline</var>, table=<var>table</var>);</code></dt>
        <dd>
          Executes the given logical datapath <var>table</var> in
          <var>pipeline</var> as a subroutine.  The default <var>table</var> is
          just after the current one.  If <var>pipeline</var> is specified, it
          may be <code>ingress</code> or <code>egress</code>; the default
          <var>pipeline</var> is the one currently executing. Actions in the
          both ingress and egress pipeline can use <code>next</code> to jump
          across the other pipeline.  Actions in the ingress pipeline should
          use <code>next</code> to jump into the specific table of egress
          pipeline only if it is certain that the packets are local and not
          tunnelled and wants to skip certain stages in the packet processing.
        </dd>

        <dt><code><var>field</var> = <var>constant</var>;</code></dt>
        <dd>
          <p>
            Sets data or metadata field <var>field</var> to constant value
            <var>constant</var>, e.g. <code>outport = "vif0";</code> to set the
            logical output port.  To set only a subset of bits in a field,
            specify a subfield for <var>field</var> or a masked
            <var>constant</var>, e.g. one may use <code>vlan.pcp[2] = 1;</code>
            or <code>vlan.pcp = 4/4;</code> to set the most significant bit of
            the VLAN PCP.
          </p>

          <p>
            Assigning to a field with prerequisites implicitly adds those
            prerequisites to <ref column="match"/>; thus, for example, a flow
            that sets <code>tcp.dst</code> applies only to TCP flows,
            regardless of whether its <ref column="match"/> mentions any TCP
            field.
          </p>

          <p>
            Not all fields are modifiable (e.g. <code>eth.type</code> and
            <code>ip.proto</code> are read-only), and not all modifiable fields
            may be partially modified (e.g. <code>ip.ttl</code> must assigned
            as a whole).  The <code>outport</code> field is modifiable in the
            <code>ingress</code> pipeline but not in the <code>egress</code>
            pipeline.
          </p>
        </dd>

        <dt><code><var>ovn_field</var> = <var>constant</var>;</code></dt>
        <dd>
          <p>
            Sets OVN field <var>ovn_field</var> to constant value
            <var>constant</var>.
          </p>

          <p>
            <code>OVN</code> supports setting the values of certain fields
            which are not yet supported in OpenFlow to set or modify them.
          </p>

          <p>
            Below are the supported <code>OVN fields</code>:
          </p>

          <ul>
            <li>
              <code>icmp4.frag_mtu</code>
              <code>icmp6.frag_mtu</code>
              <p>
                This field sets the low-order 16 bits of the ICMP{4,6} header
                field that is labelled "unused" in the ICMP specification as
                defined in the RFC 1191 with the value specified in
                <var>constant</var>.
              </p>

              <p>
                Eg. icmp4.frag_mtu = 1500;
              </p>
            </li>
          </ul>
        </dd>

        <dt><code><var>field1</var> = <var>field2</var>;</code></dt>
        <dd>
          <p>
            Sets data or metadata field <var>field1</var> to the value of data
            or metadata field <var>field2</var>, e.g. <code>reg0 =
            ip4.src;</code> copies <code>ip4.src</code> into <code>reg0</code>.
            To modify only a subset of a field's bits, specify a subfield for
            <var>field1</var> or <var>field2</var> or both, e.g. <code>vlan.pcp
            = reg0[0..2];</code> copies the least-significant bits of
            <code>reg0</code> into the VLAN PCP.
          </p>

          <p>
            <var>field1</var> and <var>field2</var> must be the same type,
            either both string or both integer fields.  If they are both
            integer fields, they must have the same width.
          </p>

          <p>
            If <var>field1</var> or <var>field2</var> has prerequisites, they
            are added implicitly to <ref column="match"/>.  It is possible to
            write an assignment with contradictory prerequisites, such as
            <code>ip4.src = ip6.src[0..31];</code>, but the contradiction means
            that a logical flow with such an assignment will never be matched.
          </p>
        </dd>

        <dt><code><var>field1</var> &lt;-&gt; <var>field2</var>;</code></dt>
        <dd>
          <p>
            Similar to <code><var>field1</var> = <var>field2</var>;</code>
            except that the two values are exchanged instead of copied.  Both
            <var>field1</var> and <var>field2</var> must modifiable.
          </p>
        </dd>

        <dt><code>push(<var>field</var>);</code></dt>
        <dd>
          <p>
            Push the value of <var>field</var> to the stack top.
          </p>
        </dd>

        <dt><code>pop(<var>field</var>);</code></dt>
        <dd>
          <p>
            Pop the stack top and store the value to <var>field</var>,
            which must be modifiable.
          </p>
        </dd>

        <dt><code>ip.ttl--;</code></dt>
        <dd>
          <p>
            Decrements the IPv4 or IPv6 TTL.  If this would make the TTL zero
            or negative, then processing of the packet halts; no further
            actions are processed.  (To properly handle such cases, a
            higher-priority flow should match on
            <code>ip.ttl == {0, 1};</code>.)
          </p>

          <p><b>Prerequisite:</b> <code>ip</code></p>
        </dd>

        <dt><code>ct_next;</code></dt>
        <dd>
          <p>
            Apply connection tracking to the flow, initializing
            <code>ct_state</code> for matching in later tables.
            Automatically moves on to the next table, as if followed by
            <code>next</code>.
          </p>

          <p>
            As a side effect, IP fragments will be reassembled for matching.
            If a fragmented packet is output, then it will be sent with any
            overlapping fragments squashed.  The connection tracking state is
            scoped by the logical port when the action is used in a flow for
            a logical switch, so overlapping addresses may be used.  To allow
            traffic related to the matched flow, execute <code>ct_commit
            </code>.  Connection tracking state is scoped by the logical
            topology when the action is used in a flow for a router.
          </p>

          <p>
            It is possible to have actions follow <code>ct_next</code>,
            but they will not have access to any of its side-effects and
            is not generally useful.
          </p>
        </dd>

        <dt><code>ct_commit { };</code></dt>
        <dt><code>ct_commit { ct_mark=<var>value[/mask]</var>; };</code></dt>
        <dt><code>ct_commit { ct_label=<var>value[/mask]</var>; };</code></dt>
        <dt><code>ct_commit { ct_mark=<var>value[/mask]</var>; ct_label=<var>value[/mask]</var>; };</code></dt>
        <dd>
          <p>
            Commit the flow to the connection tracking entry associated with it
            by a previous call to <code>ct_next</code>.  When
            <code>ct_mark=<var>value[/mask]</var></code> and/or
            <code>ct_label=<var>value[/mask]</var></code> are supplied,
            <code>ct_mark</code> and/or <code>ct_label</code> will be set to the
            values indicated by <var>value[/mask]</var> on the connection
            tracking entry. <code>ct_mark</code> is a 32-bit field.
            <code>ct_label</code> is a 128-bit field. The <var>value[/mask]</var>
            should be specified in hex string if more than 64bits are to be used.
            Registers and other named fields can be used for <var>value</var>.
            <code>ct_mark</code> and <code>ct_label</code> may be sub-addressed
            in order to have specific bits set.
          </p>

          <p>
            Note that if you want processing to continue in the next table,
            you must execute the <code>next</code> action after
            <code>ct_commit</code>.  You may also leave out <code>next</code>
            which will commit connection tracking state, and then drop the
            packet.  This could be useful for setting <code>ct_mark</code>
            on a connection tracking entry before dropping a packet,
            for example.
          </p>
        </dd>

        <dt><code>ct_dnat;</code></dt>
        <dt><code>ct_dnat(<var>IP</var>);</code></dt>
        <dd>
          <p>
            <code>ct_dnat</code> sends the packet through the DNAT zone in
            connection tracking table to unDNAT any packet that was DNATed in
            the opposite direction.  The packet is then automatically sent to
            to the next tables as if followed by <code>next;</code> action.
            The next tables will see the changes in the packet caused by
            the connection tracker.
          </p>
          <p>
            <code>ct_dnat(<var>IP</var>)</code> sends the packet through the
            DNAT zone to change the destination IP address of the packet to
            the one provided inside the parentheses and commits the connection.
            The packet is then automatically sent to the next tables as if
            followed by <code>next;</code> action.  The next tables will see
            the changes in the packet caused by the connection tracker.
          </p>
        </dd>

        <dt><code>ct_snat;</code></dt>
        <dt><code>ct_snat(<var>IP</var>);</code></dt>
        <dd>
          <p>
            <code>ct_snat</code> sends the packet through the SNAT zone to
            unSNAT any packet that was SNATed in the opposite direction.  The
            packet is automatically sent to the next tables as if followed by
            the <code>next;</code> action.   The next tables will see the
            changes in the packet caused by the connection tracker.
          </p>
          <p>
            <code>ct_snat(<var>IP</var>)</code> sends the packet through the
            SNAT zone to change the source IP address of the packet to
            the one provided inside the parenthesis and commits the connection.
            The packet is then automatically sent to the next tables as if
            followed by <code>next;</code> action.  The next tables will see the
            changes in the packet caused by the connection tracker.
          </p>
        </dd>

        <dt><code>ct_dnat_in_czone;</code></dt>
        <dt><code>ct_dnat_in_czone(<var>IP</var>);</code></dt>
        <dd>
          <p>
            <code>ct_dnat_in_czone</code> sends the packet through the common
            NAT zone (used for both DNAT and SNAT) in connection tracking table
            to unDNAT any packet that was DNATed in the opposite direction.
            The packet is then automatically sent to to the next tables as if
            followed by <code>next;</code> action.  The next tables will see
            the changes in the packet caused by the connection tracker.
          </p>
          <p>
            <code>ct_dnat_in_czone(<var>IP</var>)</code> sends the packet
            through the common NAT zone to change the destination IP address
            of the packet to the one provided inside the parentheses and
            commits the connection.  The packet is then automatically sent to
            the next tables as if followed by <code>next;</code> action.  The
            next tables will see the changes in the packet caused by the
            connection tracker.
          </p>
        </dd>

        <dt><code>ct_snat_in_czone;</code></dt>
        <dt><code>ct_snat_in_czone(<var>IP</var>);</code></dt>
        <dd>
          <p>
            <code>ct_snat_in_czone</code> sends the packet through the common
            NAT zone to unSNAT any packet that was SNATed in the opposite
            direction.  The packet is automatically sent to the next tables as
            if followed by the <code>next;</code> action.   The next tables
            will see the changes in the packet caused by the connection
            tracker.
          </p>
          <p>
            <code>ct_snat_in_czone(<var>IP</var>)</code> sends the packet\
            through the common NAT zone to change the source IP address of
            the packet to the one provided inside the parenthesis and commits
            the connection.  The packet is then automatically sent to the next
            tables as if followed by <code>next;</code> action.  The next
            tables will see the changes in the packet caused by the connection
            tracker.
          </p>
        </dd>

        <dt><code>ct_clear;</code></dt>
        <dd>
          Clears connection tracking state.
        </dd>

        <dt><code>ct_commit_nat;</code></dt>
        <dd>
          <p>
            Applies NAT and commits the connection to the CT. Automatically
            moves on to the next table, as if followed by
            <code>next</code>.
            This is very useful for connections that are in related state for
            already existing connections and allows the NAT to be applied
            to them as well.
          </p>
        </dd>

        <dt><code>clone { <var>action</var>; </code>...<code> };</code></dt>
        <dd>
          Makes a copy of the packet being processed and executes each
          <code>action</code> on the copy.  Actions following the
          <var>clone</var> action, if any, apply to the original, unmodified
          packet.  This can be used as a way to ``save and restore'' the packet
          around a set of actions that may modify it and should not persist.
        </dd>

        <dt><code>arp { <var>action</var>; </code>...<code> };</code></dt>
        <dd>
          <p>
            Temporarily replaces the IPv4 packet being processed by an ARP
            packet and executes each nested <var>action</var> on the ARP
            packet.  Actions following the <var>arp</var> action, if any, apply
            to the original, unmodified packet.
          </p>

          <p>
            The ARP packet that this action operates on is initialized based on
            the IPv4 packet being processed, as follows.  These are default
            values that the nested actions will probably want to change:
          </p>

          <ul>
            <li><code>eth.src</code> unchanged</li>
            <li><code>eth.dst</code> unchanged</li>
            <li><code>eth.type = 0x0806</code></li>
            <li><code>arp.op = 1</code> (ARP request)</li>
            <li><code>arp.sha</code> copied from <code>eth.src</code></li>
            <li><code>arp.spa</code> copied from <code>ip4.src</code></li>
            <li><code>arp.tha = 00:00:00:00:00:00</code></li>
            <li><code>arp.tpa</code> copied from <code>ip4.dst</code></li>
          </ul>

          <p>
            The ARP packet has the same VLAN header, if any, as the IP packet
            it replaces.
          </p>

          <p><b>Prerequisite:</b> <code>ip4</code></p>
        </dd>

        <dt><code>get_arp(<var>P</var>, <var>A</var>);</code></dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 32-bit
            IP address field <var>A</var>.
          </p>

          <p>
            Looks up <var>A</var> in <var>P</var>'s mac binding table.
            If an entry is found, stores its Ethernet address in
            <code>eth.dst</code>, otherwise stores
            <code>00:00:00:00:00:00</code> in <code>eth.dst</code>.
          </p>

          <p><b>Example:</b> <code>get_arp(outport, ip4.dst);</code></p>
        </dd>

        <dt>
          <code>put_arp(<var>P</var>, <var>A</var>, <var>E</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 32-bit
            IP address field <var>A</var>, 48-bit Ethernet address field
            <var>E</var>.
          </p>

          <p>
            Adds or updates the entry for IP address <var>A</var> in
            logical port <var>P</var>'s mac binding table, setting its
            Ethernet address to <var>E</var>.
          </p>

          <p><b>Example:</b> <code>put_arp(inport, arp.spa, arp.sha);</code></p>
        </dd>

        <dt>
          <code><var>R</var> = lookup_arp(<var>P</var>, <var>A</var>, <var>M</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 32-bit
            IP address field <var>A</var>, 48-bit MAC address field
            <var>M</var>.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Looks up <var>A</var> and <var>M</var> in <var>P</var>'s mac
            binding table. If an entry is found, stores <code>1</code> in
            the 1-bit subfield <var>R</var>, else 0.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
            </code>
          </p>
        </dd>

        <dt>
          <code><var>R</var> = lookup_arp_ip(<var>P</var>, <var>A</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 32-bit
            IP address field <var>A</var>.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Looks up <var>A</var> in <var>P</var>'s mac binding table. If an
            entry is found, stores <code>1</code> in the 1-bit subfield
            <var>R</var>, else 0.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[0] = lookup_arp_ip(inport, arp.spa);
            </code>
          </p>
        </dd>

        <dt><code><var>P</var> = get_fdb(<var>A</var>);</code></dt>

        <dd>
          <p>
            <b>Parameters</b>:48-bit MAC address field <var>A</var>.
          </p>

          <p>
            Looks up <var>A</var> in fdb table. If an entry is found, stores
            the logical port key to the out parameter <code>P</code>.
          </p>

          <p><b>Example:</b> <code>outport = get_fdb(eth.src);</code></p>
        </dd>

        <dt>
          <code>put_fdb(<var>P</var>, <var>A</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 48-bit
            MAC address field <var>A</var>.
          </p>

          <p>
            Adds or updates the entry for Ethernet address <var>A</var> in
            fdb table, setting its logical port key to <var>P</var>.
          </p>

          <p><b>Example:</b> <code>put_fdb(inport, arp.spa);</code></p>
        </dd>

        <dt>
          <code><var>R</var> = lookup_fdb(<var>P</var>, <var>A</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: 48-bit MAC address field <var>M</var>,
            logical port string field <var>P</var>.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Looks up <var>A</var> in fdb table. If an entry is found
            and the the logical port key is <var>P</var>, <code>P</code>,
            stores <code>1</code> in the 1-bit subfield
            <var>R</var>, else 0.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[0] = lookup_fdb(inport, eth.src);
            </code>
          </p>
        </dd>

        <dt><code>nd_ns { <var>action</var>; </code>...<code> };</code></dt>
        <dd>
          <p>
            Temporarily replaces the IPv6 packet being processed by an IPv6
            Neighbor Solicitation packet and executes each nested
            <var>action</var> on the IPv6 NS packet.  Actions following the
            <var>nd_ns</var> action, if any, apply to the original, unmodified
            packet.
          </p>

          <p>
            The IPv6 NS packet that this action operates on is initialized
            based on the IPv6 packet being processed, as follows.  These are
            default values that the nested actions will probably want to
            change:
          </p>

          <ul>
            <li><code>eth.src</code> unchanged</li>
            <li><code>eth.dst</code> set to IPv6 multicast MAC address</li>
            <li><code>eth.type = 0x86dd</code></li>
            <li><code>ip6.src</code> copied from <code>ip6.src</code></li>
            <li>
              <code>ip6.dst</code> set to IPv6 Solicited-Node multicast address
            </li>
            <li><code>icmp6.type = 135</code> (Neighbor Solicitation)</li>
            <li><code>nd.target</code> copied from <code>ip6.dst</code></li>
          </ul>

          <p>
            The IPv6 NS packet has the same VLAN header, if any, as the IP
            packet it replaces.
          </p>

          <p><b>Prerequisite:</b> <code>ip6</code></p>
        </dd>

        <dt>
          <code>nd_na { <var>action</var>; </code>...<code> };</code>
        </dt>

        <dd>
          <p>
            Temporarily replaces the IPv6 neighbor solicitation packet
            being processed by an IPv6 neighbor advertisement (NA)
            packet and executes each nested <var>action</var> on the NA
            packet.  Actions following the <code>nd_na</code> action,
            if any, apply to the original, unmodified packet.
          </p>

          <p>
            The NA packet that this action operates on is initialized based on
            the IPv6 packet being processed, as follows. These are default
            values that the nested actions will probably want to change:
          </p>

          <ul>
            <li><code>eth.dst</code> exchanged with <code>eth.src</code></li>
            <li><code>eth.type = 0x86dd</code></li>
            <li><code>ip6.dst</code> copied from <code>ip6.src</code></li>
            <li><code>ip6.src</code> copied from <code>nd.target</code></li>
            <li><code>icmp6.type = 136</code> (Neighbor Advertisement)</li>
            <li><code>nd.target</code> unchanged</li>
            <li><code>nd.sll = 00:00:00:00:00:00</code></li>
            <li><code>nd.tll</code> copied from <code>eth.dst</code></li>
          </ul>

          <p>
            The ND packet has the same VLAN header, if any, as the IPv6 packet
            it replaces.
          </p>

          <p>
            <b>Prerequisite:</b> <code>nd_ns</code>
          </p>
        </dd>

        <dt>
          <code>nd_na_router { <var>action</var>; </code>...<code> };</code>
        </dt>

        <dd>
          <p>
            Temporarily replaces the IPv6 neighbor solicitation packet
            being processed by an IPv6 neighbor advertisement (NA)
            packet, sets ND_NSO_ROUTER in the RSO flags and executes each
            nested <var>action</var> on the NA packet.  Actions following
            the <code>nd_na_router</code> action, if any, apply to the
            original, unmodified packet.
          </p>

          <p>
            The NA packet that this action operates on is initialized based on
            the IPv6 packet being processed, as follows. These are default
            values that the nested actions will probably want to change:
          </p>

          <ul>
            <li><code>eth.dst</code> exchanged with <code>eth.src</code></li>
            <li><code>eth.type = 0x86dd</code></li>
            <li><code>ip6.dst</code> copied from <code>ip6.src</code></li>
            <li><code>ip6.src</code> copied from <code>nd.target</code></li>
            <li><code>icmp6.type = 136</code> (Neighbor Advertisement)</li>
            <li><code>nd.target</code> unchanged</li>
            <li><code>nd.sll = 00:00:00:00:00:00</code></li>
            <li><code>nd.tll</code> copied from <code>eth.dst</code></li>
          </ul>

          <p>
            The ND packet has the same VLAN header, if any, as the IPv6 packet
            it replaces.
          </p>

          <p>
            <b>Prerequisite:</b> <code>nd_ns</code>
          </p>
        </dd>

        <dt><code>get_nd(<var>P</var>, <var>A</var>);</code></dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 128-bit
            IPv6 address field <var>A</var>.
          </p>

          <p>
            Looks up <var>A</var> in <var>P</var>'s mac binding table.
            If an entry is found, stores its Ethernet address in
            <code>eth.dst</code>, otherwise stores
            <code>00:00:00:00:00:00</code> in <code>eth.dst</code>.
          </p>

          <p><b>Example:</b> <code>get_nd(outport, ip6.dst);</code></p>
        </dd>

        <dt>
          <code>put_nd(<var>P</var>, <var>A</var>, <var>E</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>,
            128-bit IPv6 address field <var>A</var>, 48-bit Ethernet
            address field <var>E</var>.
          </p>

          <p>
            Adds or updates the entry for IPv6 address <var>A</var> in
            logical port <var>P</var>'s mac binding table, setting its
            Ethernet address to <var>E</var>.
          </p>

          <p><b>Example:</b> <code>put_nd(inport, nd.target, nd.tll);</code></p>
        </dd>

        <dt><code><var>R</var> = lookup_nd(<var>P</var>, <var>A</var>, <var>M</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 128-bit
            IP address field <var>A</var>, 48-bit MAC address field
            <var>M</var>.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Looks up <var>A</var> and <var>M</var> in <var>P</var>'s mac
            binding table. If an entry is found, stores <code>1</code> in
            the 1-bit subfield <var>R</var>, else 0.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[0] = lookup_nd(inport, ip6.src, eth.src);
            </code>
          </p>
        </dd>

        <dt><code><var>R</var> = lookup_nd_ip(<var>P</var>, <var>A</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>, 128-bit
            IP address field <var>A</var>.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Looks up <var>A</var> in <var>P</var>'s mac binding table. If an
            entry is found, stores <code>1</code> in the 1-bit subfield
            <var>R</var>, else 0.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[0] = lookup_nd_ip(inport, ip6.src);
            </code>
          </p>
        </dd>

        <dt>
          <code><var>R</var> = put_dhcp_opts(<var>D1</var> = <var>V1</var>, <var>D2</var> = <var>V2</var>, ..., <var>Dn</var> = <var>Vn</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: one or more DHCP option/value pairs, which must
            include an <code>offerip</code> option (with code 0).
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Valid only in the ingress pipeline.
          </p>

          <p>
            When this action is applied to a DHCP request packet (DHCPDISCOVER
            or DHCPREQUEST), it changes the packet into a DHCP reply (DHCPOFFER
            or DHCPACK, respectively), replaces the options by those specified
            as parameters, and stores 1 in <var>R</var>.
          </p>

          <p>
            When this action is applied to a non-DHCP packet or a DHCP packet
            that is not DHCPDISCOVER or DHCPREQUEST, it leaves the packet
            unchanged and stores 0 in <var>R</var>.
          </p>

          <p>
            The contents of the <ref table="DHCP_Option"/> table control the
            DHCP option names and values that this action supports.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router = 10.0.0.1,
              netmask = 255.255.255.0, dns_server = {8.8.8.8, 7.7.7.7});
            </code>
          </p>
        </dd>

        <dt>
          <code><var>R</var> = put_dhcpv6_opts(<var>D1</var> = <var>V1</var>, <var>D2</var> = <var>V2</var>, ..., <var>Dn</var> = <var>Vn</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: one or more DHCPv6 option/value pairs.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Valid only in the ingress pipeline.
          </p>

          <p>
            When this action is applied to a DHCPv6 request packet, it changes
            the packet into a DHCPv6 reply, replaces the options by those
            specified as parameters, and stores 1 in <var>R</var>.
          </p>

          <p>
            When this action is applied to a non-DHCPv6 packet or an invalid
            DHCPv6 request packet , it leaves the packet unchanged and stores
            0 in <var>R</var>.
          </p>

          <p>
            The contents of the <ref table="DHCPv6_Options"/> table control the
            DHCPv6 option names and values that this action supports.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4, server_id = 00:00:00:00:10:02,
              dns_server={ae70::1,ae70::2});
            </code>
          </p>
        </dd>

        <dt>
          <code>set_queue(<var>queue_number</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: Queue number <var>queue_number</var>, in the range 0 to 61440.
          </p>

          <p>
            This is a logical equivalent of the OpenFlow <code>set_queue</code>
            action.  It affects packets that egress a hypervisor through a
            physical interface.  For nonzero <var>queue_number</var>, it
            configures packet queuing to match the settings configured for the
            <ref table="Port_Binding"/> with
            <code>options:qdisc_queue_id</code> matching
            <var>queue_number</var>.  When <var>queue_number</var> is zero, it
            resets queuing to the default strategy.
          </p>

          <p><b>Example:</b> <code>set_queue(10);</code></p>
        </dd>

        <dt><code>ct_lb;</code></dt>
        <dt><code>ct_lb(backends=<var>ip</var>[:<var>port</var>][,...][; hash_fields=<var>field1</var>,<var>field2</var>,...][; ct_flag]);</code></dt>
        <dd>
          <p>
            With arguments, <code>ct_lb</code> commits the packet
            to the connection tracking table and DNATs the packet's destination
            IP address (and port) to the IP address or addresses (and optional
            ports) specified in the <code>backends</code>.  If multiple
            comma-separated IP addresses are specified, each is given equal
            weight for picking the DNAT address. By default,
            <code>dp_hash</code> is used as the OpenFlow group selection
            method, but if <code>hash_fields</code> is specified,
            <code>hash</code> is used as the selection method, and the fields
            listed are used as the hash fields. The <code>ct_flag</code>
            field represents one of supported flag: <code>skip_snat</code> or
            <code>force_snat</code>, this flag will be stored in
            <code>ct_label</code> register.
          </p>
          <p>
            Without arguments, <code>ct_lb</code> sends the packet to the
            connection tracking table to NAT the packets.  If the packet is
            part of an established connection that was previously committed to
            the connection tracker via <code>ct_lb(</code>...<code>)</code>, it
            will automatically get DNATed to the same IP address as the first
            packet in that connection.
          </p>
          <p>
            Processing automatically moves on to the next table,
            as if <code>next;</code> were specified, and later tables act on
            the packet as modified by the connection tracker.  Connection
            tracking state is scoped by the logical port when the action is
            used in a flow for a logical switch, so overlapping
            addresses may be used.  Connection tracking state is scoped by the
            logical topology when the action is used in a flow for a router.
          </p>
        </dd>

        <dt><code>ct_lb_mark;</code></dt>
        <dt><code>ct_lb_mark(backends=<var>ip</var>[:<var>port</var>][,...][; hash_fields=<var>field1</var>,<var>field2</var>,...][; ct_flag]);</code></dt>
        <dd>
          <p>
              Same as <code>ct_lb</code>, except that it internally uses ct_mark
              to store the NAT flag, while <code>ct_lb</code> uses ct_label for
              the same purpose.
          </p>
        </dd>

        <dt>
          <code><var>R</var> = dns_lookup();</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: No parameters.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Valid only in the ingress pipeline.
          </p>

          <p>
            When this action is applied to a valid DNS request (a UDP packet
            typically directed to port 53), it attempts to resolve the query
            using the contents of the <ref table="DNS"/> table.  If it is
            successful, it changes the packet into a DNS reply and stores 1 in
            <var>R</var>.  If the action is applied to a non-DNS packet, an
            invalid DNS request packet, or a valid DNS request for which the
            <ref table="DNS"/> table does not supply an answer, it leaves the
            packet unchanged and stores 0 in <var>R</var>.
          </p>

          <p>
            Regardless of success, the action does not make any of the changes
            to the flow that are necessary to direct the packet back to the
            requester.  The logical pipeline can implement this behavior with
            matches and actions in later tables.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[3] = dns_lookup();
            </code>
          </p>

          <p>
            <b>Prerequisite:</b> <code>udp</code>
          </p>
        </dd>

        <dt>
          <code><var>R</var> = put_nd_ra_opts(<var>D1</var> = <var>V1</var>, <var>D2</var> = <var>V2</var>, ..., <var>Dn</var> = <var>Vn</var>);</code>
        </dt>

        <dd>
          <p>
            <b>Parameters</b>: The following IPv6 ND Router Advertisement
               option/value pairs as defined in RFC 4861.

            <ul>
              <li>
                <code>addr_mode</code>
                <p>
                  Mandatory parameter which specifies the address mode flag to
                  be set in the RA flag options field. The value of this option
                  is a string and the following values can be defined -
                  "slaac", "dhcpv6_stateful" and "dhcpv6_stateless".
                </p>
              </li>

              <li>
                <code>slla</code>
                <p>
                  Mandatory parameter which specifies the link-layer address of
                  the interface from which the Router Advertisement is sent.
                </p>
              </li>

              <li>
                <code>mtu</code>
                <p>
                  Optional parameter which specifies the MTU.
                </p>
              </li>

              <li>
                <code>prefix</code>
                <p>
                  Optional parameter which should be specified if the addr_mode
                  is "slaac" or "dhcpv6_stateless". The value should be an IPv6
                  prefix which will be used for stateless IPv6 address
                  configuration. This option can be defined multiple times.
                </p>
              </li>
            </ul>
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            Valid only in the ingress pipeline.
          </p>

          <p>
            When this action is applied to an IPv6 Router solicitation request
            packet, it changes the packet into an IPv6 Router Advertisement
            reply and adds the options specified in the parameters, and stores
            1 in <var>R</var>.
          </p>

          <p>
            When this action is applied to a non-IPv6 Router solicitation
            packet or an invalid IPv6 request packet , it leaves the packet
            unchanged and stores 0 in <var>R</var>.
          </p>

          <p>
            <b>Example:</b>
            <code>
              reg0[3] = put_nd_ra_opts(addr_mode = "slaac",
              slla = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
            </code>
          </p>
        </dd>

        <dt><code>set_meter(<var>rate</var>);</code></dt>
        <dt><code>set_meter(<var>rate</var>, <var>burst</var>);</code></dt>
        <dd>
          <p>
            <b>Parameters</b>: rate limit int field <var>rate</var> in kbps,
            burst rate limits int field <var>burst</var> in kbps.
          </p>

          <p>
            This action sets the rate limit for a flow.
          </p>

          <p><b>Example:</b> <code>set_meter(100, 1000);</code></p>
        </dd>

        <dt><code><var>R</var> = check_pkt_larger(<var>L</var>)</code></dt>
        <dd>
          <p>
            <b>Parameters</b>: packet length <var>L</var> to check for
            in bytes.
          </p>

          <p>
            <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
          </p>

          <p>
            This is a logical equivalent of the OpenFlow
            <code>check_pkt_larger</code> action. If the packet is larger
            than the length specified in <var>L</var>, it stores 1 in the
            subfield <var>R</var>.
          </p>

          <p><b>Example: </b><code>reg0[6] = check_pkt_larger(1000);</code></p>
        </dd>
      </dl>

      <dl>
        <dt>
          <code>log(<var>key</var>=<var>value</var>, </code>...<code>);</code>
        </dt>

        <dd>
          <p>
            Causes <code>ovn-controller</code> to log the packet on the chassis
            that processes it.  Packet logging currently uses the same logging
            mechanism as other Open vSwitch and OVN messages, which means that
            whether and where log messages appear depends on the local logging
            configuration that can be configured with <code>ovs-appctl</code>,
            etc.
          </p>
          <p>
            The <code>log</code> action takes zero or more of the following
            key-value pair arguments that control what is logged:
          </p>
          <dl>
            <dt><code>name=</code><var>string</var></dt>
            <dd>
              An optional name for the ACL.  The <var>string</var> is
              currently limited to 64 bytes.
            </dd>
            <dt><code>severity=</code><var>level</var></dt>
            <dd>
              Indicates the severity of the event.  The <var>level</var> is one
              of following (from more to less serious): <code>alert</code>,
              <code>warning</code>, <code>notice</code>, <code>info</code>, or
              <code>debug</code>.  If a severity is not provided, the default
              is <code>info</code>.
            </dd>
            <dt><code>verdict=</code><var>value</var></dt>
            <dd>
              The verdict for packets matching the flow.  The value must be one
              of <code>allow</code>, <code>deny</code>, or <code>reject</code>.
            </dd>
            <dt><code>meter=</code><var>string</var></dt>
            <dd>
              An optional rate-limiting meter to be applied to the logs.
              The <var>string</var> should reference a
              <ref column="name" table="Meter"/> entry from the
              <ref table="Meter"/> table.  The only meter
              <ref column="action" table="meter"/> that is appropriate
              is <code>drop</code>.
            </dd>
          </dl>
        </dd>

        <dt><code>fwd_group(liveness=<var>bool</var>, childports=<var>port</var>, ...);</code></dt>
        <dd>
          <p>
            <b>Parameters</b>: optional <code>liveness</code>, either
            <code>true</code> or <code>false</code>, defaulting to false;
            <code>childports</code>, a comma-delimited list of strings denoting
            logical ports to load balance across.
          </p>

          <p>
            Load balance traffic to one or more child ports in a logical
            switch. <code>ovn-controller</code> translates the
            <code>fwd_group</code> into an OpenFlow group with one bucket for
            each child port. If <code>liveness=true</code> is specified, it
            also integrates the bucket selection with BFD status on the tunnel
            interface corresponding to child port.
          </p>

          <p><b>Example:</b> <code>fwd_group(liveness=true, childports="p1",
          "p2");</code></p>
        </dd>
      </dl>

      <dl>
        <dt><code>icmp4 { <var>action</var>; </code>...<code> };</code></dt>
        <dt>
          <code>icmp4_error { <var>action</var>; </code>...<code> };</code>
        </dt>
        <dd>
          <p>
            Temporarily replaces the IPv4 packet being processed by an ICMPv4
            packet and executes each nested <var>action</var> on the ICMPv4
            packet.  Actions following these actions, if any,
            apply to the original, unmodified packet.
          </p>

          <p>
            The ICMPv4 packet that these actions operates on is initialized
            based on the IPv4 packet being processed, as follows.  These are
            default values that the nested actions will probably want to
            change. Ethernet and IPv4 fields not listed here are not changed:
          </p>

          <ul>
            <li><code>ip.proto = 1</code> (ICMPv4)</li>
            <li><code>ip.frag = 0</code> (not a fragment)</li>
            <li><code>ip.ttl = 255</code></li>
            <li><code>icmp4.type = 3</code> (destination unreachable)</li>
            <li><code>icmp4.code = 1</code> (host unreachable)</li>
          </ul>

          <p>
              <code>icmp4_error</code> action is expected to be used to
              generate an ICMPv4 packet in response to an error in original
              IP packet. When this action generates the ICMPv4 packet, it
              also copies the original IP datagram following the ICMPv4 header
              as per RFC 1122: 3.2.2.
          </p>
          <p><b>Prerequisite:</b> <code>ip4</code></p>
        </dd>

        <dt><code>icmp6 { <var>action</var>; </code>...<code> };</code></dt>
        <dt>
          <code>icmp6_error { <var>action</var>; </code>...<code> };</code>
        </dt>
        <dd>
          <p>
            Temporarily replaces the IPv6 packet being processed by an ICMPv6
            packet and executes each nested <var>action</var> on the ICMPv6
            packet. Actions following the <var>icmp6</var> action, if any,
            apply to the original, unmodified packet.
          </p>

          <p>
            The ICMPv6 packet that this action operates on is initialized based
            on the IPv6 packet being processed, as follows. These are default
            values that the nested actions will probably want to change.
            Ethernet and IPv6 fields not listed here are not changed:
          </p>

          <ul>
            <li><code>ip.proto = 58</code> (ICMPv6)</li>
            <li><code>ip.ttl = 255</code></li>
            <li><code>icmp6.type = 1</code> (destination unreachable)</li>
            <li><code>icmp6.code = 1</code> (administratively prohibited)</li>
          </ul>

          <p>
              <code>icmp6_error</code> action is expected to be used to
              generate an ICMPv6 packet in response to an error in original
              IPv6 packet.
          </p>
          <p><b>Prerequisite:</b> <code>ip6</code></p>
        </dd>

        <dt><code>tcp_reset;</code></dt>
        <dd>
          <p>
            This action transforms the current TCP packet according to the
            following pseudocode:
          </p>

          <pre>
if (tcp.ack) {
        tcp.seq = tcp.ack;
} else {
        tcp.ack = tcp.seq + length(tcp.payload);
        tcp.seq = 0;
}
tcp.flags = RST;
</pre>

          <p>
            Then, the action drops all TCP options and payload data, and
            updates the TCP checksum. IP ttl is set to 255.
          </p>

          <p><b>Prerequisite:</b> <code>tcp</code></p>
        </dd>

        <dt><code>reject { <var>action</var>; </code>...<code> };</code></dt>
        <dd>
          <p>
            If the original packet is IPv4 or IPv6 TCP packet, it replaces it
            with IPv4 or IPv6 TCP RST packet and executes the inner actions.
            Otherwise it replaces it with an ICMPv4 or ICMPv6 packet and
            executes the inner actions.
          </p>

          <p>
            The inner actions should not attempt to swap eth source with eth
            destination and IP source with IP destination as this action
            implicitly does that.
          </p>
        </dd>

        <dt><code>trigger_event;</code></dt>
        <dd>
          <p>
            This action is used to allow ovs-vswitchd to report CMS related
            events writing them in <ref table="Controller_Event"/> table.
            It is possible to associate a meter to a each event in order to
            not overload pinctrl thread under heavy load; each meter is
            identified though a defined naming convention. Supported events:
          </p>

          <ul>
            <li>
              <p>
                <dfn>empty_lb_backends</dfn>. This event is raised if a
                received packet is destined for a load balancer VIP that has
                no configured backend destinations. For this event, the event
                info includes the load balancer VIP, the load balancer UUID,
                and the transport protocol.
                Associated meter: <code>event-elb</code>
              </p>
            </li>
          </ul>
        </dd>
        <dt><code>igmp;</code></dt>
        <dd>
          <p>
            This action sends the packet to <code>ovn-controller</code> for
            multicast snooping.
          </p>
          <p><b>Prerequisite:</b> <code>igmp</code></p>
        </dd>

        <dt><code>bind_vport(<var>V</var>, <var>P</var>);</code></dt>
        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>V</var>
            of type <code>virtual</code>, logical port string field
            <var>P</var>.
          </p>

          <p>
            Binds the virtual logical port <var>V</var> and sets the
            <ref table="Port_Binding" column="chassis"/> column and
            <ref table="Port_Binding" column="virtual_parent"/> of
            the table <ref table="Port_Binding"/>.
            <ref table="Port_Binding" column="virtual_parent"/> is
            set to <var>P</var>.
          </p>
        </dd>

        <dt><code>handle_svc_check(<var>P</var>);</code></dt>
        <dd>
          <p>
            <b>Parameters</b>: logical port string field <var>P</var>.
          </p>

          <p>
            Handles the service monitor reply received from the VIF of
            the logical port <var>P</var>. <code>ovn-controller</code>
            periodically sends out the service monitor packets for the
            services configured in the <ref table="Service_Monitor"/>
            table and this action updates the status of those services.
          </p>

          <p><b>Example:</b> <code>handle_svc_check(inport);</code></p>
        </dd>

        <dt><code>handle_dhcpv6_reply;</code></dt>
        <dd>
          <p>
            Handle DHCPv6 prefix delegation advertisements/replies from
            a IPv6 delegation server. <code>ovn-controller</code> will
            add an entry <code>ipv6_ra_pd_list</code> in the
            <ref table="Port_Binding" column="options"/> table for each
            prefix received from the delegation server
          </p>
        </dd>

        <dt><code><var>R</var> = select(<var>N1</var>[=<var>W1</var>], <var>N2</var>[=<var>W2</var>], ...);</code></dt>
        <dd>
          <p>
            <b>Parameters</b>: Integer <var>N1</var>, <var>N2</var>..., with
            optional weight <var>W1</var>, <var>W2</var>, ...
          </p>

          <p>
            <b>Result</b>: stored to a logical field or subfield <var>R</var>.
          </p>

          <p>
            Select from a list of integers <var>N1</var>, <var>N2</var>...,
            each within the range 0 ~ 65535, and store the selected one in the
            field <var>R</var>.  There must be 2 or more integers listed, each
            with an optional weight, which is an integer within the range 1 ~
            65535.  If weight is not specified, it defaults to 100. The
            selection method is based on the 5-tuple hash of packet header.
          </p>

          <p>
            Processing automatically moves on to the next table, as if
            <code>next;</code> were specified.  The <code>select</code> action
            must be put as the last action of the logical flow when there are
            multiple actions (actions put after <code>select</code> will not
            take effect).
          </p>

          <p>
            <b>Example:</b> <code>reg8[16..31] = select(1=20, 2=30, 3=50);</code>
          </p>
        </dd>

        <dt><code>handle_dhcpv6_reply;</code></dt>
        <dd>
          <p>
            This action is used to parse DHCPv6 replies from IPv6
            Delegation Router and managed IPv6 Prefix delegation state machine
          </p>
        </dd>

        <dt><code><var>R</var> = chk_lb_hairpin();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration was destined
            to a load balancer VIP and it is hairpinned, i.e., after load
            balancing the destination IP matches the source IP. If it is so,
            then the 1-bit destination register <var>R</var> is set to 1.
          </p>
        </dd>

        <dt><code><var>R</var> = chk_lb_hairpin_reply();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration is from
            one of the backend IP of a load balancer VIP and the destination IP
            is the load balancer VIP. If it is so, then the 1-bit destination
            register <var>R</var> is set to 1.
          </p>
        </dd>

        <dt><code><var>R</var> = ct_snat_to_vip;</code></dt>
        <dd>
          <p>
            This action sends the packet through the SNAT zone to change the
            source IP address of the packet to the load balancer VIP if the
            original destination IP was load balancer VIP and commits the
            connection. This action applies successfully only for the
            hairpinned traffic i.e if the action <code>chk_lb_hairpin</code>
            returned success. This action doesn't take any arguments and it
            determines the SNAT IP internally.

            The packet is not automatically sent to the next table. The caller
            has to execute the <code>next;</code> action explicitly after this
            action to advance the packet to the next stage.
          </p>
        </dd>

        <dt><code><var>R</var> = check_in_port_sec();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration passes the
            inport port security checks.  If the packet fails the port security
            checks, then <code>1</code> is stored in the destination register
            <var>R</var>.  Else 0 is stored.  The port security values to check
            are retrieved from the the <code>inport</code> logical port.
          </p>

          <p>
            This action should be used in the ingress logical switch pipeline.

          </p>
          <p>
            <b>Example:</b> <code>reg8[0..7] = check_in_port_sec();</code>
          </p>
        </dd>

        <dt><code><var>R</var> = check_out_port_sec();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration passes the
            outport port security checks.  If the packet fails the port
            security checks, then <code>1</code> is stored in the destination
            register <var>R</var>.  Else 0 is stored.  The port security
            values to check are retrieved from the the <code>outport</code>
            logical port.
          </p>

          <p>
            This action should be used in the egress logical switch pipeline.

          </p>
          <p>
            <b>Example:</b> <code>reg8[0..7] = check_out_port_sec();</code>
          </p>
        </dd>

        <dt><code>commit_ecmp_nh(<var>ipv6</var>);</code></dt>
        <dd>
          <p>
              <b>Parameters</b>: IPv4/IPv6 traffic.
          </p>

          <p>
            This action translates to an openflow "learn" action that inserts
            two new flows in tables 76 and 77.
          </p>

          <ul>
            <li>
              Match on the the 5-tuple and the expected next-hop mac address
              in table 76: <code>nw_src=ip0</code>, <code>nw_dst=ip1</code>,
              <code>ip_proto</code>,<code>tp_src=l4_port0</code>,
              <code>tp_dst=l4_port1</code>,<code>dl_src=ethaddr</code> and
              set <code>reg9[5]</code>.
            </li>
            <li>
              Match on the 5-tuple in table 77: <code>nw_src=ip1</code>,
              <code>nw_dst=ip0</code>, <code>ip_proto</code>,
              <code>tp_src=l4_port1</code>, <code>tp_dst=l4_port0</code>
              and set <code>reg9[5]</code> to 1
            </li>
          </ul>

          <p>
            This action is applied if the packet arrives via ECMP route or
            if it is routed via an ECMP route
          </p>
        </dd>

        <dt><code><var>R</var> = check_ecmp_nh_mac();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration matches
            any flow in table 76. If it is so, then the 1-bit destination
            register <var>R</var> is set to 1.
          </p>
        </dd>

        <dt><code><var>R</var> = check_ecmp_nh();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration matches
            the any flow in table 77. If it is so, then the 1-bit destination
            register <var>R</var> is set to 1.
          </p>
        </dd>

        <dt>
          <code>
            commit_lb_aff(<var>vip</var>, <var>backend</var>,
            <var>proto</var>, <var>timeout</var>);
          </code>
        </dt>
        <dd>
          <p>
            <b>Parameters</b>: load-balancer virtual ip:port <var>vip</var>,
            load-balancer backend ip:port <var>backend</var>, load-balancer
            protocol <var>proto</var>, affinity timeout <var>timeout</var>.
          </p>

          <p>
            This action translates to an openflow "learn" action that inserts
            a new flow in table 78.
          </p>

          <ul>
            <li>
              Match on the 4-tuple in table 78: <code>nw_src=ip client</code>,
              <code>nw_dst=vip ip</code>, <code>ip_proto</code>,
              <code>tp_dst=vip port</code> and set <code>reg9[6]</code> to 1,
              <code>reg4</code> and <code>reg8</code> to backend ip and port
              respectively. For IPv6 register <code>xxreg1</code> is used to
              store the backend ip.
            </li>
          </ul>

          <p>
            This action is applied for new connections received by a specific
            load-balacer with affinity timeout configured.
          </p>
        </dd>

        <dt><code><var>R</var> = chk_lb_aff();</code></dt>
        <dd>
          <p>
            This action checks if the packet under consideration matches any
            flow in table 78. If it is so, then the 1-bit destination
            register <var>R</var> is set to 1.
          </p>
        </dd>

        <dt><code>sample(probability=<var>packets</var>, ...)</code></dt>
        <dd>
          <p>
            This action causes the matched traffic to be sampled using
            IPFIX protocol. More information about how per-flow IPFIX sampling
            works in OVS can be found in <code>ovs-actions</code>(7) and
            <code>ovs-vswitchd.conf.db</code>(5).
          </p>

          <p>
            In order to reliably identify each sampled packet when it is
            received by the IPFIX collector, this action sets the content of
            the <code>ObservationDomainID</code> and
            <code>ObservationPointID</code> IPFIX fields (see argument
            description below).
          </p>

          <p>
            The following key-value arguments are supported:
          </p>

          <dl>
            <dt><code>probability=</code><var>packets</var></dt>
            <dd>
              The number of sampled packets out of 65535. It must be greater or
              equal to 1.
            </dd>
            <dt><code>collector_set=</code><var>id</var></dt>
            <dd>
              The unsigned 32-bit integer identifier of the sample collector to
              send sampled packets to. It must match the value configured in
              the <code>Flow_Sample_Collector_Set</code> Table in OVS.
              Defaults to 0.
            </dd>
            <dt><code>obs_domain=</code><var>id</var></dt>
            <dd>
              An unsigned 8-bit integer that identifies the sampling
              application. It will be placed in the 8 most significant bits of
              the <code>ObservationDomainID</code> field of IPFIX samples.
              The 24 less significant bits will be automatically filled in with
              the datapath key. Defaults to 0.
            </dd>
            <dt><code>obs_point=</code><var>id</var></dt>
            <dd>
              An unsigned 32-bit integer to be used as
              <code>ObsservationPointID</code> or the string
              <code>@cookie</code> to indicate that the first 32 bits of the
              <code>Logical_Flow</code>'s UUID shall be used instead.
            </dd>
          </dl>
        </dd>
      </dl>
    </column>

    <column name="tags">
      Key-value pairs that provide additional information to help
      ovn-controller processing the logical flow. Below are the tags used
      by ovn-controller.

      <dl>
        <dt>in_out_port</dt>
        <dd>
          In the logical flow's "match" column, if a logical port P is
          compared with "inport" and the logical flow is on a logical switch
          ingress pipeline, or if P is compared with "outport" and the
          logical flow is on a logical switch egress pipeline, and the
          expression is combined with other expressions (if any) using the
          operator &amp;&amp;, then the port P should be added as the value in
          this tag. If there are multiple logical ports meeting this criteria,
          one of them can be added. ovn-controller uses this information to
          skip parsing flows that are not needed on the chassis. Failing to add
          the tag will affect efficiency, while adding wrong value will affect
          correctness.
        </dd>
      </dl>
    </column>

    <column name="controller_meter">
      The name of the meter in table <ref table="Meter"/> to be used for
      all packets that the logical flow might send to
      <code>ovn-controller</code>.
    </column>

    <column name="external_ids" key="stage-name">
      Human-readable name for this flow's stage in the pipeline.
    </column>

    <column name="external_ids" key="stage-hint" type='{"type": "uuid"}'>
      UUID of a <ref db="OVN_Northbound"/> record that caused this logical flow
      to be created.  Currently used only for attribute of logical flows to
      northbound <ref db="OVN_Northbound" table="ACL"/> records.
    </column>

    <column name="external_ids" key="source">
      Source file and line number of the code that added this flow to the
      pipeline.
    </column>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
    </group>
  </table>

  <table name="Logical_DP_Group" title="Logical Datapath Groups">
    <p>
      Each row in this table represents a group of logical datapaths referenced
      by the <ref column="logical_dp_group" table="Logical_Flow"/> column
      in the <ref table="Logical_Flow"/> table.
    </p>

    <column name="datapaths">
      <p>
        List of <ref table="Datapath_Binding"/> entries.
      </p>
    </column>
  </table>

  <table name="Multicast_Group" title="Logical Port Multicast Groups">
    <p>
      The rows in this table define multicast groups of logical ports.
      Multicast groups allow a single packet transmitted over a tunnel to a
      hypervisor to be delivered to multiple VMs on that hypervisor, which
      uses bandwidth more efficiently.
    </p>

    <p>
      Each row in this table defines a logical multicast group numbered <ref
      column="tunnel_key"/> within <ref column="datapath"/>, whose logical
      ports are listed in the <ref column="ports"/> column.
    </p>

    <column name="datapath">
      The logical datapath in which the multicast group resides.
    </column>

    <column name="tunnel_key">
      The value used to designate this logical egress port in tunnel
      encapsulations.  An index forces the key to be unique within the <ref
      column="datapath"/>.  The unusual range ensures that multicast group IDs
      do not overlap with logical port IDs.
    </column>

    <column name="name">
      <p>
        The logical multicast group's name.  An index forces the name to be
        unique within the <ref column="datapath"/>.  Logical flows in the
        ingress pipeline may output to the group just as for individual logical
        ports, by assigning the group's name to <code>outport</code> and
        executing an <code>output</code> action.
      </p>

      <p>
        Multicast group names and logical port names share a single namespace
        and thus should not overlap (but the database schema cannot enforce
        this).  To try to avoid conflicts, <code>ovn-northd</code> uses names
        that begin with <code>_MC_</code>.
      </p>
    </column>

    <column name="ports">
      The logical ports included in the multicast group.  All of these ports
      must be in the <ref column="datapath"/> logical datapath (but the
      database schema cannot enforce this).
    </column>
  </table>

  <table name="Mirror" title="Mirror Entry">
    <p>
      Each row in this table represents a mirror that can be used for
      port mirroring. These mirrors are referenced by the
      <ref column="mirror_rules" table="Port_Binding"/> column in
      the <ref table="Port_Binding"/> table.
    </p>

    <column name="name">
      <p>
        Represents the name of the mirror.
      </p>
    </column>

    <column name="filter">
      <p>
        The value of this field represents selection criteria of the mirror.
        <code>to-lport</code> mirrors the packets coming into logical port.
        <code>from-lport</code> mirrors the packets going out of logical port.
        <code>both</code> mirrors for both directions.
      </p>
    </column>

    <column name="sink">
      <p>
        The value of this field represents the destination/sink of the mirror.
        If the <var>type</var> is <code>gre</code> or <code>erspan</code>,
        the value indicates the tunnel remote IP (either IPv4 or IPv6).
        For a <var>type</var> of <code>local</code>, this field defines a
        local interface on the OVS integration bridge to be used as the
        mirror destination. The interface must possess external-ids:mirror-id
        that matches this string.
      </p>
    </column>

    <column name="type">
      <p>
        The value of this field specifies the mirror type - <code>gre</code>,
        <code>erspan</code> or <code>local</code>.
      </p>
    </column>

    <column name="index">
      <p>
        The value of this field represents the tunnel ID. If the configured
        tunnel type is <code>gre</code>, this field represents the
        <code>GRE</code> key value and if the configured tunnel type is
        <code>erspan</code> it represents the <code>erspan_idx</code> value.
        It is ignored if the type is <code>local</code>.
      </p>
    </column>

    <column name="external_ids">
      See <em>External IDs</em> at the beginning of this document.
    </column>
  </table>

  <table name="Meter" title="Meter entry">
    <p>
      Each row in this table represents a meter that can be used for QoS or
      rate-limiting.
    </p>

    <column name="name">
      <p>
        A name for this meter.
      </p>

      <p>
        Names that begin with "__" (two underscores) are reserved for
        OVN internal use and should not be added manually.
      </p>
    </column>

    <column name="unit">
      <p>
        The unit for <ref column="rate" table="Meter_Band"/> and
        <ref column="burst_rate" table="Meter_Band"/> parameters in
        the <ref column="bands"/> entry.  <code>kbps</code> specifies
        kilobits per second, and <code>pktps</code> specifies packets
        per second.
      </p>
    </column>

    <column name="bands">
      <p>
        The bands associated with this meter.  Each band specifies a
        rate above which the band is to take the action
        <code>action</code>.  If multiple bands' rates are exceeded,
        then the band with the highest rate among the exceeded bands is
        selected.
      </p>
    </column>
  </table>

  <table name="Meter_Band" title="Band for meter entries">
    <p>
      Each row in this table represents a meter band which specifies the
      rate above which the configured action should be applied.  These bands
      are referenced by the <ref column="bands" table="Meter"/> column in
      the <ref table="Meter"/> table.
    </p>

    <column name="action">
      <p>
        The action to execute when this band matches.  The only supported
        action is <code>drop</code>.
      </p>
    </column>

    <column name="rate">
      <p>
        The rate limit for this band, in kilobits per second or bits per
        second, depending on whether the parent <ref table="Meter"/>
        entry's <ref column="unit" table="Meter"/> column specified
        <code>kbps</code> or <code>pktps</code>.
      </p>
    </column>

    <column name="burst_size">
      <p>
        The maximum burst allowed for the band in kilobits or packets,
        depending on whether <code>kbps</code> or <code>pktps</code> was
        selected in the parent <ref table="Meter"/> entry's
        <ref column="unit" table="Meter"/> column.  If the size is zero,
        the switch is free to select some reasonable value depending on
        its configuration.
      </p>
    </column>
  </table>

  <table name="Datapath_Binding" title="Physical-Logical Datapath Bindings">
    <p>
      Each row in this table represents a logical datapath, which implements a
      logical pipeline among the ports in the <ref table="Port_Binding"/> table
      associated with it.  In practice, the pipeline in a given logical
      datapath implements either a logical switch or a logical router.
    </p>

    <p>
      The main purpose of a row in this table is provide a physical binding for
      a logical datapath.  A logical datapath does not have a physical
      location, so its physical binding information is limited: just <ref
      column="tunnel_key"/>.  The rest of the data in this table does not
      affect packet forwarding.
    </p>

    <column name="tunnel_key">
      The tunnel key value to which the logical datapath is bound.
      The <code>Tunnel Encapsulation</code> section in
      <code>ovn-architecture</code>(7) describes how tunnel keys are
      constructed for each supported encapsulation.
    </column>

    <column name="load_balancers">
      <p>
        Not used anymore; kept for backwards compatibility of the schema.
      </p>
    </column>

    <group title="OVN_Northbound Relationship">
      <p>
        Each row in <ref table="Datapath_Binding"/> is associated with some
        logical datapath.  <code>ovn-northd</code> uses these keys to track the
        association of a logical datapath with concepts in the <ref
        db="OVN_Northbound"/> database.
      </p>

      <column name="external_ids" key="logical-switch" type='{"type": "uuid"}'>
        For a logical datapath that represents a logical switch,
        <code>ovn-northd</code> stores in this key the UUID of the
        corresponding <ref table="Logical_Switch" db="OVN_Northbound"/> row in
        the <ref db="OVN_Northbound"/> database.
      </column>

      <column name="external_ids" key="logical-router" type='{"type": "uuid"}'>
        For a logical datapath that represents a logical router,
        <code>ovn-northd</code> stores in this key the UUID of the
        corresponding <ref table="Logical_Router" db="OVN_Northbound"/> row in
        the <ref db="OVN_Northbound"/> database.
      </column>

      <column name="external_ids" key="interconn-ts" type='{"type": "string"}'>
        For a logical datapath that represents a logical switch that represents
        a transit switch for interconnection, <code>ovn-northd</code> stores in
        this key the value of the same <code>interconn-ts</code> key of the <ref
        column="external_ids" table="Logical_Switch" db="OVN_Northbound"/>
        column of the corresponding <ref table="Logical_Switch"
        db="OVN_Northbound"/> row in the <ref db="OVN_Northbound"/> database.
      </column>

      <group title="Naming">
        <p>
          <code>ovn-northd</code> copies these from the name fields in the <ref
          db="OVN_Northbound"/> database, either from <ref
          table="Logical_Router" db="OVN_Northbound" column="name"/> and <ref
          table="Logical_Router" db="OVN_Northbound" column="external_ids"
          key="neutron:router_name"/> in the <ref table="Logical_Router"
          db="OVN_Northbound"/> table or from <ref table="Logical_Switch"
          db="OVN_Northbound" column="name"/> and <ref table="Logical_Switch"
          db="OVN_Northbound" column="external_ids"
          key="neutron:network_name"/> in the <ref table="Logical_Switch"
          db="OVN_Northbound"/> table.
        </p>

        <column name="external_ids" key="name">
          A name for the logical datapath.
        </column>

        <column name="external_ids" key="name2">
          Another name for the logical datapath.
        </column>
      </group>
    </group>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
    </group>
  </table>

  <table name="Port_Binding" title="Physical-Logical Port Bindings">
    <p>
      Each row in this table binds a logical port to a realization.  For most
      logical ports, this means binding to some physical location, for example
      by binding a logical port to a VIF that belongs to a VM running on a
      particular hypervisor.  Other logical ports, such as logical patch ports,
      can be realized without a specific physical location, but their bindings
      are still expressed through rows in this table.
    </p>

    <p>
      For every <code>Logical_Switch_Port</code> record in
      <code>OVN_Northbound</code> database, <code>ovn-northd</code>
      creates a record in this table.  <code>ovn-northd</code> populates
      and maintains every column except the <code>chassis</code> and
      <code>virtual_parent</code> columns, which it leaves empty in new records.
    </p>

    <p>
      <code>ovn-controller</code>/<code>ovn-controller-vtep</code>
      populates the <code>chassis</code> column for the records that
      identify the logical ports that are located on its hypervisor/gateway,
      which <code>ovn-controller</code>/<code>ovn-controller-vtep</code> in
      turn finds out by monitoring the local hypervisor's Open_vSwitch
      database, which identifies logical ports via the conventions described
      in <code>IntegrationGuide.rst</code>.  (The exceptions are for
      <code>Port_Binding</code> records with <code>type</code> of
      <code>l3gateway</code>, whose locations are identified by
      <code>ovn-northd</code> via the <code>options:l3gateway-chassis</code>
      column in this table.  <code>ovn-controller</code> is still responsible
      to populate the <code>chassis</code> column.)
    </p>

    <p>
      <code>ovn-controller</code> also populates the
      <code>virtual_parent</code> column of records whose <code>type</code> is
      <code>virtual</code>.
    </p>

    <p>
      When a chassis shuts down gracefully, it should clean up the
      <code>chassis</code> column that it previously had populated.
      (This is not critical because resources hosted on the chassis are equally
      unreachable regardless of whether their rows are present.)  To handle the
      case where a VM is shut down abruptly on one chassis, then brought up
      again on a different one,
      <code>ovn-controller</code>/<code>ovn-controller-vtep</code> must
      overwrite the <code>chassis</code> column with new information.
    </p>

    <group title="Core Features">
      <column name="datapath">
        The logical datapath to which the logical port belongs.
      </column>

      <column name="logical_port">
        A logical port.  For a logical switch port, this is taken from <ref
        table="Logical_Switch_Port" column="name" db="OVN_Northbound"/> in the
        OVN_Northbound database's <ref table="Logical_Switch_Port"
        db="OVN_Northbound"/> table.  For a logical router port, this is taken
        from <ref table="Logical_Router_Port" column="name"
        db="OVN_Northbound"/> in the OVN_Northbound database's <ref
        table="Logical_Router_port" db="OVN_Northbound"/> table.  (This means
        that logical switch ports and router port names must not share names in
        an OVN deployment.) OVN does not prescribe a particular format for the
        logical port ID.
      </column>

      <column name="encap">
        Points to preferred encapsulation configuration to transmit
        logical dataplane packets to this chassis. The entry is reference to
        a <ref table="Encap"/> record.
      </column>

      <column name="additional_encap">
        Points to preferred encapsulation configuration to transmit
        logical dataplane packets to this additional chassis. The entry is
        reference to a <ref table="Encap"/> record.

        See also <ref column="additional_chassis"/>.
      </column>

      <column name="chassis">
        The meaning of this column depends on the value of the <ref column="type"/>
        column.  This is the meaning for each <ref column="type"/>

        <dl>
          <dt>(empty string)</dt>
          <dd>
            The physical location of the logical port.  To successfully identify a
            chassis, this column must be a <ref table="Chassis"/> record.  This is
            populated by <code>ovn-controller</code>.
          </dd>

          <dt>vtep</dt>
          <dd>
            The physical location of the hardware_vtep gateway.  To successfully
            identify a chassis, this column must be a <ref table="Chassis"/> record.
            This is populated by <code>ovn-controller-vtep</code>.
          </dd>

          <dt>localnet</dt>
          <dd>
            Always empty.  A localnet port is realized on every chassis that has
            connectivity to the corresponding physical network.
          </dd>

          <dt>localport</dt>
          <dd>
            Always empty.  A localport port is present on every chassis.
          </dd>

          <dt>l3gateway</dt>
          <dd>
            The physical location of the L3 gateway.  To successfully identify a
            chassis, this column must be a <ref table="Chassis"/> record.  This is
            populated by <code>ovn-controller</code> based on the value of
            the <code>options:l3gateway-chassis</code> column in this table.
          </dd>

          <dt>l2gateway</dt>
          <dd>
            The physical location of this L2 gateway.  To successfully identify a
            chassis, this column must be a <ref table="Chassis"/> record.
            This is populated by <code>ovn-controller</code> based on the value
            of the <code>options:l2gateway-chassis</code> column in this table.
          </dd>
        </dl>

      </column>

      <column name="additional_chassis">
        The meaning of this column is the same as for the
        <ref column="chassis"/>. The column is used to track an additional
        physical location of the logical port. Used with regular (empty
        <ref column="type"/>) port bindings.
      </column>

      <column name="gateway_chassis">
        <p>
          A list of <ref table="Gateway_Chassis"/>.
        </p>
        <p>
          This should only be populated for ports with
          <ref column="type"/> set to <code>chassisredirect</code>.
          This column defines the list of chassis used as gateways where
          traffic will be redirected through.
        </p>
      </column>

      <column name="ha_chassis_group">
        <p>
          This should only be populated for ports with
          <ref column="type"/> set to <code>chassisredirect</code>.
          This column defines the HA chassis group with a list of
          HA chassis used as gateways where traffic will be redirected
          through.
        </p>
      </column>

      <column name="up">
        <p>
          This is set to <code>true</code> whenever all OVS flows
          required by this Port_Binding have been installed.  This is
          populated by <code>ovn-controller</code>.
        </p>
      </column>

      <column name="tunnel_key">
        <p>
          A number that represents the logical port in the key (e.g. STT key or
          Geneve TLV) field carried within tunnel protocol packets.
        </p>

        <p>
          The tunnel ID must be unique within the scope of a logical datapath.
        </p>
      </column>

      <column name="mac">
        This column is a misnomer as it may contain MAC addresses and IP
        addresses. It is copied from the <code>addresses</code> column in the
        <code>Logical_Switch_Port</code> table in the Northbound database. It
        follows the same format as that column.
      </column>

      <column name="port_security">
        <p>
          This column controls the addresses from which the host attached to
          the logical port (``the host'') is allowed to send packets and to
          which it is allowed to receive packets.  If this column is empty,
          all addresses are permitted.
        </p>

        <p>
          It is copied from the <code>port_security</code> column in the
          <code>Logical_Switch_Port</code> table in the Northbound database. It
          follows the same format as that column.
        </p>
      </column>

      <column name="type">
        <p>
          A type for this logical port.  Logical ports can be used to model other
          types of connectivity into an OVN logical switch.  The following types
          are defined:
        </p>

        <dl>
          <dt>(empty string)</dt>
          <dd>VM (or VIF) interface.</dd>

          <dt><code>patch</code></dt>
          <dd>
            One of a pair of logical ports that act as if connected by a patch
            cable.  Useful for connecting two logical datapaths, e.g. to connect
            a logical router to a logical switch or to another logical router.
          </dd>

          <dt><code>l3gateway</code></dt>
          <dd>
            One of a pair of logical ports that act as if connected by a patch
            cable across multiple chassis.  Useful for connecting a logical
            switch with a Gateway router (which is only resident on a
            particular chassis).
          </dd>

          <dt><code>localnet</code></dt>
          <dd>
            A connection to a locally accessible network from
            <code>ovn-controller</code> instances that have a corresponding
            bridge mapping.  A logical switch can have multiple
            <code>localnet</code> ports attached.  This type is used to model
            direct connectivity to existing networks.  In this case, each
            chassis should have a mapping for one of the physical networks
            only.  Note: nothing said above implies that a chassis cannot be
            plugged to multiple physical networks as long as they belong to
            different switches.
          </dd>

          <dt><code>localport</code></dt>
          <dd>
            A connection to a local VIF. Traffic that arrives on a
            <code>localport</code> is never forwarded over a tunnel to another
            chassis. These ports are present on every chassis and have the same
            address in all of them. This is used to model connectivity to local
            services that run on every hypervisor.
          </dd>

          <dt><code>l2gateway</code></dt>
          <dd>
            An L2 connection to a physical network.  The chassis this
            <ref table="Port_Binding"/> is bound to will serve as
            an L2 gateway to the network named by
            <ref column="options" table="Port_Binding"/>:<code>network_name</code>.
          </dd>

          <dt><code>vtep</code></dt>
          <dd>
            A port to a logical switch on a VTEP gateway chassis.  In order to
            get this port correctly recognized by the OVN controller, the <ref
            column="options"
            table="Port_Binding"/>:<code>vtep-physical-switch</code> and <ref
            column="options"
            table="Port_Binding"/>:<code>vtep-logical-switch</code> must also
            be defined.
          </dd>

          <dt><code>chassisredirect</code></dt>
          <dd>
            A logical port that represents a particular instance, bound
            to a specific chassis, of an otherwise distributed parent
            port (e.g. of type <code>patch</code>).  A
            <code>chassisredirect</code> port should never be used as an
            <code>inport</code>.  When an ingress pipeline sets the
            <code>outport</code>, it may set the value to a logical port
            of type <code>chassisredirect</code>.  This will cause the
            packet to be directed to a specific chassis to carry out the
            egress pipeline.  At the beginning of the egress pipeline,
            the <code>outport</code> will be reset to the value of the
            distributed port.
          </dd>

          <dt><code>virtual</code></dt>
          <dd>
            Represents a logical port with an <code>virtual ip</code>.
            This <code>virtual ip</code> can be configured on a
            logical port (which is referred as virtual parent).
          </dd>
        </dl>
      </column>
      <column name="requested_chassis">
        This column exists so that the ovn-controller can effectively monitor
        all <ref table="Port_Binding"/> records destined for it, and is a
        supplement to the <ref
        table="Port_Binding"
        column="options"
        key="requested-chassis"/> option.  The option is still required so that
        the ovn-controller can check the CMS intent when the chassis pointed
        to does not currently exist, which for example occurs when the
        ovn-controller is stopped without passing the --restart argument.

        This column must be a
        <ref table="Chassis"/> record.  This is populated by
        <code>ovn-northd</code> when the <ref
        table="Logical_Switch_Port"
        column="options"
        key="requested-chassis"
        db="OVN_Northbound"/>
        is defined and contains a string matching the name or hostname of an
        existing chassis.

        See also
        <ref table="Port_Binding" column="requested_additional_chassis"/>.
      </column>
      <column name="requested_additional_chassis">
        This column exists so that the ovn-controller can effectively monitor
        all <ref table="Port_Binding"/> records destined for it, and is a
        supplement to the <ref
        table="Port_Binding"
        column="options"
        key="requested-chassis"/> option when multiple chassis are listed.

        This column must be a list of
        <ref table="Chassis"/> records.  This is populated by
        <code>ovn-northd</code> when the <ref
        table="Logical_Switch_Port"
        column="options"
        key="requested-chassis"
        db="OVN_Northbound"/>
        is defined as a list of chassis names or hostnames.

        See also <ref table="Port_Binding" column="requested_chassis"/>.
      </column>
    </group>

    <column name="mirror_rules">
        Mirror rules that apply to the port binding.
        Please see the <ref table="Mirror"/> table.
    </column>

    <group title="Patch Options">
      <p>
        These options apply to logical ports with <ref column="type"/> of
        <code>patch</code>.
      </p>

      <column name="options" key="peer">
        The <ref column="logical_port"/> in the <ref table="Port_Binding"/>
        record for the other side of the patch.  The named <ref
        column="logical_port"/> must specify this <ref column="logical_port"/>
        in its own <code>peer</code> option.  That is, the two patch logical
        ports must have reversed <ref column="logical_port"/> and
        <code>peer</code> values.
      </column>

      <column name="nat_addresses">
        MAC address followed by a list of SNAT and DNAT external IP
        addresses, followed by
        <code>is_chassis_resident("<var>lport</var>")</code>, where
        <var>lport</var> is the name of a logical port on the same chassis
        where the corresponding NAT rules are applied.  This is used to
        send gratuitous ARPs for SNAT and DNAT external IP addresses via
        <code>localnet</code>, from the chassis where <var>lport</var>
        resides.  Example: <code>80:fa:5b:06:72:b7 158.36.44.22
        158.36.44.24 is_chassis_resident("foo1")</code>.  This would result
        in generation of gratuitous ARPs for IP addresses 158.36.44.22 and
        158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7 from the chassis
        where the logical port "foo1" resides.
      </column>
    </group>

    <group title="L3 Gateway Options">
      <p>
        These options apply to logical ports with <ref column="type"/> of
        <code>l3gateway</code>.
      </p>

      <column name="options" key="peer">
        The <ref column="logical_port"/> in the <ref table="Port_Binding"/>
        record for the other side of the 'l3gateway' port.  The named <ref
        column="logical_port"/> must specify this <ref column="logical_port"/>
        in its own <code>peer</code> option.  That is, the two 'l3gateway'
        logical ports must have reversed <ref column="logical_port"/> and
        <code>peer</code> values.
      </column>

      <column name="options" key="l3gateway-chassis">
        The <code>chassis</code> in which the port resides.
      </column>

      <column name="nat_addresses">
        MAC address of the <code>l3gateway</code> port followed by a list of
        SNAT and DNAT external IP addresses.  This is used to send gratuitous
        ARPs for SNAT and DNAT external IP addresses via <code>localnet</code>.
        Example: <code>80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24</code>.
        This would result in generation of gratuitous ARPs for IP addresses
        158.36.44.22 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7.
        This is used in OVS version 2.8 and later versions.
      </column>
    </group>

    <group title="Localnet Options">
      <p>
        These options apply to logical ports with <ref column="type"/> of
        <code>localnet</code>.
      </p>

      <column name="options" key="network_name">
        Required.  <code>ovn-controller</code> uses the configuration entry
        <code>ovn-bridge-mappings</code> to determine how to connect to this
        network.  <code>ovn-bridge-mappings</code> is a list of network names
        mapped to a local OVS bridge that provides access to that network.  An
        example of configuring <code>ovn-bridge-mappings</code> would be:

        <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1</pre>

        <p>
          When a logical switch has a <code>localnet</code> port attached,
          every chassis that may have a local vif attached to that logical
          switch must have a bridge mapping configured to reach that
          <code>localnet</code>.  Traffic that arrives on a
          <code>localnet</code> port is never forwarded over a tunnel to
          another chassis.  If there are multiple <code>localnet</code>
          ports in a logical switch, each chassis should only have a single
          bridge mapping for one of the physical networks.  Note: In case of
          multiple <code>localnet</code> ports, to provide interconnectivity
          between all VIFs located on different chassis with different fabric
          connectivity, the fabric should implement some form of routing
          between the segments.
        </p>
      </column>

      <column name="tag">
        If set, indicates that the port represents a connection to a specific
        VLAN on a locally accessible network. The VLAN ID is used to match
        incoming traffic and is also added to outgoing traffic.
      </column>
    </group>

    <group title="L2 Gateway Options">
      <p>
        These options apply to logical ports with <ref column="type"/> of
        <code>l2gateway</code>.
      </p>

      <column name="options" key="network_name">
        Required.  <code>ovn-controller</code> uses the configuration entry
        <code>ovn-bridge-mappings</code> to determine how to connect to this
        network.  <code>ovn-bridge-mappings</code> is a list of network names
        mapped to a local OVS bridge that provides access to that network.  An
        example of configuring <code>ovn-bridge-mappings</code> would be:

        <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1</pre>

        <p>
          When a logical switch has a <code>l2gateway</code> port attached,
          the chassis that the <code>l2gateway</code> port is bound to
          must have a bridge mapping configured to reach the network
          identified by <code>network_name</code>.
        </p>
      </column>

      <column name="options" key="l2gateway-chassis">
        Required. The <code>chassis</code> in which the port resides.
      </column>

      <column name="tag">
        If set, indicates that the gateway is connected to a specific
        VLAN on the physical network. The VLAN ID is used to match
        incoming traffic and is also added to outgoing traffic.
      </column>
    </group>

    <group title="VTEP Options">
      <p>
        These options apply to logical ports with <ref column="type"/> of
        <code>vtep</code>.
      </p>

      <column name="options" key="vtep-physical-switch">
        Required. The name of the VTEP gateway.
      </column>

      <column name="options" key="vtep-logical-switch">
        Required.  A logical switch name connected by the VTEP gateway.  Must
        be set when <ref column="type"/> is <code>vtep</code>.
      </column>
    </group>

    <group title="VMI (or VIF) Options">
      <p>
        These options apply to logical ports with <ref column="type"/> having
        (empty string)
      </p>

      <column name="options" key="requested-chassis">
        <p>
          If set, identifies a specific chassis (by name or hostname) that
          is allowed to bind this port. Using this option will prevent
          thrashing between two chassis trying to bind the same port during
          a live migration. It can also prevent similar thrashing due to a
          mis-configuration, if a port is accidentally created on more than
          one chassis.
        </p>

        <p>
          If set to a comma separated list, the first entry identifies the main
          chassis and the rest are one or more additional chassis that are
          allowed to bind the same port.
        </p>

        <p>
          When multiple chassis are set for the port, and the logical switch
          is connected to an external network through a <code>localnet</code>
          port, tunneling is enforced for the port to guarantee delivery of
          packets directed to the port to all its locations. This has MTU
          implications because the network used for tunneling must have MTU
          larger than <code>localnet</code> for stable connectivity.
        </p>
      </column>

      <column name="options" key="activation-strategy">
        If used with multiple chassis set in <ref column="requested-chassis"/>,
        specifies an activation strategy for all additional chassis. By
        default, no activation strategy is used, meaning additional port
        locations are immediately available for use. When set to "rarp", the
        port is blocked for ingress and egress communication until a RARP
        packet is sent from a new location. The "rarp" strategy is useful
        in live migration scenarios for virtual machines.
      </column>

      <column name="options" key="additional-chassis-activated">
        When <ref column="activation-strategy"/> is set, this option indicates
        that the port was activated using the strategy specified.
      </column>

      <column name="options" key="iface-id-ver">
        If set, this port will be bound by <code>ovn-controller</code>
        only if this same key and value is configured in the
        <ref table="Interface" column="external_ids" db="Open_vSwitch"/>
        column in the Open_vSwitch database's
        <ref table="Interface" db="Open_vSwitch"/> table.
      </column>

      <column name="options" key="qos_min_rate">
        If set, indicates the minimum guaranteed rate available for data sent
        from this interface, in bit/s.
      </column>

      <column name="options" key="qos_max_rate">
        If set, indicates the maximum rate for data sent from this interface,
        in bit/s. The traffic will be shaped according to this limit.
      </column>

      <column name="options" key="qos_burst">
        If set, indicates the maximum burst size for data sent from this
        interface, in bits.
      </column>

      <column name="options" key="qos_physical_network">
        If set, indicates the name of the egress network name where traffic
        shaping will be applied.
      </column>

      <column name="options" key="qdisc_queue_id"
              type='{"type": "integer", "minInteger": 1, "maxInteger": 61440}'>
        Indicates the queue number on the physical device. This is same as the
        <code>queue_id</code> used in OpenFlow in <code>struct
        ofp_action_enqueue</code>.
      </column>
    </group>

    <group title="Distributed Gateway Port Options">
      <p>
        These options apply to the distributed parent ports of logical ports
        with <ref column="type"/> of <code>chasssisredirect</code>.
      </p>

      <column name="options" key="chassis-redirect-port">
        The name of the chassis redirect port derived from this port if this
        port is a distributed parent of a chassis redirect port.
      </column>
    </group>

    <group title="Chassis Redirect Options">
      <p>
        These options apply to logical ports with <ref column="type"/>
        of <code>chassisredirect</code>.
      </p>

      <column name="options" key="distributed-port">
        The name of the distributed port for which this
        <code>chassisredirect</code> port represents a particular instance.
      </column>

      <column name="options" key="redirect-type">
        The value is copied from the column
        <ref table="Logical_Router_Port" column="options" db="OVN_Northbound"/>
        in the OVN_Northbound database's
        <ref table="Logical_Router_Port" db="OVN_Northbound"/> table for the
        distributed parent of this port.
      </column>

      <column name="options" key="always-redirect">
        A boolean option that is set to true if the distributed parent of this
        chassis redirect port does not need distributed processing.
      </column>
    </group>

    <group title="Nested Containers">
      <p>
        These columns support containers nested within a VM.  Specifically,
        they are used when <ref column="type"/> is empty and <ref
        column="logical_port"/> identifies the interface of a container spawned
        inside a VM.  They are empty for containers or VMs that run directly on
        a hypervisor.
      </p>

      <column name="parent_port">
        This is taken from
        <ref table="Logical_Switch_Port" column="parent_name"
        db="OVN_Northbound"/> in the OVN_Northbound database's
        <ref table="Logical_Switch_Port" db="OVN_Northbound"/> table.
      </column>

      <column name="tag">
        <p>
          Identifies the VLAN tag in the network traffic associated with that
          container's network interface.
        </p>

        <p>
          This column is used for a different purpose when <ref column="type"/>
          is <code>localnet</code> (see <code>Localnet Options</code>, above)
          or <code>l2gateway</code> (see <code>L2 Gateway Options</code>, above).
        </p>
      </column>
    </group>

    <group title="Virtual ports">
      <column name="virtual_parent">
        <p>
          This column is set by <code>ovn-controller</code> with one of the
          value from the
          <ref table="Logical_Switch_Port" column="options:virtual-parents"
          db="OVN_Northbound"/> in the OVN_Northbound database's
          <ref table="Logical_Switch_Port" db="OVN_Northbound"/> table
          when the OVN action <code>bind_vport</code> is executed.
          <code>ovn-controller</code> also sets the
          <ref column="chassis"/> column when it executes this action
          with its chassis id.
        </p>

        <p>
          <code>ovn-controller</code> sets this column only if the
          <ref column="type"/> is "virtual".
        </p>
      </column>
    </group>

    <group title="Naming">
      <column name="external_ids" key="name">
        <p>
          For a logical switch port, <code>ovn-northd</code> copies this from
          <ref table="Logical_Switch_Port" db="OVN_Northbound"
          column="external_ids" key="neutron:port_name"/> in the <ref
          table="Logical_Switch_Port" db="OVN_Northbound"/> table in the
          OVN_Northbound database, if it is a nonempty string.
        </p>

        <p>
          For a logical switch port, <code>ovn-northd</code> does not currently
          set this key.
        </p>
      </column>
    </group>

    <group title="Common Columns">
      <column name="external_ids">
        <p>
          See <em>External IDs</em> at the beginning of this document.
        </p>

        <p>
          The <code>ovn-northd</code> program populates this column with
          all entries into the <ref column="external_ids"/> column of the
          <ref table="Logical_Switch_Port"/> and
          <ref table="Logical_Router_Port"/> tables of the
          <ref db="OVN_Northbound"/> database.
        </p>
      </column>
    </group>
  </table>

  <table name="MAC_Binding" title="IP to MAC bindings">
    <p>
      Each row in this table specifies a binding from an IP address to an
      Ethernet address that has been discovered through ARP (for IPv4) or
      neighbor discovery (for IPv6).  This table is primarily used to discover
      bindings on physical networks, because IP-to-MAC bindings for virtual
      machines are usually populated statically into the <ref
      table="Port_Binding"/> table.
    </p>

    <p>
      This table expresses a functional relationship: <ref
      table="MAC_Binding"/>(<ref column="logical_port"/>, <ref column="ip"/>) =
      <ref column="mac"/>.
    </p>

    <p>
      In outline, the lifetime of a logical router's MAC binding looks like
      this:
    </p>

    <ol>
      <li>
        On hypervisor 1, a logical router determines that a packet should be
        forwarded to IP address <var>A</var> on one of its router ports.  It
        uses its logical flow table to determine that <var>A</var> lacks a
        static IP-to-MAC binding and the <code>get_arp</code> action to
        determine that it lacks a dynamic IP-to-MAC binding.
      </li>

      <li>
        Using an OVN logical <code>arp</code> action, the logical router
        generates and sends a broadcast ARP request to the router port.  It
        drops the IP packet.
      </li>

      <li>
        The logical switch attached to the router port delivers the ARP request
        to all of its ports.  (It might make sense to deliver it only to ports
        that have no static IP-to-MAC bindings, but this could also be
        surprising behavior.)
      </li>

      <li>
        A host or VM on hypervisor 2 (which might be the same as hypervisor 1)
        attached to the logical switch owns the IP address in question.  It
        composes an ARP reply and unicasts it to the logical router port's
        Ethernet address.
      </li>

      <li>
        The logical switch delivers the ARP reply to the logical router port.
      </li>

      <li>
        The logical router flow table executes a <code>put_arp</code> action.
        To record the IP-to-MAC binding, <code>ovn-controller</code> adds a row
        to the <ref table="MAC_Binding"/> table.
      </li>

      <li>
        On hypervisor 1, <code>ovn-controller</code> receives the updated <ref
        table="MAC_Binding"/> table from the OVN southbound database.  The next
        packet destined to <var>A</var> through the logical router is sent
        directly to the bound Ethernet address.
      </li>
    </ol>

    <column name="logical_port">
      The logical port on which the binding was discovered.
    </column>

    <column name="ip">
      The bound IP address.
    </column>

    <column name="mac">
      The Ethernet address to which the IP is bound.
    </column>

    <column name="timestamp">
      The timestamp in msec when the MAC binding was added or updated.
      Records that existed before this column will have 0.
    </column>

    <column name="datapath">
      The logical datapath to which the logical port belongs.
    </column>
  </table>

  <table name="DHCP_Options" title="DHCP Options supported by native OVN DHCP">
    <p>
      Each row in this table stores the DHCP Options supported by native OVN
      DHCP. <code>ovn-northd</code> populates this table with the supported
      DHCP options. <code>ovn-controller</code> looks up this table to get the
      DHCP codes of the DHCP options defined in the "put_dhcp_opts" action.
      Please refer to the RFC 2132 <code>"https://tools.ietf.org/html/rfc2132"</code>
      for the possible list of DHCP options that can be defined here.
    </p>

    <column name="name">
      <p>
        Name of the DHCP option.
      </p>

      <p>
        Example. name="router"
      </p>
    </column>

    <column name="code">
      <p>
        DHCP option code for the DHCP option as defined in the RFC 2132.
      </p>

      <p>
        Example. code=3
      </p>
    </column>

    <column name="type">
      <p>
        Data type of the DHCP option code.
      </p>

      <dl>
        <dt><code>value: bool</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is a bool.
          </p>

          <p>
            Example. "name=ip_forward_enable", "code=19", "type=bool".
          </p>

          <p>
            put_dhcp_opts(..., ip_forward_enable = 1,...)
          </p>
        </dd>

        <dt><code>value: uint8</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is an unsigned
            int8 (8 bits)
          </p>

          <p>
            Example. "name=default_ttl", "code=23", "type=uint8".
          </p>

          <p>
            put_dhcp_opts(..., default_ttl = 50,...)
          </p>
        </dd>

        <dt><code>value: uint16</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is an unsigned
            int16 (16 bits).
          </p>

          <p>
            Example. "name=mtu", "code=26", "type=uint16".
          </p>

          <p>
            put_dhcp_opts(..., mtu = 1450,...)
          </p>
        </dd>

        <dt><code>value: uint32</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is an unsigned
            int32 (32 bits).
          </p>

          <p>
            Example. "name=lease_time", "code=51", "type=uint32".
          </p>

          <p>
            put_dhcp_opts(..., lease_time = 86400,...)
          </p>
        </dd>

        <dt><code>value: ipv4</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is an IPv4
            address or addresses.
          </p>

          <p>
            Example. "name=router", "code=3", "type=ipv4".
          </p>

          <p>
            put_dhcp_opts(..., router = 10.0.0.1,...)
          </p>

          <p>
            Example. "name=dns_server", "code=6", "type=ipv4".
          </p>

          <p>
            put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
          </p>
        </dd>

        <dt><code>value: static_routes</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option contains a pair of
            IPv4 route and next hop addresses.
          </p>

          <p>
            Example. "name=classless_static_route", "code=121", "type=static_routes".
          </p>

          <p>
            put_dhcp_opts(..., classless_static_route = {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
          </p>
        </dd>

        <dt><code>value: str</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is a string.
          </p>

          <p>
            Example. "name=host_name", "code=12", "type=str".
          </p>
        </dd>

        <dt><code>value: host_id</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is a host_id.
            It can either be a host_name or an IP address.
          </p>

          <p>
            Example. "name=tftp_server", "code=66", "type=host_id".
          </p>
        </dd>

        <dt><code>value: domains</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCP option is a domain name
            or a comma separated list of domain names.
          </p>

          <p>
            Example. "name=domain_search_list", "code=119", "type=domains".
          </p>
        </dd>
      </dl>
    </column>
  </table>

  <table name="DHCPv6_Options" title="DHCPv6 Options supported by native OVN DHCPv6">
    <p>
      Each row in this table stores the DHCPv6 Options supported by native OVN
      DHCPv6. <code>ovn-northd</code> populates this table with the supported
      DHCPv6 options. <code>ovn-controller</code> looks up this table to get
      the DHCPv6 codes of the DHCPv6 options defined in the
      <code>put_dhcpv6_opts</code> action. Please refer to RFC 3315 and RFC
      3646 for the list of DHCPv6 options that can be defined here.
    </p>

    <column name="name">
      <p>
        Name of the DHCPv6 option.
      </p>

      <p>
        Example. name="ia_addr"
      </p>
    </column>

    <column name="code">
      <p>
        DHCPv6 option code for the DHCPv6 option as defined in the appropriate
        RFC.
      </p>

      <p>
        Example. code=3
      </p>
    </column>

    <column name="type">
      <p>
        Data type of the DHCPv6 option code.
      </p>

      <dl>
        <dt><code>value: ipv6</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCPv6 option is an IPv6
            address(es).
          </p>

          <p>
            Example. "name=ia_addr", "code=5", "type=ipv6".
          </p>

          <p>
            put_dhcpv6_opts(..., ia_addr = ae70::4,...)
          </p>
        </dd>

        <dt><code>value: str</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCPv6 option is a string.
          </p>

          <p>
            Example. "name=domain_search", "code=24", "type=str".
          </p>

          <p>
            put_dhcpv6_opts(..., domain_search = ovn.domain,...)
          </p>
        </dd>

        <dt><code>value: mac</code></dt>
        <dd>
          <p>
            This indicates that the value of the DHCPv6 option is a MAC address.
          </p>

          <p>
            Example. "name=server_id", "code=2", "type=mac".
          </p>

          <p>
            put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
          </p>
        </dd>
      </dl>
    </column>
  </table>
  <table name="Connection" title="OVSDB client connections.">
    <p>
      Configuration for a database connection to an Open vSwitch database
      (OVSDB) client.
    </p>

    <p>
      This table primarily configures the Open vSwitch database server
      (<code>ovsdb-server</code>).
    </p>

    <p>
      The Open vSwitch database server can initiate and maintain active
      connections to remote clients.  It can also listen for database
      connections.
    </p>

    <group title="Core Features">
      <column name="target">
        <p>Connection methods for clients.</p>
        <p>
          The following connection methods are currently supported:
        </p>
        <dl>
          <dt><code>ssl:<var>host</var></code>[<code>:<var>port</var></code>]</dt>
          <dd>
            <p>
              The specified SSL <var>port</var> on the given <var>host</var>,
              which can either be a DNS name (if built with unbound library) or
              an IP address.  A valid SSL configuration must be provided when
              this form is used, this configuration can be specified via
              command-line options or the <ref table="SSL"/> table.
            </p>
            <p>
              If <var>port</var> is not specified, it defaults to 6640.
            </p>
            <p>
              SSL support is an optional feature that is not always
              built as part of Open vSwitch.
            </p>
          </dd>

          <dt><code>tcp:<var>host</var></code>[<code>:<var>port</var></code>]</dt>
          <dd>
            <p>
              The specified TCP <var>port</var> on the given <var>host</var>,
              which can either be a DNS name (if built with unbound library) or
              an IP address (IPv4 or IPv6).  If <var>host</var> is an IPv6
              address, wrap it in square brackets, e.g. <code>tcp:[::1]:6640</code>.
            </p>
            <p>
              If <var>port</var> is not specified, it defaults to 6640.
            </p>
          </dd>
          <dt><code>pssl:</code>[<var>port</var>][<code>:<var>host</var></code>]</dt>
          <dd>
            <p>
              Listens for SSL connections on the specified TCP <var>port</var>.
              Specify 0 for <var>port</var> to have the kernel automatically
              choose an available port.  If <var>host</var>, which can either
              be a DNS name (if built with unbound library) or an IP address,
              is specified, then connections are restricted to the resolved or
              specified local IP address (either IPv4 or IPv6 address).  If
              <var>host</var> is an IPv6 address, wrap in square brackets,
              e.g. <code>pssl:6640:[::1]</code>.  If <var>host</var> is not
              specified then it listens only on IPv4 (but not IPv6) addresses.
              A valid SSL configuration must be provided when this form is used,
              this can be specified either via command-line options or the
              <ref table="SSL"/> table.
            </p>
            <p>
              If <var>port</var> is not specified, it defaults to 6640.
            </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>host</var></code>]</dt>
          <dd>
            <p>
              Listens for connections on the specified TCP <var>port</var>.
              Specify 0 for <var>port</var> to have the kernel automatically
              choose an available port.  If <var>host</var>, which can either
              be a DNS name (if built with unbound library) or an IP address,
              is specified, then connections are restricted to the resolved or
              specified local IP address (either IPv4 or IPv6 address).  If
              <var>host</var> is an IPv6 address, wrap it in square brackets,
              e.g. <code>ptcp:6640:[::1]</code>.  If <var>host</var> is not
              specified then it listens only on IPv4 addresses.
            </p>
            <p>
              If <var>port</var> is not specified, it defaults to 6640.
            </p>
          </dd>
        </dl>
        <p>When multiple clients are configured, the <ref column="target"/>
        values must be unique.  Duplicate <ref column="target"/> values yield
        unspecified results.</p>
      </column>

      <column name="read_only">
        <code>true</code> to restrict these connections to read-only
        transactions, <code>false</code> to allow them to modify the database.
      </column>
      <column name="role">
        String containing role name for this connection entry.
      </column>
    </group>

    <group title="Client Failure Detection and Handling">
      <column name="max_backoff">
        Maximum number of milliseconds to wait between connection attempts.
        Default is implementation-specific.
      </column>

      <column name="inactivity_probe">
        Maximum number of milliseconds of idle time on connection to the client
        before sending an inactivity probe message.  If Open vSwitch does not
        communicate with the client for the specified number of seconds, it
        will send a probe.  If a response is not received for the same
        additional amount of time, Open vSwitch assumes the connection has been
        broken and attempts to reconnect.  Default is implementation-specific.
        A value of 0 disables inactivity probes.
      </column>
    </group>

    <group title="Status">
      <p>
        Key-value pair of <ref column="is_connected"/> is always updated.
        Other key-value pairs in the status columns may be updated depends
        on the <ref column="target"/> type.
      </p>

      <p>
        When <ref column="target"/> specifies a connection method that
        listens for inbound connections (e.g. <code>ptcp:</code> or
        <code>punix:</code>), both <ref column="n_connections"/> and
        <ref column="is_connected"/> may also be updated while the
        remaining key-value pairs are omitted.
      </p>

      <p>
        On the other hand, when <ref column="target"/> specifies an
        outbound connection, all key-value pairs may be updated, except
        the above-mentioned two key-value pairs associated with inbound
        connection targets. They are omitted.
      </p>

      <column name="is_connected">
        <code>true</code> if currently connected to this client,
        <code>false</code> otherwise.
      </column>

      <column name="status" key="last_error">
        A human-readable description of the last error on the connection
        to the manager; i.e. <code>strerror(errno)</code>.  This key
        will exist only if an error has occurred.
      </column>

      <column name="status" key="state"
              type='{"type": "string", "enum": ["set", ["VOID", "BACKOFF", "CONNECTING", "ACTIVE", "IDLE"]]}'>
        <p>
          The state of the connection to the manager:
        </p>
        <dl>
          <dt><code>VOID</code></dt>
          <dd>Connection is disabled.</dd>

          <dt><code>BACKOFF</code></dt>
          <dd>Attempting to reconnect at an increasing period.</dd>

          <dt><code>CONNECTING</code></dt>
          <dd>Attempting to connect.</dd>

          <dt><code>ACTIVE</code></dt>
          <dd>Connected, remote host responsive.</dd>

          <dt><code>IDLE</code></dt>
          <dd>Connection is idle.  Waiting for response to keep-alive.</dd>
        </dl>
        <p>
          These values may change in the future.  They are provided only for
          human consumption.
        </p>
      </column>

      <column name="status" key="sec_since_connect"
              type='{"type": "integer", "minInteger": 0}'>
        The amount of time since this client last successfully connected
        to the database (in seconds). Value is empty if client has never
        successfully been connected.
      </column>

      <column name="status" key="sec_since_disconnect"
              type='{"type": "integer", "minInteger": 0}'>
        The amount of time since this client last disconnected from the
        database (in seconds). Value is empty if client has never
        disconnected.
      </column>

      <column name="status" key="locks_held">
        Space-separated list of the names of OVSDB locks that the connection
        holds.  Omitted if the connection does not hold any locks.
      </column>

      <column name="status" key="locks_waiting">
        Space-separated list of the names of OVSDB locks that the connection is
        currently waiting to acquire.  Omitted if the connection is not waiting
        for any locks.
      </column>

      <column name="status" key="locks_lost">
        Space-separated list of the names of OVSDB locks that the connection
        has had stolen by another OVSDB client.  Omitted if no locks have been
        stolen from this connection.
      </column>

      <column name="status" key="n_connections"
              type='{"type": "integer", "minInteger": 2}'>
        When <ref column="target"/> specifies a connection method that
        listens for inbound connections (e.g. <code>ptcp:</code> or
        <code>pssl:</code>) and more than one connection is actually active,
        the value is the number of active connections.  Otherwise, this
        key-value pair is omitted.
      </column>

      <column name="status" key="bound_port" type='{"type": "integer"}'>
        When <ref column="target"/> is <code>ptcp:</code> or
        <code>pssl:</code>, this is the TCP port on which the OVSDB server is
        listening.  (This is particularly useful when <ref
        column="target"/> specifies a port of 0, allowing the kernel to
        choose any available port.)
      </column>
    </group>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
      <column name="other_config"/>
    </group>
  </table>
  <table name="SSL">
    SSL configuration for ovn-sb database access.

    <column name="private_key">
      Name of a PEM file containing the private key used as the switch's
      identity for SSL connections to the controller.
    </column>

    <column name="certificate">
      Name of a PEM file containing a certificate, signed by the
      certificate authority (CA) used by the controller and manager,
      that certifies the switch's private key, identifying a trustworthy
      switch.
    </column>

    <column name="ca_cert">
      Name of a PEM file containing the CA certificate used to verify
      that the switch is connected to a trustworthy controller.
    </column>

    <column name="bootstrap_ca_cert">
      If set to <code>true</code>, then Open vSwitch will attempt to
      obtain the CA certificate from the controller on its first SSL
      connection and save it to the named PEM file. If it is successful,
      it will immediately drop the connection and reconnect, and from then
      on all SSL connections must be authenticated by a certificate signed
      by the CA certificate thus obtained.  <em>This option exposes the
      SSL connection to a man-in-the-middle attack obtaining the initial
      CA certificate.</em>  It may still be useful for bootstrapping.
    </column>

    <column name="ssl_protocols">
      List of SSL protocols to be enabled for SSL connections. The default
      when this option is omitted is <code>TLSv1,TLSv1.1,TLSv1.2</code>.
    </column>

    <column name="ssl_ciphers">
      List of ciphers (in OpenSSL cipher string format) to be supported
      for SSL connections. The default when this option is omitted is
      <code>HIGH:!aNULL:!MD5</code>.
    </column>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
    </group>
  </table>
  <table name="DNS" title="Native DNS resolution">
    <p>
      Each row in this table stores the DNS records. The OVN action
      <code>dns_lookup</code> uses this table for DNS resolution.
    </p>

    <column name="records">
      Key-value pair of DNS records with <code>DNS query name</code> as the key
      and a string of IP address(es) separated by comma or space as the
      value. ovn-northd stores the DNS query name in all lowercase in order to
      facilitate case-insensitive lookups.

      <p><b>Example: </b> "vm1.ovn.org" = "10.0.0.4 aef0::4"</p>
    </column>

    <column name="datapaths">
      The DNS records defined in the column <ref column="records"/> will be
      applied only to the DNS queries originating from the datapaths defined
      in this column.
    </column>

    <group title="Common Columns">
      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>
    </group>
  </table>

  <table name="RBAC_Role">
    Role table for role-based access controls.

    <column name="name">
        The role name, corresponding to the <code>role</code>
        column in the <code>Connection</code> table.
    </column>

    <column name="permissions">
        A mapping of table names to rows in the
        <code>RBAC_Permission</code> table.
    </column>
  </table>
  <table name="RBAC_Permission">
    Permissions table for role-based access controls.

    <column name="table">
      Name of table to which this row applies.
    </column>

    <column name="authorization">
        Set of strings identifying columns and column:key pairs to be compared
        with client ID. At least one match is required in order to be
        authorized.  A zero-length string is treated as a special value
        indicating all clients should be considered authorized.
    </column>

    <column name="insert_delete">
        When "true", row insertions and authorized row
        deletions are permitted.
    </column>
    <column name="update">
        Set of strings identifying columns and column:key pairs that authorized
        clients are allowed to modify.
    </column>
  </table>
  <table name="Gateway_Chassis">
    <p>
      Association of <ref table="Port_Binding"/> rows of
      <ref table="Port_Binding" column="type"/> <code>chassisredirect</code> to
      a <ref table="Chassis"/>. The traffic going out through a specific
      <code>chassisredirect</code> port will be redirected to a chassis,
      or a set of them in high availability configurations.
    </p>

    <column name="name">
      <p>
        Name of the <ref table="Gateway_Chassis"/>.
      </p>
      <p>
        A suggested, but not required naming convention is
        <code>${port_name}_${chassis_name}</code>.
      </p>
    </column>

    <column name="chassis">
      The <ref table="Chassis"/> to which we send the traffic.
    </column>

    <column name="priority">
      This is the priority the specific <ref table="Chassis"/> among all
      Gateway_Chassis belonging to the same <ref table="Port_Binding"/>.
    </column>

    <column name="options">
      Reserved for future use.
    </column>

    <group title="Common Columns">
      The overall purpose of these columns is described under <code>Common
      Columns</code> at the beginning of this document.

      <column name="external_ids"/>
    </group>
  </table>

  <table name="HA_Chassis">
    <column name="chassis">
      <p>
        The <ref table="Chassis"/> which provides the HA functionality.
        </p>
    </column>

    <column name="priority">
      <p>
        Priority of the HA chassis. Chassis with highest priority will be
        the master in the HA chassis group.
      </p>
    </column>

    <group title="Common Columns">
      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>
    </group>
  </table>

  <table name="HA_Chassis_Group">
    <p>
      Table representing a group of chassis which can provide High availability
      services. Each chassis in the group is represented by the table
      <ref table="HA_Chassis"/>. The HA chassis with highest priority will
      be the master of this group. If the master chassis failover is detected,
      the HA chassis with the next higher priority takes over the
      responsibility of providing the HA. If <ref db="OVN_Southbound"
      table="Port_Binding" column="ha_chassis_group"/> column of the table
      <ref db="OVN_Southbound" table="Port_Binding"/> references this table,
      then this HA chassis group provides the gateway functionality and
      redirects the gateway traffic to the master of this group.
    </p>
    <column name="name">
      Name of the <ref table="HA_Chassis_Group"/>. Name should be unique.
    </column>

    <column name="ha_chassis">
      A list of <ref table="HA_Chassis"/> which belongs to this group.
    </column>

    <column name="ref_chassis">
      The set of <ref table="Chassis"/> that reference this HA chassis group.
      To determine the correct <ref table="Chassis"/>, find the
      <code>chassisredirect</code> type <ref table="Port_Binding"/> that
      references this <ref table="HA_Chassis_Group"/>.  This <ref
      table="Port_Binding"/> is derived from some particular logical router.
      Starting from that LR, find the set of all logical switches and routers
      connected to it, directly or indirectly, across router ports that link
      one LRP to another or to a LSP.  For each LSP in these logical switches,
      find the corresponding <ref table="Port_Binding"/> and add its bound <ref
      table="Chassis"/> (if any) to <ref column="ref_chassis"/>.
    </column>

    <group title="Common Columns">
      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>
    </group>
  </table>
  <table name="Controller_Event" title="Controller Event table">
    <p>
      Database table used by <code>ovn-controller</code> to report CMS
      related events. Please note there is no guarantee a given event is
      written exactly once in the db. It is CMS responsibility to squash
      duplicated lines or to filter out duplicated events
    </p>
    <column name="event_type">
      Event type occurred
    </column>
    <column name="event_info">
    <p>
      Key-value pairs used to specify event info to the CMS.
      Possible values are:
    </p>
      <ul>
        <li>
         <code>vip</code>: VIP reported for the <code>empty_lb_backends</code>
         event
        </li>
        <li>
          <code>protocol</code>: Transport protocol reported for the
          <code>empty_lb_backends</code> event
        </li>
        <li>
          <code>load_balancer</code>: UUID of the load balancer reported for
          the <code>empty_lb_backends</code> event
        </li>
      </ul>
    </column>
    <column name="chassis">
      This column is a <ref table="Chassis"/> record to identify the chassis
      that has managed a given event.
    </column>
    <column name="seq_num">
      Event sequence number. Global counter for controller generated events.
      It can be used by the CMS to detect possible duplication of the same
      event.
    </column>
  </table>
  <table name="IP_Multicast">
    <p>
      IP Multicast configuration options. For now only applicable to IGMP.
    </p>

    <column name="datapath">
      <ref table="Datapath_Binding"/> entry for which these configuration
      options are defined.
    </column>
    <column name="enabled">
      Enables/disables multicast snooping. Default: disabled.
    </column>
    <column name="querier">
      Enables/disables multicast querying. If
      <ref table="IP_Multicast" column="enabled"/> then multicast querying is
      enabled by default.
    </column>
    <column name="table_size">
      Limits the number of multicast groups that can be learned. Default:
      2048 groups per datapath.
    </column>
    <column name="idle_timeout">
      Configures the idle timeout (in seconds) for IP multicast groups if
      multicast snooping is enabled. Default: 300 seconds.
    </column>
    <column name="query_interval">
      Configures the interval (in seconds) for sending multicast queries if
      snooping and querier are enabled.
      Default: <ref table="IP_Multicast" column="idle_timeout"/>/2 seconds.
    </column>
    <column name="seq_no">
      <code>ovn-controller</code> reads this value and flushes all learned
      multicast groups when it detects that <code>seq_no</code> was changed.
    </column>

    <group title="Querier configuration options">
      The <code>ovn-controller</code> process that runs on OVN hypervisor
      nodes uses the following columns to determine field values in IGMP/MLD
      queries that it originates:
      <column name="eth_src">
        Source Ethernet address.
      </column>
      <column name="ip4_src">
        Source IPv4 address.
      </column>
      <column name="ip6_src">
        Source IPv6 address.
      </column>
      <column name="query_max_resp">
        Value (in seconds) to be used as "max-response" field in multicast
        queries. Default: 1 second.
      </column>
    </group>
  </table>
  <table name="IGMP_Group">
    <p>
      Contains learned IGMP groups indexed by address/datapath/chassis.
    </p>

    <column name="address">
      Destination IPv4 address for the IGMP group.
    </column>

    <column name="datapath">
      Datapath to which this IGMP group belongs.
    </column>

    <column name="chassis">
      Chassis to which this IGMP group belongs.
    </column>

    <column name="ports">
      The destination port bindings for this IGMP group.
    </column>
  </table>

  <table name="Service_Monitor">
    <p>
      Each row in this table configures monitoring a service for its liveness.
      The service can be an IPv4 TCP or UDP
      service. <code>ovn-controller</code> periodically sends out service
      monitor packets and updates the status of the service. Service monitoring
      for IPv6 services is not supported.
    </p>

    <p>
      <code>ovn-northd</code> uses this feature to implement the load balancer
      health check feature offered to the CMS through the northbound database.
    </p>

    <group title="Configuration">
      <p>
        <code>ovn-northd</code> sets these columns and values to configure the
        service monitor.
      </p>

      <column name="ip">
        IP of the service to be monitored. Only IPv4 is supported.
      </column>

      <column name="protocol">
        The protocol of the service.
      </column>

      <column name="port">
        The TCP or UDP port of the service.
      </column>

      <column name="logical_port">
        The VIF of the logical port on which the service is running. The
        <code>ovn-controller</code> that binds this <code>logical_port</code>
        monitors the service by sending periodic monitor packets.
      </column>

      <column name="src_mac">
        Source Ethernet address to use in the service monitor packet.
      </column>

      <column name="src_ip">
        Source IPv4 address to use in the service monitor packet.
      </column>

      <column name="options" key="interval" type='{"type": "integer"}'>
        The interval, in seconds, between service monitor checks.
      </column>

      <column name="options" key="timeout" type='{"type": "integer"}'>
        The time, in seconds, after which the service monitor check times
        out.
      </column>

      <column name="options" key="success_count" type='{"type": "integer"}'>
        The number of successful checks after which the service is
        considered <code>online</code>.
      </column>

      <column name="options" key="failure_count" type='{"type": "integer"}'>
        The number of failure checks after which the service is considered
        <code>offline</code>.
      </column>
    </group>

    <group title="Status Reporting">
      <p>
        The <code>ovn-controller</code> on the chassis that hosts the <ref
        column="logical_port"/> updates this column to report the service's
        status.
      </p>
      
      <column name="status">
        <p>
          For TCP service, <code>ovn-controller</code> sends a SYN to the
          service and expects an ACK response to consider the service to be
          <code>online</code>.
        </p>

        <p>
          For UDP service, <code>ovn-controller</code> sends a UDP packet to
          the service and doesn't expect any reply.  If it receives an ICMP
          reply, then it considers the service to be <code>offline</code>.
        </p>
      </column>
    </group>

    <group title="Common Columns">
      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>
    </group>
  </table>

  <table name="Load_Balancer">
    <p>
      Each row represents a load balancer.
    </p>

    <column name="name">
      A name for the load balancer.  This name has no special meaning or
      purpose other than to provide convenience for human interaction with
      the ovn-nb database.
    </column>

    <column name="vips">
      A map of virtual IP addresses (and an optional port number with
      <code>:</code> as a separator) associated with this load balancer and
      their corresponding endpoint IP addresses (and optional port numbers
      with <code>:</code> as separators) separated by commas.
    </column>

    <column name="protocol">
      <p>
        Valid protocols are <code>tcp</code>, <code>udp</code>, or
        <code>sctp</code>.  This column is useful when a port number is
        provided as part of the <code>vips</code> column.  If this column is
        empty and a port number is provided as part of <code>vips</code>
        column, OVN assumes the protocol to be <code>tcp</code>.
      </p>
    </column>

    <column name="datapaths">
      Datapaths to which this load balancer applies to.
    </column>

    <column name="datapath_group">
      The group of datapaths to which this load balancer applies to.  This
      means that the same load balancer applies to all datapaths in a group.
    </column>

    <group title="Load_Balancer options">
    <column name="options" key="hairpin_snat_ip">
      IP to be used as source IP for packets that have been hair-pinned after
      load balancing.  This value is automatically populated by
      <code>ovn-northd</code>.
    </column>
    <column name="options" key="hairpin_orig_tuple" type='{"type": "boolean"}'>
      This value is automatically set to <code>true</code> by
      <code>ovn-northd</code> when original destination IP and transport port
      of the load balanced packets are stored in registers
      <code>reg1, reg2, xxreg1</code>.
    </column>
    </group>

    <group title="Common Columns">
      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>
    </group>
  </table>

  <table name="BFD">
    <p>
      Contains BFD parameter for ovn-controller bfd configuration.
    </p>

    <group title="Configuration">
      <column name="src_port">
        udp source port used in bfd control packets.
        The source port MUST be in the range 49152 through 65535
        (RFC5881 section 4).
      </column>

      <column name="disc">
        A unique, nonzero discriminator value generated by the transmitting
        system, used to demultiplex multiple BFD sessions between the same pair
        of systems.
      </column>

      <column name="logical_port">
        OVN logical port when BFD engine is running.
      </column>

      <column name="dst_ip">
        BFD peer IP address.
      </column>

      <column name="min_tx">
        This is the minimum interval, in milliseconds, that the local
        system would like to use when transmitting BFD Control packets,
        less any jitter applied. The value zero is reserved.
      </column>

      <column name="min_rx">
        This is the minimum interval, in milliseconds, between received
        BFD Control packets that this system is capable of supporting,
        less any jitter applied by the sender. If this value is zero,
        the transmitting system does not want the remote system to send
        any periodic BFD Control packets.
      </column>

      <column name="detect_mult">
        Detection time multiplier.  The negotiated transmit interval,
        multiplied by this value, provides the Detection Time for the
        receiving system in Asynchronous mode.
      </column>

      <column name="options">
        Reserved for future use.
      </column>

      <column name="external_ids">
        See <em>External IDs</em> at the beginning of this document.
      </column>
    </group>

    <group title="Status Reporting">
      <column name="status">
        <p>
          BFD port logical states. Possible values are:
          <ul>
            <li>
              <code>admin_down</code>
            </li>
            <li>
              <code>down</code>
            </li>
            <li>
              <code>init</code>
            </li>
            <li>
              <code>up</code>
            </li>
          </ul>
        </p>
      </column>
    </group>
  </table>

  <table name="FDB" title="Port to MAC bindings">
    <p>
      This table is primarily used to learn the MACs observed on a VIF
      (or a localnet port with 'localnet_learn_fdb' enabled)
      which belongs to a <code>Logical_Switch_Port</code> record in
      <code>OVN_Northbound</code> whose port security is disabled
      and 'unknown' address set.  If port security is disabled on a
      <code>Logical_Switch_Port</code> record, OVN should allow traffic
      with any source mac from the VIF.  This table will be used to deliver
      a packet to the VIF, If a packet's <code>eth.dst</code> is learnt.
    </p>

    <column name="mac">
      The learnt mac address.
    </column>

    <column name="dp_key">
      The key of the datapath on which this FDB was learnt.
    </column>

    <column name="port_key">
      The key of the port binding on which this FDB was learnt.
    </column>

    <column name="timestamp">
      The timestamp in msec when the FDB was added or updated.
      Records that existed before this column will have 0.
    </column>
  </table>

  <table name="Static_MAC_Binding" title="IP to MAC bindings">
    <p>
      Each record represents a Static_MAC_Binding entry for a logical router.
    </p>


    <column name="logical_port">
        The logical router port for the binding.
    </column>

    <column name="ip">
      The bound IP address.
    </column>

    <column name="mac">
      The Ethernet address to which the IP is bound.
    </column>

    <column name="override_dynamic_mac">
      Override dynamically learnt MACs.
    </column>

    <column name="datapath">
      The logical datapath to which the logical router port belongs.
    </column>
  </table>

  <table name="Chassis_Template_Var">
    <p>
      Each record represents the set of template variable instantiations
      for a given chassis and is populated by <code>ovn-northd</code>
      from the contents of the <code>OVN_Northbound.Chassis_Template_Var</code>
      table.
    </p>
    <column name="chassis">
      The chassis this set of variable values applies to.
    </column>
    <column name="variables">
      The set of variable values for a given chassis.
    </column>
  </table>
</database>