Provided by: openvswitch-common_3.1.0-1ubuntu1_amd64 bug

NAME

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

INTRODUCTION

       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

       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

   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

   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

   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

   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

   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

   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

   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

   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

   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

   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  16  48  16
       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
       |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

   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

   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

   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

              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

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