actions: Allow caller to specify output table.

[mirror_ovs.git] / ovn / 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>, and northbound to the Cloud Management
    System, via <code>ovn-northd</code>:
  </p>

  <h2>Database Structure</h2>

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

  <h3>Physical Network (PN) data</h3>

  <p>
    PN 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 PN 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="Gateway"/> tables comprise the
    PN tables.
  </p>

  <h3>Logical Network (LN) data</h3>

  <p>
    LN 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>
    LN 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.  Past
    experience shows that in the presence of large logical networks, even
    finer-grained partitioning of data, e.g. designing logical flows so that
    only the chassis hosting a logical port needs related flows, pays off
    scale-wise.  (This is not necessary initially but it is worth bearing in
    mind in the design.)
  </p>

  <p>
    The LN is a slave of the cloud management system running northbound of OVN.
    That CMS determines the entire OVN logical configuration and therefore the
    LN's content at any given time is a deterministic function of the CMS's
    configuration, although that happens indirectly via the OVN Northbound DB
    and <code>ovn-northd</code>.
  </p>

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

  <p>
    The <ref table="Logical_Flow"/> table is currently the only LN table.
  </p>

  <h3>Bindings data</h3>

  <p>
    The Binding tables contain the current placement of logical components
    (such as VMs and VIFs) onto chassis and the bindings between logical ports
    and MACs.
  </p>

  <p>
    Bindings 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"/> table is currently the only binding data.
  </p>

  <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 (PN).  Each chassis, via
      <code>ovn-controller</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">
      A chassis name, taken from <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 does
      not prescribe a particular format for chassis names.
    </column>

    <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 a
        logical network and a physical VLAN.  Gateways are typically dedicated
        nodes that do not host VMs.
      </p>

      <column name="gateway_ports">
        Maps from the name of a port attached to the OVN integration bridge
        (typically a physical port or an Open vSwitch patch port) to a <ref
        table="Gateway"/> record that describes the details of the gatewaying
        function.
      </column>
    </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), 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 must use either <code>geneve</code> or
      <code>stt</code>.  Gateways may use <code>vxlan</code>,
      <code>geneve</code>, or <code>stt</code>.
    </column>

    <column name="options">
      Options for configuring the encapsulation, e.g. IPsec parameters when
      IPsec support is introduced.  No options are currently defined.
    </column>

    <column name="ip">
      The IPv4 address of the encapsulation tunnel endpoint.
    </column>
  </table>

  <table name="Gateway" title="Physical Network Gateway Ports">
    <p>
      The <ref column="gateway_ports" table="Chassis"/> column in the <ref
      table="Chassis"/> table refers to rows in this table to connect a chassis
      port to a gateway function.  Each row in this table describes the logical
      networks to which a gateway port is attached.  Each chassis, via
      <code>ovn-controller</code>(8), adds and updates its own rows, if any
      (since most chassis are not gateways), and keeps a copy of the remaining
      rows to determine how to reach other chassis.
    </p>

    <column name="vlan_map">
      Maps from a VLAN ID to a logical port name.  Thus, each named logical
      port corresponds to one VLAN on the gateway port.
    </column>
  </table>

  <table name="Logical_Flow" title="Logical Network Flow">
    <p>
      Each row in this table represents one logical flow.  The cloud management
      system, via its OVN integration, populates this table with logical flows
      that implement the L2 and L3 topology specified in the CMS configuration.
      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 CMS to do less work, since
      it does 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>

    <column name="logical_datapath">
      The logical datapath to which the logical flow belongs.  A logical
      datapath implements a logical pipeline among the ports in the <ref
      table="Port_Binding"/> table associated with it.  (No table represents a
      logical datapath.)  In practice, the pipeline in a given logical datapath
      implements either a logical switch or a logical router, and
      <code>ovn-northd</code> reuses the UUIDs for those logical entities from
      the <code>OVN_Northbound</code> for logical datapaths.
    </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><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 nominal 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).  String constants are used for naming
        logical ports.  Thus, the useful values are <ref
        column="logical_port"/> names from the <ref column="Port_Binding"/> and
        <ref column="Gateway"/> tables in a logical flow's <ref
        column="logical_datapath"/>.
      </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><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>

      <ul>
        <li>
          <code>metadata</code> <code>reg0</code> ... <code>reg7</code>
          <code>xreg0</code> ... <code>xreg3</code>
        </li>
        <li><code>inport</code> <code>outport</code> <code>queue</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>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>
      </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 will be initially supported:
      </p>

      <dl>
        <dt><code>output;</code></dt>
        <dd>
          Outputs the packet to the logical port current designated by
          <code>outport</code>.  Output to the ingress port is implicitly
          dropped, that is, <code>output</code> becomes a no-op if
          <code>outport</code> == <code>inport</code>.
        </dd>

        <dt><code>next;</code></dt>
        <dd>
          Executes the next logical datapath table as a subroutine.
        </dd>

        <dt><code><var>field</var> = <var>constant</var>;</code></dt>
        <dd>
          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.  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.  To set only a subset of bits in a field,
          <var>field</var> may be a subfield or <var>constant</var> may be
          masked, e.g. <code>vlan.pcp[2] = 1;</code> and <code>vlan.pcp =
          4/4;</code> both set the most sigificant bit of the VLAN PCP.  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).
        </dd>
      </dl>

      <p>
        The following actions will likely be useful later, but they have not
        been thought out carefully.
      </p>

      <dl>
        <dt><code><var>field1</var> = <var>field2</var>;</code></dt>
        <dd>
          Extends the assignment action to allow copying between fields.
        </dd>

        <dt><code>learn</code></dt>

        <dt><code>conntrack</code></dt>

        <dt><code>dec_ttl { <var>action</var>, </code>...<code> } { <var>action</var>; </code>...<code>};</code></dt>
        <dd>
          decrement TTL; execute first set of actions if
          successful, second set if TTL decrement fails
        </dd>

        <dt><code>icmp_reply { <var>action</var>, </code>...<code> };</code></dt>
        <dd>generate ICMP reply from packet, execute <var>action</var>s</dd>

        <dt><code>arp { <var>action</var>, </code>...<code> }</code></dt>
        <dd>generate ARP from packet, execute <var>action</var>s</dd>
      </dl>
    </column>
  </table>

  <table name="Port_Binding" title="Physical-Logical Port Bindings">
    <p>
      Each row in this table identifies the physical location of a logical
      port.
    </p>

    <p>
      For every <code>Logical_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> column, which it leaves empty in new records.
    </p>

    <p>
      <code>ovn-controller</code> populates the <code>chassis</code> column
      for the records that identify the logical ports that are located on its
      hypervisor, which <code>ovn-controller</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.md</code>.
    </p>

    <p>
      When a chassis shuts down gracefully, it should cleanup 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> must overwrite the
      <code>chassis</code> column with new information.
    </p>

    <column name="logical_datapath">
      The logical datapath to which the logical port belongs.  A logical
      datapath implements a logical pipeline via logical flows in the <ref
      table="Logical_Flow"/> table.  (No table represents a logical datapath.)
    </column>

    <column name="logical_port">
      A logical port, taken from <ref table="Logical_Port" column="name"
      db="OVN_Northbound"/> in the OVN_Northbound database's
      <ref table="Logical_Port" db="OVN_Northbound"/> table.  OVN does not
      prescribe a particular format for the logical port ID.
    </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.  Leaving this column
      blank maintains the default logical port behavior.
      </p>

      <p>
      There are no other logical port types implemented yet.
      </p>
    </column>

    <column name="options">
        This column provides key/value settings specific to the logical port
        <ref column="type"/>.
    </column>

    <column name="tunnel_key">
      <p>
        A number that represents the logical port in the key (e.g. VXLAN VNI or
        STT key) field carried within tunnel protocol packets.  (This avoids
        wasting space for a whole UUID in tunneled packets.  It also allows OVN
        to support encapsulations that cannot fit an entire UUID in their
        tunnel keys.)
      </p>

      <p>
        Tunnel ID 0 is reserved for internal use within OVN.
      </p>
    </column>

    <column name="parent_port">
      For containers created inside a VM, this is taken from
      <ref table="Logical_Port" column="parent_name" db="OVN_Northbound"/>
      in the OVN_Northbound database's <ref table="Logical_Port"
      db="OVN_Northbound"/> table.  It is left empty if
      <ref column="logical_port"/> belongs to a VM or a container created
      in the hypervisor.
    </column>

    <column name="tag">
      When <ref column="logical_port"/> identifies the interface of a container
      spawned inside a VM, this column identifies the VLAN tag in
      the network traffic associated with that container's network interface.
      It is left empty if <ref column="logical_port"/> belongs to a VM or a
      container created in the hypervisor.
    </column>

    <column name="chassis">
      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>.
    </column>

    <column name="mac">
      <p>
        The Ethernet address or addresses used as a source address on the
        logical port, each in the form
        <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
        The string <code>unknown</code> is also allowed to indicate that the
        logical port has an unknown set of (additional) source addresses.
      </p>

      <p>
        A VM interface would ordinarily have a single Ethernet address.  A
        gateway port might initially only have <code>unknown</code>, and then
        add MAC addresses to the set as it learns new source addresses.
      </p>
    </column>
  </table>
</database>