This document is generated from the source file.

View Source on GitHub

Created on 2015/8/3

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:

  • |<-------------------- nxm_type ------------------>|

  • |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.


vlcp.protocol.openflow.defs.nicira_ext.nx_vendor_error_types = {0: nx_vendor_error_nx, 1: nx_vendor_error_nx, 2: nx_vendor_error_nx, 3: nx_vendor_error_nx, 5: nx_vendor_error_nx, 13: nx_vendor_error_nx, 14: nx_vendor_error_nx}

/* Fields to use when hashing flows. */