ovs-fields(7) — Linux manual page

NAME | INTRODUCTION | FIELDS REFERENCE | CONJUNCTIVE MATCH FIELDS | TUNNEL FIELDS | METADATA FIELDS | CONNECTION TRACKING FIELDS | REGISTER FIELDS | LAYER 2 (ETHERNET) FIELDS | VLAN FIELDS | LAYER 2.5: MPLS FIELDS | LAYER 3: IPV4 AND IPV6 FIELDS | LAYER 3: ARP FIELDS | LAYER 3: NSH FIELDS | LAYER 4: TCP, UDP, AND SCTP FIELDS | LAYER 4: ICMPV4 AND ICMPV6 FIELDS | REFERENCES | AUTHORS | COLOPHON

ovs-fields(7)              Open vSwitch Manual             ovs-fields(7)

NAME         top

       ovs-fields - protocol header fields in OpenFlow and Open vSwitch

INTRODUCTION         top

       This document aims to comprehensively document all of the fields,
       both standard and non-standard, supported by OpenFlow or Open
       vSwitch, regardless of origin.

   Fields
       A field is a property of a packet. Most familiarly, data fields
       are fields that can be extracted from a packet. Most data fields
       are copied directly from protocol headers, e.g. at layer 2, the
       Ethernet source and destination addresses, or the VLAN ID; at
       layer 3, the IPv4 or IPv6 source and destination; and at layer 4,
       the TCP or UDP ports. Other data fields are computed, e.g.
       ip_frag describes whether a packet is a fragment but it is not
       copied directly from the IP header.

       Data fields that are always present as a consequence of the basic
       networking technology in use are called called root fields. Open
       vSwitch 2.7 and earlier considered Ethernet fields to be root
       fields, and this remains the default mode of operation for Open
       vSwitch bridges. When a packet is received from a non-Ethernet
       interfaces, such as a layer-3 LISP tunnel, Open vSwitch 2.7 and
       earlier force-fit the packet to this Ethernet-centric point of
       view by pretending that an Ethernet header is present whose
       Ethernet type that indicates the packet’s actual type (and whose
       source and destination addresses are all-zero).

       Open vSwitch 2.8 and later implement the ``packet type-aware
       pipeline’’ concept introduced in OpenFlow 1.5. Such a pipeline
       does not have any root fields. Instead, a new metadata field,
       packet_type, indicates the basic type of the packet, which can be
       Ethernet, IPv4, IPv6, or another type. For backward
       compatibility, by default Open vSwitch 2.8 imitates the behavior
       of Open vSwitch 2.7 and earlier. Later versions of Open vSwitch
       may change the default, and in the meantime controllers can turn
       off this legacy behavior, on a port-by-port basis, by setting
       options:packet_type to ptap in the Interface table. This is
       significant only for ports that can handle non-Ethernet packets,
       which is currently just LISP, VXLAN-GPE, and GRE tunnel ports.
       See ovs-vwitchd.conf.db(5) for more information.

       Non-root data fields are not always present. A packet contains
       ARP fields, for example, only when its packet type is ARP or when
       it is an Ethernet packet whose Ethernet header indicates the
       Ethertype for ARP, 0x0806. In this documentation, we say that a
       field is applicable when it is present in a packet, and
       inapplicable when it is not. (These are not standard terms.) We
       refer to the conditions that determine whether a field is
       applicable as prerequisites. Some VLAN-related fields are a
       special case: these fields are always applicable for Ethernet
       packets, but have a designated value or bit that indicates
       whether a VLAN header is present, with the remaining values or
       bits indicating the VLAN header’s content (if it is present).

       An inapplicable field does not have a value, not even a nominal
       ``value’’ such as all-zero-bits. In many circumstances, OpenFlow
       and Open vSwitch allow references only to applicable fields. For
       example, one may match (see Matching, below) a given field only
       if the match includes the field’s prerequisite, e.g. matching an
       ARP field is only allowed if one also matches on Ethertype 0x0806
       or the packet_type for ARP in a packet type-aware bridge.

       Sometimes a packet may contain multiple instances of a header.
       For example, a packet may contain multiple VLAN or MPLS headers,
       and tunnels can cause any data field to recur. OpenFlow and Open
       vSwitch do not address these cases uniformly. For VLAN and MPLS
       headers, only the outermost header is accessible, so that inner
       headers may be accessed only by ``popping’’ (removing) the outer
       header. (Open vSwitch supports only a single VLAN header in any
       case.) For tunnels, e.g. GRE or VXLAN, the outer header and inner
       headers are treated as different data fields.

       Many network protocols are built in layers as a stack of
       concatenated headers. Each header typically contains a ``next
       type’’ field that indicates the type of the protocol header that
       follows, e.g. Ethernet contains an Ethertype and IPv4 contains a
       IP protocol type. The exceptional cases, where protocols are
       layered but an outer layer does not indicate the protocol type
       for the inner layer, or gives only an ambiguous indication, are
       troublesome. An MPLS header, for example, only indicates whether
       another MPLS header or some other protocol follows, and in the
       latter case the inner protocol must be known from the context. In
       these exceptional cases, OpenFlow and Open vSwitch cannot provide
       insight into the inner protocol data fields without additional
       context, and thus they treat all later data fields as
       inapplicable until an OpenFlow action explicitly specifies what
       protocol follows. In the case of MPLS, the OpenFlow ``pop MPLS’’
       action that removes the last MPLS header from a packet provides
       this context, as the Ethertype of the payload. See Layer 2.5:
       MPLS for more information.

       OpenFlow and Open vSwitch support some fields other than data
       fields. Metadata fields relate to the origin or treatment of a
       packet, but they are not extracted from the packet data itself.
       One example is the physical port on which a packet arrived at the
       switch. Register fields act like variables: they give an OpenFlow
       switch space for temporary storage while processing a packet.
       Existing metadata and register fields have no prerequisites.

       A field’s value consists of an integral number of bytes. For data
       fields, sometimes those bytes are taken directly from the packet.
       Other data fields are copied from a packet with padding (usually
       with zeros and in the most significant positions). The remaining
       data fields are transformed in other ways as they are copied from
       the packets, to make them more useful for matching.

   Matching
       The most important use of fields in OpenFlow is matching, to
       determine whether particular field values agree with a set of
       constraints called a match. A match consists of zero or more
       constraints on individual fields, all of which must be met to
       satisfy the match. (A match that contains no constraints is
       always satisfied.) OpenFlow and Open vSwitch support a number of
       forms of matching on individual fields:

              Exact match, e.g. nw_src=10.1.2.3
                     Only a particular value of the field is matched;
                     for example, only one particular source IP address.
                     Exact matches are written as field=value. The forms
                     accepted for value depend on the field.

                     All fields support exact matches.

              Bitwise match, e.g. nw_src=10.1.0.0/255.255.0.0
                     Specific bits in the field must have specified
                     values; for example, only source IP addresses in a
                     particular subnet. Bitwise matches are written as
                     field=value/mask, where value and mask take one of
                     the forms accepted for an exact match on field.
                     Some fields accept other forms for bitwise matches;
                     for example, nw_src=10.1.0.0/255.255.0.0 may also
                     be written nw_src=10.1.0.0/16.

                     Most OpenFlow switches do not allow every bitwise
                     matching on every field (and before OpenFlow 1.2,
                     the protocol did not even provide for the
                     possibility for most fields). Even switches that do
                     allow bitwise matching on a given field may
                     restrict the masks that are allowed, e.g. by
                     allowing matches only on contiguous sets of bits
                     starting from the most significant bit, that is,
                     ``CIDR’’ masks [RFC 4632]. Open vSwitch does not
                     allows bitwise matching on every field, but it
                     allows arbitrary bitwise masks on any field that
                     does support bitwise matching. (Older versions had
                     some restrictions, as documented in the
                     descriptions of individual fields.)

              Wildcard, e.g. ``any nw_src’’
                     The value of the field is not constrained.
                     Wildcarded fields may be written as field=*,
                     although it is unusual to mention them at all.
                     (When specifying a wildcard explicitly in a command
                     invocation, be sure to using quoting to protect
                     against shell expansion.)

                     There is a tiny difference between wildcarding a
                     field and not specifying any match on a field:
                     wildcarding a field requires satisfying the field’s
                     prerequisites.

       Some types of matches on individual fields cannot be expressed
       directly with OpenFlow and Open vSwitch. These can be expressed
       indirectly:

              Set match, e.g. ``tcp_dst ∈ {80, 443, 8080}’’
                     The value of a field is one of a specified set of
                     values; for example, the TCP destination port is
                     80, 443, or 8080.

                     For matches used in flows (see Flows, below),
                     multiple flows can simulate set matches.

              Range match, e.g. ``1000 ≤ tcp_dst ≤ 1999’’
                     The value of the field must lie within a numerical
                     range, for example, TCP destination ports between
                     1000 and 1999.

                     Range matches can be expressed as a collection of
                     bitwise matches. For example, suppose that the goal
                     is to match TCP source ports 1000 to 1999,
                     inclusive. The binary representations of 1000 and
                     1999 are:

                     01111101000
                     11111001111

                     The following series of bitwise matches will match
                     1000 and 1999 and all the values in between:

                     01111101xxx
                     0111111xxxx
                     10xxxxxxxxx
                     110xxxxxxxx
                     1110xxxxxxx
                     11110xxxxxx
                     1111100xxxx

                     which can be written as the following matches:

                     tcp,tp_src=0x03e8/0xfff8
                     tcp,tp_src=0x03f0/0xfff0
                     tcp,tp_src=0x0400/0xfe00
                     tcp,tp_src=0x0600/0xff00
                     tcp,tp_src=0x0700/0xff80
                     tcp,tp_src=0x0780/0xffc0
                     tcp,tp_src=0x07c0/0xfff0

              Inequality match, e.g. ``tcp_dst ≠ 80’’
                     The value of the field differs from a specified
                     value, for example, all TCP destination ports
                     except 80.

                     An inequality match on an n-bit field can be
                     expressed as a disjunction of n 1-bit matches. For
                     example, the inequality match ``vlan_pcp ≠ 5’’ can
                     be expressed as ``vlan_pcp = 0/4 or vlan_pcp = 2/2
                     or vlan_pcp = 0/1.’’ For matches used in flows (see
                     Flows, below), sometimes one can more compactly
                     express inequality as a higher-priority flow that
                     matches the exceptional case paired with a lower-
                     priority flow that matches the general case.

                     Alternatively, an inequality match may be converted
                     to a pair of range matches, e.g. tcp_src ≠ 80 may
                     be expressed as ``0 ≤ tcp_src < 80 or 80 < tcp_src
                     ≤ 65535’’, and then each range match may in turn be
                     converted to a bitwise match.

              Conjunctive match, e.g. ``tcp_src ∈ {80, 443, 8080} and
              tcp_dst ∈ {80, 443, 8080}’’
                     As an OpenFlow extension, Open vSwitch supports
                     matching on conditions on conjunctions of the
                     previously mentioned forms of matching. See the
                     documentation for conj_id for more information.

       All of these supported forms of matching are special cases of
       bitwise matching. In some cases this influences the design of
       field values. ip_frag is the most prominent example: it is
       designed to make all of the practically useful checks for IP
       fragmentation possible as a single bitwise match.

     Shorthands

       Some matches are very commonly used, so Open vSwitch accepts
       shorthand notations. In some cases, Open vSwitch also uses
       shorthand notations when it displays matches. The following
       shorthands are defined, with their long forms shown on the right
       side:

              eth    packet_type=(0,0) (Open vSwitch 2.8 and later)

              ip     eth_type=0x0800

              ipv6   eth_type=0x86dd

              icmp   eth_type=0x0800,ip_proto=1

              icmp6  eth_type=0x86dd,ip_proto=58

              tcp    eth_type=0x0800,ip_proto=6

              tcp6   eth_type=0x86dd,ip_proto=6

              udp    eth_type=0x0800,ip_proto=17

              udp6   eth_type=0x86dd,ip_proto=17

              sctp   eth_type=0x0800,ip_proto=132

              sctp6  eth_type=0x86dd,ip_proto=132

              arp    eth_type=0x0806

              rarp   eth_type=0x8035

              mpls   eth_type=0x8847

              mplsm  eth_type=0x8848

   Evolution of OpenFlow Fields
       The discussion so far applies to all OpenFlow and Open vSwitch
       versions. This section starts to draw in specific information by
       explaining, in broad terms, the treatment of fields and matches
       in each OpenFlow version.

     OpenFlow 1.0

       OpenFlow 1.0 defined the OpenFlow protocol format of a match as a
       fixed-length data structure that could match on the following
       fields:

              •      Ingress port.

              •      Ethernet source and destination MAC.

              •      Ethertype (with a special value to match frames
                     that lack an Ethertype).

              •      VLAN ID and priority.

              •      IPv4 source, destination, protocol, and DSCP.

              •      TCP source and destination port.

              •      UDP source and destination port.

              •      ICMPv4 type and code.

              •      ARP IPv4 addresses (SPA and TPA) and opcode.

       Each supported field corresponded to some member of the data
       structure. Some members represented multiple fields, in the case
       of the TCP, UDP, ICMPv4, and ARP fields whose presence is
       mutually exclusive. This also meant that some members were poor
       fits for their fields: only the low 8 bits of the 16-bit ARP
       opcode could be represented, and the ICMPv4 type and code were
       padded with 8 bits of zeros to fit in the 16-bit members
       primarily meant for TCP and UDP ports. An additional bitmap
       member indicated, for each member, whether its field should be an
       ``exact’’ or ``wildcarded’’ match (see Matching), with additional
       support for CIDR prefix matching on the IPv4 source and
       destination fields.

       Simplicity was recognized early on as the main virtue of this
       approach. Obviously, any fixed-length data structure cannot
       support matching new protocols that do not fit. There was no
       room, for example, for matching IPv6 fields, which was not a
       priority at the time. Lack of room to support matching the
       Ethernet addresses inside ARP packets actually caused more of a
       design problem later, leading to an Open vSwitch extension action
       specialized for dropping ``spoofed’’ ARP packets in which the
       frame and ARP Ethernet source addressed differed. (This extension
       was never standardized. Open vSwitch dropped support for it a few
       releases after it added support for full ARP matching.)

       The design of the OpenFlow fixed-length matches also illustrates
       compromises, in both directions, between the strengths and
       weaknesses of software and hardware that have always influenced
       the design of OpenFlow. Support for matching ARP fields that do
       fit in the data structure was only added late in the design
       process (and remained optional in OpenFlow 1.0), for example,
       because common switch ASICs did not support matching these
       fields.

       The compromises in favor of software occurred for more
       complicated reasons. The OpenFlow designers did not know how to
       implement matching in software that was fast, dynamic, and
       general. (A way was later found [Srinivasan].) Thus, the
       designers sought to support dynamic, general matching that would
       be fast in realistic special cases, in particular when all of the
       matches were microflows, that is, matches that specify every
       field present in a packet, because such matches can be
       implemented as a single hash table lookup. Contemporary research
       supported the feasibility of this approach: the number of
       microflows in a campus network had been measured to peak at about
       10,000 [Casado, section 3.2]. (Calculations show that this can
       only be true in a lightly loaded network [Pepelnjak].)

       As a result, OpenFlow 1.0 required switches to treat microflow
       matches as the highest possible priority. This let software
       switches perform the microflow hash table lookup first. Only on
       failure to match a microflow did the switch need to fall back to
       checking the more general and presumed slower matches. Also, the
       OpenFlow 1.0 flow match was minimally flexible, with no support
       for general bitwise matching, partly on the basis that this
       seemed more likely amenable to relatively efficient software
       implementation. (CIDR masking for IPv4 addresses was added
       relatively late in the OpenFlow 1.0 design process.)

       Microflow matching was later discovered to aid some hardware
       implementations. The TCAM chips used for matching in hardware do
       not support priority in the same way as OpenFlow but instead tie
       priority to ordering [Pagiamtzis]. Thus, adding a new match with
       a priority between the priorities of existing matches can require
       reordering an arbitrary number of TCAM entries. On the other
       hand, when microflows are highest priority, they can be managed
       as a set-aside portion of the TCAM entries.

       The emphasis on matching microflows also led designers to
       carefully consider the bandwidth requirements between switch and
       controller: to maximize the number of microflow setups per
       second, one must minimize the size of each flow’s description.
       This favored the fixed-length format in use, because it expressed
       common TCP and UDP microflows in fewer bytes than more flexible
       ``type-length-value’’ (TLV) formats. (Early versions of OpenFlow
       also avoided TLVs in general to head off protocol fragmentation.)

       Inapplicable Fields

       OpenFlow 1.0 does not clearly specify how to treat inapplicable
       fields. The members for inapplicable fields are always present in
       the match data structure, as are the bits that indicate whether
       the fields are matched, and the ``correct’’ member and bit values
       for inapplicable fields is unclear. OpenFlow 1.0 implementations
       changed their behavior over time as priorities shifted. The early
       OpenFlow reference implementation, motivated to make every flow a
       microflow to enable hashing, treated inapplicable fields as exact
       matches on a value of 0. Initially, this behavior was implemented
       in the reference controller only.

       Later, the reference switch was also changed to actually force
       any wildcarded inapplicable fields into exact matches on 0. The
       latter behavior sometimes caused problems, because the modified
       flow was the one reported back to the controller later when it
       queried the flow table, and the modifications sometimes meant
       that the controller could not properly recognize the flow that it
       had added. In retrospect, perhaps this problem should have
       alerted the designers to a design error, but the ability to use a
       single hash table was held to be more important than almost every
       other consideration at the time.

       When more flexible match formats were introduced much later, they
       disallowed any mention of inapplicable fields as part of a match.
       This raised the question of how to translate between this new
       format and the OpenFlow 1.0 fixed format. It seemed somewhat
       inconsistent and backward to treat fields as exact-match in one
       format and forbid matching them in the other, so instead the
       treatment of inapplicable fields in the fixed-length format was
       changed from exact match on 0 to wildcarding. (A better
       classifier had by now eliminated software performance problems
       with wildcards.)

       The OpenFlow 1.0.1 errata (released only in 2012) added some
       additional explanation [OpenFlow 1.0.1, section 3.4], but it did
       not mandate specific behavior because of variation among
       implementations.

     OpenFlow 1.1

       The OpenFlow 1.1 protocol match format was designed as a
       type/length/value (TLV) format to allow for future flexibility.
       The specification standardized only a single type OFPMT_STANDARD
       (0) with a fixed-size payload, described here. The additional
       fields and bitwise masks in OpenFlow 1.1 cause this match
       structure to be over twice as large as in OpenFlow 1.0, 88 bytes
       versus 40.

       OpenFlow 1.1 added support for the following fields:

              •      SCTP source and destination port.

              •      MPLS label and traffic control (TC) fields.

              •      One 64-bit register (named ``metadata’’).

       OpenFlow 1.1 increased the width of the ingress port number field
       (and all other port numbers in the protocol) from 16 bits to 32
       bits.

       OpenFlow 1.1 increased matching flexibility by introducing
       arbitrary bitwise matching on Ethernet and IPv4 address fields
       and on the new ``metadata’’ register field. Switches were not
       required to support all possible masks [OpenFlow 1.1, section
       4.3].

       By a strict reading of the specification, OpenFlow 1.1 removed
       support for matching ICMPv4 type and code [OpenFlow 1.1, section
       A.2.3], but this is likely an editing error because ICMP matching
       is described elsewhere [OpenFlow 1.1, Table 3, Table 4, Figure
       4]. Open vSwitch does support ICMPv4 type and code matching with
       OpenFlow 1.1.

       OpenFlow 1.1 avoided the pitfalls of inapplicable fields that
       OpenFlow 1.0 encountered, by requiring the switch to ignore the
       specified field values [OpenFlow 1.1, section A.2.3]. It also
       implied that the switch should ignore the bits that indicate
       whether to match inapplicable fields.

       Physical Ingress Port

       OpenFlow 1.1 introduced a new pseudo-field, the physical ingress
       port. The physical ingress port is only a pseudo-field because it
       cannot be used for matching. It appears only one place in the
       protocol, in the ``packet-in’’ message that passes a packet
       received at the switch to an OpenFlow controller.

       A packet’s ingress port and physical ingress port are identical
       except for packets processed by a switch feature such as bonding
       or tunneling that makes a packet appear to arrive on a
       ``virtual’’ port associated with the bond or the tunnel. For such
       packets, the ingress port is the virtual port and the physical
       ingress port is, naturally, the physical port. Open vSwitch
       implements both bonding and tunneling, but its bonding
       implementation does not use virtual ports and its tunnels are
       typically not on the same OpenFlow switch as their physical
       ingress ports (which need not be part of any switch), so the
       ingress port and physical ingress port are always the same in
       Open vSwitch.

     OpenFlow 1.2

       OpenFlow 1.2 abandoned the fixed-length approach to matching. One
       reason was size, since adding support for IPv6 address matching
       (now seen as important), with bitwise masks, would have added 64
       bytes to the match length, increasing it from 88 bytes in
       OpenFlow 1.1 to over 150 bytes. Extensibility had also become
       important as controller writers increasingly wanted support for
       new fields without having to change messages throughout the
       OpenFlow protocol. The challenges of carefully defining fixed-
       length matches to avoid problems with inapplicable fields had
       also become clear over time.

       Therefore, OpenFlow 1.2 adopted a flow format using a flexible
       type-length-value (TLV) representation, in which each TLV
       expresses a match on one field. These TLVs were in turn
       encapsulated inside the outer TLV wrapper introduced in OpenFlow
       1.1 with the new identifier OFPMT_OXM (1). (This wrapper
       fulfilled its intended purpose of reducing the amount of churn in
       the protocol when changing match formats; some messages that
       included matches remained unchanged from OpenFlow 1.1 to 1.2 and
       later versions.)

       OpenFlow 1.2 added support for the following fields:

              •      ARP hardware addresses (SHA and THA).

              •      IPv4 ECN.

              •      IPv6 source and destination addresses, flow label,
                     DSCP, ECN, and protocol.

              •      TCP, UDP, and SCTP port numbers when encapsulated
                     inside IPv6.

              •      ICMPv6 type and code.

              •      ICMPv6 Neighbor Discovery target address and source
                     and target Ethernet addresses.

       The OpenFlow 1.2 format, called OXM (OpenFlow Extensible Match),
       was modeled closely on an extension to OpenFlow 1.0 introduced in
       Open vSwitch 1.1 called NXM (Nicira Extended Match). Each OXM or
       NXM TLV has the following format:

               type
        <---------------->
             16        7   1    8      length bytes
       +------------+-----+--+------+ +------------+
       |vendor/class|field|HM|length| |    body    |
       +------------+-----+--+------+ +------------+

       The most significant 16 bits of the NXM or OXM header, called
       vendor by NXM and class by OXM, identify an organization
       permitted to allocate identifiers for fields. NXM allocates only
       two vendors, 0x0000 for fields supported by OpenFlow 1.0 and
       0x0001 for fields implemented as an Open vSwitch extension. OXM
       assigns classes as follows:

              0x0000 (OFPXMC_NXM_0).
              0x0001 (OFPXMC_NXM_1).
                   Reserved for NXM compatibility.

              0x0002 to 0x7fff
                   Reserved for allocation to ONF members, but none yet
                   assigned.

              0x8000 (OFPXMC_OPENFLOW_BASIC)
                   Used for most standard OpenFlow fields.

              0x8001 (OFPXMC_PACKET_REGS)
                   Used for packet register fields in OpenFlow 1.5 and
                   later.

              0x8002 to 0xfffe
                   Reserved for the OpenFlow specification.

              0xffff (OFPXMC_EXPERIMENTER)
                   Experimental use.

       When class is 0xffff, the OXM header is extended to 64 bits by
       using the first 32 bits of the body as an experimenter field
       whose most significant byte is zero and whose remaining bytes are
       an Organizationally Unique Identifier (OUI) assigned by the IEEE
       [IEEE OUI], as shown below.

            type                 experimenter
        <---------->             <---------->
          16     7   1    8        8     24     (length - 4) bytes
       +------+-----+--+------+ +------+-----+ +------------------+
       |class |field|HM|length| | zero | OUI | |       body       |
       +------+-----+--+------+ +------+-----+ +------------------+
        0xffff                    0x00

       OpenFlow says that support for experimenter fields is optional.
       Open vSwitch 2.4 and later does support them, so that it can
       support the following experimenter classes:

              0x4f4e4600 (ONFOXM_ET)
                     Used by official Open Networking Foundation
                     extensions in OpenFlow 1.3 and later. e.g. [TCP
                     Flags Match Field Extension].

              0x005ad650 (NXOXM_NSH)
                     Used by Open vSwitch for NSH extensions, in the
                     absence of an official ONF-assigned class. (This
                     OUI is randomly generated.)

       Taken as a unit, class (or vendor), field, and experimenter (when
       present) uniquely identify a particular field.

       When hasmask (abbreviated HM above) is 0, the OXM is an exact
       match on an entire field. In this case, the body (excluding the
       experimenter field, if present) is a single value to be matched.

       When hasmask is 1, the OXM is a bitwise match. The body
       (excluding the experimenter field) consists of a value to match,
       followed by the bitwise mask to apply. A 1-bit in the mask
       indicates that the corresponding bit in the value should be
       matched and a 0-bit that it should be ignored. For example, for
       an IP address field, a value of 192.168.0.0 followed by a mask of
       255.255.0.0 would match addresses in the 196.168.0.0/16 subnet.

              •      Some fields might not support masking at all, and
                     some fields that do support masking might restrict
                     it to certain patterns. For example, fields that
                     have IP address values might be restricted to CIDR
                     masks. The descriptions of individual fields note
                     these restrictions.

              •      An OXM TLV with a mask that is all zeros is not
                     useful (although it is not forbidden), because it
                     is has the same effect as omitting the TLV
                     entirely.

              •      It is not meaningful to pair a 0-bit in an OXM mask
                     with a 1-bit in its value, and Open vSwitch rejects
                     such an OXM with the error OFPBMC_BAD_WILDCARDS, as
                     required by OpenFlow 1.3 and later.

       The length identifies the number of bytes in the body, including
       the 4-byte experimenter header, if it is present. Each OXM TLV
       has a fixed length; that is, given class, field, experimenter (if
       present), and hasmask, length is a constant. The length is
       included explicitly to allow software to minimally parse OXM TLVs
       of unknown types.

       OXM TLVs must be ordered so that a field’s prerequisites are
       satisfied before it is parsed. For example, an OXM TLV that
       matches on the IPv4 source address field is only allowed
       following an OXM TLV that matches on the Ethertype for IPv4.
       Similarly, an OXM TLV that matches on the TCP source port must
       follow a TLV that matches an Ethertype of IPv4 or IPv6 and one
       that matches an IP protocol of TCP (in that order). The order of
       OXM TLVs is not otherwise restricted; no canonical ordering is
       defined.

       A given field may be matched only once in a series of OXM TLVs.

     OpenFlow 1.3

       OpenFlow 1.3 showed OXM to be largely successful, by adding new
       fields without making any changes to how flow matches otherwise
       worked. It added OXMs for the following fields supported by Open
       vSwitch:

              •      Tunnel ID for ports associated with e.g. VXLAN or
                     keyed GRE.

              •      MPLS ``bottom of stack’’ (BOS) bit.

       OpenFlow 1.3 also added OXMs for the following fields not
       documented here and not yet implemented by Open vSwitch:

              •      IPv6 extension header handling.

              •      PBB I-SID.

     OpenFlow 1.4

       OpenFlow 1.4 added OXMs for the following fields not documented
       here and not yet implemented by Open vSwitch:

              •      PBB UCA.

     OpenFlow 1.5

       OpenFlow 1.5 added OXMs for the following fields supported by
       Open vSwitch:

              •      Packet type.

              •      TCP flags.

              •      Packet registers.

              •      The output port in the OpenFlow action set.

