+/* Open vSwitch fields
+ * ===================
+ *
+ * A "field" is a property of a packet. Most familiarly, "data fields" are
+ * fields that can be extracted from a packet.
+ *
+ * Some data fields are always present as a consequence of the basic networking
+ * technology in use. Ethernet is the assumed base technology for current
+ * versions of OpenFlow and Open vSwitch, so Ethernet header fields are always
+ * available.
+ *
+ * Other data fields are not always present. A packet contains ARP fields, for
+ * example, only when its Ethernet header indicates the Ethertype for ARP,
+ * 0x0806. We say that a field is "applicable" when it is it present in a
+ * packet, and "inapplicable" when it is not, and 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,
+ * 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). See MFF_VLAN_TCI for an example.
+ *
+ * Conceptually, 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 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.
+ *
+ * (Practically, however, OVS represents a field's value as some fixed member
+ * in its "struct flow", so accessing that member will obtain some value. Some
+ * members are used for more than one purpose, e.g. the "tp_src" member
+ * represents the TCP, UDP, and SCTP source port, so the value read may not
+ * even make sense. For this reason, it is important to know whether a field's
+ * prerequisites are satisfied before attempting to read it.)
+ *
+ * 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.
+ *
+ * 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. Most data fields
+ * are copied directly from protocol headers, e.g. at layer 2, MFF_ETH_SRC is
+ * copied from the Ethernet source address and MFF_ETH_DST from the destination
+ * address. Other data fields are copied from a packet with padding, usually
+ * with zeros and in the most significant positions (see e.g. MFF_MPLS_LABEL)
+ * but not always (see e.g. MFF_IP_DSCP). A final category of data fields is
+ * transformed in other ways as they are copied from the packets, to make them
+ * more useful for matching, e.g. MFF_IP_FRAG describes whether a packet is a
+ * fragment but it is not copied directly from the IP header.
+ *
+ *
+ * Field specifications
+ * ====================
+ *
+ * Each of the enumeration values below represents a field. The comments
+ * preceding each enum must be in a stylized form that is parsed at compile
+ * time by the extract-ofp-fields program. The comment itself consists of a
+ * series of paragraphs separate by blank lines. The paragraphs consist of:
+ *
+ * - The first paragraph gives the user-visible name of the field as a
+ * quoted string. This is the name used for parsing and formatting the
+ * field.
+ *
+ * For historical reasons, some fields have an additional name that is
+ * accepted as an alternative in parsing. This name, when there is one,
+ * is given as a quoted string in parentheses along with "aka". For
+ * example:
+ *
+ * "tun_id" (aka "tunnel_id").
+ *
+ * New fields should have only one name.
+ *
+ * - Any number of paragraphs of free text that describe the field. This
+ * is meant for human readers, so extract-ofp-fields ignores it.
+ *
+ * - A final paragraph that consists of a series of key-value pairs, one
+ * per line, in the form "key: value." where the period at the end of the
+ * line is a mandatory part of the syntax.
+ *
+ * Every field must specify the following key-value pairs:
+ *
+ * Type:
+ *
+ * The format and size of the field's value. Some possible values are
+ * generic:
+ *
+ * u8: A one-byte field.
+ * be16: A two-byte field.
+ * be32: A four-byte field.
+ * be64: An eight-byte field.
+ *
+ * The remaining values imply more about the value's semantics, though OVS
+ * does not currently take advantage of this additional information:
+ *
+ * MAC: A six-byte field whose value is an Ethernet address.
+ * IPv6: A 16-byte field whose value is an IPv6 address.
+ * tunnelMD: A variable length field, up to 124 bytes, that carries
+ * tunnel metadata.
+ *
+ * Maskable:
+ *
+ * Either "bitwise", if OVS supports matching any subset of bits in the
+ * field, or "no", if OVS only supports matching or wildcarding the entire
+ * field.
+ *
+ * Formatting:
+ *
+ * Explains how a field's value is formatted and parsed for human
+ * consumption. Some of the options are fairly generally useful:
+ *
+ * decimal: Formats the value as a decimal number. On parsing, accepts
+ * decimal (with no prefix), hexadecimal with 0x prefix, or octal
+ * with 0 prefix.
+ *
+ * hexadecimal: Same as decimal except nonzero values are formatted in
+ * hex with 0x prefix. The default for parsing is *not* hexadecimal:
+ * only with a 0x prefix is the input in hexadecimal.
+ *
+ * Ethernet: Formats and accepts the common format xx:xx:xx:xx:xx:xx.
+ * 6-byte fields only.
+ *
+ * IPv4: Formats and accepts the common format w.x.y.z. 4-byte fields
+ * only.
+ *
+ * IPv6: Formats and accepts the common IPv6 formats. 16-byte fields
+ * only.
+ *
+ * OpenFlow 1.0 port: Accepts an OpenFlow well-known port name
+ * (e.g. "IN_PORT") in uppercase or lowercase, or a 16-bit port
+ * number in decimal. Formats ports using their well-known names in
+ * uppercase, or in decimal otherwise. 2-byte fields only.
+ *
+ * OpenFlow 1.1+ port: Same syntax as for OpenFlow 1.0 ports but for
+ * 4-byte OpenFlow 1.1+ port number fields.
+ *
+ * Others are very specific to particular fields:
+ *
+ * frag: One of the strings "no", "first", "later", "yes", "not_later"
+ * describing which IPv4/v6 fragments are matched.
+ *
+ * tunnel flags: Any number of the strings "df", "csum", "key", or
+ * "oam" separated by "|".
+ *
+ * TCP flags: See the description of tcp_flags in ovs-ofctl(8).
+ *
+ * Prerequisites:
+ *
+ * The field's prerequisites. The values should be straightfoward.
+ *
+ * Access:
+ *
+ * Either "read-only", for a field that cannot be changed via OpenFlow, or
+ * "read/write" for a modifiable field.
+ *
+ * NXM:
+ *
+ * If the field has an NXM field assignment, then this specifies the NXM
+ * name of the field (e.g. "NXM_OF_ETH_SRC"), followed by its nxm_type in
+ * parentheses, followed by "since v<x>.<y>" specifying the version of Open
+ * vSwitch that first supported this field in NXM (e.g. "since v1.1" if it
+ * was introduced in Open vSwitch 1.1).
+ *
+ * The NXM name must begin with NXM_OF_ or NXM_NX_. This allows OVS to
+ * determine the correct NXM class.
+ *
+ * If the field does not have an NXM field assignment, specify "none".
+ *
+ * OXM:
+ *
+ * If the field has an OXM field assignment, then this specifies the OXM
+ * name of the field (e.g. "OXM_OF_ETH_SRC"), followed by its nxm_type in
+ * parentheses, followed by "since OF<a>.<b> v<x>.<y>" specifying the
+ * versions of OpenFlow and Open vSwitch that first supported this field in
+ * OXM (e.g. "since OF1.3 and v1.10" if it was introduced in OpenFlow 1.3
+ * and first supported by Open vSwitch in version 1.10).
+ *
+ * Some fields have more than one OXM field assignment. For example,
+ * actset_output has an experimenter OXM assignment in OpenFlow 1.3 and a
+ * standard OXM assignment in OpenFlow 1.5. In such a case, specify both,
+ * separated by commas.
+ *
+ * OVS uses the start of the OXM field name to determine the correct OXM
+ * class. To support a new OXM class, edit the mapping table in
+ * build-aux/extract-ofp-fields.
+ *
+ * If the field does not have an OXM field assignment, specify "none".
+ *
+ * The following key-value pairs are optional. Open vSwitch already supports
+ * all the fields to which they apply, so new fields should probably not
+ * include these pairs:
+ *
+ * OF1.0:
+ *
+ * Specify this as "exact match" if OpenFlow 1.0 can match or wildcard the
+ * entire field, or as "CIDR mask" if OpenFlow 1.0 can match any CIDR
+ * prefix of the field. (OpenFlow 1.0 did not support bitwise matching.)
+ * Omit, if OpenFlow 1.0 did not support this field.
+ *
+ * OF1.1:
+ *
+ * Specify this as "exact match" if OpenFlow 1.1 can match or wildcard the
+ * entire field, or as "bitwise" if OpenFlow 1.1 can match any subset of
+ * bits in the field. Omit, if OpenFlow 1.1 did not support this field.
+ *
+ * The following key-value pair is optional:
+ *
+ * Prefix lookup member:
+ *
+ * If this field makes sense for use with classifier_set_prefix_fields(),
+ * specify the name of the "struct flow" member that corresponds to the
+ * field.
+ *
+ * Finally, a few "register" fields have very similar names and purposes,
+ * e.g. MFF_REG0 through MFF_REG7. For these, the comments may be merged
+ * together using <N> as a metasyntactic variable for the numeric suffix.
+ * Lines in the comment that are specific to one of the particular fields by
+ * writing, e.g. <1>, to consider that line only for e.g. MFF_REG1.
+ */