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.