FIELDS REFERENCE         top

       The following sections document the fields that Open vSwitch
       supports. Each section provides introductory material on a group
       of related fields, followed by information on each individual
       field. In addition to field-specific information, each field
       begins with a table with entries for the following important
       properties:

              Name   The field’s name, used for parsing and formatting
                     the field, e.g. in ovs-ofctl commands. For
                     historical reasons, some fields have an additional
                     name that is accepted as an alternative in parsing.
                     This name, when there is one, is listed as well,
                     e.g. ``tun (aka tunnel_id).’’

              Width  The field’s width, always a multiple of 8 bits.
                     Some fields don’t use all of the bits, so this may
                     be accompanied by an explanation. For example,
                     OpenFlow embeds the 2-bit IP ECN field as as the
                     low bits in an 8-bit byte, and so its width is
                     expressed as ``8 bits (only the least-significant 2
                     bits may be nonzero).’’

              Format How a value for the field is formatted or parsed
                     by, e.g., ovs-ofctl. Some possibilities are
                     generic:

                     decimal
                            Formats as a decimal number. On input,
                            accepts decimal numbers or hexadecimal
                            numbers prefixed by 0x.

                     hexadecimal
                            Formats as a hexadecimal number prefixed by
                            0x. On input, accepts decimal numbers or
                            hexadecimal numbers prefixed by 0x. (The
                            default for parsing is not hexadecimal: only
                            a 0x prefix causes input to be treated as
                            hexadecimal.)

                     Ethernet
                            Formats and accepts the common Ethernet
                            address format xx:xx:xx:xx:xx:xx.

                     IPv4   Formats and accepts the dotted-quad format
                            a.b.c.d. For bitwise matches, formats and
                            accepts address/length CIDR notation in
                            addition to address/mask.

                     IPv6   Formats and accepts the common IPv6 address
                            formats, plus CIDR notation for bitwise
                            matches.

                     OpenFlow 1.0 port
                            Accepts 16-bit port numbers in decimal, plus
                            OpenFlow well-known port names (e.g.
                            IN_PORT) in uppercase or lowercase.

                     OpenFlow 1.1+ port
                            Same syntax as OpenFlow 1.0 ports but for
                            32-bit OpenFlow 1.1+ port number fields.

                     Other, field-specific formats are explained along
                     with their fields.

              Masking
                     For most fields, this says ``arbitrary bitwise
                     masks,’’ meaning that a flow may match any
                     combination of bits in the field. Some fields
                     instead say ``exact match only,’’ which means that
                     a flow that matches on this field must match on the
                     whole field instead of just certain bits. Either
                     way, this reports masking support for the latest
                     version of Open vSwitch using OXM or NXM (that is,
                     either OpenFlow 1.2+ or OpenFlow 1.0 plus Open
                     vSwitch NXM extensions). In particular, OpenFlow
                     1.0 (without NXM) and 1.1 don’t always support
                     masking even if Open vSwitch itself does; refer to
                     the OpenFlow 1.0 and OpenFlow 1.1 rows to learn
                     about masking with these protocol versions.

              Prerequisites
                     Requirements that must be met to match on this
                     field. For example, ip_src has IPv4 as a
                     prerequisite, meaning that a match must include
                     eth_type=0x0800 to match on the IPv4 source
                     address. The following prerequisites, with their
                     requirements, are currently in use:

                     none   (no requirements)

                     VLAN VID
                            vlan_tci=0x1000/0x1000 (i.e. a VLAN header
                            is present)

                     ARP    eth_type=0x0806 (ARP) or eth_type=0x8035
                            (RARP)

                     IPv4   eth_type=0x0800

                     IPv6   eth_type=0x86dd

                     IPv4/IPv6
                            IPv4 or IPv6

                     MPLS   eth_type=0x8847 or eth_type=0x8848

                     TCP    IPv4/IPv6 and ip_proto=6

                     UDP    IPv4/IPv6 and ip_proto=17

                     SCTP   IPv4/IPv6 and ip_proto=132

                     ICMPv4 IPv4 and ip_proto=1

                     ICMPv6 IPv6 and ip_proto=58

                     ND solicit
                            ICMPv6 and icmp_type=135 and icmp_code=0

                     ND advert
                            ICMPv6 and icmp_type=136 and icmp_code=0

                     ND     ND solicit or ND advert

                     The TCP, UDP, and SCTP prerequisites also have the
                     special requirement that nw_frag is not being used
                     to select ``later fragments.’’ This is because only
                     the first fragment of a fragmented IPv4 or IPv6
                     datagram contains the TCP or UDP header.

              Access Most fields are ``read/write,’’ which means that
                     common OpenFlow actions like set_field can modify
                     them. Fields that are ``read-only’’ cannot be
                     modified in these general-purpose ways, although
                     there may be other ways that actions can modify
                     them.

              OpenFlow 1.0
              OpenFlow 1.1
                   These rows report the level of support that OpenFlow
                   1.0 or OpenFlow 1.1, respectively, has for a field.
                   For OpenFlow 1.0, supported fields are reported as
                   either ``yes (exact match only)’’ for fields that do
                   not support any bitwise masking or ``yes (CIDR match
                   only)’’ for fields that support CIDR masking.
                   OpenFlow 1.1 supported fields report either ``yes
                   (exact match only)’’ or simply ``yes’’ for fields
                   that do support arbitrary masks. These OpenFlow
                   versions supported a fixed collection of fields that
                   cannot be extended, so many more fields are reported
                   as ``not supported.’’

              OXM
              NXM  These rows report the OXM and NXM code points that
                   correspond to a given field. Either or both may be
                   ``none.’’

                   A field that has only an OXM code point is usually
                   one that was standardized before it was added to Open
                   vSwitch. A field that has only an NXM code point is
                   usually one that is not yet standardized. When a
                   field has both OXM and NXM code points, it usually
                   indicates that it was introduced as an Open vSwitch
                   extension under the NXM code point, then later
                   standardized under the OXM code point. A field can
                   have more than one OXM code point if it was
                   standardized in OpenFlow 1.4 or later and
                   additionally introduced as an official ONF extension
                   for OpenFlow 1.3. (A field that has neither OXM nor
                   NXM code point is typically an obsolete field that is
                   supported in some other form using OXM or NXM.)

                   Each code point in these rows is described in the
                   form ``NAME (number) since OpenFlow spec and Open
                   vSwitch version,’’ e.g. ``OXM_OF_ETH_TYPE (5) since
                   OpenFlow 1.2 and Open vSwitch 1.7.’’ First, NAME,
                   which specifies a name for the code point, starts
                   with a prefix that designates a class and, in some
                   cases, a vendor, as listed in the following table:

                   Prefix           Vendor       Class
                   ───────────────  ───────────  ───────
                   NXM_OF           (none)       0x0000
                   NXM_NX           (none)       0x0001
                   ERICOXM_OF       (none)       0x1000
                   OXM_OF           (none)       0x8000
                   OXM_OF_PKT_REG   (none)       0x8001
                   NXOXM_ET         0x00002320   0xffff
                   NXOXM_NSH        0x005ad650   0xffff
                   ONFOXM_ET        0x4f4e4600   0xffff

                   For more information on OXM/NXM classes and vendors,
                   refer back to OpenFlow 1.2 under Evolution of
                   OpenFlow Fields. The number is the field number
                   within the class and vendor. The OpenFlow spec is the
                   version of OpenFlow that standardized the code point.
                   It is omitted for NXM code points because they are
                   nonstandard. The version is the version of Open
                   vSwitch that first supported the code point.

CONJUNCTIVE MATCH FIELDS         top

   Summary:
       Name      Bytes   Mask   RW?   Prereqs   NXM/OXM Support
       ────────  ──────  ─────  ────  ────────  ────────────────
       conj_id   4       no     no    none      OVS 2.4+

       An individual OpenFlow flow can match only a single value for
       each field. However, situations often arise where one wants to
       match one of a set of values within a field or fields. For
       matching a single field against a set, it is straightforward and
       efficient to add multiple flows to the flow table, one for each
       value in the set. For example, one might use the following flows
       to send packets with IP source address a, b, c, or d to the
       OpenFlow controller:

             ip,ip_src=a actions=controller
             ip,ip_src=b actions=controller
             ip,ip_src=c actions=controller
             ip,ip_src=d actions=controller

       Similarly, these flows send packets with IP destination address
       e, f, g, or h to the OpenFlow controller:

             ip,ip_dst=e actions=controller
             ip,ip_dst=f actions=controller
             ip,ip_dst=g actions=controller
             ip,ip_dst=h actions=controller

       Installing all of the above flows in a single flow table yields a
       disjunctive effect: a packet is sent to the controller if ip_src
       ∈ {a,b,c,d} or ip_dst ∈ {e,f,g,h} (or both). (Pedantically, if
       both of the above sets of flows are present in the flow table,
       they should have different priorities, because OpenFlow says that
       the results are undefined when two flows with same priority can
       both match a single packet.)

       Suppose, on the other hand, one wishes to match conjunctively,
       that is, to send a packet to the controller only if both ip_src ∈
       {a,b,c,d} and ip_dst ∈ {e,f,g,h}. This requires 4 × 4 = 16 flows,
       one for each possible pairing of ip_src and ip_dst. That is
       acceptable for our small example, but it does not gracefully
       extend to larger sets or greater numbers of dimensions.

       The conjunction action is a solution for conjunctive matches that
       is built into Open vSwitch. A conjunction action ties groups of
       individual OpenFlow flows into higher-level ``conjunctive
       flows’’. Each group corresponds to one dimension, and each flow
       within the group matches one possible value for the dimension. A
       packet that matches one flow from each group matches the
       conjunctive flow.

       To implement a conjunctive flow with conjunction, assign the
       conjunctive flow a 32-bit id, which must be unique within an
       OpenFlow table. Assign each of the n ≥ 2 dimensions a unique
       number from 1 to n; the ordering is unimportant. Add one flow to
       the OpenFlow flow table for each possible value of each dimension
       with conjunction(id, k/n) as the flow’s actions, where k is the
       number assigned to the flow’s dimension. Together, these flows
       specify the conjunctive flow’s match condition. When the
       conjunctive match condition is met, Open vSwitch looks up one
       more flow that specifies the conjunctive flow’s actions and
       receives its statistics. This flow is found by setting conj_id to
       the specified id and then again searching the flow table.

       The following flows provide an example. Whenever the IP source is
       one of the values in the flows that match on the IP source
       (dimension 1 of 2), and the IP destination is one of the values
       in the flows that match on IP destination (dimension 2 of 2),
       Open vSwitch searches for a flow that matches conj_id against the
       conjunction ID (1234), finding the first flow listed below.

             conj_id=1234 actions=controller
             ip,ip_src=10.0.0.1 actions=conjunction(1234, 1/2)
             ip,ip_src=10.0.0.4 actions=conjunction(1234, 1/2)
             ip,ip_src=10.0.0.6 actions=conjunction(1234, 1/2)
             ip,ip_src=10.0.0.7 actions=conjunction(1234, 1/2)
             ip,ip_dst=10.0.0.2 actions=conjunction(1234, 2/2)
             ip,ip_dst=10.0.0.5 actions=conjunction(1234, 2/2)
             ip,ip_dst=10.0.0.7 actions=conjunction(1234, 2/2)
             ip,ip_dst=10.0.0.8 actions=conjunction(1234, 2/2)

       Many subtleties exist:

              •      In the example above, every flow in a single
                     dimension has the same form, that is, dimension 1
                     matches on ip_src and dimension 2 on ip_dst, but
                     this is not a requirement. Different flows within a
                     dimension may match on different bits within a
                     field (e.g. IP network prefixes of different
                     lengths, or TCP/UDP port ranges as bitwise
                     matches), or even on entirely different fields
                     (e.g. to match packets for TCP source port 80 or
                     TCP destination port 80).

              •      The flows within a dimension can vary their matches
                     across more than one field, e.g. to match only
                     specific pairs of IP source and destination
                     addresses or L4 port numbers.

              •      A flow may have multiple conjunction actions, with
                     different id values. This is useful for multiple
                     conjunctive flows with overlapping sets. If one
                     conjunctive flow matches packets with both ip_src ∈
                     {a,b} and ip_dst ∈ {d,e} and a second conjunctive
                     flow matches ip_src ∈ {b,c} and ip_dst ∈ {f,g}, for
                     example, then the flow that matches ip_src=b would
                     have two conjunction actions, one for each
                     conjunctive flow. The order of conjunction actions
                     within a list of actions is not significant.

              •      A flow with conjunction actions may also include
                     note actions for annotations, but not any other
                     kind of actions. (They would not be useful because
                     they would never be executed.)

              •      All of the flows that constitute a conjunctive flow
                     with a given id must have the same priority. (Flows
                     with the same id but different priorities are
                     currently treated as different conjunctive flows,
                     that is, currently id values need only be unique
                     within an OpenFlow table at a given priority. This
                     behavior isn’t guaranteed to stay the same in later
                     releases, so please use id values unique within an
                     OpenFlow table.)

              •      Conjunctive flows must not overlap with each other,
                     at a given priority, that is, any given packet must
                     be able to match at most one conjunctive flow at a
                     given priority. Overlapping conjunctive flows yield
                     unpredictable results. (The flows that constitute a
                     conjunctive flow may overlap with those that
                     constitute the same or another conjunctive flow.)

              •      Following a conjunctive flow match, the search for
                     the flow with conj_id=id is done in the same
                     general-purpose way as other flow table searches,
                     so one can use flows with conj_id=id to act
                     differently depending on circumstances. (One
                     exception is that the search for the conj_id=id
                     flow itself ignores conjunctive flows, to avoid
                     recursion.) If the search with conj_id=id fails,
                     Open vSwitch acts as if the conjunctive flow had
                     not matched at all, and continues searching the
                     flow table for other matching flows.

              •      OpenFlow prerequisite checking occurs for the flow
                     with conj_id=id in the same way as any other flow,
                     e.g. in an OpenFlow 1.1+ context, putting a
                     mod_nw_src action into the example above would
                     require adding an ip match, like this:

                               conj_id=1234,ip actions=mod_nw_src:1.2.3.4,controller

              •      OpenFlow prerequisite checking also occurs for the
                     individual flows that comprise a conjunctive match
                     in the same way as any other flow.

              •      The flows that constitute a conjunctive flow do not
                     have useful statistics. They are never updated with
                     byte or packet counts, and so on. (For such a flow,
                     therefore, the idle and hard timeouts work much the
                     same way.)

              •      Sometimes there is a choice of which flows include
                     a particular match. For example, suppose that we
                     added an extra constraint to our example, to match
                     on ip_src ∈ {a,b,c,d} and ip_dst ∈ {e,f,g,h} and
                     tcp_dst = i. One way to implement this is to add
                     the new constraint to the conj_id flow, like this:

                               conj_id=1234,tcp,tcp_dst=i actions=mod_nw_src:1.2.3.4,controller

                     but this is not recommended because of the cost of
                     the extra flow table lookup. Instead, add the
                     constraint to the individual flows, either in one
                     of the dimensions or (slightly better) all of them.

              •      A conjunctive match must have n ≥ 2 dimensions
                     (otherwise a conjunctive match is not necessary).
                     Open vSwitch enforces this.

              •      Each dimension within a conjunctive match should
                     ordinarily have more than one flow. Open vSwitch
                     does not enforce this.

       Conjunction ID Field
       Name:            conj_id
       Width:           32 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CONJ_ID (37) since Open vSwitch 2.4

       Used for conjunctive matching. See above for more information.

