5.3.1.1.3. vlcp.protocol.openflow.defs.nicira_ext¶
Note
This document is generated from the source file.
Created on 2015/8/3
| author: | hubo |
|---|
-
vlcp.protocol.openflow.defs.nicira_ext.nx_flow_format= nx_flow_format¶ /* ‘flags’ bits in struct nx_flow_monitor_request. */
-
vlcp.protocol.openflow.defs.nicira_ext.nx_flow_monitor_flags= nx_flow_monitor_flags¶ /* ‘event’ values in struct nx_flow_update_header. */
-
vlcp.protocol.openflow.defs.nicira_ext.nx_role= nx_role¶ - /* Flexible flow specifications (aka NXM = Nicira Extended Match).
OpenFlow 1.0 has “struct ofp10_match” for specifying flow matches. This
structure is fixed-length and hence difficult to extend. This section
describes a more flexible, variable-length flow match, called “nx_match” for
short, that is also supported by Open vSwitch. This section also defines a
replacement for each OpenFlow message that includes struct ofp10_match.
Format
An nx_match is a sequence of zero or more “nxm_entry”s, which are
type-length-value (TLV) entries, each 5 to 259 (inclusive) bytes long.
“nxm_entry”s are not aligned on or padded to any multibyte boundary. The
first 4 bytes of an nxm_entry are its “header”, followed by the entry’s
“body”.
An nxm_entry’s header is interpreted as a 32-bit word in network byte order:
|31 16 15 9| 8 7 0
- nxm_vendor | nxm_field |hm| nxm_length |
The most-significant 23 bits of the header are collectively “nxm_type”.
Bits 16…31 are “nxm_vendor”, one of the NXM_VENDOR_* values below. Bits
9…15 are “nxm_field”, which is a vendor-specific value. nxm_type normally
designates a protocol header, such as the Ethernet type, but it can also
refer to packet metadata, such as the switch port on which a packet arrived.
Bit 8 is “nxm_hasmask” (labeled “hm” above for space reasons). The meaning
of this bit is explained later.
The least-significant 8 bits are “nxm_length”, a positive integer. The
length of the nxm_entry, including the header, is exactly 4 + nxm_length
bytes.
For a given nxm_vendor, nxm_field, and nxm_hasmask value, nxm_length is a
constant. It is included only to allow software to minimally parse
“nxm_entry”s of unknown types. (Similarly, for a given nxm_vendor,
nxm_field, and nxm_length, nxm_hasmask is a constant.)
Semantics
A zero-length nx_match (one with no “nxm_entry”s) matches every packet.
An nxm_entry places a constraint on the packets matched by the nx_match:
- If nxm_hasmask is 0, the nxm_entry’s body contains a value for the
field, called “nxm_value”. The nx_match matches only packets in which
the field equals nxm_value.
- If nxm_hasmask is 1, then the nxm_entry’s body contains a value for the
field (nxm_value), followed by a bitmask of the same length as the
value, called “nxm_mask”. For each 1-bit in position J in nxm_mask, the
nx_match matches only packets for which bit J in the given field’s value
matches bit J in nxm_value. A 0-bit in nxm_mask causes the
corresponding bit in nxm_value is ignored (it should be 0; Open vSwitch
may enforce this someday), as is the corresponding bit in the field’s
value. (The sense of the nxm_mask bits is the opposite of that used by
the “wildcards” member of struct ofp10_match.)
When nxm_hasmask is 1, nxm_length is always even.
An all-zero-bits nxm_mask is equivalent to omitting the nxm_entry
entirely. An all-one-bits nxm_mask is equivalent to specifying 0 for
nxm_hasmask.
When there are multiple “nxm_entry”s, all of the constraints must be met.
Mask Restrictions
Masks may be restricted:
- Some nxm_types may not support masked wildcards, that is, nxm_hasmask
must always be 0 when these fields are specified. For example, the
field that identifies the port on which a packet was received may not be
masked.
- Some nxm_types that do support masked wildcards may only support certain
nxm_mask patterns. For example, fields that have IPv4 address values
may be restricted to CIDR masks.
These restrictions should be noted in specifications for individual fields.
A switch may accept an nxm_hasmask or nxm_mask value that the specification
disallows, if the switch correctly implements support for that nxm_hasmask
or nxm_mask value. A switch must reject an attempt to set up a flow that
contains a nxm_hasmask or nxm_mask value that it does not support.
Prerequisite Restrictions
The presence of an nxm_entry with a given nxm_type may be restricted based
on the presence of or values of other “nxm_entry”s. For example:
- An nxm_entry for nxm_type=NXM_OF_IP_TOS is allowed only if it is
preceded by another entry with nxm_type=NXM_OF_ETH_TYPE, nxm_hasmask=0,
and nxm_value=0x0800. That is, matching on the IP source address is
allowed only if the Ethernet type is explicitly set to IP.
- An nxm_entry for nxm_type=NXM_OF_TCP_SRC is allowed only if it is
preceded by an entry with nxm_type=NXM_OF_ETH_TYPE, nxm_hasmask=0, and
nxm_value either 0x0800 or 0x86dd, and another with
nxm_type=NXM_OF_IP_PROTO, nxm_hasmask=0, nxm_value=6, in that order.
That is, matching on the TCP source port is allowed only if the Ethernet
type is IP or IPv6 and the IP protocol is TCP.
These restrictions should be noted in specifications for individual fields.
A switch may implement relaxed versions of these restrictions. A switch
must reject an attempt to set up a flow that violates its restrictions.
Ordering Restrictions
An nxm_entry that has prerequisite restrictions must appear after the
“nxm_entry”s for its prerequisites. Ordering of “nxm_entry”s within an
nx_match is not otherwise constrained.
Any given nxm_type may appear in an nx_match at most once.
nxm_entry Examples
These examples show the format of a single nxm_entry with particular
nxm_hasmask and nxm_length values. The diagrams are labeled with field
numbers and byte indexes.
8-bit nxm_value, nxm_hasmask=1, nxm_length=2:
0 3 4 5
- header | v | m |
16-bit nxm_value, nxm_hasmask=0, nxm_length=2:
0 3 4 5
- header | value|
32-bit nxm_value, nxm_hasmask=0, nxm_length=4:
0 3 4 7
- header | nxm_value |
48-bit nxm_value, nxm_hasmask=0, nxm_length=6:
0 3 4 9
- header | nxm_value |
48-bit nxm_value, nxm_hasmask=1, nxm_length=12:
0 3 4 9 10 15
- header | nxm_value | nxm_mask |
Error Reporting
A switch should report an error in an nx_match using error type
OFPET_BAD_REQUEST and one of the NXBRC_NXM_* codes. Ideally the switch
should report a specific error code, if one is assigned for the particular
problem, but NXBRC_NXM_INVALID is also available to report a generic
nx_match error.
*/