TUNNEL FIELDS         top

   Summary:
       Name                   Bytes             Mask   RW?   Prereqs   NXM/OXM Support
       ─────────────────────  ────────────────  ─────  ────  ────────  ─────────────────────
       tun_id aka tunnel_id   8                 yes    yes   none      OF 1.3+ and OVS 1.1+
       tun_src                4                 yes    yes   none      OVS 2.0+
       tun_dst                4                 yes    yes   none      OVS 2.0+
       tun_ipv6_src           16                yes    yes   none      OVS 2.5+
       tun_ipv6_dst           16                yes    yes   none      OVS 2.5+
       tun_gbp_id             2                 yes    yes   none      OVS 2.4+
       tun_gbp_flags          1                 yes    yes   none      OVS 2.4+
       tun_erspan_ver         1 (low 4 bits)    yes    yes   none      OVS 2.10+
       tun_erspan_idx         4 (low 20 bits)   yes    yes   none      OVS 2.10+
       tun_erspan_dir         1 (low 1 bits)    yes    yes   none      OVS 2.10+
       tun_erspan_hwid        1 (low 6 bits)    yes    yes   none      OVS 2.10+
       tun_gtpu_flags         1                 yes    no    none      OVS 2.13+
       tun_gtpu_msgtype       1                 yes    no    none      OVS 2.13+
       tun_metadata0          124               yes    yes   none      OVS 2.5+
       tun_metadata1          124               yes    yes   none      OVS 2.5+
       tun_metadata2          124               yes    yes   none      OVS 2.5+
       tun_metadata3          124               yes    yes   none      OVS 2.5+
       tun_metadata4          124               yes    yes   none      OVS 2.5+
       tun_metadata5          124               yes    yes   none      OVS 2.5+
       tun_metadata6          124               yes    yes   none      OVS 2.5+
       tun_metadata7          124               yes    yes   none      OVS 2.5+
       tun_metadata8          124               yes    yes   none      OVS 2.5+
       tun_metadata9          124               yes    yes   none      OVS 2.5+
       tun_metadata10         124               yes    yes   none      OVS 2.5+
       tun_metadata11         124               yes    yes   none      OVS 2.5+
       tun_metadata12         124               yes    yes   none      OVS 2.5+
       tun_metadata13         124               yes    yes   none      OVS 2.5+
       tun_metadata14         124               yes    yes   none      OVS 2.5+
       tun_metadata15         124               yes    yes   none      OVS 2.5+
       tun_metadata16         124               yes    yes   none      OVS 2.5+
       tun_metadata17         124               yes    yes   none      OVS 2.5+
       tun_metadata18         124               yes    yes   none      OVS 2.5+
       tun_metadata19         124               yes    yes   none      OVS 2.5+
       tun_metadata20         124               yes    yes   none      OVS 2.5+
       tun_metadata21         124               yes    yes   none      OVS 2.5+
       tun_metadata22         124               yes    yes   none      OVS 2.5+
       tun_metadata23         124               yes    yes   none      OVS 2.5+
       tun_metadata24         124               yes    yes   none      OVS 2.5+
       tun_metadata25         124               yes    yes   none      OVS 2.5+
       tun_metadata26         124               yes    yes   none      OVS 2.5+
       tun_metadata27         124               yes    yes   none      OVS 2.5+
       tun_metadata28         124               yes    yes   none      OVS 2.5+
       tun_metadata29         124               yes    yes   none      OVS 2.5+
       tun_metadata30         124               yes    yes   none      OVS 2.5+
       tun_metadata31         124               yes    yes   none      OVS 2.5+
       tun_metadata32         124               yes    yes   none      OVS 2.5+
       tun_metadata33         124               yes    yes   none      OVS 2.5+
       tun_metadata34         124               yes    yes   none      OVS 2.5+
       tun_metadata35         124               yes    yes   none      OVS 2.5+
       tun_metadata36         124               yes    yes   none      OVS 2.5+
       tun_metadata37         124               yes    yes   none      OVS 2.5+
       tun_metadata38         124               yes    yes   none      OVS 2.5+
       tun_metadata39         124               yes    yes   none      OVS 2.5+
       tun_metadata40         124               yes    yes   none      OVS 2.5+
       tun_metadata41         124               yes    yes   none      OVS 2.5+
       tun_metadata42         124               yes    yes   none      OVS 2.5+
       tun_metadata43         124               yes    yes   none      OVS 2.5+
       tun_metadata44         124               yes    yes   none      OVS 2.5+
       tun_metadata45         124               yes    yes   none      OVS 2.5+
       tun_metadata46         124               yes    yes   none      OVS 2.5+
       tun_metadata47         124               yes    yes   none      OVS 2.5+
       tun_metadata48         124               yes    yes   none      OVS 2.5+
       tun_metadata49         124               yes    yes   none      OVS 2.5+
       tun_metadata50         124               yes    yes   none      OVS 2.5+
       tun_metadata51         124               yes    yes   none      OVS 2.5+
       tun_metadata52         124               yes    yes   none      OVS 2.5+
       tun_metadata53         124               yes    yes   none      OVS 2.5+
       tun_metadata54         124               yes    yes   none      OVS 2.5+
       tun_metadata55         124               yes    yes   none      OVS 2.5+
       tun_metadata56         124               yes    yes   none      OVS 2.5+
       tun_metadata57         124               yes    yes   none      OVS 2.5+
       tun_metadata58         124               yes    yes   none      OVS 2.5+
       tun_metadata59         124               yes    yes   none      OVS 2.5+
       tun_metadata60         124               yes    yes   none      OVS 2.5+
       tun_metadata61         124               yes    yes   none      OVS 2.5+
       tun_metadata62         124               yes    yes   none      OVS 2.5+
       tun_metadata63         124               yes    yes   none      OVS 2.5+
       tun_flags              2 (low 1 bits)    yes    yes   none      OVS 2.5+

       The fields in this group relate to tunnels, which Open vSwitch
       supports in several forms (GRE, VXLAN, and so on). Most of these
       fields do appear in the wire format of a packet, so they are data
       fields from that point of view, but they are metadata from an
       OpenFlow flow table point of view because they do not appear in
       packets that are forwarded to the controller or to ordinary (non-
       tunnel) output ports.

       Open vSwitch supports a spectrum of usage models for mapping
       tunnels to OpenFlow ports:

              ``Port-based’’ tunnels
                     In this model, an OpenFlow port represents one
                     tunnel: it matches a particular type of tunnel
                     traffic between two IP endpoints, with a particular
                     tunnel key (if keys are in use). In this situation,
                     in_port suffices to distinguish one tunnel from
                     another, so the tunnel header fields have little
                     importance for OpenFlow processing. (They are still
                     populated and may be used if it is convenient.) The
                     tunnel header fields play no role in sending
                     packets out such an OpenFlow port, either, because
                     the OpenFlow port itself fully specifies the tunnel
                     headers.

                     The following Open vSwitch commands create a bridge
                     br-int, add port tap0 to the bridge as OpenFlow
                     port 1, establish a port-based GRE tunnel between
                     the local host and remote IP 192.168.1.1 using GRE
                     key 5001 as OpenFlow port 2, and arranges to
                     forward all traffic from tap0 to the tunnel and
                     vice versa:

                     ovs-vsctl add-br br-int
                     ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
                     ovs-vsctl add-port br-int gre0 -- \
                         set interface gre0 ofport_request=2 type=gre \
                                            options:remote_ip=192.168.1.1 options:key=5001
                     ovs-ofctl add-flow br-int in_port=1,actions=2
                     ovs-ofctl add-flow br-int in_port=2,actions=1

              ``Flow-based’’ tunnels
                     In this model, one OpenFlow port represents all
                     possible tunnels of a given type with an endpoint
                     on the current host, for example, all GRE tunnels.
                     In this situation, in_port only indicates that
                     traffic was received on the particular kind of
                     tunnel. This is where the tunnel header fields are
                     most important: they allow the OpenFlow tables to
                     discriminate among tunnels based on their IP
                     endpoints or keys. Tunnel header fields also
                     determine the IP endpoints and keys of packets sent
                     out such a tunnel port.

                     The following Open vSwitch commands create a bridge
                     br-int, add port tap0 to the bridge as OpenFlow
                     port 1, establish a flow-based GRE tunnel port 3,
                     and arranges to forward all traffic from tap0 to
                     remote IP 192.168.1.1 over a GRE tunnel with key
                     5001 and vice versa:

                     ovs-vsctl add-br br-int
                     ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
                     ovs-vsctl add-port br-int allgre -- \
                         set interface allgre ofport_request=3 type=gre \
                                              options:remote_ip=flow options:key=flow
                     ovs-ofctl add-flow br-int \
                         ’in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3’
                     ovs-ofctl add-flow br-int ’in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1’

              Mixed models.
                     One may define both flow-based and port-based
                     tunnels at the same time. For example, it is valid
                     and possibly useful to create and configure both
                     gre0 and allgre tunnel ports described above.

                     Traffic is attributed on ingress to the most
                     specific matching tunnel. For example, gre0 is more
                     specific than allgre. Therefore, if both exist,
                     then gre0 will be the ingress port for any GRE
                     traffic received from 192.168.1.1 with key 5001.

                     On egress, traffic may be directed to any
                     appropriate tunnel port. If both gre0 and allgre
                     are configured as already described, then the
                     actions 2 and
                     set_tunnel:5001,set_field:192.168.1.1->tun_dst,3
                     send the same tunnel traffic.

              Intermediate models.
                     Ports may be configured as partially flow-based.
                     For example, one may define an OpenFlow port that
                     represents tunnels between a pair of endpoints but
                     leaves the flow table to discriminate on the flow
                     key.

       ovs-vswitchd.conf.db(5) describes all the details of tunnel
       configuration.

       These fields do not have any prerequisites, which means that a
       flow may match on any or all of them, in any combination.

       These fields are zeros for packets that did not arrive on a
       tunnel.

       Tunnel ID Field
       Name:            tun_id (aka tunnel_id)
       Width:           64 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_TUNNEL_ID (38) since OpenFlow 1.3 and
                        Open vSwitch 1.10
       NXM:             NXM_NX_TUN_ID (16) since Open vSwitch 1.1

       Many kinds of tunnels support a tunnel ID:

              •      VXLAN and Geneve have a 24-bit virtual network
                     identifier (VNI).

              •      LISP has a 24-bit instance ID.

              •      GRE has an optional 32-bit key.

              •      STT has a 64-bit key.

              •      ERSPAN has a 10-bit key (Session ID).

              •      GTPU has a 32-bit key (Tunnel Endpoint ID).

       When a packet is received from a tunnel, this field holds the
       tunnel ID in its least significant bits, zero-extended to fit.
       This field is zero if the tunnel does not support an ID, or if no
       ID is in use for a tunnel type that has an optional ID, or if an
       ID of zero received, or if the packet was not received over a
       tunnel.

       When a packet is output to a tunnel port, the tunnel
       configuration determines whether the tunnel ID is taken from this
       field or bound to a fixed value. See the earlier description of
       ``port-based’’ and ``flow-based’’ tunnels for more information.

       The following diagram shows the origin of this field in a typical
       keyed GRE tunnel:

          Ethernet            IPv4               GRE           Ethernet
        <----------->   <--------------->   <------------>   <---------->
        48  48   16           8   32  32    16    16   32    48  48   16
       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
       |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
                0x800        47                 0x6558

       Tunnel IPv4 Source Field
       Name:            tun_src
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_IPV4_SRC (31) since Open vSwitch 2.0

       When a packet is received from a tunnel, this field is the source
       address in the outer IP header of the tunneled packet. This field
       is zero if the packet was not received over a tunnel.

       When a packet is output to a flow-based tunnel port, this field
       influences the IPv4 source address used to send the packet. If it
       is zero, then the kernel chooses an appropriate IP address based
       using the routing table.

       The following diagram shows the origin of this field in a typical
       keyed GRE tunnel:

          Ethernet            IPv4               GRE           Ethernet
        <----------->   <--------------->   <------------>   <---------->
        48  48   16           8   32  32    16    16   32    48  48   16
       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
       |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
                0x800        47                 0x6558

       Tunnel IPv4 Destination Field
       Name:            tun_dst
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_IPV4_DST (32) since Open vSwitch 2.0

       When a packet is received from a tunnel, this field is the
       destination address in the outer IP header of the tunneled
       packet. This field is zero if the packet was not received over a
       tunnel.

       When a packet is output to a flow-based tunnel port, this field
       specifies the destination to which the tunnel packet is sent.

       The following diagram shows the origin of this field in a typical
       keyed GRE tunnel:

          Ethernet            IPv4               GRE           Ethernet
        <----------->   <--------------->   <------------>   <---------->
        48  48   16           8   32  32    16    16   32    48  48   16
       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
       |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
                0x800        47                 0x6558

       Tunnel IPv6 Source Field
       Name:            tun_ipv6_src
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_IPV6_SRC (109) since Open vSwitch 2.5

       Similar to tun_src, but for tunnels over IPv6.

       Tunnel IPv6 Destination Field
       Name:            tun_ipv6_dst
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_IPV6_DST (110) since Open vSwitch 2.5

       Similar to tun_dst, but for tunnels over IPv6.

   VXLAN Group-Based Policy Fields
       The VXLAN header is defined as follows [RFC 7348], where the I
       bit must be set to 1, unlabeled bits or those labeled reserved
       must be set to 0, and Open vSwitch makes the VNI available via
       tun_id:

          VXLAN flags
        <------------->
        1 1 1 1 1 1 1 1    24    24     8
       +-+-+-+-+-+-+-+-+--------+---+--------+
       | | | | |I| | | |reserved|VNI|reserved|
       +-+-+-+-+-+-+-+-+--------+---+--------+

       VXLAN Group-Based Policy [VXLAN Group Policy Option] adds new
       interpretations to existing bits in the VXLAN header,
       reinterpreting it as follows, with changes highlighted:

           GBP flags
        <------------->
        1 1 1 1 1 1 1 1       24        24     8
       +-+-+-+-+-+-+-+-+---------------+---+--------+
       | |D| | |A| | | |group policy ID|VNI|reserved|
       +-+-+-+-+-+-+-+-+---------------+---+--------+

       Open vSwitch makes GBP fields and flags available through the
       following fields. Only packets that arrive over a VXLAN tunnel
       with the GBP extension enabled have these fields set. In other
       packets they are zero on receive and ignored on transmit.

       VXLAN Group-Based Policy ID Field
       Name:            tun_gbp_id
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_GBP_ID (38) since Open vSwitch 2.4

       For a packet tunneled over VXLAN with the Group-Based Policy
       (GBP) extension, this field represents the GBP policy ID, as
       shown above.

       VXLAN Group-Based Policy Flags Field
       Name:            tun_gbp_flags
       Width:           8 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_GBP_FLAGS (39) since Open vSwitch 2.4

       For a packet tunneled over VXLAN with the Group-Based Policy
       (GBP) extension, this field represents the GBP policy flags, as
       shown above.

       The field has the format shown below:

           GBP Flags
        <------------->
        1 1 1 1 1 1 1 1
       +-+-+-+-+-+-+-+-+
       | |D| | |A| | | |
       +-+-+-+-+-+-+-+-+

       Unlabeled bits are reserved and must be transmitted as 0. The
       VXLAN GBP draft defines the other bits’ meanings as:

              D (Don’t Learn)
                     When set, this bit indicates that the egress tunnel
                     endpoint must not learn the source address of the
                     encapsulated frame.

              A (Applied)
                     When set, indicates that the group policy has
                     already been applied to this packet. Devices must
                     not apply policies when the A bit is set.

   ERSPAN Metadata Fields
       These fields provide access to features in the ERSPAN tunneling
       protocol [ERSPAN], which has two major versions: version 1 (aka
       type II) and version 2 (aka type III).

       Regardless of version, ERSPAN is encapsulated within a fixed
       8-byte GRE header that consists of a 4-byte GRE base header and a
       4-byte sequence number. The ERSPAN version 1 header format is:

             GRE                ERSPAN v1            Ethernet
        <------------>   <--------------------->   <---------->
        16    16   32     4  18    10    12  20    48  48   16
       +---+------+---+ +---+---+-------+---+---+ +---+---+----+
       |...| type |seq| |ver|...|session|...|idx| |dst|src|type| ...
       +---+------+---+ +---+---+-------+---+---+ +---+---+----+
            0x88be        1      tun_id

       The ERSPAN version 2 header format is:

             GRE                         ERSPAN v2                      Ethernet
        <------------>   <---------------------------------------->   <---------->
        16    16   32     4  18    10       32     22   6    1   3    48  48   16
       +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
       |...| type |seq| |ver|...|session|timestamp|...|hwid|dir|...| |dst|src|type| ...
       +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
            0x22eb        2      tun_id                     0/1

       ERSPAN Version Field
       Name:            tun_erspan_ver
       Width:           8 bits (only the least-significant 4 bits may be nonzero)
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_ET_ERSPAN_VER (12) since Open vSwitch 2.10

       ERSPAN version number: 1 for version 1, or 2 for version 2.

       ERSPAN Index Field
       Name:            tun_erspan_idx
       Width:           32 bits (only the least-significant 20 bits may be nonzero)
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_ET_ERSPAN_IDX (11) since Open vSwitch 2.10

       This field is a 20-bit index/port number associated with the
       ERSPAN traffic’s source port and direction (ingress/egress). This
       field is platform dependent.

       ERSPAN Direction Field
       Name:            tun_erspan_dir
       Width:           8 bits (only the least-significant 1 bits may be nonzero)
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_ET_ERSPAN_DIR (13) since Open vSwitch 2.10

       For ERSPAN v2, the mirrored traffic’s direction: 0 for ingress
       traffic, 1 for egress traffic.

       ERSPAN Hardware ID Field
       Name:            tun_erspan_hwid
       Width:           8 bits (only the least-significant 6 bits may be nonzero)
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_ET_ERSPAN_HWID (14) since Open vSwitch 2.10

       A 6-bit unique identifier of an ERSPAN v2 engine within a system.

   GTP-U Metadata Fields
       These fields provide access to set-up GPRS Tunnelling Protocol
       for User Plane (GTPv1-U), based on 3GPP TS 29.281. A GTP-U header
       has the following format:

          8      8       16    32
       +-----+--------+------+----+
       |flags|msg type|length|TEID| ...
       +-----+--------+------+----+

       The flags and message type have the Open vSwitch GTP-U specific
       fields described below. Open vSwitch makes the TEID (Tunnel
       Endpoint Identifier), which identifies a tunnel endpoint in the
       receiving GTP-U protocol entity, available via tun_id.

       GTP-U Flags Field
       Name:            tun_gtpu_flags
       Width:           8 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_ET_GTPU_FLAGS (15) since Open vSwitch 2.13

       This field holds the 8-bit GTP-U flags, encoded as:

         GTP-U Tunnel Flags
        <------------------->
           3    1   1  1 1 1
       +-------+--+---+-+-+--+
       |version|PT|rsv|E|S|PN|
       +-------+--+---+-+-+--+
           1        0

       The flags are:

              version
                     Used to determine the version of the GTP-U
                     protocol, which should be set to 1.

              PT     Protocol type, used as a protocol discriminator
                     between GTP (1) and GTP’ (0).

              rsv    Reserved. Must be zero.

              E      If 1, indicates the presence of a meaningful value
                     of the Next Extension Header field.

              S      If 1, indicates the presence of a meaningful value
                     of the Sequence Number field.

              PN     If 1, indicates the presence of a meaningful value
                     of the N-PDU Number field.

       GTP-U Message Type Field
       Name:            tun_gtpu_msgtype
       Width:           8 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_ET_GTPU_MSGTYPE (16) since Open vSwitch
                        2.13

       This field indicates whether it’s a signalling message used for
       path management, or a user plane message which carries the
       original packet. The complete range of message types can be
       referred to [3GPP TS 29.281].

   Geneve Fields
       These fields provide access to additional features in the Geneve
       tunneling protocol [Geneve]. Their names are somewhat generic in
       the hope that the same fields could be reused for other protocols
       in the future; for example, the NSH protocol [NSH] supports TLV
       options whose form is identical to that for Geneve options.

       Generic Tunnel Option 0 Field
       Name:            tun_metadata0
       Width:           992 bits (124 bytes)
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_METADATA0 (40) since Open vSwitch 2.5

       The above information specifically covers generic tunnel option
       0, but Open vSwitch supports 64 options, numbered 0 through 63,
       whose NXM field numbers are 40 through 103.

       These fields provide OpenFlow access to the generic type-length-
       value options defined by the Geneve tunneling protocol or other
       protocols with options in the same TLV format as Geneve options.
       Each of these options has the following wire format:

               header                 body
        <-------------------> <------------------>
         16    8    3    5    4×(length - 1) bytes
       +-----+----+---+------+--------------------+
       |class|type|res|length|       value        |
       +-----+----+---+------+--------------------+
                    0

       Taken together, the class and type in the option format mean that
       there are about 16 million distinct kinds of TLV options, too
       many to give individual OXM code points. Thus, Open vSwitch
       requires the user to define the TLV options of interest, by
       binding up to 64 TLV options to generic tunnel option NXM code
       points. Each option may have up to 124 bytes in its body, the
       maximum allowed by the TLV format, but bound options may total at
       most 252 bytes of body.

       Open vSwitch extensions to the OpenFlow protocol bind TLV options
       to NXM code points. The ovs-ofctl(8) program offers one way to
       use these extensions, e.g. to configure a mapping from a TLV
       option with class 0xffff, type 0, and a body length of 4 bytes:

       ovs-ofctl add-tlv-map br0 "{class=0xffff,type=0,len=4}->tun_metadata0"

       Once a TLV option is properly bound, it can be accessed and
       modified like any other field, e.g. to send packets that have
       value 1234 for the option described above to the controller:

       ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller

       An option not received or not bound is matched as all zeros.

       Tunnel Flags Field
       Name:            tun_flags
       Width:           16 bits (only the least-significant 1 bits may be nonzero)
       Format:          tunnel flags
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_TUN_FLAGS (104) since Open vSwitch 2.5

       Flags indicating various aspects of the tunnel encapsulation.

       Matches on this field are most conveniently written in terms of
       symbolic names (given in the diagram below), each preceded by
       either + for a flag that must be set, or - for a flag that must
       be unset, without any other delimiters between the flags. Flags
       not mentioned are wildcarded. For example, tun_flags=+oam matches
       only OAM packets. Matches can also be written as flags/mask,
       where flags and mask are 16-bit numbers in decimal or in
       hexadecimal prefixed by 0x.

       Currently, only one flag is defined:

              oam    The tunnel protocol indicated that this is an OAM
                     (Operations and Management) control packet.

       The switch may reject matches against unknown flags.

       Newer versions of Open vSwitch may introduce additional flags
       with new meanings. It is therefore not recommended to use an
       exact match on this field since the behavior of these new flags
       is unknown and should be ignored.

       For non-tunneled packets, the value is 0.

METADATA FIELDS         top

   Summary:
       Name            Bytes   Mask   RW?   Prereqs   NXM/OXM Support
       ──────────────  ──────  ─────  ────  ────────  ─────────────────────
       in_port         2       no     yes   none      OVS 1.1+
       in_port_oxm     4       no     yes   none      OF 1.2+ and OVS 1.7+
       skb_priority    4       no     no    none
       pkt_mark        4       yes    yes   none      OVS 2.0+
       actset_output   4       no     no    none      OF 1.3+ and OVS 2.4+
       packet_type     4       no     no    none      OF 1.5+ and OVS 2.8+

       These fields relate to the origin or treatment of a packet, but
       they are not extracted from the packet data itself.

       Ingress Port Field
       Name:            in_port
       Width:           16 bits
       Format:          OpenFlow 1.0 port
       Masking:         not maskable
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             none
       NXM:             NXM_OF_IN_PORT (0) since Open vSwitch 1.1

       The OpenFlow port on which the packet being processed arrived.
       This is a 16-bit field that holds an OpenFlow 1.0 port number.
       For receiving a packet, the only values that appear in this field
       are:

              1 through 0xfeff (65,279), inclusive.
                     Conventional OpenFlow port numbers.

              OFPP_LOCAL (0xfffe or 65,534).
                     The ``local’’ port, which in Open vSwitch is always
                     named the same as the bridge itself. This
                     represents a connection between the switch and the
                     local TCP/IP stack. This port is where an IP
                     address is most commonly configured on an Open
                     vSwitch switch.

                     OpenFlow does not require a switch to have a local
                     port, but all existing versions of Open vSwitch
                     have always included a local port. Future
                     Directions: Future versions of Open vSwitch might
                     be able to optionally omit the local port, if
                     someone submits code to implement such a feature.

              OFPP_NONE (OpenFlow 1.0) or OFPP_ANY (OpenFlow 1.1+)
              (0xffff or 65,535).
              OFPP_CONTROLLER (0xfffd or 65,533).
                   When a controller injects a packet into an OpenFlow
                   switch with a ``packet-out’’ request, it can specify
                   one of these ingress ports to indicate that the
                   packet was generated internally rather than having
                   been received on some port.

                   OpenFlow 1.0 specified OFPP_NONE for this purpose.
                   Despite that, some controllers used OFPP_CONTROLLER,
                   and some switches only accepted OFPP_CONTROLLER, so
                   OpenFlow 1.0.2 required support for both ports.
                   OpenFlow 1.1 and later were more clearly drafted to
                   allow only OFPP_CONTROLLER. For maximum
                   compatibility, Open vSwitch allows both ports with
                   all OpenFlow versions.

       Values not mentioned above will never appear when receiving a
       packet, including the following notable values:

              0      Zero is not a valid OpenFlow port number.

              OFPP_MAX (0xff00 or 65,280).
                     This value has only been clearly specified as a
                     valid port number as of OpenFlow 1.3.3. Before
                     that, its status was unclear, and so Open vSwitch
                     has never allowed OFPP_MAX to be used as a port
                     number, so packets will never be received on this
                     port. (Other OpenFlow switches, of course, might
                     use it.)

              OFPP_UNSET (0xfff7 or 65,527)
              OFPP_IN_PORT (0xfff8 or 65,528)
              OFPP_TABLE (0xfff9 or 65,529)
              OFPP_NORMAL (0xfffa or 65,530)
              OFPP_FLOOD (0xfffb or 65,531)
              OFPP_ALL (0xfffc or 65,532)
                   These port numbers are used only in output actions
                   and never appear as ingress ports.

                   Most of these port numbers were defined in OpenFlow
                   1.0, but OFPP_UNSET was only introduced in OpenFlow
                   1.5.

       Values that will never appear when receiving a packet may still
       be matched against in the flow table. There are still
       circumstances in which those flows can be matched:

              •      The resubmit Open vSwitch extension action allows a
                     flow table lookup with an arbitrary ingress port.

              •      An action that modifies the ingress port field (see
                     below), such as e.g. load or set_field, followed by
                     an action or instruction that performs another flow
                     table lookup, such as resubmit or goto_table.

       This field is heavily used for matching in OpenFlow tables, but
       for packet egress, it has only very limited roles:

              •      OpenFlow requires suppressing output actions to
                     in_port. That is, the following two flows both drop
                     all packets that arrive on port 1:

                     in_port=1,actions=1
                     in_port=1,actions=drop

                     (This behavior is occasionally useful for flooding
                     to a subset of ports. Specifying actions=1,2,3,4,
                     for example, outputs to ports 1, 2, 3, and 4,
                     omitting the ingress port.)

              •      OpenFlow has a special port OFPP_IN_PORT (with
                     value 0xfff8) that outputs to the ingress port. For
                     example, in a switch that has four ports numbered 1
                     through 4, actions=1,2,3,4,in_port outputs to ports
                     1, 2, 3, and 4, including the ingress port.

       Because the ingress port field has so little influence on packet
       processing, it does not ordinarily make sense to modify the
       ingress port field. The field is writable only to support the
       occasional use case where the ingress port’s roles in packet
       egress, described above, become troublesome. For example,
       actions=load:0->NXM_OF_IN_PORT[],output:123 will output to port
       123 regardless of whether it is in the ingress port. If the
       ingress port is important, then one may save and restore it on
       the stack:

       actions=push:NXM_OF_IN_PORT[],load:0->NXM_OF_IN_PORT[],output:123,pop:NXM_OF_IN_PORT[]

       or, in Open vSwitch 2.7 or later, use the clone action to save
       and restore it:

       actions=clone(load:0->NXM_OF_IN_PORT[],output:123)

       The ability to modify the ingress port is an Open vSwitch
       extension to OpenFlow.

       OXM Ingress Port Field
       Name:            in_port_oxm
       Width:           32 bits
       Format:          OpenFlow 1.1+ port
       Masking:         not maskable
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_IN_PORT (0) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             none

       OpenFlow 1.1 and later use a 32-bit port number, so this field
       supplies a 32-bit view of the ingress port. Current versions of
       Open vSwitch support only a 16-bit range of ports:

              •      OpenFlow 1.0 ports 0x0000 to 0xfeff, inclusive, map
                     to OpenFlow 1.1 port numbers with the same values.

              •      OpenFlow 1.0 ports 0xff00 to 0xffff, inclusive, map
                     to OpenFlow 1.1 port numbers 0xffffff00 to
                     0xffffffff.

              •      OpenFlow 1.1 ports 0x0000ff00 to 0xfffffeff are not
                     mapped and not supported.

       in_port and in_port_oxm are two views of the same information, so
       all of the comments on in_port apply to in_port_oxm too.
       Modifying in_port changes in_port_oxm, and vice versa.

       Setting in_port_oxm to an unsupported value yields unspecified
       behavior.

       Output Queue Field
       Name:            skb_priority
       Width:           32 bits
       Format:          hexadecimal
       Masking:         not maskable
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             none

       Future Directions: Open vSwitch implements the output queue as a
       field, but does not currently expose it through OXM or NXM for
       matching purposes. If this turns out to be a useful feature, it
       could be implemented in future versions. Only the set_queue,
       enqueue, and pop_queue actions currently influence the output
       queue.

       This field influences how packets in the flow will be queued, for
       quality of service (QoS) purposes, when they egress the switch.
       Its range of meaningful values, and their meanings, varies
       greatly from one OpenFlow implementation to another. Even within
       a single implementation, there is no guarantee that all OpenFlow
       ports have the same queues configured or that all OpenFlow ports
       in an implementation can be configured the same way queue-wise.

       Configuring queues on OpenFlow is not well standardized. On
       Linux, Open vSwitch supports queue configuration via OVSDB,
       specifically the QoS and Queue tables (see
       ovs-vswitchd.conf.db(5) for details). Ports of Open vSwitch to
       other platforms might require queue configuration through some
       separate protocol (such as a CLI). Even on Linux, Open vSwitch
       exposes only a fraction of the kernel’s queuing features through
       OVSDB, so advanced or unusual uses might require use of separate
       utilities (e.g. tc). OpenFlow switches other than Open vSwitch
       might use OF-CONFIG or any of the configuration methods mentioned
       above. Finally, some OpenFlow switches have a fixed number of
       fixed-function queues (e.g. eight queues with strictly defined
       priorities) and others do not support any control over queuing.

       The only output queue that all OpenFlow implementations must
       support is zero, to identify a default queue, whose properties
       are implementation-defined. Outputting a packet to a queue that
       does not exist on the output port yields unpredictable behavior:
       among the possibilities are that the packet might be dropped or
       transmitted with a very high or very low priority.

       OpenFlow 1.0 only allowed output queues to be specified as part
       of an enqueue action that specified both a queue and an output
       port. That is, OpenFlow 1.0 treats the queue as an argument to an
       action, not as a field.

       To increase flexibility, OpenFlow 1.1 added an action to set the
       output queue. This model was carried forward, without change,
       through OpenFlow 1.5.

       Open vSwitch implements the native queuing model of each OpenFlow
       version it supports. Open vSwitch also includes an extension for
       setting the output queue as an action in OpenFlow 1.0.

       When a packet ingresses into an OpenFlow switch, the output queue
       is ordinarily set to 0, indicating the default queue. However,
       Open vSwitch supports various ways to forward a packet from one
       OpenFlow switch to another within a single host. In these cases,
       Open vSwitch maintains the output queue across the forwarding
       step. For example:

              •      A hop across an Open vSwitch ``patch port’’ (which
                     does not actually involve queuing) preserves the
                     output queue.

              •      When a flow sets the output queue then outputs to
                     an OpenFlow tunnel port, the encapsulation
                     preserves the output queue. If the kernel TCP/IP
                     stack routes the encapsulated packet directly to a
                     physical interface, then that output honors the
                     output queue. Alternatively, if the kernel routes
                     the encapsulated packet to another Open vSwitch
                     bridge, then the output queue set previously
                     becomes the initial output queue on ingress to the
                     second bridge and will thus be used for further
                     output actions (unless overridden by a new ``set
                     queue’’ action).

                     (This description reflects the current behavior of
                     Open vSwitch on Linux. This behavior relies on
                     details of the Linux TCP/IP stack. It could be
                     difficult to make ports to other operating systems
                     behave the same way.)

       Packet Mark Field
       Name:            pkt_mark
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_PKT_MARK (33) since Open vSwitch 2.0

       Packet mark comes to Open vSwitch from the Linux kernel, in which
       the sk_buff data structure that represents a packet contains a
       32-bit member named skb_mark. The value of skb_mark propagates
       along with the packet it accompanies wherever the packet goes in
       the kernel. It has no predefined semantics but various kernel-
       user interfaces can set and match on it, which makes it suitable
       for ``marking’’ packets at one point in their handling and then
       acting on the mark later. With iptables, for example, one can
       mark some traffic specially at ingress and then handle that
       traffic differently at egress based on the marked value.

       Packet mark is an attempt at a generalization of the skb_mark
       concept beyond Linux, at least through more generic naming. Like
       skb_priority, packet mark is preserved across forwarding steps
       within a machine. Unlike skb_priority, packet mark has no direct
       effect on packet forwarding: the value set in packet mark does
       not matter unless some later OpenFlow table or switch matches on
       packet mark, or unless the packet passes through some other
       kernel subsystem that has been configured to interpret packet
       mark in specific ways, e.g. through iptables configuration
       mentioned above.

       Preserving packet mark across kernel forwarding steps relies
       heavily on kernel support, which ports to non-Linux operating
       systems may not have. Regardless of operating system support,
       Open vSwitch supports packet mark within a single bridge and
       across patch ports.

       The value of packet mark when a packet ingresses into the first
       Open vSwich bridge is typically zero, but it could be nonzero if
       its value was previously set by some kernel subsystem.

       Action Set Output Port Field
       Name:            actset_output
       Width:           32 bits
       Format:          OpenFlow 1.1+ port
       Masking:         not maskable
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             ONFOXM_ET_ACTSET_OUTPUT (43) since OpenFlow 1.3
                        and Open vSwitch 2.4; OXM_OF_ACTSET_OUTPUT (43)
                        since OpenFlow 1.5 and Open vSwitch 2.4
       NXM:             none

       Holds the output port currently in the OpenFlow action set (i.e.
       from an output action within a write_actions instruction). Its
       value is an OpenFlow port number. If there is no output port in
       the OpenFlow action set, or if the output port will be ignored
       (e.g. because there is an output group in the OpenFlow action
       set), then the value will be OFPP_UNSET.

       Open vSwitch allows any table to match this field. OpenFlow,
       however, only requires this field to be matchable from within an
       OpenFlow egress table (a feature that Open vSwitch does not yet
       implement).

       Packet Type Field
       Name:            packet_type
       Width:           32 bits
       Format:          packet type
       Masking:         not maskable
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_PACKET_TYPE (44) since OpenFlow 1.5 and
                        Open vSwitch 2.8
       NXM:             none

       The type of the packet in the format specified in OpenFlow 1.5:

        Packet type
        <--------->
        16    16
       +---+-------+
       |ns |ns_type| ...
       +---+-------+

       The upper 16 bits, ns, are a namespace. The meaning of ns_type
       depends on the namespace. The packet type field is specified and
       displayed in the format (ns,ns_type).

       Open vSwitch currently supports the following classes of packet
       types for matching:

              (0,0)  Ethernet.

              (1,ethertype)
                     The specified ethertype. Open vSwitch can forward
                     packets with any ethertype, but it can only match
                     on and process data fields for the following
                     supported packet types:

                     (1,0x800)
                            IPv4

                     (1,0x806)
                            ARP

                     (1,0x86dd)
                            IPv6

                     (1,0x8847)
                            MPLS

                     (1,0x8848)
                            MPLS multicast

                     (1,0x8035)
                            RARP

                     (1,0x894f)
                            NSH

       Consider the distinction between a packet with packet_type=(0,0),
       dl_type=0x800 and one with packet_type=(1,0x800). The former is
       an Ethernet frame that contains an IPv4 packet, like this:

          Ethernet            IPv4
        <----------->   <--------------->
        48  48   16           8   32  32
       +---+---+-----+ +---+-----+---+---+
       |dst|src|type | |...|proto|src|dst| ...
       +---+---+-----+ +---+-----+---+---+
                0x800

       The latter is an IPv4 packet not encapsulated inside any outer
       frame, like this:

              IPv4
        <--------------->
              8   32  32
       +---+-----+---+---+
       |...|proto|src|dst| ...
       +---+-----+---+---+

       Matching on packet_type is a pre-requisite for matching on any
       data field, but for backward compatibility, when a match on a
       data field is present without a packet_type match, Open vSwitch
       acts as though a match on (0,0) (Ethernet) had been supplied.
       Similarly, when Open vSwitch sends flow match information to a
       controller, e.g. in a reply to a request to dump the flow table,
       Open vSwitch omits a match on packet type (0,0) if it would be
       implied by a data field match.

CONNECTION TRACKING FIELDS         top

   Summary:
       Name          Bytes   Mask   RW?   Prereqs   NXM/OXM Support
       ────────────  ──────  ─────  ────  ────────  ────────────────
       ct_state      4       yes    no    none      OVS 2.5+
       ct_zone       2       no     no    none      OVS 2.5+
       ct_mark       4       yes    yes   none      OVS 2.5+
       ct_label      16      yes    yes   none      OVS 2.5+
       ct_nw_src     4       yes    no    CT        OVS 2.8+
       ct_nw_dst     4       yes    no    CT        OVS 2.8+
       ct_ipv6_src   16      yes    no    CT        OVS 2.8+
       ct_ipv6_dst   16      yes    no    CT        OVS 2.8+
       ct_nw_proto   1       no     no    CT        OVS 2.8+
       ct_tp_src     2       yes    no    CT        OVS 2.8+
       ct_tp_dst     2       yes    no    CT        OVS 2.8+

       Open vSwitch supports ``connection tracking,’’ which allows
       bidirectional streams of packets to be statefully grouped into
       connections. Open vSwitch connection tracking, for example,
       identifies the patterns of TCP packets that indicates a
       successfully initiated connection, as well as those that indicate
       that a connection has been torn down. Open vSwitch connection
       tracking can also identify related connections, such as FTP data
       connections spawned from FTP control connections.

       An individual packet passing through the pipeline may be in one
       of two states, ``untracked’’ or ``tracked,’’ which may be
       distinguished via the ``trk’’ flag in ct_state. A packet is
       untracked at the beginning of the Open vSwitch pipeline and
       continues to be untracked until the pipeline invokes the ct
       action. The connection tracking fields are all zeroes in an
       untracked packet. When a flow in the Open vSwitch pipeline
       invokes the ct action, the action initializes the connection
       tracking fields and the packet becomes tracked for the remainder
       of its processing.

       The connection tracker stores connection state in an internal
       table, but it only adds a new entry to this table when a ct
       action for a new connection invokes ct with the commit parameter.
       For a given connection, when a pipeline has executed ct, but not
       yet with commit, the connection is said to be uncommitted. State
       for an uncommitted connection is ephemeral and does not persist
       past the end of the pipeline, so some features are only available
       to committed connections. A connection would typically be left
       uncommitted as a way to drop its packets.

       Connection tracking is an Open vSwitch extension to OpenFlow.
       Open vSwitch 2.5 added the initial support for connection
       tracking. Subsequent versions of Open vSwitch added many
       refinements and extensions to the initial support. Many of these
       capabilities depend on the Open vSwitch datapath rather than
       simply the userspace version. The capabilities column in the
       Datapath table (see ovs-vswitchd.conf.db(5)) reports the detailed
       capabilities of a particular Open vSwitch datapath.

       Connection Tracking State Field
       Name:            ct_state
       Width:           32 bits
       Format:          ct state
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_STATE (105) since Open vSwitch 2.5

       This field holds several flags that can be used to determine the
       state of the connection to which the packet belongs.

       Matches on this field are most conveniently written in terms of
       symbolic names (listed below), each preceded by either + for a
       flag that must be set, or - for a flag that must be unset,
       without any other delimiters between the flags. Flags not
       mentioned are wildcarded. For example, tcp,ct_state=+trk-new
       matches TCP packets that have been run through the connection
       tracker and do not establish a new connection. Matches can also
       be written as flags/mask, where flags and mask are 32-bit numbers
       in decimal or in hexadecimal prefixed by 0x.

       The following flags are defined:

              new (0x01)
                     A new connection. Set to 1 if this is an
                     uncommitted connection.

              est (0x02)
                     Part of an existing connection. Set to 1 if packets
                     of a committed connection have been seen by
                     conntrack from both directions.

              rel (0x04)
                     Related to an existing connection, e.g. an ICMP
                     ``destination unreachable’’ message or an FTP data
                     connections. This flag will only be 1 if the
                     connection to which this one is related is
                     committed.

                     Connections identified as rel are separate from the
                     originating connection and must be committed
                     separately. All packets for a related connection
                     will have the rel flag set, not just the initial
                     packet.

              rpl (0x08)
                     This packet is in the reply direction, meaning that
                     it is in the opposite direction from the packet
                     that initiated the connection. This flag will only
                     be 1 if the connection is committed.

              inv (0x10)
                     The state is invalid, meaning that the connection
                     tracker couldn’t identify the connection. This flag
                     is a catch-all for problems in the connection or
                     the connection tracker, such as:

                     •      L3/L4 protocol handler is not
                            loaded/unavailable. With the Linux kernel
                            datapath, this may mean that the
                            nf_conntrack_ipv4 or nf_conntrack_ipv6
                            modules are not loaded.

                     •      L3/L4 protocol handler determines that the
                            packet is malformed.

                     •      Packets are unexpected length for protocol.

              trk (0x20)
                     This packet is tracked, meaning that it has
                     previously traversed the connection tracker. If
                     this flag is not set, then no other flags will be
                     set. If this flag is set, then the packet is
                     tracked and other flags may also be set.

              snat (0x40)
                     This packet was transformed by source address/port
                     translation by a preceding ct action. Open vSwitch
                     2.6 added this flag.

              dnat (0x80)
                     This packet was transformed by destination
                     address/port translation by a preceding ct action.
                     Open vSwitch 2.6 added this flag.

       There are additional constraints on these flags, listed in
       decreasing order of precedence below:

              1.  If trk is unset, no other flags are set.

              2.  If trk is set, one or more other flags may be set.

              3.  If inv is set, only the trk flag is also set.

              4.  new and est are mutually exclusive.

              5.  new and rpl are mutually exclusive.

              6.  rel may be set in conjunction with any other flags.

       Future versions of Open vSwitch may define new flags.

       Connection Tracking Zone Field
       Name:            ct_zone
       Width:           16 bits
       Format:          hexadecimal
       Masking:         not maskable
       Prerequisites:   none
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_ZONE (106) since Open vSwitch 2.5

       A connection tracking zone, the zone value passed to the most
       recent ct action. Each zone is an independent connection tracking
       context, so tracking the same packet in multiple contexts
       requires using the ct action multiple times.

       Connection Tracking Mark Field
       Name:            ct_mark
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_MARK (107) since Open vSwitch 2.5

       The metadata committed, by an action within the exec parameter to
       the ct action, to the connection to which the current packet
       belongs.

       Connection Tracking Label Field
       Name:            ct_label
       Width:           128 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_LABEL (108) since Open vSwitch 2.5

       The label committed, by an action within the exec parameter to
       the ct action, to the connection to which the current packet
       belongs.

       Open vSwitch 2.8 introduced the matching support for connection
       tracker original direction 5-tuple fields.

       For non-committed non-related connections the conntrack original
       direction tuple fields always have the same values as the
       corresponding headers in the packet itself. For any other packets
       of a committed connection the conntrack original direction tuple
       fields reflect the values from that initial non-committed non-
       related packet, and thus may be different from the actual packet
       headers, as the actual packet headers may be in reverse direction
       (for reply packets), transformed by NAT (when nat option was
       applied to the connection), or be of different protocol (i.e.,
       when an ICMP response is sent to an UDP packet). In case of
       related connections, e.g., an FTP data connection, the original
       direction tuple contains the original direction headers from the
       parent connection, e.g., an FTP control connection.

       The following fields are populated by the ct action, and require
       a match to a valid connection tracking state as a prerequisite,
       in addition to the IP or IPv6 ethertype match. Examples of valid
       connection tracking state matches include ct_state=+new,
       ct_state=+est, ct_state=+rel, and ct_state=+trk-inv.

       Connection Tracking Original Direction IPv4 Source Address Field
       Name:            ct_nw_src
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_NW_SRC (120) since Open vSwitch 2.8

       Matches IPv4 conntrack original direction tuple source address.
       See the paragraphs above for general description to the conntrack
       original direction tuple. Introduced in Open vSwitch 2.8.

       Connection Tracking Original Direction IPv4 Destination Address
       Field
       Name:            ct_nw_dst
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_NW_DST (121) since Open vSwitch 2.8

       Matches IPv4 conntrack original direction tuple destination
       address. See the paragraphs above for general description to the
       conntrack original direction tuple. Introduced in Open vSwitch
       2.8.

       Connection Tracking Original Direction IPv6 Source Address Field
       Name:            ct_ipv6_src
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_IPV6_SRC (122) since Open vSwitch 2.8

       Matches IPv6 conntrack original direction tuple source address.
       See the paragraphs above for general description to the conntrack
       original direction tuple. Introduced in Open vSwitch 2.8.

       Connection Tracking Original Direction IPv6 Destination Address
       Field
       Name:            ct_ipv6_dst
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_IPV6_DST (123) since Open vSwitch 2.8

       Matches IPv6 conntrack original direction tuple destination
       address. See the paragraphs above for general description to the
       conntrack original direction tuple. Introduced in Open vSwitch
       2.8.

       Connection Tracking Original Direction IP Protocol Field
       Name:            ct_nw_proto
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_NW_PROTO (119) since Open vSwitch 2.8

       Matches conntrack original direction tuple IP protocol type,
       which is specified as a decimal number between 0 and 255,
       inclusive (e.g. 1 to match ICMP packets or 6 to match TCP
       packets). In case of, for example, an ICMP response to an UDP
       packet, this may be different from the IP protocol type of the
       packet itself. See the paragraphs above for general description
       to the conntrack original direction tuple. Introduced in Open
       vSwitch 2.8.

       Connection Tracking Original Direction Transport Layer Source
       Port Field
       Name:            ct_tp_src
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_TP_SRC (124) since Open vSwitch 2.8

       Bitwise match on the conntrack original direction tuple transport
       source, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or
       132 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58
       for ICMPv6, the lower 8 bits of MFF_CT_TP_SRC matches the
       conntrack original direction ICMP type. See the paragraphs above
       for general description to the conntrack original direction
       tuple. Introduced in Open vSwitch 2.8.

       Connection Tracking Original Direction Transport Layer Source
       Port Field
       Name:            ct_tp_dst
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   CT
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_CT_TP_DST (125) since Open vSwitch 2.8

       Bitwise match on the conntrack original direction tuple transport
       destination port, when MFF_CT_NW_PROTO has value 6 for TCP, 17
       for UDP, or 132 for SCTP. When MFF_CT_NW_PROTO has value 1 for
       ICMP, or 58 for ICMPv6, the lower 8 bits of MFF_CT_TP_DST matches
       the conntrack original direction ICMP code. See the paragraphs
       above for general description to the conntrack original direction
       tuple. Introduced in Open vSwitch 2.8.

REGISTER FIELDS         top

   Summary:
       Name       Bytes   Mask   RW?   Prereqs   NXM/OXM Support
       ─────────  ──────  ─────  ────  ────────  ─────────────────────
       metadata   8       yes    yes   none      OF 1.2+ and OVS 1.8+
       reg0       4       yes    yes   none      OVS 1.1+
       reg1       4       yes    yes   none      OVS 1.1+
       reg2       4       yes    yes   none      OVS 1.1+
       reg3       4       yes    yes   none      OVS 1.1+
       reg4       4       yes    yes   none      OVS 1.3+
       reg5       4       yes    yes   none      OVS 1.7+
       reg6       4       yes    yes   none      OVS 1.7+
       reg7       4       yes    yes   none      OVS 1.7+
       reg8       4       yes    yes   none      OVS 2.6+
       reg9       4       yes    yes   none      OVS 2.6+
       reg10      4       yes    yes   none      OVS 2.6+
       reg11      4       yes    yes   none      OVS 2.6+
       reg12      4       yes    yes   none      OVS 2.6+
       reg13      4       yes    yes   none      OVS 2.6+
       reg14      4       yes    yes   none      OVS 2.6+
       reg15      4       yes    yes   none      OVS 2.6+
       xreg0      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg1      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg2      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg3      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg4      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg5      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg6      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xreg7      8       yes    yes   none      OF 1.3+ and OVS 2.4+
       xxreg0     16      yes    yes   none      OVS 2.6+
       xxreg1     16      yes    yes   none      OVS 2.6+
       xxreg2     16      yes    yes   none      OVS 2.6+
       xxreg3     16      yes    yes   none      OVS 2.6+

       These fields give an OpenFlow switch space for temporary storage
       while the pipeline is running. Whereas metadata fields can have a
       meaningful initial value and can persist across some hops across
       OpenFlow switches, registers are always initially 0 and their
       values never persist across inter-switch hops (not even across
       patch ports).

       OpenFlow Metadata Field
       Name:            metadata
       Width:           64 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_METADATA (2) since OpenFlow 1.2 and Open
                        vSwitch 1.8
       NXM:             none

       This field is the oldest standardized OpenFlow register field,
       introduced in OpenFlow 1.1. It was introduced to model the
       limited number of user-defined bits that some ASIC-based switches
       can carry through their pipelines. Because of hardware
       limitations, OpenFlow allows switches to support writing and
       masking only an implementation-defined subset of bits, even no
       bits at all. The Open vSwitch software switch always supports all
       64 bits, but of course an Open vSwitch port to an ASIC would have
       the same restriction as the ASIC itself.

       This field has an OXM code point, but OpenFlow 1.4 and earlier
       allow it to be modified only with a specialized instruction, not
       with a ``set-field’’ action. OpenFlow 1.5 removes this
       restriction. Open vSwitch does not enforce this restriction,
       regardless of OpenFlow version.

       Register 0 Field
       Name:            reg0
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_REG0 (0) since Open vSwitch 1.1

       This is the first of several Open vSwitch registers, all of which
       have the same properties. Open vSwitch 1.1 introduced registers
       0, 1, 2, and 3, version 1.3 added register 4, version 1.7 added
       registers 5, 6, and 7, and version 2.6 added registers 8 through
       15.

       Extended Register 0 Field
       Name:            xreg0
       Width:           64 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_PKT_REG0 (0) since OpenFlow 1.3 and Open
                        vSwitch 2.4
       NXM:             none

       This is the first of the registers introduced in OpenFlow 1.5.
       OpenFlow 1.5 calls these fields just the ``packet registers,’’
       but Open vSwitch already had 32-bit registers by that name, so
       Open vSwitch uses the name ``extended registers’’ in an attempt
       to reduce confusion. The standard allows for up to 128 registers,
       each 64 bits wide, but Open vSwitch only implements 4 (in
       versions 2.4 and 2.5) or 8 (in version 2.6 and later).

       Each of the 64-bit extended registers overlays two of the 32-bit
       registers: xreg0 overlays reg0 and reg1, with reg0 supplying the
       most-significant bits of xreg0 and reg1 the least-significant.
       Similarly, xreg1 overlays reg2 and reg3, and so on.

       The OpenFlow specification says, ``In most cases, the packet
       registers can not be matched in tables, i.e. they usually can not
       be used in the flow entry match structure’’ [OpenFlow 1.5,
       section 7.2.3.10], but there is no reason for a software switch
       to impose such a restriction, and Open vSwitch does not.

       Double-Extended Register 0 Field
       Name:            xxreg0
       Width:           128 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   none
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_XXREG0 (111) since Open vSwitch 2.6

       This is the first of the double-extended registers introduce in
       Open vSwitch 2.6. Each of the 128-bit extended registers overlays
       four of the 32-bit registers: xxreg0 overlays reg0 through reg3,
       with reg0 supplying the most-significant bits of xxreg0 and reg3
       the least-significant. xxreg1 similarly overlays reg4 through
       reg7, and so on.

LAYER 2 (ETHERNET) FIELDS         top

   Summary:
       Name                   Bytes   Mask   RW?   Prereqs    NXM/OXM Support
       ─────────────────────  ──────  ─────  ────  ─────────  ─────────────────────
       eth_src aka dl_src     6       yes    yes   Ethernet   OF 1.2+ and OVS 1.1+
       eth_dst aka dl_dst     6       yes    yes   Ethernet   OF 1.2+ and OVS 1.1+
       eth_type aka dl_type   2       no     no    Ethernet   OF 1.2+ and OVS 1.1+

       Ethernet is the only layer-2 protocol that Open vSwitch supports.
       As with most software, Open vSwitch and OpenFlow regard an
       Ethernet frame to begin with the 14-byte header and end with the
       final byte of the payload; that is, the frame check sequence is
       not considered part of the frame.

       Ethernet Source Field
       Name:            eth_src (aka dl_src)
       Width:           48 bits
       Format:          Ethernet
       Masking:         arbitrary bitwise masks
       Prerequisites:   Ethernet
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_ETH_SRC (4) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_ETH_SRC (2) since Open vSwitch 1.1

       The Ethernet source address:

          Ethernet
        <---------->
        48  48   16
       +---+---+----+
       |dst|src|type| ...
       +---+---+----+

       Ethernet Destination Field
       Name:            eth_dst (aka dl_dst)
       Width:           48 bits
       Format:          Ethernet
       Masking:         arbitrary bitwise masks
       Prerequisites:   Ethernet
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_ETH_DST (3) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_ETH_DST (1) since Open vSwitch 1.1

       The Ethernet destination address:

          Ethernet
        <---------->
        48  48   16
       +---+---+----+
       |dst|src|type| ...
       +---+---+----+

       Open vSwitch 1.8 and later support arbitrary masks for source
       and/or destination. Earlier versions only support masking the
       destination with the following masks:

              01:00:00:00:00:00
                     Match only the multicast bit. Thus,
                     dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 matches
                     all multicast (including broadcast) Ethernet
                     packets, and
                     dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 matches
                     all unicast Ethernet packets.

              fe:ff:ff:ff:ff:ff
                     Match all bits except the multicast bit. This is
                     probably not useful.

              ff:ff:ff:ff:ff:ff
                     Exact match (equivalent to omitting the mask).

              00:00:00:00:00:00
                     Wildcard all bits (equivalent to dl_dst=*).

       Ethernet Type Field
       Name:            eth_type (aka dl_type)
       Width:           16 bits
       Format:          hexadecimal
       Masking:         not maskable
       Prerequisites:   Ethernet
       Access:          read-only
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_ETH_TYPE (5) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_ETH_TYPE (3) since Open vSwitch 1.1

       The most commonly seen Ethernet frames today use a format called
       ``Ethernet II,’’ in which the last two bytes of the Ethernet
       header specify the Ethertype. For such a frame, this field is
       copied from those bytes of the header, like so:

             Ethernet
        <---------------->
        48  48      16
       +---+---+----------+
       |dst|src|   type   | ...
       +---+---+----------+
                ≥0x600

       Every Ethernet type has a value 0x600 (1,536) or greater. When
       the last two bytes of the Ethernet header have a value too small
       to be an Ethernet type, then the value found there is the total
       length of the frame in bytes, excluding the Ethernet header. An
       802.2 LLC header typically follows the Ethernet header. OpenFlow
       and Open vSwitch only support LLC headers with DSAP and SSAP 0xaa
       and control byte 0x03, which indicate that a SNAP header follows
       the LLC header. In turn, OpenFlow and Open vSwitch only support a
       SNAP header with organization 0x000000. In such a case, this
       field is copied from the type field in the SNAP header, like
       this:

           Ethernet           LLC                SNAP
        <------------>   <------------>   <----------------->
        48  48    16      8    8    8        24        16
       +---+---+------+ +----+----+----+ +--------+----------+
       |dst|src| type | |DSAP|SSAP|cntl| |  org   |   type   | ...
       +---+---+------+ +----+----+----+ +--------+----------+
                <0x600   0xaa 0xaa 0x03   0x000000 ≥0x600

       When an 802.1Q header is inserted after the Ethernet source and
       destination, this field is populated with the encapsulated
       Ethertype, not the 802.1Q Ethertype. With an Ethernet II inner
       frame, the result looks like this:

        Ethernet     802.1Q     Ethertype
        <------>   <-------->   <-------->
         48  48      16   16        16
       +----+---+ +------+---+ +----------+
       |dst |src| | TPID |TCI| |   type   | ...
       +----+---+ +------+---+ +----------+
                   0x8100       ≥0x600

       LLC and SNAP encapsulation look like this with an 802.1Q header:

        Ethernet     802.1Q     Ethertype        LLC                SNAP
        <------>   <-------->   <------->   <------------>   <----------------->
         48  48      16   16       16        8    8    8        24        16
       +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
       |dst |src| | TPID |TCI| |  type   | |DSAP|SSAP|cntl| |  org   |   type   | ...
       +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
                   0x8100        <0x600     0xaa 0xaa 0x03   0x000000 ≥0x600

       When a packet doesn’t match any of the header formats described
       above, Open vSwitch and OpenFlow set this field to 0x5ff
       (OFP_DL_TYPE_NOT_ETH_TYPE).

VLAN FIELDS         top

   Summary:
       Name          Bytes             Mask   RW?   Prereqs    NXM/OXM Support
       ────────────  ────────────────  ─────  ────  ─────────  ─────────────────────
       dl_vlan       2 (low 12 bits)   no     yes   Ethernet
       dl_vlan_pcp   1 (low 3 bits)    no     yes   Ethernet
       vlan_vid      2 (low 12 bits)   yes    yes   Ethernet   OF 1.2+ and OVS 1.7+
       vlan_pcp      1 (low 3 bits)    no     yes   VLAN VID   OF 1.2+ and OVS 1.7+
       vlan_tci      2                 yes    yes   Ethernet   OVS 1.1+

       The 802.1Q VLAN header causes more trouble than any other 4 bytes
       in networking. OpenFlow 1.0, 1.1, and 1.2+ all treat VLANs
       differently. Open vSwitch extensions add another variant to the
       mix. Open vSwitch reconciles all four treatments as best it can.

   VLAN Header Format
       An 802.1Q VLAN header consists of two 16-bit fields:

          TPID        TCI
        <-------> <--------->
           16      3   1  12
       +---------+---+---+---+
       |Ethertype|PCP|CFI|VID|
       +---------+---+---+---+
         0x8100        0

       The first 16 bits of the VLAN header, the TPID (Tag Protocol
       IDentifier), is an Ethertype. When the VLAN header is inserted
       just after the source and destination MAC addresses in a
       Ethertype frame, the TPID serves to identify the presence of the
       VLAN. The standard TPID, the only one that Open vSwitch supports,
       is 0x8100. OpenFlow 1.0 explicitly supports only TPID 0x8100.
       OpenFlow 1.1, but not earlier or later versions, also requires
       support for TPID 0x88a8 (Open vSwitch does not support this).
       OpenFlow 1.2 through 1.5 do not require support for specific
       TPIDs (the ``push vlan header’’ action does say that only 0x8100
       and 0x88a8 should be pushed). No version of OpenFlow provides a
       way to distinguish or match on the TPID.

       The remaining 16 bits of the VLAN header, the TCI (Tag Control
       Information), is subdivided into three subfields:

              •      PCP (Priority Control Point), is a 3-bit 802.1p
                     priority. The lowest priority is value 1, the
                     second-lowest is value 0, and priority increases
                     from 2 up to highest priority 7.

              •      CFI (Canonical Format Indicator), is a 1-bit field.
                     On an Ethernet network, its value is always 0. This
                     led to it later being repurposed under the name DEI
                     (Drop Eligibility Indicator). By either name,
                     OpenFlow and Open vSwitch don’t provide any way to
                     match or set this bit.

              •      VID (VLAN IDentifier), is a 12-bit VLAN. If the VID
                     is 0, then the frame is not part of a VLAN. In that
                     case, the VLAN header is called a priority tag
                     because it is only meaningful for assigning the
                     frame a priority. VID 0xfff (4,095) is reserved.

       See eth_type for illustrations of a complete Ethernet frame with
       802.1Q tag included.

   Multiple VLANs
       Open vSwitch can match only a single VLAN header. If more than
       one VLAN header is present, then eth_type holds the TPID of the
       inner VLAN header. Open vSwitch stops parsing the packet after
       the inner TPID, so matching further into the packet (e.g. on the
       inner TCI or L3 fields) is not possible.

       OpenFlow only directly supports matching a single VLAN header. In
       OpenFlow 1.1 or later, one OpenFlow table can match on the
       outermost VLAN header and pop it off, and a later OpenFlow table
       can match on the next outermost header. Open vSwitch does not
       support this.

   VLAN Field Details
       The four variants have three different levels of expressiveness:
       OpenFlow 1.0 and 1.1 VLAN matching are less powerful than
       OpenFlow 1.2+ VLAN matching, which is less powerful than Open
       vSwitch extension VLAN matching.

   OpenFlow 1.0 VLAN Fields
       OpenFlow 1.0 uses two fields, called dl_vlan and dl_vlan_pcp,
       each of which can be either exact-matched or wildcarded, to
       specify VLAN matches:

              •      When both dl_vlan and dl_vlan_pcp are wildcarded,
                     the flow matches packets without an 802.1Q header
                     or with any 802.1Q header.

              •      The match dl_vlan=0xffff causes a flow to match
                     only packets without an 802.1Q header. Such a flow
                     should also wildcard dl_vlan_pcp, since a packet
                     without an 802.1Q header does not have a PCP.
                     OpenFlow does not specify what to do if a match on
                     PCP is actually present, but Open vSwitch ignores
                     it.

              •      Otherwise, the flow matches only packets with an
                     802.1Q header. If dl_vlan is not wildcarded, then
                     the flow only matches packets with the VLAN ID
                     specified in dl_vlan’s low 12 bits. If dl_vlan_pcp
                     is not wildcarded, then the flow only matches
                     packets with the priority specified in
                     dl_vlan_pcp’s low 3 bits.

                     OpenFlow does not specify how to interpret the high
                     4 bits of dl_vlan or the high 5 bits of
                     dl_vlan_pcp. Open vSwitch ignores them.

   OpenFlow 1.1 VLAN Fields
       VLAN matching in OpenFlow 1.1 is similar to OpenFlow 1.0. The one
       refinement is that when dl_vlan matches on 0xfffe (OFVPID_ANY),
       the flow matches only packets with an 802.1Q header, with any
       VLAN ID. If dl_vlan_pcp is wildcarded, the flow matches any
       packet with an 802.1Q header, regardless of VLAN ID or priority.
       If dl_vlan_pcp is not wildcarded, then the flow only matches
       packets with the priority specified in dl_vlan_pcp’s low 3 bits.

       OpenFlow 1.1 uses the name OFPVID_NONE, instead of OFP_VLAN_NONE,
       for a dl_vlan of 0xffff, but it has the same meaning.

       In OpenFlow 1.1, Open vSwitch reports error OFPBMC_BAD_VALUE for
       an attempt to match on dl_vlan between 4,096 and 0xfffd,
       inclusive, or dl_vlan_pcp greater than 7.

   OpenFlow 1.2 VLAN Fields
       OpenFlow 1.2+ VLAN ID Field
       Name:            vlan_vid
       Width:           16 bits (only the least-significant 12 bits may be nonzero)
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   Ethernet
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_VLAN_VID (6) since OpenFlow 1.2 and Open vSwitch 1.7
       NXM:             none

       The OpenFlow standard describes this field as consisting of
       ``12+1’’ bits. On ingress, its value is 0 if no 802.1Q header is
       present, and otherwise it holds the VLAN VID in its least
       significant 12 bits, with bit 12 (0x1000 aka OFPVID_PRESENT) also
       set to 1. The three most significant bits are always zero:

        OXM_OF_VLAN_VID
        <------------->
         3  1     12
       +---+--+--------+
       |   |P |VLAN ID |
       +---+--+--------+
         0

       As a consequence of this field’s format, one may use it to match
       the VLAN ID in all of the ways available with the OpenFlow 1.0
       and 1.1 formats, and a few new ways:

              Fully wildcarded
                     Matches any packet, that is, one without an 802.1Q
                     header or with an 802.1Q header with any TCI value.

              Value 0x0000 (OFPVID_NONE), mask 0xffff (or no mask)
                     Matches only packets without an 802.1Q header.

              Value 0x1000, mask 0x1000
                     Matches any packet with an 802.1Q header,
                     regardless of VLAN ID.

              Value 0x1009, mask 0xffff (or no mask)
                     Match only packets with an 802.1Q header with VLAN
                     ID 9.

              Value 0x1001, mask 0x1001
                     Matches only packets that have an 802.1Q header
                     with an odd-numbered VLAN ID. (This is just an
                     example; one can match on any desired VLAN ID bit
                     pattern.)

       OpenFlow 1.2+ VLAN Priority Field
       Name:            vlan_pcp
       Width:           8 bits (only the least-significant 3 bits may be nonzero)
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   VLAN VID
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_VLAN_PCP (7) since OpenFlow 1.2 and Open vSwitch
                        1.7
       NXM:             none

       The 3 least significant bits may be used to match the PCP bits in
       an 802.1Q header. Other bits are always zero:

        OXM_OF_VLAN_VID
        <------------->
           5       3
       +--------+------+
       |  zero  | PCP  |
       +--------+------+
           0

       This field may only be used when vlan_vid is not wildcarded and
       does not exact match on 0 (which only matches when there is no
       802.1Q header).

       See VLAN Comparison Chart, below, for some examples.

   Open vSwitch Extension VLAN Field
       The vlan_tci extension can describe more kinds of VLAN matches
       than the other variants. It is also simpler than the other
       variants.

       VLAN TCI Field
       Name:            vlan_tci
       Width:           16 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   Ethernet
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             none
       NXM:             NXM_OF_VLAN_TCI (4) since Open vSwitch 1.1

       For a packet without an 802.1Q header, this field is zero. For a
       packet with an 802.1Q header, this field is the TCI with the bit
       in CFI’s position (marked P for ``present’’ below) forced to 1.
       Thus, for a packet in VLAN 9 with priority 7, it has the value
       0xf009:

        NXM_VLAN_TCI
        <---------->
         3   1   12
       +----+--+----+
       |PCP |P |VID |
       +----+--+----+
         7   1   9

       Usage examples:

              vlan_tci=0
                     Match packets without an 802.1Q header.

              vlan_tci=0x1000/0x1000
                     Match packets with an 802.1Q header, regardless of
                     VLAN and priority values.

              vlan_tci=0xf123
                     Match packets tagged with priority 7 in VLAN 0x123.

              vlan_tci=0x1123/0x1fff
                     Match packets tagged with VLAN 0x123 (and any
                     priority).

              vlan_tci=0x5000/0xf000
                     Match packets tagged with priority 2 (in any VLAN).

              vlan_tci=0/0xfff
                     Match packets with no 802.1Q header or tagged with
                     VLAN 0 (and any priority).

              vlan_tci=0x5000/0xe000
                     Match packets with no 802.1Q header or tagged with
                     priority 2 (in any VLAN).

              vlan_tci=0/0xefff
                     Match packets with no 802.1Q header or tagged with
                     VLAN 0 and priority 0.

       See VLAN Comparison Chart, below, for more examples.

   VLAN Comparison Chart
       The following table describes each of several possible matching
       criteria on 802.1Q header may be expressed with each variation of
       the VLAN matching fields:

       Criteria   OpenFlow 1.0   OpenFlow 1.1   OpenFlow 1.2+         NXM
       ─────────  ─────────────  ─────────────  ──────────────  ──────────
            [1]    ????/1,??/?    ????/1,??/?    0000/0000,--   0000/0000
            [2]    ffff/0,??/?    ffff/0,??/?    0000/ffff,--   0000/ffff
            [3]    0xxx/0,??/1    0xxx/0,??/1    1xxx/ffff,--   1xxx/1fff
            [4]    ????/1,0y/0    fffe/0,0y/0    1000/1000,0y   z000/f000
            [5]    0xxx/0,0y/0    0xxx/0,0y/0    1xxx/ffff,0y   zxxx/ffff
            [6]      (none)         (none)       1001/1001,--   1001/1001
            [7]      (none)         (none)         (none)       3000/3000
            [8]      (none)         (none)         (none)       0000/0fff
            [9]      (none)         (none)         (none)       0000/f000
           [10]      (none)         (none)         (none)       0000/efff

       All numbers in the table are expressed in hexadecimal. The
       columns in the table are interpreted as follows:

              Criteria
                     See the list below.

              OpenFlow 1.0
              OpenFlow 1.1
                   wwww/x,yy/z means VLAN ID match value wwww with
                   wildcard bit x and VLAN PCP match value yy with
                   wildcard bit z. ? means that the given bits are
                   ignored (and conventionally 0 for wwww or yy,
                   conventionally 1 for x or z). ``(none)’’ means that
                   OpenFlow 1.0 (or 1.1) cannot match with these
                   criteria.

              OpenFlow 1.2+
                   xxxx/yyyy,zz means vlan_vid with value xxxx and mask
                   yyyy, and vlan_pcp (which is not maskable) with value
                   zz. -- means that vlan_pcp is omitted. ``(none)’’
                   means that OpenFlow 1.2 cannot match with these
                   criteria.

              NXM  xxxx/yyyy means vlan_tci with value xxxx and mask
                   yyyy.

       The matching criteria described by the table are:

              [1]    Matches any packet, that is, one without an 802.1Q
                     header or with an 802.1Q header with any TCI value.

              [2]    Matches only packets without an 802.1Q header.

                     OpenFlow 1.0 doesn’t define the behavior if dl_vlan
                     is set to 0xffff and dl_vlan_pcp is not wildcarded.
                     (Open vSwitch always ignores dl_vlan_pcp when
                     dl_vlan is set to 0xffff.)

                     OpenFlow 1.1 says explicitly to ignore dl_vlan_pcp
                     when dl_vlan is set to 0xffff.

                     OpenFlow 1.2 doesn’t say how to interpret a match
                     with vlan_vid value 0 and a mask with
                     OFPVID_PRESENT (0x1000) set to 1 and some other
                     bits in the mask set to 1 also. Open vSwitch
                     interprets it the same way as a mask of 0x1000.

                     Any NXM match with vlan_tci value 0 and the CFI bit
                     set to 1 in the mask is equivalent to the one
                     listed in the table.

              [3]    Matches only packets that have an 802.1Q header
                     with VID xxx (and any PCP).

              [4]    Matches only packets that have an 802.1Q header
                     with PCP y (and any VID).

                     OpenFlow 1.0 doesn’t clearly define the behavior
                     for this case. Open vSwitch implements it this way.

                     In the NXM value, z equals (y << 1) | 1.

              [5]    Matches only packets that have an 802.1Q header
                     with VID xxx and PCP y.

                     In the NXM value, z equals (y << 1) | 1.

              [6]    Matches only packets that have an 802.1Q header
                     with an odd-numbered VID (and any PCP). Only
                     possible with OpenFlow 1.2 and NXM. (This is just
                     an example; one can match on any desired VID bit
                     pattern.)

              [7]    Matches only packets that have an 802.1Q header
                     with an odd-numbered PCP (and any VID). Only
                     possible with NXM. (This is just an example; one
                     can match on any desired VID bit pattern.)

              [8]    Matches packets with no 802.1Q header or with an
                     802.1Q header with a VID of 0. Only possible with
                     NXM.

              [9]    Matches packets with no 802.1Q header or with an
                     802.1Q header with a PCP of 0. Only possible with
                     NXM.

              [10]   Matches packets with no 802.1Q header or with an
                     802.1Q header with both VID and PCP of 0. Only
                     possible with NXM.

LAYER 2.5: MPLS FIELDS         top

   Summary:
       Name         Bytes             Mask   RW?   Prereqs   NXM/OXM Support
       ───────────  ────────────────  ─────  ────  ────────  ──────────────────────
       mpls_label   4 (low 20 bits)   no     yes   MPLS      OF 1.2+ and OVS 1.11+
       mpls_tc      1 (low 3 bits)    no     yes   MPLS      OF 1.2+ and OVS 1.11+
       mpls_bos     1 (low 1 bits)    no     no    MPLS      OF 1.3+ and OVS 1.11+
       mpls_ttl     1                 no     yes   MPLS      OVS 2.6+

       One or more MPLS headers (more commonly called MPLS labels)
       follow an Ethernet type field that specifies an MPLS Ethernet
       type [RFC 3032]. Ethertype 0x8847 is used for all unicast.
       Multicast MPLS is divided into two specific classes, one of which
       uses Ethertype 0x8847 and the other 0x8848 [RFC 5332].

       The most common overall packet format is Ethernet II, shown below
       (SNAP encapsulation may be used but is not ordinarily seen in
       Ethernet networks):

           Ethernet           MPLS
        <------------>   <------------>
        48  48    16      20   3  1  8
       +---+---+------+ +-----+--+-+---+
       |dst|src| type | |label|TC|S|TTL| ...
       +---+---+------+ +-----+--+-+---+
                0x8847

       MPLS can be encapsulated inside an 802.1Q header, in which case
       the combination looks like this:

        Ethernet     802.1Q     Ethertype        MPLS
        <------>   <-------->   <------->   <------------>
         48  48      16   16       16        20   3  1  8
       +----+---+ +------+---+ +---------+ +-----+--+-+---+
       |dst |src| | TPID |TCI| |  type   | |label|TC|S|TTL| ...
       +----+---+ +------+---+ +---------+ +-----+--+-+---+
                   0x8100        0x8847

       The fields within an MPLS label are:

              Label, 20 bits.
                     An identifier.

              Traffic control (TC), 3 bits.
                     Used for quality of service.

              Bottom of stack (BOS), 1 bit (labeled just ``S’’ above).
                     0 indicates that another MPLS label follows this
                     one.

                     1 indicates that this MPLS label is the last one in
                     the stack, so that some other protocol follows this
                     one.

              Time to live (TTL), 8 bits.
                     Each hop across an MPLS network decrements the TTL
                     by 1. If it reaches 0, the packet is discarded.

                     OpenFlow does not make the MPLS TTL available as a
                     match field, but actions are available to set and
                     decrement the TTL. Open vSwitch 2.6 and later makes
                     the MPLS TTL available as an extension.

   MPLS Label Stacks
       Unlike the other encapsulations supported by OpenFlow and Open
       vSwitch, MPLS labels are routinely used in ``stacks’’ two or
       three deep and sometimes even deeper. Open vSwitch currently
       supports up to three labels.

       The OpenFlow specification only supports matching on the
       outermost MPLS label at any given time. To match on the second
       label, one must first ``pop’’ the outer label and advance to
       another OpenFlow table, where the inner label may be matched. To
       match on the third label, one must pop the two outer labels, and
       so on.

   MPLS Inner Protocol
       Unlike all other forms of encapsulation that Open vSwitch and
       OpenFlow support, an MPLS label does not indicate what inner
       protocol it encapsulates. Different deployments determine the
       inner protocol in different ways [RFC 3032]:

              •      A few reserved label values do indicate an inner
                     protocol. Label 0, the ``IPv4 Explicit NULL
                     Label,’’ indicates inner IPv4. Label 2, the ``IPv6
                     Explicit NULL Label,’’ indicates inner IPv6.

              •      Some deployments use a single inner protocol
                     consistently.

              •      In some deployments, the inner protocol must be
                     inferred from the innermost label.

              •      In some deployments, the inner protocol must be
                     inferred from the innermost label and the
                     encapsulated data, e.g. to distinguish between
                     inner IPv4 and IPv6 based on whether the first
                     nibble of the inner protocol data are 4 or 6.
                     OpenFlow and Open vSwitch do not currently support
                     these cases.

       Open vSwitch and OpenFlow do not infer the inner protocol, even
       if reserved label values are in use. Instead, the flow table must
       specify the inner protocol at the time it pops the bottommost
       MPLS label, using the Ethertype argument to the pop_mpls action.

   Field Details
       MPLS Label Field
       Name:            mpls_label
       Width:           32 bits (only the least-significant 20 bits may be nonzero)
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   MPLS
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_MPLS_LABEL (34) since OpenFlow 1.2 and Open vSwitch
                        1.11
       NXM:             none

       The least significant 20 bits hold the ``label’’ field from the
       MPLS label. Other bits are zero:

        OXM_OF_MPLS_LABEL
        <--------------->
           12       20
       +--------+--------+
       |  zero  | label  |
       +--------+--------+
           0

       Most label values are available for any use by deployments.
       Values under 16 are reserved.

       MPLS Traffic Class Field
       Name:            mpls_tc
       Width:           8 bits (only the least-significant 3 bits may be nonzero)
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   MPLS
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_MPLS_TC (35) since OpenFlow 1.2 and Open vSwitch
                        1.11
       NXM:             none

       The least significant 3 bits hold the TC field from the MPLS
       label. Other bits are zero:

        OXM_OF_MPLS_TC
        <------------>
           5       3
       +--------+-----+
       |  zero  | TC  |
       +--------+-----+
           0

       This field is intended for use for Quality of Service (QoS) and
       Explicit Congestion Notification purposes, but its particular
       interpretation is deployment specific.

       Before 2009, this field was named EXP and reserved for
       experimental use [RFC 5462].

       MPLS Bottom of Stack Field
       Name:            mpls_bos
       Width:           8 bits (only the least-significant 1 bits may be nonzero)
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   MPLS
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_MPLS_BOS (36) since OpenFlow 1.3 and Open vSwitch
                        1.11
       NXM:             none

       The least significant bit holds the BOS field from the MPLS
       label. Other bits are zero:

        OXM_OF_MPLS_BOS
        <------------->
           7       1
       +--------+------+
       |  zero  | BOS  |
       +--------+------+
           0

       This field is useful as part of processing a series of incoming
       MPLS labels. A flow that includes a pop_mpls action should
       generally match on mpls_bos:

              •      When mpls_bos is 0, there is another MPLS label
                     following this one, so the Ethertype passed to
                     pop_mpls should be an MPLS Ethertype. For example:
                     table=0, dl_type=0x8847, mpls_bos=0,
                     actions=pop_mpls:0x8847, goto_table:1

              •      When mpls_bos is 1, this MPLS label is the last
                     one, so the Ethertype passed to pop_mpls should be
                     a non-MPLS Ethertype such as IPv4. For example:
                     table=1, dl_type=0x8847, mpls_bos=1,
                     actions=pop_mpls:0x0800, goto_table:2

       MPLS Time-to-Live Field
       Name:            mpls_ttl
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   MPLS
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_MPLS_TTL (30) since Open vSwitch 2.6

       Holds the 8-bit time-to-live field from the MPLS label:

        NXM_NX_MPLS_TTL
        <------------->
               8
       +---------------+
       |      TTL      |
       +---------------+

LAYER 3: IPV4 AND IPV6 FIELDS         top

   Summary:
       Name                    Bytes             Mask   RW?   Prereqs     NXM/OXM Support
       ──────────────────────  ────────────────  ─────  ────  ──────────  ─────────────────────
       ip_src aka nw_src       4                 yes    yes   IPv4        OF 1.2+ and OVS 1.1+
       ip_dst aka nw_dst       4                 yes    yes   IPv4        OF 1.2+ and OVS 1.1+
       ipv6_src                16                yes    yes   IPv6        OF 1.2+ and OVS 1.1+
       ipv6_dst                16                yes    yes   IPv6        OF 1.2+ and OVS 1.1+
       ipv6_label              4 (low 20 bits)   yes    yes   IPv6        OF 1.2+ and OVS 1.4+
       nw_proto aka ip_proto   1                 no     no    IPv4/IPv6   OF 1.2+ and OVS 1.1+
       nw_ttl                  1                 no     yes   IPv4/IPv6   OVS 1.4+
       ip_frag aka nw_frag     1 (low 2 bits)    yes    no    IPv4/IPv6   OVS 1.3+
       nw_tos                  1                 no     yes   IPv4/IPv6   OVS 1.1+
       ip_dscp                 1 (low 6 bits)    no     yes   IPv4/IPv6   OF 1.2+ and OVS 1.7+
       nw_ecn aka ip_ecn       1 (low 2 bits)    no     yes   IPv4/IPv6   OF 1.2+ and OVS 1.4+

   IPv4 Specific Fields
       These fields are applicable only to IPv4 flows, that is, flows
       that match on the IPv4 Ethertype 0x0800.

       IPv4 Source Address Field
       Name:            ip_src (aka nw_src)
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   IPv4
       Access:          read/write
       OpenFlow 1.0:    yes (CIDR match only)
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_IPV4_SRC (11) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_IP_SRC (7) since Open vSwitch 1.1

       The source address from the IPv4 header:

          Ethernet            IPv4
        <----------->   <--------------->
        48  48   16           8   32  32
       +---+---+-----+ +---+-----+---+---+
       |dst|src|type | |...|proto|src|dst| ...
       +---+---+-----+ +---+-----+---+---+
                0x800

       For historical reasons, in an ARP or RARP flow, Open vSwitch
       interprets matches on nw_src as actually referring to the ARP
       SPA.

       IPv4 Destination Address Field
       Name:            ip_dst (aka nw_dst)
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   IPv4
       Access:          read/write
       OpenFlow 1.0:    yes (CIDR match only)
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_IPV4_DST (12) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_IP_DST (8) since Open vSwitch 1.1

       The destination address from the IPv4 header:

          Ethernet            IPv4
        <----------->   <--------------->
        48  48   16           8   32  32
       +---+---+-----+ +---+-----+---+---+
       |dst|src|type | |...|proto|src|dst| ...
       +---+---+-----+ +---+-----+---+---+
                0x800

       For historical reasons, in an ARP or RARP flow, Open vSwitch
       interprets matches on nw_dst as actually referring to the ARP
       TPA.

   IPv6 Specific Fields
       These fields apply only to IPv6 flows, that is, flows that match
       on the IPv6 Ethertype 0x86dd.

       IPv6 Source Address Field
       Name:            ipv6_src
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   IPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_IPV6_SRC (26) since OpenFlow 1.2 and Open
                        vSwitch 1.1
       NXM:             NXM_NX_IPV6_SRC (19) since Open vSwitch 1.1

       The source address from the IPv6 header:

           Ethernet            IPv6
        <------------>   <-------------->
        48  48    16          8   128 128
       +---+---+------+ +---+----+---+---+
       |dst|src| type | |...|next|src|dst| ...
       +---+---+------+ +---+----+---+---+
                0x86dd

       Open vSwitch 1.8 added support for bitwise matching; earlier
       versions supported only CIDR masks.

       IPv6 Destination Address Field
       Name:            ipv6_dst
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   IPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_IPV6_DST (27) since OpenFlow 1.2 and Open
                        vSwitch 1.1
       NXM:             NXM_NX_IPV6_DST (20) since Open vSwitch 1.1

       The destination address from the IPv6 header:

           Ethernet            IPv6
        <------------>   <-------------->
        48  48    16          8   128 128
       +---+---+------+ +---+----+---+---+
       |dst|src| type | |...|next|src|dst| ...
       +---+---+------+ +---+----+---+---+
                0x86dd

       Open vSwitch 1.8 added support for bitwise matching; earlier
       versions supported only CIDR masks.

       IPv6 Flow Label Field
       Name:            ipv6_label
       Width:           32 bits (only the least-significant 20 bits may be nonzero)
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   IPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_IPV6_FLABEL (28) since OpenFlow 1.2 and Open vSwitch
                        1.7
       NXM:             NXM_NX_IPV6_LABEL (27) since Open vSwitch 1.4

       The least significant 20 bits hold the flow label field from the
       IPv6 header. Other bits are zero:

        OXM_OF_IPV6_FLABEL
        <---------------->
           12       20
       +--------+---------+
       |  zero  |  label  |
       +--------+---------+
           0

   IPv4/IPv6 Fields
       These fields exist with at least approximately the same meaning
       in both IPv4 and IPv6, so they are treated as a single field for
       matching purposes. Any flow that matches on the IPv4 Ethertype
       0x0800 or the IPv6 Ethertype 0x86dd may match on these fields.

       IPv4/v6 Protocol Field
       Name:            nw_proto (aka ip_proto)
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   IPv4/IPv6
       Access:          read-only
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_IP_PROTO (10) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_IP_PROTO (6) since Open vSwitch 1.1

       Matches the IPv4 or IPv6 protocol type.

       For historical reasons, in an ARP or RARP flow, Open vSwitch
       interprets matches on nw_proto as actually referring to the ARP
       opcode. The ARP opcode is a 16-bit field, so for matching
       purposes ARP opcodes greater than 255 are treated as 0; this
       works adequately because in practice ARP and RARP only use
       opcodes 1 through 4.

       In the case of fragmented traffic, a difference exists in the way
       the field acts for IPv4 and IPv6 later fragments. For IPv6
       fragments with nonzero offset, nw_proto is set to the IPv6
       protocol type for fragments (44). Conversely, for IPv4 later
       fragments, the field is set based on the protocol type present in
       the header.

       IPv4/v6 TTL/Hop Limit Field
       Name:            nw_ttl
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   IPv4/IPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_IP_TTL (29) since Open vSwitch 1.4

       The main reason to match on the TTL or hop limit field is to
       detect whether a dec_ttl action will fail due to a TTL exceeded
       error. Another way that a controller can detect TTL exceeded is
       to listen for OFPR_INVALID_TTL ``packet-in’’ messages via
       OpenFlow.

       IPv4/v6 Fragment Bitmask Field
       Name:            ip_frag (aka nw_frag)
       Width:           8 bits (only the least-significant 2 bits may be nonzero)
       Format:          frag
       Masking:         arbitrary bitwise masks
       Prerequisites:   IPv4/IPv6
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXM_NX_IP_FRAG (26) since Open vSwitch 1.3

       Specifies what kinds of IP fragments or non-fragments to match.
       The value for this field is most conveniently specified as one of
       the following:

              no     Match only non-fragmented packets.

              yes    Matches all fragments.

              first  Matches only fragments with offset 0.

              later  Matches only fragments with nonzero offset.

              not_later
                     Matches non-fragmented packets and fragments with
                     zero offset.

       The field is internally formatted as 2 bits: bit 0 is 1 for an IP
       fragment with any offset (and otherwise 0), and bit 1 is 1 for an
       IP fragment with nonzero offset (and otherwise 0), like so:

        NXM_NX_IP_FRAG
        <------------>
         6     1    1
       +----+-----+---+
       |zero|later|any|
       +----+-----+---+
         0

       Even though 2 bits have 4 possible values, this field only uses 3
       of them:

              •      A packet that is not an IP fragment has value 0.

              •      A packet that is an IP fragment with offset 0 (the
                     first fragment) has bit 0 set and thus value 1.

              •      A packet that is an IP fragment with nonzero offset
                     has bits 0 and 1 set and thus value 3.

       The switch may reject matches against values that can never
       appear.

       It is important to understand how this field interacts with the
       OpenFlow fragment handling mode:

              •      In OFPC_FRAG_DROP mode, the OpenFlow switch drops
                     all IP fragments before they reach the flow table,
                     so every packet that is available for matching will
                     have value 0 in this field.

              •      Open vSwitch does not implement OFPC_FRAG_REASM
                     mode, but if it did then IP fragments would be
                     reassembled before they reached the flow table and
                     again every packet available for matching would
                     always have value 0.

              •      In OFPC_FRAG_NORMAL mode, all three values are
                     possible, but OpenFlow 1.0 says that fragments’
                     transport ports are always 0, even for the first
                     fragment, so this does not provide much extra
                     information.

              •      In OFPC_FRAG_NX_MATCH mode, all three values are
                     possible. For fragments with offset 0, Open vSwitch
                     makes L4 header information available.

       Thus, this field is likely to be most useful for an Open vSwitch
       switch configured in OFPC_FRAG_NX_MATCH mode. See the description
       of the set-frags command in ovs-ofctl(8), for more details.

     IPv4/IPv6 TOS Fields

       IPv4 and IPv6 contain a one-byte ``type of service’’ or TOS field
       that has the following format:

        type of service
        <------------->
           6       2
       +--------+------+
       |  DSCP  | ECN  |
       +--------+------+

       IPv4/v6 DSCP (Bits 2-7) Field
       Name:            nw_tos
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   IPv4/IPv6
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             none
       NXM:             NXM_OF_IP_TOS (5) since Open vSwitch 1.1

       This field is the TOS byte with the two ECN bits cleared to 0:

        NXM_OF_IP_TOS
        <----------->
          6      2
       +------+------+
       | DSCP | zero |
       +------+------+
                 0

       IPv4/v6 DSCP (Bits 0-5) Field
       Name:            ip_dscp
       Width:           8 bits (only the least-significant 6 bits may be nonzero)
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   IPv4/IPv6
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_IP_DSCP (8) since OpenFlow 1.2 and Open vSwitch
                        1.7
       NXM:             none

       This field is the TOS byte shifted right to put the DSCP bits in
       the 6 least-significant bits:

        OXM_OF_IP_DSCP
        <------------>
           2      6
       +-------+------+
       | zero  | DSCP |
       +-------+------+
           0

       IPv4/v6 ECN Field
       Name:            nw_ecn (aka ip_ecn)
       Width:           8 bits (only the least-significant 2 bits may be nonzero)
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   IPv4/IPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_IP_ECN (9) since OpenFlow 1.2 and Open vSwitch 1.7
       NXM:             NXM_NX_IP_ECN (28) since Open vSwitch 1.4

       This field is the TOS byte with the DSCP bits cleared to 0:

        OXM_OF_IP_ECN
        <----------->
           6      2
       +-------+-----+
       | zero  | ECN |
       +-------+-----+
           0

LAYER 3: ARP FIELDS         top

   Summary:
       Name      Bytes   Mask   RW?   Prereqs   NXM/OXM Support
       ────────  ──────  ─────  ────  ────────  ─────────────────────
       arp_op    2       no     yes   ARP       OF 1.2+ and OVS 1.1+
       arp_spa   4       yes    yes   ARP       OF 1.2+ and OVS 1.1+
       arp_tpa   4       yes    yes   ARP       OF 1.2+ and OVS 1.1+
       arp_sha   6       yes    yes   ARP       OF 1.2+ and OVS 1.1+
       arp_tha   6       yes    yes   ARP       OF 1.2+ and OVS 1.1+

       In theory, Address Resolution Protocol, or ARP, is a generic
       protocol generic protocol that can be used to obtain the hardware
       address that corresponds to any higher-level protocol address. In
       contemporary usage, ARP is used only in Ethernet networks to
       obtain the Ethernet address for a given IPv4 address. OpenFlow
       and Open vSwitch only support this usage of ARP. For this use
       case, an ARP packet has the following format, with the ARP fields
       exposed as Open vSwitch fields highlighted:

          Ethernet                      ARP
        <----------->   <---------------------------------->
        48  48   16     16   16    8   8  16 48  32  48  32
       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
       |dst|src|type | |hrd| pro |hln|pln|op|sha|spa|tha|tpa|
       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
                0x806    1  0x800  6   4

       The ARP fields are also used for RARP, the Reverse Address
       Resolution Protocol, which shares ARP’s wire format.

       ARP Opcode Field
       Name:            arp_op
       Width:           16 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ARP
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_ARP_OP (21) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_ARP_OP (15) since Open vSwitch 1.1

       Even though this is a 16-bit field, Open vSwitch does not support
       ARP opcodes greater than 255; it treats them to zero. This works
       adequately because in practice ARP and RARP only use opcodes 1
       through 4.

       ARP Source IPv4 Address Field
       Name:            arp_spa
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   ARP
       Access:          read/write
       OpenFlow 1.0:    yes (CIDR match only)
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_ARP_SPA (22) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_ARP_SPA (16) since Open vSwitch 1.1

       ARP Target IPv4 Address Field
       Name:            arp_tpa
       Width:           32 bits
       Format:          IPv4
       Masking:         arbitrary bitwise masks
       Prerequisites:   ARP
       Access:          read/write
       OpenFlow 1.0:    yes (CIDR match only)
       OpenFlow 1.1:    yes
       OXM:             OXM_OF_ARP_TPA (23) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_ARP_TPA (17) since Open vSwitch 1.1

       ARP Source Ethernet Address Field
       Name:            arp_sha
       Width:           48 bits
       Format:          Ethernet
       Masking:         arbitrary bitwise masks
       Prerequisites:   ARP
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_ARP_SHA (24) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_NX_ARP_SHA (17) since Open vSwitch 1.1

       ARP Target Ethernet Address Field
       Name:            arp_tha
       Width:           48 bits
       Format:          Ethernet
       Masking:         arbitrary bitwise masks
       Prerequisites:   ARP
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_ARP_THA (25) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_NX_ARP_THA (18) since Open vSwitch 1.1

LAYER 3: NSH FIELDS         top

   Summary:
       Name               Bytes             Mask   RW?   Prereqs   NXM/OXM Support
       ─────────────────  ────────────────  ─────  ────  ────────  ────────────────
       nsh_flags          1                 yes    yes   NSH       OVS 2.8+
       nsh_ttl            1                 no     yes   NSH       OVS 2.9+
       nsh_mdtype         1                 no     no    NSH       OVS 2.8+
       nsh_np             1                 no     no    NSH       OVS 2.8+
       nsh_spi aka nsp    4 (low 24 bits)   no     yes   NSH       OVS 2.8+
       nsh_si aka nsi     1                 no     yes   NSH       OVS 2.8+
       nsh_c1 aka nshc1   4                 yes    yes   NSH       OVS 2.8+
       nsh_c2 aka nshc2   4                 yes    yes   NSH       OVS 2.8+
       nsh_c3 aka nshc3   4                 yes    yes   NSH       OVS 2.8+
       nsh_c4 aka nshc4   4                 yes    yes   NSH       OVS 2.8+

       Service functions are widely deployed and essential in many
       networks. These service functions provide a range of features
       such as security, WAN acceleration, and server load balancing.
       Service functions may be instantiated at different points in the
       network infrastructure such as the wide area network, data
       center, and so forth.

       Prior to development of the SFC architecture [RFC 7665] and the
       protocol specified in this document, current service function
       deployment models have been relatively static and bound to
       topology for insertion and policy selection. Furthermore, they do
       not adapt well to elastic service environments enabled by
       virtualization.

       New data center network and cloud architectures require more
       flexible service function deployment models. Additionally, the
       transition to virtual platforms demands an agile service
       insertion model that supports dynamic and elastic service
       delivery. Specifically, the following functions are necessary:

              1.  The movement of service functions and application
                  workloads in the network.

              2.  The ability to easily bind service policy to granular
                  information, such as per-subscriber state.

              3.  The capability to steer traffic to the requisite
                  service function(s).

       The Network Service Header (NSH) specification defines a new data
       plane protocol, which is an encapsulation for service function
       chains. The NSH is designed to encapsulate an original packet or
       frame, and in turn be encapsulated by an outer transport
       encapsulation (which is used to deliver the NSH to NSH-aware
       network elements), as shown below:

       +-----------------------+----------------------------+---------------------+
       |Transport Encapsulation|Network Service Header (NSH)|Original Packet/Frame|
       +-----------------------+----------------------------+---------------------+

       The NSH is composed of the following elements:

              1.  Service Function Path identification.

              2.  Indication of location within a Service Function Path.

              3.  Optional, per packet metadata (fixed length or
                  variable).

       [RFC 7665] provides an overview of a service chaining
       architecture that clearly defines the roles of the various
       elements and the scope of a service function chaining
       encapsulation. Figure 3 of [RFC 7665] depicts the SFC
       architectural components after classification. The NSH is the SFC
       encapsulation referenced in [RFC 7665].

       flags field (2 bits) Field
       Name:            nsh_flags
       Width:           8 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_FLAGS (1) since Open vSwitch 2.8

       TTL field (6 bits) Field
       Name:            nsh_ttl
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_TTL (10) since Open vSwitch 2.9

       mdtype field (8 bits) Field
       Name:            nsh_mdtype
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   NSH
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_MDTYPE (2) since Open vSwitch 2.8

       np (next protocol) field (8 bits) Field
       Name:            nsh_np
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   NSH
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_NP (3) since Open vSwitch 2.8

       spi (service path identifier) field (24 bits) Field
       Name:            nsh_spi (aka nsp)
       Width:           32 bits (only the least-significant 24 bits may be nonzero)
       Format:          hexadecimal
       Masking:         not maskable
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_SPI (4) since Open vSwitch 2.8

       si (service index) field (8 bits) Field
       Name:            nsh_si (aka nsi)
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_SI (5) since Open vSwitch 2.8

       c1 (Network Platform Context) field (32 bits) Field
       Name:            nsh_c1 (aka nshc1)
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_C1 (6) since Open vSwitch 2.8

       c2 (Network Shared Context) field (32 bits) Field
       Name:            nsh_c2 (aka nshc2)
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_C2 (7) since Open vSwitch 2.8

       c3 (Service Platform Context) field (32 bits) Field
       Name:            nsh_c3 (aka nshc3)
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_C3 (8) since Open vSwitch 2.8

       c4 (Service Shared Context) field (32 bits) Field
       Name:            nsh_c4 (aka nshc4)
       Width:           32 bits
       Format:          hexadecimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   NSH
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             NXOXM_NSH_C4 (9) since Open vSwitch 2.8

LAYER 4: TCP, UDP, AND SCTP FIELDS         top

   Summary:
       Name                 Bytes             Mask   RW?   Prereqs   NXM/OXM Support
       ───────────────────  ────────────────  ─────  ────  ────────  ─────────────────────
       tcp_src aka tp_src   2                 yes    yes   TCP       OF 1.2+ and OVS 1.1+
       tcp_dst aka tp_dst   2                 yes    yes   TCP       OF 1.2+ and OVS 1.1+
       tcp_flags            2 (low 12 bits)   yes    no    TCP       OF 1.3+ and OVS 2.1+
       udp_src              2                 yes    yes   UDP       OF 1.2+ and OVS 1.1+
       udp_dst              2                 yes    yes   UDP       OF 1.2+ and OVS 1.1+
       sctp_src             2                 yes    yes   SCTP      OF 1.2+ and OVS 2.0+
       sctp_dst             2                 yes    yes   SCTP      OF 1.2+ and OVS 2.0+

       For matching purposes, no distinction is made whether these
       protocols are encapsulated within IPv4 or IPv6.

   TCP
       The following diagram shows TCP within IPv4. Open vSwitch also
       supports TCP in IPv6. Only TCP fields implemented as Open vSwitch
       fields are shown:

          Ethernet            IPv4                   TCP
        <----------->   <--------------->   <------------------->
        48  48   16           8   32  32    16  16       12
       +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
       |dst|src|type | |...|proto|src|dst| |src|dst|...|flags|...| ...
       +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
                0x800         6

       TCP Source Port Field
       Name:            tcp_src (aka tp_src)
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   TCP
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_TCP_SRC (13) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_TCP_SRC (9) since Open vSwitch 1.1

       Open vSwitch 1.6 added support for bitwise matching.

       TCP Destination Port Field
       Name:            tcp_dst (aka tp_dst)
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   TCP
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_TCP_DST (14) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_TCP_DST (10) since Open vSwitch 1.1

       Open vSwitch 1.6 added support for bitwise matching.

       TCP Flags Field
       Name:            tcp_flags
       Width:           16 bits (only the least-significant 12 bits may be nonzero)
       Format:          TCP flags
       Masking:         arbitrary bitwise masks
       Prerequisites:   TCP
       Access:          read-only
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             ONFOXM_ET_TCP_FLAGS (42) since OpenFlow 1.3 and Open
                        vSwitch 2.4; OXM_OF_TCP_FLAGS (42) since OpenFlow 1.5 and
                        Open vSwitch 2.3
       NXM:             NXM_NX_TCP_FLAGS (34) since Open vSwitch 2.1

       This field holds the TCP flags. TCP currently defines 9 flag
       bits. An additional 3 bits are reserved. For more information,
       see [RFC 793], [RFC 3168], and [RFC 3540].

       Matches on this field are most conveniently written in terms of
       symbolic names (given in the diagram below), each preceded by
       either + for a flag that must be set, or - for a flag that must
       be unset, without any other delimiters between the flags. Flags
       not mentioned are wildcarded. For example, tcp,tcp_flags=+syn-ack
       matches TCP SYNs that are not ACKs, and tcp,tcp_flags=+[200]
       matches TCP packets with the reserved [200] flag set. Matches can
       also be written as flags/mask, where flags and mask are 16-bit
       numbers in decimal or in hexadecimal prefixed by 0x.

       The flag bits are:

                 reserved      later RFCs         RFC 793
             <---------------> <--------> <--------------------->
         4     1     1     1   1   1   1   1   1   1   1   1   1
       +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
       |zero|[800]|[400]|[200]|NS|CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|
       +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
         0

   UDP
       The following diagram shows UDP within IPv4. Open vSwitch also
       supports UDP in IPv6. Only UDP fields that Open vSwitch exposes
       as fields are shown:

          Ethernet            IPv4              UDP
        <----------->   <--------------->   <--------->
        48  48   16           8   32  32    16  16
       +---+---+-----+ +---+-----+---+---+ +---+---+---+
       |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
       +---+---+-----+ +---+-----+---+---+ +---+---+---+
                0x800        17

       UDP Source Port Field
       Name:            udp_src
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   UDP
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_UDP_SRC (15) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_UDP_SRC (11) since Open vSwitch 1.1

       UDP Destination Port Field
       Name:            udp_dst
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   UDP
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_UDP_DST (16) since OpenFlow 1.2 and Open
                        vSwitch 1.7
       NXM:             NXM_OF_UDP_DST (12) since Open vSwitch 1.1

   SCTP
       The following diagram shows SCTP within IPv4. Open vSwitch also
       supports SCTP in IPv6. Only SCTP fields that Open vSwitch exposes
       as fields are shown:

          Ethernet            IPv4             SCTP
        <----------->   <--------------->   <--------->
        48  48   16           8   32  32    16  16
       +---+---+-----+ +---+-----+---+---+ +---+---+---+
       |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
       +---+---+-----+ +---+-----+---+---+ +---+---+---+
                0x800        132

       SCTP Source Port Field
       Name:            sctp_src
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   SCTP
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_SCTP_SRC (17) since OpenFlow 1.2 and Open
                        vSwitch 2.0
       NXM:             none

       SCTP Destination Port Field
       Name:            sctp_dst
       Width:           16 bits
       Format:          decimal
       Masking:         arbitrary bitwise masks
       Prerequisites:   SCTP
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_SCTP_DST (18) since OpenFlow 1.2 and Open
                        vSwitch 2.0
       NXM:             none

LAYER 4: ICMPV4 AND ICMPV6 FIELDS         top

   Summary:
       Name              Bytes   Mask   RW?   Prereqs      NXM/OXM Support
       ────────────────  ──────  ─────  ────  ───────────  ─────────────────────
       icmp_type         1       no     yes   ICMPv4       OF 1.2+ and OVS 1.1+
       icmp_code         1       no     yes   ICMPv4       OF 1.2+ and OVS 1.1+
       icmpv6_type       1       no     yes   ICMPv6       OF 1.2+ and OVS 1.1+
       icmpv6_code       1       no     yes   ICMPv6       OF 1.2+ and OVS 1.1+
       nd_target         16      yes    yes   ND           OF 1.2+ and OVS 1.1+
       nd_sll            6       yes    yes   ND solicit   OF 1.2+ and OVS 1.1+
       nd_tll            6       yes    yes   ND advert    OF 1.2+ and OVS 1.1+
       nd_reserved       4       no     yes   ND           OVS 2.11+
       nd_options_type   1       no     yes   ND           OVS 2.11+

   ICMPv4
          Ethernet            IPv4             ICMPv4
        <----------->   <--------------->   <----------->
        48  48   16           8   32  32     8    8
       +---+---+-----+ +---+-----+---+---+ +----+----+---+
       |dst|src|type | |...|proto|src|dst| |type|code|...| ...
       +---+---+-----+ +---+-----+---+---+ +----+----+---+
                0x800         1

       ICMPv4 Type Field
       Name:            icmp_type
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ICMPv4
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_ICMPV4_TYPE (19) since OpenFlow 1.2 and
                        Open vSwitch 1.7
       NXM:             NXM_OF_ICMP_TYPE (13) since Open vSwitch 1.1

       For historical reasons, in an ICMPv4 flow, Open vSwitch
       interprets matches on tp_src as actually referring to the ICMP
       type.

       ICMPv4 Code Field
       Name:            icmp_code
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ICMPv4
       Access:          read/write
       OpenFlow 1.0:    yes (exact match only)
       OpenFlow 1.1:    yes (exact match only)
       OXM:             OXM_OF_ICMPV4_CODE (20) since OpenFlow 1.2 and
                        Open vSwitch 1.7
       NXM:             NXM_OF_ICMP_CODE (14) since Open vSwitch 1.1

       For historical reasons, in an ICMPv4 flow, Open vSwitch
       interprets matches on tp_dst as actually referring to the ICMP
       code.

   ICMPv6
           Ethernet            IPv6            ICMPv6
        <------------>   <-------------->   <----------->
        48  48    16          8   128 128    8    8
       +---+---+------+ +---+----+---+---+ +----+----+---+
       |dst|src| type | |...|next|src|dst| |type|code|...| ...
       +---+---+------+ +---+----+---+---+ +----+----+---+
                0x86dd        58

       ICMPv6 Type Field
       Name:            icmpv6_type
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ICMPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_ICMPV6_TYPE (29) since OpenFlow 1.2 and
                        Open vSwitch 1.7
       NXM:             NXM_NX_ICMPV6_TYPE (21) since Open vSwitch 1.1

       ICMPv6 Code Field
       Name:            icmpv6_code
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ICMPv6
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_ICMPV6_CODE (30) since OpenFlow 1.2 and
                        Open vSwitch 1.7
       NXM:             NXM_NX_ICMPV6_CODE (22) since Open vSwitch 1.1

   ICMPv6 Neighbor Discovery
           Ethernet            IPv6              ICMPv6            ICMPv6 ND
        <------------>   <-------------->   <-------------->   <--------------->
        48  48    16          8   128 128      8     8          128
       +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
       |dst|src| type | |...|next|src|dst| | type  |code|...| |target|option ...|
       +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
                0x86dd        58            135/136  0

       ICMPv6 Neighbor Discovery Target IPv6 Field
       Name:            nd_target
       Width:           128 bits
       Format:          IPv6
       Masking:         arbitrary bitwise masks
       Prerequisites:   ND
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_IPV6_ND_TARGET (31) since OpenFlow 1.2
                        and Open vSwitch 1.7
       NXM:             NXM_NX_ND_TARGET (23) since Open vSwitch 1.1

       ICMPv6 Neighbor Discovery Source Ethernet Address Field
       Name:            nd_sll
       Width:           48 bits
       Format:          Ethernet
       Masking:         arbitrary bitwise masks
       Prerequisites:   ND solicit
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_IPV6_ND_SLL (32) since OpenFlow 1.2 and
                        Open vSwitch 1.7
       NXM:             NXM_NX_ND_SLL (24) since Open vSwitch 1.1

       ICMPv6 Neighbor Discovery Target Ethernet Address Field
       Name:            nd_tll
       Width:           48 bits
       Format:          Ethernet
       Masking:         arbitrary bitwise masks
       Prerequisites:   ND advert
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             OXM_OF_IPV6_ND_TLL (33) since OpenFlow 1.2 and
                        Open vSwitch 1.7
       NXM:             NXM_NX_ND_TLL (25) since Open vSwitch 1.1

       ICMPv6 Neighbor Discovery Reserved Field Field
       Name:            nd_reserved
       Width:           32 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ND
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             ERICOXM_OF_ICMPV6_ND_RESERVED (1) since Open
                        vSwitch 2.11

       This is used to set the R,S,O bits in Neighbor Advertisement
       Messages

       ICMPv6 Neighbor Discovery Options Type Field Field
       Name:            nd_options_type
       Width:           8 bits
       Format:          decimal
       Masking:         not maskable
       Prerequisites:   ND
       Access:          read/write
       OpenFlow 1.0:    not supported
       OpenFlow 1.1:    not supported
       OXM:             none
       NXM:             ERICOXM_OF_ICMPV6_ND_OPTIONS_TYPE (2) since Open
                        vSwitch 2.11

       A value of 1 indicates that the option is Source Link Layer. A
       value of 2 indicates that the options is Target Link Layer. See
       RFC 4861 for further details.

REFERENCES         top

              Casado M. Casado, M. J. Freedman, J. Pettit, J. Luo, N.
                     McKeown, and S. Shenker, ``Ethane: Taking Control
                     of the Enterprise,’’ Computer Communications
                     Review, October 2007.

              ERSPAN M. Foschiano, K. Ghosh, M. Mehta, ``Cisco Systems’
                     Encapsulated Remote Switch Port Analyzer
                     (ERSPAN),’’ ⟨https://tools.ietf.org/html/
                     draft-foschiano-erspan-03⟩ .

              EXT-56 J. Tonsing, ``Permit one of a set of prerequisites
                     to apply, e.g. don’t preclude non-Ethernet media,’’
                     ⟨https://rs.opennetworking.org/bugs/browse/EXT-56⟩
                     (ONF members only).

              EXT-112
                     J. Tourrilhes, ``Support non-Ethernet packets
                     throughout the pipeline,’’ ⟨https://
                     rs.opennetworking.org/bugs/browse/EXT-112⟩ (ONF
                     members only).

              EXT-134
                     J. Tourrilhes, ``Match first nibble of the MPLS
                     payload,’’ ⟨https://rs.opennetworking.org/bugs/
                     browse/EXT-134⟩ (ONF members only).

              Geneve J. Gross, I. Ganga, and T. Sridhar, editors,
                     ``Geneve: Generic Network Virtualization
                     Encapsulation,’’ ⟨https://datatracker.ietf.org/doc/
                     draft-ietf-nvo3-geneve/⟩ .

              IEEE OUI
                     IEEE Standards Association, ``MAC Address Block
                     Large (MA-L),’’ ⟨https://standards.ieee.org/
                     develop/regauth/oui/index.html⟩ .

              NSH    P. Quinn and U. Elzur, editors, ``Network Service
                     Header,’’ ⟨https://datatracker.ietf.org/doc/
                     draft-ietf-sfc-nsh/⟩ .

              OpenFlow 1.0.1
                     Open Networking Foundation, ``OpenFlow Switch
                     Errata, Version 1.0.1,’’ June 2012.

              OpenFlow 1.1
                     OpenFlow Consortium, ``OpenFlow Switch
                     Specification Version 1.1.0 Implemented (Wire
                     Protocol 0x02),’’ February 2011.

              OpenFlow 1.5
                     Open Networking Foundation, ``OpenFlow Switch
                     Specification Version 1.5.0 (Protocol version
                     0x06),’’ December 2014.

              OpenFlow Extensions 1.3.x Package 2
                     Open Networking Foundation, ``OpenFlow Extensions
                     1.3.x Package 2,’’ December 2013.

              TCP Flags Match Field Extension
                     Open Networking Foundation, ``TCP flags match field
                     Extension,’’ December 2014. In [OpenFlow Extensions
                     1.3.x Package 2].

              Pepelnjak
                     I. Pepelnjak, ``OpenFlow and Fermi Estimates,’’
                     ⟨http://blog.ipspace.net/2013/09/
                     openflow-and-fermi-estimates.html⟩ .

              RFC 793
                     ``Transmission Control Protocol,’’ ⟨http://
                     www.ietf.org/rfc/rfc793.txt⟩ .

              RFC 3032
                     E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D.
                     Farinacci, T. Li, and A. Conta, ``MPLS Label Stack
                     Encoding,’’ ⟨http://www.ietf.org/rfc/rfc3032.txt⟩ .

              RFC 3168
                     K. Ramakrishnan, S. Floyd, and D. Black, ``The
                     Addition of Explicit Congestion Notification (ECN)
                     to IP,’’ ⟨https://tools.ietf.org/html/rfc3168⟩ .

              RFC 3540
                     N. Spring, D. Wetherall, and D. Ely, ``Robust
                     Explicit Congestion Notification (ECN) Signaling
                     with Nonces,’’ ⟨https://tools.ietf.org/html/
                     rfc3540⟩ .

              RFC 4632
                     V. Fuller and T. Li, ``Classless Inter-domain
                     Routing (CIDR): The Internet Address Assignment and
                     Aggregation Plan,’’ ⟨https://tools.ietf.org/html/
                     rfc4632⟩ .

              RFC 5462
                     L. Andersson and R. Asati, ``Multiprotocol Label
                     Switching (MPLS) Label Stack Entry: ``EXP’’ Field
                     Renamed to ``Traffic Class’’ Field,’’ ⟨http://
                     www.ietf.org/rfc/rfc5462.txt⟩ .

              RFC 6830
                     D. Farinacci, V. Fuller, D. Meyer, and D. Lewis,
                     ``The Locator/ID Separation Protocol (LISP),’’
                     ⟨http://www.ietf.org/rfc/rfc6830.txt⟩ .

              RFC 7348
                     M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L.
                     Kreeger, T. Sridhar, M. Bursell, and C. Wright,
                     ``Virtual eXtensible Local Area Network (VXLAN): A
                     Framework for Overlaying Virtualized Layer 2
                     Networks over Layer 3 Networks, ’’ ⟨https://
                     tools.ietf.org/html/rfc7348⟩ .

              RFC 7665
                     J. Halpern, Ed. and C. Pignataro, Ed., ``Service
                     Function Chaining (SFC) Architecture,’’ ⟨https://
                     tools.ietf.org/html/rfc7665⟩ .

              Srinivasan
                     V. Srinivasan, S. Suriy, and G. Varghese, ``Packet
                     Classification using Tuple Space Search,’’ SIGCOMM
                     1999.

              Pagiamtzis
                     K. Pagiamtzis and A. Sheikholeslami, ``Content-
                     addressable memory (CAM) circuits and
                     architectures: A tutorial and survey,’’ IEEE
                     Journal of Solid-State Circuits, vol. 41, no. 3,
                     pp. 712-727, March 2006.

              VXLAN Group Policy Option
                     M. Smith and L. Kreeger, `` VXLAN Group Policy
                     Option.’’ Internet-Draft.  ⟨https://tools.ietf.org/
                     html/draft-smith-vxlan-group-policy⟩ .

AUTHORS         top

       Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.

COLOPHON         top

       This page is part of the Open vSwitch (a distributed virtual
       multilayer switch) project.  Information about the project can be
       found at ⟨http://openvswitch.org/⟩.  If you have a bug report for
       this manual page, send it to bugs@openvswitch.org.  This page was
       obtained from the project's upstream Git repository
       ⟨https://github.com/openvswitch/ovs.git⟩ on 2023-12-22.  (At that
       time, the date of the most recent commit that was found in the
       repository was 2023-12-21.)  If you discover any rendering
       problems in this HTML version of the page, or you believe there
       is a better or more up-to-date source for the page, or you have
       corrections or improvements to the information in this COLOPHON
       (which is not part of the original manual page), send a mail to
       man-pages@man7.org

Open vSwitch                     3.2.90                    ovs-fields(7)

Pages that refer to this page: ovs-vswitchd.conf.db(5)ovn-architecture(7)ovs-actions(7)ovn-trace(8)ovs-ofctl(8)